Hi Don,

On Tue, Jan 19, 2010 at 03:32:45AM -0800, root wrote:
> >>krb5secret: Unknown error -1765328228 getting credentials
> >
> >This error code seems to mean
> > "Cannot contact any KDC for requested realm"
> 
> Good to know.  In the interest of being self-sufficient, where did you find 
> this information? 

Asked Google for "1765328228 kerberos" :)

It is present in the source code of course - but the library we are using
is built without the strings and it is easier to ask Google than to look
in the code.

> I scrambled it.  Our realm is the upper-cased domain of the company I'm 
> working for. 

(imho there is no reason for a Coda realm to be upper-cased,
rather not - to avoid confusion with Kerberos)

> I still need better understanding of what the "authorities" declarations do 
> in codaauth2.conf and what the "identities" declarations do in 
> .codafs/clog/pref.  They are clearly two sides of the same coin (or perhaps 
> similar coins at different points in the auth process). 

For the moment just forget .codafs/clog/pref, this is a totaly separate
piece of data, mostly unnecessary.

"identities" are your totally personal shortcuts for Coda identities, to
be able to type
 "clog cmu"
which may mean e.g.
 "clog myaccount/certainauthority_at_coda.cmu.edu"

Authorities are realm-local entities, with names in a separate name space,
corresponding each to a certain protocol/trusted-database-instance pair.

> >This is server side and is optional too but crucial for _transparent_
> >authentication. Otherwise you can always manually supply all options
> >(like kdc addresses etc) on clog command line.
> 
> I'll need more info on this, but before I consume needless resources, I 
> will get clog to work exclusively with options.  It is not unusual for 
> understanding to crystalize upon finally hitting the magic combination for 
> success. 

clog command line options are "self-documented" and the syntax is
quite straightforward - may feel not exactly intuitive for
method options though...

> > http://coda.wikidev.net/Server_Binary_Installer 

> >What is missing?

> I know that you don't handle kerberos, per se, and the whole point of this 
> clog adaptation is to permit any random pairing of coda and kerberos 
> possible, but for the experienced/enthusiastic novice, a base-line example 
> is invaluable. 
> 
> I would even be more than happy to write it (I could send it via listserv, 
> email, or direct edit of the wiki).  That is, once I figure out the basic 
> kerberos implementation my own self.  :) 

It would be great if you can share your experience (let us make it
a success story :) via the wiki.

> At your preference.  I call it a server, because it is a mostly headless, 
> rack mount "server" providing services to other servers and workstations.  
> Services for which it will depend on a /coda filesystem.  I.E.:  A server 
> [hardware] running a coda client only [software].  I can just as easiy use 
> "host" here if that is a more accepted convention. 

I see. Unfortunately the word "server" is heavily overloaded and especially
in the context where it normally has a certain meaning - "a Coda server"
it would be advisable to use a different word for a different meaning.

> Will do, though the server, being the krb/kadmin in this test environment, 
> will always have krb files laying about. 

That's no problem. The Coda server is not looking outside /vice (or what
you chose as its file tree prefix). Unfortunately, there still can be
references to extra paths in the Kerberos libraries or in the environment
the server is being started under, but the risk to get unexpected
influences is low (no risk when the configuration is ok).

> >don't hesitate to come back and ask.
> 
> Thanks, I will. 

Welcome.

> A few burning questions raised from the wiki's and your comments above: 
> 
> keytab (krb5.keytab):  Can clog use a kerberos keytab as an auth method?  

Sure:

$ clog -method kerberos5 -- -help
Usage: clog
        -method kerberos5 [<id>][/<authority>][@<codarealm>]
       [-v]
       [-tokenserver <host> <port> [-tokenserver <host> <port> ...]]
       [-krealm <kerberos_realm>]
       [-kdc <kerberos_kdc>[:<port>] [-kdc <kerberos_kdc>[:<port>]] ...]
       [-servprinc <serv_principal>]
       [-keytab {<keytab>|''}]                        <=====================
       [-tgt {only|no}]
       [-withaddr  {yes|no}] (default: yes)
       [-proxiable {yes|no}] (default: no)

[Empty keytab name '' should let it look in implicit "standard Kerberos"
location(s) which is _not_ what I would recommend. Different services
need different identities, a host-wide /etc/krb5.keytab is bad.]

> The implementation appears very similar to the ssh authorized_keys file, 

Hmm. I wouldn't draw such concusions easily, this depends on which aspects
you are thinking of.

> though the keytab is obviously obtained in a much more complicated way and 
> is attached to a given auth user/password. 

Right.

> kinit:  Assuming kinit is laying about on the coda client host, will clog 
> auth transparently off of a kinit fetched tgt? 

Yes, unless you use "-tgt no" (you may want to, if there can be broken
tgts lying around).

> Related to the kinit question, is it preferred to use clog to refresh 
> kerberos tickets (if not using keytab for some reason) or some facility of 
> kerberos (such as krenew or k5start)? 

Clog is definitely a wrong tool for refreshing Kerberos tickets.
It is a Coda tool and it does not have any relation to Kerberos tgts
besides the capability to use them. Clog gives you Coda tokens only
(it creates possibly some very short-lived Kerberos tickets for its own use).

Did you really mean "refreshing Kerberos credentials" or rather
"refreshing Coda credentials"? For the last one
 clog acc_at_codarealm <protected-file-with-password
should be adequate, as well as
 clog [-method kerberos5] \
      acc_at_codarealm \
      [-krealm REALM] -keytab protected-file-with-keytab

(-method amd -krealm are necessary if you do not have the auth
advertisement service)

Note that refreshing Kerberos credentials (say with kinit) will not
refresh your Coda credentials per se, you would need a separate clog
command anyway.

See you Don,
Rune