I actually found where at least some of the trust info is stored in LDAP.
They can be found in CN=SYSTEM,DC=yourdomain,DC=com
each one is listed as CN=(nameOfTrustedDomain) in the SYSTEM container.
andrew
--On Friday, June 24, 2005 2:41 PM -0500 Rick Kingslan <[EMAIL PROTECTED]>
wrote:
IIRC, the trusts are defined and stored as GUIDs. So, determining the
GUIDs are going to make it much easier to determine where the information
is stored. Let me poke around a bit.
As I mentioned yesterday - things are a bit frantic right now, so I might
not get to it today. But, soon the rush is going to be over and I'll be
able to get back to normal (well, some semblance of normal).
Rick
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Andrew Riley
Sent: Friday, June 24, 2005 1:28 PM
To: [email protected]
Subject: RE: [ActiveDir] Windows -> MIT Cross-realm auth to domains not in
the same dns hierarchy
I've gotten some new info on this topic. Apparently the default in MIT
Kerberos is the trust path will go from a 4th level domain (in our CASE
OTHER.AD.SCHOOL.EDU) to it's 3rd level parent (AD.SCHOOL.EDU) to it's 2nd
level parent and so on. If the trust is established, but the
REALMS/domains are not laid out in such an order, you have to manually
specify how to follow the trust path.
I'm curious if anyone knows where the trust information is stored in AD.
I've been using ADSIEdit.exe to look though the domain info, but I can't
seem to find any LDAP records of the trusts I've established.
andrew
--On Thursday, June 23, 2005 12:04 PM -0400 Andrew Riley
<[EMAIL PROTECTED]> wrote:
Sorry if I made this confusing, I tried to condense the problem as best I
could but it's a bit hard to wrap up in a neat little package.
The entire campus has a central BIND DNS, there is no use of individual
MS or BIND DNS for the individual domains. All domains manually register
their records.
All the hostnames, cnames, srv records etc. are resolvable by all of the
hosts involved.
When a client successfully authenticates their workstation gets a TGT
from the MIT KDC and then gets that gets passed along to AD.SCHOOL.EDU.
I'd assume that it must pass through their local domain controller on the
way. Once it is mapped to an account in AD.SCHOOL.EDU it also gets a TGT
from its local DC as well and any other tickets it is supposed to have.
Here are some events that are logged when I try a valid user/pass from
the MIT realm, that has not been mapped to a user account in
AD.SCHOOL.EDU.
When OTHER.AD.SCHOOL.EDU trusts AD.SCHOOL.EDU and I try to log on these
errors are logged
ON THE AD.SCHOOL.EDU domain controller
----------------------------------
Event Type: Failure Audit
Event Source: Security
Event Category: Account Logon
Event ID: 678
Date: 6/23/2005
Time: 11:47:44 AM
User: NT AUTHORITY\SYSTEM
Computer: EINS
Description:
Account Mapped for Logon.
Mapping Attempted By:
kdc
Client Name:
[EMAIL PROTECTED]
Mapped Name:
-----------------------------------
AND ALSO ON THE OTHER.AD.SCHOOL.EDU domain controller
------------------------------------
Event Type: Failure Audit
Event Source: Security
Event Category: Account Logon
Event ID: 678
Date: 6/23/2005
Time: 11:47:45 AM
User: NT AUTHORITY\SYSTEM
Computer: DREI
Description:
Account Mapped for Logon.
Mapping Attempted By:
kdc
Client Name:
[EMAIL PROTECTED]
Mapped Name:
-------------------------------------
This is fine. Since the user isn't mapped it tries to find the mapping
in AD.SCHOOL.EDU because that's the one that trusts the SCHOOL.EDU realm,
then it tries to find the mapping in OTHER.AD.SCHOOL.EDU. Since it
doesn't exist in either place, logon fails.
When a user is mapped properly and successfully authenticated an entry
like this is logged on the AD.SCHOOl.EDU domain controller
---------------------------------
Event Type: Success Audit
Event Source: Security
Event Category: Account Logon
Event ID: 678
Date: 6/23/2005
Time: 11:26:25 AM
User: AD\myuser
Computer: EINS
Description:
Account Mapped for Logon.
Mapping Attempted By:
kdc
Client Name:
[EMAIL PROTECTED]
Mapped Name:
myuser
---------------------------------
So when set up as OTHER.SCHOOL.EDU trusts AD.SCHOOL.EDU an event as shown
below is logged only on the workstation itself.
----------------------------------
Event Type: Failure Audit
Event Source: Security
Event Category: Account Logon
Event ID: 529
Date: 6/23/2005
Time: 11:26:25 AM
User: NT AUTHORITY\SYSTEM
Computer: myWorkstation
Description:
Logon Failure:
Reason: Unknown user name or bad password
User name: myuser
Domain: SCHOOL.EDU
Logon Type: 2
Logon Process: User32
Authentication Package: Negotiate
Workstation Name: myWorkstation
----------------------------------
When set up as OTHER.SCHOOL.EDU trusts AD.SCHOOL.EDU the user isn't being
passed to AD.SCHOOL.EDU for mapping. When the trust is from
OTHER.AD.SCHOOL.EDU to AD.SCHOOL.EDU the user is passed along to be
mapped from either the workstation or the OTHER.AD.SCHOOL.EDU domain.
andrew
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
