Restting password for a user with and Administrator account

Hi to all. I am running OpenEMR 6.0 with the patches. Today, and this is the second time, for some unknown reason, I was unable to login as a user/provider using an unexpired, current password. It happened before, and I had to create another user for the same provider because I was unable to get the reset password to work, which messes up the provider id etc. The fact is, although I have my administrator account able to login, if I change the user’s password using Adminstation->Users-> selecte user to change -> and reset the password using the “current administrator’s password” in its field and which is masked and not visible, it appears that the password is changed when pressing the save button, yet, when logging in again as the user using the new password, I get a wrong user or password message and I am unable to login. Is there any way to recover the login ability of the user?.

Thanks

hi @jfuenmayor, you can use

UPDATE users_secure SET `password` = '$2a$05$MKtnxYsfFPlb2mOW7Qzq2Oz61S26s5E80Yd60lKdX4Wy3PBdEufNu' WHERE `username` = 'admin'

for example to update the admin user to password pass

Hi Stephen, once again, thank you for the input. This is the thing, I have a test install of openemr in a separate computer with the same data. I was able to recover one account in the test computer but when I do the same thing in the production computer I continue to be unable to login in the account. This seems a bit strange to me. Does openemr look at any other parameter besides the encrypted password in the users_secure table?.

check your Minimum Password Length in Globals->Security

Golly, I was just about to try that. Thanks

I also noted that you single quoted ‘password’ and ‘username’. It gives an error when using it, as it probably should. I also checked the password after i entered the command and it shows the correct password. Still I am unable to login. I reduced the number of require characters to 4 and unchecked require strong password. No luck. Why did work in one account and not the other?. That is intriguing

hi @jfuenmayor, are you using ' sometimes the forum posts tweak quotes/apostrophes

Hi,

I’m not sure why this is not working for me :frowning: also I saw other post that have the column salt on the users_secure mine does not so your solution should work unless I do have so set up a salt and I dunno where that column is any ideas are welcome, thanks.

This can effect outcome with password insert. Try to use the password length from working passwords.

Change the min length globals table. gbl_minimum_password_length

Hi,
Did check the table. gbl_minimum_password_length in fact it was on 9 as the new default. I change it to 4 because I’m trying to reset to the original “pass” but still not working, is the salt not store on users_secure table anymore or not used at all on the newest versions? Any help is much appreciated, thanks.

hi @Carlos_Andres_Chavez, right, no salt.

All of my users are still locked out the system, is there a inactive field or anything of that. Or could I enable the password reset feature or maybe insert and admin user directly and see.

hi @Carlos_Andres_Chavez, yes, there’s an active field

Hi @stephenwaite where can I find this field? I don’t see it in users_secure

hi @Carlos_Andres_Chavez, it’s in users

@Carlos_Andres_Chavez
Do you remember or ask your users if a Globals save was done where they may have been kicked to login screen. Or even suddenly kicked to login at anytime.

I just blew up all my users trying to debug your issue!

Update: I don’t think this issue is caused by user password corruption. Check PHP error log and report.

Do you think this could be related to my globals blowing up recently on the stress testing I was doing?

Definitely! I’m still tracking it down but first looking at a way to give @Carlos_Andres_Chavez a recovery for his dilemma.
You and me should talk about a plan for this issue!

I had to recover my system by using a backed up copy of the globals table. I don’t know if that is the problem you are running into @Carlos_Andres_Chavez, but if so, you could try doing that.

Hi there, Client agreed to a new install. I feel bad that you blew up your users but glad that you discovered that so that it can be addressed in the future.