Well, I spent about 15 hours trying to solve this problem, and I finally resigned to posting here to try and solve the problem. I know this post is very long, but I did all the normal things that they will tell me to try, so I want to make sure that it is understandable, so we do not waste time on it.
I have a Win Server 2008 R2 virtual machine hosted on an ESXi 5.0 server. On this server, I installed a preview of SharePoint Foundation 2013, as well as all preliminary requsites, etc. I run everything from one server (MSSQL, IIS 7.5, SharePoint Services), since we will have very limited use and will have about 30 users. One thing that I desperately needed to add to SharePoint was the ability of users to modify their information in Active Directory (Server 2003), since our AD was barely full and outdated. I found the perfect WebPart and it works great for editing users.
The problem arises when I want to configure WebPart to allow the user to edit themselves. WebPart (correctly) uses this line of code in C # .NET :. to get the identifier that was currently registered, which was authenticated using Windows authentication in IIS. Instead, however, this returns the local NT AUTHORITY / IUSR user. (I know this is not news to anyone).
System.Security.Principal.WindowsIdentity.GetCurrent().Name;
So, I began my research and was convinced 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 options for the IIS website where my SharePoint installation is located:
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 that the site is still logged in with an anonymous user, even though anonymous authentication is disabled. I came across information about a double-hop problem that matches my problems, and I came across this link and followed all 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 changes in the behavior of the application, but did not find it.
In conclusion, I did the following:
- I set up a domain user account to start the application pool. For testing, I made this user a member of the Domain Admins group.
- I changed the line in web.config to
<add key="aspnet:AllowAnonymousImpersonation" value="false" /> (that was true). This prevented the NT AUTHORITY \ IUSR user from starting the application, but instead it was running under the domain account created to run the application pool. Now I can log into SharePoint and access my WebPart, however, as expected, he presented me with AD information for a domain user using an application pool, and not an authenticated domain user. Therefore, I know that WebPart works and has the necessary permissions, etc., but System.Security.Principal.WindowsIdentity.GetCurrent().Name; still returns the user starting the application pool, i.e. impersonation still does not work. - In AD Users and Computers, I provided
Trust this computer for delegation to any service for a virtual server on which all this runs. - Since I did not have the Delegation tab for the domain user account using the application pool, I had to register the SPN for the user. After registering all the SPNs, I copied the SPNs from the list of servers, as well as the pair of http SPNs that I found on the Internet, and also set
Trust this user for delegation to any service for the user, no changes in the application behavior occurred. - I made sure that the user of the domain with which I was logged in was not protected from delegation
- I went into the local policy editor on the SharePoint server and made sure that the domain user using the application pool was allowed to "act as part of the operating system" and "impersonate the client after authentication."
- Other things I've tried
- Add
Negotiate:Kerberos as an Authentication Provider for Windows Auth on the IIS Web site. - The presence of these two lines in SharePoint web.config is confirmed:
Below are my SPN records on 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 times during this process. However, when I log in, my web part identifies me as the user launching the application pool. I know that there is work around, like using the application pool in Classic mode, but this is deprecated. There are other ways to get the correct name in .NET, but I don’t want to change the web part and, more importantly, this is the right way to do this, and I need to be able to make it work. I do not want to constantly work on this.
If someone has more ideas about what might cause the problem, I LOVE to hear them.