Posted on March 20, 2012 by Marc Boorshtein
All the Active Directory forests are a stage, and all the objects merely players; they have their authentication and their data; one object in its time plays many parts, its acts being impersonated.
My deepest apologizes, once again, to William Shakespeare; however, I felt his quote on “all the world being a stage” was a good introduction to the concept of impersonation. A colleague once told me he felt that impersonation was “black magic”. It’s something that often comes up and I thought I'd spend a few minutes talking about what impersonation is, why it affects you and how it can be very useful.
So the first question is, what is impersonation when we're talking about Active Directory? Simply put, impersonation is when the current context of action being taken on occurs using a user's context other then the currently logged in user. OK, that wasn't so simple. It’s similar to how an Executive Assistant cans scheduled meetings on behalf of the person the EA works for. It comes from their calendar but the EA does NOT know their boss' password. Impersonation allows you to do the same thing inside of Windows security.
AD is based on the venerable Kerberos protocol. This reaches into how security on Windows based platforms work in general. For instance, when you login to your portal without ever entering a user-name and password, what’s happening is the browser is generating a Kerberos ticket for you. The key benefit of Kerberos is that the Administrator doesn't know a user's password and the password never travels across the network. This means you need to know your password to generate a Kerberos ticket for yourself.
What if you don't have or know your password? For instance, if you're authenticating via identity federation or a certificate? How can you generate a ticket to represent yourself? That's where impersonation comes in. Microsoft introduced the s4u2self and s4u2proxy Kerberos extensions with Windows 2003r2 to handle these situations. These protocols are also known by “constrained delegation” and “protocol transition” with the idea being that you can designate a service, such as IIS or ISA, to generate a Kerberos ticket on your behalf without knowing your password.
This can be very powerful but also very dangerous. Since AD isn't validating the user's password, it’s trusting the service to generate a ticket on the user's behalf. To help mitigate security risks, Microsoft makes you specify exactly what services can be delegated to. This makes sure a web server that's allowed to create tickets for SQL Server access can't generate a ticket that can log you into a web application.
In the next installment in this series, I'll take you through the basic steps of creating an impersonation user for IIS and what it can be used for.