Univention Bugzilla – Bug 33642
UCS memberserver IDMAP problems after univention-ad-takeover of German AD
Last modified: 2013-12-17 10:36:52 CET
After doing a univention-ad-takeover of a German AD server, UCS Memberservers in the UCS domain have problems resolving some well known groups that are named differently in Samba4 and UCS LDAP, e.g. "Domänen-Benutzer" vs. "Domain Users". This causes problems when files are copied to the UCS Memberserver, which have ACLs that grant rights to "Domänen-Benutzer". To reproduce this, one can use a Windows-Client to create a folder on the UCS Samba4 DC Master, assign access rights for the German group name and then use robocopy /mir to copy the folder to a share hosted on a UCS memberserver. The original rights on the UCS DC Master where: ============================================================================ root@master:~# smbcacls //localhost/opt3 "Neuer Ordner" -Uadministrator%univentionREVISION:1 CONTROL:SR|SI|DI|DP OWNER:W2K12+win1 GROUP:W2K12+Domänen-Benutzer ACL:W2K12+Domänen-Benutzer:ALLOWED/OI|CI/FULL ACL:W2K12+win1:ALLOWED/I/FULL ACL:CREATOR OWNER:ALLOWED/OI|CI|IO|I/FULL ACL:W2K12+Domänen-Benutzer:ALLOWED/I/READ ACL:CREATOR GROUP:ALLOWED/OI|CI|IO|I/READ ACL:EVERYONE:ALLOWED/OI|CI|I/READ root@master:~# smbcacls //localhost/opt3 "Neuer Ordner" -Uadministrator%univention --sddl O:S-1-5-21-4081652553-1298243908-2397940796-1104G:DUD:AI(A;OICI;0x001f01ff;;;DU)(A;ID;0x001f01ff;;;S-1-5-21-4081652553-1298243908-2397940796-1104)(A;OICIIOID;0x001f01ff;;;CO)(A;ID;0x001200a9;;;DU)(A;OICIIOID;0x001200a9;;;CG)(A;OICIID;0x001200a9;;;WD) root@master:~# getfacl /opt3/Neuer\ Ordner getfacl: Entferne führende '/' von absoluten Pfadnamen # file: opt3/Neuer Ordner # owner: win1 # group: Domänen-Benutzer user::rwx user:win1:rwx group::rwx group:Domänen-Benutzer:rwx mask::rwx other::r-x default:user::rwx default:user:win1:rwx default:group::r-x default:group:Domänen-Benutzer:rwx default:mask::rwx default:other::r-x ============================================================================ The copied folder shows the following rights: ============================================================================ root@member:~# getfacl /opt2/Neuer\ Ordner getfacl: Entferne führende '/' von absoluten Pfadnamen # file: opt2/Neuer Ordner # owner: Administrator # group: Domain\040Admins user::rwx user:Administrator:rwx user:win1:rwx group::r-x group:Domain\040Admins:r-x mask::rwx other::r-x default:user::rwx default:user:Administrator:rwx default:group::r-x default:group:Domain\040Admins:r-x default:mask::rwx default:other::r-x ============================================================================ Note: It's only the mapping of the fACLs that fails here, the NTACLs remain correct. This can be exploited as a workaround: The original fACLs can be restored again by using robocopy to copy the folder back to any Samba4 DC.
Analysis: Accordingly, winbind fails to convert the SID to GID and vice versa: ============================================================================ root@member:~# net rpc testjoin Join to 'W2K12' is OK root@member:~# net cache flush root@member:~# wbinfo -n "Domänen-Benutzer" S-1-5-21-4081652553-1298243908-2397940796-513 SID_DOM_GROUP (2) root@member:~# wbinfo -Y S-1-5-21-4081652553-1298243908-2397940796-513 failed to call wbcSidToGid: WBC_ERR_DOMAIN_NOT_FOUND root@member:~# wbinfo -G 5001 failed to call wbcGidToSid: WBC_ERR_DOMAIN_NOT_FOUND Could not convert gid 5001 to sid ============================================================================ It seems that winbind is confused by the fact that nss-ldap maps gidNumber=5001 to "Domain Users" and that this account name cannot be found in the Samba SAM database on the DC. This assumption is supported by the following quick check: After stopping the S4 Connector on the Master and renaming "Domain Users" to "Domänen-Benutzer" in UDM, wbinfo works again on the Memberserver: ============================================================================ root@member:~# getent group Domänen-Benutzer root@member:~# getent group Domänen-Benutzer root@member:~# getent group Domänen-Benutzer root@member:~# getent group Domänen-Benutzer Domänen-Benutzer:*:5001:Administrator,win2,win3,krbtgt,win1,dns-master root@member:~# wbinfo -G 5001 S-1-5-21-4081652553-1298243908-2397940796-513 root@member:~# wbinfo -Y S-1-5-21-4081652553-1298243908-2397940796-513 5001 ============================================================================ This also fixes the original problem: After removing the folder on the Memberserver and copying it again from the master (via robocopy): ============================================================================ root@member:~# getfacl /opt2/Neuer\ Ordner getfacl: Entferne führende '/' von absoluten Pfadnamen # file: opt2/Neuer Ordner # owner: Administrator # group: Domänen-Benutzer user::rwx user:Administrator:rwx user:win1:rwx group::rwx group:Domänen-Benutzer:rwx mask::rwx other::r-x default:user::rwx default:user:Administrator:rwx default:group::r-x default:group:Domänen-Benutzer:rwx default:mask::rwx default:other::r-x ============================================================================
Looks like the issue can also be resolved by renaming+moving the group object in Samba4: =============================================================================== root@master:~# /etc/init.d/univention-s4-connector stop Stopping univention-s4-connector daemon. done. root@master:~# ldbrename -H /var/lib/samba/private/sam.ldb \ CN=Domänen-Benutzer,CN=Users,DC=w2k12,DC=test "CN=Domain Users,CN=Users,DC=w2k12,DC=test" Renamed 1 record root@master:~# echo -e "dn: CN=Domain Users,CN=Users,DC=w2k12,DC=test changetype: modify\nreplace: sAMAccountName\nsAMAccountName: Domain Users" \ | ldbmodify -H /var/lib/samba/private/sam.ldb Modified 1 records successfully root@master:~# ucr unset "connector/s4/mapping/group/table/Domain Users" Unsetting connector/s4/mapping/group/table/Domain Users root@master:~# /etc/init.d/univention-s4-connector start Starting univention-s4-connector daemon. done. =============================================================================== Not sure if this can be done this cleanly though (it was a bit more messy to obtain the desired final result than suggested by the steps above...). But I think this might be the easiest way to get this fixed.
The futuristic solution on the other hand would be to store the Posix-IDs in the Samba4 SAM database and configure the source3/winbind on the UCS Memberserver to use idmap_ad to look them up from there. "I have a dream..." :-)
The original issue was Ticket#: 2013120221002266
Can this bug be closed as duplicate of Bug #33644?
*** This bug has been marked as a duplicate of bug 33644 ***