Hi Daniel,

On Fri, Mar 18, 2005 at 08:54:21AM -0500, Daniel Savard wrote:
> trying to clog I am getting the following messages:
> krb5.c: Server not found in Kerberos database while preparing AP_REQ
> Failed to get secret for somehost.mycorp.ca

> In my venus.conf I have the following lines:

the lines like below should be in server.conf, not venus.conf.

> realm="somehost.mycorp.ca"
> kerberos5service="host/%s"
> kerberos5realm=MYCORP.CA
> kerberos5kinit="kinit"
> 
> What am I missing?

You need to configure the server to use a certain Kerberos realm,
it implies creating a server principal in that Kerberos realm.
Is your auth2 daemon running on the host "somehost.mycorp.ca"?
Then the principal you need is "host/somehost.mycorp.ca".

You have to create a suitable krb5 config file (which points out the right
kdcs with right options) and give the config and the keytab file
for "host/somehost.mycorp.ca" to the auth2 daemon.
You can do it best by setting KRB5_CONFIG and KRB5_KTNAME to point
to the files, in your startup script for auth2.
[Another (though rather confusing) option is to put these
files with their "default" names in /etc - the historical practice
in Kerberos administration, which is quite misleading.]

Then for each user going to use kerberos authentication for Coda access,
create a Coda user with a suitable name, via pdbtool,
and a Kerberos principal with the same name.

Then I'd strongly urge you to switch to the modular clog
on the client side (using the client from konvalo.org).
[If you don't, you might get it to work, but I can not help you]

You may test the setup with the following command (if you have
a user name "testuser" and if one of the KDCs of the Kerberos realm is
kdc1.mycorp.ca)

clog -method kerberos5 testuser_at_somehost.mycorp.ca \
     -tokenserver somehost.mycorp.ca 370 \
     -krealm MYCORP.CA \
     -kdc kdc1.mycorp.ca \
     -servprinc host/somehost.mycorp.ca \
# possibly optional variations of:
     -withaddr no \
     -proxiable yes

When it works, you may create a file on the server (say /vice/auth2/info)
like that:
-------------------------------------------------------------------------
version = 3
authorities {
# the following name you choose yourself
  MYCORP {
    methods {
# the following name you choose yourself
      krb5 {
        authmethod = kerberos5
        methodopts {
          krb5realm = MYCORP.CA
          krb5kdcs {
# you may need to list the KDCs here if the Kerberos realm does not advertise
# them via DNS, like
#            kdc1.mycorp.ca
#            kdc2.mycorp.ca
          }
          krb5options {
            withaddrs = no
            proxiable = yes
          }
          krb5service {
            host/somehost.mycorp.ca
          }
          tokensrvs {
            somehost.mycorp.ca 370
          }
        }
      }
    }
  }
}
-------------------------------------------------------------------------

and publish it with a line in inetd.conf like
-------------------------------------------------------------------------
codaauth2      stream  tcp     nowait  root    /bin/cat cat /vice/auth2/info
-------------------------------------------------------------------------

And then automagically

$ clog testuser_at_somehost.mycorp.ca
Password for testuser/MYCORP-krb5_at_somehost.mycorp.ca: [type krb password]
$ [done]

A user can even create $HOME/.codafs/clog/pref as follows:
-------------------------------------------------------------------------
version = 4
profiles {
# a profile is a collection of identities to obtain credentials for,
# choosable via "clog -p <profile>"
# the following name you choose yourself
  default {
    desc = Default profile
    identities {
# the following name you choose yourself
      mycorp {
        desc = My main identity
        identity = testuser_at_somehost.mycorp.ca
      }
    }
  }
}
-------------------------------------------------------------------------

then it becomes even more easy:

$ clog
Password for testuser/MYCORP-krb5_at_somehost.mycorp.ca: 
$

Note that you don't have to prepare anything as root on any client.
Note also that Coda authentication uses Kerberos protocols and servers,
but not the Kerberos credentials cache - that is, has nothing to do with
"kinit" or alike that the users may [have] run.

If you really want Coda and Kerberos credentials to depend on each other,
you have an option of using kerberos5 gss api authentication.
Then you would need to recompile your server with the corresponding patches.
Configuration of the server is very similar, no changes on the clients at all,
and users will be able to get Coda tokens based on an existing tgt.

Hope it helps,
--
Ivan