Windows Kerberosに対する脆弱性CVE-2025-26647の続報

複数フェーズからなるADの脆弱性対策「CVE-2025-26647 (Kerberos 認証) の保護」 

という記事を書いていました。

先日続報がリリースされましたので、ご紹介します。

CVE-2025-26647 への対応とその影響について

が日本マイクロソフトのWindowsサポートチームよりリリースされています。この記事によると強制モードの開始日（更新プログラムのリリース日）が2025年10月14日で確定しています。

複数フェーズからなるADの脆弱性対策「CVE-2025-26647 (Kerberos 認証) の保護」 

に記載した通り、強制モードは下記のような状況になります。

このモードになると、ADドメインコントローラーが安全でない証明書を使用してKerberos認証要求を受け取った場合、イベント D 21 がログに記録され、要求が拒否されます。
またAllowNtAuthPolicyBypassレジストリキーに対するMicrosoft のサポートは中止されます。よって監査モードに戻すことはできません。

ということで、証明書認証をお使いの場合は、残り1か月で対応が必要になります。

CVE-2025-26647 (Kerberos 認証) の保護　はサポート情報でした。今回は日本マイクロソフトのWindowsサポートチームによる記事のため、すでにリリース済みの更新プログラムに対する不具合情報が記載されています。各々の不具合情報は、CVE-2025-26647 への対応とその影響について に詳細がございますのでご確認ください。下記では、その不具合情報が、すでに改善済みか否かを抜粋して記載いたします。

• 2025 年 4 月 8 日の更新プログラムに含まれている不具合は、2025 年 6 月 10 日の更新プログラムで改善済みとのこと。
• 2025 年 7 月 8 日の更新プログラムに含まれている不具合は、上記とは別とのことです。そのため、今後改善する見込みとのこと。
  ただし、6 月の更新プログラムを適用済みの状態で ID:45 が記録されていない状況であれば、ID:21 イベントによる実影響がないとも記載ありました。

複数フェーズからなるADの脆弱性対策「CVE-2025-26647 (Kerberos 認証) の保護」

CVE-2025-26647 (Kerberos 認証) の保護

上記は、2025年4月8日に公開されました。

本文に記載ありますが、本脆弱性は、3フェーズでADの脆弱性の対策が図られます。上記の内容をサマリして以下に記載します。

• 脆弱性の概要：NTAuth ストアに存在しない認証局（CA）から発行された証明書を使って Kerberos 認証が行われると、セキュリティ上のリスクが生じる可能性があります。
• 影響対象：altSecID 属性を使った証明書マッピングを行っているセキュリティプリンシパル。またADドメインコントローラーがこちらの影響を受けます。
• 対策の段階的導入：

1. 2025 年 4 月 8 日: 初期展開フェーズ – 監査モード
   初期展開フェーズ（監査モード）として、NTAuth チェックと監査ログ警告イベント（イベントID 45）が有効になります。このイベントID 45は、安全でない証明書を使用して Kerberos 認証要求を受信すると記録されます。
   この記録されたイベントを監視して、NTAuthストアに含まれていない影響を受ける証明機関を特定していくことも必要です。
2. 2025 年 7 月: 既定で適用されるフェーズ
   このフェーズ（モード）では、NTAuthストアのチェックが既定の動作となります。が、AllowNtAuthPolicyBypassレジストリキー設定を使用することで監査モードに戻すことも可能エス。
   ただしこのモードでは、セキュリティ更新プログラムを完全に無効にする機能は削除されます
3. 2025 年 10 月: 強制モード
   このモードになると、ADドメインコントローラーが安全でない証明書を使用してKerberos認証要求を受け取った場合、イベント D 21 がログに記録され、要求が拒否されます。
   またAllowNtAuthPolicyBypassレジストリキーに対するMicrosoft のサポートは中止されます。よって監査モードに戻すことはできません。

物理サーバーでWindows Server 2025へのインプレースアップグレードを試す

Windows Server 2025がGAしたようですね。

と

どうやら互換性の問題なのか、Windows Server 2025に最新の累積更新プログラムを適用すると起動失敗する模様

の続き。

もう一つ物理サーバーがありましたので、そちらでWindows Server 2025へのインプレースアップグレードを試してみました。最初に結論を書いておくと、HWメーカーのサポートはないと思いますが、Windows Server 2025へのインプレースアップグレードはPowerEdge T320でできました。

アウトバウンドコントローラー経由からの画面ショットにて、一連の流れを載せておきます。インプレース元のOSバージョンは、Windows Server 2022です。

USBメモリに配置したsetup.exeを起動します。ウィザード起動しました。

「インストールの向上」にチェックを入れて先に進めます。

プロダクトキーを入力し、先に進めます。

「デスクトップエクスペリエンス」を選択し、先に進めます。

「ライセンス条項」に同意し、先に進めます。

引き継ぐ項目として、「ファイル、設定、アプリを保持する」を選択し、先に進めます。

準備完了しましたので、「インストール」をクリックして、インストール開始します。

インストール中。

ここから複数回再起動しました。

小一時間程経過後、インストール完了しました。

インプレースアップグレードできたことを確認しました。

当方の環境だけなのか、アクティベーションがうまくいっていない様子。

bing copilotに聞いてみまして、

ソフトウェア保護サービスを再起動してみました。がそれでは解消せず。

プロダクトキーのトラブルシューティングを実行したところ、アクティベーションが復旧しました。

以上

どうやら互換性の問題なのか、Windows Server 2025に最新の累積更新プログラムを適用すると起動失敗する模様

タイトルにも書いたのですが、Windows Server 2022どまりとなった物理サーバーが出ました。ML110G7という古い機器ですが逆に度重なるOSアップグレードに対して、よくぞここまで持ってくれたと言えますね。
※特定機器を誹謗中傷する意図は無いことを明言しておきます。上記でも書いた通り、ここまで良く持ってくれたなと感謝してます。

Windows Server 2025のインストール後に10月の累積更新プログラムを適用していました。その時は、起動していたと思ったのですが、2週間ほど間を空いたのちに起動させてみると、赤い画面で起動せず。

BIOSバージョンは、2019/04/04が最新版のようでした。

起動メディアから修復を試みました。

が如何ともし難いので再びクリーンインストールしました。

今度は、11月の累積更新プログラムを適用して、再起動しました。結果は下記の通りです。

ここまで連続して通電していたので、BIOSの日付がズレた可能性も低いと思います。

これ以上の探求は諦めて、Windows Server 2022を入れ直しました！

2024年4月のセキュリティ更新プログラムで、既知の問題が2つ出ています。

おもにWindows Server 2022に影響ありますが、

2024 年 4 月 9 日 — KB5036909 (OS ビルド 20348.2402)

で、下記の通り既知の問題が2つ出ています。文面を引用します。

1. 2024 年 4 月のセキュリティ更新プログラムをインストールした後の NTLM トラフィックの問題
   ドメイン コントローラー (DC) に 2024 年 4 月のセキュリティ更新プログラム (KB5036909) をインストールすると、 NTLM 認証トラフィックが大幅に増加する可能性があります。 この問題は、環境内のプライマリ ドメイン コントローラーの割合が非常に少なく、NTLM トラフィックが多い組織に影響を与える可能性があります。
   次の手順: 解決に取り組んでおり、今後のリリースで更新プログラムを提供します。
   影響を受けるプラットフォーム:
1. クライアント: なし
2. サーバー: Windows Server 2022、Windows Server 2019、Windows Server 2016、Windows Server 2012 R2、Windows Server 2012、Windows Server 2008 R2、Windows Server 2008
2. 2024 年 4 月のセキュリティ更新プログラムをインストールした後、VPN 接続が失敗する可能性があります
   Windows デバイスは、2024 年 4 月のセキュリティ更新プログラム (KB5036909) または 2024 年 4 月のセキュリティ以外のプレビュー更新プログラム をインストールした後、VPN 接続エラーに直面する可能性があります。
   次の手順: 解決に取り組んでおり、今後のリリースで更新プログラムを提供します。
   影響を受けるプラットフォーム:
1. クライアント: Windows 11バージョン 23H2;Windows 11、バージョン 22H2、Windows 11、バージョン 21H2、Windows 10、バージョン 22H2、Windows 10、バージョン 21H2。
2. サーバー: Windows Server 2022、Windows Server 2019、Windows Server 2016、Windows Server 2012 R2、Windows Server 2012、Windows Server 2008 R2、Windows Server 2008。

いずれにしても、今後の定例なのか、定例外で対応が図られそうですね。

Windows Server 2022でKB5034439が適用できない事象に遭遇しました その2 WinREのパーティションを拡張するスクリプトを試した

Windows RE のパーティションを拡張する

と言うスクリプトがリリースされたのを聞いたので、確認しました。

結果としては、WinREのパーティションを拡張できます。しかしながら、下記の点を留意した方が良いですね。

• PowerShellの実行ポリシーを一時的に変えておくのが定石です。
• あらかじめ作成しておくとの記載があるバックアップフォルダーは、作成不要だった。理由は以降に記載します。
  
• 絶対パスが機能しない模様で、相対パス指定だった。
  

  

  
• "で囲むのも機能しない模様です。
  
• 相対パス指定した結果、スクリプトの実行フォルダー配下にバックアップフォルダーが作成された。
  

では、実際の流れを見ていきます。

念の為、KB5034439が適用できない事象が起きていることを確認します。

WinREのパーティションを拡張するスクリプトを実行します。

なぜか直後は、Windows UpdateでKB5034439が適用できない事象が再発してました。

他の更新プログラムもあったので再起動しました。

Windows UpdateでKB5034439をインストールしています。

KB5034439の適用が成功しました。

Azure VMなWindows Server 2022でKB5034439が適用できない事象に遭遇しました

当方の手元で使っている環境でも発生していました。ということで、適用できない事象の画面を貼ります。

このケースの場合、回復パーティションが前方にあります。

回復パーティションを拡張しようとするとCドライブのパーティションを削除することとなり、本末転倒な事態へ陥ります。

つまり、

KB5028997: WinRE 更新プログラムをインストールするためにパーティションのサイズを手動で変更する手順

による拡張はできません。。。

Azure VMなWindows Server 2022については、小澤氏による詳細な解説記事がすでにあります。こちらを参考にしてください。 

Windows Server で KB5034439 の適用がエラーとなった場合の対応

上記にも書かれている通り、このケースに関しては無視するか、抜本的な対応が無いとどうにもなりませんね。

Windows Server 2022でKB5034439が適用できない事象に遭遇しました

いくつかのOSで回復パーティションサイズを確認した。 

Windows 10向けの更新プログラム「KB5034441」が、Windows Update適用時に「0x80070643」エラーとなりました　解消しました！

の続き

KB5034439: Windows Server 2022 の Windows 回復環境更新プログラム: 2024 年 1 月 9 日

が適用できない事象が手元の環境でも発生しました。

KB5028997: WinRE 更新プログラムをインストールするためにパーティションのサイズを手動で変更する手順

に基づいて、回復パーティションを拡張するのですが、搭載メモリ量によって回復パーティションのサイズが違うことに気づきました。

搭載メモリが128GBの場合は、597MBとなる例

搭載メモリが192GBの場合は、612MBとなる例

KB5028997: WinRE 更新プログラムをインストールするためにパーティションのサイズを手動で変更する手順　に従い、回復パーティションを626MB（表示上は627MB）としました。

KB5034439: Windows Server 2022 の Windows 回復環境更新プログラム: 2024 年 1 月 9 日

を改めて適用してみました。
※本環境は、Hyper-Vフェールオーバークラスターであることから、クラスター対応更新を使用しました。なおKB50334439の適用は、再起動不要みたいです。　　

• 搭載メモリが128GBのサーバーにおいて、回復パーティションを626MB（表示上は627MB）としたケースは、KB50334439の適用成功を確認しました。下記"01"および"02"のサーバーは、搭載メモリが128GBのサーバーとなります。
• 搭載メモリが192GBのサーバーにおいて、回復パーティションを626MB（表示上は627MB）としたケースは、KB50334439の適用失敗を確認しました。クラスター対応更新での失敗結果を下記に添付します。下記"03"のサーバーは、搭載メモリが192GBのサーバーとなります。
  

ということで、搭載メモリが192GBのサーバーは、回復パーティションをさらに広げる必要有ということに。。。

では、どれくらい広げるのが良いのかという点については、

KB5028997: WinRE 更新プログラムをインストールするためにパーティションのサイズを手動で変更する手順　に書かれている250MBを採用しました。回復パーティションを再拡張した画面ショットは、下記のとおりです。

改めてクラスター対応更新を実行しました。

まず更新プログラムのプレビューを行ったところ、該当のサーバーのみKB50334439が適用可能です。

状況確認できましたので、クラスター対応更新を実行しました。今度は成功しましたね。

"03"のサーバー上で回復パーティションを再拡張後、本日2回目の適用は成功しました。

以上のことから、サーバーの搭載メモリ上に応じて、回復パーティションのサイズ変更を試行錯誤する可能性があると認識しました。

いくつかのOSで回復パーティションサイズを確認した。

Windows 10向けの更新プログラム「KB5034441」が、Windows Update適用時に「0x80070643」エラーとなりました　解消しました！

にて回復パーティションのサイズが重要だとわかりました。また、ITライターの山内氏より下記記事がある旨、ご連絡いただきました。

Windows 10／11で「2024年1月の更新プログラム」のインストールが失敗（エラー0x80070643）！　その原因は？

ご連絡いただいた際、下記の情報を連携いただいたこと、申し添えます。上記記事含め、改めて御礼申し上げます。

• UEFIパーティション要件を鑑みると、最終的に空き52MB+5～15MBのあきがあれば成功するはずだろう。
• Windows 22H2以前なら+50MBくらいで成功すると思います。Windowsセットアップの既定だと確か83MBくらいの空きで回復パーティションを作る故。

いろいろ情報を教えていただきました。GUIかdiskpartのいずれかで、Windows Server系の回復パーティションの配置やサイズをメモしておきます。

Windows Serve 2016

450MBで先頭に配置されているサーバーがありました。

Windows Serve 2019

全3台で確認したところ、499MBで先頭に配置されているサーバーがありました。
※全3台ともOSインストール時に、手動でパーティション作成していません。おそらくこれはパターンの一つでしょうかね。

Windows Serve 2022

597MBの回復パーティションが一番後ろにあります。

Azure Stack HCI OS 22H2

515MBの回復パーティションが一番後ろにあります。

Azure Arcのオンボードとプロキシサーバー

プロキシーサーバーの配下だとAzure Arc Setupは、インストールに失敗します。

本稿執筆時点のAzure Arc Setupは、構成ボタンが使用不可なんですね。

いずれここに、プロキシーサーバーの設定ができるのではないか、と踏んでいるのですけど。

なぜこんなことに気づいたのかといえば、Azure Arcのオンボードスクリプト生成時にプロキシサーバーを指定するようになっていたからです。さらに書くとプロキシサーバーをPowerShellの$env:HTTPS_PROXY環境変数に設定しておいても、Azure Arcのオンボードスクリプトでは参照しないからでした。
※この挙動に気づくまで数時間ほど無駄にしました。。。

Azure Arcのオンボードスクリプト生成時にプロキシサーバーを指定する画面は、下記の通り。ちなみにプライベートエンドポイントもここで指定できますね。

Azure Arcのオンボードスクリプト内にプロキシーサーバーの情報が記載されていますので、赤枠で囲ってみました。プロキシサーバーの設定がオンボードスクリプト内にコーディングされています。

ということで、Azure Arcのオンボード時は、引き続き注意しながら進めます。