User Types

Local User

Local users can only be created in Orchestrator. Attributes like name and email are managed in Orchestrator, along with roles and other Orchestrator-specific settings. It is used to log into Orchestrator, have a custom view of Orchestrator, depending on your position within the automating team, and, optionally, to receive email alerts. You cannot change the username of this type of user.

Local users are added by creating the user, setting user attributes, and assigning roles. Two pages contain user-pertaining information: the User page and the Profile page. Populating one of them overwrites the associated information in the other one (name, surname, email address).

Converting Local AD Users Into Directory Users

There two ways to convert local users that log in with AD credentials into directory users:

• Set the WindowsAuth.ConvertUsersAtLogin parameter to True. This converts each local AD user into a directory user after the first login with AD credentials.
• Through the below script. This converts all the local AD users that have ever logged in with AD credentials at once.

This feature only works for users logging in using the Login page in Orchestrator. It does not work for users that sign in via Studio, using interactive login.

Important: Once the conversion is complete, you cannot use basic authentication credentials to log in with the respective users any longer.

DECLARE @domain VARCHAR(100) = 'your-domain-name-here'
UPDATE u
SET
    u.[UserName] = CONCAT(u.[UserName], '@', lower(@domain)),
    u.[Type] = 2
FROM
    [dbo].[Users] u
    JOIN [dbo].[UserLogins] l ON u.[Id] = l.[UserId]
WHERE 
    u.[Type] = 0
    AND l.[LoginProvider] = 'Windows'
    AND u.[IsDeleted] = 0

Directory User

For directory users, only roles and Orchestrator-specific settings are managed in Orchestrator, while the external directory admin manages user-specific attributes (name, email, group membership).

A directory user can be created in two ways:

1. By adding an AD user by itself - we refer to it as an individually-added user.
2. By logging in with a user belonging to a previously added AD group - we refer to it as an auto-provisioned user. See more info on the About Users page.

Directory users always inherit access-rights from the parent group if it exists in Orchestrator.

Access	Local User	Directory User
Inherits access-rights
Can have explicit access-rights
AD is the central hub for user information
SSO

Directory Group

A user entity created by referencing an AD group into your Orchestrator instance. All members of the group are potential users of Orchestrator. All access-rights set to a group are passed on to any directory users that belong to that group, auto-provisioned or individually-added. We refer to them as "inherited access-rights" instead of "explicit access-rights" that can only be set individually per user.

• A user who belongs to multiple groups inherits access-rights from all of them.
• A user who belongs to multiple groups, and has been granted access-rights explicitly as well, has the union of all the rights as inherited from parent-groups, and explicitly-set.

Using directory groups enables automatic access with the group permissions, based on users being added or removed from the directory group (when switching departments, for example), with no need to manage user permissions individually.

Example

Directory Groups	Inherited Rights	Explicit Rights
Added group X with X set of access rights and group Y with Y set of access rights.	John Smith belongs to both Group X and Y. He logs in to Orchestrator. His user is auto-provisioned with the following rights: X, Y.	In addition to the X and Y sets, John is also granted the Z set explicitly. John now has the following rights: X, Y, Z. Deleting groups X and Y leaves John with Z.

• You don't need an explicit user entry to log in to Orchestrator, if you belong to a group that has been added to Orchestrator (step 1 - Behavior section).
• Inherited access rights are dependent on the associated Directory Group. If the directory is deleted, so are inherited access-rights.
• Explicitly-set access rights are independent of the Directory Group. They persist between sessions, regardless of the group's state.

Robot

The Robot user is automatically created when you manually deploy a Robot to Orchestrator. Robot users have the Robot role by default.

The Robot role grants your Robots access to multiple pages, making it able to perform various actions. See here the exact permissions of the Robot role.

Service Account

A service account is a non-human account used to provide a security context for running workloads which don't involve the existence of a human account, such as server-to-server authentications. In these cases, Orchestrator assumes the identity of the service account.

Only one service account is created per Orchestrator instance it is not visible in the user interface, and can only be identified in database tables.

There is no authentication information attached to this type of account, and, as such, it cannot log in interactively via browsers or cookies.

We recommend not to disable or delete the service account, as this will have a direct impact on running workloads.