-1

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?

Jared Peless
  • 99
  • 2
  • Previously, like when? I'm pretty sure IIS 6 had this behavior, too.. – Shane Madden Dec 06 '11 at 04: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 06 '11 at 04:53

1 Answers1

0

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

Ben
  • 105
  • 1