AD/LDAPコネクタのトラブルシューティング

AD/LDAPコネクタで問題が発生している場合は、以下をお読みいただいて、一般的な問題のトラブルシューティング方法を確認してください。

トラブルシューティングツールは、AD/LDAPコネクタ管理コンソールで実行することも、Admin Consoleの外部でプログラムを手動で実行することもできます。

証明書の問題を検出するには、AD/LDAPコネクタ構成ファイルでCONNECTIONS_API_V2_KEY変数を設定します。

トラブルシューティングツールは、Admin Consoleで実行できます。

1. トラブルシューティングビューに切り替えて、ログをお読みください。

   

2. ［Run（実行）］を選択して、AD/LDAPコネクタに関連する最も一般的な問題を検出します。

Admin Consoleの外部でトラブルシューティングツールを起動できます。

Windowsマシンで、提供されたコマンドファイルを実行してトラブルシューティングツールを起動します。

1. AD/LDAP Connectorフォルダー（AD LDAP Connector）を見つけます。

2. troubleshoot.cmdファイルを実行します。

例：C:\Program Files (x86)\Auth0\AD LDAP Connector\troubleshoot.cmd.

Linuxマシンで、提供されているNode.jsプログラムを実行して、トラブルシューティングツールを起動します。

1. 新しいターミナルウィンドウを開きます。

2. 作業ディレクトリをAD/LDAP Connectorフォルダー（AD LDAP Connector）に変更します。

3. Node Troubleshoot.jsコマンドを実行します。

［Save（保存）］をクリックすると、AD/LDAP Connector Admin Consoleによって一連のテストが実行され、提供された情報が検証されます。テストの結果は、［Configuration log（構成ログ）］の見出しの下に表示されます。

Admin Consoleは、次のテストを実行します

• Test 1（テスト1）：指定されたLDAPサーバーおよびポートへのTCP接続の確立を試みます。テスト1が失敗した場合は、このような接続を妨げる可能性のある基本的なネットワーク接続とファイアウォール設定を確認します。

• Test 2（テスト2）：指定されたLDAPサーバーおよびポートで、指定されたユーザー名とパスワードを使用してLDAPバインドの実行を試みます。テスト2が失敗した場合は、LDAP接続文字列、検索パス、ユーザー名、およびパスワードを確認します。

• Test 3（テスト3）：指定されたユーザー名の権限を確認するために、ディレクトリに対してLDAP検索を試行します。テスト3が失敗した場合は、ターゲットディレクトリ内のユーザー名の権限を確認します。

• Test 4（テスト4）：Auth0サーバーへの接続確立を試行します。テスト4が失敗した場合は、このような接続を妨げる可能性のあるネットワーク接続とファイアウォール設定を確認します。

いくつかの一般的な問題とその解決策について説明します。

デフォルトでは、Auth0 AD/LDAPコネクタは、Active Directoryからユーザーのグループメンバーシップをインポートし、［user（ユーザー）］オブジェクトにそれらを含めます。

この動作では、AD/LDAPコネクタがActive Directoryに対して追加のクエリを実行する必要があります。これにより、認証プロセスの時間が大幅に長くなる可能性があります。

ユーザープロファイルにグループを返す必要がない場合、Auth0は、AD/LDAP Connector構成ファイルでGROUPS変数を明示的に無効にすることを推奨します。

AD/LDAPコネクタをホストするマシンのCPU使用率が常に高い場合（例えば、使用率が60%以上持続する場合）、いくつかの緩和策があります。

CPUサイクルを消費している可能性のあるホストマシン上の重要でないサービスをアンインストールします。

ユーザープロファイルでグループを返す必要がない場合は、［Authentication requests take too long to process（認証要求の処理に時間がかかりすぎる）］の説明に従ってグループインポートを無効にします。

ユーザープロファイルでグループを返す必要がある場合は、Auth0ユーザープロファイルで返されるグループを調査します。ネストされたグループと再帰グループに対するクエリは、高いCPU利用を引き起こす可能性があります。可能であれば、グループインポートを無効にしてテストして、グループクエリの影響を評価します。

影響を軽減するには、AD/LDAPサーバーで再帰的または問題のあるグループ割り当てを修正するか、AD/LDAPコネクタ構成ファイルのGROUPS_CACHE_SECONDS変数の値を増やします。

最初にAD/LDAPコネクタを展開してから、アクティブユーザーの数が増加しているかどうかを確認します。これは、独自の監視ソリューションを使用して評価することも、Auth0アクティブユーザーレポートから推定値を取得することもできます。

アクティブユーザーの数が増加し、上記のすべての手順が既に実行されている場合は、ホストマシンのハードウェア仕様をアップグレードするか、高可用性環境を構成する必要があります。

コネクタでは、サーバー上のクロックをAuth0サービスと同期する必要があります。許容される最大しきい値は5秒です。

クロックスキューがある場合は、トラブルシューターとコネクタログにこのような出力が表示されます。

12:18:55 - info: * Testing clock skew...
12:18:55 - error: × Clock skew detected:
12:18:55 - error: > Local time: 2020-05-04 12:18:55
12:18:55 - error: > Auth0 time: 2020-05-04 12:19:10

サーバーのクロックが最新であることを確認します。時間が正しくない場合、認証要求が失敗します。これは、ネットワークタイムプロトコル (NTP) を使用して同期サーバーをポーリングするようにシステムが適切に構成されていることを確認することで解決できます。Windows環境では、NTPプロバイダーは通常、同じドメインコントローラです。ドメインコントローラが外部サービスと同期されていることを確認します。

Active Directory環境を外部タイムサーバーと同期する方法については、renanrodrigues.comの［How to configure NTP server in Active Directory（Active DirectoryでNTPサーバーを構成する方法）］をお読みください。

サーバーの時計がNTPと同期しているかどうかがわからない場合は、https://nist.time.govに移動して、そのページの時間と、コネクタが実行されているサーバーの時間を比較します。両者の間に1秒以上の差はありません。

AD/LDAPコネクタは、LDAPサーバーに到達できるサーバーにインストールする必要があります。AD/LDAPコネクタとLDAPサーバーの間にファイアウォールとVPN接続を配置すると、接続の問題が発生する可能性があります。

Active Directoryを使用してWindowsネットワークを構成する場合は、nltestコマンドを使用します。たとえば、特定のマシンがFabrikam.localドメインに到達できるかどうかをテストするには、nltest/dsgetdc:fabrikam.localを使用します。

現在のサーバーがどのドメインに接続されているかを確認するには、nltest/dsgetdc:を使用します。

ドメインが存在しないか、到達できない場合、nltestはエラーメッセージを返します：DC名の取得に失敗しました:Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN.

このエラーは、プライベートクラウドと組み合わせたAD/LDAPコネクタに適用されます。

このエラーメッセージは、AD/LDAP Connectorがプライベートクラウドで構成されたSSL証明書を検証できない場合に、その起動に失敗したときに発生します。これは、ルート証明書（または中間証明書）がマシンの証明書ストア（Windows）にない場合に発生する可能性があります。これを解決するには、AD/LDAPコネクタがインストールされているマシンの［Local Machine（ローカルマシン）］>［Trusted Root（信頼ルート）］証明書ストアに証明書チェーンをインポートします。

コネクタをホストしているコンピューターがプロキシの背後にある場合は、HTTP_PROXYシステム環境変数を設定するか、AD/LDAPコネクタ構成ファイルでHTTP_PROXY変数を設定できます。認証されたプロキシを使用する場合、URLは http://USERNAME:PASSWORD@SERVER_URL:PORTの形式にする必要があります。

HTTP_PROXY URLはプロキシ自体のURLである必要があり、.pac（自動構成）ファイルを指すことはできません。プロキシが.pacファイルを使用して構成されている場合は、.pacファイルをダウンロードし、そこでプロキシ URL を見つけます。

プロキシが正しく構成されていないと、Auth0サーバーに到達できないおよびSELF_SIGNED_CERT_IN_CHAINエラーなど、いくつかのエラーが発生する可能性があります。

プロキシURLを構成し、AD/LDAPコネクタを再起動してもSELF_SIGNED_CERT_IN_CHAINエラーが発生する場合は、サーバーがプロキシのルート証明書を信頼していることを確認してください。Windowsコンピューターでは、certmgr.mscを開いてプロキシの証明書を検索することで、これを確認できます。詳細については、［ウィキペディアのプロキシAuto Config（PAC）］をお読みください。

サーバーがAuth0テナント（https://{yourDomain}）に接続できることを確認します。

これを確認するには、ブラウザを開き、https://{yourDomain}/テストに移動します。

AD/LDAPコネクタを構成するために使用されるサービスアカウントは、AD/LDAP サーバー上でread権限を持っている必要があり、ユーザーのグループを照会できる必要があります。

Kerberos要求の詳細ログを有効にするには：

1. システム環境変数としてDEBUG=kerberos-serverを追加します。

2. AD/LDAPコネクタを再起動します。

3. ログインします。

4. 詳細については、ログを確認してください。

Kerberosが有効になっているにもかかわらず、ユーザーがユーザー名/パスワードを要求される場合は、IPアドレス設定が適切に構成されていることを確認します。詳細については、［Configure AD/LDAP Connector Authentication with Kerberos（Kerberosを使用したAD/LDAPコネクタ認証の構成）］を参照してください。

AD/LDAPコネクタでは、次の2つのレベルの構成可能なキャッシュが使用されます：

1. Auth0サーバー：ユーザーの資格情報とプロファイルの両方をキャッシュします。

2. AD/LDAPコネクタ：ユーザーのグループメンバーシップをキャッシュします。

これらの設定の構成により、ユーザーがアプリケーションにログインしたときにディレクトリの変更がユーザーのプロファイルに反映される即時性が決まります。一部のAD/LDAPインストールでは、ユーザー属性の同期に数分かかる場合があります。

Auth0サーバーは、ユーザー名とパスワードのハッシュを含む、ユーザーの最後に正常に認証されたプロファイルをキャッシュします。デフォルトで有効になっていますが、無効にすることもできます。

この第1レベルのキャッシュの目的は、ネットワークの停止中など、ADが使用できない場合に認証トランザクションの可用性を最大化することです。AD/LDAPコネクタまたはAD/LDAPサーバーが使用できない場合にのみアクティブになります。

AD/LDAPコネクタは、ユーザーのグループメンバーシップをキャッシュします。このキャッシュの有効期限はAD/LDAPコネクタ設定ファイルのGROUPS_CACHE_SECONDS変数によって決定され、デフォルト値は600（秒）です。

このセカンドレベルキャッシュの目的は実行時間を最小化することです。デフォルトでは、AD/LDAPコネクタはユーザーのすべてのグループメンバーシップを再帰的に取得します。これは、一部のAD/LDAPインストールでは負荷の高いプロセスになる可能性があります。このキャッシュは、AD/LDAPコネクタを再起動するたびに削除されます。

サーバーのオープンインバウンドポートの要件を回避するために、AD/LDAPコネクタはAuth0のサーバークラスター内の利用可能なノードにWebソケット接続を作成し、Auth0からの受信メッセージをリッスンするためにオープン状態を維持します。

約1日1回（ただし、状況により頻度が異なる場合がある）、各サーバーノードは接続を終了し、内部導入プロセスを実行できるようにします。AD/LDAPコネクタは閉じた接続を検出してプロセスを終了し、サービススタックがプロセスを再起動し、使用可能なノードへの新しい接続を作成し、操作を再開できるようにします。

ダウンタイムを回避するには、キャッシュを有効にします。

1. ［Auth0 Dashboard］>［Authentication（認証）］>［Enterprise（エンタープライズ）］に移動して、［Active Directory/LDAP］の接続タイプを選択します。

2. AD/LDAP接続を選択します。

3. ［Applications（アプリケーション）］ビューに切り替え、目的のアプリケーションの接続を有効にします。

4. ［Save（保存）］を選択します。

カスタムドメインの追加の構成を完了していない場合、このエラーが発生することがあります。

KerberosをサポートするAD/LDAP接続を使用するには、カスタムドメインで動作するように［Ticket（チケット）］エンドポイントを更新する必要があります。

1. AD/LDAPコネクタ構成ファイルを開きます。

2. PROVISIONING_TICKET構成変数をhttps://{yourDomain}/p/ad/jUG0dN0Rに設定します。

3. AD/LDAPコネクタを再起動します。

AD/LDAP Connectorの構成後に、UNABLE_TO_GET_ISSUER_CERT_LOCALLYエラーが表示される場合、認証局がマシンから見つからない可能性があります。

• テナントがパブリッククラウド環境にある場合、AD/LDAP Connectorがインストールされたマシンの信頼できるストアにISRG Root X1証明書があることを確認します。

• 統合プラットフォーム環境を使用している場合は、AD/LDAPコネクタがインストールされているマシンの信頼済みストアにISRGルートX2証明書を追加します。

高可用性環境を構成しており、追加マシンでこのエラーが発生する場合、追加マシンの信頼されたルート認証機関が初期マシンの信頼されたルート認証機関と一致していることを確認してください。

これらの問題を自分で解決できない場合は、Auth0サポートにお問い合わせください。

サポートチームが問題をトラブルシューティングできるように、サポートチケットに次の項目を含めてください。

1. 課題の説明。

2. AD/LDAP構成ファイルのエクスポート。

3. サービスログファイルのコピー:

   • Windows:C:\Program Files (x86)\Auth0\AD LDAP Connector\logs.log

   • Linux:/var/log/auth0-adldap.log

4. AD/LDAPコネクタのバージョン番号。

   

• AD/LDAPコネクターのシステム要件
• AD/LDAPコネクター構成のインポートとエクスポ―ト
• AD/LDAPコネクターのテスト環境をセットアップする
• AD/LDAPコネクターを更新する
• AD/LDAPコネクターの構成ファイルスキーマ
• System Center Operations Managerを使用してAD/LDAPコネクターを監視する