2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

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

2
Last updated at Posted at 2026-05-15

ADCS を使った手軽な環境でサクッと Entra ID 証明書ベースの認証 (certificate-based authentication, CBA) を試すことができましたので、本記事に検証ステップをまとめます。

今回は Android 編です!

関連記事
先日 Windows クライアントから CBA を利用する検証記事を公開しました!

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

  • ADCS を使った簡易な検証環境で、Android 端末から Entra ID の証明書ベース認証 (CBA) が実際に動作するところまでを確認します。
  • Android へのユーザー証明書の配置・インストール方法や、Windows 環境を流用する際の設計・構成ポイントを具体的な手順で整理しています。
  • BYOD をはじめとする Intune が管理しないモバイル端末経由のアクセスをセキュアに認証する現実的なアプローチをまとめています。

目次

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

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

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

1. 動作例

Android を使うエンドユーザー目線の動作を以下に掲載します。

Microsoft 365 利用時に証明書認証を求める場合

  • Teams を起動します。
    Screenshot_20260311-114535.png

  • 初回サインイン時はID・パスワードを入力します。(検証時はサインイン済みでした)
    多要素認証としてサインインする方法の指定を求められるので、「このデバイスの証明書」を選択して「続行」をクリックします。
    Screenshot_20260311-114545.png

  • インストール済み証明書一覧より、Entra ID認証に利用したいユーザー証明書を選択し、「選択」をクリックします。
    Screenshot_20260311-114550.png

  • サインイン成功! 以後、Teams を利用できます。
    Screenshot_20260311-114557.png

以後、本記事には本動作を実現するためのアーキテクチャと構成を記載します。

2. 検証環境

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

2-1. 構成図

前回 Windows の CBA に利用した環境を流用しています。

今回は Android から CBA を使うため Android が追加になり、また Android に証明書を配置するのに一度物理端末を経由させました。

CBAfAndroid-dev-env-architecture.png

Android への証明書配置方法
当初 SharePoint Online に証明書ファイルをアップロードし、Android にダウンロードしましたが、正しい秘密キーをいくら入力してもエラーになってしまう事象が発生しました。
(Teams 経由方式ではこのエラーから抜け出せず...)
Screenshot_20260306-141321.png

同じ証明書ファイルを一度物理端末に配置し、USB 経由で Android にファイル転送し配置したところ、証明書インストールに成功しました!

2-2. 構成要素

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

# 環境 機能 備考
1 サーバー ADDS ドメイン環境を構成
2 サーバー Entra Connect Windows Server AD のドメインを Entra ID に同期
3 サーバー ADCS 証明書テンプレートを作成・発行、ルート証明書をエクスポート
4 クライアント Windows 11 (VM) ドメイン環境に接続可能なクライアント、証明書のインストール・エクスポートに利用
5 クライアント Windows 11 (物理) USB を経由し Android に証明書ファイルを転送するのに利用
6 クライアント Android CBA 動作確認に利用するクライアント
7 クラウド Entra ID 条件付きアクセスを利用するため、P1 ライセンス
8 クラウド Teams 条件付きアクセスにて証明書要求するのを動作確認するため、Entra ID が認証する任意のクラウドアプリを用意

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

前回検証時と同じ構成です。
繰り返しとなってしまうため記載は割愛します。

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

Android の CBA 検証をするのに、予想外でしたが結果的に Windows VM/物理 を発動することになり、今回検証で計 3つのクライアントを使いました。

今回、ADCS から発行した証明書を Android にインストールするのがひとつの挑戦でした。
ChatGPT と壁打ちし、以下の手順を踏むことにしました。

  1. ドメイン参加済みの Windows に証明書をインストールする
  2. Windows から証明書を秘密鍵付きでエクスポートする
  3. Android に証明書をどうにかして配置する (ここはファジー)
  4. Android に証明書をインストールする

3. の Android 証明書配置ですが、試しに手ごろなクラウドストレージとして SharePoint Online を活用したところ、ダウンロードした証明書をインストールするときに秘密鍵パスワードが通らない事象に阻まれました。 (どうやらファイルが壊れてしまうようです。) このため、USB 経由で配置する方法に切り替えました。
←1. で利用したドメイン参加済みの Windows がたまたま VM だったため、USB 接続ができるよう物理端末を経由することにしました。

これにより、最終的に以下のステップを踏むことになりました。

  1. ドメイン参加済みの Windows VM に証明書をインストールする
  2. Windows VM から証明書を秘密鍵付きでエクスポートする
  3. Windows VM から Windows 物理端末に証明書をコピペ配置する
  4. Windows 物理端末から USB を経由して Android に証明書を配置する
  5. Android に証明書をインストールする

CBAfAndroid-certinstallation.png

本記事には成功したパターンを記載します🙌🎉

クラウド環境 (#7, 8)

サーバー環境と同じく、クラウド環境も前回検証時と同じ構成です。
繰り返しとなってしまうため記載は割愛します。

3. 検証ステップ

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

CBAfAndroid-dev-exstep.png

Windows 用 CBA 環境を流用する場合
すでに設定済みの以下は新規対応不要です。

  • 3-6. [サーバー] ルート証明書エクスポート
  • 3-7. [Entra ID] ルート証明書アップロード
  • 3-9. [Entra ID] 認証方法設定
  • 3-10. [Entra ID] 認証強度設定

ユーザー証明書テンプレートも Windows と Android で同じものを利用することができるのですが、前回 Windows 検証時に作成したテンプレートでは秘密キーのエクスポートをブロックする構成にしていたため、今回再作成しました。

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

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

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

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

前回 Windows 向けに CBA 検証した際に作成した証明書テンプレートでは「Allow private key to be exported」(秘密鍵のエクスポートを許可する) 設定項目をオフにしていました。
今回は Android に証明書インストールすることを想定して、当該設定項目をオンにしてテンプレート作成します。

Android にインストール可能な証明書テンプレート作成
Android では秘密鍵付きの証明書が必要だそうなので、秘密鍵のエクスポートを許可する証明書テンプレートを作成します。

なお、今回複製元とする証明書テンプレートですが、前回作成した [Entra CBA] 証明書テンプレートを利用しました。

[Entra CBA] テンプレートは既定の User テンプレートを基にしています

【作業ステップ】

3-1. 作業ステップ (折りたたみました。左端の ▶ をクリックして展開)
  • サーバーにサインインし、[Windows] キー + [R] キーをクリックして [ファイル名を指定して実行] を起動します。

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

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

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

    General タブの設定
    当方検証環境ではテンプレート名を「Entra CBA for Android」としました。

    • Template display name: Entra CBA for Android
    • Template name: EntraCBAforAndroid

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

    02.png

  • [Request Handling] タブにて、[Allow private key to be exported] (秘密鍵のエクスポートを許可する) をオン (✅) にします。
    03.png

  • [Subject Name] タブ にて、[E-mail name] をオフ (☐)、[User principal name (UPN)] をオン (✅) にします。

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

    04.png

  • [Extensions] タブ にて **[Application Policies] 配下に [Client Authentication] が存在していること (既定値) を確認します。[Edit] > [Add]/[Remove] から [Smart Card Logon] など他の要素を追加したり削除したりすることも可能です。今回の検証では [Client Authentication] 以外を削除しました。
    07.png

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

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

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

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

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

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

以上で証明書テンプレートの作成は完了です。

ちなみにですが今回作成した証明書テンプレートから要求するユーザー証明書は Android でも Windows でも利用可能でした。(検証済み)

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

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

先ほど ADCS 上で発行した証明書を、ドメイン参加済みの Windows VM から要求しインストールします。

Windows サインインユーザー
本検証では最終的に Android から Teams など Microsoft 365 サービスにサインインし証明書認証動作を確認します。
Android からアクセス確認を実施する際に利用するユーザーで Windows にもサインインし、証明書をインストールする必要があります。(ユーザー証明書のため)

【作業ステップ】

3-2. 作業ステップ (折りたたみました。左端の ▶ をクリックして展開)
  • Windows VM にサインインし、[Windows] キー + [R] キーをクリックして [ファイル名を指定して実行] を起動します。

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

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

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

    01.png

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

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

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

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

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

Certificate - Current User (certmgr.msc) は、次工程でユーザー証明書をエクスポートする際にも利用します。

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

3-3. [クライアント (Win VM)] ユーザー証明書エクスポート

操作対象 作業概要 内容
クライアント (Win VM) ユーザー証明書エクスポート 先ほどインストールした証明書をファイルにエクスポートします

別クライアント環境での利用を可能にするため、先ほど Windows VM にインストールした証明書をエクスポートします。

【作業ステップ】

3-3. 作業ステップ (折りたたみました。左端の ▶ をクリックして展開)
  • 先ほどと同様に Windows VM にサインインし、[Windows] キー + [R] キー > [ファイル名を指定して実行] より certmgr.msc を実行して、[Certificate - Current User] コンソールを開きます。

  • [Certificates - Current User] を展開して [Personal] > [Certificate] 下に表示される 「Entra CBA for Android」テンプレートのユーザー証明書をダブルクリックします。(プロパティを開きます。)
    06.png

  • ユーザー証明書のプロパティが表示されるので、[Details] タブ > [Copy to File...] をクリックします。
    07.png
    08.png

  • [Certificate Export Wizard] (証明書エクスポート ウィザード) が表示されるので、[Export Private Key] 画面にて [Yes, export the private key] を選択して [Next] をクリックします。
    01.png

  • [Export File Format] 画面にて、[Personal Information Exchange - PKCS #12 (.PFX)] を選択し、写真のように設定して [Next] をクリックします。
    02.png

  • [Security] 画面にて [Password] を選択して任意の文字列を入力し、[Encryption] として [AES 256-SHA256] を選択し、[Next] をクリックします。
    03_bk.png

  • [File to Export] 画面にて、ファイル名を含むパスを指定して [Next] をクリックします。

    証明書ファイル名
    当検証環境では「EntraCBAusercert2.pfx」にしました。
    (別の名を設定する場合は適宜本記事の記載や写真を読み替えてください。)

    04.png

  • [Completing the Certificate Export Wizard] 画面にて設定値を確認し、[Finish] をクリックします。
    05.png

以上で証明書ファイルのエクスポート作業は完了です。

[Certificate Export Wizard] で指定したフォルダパス下に保存された証明書ファイルを、Windows VM から Windows 物理端末に配置します。

Windows VM から Windows 物理端末へのファイル配置
今回はクリップボードを経由したコピー&ペーストで配置しました。
同一ドメイン配下のデバイスであればファイルサーバーなど共有領域を経由しての配置という手段もありそうです。

次のステップにて、さらにこの証明書ファイルを Windows 物理端末から Android に配置します。

3-4. [クライアント (Win 物理, Android)] 証明書ファイル転送

操作対象 作業概要 内容
クライアント (Win 物理, Android) 証明書ファイル転送 証明書を Android に配置します

【作業ステップ】

3-4. 作業ステップ (折りたたみました。左端の ▶ をクリックして展開)
  • Android を Windows 物理端末に USB ケーブルで接続します。

  • Android 側で自動的に [USB の設定] 画面が表示されるので、[USB の接続用途] 欄で「ファイル転送 / Android Auto」を選択します。
    Screenshot_20260311-104010.png

  • この状態で Windows 物理端末側でファイルエクスプローラーを開くと、Android のストレージが見える状態になっているので、[内部共有ストレージ] > [Download] を開きます
    スクリーンショット 2026-03-12 190310.png
    スクリーンショット 2026-03-12 190316.png

  • Windows 物理端末上の証明書ファイルドラッグアンドドロップで Android 端末の [Download] フォルダ下に配置します。
    スクリーンショット 2026-03-12 190321.png

以上で証明書ファイル転送作業は完了です。

3-5. [クライアント (Android)] ユーザー証明書インストール

操作対象 作業概要 内容
クライアント (Android) ユーザー証明書インストール 証明書を Android にインストールします

【作業ステップ】

3-5. 作業ステップ (折りたたみました。左端の ▶ をクリックして展開)
  • Android にて [設定] アプリを起動し、画面をスクロールダウンして [セキュリティ] をクリックします。
    Screenshot_20260306-145552.png

  • [セキュリティ] 画面下部の [セキュリティの詳細設定] をクリックします。
    Screenshot_20260306-145558.png

  • [セキュリティの詳細設定] 画面中央の [暗号化と認証情報] をクリックします。
    Screenshot_20260306-145602 1.png

  • [暗号化と認証情報] 画面中央の [証明書のインストール] をクリックします。
    Screenshot_20260306-145606.png

  • [証明書のインストール] 画面中央の [VPN とアプリユーザー証明書] をクリックします。
    Screenshot_20260306-145609.png

  • 先ほど [Download] フォルダ配下に配置した証明書ファイルをクリックします。
    Screenshot_20260306-145613 1.png

  • [証明書を抽出] ポップアップ画面が表示されるので、証明書エクスポート時に設定したパスワードを入力し、[OK] をクリックします。
    Screenshot_20260306-145626.png

  • [この証明書の名前を指定してください] ポップアップ画面が表示されるので、直感的に分かりやすい文字列を指定し、[OK] をクリックします。

    証明書の名前
    当検証環境では「EntraCBAforAndroid」にしました。
    (別の名を設定する場合は適宜本記事の記載や写真を読み替えてください。)

    Screenshot_20260311-104049.png

  • Android 端末の画面下部に [ユーザー証明書をインストールしました] と表示されます。
    Screenshot_20260311-104054.png

以上で Android 端末への証明書インストール作業は完了です。

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

操作対象 作業概要 内容
サーバー ルート証明書エクスポート ADCS にてルート証明書をエクスポートし、ファイルとして保存します
※前回実施済みの場合はスキップ

今回利用するユーザー証明書は、前回検証時と同じ Certificate Authority から発行しており、ルート証明書が同じです。
このため、改めて Entra ID にルート証明書をアップロードする必要がありませんでした。
(前回アップロードしたもので今回も動作しました。)
09.png

ご参考までに、新規の検証の場合は以下手順でまず ADCS からルート証明書をエキスポートします。

前回記事の手順を再掲します ↓↓

【作業ステップ】

3-6. 作業ステップ (折りたたみました。左端の ▶ をクリックして展開)
  • サーバーにサインインし、[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] をクリックします。
    01.png
  • [Certificate Export Wizard] の [Export File Format] 画面にて、[Base-64 encoded X.509 (.CER)] が選択されていること (既定値) を確認して、[Next] をクリックします。
    02.png
  • [Certificate Export Wizard] の [File to Export] 画面にて、ファイル名を含むパスを指定して [Next] をクリックします。
    03.png
  • [Certificate Export Wizard] の [Completing the Certificate Export Wizard] 画面にて設定値を確認し、[Finish] をクリックします。
    04.png
ルート証明書エクスポートは以上です。

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

操作対象 作業概要 内容
Entra ID ルート証明書アップロード 先ほど保存したルート証明書ファイルを Entra ID にアップロードします
※前回実施済みの場合はスキップ

先述の通り今回検証では前回とルート証明書が共通のため、Entra ID に再度アップロード不要で既存のものを使いまわすことができました。

ご参考までに、新規の検証の場合は以下手順で先ほど ADCS からエキスポートしたルート証明書を Entra ID にアップロードします。

前回記事の手順を再掲します ↓↓

【作業ステップ】

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

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

03.png

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

3-8. [Entra ID] (任意) グループ メンバー追加

操作対象 作業概要 内容
Entra ID (任意) グループ メンバー追加 CBA の利用対象グループのメンバーに Android を利用するユーザーを追加します

今回 Android を利用するユーザーは、前回 Windows 検証時と異なるユーザーを利用しました。
当方検証環境では CBA の利用範囲をセキュリティグループで絞っているため、当該セキュリティグループのメンバーとして Android ユーザーを追加しました。

スクリーンショット 2026-03-18 105111.png

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

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

操作対象 作業概要 内容
Entra ID 認証方法設定 「証明書ベースの認証」方法を有効化し、利用可能な状態にします
※前回実施済みの場合はスキップ

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

当方環境では、前回検証時に「CBA Enabled Users」セキュリティグループ向けに有効化しました。以降はこのグループのメンバーをメンテナンスしていけばいいため、今回の検証に際して認証方法設定自体を更新する必要はありません

ご参考までに、新規検証の場合は以下手順でまず証明書ベースの認証方法を有効化してください。

前回記事の手順を再掲します ↓↓

【作業ステップ】

3-9. 作業ステップ (折りたたみました。左端の ▶ をクリックして展開)
  • Microsoft Entra 管理センター (entra.microsoft.com)1 にて、[Entra ID] 配下の [認証方法] > [ポリシー] > [証明書ベースの認証] をクリックします。
    スクリーンショット 2026-03-05 141430.png

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

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

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

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

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

    スクリーンショット 2026-03-05 141443.png

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

    • 既定の認証強度:多要素
      スクリーンショット 2026-03-05 141454.png
  • [証明書ベースの認証] の設定画面にて [構成] タブ下で設定を変更すると以下の警告メッセージが表示されるので、[確認しました] > [保存] をクリックします。

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

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

    20 - コピー.png

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

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

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

通常条件付きアクセスポリシーで多要素認証を要求すると、対象ユーザに対して有効な認証方式のなかからユーザーが任意で選択した方法で多要素認証を実施・検証することになります。

今回は任意の多要素ではなく、証明書認証による多要素を必須にすることを仮想要件とします。これを実現するため、事前に認証強度を構成し、その認証強度を条件付きアクセスポリシーにて求めます

認証強度の設定では、証明書を多要素として指定するほか、その証明書の発行者も指定します。
今回の検証では、前回の検証と同じ Certificate Authority を利用しており証明書の発行者が同じです。このため、新規で認証強度を構成する必要が無く既存の構成を流用できました。

ご参考までに、新規検証の場合証明書の発行者が新規の場合以下手順でまず認証強度を作成してください。

前回記事の手順を再掲します ↓↓

【作業ステップ】

3-10. 作業ステップ (折りたたみました。左端の ▶ をクリックして展開)
  • Microsoft Entra 管理センター (entra.microsoft.com)1 にて、[Entra ID] 配下の [認証方法] > [認証強度] > [新しい認証強度] をクリックします。

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

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

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

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

    スクリーンショット 2026-03-05 142235.png

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

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

    スクリーンショット 2026-03-05 142248.png

  • [新しい認証強度] を [作成] します。
    スクリーンショット 2026-03-05 142338.png

認証強度の設定は以上です。

3-11. [Entra ID] 条件付きアクセスポリシー更新

操作対象 作業概要 内容
Entra ID 条件付きアクセスポリシー更新 証明書ベースの多要素認証を求める条件付きアクセスポリシーの対象プラットフォームに Android を追加します

先ほどの認証強度 (証明書認証) をアクセス許可条件として求める条件付きアクセスポリシーを用意します。

当方検証環境では、前回検証時と同じ認証強度を利用するため、条件付きアクセスポリシーも前回検証時と同じポリシーを利用しました。
ただし、前回検証時のポリシーではデバイスプラットフォームを Windows に限定していたため、対象に Android を追加し更新しました。
(ポリシー名にプラットフォームを入れるのが好みなので、ポリシー名も合わせて更新しました。)

ご参考までに、今回の検証で利用したポリシーの値は以下です。

【構成例 (表)】

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

前回検証時と同じポリシーを使いました。

今回更新したのは以下です(どちらも Android を追加):

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

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

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

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

3-11. 構成のポイント (写真) (折りたたみました。左端の ▶ をクリックして展開)
  • ポリシー名:Require CBA (Win/Android)
    直感的に分かりやすいポリシー名を設定します。個人的には、Microsoftのテンプレートに倣って制御内容を明記し、一工夫として対象プラットフォームを括弧書きするのが好きです。
    スクリーンショット 2026-03-23 111040 - コピー.png

  • 割り当て (対象):CBA Required Users
    検証範囲を絞る場合はここでもセキュリティグループを指定、そうでなくテナント全体として適用する場合は「すべてのユーザー」を指定します。
    (ゲストや管理者への適用は証明書展開範囲に合わせて要検討)
    スクリーンショット 2026-03-23 111040.png

  • ターゲットリソース (対象):すべてのリソース
    特定のアプリに対する接続要件として証明書を求める場合はアプリを指定、そうでなく広範囲で証明書を利用する場合は「すべてのリソース」を指定します。
    スクリーンショット 2026-03-23 111049.png

  • ターゲットリソース (対象外):Microsoft Intune
    Intuneとの同期を阻害しないよう、Intuneサービスを証明書認証対象から除外2します。
    スクリーンショット 2026-03-23 111057.png

  • 条件 > デバイスプラットフォーム:Windows、Android
    必要に応じてプラットフォームを構成します。(すり抜け注意)
    今回の検証範囲では Windows と Android にのみ証明書をインストールして動作確認する予定だったため、プラットフォームを指定しました。
    スクリーンショット 2026-03-23 111104.png

  • アクセス制御 > 許可 > 認証強度が必要:[プリフィックス]CBA
    明示的に証明書認証を多要素認証方式として求めるため、事前に構成した認証強度をここで指定します。
    スクリーンショット 2026-03-23 111113.png

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

3-12. [クライアント (Android)] サインイン動作確認

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

Microsoft 365 サービスに接続する適当なアプリとして、Teams を使いました。

証明書ベースの認証方式および条件付きアクセスポリシーの対象となる「CBA Required Users」グループのメンバー(かつ Windows VM に証明書インストール作業時のサインインユーザー) で Teams にサインインし、動作を確認します。

事前作業:アプリのインストール
Google Play ストアから Microsoft Teams をインストールしました。
また、当環境では Intune アプリ保護ポリシーも利用しているため、ブローカーアプリである Microsoft Authentication アプリも同じく Google Play ストアからインストールしています。

以下、「1. 動作例」の再掲となりますが今回の環境で確認した動作をまとめます。

【動作確認ステップ】

3-12. 動作確認ステップ (折りたたみました。左端の ▶ をクリックして展開)
  • Teams を起動します。
    Screenshot_20260311-114535.png

  • 初回サインイン時はID・パスワードを入力します。(検証時はサインイン済みでした)
    多要素認証としてサインインする方法の指定を求められるので、「このデバイスの証明書」を選択して「続行」をクリックします。
    Screenshot_20260311-114545.png

  • インストール済み証明書一覧より、Entra ID認証に利用したいユーザー証明書を選択し、「選択」をクリックします。
    Screenshot_20260311-114550.png

  • サインイン成功! 以後、Teams を利用できます。
    Screenshot_20260311-114557.png

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

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

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

【確認ポイント】

3-13. 確認ポイント (折りたたみました。左端の ▶ をクリックして展開)
  • [基本情報] タブ

    • 認証の要件:多要素認証
    • 状態:成功
      スクリーンショット 2026-03-11 143628 - コピー.png
  • [デバイス情報] タブ

    • オペレーティングシステム:Android
      スクリーンショット 2026-03-11 143650 - コピー.png
  • [認証の詳細] タブ

    • 認証ポリシーが適用されました - 条件付きアクセス - Authentication Strength(s)
    • 成功:true
    • 結果の詳細:MFA requirement satisfied by certificate based authentication
    • 用件:[プリフィックス]CBA   ← ※認証強度
      スクリーンショット 2026-03-11 143734 - コピー.png
  • [条件付きアクセス] タブ

    • ポリシーの状態:有効
    • 結果:成功
    • デバイスのプラットフォーム:Android - 一致しました
    • 制御の許可:満足している - 認証強度が必要 - [プリフィックス]CBA ユーザーはこの認証強度を満たしました。
      スクリーンショット 2026-03-11 143828 - コピー.png
  • [追加の詳細] タブ
    証明書関連と思われる情報が表示されている状態
    スクリーンショット 2026-03-11 143852 - コピー.png

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

さいごに

担当案件にて Android 端末の証明書認証を検討していることが、今回 CBA の検証をはじめた背景でした。
Android に自己証明書をインストールできるのか、どうやって? というところからが挑戦でしたが、なんとか動きを見届けることができ嬉しいです。

CBA の公開情報では Android もサポート内と記載ありますが、こうして手元で動作を見て得る安心に勝るものはないと感じます。

また、前回 Windows 向けに用意した証明書用設定を今回流用しながら Android に対象範囲を広げられたことで、案外拡張性のある設計が可能ということも分かりました。

なお今回の検証では Android 端末上に直接証明書を格納しましたが、Yubikey のようなハードウェア トークンに証明書を格納して CBA を利用することもできるそうです。
特に BYOD シナリオでは MDM 不在でなかなか組織的に証明書を展開することが難しいので、その場合にはハードウェア トークンがよさそうですね!
(参考:Microsoft Entra certificate-based authentication on Android devices、2026年3月27日閲覧)

ハードウェア トークンをお持ちの方はぜひ試してみてください!! (そして結果を共有してください~🙏✨ (強欲))

余談ですが、そもそも CBA が GA された背景にはアメリカのサイバーセキュリティに関する大統領令があるそうです。
すべてのデバイス プラットフォームでフィッシング耐性のある MFA を要求するように、という令 (とても具体的) だそうで Ignite 2022 で CBA が GA され、これに続いて 2023年に Android・iOS にサポートが拡充されました。
(参考:モバイル デバイスでの Azure AD 証明書ベースの認証が GA となりました!、2026年3月27日閲覧)

CBA は単に Intune 不在 (Entra ID が組織デバイスをネイティブに判別できない) デバイスの救済手段になるというだけではなく、実は認証としてもフィッシング耐性があり優れたオプションであると分かります。

CBA を使ってセキュリティ高めていきましょう!💪🛡️✨

参考

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

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

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

2
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?