Hi Don,

On Mon, Jan 18, 2010 at 12:51:52PM -0800, root wrote:
> I have [modular] clog working, and kerberos working.  However, I've yet to 
> get coda w/kerberos working.  If anyone has a base example of how to get 
> kerberos/coda talking to each other, I would sincerely appreciate it.  

Configuring Coda with Kerberos may feel tricky the first time.

> Specifically, I think either my coda/kerberos users aren't matching up, or 
> I'm failing to indicate the user to coda (coda realm vs kerberos realm, 
> with or without kerberos realm, etc.) 

> kinit & klist function normally
> clog w/codaauth functions normally 

Good!

> clog w/kerberos /wo kinit auth failure: 
> 
> [root_at_sandbox2 ~]# kdestroy
> [root_at_sandbox2 ~]# clog
> Password for admin/admin_at_KERBEROS.REALM:
> krb5secret: Unknown error -1765328228 getting credentials

This error code seems to mean
 "Cannot contact any KDC for requested realm"

I guess the problem is that you rely on your client-side ~/.codafs/clog/pref
which is totally unnecessary for testing, nor for regular use as long as
you supply the Coda account name and the Coda realm name on the command line.

Your file (and possibly the corresponding advertisement from the server)
seems to point to a non-existing Coda realm (named for some reason
"KERBEROS.REALM"!) and to an authentication authority called "admin" which
looks confusing. The authentication authority is a name for a certain
way to authenticate against the given Coda realm. You may have several
authorities designating e.g. several Kerberos realms usable with one Coda
realm, or authorities to refer to different authentication means. If you
are using a single Kerberos realm as the main means of authentication,
call the corresponding authority "krb" or "common" (but why "admin"? -
it is really you private matter of choice - I just want to make sure
you know the semantics).

I would suggest to begin with manually supplying all the parameters
on clog command line and removing ~/.codafs/clog/pref to avoid
extra confusion.

> NOTE:  It is quite possible that I simply have not created the kerberos 
> principal/user or the coda user correctly -- or, perhaps I simply haven't 
> configured .codafs/clog/pref

This is client side and is totally optional.

> or TCP 370 "codaauth" service correctly for 

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.

> this user/principal pair.  This part of the configuration is largely 
> undocumented.  While I have spent considerable time adding all manner of 

Well, I think I made a reasonable effort in
 http://coda.wikidev.net/Server_Binary_Installer

It would help if you ask more explicit questions with reference to
certain statements from that page, then I may fix/add it there.
What is missing?

> An example of my novice level:  I created a coda user "admin" using pdbtool 
> "cu" to duplicate the realmadmin user default.  This matches our kerberos 

Good.

> "admin" user which, while not necessary, worked for us.  I can verify the 
> coda "admin" user now exists, but how does one test to see if the coda user 
> has a password; aetey.se instructions refer to leaving the coda user 

As long as you did not set such password (with the "au" command) it does
not exist.

You are not interested in this fact for the sake of setting up Kerberos
authentication. Missing Coda password just makes it sure there is no
way to authenticate without the corresponding Kerberos password.

> password blank for the coda side of the kerberos/coda pairing. 
> 
> I am using coda client and server as available from aetey.se -- my 
> understanding is that this provides the modular clog which is recommended 
> for kerberos. 

Exactly.

> I have followed the instructions on aetey.se for client and server.  I have 
> also configured DNS with optional SRV records (coda entries, as well as 
> kerberos auth entries). 

Good.

> For simplicity, I am testing the coda client on the server running the coda 
> server.

>  However, if needed, I also have a second server only running the 
> client. 

This looks contradictory :) You mean, you have another host running a client?

A client on the server host may be more confusing for the beginning, in case
you have Kerberos-related things lying in /etc and alike and expect the client
to pick things from there.

For simplicity use a plain Aetey client on a different host, there
shouldn't be any Kerberos-related configuration present there, really,
to avoid possible confusion. You do not need any "kinit" or similar.

Similarly for the server - put it preferably on a "Kerberos-agnostic" host
without any traditional Kerberos configuration files and libraries. Those
are ignored by the server but may confuse yourself.

When you have Coda authentication with Kerberos working, with all parameters
given on the clog command line, then set up the advertisement service on
the server and make clog work with <account>@<codarealm> only. When it is
working and you feel adventurous, proceed wiht setting up .codafs/clog/pref...

> Since kinit works, and I have successfully tested kerberos for http auth, I 
> am assuming the issue is not related to kerberos, and have thereby made my 
> appeal on the coda mailing list. 

Sure.

Good luck Don,
don't hesitate to come back and ask.

> Regards,
> -Don
> {void} 

Regards,
Rune