RDP智能卡登录AD域：安全层错误与0xC000015B排查

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 状态码是 0xC000018B（SAM 数据库或域信任关系故障），那要去看域控和网络。

我在一次实际排查中见过更迷惑的情况：服务器日志里 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 死穴一：证书到账户的映射对不上

这是最隐蔽也最常见的一个。智能卡证书里携带用户身份靠的是 SAN（Subject Alternative Name）扩展里的 UPN，格式通常是user@domain.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，跟“允许”里漏配的表现一模一样。我在一次排查里就遇到过：用户被加进了允许列表，但他同时在另一个被整体加入“拒绝”列表的安全组里，查了两小时才定位到。

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 账户的 UPN：

Get-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 MinEncryptionLevel

SecurityLayer的取值：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. 常见问题速查表与踩坑实录

把上面这些整理成一张表，遇到问题的时候可以直接对照，比从头推理快。

再说几个我在实际环境里踩过的具体坑。

一个是中间证书缺失。某次环境里根 CA 是新的，中间 CA 也是新的，客户端能正常选证书，服务器也收到了，但域控验证链的时候找不到中间 CA。原因是证书的 AIA 扩展指向了一个内网 HTTP 地址，而域控所在网段访问不到那个地址。解决办法是在域控的受信任根存储和中间 CA 存储里手动导入中间证书，不依赖 AIA 下载。这个问题的迷惑性在于客户端侧一切正常，只有服务端验证失败。

另一个是读卡器驱动导致的偶发失败。某实验室的一批机器用的是同一型号读卡器，其中几台在远程登录时偶发“安全层错误”，换台机器就好。最后查明是读卡器固件版本不一致，旧固件在并发读取时偶发失败，导致证书选择对话框返回了空值，客户端带着空凭据去握手，自然失败。这类问题用日志根本查不出来，只能靠交叉验证：同样的账户换机器、同样的机器换账户，把变量收缩到硬件上。

还有一次是组策略的优先级问题。OU 级别的 GPO 里把“允许通过远程桌面服务登录”设置成了只包含 Administrators，而用户是通过一个自定义组获得权限的，那个组在更上层的 GPO 里有，但在更下层的 GPO 里被覆盖了。gpresult 一看就明白了，但如果不看结果集，只逐层看策略设置，很容易漏。

注意：排查这类问题时，一定要看“最终生效的策略”，而不是“某个 GPO 里写了什么”。组策略的继承和覆盖关系是最容易让人误判的地方，gpresult /h生成的那份 HTML 报告值得多花两分钟仔细读。

最后分享一个我觉得最省时间的习惯：在动手改任何配置之前，先把当前状态完整记录下来。包括注册表的相关键值、gpresult 的结果、certutil -scinfo 的输出、事件日志的时间窗口。老环境里经常出现“改了一个地方，另一个地方又坏了”的情况，没有基线记录，回滚都无从下手。我吃过这个亏，一次为了排查安全层错误临时把AllowEncryptionOracle降到 1，后来忘了改回去，几个月后做安全审计时才被发现，那段时间里这台机器的实际安全强度是下降的。从那以后我改任何与安全相关的键值，都会在变更记录里写清楚原因和恢复条件。

这类问题的本质其实不复杂，难的是把“传输层”“认证层”“授权层”这三层分开看。大部分人在第一层就卡住了，因为报错信息太笼统；少部分人越过了第一层，却在第二层和第三层之间来回打转。把判断分界线建立起来——先看有没有 4625、再看状态码是什么——后面的事情就是按图索骥。老系统的问题会越来越多，但只要这套分层思路在，换什么系统都能套用。