[PATCH] support for kerberos in plugin DC code

[Andrew Bartlett]

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.  

Andrew Bartlett

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