Bug 13418 - Extended DN SID component missing for member after switching group membership
Summary: Extended DN SID component missing for member after switching group membership
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: AD: LDB/DSDB/SAMDB (show other bugs)
Version: 4.7.6
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Karolin Seeger
QA Contact: Samba QA Contact
Depends on:
Reported: 2018-05-02 17:23 UTC by Arvid Requate
Modified: 2018-11-06 08:08 UTC (History)
4 users (show)

See Also:

reproduce-incorrect-DN-SID-component-for-member.sh (674 bytes, application/x-shellscript)
2018-05-02 17:23 UTC, Arvid Requate
no flags Details
reproduce-unfixable-incorrect-DN-SID-component-for-member.sh (1017 bytes, application/x-shellscript)
2018-05-03 20:37 UTC, Arvid Requate
no flags Details
Patches for v4-9-test (59.94 KB, text/plain)
2018-10-30 09:42 UTC, Stefan Metzmacher
abartlet: review+
Patches for v4-8-test (75.71 KB, patch)
2018-10-30 09:42 UTC, Stefan Metzmacher
abartlet: review+

Note You need to log in before you can comment on or make changes to this bug.
Description Arvid Requate 2018-05-02 17:23:35 UTC
Created attachment 14171 [details]

The attached script triggers an inconsistency in extended DN of a member attribute in the sam.ldb backend.

The script simply creates a user and then modifies the primaryGroupID to something other than 513. After that samba-tool dbcheck shows this:

ERROR: incorrect DN SID component for member in object CN=Domain Users,CN=Groups,DC=some,DC=domain - <GUID=7eb7e9a9-1cf5-4d34-915c-662897d7c660>;<RMD_ADDTIME=131643299170000000>;<RMD_CHANGETIME=131643299170000000>;<RMD_FLAGS=0>;<RMD_INVOCID=ff8235ec-3395-407e-ad8b-61e725384ce0>;<RMD_LOCAL_USN=4079>;<RMD_ORIGINATING_USN=4079>;<RMD_VERSION=0>;CN=testuser1,CN=Users,DC=some,DC=domain

The <SID=...>; part is missing here.

From the ldbmodify --trace it looks like extended_dn_modify from source4/dsdb/samdb/ldb_modules/extended_dn_store.c could be a point of interest, but I haven't fully understood the code path yet. Any ideas where I should dig into or how to approach this?
Comment 1 Arvid Requate 2018-05-03 20:26:35 UTC
Ok, I see that during samldb_modify the samldb_prim_group_change function in source4/dsdb/samdb/ldb_modules/samldb.c adds the new "member" attribute to the prev_prim_group_dn.

But then neither the linked_attributes_modify function in the linked_attributes module nor the extended_dn_modify in extended_dn_store trigger adding the <SID=...>; part. On the other hand the "GUID" part of the extended member dn gets added. Hmm, I'm giving up for today.

Usually the resulting inconsistency can be fixed easily with dbcheck --fix but I've seen cases where dbcheck --fix runs into a secondary error while fixing that attribute and aborts the transaction. I'll add a script if I manage to reproduce that too.
Comment 2 Arvid Requate 2018-05-03 20:37:23 UTC
Created attachment 14177 [details]

Ah, it's easy to reproduce the "unfixable" case just by changing the primaryGroupID back to the original value. Script attached.
Comment 3 Andrew Bartlett 2018-07-04 09:10:47 UTC
So this is a module ordering issue, as the request goes down the stack it never gains the extra SID etc because extended_dn_store is above samldb.
Comment 4 Stefan Metzmacher 2018-10-30 09:42:26 UTC
Created attachment 14549 [details]
Patches for v4-9-test
Comment 5 Stefan Metzmacher 2018-10-30 09:42:55 UTC
Created attachment 14550 [details]
Patches for v4-8-test
Comment 6 Andrew Bartlett 2018-11-04 23:21:46 UTC
G'Day Karolin,

Please pick for 4.8.next and 4.9.next

Comment 7 Karolin Seeger 2018-11-05 08:33:07 UTC
(In reply to Andrew Bartlett from comment #6)
Hi Andrew,

pushed to autobuild-v4-{9,8}-test.
Comment 8 Karolin Seeger 2018-11-06 08:08:17 UTC
(In reply to Karolin Seeger from comment #7)
Pushed to both branches.
Closing out bug report.