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> -- Simo Sorce RHEL Crypto Team Red Hat, Inc
