Identifying NTLM vs. Kerberos authentication using Fiddler

,

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:

|

|

|

|

|

|

Rate

Share

Share

Rate