6.1.6.9.3.2 Building Well-Formed msDS-TrustForestTrustInfo Messages

  • Article

The msDS-TrustForestTrustInfo attribute contains a String(Octet) with the data structures specified in the preceding sections. This attribute contains information about the namespaces that are served by a given trusted forest. For example, if forest a.com contains the domains a.com, b.a.com, and c.a.com, then the msDS-TrustForestTrustInfo for a.com would contain the FQDN (2) and NetBIOS names for each domain, as well as the SID space served by each domain. This section details the rules that well-formed msDS-TrustForestTrustInfo messages must follow.

The msDS-TrustForestTrustInfo attribute is written on the PDC for the trusting and trusted domains. Both the trusted and trusting forest have forest functional level DS_BEHAVIOR_WIN2003 or greater.

Some concepts are necessary to understand the algorithm that is used when validating this attribute.

Namespaces

Namespaces are meant to represent those NetBIOS, FQDN (2), or SID values that a trusted forest or domain claims.

Top Level Names (TLNs)

TLNs are an important concept when detecting and resolving conflicts in namespaces between different TDOs, and for determining which forest owns a given namespace. A TLN really corresponds to a forest namespace, and in order to be enabled, the TLN must be unique among all TDOs. For example, the TLN for the forest example.com is example.com. Note that it is possible that the forest example.com could have another domain corresponding to an entirely different TLN (for example, mailservers.com), in which case two TLNs would need to be registered for the example.com forest. TLNs for a TDO are stored in records identified by the ForestTrustTopLevelName Record Type.

TLNs that must be excluded from a namespace are identified by the ForestTrustTopLevelNameEx RecordType. Exclusion becomes necessary if the namespaces of two forests collide (for example, the forests corp.mycompany.com and the forest hr.corp.mycompany.com). These exclusions are set administratively to ensure proper functioning of the domain.

Superior/Subordinate Namespaces

When evaluating all forest trusts, TLNs are expressed as FQDNs (2). Parsing the FQDN (2) allows the concept of superior and subordinate namespaces. For example, for the namespace sample.example.com, the superior namespace (and the TLN) is example.com. Similarly, the sample.example.com namespace is subordinate to the example.com namespace. This allows the routing mechanism to understand that the name sample.example.com is associated with the example.com namespace expressed in the TLN, as it is a subordinate.

Enabled Records vs. Disabled Records

During validation of the Records stored in the msDS-ForestTrustForestInfo, it is possible to have TLN or namespace conflicts. In these circumstances, the conflicting record is disabled. Namespace conflicts are determined using the Record Flags specified in the msDS-ForestTrustInfo data format definitions.

  1. ForestTrustTopLevelName RecordType (0)

    If the TDN / TDA / TDC Flags are present, then the name that is present in the TLN and its subordinate namespaces (as well as all domains whose FQDNs (2) are equal to or subordinate to the TLN) is not used for routing names or SIDs.

  2. ForestTrustTopLevelNameEx RecordType (1)

    If the TDN / TDA / TDC Flags are present, then the name that is present in the exclusion TLN is not used for exclusion purposes, and conflicts will be unresolved. All domains whose FQDNs (2) are equal to or subordinate to the exclusion TLN are not used for routing names or SIDs.

  3. ForestTrustDomainInfo RecordType (2)

    If the NDC or NDA Flags are set, then the NetBIOS name is excluded from routing for the NetBIOS name.

    If the SDA or SDC Flags are set, then the entire domain and all domains whose FQDN (2) names are subordinate to the FQDN (2) name of that domain are excluded from name routing by SID, FQDN (2), or NetBIOS names. The entire subtree of the forest that is rooted at the affected domain is effectively not computed in the trust domain name mappings.

msDS-TrustForestTrustInfo Validation

When the TDO information for a domain is added or changed, or if the DC possessing the PDC FSMO role in the root domain of the forest is freshly started, every TDO with msDS-ForestTrustInfo attributes is validated against all other TDOs. The results of that validation are then rewritten to the DS and replicated to the other DCs in the domain. DCs that do not own the PDC FSMO role treat the attribute as READONLY and internally consistent.

Validation of the matrix of trusted domains and trusted forest information stored in msDS-ForestTrustInfo includes a mechanism to prevent name collisions. Manipulations of this attribute ensure that each namespace is only assigned to a single TDO. If any of the following rules are violated, the colliding RecordFlag is marked as disabled.

The rules for determining whether namespaces collide for ForestTrustDomainInfo Records are as follows:

  1. Each SID corresponding to a domain in a trusted forest is unique among all TDOs and among all of the SIDs listed within the ForestTrustData Records. If not, the Record MUST have the SDC bit in the Record Flags.

  2. Each SID for each domain in a trusted forest does not equal any SIDs within the domains of the local forest. If not, the Record MUST have the SDC bit in the Record Flags.

  3. Each FQDN (2) corresponding to a domain in a trusted forest is unique among all TDOs and among all of the FQDNs (2) and TLNs listed within the ForestTrustData Records. If not, the Record MUST have the SDC bit in the Record Flags.

  4. Each FQDN (2) for each domain in the trusted forest does not correspond to any FQDNs (2) within the domains from the local forest. If not, the Record MUST have the SDC bit in the Record Flags.

  5. Each NetBIOS domain name corresponding to a domain in a trusted forest is unique among all TDOs and among all of the NetBIOS domains listed within the Forest Trust Data records. If not, the Record MUST have the NDC bit in the Record Flags. For conflict resolution, the TDO with the alphabetically longest name is disabled.

  6. Each NetBIOS name for each domain in the trusted forest does not equal any NetBIOS domain name within the domains of the local forest. If not, the Record MUST have the NDC bit in the Record Flags. Local forest NetBIOS names always take precedence over those of trusted forests.

The rules for determining whether namespaces collide for ForestTrustTopLevelName Records are as follows:

  1. Each TLN corresponding to a domain in a trusted forest is unique among all TDOs, and among all of the FQDNs (2) and TLNs listed within the Forest Trust Data records. If not, the conflicting Record has the TDC bit in the Record Flags. For the sake of consistency, since the two TLNs are equal, the first TLN Record that is read is authoritative, and subsequent conflicting Records are disabled.

  2. Each TLN for each domain in the trusted forest does not correspond to any FQDNs (2) within the domains from the local forest. If not, the Record has the TDC bit in the Record Flags.

ForestTrustTopLevelNameEx Records, by definition, cannot conflict.

Additionally, additions to msDS-TrustForestTrustInfo pass namespace consistency checks before the attribute is set. Any failures in the consistency checks cause the attempt to modify the msDS-TrustForestTrustInfo to fail. The following rules dictate the requirements that each trusted forest must match:

  1. At least one ForestTrustTopLevelName TLN Record is specified for each msDS-TrustForestTrustInfo. It is possible for a forest to have more than one TLN if it contains additional TLNs.

  2. All domains listed in the ForestTrustDomainInfo for a TDO are subordinate to the TLNs for that TDO.

  3. All domains listed in the ForestTrustDomainInfo are not subordinate or superior to other TLNs unless an exclusion record for that TLN or domain is registered.

If all of the preceding tests pass, then the entry is written in binary format to the msDS-ForestTrustInfo, replicated, and honored by all DCs in the forest.