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 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: 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: Monday, January 11, 2010 6:54 AM 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 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 cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
