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.

Wenn Active Directory das Ziel einer bestehenden eDirectory-Umgebung wird, sollte man zuerst den kontrollierten eDirectory-Migrationsablauf mit Gruppenprüfung, schrittweisem Cutover und dokumentiertem Rückweg planen.

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.

Zusätzlich müssen Routing und Quellpfad von der Firewall zum Domain Controller feststehen. Für LDAPS braucht man TCP 636, für STARTTLS TCP 389; interne DNS-Auflösung und eine vollständige, gültige Zertifikatskette müssen vom tatsächlich verwendeten Firewall-Pfad funktionieren. Vor der Änderung wird unter Backup and firmware > Backup and restore ein verschlüsseltes Konfigurationsbackup erstellt, heruntergeladen und das Backup-Passwort sicher abgelegt.

⚠️ 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 Kontos für AD-Abfragen. Sophos verwendet im Beispiel den Kurznamen administrator. Für den produktiven Betrieb empfiehlt Avanet stattdessen ein dediziertes Servicekonto mit Rechten zum Suchen, Lesen und Abfragen der Gruppenmitgliedschaft, kein Domain-Admin-Konto. Sophos bestätigt nicht pauschal, dass Kurzname, DOMAIN\user und UPN in jeder Konstellation gleichwertig sind. Deshalb sollte das in der eigenen AD-Umgebung getestete Format verwendet und dokumentiert werden.
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 für den auf der Firewall angezeigten Namen. Der Wert muss zum eigenen Verzeichnisschema passen und mit einem Testbenutzer geprüft werden; die allgemeine Sophos-Anleitung erklärt hier keine pauschal austauschbaren Standardwerte. Für Microsoft Entra Domain Services nennt Sophos ausdrücklich DisplayName.
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 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=ad,DC=example,DC=com oder gezielter OU=Users,OU=Company,DC=ad,DC=example,DC=com ein. Eine gezielte OU begrenzt den sichtbaren Benutzerkreis und hält den Import übersichtlich.

Nur Benutzer, die von mindestens einer Search query erfasst werden, können über diesen AD-Server unter Current activities > Live users erscheinen. Fehlt ein erwarteter Benutzer trotz erfolgreichem Test connection, wird zuerst geprüft, ob Base DN und OU-Scope sein tatsächliches Verzeichnisobjekt einschliessen. Die Suchbasis wird nicht vorsorglich auf die ganze Domäne erweitert.

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. Das Serverzertifikat des Domain Controllers wird unter Certificates > Certificates > Add > Upload certificate hochgeladen. Ein reiner CA-Import gehört dagegen unter Certificates > Certificate authorities; diese beiden Listen dürfen nicht verwechselt werden.
2. Unter Server IP/domain wird gemäss Sophos-Anleitung der CNAME eingetragen; dieser DNS-Name muss im Subject Alternative Name des Serverzertifikats enthalten sein.
3. Die Firewall kann den verwendeten CNAME 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 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 Serverzertifikat. Wenn Validate server certificate aktiv ist, folgt man dem oben beschriebenen Sophos-Import für das Serverzertifikat; ein zusätzlich erforderliches CA-Zertifikat wird separat als Certificate Authority importiert.

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.
• Serverzertifikat und gegebenenfalls die ausstellende CA sind in der jeweils richtigen Zertifikatsliste importiert.
• Zeit und Datum auf Firewall und Domain Controller stimmen.

Eine wichtige Produktgrenze bleibt: SFOS 22 unterstützt derzeit keine strikte Erzwingung von LDAP Channel Binding und LDAP Signing. LDAPS mit Zertifikatsprüfung schützt die Verbindung, ersetzt aber keinen Nachweis, dass eine AD-Sicherheitsrichtlinie mit zwingendem Channel Binding oder Signing erfüllt ist. Verlangt die Organisation diese Erzwingung, wird die Integration vor dem Rollout gegen die konkrete AD-Richtlinie geprüft und nicht allein aufgrund eines erfolgreichen Test connection freigegeben.

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.

Microsoft Entra Domain Services anbinden

Eine verwaltete Domäne aus Microsoft Entra Domain Services kann wie ein Active-Directory-Server angebunden werden. Sophos nennt dafür WebAdmin, Captive Portal, User Portal, Client Authentication Agent und Remote Access SSL VPN. Das ist keine direkte Entra-ID-SSO-Anbindung. Sophos nennt das VPN Portal in diesem Zusammenhang nicht als unterstützten Anwendungsfall.

Für den produktiven Betrieb wird Secure LDAP aktiviert und Port 636 vom gewählten Firewall-Pfad zur verwalteten Domäne freigegeben. Das Serverzertifikat benötigt die Extended Key Usage Server Authentication. Statt LDAPS öffentlich erreichbar zu machen, wird wenn möglich eine private Verbindung über Azure-Netze oder IPsec verwendet und der Zugriff in der Network Security Group auf die benötigte Quelladresse begrenzt.

Die offizielle Sophos-Beispielkonfiguration verwendet die öffentliche Secure-LDAP-IP, SSL/TLS, Port 636, DisplayName, mail und deaktiviert Validate server certificate. Eine private Verbindung über Azure-Netze oder IPsec ist Sophos’ zusätzliche Sicherheitsempfehlung. Die Zertifikatsprüfung mit passendem Namen und korrekter Vertrauenskette ist hier eine zusätzliche Avanet-Hardening-Empfehlung und nicht Bestandteil der Sophos-Beispielkonfiguration. Sie muss vor dem Produktivbetrieb in der eigenen Umgebung geprüft werden. Entra-Benutzer müssen sich zuvor anmelden und ihr Kennwort ändern, damit Kerberos-/NTLM-Hashes erzeugt und synchronisiert werden; das Bind-Konto gehört in die konfigurierte Entra-Domain-Services-Administratorgruppe.

Anzeigeattribut und E-Mail-Attribut

Das Anzeigeattribut bestimmt, wie Benutzer in der Sophos Firewall dargestellt werden. Mögliche Verzeichnisattribute, die man in der eigenen Umgebung antreffen und vor der Verwendung prüfen kann, sind:

• sAMAccountName
• userPrincipalName
• displayName
• name

Diese Werte sind nicht pauschal austauschbar. Entscheidend sind Verzeichnisschema, Eindeutigkeit und das Ergebnis mit einem Testbenutzer. Für Entra Domain Services dokumentiert Sophos DisplayName; daraus folgt keine allgemeine Vorgabe für lokales AD.

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=ad,DC=example,DC=com

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

OU=Users,OU=Company,DC=ad,DC=example,DC=com

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 sind folgende Massnahmen sinnvoll:

• 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. Wie Sie Mitglieder explizit freigeben, die Einschränkung auf die Main Group berücksichtigen und den Zugriff testen, beschreibt L2TP Remote Access auf Sophos Firewall einrichten.

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 keine AD-Gruppe eines Benutzers auf der Firewall existiert, erhält er die unter Authentication > Services konfigurierte Default group. Der Produktstandard ist Open group. Vor dem Rollout wird der effektive Wert trotzdem geprüft, weil er geändert worden sein kann und unmittelbar die geerbten Einstellungen bestimmt.

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.

Wie Gruppen-Policies, Default Group, Main Group, Benutzer-Overrides und die funktionsabhängige Mehrfachgruppenlogik gemeinsam betrieben und getestet werden, erklärt Sophos Firewall Benutzergruppen und Main Group richtig verwalten.

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

Wie man die Main Group für eine zeitabhängige Benutzerfreigabe prüft und Benutzer-Overrides abgrenzt, zeigt Sophos Firewall Access Time für Benutzer und Gruppen.

Für verbrauchsabhängige Zeit- und Datenkontingente gilt dieselbe Main-Group-Grenze. Den vollständigen Ablauf zeigt Surfing Quota und Network Traffic Quota auf Sophos Firewall.

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. Für Firewall authentication methods gilt eine wichtige Semantik: Die Firewall geht nur dann zum nächsten Server weiter, wenn der vorherige nicht erreichbar ist; abgelehnte Zugangsdaten lösen keinen normalen Fallback aus. Diese Reihenfolge ist daher weder Lastverteilung noch ein 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.

Bleibt danach offen, ob Dienstwahl, Benutzeridentität, Main Group, Quota oder erst die spätere Firewall-Regel scheitert, trennt Sophos Firewall Authentifizierungsfehler systematisch beheben diese Ebenen mit einem reproduzierbaren Testfall.

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. Prüfen, ob die Gruppe gefunden wird und ob ein definierter Testbenutzer als Mitglied erscheint.
• 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.

Wenn Sophos Endpoint bereits Security Heartbeat sendet, kann Synchronized User ID Authentication einen Windows-10-Domänenbenutzer ohne zusätzlichen Authentifizierungsagenten an die Firewall übermitteln. Anschliessend muss mit realem Testtraffic geprüft werden, ob der Benutzer erkannt wird und die vorgesehene Firewallregel greift.

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.

Die Firewall versucht zunächst General Authentication Client, Clientless single sign-on und Client-based single sign-on. Greift keine dieser Methoden, folgt browserinitiiertes NTLM. Schlägt auch NTLM fehl, erscheint das Captive Portal. Prüfen Sie bei einer unerwarteten Zuordnung zuerst Client type unter Current activities > Live users.

Die Einstellung Kerberos & NTLM bietet dem Browser beide Verfahren an; der Client entscheidet, welches er verwendet. Einen Kerberos-only-Modus gibt es nicht, weil er von der HTTP-Spezifikation nicht unterstützt wird. Bei transparentem Webverkehr leitet die Firewall die Authentifizierung auf TCP-Port 8091 um.

Wenn mehrere Benutzer dieselbe RDS- oder Terminalserver-IP teilen, reicht die normale IP-Zuordnung nicht. Für ausschliesslich über einen expliziten Proxy geführten HTTP- und HTTPS-Traffic zeigt Per-Connection AD SSO für Multi-User-Hosts den eigenen Ablauf und die Abgrenzung zu SATC.

⚠️ Upgrade-Hinweis für SFOS 22: Nach einem Upgrade von SFOS 21.5 oder älter auf SFOS 22.0 GA kann AD SSO mit Kerberos und NTLM ausfallen. Benutzerbasierte Regeln erkennen die betroffenen Domain-Benutzer dann nicht mehr, während anderer Firewall-Traffic weiterläuft. Sophos hat den Fehler in SFOS 22.0 MR1 Build 490 behoben. AD SSO sollte vor und direkt nach dem Upgrade mit einem echten Benutzerzugriff getestet werden. AD SSO nach dem SFOS-22-Upgrade reparieren zeigt die Prüfung in nasm.log, den gezielten NASM-Cleanup und die anschliessende Kontrolle mit echtem Benutzertraffic.

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.

   Beispiel: Die Firewall ist als fw01.edge.example.com konfiguriert, die AD-Domäne heisst corp.example.com. Beim Domain Join verwendet SFOS den NetBIOS-Hostnamen fw01 mit der AD-Domäne. Der in AD bekannte Name ist damit fw01.corp.example.com, nicht automatisch der konfigurierte Firewall-FQDN. Der Redirect-Name für transparentes Kerberos muss zum in AD registrierten HTTP-SPN passen und im DNS auflösbar sein.

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. Ein Konto mit AD-Leserechten kann die gezielte, nur lesende Abfrage auf einem Windows-System ausführen:

   setspn -Q HTTP/fw01.corp.example.com
   

   Der eigene Redirect-FQDN ersetzt den Beispielwert. Die Ausgabe muss genau den erwarteten SPN und das erwartete Computerobjekt zeigen; kein Treffer oder ein Treffer auf einem anderen Objekt wird vor dem Rollout mit dem AD-Verantwortlichen geklärt.

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 geht nur dann zum nächsten Server weiter, wenn der vorherige nicht erreichbar ist, nicht bei abgelehnten Zugangsdaten.

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.

Unter Authentication > Services sollte HTTP challenge redirect on intranet zone aktiviert bleiben. Wird eine NTLM-Challenge von einer im Internet gehosteten Website ausgelöst, führt die Firewall den Austausch damit über ihre lokale Interface-IP in der Intranet-Zone. Ist die Option ausgeschaltet, kann der Browser Anmeldedaten über das Internet senden. Das ist keine harmlose Kompatibilitätseinstellung.

Wenn Use web authentication for unknown users HTTPS-Traffic in transparentem Modus authentifiziert, entschlüsselt die Firewall die Verbindung für den Authentifizierungsvorgang, unabhängig von den Einstellungen der Firewallregel oder der SSL/TLS Inspection Rule. 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.

Sophos Firewall bietet dem Browser erst dann eines der beiden Verfahren an, wenn Kerberos und NTLM auf der Firewall erfolgreich initialisiert sind. Darum ist ein sichtbarer NTLM-Fallback kein Grund, die Kerberos-Prüfung zu überspringen. DNS, SPN und Systemzeit müssen zusammenpassen; bei Kerberos dürfen die beteiligten Uhren standardmässig höchstens fünf Minuten auseinanderliegen.

Die Kontorollen müssen getrennt betrachtet werden. Das LDAP-Bind-Konto benötigt nur die für Verzeichnisabfragen erforderlichen Leserechte. Für den Domain Join bei AD SSO ist dagegen ein Domain-Admin-Konto oder ein Konto mit delegierten Rechten zum Anlegen des Computerobjekts beziehungsweise SPN nötig. In HA-Umgebungen, bei mehreren AD-Servern oder nach Upgrades kann ein erneuter Domain Join erforderlich sein. Dafür müssen geeignete Join-Zugangsdaten verfügbar sein; das LDAP-Bind-Konto benötigt diese erhöhten Rechte nicht.

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-Benutzer können sich nicht am VPN Portal anmelden

Wenn ein bestehender AD-Benutzer das VPN Portal verwenden kann, ein neu angelegter Benutzer mit vergleichbarer Berechtigung aber nicht, sollte man zuerst Gruppenzuordnung, Remote-Access-Methode und Firmwarestand vergleichen. Unter Authentication > Users zeigt Group die Main Group; weitere importierte Gruppen stehen unter Other group memberships. SSL VPN kann mehrere Gruppenmitgliedschaften berücksichtigen, IPsec Remote Access dagegen nur die Main Group oder einen explizit ausgewählten Benutzer.

Für die Diagnose:

1. Betroffenen neuen Benutzer mit einem funktionierenden bestehenden Benutzer vergleichen.
2. Main Group und Other group memberships kontrollieren.
3. Unter Authentication > Services die VPN portal authentication methods, unter Administration > Device access die erlaubte Quellzone und in der Remote-Access-Policy den Benutzer beziehungsweise die Gruppe prüfen.
4. SFOS-Version und Build erfassen.

Sophos hat mit NC-180824 einen Fehler behoben, bei dem sich neue AD-Benutzer aus einer Secondary AD Group nicht am VPN Portal anmelden konnten. Der Fix ist in SFOS 22.0 MR2 Build 546 vom 14. Juli 2026 enthalten. Sophos nennt weder eine Introduktionsversion noch einen offiziellen Workaround. Identifizieren Sie zunächst, ob eine betroffene ältere Version eingesetzt wird. Aktualisieren Sie diese auf SFOS 22.0 MR2 oder neuer. Testen Sie danach mit einem AD-Benutzer, der sich erstmals an der Firewall anmeldet. Seine VPN-Berechtigung muss für diesen Test ausschliesslich über die betroffene Secondary Group in einer SSL-VPN-Policy erteilt werden.

⚠️ Gruppen nicht auf Verdacht neu sortieren, Benutzer nicht vorschnell mit Purge AD users bereinigen und Gruppen nicht neu erstellen. Diese Massnahmen sind von Sophos nicht als Lösung für NC-180824 dokumentiert und können andere Berechtigungen verändern.

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/fw01.corp.example.com 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.

Das unter Admin console and end-user interaction > Certificate ausgewählte Zertifikat muss den Redirect-Hostname oder FQDN abdecken und auf den Endpoints vertrauenswürdig sein. Das vorinstallierte selbstsignierte Firewall-Zertifikat erfüllt diese beiden Bedingungen für einen neu gesetzten Namen normalerweise nicht. Eine Zertifikatswarnung wird deshalb nicht übergangen, sondern mit einem passenden öffentlichen oder internen Zertifikat behoben.

Für NTLM lässt sich das Vertrauen gezielt auf den internen Redirect-Namen begrenzen. Microsoft Edge und Google Chrome übernehmen unter Windows die Einstellung aus Internet Options > Security > Local intranet > Sites > Advanced. In Firefox wird derselbe FQDN unter about:config in network.automatic-ntlm-auth.trusted-uris eingetragen. Nur den tatsächlich verwendeten internen Namen freigeben, keine breite Domain oder beliebige Websites.

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.

Änderung zurücknehmen und sicher weiterbetreiben

Vor Änderungen werden Serverreihenfolge, verwendete Dienste, Gruppen und Zertifikatseinstellungen dokumentiert. Scheitert die Abnahme, stellt man zuerst die vorherige Reihenfolge sowie die ursprüngliche verschlüsselte Verbindungsart und den Port wieder her. Eine testweise verwendete unverschlüsselte LDAP-Verbindung auf Port 389 dient ausschliesslich der kurzen Diagnose und darf nicht als Produktions-Rollback bestehen bleiben.

Muss die gesamte Konfiguration zurück, kann das zuvor heruntergeladene Backup unter Backup and firmware > Backup and restore wiederhergestellt werden. Das ersetzt die aktuelle Konfiguration, verwirft spätere Änderungen und startet die Firewall neu; der Vorgang gehört deshalb in ein Wartungsfenster. Ein Firmware-Rollback bootet die vorherige Partition samt deren Konfiguration und beendet ebenfalls Sitzungen. Der automatische Firmware-Rollback greift nur bei fehlgeschlagener Konfigurationsmigration, nicht bei einer erst im Betrieb sichtbaren AD-SSO-Störung.

Nach jedem Rückweg werden Test connection, ein normaler Dienst-Login, Gruppenwirkung und bei SSO ein echter Benutzerzugriff samt Log viewer > Authentication erneut geprüft. Bei HA gehören Gruppenimport und Purge AD users auf das Primary-Gerät; einen Ausfalltest des vorgesehenen sekundären DC führt man nur im freigegebenen Wartungsfenster durch und bestätigt dabei, dass der erste Server wirklich nicht erreichbar ist und der Login über den zweiten Server gelingt.

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.
• Bei Mehrfachgruppen: VPN-Portal-Login mit einem bestehenden und einem erstmals an der Firewall anmeldenden Benutzer geprüft, dessen Berechtigung ausschliesslich über eine Secondary Group in einer SSL-VPN-Policy erteilt wird.
• 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