[PATCH] support for kerberos in plugin DC code

[simo]

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.

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


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

Simo.

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