Administrator roles and permissions

Not every administrator needs to change everything. Administrator roles let you decide, area by area, what each administrator may look at and what they may change in the console, and let membership of an Active Directory group grant a role automatically.

Administrators and portal users are separate

Console administrators are listed under System → Admin Users, not under Authentication → Users. The Users page and the user group member lists show ordinary portal users only, and administrators do not appear in the access picker as portal users.

There are two ways to be a console administrator:

• A local administrator account, created in DartRelay with the Administrator option ticked. You assign roles to it by name.
• A directory administrator: an Active Directory (or local Windows) account that signs in to the console with its normal Windows credentials and receives roles through its groups. No DartRelay account is created for it.

Both sign in at the console's own sign-in page, /admin. The console is not affected by the per-address sign-in rules under Appearance → Tenancy & Branding, which means you can always get back in to fix a mistake there. Which network addresses may reach the console is a separate setting; see Sign-in protection.

How roles work

A role is a named set of permissions. For each area (module) of the console, a role gives one of three levels:

The modules are grouped the same way as the console menu: General, Catalog, Authentication, Email and System. A few pages belong to a neighbouring module, for example the Directories page belongs to the Authentication Methods module, and the Network Access page to Security.

• Roles add up. An administrator with several roles gets the highest level any of them gives for each module.
• The menu follows the role. Menu entries, and whole menu sections, disappear when the administrator cannot view them.
• Refused actions lead to a page saying the administrator does not have permission.
• Portal access is a separate setting on each role. An administrator whose roles do not allow it cannot use the portal at all. An administrator whose role does allow it sees every resource in the portal, whatever the resource's access list says.

The built-in Full Administrator role

DartRelay always has a role called Full Administrator with full access to everything. It cannot be deleted or deactivated, and its full access cannot be removed.

Administrators with no role

A local administrator account that has no roles assigned at all has unrestricted access, as administrators did before roles existed. Once you give an account a role, its access is limited to what its roles allow. If you later deactivate that role, the account loses the access; it does not fall back to unrestricted.

Create a role

1. Open the roles page. Go to System → Admin Roles. The list shows each role with how many modules it covers, how many directory groups grant it, how many administrators hold it, and whether it allows portal access.
2. Add a role. Give it a name and description, and choose a starting level for every module (None, View or Full). Starting everything at View is a quick way to make a read-only role.
3. Set the permission grid. On the role's page, change the level for each module as needed.
4. Decide about portal access. Allow it only if administrators with this role also need to use the portal.
5. Choose who holds the role. Assign it to local administrator accounts, and/or add directory groups whose members should receive it (see below).
6. Save.

Give a role to an Active Directory group

This lets your existing IT groups manage DartRelay without separate accounts. For example, members of CORP\Helpdesk can sign in to the console with their Windows credentials and receive a Help Desk role.

1. Switch on the sign-in source. Make sure Domain Users (or Windows Users, for local groups) is on in Authentication → Authentication Methods.
2. Open the role under System → Admin Roles.
3. Add the group. In the directory group picker, choose where to look (each listed domain, or the DartRelay server's local groups), search for the group and add it. Groups are stored with their domain, such as CORP\Helpdesk.
4. Save.
5. Try it. Sign in at /admin as a member, using CORP\name or the domain list on the sign-in page. The menu should show only what the role allows.

A domain group and a local Windows group with the same name are different groups: a local group called Admins on the DartRelay server never receives a role given to CORP\Admins. Groups in different domains are kept apart in the same way. Nested group membership counts.

An account that signs in successfully but is in no group that grants a role is refused, with the same "Invalid username or password" message as a wrong password.

Local administrator accounts

Local administrator accounts are managed under System → Admin Users. Turning an account into an administrator, or back into an ordinary user, needs Full permission on Admin Users; Full permission on portal Users alone is not enough. This stops somebody who manages portal users from making themselves an unrestricted administrator.

Safety rails

• You cannot lock everyone out. A save that would leave no active administrator with Full permission on Admin Roles is refused.
• The built-in role stays. Full Administrator cannot be deleted or weakened.
• New console pages are protected by default. A page that does not belong to any module is refused rather than left open.

When changes take effect

An administrator's roles are worked out when they sign in. If you change a role, or add or remove somebody from a group that grants one, the change applies the next time that administrator signs in. Ask them to sign out and back in if you need a change to apply straight away.

Example: a read-only auditor and a help desk

• Auditor: a role created with every module starting at View, no portal access, assigned to the local account auditor. The auditor can open every page, but every Save is refused.
• Help Desk: a role with Full on Users, User Groups and Sessions, View on Hosts and the catalog, and None on System and Email. It is granted to CORP\Helpdesk. Help desk staff reset portal passwords, change group membership and disconnect stuck sessions, but cannot publish applications or change system settings.

If something goes wrong

For directory administrators, the console's sign-in page always says "Invalid username or password", so that it does not reveal which accounts exist. The real reason is written to System → Audit Log.

Related pages