Re: How to determine if an account should use AES?

[Sebastian Canevari]

Hi Andrew,

I've been investigating this and I'm still discussing with the product group what would be the best way to better detail this process.

As explained in the document, the KDC will rely on the AD property msDS-SupportedEncryptionTypes.
Now, if the property is not populated by the server or service, then the KDC will default to RC4 which is the legacy type.

With respect to the NETLOGON_DOMAIN_INFO, Matthieu is working with Obaid on that section and I believe Obaid is sending him his response shortly.

Please let me know if you need further assistance.

Thanks and regards,

Sebastian

Sebastian Canevari
Senior Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM
7100 N Hwy 161, Irving, TX - 75039
"Las Colinas - LC2"
Tel: [phone]
e-mail: sebastc@...



-----Original Message-----
From: Andrew Bartlett [mailto:abartlet@...]
Sent: Monday, August 03, 2009 7:29 AM
To: Interoperability Documentation Help
Cc: pfif@...; cifs-protocol@...
Subject: How to determine if an account should use AES?

G'day,

In Windows 2008 mode, we now generate AES keys for user and computer accounts.  The KDC will then issue tickets using those keys.

However, it seems to me that we should not do so for Windows XP and similar targets - ie, those that would not be able to decrypt AES keys.  

In traditional kerberos, you would manually set the encryption types for which you generated keys to the 'safe set' of commonly accepted types.
How, as a domain controller, should I know what encryption types are safe for a particular member server to accept (and for the DC to generate and store)?

Also, where should we return this information:  For example, should we return what encryption types the workstation supports in 2.2.1.3.11
NETLOGON_DOMAIN_INFO: SupportedEncTypes, or is this the encryption types supported by the domain?

Thanks,

Andrew Bartlett

--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.
_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Andrew Bartlett]

On Fri, 2009-08-14 at 11:40 -0700, Sebastian Canevari wrote:
> Hi Andrew,
>
> I've been investigating this and I'm still discussing with the product group what would be the best way to better detail this process.
>
> As explained in the document, the KDC will rely on the AD property msDS-SupportedEncryptionTypes.
> Now, if the property is not populated by the server or service, then the KDC will default to RC4 which is the legacy type.

So, the outstanding question is: what would normally populate that
attribute?

> With respect to the NETLOGON_DOMAIN_INFO, Matthieu is working with Obaid on that section and I believe Obaid is sending him his response shortly.

I have to say, I'm not the wiser from Obaid's answer.   Sorry.

Perhaps you could spell it out a bit more clearly?

Andrew Bartlett

--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.


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

[Sebastian Canevari]

Hi Andrew,

The msDS-SupportedEncryptionTypes attribute is populated at object creation time by the subjects that support the property. It is also updated whenever there's a change on the object's configuration that require an update of the property. Meaning that when a subject changes the type of encryption it supports, it modifies this attribute to reflect the change.

With regards of the NETLOGON_DOMAIN_INFO, I'll check with Obaid to see if I can be of any help.


Please let me know if this answer fully addresses your question.


Thanks and regards,

Sebastian


Sebastian Canevari
Senior Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM
7100 N Hwy 161, Irving, TX - 75039
"Las Colinas - LC2"
Tel: [phone]
e-mail: sebastc@...



-----Original Message-----
From: Andrew Bartlett [mailto:abartlet@...]
Sent: Tuesday, August 18, 2009 1:01 AM
To: Sebastian Canevari
Cc: pfif@...; cifs-protocol@...
Subject: RE: How to determine if an account should use AES?

On Fri, 2009-08-14 at 11:40 -0700, Sebastian Canevari wrote:
> Hi Andrew,
>
> I've been investigating this and I'm still discussing with the product group what would be the best way to better detail this process.
>
> As explained in the document, the KDC will rely on the AD property msDS-SupportedEncryptionTypes.
> Now, if the property is not populated by the server or service, then the KDC will default to RC4 which is the legacy type.

So, the outstanding question is: what would normally populate that attribute?

> With respect to the NETLOGON_DOMAIN_INFO, Matthieu is working with Obaid on that section and I believe Obaid is sending him his response shortly.

I have to say, I'm not the wiser from Obaid's answer.   Sorry.

Perhaps you could spell it out a bit more clearly?

Andrew Bartlett

--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.
_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Andrew Bartlett]

On Wed, 2009-08-19 at 09:41 -0700, Sebastian Canevari wrote:
> Hi Andrew,
>
> The msDS-SupportedEncryptionTypes attribute is populated at object creation time by the subjects that support the property.

So it is modified over LDAP by the Windows Vista (for example) domain
member?

> It is also updated whenever there's a change on the object's
> configuration that require an update of the property.

So if the domain member upgrades, it is expected to reach out and update
this property using LDAP?

Are there any ACL considerations to be aware of here?  Are there any
other restrictions on the values clients might populate here?

> Meaning that when a subject changes the type of encryption it
> supports, it modifies this attribute to reflect the change.

Any chance you can provide an annotated (ie, with a separate document
mentioning frame numbers) PCAP-formatted example network trace and
documentation references to support this?  I would really like to pin
this down firmly before the next alpha, now that I've turned on the
Windows 2008 functional level and therefore AES encryption in our DC.

Thanks,

Andrew Bartlett

--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.


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

[Matthieu PATOU-2]

Hello Sebastian,

I'm coming back to you on this subject.
Last week I made tests with one of the newsest version of samba4 which
tries to pretend to be have a windows 2008 forest/domain and dc
compatibility level.

And I didn't noticed any request from a windows 2008 acting as a client
of my S4 domain.

It raise a few possibilities but two are most probable:

1) S4 is not behaving like windows 2008 enough so that client thinks
that it is not a real windows 2008 and so it don't send this attibute.
2) This attribute is not sent by the client it's just the server that
based on some algorithm (ie. if os.version >=6.0 and os.name contains
"Windows" then set msDS-SupportedEncryptionType)

Can you indicate us if one of the two possibilities are the right one.
If not please indicate the correct one.
If yes please do not forget for the case 1 to indicate what exactly
trigger the sending of this attribute (or what block the transmission)
or if it's case 2 then give us the good algorithm.

In any case I can only reiterate the request of Andrew about pcap
formatted  network  trace with packets which are significant (ie those
holding this attribute).

Best regards.
Matthieu Patou.

On 08/20/2009 02:16 AM, Andrew Bartlett wrote:

> On Wed, 2009-08-19 at 09:41 -0700, Sebastian Canevari wrote:
>> Hi Andrew,
>>
>> The msDS-SupportedEncryptionTypes attribute is populated at object creation time by the subjects that support the property.
>
> So it is modified over LDAP by the Windows Vista (for example) domain
> member?
>
>> It is also updated whenever there's a change on the object's
>> configuration that require an update of the property.
>
> So if the domain member upgrades, it is expected to reach out and update
> this property using LDAP?
>
> Are there any ACL considerations to be aware of here?  Are there any
> other restrictions on the values clients might populate here?
>
>> Meaning that when a subject changes the type of encryption it
>> supports, it modifies this attribute to reflect the change.
>
> Any chance you can provide an annotated (ie, with a separate document
> mentioning frame numbers) PCAP-formatted example network trace and
> documentation references to support this?  I would really like to pin
> this down firmly before the next alpha, now that I've turned on the
> Windows 2008 functional level and therefore AES encryption in our DC.
>
> Thanks,
>
> Andrew Bartlett
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> cifs-protocol mailing list
> cifs-protocol@...
> https://lists.samba.org/mailman/listinfo/cifs-protocol

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

[Sebastian Canevari]

Hi Matthieu and Andrew,


I am looking into this and will update you as soon as I have news.

Thanks!

Sebastian





Sebastian Canevari
Senior Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM
7100 N Hwy 161, Irving, TX - 75039
"Las Colinas - LC2"
Tel: [phone]
e-mail: sebastc@...



-----Original Message-----
From: Matthieu Patou [mailto:mat@...]
Sent: Monday, August 24, 2009 5:22 PM
To: Andrew Bartlett
Cc: Sebastian Canevari; pfif@...; cifs-protocol@...; Interoperability Documentation Help
Subject: Re: [cifs-protocol] How to determine if an account should use AES?

Hello Sebastian,

I'm coming back to you on this subject.
Last week I made tests with one of the newsest version of samba4 which
tries to pretend to be have a windows 2008 forest/domain and dc
compatibility level.

And I didn't noticed any request from a windows 2008 acting as a client
of my S4 domain.

It raise a few possibilities but two are most probable:

1) S4 is not behaving like windows 2008 enough so that client thinks
that it is not a real windows 2008 and so it don't send this attibute.
2) This attribute is not sent by the client it's just the server that
based on some algorithm (ie. if os.version >=6.0 and os.name contains
"Windows" then set msDS-SupportedEncryptionType)

Can you indicate us if one of the two possibilities are the right one.
If not please indicate the correct one.
If yes please do not forget for the case 1 to indicate what exactly
trigger the sending of this attribute (or what block the transmission)
or if it's case 2 then give us the good algorithm.

In any case I can only reiterate the request of Andrew about pcap
formatted  network  trace with packets which are significant (ie those
holding this attribute).

Best regards.
Matthieu Patou.

On 08/20/2009 02:16 AM, Andrew Bartlett wrote:

> On Wed, 2009-08-19 at 09:41 -0700, Sebastian Canevari wrote:
>> Hi Andrew,
>>
>> The msDS-SupportedEncryptionTypes attribute is populated at object creation time by the subjects that support the property.
>
> So it is modified over LDAP by the Windows Vista (for example) domain
> member?
>
>> It is also updated whenever there's a change on the object's
>> configuration that require an update of the property.
>
> So if the domain member upgrades, it is expected to reach out and update
> this property using LDAP?
>
> Are there any ACL considerations to be aware of here?  Are there any
> other restrictions on the values clients might populate here?
>
>> Meaning that when a subject changes the type of encryption it
>> supports, it modifies this attribute to reflect the change.
>
> Any chance you can provide an annotated (ie, with a separate document
> mentioning frame numbers) PCAP-formatted example network trace and
> documentation references to support this?  I would really like to pin
> this down firmly before the next alpha, now that I've turned on the
> Windows 2008 functional level and therefore AES encryption in our DC.
>
> Thanks,
>
> Andrew Bartlett
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> cifs-protocol mailing list
> cifs-protocol@...
> https://lists.samba.org/mailman/listinfo/cifs-protocol

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

[Sebastian Canevari]

Matthieu / Andrew,

I'm attaching a revised version of [MS-KILE]section 3.1.5.4 where the KDC behavior is described for the cases in which the the msDS-SupportedEncryptionTypes is not populated.

Upcoming versions of the document will reflect the changes with same or very similar wording.

I'm still working in providing you a complete and accurate set of responses for your latest set of questions regarding this matter.



Thanks and regards,

Sebastian


Sebastian Canevari
Senior Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM
7100 N Hwy 161, Irving, TX - 75039
"Las Colinas - LC2"
Tel: [phone]
e-mail: sebastc@...



-----Original Message-----
From: Matthieu Patou [mailto:mat@...]
Sent: Monday, August 24, 2009 5:22 PM
To: Andrew Bartlett
Cc: Sebastian Canevari; pfif@...; cifs-protocol@...; Interoperability Documentation Help
Subject: Re: [cifs-protocol] How to determine if an account should use AES?

Hello Sebastian,

I'm coming back to you on this subject.
Last week I made tests with one of the newsest version of samba4 which
tries to pretend to be have a windows 2008 forest/domain and dc
compatibility level.

And I didn't noticed any request from a windows 2008 acting as a client
of my S4 domain.

It raise a few possibilities but two are most probable:

1) S4 is not behaving like windows 2008 enough so that client thinks
that it is not a real windows 2008 and so it don't send this attibute.
2) This attribute is not sent by the client it's just the server that
based on some algorithm (ie. if os.version >=6.0 and os.name contains
"Windows" then set msDS-SupportedEncryptionType)

Can you indicate us if one of the two possibilities are the right one.
If not please indicate the correct one.
If yes please do not forget for the case 1 to indicate what exactly
trigger the sending of this attribute (or what block the transmission)
or if it's case 2 then give us the good algorithm.

In any case I can only reiterate the request of Andrew about pcap
formatted  network  trace with packets which are significant (ie those
holding this attribute).

Best regards.
Matthieu Patou.

On 08/20/2009 02:16 AM, Andrew Bartlett wrote:

> On Wed, 2009-08-19 at 09:41 -0700, Sebastian Canevari wrote:
>> Hi Andrew,
>>
>> The msDS-SupportedEncryptionTypes attribute is populated at object creation time by the subjects that support the property.
>
> So it is modified over LDAP by the Windows Vista (for example) domain
> member?
>
>> It is also updated whenever there's a change on the object's
>> configuration that require an update of the property.
>
> So if the domain member upgrades, it is expected to reach out and update
> this property using LDAP?
>
> Are there any ACL considerations to be aware of here?  Are there any
> other restrictions on the values clients might populate here?
>
>> Meaning that when a subject changes the type of encryption it
>> supports, it modifies this attribute to reflect the change.
>
> Any chance you can provide an annotated (ie, with a separate document
> mentioning frame numbers) PCAP-formatted example network trace and
> documentation references to support this?  I would really like to pin
> this down firmly before the next alpha, now that I've turned on the
> Windows 2008 functional level and therefore AES encryption in our DC.
>
> Thanks,
>
> Andrew Bartlett
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> cifs-protocol mailing list
> cifs-protocol@...
> https://lists.samba.org/mailman/listinfo/cifs-protocol

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

[Sebastian Canevari]

Hi Andrew / Matthieu,


I'm answering all the questions that were still pending (inline):


. So it is modified over LDAP by the Windows Vista (for example) domain member?
Yes, whenever the Kerberos encryption types supported by the Kerberos server (Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2) are changed, Windows will use LDAP to update the msDS-SupportedEncryptionTypes.


. So if the domain member upgrades, it is expected to reach out and update this property using LDAP?
No, this attribute is only updated when different from the configuration on the Kerberos server. Now that said, in Windows 7 and Windows Server 2008 R2 we disable DES by default, so the attribute is updated.


. Are there any ACL considerations to be aware of here?
Yes, the ACL of the  msDS-SupportedEncryptionTypes attribute.


. Are there any other restrictions on the values clients might populate here?
As specified in [MS-KILE] Section 3.1.5.4, KILE only supports the first 5 bits and ignores all others. We might be using the other bits as more crypto is supported in the RFC.


. I would really like to pin this down firmly before the next alpha, now that I've turned on the Windows 2008 functional level and therefore AES encryption in our DC.
This would not impact the value. The value is what the Kerberos server supports. DFL will not change the value.


. It raise a few possibilities but two are most probable:
1) S4 is not behaving like windows 2008 enough so that client thinks that it is not a real windows 2008 and so it don't send this attibute.
2) This attribute is not sent by the client it's just the server that based on some algorithm (ie. if os.version >=6.0 and os.name contains "Windows" then set msDS-SupportedEncryptionType)

Guessing that your DC is either not returning SupportedEncTypes ([MS-NRPC] Section 2.2.1.3.11) when system calls NetrLogonGetDomainInfo() ([MS-NRPC] Section 3.5.4.3.9) or that the value in msDS-SupportedEncryptionType is correct based on what you are returning.
If the server does not return the value after the call, then the client OS assumes that the attribute is not present on AD (unsupported or legacy) thus it does not try to populate it.
If the value returned is fine, so the client does not need to update.


. Any chance you can provide an annotated (ie, with a separate document mentioning frame numbers) PCAP-formatted example network trace and documentation references to support this?
If after these clarifications you still need a network trace, I can work with you on that.

Thanks and regards,

Sebastian

Sebastian Canevari
Senior Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM
7100 N Hwy 161, Irving, TX - 75039
"Las Colinas - LC2"
Tel: [phone]
e-mail: sebastc@...



-----Original Message-----
From: Sebastian Canevari
Sent: Friday, August 28, 2009 4:36 PM
To: 'Matthieu Patou'; Andrew Bartlett
Cc: pfif@...; cifs-protocol@...
Subject: RE: [cifs-protocol] How to determine if an account should use AES?

Matthieu / Andrew,

I'm attaching a revised version of [MS-KILE]section 3.1.5.4 where the KDC behavior is described for the cases in which the the msDS-SupportedEncryptionTypes is not populated.

Upcoming versions of the document will reflect the changes with same or very similar wording.

I'm still working in providing you a complete and accurate set of responses for your latest set of questions regarding this matter.



Thanks and regards,

Sebastian


Sebastian Canevari
Senior Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM 7100 N Hwy 161, Irving, TX - 75039 "Las Colinas - LC2"
Tel: [phone]
e-mail: sebastc@...



-----Original Message-----
From: Matthieu Patou [mailto:mat@...]
Sent: Monday, August 24, 2009 5:22 PM
To: Andrew Bartlett
Cc: Sebastian Canevari; pfif@...; cifs-protocol@...; Interoperability Documentation Help
Subject: Re: [cifs-protocol] How to determine if an account should use AES?

Hello Sebastian,

I'm coming back to you on this subject.
Last week I made tests with one of the newsest version of samba4 which tries to pretend to be have a windows 2008 forest/domain and dc compatibility level.

And I didn't noticed any request from a windows 2008 acting as a client of my S4 domain.

It raise a few possibilities but two are most probable:

1) S4 is not behaving like windows 2008 enough so that client thinks that it is not a real windows 2008 and so it don't send this attibute.
2) This attribute is not sent by the client it's just the server that based on some algorithm (ie. if os.version >=6.0 and os.name contains "Windows" then set msDS-SupportedEncryptionType)

Can you indicate us if one of the two possibilities are the right one.
If not please indicate the correct one.
If yes please do not forget for the case 1 to indicate what exactly trigger the sending of this attribute (or what block the transmission) or if it's case 2 then give us the good algorithm.

In any case I can only reiterate the request of Andrew about pcap formatted  network  trace with packets which are significant (ie those holding this attribute).

Best regards.
Matthieu Patou.

On 08/20/2009 02:16 AM, Andrew Bartlett wrote:

> On Wed, 2009-08-19 at 09:41 -0700, Sebastian Canevari wrote:
>> Hi Andrew,
>>
>> The msDS-SupportedEncryptionTypes attribute is populated at object creation time by the subjects that support the property.
>
> So it is modified over LDAP by the Windows Vista (for example) domain
> member?
>
>> It is also updated whenever there's a change on the object's
>> configuration that require an update of the property.
>
> So if the domain member upgrades, it is expected to reach out and
> update this property using LDAP?
>
> Are there any ACL considerations to be aware of here?  Are there any
> other restrictions on the values clients might populate here?
>
>> Meaning that when a subject changes the type of encryption it
>> supports, it modifies this attribute to reflect the change.
>
> Any chance you can provide an annotated (ie, with a separate document
> mentioning frame numbers) PCAP-formatted example network trace and
> documentation references to support this?  I would really like to pin
> this down firmly before the next alpha, now that I've turned on the
> Windows 2008 functional level and therefore AES encryption in our DC.
>
> Thanks,
>
> Andrew Bartlett
>
>
>
> ----------------------------------------------------------------------
> --
>
> _______________________________________________
> cifs-protocol mailing list
> cifs-protocol@...
> https://lists.samba.org/mailman/listinfo/cifs-protocol

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

[Matthieu Patou-5]

Hi Sebastian,
As for myself you provided a lot a good explanations that fulfills my
questions. I will try to do force a supported encoding !=0 and !=0x1f
(ie. 0x0f) in samba4 in order to see if I can trigger the request for
changing the value of msDS-SupportedEncryptionTypes from the client.

In any case thank you because for things looks much more clear !

Matthieu.



08/31/2009 06:43 PM, Sebastian Canevari wrote:

> Hi Andrew / Matthieu,
>
>
> I'm answering all the questions that were still pending (inline):
>
>
> . So it is modified over LDAP by the Windows Vista (for example) domain member?
> Yes, whenever the Kerberos encryption types supported by the Kerberos server (Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2) are changed, Windows will use LDAP to update the msDS-SupportedEncryptionTypes.
>
>
> . So if the domain member upgrades, it is expected to reach out and update this property using LDAP?
> No, this attribute is only updated when different from the configuration on the Kerberos server. Now that said, in Windows 7 and Windows Server 2008 R2 we disable DES by default, so the attribute is updated.
>
>
> . Are there any ACL considerations to be aware of here?
> Yes, the ACL of the  msDS-SupportedEncryptionTypes attribute.
>
>
> . Are there any other restrictions on the values clients might populate here?
> As specified in [MS-KILE] Section 3.1.5.4, KILE only supports the first 5 bits and ignores all others. We might be using the other bits as more crypto is supported in the RFC.
>
>
> . I would really like to pin this down firmly before the next alpha, now that I've turned on the Windows 2008 functional level and therefore AES encryption in our DC.
> This would not impact the value. The value is what the Kerberos server supports. DFL will not change the value.
>
>
> . It raise a few possibilities but two are most probable:
> 1) S4 is not behaving like windows 2008 enough so that client thinks that it is not a real windows 2008 and so it don't send this attibute.
> 2) This attribute is not sent by the client it's just the server that based on some algorithm (ie. if os.version>=6.0 and os.name contains "Windows" then set msDS-SupportedEncryptionType)
>
> Guessing that your DC is either not returning SupportedEncTypes ([MS-NRPC] Section 2.2.1.3.11) when system calls NetrLogonGetDomainInfo() ([MS-NRPC] Section 3.5.4.3.9) or that the value in msDS-SupportedEncryptionType is correct based on what you are returning.
> If the server does not return the value after the call, then the client OS assumes that the attribute is not present on AD (unsupported or legacy) thus it does not try to populate it.
> If the value returned is fine, so the client does not need to update.
>
>
> . Any chance you can provide an annotated (ie, with a separate document mentioning frame numbers) PCAP-formatted example network trace and documentation references to support this?
> If after these clarifications you still need a network trace, I can work with you on that.
>
> Thanks and regards,
>
> Sebastian
>
> Sebastian Canevari
> Senior Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM
> 7100 N Hwy 161, Irving, TX - 75039
> "Las Colinas - LC2"
> Tel: [phone]
> e-mail: sebastc@...
>
>
>
> -----Original Message-----
> From: Sebastian Canevari
> Sent: Friday, August 28, 2009 4:36 PM
> To: 'Matthieu Patou'; Andrew Bartlett
> Cc: pfif@...; cifs-protocol@...
> Subject: RE: [cifs-protocol] How to determine if an account should use AES?
>
> Matthieu / Andrew,
>
> I'm attaching a revised version of [MS-KILE]section 3.1.5.4 where the KDC behavior is described for the cases in which the the msDS-SupportedEncryptionTypes is not populated.
>
> Upcoming versions of the document will reflect the changes with same or very similar wording.
>
> I'm still working in providing you a complete and accurate set of responses for your latest set of questions regarding this matter.
>
>
>
> Thanks and regards,
>
> Sebastian
>
>
> Sebastian Canevari
> Senior Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM 7100 N Hwy 161, Irving, TX - 75039 "Las Colinas - LC2"
> Tel: [phone]
> e-mail: sebastc@...
>
>
>
> -----Original Message-----
> From: Matthieu Patou [mailto:mat@...]
> Sent: Monday, August 24, 2009 5:22 PM
> To: Andrew Bartlett
> Cc: Sebastian Canevari; pfif@...; cifs-protocol@...; Interoperability Documentation Help
> Subject: Re: [cifs-protocol] How to determine if an account should use AES?
>
> Hello Sebastian,
>
> I'm coming back to you on this subject.
> Last week I made tests with one of the newsest version of samba4 which tries to pretend to be have a windows 2008 forest/domain and dc compatibility level.
>
> And I didn't noticed any request from a windows 2008 acting as a client of my S4 domain.
>
> It raise a few possibilities but two are most probable:
>
> 1) S4 is not behaving like windows 2008 enough so that client thinks that it is not a real windows 2008 and so it don't send this attibute.
> 2) This attribute is not sent by the client it's just the server that based on some algorithm (ie. if os.version>=6.0 and os.name contains "Windows" then set msDS-SupportedEncryptionType)
>
> Can you indicate us if one of the two possibilities are the right one.
> If not please indicate the correct one.
> If yes please do not forget for the case 1 to indicate what exactly trigger the sending of this attribute (or what block the transmission) or if it's case 2 then give us the good algorithm.
>
> In any case I can only reiterate the request of Andrew about pcap formatted  network  trace with packets which are significant (ie those holding this attribute).
>
> Best regards.
> Matthieu Patou.
>
> On 08/20/2009 02:16 AM, Andrew Bartlett wrote:
>> On Wed, 2009-08-19 at 09:41 -0700, Sebastian Canevari wrote:
>>> Hi Andrew,
>>>
>>> The msDS-SupportedEncryptionTypes attribute is populated at object creation time by the subjects that support the property.
>>
>> So it is modified over LDAP by the Windows Vista (for example) domain
>> member?
>>
>>> It is also updated whenever there's a change on the object's
>>> configuration that require an update of the property.
>>
>> So if the domain member upgrades, it is expected to reach out and
>> update this property using LDAP?
>>
>> Are there any ACL considerations to be aware of here?  Are there any
>> other restrictions on the values clients might populate here?
>>
>>> Meaning that when a subject changes the type of encryption it
>>> supports, it modifies this attribute to reflect the change.
>>
>> Any chance you can provide an annotated (ie, with a separate document
>> mentioning frame numbers) PCAP-formatted example network trace and
>> documentation references to support this?  I would really like to pin
>> this down firmly before the next alpha, now that I've turned on the
>> Windows 2008 functional level and therefore AES encryption in our DC.
>>
>> Thanks,
>>
>> Andrew Bartlett
>>
>>
>>
>> ----------------------------------------------------------------------
>> --
>>
>> _______________________________________________
>> cifs-protocol mailing list
>> cifs-protocol@...
>> https://lists.samba.org/mailman/listinfo/cifs-protocol
>
>

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

[Matthieu PATOU-2]

Sebastian,

I successfully tested the described behavior so you can firmly consider
my questions as correctly answered.

Regards.

Matthieu

On 08/31/2009 07:04 PM, Matthieu Patou wrote:

> Hi Sebastian,
> As for myself you provided a lot a good explanations that fulfills my
> questions. I will try to do force a supported encoding !=0 and !=0x1f
> (ie. 0x0f) in samba4 in order to see if I can trigger the request for
> changing the value of msDS-SupportedEncryptionTypes from the client.
>
> In any case thank you because for things looks much more clear !
>
> Matthieu.
>
>
>
> 08/31/2009 06:43 PM, Sebastian Canevari wrote:
>> Hi Andrew / Matthieu,
>>
>>
>> I'm answering all the questions that were still pending (inline):
>>
>>
>> . So it is modified over LDAP by the Windows Vista (for example)
>> domain member?
>> Yes, whenever the Kerberos encryption types supported by the Kerberos
>> server (Windows Vista, Windows Server 2008, Windows 7, Windows Server
>> 2008 R2) are changed, Windows will use LDAP to update the
>> msDS-SupportedEncryptionTypes.
>>
>>
>> . So if the domain member upgrades, it is expected to reach out and
>> update this property using LDAP?
>> No, this attribute is only updated when different from the
>> configuration on the Kerberos server. Now that said, in Windows 7 and
>> Windows Server 2008 R2 we disable DES by default, so the attribute is
>> updated.
>>
>>
>> . Are there any ACL considerations to be aware of here?
>> Yes, the ACL of the msDS-SupportedEncryptionTypes attribute.
>>
>>
>> . Are there any other restrictions on the values clients might
>> populate here?
>> As specified in [MS-KILE] Section 3.1.5.4, KILE only supports the
>> first 5 bits and ignores all others. We might be using the other bits
>> as more crypto is supported in the RFC.
>>
>>
>> . I would really like to pin this down firmly before the next alpha,
>> now that I've turned on the Windows 2008 functional level and
>> therefore AES encryption in our DC.
>> This would not impact the value. The value is what the Kerberos server
>> supports. DFL will not change the value.
>>
>>
>> . It raise a few possibilities but two are most probable:
>> 1) S4 is not behaving like windows 2008 enough so that client thinks
>> that it is not a real windows 2008 and so it don't send this attibute.
>> 2) This attribute is not sent by the client it's just the server that
>> based on some algorithm (ie. if os.version>=6.0 and os.name contains
>> "Windows" then set msDS-SupportedEncryptionType)
>>
>> Guessing that your DC is either not returning SupportedEncTypes
>> ([MS-NRPC] Section 2.2.1.3.11) when system calls
>> NetrLogonGetDomainInfo() ([MS-NRPC] Section 3.5.4.3.9) or that the
>> value in msDS-SupportedEncryptionType is correct based on what you are
>> returning.
>> If the server does not return the value after the call, then the
>> client OS assumes that the attribute is not present on AD (unsupported
>> or legacy) thus it does not try to populate it.
>> If the value returned is fine, so the client does not need to update.
>>
>>
>> . Any chance you can provide an annotated (ie, with a separate
>> document mentioning frame numbers) PCAP-formatted example network
>> trace and documentation references to support this?
>> If after these clarifications you still need a network trace, I can
>> work with you on that.
>>
>> Thanks and regards,
>>
>> Sebastian
>>
>> Sebastian Canevari
>> Senior Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM
>> 7100 N Hwy 161, Irving, TX - 75039
>> "Las Colinas - LC2"
>> Tel: [phone]
>> e-mail: sebastc@...
>>
>>
>>
>> -----Original Message-----
>> From: Sebastian Canevari
>> Sent: Friday, August 28, 2009 4:36 PM
>> To: 'Matthieu Patou'; Andrew Bartlett
>> Cc: pfif@...; cifs-protocol@...
>> Subject: RE: [cifs-protocol] How to determine if an account should use
>> AES?
>>
>> Matthieu / Andrew,
>>
>> I'm attaching a revised version of [MS-KILE]section 3.1.5.4 where the
>> KDC behavior is described for the cases in which the the
>> msDS-SupportedEncryptionTypes is not populated.
>>
>> Upcoming versions of the document will reflect the changes with same
>> or very similar wording.
>>
>> I'm still working in providing you a complete and accurate set of
>> responses for your latest set of questions regarding this matter.
>>
>>
>>
>> Thanks and regards,
>>
>> Sebastian
>>
>>
>> Sebastian Canevari
>> Senior Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM 7100 N
>> Hwy 161, Irving, TX - 75039 "Las Colinas - LC2"
>> Tel: [phone]
>> e-mail: sebastc@...
>>
>>
>>
>> -----Original Message-----
>> From: Matthieu Patou [mailto:mat@...]
>> Sent: Monday, August 24, 2009 5:22 PM
>> To: Andrew Bartlett
>> Cc: Sebastian Canevari; pfif@...; cifs-protocol@...;
>> Interoperability Documentation Help
>> Subject: Re: [cifs-protocol] How to determine if an account should use
>> AES?
>>
>> Hello Sebastian,
>>
>> I'm coming back to you on this subject.
>> Last week I made tests with one of the newsest version of samba4 which
>> tries to pretend to be have a windows 2008 forest/domain and dc
>> compatibility level.
>>
>> And I didn't noticed any request from a windows 2008 acting as a
>> client of my S4 domain.
>>
>> It raise a few possibilities but two are most probable:
>>
>> 1) S4 is not behaving like windows 2008 enough so that client thinks
>> that it is not a real windows 2008 and so it don't send this attibute.
>> 2) This attribute is not sent by the client it's just the server that
>> based on some algorithm (ie. if os.version>=6.0 and os.name contains
>> "Windows" then set msDS-SupportedEncryptionType)
>>
>> Can you indicate us if one of the two possibilities are the right one.
>> If not please indicate the correct one.
>> If yes please do not forget for the case 1 to indicate what exactly
>> trigger the sending of this attribute (or what block the transmission)
>> or if it's case 2 then give us the good algorithm.
>>
>> In any case I can only reiterate the request of Andrew about pcap
>> formatted network trace with packets which are significant (ie those
>> holding this attribute).
>>
>> Best regards.
>> Matthieu Patou.
>>
>> On 08/20/2009 02:16 AM, Andrew Bartlett wrote:
>>> On Wed, 2009-08-19 at 09:41 -0700, Sebastian Canevari wrote:
>>>> Hi Andrew,
>>>>
>>>> The msDS-SupportedEncryptionTypes attribute is populated at object
>>>> creation time by the subjects that support the property.
>>>
>>> So it is modified over LDAP by the Windows Vista (for example) domain
>>> member?
>>>
>>>> It is also updated whenever there's a change on the object's
>>>> configuration that require an update of the property.
>>>
>>> So if the domain member upgrades, it is expected to reach out and
>>> update this property using LDAP?
>>>
>>> Are there any ACL considerations to be aware of here? Are there any
>>> other restrictions on the values clients might populate here?
>>>
>>>> Meaning that when a subject changes the type of encryption it
>>>> supports, it modifies this attribute to reflect the change.
>>>
>>> Any chance you can provide an annotated (ie, with a separate document
>>> mentioning frame numbers) PCAP-formatted example network trace and
>>> documentation references to support this? I would really like to pin
>>> this down firmly before the next alpha, now that I've turned on the
>>> Windows 2008 functional level and therefore AES encryption in our DC.
>>>
>>> Thanks,
>>>
>>> Andrew Bartlett
>>>
>>>
>>>
>>> ----------------------------------------------------------------------
>>> --
>>>
>>> _______________________________________________
>>> cifs-protocol mailing list
>>> cifs-protocol@...
>>> https://lists.samba.org/mailman/listinfo/cifs-protocol
>>
>>
>
> _______________________________________________
> cifs-protocol mailing list
> cifs-protocol@...
> https://lists.samba.org/mailman/listinfo/cifs-protocol

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

[Sebastian Canevari]

Hi Matthieu,

Thank you very much for the follow up!

I'm glad that we could help.

Please let us know if we can be of any help.

Thanks and regards,

Sebastian



Sebastian Canevari
Senior Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM
7100 N Hwy 161, Irving, TX - 75039
"Las Colinas - LC2"
Tel: [phone]
e-mail: sebastc@...



-----Original Message-----
From: Matthieu Patou [mailto:mat@...]
Sent: Tuesday, September 01, 2009 7:01 AM
To: Sebastian Canevari
Cc: pfif@...; cifs-protocol@...; Andrew Bartlett
Subject: Re: [cifs-protocol] How to determine if an account should use AES?

Sebastian,

I successfully tested the described behavior so you can firmly consider
my questions as correctly answered.

Regards.

Matthieu

On 08/31/2009 07:04 PM, Matthieu Patou wrote:

> Hi Sebastian,
> As for myself you provided a lot a good explanations that fulfills my
> questions. I will try to do force a supported encoding !=0 and !=0x1f
> (ie. 0x0f) in samba4 in order to see if I can trigger the request for
> changing the value of msDS-SupportedEncryptionTypes from the client.
>
> In any case thank you because for things looks much more clear !
>
> Matthieu.
>
>
>
> 08/31/2009 06:43 PM, Sebastian Canevari wrote:
>> Hi Andrew / Matthieu,
>>
>>
>> I'm answering all the questions that were still pending (inline):
>>
>>
>> . So it is modified over LDAP by the Windows Vista (for example)
>> domain member?
>> Yes, whenever the Kerberos encryption types supported by the Kerberos
>> server (Windows Vista, Windows Server 2008, Windows 7, Windows Server
>> 2008 R2) are changed, Windows will use LDAP to update the
>> msDS-SupportedEncryptionTypes.
>>
>>
>> . So if the domain member upgrades, it is expected to reach out and
>> update this property using LDAP?
>> No, this attribute is only updated when different from the
>> configuration on the Kerberos server. Now that said, in Windows 7 and
>> Windows Server 2008 R2 we disable DES by default, so the attribute is
>> updated.
>>
>>
>> . Are there any ACL considerations to be aware of here?
>> Yes, the ACL of the msDS-SupportedEncryptionTypes attribute.
>>
>>
>> . Are there any other restrictions on the values clients might
>> populate here?
>> As specified in [MS-KILE] Section 3.1.5.4, KILE only supports the
>> first 5 bits and ignores all others. We might be using the other bits
>> as more crypto is supported in the RFC.
>>
>>
>> . I would really like to pin this down firmly before the next alpha,
>> now that I've turned on the Windows 2008 functional level and
>> therefore AES encryption in our DC.
>> This would not impact the value. The value is what the Kerberos server
>> supports. DFL will not change the value.
>>
>>
>> . It raise a few possibilities but two are most probable:
>> 1) S4 is not behaving like windows 2008 enough so that client thinks
>> that it is not a real windows 2008 and so it don't send this attibute.
>> 2) This attribute is not sent by the client it's just the server that
>> based on some algorithm (ie. if os.version>=6.0 and os.name contains
>> "Windows" then set msDS-SupportedEncryptionType)
>>
>> Guessing that your DC is either not returning SupportedEncTypes
>> ([MS-NRPC] Section 2.2.1.3.11) when system calls
>> NetrLogonGetDomainInfo() ([MS-NRPC] Section 3.5.4.3.9) or that the
>> value in msDS-SupportedEncryptionType is correct based on what you are
>> returning.
>> If the server does not return the value after the call, then the
>> client OS assumes that the attribute is not present on AD (unsupported
>> or legacy) thus it does not try to populate it.
>> If the value returned is fine, so the client does not need to update.
>>
>>
>> . Any chance you can provide an annotated (ie, with a separate
>> document mentioning frame numbers) PCAP-formatted example network
>> trace and documentation references to support this?
>> If after these clarifications you still need a network trace, I can
>> work with you on that.
>>
>> Thanks and regards,
>>
>> Sebastian
>>
>> Sebastian Canevari
>> Senior Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM
>> 7100 N Hwy 161, Irving, TX - 75039
>> "Las Colinas - LC2"
>> Tel: [phone]
>> e-mail: sebastc@...
>>
>>
>>
>> -----Original Message-----
>> From: Sebastian Canevari
>> Sent: Friday, August 28, 2009 4:36 PM
>> To: 'Matthieu Patou'; Andrew Bartlett
>> Cc: pfif@...; cifs-protocol@...
>> Subject: RE: [cifs-protocol] How to determine if an account should use
>> AES?
>>
>> Matthieu / Andrew,
>>
>> I'm attaching a revised version of [MS-KILE]section 3.1.5.4 where the
>> KDC behavior is described for the cases in which the the
>> msDS-SupportedEncryptionTypes is not populated.
>>
>> Upcoming versions of the document will reflect the changes with same
>> or very similar wording.
>>
>> I'm still working in providing you a complete and accurate set of
>> responses for your latest set of questions regarding this matter.
>>
>>
>>
>> Thanks and regards,
>>
>> Sebastian
>>
>>
>> Sebastian Canevari
>> Senior Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM 7100 N
>> Hwy 161, Irving, TX - 75039 "Las Colinas - LC2"
>> Tel: [phone]
>> e-mail: sebastc@...
>>
>>
>>
>> -----Original Message-----
>> From: Matthieu Patou [mailto:mat@...]
>> Sent: Monday, August 24, 2009 5:22 PM
>> To: Andrew Bartlett
>> Cc: Sebastian Canevari; pfif@...; cifs-protocol@...;
>> Interoperability Documentation Help
>> Subject: Re: [cifs-protocol] How to determine if an account should use
>> AES?
>>
>> Hello Sebastian,
>>
>> I'm coming back to you on this subject.
>> Last week I made tests with one of the newsest version of samba4 which
>> tries to pretend to be have a windows 2008 forest/domain and dc
>> compatibility level.
>>
>> And I didn't noticed any request from a windows 2008 acting as a
>> client of my S4 domain.
>>
>> It raise a few possibilities but two are most probable:
>>
>> 1) S4 is not behaving like windows 2008 enough so that client thinks
>> that it is not a real windows 2008 and so it don't send this attibute.
>> 2) This attribute is not sent by the client it's just the server that
>> based on some algorithm (ie. if os.version>=6.0 and os.name contains
>> "Windows" then set msDS-SupportedEncryptionType)
>>
>> Can you indicate us if one of the two possibilities are the right one.
>> If not please indicate the correct one.
>> If yes please do not forget for the case 1 to indicate what exactly
>> trigger the sending of this attribute (or what block the transmission)
>> or if it's case 2 then give us the good algorithm.
>>
>> In any case I can only reiterate the request of Andrew about pcap
>> formatted network trace with packets which are significant (ie those
>> holding this attribute).
>>
>> Best regards.
>> Matthieu Patou.
>>
>> On 08/20/2009 02:16 AM, Andrew Bartlett wrote:
>>> On Wed, 2009-08-19 at 09:41 -0700, Sebastian Canevari wrote:
>>>> Hi Andrew,
>>>>
>>>> The msDS-SupportedEncryptionTypes attribute is populated at object
>>>> creation time by the subjects that support the property.
>>>
>>> So it is modified over LDAP by the Windows Vista (for example) domain
>>> member?
>>>
>>>> It is also updated whenever there's a change on the object's
>>>> configuration that require an update of the property.
>>>
>>> So if the domain member upgrades, it is expected to reach out and
>>> update this property using LDAP?
>>>
>>> Are there any ACL considerations to be aware of here? Are there any
>>> other restrictions on the values clients might populate here?
>>>
>>>> Meaning that when a subject changes the type of encryption it
>>>> supports, it modifies this attribute to reflect the change.
>>>
>>> Any chance you can provide an annotated (ie, with a separate document
>>> mentioning frame numbers) PCAP-formatted example network trace and
>>> documentation references to support this? I would really like to pin
>>> this down firmly before the next alpha, now that I've turned on the
>>> Windows 2008 functional level and therefore AES encryption in our DC.
>>>
>>> Thanks,
>>>
>>> Andrew Bartlett
>>>
>>>
>>>
>>> ----------------------------------------------------------------------
>>> --
>>>
>>> _______________________________________________
>>> cifs-protocol mailing list
>>> cifs-protocol@...
>>> https://lists.samba.org/mailman/listinfo/cifs-protocol
>>
>>
>
> _______________________________________________
> cifs-protocol mailing list
> cifs-protocol@...
> https://lists.samba.org/mailman/listinfo/cifs-protocol

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