Compartir a través de

3.1.1.1.5 NC, NC Replica

  • Artículo

The type DSNAME is defined as a C structure in [MS-DRSR] section 5.50; this state model uses the simpler DSName, which contains the same information in a tuple of the form:

DSName: [dn: DN; guid: GUID; sid: SID]

An NC is a set of objects organized as a tree. It is referenced by a DSName containing a non-NULL dn and a non-NULL GUID. This DSName also references the NC root, which is the root object of the tree of objects in the NC. The NC root has the IT_NC_HEAD bit set in the instanceType attribute. Any instance of the NC on any DC is called an NC replica. It is convenient to say "the NC x" where x is the DSName referencing the NC.

A replica of NC x is a replica as already defined, with its root object r constrained as follows:

Mutation of a replica in the general sense is unconstrained. In the case of a replica of a specific NC, the root object cannot be replaced, because doing so would change the objectGUID (and objectSid if any), and this MUST equal the NC's guid. In a replica of a given NC the root object's DN cannot be changed, because the root object's DN MUST equal the NC's dn.

All replicas in Active Directory are NC replicas.

NC replicas are mutable. The term originating update means any mutation to an NC replica performed via any protocol except replication.

Active Directory performs replication between replicas of the same NC to converge their states, so an update originated on one replica is reflected in all the others. The replication algorithm has the property that if originating updates to all replicas ceases and communication between replicas is maintained, the application-visible states of the replicas will eventually converge to a common value. Applications of Active Directory can read from several replicas of a given NC and observe the differences, but applications typically bind to a single replica.

Active Directory supports four NC types:

Domain NC: A domain naming context (domain NC). The sid field of a domain NC is not NULL.

Config NC: An NC that stores Active Directory configuration information. The sid field of a config NC is NULL.

Schema NC: An NC that stores Active Directory schema information. The sid field of a schema NC is NULL.

Application NC: An application NC. The sid field of an application NC is NULL.

The dn of a domain NC or an AD DS application NC takes the form:

dc=n1,dc=n2, ... dc=nk

where each ni satisfies the syntactic requirements of a DNS name component [RFC1034]. Such a DN corresponds to the DNS name:

n1.n2. ... .nk

This is the DNS name of the NC. The mapping just specified follows [RFC2247].

In AD LDS, an application NC can have any valid DN; therefore an AD LDS application NC does not necessarily have a DNS name.

Replicas of a domain NC have one of these two subtypes:

  • Full. A replica whose objects contain their full state as defined by all originating updates.

  • Partial. A replica whose objects contain a filtered view of the full state as defined by all originating updates. There are three types of the partial replica:

Replicas of other NC types are always full. A full replica is either writable, that is, it accepts originating updates, or is read-only. A partial replica is read-only.

This section has introduced many concepts without describing how they are reflected in the state model. To a great extent this obligation will be discharged in other sections of this document. The schema NC is described in section 3.1.1.2, while the other NC types are described in section 6.1. Here are three elaborations of the state model that can be explained without making a forward reference:

  1. NC replicas are modeled by making a DSName, converted into a string formatted as specified in [MS-DRSR] section 5.16.2.1, the first element of a replica.

  2. The root object of a domain NC or an AD DS application NC has class domainDNS. The RDN attribute of domainDNS is dc. Therefore both the dc and name attributes of the root object of a domain NC or an AD DS application NC equal the first component (for example, n1 for DNS name n1.n2. ... .nk) of the NC's DNS name. The root object of an AD LDS application NC can have any object class except dMD or configuration.

  3. In AD DS, the generation of objectSid values is constrained by the sid of a domain NC as follows. The sid of a domain NC, the domain SID, is a SID with four SubAuthority values. The root object of a domain NC has objectSid equal to the domain SID, as required by the definition of NC replica. Every security principal object o in a domain NC has o!objectSid equal to the domain SID plus the RID portion (that is, it has five SubAuthority values). The RID portion of o!objectSid is a number not assigned as the RID portion of the objectSid to any other object of the domain, including objects that existed earlier but have been deleted.

    Section 3.1.1.5.2.4 specifies how AD DS assigns RIDs. The same section specifies how AD LDS generates objectSid values for new AD LDS security principals.

Continuing the example, let the example NC be a domain NC, and let the object with name "Peter Houston" be assigned the RID value 2055 (decimal). Then the state of the example NC is as follows.

 (
   "<GUID=5>;<SID=0x0105...94E1F2E6>;
    dc=microsoft,dc=com"
   ( (objectGUID 5) (parent 0) (dc "microsoft")
     (objectClass top ... domainDNS)
     (name "microsoft") (rdnType dc)
     (objectSid 0x0105...94E1F2E6) )
   ( (objectGUID 2) (parent 5) (ou "NTDEV")
     (objectClass top ... organizationalUnit)
     (name "NTDEV") (rdnType ou) )
   ( (objectGUID 9) (parent 2) (cn "Peter Houston")
     (objectClass top ... user) 
     (name "Peter Houston") (rdnType cn)
     (objectSid 0x0105...94E1F2E607080000) )
 )

The DNS name of this domain NC is microsoft.com. Note that the domain SID is a prefix of the "Peter Houston" object's objectSid. Portions of the (long) SID values have been elided for clarity; consider the elided portions to be the following hex digits

 0000000000051500000089598D33D3C56B68

and the example SID will be a valid SID.