- 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
Account Types
The UiPath Identity Server stores local accounts and the roles assigned to them, but also validates any directory accounts used in Orchestrator.
An account that was created and can be managed from Identity Server, through the Management portal, is considered to be local to the UiPath ecosystem. For local accounts, all account attributes like name and email address are stored in Identity Server.
User accounts that originate from a directory outside of the UiPath ecosystem (for example, from Azure Active Directory) are directory users. These accounts can access Orchestrator and can receive roles if you integrate with the directory.
For directory users, only role assignments and Orchestrator-specific settings are managed within the UiPath ecosystem, in Identity Server and Orchestrator, while the external directory admin manages account-specific attributes (name, email, directory group membership).
There are two ways to grant a directory user access to Orchestrator:
- By assigning roles in Orchestrator to the directory user - we refer to it as an individually-added user.
- By logging in with an account that belongs to a directory group which was previously added to Orchestrator - we refer to this as an auto-provisioned user. See About Users for more information.
Regardless of their type, directory users always inherit roles from the groups to which they belong, if they exist in Orchestrator.
Local groups are entities originating in Identity Server which represent a collection of user and robot accounts. You can assign roles and licenses to groups as opposed to assigning them to individual users. Anything assigned to the group is automatically assigned to all group members.
An entity created by referencing a group from a linked directory in your Orchestrator instance. All members of the group are potential users of Orchestrator. All roles assigned to a group are inherited by the users that belong to that group, auto-provisioned or individually-added.
- A user who belongs to multiple groups inherits roles from all of them.
- A user who belongs to multiple groups, and has also been granted roles explicitly, has the union of all the roles inherited and explicitly assigned.
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.
- 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 accounts are helpful for when you need to run back-office unattended processes that should not be the responsibility of any particular user. These are our RPA-specific equivalent of service accounts. Similar to the accounts that Windows services run as application identities in the OAuth model, they are a non-user identity to be used to run unattended processes.
Working with robot accounts
Robot accounts behave like user accounts in terms of permissions. In UiPath Orchestrator, you can add robot accounts and configure permissions for them in the same way as for any other account.
The only differences compared to user accounts are:
- robot accounts are not allowed any interactive-related process configuration
- no email address is required to create a robot account.
You can find and work with robot accounts in broadly the same way as you work with user accounts:
-
Administrators can create and manage robot accounts from the Admin > Accounts & Groups page - except not from the Users tab, but from the dedicated Robot accounts tab.
Robot accounts can also be included in groups and managed as part of the group.
- When assigning roles in Orchestrator, searching for accounts shows users, groups, and also robot accounts for selection.
For classic folders, when you manually deploy a robot to Orchestrator, a robot entity is automatically created, viewable on the Robots tab.
Robot users have the Robot role assigned to them by default.
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.
