[PATCH] support for kerberos in plugin DC code

[simo]

On Thu, 2011-07-28 at 05:56 +1000, Andrew Bartlett wrote:
> On Wed, 2011-07-27 at 08:19 -0400, simo wrote:
> > On Wed, 2011-07-27 at 14:31 +1000, tridge at samba.org wrote:
> > > Hi All,
> > > 
> > > Andrew and I have been working towards making the combination of the
> > > s3 file server and s4 DC code more functional. One of the big missing
> > > pieces in this was kerberos - it was not possible to use kerberos
> > > authenticated connections in a s4 server when using the s3 file server
> > > code, regardless of whether the franky or builtin approach is used.
> > > 
> > > The reason for this is that the s3 authentication layer doesn't
> > > support AES tickets, and whether AES is used is a property of the
> > > join, not a property of the connection. So when s4 joins a domain
> > > (either as a DC or as an ordinary member), it will set itself up as
> > > supporting AES, but when the s3 auth code then tried to negotiate a
> > > kerberos based connection with a client it could not handle the
> > > resulting AES tickets.
> > 
> > As far as I remember this is only because we explicitly set the
> > supported set of enctype to DES and RC4 and exclude AES.
> > IIRC it would be very easy to just allow the use of AES keys as well by
> > changing that list.
> 
> Sadly this is not the case.  If we support AES, then we must support
> 'new' SPNEGO, which is substantially more work, and quite incompatible
> with the 'fake GSSAPI' modal of the Samba3 session setup. 
> 
> > > The fix is to allow the s3 file server to use the existing s4
> > > authentication infrastructure for kerberos. This was already possible
> > > for NTLMSSP via the existing auth_samba4 module, but it wasn't
> > > possible for kerberos due to the layering in the s3 auth code.
> > > 
> > > Andrew and I (mostly Andrew!) have put together a set of patches which
> > > allow the auth layer in s3 to use the gensec interface if it is
> > > offered by a auth module. So the auth_samba4 module sets a
> > > start_gensec method in its s3 auth module structure, and if this is
> > > set then the s3 auth layer defers to the s4 auth code for both
> > > SPNEGO, kerberos and NTLMSSP. 
> > > 
> > > This approach has the advantage that it doesn't alter the behaviour of
> > > the s3 auth subsystem when the auth_samba4 module is not loaded, so it
> > > won't have any impact on existing use cases, but it allows for the use
> > > of the s4 auth layer uniformly across all protocols when you configure
> > > a combined s3/s4 server.
> > > 
> > > In order for this to work the patch series re-arranges some of the s3
> > > auth code, while retaining existing functionality. This is needed to
> > > remove some of the layering violations in the existing code, to allow
> > > the abstraction to work.
> > 
> > Does this means the s3 code will now depend on both ldb and the heimdal
> > embedded in s4 and other dependencies ? Or are they loaded only at
> > runtime and only if a AD DC setup is used ?
> 
> This is a runtime only change.  If pdb_samba4 is loaded, then this code
> is used.  Otherwise, quite deliberately, the intention is that behaviour
> is unchanged.
> 
> > > The patches are in the s3-auth-gensec in git://git.samba.org/abartlet/samba.git
> > > 
> > > I've looked at these changes pretty carefully and I'm happy that they
> > > are OK, so we plan on pushing these soon if there are no objections. I
> > > think this is an important step towards releasing Samba 4.0 with a
> > > fully functional file server based on the current s3 file server code.
> > 
> > I'd like you to give quite some time to review and decide if it is ok.
> > I have been opposed on introducing gensec in s3 for a few reasons. One
> > is dependencies, the other is that IIRC gensec does not create new event
> > loops bu allows nesting of loops. That is something too dangerous for
> > the file server imho.
> 
> The file server event loop is not involved in GENSEC.  pdb_samba4
> creates a new event loop for GENSEC.  This is no different to the
> existing pdb_samba4 code which already created a private event loop, and
> is used for exactly the same reasons.
> 
> The main file server event loop will simply block while GENSEC is being
> called for NTLMSSP authentication, just as it does now.
> 
> I hope this helps address your concerns.  

It does alleviate them, thanks.

Simo.

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