RC4廃止で何が起きるのか ─ Active Directory運用者が今すぐ確認すべきポイント

2026年7月、それまで動いていた認証が静かに壊れる。

RC4廃止は単なる暗号の更新ではない。
一部のログインや業務処理が突然失敗する可能性がある。
Active Directory環境に潜む“見えていない依存関係”が表に出るタイミングだ。

■ 第1章：RC4廃止のスケジュールとMicrosoftの方針

RC4の廃止は、ある日突然行われるものではない。
Microsoft は、企業環境への影響を考慮し、段階的な移行を採用している。

この流れを正確に理解しておくことが、今回のテーマでは最も重要になる。

■ 段階的廃止の全体像

MicrosoftはRC4を即時無効化するのではなく、以下の3段階で排除する方針を取っている。

2026年1月：監査フェーズ（Audit Mode）
2026年4月：既定設定の変更（RC4のデフォルト無効化）
2026年7月：強制適用（RC4の事実上の終了）

このスケジュールは Microsoft Learn および公式技術コミュニティで公開されている（参考リンクは記事末尾参照）。

■ 2026年1月：監査フェーズ

この段階では、RC4はまだ利用可能である。

ただし挙動は変わる。

RC4使用時にログが出力される
管理者が依存関係を検出できるようになる

目的は明確だ。

「使っていることに気づかせる」

多くの環境では、RC4を意識的に使っているのではなく、
結果として使われている。

このフェーズは、その“見えていない依存”を可視化するためのものだ。

■ 2026年4月：既定無効化

ここが最初の分岐点になる。

RC4が既定の暗号スイートから外れる
フォールバックが機能しなくなる

これまでの環境では、

AESが使えなければRC4に落ちる

という挙動が暗黙的に存在していた。

しかしこの段階からは、

「RC4に逃げる」ことができなくなる

ここで初めて、実際の障害が発生し始める。

■ 2026年7月：強制適用

最終フェーズでは、RC4は実質的に使用不可となる。

監査モードは終了
強制モードに固定
明示的な設定を除きRC4は使用されない

ここまで来ると、もはや互換性の猶予はない。

「対応していないものは動かない」

■ なぜ段階的なのか

この慎重な進め方には理由がある。

Active Directoryは企業インフラの中核であり、
その認証方式の変更は直接業務停止につながる。

特に問題となるのは以下のような要素だ。

長期間運用されているサービスアカウント
更新されていない業務システム
古い仕様のまま稼働している機器

これらは管理下にあるようでいて、実際には“ブラックボックス化”しているケースが多い。

そのためMicrosoftは、

「いきなり止める」のではなく
「気づかせてから止める」

という戦略を取っている。

■ 本質的な意味

このスケジュールが示しているのは、単なる仕様変更ではない。

過去の互換性を前提とした設計からの脱却

である。

RC4は長年にわたり“互換性のために残されてきた暗号”だが、
今回の変更はそれを明確に終わらせるものだ。

■ まとめ

RC4廃止は突発的な変更ではない。
計画的に進められている移行プロセスである。

ただし重要なのは、

「時間はあるが、猶予ではない」

という点だ。

このスケジュールは“準備期間”であり、
対応しなければ最終的に確実に影響が出る。

いわゆる「KerberosにおけるRC4廃止の影響」は、単なる設定変更ではなく運用全体に波及する。

■ 第2章：なぜRC4は排除されるのか

RC4が廃止される理由は単純ではない。
「古いから」では説明にならない。

本質はここにある。

攻撃に使われる暗号だからだ

■ RC4の前提を整理する

RC4はもともと、

高速・軽量で扱いやすい暗号

として広く普及した。

特に企業環境では、

Kerberos認証
NTLMとの併用
レガシー互換性

といった理由で長く使われてきた。

■ 問題は「設計のクセ」

RC4は致命的に壊れているわけではない。
しかし、暗号として重要な性質に問題がある。
RC4は“現実の攻撃で使われている暗号”である

鍵ストリームに偏りがある
初期バイトに規則性がある
同一鍵の使い回しに弱い

これらは単体では致命傷ではないが、

条件が揃うと攻撃に転用できる

■ 転換点：攻撃手法の確立

RC4の評価を決定的に変えたのは、

“現実に使える攻撃”が成立したこと

■ Kerberoasting（代表例）

これはActive Directory環境では定番の侵害手法だ。

流れはシンプル：

サービスチケットを取得
チケットをオフラインで解析
パスワードを特定

ここで重要なのが、

RC4は解析しやすい

という点だ。

AESに比べて計算コストが低く、
現実的な時間で解読が可能になる。

■ ダウングレード攻撃

さらに厄介なのがこれ。

本来はAESが使える環境でも、

意図的にRC4へ落とす

ことができる。

つまり：

強い暗号が使える環境でも
弱い暗号を強制される

これがRC4の最大の問題

■ なぜMicrosoftが本気で切るのか

Microsoft がRC4排除を進める理由は明確だ。

Active Directory侵害の入口になっているから

実際の攻撃では、

初期侵入
権限昇格
横展開

この一連の流れの中で、

Kerberos + RC4 は頻繁に使われる

■ 「古い」ではなく「危険」

ここは誤解されやすい。

RC4は単に古いから排除されるのではない。

古いだけなら残される

しかし今回は違う。

攻撃の成功率を上げる要素になっている

■ 現場にとっての意味

この変更はセキュリティ強化というより、

“攻撃のショートカットを潰す”

という意味を持つ。

これまで攻撃者は、

RC4を利用して解析を高速化
弱い暗号に誘導

という手法を使ってきた。

それが通用しなくなる。

■ 一刀両断

RC4は、

「使える暗号」ではなく
「使われると危険な暗号」

に変わった。

■ まとめ

RC4廃止の理由は技術的な進化ではない。

攻撃側の進化に対する対抗措置

である。

そのため今回の変更は、

任意ではない
推奨でもない

必ず実施される前提のもの

になる。

■ 第3章：何が影響を受けるのか

RC4廃止の影響は、「古いOS」だけに出るわけではない。

むしろ問題になるのは、

今も普通に動いている環境

だ。

■ ① サービスアカウント（最重要）

最も影響が大きいのはここ。

長期間パスワード未変更
自動実行ジョブで使用
管理者も詳細を把握していない

こうしたアカウントは、

RC4前提で動いている可能性が高い

■ なぜ危険か

Kerberosでは、

パスワード変更時に暗号キーが更新される

つまり：

古いアカウント
→ AESキーを持っていない
→ RC4しか使えない

■ 現実のパターン

バックアップソフト
バッチ処理
連携サービス

“誰も触らないが止められない”

■ ② NAS・複合機・業務機器

ここは読者の想像通り。

古いNAS
コピー機
スキャン連携機器

■ 問題の本質

Kerberos実装が古い

AES未対応
RC4前提

■ 厄介な点

ファーム更新がない
ベンダーが消えている
設定変更不可

物理的に詰む可能性あり

■ ③ レガシー業務システム

古いERP
社内開発アプリ
古いミドルウェア

■ よくある状況

ソースコード不明
ベンダー保守終了
仕様書なし

“動いている理由が不明”

■ ④ 古いドメイン構成

ここは見落とされがち。

長年アップグレードだけ繰り返し
初期設計が古いまま

■ 典型例

古い暗号設定が残存
ポリシーが混在
不要な設定が蓄積

見た目は最新、中身は過去

■ ⑤ 見えていないRC4依存

これが一番厄介。

誰もRC4を使っている認識がない

■ なぜ起きるか

Kerberosは自動で暗号を選ぶ。

AESが使えない
→ RC4にフォールバック

■ 結果

表面上は正常
内部ではRC4使用

完全なサイレント依存

■ よくある誤解

ここで整理しておく。

■ 誤解

古いWindowsが危ない
サーバーOSが問題

実態

OSではない

“設定と運用履歴”が問題

■ 地雷ランキング

現場目線で並べるとこうなる。

1位
サービスアカウント（未更新）

2位
見えないRC4フォールバック

3位
古いNAS・機器

4位
レガシー業務システム

「古いサーバー」より
“忘れられた設定”の方が危険

■ 一刀両断

RC4問題の本質はこれ。

古い機器の問題ではない

“誰も把握していない依存関係の問題”

■ まとめ

影響を受けるのは特定の製品ではない。

“管理されていない部分”すべて

である。

そしてそれは、

ドキュメントに載っていない
担当者も知らない
しかし確実に存在する

だからこそ厄介

■ 第4章：実際に起きる障害

RC4廃止の影響は、派手に全停止するわけではない。

むしろ厄介なのは、

“普通に動いているように見えるのに壊れている”

という状態だ。

■ 代表的な症状

まずは現場で実際に起きるパターンを整理する。

■ ① ドメインログオン失敗

ログインできない
資格情報が正しいのに拒否される
ログオン遅延・タイムアウト

■ ② ファイル共有が使えない

SMBアクセス不可
ネットワークドライブが開けない
「アクセスが拒否されました」

■ ③ リモート接続障害

RDP接続不可
認証エラーで弾かれる

■ ④ サービス・バッチ処理停止

スケジュールタスク失敗
バックアップ停止
連携処理エラー

しかもこれ、

“全部同時に起きるとは限らない”

■ 一番厄介な特徴

ここがこの問題の本質。

■ 「一部だけ壊れる」

新しいPC → 正常
一部の端末 → NG
特定のサービスだけ → NG

完全停止ではない

部分障害

■ なぜ切り分けが難しいのか

通常のトラブルシュートでは、

ネットワーク
認証情報
サーバー状態

を疑う。

しかし今回の問題は違う。

■ 見た目

Ping通る
サーバー動いている
パスワード正しい

すべて正常に見える

■ 実際

暗号方式だけが不一致

これが最大の罠

■ よくある現場の流れ

リアルにこうなる。

「ログインできません」報告
ネットワーク確認 → 問題なし
パスワードリセット → 改善しない
サーバー再起動 → 無意味
原因不明で時間消費

最後に気づく

Kerberosの暗号だった

■ “突然死”に見える理由

RC4依存の怖さはここ。

■ これまで

AES使えない
→ 自動でRC4にフォールバック
→ 問題なし

■ これから

AES使えない
→ フォールバックしない
→ 認証失敗

挙動が変わるだけ

環境は変わっていない

だから現場では、

「昨日まで動いていたのに」

となる。

■ さらに厄介なケース

■ サービス単位で壊れる

ユーザーログイン → OK
バックアップ → NG

原因は同じでも、症状がバラバラ

■ 時間差で発生

ある日はOK
別の日にNG

チケット更新タイミングで発生

■ 一刀両断

RC4廃止の障害はこう定義できる。

ネットワークでもない
認証情報でもない

「暗号のミスマッチ」

■ まとめ

RC4廃止による障害は、

全停止ではない
分かりやすくもない
再現もしにくい

だから危険

そして最大の問題は、

気づくまでに時間がかかること

第5章：確認すべきポイント（実務）

ここからが本番。
RC4問題は「知っている」だけでは意味がない。

確認できるかどうかがすべて

msDS-SupportedEncryptionTypes を確認する

まず見るべきはこれ。

Active Directoryの各アカウントには、
使用可能な暗号方式が属性として定義されている。

msDS-SupportedEncryptionTypes

ここにAESが含まれているかを確認する。

見る対象

サービスアカウント
ユーザーアカウント（特に古いもの）
コンピュータアカウント

危険な状態

RC4のみ
値が未設定（古い環境でよくある）

この状態はそのまま“RC4依存”

パスワード最終更新日を確認する

Kerberosでは、パスワード変更時に暗号キーが生成される。

つまり：

古いパスワード = 古い暗号のまま

特に危険なアカウント

数年間パスワード未変更
自動実行用アカウント
管理対象外のサービス

AESキーを持っていない可能性が高い

イベントログでRC4使用を検出する

ここは“可視化”のポイント。

RC4は意識して使われていないことが多い。

ログで炙り出す

確認対象

Kerberos関連ログ
認証イベント

見るポイント

使用暗号方式
チケット発行時の挙動

“まだ使われているか”を事実で確認する

SPN（Service Principal Name）の棚卸し

SPNに紐づくアカウントは要注意。

よくある問題

古い設定のまま残っている
不要なSPNが残存
誰も管理していない

サービスアカウントとセットで確認する

レガシー機器の洗い出し

ここは避けて通れない。

対象

NAS
複合機
業務機器

確認ポイント

Kerberos対応状況
AES対応有無
ファーム更新可否

「動いているからOK」は通用しない

小さくテストする

いきなり本番はNG。

推奨手順

テストOUを作る
一部ユーザーで検証
RC4無効化の影響を確認

“壊れ方”を事前に見る

一刀両断

この章のポイントはこれ。

知識は不要
確認できるかどうかだけが重要

まとめ

RC4問題は、

技術的に難しい問題ではない
しかし見えにくい

だからログと属性で確認する

ここまでやれば、

“どこが危ないか”は見える

第6章：推奨対応（現実路線）

RC4廃止への対応は難しくない。
ただし順番を間違えると事故る。

やることはシンプル、順序がすべて

優先順位を決める

まず全部を一気に触ろうとしない。

影響の大きい順に潰す

最優先

サービスアカウント
SPNが紐づくアカウント

次点

ユーザーアカウント（古いもの）
コンピュータアカウント

後回しでもよい

一般ユーザー（最近ログインしている）

「止まると困る順」で考える

サービスアカウントの再設定

ここが最重要ポイント。

やること

パスワード変更
AESキー再生成

注意点

サービス停止の可能性あり
依存関係を確認する

いきなり変更しない
影響範囲を把握してから

AES有効化の確認

チェック内容

AES128 / AES256 が有効
RC4依存になっていない

msDS-SupportedEncryptionTypes を確認

レガシー機器の扱いを決める

ここは“割り切り”が必要。

選択肢

交換
ファーム更新
分離（別ネットワーク）

一番やってはいけない

放置

段階的にRC4を止める

いきなり本番で切るのは事故の元。

手順

監査ログ確認
テストOUで無効化
部分適用
全体適用

“壊れる場所”を先に知る

ロールバックを用意する

ここ、意外と重要。

準備

設定戻し手順
影響範囲の記録
変更履歴

事故った時に戻せるかどうか

よくある失敗

❌ いきなりGPOでRC4無効化

一発で業務停止

❌ サービスアカウントを無計画に変更

バッチ・連携が全滅

❌ ログを見ない

原因不明地獄

一刀両断

RC4対応はこれに尽きる。

「全部直す」ではない

「危ないところから潰す」

まとめ

やるべきことは少ない。

アカウント確認
パスワード更新
段階的テスト

ただし順番を間違えると事故る

第7章：Microsoftの立場と現実

RC4廃止は単なる技術判断ではない。
そこには、避けて通れない現実がある。

セキュリティと互換性の衝突

企業インフラにおいて、この2つは常に対立する。

セキュリティ側

RC4は攻撃に利用される
Kerberoastingの成功率を下げたい
ダウングレード攻撃を防ぎたい

今すぐ切りたい

互換性側

古い機器が現役で稼働
業務システムが更新できない
ベンダーサポート終了

切ると業務が止まる

この2つは両立しない。

なぜ段階的なのか

Microsoft が今回選んだのは、

段階的排除

理由

企業環境はすぐに変えられない
影響範囲が広すぎる
一斉停止は現実的でない

そのため、

まず気づかせる
次に既定を変える
最後に強制する

という流れになっている。

Microsoftの本音

表向きは「セキュリティ強化」だが、実際はもう一歩踏み込んでいる。

「これ以上は面倒見ない」

RC4は長年、互換性のために残されてきた。

古いシステムを守るため
移行を猶予するため

しかし、

攻撃リスクの増大
クラウド時代のセキュリティ要件

これらを踏まえると、

維持コストが限界を超えた

現場とのギャップ

ここが一番リアルな問題。

Microsoftの前提

管理されている環境
定期的な更新
設計が把握されている

現実の現場

誰も触らないシステム
仕様不明の連携
属人化した運用

このギャップがトラブルを生む

それでも止める理由

それでもMicrosoftはRC4を切る。

理由はシンプル。

残す方が危険だから

RC4はもはや、

安全な選択肢ではない
例外として許容されるものでもない

“存在するだけでリスク”

一刀両断

今回の流れを一言で言うとこうなる。

「互換性よりセキュリティが勝った」

そしてもう一歩踏み込むと、

「負債を先送りできなくなった」

まとめ

RC4廃止は、技術的な進化ではない。

運用の前提が変わった

これまでの世界：

動いていればOK

これからの世界：

安全でなければNG

この違いが、今回の変更の本質だ。

第8章：この問題の本質

ここまでRC4廃止について見てきたが、
この問題は暗号の話ではない。

運用の話だ

よくある理解

多くの場合、RC4廃止はこう捉えられる。

古い暗号が使えなくなる
セキュリティが強化される
一部の機器が影響を受ける

これは間違いではない。

しかし、本質ではない。

本当に起きていること

今回の変更で露わになるのはこれだ。

「なぜ動いているのか分からないもの」

企業システムには必ず存在する。

誰が作ったか分からない設定
なぜ残っているか分からないアカウント
触ると怖いから放置されている機能

これらは普段は問題にならない。

なぜなら、

互換性が吸収してくれていたから

RC4の役割

RC4は単なる暗号ではない。

“最後の受け皿”

AESが使えないときでも、

RC4がある
→ 動く

つまり、

問題を隠す役割を果たしていた

それがなくなる

今回の変更で何が起きるか。

隠れていた問題が表に出る

古いアカウント
古い設定
古い依存関係

全部見えるようになる

なぜ“突然壊れる”のか

環境は変わっていない。

変わるのはただ一つ。

「ごまかし」が効かなくなる

これまで：

動いていた理由
→ RC4が吸収

これから：

吸収しない
→ 失敗として現れる

だから突然壊れるように見える

問題の正体

ここまでを一文で言うとこうなる。

RC4廃止は暗号の問題ではない

“可視化されていなかった負債の顕在化”

現場にとっての意味

この変更が突きつけているのは、

「ちゃんと把握しているか？」

という問いだ。

どのアカウントが何に使われているか
どの機器がどの方式で認証しているか
どの設定がいつから存在しているか

分からなければ、それはリスク

一刀両断

RC4の廃止は、

「古い暗号を捨てる話」ではない

「見えていないものを放置するな」という話

まとめ

RC4は長年、

互換性を支える存在だった
問題を覆い隠す存在だった

そして今、それがなくなる。

残るのは“本当の構成”だけ

この変更は、単なるアップデートではない。

放置していたものは、全部バレる

参考情報

Microsoft Learn
https://learn.microsoft.com/windows-server/security/kerberos/detect-remediate-rc4-kerberos
KerberosにおけるRC4依存の検出と移行手順を解説した公式ドキュメント。 Microsoft Tech Community
https://techcommunity.microsoft.com/blog/askds/what-is-going-on-with-rc4-in-kerberos/4489365
RC4廃止の背景とKerberosへの影響を解説した技術ブログ。 Microsoft Tech Community（セキュリティ更新関連）
https://techcommunity.microsoft.com/discussions/microsoft-security/kerberos-and-the-end-of-rc4-protocol-hardening-and-preparing-for-cve-2026-20833/4502262
RC4廃止に関連するセキュリティ強化の詳細。 MIT Kerberos
https://web.mit.edu/kerberos/
Kerberosの仕様および暗号方式に関する公式情報。 CISA（米国サイバーセキュリティ機関）
https://www.cisa.gov
レガシー暗号排除や認証強化に関するガイドライン。

本記事は、各種公式ドキュメントおよび公開情報をもとに、
Active Directory 運用現場の観点から再構成したものである。