analyzing-access

Analyzing ServiceNow Access

Two jobs: review role and group hygiene across users, and explain why a call was denied or came back incomplete. Everything here is read-only. See references/access-errors.md for the denial messages and what each one means, and references/acl-evaluation.md for how ServiceNow decides access.

Tables and roles

Table	What it answers	Readable with
sys_user_has_role	Which user holds which role, directly or inherited	itil (all users' rows); snc_read_only alone gets 403
sys_user_grmember	Group membership; group names come from sys_user_group through group.name	itil
sys_group_has_role	Which roles a group grants	itil
sys_user	active, last_login_time	snc_read_only
sys_security_acl	The ACL rules themselves	admin / security_admin only: 403 for least-privilege identities

Role names come through dot-walks (role.name). The role table itself (sys_user_role) usually hides some or all of its rows from least-privilege identities, so role.name can come back empty (observed for admin and security_admin) while a filter on role.name=admin still matches. Workflow 5 covers dot-walks and their limits.

When access is denied

• 403 on a table: not assessable with this identity. Say so, name the table, and move on; don't guess.
• 0 rows or fields missing from every row (list_records adds a warning): possibly hidden by an ACL, not proof that nothing exists.
• 401 under API-key auth on aggregates or single-record reads: a REST API access policy doesn't cover that API; table reads still work.

Workflows

1. Who holds privileged roles

Progress checklist:

- [ ] List active admin and security_admin grants
- [ ] Flag inactive users and stale logins among them
- [ ] Separate direct grants from group grants
- [ ] Report counts and the accounts to review

1. List the grants, with enough user context to judge each one:

   list_records(table_name="sys_user_has_role", query="role.nameINadmin,security_admin^state=active", fields="user.user_name,user.active,user.last_login_time,role,role.name,inherited", limit=200)
   

   If role.name comes back empty, tell the two roles apart by the role sys_id, or run the query once per role.
2. A row with inherited=false is a direct grant. An inherited row came through a group or through a role that contains this one. To find the group, intersect the user's groups with the groups that grant the role (workflow 2, step 3):

   list_records(table_name="sys_user_grmember", query="user.user_name=<user>", fields="group.name", limit=100)
   

   granted_by still names the group on some instances, but ServiceNow has deprecated it, so don't rely on it.
3. Report the holder count per role, then the accounts to review first: inactive users, users with no recent login, and direct grants.