Windows authentication failure between multiple domains (sites)

Question

I have just rolled out a new Intranet company wide - the company has 6 UK sites, each has a local domain called (for example) london.local, derby.local, thatlotupnorth.local etc etc, and each has its own AD server.(The sites are connected via MPLS through Virgin, but that should be transparent to the issue)

The intranet server (Server 2008 R2, IIS 7.5) is based in, lets say london.local, and uses Windows Authentication in order to authenticate and access the site on the intranet server.

This works fine from all but one site.

Further investigation shows that a user who is a member of this site, lets say derby.local, cannot log into their account from inside another domain, for example i set up an account on the derby.local domain and tried to log in from london.local, i get the error “There are currently no logon servers available to service the logon” suggesting that the AD server is not accessible, however i CAN ping it.

I am fairly sure that the cause of the intranet windows authentication is because the server cannot access the AD server at the other site.

nslookup reports that one domain as "non-existent", all the other AD servers reply with their details. However I AM able to ping derby.local.

any pointers on where to start trouble shooting much appreciated!

Solution

If the site is in the Trusted Sites zone, and that zone is configured for "Automatic logon with current username and password", and IIS is configured with an application pool account that can impersonate the user, it should be possible for Internet Explorer to present the authentication token as part of the http request header, and IIS to use that token for authentication and authorization.

The Intranet Zone may also be used if the url is a single-label/short name.

This "integrated authentication", as opposed to prompting for credentials (probably in plain text), is typically the preferred authentication mechanism.

One way to determine if it is configured properly is to download the DelegConfig utility, and add it as a virtual directory under the web site. When you open the link to that virtual directory, it will run a few tests and display what, if anything, may be configured incorrectly.

Typically this requires the IIS computer to be "Trusted for Delegation" on the delegation tab of the computer account, or if the application pool is using a domain account, that account needs to be trusted in the same way, although the Delegation tab does not show by default for user accounts so you would need to use setspn.exe.

Sometimes the HTTP request header is very large, due to many group memberships. This would require adjusting an IIS registry setting for MaxRequestBytes.

Http.sys registry settings for IIS
http://support.microsoft.com/kb/820129

DelegConfig Download:
http://blogs.iis.net/brian-murphy-booth/archive/2009/04/22/delegconfig-v2-beta.aspx

Comments

[Greg Askew]

From the IIS server in London, open a cmd prompt, can you perform the following: 'runas /user:derby.local\username cmd.exe' . That would localize the symptom from IIS if you cannot authenticate just from the command prompt.

[Alpharius]

Thanks Greg, interestingly that worked, so the iis server IS able to authenticate to the troublesome domain... so this must be a client side windows auth issue. ETA: i just tried the same from my Dev machine (which is in the same domain as the IIS server!), and it failed - so this may be a routing issue.

[Greg Askew]

You're using Windows integrated authentication? I.e., not prompting for their Windows credentials?

[Ryan Ferretti]

Are these domains within the same forest or are they separate forests that are manually trusted together?