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