[OpenAFS] Native Kerberos 5 authentication in openafs-1.4

[Douglas E. Engert]

Earl Shannon wrote:

> Hello,
> 
> This is just a minor point, and if using aklog is where things go
> then fine.  If I understand you correctly Ken, then aklog is getting
> my token/ticket as part of setting up a session at login as a
> separate application of sorts. And as I say that's fine. But my
> point is I don't get a ticker for say, IMAP, until I start a mail
> client and it attempts to login to the IMAP server.  I'm suggesting
> that the afs token/ticket doesn't need to be obtained until the
> user attempts to make use of AFS, ie, by cd 'ing into the AFS
> file system. And its at that point that the authentication to AFS
> occurs. Using aklog as part of a session setup is a "pre-authentication"
> of sorts.
> 

Two comments here:

(1) One of the problems is that a cd /afs is done by the kernel,
where as Kerberos ticket caches are maintained in user space and pointed
at by environment variables.

The Opengroup's DFS did some thing similar to what you wanted to do
as the ticket caches where stored in /opt/dcelocal/var/security/creds/dcecreds_<PAG>
where <PAG> was the pag number in hex. The DFS kernel code could then ask the
dced (or was it a dfsd) daemon to get additional tickets as needed to access
the servers. In DFS each server had its own principal and key, unlike AFS
where there was one common key for all the servers in the cell. So as the DFS
kernel need to contact a different DFS server, it would need a new ticket.

NFSv4 has the same problem and I think they are trying to use gsspai and store
the tickets in the kernel. (I may be wrong on how they are doing it, but they
have the same problem of the kernel needing to get tickets.)



(2) You also asked, why aklog is not built. I would speculate, it has to do
with whose Kerberos do you build it against? MIT, Heimdal, or a vendor's
provided version? The APS community has supporters for all of these different
Kerberos implementations.  Sun and HP both provide thier own Kerberos with
their OSs. Some Linux provide both MIT and Heimdal. Kerberos does not have a
standard API like gssapi where an application like aklog could be built against
the API, and at runtime use the local version on the system.  How about a gssklog ;-)

> Now, since most sites using AFS put peoples home file
> space in AFS, the session setup getting the token is a good
> and currently necessary, thing. :)

It sure is.

> 
> Regards,
> Earl Shannon
> 
> 
> Ken Hornstein wrote:
> 
>>> While probably not the case I can only hope that the exclusion of the 
>>> tools
>>> is because they want to do a better job of inter operating with the KDC.
>>> In my opinion that would mean dropping the need for aklog and asetkey.
>>> After all aklog is basically a second authentication.
>>>   
>>
>>
>> You are incorrect.  Aklog is simply the program that takes your Kerberos
>> tickets and makes them available to AFS (possibly getting a Kerberos
>> ticket for AFS, but it doesn't ask for a password).  In this sense, it
>> behaves just like every other Kerberized application.  If you arrange for
>> aklog to be run at login time, it becomes an essential component of
>> single sign-on (you don't have to use aklog per se, you can use a PAM
>> module that does aklog-like things).
>>
>>  
>>
>>> Why can't the authentication
>>> take place the same way as say, using an IMAP server?. You access the 
>>> server,
>>> ( cd to /afs ) and get asked for your credentials.
>>>   
>>
>>
>> If you can figure out how to make this happen in a portable manner, let
>> me know.
>>
>>  
>>
>>> And asetkey simply puts the principal afs into a keyfile that afs 
>>> knows how
>>> to read. Well, make afs read the kerberos key file where it is as it is.
>>>   
>>
>>
>> That's not unreasonable.  I suspect sometime in the future someone will
>> do that.  But it's worth pointing out that you don't technically need
>> asetkey; you can use klist to read the raw key data (-K in MIT
>> Kerberos), and Heimdal already knows how to write a AFS KeyFile.  I'm
>> not saying asetkey won't get added, but there was a finite amount of
>> time before the 1.4 branch was cut, and I only had the free time to do
>> aklog.
>>
>> --Ken
>> _______________________________________________
>> OpenAFS-info mailing list
>> OpenAFS-info@openafs.org
>> https://lists.openafs.org/mailman/listinfo/openafs-info
>>  
>>
> 
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
> 
> 

-- 

  Douglas E. Engert  <DEEngert@anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444