NTLM authentication not working

Michal Bruncko michal.bruncko at zssos.sk
Thu Apr 16 06:30:33 EDT 2020


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 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>



More information about the Cyrus-sasl mailing list