Really odd behaviour on a Debian/Squeeze system: when users change their password from within Windows, everything works fine (i.e. passdb.tdb is updated and /etc/shadow as well via password sync, the user can log in on both systems). When I try to assign a new password via smbpasswd (or create a new user, which causes the real problem), /etc/shadow is updated properly (unix logins are possible), but users CANNOT login with windows anymore (though the timestamp of passdb.tdb is updated, so smbpasswd DOES something there). I have to reassign the old password with smbpasswd and to change it via windows to re-enable login for this user. What can cause such a behaviour? I never had trouble in THIS direction before - only the other way round... but what can make smbpasswd store a wrong(?) password in its native database? Lines of smb.conf I consider relevant: domain master = yes domain logons = yes security = user encrypt passwords = true passdb backend = tdbsam obey pam restrictions = yes unix password sync = yes passwd program = /usr/bin/passwd %u passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* . pam password change = yes If you need any more details, please ask. Bye, Stefan
On Wed, Sep 28, 2011 at 11:20:10AM +0200, Stefan Froehlich wrote:> When I try to assign a new password via smbpasswd (or create a new > user, which causes the real problem), /etc/shadow is updated properly > (unix logins are possible), but users CANNOT login with windows > anymore (though the timestamp of passdb.tdb is updated, so smbpasswd > DOES something there).Perhaps I'll supply an experiment do illustrate this: unix login works with password foo windows login works with password foo herkules:~# pdbedit -L -w sfroehli [returns hash value FOO] Changing password from within windows to bar herkules:~# pdbedit -L -w sfroehli [returns hash value BAR] unix login works with password bar windows login works with password bar herkules:~# smbpasswd sfroehli [assign password foo] herkules:~# pdbedit -L -w sfroehli [returns hash value FOO] unix login works with foo windows login does NOT work (neither with foo nor with bar) herkules:~# smbpasswd sfroehli [assign password bar] herkules:~# pdbedit -L -w sfroehli [returns hash value BAR] unix login works with password bar windows login works with password bar Changing password from within windows to foo herkules:~# pdbedit -L -w sfroehli [returns hash value FOO] unix login works with password foo windows login works with password foo I think this covers all possible transitions - and still completely puzzles me. Bye, Stefan
On Wed, Sep 28, 2011 at 11:20:10AM +0200, Stefan Froehlich wrote:> When I try to assign a new password via smbpasswd (or create a new > user, which causes the real problem), /etc/shadow is updated properly > (unix logins are possible), but users CANNOT login with windows > anymore (though the timestamp of passdb.tdb is updated, so smbpasswd > DOES something there).Perhaps I'll supply an experiment do illustrate this: |unix login works with password foo |windows login works with password foo | |herkules:~# pdbedit -L -w sfroehli |[returns hash value FOO] | |Changing password from within windows to bar | |herkules:~# pdbedit -L -w sfroehli |[returns hash value BAR] | |unix login works with password bar |windows login works with password bar | |herkules:~# smbpasswd sfroehli |[assign password foo] |herkules:~# pdbedit -L -w sfroehli |[returns hash value FOO] | |unix login works with foo |windows login does NOT work (neither with foo nor with bar) | |herkules:~# smbpasswd sfroehli |[assign password bar] |herkules:~# pdbedit -L -w sfroehli |[returns hash value BAR] | |unix login works with password bar |windows login works with password bar | |Changing password from within windows to foo | |herkules:~# pdbedit -L -w sfroehli |[returns hash value FOO] | |unix login works with password foo |windows login works with password foo I think this covers all possible transitions - and still completely puzzles me. Bye, Stefan