Windows Server 的 AD FS 要求

以下是在部署 AD FS 时必须符合的各种要求：

• 证书要求

• 硬件要求

• 软件要求

• AD DS 要求

• 配置数据库要求

• 浏览器要求

• Extranet 需求

• 网络要求

• 属性存储要求

• 应用程序要求

• 身份验证要求

• 工作场所加入要求

• 加密要求

• 权限要求

证书要求

证书在保护联合服务器、Web 应用程序代理、声明感知应用程序和 Web 客户端之间的通信方面发挥着最关键的作用。 证书的要求会有所不同，具体取决于是设置联合服务器还是代理计算机，如本部分所述。

联合服务器证书

硬件要求

以下最低和建议的硬件要求适用于 Windows Server 2012 R2 中的 AD FS 联合服务器：

软件要求

以下 AD FS 要求适用于 Windows Server® 2012 R2作系统中内置的服务器功能：

• 若要进行 Extranet 访问，必须部署 Web 应用程序代理角色服务 - Windows Server® 2012 R2 远程访问服务器角色的一部分。 Windows Server® 2012 R2 中的 AD FS 不支持以前版本的联合服务器代理。

• 无法在同一计算机上安装联合服务器和 Web 应用程序代理角色服务。

AD DS 要求

域控制器要求

所有用户域中的域控制器和加入 AD FS 服务器的域必须运行 Windows Server 2008 或更高版本。

域功能级别要求

所有用户帐户域以及 AD FS 服务器加入的域必须在 Windows Server 2003 或更高版本的域功能级别下运行。

大多数 AD FS 功能不需要 AD DS 功能级别修改才能成功运行。 但是，如果证书显式映射到 AD DS 中的用户帐户，则客户端证书身份验证需要 Windows Server 2008 域功能级别或更高版本才能成功运行。

架构要求

• AD FS 不需要对 AD DS 进行架构更改或功能级修改。

• 若要使用工作区加入功能，必须将 AD FS 服务器加入到的林的架构设置为 Windows Server 2012 R2。

服务帐户要求

• 任何标准服务帐户都可以用作 AD FS 的服务帐户。 也支持组托管服务帐户托管服务帐户。 这至少需要一个域控制器（建议部署两个或更多个）运行 Windows Server 2012 或更高版本。

• 若要使 Kerberos 身份验证在已加入域的客户端和 AD FS 之间正常工作，必须在服务帐户上将“HOST/<adfs_service_name>”注册为 SPN。 默认情况下，如果 AD FS 有足够的权限来执行此作，AD FS 将在创建新的 AD FS 场时对其进行配置。

• AD FS 服务帐户必须在包含对 AD FS 服务进行身份验证的用户的每个用户域中都受信任。

域要求

• 所有 AD FS 服务器都必须加入 AD DS 域。

• 场中的所有 AD FS 服务器都必须部署在单个域中。

• AD FS 服务器加入的域必须信任包含对 AD FS 服务进行身份验证的用户的每个用户帐户域。

多重森林环境要求

• AD FS 服务器加入到的域必须信任其中包含的用户向 AD FS 服务进行身份验证的每个用户帐户域或林。

• AD FS 服务帐户必须在包含对 AD FS 服务进行身份验证的用户的每个用户域中都受信任。

配置数据库要求

以下是基于配置存储类型的要求和限制：

WID

• 如果您的信任的依赖方数量不超过 100 个，WID 场的限制为 30 个联合服务器。

• WID 配置数据库不支持 SAML 2.0 中的项目解析配置文件。 WID 配置数据库不支持令牌重播检测。 此功能仅在 AD FS 充当联合身份验证提供程序并使用来自外部声明提供程序的安全令牌的情况下使用。

• 只要服务器数不超过 30，就支持在不同的数据中心部署 AD FS 服务器进行故障转移或地理负载均衡。

下表提供了使用 WID 集群的概述。 使用它来规划实施。

SQL Server

对于 Windows Server 2012 R2 中的 AD FS，可以使用 SQL Server 2008 及更高版本

浏览器要求

通过浏览器或浏览器控件执行 AD FS 身份验证时，浏览器必须符合以下要求：

• 必须启用 JavaScript

• 必须启用 Cookie

• 必须支持服务器名称指示（SNI）

• 对于用户证书和设备证书身份验证（工作区加入功能），浏览器必须支持 SSL 客户端证书身份验证

一些关键的浏览器和平台已对呈现和功能进行了验证，下面列出了这些内容的详细信息。 如果浏览器和设备满足上面列出的要求，则此表中未涵盖的浏览器和设备仍受支持：

Cookie

AD FS 创建必须存储在客户端计算机上的基于会话的持久 Cookie，以提供登录、注销、单一登录（SSO）和其他功能。 因此，必须将客户端浏览器配置为接受 Cookie。 用于身份验证的 Cookie 始终是针对发起服务器编写的安全超文本传输协议（HTTPS）会话 Cookie。 如果未将客户端浏览器配置为允许这些 Cookie，AD FS 将无法正常工作。 持久性cookie用于保存声明提供程序的用户选择。 可以在 AD FS 登录页的配置文件中使用配置设置来禁用它们。 出于安全原因，需要对 TLS/SSL 的支持。

Extranet 要求

要为 AD FS 服务提供 Extranet 访问权限，您必须部署 Web 应用程序代理角色服务，将其作为处理身份验证请求并安全传输到 AD FS 服务的 Extranet 角色。 这可以隔离 AD FS 服务终结点，并将所有安全密钥（例如令牌签名证书）与源自 Internet 的请求隔离开。 此外，软 Extranet 帐户锁定等功能需要使用 Web 应用程序代理。 有关 Web 应用程序代理的详细信息，请参阅 Web 应用程序代理。 `

网络要求

正确配置以下网络服务对于在组织中成功部署 AD FS 至关重要：

配置公司防火墙

位于 Web 应用程序代理和联合服务器场之间的防火墙以及客户端和 Web 应用程序代理之间的防火墙都必须启用 TCP 端口 443 入站。

此外，如果需要客户端用户证书身份验证（使用 X509 用户证书进行客户端TLS 身份验证），Windows Server 2012 R2 中的 AD FS 要求在客户端与 Web 应用程序代理之间的防火墙上启用 TCP 端口 49443 入站。 这在 Web 应用程序代理与联合服务器之间的防火墙上不是必需的。

配置 DNS

• 要进行 Intranet 访问，在内部公司网络 (Intranet) 中访问 AD FS 服务的所有客户端必须能够将 AD FS 服务名称（SSL 证书提供的名称）解析为多个或单个 AD FS 服务器的负载均衡器。

• 对于 Extranet 访问，所有从公司网络 (extranet/internet) 外部访问 AD FS 服务的客户端必须能够将 AD FS 服务名称（SSL 证书提供的名称）解析为多个或单个 Web 应用程序代理服务器的负载均衡器。

• 要使 Extranet 访问正常工作，DMZ 中的每个 Web 应用程序代理服务器都必须能够将 AD FS 服务名称（SSL 证书提供的名称）解析为 AD FS 服务器或 AD FS 服务器的负载均衡器。 这可以通过外围网络中的备用 DNS 服务器或通过使用 HOSTS 文件更改本地服务器解析来实现。

• 要在网络内部和网络外部对通过 Web 应用程序代理公开的一部分终结点正常使用 Windows 集成身份验证，必须使用 A 记录（而不是 CNAME）指向负载均衡器。

有关为联合身份验证服务和设备注册服务配置公司 DNS 的信息，请参阅 为联合身份验证服务和 DRS 配置公司 DNS。

有关为 Web 应用程序代理配置公司 DNS 的信息，请参阅 步骤 1 中的“配置 DNS”部分：配置 Web 应用程序代理基础结构。

有关如何配置群集 IP 地址或群集 FQDN 使用 NLB 的信息，请参阅“指定群集参数”http://go.microsoft.com/fwlink/?LinkId=75282。

属性存储要求

AD FS 要求至少使用一个属性存储来对用户进行身份验证，并为这些用户提取安全声明。 有关 AD FS 支持的属性存储的列表，请参阅 属性存储的角色。

LDAP 属性存储

使用其他基于轻型目录访问协议（LDAP）的属性存储时，必须连接到支持 Windows 集成身份验证的 LDAP 服务器。 LDAP 连接字符串还必须采用 LDAP URL 的格式编写，如 RFC 2255 中所述。

还需要 AD FS 服务的服务帐户有权检索 LDAP 属性存储中的用户信息。

SQL Server 属性存储

若要使 Windows Server 2012 R2 中的 AD FS 成功运行，托管 SQL Server 属性存储的计算机必须运行Microsoft SQL Server 2008 或更高版本。 使用基于 SQL 的属性存储时，还必须配置连接字符串。

自定义属性存储

可以开发自定义属性存储来启用高级方案。

• AD FS 中内置的策略语言可以引用自定义属性存储，以便可以增强以下任一方案：

  • 为本地经过身份验证的用户创建声明

  • 对外部验证用户的声明进行补充

  • 授权用户获取令牌

  • 授权服务，以获取用户行为的令牌

  • 在 AD FS 向信赖方颁发的安全令牌中颁发附加数据。

• 所有自定义属性存储必须基于 .NET 4.0 或更高版本生成。

使用自定义属性存储时，可能还需要配置连接字符串。 在这种情况下，可以输入所选的自定义代码，以便与自定义属性存储建立连接。 在这种情况下，连接字符串是一组名称/值对，解释为由自定义属性存储的开发人员实现。有关开发和使用自定义属性存储的详细信息，请参阅 属性存储概述。

应用程序要求

AD FS 支持使用以下协议的声明感知应用程序：

• WS 联合身份验证

• WS-Trust

• SAML 2.0 协议使用 IDPLite、SPLite 和 eGov1.5 配置文件。

• OAuth 2.0 授权授予配置文件

AD FS 还支持对 Web 应用程序代理支持的任何非声明感知应用程序进行身份验证和授权。

身份验证要求

AD DS 身份验证（主身份验证）

对于 Intranet 访问，支持 AD DS 的以下标准身份验证机制：

• 使用 Kerberos 和 NTLM 协商进行 Windows 集成身份验证

• 使用用户名/密码进行表单身份验证

• 使用映射到 AD DS 中的用户帐户的证书进行身份验证

对于 Extranet 访问，支持以下身份验证机制：

• 使用用户名/密码进行表单身份验证

• 使用映射到 AD DS 中的用户帐户的证书进行身份验证

• 使用接受 Windows 集成身份验证的 WS-Trust 终结点的协商（仅限 NTLM）进行 Windows 集成身份验证。

对于证书身份验证：

• 扩展到可以使用PIN码保护的智能卡。

• 用户输入其 PIN 的 GUI 不是由 AD FS 提供的，而是需要作为在使用客户端 TLS 时显示的客户端操作系统的一部分。

• 智能卡的读取器和加密服务提供商（CSP）必须在浏览器所在的计算机上工作。

• 智能卡证书必须链接到所有 AD FS 服务器和 Web 应用程序代理服务器上的受信任根目录。

• 证书必须通过以下任一方法映射到 AD DS 中的用户帐户：

  • 证书使用者名称对应于 AD DS 中的用户帐户的 LDAP 可分辨名称。

  • 证书使用者 Altname 扩展具有 AD DS 中用户帐户的用户主体名称 (UPN)。

若要在 Intranet 中使用 Kerberos 进行无缝 Windows 集成身份验证，

• 服务名称必须是受信任的站点或本地 Intranet 站点的一部分。

• 此外，必须在运行 AD FS 场的服务帐户中设置 HOST/<adfs_service_name> SPN。

多重身份验证

AD FS 支持其他身份验证（除了 AD DS 支持的主要身份验证之外），使用提供程序模型，供应商/客户可以生成自己的多重身份验证适配器，管理员可以在登录期间注册和使用这些适配器。

每个 MFA 适配器都必须基于 .NET 4.5 构建。

有关 MFA 的详细信息，请参阅 使用敏感应用程序的其他多重身份验证管理风险。

设备身份验证

AD FS 支持在最终用户工作区加入其设备的过程中使用设备注册服务预配的证书进行设备身份验证。

工作场所加入要求

最终用户可以使用 AD FS 将设备加入组织工作区。 AD FS 中的设备注册服务支持此功能。 因此，最终用户可以跨 AD FS 支持的应用程序获得 SSO 的额外优势。 此外，管理员可以通过仅限已加入组织工作区的设备访问应用程序来管理风险。 下面是启用此方案时要满足的以下要求。

• AD FS 支持将 Windows 8.1 和 iOS 5+ 设备加入工作区

• 若要使用工作区加入功能，AD FS 服务器加入到的林的架构必须为 Windows Server 2012 R2。

• AD FS 服务的 SSL 证书的使用者可选名称必须包含 enterpriseregistration 值，后接组织的用户主体名称 (UPN) 后缀，例如 enterpriseregistration.corp.contoso.com。

加密要求

下表提供了有关 AD FS 令牌签名、令牌加密/解密功能的其他加密支持信息：

权限要求

执行 AD FS 安装和初始配置的管理员必须在本地域（即联合服务器加入到的域）中拥有域管理员权限。

另请参阅

Windows Server 2012 R2 中的 AD FS 设计指南