[Samba] Inconsistency with LANMAN1 and Samba 4.9

[Andreas Reichel]

On 31.05.19 22:59, Andrew Bartlett wrote:
> On Fri, 2019-05-31 at 22:33 +0200, Andreas Reichel via samba wrote:
>> On 31.05.19 22:07, Andrew Bartlett wrote:
>>> On Fri, 2019-05-31 at 11:40 -0700, Jeremy Allison via samba wrote:
>>>> On Fri, May 31, 2019 at 07:09:44PM +0200, Andreas Reichel wrote:
>>>>>>> When adding me as the user with 'smbpasswd -a andreas', and entering a password,
>>>>>>> no LANMAN hash is generated. The generated smbpasswd entry always contains 32 X as the first hash.
>>>>>>>
>>>>>>> When I do the same with Samba 4.3.11-Ubuntu, the hash IS generated correctly.
>>>>>>>
>>>>>>> When I manually add the hash in 4.9.4, I still cannot connect from Win 3.11 and always get access denied.
>>>>>>>
>>>>>>> In 4.3.11, it works flawlessly, I can connect from Windows 3.11 without any problem.
>>>>>>>
>>>>>>> Question: Is this intended? And if yes, why are there all these options still settable?
>>>>>> You may be running into this code in passdb:
>>>>>>
>>>>>> bool pdb_set_plaintext_passwd(struct samu *sampass, const char *plaintext)
>>>>>> {
>>>>>> ...
>>>>>>            if (!E_deshash(plaintext, new_lanman_p16)) {
>>>>>>                    /* E_deshash returns false for 'long' passwords (> 14
>>>>>>                       DOS chars).  This allows us to match Win2k, which
>>>>>>                       does not store a LM hash for these passwords (which
>>>>>>                       would reduce the effective password length to 14 */
>>>>>>
>>>>>>                    if (!pdb_set_lanman_passwd (sampass, NULL, PDB_CHANGED))
>>>>>>                            return False;
>>>>>>            } else {
>>>>>>                    if (!pdb_set_lanman_passwd (sampass, new_lanman_p16, PDB_CHANGED))
>>>>>>                            return False;
>>>>>>            }
>>>>>> ...
>>>>>>
>>>>>> Is the password greater that 14 characters ? If so, looks like
>>>>>> we won't store it.
>>>>> No, it has 8 characters. And I tried to enter the hash manually into the
>>>>> smbpasswd, which didn't work either. It is as if samba 4.9.4 would
>>>>> ignore lanman completely.
>>>> Hmmm. Sounds like a bug. Are you able to use gdb to
>>>> walk through the call stack to debug ?
>>>>
>>>> If not someone here will do it, but you might have
>>>> to wait a while (log a bug at bugzilla.samba.org
>>>> so we can track it) as getting LANMAN auth working
>>>> is low priority (it's completely insecure I'm afraid).
>>> We honour 'lanman auth' and don't store it if set, but that much has
>>> been the same for a long time, but if the hash is being injected
>>> manually that won't be it.
>>>
>>> It might be further up the stack, like requirements for SPNEGO, ntlmv2
>>> etc.
>>>
>>> Andreas,
>>>
>>> Can you post your smb.conf and check your logs for helpful messages?
>>> (turn up the log level until you get some).
>>>
>>> Thanks,
>>>
>>> Andrew Bartlett
>> Hi Andrew, I have already posted my config :) As a first step, I think
>> we have to understand why
>>
>> smbpasswd does not generate the hash on 4.9.4 but does it on 4.3.11.
>>
> Samba 4.7 changed 'lanman auth' to first honour 'ntlm auth', so you
> must set that as well.
>
> I'll prepare a documentation update.
>
> I've also confirmed that lanman passwords are still generated in our
> test environment.
>
> Andrew Bartlett


Thank you very very much :D This is really non-trivial. Since Win311
does not understand ntlm,

the logical step was to disable it. When I enable it, lanman works :D