Wie konfiguriert man die externe LDAP-Authentifizierung für Zimbra?

Welche Änderungen an der externen LDAP-Authentifizierung gibt es in Zimbra?

Die externe LDAP-Authentifizierung ermöglicht es Zimbra, das Benutzerpasswort anhand eines externen Verzeichnisses anstatt des in Zimbras internem LDAP gespeicherten Passworts zu überprüfen. Laut dem aktuellen Zimbra Daffodil (v10) Administratorhandbuch wird die externe LDAP-Authentifizierung pro Domäne konfiguriert. Die externe Methode versucht, sich mit den angegebenen Benutzerdaten an das angegebene Verzeichnis zu binden. Bei erfolgreicher Bindung gilt das Passwort als gültig.

Dadurch wird ein externes LDAP-Verzeichnis nicht automatisch in die Zimbra-Benutzerdatenbank umgewandelt. Zimbra speichert seine spezifischen Benutzerdaten weiterhin in einem eigenen Verzeichnis. Im Leitfaden zu Version 10 wird ausdrücklich darauf hingewiesen, dass Benutzer normalerweise sowohl in Zimbra als auch im externen Verzeichnis vorhanden sein müssen, sofern die automatische Bereitstellung nicht separat konfiguriert wird.

Die aktuelle Produktdokumentation finden Sie im Zimbra Daffodil v10 Administrator Guide und im Zimbra v10 Config Guide .

Checkliste für die schnelle Planung

• Bestätigen Sie die Zimbra-Domäne, die Sie ändern möchten, zum Beispiel example.com.
• Prüfen Sie, ob die gleichen Benutzer bereits in Zimbra existieren, oder planen Sie die automatische Bereitstellung separat.
• Kennen Sie den externen LDAP-Hostnamen, den Port, die TLS-Methode und die Zertifikatskette.
• Wissen, wie ein Zimbra-Anmeldename einem Benutzer-DN in LDAP zugeordnet ist?
• Falls der DN nicht direkt aus dem Anmeldenamen erstellt werden kann, bereiten Sie eine Suchbasis, einen Suchfilter und ein Suchkonto mit minimalen Berechtigungen vor.
• Lassen Sie während des Tests eine Zimbra-Administrator-Sitzung geöffnet, damit Sie schnell zum vorherigen Zustand zurückkehren können.

Wählen Sie zuerst die richtige Mapping-Methode aus.

Der aktuelle Konfigurationsleitfaden für Version 10 definiert weiterhin die Attribute `search-base`, `search-bind`, `search-filter` und `per-account external-DN`. Ältere offizielle Dokumente des Zimbra Tech Centers erläutern die praktische Anwendung dieser Zuordnungen. Da diese Dokumente vor der Einführung von Daffodil erstellt wurden, sollten sie lediglich als Betriebsgrundlage dienen. Überprüfen Sie die Details anhand Ihrer installierten Version, bevor Sie eine umfangreiche Migration durchführen. Weitere Informationen finden Sie in den offiziellen Hinweisen des Zimbra Tech Centers zu externem LDAP .

Schritt 1: Aktuelle Domänenauthentifizierungseinstellungen aufzeichnen

Führen Sie administrative Befehle als zimbraBetriebssystembenutzer aus. Notieren Sie sich vor jeglichen Änderungen die vorhandenen Domänenwerte:

su - zimbra

zmprov gd example.com \
  zimbraAuthMech \
  zimbraAuthLdapURL \
  zimbraAuthLdapBindDn \
  zimbraAuthLdapSearchBase \
  zimbraAuthLdapSearchFilter \
  zimbraAuthFallbackToLocal

Speichern Sie die Ausgabe in Ihrem Änderungsdatensatz. Der Konfigurationsleitfaden für Version 10 listet gültige Werte für auf zimbraAuthMech, darunter zimbra, ldap, ad, sowie Kerberos- oder benutzerdefinierte Mechanismen. In diesem Leitfaden ist der Zielmechanismus ldap.

Schritt 2: Netzwerkverfügbarkeit und TLS vor der Änderung von Zimbra überprüfen

Führen Sie keine Fehlerbehebung bei Authentifizierungszuordnungen durch, bevor die grundlegende Konnektivität sichergestellt ist. Überprüfen Sie vom Zimbra-Server aus die DNS-Auflösung und die Erreichbarkeit des LDAP-Endpunkts. Bei LDAPS können Sie die Zertifikatskette mit OpenSSL überprüfen.

openssl s_client -connect ldap.example.net:636 \
  -servername ldap.example.net -showcerts

Bei einem Verzeichnis, das Standard-LDAP plus StartTLS verwendet, testen Sie den StartTLS-fähigen Endpunkt mit einem für Ihr Betriebssystem geeigneten LDAP-Client. Falls dieser ldapsearchinstalliert ist, kann eine Überprüfung des Suchkontos wie folgt aussehen:

ldapsearch -x -H ldap://ldap.example.net:389 -ZZ \
  -D "cn=zimbra-search,ou=svc,dc=example,dc=net" -W \
  -b "ou=people,dc=example,dc=net" \
  "(uid=alice)" dn

Im Zimbra-Administratorhandbuch (Version 10) ist festgelegt, dass ein ldaps:Endpunkt ein LDAP-Serverzertifikat benötigt, das von Zimbra als vertrauenswürdig eingestuft wird. Umgehen Sie die Zertifikatsvalidierung nicht, nur um den Test zu bestehen. Installieren Sie die entsprechende Zertifizierungsstelle (CA) oder Zertifikatskette gemäß der Truststore-Prozedur für Ihre spezifische Zimbra-Version.

Schritt 3: Konfigurieren Sie eine direkte Bind-DN-Vorlage, wenn Benutzer-DNs vorhersehbar sind

Dies ist das einfachste Muster. Angenommen, das externe Verzeichnis speichert Benutzer als uid=alice,ou=people,dc=example,dc=netund der Zimbra-Login lautet alice@example.com. Konfigurieren Sie die Domäne wie folgt:

zmprov md example.com zimbraAuthMech ldap

zmprov md example.com \
  zimbraAuthLdapURL "ldaps://ldap.example.net:636"

zmprov md example.com \
  zimbraAuthLdapBindDn "uid=%u,ou=people,dc=example,dc=net"

Das Administratorhandbuch beschreibt zimbraAuthLdapBindDneine Formatzeichenfolge, die zur Bestimmung des für die externe Bindung verwendeten DN dient. Die offizielle Dokumentation des Zimbra Tech Centers beschreibt gängige Ersetzungswerte, z. B. %ufür den lokalen Teil des Anmeldenamens und %nfür den vollständigen Anmeldenamen.

Verwenden Sie eine DN-Vorlage nur dann, wenn sie das richtige Verzeichnisobjekt eindeutig identifiziert. Befinden sich Benutzer in verschiedenen Organisationseinheiten oder ist ihr DN nicht vom Anmeldenamen abgeleitet, verwenden Sie stattdessen das Suchfiltermuster.

Schritt 4: Verwenden Sie die Suchfilterzuordnung, wenn der DN nicht direkt erstellt werden kann.

Die Suchfilterzuordnung ermöglicht es Zimbra, zunächst den Benutzereintrag zu finden und sich anschließend anhand des zurückgegebenen DN zu authentifizieren. Der Konfigurationsleitfaden für Version 10 definiert die erforderlichen suchbezogenen Domänenattribute.

Eine typische OpenLDAP-Konfiguration sieht folgendermaßen aus:

zmprov md example.com \
  zimbraAuthLdapSearchBase "ou=people,dc=example,dc=net"

zmprov md example.com \
  zimbraAuthLdapSearchFilter "(uid=%u)"

zmprov md example.com \
  zimbraAuthLdapSearchBindDn \
  "cn=zimbra-search,ou=svc,dc=example,dc=net"

Um zu vermeiden, dass ein Verzeichnispasswort direkt in den Shell-Verlauf geschrieben wird, sollte es zuerst in eine temporäre Shell-Variable eingelesen werden:

read -s LDAP_BIND_PASSWORD
zmprov md example.com \
  zimbraAuthLdapSearchBindPassword "$LDAP_BIND_PASSWORD"
unset LDAP_BIND_PASSWORD

Das Suchkonto sollte lediglich über Lesezugriff verfügen, um Benutzer im konfigurierten Stammverzeichnis zu finden. Es benötigt keine umfassenden Verzeichnisverwaltungsrechte.

Für Active Directory kann ein Filter je nach Anmeldekonvention entweder `true` sAMAccountNameoder userPrincipalName`false` verwenden. Zimbra bietet außerdem einen externen Active Directory-Authentifizierungsmechanismus. Nutzen Sie daher den AD-spezifischen Mechanismus, wenn er besser zu Ihrer Bereitstellung passt, anstatt jede AD-Umgebung über generische LDAP-Einstellungen zu erzwingen.

Schritt 5: Überprüfen Sie, was Zimbra tatsächlich gespeichert hat.

Lesen Sie die Domänenattribute nach der Änderung wieder aus:

zmprov gd example.com \
  zimbraAuthMech \
  zimbraAuthLdapURL \
  zimbraAuthLdapBindDn \
  zimbraAuthLdapSearchBase \
  zimbraAuthLdapSearchFilter \
  zimbraAuthLdapSearchBindDn \
  zimbraAuthFallbackToLocal

Prüfen Sie auf Fehler in den Anführungszeichen, einen falschen Basis-DN, einen unerwarteten Hostnamen oder eine alte Zuordnung, die von einem vorherigen Versuch übrig geblieben ist. Geben Sie das Suchbindungspasswort nicht in der Dokumentation, in Screenshots, Tickets oder Shell-Protokollen aus.

Schritt 6: Vor der breiten Einführung mit einem kontrollierten Benutzer testen

Wählen Sie ein Testkonto ohne Administratorrechte, das sowohl in Zimbra als auch im externen Verzeichnis existiert. Testen Sie diese Fälle gezielt:

• Das korrekte externe LDAP-Passwort ermöglicht die Anmeldung bei Zimbra.
• Ein falsches externes LDAP-Passwort wird abgelehnt.
• Ein deaktiviertes oder gesperrtes Verzeichniskonto verhält sich gemäß Ihrer Verzeichnisrichtlinie.
• Ein nicht existierendes Zimbra-Konto kann sich nur anmelden, wenn die automatische Bereitstellung konfiguriert wurde.
• Ein Ausfall des LDAP-Servers oder des Netzwerks führt zum erwarteten Ausfallverhalten.

Der letzte Test ist wichtig, da zimbraAuthFallbackToLocales sich um eine separate Domänenoption handelt. Laut Dokumentation zu Version 10 ist der Standardwert „false FALSE“. Die Aktivierung des Fallbacks kann bei einer sorgfältig geplanten Migration hilfreich sein, aber auch die Erwartung untergraben, dass das Deaktivieren oder Ändern eines Passworts im externen Verzeichnis den Zugriff sofort blockiert, wenn ein altes lokales Zimbra-Passwort weiterhin gültig ist. Behandeln Sie den Fallback als eine Entscheidung der Sicherheitsrichtlinie und nicht als eine allgemeine Option zur Fehlerbehebung.

Schritt 7: Entscheiden Sie, ob Sie auch die automatische Bereitstellung benötigen.

Externe Authentifizierung und Kontobereitstellung sind unterschiedliche Funktionen. Sollen neue Verzeichnisbenutzer automatisch Zimbra-Konten erhalten, konfigurieren Sie die automatische Zimbra-Bereitstellung separat. Das aktuelle Administratorhandbuch (Version 10) beschreibt die Modi EAGER, LAZY und MANUAL sowie deren zimbraAutoProv*Attribute.

Verwenden Sie Authentifizierungseinstellungen nicht ohne Weiteres für die automatische Bereitstellung. Die automatische Bereitstellung bietet separate Optionen für URL, Bindung, Suchbasis, Filter, Kontonamenszuordnung und Attributzuordnung. Stellen Sie zunächst eine zuverlässige externe Authentifizierung für bestehende Benutzer sicher; die Bereitstellung kann anschließend als zweiter Schritt implementiert werden.

Häufige Fehlermuster und worauf zu achten ist

Rücknahmeplan

Falls die Konfiguration des externen Verzeichnisses die normale Benutzerauthentifizierung verhindert, schalten Sie die Domäne mithilfe einer bereits geöffneten Administratorsitzung wieder auf die interne Zimbra-Authentifizierung um:

zmprov md example.com zimbraAuthMech zimbra

Überprüfen Sie anschließend den Wert:

zmprov gd example.com zimbraAuthMech

Löschen Sie die externen LDAP-Attribute während eines Notfall-Rollbacks nur, wenn ein triftiger Grund dafür vorliegt. Durch deren Beibehaltung lässt sich die Fehlerursache leichter ermitteln und der Vorgang nach Behebung des Mapping- oder TLS-Problems wiederholen.

Zusammenfassung der praktischen Referenz

• zimbraAuthMech: wählt den Authentifizierungsmechanismus für die Domäne aus.
• zimbraAuthLdapURL: externer LDAP-Endpunkt; Verwendung ldaps:für LDAP über SSL.
• zimbraAuthLdapBindDn: Format, das zur Erstellung des Benutzer-DN für die direkte Bindung verwendet wird.
• zimbraAuthLdapSearchBase: Teilbaum, in dem Zimbra nach dem externen Benutzer sucht.
• zimbraAuthLdapSearchFilter: LDAP-Filter, der zum Auffinden des Benutzers verwendet wird.
• zimbraAuthLdapSearchBindDnund zimbraAuthLdapSearchBindPassword: Anmeldeinformationen, die für die Suche verwendet werden, wenn eine anonyme Suche nicht angebracht ist.
• zimbraAuthLdapExternalDn: explizite externe DN-Zuordnung für ein einzelnes Zimbra-Konto.
• zimbraAuthFallbackToLocal: Steuert, ob Zimbra auf die lokale Authentifizierung zurückgreift, wenn die externe Authentifizierung fehlschlägt.

Checkliste für die abschließende Validierung

• Der externe LDAP-Endpunkt ist vom Zimbra-Mailbox-Server aus erreichbar.
• Die Validierung des TLS-Zertifikats gelingt ohne unsichere Umgehungslösungen.
• Die gewählte Bind-DN-Vorlage oder der Suchfilter ordnet jedem Login genau einen Verzeichniseintrag zu.
• Der Testbenutzer existiert in Zimbra oder die automatische Bereitstellung ist absichtlich konfiguriert.
• Tests mit korrekten und falschen Passwörtern verhalten sich wie erwartet.
• Das Ausweichverhalten entspricht Ihrer Sicherheitsrichtlinie.
• Die ursprünglichen Domäneneinstellungen und der Rollback-Befehl sind dokumentiert.

Bei Änderungen in der Produktionsumgebung empfiehlt sich eine stufenweise Einführung mit einer Testdomäne oder einer kleinen Benutzergruppe. Die externe LDAP-Authentifizierung ist unkompliziert, wenn die Identitätszuordnung vorhersehbar ist; die meisten schwerwiegenden Fehler entstehen durch Probleme mit der DN-Zuordnung, der Zertifikatsvertrauenswürdigkeit oder der Verwechslung von Authentifizierung und Kontobereitstellung.