Kopano Active Directory Benutzerverwaltung

Apps & App Center
,
#1

Hallo …
… aktuell haben wir noch ein in die Tage gekommenes Zarafa im Einsatz.
Und bislang haben wir die User immer im Active Directory über die Schema-Erweiterung verwaltet.

Jetzt habe ich mal testweise UCS mit Kopano installiert und ans AD gebunden.
Die Nutzer werden auch alle angezeigt, aber die Kopano-Konten sind nicht da.

In der Kopano-Nutzerverwaltung sind auch keine email-adressen eingetragen, obwohl im diese im AD vorhanden sind.

Sollten die Konten aus dem AD nicht übernommen werden, so dass die Nutzerverwaltung weiterhin komplett über den Windows Server erfolgen kann?

Greetz

Der Rico

#2

Hallo,

also so gut UCS und die Kopano-Integration darauf auch funktioniert, aber in diesem Fall - und insbesondere, wenn Sie weiter primär ein AD einsetzen wollen - glaube ich, dass Sie mit Kopano auf einer anderen Distribution besser beraten sind.

Was Sie momentan haben, ist eine Anbindung ans AD über eine dafür gebaute Schemaerweiterung. UCS benutzt OpenLDAP als Verzeichnisdienst und Kopano auf UCS setzt auf ene für OpenLDAP angepasste Schemaerweiterung. Die Attribute, die die beiden Integrationen benutzen sind doch sehr unterschiedlich, was Sie ja durch das Fehlen der Mailadressen und der Mailboxen schon als Resultat bemerkt haben.
Sicherlich könnte man das noch irgendwie umbauen, aber am Ende haben Sie dann doch 2 Synchronisationen ( AD zu UCS zu Kopano) und eine Lösung, die so nicht gedacht ist.

Mein Aussage rüttelt aber trotzdem nicht am Vorteil eines UCS unter einem führenden AD bei anderen Applikationen.

hth,
Dirk Ahrnke

#3

Ich habe den AD Whatever von Univention immer so verstanden, dass obrige Aussage nicht zutrifft. Nutzer anlegen und grobe Details (Name etc) werden zwar noch im AD verwaltet, alles Appspezifische (Quotas, Email, etc, was halt das Schema nutzt) wird dann in Univention verwaltet.

#4

Beim AD-Takeover werden die Benutzer-, Gruppen- und Computerinformationen übernommen. Anschließend wird das Windows-AD abgeschaltet, und das UCS-AD übernimmt die DC-Dienste der Domäne. Es handelt sich also um einen einmaligen Vorgang.

Bei einer AD-Verbindung ist es ähnlich, aber beide Systeme laufen gleichzeitig weiter, und Accounts werden fortlaufend synchronisiert (optional bidirektional oder halt nur unidirektional). Die Windows-DCs bleiben erhalten und stellen weiterhin die DC-Dienste bereit. Das UCS-System stellt keinerlei AD-DC-Dienste bereit. Dafür können Linux-spezifische Anwendungen die Benutzer-/Gruppeninformationen aus dem UCS-LDAP nehmen.

In Fall 1 kommt der AD-Connector zum Einsatz, aber halt nur ein einziges mal. In Fall 2 läuft der AD Connector hingegen ständig.

In beiden Fällen ist es so, dass der AD-Connector standardmäßig nur gewisse Attribute aus dem Windows-AD übernimmt. Diese beinhalten nicht AD-Schema-Erweiterungen wie die von Kopano. Allerdings ist das Mapping (also die Konfiguration, die festlegt, welche Windows-AD-Attribute in welche UCS-LDAP-Attribute umgesetzt werden sollen) auch nichts weiter als eine Python-Datei, die man sehr wohl anpassen kann und darf und somit auch eine Synchronisation der Kopano-Attribute erreichen kann.

Im Fall von Kopano ist es so, dass man Kopano problemlos direkt mit einem (Windows-)AD betreiben kann. Daher ist der eine große Vorteil einer UCS-AD-Verbindung, nämlich dass die Infos im (Open)LDAP bereit stehen, nur von begrenztem Nutzen. Wenn das AD weiterhin von Windows-DCs betrieben werden soll und keine anderen Apps aus dem UCS-App-Center zum Einsatz kommen sollen, so ist in der Tat der Betrieb von Kopano auf einem Nicht-UCS vermutlich die einfachere Variante — schlicht und ergreifend, weil jede Form von Synchronisation (AD Connector) die Komplexität eines Systems beträchtlich erhöht und interessante potenzielle Fehlerquellen einführt.

Gruß
mosu

#5

Danke für die raschen Antworten und die ausführlichen Erklärungen.
Denke, dann wird wohl der altbewährte Weg für uns praktikabler sein.

Mastodon