Getting Wine to do NTLMSSP authentication and what is needed on the Samba side

[Andrew Bartlett]

On Mon, 2006-07-03 at 11:54 +0200, Stefan (metze) Metzmacher wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Kai Blin schrieb:
> > Looking at those requirements and talking to a couple of people in 
> > #samba-technical, I see a couple of possible solutions and I depend on your 
> > help for most of them.
> > 
> > 1) Spin out the minimal functionality GENSEC library and find a method to 
> > handle server side functionality later. This approach has the downside that I 
> > will be deleting some of the functionality I currently have in Wine, as 
> > ntlm_auth can do server side authentication. On the plus side, it seems that 
> > ntlmssp_server is the part that would be tricky to LGPL, client side seems 
> > easier. I could also keep the old ntlm_auth code around for server side 
> > authentication, which would add bloat to the Wine source, though.
> > 
> > 2) Scratch the current approach using GENSEC and add handling of NTLMSSP blobs 
> > to winbind. This would possibly go into Samba 3, and thus be part of a 
> > distribution's Samba package sooner. It would also mean that there is a nice 
> > IPC border between the GPL and the LGPL code, so no problems there. I would 
> > need to rewrite that part of Wine yet again, though.
> 
> I would vote for a combination of 1) and 2)
> 
> I think we should only pass authentification blobs to winbind,
> so that ntlmssp_server.c works with a generic backend,
> the current one to samba's auth subsystem.
> 
> and one that passes the blob's from gensec_update() to winbind
> 
> but the sign and seal should be part of the LGPL'ed library,
> as asking winbind for each packet for en/decrypting would be bad!

I've been thinking about this, and talking with some other team members.
I think there is a lot of value is having winbindd as the local LSA-like
thing.  That is, for other reasons we are starting to stash the password
at logon time.  (And winbind is required for the server-side).

What has worked very well in the past has been ntlm_auth, as a long-term
interface.  Being a binary has helped a lot, but this is impractical for
sign/seal interfaces. 

Perhaps this is a solution:  We extend ntlm_auth to simply spit out the
keys, and the negotiated flags.  Then, a small library can turn that
into a signed/sealed stream, if required.  That library could even be
GENSEC (without the normal modules, but with a glue-to-ntlm_auth
module).

ntlm_auth as a client would not require winbindd, unless you wanted
single-sign-on. 

One thing I should make clear:  We should aim for solutions that don't
ask the Samba team to wholesale relicence code, but instead show maximum
bang-for-buck.  That is, showing a working solution with Outlook doing
encrypted RPC to exchange is very valuable.  Showing that 'we only need
these small parts' is even more valuable. 

I don't want to lock up our authentication code, as it is valuable.  It
has taken us many years to get here, and we should be able to show
exactly what we gained for relaxing any conditions on this.  

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20060704/8668f648/attachment.bin