Greetings Rune et al: 

Ok, I think we're getting to the real core of what I do not understand. 


>> [root_at_sandbox3 ~]# clog -method kerberos5 coda_admin_user_at_coda.domain 
>> -tokenserver sandbox2.host.domain 370 -krealm KERBEROS.REALM -kdc 
>> sandbox2.host.domain
>> Password for coda_admin_user/default_at_coda.domain:
>> krb5secret: Unknown error -1765328377 getting credentials
>> clog: failed to login to Kerberos 
> 
> The error means: Server not found in Kerberos database 
> 
> Do you have a principal called "codaauth/coda.domain" ?

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 

NOTE:  I set those up when trying to get kerberos auth to work under the 
basic bundle rpms.  The instructions I found stated to use "coda" rather 
than the default "host".  The aetey.se instructions say to use codaauth 
instead, but I updated the server.conf to match coda/ (see below). 


>> I do not specify -servprinc as I'm not really certain what I should put
>> in there and how it ought to relate to a keytab (currently
>> non-existant). 
> 
> http://coda.wikidev.net/Server_Binary_Installer :
> -----------------------------------------------------------------------------
> Edit /vice/server.conf for the following statements being present and
> not commented out: 
> 
> kerberos5servprinc=codaauth/<your.coda.realm>
> kerberos5realm=<kerberos.realm> 
> 
> You can also use any principal name instead of codaauth/your.coda.realm,
> but then each user will have to configure her clog to trust this principal
> for your Coda realm authentication, to prevent possible principal
> spoofing. So as long as you have some influence on the Kerberos realm
> in question, ask them for codaauth/your.coda.realm. 
> 
> Put the keytab for the chosen principal into /vice/db/krb5.keytab

And this is where my understanding really starts falling a part.  I have, 
none-the-less, configured vice/server.conf as follow: 

kerberos5servprinc=coda/sandbox2.host.domain
kerberos5realm=KERBEROS.REALM 

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 

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

None of this has changed recently. 


Is a krb5.keytab needed on the client? 

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? 

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. 


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

Thanks,
 -Don
{void}