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

[Kai Blin]

On Tuesday 04 July 2006 14:01, Andrew Bartlett wrote:

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

Ok, my suggestion here would be this.

For the ntlm client mode of ntlm_auth, we extend it as follows:

YR [flags]    <-- The requested flags from the application
OK [flags and key] <-- negotiated flags and session key

(on a side note, should that go into the ntlmssp-client-1 helper mode or into 
a new ntlmssp-client-2 mode that is like ntlmssp-client-1 but with those new 
features?

I think I'll first have a go at encryption/signing from within Wine, and try 
to spin it out as a separate library once I know what is needed.

Does this sound reasonable?

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

We might want to look into that later, but I guess the correct way to do that 
is to interface with whatever credentials cache we want to use from the LSA 
code.

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

Unfortunately I neither have Outlook nor Exchange myself, but I'll see if I 
can arrange for a test setup there, somehow.

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

This doesn't fully parse for me, but I assume you don't want to open up the 
authentication code...

Cheers,
Kai

-- 
Kai Blin, <kai Dot blin At gmail Dot com>
WorldForge developer    http://www.worldforge.org/
Wine developer          http://wiki.winehq.org/KaiBlin/
--
Will code for cotton.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20060705/59415807/attachment.bin