Bug 10708 - ntlm_auth --helper-protocol=gss-spnego does not fall back to NTLMSSP
ntlm_auth --helper-protocol=gss-spnego does not fall back to NTLMSSP
Status: NEW
Product: Samba 4.1 and newer
Classification: Unclassified
Component: Winbind
4.1.9
All All
: P5 normal
: ---
Assigned To: Samba QA Contact
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-07-11 12:31 UTC by David Woodhouse
Modified: 2014-07-11 15:57 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Woodhouse 2014-07-11 12:31:13 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: 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...