I'm using squid configured thus: auth_param negotiate program /usr/bin/ntlm_auth --helper-protocol=gss-spnego Due to reverse DNS issues, a client sometimes presents a Kerberos ticket for the *wrong* SPN. When this happens, I see: write(2, "GENSEC login failed: NT_STATUS_LOGON_FAILURE\n", 45) = 45 write(1, "NA * NT_STATUS_LOGON_FAILURE\n", 29) = 29 Surely it shouldn't just abort? I would expect it to give me a SPNEGO response telling me to try NTLMSSP next? Yes, my client's negTokenInit *did* offer that: GSS-API Generic Security Service Application Program Interface OID: 1.3.6.1.5.5.2 (SPNEGO - Simple Protected Negotiation) Simple Protected Negotiation negTokenInit mechTypes: 5 items MechType: 1.2.840.113554.1.2.2 (KRB5 - Kerberos 5) MechType: 1.3.5.1.5.2 (iso.3.5.1.5.2) MechType: 1.2.840.48018.1.2.2 (MS KRB5 - Microsoft Kerberos 5) MechType: 1.3.6.1.5.2.5 (iso.3.6.1.5.2.5) MechType: 1.3.6.1.4.1.311.2.2.10 (NTLMSSP - Microsoft NTLM Security Support Provider) mechToken: 60820e3e06092a864886f71201020201006e820e2d30820e... krb5_blob: 60820e3e06092a864886f71201020201006e820e2d30820e...
We don't check the service principal name, we just compare it with what we can find in a keytab. If we can't decrypt it with anything in our keytab, we report logon failure. It isn't for the server to offer a downgrade in this situation, as I understand it. It would be a different matter if the KDC hadn't issued a ticket, as then the client could choose to downgrade.