inappropriate checking in smbpasswd when changing passwords (api_SamOEMChangePassword in smbd/ipc.c)

[James Caccese]

hi, I think I have found a small bug in the password changing routine "api_SamOEMChangePassword" in the file smbd/ipc.c and the routines it calls.


here's the behavior I observe in samba 2.0.6:

when you are using non-encrypted passwords, samba checks the username and password it gets from windows against the unix password database to logon. It doesn't even matter if you don't have an smbpasswd [file], or if the password stored in smbpasswd [file] is something completely different, the only thing that counts in getting logged in is weather the username and password you supply to windows exist in the unix password database.

that behavior is nice for people like me. I don't want to deal with password synchronization between smbpasswd [file] and passwd (unix password database), and I don't have enough of a security risk to need encrypted passwords. I would like nothing more then to not have an smbpasswd [file]. Now, I want to allow my users to be able to change their passwords. 

In both windows and unix (through smbpasswd [program] running as the user, not root) the password changing client asks for the old password. Now, here's the problem, the server checks the old password against an entry in smbpasswd [file]. This means the users can only change their password if smbpasswd [file] is kept in sync with the unix password database!

If the password files were initially in sync, and the users always change passwords through windows or smbpasswd [program], then they will never see a problem, because the password change keeps the files in sync (provided unix password sync is on and configured correctly). 

But if they ever change their password with passwd [unix password change program] they can still log in (remember samba checks logins against unix database) but they will never be able to change their password through windows or smbpasswd [program] again. The problem is smbpasswd [file] is out of sync and still contains the old password, and the password change routine requires the old password given by the client to match the one in smbpasswd [file]. It wouldn't accept the old password matching the one in the unix database, which is the one they logged in with.

I can't imagine that is what it should be doing.

I recommend that when using un-encrypted passwords, there should be nothing that uses smbpasswd [file], and that smbpasswd [file] shouldn't be required to exist. For un-encrypted passwords, changing the samba password (through windows or smbpasswd [program]) should simply update the password for the appropriate unix account. 

Also, notice that even when unix password sync is turned off, logins are still authenticated off the unix database, so unix password sync should have no effect when encrypted passwords are turned off. (currently it's effect is to demand that smbpasswd [file] and the unix passwd database be synchronized because of the before mentioned behavior)

thanks
- james

James Caccese '01
Pres: Holy Cross Computer Society
Holy Cross College
Worcester, Ma

jwcacces at holycross.edu


here's the log of a password change. Un-encrypted passwords, sync unix passwd on:

 Doing SamOEMChangePassword
[2000/04/10 18:05:43, 3] smbd/ipc.c:api_SamOEMChangePassword(1776)
  api_SamOEMChangePassword: Change password for <jwcacces>
[2000/04/10 18:05:43, 10] passdb/passdb.c:iterate_getsmbpwnam(142)
  search by name: jwcacces
                  <----- it's searching smbpasswd to be sure the old passwords match (take out)
[2000/04/10 18:05:43, 10] passdb/smbpass.c:startsmbfilepwent(45)
  startsmbfilepwent: opening file /etc/smbpasswd
[2000/04/10 18:05:43, 6] passdb/smbpass.c:getsmbfilepwent(159)
  getsmbfilepwent: skipping comment or blank line
[2000/04/10 18:05:43, 5] passdb/smbpass.c:getsmbfilepwent(258)
  getsmbfilepwent: returning passwd entry for user jwcacces, uid 500
[2000/04/10 18:05:43, 10] passdb/passdb.c:iterate_getsmbpwnam(158)
  found by name: jwcacces
[2000/04/10 18:05:43, 7] passdb/smbpass.c:endsmbfilepwent(81)
  endsmbfilepwent: closed password file.
[2000/04/10 18:05:43, 3] smbd/chgpasswd.c:chgpasswd(388)
  Password change for user: jwcacces
                 <------------ doing the unix password change
[2000/04/10 18:05:43, 10] smbd/chgpasswd.c:findpty(75)
  findpty: Allocated slave pty /dev/pts/2
[2000/04/10 18:05:43, 3] smbd/chgpasswd.c:chat_with_program(363)
  Dochild for user jwcacces (uid=0,gid=0)
[2000/04/10 18:05:43, 10] smbd/chgpasswd.c:dochild(184)
  Invoking '/usr/bin/passwd jwcacces' as password change program.
[2000/04/10 18:05:43, 100] smbd/chgpasswd.c:expect(229)
  expect: expected [*New*password*] received [Changing password for user jwcacces
  New UNIX password: ]
[2000/04/10 18:05:43, 100] smbd/chgpasswd.c:expect(205)
  expect: sending [mwbh43a
  ]
[2000/04/10 18:05:43, 100] smbd/chgpasswd.c:expect(229)
  expect: expected [*new*password*] received [
  Retype new UNIX password: ]
[2000/04/10 18:05:43, 100] smbd/chgpasswd.c:expect(205)
  expect: sending [mwbh43a
  ]
[2000/04/10 18:05:44, 100] smbd/chgpasswd.c:expect(229)
  expect: expected [*success*] received [
  passwd: all authentication tokens updated successfully
 ]
[2000/04/10 18:05:44, 3] smbd/chgpasswd.c:chat_with_program(375)
  Password change successful for user jwcacces
                     <-- unix password change successful
[2000/04/10 18:05:44, 10] passdb/smbpass.c:mod_smbfilepwd_entry(599)
  mod_smbfilepwd_entry: opening file /etc/smbpasswd
                      < ------- make changes in smbpasswd (take out)
[2000/04/10 18:05:44, 6] passdb/smbpass.c:mod_smbfilepwd_entry(677)
  mod_smbfilepwd_entry: skipping comment or blank line
[2000/04/10 18:05:44, 6] passdb/smbpass.c:mod_smbfilepwd_entry(706)
  mod_smbfilepwd_entry: entry exists
[2000/04/10 18:05:44, 5] smbd/ipc.c:copy_trans_params_and_data(156)
  copy_trans_params_and_data: params[0..2] data[0..0]