Click here to Skip to main content
15,888,056 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
Hi there,

I've a very puzzling situation that I've been struggling to resolve.

I have a web application hosted in IIS on a Windows Server 2003 (SP2) operating system running on ASP.NET V4. It uses Windows authentication to identify the user and AD group membership to check their access levels.

Part of the application functionality is to access a file repository on a separate server, also Windows Server 2003 (SP2).

To control access to the file repository the web app uses impersonation (<identity impersonate="true"), with a user who has Admin access to the file repository server.

This all works fine and has done for years.

Now I am moving the application to a new Windows Server 2012 R2 machine with IIS 8.5 and using ASP.NET v4.5.

All functionality on the application works the same except for accessing the file repository, where I get the error- Access to the path '<document path>' is denied.

It's behaving as if the credentials of the impersonate user, specified in the web.config file, aren't getting passed to the file repository server.

Any help and advice would be greatly appreciated.

What I have tried:

Publishing the same application build, at the same .net version, to both the old and new servers. Can access files from old server publish but not on new server publish.

Comparing IIS configurations on old and new servers. IIS versions are quite different but I have tried to configure as close as possible.

Running new server IIS App Pool as the impersonated user.

Setting Default Impersonation Level (in Component Services) to Impersonate

Disabling User Account Control

Running web app, IIS app pool & impersonate user as a user with admin rights on the file server.

Removing impersonation from web.config and IIS config and running app as user with admin rights on file server.
Posted
Updated 22-Feb-18 6:01am
v3
Comments
phil.o 21-Feb-18 20:07pm    
Uberbob77 22-Feb-18 12:00pm    
Hi phil.o, that looked really promising but I'm afraid it didn't work.

I followed the instruction on the link and set the Default Impersonation level from Identify to Impersonate, then re-booted the server. But the result is still the same.

Thanks for trying to help though.
phil.o 22-Feb-18 12:24pm    
I empathize as I've been there and it was a PITA to make things work again.
Unfortunately, it was nearly 10 years ago, and I can remember neither the precise issue, nor the solution I then found.
The only thing I barely remember is it had something to do with a default signing algorithm for secure communications (a hashing algorithm, so), which had been changed starting from 2008 R2. We had to install a hotfix on all servers and workstations for them to be able to authenticate on the new 2008 R2 server.
I'm sorry I cannot be of greater help. Kindly.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900