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/
