[OpenAFS] Re: Authentication without aklog
Douglas E Engert
Tue, 05 Aug 2014 09:34:30 -0500
On 8/4/2014 9:35 PM, Andrew Deason wrote:
> On Mon, 04 Aug 2014 15:21:36 -0500
> Douglas E Engert <firstname.lastname@example.org> wrote:
>> User's have to "login" to other "network file systems" like DropBox,
>> Box, or other Cloud systems. The issue of having to login twice, is a
>> trust issue. Users live with it every day, on the Web.
> Users of all other kerberized services do not need to "login" to every
> service they use. If everything is configured properly to use kerberos,
> I don't need to separately login to the ldap server, to ssh, to
> kerberized nfs, or even to a website using spnego.I just use the
> relevant service after I have acquired kerberos tickets.
> Of course, most
> of those are userspace programs where this is much easier, but I see no
> reason for the user experience to be different for a non-userspace
> application if there are no technical obstacles making it impossible.
> (And imo, NFS has shown it's not impossible.)
That works if both user and server are in same realm or with cross realm
trust. An afs aklog daemon could work like (or use) the rpc.gssd.
This works well in an enterprise,or where cross realm trust between
organization is setup. But wide spreed cross realm trust has not caught on.
and it is not clear if the original question of this thread was addressing
where the user did not do a Kerberos login.
> I can only imagine if I wanted to use 5 different kerberized services on
> the same box, and they all worked like AFS. Running aklog, nfsklog,
> sshklog, ldapklog, httpklog... it would be a nightmare.
But who is to say if the nfs, ssh, ldap, or web server all had the same
kerberos trust relationships. And the nightmare exists on the web today,
with different userids and passwords for every site. How many do you have?
> aklog has the
> ability to authenticate to multiple cells
Which is the nice feature of aklog. It allows a user to authenticate
to some foreign cell, even if the local machine has no trust relationship
with the foreign cell. (i.e. user did local login, or kerberos login to
a realm where no cross realm trust is setup to the realm of the AFS server.
Its the user and the foreign cell that have the trust relationship. The
foreign cell is trusting the user to be using a machine the
> (which would help for dfs, and
> could probably help for nfs if it needed it, etc) but it would have to
> have knowledge of every single system to be convenient.
And thats the problem.
A side question is can AFS use some other authentication
method other then Kerberos?
The was the reference to using Globus Grid proxy certificates with gssklog.
As a side note, where I used to work, is a member of InCommon, uses AD
for kerberos, and the Shibboleth IDP would accept user/password,
Smartcards or Windows Auto Enroll certificates, or Kerberos credentials
for authentication. We used Box and other cloud services. AFS is used
only internally and works without the users having to use aklog
if they logged in via Kerberos to AD.
Douglas E. Engert <DEEngert@gmail.com>