MENU

Windows Server 2022 ドメインコントローラーの StrongCertificateBindingEnforcement と Intune 証明書ベース認証への影響と対策

Active Directory

Windows Server 2022 のドメイン コントローラーで StrongCertificateBindingEnforcement が見当たらず、「Intune 管理デバイスに影響が出ないか？」と不安になっている管理者は少なくありません。本記事では、このレジストリ キーの正しい位置や既定動作、2025 年以降の変更点、そして Intune 環境と証明書ベース認証への具体的な影響と対策を、できるだけ分かりやすく整理します。

ITtripTOOLS
その「面倒」、無料で解決。 ITtripがつくる、6つの道具。 無料ツール一覧へ すべて無料・追加課金なし
先頭0を守るCSV編集こわさないCSV PDFに直接書き込みかけるPDF 写真＋説明をPDFに写レポ スマホ⇄PCで共有コピペ便 · 文章・写真 みんなの日程を調整日程Fit 匿名質問・投票を集めるKOEQ
目次

KB5014754 と StrongCertificateBindingEnforcement の背景

まず前提として、問題のレジストリ キー StrongCertificateBindingEnforcement は、2022 年 5 月の更新プログラム KB5014754 で導入された、「証明書ベース認証の強化機能」を制御するためのものです。ターゲットは Windows ドメイン コントローラー上の Kerberos Key Distribution Center (KDC) で、証明書から Active Directory アカウントをどのように「ひも付けるか（マッピングするか）」をより厳格にチェックするように変更されました。

この変更のきっかけは、証明書のサブジェクト名や UPN、sAMAccountName の衝突を悪用した権限昇格脆弱性（CVE-2022-26923 など）で、名前ベースのマッピングだけに頼る仕組みは「なりすましに弱い」と判断されたためです。そこで Microsoft は、証明書の中に AD アカウントの SID（Security Identifier） を埋め込む 強力な証明書マッピング（Strong Certificate Mapping） を導入し、段階的にそれを必須化する方針を取りました。

レジストリ キーが見当たらないのは正常か？

質問のとおり、Windows Server 2022 のドメイン コントローラーを確認しても、StrongCertificateBindingEnforcement がレジストリ内に見当たらないケースは普通にあります。これ自体は異常ではなく「既定の仕様」です。

レジストリ キーの正しい場所

まず、キーの位置を正しく押さえておきましょう。公式ドキュメントでは、値は以下の場所にあります。

HKEY_LOCAL_MACHINE
  \SYSTEM
    \CurrentControlSet
      \Services
        \Kdc
          StrongCertificateBindingEnforcement (REG_DWORD)

Control\Lsa 配下ではなく、Services\Kdc 配下に DWORD 値として定義される点に注意してください。

キーがないときの動作

ポイントは次のとおりです。

  • レジストリ値は既定では作成されない（自分で作らない限り存在しない）。
  • KB5014754 適用後、値が存在しない場合は互換モード（Compatibility mode）として扱われ、従来どおり弱いマッピングの証明書でも認証を許可します（警告イベントは出る）。
  • 2025 年 2 月のセキュリティ更新プログラム（2025-02-11）以降は、値が存在しなくても既定が「完全適用モード（Full Enforcement）」に切り替わりました。

つまり、StrongCertificateBindingEnforcement がないのは不具合ではなく、「KB5014754 導入後～2025 年 2 月パッチまで」の期間は「まだ互換モードのまま」だったことを意味します。そして 2025 年 2 月以降にパッチを適用したサーバーでは、何もしなくても原則 Full Enforcement に移行済みと考えるべきです。

StrongCertificateBindingEnforcement の値とモード

このレジストリ値は、KDC の動作モードを数値で切り替えるものです。ドキュメントや時期によって説明が微妙に異なりますが、代表的な整理は以下のようになります。

値モード概要現在の扱い
0無効 / 互換モード（Disabled / Compatibility）強力なマッピングを要求しない。SID 拡張を無視し、従来どおり SAN や Subject ベースの「弱いマッピング」で認証する。2023 年 4 月以降は非推奨。新しいドキュメントでは利用しない前提。
1互換モード（Compatibility / Audit）強力なマッピングを優先してチェックし、存在しない場合は従来どおりの弱いマッピングも許可する。ただしイベント ログに警告を記録。移行期間中の監査モードとして推奨。2025 年 9 月以降はキー自体が無効化される予定。
2完全適用モード（Full Enforcement）強力なマッピングや SID 拡張がなければ認証を拒否する。2025 年 2 月以降の既定動作。最終的に全 DC がこの挙動になる。

環境によっては「0=互換, 1=完全適用」といった記述もありますが、重要なのは最終形として「互換モード（1）か完全適用（2）か」に集約されることです。新規設計やこれからの調整では、基本的に以下の 2 パターンだけを意識しておけば十分です。

  • 移行・テスト中：1（互換 / 監査モード）
  • 本番移行完了後：2（完全適用）

2025 年以降のタイムライン整理

KB5014754 周りは日付が何度も延びたため、「結局いつまでに何をすればいいの？」という混乱がよく起きます。ここでざっくり整理しておきます。

時期主な変更点管理者に求められる対応
2022-05-10 以降KB5014754 が公開。DC は既定で互換モード。強力なマッピングを満たさない証明書は警告イベントを出す。AD CS と DC にパッチを適用し、イベント ID 39/40 を監視して問題証明書を洗い出す。
～2025-02-10互換モードの猶予期間。レジストリ キーを使って任意に完全適用モードへ切り替えてテスト可能。証明書テンプレートや Intune 発行証明書を修正し、「SID を含む強力なマッピング」が行える状態にしておく。
2025-02-11 以降セキュリティ更新プログラム適用済み DC は、キー未設定でもFull Enforcement を既定で有効化。弱いマッピングの証明書は認証エラーになる。必要に応じて StrongCertificateBindingEnforcement=1 を設定して一時的に互換モードへ戻しつつ、本番環境の調整と再発行を進める。
2025-09-09 / 10 以降Windows 更新プログラム適用後、StrongCertificateBindingEnforcement レジストリ値はサポート対象外になり、常時 Full Enforcement 相当の動作になる。この時点までに、すべての証明書ベース認証が強力なマッピング基準に準拠していることを確認しておく必要がある。

現在（2025 年 11 月）時点では、多くの環境がすでに 2 月・9 月の更新済みであると想定されるため、実質的には「常に Full Enforcement が前提」と考えるのが安全です。

Intune 管理デバイスへの影響は？

本題の「Intune で管理しているデバイスに影響があるのか？」は、実は次の一点に集約されます。

その Intune 管理デバイスが、オンプレ AD に対して証明書ベースで認証しているかどうか。

主なシナリオ別の影響度

シナリオ例KB5014754 / Strong Mapping の影響
クラウドのみで認証Entra ID（旧 Azure AD）サインイン、OAuth / OpenID Connect、クラウド専用アプリのみオンプレ AD の KDC を経由しないため、基本的に影響なし。レジストリ キーを意識する必要はほぼない。
Intune 端末＋オンプレ Wi‑Fi / VPN 認証802.1X Wi‑Fi、Always On VPN、RADIUS（NPS）でオンプレ AD に対して証明書ベース認証証明書が強力なマッピング条件を満たさない場合、2025 年 2 月以降に認証エラーが発生する可能性が高い。
ハイブリッド環境オンプレ AD 参加＋ Entra ハイブリッド参加、GPO と Intune を併用オンプレ DC が証明書を使って認証しているサービス（Wi‑Fi / VPN / NPS / IIS クライアント証明書など）がある場合、影響あり。
スマート カード / vSmartCard ログオン物理スマートカードや仮想スマートカードでドメイン ログオンテンプレートや証明書に SID 拡張が入っていないと、Full Enforcement 時にログオン不可となるリスクがある。

したがって、Intune 管理デバイスが オンプレ AD ドメイン コントローラーに対して証明書ベースで認証していないのであれば、今回のレジストリ キーの有無はほぼ気にしなくてよいと言えます。一方、Wi‑Fi や VPN、NPS などで証明書を使っている場合は、かなりの確率で影響が出るため、ここからの対策が重要になります。

Intune ＋ 証明書ベース認証環境でのチェックポイント

オンプレ AD を使った証明書ベース認証を行っている Intune 環境では、次の 4 つを重点的に確認しましょう。

  1. AD CS の証明書テンプレート
  2. 実際にクライアントに配布されている証明書の中身
  3. Intune の PKCS / SCEP プロファイル設定
  4. ドメイン コントローラーと NPS のイベント ログ

1. 証明書テンプレートと発行ポリシーの点検

まず、オンプレ AD CS で使用しているテンプレートが「強力なマッピングに対応しているか」を確認します。Microsoft は、証明書に AD アカウントの SID を埋め込むために、OID 1.3.6.1.4.1.311.25.2 の拡張を利用しています。

オンライン テンプレート（サブジェクト名を AD から自動構成するテンプレート）の多くは、KB5014754 適用後に自動でこの拡張を付与するようになっていますが、オフライン テンプレート（サブジェクト名を要求側が自由に指定できるタイプ）は、そのままだと SID 拡張が入りません。このオフライン テンプレートが、まさに Intune（PKCS/SCEP）から利用されるテンプレートです。

テンプレート種別例SID 拡張の扱い
オンライン テンプレートユーザー証明書、コンピューター証明書（Subject を AD 情報から構成）KB5014754 適用後は、多くの場合自動的に SID 拡張が付与される。
オフライン テンプレートIntune / NDES / SCEP / PKCS 用テンプレート、証明書要求者が Subject を指定するテンプレート既定のままでは SID 拡張が付かない。Intune 側設定やポリシー モジュールでの制御が必要。

AD CS 側では、テンプレートのプロパティや certutil -template などを用いて、対象テンプレートに SID 拡張が含まれるかどうかを確認してください。

2. Intune 証明書の「強力なマッピング」対応状況

Intune が発行する PKCS / SCEP 証明書については、2024 年 10 月の更新以降、管理者が SID 情報を埋め込める機能が追加されています。

  • PKCS 証明書：Intune Certificate Connector を v6.2406.0.1001 以降に更新し、コネクタ サーバーに以下のレジストリを設定することで、SID 拡張を埋め込めます。 Key: HKLM\Software\Microsoft\MicrosoftIntune\PFXCertificateConnector Name: EnableSidSecurityExtension Type: DWORD Value: 1 設定後、コネクタ サーバーを再起動することで新規発行証明書から SID 拡張が付与されます。
  • SCEP 証明書：Intune の SCEP デバイス構成プロファイルに、Subject Alternative Name（SAN）の URI 属性として次を追加します。 URI = {{OnPremisesSecurityIdentifier}} これにより、証明書の SAN に URL=tag:microsoft.com,2022-09-24:sid:<SID> のような形で SID が埋め込まれます。

注意点として、既存証明書は自動では書き換わらないため、プロファイル変更後に新しい証明書を配布し直す（古いものを失効・削除する）設計が必要です。

3. 実際の証明書を確認する

クライアント マシン上の証明書ストアから、Wi‑Fi / VPN / NPS で使用している証明書を開き、次の点をチェックします。

  • 「詳細」タブで OID 1.3.6.1.4.1.311.25.2 の拡張が存在するか
  • 存在する場合、その値が対象 AD アカウントの SID と一致しているか
  • SAN に URL=tag:microsoft.com,2022-...:sid:<SID> のエントリが含まれているか（Intune SCEP の場合）
  • サブジェクト名 / SAN に userPrincipalName や dNSName など、AD アカウントと紐付く属性が正しく設定されているか

SID 拡張がない、あるいは別ユーザーの SID になっている場合、その証明書は Full Enforcement 環境では認証に失敗する可能性があります。

4. DC / NPS のイベント ログを読む

KB5014754 適用後は、KDC は問題のある証明書を検出するとイベントを出力します。代表的なものは以下のとおりです。

イベント IDソースモード概要
39 / 41Kdcsvc（System ログ）互換 / 完全適用証明書に強力なマッピングが見つからない、または SID 拡張が不正。互換モードでは警告、完全適用モードではエラー。
40Kdcsvc互換「弱いマッピング」にフォールバックして認証を許可したことを示す警告。
6273Network Policy Server（NPS / Security ログ）完全適用Reason Code 16（資格情報の不一致）などで Wi‑Fi / VPN 認証を拒否。証明書の SID マッピング不備が原因のことが多い。

Full Enforcement へ移行する前後は、これらのイベントを継続的にモニタリングし、「どのユーザー / デバイスが問題証明書を使っているのか」を把握しておくことが重要です。

レジストリ キーを使った段階移行の実務

2025 年 9 月以降はキーが無効化されるとはいえ、「まだ 9 月のパッチを当てていない」「検証環境で挙動を確認したい」といった場面では、StrongCertificateBindingEnforcement を自分で設定してモードを制御することが有効です。

レジストリ キーの作成方法

レジストリ エディタから作成する場合は次のとおりです。

  1. regedit.exe を起動。
  2. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc に移動。
  3. StrongCertificateBindingEnforcement という DWORD (32 ビット) 値を新規作成。
  4. 値を 1（互換 / 監査）または 2（完全適用）に設定。
  5. ドメイン コントローラーを再起動、または KDC サービスを再起動。

PowerShell でまとめて設定する場合の例：

# 互換モード（監査）に設定
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\Kdc' `
  -Name 'StrongCertificateBindingEnforcement' `
  -PropertyType DWORD -Value 1 -Force

# 完全適用モードに設定
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\Kdc' `
  -Name 'StrongCertificateBindingEnforcement' `
  -PropertyType DWORD -Value 2 -Force

必ずすべてのドメイン コントローラーで同じ設定にすること、そして本番環境の前に検証環境でテストすることを忘れないでください。

安全な段階移行のパターン例

  • Step 1：互換モードで監査
    1 を設定し、しばらく運用してイベント ログに警告が出ていないか確認。問題証明書がある場合はテンプレート見直しや再発行を行う。
  • Step 2：限定的な完全適用テスト
    検証用 DC または検証用ドメインで 2 を設定し、Wi‑Fi / VPN / スマートカード等の認証が想定どおり動作するか確認。
  • Step 3：本番 DC を完全適用へ切り替え
    問題がないことを確認したら、本番 DC も 2 に切り替える。切り替え直後はイベント ログとヘルプデスクの問い合わせを密にモニタリングする。

よくある誤解の整理

「キーがない＝機能が無効」ではない

StrongCertificateBindingEnforcement がレジストリに存在しないからといって、KB5014754 の影響を受けないわけではありません。パッチ適用後は、値がなくても内部的には既定のモード（2025 年 2 月以降は Full Enforcement）が適用されます。キーはあくまで「既定動作を上書きするスイッチ」と考えると理解しやすいでしょう。

「Intune ＝必ず影響あり」ではない

Intune 管理だからといって、自動的に KB5014754 のリスクが発生するわけではありません。影響があるのは、次の 2 条件を両方満たすケースです。

  • 認証先がオンプレ AD ドメイン コントローラー（KDC）である
  • その認証で証明書（Intune 発行 or AD CS 発行）を使っている

逆に言うと、クラウド ネイティブな Entra ID / OAuth 認証のみで運用している Intune 環境であれば、KB5014754 による直接的な影響はほぼありません。

「とりあえず 0 にしておけば安全」でもない

一部の古い情報では「StrongCertificateBindingEnforcement=0 で互換モードなので安全」といった説明が見られますが、Disabled モードは 2023 年 4 月以降サポートされておらず、将来の更新で意図しない挙動になる可能性があります。現在は 1（互換）か 2（完全適用）を前提に設計するのがベスト プラクティスです。

Intune 管理環境向けアクション プラン

最後に、Intune 管理デバイスを含むハイブリッド環境で、KB5014754 / StrongCertificateBindingEnforcement に対応するための実務的なアクション プランをまとめます。

フェーズ目的具体的な作業
1. 現状把握影響範囲を特定するどのサービスがオンプレ AD に証明書ベースで認証しているか棚卸し（Wi‑Fi, VPN, NPS, スマートカードなど）。 Intune の Wi‑Fi / VPN / 証明書プロファイルで「オンプレ CA の証明書」を使っていないか確認。
2. 証明書の健全性チェック強力なマッピング要件への準拠状況確認対象証明書に SID 拡張（OID 1.3.6.1.4.1.311.25.2）または SID を含む SAN URI が入っているか確認。 サブジェクト名 / SAN が AD アカウント（UPN / dNSName 等）と正しく対応しているか確認。
3. Intune 側の設定見直し新規証明書の強力なマッピング対応PKCS：Intune Certificate Connector を最新版へ更新し、EnableSidSecurityExtension=1 を設定。 SCEP：SAN の URI に {{OnPremisesSecurityIdentifier}} を追加。 古い証明書から新しい証明書へのローテーション ポリシーを設計。
4. DC のモード制御とテスト停止事故を避けつつ Full Enforcement へ検証環境で StrongCertificateBindingEnforcement を 1 → 2 に切り替えて挙動を確認。 イベント ID 39/40/41 や NPS のイベント 6273 を監視して問題ユーザー・デバイスを洗い出す。 問題が解消したら本番 DC も順次 2（完全適用）へ移行。
5. 長期運用2025 年 9 月以降も安心して運用証明書テンプレート変更時に SID 拡張が維持されることを標準手順に組み込む。 新しいネットワーク機器・NAC 製品などを導入する際も、強力なマッピング対応を事前に確認。

まとめ

ここまでのポイントを整理すると、次のようになります。

  • StrongCertificateBindingEnforcement は既定ではレジストリに存在しないが、それは正常な挙動であり、キーがないからといって KB5014754 の影響を受けていないわけではない。
  • 2025 年 2 月のセキュリティ更新以降、パッチ適用済み DC は既定で Full Enforcement となり、弱い証明書マッピングのままでは Wi‑Fi / VPN などで認証障害が起こり得る。
  • Intune 管理デバイスでも、オンプレ AD への証明書ベース認証を使っていなければ基本的に影響なし。クラウド専用認証のみなら特別な対策は不要なケースが多い。
  • 一方で、ハイブリッド認証（オンプレ DC ＋ Intune 証明書）を利用している場合は、SID 拡張を含んだ強力なマッピング対応証明書への切り替えが必須。
  • レジストリ キーは、移行期間中に「互換モード（1）→ 完全適用（2）」を段階的に切り替えるためのスイッチとして活用し、イベント ログを監視しながら安全に本番移行するのが現実的なアプローチ。

「キーが見当たらない＝大問題」というわけではありませんが、2025 年以降は 「証明書ベース認証なら強力なマッピング対応が当たり前」という前提に世界がシフトしました。今のうちに、自社の Wi‑Fi / VPN / NPS / スマートカード / Intune 証明書発行フローを一度棚卸しし、どこでオンプレ DC に証明書を投げているのか、そしてその証明書は本当に SID ベースの強力なマッピングを満たしているのか、落ち着いて確認しておくことをおすすめします。

Active Directory
Active Directory Windows Server 2022 Intune 証明書ベース認証 KB5014754

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次