Azure AD 密码同步悄悄停了四天：改了密码却还要用旧密码登录 M365
用户报障的说法很玄学：「我改了密码，电脑能登，但 Outlook/Teams 要用旧密码才能进。」
这个症状指向一个很具体的方向：本地 AD 和 Azure AD 之间的密码同步断了——目录对象还在同步（所以账号没有异常），但 password hash 停止上云，Azure AD 手里还是旧密码的 hash。
确认症状
Microsoft 365 admin center → Health → Directory sync status，一眼就能看到问题：
| 项目 | 状态 |
|---|---|
| Directory sync | On |
| Last directory sync | 13 minutes ago（正常） |
| Password sync | On |
| Last password sync | 4 days ago（红字 + Troubleshoot 链接） |
目录同步 13 分钟前刚跑过，密码同步却停在四天前——两条通道是独立的，一条活着不代表另一条没死。
事发当时的 Directory sync status（真实截图）——那行红色的 “4 days ago” 就是全部答案
根因
到 Azure AD Connect 服务器上打开 Synchronization Service Manager 排查，最后定位到的原因让人哭笑不得：同步用的账号密码过期了。
域里的密码过期策略一视同仁地作用到了这个账号上。密码一过期，password hash sync 就开始静默失败——没有弹窗、没有邮件，什么都没有，只有 admin center 里那行红字。
修复
- 把同步账号的密码策略改为 password never expires（服务账号本就该如此）；
- 触发一次 full sync，在 AAD Connect 服务器上：
Start-ADSyncSyncCycle -PolicyType Initial- 回到 Directory sync status 页面确认 Last password sync 变成几分钟前，再找报障用户确认新密码可以登录 M365。
微软有一篇专门的 troubleshoot 文档（admin center 红字旁边的 Troubleshoot 链接就指向它），排查思路值得收藏：事件日志里查 611/650/651 系列事件，能更快定位 password sync 失败的具体环节。
教训
- 服务账号一律 never expires + 强随机密码。让人类密码策略去管服务账号，就是定时炸弹；
- Directory sync 正常 ≠ password sync 正常，监控要分开看两个时间戳；
- 这类静默失败又是「没有告警就等于没有监控」的案例——admin center 的 Directory sync status 值得纳入每周巡检清单（和 RSP 备份检查一个待遇）；
- 用户说「要用旧密码才能登」的时候，别怀疑用户记错了——这是一个精确的技术信号。