In einem unserer früheren Artikel haben wir erläutert, wie man Zimbra mit MS Active Directory verbindet, das in den meisten russischen Unternehmen für das Management von Benutzerkonten verwendet wird. Wir empfahlen Zimbra-Benutzern, die einfachste und sicherste Methode zur Erstellung von Postfächern in Zimbra basierend auf Daten aus AD zu verwenden, die wir LAZY Mode nennen. Dieser Betriebsmodus ermöglicht es, einen neuen Zimbra-Benutzer mit Name und Passwort aus AD automatisch beim ersten Login im Zimbra-Webclient zu erstellen. Allerdings wurde durch die entstandene Diskussion in den Kommentaren klar, dass diese Methode der automatischen Benutzeranpassung aus AD nicht für alle Administratoren geeignet ist. Daher werden wir jetzt eine alternative Methode zur Automatisierung der Erstellung von Benutzerkonten auf Basis von AD-Daten vorstellen, die wir EAGER Mode nennen.
Der LAZY- und der EAGER-Modus unterscheiden sich in der Art und Weise, wie neue Konten erstellt werden. Während im LAZY-Modus das System darauf wartet, dass der Benutzer selbst in den Zimbra-Webclient einsteigt, um einen neuen Benutzer zu erstellen, fragt das System im EAGER-Modus regelmäßig den Server mit Active Directory nach dem Auftreten neuer Benutzer. Bei einer positiven Rückmeldung erstellt es automatisch ein neues Konto basierend auf den von Active Directory bereitgestellten Daten. Dieser scheinbar geringfügige Unterschied kann die Nutzung des LAZY-Modus für viele IT-Manager völlig unakzeptabel machen.
Ein solches Szenario könnte ein direkter Verbot der Nutzung des Zimbra-Webclients sein. Dies könnte einerseits durch die Einsparung von Server-Rechenleistung bedingt sein (bei Verwendung des Webclients kann der Server mit Zimbra einen qualitativ hochwertigen Service für 2500 Nutzer bereitstellen, während bei der Nutzung von Desktop- und Mobilclients bis zu 5-6 Tausend Nutzer unterstützt werden können), andererseits könnte es auch an der Sicherheitsrichtlinie des Unternehmens liegen, die die Verwendung des Webclients für die E-Mail-Kommunikation ausdrücklich verbietet. Das Fehlen eines Webclients führt zur Unmöglichkeit, den LAZY Mode zu nutzen, der nur in diesem Modus funktioniert, was bedeutet, dass den IT-Managern solcher Unternehmen keine andere Wahl bleibt, als den EAGER Mode zu verwenden.
Zunächst müssen wir AD als externes LDAP mit Zimbra verbinden. Dazu sollten wir die Administrationskonsole aufrufen, die unter folgender Adresse zu finden ist: mail.company.ru:7071/zimbraAdmin/, danach wählen wir im linken Seitenbereich den Punkt Configure, und dann den Unterpunkt Domains. Zu den Unternehmen gehören Domänen Jetzt muss derjenige ausgewählt werden, den wir mit AD verwenden werden, und durch einen Rechtsklick auf die gewählte Domain den Punkt «Configure Authentification» auswählen.. Nachdem wir die notwendigen Daten eingegeben haben, erscheint ein Dialog zur Konfiguration des externen LDAP, in dem wir alle erforderlichen Informationen für die Integration von Zimbra mit AD eingeben.
Nachdem alle notwendigen Daten eingegeben wurden, sollten wir eine Konfigurationsdatei erstellen, zum Beispiel touch ~/Documents/autoprov.cfg, in die wir eine Reihe von Befehlen eingeben, die benötigt werden, um die automatische Konfiguration der Konten aus AD im EAGER Mode zu aktivieren. Im Gegensatz zum LAZY Mode, wo der Setup-Prozess sehr einfach ist und alle Einstellungen direkt über die CLI eingegeben werden können, ist es bei EAGER Mode besser, auf Nummer sicher zu gehen und alle Konfigurationen in einer separaten Datei zu speichern. So wird es einfacher, Änderungen vorzunehmen, falls etwas schiefgeht.
Also, nach der Erstellung der Datei ~/Documents/autoprov.cfg, sollten wir die folgenden Zeilen eintragen, nachdem wir sie an unsere Infrastruktur angepasst haben:
md company.ru zimbraAutoProvAccountNameMap "samAccountName"
md company.ru +zimbraAutoProvAttrMap description=description
md company.ru +zimbraAutoProvAttrMap displayName=displayName
md company.ru +zimbraAutoProvAttrMap givenName=givenName
md company.ru +zimbraAutoProvAttrMap cn=cn
md company.ru +zimbraAutoProvAttrMap sn=sn
md company.ru zimbraAutoProvAuthMech LDAP
md company.ru zimbraAutoProvBatchSize 40
md company.ru zimbraAutoProvLdapAdminBindDn "CN=Administrator,CN=Users,DC=company,DC=ru"
md company.ru zimbraAutoProvLdapAdminBindPassword *********
md company.ru zimbraAutoProvLdapBindDn "Administrator@company.ru"
md company.ru zimbraAutoProvLdapSearchBase "CN=Users,dc=company,dc=ru"
md company.ru zimbraAutoProvLdapSearchFilter "(cn=%u)"
md company.ru zimbraAutoProvLdapURL "ldap://192.168.0.1:389"
md company.ru zimbraAutoProvMode EAGER
md company.ru zimbraAutoProvNotificationBody "Ihr Konto wurde automatisch erstellt. Ihre E-Mail-Adresse ist ${ACCOUNT_ADDRESS}."
md company.ru zimbraAutoProvNotificationFromAddress Administrator@company.ru
md company.ru zimbraAutoProvNotificationSubject "Neues Konto wurde automatisch erstellt"
ms mail.company.ru zimbraAutoProvPollingInterval "1m"
ms mail.company.ru +zimbraAutoProvScheduledDomains "company.ru"Mit diesen Einstellungen verlangen wir vom Zimbra-Server, dass er jede Minute auf das AD zugreift und Informationen über neue Benutzer in der Datenbank abruft. Bei deren Entdeckung wird ein Konto für sie erstellt und eine Willkommensnachricht gesendet.
Nachdem alle Änderungen in der Datei gespeichert wurden, müssen die in ihr festgelegten Einstellungen mit dem Befehl angewendet werden. zmprov < ~/Documents/autoprov.cfg. Alle vorgenommenen Änderungen werden sofort wirksam, es muss nicht neu gestartet werden.
Falls die automatische Kontoanpassung aus AD im EAGER-Modus funktioniert, wird im Datei /opt/zimbra/log/mailbox.log der Verlauf der automatischen Kontoanpassung folgendermaßen angezeigt:
[AutoProvision] [] autoprov - Automatische Bereitstellung von Konten in der Domain company.ru
[AutoProvision] [] autoprov - 1 externe LDAP-Einträge als Suchergebnis zurückgegeben
[AutoProvision] [] autoprov - Konto im EAGER-Modus automatisch erstellt: example@company.ru, dn="CN=example,OU=zimbrausers,DC=company,DC=ru"Wenn die automatische Kontoanpassung nicht funktioniert, liegt das Problem wahrscheinlich am AD-Server. In diesem Fall sollte der aufgetretene Fehlercode betrachtet werden. Hier sind die häufigsten Fehler:
525 — Benutzer nicht gefunden
52e — Ungültige Anmeldedaten
530 — Momentan keine Anmeldeberechtigung
531 — Keine Anmeldeberechtigung von diesem Computer
532 — Passwortablaufdatum überschritten
533 — Konto ist deaktiviert
534 — Der Benutzer hat nicht genügend Berechtigungen, um sich von diesem Computer anzumelden
701 — Ablaufdatum des Kontos überschritten
773 — Der Benutzer muss das Passwort zurücksetzen
775 — Der Kontozugriff ist vorübergehend eingeschränkt
8350 — ungültiges Format des Distinguished Name
Quelle: habr.com
