Local User

A user entity that can only be created in Orchestrator. For local users, 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. There are two pages containing 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 Users into Directory Users

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

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

🚧

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 user-specific attributes (name, email, group membership) are managed by the external directory admin.
A directory user can be created in two ways:

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

Directory users, regardless of their type, always inherit access-rights from the parent group, if it exists in Orchestrator.

	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" as opposed to "explicit access-rights" which can only be set individually per user.

• A user which belongs to multiple groups inherits access-rights from all of them.
• A user which 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

• 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.