Impersonation NOT working - Network Share

2019-04-11 20:14发布

问题:

I have created a virtual Directory (IIS 7.0), which points to a network share. This virtual directory resides under my web application root.

I tried using anonymous access with domain credentials. Also, I tried using impersonation as below...

<identity impersonate="true" userName="<supplied username>"
password="<supplied password>" />

ISSUE: Application is always using IUSR to connect to that share and getting "ACCESS DENIED". I need to force my application to Use domain name above.


UPDATES
1. While running procmon I can see "FAST IO DISALLOWED" message everytime before access denied. Not really sure if its related.
2. I suspect symptoms of Double Hop Issue here. But don't know how really to validate it or how to get around it without really changing authentication to Kerbros.

Thanks!

回答1:

IIS 7 by default runs in "integrated mode".
You can no-longer impersonate there
(you don't get an error message on impersonation, but it just doesn't elevate privileges).

You need to switch the ASP.NET app-pool of your application to "classic mode" in order to use impersonation.
Note that this also means that you loose all the features that depend on integrated mode.

Another possible solution might be to create a symbolic link pointing to the smb share, giving IUSR permission to the symlink, and let the operating system handle the rest (don't know if that works, and given MSFT's track record, I'd guess that it doesn't).

mklink /d  C:\inetpub\wwwroot\your_application_root\ShareName \\Server\ShareName\Directory

mklink however requries Windows Vista+, that is to say Windows Server 2008+



回答2:

With ASP.NET applications it’s usually recommended that you run under the ‘ASP.NET user account’ without impersonation. The idea is that this account is a low rights account that can do little damage if for some reason the machine is compromised.

(Here is a link reference to an article that should help you).

http://west-wind.com/weblog/posts/2153.aspx



回答3:

I agree with Joe's statement. However, on most enterprise environments, where strict policies are applied, it won't be possible to grant low rights accounts to access certain resources. In that case, programmatic impersonation will be a better approach: http://www.west-wind.com/weblog/posts/1572.aspx



回答4:

Give the IUSR account access to your share. Better yet have your program use the built in ASP account (as Joe Garrett stated) and give that access to the share.



回答5:

Try disabling Anonymous access. Using Windows Authentication if you don't force the user to login (by adding deny="?" in your web.config) will cause IIS to impersonate using the configured account.