http://www.sqlservercentral.com/blogs/brian_kelley/2006/08/02/identifying-ntlm-vs-kerberos-authentication-using-fiddler/

Printed 2014/12/20 11:45AM

Identifying NTLM vs. Kerberos authentication using Fiddler

2006/08/02

I saw this post on using Fiddler to tell the difference between an NTLM and a Kerberos connection to a web server.

Two easy ways to pick Kerberos from NTLM in an HTTP capture

If you aren't aware of what Fiddler is, it's a web proxy that will allow you to see the communications between a web browser and a server. You point to is as a proxy server and then you can display the traffic in the Fiddler application itself. This kind of tool can help a lot when performing security analysis, such as penentration testing a web application (you can alter what's being sent back to a web server without having to code up a web page), but it can also be useful when troubleshooting why a given application isn't working.

One such application is SQL Server Reporting Services. If you're connecting via Windows authentication and the Reporting Services is installed on a different server than SQL Server, you have a double-hop situation (one hop between the client and the SSRS server and a second hop between the SSRS server and SQL Server). That leads to a failure when NTLM is used because it doesn't support a double hop. Kerberos does, when properly configured. When it's not, clients tend to drop back to NTLM... thereby leading to a failure. Fiddler can help you spot whether or not the initial connection to the web server is via NTLM or Kerberos. How does help troubleshoot a Reporting Services issue? Well, if the issue is because of security where you're seeing NT Authority\Anonymous Logon on the SQL Server side, understanding how the client the connecting to the web server can tell us where to start looking for issues.

If it's connecting via NTLM, you need to look at the client and SSRS server to determine what is misconfigured. The client may be set to only pass credentials automatically when the server is in the Intranet zone and the client doesn't recognize the server is in the Intranet zone. The client may be set up where it doesn't use integrated Windows Authentication (this is the default with IE 6 SP1, unfortunately). The NTAuthenticationProviders setting for the web site may not be set to use Negotatie, which is Kerberos. These are some of the more likely possibilities.

It's the connectiong is being made with Kerberos, than that means the connection between the SSRS and the SQL Server is likely where the issue is. In that case it could be the web server isn't setup to allow delegation in Active Directory, the application pool identity isn't set up to delegate within Active Directory (if Network Service is used, this is the computer account itself, which the first setting takes care of), if the application pool identity isn't Network Service it may not have a Service Principal Name (SPN) for HTTP, if you're using a common name that's differerent from the actual server name an SPN might be required, or it could mean the SQL Server doesn't have a properly registered (SPN).

Now, can you get the same information using a network sniffer? Yes. However, using Fiddler may be easier for those who aren't experienced with dealing with packet traces.



Technorati Tags: | | | | | |


Copyright © 2002-2014 Simple Talk Publishing. All Rights Reserved. Privacy Policy. Terms of Use. Report Abuse.