3 Sep
2005
3 Sep
'05
12:09 a.m.
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 "samba.org" 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 samba.org 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.
sorry!
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
requirement!!!
... 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
in NTOSKRNL.
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
winbindd.
i added an extra "method" to winbindd, which was required for freedce's
"ntlmsspauth.so".
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 ntlmsspauth.so module could then
use.
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
double-check.
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.
l.
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:
--
--
<a href="http://lkcl.net">http://lkcl.net</a>
--
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 http://samba.org/~abartlet/
Samba Developer, SuSE Labs, Novell Inc. http://suse.de
Authentication Developer, Samba Team http://samba.org
Student Network Administrator, Hawker College http://hawkerc.net