[cifs-protocol] MS-LSAD 3.1.4.7.10-12 CreateTrustedDomain* question

[Hongwei Sun]

Matthias,

  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 3.1.1.5.2.2 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 7.1.6.9.7 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 3.1.1.5. 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.

Thanks!

Hongwei
  

-----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 3.1.4.7.10-12 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 
right?

Greets,
Matthias

Hongwei Sun wrote:
> Matthias,
>
>    As per the processing logic in 3.1.4.7.10 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 3.1.4.7.10-12 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
> "SYSTEM"?
>
> Since otherwise we run into the following constraint (taken from MS-ADTS
> 3.1.1.5.2.2):
>    
>> The structural objectClass is not a Local Security Authority
>> (LSA)-specific object class (section
>> 3.1.1.5.2.3). If it is, Add returns unwillingToPerform /
>> ERROR_DS_CANT_ADD_SYSTEM_ONLY.
>>      
> Thanks,
> Matthias Wallnöfer
>
>
>