Scanning

Scanning is the core function of OrbisID. Scan policies define which systems to scan, when, and how to classify the accounts discovered.

How Scanning Works

1. A scan policy is triggered (manually or on schedule)
2. The orchestration service creates a scan execution and dispatches jobs for each system
3. Each system is scanned using the appropriate scanner for its OS type
4. Discovered accounts and entitlements are stored in the database
5. Policy rules evaluate each account to assign privilege levels and classifications

Scan Policies

A scan policy groups systems together and defines when they should be scanned.

Policy Types

Type	Description
System Scan (default)	Scans the assigned systems for accounts, entitlements, and services
Attestation Reminder	Sweeps the assigned systems for Privileged Access Attestations that are due (never completed, or not completed within the system's configured attestation period) and emails the System Owner. Does not connect to or scan any system — it only checks attestation due-dates and sends reminder emails.

Attestation Reminder policies reuse the same Schedule Type, systems assignment, manual Scan Now trigger, and Scan History as System Scan policies.

Creating a Scan Policy

1. Navigate to Scanning
2. Click Create Policy
3. Fill in the fields:

Field	Required	Description
Name	Yes	Descriptive name for the policy
Description	No	Optional notes about the policy's purpose
Policy Type	Yes	System Scan or Attestation Reminder (see above)
Schedule Type	Yes	When the policy runs (see below)
Systems	Yes	Which systems to include

Schedule Types

Type	Description	Edition
On Demand	Manual trigger only	Community+
Daily	Runs once per day at a configured time	Pro+
Weekly	Runs once per week on a configured day and time	Pro+
Monthly	Runs once per month on a configured day and time	Pro+
Quarterly	Runs once per quarter	Pro+

The Community edition only supports on-demand scanning. Pro allows 1 scheduled policy. Enterprise allows unlimited.

Adding Systems to a Policy

1. Open a scan policy
2. Click Add Systems
3. Select one or more systems from the list
4. Click Confirm

Systems with a scan priority of -1 are automatically excluded from policy execution but can still be scanned individually via Scan Now on the Systems page.

Within a policy, systems are scanned in priority order (lowest number first).

Running a Scan

Manual Scan

1. Navigate to Scanning
2. Find the policy you want to run
3. Click Scan Now

Scheduled Scan

Scheduled policies run automatically at their configured time. No manual intervention is required.

Single System Scan

You can also trigger a scan for a single system from the Systems page by clicking Scan Now on that system. This bypasses the scan priority setting (including -1 excluded systems).

Scan History

Navigate to Scanning > History to view all scan executions.ß

Each execution shows:

Column	Description
Policy	The scan policy name
Started	When the scan began
Completed	When the scan finished
Status	QUEUED, RUNNING, COMPLETED, FAILED, or CANCELLED
Systems	Number of systems scanned

Scan Statuses

Status	Meaning
Queued	Waiting to start
Running	Currently executing
Completed	Finished successfully
Failed	Encountered errors (check logs for details)
Cancelled	Stopped by a user

Viewing Scan Logs

Click on any scan execution to view its detailed logs. Logs include:

• Connection attempts and results
• Number of accounts discovered per system
• Entitlement enumeration details
• Policy rule evaluation results
• Errors and warnings

Each log entry has a severity level (INFO, WARN, ERROR) and a timestamp.

Stopping a Running Scan

Click Stop on a running scan to cancel it. Systems that have already been scanned retain their results. Systems not yet scanned are skipped.

Policy Rules

Policy rules determine how discovered accounts are classified. Most types use Spring Expression Language (SpEL) to evaluate account attributes — the exceptions are the AI Auto-Link / AI Auto-Match / AI Auto-Classify rule types (all Pro+/Enterprise): Identity Linking, PAM Inventory Linking, Account Type, Identity Type, Privilege Detection, Service Privilege Detection, and NHI Subtype each have an AI-assisted sibling that classifies or links above a configured confidence threshold instead of a hand-written condition (the NHI Subtype AI Auto-Classify rule is fully functional but not yet available in this editor — it can only be created and run via the Policy Rule API today; the base, non-AI NHI Subtype SpEL rule type below is available here now). The Account Type / Identity Type / Privilege Detection / Service Privilege Detection / NHI Subtype AI variants additionally only ever act on items no SpEL rule has already classified — a rule-based match always takes precedence. Privilege Detection and Service Privilege Detection are further restricted to one-directional (upgrade-only) classification — see AI-Assisted Privilege Detection.

Navigate to Configuration (Administrator role required) to manage policy rules.

Privilege Detection, Account Type, Identity Type, Service Privilege Detection, Share Privilege Detection, PAM Inventory Linking, and NHI Subtype rules each have a Skip Already-Set Items toggle (on by default). When on, an item that already has the value the rule would set — an entitlement already marked Privileged, an account already classified, an account already linked to a PAM record, a Non-Human account that already has an NHI Subtype — is excluded from evaluation entirely, instead of being re-matched and re-written on every scan. Turn it off to force the rule to re-evaluate every item regardless of its current state (for example, to let this rule override a value a different, now-changed rule previously set). Identity Linking doesn't need this toggle — it already always excludes accounts that are already linked. Every AI Auto-Link/Auto-Match/Auto-Classify rule variant already behaves this way unconditionally, since only ever touching not-yet-set items is core to how they work.

How Rules Work

Each policy rule has:

Field	Description
Name	Descriptive name
Condition	A SpEL expression that evaluates to true or false
Privilege Level	The level assigned if the condition is true (e.g., PRIVILEGED, NON_PRIVILEGED)
Account Type	The classification assigned (HUMAN, NON_HUMAN)
Priority	Order of evaluation (lower = evaluated first)
Enabled	Whether the rule is active

Rules are evaluated in priority order. The first matching rule determines the account's classification.

A rule of type NHI Subtype replaces the Privilege Level/Account Type fields above with a dedicated NHI Subtype (when rule matches) dropdown, since its outcome is one of ten subtype values rather than a binary classification — it's only ever evaluated for accounts already classified Non-Human.

Available SpEL Variables

These variables are available in rule conditions:

Variable	Type	Description
username	String	The account's username
displayName	String	The account's display name
groups	List<String>	Group memberships
enabled	Boolean	Whether the account is enabled
lastLogon	Date	Last logon timestamp
systemType	String	The system type (DIRECTORY_SERVICE, SERVER, etc.)
osType	String	The OS type (ACTIVE_DIRECTORY, LINUX, etc.)
attributes	Map	Additional key-value attributes from the scan

Example Rules

Domain Admins are Privileged:

groups.contains('Domain Admins') or groups.contains('Enterprise Admins')

Service accounts are Non-Human:

username.startsWith('svc_') or username.startsWith('SVC_')

Disabled accounts are Non-Privileged:

enabled == false

Linux root is Privileged:

osType == 'LINUX' and (username == 'root' or groups.contains('sudo') or groups.contains('wheel'))

SQL Server sysadmin is Privileged:

osType == 'SQL_SERVER' and groups.contains('sysadmin')

Testing Rules

Use the Test Rule feature to evaluate a SpEL expression against sample data before saving it. Enter the expression and a sample account, and the system will show whether the rule matches.

Built-in Rules

OrbisID ships with a set of default policy rules that cover common privileged access patterns. These can be modified or disabled as needed.

A Policy Rule Catalogue is available showing pre-built rule templates that you can add with one click.

Auth Delegation Mapping

Some accounts don't hold their own independent credential — a SQL Server Windows Login, or any account that authenticates via SSO/federation, shares its credential with an account on another system. OrbisID calls the account that shares a credential a Shadow Directory Account, and the account that actually holds the credential the auth account. Mapping these matters for risk scoring: compromising a Shadow Directory Account's credential also compromises its auth account (and every other Shadow Directory Account sharing it) — see Blast Radius on the Privileged Account Risk Score.

Unlike other rule types, an Auth Delegation Mapping rule targets two explicit system selections instead of a System Type Filter:

1. Add a rule of type Auth Delegation Mapping
2. Set Authentication System to the system that actually holds the credential (e.g. Active Directory) — not offered for PAM Platform systems, since a vault manages other accounts' credentials rather than being a delegation target itself
3. Set Shadow Accounts System(s) to the system(s) whose accounts share that credential (multiple systems can map to the same Authentication System)
4. Set the Mapping Rule (SpEL) — evaluated per account on the shadow system(s), with #account bound, returning the account name to look up on the Authentication System. Common examples (also available in the Policy Rule Catalogue):
   • #account.accountName — same username on both systems
   • #account.accountName.indexOf(92) >= 0 ? #account.accountName.substring(#account.accountName.indexOf(92) + 1) : #account.accountName — strips a DOMAIN\username prefix (92 is the character code for \)
   • #account.attributes['mail'] — match by the local part of an email address instead
5. Save, then add Auth Delegation Mapping to a Scan Policy's Policy Rule Types so it runs after future scans — like any other rule type, it only resolves when the policy that ran the scan selected it.

Once resolved:

• The Shadow Directory Account is tagged on the Accounts list and in its own Account Details, which also shows which auth account it delegates to.
• The auth account's Account Details lists every Shadow Directory Account sharing its credential.
• Every group the Shadow Directory Account holds is automatically mirrored onto the auth account (shown in its Groups tab, marked INHERITED with a "via: ..." note) — so the auth account's Groups tab reflects everything reachable through that shared credential, not just what it holds directly.

If the mapping rule can't find exactly one matching account on the Authentication System, the account is left unresolved (ambiguous or zero matches aren't guessed) and retried on the next scan; a previously-resolved link is left in place rather than cleared if a later scan can no longer confirm it — a genuinely stale mapping needs to be corrected manually.