[cifs-protocol] Clarify reserved bytes that are in fact used in LogonSamLogonEx response

Sebastian Canevari Sebastian.Canevari at microsoft.com
Fri Sep 18 17:32:57 MDT 2009


Hi Matthieu,

The product group has been working in your suggestion (I understood that we were done with this but I just wanted to let them hear your point of view) and they did modify MS-PAC and MS-NRPC to try to reflect this subject better.
I'm attaching those changes in this e-mail. 
Please let me know what you think about them.

Thanks and regards,

Sebastian


-----Original Message-----
From: Matthieu Patou [mailto:mat+Informatique.Samba at matws.net] 
Sent: Tuesday, August 25, 2009 4:28 PM
To: Sebastian Canevari
Cc: Hongwei Sun; Andrew Bartlett; Nick Meier; pfif at tridgell.net; cifs-protocol at 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: sebastc at microsoft.com
>
>
>
> -----Original Message-----
> From: Matthieu Patou [mailto:mat+Informatique.Samba at matws.net]
> Sent: Monday, August 24, 2009 2:53 PM
> To: Sebastian Canevari
> Cc: Hongwei Sun; Andrew Bartlett; Nick Meier; pfif at tridgell.net; 
> cifs-protocol at 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: sebastc at microsoft.com
>>
>>
>>
>> -----Original Message-----
>> From: Matthieu Patou [mailto:mat+Informatique.Samba at matws.net]
>> Sent: Wednesday, August 05, 2009 1:18 AM
>> To: Hongwei Sun
>> Cc: Andrew Bartlett; Nick Meier; pfif at tridgell.net; 
>> cifs-protocol at 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.Samba at matws.net]
>>> Sent: Saturday, August 01, 2009 4:40 AM
>>> To: Hongwei Sun
>>> Cc: Andrew Bartlett; Nick Meier; pfif at tridgell.net; 
>>> cifs-protocol at 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  . at ..,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. at .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:abartlet at samba.org]
>>>> Sent: Friday, July 24, 2009 1:37 AM
>>>> To: Interoperability Documentation Help
>>>> Cc: pfif at tridgell.net; cifs-protocol at 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 at cifs.org
>>>> https://lists.samba.org/mailman/listinfo/cifs-protocol
>>>>
>>>>
>>>>          
>>>
>>>
>>>        
>>
>>      
>
>    


-------------- next part --------------
A non-text attachment was scrubbed...
Name: MSPACandMSNRPCchangedsections.pdf
Type: application/pdf
Size: 159896 bytes
Desc: MSPACandMSNRPCchangedsections.pdf
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20090918/be73c169/attachment-0001.pdf>


More information about the cifs-protocol mailing list