[cifs-protocol] MS-LSAD CreateTrustedDomain* question

Hongwei Sun hongweis at microsoft.com
Mon Nov 22 17:11:00 MST 2010


  As I understand, LsarCreateTrustedDomainEx2 is a part of LSA remote interface that is implemented in lsasrv.dll.  It resides in the same lsass process as Active Directory server.  LDAP is another interface to the Active Directory server.    LsarCreateTrustedDomainEx2 will not access Active Directory data store through LDAP operation, although LDAP and LSA server may use the same set of API to access the Active Directory server internally.  Please see the following link for LSA architecture http://technet.microsoft.com/en-us/library/cc780332(WS.10).aspx .   Lsass process is running under SYSTEM account, so LSA RPC server and Active Directory server all run with the security context of SYSTEM.  

   The constraint in MS-ADTS means that the TDO cannot be added through LDAP interface, instead it can only be created through LSA Policy API.   This is also explained in MS-ADTS as follows:
   "Despite being replicated normally between peer DCs in a domain, the process of creating or manipulating TDOs is specifically restricted to the LSA Policy APIs, as detailed in [MS-LSAD] section Unlike other objects in the DS, TDOs may not be created or manipulated by client machines over the LDAPv3 transport."

  Let me know if you have more questions.



-----Original Message-----
From: Matthias Dieter Wallnöfer [mailto:mdw at samba.org] 
Sent: Wednesday, November 17, 2010 4:30 PM
To: Hongwei Sun
Cc: cifs-protocol at samba.org
Subject: Re: MS-LSAD CreateTrustedDomain* question

Hi Hongwei,

well, but LsarCreateTrustedDomainEx2 for sure internally performs an 
LDAP add operation. But using which user (the member of the "Domain 
Admins" group or SYSTEM)? And how is the mentioned constraint omitted?

My assumption is that the bind for the LDAP add operation is performed 
as "SYSTEM" and for "SYSTEM" the constraint simply doesn't apply. Am I 


Hongwei Sun wrote:
> Matthias,
>    As per the processing logic in in MS-LSAD,  the caller to LsarCreateTrustedDomainEx2 or similar functions has to be a member of the Domain Admins group to access the policy handle.  The requirement for the caller's control access right is also defined in the same section.   The constraint you mentioned in MS-ADTS is for LDAP Add operation.  The ERROR_DS_CANT_ADD_SYSTEM_ONLY means that it is not permitted to add the attribute which is owned by the system.
>    Please let me know if I understand your questions correctly and if you have more questions.
> Thanks!
> Hongwei
> -----Original Message-----
> From: Matthias Dieter Wallnöfer [mailto:mdw at samba.org]
> Sent: Saturday, November 13, 2010 8:47 AM
> To: Interoperability Documentation Help
> Cc: cifs-protocol at samba.org
> Subject: MS-LSAD CreateTrustedDomain* question
> Hi dochelp people,
> the calls "CreateTrustedDomain*" allow to create trusted domain objects.
> Now the question is: what AD security user is used to create them? It is
> Since otherwise we run into the following constraint (taken from MS-ADTS
>> The structural objectClass is not a Local Security Authority
>> (LSA)-specific object class (section
>> If it is, Add returns unwillingToPerform /
> Thanks,
> Matthias Wallnöfer

More information about the cifs-protocol mailing list