[cifs-protocol] RE: 601628 RE: Mapping of MS-LSAD onto LDAP and DRS replications

Richard Guthrie rguthrie at microsoft.com
Tue Aug 26 18:11:54 GMT 2008


The link between G$$<trusted domain secrets> and trustAuthIncoming is that G$$<trusted domain secrets> is where the password for the trust was stored prior to active directory (I.E. NT4 for example).  If the trust is a trust between Active Directory enabled domains, the TDO object is where the trust passwords are stored.  I was mistaken when I spoke previously, stating that if you use the method LsarSetTrustedDomainInfo with InformationClass==TrustedPasswordInformation you would be able to modify trustAuthIncoming/ trustAuthOutgoing values.  You can only modify secret objects when you have InformationClass==TrustedPasswordInformation.  If you want to manipulate trustAuthIncoming/trustAuthOutgoing, you would need to set InformationClass = TrustedDomainInformationEx.  One point to note is that this method requires all the fields on the TDO passed in the TrustedDOmainInformation object be set properly.  The preferred means of modifying trustAuthIncoming/trustAuthOutgoing attributes on the TDO is through the use of LsarSetInformationTrustedDomain.

We have also made a modification to the MS-LSAD document for section to make the portion about TrustedPasswordInformation more clear that it refers to manipulation of a secret object.  Here is the revised text below with the reference to section

TrustedPasswordInformation: The server MUST verify that a trusted domain object with this SID exists in its policy database. If the object does not exist, the call MUST fail with STATUS_NO_SUCH_DOMAIN. Otherwise, the server MUST open the secret object, as defined in section, (or create a secret object, if one does not already exist) with "Name" set to "G$$<Trusted Domain Name>". The server MUST then set "Old Value" of the secret object to the "OldPassword" value in TrustedDomainInformation and set "New Value" of the secret object to the "Password" value in TrustedDomainInformation, similar to the processing when an LsarSetSecret request has been made.
Please let us know if you have any additional questions regarding this issue.

Richard Guthrie
Open Protocols Support Team
Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM
Tel: +1 (469) 775-7794
E-mail: rguthrie at microsoft.com
We're hiring http://members.microsoft.com/careers/search/details.aspx?JobID=A976CE32-B0B9-41E3-AF57-05A82B88383E&start=1&interval=10&SortCol=DatePosted

-----Original Message-----
From: Andrew Bartlett [mailto:abartlet at samba.org]
Sent: Tuesday, August 12, 2008 10:51 PM
To: Richard Guthrie
Cc: pfif at tridgell.net; cifs-protocol at samba.org
Subject: Re: 601628 RE: Mapping of MS-LSAD onto LDAP and DRS replications

On Tue, 2008-08-12 at 19:57 -0700, Richard Guthrie wrote:
> Andrew,
> We have completed our investigation of your request to include information linking the structures in the backing store for LSA with the MS-LSAD documents.  We have focused on the methods related to trusted domain operations.  The list of these methods can be found in section  To summarize, all of these methods deal with various aspects of manipulating/querying Trusted Domain Objects as defined in section 7.1.6 of the MS-ADTS documentation.

I think we still have a fair way to go with this, but that at least provides some of the missing links.

I'll note that on further reading, much of what I'm after can actually be answered pretty simply - if the table in MS-LSAD and MS-ADTS were combined.

But as to your response, as a start, I'll pick on:

> 3.)    InformationClass == TrustedPasswordInformation
> LSAPR_TRUSTED_PASSWORD_INFO (MS-LSAD section 2.2.46) This can be any
> of the stored secret objects on the TDO such as TrustAuthIncoming and
> TrustAuthOutgoing (MS-ADTS section and

So (and this in part relates to my broader question), what is the link between G$$<trustedomainname> secrets and trustAuthIncoming.  Please specify to the extent that given an LDAP database, possibly containing such trust objects, I could both set and query these values, with the this call and with the secrets calls.


Andrew Bartlett

Andrew Bartlett
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.

More information about the cifs-protocol mailing list