[OpenAFS] one afs/cell.domain princs per realm

[Douglas E. Engert]

Ken Hornstein wrote:
> 
> >I'm looking at Doug's kerberos 5 modifications below and also the
> >gssklog. Any suggestions as two which might fit better? Maybe a
> >combination of the two?
> >I may be able to just do one REALM, and that being ttu.edu. But I must
> >create a cell called cs.ttu.edu, and have the users be local.
> >I'll have to run any krb524ness within my boxes. TTU.EDU is a windows
> >AD domain and they are not likely to run krb524. Thanks for all the
> >direction and support thus far.
> 
> My main issue is with gssklog is that my impression is that relatively
> few people use it.  I don't know of anyone outside of Doug, actually.
> This isn't a scientific survey; it's just a "gut feeling".  There could
> be tens of thousands of people out there using gssklog, and they're
> just quiet about it.  Well, okay, I have one other minor issue, which
> relates to the "few people using it" issue; if you're ever going to
> want someone else to use your cell, they're not likely to have gssklog,
> they're more likely to have one of the V5 aklog variants.

As with any new software, acceptance can be slow. But the best that I can tell,
there are some sites using or testing it. The readme file 
ftp://achilles.ctd.anl.gov/pub/DEE/README.GSSKLOG has acknowledgments
for 5 people who have submitted changes. My intent is to turn gssklog over 
to OpenAFS eventually if they will have it. 

Gssklog originally started to allow Globus GSI to get AFS tokens without
having to go thorough Kerberos and krb524d first. Since it was using GSSAPI,
it was a simple mater to allow it to use Kerberos GSSAPI.

Since then, one of the goals was to not require a separate Kerberos package 
on the client. This is especially important on Windows. The MIT tools work
great, but many users and admins don't want the extra packages. This week
there has been some discussion on how to use it with SEAM on Solaris too.

The last release of the gssklog, can use either a gssapi32.dll or the
Microsoft SSPI. (It does this at run time.) So if you have the MIT tools 
installed it can use them. If not, or you don't have a ticket,
it can use the SSPI, and the logon credential. The next version 
I am working on can even use a principal and password with SSPI so
the user does not have login to a domain first. 

The use of gssklog does not preclude the use of aklog. They can both 
issues AFS tokens. On UNIX we are running both, but for Windows we are 
using only gssklog, as we phase out the use of the KAS.    

> 
> So, if few people use gssklog, that means that you've only got Doug to
> help you when there are problems.  Maybe there won't BE any problems,
> but I am doubtful.  Not that I think gssklog is a bad piece of software,
> but it's been my experience that when you're starting out with AFS
> and trying to put a seperate Kerberos realm in the mix, you're
> going to have some problems, simply due to a lack of experience and
> the complexity of the different parts.
> 
> If I was in your situation, knowing what I know now, I'd do one of
> two things:
> 
> - I'd investigate the relocating of the krb524d server, similar to what
>   other people who are stuck using Windows AD servers are doing.
> - I'd have aklog do the krb5 ticket mangling itself.
>

In the long run, if you can live with the AFS cell being equivelent to
the Kerberos realm, using a K5 ticket directly is not such a bad idea. 
Today there are problems with using a Windows AD server this way. There
are KVNO problems and the AD will add the PAC to the ticket, making it to
large for use with the AFS RX. Microsoft is looking at the size issue,
and in the future it might be possible to not have the PAC included. 
(See my note of a few days ago on this.)

I also have something called mskog, that uses the SSPI and LSA to get
a K5 ticket from the AD or K5 KDC, then use this directly as an AFS token.
i.e. no krb524d or gsklogd deamins involved. But the knvo and 
requesting of no PAC have some problems.  
 

> But this is just my opinion.

See: ftp://achilles.ctd.anl.gov/pub/DEE/README.GSSKLOG

> 
> --Ken
> _______________________________________________
> 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