Outlook 无限弹密码框：清了 Credential Manager 也没用的那种
用户的 Outlook（Microsoft 365 版客户端 + on-prem Exchange）开始无限弹凭据登录框。这个故障最气人的地方在于它的行为完全不讲逻辑：
- 弹框后点取消——Outlook 照常连接，邮件正常收发；
- 重新输入正确密码——也正常，但过一会儿又弹；
- 清空 Credential Manager 里的所有缓存凭据——毫无变化。
常规偏方全家桶（都试了）
这是个古老且著名的故障，网上的排查清单大同小异：
- 检查账户设置里「总是提示登录凭据」有没有被勾上；
- 清 Credential Manager 缓存凭据（试过，没用）；
- Outlook Anywhere 的认证方式是否为 NTLM；
- 新建 Outlook profile（试过，弹框依旧）；
- 损坏的 OST、防病毒插件、共享日历、不稳定的网络……
一套跑完，问题纹丝不动。
真正有价值的线索
抓行为细节的时候发现：弹出的凭据框里，Outlook 尝试用的身份是云端格式的 UPN（user@<云端域名>），而我们 on-prem Exchange 认的是域格式（DOMAIN\user）。
“点取消也能用”的完整解释：收发邮件走的路和弹框的路根本不是同一条
这一下就说通了：这台机器上装的是 Microsoft 365 版的 Office，它天然倾向走 modern auth、拿云端身份去认证；而邮箱还在本地 Exchange 上，两边的身份体系对不上。Outlook 每隔一段时间试图用云身份握手 → 失败 → 弹框问人；而底层的 NTLM 通道其实一直是通的，所以点取消也不影响收发。
这也解释了为什么所有客户端侧的偏方都无效——问题不在这台电脑，在架构：云版客户端 + 本地邮箱的组合，就是会在认证的夹缝里反复横跳。
结局
临时缓解只能靠「点取消」共存。真正的解法写在架构路线图里：上 Exchange Hybrid / 迁移 Exchange Online，让邮箱和客户端在同一套 modern auth 体系里，这个弹框从根上消失。（后来 Hybrid 上线，此问题绝迹。）
教训
- 「点取消也能正常用」是个强信号：真正的连接是通的，弹框来自某条额外的、失败的认证路径——排查方向应该是「谁在多此一举」，而不是「连接为什么不通」；
- 弹框里预填的用户名格式（UPN vs DOMAIN\user）是最有信息量的线索，比任何日志都直白；
- 客户端偏方跑完两三个还没效果，就该停下来问：这是不是架构层的问题？ 在错误的层级排查，做多少都是无用功；
- 云版 Office + 本地 Exchange 是一个「能用但拧巴」的过渡态组合——它产生的怪问题，最终解法往往都叫 Hybrid。