Azure Active Directory と Office 365 AD FS のトラブルシューティングします。

重要: このサポート技術情報 (以下「KB」) は、翻訳者による翻訳の代わりに、マイクロソフト機械翻訳システムによって翻訳されたものです。マイクロソフトは、お客様に、マイクロソフトが提供している全ての KB を日本語でご利用いただけるように、翻訳者による翻訳 KB に加え機械翻訳 KB も提供しています。しかしながら、機械翻訳の品質は翻訳者による翻訳ほど十分ではありません。誤訳や、文法、言葉使い、その他、たとえば日本語を母国語としない方が日本語を話すときに間違えるようなミスを含んでいる可能性があります。マイクロソフトは、機械翻訳の品質、及び KB の内容の誤訳やお客様が KB を利用されたことによって生じた直接または間接的な問題や損害については、いかなる責任も負わないものとします。マイクロソフトは、機械翻訳システムの改善を継続的に行っています。

英語版 KB:3079872
この資料では、ワークフローの Azure Active Directory または Office 365 のフェデレーション ユーザーの認証に関する問題のトラブルシューティングについて説明します。
現象
  • フェデレーション ユーザーにログオンできない Office 365 または Microsoft Azure クラウド専用のマネージ ユーザー domainxx.onmicrosoft.com のユーザー プリンシパル名サフィックスを持つが、問題なくログオンできる場合でも。
  • Active Directory フェデレーション サービス (AD FS) へのリダイレクトや、STS は、フェデレーション ユーザーには発生しません。または、「ページを表示できません」のエラーが発生します。
  • AD FS を使用して認証しようとするとき、ブラウザーに証明書に関連する警告が表示されます。これは、証明書の検証が失敗することや、証明書が信頼されていないことを示しています。
  • "不明な認証方法] 以上のエラー AuthnContext がサポートされていないことを示します。AD FS または STS のレベルから Office 365 にリダイレクトした場合でも、エラーは。
  • AD FS では、「アクセスが拒否されました」エラーがスローされます。
  • AD FS は、サイトへのアクセスに問題があることを示すエラーをスローします。これには、参照 ID 番号が含まれます。
  • ユーザーは AD FS レベルで資格情報を繰り返し要求します。
  • フェデレーション ユーザーは、外部ネットワークから認証できないか、外部のネットワーク ルート (たとえば、Outlook) に必要なアプリケーションを使用するとき。
  • フェデレーション ユーザーは、AD FS のトークン署名証明書が変更された後にログオンできません。
  • フェデレーション ユーザーが Microsoft Azure で Office 365 にサインインすると、「すみません、ですが問題ある署名する」エラーが発生します。このエラーには、エラー コード 8004786 C、80041034、80041317、80043431、80048163、80045C 06、8004789A、または不正な要求が含まれています。

ワークフローのトラブルシューティング
  1. アクセス https://login.microsoftonline.com、フェデレーション ユーザーのログイン名 (を入力し、誰か@使用例.com).ログイン ボックスからフォーカスを削除するのにはタブをクリックすると後、は、「リダイレクト」とし、ページの変更の状態が、Active Directory フェデレーション サービス (AD FS) のサインインにリダイレクトしているかどうかを確認します。

    リダイレクトが発生した場合、次のページを参照してください。

    手順 1 のスクリーン ショット
    1. リダイレクトは発生しませんし、同じページにパスワードを入力するプロンプトが表示されたら、する場合は、Azure Active Directory (AD)、または Office 365 を認識できないというユーザーまたはユーザーのドメインをフェデレーションするを意味します。Azure AD の間でフェデレーションの信頼があるかどうかを確認するか、Office 365 と、AD FS サーバーの実行、 Get msoldomain Azure AD PowerShell のコマンドレットです。ドメインをフェデレーションすると、その認証プロパティは次のスクリーン ショットに示すように「連合、」として表示されます。

      フェデレーション ドメインに関する手順します。
    2. リダイレクトが発生した場合は、サインイン用の AD FS サーバーにリダイレクトされないかどうか、AD FS サービス名に解決される、正しい ip アドレスと TCP ポート 443 では、その IP に接続できるかどうかを確認してください。

      ドメインは「連合」として表示されている場合は、次コマンドを実行して、フェデレーションの信頼に関する情報を取得します。
      Get-MsolFederationProperty -DomainName <domain>
      Get-MsolDomainFederationSettings -DomainName <domain>
      URI、URL、および Office 365 または Azure AD によって構成されているフェデレーション パートナーの証明書を確認してください。
  2. AD FS にリダイレクトした後、ブラウザーは、証明書の信頼に関連するエラーをスロー可能性があり、一部のクライアントおよびデバイスにできないこともあります AD FS と SSL セッションを確立します。手動でこの問題を解決するには、以下の手順を実行します。
    1. クライアントに提示される AD FS サービス通信の証明書が AD FS で構成されている 1 つと同じであることを確認します。

      スクリーン ショットについては、ステップ A

      理想的には、AD FS サービス通信の証明書は、AD FS サービスで SSL トンネルを確立するときにクライアントに提供される SSL 証明書と同じにする必要があります。

      AD FS 2.0。

      • -> 最初のサイトの既定の IIS に証明書をバインドします。
      • AD FS スナップインを使用して、サービス通信の証明書と同じ証明書を追加します。

      AD FS 2012 R2: の

      • AD FS スナップインを使用して、または、 追加 adfscertificate サービス通信の証明書を追加するコマンドです。
      • 使用して、 セット adfssslcertificate 同じ証明書の SSL バインドを設定するコマンドです。

    2. AD FS サービス通信証明書がクライアントによって信頼されていることを確認します。
    3. SNI: 対応していないクライアントは、2-12 R2 の AD FS または WAP と SSL セッションを確立しようとしている、試行が失敗します。この場合、SNI でないクライアントをサポートするために AD FS または WAP サーバー上のフォールバック エントリの追加を検討してください。詳細については、次のブログ記事を参照してください。
  3. AuthnContext ないがサポートされている AD FS または STS のレベルで Office 365 からリダイレクトされるときにことを示すエラーまたは"不明な認証方法] エラーが発生する可能性があります。Office 365 と Azure AD、認証方法を設定するパラメーターを使用して、AD FS または STS にリダイレクトすると、このことが一般的です。認証方法を適用するには、次の方法のいずれかの手順に従います。
    • Ws-federation の、WAUTH クエリ文字列を使用して、推奨される認証方法を強制します。
    • SAML2.0 を、次を使用します。
      <saml:AuthnContext><saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef></saml:AuthnContext>
    、不適切な値に適用される認証方法が送信されるとき、または AD FS または STS で認証メソッドがサポートされていない場合は、認証する前にエラー メッセージが表示されます。

    次の表の AD FS によって認識されている Uri の認証の種類を示しています。 Ws-federation パッシブ認証します。
    希望の認証方法wauth URI
    ユーザー名とパスワードの認証urn: オアシス: 名前: tc: SAML:1.0:am:password
    SSL クライアント認証urn: ietf:rfc:2246
    Windows 統合認証urn: フェデレーション: 認証: windows

    サポート SAML 認証コンテキスト クラス

    認証方法 認証コンテキスト クラスの URI
    ユーザー名とパスワードurn: オアシス: 名前: tc: SAML:2.0:ac:classes:Password
    パスワードで保護されたトランスポートurn: オアシス: 名前: tc: SAML:2.0:ac:classes:PasswordProtectedTransport
    トランスポート層セキュリティ (TLS) クライアントurn: オアシス: 名前: tc: SAML:2.0:ac:classes:TLSClient
    X.509 証明書urn: オアシス: 名前: tc: SAML:2.0:ac:classes:X 509
    統合 Windows 認証urn: フェデレーション: 認証: windows
    Kerberosurn: オアシス: 名前: tc: SAML:2.0:ac:classes:Kerberos

    AD FS レベルで認証方法がサポートされていることを確認するのには、次の手順を確認します。

    AD FS 2.0

    /adfs/ls/web.config、認証の種類のエントリが存在するかどうかを確認します。

    <microsoft.identityServer.web></microsoft.identityServer.web>
    <localAuthenticationTypes></localAuthenticationTypes>
    名前を追加 ="Forms"page="FormsSignIn.aspx"/>
    <add name="Integrated" page="auth/integrated/"></add>
    <add name="TlsClient" page="auth/sslclient/"></add>
    <add name="Basic" page="auth/basic/"></add>


    ローカル認証の種類を変更するのには、AD FS 2.0: 方法

    AD FS 2012 R2

    AD FS の管理、] をクリックして 認証ポリシー AD FS スナップインです。

    で、 第 1 の認証 をクリックしてください 編集 [次へ グローバル設定.右クリックすることも 認証ポリシー 選択し、 グローバルの主要な認証を編集します。.または、 アクション ペインで、 グローバルの主要な認証を編集します。.

    で、 グローバル認証ポリシーを編集します。 ウィンドウで、 プライマリ タブで、設定は、グローバル認証ポリシーの一部として構成できます。などの第 1 の認証を選択できます] の下の使用可能な認証方法 エクストラネットイントラネット.

    * 必要な認証方法のチェック ボックスが選択されていることを確認します。
  4. 資格情報を入力して、AD FS には、認証できない場合は、次の問題を確認します。
    1. アクティブ ディレクトリ レプリケーションの問題

      AD レプリケーションが破損している場合は、ドメイン コント ローラー間でユーザーまたはグループに加えられた変更を同期できません可能性があります。ドメイン コント ローラー間である可能性があります、UPN のパスワード GroupMembership、または メタベース AD FS の応答 (認証とクレーム) に影響を与えるが一致しません。AD FS と同じサイトのドメイン コント ローラーで検索を開始する必要があります。実行している、 repadmin/showreps または、 DCdiag/v コマンドでは、AD FS は、連絡するほとんどのドメイン コント ローラーに問題があるかどうかが表示されます。

      AD の変更がすべてのドメイン コント ローラー間で正しくレプリケートされることになっていることを確認するのには、AD レプリケーションの概要を収集することもできます。、 repadmin/showrepl */csv > showrepl.csv 出力では、レプリケーションの状態をチェックするために便利です。詳細については、 Active Directory のレプリケーションに関する問題のトラブルシューティング.
    2. アカウントのロックアウトまたは Active Directory で無効になっています。

      AD FS によって、エンド ・ ユーザーが認証されると、彼または彼女を受信しません、アカウントをロックするか、無効になっていることを示すエラー メッセージ。AD FS およびログオンの監査は、アカウントが無効になっているか、またはロックされているかどうか、パスワードの誤りによる認証に失敗したかどうかを判断することなどがあります。

      AD FS および AD FS サーバーの監査ログオンを有効にするには、次の手順を実行します。
      1. 成功と失敗の次のポリシーを有効にするのにには、ローカルまたはドメイン ポリシーを使用します。
        • コンピューターの構成 \windows の設定 \ セキュリティの setting\Local Policy\Audit のポリシーである、ログオン イベントの監査]
        • 、コンピューターの構成 \windows の設定 \ セキュリティの setting\Local Policy\Audit のポリシーにある [オブジェクト アクセスの監査]
        スクリーン ショットのポリシーについて
      2. 次のポリシーを無効にします。

        監査: 監査ポリシー サブカテゴリを強制 (Windows Vista 以降) 監査ポリシーのカテゴリ設定を上書きするのには

        このポリシーは、コンピューターの構成 \windows の設定 \ セキュリティの setting\Local ポリシーのオプションにあります。

        スクリーン ショットのポリシーについて

        高度な監査を使用することによってこれを構成する場合は、をクリックします。 ここで.
      3. 監査のためには、AD FS を構成します。
        1. 開く、AD FS 2.0 管理スナップインです。
        2. [操作] ウィンドウで、フェデレーション サービスのプロパティの編集をクリックします。
        3. フェデレーション サービスのプロパティ ] ダイアログ ボックスをクリックして、イベント ] タブ。
        4. 選択して、の成功の監査 失敗の監査 ] チェック ボックス。

          について sceenshot では、AD FS の監査を有効にします。
        5. 実行 GPupdate/force サーバーです。
    3. サービス プリンシパル名 (SPN) が正常に登録されています。

      Spn が重複または AD FS サービス アカウント以外のアカウントで登録されている SPN が存在する場合があります。AD FS のファームを設定することを確認します。 SPN のホスト/AD FSservicename AD FS サービスを実行しているサービス アカウントに追加されます。サービスが実行されている場所の AD FS スタンドアロン セットアップ ネットワーク サービス、SPN は、AD FS をホストしているサーバーのコンピューター アカウントである必要があります。

      AD FS サービス名のスクリーン ショット

      断続的な認証に失敗した AD FS の原因になるために、AD FS サービスの Spn が重複していることを確認してください。Spn の一覧を表示、次のように実行します。 SETSPN – L<ServiceAccount></ServiceAccount>.

      スクリーン ショットの SPN の一覧

      実行 SETSPN – ホスト/AD FSservicename ServiceAccount SPN を追加します。

      実行 SETSPN – X F 重複した Spn を確認します。
    4. Active Directory 内の重複する Upn

      ユーザーが使用しているときに AD FS を使用して認証できる場合があります。 SAMAccountName UPN を使用する際に認証することはできません。このシナリオでは、同一の UPN を持つ 2 つのユーザーが Active Directory にあります。ユーザーが追加または変更するときは、同一の UPN を持っている 2 人のユーザーにすることは (ADSIedit の使用例) のスクリプトを使用します。

      このシナリオでの認証に UPN を使用する場合は、重複するユーザーに対する認証がします。したがって、提供される資格情報は検証されません。

      AD 属性に同じ値を持つ複数のオブジェクトがあるかどうかを確認するのには次のようなクエリを使用できます。
      Dsquery * forestroot -filter UserPrincipalName=problemuser_UPN

      確認、重複するユーザーの UPN の名前を変更 UPN を使用して認証要求は、正しいオブジェクトに対して検証できるようにします。
    5. シナリオでは、あなたの電子メール アドレスを使用して、Office 365 にログイン ID とは、認証のための AD FS にリダイレクトした場合、同じ電子メール アドレスを入力する、監査ログの"NO_SUCH_USER"エラーと認証は失敗します。以外の UPN または SAMaccountname 属性を使用して、認証用のユーザーを検索するのには、AD FS を有効にするには、代替のログイン ID をサポートするために AD FS を構成する必要があります。詳細については、 代替のログイン ID を設定します。.

      AD FS 2012 R2 の

      1. インストール 2919355 を更新します。.
      2. フェデレーション サーバー ファーム内のいずれかに次の PowerShell コマンドレットを実行して、AD FS の構成を更新 (WID ファームがあれば、必要がありますコマンドを実行するこのファームの主な AD FS サーバー上)。

        セット-AdfsClaimsProviderTrust-TargetIdentifier「AD 機関」- AlternateLoginID <attribute>- LookupForests <forest domain=""></forest> </attribute>

        注: <b>AlternateLoginID ログインに使用する属性の LDAP 名前です。と LookupForests フォレストにユーザーが属している DNS エントリの一覧です。

        代替のログイン ID の機能を有効にするのには、両方を構成する必要があります、 AlternateLoginIDLookupForests null 以外の有効な値を持つパラメーターです。

    6. AD FS サービス アカウントには、AD FS トークン署名証明書の秘密キーを上への読み取りアクセスがありません。このアクセス許可を追加するには、次の手順を実行します。
      1. 新しいトークン署名証明書を追加すると、次の警告メッセージが表示されます:「選択した証明書の秘密キーはファーム内の各サーバー上のこのフェデレーション サービスのサービス アカウントにアクセスできることをことを確認」です。
      2. [スタート] ボタン、[実行] をクリック、種類 mmc.exe、し、Enter キーを押します。
      3. [ファイル] をクリックし、 [スナップインの追加と削除] をクリックします。
      4. 証明書をダブルクリックします。
      5. 対象のコンピューター アカウントを選択し、[次へ] をクリックします。
      6. ローカル コンピューターを選択し、[完了] をクリックします。
      7. [証明書 (ローカル コンピューター)を展開し、展開し、 ペルソナl、および証明書を選択します。
      8. 新しいトークン署名証明書を右クリックし、すべてのタスクを選択し、秘密キーの管理です。

        手順 8 の sceenshot
      9. AD FS 2.0 サービス アカウントの読み取りアクセス権を追加し、し、[ OK] をクリックします。
      10. 証明書 MMC を閉じます。
    7. Windows 認証の拡張保護オプションは、AD FS または LS の仮想ディレクトリに対して有効になります。特定のブラウザーで問題が発生する可能性があります。繰り返し資格情報の確認、AD FS が表示される場合もありますし、これに関連している、 拡張保護 IIS で AD FS や LS のアプリケーションで Windows 認証が有効に設定します。

      手順 8 の sceenshot
      とき 拡張保護 認証が有効になっていると、両方のサービス プリンシパル名 (Spn) をクライアントが接続しようと、統合 Windows 認証が発生する外部のトランスポート層セキュリティ (TLS) チャネルをサーバーの認証要求がバインドされます。拡張保護認証の中継や「中央のマニュアル」攻撃を軽減するため既存の Windows 認証の機能が強化されます。ただし、特定のブラウザーがうまくできないと、 拡張保護 設定です。代わりに資格情報を繰り返し要求、アクセスが拒否されます。無効にします。 拡張保護 支援は、このシナリオです。

      詳細については、 AD FS 2.0: が継続的に Fiddler web デバッガーを使用しているときに資格情報を要求.

      AD FS 2012 R2 の

      Extendedprotection を無効にするのには、次のコマンドレットを実行します。

      セット-ADFSProperties-ExtendedProtectionTokenCheck なし

    8. 依存するパーティ (RP) の信頼での発行承認規則は、ユーザーにアクセスを拒否する場合があります。AD FS 利用者の信頼には、かどうか認証済みユーザーを発行するかトークンを利用者を制御する発行承認規則を構成できます。管理者は、要求として証明書抽出されたグループのメンバーであるユーザーに対してアクセスを拒否するかどうかを決定するのには、発行される要求を使用できます。

      AD FS によって特定のフェデレーション ユーザーを認証できない、する場合を Office 365 の RP の発行承認規則を確認するかどうか、 すべてのユーザーにアクセスを許可します。 ルールが構成されています。

      スクリーン ショットのルールについて
      このルールを構成すると場合、は、そのルールの条件の評価対象となるユーザーを"true"かどうかをチェックするカスタム承認規則を熟読します。詳細については、次のリソースを参照してください。
      AD FS サーバーに直接アクセスできますが、AD FS を AD FS プロキシを介してアクセスするときに認証できない場合、イントラネットから認証することができますと、は、次の問題を確認します。
      • AD FS サーバーおよび AD FS プロキシ上の時間の同期の問題

        AD FS サーバー上の時刻と、プロキシ上の時刻が同期することを確認します。AD FS サーバーの切り替えが行われるドメイン コント ローラー上の時間から 5 分以上、認証エラーが発生します。AD FS では、AD FS プロキシ上の時刻が同期されていない、プロキシの信頼は、影響を受けるし、破損しています。したがって、AD FS プロキシを通過する要求が失敗します。
      • AD FS サービスとは、AD FS プロキシ信頼が正常に機能しているかどうかを確認してください。プロキシの信頼が壊れていることが疑われる場合は、プロキシの構成を再実行します。
  5. AD FS トークン、Azure AD を発行するか、Office 365 は、エラーをスローします。このような場合は、次の問題を確認します。
    • トークン内の AD FS によって発行されたクレームは、Azure AD のユーザーのそれぞれの属性を一致させてください。Azure AD のトークンで Office 365 では、次の請求が必要なのか。

      WSFED。
      UPN: この要求の値は、Azure AD でユーザーの UPN を一致する必要があります。
      ImmutableID: この要求の値必要があります一致、sourceAnchor または ImmutableID は、ユーザーの Azure AD で。

      Azure AD のユーザー属性の値を取得するには、次のコマンドラインを実行します。 Get MsolUser – UserPrincipalName<UPN></UPN>

      SAML 2.0:
      IDPEmail: この要求の値は、Azure AD でユーザーのユーザー プリンシパル名を一致する必要があります。
      NAMEID: この要求の値必要があります一致、sourceAnchor または ImmutableID は、ユーザーの Azure AD で。

      詳細については、 SAML 2.0 の id プロバイダーを使用すると、シングル サインオンを実装します。

      例:
      AD では、オンライン ディレクトリを更新せずに同期されたユーザーの UPN が変更されたときに、この問題が発生することができます。このシナリオでは、解決するには、ユーザーの UPN AD に関連するユーザーのログオン名と一致) でまたはオンライン ディレクトリに関連するユーザーのログオン名を変更するのには次のコマンドレットを実行します。

      セット-MsolUserPrincipalName-UserPrincipalName [ExistingUPN] NewUserPrincipalName [DomainUPN AD]

      同期させる AADsync を使用している場合もあります。 UPN として送信します。EMPID SourceAnchor として、要求の送信に AD FS レベルで規則が更新されていない利用者が、 UPN として送信します。EMPID ImmutableID として.
    • AD FS と Office 365 の間でトークン署名証明書不一致があります。

      これは、最も一般的な問題の 1 つです。AD FS は、ユーザーまたはアプリケーションに送信されるトークンに署名するのには、トークン署名証明書を使用します。AD FS と Office 365 間の信頼は、フェデレーションの信頼は、このトークン署名証明書に基づいて (たとえば、Office 365 を確認、信頼されているクレーム プロバイダー [AD FS サービス] のトークン署名証明書を使用して受信したトークンが署名されている)。

      AD FS トークン署名証明書が変更された場合自動証明書のロール オーバーが発生したため、または管理者の介入をした後 (証明書の有効期限の前に)、新しい証明書の詳細は、フェデレーション ドメインを Office 365 テナントに更新する必要があります。

      パブリック ネットワークからアクセスできるとしたときに office の 365 や Azure AD は、AD FS サービスにアクセスしようとしていますが用意されています。まず ad FS のフェデレーション メタデータを ADFS では、主に、トークン署名証明書の構成の変更をプルするのには、一定の間隔でポーリングを試みます。このプロセスが動作していない場合は、グローバル管理者する必要がありますを参照してください通知 Office 365 ポータルでは、それを更新するのには、実行するアクションとトークン署名証明書の有効期限についての警告。

      使用することができます。 ドメイン名の取得 MsolFederationProperty<domain></domain> AD FS と Office 365 のフェデレーション プロパティをダンプします。ここでは、フェデレーション ドメインを Office 365 テナント構成が AD FS と同期させるかどうかを確認するのには、TokenSigningCertificate の拇印を比較できます。トークン署名証明書の構成に一致しない場合は、それを更新する次のコマンドを実行します。
      Update-MsolFederatedDomain -DomainName <domain> -SupportMultipleDomain
      AD FS サーバーのトークン署名証明書と更新プログラム、Office 365 のテナントに自動的に証明書の自動ロール オーバーを監視する上でタスクをスケジュールするのには次のツールを実行することもできます。

      Microsoft Office 365 フェデレーション メタデータの更新の自動インストール ツール

      確認し、AD FS でのシングル サインオンの管理
    • Office 365 の RP の発行の変換要求ルールが正しく構成されていません。

      複数の Tld (トップレベル ドメイン) がある場合、する必要がありますログオンの問題に関する場合は、 Supportmultipledomain RP の信頼が作成され、更新すると、スイッチは使用されませんでした。詳細については、次のようにクリックします。 ここで.
    • トークンの暗号化されるかどうかを確認します。 ありません Azure AD に、または Office 365 にトークンが発行されると、AD FS または STS で使用されています。
  6. 古いキャッシュされた資格情報では、Windows 資格情報マネージャー。

    場合がありますログイン時のワークステーションからポータル (または Outlook を使用する場合) の資格情報、ユーザーの入力を求められたら、Windows 資格情報マネージャー (コントロール ・ Panel\User ・ Accounts\Credential ・ マネージャー) のターゲット (Office 365 または AD FS サービス) の資格情報を保存することがあります。しばらくの間では、資格情報のプロンプトを防ぐことができますが、ユーザーのパスワードが変更され、資格情報マネージャーが更新されていない後に問題が発生可能性があります。シナリオでは、古い資格情報が、AD FS サービスに送信され、認証が失敗したためです。削除するか、キャッシュされた資格情報を Windows 資格情報マネージャーでの更新が役立つ場合があります。
  7. Office 365 に依存しているパーティ信頼に構成されているセキュリティで保護されたハッシュ アルゴリズムは SHA1 に設定されていることを確認します。

    STS または AD FS と Azure AD と Office 365 間の信頼は SAML 2.0 プロトコルを使用しているときにデジタル署名用に構成されたセキュリティで保護されたハッシュ アルゴリズムは、SHA1 のはずです。
  8. 上記の原因の [なし] は、自分の状況に適用される場合マイクロソフトとサポート ケースを作成し、ユーザー アカウントが Office 365 のテナントで一貫して表示するかを確認するように依頼します。詳細については、次のリソースを参照してください。

    AD FS 2.0 フェデレーション ユーザーが Office 365 にサインインするときのエラー メッセージ:「サイトへのアクセスに問題が発生しました」

    フェデレーション ユーザーは彼または彼女、Office 365 にサインイン中に、AD FS 2.0 サービス エンドポイントに接続すると、繰り返し資格情報を要求します。
  9. (Azure AD と統合)、どのクラウド サービスによってアクセスしている場合、AD FS に送信される認証要求が異なる場合があります。例: 特定の要求は次のように追加のパラメーターを含めることが Wauth または Wfresh、AD FS レベルでのさまざまな動作が発生する可能性がありますこれらのパラメーターとします。

    AD FS のバイナリ常に保持する既知の問題に対する修正プログラムを含むように更新されたことをお勧めします。最新の更新プログラムの詳細については、次の表を参照してください。

警告: この記事は自動翻訳されています

プロパティ

文書番号:3079872 - 最終更新日: 08/11/2015 20:20:00 - リビジョン: 2.0

Windows Server 2008 Datacenter, Windows Server 2008 Enterprise, Windows Server 2008 Foundation, Windows Server 2008 Standard, Windows Server 2008 R2 Datacenter, Windows Server 2008 R2 Enterprise, Windows Server 2008 R2 Foundation, Windows Server 2008 R2 Standard, Windows Server 2012 Foundation, Windows Server 2012 Essentials, Windows Server 2012 Datacenter, Windows Server 2012 Standard, Windows Server 2012 R2 Datacenter, Windows Server 2012 R2 Essentials, Windows Server 2012 R2 Foundation, Windows Server 2012 R2 Standard

  • kbmt KB3079872 KbMtja
フィードバック