Hi Jasnov, I'm attempting a different approach, can you double check those definitions and see if they look correct to you?
#define NTLMSSP_NEGOTIATE_56 0x80000000 /* W (0) */ #define NTLMSSP_NEGOTIATE_KEY_EXCH 0x40000000 /* V (1) */ #define NTLMSSP_NEGOTIATE_128 0x20000000 /* U (2) */ #define NTLMSSP_NEGOTIATE_VERSION 0x02000000 /* T (6) */ #define NTLMSSP_NEGOTIATE_TARGET_INFO 0x00800000 /* S (8) */ #define NTLMSSP_REQUEST_NON_NT_SESSION_KEY 0x00400000 /* R (9) */ #define NTLMSSP_NEGOTIATE_IDENTIFY 0x00100000 /* Q (11) */ #define NTLMSSP_NEGOTIATE_EXTENDED_SESSION_SECURITY 0x00080000 /* P (12) */ #define NTLMSSP_TARGET_TYPE_SERVER 0x00020000 /* O (14) */ #define NTLMSSP_TARGET_TYPE_DOMAIN 0x00010000 /* N (15) */ #define NTLMSSP_NEGOTIATE_ALWAYS_SIGN 0x00008000 /* M (16) */ #define NTLMSSP_NEGOTIATE_WORKSTATION_SUPPLIED 0x00002000 /* L (18) */ #define NTLMSSP_NEGOTIATE_DOMAIN_SUPPLIED 0x00001000 /* K (19) */ #define NTLMSSP_NEGOTIATE_NTLM 0x00000200 /* H (22) */ #define NTLMSSP_NEGOTIATE_LM_KEY 0x00000080 /* G (24) */ #define NTLMSSP_NEGOTIATE_DATAGRAM 0x00000040 /* F (25) */ #define NTLMSSP_NEGOTIATE_SEAL 0x00000020 /* E (26) */ #define NTLMSSP_NEGOTIATE_SIGN 0x00000010 /* D (27) */ #define NTLMSSP_REQUEST_TARGET 0x00000004 /* C (29) */ #define NTLMSSP_NEGOTIATE_OEM 0x00000002 /* B (30) */ #define NTLMSSP_NEGOTIATE_UNICODE 0x00000001 /* A (31) */ I find it highly confusing that they've named each bit with a letter which is in reverse order of the bits... why name bit 31 bit 'A'? argh. With those definitions the server disconnects me at the AUTHENTICATE_MESSAGE On Tue, Nov 29, 2011 at 2:10 PM, Marc-André Moreau < marcandre.mor...@gmail.com> wrote: > Hi Jasnov, > > You are right, I'm pretty sure the current code works by a combination of > errors on top of errors that eventually partially cancel out and give > something that "works". However, this is bad, but there are quite a few > things I never really was sure from the spec. If you can help me figure it > out, we can probably fix this. > > The "NEGOTIATE" data structure (section 2.2.2.5) of MS-NLMP defines the > bits in the negotiate flags. Nowhere does it say if it's little-endian, > big-endian, or simply an array of bits straight from bit 0 to bit 31 left > to right. I was under the impression that the latter was right. Sample > 4.2.2 from MS-NLMP might help clarify this, it provides "32 82 02 E2" as a > hex dump. > > Do you have any idea on this? > > Best regards, > - Marc-Andre > > On Tue, Nov 29, 2011 at 9:36 AM, Jasnov, Dmitrij < > dmitrij.jas...@ts.fujitsu.com> wrote: > >> Hi, guys.. >> >> im working now on RDPoverHTTP feature for FreeRDP and have taken the NTLM >> sources from libfreerdp-core for authentification. >> Ive detected a mistake in NTLMSSP flag definition. All indexes are >> defined in wrong way. >> >> freerdp/libfreerdp-core/ntlmssp.c (line 30): >> >> #define NTLMSSP_INDEX_NEGOTIATE_56 0 >> #define NTLMSSP_INDEX_NEGOTIATE_KEY_EXCH 1 >> #define NTLMSSP_INDEX_NEGOTIATE_128 2 >> .... >> #define NTLMSSP_INDEX_REQUEST_TARGET 29 >> #define NTLMSSP_INDEX_NEGOTIATE_OEM 30 >> #define NTLMSSP_INDEX_NEGOTIATE_UNICODE 31 >> >> #define NTLMSSP_NEGOTIATE_56 (1 << >> NTLMSSP_INDEX_NEGOTIATE_56) >> #define NTLMSSP_NEGOTIATE_KEY_EXCH (1 << >> NTLMSSP_INDEX_NEGOTIATE_KEY_EXCH) >> #define NTLMSSP_NEGOTIATE_128 (1 << >> NTLMSSP_INDEX_NEGOTIATE_128) >> .... >> #define NTLMSSP_REQUEST_TARGET (1 << >> NTLMSSP_INDEX_REQUEST_TARGET) >> #define NTLMSSP_NEGOTIATE_OEM (1 << >> NTLMSSP_INDEX_NEGOTIATE_OEM) >> #define NTLMSSP_NEGOTIATE_UNICODE (1 << >> NTLMSSP_INDEX_NEGOTIATE_UNICODE) >> >> It means NTLMSSP_NEGOTIATE_56 has value 0x00000001 - wrong. According to >> [MS-NLMP] specification NTLMSSP_NEGOTIATE_56 has value 0x80000000. >> >> So all flag indexes should be defined with increment in another direction: >> #define NTLMSSP_INDEX_NEGOTIATE_56 >> 31 //0 >> #define NTLMSSP_INDEX_NEGOTIATE_KEY_EXCH >> 30 //1 >> #define NTLMSSP_INDEX_NEGOTIATE_128 >> 29 //2 >> ... >> #define NTLMSSP_INDEX_REQUEST_TARGET >> 2 //29 >> #define NTLMSSP_INDEX_NEGOTIATE_OEM >> 1 //30 >> #define NTLMSSP_INDEX_NEGOTIATE_UNICODE >> 0 //31 >> >> ciao >> >> Dmitrij >> >> ------------------------------------------------------------------------------ >> All the data continuously generated in your IT infrastructure >> contains a definitive record of customers, application performance, >> security threats, fraudulent activity, and more. Splunk takes this >> data and makes sense of it. IT sense. And common sense. >> http://p.sf.net/sfu/splunk-novd2d >> _______________________________________________ >> Freerdp-devel mailing list >> Freerdp-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/freerdp-devel >> > > ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Freerdp-devel mailing list Freerdp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freerdp-devel
