はじめに
2025/5/2 に、以下の記事が投稿されました。
GIGAZINE：Windowsのリモートデスクトッププロトコルは変更済みの古いパスワードでもログイン可能＆Microsoftは公式の仕様としているため永続的に存在するバックドアになるとの指摘
https://gigazine.net/news/20250502-windows-rdp-log-in-revoked-passwords/
Copilot 要約
- "WindowsのRDP（リモートデスクトッププロトコル）" は、変更済みの古いパスワードでもログイン可能であることが判明。
- Microsoftはこの仕様を公式の設計としており、変更する予定はないと発表。
- セキュリティ研究者のダニエル・ウェイド氏がこの問題を発見し、Microsoftに報告。
- パスワード変更後も古いパスワードが有効であり、クラウド認証や多要素認証を回避できる可能性がある。
- "Microsoftは「システムがオフラインでも少なくとも1つのアカウントがログイン可能にするための設計」" と説明。
- "セキュリティ専門家は「永続的なバックドア」" と指摘し、懸念を表明。
- 唯一の対策はRDPをローカル認証情報のみで認証するよう設定すること。
これが結構インパクトがあり、私の身の回りでも話題になりました。
別々の現場で、それぞれ話題になっていたので、世の中的にも気になっている人は多いのではないでしょうか？
結論から言うと、これは ホント です。
とは言え、無条件に 危険 とだけ騒ぐ話ではなく、ちゃんと内容を理解して 受け入れられる部分は受け入れて、気づいていなかったリスクに気が付くことで対策を施すことができれば良いんじゃないかと思います。
これについて、私なりに見解を述べておきたいと思い、記事にしたいと思います。
まず、GIGAZINE の記事は、どういう利用シーンに該当するのか、整理してみました。
せっかくなので、これを機に、下記の ① ～ ④ の全パターンについて まとめて考える機会にしたいと思います。
| 利用方法 ▶ ▼ 認証方法 |
物理 PC | リモートデスクトップ |
|---|---|---|
|
ID プロバイダー (Microsoft アカウント) (Microsoft Entra ID) |
① | ② GIGAZINE 記事の対象 |
| Active Directory ドメイン | ③ | ④ |
1. 公開情報の内容を読み解く
1-1. 概要と影響範囲について
まずは、GIGAZINE の記事でも取り上げられている、以下の箇所について。
公開情報：上記の青字部分のリンク先
https://learn.microsoft.com/ja-jp/windows-server/security/windows-authentication/windows-logon-scenarios?wt.mc_id=mvp_407731
上記、公開情報のキャプチャ
上記を解釈してみると、以下のようなシナリオになっています。
- ユーザーが、手元の PC でログオンを実行
- そのユーザーの "ID + パスワード" は、キャッシュ（その PC で 過去にログオンした際の記録）と比較されて 一致していればログオンに成功します（★1）
- この仕組みによって、手元の PC が オフライン（インターネットに繋がっていない）でも、ログオンが可能になります（★2）
★1 ID プロバイダー（つまりクラウド側）より前と説明されているので、インターネットに繋がっていても同じ動作になると説明されています
★2 仮に、ユーザーが ID プロバイダー側 でパスワードを変更していたとしても、手元の PC のキャッシュ情報は更新されないので、いつまでも 古いパスワードのまま ログインできてしまいます
問題点
上記の ★1 と ★2 で書かれている点が問題点だ！ という指摘をしていることになります。
つまり、PC を紛失したからといって、ID プロバイダー側で パスワードを変えたり、アカウントを無効化したりしても、ダメだよ・・・ということです。
どうやら、ホント に懸念がある・・・という風に読めますね。
1-1-1.（影響範囲）ID プロバイダーとは？
上記で、ID プロバイダー と説明されているものは、いったい何を指しているのでしょうか？
この場合、以下の２つが該当し、これが 影響範囲 となります。
-
Microsoft アカウント（MSA とも呼ばれます）
→ スタンドアロン (WORKGROUP) の PC に MSA でログオンするように構成されている場合 -
Microsoft Entra ID（旧Azure AD、"組織アカウント" とか、"職場または学校アカウント" とも呼ばれます）
→ Microsoft Entra Join が構成されている場合
※ドメインコントローラー (Active Directory) の場合は、含まれていません。
1-1-2. ドメインコントローラーの場合ってどうなの？
GIGAZINE の記事で意図されている ID プロバイダー には、ドメインコントローラー（つまりドメインに参加した PC）は含まれていません。
ドメイン環境でも、キャッシュログオン という機能が搭載されており、社外に持ち出した場合でも ログオンすることが可能です。その点では、似たような問題が発生します（ドメイン側で アカウントを失効させても、パスワードを変更したとしても、PC が オフラインの状態では、古いパスワードでログオンが可能です）
まあ、これって 企業の情報システム部さんは 皆さん知っていることであり、特に問題視していないと思います。
セキュリティ的な懸念は もちろんありますが、別のソリューション と組み合わせてカバーしているでしょうし、情報リソースは 社内 LAN 側にあります。
※"別のソリューション" については、1-3. 物理 PC に関しての対策 で説明しています。
歴史のある 認証基盤 であるだけに、ちゃんとリスクが理解された範囲で運用されているという訳です。
ポイント
なお、ドメインコントローラー と接続できる場合には、必ず ドメインコントローラーで認証されるようになっているため、社内リソースにアクセスするためには、アカウントが失効されておらず、パスワードは最新のものを使う必要があります。この点が、ID プロバイダー によるログオン と ドメインログオン では異なる部分となっています。
（再掲）
| 利用方法 ▶ ▼ 認証方法 |
物理 PC | リモートデスクトップ |
|---|---|---|
|
ID プロバイダー (Microsoft アカウント) (Microsoft Entra ID) |
① | ② GIGAZINE 記事の対象 |
| Active Directory ドメイン | ③ | ④ |
次の章では、ID プロバイダー で認証された PC（上記の ① と ②）について掘り下げていきたいと思います。
1-2. 掘り下げた解釈
もう少し、具体的に説明されている箇所をさがしたところ、以下の公開情報に行き当たりました。
Microsoft Entra 参加済みデバイスでユーザーのキャッシュされたログオンを無効にしたり、キャッシュ ログオンを期限切れにしたりするにはどうすればよいですか?
https://learn.microsoft.com/ja-jp/entra/identity/devices/faq?wt.mc_id=mvp_407731#microsoft-entra--------------------------------------------------------------------
上記 URL 抜粋
Microsoft Entra 参加済みデバイスで以前にキャッシュされたログオンを無効にしたり、期限切れにしたりすることはできません。
ズバリ、明確に書かれちゃってますね。古いパスワードを使い続けられるってことです。
Microsoft Entra 参加済みデバイスでユーザーが一時または期限切れのパスワードを変更するにはどうすればよいですか?
https://learn.microsoft.com/ja-jp/entra/identity/devices/faq?wt.mc_id=mvp_407731#microsoft-entra-----------------------------------------------
上記 URL 抜粋
現在、Microsoft Entra 参加済みデバイスでは、ユーザーがロック画面でパスワード変更を求められることはありません。 そのため、一時または期限切れのパスワードを持つユーザーは、Windows にログインした後で、(Microsoft Entra トークンを必要とする) アプリケーションにアクセスしたときにのみ、パスワードを変更するように求められます。
ID プロバイダー側のアカウントの期限が切れたとしても、手元の PC のログオンは 引き続き 古いパスワードを使えるということです。トークンを必要とするアプリとは、Microsoft 365 などのクラウドサービスですね。これらを使う際に クラウドの認証が走って、その際にパスワードの変更を求められます。
ユーザーは Microsoft Entra ID で削除されたか無効にされた Microsoft Entra 参加済みデバイスにサインインできますか?
https://learn.microsoft.com/ja-jp/entra/identity/devices/faq?wt.mc_id=mvp_407731#------microsoft-entra-id---------------microsoft-entra--------------------
上記 URL 抜粋
はい。 Windows には、以前にサインインしたユーザーがネットワークに接続していなくてもすばやくデスクトップにアクセスできるようにする、キャッシュされたユーザー名とパスワードの機能があります。
Microsoft Entra ID でデバイスが削除または無効化されても、Windows デバイスにはわかりません。 そのため、以前にサインインしたユーザーは、引き続きキャッシュされたユーザー名とパスワードを使ってデスクトップにアクセスします。 しかし、デバイスは削除または無効化されているため、ユーザーはデバイスベースの条件付きアクセスによって保護されているリソースにアクセスできません。
以前にサインインしたことのないユーザーは、デバイスにはアクセスできません。 そのようなユーザーには、キャッシュされたユーザー名とパスワードが有効になっていません。
これ、分かりづらいですが、Microsoft Entra ID から デバイス を切り離した場合のことを指していて、ユーザーアカウントは、有効なままの状態です。
デバイス を無効化しても 手元の PC は、気づきません・・・とあります。
その代わり、クラウドアプリを使おうとする際に 認証が走ります・・ということで、クラウド上のリソースは 最新のパスワードで守られているという事になりますが、手元の PC には ログオン可能であり、ローカルにある情報は 引き続き リスクにさらされているという事になります。
クラウドのリソースにアクセスしようとした際に、条件付きアクセスで デバイス が指定されていた場合は、そのデバイスは すでに テナントには存在しないため、ブロックされるという事です。
無効にされたか削除されたユーザーは、Microsoft Entra 参加済みデバイスにサインインできますか?
https://learn.microsoft.com/ja-jp/entra/identity/devices/faq?wt.mc_id=mvp_407731#------------------microsoft-entra--------------------
上記 URL 抜粋
はい、ただし限られた期間だけです。 Microsoft Entra ID でユーザーが削除または無効化されても、Windows デバイスはそのことをすぐには認識しません。 そのため、以前にサインインしたユーザーは、キャッシュされたユーザー名とパスワードを使ってデスクトップにアクセスできます。
通常、デバイスが認識するユーザーの状態は、4 時間以内の状態です。 その後は、Windows がそれらのユーザーのデスクトップへのアクセスをブロックします。 ユーザーが Microsoft Entra ID で削除または無効化されると、すべてのトークンが取り消されます。 そのため、ユーザーはリソースにアクセスできなくなります。
削除または無効化されたユーザーのうち、以前にサインインしたことのないユーザーは、デバイスにはアクセスできません。 そのようなユーザーには、キャッシュされたユーザー名とパスワードが有効になっていません。
こちらが、Microsoft Entra ID 上の ユーザー を無効化した場合のことを言っています。
ユーザーアカウント を "無効" ・ "削除" を行っても、４時間の間は 手元の PC にはログオンできてしまいます。無効化すれば、PC には ログオン出来なくなるという事ですね。
なお、これは、インターネットに接続されていれば・・・というのが前提ですね。
もし、PC がオフラインの状態であれば、パスワードのキャッシュを使って 永続的にログオンが可能です。
ポイント
この公開情報の内容は、特に 覚えておいてください（ユーザー削除 & ４時間）
後半の２章で、検証していますが、検証結果も記載してあります。
（公開情報の掘り下げ の まとめ）
ID プロバイダー のアカウントは、クラウド側のリソースを守るためのものであって、手元の PC 内のローカルな情報を守るためには 役に立たない・・・という事になります。
最近の ID プロバイダー のアカウントは、MFA を利用する必要がありますよね。
SMS や Authenticator とか FIDO2 セキュリティキーなどを組み合わせて使います。
つまり、クラウドに置いておけば、適切に管理されているという事になります。
※あくまで、MFA のレベルでってことで、100% 万全と言っているわけではありません。
しかし、手元の PC に関しては、MFA とはならずに パスワード を使った認証のみですよね。
まあ、PC を紛失せずに 常に 手元に置いておけば 自分しか入れないので問題ないのですが、紛失・盗難 をされてしまったら、対処できないという事であり、その場合 ID プロバイダー のアカウント制御では、ローカル上の 情報資産を 守れない ということが結論です。
さて、GIGAZINE の記事に話を戻します。
公開情報の掘り下げ では、特に リモートデスクトップ に言及していません。
つまり、物理 PC を使ったログオン も、リモートデスクトップ を使ったログオンでも、どちらも 同じようにキャッシュログオンの振る舞いになるという事です。GIGAZINE の記事では、リモートデスクトップ が脆弱だ！ と言っている訳なので、次の章では、物理 PC の場合と、リモートデスクトップ の場合 とで、分けて考えていきたいと思います。
（再掲）
| 利用方法 ▶ ▼ 認証方法 |
物理 PC | リモートデスクトップ |
|---|---|---|
|
ID プロバイダー (Microsoft アカウント) (Microsoft Entra ID) |
① | ② GIGAZINE 記事の対象 |
| Active Directory ドメイン | ③ | ④ |
1-3. 物理 PC に関しての対策
1-3-1. 物理 PC "①" と "③" の共通点
この章では、表の "①" と "③" つまり 物理 PC について説明します。
前章までの まとめと見解では、手元の PC のローカルにある情報を守る必要があることが分かったと思います。
そうすると、ローカルにある情報を守るために、どういう対策を講じれば良いのかが分かります。
-
① ローカルに 機密情報 を置かないというルール
盗まれても良い情報だけを、ローカルに置く・・という 利用者に責任を押し付ける方法ですが、企業では こんな対策では不十分ですね。 -
② PC を外に持ち出さない
会社から持ち出さない。在宅ワークの場合でも、家から絶対に持ち出さない・・などの対策がありますが、これは、一定の効果があると思います。合わせ技で、ケンジントンロックするなど。
でも、家に持っていく途中での紛失もあるし、盗難に遭うかもしれない。ルールを破って、カフェで仕事をしちゃう社員も居るかもしれないです。 -
③ Bitlocker 暗号化、EFS 暗号化
よく使われる手法ですが、あくまで HDD や ファイル が一律で暗号化されているだけです。HDD を外されて 別の PC へ接続して閲覧されてしまうというリスクに対する対策となります。
PC にログオンが出来てしまえば、ディスクの内容が見えてしまうので、本件の対策としては 片手落ちの対策です。 -
④ PC の起動時に TPM の PIN を使う
これと Bitlocker を組み合わせることで、ある程度の効果が期待できると思います。
PIN の認証を通らないと、OS を起動できないので、キャッシュされたパスワードを使う以前のところでガードできます。TPM の PIN は、ハンマリング防止機構 があるので、パスワードよりも安全です。
但し、PC をスリープ状態で持ち歩かないようにする必要がありますね。 -
⑤ 手元の PC のログオンに パスワードを使わない（パスワードレス化する）
FIDO2 セキュリティキー や、Windows Hello (for Business)、スマートカードログオン を採用して、ユーザーのパスワードを完全無効化してしまいます。当然、PC と キー や カードは 別々に管理する必要がありますね（一緒のバッグに入れて置いたらダメです）
この場合ですが、バッグごと盗まれた場合、キーを挿して PIN でログオンが試行されてしまいますが、ハンマリング防止機構 によって 総当たり攻撃 を回避することができるため、パスワードよりはマシです。
※PIN を書いた紙のメモも一緒だったら、元も子も無いですが・・・ -
⑥ 仮想デスクトップ (VDI) 化する
これも良く使われる手法です。
シンクライアントには、情報を置かずに クラウドのみに保存する方法です。
Microsoft が提供するサービスとしては、Windows 365 とか Azure Virtual Desktop というソリューションがあります。 -
⑦ Intune を使う
Intune は、デバイス管理のソリューションです。
リモートワイプ を使い、デバイス盗難の際に ディスクの内容を削除することが可能です。
しかしながら、PC が起動されて インターネットに接続された状態にならないと、ワイプできないので、限界があります。なお、SIM を内蔵できる機種を採用して、あえて 常に インターネットに接続できるようにしておく・・というのは、対策になると思いますね。 -
⑧ Microsoft Purview を使う
企業リソースを、ファイル単位で 常に暗号化して利用する方法です。
クラウドにあっても、ローカルにあっても ドキュメントを開く際には、常に Microsoft Entra ID を使って認証されるようになります。この方法は、一定の効果が見込めると思います。
物理 PC に関しては、リスク と コスト のバランスにはなりますが、それらを考慮しつつ、対策を講じれば良いと思います。まあ、従来の考え方と一緒ですね。せっかくの機会なので、上記の対策例をみて あ、うちの会社は対応が漏れてる観点があったなとお気づきの場合は、追加の対策を検討してみてください。
PC が盗難に遭った場合と、ユーザーのパスワードを無効にしても ログオンされちゃう・・という現実を把握したうえで対策を講じれば良いわけです。
従来の ドメイン環境 の場合も、オフライン環境だったら、アカウントを無効にしても PC にログオンできてしまう訳です。ローカル上の情報を守るためには、全く 同じような対策が必要・・・という話になると思います。
個人 PC の場合の対応策
⑥～⑧ の対策は、個人 PC では 実現ができないと思います。
実は、⑤ パスワードレス化 のうち、Windows Hello については 対応が可能です。
Microsoft アカウント の場合は、サインインオプション の設定で、セキュリティ向上のため、このデバイスでは Microsoft アカウント用に Windows Hello サインインのみを許可する という設定があります。
これを オン にしておくことで、サインイン 画面に パスワード の選択肢がなくなるので、多少の対策になると思います。
公開情報：Windows の Sign-In オプション
https://support.microsoft.com/ja-jp/windows/windows-の-sign-in-オプション-8ae09c04-c5da-41c9-972f-b126a13d18a8
1-3-2. 物理 PC "①" と "③" における相違点
（再掲）
| 利用方法 ▶ ▼ 認証方法 |
物理 PC | リモートデスクトップ |
|---|---|---|
|
ID プロバイダー (Microsoft アカウント) (Microsoft Entra ID) |
① | ② GIGAZINE 記事の対象 |
| Active Directory ドメイン | ③ | ④ |
前章では、表の "①" と "③" の対策は、一緒です・・と言ってきましたが、
それでは、表の "①" と "③" では、どういう場合に相違が出てくるのか考えてみました。
シナリオ 1
事業所に 共用の PC が数台あって、数百人の従業員がいる場合などが考えられます。
まず、パスワードの変更をする場合のリスクがあります。
パスワードが漏洩したな・・と思って、パスワードを変更するシーンがあると思います。
共用 PC のうち 任意の１台を 使って、パスワードを変更し、ID プロバイダー側もパスワードが変更されました。
しかし、これだけでは 別の 共用 PC のパスワードは、古いままです。
パスワードの漏洩対策をしたつもりが、考慮漏れが発生しているかもしれません。
第３者が 漏洩したパスワードを使って 別の 共用 PC からログオンできてしまう余地が生まれます。
"③" の Active Directory ドメイン であれば、こういう状況は発生せず、すべての 共用 PC のパスワードは、一律で保たれるので、違いが生じますね。
シナリオ 2
次に、従業員の離職に際しての運用による違いです。
この場合、離職した従業員がいた場合は、ユーザーアカウントを 無効 or 削除 します。
共用 PC を停止してしまうと、他のユーザーが仕事できなくなるので、困る・・・ってシチュエーションですね。
なので、PC を止める手立てが使えません。
このとき、ID プロバイダー で認証をしている "①" のパターンだと、公開情報では、ユーザーアカウントの状態の反映は、４時間以内となっています。
"③" の Active Directory ドメイン の場合は、これが 即座に反映されるため、ここに違いが生じることになると思います。
まあ、事業所内に設置してある PC であれば、４時間くらいは、使える余地があっても いいんじゃないか・・・とも考えられますが、私が検証してみた結果では、キャッシュが削除されない ・・・という事象も観察されているため注意が必要です（最終章で説明しています）
シーン3
全社員に Microsoft Entra Join された PC が提供されています。
通常は、１名１台 で使っているのですが、緊急用に 貸し出し用の PC が用意されています。
ある日、緊急用の PC を借りてログオンしました。ここで キャッシュが残ります。
※Entra Join されている PC は、実は 誰のアカウントでもサインインできるのです。
その後、また 自分の PC の利用に戻りました。
あるとき、パスワードが漏洩したかな・・・と思って、自分の PC を使って パスワードを変更しました。
ですが、緊急貸し出しで利用した PC に残っているパスワードは、依然として古いままです。
なので、本当に パスワード が漏洩してしまっていたとしたら、この 貸し出し用 PC を使って、ログオンされてしまうリスクがあります。パスワード漏洩に対して、パスワード変更が 無意味になってしまう可能性があります。
"③" の Active Directory ドメイン であれば、社内 LAN に接続していれば、こういう状況は発生せず、緊急貸し出しの PC も、変更後のパスワードでログオンする必要があります。
私としては、差は この点くらいなのかなと思っていますが、考慮漏れなどがありましたら、ぜひ コメント欄で教えてください。
1-4. リモートデスクトップ に関しての対策
1-4-1. リモートデスクトップ "②" と "④" の共通点
（再掲）
| 利用方法 ▶ ▼ 認証方法 |
物理 PC | リモートデスクトップ |
|---|---|---|
|
ID プロバイダー (Microsoft アカウント) (Microsoft Entra ID) |
① | ② GIGAZINE 記事の対象 |
| Active Directory ドメイン | ③ | ④ |
物理 PC は、手元にあるわけなので、モノを 自分で管理している上では 大丈夫です。
あくまで、紛失＆盗難 に遭った場合の対策を考えれば良かったのです。
しかし、リモートデスクトップ の場合は、ネットワークを使って どこからでも リモートでアクセスすることが可能です。クラウド上に ホスト があった場合、世界中から接続が可能です。
これに対する対策は、以下のようなものが考えられます。
-
ホスト へリモート接続できる対象を絞る
Azure であれば、NSG で、リモートアクセスが可能な可能な IP アドレスを限定する方法や、Just in Time VM アクセス という仕組みがあります。 -
ホスト を停止する
利用者専用のホストであれば、アカウントを無効化するのに合わせて、そのホスト を止めてしまえば良いです。
これらは、よく知られた手法ですよね。
上記の対策としては、"②" と "④" は一緒という訳です。
そのため、きちんと この方法で 管理を行っておけば 大丈夫なんじゃないかという訳です。
1-4-2. リモートデスクトップ "②" と "④" の相違点
ようやく本題です。
では、② GIGAZINE 記事の対象 に限定したリスクって、どういう場合なのでしょうか？
② の場合 は、オンラインの場合であっても、パスワードをリセットしても デバイス側のログオンキャッシュが優先されます。しかし、④ の場合 は、オンラインであれば 必ず ドメインコントローラーへ認証されるため、変更後のパスワードで認証されます。
いままでの理解を踏まえて、どういう場合だと リスクが生じそうか 考えてみました。
シーン1
ある情報システム部では、Microsoft Entra Join された Azure VM 上に 保守用の踏み台 環境を整備して、数台のマシンを メンバー間で共用 で利用しています。
保守用の踏み台 環境とは、インターネット経由で リモート接続を行ったあと、その踏み台を介して、社内の業務用サーバーに接続する仕組みです。作業用の VM を 共用 で利用するパターンが多いと思います。
ある社員が、リモート接続手順と パスワードを書いたメモを紛失してしまった との申告がありました。
じゃあ、危ないから パスワードをリセットしましょう・・・ってことで、リセットしました。
この社員は、再発行されたパスワードを使って仕事ができるようになりました。
このとき、共用の PC は 複数台あります。
利用者が すべての 共用 PC にアクセスするまでは、旧パスワードのキャッシュが残っているものがあるかもしれません。
シーン2
シーン1 と同様に、保守用の踏み台 を利用しています。
情報システム部の社員が退職することになったので、Microsoft Entra テナントから ユーザーを削除しました。
しかし、踏み台の作業用 PC には、サインインのキャッシュ が残り続けています。
このような場合、大変なリスクになりそうです。
ポイント
パスワードが漏洩した場合、ユーザーアカウントの対処をするだけでなく、ホストの方も 停止や削除するなどの措置が出来る状態であれば問題ないと考えます。しかし、共用 のホストになっていると、それが出来なくなり、セキュリティホールになりそうです。
2. 再現検証
では、Microsoft Entra Join された PC に RDP できる環境を作って、再現検証をしてみたいと思います。
環境は、以下の手順で 構築できます。
- Azure 上に VM を構築
- Microsoft Entra Join を実施（以下の URL を参考）
https://qiita.com/carol0226/items/74efd0c2cce7fc42e110
- Entra アカウントを使った RDP の接続許可設定を実施（以下の URL を参考）
https://qiita.com/carol0226/items/4f60443dead0a20e95f6
検証シナリオ1：パスワード変更時の振る舞い
- VM に、Entra アカウントでサインインします。
- VM から サインアウトします。
- Entra テナント で ユーザーのパスワードを変更します。
- VM に、旧 パスワードを使って サインインを試みます。
★このあと、パスワードの変更をしながら、旧で入ったり、わざとミスしたり、新で入ったりします。
検証シナリオ2：ユーザーアカウント削除時の振る舞い
- VM に、Entra アカウントでサインインします。
- VM から サインアウトします。
- Entra アカウント を 削除します。
- VM に サインインします。
- VM から サインアウトします。
- ４時間以上経過してから、VM にサインインします。
2-1. 検証シナリオ1：パスワード変更時の振る舞い
結果1：
旧パスワードでサインインしたあと、Entra テナントでパスワードを変更します。
そのあと、PC で 旧パスワードでサインインが可能でした。
結果2：
ふたたび、サインアウトしてからでも、旧パスワードでサインインが可能でした。
サインアウトを繰り返しても、旧パスワードでサインインが可能で、状況は変わらなそうです。
結果3：
再起動を行いました。
それでも、旧パスワードでサインインが可能でした。
再起動を繰り返しても、旧パスワードでサインインが可能で、状況は変わらなそうです。
結果4：
わざとパスワードを間違えました。
当然、エラーになりました。
そのあと、旧パスワードでサインインが可能でした。
推測1：
つまり、パスワードのチェックは、まず ローカルのキャッシュ と比較され、違っていれば クラウドへ認証 しに行くという２段階で行われている可能性があります。
※オフラインだった場合は、１段階目で終了
ふたたびサインアウトしてから、パスワード誤り と、旧パスワードのサインイン成功 を繰り返しましたが、同じことの繰り返しで 状況は変わらなそうです。
推測2：
当初、パスワードを間違えて、クラウドへの認証 が行われれば、新パスワードが PC に取り込まれて、旧パスワードでサインインできなくなるんじゃないかと思ったのですが、そうではありませんでした。
結果5：
サインアウトしてから、新パスワードで サインインしました。
すると、サインイン に成功しました。
ちゃんと、クラウド側のパスワードでも 入れるようです。
推測3：
オンラインであれば、パスワードが ローカルキャッシュと違っていた場合は、次に クラウドにも認証しに行っていると思われます。
そして、パスワードが クラウド側とも 違っていれば エラーになりますが、正しければ サインイン が出来るような実装になっていることが考えられます。
結果6：
サインアウト後、旧パスワードでサインインを試みました。
サインイン できません。
新パスワードでサインインを試みると、サインインができました。
何度か繰り返しても、もう 新パスワードでしか サインインが出来なくなっているようです。
結果考察
つまり、１度でも 新パスワードでサインインに成功すれば、ちゃんと切り替わっていて、過去のパスワードが記憶されていて、新パスワードで運用しているのに、裏で 旧パスワードでも入れてしまう・・・という事は無さそうです。
→ これが、Microsoft 側 の見解として 公式の設計で 変更するつもりはないと明言している根拠なのかなと思います。
GIGAZINE の記事を見たときには、パスワードを新しいものに変更した PC の場合でも、旧パスワードのキャッシュも残っていて RDP でサインインし続けられるんじゃないか・・・って心配しましたが、結論としては ちゃんと切り替わるという事です。
懸念事項
ただ、GIGAZINE の記事では、古いパスワードの履歴 云々という記載もあり、私の検証では 再現されなかった振る舞いがある可能性も否定はできません。
まあ、ひとまずの結論としては、私が シナリオで考えたとおり、共用 PC や 緊急用 PC があった場合に、パスワードを新しいものに切り替えないままのマシンが残っていると、そこに 隙が生まれるんじゃないかという懸念になるのかと思います。
パスワード変更時 の 対策案
一度でも、Entra アカウントでサインインしたことがある PC には、全部 新しいパスワードで 入りなおしておけば、良さそうに思います。まあ、たしかに 微妙な対策には違いが無いですが・・・
2-2. 検証シナリオ2：ユーザーアカウント削除時の振る舞い
結果1：
Entra テナント上から、アカウントを削除しました。
そのあと、そのアカウントで サインイン することができました。
やっぱり、削除 しても PC は気が付かない仕様になっているようです。
パスワード誤りで失敗して、そのあと キャッシュ上のパスワードを入れれば、サインインに成功してしまいます。
再起動して、再度 キャッシュ上のパスワードを入力しても、サインインできます。
これでも、アカウントが消えたことに気付かないのか・・・（最大４時間待つ必要がありそう）
結果2：
なんと、その後 4時間以上経過しても、アカウント削除を行ったユーザーで、キャッシュを使った RDP ログオンが可能 でした。あれ、公開情報の記載と違う！
これが RDP による バックドアなのか？
これが、GIGAZINE の記事で指摘されている 永続的なバックドア に該当するのかも。
前章の シナリオ2 で説明したような、保守用の踏み台 サーバーへ、退職した社員が引き続き アクセス可能な状態になってしまっているかもしれません。
ユーザー削除時 の 対策案
この結果が正であれば、セキュリティリスクになりえます。
十分に理解の上、テナントから ユーザーアカウントを削除した時には、それとセットで ユーザーが使っていたデバイスも始末するようにする必要があると思います。
3. さいごに
注意事項
あくまで、私が検証して、個人的に見解を述べた結果となります。
私も、アーキテクトではありますが、ハッカーレベルのセキュリティ知識までは持ち合わせていません。
考慮できていない 隙が あるのかもしれないため、今回 解説した公開情報の見解や、私の考えてみたシナリオ、私の検証結果 を踏まえつつ、ぜひ 運用環境で動作を検証して、大丈夫かどうか確かめておくことをお勧めします。
悪用禁物
安易に パスワードを人に教えちゃう人って、一定数いるし、その人が あとで パスワードを変更したから もう安心・・とか思ってしまう点に隙があるかなと。
電話越しに、ちょっと緊急だから パスワード教えてよ・・と言って、代理ログオンさせておき、いまパスワード聞いちゃってまずいから、変更しといてね・・とか言えば、本人も変更して安心しちゃうかなと（普通は 代理ログオンマシンのパスワードも変わると思っちゃう）
でも、代理ログオンに使った PC が手元に残っているので、これ使って 引き続き ログオンができちゃいますね。
クラウドリソースにアクセスする際に、MFA でブロック掛けられるとは言え、まあ、たしかに ハッカーレベルの人であれば、こんな感じで隙を作って、なんらかの攻撃を仕掛けられそうな気がしないでもないですね。
もし、考慮漏れがあるようであれば、ぜひ コメント欄でご指摘ください。
完全パスワードレス化 の ススメ
私の方で Windows や M365 環境を FIDO2 で 完全パスワードレス化 するための記事を公開中です。
こちらを参照いただき、ぜひ パスワードレス化 を検討してみてください。
＠carol0226 による FIDO2 の公開ストックリスト
https://qiita.com/carol0226/stocks/3670cb8678daed11b191
まず初めに、FIDO2 で Windows に サインインする（Entra Join 編） の記事から読んでいただくと読みやすいと思います。
長文となってしまいましたが、最後まで 閲覧いただき ありがとうございました。