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:[EMAIL PROTECTED]
Sent: Wednesday, August 27, 2008 1:43 AM
To: Bill Wesse
Cc: 'Stefan (metze) Metzmacher'; '[EMAIL PROTECTED]'
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.
_______________________________________________
cifs-protocol mailing list
[email protected]
https://lists.samba.org/mailman/listinfo/cifs-protocol
