- First Time Configuration
- Host Administration
- Organization Administration
- Accounts and Roles
- Licensing
- Notifications
Configuring the Active Directory Integration
Active Directory integration is not supported with Automation Suite on AKS/EKS.
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.
- 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.
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:
- Kerberos authentication
- username and password
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 |
In an Active Directory environment, LDAPS is a commonly used secure connection for directory services. It is important to note that LDAPS support scenarios differ based on the authentication mechanism used.
Authentication mechanism |
LDAPS support |
---|---|
Username and password |
Supported |
Kerberos authentication |
Not supported |
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.
Known issue: The configured LDAPS certificate is not persisted upon upgrading. As a result, after an upgrade, it is necessary to add the LDAPS certificate again in order for LDAP secure connections to work.
B.2. Active Directory Configuration
<KERB_DEFAULT_KEYTAB>
, which is the base64-encoded string of the keytab file generated as part of Kerberos setup.
Important notes:
Skip this step if you already configured Automation Suite as a Kerberos client following the procedure described in the Configuring Automation Suite as a Kerberos client guide.
If you configured the Active Directory integration through the username and password method, which is not recommended, perform the following steps:
Normally, Google Chrome works without additional configuration.
If it does not, follow the below instructions.
- Open the browser configuration window.
- Type about:config in the address bar.
- Specify the Automation Suite FQDNs for which you use Kerberos authentication:
- Search for the term
network.negotiate
. - 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
), andnetwork.negotiate-auth.allow-non-fqdn
(value:true
).
- Search for the term
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.
- Log in to Automation Suite as an organization administrator.
- Assign an organization-level role to an Active Directory user or group, which you can select from search.
- 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.
If you receive a HTTP 500 error when trying to log in using Windows credentials, here are some things to check:
-
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.
-
Can you log in to the Windows machine with the same credentials?
If not, ask your system administrator for help.
-
Are you using a browser other than Microsoft Edge?
Additional configuration is required for supported browsers other than Microsoft Edge.
- Check the keytab configuration:
- After generating the keytab, on the Active Directory server, the AD user's property (
servicePrincpalName
) should be of the formHTTP/<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/sfdev.eastus.cloudapp.azure.com@EXAMPLE.COM kvno 4 enctype aes256-cts found in keytab but cannot decrypt ticket).* at Microsoft.AspNetCore.Authentication.Negotiate.NegotiateHandler.HandleRequestAsync()
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/sfdev.eastus.cloudapp.azure.com@EXAMPLE.COM kvno 4 enctype aes256-cts found in keytab but cannot decrypt ticket).* at Microsoft.AspNetCore.Authentication.Negotiate.NegotiateHandler.HandleRequestAsync()
- After generating the keytab, on the Active Directory server, the AD user's property (
-
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 'xyz@example.com' not found in Kerberos database while getting initial credentials
kinit: Client 'xyz@example.com' not found in Kerberos database while getting initial credentialsIn this case, make sure the machine account created for authentication is replicated to all Active Directories.
-
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:In this case, you need to updateRequest ticket server HTTP/rpasf.EXAMPLE.COM kvno 4 not found in keytab; ticket is likely out of date
Request ticket server HTTP/rpasf.EXAMPLE.COM kvno 4 not found in keytab; ticket is likely out of datekrb5KeytabSecret
in ArgoCD. -
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).
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, updateglobal.userInputs.identity.krb5KeytabSecret
, and sync again.
-
-
Does the browser use the expected SPN?
If Kerberos event logging is enabled by following these instructions , you will see theKDC_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 .
- Known Limitations
- Step 1. Configure the Active Directory Integration
- A. Kerberos Configuration (recommended)
- B. Username and Password Configuration
- Step 2. Configure Windows Authentication
- Prerequisite
- Configure the Automation Suite Cluster
- Step 3. Browser Configuration
- Microsoft Internet Explorer
- Microsoft Edge
- Google Chrome
- Mozilla Firefox
- Step 4. Allow Windows Authentication for the Organization
- Troubleshooting