Visual Studio入りEC2にRDP接続できなくなったので色々試してみた

Takuya Shibata

2022.08.07

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

しばたです。

前の記事で作成したVisual Studio入りEC2でいろいろと調査・検証していたのですが、あるとき突然RDP接続できなくなってしまいました。

本記事ではこの事象に対して行った対応について共有します。

TL;DR

最終的に理想的な結果にならなかったので最初に結論を書いておきます。

今回は何らかの理由によりセキュアチャネルが破損しRDP接続出来なくなりました。
セキュアチャネルが破損した際の一般的な対応を行うもVisual Studio入りEC2だと権限不足のエラーとなり解消できず、最終的に当該インスタンスを破棄し新しいインスタンスを作り直すことになりました。

Visual Studio入りEC2は利用可能なユーザーを制限するためにActive Directoryまわりの設定がかなり特殊です。
加えてマネージドサービスであるAWS Managed Microsoft ADでは管理者ユーザーはドメイン環境に対する完全な管理者権限(Domain AdminsやEnterprise Admins)を持っていません。
両者の制限により一般的な対応がうまくいかなかったものと推測されます。

何が起きたか？

Visual Studio入りEC2の調査を行い一度インスタンスをシャットダウンしました。
翌日にインスタンスを起動しRDP接続しようとしたところ下図のエラーメッセージが表示される様になってしまいました。

メッセージの内容自体はネットワークレベル認証(NLA)を要求するエラーですが、もともとNLAは有効で前日までは普通に接続できていました。
このため事前の設定不足ではなく新たにセキュリティに関連する何らかの問題が起きてしまった様です。

行った対応

このエラーメッセージが出た時の対応は多岐にわたるのですが、Azure VM向けのこのドキュメントがよくまとまっているので参考になります。

Troubleshoot authentication errors when you use RDP to connect to Azure VM

本記事でもこちらの内容に従って対応してみました。

1. SSM Session接続

RDPが使えない状況でしたがSSM Sessionは普通に使えました。
このため以後の対応は全てSSM Session上で行っています。

2. グループポリシーの更新

まずはドキュメントにある通りgpupdate /forceコマンドを使いグループポリシーの適用を試してみました。

gpupdate /force

結果としては何度か適用に失敗したあとにで適用に成功したのですが状況は改善されませんでした。
グループポリシー適用後に改めてインスタンスを再起動しなおしてもダメでした。

ワークアラウンドとしてNLAを無効にする方法もありますが、検証環境でしたしわざわざセキュリティを脆弱にする気も無かったので今回は採用しませんでした。

3. セキュアチャネルの検証

次にTest-ComputerSecureChannelコマンドを使いセキュアチャネルの状態を確認しました。

Test-ComputerSecureChannel -Verbose

結果は以下の様になり、ここでセキュアチャネルが破損していることが分かりました。

PS C:\> Test-ComputerSecureChannel -Verbose
VERBOSE: Performing the operation "Test-ComputerSecureChannel" on target "EC2AMAZ-PK0PF0F".
False
VERBOSE: The secure channel between the local computer and the domain corp.contoso.com is broken.

原因が分かったのであとは復旧してやるだけ、と気楽に構えていたのですがここからが長くなります...

4. セキュアチャネルの復旧

通常であればTest-ComputerSecureChannel -Repairでセキュアチャネルの復旧をしてやります。
SSM Session上でGUIが無いので以下の様な感じでクレデンシャルを指定して実行する必要があります。

$username = "admin@corp.contoso.com" # AWS Managed Microsoft ADの管理者ユーザー
$password = ConvertTo-SecureString "管理者のパスワード" -AsPlainText -Force
$cred = New-Object System.Management.Automation.PSCredential ($username, $password)
Test-ComputerSecureChannel -Repair -Credential $cred

結果は残念ながらアクセス権エラーになってしまいました。
AWS Managed Microsoft ADの管理者ユーザーの権限で実行してるのでこれ以上の権限はユーザーにはありません。

PS C:\> Test-ComputerSecureChannel -Repair -Credential $cred
Test-ComputerSecureChannel : Cannot reset the secure channel password for the computer account in the domain. Operation failed with the following exception: Access is denied. (Exception from HRESULT: 0x80070005
(E_ACCESSDENIED)).
At line:1 char:1
+ Test-ComputerSecureChannel -Repair -Credential $cred
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (EC2AMAZ-PK0PF0F:String) [Test-ComputerSecureChannel], InvalidOperationException
    + FullyQualifiedErrorId : FailToResetPasswordOnDomain,Microsoft.PowerShell.Commands.TestComputerSecureChannelCommand

5. コンピューターアカウントパスワードのリセット

次にReset-ComputerMachinePasswordコマンドを使いコンピューターアカウントパスワードのリセットを試みました。
こちらも前節と同様にしてクレデンシャルを指定してやります。

$username = "admin@corp.contoso.com" # AWS Managed Microsoft ADの管理者ユーザー
$password = ConvertTo-SecureString "管理者のパスワード" -AsPlainText -Force
$cred = New-Object System.Management.Automation.PSCredential ($username, $password)
Reset-ComputerMachinePassword -Server "$(hostname)" -Credential $cred

こちらも結果は失敗し「サーバーは使用可能でない」旨のエラーが出てしまいました。

PS C:\> Reset-ComputerMachinePassword -Server "$(hostname)" -Credential $cred
Reset-ComputerMachinePassword : Cannot reset the secure channel password for the computer account in the domain. Operation failed with the following exception: The server is not operational.
.
At line:1 char:1
+ Reset-ComputerMachinePassword -Server "$(hostname)" -Credential $cred
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (EC2AMAZ-PK0PF0F:String) [Reset-ComputerMachinePassword], InvalidOperationException
    + FullyQualifiedErrorId : FailToResetPasswordOnDomain,Microsoft.PowerShell.Commands.ResetComputerMachinePasswordCommand

6. ドメインからの離脱

ここまで全ての手順がダメでした。
仕方なく「一旦ドメインから離脱してその後EC2を再起動すれば自動でAWS License Managerが再参加させてくれるだろう。」と考えました。

ドメインからの離脱はRemove-Computerコマンドで行えます。
通常であればAWS Managed Microsoft ADの管理者ユーザーで何の問題もなく実行できるはずです。

$username = "admin@corp.contoso.com" # AWS Managed Microsoft ADの管理者ユーザー
$password = ConvertTo-SecureString "管理者のパスワード" -AsPlainText -Force
$cred = New-Object System.Management.Automation.PSCredential ($username, $password)
Remove-Computer -Credential $cred -Force

管理者ユーザーの権限でコマンドを実行したのですが、予想に反してアクセス権エラーで離脱できませんでした。

PS C:\> Remove-Computer -Credential $cred -Force
Remove-Computer : Failed to unjoin computer 'EC2AMAZ-PK0PF0F' from domain 'corp.contoso.com' with the following error message: Access is denied.
At line:1 char:1
+ Remove-Computer -Credential $cred -Force
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (EC2AMAZ-PK0PF0F:String) [Remove-Computer], InvalidOperationException
    + FullyQualifiedErrorId : FailToUnjoinDomain,Microsoft.PowerShell.Commands.RemoveComputerCommand

正直この結果は全く予想できませんでした...
「なんで管理者なのにドメインから離脱できないの？？？」って感じです。

ここからは予想になるのですが、前の記事で軽く紹介した様にAWS License Managerによるドメイン参加処理はかなり特殊です。
AWSが管理するAWS ReservedOU配下にインスタンス毎専用のOUを新規作成したうえでそこにコンピューターオブジェクトを配置する様になっています。
このため管理者であってもユーザーには離脱の権限が無いんだと思います。

実際自由にドメインから離脱できてしまうとグループポリシーによる制限も適用できずに不正な利用ができてしまいます。
このため制限されているのでしょう。