Kerberos constrained delegation to domain controllers

You can mitigate the risk by checking the box on the account tab > account options for "Account is sensitive and cannot be delegated" for your privileged administrative accounts.

Constrained delegation is somewhat unusual and misunderstood feature of Active Directory. It isn't new; it has been around since Windows 2003.

Prior to "constrained" delegation, delegating the capability to impersonate another user account to perform functions on their behalf had minimal"constraints". This means that with unconstrained delegation, if you have a a "delegation-level" token for another user account, you can impersonate that account and access any resource on any server as that user account. This was, as you can imagine, undesirable in higher-security environments. The tokens are typically made available when the user logs on either by entering their credentials, or by using integrated Windows authentication. If using Windows auth, you need Kerberos to get a "delegation-level" token, as opposed to an impersonation or identity token. IIS exposes user tokens and makes it easy to use this feature.

Constrained delegation addressed the risks in the following ways:

• the service impersonating the account may only access resources in the domain where the impersonating account and services are located (typically a "resource" domain). It cannot access resources in trusted domains. (Although it can impersonate any account from any trusted domain).
• limiting the servers to which the impersonating service could access;
• further limiting the scope by specifying the type of service (CIFS, LDAP, SQL, etc).

One other twist though: with Constrained delegation, it is possible to create a token for and impersonate any user account in any domain, and that account does not need to first enter credentials, as with unconstrained delegation. It is trivial to write only a few lines of .NET code to do this, providing the appropriate permissions and the server where the impersonation is performed is setup correctly.

So yes, this is powerful, which is why Microsoft provides the scary warnings in documentation for delegation topics. But with that box checked, the privileged accounts cannot be impersonated.

Note that in some scenarios, the risk exposure is a matter of perspective. Some would prefer the delegation and impersonation capability over transmitting passwords beyond a security boundary. If in an environment where there aren't passwords (such as with some smart cards), impersonation and delegation may be one of the few ways to perform certain functions in a practical way.

I haven't used this feature of Citrix, but if it is possible to use the Global Catalog (GC:// versus LDAP://, port 3268/3269 instead of 389/636), this could mitigate the risk further, because the Global Catalog is read-only. They should not need to update AD if only authenticating.

This is what I got from Microsoft support.

Unconstrained delegation - Server should have ticket from user to impersonate, it can't get credential for any user without knowing the password or getting a ticket first.

constrained/kerberos only - Server should have ticket from user to impersonate, it can't get credential for any user without knowing the password or getting a ticket first.

Constrained/protocol transition - Server can impersonate any user without knowing their password or getting a ticket first (MOST RISKY).

Only effective mitigation at AD level is to enable "account is sensitive, do not delegate" flag for high privilege users such as domain admins.

More details:

http://msdn.microsoft.com/en-us/magazine/cc163500.aspx

and

http://technet.microsoft.com/en-us/library/cc738207(WS.10).aspx