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:[email protected]]
Sent: Wednesday, November 17, 2010 4:30 PM
To: Hongwei Sun
Cc: [email protected]
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:[email protected]]
> Sent: Saturday, November 13, 2010 8:47 AM
> To: Interoperability Documentation Help
> Cc: [email protected]
> 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
>
>
>
_______________________________________________
cifs-protocol mailing list
[email protected]
https://lists.samba.org/mailman/listinfo/cifs-protocol
