How to troubleshoot role inheritance causing unexpected access?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
4 weeks ago
Body:
Hello Experts,
A user currently has access to modules and records that were not intentionally assigned. After investigation, I suspect the access may be inherited through another role.
What is the best approach to:
- Identify inherited roles?
- Trace role relationships?
- Determine the exact source of access?
- Remove unnecessary permissions safely?
Any troubleshooting recommendations would be greatly appreciated.
Thank you.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
4 weeks ago
Use User Administration > Users > [User] > Roles and check Inherited = true to identify inherited roles.
Also:
- Review User Role (sys_user_has_role) to see how roles are assigned.
- Open the parent role and check Contains Roles to trace role inheritance.
- Use Security Debug or Debug Security Rules to determine which role grants access.
- Remove only the unnecessary parent role or group membership after confirming there are no dependencies.
Please Accept the solution if it assisted you with your question & Mark this response as Helpful.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
4 weeks ago
Hi @akash_birada,
This is a very common pattern in ServiceNow because roles are not flat, a role can contain other roles, and a group can grant roles to every member. Nine times out of ten "why does this user have access I never gave them" comes down to one of those two mechanisms, so I'd chase it in this order:
- sys_user_has_role: open this table filtered to the user in question. It has an inherited field, true means the role wasn't assigned directly to that user record, false means someone explicitly added it. This is your fastest triage step.
- Role containment: for any role showing as inherited, open the role record in User Administration > Roles and check the Contains Roles related list (backed by the sys_user_role_contains table). If role A contains role B, everyone with A silently gets B too, this is by far the most common source of "surprise" access. Chase it upward, a contained role can itself be contained by yet another role, so you may have to walk two or three levels.
- Group inheritance: check sys_user_grmember for the user's group memberships, then sys_group_has_role for each of those groups. A role picked up through group membership will also show inherited = true on sys_user_has_role, with the group listed as the granted-by source.
- Confirm it live with Debug Security Rules: go to System Security > Debugging > Debug Security Rules (or append &sysparm_debug=security to the URL) and impersonate the user, then hit the module or record in question. It walks through every ACL evaluated and tells you which one passed and which role satisfied it, so you can see the actual chain rather than guessing from the tables.
On removal: don't try to delete the inherited row straight off the user's Roles related list, it won't stick because it gets regenerated from the source. Remove the role at the source instead, either take it out of the Contains Roles list on the parent role, or unassign it from the group, whichever is actually granting it. And before you pull a contained role off a widely used parent role, run an impact check (a report or GlideAggregate count on sys_user_has_role for that role) so you're not quietly locking out a bunch of people who legitimately needed it.
Thank you,
Vikram Karety
Octigo Solutions INC
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
4 weeks ago
1) To find inherited roles in ServiceNow,
- query the sys_user_has_role table and
- look for records where the Inherited column is true.
These inherited roles are granted either through group memberships, parent-child role hierarchies etc.
2) Navigate to User Administration > Groups, search for the groups the user belongs to, and check the Roles related list to confirm if the triggering role is assigned there
3) If access is specifically related to modules, check if the module itself has a hardcoded role requirement. Navigate to System Definition > Application Menus or Modules, click the record in question, and verify the Roles field.
Probable Fix.
- Once you identied the role if the role is assigned to any other user
- If no, Remove the user from the specific Group, remove the role from that Group's Roles related list, or remove the problematic role from the Contains Roles tab of the parent role
- Test changes thoroughly in a sub-production instance
Regards
Tanushree Maiti
ServiceNow Technical Architect
LinkedIn: https://www.linkedin.com/in/tanushreemaiti
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
4 weeks ago
Hi @akash_birada,
Navigate to User table and check the roles and if Inherited = true, means the role was not directly assigned but added from another source. Also, check in the sys_user_has_role table.
Check in the sys_user_grmember table if it's group-based inheritance.
Navigate to Debug Security Rules and analyze and also verify ACL granted access.
Remove the parent source (Group/Role) instead of deleting inherited roles directly.
Refer below:
Solved: User roles inherited but not from group and roles ... - ServiceNow Community
User is not part any group but still has the roles - ServiceNow Community