8

I've been spending hours upon hours trying to learn and understand Windows Authentication, Kerberos, SPNs, and Constrained Delegation in IIS 7.5. One thing I just don't get is why it is "risky" to leave delegation enabled (i.e. not disable delegation for sensitive accounts) for Admins, CEOs, etc. Can someone please explain this to me in simple terms? Please frame your answer with respect to an intranet environment.

My reasoning is that it shouldn't be a concern, because delegation simply allows a front-end web server, for example, to act on the Windows Authenticated person's behalf when communicating to other servers. If the person has access, they have access, I don't understand why this should be a concern.

Please forgive my ignorance. I'm primarily a developer, but my company is running very lean these days and I'm forced to wear the server admin hat too... unfortunately, it still doesn't fit very well, lol.

Improve this question

2 Answers 2

Reset to default
7

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.

Improve this answer
3
  • First off, incredibly helpful and in-depth answer. Can't tell you how much I appreciate it. :) I still wonder, what is necessary for this to be exploited because people are certainly not going to have access to our executive's credentials. It should also be noted that the systems we are allowing constrained delegation to are accessible by every employee on the network anyway. Also, I am trying to accomplish this with Integrated pipeline mode and NO ASP.NET Impersonation.
    – Chiramisu
    Nov 10, 2012 at 1:23
  • 1
    Even if using integrated pipeline mode, if the auth token is present, it can be leveraged by IIS and whatever application is running. When using Windows integrated authentication, the auth token is part of the http header. It may be useful to try to perform a penetration test on the proposed configuration to determine if what you think is correct.
    – Greg Askew
    Nov 10, 2012 at 2:05
  • Holy crap! Part of the HTTP Header? It must at least be encrypted right? Otherwise that's just insane! Why would Microsoft even make such a ludicrous recommendation? I'm afraid I haven't the first clue about pen testing, so I'll just have to take your word for it. Still, none of the apps on this particular intranet server are internally restricted so I think it would be safe. Tokens are limited time and dynamically generated right? We only restrict certain pages using allow/deny authorization tags.
    – Chiramisu
    Nov 10, 2012 at 9:53
2

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...

Improve this answer
1
  • I greatly appreciate your insights; very helpful. I've long since given up on configuring delegation on our Intranet and fell back to running the AppPool in IIS under a special account with access to the necessary resource as it was previously setup. I hope to revisit this issue and get a real solution in place, but a lack of time and experience with delegation preclude that hope for now. :(
    – Chiramisu
    Jan 10, 2014 at 1:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .