Azure AD 証明書ベースの認証を構成する方法

Azure Active Directory (Azure AD) 証明書ベースの認証 (CBA) を使用すると、組織はアプリやブラウザーのサインイン時に Enterprise 公開キー基盤 (PKI) によって作成された X.509 証明書を使用して認証を許可または要求するように Azure AD テナントを構成できます。 この機能により、組織は x.509 証明書を使用したフィッシングに強い最新のパスワードレス認証を採用することができます。

サインイン時に、パスワードを入力する代わりに証明書で認証するオプションもユーザーに表示されます。 一致する証明書がデバイスに複数存在する場合、ユーザーは使用するものを選択できます。 証明書がユーザー アカウントに対して検証され、成功すればサインインとなります。

Office 365 Enterprise および US Government プランのテナントに Azure AD CBA を構成して使用するには、次の手順に従います。 公開キー基盤 (PKI) が構成済みである必要があります。

前提条件

次の前提条件が満たされていることを確認します。

  • Azure AD に少なくとも 1 つの証明機関 (CA) と任意の中間 CA が構成されている。
  • ユーザーは、Azure AD に対して認証を行うために、クライアント認証を目的としたユーザー証明書 (テナントで構成された信頼済み公開キー基盤から発行されたもの) にアクセスできること。
  • 各 CA には、インターネットに接続する URL から参照できる証明書失効リスト (CRL) が必要です。 信頼された CA に CRL が構成されていない場合、Azure AD で CRL チェックは実行されません。ユーザー証明書の失効も機能せず、認証はブロックされません。

重要

PKI がセキュリティで保護され、容易に侵害されないことを確認します。 侵害が発生した場合、攻撃者はクライアント証明書を作成して署名し、テナント内のすべてのユーザー (オンプレミスから同期されたユーザーとクラウド専用ユーザーの両方) を侵害する可能性があります。 しかし、強力なキー保護戦略に加え、HSM アクティブ化カードや成果物を安全に保管するためのトークンなど、その他の物理的および論理的コントロールにより、外部攻撃者や内部脅威による PKI 整合性の侵害を防ぐための多重防御を実現できます。 詳細については、PKI の保護に関する記事をご覧ください。

Note

PKI を評価するときは、証明書の発行ポリシーと適用を確認することが重要です。 前述のように、Azure AD 構成に証明機関 (CA) を追加すると、それらの CA によって発行された証明書で Azure AD のすべてのユーザーを認証できます。 このため、CA が証明書の発行をいつどのように許可されるか、また、再利用可能な識別子をどのように実装するかを検討することが重要です。 管理者が、ユーザーの認証に特定の証明書のみを使用できるようにする必要がある場合、管理者は高アフィニティ バインドのみを使用して、特定の証明書でのみユーザーを認証できるという、より高いレベルの保証を実現する必要があります。 詳細については、高アフィニティ バインドに関するページを参照してください。

Azure AD CBA の構成とテストの手順

Azure AD CBA を有効にする前に行う必要がある、いくつかの構成手順。 まず、管理者は、ユーザー証明書を発行する信頼された CA を構成する必要があります。 次の図に示すとおり、ロールベースのアクセス制御を使用して、最小特権の管理者だけが変更を加える必要があるようにしています。 CA を構成できるのは、特権認証管理者ロールのみです。

必要に応じて、証明書を単一要素または多要素認証にマップする認証バインドを構成し、証明書フィールドをユーザー オブジェクトの属性にマップするユーザー名バインドを構成することもできます。 認証ポリシー管理者は、ユーザー関連の設定を構成できます。 すべての構成が完了したら、テナントで Azure AD CBA を有効にします。

Azure Active Directory 証明書ベースの認証を有効にするために必要な手順の図。

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

CA は、Azure portal または PowerShell を使用して構成できます。

Azure portal を使用して証明機関を構成する

Azure portal で証明書ベースの認証を有効にして、ユーザー バインドを構成するには、次の手順を実行します。

  1. Azure portal に全体管理者としてサインインします。

  2. [Azure Active Directory]>[セキュリティ] をクリックします。

    証明機関のスクリーンショット。

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

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

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

    3. 失効したすべての証明書を含む CA のベース CRL の HTTP 公開 URL を設定します。 URL が設定されていない場合、失効した証明書を使用した認証が失敗しません。

    4. Delta CRL URL (最後のベース CRL の公開後に失効したすべての証明書を含む CRL の HTTP 公開 URL) を設定します。

    5. [追加] をクリックします。

      証明機関ファイルをアップロードする方法のスクリーンショット。

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

  5. [列] をクリックして列を追加または削除します。

PowerShell を使用して証明機関を構成する

信頼された CA に対してサポートされている CRL 配布ポイント (CDP) は 1 つのみです。 CDP には HTTP URL のみを指定できます。 オンライン証明書状態プロトコル (OCSP)、またはライトウェイト ディレクトリ アクセス プロトコル (LDAP) の URL はサポートされていません。

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

  • 証明書の公開部分 ( .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
    }

構成には、Azure Active Directory PowerShell バージョン 2 を使用できます。

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

  2. Azure AD モジュール バージョン 2.0.0.33 以降をインストールします。

        Install-Module -Name AzureAD –RequiredVersion 2.0.0.33
    

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

接続する

テナントとの接続を確立するには、Connect-AzureAD コマンドレットを使用します。

    Connect-AzureAD

取得

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

    Get-AzureADTrustedCertificateAuthority

追加

信頼された証明機関を作成するには、New-AzureADTrustedCertificateAuthority コマンドレットを使用し、crlDistributionPoint 属性に正しい値を設定します。

    $cert=Get-Content -Encoding byte "[LOCATION OF THE CER FILE]"
    $new_ca=New-Object -TypeName Microsoft.Open.AzureAD.Model.CertificateAuthorityInformation
    $new_ca.AuthorityType=0
    $new_ca.TrustedCertificate=$cert
    $new_ca.crlDistributionPoint="<CRL Distribution URL>"
    New-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation $new_ca

AuthorityType

  • ルート証明機関を示すには、0 を使用します
  • 中間または発行元の証明機関を示すには 1 を使用します

crlDistributionPoint

CRL をダウンロードし、CA 証明書と CRL 情報を比較して、前の PowerShell 例の crlDistributionPoint 値が、追加する CA に対して有効であることを検証できます。

次の表と図は、CA 証明書の情報とダウンロードした CRL の属性との対応関係を表しています。

CA 証明書の情報 = ダウンロードされた CRL 情報
サブジェクト = 発行者
サブジェクト キー識別子 = 機関キー識別子 (KeyID)

CA 証明書と CRL 情報を比較します。

ヒント

前の例の crlDistributionPoint の値は、CA の証明書失効リスト (CRL) がある場所の http です。 これは、いくつかの場所にあります。

  • CA から発行された証明書の CRL 配布ポイント (CDP) 属性。

発行元の CA が Windows Server である場合:

  • 証明機関 Microsoft 管理コンソール (MMC) の CA の [プロパティ]
  • CA (certutil -cainfo cdp を実行)。 詳細については、「certutil」を参照してください。

詳細については、「証明書の失効プロセスについて」を参照してください。

[削除]

信頼された証明機関を削除するには、Remove-AzureADTrustedCertificateAuthority コマンドレットを使用します。

    $c=Get-AzureADTrustedCertificateAuthority
    Remove-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation $c[2]

Remove-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation $c[0] に変更することで、0 番目の要素を削除するようにコマンドを変更できます。

変更

信頼された証明機関を変更するには、Set-AzureADTrustedCertificateAuthority コマンドレットを使用します。

    $c=Get-AzureADTrustedCertificateAuthority
    $c[0].AuthorityType=1
    Set-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation $c[0]

手順 2: テナントで CBA を有効にする

Azure portal で証明書ベースの認証を有効にするには、次の手順を実行します。

  1. 認証ポリシー管理者として Azure portal にサインインします。

  2. Azure Active Directory を選択し、左側のメニューから [セキュリティ] を選択します。

  3. [管理] で、[認証方法]>[証明書ベースの認証] を選択します。

  4. [基本][はい] を選択して CBA を有効にします。

  5. CBA は、対象となる一連のユーザーに対して有効にできます。

    1. [すべてのユーザー] をクリックすると、すべてのユーザーが有効になります。
    2. [ユーザーの選択] をクリックすると、選択したユーザーまたはグループが有効になります。
    3. [+ ユーザーの追加] をクリックして特定のユーザーとグループを選択します。
    4. [選択] をクリックして追加します。

    CBA を有効にする方法のスクリーンショット。

テナントで証明書ベースの認証が有効になると、証明書を使用してサインインするオプションがテナント内のすべてのユーザーに表示されます。 X.509 証明書を使用して認証できるのは、証明書ベースの認証が有効になっているユーザーのみです。

Note

ネットワーク管理者は、login.microsoftonline.com に加えて、顧客のクラウド環境の certauth エンドポイントへのアクセスを許可する必要があります。 certauth エンドポイントで TLS 検査を無効にして、TLS ハンドシェイクの一部としてクライアント証明書の要求が成功するようにします。

手順 3: 認証バインド ポリシーを構成する

認証バインド ポリシーは、認証の強度を単一要素か多要素のいずれかに決定するのに役立ちます。 管理者は、既定値を単一要素から多要素に変更したり、証明書の発行者のサブジェクトまたはポリシー OID フィールドにマッピングして、カスタム ポリシー ルールを構成したりすることができます。

Azure portal で Azure AD CBA を有効にしてユーザー バインドを構成するには、次の手順を実行します。

  1. 認証ポリシー管理者として Azure portal にサインインします。

  2. Azure Active Directory を選択し、左側のメニューから [セキュリティ] を選択します。

  3. [認証方法]>[ポリシー] をクリックします。

  4. [管理] で、[認証方法]>[証明書ベースの認証] を選択します。

    認証ポリシーのスクリーンショット。

  5. [構成] をクリックして、認証バインドとユーザー名バインドを設定します。

  6. 保護レベル属性の既定値は、単一要素認証です。 [多要素認証] を選択して既定値を多要素認証に変更します。

    Note

    カスタム ルールを追加しない場合は、既定の保護レベル値が有効になります。 カスタム ルールを追加した場合は、代わりにルール レベルで定義された保護レベルが適用されます。

    既定のポリシーを MFA に変更する方法のスクリーンショット。

  7. また、カスタム認証バインド規則を設定して、クライアント証明書の保護レベルの決定に役立てることもできます。 これは、証明書の発行者のサブジェクトまたはポリシー OID フィールドを使用して構成できます。

    認証バインド規則によって、証明書属性 (発行者またはポリシー OID) が値にマップされ、その規則に対して既定の保護レベルが選択されます。 複数のルールを作成できます。

    カスタム ルールを追加するには、[ルールの追加] をクリックします。

    ルールを追加する方法のスクリーンショット。

    証明書の発行者別のルールを作成するには、[証明書の発行者] をクリックします。

    1. リスト ボックスから [証明書の発行者識別子] を選択します。

    2. [多要素認証] をクリックします。

      多要素認証ポリシーのスクリーンショット。

    ポリシー OID でルールを作成するには、[ポリシー OID] をクリックします。

    1. [ポリシー OID] の値を入力します。

    2. [多要素認証] をクリックします。

      ポリシー OID へのマッピングのスクリーンショット。

  8. [OK] をクリックして、任意のカスタム ルールを保存します。

手順 4: ユーザー名バインド ポリシーを構成する

ユーザー名のバインド ポリシーは、ユーザーの証明書を検証するために役立ちます。 既定では、証明書のプリンシパル名をユーザー オブジェクトの UserPrincipalName にマップしてユーザーを特定します。 管理者は、既定値をオーバーライドし、カスタム マッピングを作成できます。

ユーザー名のバインドを構成する方法を確認するには、「ユーザー名のバインドについて」を参照してください。

重要

ユーザー名バインド ポリシーでユーザー オブジェクトの onPremisesUserPrincipalName 属性などの同期された属性を使用する場合は、Active Directory Administrators 特権を持つユーザーはだれでも、Azure AD の onPremisesUserPrincipalName 値に影響を与える変更を加えることができます。これには、同期されたユーザー アカウントに対する委任された管理特権、または Azure AD Connect サーバーに対する管理者権限を持つユーザーが含まれます。

  1. X.509 証明書フィールドのいずれかを選択してユーザー属性の 1 つとバインドし、ユーザー名バインドを作成します。 ユーザー名のバインド順序は、バインドの優先順位を表します。 1 つ目は優先順位が最も高い、などです。

    ユーザー名バインド ポリシーのスクリーンショット。

    指定の X.509 証明書フィールドが証明書に見つかっても、Azure AD がその値を使用するユーザー オブジェクトを見つけられない場合、認証に失敗します。 Azure AD でフォールバックが行われ、一覧にある次のバインドが試されます。

  2. [保存] をクリックして変更を保存します。

最終的な構成は次の画像のようになります。

最終的な構成のスクリーンショット。

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

このセクションでは、証明書とカスタム認証バインド規則をテストする方法について説明します。

証明書のテスト

構成の最初のテストとして、デバイス上のブラウザーを使用して MyApps ポータルへのサインインを試みる必要があります。

  1. ユーザー プリンシパル名 (UPN) を入力します。

    ユーザー プリンシパル名のスクリーンショット。

  2. [次へ] をクリックします。

    証明書を使用したサインインのスクリーンショット。

    電話によるサインインや FIDO2 などの他の認証方法を有効にしている場合、ユーザーには別のサインイン画面が表示される場合があります。

    代替サインインのスクリーンショット。

  3. [証明書を使用してサインイン] を選択します。

  4. クライアント証明書ピッカー UI で正しいユーザー証明書を選択し、[OK] をクリックします。

証明書ピッカー UI のスクリーンショット。

  1. ユーザーは MyApps ポータルにサインインするはずです。

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

  • ユーザー証明書がテスト デバイスにプロビジョニングされている。
  • Azure AD が、信頼された CA で正しく構成されている。
  • ユーザー名バインドが正しく構成され、ユーザーが見つかり認証される。

カスタム認証バインド規則のテスト

強力な認証を検証するシナリオを見てみましょう。 2 つの認証ポリシー ルールを作成します。1 つは発行者のサブジェクトを使用して単一要素認証を満たし、もう 1 つはポリシー OID を使用して多要素認証を満たすものです。

  1. 保護レベルを単一要素認証とし、CA のサブジェクト値を値とする発行者サブジェクト ルールを作成します。 次に例を示します。

    CN = WoodgroveCA

  2. ポリシー OID ルールを作成し、保護レベルを多要素認証とし、値を証明書内のポリシー OID のいずれかに設定します。 たとえば、1.2.3.4 です。

    ポリシー OID ルールのスクリーンショット。

  3. 条件付きアクセス - MFA の要求に関する記事の手順に従って、ユーザーに多要素認証を要求するための条件付きアクセス ポリシーを作成します。

  4. MyApps ポータルに移動します。 UPN を入力し、[次へ] をクリックします。

    ユーザー プリンシパル名のスクリーンショット。

  5. [証明書を使用してサインイン] を選択します。

    証明書を使用したサインインのスクリーンショット。

    電話によるサインインや FIDO2 などの他の認証方法を有効にしている場合、ユーザーには別のサインイン画面が表示される場合があります。

    代替サインインのスクリーンショット。

  6. クライアント証明書を選択し、[証明書情報] をクリックします。

    クライアント ピッカーのスクリーンショット。

  7. 証明書が表示され、発行者とポリシー OID の値を確認できます。 発行者のスクリーンショット。

  8. ポリシー OID の値を表示するには、[詳細] をクリックします。

    認証の詳細のスクリーンショット。

  9. クライアント証明書を選択し、[OK] をクリックします。

  10. 証明書のポリシー OID は、構成された値 1.2.3.4 と一致しており、多要素認証を満たすことになります。 同様に、証明書の発行者は、構成された値 CN=WoodgroveCA と一致しており、単一要素認証を満たすことになります。

  11. ポリシー OID ルールは発行者ルールよりも優先されるので、証明書は多要素認証を満たすことになります。

  12. ユーザーの条件付きアクセス ポリシーは MFA を要求しており、証明書は多要素を満たすため、ユーザーはアプリケーションに対して認証されます。

Microsoft Graph API を使用して Azure AD CBA を有効にする

Graph API を使用して CBA を有効にし、ユーザー名バインドを構成するには、次の手順を実行します。

Note

次の手順では、米国政府クラウドでは使用できない Graph エクスプローラーを使用します。 米国政府のクラウド テナントでは、Postman を使用して Microsoft Graph のクエリをテストできます。

  1. Microsoft Graph エクスプローラーに移動します。

  2. [Sign into Graph Explorer] (Graph エクスプローラーにサインイン) をクリックして、テナントにサインインします。

  3. 手順に従って、Policy.ReadWrite.AuthenticationMethod の委任されたアクセス許可に同意します。

  4. 次のように、すべての認証方法を取得します。

    GET  https://graph.microsoft.com/v1.0/policies/authenticationmethodspolicy
    
  5. 次のように、x509Certificate の認証方法の構成を取得します。

    GET https://graph.microsoft.com/v1.0/policies/authenticationmethodspolicy/authenticationMethodConfigurations/X509Certificate
    
  6. 既定では、x509Certificate の認証方法は無効になっています。 ユーザーが証明書を使用してサインインできるようにするには、更新操作によって認証方法を有効にし、認証とユーザー名バインドのポリシーを構成する必要があります。 ポリシーを更新するには、PATCH 要求を実行します。

    要求本文:

    PATCH https: //graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/x509Certificate
    Content-Type: application/json
    
    {
        "@odata.type": "#microsoft.graph.x509CertificateAuthenticationMethodConfiguration",
        "id": "X509Certificate",
        "state": "enabled",
        "certificateUserBindings": [
            {
                "x509CertificateField": "PrincipalName",
                "userProperty": "onPremisesUserPrincipalName",
                "priority": 1
            },
            {
                "x509CertificateField": "RFC822Name",
                "userProperty": "userPrincipalName",
                "priority": 2
            }, 
            {
                "x509CertificateField": "PrincipalName",
                "userProperty": "certificateUserIds",
                "priority": 3
            }
        ],
        "authenticationModeConfiguration": {
            "x509CertificateAuthenticationDefaultMode": "x509CertificateSingleFactor",
            "rules": [
                {
                    "x509CertificateRuleType": "issuerSubject",
                    "identifier": "CN=WoodgroveCA ",
                    "x509CertificateAuthenticationMode": "x509CertificateMultiFactor"
                },
                {
                    "x509CertificateRuleType": "policyOID",
                    "identifier": "1.2.3.4",
                    "x509CertificateAuthenticationMode": "x509CertificateMultiFactor"
                }
            ]
        },
        "includeTargets": [
            {
                "targetType": "group",
                "id": "all_users",
                "isRegistrationRequired": false
            }
        ]
    }
    
  7. 応答コード 204 No content が表示されます。 GET 要求を再実行して、ポリシーが正しく更新されていることを確認します。

  8. ポリシーを満たす証明書でサインインして、構成をテストします。

次の手順