Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Previously, when using Windows authentication in an IIS application it would use the application pool identity to access the disk files. This meant the ACLs had to know the application pool identity for Read permission, etc. Impersonation is NOT being used here.

An application that has disabled anonymous and enabled Basic and Windows authentication and has Windows authentication configured in the web.config was refusing access to a user (correct credentials) that was configured as "allow" in the web config for a particular directory until I configured that user to have Read permission on the file.

This seemed odd because without impersonation, I was under the impression (and I certainly seem to recall it being the case before) that it would access disk resouces as the Worker Process Identity (a named domain service account in this case, this service account is in IUSR_WPG or whatever the correct name for the worker process group is).

Any ideas why it wants ACLs configured for the specific user instead of the domain service account that is the WPI?

share|improve this question
Previously, like when? I'm pretty sure IIS 6 had this behavior, too.. – Shane Madden Dec 6 '11 at 4:49
I recall it doing that only when impersonation was turned on (i.e. windows authentication for the database connection uses the WPI, why would it differ for local disk access). – Jared Peless Dec 6 '11 at 4:53

I believe you have to enable anonymous if you want the application to use the service account. Check out IIS Authentication Article

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.