[cifs-protocol] 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 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.tT 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 0x. Can you explain this situation ? Thanks. Matthieu Patou. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] 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:m...@matws.net] Sent: Saturday, August 08, 2009 1:55 PM To: p...@tridgell.net; Interoperability Documentation Help; cifs-proto...@samba.org 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 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.tT 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 0x. Can you explain this situation ? Thanks. Matthieu Patou. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] Explain not standard behaviour of Windows 2003 server
Hi Obaid, Now it's more clear concerning the SupportedEncTypes but as I reread the MS-NRPC.pdf doc I still didn't find obvious that the SupportedEncTypes is in fact the list of client's supported encoding as it is currently known by the server. At first I thought it was the list of supported encoding of the server (after all it's the server who is answering ...) Hopefully the mail from sebastian make it clear, it would be great to change the wording in order to make clearer (ie. like it's done for the dnsHostNameId). Regards. Matthieu Patou. On 08/31/2009 07:41 PM, Obaid Farooqi wrote: Hi Matthieu: We have finished our investigation on your question about SupportedEncTypes. The following Windows behavior note will be added in a future release of MS-NRPC, section 7 Appendix B: Product Behavior. This field was added in Vista/WS2008. Clients and Servers of Windows NT, Windows 2000, Windows XP and Windows 2003 ignore this field. Please let me know if it answers your question. If yes, I'll consider this issue resolved. Regards, Obaid Farooqi Sr. Support Escalation Engineer | Microsoft -Original Message- From: Matthieu Patou [mailto:m...@matws.net] Sent: Saturday, August 08, 2009 1:55 PM To: p...@tridgell.net; Interoperability Documentation Help; cifs-proto...@samba.org 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 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.tT 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
Re: [cifs-protocol] Explain not standard behaviour of Windows 2003 server
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:mat+informatique.sa...@matws.net] Sent: Thursday, August 27, 2009 2:30 PM To: Obaid Farooqi Cc: p...@tridgell.net; cifs-proto...@samba.org; 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:mat+informatique.sa...@matws.net] Sent: Tuesday, August 18, 2009 3:11 AM To: Obaid Farooqi Cc: p...@tridgell.net; cifs-proto...@samba.org; 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:mat+informatique.sa...@matws.net] Sent: Saturday, August 15, 2009 8:00 AM To: Obaid Farooqi Cc:p...@tridgell.net;cifs-proto...@samba.org; 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:mat+informatique.sa...@matws.net] Sent: Friday, August 14, 2009 3:10 PM To: Obaid Farooqi Cc:p...@tridgell.net;cifs-proto...@samba.org Subject: Re: [cifs
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:mat+informatique.sa...@matws.net] Sent: Saturday, August 15, 2009 8:00 AM To: Obaid Farooqi Cc:p...@tridgell.net;cifs-proto...@samba.org; 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:mat+informatique.sa...@matws.net] Sent: Friday, August 14, 2009 3:10 PM To: Obaid Farooqi Cc:p...@tridgell.net;cifs-proto...@samba.org 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 0x 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:mat+informatique.sa...@matws.net] Sent: Thursday, August 13, 2009 10:58 AM To: Obaid Farooqi Cc:p...@tridgell.net;cifs-proto...@samba.org 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
Re: [cifs-protocol] Explain not standard behaviour of Windows 2003 server
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:mat+informatique.sa...@matws.net] Sent: Tuesday, August 18, 2009 3:11 AM To: Obaid Farooqi Cc: p...@tridgell.net; cifs-proto...@samba.org; 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:mat+informatique.sa...@matws.net] Sent: Saturday, August 15, 2009 8:00 AM To: Obaid Farooqi Cc:p...@tridgell.net;cifs-proto...@samba.org; 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:mat+informatique.sa...@matws.net] Sent: Friday, August 14, 2009 3:10 PM To: Obaid Farooqi Cc:p...@tridgell.net;cifs-proto...@samba.org 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 0x 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
Re: [cifs-protocol] Explain not standard behaviour of Windows 2003 server
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:mat+informatique.sa...@matws.net] Sent: Saturday, August 15, 2009 8:00 AM To: Obaid Farooqi Cc: p...@tridgell.net; cifs-proto...@samba.org; 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:mat+informatique.sa...@matws.net] Sent: Friday, August 14, 2009 3:10 PM To: Obaid Farooqi Cc: p...@tridgell.net; cifs-proto...@samba.org 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 0x 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:mat+informatique.sa...@matws.net] Sent: Thursday, August 13, 2009 10:58 AM To: Obaid Farooqi Cc: p...@tridgell.net; cifs-proto...@samba.org 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:m...@matws.net] Sent: Tuesday, August 11, 2009 12:23 AM To: Obaid Farooqi Cc: p...@tridgell.net; cifs-proto...@samba.org 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:m...@matws.net] Sent: Monday, August 10, 2009 1:02 PM To: Obaid Farooqi Cc: p...@tridgell.net; cifs-proto...@samba.org 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
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:mat+informatique.sa...@matws.net] Sent: Friday, August 14, 2009 3:10 PM To: Obaid Farooqi Cc: p...@tridgell.net; cifs-proto...@samba.org 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 0x 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:mat+informatique.sa...@matws.net] Sent: Thursday, August 13, 2009 10:58 AM To: Obaid Farooqi Cc: p...@tridgell.net; cifs-proto...@samba.org 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:m...@matws.net] Sent: Tuesday, August 11, 2009 12:23 AM To: Obaid Farooqi Cc: p...@tridgell.net; cifs-proto...@samba.org 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:m...@matws.net] Sent: Monday, August 10, 2009 1:02 PM To: Obaid Farooqi Cc: p...@tridgell.net; cifs-proto...@samba.org 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:m...@matws.net] Sent: Saturday, August 08, 2009 1:55 PM To: p...@tridgell.net; Interoperability Documentation Help; cifs-proto...@samba.org 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
Re: [cifs-protocol] Explain not standard behaviour of Windows 2003 server
Hi Matthieu: Here is what I found out about SupportedEncTypes: Client Server SupportedEncValue -- -- - WS2003 WS2008 0x 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. Regards, Obaid Farooqi Sr. Support Escalation Engineer | Microsoft -Original Message- From: Matthieu Patou [mailto:mat+informatique.sa...@matws.net] Sent: Thursday, August 13, 2009 10:58 AM To: Obaid Farooqi Cc: p...@tridgell.net; cifs-proto...@samba.org 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:m...@matws.net] Sent: Tuesday, August 11, 2009 12:23 AM To: Obaid Farooqi Cc: p...@tridgell.net; cifs-proto...@samba.org 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:m...@matws.net] Sent: Monday, August 10, 2009 1:02 PM To: Obaid Farooqi Cc: p...@tridgell.net; cifs-proto...@samba.org 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:m...@matws.net] Sent: Saturday, August 08, 2009 1:55 PM To: p...@tridgell.net; Interoperability Documentation Help; cifs-proto...@samba.org 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
Re: [cifs-protocol] Explain not standard behaviour of Windows 2003 server
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:mat+informatique.sa...@matws.net] Sent: Friday, August 14, 2009 3:10 PM To: Obaid Farooqi Cc: p...@tridgell.net; cifs-proto...@samba.org 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 0x 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:mat+informatique.sa...@matws.net] Sent: Thursday, August 13, 2009 10:58 AM To: Obaid Farooqi Cc: p...@tridgell.net; cifs-proto...@samba.org 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:m...@matws.net] Sent: Tuesday, August 11, 2009 12:23 AM To: Obaid Farooqi Cc: p...@tridgell.net; cifs-proto...@samba.org 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:m...@matws.net] Sent: Monday, August 10, 2009 1:02 PM To: Obaid Farooqi Cc: p...@tridgell.net; cifs-proto...@samba.org 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:m...@matws.net] Sent: Saturday, August 08, 2009 1:55 PM To: p...@tridgell.net; Interoperability Documentation Help; cifs-proto...@samba.org 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
Re: [cifs-protocol] Explain not standard behaviour of Windows 2003 server
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:m...@matws.net]
Sent: Tuesday, August 11, 2009 12:23 AM
To: Obaid Farooqi
Cc: p...@tridgell.net; cifs-proto...@samba.org
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:m...@matws.net]
Sent: Monday, August 10, 2009 1:02 PM
To: Obaid Farooqi
Cc: p...@tridgell.net; cifs-proto...@samba.org
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:m...@matws.net]
Sent: Saturday, August 08, 2009 1:55 PM
To: p...@tridgell.net; Interoperability Documentation Help;
cifs-proto...@samba.org
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
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
Re: [cifs-protocol] Explain not standard behaviour of Windows 2003 server
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:m...@matws.net] Sent: Saturday, August 08, 2009 1:55 PM To: p...@tridgell.net; Interoperability Documentation Help; cifs-proto...@samba.org 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 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.tT 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 0x. Can you explain this situation ? Thanks. Matthieu Patou. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] Explain not standard behaviour of Windows 2003 server
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:m...@matws.net]
Sent: Monday, August 10, 2009 1:02 PM
To: Obaid Farooqi
Cc: p...@tridgell.net; cifs-proto...@samba.org
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:m...@matws.net]
Sent: Saturday, August 08, 2009 1:55 PM
To: p...@tridgell.net; Interoperability Documentation Help;
cifs-proto...@samba.org
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
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.tT
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
Re: [cifs-protocol] Explain not standard behaviour of Windows 2003 server
Good evening! Thanks for your question about [MS-LSAD] TRUSTED_DOMAIN_SUPPORTED_ENCRYPTION_TYPES. I have created case SRX090808600017 to track our work against your request. One of my team members will take ownership of this case and will be in contact with you on Monday (August 10). Thanks for your patience! Regards, Bill Wesse MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM 8055 Microsoft Way Charlotte, NC 28273 TEL: +1(980) 776-8200 CELL: +1(704) 661-5438 FAX: +1(704) 665-9606 -Original Message- From: Matthieu Patou [mailto:m...@matws.net] Sent: Saturday, August 08, 2009 2:55 PM To: p...@tridgell.net; Interoperability Documentation Help; cifs-proto...@samba.org 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 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.tT 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 0x. Can you explain this situation ? Thanks. Matthieu Patou. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
