Jos Backus wrote:
Which in turn would disable Kerberos referrals.On Fri, Jun 27, 2008 at 01:57:37AM -0400, Jeffrey Altman wrote:There are several issues here. First, DNS TXT records are known to be insecure. Turning them on for use in realm resolution provides for convenience but at the risk that your clientsUnderstood.can be redirected to a realm that you do not control.Second, any domain_realm mapping for your domain .foo.com is going to override the use of DNS lookups. That is because local configuration data is considered to be trustworthyThat's something my patch changes as it performs the DNS lookup first (whenwhereas DNS lookups are not.configured).
There is a serious need for the zero configuration solution for Kerberos deployments. Of course, DNS is insecure so relying on DNS to boot strap your authentication system is undesirable. That is not to say it has not been used but only because there haveIn the case of two realms, PROD.FOO.COM and DEV.FOO.COM some of your hosts are in one and some are in the other. By default you want PROD.FOO.COM to be used. However, for specific hosts you want DEV.FOO.COM. Using the config file you wouldspecify [domain_realm] devhost1.foo.com = DEV.FOO.COM .foo.com = PROD.FOO.COMYup, tried that, works, but doesn't scale well.
been no other choices.
For referrals to work the user must have already obtained a TGT. If you are trying to decide which identity a user should obtain a credential for based upon the host that the user is going to communicate with, that is not something that will be solved by referrals. To be honest, I don't think it will be solved by domain_realm mappings whether storedIf you want to rely on DNS TXT records you have to make sure that there are no mappingsin the config file. Then you would create records for _kerberos.devhost1.foo.com IN TXT DEV.FOO.COM _kerberos.foo.com IN TXT PROD.FOO.COMOkay. We have the former (obviously) but not the latter. I can add that.Because DNS TXT records are insecure and there is a need to be able to provide for centralized configuration data Microsoft created the Kerberos referrals mechanism. Using referrals a client asks the KDC belonging to the TGT realm for a referral to the correct realm for the desired service principal. Referrals are used whenever there is not a local [domain_realm] mapping.So this implies two-way trust and communication, yes? I wonder if this willrequire network/ACL changes.
locally or in DNS.
The safe way to add DNS TXT records back into the equation would be to add the DNS TXTlookup after the referrals request fails.ISTR that's where krb5_get_fallback_host_realm() is called, from a comment in the code. Now it's clear why although I still don't quite grok the referral mechanism. Time to study the documentation. Thanks for the critique and helpful information, Jeffrey.
No problem.
smime.p7s
Description: S/MIME Cryptographic Signature
________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
