Kerberos 域认证加固实战：NTLM 禁用配置

Kerberos 域认证加固是内网安全建设中被长期忽视的一环。多数企业的域环境在部署完成后多年未调整默认配置，Kerberos 仍允许弱加密类型、NTLM 仍在全网通行、服务账户口令十年未换，攻击者只要拿到一个普通域账号，就能通过 Kerberoasting 或 NTLM Relay 在内网横向移动直至拿到域管理员。本文给出 Kerberos 域认证加固的完整操作流程，覆盖 NTLM 审计与禁用、加密类型收紧、SPN 账户治理、NTLM Relay 防护与验证手段。

适用场景

运行 Active Directory 的企业内网，域控版本为 Windows Server 2016 及以上。
已加入域的 Linux 服务器通过 SSSD 或 Winbind 进行单点登录，需要统一收紧加密算法。
安全评估或等保测评指出「NTLM 未限制」「Kerberos 弱加密未禁用」等整改项。
发生过凭据窃取类事件，需要压缩攻击者拿到哈希后横向移动的空间。
准备从 NTLM 逐步迁移到纯 Kerberos 认证，需要先完成现状测绘再分批切换。

前置条件

具备域管理员权限或已授权执行域级组策略修改的委派权限。
已备份默认域策略与所有自定义 GPO，备份命令见操作步骤第一节。
域内 DNS 解析正常，正向与反向解析均可用，Kerberos 对域名解析极其敏感。
域控与成员服务器时间偏差不超过 5 分钟，否则票据申请会直接失败。
已部署集中日志收集，能够采集域控安全日志与成员服务器事件日志。
在测试组织单位内准备若干测试账号与测试主机，用于灰度验证。

原理说明

Kerberos 认证流程简述

客户端先向 KDC 的 AS 服务发送 AS-REQ，通过预认证信息证明身份后获得票据授予票据 TGT；随后向 TGS 服务发送 TGS-REQ 申请访问具体服务的服务票据；最后携带服务票据向目标服务出示完成认证。整条链路中，票据使用长期密钥派生的会话密钥加密，因此加密类型的强度直接决定票据被离线破解的难度。

风险点有三个：其一，TGS-REP 中服务票据的加密部分使用服务账户密钥派生，攻击者可申请票据后离线暴力破解，即 Kerberoasting；其二，若账号勾选了「不需要 Kerberos 预认证」，任何人都能直接请求 AS-REP 并离线破解，即 AS-REP Roasting；其三，NTLM 使用挑战响应机制，攻击者可中继认证流量到其他服务，即 NTLM Relay。

为什么必须先审计再禁用 NTLM

直接禁用 NTLM 会让仍在依赖它的老系统、打印机、扫描仪、NAS 和部分业务软件立刻不可用。正确顺序是：先开启 NTLM 审核收集使用情况，识别出仍然依赖 NTLM 的主体与目标，逐个迁移到 Kerberos 或协商认证，最后才收紧策略。跳过审计直接禁用的后果通常是当天出现大面积故障，被迫回滚，整改不了了之。

操作步骤

步骤一：备份 GPO 并开启 NTLM 审计

# 在域控上备份全部组策略，输出目录按日期归档
$stamp = Get-Date -Format "yyyyMMdd"
Backup-GPO -All -Path "D:\GPOBackup\$stamp"

# 开启 NTLM 审核：默认域控制器策略 与 默认域策略 都要设置
# 路径：计算机配置 - 策略 - Windows 设置 - 安全设置 - 本地策略 - 安全选项
# 策略名：网络安全: 配置 NTLM 审核
# 取值：  发送所有 NTLM 流量时审核（同时审核域内与域外流量）

# 也可用注册表批量下发（域控与成员服务器均适用）
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v LmCompatibilityLevel /t REG_DWORD /d 5 /f

# 域控上启用详细 NTLM 审计日志，事件 ID 8004（域内）与 8005 / 8006（域外）
wevtutil sl Microsoft-Windows-NTLM/Operational /e:true

开启审核后至少观察 两到四周，覆盖月末结账、批量打印、备份作业等周期性任务，避免遗漏低频依赖。

步骤二：统计 NTLM 使用情况并识别依赖方

# 汇总发起 NTLM 认证的账号与目标服务器（域控执行）
Get-WinEvent -LogName "Microsoft-Windows-NTLM/Operational" -MaxEvents 20000 |
  Where-Object { $_.Id -in 8001,8002,8003,8004 } |
  ForEach-Object {
    $x = [xml]$_.ToXml()
    [pscustomobject]@{
      Time    = $_.TimeCreated
      User    = ($x.Event.EventData.Data | Where-Object Name -eq 'UserName').'#text'
      Domain  = ($x.Event.EventData.Data | Where-Object Name -eq 'DomainName').'#text'
      Target  = ($x.Event.EventData.Data | Where-Object Name -eq 'ServerName').'#text'
      Process = ($x.Event.EventData.Data | Where-Object Name -eq 'ProcessName').'#text'
    }
  } | Group-Object Target,Process | Sort-Object Count -Descending |
  Select-Object Count,Name | Export-Csv D:\ntlm_audit.csv -Encoding UTF8 -NoTypeInformation

# 快速查看仍在使用 NTLM 的账号（按出现次数排序）
Import-Csv D:\ntlm_audit.csv | Select-Object -First 30

重点排查三类：域管理员与特权账号使用 NTLM（必须优先消除）、服务器之间的机器账户认证（通常是应用配置写死了 IP 而非域名）、网络设备与打印服务（多数只支持 NTLM，需要通过隔离网段或专用账号缓解）。

步骤三：收紧 Kerberos 加密类型

默认域策略中通常仍允许 RC4_HMAC_MD5，这正是 Kerberoasting 能高效破解的根因。应改为仅允许 AES：

# 域策略：计算机配置 - 策略 - Windows 设置 - 安全设置 - 本地策略 - 安全选项
# 「网络安全: 配置 Kerberos 允许的加密类型」勾选：
#   AES128_HMAC_SHA1
#   AES256_HMAC_SHA1
#   Future encryption types
# 取消勾选：RC4_HMAC_MD5、DES_CBC_CRC、DES_CBC_MD5

# Linux 域成员同步收紧（/etc/krb5.conf）
[libdefaults]
    default_realm = CORP.EXAMPLE.COM
    default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
    default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
    permitted_enctypes   = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
    rdns = false
    dns_lookup_kdc = true
    ticket_lifetime = 10h
    renew_lifetime  = 7d
    forwardable = true

# 检查服务账户支持的加密类型，确认已具备 AES 密钥
Get-ADUser -Filter { ServicePrincipalName -like "*" } -Properties ServicePrincipalName,msDS-SupportedEncryptionTypes |
  Select-Object SamAccountName, msDS-SupportedEncryptionTypes, ServicePrincipalName

# 为服务账户显式声明 AES 支持（值为 24 表示 AES128 + AES256）
Set-ADUser -Identity svc_sql -Replace @{ "msDS-SupportedEncryptionTypes" = 24 }

修改加密类型前必须先确认所有服务账户都已具备 AES 密钥。查询命令为 Get-ADUser svc_sql -Properties msDS-SupportedEncryptionTypes，若值为 0 或 4（仅 RC4），需要先用 Set-ADUser -Identity svc_sql -KerberosEncryptionType AES256,AES128 补发密钥，否则服务票据申请会失败并导致业务中断。

步骤四：治理服务账户与禁用弱预认证

# 1) 找出所有配置了 SPN 的账户（Kerberoasting 的目标）
Get-ADUser -Filter { ServicePrincipalName -like "*" } -Properties ServicePrincipalName |
  Select-Object SamAccountName, PasswordLastSet, ServicePrincipalName

# 2) 找出免预认证的账户（AS-REP Roasting 的目标）
Get-ADUser -Filter { DoesNotRequirePreAuth -eq $true } -Properties DoesNotRequirePreAuth |
  Select-Object SamAccountName

# 3) 关闭免预认证
Set-ADAccountControl -Identity baduser -DoesNotRequirePreAuth $false

# 4) 服务账户口令改为 32 位以上随机值，并纳入定期轮换
$pwd = -join ((33..126) | Get-Random -Count 40 | ForEach-Object {[char]$_})
Set-ADAccountPassword -Identity svc_sql -Reset -NewPassword (ConvertTo-SecureString $pwd -AsPlainText -Force)

# 5) 更彻底的方案：迁移到组托管服务账户 gMSA，口令由 AD 自动轮换
New-ADServiceAccount -Name gmsa_sql -DNSHostName gmsa_sql.corp.example.com -PrincipalsAllowedToRetrieveManagedPassword "SQL-Hosts"

gMSA 是治理服务账户的最优解，口令由 AD 每 30 天自动轮换且不落盘到配置文件，账号无法被交互式登录。迁移时需要把服务运行账户改为 CORP\gmsa_sql$，并在承载主机上执行 Install-ADServiceAccount gmsa_sql。

步骤五：防护 NTLM Relay

Relay 攻击的原理是攻击者把捕获到的 NTLM 认证流量中继到另一台服务器，从而以受害者身份完成认证。只要目标服务不校验认证来源的完整性，中继就成立。防护手段是签名与通道绑定：

# SMB 签名（GPO：计算机配置 - Windows 设置 - 安全设置 - 本地策略 - 安全选项）
#   网络安全: Microsoft 网络客户端: 数字签名通信(始终)        已启用
#   网络安全: Microsoft 网络服务器: 数字签名通信(始终)        已启用
# Linux 端同步开启 SMB 签名（/etc/samba/smb.conf 或挂载参数）
mount -t cifs //fs01/share /mnt/share -o sec=krb5,vers=3.1.1,seal

# LDAP 签名与通道绑定（域控）
#   网络安全: LDAP 客户端签名要求                      要求签名
#   域控制器: LDAP 服务器签名要求                      要求签名
#   域控制器: 允许的 LDAP 通道绑定                      始终要求通道绑定令牌

# 彻底禁用 NTLM 的域级策略（确认识别完毕后再启用）
#   网络安全: 限制 NTLM: 传出 NTLM 流量      已启用，取值：拒绝所有域账户
#   RestrictSendingNTLMTraffic = 2
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" /v RestrictSendingNTLMTraffic /t REG_DWORD /d 2 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" /v AuditReceivingNTLMTraffic /t REG_DWORD /d 2 /f

如果暂不能全量禁用，可先使用 NTLM 审计模式的例外清单 ClientAllowedNTLMServers 放行必要目标，其余流量全部拒绝。放行清单必须逐条登记用途与责任人，并设定清理期限。

配置验证

验证分四步，分别确认票据加密类型、禁用策略生效、Relay 防护生效、业务未受影响：

# 1) 确认申请到的票据使用 AES 而非 RC4
kinit -V admin@CORP.EXAMPLE.COM
klist -e
# 输出中 EType 应为 aes256-cts-hmac-sha1-96 或 aes128-cts-hmac-sha1-96
# 若仍出现 arcfour-hmac-md5，说明域策略或服务账户加密类型未生效

# 2) 确认某台主机不再发出 NTLM 流量
Get-WinEvent -LogName "Microsoft-Windows-NTLM/Operational" -MaxEvents 200 |
  Where-Object { $_.Id -eq 8001 } | Measure-Object | Select-Object Count
# 预期：禁用策略生效后计数应归零或仅剩白名单主体

# 3) 确认 SMB 签名已强制
Get-SmbClientConfiguration | Select-Object RequireSecuritySignature, EnableSecuritySignature
Get-SmbServerConfiguration | Select-Object RequireSecuritySignature, EnableSecuritySignature
# 预期：RequireSecuritySignature 均为 True

# 4) 确认 LDAP 签名与通道绑定生效（域控）
Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" |
  Select-Object LDAPServerIntegrity, LdapEnforceChannelBinding
# 预期：LDAPServerIntegrity = 2，LdapEnforceChannelBinding = 2

# 5) 确认 Kerberoast 难度提升：普通用户请求服务票据应带 AES 加密
Add-Type -AssemblyName System.IdentityModel
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList "MSSQLSvc/sql01.corp.example.com:1433"

灰度期间重点监控四类事件：域控 事件 ID 4768 / 4769 / 4771（票据申请成功、服务票据申请、预认证失败）、成员服务器登录失败、业务系统连接数据库或文件共享的报错、打印机与扫描服务可用性。任一异常升高都应暂停下一批主机的策略推送。

常见问题

问题一：禁用 RC4 后部分老系统无法登录域

原因是这些系统的 Kerberos 实现较旧，只支持 RC4 或 DES。处理方式是先查清具体主机与账号，为其单独申请加密类型豁免，而不是全域名单撤销收紧策略。豁免时应把该主机划入独立 VLAN 并限制其可访问的服务，同时评估升级或替换的排期。若无法升级，至少要保证该主机上不存在特权账号，避免被攻陷后直接用于横向移动。

问题二：Kerberoasting 加固后还需要做什么

加固加密类型只是提高破解成本，并不能阻止攻击者申请票据。根治手段是减少可被申请的服务票据数量：清理无用 SPN、把服务账户迁移到 gMSA、避免把服务运行在高权限账号下、对服务账户设置登录限制（拒绝交互式登录、限定登录主机）。此外应部署对「短时间内大量 TGS 请求」的检测规则，这是 Kerberoasting 最明显的可观测特征。

问题三：Linux 服务器加入域后账号登录很慢或偶发失败

常见原因有三个。其一，krb5.conf 中启用了 rdns = true，反向解析超时会拖慢认证，应改为 false。其二，SSSD 缓存与 KDC 通信超时参数过小，可在 [domain/CORP.EXAMPLE.COM] 段设置 krb5_auth_timeout = 15 与 ldap_opt_timeout = 8。其三，多个 KDC 中有一台不可达，客户端在超时后才会切到下一台，应先修复该 KDC 或从配置中移除。

问题四：如何确认 NTLM 禁用不会影响备份与打印

在审计阶段的 CSV 报表中筛出这两类目标，逐台与业务方确认认证方式。打印服务器建议启用 Kerberos 认证并改用 IPP；备份软件需检查是否支持以域账号 Kerberos 认证，若不支持则把备份目标纳入 ClientAllowedNTLMServers 白名单，并在网络层限制只有备份服务器可访问该目标端口。所有豁免都要写明到期时间，每季度复核一次。

总结

Kerberos 域认证加固的正确顺序是：先备份策略、开启 NTLM 审计并观察至少两周、再收紧 Kerberos 加密类型、治理服务账户与免预认证账号、最后才考虑全量禁用 NTLM。收尾阶段依靠 SMB 签名、LDAP 签名与通道绑定消除中继空间，靠监控 4768 / 4769 / 4771 事件发现异常票据申请。整个过程必须灰度推进，每一批策略变更后都有明确的回滚预案，避免为了安全指标造成业务中断。