Hi Matthieu: I am still working on this issue. Thanks for your patience.
Regards, Obaid Farooqi Sr. Support Escalation Engineer | Microsoft -----Original Message----- From: Matthieu Patou [mailto:[email protected]] Sent: Thursday, August 27, 2009 2:30 PM To: Obaid Farooqi Cc: [email protected]; [email protected]; Interoperability Documentation Help Subject: Re: [cifs-protocol] Explain not standard behaviour of Windows 2003 server Hi obaid, Don't forget about us I'm really interested to have a clear explanation ! Best regards. Matthieu. On 08/18/2009 08:16 PM, Obaid Farooqi wrote: > Hi Matthieu: > Thanks for the clarification. I am working with product team to have an > answer for your question. As soon as I have an answer, I'll be in touch. > > Regards, > Obaid Farooqi > Sr. Support Escalation Engineer | Microsoft > > > -----Original Message----- > From: Matthieu Patou [mailto:[email protected]] > Sent: Tuesday, August 18, 2009 3:11 AM > To: Obaid Farooqi > Cc: [email protected]; [email protected]; Interoperability > Documentation Help > Subject: Re: [cifs-protocol] Explain not standard behaviour of Windows 2003 > server > > Hi obaid, > > I initially made the following question: > > >> Hello, >> >> In MS-NRPC for response to GetDomainInfo the DC usually return a >> NETLOGON_DOMAIN_INFO structure. >> >> This stucture as explained in 2.2.1.3.11 contains a field called >> SupportedEncTypes. >> >> This field is definied like this: >> >> SupportedEncTypes: A set of bit flags that specify the encryption >> types supported, as specified in [MS-LSAD] section 2.2.7.18. See >> [MS-LSAD] for a specification of these bit values and their allowed >> combinations. >> >> >> Looking at MS-LSAD we can learn that the 5th lower bit have the >> following meaning: >> >> C: Supports CRC32, as specified in [RFC3961] page 31. >> M: Supports RSA-MD5, as specified in [RFC3961] page 31. >> R: Supports RC4-HMAC-MD5, as specified in [RFC4757]. >> A: Supports HMAC-SHA1-96-AES128, as specified in [RFC3961] page 31. >> S: Supports HMAC-SHA1-96-AES256, as specified in [RFC3961] page 31. >> All other bits SHOULD be 0 and ignored upon receipt. >> >> >> We can reasonably expect that a freshly installed windows 2003 >> server DC will have bit R set (RC4-HMAC-MD5). >> >> > Unless I'm wrong I still do not have the explanation of why Windows 2003 > returns 0x0 on supported encryption types when I can normally suppose that it > should at least support RC4-HMAC-MD5 (and so have the third bit of the last > byte set). Am I wrong in my logic ? if yes please correct it, if not how can > you explain this ? > > Now if we look at a w2k3 -> w2k8 dialog we have supportedEncType as 0xff ff > ff ff, first it's interesting to note that the server respond differently > depending on the client (w2k8/vista vs w2k3) which should not be the case as > far as I understand the definition for this field. And also it's worth noting > that in this case the server fails to comply to the specification that > indicate that "All other bits SHOULD be 0". > > As we can see two different behavior from the same product (w2k8) depending > on the client I'm still wondering if we will see another behavior with > windows 7 and windows 2008. > > It gives us the following tests to do (well to my mind): > > w2k8r2 -> w2k8 > w7 -> w2k8 > w2k8 -> w2k8r2 > w2k8r2 -> w2k8r2 > vista -> w2k8r2 > w2k3 -> w2k8r2 > w7 -> w2k8r2 > > > Best regards. > > Matthieu Patou. > > > > On 08/16/2009 11:22 PM, Obaid Farooqi wrote: > >> Hi Matthieu: >> Based on your original question, I am trying to explain why there is >> difference in the values of SupportedEncTypes when Windows server 2003 is >> used compared to Windows Server 2008. >> As far as the exact meaning of SupportedEncTypes is concerned, as mentioned >> in your question, it is described in MS-NRPC section 2.2.1.3.11 and MS-LSAD >> 2.2.7.18. >> >> If you have any further question on the meaning of SupportedEncTypes, please >> let me know. >> >> Regards, >> Obaid Farooqi >> Sr. Support Escalation Engineer | Microsoft >> >> -----Original Message----- >> From: Matthieu Patou [mailto:[email protected]] >> Sent: Saturday, August 15, 2009 8:00 AM >> To: Obaid Farooqi >> Cc:[email protected];[email protected]; Interoperability Documentation >> Help >> Subject: Re: [cifs-protocol] Explain not standard behaviour of Windows 2003 >> server >> >> Hi obaid, >> >> So we are waiting for you to provide us the exact meaning of the >> SupportedEncTypes in GetDomainInfo in Netlogon RPC. >> Am I right ? >> >> Regards. >> >> Matthieu. >> >> On 08/15/2009 02:38 AM, Obaid Farooqi wrote: >> >> >>> Hi Matthieu: >>> I did not run the test for win 7 and WS2008R2 but code in unchanged (at the >>> writing of this email) so I would expect the behavior to be same as vista >>> and ws2008. >>> >>> Regards, >>> Obaid Farooqi >>> Sr. Support Escalation Engineer | Microsoft >>> >>> -----Original Message----- >>> From: Matthieu Patou [mailto:[email protected]] >>> Sent: Friday, August 14, 2009 3:10 PM >>> To: Obaid Farooqi >>> Cc:[email protected];[email protected] >>> Subject: Re: [cifs-protocol] Explain not standard behaviour of Windows 2003 >>> server >>> >>> On 08/14/2009 08:01 PM, Obaid Farooqi wrote: >>> >>> >>> >>>> Hi Matthieu: >>>> >>>> Here is what I found out about SupportedEncTypes: >>>> >>>> Client Server SupportedEncValue >>>> ------ ------ ----------------- >>>> WS2003 WS2008 0xffffffff >>>> WS2008 WS2003 0x0 >>>> WS2008 WS2008 0x1f >>>> Vista WS2008 0x1f >>>> >>>> I'll let you know the modifications to MS-NRPC with respect to >>>> SupportedEncTypes as soon as I have them. >>>> >>>> >>>> >>>> >>>> >>> I do not have the opportunity to do it test with windows 7 and windows >>> 2008 R2 if you can investigate with this it could be great. >>> >>> Matthieu. >>> >>> >>> >>>> Regards, >>>> Obaid Farooqi >>>> Sr. Support Escalation Engineer | Microsoft >>>> >>>> -----Original Message----- >>>> From: Matthieu Patou [mailto:[email protected]] >>>> Sent: Thursday, August 13, 2009 10:58 AM >>>> To: Obaid Farooqi >>>> Cc:[email protected];[email protected] >>>> Subject: Re: [cifs-protocol] Explain not standard behaviour of Windows >>>> 2003 server >>>> >>>> Hi Obaid, >>>> >>>> Find attach 2 extraction of DCERPC: >>>> >>>> * dcerpc_w2k3 with a w2k3 DC and a w2k8 client, >>>> * dcerpc_w2k8 with a w2k8 DC and a w2k3 client >>>> >>>> I added an byte extraction of the GetDomainInfo reply for both. In w2k3 >>>> exchange the frame 14 is the first GetDomainInfo reply, in w2K8 it's frame >>>> 31. >>>> >>>> >>>> Regards. >>>> >>>> Matthieu. >>>> >>>> On 08/11/2009 08:23 PM, Obaid Farooqi wrote: >>>> >>>> >>>> >>>> >>>>> Hi Matthieu: >>>>> Thanks for the info. One more request, please send me the traces that you >>>>> collected. As you mentioned, I'll not be able to decrypt the messages but >>>>> it will still be useful to see what messages are passing. Please also >>>>> mention in what frames you saw the issue. >>>>> >>>>> Regards, >>>>> Obaid Farooqi >>>>> Sr. Support Escalation Engineer | Microsoft >>>>> >>>>> -----Original Message----- >>>>> From: Matthieu Patou [mailto:[email protected]] >>>>> Sent: Tuesday, August 11, 2009 12:23 AM >>>>> To: Obaid Farooqi >>>>> Cc:[email protected];[email protected] >>>>> Subject: Re: [cifs-protocol] Explain not standard behaviour of Windows >>>>> 2003 server >>>>> >>>>> Hello Obaid, >>>>> >>>>> So I did the following tests: >>>>> >>>>> W2K8 "client" with a W2K3R2 server >>>>> W2K8 "client" with a W2K8 server >>>>> >>>>> All computers are setuped without any special things: I installed >>>>> windows 2003/2008 and the run a dcpromo for the dc, and then make the >>>>> "client" join the AD domain. >>>>> >>>>> For the w2K3R2 server the ad level is 2000, and for w2K8 the ad level >>>>> is 2008. >>>>> >>>>> I did the trace when I faced bugs with samba4 with W2K8 as a SMB >>>>> client or server, so this trace were done in order to see what's the >>>>> difference between windows 2003/2008 as a DC and samba4. >>>>> >>>>> Note that I noticed the same behavior when looking at trace of other >>>>> samba team member. >>>>> >>>>> Let me know if you do not see the same problem. >>>>> >>>>> Matthieu. >>>>> >>>>> >>>>> On 08/11/2009 02:42 AM, Obaid Farooqi wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> Hi Matthieu: >>>>>> Let's tackle it from a different angle. If you tell me your >>>>>> configuration/environment and what you are exactly doing, I may be able >>>>>> to reproduce this and debug Windows to see what is happening. >>>>>> >>>>>> Please let me know details of your environment and you what are you >>>>>> testing. >>>>>> >>>>>> Regards, >>>>>> Obaid Farooqi >>>>>> Sr. Support Escalation Engineer | Microsoft >>>>>> >>>>>> -----Original Message----- >>>>>> From: Matthieu Patou [mailto:[email protected]] >>>>>> Sent: Monday, August 10, 2009 1:02 PM >>>>>> To: Obaid Farooqi >>>>>> Cc:[email protected];[email protected] >>>>>> Subject: Re: Explain not standard behaviour of Windows 2003 server >>>>>> >>>>>> Hi Obaid, >>>>>> The frames are encrypted (schannel encryption). >>>>>> >>>>>> Do you have the opportunity to rebuild a wireshark if so using my >>>>>> patchs you can quite easily decrypt them of not then it's gonna be >>>>>> more difficult ... >>>>>> >>>>>> Matthieu. >>>>>> On 08/10/2009 08:47 PM, Obaid Farooqi wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Hi Matthieu: >>>>>>> Please send me the network traces for both Windows 2003 and Windows >>>>>>> 2008. Please also mention the number of frames that have the problem. >>>>>>> Please also include the information about the environment, especially >>>>>>> client OS (DC OS is obvious from question). >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>> >>>>>>> Regards, >>>>>>> Obaid Farooqi >>>>>>> Sr. Support Escalation Engineer | Microsoft >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Matthieu Patou [mailto:[email protected]] >>>>>>> Sent: Saturday, August 08, 2009 1:55 PM >>>>>>> To:[email protected]; Interoperability Documentation Help; >>>>>>> [email protected] >>>>>>> Subject: Explain not standard behaviour of Windows 2003 server >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> In MS-NRPC for response to GetDomainInfo the DC usually return a >>>>>>> NETLOGON_DOMAIN_INFO structure. >>>>>>> >>>>>>> This stucture as explained in 2.2.1.3.11 contains a field called >>>>>>> SupportedEncTypes. >>>>>>> >>>>>>> This field is definied like this: >>>>>>> >>>>>>> SupportedEncTypes: A set of bit flags that specify the encryption >>>>>>> types supported, as specified in [MS-LSAD] section 2.2.7.18. See >>>>>>> [MS-LSAD] for a specification of these bit values and their allowed >>>>>>> combinations. >>>>>>> >>>>>>> >>>>>>> Looking at MS-LSAD we can learn that the 5th lower bit have the >>>>>>> following meaning: >>>>>>> >>>>>>> C: Supports CRC32, as specified in [RFC3961] page 31. >>>>>>> M: Supports RSA-MD5, as specified in [RFC3961] page 31. >>>>>>> R: Supports RC4-HMAC-MD5, as specified in [RFC4757]. >>>>>>> A: Supports HMAC-SHA1-96-AES128, as specified in [RFC3961] page 31. >>>>>>> S: Supports HMAC-SHA1-96-AES256, as specified in [RFC3961] page 31. >>>>>>> All other bits SHOULD be 0 and ignored upon receipt. >>>>>>> >>>>>>> >>>>>>> We can reasonably expect that a freshly installed windows 2003 >>>>>>> server DC will have bit R set (RC4-HMAC-MD5). >>>>>>> >>>>>>> Unfortunately it's not the case see at 0x00a4 the field is >>>>>>> completely null >>>>>>> >>>>>>> 0000 83 65 6d 02 2a 9a 4b f2 00 02 00 00 01 00 00 00 .em.*.K......... >>>>>>> 0010 00 00 02 00 0c 00 0e 00 04 00 02 00 16 00 18 00 ................ >>>>>>> 0020 08 00 02 00 16 00 18 00 0c 00 02 00 f7 ed 67 20 ..............g >>>>>>> 0030 9d ca e0 4d a2 51 d9 86 a4 f0 16 24 10 00 02 00 ...M.Q.....$.... >>>>>>> 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 00 00 00 00 00 00 00 00 ................ >>>>>>> 0070 01 00 00 00 14 00 02 00 00 00 00 00 00 00 00 00 ................ >>>>>>> 0080 28 00 2a 00 28 00 02 00 00 00 00 00 00 00 00 00 (.*.(........... >>>>>>> 0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ >>>>>>> 00a0 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ >>>>>>> 00b0 07 00 00 00 00 00 00 00 06 00 00 00 4d 00 53 00 ............M.S. >>>>>>> 00c0 57 00 32 00 4b 00 33 00 0c 00 00 00 00 00 00 00 W.2.K.3......... >>>>>>> 00d0 0b 00 00 00 6d 00 73 00 77 00 32 00 6b 00 33 00 ....m.s.w.2.k.3. >>>>>>> 00e0 2e 00 74 00 73 00 74 00 2e 00 c5 54 0c 00 00 00 ..t.s.t....T.... >>>>>>> 00f0 00 00 00 00 0b 00 00 00 6d 00 73 00 77 00 32 00 ........m.s.w.2. >>>>>>> 0100 6b 00 33 00 2e 00 74 00 73 00 74 00 2e 00 9e fe k.3...t.s.t..... >>>>>>> 0110 04 00 00 00 01 04 00 00 00 00 00 05 15 00 00 00 ................ >>>>>>> 0120 86 ec 41 48 9a 49 bf 58 d1 8f f7 2b 01 00 00 00 ..AH.I.X...+.... >>>>>>> 0130 0c 00 0e 00 18 00 02 00 14 00 16 00 1c 00 02 00 ................ >>>>>>> 0140 00 00 00 00 00 00 00 00 f7 ed 67 20 9d ca e0 4d ..........g ...M >>>>>>> 0150 a2 51 d9 86 a4 f0 16 24 20 00 02 00 10 00 10 00 .Q.....$ ....... >>>>>>> 0160 24 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 $............... >>>>>>> 0170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ >>>>>>> 0180 00 00 00 00 00 00 00 00 00 00 00 00 07 00 00 00 ................ >>>>>>> 0190 00 00 00 00 06 00 00 00 4d 00 53 00 57 00 32 00 ........M.S.W.2. >>>>>>> 01a0 4b 00 33 00 0b 00 00 00 00 00 00 00 0a 00 00 00 K.3............. >>>>>>> 01b0 6d 00 73 00 77 00 32 00 6b 00 33 00 2e 00 74 00 m.s.w.2.k.3...t. >>>>>>> 01c0 73 00 74 00 04 00 00 00 01 04 00 00 00 00 00 05 s.t............. >>>>>>> 01d0 15 00 00 00 86 ec 41 48 9a 49 bf 58 d1 8f f7 2b ......AH.I.X...+ >>>>>>> 01e0 08 00 00 00 00 00 00 00 08 00 00 00 0d 00 00 00 ................ >>>>>>> 01f0 00 00 00 00 02 00 00 00 00 00 00 00 15 00 00 00 ................ >>>>>>> 0200 00 00 00 00 14 00 00 00 73 00 6d 00 62 00 61 00 ........s.m.b.a. >>>>>>> 0210 73 00 76 00 7a 00 30 00 34 00 2e 00 6d 00 73 00 s.v.z.0.4...m.s. >>>>>>> 0220 77 00 32 00 6b 00 33 00 2e 00 74 00 73 00 74 00 w.2.k.3...t.s.t. >>>>>>> 0230 00 00 00 00 .... >>>>>>> >>>>>>> With a windows 2008 server it's not better because I have 0xffffffff. >>>>>>> >>>>>>> Can you explain this situation ? >>>>>>> >>>>>>> Thanks. >>>>>>> Matthieu Patou. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> cifs-protocol mailing list >>>>>> [email protected] >>>>>> https://lists.samba.org/mailman/listinfo/cifs-protocol >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > > _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
