4月17日,微软承认两个补丁编号——KB5082063与KB5082142——正在让全球企业的Windows Server域控制器变成"重启永动机"。这不是比喻,是字面意义上的无限循环崩溃。
故障机制:两个安全模块的致命冲突
![]()
问题出在特权访问管理(PAM)与本地安全机构服务器服务(LSASS)的兼容性断裂。PAM负责隔离环境中管控特权账户,LSASS则是Windows身份验证的守门员——你每次登录、每次访问网络资源,都要经过它。
4月更新让两者互相"误伤":LSASS进程崩溃→系统触发保护性重启→重启后再次崩溃。循环往复,直到整个Active Directory域瘫痪。
更隐蔽的触发条件:新建域控制器、启动早期处理认证请求,都可能引爆。这意味着不是所有环境都会立刻中招,但风险像地雷一样埋着。
正方观点:这是企业级软件的常态代价
支持微软的一方会指出:Windows Server支撑着全球数百万组织,补丁复杂度与测试矩阵是天文数字。PAM与LSASS的交互场景本就属于高级安全功能,边缘案例遗漏难以完全避免。
临时缓解措施已放出,企业支持通道畅通——对于付费客户而言,这属于可接受的响应速度。相比完全静默的安全漏洞,可控的、可回滚的故障反而是运维更可预期的风险类型。
反方观点:信任损耗正在累积
批评者关注的是模式。过去18个月,微软多次补丁翻车:2023年1月导致VPN故障,2024年3月引发蓝屏死机,再到这次的域控制器瘫痪。每次事后流程相似——承认、缓解、修复、循环。
企业IT的噩梦不是修复本身,是"要不要第一时间打补丁"的决策困境。延迟更新暴露于已知漏洞,立即更新则可能引入生产环境崩溃。这种两难正在将补丁管理变成博弈论问题。
判断:基础设施软件的"免疫反应"困境
我的看法是:这不是技术失误的个案,而是超大规模系统维护的结构性张力。微软的安全更新频率与功能覆盖广度,本质上与"零故障"目标存在数学矛盾。
真正值得追踪的指标有两个——从报告到缓解措施的时间窗口(本次约24小时),以及修复补丁的回归测试透明度。后者微软从未公开,也是企业信任最难量化的部分。
数据收束:NeoWin报道发布于4月17日,故障影响范围尚未有官方统计。但一个参考维度是:Windows Server 2022的扩展支持将持续至2031年,这意味着类似场景还有六年以上的重复上演空间。
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.