Zum Inhalt springen
Avanet

Microsoft AD FS mit Sophos Central verbinden

Microsoft AD FS kann bestehende Active-Directory-Identitäten für Sophos Central authentifizieren. Der Ablauf ist SP-initiiert: Sophos Central liefert Entity ID und Callback URL, AD FS verarbeitet die Anmeldung als Claims-Aware Relying Party Trust.

AD FS erhöht den Eigenbetrieb gegenüber Entra ID oder einem verwalteten OIDC-Dienst. Zertifikate, Metadaten, externe Erreichbarkeit, Hochverfügbarkeit und Patchstand des Federation Service bleiben in der Verantwortung der Organisation.

Voraussetzungen

Erforderlich sind Super-Admin-Rechte in Central, ein betriebsbereiter AD-FS-Dienst, Freigabe des AD-Verantwortlichen und eine verifizierte Domain. Central-Administratoren und Benutzer müssen im verwendeten AD-Forest vorhanden sein; deren E-Mail-Adressen müssen den in Central hinterlegten Adressen entsprechen.

Bevor Federated credentials only als Anmeldeoption aktiviert wird, muss jeder betroffene Administrator und Benutzer einer verifizierten Domain und einem funktionsfähigen Identity Provider zugeordnet sein. Andernfalls sperrt die Umstellung diese Konten aus. Ein unabhängiges Sophos-Break-Glass-Konto und ein erfolgreicher Pilot gehören daher zu den Voraussetzungen, nicht erst zum nachträglichen Troubleshooting.

Die AD-FS-Metadata-URL, Federation-Service-Zertifikate und externe Namensauflösung werden vor der Central-Änderung geprüft. Sophos zeigt als Metadatenformat https://login.microsoftonline.com/<TenantDomainName>/FederationMetadata/2007-06/FederationMetadata.xml; bei einem klassischen eigenen AD-FS-Service wird jedoch die tatsächlich publizierte FederationMetadata-URL des eigenen Dienstes verwendet. Ein Microsoft-Online-Beispiel wird nicht blind auf On-Premises AD FS übertragen.

Domain und Provider in Central vorbereiten

Unter Global Settings > Access Control > Sign-in and Identity > Sophos sign-in > Verify domains wird die Domain per DNS-TXT-Record verifiziert. Die Propagation kann bis zu 24 Stunden dauern, die Verifizierung gilt ein Jahr.

Danach:

  1. Federated identity providers öffnen und einen neuen Provider anlegen.
  2. Name ohne problematische Sonderzeichen und Beschreibung erfassen.
  3. Type: Microsoft AD FS und den passenden Vendor wählen.
  4. Die geprüfte AD FS metadata URL eintragen.
  5. Die verifizierte Domain auswählen.
  6. Festlegen, ob AD FS MFA erzwingt oder Central nach erfolgreicher AD-FS-Anmeldung eigene MFA verlangt.
  7. Speichern und aus dem Provider die von Central generierte Entity ID sowie Callback URL kopieren.

Der Provider wird noch nicht tenantweit als einziger Anmeldeweg aktiviert.

Relying Party Trust in AD FS anlegen

Auf dem AD-FS-Server wird über Server Manager > Tools > AD FS Management der Assistent Add Relying Party Trust gestartet:

  1. Claims Aware auswählen.
  2. Enter data about the relying party manually verwenden.
  3. Einen eindeutigen Display Name erfassen.
  4. AD FS profile wählen; beim Zertifikatschritt ohne zusätzliche Verschlüsselungsanforderung weitergehen.
  5. Unter Configure URL Enable support for the WS-Federation Passive protocol aktivieren.
  6. Die aus Central kopierte Callback URL als WS-Federation Passive Protocol URL eintragen.
  7. Unter Configure Identifiers die aus Central kopierte Entity ID als Relying Party Trust Identifier hinzufügen.
  8. MFA nach dem eigenen AD-FS- und Conditional-Access-Design konfigurieren.
  9. Für den Pilot nur die benötigten Benutzer zulassen. Sophos zeigt Permit all users to access this relying party als Standardweg; eine kontrollierte Pilotgruppe ist sicherer.
  10. Den Trust fertigstellen und direkt den Dialog Edit Claim Rules öffnen.

Claims korrekt ausgeben

Unter Issuance Transform Rules > Add rule wird Send LDAP Attributes as Claims gewählt. Als Attribute Store dient Active Directory. Die Zuordnung lautet:

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

Der E-Mail-Wert ist die entscheidende Zuordnung zu Central. Leere, doppelte oder abweichende Adressen werden vor dem Rollout korrigiert. Eine erfolgreiche AD-FS-Anmeldung ohne passenden E-Mail-Claim führt trotzdem nicht zuverlässig zum richtigen Central-Konto.

Provider aktivieren und testen

Nach dem AD-FS-Trust wird der Provider in Central mit Turn on aktiviert. Unter Sophos sign-in bleibt zunächst die Auswahl zwischen Sophos-Zugangsdaten und föderierter Anmeldung bestehen.

Der Test startet auf der Sophos-Anmeldeseite und umfasst:

  • einen normalen Administrator,
  • einen Super Admin,
  • AD-FS-MFA beziehungsweise Central-MFA,
  • einen Benutzer ohne Trust-Berechtigung,
  • Abmeldung und erneute Anmeldung,
  • Ablauf oder Wechsel des AD-FS-Signing-Zertifikats,
  • ein unabhängiges Break-Glass-Konto mit Sophos-Login.

Erst danach wird Federated credentials only aktiviert. Alle betroffenen Konten müssen zu diesem Zeitpunkt einer verifizierten Domain und dem eingeschalteten Provider zugeordnet sein.

Troubleshooting

  • Metadata URL nicht erreichbar: DNS, Zertifikat, TLS, Web Application Proxy und Federation Service prüfen.
  • Relying Party Identifier ungültig: Entity ID exakt aus Central übernehmen und auf unsichtbare Leerzeichen prüfen.
  • Callback-Fehler: WS-Federation Passive URL mit der aktuellen Central Callback URL vergleichen.
  • AD FS akzeptiert den Benutzer, Central nicht: E-Mail- und Name-ID-Claims sowie Central-E-Mail prüfen.
  • MFA fehlt oder doppelt: AD-FS-Regeln und Auswahl IdP enforced MFA gemeinsam kontrollieren.
  • Provider nach Zertifikatswechsel gestört: Metadata, Signing-Zertifikat und Central-Vertrauen aktualisieren und erneut pilotieren.

Der übergeordnete Ablauf für Sign-in Rules, MFA-Recovery und den kontrollierten Wechsel auf Federated credentials only steht unter Sophos Central Anmeldung mit MFA, Passkeys und IdP absichern.

Häufige Fragen

Kann derselbe AD-FS-Trust ohne Claims verwendet werden?

Nein. Central benötigt insbesondere eine konsistente E-Mail-Identität. Der Trust wird als Claims-Aware eingerichtet und gibt Name ID, Vorname, Nachname und E-Mail-Adresse wie dokumentiert aus.

Soll Permit all users verwendet werden?

Für einen ersten sicheren Rollout ist eine begrenzte Pilotgruppe besser. Erst wenn Claims, MFA und Rückfallweg funktionieren, wird die Berechtigung auf den gewünschten Benutzerkreis erweitert.