The Most Confusing Dialog Box in Active Directory

One of Microsoft’s most blogged-about and documented technologies is Kerberos authentication. That’s a little odd, given that there have been no significant changes to Kerberos and its functionality since the release of Windows Server 2003. And yet Kerberos keeps getting documentation.

This ongoing need to clarify how Kerberos works and how it fails is a result of the fact that—although Kerberos remains the same—the services that use it and the ways they use it are often unique. The aspects that remain the same in each scenario, however, are what the settings in Active Directory (AD) are intended to address, and the difficult-to-interpret messages you’ll see when things fail.

In this article, I’ll try to provide some clarity about what I call “The Most Confusing Dialog Box in AD,” which is the Delegation tab in the object’s Properties in the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in (dsa.msc). I’m going to talk about what you can expect to see at the attribute level for the different configurations. This is important because if you know what the different settings that can be configured in AD for a service do, you can make sense out of what settings you might need for an application or service that uses Kerberos delegation.

A Simple UI

Why spend time looking at a “simple” UI? In Microsoft support, we spend time delving into items like this because once you know how things work under the hood, you have a better idea of how to fix them when they’re broken. So, let’s go over what these setting are. If you open the Active Directory Users and Computers snap-in and go to a computer account’s Properties, you’ll see the Delegation tab—provided that your forest is at Server 2003 Forest Functional Level or above. Figure 1 shows the tab in question.

Now, let’s dissect what the radio buttons in that figure do. In the matrix that Figure 2 shows, I interpret what the selections really mean and I share alternative names that I might have used if I’d named them.

Before we get too deep into the settings, let’s talk briefly about what Kerberos delegation is. Delegation (aka impersonation or simple delegation) is the act of an application or service getting Kerberos tickets to gain access to resources on a remote computer on behalf of a user. The identity that is trusted for that delegation is the service account that the application is running as. This allows the application to gain access only to resources the user would have access to and to provide that information back to the user. A typical scenario would be a web server connecting to a SQL Server system to display data to a user on a web client.

The top two settings in Figure 2 are self-explanatory. The third is essentially Constrained Delegation (KCD), which is like simple delegation but guarantees that the identity being impersonated will be impersonated only to specific services on specific computers. This setting is a security enhancement because where and how a user can be impersonated is limited, so that if a service identity which is being trusted for delegation is ever compromised the effect is limited to being able to access only those specific resources on the remote servers that are manually selected for constrained delegation.

The fourth setting in Figure 2 allows KCD as well as Services for User. S4U allows for more advanced functions—such as protocol transition—and is actually pretty complex. What is protocol transition? It occurs when a client authenticates with a protocol other than Kerberos incoming to the computer and then is transitioned to Kerberos. For detailed documentation about S4U, check out “Exploring S4U Kerberos Extensions in Windows Server 2003” and “Protocol Transition with Constrained Delegation Technical Supplement.” Those resources target programming, not administration, but from an administrator’s point of view, it’s important to understand what S4U is, how it’s configured, and whether you’re using it. To that end, here’s an IT administrator’s short-and-sweet list of what S4U allows:

Under the Hood

Now, let’s go over what happens under the hood when you alter those four settings by using LDP to view the attributes set for each of these configurations. LDP is a tool installed with the AD Domain Services role, by default, which can be used as a GUI-based LDAP-querying tool. LDP is basically a tool to let you construct your own LDAP queries and see the results in a relatively nice, friendly interface. The added value in using LDP to look at values such as userAccountControl is that LDP will interpret computed flag values into human-readable results instead of leaving them as a combination of numerical values. To be fair, later versions of adsiedit.msc will perform that flag-value computation for you as well, but I’m partial to the “old school” LDP tool and its versatility.

In other words, in Windows Server 2008 and later, ldp.exe and adsiedit.msc are useful for automatically translating values and flags (e.g., userAccountControl) so that you don’t have to open calc.exe and refer to the online documentation on MSDN or in the Microsoft Knowledge Base.

I’ll show you the Active Directory Users and Computers snap-in you work with, then show you the changed attributes in LDP.

Do not trust for delegation. Let’s start with an account that isn’t trusted for delegation at all. In Figure 3, note that Test2 isn’t trusted and that the userAccountControl value of 1020 hexadecimal (4128) translates to WORKSTATION_TRUST_ACCOUNT and PASWD_NOTREQD.

Trust for delegation. Figure 4 shows an account that is trusted for delegation. You can clearly see TRUSTED_FOR_DELEGATION in the translated userAccountControl flags. This flag is what allows simple, unconstrained Kerberos delegation to take place for that service identity.

Trusted for delegation to specified services. These next settings can make or break you if you’re looking to use S4U or KCD. In this case, you’ve selected the Trusted for Delegation to specified services button, as well as the first choice underneath that, Use Kerberos only. As Figure 5 shows, this option sets the userAccountControl flag back to WORKSTATION_TRUST_ACCOUNT only and populates the MsDS-AllowedToDelegateTo attribute automatically with any selected services you’ll allow delegation to. This attribute isn’t populated or touched by any other routine. These entries are the specific services on the specific computer that delegation will be allowed to.

The second option here is the less secure Use any authentication protocol radio button, which allows for protocol transition and other advanced uses. In addition to the MsDS-AllowedToDelegateTo entries, this changes the userAccountControl attribute to contain the flag for Trusted_To_Authenticate_For_Delegation (aka T2A4D), as you see in Figure 6.

Without the T2A4D flag being present, you can expect protocol transition to fail. This flag isn’t used or populated by any other component. Note that this simple radio button is extremely important because without it selected, S4U2Self, S4U2Proxy, and protocol transition will behave differently and can cause problems for applications and services that use expect these kinds of tickets. In the case of protocol transition, it will fail. No ticket will be issued. For S4U2Proxy and S4U2Self, they will fail to have the forwardable flag present, which also results in a failure in every case for S4U2Proxy and in situations where S4U2Self needs to send a ticket to another service or host.

Do It Yourself

What happens if the service account that an application or service is running as must do an action that requires protocol transition, and the Delegation tab is configured for Use Kerberos only and not Use any authentication protocol? The client application failure could be an Access Denied error when you’re attempting to access a resource on the network, or could be a silent failure over to NTLM and succeed with access, or could give an unexpected application-specific error. The ambiguity of how the failure would appear accents some of the pain of this kind of problem. However, the most likely result would be an Access Denied error message. In this situation, be sure to check the application or service documentation to see if they state that protocol transition or TGT-less service ticket requests will take place. The problem is that most documentation doesn’t truly understand what KCD configuration means, and as a result it doesn’t explain it well or even at all.

The do-it-yourself way to figure out a failure would be to simply gather a network trace from the server that’s trusted for delegation as the issue happens. Once you have that capture, filter it for Kerberos (Kerberosv5 in Microsoft Network Monitor or kerberos in Wireshark). The service ticket request (TGS_REQ) will be sent to the AD Kerberos Distribution Center (KDC) for the ticket, and the service ticket request will contain KDC Options that have the Constrained Delegation flag set. The server response (TGS_REP) will contain the error KDC_ERR_BAD_OPTION, which will be easily seen in the network parser, and the ticket won’t be issued.

More information about how the Microsoft Kerberos implementation works can be found in the online Open Protocol specification. “Kerberos Protocol Extensions” provides general Kerberos documentation, and “Kerberos Protocol Extensions: Service for User and Constrained Delegation Protocol Specification” provides documentation about Kerberos Constrained Delegation and S4U.

Perfect World

Hopefully, this breakdown of what the UI settings for Kerberos are and what they correspond to in AD helps make sense of things. In a perfect world, the documentation of the services that you’re administering would provide the technical guidance on how to configure them correctly for authentication. But in case they don’t, this information should improve your tool set. Knowing what should be present when things are working is half the battle.