Andrew, Per [MS-ADTS] Section 6.2, which provides a lot of details on Windows-based KCC implementation, KCC runs produce or update the following: • Config NC objects: nTDSConnection • Abstract attributes of NC replicas: repsFrom, repsTo • Variables of DCs: kCCFailedConnections, kCCFailedLinks
Referring to the simplified example in Section 3.1.1.1.13 NC Replica Graph, the output would be specific to a given topology and configuration for that implementation. As you alluded to, a given implementation may produce a different output and that should be fine provided the end outcome is achieved. This clearly seems a potential area of innovation for implementers. [MS-ADTS] 6.2 Knowledge Consistency Checker https://msdn.microsoft.com/en-us/library/cc223795.aspx 6.2.2 Overview The KCC automates management of the NC replica graph for each NC in the forest. In doing so, it maintains the following requirements: • There exists a path from each writable replica to every other NC replica (writable, read-only full, or read-only partial) of the same NC. • No path from a writable replica to another writable replica passes through a read-only replica. • For each domain NC, the path from a writable replica to another writable replica utilizes only the RPC transport (never SMTP [MS-SRPL]). • For each domain NC, the path from a writable replica to a read-only full replica utilizes only the RPC transport (never SMTP [MS-SRPL]). • Replication latency is short between NC replicas on DCs in the same site, at the expense of additional replication traffic within the site. • Replication traffic between sites is low, at the expense of additional replication latency between sites. • A state in which one or more DCs are offline or unreachable (temporarily or indefinitely) does not cause the replication latency across the remaining DCs to grow without bound. • Edges between DCs in different sites constitute a least cost spanning tree for an administrator-defined cost metric. The KCC performs this work in a sequence of tasks called a "run". These runs execute periodically and on receipt of an IDL_DRSExecuteKCC request. The first periodic run of the Windows KCC begins 5 minutes after system startup. Subsequent runs execute such that the interval between the end of one run and the beginning of the next run is 15 minutes. These tasks utilize the following inputs: • Config NC objects: crossRef, interSiteTransport, nTDSDSA, nTDSConnection, site, nTDSSiteSettings, siteLink, siteLinkBridge • Abstract attributes of NC replicas: repsFrom, repsTo • Variables of DCs: kCCFailedConnections, kCCFailedLinks • Current date/time And produce or update the following: • Config NC objects: nTDSConnection • Abstract attributes of NC replicas: repsFrom, repsTo • Variables of DCs: kCCFailedConnections, kCCFailedLinks The KCC individual tasks are detailed in the remainder of this section, and are executed in the sequence in which they appear in this document. In summary, these tasks are: • Refresh kCCFailedLinks and kCCFailedConnections. • Create intra-site connections. • Create inter-site connections. • Remove unnecessary connections. • Translate connections. • Remove unnecessary kCCFailedLinks and kCCFailedConnections. 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. . . . Thanks, Edgar -----Original Message----- From: Edgar Olougouna Sent: Wednesday, March 4, 2015 4:09 PM To: Andrew Bartlett Cc: [email protected]; MSSolve Case Email Subject: RE: Test fixtures for the KCC [REG:115030412472722] Andrew, I will work with you on this inquiry. Thanks, Edgar -----Original Message----- From: Josh Curry Sent: Wednesday, March 04, 2015 11:14 AM To: Andrew Bartlett Cc: [email protected]; MSSolve Case Email Subject: RE: Test fixtures for the KCC [REG:115030412472722] Hi Andrew, thank you for your question. Case 115030412472722 has been created to track your issue. A member of the protocol documentation team will be in touch with you soon. Josh Curry | Escalation Engineer | Open Specifications Support Team P +1 469 775 2321 One Microsoft Way, 98052, Redmond, WA, USA http://support.microsoft.com -----Original Message----- From: Andrew Bartlett [mailto:[email protected]] Sent: Tuesday, March 3, 2015 9:56 PM To: Interoperability Documentation Help Cc: [email protected] Subject: Test fixtures for the KCC We are working on making Samba's KCC much, much smarter than the full-mesh topology we currently have. (For those familiar with Samba, the particular task involves finsishing the work on the samba_kcc script). One thing that has come to our attention, is the need for really good and diverse text fixtures, and expected outputs for the KCC algorithm. That is, while the docs really are great, they are incredibly detailed and at points appear to have errors at some point. To be sure one way or the other, we need to test a variety of network topologies against the reference implementation in Windows, or the output thereof. The trouble I've got is that unlike so many other aspects of the protocol, the output isn't a network response, but instead one part of a distributed algorithm, which the author warns must be implemented exactly (or else replication will fail in horrible ways). So I'm looking for suggestions as to how to handle this, and wondering if a documented algorithm such as this should have some expected output values, to validate against. In particular, the challenge is how to assert not just by looking at a running windows server, but to do the same in our as part of our internal make test. I realise this is a little open-ended, but I figured I would ask. Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
