There are multiple possible issues:
1. How Is the Remote Access to a Local Account Configured.
Is the system in a domain or workgroup? If in a workgroup, unless you change it, all remote access by administrator accounts is disabled (they are treated as guests).
You can change this in local security policy:
- Run
secpol.msc
from Start | Run
- Go to Local Policies | Security Options
- Select setting "Network access: Sharing and security model for local accounts"
- Ensure this is set to "Classic: Local users authenticate as themselves."
(The explanation tab gives more details.)
While in secpol
also check that you are auditting account logins.
2. ISS Authentication Settings
What are the authentication settings for the virtual directory? Is anonymous access enabled? Is Windows Authentication enabled?
If you are auditting account login events, check the security event log to see the logins that should have happened if the user was authenticated.
3. What are the permissions on the file system
Does the remote user (for Windows Authentication) or the Worker Process identity (for anonymous) have read access to the file system objects?
Use Process Monitor to see if the files are being accessed (or attempts made to access them), this should help see if it is IIS generating the unauthorized error internally or use to an access denied from the file system.
4. Go back to the error
HTTP/1.1 401 Access denied Learn about IIS status codes Path:W3SVC/1670937635/ROOT AuthType:Anonymous
This seems to be saying that the client is not being authorised as their Windows account. This seems to be the area to focus on. Do you get the same if the client browser is running on the server box, how about a different box, how about a different browser? Is IE configured for the applicable zone to allow Windows authentication?
A clear explanation from Daniel Irvine:
There's a problem with 401 Unauthorized, the HTTP status code for authentication errors. And that’s just it: it’s for authentication, not authorization.
Receiving a 401 response is the server telling you, “you aren’t
authenticated–either not authenticated at all or authenticated
incorrectly–but please reauthenticate and try again.” To help you out,
it will always include a WWW-Authenticate header that describes how
to authenticate.
This is a response generally returned by your web server, not your web
application.
It’s also something very temporary; the server is asking you to try
again.
So, for authorization I use the 403 Forbidden response. It’s
permanent, it’s tied to my application logic, and it’s a more concrete
response than a 401.
Receiving a 403 response is the server telling you, “I’m sorry. I know
who you are–I believe who you say you are–but you just don’t have
permission to access this resource. Maybe if you ask the system
administrator nicely, you’ll get permission. But please don’t bother
me again until your predicament changes.”
In summary, a 401 Unauthorized response should be used for missing
or bad authentication, and a 403 Forbidden response should be used
afterwards, when the user is authenticated but isn’t authorized to
perform the requested operation on the given resource.
Another nice pictorial format of how http status codes should be used.
Best Answer
I realize this is an older post but I had the same error on IIS 8.5. Hopefully this can help another experiencing the same issue (I didn't see my issue outlined in other questions with a similar title).
Everything seemed set up correctly with the Application Pool Identity, but I continued to receive the error. After much digging, there is a setting for the anonymous user to use the credentials of the application pool identity or a specific user. For whatever reason, mine was defaulted to a specific user. Altering the setting to the App Pool Identity fixed the issue for me.
Hopefully this saves someone else some time!