Greetings Rune et al: 

I have attempted the following: 

[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 

[root_at_sandbox3 ~]# clog -method kerberos5 kerberos_admin_user_at_KERBEROS.REALM 
 -tokenserver sandbox2.host.domain 370 -krealm KERBEROS.REALM -kdc 
sandbox2.host.domain
Password for kerberos_admin_user/default_at_KERBEROS.REALM:
krb5secret: Unknown error -1765328377 getting credentials
clog: failed to login to Kerberos 

[root_at_sandbox3 ~]# clog -method kerberos5 
coda_admin_user/kerberos_admin_user_at_KERBEROS.REALM_at_coda.domain -tokenserver 
sandbox2.host.domain 370 -krealm KERBEROS.REALM -kdc sandbox2.host.domain
Password for coda_admin_user/kerberos_admin_user_at_KERBEROS.REALM_at_coda.domain:
krb5secret: Unknown error -1765328377 getting credentials
clog: failed to login to Kerberos 


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). 


Regards,
 -Don
{void} 


root writes: 

> Greetings Rune:  
> 
> Thank you for your thorough and expedient reply.  My comments are in-line:  
> 
> 
>>> 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"
> 
> Good to know.  In the interest of being self-sufficient, where did you 
> find this information?  
> 
> 
>> 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.
> 
> Understood.  I will attempt some clog commands with various options.  
> 
> 
>> 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"!)
> 
> I scrambled it.  Our realm is the upper-cased domain of the company I'm 
> working for.  
> 
> 
>> 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.
> 
> Ok!  Now this is good to know.  I thought perhaps that was what it was, 
> but I couldn't quite give-over from the "classic" coda method of having 
> coda user / kerberos user semantics.  So this is the key to modular clog's 
> full abstraction from 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).  
> 
> However, the point is still clear regarding my next step.  Shutdown/remove 
> these configurations and try again with explicit clog options.  I will 
> post back the command and results (hopefully success).  
> 
> 
>>> 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.
> 
> 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.  
> 
> 
>>> 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?
> 
> First, allow me to say that these instructions were clear and precise for 
> their purpose.  Permitting basic authentication.  And with respect to 
> initial coda install, both the packages and the nitty/gritty configuration 
> primer allowed for several insights I had not yet understood.  
> 
> However, unfortunately for me, I was already able to get coda working with 
> basic auth from default packages.  What I couldn't do is get kerberos auth 
> working with coda.  
> 
> It's a cruel joke that I can find countless references in search engines 
> of people with kerberos auth issues getting directed to aetey.se, only to 
> end up right back where I was:  Coda auth, no kerberos auth -- albeit, 
> presumably now with a coda client capable of "better" kerberos auth.  
> 
> 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.  :)  
> 
> 
>>>  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?
> 
> 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.  
> 
> 
>> 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.
> 
> Noted.  Should be easily done.  
> 
> 
>> 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...
> 
> Will do, though the server, being the krb/kadmin in this test environment, 
> will always have krb files laying about.  
> 
> 
>> Good luck Don,
>> don't hesitate to come back and ask.
> 
> Thanks, I will.  
> 
> 
> 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?  
> The implementation appears very similar to the ssh authorized_keys file, 
> though the keytab is obviously obtained in a much more complicated way and 
> is attached to a given auth user/password.  
> 
> kinit:  Assuming kinit is laying about on the coda client host, will clog 
> auth transparently off of a kinit fetched tgt?  
> 
> 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)?  
> 
> 
> Regards,
> -Don
> {void}  
> 
>