Active Directory との連携を構成する

Automation Suite の Test Cloud (プライベート) で Active Directory との連携を設定します。必要な設定と検証のガイダンスが含まれます。

警告:

Active Directory との連携は、AKS/EKS の Automation Suite ではサポートされていません。

Windows 認証を使用した SSO を有効化し、Active Directory 連携によるディレクトリ検索機能を有効化できます。ディレクトリ検索を使用すると、ディレクトリ アカウントやグループを検索して、それらをローカル アカウントと同じように扱うことができます。

既知の制限事項

• ディレクトリ検索では、外部の信頼できるドメインからのユーザーは検索されません。外部の信頼できる機関と相互に信頼できる機関がないため、この機能はサポートされていません。
• Windows 認証は Test Cloud (プライベート) で Kerberos プロトコルを使用するため、Windows ログインはドメインに参加しているマシンでのみ使用できます。

手順 1. Active Directory との連携を構成する

Automation Suite のクラスターが Active Directory (AD) にアクセスできることを IT 管理者も交えて確認してください。

Active Directory との連携を構成するには、次の 2 つのオプションのいずれかを使用します。

1. Kerberos 認証
2. ユーザー名とパスワード

Kerberos 認証は、次の表に示すように、より多くのシナリオをサポートするため、推奨されます。

シナリオ	ユーザー名とパスワード	Kerberos 認証
同じフォレスト内のドメインをディレクトリ検索する	サポート対象	サポート対象
信頼できるフォレスト内のドメインをディレクトリ検索する	サポート対象外	サポート対象
外部の信頼できるドメインをディレクトリ検索する	サポート対象外	サポート対象外

Active Directory 環境では、ディレクトリ サービスに対するセキュリティで保護された接続として、LDAPS が一般的に使用されます。 LDAPS のサポート状況は、次の表に示すように、使用される認証メカニズムによって異なります。

認証メカニズム	LDAPS のサポート
ユーザー名とパスワード	サポート対象
Kerberos 認証	サポート対象外

a. Kerberos の構成 (推奨)

1. 「Kerberos 認証を設定する」の指示に従って、Kerberos 認証を構成します。
2. ホスト ポータルにシステム管理者としてログインします。
3. 左側のペインの上部にある [ホスト ] が選択されていることを確認し、[ セキュリティ] を選択します。
4. [ Active Directory] で [ 構成] を選択します。
   • (任意) Active Directory アカウントでのログインのみを許可する場合は、[このプロバイダーを使用した自動ログインを強制] チェックボックスをオンにします。これは、プロバイダーとの連携が正常に検証されていて、ロックアウトが防止されている場合にのみ行ってください。
   • [Kerberos 認証を使用] チェックボックスは、オンのままにします。
   • [表示名] フィールドに、このログイン オプションのログイン ページに表示するテキストを入力します。
5. [ 保存 ] を選択して変更を保存し、前のページに戻ります。
6. [Active Directory] の左側にあるトグルを選択し、連携を有効化します。
7. identity-service-api-* ポッドを再起動します。
   1. SSH を使用してプライマリ サーバーに接続します。
   2. 次のコマンドを実行します。kubectl -n uipath rollout restart deployment identity-service-api

以前の管理エクスペリエンス

[新しい管理エクスペリエンス] トグルがオフになっている場合は、以下の手順を実行します。

1. 「Kerberos 認証を設定する」の指示に従って、Kerberos 認証を構成します。
2. ホスト ポータルにシステム管理者としてログインします。
3. [セキュリティ設定] に移動します。
4. [外部プロバイダー] セクションの [Active Directory] で [設定] を選択します。
   • 連携を有効化するには、[有効] チェックボックスをオンにします。
   • Active Directory アカウントでのログインのみを許可する場合は、[このプロバイダーを使用した自動ログインを強制] チェックボックスをオンにします。:fa-warning: これは、プロバイダーとの連携が正常に検証されていて、ロックアウトが防止されている場合にのみ行ってください。
   • [表示名] フィールドに、このログイン オプションのログイン ページに表示するテキストを入力します。
   • [Kerberos 認証を使用] チェックボックスは、オンのままにします。
5. [ テストして保存 ] を選択して変更を保存します。
6. identity-service-api-* ポッドを再起動します。
   1. SSH を使用してプライマリ サーバーに接続します。
   2. 次のコマンドを実行します。kubectl -n uipath rollout restart deployment identity-service-api

b. ユーザー名とパスワードの設定

重要:

このオプションを使用する場合、UiPath® サービスは、クリア テキストで提供される資格情報を使用して Active Directory と通信します。これを防ぐには、この構成で LDAP over SSL (LDAPS) を使用することをお勧めします。

重要:

UiPath クラスターを操作できるのは、このページで構成したフォレストと同じフォレストのユーザーのみです。信頼されたフォレストのユーザーは、この UiPath クラスターにログインできません。

b.1.LDAPS を使用するための前提条件

SSL 経由の LDAP (LDAPS) を使用する場合は、最初に Active Directory 環境で SSL 経由の LDAP を構成し、UiPath クラスター構成で使用するルート証明書を取得する必要があります。

注:

既知の問題: 設定された LDAPS 証明書は、アップグレード時に保持されません。そのため、アップグレード後に、LDAP によるセキュリティで保護された接続を機能させるには、LDAPS 証明書を再度追加する必要があります。

1. LDAPS の SSL 証明書を取得して各ドメイン コントローラーにインストールします。

   詳細と手順については、「 LDAP over SSL (LDAPS) Certificate (SSL 経由の LDAP (LDAPS) 証明書)」のページをご覧ください。

2. 次のコマンドを実行して、ルート証明書を Base64 でエンコードします。

   [Convert]::ToBase64String([System.IO.File]::ReadAllBytes("<Path to the .crt or .cer file>"))
   

3. エンコードされたルート証明書を ArgoCD に追加します。

   1. ArgoCD にログインします。
   2. uipath アプリケーションを選択し、移動します。
   3. 左上隅の [ APP DETAILS] を選択します。
   4. [PARAMETERS] セクションで、global.userInputs.certificate.identity.ldaps.customRootCA パラメーターを検索します。
   5. パラメーターの値を、前に取得したエンコードされたコンテンツに更新します。
   6. 保存します。
   7. [SYNC] を選択して変更を適用します。

b.2.Active Directory の構成

1. ホスト ポータルにシステム管理者としてログインします。
2. 左側のペインの上部にある [ホスト ] が選択されていることを確認し、[ セキュリティ] を選択します。
3. [ Active Directory] で [ 構成] を選択します。
   • Active Directory アカウントを使用したログインのみを許可する場合は、[このプロバイダーを使用した自動ログインを強制] チェックボックスをオンにします。
   • [Kerberos 認証を使用] チェックボックスをオフにします。
   • (任意ですが強く推奨) [SSL 経由の LDAP (LDAPS) を使用] チェックボックスをオンにします。
   • [表示名] フィールドに、このサインイン オプションのログイン ページに表示する名前を入力します。
   • [既定のドメイン] フィールドに、Active Directory (AD) の完全修飾ドメイン名 (FQDN) を入力します。
   • [ユーザー名] フィールドに、Active Directory ユーザーのユーザー名を入力します。DOMAIN\username の形式である必要があります。例: TESTDOMAIN\user1
   • [ユーザー パスワード] フィールドに、AD アカウントのパスワードを入力します。
4. [ テストして保存 ] を選択して変更を保存し、前のページに戻ります。
5. [Active Directory] の左側にあるトグルを選択し、連携を有効化します。
6. identity-service-api-* ポッドを再起動します。
   1. SSH を使用してプライマリ サーバーに接続します。
   2. 次のコマンドを実行します。kubectl -n uipath rollout restart deployment identity-service-api

手順 2. Windows 認証を構成する

前提条件

<KERB_DEFAULT_KEYTAB> を取得します。これは、Kerberos 設定の一部として生成される keytab ファイルの Base64 エンコード文字列です。

Automation Suite クラスターを構成する

重要

「Automation Suite を Kerberos クライアントとして構成する」のガイドで説明している手順に従って既に Automation Suite を Kerberos クライアントとして構成済みの場合、この手順はスキップしてください。

Active Directory との連携をユーザー名とパスワードによる方法で構成している場合 (この方法は推奨されません)、次の手順を実行します。

1. ArgoCD に移動し、管理者としてログインします。

2. 「uipath」アプリケーションを選択し、移動します。

3. 左上隅にある [APP DETAILS ] を選択します。

4. [PARAMETERS] セクションで、global.kerberosAuthConfig.userKeytab パラメーターを検索します。

   既定では、このパラメーターにはプレースホルダー値が設定されています。

5. パラメーターのプレースホルダー値を <KERB_DEFAULT_KEYTAB> で更新して保存します。

6. [ SYNC ] を選択して変更を適用します。

7. 正常に同期されたら、次のコマンドを実行して Identity Server を再起動します。

   kubectl -n uipath rollout restart deployment identity-service-api

手順 3. ブラウザーを設定する

Microsoft Internet Explorer

サポートされていません。

Microsoft Edge

追加の構成は必要ありません。

Google Chrome

通常、Google Chrome は追加の設定なしで動作します。

うまくいかない場合は、次の手順に従います。

1. [ツール] > [インターネット オプション] > [セキュリティ] に移動します。

2. [ローカル イントラネット] を選択します。

3. [ サイト] を選択します。

4. [イントラネットのネットワークを自動的に検出する] が選択されているか、すべてのオプションが選択されていることを確認します。

5. [ 詳細設定] を選択します。

6. Automation Suite の FQDN を [ローカル イントラネット] に追加します。

7. [ 閉じる ] と [ OK] を選択します。

8. [ On Custom Level] を選択します。

9. 必要に応じて、[ユーザー認証] の下にある [イントラネット ゾーンでのみ自動的にログオンする] を選択します。

   選択した場合、ブラウザーがリダイレクト認証要求を受信すると、要求の送信元がチェックされます。ドメインまたは IP がイントラネットに属している場合、ブラウザーがユーザー名とパスワードを自動的に送信します。イントラネットに属していない場合は、ブラウザーにユーザー名とパスワードの入力ダイアログが開かれ、手動で入力する必要があります。

10. 必要に応じて、[ユーザー認証] の下にある [現在のユーザー名とパスワードで自動的にログオンする] を選択します。

    選択した場合、ブラウザーがリダイレクト認証要求を受信すると、ユーザー名とパスワードがサイレント モードで送信されます。認証結果が成功の場合、ブラウザーは元の動作を続行します。認証に失敗した場合は、ブラウザーにユーザー名とパスワードの入力ダイアログが開かれ、成功するまでリトライされます。

11. [インターネット オプション] > [詳細設定] タブの [セキュリティ] セクションの下で、[統合 Windows 認証を使用する] が選択されていることを確認します。

Mozilla Firefox

1. ブラウザーの設定ウィンドウを開きます。
2. アドレス バーに「about:config」と入力します。
3. Kerberos 認証を使用する Automation Suite の FQDN を指定します。
   1. 「network.negotiate」という用語を検索します。
   2. Kerberos で次を有効化し、設定します。network.negotiate-auth.delegation-uris (値の例: uipath-34i5ui35f.westeurope.cloudapp.azure.com)、network.negotiate-auth.trusted-uris (値の例: uipath-34i5ui35f.westeurope.cloudapp.azure.com)、network.negotiate-auth.allow-non-fqdn (値: true)

手順 4. 組織に対して Windows 認証を許可する

以上で UiPath Platform と Windows 認証の連携が設定されました。UiPath でユーザー アカウントを作成するユーザーは、[ログイン] ページの [Windows] オプションを使用して UiPath Platform にサインインできます。

図 1.Windows のサインイン オプション

Windows 資格情報によるログインを許可するには、各組織の管理者が以上の設定をそれぞれの組織に対して実行する必要があります。

1. 組織管理者としてログインします。

2. Active Directory ユーザーまたはグループに組織レベルのロールを割り当てます。これは検索から選択できます。

3. Windows 認証でのログインを許可するユーザーごとに、前の手順を繰り返します。

   ロールを割り当てたユーザーは、Active Directory アカウントを使用して UiPath の組織にログインできます。 ドメインに参加しているマシンからログインする必要があります。

トラブルシューティング

Windows 資格情報を使用してログインしようとしたときに HTTP 500 エラーが発生する場合は、次の点を確認してください。

1. Windows マシンはドメインに参加していますか? 該当するマシンで、[コントロール パネル] > [システムとセキュリティ] > [システム] に移動し、ドメインが表示されているかどうかを確認します。ドメインが表示されていない場合は、マシンをドメインに追加します。Kerberos プロトコルで Windows 認証を使用するには、マシンがドメインに参加している必要があります。

2. 同じ資格情報で Windows マシンにログインできますか? できない場合は、システム管理者にヘルプを依頼してください。

3. Microsoft Edge 以外のブラウザーを使用していますか? Microsoft Edge 以外のサポート対象ブラウザーでは、追加の設定が必要です。

4. keytab の設定を確認します。

   1. keytab の生成後、Active Directory サーバーでは、Active Directory ユーザーのプロパティ (servicePrincpalName) が HTTP/<Service Fabric FQDN> の形式になっている必要があります (例: HTTP/uipath-34i5ui35f.westeurope.cloudapp.azure.com)。
   2. Active Directory のユーザー アカウントに対して [ このアカウントは Kerberos AES 256 ビット暗号化をサポートしています 。] オプションを選択する必要があります。この設定が不適切な場合は、identity-service-api ログに次のように表示されます。

      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/[e-mail] kvno 4 enctype aes256-cts found in keytab but cannot decrypt ticket).* at Microsoft.AspNetCore.Authentication.Negotiate.NegotiateHandler.HandleRequestAsync()
      

5. 使用しているドメイン内で複数の Active Directory を設定している場合、認証は失敗し、identity-service-api ログに次のように表示されます。

   kinit: Client '[e-mail]' not found in Kerberos database while getting initial credentials
   

   この場合、認証用に作成したマシン アカウントがすべての Active Directory に複製されていることを確認します。

6. ktpass を実行してユーザー アカウントに新しいパスワードを割り当てると、キーのバージョン (kvno) が増加し、古い keytab が無効になります。identity-service-api ログには、次のように表示されます。

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

   この場合、ArgoCD で krb5KeytabSecret を更新する必要があります。

7. identity-service-api ポッドで次のエラーが発生した場合、

   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).
   

   1. この場合はまず、ArgoCD で global.userInputs.identity.krb5KeytabSecret パラメーターを指定したかどうかを確認します。 このパラメーターが存在する場合は、keytab の生成に使用した Active Directory ユーザーの資格情報で Windows マシンにログインできるかどうかを確認します。パスワードが変更されたか、有効期限が切れている場合は、keytab を再生成する必要があります。
   2. この問題の原因としてもう 1 つ考えられるのは、以前に ArgoCD が不適切に同期されていたことです。この問題を修正するには、既存の global.userInputs.identity.krb5KeytabSecret を削除して ArgoCD を同期します。操作が成功したら global.userInputs.identity.krb5KeytabSecret を更新し、再度同期します。

8. ブラウザーで、期待される SPN を使用していますか?

   指示に従って Kerberos イベント ログを有効化した場合、Kerberos イベント ログに KDC_ERR_S_PRINCIPAL_UNKNOWN エラーが表示されます。この問題の詳細については、Microsoft のドキュメントをご覧ください。

この問題を解決するには、グループ ポリシーを変更することにより、Kerberos 認証をネゴシエートする際の CNAME ルックアップを無効化してください。詳細については、Google Chrome の手順と Microsoft Edge の手順をご覧ください。

Debugging the Active Directory integration with Kerberos

Use the following flow to debug login and integration failures that are not covered by the checks above.

Check the Kerberos job pods in ArgoCD

1. In ArgoCD, go to the uipath application and verify that the applications are synced and healthy.
2. Make sure the services-preinstall-validations-job and kerberos-jobs-trigger pods are in a successful state. These two jobs run kinit to generate the TGT once Kerberos is configured, so if both are in a successful state, Kerberos is configured correctly. If either failed, check its logs for the cause.
3. Make sure the kerberos-tgt-update cron job pod runs successfully. This cron job is triggered regularly to get a fresh TGT before the existing one expires. If it failed, check its logs.

Inspect the identity service logs

If the identity-service-api pods are unhealthy, open the pod in ArgoCD, navigate to Logs, and select the identity-server container. Match the errors in the log to the following causes:

• The domain controller cannot be reached — This is a network-level issue. The cluster is trying to reach the domain specified in the configuration, and the DNS service that the cluster connects to does not have information about the domain. A related cause is DNS returning multiple unreachable domain controllers: connection attempts can time out within the retry limit before a healthy controller is reached. Work with your IT department so that the cluster uses an official domain registered in your network's DNS service and that DNS resolution only returns reachable domain controllers.
• LDAP error A local error occurred — This is a generic error from the LDAP libraries (displayed in the identity-service-api logs as Ldap connection failed due to error 82). The following root causes are known:
  • Switching between the Kerberos and LDAPS configurations — a known issue occurs when you switch the AD integration from a Kerberos configuration to LDAPS, or the other way around. To work around it:
    1. Open the cluster's SQL database.
    2. In the [identity].[DirectoryConnections] table, find the ldapad entry and set the IsDeleted value to True.
    3. In the [identity].[ExternalIdentityProviders] table, find the ldapad entry and set the IsActive value to True.
    4. Restart the identity-service-api pods.
    5. Configure the AD integration through the host security settings again.
  • LDAP canonicalization in older builds — upgrade to the latest available cumulative update (CU). Recent CUs contain changes that turn off LDAP canonicalization, which can cause this error when the openldap libraries are used.
  • Stale DNS SRV records for de-provisioned domain controllers — if domain controllers were removed without cleaning up DNS, the _kerberos._udp. SRV records may no longer match the _kerberos._tcp. records. In your DNS server, list the SRV records for your domain under _kerberos._udp. and _kerberos._tcp., make sure they match one-to-one, and remove the stale entries that point to de-provisioned domain controllers.

Debug browser-based authentication

If the pods are healthy but you still cannot authenticate in the browser:

1. Make sure the browser runs on a Windows machine domain-joined to the domain (or forest, or trusted forest) to which the account represented by the keytab belongs. Kerberos only works in such an environment. Note that on MSI installations, Windows authentication also works with NTLM; in Automation Suite, only Kerberos is supported.
2. If the cluster name resolves through a CNAME record in DNS and you use Chrome or Edge, disable the CNAME lookup when negotiating Kerberos authentication (see the "Does the browser use the expected SPN?" check above), restart the browser, and try again. If this fixes the issue, configure the DNS entry as an A record instead of a CNAME record, or apply the browser setting across your organization by using Group Policy.
3. If the error persists — for example, An unsupported mechanism was requested or a repeated authentication prompt — enable Kerberos event logging as described in the Microsoft documentation, retry the scenario, and inspect the System log in Event Viewer:
   • KDC_ERR_PREAUTH_REQUIRED errors are expected and can be ignored.
   • KDC_ERR_S_PRINCIPAL_UNKNOWN or KRB_AP_ERR_MODIFIED — the SPN for the service account is not set correctly. Set the SPN HOST/<cluster name> on the account represented by the keytab configured in the cluster.
   • KDC_ERR_ETYPE_NOTSUPP — encryption types are disabled in your organization. By default, Windows uses RC4-HMAC unless AES128 or AES256 is explicitly configured. To force AES256, in Active Directory Users and Computers, navigate to the user account that represents the keytab file used by the cluster, open the Account tab, select This account supports Kerberos AES 256 bit encryption, and select OK. Then reset the password of this account, regenerate the keytab, and update it in the cluster configuration. This generates the new password hashes required for AES256.

Enable verbose Kerberos logging

To get additional logging for the Kerberos integration, set the following environment variable in the identity-service-api pod env section:

- name: KRB5_TRACE
  value: /dev/stderr