Univention Bugzilla – Bug 45840
Memberservers allocate different PosixIDs for Samba NT AUTHORITY SIDs
Last modified: 2021-07-15 19:23:12 CEST
When UCS Memberserver look up a Posix ID for a builtin SambaSID, they don't find it via the NSS Idmap backend, so winbind allocates Posix ID in OpenLDAP. This is not so cool in Samba/AD domains, because the Samba/AD DCs don't see this information. ========================================================================= root@member-42-14:~# univention-ldapsearch -LLL objectClass=sambaSidEntry dn: sambaSID=S-1-1-0,cn=idmap,cn=univention,dc=nvsx,dc=local objectClass: sambaIdmapEntry objectClass: sambaSidEntry gidNumber: 55000 sambaSID: S-1-1-0 dn: sambaSID=S-1-5-2,cn=idmap,cn=univention,dc=nvsx,dc=local objectClass: sambaIdmapEntry objectClass: sambaSidEntry gidNumber: 55001 sambaSID: S-1-5-2 dn: sambaSID=S-1-5-11,cn=idmap,cn=univention,dc=nvsx,dc=local objectClass: sambaIdmapEntry objectClass: sambaSidEntry gidNumber: 55002 sambaSID: S-1-5-11 dn: sambaSID=S-1-5-18,cn=idmap,cn=univention,dc=nvsx,dc=local objectClass: sambaIdmapEntry objectClass: sambaSidEntry gidNumber: 55003 sambaSID: S-1-5-18 root@member-42-14:~# wbinfo --sid-to-gid S-1-5-18 55003 root@member-42-14:~# ========================================================================= ========================================================================= root@master-42-10:~# ldbsearch -H /var/lib/samba/private/idmap.ldb objectSid=S-1-5-18 # record 1 dn: CN=S-1-5-18 cn: S-1-5-18 objectClass: sidMap objectSid: S-1-5-18 type: ID_TYPE_BOTH xidNumber: 5036 distinguishedName: CN=S-1-5-18 # returned 1 records # 1 entries # 0 referrals root@master-42-10:~# wbinfo --sid-to-gid S-1-5-18 5036 root@master-42-10:~# ========================================================================= This can be solved by fixing Bug 32268 and configuring univention-samba IDmap to use the idmap_ad backend.
https://forge.univention.org/bugzilla/show_bug.cgi?id=33370#c4 could be a workaround.
I tested with UCS 4.2-2 errata184 and the "NT AUTHORITY" hack from Bug 33370 did not work (any more). Without that we cannot configure winbind to use any useful idmap backend for this special domain.
Seen again in Ticket# 2018041221000737 and also in internal domain: ===================================================================== # Authenticated Users, Builtin, domain.local dn: cn=Authenticated Users,cn=Builtin,dc=domain,dc=local ownCloudEnabled: 1 cn: Authenticated Users objectClass: ownCloudGroup objectClass: sambaGroupMapping objectClass: top objectClass: univentionGroup objectClass: maildisclaimer objectClass: univentionObject objectClass: posixGroup objectClass: oxGroup isOxGroup: OK uniqueMember: cn=DC Slave Hosts,cn=groups,dc=domain,dc=local uniqueMember: cn=Windows Hosts,cn=groups,dc=domain,dc=local univentionObjectFlag: hidden univentionObjectType: groups/group maildisclaimerTemplate: 0 gidNumber: 1097 sambaGroupType: 5 sambaSID: S-1-5-11 univentionGroupType: -2147483643 # S-1-5-11, idmap, univention, knut.univention.de dn: sambaSID=S-1-5-11,cn=idmap,cn=univention,dc=domain,dc=local objectClass: sambaIdmapEntry objectClass: sambaSidEntry sambaSID: S-1-5-11 gidNumber: 55002 ===================================================================== The object in cn=idmap is the one that winbind on the memberserver actually considers when running "wbinfo --sid-to-gid" and "wbinfo --gid-to-sid": memberserver# wbinfo --gid-to-sid 55002 S-1-5-22 On Ticket# 2018041221000737 this had unexpected consequences after changing the idmap "domain" range on the membersever from the default of 1000-54999 to something like 1000-1999999 (and raising the alloc/"*" range to 2000000-...). After that change, the winbind on the memberserver apparently ignores the cn=idmap entry (which he probably created in the first place), probably because gidNumber 55002 is not in the alloc/"*" range. So the winbind just makes up a fake "Unix"-SID: memberserver# wbinfo --gid-to-sid 55002 S-1-22-2-55002 And then share access broke down for a share where the UCS share path had something like mode 0750 for group "Authenticated Users". Honestly I don't fully understand how the users could enter that directory before the change in the first place, because in Linux/UCS they are actually not member of "Authenticated Users", but that's a different story.
Just a quick note from a different issue: Felix and I discussed the viability of supporting inter domain trust setups with Samba/AD and especially how we may configure the idmap to work consistently across hosts. The result of that discussion was, that we should try to get the old (univention-samba) combination of idmap_nss (for lookup) and idmap_ldap going again. In comparison to the idmap_ad it allows dynamic allocation of Posix IDs in the context of inter domain trusts. The samba4-idmap listener would probably need to be adjusted to clean up the dynamically created sambaIdmapEntry records, in case any have been created temporarily for accounts in the local Samba/AD domain. We would need to experiment if those are created temporarily and how to clean up.
Created attachment 9983 [details] debug-bug45840.log
This issue has been filed against UCS 4.3. UCS 4.3 is out of maintenance and many UCS components have changed in later releases. Thus, this issue is now being closed. If this issue still occurs in newer UCS versions, please use "Clone this bug" or reopen it and update the UCS version. In this case please provide detailed information on how this issue is affecting you.