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
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
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==
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?
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.
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.
(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...