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? Kind regards Andreas
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.
On 31.05.19 18:47, Jeremy Allison wrote:> 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.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.