Active Directory との連携を構成する

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

既知の制限事項

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

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

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

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

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

より多くのシナリオがサポートされているため、Kerberos 認証をお勧めします。

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

a. Kerberos の構成 (推奨)

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 と通信します。これを防ぐには、この構成で SSL 経由の LDAP (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 アカウントを使用したログインのみを許可する場合は、[このプロバイダーを使用した自動ログインを強制] チェックボックスをオンにします。
   • (任意ですが強く推奨) [SSL 経由の LDAP (LDAPS) を使用] チェックボックスをオンにします。
   • [Kerberos 認証を使用] チェックボックスは、オフにする必要があります。
   • [表示名] フィールドに、このサインイン オプションのログイン ページに表示する名前を入力します。
   • [既定のドメイン] フィールドに、Active Directory (AD) の完全修飾ドメイン名 (FQDN) を入力します。
   • [ユーザー名] フィールドに、Active Directory ユーザーのユーザー名を入力します。DOMAIN\username の形式である必要があります。例: TESTDOMAIN\user1
   • [ユーザー パスワード] フィールドに、上記 Active Directory アカウントのパスワードを入力します。
4. [テストして保存] をクリックして変更を保存します。
5. identity-service-api-* ポッドを再起動します。
   1. SSH を使用してプライマリ サーバーに接続します。
   2. 次のコマンドを実行します。

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

トラブルシューティング

ドメインに到達できない

エラー Domain unreachable が発生する場合は、コマンド getent ahosts <AD domain> を使用して DNS ルーティングを確認します。

IP アドレスが返されない場合は、ノードの /etc/resolv.conf を確認します。ネームサーバーの値が Active Directory ドメインの DNS を指している必要があります。指していない場合は、システム管理者に問い合わせて、適切な設定を依頼してください。

ノードが Azure 上で実行される場合は、「Azure 仮想ネットワーク内のリソースの名前解決」の手順に従ってください。

これを行う方法の 1 つは、次のとおりです。

1. Azure でノードの仮想ネットワークに移動し、仮想ネットワークの DNS サーバーを Active Directory DNS に設定します。
2. systemctl restart NetworkManager.service を実行し、/etc/resolv.conf が更新されているかどうかを確認します。
3. ArgoCD からクラスターのコア DNS を再起動します。

LDAPS の使用中にドメインに到達できない

LDAPS が有効化されているときに Domain unreachable エラーが発生する場合は、誤った証明書が使用されている可能性があります。

LDAP サーバーのローカル・コンピューターの証明書ストアに、サーバー認証に有効な証明書が複数あるかどうかを確認します。ある場合、必要な証明書とは別の証明書を LDAPS 通信に使用できます。

最も簡単な解決方法は、不要な証明書をローカル コンピューターの証明書ストアからすべて削除し、サーバー認証に有効な証明書を 1 つだけ持つことです。

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

前提条件

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

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

1. ArgoCD に移動し、管理者としてログインします。
2. 「uipath」アプリケーションを選択し、移動します。
3. 左上隅の [APP DETAILS] をクリックします。
4. [PARAMETERS] セクションで、global.userInputs.identity.krb5KeytabSecret パラメーターを検索します。

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

5. パラメーターのプレースホルダー値を <KERB_DEFAULT_KEYTAB> で更新して保存します。
6. [SYNC] をクリックして変更を適用します。
7. 同期が成功したら、コマンド kubectl -n uipath rollout restart deployment identity-service-api を実行して Identity Server を再起動します。

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

Microsoft Internet Explorer

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

Microsoft Edge

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

Google Chrome

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

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

1. [ツール] > [インターネット オプション] > [セキュリティ] に移動します。
2. [ローカル イントラネット] を選択します。
3. [ サイト] を選択します。
4. [イントラネットのネットワークを自動的に検出する] が選択されているか、すべてのオプションが選択されていることを確認します。
5. [ 詳細設定] を選択します。
6. Automation Suite の FQDN を [ローカル イントラネット] に追加します。
7. [閉じる] と [OK] を選択します。
8. [ レベルのカスタマイズ] を選択します。
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 にサインインできるようになりました。

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

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