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

Hongwei Sun hongweis at microsoft.com
Tue Aug 4 21:43:55 MDT 2009


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




More information about the cifs-protocol mailing list