arla-0.41 and support for Tiger

[Harald Barth]

The confusion springs often from the differnt ways you can obtain
your authentification for AFS.

1. klog and kalog

There are different versions with different feature sets of these
around but the most important with thsese is that they come with your
AFS distributions (convinient) but use kaserver or a krb4 server for
authentification. That is bad because kaserver is really bad and krb4
just a little bit better for you safety. If you use the kaserver you
don't use kerberos and don't need any kerberos authentification. If
you use v4 you need probably a minimal config in krb.conf. klog and
kalog put the authentification token into the kernel so that AFS can
use it. Your kaservers are found from CellServDB, your kerberos
servers from krb.conf.

2. Older kinit

Get you a kerberos v4 ticket. From that a token can be derived
and put into the kernel, either by kinit itself or another program.
For v4 you need a correct krb.conf.

3. Newer versions of (heimdal and maybe MIT) kinit.
   (kauth is another name for heimdal kinit)

Get you a kerberos v5 ticket (and maybe v4, too). From that a token
can be derived and put into the kernel, either by kinit itself or
another program. For v4 you need a working krb.conf, for v5 you need a
working krb5.conf. As newer kinit can take correct information from
DNS, it sometimes helps to DELETE krb5.conf. Typically the krb5.conf
shipped with many distros containing EXAMPLE.COM is only in the way
and should be nuked right away. As all other versions that the kerberos
v5 one are unsafe, I'll only describe this one in detail. Normally 
cellnames are written all lower case and realmnames are upper case.
However, in contrary to domain names, case does matter!

3a) After using kinit which uses krb5.conf and DNS to find your kerberos
server you get a ticket granting ticket:

$ /usr/heimdal-0.7.1/bin/klist 
Credentials cache: FILE:/tmp/krb5cc_22421
        Principal: haba at NADA.KTH.SE

  Issued           Expires          Principal
Jan  9 11:15:42  Jan  9 21:15:44  krbtgt/NADA.KTH.SE at NADA.KTH.SE

3b) With that you can get a service ticket for AFS from your AFS cell
or cells:

Jan  9 11:15:42  Jan  9 21:15:44  afs/pdc.kth.se at NADA.KTH.SE

(This is btw how it looks if your cellname != tolower(realmname)).
Mostly your kinit will be AFS-aware and fix this for you right away
after you punched your password. 

3c) It might be even so AFS aware that it can use that service key to
put a token into your kernel:

$ /usr/openafs/bin/tokens 

Tokens held by the Cache Manager:

User's (AFS ID 22421) tokens for afs at pdc.kth.se [Expires Jan  9 21:20]

And then everything is nice and fine. The interresting times
begin if one of these 3 steps is broken because of "some reason".
That can be broken configuration files, firewalls or that Linus
hinders us to put the tokens into the kernel ;-) To debug such
a situation you can use "kinit --no-afslog" for doing 3a)
and "afslog -c your-cellname" for doing 3b) and 3c). 

If you then finally have all authentification in place, you still
might be locked out if you have a firewall that does not let you
reach the right UDP ports of your DB servers (the ones that you
configure in DNS or in CellServDB) or a firewall that locks away
your fileservers (whose names you get from the DB servers).

As the kerberos code consist of a library which might or might not
be able to tell the correct error code to your application (kinit)
debugging is not allways easy.

4. krb524

I have deliberately lefy you services like 5-to-4 ticket "complete
makeover" as I don't know so much about it and it definitely confuses
things yet more. I see these as migration tools which should go away
as soon as possible. As AFS support v5 nowadays, I can't see any
reason for using 524 for AFS.

Are you still reading? If so and found any errors, please correct me.
Back to our setup "example" from the cern.ch cell in the CELL.CH realm:

jdurand wrote:
> The important line in krb5.conf is for the kdc: afsdb[1-3].cern.ch. Beware
> that inside cern, that file contains afsmisc[1-3].cern.ch instead. This is
> an error since these machines are behind a firewall.

I think the setup with different names from different places is
broken. As sysadmin you may get away with such a setup if you manage
to eliminate all config files and show different DNS views from the
in-and outside. But I still do not understand WHY.

> Recently debian dropped kerberos4. 

Finally!

> Before that, kinit alone was enough.
> With heimdal only, I did not find a way using kinit only to bypass the kalog 
> step (but I did not investigated very much...).

Your Heimdal version might support your setup, but the newer the Heimdal the
more unsecure old ways are disabled by config or compile time options. Really
can't say more without knowing all if version, compile and setup options.

Philippe Charpentier wrote:
> > As for what concerns afslog, I never managed to get a token with
> > it... probably as I have not understood how it should work.

Afslog is only useful if you allready have a kerberos ticket and want to
get a service ticket and then convert that into an afs token.

> > Most probably all this is due to my ignorance, but I certainly want
> > to remain ignorant of all the internals of AFS and Kerberos ;-)

You only can succeed with being that if both your sysadmins who setup
your AFS and Kerberos and your OS packager do a very good and synced
job.

> > If I use kinit without parameter, it complains that the default realm
> > is not defined in the configuration file, but I have set "cern.ch"
> > in /usr/arla/etc/ThisCell.

cell != realm.

Solution 1: Convince your sysadmins to put information in DNS and throw
away your config files.

Solution 2: Update your config files (at least ThisCell, CellServDB,
krb.conf, krb5.conf)

Harald.