A: A shortcut trust is an AD trust relationship that administrators can explicitly define in addition to the trust relationships that AD automatically creates between the domains in an AD forest as part of the AD installation process (dcpromo). Shortcut trusts can speed up inter-domain authentication traffic, as I'll explain in more detail below.
A typical scenario where you would create a shortcut trust is an AD domain tree where a considerable amount of authentication traffic occurs between two domains that are logically linked by an automatically created trust relationship. These automatically created trust relationships are
transitive trust relationships.
With transitive trusts, the trust extends beyond the directly trusted and the trusting domain to any other domain that is linked to the trusted or trusting domain. For example, if both the europe.hp.com and us.hp.com domains trust the hp.com domain, then the europe.hp.com domain implicitly trusts the us.hp.com domain. Transitive trust reduces the number of trusts that are needed for enabling authentication traffic between different domains. In Figure 1, only three trusts are needed—between each parent and child domain in the same AD forest—to enable authentication traffic between all four domains. In a Windows NT 4.0 setup, we would have needed six trust relationships to do the same thing.
Figure 1: Number of trust relationships required in Windows 2008/2003/2000 compared to Windows NT 4.0 (click image for larger view)
Transitive trust is only a logical concept: There's no shared secret (i.e., a shared cryptographic key or password) between the domain controllers (DCs) of the domains that share a transitive trust. This circumstance means that for authentication to occur between two domains on opposite ends of two or more transitive trusts—for example, domain B and domain D of Figure 1, both of which trust domain A in the same AD forest—the authentication process doesn't flow directly between the two domains but along a path known as the trust path. Therefore, all other domains that link the two domains together by means of a transitive trust participate in the authentication process. So in this example, domain A participates when a user from domain B tries to access resources in domain D. This process also means that if domain A is unavailable, users in domain B cannot access resources in domain D.
To help avoid this potential problem, administrators can create shortcut trusts for domains in a forest that aren't directly trusted—these shortcuts remove the dependency on other domains in scenarios such as the one described above. Shortcut trusts can also make sense if cross-domain resource access happens frequently and if the network link to DCs of other domains along the trust path is not sufficiently stable or is fairly slow.
Figure 2 shows how the number of authentication referrals can be reduced and how the trust path used during authentication is shortened thanks to the creation of a shortcut trust.
Figure 2: Reducing the number of referrals with a shortcut trust in a multiple-domain Kerberos logon (click image for larger view)The Key Distribution Center (KDC—this is the Kerberos authentication service that's available on every Windows 2000 and later DC) in the user domain can detect the existence of a shortcut trust when querying AD. The KDC has enough intelligence to leverage the shortcut trust and refer the user directly to the KDC in the resource domain.
To further illustrate the effect of a shortcut trust, let me first explain what happens during a non-interactive (network) Kerberos logon process in a multi-domain environment. Figure 3 shows an AD forest consisting of a parent domain and two child domains.
Figure 3: Non-interactive Kerberos logon in a multiple-domain environment (click image for larger view)
In the example, Bob is logged on to the us domain; both Bob's account and the computer account are defined in the us domain. Bob wants to access a resource that's hosted on a server in the europe domain. The non-interactive Kerberos logon process can be split into the following four steps:
- Step 1: Before Bob can contact the KDC in the europe.hp.com domain, he must have a valid ticket to talk to the KDC of that domain. Because there's no direct trust between europe.hp.com and us.hp.com, Bob must request the ticket via an intermediary domain. Bob first tries to request a ticket for the KDC of the domain closest to the europe.hp.com domain; in the example, this domain is hp.com. Because there's a direct trust between us.hp.com and hp.com, Bob can request this ticket from his proper KDC. The KDC returns a referral ticket that's encrypted with the inter-domain key shared between us.hp.com and hp.com.
- Step 2: Armed with this referral ticket, Bob can request a ticket for the KDC of the europe.hp.com domain from the KDC of the hp.com domain. Because there's a direct trust between hp.com and europe.hp.com, the KDC of hp.com can answer this request. The returned referral ticket is encrypted with the inter-domain key shared between hp.com and europe.hp.com.
- Step 3: With this referral ticket, Bob can finally request a ticket for the resource server from a KDC of the europe.hp.com domain.
- Step 4: With the ticket he received from the KDC in the europe.hp.com domain, Bob can send an authentication request to the resource server.
- Step 1: Bob uses his ticket-granting ticket (TGT) to request from the KDC in the us domain a ticket for the resource server in the europe domain. The KDC in the us domain isn't an authoritative KDC for the europe domain and must refer Bob to the domain closest to the target domain and with which it has a Kerberos trust relationship. Due to the shortcut trust, this is now the europe domain.
- Step 2: The KDC in the europe domain generates a ticket for Bob.
- Step 3: Bob uses the ticket to access the resource server.
Figure 4: The affect of different shortcut trusts on multiple-domain traffic (click image for larger view)
In example A, a shortcut trust is created between two child domains of the user and the resource domain. This shortcut trust won't reduce the referral traffic between the user and the resource domain because the shortcut trust isn't on the referral path between the user and the resource domain. In example B, the shortcut trust will have an effect on the referral traffic because the shortcut trust is on the referral path
