Hello Jorge-Le�n, > 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/[EMAIL PROTECTED]" 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 "[EMAIL PROTECTED]" 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 [EMAIL PROTECTED] \ -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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] and a Coda authserver which trusts ABC Kerberos realm, then issues tokens for [EMAIL PROTECTED] The existence of [EMAIL PROTECTED] has nothing to do with the existence of a Kerberos principal [EMAIL PROTECTED], 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/[EMAIL PROTECTED] (supply Coda password) clog testuser/[EMAIL PROTECTED] (supply password for [EMAIL PROTECTED] Kerberos realm) clog testuser/[EMAIL PROTECTED] (supply password for [EMAIL PROTECTED] 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
