次の方法で共有

Microsoft Entra 証明書ベースの認証に関する問題のトラブルシューティング

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

この記事では、証明書ベースの認証に関する問題のトラブルシューティングに役立つ情報を提供します。

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

一般的な要件

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

Azure portal で証明書ベースの認証が機能するかどうかを判断する

  1. デバイスから Azure ポータル を参照して、証明書ベースの認証をテストします。

    Note

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

  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 属性を正しい値に設定します。

    Note

    Microsoft Entra ID で TrustedRootCertificateAuthority オブジェクトを作成すると、.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

    Note

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

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

    Connect-msolService

     Get-MSOLDomainFederationSettings -DomainName contoso.com

    Note

    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 日以降に中断が発生する可能性があります。

    Note

    これは、一部の最新のアプリが要求で microsoft Entra ID に prompt=login を送信するためです。 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. 証明書ベースの認証には ADFS 2012R2 以降のバージョンが必要であり、Web アプリケーション プロキシを使用する必要があります。

    Note

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

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

    certutil -verifystore root

    certutil -verifystore CA**

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

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

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

      1. certsrv.msc を実行し、Issued Certificates ノードを選択します。

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

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

        Note

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

      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. 出力で、 ---------------- Certificate CDP ---------------- セクションを確認し、すべてのエンドポイントを解決できるかどうかを判断します。

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

  4. serialNumberとissuerのパススルー要求は、Active Directoryクレーム プロバイダー信頼とMicrosoft Office 365 Identity Platform 証明書利用者信頼用に構成する必要があります。 これらは、管理者特権のプロンプトで次の 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. 証明書認証を使用するほとんどのデバイスはエクストラネット (企業ネットワーク外) に配置される可能性があるため、必要に応じてエクストラネットまたはイントラネットに対してのみ証明書ベースの認証を有効にすることができます。 いずれかのオプションまたは両方のオプションに対して "証明書認証" メソッドが有効になっているかどうかを確認するには、管理者特権の 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. Certificate Authentication という名前の AdminName エントリ見つけます。
    2. AllowedForPrimaryExtranet が True に設定されていることを確認します。
    3. 必要に応じて、イントラネット ユーザーからの証明書ベースの認証が必要な場合は AllowedForPrimaryIntranet を True に設定することもできます。
    4. [ Details ] タブをクリックし、[ Copy to file ] ボタンをクリックします。

  6. TCP ポート 49443 は、クライアント デバイスと ADFS の間、またクライアント デバイスと Web アプリケーション プロキシ サーバーの間でもアクセスできる必要があります。 TCP 49443 が ADFS サーバーと Web アプリケーション プロキシで ADFS をリッスンし、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 エンドポイントへの接続を試みます。 たとえば、 Contoso.comには次の URL を使用します。

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

    Note

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

詳細

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

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