2026年4月のWindowsセキュリティ更新プログラムを境に、Active Directory（AD）環境における Kerberos 認証の RC4 暗号化廃止が新たな段階へ進んだ。「今動いているから大丈夫」で放置してきた環境が、ひっそりと壊れ始めるタイミングが来ている。

RC4廃止フェーズ2とは何が変わるのか

Kerberos 認証で使われる暗号化方式として、長年 RC4-HMAC（ARCFOUR）が使われてきた。RC4 は 1990 年代に設計されたストリーム暗号であり、現代の基準では脆弱性が指摘され続けてきた。Microsoftは段階的に RC4 の使用を制限する方針を取っており、今回の更新はその「フェーズ2」にあたる。

フェーズ1（既往の更新） では、KDC（Key Distribution Center、つまりドメインコントローラー）が AES を優先するよう挙動が変更されていた。

フェーズ2（2026年4月更新） からは、アカウントに明示的な暗号化タイプの設定がない場合、AES-SHA1（AES256-CTS-HMAC-SHA1-96 または AES128-CTS-HMAC-SHA1-96）のチケットがデフォルトで発行されるようになる。RC4 でしか動かない古い設定やアプリケーションは、ここで初めて認証エラーとして顕在化する。

影響を受ける可能性のある構成

主に以下のケースで認証失敗が発生しうる。

msDS-SupportedEncryptionTypes 属性が未設定またはゼロのアカウント コンピューターアカウントやサービスアカウントを古い手順で作成・管理していた場合に多い。ADUCで確認可能だが、多くの組織では棚卸しができていない。

SPN（Service Principal Name）が登録されたサービスアカウント SQL Server の実行アカウント、IIS のアプリケーションプール、Jenkins などのCI/CDエージェントなどが該当しやすい。これらは昔のドキュメント通りに設定したまま何年も動き続けているケースが多い。

古い NAS・複合機・ネットワーク機器 AES をサポートしていないベンダー実装が残っていると、認証できなくなる。ファームウェアアップデートで対応できるものと、製品の寿命を迎えているものがある。

Kerberos を使う Linux/Unix ホスト MIT Kerberos や SSSD の設定で RC4 固定になっている場合は要確認。

確認・対応の手順

1. イベントログで RC4 使用状況を洗い出す ドメインコントローラーのセキュリティイベントログ（イベントID 4769）を確認し、Ticket Encryption Type: 0x17（RC4-HMAC）で認証しているアカウントを特定する。Microsoft が提供するスクリプトや、DefenderのAD監査機能も活用できる。

2. msDS-SupportedEncryptionTypes を明示的に設定する 対象アカウントに AES256（0x10）または AES128+AES256（0x18）を明示的に設定する。Set-ADUser や Set-ADComputer の -KerberosEncryptionType パラメーターで一括処理が可能。

3. 古い機器・ソフトウェアのファームウェア・設定を更新する ベンダーの対応状況を確認し、AES 非対応の機器はネットワーク分離や代替手段の検討が必要になる場合がある。

4. テスト環境で事前検証する 本番への適用前に、非本番のドメインコントローラーに更新プログラムを適用して動作確認することを強く推奨する。

実務への影響

大手企業ほどADの歴史が長く、誰も触れていないアカウントが無数に眠っている。特に以下の担当者は今週中に動き出すべきだ。

  • AD管理者: イベントログの確認を今すぐ実施する。RC4 使用が多い環境ほど影響範囲が広い
  • インフラエンジニア: SQL Server・IIS・CI/CD系のサービスアカウントの暗号化設定を確認する
  • セキュリティ担当者: RC4 の撲滅はゼロトラスト移行の前提条件。この機会に棚卸しを進める
  • ヘルプデスク: 4月更新適用後に「突然ログインできなくなった」報告が来る可能性がある。RC4 廃止を頭に入れてトリアージする

筆者の見解

正直に言えば、この変更は「遅すぎた」くらいだ。RC4 が脆弱とわかってから何年も経つのに、いまだ現役で動き続けているAD環境がいかに多いか。Microsoftが段階的に廃止を進めているのは正しいアプローチで、技術的には支持したい。

ただ、現場の運用側から見ると悩ましい面もある。「Windows Update: 数日様子を見る勇気も立派なセキュリティ判断」という考え方を持っているが、今回ばかりは逆に「早めに自分から動く」方が安全だ。更新プログラムが当たってから慌てて調べるのではなく、事前に RC4 使用状況を把握して潰しておく——そういうプロアクティブな対応が求められる。

セキュリティ強化の方向性は正しい。VPNやレガシー認証の残骸が企業ネットワークに散らばっている日本の大手エンタープライズにとって、このタイミングで棚卸しを進めることには意義がある。ゼロトラストへの移行を本気で考えるなら、認証基盤の整備は避けて通れない。RC4 廃止はその第一歩として、むしろ歓迎すべき変化だ。

「今動いているから大丈夫」——この言葉がどれだけ危険か、過去のトラブルが何度も証明してきた。今回もその例外ではない。

出典: この記事は Phase 2 of Kerberos RC4 hardening begins with the April 2026 Windows security update の内容をもとに、筆者の見解を加えて独自に執筆したものです。