[Samba] Inconsistency with LANMAN1 and Samba 4.9

[Andrew Bartlett]

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

-- 
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba