2

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?

T-Heron
  • 5,385
  • 7
  • 26
  • 52
Rick V
  • 1,286
  • 1
  • 11
  • 13
  • Have you found any solution for the problem? I have also experienced the same, the moment any browser which isn't configured for kerberos tries to access the application, it wrecks the sessions of other active users also. Also digging into the event log, i observed that normally in the double hop situation the call to another server, happens using Kerberos and is initiated by advapi process, however whenever this issue is reproduced, all the calls to the second server from the main server process are happening via NTLMV1 by the NTLMssp process. – blueharoon Apr 23 '20 at 05:09

2 Answers2

1

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.

T-Heron
  • 5,385
  • 7
  • 26
  • 52
  • Thank you. #2 is currently in the works as a proactive measure. The links you provided are very helpful and I will share with our team! – Rick V Feb 14 '17 at 14:17
  • Hi; Did this work for you? If so, and we've answered your question, please mark it as such which will verify it to others in the community; otherwise please let us know if any. – T-Heron Mar 27 '17 at 19:28
  • You suggested proactive ways to prevent Kerberos delegation from failing, but not reactive solutions to reset it, which is the core of my question. So your answer was helpful to the discussion, but it is not the answer to how to restore it once it has failed. – Rick V Mar 27 '17 at 21:42
  • I see. Thanks for getting back. Based on the problem statement, it appears that solving the issue would be too complex to be handled in a Q&A forum like this. I don't have an further guidance that is specific to reacting to the problem when it occurs. It appears to be a very strange problem, maybe at least partially related to unique conditions of the environment. – T-Heron Mar 27 '17 at 21:56
1

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.

Philip V
  • 11
  • 1
  • Hi, Can you share the link of that Microsoft case, if its not private? We are currently experiencing the same issue wherein a improperly configured client (Blackberry Access) attempts a login (in an Constrained Kerberos setup) and downgrades the the authentication to NTLM, breaking it for every other active user) – blueharoon Jun 01 '20 at 14:18
  • Sorry, it is a private case. Anyway, there is not much to be learned other than the solution I provided above. – Philip V Jun 11 '20 at 19:16