Cisco Secure Client が RDP セッションからの VPN 接続を遮断する

サインインは成功するのに、トンネルは上がらない。この組み合わせは、認証の問題だと読み違えられ、原因ではなかった資格情報のリセットに半日を費やすことになります。Cisco Secure Client は、試行が Remote Desktop セッションから来たという理由だけで VPN の確立を拒否することがあり、その判断はクライアント側のポリシーが行います。

接続の流れのどこで起きるか

クライアントを上から順にたどります。プロファイルが読み込まれ、資格情報が集められ、認証が完了します。その後、トンネルが構築される前に、クライアントは自分が置かれた環境に対してセッションと確立の設定を評価します。

その時点で三つを記録します。正確なメッセージ、クライアントのバージョン、クライアントに表示されるプロファイル名です。この三つがあれば、曖昧な不満が対応可能なサポート依頼になります。長いメッセージはログで切り詰められるため、ダイアログの画面を撮っておきます。時刻も控えておけば、管理者がヘッドエンド側と突き合わせられます。

実際に判断している設定

関係する制御は Windows VPN Establishment ポリシーで、記録されている値は二つ、ローカル ユーザーのみとリモート ユーザーを許可するです。後者は、サポートされる構成であれば Remote Desktop セッションからのトンネル構築を許可します。前者は多くの企業プロファイルでの既定の姿勢です。

Windows Logon Enforcement と混同しないでください。プロファイル ガイドはこれをログオン セッションに関する別のポリシーとして記録しています。一方はどのセッションがトンネルを構築できるかを定め、もう一方は同時接続やログオン前の動作を定めます。誤った方を変更しても目に見える効果はありません。

実際に適用されているプロファイルを読む

管理された配備では、クライアントはヘッドエンドや管理された場所からプロファイルを受け取り、ディスク上で編集したコピーが有効なものではないことがよくあります。そのため、ローカルの XML 変更は正しく見えても何も変わりません。

ノート PC にどのファイルがあるかではなく、デバイスがどのプロファイルとグループ ポリシーを受け取るかを管理者に尋ねてください。バージョン アップグレード後は両者が食い違うことがよくあります。ローカル フォルダーの古いコピーは今もエディターで開け、今も正しく見えます。ただ、クライアントが適用したものではないだけです。

トンネルが上がった後の RDP 経路

リモートからの確立を許可しても、Remote Desktop セッションが生き残る保証はありません。トンネルが経路やローカルのアクセス ルールを変えると、あなたを中へ運んだセッションは、それを支える経路を失うことがあります。

変更の前に復旧経路を計画してください。コンソール アクセス、帯域外の管理経路、文書化された再接続手順のいずれかです。後から決めることは、たいてい機械のところまで行くことを意味します。

ポリシーを回避するために、セッションを乗っ取る仕掛け、別のリモート制御ツール、スクリプトに書いたパスワードを使わないでください。組織がこの作業手順を認めていないなら、正しい行動は組織が支援する管理の経路です。

管理者に送るもの

メッセージの文面、クライアントのバージョン、有効なプロファイル名、接続したセッションの種類、ローカル コンソールからの試行が異なる動作をするかどうかを伝えます。時刻も添えます。

時間を節約するのはこの最後の比較です。セッション ポリシーによる拒否と、デバイス全体の障害を切り分けられるからです。

承認された変更の後に確認する

プロファイルが更新されたら、新しい RDP セッションを確立して再接続し、そのうえで切断の手順を意図的にたどります。トンネルが上がること、管理経路が生き残ること、アカウントが今もデスクトップにサインインできることを確認します。

VPN の受け入れ、セッションの存続、Windows のログオン許可は三つの別々の確認です。一つ通っても、残り二つについては何もわかりません。