Error 401.3 not authorized when NOT using impersonation

0
votes

I am trying to access an old fashioned asmx web service hosted in IIS and I am banging my head against a 401.3 error. I know there are lot of resources out there but most of them make use of impersonation and by adding permissions for the authorized user to the file system, which I want to avoid.

My scenario is basically an IIS webservice, running with an AppPool which runs as a specific service account (DOMAIN\username + password). This service account has full control on the folder and the Anonymous authentication is set to use the AppPool Identity.

This is all good and working but now I wanted to secure my webservice by adding Windows authentication. I did that and added a simple <deny users="?" /> to the authorization section. What happens now is that when I connect to the server I get asked for a username and pwd, I provide one and then I get a 401.3 error.

I have tried adding read&execute permissions for myself to the folder and everything works but this is clearly not a proper solution as I would have to keep managing folder permissions.

My question is: why does the authenticated user needs folder access? Isn't the folder accessed as the app pool identity? Impersonation is disabled so I would expect that to be the proper behaviour.

1
asp.netiisauthorizationasmximpersonation
docs.microsoft.com/en-us/iis/troubleshoot/… Find the source of 401.3 first. – Lex Li

1 Answers

1
votes

why does the authenticated user needs folder access?

The FileAuthorization module requires the authenticated user to have permissions to the file.

Isn't the folder accessed as the app pool identity

Yes, but the above module also checks the authenticated user. You mentioned that you have Anonymous set to use AppPoolIdentity, so I'd expect in your case, this to be true.

Impersonation is disabled so I would expect that to be the proper behaviour.

This is independent as the FileAuthorization module kicks in anyways.

By recommendation for how to troubleshoot would be grab a ProcMon trace and I suspect you'll see some AccessDenied. Go look and see what permissions are required by what process and see if its doing impersonation (for this check). This will tell you what permission is missing/failing.