How do I stop users with user_admin role adding themselves to the admin role?

Wayne Richmond · ‎05-17-2017

I've given various IT staff the user_admin role so they can update user groups but I've noticed they're also able to give themselves the admin role. How can I prevent this?

I've tried changing the Read rule on the sys_user_role table to only include the role_delegator role (removing itil and user_admin) and while this appears to work, it has undesired knock-on effects elsewhere.

Tim Deniston · ‎05-17-2017

You would need a business rule on the sys_user_has_role table that aborts the insert of the User Role record if the user does not have Admin.

This should be run on Insert and onBefore.

// don't allow user_admin to assign admin role without already having admin:

function onBefore(current, previous) {

   var role = new GlideRecord("sys_user_role");

   role.get(current.role);


   if (role.getValue("name") == "admin" && !gs.hasRole('admin')) {

           gs.addErrorMessage(gs.getMessage("You cannot assign the admin role without already having the admin role."));

           current.setAbortAction(true);

   }

}

View solution in original post

Wayne Richmond · ‎05-17-2017

Thanks Tim, this certainly seems to do the trick, thanks.

Corey19 · ‎03-01-2023

While I haven't confirmed the context as written, the idea behind Gurpreet07's approach makes the most sense if restricting access is the plan. While a Business Rule works, access should be controlled primarily by the tools designed for that purpose.

An example of how an oversight in this regard can be used is found in the ATF suite where the developers have restricted access, preventing access to create steps in specific test step environments. Due to the developers relying on Business Rules and not employing ACLs you can get around this with a bit of scripting and the use of setWorkFlow(false).

Gurpreet07 · ‎05-17-2017

Create a Write/Create ACL on sys_user_role and check if current.role='admin' && !gs.getUser().hasRole('admin'){ return false};

Corey19 · ‎03-06-2023

While I haven't confirmed the context as written, the idea behind Gurpreet07's approach makes the most sense if restricting access is the plan. While a Business Rule works, access should be controlled primarily by the tools designed for that purpose.

An example of how an oversight in this regard can be used is found in the ATF suite where the developers have restricted access, preventing access to create steps in specific test step environments. Due to the developers relying on Business Rules and not employing ACLs you can get around this with a bit of scripting and the use of setWorkFlow(false).

TStark · ‎05-15-2024

It looks like this is no longer an issue OOB. At least not in versions Utah and up.