[OpenAFS] Re: Issues with KfW and OpenAFS

[Douglas E. Engert]

> Jeffrey Altman wrote:
> 
> Douglas E. Engert wrote:
> 
> > There is an important issue here. Will future versions of OpenAFS be dependent
> > on KfW?
> >
> OpenAFS is not dependent on KFW.  You can turn the use
> of KFW off on a local machine or current user basis if
> desired.  However, if you want Kerberos 5 support integrated
> into the OpenAFS tools (system tray dialogs, aklog, integrated
> logon, etc) KFW is the way you get it.

Yes I agree. KfW gives you all the features and many people will use it.
But it is another package to install or if installed with OpenAFS,
doubles it size.   

> 
> As you well know, the version of Kerberos provided in Windows does not have
> a clean API.  Its behaviors have changed in each version of Windows.  Via
> the MIT MSLSA: krb5_ccache type all of this is hidden.  You are able to
> utilize both the Kerberos SSP and the MIT implementation in a uniform
> manner.  All of the ugly details of the Kerberos SSP are hidden from view.
> 
> Even if you could simply use the Kerberos SSP, you would still need
> a Kerberos library to support krb524d or something similar.

krb524d can be eliminated if no mapping is needed between user@realm and
user@cell, as the client can use the K5 ticket as the token using the 
kvno = RXKAD_TKT_TYPE_KERBEROS_V5 code.  This is exactly what the msklog 
code I contributed to OpenAFS does. It can work with any KDC too.

But due to the size if the ticket produced by a Microsoft AD AFS has
problems. Microsoft had sent us a test fix for the problem, i.e.
don't send the PAC in the service ticket, and they have been promising to 
release itas a hot fix any day. When this happens I will be geting 
back to msklog.  

> Yes, I know about your desire to have your gssklogd be supported instead.

Its not instead, it is an alternative. And it can use the SSPI or the
MIT gssapi, or any gssapi.   

>  However, that
> functionality is not packaged at the current time with either of the popular
> KDCs nor is it packaged with OpenAFS.

I did get gssklog built against 1.3.50 sometime ago, and now that you added
the SDK changes to 1.3.61, it can be built using the SDK includes and libs. 
(It did take me a day and a half to get the VS .NET 2003 installed to build it.) 
 
> 
> My final argument is one of limited resources.  The available resources
> are extremely limited.  Not just from a funding perspective but from a
> developer perspective.  Its not like we have had people jumping up and
> down desiring to perform development work on OpenAFS for Windows.

I think there are a lot of people that would like to help, but you are
the only person I know of who really understands OpenAFS and Windows enough
to get things done. Glad to see you working on it!   

> I cannot justify the cost of re-implementing and maintaining the code
> necessary to utilize the Kerberos LSA on current and future platforms
> within OpenAFS when there is a library available which is supported
> and maintained which breaks the dependencies and provides an abstraction
> layer which allows OpenAFS to use Kerberos 5 seemlessly regardless of
> whether the Windows Logon Session is Kerberos 5 authenticated or not.

Well when Microsoft finally releases that NOPAC for the ticket hot fix
I am going to look closer at integrating the msklog code which uses the 
Kerberos LSA.  The main subroutine with all the LSA code is only 365 
lines of code. 

> 
> So while MIT Kerberos for Windows is not required, I believe that from
> a practical perspective, for 99% of OpenAFS users on Windows it should
> be considered as if it were.  Constructing a single NSIS installer which
> conditionally installs MIT KFW if it is not there is trivial given the fact
> that both OpenAFS and MIT KFW are using the NSIS scripts.

I think your estimate of 99% is high, but we will see. I know I will
install it, at least for now. But I still think there are many users
who would use OpenAFS in a AD who don't want to install the extra KfW 
package if they don't have to. 

  

> 
> Jeffrey Altman

-- 

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