Re: [cifs-protocol] Status: SRX091220600031 [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes usage
Good morning Matthieu. Thanks for your patience. Our documentation team has responded to 3 of the four cross-reference requests. Details are shown below, as well as an attached pdf ([MS-ADTS]_Changes.pdf) showing new text for that document. 1. A request was made for a link in '[MS-ADTS] section 7.1.6.7.3 msDs-supportedEncryptionTypes', pointing to '[MS-LSAD] section 2.2.7.18 TRUSTED_DOMAIN_SUPPORTED_ENCRYPTION_TYPES'. We haven't added this link because the relationship between the trustedDomain!msDs-supportedEncryptionTypes attribute and TRUSTED_DOMAIN_SUPPORTED_ENCRYPTION_TYPES structure is already specified in '[MS-LSAD] section 3.1.1.5 Trusted Domain Object Data Model'. 2. A request was made for a link in '[MS-ADTS] section 7.1.6.7.3 msDs-supportedEncryptionTypes', pointing to '[MS-NRPC] section 2.2.1.3.11 NETLOGON_DOMAIN_INFO (SupportedEncTypes)'. We haven't added this link, because we think this link would be inappropriate, since these two sections are about two different types of object. '[MS-ADTS] section 7.1.6.7.3 msDs-supportedEncryptionTypes' is about trustedDomain objects; however, the NETLOGON_DOMAIN_INFO structure in '[MS-NRPC] section 2.2.1.3.11 NETLOGON_DOMAIN_INFO' provides information on a domain joined computer object. Therefore, instead of adding a cross reference between trustedDomain!msDs-supportedEncryptionTypes and NETLOGON_DOMAIN_INFO, we have added text in the [MS-ADTS] sections noted below providing information on the msDs-supportedEncryptionTypes attribute of the computer object. [MS-ADTS] 7.4.1 State of a Machine Joined to a Domain [MS-ADTS] 7.4.2 State in an Active Directory Domain [MS-ADTS] 7.4.3 Relationship to Protocols 3. A request was made for links in '[MS-LSAD] section 2.2.7.18 TRUSTED_DOMAIN_SUPPORTED_ENCRYPTION_TYPES', pointing to '[MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes' and '[MS-NRPC] 2.2.1.3.11 NETLOGON_DOMAIN_INFO' (SupportedEncTypes). We haven't added these links, because when describing the member SupportedEncTypes of struct NETLOGON_DOMAIN_INFO, '[MS-NRPC] section 2.2.1.3.11 NETLOGON_DOMAIN_INFO' links to section '[MS-LSAD] 2.2.7.18 TRUSTED_DOMAIN_SUPPORTED_ENCRYPTION_TYPES', which describes the structure represented in SupportedEncTypes. Additionally '[MS-LSAD] section 3.1.1.5 Trusted Domain Object Data Model' references '[MS-ADTS] section 7.1.6.7.3 msDs-supportedEncryptionTypes' to link the data retrieved from AD. Also, [MS-LSAD] does not need to reference [MS-NRPC] for the purposes of supported encryption types because MS-LSAD does not consume any encryption type definition in [MS-NRPC]. Additionally, [MS-LSAD] supportedEncryptionTypes usage is for trusts only, whereas [MS-NRPC] supportedEncryptionTypes usage is for both trusts and computers. 4. A request was made for links in '[MS-NRPC] 2.2.1.3.11 NETLOGON_DOMAIN_INFO (SupportedEncTypes)', pointing to '[MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes'. This request is currently pending review. Regards, Bill Wesse MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM 8055 Microsoft Way Charlotte, NC 28273 Email: bil...@microsoft.com Tel:+1(980) 776-8200 Cell: +1(704) 661-5438 Fax:+1(704) 665-9606 ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] Status: SRX091220600031 [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes usage
Hello again Matthieu - here are my follow ups to the unanswered questions. == Unanswered Question 1 == Sorry I don't really understand the change introduced, can you be just more clear and just say that there is a link between msDS-SupportedEncryptionTypes and SupportedEncTypes, as the first one is updated by the capable workstation upon reception of an incorrect value in the second one. Response: I have added your suggestion to the TDI against [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes (http://msdn.microsoft.com/en-us/library/cc223853(PROT.13).aspx). References: msDS-SupportedEncryptionTypes [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes http://msdn.microsoft.com/en-us/library/cc223853(PROT.13).aspx SupportedEncTypes [MS-NRPC] 3.5.5.3.9 NetrLogonGetDomainInfo (Opnum 29) http://msdn.microsoft.com/en-us/library/cc237247(PROT.13).aspx [MS-NRPC] 2.2.1.3.11 NETLOGON_DOMAIN_INFO http://msdn.microsoft.com/en-us/library/cc237052(PROT.13).aspx == Unanswered Question 2 == Also one last question: the very first time the SupportedEncTypes is returned, if the DC has no information about the workstation, what should be returned? 0x00 or 0xFF or something else. Response: As you have noted, NetrLogonGetDomainInfo behavior on this point is not documented (and a debug would be necessary for me to dig into actual behavior, since the calls are encrypted). Please confirm (or update) the accuracy of my rewording reflects you needs properly. Also, please advise me how this impacts your implementation - is that blocking work? I expect to create a new case and TDI for this, once you respond. References: [MS-NRPC] 3.5.5.3.9 NetrLogonGetDomainInfo (Opnum 29) http://msdn.microsoft.com/en-us/library/cc237247(PROT.13).aspx [MS-NRPC] 2.2.1.3.11 NETLOGON_DOMAIN_INFO http://msdn.microsoft.com/en-us/library/cc237052(PROT.13).aspx Regards, Bill Wesse MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM 8055 Microsoft Way Charlotte, NC 28273 Email: bil...@microsoft.com Tel:+1(980) 776-8200 Cell: +1(704) 661-5438 Fax:+1(704) 665-9606 -Original Message- From: Bill Wesse Sent: Monday, January 11, 2010 1:46 PM To: 'Matthieu Patou' Cc: cifs-proto...@samba.org; p...@tridgell.net; Sebastian Canevari Subject: RE: Status: SRX091220600031 [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes usage Good afternoon Matthieu - holidays are good! I've attached a pdf with some changes I am proposing to Sebastian concerning updates to the blog entry. Also, I have (hopefully adequate) answers to your first two questions (I will be working on the last ones about the doc cross-refs NETLOGON_DOMAIN_INFO, as I have some diligence to do on NETLOGON_DOMAIN_INFO). == Unanswered questions == Sorry I don't really understand the change introduced, can you be just more clear and just say that there 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. == Answers... == Question 1 == 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. == Response 1 == I have attached an update to the blog (also as a change proposal to Sebastian), which removes that 'attribute
Re: [cifs-protocol] Status: SRX091220600031 [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes usage
Hi bill, It seems quite ok ! About question2 what we see is mostly 0xFF on server supporting this attribute (w2k8 and upper). Also as a tip for decoding encrypted with schannel you can use dev version of wireshark, we wrote some patch to decode this kind of traffic. Of course you will need keytab with passwords of workstation for decoding. This can be obtain with the net vampire of samba3 ! Matthieu. On 12/01/2010 18:38, Bill Wesse wrote: Hello again Matthieu - here are my follow ups to the unanswered questions. == Unanswered Question 1 == Sorry I don't really understand the change introduced, can you be just more clear and just say that there is a link between msDS-SupportedEncryptionTypes and SupportedEncTypes, as the first one is updated by the capable workstation upon reception of an incorrect value in the second one. Response: I have added your suggestion to the TDI against [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes (http://msdn.microsoft.com/en-us/library/cc223853(PROT.13).aspx). References: msDS-SupportedEncryptionTypes [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes http://msdn.microsoft.com/en-us/library/cc223853(PROT.13).aspx SupportedEncTypes [MS-NRPC] 3.5.5.3.9 NetrLogonGetDomainInfo (Opnum 29) http://msdn.microsoft.com/en-us/library/cc237247(PROT.13).aspx [MS-NRPC] 2.2.1.3.11 NETLOGON_DOMAIN_INFO http://msdn.microsoft.com/en-us/library/cc237052(PROT.13).aspx == Unanswered Question 2 == Also one last question: the very first time the SupportedEncTypes is returned, if the DC has no information about the workstation, what should be returned? 0x00 or 0xFF or something else. Response: As you have noted, NetrLogonGetDomainInfo behavior on this point is not documented (and a debug would be necessary for me to dig into actual behavior, since the calls are encrypted). Please confirm (or update) the accuracy of my rewording reflects you needs properly. Also, please advise me how this impacts your implementation - is that blocking work? I expect to create a new case and TDI for this, once you respond. References: [MS-NRPC] 3.5.5.3.9 NetrLogonGetDomainInfo (Opnum 29) http://msdn.microsoft.com/en-us/library/cc237247(PROT.13).aspx [MS-NRPC] 2.2.1.3.11 NETLOGON_DOMAIN_INFO http://msdn.microsoft.com/en-us/library/cc237052(PROT.13).aspx Regards, Bill Wesse MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM 8055 Microsoft Way Charlotte, NC 28273 Email: bil...@microsoft.com Tel:+1(980) 776-8200 Cell: +1(704) 661-5438 Fax:+1(704) 665-9606 -Original Message- From: Bill Wesse Sent: Monday, January 11, 2010 1:46 PM To: 'Matthieu Patou' Cc: cifs-proto...@samba.org; p...@tridgell.net; Sebastian Canevari Subject: RE: Status: SRX091220600031 [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes usage Good afternoon Matthieu - holidays are good! I've attached a pdf with some changes I am proposing to Sebastian concerning updates to the blog entry. Also, I have (hopefully adequate) answers to your first two questions (I will be working on the last ones about the doc cross-refs NETLOGON_DOMAIN_INFO, as I have some diligence to do on NETLOGON_DOMAIN_INFO). == Unanswered questions == Sorry I don't really understand the change introduced, can you be just more clear and just say that there 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. == Answers... == Question 1 == 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
Re: [cifs-protocol] Status: SRX091220600031 [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes usage
Thanks Matthieu - I will create the new case for the below...(I'm just lazy about Wireshark/keytab, I guess). Could you advise me on how this impacts your implementation progess (this is important for the TDI priority)? Also, I agree NETLOGON_DOMAIN_INFO.SupportedEncTypes returned from (Windows 2008 R2) NetrLogonGetDomainInfo as 0x (a.k.a. (ULONG)-1) is not documented. I think this should indicate to the client that an update to SupportedEncTypes is needed. Also note that an incoming value of 0 also means a client is pre-Vista (Windows), and/or is ignorant of the msDS-SupportedEncryptionTypes attribute. That, of course, will be the gist of what will go into the TDI for the new case. == Unanswered Question 2 == Also one last question: the very first time the SupportedEncTypes is returned, if the DC has no information about the workstation, what should be returned? 0x00 or 0xFF or something else. Response: As you have noted, NetrLogonGetDomainInfo behavior on this point is not documented (and a debug would be necessary for me to dig into actual behavior, since the calls are encrypted). Please confirm (or update) the accuracy of my rewording reflects you needs properly. Also, please advise me how this impacts your implementation - is that blocking work? I expect to create a new case and TDI for this, once you respond. References: [MS-NRPC] 3.5.5.3.9 NetrLogonGetDomainInfo (Opnum 29) http://msdn.microsoft.com/en-us/library/cc237247(PROT.13).aspx [MS-NRPC] 2.2.1.3.11 NETLOGON_DOMAIN_INFO http://msdn.microsoft.com/en-us/library/cc237052(PROT.13).aspx Regards, Bill Wesse MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM 8055 Microsoft Way Charlotte, NC 28273 Email: bil...@microsoft.com Tel:+1(980) 776-8200 Cell: +1(704) 661-5438 Fax:+1(704) 665-9606 -Original Message- From: Matthieu Patou [mailto:mat+informatique.sa...@matws.net] Sent: Tuesday, January 12, 2010 2:08 PM To: Bill Wesse Cc: cifs-proto...@samba.org; p...@tridgell.net; Sebastian Canevari Subject: Re: Status: SRX091220600031 [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes usage Hi bill, It seems quite ok ! About question2 what we see is mostly 0xFF on server supporting this attribute (w2k8 and upper). Also as a tip for decoding encrypted with schannel you can use dev version of wireshark, we wrote some patch to decode this kind of traffic. Of course you will need keytab with passwords of workstation for decoding. This can be obtain with the net vampire of samba3 ! Matthieu. On 12/01/2010 18:38, Bill Wesse wrote: Hello again Matthieu - here are my follow ups to the unanswered questions. == Unanswered Question 1 == Sorry I don't really understand the change introduced, can you be just more clear and just say that there is a link between msDS-SupportedEncryptionTypes and SupportedEncTypes, as the first one is updated by the capable workstation upon reception of an incorrect value in the second one. Response: I have added your suggestion to the TDI against [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes (http://msdn.microsoft.com/en-us/library/cc223853(PROT.13).aspx). References: msDS-SupportedEncryptionTypes [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes http://msdn.microsoft.com/en-us/library/cc223853(PROT.13).aspx SupportedEncTypes [MS-NRPC] 3.5.5.3.9 NetrLogonGetDomainInfo (Opnum 29) http://msdn.microsoft.com/en-us/library/cc237247(PROT.13).aspx [MS-NRPC] 2.2.1.3.11 NETLOGON_DOMAIN_INFO http://msdn.microsoft.com/en-us/library/cc237052(PROT.13).aspx == Unanswered Question 2 == Also one last question: the very first time the SupportedEncTypes is returned, if the DC has no information about the workstation, what should be returned? 0x00 or 0xFF or something else. Response: As you have noted, NetrLogonGetDomainInfo behavior on this point is not documented (and a debug would be necessary for me to dig into actual behavior, since the calls are encrypted). Please confirm (or update) the accuracy of my rewording reflects you needs properly. Also, please advise me how this impacts your implementation - is that blocking work? I expect to create a new case and TDI for this, once you respond. References: [MS-NRPC] 3.5.5.3.9 NetrLogonGetDomainInfo (Opnum 29) http://msdn.microsoft.com/en-us/library/cc237247(PROT.13).aspx [MS-NRPC] 2.2.1.3.11 NETLOGON_DOMAIN_INFO http://msdn.microsoft.com/en-us/library/cc237052(PROT.13).aspx Regards, Bill Wesse
Re: [cifs-protocol] Status: SRX091220600031 [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes usage
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_NOTREQD0x020 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
