Coda File System

Re: modular clog + kerberos

From: u <u+codalist-wk5r_at_chalmers.se>
Date: Wed, 20 Jan 2010 10:28:08 +0100
Hi Don,

On Tue, Jan 19, 2010 at 11:57:24AM -0800, root wrote:
> Greetings Rune et al: 
> 
> Ok, I think we're getting to the real core of what I do not understand. 

Kerberos is not easy to understand, among others due to all the
oversimplifying howtos which help while solving simple problems but
hinder comprehension :)

> >Do you have a principal called "codaauth/coda.domain" ?

Well, I should have used the right term myself, "codaauth/coda._realm_".

> Here are my coda/ kerberos service principals (no recent changes):
> coda/sandbox2.host.domain_at_KERBEROS.REALM
> coda/sandbox3.host.domain_at_KERBEROS.REALM
> coda/coda.realm_at_KERBEROS.REALM 

The answer is apparently "you don't".
The are comments on the wiki about the implication of using any other
principal. Let you use the right one.

> >Put the keytab for the chosen principal into /vice/db/krb5.keytab

> Additionally, I have created the following krb5.keytab (used ktutil to 
> output contents):
> [root_at_sandbox2 ~]# echo -e "read_kt /etc/krb5.keytab\nl\nquit"|ktutil; echo
> ktutil:  ktutil:  slot KVNO Principal
> ---- ---- 
> ---------------------------------------------------------------------
>  1    3 host/sandbox2.host.domain_at_KERBEROS.REALM
>  2    1 coda/sandbox2.host.domain_at_KERBEROS.REALM
>  3    1 coda/sandbox2.host.domain_at_KERBEROS.REALM
>  4    1 coda/sandbox2.host.domain_at_KERBEROS.REALM
>  5    1 coda/sandbox2.host.domain_at_KERBEROS.REALM
>  6    1 coda/sandbox2.host.domain_at_KERBEROS.REALM
>  7    1 coda/sandbox3.host.domain_at_KERBEROS.REALM
>  8    1 coda/sandbox3.host.domain_at_KERBEROS.REALM
>  9    1 coda/sandbox3.host.domain_at_KERBEROS.REALM
> 10    1 coda/sandbox3.host.domain_at_KERBEROS.REALM
> 11    1 coda/sandbox3.host.domain_at_KERBEROS.REALM 

There is no mention of codaauth/coda.realm_at_KERBEROS.REALM
No other entries are necessary.

> Further, /etc/krb5.keytab is duplicated to /vice/db/krb5.keytab. 

Forget /etc/krb5.keytab. It is not used by Coda.

> Is a krb5.keytab needed on the client? 

It depends on your needs. Not for being able to use the Kerberos
password to authenticate against Coda.

If you feel you want to use a keytab, hope you understand that the user
keytab has to contain data for the user's principal, not for the Coda realm's
one.

Note, a keytab is in this case per _user_ not per client host.
(Of course /etc would _not_ be an appropriate place for it.)

> Do I need to remove all the coda/sandbox*.host.domain_at_KERBEROS.REALM  
> entries and replace them with a single coda/coda.realm_at_KERBEROS.REALM? 

What you need is only codaauth/coda.realm_at_KERBEROS.REALM

> Wouldn't it be more secure to have a service principal for each server 
> host? And likely one for each client host as well once we start using 
> keytab based auth. 

Forget all you said in this paragraph :)

A "service principal" is as it says - per service.
Coda is replicated, all servers in a realm are the same service.

Historically there were hardly any services not bound to a single host (!)
which is a pity, This has also damaged the understanding of the concepts,
not only for you but for a couple of generations of system administrators :-/

Regarding "client authentication":
For the sake of security I reiterate once more, it is not a client host
who authenticates against Coda, it is a user. There can be many users
on one host or the same user can be using multiple Coda client hosts
at once...

> I expect this next response will clarify things greatly for me.  I 
> sincerely appreciate this assistance. 

I hope it helps.

Regards,
Rune
Received on 2010-01-20 04:29:27