title: Client sometimes negotiates NTLM after Kerberos has been enabled, until client server rebooted. How to avoid the reboot?
body: <p><strong>Some context about the setup:</strong> </p>
  
  <p>We're switching from NTLM to Kerberos (Negotiate) for service-to-service authentication between various .NET workloads (e.g. IIS-hosted web API, or simple .NET command line program).</p>
  
  <p>For any call from client to server, there is an API gateway in the middle. We have some custom logic in the gateway for doing the authentication and enforcing Kerberos (rejecting Negotiate headers with an NTLM ticket). The healthy client-server flow looks something like this:</p>
  
  <ol>
  <li><strong>Client</strong> (C) sends request to <strong>server</strong> (S)</li>
  <li><strong>Gateway</strong> (G) intercepts the request</li>
  <li>(G) returns a 401 challenge with <em>WWW-Authenticate: Negotiate</em></li>
  <li>(C) sends the request again, with an <em>Authorization: Negotiate [ticket]</em> header</li>
  <li>(G) inspects <em>[ticket]</em> and:<br>
  5.a If <em>[ticket]</em> is NTLM: "reject" the request (return non-success status code)<br>
  5.b If <em>[ticket]</em> is Kerberos: validate ticket and (if valid) pass the request onto (S)</li>
  </ol>
  
  <p>Now, to not do a big-bang change, we are able to configure (in the gateway) which requests should this Kerberos-check happen for, based on the original destination of the request from (C), which should be the roughly hostname and port of (S).</p>
  
  <p>This setup works fine, but there is this occasional hard-to-replicate issue:</p>
  
  <ul>
  <li>Occasionaly, for some (S), when we enable the Kerberos-check in (G), the client (C) keeps sending NTLM tickets (therefore getting rejected).</li>
  <li>This is despite the fact that all the prerequisites for (C) being able to talk Kerberos to (G) being met - e.g. it is possible to do a <code>klist get HTTP/spn-of-G</code> from (C) and receive a proper Kerberos ticket, even when impersonating the exact same user that (C) would normally run as</li>
  <li>On top of that, there are often other applications on the same server as (C) that go through the same flow just fine</li>
  <li>A reboot of the Windows Server instance that (C) is running on fixes this, making (C) send proper Kerberos ticket to (G) after the restart</li>
  </ul>
  
  <blockquote>
    <p><strong>My question is:</strong> Is there any other possibility to fix such a situation, <em>without rebooting the server</em> ?</p>
  </blockquote>
  
  <p><strong>Things I already tried without success:</strong></p>
  
  <ul>
  <li>Restarting the application running on (C). In case (C) is an IIS application I tried restarting app pool, or <code>iisreset</code>. But I've seen this issue also happen e.g. in a case where (C) is a C# command-line program running to completion every 15min.</li>
  <li>Flushing DNS on the server where (C) runs, with <code>ipconfig /flushdns</code></li>
  <li>Purging all cached Kerberos tickets on the server where (C) runs (with <code>klist purge</code> executed for all logon sessions using a powershell script)</li>
  </ul>