Compartir a través de

3.1.1.1.7 Forest, Canonical Name

  • Artículo

An Active Directory forest is a set of NCs. Every forest contains one schema NC and one config NC. The other types of NCs present in a forest depends on whether it is an AD DS forest or an AD LDS forest:

  • AD DS: Every forest also contains one or more domain NCs, and zero or more application NCs.

  • AD LDS: Every forest also contains zero or more application NCs.

The NCs within a forest are related by their assigned DNs as follows:

  • In AD DS there MUST exist a domain NC root such that the config NC's dn equals Cat("cn=Configuration", root.dn) (where Cat is the string concatenation function). This unique domain NC is called the root domain NC of the forest.

    Describe this DN relationship as "The config NC is a child of the root domain NC". Technically these NCs are not related in the same way that a child object and its parent object are related within an NC; the parent relationship stops at the root of an NC. But their DNs are related in the same way as the DNs of a child object and its parent object within an NC. Given NCs with their corresponding DNs forming a child and parent relationship, it is convenient to refer to the NCs as the child NC and the parent NC.

    In AD LDS, the config NC does not have a parent NC. An AD LDS forest contains no domain NCs, so there is no forest root domain NC, either. The DN of an AD LDS config NC takes the form "CN=Configuration, CN={G}" where G is a GUID in dashed-string form ([RFC4122] section 3). For example,

    CN=Configuration, CN={FD783EE9-0216-4B83-8A2A-60E45AECCB81}

    is a possible DN of the config NC in an AD LDS forest.

  • The schema NC is a child of the config NC, with RDN "cn=Schema".

  • If short and long are NCs with DNS names (domain NCs or application NCs), and short is a suffix of long, then each DNS name obtained by removing DNS name components successively from the front of long until the result is short MUST also name NCs with DNS names. For instance, if a forest contains both NCs microsoft.com and nttest.ntdev.microsoft.com, it MUST also contain NC ntdev.microsoft.com.

  • If app is an application NC and dom is a domain NC, then dom MUST not be a child of app.

  • If root is the root domain NC and dom is another domain NC in the forest, then root MUST not be a child of dom.

Extend the running example by adding the config NC and schema NC as follows.

 (
   "<GUID=4>;cn=Configuration,dc=microsoft,dc=com"
   ( (objectGUID 4) (parent 0) (cn "Configuration")
     (objectClass top ... configuration)
     (name "Configuration") (rdnType cn) )
 )
 (
   "<GUID=8>;cn=Schema,cn=Configuration,dc=microsoft,dc=com"
   ( (objectGUID 8) (parent 0) (cn "Schema")
     (objectClass top ... dMD)
     (name "Schema") (rdnType cn) )
 )
 (
   "<GUID=5>;<SID=0x0105...00000000>;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) )
   ( (objectGUID 6) (parent 2) (cn "DSYS")
     (objectClass top ... group) 
     (name "DSYS") (rdnType cn)
     (objectSid 0x0105...94E1F2E60B080000)
     (members
       "<GUID=9>;<SID=0x0105...07080000>;
       cn=Peter Houston,ou=NTDEV,dc=microsoft,dc=com" ) )
 )

This example illustrates the dn relationships between the root domain NC, config NC, and schema NC. It shows that in a forest, the parent relationship does not cross NC boundaries. It also illustrates the object classes of the config NC and schema NC root objects and the lack of a sid in these NCs. It does not show the contents of these NCs, which are specified in sections 6.1 and 3.1.1.2.

Every object in a forest has a canonical name. The canonical name of an object is a syntactic transformation of its DN into something resembling a pathname that still identifies the object. A canonical name is a DNS name, followed by a "/", followed by a sequence of zero or more names separated by "/". The DNS name is the translation of the final sequence of "dc=" DN components into an equivalent DNS name (following [RFC2247]). The sequence of names is the sequence of names in the non-"dc=" DN components, appearing in the reverse order to the order they appeared in the DN. Here are several examples of this translation drawn from the preceding example.

 DN:             cn=Peter Houston, ou=NTDEV, dc=microsoft,
                 dc=com
 canonical name: microsoft.com/NTDEV/Peter Houston
  
 DN:             cn=Configuration, dc=microsoft, dc=com
 canonical name: microsoft.com/Configuration
  
 DN:             dc=microsoft, dc=com
 canonical name: microsoft.com/

Active Directory supports a constructed attribute canonicalName on every object. Its value is the object's canonical name.