- Getting started
- Best practices
- Tenant
- About the Tenant Context
- Searching for Resources in a Tenant
- Managing Robots
- Connecting Robots to Orchestrator
- Storing Robot Credentials in CyberArk
- Storing Unattended Robot Passwords in Azure Key Vault (read only)
- Storing Unattended Robot Credentials in HashiCorp Vault (read only)
- Storing Unattended Robot Credentials in AWS Secrets Manager (read only)
- Deleting Disconnected and Unresponsive Unattended Sessions
- Robot Authentication
- Robot Authentication With Client Credentials
- SmartCard Authentication
- Configuring automation capabilities
- Managing Machines
- Assigning Machine Objects to Folders
- Configuring Account-machine Mappings
- EDR Protection Status
- Audit
- Settings - Tenant Level
- Resource Catalog Service
- Folders Context
- Automations
- Processes
- Jobs
- Triggers
- Logs
- Monitoring
- Queues
- Assets
- Storage Buckets
- Test Suite - Orchestrator
- Other Configurations
- Integrations
- Host administration
- Organization administration
- Troubleshooting
Orchestrator User Guide
Configuring Account-machine Mappings
This article walks administrators through the procedure for configuring specific account-machine pairs as the only valid targets for execution, by linking the accounts that usually log in on specific host machines to the associated machine templates.
The account-machine mappings functionality gives administrators granular control over jobs' execution targets, by restricting users to executing automations on machines on which they log in. Specifically, you can tie unattended usage under particular accounts to specific machine templates such that when starting a job or configuring a trigger, only those account-machine pairs can be used for execution.
According to their scope, there are two types of account-machine mappings:
- tenant-scoped mappings - impact all folders in a tenant;
- folder-scoped account-machine mappings - tied to a specific folder.
Accounts are depicted on the Account-Machine Mappings page using the credentials (Domain\Username) of their unattended robot if one has been created.
All changes made to tenant-scoped mappings are reflected at a folder level as follows:
- Inherit from tenant - all account configuration changes made for tenant mappings are reflected at a folder level, adding or removing accounts to tenant mappings adds/removes them from folder mappings as well.
- Specific account-machine mappings for this folder - adding an account to tenant mappings does not make them available for folder mappings; the account is excluded from folder mappings. Removing an account from tenant mappings removes them at the folder level as well.
Folder-scoped mappings are subsets of tenant-scoped mappings and they control the account-machine pairs allowed to execute automation in a folder. Not providing folder-scoped mappings leaves template-scoped mappings in place as the defaults.
You can configure folder-scoped mappings at the tenant level (Tenant > Folders), or you can configure them directly at the folder level (Folder > Machines).
Here's a short video on how to configure folder-scoped account-machine mappings at the tenant level.
Here's a short video on how to configure folder-scoped account-machine mappings at the folder level.
- Accounts added to a folder after account-machine mappings have been configured are not added to the existing mappings; hence, they will not be able to use that machine. Make sure to manually map the accounts to the machines in order to use them.
- Accounts part of mappings that are employed in triggers cannot be deleted or unassigned from the folder the trigger resides in. Make sure the account is not set as an execution target in a trigger so you can delete them.