CODEWITHSUNDEEP
.netkerberosntlmiis-8.5kerberos-delegation
Rick V
Rick V

Reputation: 1296

Reset to Kerberos when Negotiate:Kerberos faults to NTLM

I am working with a system which implements constrained delegation for a double-hop from Firefox 38.2.1 (or IE 11) accessing an intranet .NET 4.5.1 web application running on Windows Server 2012 (IIS 8.5) to SQL Server 2008 R2 on a different server. The delegation scenario is functioning: the user's AD credentials are passed through to the database on a server separate from the web server. The DCs are Windows Server 2008 R2, and we use SPNs.

However, there are scenarios such as a missing Firefox configuration setting where Kerberos will fail; and the authentication protocol downgrades to NTLM. Delegation no longer works for a period of time until the Kerberos authentication protocol is re-instated (some sources say 5 minutes; it is more like 10-12 minutes with our testing). Furthermore, the failed delegation affects all users who access the application after the protocol downgrade takes effect until Kerberos is re-instated automatically. In other words, their sessions use NTLM and are blocked from accessing the database for 10-12 minutes.

Is there a way via code (c#)/IIS/Firefox/IE, or another method, to restore manually the authentication protocol to Kerberos, thus shortening the window in which NTLM is the protocol being used?

Upvotes: 2

Views: 2006

Answers (2)

Philip V
Philip V

Reputation: 11

We experienced this same problem (kerberos downgrade affecting all users and breaking delegation). We opened a Microsoft case, and their solution was to check "Use any authentication protocol" on the service account delegation setup. I believe this is the "TrustedToAuthForDelegation" property. I think this is the best solution if you have clients that might negotiate down to NTLM because it allows to transition from NTLM up to kerberos in order to perform the double-hop.

Upvotes: 1

T-Heron
T-Heron

Reputation: 5594

I've seen this type of problem before. I would strongly advise against trying to solve this through custom code, because then you would have to detect on protocol condition failures and act accordingly and so forth. Such an effort would be non-trivial. Instead, it would actually be easier to either (1) develop a script method to iterate through all machines which have Firefox installed and set the network.negotiate-auth.trusted-uris and network.negotiate-auth.delegation-uris to contain the name of your domain (see: Configure Firefox to authenticate using SPNEGO and Kerberos), or (2) enforce Firefox settings (the ones visible via about:config) via a central server. For #2, see Deploying Firefox in an enterprise environment. I like #2 better since you can control all custom Firefox settings that way.

Upvotes: 1

Related Questions