Question about dns_lookup_realm and domain_realm

[Jeffrey Altman]

Jos Backus wrote:
> 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 clients
>> can be redirected to a realm that you do not control.
>  
> Understood.
>
>> 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 trustworthy
>> whereas DNS lookups are not.
>  
> That's something my patch changes as it performs the DNS lookup first (when
> configured).
Which in turn would disable Kerberos referrals.  
>
>> In 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 would
>> specify
>>
>> [domain_realm]
>>   devhost1.foo.com = DEV.FOO.COM
>>   .foo.com = PROD.FOO.COM
>
> Yup, tried that, works, but doesn't scale well.
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 have
been no other choices.
>
>> If you want to rely on DNS TXT records you have to make sure that there 
>> are no mappings
>> in 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.COM
>
> Okay. 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 will
> require network/ACL changes.
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 stored
locally or in DNS.
>
>> The safe way to add DNS TXT records back into the equation would be to 
>> add the DNS TXT
>> lookup 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/kerberos/attachments/20080627/3f0bc9d5/attachment.bin