在对 Windows 8.1 客户端更新做了一番精彩探讨之后，我们想接着在 ASKPFEPLAT上介绍一个重要 Active Directory 联合身份验证服务 (AD FS) 功能，它是随 Windows Server 2012 R2 更新一起发布的。
我是 Keith Brewer，在这里我将介绍这个名为 AlternateLoginID 的 AD FS 登录增强功能。
本篇博文旨在讨论这一新功能，您可以在自己的 AD FS 实验室中测试这一功能。没有实验室？访问 此处开始构建 AD FS 实验室。
AlternateLoginID 是 Windows Server 2012 R2 更新中引入的一个功能，帮助使用系统定义的用户属性登录到 AD FS。
许多客户希望最终用户知悉其电子邮件，以便于在登录时使用。然而，在客户的 AD FS 环境内，管理员可能无法确保用户 UserPrincipalName (UPN) 和电子邮件相匹配。此外，在一些 AD DS 环境中，UPN 是不可公开路由的，这可能会给一些 SaaS 提供商带来挑战。
在 Windows Server 2012 R2 更新中，AD FS 为管理员提供了一个功能来支持用户通过备用登录 ID 进行登录，该 ID 是 AD FS 中用户对象的一个属性。
一经配置，AD FS 会优先根据已定义的备用属性（而非 UPN）定位 AD DS 内的用户帐户。
最终用户仍然可以使用 Active Directory 域服务 (AD DS) 接受的任何形式的用户标识符登录到依赖于 AD FS 的应用程序。这些标识符包括 UPN (johndoe@contoso.com) 或域限定的 SamAccountName (Contoso\johndoe or contoso.com\johndoe)。
为了支持这一功能，当用户通过 AlternateLoginID 的值成功完成身份验证时，一个新声明会进入声明管道。备用登录 ID 有一个新声明类型，描述如下：
http://schemas.microsoft.com/ws/2013/11/alternateloginid
· 显示名称：Alternate Login ID
· 描述：Alternate login of the user
（已于 2014 年 5 月 11 日更新，以进一步澄清声明描述）
实现 AlternateLoginID 功能不需要有 Alternate Login ID 声明描述。然而，如果管理员希望对此声明创建声明规则（正如我们出于演示目的在以下实验中所做的），可能需要手动添加声明描述。
默认情况下，仅在应用了更新的 Windows 2012 R2 上创建的 AD FS 场上有 Alternate Login ID 声明描述。2012 R2 上现有的、随后应用了 2919355 更新的 AD FS 场的管理员（希望对新声明创建声明规则）需要手动添加声明描述。这可以通过 AD FS MGMT UI 或 PowerShell 完成。
在其中一台联合服务器上打开 PowerShell。
Add-AdfsClaimDescription -Name "AlternateLogin ID" -ClaimType http://schemas.microsoft.com/ws/2013/11/alternateloginid -ShortName AlternateLoginID -IsAccepted $True -IsOffered $True -IsRequired $False -Notes "Alternate login ID of the user"
先决条件
- AD FS 服务帐户必须为目录中的所有用户提供 Canonical Name 属性的读取权限。
o 默认情况下，经过身份验证的用户拥有这一权限，这对于 AD FS 服务帐户来说应该足够了。
O如果 “LookupForests’ 中标识多个林，每个林中的所有用户都要有这些权限。
- 仅在应用了 Windows Server 2012 R2 更新的 2012 R2 上受支持
o 必须向所有联合服务器应用此更新
- 必须对 alternate login ID 属性编制索引
o 这是 PowerShell 完成配置所需的
- alternate login ID 属性必须在全局目录中。
o 这是 PowerShell 完成配置所需的
- alternate login ID 属性必须与 UPN 格式兼容
o UPN 架构细节：
http://msdn.microsoft.com/en-us/library/windows/desktop/ms680857(v=vs.85).aspx
o 属性值必须使用 UPN格式 (Prefix@suffix) 或域限定的 samAccountNames (NETBIOS Domain\SamAccountName or DOMAIN FQDN\SamAccountName)。这是因为 AD FS 登录页面上需要该格式。
- alternate login ID 属性的值在所有用户中必须是唯一的。
o 如果在 “LookupForests’ 中标识多个林，alternate login ID 的值在所有林中必须是唯一的。
启用 AlternateLoginID
安装 Windows Server 2012 R2 更新
Windows RT 8.1、Windows 8.1 和 2014 年 4 月发布的 Windows Server 2012 R2 更新
http://support.microsoft.com/kb/2919355
通过 PowerShell 启用 AlternateLoginID
通过 PowerShell 启用 AlternateLoginID 功能，命令如下所示：
有关该 Powershell 命令的更多信息参见 此处
Set-ADFSClaimsProviderTrust -Target Identifier "AD AUTHORITY" -AlternateLoginID <attribute> -LookupForests <forest domain>
验证已启用 AlternateLoginID
另外还可使用 PowerShell 验证 AlternateLoginID 功能，命令如下所示：
Get-ADFSClaimsProviderTrust –Identifier “AD Authority” | ft AlternateLoginID,LookupForests
禁用 AlternateLoginID
通过 PowerShell 禁用 AlternateLoginID 功能，命令如下所示：
Set-ADFSClaimsProviderTrust -Target Identifier "AD AUTHORITY" -AlternateLoginID $NULL -LookupForests $NULL
AlternateLoginID 的工作原理
对话流：
1.) 向 AD FS 服务器提供凭据
AlternateLoginID 查询仅发生在以下场景中：
- 用户使用 AD FS 基于表单的页面 (FBA) 进行登录
- 用户通过用户名和密码终结点上的富客户端应用程序进行登录
- 用户通过 Web 应用程序代理 (WAP) 执行预身份验证
- 用户使用 AD FS 更新密码页面更新企业帐户密码
2.) 是否已启用 AlternateLoginID
如果启用此功能，AD FS 服务器会对所有已定义查询林执行 LDAP 搜索，查找与已定义 AlternateLoginID 属性中的用户提供值相匹配的用户对象。
该查询会返回用户对象 SamAccountName、CanonicalName 和 DistinguishedName 的属性。
3.) 是否找到值
如果未找到，则尝试使用所提供的凭据让用户登录
4.) 是否在所有查询林中找到某个唯一用户对象的值
如果未找到，则存在冲突，抛出错误，登录失败
5.) Canonical Name 和 SamAccountName 的值是否经过正确格式化
如果不是，则抛出错误，登录失败。
如果是，基于 LDAP 查询结果构建登录凭据，让用户登录。
最佳实践
在选择充当 AlternateLoginID 的属性时，管理员应考虑以下因素：
- AlternateLoginID 属性的值在所有已定义查询林中的所有用户中必须是唯一的
- AlternateLoginID 属性的值在所有用户的 AlternateLoginID 属性以及所有用户的 UserPrincipalName 属性中应当是唯一的
- 用户应不能更新/编辑其自己（或其他用户）的 Alternate Login ID 属性值
在考虑使用 AlternateLoginID 时，重要的是要仔细考虑每个信赖方信任以及它们如何可能受到或不受到这一变化的影响。如果当前依赖方的声明规则取决于 UserPrincipalName 值，那么可能需要使用已定义的 AlternateLoginID 属性更新规则。
如果定义了多个查询林，管理员应考虑将每个林的全局目录放到靠近 AD FS 服务器的地方。
测试实验概述
在此测试实验中，AD FS 部署有：
（已于 2014 年 4 月 28 日更新，以进一步澄清实验部分的内容。）
- 配置为域控制器的一台服务器（根据 Windows Server 2012 R2 上的 AD FS 要求，如要让 AD FS 得到支持，所有用户域和 AD FS 服务器加入的域中的域控制器必须运行 Windows Server 2008 或更高版本。）
- 配置为 Active Directory 联合服务器且运行 Windows Server 2012 R2 更新（KB2919355）的一台成员服务器
- 配置为 Web 应用程序代理 (WAP) 服务器且运行 Windows Server 2012 R2 更新（KB2919355）的一台独立服务器
· 配置为 Web 服务器且托管依赖方声明感知的应用程序的一台成员服务器（在本实验中，Web 服务器上可使用任何受支持的服务器操作系统。）
- 一台独立客户机（在本实验中，Internet 客户端上可使用任何受支持的客户端操作系统。）
本实验配置最初基于以下设置：
How to Build Your AD FS Lab on Server 2012 Part 1 http://blogs.technet.com/b/askpfeplat/archive/2013/12/09/how-to-build-your-AD FS-lab-on-server-2012-part-1.aspx
How to Build Your AD FS Lab on Server 2012, Part2: Web SSOhttp://blogs.technet.com/b/askpfeplat/archive/2013/12/23/how-to-build-your-AD FS-lab-on-server-2012-part2-web-sso.aspx
How to Build Your ADFS Lab on Server 2012 Part 3: ADFS Proxyhttp://blogs.technet.com/b/askpfeplat/archive/2014/03/17/how-to-build-your-adfs-lab-on-server-2012-part-3-adfs-proxy.aspx
然后将 AD FS 服务器迁移到 Windows Server 2012 R2。
不用担心，ASKPFE 已经为您提供了相关资料。
Migrating Active Directory Federation Services Role Service to Windows Server 2012 R2 http://technet.microsoft.com/en-us/library/dn486815.aspx
最后，应用 2014 年 4 月发布的 Windows Server 2012 R2 更新。
Windows RT 8.1、Windows 8.1 和 2014 年 4 月发布的 Windows Server 2012 R2 更新 http://support.microsoft.com/kb/2919355
重要事项
以下是使用最少数量的计算机配置 AD FS 测试实验的指导信息。需要使用个人计算机来分离网络上提供的服务并清楚地显示所需的功能。该配置并不是为了反映最佳实践或生产网络的理想或推荐配置。该配置以及所有其他配置参数仅仅是为了在一个独立的测试实验网络上工作而设。
如果您试图在生产部署中应用这一 AD FS 测试实验配置，可能会导致可用性、配置或功能问题。
本 AD FS 实验由模拟以下网络的三个子网组成：
- Internet
- DMZ 网络
- 内部网络
软件要求
以下是测试实验的必需组件：
所有 AD FS 和 WAP 服务器都必须运行 Windows Server 2012 R2 更新（KB2919355）
第 1 步：启用 AD FS 中的 Alternate Login ID 功能
默认配置是禁用该功能。
以下是启用该功能所需的步骤：
启用 alternate login ID 的步骤
1. 在其中一台联合服务器上打开 Power Shell。
Set-ADFSClaimsProviderTrust –Target Identifier “AD AUTHORITY” –AlternateLoginID <attribute> -LookupForests <forest domain>
第 2 步：配置演示用的声明规则
为 UPN 将放行规则添加到依赖方
1. 以管理员身份登录到 AD FS 服务器
2. 在服务器管理器中，选择 Tools 菜单
3. 在 Tools 菜单中，选择 AD FS Management
4. 在 AD FS 管理控制台树中展开 Trust Relationships
5. 在 Trust Relationships 下展开 Relying Party Trusts
6. 右键单击 Relying Party Trust for your Claims Aware Application
7. 在上下文菜单中，选择 Edit Claims Rules…
8. 在 Edit Claims Rules 窗口中，选择 Add Rule…
9. 在 Add Transform Claim Rule 窗口的 Claim Rule Template 下拉菜单中，
a. 选择 “Pass Through or Filter an Incoming Claim”
10. 在 Add “Transform Claim Rule Wizard” 中，
a. 选择任何适当的名称
b. 选择 UPN 作为 Incoming Claim type
c. 保留默认选项 “Pass Through all Claim Values”
11. 单击 Finish。
为Alternate Login ID 将放行规则添加到依赖方
1. 以管理员身份登录到 AD FS 服务器
2.在服务器管理器中，选择 Tools 菜单
3. 在 Tools 菜单中，选择 AD FS Management
4. 在 AD FS 管理控制台树中展开 Trust Relationships
5. 在 Trust Relationships 下展开 Relying Party Trusts
6. 右键单击 Relying Party Trust for your Claims Aware Application
7. 在上下文菜单中，选择 Edit Claims Rules…
8. 在 Edit Claims Rules 窗口中，选择 Add Rule…
9. 在 Add Transform Claim Rule 窗口的 Claim Rule Template 下拉菜单中，
a. 选择 “Pass Through or Filter an Incoming Claim”
10. 在 Add “Transform Claim Rule Wizard” 中，
a. 选择任何适当的名称
b. 选择 Alternate Login ID 作为 Incoming Claim type
（已于 2014 年 5 月 11 日更新，以进一步澄清声明描述。）
如果您的 AD FS 场构建于 Windows Server 2012 R2 之上，然后应用了 2919355 更新，那么就需要手动添加 Alternate Login ID 声明描述。
Add-AdfsClaimDescription -Name "AlternateLogin ID" -ClaimType http://schemas.microsoft.com/ws/2013/11/alternateloginid -ShortName AlternateLoginID -IsAccepted $True -IsOffered $True -IsRequired $False -Notes "Alternate login ID of the user"
c. 保留默认选项 “Pass Through all Claim Values”
单击 Finish。
第 3 步：记录用户属性值
1. 以管理员身份登录到域控制器
2. 打开 PowerShell
3. 运行以下命令
Get-ADUser –Filter ‘SamAccountName –eq “TESTUSERNAME”’ –Properties * | fl SamAccountName,UserPrincipalName,Mail
如果您收到以下错误：
使用以下命令导入 Active Directory Powershell 模块：
Import-Module ActiveDirectory
第 4 步：从外部客户端导航到 ClaimsWeb 应用程序
1. 登录到外部客户端。
2. 打开 Internet Explorer，导航到 ClaimsWeb Application。
3. 在基于表单的登录页面 (WAP) 上，输入用户的电子邮件地址和密码。
4. 注意，由于我们通过 Alternate Login ID 登录了进来，所以这个声明类型已包含在内（鉴于以上声明规则）。
其他信息
有关更多信息，包括专门为该功能添加的事件和性能计数器，参见以下资料：
Configure Alternate Login ID
http://technet.microsoft.com/en-us/library/dn659436.aspx
（已于 2014 年 5 月 11 日更新，进一步澄清了该功能和 Azure Active Directory）
使用备用 ID 登录到 Azure Active Directory
Keith “What’s your ALTID” Brewer