Bug 10691 - ntlm_auth doesn't give up session key when used with cached credentials
ntlm_auth doesn't give up session key when used with cached credentials
Status: ASSIGNED
Product: Samba 4.0
Classification: Unclassified
Component: Winbind
unspecified
All All
: P5 normal
: ---
Assigned To: Jeremy Allison
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-07-05 22:04 UTC by David Woodhouse
Modified: 2014-08-07 22:48 UTC (History)
1 user (show)

See Also:


Attachments
Partial fix (3.17 KB, patch)
2014-07-05 23:15 UTC, David Woodhouse
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description David Woodhouse 2014-07-05 22:04:18 UTC
Works when given a password for manual auth...

$ ntlm_auth --helper-protocol ntlmssp-client-1  --username dwoodhou --diagnostics --domain=GER 
SF NTLMSSP_FEATURE_SESSION_KEY
Got 'SF NTLMSSP_FEATURE_SESSION_KEY' from squid (length: 30).
Looking for flags to negotiate
OK
PW AA==
Got 'PW AA==' from squid (length: 7).
OK
YR
Got 'YR' from squid (length: 2).
got NTLMSSP packet:
YR TlRMTVNTUAABAAAAFYIIYAMAAwAgAAAADgAOACMAAABHRVJEV09PREhPVS1MSU5VWA==
NTLMSSP challenge
TT TlRMTVNTUAACAAAABgAGADAAAAA1golgERQUjwCYmxMAAAAAAAAAAHAAcAA2AAAARwBFAFIAAgAGAEcARQBSAAEAHABEAFcATwBPAEQASABPAFUALQBMAEkATgBVAFgABAAaAGkAbgBmAHIAYQBkAGUAYQBkAC4AbwByAGcAAwAgAGkANwAuAGkAbgBmAHIAYQBkAGUAYQBkAC4AbwByAGcAAAAAAA==
Got 'TT TlRMTVNTUAACAAAABgAGADAAAAA1golgERQUjwCYmxMAAAAAAAAAAHAAcAA2AAAARwBFAFIAAgAGAEcARQBSAAEAHABEAFcATwBPAEQASABPAFUALQBMAEkATgBVAFgABAAaAGkAbgBmAHIAYQBkAGUAYQBkAC4AbwByAGcAAwAgAGkANwAuAGkAbgBmAHIAYQBkAGUAYQBkAC4AbwByAGcAAAAAAA==' from squid (length: 227).
got NTLMSSP packet:
AF TlRMTVNTUAADAAAAGAAYAEAAAACcAJwAWAAAAAYABgD0AAAAEAAQAPoAAAAcABwACgEAABAAEAAmAQAAFYIIYBNiRVD0vidhNNlcRqdew0uqjR2f8PKKwiO47va8jtAOhwwYhMouriIBAQAAAAAAAIAsDA6dmM8BWcZ9y5pgXF8AAAAAAgAGAEcARQBSAAEAHABEAFcATwBPAEQASABPAFUALQBMAEkATgBVAFgABAAaAGkAbgBmAHIAYQBkAGUAYQBkAC4AbwByAGcAAwAgAGkANwAuAGkAbgBmAHIAYQBkAGUAYQBkAC4AbwByA
Comment 1 David Woodhouse 2014-07-05 22:06:32 UTC
Fails with cached creds. Should do_ccache_ntlm_auth() be returning NT_STATUS_OK instead of NT_STATUS_MORE_PROCESSING_REQUIRED?

$ ntlm_auth --helper-protocol ntlmssp-client-1  --username dwoodhou --diagnostics --domain=GER --use-cached-creds
SF NTLMSSP_FEATURE_SESSION_KEY
Got 'SF NTLMSSP_FEATURE_SESSION_KEY' from squid (length: 30).
Looking for flags to negotiate
OK
YR
Got 'YR' from squid (length: 2).
got NTLMSSP packet:
YR TlRMTVNTUAABAAAAFYIIYAMAAwAgAAAADgAOACMAAABHRVJEV09PREhPVS1MSU5VWA==
NTLMSSP challenge
TT TlRMTVNTUAACAAAABgAGADAAAAA1golgERQUjwCYmxMAAAAAAAAAAHAAcAA2AAAARwBFAFIAAgAGAEcARQBSAAEAHABEAFcATwBPAEQASABPAFUALQBMAEkATgBVAFgABAAaAGkAbgBmAHIAYQBkAGUAYQBkAC4AbwByAGcAAwAgAGkANwAuAGkAbgBmAHIAYQBkAGUAYQBkAC4AbwByAGcAAAAAAA==
Got 'TT TlRMTVNTUAACAAAABgAGADAAAAA1golgERQUjwCYmxMAAAAAAAAAAHAAcAA2AAAARwBFAFIAAgAGAEcARQBSAAEAHABEAFcATwBPAEQASABPAFUALQBMAEkATgBVAFgABAAaAGkAbgBmAHIAYQBkAGUAYQBkAC4AbwByAGcAAwAgAGkANwAuAGkAbgBmAHIAYQBkAGUAYQBkAC4AbwByAGcAAAAAAA==' from squid (length: 227).
got NTLMSSP packet:
KK TlRMTVNTUAADAAAAGAAYAEAAAACcAJwAWAAAAAYABgD0AAAAEAAQAPoAAAAcABwACgEAABAAEAAmAQAAFYIIYJeU+yOI9u39q7udxy2zNsvGD3xzU67oqhbw0oDI1z/lDNwYcDt0YAEBAQAAAAAAAACsSUSdmM8BG6H/0ZwVbwUAAAAAAgAGAEcARQBSAAEAHABEAFcATwBPAEQASABPAFUALQBMAEkATgBVAFgABAAaAGkAbgBmAHIAYQBkAGUAYQBkAC4AbwByAGcAAwAgAGkANwAuAGkAbgBmAHIAYQBkAGUAYQBkAC4AbwByAGcAAAAAAEcARQBSAGQAdwBvAG8AZABoAG8AdQBEAFcATwBPAEQASABPAFUALQBMAEkATgBVAFgA+Lv1HZno8gHl2PAgVMwICw==
NTLMSSP challenge
GF
Got 'GF' from squid (length: 2).
Requested negotiated NTLMSSP flags
BH
GK
Got 'GK' from squid (length: 2).
Requested session key
BH
Comment 2 David Woodhouse 2014-07-05 22:08:14 UTC
Gr. gnome-terminal ate the end of my first successful session log, which looked like this when I was using a manual password:

NTLMSSP OK!
GF
Got 'GF' from squid (length: 2).
Requested negotiated NTLMSSP flags
GF 0x60088215
GK
Got 'GK' from squid (length: 2).
Requested session key
GK yaDKwij/HYTfm8hnCl5e+w==
Comment 3 David Woodhouse 2014-07-05 23:15:22 UTC
Created attachment 10073 [details]
Partial fix

This patch goes some way towards fixing it. But where are we supposed to get the negotiated flags from? Are we supposed to pick them out of the reply packet?
Comment 4 Jeremy Allison 2014-07-09 00:00:51 UTC
I wrote this whilst at Novell, back in 2006. Let me try and load the context back into my head :-).

Can you explain exactly what you're using this with so I can try and understand the issue better ?

Cheers,

Jeremy.
Comment 5 David Woodhouse 2014-07-09 07:00:52 UTC
When implementing a GSSAPI/SSPI mechanism based on winbind/ntlm_auth it's not sufficient just to have winbind handle the challenge/response and give us a fait accompli. We need the session key in order to perform subsequent gss_wrap()/gss_unwrap() operations, etc.

I believe the original user of this facility was Wine:

http://www.kblin.org/code/gsoc/2005/wine_single_sign-on_paper.pdf
http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/secur32/ntlm.c#l416

Although it was really cute that I could use Wine to test automatic SSPI authentication to proxies in the Windows port of the OpenConnect VPN client, that isn't actually my real motivation...

There also exists a GSSAPI module for NTLM on non-Windows systems, gss-ntlmssp: https://fedorahosted.org/gss-ntlmssp/

I'm looking at adding support for winbind cached creds to that, since that will give me consistent GSSAPI single-sign-on to corporate services even in the extremely common case that Kerberos fails due to wrong SPNs.

In fact my immediate need is solved by using libwbclient instead, which *does* correctly give me the session key (modulo bug 10692):
http://david.woodhou.se/gssntlmssp-use-libwbclient-response.patch

We should still fix this bug in ntlm_auth though.
Comment 6 David Woodhouse 2014-08-07 22:48:22 UTC
(In reply to comment #3)
> This patch goes some way towards fixing it. But where are we supposed to get
> the negotiated flags from? Are we supposed to pick them out of the reply
> packet?

No, because they're *wrong* in the reply packet....


$ /usr/bin/ntlm_auth.orig --helper-protocol ntlmssp-client-1 --username dwoodhou --use-cached-creds
SF NTLMSSP_FEATURE_SEAL NTLMSSP_FEATURE_SIGN
Got 'SF NTLMSSP_FEATURE_SEAL NTLMSSP_FEATURE_SIGN' from squid (length: 44).
Looking for flags to negotiate
OK
YR
Got 'YR' from squid (length: 2).
got NTLMSSP packet:
YR TlRMTVNTUAABAAAANYIIYAMAAwAgAAAADgAOACMAAABHRVJEV09PREhPVS1MSU5VWA==
NTLMSSP challenge
TT TlRMTVNTUAACAAAAHAAcADAAAAA1gopgKJ8T5FHiJg4AAAAAAAAAAF4AXgBMAAAARABXAE8ATwBEAEgATwBVAC0ATABJAE4AVQBYAAEAHABEAFcATwBPAEQASABPAFUALQBMAEkATgBVAFgAAgAGAEcARQBSAAMAIABpADcALgBpAG4AZgByAGEAZABlAGEAZAAuAG8AcgBnAAcACADe9V0ikbLPAQAAAAA=
Got 'TT TlRMTVNTUAACAAAAHAAcADAAAAA1gopgKJ8T5FHiJg4AAAAAAAAAAF4AXgBMAAAARABXAE8ATwBEAEgATwBVAC0ATABJAE4AVQBYAAEAHABEAFcATwBPAEQASABPAFUALQBMAEkATgBVAFgAAgAGAEcARQBSAAMAIABpADcALgBpAG4AZgByAGEAZABlAGEAZAAuAG8AcgBnAAcACADe9V0ikbLPAQAAAAA=' from squid (length: 231).
got NTLMSSP packet:
KK TlRMTVNTUAADAAAAGAAYAEAAAACKAIoAWAAAAAYABgDiAAAAEAAQAOgAAAAcABwA+AAAABAAEAAUAQAAFYIIYNLM/8ftp2t8TLtNfHdxLPRl9BfBRjDnYzcnJUtOU4NgKcGUWLrHYmgBAQAAAAAAAAB1AHWRss8BsmH3OZEi4XwAAAAAAQAcAEQAVwBPAE8ARABIAE8AVQAtAEwASQBOAFUAWAACAAYARwBFAFIAAwAgAGkANwAuAGkAbgBmAHIAYQBkAGUAYQBkAC4AbwByAGcABwAIAN71XSKRss8BAAAAAEcARQBSAGQAdwBvAG8AZABoAG8AdQBEAFcATwBPAEQASABPAFUALQBMAEkATgBVAFgAqu8AZWbT6B1dEwcRL85ZFg==
NTLMSSP challenge


Note NTLMSSP_NEGOTIATE_SEAL is set in the first negotiation packet we generate, and it's set in the challenge packet we get back from the server... but it's missing from the authentication packet at the end.

I'm testing this with wine now, and have filed bugs against its handling too: http://bugs.winehq.org/show_bug.cgi?id=37063
It may actually turn out that the error in the SEAL flag is irrelevant because we always need to act as if it's set anyway...