Configurations for Domain Controllers from Different Domains

  • Article

Applies To: Windows Server 2008

The following sections explain operations for scenarios in which the domain controllers are from different domains but are in the same site.

Scenario: Writable Windows Server 2008 domain controller and RODC from different domains in the same site

  • Cross-domain authentication fails if the WAN is offline.

  • RODC domain authentication for cached accounts succeeds if the WAN is offline.

  • RODC domain authentication for accounts that are not cached fails if the WAN is offline.

Scenario: Windows Server 2003 domain controller and RODC from different domains in the same site

  • Cross-domain authentication fails if the WAN is offline.

  • RODC domain authentication for cached accounts succeeds if the WAN is offline.

  • RODC domain authentication for accounts that are not cached fails if the WAN is offline.

Scenario: Windows Server 2008 RODC and Windows Server 2008 RODC from different domains in the same site

  • Cross-domain authentication fails if the WAN is offline.

  • RODC domain authentication for cached accounts succeeds if the WAN is offline.

  • RODC domain authentication for accounts that are not cached fails if the WAN is offline.

Each RODC builds a replication topology that excludes the other RODC. For replication, there is no interaction. The RODCs interact for cross-domain authentication, but not directly. The following diagram illustrates the limitations of this functionality, based on how the underlying authentication operations work.

The branch site contains an RODC for domain A and for domain B. A user from domain A, whose computer account is also in domain A, attempts to access a resource on server 1 in domain B. The following sequence occurs:

  1. Using the ticket-granting service (TGS), the client presents a service ticket request to a local domain controller for its domain—in this case, an RODC.

  2. By reading files in the TGS, the RODC determines that the requested resource is in a different domain. The KDC on the RODC must be able to provide the client with a referral ticket. This allows the client to access a KDC in the next domain in the trust path. However, the RODC does not have the trust password. Therefore, it has to forward the request to a writable domain controller in the same domain.

  3. The full domain controller returns the referral ticket to the RODC.

  4. The RODC returns the referral TGT to the client.

  5. The client uses the referral TGT to contact a local domain controller in the target domain (domain B) to request a TGS for the resource.

  6. The domain controller, which again is an RODC, cannot decrypt the request because it does not have the trust password. Therefore, the RODC refers the request to a writable domain controller in the same domain.

  7. The writable domain controller validates the request, issues the service ticket, and returns it to the RODC.

  8. The RODC returns the TGS to the client.

The client can then present the service ticket to the resource.

The RODCs in this scenario must contact writable domain controllers because they do not have the trust password. This means that any new cross-domain authentication requests will not work if the WAN is offline.