Bug 537 - Incorrect behaviour on 'long' (14 character) passwords
Incorrect behaviour on 'long' (14 character) passwords
Status: CLOSED FIXED
Product: Samba 3.0
Classification: Unclassified
Component: User/Group Accounts
3.0.0
All FreeBSD
: P2 major
: none
Assigned To: Andrew Bartlett
:
: 1210 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2003-09-30 07:36 UTC by Alex Deiter
Modified: 2005-08-24 10:19 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Deiter 2003-09-30 07:36:29 UTC
I cannot change user password (with ctrl+alt+del from w2k) if my OLD password > 
14 symbols:

  smbldap_search_suffix: searching for:[(&(uid=tiamat)
(objectclass=sambaSamAccount))]
[2003/09/30 18:14:39, 2] passdb/pdb_ldap.c:init_sam_from_ldap(462)
  init_sam_from_ldap: Entry found for user: tiamat
[2003/09/30 18:14:39, 3] smbd/sec_ctx.c:pop_sec_ctx(386)
  pop_sec_ctx (65534, 65534) - sec_ctx_stack_ndx = 1
[2003/09/30 18:14:39, 0] smbd/chgpasswd.c:check_oem_password(827)
  check_oem_password: incorrect password length (-1274909167).

With smbpasswd it works:

# smbpasswd -U tiamat -r server
Old SMB password:
New SMB password:
Retype new SMB password:
Password changed for user tiamat on server.

I run samba CVS 3.0.1pre1 on FreeBSD sparc64.

Thanks!
Comment 1 Alex Deiter 2003-09-30 22:36:49 UTC
I check this bug with samba CVS 3.0.1pre1 on FreeBSD 5.1 (sparc64 and i386).
Samba act as PDC with ldapsam backend.

I cannot change user password from Win2k workstations with ctrl+alt+del, if
length of the current password is more than 14 symbols.

My steps:
1. set user password to 'passwd'.
2. login to Win2k workstation, press alt+ctrl+del and success change
password from 'passwd' to 'verylongpassword'.
3.again alt+ctrl+del and try change password from 'verylongpassword' to
'passwd' - get error:
The User name or old password is incorrect. Letters in password must be
typed using the correct case. Make sure that Caps Lock is not accidentaly
on.

In samba logs (i try i386 and sparc64) i see same errors:

[2003/10/01 09:09:16, 0] smbd/chgpasswd.c:check_oem_password(827)
  check_oem_password: incorrect password length (456509439).

i can successfully change the user password with smbpasswd -U user -r server
(server i386 or sparc64):

$ smbpasswd -U user -r server
Old SMB password: verylongpassword
New SMB password: passwd
Retype new SMB password: passwd
Password changed for user user on server.

Thanks!

Comment 2 Andrew Bartlett 2003-11-08 14:07:33 UTC
From what I understand, Win2k handles long passwords by simply not using the LM
password at all.  It is not included in the password change request, and not
stored in the SAM.

We check the LM password first, and trucate long passwords.  This is the
incorrect way to handle this, and causes this error.
Comment 3 Gerald (Jerry) Carter 2003-12-12 08:27:44 UTC
reseting target milestone.  3.0.1 has been frozen.  WIll have to 
re-evaluate these.
Comment 4 Gerald (Jerry) Carter 2004-02-09 09:22:47 UTC
fixed in latest 3.0 CVS code
Comment 5 Alex Deiter 2004-02-09 12:33:25 UTC
samba 3.0.2 include fix ?

Thanks a lot!
Comment 6 Andrew Bartlett 2004-02-09 12:52:01 UTC
This is not in 3.0.2, but in 3.0 CVS (we branched the code to avoid taking this
patch).

There are still some more '14 char' issues to sort however...

 - Ensure we do not send the (weak, 14-character effective length) password as a
   client
 - Fix smbpasswd to talk to a Samba server, with correct NTLMSSP for the NULL
   user session.
 - Don't use the LanMan password change for >14 passwords.

Andrew Bartlett
Comment 7 Andrew Bartlett 2004-03-09 05:49:03 UTC
Whenever we are after an LM password we need to call

E_deshash() directly, and if the BOOL return is False, then the password has
been truncated.  We can't strlen it directly, as we need the length in the DOS
charset.

Most of samba calls other 'helper' functions, like nt_lm_owf_gen() and
SMBencrypt, and this needs to be fixed.
Comment 8 Gerald (Jerry) Carter 2004-03-23 15:14:11 UTC
*** Bug 1210 has been marked as a duplicate of this bug. ***
Comment 9 Andrew Bartlett 2004-07-25 05:21:18 UTC
Patch for the final issue here is in SVN (don't use a null session, and avoid
that complexity).
Comment 10 Gerald (Jerry) Carter 2005-08-24 10:19:36 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.