Administrators
Administrators manage Tessera itself — users, targets, access and settings. This page covers how administrative authority is delegated and protected. For connect-level access to targets, see Access control.
Beyond full administrator, you can grant finer management permissions to a user under Users:
- Manage targets — add and edit servers, databases, clusters and RDP hosts, their stored credentials, projects, groups and the SSH key library.
- Manage access — grant and revoke access to targets, approve just-in-time requests, end a live session and watch one as it happens. It does not carry the power to change what other people may administer.
- Manage users — create accounts, reset passwords, enable and disable them, and set which management permissions other people hold. Granting administrator is reserved to administrators.
- View audit — read the audit log, verify the integrity chain, replay recorded sessions. Read only: it changes nothing and grants no access to any target.
Each one owns a single subject: targets, access to them, the people, and the record. Somebody who hands out access to servers cannot quietly make themselves a user administrator, and somebody who administers people does not thereby get into any server.
A full administrator implicitly has all of these.
View audit is separate from Manage access on purpose. Reading the record of who reached what, and holding the power to hand that access out, are two duties. An auditor needs the first and should not be given the second, which is what ISO/IEC 27001:2022 asks for under A.5.3 and what least privilege means under A.5.15 and A.8.2. Granting this permission and nothing else produces an account that can answer every question an access review asks and change nothing while doing it.
Setting these permissions needs the RBAC feature, so on Community every account is either a full administrator or an ordinary user.
A delegate cannot exceed itself
Section titled “A delegate cannot exceed itself”Two rules apply to everyone who is not a full administrator, and they exist because without them any one management permission was a route to all of them:
- You cannot grant a permission you do not hold. Otherwise the holder of Manage users could create an account, give it Manage access, sign in as it, and hand themselves every server.
- You cannot reset the password of an account that holds authority you do not hold. That is the same takeover without the grant: choose a password for somebody stronger than you and sign in as them. Administrators’ passwords were already protected this way; this extends it to delegated roles.
For which control each of these answers, and what to hand an auditor, see Control mapping.
Withdrawing a permission is not restricted, because taking authority away is what a user administrator is for. Only an administrator can move the Admin flag, in either direction, and the primary administrator cannot be demoted, disabled or deleted by anyone else.
The primary administrator
Section titled “The primary administrator”Exactly one account is the primary administrator — by default the built-in admin created on
first start. It carries a primary badge in the Users list. The primary administrator:
- cannot be demoted, disabled or deleted by anyone else — this is the account that can always recover control of the installation;
- is the root of the management hierarchy (below).
To hand the role to another administrator, open Users, and choose Make primary on their row. Only the current primary administrator can do this, and there is always exactly one.
Who can manage whom
Section titled “Who can manage whom”When an administrator grants another user an admin or management role, they become that user’s manager. Tessera then prevents a delegated administrator from turning on the people above them:
- You cannot change the roles, disable, delete or reset the password of your manager, or of anyone further up the chain — all the way to the primary administrator.
- You can manage peers (administrators created alongside you) and anyone you granted a role to.
So an administrator you create can never revoke or lock out the administrator who created them.
Losing access
Section titled “Losing access”If you are ever locked out of single sign-on with password login disabled, use the break-glass recovery on the controller host.
We would like to count visits with Google Analytics, which needs a cookie. Nothing is loaded and nothing is stored unless you accept. What this sets.