Univention Bugzilla – Bug 56886
Samba idmap.ldb may map some 3000xxx Posix ID to Well known SID S-1-18-1
Last modified: 2024-01-30 12:56:43 CET
In some UCS Samba/AD environments there's an idmap entry for S-1-18-1: ldbsearch -H /var/lib/samba/private/idmap.ldb objectSid=S-1-18-1 | less # record 1 dn: CN=S-1-18-1 cn: S-1-18-1 objectClass: sidMap objectSid: S-1-18-1 type: ID_TYPE_BOTH xidNumber: 3000013 distinguishedName: CN=S-1-18-1 We should check what implication that has. It's generated by samba in case somebody asks to resolve that sid into a uid, like so: wbinfo --sid-to-uid S-1-18-1 ## don't run this unless you want it created. The exact xidNumber depends on the state of the idmap.ldb on the local system and may vary between systems. For other well known sids we avoid that by pre-creating actual accounts for them in OpenLDAP to have domain wide identical Posix-IDs for those well known SIDs.
smbd.log with debug5 [2024/01/12 12:36:39.741143, 0, pid=11086] ../../source4/auth/unix_token.c:125(security_token_to_unix_token) Unable to convert SID (S-1-18-1) at index 54 in user token to a GID. Conversion was returned as type 0, full token: [2024/01/12 12:36:39.741163, 0, pid=11086] ../../libcli/security/security_token.c:52(security_token_debug) Security token SIDs (60): [..] SID[ 54]: S-1-18-1 SID[ 55]: S-1-1-0 SID[ 56]: S-1-5-2 SID[ 57]: S-1-5-11 SID[ 58]: S-1-5-32-545 SID[ 59]: S-1-5-32-554 Privileges (0x 800000): Privilege[ 0]: SeChangeNotifyPrivilege Rights (0x 400): Right[ 0]: SeRemoteInteractiveLogonRight [2024/01/12 12:36:39.741443, 3, pid=11086] ../../source3/smbd/smb2_server.c:3964(smbd_smb2_request_error_ex) smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_INVALID_SID] || at ../../source3/smbd/smb2_sesssetup.c:147 This appears during :~$ klist Credentials cache: FILE:/tmp/krb5cc_60112_KzPwno0Uq0 Principal: abc@SCHEIN.ME Issued Expires Principal Jan 12 11:07:02 2024 Jan 12 16:46:37 2024 krbtgt/SCHEIN:ME@SCHEIN:ME :~$ smbclient -k //$(hostname -f)/abc
Created attachment 11171 [details] Script to create S-1-18-1 to S-1-18-6 in UDM/OpenLDAP The attached script may be used to create the objects in OpenLDAP that would trigger the samba4-idmap.py listener module to create an entry in idmap.ldb (which is needed as long as we use "idmap config * : backend = tdb" in smb.conf). Extends the script https://forge.univention.org/bugzilla/show_bug.cgi?id=56334#c3 (sorry only saw that later). The SIDs are documented under https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-special-identities-groups and https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-dtyp/81d92bba-d22b-4a8c-908a-554ab29148ab, but it's a bit strange that in Christinas case the Object was dn: CN=Authentication authority asserted identity,CN=Builtin,DC=schein,DC=me objectClass: group objectGUID: 8bdf4274-7a4f-44eb-bc56-11637469c8c0 sAMAccountName: Authentication authority asserted identity objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=schein,DC=me gidNumber: 5157 groupType: -2147483643 objectSid: S-1-18-1 sAMAccountType: 536870912 while in the MS docs it's described as objectClass=foreignSecurityPrincipal under CN=WellKnown Security Principals,CN=Configuration. The ugly difference is, that those objects don't have a sAMAccountName and are not replicated by the S4-Connector. This means that when you create the objects in OpenLDAP with the attached script, then you will probably have rejects in the S4-Connector because it cannot find a group with that name and it cannot create it when the objectSid is already occupied by a foreignSecurityPrincipal. Anyway, it's not a big deal probably but we need to find out how to address this in the product.
This will give you this behavior: root@primary20:~# wbinfo --sid-to-uid S-1-18-1 failed to call wbcSidToUid: WBC_ERR_DOMAIN_NOT_FOUND Could not convert sid S-1-18-1 to uid root@primary20:~# wbinfo --sid-to-gid S-1-18-1 5074
Created attachment 11172 [details] samba4-idmap.py.patch To make the SID also resolvable as uid we need to extend the __SPECIAL_ACCOUNT_SIDS list in the samba4-idmap.py listener. Or you manually change the objectSid=S-1-18-* entries in (each) idmap.ldb to change "type: ID_TYPE_GID" into "type: ID_TYPE_BOTH".
Microsoft also had some issues with that: https://support.microsoft.com/kb/2830145 I checked on a Windows Server 2019 Forest root domain DC, where the objects look like this: === dn: CN=Authentication Authority Asserted Identity,CN=WellKnown Security Principals,CN=Configuration,DC=autotest240win,DC=test objectClass: foreignSecurityPrincipal showInAdvancedViewOnly: TRUE objectSid: S-1-18-1 dn: CN=Service Asserted Identity,CN=WellKnown Security Principals,CN=Configuration,DC=autotest240win,DC=test objectClass: foreignSecurityPrincipal showInAdvancedViewOnly: TRUE objectSid: S-1-18-2 dn: CN=Fresh public key identity,CN=WellKnown Security Principals,CN=Configuration,DC=autotest240win,DC=test objectClass: foreignSecurityPrincipal showInAdvancedViewOnly: TRUE objectSid: S-1-18-3 dn: CN=Key Trust,CN=WellKnown Security Principals,CN=Configuration,DC=autotest240win,DC=test objectClass: foreignSecurityPrincipal showInAdvancedViewOnly: TRUE objectSid: S-1-18-4 dn: CN=MFA Key Property,CN=WellKnown Security Principals,CN=Configuration,DC=autotest240win,DC=test objectClass: foreignSecurityPrincipal showInAdvancedViewOnly: TRUE objectSid: S-1-18-5 dn: CN=Attested Key Property,CN=WellKnown Security Principals,CN=Configuration,DC=autotest240win,DC=test objectClass: foreignSecurityPrincipal showInAdvancedViewOnly: TRUE objectSid: S-1-18-6 === The MR linked in the URL field holds a proposal to fix it in the product. Please note that these are logically three steps: 1. Append the new identity *names* on the UCR variable connector/s4/mapping/group/ignorelist 2. Create them in UDM specifying the correct Well Knwon SIDs 3. Optionally add them to Samba/AD under "CN=WellKnown Security Principals,CN=Configuration"
Created attachment 11179 [details] Script to create S-1-18-1 to S-1-18-6 in UDM/OpenLDAP and Samba/AD Updated script that may be useful to create the new entities in OpenLDAP and Samba/AD i na way that should avoid S4-Connector rejects and hopefully also avoids problems with Windows Clients as well as with future Samba/AD updates.