I'm wanting to include information about when a password for a resource is changed and by whom. How can this be done?
I don't think that's not possible without customization by writing trigger as password is not an attribute in resource object.
Thanks for the help Suman. I think the backend tables with the audit data is likely to suffice.
There is a difference between a User and a Resource in Clarity; the password is a detail of the User. Out of the box auditing can only be done on Studio objects (which makes auditing available to Resource but not User records/attributes).
Using a backend trigger would be an unsupported customization, but a caveat you may want to consider if you go that route is that when users are prompted to change their password because it has expired or through their Account Settings page, then the last_updated_by and last_updated_date fields for cmn_sec_users are not reflecting this change (which is what your triggers would probably be designed to key off to see who made the change, and could pull the wrong data if they do).
Thanks for the advice Nick
Another challenge is the format in which the passwords are stored. You could also store the passwords into a custom object/table and compare daily the current passwords to the copies and record again if they are changed. That only keeps track who changed and when, but not what the actual passwords are.
I'm not sure that should matter (you rarely care what the contents of the password field contains, and end users are always required to pick something new/different when changing it), and a db trigger will just see a difference between the old one-way hash string and the new one-way hash string as being sufficient notification of a change, but it does remind me of another area you may want to check/consider for inclusion in this task.
In the General System Options page for Clarity you can specify a number for the amount of times that unique passwords are required before they may be reused.
If you're using that feature, then check the table CMN_PWD_VERSIONS, as that will give you an automatic (albeit rolling, not permanent) list of password changes by users.
However, I don't think that any passwords set by administrators into the Administration > Users pages abide by those password history rules, and I'm not sure the changes will be logged in there (I know it won't care to check there if the passwords are being reused prematurely, but I'm unsure if it will record the changes made by admins).
If you set the password in the Administration that certain abides the history rules. That is the only way I am aware of to reissue the same expired password.
Theres also the CMN_SEC_USERS.LAST_PWD_CHANGE field - a simple "when" a user last changed their password.
Thank you for everyone's input.
After realising there was not an easy way to see who changed a user's password and when, from the audit UI, I had settled for looking at the CMN_PWD_VERSIONS table as that gives me what I am after - who changed the password and when. The password itself is irrelevant to me.
However, the downfall to this, as mentioned above, is that the table only shows password changes by the user, not an administrator. Does anyone know how the administrator changed password could be picked up?
I think the administrator changes can only be picked up via the custom db triggers watching for changes to cmn_sec_users.pwd and capturing the cmn_sec_users.last_updated_by and cmn_sec_users.last_updated fields.
However, where the :old.last_updated = :new.last_updated (but :old.pwd <> :new.pwd) for the cmn_sec_users table, you would instead want to query for the change data from CMN_PWD_VERSIONS instead.
Something along those lines.
Retrieving data ...