网络资讯
给远程桌面加上第二道验证，并不等于所有连接都自动受条件访问保护。规划RDP远程桌面多因素认证与条件访问配置时，先确认用户通过什么入口连接：云端托管的 Azure Virtual Desktop（AVD），还是经由 RD Gateway 访问内部主机。入口不同，策略生效的位置也不同。
1. 先画清认证路径，别把两种控制混为一谈
Microsoft Entra 条件访问主要评估云端登录请求，可按用户、应用、设备状态或风险等条件决定是否要求 MFA、限制访问。传统 RD Gateway 则可通过 RADIUS 与 NPS 等组件接入 MFA。两者并非天然联动：给云应用设了条件访问，不代表任意一台可直连的 RDP 主机都会执行这条规则。
先记录用户、客户端、网关、身份验证服务和目标主机的顺序。若使用 AVD，检查其对应的云端应用登录是否纳入条件访问；若使用 RD Gateway，单独核实网关及 MFA 的配置路径。不要把直接开放的主机端口当成受网关策略保护。
2. 选择与连接入口匹配的 MFA 方案
云端桌面与内部网关分别处理
AVD 场景可在 Entra 管理中心为相关应用建立条件访问策略，要求 MFA，并按组织能力增加设备合规等条件。内部 RDP 场景可评估 RD Gateway 配合 RADIUS/NPS MFA；部署前应确认组件版本、身份验证流程和支持范围。NPS 扩展一类方案不应被视为完整的 Entra 条件访问替代品。
优先考虑抗钓鱼认证方式，例如安全密钥或平台通行密钥；若环境尚不支持，可使用经过组织批准的验证器方式。短信验证码对号码劫持等风险更敏感，不宜在条件允许时作为首选。还要测试连接客户端是否能正确完成二次验证。
3. 把策略写成可验证的条件
不要只写“要求 MFA”。明确哪些用户、哪些云应用或网关、哪些设备和网络位置适用，以及不满足条件时是阻止还是要求补充验证。地点条件可用于识别异常来源，但网络地址可能因代理、漫游或出口变化而改变，不宜单独作为可信证明。
- 建立策略前，确认目标应用和用户组范围，避免误把管理员或普通用户纳入错误对象。
- 先以报告模式观察策略评估结果，查看登录日志中命中的条件和结果。
- 选少量测试账户试行，分别验证受管设备、未受管设备和非预期网络的行为。
- 确认无误后分批启用，并记录负责人、变更时间及回退办法。
4. 缩小暴露面，并保留应急通道
优先让外部用户经受控网关进入，不要把 RDP 服务直接暴露到公网；在防火墙上仅允许必要来源访问网关，主机侧也只开放业务所需范围。MFA 能降低密码被盗后的风险，却不能替代网络隔离、补丁管理和最小权限。
为账号遗失、验证器故障或身份服务中断准备应急流程。应急账户数量应尽量少，凭据独立保管，并设置告警和定期检查；不要简单把常用管理员账号排除在策略之外。变更前确认至少有一条可用的管理恢复路径。
5. 用日志和复测保持配置有效
上线后检查 Entra 登录日志、RD Gateway 或 NPS 认证记录，以及主机安全日志，重点关注 MFA 未完成、策略未命中、重复失败和异常来源。日志保留时间与告警能力取决于具体服务和组织设置，应提前核对。用户组、客户端版本、网关证书或身份策略发生变化后，都要重新测试。
好的RDP远程桌面多因素认证与条件访问配置，不是策略越多越安全，而是每个入口都有明确的认证控制，且管理员能从日志证明控制确实生效。
常见问题
条件访问能直接保护所有 RDP 连接吗？
不能。它针对符合条件的云端身份验证流程；传统 RDP 连接还需确认网关和 MFA 的具体实现。
已经要求 MFA，还需要限制网络吗？
需要。限制可访问网关的来源、避免主机直接暴露，能减少凭据攻击和服务探测带来的风险。
上线前如何降低误锁风险？
先用报告模式和小范围试点，验证不同设备与网络下的登录，再分批启用，并准备经过测试的应急恢复流程。