[cifs-protocol] [REG:115041612643080 ] MS-ADTS 6.2 - Knowledge consistency checker

[Edgar Olougouna]

Garming,

The RODC has two inbound connection objects. The first connection object is created at RODC creation time as part of DC installation, i.e. by dcpromo.
The second connection object on the RODC is created by the KCC on the RODC, which acts as an ISTG for itself. The KCC runs on its normal schedule and maintains this object. 
The second connection object is used for DC replication and its use is documented in MS-DRSR. However, this second connection object does not replicate, recall that the RODC only performs inbound unidirectional replication. If you delete that connection object, it gets recreated by the KCC.
As for when is MS-ADTS 6.2.2.7 called to update the RODC NTFRS Connection Object, the RODC NTFRS connection object is created at DC installation time and is not maintained by the DC beyond that.
Technically, it may be possible to create on an RODC some ntdsConnection objects that do not have NTDSCONN_OPT_RODC_TOPOLOGY. However, unless the protocol describes what to do with such an object the behavior of the system on encountering such an object is outside of protocol.  
Any necessary documentation is in MS-ADTS or MS-DRSR.
An informative article that briefly describes why the KCC acts as an ISTG for itself is at the following link. https://technet.microsoft.com/en-us/library/cc754956(v=ws.10).aspx
Please note that explaining the reasons behind Windows implementation choices is beyond the scope of protocol documentation.

Thanks,
Edgar

-----Original Message-----
From: Edgar Olougouna 
Sent: Friday, May 15, 2015 4:30 PM
To: garming at catalyst.net.nz
Cc: cifs-protocol at samba.org; MSSolve Case Email
Subject: RE: [REG:115041612643080 ] MS-ADTS 6.2 - Knowledge consistency checker

Garming,
This is a quick note that I will follow-up when as soon as there is an update. I am pending the product group comments on some of the aspects.

Thanks,
Edgar  

-----Original Message-----
From: garming at catalyst.net.nz [mailto:garming at catalyst.net.nz]
Sent: Saturday, April 25, 2015 5:53 AM
To: Edgar Olougouna
Cc: Garming Sam; cifs-protocol at samba.org; MSSolve Case Email
Subject: RE: [REG:115041612643080 ] MS-ADTS 6.2 - Knowledge consistency checker

Hi Edgar,

Is it at all possible to describe more details on ntdsConnection objects for the RODC which do not have NTDSCONN_OPT_RODC_TOPOLOGY?

From what I understand, they should exist, but I have yet to see any in a test setup I built to observe (which may be due to failing to wait long enough). ADTS 6.2.2.7 - Updating the RODC NTFRS Connection Object mentions updating the fromServer attribute from a connection which does have NTDSCONN_OPT_RODC_TOPOLOGY to the fromServer of an ntdsConnection which does not have NTDSCONN_OPT_RODC_TOPOLOGY. Similarly the question, on the RODC FAQ [1] asks: Why does an RODC have two inbound connection objects? I assume it refers to the same phenomenon.

Cheers,

Garming


[1] https://technet.microsoft.com/en-us/library/cc754956%28v=ws.10%29.aspx



> Garming,
> RODCs are particular in the sense they are designed for inbound 
> unidirectional replication, and are not meant to replicate outbound or 
> between each other. An RODC KCC does consider itself as part of the 
> topology. NTDS-DSA-RO object category types are not returned in KCC / 
> ISTG queries while attempting to enumerate inbound topology objects.
> The RODC connection object is however created during dcpromo when the 
> RODC machine account is set.
> The RODC ntdsConnection object has
> Options: 0x41 NTDSCONN_OPT_IS_GENERATED | NTDSCONN_OPT_RODC_TOPOLOGY
> fromServer: the nTDSDSA object of the source DC.
> RODC connections are marked as IS_GENERATED although they are not 
> auto-generated.
>
> MS-ADTS 6.1.1.2.2.1.2.1.3 RODC NTFRS Connection Object 
> https://msdn.microsoft.com/en-us/library/dd340911.aspx
>
> In Section 6.2, the options bit NTDSCONN_OPT_RODC_TOPOLOGY is 
> referenced whenever appropriate.
>
> Thanks,
> Edgar
>
> -----Original Message-----
> From: Garming Sam [mailto:garming at catalyst.net.nz]
> Sent: Wednesday, April 22, 2015 9:45 PM
> To: Edgar Olougouna
> Cc: cifs-protocol at samba.org; MSSolve Case Email
> Subject: Re: [REG:115041612643080 ] MS-ADTS 6.2 - Knowledge 
> consistency checker
>
> Hi,
>
> Everything that you've mentioned, I've managed to grasp. Likewise, 
> I've seen most of the available documentation on RODC and KCC 
> including the ones you've posted.
>
>> If the local site color is white or number of colored vertices is 
>> less than two, KCC does not need to build spanning tree for that NC.
>
> This check for a white vertex evidently happens in CreateConnections 
> of ADTS 6.2.2.3.4.5. This means, as it describes, that the topology 
> does not need to be computed. However, if the RODC does not compute 
> the topology, it doesn't explain how the inbound connection objects it 
> needs are created when its in its own site.  At least from the KCC, 
> all the regular DC see the RODC as invisible (Why doesn't the KCC on 
> writable domain controllers try to build connections from an RODC? on 
> https://technet.microsoft.com/en-us/library/cc754956%28v=ws.10%29.aspx).
>
> Is the connection creation outside of the KCC? The only thing I know 
> for certain that a KCC on an RODC does is update the FRS connection to 
> point at the same place as the DRS connection. But the description 
> itself obviously has checks to imply otherwise. Notably when it is in 
> its own site, according to ADTS 6.2.2.3.1 RODC apparently acts as an 
> intersite-topology generator for itself. Following the guidelines for 
> "is present", every indication seems to show that all the NC replicas 
> on the RODC satisfy these conditions. However, it seems irrelevant 
> since the KCC never gets far enough to use this value - again with the 
> RODC being invisible to everyone but itself.
>
>
>
> Cheers,
>
> Garming Sam
>> Either the local site does not host this NC, or the spanning tree 
>> would not have any edge. In either case, we do not need to compute 
>> the topology.  KCC moves to the next NC in the list.
>> Recall that vertex initialization sets the color to ‘white’. The 
>> colored vertices are sites which contain a writeable or partial 
>> replica of the NC specified by CrossRef. Sites which contain at least 
>> one writeable replica are considered 'red' vertices. Sites which 
>> contain at least one partial replica but no writeable replicas are 
>> considered 'black' vertices. All other sites are considered 'white'
>> vertices as marked during initialization, and are not colored.
>> Please take a look at the following references, including the 
>> non-MS-ADTS ones, they may be useful.
>>
>> MS-ADTS 6.2.2 Overview
>> https://msdn.microsoft.com/en-us/library/cc223797.aspx
>> . . .
>> To simplify the task descriptions, the following concepts are used:
>> •	An NC replica that "is present" on a DC. Given NC replica r of NC n
>> and a DC with nTDSDSA object o, r "is present" on the DC if both of 
>> the following conditions is true:
>> o	o!hasMasterNCs contains n or o!msDS-hasFullReplicaNCs contains n or
>> o!hasPartialReplicaNCs contains n.
>> o	One of the following two conditions is true:
>> 	o!msDS-HasInstantiatedNCs contains no value v where the dsname
>> portion of v = n. (In this case n is in the process of being
>> instantiated.)
>> 	o!msDS-HasInstantiatedNCs contains a value v, where the dsname part
>> of v = n, and the binary part of v (DWORD in big-endian byte order) 
>> is an integer such that the IT_NC_GOING bit is clear. (In this case n 
>> is instantiated, and is not in the process of being uninstantiated.)
>> •	An NC replica that "should be present" on a DC. Given NC replica r
>> of NC n and a DC with nTDSDSA object o, r "should be present" on the 
>> DC if r is one of the following:
>> o	A writable replica of the config NC, the schema NC, or the DC's
>> default NC on a writable DC.
>> o	A full read-only replica of the config NC, the schema NC, or the DC's
>> default NC on an RODC.
>> o	A writable replica of an application NC for which there exists a
>> crossRef object cr such that cr!nCName = n and 
>> cr!msDS-NC-Replica-Locations contains a reference to o.
>> o	A full read-only replica of an application NC for which there exists a
>> crossRef object cr such that cr!nCName = n and 
>> cr.ms-DS-NC-RO-Replica-Locations contains a reference to o.
>> o	If the DC is a GC server (that is, if bit NTDSDSA_OPT_IS_GC is set in
>> o!options), a partial replica of a domain NC n such that n ≠ the 
>> DC's default NC, and there exists a crossRef object cr such that 
>> cr!nCName = n.
>> •	An nTDSConnection object "implies" a tuple in the repsFrom abstract
>> attribute of an NC replica (and a corresponding edge in an NC replica 
>> graph). An nTDSConnection object cn implies a tuple in r!repsFrom for 
>> NC replica r of NC n on the DC with nTDSDSA object t, if each of the 
>> following is true:
>> o	cn is a child of t.
>> o	cn!fromServer references an nTDSDSA object s.
>> o	An NC replica of n "is present" on s.
>> o	r "should be present" on t.
>> o	The NC replica on s is a full replica or r is a partial replica.
>> o	n is not a domain NC, or r is a partial replica, or cn!transportType
>> has no value, or cn!transportType has an RDN of CN=IP.
>>
>> Review Bridgehead Server Load-Balancing Improvements with Windows 
>> Server 2008 RODCs 
>> https://technet.microsoft.com/en-us/library/dd735927(WS.10).aspx
>>
>> Active Directory Replication Concepts 
>> https://technet.microsoft.com/en-us/library/cc731537(v=ws.10).aspx
>>
>> RODC Frequently Asked Questions
>> https://technet.microsoft.com/en-us/library/cc754956(v=ws.10).aspx
>>
>> Thanks,
>> Edgar
>>
>> -----Original Message-----
>> From: Edgar Olougouna
>> Sent: Thursday, April 16, 2015 10:23 AM
>> To: Garming Sam
>> Cc: cifs-protocol at samba.org; MSSolve Case Email
>> Subject: [REG:115041612643080 ] MS-ADTS 6.2 - Knowledge consistency 
>> checker
>>
>> [case number in subject]
>> [bcc dochelp; cc casemail]
>>
>> Hello Garming,
>> Glad to hear from you. The case number 115041612643080 has been 
>> created for this inquiry. I will investigate and assist you on this.
>>
>> Thanks,
>> Edgar
>>
>> -----Original Message-----
>> From: Garming Sam [mailto:garming at catalyst.net.nz]
>> Sent: Wednesday, April 15, 2015 11:25 PM
>> To: Interoperability Documentation Help
>> Cc: cifs-protocol at samba.org
>> Subject: MS-ADTS 6.2 - Knowledge consistency checker
>>
>> Hi,
>>
>> In attempting to implement the inter-site topology generation 
>> algorithm, it appears that cases around RODC are lacking clarity in 
>> the documentation.
>>
>> For instance described in 6.2.2.3.3 - Site Graph Concepts, 
>> essentially Red describes sites with writable replicas, Black 
>> describes sites with only partial read-only and White with neither 
>> writable nor partial read-only replicas. But there is no mention of full read-only replicas.
>>
>> The only assumption that could be made here is that they are white, 
>> however, there are two problems:
>>
>> 1. In 6.2.2.3.4.3 - Site Graph Construction under ColorVertices, Red 
>> describes sites with one or more DCs with full replicas - not writable.
>> This would make full read-only replica Red.
>>
>> 2. Being marked as White, during intersite topology generation, sites 
>> with only an RODC do not appear in the spanning-tree computation.
>> Therefore, they will never create any connections.
>>
>> Being marked as Red however, there does not appear to be any 
>> restrictions in the graph construction on who may replicate from it 
>> (like a Black node for instance). Is there something here I am 
>> misunderstanding?
>>
>> What color is a site containing only an RODC intended to be? And are 
>> there any additional undocumented special cases for RODC?
>>
>>
>> Cheers,
>>
>> Garming Sam
>>
>
>