Univention Bugzilla – Bug 29712
Unzugeordnete Posix-IDs und Samba-SIDs in den Sysvol-ACLs
Last modified: 2023-03-25 06:55:10 CET
Während mit Samba4-RC6 die GPO-Bearbeitung deutlich besser funktioniert und die Auswertung auch weiterhin funktioniert, sahen die POSIX-fACLs nach den Produkttests beispielsweise wie folgt aus: root@master20:~# getfacl /var/lib/samba/sysvol/arucs31i20.qa/Policies getfacl: Entferne führende '/' von absoluten Pfadnamen # file: var/lib/samba/sysvol/arucs31i20.qa/Policies # owner: root # group: 3000000 user::rwx user:root:rwx group::rwx group:Authenticated\040Users:r-x group:3000000:rwx group:3000001:r-x group:3000002:rwx group:3000003:r-x group:3000012:rwx mask::rwx other::--- default:user::rwx default:user:root:rwx default:group::--- default:group:Authenticated\040Users:r-x default:group:3000000:rwx default:group:3000001:r-x default:group:3000002:rwx default:group:3000003:r-x default:group:3000012:rwx default:mask::rwx default:other::--- Diese nicht gemapped'ten Posix-IDs stehen nicht in idmap.ldb (daher auch "nicht gemapped"), und Samba schreibt dafür auch passende SIDs in die NTACL: root@master20:~# samba-tool ntacl get --as-sddl /var/lib/samba/sysvol/arucs31i20.qa/Policies WARNING: No path in service IPC$ - making it unavailable! NOTE: Service IPC$ is flagged unavailable. O:LAG:S-1-22-2-3000000D:(A;OICI;0x001f01ff;;;S-1-22-2-3000012)(A;OICI;0x001200a9;;;S-1-22-2-3000003)(A;OICI;0x001f01ff;;;SY)(A;OICI;0x001200a9;;;S-1-22-2-3000001)(A;OICI;0x001f01ff;;;S-1-22-2-3000000)(A;OICI;0x001200a9;;;AU)(A;OICI;0x001f01ff;;;S-1-22-1-0)(A;OICI;;;;WD)(A;;0x001f01ff;;;LA)(A;;0x001f01ff;;;S-1-22-2-3000000)(A;OICIIO;0x001f01ff;;;CO)(A;OICIIO;;;;CG) Durch Aufruf von samba-tool ntacl sysvolreset ändern sich die fACLs und ntacl etwas, aber die von Samba eigenhändig vergebenen POSIX-IDs verbleiben an einigen Stellen. Logs hängen unten an. Leider lässt sich z.B. aus dem listner.log auf dem Master nicht mehr rekonstruieren, welche dieser Posix-IDs temporär zu welcher SID gehört hat. Einem Diff der fACLs nach zu urteilen ist vermutlich * 3000000: Administrators (S-1-5-32-544) * 3000001 oder 3000003: System Operators (S-1-5-32-549) * 3000012: Group Policy Creator Owners (DOMSID-520) In idmap.ldb findet man im Moment nur noch Posix-IDs für die SIDs, die nicht in OpenLDAP abgebildet sind: * 3000002: System (S-1-5-18) * 3000010: "Enterprise domain controllers" (S-1-5-9) * 3000014: "Network" (S-1-5-2) Es wäre hier in erster Iteration sinnvoll herauszufinden, wodurch die Zuordung dieser Posix-IDs verloren gegangen ist. Falls es das samba4-idmap Listener-Modul war, sollte sichergestellt werden, dass es im listener.log vollstänsig protokolliert, wenn es IDMAP-Einträge modifiziert, ggf. tut es das bei --direct-resync nicht. Prinzipiell darf das samba4-idmap Listner-Modul eigentlich nicht Posix-IDs aus der idmap.ldb umschreiben, weil es sein kann, dass diese z.B. schon im Dateisystem hinterlegt sind. Aktuell tut es das aber. Ggf. würde es ein bisschen was bringen, wenn der Aufruf von "samba4-idmap.py --direct-resync" im univention-samba4 Joinscript vor dem "ntacl sysvolreset" durchgeführt wird. Müsste man testen.
Created attachment 4901 [details] fACLS und NTACLs nach den Produkttests und vor ntacl sysvolreset
Created attachment 4902 [details] fACLS und NTACLs nach ntacl sysvolreset
Nach dem sysvolreset sieht das obige Beispiel so aus: # file: var/lib/samba/sysvol/arucs31i20.qa/Policies # owner: Administrator # group: Administrators user::rwx user:Administrator:rwx group::rwx group:Administrators:rwx group:System\040Operators:r-x group:Authenticated\040Users:r-x group:Group\040Policy\040Creator\040Owners:rwx group:3000002:rwx mask::rwx other::--- default:user::rwx default:user:Administrator:rwx default:group::--- default:group:Administrators:rwx default:group:System\040Operators:r-x default:group:Authenticated\040Users:r-x default:group:Group\040Policy\040Creator\040Owners:rwx default:group:3000002:rwx default:mask::rwx default:other::--- # File: /var/lib/samba/sysvol/arucs31i20.qa/Policies O:LAG:BAD:P(A;OICI;0x001f01ff;;;BA)(A;OICI;0x001200a9;;;SO)(A;OICI;0x001f01ff;;;SY)(A;OICI;0x001200a9;;;AU)(A;OICI;0x001301bf;;;PA)
Created attachment 4903 [details] fACLS und NTACLs nach anlegen einer neuen GPO Die angehängten ACLs sind von einer frisch angelegten GPO bei abgeschaltetem sysvol-sync (/etc/cron.d/sysvol-sync per Kommentarzeicheichen deaktivert, alle anderen DCs sind suspendiert). Man sieht dort, dass das GPO-GUID-Basisverzeichnis als Owner "5000" hat, was der Gruppe "Domain Admins" entspricht. D.h. dass mein Patch für Bug 28737 mit RC6 nicht mehr vollständig ausreicht. Eigentlich sollte da dann in den Posix-ACLs als Besitzer "root" stehen. Der Rest sieht OK aus. Die PosixIDs 3000002 ("System") und 3000010 ("Enterprise domain controllers") sind nur lokal per idmap.ldb gemapped, das ist Bug 29000.
Created attachment 4907 [details] Inhalt der idmap.ldb am Ende des 96univention-samba4 Joinscripts Die temporär beim Join von Samba4-RC6 vergebenen Posix-IDs sind dementsprechend wie folgt: * 3000000: Administrators (S-1-5-32-544) ## wird auch in base.ldif angelegt * 3000001: System Operators (S-1-5-32-549) ## wird auch in base.ldif angelegt * 3000002: Local System (S-1-5-18) * 3000003: Authenticated Users (S-1-5-11) ## wird auch in base.ldif angelegt * 3000004: Group Policy Creator Owners (DOMSID-520) ## siehe unten * 3000005: Denied RODC Password Replication Group (DOMSID-572) ## siehe unten * 3000006: Enterprise Admins (DOMSID-519) ## wird auch in base.ldif angelegt * 3000007: Schema Admins (DOMSID-518) ## siehe unten * 3000008: Domain Admins (DOMSID-512) ## wird auch in base.ldif angelegt * 3000009: Users (S-1-5-32-545) ## wird auch in base.ldif angelegt * 3000010: Enterprise Domain Controllers (S-1-5-9) * 3000011: Guest (DOMSID-501) * 3000012: Domain Guests (DOMSID-514) ## wird auch in base.ldif angelegt * 3000013: Everyone (S-1-1-0) ## wird auch in base.ldif angelegt * 3000014: Network (S-1-5-2) * 3000015: Guests (S-1-5-32-546) ## wird auch in base.ldif angelegt Die Gruppen "Group Policy Creator Owners", "Denied RODC Password Replication Group" und "Schema Admins" werden zur Zeit von 97univention-s4-connector.inst im UDM mit einer beliebigen DomänenSID angelegt und scheinen dann per S4 Connector auf die Well Known SID aus dem Samba4-Verzeichnis umgeschrieben zu werden. Vielleicht kommt also das "samba-tool ntacl sysvolreset" in 98univention-samba4-dns.inst einfach noch zu früh bevor der S4 Connector die SIDs abgeglichen hat und der samba4-idmap Listener diese mit den korrekten UIDs in die idmap.ldb eingetragen hat. Daraus ergeben sich für mich hier folgende Verbesserungsvorschläge: * Die per 97univention-s4-connector.inst angelegten Gruppen sollten direkt mit der richtigen Well Known SID angelegt werden (um den S4-Connector rewrite und den dadurch entstehenden Delay/Race zu vermeiden) * Vor dem finalen "samba-tool ntacl sysvolreset" in 98univention-samba4-dns.inst sollte vielleicht nochmal samba4-idmap.py --direct-resync aufgerufen werden (um den Delay durch den Listener zu vermeiden). * Der samba4-idmap-Listener sollte die Posix-IDs, der Einträge, die der umschreibt in die Logdatei mit ausgeben (zum Debugging). * Zusätzlich könnte die in Comment 4 festgestellte RC6-Regression des Patches für Bug 28737 behoben werden, um Privileg-Eskalationen durch überschneidende Gruppen und Benutzer-IDs vorzubeugen.
1. The main issue here has been fixed via Bug 29486 and Bug 32768, see also SDB article Bug 32863. 2. Debugging Ticket#201301312100075 showed that the GPOs with an NTACL owner group of "BA" (Builtin Administrators), aka "Administrators" did not have a representation in the Samba/AD LDAP any more. Don't know if this a general rule. 3. A correction to the statement of Comment 4: > Eigentlich sollte da dann in den Posix-ACLs als Besitzer "root" stehen. This is not completely correct, see Bug 41319 for an explanation. *** This bug has been marked as a duplicate of bug 29486 ***
OK