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.

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
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. They use Spring Expression Language (SpEL) to evaluate account attributes.

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

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.

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.