Univention Bugzilla – Bug 26693
Gruppe Printer Admins nicht im S4
Last modified: 2017-03-02 13:48:24 CET
Ausgangslage: Benutzer "Administrator" UCS-seitig in der Gruppe "Printer Admins". UCS 3.0 Memberserver mit Cups/S3 in einer S4-Umgebung. Share "/var/lib/samba/drivers": drwsrwsr-x 2 root Printer-Admins 4096 2. Apr 16:33 W32X86 getent group: Printer-Admins:*:5016:Administrator Der Benutzer "Administrator" kann effektiv nicht in den Share schreiben. Sowohl von einem Windows-Client, als auch mit smbclient nicht. /var/log/samba/log.smbd: " [2012/04/02 16:37:05.464022, 5] smbd/uid.c:354(change_to_user) change_to_user uid=(0,2002) gid=(0,5000) [2012/04/02 16:37:05.464078, 5] smbd/filename.c:169(unix_convert) unix_convert called on file "W32X86/fooobar" [2012/04/02 16:37:05.464106, 5] smbd/filename.c:328(unix_convert) unix_convert begin: name = W32X86/fooobar, dirpath = W32X86, start = fooobar [2012/04/02 16:37:05.464194, 5] smbd/filename.c:653(unix_convert) New file fooobar [2012/04/02 16:37:05.464211, 3] smbd/vfs.c:881(check_reduced_name) check_reduced_name [W32X86/fooobar] [/var/lib/samba/drivers] [2012/04/02 16:37:05.464244, 3] smbd/vfs.c:1038(check_reduced_name) check_reduced_name: W32X86/fooobar reduced to /var/lib/samba/drivers/W32X86/fooobar [2012/04/02 16:37:05.464265, 3] smbd/vfs.c:881(check_reduced_name) check_reduced_name [W32X86/fooobar] [/var/lib/samba/drivers] [2012/04/02 16:37:05.464287, 3] smbd/vfs.c:1038(check_reduced_name) check_reduced_name: W32X86/fooobar reduced to /var/lib/samba/drivers/W32X86/fooobar [2012/04/02 16:37:05.464308, 5] smbd/files.c:119(file_new) allocated file structure 12945, fnum = 17041 (1 used) [2012/04/02 16:37:05.464329, 3] smbd/dosmode.c:166(unix_mode) unix_mode(W32X86/fooobar) returning 0744 [2012/04/02 16:37:05.464342, 3] smbd/vfs.c:881(check_reduced_name) check_reduced_name [W32X86/fooobar] [/var/lib/samba/drivers] [2012/04/02 16:37:05.464365, 3] smbd/vfs.c:1038(check_reduced_name) check_reduced_name: W32X86/fooobar reduced to /var/lib/samba/drivers/W32X86/fooobar [2012/04/02 16:37:05.464382, 4] smbd/open.c:2000(open_file_ntcreate) calling open_file with flags=0x2 flags2=0x240 mode=0744, access_mask = 0x12019f, open_access_mask = 0x12019f [2012/04/02 16:37:05.464405, 3] smbd/open.c:477(open_file) Error opening file W32X86/fooobar (NT_STATUS_ACCESS_DENIED) (local_flags=66) (flags=578) [2012/04/02 16:37:05.464423, 5] smbd/files.c:497(file_free) freed files structure 17041 (0 used) [2012/04/02 16:37:05.464440, 3] smbd/error.c:80(error_packet_set) error packet at smbd/error.c(160) cmd=45 (SMBopenX) NT_STATUS_ACCESS_DENIED " LDAP: # Printer-Admins, groups, alien.orig dn: cn=Printer-Admins,cn=groups,dc=alien,dc=orig objectClass: top objectClass: posixGroup objectClass: univentionGroup objectClass: sambaGroupMapping objectClass: univentionObject univentionObjectType: groups/group cn: Printer-Admins sambaSID: S-1-5-32-550 gidNumber: 5016 sambaGroupType: 5 uniqueMember: uid=Administrator,cn=users,dc=alien,dc=orig memberUid: Administrator # record 1 dn: CN=Print Operators,CN=Builtin,DC=alien,DC=orig objectClass: top objectClass: group cn: Print Operators description: Members can administer domain printers instanceType: 4 whenCreated: 20120215111930.0Z uSNCreated: 3568 name: Print Operators objectGUID: 12d9d799-bb89-454b-97bb-5475dc1b4fe0 objectSid: S-1-5-32-550 adminCount: 1 sAMAccountName: Print Operators sAMAccountType: 536870912 systemFlags: -1946157056 groupType: -2147483643 objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=alien,DC=orig isCriticalSystemObject: TRUE whenChanged: 20120402150053.0Z uSNChanged: 3910 distinguishedName: CN=Print Operators,CN=Builtin,DC=alien,DC=orig root@ellen:~# univention-s4search cn="Print Operators" memberof # record 1 dn: CN=Print Operators,CN=Builtin,DC=alien,DC=orig
SambaSID und ObjectSID der beiden Gruppen sind gleich... Passe ich die Berechtigungen im Dateisystem an, so dass "other" schreiben darf, geht es (wie erwartet). Umgebung besteht noch.
In der idmap.ldb ist das Mapping SID<->Posix-ID analog zu dem im UCS LDAP, das ist also korrekt. Ich denke das Problem ist, dass winbind auf dem Memberserver folgende Schritte unternimmt, um die Dateirechte zu prüfen: PosixID im Dateisystem --NSS-LDAP-> Gruppenname Printer-Admins --SAM-Datenbank auf dem DC-> Kein Match. Erstens müsste also der Name in UCS LDAP und Samba4 Verzeichnis gleich sein, damit die Zugriffsrechte korrekt ausgewertet werden, und zweitens werden Mitgliedschaften nicht synchronisiert, weil Gruppenobjekte mit "sambaGroupType: 5" per ignore_filter im S4 Connector mapping ignoriert werden.
Der Versuch, die Gruppe "Printer-Admins" im UCS LDAP ebenfalls in "Print Operators" umzubenennen, hat keine Verbesserung gebracht. Ich nehme jetzt an, dass es hier ein spezielles Verhalten der BUILTIN (oder local) Samba Gruppen Konten gibt. Ein Vergleich mit einer UCS 3.0 Samba3 Domäne zeigt allerdings keinen Unterschied: ================================================== root@s3master:~# wbinfo -n BUILTIN+"Print Operators" S-1-5-32-550 SID_ALIAS (4) root@s3master:~# wbinfo -s S-1-5-32-550 BUILTIN+Print Operators 4 root@s3master:~# wbinfo -Y S-1-5-32-550 5016 root@s3member:~# wbinfo -n BUILTIN+"Print Operators" S-1-5-32-550 SID_ALIAS (4) root@s3member:~# wbinfo -s S-1-5-32-550 BUILTIN+Print Operators 4 root@s3member:~# wbinfo -Y S-1-5-32-550 Could not convert sid S-1-5-32-550 to gid ==================================================
De Benutzer Administrator ist ein spezieller Fall, da dieser explizit in der write list für das 'print$' share steht (/etc/samba/base.conf). Es gibt hier also vermutlich zwei Bugs: 1. Administrator hat auf Memberservern in einer UCS-Samba4-Domäne keinen Schreibzugriff auf die lokale 'print$' Freigabe. 2. Mitglieder der Gruppe Printer-Admins haben generell, auch auf dem UCS 3.0 Samba4 Master keinen Schreibzugriff auf die lokale 'print$' Freigabe. Der zweite Bug betrifft auch Memberserver in Samba3-Domänen, siehe Bug 26712: Dort hat Administrator zwar auf Memberservern Schreibzugriff auf die 'print$' Freigabe, aber Mitglieder der Gruppe Printer-Admins nicht. Da auf einem UCS 3.0 Samba4 Master der smbd auch per security=ads läuft, könnte das das gleiche Problem sein. Note: Im Unterschied zu der Samba3-Domäne hat die LDAP-Gruppe Printer-Admins in der UCS-Samba4-Domäne die gleiche SID wie die BUILTIN Gruppe "Print Operators" (wegen directory/manager/samba3/legacy!=yes). Details zum 1. Bug: =================== root@s4master:/tmp# smbclient //s4master/print\$ -UAdministrator%univention -c 'put testfile' putting file testfile as \testfile (51.9 kb/s) (average 51.9 kb/s) root@member:/tmp# smbclient //member/print\$ -UAdministrator%univention -c 'put testfile' Domain=[ALIEN] OS=[Unix] Server=[Samba 3.5.11] NT_STATUS_ACCESS_DENIED opening remote file \testfile Auf dem Samba4 Master hat Administrator beim Zugriff folgendes Security token: =============================================================== Security token SIDs (15): SID[ 0]: S-1-5-21-3508360685-4114613763-1990273819-500 SID[ 1]: S-1-5-21-3508360685-4114613763-1990273819-512 SID[ 2]: S-1-5-21-3508360685-4114613763-1990273819-572 SID[ 3]: S-1-5-21-3508360685-4114613763-1990273819-520 SID[ 4]: S-1-5-21-3508360685-4114613763-1990273819-518 SID[ 5]: S-1-5-21-3508360685-4114613763-1990273819-513 SID[ 6]: S-1-5-21-3508360685-4114613763-1990273819-11012 SID[ 7]: S-1-5-21-3508360685-4114613763-1990273819-11013 SID[ 8]: S-1-5-21-3508360685-4114613763-1990273819-11015 SID[ 9]: S-1-5-32-544 ## BUILTIN Administrators SID[ 10]: S-1-5-32-550 ## BUILTIN Printer Operators SID[ 11]: S-1-5-32-545 ## BUILTIN Users SID[ 12]: S-1-1-0 SID[ 13]: S-1-5-2 SID[ 14]: S-1-5-11 =============================================================== D.h. die SID der BUILTIN "Print Operators" ist hier ebenso im Security token wir die der "Domain Admins" (Domain RID 512) Auf dem Memberserver erhält der Administrator hingegen folgendes NT token: =============================================================== NT user token of user S-1-5-21-3508360685-4114613763-1990273819-500 contains 22 SIDs SID[ 0]: S-1-5-21-3508360685-4114613763-1990273819-500 SID[ 1]: S-1-5-21-3508360685-4114613763-1990273819-572 SID[ 2]: S-1-1-0 SID[ 3]: S-1-5-2 SID[ 4]: S-1-5-11 SID[ 5]: S-1-5-21-3508360685-4114613763-1990273819-520 SID[ 6]: S-1-5-21-3508360685-4114613763-1990273819-518 SID[ 7]: S-1-5-21-3508360685-4114613763-1990273819-513 SID[ 8]: S-1-5-21-3508360685-4114613763-1990273819-11012 SID[ 9]: S-1-5-21-3508360685-4114613763-1990273819-11013 SID[ 10]: S-1-5-21-3508360685-4114613763-1990273819-11015 SID[ 11]: S-1-22-1-2002 SID[ 12]: S-1-22-2-5032 SID[ 13]: S-1-22-2-55000 SID[ 14]: S-1-22-2-55001 SID[ 15]: S-1-22-2-55002 SID[ 16]: S-1-22-2-5028 SID[ 17]: S-1-22-2-5029 SID[ 18]: S-1-22-2-5001 SID[ 19]: S-1-22-2-5005 SID[ 20]: S-1-22-2-5006 SID[ 21]: S-1-22-2-5007 =============================================================== D.h. hier sind die SIDs der BUILTIN "Print Operators", "Administrators" und "Users" nicht im NT token und auch nicht die der "Domain Admins" (Domain RID 512). Die SIDs mit Prefix S-1-22-2- sind Unix Groups, deren RID Winbind auf die Posix ID mapped. U.a. ist da die GID 5016 der Printer-Admins nicht dabei, selbst wenn man Administrator explizit in diese LDAP-Gruppe einträgt, auch nicht wenn man Printer-Admins im LDAP eine SID S-1-22-2-5016 gibt. Details zum 2. Bug: =================== root@s4master:/tmp# id cheese uid=2044(cheese) gid=5001(Domain Users) Gruppen=5001(Domain Users),5016(Printer-Admins) root@s4master:/tmp# smbclient //s4master/print\$ -Ucheese%univention -c 'put testfile' NT_STATUS_ACCESS_DENIED opening remote file \testfile Auf dem Samba4 Master erhält der Benutzer beim Zugriff folgendes Security token: =============================================================== SID[ 0]: S-1-5-21-3508360685-4114613763-1990273819-11127 SID[ 1]: S-1-5-21-3508360685-4114613763-1990273819-513 SID[ 2]: S-1-5-32-545 ## BUILTIN Users SID[ 3]: S-1-1-0 SID[ 4]: S-1-5-2 SID[ 5]: S-1-5-11 =============================================================== Auf dem Memberserver erhält der Benutzer hingegen folgendes NT token: =============================================================== NT user token of user S-1-5-21-3508360685-4114613763-1990273819-11127 contains 8 SIDs SID[ 0]: S-1-5-21-3508360685-4114613763-1990273819-11127 SID[ 1]: S-1-1-0 SID[ 2]: S-1-5-2 SID[ 3]: S-1-5-11 SID[ 4]: S-1-22-1-2044 SID[ 5]: S-1-22-2-55000 SID[ 6]: S-1-22-2-55001 SID[ 7]: S-1-22-2-55002 =============================================================== D.h. hier ist weder die SID der Printer-Admins noch die SIDs der BUILTIN "Users" und der "Domain Users" (Domain RID 513) im NT token. Die SID der Printer Admins taucht ebenfalls nicht auf wenn man Printer-Admins im LDAP eine SID S-1-22-2-5016 gibt. Analog zum Samba3 Bug 26712 Comment 1 sind die drei 5-stelligen RIDs IDMAP-Artefakte, die vermutlich für diese Bugs keine Rolle spielen.
Note: Für die SIDs von LDAP Gruppe Printer-Admins und BUILTIN "Print Operators" gibt es sehr unterschiedliche Mappings auf die Posix IDs. ============================================= root@s4master:/tmp# wbinfo -Y S-1-5-32-550 5016 ### per samba4-idmap Listener in idmap.ldb gemapped root@s4master:/tmp# wbinfo -Y S-1-22-2-5016 5016 ### Hmm, woher weiss er das? root@s4master:/tmp# wbinfo -Y S-1-22-2-73453465 73453465 ### Ah, er rät.. root@member:/tmp# wbinfo -Y S-1-5-32-550 Could not convert sid S-1-5-32-550 to gid root@member:/tmp# wbinfo -Y S-1-22-2-5016 55004 root@member:/tmp# ldapdelete -D "$ldap_hostdn" -y /etc/machine.secret \ "sambaSID=S-1-22-2-5016,cn=idmap,cn=univention,dc=alien,dc=orig" root@member:/tmp# net cache flush root@member:/tmp# wbinfo -Y S-1-22-2-5016 55005 ============================================= Nachdem Printer-Admins im LDAP manuell die SID S-1-22-2-5016 gegeben wurde, sieht das auf dem Master so aus: ============================================= root@s4master:/tmp# wbinfo -Y S-1-5-32-550 3000005 ### Dynamisch in idmap.ldb alloziert root@s4master:/tmp# wbinfo -Y S-1-22-2-5016 5016 ### Jetzt samba4-idmap Listener in idmap.ldb gemapped =============================================
Note #2: Nur zum Vergleich mit Comment 3: Auf dem Samba4-Master kann wbinfo "Unix Group+Printer-Admins" nicht auflösen. ============================================= root@s4master:/tmp# wbinfo -n BUILTIN+"Print Operators" S-1-5-32-550 SID_ALIAS (4) root@s4master:/tmp# wbinfo -s S-1-5-32-550 BUILTIN+Print Operators 4 root@s4master:/tmp# wbinfo -n "Unix Group+Printer-Admins" failed to call wbcLookupName: WBC_ERR_DOMAIN_NOT_FOUND Could not lookup name Unix Group+Printer-Admins root@s4master:/tmp# wbinfo -s S-1-22-2-5016 failed to call wbcLookupSid: WBC_ERR_DOMAIN_NOT_FOUND Could not lookup sid S-1-22-2-5016 root@member:/tmp# wbinfo -n BUILTIN+"Print Operators" S-1-5-32-550 SID_ALIAS (4) root@member:/tmp# wbinfo -s S-1-5-32-550 BUILTIN+Print Operators 4 root@member:/tmp# wbinfo -n "Unix Group+Printer-Admins" S-1-22-2-5016 SID_DOM_GROUP (2) root@member:/tmp# wbinfo -s S-1-22-2-5016 Unix Group+Printer-Admins 2 ============================================= Auf einem Samba3-Master und -Member ist das problemlos möglich: ============================================= root@s3master:~# wbinfo -n "Unix Group+Printer-Admins" S-1-22-2-5016 SID_DOM_GROUP (2) root@s3master:~# wbinfo -s S-1-22-2-5016 Unix Group+Printer-Admins 2 =============================================
Das Problem entsteht dadurch, dass 1. "Printer-Admins" im UCS LDAP mit der "well known" SID der Windows/Samba BUILTIN Gruppe "Print Operators" angelegt ist. 2. "Printer-Admins" als "sambaGroupType: 5" angelegt wird, also als lokale Gruppe, die durch das mapping des S4 Connectors ignoriert werden. Wenn man die SID auf eine normale Domain-SID ändert und den sambaGroupType auf 4 ändert, dann funktioniert der Zugriff für Mitglieder der Gruppe "Printer-Admins" aus Master und Memberserver der UCS-Samba4-Domäne. Interessanterweise funktioniert dann auf dem Memberserver auch der Zugriff als Administrator wieder.
Aus meiner Sicht sollten wir mit UCS das Mapping von Sambagruppen mit dem Typ 5 im S4 Connector unterstützen. Zusätzlich sollte es dann entweder ein Namesmapping oder ein Mapping auf SID-Ebene geben. Vermutlich muss Printer-Admins dann noch nach Print Operators umbenannt werden. Das sollten wir allerdings erst zu UCS 3.1 machen, da die Änderungen schon deutlich größer für den Administrator sind.
Mit der Samba Version in 3.1 gibt es aktuell noch Probleme im Zusammenspiel mit dem Druckserver. Mit einem UCS 3.0-2 Samba 4 Server (ohne S3 Memberserver) konnte ich problemlos Druckertreiber hochladen.
(In reply to comment #9) > Mit der Samba Version in 3.1 gibt es aktuell noch Probleme im Zusammenspiel mit > dem Druckserver. Das wurde temporär behoben und wird Bestandteil vom nächsten S4 Update sein. > Mit einem UCS 3.0-2 Samba 4 Server (ohne S3 Memberserver) konnte ich problemlos > Druckertreiber hochladen. Durch den Fix konnte ich die Druckertreiber auf ein UCS 3.1 mit Samba 4 hochladen und ich konnte auch das Share direkt bearbeiten. Dann habe ich einen UCS 3.1 Memberserver installiert und gejoint und auch dort konnte ich problemlos Druckertreiber hochladen und das Share modifizieren. WORKSFORME
Für mich funktioniert das noch nicht: 1. Benutzer "user1" angelegt und in Gruppe Printer-Admins aufgenommen 2. Login an Windows7-Client als user1 3. Explorer > Netwerkumgebung > Memberserver [click] 4. In der oberen Menüleiste "Remotedrucker anzeigen" auswählen 5. Rechtsclick auf die freie Fläche "Servereigenschaften...", Problem: Auf Reiter "Teiber" ist "Hinzufügen" ausgegraut. Als Administrator geht das. Gleiches Verhalten auch gegen den Master. Test per smbclient liefert weiterhin einen Zugriffsfehler: root@member:~# smbclient //$(hostname -f)/'print$' -Uuser1%univention Domain=[ARUCS31I5] OS=[Unix] Server=[Samba 3.6.8] smb: \> put /etc/hosts h2 NT_STATUS_ACCESS_DENIED opening remote file \h2 root@member:~# ls -ld /var/lib/samba/drivers drwsrwsr-x 10 root Printer-Admins 4096 30. Okt 16:41 /var/lib/samba/drivers root@member:~# id user1 uid=2013(user1) gid=5001(Domain Users) Gruppen=5001(Domain Users),5016(Printer-Admins) root@member:~# smbclient //$(hostname -f)/'print$' -UAdministrator%univention Domain=[ARUCS31I5] OS=[Unix] Server=[Samba 3.6.8] smb: \> put /etc/hosts h1 putting file /etc/hosts as \h1 (182,4 kb/s) (average 182,4 kb/s)
Das Hinzufügen der Druckertreiber als Administrator funktioniert. Workaround damit es auch für andere Benutzer funktioniert: samba-tool group addmembers "Print Operators" <Benutzer> udm users/user modify --dn <Benutzer-DN> \ --set sambaPrivileges=SePrintOperatorPrivilege Im Moment ist das so OK. Langfristig sollte das vereinheitlicht werden. Vermutlich sollte Printer-Admins nach Print Operators umbenannt und synchronisiert werden. Ggf. reicht es auch aus nur die Gruppenmitglieder zu synchronisieren. Dann ist vermutlich auch die zusätzliche sambaPrivileges Konfiguration nicht notwendig, da Printer-Admins diese Option derzeit schon bekommt. Vermutlich greift sie aber nicht, da Printer-Admins != Print Operators ist.
*** Bug 10544 has been marked as a duplicate of this bug. ***
Mit dem Workaround funktioniert der Treiber-Upload auf dem Samba4-DC als Mitglied der Printer-Admins. Der Upload auf einen UCS-Memberserver scheitert weiterhin an Bug 26712.
(In reply to comment #12) > Das Hinzufügen der Druckertreiber als Administrator funktioniert. Workaround > damit es auch für andere Benutzer funktioniert: > > samba-tool group addmembers "Print Operators" <Benutzer> > > udm users/user modify --dn <Benutzer-DN> \ > --set sambaPrivileges=SePrintOperatorPrivilege Das reicht noch nicht, dann tritt noch Bug #26712 auf. Auf dem Memberserver hilft das: setfacl -R -m u:<Benutzer>:rwx /var/lib/samba/drivers/ setfacl -R -d -m u:<Benutzer>:rwx /var/lib/samba/drivers/
(In reply to comment #15) > (In reply to comment #12) > > Das Hinzufügen der Druckertreiber als Administrator funktioniert. Workaround > > damit es auch für andere Benutzer funktioniert: > > > > samba-tool group addmembers "Print Operators" <Benutzer> > > > > udm users/user modify --dn <Benutzer-DN> \ > > --set sambaPrivileges=SePrintOperatorPrivilege > > Das reicht noch nicht, dann tritt noch Bug #26712 auf. Auf dem Memberserver > hilft das: > > setfacl -R -m u:<Benutzer>:rwx /var/lib/samba/drivers/ > setfacl -R -d -m u:<Benutzer>:rwx /var/lib/samba/drivers/ Im Handbuch ist das Hochladen als Administrator beschrieben. Ich glaube es reicht dann hierzu einen SDB Artikel zu erstellen und zu beschreiben, was man machen muss, damit auch andere Benutzer einen Druckertreiber hochladen können.
This issue has been filed against UCS 3.0. UCS 3.0 is out of maintenance and many UCS components have vastly changed in later releases. Thus, this issue is now being closed. If this issue still occurs in newer UCS versions, please reopen.