Getting Wine to do NTLMSSP authentication and what is needed on
the Samba side
kai.blin at gmail.com
Wed Jul 5 10:26:45 GMT 2006
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
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
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
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
> 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
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
Size: 189 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20060705/59415807/attachment.bin
More information about the samba-technical