ASP.net kerberos dropping down to NTLM sporadically

2
votes

Background (just the relevant pieces): We have a large intranet asp.net 2.0/3.5 app.
Web servers are Windows Server 2003 on an AD domain.
Clients are on Windows, IE 6-8. Windows Authentication, with a custom principal created from the Windows Identity. Web servers sit behind an F5 NLB which forwards the user to a specific web server. (The reason for this is a limitation w/ our company's F5 dealing w/ kerberos). There are no system wide problems like dropping sessions, or timeouts, or overloaded servers, everything's running fine in general.

One piece of functionality requires delegation - we are connecting to a network file share as the authenticated user, using the Kerberos token given to us by the domain/web server.

SPNs, ACLs, etc, seem to be set up properly.

99.x percent of the time, it all works. The problem we're seeing is every now and again, on a refresh, the token drops from kerberos down to ntlm. I can see the login on the web server's event log showing one call getting this:

Logon Process: Kerberos Authentication Package: Kerberos

And a subsequent call (usually after 10 or 20 page loads) getting this:

Logon Process: NtLmSsp Authentication Package: NTLM

Anyone have any insight as to what might be making a subsequent postback sometimes go NTLM?

Thanks!

1
asp.netkerberosdelegation

1 Answers

2
votes

All the tools and techniques you need to identify the issue are in Troubleshooting Kerberos Errors. That document never failed me.

NTLM Fallback
You might find that the security log recorded an event in which logon occurred using NTLM when it should have occurred using Kerberos authentication.

Problem
There are two situations in which this might happen:
- The first situation is where the system attempts authentication using the Kerberos protocol but it fails. As a result, the system attempts to authenticate using NTLM. Windows Server 2003, Windows XP, and Windows 2000 use an algorithm called Negotiate (SPNEGO) to negotiate which authentication protocol is used. Although the Kerberos protocol is the default, if the default fails, Negotiate will try NTLM.
- The second situation is one in which a call to Negotiate returns NTLM as the only protocol available.

Confirmation
The first situation will result in a failed Kerberos authentication that you can investigate by examining errors in the event log or data packets captured by Network Monitor. Both investigation methods are discussed later in this document...