ネットワーク認証にPEAPを使っているところは今後注意が必要かも？なWindowsのCredential Guardのお話。

皆さんネットワーク認証、してますか？

ITシステムの世界で”認証”という単語は2025年現在、非常に幅広い用途で用いられています。
端的に表現すると「人や物(システムやデバイス)を適切な利用権限があるかどうかを確認する行為」を指しますが、「どうやって確認するか」については非常に多くのアプローチがあります。
ネットワークの世界での認証と呼ばれる行為はレイヤ2からレイヤ7まで多くの種類があり、その方法や資格情報(クレデンシャル)も様々です。

今回のテーマであるCredential Guardも複数の認証に絡んでくる機能ですが、本記事ではレイヤ2のいわゆる「ネットワーク認証」に焦点を当ててお話ししたいと思います。

ネットワーク認証では比較的導入しやすいPEAPですが、Windows環境では今後注意が必要かもしれません

レイヤ2のネットワーク認証としてエンタープライズネットワークの中で多く使用されているものとして802.1X/EAPがあります。
802.1X/EAPは認証情報として証明書を用いるEAP-TLSが多くの場合セキュリティ的に強固と言われていますが、クライアント側(サプリカント側)にも個別の証明書が必ず必要のため運用負荷としては後述するPEAPより高くなります。

EAP-TLSに次いで利用しているユーザーが多いと思われるPEAP(EAP-MSCHAPv2)については、クライアント側(サプリカント側)は証明書ではなくユーザID/パスワードを利用します。個別の証明書のクライアント側への発行/配布がない分、大規模な展開がEAP-TLSに比べて容易になります。
この比較的導入が容易で広く用いられているPEAP(EAP-MSCHAPv2)ですが、メインで使用されているWindowsの今後の動向に注意をする必要が出てきたので実際に検証を行い挙動を確認してみました。

Credential Guardとは

Windows10以降の特定のエディションのクライアント用Windowsや、WindowsServerとの組み合わせによって有効化することができるNTLMパスワードハッシュやKerberos TGTなどのドメイン資格情報を保護することができる機能です。

またOSだけではなくデバイスのハードウェア的にも対応が必要で、仮想化ベースのセキュリティやセキュアブート、TPMモジュール(これはCPUに内蔵されるIntel PTTやAMD fTPMなどを含みます)などが必要になります。

このCredential GuardはWindows11では要件を満たす場合に自動的に有効化されるという特徴があるため注意が必要です。

• Windows11以降(Windows11 22H2以降)での要件(2025/3月時点)
  ・ライセンス要件を満たす
  ・ハードウェアとソフトウェアの要件を満たす
  ・Credential Guardを無効にするよう明示的にデバイスが構成されていない
• WindowsServer2025以降での要件
  ・ライセンス要件を満たす
  ・ハードウェアとソフトウェア要件を満たす
  ・Credential Guardを無効にするように明示的に構成されていない
  ・ドメインに参加している
  ・ドメインコントローラではない

引用元：https://learn.microsoft.com/ja-jp/windows/security/identity-protection/credential-guard/

クライアントWindows、Windows Server共に「Credential Guardを無効にするように明示的に構成されていない」という要件があり、この設定をローカルポリシー/GPOで構成することによりCredential Guardを無効化することは可能です。

逆説的に言えば、この設定を意図的に構成していない場合、ライセンス要件を満たすOSおよび要件を満たすハードウェア/ソフトウェア環境では自動的にCredential Guardが有効化されてしまう点には注意が必要と言えます。
特にクライアントに関しては、Windows11のインストール要件がそもそもCredential Guardの利用に必要なハードウェア要件とほぼ一致しているため、意図せず有効化されてしまった、ということは起こりうる状態と言えるでしょう。

そしてCredential Guardには「Wi-Fi と VPN に関する考慮事項」として以下のような記載があります。

-------
Credential Guard が有効になっている場合、シングル サインオン (SSO) に NTLM クラシック認証 (NTLMv1) を使用できなくなります。 これらのプロトコルを使用するために資格情報の入力が強制され、後で使用するために資格情報を保存することはできません。

MS-CHAPv2 に基づく WiFi エンドポイントと VPN エンドポイントを使用している場合、NTLMv1 と同様の攻撃を受けます。

WiFi と VPN 接続の場合は、MSCHAPv2 ベースの接続 (PEAP-MSCHAPv2 や EAP-MSCHAPv2 など) から証明書ベースの認証 (PEAP-TLS や EAP-TLS など) に移行することをお勧めします。
-------
引用元：https://learn.microsoft.com/ja-jp/windows/security/identity-protection/credential-guard/considerations-known-issues

Credential Guardが有効な場合、PEAP認証では何が起きるか？

実際の動作を確認するため、WindowsServer2019とWindows11搭載ノートPCを用意しActiveDirectoryを構成、意図的にGPOでCredential Guardを有効にした状態でPEAP(EAP-MSCHAPv2)を行い、挙動を確認してみます。

図1.検証構成

端末でCredential Guardが有効なことを確認するのは、システム情報(msinfo32.exe)を用いることで可能です。
仮想化ベースのセキュリティ実行中サービスとしてCredential Guardが記載されている場合は、Credential Guardが動作しています。

図2.Credential Guardが有効なことを確認

この状態でPEAPとして無線LAN接続を行うと、以下のような現象が発生します

• ID/パスワードを入力して接続自体は可能(接続毎に入力しなければならず、ユーザID/パスワードの保存が行えない)
• WindowsアカウントのログインID/パスワードを利用する場合でも、都度の入力が必須（Windowsログオン時の情報を利用したシングルサインオンができない)

これはCredentail Guardの「NTLM資格情報/シークレットの保護」が働いているためであり、注意事項にあるように「これらのプロトコルを使用するために資格情報の入力が強制され、後で使用するために資格情報を保存することはできません。」という考慮事項にあるような動作となっていることが確認できます。

今後PEAPを使い続けるべきか？移行するべきか？

PEAP-MSCHAPv2を使い続ける場合

現時点では明示的に無効化することを構成することによりPEAPを使い続けることが可能です。
ですが、今後Credential Guardをドメインで有効にするとなった場合や、強制的に有効化されるタイミングが到来した場合、ユーザは毎回の無線LAN接続時および再認証時に必ずユーザID/Passを要求されることになるため、ネットワーク接続時のユーザビリティは間違いなく悪化することになります。
特に無線LAN環境で利用する場合、ローミングが発生した場合RF環境や様々な要因によりフルでの再認証が発生するケースがあり、その度にユーザは認証情報を入力する必要が発生します。
ローミングはPCを動かさなくても発生する場合があるため、利用ユーザから見ると「何もしていないのに突然無線LANが切断された」というような状況に見え、IT部門への問い合わせが多くなることが予測されます。

EAP-TTLS(CHAP)へ移行する

Credential Guardによって認証情報がキャッシュされないのがNTLM/MSCHAP(v2)プロトコルのため、TLSトンネル確立後に様々な認証プロトコルが使えるEAP-TTLSに変更し、TLSトンネル内のインナーメソッドにCHAPを使えば制限は回避できると思われます。
またEAP-TTLS(CHAP)はPEAPと同様、ユーザ側の認証情報にパスワードを用いる関係上、辞書攻撃に対して考慮を行う必要があります。
なおOSや認証サーバによってはEAP-TTLSは標準対応していない場合があるため、移行できるか(対応しているか)に関しての調査も必要です。

EAP-TLSへ移行する

移行に際しコストはかかってしまいますが、オススメなのがEAP-TLSへの移行です。
EAP-TLSではクライアント側にも個別の証明書を使用し(コンピュータ証明書、ユーザ証明書)、ユーザの手動での認証情報の入力操作なしに認証を行うことが可能です。
PEAPやEAP-TTLS等のパスワード使用時に考慮しなければいけない辞書攻撃への考慮も不要となります。
しかしながらEAP-TLSでは「クライアントに対して個別の証明書を発行する」点もそのままデメリットとなります。
証明書の発行対応、運用(失効、更新管理)対応等が併せて必要となる点に注意が必要です。
なお、稀にクライアント側の証明書を共通の1通の証明書として使用しようとする方がいますが、証明書本来の使い方とは異なるためこのような取り扱いはご法度です。

※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。