Windows 身份验证中的凭据进程
适用范围：Windows Server 2022、Windows Server 2019、Windows Server 2016
此面向 IT 专业人员的参考主题介绍了 Windows 身份验证如何处理凭据。
Windows 凭据管理是这样一个过程：操作系统从服务或用户接收凭据，并保护该信息，以便将来提供给身份验证目标。 对于已加入域的计算机，身份验证目标是域控制器。 身份验证中使用的凭据是将用户身份与某种形式的真实性证明关联的数字文档，例如证书、密码或 PIN。
默认情况下，Windows 凭据通过 Winlogon 服务针对本地计算机上的安全帐户管理器 (SAM) 数据库进行验证，或针对已加入域的计算机上的 Active Directory 进行验证。 凭据通过登录用户界面上的用户输入或通过应用程序编程接口 (API) 以编程方式收集，以提供给身份验证目标。
本地安全信息存储在注册表中的 HKEY_LOCAL_MACHINE\SECURITY 下。 存储的信息包括策略设置、默认安全值和帐户信息，例如缓存的登录凭据。 SAM 数据库的副本也存储在此处，但对其进行了写保护。
下图显示了对用户或进程进行身份验证以实现成功登录时所需的组件以及凭据通过系统的路径。
下表介绍了在登录时管理身份验证过程中的凭据的每个组件。
所有系统的身份验证组件
| 组件 | 说明 |
|---|---|
| 用户登录 | Winlogon.exe 是负责管理安全用户交互的可执行文件。 Winlogon 服务通过 Secur32.dll 将用户操作在安全桌面（登录 UI）上收集的凭据传递给本地安全机构 (LSA)，从而启动 Windows 操作系统的登录过程。 |
| 应用程序登录 | 不需要交互式登录的应用程序或服务登录。 用户启动的大多数进程都使用 Secur32.dll 在用户模式下运行，而在启动时启动的进程（例如服务）使用 Ksecdd.sys 在内核模式下运行。 有关用户模式和内核模式的详细信息，请参阅本主题中的“应用程序和用户模式”或“服务和内核模式”。 |
| Secur32.dll | 构成身份验证过程基础的多个验证提供程序。 |
| Lsasrv.dll | LSA Server 服务，该服务强制实施安全策略并充当 LSA 的安全包管理器。 LSA 包含 Negotiate 函数，该函数在确定哪个协议会成功后选择 NTLM 或 Kerberos 协议。 |
| 安全支持提供程序 | 一组可以单独调用一个或多个身份验证协议的提供程序。 默认的一组提供程序可以随每个 Windows 操作系统版本而变化，并且可以编写自定义提供程序。 |
| Netlogon.dll | Net Logon 服务执行的服务如下所示： - 维护计算机到域控制器的安全通道（不要与 Schannel 混淆）。 |
| Samsrv.dll | 安全帐户管理器 (SAM)，用于存储本地安全帐户、强制实施本地存储的策略并支持 API。 |
| 注册表 | 注册表包含 SAM 数据库、本地安全策略设置、默认安全值和帐户信息的副本，这些内容仅供系统访问。 |
本主题包含以下各节：
用户登录的凭据输入
在 Windows Server 2008 和 Windows Vista 中，图形标识和身份验证 (GINA) 体系结构已替换为凭据提供程序模型，因而可以通过使用登录磁贴来枚举不同的登录类型。 下面介绍了这两种模型。
图形标识和身份验证体系结构
图形标识和身份验证 (GINA) 体系结构适用于 Windows Server 2003、Microsoft Windows 2000 Server、Windows XP 和 Windows 2000 Professional 操作系统。 在这些系统中，每个交互式登录会话都会创建单独的 Winlogon 服务实例。 GINA 体系结构加载到 Winlogon 使用的进程空间中，接收和处理凭据，并通过 LSALogonUser 调用身份验证接口。
交互式登录的 Winlogon 实例在会话 0 中运行。 会话 0 承载系统服务和其他关键进程，包括本地安全机构 (LSA) 进程。
下图显示了 Windows Server 2003、Microsoft Windows 2000 Server、Windows XP 和 Microsoft Windows 2000 Professional 的凭据处理过程。
凭据提供程序体系结构
凭据提供程序体系结构适用于本主题开头的“适用于”列表中指定的版本。 在这些系统中，凭据输入体系结构通过使用凭据提供程序更改为可扩展设计。 这些提供程序由安全桌面上的不同登录磁贴表示，这些磁贴允许任意数量的登录方案 - 同一用户的不同帐户和不同的身份验证方法（例如密码、智能卡和生物识别）。
使用凭据提供程序体系结构时，Winlogon 始终在收到安全注意序列事件后启动登录 UI。 登录 UI 会查询每个凭据提供程序，以了解配置该提供程序枚举的不同凭据类型的数量。 凭据提供程序可以选择将其中一个磁贴指定为默认磁贴。 所有提供程序都枚举其磁贴后，登录 UI 会向用户显示这些磁贴。 用户与磁贴交互以提供其凭据。 登录 UI 提交这些凭据进行身份验证。
凭据提供程序不是强制机制。 它们用于收集和序列化凭据。 本地安全机构和身份验证包强制实施安全性。
凭据提供程序在计算机上注册，并负责以下事项：
描述身份验证所需的凭据信息。
处理与外部身份验证机构的通信和逻辑。
打包用于交互式登录和网络登录的凭据。
打包用于交互式登录和网络登录的凭据包括序列化过程。 通过序列化凭据，可以在登录 UI 上显示多个登录磁贴。 因此，组织可以通过使用自定义凭据提供程序来控制登录显示，例如用户、登录目标系统、网络的登录前访问和工作站锁定/解锁策略。 多个凭据提供程序可以共存于同一台计算机上。
单一登录 (SSO) 提供程序可以开发为标准凭据提供程序或登录前访问提供程序。
每个版本的 Windows 都包含一个默认凭据提供程序和一个默认的登录前访问提供程序 (PLAP)，也称为 SSO 提供程序。 SSO 提供程序允许用户在登录到本地计算机之前与网络建立连接。 实现此提供程序时，提供程序不会在登录 UI 上枚举磁贴。
SSO 提供程序专用于以下方案：
网络身份验证和计算机登录由不同的凭据提供程序处理。 此方案的变体包括：
用户可以选择在登录到计算机之前连接到网络（例如连接到虚拟专用网 (VPN)），但不是必须进行此连接。
需要经过网络身份验证才能检索在本地计算机上进行交互式身份验证期间使用的信息。
多个网络身份验证后是一个其他方案。 例如，用户向 Internet 服务提供商 (ISP) 进行身份验证，向 VPN 进行身份验证，然后使用其用户帐户凭据在本地登录。
缓存的凭据处于禁用状态，并且在本地登录之前，需要通过 VPN 建立远程访问服务连接才能对用户进行身份验证。
域用户未在已加入域的计算机上设置本地帐户，并且必须先通过 VPN 连接建立远程访问服务连接，然后才能完成交互式登录。
网络身份验证和计算机登录由同一凭据提供程序处理。 在这种情况下，用户需要先连接到网络，然后才可登录到计算机。
登录磁贴枚举
凭据提供程序枚举以下实例中的登录磁贴：
适用于本主题开头的“适用于”列表中指定的操作系统。
凭据提供程序枚举工作站登录磁贴。 凭据提供程序通常会序列化凭据，以便向本地安全机构进行身份验证。 此过程显示特定于每个用户和每个用户的目标系统的磁贴。
登录和身份验证体系结构可让用户使用凭据提供程序枚举的磁贴来解锁工作站。 通常，当前登录的用户是默认磁贴，但如果有多个用户登录，则会显示大量磁贴。
凭据提供程序枚举磁贴以响应用户更改其密码或其他私人信息（如 PIN）的请求。 通常，当前登录的用户是默认磁贴，但如果有多个用户登录，则会显示大量磁贴。
凭据提供程序根据要用于在远程计算机上进行身份验证的序列化凭据枚举磁贴。 凭据 UI 不使用与登录 UI、解锁工作站或更改密码相同的提供程序实例。 因此，无法在凭据 UI 实例之间的提供程序中维护状态信息。 假设凭据已正确序列化，此结构会导致每个远程计算机登录产生一个磁贴。 此方案还用于用户帐户控制 (UAC)，它在执行可能影响计算机操作或对影响计算机的其他用户的设置进行更改的操作之前，提示用户提供相关权限或管理员密码，从而帮助防止对计算机进行未经授权的更改。
下图显示了本主题开头的“适用于”列表中指定的操作系统的凭据处理。
应用程序和服务登录的凭据输入
Windows 身份验证旨在管理不需要用户交互的应用程序或服务的凭据。 用户模式下的应用程序在它们有权访问的系统资源方面受到限制，而服务可以不受限制地访问系统内存和外部设备。
系统服务和传输级应用程序通过 Windows 中的安全支持提供程序接口 (SSPI) 访问安全支持提供程序 (SSP)，该接口提供用于枚举系统上可用的安全包、选择包以及使用该包获取经过身份验证的连接的功能。
对客户端/服务器连接进行身份验证时：
连接的客户端上的应用程序使用 SSPI 函数
InitializeSecurityContext (General)将凭据发送到服务器。连接的服务器端上的应用程序使用 SSPI 函数
AcceptSecurityContext (General)进行响应。重复使用 SSPI 函数
InitializeSecurityContext (General)和AcceptSecurityContext (General)，直到交换所有必要的身份验证消息以完成身份验证（成功或失败）。对连接进行身份验证后，服务器上的 LSA 使用来自客户端的信息来生成包含访问令牌的安全上下文。
然后，服务器可以调用 SSPI 函数
ImpersonateSecurityContext，将访问令牌附加到服务的模拟线程。
应用程序和用户模式
Windows 中的用户模式由两个能够将 I/O 请求传递到相应内核模式驱动程序的系统组成：运行为许多不同类型的操作系统编写的应用程序的环境系统，以及代表环境系统运行特定于系统的功能的整体系统。
整体系统代表环境系统管理操作系统的特定功能，由安全系统进程 (LSA)、工作站服务和服务器服务组成。 安全系统进程处理安全令牌，根据资源权限授予或拒绝访问用户帐户的权限，处理登录请求并启动登录身份验证，并确定操作系统需要审核的系统资源。
应用程序可以在用户模式下运行，在该模式下，应用程序可以作为任何主体运行，包括在本地系统 (SYSTEM) 的安全上下文中。 应用程序还可以在内核模式下运行，在该模式下，应用程序可以在本地系统 (SYSTEM) 的安全上下文中运行。
SSPI 可通过 Secur32.dll 模块获得，该模块是一种 API，用于获取实现身份验证、消息完整性和消息隐私的集成安全服务。 它在应用程序级协议和安全协议之间提供一个抽象层。 由于不同的应用程序需要不同的方式来标识用户或对用户进行身份验证，还需要不同的方式来加密网络中传输的数据，因此 SSPI 提供了一种方法来访问包含不同身份验证和加密功能的动态链接库 (DLL)。 这些 DLL 称为安全支持提供程序 (SSP)。
Windows Server 2008 R2 和 Windows 7 中引入了托管服务帐户和虚拟帐户，以提供关键应用程序（例如 Microsoft SQL Server 和 Internet Information Services (IIS)），并隔离其自己的域帐户，同时无需管理员手动管理这些帐户的服务主体名称 (SPN) 和凭据。 有关这些功能及其在身份验证中的作用的详细信息，请参阅适用于 Windows 7 和 Windows Server 2008 R2 的托管服务帐户文档和组托管服务帐户概述。
服务和内核模式
尽管大多数 Windows 应用程序都在启动它们的用户的安全上下文中运行，但服务并非如此。 许多 Windows 服务（例如网络和打印服务）都是在用户启动计算机时由服务控制器启动的。 这些服务可能作为本地服务或本地系统运行，并可能在最后一个用户注销后继续运行。
注意
服务通常在称为本地系统 (SYSTEM)、网络服务或本地服务的安全上下文中运行。 Windows Server 2008 R2 引入了在托管服务帐户下运行的服务，这些帐户是域主体。
在启动服务之前，服务控制器使用为服务指定的帐户登录，然后提供服务的凭据以供 LSA 进行身份验证。 Windows 服务实现了一个编程接口，服务控制器管理器可以使用该接口来控制服务。 Windows 服务可以在系统启动时自动启动，也可以通过服务控制程序手动启动。 例如，当 Windows 客户端计算机加入域时，计算机上的 Messenger 服务会连接到域控制器并打开一个到该控制器的安全通道。 要获取经过身份验证的连接，该服务必须具有远程计算机的本地安全机构 (LSA) 信任的凭据。 当与网络中的其他计算机通信时，LSA 使用本地计算机域帐户的凭据，就像在本地系统和网络服务的安全上下文中运行的所有其他服务一样。 本地计算机上的服务作为 SYSTEM 运行，因此不需要向 LSA 提供凭据。
文件 Ksecdd.sys 管理并加密这些凭据，并使用对 LSA 的本地过程调用。 文件类型为 DRV（驱动程序），称为内核模式安全支持提供程序 (SSP)，在本主题开头的“适用于”列表中指定的那些版本中，符合 FIPS 140-2 级别 1 标准。
内核模式对计算机的硬件和系统资源具有完全访问权限。 内核模式阻止用户模式服务和应用程序访问它们不应有权访问的操作系统的关键区域。
本地安全机构
本地安全机构 (LSA) 是一个受保护的系统进程，用于对用户进行身份验证并将其登录到本地计算机。 此外，LSA 在计算机上维护有关本地安全的所有方面的信息（这些方面统称为本地安全策略），并提供多种用于在名称和安全标识符 (SID) 之间进行转换的服务。 安全系统进程本地安全机构服务器服务 (LSASS) 持续跟踪在计算机系统上生效的安全策略和帐户。
LSA 根据以下两个实体中的哪一个颁发了用户帐户来验证用户的标识：
本地安全机构。 LSA 可以通过检查位于同一台计算机上的安全帐户管理器 (SAM) 数据库来验证用户信息。 任何工作站或成员服务器都可以存储本地用户帐户和有关本地组的信息。 但是，这些帐户只能用于访问该工作站或计算机。
本地域或受信任域的安全机构。 LSA 联系颁发帐户的实体，并请求验证该帐户是否有效以及请求是否来自帐户持有者。
本地安全机构子系统服务 (LSASS) 通过活动 Windows 会话以用户的名义将凭据存储在内存中。 使用存储的凭据，用户可以无缝地访问网络资源（例如文件共享、Exchange Server 邮箱和 SharePoint 站点），而无需为每个远程服务重新输入其凭据。
LSASS 可以采用多种形式来存储凭据，包括：
反向加密的纯文本
Kerberos 票证（票证授予票证 (TGT)、服务票证）
NT 哈希
LAN 管理器 (LM) 哈希
如果用户使用智能卡登录 Windows，LSASS 不会存储纯文本密码，而是存储帐户对应的 NT 哈希值和该智能卡的纯文本 PIN。 如果为交互式登录所需智能卡启用了帐户属性，将自动为该帐户生成一个随机的 NT 哈希值（而非原始密码哈希）。 在设置属性时自动生成的密码哈希不会发生更改。
如果用户使用与 LAN 管理器 (LM) 哈希兼容的密码登录到基于 Windows 的计算机，则此身份验证器将存在于内存中。
无法禁用内存中纯文本凭据的存储，即使禁用需要它们的凭据提供程序也是如此。
存储的凭据直接与已在上次重启后启动且尚未关闭的本地安全机构子系统服务 (LSASS) 登录会话关联。 例如，当用户执行以下任何操作时，都会创建带有已存储 LSA 凭据的 LSA 会话：
登录到计算机上的本地会话或远程桌面协议 (RDP) 会话
使用“RunAs”选项运行任务
在计算机上运行活动的 Windows 服务
运行计划任务或者批处理作业
使用远程管理工具在本地计算机上运行任务
在某些情况下，LSA 机密（仅供 SYSTEM 帐户进程访问的机密数据片段）存储在硬盘驱动器上。 其中一些机密是重新启动后必须保留的凭据，并且它们以加密的形式存储在硬盘驱动器上。 存储为 LSA 机密的凭据可能包括：
计算机的 Active Directory 域服务 (AD DS) 帐户的帐户密码
在计算机上配置的 Windows 服务的帐户密码
用于已配置的计划任务的帐户密码
用于 IIS 应用程序池和网站的帐户密码
Microsoft 帐户的密码
Windows 8.1 中引入了客户端操作系统，用于为 LSA 提供附加保护，以防止未受保护的进程读取内存及注入代码。 此保护提高了 LSA 存储和管理的凭据的安全性。
有关这些附加保护的详细信息，请参阅配置附加 LSA 保护。
缓存的凭据和验证
验证机制依赖于在登录时提供的凭据。 但是，当计算机与域控制器断开连接并且用户提供域凭据时，Windows 在验证机制中使用缓存的凭据处理。
每次用户登录域时，Windows 都会缓存提供的凭据并将它们存储在操作系统注册表的安全配置单元中。
使用缓存的凭据，用户可以登录到域成员，而无需连接到该域中的域控制器。
凭据存储和验证
并不总是需要使用一组凭据来访问不同的资源。 例如，在访问远程服务器时，管理员可能希望使用管理凭据而不是用户凭据。 同样，访问外部资源（例如银行帐户）时，用户只能使用不同于其域凭据的凭据。 以下部分介绍了当前版本的 Windows 操作系统与 Windows Vista 和 Windows XP 操作系统之间的凭据管理差异。
远程登录凭据进程
远程桌面协议 (RDP) 管理使用 Windows 8 中引入的远程桌面客户端连接到远程计算机的用户的凭据。 纯文本形式的凭据发送到目标主机，该主机尝试执行身份验证过程，如果成功，则将用户连接到允许的资源。 RDP 不在客户端存储凭据，但用户的域凭据存储在 LSASS 中。
受限管理员模式在 Windows Server 2012 R2 和 Windows 8.1 中引入，为远程登录方案提供了额外的安全性。 这种远程桌面模式导致客户端应用程序使用 NT 单向函数 (NTOWF) 执行网络登录质询-响应，或者在向远程主机进行身份验证时使用 Kerberos 服务票证。 对管理员进行身份验证后，管理员在 LSASS 中没有相应的帐户凭据，因为未将其提供给远程主机。 但是，管理员拥有会话的计算机帐户凭据。 管理员凭据未提供给远程主机，因此操作以计算机帐户身份执行。 资源也仅限于计算机帐户，管理员无法使用自己的帐户访问资源。
自动重启登录凭据处理
当用户登录 Windows 8.1 设备时，LSA 会将用户凭据保存在加密内存中，只能由 LSASS.exe 访问。 当 Windows 更新在没有用户存在的情况下发起自动重启时，这些凭据用于为用户配置自动登录。
重启时，用户通过自动登录机制自动登录，然后额外锁定计算机以保护用户的会话。 锁定通过 Winlogon 发起，而凭据管理由 LSA 负责。 通过在控制台上自动登录并锁定用户会话，用户的锁屏应用程序会重启并可用。
有关 ARSO 的详细信息，请参阅 Winlogon 自动重启登录 (ARSO)。
Windows Vista 和 Windows XP 中存储的用户名和密码
在 Windows Server 2008、Windows Server 2003、Windows Vista 和 Windows XP 中，控制面板中存储的用户名和密码可简化多组登录凭据的管理和使用，包括用于智能卡的 X.509 证书和 Windows Live 凭据（现在称为 Microsoft 帐户）。 凭据（用户配置文件的一部分）会一直存储到需要时为止。 此操作可以确保在一个密码泄露时不会危及所有安全性，从而提高每个资源的安全性。
在用户登录并尝试访问其他受密码保护的资源（例如服务器上的共享）后，如果用户的默认登录凭据不足以获得访问权限，则会查询存储的用户名和密码。 如果具有正确登录信息的备用凭据已保存在存储的用户名和密码中，则系统使用这些凭据获取访问权限。 否则，系统会提示用户提供新凭据，然后可以保存这些凭据以供以后在登录会话中或在后续会话期间重复使用。
存在以下限制：
如果存储的用户名和密码包含特定资源的无效或错误凭据，则会拒绝对该资源的访问，并且不会出现“存储的用户名和密码”对话框。
存储的用户名和密码仅存储用于 NTLM、Kerberos 协议、Microsoft 帐户（以前的 Windows Live ID）和安全套接字层 (SSL) 身份验证的凭据。 某些版本的 Internet Explorer 会维护自己的缓存，以便进行基本身份验证。
这些凭据成为 \Documents and Settings\Username\Application Data\Microsoft\Credentials 目录中用户本地配置文件的加密部分。 因此，如果用户的网络策略支持漫游用户配置文件，则这些凭据可以随用户一起漫游。 但是，如果用户在两台不同的计算机上有存储的用户名和密码的副本，并在其中一台计算机上更改了与资源关联的凭据，则更改不会传播到第二台计算机上存储的用户名和密码。
Windows 保管库和凭据管理器
凭据管理器作为控制面板功能在 Windows Server 2008 R2 和 Windows 7 中引入，用于存储和管理用户名和密码。 使用凭据管理器，用户可在安全的 Windows 保管库中存储与其他系统和网站相关的凭据。 某些版本的 Internet Explorer 使用此功能对网站进行身份验证。
使用凭据管理器管理凭据，由本地计算机用户控制。 用户可以从支持的浏览器和 Windows 应用程序保存和存储凭据，需要登录到这些资源时非常方便。 凭据保存在计算机上特殊加密文件夹中的用户配置文件下。 在登录过程中，支持这种功能（通过使用凭据管理器 API）的应用程序（例如 Web 浏览器和应用）可以向其他计算机和网站提供正确的凭据。
当网站、应用程序或其他计算机通过 NTLM 或 Kerberos 协议请求身份验证时，会出现一个对话框，可在其中选中“更新默认凭据”或“保存密码”复选框。 此对话框允许用户在本地保存凭据，由支持凭据管理器 API 的应用程序生成。 如果用户选中“保存密码”复选框，凭据管理器会持续跟踪用户的用户名、密码和正在使用的身份验证服务的相关信息。
下次使用服务时，凭据管理器自动提供存储在 Windows 保管库中的凭据。 如果未接受凭据，将提示用户提供正确的访问信息。 如果使用新凭据授予访问权限，凭据管理器会用新凭据覆盖以前的凭据，然后将新凭据存储在 Windows 保管库中。
安全帐户管理器数据库
安全帐户管理器 (SAM) 是一个存储本地用户帐户和组的数据库。 它存在于每个 Windows 操作系统中；但是，当计算机加入域时，Active Directory 会管理 Active Directory 域中的域帐户。
例如，运行 Windows 操作系统的客户端计算机通过与域控制器通信来参与网络域，即使没有用户登录也是如此。 若要启动通信，计算机必须在域中具有活动帐户。 在接受来自计算机的通信之前，域控制器上的 LSA 会对计算机的标识进行身份验证，然后构造计算机的安全上下文，就像对用户的安全主体一样。 此安全上下文定义特定计算机上的用户或服务，或者网络上的用户、服务或计算机的标识和功能。 例如，安全上下文中包含的访问令牌定义了可以访问的资源（例如文件共享或打印机）以及可以由该主体（用户、计算机或该资源上的服务）执行的操作（例如读取、写入或修改）。
用户或计算机的安全上下文可能因计算机而异，例如当用户登录服务器或用户自己的主工作站以外的工作站时。 安全上下文也可能因会话而异，例如管理员修改用户的权限时。 此外，当用户或计算机以独立方式、在网络中或作为 Active Directory 域的一部分运行时，安全上下文通常有所不同。
本地域和受信任的域
当两个域之间存在信任时，每个域的身份验证机制都依赖于来自另一个域的身份验证的有效性。 信任通过验证传入的身份验证请求是否来自受信任的机构（受信任的域），来帮助提供对资源域（信任域）中共享资源的受控访问。 通过这种方式，信任可以充当桥梁，仅允许经过验证的身份验证请求在域之间传输。
特定信任传递身份验证请求的方式取决于其配置方式。 信任关系可以是单向的，即提供从受信域到信任域中资源的访问，也可以是双向的，即提供从每个域到另一个域中资源的访问。 信任可以是不可传递的（在这种情况下，信任仅存在与两个信任合作伙伴域之间），也可以是可传递的（在这种情况下，信任会自动扩展到任一合作伙伴信任的任何其他域）。
要了解有关身份验证的域和林信任关系，请参阅委托身份验证和信任关系。
Windows 身份验证中的证书
公钥基础结构 (PKI) 是软件、加密技术、过程和服务的组合，可让组织保证其通信与业务事务的安全。 PKI 保护通信和业务事务的能力基于经过身份验证的用户与受信任资源之间的数字证书交换。
数字证书是一种电子文档，其中包含有关其所属实体、颁发实体、唯一序列号或其他一些唯一标识、颁发日期和到期日期以及数字指纹的信息。
身份验证是确定是否可以信任远程主机的过程。 要建立其可信度，远程主机必须提供可接受的身份验证证书。
远程主机通过从证书颁发机构 (CA) 获取证书来建立其可信度。 而 CA 又可从更高级别的机构获得认证，从而创建信任链。 要确定证书是否可信，应用程序必须确定根 CA 的身份，然后确定它是否可信。
同样，远程主机或本地计算机必须确定用户或应用程序提供的证书是否真实。 用户通过 LSA 和 SSPI 提供的证书在用于本地登录的本地计算机上、在网络上或在域上（通过 Active Directory 中的证书存储）进行真实性评估。
为了生成证书，身份验证数据会通过哈希算法（如安全哈希算法 1 (SHA1)），以便生成消息摘要。 然后使用发件人的私钥对消息摘要进行数字签名，以证明该消息摘要是由发件人生成的。
注意
SHA1 是 Windows 7 和 Windows Vista 中的默认哈希算法，但在 Windows 8 中已更改为 SHA2。
智能卡身份验证
智能卡技术是基于证书的身份验证的一个示例。 使用智能卡登录网络提供了一种强大的身份验证形式，因为它在对域用户进行身份验证时使用基于加密的标识和所有权证明。 Active Directory 证书服务 (AD CS) 通过为每张智能卡颁发登录证书来提供基于加密的标识。
有关智能卡身份验证的信息，请参阅 Windows 智能卡技术参考。
Windows 8 中引入了虚拟智能卡技术。 它将智能卡的证书存储在电脑中，然后使用设备的防篡改受信任平台模块 (TPM) 安全芯片对其进行保护。 这样，电脑实际上就变成了智能卡，必须接收用户的 PIN 才能进行身份验证。
远程和无线身份验证
远程和无线网络身份验证是另一种使用证书进行身份验证的技术。 Internet 身份验证服务 (IAS) 和虚拟专用网服务器使用可扩展身份验证协议-传输级安全性 (EAP-TLS)、受保护的可扩展身份验证协议 (PEAP) 或 Internet 协议安全性 (IPsec) 为多种类型的网络访问（包括虚拟专用网 (VPN) 和无线连接）执行基于证书的身份验证。
有关网络中基于证书的身份验证的信息，请参阅网络访问身份验证和证书。