I think the analysis(by BrockAllen) about the windows identity forward limitation across multiple server boundary is reasonable.
Actually, based on your description, you're hitting a typical "double hop" case when using windows authentication in a multiple-tier application. So the basic view is a below:
A -----> B ------> C
A is the client browser
B is the webserver hosting your ASP.NET web app
C is the remote resource(file share or sql database which require certain authenticated user to access)
A,B,C are all on different machines. Then when your ASP.NET web on B is using windows authentication (and without using kerberos delgation over the entire processing line from A to C). Then, the user identity of the client user on A machine, can be got
by ASP.NET web app on B server; but cannot be further forwarded to C machine. What C machine will get is the account under which your ASP.NET web application is running on B(not the impersonated user account forwarded from A).
Here are some reference on about double hop issue:
using a fixed account on B machine to access other remote resources(like the file share in your case) And you can also programmtically impersonate a fixed account (with username/password) too
Steven Cheng...
Contributor
4187 Points
547 Posts
Microsoft
Moderator
Re: Access Denied - CreateDirectory
Apr 19, 2012 06:32 AM|LINK
Hi kjmcad,
I think the analysis(by BrockAllen) about the windows identity forward limitation across multiple server boundary is reasonable.
Actually, based on your description, you're hitting a typical "double hop" case when using windows authentication in a multiple-tier application. So the basic view is a below:
A -----> B ------> C
A is the client browser
B is the webserver hosting your ASP.NET web app
C is the remote resource(file share or sql database which require certain authenticated user to access)
A,B,C are all on different machines. Then when your ASP.NET web on B is using windows authentication (and without using kerberos delgation over the entire processing line from A to C). Then, the user identity of the client user on A machine, can be got by ASP.NET web app on B server; but cannot be further forwarded to C machine. What C machine will get is the account under which your ASP.NET web application is running on B(not the impersonated user account forwarded from A).
Here are some reference on about double hop issue:
#IIS, Windows Authentication and the Double Hop issue
http://weblogs.asp.net/owscott/archive/2008/08/22/iis-windows-authentication-and-the-double-hop-issue.aspx
#The Double-Hop Problem
http://blogs.msdn.com/b/knowledgecast/archive/2007/01/31/the-double-hop-problem.aspx
And some workarounds exists. For example:
#How To: Use Impersonation and Delegation in ASP.NET 2.0
http://msdn.microsoft.com/en-us/library/ff647404.aspx
Feedback to us
Microsoft One Code Framework