pseudobacklinks: problems with dynamic search of ntds setting for the current server

Matthieu Patou mat at
Mon Jul 25 15:09:46 MDT 2011

Hello  Andrew,

Following your discussion on IRC and remarks you made by email about the 
patch set for pseudobacklinks (available here:;a=shortlog;h=refs/heads/pseudobacklink 

I made more search about this, to sum up you would like that the rootdse 
module do a dynamic search for the NTDS entry when asked for the 
dsServiceName attribute (and also for serverName).

The only approach that can work appart from changing rootdse entries 
when the DN of the DC's NTDS has changed (due to site change for 
instance) is to use an hybrid approach based on the GUID.

When the partitions are not completely loaded (that is to say before the 
end of partitions_init), the dsServername is used in the pdc_fsmo and 
naming_fsmo modules as they try to determine if they are master for this 
role. At this moment the ldb_context object passed to  
samdb_ntds_settings_dn() will allow search only on the entires really 
inside the sam.ldb file, that is to say that at this moment the rootdse 
module can not resolve the real DN of dsServiceName from its GUID (the 
search return object not found), so the solution is to check if the DN 
returned by samdb_ntds_settings_dn (which makes a search in the rootdse) 
is the same as the one in fsmoRoleOwner entry if not we check GUID of 
both DNs and if equal then we know that they are the same (even if the 
string value of DN differ). When the partitions are completely loaded 
the rootdse module can then do a full resolution of the GUID to return 
the correct DN for dsServiceName. That's a bit complicated but not too 
much in fact (look at commits 0bc4fce to 3c3abe9).

The other option is to track change on our NTDS either done by us or 
through DRS, for some reasons it seems that you don't like this one but 
I don't understand too much why.

Nevertheless both approach have a major drawback: if the DN of the NTDS 
settings change, it stays in cache with the OLD value, for this there is 
not a lot of solutions, we can instead of the DN store the GUID in cache 
(or both) and do the search with the GUID and if it fails (or if the 
GUID is not present) then we return the cached DN version. It might be a 
bit too complicated for just a cache that didn't seems to be used so 
often (unless you keep the way too aggressive settings for DRS 
notification to 5 seconds).

Any remarks ?

Note: last patches need some cleaning maybe.

Matthieu Patou
Samba Team
Private repo;a=summary

More information about the samba-technical mailing list