nTDSConnection object attributes

[tridge at samba.org]

Hi Cr stian,

Just a few more comments following on from the details that Metze
gave.

Metze is correct about the correct way to fill things in, but if you
find it too complex for a first version, then you could do something
much simpler first, and have us look at your initial patch. 

If you look in setup/ad-schema/MS-AD_Schema_2K8_Classes.txt you can
see which attributes are mandatory. The systemMustContain attribute
only lists "options", "fromServer" and "enabledConnection", so you
could just start with those.

Then once you have a simple patch that fills in those values then you
can work on filling in the other values. We could accept the patch in
several stages, starting with a very simple one, and moving onto one
that fills in all the other attributes.

The reason I'm suggesting this approach is that I'd like to be able to
give you feedback on your code as you go, so you can get some
suggestions on coding styles etc.

 > here are the questions:
 > 
 > 1) the "fromServer" attribute is the DN of the other server replicating with
 > the current one, right?

It is the DN of the other servers nTDSDSA object. The nTDSDSA object
is the primary source of information about a replicating server in
AD, so by using that DN you can find out all the basic information you
need to know about that server.

 > 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?

that guid corresponds to the objectGUID of the nTDSDSA object for the
server. So if you use dsdb_find_dn_by_guid() you could find the DN of
the servers nTDSDSA object from that guid.

Please also look at the approach Metze suggested, but as I said above,
if you want to start with something simpler that is fine.

 > 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?

As Metze mentioned, you can use data_blob_const(). In
lib/util/data_blob.h we use a #define to alias a "DATA_BLOB" with a
"struct ldb_val". We do this as there are so many core functions in
Samba that deal with a "DATA_BLOB" and ldb deals with "struct
ldb_val". By making them the same structure it is easier to mix data
values. So data_blob_const() produces a valid "struct ldb_val".

 > 3) what does the attribute "dSCorePropagationData" mean? from the MS
 > documentation, it says "The DS-Core-Propagation-Data attribute is for
 > internal use only."

It probably means it isn't look at by other DCs, so you can probably
leave it out. If you'd like clarification on this or any other
question about the docs, you can ask Microsoft for help by emailing
dochelp at winse.microsoft.com (please also CC cifs-protocol at samba.org).

 > 4) does the "mS-DS-ReplicatesNCReason" attribute always happen 3 times?

It seems to contain the last failure/pass reason for each NC that is
replicated with this DC. In the example you posted Samba has 3 NCs
(the user NC, the configuration NC and the schema NC), so it contains
the failure code for the replication with each of those NCs.

In the KCC I don't think you should fill these in, but I think the
correct thing to do would be for the dsdb/repl/ code to update these
when it does a replication. 

 > 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?

for now just assume a "fully connected" topology. We'll have to later
add proper topology support, and work out how we fit into a domains
topology, but replicating with all other DCs will work for now.

Cheers, Tridge