Adding security_admin, sn_hr_core.admin, etc. without having correct roles yourself

[Mark Roethof]

Articles, Blogs, Videos, Podcasts, Share projects - Experiences from the field

What is shared in this article, might not be best practice. Just sharing this to explore possibilities, find openings in ServiceNow, and have a mindset that your imagination is your limitation.

Hi there,

Ever encountered missing the security_admin role or sn_hr_core.admin role? Tried adding one of those roles to your own user record or to colleagues? Tried workarounds like importing an exported sys_user_has_role record with the security_admin role or sn_hr_core.admin role or trying to add the sys_user_has_role record manually through Background script? Or thought about resetting the password of a user with the sn_hr_core.admin role (and then reverting it) so you can login as that user and adding the role to your own user?

All no go, even though you do have the admin role. That's correct, this is on purpose, it's by design. Although it sometimes might be annoying as a developer, it's also a pretty nice design by ServiceNow! Though did you know that this isn't rock solid and with - a bit of a workaround - you can actually add roles like security_admin or sn_hr_core.admin without having the correct roles yourself?

Just sharing this piece of knowledge, as it can be useful on sub-production instances where for example you accidentally lost access, or for companies that are very strict on security and where this would be a potential security issue.

Do note: That you can add these roles through a workaround, does not mean you should!

No go

Some examples of how you might want to add a role:

• On the User record, using Edit on the Roles Related List
  Roles like security_admin or sn_hr_core.admin actually won't show up
  
• Using a Background script to add a sys_user_has_role record
  Would generate a message like:
  "User test_user does not have the role 'sn_hr_core.admin' which is required to grant/remove 'sn_hr_core.secure_info_reader' under application administration, Resource: 'record/sys_user_has_role/create'"
  - OR -
  "User test_user.admin without admin/security_admin role is not allowed to grant admin/security_admin-containing roles or groups."
  
• Creating a Schedule with a similar script like a Background script
  Would generate a message like:
  "User system does not have the role 'sn_hr_core.admin' which is required to grant/remove 'sn_hr_core.secure_info_reader' under application administration, Resource: 'record/sys_user_has_role/create'"
  
• Exporting an XML for a sys_user_has_role record from a different instance and importing this
  Would generate a message like: "Skipping record for table sys_user_has_role and id d9d18e3997102110d107f3ffe153af9f - permission denied"
• Changing the password of a user with sn_hr_core.admin role (with which you then could login and add the role to your user)
  Would generate a message like: "The scope 'Human Resources: Core' has scoped administration enabled and this user has protected roles but you are not an administrator of that scope"

Workaround

Seeing the two messages concerning "User test_user does not have the role …" and "User system does not have the role …", that's interesting. The user does not have the correct roles, what if you could influence the user the query is run as?

Selecting a "Run as" is a possibility with for example Scheduled Jobs and Scheduled Flows. So let's test a workaround using a Scheduled Job, and executing the same script as we would use in previous cases with Background script of a Schedule.

After executing the Scheduled Job with a Run as User who contains the correct role, the role instantly has been added to your User record even though you didn't have the correct roles yourself.

Interesting knowledge. Definitely a workaround that can be useful in some situations, though also good to know from a security perspective as companies might consider this to be a security issue.

Again: That you can add these roles through a workaround, does not mean you should!

---

And that's it! If any questions, let me know.

C	If this content helped you, I would appreciate it if you hit bookmark or mark it as helpful. Interested in more Articles, Blogs, Videos, Podcasts, Share projects I shared/participated in? - Articles, Blogs, Videos, Podcasts, Share projects - Experiences from the field

Kind regards,

Mark Roethof

Independent ServiceNow Consultant

3x ServiceNow Developer MVP

3x ServiceNow Community MVP

---

LinkedIn

[Mathew Hillyard]

Interesting.

I have replicated this scheduled script execution in my Tokyo PDI, attempting to add security_admin role as a (non security admin) admin user using Run as > System Administrator. It does indeed create the User role record, but as that user, logging out and back in again I cannot elevate privileges and therefore cannot create or edit ACLs, and even though I can see the security_admin role referenced in the User role record, I cannot view the record itself (although I can add to related lists), nor is the security_admin role added to the user record.

I haven't yet tried it with a scoped admin role.

Do you get a different outcome?

[Rim1]

my requirement was to populate several roles (like security_admin, admin, hr admin, etc.) to the groups (don't worry, this is for non prod purposes :)). I was running this with Run As as blank. Worked fine on two non prod instances until I hit the third one. There everything works fine expect for hr scoped app:

User system does not have the role 'sn_hr_core.admin' which is required to grant/remove 'sn_hr_core.secure_info_reader' under application administration, Resource: 'record/sys_group_has_role/create'

System user is not something you can get access to mangle with. Wondering, why it works on some instances, but not the others...

[Eli Guttman]

@Rim1 - were you able to find solution for this? is there a way to run a business rule as an HR core admin?

[Rim1]

I think my issue was a bit different, I needed to run scheduled job rather than BR . I ended up creating service account in ServiceNow with privileged roles to run the job, and that worked on some of the instances. 

BRs don't have such thing as Run As, if your BR in HR scope, it should perform appropriately within HR scope.