Microsoft Entra ID の証明書ベース認証をフェデレーションで始めましょう

フェデレーションを使用した証明書ベースの認証 (CBA) を使用すると、Microsoft Entra ID は、Exchange オンライン アカウントを次に接続するときに、Windows、Android、または iOS デバイス上のクライアント証明書を使用してユーザーを認証できます。

• Microsoft Outlook や Microsoft Word などの Microsoft モバイル アプリケーション
• Exchange ActiveSync (EAS) クライアント

この機能を構成すると、モバイル デバイス上の特定のメールおよび Microsoft Office アプリケーションにユーザー名とパスワードの組み合わせを入力する必要がなくなります。

このトピック:

• Office 365 Enterprise、Business、Education、US Government プランのテナントのユーザーに対して CBA を構成して使用する手順について説明します。
• 公開キー 基盤 (PKI) と AD FS が既に構成されていることを前提としています。

要求事項

フェデレーションを使用して CBA を構成するには、次のステートメントが true である必要があります。

• フェデレーションを使用する CBA は、ブラウザー アプリケーション、先進認証を使用するネイティブ クライアント、または MSAL ライブラリのフェデレーション環境でのみサポートされます。 1 つの例外は Exchange Online (EXO) の Exchange Active Sync (EAS) であり、フェデレーション アカウントとマネージド アカウントに使用できます。 フェデレーションを必要とせずに Microsoft Entra CBA を構成するには、「 Microsoft Entra 証明書ベースの認証を構成する方法」を参照してください。
• ルート証明機関と中間証明機関は、Microsoft Entra ID で構成する必要があります。
• 各証明機関には、インターネットに接続する URL を介して参照できる証明書失効リスト (CRL) が必要です。
• Microsoft Entra ID で少なくとも 1 つの証明機関が構成されている必要があります。 関連する手順は、「 証明機関の構成」 セクションにあります。
• Exchange ActiveSync クライアントの場合、クライアント証明書には、[サブジェクトの別名] フィールドの [プリンシパル名] または [RFC822 Name] の値に、Exchange Online のユーザーのルーティング可能な電子メール アドレスが必要です。 Microsoft Entra ID は、RFC822 値をディレクトリ内のプロキシ アドレス属性にマップします。
• クライアント デバイスは、クライアント証明書を発行する少なくとも 1 つの証明機関にアクセスできる必要があります。
• クライアント認証用のクライアント証明書がクライアントに発行されている必要があります。

手順 1: デバイス プラットフォームを選択する

最初の手順として、関心のあるデバイス プラットフォームの場合は、次の内容を確認する必要があります。

• Office モバイル アプリケーションのサポート
• 特定の実装要件

関連情報は、次のデバイス プラットフォームに存在します。

• アンドロイド
• iOS

手順 2: 証明機関を構成する

Microsoft Entra ID で証明機関を構成するには、証明機関ごとに次のものをアップロードします。

• 証明書のパブリック部分 ( .cer 形式)
• 証明書失効リスト (CRL) が存在する、インターネットに接続する URL

証明機関のスキーマは次のようになります。

    class TrustedCAsForPasswordlessAuth
    {
       CertificateAuthorityInformation[] certificateAuthorities;
    }

    class CertificateAuthorityInformation

    {
        CertAuthorityType authorityType;
        X509Certificate trustedCertificate;
        string crlDistributionPoint;
        string deltaCrlDistributionPoint;
        string trustedIssuer;
        string trustedIssuerSKI;
    }

    enum CertAuthorityType
    {
        RootAuthority = 0,
        IntermediateAuthority = 1
    }

構成には、 Microsoft Graph PowerShell を使用できます。

1. Windows PowerShell を管理者特権で起動します。

2. Microsoft Graph PowerShell をインストールします。

       Install-Module Microsoft.Graph
   

構成の最初の手順では、テナントとの接続を確立する必要があります。 テナントへの接続が確立されるとすぐに、ディレクトリに定義されている信頼された証明機関をレビュー、追加、削除、および変更できます。

接続する

テナントとの接続を確立するには、 Connect-MgGraph を使用します。

    Connect-MgGraph

取得

ディレクトリで定義されている信頼された証明機関を取得するには、 Get-MgOrganizationCertificateBasedAuthConfiguration を使用します。

    Get-MgOrganizationCertificateBasedAuthConfiguration

CA を追加、変更、または削除するには、Microsoft Entra 管理センターを使用します。

1. Microsoft Entra 管理センターにグローバル管理者としてサインインします。

2. Entra ID>Identity Secure Score>認証局に移動します。

3. CA をアップロードするには、[ アップロード] を選択します。

   1. CA ファイルを選択します。

   2. CA がルート証明書の場合は [はい] を選択し、それ以外の場合は [いいえ] を選択します。

   3. [証明書失効リスト URL] には、失効したすべての証明書を含む CA ベース CRL のインターネットに接続する URL を設定します。 URL が設定されていない場合、失効した証明書を使用した認証は失敗しません。

   4. [デルタ証明書失効リストの URL] には、最後のベース CRL が発行されて以降に失効したすべての証明書を含む CRL のインターネットに接続する URL を設定します。

   5. [] を選択し、[] を追加します。

      

4. CA 証明書を削除するには、証明書を選択し、[削除] を選択します。

5. [列] を選択して列を追加または削除します。

手順 3: 失効を構成する

クライアント証明書を失効させるために、Microsoft Entra ID は、証明機関の情報の一部としてアップロードされた URL から証明書失効リスト (CRL) をフェッチし、キャッシュします。 CRL の最後の発行タイムスタンプ (有効日 プロパティ) は、CRL がまだ有効であることを確認するために使用されます。 CRL は定期的に参照されて、リストに含まれる証明書へのアクセスは無効になります。

即時の失効が必要な場合 (たとえば、ユーザーがデバイスを紛失した場合) は、ユーザーの認証トークンを無効にできます。 承認トークンを無効にするには、Windows PowerShell を使用して、この特定のユーザーの StsRefreshTokensValidFrom フィールドを設定します。 アクセスを取り消す各ユーザーの StsRefreshTokensValidFrom フィールドを更新する必要があります。

失効が維持されるようにするには、CRL の 有効日 を StsRefreshTokensValidFrom によって設定された値の後の日付に設定し、問題の証明書が CRL にあることを確認する必要があります。

次の手順では、 StsRefreshTokensValidFrom フィールドを設定して承認トークンを更新および無効化するプロセスについて説明します。

# Authenticate to Microsoft Graph
Connect-MgGraph -Scopes "User.Read.All"

# Get the user
$user = Get-MgUser -UserPrincipalName "test@yourdomain.com"

# Get the StsRefreshTokensValidFrom property
$user.StsRefreshTokensValidFrom

設定する日付は、現在より後の日付にする必要があります。 日付が将来でない場合、 StsRefreshTokensValidFrom プロパティは設定されません。 日付が将来の場合、 StsRefreshTokensValidFrom は現在の時刻に設定されます (Set-MsolUser コマンドで示される日付ではありません)。

手順 4: 構成をテストする

証明書のテスト

最初の構成テストとして、デバイス上のブラウザーを使用して Outlook Web Access または SharePoint Online にサインインする必要があります。

サインインが成功した場合、次のことがわかります。

• ユーザー証明書がテスト デバイスにプロビジョニングされている
• AD FS が正しく構成されている

Office モバイル アプリケーションのテスト

1. テスト デバイスに、Office モバイル アプリケーション (OneDrive など) をインストールします。
2. アプリケーションを起動します。
3. ユーザー名を入力し、使用するユーザー証明書を選択します。

正常にサインインしている必要があります。

Exchange ActiveSync クライアント アプリケーションのテスト

証明書ベースの認証を使用して Exchange ActiveSync (EAS) にアクセスするには、クライアント証明書を含む EAS プロファイルをアプリケーションで使用できる必要があります。

EAS プロファイルには、次の情報が含まれている必要があります。

• 認証に使用するユーザー証明書

• EAS エンドポイント (たとえば、outlook.office365.com)

EAS プロファイルは、Microsoft Intune などのモバイル デバイス管理 (MDM) を使用するか、デバイスの EAS プロファイルに証明書を手動で配置することで、デバイスに構成して配置できます。

Android での EAS クライアント アプリケーションのテスト

1. 前のセクションの要件を満たす EAS プロファイルをアプリケーションで構成します。
2. アプリケーションを開き、メールが同期していることを確認します。

次のステップ

Android デバイスでの証明書ベースの認証に関する追加情報。

iOS デバイスでの証明書ベースの認証に関する追加情報。