Andrew, 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 3.1.4.7.3 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 3.1.1.4: 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 3.1.1.4, (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: [EMAIL PROTECTED] 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:[EMAIL PROTECTED] Sent: Tuesday, August 12, 2008 10:51 PM To: Richard Guthrie Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] 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 3.1.4.7. 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 3.1.1.5 and MS-ADTS 7.1.6.7 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 7.1.6.7.10 and 7.1.6.7.11) 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. Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
