Hello Andrew,

On Tue, Mar 11, 2014 at 11:41:07PM +0000, Andrew Wasielewski wrote:
> At the risk of re-asking an old question, can I ask for help on setting up Kerberos authentication for the coda client?

Oh yes. Kerberos support. Thanks for asking.

The use of Kerberos has been implemented ages ago first at a quality of
proof-of-concept so to say. It had to be replaced.

That's why the authentication subsystem, in the first hand clog
was largely rewritten several years (now many years) ago.

This allowed multiple authentication authorities (trusted database
instances like Kerberos realms) and technologies to be used seamlessly,
even simultaneously for the same Coda realm, without constraints on
account naming or similar.

Unfortunately this part of the code (written at CMU and further refined
here in Sweden) never officially did it to upstream. The main reason
is that the CMU Coda group never needed this functionality for themselves
and lacked prerequisites for extensive testing, on the other side they
were conservative about replacing the security-related code.

Thus if you use Coda via a distro then you do not have any
working/workable Kerberos support - the packagers pick only the old CMU
code. This is a shame of course but on the other hand the functionality
is easily available via the universal installer which we (Aetey) maintain.

The universal one is much easier to maintain than to learn all the
distros' expectations and follow their routines. The latter is hardly
feasible unless there is a person for every distro who both is a regular
Coda user and has enough of the distro-specific competence to maintain
a package.

You have several options depending on your needs and preferences:
- just install Coda clients and servers with the help of Aetey's
  binary installers, Kerberos support is included and I will be
  happy to document any unclear issues you find
  https://www.aetey.se/dl/cocli-2.1-6.9.5-linux-ia32-3.bin
   md5: b2897b0be53b1b209f85fdf0a5452504
  https://www.aetey.se/dl/cocli-2.0-6.9.5-linux-x86_64-0.bin
   md5: 971080aeece1829b4730021337761342
  https://www.aetey.se/dl/coser-1.5-6.9.5-linux-ia32-0.bin
   md5: 8a1f047bb326fa3489f3feb81b0f68da
- take the source code from the same site and compile it yourself
  client:
  https://www.aetey.se/dl/cocli-2.1-6.9.5-linux-ia32-3.src.tar
  https://www.aetey.se/dl/cocli-2.0-6.9.5-linux-x86_64-0.src.tar
  server:
  https://www.aetey.se/dl/coser-1.5-6.9.5-linux-ia32-0.src.tar
- remind myself to publish the git repository with our (Aetey) branches,
  CMU has the code too (Jan, which branch is it in?)
  but we certainly have a newer version here

> I am running Coda 6.9.5-11 both client and server on Fedora 20
> (different hosts) installed from standard Fedora RPM packages.
> Everything works fine using auth2 authentication.

Nice to hear!

> I have created a service principal codaauth/server.wasielewski_at_WASIELEWSKI and exported the keytab file to /vice/db/krb5.keytab.  In /etc/coda/server.conf I have the following Kerberos-relevant setup:
> 
> # kerberos5service contains "%s" which will be substituted with a hostname,
> # for a usual DCE setup it would be "hosts/%s/self
> kerberos5servprinc=codaauth/server.wasielewski_at_WASIELEWSKI
> kerberos5service=host/%s/self
> kerberos5realm=WASIELEWSKI
> kerberos5keytab=/vice/db/krb5.keytab

The line kerberos5service= suggests that your configuration assumes
the code which I consider broken and not-to-be-used.

> If I try to clog in using Kerberos I get the following error message on the client:
> 
> [Andrew_at_ivanka-laptop ~]$ clog -kerberos5 codauser2_at_server.wasielewski
> username: codauser2_at_server.wasielewski
> krb5.c: No credentials cache found while preparing AP_REQ
> kinit: Client 'Andrew_at_WASIELEWSKI' not found in Kerberos database while getting initial credentials

There are many issues with the above, among others using a "wrong" kind
of clog. To really be able to use Kerberos support you need a clog which
behaves like that:

$ clog -help
* clog wrapper, ver 1.0
Usage: clog [<general-options>]
            { [<id>][/<authority>][@<realm>] | -- }
            [<specific-options>]
  general options are
             -help                       (get this message)
            [-show|-dump|-dumpto <file>] (show / output / save)
            [-method <method-name>]      (specify a method explicitely)
  method-name is one of
              anonymousssl
              codapassword
              fromfile
              generate
              kerberos5
              present
  specific options vary from method to method, use
             -help
  to get a list of the corresponding method's options

Besides having the right kind of clog on the client,
as a Coda realm administrator you have quite a lot to set up
on the servers (but this pays back nicely when you are done).

> ...and this in the krb5kdc.log file on the server

It's a pity Codawiki is down and I haven't yet had time to set up
its replacement. Well, let the list archive serve as documentation.

- take a working Kerberos realm
  (You do not have to be a Kerberos realm administrator nor
  need any influence there besides the creation of the Coda service
  principal)

- decide about mapping between Coda identities and Kerberos principals,
  there are two ways
  - a primitive oversimplifying one with extra limitations
  - a straightforward and general one, which implies more
    understanding of what one is doing

  I do not like the oversimplifying approach which assumes the identities
  in Coda and in Kerberos to correspond to each other one-to-one, with the
  same names. This implies that the Kerberos realm and the Coda realm
  are administrated together now and ever and hides important differences
  between the two kinds of identities.
  Taking this as a starting point would be bad for understanding.

  Thus, I recommend that you realize from the beginning that a Coda realm
  can trust several "authentication providers" independently of which
  technology they use or of identity naming conventions/constraints
  of different authentication providers.

  The relevant "technology interface" has to be present
  in a technology-specific clog module (a small executable) _and_
  in an instance of auth2 daemon.

  auth2d does have _some_limited_ capability to support more than one
  authentication provider technology and/or instance at the same time
  but this is not possible in general (!).

  Thus it is correct to always run one auth2 daemon per "authentication
  authority". The Coda realm shall advertise the authentication authorities
  which it trusts and the corresponding auth2 daemons' hosts and ports
  so that clog knows which daemon to talk to depending on which kind of
  identity the user wishes to use.

  (Note, as a Coda realm owner you thus want to set up the advertisement
  service - it is normally a simple inetd directive "cat <your-auth-conf>"
  for tcp port 370)

  One of the usable authentication authorities is the "builtin"
  Coda password database. Often it is the only one to be used
  and then has no special name ("no advertisement service" means exactly
  this situation). As soon as there are more then one authority to trust,
  the authorities have to have names. The names are used in the context
  of a certain Coda realm so you as the realm owner can choose them freely.

  The Coda account names will contain the name of the authentication
  authority to be consulted - as the /suffix, like
   bob/foo (@coda.rea.lm).
   AliCe/bar (@coda.rea.lm).

  (A user can then "clog AliCe/bar_at_coda.rea.lm" or otherwise can
  prepare ~/.codafs/clog/pref and then use
  just "clog" or say "clog asalice")

  The name string including the suffix is to be present as the name
  in the Coda account database (managed with pdbtool).

  The corresponding auth2 daemon instances are to be run with proper
  arguments (the currently shipped binary contains both support
  for Coda password authentication and for Kerberos but should
  be run as separate processes for separate authorities) like
   authd-auth2 -authority codapass        (default port 370)
   authd-auth2 -authority krb5was -port 369

  Moreover the second instance has to be wrapped to see a different
  CODACONFPATH=/somedir with a different server.conf in that directory
  containing the differing arguments and a differing vicedir like
   AUTH2_FLAGS="-authority krb5was -port 369"
   kerberos5servprinc=codaauth/was.rea.lm
   kerberos5realm=WAS
   vicedir=/vice/a2
  and a subdirectory "/vide/a2/auth2" of that differing vicedir
  for the pid and log files of this daemon instance,
  and also symlinks there for other objects which are
  present in the usual /vice (pointing to those objects
  present under the usual /vice).
  (the keytab is looked for in db/krb5.keytab)

So this is far from "automagic" - it is just very hard to make
it "easy" without sacrificing important possibilities/features.

It is also less pretty than it could be because the historically present
configuration management tools in Coda did not foresee multiple auth2
daemons and mutually independent authentication authorities.
Thankfully, it is sufficiently general to make them possible.

For comparison, you have no way to do things like this with NFSv4
or AFS. There you must choose exactly one Kerberos realm and that's all
the accounts you can use in connection with the file service
(i.e. in your groups and acls).

> codauser2 exists as both a FreeIPA and a Coda user, and I can log in
> fine using normal Linux login and auth2 respectively.  Whatever options
> I give clog, it seems to take the Linux username and apply that as the
> Coda user.

The logic in the old clog which you are running is basically broken. The
corresponding logic in the server is bad too. Sorry about that. This
crap has been fixed really really long ago. Please use the modular clog.

> Can anyone see where I am going wrong?  I have read about a "modular
> clog", but not clear where/how I get and use it, nor whether it is
> already part of the Coda client.

It is part of the Coda client which Aetey distributes.
The server support is present in the corresponding package too.

Regards,
Rune