proper nt-style authentication (reactos, wine, samba tng)

Luke Kenneth Casson Leighton lkcl at
Fri Sep 2 19:09:47 CDT 2005

andrew bartlett, your sarcasm is totally inappropriate, and
you are completely out of line, and you damn well know it.
get a grip, and if you cannot do so, do not embarrass yourself
or the reputation of the samba team, which you represent by
utilising a "" email address, by replying at all.

i also cannot reply and tell you this because of a decision
made on the 15th december 2004 by the samba team to block all
email sent by me to and to treat any such attempts as
"net abuse".

if you pick up this message on the mailing lists i hope that
you will, should you wish to make useful contributions to
this discussion, provide a suitable email address to which i
can reply.

anyway: in order to move discussions _forward_ rather than put
it on an actively hostile footing, i will rewrite your message
in a more appropriate manner and i trust that this meets with
your approval.

i will then reply to it.

	"dear luke,

	 thank you for raising this issue.  your message is a
	 bit long, so i will skip most of it and mention just
	 one thing.

	 i trust that you are aware that NTLM authentication has
	 been provided for quite some time to external services,
	 in a number of ways.  as you helped design one of those
	 methods (the winbind_auth_crap :) and guided tim in its
	 implementation, i am puzzled by the fact that it was not
	 mentioned in your message.

	 there is also an additional method which has been
	 developed in samba 3, called ntlm_auth, which has even
	 been utilised by a SOC Google student.

	 both these methods avoid reimplementation of NTLMSSP:
	 what therefore are you proposing that is, if at all,
	 different from this?  i don't understand: perhaps you
	 could explain?

	 anyway, it is good to hear from you and your design
	 input even if it is a little bit mad is always welcome.

	 best regards,

	 andrew bartlett."

now, pretending that you have written the above paragraphs
instead of the ones below, i will proceed.

without sarcasm and without endeavouring to be totally and
blatantly and unnecessarily cruel.

dear andrew,

thanks for replying,

okay.  i re-read my message several times and i _knew_ i had missed
something out - explicitly mentioning winbind.


and no, i wasn't aware of ntlm_auth: it's good to hear of that because
yes it might prove useful.

no, of course i am not advocating that NTLMSSP be reimplemented:
i will clarify this later in this reply.

i should be clear (and this will help rob as well) that the specific
focus of my message was directed towards _reactos_ not towards wine (per
se).  the requirements are therefore quite different.

yes, for _wine_ - you (and rob) are absolutely correct: ntlm_auth and
winbindd are perfectly adequate.

the reason why?  samba can be run ON THE SAME MACHINE.  samba is a unix
service: wine is a win32 emulation layer running _on unix_.

the reason why that is inappropriate for reactos?  samba cannot run on a
win32 platform.  therefore any attempt to contact a unix service will
require implementation of a POSIX subsystem in reactos as a primary

... oops :)

it's that straightforward.

there is also a second difference (which isn't anything to do with what
you mention - use of winbind or ntlm_auth) which is to do with the
implementation: in reactos, things have to be done "properly" in this
area (authentication) - and that means implementing an LSASS (lsa
security service) MSV1_0.DLL and registering it with the LSASS running

i do not know what has been picked / decided upon for Wine, but for
reactos MSV1_0.DLL is definitely the way forward.

what else is relevant that i may have missed... oh, yes: samba tng's

i added an extra "method" to winbindd, which was required for freedce's

winbindd pre-modifications (and therefore also the version in samba
afaik) does not contain a means to utilise NT+LM hashes plus domain name
in unicode plus username in unicode, and it most certainly doesn't
return a NET_USER_INFO_3 structure.

this is an absolute critical requirement for "authorisation"
purposes - not least because the NET_USER_INFO_3 structure,
as you are undoubtedly aware (but others might not be so i
mention it for completeness), contains the 16-bit "session key".
it also contains the group SIDs etc. which are again essential
to be returned to the LsaLogonUser (and LsaLogonUserEx)
functions - see lsa.c in ReactOS code.

so, anyway, this is what i added to samba tng's winbindd and also to a
client-side function which freedce's module could then

i do not know what nltm_auth does so i could not advise you as to
whether it would be appropriate: perhaps you could help out by pointing
people to some appropriate documentation on the ntlm_auth API, in order
to evaluate whether it would be suitable (possibly even for reactos: i
won't know until i see the API)

okay.  what else.

oh, yes.  the use of ntlm_auth and/or winbindd to "outsource"
authentication is, i believe, a "temporary" measure, that allows
the parallel development and maturisation of Wine / ReactOS
specific code (in the case of ReactOS, that's MSV1_0.DLL)
_without_ having to pull in a shed-load of code.

the API is basically this: send (in unicode) a plaintext
password, a domain name and a username, and receive a yes/no
answer along with a NET_USER_INFO_3 structure, from which the
session key and group sids can be "pulled".

there's also the second function LsaLogonUserEx which is i believe
"send NT+LM hashes, plus unicode domain name, unicode username, and
receive..." but it would take a little reverse-engineering to

so yes, in conclusion, i believe that the use of ntlm_auth
and/or winbind _may_ be appropriate for Wine, is temporarily
appropriate for proof-of-concept in ReactOS, but for final
code in ReactOS, definitely not.

that's the gist: hope this helps clarify things.


On Fri, Sep 02, 2005 at 11:25:36PM +1000, Andrew Bartlett wrote:

> On Fri, 2005-09-02 at 01:39 +0100, Luke Kenneth Casson Leighton wrote:
> I will leave the rest of this mail well aside, but I just wanted to
> clarify exactly how long we have been providing NTLM authentication
> services to external projects:
> > 2) write a lovely insecure method of "outsourcing" the username,
> > domain and password to an external server - Samba TNG - which performs
> > the authentication on your behalf and gets back "real" data.
> > 
> > this could be done simply with a TCP connection, throw the data
> > in-the-clear over to a simple temporary shim service blah blah,
> > bob's your uncle.
> Like, say the winbind_auth_crap (thank Mr Potter for the name) function
> in Samba's winbindd client interface, used successfully by external
> projects (Squid in particular) since Samba 2.2?  
> Or better still (avoiding reimplementing NTLMSSP) by calling ntlm_auth
> (shipped with Samba 3.0 since release)?  Oh wait, we hooked up a Google
> SOC student to do just that, and it's working well! :-)
> Andrew Bartlett
> -- 
> Andrew Bartlett                      
> Samba Developer, SuSE Labs, Novell Inc.
> Authentication Developer, Samba Team 
> Student Network Administrator, Hawker College

<a href=""></a>

More information about the wine-devel mailing list