Clarify reserved bytes that are in fact used in LogonSamLogonEx response
|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 | Next > |
 |
Clarify reserved bytes that are in fact used in LogonSamLogonEx response
by Andrew Bartlett
::
Rate this Message:
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. Thanks, Andrew Bartlett -------- Original Message -------- Subject: clarify reserved bytes that are in fact used in LogonSamLogonEx response Date: Mon, 20 Jul 2009 00:45:28 +0400 From: Matthieu Patou <mat+Informatique.Samba@...> Hello, Data returned by the LogonSamLogonEx RPC there is a NETLOGON_VALIDATION pointer called ValidationInformation (in MS-NRPC.pdf). The following data is obtained with a Windows 2003R2 server 0000 06 00 00 00 00 00 02 00 10 95 6f 37 a6 05 ca 01 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 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 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 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 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 0150 72 00 61 00 74 00 6f 00 72 00 00 00 05 00 00 00 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 01a0 56 00 5a 00 30 00 31 00 07 00 00 00 00 00 00 00 01b0 06 00 00 00 4d 00 53 00 57 00 32 00 4b 00 33 00 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 01e0 00 00 00 00 0a 00 00 00 6d 00 73 00 77 00 32 00 01f0 6b 00 33 00 2e 00 74 00 73 00 74 00 18 00 00 00 0200 00 00 00 00 18 00 00 00 41 00 64 00 6d 00 69 00 0210 6e 00 69 00 73 00 74 00 72 00 61 00 74 00 6f 00 0220 72 00 40 00 6d 00 73 00 77 00 32 00 6b 00 33 00 0230 2e 00 74 00 73 00 74 00 01 00 00 00 00 00 00 00 0240 00 00 00 00 As the level for this netlogon_validation is 6, the returned data is in fact a pointer to a NETLOGON_VALIDATION_SAM_INFO4 structure called ValidationSam4. It is stated: "All fields of this structure, except the following fields, have the same meaning as the identically named fields in the KERB_VALIDATION_INFO structure, as specified in [MS-PAC] section 2.5. The following is the list of fields that are not found in [MS-PAC]" Reading this document inform us that after LogonDomainId there is reserved1 (at offset 0xa5) "Reserved1: A two-element array of unsigned 32-bit integers. This member is reserved, and each element of the array MUST be equal to 0x00000000 and MUST be ignored on receipt." Clearly it's not the case here because the value is not null: c7 b2 00 73 b4 fb 7d b2. Can you explain the contents of this two longs ? Best regards. Matthieu Patou. -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. _______________________________________________ cifs-protocol mailing list cifs-protocol@... https://lists.samba.org/mailman/listinfo/cifs-protocol |
|
|
Re: Clarify reserved bytes that are in fact used in LogonSamLogonEx response
by Andrew Bartlett
::
Rate this Message:
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. [fix-gssapi_spengo.patch] diff --git a/source4/auth/gensec/gensec_gssapi.c b/source4/auth/gensec/gensec_gssapi.c index 7129db7..bef0ae2 100644 --- a/source4/auth/gensec/gensec_gssapi.c +++ b/source4/auth/gensec/gensec_gssapi.c @@ -460,7 +460,7 @@ static NTSTATUS gensec_gssapi_update(struct gensec_security *gensec_security, gensec_gssapi_state->want_flags, 0, gensec_gssapi_state->input_chan_bindings, - &input_token, + gensec_gssapi_state->gss_exchange_count == 0 ? NULL : &input_token, &gss_oid_p, &output_token, &gensec_gssapi_state->got_flags, /* ret flags */ _______________________________________________ cifs-protocol mailing list cifs-protocol@... https://lists.samba.org/mailman/listinfo/cifs-protocol  samba4-to-win2008-failure.cap (19K) Download Attachment samba4-to-win2008-failure-gssapi_spengo.cap (17K) Download Attachment signature.asc (196 bytes) Download Attachment |
|
|
Inability to use Win2k8 as a member server in Samba4 domain (was Clarify reserved bytes that are in fact used in LogonSamLogonEx response)
by Andrew Bartlett
::
Rate this Message:
On Fri, 2009-07-24 at 16:37 +1000, Andrew Bartlett wrote:
> 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. least advising us of the answer to our initial inquiry? We can handle the Kerberos issue (a partial fix for that is in already in the tree), but the STATUS_REQUEST_NOT_ACCEPTED issue has us stumped. > 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 > http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. _______________________________________________ cifs-protocol mailing list cifs-protocol@... https://lists.samba.org/mailman/listinfo/cifs-protocol |
|
|
Re: Inability to use Win2k8 as a member server in Samba4 domain (was Clarify reserved bytes that are in fact used in LogonSamLogonEx response)
by Sebastian Canevari
::
Rate this Message:
|
|
|
Re: Inability to use Win2k8 as a member server in Samba4 domain (was Clarify reserved bytes that are in fact used in LogonSamLogonEx response)
by Andrew Bartlett
::
Rate this Message:
On Tue, 2009-07-28 at 17:07 -0700, Sebastian Canevari wrote:
> Hi Andrew, > > I'm working with the product group in confirming my findings. > > I am pretty sure that the first two longs in array ExpansionRoom in > NETLOGON_VALIDATION_SAM_INFO4 (2.2.1.4.13 MS-NRPC) are used for the > LanmanSessionKey but like I said I need to confirm it with the product > group before giving you a definitive answer. Indeed. If I had looked more carefully at the Samba Team's netlogon IDL this would have been clear. This means that the actual problem here is unrelated. Perhaps it needs a new case, but can you please reproduce the failure of Win2k8 to operate in a Samba4 domain, and see if you can tell us why this is the case. We have been unable to identify any other differences in the protocol stream at this time. 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@... https://lists.samba.org/mailman/listinfo/cifs-protocol |
|
|
Re: Inability to use Win2k8 as a member server in Samba4 domain (was Clarify reserved bytes that are in fact used in LogonSamLogonEx response)
by Hongwei Sun
::
Rate this Message:
|
|
|
Re: Clarify reserved bytes that are in fact used in LogonSamLogonEx response
by Hongwei Sun
::
Rate this Message:
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@...] Sent: Friday, July 24, 2009 1:37 AM To: Interoperability Documentation Help Cc: pfif@...; cifs-protocol@... 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@... https://lists.samba.org/mailman/listinfo/cifs-protocol Screen-shot-command-1&2.jpg (413K) Download Attachment Screen-shot-command-3.jpg (409K) Download Attachment |
|
|
Re: Clarify reserved bytes that are in fact used in LogonSamLogonEx response
by Matthieu Patou-5
::
Rate this Message:
|
|
|
Re: Clarify reserved bytes that are in fact used in LogonSamLogonEx response
by Hongwei Sun
::
Rate this Message:
|
|
|
Re: Clarify reserved bytes that are in fact used in LogonSamLogonEx response
by Andrew Bartlett
::
Rate this Message:
On Fri, 2009-07-31 at 00:30 +0000, 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. easier to quote etc). As I see it, you need to put: [libdefaults] default_realm = SAMBA4.NET dns_lookup_realm = true dns_lookup_kdc = true into your /etc/krb5.conf (assuming you can get to samba4.net with DNS, otherwise add a manual KDC declaration). 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@... https://lists.samba.org/mailman/listinfo/cifs-protocol |
|
|
Re: Clarify reserved bytes that are in fact used in LogonSamLogonEx response
by Hongwei Sun
::
Rate this Message:
|
|
|
Re: Inability to use Win2k8 as a member server in Samba4 domain (was Clarify reserved bytes that are in fact used in LogonSamLogonEx response)
by Sebastian Canevari
::
Rate this Message:
|
|
|
Re: Clarify reserved bytes that are in fact used in LogonSamLogonEx response
by Hongwei Sun
::
Rate this Message:
|
|
|
Re: Clarify reserved bytes that are in fact used in LogonSamLogonEx response
by Matthieu Patou-5
::
Rate this Message:
|
|
|
Re: Clarify reserved bytes that are in fact used in LogonSamLogonEx response
by Sebastian Canevari
::
Rate this Message:
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@... -----Original Message----- From: Matthieu Patou [mailto:mat+Informatique.Samba@...] Sent: Wednesday, August 05, 2009 1:18 AM To: Hongwei Sun Cc: Andrew Bartlett; Nick Meier; pfif@...; cifs-protocol@...; 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@...] > Sent: Saturday, August 01, 2009 4:40 AM > To: Hongwei Sun > Cc: Andrew Bartlett; Nick Meier; pfif@...; cifs-protocol@...; 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.@.... > 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@...] >> Sent: Friday, July 24, 2009 1:37 AM >> To: Interoperability Documentation Help >> Cc: pfif@...; cifs-protocol@... >> 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@... >> https://lists.samba.org/mailman/listinfo/cifs-protocol >> > > > _______________________________________________ cifs-protocol mailing list cifs-protocol@... https://lists.samba.org/mailman/listinfo/cifs-protocol |
|
|
Re: Clarify reserved bytes that are in fact used in LogonSamLogonEx response
by Matthieu Patou-5
::
Rate this Message:
|
|
|
Re: Clarify reserved bytes that are in fact used in LogonSamLogonEx response
by Sebastian Canevari
::
Rate this Message:
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@... -----Original Message----- From: Matthieu Patou [mailto:mat+Informatique.Samba@...] Sent: Monday, August 24, 2009 2:53 PM To: Sebastian Canevari Cc: Hongwei Sun; Andrew Bartlett; Nick Meier; pfif@...; cifs-protocol@... 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@... > > > > -----Original Message----- > From: Matthieu Patou [mailto:mat+Informatique.Samba@...] > Sent: Wednesday, August 05, 2009 1:18 AM > To: Hongwei Sun > Cc: Andrew Bartlett; Nick Meier; pfif@...; cifs-protocol@...; 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@...] >> Sent: Saturday, August 01, 2009 4:40 AM >> To: Hongwei Sun >> Cc: Andrew Bartlett; Nick Meier; pfif@...; cifs-protocol@...; 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.@.... >> 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@...] >>> Sent: Friday, July 24, 2009 1:37 AM >>> To: Interoperability Documentation Help >>> Cc: pfif@...; cifs-protocol@... >>> 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@... >>> https://lists.samba.org/mailman/listinfo/cifs-protocol >>> >>> >> >> >> > > _______________________________________________ cifs-protocol mailing list cifs-protocol@... https://lists.samba.org/mailman/listinfo/cifs-protocol |
|
|
Re: Clarify reserved bytes that are in fact used in LogonSamLogonEx response
by Matthieu Patou-5
::
Rate this Message:
|
|
|
Re: Clarify reserved bytes that are in fact used in LogonSamLogonEx response
by Sebastian Canevari
::
Rate this Message:
|
|
|
Re: Clarify reserved bytes that are in fact used in LogonSamLogonEx response
by Sebastian Canevari
::
Rate this Message:
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@...] Sent: Tuesday, August 25, 2009 4:28 PM To: Sebastian Canevari Cc: Hongwei Sun; Andrew Bartlett; Nick Meier; pfif@...; cifs-protocol@... 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@... > > > > -----Original Message----- > From: Matthieu Patou [mailto:mat+Informatique.Samba@...] > Sent: Monday, August 24, 2009 2:53 PM > To: Sebastian Canevari > Cc: Hongwei Sun; Andrew Bartlett; Nick Meier; pfif@...; > cifs-protocol@... > 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@... >> >> >> >> -----Original Message----- >> From: Matthieu Patou [mailto:mat+Informatique.Samba@...] >> Sent: Wednesday, August 05, 2009 1:18 AM >> To: Hongwei Sun >> Cc: Andrew Bartlett; Nick Meier; pfif@...; >> cifs-protocol@...; 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@...] >>> Sent: Saturday, August 01, 2009 4:40 AM >>> To: Hongwei Sun >>> Cc: Andrew Bartlett; Nick Meier; pfif@...; >>> cifs-protocol@...; 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.@.... >>> 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@...] >>>> Sent: Friday, July 24, 2009 1:37 AM >>>> To: Interoperability Documentation Help >>>> Cc: pfif@...; cifs-protocol@... >>>> 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@... >>>> https://lists.samba.org/mailman/listinfo/cifs-protocol >>>> >>>> >>>> >>> >>> >>> >> >> > > _______________________________________________ cifs-protocol mailing list cifs-protocol@... https://lists.samba.org/mailman/listinfo/cifs-protocol |
| < Prev | 1 - 2 | Next > |
| Free embeddable forum powered by Nabble | Forum Help |
