[cifs-protocol] RE: [Pfif] How are 'supported enc types' determined in trusts? - 600253

[Richard Guthrie]

Andrew/Stefan,

I have completed my research with regard to your question regarding what value LSA would return in the case that the domain functional level is set to 2003.  The value returned is dependent on the OS version of the domain controller responding to the query:

If the domain controller is a windows 2003 domain controller, the method will return STATUS_INVALID_PARAMETER

If the domain controller is a windows 2008 domain controller, the method will return whatever value is set on that attribute.  Before a 2008 server is added as a domain controller to a 2003 domain, the schema is required to be updated and adprep /domainprep has been run from a 2008 installation CD.  Because of this, the attribute will be present on the TDO but will have a value of zero.  This should not be any value other than zero until both sides of the trust are moved to a domain functional level of 2008 where all Domain Controllers were 2008 as well.  The administrator can then enable AES through Active Directory Domains and Trust.  If all encryption types are enabled, the value will be 31.

NOTE: This should not be confused with computer accounts as even with a functional level of 2003, computer accounts will updated their msds-supportedEncryptionTypes attribute to 31 when they are rebooted as part of establishing their secure channel with the domain controller.

Richard Guthrie
Open Protocols Support Team
Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM
Tel: +1 (469) 775-7794
E-mail: rguthrie at microsoft.com
We're hiring http://members.microsoft.com/careers/search/details.aspx?JobID=A976CE32-B0B9-41E3-AF57-05A82B88383E&start=1&interval=10&SortCol=DatePosted

-----Original Message-----
From: Andrew Bartlett [mailto:abartlet at samba.org]
Sent: Monday, September 08, 2008 5:39 PM
To: Stefan (metze) Metzmacher
Cc: Richard Guthrie; pfif at tridgell.net; cifs-protocol at samba.org
Subject: Re: [Pfif] How are 'supported enc types' determined in trusts? - 600253

On Mon, 2008-09-08 at 16:35 +0200, Stefan (metze) Metzmacher wrote:
> Richard Guthrie schrieb:
> > Andrew,
> >
> > If you have a windows 2008 server acting as a member server in a
> downlevel domain (for this discussion we will assume 2003 functional
> level), this attribute will only exist if you extend the schema to a
> level that is compatible with 2008 functional level.  This is a normal
> step as part of an upgrade from Windows 2000 -> 2003 or Windows 2003
> -> 2008.  The following kb article describes this process in more
> detail http://technet.microsoft.com/en-us/library/cc773360.aspx.
> >
> > It will show up in the schema for computer accounts as well as being
> an attribute on objects where objectClass == trustedDomain.  It does
> not matter if the domain controller is still Windows 2003, the
> computer account and TDO will have this attribute.  The value of this
> attribute will show up as 'Not Set' in a tool such as ADSIEdit (see
> attached msds-SupportedEncryptionTypes.zip).  This is the same as
> saying the attribute is null.  It will not be in use until the domain
> functional level is set to 2008.  Setting the functional level to 2008
> requires that all the domain controllers be upgraded to Windows Server
> 2008.  Schema version can be set independently of the functional level
> to facilitate seamless upgrade scenarios.

So, what is the value returned over LSA in this case?

> > As to your second question, this attribute value is not dependent on
> trust type/attribute flags. It also will not have a value unless
> someone explicitly sets it.  In the case of computer accounts this
> attribute is set by netlogon during secure channel initiation.
>
> Can you explain that process a bit further, please?

Indeed.  I didn't actually ask about computer account enctype negotiation, as you raise it, this is an area I do need clarified.

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