[cifs-protocol] Status: SRX091220600031 [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes usage
Matthieu Patou
mat+Informatique.Samba at matws.net
Mon Jan 11 04:53:56 MST 2010
Hello Bill,
Sorry for the late answer, holidays holidays and holidays ...
So this email brings some answers to some of my questions some remains
not clear for me.
First this page
"http://blogs.msdn.com/openspecification/archive/2009/09/12/msds-supportedencryptiontypes-episode-1-computer-accounts.aspx"
still state "Although this attribute is present in all the computer
objects of the domain regardless of the version of the OS the physical
machines have installed, not all of them are aware of its existence
hence, older versions (2003 and earlier) do not populate it at any
time." even if you just said that this added by some version (vista/w2k8
and higher) will it be updated ?
Also you are basically saying that having ADS_UF_USE_DES_KEY_ONLY don't
make any difference because the content of msDS-SupportedEncryptionTypes
will not present for everything up to XP/w2k3r2, then 1F for vista/w2k8
then 1C for w7/w2k8r2.
I'm quoting your text:
"ADS_UF_USE_DES_KEY_ONLY set in userAccountControl:
2000 SP4, XP SP3, 2003 SP2& 2003 R2:
never present
VISTA SP2& 2008 SP2:
not present
2008 R2& WINDOWS 7:
msDS-SupportedEncryptionTypes: 0x1C =
( RC4_HMAC_MD5 | AES128_CTS_HMAC_SHA1_96 | AES256_CTS_HMAC_SHA1_96 );
"
Concerning this
"
==============================================================================
This blog entry (of msdn)<http://blogs.msdn.com/openspecification/archive/2009/09/12/msds-supportedencryptiontypes-episode-1-computer-accounts.aspx> also states:
"This check is especially relevant in domains that have Win7 and Windows Server 2008 R2 machines joined because those two newer OSs disable their bit by default so older DES is not an option for them.".
Question:
=========
It seems that a w2k3 server member of w2k8 domain do not have this bit set also (userAccountControl=4096 => only WT flag set).
Response:
=========
I agree - the ADS_UF_WORKSTATION_TRUST_ACCOUNT bit only is set on userAccountControl for all computer accounts; if the account is pre-created (for example, using Active Directory Users& Computers), the ADS_UF_PASSWD_NOTREQD bit is also set.
userAccountControl: 0x1000 = ( WORKSTATION_TRUST_ACCOUNT );
userAccountControl: 0x1020 = ( PASSWD_NOTREQD | WORKSTATION_TRUST_ACCOUNT );
ADS_UF_PASSWD_NOTREQD 0x0000020
ADS_UF_WORKSTATION_TRUST_ACCOUNT 0x0001000
=============================================================================="
I might no having been clear, so the entry state that only w7 and w2k8r2 disable the ADS_UF_USE_DES_KEY_ONLY, but it turns out that it's also the case in earlier version. Am I right (as I have only bit ADS_UF_WORKSTATION_TRUST_ACCOUNT set for a joined workstation in a w2k3 domain) ?
"
==============================================================================
Question:
Also neither MS-LSAD nor MS-NRPC talk about the link between the attribute msDS-SupportedEncryptionTypes stored in the AD and the fact that it's returned as SupportedEncTypes in NETLOGON_DOMAIN_INFO call.
I can understand that it can be called "secret" of implementation but when after a workstation tries to update this attribute to let the DC know what are the supported encoding it's better to clarify the link.
Response:
=========
I have filed 3 Technical Document Issues (TDI) as shown below, requesting the cross references to be added.
.....
"
Sorry I don't really understand the change introduced, can you be just more clear and just say that their is a link between
ms-SupportedEncryptionTypes and SupportedEncTypes as the first one is updated by the capable workstation upon reception of an incorrect value in the second one.
Also one last question: the very first time the SupportedEncTypes is returned as the DC as no information about the workstation what should be returned ?
0x00 of 0xFF or something else.
Thank you.
Matthieu.
On 30/12/2009 20:19, Bill Wesse wrote:
> Good day Matthieu - thanks for your patience. I have provided answers to all of your questions below; in addition, I have filed change requests for [MS-ADTS], [MS-LDAS] and [MS-NRPC] concerning cross referencing of SupportedEncTypes and msDS-SupportedEncryptionTypes (this is near the end of this email).
>
> Please let me know if this answers your questions satisfactorily; if so, I will consider the case resolved. Thanks for helping us improve our documentation!
>
> ==============================================================================
> ==============================================================================
> This blog entry (of msdn)<http://blogs.msdn.com/openspecification/archive/2009/09/12/msds-supportedencryptiontypes-episode-1-computer-accounts.aspx> says:
>
> "Although this attribute is present in all the computer objects of the domain regardless of the version of the OS the physical machines have installed, not all of them are aware of its existence hence, older versions (2003 and earlier) do not populate it at any time."
>
> Question:
> =========
>
> It means that when I join a w2k8 domain with a XP workstation that the DC will create a computer object for this XP workstation and set the msDS-SupportedEncryptionTypes attribute?
>
> If so to which value?
>
> On my tests when I join a w2k3 server to a w2k8 domain the attribute SupportedEncryptionTypes is not set. Can this point be clarified and if possible written in a formal document.
>
> In fact that's not only w2k/xp/w2k3, it's the whole range. My assumption is that the phrase is false, and that when the computer object is created it is created without this attribute and then systems newer or equal to vista/windows 2k8 are modifying this attribute to set it to the exact value that they support.
>
> Response:
> =========
>
> You are correct - when the computer object is created, the msDS-SupportedEncryptionTypes attribute is not present. The client will update the object during the first reboot after successfully joining the domain, modifying the msDS-SupportedEncryptionTypes attribute value as shown below:
>
> ADS_UF_USE_DES_KEY_ONLY NOT set in userAccountControl:
>
> 2000 SP4, XP SP3, 2003 SP2& 2003 R2:
> never present
>
> VISTA SP2& 2008 SP2:
> msDS-SupportedEncryptionTypes: 0x1F =
> ( DES_CBC_CRC | DES_CBC_MD5 | RC4_HMAC_MD5 | AES128_CTS_HMAC_SHA1_96 | AES256_CTS_HMAC_SHA1_96 );
>
> 2008 R2& WINDOWS 7:
>
> msDS-SupportedEncryptionTypes: 0x1C =
> ( RC4_HMAC_MD5 | AES128_CTS_HMAC_SHA1_96 | AES256_CTS_HMAC_SHA1_96 );
>
> ADS_UF_USE_DES_KEY_ONLY set in userAccountControl:
>
> 2000 SP4, XP SP3, 2003 SP2& 2003 R2:
> never present
>
> VISTA SP2& 2008 SP2:
> not present
>
> 2008 R2& WINDOWS 7:
>
> msDS-SupportedEncryptionTypes: 0x1C =
> ( RC4_HMAC_MD5 | AES128_CTS_HMAC_SHA1_96 | AES256_CTS_HMAC_SHA1_96 );
>
> Please see the attached zip file for a full set of Wireshark tcpdump captures and ldp dumps of the computer objects.
>
> ==============================================================================
> ==============================================================================
> This blog entry (of msdn)<http://blogs.msdn.com/openspecification/archive/2009/09/12/msds-supportedencryptiontypes-episode-1-computer-accounts.aspx> also states:
>
> When the KDC checks the attribute to decide what encryption algorithm to use in order to encrypt the ticket, it could find basically two scenarios:
>
> 1) The attribute is populated
> 2) The attribute is empty
>
> If the attribute is populated, then the deal is done since the KDC can determine the best common algorithm to encrypt the ticket with the value present.
>
> However, if the attribute is empty then the KDC will have to work harder being the next step to check another attribute. This attribute is defined in MS-ADA3 (section 2.341) and described in MS-ADTS (section 2.2.15) and it's called userAccountControl. This attribute is also a 4 byte Bit Mask that defines many aspects of the account but the only one the KDC is interested in is the DK ( ADS_UF_USE_DES_KEY_ONLY ) bit.
>
> This bit defines what legacy encryption method will be used:
>
> 1) If the bit is set, then only DES will be used
> 2) If the bit is NOT set, then DES and RC4 can be used
>
> This check is especially relevant in domains that have Win7 and Windows Server 2008 R2 machines joined because those two newer OSs disable their bit by default so older DES is not an option for them.
>
> Question:
> =========
>
> What is the exact meaning of ADS_UF_USE_DES_KEY_ONLY?
>
> If a w2k8 server acting as a domain member within a w2k8 domain has this DK bit set, will the DC not use AES but only DES with it?
>
> Response:
> =========
>
> This is essentially for MIT Kerberos-based client and host systems. Generally, a new user account is created for the system in question. The following white paper discusses this in depth:
>
> Step-by-Step Guide to Kerberos 5 (krb5 1.0) Interoperability http://technet.microsoft.com/en-us/library/bb742433.aspx
>
> More information is available in the following white papers:
>
> Windows 2000 Kerberos Interoperability
> http://technet.microsoft.com/en-us/library/bb742432.aspx
>
> Windows 2000 Kerberos Authentication
> http://technet.microsoft.com/en-us/windowsserver/2000/bb742431.aspx
>
> If ADS_UF_USE_DES_KEY_ONLY is set on a (Windows) computer account, Kerberos As and TGS Requests for the account will always fail with KDC_ERR_ETYPE_NOSUPP.
>
> This is true for Windows 2000 through Windows 7, when authenticating with a Windows domain controller (I tested this with Windows 2003 R2 and Windows 2008 R2, in native functional levels).
>
> This does not break the Windows client system functionality, as necessary operations will fall back to NTLM authentication.
>
> So, the blog statement below is correct:
>
> 1) If the bit is set, then only DES will be used, if it is the only EType offered.
> 2) If the bit is NOT set, then AES, RC4 and DES can be used.
>
> Example:
>
> - Kerberos: AS Request Cname: computername$ Realm: DOMAIN.COM Sname: krbtgt/DOMAIN.COM
> - Kerberos: KRB_ERROR - KDC_ERR_ETYPE_NOSUPP (14)
> - Kerberos: TGS Request Realm: DOMAIN.COM Sname: computername$
> - Kerberos: KRB_ERROR - KDC_ERR_ETYPE_NOSUPP (14)
>
> Please see the attached zip file for a full set of Wireshark tcpdump captures and ldp dumps of the computer objects.
>
> ==============================================================================
> ==============================================================================
> This blog entry (of msdn)<http://blogs.msdn.com/openspecification/archive/2009/09/12/msds-supportedencryptiontypes-episode-1-computer-accounts.aspx> also states:
>
> "This check is especially relevant in domains that have Win7 and Windows Server 2008 R2 machines joined because those two newer OSs disable their bit by default so older DES is not an option for them.".
>
> Question:
> =========
>
> It seems that a w2k3 server member of w2k8 domain do not have this bit set also (userAccountControl=4096 => only WT flag set).
>
> Response:
> =========
>
> I agree - the ADS_UF_WORKSTATION_TRUST_ACCOUNT bit only is set on userAccountControl for all computer accounts; if the account is pre-created (for example, using Active Directory Users& Computers), the ADS_UF_PASSWD_NOTREQD bit is also set.
>
> userAccountControl: 0x1000 = ( WORKSTATION_TRUST_ACCOUNT );
> userAccountControl: 0x1020 = ( PASSWD_NOTREQD | WORKSTATION_TRUST_ACCOUNT );
>
> ADS_UF_PASSWD_NOTREQD 0x0000020
> ADS_UF_WORKSTATION_TRUST_ACCOUNT 0x0001000
>
> ==============================================================================
> ==============================================================================
>
> Question:
>
> Also neither MS-LSAD nor MS-NRPC talk about the link between the attribute msDS-SupportedEncryptionTypes stored in the AD and the fact that it's returned as SupportedEncTypes in NETLOGON_DOMAIN_INFO call.
>
> I can understand that it can be called "secret" of implementation but when after a workstation tries to update this attribute to let the DC know what are the supported encoding it's better to clarify the link.
>
> Response:
> =========
>
> I have filed 3 Technical Document Issues (TDI) as shown below, requesting the cross references to be added.
>
> -----
> [MS-ADTS]
> 7.1.6.7.3 msDs-supportedEncryptionTypes
> http://msdn.microsoft.com/en-us/library/cc223853(PROT.13).aspx
>
> Requested references to:
>
> [MS-LSAD] 2.2.7.18 TRUSTED_DOMAIN_SUPPORTED_ENCRYPTION_TYPES
> http://msdn.microsoft.com/en-us/library/cc234304(PROT.13).aspx
>
> [MS-NRPC] 2.2.1.3.11 NETLOGON_DOMAIN_INFO (SupportedEncTypes) http://msdn.microsoft.com/en-us/library/cc237052(PROT.13).aspx
>
> -----
> [MS-LSAD] 2.2.7.18 TRUSTED_DOMAIN_SUPPORTED_ENCRYPTION_TYPES
> http://msdn.microsoft.com/en-us/library/cc234304(PROT.13).aspx
>
> Requested references to:
>
> [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes http://msdn.microsoft.com/en-us/library/cc223853(PROT.13).aspx
>
> [MS-NRPC] 2.2.1.3.11 NETLOGON_DOMAIN_INFO (SupportedEncTypes) http://msdn.microsoft.com/en-us/library/cc237052(PROT.13).aspx
>
> -----
> [MS-NRPC] 2.2.1.3.11 NETLOGON_DOMAIN_INFO (SupportedEncTypes) http://msdn.microsoft.com/en-us/library/cc237052(PROT.13).aspx
>
> Requested reference to:
>
> [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes http://msdn.microsoft.com/en-us/library/cc223853(PROT.13).aspx
>
> ==============================================================================
> Document references
> ==============================================================================
> [MS-ADTS]: Active Directory Technical Specification http://msdn.microsoft.com/en-us/library/cc223122(PROT.13).aspx
>
> 7.1.6.7.3 msDs-supportedEncryptionTypes
> http://msdn.microsoft.com/en-us/library/cc223853(PROT.13).aspx
>
> Windows Server® 2008 operating system and Windows Server® 2008 R2 operating system only.
> Contains bitmapped values that define the encryption types supported by this trust relationship. One or more of the following flags can be set. Unused flags should be set to 0 when writing the attribute and should be ignored when reading the attribute. The flags are presented in big-endian byte order.
>
> CRC (KERB_ENCTYPE_DES_CBC_CRC, 0x00000001) Supports CRC32 as described in [RFC3961] page 31.
> MD5 (KERB_ENCTYPE_DES_CBC_MD5, 0x00000002) Supports RSA-MD5 as described in [RFC3961] page 31.
> RC4 (KERB_ENCTYPE_RC4_HMAC_MD5, 0x00000004) Supports RC4-HMAC-MD5 as described in [RFC-DRAFT-RC4-HMAC].
> A128 (KERB_ENCTYPE_AES128_CTS_HMAC_SHA1_96, 0x00000008) Supports HMAC-SHA1-96-AES128 as described in [RFC3961] page 31.
> A256 (KERB_ENCTYPE_AES256_CTS_HMAC_SHA1_96, 0x00000010) Supports HMAC-SHA1-96-AES256 as described in [RFC3961] page 31.
>
> ==============================================================================
> [MS-LSAD]: Local Security Authority (Domain Policy) Remote Protocol Specification http://msdn.microsoft.com/en-us/library/cc234225(PROT.13).aspx
>
> 2.2.7.18 TRUSTED_DOMAIN_SUPPORTED_ENCRYPTION_TYPES
> http://msdn.microsoft.com/en-us/library/cc234304(PROT.13).aspx
>
> The TRUSTED_DOMAIN_SUPPORTED_ENCRYPTION_TYPES structure is used to present the encryption types that are allowed through a trust.
>
> typedef struct _TRUSTED_DOMAIN_SUPPORTED_ENCRYPTION_TYPES {
> unsigned long SupportedEncryptionTypes; } TRUSTED_DOMAIN_SUPPORTED_ENCRYPTION_TYPES,
> *PTRUSTED_DOMAIN_SUPPORTED_ENCRYPTION_TYPES;
>
> SupportedEncryptionTypes: This field contains bitmapped values that define the encryption types supported by this trust relationship. The flags can be set in any combination.
>
> 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 S A R M C
>
> 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.
>
> ==============================================================================
>
> [MS-NRPC]: Netlogon Remote Protocol Specification http://msdn.microsoft.com/en-us/library/cc237008(PROT.13).aspx
>
> 2.2.1.3.11 NETLOGON_DOMAIN_INFO
> http://msdn.microsoft.com/en-us/library/cc237052(PROT.13).aspx
>
> typedef struct _NETLOGON_DOMAIN_INFO {
> NETLOGON_ONE_DOMAIN_INFO PrimaryDomain;
> unsigned long TrustedDomainCount;
> [size_is(TrustedDomainCount)] PNETLOGON_ONE_DOMAIN_INFO TrustedDomains;
> NETLOGON_LSA_POLICY_INFO LsaPolicy;
> RPC_UNICODE_STRING DnsHostNameInDs;
> RPC_UNICODE_STRING DummyString2;
> RPC_UNICODE_STRING DummyString3;
> RPC_UNICODE_STRING DummyString4;
> unsigned long WorkstationFlags;
> unsigned long SupportedEncTypes;
> unsigned long DummyLong3;
> unsigned long DummyLong4;
> } NETLOGON_DOMAIN_INFO,
> *PNETLOGON_DOMAIN_INFO;
>
> 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.<30>
>
> <30> Section 2.2.1.3.11: SupportedEncTypes was added in Windows Vista and Windows Server 2008. Windows Server 2003 and client and server versions of Windows NT, Windows 2000, and Windows XP ignore this field.
>
> 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
>
>
More information about the cifs-protocol
mailing list