Active Directory mit Sophos Firewall verbinden

Active Directory ist in vielen Sophos-Firewall-Umgebungen weiterhin die zentrale Quelle für Benutzer, Gruppen und Authentifizierung. Die Firewall nutzt die AD-Anbindung zum Beispiel für Benutzerregeln, Remote Access VPN, Captive Portal, User Portal, Reporting oder Single Sign-On-Szenarien.

Der Artikel erklärt, wie man einen Active-Directory-Server auf Sophos Firewall hinzufügt, welche Felder wirklich wichtig sind und wie man die Verbindung danach prüft. Für neue Remote-Access-Designs sollte man zusätzlich entscheiden, ob klassisches AD, RADIUS oder Microsoft Entra ID SSO für Sophos Connect und VPN Portal besser passt.

Das folgende Sophos-Techvids-Video zeigt den Grundprozess als visuelle Ergänzung. Es wurde mit SFOS v21 erstellt, die Logik ist weiterhin hilfreich, einzelne Masken können in SFOS 22 aber leicht anders aussehen.

Der praktische Ablauf besteht aus vier Teilen. Ein erfolgreicher Verbindungstest ist nur der Anfang; VPN, Portal, Benutzerregeln und SSO müssen separat validiert werden.

1. Server hinzufügen: Domain Controller, NetBIOS-Domäne, Suchbasis und Servicekonto korrekt eintragen.
2. Verbindung schützen: LDAPS, Zertifikatsprüfung und interne DNS-Auflösung bewusst planen.
3. Gruppen importieren: Nur benötigte AD-Gruppen importieren und Main Group verstehen.
4. Nutzung testen: Login, MFA, VPN, User Portal, Captive Portal, SSO und Log Viewer prüfen.

Einordnung

Die Sophos Firewall kann mehrere Authentifizierungsquellen verwenden. Active Directory ist sinnvoll, wenn Benutzer und Gruppen bereits lokal in einer Windows-Domäne gepflegt werden und die Firewall diese Identitäten direkt verwenden soll.

Typische Anwendungsfälle:

• Benutzer- und Gruppenabgleich aus dem lokalen Active Directory
• Firewall-Regeln mit Benutzer- oder Gruppenbezug
• Remote Access VPN mit AD-Benutzern
• User Portal oder Captive Portal mit Domänenkonten
• Reporting nach Benutzer statt nur nach IP-Adresse
• Active Directory SSO mit NTLM oder Kerberos

AD-Anbindung bedeutet aber nicht automatisch, dass jede Authentifizierungsfrage gelöst ist. Man muss unterscheiden, ob die Firewall Benutzer nur per LDAP/LDAPS abfragt, ob Gruppen importiert werden, ob SSO genutzt wird oder ob Remote Access zusätzlich MFA braucht. Für MFA-Grundlagen passt MFA für Sophos Firewall WebAdmin, VPN Portal und Remote Access aktivieren.

Wichtige Entscheidungen vor der Einrichtung

Vor dem Hinzufügen des Servers sollten diese Punkte geklärt sein:

• Verbindung: Wenn möglich LDAPS mit SSL/TLS auf Port 636 verwenden.
• Servicekonto: Dediziertes AD-Konto mit Leserechten statt Domain Admin verwenden.
• Suchbasis: Nur benötigte OUs durchsuchen, nicht blind die ganze Domäne.
• Anzeigeattribut: sAMAccountName, userPrincipalName oder displayName bewusst wählen.
• Gruppen: Nur Gruppen importieren, die für Firewall, VPN oder Portal wirklich gebraucht werden.
• MFA: Remote Access und Portale zusätzlich mit MFA absichern.
• Serverreihenfolge: Bei mehreren AD-Servern die Abfragereihenfolge bewusst festlegen.
• Betrieb: Auth-Logs, Gruppenimport, Zertifikate und Passwortablauf regelmässig prüfen.

⚠️ Die Verbindung zwischen Firewall und Authentifizierungsserver sollte verschlüsselt sein. Unverschlüsseltes LDAP auf Port 389 kann in Labors funktionieren, ist für produktive Umgebungen aber keine gute Dauerlösung.

Für AD-Integration werden auch ältere Windows-Server-Versionen unterstützt, in aktuellen Umgebungen sind aber vor allem Windows Server 2016, 2019, 2022 und 2025 relevant. Seit SFOS 21.5 MR1 ist Active Directory SSO mit Windows Server 2025 für NTLM und Kerberos möglich. SFOS 22 enthält aktualisierte Samba-Komponenten für Kerberos- und NTLM-Authentifizierung und entfernt ältere Verschlüsselungsverfahren. Gerade nach Firewall- oder Domain-Controller-Upgrades sollte man AD SSO, Gruppenimport und Remote Access deshalb gezielt testen.

Wichtig: Strikte Erzwingung von LDAP Channel Binding und LDAP Signing wird von Sophos Firewall aktuell nicht unterstützt. Wenn Domain Controller sehr harte LDAP-Sicherheitsvorgaben erzwingen, sollte man die AD-Anbindung deshalb vor einer produktiven Umstellung in einem Wartungsfenster testen.

Active Directory Server hinzufügen

Die Konfiguration erfolgt im WebAdmin der Sophos Firewall:

Authentication > Servers

Dort wird mit Add ein neuer Authentifizierungsserver erstellt und als Server Type Active Directory ausgewählt.

Felder der Active-Directory-Konfiguration

Die Nummerierung im Screenshot ist bewusst so gewählt: Die wichtigsten Felder werden von oben nach unten erklärt. Je nach SFOS-Version kann die Reihenfolge leicht anders aussehen. In neueren Versionen sieht man zusätzlich Validate server certificate, wenn die Zertifikatsprüfung für LDAPS aktiviert werden soll.

1. Server type: Für eine klassische Windows-Domäne wird Active Directory verwendet. Andere Servertypen wie RADIUS, LDAP oder Microsoft Entra ID sind andere Integrationsarten und sollten nicht vermischt werden.
2. Server name: Interner Anzeigename auf der Firewall. Der Name hat keinen Einfluss auf DNS oder AD, sollte aber eindeutig sein, zum Beispiel AD-ZH-DC01 oder AD-HQ-LDAPS. Bei mehreren Domain Controllern hilft ein sauberer Name später im Log Viewer und beim Troubleshooting.
3. Server IP/domain: IP-Adresse oder DNS-Name des Domain Controllers. Ein DNS-Name ist sauberer, wenn Zertifikat, interne DNS-Auflösung und Failover dazu passen. Eine IP-Adresse ist einfacher zu debuggen, bindet die Firewall aber direkt an einen bestimmten Domain Controller.
4. Port: Port für die LDAP-Verbindung. Für produktive Umgebungen ist 636 mit SSL/TLS die bevorzugte Variante. 389 wird für unverschlüsseltes LDAP oder STARTTLS verwendet, sollte aber nicht die Dauerlösung sein, wenn Benutzerauthentifizierung produktiv genutzt wird.
5. NetBIOS domain: Kurzer NetBIOS-Name der AD-Domäne, zum Beispiel AVANET. Dieser Wert ist nicht der DNS-Domänenname. Falsche NetBIOS-Werte führen häufig dazu, dass Benutzer zwar existieren, aber nicht sauber gefunden oder zugeordnet werden.
6. ADS user name: Benutzername des Servicekontos, mit dem die Firewall AD-Abfragen ausführt. Dafür sollte ein dediziertes Konto mit Leserechten verwendet werden, kein Domain-Admin. Je nach Umgebung funktioniert der kurze Logon-Name, DOMAIN\user oder ein UPN wie svc-firewall-ldap@example.local.
7. Password: Kennwort des Servicekontos. Wenn dieses Kennwort abläuft oder geändert wird, funktionieren Benutzerabfragen, Gruppenimport, VPN-Logins oder Portal-Logins plötzlich nicht mehr. Darum sollte das Konto dokumentiert und überwacht werden.
8. Connection security: Legt fest, ob und wie die Verbindung geschützt wird. Für LDAPS wird SSL/TLS mit Port 636 verwendet. STARTTLS nutzt normalerweise Port 389, setzt aber voraus, dass der Domain Controller STARTTLS sauber anbietet. Simple ist unverschlüsselt und sollte höchstens für Tests verwendet werden.
9. Display name attribute: AD-Attribut, das die Firewall als Anzeigenamen verwendet. Häufige Werte sind sAMAccountName, userPrincipalName, displayName oder name. Für Betrieb und Troubleshooting ist ein eindeutiges Attribut wichtiger als ein schön lesbarer Name.
10. Email address attribute: Attribut für die E-Mail-Adresse. Meistens ist das mail. Das Feld ist nur hilfreich, wenn E-Mail-Adressen im AD wirklich gepflegt sind. Sonst entstehen leere oder uneinheitliche Benutzerinformationen.
11. Domain name: DNS-Name der AD-Domäne, zum Beispiel example.local oder ad.example.com. Dieser Wert ist nicht der NetBIOS-Name. Er muss zur Domäne, zur Suchbasis und zum verwendeten Domain Controller passen.
12. Search queries: Suchbasis für Benutzer- und Gruppenabfragen. Hier trägt man Distinguished Names wie DC=example,DC=local oder gezielter OU=Users,OU=Company,DC=example,DC=local ein. Je enger die Suchbasis gewählt wird, desto übersichtlicher und performanter bleibt der Import.

Wenn mehrere Domain Controller vorhanden sind, sollte man bewusst entscheiden, ob die Firewall einen bestimmten DC anspricht oder ob ein stabiler interner DNS-Name auf eine geeignete AD-Infrastruktur zeigt. Wichtig ist, dass DNS-Auflösung, Zertifikat, Routing und Firewall-Regeln zusammenpassen.

Validate server certificate

In aktuellen SFOS-Versionen kann zusätzlich Validate server certificate aktiviert werden. Das ist für LDAPS sinnvoll, weil die Firewall dann nicht nur verschlüsselt verbindet, sondern auch prüft, ob sie dem Zertifikat des Domain Controllers vertraut.

Dafür müssen diese Punkte stimmen:

1. Die ausstellende CA des Domain-Controller-Zertifikats ist auf der Firewall unter Certificates > Certificates bekannt.
2. Der Wert in Server IP/domain passt zum Zertifikatsnamen oder zu einem Subject Alternative Name des Zertifikats.
3. Falls ein CNAME verwendet wird, kann die Firewall diesen Namen intern auflösen.
4. Datum und Uhrzeit auf Firewall und Domain Controller stimmen.

Wenn die interne DNS-Auflösung einen CNAME oder den Domain-Controller-Namen nicht sauber auflöst, kann ein DNS Host Entry unter Network > DNS > DNS host entry helfen.

NetBIOS-Domäne und Domänenname

Die Sophos Firewall benötigt sowohl Angaben zur NetBIOS-Domäne als auch zum Domänennamen. Diese Werte sollten exakt zur AD-Domäne passen.

Die NetBIOS-Domäne findet man zum Beispiel in Active Directory Users and Computers über die Eigenschaften der Domäne.

Der Domänenname ist der DNS-Name der Domäne, zum Beispiel example.local oder ad.example.com.

Typische Fehler an dieser Stelle:

• NetBIOS-Name und DNS-Domänenname werden verwechselt.
• Der eingetragene Domain Controller gehört zu einer anderen Domäne.
• Die Firewall kann den DNS-Namen des Domain Controllers nicht auflösen.
• Zwischen Firewall und Domain Controller blockiert eine Netzwerk- oder Windows-Firewall die Verbindung.

Servicekonto und Kennwort

Für den Zugriff auf Active Directory sollte ein dediziertes Servicekonto verwendet werden. Ein Domain-Admin-Konto ist für die normale LDAP-Abfrage nicht nötig und erhöht das Risiko unnötig.

Sinnvolle Vorgaben:

• eigenes Konto für die Firewall, zum Beispiel svc-sophos-fw-ldap
• nur benötigte Leserechte
• dokumentierter Owner für Passwortwechsel
• langes, eindeutiges Passwort
• keine interaktive Anmeldung, wenn die AD-Richtlinien das sauber abbilden
• Monitoring oder Erinnerung vor Passwortablauf

Wenn das Kennwort des Servicekontos abläuft oder geändert wird, kann die Firewall keine Benutzer und Gruppen mehr abfragen. Das zeigt sich später oft als VPN-, Portal- oder Benutzerregelproblem, obwohl die eigentliche Ursache in der AD-Anbindung liegt.

Verbindungssicherheit und LDAPS

Für produktive Umgebungen sollte man LDAPS bevorzugen. Dafür braucht der Domain Controller ein passendes Zertifikat, und die Firewall muss der ausstellenden CA vertrauen.

Prüfen sollte man:

• Port 636 ist vom Firewall-Interface zum Domain Controller erreichbar.
• Zertifikat des Domain Controllers ist gültig.
• Zertifikatname passt zum verwendeten DNS-Namen.
• Ausstellende CA ist auf der Firewall bekannt, falls eine Prüfung erforderlich ist.
• Zeit und Datum auf Firewall und Domain Controller stimmen.

Bei Zertifikatsthemen ist auch die CA-Verteilung relevant. Für die Verteilung der Sophos-Firewall-CA an Clients passt Sophos Firewall CA-Zertifikat für HTTPS Scanning verteilen. Für LDAPS ist dagegen primär die CA des Domain Controllers beziehungsweise der internen PKI entscheidend.

Anzeigeattribut und E-Mail-Attribut

Das Anzeigeattribut bestimmt, wie Benutzer in der Sophos Firewall dargestellt werden. Typische Werte sind:

• sAMAccountName
• userPrincipalName
• displayName
• name

sAMAccountName ist in klassischen AD-Umgebungen oft robust und kurz. userPrincipalName ist näher an modernen Login-Namen und Cloud-Identitäten. displayName ist für Menschen gut lesbar, aber nicht immer eindeutig genug für Betrieb und Troubleshooting.

Die Attribute kann man in Active Directory Users and Computers prüfen, wenn Advanced Features aktiviert ist.

Das E-Mail-Attribut ist meistens mail. Es ist vor allem relevant, wenn die Firewall Benutzern E-Mail-bezogene Informationen zuordnen soll.

Suchbasis und Gruppen

Die Suchbasis legt fest, welchen Teil des Active Directory die Firewall durchsucht. Für eine ganze Domäne wäre ein Beispiel:

DC=example,DC=local

Für eine einzelne OU kann der Pfad zum Beispiel so aussehen:

OU=Users,OU=Company,DC=example,DC=local

Den Distinguished Name einer OU findet man in Active Directory Users and Computers in den Attributen der OU.

Eine zu breite Suchbasis funktioniert zwar oft, macht die Konfiguration aber unübersichtlicher. Für produktive Umgebungen ist besser:

• dedizierte OU oder klare Suchbasis für relevante Benutzer
• separate AD-Gruppen für VPN, Portale oder Firewall-Regeln
• keine zufällige Wiederverwendung grosser Abteilungsgruppen
• Gruppenimport nach Änderungen testen
• alte oder leere Gruppen regelmässig entfernen

Zu breite Gruppenimporte können langfristig auch die interne Benutzerverwaltung der Firewall belasten. Wenn sehr viele alte Benutzer oder Gruppen entstehen und VPN-Portal-Downloads später unerwartet fehlschlagen, hilft die Prüfung des Sophos Firewall User-ID-Limits.

Wichtig bei Remote Access: Sophos hat in SFOS 21.5 MR1 geändert, dass L2TP und PPTP beim Import von Gruppen aus Active Directory und Microsoft Entra ID nicht mehr automatisch aktiviert werden. Das reduziert ungewollte Angriffsfläche, sollte aber nach Upgrades geprüft werden, wenn alte Remote-Access-Prozesse darauf vertraut haben.

Gruppen importieren und Benutzer verstehen

Nach dem Hinzufügen des AD-Servers sind AD-Gruppen nicht automatisch vollständig in der Firewall vorhanden. Gruppen werden über den Import-Assistenten importiert:

Authentication > Servers > Import

Der Ablauf ist:

1. AD-Server auswählen und Import starten.
2. Base DN für die Gruppensuche auswählen.
3. Benötigte AD-Gruppen auswählen.
4. Gemeinsame Gruppen-Policies prüfen.
5. Auswahl kontrollieren und Import abschliessen.
6. Unter Authentication > Groups prüfen, ob die Gruppen sauber vorhanden sind.

Benutzer erscheinen unter Authentication > Users erst, wenn sie sich an einem Dienst anmelden, zum Beispiel am User Portal, VPN Portal, Captive Portal oder per Remote Access VPN. Bei jeder Anmeldung prüft die Firewall erneut, welche importierten Gruppen zum Benutzer passen, und aktualisiert die Zuordnung.

Wenn ein Benutzer in keiner importierten AD-Gruppe gefunden wird, landet er in der Default Group. Diese Default Group sieht man unter Authentication > Services bei den Firewall Authentication Methods. Standardmässig ist das häufig die Open group.

In HA-Umgebungen importiert man AD-Gruppen auf dem Primary-Gerät. Das gilt auch für das Bereinigen alter AD-Benutzer mit Purge AD users.

Main Group, Gruppenreihenfolge und verschachtelte Gruppen

Ein AD-Benutzer kann in mehreren Gruppen sein. Die Sophos Firewall unterscheidet dabei zwischen:

• Group: Die erste passende Gruppe in der Firewall-Gruppenliste. Das ist die Main Group des Benutzers.
• Other group memberships: Weitere importierte Gruppen, in denen der Benutzer ebenfalls Mitglied ist.
• Group order: Reihenfolge unter Authentication > Groups. Dieser Wert entscheidet, welche Gruppe bei mehreren Treffern zur Main Group wird.

Das ist wichtig, weil nicht alle Funktionen Mehrfachgruppen auswerten. Einige Funktionen nutzen nur die Main Group. Wenn ein Benutzer in mehreren AD-Gruppen ist, kann deshalb eine andere Policy greifen als erwartet.

Die Gruppenreihenfolge ändert man hier:

Authentication > Groups > Reorder

Verschachtelte AD-Gruppen werden nicht unterstützt. Wenn eine Firewall-Policy für eine Untergruppe gelten soll, muss diese Untergruppe selbst importiert werden. Es reicht nicht, nur die übergeordnete AD-Gruppe zu importieren.

Die primäre AD-Gruppe eines Benutzers wird ebenfalls nicht wie eine normale Gruppenmitgliedschaft übernommen. Das betrifft besonders die AD-Standardgruppe Domain Users. Für Firewall-Policies sollte man deshalb explizite Sicherheitsgruppen verwenden und Benutzer direkt in diese Gruppen aufnehmen.

Welche Funktionen Mehrfachgruppen unterstützen

Für den Betrieb ist diese Unterscheidung besonders wichtig.

Mehrere AD-Gruppen können berücksichtigt werden bei:

• Firewall rules: Entscheidend bleibt die Reihenfolge der Firewall-Regeln.
• SSL/TLS inspection rules: Die erste passende Inspection-Regel greift.
• Web policies: Erst trifft die Firewall-Regel, danach die passende Web-Policy-Regel.
• IPS policies: Die Policy aus der passenden Regel wird angewendet.
• Application control policies: Die Auswertung erfolgt über die passende Firewall-Regel.
• SD-WAN routes: Benutzer- oder Gruppenkriterien können mehrere Gruppen berücksichtigen.
• Policy test: Hilfreich, um Gruppen- und Policy-Matching zu prüfen.
• Remote access SSL VPN: Berechtigungen aus passenden Full- und Split-Tunnel-Policies werden berücksichtigt. Bei Full Tunnel hat Full Tunnel Vorrang.
• Clientless SSL VPN: Berechtigungen aus passenden Gruppen werden kombiniert.

Nur Main Group oder explizite Benutzer werden berücksichtigt bei:

• WAF rules
• Remote access IPsec VPN
• L2TP und PPTP
• Hotspots
• MFA, wenn MFA gezielt auf Gruppen angewendet wird
• Surfing quota, Access time, Network traffic und Traffic shaping
• Quarantine digest, MAC binding und Sign-in restriction

Praxisbeispiel: Ein Benutzer ist in VPN-Users und Firewall-Admins. Für SSL VPN kann die Mehrfachmitgliedschaft funktionieren. Für IPsec Remote Access oder MFA-Gruppenzuordnung kann aber nur die Main Group zählen. Darum sollte man bei Remote Access und administrativen Zugängen bewusst testen, welche Gruppe im Benutzerobjekt als Group gesetzt ist.

Mehrere Active-Directory-Server

Man kann mehrere AD-Server konfigurieren. Die Firewall validiert Benutzer dann in der Reihenfolge, die im WebAdmin konfiguriert ist. Das ist kein Ersatz für ein sauber geplantes AD-Design.

Empfehlungen:

• Serverreihenfolge unter Authentication > Services bewusst setzen.
• Pro Server Suchbasis und Domäne sauber dokumentieren.
• Keine widersprüchlichen Gruppen mit gleichem Namen in unterschiedlichen Quellen verwenden.
• Bei mehreren UPNs oder mehreren Domänen separate DNS- und AD-Konfigurationen sauber planen.
• Failover nicht nur mit Test connection, sondern mit einem echten Benutzerlogin prüfen.
• Bei Ausfall eines AD-Servers kann die Fehlermeldung für den Benutzer wie ein falsches Passwort wirken.

Wenn mehrere UPNs zur gleichen Domain-Infrastruktur gehören, müssen DNS-Einträge und AD-Serverkonfiguration zur jeweiligen Domain passen. Wichtig ist, dass Suchbasis, Domain Name und Serverauflösung zusammengehören.

Verbindung testen

Nach dem Speichern sollte die Verbindung direkt getestet werden. Der Test prüft, ob die Firewall den Server erreicht und ob die eingegebenen Daten grundsätzlich passen.

Ein erfolgreicher Test bedeutet nicht automatisch, dass Benutzerregeln, SSO oder VPN bereits funktionieren. Danach sollten mindestens diese Punkte geprüft werden:

1. AD-Benutzer oder Gruppen werden korrekt gefunden.
2. Testbenutzer kann sich an der vorgesehenen Stelle anmelden.
3. Gruppenmitgliedschaft passt zur gewünschten Firewall- oder VPN-Berechtigung.
4. Log Viewer zeigt nachvollziehbare Authentifizierungsereignisse.
5. Remote Access VPN, User Portal oder Captive Portal funktionieren mit einem normalen Testbenutzer.
6. MFA wird abgefragt, wenn sie für den Anwendungsfall geplant ist.
7. Der AD-Server ist unter Authentication > Services an der gewünschten Stelle der Firewall Authentication Methods eingetragen.

Für Remote Access mit Sophos Connect ist Sophos Connect Client auf Sophos Firewall konfigurieren der nächste passende Schritt.

Validierung nach Anwendungsfall

Nach der AD-Anbindung sollte nicht nur ein einzelner Verbindungstest dokumentiert werden. Unterschiedliche Funktionen nutzen die AD-Integration auf unterschiedliche Weise. Darum sollte man für jeden geplanten Anwendungsfall einen eigenen Test durchführen.

• Gruppenimport: Relevante AD-Gruppe suchen und auf der Firewall importieren. Wenn etwas nicht passt, wird die Gruppe nicht gefunden oder enthält unerwartete Benutzer.
• User Portal: Anmeldung mit normalem AD-Benutzer testen. Ein typisches Fehlersymptom ist ein fehlgeschlagener Login, obwohl der Server-Test erfolgreich war.
• Remote Access VPN: VPN-Login, Gruppenberechtigung, MFA und Zugriff auf interne Ziele prüfen. Bei Fehlern authentifiziert sich der Benutzer vielleicht, erhält aber keine passende Policy oder keinen Zugriff.
• Benutzerbasierte Firewall-Regel: Testtraffic erzeugen und Log Viewer auf Benutzer, Gruppe und Rule ID prüfen. Wenn die Zuordnung nicht funktioniert, erscheint Traffic nur mit IP-Adresse oder trifft eine andere Regel.
• Captive Portal: Browser-Login und anschliessenden Traffic testen. Fehler zeigen sich oft so, dass der Login funktioniert, der Benutzer danach aber nicht korrekt zugeordnet wird.
• AD SSO oder STAS: Live Users und Log Viewer nach Windows-Anmeldung prüfen. Bei Problemen bleibt der Benutzer unbekannt oder wird einer falschen IP zugeordnet.

Diese Trennung spart im Betrieb Zeit. Ein erfolgreicher LDAP-Test beweist nur, dass Server, Port, Bind-Konto und Suchbasis grundsätzlich erreichbar sind. Er beweist nicht, dass VPN-Gruppen korrekt zugeordnet sind, dass MFA greift oder dass Benutzertraffic in Firewall-Regeln mit Identität bewertet wird.

Für benutzerbasierte Regeln sollte man immer einen echten Traffic-Test auslösen und im Log Viewer prüfen, ob Benutzername, Gruppe, Firewall Rule ID und Aktion zur Erwartung passen. Wenn nur die IP-Adresse sichtbar ist, liegt die Ursache oft bei SSO, STAS, Captive Portal oder bei der Reihenfolge der Firewall-Regeln. Für STAS-Umgebungen passt STAS auf Sophos Firewall einrichten als Anschlussartikel.

Active Directory SSO beachten

Active Directory SSO ist ein eigener Betriebsbereich. Die reine AD-Serververbindung ist dafür eine Grundlage, aber SSO braucht zusätzlich passende Client-, Browser-, DNS-, Kerberos- oder NTLM-Bedingungen.

Für Web Authentication unterstützt Sophos Firewall klassisches AD SSO mit Kerberos und NTLM. Kerberos ist sauberer und schneller, stellt aber höhere Anforderungen an FQDN, DNS, SPN und Browser-Vertrauen. NTLM ist toleranter und in alten Umgebungen manchmal der pragmatische Fallback, sollte aber nicht unbemerkt die einzige funktionierende Methode sein.

Der Ablauf für AD SSO ist deshalb mehr als nur Test connection beim AD-Server:

1. Unter Administration > Admin and user settings einen Hostname oder FQDN setzen. Für Kerberos sollte es ein FQDN sein, klein geschrieben und mit einem Host-Teil von maximal 15 Zeichen, damit NetBIOS-Name, AD-Computerobjekt und SPN nicht auseinanderlaufen.
2. Unter Administration > Admin and user settings die Redirection Location so setzen, dass Clients den Namen auflösen und dem Ziel vertrauen. In transparenten Kerberos-Szenarien muss dieser Name zum SPN passen. Auf einem Windows-Client hilft setspn -Q HTTP/*, um vorhandene HTTP-SPNs zu prüfen.
3. Unter Authentication > Servers den AD-Server speichern und Test connection ausführen. Dieser Test prüft Verbindung und Zugangsdaten, aber noch nicht, ob AD SSO funktioniert.
4. Unter Authentication > Services den AD-Server in den Firewall authentication methods an die gewünschte Position setzen. AD SSO verwendet die Server in dieser Reihenfolge und fällt erst auf den nächsten Server zurück, wenn der vorherige nicht erreichbar ist.
5. Unter Administration > Device access für die benötigten Zonen AD SSO aktivieren. Meist ist das LAN oder ein klar definiertes internes Clientnetz, nicht pauschal jede Zone.
6. Unter Authentication > Web authentication bei If Active Directory (AD) SSO is configured die Methode Kerberos & NTLM oder bewusst NTLM only wählen.
7. In den passenden Firewallregeln prüfen, ob Match known users und bei unbekannten Web-Requests Use web authentication for unknown users zum gewünschten Ablauf passen. Für HTTP und HTTPS ist oft eine eigene, klar benannte Regel übersichtlicher.

Wenn Use web authentication for unknown users HTTPS-Traffic in transparentem Modus authentifizieren soll, kann die Firewall die Verbindung für den Authentifizierungsvorgang entschlüsseln. Das muss zum TLS-Inspection- und Zertifikatsdesign passen; sonst wirkt AD SSO schnell wie ein Browser-, Zertifikats- oder Webfilterproblem.

Für die Validierung ist der Log Viewer entscheidend. Unter Log viewer > Authentication sollte man beim Start der AD-SSO-Verbindung Meldungen wie Kerberos authentication initialized successfully und NTLM authentication channel established successfully sehen. Problematisch sind Meldungen wie Cannot initialize Kerberos authentication oder Cannot establish NTLM authentication channel. In der Spalte Log Comp erkennt man ausserdem, ob ein Client Kerberos oder NTLM verwendet.

Wichtig ist die Kontenfrage: Für normale LDAP-Abfragen reicht ein Domain-User mit Leserechten oft aus. Für AD SSO muss die Firewall aber der Domäne beitreten und ein Computerobjekt beziehungsweise SPN anlegen können. Dafür braucht man entweder ein Domain-Admin-Konto oder ein Konto mit sauber delegierten Domain-Join-Rechten. In HA-Umgebungen, bei mehreren AD-Servern oder nach Upgrades kann die Firewall erneut beitreten müssen. Darum sollte man nicht einmalig mit Domain Admin joinen und danach auf ein schwächeres Konto wechseln, wenn dieses Konto den Rejoin später nicht darf.

Seit SFOS 21.5 MR1 ist Windows Server 2025 bei Active Directory SSO mit NTLM und Kerberos unterstützt. SFOS 22 bringt zudem aktualisierte Samba-Komponenten und entfernt ältere Verschlüsselungsverfahren. Für Admins heisst das:

• Nach Domain-Controller-Upgrades AD SSO gezielt testen.
• Nach SFOS-Upgrades Authentifizierung und Benutzerzuordnung prüfen.
• Kerberos-/NTLM-Abhängigkeiten in alten Umgebungen dokumentieren.
• Veraltete Verschlüsselung nicht als Dauerlösung einplanen.
• DNS Request Routes für AD-Domänen prüfen, wenn die Firewall AD-Service-Records nicht über den normalen Resolver findet.
• SSO nicht mit Entra ID SSO für Sophos Connect verwechseln.

Wenn Entra ID SSO für VPN oder VPN Portal geplant ist, sollte man den separaten Artikel Microsoft Entra ID SSO für Sophos Connect und VPN Portal einrichten verwenden. Das ist ein anderes Authentifizierungsmodell als klassische lokale AD-Anbindung.

Troubleshooting

Verbindungstest schlägt fehl

Zuerst Erreichbarkeit, Port, Routing und DNS prüfen. Danach Verbindungssicherheit, Zertifikat, Servicekonto und Kennwort kontrollieren.

Praktische Checks:

• Kann die Firewall den Domain Controller per IP erreichen?
• Wird der DNS-Name korrekt aufgelöst?
• Ist Port 389 oder 636 erreichbar?
• Passt SSL/TLS wirklich zum Port und Zertifikat?
• Ist das Servicekonto aktiv und nicht gesperrt?
• Gibt es auf Windows-Seite Firewall-Regeln oder LDAP-Signing-Vorgaben?

Benutzer wird nicht gefunden

Dann ist häufig die Suchbasis falsch oder zu eng. Den distinguishedName der OU prüfen und sicherstellen, dass der Benutzer wirklich innerhalb der Suchbasis liegt. Auch Schreibweise, Umlaute, Sonderzeichen und das gewählte Anzeigeattribut können die Suche erschweren.

Gruppe wird importiert, aber Zugriff funktioniert nicht

Dann sollte man die Berechtigungskette prüfen: AD-Gruppe, importierte Firewall-Gruppe, zugewiesene VPN-/Portal-/Firewall-Regel, MFA und Regelposition. Bei Remote Access muss zusätzlich die passende VPN-Konfiguration mit der Gruppe verknüpft sein.

Wenn der Benutzer in mehreren AD-Gruppen ist, zusätzlich die Main Group unter Authentication > Users prüfen. Besonders MFA, Remote access IPsec VPN, WAF, Hotspots und mehrere benutzerbezogene Einstellungen berücksichtigen nur die Main Group.

Neue AD-Gruppe erscheint nicht automatisch

Neu erstellte AD-Gruppen werden nicht automatisch in die Firewall synchronisiert. Die Gruppe muss erneut über den Import-Assistenten importiert oder manuell als passende Gruppe angelegt werden. Danach sollte sich ein Testbenutzer neu anmelden, damit die Firewall die Gruppenmitgliedschaften erneut bewertet.

Benutzer wurde im AD gelöscht, bleibt aber auf der Firewall sichtbar

AD-Benutzer, die sich bereits angemeldet haben, können auf der Firewall sichtbar bleiben. Wenn Benutzer im AD gelöscht wurden, sollte man sie zuerst im AD entfernen und danach auf der Firewall Purge AD users verwenden. In HA-Umgebungen macht man das auf dem Primary-Gerät.

Anmeldung funktioniert, aber Benutzerregel greift nicht

Dann ist meistens nicht LDAP selbst das Problem, sondern Benutzerzuordnung, SSO, Regelposition oder Logging. Im Log Viewer sollte sichtbar sein, ob der Traffic mit Benutzeridentität oder nur mit IP-Adresse bewertet wird. Für die Regelanalyse passt Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture.

AD SSO fällt auf Captive Portal oder NTLM zurück

Wenn AD SSO nicht transparent funktioniert, sind meist Redirection URL, SPN, DNS-Auflösung oder Browser-Vertrauen beteiligt. Für Kerberos muss der Name, zu dem die Firewall umleitet, zum passenden HTTP-SPN gehören und vom Client auflösbar sein. Für NTLM muss der Browser den Zielnamen als vertrauenswürdig behandeln, sonst fragt er nach Zugangsdaten oder landet im Captive Portal.

Praktisch prüft man zuerst Administration > Admin and user settings, die DNS-Auflösung des Redirect-Namens, setspn -Q HTTP/* auf einem Windows-Client und Log viewer > Authentication. Wenn nur NTLM statt Kerberos erscheint, ist das oft ein Hinweis auf ein SPN- oder Browser-Trust-Problem, nicht zwingend auf eine defekte AD-Serververbindung.

Nach einem Upgrade funktionieren einzelne Logins nicht mehr

Nach SFOS- oder Domain-Controller-Upgrades sollte man besonders auf SSO, Kerberos/NTLM, alte Verschlüsselungsverfahren, Zertifikate und Gruppenimport achten. Wenn nur bestimmte Benutzer betroffen sind, zusätzlich Sonderzeichen, Leerzeichen, UPN, Gruppenmitgliedschaften und Passwortstatus prüfen.

Für Authentifizierungs- und Service-Logs hilft Sophos Firewall Troubleshooting: Services und Logs.

Verbindung funktioniert nicht bei aktivierter Zertifikatsprüfung

Wenn Validate server certificate aktiviert ist, müssen Zertifikat, CNAME, DNS-Auflösung und CA-Vertrauen zusammenpassen. Häufige Ursachen sind ein Zertifikat mit anderem Namen, eine fehlende interne CA auf der Firewall oder ein CNAME, den die Firewall nicht auflösen kann.

Betriebscheckliste

Vor der Einrichtung:

• Domain Controller, Port und DNS-Name festgelegt.
• LDAPS und Zertifikatskette geprüft.
• Dediziertes Servicekonto erstellt.
• Suchbasis und relevante Gruppen definiert.
• MFA- und Remote-Access-Design geklärt.

Nach der Einrichtung:

• Verbindungstest erfolgreich.
• AD-Server als primäre oder passende Authentication Method eingetragen.
• Testbenutzer und Testgruppe geprüft.
• AD-Gruppen über den Import-Assistenten importiert.
• Main Group eines Testbenutzers kontrolliert.
• Remote Access, Portal oder Benutzerregel mit normalem Benutzer getestet.
• Log Viewer zeigt erwartete Authentifizierungsereignisse.
• Bei AD SSO sind Kerberos-/NTLM-Meldungen im Authentication Log geprüft.
• Passwortablauf des Servicekontos dokumentiert.
• Upgrade-Test für AD SSO, Gruppenimport und VPN-Prozesse eingeplant.

Im Betrieb:

• Nicht mehr benötigte Gruppen entfernen.
• Neue AD-Gruppen aktiv importieren, nicht auf automatische Synchronisierung warten.
• Servicekonto regelmässig prüfen.
• LDAPS-Zertifikate vor Ablauf erneuern.
• Gruppenreihenfolge nach AD-Änderungen kontrollieren.
• Named Admins und MFA für administrative Zugriffe verwenden.
• Authentifizierungsfehler nicht nur als Benutzerproblem behandeln, sondern AD, Netzwerk, Zertifikate und Firewall-Regeln mitprüfen.

FAQ