- 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
- 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
Configuring the Active Directory Integration
You can enable SSO using Windows authentication and enable the directory search functionality with the Active Directory integration. Directory search lets you search for directory accounts and groups from Orchestrator and work with them as you would with local accounts.
user@domain
. Thus the user can no longer use their original username to sign in and must instead use the new username in the format user@domain
, or the email address tied to the Active Directory account.
Prerequisites
- To integrate with Windows Active Directory (AD) and use Windows Authentication, LDAP port 389 must be accessible on one or more domain controllers in your domain.
- Work with your IT administrators to ensure the Orchestrator server can access your Active Directory (AD).
-
If you plan on using LDAP over SSL (LDAPS), you must obtain and install certificates for configuring secure LDAP on each domain controller. For more information and instructions, see the LDAP over SSL (LDAPS) Certificate article on the Microsoft website.
When users log in to Orchestrator with their Active Directory credentials, Orchestrator uses the Kerberos protocol to authenticate users.
If you do not want to use the Kerberos protocol for authentication, skip to the next step.
Requirements for multi-node clusters
- The nodes in the cluster must be deployed under a load balancer. Use the load balancer host name whenever the hostname is required in these instructions.
- The Orchestrator application pool must be configured to run under a custom identity. The custom identity should be a domain account.
This is only required if you are running a multi-node cluster, or a single-node cluster with a load balancer.
For single-node clusters with no load balancer, this is optional.
If the Orchestrator application pool is configured to run under a custom identity, that account must have an SPN registered for the host name.
This step is required if you are running:
- a multi-node cluster because you must define a custom identity or
- a single-node cluster with a load balancer, which is treated the same as a multi-node cluster.
This step is not required if:
- you are running a single-node cluster with no load balancer and
- you chose to use a custom identity, but you used the cluster computer name as the custom identity
On a domain-joined machine that has write access in the target Orchestrator organization and tenant:
Now that the integration is configured, we recommend performing a test login using AD credentials and verifying that your chosen authentication protocol (NTLM or Kerberos) is used for logging in.
In Google Chrome incognito mode, the browser prompts for credentials and it does an explicit authentication with credentials. The flow does work and it uses Kerberos.