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.

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.

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. Benutzerspezifische Policies haben Vorrang vor Gruppen-Policies. Die vollständige Gruppenlogik mit Pilot, Benutzer-Overrides und Main Group 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 der Server die Base DN beim Bind ergänzen 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.

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.

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.

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.

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.

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 offizielle Google-Anleitung setzt Validate server certificate in ihrer Werteliste nicht ausdrücklich. Ohne einen SFOS-22-Labortest sollte daraus weder ein festes Ein noch Aus abgeleitet werden; die Option wird nach dem allgemeinen TLS-Vorgehen und der eigenen Vertrauenskette entschieden.

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. 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: Benutzer-Override, Gruppen-Policy, Gruppenabbildung und die zuständige Firewall- oder VPN-Regel getrennt prüfen. Das vollständige Diagnosemodell zeigt Authentifizierungsfehler systematisch beheben.

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.