Subscribe

UiPath Automation Suite

The UiPath Automation Suite Guide

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 and work with them as you would with local accounts.

Known limitations

  • Directory search does not find users from an external trust domain. This feature is not supported because there isn't a mutually-trusted authority with external trusts.
  • Windows authentication uses the Kerberos protocol in Automation Suite, therefore Windows login can only be used with domain-joined machines.

Step 1. Configure the Active Directory integration


Work with your IT administrators to ensure the Automation Suite cluster can access your Active Directory (AD).

The Active Directory integration can be configured using one of two options:
a. Kerberos authentication
b. username and password

Instructions for each are available below. Follow the ones that apply for your selected authentication protocol.

Kerberos authentication is recommended because it supports more scenarios:

Scenario

Username and password

Kerberos Authentication

Directory search for domains in the same forest

Supported

Supported

Directory search for domains in a trusted forest

Not supported

Supported

Directory search for external trust domains

Not supported

Not supported

a. Kerberos configuration (recommended)

  1. Configure Kerberos authentication following the instructions in Setting up Kerberos authentication.
  2. Log in to the Automation Suite host portal as a system administrator.
  3. Go to Security Settings.
  4. In the External Providers section, click Configure under Active Directory.
    • Select the Enabled checkbox to enable the integration.
    • Select the Force automatic login using this provider checkbox if you want to only allow login with Active Directory accounts. Only do this if the integration with the provider has been successfully validated to prevent lockout.
    • In the Display Name field, type the text you want to show under this login option on the Login page.
    • Leave the Use Kerberos Auth checkbox selected.
  5. Click Test and Save to save your changes.
  6. Restart the identity-service-api-* pod.
    a. Connect to the primary server using SSH.
    b. Run the following command:
    kubectl -n uipath rollout restart deployment identity-service-api

b. Username and password configuration

When you use this option, UiPath service uses credentials provided in clear text to communicate with Active Directory. To prevent this, we recommend using LDAP over SSL (LDAPS) with this configuration.
Only users from the same forest as the one configured in this page can interact with the UiPath cluster. Users from trusted forests will not be able to login to this UiPath cluster.

b.1. Prerequisite for using LDAPS

If you intend to use LDAP over SSL (LDAPS), then you must first configure LDAP over SSL in your AD environment and obtain the root certificate to be used in UiPath cluster configuration.

  1. Obtain and install the SSL certificate for LDAPS on each domain controller.
    For more information and instructions, see the article LDAP over SSL (LDAPS) Certificate.
  2. Encode the root certificate in Base64 by running the following command:
[Convert]::ToBase64String([System.IO.File]::ReadAllBytes("<Path to the .crt or .cer file>"))
  1. Add the encoded root certificate in ArgoCD:
    a. Log in to ArgoCD.
    b. Select and go to the uipath application.
    c. In the top left corner, click APP DETAILS.
    d. In the Parameters section, search for the parameter global.userInputs.certificate.identity.ldaps.customRootCA.
    e. Update the value of the parameter to the encoded content you obtained earlier.
    f. Save.
    g. Click SYNC to apply your changes.

b.2. Active Directory configuration

  1. Log in to the Automation Suite host portal as a system administrator.
  2. Go to Security Settings.
  3. In the External Providers section, click Configure under Active Directory.
    • Select the Enabled checkbox.
    • If you want to only allow login with Active Directory accounts, select the Force automatic login using this provider checkbox.
    • (Optional, but strongly recommended) Select the Use LDAP over SSL (LDAPS) checkbox.
    • The Use Kerberos Auth checkbox must be cleared.
    • In the Display Name field, type the name you want to show on the Login page for this sign in option.
    • In the Default Domain field, type your fully-qualified domain name (FQDN) for Active Directory (AD).
    • In the Username field, type the user name of an AD user. It needs to be in the format DOMAIN\username. For example, TESTDOMAIN\user1.
    • In the User Password field, type the password for the above AD account.
  4. Click Test and Save to save the changes.
  5. Restart the identity-service-api-* pod.
    a. Connect to the primary server using SSH.
    b. Run the following command:
    kubectl -n uipath rollout restart deployment identity-service-api

Troubleshooting

Domain unreachable

If you get the error Domain unreachable, check the DNS routing using the command getent ahosts <AD domain>.
If it does not return an IP address, check the node /etc/resolv.conf. The nameserver value should point to the AD Domain DNS. If not, reach out to your system administrator for proper configuration.

If the node runs on Azure, follow the instructions in Name resolution for resources in Azure virtual networks.
One way to do this is:

  1. In Azure, go to the node virtual network and set the virtual network DNS servers to the Active Directory DNS.
  2. Run systemctl restart NetworkManager.service and check if /etc/resolv.conf is updated.
  3. Restart the cluster core DNS from ArgoCD.

Domain unreachable while using LDAPS

If you get the error Domain unreachable when LDAPS is enabled, it may be caused by having the wrong certificate in use.

Check if you have multiple certificates valid for Server Authentication in the LDAP server's local computer certificate store. If so, a different certificate than the one you want may be used for LDAPS communications.
The easiest resolution is to remove all unnecessary certificates from the local computer certificate store and have only one certificate that is valid for server authentication.

 

Step 2. Configure Windows Authentication


Prerequisite

Obtain the <KERB_DEFAULT_KEYTAB>, which is the base64-encoded string of the keytab file generated as part of Kerberos setup.

Configure the Automation Suite cluster

  1. Go to Argo CD and log in as an administrator.
  2. Select and go to the “uipath“ application.
  3. Click APP DETAILS in the top left corner.
  4. In the PARAMETERS section, search for the global.userInputs.identity.krb5KeytabSecret parameter.
    The parameter has a placeholder value by default.
  5. Update the parameter's placeholder value with <KERB_DEFAULT_KEYTAB>, and then save.
  6. Click SYNC to apply the change.
  7. After a successful sync, run the command kubectl -n uipath rollout restart deployment identity-service-api to restart the Identity Server.

Step 3. Browser configuration


Microsoft Internet Explorer

Not supported.

Microsoft Edge

No additional configuration required.

Google Chrome

Normally, Google Chrome works without additional configuration.
If it does not, follow the below instructions.

  1. Go to Tools > Internet Options > Security.
  2. Select Local Intranet.
  3. Click Sites.
  4. Make sure that Automatically detect intranet network is selected or that all of the options are selected.
  5. Click on Advanced.
  6. Add the Automation Suite FQDN to the Local Intranet.
  7. Click Close and OK.
  8. Click on Custom Level.
  9. Optionally select Automatic logon only in Intranet zone under User Authentication
    If selected, when the browser receives the redirect authentication request, it checks the source of the requirement. If the domain or IP belong to the Intranet, the browser sends the user name and password automatically. If not, the browser opens a user name and password input dialog, and expects manual input.
  10. Optionally select Automatic logon with current user name and password under User Authentication.
    If selected, when the browser receives the redirect authentication request, it sends the user name and password silently. If the authentication result is successful, the browser continues to the original action. If the authentication fails, the browser opens a user name and password input dialog, and retries until successful.
  11. Make sure that Enable Integrated Windows Authentication is selected under Internet Options > Advanced tab and in the Security section.

Mozilla Firefox

  1. Open the browser configuration window.
  2. Type about:config in the address bar.
  3. Specify the Automation Suite FQDNs for which you use Kerberos authentication:
    a. Search for the term network.negotiate.
    b. Enable and set the following for Kerberos: network.negotiate-auth.delegation-uris (example value: uipath-34i5ui35f.westeurope.cloudapp.azure.com), network.negotiate-auth.trusted-uris (example value: uipath-34i5ui35f.westeurope.cloudapp.azure.com), and network.negotiate-auth.allow-non-fqdn (value: true).

Step 4. Allow Windows Authentication for the organization


Now that Automation Suite is integrated with Windows Authentication, users for which a user account is created in Automation Suite can use the Windows option on the Login page to sign in to Automation Suite.

Each organization administrator must do this for their organization if they want to allow login with Windows credentials.

  1. Log in to Automation Suite as an organization administrator.
  2. Assign an organization-level role to an Active Directory user or group, which you can select from search.
  3. Repeat the above step for each user you want to allow to log in with Windows Authentication.

The users to which you assigned roles can then log in to the Automation Suite organization with their Active Directory account. They must log in from a domain-joined machine.

Troubleshooting

If you receive a HTTP 500 error when trying to log in using Windows credentials, here are some things to check:

a. Is the Windows machine domain-joined?
On the machine, go to Control Panel > System and Security > System and check if a domain is shown. If no domain is shown, add the machine to the domain. Machines must be domain-joined to use Windows Authentication with the Kerberos protocol.

b. Can you log in to the Windows machine with the same credentials?
If not, ask your system administrator for help.

c. Are you using a browser other than Microsoft Edge?
Additional configuration is required for supported browsers other than Microsoft Edge.

d. Check the keytab configuration:

  • After generating the keytab, on the Active Directory server, the AD user's property (servicePrincpalName) should be of the form HTTP/<Service Fabric FQDN> - for example, HTTP/uipath-34i5ui35f.westeurope.cloudapp.azure.com.

  • The option This account supports Kerberos AES 256 bit encryption must be selected for the user account in AD.
    If this is improperly configured, in the identity-service-api log, you can see:

Microsoft.AspNetCore.Authentication.Negotiate.NegotiateHandler An exception occurred while processing the authentication request.
GssApiException*GSSAPI operation failed with error - Unspecified GSS failure. Minor code may provide more information (Request ticket server HTTP/[email protected] kvno 4 enctype aes256-cts found in keytab but cannot decrypt ticket).* at Microsoft.AspNetCore.Authentication.Negotiate.NegotiateHandler.HandleRequestAsync()

e. If you have multiple Active Directories configured in the domain you are using, authentication fails, and in the identity-service-api log, you can see:

kinit: Client '[email protected]' not found in Kerberos database while getting initial credentials

In this case, make sure the machine account created for authentication is replicated to all Active Directories.

f. If you run ktpass and assign a new password to the user account, the key version (kvno) increases and invalidates the old keytab. In the identity-service-api log, you can see:

Request ticket server HTTP/rpasf.EXAMPLE.COM kvno 4 not found in keytab; ticket is likely out of date

In this case, you need to update krb5KeytabSecret in ArgoCD.

g. If you see the following error in the identity-service-api pod:

GssApiException*GSSAPI operation failed with error - Unspecified GSS failure. Minor code may provide more information (Keytab FILE:/uipath/krb5/krb5.keytab is nonexistent or empty).

First check if you provided the global.userInputs.identity.krb5KeytabSecret parameter in ArgoCD.
If the parameter exists, verify if you can log into the Windows machine with the credentials of the AD user used to generate the keytab. Note that you must regenerate the keytab if the password was changed or expired.
Another possible cause of this issue is that ArgoCD was previously synced incorrectly. To fix the problem, remove the existing global.userInputs.identity.krb5KeytabSecret, sync ArgoCD, and once the operation is successful, update global.userInputs.identity.krb5KeytabSecret, and sync again.

h. Does the browser use the expected SPN?
If Kerberos event logging is enabled by following these instruction, you will see the KDC_ERR_S_PRINCIPAL_UNKNOWN error in the Kerberos event logs. For details on this issue, see Microsoft documentation.
To solve this issue, disable the CNAME lookup when negotiating Kerberos authentication by modifying the group policy. For details, see instructions for Google Chrome and for Microsoft Edge.

Updated about a month ago


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 and work with them as you would with local accounts.

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.