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:

•  using kerberos delegation  
•  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

#How To: Use Impersonation and Delegation in ASP.NET 2.0
http://msdn.microsoft.com/en-us/library/ff647404.aspx