Allow analysts to reset passwords

[Jim]

So our analysts have access to reset passwords and archive users or unarchive in Hornbill, The problem is when I have tested they can reset passwords or archive the admin accounts aswell. Shouldn't there be a level of protection against this? like only an admin can edit an admin account sort of thing?

[Keith Stevenson]

@Jim
We have tested this and cannot replicate. You need Admin Privilege to change the Admin account. Any attempt is met with 1 of the 2 messages



Code : 0200
Service : admin
Operation : userRecoverPassword
Message : The 'admin' account's password cannot be recovered by a user that does not hold the Admin privilege.



or 

Code : 0200
Service : admin
Operation : userSetAccountStatus
Message : The 'admin' account cannot be updated by a user that does not hold the Admin privilege.


Can you confirm that the "changee" doesnt have the Admin Privilege

Kind Regards

[Jim]

I have been able to change several admin accounts passwords and status's using this test account, I have had to double check the email address can't be changed so at least mfa is a barrier on them

This is the privilege of the account I am testing as 

[Jim]

So, that looks to be the 'admin' account, I'm referring to any account with admin rights  

[Graham]

@Jim Does your test account have a role with the Manage Users right?

[Jim]

Hi, they do have the manage users right as I want them to be able to archive and reset passwords for basic users, However it shows a flaw that they could reset my or any other admins account. I do have MFA on and they can't turn it off or modify the email so is a level of protection but not as much as it should be

[Graham]

@Jim The Manage Users right allows a user to manage all users apart from the "admin" user (or any other account with the Admin privilege). 

As I understand it, you're looking for two different rights - one to manage full and basic users and one that can only manage basic users?

 

[Jim]

@Graham, Only the top line I am looking at working, so My main account has admin privileges, my test account is just a standard licensed analyst, with user privileges However with my test account I do not want to be allowed to modify my password on my main account or the status, The test account reflects all licensed users general rights and roles

[Jim]

10 minutes ago, Graham said:

(or any other account with the Admin privilege). 

it's this part that is not actually true with my test

[Graham]

@Jim  

10 minutes ago, Jim said:

Only the top line I am looking at working

Not sure what you mean by this.
 

9 minutes ago, Jim said:

all licensed users general rights and roles

Do these rights include the Manage Users right?
 

9 minutes ago, Jim said:

it's this part that is not actually true with my test

Can you change the password for the user with the user id "admin"?

[Jim]

Yes they have the manage users rights so they can archive, and reset passwords. 
The main 'admin' account this feature works for and will not allow them to reset the password or the status for archiving - It does not work for accounts with admin privileges

[Graham]

@Jim That behaviour is by design. A user with the Manage Users right can change the password for any user on the system apart from the "admin" user.

However, we may be using the same term for different things. What's your definition of an "account with admin privileges"?

 

[Jim]

so there is the generic system admin account, and then there is the actual staff that support Hornbill within the business which have certain admin rights, these are the users that I would also like to be protected.

 

Theoretically an analyst could reset my account password, sign in directly and then they can act as my account with all the admin rights that I have and other admins. 

[Jim]

and in turn, They could reset an actual staff members admin account, sign in, then reset the generic admin account 

[Graham]

4 minutes ago, Jim said:

Theoretically an analyst could reset my account password

True, because that's one of the activities enabled by holding the Manage Users right. 

 

8 minutes ago, Jim said:

They could reset an actual staff members admin account

This is where I think we may be talking at cross purposes. What's your definition of an "admin account"?
 

3 minutes ago, Jim said:

then reset the generic admin account 

They can't do this, since only someone who can log on as "admin" can reset the password for "admin".

[Jim]

1 minute ago, Graham said:

This is where I think we may be talking at cross purposes. What's your definition of an "admin account"?

So in essence anyone with the Privilege Granted: Admin 

[Graham]

@Jim Ok, got you. So do those user have the Platform Super User Role granted? If so, how many users have that role granted?

[Jim]

Only around 4 on our instance, They are all second accounts for these admins and they have the usual analyst standard accounts also

[Graham]

@Jim That's not really a recommended approach. As it says in the role description:

This role provides super user functionality to the system as it overrides all rights and permissions. A super user should never log into the user application, and the role should only ever be used when first setting up the system, or in an emergency to recover the system.

I would suggest that you remove this role from any account which is used for day-to-day activities within Hornbill and grant those accounts a more granular set of roles dependent on the tasks carried out by their respective users.

[Jim]

@Graham I will review the rights although it might be a custom role, I still think there still needs to be a layer of protection against anyone with admin rights, to either workflows, config, keys etc should only be able to be reset by another similar or higher privileged user 

[Graham]

@Jim Yes, it's something we're now discussing internally.

 

[Jim]

Thank you

[Graham]

@Jim To follow up on the above, we've now chatted all this through within the team, and there will be some changes made to how the system processes password changes for users.

Going forward, only a user who currently holds the admin-level privilege will be able to change a user's password directly. This will prevent the scenario you outlined above whereby an analyst would be able to change your password. For users that do not hold the admin-level privilege, the ability to directly set a user's password from within the Administration section of Hornbill will be replaced by a facility to initiate a password reset request to the user via e-mail.

Also, I would re-iterate the point that accounts with the admin-level privilege are not intended for day-to-day usage, but rather are for system setup and emergency situations, and I would encourage you to review those users who currently do hold that privilege and remove it where possible.

Finally, for resetting the passwords of basic users, I would be interested to understand why it is the analysts that are taking on this task. A user can request a password reset directly from the login page. Is there a reason why this self-service approach is not being used?

 

[Jim]

@Graham Thank you, I have removed any permissions for the admin privilege role. The users resetting password side I agree should be done via self service but sometimes we have accounts with an invalid email due to the way they are set up usually the external contacts that live within our AD so get imported as part of the internal users side (This was decided before my time as I'd of had them just use the external version and still might at some point) And then theirs general users where it is sometimes a lot more time saving to just do it for them

[Steve Giller]

4 minutes ago, Jim said:

The users resetting password side I agree should be done via self service but sometimes we have accounts with an invalid email due to the way they are set up

The pedantic view here would be that the analyst should not alter the password, but have the email address corrected (via a request to your AD team) so that the Customer can use the reset password link.
On the one hand that can be cumbersome, but on the other it's a good incentive for external contacts to inform you of any email changes promptly.