Active Directory 与 Kerberos 集成

Microsoft Active Directory 将 Kerberos 5 实现为其主要认证协议。每个 Windows 域控制器都运行 KDC 服务，其中包括认证服务和票据授予服务。域名会直接映射到 Kerberos 领域名称，域账户则对应于 Kerberos 主体。

在 Active Directory 域中，每个域控制器都可以充当 KDC，复制机制确保所有 DC 中的主体信息保持一致。krbtgt 账户存在于每个域中，其密码哈希是用于加密 TGT 的主密钥。该账户的安全性至关重要：一旦遭到入侵，攻击者就可以为任何主体伪造 TGT。

用户设置 Active Directory 密码时，Windows 会使用密钥派生函数从密码派生 Kerberos 长期密钥。该密钥与 NTLM 哈希一起存储在 AD 数据库中。在 Kerberos 预认证期间，客户端会证明自己知道该密钥，但不会传输密钥本身。

NTLM（NT 局域网管理器）是 Windows 环境中的旧版认证协议。当 Kerberos 不可用时，Windows 会回退到 NTLM，例如通过 IP 地址而不是主机名访问资源、目标设备未加入域，或者服务主体名称（SPN）未正确注册时。

服务主体名称（SPN）是 Active Directory 中服务实例的唯一标识符。格式为：ServiceClass/FQDN:Port。例如：HTTP/webserver.corp.example.com:443。Kerberos 使用 SPN 查找正确的服务账户密钥，以加密服务票据。配置错误或缺失的 SPN 会导致 Kerberos 回退到 NTLM。

Windows 使用 SPNEGO（简单且受保护的 GSSAPI 协商机制）在 Kerberos 和 NTLM 之间透明地进行协商。当客户端连接到 IIS 服务器时，服务器会声明支持 SPNEGO，客户端首先尝试 Kerberos；如果 Kerberos 失败，则回退到 NTLM。用户不会看到这一协商过程。

Active Directory 中的 Kerberos 行为通过默认域策略中的组策略进行配置。设置包括最大票据有效期（默认 10 小时）、最大 TGT 有效期（默认 7 天）、最大时钟偏差（默认 5 分钟）以及是否强制执行预认证。这些设置会在整个域范围内应用于所有账户。

PKINIT（用于初始认证的公钥密码学）是 Kerberos 的扩展，允许使用 X.509 证书（存储在智能卡或虚拟智能卡中）代替由密码派生的密钥进行 AS-REQ 预认证。私钥会为 AS-REQ 签名，从而支持由硬件保障的无密码 Kerberos 认证。

MS-KKDCP（Microsoft Kerberos KDC 代理协议）允许通过 HTTPS 隧道传输 Kerberos 认证流量，使企业网络之外的已加入域设备能够通过 Kerberos 进行认证，而无需直接通过 VPN 连接到域控制器。这用于 DirectAccess 和某些 Azure AD 场景。

Azure AD 原生不运行 Kerberos，但 Azure AD Kerberos 可让云端管理的用户获取用于本地资源的 Kerberos 票据。Azure AD Connect Cloud Sync 和 Azure AD Kerberos 服务弥合了这一差距，使云优先型组织能够继续访问受本地 Kerberos 保护的资源。

Kerberos 加固（FAST - 灵活身份验证安全隧道）通过将预身份验证交换封装在来自受信任计算机账户的 TGT 中来保护该交换过程。这可以防止针对 AS-REQ 数据的离线字典攻击，对于未要求预身份验证的账户尤其重要。

在 Active Directory 中，krbtgt 账户代表什么？为什么其安全性至关重要？

Active Directory 在域控制器上实现 Kerberos 5。用户密码派生出存储在 AD 中的 Kerberos 长期密钥。SPNs 将服务映射到账户，以便进行票据加密。Kerberos 失败时会回退到 NTLM。PKINIT 支持智能卡身份验证。krbtgt 账户是域的信任根：一旦遭到泄露，攻击者就能伪造黄金票据。