[Samba] Inconsistency with LANMAN1 and Samba 4.9

[Jeremy Allison]

On Fri, May 31, 2019 at 06:32:56PM +0200, Andreas Reichel via samba wrote:
> Dear samba team,
> 
> I have a lot of hobby projects including old PCs. I wanted to hook up a Win3.11 machine to my current
> Arch-Linux Workstation running samba 4.9.4.
> 
> I have used the following configuration:
> 
> [global]
> 	workgroup = HOMEBASE
>  	netbios name = Orcane
> 	wins support = Yes
> 	client signing = No
> 	domain master = No
> 	lanman auth = Yes
> 	log file = /var/log/samba/%m.log
> 	max log size = 50
> 	name resolve order = host lmhosts wins bcast
> 	passdb backend = smbpasswd
> 	preferred master = Yes
> 	security = USER
> 	server signing = No
> 	server string = Orcane Cortex Gateway
> 	smb passwd file = /etc/samba/smbpasswd
> 
> [homes]
> 	browseable = No
> 	comment = Home Directories
> 	read only = No
> 
> 
> [printers]
> 	browseable = No
> 	comment = All Printers
> 	path = /var/spool/samba
> 	printable = Yes
> 
> 
> [win311]
> 	comment = File transfer1
> 	guest ok = Yes
> 	path = /win311
> 	read only = No
> 
> ---
> 
> Fact is, for Windows 3.11, I need lanman authentication.
> The following problems arose:
> 
> 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.