Authentication to another domain when using UNC path
Question asked by Slodex - September 13, 2015 at 11:31 PM
Hi everyone,
I'm testing an instance of FileVista set up on a server on DOMAIN1. The server can access servers on DOMAIN2, DOMAIN3, etc. There's no trust or federation set up between any of the domains.
Although there are no problems using DOMAIN1\User or User@Domain.1 for accessing a UNC path within the same domain, when I try to access a UNC path like \\Server.Domain.2\Share, I can't access the share in FileVista using DOMAIN2\User or User@Domain.2. The error I'm getting is this:
The security database on the server does not have a computer account for this workstation trust relationship.
Does anyone have an idea of what's happening for this error to happen, and whether there's a way around it without moving the server from one domain to the other?

2 Replies

Reply to Thread
Cem Alacayir Replied
September 14, 2015 at 6:18 AM
Employee Post
On the web server that you installed FileVista, can you access \\Server.Domain.2\Share as DOMAIN2\User or User@Domain.2 in "Windows Explorer" (eg. map network drive with connect as option)?
Cem Alacayir Replied
September 14, 2015 at 5:46 PM
Employee Post
Below information can be useful for Windows Auth and UNC paths:
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

Reply to Thread