For the moment, I think 0xffffffff is a workable return value, but cannot be authoritative on this (I am obliged to leave that to product development, of course).
I will continue my work on this in the new case [REG:110011276087815]; I have scheduled myself for a code dive tomorrow (to see when 2008R2 does this - some client SPN registration results impact setting the return value to 0xffffffff), followed by a TDI submission. Regards, Bill Wesse MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM 8055 Microsoft Way Charlotte, NC 28273 Email: [email protected] Tel: +1(980) 776-8200 Cell: +1(704) 661-5438 Fax: +1(704) 665-9606 -----Original Message----- From: Matthieu Patou [mailto:[email protected]] Sent: Tuesday, January 12, 2010 5:05 PM To: Bill Wesse Cc: [email protected]; [email protected] Subject: Re: Status: SRX091220600031 [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes usage On 12/01/2010 23:47, Bill Wesse wrote: > 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)? > In fact we had at the begining (september 2009) a default "sensible" value that was DES_CBC_CRC | DES_CBC_MD5 | RC4_HMAC_MD5 when we didn't have any information. But it seems that it caused pb when a w2k8 server made a dcpromo to a S4 domain. so now we return 0xFFFFFFFF. But we wanted to settle on which was the good value and to know if had any idea that this behavior will change anytime soon ! > Also, I agree NETLOGON_DOMAIN_INFO.SupportedEncTypes returned from (Windows > 2008 R2) NetrLogonGetDomainInfo as 0xffffffff (a.k.a. (ULONG)-1) is not > documented. I think this should indicate to the client that an update to > SupportedEncTypes is needed. > > it seems to do its job as w2k8 at least send just after a ldap request for modifying the msDS-SupportedEncryptionTypes. > 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. > > Regards. Matthieu. >> ============================================================================== >> 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: [email protected] > Tel: +1(980) 776-8200 > Cell: +1(704) 661-5438 > Fax: +1(704) 665-9606 > > > -----Original Message----- > From: Matthieu Patou [mailto:[email protected]] > Sent: Tuesday, January 12, 2010 2:08 PM > To: Bill Wesse > Cc: [email protected]; [email protected]; 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 >> MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM >> 8055 Microsoft Way >> Charlotte, NC 28273 >> Email: [email protected] >> 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: [email protected]; [email protected]; 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 is present in all the computer >> objects...' text, among other changes (some of which follow). >> >> ADS_UF_USE_DES_KEY_ONLY does indeed make a serious difference - when set on >> a Windows computer account (this is not a good idea): >> >> If ADS_UF_USE_DES_KEY_ONLY is set on a (Windows) computer account, Windows >> 2003 and newer Domain Controllers will fail Kerberos AS and TGS Requests for >> the krbtgt/domain.name with KDC_ERR_ETYPE_NOSUPP, since Windows clients >> offer non-DES encryption types (see Table 3: Windows Client Offered >> Encryption Types). >> >> However, this does not break Windows client system functionality, as >> necessary operations will fall back to NTLM authentication. Needless to say, >> it is not recommended to set the userAccountControl ADS_UF_USE_DES_KEY_ONLY >> bit on a Windows-based computer account. >> >> ADS_UF_USE_DES_KEY_ONLY is essentially for MIT Kerberos-based client and >> host systems. Generally, a new user account is pre-created for the system in >> question. >> >> ============================================================================== >> Question 2 >> ============================================================================== >> >> 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 not having been clear, so the entry states 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) ? >> >> ============================================================================== >> Response 2 >> ============================================================================== >> You are correct - please note that ADS_UF_USE_DES_KEY_ONLY was first defined >> in Windows 2003 - ADS_UF_USE_DES_KEY_ONLY is never set on a computer account >> by a Windows DC (any version); this is generally done by an admin, when >> pre-creating accounts for use with MIT Kerberos-based client and host >> systems (the blog update addresses this). >> >> ADS_UF_WORKSTATION_TRUST_ACCOUNT is generally the only bit set on a computer >> accounts' userAccountControl attribute by a Windows DC. >> >> Regards, >> Bill Wesse >> MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM >> 8055 Microsoft Way >> Charlotte, NC 28273 >> Email: [email protected] >> Tel: +1(980) 776-8200 >> Cell: +1(704) 661-5438 >> Fax: +1(704) 665-9606 >> >> -----Original Message----- >> From: Matthieu Patou [mailto:[email protected]] >> Sent: Monday, January 11, 2010 6:54 AM >> To: Bill Wesse >> Cc: [email protected]; [email protected]; Sebastian Canevari >> Subject: Re: 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_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 >>> >>> >>> >>> >> >> > > _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
