日時のずれでリモートデスクトップがリモートコンピュータのIDを確認できないときの対処法

ADドメイン内のリモートサーバーに対してRDP(リモートデスクトップ)接続を試みたところ、次のようなエラーに遭遇しました。RDPユーザーとして正しいドメイン資格情報を入力したにもかかわらず、エラーメッセージが表示され、そのままRDPクライアントのウィンドウが閉じられてしまったのです。

「ローカルコンピュータとリモートコンピュータの間に時刻または日付の違いがあるため、リモートデスクトップはリモートコンピュータのIDを確認できません。コンピュータの時計が正しい時刻に設定されていることを確認してから、再接続してください。問題が繰り返し発生する場合は、ネットワーク管理者またはリモートコンピュータの所有者にお問い合わせください。」

Kerberos認証と5分ルール

このエラーは一見、Kerberos認証の失敗を示しています。Kerberosプロトコルでは、クライアントとサーバー間の時刻のずれが5分以内である必要があるためです。

しかしこのケースでは、実際にはそうではありませんでした。HPE ILO経由でリモートサーバーのコンソールを開いて確認したところ、両方のコンピュータの時刻とタイムゾーンは同一であり(同じNTPサーバーから時刻を取得)、特に問題はないことが判明したのです。

リモート側の時刻の確認と手動同期

まず、以下のコマンドでリモートコンピュータの時刻を確認できます。

net time \\リモートコンピュータのIPアドレス

念のため、時刻を手動で同期し、w32timeサービスを再起動しておくのも有効です。

w32tm /config /manualpeerlist:NTPサーバーのIP NTP,0x8 /syncfromflags:manual
net stop w32time & net start w32time & w32tm /resync

なお、コンピュータの時刻がずれる原因としては、CMOS電池の消耗や仮想化環境特有の時刻同期の問題など、ほかにもさまざまな要因が考えられます。

仮想マシンの場合の注意点

ヒント: リモートサーバーが仮想マシン(VM)である場合は、VM設定でホストハイパーバイザーとの時刻同期が無効になっているかを確認してください。ホスト側の時刻がずれていると、ゲストOSの時刻も連動して狂うことがあります。

DNSサーバーへの疎通を確認する

リモートコンピュータに物理的(または帯域外)アクセスできる場合(ILOコンソール経由など)、ネットワークアダプターの設定でDNSサーバーを確認します。さらに、リモートサーバーからそのDNSサーバーに到達できることも確かめましょう。以下のコマンドが便利です。

nslookup 確認したいサーバー名 DNSサーバー名

DNSサーバーが応答しない場合は、DNSサーバー自体が正常に稼働しているか確認するか、別のDNSサーバーアドレスを指定してみてください。

複数NIC環境でのルーティング確認

リモートコンピュータで複数のネットワークアダプターを使用している場合は、DNSサーバーへのアクセス時にルーティングテーブルが正しいかどうかを確認してください。コンピュータが、別のIPサブネットに属する別のアダプター経由でDNSサーバーへアクセスしようとしている可能性があります。

FQDNではなくIPアドレスで接続する

RDPクライアントの接続画面で、完全修飾ドメイン名(FQDN)ではなくIPアドレスを指定して接続してみてください。この場合、認証にKerberosが使用されなくなるため、時刻ずれに起因するKerberos認証エラーを回避できます。

ADドメインとの信頼関係(セキュアチャネル)を確認する

Active Directoryドメインとの信頼関係が維持されているかは、PowerShellで次のコマンドを実行して確認できます。

Test-ComputerSecureChannel

信頼関係が正常であれば「True」が返されます。

信頼関係の修復方法

信頼関係が壊れている場合は、管理者権限で次のコマンドを実行して修復できます。

Test-ComputerSecureChannel -Repair -Credential contoso\管理者アカウント名

修復時に「Test-ComputerSecureChannel : ドメイン内のコンピュータアカウントのセキュアチャネルパスワードをリセットできません。操作は次の例外で失敗しました: The server is not operational」というエラーが表示される場合は、サーバーからドメインコントローラーに到達できるかを確認し、portqryなどのツールを使って「Domain and Trusts」サービスに必要なTCP/UDPポートが開放されているかをチェックしてください。

RDPセキュリティレイヤーの設定を揃える

ローカルコンピュータとリモートコンピュータで、同じ「RDPセキュリティレイヤー」が選択されていることも確認します。この設定は、グループポリシー(GPO)の [コンピューターの構成] → [管理用テンプレート] → [Windows コンポーネント] → [リモート デスクトップ サービス] → [リモート デスクトップ セッション ホスト] → [セキュリティ] にある「リモート(RDP)接続に特定のセキュリティレイヤーの使用を必須とする」ポリシーから変更できます。トラブルシューティング中は、より互換性の高い(安全性の低い)RDPレベルを選択して挙動を比較するのも一案です。

あるいは、次のレジストリキーで直接設定することも可能です。
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\SecurityLayer

CredSSP関連の変更もチェックする

最後に、問題がCredSSP(資格情報セキュリティサポートプロバイダー)プロトコルの最近の変更(たとえば2018年の脆弱性対策による暗号化オラクルの修復など)に起因していないことも確認しておきましょう。クライアントとサーバーの両方に最新のWindows更新プログラムが適用されているかを確認することが重要です。