Greetings Rune et al:
I have attempted the following:
[r...@sandbox3 ~]# clog -method kerberos5 coda_admin_u...@coda.domain
-tokenserver sandbox2.host.domain 370 -krealm KERBEROS.REALM -kdc
sandbox2.host.domain
Password for coda_admin_user/defa...@coda.domain:
krb5secret: Unknown error -1765328377 getting credentials
clog: failed to login to Kerberos
[r...@sandbox3 ~]# clog -method kerberos5 kerberos_admin_u...@kerberos.realm
-tokenserver sandbox2.host.domain 370 -krealm KERBEROS.REALM -kdc
sandbox2.host.domain
Password for kerberos_admin_user/defa...@kerberos.realm:
krb5secret: Unknown error -1765328377 getting credentials
clog: failed to login to Kerberos
[r...@sandbox3 ~]# clog -method kerberos5
coda_admin_user/kerberos_admin_u...@kerberos.realm@coda.domain -tokenserver
sandbox2.host.domain 370 -krealm KERBEROS.REALM -kdc sandbox2.host.domain
Password for coda_admin_user/kerberos_admin_u...@kerberos.realm@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/ad...@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}
