Hi all, i post that here, so it's not getting lost. :-) Most of the background info has already been posted - see: http://lists.samba.org/archive/samba-technical/2007-September/055549.html During handling of reply_sesssetup_and_X () the LM password hash is deleted, so no further logins will succeed, until a new password is (manually) supplied. Tried to debug that behaviour with my really very limited knowledge of the 'whole samba auth specifics' - just somewhat followed and analysed the call tree... and gave up after hours. I see no easy solution to avoid the LM hash deletion - probably a more experienced developer could. Just some notes from abartlet on irc: 09/19/07 5:33:50 <abartlet> the issue is that once an OS/2 client accesses the server, it reads in the password, sets the lanman password to NULL (to ensure it is not used), then finds the client can't authenticate 09/19/07 5:34:08 <abartlet> so, it calls pdb_update_sam_account() to ensure updated 'bad password count' is written 09/19/07 5:34:22 <abartlet> which writes out the XXXX password 09/19/07 5:34:43 <abartlet> all of the steps make sense on their own, but in sequence, it kills your LM passwords If no solution is found - that behaviour should be noted in the release notes! In networks, where lanman auth clients are running, lanman auth = Yes should be added *explicitly* to the [global] section of smb.conf _before_ such a new samba version is installed and started! Btw - also the implications of the new "client lanman auth = No" should be described. Cheers, Guenter
This is a tricky one. We need to have a way to update the bad password count (if we should count a disabled LM-only login as such) without calling pdb_update_sam_account().
Created attachment 2932 [details] Set the smbpasswd backend to return "not implemented" for the update_login_account Please test. Thanks.
Hi Jerry, did test your patch against - passdb backend = smbpasswd - passdb backend = tdbsam - ??? (not tested) All seems to work fine now! :-) The Lanman hash is no longer _deleted_ (!) - but the legacy clients now get "access denied" (as expected) - which should be noted in the upcoming release notes! Admins which have legacy clients inside their network should now explicitely add lanman auth = Yes to smb.conf! Same with new default client lanman auth = No Admins which have legacy _SERVERS_ inside their network should now explicitely add client lanman auth = Yes to smb.conf Otherwise, all samba client tools - and mounting smbfs and cifs - would not work anymore against legacy servers! Cheers, Guenter
(In reply to comment #3) > Hi Jerry, > > did test your patch against > - passdb backend = smbpasswd > - passdb backend = tdbsam > - ??? (not tested) > > All seems to work fine now! :-) Cool. > > The Lanman hash is no longer _deleted_ (!) - but the > legacy clients now get "access denied" (as expected) - which > should be noted in the upcoming release notes! Already there.