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 local users.
There two ways to convert local users that log in with AD credentials into directory users:
- Set the
WindowsAuth.ConvertUsersAtLoginapp setting to
True. This converts each local AD user into a directory user after the first login with AD credentials. This only works if the login is performed on the Orchestrator Login page.
- 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.
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
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:
- By adding an AD user by itself - we refer to it as an individually-added user.
- 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.
Regardless of their type, directory users always inherit access-rights from the parent group, if it exists in Orchestrator.
Can have explicit access-rights
AD is the central hub for user information
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 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.
|Dirctory 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 persists between sessions, regardless of the group's state.
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.
Updated 2 months ago