シングル サインオンを実装するための SAML 2.0 ID プロバイダーの使用

適用対象: Azure, Office 365, Power BI, Windows Intune

このトピックでは、Microsoft クラウド サービスのソリューション導入担当者が、推奨のセキュリティ トークン サービス (STS) および ID プロバイダーとして SAML 2.0 に準拠した SP-Lite プロファイル ベースの ID プロバイダーを使用し、Azure Active Directory (AD) ユーザーにサインオン検証を提供する手順を説明します。以下の手順は、SAML 2.0 を使用してアクセス可能なユーザー ディレクトリおよびパスワードを、ソリューションの導入担当者がオンプレミスで既に保持している場合に有用です。この既存のユーザー ディレクトリを使用すると、Office 365 や、Azure AD で保護されたその他のリソースにサインオンできます。SAML 2.0 SP-Lite プロファイルは、広く使用されている Security Assertion Markup Language (SAML) フェデレーション ID 標準に基づき、サインオンおよび属性交換フレームワークを提供します。

マイクロソフトでは、このサインオン エクスペリエンスを、Office 365 などの Microsoft クラウド サービスへの統合として、適切に設定された SAML 2.0 プロファイル ベースの ID プロバイダー (以下 SAML 2.0 ID プロバイダー) を使用してサポートしています。SAML 2.0 ID プロバイダーはサードパーティ製品なので、マイクロソフトではこれらの展開、構成、トラブルシューティング時のベスト プラクティスについてはサポートしていません。正しく構成したら、以降で詳細に説明する Microsoft 接続アナライザー ツールを使用して SAML 2.0 ID プロバイダーが正しく統合されているかテストできます。SAML 2.0 SP-Lite プロファイル ベースの ID プロバイダーの詳細は、それを提供している組織に問い合わせてください。

重要

サード パーティ製の SAML プロバイダーは、Modern Auth Office 365 クライアントでサポートされます。Works with Office 365 プログラムで検証する必要はありません。詳細については、Office 365 SAML 2.0 フェデレーション実装担当者向けガイドをご覧ください。

また、この SAML 2.0 ID プロバイダーを使用したサインオン シナリオでは、次のクライアントも使用できます。

  • Outlook Web Access や SharePoint Online などの Web ベースのクライアント

  • 基本認証と IMAP、POP、Active Sync、MAPI などサポート対象の Exchange のアクセス方法を使用する電子メールリッチ クライアント (展開には、Enhanced Client Protocol エンド ポイントが必要)、次のクライアントが含まれます。

    1. Microsoft Outlook 2010、Microsoft Outlook 2013、Word 2013、Excel 2013、PowerPoint 2013、Skype for Business 2013、Publisher 2013、Viso 2013、Access 2013、Project 2013、OneDrive for Business Sync Client。

    2. Apple iPhone (さまざまな iOS のバージョン)

    3. さまざまな Google Android デバイス

    4. Windows Phone 7、Windows Phone 7.8 および Windows Phone 8.0

    5. Windows 8 電子メール クライアントおよび Windows 8.1 電子メール クライアント

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

重要

以下の手順を開始するにあたっての前提条件として、あらかじめ「シングル サインオンを準備する」を参照して、シングル サインオンの利点、ユーザー エクスペリエンス、および要件を確認してください。

Azure AD SAML 2.0 のプロトコル要件

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

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

Azure AD メタデータは、https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml からダウンロードできます。

中国で、Office 365 の中国固有のインスタンスを使用しているお客様は、https://nexus.partner.microsoftonline-p.cn/federationmetadata/saml20/federationmetadata.xml のフェデレーション エンドポイントを使用してください。

SAML プロトコルの要件

このセクションでは、正しくメッセージをフォーマットできるようにするため、要求および応答メッセージのペアがどのように編成されるのかを説明します。

Azure AD は、次に示すいくつかの要件を満たせば、SAML 2.0 SP Lite プロファイルを使用する ID プロバイダーと連携するように構成できます。サンプルの SAML 要求および応答メッセージと自動および手動によるテストを使用して、Azure AD との相互運用性を確保するための作業を行うことができます。

署名ブロックの要件

SAML 応答メッセージの署名ノードには、メッセージ自体の電子署名情報があります。署名ブロックには、次の要件があります:

  1. アサーション ノード自体に署名が必要である。

  2. DigestMethod として RSA-sha1 アルゴリズムを使用する必要がある。その他の電子署名アルゴリズムは許可されていません。

    <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
    
  3. XML ドキュメントも署名できます。

  4. Transform Algorithm は、次の例の値と一致している必要があります。

    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
      <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
    
  5. SignatureMethod Algorithm は、次の例と一致している必要があります。

    <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
    

サポート対象のバインド

バインドとは、必須のトランスポートに関係する通信パラメーターです。バインドには次の要件があります。

  1. HTTPS は必須のトランスポートです。

  2. Azure AD では、ログオン中のトークン送信に HTTP POST が必要です。

  3. Azure AD では、ID プロバイダーに対する認証要求に HTTP POST を使用し、ID プロバイダーに対するログオフ メッセージに REDIRECT を使用します。

必須の属性

次の表に SAML 2.0 メッセージに固有の属性の要件を示します。

NameID

このアサーションの値は、Azure AD ユーザーの ImmutableID と同じである必要があります。これは最大 64 文字までの英数字です。HTML で正常に表示されない文字は、エンコードする必要があります。たとえば、"+" の記号は ".2B" と表示されます。

IDPEmail

ユーザー プリンシパル名 (UPN) は、SAML 応答で IDPEmail という名前の要素として列挙されます。これは、Azure AD および Office 365 のユーザーの UserPrincipalName (UPN) です。この UPN は電子メール アドレスの形式です。Windows Office 365 (Azure Active Directory) の UPN 値

Issuer

これは ID プロバイダーの URI である必要があります。サンプル メッセージの Issuer は再利用しないでください。Azure AD テナントに複数のトップレベル ドメインがある場合、Issuer はドメインごとに構成された特定の URI 設定と同じである必要があります。

警告

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

SAML の要求および応答メッセージの例

サインオン メッセージの交換のための要求および応答メッセージのペアを次に示します。

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

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_7171b0b2-19f2-4ba2-8f94-24b5e56b7f1e" IssueInstant="2014-01-30T16:18:35Z" Version="2.0" AssertionConsumerServiceIndex="0" >
  <saml:Issuer>urn:federation:MicrosoftOnline</saml:Issuer>
  <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/>
</samlp:AuthnRequest>

これは、サンプルの SAML 2.0 対応 ID プロバイダーから Azure AD および Office 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="http://www.w3.org/2000/09/xmldsig#">
      <ds:SignedInfo>
        <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
        <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
        <ds:Reference URI="#_7e3c1bcd-f180-4f78-83e1-7680920793aa">
          <ds:Transforms>
            <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
            <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
          </ds:Transforms>
          <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
          <ds:DigestValue>CBn/5YqbheaJP425c0pHva9PhNY=</ds:DigestValue>
        </ds:Reference>
      </ds:SignedInfo>
      <ds:SignatureValue>TciWMyHW2ZODrh/2xrvp5ggmcHBFEd9vrp6DYXp+hZWJzmXMmzwmwS8KNRJKy8H7XqBsdELA1Msqi8I3TmWdnoIRfM/ZAyUppo8suMu6Zw+boE32hoQRnX9EWN/f0vH6zA/YKTzrjca6JQ8gAV1ErwvRWDpyMcwdYCiWALv9ScbkAcebOE1s1JctZ5RBXggdZWrYi72X+I4i6WgyZcIGai/rZ4v2otoWAEHS0y1yh1qT7NDPpl/McDaTGkNU6C+8VfjD78DrUXEcAfKvPgKlKrOMZnD1lCGsViimGY+LSuIdY45MLmyaa5UT4KWph6dA==</ds:SignatureValue>
      <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
        <ds:X509Data>
          <ds:X509Certificate>MIIC7jCCAdagAwIBAgIQRrjsbFPaXIlOG3GTv50fkjANBgkqhkiG9w0BAQsFADAzMTEwLwYDVQQDEyhBREZTIFNpZ25pbmcgLSBXUzIwMTJSMi0wLnN3aW5mb3JtZXIuY29tMB4XDTE0MDEyMDE1MTY0MFoXDTE1MDEyMDE1MTY0MFowMzExMC8GA1UEAxMoQURGUyBTaWduaW5nIC0gV1MyMDEyUjItMC5zd2luZm9ybWVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKe+rLVmXy1QwCwZwqgbbp1/+3ZWxd9T/jV0hpLIIWr+LCOHqq8n8beJvlivgLmDJo8f+EITnAxWcsJUvVai/35AhHCUq9tc9sqMp5PWtabAEMb2AU72/QlX/72D2/NbGQq1BWYbqUpgpCZ2nSgvlWDHlCiUo//UGsvfox01kjTFlmqQInsJVfRxF5AcCAwEAATANBgkqhkiG9w0BAQsFAAOCAQEAi8c6C4zaTEc7aQiUgvnGQgCbMZbhUXXLGRpjvFLKaQzkwa9eq7WLJibcSNyGXBa/SfT5wJgsm3TPKgSehGAOTirhcqHheZyvBObAScY7GOT+u9pVYp6raFrc7ez3c+CGHeV/tNvy1hJNs12FYH4X+ZCNFIT9tprieR25NCdi5SWUbPZL0tVzJsHc1y92b2M2FxqRDohxQgJvyJOpcg2mSBzZZIkvDg7gfPSUXHVS1MQs0RHSbwq/XdQocUUhl9/e/YWCbNNxlM84BxFsBUok1dH/gzBySx+Fc8zYi7cOq9yaBT3RLT6cGmFGVYZJW4FyhPZOCLVNsLlnPQcX3dDg9A==</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 プロバイダーの構成

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

Azure AD メタデータの追加

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

SAML 2.0 ID プロバイダーを構成する場合、常に最新の Azure AD メタデータをインポートすることをお勧めします。Azure AD は ID プロバイダーからメタデータを読み取らないことに注意してください。

証明書利用者としての Azure AD の追加

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

注意

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

SAML 2.0 ID プロバイダーでのサインオンのための Windows PowerShell のインストール

Azure AD サインオンで使用するために SAML 2.0 ID プロバイダーを構成したら、次の手順として、Windows PowerShell 用の Azure Active Directory モジュールをダウンロードします。一度インストールすると、これらのコマンドレットを使用して Azure AD ドメインをフェデレーション ドメインとして構成できます。

Windows PowerShell 用の Azure Active Directory モジュールは、Azure AD で組織のデータを管理するために使用されます。このモジュールにより、Windows PowerShell に一連のコマンドレットがインストールされます。これらのコマンドレットを実行して、Azure AD およびサブスクライブしているすべてのクラウド サービスへのシングル サインオン アクセスを設定します。cmdlets のダウンロードおよびインストール手順については、http://technet.microsoft.com/library/jj151815.aspx を参照してください。

SAML ID プロバイダーと Azure AD の間で信頼を確立する

Azure AD ドメインでフェデレーションを構成する前に、カスタム ドメインを構成する必要があります。マイクロソフトによって提供されている既定のドメインにフェデレーションすることはできません。マイクロソフトの既定のドメインは、"onmicrosoft.com" で終了します。

シングル サインオン用にドメインを追加または変換するために、Windows PowerShell コマンドライン インターフェイスで一連の cmdlets を実行します。

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

次の手順では、既存の標準ドメインを SAML 2.0 SP-Lite を使用したフェデレーション済みドメインに変換する方法について説明します。この手順を実行した場合、ユーザーに対しドメインを最大 2 時間停止する影響がある場合があります。

Office 365 テナントでのフェデレーション用のドメインの構成

  1. テナント管理者として Office 365 テナントに接続します。Connect-MsolService .

  2. SAML 2.0 でフェデレーションを使用するために必要な Office 365 ドメインの構成:

    $dom = "contoso.com" $BrandName - "Sample SAML 2.0 IDP" $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" $MySigningCert = @" MIIC7jCCAdagAwIBAgIQRrjsbFPaXIlOG3GTv50fkjANBgkqhkiG9w0BAQsFADAzMTEwLwYDVQQDEyh BREZTIFNpZ25pbmcgLSBXUzIwMTJSMi0wLnN3aW5mb3JtZXIuY29tMB4XDTE0MDEyMDE1MTY0MFoXDT E1MDEyMDE1MTY0MFowMzExMC8GA1UEAxMoQURGUyBTaWduaW5nIC0gV1MyMDEyUjItMC5zd2luZm9yb WVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKe+rLVmXy1QwCwZwqgbbp1/kupQ VcjKuKLitVDbssFyqbDTjP7WRjlVMWAHBI3kgNT7oE362Gf2WMJFf1b0HcrsgLin7daRXpq4Qi6OA57 sW1YFMj3sqyuTP0eZV3S4+ZbDVob6amsZIdIwxaLP9Zfywg2bLsGnVldB0+XKedZwDbCLCVg+3ZWxd9 T/jV0hpLIIWr+LCOHqq8n8beJvlivgLmDJo8f+EITnAxWcsJUvVai/35AhHCUq9tc9sqMp5PWtabAEM b2AU72/QlX/72D2/NbGQq1BWYbqUpgpCZ2nSgvlWDHlCiUo//UGsvfox01kjTFlmqQInsJVfRxF5AcC AwEAATANBgkqhkiG9w0BAQsFAAOCAQEAi8c6C4zaTEc7aQiUgvnGQgCbMZbhUXXLGRpjvFLKaQzkwa9 eq7WLJibcSNyGXBa/SfT5wJgsm3TPKgSehGAOTirhcqHheZyvBObAScY7GOT+u9pVYp6raFrc7ez3c+ CGHeV/tNvy1hJNs12FYH4X+ZCNFIT9tprieR25NCdi5SWUbPZL0tVzJsHc1y92b2M2FxqRDohxQgJvy JOpcg2mSBzZZIkvDg7gfPSUXHVS1MQs0RHSbwq/XdQocUUhl9/e/YWCbNNxlM84BxFsBUok1dH/gzBy Sx+Fc8zYi7cOq9yaBT3RLT6cGmFGVYZJW4FyhPZOCLVNsLlnPQcX3dDg9A==" "@ $uri = "http://WS2012R2-0.contoso.com/adfs/services/trust" $Protocol = "SAMLP" Set-MsolDomainAuthentication ` -DomainName $dom -FederationBrandName $dom -Authentication Federated -PassiveLogOnUri $MyURI -ActiveLogOnUri $ecpUrl -SigningCertificate $MySigningCert -IssuerUri $uri -LogOffUri $url -PreferredAuthenticationProtocol $Protocol 
    

    注:IDP メタデータ ファイルから、署名証明書 base64 エンコード文字列を取得できます。この場所の例は次のとおりですが、実装によって若干形式は異なります。

    <IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"> <KeyDescriptor use="signing"> <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"> <X509Data> <X509Certificate>MIIC5jCCAc6gAwIBAgIQLnaxUPzay6ZJsC8HVv/QfTANBgkqhkiG9w0BAQsFADAvMS0wKwYDVQQDEyRBREZTIFNpZ25pbmcgLSBmcy50ZWNobGFiY2VudHJhbC5vcmcwHhcNMTMxMTA0MTgxMzMyWhcNMTQxMTA0MTgxMzMyWjAvMS0wKwYDVQQDEyRBREZTIFNpZ25pbmcgLSBmcy50ZWNobGFiY2VudHJhbC5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwMdVLTr5YTSRp+ccbSpuuFeXMfABD9mVCi2wtkRwC30TIyPdORz642MkurdxdPCWjwgJ0HW6TvXwcO9afH3OC5V//wEGDoNcI8PV4enCzTYFe/h//w51uqyv48Fbb3lEXs+aVl8155OAj2sO9IX64OJWKey82GQWK3g7LfhWWpp17j5bKpSd9DBH5pvrV+Q1ESU3mx71TEOvikHGCZYitEPywNeVMLRKrevdWI3FAhFjcCSO6nWDiMqCqiTDYOURXIcHVYTSof1YotkJ4tG6mP5Kpjzd4VQvnR7Pjb47nhIYG6iZ3mR1F85Ns9+hBWukQWNN2hcD/uGdPXhpdMVpBAgMBAAEwDQYJKoZIhvcNAQELBQADggEBAK7h7jF7wPzhZ1dPl4e+XMAr8I7TNbhgEU3+oxKyW/IioQbvZVw1mYVCbGq9Rsw4KE06eSMybqHln3w5EeBbLS0MEkApqHY+p68iRpguqa+W7UHKXXQVgPMCpqxMFKonX6VlSQOR64FgpBme2uG+LJ8reTgypEKspQIN0WvtPWmiq4zAwBp08hAacgv868c0MM4WbOYU0rzMIR6Q+ceGVRImlCwZ5b7XKp4mJZ9hlaRjeuyVrDuzBkzROSurX1OXoci08yJvhbtiBJLf3uPOJHrhjKRwIt2TnzS9ElgFZlJiDIA26Athe73n43CT0af2IG6yC7e6sK4L3NEXJrwwUZk=</X509Certificate> </X509Data> </KeyInfo> </KeyDescriptor> 
    

    "Set-MsolDomainAuthentication" の詳細については、http://technet.microsoft.com/library/dn194112.aspx からダウンロードする必要があります。

    注意

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

    フェデレーションが構成されたら、"フェデレーションされていない" (または "管理されている") に戻ることができます。ただし、この変更の完了には最大で 2 時間がかかり、クラウド ベースのサインインで、各ユーザーに新しいランダムなパスワードを割り当てなければならなくなります。設定のエラーをリセットするために、一部のシナリオでは "管理されている" に切り替える必要がある場合があります。ドメインの変換の詳細については、http://msdn.microsoft.com/library/windowsazure/dn194122.aspx からダウンロードする必要があります。

Azure AD および Office 365 へのユーザー プリンシパルのプロビジョニング

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

DirSync ツールを使用すると、オンプレミスの Active Directory から Office 365 テナントのドメインにプリンシパルをプロビジョニングできます。詳細については、http://technet.microsoft.com/library/hh967642.aspx からダウンロードする必要があります。

Windows PowerShell を使用して、Azure AD に新しいユーザーを自動で追加したり、オンプレミス ディレクトリの変更を同期したりすることもできます。Windows PowerShell コマンドレットを使用するには、Azure Active Directory モジュールを http://technet.microsoft.com/library/jj151815.aspx からダウンロードする必要があります。

単一のユーザーを Azure AD に追加する手順を次に示します。

  1. テナント管理者として Office 365 テナントに接続します。Connect-MsolService.

  2. 新しいユーザー プリンシパルの作成:

    New-MsolUser ` 
    -UserPrincipalName elwoodf1@contoso.com
    -ImmutableId ABCDEFG1234567890
    -DisplayName "Elwood Folk"
    -FirstName Elwood 
    -LastName Folk 
    -AlternateEmailAddresses "Elwood.Folk@contoso.com" 
    -LicenseAssignment "samlp2test:ENTERPRISEPACK" 
    -UsageLocation "US" 
    

    "New-MsolUser" チェックアウトの詳細は、http://technet.microsoft.com/en-us/library/dn194096.aspx を参照してください。

注意

"UserPrinciplName" 値は SAML 2.0 要求で送信する "IDPEmail" と一致している必要があり、"ImmutableID" 値は "NameID" アサーションで送信する値と一致している必要があります。

SAML 2.0 IDP でのシングル サインオンの検証

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

  1. Azure AD SAML 2.0 のプロトコル要件を確認済み

  2. SAML 2.0 ID プロバイダーが構成済み

  3. SAML 2.0 ID プロバイダーでのシングル サインオンのために Windows PowerShell をインストールする

  4. SAML 2.0 ID プロバイダーと Azure AD の間で信頼を確立する

  5. Windows PowerShell または DirSync を介して、既知のテスト ユーザー プリンシパルを Azure Active Directory (Office 365) にプロビジョニング済み

  6. ディレクトリ同期のロードマップ」の詳細な手順に従って、ディレクトリ同期を準備してアクティブ化し、ツールをインストールして検証します。

SAML 2.0 SP-Lite ベースの ID プロバイダーでシングル サインオンを設定後、正しく動作していることを確認する必要があります。

注意

ドメインを追加したのではなく、変換した場合、シングル サインオンの設定には最大で 24 時間かかる場合があります。

シングル サインオンを検証する前に、Active Directory の同期の設定を完了し、ディレクトリを同期し、同期したユーザーをアクティブ化する必要があります。DirSync を使用している場合は、「ディレクトリ同期のロードマップ」を参照してください。

ツールを使用したシングル サインオンの設定が正しいことの検証

シングル サインオンが正しく設定されたことを検証するには、次の手順を実行して、企業の資格証明でクラウド サービスにサインインできることを確認します。マイクロソフトでは、さまざまな使用シナリオで AD FS を、テスト シングル サインオンでテストする際のガイダンスを TechNet で提供しています。

マイクロソフトでは、SAML 2.0 ベースの ID プロバイダーをテストするためのツールを用意しています。テスト ツールを実行する前に、ID プロバイダーとフェデレーションするために、Azure AD テナントを構成する必要があります。

注意

接続アナライザーでは、Internet Explorer 10 以降が必要です。

  1. 接続アナライザーは、https://testconnectivity.microsoft.com/?tabid=Client からダウンロードできます。

  2. [今すぐインストール] をクリックし、ツールのダウンロードおよびインストールを開始します。ツールのダウンロードおよび起動後のスクリーンショットを次に示します。

    Connectivity Analyzer を使用してシングル サインオンを確認する

    [Office 365、Azure、または Azure Active Directory を使用するその他のサービスでフェデレーションを設定できません] を選択します。

  3. ツールをダウンロードおよび実行後、[接続診断] ウィンドウが表示されます。このツールでは、フェデレーションの接続を順番にテストできます。

    Connectivity Analyzer を使用してシングル サインオンを確認する

  4. 接続アナライザーによってログオンのための SAML 2.0 IDP が開くので、テストするユーザー プリンシパルの資格証明を入力します。

    Connectivity Analyzer を使用してシングル サインオンを確認する

  5. フェデレーション テストのサインイン ウィンドウで、SAML 2.0 ID プロバイダーとフェデレーションするよう構成されている Azure AD テナントのアカウント名とパスワードを入力します。ツールによってそれらの資格証明を使用したサインインが試行され、サインインの試行時に実行されたテストの詳細な結果が出力として提供されます。

    Connectivity Analyzer を使用してシングル サインオンを確認する

  6. このウィンドウには、失敗したテストも示されます。[詳細結果をレビュー] をクリックすると、実行された各テストの結果の情報が示されます。ディスクに結果を保存して、これを共有することも可能です。

    注意

    接続アナライザーでは、WS* ベースおよび ECP/PAOS プロトコルを使用したアクティブ フェデレーションもテストしますが、これらを使用しない場合は、"ID プロバイダーのアクティブ フェデレーション ポイントを使用した、アクティブ サインイン フローをテストしています。" のエラーは無視できます。

手動でのシングル サインオンの設定が正しいことの検証

手動での検証する場合には、SAML 2.0 ID プロバイダーが多くのシナリオで正しく動作していることを確認できる追加の手順があります。

シングル サインオンの設定が正しいことを検証するには、次の手順を完了します。

  1. ドメインに参加しているコンピューターで、企業の資格証明書用に使用したものと同じログオン名を使用して、クラウド サービスにログオンします。

  2. パスワード ボックスの中をクリックします。シングル サインオンが設定されている場合、パスワード ボックスは影付きになり、"<会社> にサインインする必要があります。" のメッセージが表示されます。

  3. [<会社> にサインイン] リンクをクリックします。サインインできたら、シングル サインオンが設定されます。

関連項目

概念

DirSync とシングル サインオン