Generischen LDAP-Server mit Sophos Firewall verbinden

Sophos Firewall kann Benutzer über den Servertyp LDAP server anhand von Verzeichnisattributen und Gruppenmitgliedschaften authentifizieren. In der Praxis sind vier Schritte nötig: eine lokale Gruppe vorbereiten, den LDAP-Server anbinden, ihn unter Authentication > Services für den gewünschten Dienst auswählen und Anmeldung sowie Berechtigung mit echten Testkonten prüfen.

OpenLDAP, 389 Directory Server oder FreeIPA sind typische Kandidaten für eine generische LDAP-Anbindung, aber keine austauschbaren Produkte. Attribute, Gruppenrückgaben und Kontoablauf unterscheiden sich je nach Schema. Diese Anleitung liefert deshalb ein übertragbares Beispiel; die Werte müssen am realen Benutzerobjekt geprüft werden. Google Secure LDAP ist als eigene, von Sophos dokumentierte Variante weiter unten beschrieben.

Für Windows Active Directory mit LDAPS, Gruppenimport oder AD SSO passt Active Directory mit Sophos Firewall verbinden besser. RADIUS über Microsoft NPS oder ein MFA-Gateway behandelt Sophos Firewall RADIUS-Server einrichten. Wer den nativen eDirectory-Servertyp vor SFOS 23 ablösen muss, findet unter eDirectory vor SFOS 23 migrieren den vollständigen Migrationsablauf.

Werte und Rückweg vorbereiten

Benötigt werden:

WebAdmin-Zugriff auf die Sophos Firewall;
Erreichbarkeit des LDAP-Servers von der Firewall über den am Server konfigurierten Port;
ein Bind-Konto mit Leserechten auf den benötigten Verzeichnisbereich;
Bind DN und Base DN, zum Beispiel cn=svc-sophos,ou=service,dc=example,dc=net und ou=people,dc=example,dc=net;
die Attribute für Anmeldung, Anzeigename, E-Mail-Adresse, Gruppe und gegebenenfalls Kontoablauf;
bei Zertifikatsprüfung ein auflösbarer Servername und die passende CA-Vertrauenskette.

Die üblichen Startwerte sind Port 389 für STARTTLS und 636 für SSL/TLS. Sie sind keine feste SFOS-Vorgabe: Ein Verzeichnis kann einen anderen Port verwenden, der mit Connection security und der Serverkonfiguration übereinstimmen muss.

⚠️ Das Bind-Konto benötigt keine administrativen Schreibrechte. Begrenze seine Leserechte auf den Teilbaum und die Attribute, welche die Firewall für Benutzeranfragen braucht.

Dokumentiere vor dem Umschalten unter Authentication > Services für jede betroffene Methode die ausgewählten Server, ihre Reihenfolge und die Vererbungsoptionen. Halte unter Firewall authentication methods zusätzlich die bisherige Default group fest. So lässt sich die Änderung zurücknehmen, ohne überhastet neue Objekte zu löschen. Halte während der Änderungen einen zuvor getesteten lokalen Administratorzugang für die Wiederherstellung bereit.

Bind DN, Base DN und Attribute unterscheiden

Ein DN läuft vom spezifischen Objekt zur Verzeichniswurzel. cn=svc-sophos,ou=service,dc=example,dc=net bezeichnet im Beispiel das Bind-Konto. Die Base DN legt dagegen den Startpunkt der Benutzersuche fest, etwa ou=people,dc=example,dc=net.

Eine zu enge Base DN findet nicht alle benötigten Benutzer. Eine unnötig breite Suchbasis kann Suchvorgänge verlangsamen und unerwünschte Objekte einschliessen. Append base DN hängt die Base DN beim Bind an einen unvollständigen Bind DN an; bei einem bereits vollständigen DN bleibt die Option normalerweise aus. Entscheidend ist das Verhalten des verwendeten LDAP-Servers.

Auch die Attribute kommen aus dem Verzeichnisschema. uid, cn, mail und memberOf sind Beispiele, keine universellen Vorgaben. Sophos empfiehlt memberOf als Group name attribute, verwendet im eigenen allgemeinen Konfigurationsbeispiel jedoch GID. Deshalb müssen Rückgabewert, lokale Gruppenzuordnung und Mehrfachmitgliedschaften mit echten Testbenutzern geprüft werden.

Verschlüsselung und Zertifikate wählen

Plaintext sendet Benutzerzugangsdaten unverschlüsselt und ist keine gute Produktionskonfiguration. SSL/TLS verschlüsselt die Verbindung von Beginn an; STARTTLS wertet eine zunächst unverschlüsselte LDAP-Verbindung auf TLS auf.

Bei Validate server certificate muss unter Server IP/domain der im Serverzertifikat ausgewiesene und von der Firewall auflösbare Name stehen. Sophos bezeichnet ihn in der SFOS-22-Hilfe als CNAME, während dieselbe Feldbeschreibung an anderer Stelle nur eine Server-IP nennt. Für einen kontrollierten TLS-Rollout ist daher der Zertifikatsname die sichere Wahl. Falls die Firewall ihn nicht auflösen kann, lässt sich unter Network > DNS > DNS host entry ein Eintrag anlegen. TTL, Reverse Lookup und Resolver-Test erklärt DNS Host Entries auf Sophos Firewall einrichten.

Validate server certificate prüft das Zertifikat des entfernten LDAP-Servers. Das optionale Client certificate legt ein Zertifikat fest, mit dem die Firewall eine gesicherte Verbindung zum LDAP-Dienst aufbaut; Google Secure LDAP verlangt dafür ausdrücklich das von Google erzeugte Zertifikat. Behebe bei TLS-Fehlern zuerst Name, DNS, Uhrzeit, Gültigkeit und Vertrauenskette, statt die Serverzertifikatsprüfung als erste Massnahme abzuschalten.

LDAP-Gruppe und Server konfigurieren

Lokale Gruppe vorbereiten

Authentication > Groups öffnen und Add wählen.
Einen eindeutigen Group name eintragen, zum Beispiel LDAP-Benutzer.
Den Group type für den vorgesehenen Anmeldeweg wählen. Normal setzt eine Benutzeranmeldung voraus; Clientless steuert Zugriff anhand einer IP-Adresse.
Benötigte Benutzer-, Remote-Access- und Sign-in-Policies setzen und mit Save speichern.

Bei Surfing quota und Access time bewusst die benötigten Grenzen wählen. Sophos verwendet im Lernbeispiel Unlimited internet access und Allowed all the time; das sind Beispiel-Policies, keine Voraussetzung für LDAP. Für einen eingeschränkten Pilotzugang passen die tatsächlich benötigte Nutzungsdauer und das freigegebene Zeitfenster besser. Weitere Felder nur dann auf dem Standard belassen, wenn dieser zur eigenen Zugriffspolitik passt.

Die Gruppe wird später als Default group verwendet. Sie gewährt oder sperrt nicht von selbst den Verkehr; ihre Policies und die Regeln des jeweiligen Dienstes entscheiden. Bei Benutzer-Policies und Remote-Access-VPNs ausser SSL VPN haben benutzerspezifische Einstellungen Vorrang vor Gruppen-Policies. Für Remote-Access-SSL-VPN gilt diese Vorrangregel nicht: Ein Benutzer kann auf die Ressourcen aller für ihn oder seine Gruppen geltenden Full- und Split-Tunnel-Policies zugreifen. Eine restriktivere Benutzer-Policy hebt breitere SSL-VPN-Gruppenberechtigungen daher nicht automatisch auf. Daraus folgt keine allgemeine Zusage, dass jedes LDAP-Schema Mehrfachmitgliedschaften gleich abbildet; Gruppenzuordnung und tatsächlich erreichbare Ressourcen müssen im Pilot geprüft werden. Die vollständige Gruppenlogik mit Pilot, benutzerspezifischen Ausnahmen und Hauptgruppe steht unter Sophos Firewall Benutzergruppen sicher verwalten.

Verbindung und Bind anlegen

Authentication > Servers öffnen und Add wählen.
Als Server type LDAP server auswählen.
Einen eindeutigen Server name vergeben, zum Beispiel LDAP-Firma.
Unter Server IP/domain die Server-IP oder den Domainnamen eintragen. Bei Validate server certificate den auflösbaren Namen aus dem Serverzertifikat verwenden.
Die vom Server unterstützte Version 2 oder 3 wählen. Google Secure LDAP erfordert Version 3.
Connection security und Port gemeinsam festlegen. Für den produktiven Betrieb SSL/TLS oder STARTTLS verwenden.
Anonymous login ausschalten und Bind DN sowie Password des Lesekontos eintragen.
Append base DN nur einschalten, wenn die Firewall die Base DN beim Bind an einen unvollständigen Bind DN anhängen soll.
Bei einer gesicherten Verbindung bewusst entscheiden, ob Validate server certificate aktiviert wird. Für normale LDAP-Server ist die Prüfung nach erfolgreicher Vorbereitung von Name, DNS und Vertrauen die sichere Produktionswahl. Google Secure LDAP folgt dem weiter unten beschriebenen Sonderfall. Ein benötigtes Client certificate aus der Liste auswählen.

Suchbasis und Attribute setzen

Unter Base DN den Startpunkt der Benutzersuche eintragen. Get base DN kann die vom Server angebotene Suchbasis abrufen.
Als Authentication attribute das Attribut mit dem Anmeldenamen setzen, häufig uid oder mail.
Display name attribute und Email address attribute passend zum Benutzerobjekt eintragen, beispielsweise cn und mail.
Unter Group name attribute das am Benutzerobjekt zurückgegebene Gruppenattribut eintragen. memberOf ist Sophos’ Empfehlung, muss aber zum Schema und Rückgabeformat passen.
Das zum Schema passende Expiry date attribute eintragen. Existiert kein solches Attribut, vor dem Rollout prüfen, ob die Maske einen leeren Wert akzeptiert und wie Konten ohne Ablauf behandelt werden.
Test connection ausführen und mit Save speichern.

Display name attribute und Email address attribute sind beim generischen LDAP-Server optionale Felder. Der Anzeigename macht das lokale Benutzerobjekt leichter erkennbar; das E-Mail-Attribut liefert die zugehörige Adresse. Für die Erstellung von Google-LDAP-Gruppen ist das E-Mail-Attribut dagegen erforderlich. Ein Expiry date attribute bezeichnet den Kontoablauf, nicht die Dauer einer VPN-Sitzung. Sophos nennt im allgemeinen Lernbeispiel Date, bei Google expiry; der passende Attributname richtet sich nach dem jeweiligen Schema.

Test connection prüft laut Sophos die Verbindung und die Bind-Zugangsdaten. Der Test beweist weder, dass die Base DN alle Benutzer umfasst, noch dass eine Gruppe oder Dienstberechtigung richtig greift. Dafür ist ein echter Login nötig.

Nur für API-Automatisierung beim Wechsel von SFOS 22 auf SFOS 23: In der LDAP-API-Referenz ändern sich die dokumentierten Zeilen unter Status Message Information: für Add LDAP server von 200/500/502/503 auf 200/400/401/403/409/500, für Edit LDAP server von 200/500/503 auf 200/400/401/403/404/500. 409 steht nur bei Add, 404 nur bei Edit. Auch die Darstellungssymbole wechseln von Message.LDAP* zu Message.CP*. Diese Dokumentationszeilen und Symbole garantieren keine tatsächlich übertragenen Codes oder Meldungen und belegen keine feste Zuordnung von 502/503 zu 409/404. Für API-Automatisierung die Referenz der eingesetzten Version prüfen und die tatsächlichen Antworten der Ziel-Firewall validieren, bevor eine Zuordnung übernommen wird. Das ist eine separate API-Prüfung; die GUI-Prüfung mit Test connection und der echte Login bleiben erforderlich.

Vor jedem automatisierten LDAP-Add/Edit: Die API-Referenzen für SFOS 22 und 23 sind bei IntegrationType widersprüchlich: Das Beispiel nennt LooseIntegration/TightIntegration und kennzeichnet DisplayNameAttribute, EmailAddressAttribute, GroupNameAttribute und ExpiryDateAttribute mit Only For Tight Integration; die Parametertabelle beschreibt beide Modi, erlaubt aber nur 1. Daraus weder die Unterstützung eines Modus noch die Bedeutung von 1 oder das zulässige Weglassen bedingter Attribute ableiten. Das Beispiel ist kein sendefertiger Payload; auch seine Textwerte für Schalter und Verbindungssicherheit stimmen nicht mit den Tabellenkodierungen überein. Vor einer Änderung das Schema beziehungsweise die API-Referenz der Zielversion prüfen und die tatsächliche Zielkonfiguration sowie eine zugehörige API-Antwort lesend kontrollieren. Bleibt die Zuordnung unklar, keine darauf beruhende Automatisierung ausführen, sondern den geprüften GUI-Weg verwenden oder die API-Vorgaben mit Sophos Support klären. Die oben beschriebenen GUI-Schritte bleiben davon getrennt; Test connection sowie echte Tests für Identität, Gruppen, gegebenenfalls Kontoablauf und jeden verwendeten Dienst bleiben erforderlich.

LDAP für die benötigten Dienste aktivieren

Authentication > Services öffnen.
Unter Firewall authentication methods den LDAP-Server in Selected authentication servers verschieben. Soll er primär antworten, an die erste Position setzen.
Als Default group die vorbereitete Gruppe LDAP-Benutzer wählen und Apply anklicken.
Den Server getrennt für alle tatsächlich verwendeten Methoden auswählen: User portal authentication methods, VPN portal authentication methods, VPN (IPsec/dial-in/L2TP/PPTP) authentication methods, Administrator authentication methods und SSL VPN authentication methods.
Vererbungsoptionen wie Set authentication methods same as firewall, Same as firewall oder Same as VPN nur verwenden, wenn die abgeleitete Serverliste beabsichtigt ist.

Pro Authentifizierungsmethode können höchstens 20 Server ausgewählt werden. Bei mehreren Servern fragt die Firewall sie in der angezeigten Reihenfolge ab. Die Administrator-Methode gilt nicht für den Super Administrator. Für L2TP und PPTP dokumentiert Sophos bei LDAP nur PAP; diese Kombination sollte wegen des Protokolls und der inzwischen veralteten VPN-Verfahren nicht ungeprüft neu eingeführt werden.

Zusätzlich für Administratoranmeldungen: Ein extern über LDAP authentifizierter Benutzer wird beim ersten Login zunächst als Standardbenutzer angelegt, auch wenn er im Verzeichnis eine Administratorrolle hat. Zuerst mit dem vorgesehenen Konto an einem freigegebenen Dienst wie dem Benutzer- oder VPN-Portal anmelden. Danach mit dem bestehenden lokalen Administratorzugang unter Authentication > Users den entstandenen Benutzer bearbeiten, User type auf Administrator setzen, ein auf die benötigten Rechte begrenztes Profile auswählen und mit Save speichern. Die Auswahl des Servers unter Administrator authentication methods allein reicht nicht. Anschliessend die WebAdmin-Anmeldung sowie erlaubte und nicht erlaubte Verwaltungsaktionen mit diesem Konto prüfen; den getesteten lokalen Wiederherstellungszugang weiterhin behalten.

Google Secure LDAP einrichten

Vor der Firewall-Konfiguration wird in der Google Admin Console unter Apps > LDAP ein LDAP-Client erstellt. Dabei werden seine Access permissions begrenzt, das Zertifikat samt privatem Schlüssel heruntergeladen und separate Zugangsdaten erzeugt. Das Passwort ist nach dem Schliessen des Dialogs nicht mehr sichtbar. Sind Benutzername oder Passwort falsch oder nicht mehr verfügbar, müssen in der Google Admin Console neue Zugangsdaten erzeugt und anschliessend Bind DN und Password in der LDAP-Serverkonfiguration der Firewall aktualisiert werden.

Google kann die Oberfläche und die Schritte in der Admin Console ändern. Prüfe deshalb vor der Einrichtung die aktuelle Google-Dokumentation zum Erstellen von LDAP-Clients, zum Herunterladen des Zertifikats und zum Erzeugen von Zugangsdaten. Ob der Dienst für die eigene Google-Edition verfügbar ist, erklärt Google Secure LDAP; die Zugriffsberechtigungen müssen zum vorgesehenen Benutzer- und Gruppenbereich passen.

Der von Sophos dokumentierte Ablauf in der Google Admin Console lässt sich so nachvollziehen:

Unter Apps > LDAP mit ADD CLIENT beginnen, einen LDAP-Clientnamen und eine Description eintragen und CONTINUE wählen. Ein eindeutiger Name wie Sophos-Firewall-Pilot erleichtert die spätere Zuordnung.
Die Access permissions auf den benötigten Benutzer- und Gruppenbereich begrenzen und mit ADD LDAP CLIENT bestätigen.
Download certificate wählen. Das ZIP enthält die Zertifikatsdatei .cer und den privaten Schlüssel .key. Beide Dateien in einen geschützten Arbeitsordner entpacken und den Speicherort für den anschliessenden Import festhalten. Der private Schlüssel gehört nicht in Tickets oder ungeschützte Freigaben.
Mit CONTINUE TO CLIENT DETAILS weitergehen, die Karte Authentication öffnen und GENERATE NEW CREDENTIALS wählen. Username und Password vor CLOSE sicher festhalten; diese Werte werden später als Bind DN und Password verwendet, nicht die Zugangsdaten eines Google-Administrators.

Die Google-Zugangsdaten ersetzen das Clientzertifikat nicht. Sophos Firewall benötigt für diese Variante sowohl das Zertifikat mit privatem Schlüssel als auch die erzeugten Bind-Zugangsdaten.

Danach den Client unter Service status mit ON for everyone einschalten und mit SAVE speichern. Dieser Service-Status aktiviert den Client, ersetzt aber nicht die zuvor festgelegten Access permissions.

Prüfe vor dem Zertifikatsimport unter Administration > Time, ob die Firewall eine korrekte Zeit über NTP bezieht. Eine falsch manuell gesetzte Uhr kann laut Sophos den Import von Zertifikaten scheitern lassen. Anschliessend unter Certificates > Certificates > Add das Format CER (.cer) wählen und sowohl Certificate als auch Private key aus dem Google-Download importieren. Das Zertifikat kann als nicht vertrauenswürdig erscheinen, weil Google es selbst signiert; Sophos bestätigt, dass Google LDAP trotzdem funktioniert. Diese Anzeige beschreibt das Clientzertifikat und nicht die Prüfung des LDAP-Serverzertifikats.

Beim Import einen eindeutigen Zertifikatsnamen vergeben. Über Choose File die entpackte .cer für Certificate und die zugehörige .key für Private key auswählen, jeweils mit Open übernehmen und abschliessend Save wählen. Erst nach dem Speichern lässt sich dieses Zertifikat unter Client certificate im LDAP-Server auswählen.

Für den LDAP-Server gelten folgende Werte:

Server IP/domain: ldap.google.com
Version: 3
Connection security: SSL/TLS
Port: 636
Anonymous login: aus
Bind DN und Password: die erzeugten Google-LDAP-Zugangsdaten
Append base DN: aus
Client certificate: das importierte Google-Zertifikat
Base DN: eintragen oder mit Get base DN abrufen
Authentication attribute: UID
Display name attribute: CN
Email address attribute: mail
Group name attribute: memberOf
Expiry date attribute: expiry

mail ist für die Google-LDAP-Gruppenerstellung erforderlich. Die Sophos-Anleitung für Google Secure LDAP setzt Validate server certificate in ihrer Werteliste nicht ausdrücklich. Daraus lässt sich weder ein vorgeschriebenes Ein noch Aus ableiten; die Option wird nach dem allgemeinen TLS-Vorgehen und der eigenen Vertrauenskette entschieden. Die Anzeige eines nicht vertrauenswürdigen Google-Clientzertifikats ist kein Grund, die Prüfung des entfernten Serverzertifikats abzuschalten.

Die Google-Verbindung mit Test connection prüfen und den Server mit Save speichern. Danach wie oben beschrieben eine lokale LDAP-Gruppe vorbereiten und den Google-Server unter Authentication > Services für die benötigten Dienste auswählen. Auch bei Google macht das Anlegen des Serverobjekts allein noch keinen Dienst nutzbar; der Pilotlogin prüft anschliessend Identität, Gruppe und Berechtigung.

Anmeldung und Gruppenzuordnung prüfen

Eine Abnahme umfasst Verbindung, Identität und Berechtigung:

Test connection muss Verbindung und Bind-Zugangsdaten bestätigen.
Unter Authentication > Services Serverliste, Reihenfolge und Vererbung jeder verwendeten Methode kontrollieren. Die Default group gehört zu Firewall authentication methods.
Mit einem Pilotbenutzer am vorgesehenen Dienst anmelden. Beim ersten Login legt die Firewall den extern authentifizierten Benutzer lokal an.
Unter Authentication > Users prüfen, ob Benutzer und Gruppe wie erwartet erscheinen.
Je relevanter Verzeichnisgruppe einen Positivtest durchführen. Zusätzlich mit einem Benutzer ohne passende lokale Gruppenzuordnung kontrollieren, ob die erwartete Default group greift.
Nicht nur die Anmeldung, sondern auch die beabsichtigte Richtlinie oder Testregel prüfen. Bei SSL VPN erlaubte und gesperrte Ressourcen unter Berücksichtigung der geltenden Benutzer- und Gruppen-Policies testen; nicht von einer restriktiven Benutzer-Policy allein auf die effektiven Rechte schliessen. Danach ein falsches Passwort als Negativtest verwenden.
Für Benutzeranmeldung, Autorisierung und Accounting access_server.log prüfen; bei VPN-Portal-Problemen zusätzlich vpnportal.log.
Wenn ein Ablaufattribut verwendet wird, ein Testkonto mit bekanntem Ablaufzustand einbeziehen.

Wenn die Schemawerte unklar sind, kann ein Administrator das Benutzerobjekt von einem Linux-Administrationssystem oder direkt vom LDAP-Server aus read-only abfragen:

ldapsearch -LLL -x -H ldaps://ldap.example.net:636 \
  -D 'cn=svc-sophos,ou=service,dc=example,dc=net' -W \
  -b 'ou=people,dc=example,dc=net' \
  '(uid=max.muster)' '*' '+'

Dieser optionale Diagnoseweg ist kein SFOS-Befehl und gehört nicht in die Advanced Shell. Das Beispiel setzt LDAPS und Vertrauen in die Server-CA auf dem ausführenden System voraus; STARTTLS benötigt einen entsprechend angepassten Aufruf. -W fragt das Bind-Passwort interaktiv ab. Den Filter (uid=max.muster) an das konfigurierte Authentication attribute anpassen. '*' und '+' können viele normale sowie operative Attribute mit personenbezogenen Daten ausgeben. Vor einem Ticket oder einer Weitergabe muss die Ausgabe anonymisiert werden.

Fehler nach Symptom eingrenzen

Keine Verbindung: Routing, DNS, Port und Connection security prüfen. Danach Bind DN, Passwort und Anonymous login kontrollieren.
TLS- oder Zertifikatsfehler: Den Namen aus dem Serverzertifikat, DNS-Auflösung, Firewall-Uhrzeit, Gültigkeit und CA-Kette prüfen. Die Zertifikatsprüfung nicht als erste Massnahme deaktivieren.
Test connection funktioniert, der Benutzer wird aber nicht gefunden: Base DN, Authentication attribute und den eingegebenen Anmeldenamen vergleichen.
Login funktioniert, die Gruppe ist falsch: Group name attribute und dessen realen Rückgabewert, lokale Gruppenabbildung sowie Default group kontrollieren. memberOf ist eine Empfehlung, aber kein für jedes Schema garantiertes Mapping.
Server ist angelegt, wird aber nicht verwendet: Auswahl, Reihenfolge und Vererbung für den betroffenen Dienst unter Authentication > Services prüfen.
Google Secure LDAP bindet nicht: Version 3, Port 636, ausgeschaltetes Anonymous login, ausgeschaltetes Append base DN, Client-Service-Status, Zugangsdaten und Google-Clientzertifikat einzeln kontrollieren.
Suche ist langsam oder liefert unerwünschte Konten: Base DN auf den benötigten Teilbaum begrenzen.
Login klappt, die erwartete Richtlinie nicht: Benutzerspezifische Einstellungen, Gruppen-Policy, Gruppenabbildung und die zuständige Firewall- oder VPN-Regel getrennt prüfen. Bei SSL VPN alle geltenden Benutzer- und Gruppen-Policies sowie die tatsächlich erlaubten Ressourcen einbeziehen; eine restriktive Benutzer-Policy allein genügt nicht. Das vollständige Diagnosemodell zeigt Authentifizierungsfehler systematisch beheben.
Portal-Login klappt, WebAdmin-Login nicht: Unter Authentication > Users die manuell zugewiesene Administratorrolle und das Profile prüfen. Danach Serverauswahl unter Administrator authentication methods und die geltenden Gerätezugriffsregeln kontrollieren. Den lokalen Wiederherstellungszugang nicht aufgeben, bevor der neue Weg geprüft ist.

Sicher zurückbauen

Stelle bei einem fehlgeschlagenen Rollout zuerst für jede betroffene Methode die zuvor dokumentierte Serverauswahl, Reihenfolge und Vererbung wieder her. Unter Firewall authentication methods wird zusätzlich die frühere Default group wiederhergestellt. Mit dem früheren Authentifizierungsweg einen Positiv- und einen Negativtest durchführen und die relevanten Logs kontrollieren.

Den neuen LDAP-Server und die Gruppe erst löschen, wenn sie in keinem Dienst und keiner Policy mehr verwendet werden. Automatisch angelegte LDAP-Benutzer nicht mit Purge AD users bereinigen: Die SFOS-22-Hilfe dokumentiert diese Funktion nur für Active Directory. Wenn solche Benutzer entfernt werden müssen, den unterstützten Weg für die eigene Konfiguration vorab mit Sophos Support klären.