Hi Jasnov, Given that I've finally fixed the improper usage of flags, I went forward and added an (undocumented) command line option to enable enhanced NTLMv2 security. If you use --ntlm v2 it will enable this mode, but I could never get it to work properly.
The "--ntlm 2" mode should (if in a working state) make use of NTLMv2 authentication with the features shown in the following packet capture: http://www.freerdp.com/wiki/doku.php?id=nla_win7_win2k8r2_sep Most third party NTLM implementations barely touch the more advanced features of NTLMv2. If you're interested, it'd be cool if you give it a shot, if that's a feature that picks your interest. On Tue, Nov 29, 2011 at 3:33 PM, Marc-André Moreau < marcandre.mor...@gmail.com> wrote: > Ok, I just got it working with the proper definition for flags > > I really hope this isn't going to break anything for others, but it works > the same as the original code, except it's using proper definitions. > > It's pushed on master now > > > On Tue, Nov 29, 2011 at 2:43 PM, Marc-André Moreau < > marcandre.mor...@gmail.com> wrote: > >> I just created a personal "ntlmssp" branch for testing: >> >> https://github.com/awakecoding/FreeRDP/tree/ntlmssp >> >> Just define "ALTERNATE_NTLMSSP" to enable the alternate ntlmssp >> experiments, and see if we can get this working cleanly >> >> Best regards, >> - Marc-Andre >> >> >> On Tue, Nov 29, 2011 at 2:38 PM, Marc-André Moreau < >> marcandre.mor...@gmail.com> wrote: >> >>> 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
