[OpenAFS] Kerberos 5, AFS, and no krb524d

[Douglas E. Engert]

Rodney M Dyer wrote:
> 
> At 09:51 AM 6/9/2003 -0500, Douglas E. Engert wrote:
> 
> >The end goal should be to keep AFS flexibly enough to work with any
> >authentication system in a secure manor, and to not get it tied to closely
> >to any one.  This may be some version of Kerberos or some other authentication
> >system. AFS is a file system where the client and file server need to
> >communicate
> >on behalf of some user who has rights to access files.
> 
> Well then the solution seems straight forward.  The OpenAFS group needs to
> create a standardized wrapper library for obtaining the AFS credential
> (token).  The "klog" command then needs to be renamed to "afslogon" and all
> references to anything kerberos needs to be stripped out of the code
> base.  Then, you just end up calling your authentication wrapper with the
> information to obtain the token.  The wrapper does the work of determining
> which authentication method you are using, getting the token, etc.  Gee,
> this hints of a mechanism like SASL.  The way I see it, AFS is way too
> dedicated to Kerberos.  OpenAFS and Kerberos share a common
> history.  Seperating the two is like cutting off an arm.

Well, that is one way to look at it. The other is that the call to 
ktc_SetToken is what is common.  

> 
> > > Hmm...just thinking...for the Windows users...so would it be possible to
> > > create an AFS K5 service principle on Microsoft's AD server, then request
> > > that service principle, strip it clean, then stuff it into the AFS token
> > > cache?
> >
> >Yes, that is very possible.
> >
> >  I suppose the salts would be a problem here.  But, if you could do
> > > this, you wouldn't need the krb524 code right?
> >
> >No, the salt has to do the authentication of the user. It has nothing
> >to do with the actual AFS token. You are thinking it is a one setp process,
> >but it is a two sete process, authentication to a third party, then obtaining
> >the token.
> 
> Blinded by ignorance, you are correct.  First get TGT (auth), then get
> service ticket, convert the bits and stuff into cache?
> 
> So if I've setup my AD domain to trust a MIT Kerberos realms TGT, then I
> could just request my AFS service principle ticket from my AD server right?

You don't even need the MIT Kerberos realm. You can add to the AD
the afs/<cell>@<AD-realm> principal.  

Its been a long time, but you use the AD Management tool to
create the account. Since the AD does not like multiple part names,
you need to use the account mapping to map afs/<realm> to the account
you picked. Remenber the password used. (It can also show you the DES key 
in hex.)
 
You can use the MS ktpass command to create a keytab file or the MIT ktutil
uisng the same password or the hex key. 

This is a must see document: 
http://www.microsoft.com/windows2000/techinfo/planning/security/kerbsteps.asp

This is old, but gives a lot of step by step Kerberos facts. 

You would treat the afs/<realm> like the unix host/<hostname> 

> 
> Err, being ignorant here...how exactly would I install the AFS principle
> into the AD kerberos database?  What I mean is...I know that we have the
> "setspn.exe" utility available from Microsoft.  I'm just not sure what
> information I'd need to do this.
> 
> http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/setspn-o.asp
> 
>  From the readme...
> 
> http://www.coe.uncc.edu/~rmdyer/setspn_readme.txt
> 
> So, I need to setup the "account" for AFS first, then declare it a service
> principle with this tool?

I am not sure if you need this tool. We did not use it. 

> 
> Assuming I did this I'd have a valid Kerberos 5 AFS service principle on
> the AD that could be requested by the user through the SSPI interface?

Well almost. The sspi interface is equivelent to the gssapi. 

It is designed to do an authenticaiton under the covers, and you never see the 
actual service ticket. But the service ticket is what we want for the token. 

But if the k5 service ticket needs some translation, i.e. the encryoted
part needs to be changed, then you need a krb524d or gssklogd runing that
can decrypt, change and encrypt the ticket so it can be used as a token. 
Then you could use the sspi to authenticate to the service. Since sspi
used the K5 gssapi protocol, (see above URL for sample) if I chnage the
gssklog I have to use sspi it could talk to the existing gssklogd. I hope
to try that this week. 

If on the other hand the service ticket does not need any translation,
then you might be able to get the service ticket out. I heard the Umich
was doing something like this with the kx509.    

> 
> Anybody care to elaborate?
> 
> Rodney
> 
> _______________________________________________
> 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