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

Tue Sep 1 05:51:33 MDT 2009

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