RE: [ActiveDir] Windows -> MIT Cross-realm auth to domains not in the same dns hierarchy
This looks promising. I'll give a call to Microsoft on Monday and see if this hotfix helps. andrew --On Saturday, June 25, 2005 4:45 AM +0300 Guy Teverovsky <[EMAIL PROTECTED]> wrote: The preceding solution works great, but I've found that if we establish a trust to a domain such as DOMAIN.SCHOOL.EDU (not in the same DNS hierarchy as AD.SCHOOL.EDU) then user logons fail. [Guy] There is a similar bug when changing passwords over cross forest trust when the UPN suffix of the account you logon with to trusting forest is different from the trusted forest's DNS name. In this case the DC resolves the domain to \\ i.e.: [EMAIL PROTECTED] is AD account in internal.local forest and logs on to other.local forest over cross-forest transitive trust. When trying to change password (when logged on with UPN), the target domain is resolved to COMPANY and not INTERNAL (or internal.local) There is a hotfix that you might want to try (it addresses the way the domains are located when using UPN - might also resolve the MIT Kerb issue): http://support.microsoft.com/?kbid=890953 Also try to logon from W2K3 box in OTHER.AD.SCHOOL.EDU domain with MIT Kerberos principal as it is not experiencing the above behavior. Guy 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/
RE: [ActiveDir] Windows -> MIT Cross-realm auth to domains not in the same dns hierarchy
> The preceding solution works great, but I've found that if we establish a > trust to a domain such as DOMAIN.SCHOOL.EDU (not in the same DNS hierarchy > as AD.SCHOOL.EDU) then user logons fail. [Guy] There is a similar bug when changing passwords over cross forest trust when the UPN suffix of the account you logon with to trusting forest is different from the trusted forest's DNS name. In this case the DC resolves the domain to \\ i.e.: [EMAIL PROTECTED] is AD account in internal.local forest and logs on to other.local forest over cross-forest transitive trust. When trying to change password (when logged on with UPN), the target domain is resolved to COMPANY and not INTERNAL (or internal.local) There is a hotfix that you might want to try (it addresses the way the domains are located when using UPN - might also resolve the MIT Kerb issue): http://support.microsoft.com/?kbid=890953 Also try to logon from W2K3 box in OTHER.AD.SCHOOL.EDU domain with MIT Kerberos principal as it is not experiencing the above behavior. Guy 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/
RE: [ActiveDir] Windows -> MIT Cross-realm auth to domains not in the same dns hierarchy
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: ActiveDir@mail.activedir.org 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
RE: [ActiveDir] Windows -> MIT Cross-realm auth to domains not in the same dns hierarchy
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: ActiveDir@mail.activedir.org 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
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/
RE: [ActiveDir] Windows -> MIT Cross-realm auth to domains not in the same dns hierarchy
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/
RE: [ActiveDir] Windows -> MIT Cross-realm auth to domains not in the same dns hierarchy
True, the forest/domain reference does assume different zones. So, at least at this point my first path of inquiry is along the lines of DNS. You've determined that all authenticating elements in non-authenticating domains can be resolved by name from a client that is experiencing problems? I'm to some degree very interested in the DNS for the Windows domains. Are those, too, on BIND? If so, do they have their own zones for AD.SCHOOL.EDU, etc? I'm concerned about the SRV records that the clients need. It appears to me that the clients are finding them, but I'm not clear where they are and how they are being found. Clearly, we need to have a KDC in each Kerberos authenticating domain or realm to be responsible for the authentication in that 'area'. Do the clients know who the authenticating mechanism is? For Win2k3, the SRV records are going to handle this through the _kerberos record, which is really a CNAME (with a few extra, but important elements) to each DC. Of course, the problem could certainly be with the actual Kerberos elements themselves. They may not understand who is communicating to them, the key material being passed may not be correct, or any multitude of other small problems. Look at this, if you haven't. Even though it's for Windows 2000, it still applies. I'd also be interested in seeing logging or programmatic output from the Windows as well as the Realm side. http://www.microsoft.com/windows2000/techinfo/planning/security/kerbsteps.as p Rick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Riley Sent: Wednesday, June 22, 2005 11:49 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Windows -> MIT Cross-realm auth to domains not in the same dns hierarchy The DNS is BIND. And the there is only one DNS zone for this scenario in BIND, SCHOOL.EDU. All individual domains manually register the appropriate records from netlogon.dns. I guess that the different forests/domains might assume that they are not in the same zone but I've never really run a full fledged MS DNS service before. The problem seems to be solely that if the disparate domains are not arranged with the trusting domains at least one level further from the root of the DNS than the trusted domain, authentication fails.So it has to be DOMAIN.AD.SCHOOL.EDU trusts AD.SCHOOL.EDU not DOMAIN.SCHOOL.EDU trusts AD.SCHOOL.EDU. The only thing I can figure is that somehow the authentication path for a user principal such as [EMAIL PROTECTED] tries to walk a path that hierarchically takes it closer to SCHOOL.EDU from whatever domain it's in. I thought it might be similar to how the default for unqualified hostname resolution in windows is to "Append parent suffixes of the primary DNS suffix". So if the trusted domain doesn't happen to be in parent suffix it never looks there. But that's just a guess. andrew --On Wednesday, June 22, 2005 11:04 PM -0500 Rick Kingslan <[EMAIL PROTECTED]> wrote: > Andrew, > > Really interesting problem that you're experiencing here. I can't say > that I have seen this, but I would say in my experience I've worked with > a few multi-tree and multi-forest scenarios. Both the multi-tree and > forest would naturally use a different DNS namespace for each tree or > forest. > > I don't see this behavior, so it is concerning. You note that this is > Windows Server 2003. Is there anything that you can detail about the DNS > configuration? Being a Realm 'root', is the DNS on BIND? (Not that it's > a bad thing...) > > How do the clients find the DNS that is authoritative for a given domain, > (standard forwarding, conditional, stub zones) and where are the glue > records for the specific cross-domain resolution (stub zones or > secondaries)? > > If this was Windows 2000, I'd be more apt to be asking questions about the > configuration of the trusts - are they set as transitive for the Realm > Trusts? On and on and so forth... 2K3 seems to have resolved much of that > issue. > > > > Rick > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Riley > Sent: Wednesday, June 22, 2005 4:06 PM > To: ActiveDir@mail.activedir.org > Subject: [ActiveDir] Windows -> MIT Cross-realm auth to domains not in the > same dns hierarchy > > A few months ago I started aproject to allow a Windows domain to trust > another windows domain that trusts an MIT Kerberos Realm for user logons. > > An example of this setup would be > > SCHOOL.EDU <- our MIT Realm > AD.SCHOOL.EDU <- the Windows domain that trusts the MIT Realm > OTHER.AD.SCHOOL.EDU <- a trusting windows domain > > All of the Windows servers are Window
RE: [ActiveDir] Windows -> MIT Cross-realm auth to domains not in the same dns hierarchy
The DNS is BIND. And the there is only one DNS zone for this scenario in BIND, SCHOOL.EDU. All individual domains manually register the appropriate records from netlogon.dns. I guess that the different forests/domains might assume that they are not in the same zone but I've never really run a full fledged MS DNS service before. The problem seems to be solely that if the disparate domains are not arranged with the trusting domains at least one level further from the root of the DNS than the trusted domain, authentication fails.So it has to be DOMAIN.AD.SCHOOL.EDU trusts AD.SCHOOL.EDU not DOMAIN.SCHOOL.EDU trusts AD.SCHOOL.EDU. The only thing I can figure is that somehow the authentication path for a user principal such as [EMAIL PROTECTED] tries to walk a path that hierarchically takes it closer to SCHOOL.EDU from whatever domain it's in. I thought it might be similar to how the default for unqualified hostname resolution in windows is to "Append parent suffixes of the primary DNS suffix". So if the trusted domain doesn't happen to be in parent suffix it never looks there. But that's just a guess. andrew --On Wednesday, June 22, 2005 11:04 PM -0500 Rick Kingslan <[EMAIL PROTECTED]> wrote: Andrew, Really interesting problem that you're experiencing here. I can't say that I have seen this, but I would say in my experience I've worked with a few multi-tree and multi-forest scenarios. Both the multi-tree and forest would naturally use a different DNS namespace for each tree or forest. I don't see this behavior, so it is concerning. You note that this is Windows Server 2003. Is there anything that you can detail about the DNS configuration? Being a Realm 'root', is the DNS on BIND? (Not that it's a bad thing...) How do the clients find the DNS that is authoritative for a given domain, (standard forwarding, conditional, stub zones) and where are the glue records for the specific cross-domain resolution (stub zones or secondaries)? If this was Windows 2000, I'd be more apt to be asking questions about the configuration of the trusts - are they set as transitive for the Realm Trusts? On and on and so forth... 2K3 seems to have resolved much of that issue. Rick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Riley Sent: Wednesday, June 22, 2005 4:06 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Windows -> MIT Cross-realm auth to domains not in the same dns hierarchy A few months ago I started aproject to allow a Windows domain to trust another windows domain that trusts an MIT Kerberos Realm for user logons. An example of this setup would be SCHOOL.EDU <- our MIT Realm AD.SCHOOL.EDU <- the Windows domain that trusts the MIT Realm OTHER.AD.SCHOOL.EDU <- a trusting windows domain All of the Windows servers are Windows Server 2003. We have established a forest trust between the two Windows domains/forests, entered a new Domain Suffix in AD.SCHOOL.EDU for SCHOOL.EDU, established a REALM Trust between AD.SCHOOL.EDU and SCHOOL.EDU, used KSETUP or registry entries to add the references to the KDCs for SCHOOL.EDU on the workstations in OTHER.AD.UPENN.EDU. Additionally users in AD.SCHOOL.EDU have a name mapping to their MIT kerberos principal. In this setup, someone with a user account in AD.SCHOOL.EDU can walk up to a workstation in OTHER.AD.SCHOOL.EDU, and enter their MIT kerberos principal and password, and select SCHOOL.EDU(Kerberos Realm) from the "Log on to:" box and be authenticated as their user account in AD.SCHOOL.EDU. The preceding solution works great, but I've found that if we establish a trust to a domain such as DOMAIN.SCHOOL.EDU (not in the same DNS hierarchy as AD.SCHOOL.EDU) then user logons fail. I've gone as far as setting up 2 other domains in a different DNS hierarchy and then swapping the trust around between the 4 and it's definitely something to do with how the domains are arranged DNS-wise. None of them are in the same forests, so It seems like some parent DNS suffix fallback that's being applied, but I have no idea where to look. Any ideas? thanks 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/
RE: [ActiveDir] Windows -> MIT Cross-realm auth to domains not in the same dns hierarchy
Andrew, Really interesting problem that you're experiencing here. I can't say that I have seen this, but I would say in my experience I've worked with a few multi-tree and multi-forest scenarios. Both the multi-tree and forest would naturally use a different DNS namespace for each tree or forest. I don't see this behavior, so it is concerning. You note that this is Windows Server 2003. Is there anything that you can detail about the DNS configuration? Being a Realm 'root', is the DNS on BIND? (Not that it's a bad thing...) How do the clients find the DNS that is authoritative for a given domain, (standard forwarding, conditional, stub zones) and where are the glue records for the specific cross-domain resolution (stub zones or secondaries)? If this was Windows 2000, I'd be more apt to be asking questions about the configuration of the trusts - are they set as transitive for the Realm Trusts? On and on and so forth... 2K3 seems to have resolved much of that issue. Rick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Riley Sent: Wednesday, June 22, 2005 4:06 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Windows -> MIT Cross-realm auth to domains not in the same dns hierarchy A few months ago I started aproject to allow a Windows domain to trust another windows domain that trusts an MIT Kerberos Realm for user logons. An example of this setup would be SCHOOL.EDU <- our MIT Realm AD.SCHOOL.EDU <- the Windows domain that trusts the MIT Realm OTHER.AD.SCHOOL.EDU <- a trusting windows domain All of the Windows servers are Windows Server 2003. We have established a forest trust between the two Windows domains/forests, entered a new Domain Suffix in AD.SCHOOL.EDU for SCHOOL.EDU, established a REALM Trust between AD.SCHOOL.EDU and SCHOOL.EDU, used KSETUP or registry entries to add the references to the KDCs for SCHOOL.EDU on the workstations in OTHER.AD.UPENN.EDU. Additionally users in AD.SCHOOL.EDU have a name mapping to their MIT kerberos principal. In this setup, someone with a user account in AD.SCHOOL.EDU can walk up to a workstation in OTHER.AD.SCHOOL.EDU, and enter their MIT kerberos principal and password, and select SCHOOL.EDU(Kerberos Realm) from the "Log on to:" box and be authenticated as their user account in AD.SCHOOL.EDU. The preceding solution works great, but I've found that if we establish a trust to a domain such as DOMAIN.SCHOOL.EDU (not in the same DNS hierarchy as AD.SCHOOL.EDU) then user logons fail. I've gone as far as setting up 2 other domains in a different DNS hierarchy and then swapping the trust around between the 4 and it's definitely something to do with how the domains are arranged DNS-wise. None of them are in the same forests, so It seems like some parent DNS suffix fallback that's being applied, but I have no idea where to look. Any ideas? thanks 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/
