nTDSConnection object attributes
Stefan (metze) Metzmacher
metze at samba.org
Thu Nov 12 10:40:08 MST 2009
> I'm implementing the creation of nTDSConnection objects during replication (
> and I have some questions about some of this object's attributes.
> I'm working inside the function kccsrv_simple_update inside
First you need to split kccsrv_simple_update() into multiple functions,
I think kccsrc_update_run() should replace kccsrv_simple_update()
and it should call kccsrv_update_connections_run() followed
kccsrv_update_connections_run() should search for all
nTDSDSA objects (like kccsrv_simple_update() currently).
But we also need to ask for the "hasMasterNCs" attribute
(later we can change to msDS-hasMasterNCs or msDS-HasInstantiatedNCs).
We should also use the extended-dn control to get extended dns.
Then for each nTDSDSA object we should check whether we need to
replicate with it (for now we can just compare if the hasMasterNCs
values match with the namingContexts of our local samdb's rootDSE.
And we need to filter our own entry.
For each remaining nTDSDSA object we should do a search under our
own nTDSDSA object with
(&(objectClass=nTDSConnection)(fromServer=<other-dsa-dn>)) as filter.
If we find an object we need check if it was autogenerated (
there's a flag which says the KCC has generated it, maybe it's in the
"option" attribute, but better check the docs). If it was autogenerated
we should check if we need to update it.
If it doesn't exist, we generate a new guid name and add a new connection.
The kccsrv_update_repsFromTo_run() function should then do a search for
all nTDSConnection object under our nTDSDSA object,
They search should use the extended dn control.
Then we should create refsFrom attributes for each partition in
depending on the mS-DS-ReplicatesNCReason. I think we should first build
an ldb_message for each partition we have and do the ldb_modify() calls
after we have processed all nTDSConnection objects. This way we can
replace of all refsFrom attributes at once and don't need to manually
do adds and deletes for outdated values.
As we do searches with the extended control it's easy to use the new
dsdb_dn code to extract the GUID for thinks like r1->source_dsa_guid.
> below is the content of an existing
> nTDSConnection object from a Windows 2008 server (the objects created on
> Samba must have the same properties).
> dn: CN=8f76f9cc-7a64-4269-b682-95f921294304,CN=NTDS
> objectClass: top
> objectClass: leaf
> objectClass: nTDSConnection
> cn: 8f76f9cc-7a64-4269-b682-95f921294304
> distinguishedName: CN=8f76f9cc-7a64-4269-b682-95f921294304,CN=NTDS
> instanceType: 4
> whenCreated: 20091109171611.0Z
> whenChanged: 20091109191613.0Z
> uSNCreated: 12752
> uSNChanged: 12814
> showInAdvancedViewOnly: TRUE
> name: 8f76f9cc-7a64-4269-b682-95f921294304
> objectGUID: 18a77f06-054a-4b18-a6f0-42d1c9123cbe
> enabledConnection: TRUE
> fromServer: CN=NTDS
> options: 1
> systemFlags: 1610612736
> dSCorePropagationData: 16010101000000.0Z
> mS-DS-ReplicatesNCReason: B:8:00000008:DC=adinterop,DC=ltc,DC=virtual
> here are the questions:
> 1) the "fromServer" attribute is the DN of the other server replicating with
> the current one, right? I found Windows' GUID in r1->source_dsa_obj_guid,
> but I'm not sure if that's the right information (maybe it's indicating
> something else, even though it's the same GUID I'm interested at). should I
> do an ldbsearch to get the Windows' DN based on that GUID?
If you use the extended_dn control the fromServer DN would contain the
guid. I'm pretty sure it's the one for r1->source_dsa_obj_guid.
> 2) the "schedule" attribute is a byte array with 84 positions which I think
> is the one in r1->schedule. how do I add that value to the ldb_msg? I only
> see the functions ldb_msg_add_string and ldb_msg_add_value; if it's a
> string, how do I convert that array to the string representation that
> ldbsearch has displayed? and if it's an ldb_val, how do I convert the array
> to that struct?
schedule is just an array of 84 bytes (uint8_t schedule)
ldb_val = data_blob_const(r->schedule, sizeof(r->schedule));
schould be enough to create an ldb_val.
For now the schedule should be 84 bytes of 0xFF, which means
we do pull replication each 15 minutes 84*8 = 4*24*7 times a week.
But maybe I'm wrong and the format specified in
[MS-ADTS] 184.108.40.206 Replication Schedule Structures is used.
The LDIF is then the base64 of it, but you the base64 encoding
> 3) what does the attribute "dSCorePropagationData" mean? from the MS
> documentation, it says "The DS-Core-Propagation-Data attribute is for
> internal use only."
You can just skip this...
> 4) does the "mS-DS-ReplicatesNCReason" attribute always happen 3 times?
> there's only one instance of the nTDSConnection object on the Windows 2008,
> and that's the only example I can compare to. according to
> http://msdn.microsoft.com/en-us/library/ms678640(VS.85).aspx, the value
> "00000008" means STALE_SERVERS_TOPOLOGY. how do I find out what's the
> replication topology for each case?
I'm not sure what we should use there, as for now we want it simple,
and just replicate with everybody, even across sites.
I assume [MS-ADTS] 7.2 Knowledge Consistency Checker will have more
details, but don't get confused when you read it, first we need
something much simpler...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 260 bytes
Desc: OpenPGP digital signature
More information about the samba-technical