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
