KCD with Cross-Forest Accounts

Authors:

Jim Harrison, Program Manager, ISA SE

Yuri Diogenes, Support Engineer, CSS Security

Mohit Saxena, Security Tech Lead (ISA & IAG)

Doron Juster, Senior Developer, ISA SE

What is KCD?

“KCD” stands for “Kerberos Constrained Delegation”; a Windows extension to the MIT-created authentication protocol, Kerberos v5. Much has been written on this particular subject and my favorite documents are listed below:

1. Request for Comments memo 1510 The Kerberos Network Authentication Service (V5)

2. TechNet article Windows Server 2003 Kerberos Extensions

3. TechNet article Kerberos Protocol Transition and Constrained Delegation

4. TechNet article [MS-KILE]: Kerberos Protocol Extensions

5. TechNet article Kerberos Constrained Delegation in ISA Server 2006

6. TechNet article Enabling Kerberos constrained delegation (IAG 2007)

7. TechNet article About Kerberos constrained delegation on Forefront TMG

8. TechNet article Troubleshooting Kerberos Delegation

9. Microsoft knowledgebase article 942637 A user cannot access a Web site that is published in ISA Server 2006 by using Kerberos constrained delegation if the user is not in the same domain as the ISA Server computer

10. Microsoft Knowledgebase article 947861 Authentication of trusted users fails on a Windows Server 2003-based server if the UPN format is used and if the value of the LmCompatibilityLevel entry is equal to or larger than 3

11. Microsoft Knowledgebase article 949015 Applications that perform KCD delegation may not finish the S4U process on a computer that is running Windows Server 2008 or Windows Server 2003

12. ISABlog article ISA Server 2006 form based authentication problem using UPN logon format on a multiple domain environment

13. ISA Server 2006 Service Pack 1 (includes the fix from MSKB 942637)

KCD provides the ability to invoke strong authentication using a trusted provider (the Key Distribution Center) at nearly all protocol levels. I say “nearly” because the published web server is trusting ISA to determine that the user really is who they say they are. This is an implicit trusted authentication, rather than an explicit trusted authentication as would be provided if the user authenticated using Kerberos directly with the published server. You should also note that except for IAG Service Pack 2, when IAG is in use, ISA Server is the component responsible for handling KCD. Since this is the case, we’ll only refer to ISA from now on.

The Limitations

Windows Requirements

1. KCD is limited to Active Directory domains which are:

   1. Windows 2003 domains configured as “Windows 2003 Native”

   2. Windows 2008 domains configured as “Windows Server 2008” or “Windows Server 2003”

2. KCD is limited to machines which exist in the same domain. For example, an ISA server in domain1.forest1.tld cannot use KCD to authenticate to a published web server in any other domain, regardless of the trust relationship.

3. KCD using (authentication) protocol transition requires bi-directional (two-way) trust. Since protocol transition is always in use when ISA performs KCD, bi-directional trust is always required for ISA -employed cross-domain and cross-forest KCD. If for any reason, you cannot satisfy the bi-directional trust requirements, ISA cannot perform KCD for cross-forest or cross-domain accounts.

Known Issues

1. MSKB 942637 explains the details of an ISA 2006 hotfix which resolves a problem that caused KCD to fail if the user account was from a trusted domain (this fix is included in ISA 2006 SP1)

2. MSKB 947861 explains the details of a Windows 2003 hotfix which resolves a problem that can cause KCD to fail when LmCompatabilityLevel is equal to or larger than 3. What’s interesting about the Method 2 workaround in this KB is that it may actually confuse the hapless ISA administrator by exposing the next problem …

3. MSKB 949015 provides a workaround for a Windows design limitation related to KCD for cross-forest accounts which use unqualified domain names (NBDomain). By default, KCD S4U2Self calls for cross-forest accounts behaves as listed in the following table:

   Table 1: Credentials format and KCD state

Why does KCD Fail for Certificate Authentication?

As stated in MSKB 281245, Windows certificate authentication requires that a certificate used for authentication must include the user account in UPN format (Account@FQDN) in the SAN (Subject Alternative Name) attribute. Because the UPN-format domain name is fully-qualified (FQDN), it may seem counter-intuitive that KCD should fail for certificate authentication. The reason KCD does fail is because the process operates like this:

1. ISA obtains a handle (programmatic reference) to the client certificate from Schannel after the user presents the client certificate

2. ISA obtains a handle to the user’s security context by passing the client certificate handle in a call to WinAPI AcquireCredentialsHandle(Schannel)

3. ISA obtains a struct (data formatted in a specific manner) containing the user’s name and domain in a call to WinAPI QueryContextAttributes(Schannel)

4. ISA calls WinAPI LsaLogonUser() as described in MSKB 949015 to perform KCD for the authenticated user account

Because the information ISA obtains in step 3 provides the NBDomain name, ISA is unable to call WinAPI LsaLogonUser() using the account UPN, as would be the preferred method. Since the KDC is tasked with sorting out this question, the resolution steps described in MSKB 949015 assists the KDC in determining the FQDN from the NBDomain name provided by ISA, and can now locate the account domain’s KDC.

Successful and Failing Scenarios

Notes:

1. The following diagrams describe the domain and forest trust relationships between the user account and the two hosts involved in KCD authentication.

2. All of the scenarios assume that the user credentials are presented to ISA using NBDomain or Client Certificate.

3. The following terms are used for all of these diagrams:

   • “KDC”: the Kerberos Key Distribution Center (AKA “domain controller”)

   • “KCD domain”: the domain where the ISA performs KCD to the published web server

   • “KCD pair”: the ISA and published web server

   • “User account”: the account being authenticated by ISA

   • “Account domain”: the domain where the user account resides

   • “Domain hop”: a KDC-to-KDC relationship; contextually similar to IP routing hops

Successful Root Domain KCD

Figure 1

In figure 1, the user account and KCD pair all reside in root domains of their respective forests and the forest trust implicitly defines a direct domain trust between roota.com and rootb.com domains. The effective authentication distance between the KDCs in the KCD domain and the account domain involves a single domain hop. In other words, the KDC for roota.com can directly resolve the rootb.com account NBDomain name, locate the rootb.com KCD and obtain a ticket for ISA to authenticate the user account to the published web server.

Successful Child Domain KCD

Figure 2

In this scenario, the KCD pairs and the user accounts reside in the same forest. Since all KDC in a forest tree can resolve each other’s NBDomain names, this scenario will also provide successful KCD functionality for the user accounts.

Failing KCD Scenario A

Figure 3

In figure 3, the KDC pair in the roota.com domain and user account in the childb.rootb.com domain are separated by two domain hops across the forest trust. In this case, KCD will fail because the roota.com KDC is unable to locate the childb.rootb.com domain KDC using the childb NBDomain name.

Failing KCD Scenario B

Figure 4

The scenario depicted in figure 4 is a mirror image of that shown in figure 3; the KDC pair in the childb.rootb.com domain and user account in the roota.com domain are separated by two domain hops across the forest trust in the opposite direction. In this case, KCD will fail because the childb.rootb.com KDC is unable to locate the roota.com domain KDC using the roota NBDomain name.

Failing KCD Scenario C

Figure 5

In figure 5, the KDC pair in the childb.rootb.com domain and user account in the childa.roota.com domain are separated by three domain hops across the forest trust. In this case, KCD will fail because the childb.rootb.com KDC is unable to locate the childa.roota.com domain KDC using the childa NBDomain name.

Wrap-Up

It doesn’t matter how deep the domain structure is built; if the KCD and account domains are separated by more than one domain hop across a forest trust, KCD will fail when the user credentials are provided using NBDomain names. There are two possible solutions to this limitation:

1. Apply the resolution steps indicated in MSKB 949015

2. Create a bi-directional domain trust between the KCD and account domains.

In general, the preferred option is #1, since it limits trust management to the forest level. There may be times when option #2 is preferred, such as when the tree structure for the trusted account domain forest is complex and / or deep.