Accounts and Groups

On the Accounts & Groups page you can define local user accounts, robot accounts, and local groups for your organization.

The level of access and the actions that your users can perform is controlled using two elements:

• accounts, which establish the identity of a user and are used to log in to your UiPath applications
• roles, which are assigned to accounts in order to grant them certain permissions within the UiPath ecosystem.

Accounts are not created or managed in Orchestrator, only roles and their assignments are.

About Accounts

An account is a UiPath platform entity with access-dependent capabilities whose view and control of Orchestrator rely on the assigned access rights.

Accounts can be:

• created and managed locally (local accounts) from the:

  • Management portal. See Managing accounts for more information.
• created and managed in an external directory (directory accounts and directory groups). See the section AD Integration for a better understanding of directory integrations.

You add accounts from the organization-level Management portal and accounts are only available within the respective organization.

Once an account has been successfully added, there are two ways of granting them access-rights to Orchestrator: by adding the account to a group so that it inherits the roles of the group, or by assigning roles to each account at the service level. You can use both methods for granular control over the access an account has in your organization.

Note: In modern folders, robot management is performed at the user level. See Managing accounts for details.

AD Integration

An active directory (AD) referenced in Orchestrator makes its members potential Orchestrator users. The level of access for a directory account is configured in Orchestrator, either at the group level (directory group) or at the user level (directory user).

You can integrate with:

• a local Active Directory ( standalone Orchestrator )

• Azure Active Directory ( standalone Orchestrator )

  Note: Using an AD integration together with attended robots auto-provisioning and hierarchical folders allow for effortlessly setting up large deployments. See Managing large deployments for details.

Prerequisites

• The WindowsAuth.Domain parameter is filled in with a valid domain. All domains and subdomains from forests 2-way trusted with the domain specified in the WindowsAuth.Domain parameter are available when adding users/groups.
• The machine on which Orchestrator is installed is joined to the domain set in the WindowsAuth.Domain parameter. To check whether the device is joined to the domain, run the dsregcmd /status from the Command Prompt, and navigate to the Device State section.
• The identity under which the Orchestrator application pool is running must be a part of the Windows Authorization Access group (WAA).

Behavior

• Adding a directory group creates a user group entity in Orchestrator for which you configure access rights as desired. This entry in Orchestrator serves as a reference to the group as found in AD.
• When logging in, Orchestrator checks your group memberships. If confirmed, it automatically provisions your user account, and then associates it to the access rights inherited from the group. Inherited rights are only kept for the duration of the user session.
• Auto-provisioning takes place the first time you log in. An auto-provisioned user account doesn't get deleted at log out as you might need the entry for audit purposes.

• Group membership for an account is checked by Orchestrator at login, or once every hour during active sessions. If an account's group memberships change, for the account the changes apply the next time the account logs in or, if currently logged in, within one hour.

  This one hour interval for checking group membership can be changed by setting the value of IdentityServer.GroupMembershipCacheExpireHours.

• Groups in AD sync with Orchestrator, but changes made in Orchestrator do not affect user configuration in AD.
• AD users whose inherited access-rights (from group memberships) cannot be determined behave like local users, meaning they rely solely on roles assigned to the user account.
• The only way for you to configure access rights which persist between sessions, regardless of how group membership changes, is to directly assign the role to the user account in Orchestrator, as opposed to using groups to assign roles.

Known issues

• Due to various networking or configuration issues, there is a chance that not all domains displayed in the Domain Name drop-down list are accessible.
• Changes made to user or group names in AD are not propagated to Orchestrator.
• It can take up to an hour to update the domain list with newly added two-way trusted domains.
• The GetOrganizationUnits(Id) and GetRoles(Id) requests only return folders and roles explicitly set for an auto-provisioned user. The ones inherited from the group configuration can be retrieved through the /api/DirectoryService/GetDirectoryPermissions?userId={userId} endpoint.
• Same goes for the user interface, where only explicitly-set folders and roles are displayed on the Users page. In contrast, inherited ones have a new dedicated location, the User Permissions window (Users > More Actions > Check Permissions).
• Users do not inherit alert subscription settings from the parent group, nor do they receive any alerts by default. To have access to alerts, you are required to grant the corresponding permissions to the user explicitly.
• Removing a directory group does not remove the license of an associated directory user, even if the group removal unassigns the user from any folder. The only way to release the license is to close the Robot tray.
• On certain browsers, logging in to Orchestrator using your AD credentials only requires your username. There is no need to also specify the domain. Hence, if the domain\username syntax does not work, try filling in the username only.

Audit considerations

• User membership: User [username] was assigned to the following Directory Groups [Directory Groups the user inherits access rights from in the current session].
• Auto-Provisioning: User [username] was automatically provisioned from the following Directory groups [Directory Groups the user inherits access rights from in the current session].

User Types

Group

Groups let you manage several users at a time, by applying the same roles and configuration to them through the group.

• The membership of a user is set from Admin > Accounts & Groups.

• User groups enable automatic access with the group permissions, based on users being added or removed from the group with no need to manage user permissions individually.

• There are 4 default local groups: Administrators, Automation Users, Automation Developers, Everyone. All groups come with a default set of permissions in each new service you create. The out-of-the-box roles can be customized later on for each Orchestrator service.

• If you need more than the 4 default groups provided by UiPath, you can create custom local groups. Unlike default local groups, custom groups need to be added manually in Orchestrator to ensure the correct mapping between the group membership of a user and the corresponding role in Orchestrator.

A group's roles are passed on to any users that belong to the group, both auto-provisioned or manually-added. We refer to them as "inherited roles" as opposed to "directly-assigned roles" which can only be set per account.

Note:

• A user that belongs to multiple groups inherits access rights from all of them.
• A user who belongs to multiple groups, and has been assigned roles directly as well, has the union of all the roles inherited from groups and directly assigned.
• You don't need an explicit user account to log in to Orchestrator if you belong to a group that has been added to Orchestrator.
• Inherited roles are dependent on the associated user group. If the group is deleted from the service, so are the inherited roles of that account.
• Directly-assigned roles are not influenced by groups that the account is in. They persist regardless of the group state.

Example

Say I added John Smith to the Automation Users and Administrators user groups in my Automation Cloud organization.

• The Automation User group exists in the Finance Orchestrator service
• The Administrator group exists in the HR Orchestrator service
• Directly assigned roles to John's account in both services as well.

John has the union of inherited and explicit rights for each service:

Service/Roles	User Groups	Inherited Roles	Explicit Roles	Overall
Finance tenant	Automation User
Tenant Level Roles	Allow to be Automation User	Allow to be Automation User	Allow to be Folder Administrator	Allow to be Automation User Allow to be Folder Administrator
Folder Level Roles	Automation User on Folder A Automation User on Folder B	Automation User on Folder A Automation User on Folder B	Folder Administrator on Folder A	Automation User on Folder A Automation User on Folder B Folder Administrator on Folder A
HR tenant	Administrators
Tenant Level Roles	Allow to be Folder Administrator	Allow to be Folder Administrator		Allow to be Folder Administrator
Folder Level Roles	Folder Administrator on Folder D Folder Administrator on Folder E	Folder Administrator on Folder D Folder Administrator on Folder E	Folder Administrator on Folder F	Folder Administrator on Folder D Folder Administrator on Folder E Folder Administrator on Folder F

User

According to the mechanism used for adding user accounts in Orchestrator, they can be classified into two categories:

Manually-added users

Users that have been manually added in Orchestrator and have been granted permissions explicitly either at the tenant level or at the folder level. Manually-added user accounts inherit group access rights if they belong to a group that has been added to that Orchestrator service as well.

Auto-provisioned users

Users that have been added to a local group and log in to Orchestrator. They can access Orchestrator based on the permissions inherited from the group. Once they log in to Orchestrator for the first time, they are automatically provisioned.

Note: On the Users page, in the Roles column, you can see explicitly assigned roles for a user, be it manually added or auto-provisioned. Inherited roles are not displayed in this column.

You can check the entire permission set of a user, inherited ones included, by navigating to More Actions > Check Permissions > User Permissions window for that specific user.

Manually Added User	Auto-provisioned User
Inherits access rights
Can have explicit access rights
Cloud Portal is the central hub for user information
SSO

Robot

The Robot user is automatically created when you manually deploy a Robot to Orchestrator. Robot users have the Robot role by default. This role grants your Robot access to multiple pages, making it able to perform various actions.

Account and Group Icons

On pages where you manage accounts, groups, or roles, specific icons are displayed for each type to help you recognize the type of account or the type of group.

Account icons

- UiPath user account: user account that is linked to a UiPath account and signed in using basic authentication

- SSO user account: user account linked to a UiPath account that signed in using SSO; also applies to user accounts that have both a UiPath user account and a directory account

- Directory user account: the account originates from a directory and signed in with Enterprise SSO

- Robot account

Group icons

- Local group (or plainly, group): the group was created by a host administrator.

- Directory group: the group originates in a linked directory.

About Roles

Orchestrator uses an access-control mechanism based on roles and permissions. Roles are collections of permissions meaning that the permissions needed to use certain Orchestrator entities are assigned to roles.

Role-permissions and user-roles relationships allow for a certain level of access to Orchestrator. A user gets the permissions required to perform particular operations through one or multiple roles. Since users are not assigned permissions directly, but only acquire them through roles, management of access rights involves assigning appropriate roles to the user.

See for more information.

Permissions for Managing Users

To be able to perform various operations on the Users and Roles pages, you need to be granted the corresponding permissions:

• Users - View - Displaying the Users and Profile pages.
• Users - Edit - Editing user details and settings on the Profile page, and activating/deactivating users on the Users page.
• Users - View and Roles - View - Displaying user permissions in the User Permissions window.
• Users - Edit and Roles - View - Editing role assignments on the Manage Access > Assign Roles page.
• Users - Create and Roles - View - Creating a user.
• Users - View and Roles - Edit - Managing roles in the Manage Users window, opened from the Manage Access > Roles page.
• Users - Delete - Removing a user from Orchestrator.