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.
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). Jeremy.
On 31.05.19 20:40, Jeremy Allison 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). > > Jeremy.Okay, I am relieved you say it sounds like a bug. If it is not important to the group, I can surely take a debug session, but I don't know when I have time for it. I will log a bug, thanks so far. Andreas
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 -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba