Web lists-archives.com

Re: [Samba] Inconsistency with LANMAN1 and Samba 4.9





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



--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba