(Illustration by Gaich Muramatsu)
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, RuneReceived on 2014-03-12 07:20:11