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!
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