アダプティブ認証の問題のトラブルシューティング
問題は、設定のさまざまな段階に基づいて分類されます。
アダプティブ認証 CLI を使用して問題のトラブルシューティングを行うこともできます。CLI に接続するには、次の操作を行います。
- putty/securecrt などの SSH クライアントをマシンにダウンロードします。
- 管理 IP (プライマリ) アドレスを使用してアダプティブ認証インスタンスにアクセスします。
- 認証情報でログインします。
詳しくは、「 NetScalerアプライアンスへのアクセス」を参照してください。
アダプティブ認証ログのロギングを有効にする
アダプティブ認証ログをキャプチャするには、必ずログレベルを有効にしてください。
CLI を使用してログを有効にする:
- アダプティブ認証インスタンス CLI にログインします。
- PuTTY を使用して、管理認証情報を入力します。
- コマンド
set audit syslogParams logLevel ALL
を実行する
GUI を使用してログを有効にする:
- ブラウザを使用してアダプティブ認証インスタンスにログインします。
- [ 構成] > [システム] > [監査]に移動します。
- [監査] ページの [ 設定] で、[ 監査 Syslog 設定の変更] をクリックします。
- 「 ログレベル」で「 すべて」を選択します。
プロビジョニングに関する問題
-
アダプティブ認証 UI にアクセスできません
顧客 ID/テナントでエンタイトルメントが有効になっているかどうかを確認します。
-
プロビジョニングページで45分以上動かなくなる
エラーのスクリーンショットを収集し、Citrix サポートにお問い合わせください。
-
VNet ピアがダウンしています
- このピアリングに対応するアラートが Azure Portal にあるかどうかを確認し、推奨されるアクションを実行します。
- ピアリングを削除し、アダプティブ認証 UI から再度追加します。
-
プロビジョニング解除は完了していません
Citrixサポートに連絡してください。
インスタンスのアクセシビリティ問題
-
インスタンスの管理 IP アドレスにアクセスできない
-
アクセスに使用されるクライアントのパブリックIPアドレスが、許可された送信元IPアドレスに含まれているかどうかを確認します。
-
クライアントの送信元 IP アドレスを変更するプロキシがあるかどうかを検証します。
-
-
インスタンスにログインできません
プロビジョニング中に入力した認証情報で、管理者アクセスが正常に機能していることを確認します。
-
エンドユーザーには完全な権限がない
ユーザーを追加するときに、アクセスに適したコマンドポリシーをバインドしていることを確認してください。詳しくは、「 ユーザー、ユーザーグループ、およびコマンドポリシー」を参照してください。
AD または RADIUS 接続の問題
Azure Vnet ピアリング接続タイプの問題:
- 顧客管理の Azure VNet がアダプティブ認証インスタンスから到達可能かどうかを確認します。
- 顧客が管理する Azure VNet から AD への接続/到達可能性が機能しているかどうかを確認します。
- オンプレミスから Azure VNet にトラフィックを誘導するために、適切なルートが追加されていることを確認します。
Windows ベースのコネクタ:
- すべてのログはディレクトリ /var/log/ns.log で利用でき、各ログには [NS_AAUTH_TUNNEL] という接頭辞が付いています。
- ログの ConnectionId を使用して、さまざまなトランザクションを相互に関連付けることができます。
-
コネクタ仮想マシンのプライベート IP アドレスが RADIUS サーバの RADIUS クライアントの 1 つとして追加されていることを確認します。その IP アドレスはコネクタのソース IP アドレスだからです。
認証要求ごとに、アダプティブ認証インスタンス(NS-AAAD プロセス)と認証サーバの間にトンネルが確立されます。トンネルが正常に確立されると、認証が行われます。
コネクタ仮想マシンがアダプティブ認証 FQDN を解決できることを確認します。
-
コネクタはインストールされているが、オンプレミス接続が失敗する。
NSAUTH-TUNNELが確立されているかどうかを検証します。
cat ns.log | grep -I “tunnel”
次のサンプルログが認証要求の ns.log ファイルに出力されない場合は、トンネルの確立中に問題が発生しているか、コネクタ側から何らかの問題がある可能性があります。
LDAP: [NS_AAUTH_TUNNEL] Entering bitpump for Connection1 => Src : 192.168.0.7:28098, Dst : 10.106.103.60:636 , Connection2 => Src : 10.106.103.70:2271, Dst : 10.106.103.80:443" RADIUS: [NS_AAUTH_UDP_TUNNEL] MUX channel established" <!--NeedCopy-->
ログの詳細を確認し、適切なアクションを実行してください。
ログの詳細 修正アクション 接頭辞 [NS_AAUTH_TUNNEL]
の付いたログはログファイルに含まれませんshow cloudtunnel vserver
コマンドを実行します。このコマンドは、状態が UP の両方 (TCP と UDP) のクラウドトンネル仮想サーバーを一覧表示する必要があります。[NS_AAUTH_TUNNEL] Waiting for outbound from connector
このログで、次の応答が受信されなかった場合:[NS-AAUTH-TUNNEL] Received connect command from connector and client connection lookupsucceeded"
コネクタマシンがアダプティブ認証 FQDN に到達できるかどうかを確認するか、またはコネクタ側のファイアウォールでアダプティブ認証 FQDN へのアウトバウンド接続を確認します。 [NS_AAUTH_TUNNEL] Server is down or couldn't create connection to ip 0.0.0.0
および[NS_AAUTH_TUNNEL] Connect response code 401 is not 200 OK, bailing out"
Citrix サポートにお問い合わせください。
コネクタから応答がありません:
- アダプティブ認証 FQDN がコネクタ仮想マシンから到達可能であることを確認します。
- Adaptive Authentication インスタンス上のサーバー証明書にバインドされ、リンクされた中間証明書があることを確認します。
LDAP/RADIUS設定が正しくありません:
AD/RADIUSサーバーのIPアドレスがパブリックIPアドレスの場合は、NetScalerの式にサブネットまたはIPアドレスを追加する必要があります。既存の範囲は編集しないでください。
-
CLI を使用してサブネットまたは IP アドレスを追加するには、次の手順を実行します。
set policy expression aauth_allow_rfc1918_subnets "(CLIENT.IP.DST.BETWEEN(10.0.0.0,10.255.255.255) || CLIENT.IP.DST.BETWEEN(172.16.0.0,172.31.255.255) || CLIENT.IP.DST.BETWEEN(192.168.0.0, 192.168.255.255) || CLIENT.IP.DST.BETWEEN(13.14.0.0, 13.14.255.255)||CLIENT.IP.DST.EQ(1.2.5.4))" <!--NeedCopy-->
-
GUI を使用してサブネットまたは IP アドレスを追加するには、次の手順を実行します。
- [ Appexpert] > [式]に移動します。
- aauth_allow_rfc1918_subnetsという式を追加します。
トンネルが確立されても認証に失敗する場合は、次の手順を使用して問題のトラブルシューティングを行います。
LDAP:
- バインド DN の詳細を検証します。
- 接続テストを使用してエラーを確認します。
-
aaad
デバッグを使用してエラーを検証します。 -
CLI を使用してアダプティブ認証インスタンスにログインします。
shell cd /tmp cat aaad.debug <!--NeedCopy-->
一般的な LDAP エラー:
- サーバータイムアウト — LDAP クエリに対するコネクタからの応答がありません。
- その他の LDAP エラーについては、https://support.citrix.com/article/CTX138663を参照してください。
Radius:
- コネクタIPアドレスは、RADIUSサーバ構成でRADIUSクライアントの送信元IPアドレスとして追加する必要があります。
認証に関する問題
-
OAuth のアサーションエラーを投稿する
-
すべてのクレームがADによって提供されていることを確認してください。これを成功させるには7件のクレームが必要です。
-
/var/log/ns.log のログを検証して、OAuth 障害のエラーを特定します。
cat /var/log/ns.log <!--NeedCopy-->
- OAuth プロファイルパラメータを検証します。
-
-
Azure AD 認証がアサーション後にスタックする
認証をオフに設定して、次の要素として AD 認証を追加します。これは、認証を成功させるために必要なすべての要求を取得するためです。
EPA 関連の問題
-
プラグインは既に存在していますが、プラグインをダウンロードするように求めるプロンプトがユーザーに表示されます。
考えられる原因:バージョンの不一致またはファイルの破損
-
開発者ツールを実行し、プラグインリストファイルにNetScalerおよびクライアントマシンのバージョンと同じバージョンが含まれているかどうかを検証します。
-
NetScaler のクライアントバージョンが、クライアントマシンのクライアントバージョンと同じであることを確認します。
NetScaler のクライアントを更新します。
アダプティブ認証インスタンスで、[ Citrix Gateway]>[グローバル設定]>[クライアントライブラリの更新]に移動します。
Citrix ダウンロードのEPAプラグインライブラリページには、詳細情報が表示されます。
-
バージョンが更新されても、要求がNetScalerにキャッシュされることがあります。
show cache object
はキャッシュされたプラグインの詳細を表示します。コマンドを使用して削除できます。flush cache object -locator 0x00000023345600000007
EPA ログ収集の詳細については、「https://support.citrix.com/article/CTX209148」を参照してください。
-
-
ユーザーがオプションを選択した後に EPA の設定 ([常に]、[はい]、[いいえ]) を元に戻す方法はありますか。
現在、EPA 設定の復元は手動で行われています。
- クライアントマシンで、C:\Users<user_name>\ AppData\ Local\ Citrix\ AGEE に移動します。
-
config.js
ファイルを開き、trustAlways を null に設定します-"trustAlways":null
スマートアクセスタグの問題
-
スマートアクセスを設定した後、アプリケーションは利用できません
アダプティブ認証インスタンスとCitrix VDAデリバリーグループの両方でタグが定義されていることを確認します。
Workspaceデリバリーグループにタグがすべて大文字で追加されていることを確認します。
これが機能しない場合は、ns.log を収集し、Citrix サポートに連絡することができます。
アダプティブ認証インスタンスの一般的なログ収集
- テクニカルサポートバンドル:詳細については、 インサイト分析のためにSDXおよびVPXアプライアンスからテクニカルサポートバンドルを収集する方法を参照してください。
- トレースファイル。詳しくは、「 NetScalerでパケットトレースを記録する方法」を参照してください。
ガイダンスについては、Citrix サポートにお問い合わせください。