(Illustration by Gaich Muramatsu)
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, RuneReceived on 2010-01-20 04:29:27