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

[Edgar Olougouna]

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