If I *disable* ntlm_auth and let firefox present a password dialog, I can connect to this site. But if I let firefox use ntlm_auth, it fails thus: YR TlRMTVNTUAABAAAABYIIYAMAAwAgAAAADgAOACMAAABHRVJEV09PREhPVS1NT0JMNQ== NTLMSSP challenge TT TlRMTVNTUAACAAAAAAAAAAAAAAABAgAAVu8jMC5Zq7g= Got 'TT TlRMTVNTUAACAAAAAAAAAAAAAAABAgAAVu8jMC5Zq7g=' from squid (length: 47). got NTLMSSP packet: BH NT_STATUS_UNSUCCESSFUL NTLMSSP BH: NT_STATUS_UNSUCCESSFUL [2013/07/13 21:46:06.639433, 10, pid=2630, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd.c:677(process_request) process_request: request fn NTLMAUTH [2013/07/13 21:46:06.639502, 3, pid=2630, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_ccache_access.c:195(winbindd_ccache_ntlm_auth) [ 3011]: perform NTLM auth on behalf of user GER\dwoodhou [2013/07/13 21:46:06.639536, 10, pid=2630, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_ccache_access.c:255(winbindd_ccache_ntlm_auth) winbindd_dual_ccache_ntlm_auth: found ccache [GER\dwoodhou] [2013/07/13 21:46:06.639559, 10, pid=2630, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_ccache_access.c:37(client_can_access_ccache_entry) Access granted to uid 1000 [2013/07/13 21:46:06.639786, 1, pid=2630, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_ccache_access.c:126(do_ntlm_auth_with_stored_pw) We didn't get a response to the challenge! [NT_STATUS_INVALID_PARAMETER] [2013/07/13 21:46:06.639841, 10, pid=2630, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd.c:773(winbind_client_response_written)
When firefox does it manually it looks like this: Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA= WWW-Authenticate: NTLM TlRMTVNTUAACAAAAAAAAAAAAAAABAgAA1neUhV5iLeo= Authorization: NTLM TlRMTVNTUAADAAAAGAAYAGgAAAAYABgAgAAAAAYABgBAAAAAEAAQAEYAAAASABIAVgAAAAAAAAAAAAAAAQIAAEcARQBSAGQAdwBvAG8AZABoAG8AdQBzAGgAaQBuAHkAYgBvAG8AawDMeQWe+bbvUabrRFEGq9HaRHwUKrISeqLMeQWe+bbvUabrRFEGq9HaRHwUKrISeqI=
The issue here is that the challenge message is only 32 bytes. The 'reserved' and 'target_info' fields are missing entirely. We fixed this in gss-ntlmssp thus: https://git.fedorahosted.org/cgit/gss-ntlmssp.git/commit/?id=fd4464077
Thanks for continuing to work on this... If I don't get to it in a reasonable timeframe please ping me :-).
Ping. Still seeing this. With Simo's GSS-NTLMSSP and some MIT krb5 fixes to handle Kerberos->NTLM fallback better, we finally have single-sign-on working quite nicely from Linux clients to most services. Except the ones that do this...
Created attachment 10817 [details] Test patch for master (also applies to 4.0.x, 4.1.x, 4.2.x). If I'm not mistaken this should fix it - yes ? Can you test this and let me know ? Jeremy.
That works; thanks. I also needed to set 'client NTLMv2 auth = no' to cope with this particular server. Yes, they do the equivalent on all our Windows boxes! We also want the same change in source3/libsmb/ntlmssp.c as well, yes? (I actually tested with both changed, FWIW).
Can you upload a wireshark trace showing the truncated challenge message ? Might help if I get pushback for removing the unused fields.
I forgot about source3/libsmb/ntlmssp.c, I'll create a patch the does both :-).
Created attachment 10818 [details] truncated NTLM capture You already have the base64 challenge; this is just a trick to get me to admit that this crappy server is doing it in HTTP not HTTPS and thus a packet capture is even viable. But sure, I have no shame... (This one is actually different and has 40 bytes in the challenge, not only 32. I think the original server I saw this with has now been decommissioned.)
Created attachment 10834 [details] git-am fix for master. OK, here is the proposed patch I'd like to add to master - if you (David) can confirm it works for you. Does the full parse first, then only falls back to short parse if full parse fails. That way we get log data on which servers are failing this. Cheers, Jeremy.
David - ping - can you confirm the modified patch still works for you ?
Apologies for the delay. Yes, that appears to work. You still want to patch the s3 version too though, right?
(In reply to David Woodhouse from comment #12) That's a 2 entry git-am patch that does fix both source4 and source3.
Comment on attachment 10834 [details] git-am fix for master. Widening the review requests as it's being ignored :-).
Comment on attachment 10834 [details] git-am fix for master. LGTM
pushing to master.
Comment on attachment 10834 [details] git-am fix for master. Thanks Michael. I'll cherry-pick for 4.2.x and below now.
Created attachment 10891 [details] git-am cherry-pick from master for 4.2.next, 4.1.next, 4.0.next. Michael, here's the cherry-pick that applies cleanly to 4.2.next, 4.1.next, 4.0.next.
Comment on attachment 10891 [details] git-am cherry-pick from master for 4.2.next, 4.1.next, 4.0.next. ACK. We should push. to 4.2 and 4.1 4.0 is security-only
Karolin, please push to 4.2 and 4.1. Thanks - Michael
Ah I'd forgotten 4.0.x was security-only. How fast things change. 4.2.x, 4.1.x is fine. Thanks !
(In reply to Jeremy Allison from comment #21) Pardon, Isn't authentication failure, usually a security issue?
Not when it's authentication fail closed, not authentication fail open, for a server that's returning invalid data :-). i.e. we're not getting a CVE for this, nor should we :-).
Pushed to autobuild-v4-[1|2]-test.
(In reply to Karolin Seeger from comment #24) Pushed to both branches. Closing out bug report. Thanks!
Hm, did this regress? Fedora just shipped 4.3.6 and I'm now seeing... $ /usr/bin/ntlm_auth --helper-protocol ntlmssp-client-1 --use-cached-creds --username dwoodhou YR Got 'YR' from squid (length: 2). got NTLMSSP packet: YR TlRMTVNTUAABAAAABYIIYAMAAwAgAAAADgAOACMAAABHRVJEV09PREhPVS1MSU5VWA== NTLMSSP challenge TT TlRMTVNTUAACAAAAAAAAACgAAAABggAAVEkZgItbp3sAAAAAAAAAAA== Got 'TT TlRMTVNTUAACAAAAAAAAACgAAAABggAAVEkZgItbp3sAAAAAAAAAAA==' from squid (length: 59). got NTLMSSP packet: BH NT_STATUS_UNSUCCESSFUL NTLMSSP BH: NT_STATUS_UNSUCCESSFUL
Apologies, it didn't regress. I just ended up with 'client NTLMv2 auth = true' in my configuration due to other testing and had only just restarted. The target info missing from this host's challenge is *required* for NTLMv2, of course. Sorry for the noise.
And in 4.3.8 it did indeed regress... YR Got 'YR' from squid (length: 2). YR TlRMTVNTUAABAAAABYIIYgAAAAAoAAAAAAAAACgAAAAGAQAAAAAADw== TT TlRMTVNTUAACAAAAAAAAACgAAAABggAA5lNkQwhRf+wAAAAAAAAAAA== Got 'TT TlRMTVNTUAACAAAAAAAAACgAAAABggAA5lNkQwhRf+wAAAAAAAAAAA==' from squid (length: 59). Program received signal SIGSEGV, Segmentation fault. 0x00007ffff511e38f in _IO_vfprintf_internal (s=s@entry=0x7fffffffca60, format=<optimized out>, format@entry=0x7ffff56b0988 "talloc: access after free error - first free may be at %s\n", ap=ap@entry=0x7fffffffcbf8) at vfprintf.c:1631 1631 process_string_arg (((struct printf_spec *) NULL)); More details at https://bugzilla.redhat.com/show_bug.cgi?id=1334356
(In reply to David Woodhouse from comment #28) https://bugzilla.samba.org/show_bug.cgi?id=11912 tracks the new bug