Reset Passwords of all users

[Anon Anon]

Hi,

There was this script since Clarity v8 till v12, using which we could set all users' passwords to be same as that of admin user.

update cmn_sec_users set pwd = (select pwd from cmn_sec_users where user_name='admin') where user_name not in ('admin', 'xog');

Is there any such script for v13.3 as well?

As per out set procedure, we refresh DEV and TEST from PROD every month. After that, we change passwords of all users in DEV using the above script so that we can check and simulate problems in DEV that the users are facing in PROD.

This was our first time after upgrade from v12.1.1 to 13.3 that we refreshed  the DEV and TEST from PROD. After we executed the above script, we are not able to login by any user except 'admin' and 'xog'.

Please let us know how to reset passwords of all users in v13.3

Regards,

Vivek

 

[Suman Pramanik]

Hi vivek,

There was never a supported solution to update the password via script, but many customer used the script which you mentioned. In 13.3 the password's are stored in combination off 2 tables and we don't suggest to make the change..

The script is not a supported soluton but you can try out at your risk.

For Clarity 13.3, just execute this SQL update after generating your info:

 

Update cmn_sec_users set pwd=’<PBKDF2>’, salt=’<SALT>’

Where user_name=’<USERNAME>’;

 

i.e.  update cmn_sec_users set pwd=’b42405b4240386531646662319590b85e48f6bef387002d2f54c03086’,

     salt=’ [B@8e1dfb1’ where user_name=’admin’;

 

PBKDF2 = New algorithm used in 13.3

 

For Clarity versions prior to 13.3, just update the pwd with the <SHA256> value generated, no salt needed.

 

Regards

Suman Pramanik

 

 

[Anon Anon]

Thanks Suman,

You always rescue me!!!

I was able to reset passwords of all users to that of admin by using below query:

update cmn_sec_users set pwd = (select pwd from cmn_sec_users where user_name='admin'), salt = (select salt from cmn_sec_users where user_name='admin') where user_name not in ('admin', 'xog');

[ravindra07]

Hi Suman,

Thanks for your inputs.

Can you please let me know how salt value is being driven in system.i believe salt value is different for all users.

Would you like to share the no of interations and number of bytes for key.

Regards

Ravi

[Suman Pramanik]

Hi ravindra,

 

The encryption is an IP and cannot be shared.

 

Regards

Suman

[Luis Palacios]

Hello Everyone,

actually you can override the salt value, the following script is not supported but has been tested by me before, basically it sets the password to niku2000:

 

update jpmc.cmn_sec_users set pwd='uOKlIQvhjQY5DkehDm8EWN825FHlOsjjRg+jaQcvmlQ=',

     salt=null where user_name='admin';

[Deactivated User]

If you are doing something like that in the database why don't just copy a known password field (pwd) value to those that need to be reset?

Like

update.cmn_sec_users set pwd = (select pwd from cmn_sec_users where user name = 'admin') where user_name <> 'admin'

[pallu03]

You can also do that, in our case was on-site with a customer who refused to provide account details due to security reasons. We tried from another environment copying but didnt work,

[Deactivated User]

Something totally unsupported I have done before was to copy a table from another instance and after that was done copied some data that could not be XOGed

 

What did you try to copy and was there a specific reason why it did not work?

[Luis Palacios]

Urmas,

Table to table is highly risky specially with the 5 million ids and the sequences plus probably will corrupt.

 

We only grabbed the pwd and salt values for a known password,

[Deactivated User]

Don't disagree with that. I my case it the was the configuration in calendar which is a single record and field and a lengthy task in the GUI.