AD Connector mit zweitem AD: User im falschen LDAP-Unterbaum

Moin,

ich versuche gerade, ein frisches UCS 4 mit zwei ADs zu verheiraten, sodass bidirektional synchronisiert wird, ohne dass User vom AD1 im AD2 landen und umgekehrt.

Dazu bin ich der kurzen Anleitung gefolgt.

Die Anbindung vom ersten AD klappt problemlos. User und Gruppen werden synchronisiert. Dafür habe ich:

[ul][li]im AppStore den UCS AD Connector installiert,[/li]
[li]diesen ausgeführt und konfiguriert,[/li]
[li]den Passwort-Sync-Service eingerichtet[/li][/ul]

Soweit, so gut.

Den zweiten AD wollte ich dann nach besagter Anleitung anbinden. Allerdings will ich, dass die Benutzer, Gruppen und Computer aus AD2 in einem anderen Unterbaum im UCS-LDAP landen. Die Anleitung suggeriert, dass das gehen soll, verrät aber nicht, wie.

Also habe ich folgendes getan:

[ul][li]Zweite Connector-Instanz mit »…/prepare-new-instance -a create -c connector-ad2« angelegt,[/li]
[li]Alle Parameter mit »ucr set connector-ad2/…« gesetzt (analog zum ersten Connector, nur halt Bind-User/Passwort, Hostnamen angepasst),[/li]
[li]Eintrag in /etc/hosts via »ucr set hosts/static/…« angelegt,[/li]
[li]auf dem zweiten AD-Server den Passwort-Sync-Dienst installiert,[/li]
[li]das Mapping in /etc/univention/connector-ad2/ad/mapping angepast, indem ich dort »ucs_default_dn« auf »cn=users,cn=ad2,dc=test-ucs,dc=intranet« gesetzt habe (analog fur Gruppen und Computer),[/li]
[li]in der UMC die neuen Container »cn=ad2,…« sowi »cn=users,cn=ad2,…« angelegt, dito für Gruppen und Computer,[/li]
[li]und als Letztes den Dienst mit »service univention-ad-connector-ad2 start« gestartet.[/li][/ul]

Die zweiten Instanz synchronisiert jetzt auch brav und fleißig, sprich die Verbindung klappt. Allerdings landen die User in cn=users,dc=test-ucs,dc=intranet und nicht dort, wo ich sie haben wollte, in cn=users,cn=ad2,dc=test-ucs,dc=intranet. Dadurch wurden nun auch schön die User vom AD1 ins AD2 synchronisiert sowie umgekehrt.

Dann habe ich mal nach »ucs_default_dn« im Quellcode vom Connector gesucht:

grep -r ucs_default_dn /usr/share/pyshared/univention/connector root@master:~# grep -r ucs_default_dn /usr/share/pyshared/univention/connector /usr/share/pyshared/univention/connector/__init__.py: def __init__( self, ucs_default_dn='', con_default_dn='', ucs_module='', ucs_module_others=[], sync_mode='', scope='', con_search_filter='', ignore_filter=None, match_filter=None, ignore_subtree=[], /usr/share/pyshared/univention/connector/__init__.py: self.ucs_default_dn=ucs_default_dn

Das sieht für mich so aus, als würde der Parameter vom Connector gar nicht benutzt, sondern ausschließlich von meinem Mapping in ein Attribut gleichen Namens eine Instanz eine Python-Klasse kopiert!? Und das Attribut wird dann nirgends verwendet.

Meine Frage: wie bekomme ich beim AD-Connector die User, Gruppen und Computer in andere Container hinein?

Hallo,

die Möglichkeit Benutzer/Gruppen standardmäßig in einen anderen Container zu synchronisieren ist noch nicht vollständig implementiert. Ich habe ein entsprechendes Enhancement angelegt, dass dieser Punkt in der Doku klarer formuliert werden kann.

Mit freundlichen Grüßen,
Tim Petersen

Vielen Dank für die Antwort. Schade.

Dann sollte das in der Dokumentation aber bitte sehr deutlich herausgestellt werden, dass bei aktueller Verwendung mit zwei Domänen die Benutzer, Gruppen und Computer durch die bidirektionale Synchronisation plötzlich in beiden Domänen vorhanden sind. Wenn ich mir vorstelle, dass das jemand mit Produktivsystemen ausprobiert und dancah potenziell hunderte Benutzer und Gruppen wieder manuell auseinandertüddeln muss…

Die Frage ist jetzt schon ein bisschen her. Ich baue derzeit ein Testsystem für ein Szenario mit mehreren bestehenden ADs und stehe vor derselben Frage: Wie bekommt man es hin, dass die Daten von mehreren ADs in verschiedene, zu definierende Container synchronisiert werden. Es soll sich um eine unidirektionale Verbindung handeln, aber die User müssen im Verzeichnis getrennt sein. Die Dokumentation hat sich in diesem Punkt (auch für UCS 5) seit 2015 offenbar nicht verändert.

Mastodon