[OpenAFS] Some questions about the future of OpenAFS

[Douglas E. Engert]

Derrick J Brashear wrote:
> 
> On Mon, 22 Apr 2002, Tim Gaastra wrote:
> 
> > 1) Is there a time table for converting AFS to be a Kerberos V5 service?
> > (I.E., no need for krb524d, no need to use asetkey to grab the Key from
> > a keytab into the Keyfile but instead just using a keytab like other V5
> > services, etc.)
> 
> For this to happen, Rx needs to be able to deal with krb5, and it can't
> yet, though there has at least been progress down this path (actually,
> GSSAPI, which gets you krb5).

The gssklog programs I have been working on for the Globus Project,
http://www.globus.org use a different GSSAPI, based on SSL and X509.
Useful at sites where there is Globus and AFS but no Kerberos V5. 
But was designed to use with Kerberos GSSAPI as well. I am back working
on this. 

Not only does the use of GSSAPI eliminate the need for krb524, but could
actually free AFS to use something other then Kerberos or Kerberos code 
for tokens. For example use the OpenSSL or OpenSSH crypto routines. 

One of the goals I have is to show how OpenAFS could work on W2K 
with the gssklog using Martin Rex's GSSAPI over SSPI on W2K. This would
then not require any MIT or Hiemdal Kerberos code at all on the W2K system.
  
Another benefit, is that the AFS cell does not to be in a single realm,
it can accept authenticate from multiple Kerberos realms or other gssapi
mechanisms. 

What is needed is a good way to map authenticated users to the AFS cell 
PTS database. 


> Further, pts should likely have a way to
> deal with it, since existing sites won't want to have shadow/admin and
> shadow.admin. There are doubtless other subtleties which will crop up. A
> simple "just rename foo.bar to foo/bar and fix all the ACLs" would
> probably be easier, but painful for any site which piggybacks anything on
> pts.
> 
> > 3) What are the moral and technical objections to tying some of the
> > databases (the ptserver, mostly, obviously this isn't the best idea for
> > the VLDB) to a kerberized version of LDAP (by which I mean an LDAP that
> > authenticates access via Kerberos)... "Why would anyone want to do
> > this?" Well, the biggest reasons I can come up with is centralization of
> 
> Is there real time replication and floating master in OpenLDAP yet?
> Throwing away functionality is something I find personally repugnant,
> though in this vein I speak only for myself.
> 
> -D
> 
> _______________________________________________
> 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