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 [EMAIL PROTECTED] 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 '[EMAIL PROTECTED] 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.
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
