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:
