AP6 mit Microsoft Entra ID authentifizieren

Sophos Fusion Wireless kann Microsoft Entra ID als Identitätsanbieter für AP6-SSIDs mit Enterprise-Verschlüsselung verwenden. Der Ablauf besteht aus drei getrennten Teilen: einer Single-Tenant-App in Entra ID, einem externen IdP-Objekt in Sophos Fusion (ehemals Sophos Central) und einem passenden EAP-Profil auf den Endgeräten.

Kurzablauf: In Entra ID eine App ohne Redirect URI registrieren, Client- und Tenant-ID notieren, ein Client Secret erstellen und genau Domain.Read.All als Application- sowie User.Read als Delegated-Berechtigung setzen. Danach in Sophos Fusion unter My Products > Wireless > SSIDs > RADIUS > Add > Add external identity provider die vier Werte eintragen, Test connection ausführen und den IdP einer AP6-Enterprise-SSID zuordnen.

⚠️ Wichtige Grenze: Dieser IdP unterstützt hier nur EAP-TTLS mit PAP als innerer Authentifizierung. RADIUS-zugewiesene VLANs, RADIUS Accounting und die Verwendung als Backend für ein Captive Portal werden nicht unterstützt. Wenn eine dieser Funktionen benötigt wird, ist dieser Entra-Ablauf nicht passend.

Voraussetzungen und Cliententscheidung

Vor der App-Registrierung müssen die vorgesehenen Benutzerkonten in Entra ID vorhanden und nutzbar sein. Microsoft beschreibt Anlage, Einladung und Löschung im verlinkten Benutzerleitfaden. Für den Piloten verwendet man ein freigegebenes Testkonto und keine privilegierte Administratorkennung.

Das Vorhandensein eines Kontos belegt keine Kompatibilität. Vor der Bereitstellung erstellt man eine Tenant-spezifische Pilotmatrix für die tatsächlich vorgesehenen Richtlinien und Identitätstypen: MFA und Conditional Access, kennwortlose Konten, Gastkonten sowie föderierte Identitäten. TTLS/PAP kann keine interaktive Browserabfrage anzeigen. Unterstützung darf nicht aus den Graph-Berechtigungen abgeleitet werden. Gelingt für einen Fall keine echte Pilotanmeldung oder hat Sophos dessen Authentifizierungsablauf nicht bestätigt, wird dieser Fall gestoppt und an Sophos Support sowie den Identitätsverantwortlichen eskaliert.

Die Clientflotte entscheidet über den Verschlüsselungsmodus:

Windows und Android: Sophos dokumentiert, dass diese Geräte TTLS/PAP mit WPA3 Enterprise nicht unterstützen. Die SSID muss deshalb WPA2/WPA3 Enterprise verwenden.
Apple-Geräte: Sie benötigen ein installiertes WLAN-Konfigurationsprofil mit EAP method: TTLS und Inner authentication: PAP. Sophos verweist zum Erstellen und Installieren auf Apple Configurator.
Andere Clients: Die Sophos-Seite macht keine Kompatibilitätszusage. EAP-TTLS/PAP und der gewählte Enterprise-Modus müssen deshalb vor dem Rollout mit den tatsächlich eingesetzten Modellen und Betriebssystemständen geprüft werden.

⚠️ Stop-Bedingung zum Schutz der Zugangsdaten: PAP überträgt ein wiederverwendbares Kennwort innerhalb des TTLS-Tunnels. Jeder Client muss deshalb über freigegebene MDM- oder Clientvorgaben sowohl die erwartete Serverzertifikatskette als auch die Serveridentität prüfen. Die Zertifikatsprüfung niemals deaktivieren und unbekannte Zertifikate niemals akzeptieren. Sophos veröffentlicht weder die umgebungsspezifische Serveridentität und Vertrauenskette noch alle Profilwerte. Kann der Identitätsverantwortliche dafür keine freigegebenen Werte liefern, ist die Bereitstellung blockiert; Werte nicht erraten.

Entra-App registrieren und Werte sichern

Im Microsoft Entra admin center anmelden.
Entra ID > App registrations öffnen und New registration wählen.
Einen eindeutigen Namen eintragen, beispielsweise Sophos-Central-AP6-Auth.
Unter Supported account types Single tenant only wählen.
Redirect URI leer lassen, sofern die eigene Umgebung keine verlangt, und Register wählen.
In der App unter Overview die Application (client) ID und Directory (tenant) ID notieren.
Certificates & secrets > Client secrets > New client secret öffnen, eine Beschreibung und eine zur eigenen Rotation passende Gültigkeit wählen und Add anklicken.
Den Secret-Wert sofort über Copy to clipboard in den freigegebenen Secret Store übernehmen. Er wird danach nicht noch einmal angezeigt; bei Verlust muss ein neuer erstellt werden.
Unter Entra ID > Domain names > Custom domain names den Name der vorgesehenen Domain notieren und kontrollieren, dass ihr Status Verified ist.

Für Sophos Fusion liegen damit vier umgebungsspezifische Werte vor: Client ID, Client secret, verifizierter Domain name und Tenant ID. IDs dürfen in die vorgesehene Konfiguration, das Secret dagegen nicht in Tickets, Screenshots, Chat oder Versionsverwaltung gelangen.

Nur die dokumentierten Graph-Berechtigungen setzen

In der registrierten App öffnet man API permissions > Add a permission > Microsoft Graph. Die Berechtigungen werden getrennt hinzugefügt, damit ihr Typ eindeutig ist:

Application permissions wählen, nach Domain.Read.All suchen, die Berechtigung markieren und Add permissions wählen.
Erneut Add a permission > Microsoft Graph öffnen, Delegated permissions wählen, nach User.Read suchen, die Berechtigung markieren und Add permissions wählen.

Permission	Type	Admin consent required
`Domain.Read.All`	`Application`	Yes
`User.Read`	`Delegated`	Yes

Danach Grant admin consent for und Yes wählen. In der abschliessenden Liste ausdrücklich prüfen, dass Domain.Read.All den Typ Application, User.Read den Typ Delegated und beide den Status Granted zeigen. Sophos verlangt genau diese Kombination; keine zusätzlichen Graph-Berechtigungen vorsorglich vergeben. Wer konfigurieren und zustimmen darf, hängt von der Entra-Verwaltung ab; diese Anleitung erfindet dafür keine Verzeichnisrolle.

Entra ID in Sophos Fusion als IdP anlegen

Unter https://fusion.sophos.com bei Sophos Fusion anmelden und My Products > Wireless > SSIDs > RADIUS öffnen.
Add > Add external identity provider wählen.
Unter Name einen eindeutigen Anzeigenamen eintragen, beispielsweise HQ-Entra-ID. Dieser Name erscheint auf der RADIUS-Seite und in der Serverauswahl einer AP6-SSID.
Die Application (client) ID als Client ID eintragen.
Den zuvor gesicherten Secret-Wert unter Client secret eintragen.
Den verifizierten benutzerdefinierten Domainnamen unter Domain name eintragen.
Die Directory (tenant) ID als Tenant ID eintragen.
Test connection wählen. Nur bei einer Erfolgsmeldung mit Save speichern.

Die Abnahme umfasst drei getrennte Prüfungen. Test connection prüft nur die Fusion-zu-IdP-Konfiguration. Eine echte Clientverbindung prüft den TTLS/PAP-Authentifizierungsaustausch und die Tenant-Richtlinie der Pilotidentität. Erst der anschliessende Benutzerverkehr prüft Adressierung, DHCP, DNS, VLANs, Gateway und Firewallregeln. Erfolg auf einer Ebene belegt keine spätere Ebene; über den Cloud-Pfad der Zugangsdaten wird keine undokumentierte Aussage getroffen.

IdP einer AP6-Pilot-SSID zuordnen

Zuerst inventarisiert man jede Enterprise-SSID auf dem vorgesehenen Pilot-AP einschliesslich ihrer Frequenzbänder und der gewählten RADIUS-Server beziehungsweise IdPs. AP6 unterstützt nur eine RADIUS-Konfiguration pro Frequenzband. Verwendet eine andere Enterprise-SSID auf einem überlappenden Band einen anderen Server oder IdP, kann das Speichern der neuen Zuweisung die bestehende Bandkonfiguration überschreiben; die neue primäre Auswahl kann danach beide SSIDs betreffen. Bevorzugt wird ein AP ohne kollidierende Enterprise-SSID.

Die Enterprise-SSID wird nach dem AP6-RADIUS- und WPA3-Enterprise-Ablauf erstellt oder bearbeitet, HQ-Entra-ID gewählt und zunächst genau einem konfliktfreien Pilot-AP zugewiesen. Für Windows oder Android wählt man WPA2/WPA3 Enterprise. RADIUS VLAN assignment, RADIUS Accounting und Captive-Portal-Backend bleiben deaktiviert. Vor Save werden für jede betroffene SSID bisherige IdP-/RADIUS-Auswahl, Bänder und AP-Zuweisungen dokumentiert. Vor Save stoppen, wenn sich ein Band mit einer anderen Auswahl überschneidet oder der Bestand unklar ist; anderen Pilot-AP wählen oder an Sophos Support eskalieren.

Validierung vor dem Rollout

Fusion zu IdP: Test connection muss erfolgreich sein.
Echte Clientauthentifizierung: Mit einer freigegebenen Entra-Pilotidentität und dem freigegebenen TTLS/PAP-Profil verbinden; Zertifikatskette und Serveridentität müssen ohne Bestätigungsdialog oder unbekanntes Zertifikat validiert werden.
Tenant-Richtlinienmatrix: Für jede vorgesehene Kombination aus MFA/Conditional Access, kennwortlos, Gast und föderiert eine echte Anmeldung durchführen. Unterstützte und abgelehnte Fälle dokumentieren. Unklare oder nicht unterstützte Fälle stoppen und eskalieren; ein Standardkonto belegt keine allgemeine Entra-Kompatibilität.
Negativtest: Prüfen, dass ein eigens deaktiviertes oder unbrauchbares Testkonto keinen WLAN-Zugang erhält. Produktionskonten nicht durch Wiederholungen sperren.
Benutzerverkehr: Vorgesehene IP-Konfiguration, DNS, VLAN-Pfad, Gateway und genau die freigegebenen Ziele prüfen. Assoziierung oder Authentifizierung allein reichen nicht.
Client- und Regressionstest: Jedes vorgesehene Betriebssystem, jeden Gerätetyp und Richtlinienfall getrennt testen, danach jede bestehende Enterprise-SSID am Pilot-AP erneut prüfen. APs erst nach dokumentiertem Erfolg in kleinen Wellen ergänzen.

Fehler gezielt eingrenzen

Test connection schlägt fehl: Client ID und Tenant ID gegen Overview, den Domainnamen gegen den Status Verified und das Secret gegen den unmittelbar kopierten Wert prüfen. Danach kontrollieren, ob beide Graph-Berechtigungen den richtigen Typ haben und als Granted erscheinen. Ein abgelaufenes oder verlorenes Secret wird durch ein neues ersetzt und anschliessend auch im Fusion-IdP aktualisiert.

Test connection ist erfolgreich, aber die WLAN-Anmeldung scheitert: Das grenzt die Fusion-Integration als wahrscheinliche Fehlerquelle ein, beweist aber keinen funktionierenden Client. EAP-Profil auf TTLS/PAP, Benutzerstatus und SSID-Verschlüsselung prüfen. Bei Windows und Android muss der Modus WPA2/WPA3 Enterprise sein.

Apple-Gerät fragt unerwartet nach Einstellungen oder Zertifikatsvertrauen: Prüfen, ob das vorgesehene WLAN-Konfigurationsprofil wirklich installiert und für die richtige SSID bestimmt ist. Nicht durch unkontrolliertes Bestätigen unbekannter Zertifikate umgehen; fehlende Profilwerte müssen über den zuständigen Apple-/MDM-Prozess geklärt werden.

Authentifizierung gelingt, aber DHCP, DNS oder Ziele funktionieren nicht: Der Fehler liegt hinter der Anmeldung im Datenpfad. Clientadresse, VLAN-/Switchpfad, DHCP, Gateway, DNS und Firewall-Regeln prüfen. Keine zusätzlichen Graph-Berechtigungen vergeben, um einen Netzwerkfehler zu beheben.

Sicher zurücknehmen und Berechtigungen überprüfen

Scheitert der Pilot, werden keine weiteren APs zugewiesen. Die neue Zuweisung entfernen und jede betroffene Enterprise-SSID mit dem dokumentierten Bestand vergleichen. Das Entfernen allein stellt die Konfiguration pro Band möglicherweise nicht automatisch wieder her. Bisherige IdP-/RADIUS-Auswahl, ursprüngliche Frequenzbänder und AP-Zuweisungen ausdrücklich wiederherstellen, speichern und bekannte Bestandsauthentifizierung samt Benutzerverkehr erneut testen. Ist der frühere Zustand oder Rückweg unklar, stoppen und an Sophos Support eskalieren, statt weitere Produktionsänderungen vorzunehmen.

Das IdP-Objekt auf der Fusion-RADIUS-Seite erst löschen, wenn sein SSID count beziehungsweise die Zuordnungen zeigen, dass keine SSID es mehr verwendet. Das Client Secret oder die Entra-App erst danach und abgestimmt mit dem App-Verantwortlichen widerrufen beziehungsweise entfernen; sonst werden verbleibende Zuordnungen ohne funktionierende Anmeldung zurückgelassen. Nach erfolgreichem Rückbau kontrolliert man, dass das Objekt nicht mehr auswählbar ist und der Bestandszugang weiterhin funktioniert.

Im Betrieb werden Secret-Ablaufdatum, App-Verantwortlicher, beide Graph-Berechtigungen und die noch zugeordneten SSIDs regelmässig geprüft. Nicht mehr benötigte zusätzliche Berechtigungen gehören entfernt; für diese Integration bleibt nur die von Sophos dokumentierte Kombination bestehen.