← All KB Checks
HIGHScriptOnlyCheck

Elevated Role Co-Assignments

nowisor-elevated-role-assignments··Source on GitHub →

Elevated Role Co-Assignments

This page describes the nowisor-elevated-role-assignments check from the nowisor Instance Scan Pack v1.0.0. The check identifies active users who hold both the admin and itil_admin roles simultaneously. A single aggregate finding lists the co-assigned users (capped at 20) with an overflow count if more. The check is a specific instantiation of the broader separation-of-duties pattern: holding both platform-administration authority and ITIL process-administration authority in one identity is a documented control violation.

What this finding means

Your instance has at least one active user who holds both admin and itil_admin. These two roles together concentrate authority that a mature access program is expected to separate:

Each role on its own is appropriate to certain job functions. Combined, they create a single identity that can both modify the platform's audit and access controls AND approve or close the records that document platform operations. An attacker compromising the account — or an insider acting maliciously — can both perform a privileged action and approve/close the audit trail of that action. The combination is the canonical "fox guarding the henhouse" in a ServiceNow context.

The check is a single aggregate finding. The evidence lists the user names; if there are 30 co-assigned users, the finding lists the first 20 by name and notes "+10 more." On most well-managed instances, the expected count is zero. Counts above five usually indicate a structural issue with how the entity assigned roles during deployment (every admin was also given itil_admin as a "just in case" measure).

Why it matters for your compliance

Separation of duties is one of the most-cited controls in IAM-focused frameworks. Co-assignment of administrative roles defeats it directly.

NIS2 Article 21§2(j) — identity and access management. NIS2's IAM expectations explicitly include separation-of-duties principles for privileged access. An identity holding both platform and process administration authority is the textbook case the article addresses.

ISO 27001 A.5.18 — access rights. A.5.18 covers access rights, including the principle that conflicting duties be separated where possible. The 2022 update of ISO 27001 strengthened the language around segregation in the context of privileged access. An identity with both admin and itil_admin is a documented violation that auditors specifically flag.

The check is severity 2 (high) because the failure mode is conditional on the user being compromised or acting maliciously — but the conditional is well-attested in real incidents. Compromised admin accounts that also held process-administration authority have been the lever in multiple documented insider-misuse cases across the industry.

The attack path

The path runs through a compromised co-assigned user, with the privilege chain enabling actions that any single-role compromise could not achieve.

Step 1 — Compromise. The attacker obtains access to a user account that holds both admin and itil_admin. The path can be any standard credential-compromise vector: phishing, credential stuffing, leaked credential, insider misuse.

Step 2 — Survey the joint capabilities. With admin, the attacker can:

With itil_admin, the attacker can:

Step 3 — Use the chain. The attacker can now perform actions that would normally be visible in the ITIL workflow trail AND silently bypass that trail. For example:

The change-management trail looks legitimate. The platform's audit shows the operations being performed by an authorized administrator with appropriate change-management approval. A defender reviewing the activity sees what looks like normal operations.

Step 4 — Persistence. If the attacker wants persistent access, they can grant admin and itil_admin to a sleeper account (an old user record marked active with credentials only the attacker knows) — and approve the role grants as their own change request. The sleeper account now has the same combined authority; even if the original compromised account is detected and disabled, the attacker retains the joint capability.

The defense is structural: separate the duties. Platform administration and process administration should be held by disjoint cohorts. Where joint authority is genuinely required (rare cases in small teams), the joint holder should be specifically identified, documented, and subject to enhanced monitoring.

How to fix it

The fix is a role-assignment review and remediation per co-assigned user.

Step 1 — List the co-assigned users. The finding's evidence lists the first 20; use this Background Script to get the complete list:

// Background Script — list all users co-assigned admin + itil_admin
var adminUsers = {};
var aGr = new GlideRecord('sys_user_has_role');
aGr.addQuery('role.name', 'admin');
aGr.addQuery('user.active', true);
aGr.query();
while (aGr.next()) adminUsers[aGr.getValue('user')] = true;

var coAssigned = [];
var iGr = new GlideRecord('sys_user_has_role');
iGr.addQuery('role.name', 'itil_admin');
iGr.addQuery('user.active', true);
iGr.query();
while (iGr.next()) {
    if (adminUsers[iGr.getValue('user')]) {
        coAssigned.push(iGr.user.user_name + '');
    }
}
gs.print('Co-assigned users: ' + coAssigned.length);
coAssigned.sort();
for (var i = 0; i < coAssigned.length; i++) gs.print('  ' + coAssigned[i]);

Step 2 — Classify each user. For each co-assigned user:

Step 3 — Implement assignment guardrails. Prevent future co-assignment from happening accidentally. A Business Rule on sys_user_has_role that warns when an admin role is being granted to a user who already holds itil_admin (or vice versa) catches the issue at assignment time. The warning should not block the grant — there are legitimate cases — but it should require explicit acknowledgment from the assigner.

Step 4 — Pair with enhanced monitoring for retained joint holders. For users where joint authority is genuinely necessary, set up specific monitoring of their activity: a scheduled report or audit-log alert that flags any modification to sys_security_acl or sys_user_has_role by these users. The monitoring is the compensating control for the SoD violation.

How to verify the fix

/*
 * Verify nowisor-elevated-role-assignments progress
 * Read-only, safe for production.
 * Counts users co-assigned admin and itil_admin.
 */
(function checkCoAssignment() {
    var adminUsers = {};
    var aGr = new GlideRecord('sys_user_has_role');
    aGr.addQuery('role.name', 'admin');
    aGr.addQuery('user.active', true);
    aGr.query();
    while (aGr.next()) adminUsers[aGr.getValue('user')] = true;

    var count = 0;
    var iGr = new GlideRecord('sys_user_has_role');
    iGr.addQuery('role.name', 'itil_admin');
    iGr.addQuery('user.active', true);
    iGr.query();
    while (iGr.next()) {
        if (adminUsers[iGr.getValue('user')]) count++;
    }
    gs.print('Co-assigned (admin + itil_admin): ' + count);
    if (count === 0) {
        gs.print('[PASS] Separation of duties maintained.');
    } else {
        gs.print('[REVIEW] ' + count + ' user(s) hold both roles.');
    }
})();

The expected end state is zero, except for explicitly-documented joint holders where the documentation is the compliance artifact.

What to do next

Elevated role co-assignment compounds with the broader IAM cluster:

For organizations under NIS2 supervisory review, the nowisor advisor product is being built to surface co-assigned users with their full activity profile — admin-level operations (ACL changes, role grants, property modifications) and itil_admin-level operations (approvals, closures) side by side — making the SoD audit a single-pane review. Get the IAM evidence flow →

Related checks

← All KB Checks