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?