Univention Bugzilla – Bug 26569
Eindeutigkeit von Samba4 Konten beim Anlegen auf Slave gegen ldap/master prüfen
Last modified: 2012-06-11 06:29:39 CEST
Bei Anlegen von Rechner und Benutzerkonten im Samba4-Verzeichnis auf UCS@School Standort-Slaves sollte sichergestellt werden, dass das Konto nicht im LDAP-Verzeichnis auf dem ldap/master existiert. Ein Samba4 LDB-Modul könnte das prüfen. Vermutlich ist dafür ein neues LDB-Control notwendig, das der S4-Connector verwenden kann, um den Check zu umgehen.
Es gibt jetzt im Scope ucs_3.0-0-ucsschool ein Quellpaket univention-ldb-modules, aus dem ein Paket libunivention-ldb-modules gebaut wird, das ein entsprechendes LDB-Modul "univention_samaccountname_ldap_check" installiert. Im Joinscript des Pakets ist ein generischer Mechanismus zur LDB-Modulregistrierung implementiert, der aus der UCR-Variable samba4/ldb/module/prepend ausliest, welche Module zusätzlich am sam.ldb Backend registriert werden sollen. Diese Variable wird um Joinscript von ucs-school-slave entsprechend gesetzt. Falls das neue LDB-Modul an sam.ldb registriert ist, dann geht jeder ldb-Zugriff zusätzlich durch das Modul, das bei ldb_add und ldb_modify Operationen auf das "samAccountName" Attribut den Wert gegen die "uid"-Attribute des ldap/master prüft. Falls der neue Wert im ldap/master gefunden wird, oder die LDAP-Abfrage generell scheitert, wird die LDB-Transaktion mit einem "already exists" Fehler abgebrochen. In den Tests funktionierte das auch bei Zugriff über LDAPI, die DRS-Replikation wurde in den Tests hingegen nicht davon beeinflusst. Wird bei der LDB-Operation das Control "permissive_modify" übergeben, dann wird der LDAP-Test nicht durchgeführt. Es ist noch zu klären, ob dies Control nicht anderweitig von Samba4 interpretiert wird und es sinnvoller wäre, ein neues zu definieren. Solange der univention-s4-connector das entsprechende Control noch nicht übergibt, ist es nicht sinnvoll das Modul im ucs-school Kontext zu aktivieren. Daher wird im Joinscript von libunivention-ldb-modules aktuell für die Testphase eine UCR-Variable samba4/ldb/sam/module/test geprüft. Das Joinscript bricht ab, wenn diese nicht manuell aktiviert wurde.
Statt permissive_modify wird jetzt das neue LDB-Control 'bypass_samaccountname_ldap_check' verwendet, das im Scope ucsschool durch Patches gegen ldb und samba4 definiert wurde.
In dem Modul sollte per Default das Anlegen von Benutzern und Gruppen verhindert werden.
Aktuell bricht der Join Vorgang auf dem DC Slave ab: [...] Configure 90univention-bind-post.inst done Configure 96univention-samba4.inst done Configure 97libunivention-ldb-modules.inst failed Aus der Logdatei: Configure 97libunivention-ldb-modules.inst == skipping joinscript, set samba4/ldb/sam/module/test=yes for testing ==
Das Modul wurde wie folgt angepasst, Tests stehen noch aus: * Anlegen von user und group Objekten wird mit LDB-Fehlermeldung und Rückgabestatus LDB_ERR_UNWILLING_TO_PERFORM abgebrochen. * umc-command create_windows_computer wird aufgerufen * Falls umc-command einen Rückgabewert != 0 zurückliefert wird Das Anlegen eines Computers mit LDB_ERR_ENTRY_ALREADY_EXISTS abgebrochen * Modify-Operationen prüft das LDB-Modul aktuell nicht mehr * Check auf samba4/ldb/sam/module/test wurde entfernt
Tests waren soweit erfolgreich. TODO: Hier und im umc-command Modul noch eine Option zur Unterscheidung von samba4 und samba3 eingebaut werden.
Beim Joinen eines Windows 7 DCs bekomme ich aktuell diese Meldung in lo.samba: [2012/03/13 07:53:02.969979, 2, pid=1875] ../source3/smbd/sesssetup.c:1261(setup_new_vc_session) setup_new_vc_session: New VC == 0, if NT4.x compatible we would close all old resources. [2012/03/13 07:53:03.641625, 2, pid=1875] ../source3/smbd/uid.c:180(check_user_ok) check_user_ok: user DEDLOCK10+Administrator is an admin user. Setting uid as 0 [2012/03/13 07:53:11, 1] ../lib/ldb-samba/ldb_wrap.c:68(ldb_wrap_debug) ldb: univention_samaccountname_ldap_check: ldb_add of computer object without unicodePwd [2012/03/13 07:53:11, 0] ../source4/dsdb/common/util_samr.c:185(dsdb_add_user) Failed to create user record CN=WIN7771,CN=Computers,DC=dedlock10,DC=local: Unwilling to perform (53) [2012/03/13 07:53:26.633008, 1, pid=1875] ../source3/smbd/process.c:463(receive_smb_talloc) read_smb_length_return_keepalive failed for client ipv4:10.201.77.1:59727 read error = NT_STATUS_CONNECTION_RESET.
Hmm, Win7 hatte in meinem Test direkt ein Passwort mitgeschickt. Sonst muss man diesen Test auf das unicodePwd ggf. rausnehmen, es nicht an das umc-command übergeben und im UMC-Modul den Account ohne Passwort anlegen? Wenn das vom UMC/UDM-Modul her geht, müsste sich im Connector dann ja die Race-Condition entscheiden lassen können?
Falls das unicodePwd beim initialen LDB add fehlt gibt das Modul jetzt eine Warnung aus und ruft umc-command dann ohne "-o password" auf.
(In reply to comment #9) > Falls das unicodePwd beim initialen LDB add fehlt gibt das Modul jetzt eine > Warnung aus und ruft umc-command dann ohne "-o password" auf. Das Joinen hat bei mir funktioniert, allerdings wurde mir nach dem nächsten Boot angezeigt, dass das System kein gültiges Konto in der Domäne hat (Test mit Windows 2008 R2).
Auslöser scheint zu sein, dass manche Windows Clients nicht direkt beim Join ein Passwort mit angeben. Beim Join von XP Clients z.B. wird erst im LDB-Backend der Account ohne Passwort angelegt und erst in nachfolgenden modify Operationen (per clearTextPassword Attribut) gesetzt. Der S4 Connector bekam in diesen Fällen die Änderung in UCS früher mit als die in S4 und in sync_ucs_to_s4 wurde dann festgestellt, dass das sambaNTPassword (leer) nicht mit dem unicodePwd übereinstimmt. Für diesen Spezialfall habe ich jetzt im S4 Connector eine Prüfung eingebaut, ob wenigstens sambaPwdLastSet gesetzt ist, wenn schon nicht sambaNTPassword. Falls beides fehlt, dann wird unicodePwd nicht angefasst (und auch nicht supplementalCredentials). Characteristisch an dieser Situation ist, dass beim Client Join mit samba/debug/level=4 in log.samba folgende Meldung auftaucht: ldb: univention_samaccountname_ldap_check: new computer object without initial unicodePwd
Ist jetzt auch in ucs3.0-2 eingebaut. Zum Debugging habe ich in libunivention-ldb-modules ein weiteres Modul "univention_ldb_log" aufgenommen, das man bei Bedarf an ldb-Dateien registrieren kann, um protokollieren zu lassen, welche add/modify/delete Operationen vorgenommen werden. Das Logging erfolgt erstmal schlicht in die Datei /tmp/univention_ldb_log_module.log. Das Modul ist definitiv nicht für den produktiven Einsatz gedacht, insbesondere lässt es sicherheitstechnisch zu Wünschen.
Kein Eintrag im Changelog! Auf dem DC Slave wird über ucs-school-slave samba4/ldb/sam/module/prepend="univention_samaccountname_ldap_check" gesetzt. Im Join Skript libunivention-ldb-modules.inst wird dies ausgewertet und das LDB Modul aktiviert. Join und Anmeldung gegen S4 Schul DC klappt mit w2k8R2 (64), win7 (64) und winxp. Anlegen von Gruppen und Benutzer wird verhindert (samba-tool, Windows AD Tools). Es gab noch eine kleine Sache mit Rechneraccounts, aber das wird in Bug #27170 behandelt.
Im Changelog zu UCS 3.0-2 gibt es jetzt auch einen Hinweis auf diese Anpassung: \item NT hashes and Kerberos keys in the Samba 4 directory are only changed if the corresponding UCS object provides an NT hash or at least a sambaPwdLastSet timestamp (\ucsBug{26569}).
(In reply to comment #14) > Im Changelog zu UCS 3.0-2 gibt es jetzt auch einen Hinweis auf diese Anpassung: > > \item NT hashes and Kerberos keys in the Samba 4 directory are only changed if > the corresponding UCS object provides an NT hash or at least a sambaPwdLastSet > timestamp (\ucsBug{26569}). Bitte auch in das UCS@school Changelog übernehmen.
UCS@School Changelog ist angepasst.
UCS@school 3.0 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS@school erneut auftreten, so sollte dieser Bug dupliziert werden: "Clone This Bug"