Samba3's fake GSSAPI and FreeBSD

[Andrew Bartlett]

On Mon, 2010-09-13 at 11:51 -0400, simo wrote: 
> 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.

OK.  That should have us looking more like a standard krb5 service, and
hopefully fit into the 'expected use' modal. 

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

In s3compat we showed that we could build Samba3 against the embedded
Heimdal.  Once we get a common WAF, it would be very useful to build
against this anyway (to allow 'make test' to run Kerberos calls against
Samba4, using socket_wrapper).  

Could we have an arrangement where we build against an included Heimdal
for development testing, and for platforms without a recent enough
library, but use the system lib on modern distributions like Fedora and
Ubuntu?

That way, we would stop having optional features, and simply choose the
best method to provide those features on a given platform. 

Andrew Bartlett
-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20100915/35cc586b/attachment.pgp>