ドメインコントローラーにWindows Updateを当てたら、一部のサービスだけKerberos認証に失敗するようになった。ユーザーは普通にサインインできている。止まったのは、昔からある業務のWebアプリ、古いNAS、Azure Filesのファイル共有といった、決まったサービスだけ。しかも、やり直すとたまに通る。
2026年4月以降のWindows Updateをドメインコントローラーに当てた環境なら、まずRC4の既定無効化を疑ってください。この変更は2026年1月から3段階で進み、2026年7月の更新で、既定の動作を元に戻すための設定も読まれなくなりました（2026年10月時点）。
先に結論を書きます。
- 変わったのは、暗号化の種類が指定されていないサービスアカウントに、ドメインコントローラーがRC4のチケットを出さなくなったこと
- 直す場所は、ほとんどの場合ドメインコントローラーではなく、止まったサービスのアカウントか、その機器
- 順番は、イベントで見つける → パスワードを変えてAESの鍵を作る → どうしても無理なものだけアカウント単位で例外 → ドメインコントローラー全体を戻すのは最後の手段
この記事では、何が変わったのか、なぜユーザーではなくサービスが止まるのか、止まりやすい4つのパターン、ログでの見つけ方と直す順番を整理します。
何が変わったのか：3段階の日付
RC4は古い暗号方式で、Active DirectoryのKerberos認証では、チケットの暗号化に長く使われてきました。問題は、普通のドメインユーザーなら誰でも、SPN（サービスプリンシパル名）を持つアカウント宛てのサービスチケットを要求できることです。チケットはそのサービスアカウントのパスワードから作った鍵で暗号化されているので、手元に持ち帰って、オフラインでパスワードを総当たりできます。Microsoft Learn「Kerberos での RC4 の使用状況を検出して修復する」はこれをKerberoastingと呼び、RC4のままだとこの攻撃に使われうると説明しています。動画の3分6秒あたり（無料）では、この「チケットを持ち帰って鍵を当てに行く」流れを、なぜ暗号の強さが効くのかから話しています。
これを塞ぐ変更が、Microsoftのサポート記事「CVE-2026-20833 に関連するサービス アカウント チケット発行の変更に対する RC4 の Kerberos KDC 使用量を管理する方法」に沿って入りました。
| 更新 | ドメインコントローラーの動き |
|---|---|
| 2026年1月13日以降 | 既定の動作は変えない。RC4に頼っている要求があると、システムログに監査イベント（KDCSVC 201〜209）が出るようになる |
| 2026年4月14日以降 | 指定のないアカウントに対する既定をAESだけ（DefaultDomainSupportedEncTypes の既定値 0x18）に変える。レジストリ値 RC4DefaultDisablementPhase で、まだ元に戻せる |
| 2026年7月以降 | RC4DefaultDisablementPhase が読まれなくなり、元に戻す手段がなくなる |
動画の10分38秒あたり（無料）で、この3段階を1枚の図で追っています。毎月更新を当てていれば、1月に警告が出て、4月に変わって、困ったら戻して直す期間がありました。何か月も当てていなかったドメインコントローラーに、今まとめて当てると、警告も猶予も飛ばして7月の状態にいきなり入ります。 いま症状が出ているのは、たいていこのケースです。
ただし、RC4が完全に禁止されたわけではありません。 アカウントごと、またはドメインコントローラーごとに明示的に許可すれば、今でも使えます。動画の7分57秒あたり（無料）でも、まずこの誤解を解いています。逃げ道は残っていますが、それは置き換えが終わるまでの一時しのぎです。この点は後で書きます。
止まるのはユーザーではなく、サービスの側
「認証が通らない」と聞くと、ユーザーがサインインできなくなる場面を想像しがちです。しかし、この変更が直接変えたのはサービスチケットの発行です。動画の16分28秒あたり（無料）で強調しているとおり、影響が出るのはSPNを持つサービスの側です。
Kerberosでは、ユーザーはサインインしたときにTGT（チケットを得るためのチケット）を受け取り、ファイルサーバーやWebアプリに行くたびに、その行き先のSPN宛てのサービスチケットをドメインコントローラーからもらいます。サービスチケットは行き先のサービスアカウントの鍵で暗号化されます。だから、サービスアカウントにAESの鍵が無い、あるいはサービスがAESのチケットを読めない、という状態だと、そのサービスにだけ入れなくなります。
この「2種類のチケット」の流れは、こちらの動画の13分8秒あたり（無料）で、ファイルサーバーへのアクセスを例に図で説明しています。16分10秒あたり（無料）では、実際にクライアントで klist を実行し、手元にあるチケットと、その暗号化の種類が表示される画面が見られます。普段は気にしなくてよい欄ですが、今回の問題ではそこにRC4と出ているかどうかが手がかりになります。
共有フォルダに「一部のPCだけ」つながらないという症状全体の切り分けは、別の記事「ファイルサーバー・共有フォルダにアクセスできない原因と切り分け手順」で、名前解決から認証までの段階ごとに整理しています。この記事は、そのうち認証の段階で、RC4が原因だと見当がついた後の話です。
止まりやすい4つのパターン
1. 何年もパスワードを変えていないサービスアカウント
一番多いのがこれです。AESの鍵は、パスワードを設定したときに作られます。AESに対応する前に作られ、それ以来パスワードを変えていないアカウントには、RC4の鍵しかありません（前述のLearn「Kerberos での RC4 の使用状況を検出して修復する」による）。業務アプリ用に昔作ったサービスアカウントは、止まるのが怖くて誰もパスワードを変えていない、というのがよくある状況です。
このパターンでは、システムログにKDCSVCの202（監査期間中の警告）や204（ブロックした記録）が出ます。イベントの文面は「サービス アカウントには安全でないキーしかない」という趣旨です。
2. Windows以外の機器：NAS、アプライアンス、古いLinux
Kerberosを話せる古いNASやアプライアンスの中には、RC4しか扱えないものがあります。このとき、イベントは201（警告）や203（ブロック）になり、「クライアントが安全でない暗号化の種類しかサポートしていない」という趣旨の文面が出ます。
厄介なのは、このパターンはイベントに出ないことがある点です。サポート記事は、監査イベントはドメインコントローラーがAESのチケットを発行できないときにしか記録されず、イベントが出ていないことは、Windows以外の機器がAESのチケットを受け付けられることの保証にならないと注意しています。機器のほうがAESのチケットを受け取ったうえで読めずに失敗する場合、ドメインコントローラーから見れば正常に発行しただけだからです。動画の18分22秒あたり（無料）でも、非Windowsの機器は実機で確かめるしかないと話しています。
3. Azure Files（オンプレミスのAD DS認証）
Azure FilesをオンプレミスのActive Directoryで認証させている場合、ストレージアカウントはAD上のアカウント（コンピューターアカウントかサービス ログオン アカウント）として登録されています。Microsoft Learn「Azure Filesに影響する暗号化の変更のトラブルシューティング」によると、AES-256に対応したのはAzFilesHybridモジュールのv0.2.2からで、それより前に構成したストレージアカウントはRC4のままの可能性があります。マウントできなくなる前に、Update-AzStorageAccountAuthForAES256 でADのオブジェクトとストレージアカウントのKerberosキーを一度にAES-256へ切り替えるよう案内しています。
なぜAzureのストレージがADのアカウントを持つのか、ピンと来ないかもしれません。メンバー限定の回の11分22秒あたりから、Azure Filesの「ドメイン参加に相当すること」を管理者が代わりにやる場面、つまりストレージアカウントに対応するアカウントをADに作り、そこにAzure FilesのSPNを登録する構成を図で見せています。ストレージアカウントがADから見て「SPNを持つ1つのサービス」だと分かれば、今回の変更がそこに効く理由もそのまま見えます。文章で読むより、オンプレミスのファイルサーバーと横に並べた図を見るほうが早い部分です。
4. 昔入れたRC4の例外が、そのまま残っている
過去に古い機器のためにRC4を許可し、機器を入れ替えた後も設定だけ残っているケースです。アカウントの属性 msDS-SupportedEncryptionTypes にRC4のビットが立ったまま、パスワードも変えていない。ドメインコントローラーのレジストリに DefaultDomainSupportedEncTypes でRC4を含む値を入れたまま。後者が残っていると、KDCSVCの205が、KDCサービスが起動するたびに記録されます。サポート記事によると、205は警告のままエラーには変わりません。つまり、動いているから誰も気づかない種類の残骸です。動画の16分3秒あたり（無料）でも、一時的な対応のつもりで入れた設定がそのアカウントだけ問題を残す、という話をしています。
「たまに失敗する」はドメインコントローラーの混在を疑う
「やり直したら通った」「このフロアだとダメで、別の拠点だと通る」という再現しない症状は、更新済みと未更新のドメインコントローラーが混在しているときに起きます。クライアントは近くのサイトのドメインコントローラーからチケットをもらうので、どのドメインコントローラーに当たったかで結果が変わります。動画の20分38秒あたり（無料）で、この落とし穴を説明しています。
同じことは、ドメインコントローラーごとのレジストリ設定でも起きます。DefaultDomainSupportedEncTypes は設定したドメインコントローラーにしか効かないので、1台だけ値が違えば、その1台に当たったときだけ結果が変わります。一方、アカウントの msDS-SupportedEncryptionTypes はADの属性なので、全ドメインコントローラーに複製されます。動画の14分6秒あたり（無料）で、この2つの設定の効く範囲の違いを並べています。
見つけ方：ドメインコントローラーのログを、全台で見る
RC4に頼っている相手を探す場所は2つあります。
| どこを見るか | 何が分かるか |
|---|---|
システムログ、ソース Kdcsvc、イベントID 201〜209 |
今回の変更で止まる（止まった）要求。どのアカウント宛てで、どのクライアントからか、相手が対応している暗号の種類 |
| セキュリティログ、イベントID 4768（TGT）・4769（サービスチケット） | 実際に発行したチケットの暗号化の種類。RC4は 0x17 と記録される |
セキュリティログ側の各フィールドの読み方は、前述のLearn「Kerberos での RC4 の使用状況を検出して修復する」が表つきで解説しています。同じページで紹介されているMicrosoft公開のスクリプト Get-KerbEncryptionUsage.ps1 を使うと、-Encryption RC4 でRC4のチケットだけを一覧にできます。手でイベントを1件ずつ読むより、まずこれで全体の数をつかむのが早いです。
ここで、NTLMの棚卸しとの違いを押さえておくと迷いません。NTLMのバージョンを記録するイベント4624は、アクセスされたサーバー側にしか出ないので、全サーバーからログを集める必要がありました。メンバー限定の回の19分0秒あたりから、この「ドメインコントローラーを見ても分からない」問題と、Windowsイベント転送などで全台から集める方法を扱っています。Kerberosのチケットはドメインコントローラーが発行するので、今回はドメインコントローラーのログを見れば足ります。ただし、どのドメインコントローラーに要求が行くかは分からないので、全台を見ます。監査を有効にして、ログを長めに残すことも同じです。サービスによっては月に1回しか認証しないものもあるからです（動画の21分21秒あたり、無料）。
直す順番：AESに寄せる、例外は最小に
まず、パスワードを変えてAESの鍵を作る
パターン1なら、サービスアカウントのパスワードを変えます。これでAESの鍵ができます。注意したいのは、msDS-SupportedEncryptionTypes を書き換えても、鍵は作り直されないことです。属性でAESを許可しても、鍵が無ければAESのチケットは作れません。動画の15分23秒あたり（無料）でも、属性を変えた後にパスワードの変更が必要だと念を押しています。パスワードを変えれば、そのアカウントでサービスを動かしている側（サービスの設定、アプリの構成ファイル）も更新が要ります。変更作業として計画してください。
直したら、クライアントで古いチケットを捨てて取り直し、新しいチケットの暗号化の種類を確かめます。klist purge でチケットを消してからもう一度アクセスし、klist で見る、という流れです。メンバー限定の「診断コマンド16選」の回の10分36秒あたりから、この「一度捨てて取り直させて確かめる」使い方を実際の画面で見られます。チケットはしばらくキャッシュされるので、捨てずに確かめると、直したのに古いRC4のチケットを見て「まだダメだ」と判断してしまいます。
どうしてもAESにできないものだけ、アカウント単位で例外にする
置き換え中の古いNASのように、どうしてもRC4が要る相手だけは、そのサービスのアカウントの msDS-SupportedEncryptionTypes でRC4を明示的に許可します。サポート記事も、4月以降にRC4が必要な場合はこの方法を勧めています。
この属性はビットの足し算です。RC4が 0x4（4）、AES128が 0x8（8）、AES256が 0x10（16）。AESの2つだけなら 8+16=24（0x18）、RC4も足せば 4+8+16=28（0x1C）になります。ADの画面では10進数で表示されるので、「28」を見て意味が分からなければ2進数に戻して読みます。動画の23分17秒あたり（無料）でも、ビットの意味を理解してから足すよう話しています。
ドメインコントローラー全体でRC4を戻すのは、最後の手段
ドメインコントローラーのレジストリ DefaultDomainSupportedEncTypes にRC4を含む値を入れれば、指定のないアカウント全部にRC4が戻ります。Microsoft Learn「Kerberos プロトコルとキー配布センター (KDC) に関するレジストリ エントリ」は、RC4のチケットが必要なレガシアプリケーションがある場合の値として 0x24（RC4のチケットとAESのセッション キー）を挙げています。ただし、これは、指定のないアカウント全部を4月より前の状態に戻す操作です。入れるなら全ドメインコントローラーにそろえ（そろっていないと、前述の「たまに失敗する」が起きます）、置き換えの期限を決め、205のイベントを消すところまでを1つの計画にしてください。動画の23分41秒あたり（無料）で、これを最初の手段にしてはいけない理由を話しています。
Windows Updateを止めるのは、逆向きの対策
この種の障害の後で出てきがちなのが、「更新が勝手に当たって認証が止まった。だからドメインコントローラーの更新を止めよう」という再発防止策です。動画の25分43秒あたり（無料）でも、これは方向が逆だと指摘しています。
今回の変更は、毎月当てていれば、1月の警告、4月の切り替えと3か月ずつの猶予がありました。止まったのは、その猶予を使える状態になかったからです。更新を止めればRC4の弱さはそのまま残り、次の変更でまた同じことが起きます。代わりに用意すべきなのは、毎月当てる、ドメインコントローラーのシステムログの警告に気づける、Microsoftのサポート記事の日付表を追う、の3つです。今回のKDCSVCのイベントも、1月以降の更新を当てていれば、切り替わる前に出ていたはずです。
まとめ
- 2026年4月以降の更新で、ドメインコントローラーは指定のないアカウントにRC4のチケットを出さない。7月以降は既定を戻すレジストリ値も読まれない
- 止まるのはユーザーのサインインではなく、SPNを持つサービス。古いサービスアカウント、Windows以外の機器、Azure Files（AD DS認証）、昔のRC4の例外が典型
- 見るのは全ドメインコントローラーのシステムログ（Kdcsvc 201〜209）とセキュリティログ（4768・4769、RC4は
0x17）。Windows以外の機器はイベントに出ないことがあるので実機で試す - 直す順番は、パスワード変更でAESの鍵を作る → 無理なものだけアカウント単位で例外 → ドメインコントローラー全体を戻すのは最後。直した後は
klist purgeで取り直して確かめる - 再発防止は更新を止めることではなく、毎月当てて、警告に気づける状態にすること
