Re: [cifs-protocol] Status: SRX091220600031 [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes usage

[Matthieu Patou]

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)
  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)
  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:
==

Re: [cifs-protocol] Status: SRX091220600031 [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes usage

[Bill Wesse]

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 'attribu

Re: [cifs-protocol] Status: SRX091220600031 [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes usage

[Matthieu Patou]

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 d

Re: [cifs-protocol] Status: SRX091220600031 [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes usage

[Bill Wesse]

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:/

Re: [cifs-protocol] Status: SRX091220600031 [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes usage

[Matthieu Patou]

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 0x.
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 0x (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:  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 

Re: [cifs-protocol] Status: SRX091220600031 [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes usage

[Bill Wesse]

For the moment, I think 0x 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 0x), 
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:  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 5:05 PM
To: Bill Wesse
Cc: cifs-proto...@samba.org; p...@tridgell.net
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 0x.
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 0x (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:  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 val

Re: [cifs-protocol] Status: SRX091220600031 [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes usage

[Bill Wesse]

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

[Andrew Bartlett]

On Mon, 2010-01-25 at 16:44 +, Bill Wesse wrote:
> 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.

I've just started looking at this area again, and am very glad to have
found this thread, because I think there needs to be a few more links or
references here.  There is no information in MS-KILE to indicate that
this attribute changes KDC behaviour, for example.

Where should I look to understand how this attribute changes the KDC,
other than the blog post (which is not precise regarding differences
between AS-REQ and TGS-REQ use of the keys)? 

Thanks,

Andrew Bartlett

___
cifs-protocol mailing list
cifs-protocol@cifs.org
https://lists.samba.org/mailman/listinfo/cifs-protocol