[cifs-protocol] [REG:115041612643080 ] MS-ADTS 6.2 - Knowledge consistency checker
edgaro at microsoft.com
Fri May 15 15:29:31 MDT 2015
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.
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
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 18.104.22.168 - 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  asks: Why does an RODC have two inbound connection objects? I assume it refers to the same phenomenon.
> 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
> MS-ADTS 22.214.171.124.126.96.36.199.3 RODC NTFRS Connection Object
> In Section 6.2, the options bit NTDSCONN_OPT_RODC_TOPOLOGY is
> referenced whenever appropriate.
> -----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
> 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 188.8.131.52.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
> 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 184.108.40.206.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.
> 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
>> . . .
>> 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
>> ï‚§ 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
>> Active Directory Replication Concepts
>> RODC Frequently Asked Questions
>> -----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
>> [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.
>> -----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
>> 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 220.127.116.11.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 18.104.22.168.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
>> What color is a site containing only an RODC intended to be? And are
>> there any additional undocumented special cases for RODC?
>> Garming Sam
More information about the cifs-protocol