hgot07 Hotspot Blog

主に無線LANや認証連携などの技術についてまとめるブログです。ネコは見る専。

Windows 11 Enterprise 22H2で無線LANの認証が通らなくなる問題

Windows 11 Enterprise に 22H2 アップデートを適用すると無線LANの WPA2/WPA3 Enterprise で認証が通らなくなるという問題が見つかったようです

これにより、eduroamやOpenRoamingなども影響を受けました。
(おい、教育・研究の現場が影響を受けたぞ、なんてことをしてくれたんだ!)

なお、確実に影響が見られたのは Enterprise 版とされており、Proについてはまだ情報収集中のようです。しかし、Microsoft の動きから見て、近い将来に同じ問題にぶつかる可能性があるので、準備しておいた方がよさそうです。

 

状況

最近、Windows 11に22H2アップデートが降ってきましたが、Enterprise版に22H2を適用すると、WPA2/WPA3 Enterpriseの一部の認証方式で認証が失敗する現象が見られました。もう現場は大騒ぎさ~!_(゚。3」∠)_

私が出入りしているeduroamのコミュニティで早々に話題になり、その後にtwitterやWireless Broadband Alliance (WBA)でも話題になりました (しました)。

当初、eduroamのプロ()でも原因究明に手間取っていましたが、どうやら二つの独立した原因があったことが、調査によって見えてきました。以下のとおりです。

  • デフォルトで TLS 1.3 を使うように変更された。RADIUSサーバのなかにTLS 1.3の実装が不十分なものがあり、これが原因で認証に失敗するようになった。
    (なおFreeRADIUS 3.2.0以上は問題ないとされている。ただし、3.0.25以前はTLSに別の問題があるので、アップグレード必須)
  • Enterprise版でCredential Guardがデフォルトで有効化された。その結果、NTLMハッシュが使えなくなり、MSCHAPv2を使うEAP-TTLSやPEAPの認証に失敗するようになった。(主にAD利用者が影響を受けた)

eduroam方面の分析がこちら。

lists.geant.orghttps://lists.geant.org/sympa/arc/cat-users/2022-10/msg00040.html

 

Credential Guardって何? Microsoftの文書はこちら。

learn.microsoft.com

対策またはワークアラウンド

一つ目のTLS 1.3の問題については、以下の対策ないしワークアラウンドがあります。

  • TLS 1.3にきちんと対応したRADIUSサーバを使う。
  • TLS 1.3の実装が半端なRADIUSサーバでは、明示的にTLS 1.2を使うような設定を入れる。

 

二つ目のMSCHAPv2の問題については、以下のとおり。

  • Credential Guardを無効化する (!)
  • MSCHAPv2を使わない認証方式に移行する。

Microsoft自らが、Credential Guardの無効化をワークアラウンドとして示すのは、なんの冗談かなと。とりあえずやり方についてはこちら。

learn.microsoft.com

We have a problem!

MSCHAPv2がセキュリティ的に弱いことは2012年に注意喚起されています。

セキュリティ向上の観点で、MSCHAPv2をMicrosoft自身が排除しにかかったのは、正しい方向性でしょう。ただし、これでは EAP-TTLS (MSCHAPv2) や PEAP が死にます。「EAP-TTLS (PAP)なら大丈夫ですね」……ぇ

要するに、Microsoftはよりセキュアな、証明書ベースのEAP-TLSを使わせたい?

現場の無線LANの利用形態を考えると、必ずしもEAP-TLSが利用できるとは限りません。EAP-TLSで必要な電子証明書の扱いが、大学や事業者にとって必ずしも容易ではないという問題もあります。

EAP-TTLSやPEAPの特長の一つとして、他にネット接続手段がない状況でも、ID・パスワードの手入力で無線LANに接続できることが挙げられます。もちろん、手作業ではサーバ認証の設定が十分にできないという問題はあります。特に、PAP (Password Authentication Protocol)では、偽基地局に誘導された際にパスワードを先方に知らせてしまうことが大きな問題です。そのため、セキュリティ的に十分とは言えないにしても、セーフティネットとしてMSCHAPv2を使うのが、現在のベストプラクティスになっています。現場で要求されるセキュリティレベルに応じて手段を選択できることが重要で、代替策もない状況でいきなり止めるのは、問題ではないでしょうか

というわけで、MSCHAPv2 がある日突然使えなくなって、EAP-TLSへの移行がすぐにできないとなれば、何が起こるでしょう?

Unusable Securityとは何か

出典:  https://www.slideshare.net/Docker/dockercon-eu-day-1-general-session

EAP-TTLS (PAP)に逃げたら、こうなりますよねぇ。

ちなみに、EAP-TTLSはサーバ認証が前提の方式です。端末上でサーバ認証がきちんと設定されている限り、PAPでも安全性は保たれるはずです。

 

全くネット接続のない状況というのが最近は減ってきているので、既存のネットを利用して電子的にWi-Fi設定のためのプロファイルを流し込む web-based provisioning のような仕組みが、最近のWi-Fi業界では推奨されるようになっていますWindows 10とWindows 11では、ms-settings: URIスキームと呼ばれる仕組みを使って、ウェブからの設定ができるようになっています。この仕組みですが、執筆時点で EAP-TLS には非対応のようです (実機で確認済み)。

まって……

Microsoftさんは何がしたいんでしょうね……?

せめて十分前もってアナウンスが欲しかったです (愚痴)。

 

おしまい