[OpenAFS] aklog vs referrals

[Simon Wilkinson]

Hi,

I thought I'd just document for posterity a problem we're seeing with  
MIT Kerberos 1.6 based platforms (Mac OS X Leopard, Fedora Core 8,  
recent Kerberos for Windows), and our somewhat unusual Kerberos  
setup, breaking aklog.

Our AFS cell ('inf.ed.ac.uk') uses the afs@INF.ED.AC.UK server  
principal. In addition to the INF.ED.AC.UK realm, the central  
University runs an Active Directory realm at ED.AC.UK. This  
combination causes aklog to break with some unusual error messages.  
What's going on is as follows...
   *) aklog attempts to get a ticket for the afs/inf.ed.ac.uk  
principal from the INF.ED.AC.UK KDCs
   *) The KDC returns a PRINCIPAL_UNKNOWN error, which is swallowed  
by the Kerberos library
   *) The Kerberos library looks at the Kerberos principal - goes  
'that looks like it's for machine 'inf', in the ed.ac.uk domain', and  
makes a request for afs/inf.ed.ac.uk to the ED.AC.UK realm
   *) These return a trust path error (KRB5_PLACEHOLD_28), which the  
Kerberos library kindly returns to aklog
   *) aklog doesn't understand the error, and so never falls back to  
trying to get a ticket for the 'afs@INF.ED.AC.UK principal.

You can work around this by including explicit domain_realm mappings  
in the krb5.conf of all of your clients - but this isn't acceptable  
for us, as we'd like our clients to require as little configuration  
as possible (having machines work 'out of the box' was a big win).  
So, in the interests of fixing this quickly, we're just going to add  
the afs/inf.ed.ac.uk principal, and get on with our lives.

It's unclear to me what the 'correct' solution to actually fix aklog  
is. It would appear that it can't influence the behaviour of the  
underlying Kerberos library - and having it simply fall back to the  
non-instance 'afs' principal whenever the first request fails is  
likely to be the wrong behaviour for a number of error codes.

Cheers,

Simon.