2025年4月8日に米国マイクロソフト株式会社（Microsoft Corporation）が公開したPatch Tuesday向けアップデートを適用すると、Active Directoryドメインコントローラー（DC）上でWindows Hello Kerberos認証が正常に動作しなくなる問題が確認されました。本稿では障害発生の経緯から原因、影響範囲、回避策までを時系列に沿って解説します。
背景と経緯
マイクロソフトは毎月第2火曜日にWindows Server製品用のセキュリティ更新プログラムを公開しています。2025年4月8日には以下の更新がリリースされました：
- KB5055523: Windows Server 2025用セキュリティ更新
- KB5055526: Windows Server 2022用セキュリティ更新
- KB5055519: Windows Server 2019用セキュリティ更新
- KB5055521: Windows Server 2016用セキュリティ更新
同日にKerberos認証改善策を含むKB5057784の初期監査モード展開が開始され、権限昇格脆弱性（CVE-2025-26647）への対応が組み込まれました。
この適用後、Active Directoryドメインコントローラーが証明書ベースのKerberos認証を正しく処理できず、Windows Hello for Businessなどで認証エラーが発生しました。
2025年4月中旬には一部環境でイベントID 45やID 21のログ記録とログオン失敗が報告され、2025年5月7日にマイクロソフトが公式に問題を認め、Windows Health Dashboardで詳細を公開しました。
障害の内容
本問題は以下のKerberos機能に影響します：
- Kerberos Public Key Cryptography for Initial Authentication（PKINIT）
- Certificate based Service-for-User Delegation（S4U） via Kerberos Constrained Delegation（KCD/A2D2）
- Kerberos Resource-Based Constrained Delegation（RBKCD/A2DF）
これらを利用するWindows Hello for Business Key Trust環境、Machine PKINIT、スマートカード認証製品、サードパーティSSOソリューションで認証処理の失敗やログが過剰出力されます。
例えば、スマートカードを用いたRDP接続やOutlookの委任アクセス（オンビーハーフ）が失敗し、ユーザーと管理者が認証エラーに直面するケースが報告されています。
特にKey Trust環境では、デバイス公開鍵のキャッシュを保持するAD属性「msds-KeyCredentialLink」を介した認証処理が妨げられます。
影響範囲
対象はオンプレミスのActive Directoryドメインコントローラーですが、Azure AD Connect経由のハイブリッド環境やADフェデレーションサービス経由のクラウド認証連携にも副次的影響が出る恐れがあります。
主な症状は以下の通りです：
- AllowNtAuthPolicyBypass = 1：ID 45が大量記録されるがログオンは継続
- AllowNtAuthPolicyBypass = 2：ID 21記録後にスマートカードログオンが失敗
- 既定（値未設定）：DWORD値がない場合は内部的に「1」と同等に扱われる
さらに、Azure AD Connect経由で同期されたデバイスでも断続的なログオンエラーが発生する可能性があります。
ログ該当のDC以外でも関連イベントが相互運用テスト環境で確認されているため、影響範囲は広範です。
原因分析
KB5057784はCVE-2025-26647保護策として、証明書検証プロセスを強化し、DCが証明書チェーンをNTAuthストア登録ルートまで検証するように動作を変更しました。これにより、NTAuthストアにルート証明書が正しく登録されていない場合、証明書ベース認証が拒否されます。
msds-KeyCredentialLink属性は、デバイスごとの公開鍵情報を保持し、Key Trust環境では証明書ベースの認証を実現する要となります。本問題では、証明書チェーンがローカルのNTAuthストアに存在しない場合、KDCが証明書の信頼性を判断できずに認証を拒否します。
検証フローの大まかな流れ：
- クライアントがPKINITを開始
- DCが証明書のサーバーチェーンを解析
- NTAuthストアに該当ルートが存在するか確認
- AllowNtAuthPolicyBypassによって動作を制御
AllowNtAuthPolicyBypass値が未設定の場合、既定で「1」（監査モード）が適用され、NTAuthポリシーバイパスを許可します。
対象のレジストリパス：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc\AllowNtAuthPolicyBypass
回避策と対応手順
現行の作業手順は以下の通りです。事前にステージング環境で検証を行ってください。
- 管理者権限でレジストリエディタを起動
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdcに移動- DWORD値「AllowNtAuthPolicyBypass」を作成または編集し、「1」を設定
- コマンドプロンプトで
reg add HKLM\SYSTEM\CurrentControlSet\Services\Kdc /v AllowNtAuthPolicyBypass /t REG_DWORD /d 1 /fを実行 net stop kdc && net start kdcまたはサーバー再起動
なお、自動化ツールを利用している場合は、PowerShellで次のコマンドを実行して設定を反映させることができます：
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\Kdc' -Name AllowNtAuthPolicyBypass -Type DWord -Value 1「2」を設定するとログオン不可になるため、運用時は必ず「1」としてください。
大規模環境ではグループポリシーやPowerShellスクリプトで一括展開を検討し、反映後にドメイン全体でイベントログをモニタリングしてください。
まとめと今後の見通し
今回の障害は、セキュリティパッチ適用前後の証明書検証変更がKerberos認証フローに深刻な影響を与えた事例です。Key Trustを含む先進的な認証方式を利用する環境では、運用ポリシーとレジストリ設定の整合性を保つ必要があります。
マイクロソフトは次回以降の月例更新で修正版をリリースする予定です。Windows Health Dashboardや公式ドキュメントを定期的に確認し、本番環境への適用前に十分な動作検証を行ってください。
本番環境では夜間や週末のメンテナンスタイムを活用し、段階的にロールアウトすることを推奨します。また、障害発生時にはActive Directoryに精通した担当者とMicrosoftサポートに即時連携し、迅速な原因究明と対応を図りましょう。
常時監視と段階的なロールアウトを実施し、万が一の障害時にも迅速にロールバックできる体制を整えましょう。
