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

[garming at catalyst.net.nz]

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