[PATCH] Generalise auth_ntlmssp in s3

[Andrew Bartlett]

On Thu, 2011-12-22 at 13:44 +0100, Stefan (metze) Metzmacher wrote:
> Hi Andrew,
> 
> > This patch series generalises the auth_ntlmssp code into a more generic
> > infrastructure, with the aim to have GSSAPI handled via GENSEC in the
> > smb sealing, rpc server and eventually session setup code.  
> > 
> > The patches so far are just the start, but take a very measured, one
> > small change at a time approach without intentional behaviour change,
> > and are at: 
> > http://git.samba.org/?p=abartlet/samba.git/.git;a=shortlog;h=refs/heads/s3-rpc-gensec
> 
> Thanks! I plan to sign-off and push this too.
> 
> > Handling GSSAPI via GENSEC is important in order to finish the s3/s4
> > integration efforts, so that the spoolss server is available with GSSAPI
> > authentication in such a combined DC build.  
> > 
> > To achieve that, I will first wish to build a gensec wrapper for the
> > 'gse' layer currently in use.  Once this works, the existing hooks will
> > simply redirect to the s4 gensec modules when in the AD server mode as
> > they already do for NTLMSSP.
> > 
> > This will also simplify the smb sealing code (which will then only deal
> > with gensec), and in the longer term allow us to use real GSSAPI for
> > session setup handling (rather than the current fake GSSAPI). 
> 
> It would be really nice if could hide most of the
> source3/smbd/sessetup.c spnego code
> behind a gensec backend. I think the chunk fragmentation for large krb5
> blobs
> should be handled inside the module.

The SPNEGO code certainly is the biggest challenge here.  Once we get
the kerberos code behind GENSEC, I would like to experiment with using
the Samba4 SPNEGO code, as it already knows about signing the
mechListMIC and can handle arbitrary modules.  We could pass in the
possible modules via the gensec_settings parameter. 

> I'm currently trying to change the register_*_vuid code from
> source3/smbd/password.c
> to use a smbXsrv_session structure, which can be used for smb1 and smb2
> as a replacement for the current struct smbd_smb2_session.

That certainly sounds like a challenge.  I did notice the 'compat'
layers in there that really cry out for this kind of re-factor. 

> > Merry Christmas!
> 
> :-)
> 
> metze
> 

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