Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Setup:

Forest Functional Level: Windows 2003
All DCs - Windows 2003 64 bit SP2

Requirements:

Citrix server wants to use Kerberos delegation for SSO purpose. They want to create Kerberos constrained delegation from Citrix presentation server to local DCs for CIFS and LDAP services.

I fear that it would allow administrators on the presentation server to impersonate domain admins against LDAP service on the DCs and make unauthorized changes in AD.

Questions:

  1. Is my assumption correct?
  2. If yes, how easy it would be to do that?
  3. What are the operational repercussion of allowing such delegation on maintaining local DCs in that site? (We have 200+ DCs globally and 10 DCs in site where delegation is asked for)
share|improve this question
    
It is a bit unclear what do you mean by delegation? –  yarek Jan 23 '12 at 19:27
    
@yarek Its Kerberos delegation. Greg below has answered the basics. –  KAPes Jan 23 '12 at 20:50
    
this Microsoft-invented terminology is a bit confusing from the Kerberos perspective: they mean Kerberos credentials forwarding, right? –  yarek Jan 24 '12 at 20:45

2 Answers 2

up vote 2 down vote accepted

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.

share|improve this answer
    
Thanks Greg for the detailed answer. I was specifically worried about the situation you describe 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. well this delegation is to LDAP/DCname.com SPN and I guess it is required for login. –  KAPes Jan 23 '12 at 20:45

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

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.