📘

In modern folders robot management is done at user level. See here details on how to proceed.

A user is an entity with access-dependent capabilities whose view and control of Orchestrator rely on the assigned access-rights. Users can be created locally in Orchestrator (Local Users) or they can be created and managed in an external directory (Directory Users). For a better understanding of how directory integration works, we strongly suggest reading the corresponding section below. User types are described here.
User management is done primarily from the Users page (Management menu > Users). This page displays all available users, enables you to add or remove them, and to edit their details within the restrictions imposed by the user type.

AD Integration

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

📘

AD integration alongside Attended Robots auto-provisioning and hierarchical folders sets the stage for effortless large deployments. See here how to manage such a deployment in Orchestrator.

Prerequisites

• The WindowsAuth.Enabled parameter is set to true.
• The WindowsAuth.Domain parameter is filled in with a valid domain. All domains and subdomains from forests that are 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 or not 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 ApplicationPool is running needs to be a part of the Windows Authorization Access group (WAA).

Behavior

1. Adding an AD group creates a user entity in Orchestrator called Directory Group, for which you configure access rights (roles and folders) as desired. This entry serves as a reference to the group as found in AD.
2. When logging in, Orchestrator checks your group membership against the AD database. If confirmed, it automatically provisions your user as a Directory User, and then associates it to the access rights inherited from the Directory Group (step 1). Inherited rights are only kept for the duration of the user session.
3. Auto-provisioning takes place the first time you log in. An auto-provisioned user doesn't get deleted at log out as you might need the entry for audit purposes.
4. Changes made to AD group membership 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 parameter in web.config. 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. 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.
5. The only way for you to configure access rights which persist between sessions, regardless of how group membership changes, is to set them up explicitly per user in Orchestrator. We refer to them as explicit access-rights.
6. AD users whose inherited access-rights cannot be determined behave like local users, meaning they rely solely on explicitly-set access-rights.
7. Groups in AD sync with Orchestrator, but not the way around. Changes made to 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 are accessible.
• Changes made to AD user/group names 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, while inherited ones have a new dedicated location, the User Permissions window (Users > More Actions > Check Permissions).
• Auto-provisioned users do not inherit alert subscription settings from the parent group, nor do they receive any alerts by default. In order to have access to alerts you are required to explicitly grant the corresponding permissions to the user.
• 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 [Directory Groups the user inherits access rights from in the current session].

The Admin User

Orchestrator comes with one predefined user only: admin. Its username cannot be changed, and it cannot be deleted. It has the Administrator role, but you can add other roles to it, and even deactivate it. Note that you can not deactivate the user you are currently logged in with.

Users with the Administrator role can activate, deactivate, and remove other users as well as edit information, including the password. You cannot delete users that have the Administrator role.

Personal Workspaces

For users and directory groups to which you grant robot access using attended modern robots, you can also enable the creation of a Personal Workspace. If enabled, this workspace is automatically created for each user when their robot session is connected. In effect, this workspace is a new modern folder available only for the dedicated use of each particular user. In this workspace, each user can then store:

• Packages / Processes
• Jobs
• Assets
• Logs
• Queues (and Queue Items)
• Storage Buckets (if the functionality is enabled at Tenant level)

Packages stored in a user's personal workspace exist outside of the main Orchestrator feed and thus are not visible or accessible by other users. For each package uploaded a corresponding process is automatically created (or updated in the case of existing packages and processes), enabling the user to launch their automation almost instantly after publication, no Orchestrator access or actions needed.

Users Permissions

In order to be able to perform various operations on the Users and Profile pages, you need to be granted the corresponding permissions:

• View on Users - Displaying the Users and Profile pages.
• Edit on Users - Editing user details and settings on the Profile page, and activating/deactivating users on the Users page. Configuring the Alerts section on the Profile page requires the corresponding View permissions per alert category. Details here.
• View on Users, View on Roles - Displaying user permissions on the User Permissions window.
• Edit on Users, View on Roles - Editing user details and settings on the Users page.
• Create on Users, View on Roles - Creating a user.
• View on Users, Edit on Roles - Managing user roles on the Manage Users window, in the Roles page.
• Delete on Users - Removing a user.

Read more about roles.

Security Considerations

Basic Authentication

By default, Orchestrator does not allow user access via basic authentication. Basic authentication can be enabled by adding and configuring the Auth.RestrictBasicAuthentication setting in your web.config file. This enables you to create local users that can access Orchestrator using their basic authentication credentials, allowing you to maintain existing integrations that relied upon basic authentication when calling Orchestrator API's.

Enabling basic authentication can be done when creating or editing users.

Account Lockout

After 10 failed login attempts you are locked out for 5 minutes. These are the default Account Lockout settings which can be changed on the Security tab.
Logging in with the same user on a different machine disconnects the user from the first machine.