Skip to content
Avanet

Connect Microsoft AD FS to Sophos Fusion

Microsoft AD FS can authenticate existing Active Directory identities for Sophos Fusion (formerly Sophos Central). The flow is SP-initiated: Sophos Fusion supplies the Entity ID and Callback URL, and AD FS handles sign-in through a claims-aware Relying Party Trust.

AD FS adds self-operated infrastructure compared with Entra ID or a managed OIDC service. Certificates, metadata, external availability, high availability, and patching of the Federation Service remain the organization’s responsibility.

Prerequisites

Requirements include Super Admin permissions in Sophos Fusion, an operational AD FS service, approval by the AD owner, and a verified domain. Sophos Fusion administrators and users must exist in the relevant AD forest, and their email addresses must match those stored in Sophos Fusion.

Before enabling Federated credentials only, every affected administrator and user must be assigned to a verified domain and a working identity provider. Otherwise, the change locks those accounts out. An independent Sophos break-glass account and successful pilot are prerequisites, not troubleshooting measures after the fact.

Verify the AD FS metadata URL, Federation Service certificates, and external name resolution before changing Sophos Fusion. Sophos shows https://login.microsoftonline.com/<TenantDomainName>/FederationMetadata/2007-06/FederationMetadata.xml as the metadata format; for a classic self-hosted AD FS service, use the FederationMetadata URL actually published by that service. Do not copy a Microsoft Online example blindly to on-premises AD FS.

Prepare the domain and provider in Sophos Fusion

Under Global Settings > Access Control > Sign-in and Identity > Sophos sign-in > Verify domains, first use Add domain to save the domain and its description. Sophos Fusion then displays the TXT record under Verify domain ownership. Add it exactly to the public DNS zone. After propagation, return to Verify domains and select Verify domain ownership > Verify. Propagation can take up to 24 hours; successful verification is valid for one year and can be renewed earlier.

Then:

  1. Open Federated identity providers and create a provider.
  2. Enter a name without problematic special characters and a description.
  3. Select Type: Microsoft AD FS and the appropriate vendor.
  4. Enter the verified AD FS metadata URL.
  5. Select the verified domain.
  6. Decide whether AD FS enforces MFA or Sophos Fusion requires its own MFA after successful AD FS authentication.
  7. Save, then copy the Sophos Fusion-generated Entity ID and Callback URL from the provider.

Do not yet enable the provider as the tenant’s only sign-in method.

Create the Relying Party Trust in AD FS

On the AD FS server, open Server Manager > Tools > AD FS Management and start Add Relying Party Trust:

  1. Select Claims Aware.
  2. Use Enter data about the relying party manually.
  3. Enter a unique Display Name.
  4. Select AD FS profile; continue past the certificate step unless additional encryption is required.
  5. Under Configure URL, enable Enable support for the WS-Federation Passive protocol.
  6. Enter the Callback URL copied from Sophos Fusion as the WS-Federation Passive Protocol URL.
  7. Under Configure Identifiers, add the Entity ID copied from Sophos Fusion as the Relying Party Trust Identifier.
  8. Configure MFA according to the organization’s AD FS and Conditional Access design.
  9. Permit only the required users for the pilot. Sophos shows Permit all users to access this relying party as the default approach; a controlled pilot group is safer.
  10. Finish the trust and immediately open Edit Claim Rules.

Issue the correct claims

Under Issuance Transform Rules > Add rule, select Send LDAP Attributes as Claims. Use Active Directory as the Attribute Store. Configure this mapping:

LDAP AttributeOutgoing Claim Type
E-mail-AddressesName ID
Given-NameGiven Name
SurnameSurname
E-mail-AddressesE-mail Address

The email value is the decisive mapping to Sophos Fusion. Correct empty, duplicate, or differing addresses before rollout. A successful AD FS authentication without a matching email claim still does not reliably reach the correct Sophos Fusion account.

Enable and test the provider

After creating the AD FS trust, enable the provider in Sophos Fusion with Turn on. Initially keep the choice between Sophos credentials and federated sign-in under Sophos sign-in. Click Add custom rule, add the independent break-glass administrator to Selected Users, choose Sophos Central Admin email and password, and save the rule. Then test it in a separate private browser session. Sophos also automatically adds the administrator who changes the sign-in settings to such a custom rule. This automatic safeguard is not a substitute for a deliberately selected and documented emergency account.

Testing starts at fusion.sophos.com on the Sophos sign-in page and includes:

  • a normal administrator,
  • a Super Admin,
  • AD FS MFA or Sophos Fusion MFA,
  • a user without permission on the trust,
  • sign-out and sign-in again,
  • the documented expiry date, owner, and planned replacement test for the AD FS signing certificate,
  • an independent break-glass account using Sophos sign-in.

The sign-in test succeeds when every permitted test user reaches the expected Sophos Fusion account with the intended role after AD FS and MFA checks, the unauthorized user is rejected, and break-glass sign-in still works.

Only then enable Federated credentials only. At that point, every affected account must be assigned to a verified domain and enabled provider. After saving, test federated sign-in and the custom rule again in private browser sessions; an existing administrator session alone is not a lockout test.

Troubleshooting

  • Metadata URL is unreachable: Check DNS, certificate, TLS, Web Application Proxy, and Federation Service.
  • Relying Party Identifier is invalid: Copy the Entity ID exactly from Sophos Fusion and check for invisible spaces.
  • Callback error: Compare the WS-Federation Passive URL with the current Sophos Fusion Callback URL.
  • AD FS accepts the user but Sophos Fusion does not: Check email and Name ID claims and the email address in Sophos Fusion.
  • MFA is missing or duplicated: Review AD FS rules together with the IdP enforced MFA selection.
  • Provider fails after a certificate replacement: Update metadata, the signing certificate, and Sophos Fusion trust, then repeat the pilot.

The broader workflow for sign-in rules, MFA recovery, and controlled transition to Federated credentials only is covered in Secure Sophos Fusion sign-in with MFA, passkeys, and an IdP.

Frequently asked questions

Can the same AD FS trust be used without claims?

No. Sophos Fusion requires a consistent email identity in particular. Configure the trust as claims-aware and issue Name ID, first name, surname, and email address as documented.

Should Permit all users be used?

A limited pilot group is safer for the initial rollout. Expand permission to the intended population only after claims, MFA, and fallback work.