The Samba-Bugzilla – Bug 10708
ntlm_auth --helper-protocol=gss-spnego does not fall back to NTLMSSP
Last modified: 2017-01-03 02:58:14 UTC
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: 126.96.36.199.5.5.2 (SPNEGO - Simple Protected Negotiation)
Simple Protected Negotiation
mechTypes: 5 items
MechType: 1.2.840.1135188.8.131.52 (KRB5 - Kerberos 5)
MechType: 184.108.40.206.5.2 (iso.220.127.116.11.2)
MechType: 1.2.840.48018.1.2.2 (MS KRB5 - Microsoft Kerberos 5)
MechType: 18.104.22.168.5.2.5 (iso.22.214.171.124.2.5)
MechType: 126.96.36.199.4.1.3188.8.131.52 (NTLMSSP - Microsoft NTLM Security Support Provider)
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.