SharePoint 2013 / IIS 7.5 Impersonation/Delegation/Double Hop

user456151 picture user456151 · Aug 6, 2012 · Viewed 7.3k times · Source

Ok, I have spent about 15 hours trying to resolve this problem and I have finally been resigned to posting here to try to get it resolved. I know this post is very long but I have done all the normal things that I'm going to be told to try so I want to make sure that it is clear so we don't waste time on that.

I have a Win Server 2008 R2 virtual machine hosted on a ESXi 5.0 server. On this server I have installed SharePoint Foundation 2013 Preview as well as all pre-requsites etc. I am running everything off this one server (MSSQL, IIS 7.5, SharePoint services) as we will have very limited usage and only have around 30 users. One thing I desperately needed to add to SharePoint is the ability for users to modify their information in Active Directory (Server 2003) as our AD is barely populated and is outdated. I've found a perfect WebPart and it works wonderfully for editing users.

The problem comes in when I want to configure the WebPart to allow the user to only edit themselves. The WebPart (properly) uses this line of code in C#.NET:. to get the currently logged in Identity that was authenticated with Windows Authentication in IIS. Instead however, this is returning the local user NT AUTHORITY/IUSR. (I know this is not news to anyone).

System.Security.Principal.WindowsIdentity.GetCurrent().Name;

So I began my research and made sure of the following things.

In my web.config for SharePoint, I have the following:

<authentication mode="Windows" /> <identity impersonate="true" />

In IIS, I have the following Authentication settings for the IIS website which houses my SharePoint installation:

Anonymous Authentication    Disabled
ASP.NET Impersonation       Enabled
Basic Authentication        Disabled    HTTP 401 Challenge
Digest Authentication       Disabled    HTTP 401 Challenge
Forms Authentication        Disabled    HTTP 302 Login/Redirect
Windows Authentication      Enabled     HTTP 401 Challenge

So I know the site is still logging in with the anonymous user even though I have anonymous authentication disabled. I came across info about the double-hop issue which matches my problems and I came across this link and followed all the directions in this post: http://blogs.technet.com/b/taraj/archive/2009/01/29/checklist-for-double-hop-issues-iis-and-sql-server.aspx. After each step, I checked for any change in behavior of the application but never found any.

In summary I did the following:

  1. I set up a domain user account to run the application pool. For testing, I made this user a member of the Domain Admins group.
  2. I changed a line in web.config to <add key="aspnet:AllowAnonymousImpersonation" value="false" /> (it was true). This prevented the the NT AUTHORITY\IUSR user from running the application and instead it ran under the domain account I created to run the app pool. I could now log in to SharePoint and access my WebPart, however as expected, it presented me with the AD information for the domain user running the App Pool, rather than the domain user who had authenticated. So I know the WebPart is working and has the necessary permissions etc but System.Security.Principal.WindowsIdentity.GetCurrent().Name; is still returning the user running the app pool ie. impersonation is still not working
  3. In AD Users and Computers, I granted Trust this computer for delegation to any service for the virtual server this all runs on.
  4. Since I had no "Delegation" tab for the domain user account running the app pool, I had to register an SPN for the user. After registering all SPNs I copied from the server's list of SPNs and also a couple http SPNs I found online, and also setting Trust this user for delegation to any service on the user, there was no change in the behavior of the application.
  5. I made sure the domain user I was logging in with was not protected from delegation
  6. I went into the local policy editor on the SharePoint server and I made sure the domain user running the app pool was allowed to "Act as part of the operating system" and "Impersonate a client after authentication".
  7. Other things I tried
    • Add Negotiate:Kerberos as an authentication provider for Windows Auth on the IIS website
    • Confirmed presence of these two lines in SharePoint web.config:

Below are my SPN records on the DC:

setspn -l SPserver
Registered ServicePrincipalNames for CN=SPserver,CN=Computers,DC=DOMAIN,DC=local:
    MSSQLSvc/SPserver.DOMAIN.local:appPoolUser
    WSMAN/SPserver
    WSMAN/SPserver.DOMAIN.local
    TERMSRV/SPserver
    TERMSRV/SPserver.DOMAIN.local
    RestrictedKrbHost/SPserver
    HOST/SPserver
    RestrictedKrbHost/SPserver.DOMAIN.local
    HOST/SPserver.DOMAIN.local



setspn -l appPoolUser
Registered ServicePrincipalNames for CN=appPoolUser,OU=Utility,OU=Users,OU=Company Name,DC=DOMAIN,DC=local:
    http/subdomain.domain.com
    http/SPserver.DOMAIN.local
    RestrictedKrbHost/appPoolUser.DOMAIN.local
    RestrictedKrbHost/appPoolUser
    MSSQLSvc/appPoolUser.DOMAIN.local:appPoolUser
    HOST/appPoolUser
    HOST/appPoolUser.DOMAIN.local

I restarted the server and IIS several time throughout this process as well. Still when I log in, my Web Part identifies me as the user running the application pool. I know there are work around like using a Classic mode app pool but that is deprecated. There are other ways to get the correct name in .NET as well but I don't want to have to change the Web Part and more importantly, this is the correct way to do it and I should be able to get it working. I don't want to have to continuously work around it.

If anyone has any more ideas of what might be causing the problem, I would LOVE to hear them.

Answer

Tomasz picture Tomasz · Oct 10, 2012

Not sure if you're having issue still, the following post might help. Double Hop Impersonation, Protocol Transitioning and Constrained Delegation in ASP.NET 4