Connect Microsoft AD FS to Sophos Central
Microsoft AD FS can authenticate existing Active Directory identities for Sophos Central. The flow is SP-initiated: Sophos Central 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 Central, an operational AD FS service, approval by the AD owner, and a verified domain. Central administrators and users must exist in the relevant AD forest, and their email addresses must match those stored in Central.
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 Central. 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 Central
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. Central 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:
- Open Federated identity providers and create a provider.
- Enter a name without problematic special characters and a description.
- Select Type: Microsoft AD FS and the appropriate vendor.
- Enter the verified AD FS metadata URL.
- Select the verified domain.
- Decide whether AD FS enforces MFA or Central requires its own MFA after successful AD FS authentication.
- Save, then copy the Central-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:
- Select Claims Aware.
- Use Enter data about the relying party manually.
- Enter a unique Display Name.
- Select AD FS profile; continue past the certificate step unless additional encryption is required.
- Under Configure URL, enable Enable support for the WS-Federation Passive protocol.
- Enter the Callback URL copied from Central as the WS-Federation Passive Protocol URL.
- Under Configure Identifiers, add the Entity ID copied from Central as the Relying Party Trust Identifier.
- Configure MFA according to the organization’s AD FS and Conditional Access design.
- 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.
- 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 Attribute | Outgoing Claim Type |
|---|---|
E-mail-Addresses | Name ID |
Given-Name | Given Name |
Surname | Surname |
E-mail-Addresses | E-mail Address |
The email value is the decisive mapping to Central. 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 Central account.
Enable and test the provider
After creating the AD FS trust, enable the provider in Central 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 on the Sophos sign-in page and includes:
- a normal administrator,
- a Super Admin,
- AD FS MFA or Central 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 Central 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 Central and check for invisible spaces.
- Callback error: Compare the WS-Federation Passive URL with the current Central Callback URL.
- AD FS accepts the user but Central does not: Check email and Name ID claims and the email address in Central.
- 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 Central 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 Central sign-in with MFA, passkeys, and an IdP.