Last post Jun 01, 2012 04:54 AM by MSTechie
May 25, 2012 09:46 AM|MSTechie|LINK
WebSite is hosted IIS 7.5 Windows 2008 Server , which is a part of Active Directory Domain. Application used for intranet purpose,.
I have hosted my ASP.Net 4.0 application in IIS 7.5, which connects to SQL Server 2008. I want to
ENABLE IMPERSONATION to capture the Windows NT Domain User ID of the person who logs in to the application.
Below are my settings in web.config 's connection string
Source=Server\Instance1;Initial Catalog=Database;Integrated Security=True;persist security info=False;Trusted_Connection=Yes"/>
Now the main settings for Application Pool
There are 2 options for settings Identity for the Application Pool.
Scenario 1) When I set the Identity = Built-in account like ApplicationPoolIdentity , the applications fails while connecting to the SQL Server saying 'Login Failed for user NT Authority\Anonymous Login'. I checked the EventLog on the server
and observed that it is saying ProcessName :w3wp.exe , Thread Account="IIS AppPool\MyApplicationPoolName" and Is Impersonating="false" --> I have specifically set impersonate =true in web.config , as mentioned above and in the IIS Settings, I have enabled
ASP.Net Impersonation and set it to take Authenticated User
Scenario 2) When I set the Identity = Domain\User1 , the application connects successfuly to SQL Server, but always connects as the SAME USER (which is Domain\User1). This means that I am not able to impersonate
Thanks in Advance
Jun 01, 2012 04:54 AM|MSTechie|LINK
Impersonation only allows to access resources local to the web server as the browser user. If the logged user's identity has to travel across the network (to the SQL Server) then we need delegation. Delegation involves:
1) configuring the user's account to allow delegation (this is enabled by default in AD, but double check for your environment)
2) configure the web server/app pool to run as a domain identity and have that identity trusted for constrained delegation to the servers you want to delegate to (so your SQL Server)
3) configure a http SPN for this domain user that you configured in step #2 so your browser clients can properly authenticate with kerberos