通过 AD FS 实现到 Windows Azure Pack 的联合身份 – 第 3 部分，共 3 部分

Artikkeli
05/21/2014

原文地址：https://blogs.technet.com/b/privatecloud/archive/2013/12/18/federated-identities-to-windows-azure-pack-through-ad-fs-part-3-of-3.aspx

在前面的几篇博文中，Anders Ravnholt 讨论了 WAP 的安装和配置并讨论了使用 FQDN、端口和信任证书重新配置的细节。在这个系列中，我要讨论如何配置 AD FS，让它向 WAP 安装提供身份。

场景

Contoso 公司是一家服务提供商，托管了一个私有云环境，向他们的客户提供计算资源。Contoso 希望安装一个 Windows Azure Pack 堆栈并且实现以下功能：

向来自其 Active Directory 的用户提供管理访问
向来自 Fabrikam 公司（Contoso 的客户之一）的用户提供租户门户的自助服务。

我们将这个场景分成三个部分。

在这个博文系列的第一部分，我们讨论了 Contoso 如何在他们公司的域 pcloud.contoso.corp 中设置一个 AD FS 实例。

在第二部分，我们讨论了 Contoso 如何设置 AD FS 实例和 WAP 管理门户之间的信任关系，并为它的用户提供到管理门户的访问。

在这个第三部分，我们将讨论 Contoso 如何在 Fabrikam 的 AD FS 和自己的 AD FS 之间建立信任关系，让 Fabrikam 的用户访问租户门户。

人员

Rob 是基础结构管理员，负责维护基础结构。 Rob 负责为 Contoso 公司安装 Windows Azure Pack。

Mary 是 Contoso Active Directory 中 pcloud.contoso.corp 域的管理员。Mary 拥有配置与这个域链接的 AD FS 所必需的权限。

Alan 是租户管理员，负责在 Windows Azure Pack 中创建和管理计划及订阅。

假设和范围

在这个博文中，我们对环境有以下假设：

在 pcloud.contoso.corp 域中已经设置了 Windows Azure Pack
pcloud.contoso.corp 域已经启用和配置了 AD FS
Fabrikam.corp 域已经启用和配置了 AD FS
环境中的所有组件都配置了来自可信 CA 的证书
Contoso 和 Fabrikam 均已设置了互相对话所必需的 DNS 路径

关于读者，我们也有以下假设：

熟悉 Windows Azure Pack 的安装。关于 Windows Azure Pack 部署的更多信息，请访问https://technet.microsoft.com/en-us/library/dn296432.aspx
对基于声明的验证有一定了解（请参阅白皮书https://download.microsoft.com/download/6/F/7/6F7BB9DD-0D65-492F-9180-75A47A520F80/Claims-Based Authentication in WAP.docx )
熟悉 AD FS 和 AD FS 控制台。关于 AD FS 的更多信息，请访问https://technet.microsoft.com/en-us/library/hh831502.aspx
这篇博文将介绍如何使用 AD FS 控制台执行这个场景
这篇博文不介绍如何使用 AD FS PowerShell 执行这个场景

场景概述

在开始解释如何建立联合之前，我要概述一下为了建立联合需要完成的步骤。

将WAP 租户门户作为依赖方加入Contoso 的 AD FS 这个任务完成后，AD FS 就知道租户门户依赖它来提供验证过的身份。这个过程在这个博文系列的第二部分的管理员门户部分已经介绍过。
将Contoso 的AD FS 添加为WAP 租户门户的声明提供程序这个任务完成后，租户门户就知道 AD FS 负责提供用户声明，用户必须在上面进行验证。这个过程在这个博文系列的第二部分的管理员门户部分已经介绍过。

在 Contoso 的 AD FS 和 Fabrikam 的 AD FS 之间存在类似关系：

将Contoso 的 AD FS 作为依赖方加入Fabrikam 的 AD FS 这个任务完成后，Fabrikam 的 AD FS 就知道 Contoso 的 AD FS 依赖它对其域内的用户进行验证。
将Fabrikam 的 AD FS 作为 Claim 提供程序加入Contoso 的 AD FS 这个任务完成后，Contoso 的 ADFS 就知道它可以相信 Fabrikam 的 AD FS，后者是联合链中信任的声明提供程序之一。

要建立正确的信任关系，使用户能够登录系统，以上四个步骤必须全部完成。

建立 Contoso 的 AD FS 和WAP 租户门户之间的信任关系

将 WAP 租户门户作为依赖方加入 Contoso 的 AD FS

这个过程在这个博文系列的第二部分的管理员门户部分已经介绍过。这里我们简要回顾一下。Contoso的域管理员 Mary 必须将 WAP 租户门户作为依赖方加入 AD FS，这样 AD FS 就知道租户门户要通过它来得到令牌。为了做到这点，从 AD FS 控制台启动 "Add Relying Party trust Wizard"。

她输入了 WAP 租户门户的联合元数据信息，典型格式是：
<https://<<租户门户url>>/federationmetadata/2007-06/federationmetadata.xml

Mary 提供了租户门户的友好名称，向导的后续步骤使用默认值不变。

现在 Mary 为租户门户添加声明转换规则，与添加到管理员门户的类似（请参阅这个博文系列的第二部分 )。

除此之外，她使用 Set-ADFSRelyingPartyTrust 命令确保租户门户得到 JWT Claim（请参阅这个博文系列的第二部分)

    1: Set-AdfsRelyingPartyTrust -TargetIdentifier

将 Contoso 的 AD FS 作为声明提供程序加入租户门户

基础结构管理员 Rob 登录 WAP，完成这个合作的第二部分。他在 WAP 租户门户上运行以下脚本，让门户知道自己需要依赖 AD FS 获得身份。

    1: $fqdn = 'adfs.pcloud.contoso.corp'
    2: $dbServer = 'ContosoWAP'
    3: $dbPassword = 'pass@word1'
    4: $portalConfigStoreConnectionString = [string]::Format('Data Source={0};Initial Catalog=Microsoft.MgmtSvc.PortalConfigStore;User ID=sa;Password={1}', $dbServer, $dbPassword)
    5:  
    6: Set-MgmtSvcRelyingPartySettings -Target Tenant `
    7: -MetadataEndpoint https://$fqdn/FederationMetadata/2007-06/FederationMetadata.xml `
    8: -ConnectionString $portalConfigStoreConnectionString

将 Fabrikam 的 AD FS 作为声明提供程序加入Contoso 的 AD FS

pcloud.contoso.corp 域的管理员 Mary 打开 AD FS 控制台，在右侧的操作窗格中单击 "Add Claims Provider Trust"。
在 Select Data Source 屏幕中，输入 Fabrikam 的 AD FS 的联合元数据信息的地址，典型格式是 https:// <adfs federation servicename>/federationmetadata/2007-06/federationmetadata.xml
也可以从上述地址下载文件，然后导入向导中。
下一步是提供 Fabrikam AD FS 的友好名称，为了便于识别，我们称之为 Fabrikam AD FS。
向导余下的步骤是配置多因素验证、颁发授权规则等等，这个场景目前不需要它们，所以均采用默认值，完成向导即可。在最后一步中， Mary 确保选中了 "Open the Edit Claim Rules dialog.." 复选框，并单击 "Close"。
在 "Add Transform Claim rule Wizard" 中，声明规则模板选择为 "Send LDAP Attributes as Claims" 并单击 Next。

下一步，Mary 提供友好规则名称，选择 Active Directory 作为 Attribute 库，在映射表格中，将 User-Principal-Name 映射到 UPN 传出声明。

重复同样的过程添加 Group Claim。选择 Token-Groups – Qualified by Domain 映射到Group 传出声明。
在某些情况下，AD FS 可能已经有一个 UPN。为了处理这些场景，还需要添加两个额外的规则，将 UPN 声明按原样传递。在 "Add Transform Claim rule Wizard" 中，选择 "Pass Through or Filter an Incoming Claim" 。

下一步，她提供规则的友好名称，指定传入声明类型为 UPN，并单击 Finish。

在 AD FS Management 弹出对话框中，Mary 单击 Yes。

对 Group Claim 重复同样的步骤。
现在已经为这个依赖方增加了全部四个规则，她最后单击 Apply，完成声明转换规则。
这个任务完成后，Mary 需要确保用户从 WAP 租户门户重定向到 AD FS 时，应该直接被带到 Fabrikam 的 AD FS 页面进行验证。这个任务由以下命令执行：

    1: Set-AdfsRelyingPartyTrust -TargetName "WAP Tenant Portal" -ClaimsProviderName @("Fabrikam AD FS")

将 Contoso AD FS 作为依赖方加入 Fabrikam 的 AD FS

要完成合作的第二部分，Fabrikam 的域管理员 George 应该将 Contoso 的 AD FS 作为依赖方加进来。这个过程与添加声明提供程序的过程相同，步骤也基本相同：

输入 Contoso 的 AD FS 联合元数据的地址。
指定注册依赖方的友好名称。
完成向导的其余步骤，可以选择合适的值，或者选择默认值。在完成向导时，会显示 'Add Transform Claim Rule Wizard'
在 "Add Transform Claim rule Wizard" 中，应该选择 "Send LDAP Attributes as Claims" 作为声明规则模板，并单击 Next。
下一步，他提供友好规则名称，选择 Active Directory 作为 Attribute 库，将User-Principal-Name 映射到 UPN 传出声明。
重复类似过程添加 Group Claim。选择 Token-Groups – Qualified by Domain 映射到Group 传出声明。
在某些情况下，AD FS 可能已经有一个 UPN。为了处理这些场景，还需要添加两个额外的规则，将 UPN 声明原样传递。在 "Add Transform Claim rule Wizard" 中，选择 "Pass Through or Filter an Incoming Claim" 。
下一步，他提供规则的友好名称，指定传入声明类型为 UPN，并单击 Finish。

对 Group Claim 重复类似的过程。
这个依赖方的全部四个规则都已经添加，最后他单击 Apply，完成声明转换规则。
这个任务完成后，George 需要确保 JWT 令牌被发送到 Contoso 的 AD FS。这个任务通过以下 Powershell 执行：
```
    1: Set-ADFSRelyingPartyTrust -TargetIdentifier https://adfs.pcloud.contoso.corp/adfs/services/trust -EnableJWT $true 
```