NTLM authentication not working

[Simo Sorce]

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 at zssos.sk> 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>

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc