Hi Matthieu, Thanks for your feedback.
I have forwarded your request to the product group and they will change the text accordingly should they decide it’s necessary. Regards, Sebastian Canevari Senior Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM 7100 N Hwy 161, Irving, TX - 75039 "Las Colinas - LC2" Tel: +1 469 775 7849 e-mail: seba...@microsoft.com -----Original Message----- From: Matthieu Patou [mailto:mat+informatique.sa...@matws.net] Sent: Tuesday, August 25, 2009 4:28 PM To: Sebastian Canevari Cc: Hongwei Sun; Andrew Bartlett; Nick Meier; p...@tridgell.net; cifs-proto...@samba.org Subject: Re: [cifs-protocol] Clarify reserved bytes that are in fact used in LogonSamLogonEx response Hi sebastian, That's better but it is written: "ExpansionRoom: If NTLMV1 is used, the first 8 bytes represent the LMOWF as specified in [MS-NLMP] section 3.3.1. If NTLMV2, the first 8 bytes are set to the KXKEY ([MS-NLMP] section 3.4.5.1). This MAY be set to zero.<27>" Could it be just a bit more clear something like: "ExpansionRoom: A ten-element array of unsigned 32 bit integers. If NTLMV1 is used, the first 8 bytes represent the LMOWF as specified in [MS-NLMP] section 3.3.1. If NTLMV2, the first 8 bytes are set to the KXKEY ([MS-NLMP] section 3.4.5.1).This may be set to zero. <27>.If set* the following 4 bytes have the same meaning as the UserAccountControl in MS-PAC section xxx. The last 7 bytes MUST/MAY** be set to zero" Note * : I am pretty sure that's always set but it's just a impression from the analysis of different capture for different couple of client/server Note **: It seems that it should be MUST but I have not the opportunity to check if it true in windows product ! Of course that's just my point of view, I might be wrong in the way to write it or even in my analysis. Regards. Matthieu. On 08/25/2009 11:43 PM, Sebastian Canevari wrote: > Hi Matthieu, > > I'm attaching the revised version of section 2.2.1.4.13 of [MS-NRPC]. > > Final version will look somewhere in this lines. > > > Thanks for your help and time. > > Regards, > > > > Sebastian Canevari > Senior Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM > 7100 N Hwy 161, Irving, TX - 75039 > "Las Colinas - LC2" > Tel: +1 469 775 7849 > e-mail: seba...@microsoft.com > > > > -----Original Message----- > From: Matthieu Patou [mailto:mat+informatique.sa...@matws.net] > Sent: Monday, August 24, 2009 2:53 PM > To: Sebastian Canevari > Cc: Hongwei Sun; Andrew Bartlett; Nick Meier; p...@tridgell.net; > cifs-proto...@samba.org > Subject: Re: [cifs-protocol] Clarify reserved bytes that are in fact used in > LogonSamLogonEx response > > Hello sebastien, > > Thanks for the clarification of bits of userflag, it is stated that > Reserved1 is two 32 bit integers that must be equal to 0. > As Windows 2003 at least is not respecting this behavior in when the > auth is made through NTLM maybe it can be worth to add just a note on it > to say that this filed used to contain a value ... > The second thing is that can you also update the list of fields into > MS-NRPC so that the list in MS-PAC and MS-NRPC are synced (latst time I > checked it wasn't the case). > > Thanks. > > Matthieu > On 08/24/2009 10:04 PM, Sebastian Canevari wrote: > >> Hi Matthieu, >> >> I'm attaching a revised version of section 2.5 in [MS-PAC] that reflects the >> changes made to better clarify the meaning of the bits in UserFlags. >> >> Please let me know if you need further help. >> >> Thanks and regards, >> >> > >> >> Sebastian Canevari >> Senior Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM >> 7100 N Hwy 161, Irving, TX - 75039 >> "Las Colinas - LC2" >> Tel: +1 469 775 7849 >> e-mail: seba...@microsoft.com >> >> >> >> -----Original Message----- >> From: Matthieu Patou [mailto:mat+informatique.sa...@matws.net] >> Sent: Wednesday, August 05, 2009 1:18 AM >> To: Hongwei Sun >> Cc: Andrew Bartlett; Nick Meier; p...@tridgell.net; cifs-proto...@samba.org; >> Sebastian Canevari >> Subject: Re: [cifs-protocol] Clarify reserved bytes that are in fact used in >> LogonSamLogonEx response >> >> Hi hongwei, >> >> >> Thanks for the information, I should confess that I usually check the >> WSPP doc only, now that I discover that samba code could be a source of >> documentation as well I'll have a closer look on it. Thanks for pointing >> it ! >> >> Matthieu. >> >> I should try not to forget to look at samba as a source On 08/05/2009 >> 07:43 AM, Hongwei Sun wrote: >> >> >>> Matthieu, >>> >>> >>> The bit in your UserFlags (0x520), that is enabled but undefined in >>> MS-PAC, is bit 0x400. It is LOGON_PROFILE_PATH_RETURNED, which by the way >>> is actually defined in Samba source (librpc/gen_ndr/netlogon.h) too. This >>> bit is turned on when bit I in ParameterControl in >>> NETLOGON_LOGON_IDENTITY_INFO(2.2.1.4.15 MS-NPRC) is enabled. I filed a >>> request to have this confirmed and the document updated. >>> >>> We are also working on checking other bits on UserFlags too. I will >>> keep you posted. >>> >>> Thanks! >>> >>> Hongwei >>> >>> -----Original Message----- >>> From: Matthieu Patou [mailto:mat+informatique.sa...@matws.net] >>> Sent: Saturday, August 01, 2009 4:40 AM >>> To: Hongwei Sun >>> Cc: Andrew Bartlett; Nick Meier; p...@tridgell.net; >>> cifs-proto...@samba.org; Sebastian Canevari; Interoperability Documentation >>> Help >>> Subject: Re: [cifs-protocol] Clarify reserved bytes that are in fact used >>> in LogonSamLogonEx response >>> >>> Hello all, >>> >>> I found the problem. >>> Right now samba4 return 0 as logon and logoff time either in the >>> LogonSamLogonEx (SAM_INFO4 structure) or in kerberos (PAC_LOGON_INFO of >>> PAC). >>> >>> It seems that the srv component that handle smb dialogs in windows 2008 >>> server do not appreciate this answer. >>> >>> Tweaking the source of samba4 to make return 0x7fffffffffffffff >>> (infinite time) for logoff makes it more happy. >>> It would have be simpler to find the problem if windows 2008 returned a >>> more explicit error in place of STATUS_REQUEST_NOT_ACCEPTED. >>> >>> For some reason it seems that this problem do not occur in interactive >>> logons (it's not the same components that are called also). >>> >>> >>> In any case fine inspection through wireshark of a SAM_INFO4 structure >>> returned by a Windows 2003 R2 server to a Windows 2008 server request >>> gives us some User Flags not documented. >>> Users Flags returned:: 20 05 00 00 (last 4 bytes of line 0x70) >>> It gives us 0x520 or 0101 0010 0000 >>> In MS-PAC.pdf only the 12 lower bits are documented which didn't give an >>> explanation for the third bit of the second byte. >>> >>> Can you gives us the explanation of this bit (and others one if applicable). >>> >>> Here is the full content of the sam_info4: >>> >>> >>> 0000 06 00 00 00 00 00 02 00 10 95 6f 37 a6 05 ca 01 ..........o7.... >>> 0010 ff ff ff ff ff ff ff 7f ff ff ff ff ff ff ff 7f ................ >>> 0020 04 53 0a 67 38 61 c9 01 04 13 74 91 01 62 c9 01 .S.g8a....t..b.. >>> 0030 ff ff ff ff ff ff ff 7f 1a 00 1c 00 04 00 02 00 ................ >>> 0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ >>> 0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ >>> 0060 00 00 00 00 00 00 00 00 3b 00 00 00 f4 01 00 00 ........;....... >>> 0070 01 02 00 00 05 00 00 00 08 00 02 00 20 05 00 00 ............ ... >>> 0080 fa 40 c6 06 2c 65 f8 cc 0e 8e 5c 8a 9e 9a 57 b7 ....@..,e....\...W. >>> 0090 14 00 16 00 0c 00 02 00 0c 00 0e 00 10 00 02 00 ................ >>> 00a0 14 00 02 00 c7 b2 00 73 b4 fb 7d b2 10 02 00 00 .......s..}..... >>> 00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ >>> 00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ >>> 00d0 00 00 00 00 14 00 16 00 18 00 02 00 30 00 30 00 ............0.0. >>> 00e0 1c 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ >>> 00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ >>> 0100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ >>> 0110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ >>> 0120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ >>> 0130 00 00 00 00 0e 00 00 00 00 00 00 00 0d 00 00 00 ................ >>> 0140 41 00 64 00 6d 00 69 00 6e 00 69 00 73 00 74 00 A.d.m.i.n.i.s.t. >>> 0150 72 00 61 00 74 00 6f 00 72 00 00 00 05 00 00 00 r.a.t.o.r....... >>> 0160 07 02 00 00 07 00 00 00 08 02 00 00 07 00 00 00 ................ >>> 0170 00 02 00 00 07 00 00 00 06 02 00 00 07 00 00 00 ................ >>> 0180 01 02 00 00 07 00 00 00 0b 00 00 00 00 00 00 00 ................ >>> 0190 0a 00 00 00 57 00 32 00 4b 00 33 00 41 00 44 00 ....W.2.K.3.A.D. >>> 01a0 56 00 5a 00 30 00 31 00 07 00 00 00 00 00 00 00 V.Z.0.1......... >>> 01b0 06 00 00 00 4d 00 53 00 57 00 32 00 4b 00 33 00 ....M.S.W.2.K.3. >>> 01c0 04 00 00 00 01 04 00 00 00 00 00 05 15 00 00 00 ................ >>> 01d0 86 ec 41 48 9a 49 bf 58 d1 8f f7 2b 0b 00 00 00 ..AH.I.X...+.... >>> 01e0 00 00 00 00 0a 00 00 00 6d 00 73 00 77 00 32 00 ........m.s.w.2. >>> 01f0 6b 00 33 00 2e 00 74 00 73 00 74 00 18 00 00 00 k.3...t.s.t..... >>> 0200 00 00 00 00 18 00 00 00 41 00 64 00 6d 00 69 00 ........A.d.m.i. >>> 0210 6e 00 69 00 73 00 74 00 72 00 61 00 74 00 6f 00 n.i.s.t.r.a.t.o. >>> 0220 72 00 40 00 6d 00 73 00 77 00 32 00 6b 00 33 00 r...@.m.s.w.2.k.3. >>> 0230 2e 00 74 00 73 00 74 00 01 00 00 00 00 00 00 00 ..t.s.t......... >>> 0240 00 00 00 00 .... >>> >>> Please also note that if the MS-PAC.pdf could be updated to clearly >>> define the first two long in array ExpansionRoom as being >>> LanmanSessionKey (if confirmed). >>> >>> Regards. >>> >>> Matthieu Patou. >>> >>> On 07/31/2009 04:30 AM, Hongwei Sun wrote: >>> >>> >>> >>>> Andrew, >>>> >>>> We are able to set up environment with a W2k8 server joined to Samba >>>> domain. I ran the three commands you mentioned in your e-mail. >>>> >>>> bin/smbclient //win2008-2/test -Uadministrator%samba2 -d1 -kno >>>> bin/smbclient //win2008-2/test -Uadministrator%samba2 -d1 -kyes >>>> bin/smbclient //win2008-2/test -Uadministrator%samba2 -d1 -kyes >>>> --option=gensec:spnego=no --option=gensec:gssapi_spnego=yes >>>> >>>> I get the same error as you in the first command that is basically >>>> using NTLM. But I have problem with the next two commands that use >>>> Kerberos. Please see the errors returned on screen shots. It complains >>>> when running Kinit command that KDC cannot be reached, but from the Samba >>>> output screen on the back , it shows that KDC is processing TGS-REQ from >>>> the W2k8 server; obviously KDC is working. Could you take a look at it >>>> and give us some advice ? Have we missed configuring anything ? >>>> >>>> Also listing the expected failure from each test will also be >>>> helpful. It will ensure that we have the correct repros. >>>> >>>> Thanks! >>>> >>>> Hongwei >>>> >>>> -----Original Message----- >>>> From: Andrew Bartlett [mailto:abart...@samba.org] >>>> Sent: Friday, July 24, 2009 1:37 AM >>>> To: Interoperability Documentation Help >>>> Cc: p...@tridgell.net; cifs-proto...@samba.org >>>> Subject: Re: [cifs-protocol] Clarify reserved bytes that are in fact used >>>> in LogonSamLogonEx response >>>> >>>> On Mon, 2009-07-20 at 22:00 +1000, Andrew Bartlett wrote: >>>> >>>> >>>> >>>>> G'day, >>>>> >>>>> My friend in Samba development Matthieu has been chasing down small >>>>> but possibly significant differences between Samba4 and Windows. He >>>>> is puzzled by the following, and we wondered if you might be able to >>>>> shed some light on the matter. >>>>> >>>>> >>>>> >>>> I've reproduced the problem locally, and attach the sniffs of the network >>>> behaviour. >>>> >>>> This is being tracked in Samba bug: >>>> >>>> https://bugzilla.samba.org/show_bug.cgi?id=6273 >>>> >>>> >>>> The traces include: >>>> >>>> samba4-to-win2008-failure: >>>> an NTLM login attempt, an attempt to use Samba's own SPNEGO libraries >>>> (which are faulty) >>>> >>>> samba4-to-win2008-failure-gensec_spnego: >>>> a Kerberos login attempt using Heimdal's SPENGO code >>>> >>>> This shows that the problem is not just in NTLM logins, but perhaps in the >>>> PAC/info3 reply. Is some kind of per-user licensing thing tied up here? >>>> I've tried to up the number of users permitted to access the share, >>>> without success. >>>> >>>> If you need any assistance setting up Samba4 to reproduce this, I am more >>>> than willing to assist. >>>> >>>> The commands I used were: >>>> bin/smbclient //win2008-2/test -Uadministrator%samba2 -d1 -kno >>>> bin/smbclient //win2008-2/test -Uadministrator%samba2 -d1 -kyes >>>> bin/smbclient //win2008-2/test -Uadministrator%samba2 -d1 -kyes >>>> --option=gensec:spnego=no --option=gensec:gssapi_spnego=yes >>>> >>>> Also see the attached patch to Samba4 rev >>>> d005e4dabb396607d959ece8da3c649797d59d44 to make the last command work. >>>> >>>> Andrew Bartlett >>>> >>>> -- >>>> Andrew Bartlett >>>> http://samba.org/~abartlet/ >>>> Authentication Developer, Samba Team http://samba.org >>>> Samba Developer, Cisco Inc. >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> cifs-protocol mailing list >>>> cifs-protocol@cifs.org >>>> https://lists.samba.org/mailman/listinfo/cifs-protocol >>>> >>>> >>>> >>> >>> >>> >> >> > > _______________________________________________ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
