The security database on the server does not have a computer account for this workstation trust relationship.
With IIS Windows Authentication, impersonation is not enough network resources so you also need delegation: Impersonation only allows you to access resources local to the web server as the browser user. If you want that user's identity to travel across the then you need delegation. The reason it works when you provide user name and password is that when Windows has the password, it can access network resources. However when there is no password, IIS creates a user token which can only access local resources. IIS only creates a delegation user token when you use Basic Authentication because then it knows your password (passed in clear text). So possibly you will see that you can access the path when you enable Basic Authentication. However this is not desirable because IIS would ask your credentials every time you access the site (no automatic logon I guess). So we should focus on enabling delegation for Windows Authentication (your current setting) To enable delegation in IIS, you need to enable Negotiate:Kerberos provider: Under "Windows Authentication" right click and select "Providers". Add "Negotiate:Kerberos" and move it to the top Note that configuring delegation seems to be a pain. So there are some other steps that may be required. However we should first start by doing the above. The other steps include Configuring the user's account to allow delegation in AD Setting up SPNs for users
Eventually we found out what the problem was with impersonation level. When the client negotiated with the server the authentication, a Kerberos ticket was requested but, as we used an alias for accessing the intranet, the ticket was not delivered, so the authentication was NTLM, not Kerberos. The impersonation level was “Impersonate” not “delegate” due to NTLM cannot impersonate at delegation level (required for accessing to network resources). The result was the error denying the access. To solve it, we had to say that the address (intranet.contoso.com) is a principal one at the web server (webserver001). So, in the end, solving it was as easy as typing, at the web server: Setspn -A HTTP/intranet.contoso.com webserver001
Trouble logging in? Simply enter your email address OR username in order to reset your password.
For faster and more reliable delivery, add notify@gleamtech.com to your trusted senders list in your email software.