Samba3's fake GSSAPI and FreeBSD

[simo]

On Mon, 2010-09-13 at 09:56 +1000, Andrew Bartlett wrote:
> On Sun, 2010-09-12 at 09:24 -0400, simo wrote:
> > On Sun, 2010-09-12 at 16:08 +1000, Andrew Bartlett wrote:
> > > On Sat, 2010-09-11 at 18:59 -0700, Jeremy Allison wrote:
> > > > On Sat, Sep 11, 2010 at 07:01:16PM +1000, Andrew Bartlett wrote:
> > > > 
> > > > > Samba4 will cope with the previous behaviour (a normal krb5 checksum
> > > > > without a gssapi channel binding), and with a full gssapi channel
> > > > > binding, but not this particular combination.
> > > > 
> > > > Unfortunately Windows doesn't, and requres the checksum.
> > > 
> > > That's interesting - what I meant is that Windows and Samba4 (Heimdal)
> > > accepted the 3.0 behaviour, where we had the normal krb5 checksum type,
> > > and no data (because it's not gssapi, so no bindings to sum).  The
> > > variations after that I'm less clear on. 
> > > 
> > > > > As this is all well
> > > > > outside real GSSAPI behaviour, I've put this change in to keep
> > > > > everything consistent.
> > > > > 
> > > > > http://gitweb.samba.org/?p=samba.git;a=commitdiff;h=3b4db34011f06fb785153fa9070fb1da9d8f5c78
> > > > 
> > > > Ok, that makes sense. Please apply to v3-6-test as well please.
> > > 
> > > Sure.  
> > > 
> > > > > Perhaps we should perhaps have two simple defines:  HAVE_KRB5 and
> > > > > HAVE_MODERN_KRB5, with a switch between the two rather than testing for
> > > > > each function, and getting too many combinations.  We just can't test
> > > > > the number of variations at the moment.  
> > > > > 
> > > > > In the long term, I very much look forward to replacing this with real
> > > > > GSSAPI at some point, and removing much of this complexity.
> > > > 
> > > > Sure, Simo is working on this at the moment.
> > > 
> > > Simo,
> > > 
> > > I would like to work with you on this, if you are able. 
> > 
> > If you want to review the work being done in my msrpc branch, feel free
> > to send comments. I am going to push it very soon, as most of my test
> > scenarios sem to pass.
> 
> This looks like a very useful set of changes!  It also looks to me like
> you have removed much of the DCE/RPC specific stuff from the
> authentication code here, and so we have the hope that we could use the
> same code in the SASL and CIFS servers too. 

Yes, I explicitly and consciously made an effort to make it dcerpc
independent, so that we can think of using it ofr CIFS. Haven't looked
at SASL, but should be easy to model it like the SPNEGO wrappers.

> Is the client code here too?  It's not very clear from the commits.

The client code is already in master.

> I'm keen to extend this - is there a particular area I could work on
> that would help, without getting in your way?

Before extending it to CIFS/SASL we need review and testing in order to
be able to commit this code to master.

There is one problem with setting up the credentials that depends on the
fact that the MIT GSSAPI interface has some issues internally.
They are being resolved and a new interface similar to that of Heimdal
is being introduced to import credentials directly from a kerberos
context.
But it will not be in any distribution/OS for a long time so we need to
work around it.
But that problem may go away if we unify all the code to set up the
server credentials in only one place.

Another problem is that some of this code depends on facilities not
available in MIT until 1.7/1.8. this is what prevents us from actually
using it in CIFS as it would mean a regression (no krb5 support) for
many platforms that has only older versions available.
We never had krb5 support for DCERPC so I didn't feel constrained to
provide backward compatible support in there. But if we want to make
smbd use this code we need someone to make this code work on older
Kerberos versions first.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>