I am trying to impersonate a user going from my site into a website that requires ad credentials. I know the user id already just not the password. I was wondering if there was a way in code that I can connect to ad and impersonate a user with just the user id.
The whole purpose is to allow a proxy logon service.
I am a bit nervous to answer a question with -5 votes. I do want to point out that there exists such a feature. It’s called Protocol Transistion extension. It’s also known as S4USelf
Microsoft invents Protocol Transistion because Active Directory is mainly using Kerberos to do the authentication. However, in many cases, Kerberos port is blocked in the Internet environment. So, application cannot use Kerberos to do the authentication. This is especially true for the web application, where normally only port 80 is opened. To solve this problem, Microsoft allows the authentication being done by some other mechanism, for example, using ASP.NET form based authentication. Then, the proxy server can obtain the Kerberos ticket for whatever user it just authenticated using it’s own mechanism. In this process, no Active Directory password is required. However, please note that Microsoft does expect application using this approach to obtain the Kerberos ticket will do its own authentication against the user. For example, you might have a SQL server database storing a set of username and password. Your application authenticates using the username and password stored on your SQL Server database and then obtain the Kerberos ticket for the specified user.
As many of you pointed out this looks like a big security hole if this can really happen. Here is the fine print. In order to obtain a Kerberos ticket using Protocol Transistion approach, your process has to have Act as part of operating system privilege. This is a very high privilege in the system. To make it simple. If you just logged in as a normal AD user account and try to run a program using Protocol Transistion approach to obtain a domain administrator ticket, it’s not going to work because you don’t have Act as part of operating system privilege. By default, your
NT Authority\LocalSystemaccount will have this privilege. So, in order to do that, in many cases, you just write a service and set the service account to useNT Authority\LocalSystem. The service will have the capability to obtain whatever Kerberos S4USelf ticket you need from the Active Directory.Wait a minute. Many of you will say that this is still a security hole because I may be a local administrator on a particular workstation machine. Then, I can install whatever services that I like. I can create a service myself and use S4USelf to obtain a Domain Administrator ticket and access some important information in the enterprise environment. Well… this is not true. Microsoft makes the S4USelf Kerberos ticket so special that it can only be used on the machine that requests the ticket. In other words, you cannot use the S4USelf ticket on the network to request any other services. That sounds more reasonable, right? The access is limited to that particular machine only. Yes, I know it’s still hard to accept the fact that a person can impersonate another user account without knowing the password but the feature is there.
Along this line, there is another crazy thing called Constraint Delegation. It’s also known as S4UProxy. It basically extends this impersonation capability to the network resources. That means using the S4USelf ticket, you can get a S4UProxy ticket. With the S4UProxy ticket, you can access the selected network resources using the impersonated identity without providing any password to Active Directory. Again, this looks very crazy but here is the details. First of all, by default, all the machines joined to Active Directory cannot request S4UProxy ticket. Domain Administrator has to turn on a flag on the computer object to allow this happen consciously. Domain Administrator should well understand that granting this basically like saying that I treat this machine like a domain controller in a domain. It’s holding the key to the kingdom. Secondly, not all the services can be obtained by S4UProxy approach. Domain Administrator can select what services are allowed to use S4UProxy explicitly by specifying the SPN on the computer object. That’s why it got the name Constraint Delegation. It looks crazy but it’s really not that bad.