Generischen LDAP-Server mit Sophos Firewall verbinden

Active Directory ist auf Sophos Firewall der häufigste Authentifizierungsserver, aber nicht der einzige. Wer OpenLDAP, 389 Directory Server, FreeIPA, Google Secure LDAP oder ein anderes reines LDAP-Verzeichnis betreibt, kann Sophos Firewall genauso als LDAP-Client anbinden. Der Server-Typ heisst dafür bewusst LDAP Server, nicht Active Directory, auch wenn Active Directory technisch selbst ein LDAP-Verzeichnis ist.

Dieser Artikel behandelt gezielt den generischen Fall: ein Verzeichnisdienst ohne die AD-spezifischen Felder wie Domain-Namen oder Kerberos. Für Active-Directory-Umgebungen mit LDAPS, Gruppenimport und AD SSO passt stattdessen Active Directory mit Sophos Firewall verbinden. Für RADIUS-basierte Authentifizierung, etwa über Microsoft NPS oder ein MFA-Gateway, ist Sophos Firewall RADIUS-Server einrichten der passende Artikel.

Wann ein generischer LDAP-Server passt

Ein LDAP-Server auf Sophos Firewall ist sinnvoll, wenn:

• Benutzer und Gruppen in einem Verzeichnis liegen, das kein Active Directory ist, zum Beispiel OpenLDAP, 389 Directory Server oder FreeIPA.
• Ein cloud-basiertes Verzeichnis eine LDAP-Schnittstelle anbietet, zum Beispiel Google Secure LDAP oder ein LDAP-Proxy vor Entra ID oder Okta.
• Mehrere Systeme bereits gegen dasselbe LDAP-Verzeichnis authentifizieren und die Firewall dieselbe Quelle nutzen soll.
• Es kein Kerberos oder NTLM braucht, sondern eine einfache Bind-Authentifizierung reicht.

Wenn stattdessen ein Windows Server mit Active Directory Domain Services betrieben wird, ist der spezialisierte AD-Servertyp meistens die bessere Wahl, weil er zusätzliche Felder wie Domain-Namen sauber abbildet. Der generische LDAP-Servertyp funktioniert zwar auch gegen Active Directory, bildet aber weniger AD-spezifische Automatismen ab.

Voraussetzungen

• Zugriff auf den WebAdmin der Sophos Firewall.
• Erreichbarkeit des LDAP-Servers von der Firewall aus, meistens Port 389 (Plaintext/StartTLS) oder 636 (LDAPS).
• Ein Bind-Konto mit Leserechten auf den relevanten Teilbaum, spezifiziert als Distinguished Name (DN).
• Die Base DN, unter der Benutzer gesucht werden, zum Beispiel ou=people,dc=firma,dc=local.
• Kenntnis des Attributs, das als Anmeldename dient, häufig uid, sAMAccountName oder mail.
• Bei verschlüsselter Verbindung: das Serverzertifikat oder die Zertifikatskette, wenn die Firewall es validieren soll.

⚠️ Ein Bind-Konto sollte nur Leserechte auf den benötigten Teilbaum haben. Es wird nicht für administrative Änderungen im Verzeichnis verwendet, sondern nur, um Benutzeranfragen der Firewall am LDAP-Server zu authentifizieren.

LDAP-Server anlegen

1. Authentication > Servers öffnen.
2. Add auswählen und als Server type LDAP server wählen.
3. Unter Server name einen eindeutigen Namen vergeben, zum Beispiel LDAP_Firma_Intern.
4. Bei Server IP/domain die IP-Adresse oder den DNS-Namen des LDAP-Servers eintragen.
5. Bei Version die vom Server unterstützte LDAP-Version wählen, meistens Version 3.
6. Bei Connection security zwischen Plaintext, SSL/TLS oder STARTTLS wählen.
7. Bei Port den passenden Port setzen, falls nicht der Standardport verwendet wird.
8. Anonymous login deaktivieren, sofern der Server keine anonymen Bind-Anfragen erlaubt.
9. Bei Bind DN das technische Konto als Distinguished Name eintragen, zum Beispiel cn=svc-sophos,ou=service,dc=firma,dc=local.
10. Das zugehörige Password eintragen.
11. Bei Base DN den Suchbereich für Benutzer eintragen, zum Beispiel ou=people,dc=firma,dc=local.
12. Bei Authentication attribute das Feld eintragen, das als Anmeldename dient, häufig uid.
13. Optional Display name attribute und Email address attribute setzen, zum Beispiel cn und mail.
14. Optional Group name attribute setzen, wenn Gruppenmitgliedschaften ausgewertet werden sollen.
15. Test connection ausführen und Ergebnis prüfen.
16. Save wählen.

Die Felder im Überblick:

Ein erfolgreicher Test connection beweist nur, dass Server, Port, Bind-Konto und Suchbasis grundsätzlich erreichbar sind. Ob die richtigen Benutzer gefunden werden und Gruppen korrekt zugeordnet sind, muss danach mit einem echten Testbenutzer geprüft werden.

Verschlüsselung richtig wählen

Für produktive Umgebungen sollte die Verbindung zwischen Firewall und LDAP-Server verschlüsselt sein, entweder über LDAPS auf Port 636 oder über STARTTLS auf dem klassischen Port 389. Plaintext-LDAP sendet Bind-Passwörter und teilweise Benutzerdaten unverschlüsselt und sollte nur in eng abgesicherten, internen Testszenarien verwendet werden.

Bei Validate server certificate prüft die Firewall, ob das vom LDAP-Server präsentierte Zertifikat vertrauenswürdig ist. Bei selbstsignierten Zertifikaten, wie sie zum Beispiel bei Google Secure LDAP verwendet werden, kann das Zertifikat als nicht vertrauenswürdig markiert sein, obwohl die Verbindung funktioniert. In diesem Fall muss bewusst entschieden werden, ob die Zertifikatsprüfung angepasst oder das Zertifikat in die Firewall importiert wird.

Beispiel: Google Secure LDAP

Google Secure LDAP zeigt gut, wie ein cloud-basiertes Verzeichnis über generisches LDAP angebunden wird:

• Server IP/domain: ldap.google.com
• Port: 636
• Version: 3
• Connection security: SSL/TLS
• Bind DN und Password: Zugangsdaten aus den in der Google Admin Console erzeugten LDAP-Client-Credentials.
• Zertifikat: Das von Google ausgestellte Client-Zertifikat mit privatem Schlüssel wird auf der Firewall hinterlegt.
• Attribute: uid für die Anmeldung, cn für den Anzeigenamen, mail für die E-Mail-Adresse, memberOf für Gruppen.

Dieses Beispiel lässt sich auf andere LDAP-Anbieter mit ähnlicher Struktur übertragen. Entscheidend ist immer, welches Attribut der Anbieter für Anmeldename, Anzeigename, E-Mail und Gruppenzugehörigkeit tatsächlich befüllt.

Bind DN und Base DN richtig eintragen

Die häufigste Fehlerquelle bei einem neuen LDAP-Server ist eine falsch geschriebene oder falsch verstandene DN-Syntax.

Wichtige Regeln:

• Ein DN wird vom spezifischsten zum allgemeinsten Teil geschrieben, zum Beispiel cn=svc-sophos,ou=service,dc=firma,dc=local.
• Die Base DN für die Benutzersuche muss der Teilbaum sein, in dem die relevanten Benutzerobjekte tatsächlich liegen, nicht zwangsläufig die Wurzel des Verzeichnisses.
• Wenn Benutzer in mehreren Organisationseinheiten liegen, muss die Base DN weit genug oben im Baum gewählt werden, dass sie alle relevanten Container einschliesst.
• Append base DN entscheidet, ob die Base DN zusätzlich an den Bind DN angehängt wird. Das ist serverabhängig und sollte bei Problemen gezielt getestet werden.

Wenn die Base DN zu eng gewählt ist, meldet die Firewall unter Umständen einen erfolgreichen Verbindungstest, findet aber später keine Benutzer. Wenn die Base DN zu breit gewählt ist, kann die Suche unnötig lange dauern oder unerwünschte Objekte einschliessen.

Gruppen und Attribute zuordnen

Für Firewall-Regeln, Web Policies oder VPN-Berechtigungen nach Gruppen ist das Group name attribute entscheidend. Es bestimmt, welches LDAP-Attribut die Firewall als Gruppenzugehörigkeit interpretiert.

Typische Muster:

• Verzeichnisse mit klassischem groupOfNames- oder posixGroup-Schema verwenden oft ein Attribut wie memberOf oder werten Gruppenmitgliedschaft über Rückverweise aus.
• Cloud-Verzeichnisse mit LDAP-Proxy, zum Beispiel Google Secure LDAP, liefern Gruppen häufig direkt im Attribut memberOf am Benutzerobjekt.
• Wenn das Schema unklar ist, hilft ein LDAP-Browser oder ein Kommandozeilenwerkzeug wie ldapsearch, um das Benutzerobjekt einmal vollständig anzusehen, bevor die Firewall konfiguriert wird.

Nach der Einrichtung sollte man mindestens einen Benutzer aus jeder relevanten Gruppe testen. Ein einzelner erfolgreicher Login beweist nicht, dass die Gruppenzuordnung für alle Gruppen korrekt funktioniert.

LDAP-Server für Dienste aktivieren

Ein angelegter LDAP-Server authentifiziert noch niemanden von sich aus. Er muss zusätzlich unter Authentication > Services dem gewünschten Dienst zugeordnet werden, zum Beispiel VPN Portal, SSL VPN, Captive Portal oder Admin-Login.

Praktischer Ablauf:

1. Authentication > Services öffnen.
2. Den betroffenen Dienst auswählen, zum Beispiel Firewall authentication methods oder VPN.
3. Den neu angelegten LDAP-Server als Authentifizierungsquelle hinzufügen.
4. Reihenfolge prüfen, wenn mehrere Server parallel verwendet werden.
5. Mit einem Testbenutzer den vorgesehenen Dienst prüfen.

Wenn mehrere Authentifizierungsserver gleichzeitig aktiv sind, zum Beispiel LDAP und lokale Benutzer, sollte die Reihenfolge bewusst gewählt werden. Die Firewall fragt die Server in der eingetragenen Reihenfolge ab.

Verbindung testen und validieren

Nach dem Speichern sollte die Einrichtung mehrstufig getestet werden:

1. Test connection in der Servermaske: bestätigt Erreichbarkeit, Bind-Konto und Base DN.
2. Testbenutzer am Zieldienst anmelden: bestätigt, dass Authentifizierung tatsächlich funktioniert.
3. Gruppenzugehörigkeit prüfen: bestätigt, dass das Group name attribute korrekt ausgewertet wird.
4. Falschen Benutzer oder falsches Passwort testen: bestätigt, dass fehlgeschlagene Logins sauber abgelehnt werden.
5. Log Viewer prüfen: zeigt, ob Authentifizierungsanfragen wie erwartet ankommen und verarbeitet werden.

Ein Testbenutzer, der sich erfolgreich anmeldet, aber nicht der erwarteten Gruppe zugeordnet ist, deutet meistens auf ein falsches Group name attribute oder ein unerwartetes Gruppen-Schema hin.

Typische Fehler

• Falsche DN-Syntax: Bind DN oder Base DN sind vertauscht, falsch geschrieben oder verwenden falsche Trennzeichen. Syntax gegen das Verzeichnisschema prüfen.
• Base DN zu eng gewählt: Verbindungstest ist erfolgreich, aber reale Benutzer werden nicht gefunden. Base DN im Verzeichnisbaum weiter oben ansetzen.
• Falscher Port oder falsche Verschlüsselung: LDAPS auf Port 389 oder Plaintext auf Port 636 funktioniert nicht. Port und Connection security müssen zueinander passen.
• Zertifikat nicht vertrauenswürdig: Bei selbstsignierten Zertifikaten kann die Firewall die Verbindung als nicht vertrauenswürdig einstufen. Zertifikat bewusst importieren oder Validierung gezielt anpassen.
• Anonymous login aktiv, obwohl der Server das verweigert: Bind schlägt fehl. Anonymous login deaktivieren und Bind DN/Password eintragen.
• Gruppenattribut passt nicht zum Schema: Login funktioniert, aber Gruppenrichtlinien greifen nicht. Attribut gegen das tatsächliche LDAP-Schema prüfen, zum Beispiel mit ldapsearch.
• LDAP-Server nicht unter Authentication > Services zugeordnet: Server ist angelegt, wird aber von keinem Dienst verwendet. Zuordnung unter Authentication > Services nachholen.
• Mehrere Authentifizierungsserver in falscher Reihenfolge: Ein anderer Server antwortet zuerst und liefert unerwartetes Verhalten. Reihenfolge unter Authentication > Services prüfen.

FAQ