使用 SAML 2.0 标识提供者 (IdP) 进行单一登录Use a SAML 2.0 Identity Provider (IdP) for Single Sign On

本文档介绍有关将基于符合 SAML 2.0 的 SP-Lite 配置文件的标识提供者作为首选安全令牌服务 (STS)/标识提供者的信息。This document contains information on using a SAML 2.0 compliant SP-Lite profile-based Identity Provider as the preferred Security Token Service (STS) / identity provider. 如果已经在本地拥有可以使用 SAML 2.0 访问的用户目录和密码存储,此方案将非常有用。This scenario is useful when you already have a user directory and password store on-premises that can be accessed using SAML 2.0. 可以使用这个现有的用户目录登录到 Office 365 和其他受 Azure AD 保护的资源。This existing user directory can be used for sign-on to Office 365 and other Azure AD-secured resources. SAML 2.0 SP-Lite 配置文件基于基于广泛使用的安全断言标记语言 (SAML) 联合标识标准,可提供登录和属性交换框架。The SAML 2.0 SP-Lite profile is based on the widely used Security Assertion Markup Language (SAML) federated identity standard to provide a sign-on and attribute exchange framework.

备注

如需经测试可用于 Azure AD 的第三方 Idp 的列表,请参阅 Azure AD 联合身份验证兼容性列表For a list of 3rd party Idps that have been tested for use with Azure AD see the Azure AD federation compatibility list

Microsoft 支持此登录体验,允许将 Azure 云服务(例如 Office 365)与正确配置的基于 SAML 2.0 配置文件的 IdP 集成。Microsoft supports this sign-on experience as the integration of a Azure cloud service, such as Office 365, with your properly configured SAML 2.0 profile-based IdP. SAML 2.0 标识提供者是第三方产品,因此 Microsoft 不会对与之相关的部署、配置、故障排除最佳实践提供支持。SAML 2.0 identity providers are third-party products and therefore Microsoft does not provide support for the deployment, configuration, troubleshooting best practices regarding them. 正确配置后,可以使用 Microsoft Connectivity Analyzer 工具来测试是否已正确配置了与 SAML 2.0 标识提供者的集成,下文将详细介绍。Once properly configured, the integration with the SAML 2.0 identity provider can be tested for proper configuration by using the Microsoft Connectivity Analyzer Tool, which is described in more detail below. 有关基于 SAML 2.0 SP-Lite 配置文件的标识提供者的详细信息,请咨询其提供组织。For more information about your SAML 2.0 SP-Lite profile-based identity provider, ask the organization that supplied it.

重要

在使用 SAML 2.0 标识提供者的这个登录方案中,仅可使用有限的一组客户端,其中包括:Only a limited set of clients are available in this sign-on scenario with SAML 2.0 identity providers, this includes:

  • 基于 Web 的客户端,例如 Outlook Web Access 和 SharePoint OnlineWeb-based clients such as Outlook Web Access and SharePoint Online
  • 多重格式电子邮件客户端,使用基本身份验证以及受支持的 Exchange 访问方法,例如 IMAP、POP、Active Sync、MAPI 等(需部署增强型客户端协议终结点)。此类客户端包括:Email-rich clients that use basic authentication and a supported Exchange access method such as IMAP, POP, Active Sync, MAPI, etc. (the Enhanced Client Protocol end point is required to be deployed), including:
    • Microsoft Outlook 2010/Outlook 2013/Outlook 2016、Apple iPhone(各种 iOS 版本)Microsoft Outlook 2010/Outlook 2013/Outlook 2016, Apple iPhone (various iOS versions)
    • 各种 Google Android 设备Various Google Android Devices
    • Windows Phone 7、Windows Phone 7.8 和 Windows Phone 8.0Windows Phone 7, Windows Phone 7.8, and Windows Phone 8.0
    • Windows 8 邮件客户端和 Windows 8.1 邮件客户端Windows 8 Mail Client and Windows 8.1 Mail Client
    • Windows 10 邮件客户端Windows 10 Mail Client

在使用 SAML 2.0 标识提供者的这个登录方案中,所有其他客户端均不可用。All other clients are not available in this sign-on scenario with your SAML 2.0 Identity Provider. 例如,Lync 2010 桌面客户端不能登录到已将 SAML 2.0 标识提供者配置为进行单一登录的服务。For example, the Lync 2010 desktop client is not able to sign in to the service with your SAML 2.0 Identity Provider configured for single sign-on.

Azure AD SAML 2.0 协议要求Azure AD SAML 2.0 protocol requirements

本文档包含与 Azure AD 一起进行联合身份验证以便登录到一个或多个 Azure 云服务(例如 Office 365)时,SAML 2.0 标识提供者必须实现的协议和消息格式设置的详细要求。This document contains detailed requirements on the protocol and message formatting that your SAML 2.0 identity provider must implement to federate with Azure AD to enable sign-on to one or more Azure cloud services (such as Office 365). 本方案中使用的 Azure 云服务的 SAML 2.0 信赖方 (SP-STS) 为 Azure AD。The SAML 2.0 relying party (SP-STS) for a Azure cloud service used in this scenario is Azure AD.

建议你确保 SAML 2.0 标识提供者输出消息尽可能与提供的示例跟踪类似。It is recommended that you ensure your SAML 2.0 identity provider output messages be as similar to the provided sample traces as possible. 另外,请尽可能使用来自所提供的 Azure AD 元数据的特定属性值。Also, use specific attribute values from the supplied Azure AD metadata where possible. 对输出消息满意以后,即可使用 Microsoft Connectivity Analyzer 进行测试,如下所述。Once you are happy with your output messages, you can test with the Microsoft Connectivity Analyzer as described below.

可以从此 URL 下载 Azure AD 元数据:https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xmlThe Azure AD metadata can be downloaded from this URL: https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml. 对于使用中国特定的 Office 365 实例的中国客户而言,应使用以下联合终结点:https://nexus.partner.microsoftonline-p.cn/federationmetadata/saml20/federationmetadata.xmlFor customers in China using the China-specific instance of Office 365, the following federation endpoint should be used: https://nexus.partner.microsoftonline-p.cn/federationmetadata/saml20/federationmetadata.xml.

SAML 协议要求SAML protocol requirements

本部署详述如何将请求和响应消息对放置在一起,以便正确设置消息格式。This section details how the request and response message pairs are put together in order to help you to format your messages correctly.

Azure AD 在进行配置后可以用于标识提供者,后者使用 SAML 2.0 SP Lite 配置文件,其中的部分具体要求已在下面列出。Azure AD can be configured to work with identity providers that use the SAML 2.0 SP Lite profile with some specific requirements as listed below. 可以使用示例性的 SAML 请求和响应消息进行自动和手动测试,从而实现与 Azure AD 的互操作性。Using the sample SAML request and response messages along with automated and manual testing, you can work to achieve interoperability with Azure AD.

签名块要求Signature block requirements

在 SAML 响应消息中,签名节点包含有关消息本身的数字签名的信息。Within the SAML Response message, the Signature node contains information about the digital signature for the message itself. 签名块具有以下要求:The signature block has the following requirements:

  1. 断言节点本身必须签名The assertion node itself must be signed
  2. 必须使用 RSA-sha1 算法作为 DigestMethod。The RSA-sha1 algorithm must be used as the DigestMethod. 不接受其他数字签名算法。Other digital signature algorithms are not accepted. <ds:DigestMethod Algorithm="https://www.w3.org/2000/09/xmldsig#sha1"/>
  3. 也可对 XML 文档签名。You may also sign the XML document.
  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#"/>The Transform Algorithm must match the values in the following sample: <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"/>The SignatureMethod Algorithm must match the following sample: <ds:SignatureMethod Algorithm="https://www.w3.org/2000/09/xmldsig#rsa-sha1"/>

支持的绑定Supported bindings

绑定是所需的传输相关通信参数。Bindings are the transport-related communications parameters that are required. 以下要求适用于绑定:The following requirements apply to the bindings

  1. HTTPS 是所需的传输。HTTPS is the required transport.
  2. Azure AD 将需要使用 HTTP POST 在登录期间提交令牌。Azure AD will require HTTP POST for token submission during sign-in.
  3. Azure AD 将使用 HTTP POST 向标识提供者提交身份验证请求,并使用 REDIRECT 向标识提供者发送“注销”消息。Azure AD will use HTTP POST for the authentication request to the identity provider and REDIRECT for the sign out message to the identity provider.

必需属性Required attributes

下表显示了针对 SAML 2.0 消息中的特定属性的要求。This table shows requirements for specific attributes in the SAML 2.0 message.

属性Attribute 说明Description
NameIDNameID 此断言语句的值必须与 Azure AD 用户的 ImmutableID 相同。The value of this assertion must be the same as the Azure AD user’s ImmutableID. 它最多可以有 64 个字母数字字符。It can be up to 64 alpha numeric characters. 任何非 html 安全型字符都必须进行编码,例如,“+”字符显示为“.2B”。Any non-html safe characters must be encoded, for example a “+” character is shown as “.2B”.
IDPEmailIDPEmail 用户主体名称 (UPN) 将以名为 IDPEmail 的元素的形式列入 SAML 响应中,这是用户在 Azure AD/Office 365 中的 UserPrincipalName (UPN)。The User Principal Name (UPN) is listed in the SAML response as an element with the name IDPEmail The user’s UserPrincipalName (UPN) in Azure AD/Office 365. UPN 采用电子邮件地址格式。The UPN is in email address format. Windows Office 365 (Azure Active Directory) 中的 UPN 值。UPN value in Windows Office 365 (Azure Active Directory).
颁发者Issuer 必须是标识提供者的 URI。Required to be a URI of the identity provider. 不得重复使用示例消息中的颁发者。Do not reuse the Issuer from the sample messages. 如果在 Azure AD 租户中有多个顶级域,则 Issuer 必须与针对每个域配置的指定 URI 设置匹配。If you have multiple top-level domains in your Azure AD tenants the Issuer must match the specified URI setting configured per domain.

重要

Azure AD 目前支持下述适用于 SAML 2.0 的 NameID 格式 URI:urn:oasis:names:tc:SAML:2.0:nameid-format:persistent。Azure AD currently supports the following NameID Format URI for SAML 2.0:urn:oasis:names:tc:SAML:2.0:nameid-format:persistent.

SAML 请求与响应消息示例Sample SAML request and response messages

显示的请求与响应消息对是针对登录消息交换的。A request and response message pair is shown for the sign-on message exchange. 以下是从 Azure AD 发送到示例 SAML 2.0 标识提供者的示例请求消息。The following is a sample request message that is sent from Azure AD to a sample SAML 2.0 identity provider. 示例 SAML 2.0 标识提供者为 Active Directory 联合身份验证服务 (AD FS),已配置为使用 SAML-P 协议。The sample SAML 2.0 identity provider is Active Directory Federation Services (AD FS) configured to use SAML-P protocol. 此外,还针对其他 SAML 2.0 标识提供者完成了互操作性测试。Interoperability testing has also been completed with other SAML 2.0 identity providers.

    <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 的标识提供者发送到 Azure AD/Office 365 的示例响应消息。The following is a sample response message that is sent from the sample SAML 2.0 compliant identity provider to 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.partner.microsoftonline.cn/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/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="https://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.partner.microsoftonline.cn/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 的标识提供者Configure your SAML 2.0 compliant identity provider

本部分包含的准则适用于配置 SAML 2.0 标识提供者,目的是通过与 Azure AD 一起进行联合身份验证,使用 SAML 2.0 协议以单一登录方式访问一个或多个 Azure 云服务(例如 Office 365)。This section contains guidelines on how to configure your SAML 2.0 identity provider to federate with Azure AD to enable single sign-on access to one or more Azure cloud services (such as Office 365) using the SAML 2.0 protocol. 本方案中使用的 Azure 云服务的 SAML 2.0 信赖方为 Azure AD。The SAML 2.0 relying party for a Azure cloud service used in this scenario is Azure AD.

添加 Azure AD 元数据Add Azure AD metadata

SAML 2.0 标识提供者需遵循有关 Azure AD 信赖方的信息要求。Your SAML 2.0 identity provider needs to adhere to information about the Azure AD relying party. Azure AD 会在 https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml 上发布元数据。Azure AD publishes metadata at https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml.

建议你在配置 SAML 2.0 标识提供者时,始终导入最新的 Azure AD 元数据。It is recommended that you always import the latest Azure AD metadata when configuring your SAML 2.0 identity provider.

备注

Azure AD 不会从标识提供者读取元数据。Azure AD does not read metadata from the identity provider.

将 Azure AD 作为信赖方添加Add Azure AD as a relying party

必须启用 SAML 2.0 标识提供者与 Azure AD 之间的通信。You must enable communication between your SAML 2.0 identity provider and Azure AD. 此配置取决于具体的的标识提供者,请参阅其文档。This configuration will be dependent on your specific identity provider and you should refer to documentation for it. 通常应将信赖方 ID 设置为与 Azure AD 元数据中的 entityID 相同。You would typically set the relying party ID to the same as the entityID from the Azure AD metadata.

备注

请验证 SAML 2.0 标识提供者服务器上的时钟是否已与准确的时间源同步。Verify the clock on your SAML 2.0 identity provider server is synchronized to an accurate time source. 时钟的时间不准确可能导致联合身份验证登录失败。An inaccurate clock time can cause federated logins to fail.

安装 Windows PowerShell 以使用 SAML 2.0 标识提供者进行登录Install Windows PowerShell for sign-on with SAML 2.0 identity provider

配置用于 Azure AD 登录的 SAML 2.0 标识提供者以后,下一步是下载并安装用于 Windows PowerShell 的 Azure Active Directory 模块。After you have configured your SAML 2.0 identity provider for use with Azure AD sign-on, the next step is to download and install the Azure Active Directory Module for Windows PowerShell. 安装以后,即可使用这些 cmdlet 将 Azure AD 域配置为联合域。Once installed, you will use these cmdlets to configure your Azure AD domains as federated domains.

用于 Windows PowerShell 的 Azure Active Directory 模块在下载后可用于管理 Azure AD 中的组织数据。The Azure Active Directory Module for Windows PowerShell is a download for managing your organizations data in Azure AD. 此模块会将一组 cmdlet 安装到 Windows PowerShell。This module installs a set of cmdlets to Windows PowerShell.

在 SAML 标识提供者与 Azure AD 之间建立信任Set up a trust between your SAML identity provider and Azure AD

在 Azure AD 域上配置联合身份验证之前,必须已配置自定义域。Before configuring federation on an Azure AD domain, it must have a custom domain configured. 不能联合 Microsoft 提供的默认域。You cannot federate the default domain that is provided by Microsoft. Microsoft 提供的默认域以“partner.onmschina.cn”结尾。The default domain from Microsoft ends with “partner.onmschina.cn”.

每个需要使用 SAML 2.0 标识提供者进行联合身份验证的 Azure Active Directory 域都必须作为单一登录域添加,或者必须从标准域转换为单一登录域。Each Azure Active Directory domain that you want to federate using your SAML 2.0 identity provider must either be added as a single sign-on domain or converted to be a single sign-on domain from a standard domain. 添加或转换域可以在 SAML 2.0 标识提供者和 Azure AD 之间建立信任。Adding or converting a domain sets up a trust between your SAML 2.0 identity provider and Azure AD.

以下过程演示如何使用 SAML 2.0 SP-Lite 将现有的标准域转换为联合身份验证域。The following procedure walks you through converting an existing standard domain to a federated domain using SAML 2.0 SP-Lite.

备注

执行这一步后,域可能会遇到服务中断而影响用户,最长可持续 2 小时。Your domain may experience an outage that impacts users up to 2 hours after you take this step.

在 Azure AD Directory 中配置进行联合身份验证的域Configuring a domain in your Azure AD Directory for federation

  1. 以租户管理员身份连接到 Azure AD Directory:Connect to your Azure AD Directory as a tenant administrator:

    Connect-MsolService -AzureEnvironment AzureChinaCloud
    
  2. 通过 SAML 2.0 将所需的 Office 365 域配置为使用联合:Configure your desired Office 365 domain to use federation with SAML 2.0:

    $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 $BrandName `
        -Authentication Federated `
        -PassiveLogOnUri $LogOnUrl `
        -ActiveLogOnUri $ecpUrl `
        -SigningCertificate $MySigningCert `
        -IssuerUri $MyURI `
        -LogOffUri $LogOffUrl `
        -PreferredAuthenticationProtocol $Protocol
    
  3. 可以从 IDP 元数据文件中获取签名证书的 base64 编码字符串。You can obtain the signing certificate base64 encoded string from your IDP metadata file. 已提供此位置的示例,但该示例视实现情况可能稍有不同。An example of this location has been provided but may differ slightly based on your implementation.

    <IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
        <KeyDescriptor use="signing">
          <KeyInfo xmlns="https://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>
    </IDPSSODescriptor>
    

有关“Set-MsolDomainAuthentication”的详细信息,请参阅:https://technet.microsoft.com/library/dn194112.aspxFor more information about “Set-MsolDomainAuthentication”, see: https://technet.microsoft.com/library/dn194112.aspx.

备注

仅当为标识提供者设置了 ECP 扩展时,才必须使用 $ecpUrl = "https://WS2012R2-0.contoso.com/PAOS"You must use $ecpUrl = "https://WS2012R2-0.contoso.com/PAOS" only if you set up an ECP extension for your identity provider. 除 Outlook Web Application (OWA) 之外的 Exchange Online 客户端依赖于基于 POST 的活动终结点。Exchange Online clients, excluding Outlook Web Application (OWA), rely on a POST based active end point. 如果 SAML 2.0 STS 实现的活动终结点类似于 Shibboleth 对活动终结点的 ECP 实现,则这些富客户端可能会与 Exchange Online 服务交互。If your SAML 2.0 STS implements an active end point similar to Shibboleth’s ECP implementation of an active end point it may be possible for these rich clients to interact with the Exchange Online service.

配置联合后,可切换回“非联合”(或“托管”),但是此更改最长需要两个小时才能完成,并且需要为每个用户分配新的随机密码以用于基于云的登录。Once federation has been configured you can switch back to “non-federated” (or “managed”), however this change takes up to two hours to complete and it requires assigning new random passwords for cloud-based sign-in to each user. 在某些情况下,可能需切换回“托管”模式才能在设置中重置错误。Switching back to “managed” may be required in some scenarios to reset an error in your settings. 有关域转换的详细信息,请参阅:https://msdn.microsoft.com/library/windowsazure/dn194122.aspxFor more information on Domain conversion see: https://msdn.microsoft.com/library/windowsazure/dn194122.aspx.

预配 Azure AD/Office 365 的用户主体Provision user principals to Azure AD / Office 365

在对 Office 365 进行用户身份验证之前,必须向 Azure AD 预配与 SAML 2.0 声明中的断言相对应的用户主体。Before you can authenticate your users to Office 365, you must provision Azure AD with user principals that correspond to the assertion in the SAML 2.0 claim. 如果 Azure AD 事先无法识别这些用户主体,则它们无法用于联合登录。If these user principals are not known to Azure AD in advance, then they cannot be used for federated sign-in. 可以使用 Azure AD Connect 或 Windows PowerShell 来预配用户主体。Either Azure AD Connect or Windows PowerShell can be used to provision user principals.

可以使用 Azure AD Connect 从本地 Active Directory 预配 Azure AD 目录中域的主体。Azure AD Connect can be used to provision principals to your domains in your Azure AD Directory from the on-premises Active Directory. 如需更多详细信息,请参阅将本地目录与 Azure Active Directory 集成For more detailed information, see Integrate your on-premises directories with Azure Active Directory.

也可使用 Windows PowerShell 自动将新用户添加到 Azure AD 并同步本地目录中的更改。Windows PowerShell can also be used to automate adding new users to Azure AD and to synchronize changes from the on-premises directory. 若要使用 Windows PowerShell cmdlet,必须下载 Azure Active Directory 模块To use the Windows PowerShell cmdlets, you must download the Azure Active Directory Modules.

以下过程演示如何向 Azure AD 添加单个用户。This procedure shows how to add a single user to Azure AD.

  1. 以租户管理员身份连接到 Azure AD Directory:Connect-MsolService -AzureEnvironment AzureChinaCloud。Connect to your Azure AD Directory as a tenant administrator: Connect-MsolService -AzureEnvironment AzureChinaCloud.

  2. 创建新用户主体:Create a new user principal:

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

有关“New-MsolUser”签出的详细信息,请参阅:https://technet.microsoft.com/library/dn194096.aspxFor more information about “New-MsolUser” checkout, https://technet.microsoft.com/library/dn194096.aspx

备注

“UserPrinciplName”值必须与将在 SAML 2.0 声明中为“IDPEmail”发送的值匹配,“ImmutableID”值必须与在“NameID”断言语句中发送的值匹配。The “UserPrinciplName” value must match the value that you will send for “IDPEmail” in your SAML 2.0 claim and the “ImmutableID” value must match the value sent in your “NameID” assertion.

通过 SAML 2.0 IDP 验证单一登录Verify single sign-on with your SAML 2.0 IDP

在以管理员身份验证和管理单一登录(也称联合身份验证)之前,请查看以下文章中的信息并执行相关步骤,以便通过基于 SAML 2.0 SP-Lite 的标识提供者设置单一登录:As the administrator, before you verify and manage single sign-on (also called identity federation), review the information and perform the steps in the following articles to set up single sign-on with your SAML 2.0 SP-Lite based identity provider:

  1. 查看 Azure AD SAML 2.0 协议要求You have reviewed the Azure AD SAML 2.0 Protocol Requirements
  2. 配置 SAML 2.0 标识提供者You have configured your SAML 2.0 identity provider
  3. 安装 Windows PowerShell 以使用 SAML 2.0 标识提供者进行单一登录Install Windows PowerShell for single sign-on with SAML 2.0 identity provider
  4. 在 SAML 2.0 标识提供者与 Azure AD 之间建立信任Set up a trust between SAML 2.0 identity provider and Azure AD
  5. 通过 Windows PowerShell 或 Azure AD Connect 预配 Azure Active Directory (Office 365) 的已知测试用户主体。Provisioned a known test user principal to Azure Active Directory (Office 365) either through Windows PowerShell or Azure AD Connect.
  6. 使用 Azure AD Connect 配置目录同步。Configure directory synchronization using Azure AD Connect.

通过基于 SAML 2.0 SP-Lite 的标识提供者设置单一登录以后,应验证其是否正常工作。After setting up single sign-on with your SAML 2.0 SP-Lite based identity Provider, you should verify that it is working correctly.

备注

如果转换而不是添加域,则可能需要长达 24 小时来设置单一登录。If you converted a domain, rather than adding one, it may take up to 24 hours to set up single sign-on. 在验证单一登录之前,应完成 Active Directory 同步的设置,对目录进行同步,并激活同步的用户。Before you verify single sign-on, you should finish setting up Active Directory synchronization, synchronize your directories, and activate your synced users.

使用工具验证单一登录是否已正确设置Use the tool to verify that single sign-on has been set up correctly

若要验证是否已正确设置单一登录,可以执行以下过程来确认能否使用企业凭据登录到云服务。To verify that single sign-on has been set up correctly, you can perform the following procedure to confirm that you are able to sign-in to the cloud service with your corporate credentials.

Microsoft 提供了一种工具,用于测试基于 SAML 2.0 的标识提供者。Microsoft has provided a tool that you can use to test your SAML 2.0 based identity provider. 在运行测试工具之前,必须将一个 Azure AD 租户配置为与标识提供者联合。Before running the test tool, you must have configured an Azure AD tenant to federate with your identity provider.

备注

Connectivity Analyzer 需要 Internet Explorer 10 或更高版本。The Connectivity Analyzer requires Internet Explorer 10 or later.

  1. https://testconnectivity.microsoft.com/?tabid=Client 下载连接分析器。Download the Connectivity Analyzer from, https://testconnectivity.microsoft.com/?tabid=Client.
  2. 单击“立即安装”开始下载并安装工具。Click Install Now to begin downloading and installing the tool.
  3. 选择“我不能通过 Office 365、Azure 或其他使用 Azure Active Directory 的服务设置联合身份验证”。Select “I can’t set up federation with Office 365, Azure, or other services that use Azure Active Directory”.
  4. 下载并运行该工具后,即可看到“连接性诊断”窗口。Once the tool is downloaded and running, you will see the Connectivity Diagnostics window. 该工具将逐步引导你测试联合身份验证连接。The tool will step you through testing your federation connection.
  5. Connectivity Analyzer 将开启 SAML 2.0 IDP 用以登录,请输入进行测试的用户主体凭据:SAMLThe Connectivity Analyzer will open your SAML 2.0 IDP for you to sign-in, enter the credentials for the user principal you are testing: SAML
  6. 在联合测试登录窗口,应为配置为与 SAML 2.0 标识提供者联合的 Azure AD 租户输入帐户名和密码。At the Federation test sign-in window, you should enter an account name and password for the Azure AD tenant that is configured to be federated with your SAML 2.0 identity provider. 该工具会尝试使用这些凭据登录,并会提供在登录尝试期间执行的测试的详细结果作为输出。The tool will attempt to sign-in using those credentials and detailed results of tests performed during the sign-in attempt will be provided as output. SAMLSAML
  7. 此窗口显示失败的测试结果。This window shows a failed result of testing. 单击“查看详细结果”会显示所执行的每次测试的结果的相关信息。Clicking on Review detailed results will show information about the results for each test that was performed. 也可将结果保存到磁盘,以便进行共享。You can also save the results to disk in order to share them.

备注

Connectivity Analyzer 也使用基于 WS* 的协议和 ECP/PAOS 协议测试活动联合身份验证。The Connectivity analyzer also tests Active Federation using the WS*-based and ECP/PAOS protocols. 如果你未使用这些项,则可以忽略以下错误:使用你的标识提供者的活动联合身份验证终结点测试活动登录流。If you are not using these you can disregard the following error: Testing the Active sign-in flow using your identity provider’s Active federation endpoint.

手动验证单一登录是否已正确设置Manually verify that single sign-on has been set up correctly

手动验证提供更多的步骤,可以利用这些步骤来确保 SAML 2.0 标识提供者在多种情形下正常运行。Manual verification provides additional steps that you can take to ensure that your SAML 2.0 identity Provider is working properly in many scenarios. 若要验证单一登录是否已正确设置,请完成以下步骤:To verify that single sign-on has been set up correctly, complete the following steps:

  1. 在已加入域的计算机上,使用用于公司凭据的相同登录名登录到云服务。On a domain-joined computer, sign-in to your cloud service using the same sign-in name that you use for your corporate credentials.
  2. 在密码框内单击。Click inside the password box. 如果设置了单一登录,则密码框会灰显,同时会显示以下消息:“你现在需在<你的公司>登录。”If single sign-on is set up, the password box will be shaded, and you will see the following message: “You are now required to sign-in at <your company>.”
  3. 单击<你的公司>链接中的登录。Click the Sign-in at <your company> link. 如果能够登录,则已设置好单一登录。If you are able to sign-in, then single sign-on has been set up.

后续步骤Next Steps