The change to build encoded responses while the database lock is held in current master (commit 0559430ab6e5c48d6e853fda0d8b63f2e149015c) doesn't obey the extended DN control anymore. extended_type is used after it has already been assigned to the callback context.
Created attachment 15293 [details] Patch for master (no test) Still needs a test to show what behaviour changed without this patch.
The observation was that 2012 R2 was failing to join Samba during its initial checks of the credentials and domain level versioning. From the network traces, it wasn't obvious what was different between the successful and unsuccessful cases (and so I did a git bisection).
I think the variable should just be removed, leaving it around unnecessarily is what caused it to be overlooked.
Interestingly enough, since this code is only in the ldap server, ldbsearch on a local database doesn't respect the extended_dn controls for the top level DN of each object (while respecting it elsewhere).
This doesn't seem to be trivially able to be tested in python, because the msg->dn has already been parsed as an actual DN object and returned to python. By this point, the original information on how the GUID was encoded is now lost.
(In reply to Garming Sam from comment #4) Correction: ldbsearch always prints extended_type = 1 specifically. I don't think there's anywhere straightforward in our client stack where we could detect this correctly. I would really like to write a test for this, but there doesn't seem to be an obvious way to do so. To add: Joining the Windows machine as a regular computer was fine without this patch, but the DC provisioning failed.
Created attachment 15314 [details] Backported patch for 4.11
Created attachment 15363 [details] Patch for 4.11 (with test)
Added patch with tests.
G'Day Karolin, This needs to be in before samba 4.11.0. Thanks!
(In reply to Andrew Bartlett from comment #10) Pushed to autobuild-v4-11-test.
(In reply to Karolin Seeger from comment #11) Pushed to v4-11-test. Closing out bug report. Thanks!