Microsoft Entra Certificate-Based認証に関する問題のトラブルシューティング

  • [アーティクル]

iOS または Android デバイスのMicrosoft Entra IDの Certificate-Based 認証機能を使用すると、X.509 証明書を使用してシングル Sign-On (SSO) できます。 この機能を有効にすると、Exchange Online アカウントまたは Office モバイル アプリケーションに接続するときにユーザー名とパスワードを入力しなくても、アカウントまたはサービスにログインできます。

この記事では、Certificate-Based 認証の問題のトラブルシューティングに役立つ情報を提供します。

元の製品バージョン: Microsoft Entra ID
元の KB 番号: 4032987

一般的な要件

  • Certificate-Based 認証では、先進認証 (ADAL) を使用したフェデレーション環境のみがサポートされます。 1 つの例外は、マネージド アカウントで使用できるExchange OnlineのExchange ActiveSync (EAS) です。
  • ユーザーのプロファイルで発行されたユーザー証明書では、ユーザーのルーティング可能な電子メール アドレスを サブジェクトの別名に一覧表示する必要があります。 これは、UserPrincipalName または RFC822 形式のいずれかです。 Microsoft Entra ID RFC822 値をディレクトリ内のプロキシ アドレス属性にマップします。

Certificate-Based 認証がAzure portalで機能するかどうかを判断する

  1. Certificate-Based 認証をテストするために、デバイスからAzure portalを参照します。

    注:

    ユーザーが証明書の承認プロンプトを表示するには、接続を試す前にブラウザー キャッシュをクリアする必要があります。

  2. ユーザーのメール アドレスを入力します。 これにより、ADFS 認証ページにリダイレクトされます。

  3. パスワードを入力する代わりに (フォーム ベースの認証方法が ADFS で有効になっている場合)、[ X.509 証明書を使用してサインインする] を選択し、メッセージが表示されたらクライアント証明書の使用を承認します。

    デバイス上のブラウザー キャッシュをクリアした後に証明書の承認プロンプトが表示されない場合は、次の手順に従います。

    1. ユーザー証明書と発行元証明機関のルート証明書がデバイスにインストールされていることを確認します。
    2. ADFS/Web アプリケーション プロキシ サーバーで TCP ポート 49443 が開き、発行元証明機関の証明書チェーンがすべての ADFS/Web アプリケーション プロキシ サーバーにインストールされていることを確認します。

Microsoft Entra IDが正しく構成されているかどうかを判断する

  1. 次の PowerShell コマンドを実行して、Azure Active Directory PowerShell (プレビュー) モジュールをインストールします。

    Install-Module AzureAD

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

    注:

    Microsoft Entra IDで TrustedRootCertificateAuthority オブジェクトを作成すると、 内で定義されている CRL URL が表示されます。CER ファイルは使用されません。 CrlDistributionPoint と DeltaCrlDistributionPoint の値は、Microsoft Entra IDが CRL にアクセスできる Web の場所によって手動で設定する必要があります。 発行された証明書内の CRL パスには、Microsoft Entra IDにアクセスできる URL を含める必要はありません。 また、ダウンロードに 15 秒以上かかる大きな CRL は、中間認証エラーを引き起こす可能性のあるキャッシュ遅延を回避するために、Azure Storage などの高速リンクに配置する必要があります。

    $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

  3. 次のガイドラインに従って、 TrustedCertificateAuthority オブジェクトで次の値が正しく定義されていることを確認します。

    • すべての CrlDistributionPoint および DeltaCrlDistributionPoint URL は、クライアント デバイスと ADFS および Web アプリケーション プロキシ サーバーによってインターネットからアクセスできる必要があります。

    • *。ルート CA の CER は 、AuthorityType = RootAuthority として一覧表示する必要があります。

    • *。中間 CA の CER を次のように一覧表示する必要があります。

      AuthorityType = IntermediateAuthority
      AuthorityType = 0 = RootAuthority
      AuthorityType = 1 = IntermediateAuthority

    注:

    これらのオブジェクトを変更するには、「 証明機関の構成」を参照してください。

  4. 次のコマンドを実行して、ADFS 設定が PromptLoginBehavior に設定されていないことを確認します。 true。 それ以外の場合、一部のモダン アプリのユーザー名とパスワードの入力を求められます。

    Connect-msolService

     Get-MSOLDomainFederationSettings -DomainName contoso.com

    注:

    Azure AD および MSOnline PowerShell モジュールは、2024 年 3 月 30 日の時点で非推奨となりました。 詳細については、 非推奨の更新プログラムに関するページを参照してください。 この日付以降、これらのモジュールのサポートは、Microsoft Graph PowerShell SDK への移行支援とセキュリティ修正に限定されます。 非推奨のモジュールは、2025 年 3 月 30 日まで引き続き機能します。

    Microsoft Entra ID (旧称 Azure AD) と対話するには、Microsoft Graph PowerShell に移行することをお勧めします。 移行に関する一般的な質問については、移行に関する FAQ を参照してください。 メモ： バージョン 1.0.x の MSOnline では、2024 年 6 月 30 日以降に中断が発生する可能性があります。

    注:

    これは、一部の最新のアプリが prompt=login を要求のMicrosoft Entra IDに送信するためです。 Microsoft Entra IDは、ADFS 要求のこれを wauth=usernamepassworduri に変換します (これは ADFS にユーザー名/パスワード認証を行うように指示します)、wfresh=0 (SSO 状態を無視して新しい認証を行うように ADFS に指示します)。 ユーザーが証明書ベースの認証を使用する必要がある場合は、 PromptLoginBehavior を False に設定する必要があります。

    Microsoft Entra ドメインで PromptLoginBehavior を無効にするには、次のコマンドを実行します。

    Set-MSOLDomainFederationSettings -domainname <domain> -PromptLoginBehavior Disabled

ADFS と Web アプリケーション プロキシの構成が正しく構成されているかどうかを判断する

  1. Certificate-Based 認証には ADFS 2012R2 以降のバージョンが必要であり、Web アプリケーション プロキシを使用する必要があります。

    注:

    サードパーティの Web アプリケーション プロキシの使用は、MS-ADFSPIP プロトコル ドキュメント内のすべての MUST をサポートしていない限りサポートされません。

  2. ルート *.CER ファイルは、コンピューターの 信頼されたルート証明機関\Certificates コンテナー内にある必要があります。 また、すべての中間 *.CER ファイルは、コンピューターの 中間ルート証明機関\証明書 コンテナーに存在する必要があります。 これを確認するには、 を実行 certlm.msc するか、管理者特権のコマンド プロンプトで次 certutil.exe のコマンドを実行します。

    certutil -verifystore root

    certutil -verifystore CA**

  3. クライアント デバイス、ADFS サーバー、および Web アプリケーション プロキシは、中間 CA * に存在する CRL エンドポイントを解決できる必要があります。CER と、デバイス上のユーザー プロファイルに対して発行されたユーザー証明書。

    ADFS サーバーと Web アプリケーション プロキシがこれらを解決できることを確認するには、次の手順を実行します。

    1. 中間 CA *をエクスポートします。Cer：
      1. コンピューター証明書ストアを表示します。 これを行うには、 certlm.msc を実行し、 \中間証明機関\Certificates を展開し、中間 CA 証明書をダブルクリックします。
      2. [ 詳細 ] タブをクリックし、[ ファイルにコピー ] ボタンをクリックします。
      3. [ 次へ ] を 2 回クリックし、ウィザードのすべての既定値をそのまま使用します。
      4. ファイル名と場所を指定し、[ 次へ] をクリックし、[完了] をクリック します。
    2. 発行元 CA で、デバイスに発行されたいずれかのユーザー証明書をエクスポートします。 これを行うには、次の手順を実行します。

      1. certsrv.msc を実行し、[発行済み証明書] ノードを選択します。

      2. [ 発行済み共通名] 列で、接続できないユーザーに発行された証明書を見つけます。

      3. 証明書をダブルクリックし、[ 詳細 ] タブをクリックして証明書を * にエクスポートします。CER ファイル。

        注:

        複数の証明書がユーザーに発行された場合は、[ 詳細 ] タブで証明書のシリアル番号を見つけて、デバイス上の証明書と一致することを確認します。

      4. PSEXEC.EXEをダウンロードし、 *と共に psexec.exe をコピーします。中間 CA とユーザーからすべての ADFS および Web アプリケーション プロキシ サーバーへの CER ファイル。

      5. SYSTEM セキュリティ コンテキストで新しいコマンド プロンプトを開きます。 これを行うには、各サーバーの管理者特権のコマンド プロンプトを開き、次のコマンドを実行します。

        psexec -s -i -d cmd.exe

      6. 新しいコマンド プロンプトで、次のコマンドを実行して、CRL にアクセスできるかどうかを判断します。

        certutil.exe -verify -urlfetch SubCA.cer > %computername%_%username%_SubCA.txt

        certutil.exe -verify -urlfetch usercert.cer > %computername%_%username%_usercert.txt

      7. 出力で、----------------証明書 CDP ---------------- セクションをチェックし、すべてのエンドポイントを解決できるかどうかを判断します。

      8. ADFS サーバーが HTTP URL を解決できない場合は、ADFS が実行されているグループ管理サービス アカウントがファイアウォールとプロキシ経由でアクセスできることを確認します。 Web アプリケーション プロキシ サービスはネットワーク サービスで実行されるため、ComputerName$ アカウントにはファイアウォールとプロキシを介したアクセスが必要です。

  4. serialNumber と発行者のパススルー要求は、Active Directory 要求プロバイダー信頼とMicrosoft Office 365 ID プラットフォーム証明書利用者信頼用に構成する必要があります。 これらは、管理者特権のプロンプトで次の PowerShell コマンドを実行することで、ADFS サーバーから取得できます。

    Get-AdfsClaimsProviderTrust -Name "Active Directory"
@RuleTemplate = "PassThroughClaims"
@RuleName = "<serialnumber AD for cert based auth>"
c:[Type ==
http://schemas.microsoft.com/ws/2008/06/identity/claims/serialnumber]
  => issue(claim = c);
@RuleTemplate = "PassThroughClaims"
@RuleName = "<Issuer AD for cert based auth>"
c:[Type ==
http://schemas.microsoft.com/2012/12/certificatecontext/field/issuer]
  => issue(claim = c);

    Get-AdfsRelyingPartyTrust -Name "Microsoft Office 365 Identity Platform"
@RuleTemplate = "PassThroughClaims"
@RuleName = "<serialnumber RP for cert based auth>"
c:[Type ==
http://schemas.microsoft.com/ws/2008/06/identity/claims/serialnumber]
  => issue(claim = c);
@RuleTemplate = "PassThroughClaims"
@RuleName = "<Issuer RP for cert based auth>"
c:[Type ==
http://schemas.microsoft.com/2012/12/certificatecontext/field/issuer]
  => issue(claim = c);

  5. 証明書認証を使用するほとんどのデバイスはエクストラネット (企業ネットワーク外) に配置される可能性があるため、必要に応じて、エクストラネットまたはイントラネットに対してのみ Certificate-Based 認証を有効にすることができます。 いずれかのオプションまたは両方のオプションに対して "証明書認証" メソッドが有効になっているかどうかを判断するには、管理者特権の PowerShell コマンド プロンプトから次のコマンドレットを実行します。

    Get-AdfsAuthenticationProvider:

----------Output sample----------

AdminName                          : Certificate Authentication
AllowedForPrimaryExtranet          : True
AllowedForPrimaryIntranet          : True
AllowedForAdditionalAuthentication : True
AuthenticationMethods              : {urn:ietf:rfc:2246, urn:oasis:names:tc:SAML:1.0:am:X509-PKI,
                                     urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient,
                                     urn:oasis:names:tc:SAML:2.0:ac:classes:X509...}
Descriptions                       : {}
DisplayNames                       : {}
Name                               : CertificateAuthentication
IdentityClaims                     : {}
IsCustom                           : False
RequiresIdentity                   : False
    1. [証明書認証] という名前の AdminName エントリを見つけます。
    2. AllowedForPrimaryExtranet が True に設定されていることを確認します。
    3. 必要に応じて、イントラネット ユーザーからの認証を Certificate-Based する場合は、 AllowedForPrimaryIntranet を True に 設定することもできます。
    4. [ 詳細 ] タブをクリックし、[ ファイルにコピー ] ボタンをクリックします。

  6. TCP ポート 49443 は、クライアント デバイスと ADFS の間、またクライアント デバイスと Web アプリケーション プロキシ サーバーの間でもアクセスできる必要があります。 TCP 49443 が ADFS サーバーと Web アプリケーション プロキシで ADFS をリッスンし、バインドしていることを確認するには、次のコマンドを実行します。

    netsh http show urlacl > %computername%_49443.txt

    TCP ポート 49443 にアクセスできる場合は、次のような出力が表示されます。

    Reserved URL: https://<URL>:49443/adfs/
User: NT SERVICE\adfssrv
Listen: Yes
Delegate: Yes
SDDL: D:(A;;GA;;;S-1-5-80-2246541699-21809830-3603976364-117610243-975697593)

  7. クライアント デバイスで、CertificateTransport エンドポイントに接続してみてください。 たとえば、 には次の URL を Contoso.com使用します。

    https://sts.contoso.com:49443/adfs/services/trust/2005/certificatetransport

    注:

    エンドポイントがアクセス可能でリッスンしている場合、接続試行は応答を待機している間に無期限にスピンする必要があります。

詳細

お問い合わせはこちらから

質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティ サポートにお問い合わせください。 Azure フィードバック コミュニティに製品フィードバックを送信することもできます。