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

[Andrew Bartlett]

(CC'ed to CIFS protocol)
On Wed, 2008-08-27 at 10:01 -0700, Bill Wesse wrote:
> 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.

I don't believe this is the case.  

> 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.

This isn't true, as far as see it, per the next answer.  Remember when
answering these questions, that we may be in replication with an AD
server. 

> ================================================================================
> 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.

It would have to be the same RID that a windows server would return,
based on the same replicated data set.  It also must be unique in the
set of RIDs otherwise populated from this (objects of objectclass=user)
source. 

> 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.

Thanks.

> 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.

Thankyou for the response.  It took a while, but we seem to have got
there.  We seem to have lost the cifs-protocol CC again - could you
perhaps post this excellent summary to that list?

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/cifs-protocol/attachments/20080828/a2f6e921/attachment.bin