1. 先把两条报错拆开看它们分别来自哪一层“终端服务器安全层在协议流中检测到错误”加上“STATUS_LOGON_TYPE_NOT_GRANTED”这一对组合在智能卡远程登录 AD 域的老环境里出现的频率高得离谱尤其是 Win7 客户端连 2008/2008 R2 会话主机这种组合。很多人第一反应是去查证书查了半天发现证书没问题也有人直接去重置密码结果智能卡登录压根不走这条路。问题的根源在于这两条报错根本不是同一个层面抛出来的你把它当成一个错误去查方向从一开始就偏了。先说清楚这两句话分别是谁在什么阶段说的。“终端服务器安全层在协议流中检测到错误”这句话来自客户端侧的 RDP 客户端mstsc它对应的是 RDP 连接建立过程中安全层Security Layer的握手失败。换句话说TCP 443/3389 已经连上了TLS 握手或者 CredSSP 协商这一层出了问题连接在“还没开始谈认证”的阶段就断了。它的本质是一个传输安全层错误跟你的账户有没有权限、智能卡里的证书对不对半毛钱关系都没有。STATUS_LOGON_TYPE_NOT_GRANTED错误码 0xC000015B则完全是另一个故事。它是认证已经走完、账户身份已经被识别出来之后由本地安全授权LSA在授权阶段返回的拒绝。翻译成人话就是系统认出了你是谁但“用这种方式登录”这件事没被允许。远程桌面登录在 Windows 内部对应的是 RemoteInteractive 登录类型Logon Type 10这个类型必须在“允许通过远程桌面服务登录”这个用户权限里被显式授予否则就是这个错误。所以真实的场景往往是这样的你看到的第一条错误是现象第二条错误是根因中间还隔着好几层协商。更麻烦的是很多人在事件日志里只看到了其中一条就以为只有这一个问题。我在实际排查中遇到过太多次客户端弹出的是安全层错误服务器安全日志里躺着的却是 4625 0xC000015B两边对不上因为中间还有一次重试或者另一条连接路径。1.1 为什么这两条错误会同时出现这里需要理解 RDP 的连接时序。一次完整的智能卡远程登录大致经历这么几个阶段TCP 三次握手 → TLS 握手协商加密套件、交换证书→ CredSSP 协商NLA 预认证把用户凭据提前送到服务器→ Kerberos PKINIT 认证智能卡证书换票据→ LSA 授权检查登录类型、用户权限、账户限制→ 会话创建。“安全层在协议流中检测到错误”可能发生在第二、第三阶段中的任何一个“STATUS_LOGON_TYPE_NOT_GRANTED”只可能发生在第五阶段。这两个阶段之间隔了好几秒正常情况下不该在同一次连接里同时报出来。我实测下来的规律是当 NLA网络级别身份验证开启、安全层为 SSL/TLS 时如果服务器在 CredSSP 阶段就已经能识别出用户身份但授权失败客户端会先收到一个笼统的安全层错误然后在第二次尝试不带 NLA 的降级尝试或者用户手动重试时才把真实的 0xC000015B 暴露出来。这就是为什么两条错误总是成对出现。还有一个非常常见的诱因CredSSP 的“加密 Oracle 修正”CVE-2018-0886 对应的补丁策略。打了这个补丁之后客户端和服务器的 CredSSP 版本必须匹配否则握手直接失败客户端看到的就是“安全层在协议流中检测到错误”。而 Win7/2008 R2 这两个系统的补丁状态千差万别有的打了、有的没打、有的打了客户端没打服务端一旦不匹配就是这个症状。这个补丁问题和授权问题是两个独立故障但在老环境里经常同时存在排查时必须分开验证。1.2 一个必须先建立的判断错误发生在认证前还是认证后这一步是整个排查的分水岭判断错了后面全是白费功夫。判断方法很简单看服务器上 Security 日志里有没有对应的 4625 或者 4624 事件以及 4625 里的“状态”字段。如果完全没有4625 记录说明连接根本没走到认证阶段就断了问题在 TLS/CredSSP 层。如果有4625 且状态码是 0xC000015B说明认证链路是通的问题是授权。如果 4625 状态码是 0xC000006D用户名或密码错误或 0xC000006A说明证书到账户的映射错了也就是 PKINIT 阶段就把人认错了。如果 4625 状态码是 0xC000018BSAM 数据库或域信任关系故障那要去看域控和网络。我在一次实际排查中见过更迷惑的情况服务器日志里 4625 是 0xC000015B但客户坚持说“我明明把这个用户加进了 Remote Desktop Users 组”。最后发现用户所属的组确实加了但账户属性里“登录到”被限制成了某几台工作站远程桌面会话主机不在列表里这种情况下组权限再大也没用。所以千万别只看组要看账户本身的限制。提示不要用“能不能 ping 通”“端口通不通”来判断这类问题。RDP 的 TCP 层连通性和安全层握手、认证授权是三件完全独立的事端口通只代表第一关过了。2. 智能卡远程登录 AD 域的完整链路与三个死穴搞清楚链路才能知道该在哪里下手。智能卡远程登录 AD 域本质上是把“智能卡交互式登录”那套 Kerberos PKINIT 机制搬到了远程桌面的场景里。它比普通密码登录多了好几个环节每一个环节都可能成为阻断点。我把这条链路拆成五段并且标出三个最容易出问题的“死穴”。第一段客户端读取智能卡。mstsc 调用证书选择对话框列出智能卡里的证书。这一步要求智能卡中间件正常、读卡器驱动正常、证书容器里必须有带“智能卡登录”EKU 的证书。如果这一步就不对你连证书都选不到根本走不到后面。第二段TLS 握手。客户端和会话主机的 TermService 建立 TLS 通道服务器出示自己的 RDP 证书自签名或者由 CA 颁发双方协商加密套件。这一段的失败表现就是“安全层在协议流中检测到错误”。Win7/2008 R2 默认只启用了 TLS 1.0如果环境里做过“禁用旧版 TLS”的加固这两个系统就会直接握手失败。第三段CredSSP 协商。这是 NLA 的核心客户端用智能卡完成一次“预认证”把凭据封装后传给服务器。这一段对补丁版本极度敏感也是老系统翻车最多的地方。第四段Kerberos PKINIT。服务器拿着客户端传来的证书信息向域控发起 PKINIT 认证请求。域控需要验证这张证书是不是它信任的 CA 发的、证书里的 UPN 是不是能对上 AD 里的账户、证书有没有过期、CRL 能不能查到。这一段失败了服务器日志里往往会出现 Kerberos 客户端事件比如 KDC 相关的 4768 失败或者本地 4771。第五段LSA 授权。票据拿到手LSA 开始检查这个账户能不能以 RemoteInteractive 方式登录。这就是 STATUS_LOGON_TYPE_NOT_GRANTED 的诞生地。2.1 死穴一证书到账户的映射对不上这是最隐蔽也最常见的一个。智能卡证书里携带用户身份靠的是 SANSubject Alternative Name扩展里的 UPN格式通常是userdomain.com。域控在做 PKINIT 时会拿这个 UPN 去 AD 里找账户。如果对不上认证直接失败。对不上的典型原因有几个证书是用旧的 UPN 签的用户改过名、改过域后缀、或者做过域迁移证书模板里没有勾选“在主体名称中包含用户主体名称”证书的 SAN 里塞的是邮箱而不是 UPN还有一种情况是账户本身没有设置 UPN 后缀用的是默认的domain.local而证书里是domain.com看着像同一个域实际上字符串不一样映射就失败。比较坑的一点是这种失败在不同的日志里表现不一样。在客户端可能只看到一个含糊的“凭据无效”在服务器上可能是 0xC000006D也可能干脆没有 4625。我一般直接用certutil -scinfo在客户端把智能卡里的证书和映射信息全打出来看比翻日志快得多。2.2 死穴二CA 没有被 NTAuth 存储信任这个是很多自建 CA 或者第三方 CA 环境里必踩的坑。智能卡证书必须由 AD 信任的 CA 签发信任的落地位置就是NTAuth证书存储它存在于 AD 的企业配置分区里。企业内部的 Enterprise CA 在安装时会自动把根证书写进去但如果你用的是独立 CA、第三方 CA、或者做过 CA 迁移就必须手动执行一次certutil -enterprise -addstore NTAuth CA证书文件没做这一步的表现非常典型证书本身完全合法、链也完整、客户端能正常选到但一到服务器就认证失败域控上的 Kerberos 事件会提示“客户端证书链不受到信任”。我见过一个环境智能卡在本地登录完全正常只有远程桌面不行折腾了两天才发现是 NTAuth 里少了中间 CA。还有一个衍生问题如果 CA 证书链里有中间 CA中间 CA 也必须能被域控访问到。域控需要能下载到 CRL 和 AIA Authority Information Access里指定的证书。如果 CRL 分发点是一个内网 HTTP 地址而域控访问不到证书吊销检查就会失败。默认情况下吊销检查失败是拒绝认证的所以表现就是“证书明明有效却登不进去”。2.3 死穴三账户策略与登录类型的硬限制这一条直接对应 STATUS_LOGON_TYPE_NOT_GRANTED。很多人以为把这个用户加进“Remote Desktop Users”组就完事了其实那只是其中一层。真正决定能不能远程登录的是“允许通过远程桌面服务登录”这个用户权限分配User Rights Assignment它默认授予 Administrators 和 Remote Desktop Users 组但如果有人改过、或者用组策略在 OU 级别做过收紧就会出现组里有、权限里没有的情况。更隐蔽的是账户属性里的四类限制限制位置具体项触发后的表现账户属性-账户“登录到”限制为指定计算机0xC000015B日志提示登录类型未授予账户属性-账户“必须使用智能卡登录”未勾选但策略强制密码方式被拒智能卡方式可能被策略覆盖账户属性-拨入远程访问权限拒绝影响 RRAS不影响 RDP但容易混淆组策略-用户权限拒绝通过远程桌面服务登录优先级高于允许直接拒绝特别注意“拒绝通过远程桌面服务登录”这个权限它的优先级是最高的。也就是说即使你在“允许”列表里加了这个人只要“拒绝”列表里有他或者他所在的某个组在拒绝列表里照样登不进去而且错误就是 0xC000015B跟“允许”里漏配的表现一模一样。我在一次排查里就遇到过用户被加进了允许列表但他同时在另一个被整体加入“拒绝”列表的安全组里查了两小时才定位到。3. 从外到内的六步排查实测流程下面这套流程是我自己用顺手的顺序原则是“先排除最容易的、成本最低的再动代价大的”。不要一上来就抓包抓包放在最后。整个过程大概 20 到 40 分钟能走完比盲目试错快得多。3.1 第一步确认客户端与服务端的补丁版本是否匹配这一步专门解决“终端服务器安全层在协议流中检测到错误”。CredSSP 的加密 Oracle 修正涉及一个注册表策略项AllowEncryptionOracle它有三个取值0 强制Mitigated、1 易受攻击Vulnerable、2 缓解Default。客户端和服务器的组合必须在同一档或者兼容档否则握手直接断。先在两台机器上查一下当前值# 客户端侧 Get-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\Client\Parameters\CredSSP -ErrorAction SilentlyContinue # 服务器侧 Get-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters -ErrorAction SilentlyContinue如果服务器上这个键不存在说明走的是默认策略2。如果客户端是老版本没打补丁它只支持“易受攻击”档那么服务器必须临时降到 1 才能连上。降档的写法reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters /v AllowEncryptionOracle /t REG_DWORD /d 1 /f这个方法只能作为过渡手段因为它降低了安全强度。正确做法是把两端补丁补齐到同一水平线。Win7 需要 SP1 加上对应的一组更新才能支持较新的 CredSSP 版本2008 R2 同理光装 SP1 是不够的。顺带说一句这一步还能顺便确认 TLS 版本。如果环境里禁用过 TLS 1.0需要在注册表里检查 Schannel 的 Protocols 键reg query HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server如果 Enabled 是 0那 Win7 客户端连 2008 R2 基本没戏因为这两套系统原生不支持 TLS 1.2 的服务端场景2008 R2 需要额外补丁才支持 TLS 1.2。这种情况下事件日志里会有 Schannel 的 36871/36874 记录能直接确认。3.2 第二步在服务器上核对事件日志的真实状态码打开服务器的事件查看器看两处Security 日志里的 4625以及Microsoft-Windows-TerminalServices-LocalSessionManager/Operational。4625 事件里的字段要重点看三个登录类型应该是 10 或者 3、状态就是那个 0xC0000xxx 码、子状态。如果登录类型是 3 而不是 10说明连接被当成了网络登录那“允许通过远程桌面服务登录”这个权限是不会生效的得去看 NLA 配置和 CredSSP 是否正常工作。如果状态码确实是 0xC000015B可以直接跳到第四步。如果状态码是 0xC000006D 或者 0xC000018B说明是认证阶段的问题回到证书和域控那边去查。Operational 日志里则能看到会话的建立和断开记录能帮你判断到底是连接被拒绝还是建立后被踢掉。这两种情况的排查方向完全不同。3.3 第三步把智能卡证书的信息完整打出来在客户端上执行certutil -scinfo这条命令会把智能卡里所有证书、对应的容器、公钥算法、EKU、SAN 里的 UPN 全部列出来。重点确认三件事EKU 里有1.3.6.1.4.1.311.20.2.2智能卡登录SAN 里的 UPN 与 AD 账户的 userPrincipalName 完全一致证书没有过期。再核对一下 AD 账户的 UPNGet-ADUser -Identity 账户名 -Properties UserPrincipalName,AltSecurityIdentities | Select-Object UserPrincipalName,AltSecurityIdentities如果 UPN 不一致有两种解决方式重新签发证书推荐或者用AltSecurityIdentities属性做显式映射应急用。显式映射的写法是X509:I颁发者S主体或者X509:SHA1-PUKEY公钥哈希。第二种在证书轮换时会失效只适合临时救火。3.4 第四步授权层的三层检查到这一步确认是 STATUS_LOGON_TYPE_NOT_GRANTED 了按下面三层依次查一层不通过就往下走。第一层用户权限分配。在服务器上打开secpol.msc或者直接看组策略结果集gpresult /h report.html检查“允许通过远程桌面服务登录”和“拒绝通过远程桌面服务登录”两个策略。如果域里有多个 GPO 作用于这台机器用 gpresult 看最终生效的是哪一条别只看某一层的设置。第二层账户的“登录到”限制。在 AD 用户和计算机里打开账户属性切到“账户”页签点“登录到”。如果选了“下列计算机”而会话主机不在列表里直接就是 0xC000015B。修复方式要么改成“所有计算机”要么把会话主机的计算机名加进去注意加的是 NetBIOS 名不是 IP。第三层账户的智能卡设置。如果账户勾选了“交互式登录需要智能卡”那么所有交互式登录包括远程桌面都必须用智能卡密码方式会被拒绝。反过来如果环境策略要求智能卡登录但账户没勾这个选项某些组策略组合下也会出现授权异常。这一层在混合策略环境里最容易出现“看起来都对但就是不行”的情况。同时别忘了检查账户是否被禁用、是否过期、是否在“受保护用户”组里。“受保护用户”组会强制禁用 NTLM 和 CredSSP 的某些降级行为在智能卡场景下可能导致预认证失败表现也是安全层错误。3.5 第五步核对会话主机的 RDP 安全层配置会话主机的 RDP 监听器配置直接决定了握手方式。检查这几个注册表项reg query HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp /v SecurityLayer reg query HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp /v UserAuthentication reg query HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp /v MinEncryptionLevelSecurityLayer的取值0 是 RDP 安全层1 是协商2 是 SSL/TLS。智能卡场景必须用 2 或者 1用 0 的话智能卡凭据根本没法传递会直接报安全层错误。UserAuthentication为 1 表示启用 NLA。MinEncryptionLevel为 3 表示高加密一般保持默认。还有一个容易忽略的点会话主机的 RDP 证书。如果用的是自签名证书且客户端不信任它TLS 握手会失败。老版本客户端的表现就是“安全层在协议流中检测到错误”不会告诉你证书不受信任。可以在服务器上用Get-ChildItem Cert:\LocalMachine\Remote Desktop看一下证书是否存在、是否过期、颁发者是谁。3.6 第六步最后再抓包用证据收口前面五步都排除之后再上抓包。用 Wireshark 在客户端抓过滤条件tcp.port 3389重点看 TLS 握手阶段的 Alert 消息。如果看到handshake_failure或者protocol_version就是加密套件或 TLS 版本不匹配如果看到unknown_ca就是证书链问题如果 TLS 握手完成了但后面紧跟着 RST那就是 CredSSP 层。在服务器侧同时开一个网络监视或者用netsh trace抓一份两边对时间戳能很精确地定位断点在哪。这套方法听着重但当你前面五步都走完还没找到问题时抓包往往十分钟就能收口。4. 老系统特有的坑Win7 与 2008 R2 的参数调整实录这两个系统放在今天已经属于“能用但到处是雷”的状态。它们的默认配置是十几年前的安全基线跟现在企业环境的加固策略经常正面冲突。下面这几个坑我在实际环境里反复遇到基本都是“配置看起来没毛病但就是不工作”的类型。4.1 CredSSP 版本差异导致的握手失败Win7 的 mstsc 版本是 6.1它支持的 CredSSP 版本比较早。2008 R2 的 TermService 同样。这两个系统之间原本是匹配的问题出在后续补丁上。如果服务器打了 CredSSP 的强制修正补丁而客户端没打服务器会要求客户端支持较新的 CredSSP 版本客户端不支持握手失败。判断方法在客户端跑winver和Get-HotFix看有没有对应的安全更新在服务器上同样。两边的补丁级别必须能对上。这一点没有捷径只能补齐。补齐之后建议把AllowEncryptionOracle恢复成默认值不要长期停留在易受攻击档。4.2 TLS 1.0 被禁用后的连锁反应现在很多安全基线要求禁用 TLS 1.0 和 1.1。这个要求在 Win10/2016 以上没问题但在 Win7/2008 R2 上会导致 RDP 完全不可用因为这两个系统默认不支持 TLS 1.2 作为服务端。2008 R2 需要安装特定更新才能启用 TLS 1.2 支持Win7 也需要。如果补丁装不上比如已经停止支持的版本那就只能在 RDP 这个场景下单独放开 TLS 1.0并且用其他手段补偿风险比如限制来源网段、强化审计。我一般的处理方式是先在服务器上确认 TLS 1.2 是否可用用Get-TlsCipherSuite看套件列表如果列表里只有 TLS 1.0 的套件说明补丁没打到位。这种情况下强行禁用 TLS 1.0 就是自找麻烦。4.3 智能卡移除行为与会话锁定这个坑很隐蔽。组策略里有一项“交互式登录智能卡移除行为”默认是“无操作”。如果被配置成了“锁定工作站”或者“强制注销”那么智能卡一旦离开读卡器远程会话就会被锁定或断开。在远程桌面场景下用户经常把卡拔出来去别的地方用回来后发现会话断了还以为是网络问题。实际上这是策略行为。排查的时候用gpresult看这条策略的最终值路径在“计算机配置 → Windows 设置 → 安全设置 → 本地策略 → 安全选项”。如果环境确实需要“拔卡即锁”那就得接受这个行为但要提前告知用户如果不需要就改回“无操作”。4.4 时间同步偏差超过容差Kerberos 默认允许的时间偏差是 5 分钟。智能卡 PKINIT 对时间更敏感因为证书验证本身也有时间窗口。在老环境里如果会话主机没有正确同步时间源或者虚拟化平台做了时间漂移就会出现“证书明明有效认证却失败”的情况。检查很简单w32tm /query /status w32tm /stripchart /computer:域控地址 /samples:5如果偏移超过几秒就要处理。会话主机应该指向域控做时间同步域控再指向可靠的时间源。这条在虚拟化环境里尤其要注意因为虚拟机快照恢复、挂起恢复都会导致时间跳变。4.5 RDP 会话主机上的“仅允许运行使用网络级别身份验证的远程桌面的计算机连接”这个选项在系统属性 → 远程里。勾上之后强制 NLA。智能卡登录本来就需要 NLA 来提前传递凭据所以这个选项理论上是必要的。但问题在于如果客户端版本太老、或者 CredSSP 版本不匹配勾上这个选项就等于直接把老客户端挡在门外报错就是那句熟悉的安全层错误。我的做法是先确认两端补丁匹配再勾这个选项如果环境里确实混着老客户端就在服务器上临时取消勾选做验证确认问题是否出在这里但不要在未打补丁的环境里长期关闭 NLA。5. 常见问题速查表与踩坑实录把上面这些整理成一张表遇到问题的时候可以直接对照比从头推理快。现象最可能的原因快速验证方法处理方向客户端报安全层错误服务器无任何登录日志TLS/CredSSP 握手失败查 Schannel 36871/36874 事件补齐补丁核对 TLS 版本与加密套件客户端报安全层错误服务器有 4625 且状态 0xC000006D证书到账户映射失败certutil -scinfo对比 AD 的 UPN重签证书或配置 AltSecurityIdentities4625 状态 0xC000015B登录类型未授予查用户权限分配与账户“登录到”补权限、解除计算机限制证书有效但域控拒绝CA 未在 NTAuth 存储certutil -viewstore NTAuth手动执行 enterprise addstore认证偶尔成功偶尔失败时间漂移或 CRL 检查超时w32tm /stripchart修时间源确保 CRL 可达本地登录正常远程桌面失败RDP 监听器安全层设置查 RDP-Tcp 的 SecurityLayer改为 1 或 2确认 NLA会话建立后立即断开智能卡移除策略gpresult查安全选项改为“无操作”用户在某组里但仍被拒同时在“拒绝登录”组中对比两个权限列表从拒绝组中移除再说几个我在实际环境里踩过的具体坑。一个是中间证书缺失。某次环境里根 CA 是新的中间 CA 也是新的客户端能正常选证书服务器也收到了但域控验证链的时候找不到中间 CA。原因是证书的 AIA 扩展指向了一个内网 HTTP 地址而域控所在网段访问不到那个地址。解决办法是在域控的受信任根存储和中间 CA 存储里手动导入中间证书不依赖 AIA 下载。这个问题的迷惑性在于客户端侧一切正常只有服务端验证失败。另一个是读卡器驱动导致的偶发失败。某实验室的一批机器用的是同一型号读卡器其中几台在远程登录时偶发“安全层错误”换台机器就好。最后查明是读卡器固件版本不一致旧固件在并发读取时偶发失败导致证书选择对话框返回了空值客户端带着空凭据去握手自然失败。这类问题用日志根本查不出来只能靠交叉验证同样的账户换机器、同样的机器换账户把变量收缩到硬件上。还有一次是组策略的优先级问题。OU 级别的 GPO 里把“允许通过远程桌面服务登录”设置成了只包含 Administrators而用户是通过一个自定义组获得权限的那个组在更上层的 GPO 里有但在更下层的 GPO 里被覆盖了。gpresult 一看就明白了但如果不看结果集只逐层看策略设置很容易漏。注意排查这类问题时一定要看“最终生效的策略”而不是“某个 GPO 里写了什么”。组策略的继承和覆盖关系是最容易让人误判的地方gpresult /h生成的那份 HTML 报告值得多花两分钟仔细读。最后分享一个我觉得最省时间的习惯在动手改任何配置之前先把当前状态完整记录下来。包括注册表的相关键值、gpresult 的结果、certutil -scinfo 的输出、事件日志的时间窗口。老环境里经常出现“改了一个地方另一个地方又坏了”的情况没有基线记录回滚都无从下手。我吃过这个亏一次为了排查安全层错误临时把AllowEncryptionOracle降到 1后来忘了改回去几个月后做安全审计时才被发现那段时间里这台机器的实际安全强度是下降的。从那以后我改任何与安全相关的键值都会在变更记录里写清楚原因和恢复条件。这类问题的本质其实不复杂难的是把“传输层”“认证层”“授权层”这三层分开看。大部分人在第一层就卡住了因为报错信息太笼统少部分人越过了第一层却在第二层和第三层之间来回打转。把判断分界线建立起来——先看有没有 4625、再看状态码是什么——后面的事情就是按图索骥。老系统的问题会越来越多但只要这套分层思路在换什么系统都能套用。
1. 先把两条报错拆开看它们分别来自哪一层“终端服务器安全层在协议流中检测到错误”加上“STATUS_LOGON_TYPE_NOT_GRANTED”这一对组合在智能卡远程登录 AD 域的老环境里出现的频率高得离谱尤其是 Win7 客户端连 2008/2008 R2 会话主机这种组合。很多人第一反应是去查证书查了半天发现证书没问题也有人直接去重置密码结果智能卡登录压根不走这条路。问题的根源在于这两条报错根本不是同一个层面抛出来的你把它当成一个错误去查方向从一开始就偏了。先说清楚这两句话分别是谁在什么阶段说的。“终端服务器安全层在协议流中检测到错误”这句话来自客户端侧的 RDP 客户端mstsc它对应的是 RDP 连接建立过程中安全层Security Layer的握手失败。换句话说TCP 443/3389 已经连上了TLS 握手或者 CredSSP 协商这一层出了问题连接在“还没开始谈认证”的阶段就断了。它的本质是一个传输安全层错误跟你的账户有没有权限、智能卡里的证书对不对半毛钱关系都没有。STATUS_LOGON_TYPE_NOT_GRANTED错误码 0xC000015B则完全是另一个故事。它是认证已经走完、账户身份已经被识别出来之后由本地安全授权LSA在授权阶段返回的拒绝。翻译成人话就是系统认出了你是谁但“用这种方式登录”这件事没被允许。远程桌面登录在 Windows 内部对应的是 RemoteInteractive 登录类型Logon Type 10这个类型必须在“允许通过远程桌面服务登录”这个用户权限里被显式授予否则就是这个错误。所以真实的场景往往是这样的你看到的第一条错误是现象第二条错误是根因中间还隔着好几层协商。更麻烦的是很多人在事件日志里只看到了其中一条就以为只有这一个问题。我在实际排查中遇到过太多次客户端弹出的是安全层错误服务器安全日志里躺着的却是 4625 0xC000015B两边对不上因为中间还有一次重试或者另一条连接路径。1.1 为什么这两条错误会同时出现这里需要理解 RDP 的连接时序。一次完整的智能卡远程登录大致经历这么几个阶段TCP 三次握手 → TLS 握手协商加密套件、交换证书→ CredSSP 协商NLA 预认证把用户凭据提前送到服务器→ Kerberos PKINIT 认证智能卡证书换票据→ LSA 授权检查登录类型、用户权限、账户限制→ 会话创建。“安全层在协议流中检测到错误”可能发生在第二、第三阶段中的任何一个“STATUS_LOGON_TYPE_NOT_GRANTED”只可能发生在第五阶段。这两个阶段之间隔了好几秒正常情况下不该在同一次连接里同时报出来。我实测下来的规律是当 NLA网络级别身份验证开启、安全层为 SSL/TLS 时如果服务器在 CredSSP 阶段就已经能识别出用户身份但授权失败客户端会先收到一个笼统的安全层错误然后在第二次尝试不带 NLA 的降级尝试或者用户手动重试时才把真实的 0xC000015B 暴露出来。这就是为什么两条错误总是成对出现。还有一个非常常见的诱因CredSSP 的“加密 Oracle 修正”CVE-2018-0886 对应的补丁策略。打了这个补丁之后客户端和服务器的 CredSSP 版本必须匹配否则握手直接失败客户端看到的就是“安全层在协议流中检测到错误”。而 Win7/2008 R2 这两个系统的补丁状态千差万别有的打了、有的没打、有的打了客户端没打服务端一旦不匹配就是这个症状。这个补丁问题和授权问题是两个独立故障但在老环境里经常同时存在排查时必须分开验证。1.2 一个必须先建立的判断错误发生在认证前还是认证后这一步是整个排查的分水岭判断错了后面全是白费功夫。判断方法很简单看服务器上 Security 日志里有没有对应的 4625 或者 4624 事件以及 4625 里的“状态”字段。如果完全没有4625 记录说明连接根本没走到认证阶段就断了问题在 TLS/CredSSP 层。如果有4625 且状态码是 0xC000015B说明认证链路是通的问题是授权。如果 4625 状态码是 0xC000006D用户名或密码错误或 0xC000006A说明证书到账户的映射错了也就是 PKINIT 阶段就把人认错了。如果 4625 状态码是 0xC000018BSAM 数据库或域信任关系故障那要去看域控和网络。我在一次实际排查中见过更迷惑的情况服务器日志里 4625 是 0xC000015B但客户坚持说“我明明把这个用户加进了 Remote Desktop Users 组”。最后发现用户所属的组确实加了但账户属性里“登录到”被限制成了某几台工作站远程桌面会话主机不在列表里这种情况下组权限再大也没用。所以千万别只看组要看账户本身的限制。提示不要用“能不能 ping 通”“端口通不通”来判断这类问题。RDP 的 TCP 层连通性和安全层握手、认证授权是三件完全独立的事端口通只代表第一关过了。2. 智能卡远程登录 AD 域的完整链路与三个死穴搞清楚链路才能知道该在哪里下手。智能卡远程登录 AD 域本质上是把“智能卡交互式登录”那套 Kerberos PKINIT 机制搬到了远程桌面的场景里。它比普通密码登录多了好几个环节每一个环节都可能成为阻断点。我把这条链路拆成五段并且标出三个最容易出问题的“死穴”。第一段客户端读取智能卡。mstsc 调用证书选择对话框列出智能卡里的证书。这一步要求智能卡中间件正常、读卡器驱动正常、证书容器里必须有带“智能卡登录”EKU 的证书。如果这一步就不对你连证书都选不到根本走不到后面。第二段TLS 握手。客户端和会话主机的 TermService 建立 TLS 通道服务器出示自己的 RDP 证书自签名或者由 CA 颁发双方协商加密套件。这一段的失败表现就是“安全层在协议流中检测到错误”。Win7/2008 R2 默认只启用了 TLS 1.0如果环境里做过“禁用旧版 TLS”的加固这两个系统就会直接握手失败。第三段CredSSP 协商。这是 NLA 的核心客户端用智能卡完成一次“预认证”把凭据封装后传给服务器。这一段对补丁版本极度敏感也是老系统翻车最多的地方。第四段Kerberos PKINIT。服务器拿着客户端传来的证书信息向域控发起 PKINIT 认证请求。域控需要验证这张证书是不是它信任的 CA 发的、证书里的 UPN 是不是能对上 AD 里的账户、证书有没有过期、CRL 能不能查到。这一段失败了服务器日志里往往会出现 Kerberos 客户端事件比如 KDC 相关的 4768 失败或者本地 4771。第五段LSA 授权。票据拿到手LSA 开始检查这个账户能不能以 RemoteInteractive 方式登录。这就是 STATUS_LOGON_TYPE_NOT_GRANTED 的诞生地。2.1 死穴一证书到账户的映射对不上这是最隐蔽也最常见的一个。智能卡证书里携带用户身份靠的是 SANSubject Alternative Name扩展里的 UPN格式通常是userdomain.com。域控在做 PKINIT 时会拿这个 UPN 去 AD 里找账户。如果对不上认证直接失败。对不上的典型原因有几个证书是用旧的 UPN 签的用户改过名、改过域后缀、或者做过域迁移证书模板里没有勾选“在主体名称中包含用户主体名称”证书的 SAN 里塞的是邮箱而不是 UPN还有一种情况是账户本身没有设置 UPN 后缀用的是默认的domain.local而证书里是domain.com看着像同一个域实际上字符串不一样映射就失败。比较坑的一点是这种失败在不同的日志里表现不一样。在客户端可能只看到一个含糊的“凭据无效”在服务器上可能是 0xC000006D也可能干脆没有 4625。我一般直接用certutil -scinfo在客户端把智能卡里的证书和映射信息全打出来看比翻日志快得多。2.2 死穴二CA 没有被 NTAuth 存储信任这个是很多自建 CA 或者第三方 CA 环境里必踩的坑。智能卡证书必须由 AD 信任的 CA 签发信任的落地位置就是NTAuth证书存储它存在于 AD 的企业配置分区里。企业内部的 Enterprise CA 在安装时会自动把根证书写进去但如果你用的是独立 CA、第三方 CA、或者做过 CA 迁移就必须手动执行一次certutil -enterprise -addstore NTAuth CA证书文件没做这一步的表现非常典型证书本身完全合法、链也完整、客户端能正常选到但一到服务器就认证失败域控上的 Kerberos 事件会提示“客户端证书链不受到信任”。我见过一个环境智能卡在本地登录完全正常只有远程桌面不行折腾了两天才发现是 NTAuth 里少了中间 CA。还有一个衍生问题如果 CA 证书链里有中间 CA中间 CA 也必须能被域控访问到。域控需要能下载到 CRL 和 AIA Authority Information Access里指定的证书。如果 CRL 分发点是一个内网 HTTP 地址而域控访问不到证书吊销检查就会失败。默认情况下吊销检查失败是拒绝认证的所以表现就是“证书明明有效却登不进去”。2.3 死穴三账户策略与登录类型的硬限制这一条直接对应 STATUS_LOGON_TYPE_NOT_GRANTED。很多人以为把这个用户加进“Remote Desktop Users”组就完事了其实那只是其中一层。真正决定能不能远程登录的是“允许通过远程桌面服务登录”这个用户权限分配User Rights Assignment它默认授予 Administrators 和 Remote Desktop Users 组但如果有人改过、或者用组策略在 OU 级别做过收紧就会出现组里有、权限里没有的情况。更隐蔽的是账户属性里的四类限制限制位置具体项触发后的表现账户属性-账户“登录到”限制为指定计算机0xC000015B日志提示登录类型未授予账户属性-账户“必须使用智能卡登录”未勾选但策略强制密码方式被拒智能卡方式可能被策略覆盖账户属性-拨入远程访问权限拒绝影响 RRAS不影响 RDP但容易混淆组策略-用户权限拒绝通过远程桌面服务登录优先级高于允许直接拒绝特别注意“拒绝通过远程桌面服务登录”这个权限它的优先级是最高的。也就是说即使你在“允许”列表里加了这个人只要“拒绝”列表里有他或者他所在的某个组在拒绝列表里照样登不进去而且错误就是 0xC000015B跟“允许”里漏配的表现一模一样。我在一次排查里就遇到过用户被加进了允许列表但他同时在另一个被整体加入“拒绝”列表的安全组里查了两小时才定位到。3. 从外到内的六步排查实测流程下面这套流程是我自己用顺手的顺序原则是“先排除最容易的、成本最低的再动代价大的”。不要一上来就抓包抓包放在最后。整个过程大概 20 到 40 分钟能走完比盲目试错快得多。3.1 第一步确认客户端与服务端的补丁版本是否匹配这一步专门解决“终端服务器安全层在协议流中检测到错误”。CredSSP 的加密 Oracle 修正涉及一个注册表策略项AllowEncryptionOracle它有三个取值0 强制Mitigated、1 易受攻击Vulnerable、2 缓解Default。客户端和服务器的组合必须在同一档或者兼容档否则握手直接断。先在两台机器上查一下当前值# 客户端侧 Get-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\Client\Parameters\CredSSP -ErrorAction SilentlyContinue # 服务器侧 Get-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters -ErrorAction SilentlyContinue如果服务器上这个键不存在说明走的是默认策略2。如果客户端是老版本没打补丁它只支持“易受攻击”档那么服务器必须临时降到 1 才能连上。降档的写法reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters /v AllowEncryptionOracle /t REG_DWORD /d 1 /f这个方法只能作为过渡手段因为它降低了安全强度。正确做法是把两端补丁补齐到同一水平线。Win7 需要 SP1 加上对应的一组更新才能支持较新的 CredSSP 版本2008 R2 同理光装 SP1 是不够的。顺带说一句这一步还能顺便确认 TLS 版本。如果环境里禁用过 TLS 1.0需要在注册表里检查 Schannel 的 Protocols 键reg query HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server如果 Enabled 是 0那 Win7 客户端连 2008 R2 基本没戏因为这两套系统原生不支持 TLS 1.2 的服务端场景2008 R2 需要额外补丁才支持 TLS 1.2。这种情况下事件日志里会有 Schannel 的 36871/36874 记录能直接确认。3.2 第二步在服务器上核对事件日志的真实状态码打开服务器的事件查看器看两处Security 日志里的 4625以及Microsoft-Windows-TerminalServices-LocalSessionManager/Operational。4625 事件里的字段要重点看三个登录类型应该是 10 或者 3、状态就是那个 0xC0000xxx 码、子状态。如果登录类型是 3 而不是 10说明连接被当成了网络登录那“允许通过远程桌面服务登录”这个权限是不会生效的得去看 NLA 配置和 CredSSP 是否正常工作。如果状态码确实是 0xC000015B可以直接跳到第四步。如果状态码是 0xC000006D 或者 0xC000018B说明是认证阶段的问题回到证书和域控那边去查。Operational 日志里则能看到会话的建立和断开记录能帮你判断到底是连接被拒绝还是建立后被踢掉。这两种情况的排查方向完全不同。3.3 第三步把智能卡证书的信息完整打出来在客户端上执行certutil -scinfo这条命令会把智能卡里所有证书、对应的容器、公钥算法、EKU、SAN 里的 UPN 全部列出来。重点确认三件事EKU 里有1.3.6.1.4.1.311.20.2.2智能卡登录SAN 里的 UPN 与 AD 账户的 userPrincipalName 完全一致证书没有过期。再核对一下 AD 账户的 UPNGet-ADUser -Identity 账户名 -Properties UserPrincipalName,AltSecurityIdentities | Select-Object UserPrincipalName,AltSecurityIdentities如果 UPN 不一致有两种解决方式重新签发证书推荐或者用AltSecurityIdentities属性做显式映射应急用。显式映射的写法是X509:I颁发者S主体或者X509:SHA1-PUKEY公钥哈希。第二种在证书轮换时会失效只适合临时救火。3.4 第四步授权层的三层检查到这一步确认是 STATUS_LOGON_TYPE_NOT_GRANTED 了按下面三层依次查一层不通过就往下走。第一层用户权限分配。在服务器上打开secpol.msc或者直接看组策略结果集gpresult /h report.html检查“允许通过远程桌面服务登录”和“拒绝通过远程桌面服务登录”两个策略。如果域里有多个 GPO 作用于这台机器用 gpresult 看最终生效的是哪一条别只看某一层的设置。第二层账户的“登录到”限制。在 AD 用户和计算机里打开账户属性切到“账户”页签点“登录到”。如果选了“下列计算机”而会话主机不在列表里直接就是 0xC000015B。修复方式要么改成“所有计算机”要么把会话主机的计算机名加进去注意加的是 NetBIOS 名不是 IP。第三层账户的智能卡设置。如果账户勾选了“交互式登录需要智能卡”那么所有交互式登录包括远程桌面都必须用智能卡密码方式会被拒绝。反过来如果环境策略要求智能卡登录但账户没勾这个选项某些组策略组合下也会出现授权异常。这一层在混合策略环境里最容易出现“看起来都对但就是不行”的情况。同时别忘了检查账户是否被禁用、是否过期、是否在“受保护用户”组里。“受保护用户”组会强制禁用 NTLM 和 CredSSP 的某些降级行为在智能卡场景下可能导致预认证失败表现也是安全层错误。3.5 第五步核对会话主机的 RDP 安全层配置会话主机的 RDP 监听器配置直接决定了握手方式。检查这几个注册表项reg query HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp /v SecurityLayer reg query HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp /v UserAuthentication reg query HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp /v MinEncryptionLevelSecurityLayer的取值0 是 RDP 安全层1 是协商2 是 SSL/TLS。智能卡场景必须用 2 或者 1用 0 的话智能卡凭据根本没法传递会直接报安全层错误。UserAuthentication为 1 表示启用 NLA。MinEncryptionLevel为 3 表示高加密一般保持默认。还有一个容易忽略的点会话主机的 RDP 证书。如果用的是自签名证书且客户端不信任它TLS 握手会失败。老版本客户端的表现就是“安全层在协议流中检测到错误”不会告诉你证书不受信任。可以在服务器上用Get-ChildItem Cert:\LocalMachine\Remote Desktop看一下证书是否存在、是否过期、颁发者是谁。3.6 第六步最后再抓包用证据收口前面五步都排除之后再上抓包。用 Wireshark 在客户端抓过滤条件tcp.port 3389重点看 TLS 握手阶段的 Alert 消息。如果看到handshake_failure或者protocol_version就是加密套件或 TLS 版本不匹配如果看到unknown_ca就是证书链问题如果 TLS 握手完成了但后面紧跟着 RST那就是 CredSSP 层。在服务器侧同时开一个网络监视或者用netsh trace抓一份两边对时间戳能很精确地定位断点在哪。这套方法听着重但当你前面五步都走完还没找到问题时抓包往往十分钟就能收口。4. 老系统特有的坑Win7 与 2008 R2 的参数调整实录这两个系统放在今天已经属于“能用但到处是雷”的状态。它们的默认配置是十几年前的安全基线跟现在企业环境的加固策略经常正面冲突。下面这几个坑我在实际环境里反复遇到基本都是“配置看起来没毛病但就是不工作”的类型。4.1 CredSSP 版本差异导致的握手失败Win7 的 mstsc 版本是 6.1它支持的 CredSSP 版本比较早。2008 R2 的 TermService 同样。这两个系统之间原本是匹配的问题出在后续补丁上。如果服务器打了 CredSSP 的强制修正补丁而客户端没打服务器会要求客户端支持较新的 CredSSP 版本客户端不支持握手失败。判断方法在客户端跑winver和Get-HotFix看有没有对应的安全更新在服务器上同样。两边的补丁级别必须能对上。这一点没有捷径只能补齐。补齐之后建议把AllowEncryptionOracle恢复成默认值不要长期停留在易受攻击档。4.2 TLS 1.0 被禁用后的连锁反应现在很多安全基线要求禁用 TLS 1.0 和 1.1。这个要求在 Win10/2016 以上没问题但在 Win7/2008 R2 上会导致 RDP 完全不可用因为这两个系统默认不支持 TLS 1.2 作为服务端。2008 R2 需要安装特定更新才能启用 TLS 1.2 支持Win7 也需要。如果补丁装不上比如已经停止支持的版本那就只能在 RDP 这个场景下单独放开 TLS 1.0并且用其他手段补偿风险比如限制来源网段、强化审计。我一般的处理方式是先在服务器上确认 TLS 1.2 是否可用用Get-TlsCipherSuite看套件列表如果列表里只有 TLS 1.0 的套件说明补丁没打到位。这种情况下强行禁用 TLS 1.0 就是自找麻烦。4.3 智能卡移除行为与会话锁定这个坑很隐蔽。组策略里有一项“交互式登录智能卡移除行为”默认是“无操作”。如果被配置成了“锁定工作站”或者“强制注销”那么智能卡一旦离开读卡器远程会话就会被锁定或断开。在远程桌面场景下用户经常把卡拔出来去别的地方用回来后发现会话断了还以为是网络问题。实际上这是策略行为。排查的时候用gpresult看这条策略的最终值路径在“计算机配置 → Windows 设置 → 安全设置 → 本地策略 → 安全选项”。如果环境确实需要“拔卡即锁”那就得接受这个行为但要提前告知用户如果不需要就改回“无操作”。4.4 时间同步偏差超过容差Kerberos 默认允许的时间偏差是 5 分钟。智能卡 PKINIT 对时间更敏感因为证书验证本身也有时间窗口。在老环境里如果会话主机没有正确同步时间源或者虚拟化平台做了时间漂移就会出现“证书明明有效认证却失败”的情况。检查很简单w32tm /query /status w32tm /stripchart /computer:域控地址 /samples:5如果偏移超过几秒就要处理。会话主机应该指向域控做时间同步域控再指向可靠的时间源。这条在虚拟化环境里尤其要注意因为虚拟机快照恢复、挂起恢复都会导致时间跳变。4.5 RDP 会话主机上的“仅允许运行使用网络级别身份验证的远程桌面的计算机连接”这个选项在系统属性 → 远程里。勾上之后强制 NLA。智能卡登录本来就需要 NLA 来提前传递凭据所以这个选项理论上是必要的。但问题在于如果客户端版本太老、或者 CredSSP 版本不匹配勾上这个选项就等于直接把老客户端挡在门外报错就是那句熟悉的安全层错误。我的做法是先确认两端补丁匹配再勾这个选项如果环境里确实混着老客户端就在服务器上临时取消勾选做验证确认问题是否出在这里但不要在未打补丁的环境里长期关闭 NLA。5. 常见问题速查表与踩坑实录把上面这些整理成一张表遇到问题的时候可以直接对照比从头推理快。现象最可能的原因快速验证方法处理方向客户端报安全层错误服务器无任何登录日志TLS/CredSSP 握手失败查 Schannel 36871/36874 事件补齐补丁核对 TLS 版本与加密套件客户端报安全层错误服务器有 4625 且状态 0xC000006D证书到账户映射失败certutil -scinfo对比 AD 的 UPN重签证书或配置 AltSecurityIdentities4625 状态 0xC000015B登录类型未授予查用户权限分配与账户“登录到”补权限、解除计算机限制证书有效但域控拒绝CA 未在 NTAuth 存储certutil -viewstore NTAuth手动执行 enterprise addstore认证偶尔成功偶尔失败时间漂移或 CRL 检查超时w32tm /stripchart修时间源确保 CRL 可达本地登录正常远程桌面失败RDP 监听器安全层设置查 RDP-Tcp 的 SecurityLayer改为 1 或 2确认 NLA会话建立后立即断开智能卡移除策略gpresult查安全选项改为“无操作”用户在某组里但仍被拒同时在“拒绝登录”组中对比两个权限列表从拒绝组中移除再说几个我在实际环境里踩过的具体坑。一个是中间证书缺失。某次环境里根 CA 是新的中间 CA 也是新的客户端能正常选证书服务器也收到了但域控验证链的时候找不到中间 CA。原因是证书的 AIA 扩展指向了一个内网 HTTP 地址而域控所在网段访问不到那个地址。解决办法是在域控的受信任根存储和中间 CA 存储里手动导入中间证书不依赖 AIA 下载。这个问题的迷惑性在于客户端侧一切正常只有服务端验证失败。另一个是读卡器驱动导致的偶发失败。某实验室的一批机器用的是同一型号读卡器其中几台在远程登录时偶发“安全层错误”换台机器就好。最后查明是读卡器固件版本不一致旧固件在并发读取时偶发失败导致证书选择对话框返回了空值客户端带着空凭据去握手自然失败。这类问题用日志根本查不出来只能靠交叉验证同样的账户换机器、同样的机器换账户把变量收缩到硬件上。还有一次是组策略的优先级问题。OU 级别的 GPO 里把“允许通过远程桌面服务登录”设置成了只包含 Administrators而用户是通过一个自定义组获得权限的那个组在更上层的 GPO 里有但在更下层的 GPO 里被覆盖了。gpresult 一看就明白了但如果不看结果集只逐层看策略设置很容易漏。注意排查这类问题时一定要看“最终生效的策略”而不是“某个 GPO 里写了什么”。组策略的继承和覆盖关系是最容易让人误判的地方gpresult /h生成的那份 HTML 报告值得多花两分钟仔细读。最后分享一个我觉得最省时间的习惯在动手改任何配置之前先把当前状态完整记录下来。包括注册表的相关键值、gpresult 的结果、certutil -scinfo 的输出、事件日志的时间窗口。老环境里经常出现“改了一个地方另一个地方又坏了”的情况没有基线记录回滚都无从下手。我吃过这个亏一次为了排查安全层错误临时把AllowEncryptionOracle降到 1后来忘了改回去几个月后做安全审计时才被发现那段时间里这台机器的实际安全强度是下降的。从那以后我改任何与安全相关的键值都会在变更记录里写清楚原因和恢复条件。这类问题的本质其实不复杂难的是把“传输层”“认证层”“授权层”这三层分开看。大部分人在第一层就卡住了因为报错信息太笼统少部分人越过了第一层却在第二层和第三层之间来回打转。把判断分界线建立起来——先看有没有 4625、再看状态码是什么——后面的事情就是按图索骥。老系统的问题会越来越多但只要这套分层思路在换什么系统都能套用。
知识建站
内容驱动
阅读友好版式
SEO 精细化
线索转化