Access Denied when accessing UNC path from IIS

iis-7uncwindows-server-2008-r2

I've got an issue with receiving an access denied error when trying to access a folder via UNC on another machine, from a web application running in IIS. Now i'm sure your thinking, as I did, this is surely just a permissions problem, however the following has happened:

  • The application is using impersonation and the user it is
    impersonating has full access to that folder.
  • Permission for that folder has been set to allow full control for everyone, in case impersonation was not working, same issue.
  • The application can quite happily view other folders and files in this share

Procmon is showing an access denied error when accessing this file, details of what it is asking is below:

Operation: Create File
Result: ACCESS DENIED
Desired Access: Generic Read
Disposition:    Open
Options:    Synchronous IO Non-Alert
Attributes: N
ShareMode:  Read, Write, Delete
AllocationSize: n/a
Impersonating:  domain\user

The application is essentially just trying to read from that folder, nothing more (the create file operation is actually only creating a handle to that file).

There are no events in the security log of the file server indicating an access denied error.

Edit

Delegation has been setup for UNC access (allowing the App pool user to delegate to the HOST and CIFS service on the file server) and using Deleconfig confirms this should work, it does not. However setting the App Pool user to be allowed to delegate to any service (Kerberos) only does work. As far as I was aware HOSTS and CIFS were the only services required to delegate file server access, so I'm not sure what extra service it needs access to.

Best Answer

This is from procmon running on the remote machine?

If so, that indicates that impersonation was successful (as it identifies the right domain\user, right?), so it's not a delegation problem with Windows authentication.

If not, it's probably a delegation problem with Windows authentication; try DelegConfig.

If the application is creating its own connection using \server\share - i.e. it's not a folder in IIS mapped to that location - then further subtleties may be present based on the application framework and the way it's been programmed.

Related Topic