- Getting started
- Best practices
- Tenant
- Folders Context
- Automations
- Processes
- Jobs
- Triggers
- Logs
- Monitoring
- Queues
- Assets
- Storage Buckets
- Test Suite - Orchestrator
- Other Configurations
- Integrations
- Classic Robots
- Host administration
- About the host level
- Managing system administrators
- Managing tenants
- Configuring system email notifications
- Audit logs for the host portal
- Maintenance Mode
- Organization administration
- Troubleshooting
Managing Access and Automation Capabilities
On the Manage Access page you can define and assign roles. In Orchestrator, you use roles to control the level of access an account should have. On this page, we go over the notions you need to understand to effectively plan and implement your access control strategy.
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.
An account is a UiPath platform entity with access-dependent capabilities and whose view and control of Orchestrator rely on the assigned roles.
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 integration.
Accounts are only available within the one organization.
Once an account has been successfully added, there are two ways of granting them rights to Orchestrator:
- by adding the account to a group so that it inherits the roles of the group or
- by assigning roles to the account at the service level.
You can use both methods for granular control over the access an account has in your organization.
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
- Azure Active Directory
-
other identity providers that have or connect to a directory
Note: Using a directory 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 authentication option through which you connect to the external directory is enabled.
- A valid domain was specified during authentication configuration. All domains and subdomains from forests 2-way trusted with the specified domain are available when adding users/groups.
- The machine on which Orchestrator is installed is joined to the specified domain. To check whether the device is joined to
the domain, run
dsregcmd /statusfrom 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 an entity in Orchestrator called a directory group, for which you configure access rights as desired. This entry serves as a reference to the group as found in AD.
- When logging in, Orchestrator checks your group membership against the AD database and UiPath Identity Server. If confirmed, it automatically provisions your user as a directory user, and then associates it to the access rights inherited from the Directory Group. Inherited rights are only kept for the duration of the user session.
- Auto-provisioning takes place the first time a user logs in. An auto-provisioned user account doesn't get deleted at log out as you might need the entry for audit purposes.
-
Changes made to group membership in the directory are synced with Orchestrator at every log-in or once every hour for active user sessions.
-
This value can be changed using the WindowsAuth.GroupMembershipCacheExpireHours.
-
If you are a member of X group, what happens is this:
-
You log in, Orchestrator checks your group membership, then confirms your identity against the AD database and Identity Server. You are then granted access rights according to your Orchestrator configuration. If your system administrator changes your group membership from group X to group Y while you have an active session, the changes are interrogated by Orchestrator once every hour or the next time you log in.
- The only way to configure access rights that persist between sessions, regardless of how group membership changes, is to assign a role to the user account directly and not through group membership.
- 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.
- Groups in AD sync with Orchestrator, but changes made in Orchestrator do not affect user configuration in AD.
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)andGetRoles(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].
To be able to perform various operations on the Users and Profile 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.
- 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.
Although you can select all available rights (View,Edit,Create, or Delete) for any permission, the following rights have no effect for the listed permission:
|
Permission |
Category |
|---|---|
|
Edit |
|
|
Create |
|
|
Delete |
|
This is because, for example, it is not possible to edit system-generated logs.
By default, Orchestrator does not allow user access via basic authentication. This functionality can be enabled by adding and configuring the Auth.RestrictBasicAuthentication setting. This enables you to create local accounts that can access Orchestrator using their basic authentication credentials, allowing you to maintain existing integrations that relied on basic authentication when calling Orchestrator API.
Enabling basic authentication can be done when creating and editing accounts.
By default, after 10 failed login attempts, you are locked out for 5 minutes.
System administrators can customize the Account Lockout settings from the host Management portal.
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.
1. What happens access-wise to a user that belongs to multiple groups?
The user receives the union of access rights associated to each group he belongs to.
Example: John Smith belongs to the HR and Finance groups which have been added to Orchestrator. HR group has the Management role and access to the HR folder, Finance has the Executor role, and access to the Finance folder. Being part of both groups, John has the Management and Executor roles and access to both the HR and Finance folders.
2. What happens access-wise when a user is also added separately alongside a group it belongs to?
The user receives the union of access rights associated to the group he belongs to and the ones explicitly set. Keep in mind that inherited access rights are dependent on group settings, and that explicitly set access rights are independent of group settings.
Example: John Smith has been individually added from AD and explicitly given the Executor role, and access to the Finance folder. The HR group (of which John is a member) has been also added to Orchestrator, and given the Management role and access to the HR folder. John has the Executor and Management roles, and access to both the HR and Finance folders. If he is removed from the HR group at AD level, he loses the Management role and access to the HR folder, but keeps the ones set explicitly.
3. My user belongs to two groups, the first one allows automatic Robot creation, the second doesn't. Does a Robot get created for my user or not?
Since a user receives the union of rights associated to all the groups he belongs to, a Robot gets created for your user based on the configuration made for the first group.
4. I deleted/deactivated a directory group. Will the associated directory users still be able to log in?
No, if you did not set access-rights explicitly for them. Yes, if you granted them access-rights individually in Orchestrator. Inherited access-rights are are only kept for the duration of the active user session. Only explicitly set access rights persist between sessions. Deleting or deactivating a directory group deletes inherited rights, but does nothing to those which have been explicitly set.
5. When do changes made to an AD group take effect in Orchestrator?
WindowsAuth.GroupMembershipCacheExpireHours parameter.
