[cifs-protocol] Explain not standard behaviour of Windows 2003 server
Matthieu Patou
mat at matws.net
Tue Sep 1 05:48:41 MDT 2009
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:mat at matws.net]
> Sent: Saturday, August 08, 2009 1:55 PM
> To: pfif at tridgell.net; Interoperability Documentation Help; cifs-protocol at 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
>
> 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
> cifs-protocol at cifs.org
> https://lists.samba.org/mailman/listinfo/cifs-protocol
More information about the cifs-protocol
mailing list