[OpenAFS-devel] 1.4.5 pre5 klog v5

Jason Edgecombe jason@rampaginggeek.com
Thu, 25 Oct 2007 18:34:19 -0400


Sean O'Malley wrote:
> I think it is a good idea given the new quickstart guide starting from
> krb5 is out. klog simplifies the ticket/token hoop jumping which tends to
> be hard to explain to people especially users and newbies unfamiliar with
> the concepts in both the user and security contexts. (There is a valid
> argument that people should understand it, but the reality is it isnt that
> easy to grasp for some people.)
>
> It also just happens to be one of the few things in life that is more
> secure and easier to use if you don't already have a complete kerberos
> environment.
>
> Last, it is a PITA to upgrade from krbv4 to krbv5 so anything we can do to
> keep people off krbv4 is going to help keep thinking AFS is just another
> PITA. Especially given the interoperability/support for afs krbv4 is
> dwindling as people are/have migrated to krbv5 already.
>
> As far as what breaks. I don't know. I have a feeling it might be
> more then just a few make files or configure scripts. :) If it is much
> beyond that, I probably shouldnt be the one looking at it. :)
>
> Sean

At UNC-Charlotte, we renamed the old klog and make a script named klog
that does kerberos 5 instead. That was straight forward.  The tricky
part was pagsh. I modified an existing script to port pagsh to kerberos
5. That also went well, but there are some gotchas:

1. You have to create a new kerberos ticket cache and set KRB5CCNAME
environment variable accordingly. NO big deal
2. You must run legacy pagsh to get a new AFS pag.

There are some interesting interactions between tickets & tokens. We use
an Oracle database with kerberos authentication for administrative data.
There are some system admin scripts that require an admin token, but my
normal kerberos ticket cache. For this purpose, I just run our krb5
pagsh script and change the KRB5CCNAME back to the old value. This is
required because our AFS administrative user, "admin," isn't known to
Oracle.

just another data point. We didn't want to have to retrain any users,
but home users must still run "kinit; aklog"

Jason