Univention Bugzilla – Bug 26005
objectSid im S4 Connector beim Hinzufügen von Objekten in Samba setzen
Last modified: 2012-03-04 14:34:35 CET
Der S4 Connector sollte beim Schreiben von neuen Objekten in das Samba4-Verzeichnis die sambaSID aus OpenLDAP umkodieren in das Binärformat der objectSid um sie direkt beim Anlegen eines Objekts vorgeben zu können.
Created attachment 4140 [details] add_objectSid.patch für den univention-s4-connector
Created attachment 4141 [details] Python-Skript zum Modifizieren der objectSid per ldap.modify_s Im aktuell verwendeten Mapping wird sid_to_s4 als post_con_modify_function verwendet, aber die Funktion sid_to_s4 macht derzeit nichts. Mit dem angehängten Skript kann man die objectSid im Samba4-Verzeichnis über LDAPI ändern. Damit das über LDAPI möglich ist (und nicht nur per ldbmodify gegen sam.ldb), ist ein Patch für Samba4 notwendig, angehängt im folgenden Kommentar.
Created attachment 4142 [details] Patch für Samba4 ldb_controls.c Der Patch exponiert das notwendige "provision" Control zusätzlich für das LDAPI-Interface. In Tests war es auch mit dem Patch weiterhin nicht möglich, dieses Control über das Netzwerk (LDAP-Interface) an Samba zu übergeben, sodass hier keine Sicherheitslücke geöffnet wird. Mit dem Control sollte man extrem vorsichtig sein, was für Daten man Samba übergibt. Das Control lockert die validerungs-Checks. In einem Test konnte ich damit einen falsch kodierten ObjectSid-Wert an ein Benutzerobjekt schreiben, aber danach nicht mehr korrigieren oder gar das Objekt löschen.
Created attachment 4146 [details] sid_to_s4.patch Der angehängte Patch implementiert die Änderung der objectSid in der sid_to_s4 Funktion. Sicherheitshalber wird ndr_pack statt encode_sid/encode_object_sid verwendet.
Jetzt fehlt hier noch eine Konfigurationsmöglichkeit per UCR um bei der Synchronisation von Samba4 nach OpenLDAP die objectSid herauszufiltern, damit sie nicht an UDM übergeben wird. Damit hat UDM die Chance, bei neuen Objekten eine eigene SID zu vergeben (die dann wieder per sid_to_s4 in Samba4 gesetzt wird). Diese Anpassung sorgt unter günstigen Umständen dafür, dass man am UCS@School Aussenstandort Rechner joinen kann, analog zu dem Verhalten von samba-slave-pdc. Möglicherweise ist auch hier ein ldap/replication/sleep notwendig.
Die Samba4-Erweiterung aus Comment 3 istjetzt als Bug #26051 abgespalten.
(In reply to comment #1) > Created an attachment (id=4140) [details] > add_objectSid.patch für den univention-s4-connector Das ist ausgelagert an Bug #26055.
Das ist umgesetzt. Mit connector/s4/mapping/sid_to_ucs kann konfiguriert werden, ob die SID von Samba 4 nach UCS geschrieben werden soll (default: true) und mit connector/s4/mapping/sid_to_s4 kann konfiguriert werden, ob die SID von UCS nach Samba 4 geschrieben werden soll (default: false).
Bei Änderungen in Samba4 wird in UCS die SID am Objekt anscheinend immer gesetzt (obwohl diese nicht geändert wurde). ... sid_to_s4: UCS DN uid=aaa,dc=as,dc=df sid_to_ucs: objectSid found: [u'S-1-5-21-2552508822-3878602903-2957377927-1118'] sid_to_ucs: modlist = [('sambaSID', ['S-1-5-21-2552508822-3878602903-2957377927-1118'], u'S-1-5-21-2552508822-3878602903-2957377927-1118')] Call post_ucs_modify_functions: <function sid_to_ucs at 0x32d7a28> (done) Call post_ucs_modify_functions: <function password_sync_s4_to_ucs at 0x32d77d0> In der Modlist steht hier einmal ['S-1-5-21-2552508822-3878602903-2957377927-1118'] und einmal u'S-1-5-21-2552508822-3878602903-2957377927-1118'
Mit 6.0.102-1 sollte das Problem behoben sein.
----------------------------------------------------------------------------- OK - sid_to_ucs: # keine Synchr. von S4 nach UCS -> ucr set connector/s4/mapping/sid_to_ucs=no -> samba-tool user add samba3 univention -> univention-s4search cn=samba3 objectSid| grep Sid objectSid: S-1-5-21-2552508822-3878602903-2957377927-1212 -> univention-ldapsearch uid=samba3 sambaSID -LLL| grep SID sambaSID: S-1-4-2074 # Synchr. von S4 nach UCS -> ucr unset connector/s4/mapping/sid_to_ucs -> univention-s4search cn=samba4 objectSid| grep Sid objectSid: S-1-5-21-2552508822-3878602903-2957377927-1213 -> univention-ldapsearch uid=samba4 sambaSID -LLL| grep SID sambaSID: S-1-5-21-2552508822-3878602903-2957377927-1213 ----------------------------------------------------------------------------- sid_to_s4 # Connector gestoppt, einen Benutzer auf UCS angelegt, händisch eigene # SID vergeben -> /etc/init.d/univention-s4-connector stop -> udm users/user create --set password=univention --set lastname=test \ --set username=ucs2 Object created: uid=ucs2,dc=as,dc=df -> more /opt/ldif.ldif dn: uid=ucs2,dc=as,dc=df changetype: modify replace: sambaSID sambaSID: S-1-5-21-2552508822-3878602903-2957377927-9999 ldapmodify -D "cn=admin,$(ucr get ldap/base)" -w $(< /etc/ldap.secret) -f /opt/ldif.ldif -> /etc/init.d/univention-s4-connector start sync from ucs: [ user] [ modify] cn=ucs2,dc=as,dc=df get_object: got object: CN=ucs2,DC=as,DC=df encode_s4_object: attrib objectGUID ignored during encoding sync_from_ucs: modify object: cn=ucs2,dc=as,dc=df Call post_con_modify_functions: <function sid_to_s4 at 0x25959b0> sid_to_s4 object: {'dn': u'cn=ucs2,dc=as,dc=df', 'attributes': {u'uid': [u'ucs2'], ...u'sambaSID': [u'S-1-5-21-2552508822-3878602903-2957377927-9999'],... sid_to_s4: changing objectSid from S-1-4-2077 to S-1-5-21-2552508822-3878602903-2957377927-9999 Call post_con_modify_functions: <function sid_to_s4 at 0x25959b0> (done) -> univention-s4search cn=ucs2| grep Sid objectSid: S-1-5-21-2552508822-3878602903-2957377927-9999 -> univention-ldapsearch uid=ucs2| grep SID sambaSID: S-1-5-21-2552508822-3878602903-2957377927-9999 # nochmal mit einer UDM SID -> ucr set directory/manager/samba3/legacy=yes -> ucr set connector/s4/mapping/sid_to_ucs=no -> ucr set connector/s4/mapping/sid_to_s4=yes -> udm users/user create --set password=univention --set lastname=test \ --set username=ucs3 sync from ucs: [ user] [ add] cn=ucs3,dc=as,dc=df sync_from_ucs: add object: cn=ucs3,dc=as,dc=df to modify: cn=ucs3,dc=as,dc=df Call post_con_modify_functions: <function sid_to_s4 at 0x1b879b0> sid_to_s4 object: {'dn': u'cn=ucs3,dc=as,dc=df', 'attributes': {u'uid': [u'ucs3'], u'sambaSID': [u'S-1-5-21-2552508822-3878602903-2957377927-5156'],... sid_to_s4: changing objectSid from S-1-5-21-2552508822-3878602903-2957377927-1216 to S-1-5-21-2552508822-3878602903-2957377927-5156 Call post_con_modify_functions: <function sid_to_s4 at 0x1b879b0> (done) -> univention-ldapsearch uid=ucs3| grep aSID sambaSID: S-1-5-21-2552508822-3878602903-2957377927-5156 -> univention-s4search cn=ucs3| grep Sid objectSid: S-1-5-21-2552508822-3878602903-2957377927-5156 Getestet mit users/user, groups/group, computer/windows (computers/windows_domaincontroller wird noch nicht synchronisiert) ----------------------------------------------------------------------------- (In reply to comment #9) > Bei Änderungen in Samba4 wird in UCS die SID am Objekt anscheinend immer > gesetzt (obwohl diese nicht geändert wurde). > > ... > sid_to_s4: UCS DN uid=aaa,dc=as,dc=df > sid_to_ucs: objectSid found: > [u'S-1-5-21-2552508822-3878602903-2957377927-1118'] > sid_to_ucs: modlist = [('sambaSID', > ['S-1-5-21-2552508822-3878602903-2957377927-1118'], > u'S-1-5-21-2552508822-3878602903-2957377927-1118')] > Call post_ucs_modify_functions: <function sid_to_ucs at 0x32d7a28> (done) > Call post_ucs_modify_functions: <function password_sync_s4_to_ucs at > 0x32d77d0> > > In der Modlist steht hier einmal > > ['S-1-5-21-2552508822-3878602903-2957377927-1118'] > > und einmal > > u'S-1-5-21-2552508822-3878602903-2957377927-1118' OK, der Connector erkennt nun, dass sich die SID nicht geändert hat. 20.02.2012 11:42:31,512 LDAP (INFO ): sid_to_s4: objectSid and sambaSID are equal 20.02.2012 11:42:31,513 LDAP (INFO ): Call post_con_modify_functions: <function sid_to_s4 at 0x1b879b0> (done) Changelog Eintrag vorhanden.
UCS 3.0-1 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS erneut auftreten, so sollte dieser Bug dupliziert werden: "Clone This Bug"