Active Directory証明書ベース認証の変更対応:イベントID 39が出ていたら今すぐ確認を
この記事の内容
- Windows Updateの適用によりドメインコントローラーの証明書ベース認証のロジックが段階的に変更されている
- イベントID 39(システムログ)が記録されている環境では、2025年2月11日以降に認証失敗が発生する可能性がある
- 問題の根本は証明書とアカウントの「弱い紐付け」にあり、強い紐付けへの移行が必要
- 対処方法は「アカウント側への証明書情報の記載」と「SIDを含む新証明書の発行」の2種類がある
- レジストリキーで一時的な回避措置は可能だが、2025年9月10日以降は回避措置も無効になる
問題の背景:なぜ今この話題が重要なのか
Active Directoryの管理者の方は、まずドメインコントローラーのシステムイベントログを確認してください。以下のイベントIDが記録されている場合、緊急の対応が必要です。
| イベントID | 対象OS |
|---|---|
| 39 または 41 | Windows Server 2012以降 |
| 40 または 48 | Windows Server 2012以降 |
| 41 または 49 | Windows Server 2008系 |
これらの警告イベントは、証明書ベースの認証は現在成功しているものの、「弱い紐付け」の証明書が使われていることを示しています。2025年2月11日のWindows Updateをドメインコントローラーに適用すると、この状態のままでは認証が失敗するようになります。
なお、このイベントが出ていない環境であれば、現時点での対応は不要です。
変更の経緯:KB5014754とは
Microsoftは証明書ベースの認証における脆弱性を発見しました。攻撃者が弱い紐付けを悪用して別のユーザーやコンピューターになりすませる可能性があったためです。この問題に対応するために、KB5014754「Windowsドメインコントローラーでの証明書ベースの認証の変更」が公開されました。
適用対象はWindows Server 2008系からWindows Server 2022まで広範囲にわたります。
変更のタイムライン
段階的に変更が行われるため、Windows Updateを適用し続けると自動的にモードが移行します。
2022年5月10日:互換モードへ移行
Windows Updateの適用後、ドメインコントローラーは「互換モード」で動作します。この段階では、弱い紐付けの証明書でも認証は成功しますが、イベントID 39などの警告ログが記録されます。管理者がこのログに気づいて対処することを促す期間です。
2023年4月11日:無効モードの削除
StrongCertificateBindingEnforcementレジストリキーの値「0(無効モード)」が削除され、0を設定しても互換モードと同等の動作になりました。
2025年2月11日:完全適用モードへ移行(※直近の変更)
このWindows Updateをドメインコントローラーに適用すると、弱い紐付けの証明書による認証が拒否されるようになります。対処が完了していない環境では、認証エラーが発生します。
典型的な影響例として、802.1X認証を使ったネットワーク認証(有線・無線のデバイス認証)が突然失敗し、クライアントがネットワークに接続できなくなるケースが挙げられます。
2025年9月10日:完全適用の強制(最終期限)
この時点でStrongCertificateBindingEnforcementレジストリキー自体が無効になり、回避措置が使えなくなります。強い紐付けの証明書でしか認証できなくなる最終的な状態です。
「強い紐付け」と「弱い紐付け」の違い
証明書ベースの認証では、証明書が「このユーザー(またはコンピューター)のものである」ことを証明する仕組みが必要です。この紐付けの強度が問題の核心です。
弱い紐付き(対処が必要)
ユーザー名やメールアドレスなど、変更可能な値で証明書とアカウントを紐付けている状態です。これらは攻撃者が悪用できる可能性があります。
強い紐付き(推奨)
証明書にADオブジェクトのSID(セキュリティ識別子)が埋め込まれている状態です。SIDはADオブジェクトを一意に識別するIDであるため、なりすましが困難になります。
具体的には、証明書に以下のOIDを持つ拡張属性が含まれているかどうかで判断されます。
対処方法
対処方法は大きく2種類あります。
方法1:証明書へアカウントをマッピングする(推奨)
SIDが含まれた新しい証明書を発行する方法です。根本的な解決策であり、推奨される対処です。
エンタープライズCA(Active Directory証明書サービス)を使用している場合
2022年5月10日以降のWindows Updateを適用済みのエンタープライズCAでは、証明書テンプレートの「サブジェクト」タブが「Active Directoryの情報から構築する」に設定されていれば、新規発行・更新される証明書に自動的にSIDが追加されます。
多くの場合、古い証明書の有効期限が切れて更新されれば自然に解消されます。ただし、証明書の有効期間を極端に長く設定している場合は、手動での更新が必要になることがあります。
サードパーティCAを使用している場合
証明書プロバイダーと協力してSIDを含む証明書の発行に対応してもらうか、後述の方法2で対処する必要があります。
方法2:アカウントへ証明書をマッピングする(代替手段)
サードパーティCAを利用していて証明書の再発行が難しい場合など、証明書の更新ができない状況での対処法です。Active DirectoryのユーザーオブジェクトまたはコンピューターオブジェクトのaltSecurityIdentities属性に証明書の情報を登録します。
マッピング方法の中では、**IssuerAndSerialNumber形式(推奨)**を使用します。
手順の概要は以下の通りです。
1. 証明書の発行者とシリアル番号を取得する
certutil -store <ストア名>
2. 発行者のDN名を逆順に並べ替える
例:
3. シリアル番号を2文字ずつ逆順に並べ替える
例:
4. 文字列を組み合わせてaltSecurityIdentities属性に設定する
PowerShellを使用してユーザーオブジェクトに設定する例:
Set-ADUser -Identity <ユーザー名> `
-Replace @{altSecurityIdentities = "X509:<I>DC=com,DC=contoso,CN=MyCA<SR>785634..."}
コンピューターオブジェクトの場合:
Set-ADComputer -Identity <コンピューター名> `
-Replace @{altSecurityIdentities = "X509:<I>DC=com,DC=contoso,CN=MyCA<SR>785634..."}
既存の値がある場合は-Replaceではなく-Addを使用して追加してください。
一時的な回避措置:レジストリキーの設定
対処が完了するまでの間、レジストリキーで互換モードを明示的に維持することができます。
レジストリキーのパス:
キー名: StrongCertificateBindingEnforcement
| 値 | 動作 |
|---|---|
| 設定なし(既定)または 1 | 互換モード(警告ログを記録するが認証は成功) |
| 2 | 完全適用モード(対処完了後に設定) |
対処が完了するまでは値を 1 に設定して互換モードを維持し、対処完了後に 2 へ変更することをお勧めします。
ただし、この回避措置は2025年9月10日のWindows Update適用後は無効になります。 その時点でレジストリキー自体が参照されなくなるため、9月までには根本的な対処を完了させる必要があります。
よくある疑問:「なぜ今もイベントが出ているのか」
エンタープライズCAを使用していて2022年以降のWindows Updateを適用済みであれば、新規に発行される証明書にはSIDが自動的に含まれます。それでも警告イベントが記録されている場合、以下の原因が考えられます。
- 証明書の有効期間が長い:更新タイミングがまだ来ていない古い証明書が引き続き使われている
- 手動発行の証明書がある:テンプレート設定が「Active Directoryの情報から構築する」になっていない証明書が存在する
- サードパーティCAで発行した証明書がある:自動更新の仕組みが適用されない
まとめ
Active Directoryの証明書ベース認証の変更は、2022年5月から段階的に進められてきた長期的なセキュリティ改善施策です。
- まず確認すべきこと:ドメインコントローラーのシステムイベントログにID 39, 40, 41, 48, 49が記録されていないか確認する
- イベントが出ていない場合:現時点での対応は不要
- イベントが出ている場合:2025年2月11日のWindows Update適用前に対処を完了させる
- 対処の基本方針:エンタープライズCAの場合は証明書の再発行(有効期間が長いものは手動更新)、サードパーティCAの場合はaltSecurityIdentities属性の設定
- 一時回避:
StrongCertificateBindingEnforcementを1に設定して互換モードを維持(2025年9月10日まで有効) - 最終期限:2025年9月10日までに根本的な対処を完了させること
システムイベントログの監視と定期的なWindows Update情報のキャッチアップが、今回のような問題を早期に解決するための基本です。ドメインコントローラーを管理している組織は、周囲のAD管理担当者とも情報を共有し、対処状況を確認し合うことをお勧めします。