When using Windows Authentication in IIS (when set in web.config), you should configure your root folder location like this:
So if you are using "Windows Authentication" mode, i.e. you don't see FileVista login page and logged in automatically according to the current logged on Windows user, then you should use Authenticated User (Windows) for Connect As option. Then this root folder should be accessible by the externally logged on Windows users. Note that you can not test the result on "Edit Root Folder" window if your administrator user is an application user such as the default created admin. That Connect As option would work on that window if the administrator user is also in format Domain\User.
Otherwise, it should be a SPN issue which means IIS uses "impersonation" and not "delegation" token for some reason.
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
One user solved similar problem like this:
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