每天下午5点，RDS 远程应用集体断线——罪魁祸首是二次验证自己的计时器
有用户反映，使用 RemoteApp 远程应用时经常在下午 5 点前后被断开连接。第一反应是去检查 RD 会话相关的超时设置，结果发现：没有配置任何主动会话时长限制，也不是空闲超时导致的——如果是空闲超时，断线提示的措辞会明显不同（提示”因为没有收到任何输入而终止会话”），而实际收到的报错并不是这个说法。
两种”超时”，排除了两种，问题却还在
- 检查了 RD 会话集合的主动会话时长限制（Active Session Limit）：没有配置；
- 检查了空闲超时（Idle Timeout）：报错措辞对不上，判断不是这个原因导致。
两个最直觉的怀疑对象都被排除之后，问题反而变得更麻烦——如果两个最常见的超时机制都不是原因，那到底是什么在掐断这些会话？
当熟悉的怀疑对象都被排除，答案往往在一个完全没想到的地方
真正的计时器：二次验证服务自己的会话时长上限
搜索类似症状后发现，这类”固定时间点集体断线”的现象，在使用 DUO 二次验证保护 RD Gateway 的场景下是一个已知问题——DUO 为通过 RD Gateway 的会话设置了一个默认 8 小时的授权会话时长上限（Authorized Session Max Duration），这个计时器从用户完成二次验证的那一刻开始倒数，和会话是否活跃、有没有操作完全无关。如果大部分用户习惯早上 9 点上班登录，8 小时之后正好是下午 5 点——每天在同一个时间点集体断线，规律性由此而来。
这类问题之所以难查，在于它不属于 Windows 或 RDS 的任何一层超时机制，而是二次验证服务自己在会话建立之后另外维护的一个独立计时器，日常排查 RDS 设置根本不会想到要往这个方向查。
修复
厂商官方提供了修改这个默认值的方法（明确标注为”非官方支持，自行承担风险”）：在 RD Gateway 服务器的注册表 HKEY_LOCAL_MACHINE\SOFTWARE\Duo Security\DuoTsg 下，新建 DWORD 值 AuthorizedSession_MaxDuration，以分钟为单位设置新的会话时长上限（本例设置为 780 分钟，即 13 小时）；同时可以配合调整 AuthorizedSession_IdleTimeout（本例设置为 6 小时）。改动前后都对注册表做了备份。
教训
- “固定时间点、大范围集体发生”的症状，本身就是一条重要线索——如果只是个别用户偶发断线，方向可能是网络质量；但当断线时间高度集中在同一个时间点，且影响面很广，说明背后大概率是某个从固定起点开始计时的计时器，而不是随机的网络问题；
- 叠加在原有系统之上的安全组件（2FA、SSO 网关等），往往自带一套独立于底层系统的会话管理逻辑——本例的会话超时根本不受 RDS/Windows 自身设置控制，安全组件本身的会话策略经常是这类”排查了很久都找不到原因”问题的盲区；
- 遇到熟悉的怀疑对象都被排除、但问题依然存在的情况，下一步该往”这条链路上还有哪些环节我没有考虑过”去想，而不是重新怀疑已经排除过的选项——本例的答案就藏在认证链路里最容易被忽略的一环。