Kerberos, DNS and AAAA records

[Ken Raeburn]

On May 26, 2009, at 14:14, Ravi Channavajhala wrote:
> I was piqued by this and did some more extensive testing as how the
> best possible KDC candidate is determined out of a list.

In the MIT code, the answer is simple: It isn't.  Servers listed in  
the config file should be tried in order.  Servers listed in DNS SRV  
records should be tried in priority order, and randomly among servers  
with equal priority.

 From your earlier messages, I understand you're listing fully- 
qualified names with trailing dots in the config file now?  Then it  
should definitely try the first-listed server first.

Note that KRB5_CONFIG may provide a colon-separated list of config  
files, and the default set in the MIT code uses /etc/krb5.conf and  
then $sysconfdir/krb5.conf (where $sysconfdir is normally $prefix/etc  
but can be overridden at configure time).  Sun's changes may cause it  
to use something like /etc/krb5/krb5.conf instead.  So if you're  
experimenting with a test config file, make sure you're pointing the  
software at only that config file, and not accidentally including two  
versions of your config files and thus getting some hosts twice and in  
an unexpected order.

>  I placed the
> nearest KDC on the top of the list but for some strange reason a KDC
> located quite some distance away (alright in another continent) is the
> chosen one.

Sounds like something's amiss.

Run tcpdump or equivalent while this is happening; truss may help  
too.  If I recall correctly, name lookups are done in the order the  
names are seen in the config file too, so if they're showing up in a  
different order than you expect, that could be the source of the later  
problems.  (Local caching may make this hard to check.)

Try also listing just one KDC and see what that does.  If it still  
contacts the remote KDC instead, then for some reason the config file  
data just isn't being used.  (Realm case mismatch?  Wrong environment  
variable name for pointing to the test config file?  Bogus entries in / 
etc/hosts?  Check for simple mistakes like that.)

>  Ran the typical network diagnostics such as traceroute,
> ping etc to determine the round trip time and nearest KDC is really
> the quickest to respond to these type of test.  But, I cant generalize
> this for kerberos services or dont know the inner workings well,
> kerberos may have its unique way of determining the appropriate KDC
> not just predicated on round trip time or the number of hops.  So
> still not quite sure whats happening here.  FWIW, I'm using Solaris-10
> natively packaged Kerberos.

I know Sun has some local changes to the MIT code, but offhand I don't  
know if any of them would affect these areas.

> The slowness gets further aggravated when trying to change a passwd
> despite the explicit mention of admin_server and kpasswd_protocol is
> specified with SET_CHANGE to take care of non SEAMlessness of
> Windows/AD.
>
> I cant really seem to get around slow logins etc.  I will be glad to
> use any ideas here.

Getting it to pay attention to the config file is the first step....

-- 
Ken Raeburn / raeburn at mit.edu / no longer at MIT Kerberos Consortium