> I just set up a coda server and tried to follow the recomendation found
> somewhere some time ago to use Kerberos authentication.  So I set up
> Kerberos5 ... for the first time, just like coda.  However I could not
> get the two to play together.  It is possible to do a kinit with my
> Kerberos account, but clog fails.

I don't know what is the reason of your problem, but anyway - the old
Kerberos support is limited. You might want to try the experimental
modular clog instead. It has a lot better support for several authentication
types.

A patch to be applied to cvs-2004-08-31 after ./configure is available at

http://www.konvalo.org/pub/patch.modular-clog.gz

of course you may try it on a later version.

Then you have to configure your server for Kerberos, putting
the following lines into the server.conf :

auth2=authd-auth2
auth2flags=
kerberos5servprinc=<srv-principal>      like codaauth/coda.realm.org
kerberos5realm=<kerberos5-realm>        like MYRLM.ORG

given that your coda server has access to a keytab, containing the
key to the "codaauth/my.realm.org_at_MYRLM.ORG" principal

Then you must have created users in Coda user database (say with pdbtool)
(but not valid passwords for them), and principals with the same name
in the Coda realm (say "testuser" in Coda and "testuser_at_MYRLM.ORG" in Kerberos)

When it is setup on the server side, and in Kerberos realm,
you can clog to your Coda realm with the Kerberos password.

Note that clog deliberately ignores /etc/krb5.conf on the client where
it is run (such file never can be relied upon to contain information
necessary for authentication against all possible Coda realms - there _are_
more than one Coda realm out there, and they do use more than one Kerberos
realm, and they can be used simultaneously from any client host :)

You may choose to supply all kerberos-related information on the command line,
like

clog -method kerberos5 testuser_at_coda.realm.org \
     -tokenserver srv1.coda.realm.org 370 \
     -krealm MYRLM.ORG \
     -kdc kdc1.myrlm.org \
     -servprinc codaauth/coda.realm.org

or you may setup the authentication options advertisement, letting
inetd on your authentication server (which in test setups usually is
the only one for the Coda realm) listen on tcp port 370 and cat out
a file in a suitable format, see the format description included in the patch.

telnet galio.konvalo.org 370

to see an example.

Then a simple clog testuser_at_coda.realm.org will work as supposed.

Note that

 - clog does not depend on kinit in any way, it does not use
   possibly existing Kerberos credentials cache[s]

 - pam_kcoda does not work with this clog, another trivial pam module should be
   hacked (passing the password over a pipe), but it is not yet done

> At this moment I am confused about the following:  If I use Kerberos
> authentication, do I have to create the users and groups in coda
> anyways? (pdbtool).

Sure, you have to. Kerberos just can check that somebody knows the password
for a principal xyz_at_ABC and a Coda authserver which trusts ABC Kerberos realm,
then issues tokens for xyz_at_coda.realm.org. The existence of xyz_at_coda.realm.org
has nothing to do with the existence of a Kerberos principal xyz_at_ABC, it is
just a primitive convention to map Kerberos principal names to Coda user names
directly 1-to-1, and a decision of Coda realm coda.realm.org to use services
of Kerberos realm ABC, say not those of DEF...

> Where to I set the password, in coda or in Kerberos?

For Kerberos authentication in Kerberos realm, for Coda password authentication,
in the Coda database. You may fetch tokens for a user in several ways, if
you with to setup it so, either via Coda password, or Kerberos password.

You make the choice either by supplying clog -method ... and all necessary
options, or if you have setup the server option advertisement on tcp port 370,
and listed several authorities and several methods, you can do

clog testuser/mycoda_at_coda.realm.org   (supply Coda password)
clog testuser/myabc_at_coda.realm.org    (supply password for
                                       testuser_at_ABC Kerberos realm)
clog testuser/mydef_at_coda.realm.org    (supply password for
                                       testuser_at_DEF Kerberos realm)

in that case authorities labels (mycoda,myabc,mydef) you choose yourself,
as the Coda realm administrator, and you decide which password checking
databases they are connected to.

Hope it will work for you. Don't hesitate to ask if you have more questions.

Regards,
--
Ivan