フェデレーションを使用した Microsoft Entra ID の証明書ベースの認証の使用を開始する

フェデレーションを使用した証明書ベースの認証 (CBA) では、Windows、Android または iOS デバイス上で、Exchange Online アカウントを以下のものに接続する際に、クライアント証明書を使用した Microsoft Entra ID によって認証を行えます。

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

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

このトピックの内容と前提条件:

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

必要条件

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

• フェデレーションを使用した 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 名の値のいずれかで、Exchange Online のユーザーのルーティング可能なメール アドレスが必要になります。 Microsoft Entra ID は、ディレクトリ内のプロキシ アドレス属性に RFC822 の値をマップします。
• クライアント デバイスから、クライアント証明書を発行する証明機関の少なくとも 1 つにアクセスできる必要があります。
• クライアント認証用のクライアント証明書が、クライアントに対して発行されている必要があります。

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

まず、対象のデバイス プラットフォームについて、次の項目を確認する必要があります。

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

関連情報については、次のリンク先をご覧ください。

• Android
• 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

Retrieve

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

    Get-MgOrganizationCertificateBasedAuthConfiguration

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

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

2. [保護]>[更に表示]>[Security Center] (または[ID セキュリティ スコア]) >[証明機関] の順に移動します。

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 を使用してこの特定のユーザーの StsRefreshTokenValidFrom フィールドを設定します。 アクセスを無効にする各ユーザーの StsRefreshTokenValidFrom フィールドを更新する必要があります。

失効状態が継続していることを確認するには、CRL の発効日を StsRefreshTokenValidFrom で設定した値より後の日付に設定し、対象の証明書が CRL にあることを確認する必要があります。

次の手順は、 StsRefreshTokenValidFrom フィールドを設定することで認証トークンを更新し、無効にするプロセスを簡単に示したものです。

1. PowerShell に接続する:

   Connect-MgGraph
   

2. ユーザーの現在の StsRefreshTokensValidFrom 値を取得します。

           $user = Get-MsolUser -UserPrincipalName test@yourdomain.com`
           $user.StsRefreshTokensValidFrom
   

3. 現在のタイムスタンプと等しいユーザーの新しい StsRefreshTokensValidFrom 値を構成します。

           Set-MsolUser -UserPrincipalName test@yourdomain.com -StsRefreshTokensValidFrom ("03/05/2021")
   

設定する日付は、現在より後の日付にする必要があります。 日付を現在より後の日付にしないと、 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 デバイス上の証明書ベースの認証に関する追加情報。