次の方法で共有


シングル サインオンに SAML 2.0 ID プロバイダー (IdP) を使用する

このドキュメントでは、SAML 2.0 に準拠している SP-Lite プロファイル ベースの ID プロバイダーを、優先セキュリティ トークン サービス (STS)/ID プロバイダーとして使用する方法について説明します。 このシナリオは、SAML 2.0 を使用してアクセスできるユーザー ディレクトリとパスワード ストアがオンプレミスに既にある場合に役立ちます。 この既存のユーザー ディレクトリを使用して、Microsoft 365 やその他の Microsoft Entra ID で保護されたリソースにサインオンできます。 SAML 2.0 SP-Lite プロファイルは、サインオンおよび属性交換フレームワークを提供するために広く使用されている Security Assertion Markup Language (SAML) フェデレーション ID 標準に基づいています。

Note

Microsoft Entra ID との使用テストが行われているサード パーティの IDP の一覧については、「Microsoft Entra のフェデレーション互換性リスト」を参照してください。

Microsoft では、適切に構成された SAML 2.0 プロファイル ベースの IDP と Microsoft クラウド サービス (Microsoft 365 など) の統合として、このサインオン エクスペリエンスをサポートします。 SAML 2.0 ID プロバイダーはサード パーティ製品であるため、Microsoft では、これらに関するデプロイ、構成、トラブルシューティングのベスト プラクティスをサポートしていません。 適切に構成したら、後ほど詳述する Microsoft 接続アナライザー ツールを使用して、SAML 2.0 ID プロバイダーとの統合が適切な構成かどうかをテストできます。 SAML 2.0 SP-Lite プロファイル ベースの ID プロバイダーの詳細については、提供元の組織にお問い合わせください。

重要

SAML 2.0 ID プロバイダーを使用するこのサインオン シナリオで利用できるクライアントは、以下に限定されています。

  • Outlook Web Access や SharePoint Online などの Web ベースのクライアント
  • 基本認証を使用し、IMAP、POP、Active Sync、MAPI などのサポートされている Exchange アクセス方法を使用する電子メール リッチ クライアント。 (Enhanced Client Protocol エンド ポイントのデプロイが必要です)。これには以下があります。
    • Microsoft Outlook 2010/Outlook 2013/Outlook 2016、Apple iPhone (複数の iOS のバージョン)
    • 多様な Google Android デバイス
    • Windows Phone 7、Windows Phone 7.8、および Windows Phone 8.0
    • Windows 8 メール クライアントと Windows 8.1 メール クライアント
    • Windows 10 メール クライアント

上記以外のクライアントはすべて、SAML 2.0 ID プロバイダーを使用するこのサインオン シナリオでは利用できません。 たとえば、Lync 2010 デスクトップ クライアントは、シングル サインオン用に SAML 2.0 ID プロバイダーが構成されているサービスにサインインすることはできません。

Microsoft Entra の SAML 2.0 プロトコルの要件

このドキュメントには、1 つ以上の Microsoft クラウド サービス (Microsoft 365 など) にサインオンできるように、SAML 2.0 ID プロバイダーが Microsoft Entra ID とフェデレーションするために実装する必要があるプロトコルとメッセージ形式に関する詳細要件が含まれています。 このシナリオで使用される Microsoft クラウド サービスの SAML 2.0 証明書利用者 (SP-STS) は Microsoft Entra ID です。

SAML 2.0 ID プロバイダーの出力メッセージを、提供されているサンプル トレースと可能な限り類似させることをお勧めします。 また、可能であれば、提供されている Microsoft Entra メタデータの特定の属性値を使用してください。 出力メッセージに問題がなければ、後ほど説明する Microsoft 接続アナライザーを使用してテストできます。

Microsoft Entra メタデータは、この URL https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml からダウンロードできます。 Microsoft 365 の中国固有のインスタンスを使用している中国国内のお客様は、次のフェデレーション エンドポイントを使用する必要があります: https://nexus.partner.microsoftonline-p.cn/federationmetadata/saml20/federationmetadata.xml

SAML プロトコル要件

このセクションでは、メッセージを正しく書式設定するために、要求と応答のメッセージのペアをまとめる方法を詳しく説明します。

Microsoft Entra ID は、以下に示すいくつかの要件に従って、SAML 2.0 SP Lite プロファイルを使用する ID プロバイダーと連携するように構成できます。 サンプルの SAML 要求メッセージと応答メッセージを自動テストと手動テストで使用することで、Microsoft Entra ID との相互運用性を実現することができます。

署名ブロック要件

SAML 応答メッセージでは、署名ノードにメッセージ自体のデジタル署名に関する情報が含まれています。 署名ブロックには次の要件があります。

  1. アサーション ノード自体を署名する必要があります。
  2. DigestMethod として RSA-sha1 アルゴリズムを使用する必要があります。 他のデジタル署名アルゴリズムは容認されません。 <ds:DigestMethod Algorithm="https://www.w3.org/2000/09/xmldsig#sha1"/>
  3. XML ドキュメントに署名することもできます。
  4. 変換アルゴリズムは、次の例の値と一致する必要があります。<ds:Transform Algorithm="https://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <ds:Transform Algorithm="https://www.w3.org/2001/10/xml-exc-c14n#"/>
  5. SignatureMethod アルゴリズムは、次の例と一致する必要があります。<ds:SignatureMethod Algorithm="https://www.w3.org/2000/09/xmldsig#rsa-sha1"/>

注意

セキュリティを向上させるために SHA-1 アルゴリズムは非推奨です。 SHA-256 などのより安全なアルゴリズムを使用してください。 詳細については、こちらをご覧ください

サポートされるバインディング

バインディングは、トランスポートに関連する必須の通信パラメーターです。 バインディングには次の要件が適用されます。

  1. 要求されるトランスポートは HTTPS です。
  2. Microsoft Entra ID では、サインイン時のトークン送信に HTTP POST を必要とします。
  3. Microsoft Entra ID は ID プロバイダーへの認証要求に HTTP POST を使用し、ID プロバイダーへのサインアウト メッセージに REDIRECT を使用します。

必須の属性

次の表は、SAML 2.0 メッセージの特定の属性の要件を示します。

属性 説明
NameID このアサーションの値は、Microsoft Entra ユーザーの ImmutableID と同じである必要があります。 最大 64 文字の英数字にすることができます。 HTML で安全に使用できない文字はエンコードする必要があります。たとえば、"+" 文字は ".2B" と表示されます。
IDPEmail ユーザー プリンシパル名 (UPN) は、SAML 応答内で IDPEmail という名前の要素として示されます。これは、Microsoft Entra ID / Microsoft 365でのユーザーの UserPrincipalName (UPN) です。 UPN は電子メール アドレス形式です。 Windows Microsoft 365 (Microsoft Entra ID) の UPN 値。
発行者 ID プロバイダーの URI を指定する必要があります。 サンプル メッセージの発行者を再利用しないでください。 Microsoft Entra テナントに複数のトップ レベル ドメインがある場合、発行者は、ドメインごとに構成された指定の URI 設定と一致する必要があります。

重要

現在、Microsoft Entra ID は次の SAML 2.0 の NameID フォーマット URI をサポートしています: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent。

サンプルの SAML 要求メッセージと応答メッセージ

サインオン メッセージ交換では、要求メッセージと応答メッセージのペアが示されます。 Microsoft Entra ID からサンプルの SAML 2.0 ID プロバイダーに送信されるサンプル要求メッセージを次に示します。 このサンプル SAML 2.0 ID プロバイダーは、SAML-P プロトコルを使用するように構成された Active Directory フェデレーション サービス (AD FS) です。 その他の SAML 2.0 ID プロバイダーとの相互運用性のテストも完了しています。

<samlp:AuthnRequest ID="_1e089e5c-a976-4881-af74-3b92c89e7e2c" Version="2.0" IssueInstant="2024-03-12T14:00:18.450Z" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">urn:federation:MicrosoftOnline</Issuer><samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/></samlp:AuthnRequest>

internaldomainfederation-update で説明されているように isSignedAuthenticationRequestRequired が有効になっている場合、要求は次の例のようになります。

  <samlp:AuthnRequest ID="_1868c6f2-1fdd-40b9-818f-b4b44efb92c5" Version="2.0" IssueInstant="2024-03-11T16:51:17.120Z" Destination="https://fs.contoso.com/adfs/ls/" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">urn:federation:MicrosoftOnline</Issuer><Signature xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo><CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><Reference URI="#_1868c6f2-1fdd-40b9-818f-b4b44efb92c5"><Transforms><Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></Transforms><DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><DigestValue>aB1cD2eF3gH4iJ5kL6-mN7oP8qR=</DigestValue></Reference></SignedInfo><SignatureValue>cD2eF3gH4iJ5k...L6mN7-oP8qR9sT==</SignatureValue><KeyInfo><ds:X509Data xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509SKI>eF3gH4iJ5kL6mN7oP8-qR9sT0uV=</ds:X509SKI></ds:X509Data><ds:KeyName xmlns:ds="http://www.w3.org/2000/09/xmldsig#">MicrosoftOnline</ds:KeyName></KeyInfo></Signature><samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/></samlp:AuthnRequest>

サンプルの SAML 2.0 準拠 ID プロバイダーから Microsoft Entra ID/Microsoft 365 に送信されるサンプル応答メッセージを次に示します。

    <samlp:Response ID="_592c022f-e85e-4d23-b55b-9141c95cd2a5" Version="2.0" IssueInstant="2014-01-31T15:36:31.357Z" Destination="https://login.microsoftonline.com/login.srf" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" InResponseTo="_049917a6-1183-42fd-a190-1d2cbaf9b144" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://WS2012R2-0.contoso.com/adfs/services/trust</Issuer>
    <samlp:Status>
    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
    </samlp:Status>
    <Assertion ID="_7e3c1bcd-f180-4f78-83e1-7680920793aa" IssueInstant="2014-01-31T15:36:31.279Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
    <Issuer>http://WS2012R2-0.contoso.com/adfs/services/trust</Issuer>
    <ds:Signature xmlns:ds="https://www.w3.org/2000/09/xmldsig#">
      <ds:SignedInfo>
        <ds:CanonicalizationMethod Algorithm="https://www.w3.org/2001/10/xml-exc-c14n#" />
        <ds:SignatureMethod Algorithm="https://www.w3.org/2000/09/xmldsig#rsa-sha1" />
        <ds:Reference URI="#_7e3c1bcd-f180-4f78-83e1-7680920793aa">
          <ds:Transforms>
            <ds:Transform Algorithm="https://www.w3.org/2000/09/xmldsig#enveloped-signature" />
            <ds:Transform Algorithm="https://www.w3.org/2001/10/xml-exc-c14n#" />
          </ds:Transforms>
          <ds:DigestMethod Algorithm="https://www.w3.org/2000/09/xmldsig#sha1" />
          <ds:DigestValue>CBn/aB1cD2eF3gH4iJ5kL6-mN7oP8qR=</ds:DigestValue>
        </ds:Reference>
      </ds:SignedInfo>
      <ds:SignatureValue>cD2eF3gH4iJ5kL6mN7-oP8qR9sT==</ds:SignatureValue>
      <KeyInfo xmlns="https://www.w3.org/2000/09/xmldsig#">
        <ds:X509Data>
          <ds:X509Certificate>eF3gH4iJ5kL6mN7oP8-qR9sT0uV=</ds:X509Certificate>
        </ds:X509Data>
      </KeyInfo>
    </ds:Signature>
    <Subject>
      <NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">ABCDEG1234567890</NameID>
      <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
        <SubjectConfirmationData InResponseTo="_049917a6-1183-42fd-a190-1d2cbaf9b144" NotOnOrAfter="2014-01-31T15:41:31.357Z" Recipient="https://login.microsoftonline.com/login.srf" />
      </SubjectConfirmation>
    </Subject>
    <Conditions NotBefore="2014-01-31T15:36:31.263Z" NotOnOrAfter="2014-01-31T16:36:31.263Z">
      <AudienceRestriction>
        <Audience>urn:federation:MicrosoftOnline</Audience>
      </AudienceRestriction>
    </Conditions>
    <AttributeStatement>
      <Attribute Name="IDPEmail">
        <AttributeValue>administrator@contoso.com</AttributeValue>
      </Attribute>
    </AttributeStatement>
    <AuthnStatement AuthnInstant="2014-01-31T15:36:30.200Z" SessionIndex="_7e3c1bcd-f180-4f78-83e1-7680920793aa">
      <AuthnContext>
        <AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</AuthnContextClassRef>
      </AuthnContext>
    </AuthnStatement>
    </Assertion>
    </samlp:Response>

SAML 2.0 に準拠している ID プロバイダーを構成する

このセクションには、SAML 2.0 プロトコルを使用して、1 つ以上の Microsoft クラウド サービス (Microsoft 365 など) にシングル サインオンでアクセスできるようにするために、Microsoft Entra ID とフェデレーションするように SAML 2.0 ID プロバイダーを構成する方法に関するガイドラインが含まれています。 このシナリオで使用される Microsoft クラウド サービスの SAML 2.0 証明書利用者 は Microsoft Entra ID です。

Microsoft Entra メタデータを追加する

SAML 2.0 ID プロバイダーは、Microsoft Entra ID 証明書利用者に関する情報に準拠する必要があります。 Microsoft Entra ID は https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml でメタデータを発行します。

SAML 2.0 ID プロバイダーを構成する際は、常に最新の Microsoft Entra メタデータをインポートすることをお勧めします。

Note

Microsoft Entra ID が ID プロバイダーからメタデータを読み取ることはありません。

証明書利用者として Microsoft Entra ID を追加する

SAML 2.0 ID プロバイダーと Microsoft Entra ID の間の通信を有効にする必要があります。 この構成は、お使いの ID プロバイダーによって異なるため、その ID プロバイダー向けのドキュメントを参照する必要があります。 通常は、証明書利用者の ID を Microsoft Entra メタデータの entityID と同じ値に設定します。

Note

SAML 2.0 ID プロバイダーのサーバーのクロックが正しいタイム ソースに同期されていることを確認してください。 不正確なクロック時間は、フェデレーション ログインの失敗の原因になる可能性があります。

SAML 2.0 ID プロバイダーを使用したサインオンのために PowerShell をインストールする

Microsoft Entra のサインオンで使用するように SAML 2.0 ID プロバイダーを構成したら、次の手順として、Microsoft Graph PowerShell モジュールをダウンロードしてインストールします。 インストールしたら、これらのコマンドレットを使用して、Microsoft Entra ドメインをフェデレーション ドメインとして構成します。

Microsoft Graph PowerShell モジュールは、Microsoft Entra ID で組織のデータを管理するためのダウンロードです。 このモジュールにより、PowerShell に一連のコマンドレットがインストールされます。これらのコマンドレットを実行して Microsoft Entra ID へのシングル サインオン アクセスを設定し、サブスクライブしているすべてのクラウド サービスにアクセスします。 コマンドレットをダウンロードしてインストールする手順については、「Microsoft Graph PowerShell SDK をインストールする」を参照してください。

SAML ID プロバイダーと Microsoft Entra ID の間に信頼を確立する

Microsoft Entra ドメインのフェデレーションを構成する前に、カスタム ドメインを構成する必要があります。 Microsoft から提供されている既定のドメインをフェデレーションすることはできません。 Microsoft の既定のドメインは、onmicrosoft.com で終わります。 一連の PowerShell コマンドレットを実行して、シングル サインオン用のドメインを追加または変換します。

SAML 2.0 ID プロバイダーを使用してフェデレーションする各 Microsoft Entra ドメインは、シングル サインオン ドメインとして追加するか、標準ドメインからシングル サインオン ドメインに変換する必要があります。 ドメインを追加または変換すると、SAML 2.0 ID プロバイダーと Microsoft Entra ID の間に信頼が確立されます。

次の手順は、既存の標準ドメインを SAML 2.0 SP-Lite を使用するフェデレーション ドメインに変換する方法を説明しています。

注意

この手順の実行後、ドメインの停止が発生する可能性があります。これは、最大 2 時間、ユーザーに影響を与えます。

フェデレーションのために Microsoft Entra ディレクトリのドメインを構成する

  1. 次のテナント管理者として Microsoft Entra ディレクトリに接続します。

    Connect-MgGraph -Scopes "Domain.ReadWrite.All"
    
  2. SAML 2.0 とのフェデレーションで使用する目的の Microsoft 365 ドメインを構成します。

    $Domain = "contoso.com"  
    $LogOnUrl = "https://WS2012R2-0.contoso.com/passiveLogon" 
    $LogOffUrl = "https://WS2012R2-0.contoso.com/passiveLogOff" 
    $ecpUrl = "https://WS2012R2-0.contoso.com/PAOS" 
    $MyUri = "urn:uri:MySamlp2IDP"
    $idptokensigningcert = [System.Security.Cryptography.X509Certificates.X509Certificate2]("C:\temp\contosoidptokensign.cer")  
    $MySigningCert = [system.convert]::tobase64string($idptokensigningcert.rawdata) 
    $Protocol = "saml"
    
    New-MgDomainFederationConfiguration `
      -DomainId $Domain `
      -ActiveSignInUri $ecpUrl `
      -IssuerUri $MyUri `
      -PassiveSignInUri $LogOnUrl `
      -PreferredAuthenticationProtocol $Protocol `
      -SignOutUri $LogOffUrl `
      -SigningCertificate $MySigningCert
    
  3. IDP メタデータ ファイルから署名証明書の base64 でエンコードされた文字列を取得できます。 この場所の例を次に示しますが、実装によっては多少異なる場合があります。

    <IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
      <KeyDescriptor use="signing">
        <KeyInfo xmlns="https://www.w3.org/2000/09/xmldsig#">
         <X509Data>
           <X509Certificate> eF3gH4iJ5kL6mN7oP8-qR9sT0uV=</X509Certificate>
          </X509Data>
        </KeyInfo>
      </KeyDescriptor>
    </IDPSSODescriptor>
    

詳細については、「New-MgDomainFederationConfiguration」を参照してください。

Note

$ecpUrl = "https://WS2012R2-0.contoso.com/PAOS" は、ID プロバイダーに対して ECP 拡張機能を設定する場合にのみ使用する必要があります。 Outlook Web Application (OWA) を除く Exchange Online クライアントは、POST ベースのアクティブなエンドポイントを活用します。 SAML 2.0 STS でアクティブなエンドポイントの Shibboleth の ECP 実装に似たアクティブなエンドポイントを実装すると、これらのリッチ クライアントが Exchange Online サービスと対話することが可能になる場合があります。

フェデレーションを構成したら、"非フェデレーション" (または "マネージド") に切り替えることができます。ただし、この変更が完了するまで最大 2 時間かかり、クラウドベースのサインイン用の新しいランダム パスワードを各ユーザーに割り当てる必要があります。 "マネージド" への切り替えは、一部のシナリオで設定のエラーをリセットするために必要になる場合があります。 ドメイン変換の詳細については、「Remove-MgDomainFederationConfiguration」を参照してください。

Microsoft Entra ID/Microsoft 365 にユーザー プリンシパルをプロビジョニングする

Microsoft 365 に対してユーザーを認証するには、SAML 2.0 要求のアサーションに対応するユーザー プリンシパルを使用して Microsoft Entra ID を事前にプロビジョニングしておく必要があります。 これらのユーザー プリンシパルが Microsoft Entra ID で事前に認識されていない場合、フェデレーション サインインに使用することはできません。 ユーザー プリンシパルは、Microsoft Entra Connect または PowerShell を使用してプロビジョニングできます。

Microsoft Entra Connect を使用して、オンプレミスの Active Directory から Microsoft Entra ディレクトリ内のドメインにプリンシパルをプロビジョニングできます。 詳細については、「オンプレミスのディレクトリと Microsoft Entra ID の統合」を参照してください。

PowerShell は、新しいユーザーの Microsoft Entra ID への追加を自動化し、オンプレミスのディレクトリの変更を同期するために使用することもできます。 PowerShell コマンドレットを使用するには、Microsoft Graph PowerShell モジュールをダウンロードする必要があります。

次の手順は、Microsoft Entra ID に 1 人のユーザーを追加する方法を示しています。

  1. Connect-MgGraph を使用して、テナント管理者として Microsoft Entra ディレクトリに接続します。

  2. 新しいユーザー プリンシパルを作成します。

    $Password =  -join ((48..57) + (97..122) | Get-Random -Count 12 | % {[char]$_})
    $PasswordProfile = @{ Password = "$Password" }
    
    New-MgUser `
      -UserPrincipalName "elwoodf1@contoso.com" `
      -DisplayName "Elwood Folk" `
      -GivenName "Elwood" `
      -Surname "Folk" `
      -AccountEnabled `
      -MailNickName 'ElwoodFolk' `
      -OnPremisesImmutableId ABCDEFG1234567890 `
      -OtherMails "Elwood.Folk@contoso.com" `
      -PasswordProfile $PasswordProfile `
      -UsageLocation "US"
    

詳細については、「New-MgUser」を参照してください。

Note

"UserPrincipalName" 値は、SAML 2.0 要求で送信する "IDPEmail" の値と一致する必要があり、"OnPremisesImmutableId" 値は、"NameID" アサーションで送信される値と一致する必要があります。

SAML 2.0 IDP を使用したシングル サインオンを検証する

管理者としてシングル サインオン (ID フェデレーションとも呼ばれます) を検証して管理する前に、情報をレビューし、次の記事の手順を実行して、SAML 2.0 SP-Lite ベースの ID プロバイダーでのシングル サインオンを設定します。

  1. Microsoft Entra の SAML 2.0 プロトコルの要件を確認している。
  2. SAML 2.0 ID プロバイダーを構成している
  3. SAML 2.0 ID プロバイダーを使用したシングル サインオン (SSO) のために PowerShell をインストールする
  4. SAML 2.0 ID プロバイダーと Microsoft Entra ID の間に信頼を確立している。
  5. PowerShell または Microsoft Entra Connect を介して Microsoft Entra ID (Microsoft 365) に既知のテスト ユーザー プリンシパルをプロビジョニングしている。
  6. Microsoft Entra Connect を使用してディレクトリ同期を構成する。

SAML 2.0 SP-Lite ベースの ID プロバイダーを使用した SSO を設定したら、それが正しく動作していることを確認する必要があります。 SAML ベースの SSO のテストの詳細については、「SAML ベースのシングル サインオンのテスト」を参照してください。

Note

ドメインの追加ではなく、ドメインの変換を行った場合は、シングル サインオンが設定されるまで最大 24 時間かかる可能性があります。 シングル サインオンを検証する前に、Active Directory の同期の設定を完了し、ディレクトリを同期し、同期済みユーザーをアクティブ化する必要があります。

シングル サインオンが正しく設定されていることを手動で検証する

手動による検証には、多くのシナリオで SAML 2.0 ID プロバイダーが正しく動作することを確認するために実行できる追加の手順が用意されています。 シングル サインオンが正しく設定されていることを確認するには、次の手順を行います。

  1. ドメインに参加しているコンピューターで、会社の資格情報で使用するのと同じサインイン名を使用して、クラウド サービスにサインインします。
  2. [パスワード] ボックスの内側を選択します。 シングル サインオンが設定されている場合、[パスワード] ボックスが網掛けされ、"<会社名> にサインインする必要があります" というメッセージが表示されます。
  3. [<会社名> にサインインする] リンクを選択します。 サインインできた場合は、シングル サインオンが設定されています。

次のステップ