System User Management API with Granular Scopes

Silverback provides API endpoints for managing system users and supports granular, action-based permission scopes for API authentication. These capabilities enable secure integration with external systems such as Privileged Access Management (PAM) solutions, identity management platforms, and automation workflows. The API supports system user lifecycle management, including Create, Read, Update, and Delete (CRUD) operations as well as password rotation. This allows organizations to automate administrative user provisioning, maintenance, and credential management processes.

To improve security and adhere to the principle of least privilege, API permissions can be assigned on a per-action basis. Instead of granting broad administrative access through a single global permission, API tokens can be configured to allow only specific operations, such as:

  • Tag assignment
  • Device actions
  • System user management
  • System user password rotation

All API requests are validated against the assigned permission scopes, and supported actions are recorded in the audit trail for traceability and compliance purposes. Additionally, helper endpoints are available to retrieve valid values for configurable system user properties, including roles, cultures, time zones, and date formats. These endpoints help ensure data consistency and simplify integrations when creating or updating system users.

Functional Restrictions for System User Operations

The system user API capabilities are governed by a dedicated functional permission model to prevent misuse and unintended privilege escalation.

Create and Delete Operations

API tokens can only be generated for accounts with the Administrator role, and system users can only be created or deleted for lower privileged roles, including:

  • Super Helpdesk
  • Helpdesk
  • Reporting
  • App Manager
  • FileSync Manager

It is not possible to create or delete system users with elevated roles such as Administrator or Settings Administrator via API.

Update Operations

Updating system users is restricted to non‑administrative accounts and to the administrator account associated with the API token. The following constraints apply:

  • Administrators cannot modify other administrator accounts
  • Role changes are limited to Super Helpdesk and lower privileged roles
  • Password updates are not permitted for administrator accounts via standard update operations
  • The Account Locked Out property cannot be modified for Administrator or Settings Administrator accounts
  • The Enable MFA property cannot be modified for Settings Administrator accounts

These restrictions prevent privilege escalation and ensure that sensitive account properties remain protected.

Password Rotation

Password rotation is supported via API with controlled scope and restrictions:

  • Allowed for:
    • The administrator account associated with the API token
    • All lower privileged accounts
  • Not permitted for:
    • Other administrator accounts

This ensures that automated password rotation workflows remain possible while preventing a compromised API token from affecting multiple administrative accounts or causing system lockouts.

Summary

  • Administrator accounts cannot be created or deleted
  • Administrators can only modify their own account
  • Role escalation is prevented (e.g. assigning Administrator or Settings Administrator roles)
  • Security‑relevant properties (e.g. lockout state, MFA configuration) are restricted
  • Password operations are limited to permitted account scopes

These restrictions ensure that all automation capabilities operate strictly within defined security boundaries.

API Token Behavior

API tokens follow a scoped permission model:

  • Newly created tokens can be configured with granular action scopes
  • Existing tokens using Global Actions continue to function unchanged after upgrading to Silverback 26.2 and later
  • Newly introduced operations (e.g. system user CRUD and password rotation) require the corresponding scoped permissions
  • No existing token is automatically granted access to new capabilities

This approach preserves backward compatibility while enabling a secure and controlled rollout of the new functionality.