UCS <-> Samba4 LDAP Synchronisation

[t.janssen]

Tag zusammen,

habe hier versucht einen Samba4 Server der als ADC konfiguriert ist, mit einem UCS Server zu verbinden. Der UCS Server soll als Fileserver, sowie als Frontend für die Verwaltung von Benutzern, Gruppen usw. dienen. Eine ‘Active Directory Verbindung’ zwischen den beiden hat auch sofort funktioniert (Bidirektionaler Austausch von Benutzern, Gruppen usw.). Offensichtlich scheint es aber ein Problem bei der Synchronisierung von Passwörtern zu geben:

(aus der ‘connector.log’)
…
09.11.2016 12:56:18,829 LDAP (PROCESS): sync to ucs: Resync rejected dn: CN=dsa-kontakte,CN=Users,DC=dsa-intern,DC=net
09.11.2016 12:56:18,836 LDAP (PROCESS): sync to ucs: [ user] [ modify] uid=dsa-kontakte,cn=users,dc=dsa-gmbh,dc=de
09.11.2016 12:56:18,851 LDAP (ERROR ): failed in post_con_modify_functions
09.11.2016 12:56:18,851 LDAP (ERROR ): Traceback (most recent call last):
File “/usr/lib/pymodules/python2.7/univention/connector/init.py”, line 1309, in sync_to_ucs
f(self, property_type, object)
File “/usr/lib/pymodules/python2.7/univention/connector/ad/password.py”, line 383, in password_sync
res = get_password_from_ad(connector, univention.connector.ad.compatible_modstring(object[‘dn’]))
File “/usr/lib/pymodules/python2.7/univention/connector/ad/password.py”, line 183, in get_password_from_ad
(level, ctr) = connector.drs.DsGetNCChanges(connector.drsuapi_handle, 8, req8)
RuntimeError: (8453, ‘WERR_DS_DRA_ACCESS_DENIED’)
…

Wie ersichtlich: ‘WERR_DS_DRA_ACCESS_DENIED’
UCS wurde als Master konfiguriert. Der Samba AD und UCS haben unterschiedliche Domains. Liegt das nun an den unterschiedlichen Domänen oder müssen hier noch Benutzer und/oder Rechte übernommen/eingetragen werden.

Vielen Dank

[ahrnke]

Hallo,

ich wäre vermutlich ohne Hinweis in diesem Kontext auch nicht auf den SDB-Artikel Speed up LDAP-Binds on AD member mode systems gekommen. Aber da steht eine möglichweise nützliche Anmerkung:

By default, in AD member mode, the UCS AD Connector reads object data from Microsoft Active Directory with the permissions of the machine account of the UCS DC Master. This machine account usually isn’t authorized to read encrypted password hashes from Active Directory. The Active Directory object LDAP DN of a privileged replication user should be configured in the Univention Configuration Registry variable connector/ad/ldap/binddn. This must be a member of the Domain Admins group in the AD.

Viel Erfolg,
Dirk Ahrnke

[t.janssen]

[quote=“ahrnke”]Hallo,

ich wäre vermutlich ohne Hinweis in diesem Kontext auch nicht auf den SDB-Artikel Speed up LDAP-Binds on AD member mode systems gekommen. Aber da steht eine möglichweise nützliche Anmerkung:

By default, in AD member mode, the UCS AD Connector reads object data from Microsoft Active Directory with the permissions of the machine account of the UCS DC Master. This machine account usually isn’t authorized to read encrypted password hashes from Active Directory. The Active Directory object LDAP DN of a privileged replication user should be configured in the Univention Configuration Registry variable connector/ad/ldap/binddn. This must be a member of the Domain Admins group in the AD.

Viel Erfolg,
Dirk Ahrnke[/quote]

Na dass sieht doch mal vielverprechend aus. Vielen Dank !
Werd’s ASAP antesten und hier Rückmeldung geben.

[t.janssen]

[quote=“t.janssen”][quote=“ahrnke”]Hallo,

ich wäre vermutlich ohne Hinweis in diesem Kontext auch nicht auf den SDB-Artikel Speed up LDAP-Binds on AD member mode systems gekommen. Aber da steht eine möglichweise nützliche Anmerkung:

By default, in AD member mode, the UCS AD Connector reads object data from Microsoft Active Directory with the permissions of the machine account of the UCS DC Master. This machine account usually isn’t authorized to read encrypted password hashes from Active Directory. The Active Directory object LDAP DN of a privileged replication user should be configured in the Univention Configuration Registry variable connector/ad/ldap/binddn. This must be a member of the Domain Admins group in the AD.

Viel Erfolg,
Dirk Ahrnke[/quote]

Na dass sieht doch mal vielverprechend aus. Vielen Dank !
Werd’s ASAP antesten und hier Rückmeldung geben.[/quote]

Nope, Vorgehen wie in o.a. SDB-Artikel hat zu keinem Erfolg geführt. Das Setzen des Administrator Account über ‘ucr set connector/ad/ldap/binddn=Administrator’ führte dazu, dass gar keine Attribute mehr synchronisert wurden (Meldung in der connector.log: (ERROR ): Failed to lookup AD LDAP base, using UCR value.). Habe dann den Wert von binddn wieder auf den vollständigen LDAP verweis ‘cn=Administrator,cn=Users…’ gesetzt. Allerdings auf DC des Samba4 ADC. Dann ging es wieder, natürlich bis auf Sync von Passwörtern. Vielleicht doch ein Problem dass die beiden Server als Master unterschiedlicher Domains konfiguriert sind ?

Noch jemand eine Idee ?

[ahrnke]

Der eigentliche Passwortsync wird wahrscheinlich sowieso nicht funktionieren. 9.3.3.3. Einrichtung des Passwort-Dienstes auf dem AD-System beschreibt das für reine Windows-Systeme.
Die einzige Chance, die im führenden “AD” gepseicherten Kennwörtern zu benutzen, wäre Kerberos, also genau wie bei einem Windows-basierten AD ohne Kennwortdienst.

[SirTux]

Hm dieser Windows-Diennst ist doch AFAIK veraltet, der läuft jetzt doch auf dem UCS. Ob der dann mit einem Samba 4 auf der Gegenseite funktioniert, ist eine andere Frage.

[ahrnke]

Hm dieser Windows-Diennst ist doch AFAIK veraltet, der läuft jetzt doch auf dem UCS. Ob der dann mit einem Samba 4 auf der Gegenseite funktioniert, ist eine andere Frage.

Ja, das ist irgendwie nicht ganz klar formuliert.
In der aktuellen Doku steht unter 9.3.3. Einrichtung des UCS AD-Connectors:

In der Standardeinstellung werden Container, Organisationseinheiten, Benutzer und Gruppen synchronisiert. Die Benutzer nehmen eine Sonderstellung ein, da das Passwort in Active Directory nicht über das LDAP-Protokoll abgefragt werden kann. Hierfür wird ein zusätzlicher Dienst auf dem Windows-Server installiert, der diese Passwortsynchronisation ermöglicht (siehe Abschnitt 9.3.3.3).

Die Zöpfe müssen ab – Ablösung des Active Directory Passwortdienstes liest sich ganz anders.
Auch Univention Corporate Server 4.1 erratum 173 (bugfix) und [bug]40745[/bug] suggeriert, dass der Windows-Dienst nicht benötigt wird.

[ahrnke]

Gerade kam der Verweis auf [bug]40911[/bug] rein.
Das hilft uns zwar, zu verstehen, worauf wir nicht mehr achten müssen, das eigentliche Problem dieses Themas bleibt aber bestehen.
Und da fehlt mir gerade die zündende Idee.

[t.janssen]

Tach zusammen !

zunächst mal Danke für die prompten Antworten…
Bin da selbst auch nicht weitergekommen. Ist jedoch rein operativ nicht soooo dramatisch, weil die Mitarbeiter eh’ selten Ihre Passwörter ändern (wollen !!!). Wichtig ist mir, dass die Passwörter für den Zugriff auf die Samba Freigaben geändert werden können, und daß die erweiterten LDAP Attribute für Benutzer und Gruppen gesetzt werden können. Wäre jedoch schon eine tolle Sache, wenn über die UCS Konsole auch gleich die Passwörter auf dem Samba ADC geändert werden könnten. Diese sind für den Zugriff auf unsere ‘Groupware’ (IMAP, SMTP, Adressbücher usw.) notwendig.