[OpenAFS] aklog and aklog -524

[Russ Allbery]

vladimir konrad <v.konrad@lse.ac.uk> writes:

> thank you for your help,

>> Right.  It means that you're running krb524d to return K4 tickets to
>> applications that needed them, like AFS.  As of OpenAFS 1.2.8, the
>> server supports native K5 tickets, so you shouldn't have to do this
>> any longer. The aklog that ships with OpenAFS 1.4 is the new version
>> that does native K5 tickets by default (as opposed to the version
>> that shipped with sarge, which was from the Kerberos Migration Kit
>> and did 524 by default).

> also the debian people hinted that the pam-openafs-session module is
> going to be replaced with a new re-write...

Yeah, I'm working on that now; a 0.1 release is already out and a 0.2
release should be coming this week.

>> > when doing the same from etch with -524 option, the log shows only
>> > one request for principal:
>> > 	afs/domain-name@kerberos-realm
>> 
>> > there is only one principal in the kerberos database for afs:
>> > afs@kerberos-realm.
>> 
>> But the latter works anyway?

> yes it does, if i run aklog on etch with the -524 the aklog itself
> succeeds and /afs is accessible. if i do the same without the -524, the
> aklog on etch succeeds but the /afs in inaccessible...

Okay, my assumption then is that krb524d is doing the conversion between
the two different principal names somehow.  I'm not particularly familiar
with just how it works.

> it looks that this is exactly what is happening (wrong encryption type
> of the kerberos keys),

> kadmin(getprinc afs):

> Number of keys: 2
> Key: vno 9, Triple DES cbc mode with HMAC/sha1, no salt
> Key: vno 9, DES cbc mode with CRC-32, no salt

> one thing i do not understand is why it has 2 keys (and also do not
> understand what is the difference between a principal and a key (my gaps
> in understanding this are obvious) - are the keys used for encryption
> and the principal is basically a reference to what keys to use?

Yeah, that will do it.  And yes, the keys are essentially the password for
that principal.  By default, when you create a new Kerberos principal, it
will acquire keys for every encryption type supported by your KDC.  In
order to limit it to only des-cbc-crc:normal, you have to pass the -e
option to ank (or to kadmin when you start it).

If you're using Heimdal, you can just delete the other encryption type
(the triple DES one).  If you're using MIT Kerberos, you unfortunately
can't drop an encryption key without changing the password, which will
desync your KDC from the KeyFile on your AFS servers and hence has to be
done carefully.

>> You only have to have afs/cell-name@kerberos-realm if your cell name is
>> different than your Kerberos realm.  Otherwise, either will work,
>> although the latter form is recommended these days.

> afs-cell-name = lower_case(kerberos-realm).

Okay, then none of the krb.conf stuff matters for you.

>> /usr/share/doc/openafs-fileserver/README.servers.gz may be helpful,
>> although it's targetted at new installations rather than upgrades.

> i will read this asap.

> so, if i create kerberos 5 principal with the correct encryption key
> strength, do asetkey on servers, the native kerberos 5 authentication
> should work from all - woody, sarge and etch?

Assuming you're running MIT Kerberos, if you have a small cell and can
tolerate an outage, all you should have to do is change the key on your
existing afs principal in your KDC by regenerating it with ktadd and
specify that only des-cbc-crc:normal should be used (using the -e option
to ktadd).  Then run asetkey to load the resulting key into your KeyFile.
Note that you will have an AFS authentication outage from the point at
which you run ktadd to the point at which the new KeyFile is on all of
your servers; tokens acquired during that time period will probably be
discarded by the cache manager.

If you're instead running Heimdal, just delete the stray encryption key
and all should be fine.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>