認証Azure AD Certificate-Basedのトラブルシューティング

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

この記事では、認証に関する問題のトラブルシューティングに役立Certificate-Based説明します。

元の製品バージョン:  Azure Active Directory
元の KB 番号:   4032987

一般的な要件

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

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

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

    注意

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

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

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

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

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

正しく構成Azure AD確認する

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

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

    注意

    TrustedRootCertificateAuthority オブジェクトを Azure ADで作成すると、.CER ファイルは使用されません。 CrlDistributionPoin および DeltaCrlDistributionPoint の値は、ユーザーが CRL にアクセスできる web Azure ADによって手動で入力する必要があります。 発行された証明書内の CRL パスには、証明書からアクセスできる URL を含Azure AD。 また、中間認証エラーの原因となるキャッシュの遅延を回避するために、ダウンロードに 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 オブジェクトで次の値が正しく定義されていることを確認します。

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

    • *.ルート CA の CER は AuthorityType = RootAuthority としてリストする必要があります

    • *.中間 CA の CER は、次のようにリストする必要があります。

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

    注意

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

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

    Connect-msolService
    
     Get-MSOLDomainFederationSettings -DomainName contoso.com
    

    注意

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

    ドメインで PromptLoginBehavior を無効にするにはAzure ADコマンドを実行します。

    Set-MSOLDomainFederationSettings -domainname <domain> -PromptLoginBehavior Disabled
    

ADFS および Web アプリケーション プロキシの構成が正しく構成されていることを確認する

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

    注意

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

  2. ルート ファイル *.CER は、コンピューターの信頼されたルート 証明機関\Certificates コンテナー内にある必要 があります。 また、すべての中間 *.CER ファイルは、コンピューターの中間ルート証明機関 \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 を実行し 、[\中間証明機関\証明書] を展開し、[中間 CA 証明書] をダブルクリックします。
      2. [詳細] タブを クリックし、[ファイルにコピー] ボタンをクリック します。
      3. [ 次へ] を 2 回クリックし、ウィザードのすべての既定値を受け入れる。
      4. ファイル名と場所を指定し、[次へ] をクリック し、[完了] を クリックします
    2. 発行元 CA で、発行されたユーザー証明書の 1 つをデバイスにエクスポートします。 これを行うには、次の手順を実行します。
      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 クレーム プロバイダー信頼と id プラットフォーム証明書利用者信頼Microsoft Office 365 構成 する必要があります。 これらは、管理者特権のプロンプトで次の 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. 必要に応じて、イントラネット ユーザーからの認証を許可する場合は 、AllowedForPrimaryIntranetTrue に設定Certificate-Based設定することもできます。
    4. [詳細] タブを クリックし、[ファイルにコピー] ボタンをクリック します。
  6. クライアント デバイスと ADFS の間でも、クライアント デバイスと Web アプリケーション プロキシ サーバーの間で TCP ポート 49443 にアクセスできる必要があります。 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

    注意

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

詳細