[cifs-protocol] MS-LSAD 220.127.116.11.10-12 CreateTrustedDomain* question
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 18.104.22.168.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 22.214.171.124.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 126.96.36.199. 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.
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 188.8.131.52.10-12 CreateTrustedDomain* question
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:
> As per the processing logic in 184.108.40.206.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.
> -----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 220.127.116.11.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
> 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
>> 18.104.22.168.2.3). If it is, Add returns unwillingToPerform /
> Matthias Wallnöfer
More information about the cifs-protocol