11.1How access works

Access is built from four pieces:

• A user is a person who signs in to the console. A user holds one or more roles.
• A role is a named set of permissions, plus the directories (Active Directory connections) the role may act against.
• After signing in, a person who holds several roles chooses which one to work in — the active role. Only the active role's permissions apply, and the person can switch roles later without signing in again (see Chapter 3, Signing in and your account).
• API keys and connected AI agents also act with a role, and can never do more than their owner can (see Chapter 12, API keys, and Chapter 13, AI agents (MCP server)).

Permissions are checked by the server on every request. Hiding a button in the console is a convenience; the server's check is what enforces access. When a request is refused, the platform answers with a generic "forbidden" response and does not reveal which permission was missing.

Directory access is part of the role

Every operation against Active Directory runs as the connection's service account, not as the person. A role's directory bindings therefore decide what its holders can change, not just what they can see. A role either reaches Every directory (including connections added later) or a chosen list of connections. A role with Directory permissions but no directory selected can do nothing in any directory.

You cannot grant more than you hold

Throughout this area the platform applies one rule: you can only hand out authority you hold yourself.

• When you create or edit a role, you cannot give it a permission your active role does not hold.
• You can only give a role Every directory if your own role reaches every directory, and you can only bind connections your own role may use.
• You can only assign a role to a user if you hold every permission in that role.
• Resetting another person's password, changing their email address, resetting their two-factor sign-in, or linking a Windows account to them requires that you hold at least the permissions their roles grant.

The System Admin role

Every installation has one built-in role, System Admin. It holds every permission, reaches every directory, and is marked with a System badge. Working in the System Admin role is called system scope.

There is no built-in user account. The first administrator is created during first-time setup and is given the System Admin role (see Chapter 2, Installation and first-time setup).

System Admin follows rules that ordinary roles do not:

• Its name, permissions and directories cannot be changed, and it cannot be deleted. The edit page shows "This is a system role. Permissions cannot be modified."
• Only someone working in system scope can assign the role to a user or remove it from a user.
• Only someone working in system scope can act on an account that holds System Admin: edit it, reset its password, deactivate or activate it, delete it, reset its two-factor sign-in, link a Windows account to it, or issue an API key for it.
• The last active holder is protected. The last active user holding System Admin can never be deactivated, deleted or lose the role. Without this rule nobody could recover administration of the platform, because first-time setup does not reopen once someone has held the role.
• Some settings — single sign-on, email providers, live logs, log shipping, MCP server settings, backups and deleting a directory connection, among others — are available only in system scope, regardless of permissions. Those chapters say so where it applies.

Important: Keep at least two people able to work in the System Admin role, and protect it with two-factor sign-in (see Requiring two-factor sign-in for a role).