After working on three or four projects, troubleshooting delegation issues isn't as difficult as I first thought. I'll list the tools I use and then start working thru the troubleshooting steps. (I'll assume people have a basic understanding of the technology and terminology.) This article will cover client PC settings and the settings on the server that the client is talking directly to. The next article will have a process for walking thru an installation that uses service accounts and/or hostheaders. (The truly complicating factors)
Microsoft has a pretty complete set of tools for troubleshooting Kerberos issues. The ones I rely upon are:
- adsiedit.msc
- search.vbs (a part of the Windows support tools, on the server CD)
- logon success auditing
- setspn (limited, adsiedit is much easier to work with)
This should be all you need, assuming that the underlying Kerberos infrastructure is working correctly.
For troubleshooting web applications, the first things to check are the clients' browser settings. When you open the page you want to delegate, if you are prompted for a username / password, either Internet Explorer or IIS isn't configured to pass integrated credentials along. If you then authenticate to the page, check to see which security zone your browser says it is in. Integrated authentication only works in the Local Intranet and the Trusted Sites zones. I recommend not using the Trusted Sites zone, as the Local Intranet zone offers a bit more security to the client's browser, and has a rule to allow a hostname url (ie without the domain name, such as http://portal) to automatically be a member.
If IE claims you are in the Internet zone, the browser settings need to be adjusted. You can either manually add the site to the Intranet zone, or deploy that change via Group Policy.
Once the security zone is correct, confirm that integrated authentication is enabled. Within IE, go to Tools > Internet Options > Security. Highlight the Local Intranet icon and click the Custom Level button. Scroll to the bottom of the list of security rights and confirm that the "Automatic Logon only in..." radio button is selected. Cancel out of that dialog and go to the Advanced tab of Internet Options. Scroll down to the security section and confirm "Enable Integrated..." is checked.
At the client level, the only things remaining to check is that the computer is a member of a domain that is in the same forest as the target server. Confirm that the variance between the server's clock and the computer's clock is not greater than five minutes (time zones notwithstanding.)
To confirm the client is configured correctly, go to the server and open up the Local Security Policy. Drill into Local Policies and then Audit Policy. Enable SUCCESS auditing for account logon and logon events. In the security event viewer, this audit setting will generate entries every time someone authenticates to the local server. The important part here is that the event record will show the authentication method used, whether it is NTLM or Negotiate. (AKA Kerberos)
If the logon events show only NTLM entries, we need to look at some of the server's authentication settings. On the web app or virtual directory you're trying to authenticate to, check the website's properties. Go to the Directory security tab and click the Edit button within the Authentication box. For integrated authentication to work correctly, it has to be the ONLY box checked. Any other auth methods, including anonymous, will prevent kerberos from working.
According to this KB Article, the auth methods of IIS 5.0 can be confirmed by entering the following line, launched from c:\inetpub\wwwroot. I assume IIS6 comes configured correctly, out of the box.
cscript adsutil.vbs get w3svc/NTAuthenticationProviders
If you don't get this response,
NTAuthenticationProviders : (STRING) "Negotiate,NTLM",
you need to reconfigure the the server so it does. The usual disclaimers about modifying your metabase apply - have good backups! To change the auth methods, enter the following:
cscript adsutil.vbs set w3svc/NTAuthenticationProviders "Negotiate,NTLM"
The final thing to check is a little more application focused - the web.config file of any .Net project relying on impersonation should have the line <identity impersonate="true" /> in it.
Once these settings have been either confirmed or corrected, try reloading the original web page. Next, check your security audit log and look for successful logon events. Confirm that these entries are for your user account, in the correct timeframe, and that the "Authentication Package" doesn't read NTLM.
If you still can't generate a Kerberos login, you may have to dig further into the underlying Kerberos / Active Directory infrastructure. As mentioned before, a time variance of more than five minutes will cause Kerberos to fail. The support tools offers several other applications to help in troubleshooting.
One interesting thing I found is that when using IE on the same machine that you're connecting to via IIS, is that NTLM, and not Kerberos, is the authentication protocol with the highest precedence. As far as I know, there is no way to change this behavior. Use a separate client machine for testing. The rules about security zones and domain membership still apply though.
Next time: How to make that second server in the chain work, how host headers and service accounts make things more difficult, and how to break it down into manageable pieces.