Microsoftは2026年7月のWindowsセキュリティ更新プログラムで、Active DirectoryドメインコントローラーがKerberos認証において脆弱な暗号方式RC4を許容する「Auditモード」を完全に廃止した。これにより、情報漏えいの脆弱性CVE-2026-20833への対応は最終段階である「強制適用フェーズ」に入り、サービスチケットの発行はAESベースの暗号化が事実上必須となる。

Auditモードとロールバック設定の消滅

Kerberos認証では、ドメインコントローラー上のKDC(Key Distribution Center)がサービスチケットを発行する際、伝統的にRC4-HMACとAES(128/256)の両方の暗号方式に対応してきた。しかしRC4はパスワードハッシュから直接鍵を導出する古い方式で、オフラインでの解析(いわゆるKerberoasting)に対する耐性が低い。

Microsoftはこの弱点を段階的に締め出すため、これまで「Auditモードでまず影響を可視化し、問題があればレジストリキー(RC4DefaultDisablementPhase)でロールバックできる」という猶予期間を設けてきた。今回の7月更新ではこのAuditモードとロールバック設定そのものが削除され、Enforcementモードのみが残る。RC4をどうしても使わざるを得ない場合は明示的な設定変更で維持できるが、その構成はCVE-2026-20833に対して脆弱なままになる。

影響を受けやすい環境

影響が出やすいのは、レガシーな業務アプリケーション、Windows以外のKerberos実装(Linux/Unix系サーバーやネットワーク機器、複合機など)で、RC4を明示的に指定しているケースだ。これまでAuditモードで警告が出ていても放置していた環境は、7月更新の適用と同時にサービスチケット要求が失敗し、認証エラーとして表面化する。

実務への影響

日本企業の多くは長年運用されてきたActive Directory環境に、更新が止まった古いアプライアンスや自社開発の基幹システムを抱えている。今回のように「猶予期間そのものがなくなる」変更は、こうした資産ほど直撃しやすい。

対応の勘所は3つ。まず、セキュリティイベントログのイベントID 4769(Kerberosサービスチケット要求)を確認し、Ticket Encryption Typeフィールドが0x17(RC4-HMAC)になっているアカウントを洗い出すこと。次に、それらのサービスアカウントやアプリケーションがAESに対応できるか個別に検証すること。最後に、本番環境へのパッチ適用前に、検証環境で非Windows実装との相互運用性を必ず確認することだ。ロールバックの逃げ道が消えた以上、事前検証の重要性は格段に上がっている。

筆者の見解

RC4の締め出しという方向性自体は、Windowsのセキュリティ強化施策の中でも一貫して正しい判断だと思う。Smart App Controlやカーネルドライバーの締め出しと同じで、地味だが効く改善だ。サービスアカウントという「人間ではないID(Non-Human Identity)」が、パスワード管理も棚卸しもされないまま何年も同じ暗号設定で動き続けているケースは、ゼロトラストの観点から見ても最大級のリスクだ。「今動いているから触らない」という発想が一番危ない、というのはSID重複問題などでも繰り返し学んできたはずの教訓のはずだ。

ただ、応援する立場から一つ苦言を呈するなら、Auditモードという猶予期間が長く続いたことが、逆に「そのうちまた延期されるだろう」という油断を組織側に生んでしまった面は否めない。せっかく何年もかけて移行期間を用意したのだから、棚卸しが済んでいないアカウントを事前に可視化し、管理者に直接アラートを送るような支援ツールをもっと手厚く用意してほしかった。正面から勝負できるだけの技術力と影響力を持っているのだから、移行の「最後の一押し」こそ丁寧にやってほしいところだ。

出典: この記事は Enforcement phase for Kerberos RC4 protections begins with the July 2026 Windows security update の内容をもとに、筆者の見解を加えて独自に執筆したものです。