Troubleshooting Kerberos on Enterprise Portal – Wrong NTAuthenticationProviders

I’ve been helping with setting up Kerberos authentication for a couple of installations so far. This is normally just a matter of reading the installation guide and also the Kerberos setup guide. If you’re reading this post, you probably already know why you need to set up Kerberos; it’s because Enterprise Portal is running on another server than your SQL Server. This is a pretty normal setup. The configuration needed to get this to work might be tedious, but when you’ve done it a couple of times, it isn’t really that hard.

What if it still doesn’t work?

Kerberos errors are by default not logged, so you will have to do some modification in the Registry to turn on logging. This is not difficult. You would want activate this on the Enterprise Portal Server. The procedure is described on Microsoft’s Customer Support site, and it’s a matter of adding LogLevel (DWord) with the value of 1 to the Registry location HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
When this entry is saved, the logging will start immediately. No restart of server or services is needed.

Now there are quite a few errors that might throw you off, so keep that in mind when you open the Systems log in Event Viewer.

Remember to turn off the debugging when you’re done.

NTAuthenticationProviders matters

The procedure for setting NTAuthenticationProviders is located on Microsoft Customer Support site. It is quite similar to the instructions on how to setup IIS when SSRS is running on SQL 2005. The topology I was troubleshooting had Windows 2008 Server on both the SharePoint server (where Enterprise Portal was installed) and on the SQL 2008 Server. When loading Enterprise Portal in a browser on the SharePoint server everything was working perfectly. The SSRS reports were loaded and displayed KPIs and fine graphs. If we tried to load the same page from any other machine all the webparts displaying reports showed an error saying it could not load the report and I should “Validate that the Report Manager URL is correct”. Obviously the setup was correct since I could load the reports perfectly if I tried load the page from the SharePoint server. This was a Kerberos problem!

Since we had already checked the installation and setup several times and searched for any discrepancies, we had to involve Microsoft to hunt down the problem. For some reason the NTAuthenticationProviders on the SharePoint server was set to “NTLM” only, and not “Negotiate, NTML”. After setting it to “Negotiate, NTLM” everything was working as expected.

If you don’t want to read the support article at Microsoft, here’s what you need to do:
1. Click Start, click Administrative tools, then click Internet Information Services (IIS) Manager.
2. In the left pane, click the Web sites directory and locate the SharePoint web site hosting EP on the right-hand side.
3. Locate the ID (Identifier) column and write down the ID of the web site
4. If running Windows 2008/R2 then run an elevated cmd prompt
5. Change folder to c:\inetpub\adminscripts folder by entering the following command and press Enter: cd \inetpub\adminscripts
6. Use the following command to determine if both the "Negotiate,NTLM" authentication providers are setup or not. In the command, replace <identifier> with the ID identified in step 3 above. Then enter the commands in the command prompt and press Enter:
cscript.exe adsutil.vbs get w3svc/<identifier>/root/NTAuthenticationProviders
7. If the response does not show "Negotiate, NTLM" then use the following commands to set it:
cscript.exe adsutil.vbs set w3svc/<identifier>/root/NTAuthenticationProviders "Negotiate,NTLM"
8. The providers are now set. We need to restart the IIS services. In the command prompt, type iisreset.exe and then press Enter.

So basically, this needs to be checked on the SharePoint server if you are setting up Kerberos as authentication to the Enterprise Portal. I hope this helps someone.