本記事はマイクロソフト社員によって公開されております。
こんにちは。Windows Commercial Support Directory Services チームです。
2026 年 1 月の Windows 更新プログラム以降、Kerberos 認証で利用されている RC4 などのレガシー暗号を段階的に無効化する変更が始まりました。
KB5073381: CVE-2026-20833 に関連するサービス アカウント チケット発行の変更に対する RC4 の Kerberos KDC 使用量を管理する方法
これは、CVE‑2026‑20833 として報告された脆弱性への対処の一環であり、
最終的に 2026 年 7 月までに必要な対応を完了しなければ、一部の認証がブロックされます。
本記事では、KB5073381 の内容をもとに
- いつ・何が変わるのか(タイムライン)
- いつまでに何をしておくべきか
- 対応しなかった場合にどのような影響が出るのか
を、できるだけ分かりやすく整理してご紹介します。
CVE‑2026‑20833 について
2026 年 1 月 13 日以降にリリースされた Windows 更新プログラムには、Kerberos 認証プロトコルによる脆弱性への保護が含まれております。
RC4 などの脆弱またはレガシー暗号化の種類のサービス チケットを取得し、オフライン攻撃を実行してサービス アカウントのパスワードを回復できる可能性がある情報漏えいの脆弱性に対処します。
本脆弱性への対処のため、ドメイン コントローラー上の Kerberos Key Distribution Center (KDC) が、 既定で RC4 を使わないようにする 方向で変更が行われます。
具体的には、TGS_REQ が行われた際に発行される、サービス チケットの既定の暗号方式に変更があります。

Kerberos 認証の流れ
参考: How the Kerberos Version 5 Authentication Protocol Works
レジストリへの設定を行う、もしくは 2026 年 7 月リリースの更新プログラム適用で対処が完了いたしますが、認証への影響を考慮して、段階的に対処が進められるようにフェーズが分かれており、監査イベントの追加や、ガイドラインが公開されております。
対処方法について詳細を以下におまとめいたします。
3 つのフェーズ(タイムライン)
本脆弱性への対応はフェーズが分かれており、以下のようなタイムラインとなっております。
ポイントとしては、2026 年 1 月 13 日 - 初期展開フェーズで記録されるようになる監査イベントログに対処できていない場合、2026 年 4 月 - 第 2 の展開フェーズにて RC4DefaultDisablementPhase の既定値が 2 となり、認証が拒否されるようになります。
明示的に RC4DefaultDisablementPhase = 1 とすることで、2026 年 4 月以降も引き続き認証が拒否されることなく動作させることが可能ですが、最終的には、2026 年 7 月 までに、監査イベントログに記録されている内容に対処する必要がございます。
2026 年 1 月 13 日 - 初期展開フェーズ
このフェーズでは以下の変更が実施されます。
- 監査イベントログの追加
- 今後のセキュリティ強化 (第 2 の展開フェーズ以降) によって影響の受ける可能性のあるクライアントの監査イベントログの出力
- RC4DefaultDisablementPhase レジストリ設定を実装。明示的に設定しない限りレジストリは存在せず、存在しない場合は既定で RC4DefaultDisablementPhase = 1 相当で動作します。
2026 年 4 月 - 第 2 の展開フェーズ
このフェーズでは以下の変更が実施されます。
- DefaultDomainSupportedEncTypes の既定値が 0x18 (AES のみ) に変更となります。これにより、明示的な msds-SupportedEncryptionTypes 属性が定義されていないアカウントでは、Kerberos のサービスチケットの暗号化方式に AES-SHA1 を利用するようになります。
- RC4DefaultDisablementPhase の既定値が変更となり、レジストリが明示的に存在しない場合は、既定でRC4DefaultDisablementPhase = 2 相当で動作します。 (明示的に設定を行えば引き続き RC4DefaultDisablementPhase = 1 で動作させることが可能です)
2026 年 7 月 - 適用フェーズ
このフェーズでは以下の変更が実施されます。
- RC4DefaultDisablementPhase の値にかかわらず、RC4DefaultDisablementPhase = 2 相当の動作に強制します。
※レジストリにて 明示的に値を設定した場合でも、動作に反映されません。
追加されたレジストリについて
本脆弱性への対応で追加された RC4DefaultDisablementPhase レジストリの設定箇所等の情報は以下となります。
1 | HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters |
2026 年 4 月までにやるべきこと
初期展開フェーズで記録されるようになる監査イベントログをもとに、以下のうち、いずれかの対処を実施する必要があります。
- AES への対応を行う
- RC4 を継続して利用する場合、認証先のサービス アカウントの msds-SupportedEncryptionTypes 属性に明示的に RC4 を含むような値を設定する。
もし何らかのご事情があり、 2026 年 4 月までに上記対応が間に合わなかったり、2026 年 4 月以降も監査を続ける場合、
2026 年 6 月 の更新プログラムまでは、明示的に RC4DefaultDisablementPhase = 1 とすることで引き続き初期展開フェーズでの動作が可能です。
ただし、2026 年 7 月には RC4DefaultDisablementPhase による動作の変更を受け付けなくなるため、最終的にはそれまでに上記のいずれかの対応が必要となります。
影響を受ける可能性がある環境
今回の脆弱性対応によって、DefaultDomainSupportedEncTypes を明示的に設定していない場合、サービス チケットの暗号方式が既定で AES-SHA1 に変更されます。
影響が発生する可能性が高いのは、Kerberos 認証の暗号方式で AES-SHA1 に対応していないサードパーティー製品や古い OS への認証、また、Windows OS 上で動作するサードパーティー製品となります。
「2026 年 4 月までにやるべきこと」に記載の内容が実施できていない場合、RC4DefaultDisablementPhase = 2 の動作になると、認証失敗といった事象が発生する可能性があります。
具体的な対応ステップ
対処手順の具体的なステップについて、記載します。
1. 更新プログラムを適用する
まずは、2026 年 1 月 13 日以降にリリースされた更新プログラムを、すべてのドメイン コントローラーに適用します。これにより、RC4DefaultDisablementPhase の仕組みと監査イベントが利用できるようになります。
2. 監査イベントを確認し、影響範囲を把握する
次に、ドメイン コントローラーの システム イベントログ から、以下のイベント ID を確認します。
- 警告:201 / 202 / 206 / 207
※RC4DefaultDisablementPhase = 2 の動作では、これらの警告イベントはそれぞれ 203 / 204 / 208 / 209 のエラーイベントとなり、認証がブロックされるようになります。
それぞれの監査イベントログは、次の場合に記録されます。
- ID 201 / 206 の場合
認証元となったクライアント側が AES に対応していない、または AES が無効化されている。 - ID 202 / 207 の場合
認証先となったサービス アカウント側で Kerberos 認証で使用可能な AES のキーが存在しない(RC4 のキーのみが存在する) 。
上記イベントログの記録内容をもとに、3-(a) または 3-(b) のいずれかの対応を実施します。
3-(a). AES への移行
基本方針としては AES への移行 を推奨します。記録されている監査イベントログに応じて、それぞれ以下のように対処をご検討ください。監査イベントログの記載内容については、後述の記録される監査イベントログについてにサンプルを記載しておりますので、ご参考になれば幸いです。
ID 201 / 206 の場合
認証元となったクライアント側での対処が必要です。
クライアントで対処が必要
イベントログに記載の「ネットワーク情報: 」に、要求元クライアントの IP アドレスが記録されるため、記載された IP アドレスのクライアントをご確認ください。
※イベントログの例の抜粋
1 | ネットワーク情報: |
対処策について、現在サポートされている Windows OS では、既定で AES の暗号方式に対応しておりますので、通常記録されることは想定されません。
対象のクライアントがサードパーティー製品の場合には、恐れ入りますが対応方法について、対象製品のベンダー様にご確認ください。
もしサポートされている Windows OS で記録がされる場合、要求元のクライアント端末に以下のポリシー設定が行われている可能性があります。もし明示的に設定があり、その中に AES の設定が無い場合は AES も許可されるよう設定を更新ください。
1 | パス:[コンピュータの構成] - [ポリシー] - [Windows の設定] - [セキュリティの設定] - [ローカル ポリシー] - [セキュリティ オプション] |
以下が含まれるようにチェックを入れます。
AES128_HMAC_SHA1
AES256_HMAC_SHA1
ID 202 / 207 の場合
認証先となったサービス アカウント側での対処が必要です。
ドメイン コントローラー上で管理しているサービス アカウントと、対象のサービス アカウントで動作している製品で対処が必要
イベントログ内の「サービス情報: 」に記載の認証先アカウントのパスワード更新することで、ドメイン コントローラーが自動的に AES に対応したキーを生成するため、認証先アカウントのパスワードリセットやパスワード変更を実施ください。
認証先となったサービス アカウントは、イベントログに記載の「サービス情報: 」に、認証先のアカウントの情報が記録されますので、記載されたアカウントの用途をご確認ください。
※イベントログの例の抜粋
1 | サービス情報: |
サービス アカウントのパスワード変更方法は、アカウントを使用している製品ごとに用意されていることがありますので、ご利用のアカウントがどのようなサービスで利用されているのかご確認の上、サービスごとに確認することをご検討ください。
もし、ドメイン コントローラー側でパスワードリセットを行った場合、サービス側が保持しているパスワードとドメインコントローラー上で保持しているパスワードが不一致となってしまうため、
リセット後のパスワードで、サービス アカウントの再設定が必要となります。こちらも設定方法について、ご利用のサービスごとにご確認ください。
対象のサービス アカウントを利用しているサービスがサードパーティー製品の場合には、各ベンダー様にご確認ください。
3-(b). RC4 を継続利用する場合
AES への移行が難しいなど、RC4 を継続利用する必要がある場合は、認証先となった「サービス情報: 」に記載のサービス アカウントの msds-SupportedEncryptionTypes に、RC4 を含む値(例:0x1C)を明示的に設定ください。ID 201 / 202 / 206 / 207 とも共通で、こちらの設定を実施すると監査イベントログの記録が解消可能です。
ドメイン コントローラーが管理しているサービス アカウント オブジェクトの属性値に設定が必要
■ GUI からの設定方法
- Active Directory ユーザーとコンピューターを開きます。
- 上部タブの「表示」を選択後、拡張機能を有効にします。
- 該当のサービス アカウントのプロパティを開きます。
- 「属性エディター」タブ - msDS-SupportedEncryptionTypes をRC4 を含むように (0x1C など) に編集します。
■ 有効化方法 (CUI)
例としてユーザーアカウントにセットする場合を記載します。
- 管理者権限で PowerShell を起動します。
- 次のコマンドを実行し、msDS-SupportedEncryptionTypes に RC4 を含むように設定します。
1
Set-ADUser -Identity "<対象名>" -Replace @{'msDS-SupportedEncryptionTypes'= 0x1C }
※ <対象名> の部分には、設定対象となるユーザー名を入力ください。
※ コンピューターアカウントに対して実行する場合は、Set-ADComputer コマンドをご利用ください。
msds-SupportedEncryptionTypesに設定できる値については、後述の FAQ にある「msds-SupportedEncryptionTypes とは何ですか」に記載のリンクをご参照ください。
0x1C という値は 0x4 (RC4-HMAC)、0x8 (AES128-CTS-HMAC-SHA1-96)、0x10 (AES256-CTS-HMAC-SHA1-96) の値の足し算となっており、AES と RC4 を含む値となります。

RC4 を含む msds-SupportedEncryptionTypes の設定例
4. RC4DefaultDisablementPhase の設定
3-(a) または 3-(b) の対応を行い、「2. 監査イベントを確認し、影響範囲を把握する」で確認した監査イベントログ ID 201 / 202 / 206 / 207 の記録が無くなったことを確認したら、RC4DefaultDisablementPhase = 2 に設定します。設定後は OS の再起動、または KDC サービスの再起動が必要です。
必要な対応としては以上となります。
まとめ
今回の脆弱性対応による変更は、ドメイン コントローラーが既定で RC4 を使わないようにするという変更となりますが、裏を返すと「RC4 を継続して利用するのであれば、明示的に設定しなければならない」という変更になります。
CVE‑2026‑20833 への対応としては、監査イベントログの記録が無くなり、RC4DefaultDisablementPhase = 2 となれば完了ですので、
明示的に RC4 の設定さえすれば、対応完了後も引き続き RC4 による Kerberos 認証の利用は可能です。
お客様の選択によって、RC4 の継続利用も一つの対応となっております。
しかし、RC4 は現在安全でないと見なされており、段階的に廃止されていく動きとなっております。本脆弱性対応によって、RC4 の明示的な有効化を選択された場合、どのアカウントで RC4 を利用されているのかが明確になった状況と存じますので、 RC4 の廃止に向けた対応を継続いただくことをご検討いただけますと幸いです。
また、本脆弱性対応によって監査イベントログが記録されなくなった後も、以下の公開情報に記載の手順で、RC4 の監視を継続することができます。ご参考になれば幸いです。
Kerberos での RC4 の使用状況を検出して修復する
FAQ
DefaultDomainSupportedEncTypes とは何ですか
CVE-2022-37966 対応で追加されたレジストリです。CVE-2022-37966 対応では、このレジストリの既定値が 0x27 となることで、既定で Kerberos 認証時におけるセッションキーで利用される暗号化方式が AES となりました。
今回の CVE‑2026‑20833 対応ではこの既定値が 0x18 へと変更になり、Kerberos 認証時におけるサービス チケットの暗号化方式も AES となります。アカウントに msds-SupportedEncryptionTypes が設定されていない場合の既定値となります。
// ご参考
KB5021131: CVE-2022-37966 に関連する Kerberos プロトコルの変更を管理する方法
CVE-2022-37966 への対応とその影響について
msds-SupportedEncryptionTypes とは何ですか
アカウントがサポートする暗号化の種類を示す、Active Directory 属性です。msds-SETと呼ばれることもあります。サポートされているバージョンの Windows OS では、Active Directory でそのコンピューター アカウントの msds-SupportedEncryptionTypes が自動的に設定されます。
ユーザーアカウントや gMSA アカウントなど他のアカウントでは、msds-SupportedEncryptionTypes に明示的な値は自動的には設定されません。設定できる値については以下の公開情報を参照ください。
2.2.7 Supported Encryption Types Bit Flags
その他ご参考:
2.481 Attribute msDS-SupportedEncryptionTypes
2026 年 7 月 - 適用フェーズ 以降も RC4 の継続利用は可能ですか
はい、今回の脆弱性対応で、「認証先のサービス アカウントの msds-SupportedEncryptionTypes 属性に明示的に RC4 を含むような値を設定」をし、RC4 の継続利用すること選択された場合は、引き続き RC4 を利用することが可能です。
また、DefaultDomainSupportedEncTypes の設定は、2026 年 7 月 - 適用フェーズ 以降もその機能は削除されませんので、明示的に RC4 を含む値に設定された場合もその値の通りに動作します。ただし、DefaultDomainSupportedEncTypes に RC4 などのレガシー暗号を含む場合、ID 205 の監査イベントログが OS 再起動や KDC サービス起動のたびに記録されます。
RC4 は現在安全でないと見なされており、段階的に廃止されていく動きとなっております。本脆弱性対応によって、RC4 の明示的な有効化を選択された場合も RC4 の廃止に向けた対応を継続いただくことをご検討ください。
klist コマンドでチケットの暗号方式が RC4 と確認できるのに、監査イベントログが記録されません。なぜですか
初期展開フェーズ(2026 年 1 月 13 日以降)では、msds-SupportedEncryptionTypes (msds-SET) が未設定のサービスアカウントが AES のキーを持っている場合に発生する、想定される動作です。
初期展開フェーズでは、DefaultDomainSupportedEncTypes の既定値は CVE-2022-37966 対応で設定された 0x27 のままです。この値には RC4 が含まれているため、msds-SET が設定されていないサービスアカウントに対して既定で RC4 が利用される場合があります。
ただし、クライアントが AES に対応しており、かつ該当のサービスアカウントが AES のキーも保持している場合、今回の脆弱性対応における監査イベントログ(ID 201 / 202 / 206 / 207)は記録されません。
今回の脆弱性対応における監査イベントログ(ID 201 / 202 / 206 / 207)が記録されていない場合は、
第 2 の展開フェーズ(2026 年 4 月)へ移行すると DefaultDomainSupportedEncTypes の既定値が 0x18(AES のみ)に変更され、msds-SET が未設定のサービスアカウントでも AES が使用されるようになり、引き続き影響を受けることはありません。
「Kerberos での RC4 の使用状況を検出して修復する」のイベントログで TicketEncryptionType に RC4 の記録があるのに、監査イベントログが記録されません。影響を受ける対象かどうかはどのように判断すればよいですか
Kerberos での RC4 の使用状況を検出して修復する に記載の ID 4768 / 4769 を参照して今回の脆弱性対応による影響を受けるアカウントかどうかを判断することは適切ではありません。影響を受けるアカウントかどうかの判断には、本記事に記載の監査イベントログ(ID 201 / 202 / 206 / 207)の記録を確認する必要があります。
今回の脆弱性対応で変化があるのは、既定でサービスチケットの暗号化方式に RC4 を使わないようにするという変更です。ID 4768 は TGT(Ticket Granting Ticket)の発行に関するイベントであり、サービスチケットの暗号化方式の変更とは直接関係がないため、本脆弱性対応の影響判断には利用できません。
ID 4769 はサービスチケットの要求に関するイベントですが、初期展開フェーズで msds-SET を明示的に設定していない場合、チケットの暗号方式に RC4 が利用されるのは想定される動作です(前述の FAQ 項目もご参照ください)。
監査イベントログ(ID 201 / 202 / 206 / 207)が記録されていないのであれば、今回の脆弱性対応で影響を受ける対象ではありません。
参考
記録される監査イベントログについて
記録されるイベントログのサンプルを以下に記載します。
RC4DefaultDisablementPhase = 1 の時に記録される監査イベントログ
■ ID 201
1 | ログの名前: System |
■ ID 202
1 | ログの名前: System |
■ ID 206
1 | ログの名前: System |
■ ID 207
1 | ログの名前: System |
RC4DefaultDisablementPhase = 2 の時に記録されるエラーイベントログ
■ ID 203
1 | ログの名前: System |
■ ID 204
1 | ログの名前: System |
■ ID 208
1 | ログの名前: System |
■ ID 209
1 | ログの名前: System |
DefaultDomainSupportedEncTypes に明示的な設定がある場合に記録されるイベントログ
DefaultDomainSupportedEncTypes に明示的に RC4 を含む脆弱性な暗号方式の値があると、ID 205 の監査イベントログが OS 再起動や KDC サービス起動のたびに記録されます。これは想定される動作であり、DefaultDomainSupportedEncTypes を削除するか、AES のみを含む値に設定する以外に解消策はありません。
■ ID 205
1 | ログの名前: System |
更新履歴
2026/02/03 記事の公開
2026/03/26 図、および FAQ の追記