Hello Simo
even better approach! thanks for your response. I agree with fact that
ntlm_auth requires samba layer installed on same system which could be
unneccessary if its required just for doing NTLM.
> Finally, we already have GSS-SPNEGO in SASL so not sure what you mean
at the end of your message here.
Andrew's patch (https://bugs.gentoo.org/81342) contains support for this
mechanism in form of new module for SASL named "GSSSPNEGO" which again
uses Samba layer to make it work. But again, this is not important.
In sum from usage perspective any improvement intiative for NTLM plugin
would be better than existing state with only NTLMv1 support.
regards
michal
On 4/15/2020 3:38 PM, Simo Sorce wrote:
Hi Michal,
I have a fully working implementation of NTLM, that follows Microsoft's
spec faithfully and with proper testing, and also allow to configure
what is allowed and what isn't.
It is implemented as a GSSAPI module called GSSNTLMSSP:
https://github.com/gssapi/gss-ntlmssp
We can simply remove NTLM code entirely and just write a wrapper that
will use GSSNTLMSSP instead. This will relieve Cyrus-sasl from the need
to deal with this old broken protocol and defer it to an external
party, at the same time gaining a more tested, and better working
implementation.
Note that GSSNTLMSSP also provide a few advantages to users as it can
be integrated with Winbind and potentially other backends on a server
so that authentication will work in a Windows Domain w/o the need to
host lists of passwords for users on the individual servers.
I would avoid ntlm_auth (I am an historical Samba Team member so I know
it well), simply because it will remove features, namely that you won't
be able to just have a simple list of passwords on a system w/o having
to install all of samba and make it run. For small setup that's really
overkill.
Finally, we already have GSS-SPNEGO in SASL so not sure what you mean
at the end of your message here.
Note that GSSAPI will fallback to use GSSNTLMSSP *already* within
SPNEGO if available on the system (we used that in mod_auth_gssapi all
the time for example, as well as in Firefox actually), although I
haven't checked if cyrus-sasl code will work correctly in that case
yet.
Simo.
On Wed, 2020-04-15 at 01:39 +0200, Michal Bruncko wrote:
since the NTLMv1 is considered as completely insecure
(https://bugzilla.mozilla.org/show_bug.cgi?id=828183) I would agree with
that as many applications (incl my case with Mozilla's stuff
Thunderbird/Firefox) no longer work natively with NTLMv1 without doing
additional config changes (network.auth.force-generic-ntlm-v1 set to TRUE).
the question is what will remain in NTLM SASL subtree after removing
NTLMv1? Is the existing NTLM SASL implementation fully supporting
NTLMv2? I spent some time with debugging this but I wasn't able force
NTLM SASL module to provide NTLMv2 between the client and authenticator
(SambaAD/PDC) no matter whether I've set "yes" to sasl_ntlm_v2
(imapd.conf) or ntlm_v2 (for postfix) respectively or manually "enforce"
NTLMv2 based on patch from https://access.redhat.com/solutions/4253821 .
I was always forced to enable ntlm v1 authentication on samba side (ntlm
auth = yes) to make the NBT session progressing and not being refused by
authenticator.
For me the less effort even for future could be with reusing Andrew's
patch (https://bugs.gentoo.org/81342) which is handing over this
authentication to winbind (ntlm_auth) and which also is the best way to
have this NTLM working in future without bigger maintenance efforts. I
can share the slightly modifed Andrew's patch which can be easily
applied against rhel/centos 7 if anybody is interested. as I wrote
before it has still some drawbacks which I hope can be even easily
managed by programmers (not my case) and used in upstream (at least) as
an alternative to current state. patch provides switch - which engine
has to be used for NTLM authentication - either cyrus (existing ntlm.c)
or samba (ntlm_samba.c, smb_helper.c) - and compiled into libntlm.so.
Patch introduces also new module GSSSPNEGO (MS Kerberos method) but this
was not tested as the existing GSSAPI SASL module works well for us.
regards
michal
On 4/14/2020 10:16 PM, Quanah Gibson-Mount wrote:
--On Tuesday, April 14, 2020 10:36 PM +0200 Michal Bruncko
<michal.bruncko@xxxxxxxx> wrote:
hello again
today I've tried two other options:
I'd think at this point it'd be best to remove NTLMv1 from cyrus-sasl
master, at least, entirely.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
