[cifs-protocol] How to determine if an account should use AES?

Tue Sep 1 07:40:26 MDT 2009

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: +1 469 775 7849
e-mail: sebastc at microsoft.com

-----Original Message-----
From: Matthieu Patou [mailto:mat at matws.net] 
Sent: Tuesday, September 01, 2009 7:01 AM
To: Sebastian Canevari
Cc: pfif at tridgell.net; cifs-protocol at samba.org; 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: +1 469 775 7849
>> e-mail: sebastc at microsoft.com
>>
>>
>>
>> -----Original Message-----
>> From: Sebastian Canevari
>> Sent: Friday, August 28, 2009 4:36 PM
>> To: 'Matthieu Patou'; Andrew Bartlett
>> Cc: pfif at tridgell.net; cifs-protocol at samba.org
>> 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: +1 469 775 7849
>> e-mail: sebastc at microsoft.com
>>
>>
>>
>> -----Original Message-----
>> From: Matthieu Patou [mailto:mat at matws.net]
>> Sent: Monday, August 24, 2009 5:22 PM
>> To: Andrew Bartlett
>> Cc: Sebastian Canevari; pfif at tridgell.net; cifs-protocol at samba.org;
>> 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 at cifs.org
>>> https://lists.samba.org/mailman/listinfo/cifs-protocol
>>
>>
>
> _______________________________________________
> cifs-protocol mailing list
> cifs-protocol at cifs.org
> https://lists.samba.org/mailman/listinfo/cifs-protocol