Bug 58445 - Share listing and access not possible if idmap entry S-1-5-21-0-0-0-497 is missing after update to 5.2
Summary: Share listing and access not possible if idmap entry S-1-5-21-0-0-0-497 is mi...
Status: NEW
Alias: None
Product: UCS@school
Classification: Unclassified
Component: Samba 4
Version: UCS@school 5.0
Hardware: Other Linux
: P5 normal
Target Milestone: ---
Assignee: Samba maintainers
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-07-02 15:12 CEST by Christina Scheinig
Modified: 2025-08-27 12:32 CEST (History)
3 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 4: Minor Usability: Impairs usability in secondary scenarios
Who will be affected by this bug?: 2: Will only affect a few installed domains
How will those affected feel about the bug?: 5: Blocking further progress on the daily work
User Pain: 0.229
Enterprise Customer affected?:
School Customer affected?: Yes
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number: 2025070221000068, 2025082121000217
Bug group (optional):
Customer ID: 09711
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christina Scheinig univentionstaff 2025-07-02 15:12:04 CEST
Description:
In a big customerenvironment on some school replicas fileshare listing and therefor fileshare access was no longer possible after upgrade to 5.2(-2)
The log.smbd shows this messages, whe someone trys to list \\ucs-replica in the windows explorer.

[2025/07/02 14:53:51.780825,  0, pid=1137277] ../../source4/auth/unix_token.c:123(security_token_to_unix_token)
  Unable to convert SID (S-1-5-21-0-0-0-497) at index 4 in user token to a GID.  Conversion was returned as type 0, full token:
[2025/07/02 14:53:51.780877,  0, pid=1137277] ../../libcli/security/security_token.c:133(security_token_debug)
  Security token SIDs (10):
    SID[  0]: S-1-5-21-2258795110-56359529-1961293181-73274
    SID[  1]: S-1-5-21-2258795110-56359529-1961293181-515
    SID[  2]: S-1-5-21-2258795110-56359529-1961293181-11243
    SID[  3]: S-1-18-1
    SID[  4]: S-1-5-21-0-0-0-497
    SID[  5]: S-1-1-0
    SID[  6]: S-1-5-2
    SID[  7]: S-1-5-11
    SID[  8]: S-1-5-32-554
    SID[  9]: S-1-5-32-545

So this mysterious SID seems to be a claims_valid SID. 
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-dtyp/81d92bba-d22b-4a8c-908a-554ab29148ab
So since 4.21-1 (or 4-20) samba seems to strictly validate all SIDs found in Security token. This one cannot be looked up by windows and the access is completely not possible.

Workaround:
Add the missing entry in the idmap.ldb like this:

root@ucs-replica:~# cat > 497.ldif
dn: CN=S-1-5-21-0-0-0-497
cn: S-1-5-21-0-0-0-497
objectClass: sidMap
objectSid: S-1-5-21-0-0-0-497
type: ID_TYPE_BOTH
xidNumber: 3000577
distinguishedName: CN=S-1-5-21-0-0-0-497
^C
root@ucs-replica:~# ldbadd -H /var/lib/samba/private/idmap.ldb 497.ldif
Added 1 records successfully
root@ucs-replica:~# net cache flush
root@ucs-replica:~# /etc/init.d/winbind restart

Interesting:
This was not a problem on all servers but on 5 out of 85. The other server already had this entry in the idmap.ldb
Comment 1 Arvid Requate univentionstaff 2025-08-25 19:23:01 CEST
S-1-5-21-0-0-0-497 is already in Samba for a long time (git history says about 4.16 ?)

> Unable to convert SID (S-1-5-21-0-0-0-497) at index 4 in user token to a GID

I'd guess it needs to be added "somehow" to OpenLDAP, so that it a GID or UID is assigned.

When I look into the joinscript of univention-samba4 I see a function _create_group_with_special_sid,
so that may be a recipe to follow to solve this.