IIS 7 and Above
UNC Path Access Denied error
Last post Mar 31, 2016 12:27 PM by Ken Schaefer
Mar 25, 2016 04:22 PM|VTwin Farriers|LINK
This seems to be a common error many people run into, and I've read dozens of threads on the subject, but none of the various "solutions" seem to fix my problem.
I have an ASP.NET application which must access data for read and write on a network share. This app is hosted on a Win2012 server with IIS 8 (all updates applied). The app runs in its own app pool, which uses a domain user account as the app pool identity
Users must provide windows credentials to log in to the app. Only Windows authentication is enabled. Anonymous is disabled, along with all the others (Basic, Digest, and Forms). The application is set to impersonate the authenticated user (e.g. <identity impersonate="true"/>
The network share is shared as "Full Control" for "Everyone", 'AppPoolUser' and my own domain username. The security permissions for all the files in the share, and on the directory itself, are likewise set to full control for Everyone, AppPoolUser, and myself.
I access the app and log in with my windows ID, All works great, until I attempt to access a file on the UNC path. At that point, I am repeatedly (3 times) asked for my credentials again, after which, yields the typical error:
An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.UnauthorizedAccessException: Access to the path '\\MyServer\MyShare\myfilename.ext' is denied.
I've been banging my head on this for several days. I'm out of ideas here as to what I am doing wrong. I've spent countless hours googling around for a solution.
One question I do have is on this sentence in the error message:
"If the application is impersonating via <identity impersonate="true"/>, the identity will be the anonymous user (typically IUSR_MACHINENAME) or the authenticated request user. "
Since "IUSR_MACHINENAME" doesn't exist on Win2012 w/ IIS 8, what is the "anonymous user" referenced?
If someone can point me in the correct direction as to what I have wrong here, I would really appreciate it.
Mar 26, 2016 02:53 AM|lextm|LINK
It is very likely that you have to capture SMB packets to see what is the error. None of the threads will dig that further, simply because the participants might not even know that at network layer there is important information to check,
Mar 26, 2016 03:59 AM|ryan.b|LINK
what is the "anonymous user" referenced?
Mar 26, 2016 09:39 PM|VTwin Farriers|LINK
There is no IUSR anything user at the machine level, but there is one in the domain (both the IIS server and the server hosting the UNC path are domain members. Adding this user to both the share-level permissions (Full Control) and directory/file-level
permissions (Full Control) proved fruitless, it yielded the same problem (prompting for credentials).
I'll have to fiddle with the SMB packet stuff to see if I can determine what is going on.
I did discover a work-around earlier today.
If I go into Authentication -> ASP.NET Impersonation -> Edit and change the Identity to Impersonate from "authenticated user" to a domain administration account, I can access the UNC paths without being prompted for credentials. (I attempted to use the
Application Pool user, but that started me down a rabbit hole where I needed to start granting permission to c:\windows\Microsoft.net\Framework.... to the user in question.)
I'm not thrilled about the workaround, nor understand why selecting "authenticated user" on the Impersonation screen does not work (given the authenticated user does have permission to the share and directory/files), but I guess I can live with it at the moment,
although it isn't ideal.
Mar 28, 2016 02:17 AM|alexjones|LINK
I am also facing the same issue but not resolved yet. Will be much appreciated if anyone suggests clearly
Mar 28, 2016 03:06 PM|VTwin Farriers|LINK
Unfortunately, if you google around, you'll see that this seems to be a common problem, but most of the threads are several years old, and thus, not applicable to the newer OS/IIS revs, or the original poster simply seems to disappear with no real resolution
to the problem, or, description of why the underlying problem exists in the first place. There are dozens of threads with this problem on other coding sites, such as stackoverflow, for instance, some dating back to the mid 2000's.
Admittedly I am quite baffled why the problem continues to exist at all (e.g. why selecting "authenticated user" on the Impersonation screen does not work, given the authenticated user does have permission to the share and directory/files) and sure
wish someone with the requisite technical knowledge of what IIS is doing "behind the scenes" could explain exactly why this problem occurs.
I cannot imagine what I am attempting to do (access files via a UNC path in server-side code-behind) is all that unusual in today's decentralized world. How are larger web sites, based on IIS, serving files off NAS devices, for instance? Or, does everyone simply
avoid IIS for this and move to apache?
Mar 28, 2016 05:38 PM|VTwin Farriers|LINK
After hours of digging, this article seems to shed some light on the issue.
It would appear the user credentials supplied from the client to the IIS server are the "first" hop, and the credentials can be used to impersonate the authenticated user on the IIS server *only*. To then access a resource on a second server, would be considered
a second "hop", and the authenticated credentials between the IIS server and the client are not valid for this purpose. Another set of credentials is required.
Thus, it would appear the "workaround" I listed above seems to be one of several viable alternatives. There also appears to be the process of delegation which may offer a solution (more digging may find a how-to as to how this is accomplished), as well as obtaining
within code-behind a security token which provides access to the necessary resources by impersonating another user.
Mar 31, 2016 04:42 AM|alexjones|LINK
Ok i go through the link you have given, thanks alot
Mar 31, 2016 12:27 PM|Ken Schaefer|LINK
You are running into a delegation problem.
With "Windows authentication", the IIS server does not have the user's password in clear-text, so can not "automagically" authenticate to the remote UNC path on the user's behalf.
There are various ways around this (native Kerberos delegation is the most usual), but setting that all up requires some configuration on your part.
I have a fairly extensive FAQ here:
http://www.adopenstatic.com/faq but basically you need to ensure:
a) client is authenticating to IIS server using Keberos (or you enable Protocol Transition). This may require SPN configuration in AD depending on your IIS setup. Since you are running your app pool as a domain account, you can register the SPN under the
domain account, but you need to disable kernel mode authentication. Otherwise keep SPN under the computer account
b) appropriate delegation rights are configured for the account running your app pool - that account required appropriate Kerberos configuration to be able to impersonate the end user to the remote UNC share - that's covered in the FAQ