Two examples:

  1. Constrained delegation enables impersonation without having the user's credentials or authentication token. For an example, see this answer.

  2. In a more typical meat-and-potatoes unconstrained delegation scenario, whether it is windows integrated authentication or forms authentication, having delegation access to a user's authentication token is very powerful. That literally means that token can be used to impersonate that user to access any network resource. Anyone involved in that process, such as a developer, could use that in a nefarious way to obtain unauthorized access.

In both examples, if the box is checked for "account is sensitive and cannot be delegated", these are not security issues. It's also possible to architect a system/feature where these capabilities do exist, but are tightly controlled.

That box should be checked for administrative accounts, such as members of the Enterprise Admins group, because (hopefully) those accounts rarely need to use applications that require impersonation. It is also be a good idea for senior executives who have access to sensitive information, such as a CIO, COO, head of Finance/Treasury, etc.

So the bottom line is, Microsoft provided that checkbox and the accompanying warning for a very good reason, and it should not be dismissed or taken lightly unless it can be demonstrated that a particular scenario does not have undesirable risk exposure, or some compensating control. This usually involves vetting by some qualified person(s) that are not involved in the actual implementation or development of an application or system.


I've setup 1000's of customers with delegation most of the unconstrained. I think it is important to note that if you don't trust your application (lets say deployed on IIS) or you are giving our your delegated service account credentials for others to use freely, then constrained delegation is probably a good idea. However if you don't expect anyone to have the ability to rewrite your application, you keep your service account credentials safe, and you trust that your apps are only going to delegate to the service(s) they were designed for, then the there is usually nothing to worry about. I've seen some "security conscious" customers focus very heavily on issues like this while their resources could be better spent working on real security threats...