规划身份验证方法 (Search Server 2008)

  • 项目

更新时间: 2009年4月

应用到: Microsoft Search Server 2008

 

上一次修改主题： 2015-03-09

此部分的信息不适用于 Microsoft Search Server 2008 Express。它仅适用于完全版本的 Microsoft Search Server 2008。

本文介绍 Search Server 2008 支持的身份验证方法。阅读本文之后，您将能够：

  • 了解如何在 Search Server 2008 中实现身份验证。

  • 确定适用于您的环境的身份验证方法。

本文内容：

  • 关于身份验证

  • 支持的身份验证方法

  • 配置身份验证

  • 规划身份验证以便对内容进行爬网

  • 规划用于身份验证设计的区域

  • 选择环境中允许的身份验证方法

  • 工作表

关于身份验证

身份验证是指对用户身份进行验证的过程。在 Search Server 2008 中，Internet Information Services (IIS) 对用户执行身份验证。在验证用户身份后，Search Server 2008 执行授权过程，以确定此用户可以访问哪些网站、内容以及其他功能。当对内容项进行爬网时，将开始该过程的一部分。当爬网程序打开每个内容项以提取内容时，它还检索内容项元数据（包括每个内容项的访问控制列表 (ACL)）。在分析和处理每个内容项的内容之后，内容会被添加到全文检索（也称为内容索引）中。元数据和 ACL 信息将被添加到单独的索引（称为搜索数据库）中。

当用户提交查询时，Web 服务器将同时从内容索引中获得搜索结果和从搜索数据库中获得每个内容项的元数据（包括 ACL）。Web 服务器将提交查询的用户的凭据与搜索结果中包含的内容项的 ACL 进行比较。用户没有权限访问的任何内容项都不会包含在搜索结果中。此过程称为安全修整。

支持的身份验证方法

Search Server 2008 提供了一种灵活且可扩展的身份验证系统，此系统针对基于或不基于 Windows 操作系统的身份管理系统支持身份验证。通过与 ASP.NET 可插入验证集成，Search Server 2008 支持各种基于表单的身份验证方案。利用 Search Server 2008 支持的身份验证可实现各种身份验证方案，其中包括：

  • 使用标准的 Windows 身份验证方法。

  • 使用包含用户名和密码的简单数据库。

  • 直接连接到组织的身份管理系统。

  • 使用两种或两种以上的身份验证方法来访问合作伙伴应用程序（例如，连接到合作伙伴公司的身份管理系统以对合作伙伴公司的员工进行身份验证，同时使用 Windows 身份验证方法对内部员工进行身份验证）。

  • 加入联合身份管理系统。

下表列出支持的身份验证方法：

身份验证方法 说明 示例

Windows

支持标准的 IIS Windows 身份验证方法。

  • 匿名

  • 基本

  • 摘要式

  • 证书

  • Kerberos（集成的 Windows）

  • NTLM（集成的 Windows）

ASP.NET 表单

Search Server 2008 通过与 ASP.NET 表单身份验证系统集成，增加了对不基于 Windows 的身份管理系统的支持。使用 ASP.NET 身份验证，Search Server 2008 可使用实现 MembershipProvider 接口的身份管理系统。您不需要重写安全管理页或管理卷影 Active Directory 目录服务帐户。

  • 轻型目录访问协议 (LDAP)

  • SQL 数据库或其他数据库

  • 其他基于 ASP.NET 的表单身份验证解决方案

Web 单一登录 (SSO)

Search Server 2008 支持通过 Web SSO 供应商进行联合身份验证。Web SSO 允许在包含运行于不同平台上的服务的环境中使用 SSO。您不需要管理单独的 Active Directory 帐户。

  • Active Directory 联合身份验证服务 (ADFS)

  • 其他身份管理系统

系统帐户的身份验证

ASP.NET 表单身份验证和 Web SSO 可用于仅对用户帐户进行身份验证。用于连接到 Microsoft SQL Server 数据库软件并运行扩展部署的进程帐户必须是 Windows 帐户，即使当您使用其他身份验证方法对用户进行身份验证时也不例外。

Search Server 2008 支持 SQL Server 身份验证；对于未运行 Active Directory 的服务器场，则支持本地计算机进程帐户。例如，通过在服务器场内的所有服务器之间使用相同的用户名和密码可以实现本地帐户。

配置身份验证

虽然配置 Windows 身份验证比较简单，但将身份验证配置为使用 ASP.NET 表单或 Web SSO 需要进行更多的规划。本节提供有关如何在 Search Server 2008 中配置身份验证的摘要。这些信息将帮助您了解如何设计解决方案的身份验证策略，并确定组织中必须参与身份验证规划的人员。

连接到外部身份管理系统或不基于 Windows 的身份管理系统

若要使用 ASP.NET 表单或 Web SSO 针对不基于 Windows 的身份管理系统或外部身份管理系统来对用户进行身份验证，必须在 Web.config 文件中注册成员资格提供程序。除了注册成员资格提供程序之外，还可以注册角色管理器。Search Server 2008 使用标准的 ASP.NET 角色管理器接口来收集有关当前用户的组信息。Search Server 2008 中的授权进程将每个 ASP.NET 角色都视为一个域组。可按照为身份验证注册成员资格提供程序的相同方式，在 Web.config 文件中注册角色管理器。

如果要从管理中心网站管理成员资格用户或角色，除了在承载内容的 Web 应用程序的 Web.config 文件中注册成员资格提供程序和角色管理器之外，还可以选择在管理中心网站的 Web.config 文件中注册成员资格提供程序和角色管理器。

确保在 Web.config 文件中注册的成员资格提供程序名称和角色管理器名称与在管理中心的 Authentication.aspx 页中输入的名称相同。如果未在 Web.config 文件中输入角色管理器，则可能会改用 machine.config 文件中指定的默认提供程序。

例如，Web.config 文件中的以下字符串指定 SQL 成员资格提供程序：

<membership defaultProvider="AspNetSqlMembershipProvider">

有关如何使用 ASP.NET 表单身份验证以连接到 SQL Server 身份验证提供程序的其他信息，请参阅身份验证示例 (Search Server 2008)。

最后，如果使用 Web SSO 连接到外部身份管理系统，则还必须为 Web SSO 注册一个 HTTP 模块。HTTP 模块是针对发送至应用程序的每个请求调用的程序集。HTTP 模块将作为 ASP.NET 请求管道的一部分调用。有关详细信息，请参阅 HTTP 模块介绍 (https://go.microsoft.com/fwlink/?linkid=77954&clcid=0x804)。

与 ASP.NET 表单身份验证集成会对身份验证提供程序提出其他要求。除了在 Web.config 文件中注册各种元素之外，还必须对成员资格提供程序、角色管理器和 HTTP 模块进行编程，使之与 Search Server 2008 和 ASP.NET 方法进行交互，如下表中所示：

类别 说明

成员资格提供程序

若要使用 Search Server 2008，成员资格提供程序必须实现以下方法：

  • GetUser (String)   Search Server 2008 调用此方法来在邀请过程中解析用户名并获取用户的显示名称。

  • GetUserNameByEmail   Search Server 2008 调用此方法来解析邀请中的用户名。

  • FindUsersByName、FindUsersByEmail   Search Server 2008 调用这些方法来填充“添加用户”页上的用户选取器控件。如果成员资格提供程序未返回任何用户，则选取器不会运行，管理员将必须在“添加用户”文本框中键入用户名或电子邮件地址。

角色管理器

角色管理器必须实现以下方法：

  • RoleExists   Search Server 2008 在邀请过程中调用此方法来验证角色名称是否存在。

  • GetRolesForUser   Search Server 2008 在访问检查时调用此方法来收集当前用户的角色。

  • GetAllRoles   Search Server 2008 调用此方法来填充组和角色选取器。如果角色提供程序不返回任何组或角色，则 Search Server 2008 选取器不会运行，管理员必须在“添加用户”文本框中键入角色的名称。

HTTP 模块

HTTP 模块必须处理以下事件：

  • AuthenticateRequest   此事件在 ASP.NET 准备好对用户进行身份验证时调用。Web SSO 模块必须对用户的身份验证 Cookie 进行解压缩，并使用当前用户的身份设置 HttpContext.User 对象。

  • EndRequest 这是 ASP.NET 管道中的最后一个事件。在向客户端返回代码之前调用此事件。Web SSO 模块必须捕获来自 Search Server 2008 的 401 响应，并将这些响应转换为适当的 302 重定向以便对 Web SSO 登录服务器进行身份验证。

启用匿名访问

除了配置更安全的身份验证方法之外，还可以为 Web 应用程序启用匿名访问。通过使用此配置，Web 应用程序内的网站的管理员可以选择允许匿名访问。如果匿名用户要获取针对受保护的资源和功能的访问权限，他们可以单击登录按钮来提交其凭据。

规划身份验证以便对内容进行爬网

若要对 Web 应用程序中的内容进行成功爬网，则必须了解索引服务器的索引组件（也称作爬网程序）的身份验证要求。此节介绍如何为 Web 应用程序配置身份验证，以确保能够对这些 Web 应用程序中的内容进行成功爬网。

在服务器场管理员使用所有的默认设置创建 Web 应用程序时，此 Web 应用程序的默认区域将配置为使用 NTLM。服务器场管理员可以将默认区域的身份验证方法更改为 Search Server 2008 支持的任何身份验证方法。

服务器场管理员还可以一次或多次扩展 Web 应用程序以便启用其他区域。最多可以将五个区域与特定的 Web 应用程序关联，并且可将每个区域配置为使用 Search Server 2008 支持的任何身份验证方法。

默认情况下，爬网程序在对内容进行爬网时使用 NTLM。搜索服务管理员也可以创建一个爬网规则，以便在对特定范围的 URL 进行爬网时，将爬网程序配置为使用其他身份验证方法（例如基本身份验证或客户端证书），而不是使用 NTLM。有关爬网规则的详细信息，请参阅规划内容爬网 (Search Server 2008)。

爬网程序访问区域的顺序

为 Web 应用程序规划区域时，请考虑爬网程序在尝试进行身份验证时访问各区域的轮询顺序。此轮询顺序非常重要，因为如果爬网程序遇到一个配置为使用摘要式身份验证或 Kerberos 身份验证（未使用标准端口 80 或 443）的区域，则身份验证将失败，并且爬网程序不会尝试按照轮询顺序访问下一个区域。如果发生这种情况，爬网程序将不会对该 Web 应用程序上的内容进行爬网。

提示

确保为爬网程序配置的身份验证方法在轮询顺序中位于为 Kerberos 身份验证（使用非标准端口）或摘要式身份验证所配置区域的前面。

爬网程序按以下顺序轮询各区域：

  • 默认区域

  • Intranet 区域

  • Internet 区域

  • 自定义区域

  • Extranet 区域

下图演示当爬网程序尝试进行身份验证时身份验证系统所做的决定：

爬网程序如何轮询区域

爬网程序使用的轮询顺序

下表描述与图中每个标注关联的操作。

标注 操作

1

爬网程序尝试使用默认区域进行身份验证。

提示

爬网程序在尝试进行身份验证时总是首先尝试使用默认区域。

2

如果为爬网程序和区域配置的身份验证方法相同，则会对爬行程序进行身份验证，并进入授权阶段。否则，将进行步骤 3。

3

如果为 Kerberos 身份验证配置了区域，则进行步骤 4。否则，将进行步骤 5。

4

如果将区域配置为使用端口 80 或端口 443，则会对爬网程序进行身份验证并进入授权阶段。否则，身份验证将失败，并且爬网程序不会尝试使用其他区域来进行身份验证。这意味着不会对内容进行爬网。

5

如果轮询顺序中没有其他区域，则身份验证将失败且不会对内容进行爬网。否则，将进行步骤 6。

6

爬网程序尝试使用轮询顺序中的下一个区域来进行身份验证。返回到步骤 2。

如果将默认区域配置为使用爬网程序不支持的身份验证方法（例如，Web SSO），则必须至少创建一个附加区域，并将此区域配置为使用证书、基本身份验证、使用标准端口的 Kerberos 协议或 NTLM。如果使用证书或基本身份验证对 Web 应用程序进行爬网，则搜索服务管理员必须创建一个爬网规则，以将爬网程序配置为在对该 Web 应用程序进行爬网时使用适当的身份验证方法。请考虑以下方案。

身份验证方案

服务器场管理员创建一个 Web 应用程序并将其配置为使用表单身份验证。因为服务器场管理员希望对 Web 应用程序中的内容进行爬网和编制索引，并且该管理员知道爬网程序需要一个使用 NTLM、基本身份验证或证书配置的区域，所以该服务器场管理员会扩展 Web 应用程序并将 Intranet 区域配置为使用 NTLM。

当爬网程序尝试通过使用默认区域来进行身份验证时，身份验证系统发现没有将爬网程序和区域配置为使用相同的身份验证方法。因为没有为使用非标准端口的 Kerberos 身份验证或摘要式身份验证配置区域，且轮询顺序中至少有一个附加区域，所以爬网程序会尝试通过使用 Intranet 区域来进行身份验证。因为已将 Intranet 区域配置为使用 NTLM，并且爬网程序也使用 NTLM，所以默认情况下身份验证将成功。

请注意，如果服务器场管理员已为基本身份验证（而不是 NTLM）配置了 Intranet 区域，则搜索服务管理员必须创建一个爬网规则，以将爬网程序配置为在对该特定 Web 应用程序进行爬网时使用基本身份验证。否则，身份验证将失败，并且不会对内容进行爬网。同样，如果服务器场管理员已将 Intranet 区域配置为使用客户端证书，则搜索服务管理员必须创建一个爬网规则，以将爬网程序配置为在对该特定 Web 应用程序进行爬网时使用客户端证书。此外，服务器管理员必须向索引服务器注册该客户端证书；否则，身份验证将失败，并且不会对内容进行爬网。

提示

在有效地规划 Web 应用程序的身份验证及规划对这些 Web 应用程序所包含的内容进行爬网时，要求创建 Web 应用程序的服务器场管理员与配置爬网程序的搜索服务管理员进行协作。

请记住，如果您将某个区域配置为使用基本身份验证或证书，并且希望爬网程序通过使用该区域进行身份验证，则搜索服务管理员必须创建一个爬网规则，以将爬网程序配置为使用要对区域进行身份验证时使用的相同身份验证方法。否则，爬网程序会尝试使用下一个可用的区域。

除了正确配置身份验证方法之外，还必须确保爬网程序有权对 Web 应用程序中的内容进行爬网。搜索服务管理员必须确保内容访问帐户对通过此区域访问的内容具有“读取”权限级别。通过创建一个策略来向内容访问帐户授予针对特定 Web 应用程序的“读取”权限级别，服务器场管理员可以实现这一点。

规划用于身份验证设计的区域

如果打算通过使用区域来为 Web 应用程序实现多个身份验证方法，请使用以下指南：

  • 使用默认区域来实现最安全的身份验证设置。如果请求不能与特定区域相关联，则将应用默认区域的身份验证设置和其他安全策略。默认区域是在创建 Web 应用程序时创建的区域。通常，最安全的身份验证设置是为最终用户访问设计的。因此，默认区域可能是由最终用户访问的区域。

  • 尽量减少应用程序所需的区域数。每个区域都与新的 IIS 网站和域关联以便访问 Web 应用程序。仅在需要新的访问点时才进行添加。

  • 如果希望在搜索结果中包含 Web 应用程序中的内容，请确保至少有一个区域配置为使用 NTLM、基本或基于表单的身份验证。索引组件需要其中一种身份验证方法来对内容进行爬网。不要为索引组件创建专用区域（除非有必要）。

选择环境中允许的身份验证方法

除了解身份验证的配置方式之外，规划身份验证还包括以下内容：

  • 考虑 Search Server 2008 中的 Web 应用程序的安全性上下文或环境。

  • 评估针对每种方法的建议和缺点。

  • 了解 Search Server 2008 如何对用户凭据和相关标识数据进行缓存并使用它们。

  • 了解如何管理用户帐户。

  • 确保身份验证方法与用户使用的浏览器兼容。

工作表操作

使用身份验证方法工作表（该链接可能指向英文页面） (https://go.microsoft.com/fwlink/?linkid=77970&clcid=0x804)（该链接可能指向英文页面）来确定希望在环境中支持哪些身份验证方法，并记录对每种身份验证方法的决定和建议。当为 Search Server 2008 中的各个 Web 应用程序规划身份验证方法时，将使用此工作表。

针对特定安全环境的建议

所选的身份验证方法主要取决于应用程序的安全性上下文。下表提供基于最常见的安全环境的建议：

环境 注意事项

内部 Intranet

至少要保护用户凭据，使其不被一览无余。可与您的环境中实施的用户管理系统集成。如果实施了 Active Directory，则可使用 IIS 内置的 Windows 身份验证方法。

外部安全协作

为连接到网站的每个合作伙伴公司配置一个单独的区域。使用 Web SSO 针对每个合作伙伴自己的身份管理系统来进行身份验证。这样就无需在自己的身份管理系统中创建帐户，并确保合作伙伴雇主继续维护和验证雇员身份。如果合作伙伴公司不再雇佣某个雇员，则该雇员将不能继续访问合作伙伴应用程序。

外部匿名

启用匿名访问（无身份验证）并允许从 Internet 连接的用户具有只读权限。如果要提供目标内容或基于角色的内容，则可以使用 ASP.NET 表单身份验证通过包含用户名和角色的简单数据库为用户注册。使用注册过程来按角色标识用户（例如，医生、患者或药剂师）。当用户登录时，网站可呈现特定于用户角色的内容。在此方案中，身份验证不是用来验证凭据或限制可以访问内容的人员。身份验证过程只是提供一种设定目标内容的方法。

身份验证方法的建议和缺点

了解每种特定的身份验证方法的优点、建议和缺点可帮助您确定要在环境中使用的方法。下表主要列出了每种身份验证方法的建议和缺点。有关 IIS 支持的每种 Windows 身份验证方法的详细信息，请参阅 IIS 身份验证 (https://go.microsoft.com/fwlink/?linkid=78066&clcid=0x804)。

身份验证方法 优点和建议 缺点

Windows

  • 通过使用现有 Active Directory 帐户进行身份验证。

  • 简化用户管理。

  • 在配置 Search Server 2008 授权时利用 Active Directory 组。

  • 不必编写自定义代码。

  • 每一种方法都具有各自的优缺点。

  • 某些 IIS 身份验证协议不受所有 Web 浏览器支持。

ASP.NET 表单

  • 在不使用 Active Directory（不需要 Windows 帐户）的环境中设置 Search Server 2008。

  • 创建合作伙伴应用程序时，针对两个或多个不同的身份管理系统进行身份验证。

  • 使用任意条件来实现自定义身份验证方案。

  • 对来自 Internet 的用户进行身份验证。

  • 需要自定义 Web.config 文件。

  • 除非使用 SSL 传输层安全性 (TLS)，否则将受到针对 Cookie 生存期的重播攻击。

Web SSO

  • 在使用联合身份验证的环境中实现 Search Server 2008 可保护所有组织和安全环境中的数字标识。

  • 在向不同平台上运行的服务提供 SSO 的环境中实现 Search Server 2008，其中包括不使用 Active Directory 的环境。

  • 利用 ADFS。

  • 创建合作伙伴应用程序时，针对两个或多个不同的身份管理系统进行身份验证。

  • 需要现有联合身份验证系统。

  • 需要自定义 Web.config 文件。

  • ADFS 需要 SSL。其他 SSO 系统可能具有其他要求。

管理用户身份信息

Search Server 2008 处理和使用用户凭据和其他身份信息的方式会影响有关您对哪一个身份验证选项最适合预期目的的决定。本节详细介绍如何处理以下类别的用户身份信息：

  • 二进制 ID   Search Server 2008 如何创建或使用用户二进制标识符 (ID)。

  • 缓存   将用户的身份保留一段时间以避免为每个请求重复身份验证过程。

  • 角色和组成员身份 除了确定用户的身份之外，身份验证过程还确定用户所属的组或角色。在授权过程中，此信息用于确定用户有权执行的操作。为了进行授权，Search Server 2008 会将 Active Directory 组和 ASP.NET 角色视为同类实体。

下表详细描述了 Search Server 2008 如何管理用户的二进制 ID、缓存的用户数据以及角色和组成员身份数据，具体取决于所使用的身份验证方法：

项目 Windows 身份验证 ASP.NET 表单和 Web SSO

二进制 ID

Search Server 2008 使用 Windows 安全标识符 (SID)。

Search Server 2008 通过将提供程序名称与用户名组合在一起来创建唯一的二进制 ID。

缓存

IIS、Internet Explorer 和 Windows 对用户凭据进行缓存和管理。

ASP.NET 使用加密的 Cookie 在会话时间内保留用户凭据。

角色和组成员身份

Windows 在存取令牌中维护用户所属的 Active Directory 域组的列表。Search Server 2008 使用存储在存取令牌中的信息。

在注册角色管理器时，Windows SharePoint Services 使用标准的角色管理器接口来收集有关当前用户的组信息。授权过程将每个 ASP.NET 角色都视为一个域组。ASP.NET 可在 Cookie 中对用户所属的角色进行缓存，具体取决于在 Web.config 文件中配置的设置。

管理用户帐户

了解 Search Server 2008 处理典型用户帐户管理任务的方式还将影响您选择的身份验证方法。通常，作为一个区域中的身份验证提供程序的成员的用户可以管理所有区域中的帐户（只要授予他们权限）。无论实现哪一种身份验证方法，下表中的信息均适用：

  • 添加和邀请新用户   如果已在当前 Web.config 文件中注册成员资格提供程序和角色管理器，则可以添加或邀请使用所配置的任意区域及所有身份验证方法的新用户。当添加新用户时，Search Server 2008 将针对以下资源按下面的顺序解析用户名：

    • 由 Search Server 2008 存储的 UserInfoList 表。如果已将用户添加到另一个网站，则用户信息将位于此列表中。

    • 为当前区域配置的身份验证提供程序。例如，如果用户是为默认区域配置的身份验证提供程序的成员，则 Search Server 2008 首先检查此关联的成员资格提供程序。

    • 所有其他的身份验证提供程序。

  • 删除用户 用户帐户在 Search Server 2008 数据库中标记为已删除。但是，没有移除用户记录。

根据身份验证提供程序，Search Server 2008 内的某些用户帐户管理行为会有所不同。下表主要列出了几个常见的用户帐户任务，这些任务因实现的身份验证方法而异：

任务 经 Windows 身份验证的帐户 经 ASP.NET 表单身份验证的帐户和经 Web SSO 身份验证的帐户

添加和邀请新用户

Search Server 2008 通过使用 Active Directory 来验证用户身份。

Search Server 2008 调用成员资格提供程序和角色管理器来验证用户和角色是否存在。

更改登录名

Search Server 2008 将自动识别更新的用户名。不向 UserInfoList 表中添加新项。

必须删除旧的用户名并添加新的用户名。不能迁移权限。

登录

如果使用集成 Windows 身份验证（Kerberos 协议或 NTLM）并将浏览器配置为自动登录，则用户不必手动登录到 SharePoint 网站。默认情况下，将 Internet Explorer 配置为自动登录到 Intranet 站点。如果要求登录（例如，需要一组不同凭据的网站），则系统只提示用户输入用户名和密码。但是，如果使用基本身份验证或用户使用的浏览器没有配置为自动登录，则当用户访问 SharePoint 网站时，系统可能会提示用户输入登录凭据。

Search Server 2008 提供用于表单身份验证的标准登录页。此页包含下列字段：用户名、密码、自动登录（保存在 Cookie 中）。可以创建自己的登录页以添加登录控件（例如，创建新的帐户或重置密码）。

浏览器支持

受支持的每种身份验证方法并非适用于所有浏览器。在选择环境中允许的身份验证方法之前，请确定必须支持的浏览器。然后，确定浏览器支持的身份验证方法。受支持的每种身份验证方法都适用于 Internet Explorer。Search Server 2008 支持的其他浏览器包括：

  • Netscape 8.0

  • Netscape 7.2

  • Mozilla 1.7.12

  • Firefox 1.5

  • Safari 2.02

工作表

可使用下面的工作表来记录适用于您的环境的身份验证方法：

下表表示一个已完成的工作表的示例：

身份验证方法 允许 不允许 注释和建议

匿名

x

基本

x

摘要式

x

证书

x

NTLM（集成的 Windows）

x

“为除财务部门网站以外的所有部门网站使用 NTLM。”

Kerberos（集成的 Windows）

x

“为使用高安全服务级别协议的网站设置 Kerberos 身份验证。”

ASP.NET 表单

x

“使用表单身份验证以允许合作伙伴公司访问合作伙伴的 Extranet 中承载的网站。目前我们允许针对以下身份管理系统进行身份验证：Active Directory、LDAP。与 Sidney Higa 一起开发用于表单身份验证的身份验证设置。”

Web SSO

x

“仅当合作伙伴公司加入联合身份管理系统时，才为合作伙伴应用程序使用此方法。有关详细信息，请咨询 David Jones。”

附加注释： “在实施之前，请与 Denise Smith 一起注销 SharePoint Web 应用程序的所有身份验证设置。”

另请参阅

概念

规划身份验证 (Search Server 2008)
为 Web 应用程序规划身份验证设置 (Search Server 2008)
身份验证示例 (Search Server 2008)