Univention Bugzilla – Bug 23917
Posix UID Mapping für Samba4
Last modified: 2011-12-13 15:48:58 CET
Samba4 verwendet aktuell nicht die Posix-ID Zuordnung, die im OpenLDAP definiert ist: root@master:~# wbinfo --name-to-sid "Domain Admins" S-1-5-21-1128718043-107420793-2367769490-512 SID_DOM_GROUP (2) root@master:~# wbinfo --sid-to-uid S-1-5-21-1128718043-107420793-2367769490-512 3000000 Die Mappings sind in /var/lib/samba/private/idmap.ldb definiert: root@master:~# univention-s4search -H /var/lib/samba/private/idmap.ldb objectsid=S-1-5-21-1128718043-107420793-2367769490-512 xidNumber # record 1 dn: CN=S-1-5-21-1128718043-107420793-2367769490-512 xidNumber: 3000000 Diese Posix-ID wird z.B. beim Anlegen von Dateien unter /var/lib/samba/sysvol verwendet.
Aktuell ist dort auch für sehr wenige Benutzern/Gruppen eine Posix-ID definiert: root@master:~# wbinfo --name-to-sid "Domain Users" S-1-5-21-1128718043-107420793-2367769490-513 SID_DOM_GROUP (2) root@master:~# wbinfo --sid-to-uid S-1-5-21-1128718043-107420793-2367769490-513 failed to call wbcSidToUid: WBC_ERR_DOMAIN_NOT_FOUND Could not convert sid S-1-5-21-1128718043-107420793-2367769490-513 to uid
Anscheinend wird die Posix-ID nicht direkt bei der Erzeugung eines Samba4-Benutzers zugewiesen, sondern erst bei einer Anfrage an den internen ID mapper: root@master:~# samba-tool newuser user1 univention User user1 created successfully root@master:~# samba-tool newuser user2 univention User user2 created successfully root@master:~# wbinfo --name-to-sid user1 S-1-5-21-1128718043-107420793-2367769490-1111 SID_USER (1) root@master:~# wbinfo --name-to-sid user2 S-1-5-21-1128718043-107420793-2367769490-1112 SID_USER (1) ## Abfrage in umgedrehter Reihenfolge: root@master:~# wbinfo --sid-to-uid \ S-1-5-21-1128718043-107420793-2367769490-1112 3000001 root@master:~# wbinfo --sid-to-uid \ S-1-5-21-1128718043-107420793-2367769490-1111 3000002
Created attachment 3647 [details] Ein Beispiel-shellscript zum Anpassen der idmap per ldpadd/ldbmodify
Created attachment 3648 [details] Ein Beispiel-shellscript zum Anpassen der idmap per ldpadd/ldbmodify
Zu klären ist noch, ob die objectclass=foreignSecurityPrincipal Objekte unter "CN=WellKnown Security Principals,cn=configuration,$ldap_base" auch mappen muss. Diese werden bis jetzt nicht als Gruppenobjekte in das OpenLDAP-Verzeichnis synchronisiert und haben daher noch keine GID.
Die Einträge in idmap.ldb werden jetzt über das Listener-Modul samba4-idmap gepflegt, wenn die Attribute sambaSID oder uidNumber / gidNumber im UCS LDAP geschrieben werden. Da Samba4 Provision die idmap wieder löscht nachdem das Listener-Modul im univention-samba4.postinst initialisiert worden ist, wurde das Listener-Modul so erweitert, dass man es auch als Skript aufrufen kann, um die Ausgabe von univention-ldapsearch erneut durch den Modul-Handler zu schicken. Dies wird im Joinskript nach dem Provision aufgerufen. Nach Abschluss der Installation von univention-s4-connector stehen jetzt in der idmap weder temporäre SIDs (S-1-4-*) noch von Samba selbst vergebene UIDs/GIDs. Später kann Samba UIDs/GIDs aus dem Bereich 3000000 - 4000000 vergeben, falls es noch keinen Eintrag für eine SID in der idmap gibt. Falls es eine entsprechende in das UCS-LDAP geschrieben wird, korrigiert das Listener-Modul die UID/GID in der idmap auf den Wert im UCS-LDAP. Note: Samba4 vergibt für einige SIDs von foreignSecurityPrincipal-Objekten eigenmächtig PosixIDs aus dem Bereich 3000000 - 4000000. Z.B. für S-1-5-11 CN=Authenticated Users S-1-5-2 CN=Network siehe univention-s4search -b CN=Configuration,$samba4_ldap_base \ objectsid=S-1-5-2 Man sollte im Auge behalten, ob es notwendig ist, auch diese in das UCS-LDAP zu synchronisieren, um ihnen Posix-IDs zu geben, die per nss_ldap auflösbar sind. Dies ist insbesondere dann der Fall, wenn für diese SIDs/PosixIDs Datei-Rechte vergeben werden.
(In reply to comment #6) > Da Samba4 Provision die idmap wieder löscht nachdem das Listener-Modul im > univention-samba4.postinst initialisiert worden ist, wurde das Listener-Modul > so erweitert, dass man es auch als Skript aufrufen kann, um die Ausgabe von > univention-ldapsearch erneut durch den Modul-Handler zu schicken. Dies wird im > Joinskript nach dem Provision aufgerufen. Das sollten wir in zukünftigen Versionen noch etwas weiter einschränken, da das in großen Umgebungen relativ lange dauern kann. Das ist in Bug #24783 ausgelagert.
Created attachment 3853 [details] listener.log Eine im S4 gelöschte Gruppe wird derzeit nicht aus dem idmap entfernt. Die Gruppe ist im UCS LDAP durch den S4 Connector entfernt worden. Im Anhang die listener.log, die sollte das Anlegen und das Löschen der Gruppe (grp1) beinhalten. root@master61:~# ldbsearch -H /var/lib/samba/private/idmap.ldb xidNumber=5038 -d 0 # record 1 dn: CN=S-1-5-21-2192183024-2677559174-2030691912-1142 objectClass: sidMap type: ID_TYPE_GID xidNumber: 5038 cn: S-1-5-21-2192183024-2677559174-2030691912-1142 objectSid: S-1-5-21-2192183024-2677559174-2030691912-1142 distinguishedName: CN=S-1-5-21-2192183024-2677559174-2030691912-1142 # returned 1 records # 1 entries # 0 referrals root@master61:~#
reopen
Der entsprechende Zeig im handler ist jetzt aktiviert.
Funktioniert soweit. In der Listener Log erscheint die folgende Meldung: lpcfg_servicenumber: couldn't find ldb Dazu habe ich Bug #24811 geöffnet.
UCS 3.0-0 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"