[cifs-protocol] Case created: [Pfif] Relationship between trusted domain object

[Bill Wesse]

Good afternoon Andrew. I have a partial response concerning the previous follow-up to your questions.

Please note that our investigations are not yet complete.

================================================================================
QUESTION:

What is the relationship between the trusted domain object under cn=users,... and that under cn=system,...?

The documentation in MS-ADTS 7.1.6 does not seen to cover the 'user'
type objects.  How and when are the passwords updated in both objects, and what linkage is made between the two objects (I would have expected a DN forward and reverse link, such as between the computer account and it's entry in cn=configuration)

I assume the one in cn=otherdomain1,cn=users, is the trust account, if your domain trusts 'otherdomain1'. It matches what samba3 has in it's passdb.

And cn=otherdomain2, cn=system, holds information you need to contact 'otherdomain2', which itself trusts your domain. It matches what samba3 has in the secrets.tdb.

This is what I always assumed, but then the cn=system account has (and the documentation goes to great lengths to explain) trustAuthIncoming and trustAuthOutgoing, which implies that the CN=system holds the full details - except then what is the cn=users account for?

--------------------------------------------------------------------------------
RESPONSE:

The relationship between the object of objectClass trustedDomain under CN=System and the object of objectClass user under CN=Users is an artifact of windows implementation of trusts and is not required to build an interoperable implementation of AD protocol families. All information that is required is already present on the object of objectClass trustedDomain under CN=System.

Windows implementation creates an object of objectClass user under CN=Users when a trust is created in addition to the object of objectClass trustedDomain under CN=System when the trust that is being created is incoming or both directions. The link between these two objects is through flatName attribute of the object of objectClass trustedDomain and samAccountName attribute of the object of objectClass user. The user's samAccountName attribute value is equal to the flatName attribute value + '$' of the trustedDomain.

For example, if O1 is the object of objectClass user and O2 is the object of objectClass trustedDomain of for a trust with domain whose netbios name is "example", then O2!flatName=example and  O1!samAccountName=example$.

When the trust direction is changed to outgoing only, the object of objectClass user is deleted. When the conceptual trust is deleted, then both objects are deleted. When the trustAuthIncoming attribute of object of type trustedDomain is changed, the password attribute family (including unicodePwd, dbcsPwd etc) of the object of objectClass user is also changed. However, update of the password or any other attribute of the object of objectClass user does not affect the object of objectClass trustedDomain.

Creation deletion and update of the object of objectClass user under CN=Users should not affect any interoperable protocol since all the necessary information is present on the object of objectClass trustedDomain under CN=System.

================================================================================
QUESTION:

Usage of the cn=users compatibility account (for downlevel trusts - a.k.a. NT4) is not noted in [MS-ADTS] and related documents.

Customer comment:
In the NETLOGON RPC protocol, ServerAuthenticate{,2,3} calls are used between trusted domains to establish a session for forwarding NTLM logon details.

Traditionally Samba has used the cn=users style / 'NT4 SAM' account to authenticate those inbound calls, just like all other trust accounts of this form.  The ACB_DOMTRUST SAMR flag is used to indicate accounts marked for this use, and the ServerAuthenticate3 call returns a RID.
Only the cn=users account has a RID.

Similarly, the MS-SNTP documentation refers to the 'RID' of a trusted domain.  Only the cn=users style account has this RID.

The MS-ADTS documentation makes no mention of the cn=users account, or how it is used.

--------------------------------------------------------------------------------
RESPONSE:

These are two valid points. We are looking into this. Our initial investigations showed that in the Microsoft implementation, the RID parameter returned from the Netlogon RPC is the RID of the object of objectClass user under CN=Users, which looks like it creates a dependency from object of objectClass trustedDomain under CN=System. Again our initial investigations showed that the RID parameter returned from Netlogon RPC does not have to be the RID of the object of objectClass user under CN=Users, but Netlogon RPC can return any value as long as that instance of Netlogon RPC is consistently returning the same value for the same secure channel.

In case we find that Netlogon RPC (or SNTP which depends on Netlogon to get this value) protocol has a dependency on the object of objectClass user under CN=Users, then we will update the relevant documentation to contain this information.

While we're investigating this issue, please use the windows implementation details provided in our response around linkage and how changes to one object affects other. Please also let us know if you have further questions.

--------------------------------------------------------------------------------

Regards,
Bill Wesse
MCSE / Escalation Engineer, US-CSS DSC PROTOCOL TEAM
8055 Microsoft Way
Charlotte, NC 28273
TEL:  +1(980) 776-8200
CELL: +1(704) 661-5438
FAX:  +1(704) 665-9606
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: Wednesday, August 27, 2008 1:43 AM
To: Bill Wesse
Cc: 'Stefan (metze) Metzmacher'; 'pfif at tridgell.net'
Subject: RE: Case created: [Pfif] Relationship between trusted domain object

On Thu, 2008-07-31 at 02:44 -0700, Bill Wesse wrote:
> Good morning again. I have taken ownership of this case, and will
> begin diligence this morning. I will update you as soon as I have some
> results.

What happened here?  I'm still rather hazy about how these two objects are linked.

Thanks,

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