RDP を使用して EC2 Windows インスタンスに接続するときの認証エラーのトラブルシューティング方法を教えてください。
リモートデスクトッププロトコル (RDP) を使用して Amazon Elastic Compute Cloud (Amazon EC2) Windows インスタンスにログインしようとすると、認証エラーが表示されます。
解決策
RDP を使用して Amazon EC2 Windows インスタンスにログインすると、次の認証エラーが表示される場合があります。
- 「An authentication error has occurred.The Local Security Authority cannot be contacted.」
- 「The remote computer that you are trying to connect to requires Network Level Authentication (NLA), but your Windows domain controller cannot be contacted to perform NLA.If you are an administrator on the remote computer, you can disable NLA by using the options on the Remote tab of the System Properties dialog box.」
このエラーは、次のシナリオで発生する可能性があります。
- ネットワーク層認証 (NLA) がサーバーで有効になっています。
- RDP がログインすると、ドメインとこのドメインに参加している EC2 インスタンスとの間の信頼関係は失敗します。
サーバーの NLA が有効になっています
NLA エラーは、ドメイン認証情報が認証されていないためにインスタンスがドメインコントローラーへの接続を失ったときに発生します。この問題を解決するには、AWS Systems Manager AWSSupport-TroubleshootRDP 自動化ドキュメントを使用して、インスタンス設定を変更するか、インスタンスの NLA を無効にしてください。
AWSSupport-TroubleshootRDP自動化ドキュメントでは、RDP接続に影響を与える可能性のあるインスタンスの共通設定を変更できます。
以下のいずれかの方法を使用して、到達不可能なインスタンスの NLA を非アクティブ化します。
- AWS Systems Manager Session Manager を使用します。
- AWS-RunPowerShellScript コマンドドキュメントを実行します。
- レジストリをオフラインで手動で変更します。
**注:**NLA を変更するときは、レジストリを変更する必要があります。開始する前に、インスタンスから Amazon マシンイメージ (AMI) を作成します。これにより、レジストリを変更する前にバックアップが作成されます。
Systems Manager セッションマネージャーで NLA を非アクティブ化
Session Manager で NLA を非アクティブ化するには、次の手順を実行してレジストリキーを追加します。
重要: インスタンスには Systems Manager Agent (SSM Agent) がインストールされていて、インスタンスがオンラインになっている必要があります。インスタンスには、セッションマネージャーにアクセス権限を付与する AWS ID およびアクセス管理 (IAM) ロールも必要です。詳細については、「セッションマネージャーの前提条件」を参照してください。
- Systems Manager コンソールを開きます。
- ナビゲーションペインで、[フリートマネージャー] を選択します。
- 接続するマネージドインスタンスを選択します。
- [ノードアクション] メニューで、[ターミナルセッションを開始する]、[接続] を選択します。セッションマネージャーを使用してインスタンスに接続しています。
- ターミナルセッションで以下のコマンドを実行します。
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v SecurityLayer /t REG_DWORD /d 0 /f reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v UserAuthentication /t REG_DWORD /d 0 /f reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v fAllowSecProtocolNegotiation /t REG_DWORD /d 0 /f
AWS-RunPowerShellScript コマンドドキュメントを使用して NLA を非アクティブ化します
AWS:RunPowerShellScript コマンドドキュメントを使用して NLA を非アクティブ化するには、次の手順を実行してレジストリキーを追加します。
**重要:**インスタンスには SSM Agent がインストールされていて、オンラインになっている必要があります。インスタンスには、Session Manager にアクセス権限を付与する IAM ロールも必要です。詳細については、「セッションマネージャーの前提条件」を参照してください。
-
Systems Manager コンソールを開きます。
-
ナビゲーションペインで [コマンドを実行] を選択し、[コマンドを実行] を選択します。
-
[コマンドドキュメント] には、[AWS-RunPowerShellScript] を選択します。
-
[コマンドパラメータ] には、次のコマンドを入力します。
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v SecurityLayer /t REG_DWORD /d 0 /f reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v UserAuthentication /t REG_DWORD /d 0 /f reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v fAllowSecProtocolNegotiation /t REG_DWORD /d 0 /f -
[ターゲット]には、[インスタンスを手動で選択] を選択し、インスタンスを選択します。
-
[実行] を選択します。
-
[全体のステータス] が [成功] に変わるまで待ちます。2 分後にページを更新します。
-
インスタンスを再起動します。
-
RDP を使用して、インスタンスにログインします。
レジストリをオフラインで手動で変更
-
停止した到達不可能なインスタンスと同じアベイラビリティーゾーンで新しいインスタンスを起動します。新しいインスタンスがレスキューインスタンスになります。
**重要:**ディスク署名の問題を回避するには、到達不可能なインスタンスとは異なる Windows インスタンスを起動するのがベストプラクティスです。
-
デタッチしたボリュームを /dev/xvdf としてレスキューインスタンスにアタッチします。
-
RDP を使用してレスキューインスタンスに接続し、アタッチしたばかりのボリュームを Disk Manager でオンラインにします。
-
コマンドプロンプトで「regedit.exe」と入力し、Enter キーを押してレジストリエディターを開きます。
-
HKEY_LOCAL_MACHINE を選択し、次に [ファイル]、[ハイブのロード] を選択します。
-
アタッチされたボリュームの Windows フォルダに移動し、システムファイルを選択します。デフォルトパスは D:\Windows\System32\config です。
-
システムファイルに名前を付けます。たとえば、badsys。
-
badsys システムファイルが HKEY_LOCAL_MACHINE の下に表示されるようになりました。badsys の下で、ControlSet001、コントロール、ターミナルサーバ、WinStations、RDP-Tcp に移動します。
-
SecurityLayer をダブルクリックし、値のデータを** 0 に設定します。****[ユーザー認証]** を選択し、値のデータを 0 に設定します。次に、[AllowSecProtocolNegotiation] を選択し、値データを 0 に設定します。
-
上にスクロールして [badsys]、[ファイル]、[ハイブのアンロード] を選択します。
-
ハイブがアンロードされたら、ディスクマネージャーを開き、ディスクをオフラインにします。
-
レスキューインスタンスからボリュームをデタッチし、そのボリュームをルートボリューム (/dev/sda1) として接続します。
-
インスタンスを起動し、RDP をテストします。
お客様のドメインと、このドメインに参加している EC2 インスタンスとの間の信頼関係が、RDP ログイン中に失敗します
キャッシュされたユーザー認証情報を使用して、到達不可能なインスタンスへのログインを試みます。
前提条件
-
EC2 インスタンスに対して正常に認証できるローカルアカウント。
-
(オプション) インスタンスがドメインコントローラーと通信していたときにログインしていたドメインアカウント 1 つ以上。ドメインアカウントが機能するには、ドメインアカウントの認証情報をサーバーにキャッシュする必要があります。
**注:**ローカルアカウントを使用するのがベストプラクティスです。
-
ドメインコントローラーが使用できない場合は、キャッシュする以前のログイン数の設定が 1 以上に設定されていることを確認してください。インタラクティブログインを使用するには、これを実行する必要があります。このポリシーは、デフォルト値の 10 に設定できます。デフォルトでは、ポリシーは定義されておらず、サーバーのローカルポリシーを使用できます。
キャッシュされたユーザー認証情報を使用してログインするには、次の手順を実行します。
- EC2 コンソールを開き、[セキュリティグループ] を選択します。
- ナビゲーションペインで [セキュリティグループ] を選択します。
- [セキュリティグループの作成] を選択します。
- セキュリティグループ名と説明を追加します。
- [インバウンドルール] で [ルールを追加] を選択します。
- [タイプ] には、[RDP] を選択します。次に、RDP を使用して接続したいソースの情報を入力します。
- [アウトバウンドルール] で、すべてのアウトバウンドアクセスを削除します。
- [セキュリティグループの作成] を選択します。
- ナビゲーションペインで [インスタンス] を選択し、接続不可能なインスタンスを選択します。
- [アクション]、[セキュリティ]、[セキュリティグループの変更] を選択します。既存のセキュリティグループをすべて削除し、作成したセキュリティグループを割り当てます。
- RDP を使用して EC2 インスタンスに接続するには、通常のドメインアカウントを使用します。Amazon EC2 からすべてのアウトバウンドアクセスが削除されるため、サーバーに保存されているキャッシュされた認証情報を使用します。
**注:**認証は最初にドメインコントローラに対して試行されます。ただし、Amazon EC2 からのアウトバウンドアクセスがないため、認証は最終的にサーバーに保存されているキャッシュされた認証情報を確認します。キャッシュされた認証情報を使用して認証が再試行され、ログインが成功します。ログインしたら、セキュリティグループの設定を元の状態に戻し、ドメインの問題があれば修正を続けることができます。
その他のトラブルシューティング
それでもインスタンスに接続できない場合は、「Amazon EC2 Windows インスタンスへのリモートデスクトップ接続の問題のトラブルシューティング方法を教えてください」を参照してください。
