【検証用】ADCSでサクッとEntra ID証明書認証(CBA)を試す！【Windows】

Entra IDでクラウドアプリへのユーザーアクセスを認証する際、条件付きアクセスポリシーを使って許可/ブロック条件を指定することができます。
現場の肌感覚としては、やはりデバイスベースの認証や多要素認証が人気です。

【アクセス制御 構成例】

• デバイスベースの認証
  • Intune に登録済み かつ コンプライアンスポリシーに準拠したデバイスを接続元とするアクセスを許可する
  • Microsoft Entra hybrid join したデバイスを接続元とするアクセスを許可する
• 多要素認証 (multi-factor authentication、MFA)
  • Microsoft Authenticator / SMS / メールOTP による MFA を満たした場合にアクセスを許可する

Entra ID は、上記のようにデバイスの Entra 参加状態、Intune コンプライアンス状態をもとに組織所有のデバイスとそれ以外を区別することができます。

ただ、特に Intune とは別の MDM を使っていたり、Entra Connect が不在でハイブリッド参加ができなかったりするような場合、どう組織のデバイスとそれ以外を区別してアクセス制御するか課題になります。

そんなとき、証明書ベースの認証 (certificate-based authentication、CBA) を使うと、デバイス区別可能かつ、MFA も同時にかなえることができます！

先日、手持ちの ADCS 環境で CBA を案外サクッと動作確認できましたので、本記事では検証目的で簡易に動確する方法をまとめます。
ちょうどちょこっと手元で見てみたかったんだよね、といった方のご参考になりますと幸いです。

本記事のサマリ (written by Copilot)
CBA を一度サクッと試してみたい人へ

• 本記事では、ADCS を用いた最小構成の検証環境で、Microsoft Entra ID の証明書ベースの認証 (CBA) を実際に動かす手順をまとめています。
• Intune を使えない/使わない前提でも、CBA による認証で「信頼する環境からの接続のみを許可する」構成の実装イメージを確認できます。
• CBA における認証方法、認証強度、条件付きアクセスポリシーの関係性を、設計のインプットとして整理したい方にも参考になる内容です。

関連記事
Android 検証版の記事を公開しました！

• 【検証用】ADCSでサクッとEntra ID証明書認証(CBA)を試す！【Android】

目次

本記事は以下の構成です：

#	章題	概要
1	動作例	ユーザー目線のサインインエクスペリエンスをまとめます
2	検証環境	システム構成とポイントをまとめます
3	検証ステップ	検証時の構築作業や動作確認を実施した順に振り返ります
-	さいごに	徒然と感想など...
-	参考	検証にあたって参考にさせていただいた神記事たち

長めの記事になってしまったので、適宜飛ばし読みしていただければと思います🚀
PC で開いていただけると Qiita 標準機能の目次が常に表示されますので、ご活用ください！

1. 動作例

ユーザーが Teams など Entra ID を認証基盤とするクラウドアプリにサインインすると、ID・パスワードの入力 (シームレス SSO 時は不要) 後に証明書の選択を求められます。

選択した証明書が Entra ID の要件を満たしたら (ルート証明書がアップロードされている、バインディングなど条件を満たす) アクセスが許可されます。

以下、簡易ですが図にしてみました。

2. 検証環境

今回検証で利用した環境を、簡易ですが図示・要素をリストします。

• 2-1. 構成図
• 2-2. 構成要素

2-1. 構成図

下図 (↓) は、検証時の構成を簡易にまとめてみたものです。

ADCS をはじめとするサーバー機能と動作確認用のクライアントは Azure 仮想マシンを利用し、Entra ID 認証確認用のクラウドアプリには Microsoft 365 (Teams や Office ポータル) を利用しました。

証明書の発行・展開
Entra ID 自身に証明書を発行・展開する機能はありません。
Entra ID 証明書ベースの認証では、あくまで公的機関から発行されたルート証明書を事前に Entra ID にアップロードし、それをもとに証明書を識別して認証を行います。

証明書の展開はどう行う？
以下余談ですが、証明書の展開はデバイスを管理している何かしらの MDM で行うのがよさそうです。

Intune 証明書コネクタを使うと、ADCS から証明書を発行し Intune から展開することも可能です。
(今回は AD ドメイン参加済みかつ同一仮想ネットワーク上の検証端末を利用したため、certmgr.msc から証明書を要求してインストールしました。)

ただし、Intune 導入済みの環境であれば Intune から証明書を展開して端末識別するよりも、デバイスを Intune に登録して端末識別するほうが王道です。
(Intune から証明書を展開するにはデバイスが Intune に MDM 登録されている必要があります。)

以下の組み合わせが実際ありえるユースケースかと思います。

• Intune に登録されていないデバイスから Entra ID 認証を利用する
• Entra ID にて端末識別できないので証明書ベースの認証を利用する
• 証明書の展開はデバイスを管理している 3rd party MDM が行う

3rd party MDM 不在の検証環境のため、今回の検証では証明書の展開自動化まで深堀しませんでした。

2-2. 構成要素

先ほどの図の検証環境の構成要素は以下です：

#	環境	機能	備考
1	サーバー	ADDS	ドメイン環境を構成
2	サーバー	Entra Connect	Windows Server AD のドメインを Entra ID に同期
3	サーバー	ADCS	証明書テンプレートを作成・発行、ルート証明書をエクスポート
4	クライアント	Windows 11	アクセス動作確認に利用するクライアント
5	クラウド	Entra ID	条件付きアクセスを利用するため、P1 ライセンス
6	クラウド	Teams など	条件付きアクセスにて証明書要求するのを動作確認するため、Entra ID が認証する任意のクラウドアプリを用意

サーバー環境 (#1, 2, 3)

検証環境の都合上、ADDS・Entra Connect・ADCS を 1台のサーバーに載せています。
VM サイズは Standard B2ms (2 vcpu 数、8 GiB メモリ)、OS は Windows Server 2022 Datacenter¹ です。

証明書は中間証明書無しで、証明書チェーンはルートとユーザー証明書の寂しい 2階層構成です。
また、理想は CRL (certification revocation list) があり失効した証明書を検証して有効な証明書のみ認証を通す構成ですが、今回は CRL 無しで検証しています。
(外部からアクセスできる CRL を用意するのは証明書初心者の私にちょっとハードルが高かったです。)

ドメイン端末に証明書展開できる Enterprise CA 構成を使っていますが、今回のために特別意図したのではなくたまたま以前構築していた環境がこの構成でした。
CBA という観点では信頼できるルート証明書とユーザー証明書のセットがあれば動きそうです。
(もともと Entra ID 自体に証明書を発行・展開する機能が無いので、この部分は外部のシステム利用が前提になります。証明書チェーンに中間証明書がある場合は、Entra IDにルート証明書と中間証明書をアップロードします。)

クライアント環境 (#4)

今回は簡易に Windows で確認しました。
CBA としては Apple デバイス (macOS, iOS/iPadOS) や Android もサポートしているそうです。
(参考：Microsoft Entra certificate-based authentication on iOS and macOS、Microsoft Entra certificate-based authentication on Android devices、2026年2月27日閲覧)

関連記事
Android 検証版の記事を公開しました！

• 【検証用】ADCSでサクッとEntra ID証明書認証(CBA)を試す！【Android】

証明書の展開方法として、Intune や 3rd party MDM といったデバイス管理機関から展開するのが本番環境の一般的構成かと思いますが、今回は簡易検証のため certmgr.msc から証明書を要求してインストールしました。

また、本来 CBA を使う醍醐味としては、本記事冒頭に記載したように Entra ID で組織端末として識別できない管理方法の端末を使うシナリオですが、今回はサッと検証に使える都合のいいデバイスがたまたま Entra hybrid joined 状態 (ADDS と Entra ID のどちらにも参加している状態) でした。
← Entra hybrid joined だとシームレス SSO ができる (Entra ID 認証時ユーザーID、パスワード入力無しで SSO できる) というだけで、証明書を求める動作には影響ありません。

今回たまたまクライアントも VM を利用しました。サイズは Standard B2s (2 vcpu 数、4 GiB メモリ) です。

クラウド環境 (#5, #6)

Entra ID にて、条件付きアクセスポリシーをはじめとする、クラウドアプリ認証時に証明書を求めるために必要な構成を実施します。
(構成の詳細は [3. 検証ステップ] (次セクション) に記載します。)

また今回検証では、Entra Connect で ADDS から Entra ID に同期したユーザーを使いました。

アクセス先としては Microsoft 365 アプリ (Teams, Office ポータル) を使っています。
このため、検証ユーザーには Entra ID P1 とクラウドアプリ利用に必要な分のライセンスが割り当てられている状態です。(当方環境では Microsoft 365 Enterprise)

3. 検証ステップ

構築と動作確認を合わせて、以下の順で検証しました。

#	操作対象	作業概要	内容
3-1.	サーバー	ユーザー証明書テンプレート作成	ADCS にて User 証明書テンプレートを複製し、CBA 検証用の証明書テンプレートを作成します
3-2.	クライアント	ユーザー証明書インストール	先ほど作成した CBA 検証用の証明書をドメイン参加済みの PC から要求します
3-3.	サーバー	ルート証明書エクスポート	ADCS にてルート証明書をエクスポートし、ファイルとして保存します
3-4.	Entra ID	ルート証明書アップロード	先ほど保存したルート証明書ファイルを Entra ID にアップロードします
3-5.	Entra ID	(任意) グループ作成	CBA の利用範囲をグループ単位で定義したい場合、Entra ID 上でセキュリティグループを作成します
3-6.	Entra ID	認証方法設定	「証明書ベースの認証」方法を有効化し、利用可能な状態にします
3-7.	Entra ID	認証強度設定	条件付きアクセスポリシーにて証明書ベースの多要素認証を明示的に要求できるよう、カスタムで認証強度を作成します
3-8.	Entra ID	条件付きアクセスポリシー設定	証明書ベースの多要素認証を求める条件付きアクセスポリシーを作成します
3-9.	クライアント	サインイン動作確認	証明書インストール済みの PC にてサインイン動作を確認します
3-10.	Entra ID	サインインログ確認	サインインログから、条件付きアクセスポリシー評価結果を確認します

ADDS, Entra Connect, ADCS の構築ステップ
以前から構築済みのものを流用しながら検証を行ったため、本記事では記載を割愛しています。
以下の素敵記事をご参考ください。（2026年3月4日閲覧）

• ご参考：
  • ADDS：Azure上で Active Directory の構築＆ドメイン参加
  • Entra Connect：
    • Microsoft Entra Connect とは（旧：Azure AD Connect）
    • 「Microsoft Entra Connect」でオンプレとクラウドをつなぐ！同期開始までの構築手順まとめ
    • Azure上のADサーバをEntra Connectさせてみた
  • ADCS：「Active Directory 証明書サービス」構築の流れ

以降、各ステップで実施したことを順にまとめます。

3-1. [サーバー] ユーザー証明書テンプレート作成

操作対象	作業概要	内容
サーバー	ユーザー証明書テンプレート作成	ADCS にて User 証明書テンプレートを複製し、CBA 検証用の証明書テンプレートを作成します

• 参考：
  • Microsoft Entra CBAをオンプレのCAから発行した証明書を使って構成する、2026年3月4日閲覧
  • 【ADCS】証明書テンプレート作成・発行・配布方法 - ドメイン参加済み端末にて証明書の要求・配布確認、2026年3月4日閲覧

ADCS サーバーの Certificate Templates Console (certtmpl.msc) にて User 証明書テンプレートを複製し、CBA 検証用の証明書テンプレートを作成します。
次に、Certificate Authority (certsrv.msc) より証明書を発行します。

【作業ステップ】

3-1. 作業ステップ (折りたたみました。左端の ▶ をクリックして展開)

• サーバーにサインインし、[Windows] キー + [R] キーをクリックして [ファイル名を指定して実行] を起動します。

• [ファイル名を指定して実行] に certtmpl.msc を入力して [OK] をクリックし、[Certificate Templates Console] を開きます。

• [Certificate Templates Console] にて、Template Display Name が「User」のテンプレートを右クリックし、[Duplicate Template] をクリックします。 (テンプレートを複製)
  

• [Properties of New Template] (新しいテンプレートのプロパティ) 画面が開くので、[General] タブにてテンプレート名と期間として任意の値を設定します。

  General タブの設定
  当方検証環境ではテンプレート名を「Entra CBA」としました。
  以降、本記事でも作成した証明書を「Entra CBA」と表記します。

  • Template display name: Entra CBA
  • Template name: Entra CBA

  (別のテンプレート名を設定する場合は適宜本記事の記載や写真を読み替えてください。)

  

• [Extensions] タブにて [Application Policies] 配下に [Client Authentication] が存在していること (既定値) を確認します。[Edit] > [Add] から [Smart Card Logon] などを追加することも可能です。今回の検証では参考記事に倣い追加しました。

  Extensions タブの設定
  その後別の検証のため証明書テンプレートを再作成しましたが、Application Policies 配下に Client Authentication さえ存在していれば本記事記載の範囲の CBA は使えることが分かりました！

  
  

• [Security] タブにて、[Domain Users] に [Enroll] 許可権限がついていること (既定値) を確認します。
  

• [Compatibility] タブにて、任意で [Certification Authority] と [Certificate recipient] の compatibility を設定します。

  Compatibility タブの設定
  こちらには上位互換性があるそうなので設定変更は任意となりますが、当検証環境では逆に下位互換性を担保する必要もないので、存在する選択肢のなかから最新を選択しました。

  
  

• [Request Handling] タブにて、[Allow private key to be exported] をオフにします。
  

• [Subject Name] タブにて、alternate subject name 欄の [User principal name (UPN)] をオンにします。また、今回の検証では試しに [include e-mail name in subject name] をオフにしてみました。

  Subject Name タブの設定
  既定値のまま alternate subject name の [E-mail name] をオンにすると、証明書要求するユーザーがメールアドレスを持つ必要があります。
  (メールアドレスを持たないユーザーが証明書要求した際にエラーが発生し証明書をインストールできません。)
  ユーザーにメールアドレスを持たせておくか、[E-mail name] をオフにするか、どちらか対応し整合性を持たせておく必要があります。

  

• [Issuance Requirements] タブはじめ、その他のタブについては既定値を採用し、[OK] をクリックしてプロパティ画面を閉じます。
  

• [Certificate Templates Console] 上に先ほど作成した証明書テンプレート「Entra CBA」が表示されます。
  

• [Windows] キー + [R] キーをクリックして [ファイル名を指定して実行] を起動し、certsrv.msc を入力 > [OK] をクリックし、[Certificate Authority] を開きます。

• [Certificate Authority] 左ペインのツリーを展開し、[Certificate Template] を右クリック > [New] > [Certificate Template to Issue] をクリックします。

• [Enable Certificate Templates] ウィンドウが開くので、先ほど作成した「Entra CBA」証明書テンプレートを選択し [OK] をクリックします。
  

• [Certificate Template] 一覧上に「Entra CBA」が表示されます。
  

Certificate Authority (certsrv.msc) は、後工程でルート証明書をエクスポートする際にも利用します。

証明書テンプレートの作成、発行作業は以上です。

3-2. [クライアント] ユーザー証明書インストール

操作対象	作業概要	内容
クライアント	ユーザー証明書インストール	先ほど作成した CBA 検証用の証明書をドメイン参加済みの PC から要求します

• 参考：【ADCS】証明書テンプレート作成・発行・配布方法 - ドメイン参加済み端末にて証明書の要求・配布確認、2026年3月4日閲覧

先ほど ADCS 上で発行した証明書を、クライアントから要求しインストールします。

【作業ステップ】

3-2. 作業ステップ (折りたたみました。左端の ▶ をクリックして展開)

• クライアントにサインインし、[Windows] キー + [R] キーをクリックして [ファイル名を指定して実行] を起動します。

• [ファイル名を指定して実行] に certmgr.msc を入力して [OK] をクリックし、[Certificate - Current User] コンソールを開きます。

• [Certificates - Current User] を展開して [Personal] を右クリックし、[All Tasks] > [Request New Certificate] をクリックします。(新しい証明書の要求)

  Certification - Current User
  カレントユーザーの個人の証明書ストア配下にインストールします。

  

• [Certificate Enrollment] ウィザードが開くので、[Before You Begin] (開始する前に) 画面にて [Next] (次へ) をクリックします。

• [Certificate Enrollment] ウィザードの [Select Certificate Enrollment Policy] (証明書の登録ポリシーの選択) 画面にて [Active Directory Enrollment Policy] (Active Directory 登録ポリシー) が選択されていること (既定値) を確認して、[Next] (次へ) をクリックします。
  

• [Certificate Enrollment] ウィザードの [Request Certificates] (証明書の要求) 画面にて 「Entra CBA」を選択し、[Enroll] (登録) をクリックします。
  

• [Certificate Enrollment] ウィザードの [Certificate Installation Results] にて [STATUS: Succeeded] と表示されたことを確認して [Finish] をクリックします。
  

• [Certificates - Current User] > [Personal] 配下に 「Entra CBA」テンプレートの証明書が表示されます。
  

• ちなみに今回の構成では中間証明書不在です。
  

証明書インストール作業は以上です。

3-3. [サーバー] ルート証明書エクスポート

操作対象	作業概要	内容
サーバー	ルート証明書エクスポート	ADCS にてルート証明書をエクスポートし、ファイルとして保存します

ルート証明書を Entra ID にアップロードする必要があるため、ADCS からルート証明書をファイルとしてエクスポートしておきます。

ファイル形式
エクスポート時、ファイルのフォーマットは既定の Base-64 encoded X.509 (.CER) を利用しました。

【作業ステップ】

3-3. 作業ステップ (折りたたみました。左端の ▶ をクリックして展開)

• サーバーにサインインし、[Windows] キー + [R] キーをクリックして [ファイル名を指定して実行] を起動、certsrv.msc を入力 > [OK] をクリックし、[Certificate Authority] を開きます。
• [Certificate Authority (Local) ツリーを展開して CA 名を右クリック、プロパティを開き、[General] タブ下の CA certificate が選択された状態で [View Certificate] をクリックします。
• ルート証明書が表示されるので、[Copy to File...] をクリックします。
• [Certificate Export Wizard] が開くので、[Welcome to Certificate Export Wizard] 画面にて [Next] をクリックします。
  
• [Certificate Export Wizard] の [Export File Format] 画面にて、[Base-64 encoded X.509 (.CER)] が選択されていること (既定値) を確認して、[Next] をクリックします。
  
• [Certificate Export Wizard] の [File to Export] 画面にて、ファイル名を含むパスを指定して [Next] をクリックします。
  
• [Certificate Export Wizard] の [Completing the Certificate Export Wizard] 画面にて設定値を確認し、[Finish] をクリックします。
  

ルート証明書エクスポート作業は以上です。

3-4. [Entra ID] ルート証明書アップロード

操作対象	作業概要	内容
Entra ID	ルート証明書アップロード	先ほど保存したルート証明書ファイルを Entra ID にアップロードします

• 参考：Set up Microsoft Entra certificate-based authentication - Step 1: Configure the CAs with a PKI-based trust store、2026年3月5日閲覧

先ほど ADCS からエクスポートしたルート証明書ファイルを Entra ID にアップロードします。

【作業ステップ】

3-4. 作業ステップ (折りたたみました。左端の ▶ をクリックして展開)

• Microsoft Entra 管理センター (entra.microsoft.com)² にサインインし、[Entra ID] 配下の [証明書機関] または [ID セキュリティスコア] > [認証局 (クラシック)] > [アップロード] をクリックします。
  
• [証明書ファイルのアップロード] 画面にて、証明書欄に先ほど ADCS からエクスポートしたルート証明書ファイルを選択し、[ルート CA 証明書である] 欄の値が [はい] (既定値) であることを確認して [追加] をクリックします。
  
• [証明書が正常にアップロードされました] 通知が出れば完了です。

証明書をアップロードしています
証明書が正常にアップロードされました

ルート証明書アップロード作業は以上です。

3-5. [Entra ID] (任意) グループ作成

操作対象	作業概要	内容
Entra ID	(任意) グループ作成	CBA の利用範囲をグループ単位で定義したい場合、Entra ID 上でセキュリティグループを作成します

• 参考：Microsoft Entra グループとグループ メンバーシップを管理する、2026年3月5日閲覧

Entra ID 証明書ベースの認証 (CBA) の利用範囲は、テナント全体 (すべてのユーザー) とすることも特定のグループに絞ることも可能です。

【構成のポイント】

• 対象範囲
  今回は、特定のグループに絞って検証を行いました。この場合、Entra ID 上のセキュリティグループを利用して範囲指定します。

• グループ源泉
  ADDS から Entra Connect にて同期したセキュリティグループを使っても、クラウドネイティブに Entra ID 上で作成したセキュリティグループを使っても大丈夫です。
  今回は Entra ID 側で作成しています。

• メンバーシップ
  テストユーザーは 1アカウントのみのため静的メンバーシップにしましたが、運用的に属性ベースのメンバーシップのメリットが勝つなら動的な構成も可能です。

グループの名前
当方検証環境ではグループ名を「CBA Enabled Users」としました。
(別のグループ名を設定する場合は適宜本記事の記載や写真を読み替えてください。)

3-6. [Entra ID] 認証方法設定

操作対象	作業概要	内容
Entra ID	認証方法設定	「証明書ベースの認証」方法を有効化し、利用可能な状態にします

• 参考：Set up Microsoft Entra certificate-based authentication - Step 2: Turn on CBA for the tenant、2026年3月5日閲覧

Entra ID の既定の状態では、証明書ベースの認証方法が「無効化」されており使えない状態です。これをテナント全体 (すべてのユーザー) または特定のセキュリティグループ向けに有効化していきます。
(当方環境の検証では特定のセキュリティグループ向けに有効化)

【作業ステップ】

3-6. 作業ステップ (折りたたみました。左端の ▶ をクリックして展開)

• Microsoft Entra 管理センター (entra.microsoft.com)² にて、[Entra ID] 配下の [認証方法] > [ポリシー] > [証明書ベースの認証] をクリックします。
  

• [証明書ベースの認証] の設定画面にて [有効化およびターゲット] タブ下で以下を設定します。

  • 有効にする：トグルを動かして有効化
  • 含める：「すべてのユーザー」または「グループの選択」

  含める
  証明書ベースの認証を有効化する範囲を設定します。

  • すべてのユーザー：テナント全体に対して
  • グループの選択：特定のセキュリティグループに対して

  母集団を「すべてのユーザー」としたうえで対象外グループを指定することも可能です。

  

• [証明書ベースの認証] の設定画面にて [構成] タブ下で以下を設定します。

  • 既定の認証強度：多要素
    

• [証明書ベースの認証] の設定画面にて [構成] タブ下で設定を変更すると以下の警告メッセージが表示されるので、[確認しました] > [保存] をクリックします。

  証明書ベースの認証(CBA)が有効になっているユーザーには有効な証明書があることを確認してください。CBAは多要素認証(MFA)に対応しているため、有効な証明書が無い場合、ユーザーは、CBAを2番目の要素として使用することや、MFAに他の方法を登録することができなくなります。

  TLS検査を備えたファイアウォールまたはプロキシが組織にある場合は、[*.]certauth.login.microsoft.comの下にある任意の名前と一致するcertauthエンドポイントのTLS検査が無効され、使用する特定プロキシに応じてカスタマイズされることに同意してください。

  

認証方法の設定作業は以上です。

3-7. [Entra ID] 認証強度設定

操作対象	作業概要	内容
Entra ID	認証強度設定	条件付きアクセスポリシーにて証明書ベースの多要素認証を明示的に要求できるよう、カスタムで認証強度を作成します

• 参考：
  • Microsoft 365の認証方式にADCSを使用する方法、2026年2月27日閲覧
  • Create and manage custom Conditional Access authentication strengths、2026年3月5日閲覧

通常条件付きアクセスポリシーで多要素認証を要求すると、対象ユーザに対して有効な認証方式のなかからユーザーが任意で選択した方法で多要素認証を実施・検証することになります。
今回は「どんな多要素でも多要素さえ満たせばOK」式ではなく、「証明書認証による多要素を満たせばOK」と多要素認証に使われる要素を指定することが仮想要件であるとします。
これを実現するには、事前に認証強度を構成しておき、その認証強度を条件付きアクセスポリシーにて求めるようにします。

【作業ステップ】

3-7. 作業ステップ (折りたたみました。左端の ▶ をクリックして展開)

• Microsoft Entra 管理センター (entra.microsoft.com)² にて、[Entra ID] 配下の [認証方法] > [認証強度] > [新しい認証強度] をクリックします。

• [新しい認証強度] 画面にて以下を設定します。

  • 名前：直感的に分かりやすい名前を設定
  • 説明：(任意)
  • ■証明書ベースの認証(多要素)

  認証強度の名前
  当方検証環境ではグループ名を「[プリフィックス*] CBA」としました。
  (別の認証強度名を設定する場合は適宜本記事の記載や写真を読み替えてください。)

  *プリフィックスは写真上塗りつぶし

  

• [証明書ベースの認証] 設定画面にて、[証明書の発行者] を選択し、[保存] をクリックします。

  証明書の発行者
  Entra ID に事前にアップロードしたルート証明書に対応する発行者をドロップダウンメニューから選択します。

  

• [新しい認証強度] を [作成] します。
  

認証強度の作成作業は以上です。

3-8. [Entra ID] 条件付きアクセスポリシー設定

操作対象	作業概要	内容
Entra ID	条件付きアクセスポリシー設定	証明書ベースの多要素認証を求める条件付きアクセスポリシーを作成します

• 参考：Require multifactor authentication for all users、2026年3月5日閲覧

先ほど作成した認証強度 (証明書認証) をアクセス許可条件として求める条件付きアクセスポリシーを作成します。
なお、これまで認証方法設定時にセキュリティグループを指定し証明書認証の展開範囲を絞る想定でいる場合は、条件付きアクセスポリシーの対象ユーザーとしても同じセキュリティグループを指定し、範囲を合わせて構成します。

今回の検証では以下の値を使いました。

【構成例 (表)】

3-8. 構成例 (表) (折りたたみました。左端の ▶ をクリックして展開)

#	大項目	中項目	小項目	既定値	設定値 (例)	備考
1	名前	-	-	(空白)	Require CBA (Win_test)	直観的にわかりやすい名前 (主観) を設定
2	割り当て	ユーザー	対象	なし	CBA Required Users	セキュリティグループを設定 (検証範囲を絞る場合)
3	割り当て	ターゲットリソース	対象	なし	すべてのリソース	検証目的のため広めに設定
4	割り当て	ターゲットリソース	対象外	なし	Microsoft Intune	Intuneとの同期を阻害しないよう、Intuneサービスを証明書認証対象から除外 3
5	割り当て	ネットワーク	-	未構成	未構成	-
6	割り当て	条件	デバイスプラットフォーム	未構成	対象：Windows	必要に応じてプラットフォームを構成
7	アクセス制御	許可	-	●アクセス権の付与	●アクセス権の付与、■認証強度が必要：[プリフィックス]CBA	認証強度「[プリフィックス]CBA」を求める
8	ポリシーの有効化	-	-	レポート専用	オン	ポリシーを有効にする

デバイスプラットフォーム条件
今回の検証範囲では Windows にのみ証明書をインストールして動作確認する予定だったため、プラットフォームを指定しました。
(Windows 以外のアクセスに証明書を求められないようにするため)

なお、条件付きアクセスポリシーはブラックリスト方式のため、ポリシー対象外の条件下のアクセスを一律許可します。
上表の例のように証明書認証を求めるプラットフォームを明示的に指定する場合、指定したプラットフォーム以外のアクセス制御は別途設計してすり抜けを防止してください。

【構成のポイント (写真)】

3-8. 構成のポイント (写真) (折りたたみました。左端の ▶ をクリックして展開)

• 割り当て (対象)：CBA Required Users
  検証範囲を絞る場合はここでもセキュリティグループを指定、そうでなくテナント全体として適用する場合は「すべてのユーザー」を指定します。
  (ゲストや管理者への適用は証明書展開範囲に合わせて要検討)
  
• ターゲットリソース (対象)：すべてのリソース
  特定のアプリに対する接続要件として証明書を求める場合はアプリを指定、そうでなく広範囲で証明書を利用する場合は「すべてのリソース」を指定します。
  
• ターゲットリソース (対象外)：Microsoft Intune
  Intuneとの同期を阻害しないよう、Intuneサービスを証明書認証対象から除外³します。
  
• 条件 > デバイスプラットフォーム：Windows
  必要に応じてプラットフォームを構成します。(すり抜け注意)
  今回の検証範囲では Windows にのみ証明書をインストールして動作確認する予定だったため、プラットフォームを指定しました。
  
• アクセス制御 > 許可 > 認証強度が必要：[プリフィックス]CBA
  明示的に証明書認証を多要素認証方式として求めるため、事前に構成した認証強度をここで指定します。
  

以上で証明書ベースの認証を使うための準備が整いました。

3-9. [クライアント] サインイン動作確認

操作対象	作業概要	内容
クライアント	サインイン動作確認	証明書インストール済みの PC にてサインイン動作を確認します

• 参考：Microsoft Entra certificate-based authentication technical concepts、2026年3月4日閲覧

【動作確認ステップ】

3-9. 動作確認ステップ (折りたたみました。左端の ▶ をクリックして展開)

• ブラウザの検索バーに Office ポータルのアドレス (portal.office.com⁴) を入力します。
• Entra ID の認証画面が表示されるので、ユーザーIDとパスワードを入力します。
  (Entra 参加済みの PC でシームレス SSO が有効な環境では ID とパスワード入力は求められず SSO 状態になります)
• 多要素認証画面で証明書の選択を求められます。
  デバイスにインストール済みの証明書のうち、今回利用するユーザー証明書を選択し、[OK] をクリックします。
  
• 認証に成功すると、Office ポータル サインイン後の画面が表示されます。
  (2026年2、3月時点は Copilot Chat m365.cloud.microsoft 画面にリダイレクトされます。)
  

以上で証明書を使って認証できることを確認できました！

3-10. [Entra ID] サインインログ確認

操作対象	作業概要	内容
Entra ID	サインインログ確認	サインインログから、条件付きアクセスポリシー評価結果を確認します

• 参考：Microsoft Entra サインイン ログとは、2026年3月5日閲覧

先ほどの動作確認で証明書ベースの認証に成功した際のサインインログを確認したところ、以下の表示でした。

【確認ポイント】

3-10. 確認ポイント (折りたたみました。左端の ▶ をクリックして展開)

• [基本情報] タブ
  • 認証の要件：多要素認証
  • 状態：成功
    
• [認証の詳細]タブ
  • 認証ポリシーが適用されました - 条件付きアクセス - Authentication Strength(s)
    
• [条件付きアクセス]タブ
  • ポリシーの状態：有効
  • 結果：成功
  • デバイスのプラットフォーム：Windows 10 - 一致しました
  • 制御の許可：満足している - 認証強度が必要 - [プリフィックス]CBA ユーザーはこの認証強度を満たしました。
    
• [追加の詳細]タブ
  証明書関連と思われる情報が表示されている状態
  

以上、証明書を使った Entra ID 認証動作を確認することができました。

さいごに

当初、中間証明書もCRLも無い我が環境で CBA を検証できるのか半信半疑だったのですが、なんとか成功まで見届けることができました。

今回とてもシンプルな構成で動作を見ることができ、私自身 CBA に対する苦手意識を克服できました。

本検証を通して理解した認証方法・認証強度・条件付きアクセスポリシーの関わりは今後設計のインプットとして活かす予定です。

同じく Entra ID 担当としてサクッと CBA 動作を試したいけど、どう検証すれば... と悩んでる方がもしいらっしゃいましたら、本ブログが参考になると嬉しいです。

なお今回は深入りしませんでしたが、公開情報を見ているとバインディングの設定など認証方法設定時の構成で凝る余地がありそうです。
(参考：Set up Microsoft Entra certificate-based authentication - Step 3: Configure an authentication binding policy)

また、今回は証明書ベースの認証を多要素認証として構成しましたが、単一要素認証として構成することもできそうです。
(認証方法と認証強度のどちらも証明書ベースの認証の単一要素設定に対応しているため)

証明書ベースの認証は奥が深いですね✨✨
Android で検証してみた編も記事にしたいです！

関連記事
その後、無事 Android 検証版の記事を公開しました！

• 【検証用】ADCSでサクッとEntra ID証明書認証(CBA)を試す！【Android】

参考

※↑ Microsoft Security チャンネルの YouTube ビデオ "Configure Microsoft Certificate Based Authentication" (6分53秒)

1. VM スペック：2023年に初期構築した環境のため、当時は Windows Server 2022 が最新でした。サイズは多少 UI がもったりすることもありますが、機能観点での動作に気になる点は無いです。ただし、1人で使っている環境なので同時に動かしているのはMAX 3ユーザー、3クライアントほどです。 ↩

2. Entra 管理センターの画面推移：本記事上には検証時点 (2026年2月下旬) の画面推移を記載しております。(クラウド製品のため、今後変更になる可能性があります。なお、URLは変更が予定されています。) ↩ ↩² ↩³

3. Intuneとの同期を阻害しないよう、Intuneサービスを証明書認証対象から除外：Kernelさんがブログ化されている検証例のように、当初除外アプリを構成しないでおいたところ当方検証環境でもIntune同期に失敗する事象が発生しました。このため、「Microsoft Intune」を除外する対応をとっています。(参考：Cloud PKIを使ってEntra IDの証明書認証を試してみた) ↩ ↩²

4. portal.office.com は 2026年3月時点で利用可能な Office ポータルのアドレスです。将来的に変更になる場合があります。 ↩