Administration

The Administration section is accessible to users with the Administrator role. It covers user management, audit logging, API keys, system settings, authentication, and licence management.

User Management

Navigate to Administration > Users to manage user accounts.

User Roles

Role	Description
Administrator	Full system access. Can manage users, settings, API keys, licence, and authentication configuration.
IAM Governance Manager	Can manage systems, credentials, scan policies, identities, privilege overrides, and PAM inventory. Cannot access administration settings.
IAM Governance Analyst	Read-only access. Can view dashboards, reports, accounts, KRIs, and scan history. Cannot modify data.
Inherit from OIDC Claim	Role is determined by the SSO provider's role claim on each login. Only available when OIDC is configured.

Creating a User

1. Click Add User
2. Fill in:

Field	Required	Description
Username	Yes	Login username (must be unique)
Full Name	Yes	Display name
Email	Yes	Email address
Role	Yes	One of the roles above
Initial Password	Yes	Temporary password (user should change on first login)

3. Click Save

User creation is subject to the licence limit on maximum users.

Managing Users

• Deactivate - disables a user account (they cannot log in, but their audit history is preserved)
• Activate - re-enables a deactivated account
• Reset Password - sets a new temporary password for the user

Password Policy

Navigate to the Password Policy tab on the Users page to configure password requirements. See Configuration Reference for all available settings.

Audit Logs

Navigate to Administration > Audit Logs to view a complete record of all actions performed in OrbisID.

Each log entry contains:

Field	Description
Timestamp	When the action occurred
User	Who performed the action
Action Type	Category of action (e.g., USER_LOGIN, SYSTEM_CREATED, SCAN_EXECUTED)
Target	What was affected (e.g., system name, account ID)
Details	JSON payload with additional context

Filtering Audit Logs

Use the filters to narrow results:

• Action Type - select from a dropdown of all action types
• Date Range - start and end dates
• User - filter by the user who performed the action

Click on any log entry to view its full JSON details in a dialog.

Action Types

Common action types include:

Category	Actions
Authentication	USER_LOGIN, USER_LOGOUT, USER_LOCKED, OIDC_LOGIN_SUCCESS
Systems	SYSTEM_CREATED, SYSTEM_UPDATED, SYSTEM_OFFBOARDED
Credentials	CREDENTIAL_CREATED, CREDENTIAL_UPDATED, CREDENTIAL_PAM_SCRIPT_UPLOADED
Scanning	SCAN_EXECUTED, SCAN_COMPLETED
Accounts	ACCOUNT_LINKED, IDENTITY_CREATED
Administration	LICENSE_ACTIVATED, CONFIG_CHANGED, API_KEY_CREATED

On-Premise Agents

Navigate to Administration > On-Premise Agents to manage remote scan agents.

See On-Premise Agent for full documentation on deploying and configuring agents.

The administration page lets you:

• View registered agents and their status (online/offline, last heartbeat)
• Create agent groups to organise agents by network segment
• Assign systems to agent groups (systems in a group are scanned by agents in that group)
• Regenerate agent API keys
• Enable/disable agents
• Drain agent queues (finish current jobs, accept no new ones)
• Download agent installation packages (Docker image or JAR)

API Keys

Requires Enterprise edition.

Navigate to Administration > API Keys to manage API keys for programmatic access.

Creating an API Key

1. Click Create Key
2. Enter a name/description for the key
3. Click Create
4. Copy the key immediately - it is only displayed once

danger

The API key value is shown only at creation time. If you lose it, you must create a new key.

Managing API Keys

Action	Description
Enable	Activates a disabled key
Disable	Temporarily disables a key (can be re-enabled)
Delete	Permanently removes the key

All API key operations are recorded in the audit log.

System Settings

Navigate to Administration > Settings to configure application-wide settings.

Setting	Default	Description
Date Format	yyyy-MM-dd	How dates are displayed in the UI
DateTime Format	yyyy-MM-dd HH:mm:ss	How timestamps are displayed
Connection Timeout	60 seconds	Default timeout for testing system connections

Changes take effect immediately.

Branding & Display

Also on Administration > Settings, the Branding & Display tab customises OrbisID's appearance instance-wide — for every user, including the login page before anyone signs in.

Setting	Options	Notes
Color Scheme	Light, Dim, Dark	Menu Theme is only selectable under Light — Dim and Dark use a fixed dark menu regardless.
Menu Theme	13 colors (white, darkgray, blue, bluegray, brown, cyan, green, indigo, deeppurple, orange, pink, purple, teal)	Sidebar/menu background color. Light Color Scheme only.
Component Theme	10 colors (blue, green, lightgreen, purple, deeppurple, indigo, orange, cyan, pink, teal)	Accent color for buttons, links, and other interactive components — set independently of Menu Theme.
Login Background	4 bundled images	Background image shown behind the login form.

Date Format and DateTime Format (see the table above) also live on this tab, under its "Display Formats" card. Every setting here applies immediately, instance-wide, to all users — there is no per-user override (per-user display scale is a separate setting, on the Profile page, not here).

System Health

Also on Administration > Settings, the System Health card controls when an unreachable system is marked Offline and when a system left Offline too long is automatically archived.

Setting	Default	Description
Mark system Offline after (days)	28	Days since the last successful scan before a Pending/Active/Degraded system is marked Offline.
Auto-archive Offline systems after (days)	90	Days a system may remain continuously Offline before it is automatically archived.

info

Both checks run together in a single nightly job at 03:00 server time, not continuously. A system that goes stale just after 03:00 won't be marked Offline until the following night's run, and the same applies to auto-archiving. Threshold changes saved here are read fresh on the next nightly run — no restart is required, but they don't apply retroactively to that night's already-completed run.

If a system reconnects and scans successfully even once while Offline, its Offline timer resets, so the archive countdown starts over.

Account & Entitlement History Retention

Also on Administration > Settings, this card controls how long the Audit History and Membership History entries for Accounts and Entitlements are kept.

Setting	Default	Description
Keep history for (days)	365	Days a history entry is kept before a nightly purge removes it.

info

This only prunes the individual history entries — an archived Account or Entitlement itself is always kept, regardless of this setting, so the account or entitlement remains visible on its Archived tab indefinitely.

Privileged Account Risk Score

Also on Administration > Settings, this card controls the weighting used to compute the Privileged Account Risk Score shown on the Accounts list, Dashboard, and account detail view.

Category	Default weight
Ownership	20%
Management Coverage	20%
Staleness	15%
Threat Activity	25%
Blast Radius	20%

Weights don't need to sum to 100 - the calculation normalises by their total, so you can, for example, double every weight and get the same relative result.

Each category is scored 0-100 from signals already collected during scans - Blast Radius specifically from how many systems are reachable through this account's credential, once Auth Delegation is configured for the systems involved. Those five category scores are combined into a weighted average using the percentages above, then multiplied by the account's PAM Risk Level (its system's risk tier) before being capped at 100:

PAM Risk Level	Multiplier
Low	×0.85
Medium	×1.00
High	×1.15
Critical	×1.30

For example, an account scoring 70 on the weighted category average, on a system with a High PAM Risk Level, gets a headline score of 70 × 1.15 = 80.5, rounded to 81.

The result is then floored at a minimum that scales with the account's PAM Risk Level tier, so a privileged account can never show as zero risk purely for being well managed:

PAM Risk Level	Baseline floor
Low	10
Medium	20
High	30
Critical	40

For example, a perfectly managed account (linked, active, PAM-managed, fresh password, no threats) on a Critical-tier system still scores at least 40, not 0.

Changes take effect on the next scan; they do not retroactively recalculate existing scores. Click Recalculate Risk Scores to refresh every account's score immediately using the currently saved weights, without waiting for the next scan. This section is available (and editable by an Administrator) on all editions, including Community.

AI Assistant (OrbisAI)

Requires Pro or Enterprise edition — not available on Community.

Also on Administration > Settings, the OrbisAI tab configures the AI/Intelligence Layer — its two independent switches, AI LLM and Smart Matching & Suggestions, are both on by default (an administrator can turn either off during the one-time Initial Setup prompt, or here at any time). AI LLM is local-only (talks to a self-hosted Ollama instance, never an external provider); Smart Matching & Suggestions needs no Ollama connection at all. The tab also has Ollama connection settings (endpoint, models, timeout) and a Test Connection button — see AI Assistant (OrbisAI) for what each switch controls.

The same tab has a Generate Risk Summary Now button, which takes a KRI snapshot from your current data and generates the Dashboard's AI Risk Summary in the background — the only way to produce that summary before your first scan has run, since it otherwise only refreshes as a side effect of scanning.

See AI Assistant (OrbisAI) for full setup steps and what each feature does.

Data Import/Export

Requires Pro or Enterprise edition — not available on Community.

Also on Administration > Settings, the Data Import/Export tab exports OrbisID configuration and reference data to a single archive, and imports that archive into another OrbisID instance. Typical uses are cloning a staging estate into production, or migrating off a proof-of-concept instance, without re-entering everything by hand.

What's included

Included	Never included
Systems, Credentials, Identities, Accounts, Entitlements, Account-Entitlement Links	User accounts / logins
Policy Rules, Scan Policies (with their assigned systems)	Licence
PAM Inventory (PAM accounts and their links to Accounts)	API Keys
KRI Thresholds and KRI Exceptions	On-Premise Agents, Endpoint Sensors
Email Templates, System Settings	Scan history, audit logs, Threat Detections

Only configuration and reference data travels between instances — operational and historical data always stays on the instance it was generated on, and user logins are never copied (so importing an archive can never change who can sign in to the destination instance).

info

KRI Thresholds covers only the fields you can actually edit on a KRI from the KRIs page — enabled, RAG thresholds, and display format. The KRI catalog itself (which KRIs exist, their names, categories, and calculation logic) is fixed and ships with OrbisID, so it isn't part of the export, and import only ever updates a KRI that already exists on the destination instance — it never creates one.

Exporting

1. Open the Data Import/Export tab and use the tree to select what to export.
2. Selecting an item automatically includes anything it depends on — for example, selecting Accounts also selects Systems and Identities, since an account only makes sense together with the system and identity it belongs to. Dependencies are shown under each item and can't be deselected while something that needs them is still selected.
3. To include stored credential secrets, tick Include encrypted credential secrets (only enabled once Credentials is selected). This also covers the SMTP password under System Settings, if that's selected too.
4. Click Export to download a .zip archive.

warning

Credential secrets are exported exactly as stored — still encrypted, not decrypted first. The destination instance's encryption key must match the source instance's for them to work after import. If the keys differ, the credential and SMTP password records still import, but the import result will flag them as undecryptable, and you'll need to re-enter the actual password/key values by hand. See Configuration Reference for the ENCRYPTION_KEY setting.

Importing

1. Open the Data Import/Export tab on the destination instance.
2. Choose how to handle records that already exist there:
   • Skip existing records - only adds records that don't already exist; anything already present is left untouched.
   • Overwrite existing records - replaces the existing record's fields with the imported values.
3. Choose the .zip archive and import.

Matching between "already exists" and "new" is done by each record's natural identity (e.g. a system's hostname and IP address, a credential's name, an account's name within its system) rather than by internal ID, since internal IDs are never the same across two separate OrbisID databases.

info

Identities are matched by employee ID, falling back to email, then username. An identity with none of those three set (uncommon, but possible for some non-human identities) has no reliable way to detect "this already exists," so it's always created as a new record — importing the same archive twice would duplicate it. The import result flags how many identities this applied to.

Reading the Import Result

After an import completes, a table shows one row per data type with Total, Imported, Skipped, and Errors counts — for example, "24/25 accounts imported." Expand a row to see the specific records that failed or produced a warning, and why (a missing dependency, an encryption key mismatch, or a genuine data error). A record failing doesn't stop the rest of the import — every other record is still processed independently.

Both exports and imports are recorded in the audit log.

Authentication (OIDC/SSO)

Requires Enterprise edition.

Navigate to Administration > Authentication to configure OIDC single sign-on.

Configuration

Field	Description
Issuer URL	Your identity provider's OIDC issuer URL
Client ID	OAuth 2.0 client ID
Client Secret	OAuth 2.0 client secret (encrypted at rest)
Redirect URI	The callback URL (https://your-orbisid-host/oidc-callback)
Role Claim	JWT claim name containing the user's role

How It Works

Role Mapping

If a user has the role INHERIT_FROM_OIDC_CLAIM, their effective role is determined by the value of the configured role claim in the ID token. The claim value must match one of:

• ADMINISTRATOR
• IAM_GOVERNANCE_MANAGER
• IAM_GOVERNANCE_ANALYST

Users with a specific OrbisID role assigned always use that role, regardless of the SSO claim.

Testing

After saving the configuration, click Test to verify the OIDC flow works. If the test succeeds, the SSO button will appear on the login page.

To remove OIDC, click Delete Configuration.

Licence Management

Navigate to Administration > Licence to view and manage your OrbisID licence.

Viewing Licence Status

The licence page shows:

Field	Description
Edition	Community, Pro, or Enterprise
Status	Active, Expired, or Community
Valid Until	Expiry date (if applicable)
Max Systems	Maximum number of active systems
Max Users	Maximum number of user accounts
Max Schedules	Maximum number of scheduled scan policies

Activating a Licence

1. Paste your licence key into the text field
2. Click Preview to verify the key details before activating
3. Click Activate

Deactivating a Licence

Click Deactivate to revert to the Community edition. Your data is preserved, but features beyond Community limits will become locked.

Edition Comparison

See Licensing for a full comparison of features by edition.