[OpenAFS] Openafs with a windows kerberos server

[Douglas E. Engert]

Rodney M Dyer wrote:
> 
> At 11:22 AM 5/11/2004, Jeffrey Altman wrote:
> >I added the support to Windows.  Doug did most of the
> >work on the Unix side.
> 
> I haven't checked this, as we have not removed KAS from our equation, but
> does the new klog obtain Krb 5 tickets and stuff them into the cache
> without needing aklog?

Not that I know of. 

There is as little Kerberos V5 code in the OpenAFS code as possible.
What there is a striped done version of code in the servers to decrypt
and decode the ASN1 of a ticket. In the client libs, the encrypted part
of a ticket is treated as opaque, so there is no real Kerbers code
on the client. DES is still the only encryption used.  

The aklog or afslog, or other similar programs all end up getting
the session key, and encrypted part of a ticket and passing these to the
cachamanger via the AFS ktc_setToken routine. These programs
use MIT, Heimdal, SEAM, gssapi or MS SSPI to do all the Kerberos v5 
operations. So select a aklog that runs with the Kerberos V5 
of your choice.  

With the above additions to the server and client, they can still take
a Kerberos V4 ticket as before, but can also take a Kerberos V5 ticket.
this means that the aklog does not have to use the krb524 to convert
the ticket from V5 to V4 but use it directly as is. This conversion of a 
ticket had some good and bad features:

  o The krb524d could rewrite the ticket, making it smaller. 
    This could be important if a Windows AD created it.  

  o The krb524d could accept principals from multiple realms
    and map then to separate AFS users, such that the AFS cell
    does not have to match the Kerberos realm. Thus being able to
    treat an AFS cell as a file service separate from the 
    Kerberos authentication realms.     

  o The krb524d could accept a ticket with one encryption method or key
    but use a different method or key for the V4 ticket. 

  o V4 only had byte for the lifetime of a token. V5 does not have this
    problem.

  o The krb524d could actually map for a V5 to a V5 too!

Without the conversion of a V5 ticket: 

  o Your AFS cell is pretty much a member of one realm. As AFS does not 
    handle foreign users very well.   

  o If you are using Windows AD the ticket will be big, and with W2003
    des-cbc-md5 may be used, thus you will need OpenAFS 1.3.x   These
    where the changes I submitted, to allow a larger ticket and use of
    of md5 in the ticket. 
   
Now this may all change, as OpenAFS may include more Kerberos then
it does today. that id not my call.

Note that you can run in a mixed environment where you still have 
a kaserver running issuing tokens as before, and some users using aklog
as well.   

We are trying to get to where we can use the ticket directly
without any krb524d, as all are users are in Windows AD, and the
AFS cell name is the same as the Windows Domain name. We are not
there yet and still use krb524d, and gssklog too. We need to get the
servers and clients upgraded to support the largest tickets and MD5.

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