Hello!

The new one (0.3) is more conformant to PAM conventions than 0.2, hence
less sensitive to application [mis]behaviour.
I would recommend possible users to upgrade, as version 0.2 breaks with
some applications (not really its fault).

Version 0.3 should be used as follows (pathnames may vary) :
--------------------------------------------------------------------------
[auth required pam_krb5.so [ccache=SAFE require_keytab]]
auth optional pam_kcoda.so [kclog /usr/local/bin/kclog] [ignore_root]

[session optional pam_kcoda.so [cunlog /usr/local/bin/cunlog] [nocunlog]]
--------------------------------------------------------------------------

auth entry creates a coda token based on a kerberos tgt, that is there
must be a kerberos auth module before pam_kcoda.

session entry destroys the coda token on session close.

(session entry with "nocunlog" option is essentially a no-op)

Tested on Linux with pam_krb5 from www.nectar.com (be sure to supply
ccache=SAFE argument to pam_krb5, otherwise it needs a patch when used
with Linux glibc).

My hope is that the 0.3-module will be available on
http://www.coda.cs.cmu.edu/pub/coda/contrib/
otherwise mail me if you are using kerberized coda.

<emotions>
IMHO kerberos is a very convenient complement to Coda (and vice versa),
give it a try. At least you get one password database to support instead
of two - and no cleartext passwords. Some other cleartext things are still
there in Coda, but going to be fixed..? :)
</emotions>

Aghmmm, the hard part, a howto... The best I can suggest:
Search the web, become familiar with kerberos concepts,
setup a krb5 realm, create principals for users:
"<username>", and for the coda auth server: "host/<auth.server.domain.name>"
(or "coda/<auth.server.domain.name>" - check by running
grep SRV5PRINC coda-src/auth2/krbsupport.c),
compile Coda with kerberos support [and without Coda password auth],
create keytab for "{host|coda}/<auth.server.domain.name>" on the Coda auth
server, setup pam modules: pam_krb5 and pam_kcoda for all of your login
services like ssh, xdm and so on. Then it works.

I had to apply a patch to krbsupport.c (posted here), but there are
chances it would work for you without the patch.

Recommended: principals for all of client hosts: "host/<client.host.name>"
and corresponding keytabs on the clients, making krb5 authentication
reliable.

Regards,
--
Ivan