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

[Richard Guthrie]

Andrew,

Thanks for the follow up questions.  The use of secrets to store domain trust passwords was used prior to Windows 2000.  In Windows 2000 and beyond Trust Information such as Trust Passwords is stored in Active Directory on the TDO.  There is no mention of TrustAuthIncoming or TrustAuthOutgoing in the TrustedInformationPassword text in section 3.1.4.7.3 MS-LSAD because use of that flag for InformationClass performs work on secrets and not the TDO.

The user object under CN=Users is not influenced by calls to LsarSetTrustedDomainInfo when InformationClass==TrustedPasswordInformation. When InformationClass == TrustedDomainInformationEx and TrustDirection is set to Inbound, the value on the trustAuthIncoming attribute of the trust object is set on the user object's password attributes.

Let us know if you have additional questions

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 26, 2008 5:25 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-26 at 11:11 -0700, Richard Guthrie wrote:
> 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.

So, the secrets are another parallel to the trustAuthIncoming and trustAuthOutgoing?  The modified text does not reference trustAuthIncoming or trustAuthOutgoing, so I'm confused.

Also, how do the cn=users object is influenced by these calls?

Andrew Bartlett

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