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.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol