GitHub 修复 EMU 删除同步，企业身份管理受哪些影响

GitHub 这次修复影响的是 Enterprise Managed Users（EMU）的 SCIM 删除同步路径。结论先说：如果企业审计日志在 2026 年 6 月 1 日至 6 月 13 日出现 EMU 用户的 user.delete 事件，属于受影响范围；GitHub 已在 2026 年 10 月恢复相关用户记录，企业 owner 不需要手动修复。没有这类事件，则不属于这次已知影响。

官方资料：https://github.blog/changelog/2026-10-23-emu-deletions-fix/

先用审计日志判断是否命中

不要根据某个员工现在能否登录来倒推这次事件。GitHub 给出的判断条件是：企业审计日志在指定日期窗口内出现 EMU 账号的 user.delete 事件。查询时至少保留事件时间、用户原有标识、组织或企业范围，以及事件前后的 SCIM 操作记录。

如果窗口内没有对应事件，就不需要因为这篇公告重新导入人员、重建组织成员关系或批量触发 Provision on Demand。若存在事件，先把名单交给企业身份管理员留档，再观察恢复后的账号状态。

这次异常为什么会产生 ghost user

正常情况下，SCIM 解除配置不是简单地把用户从系统里抹掉。软解除配置会暂停账号、混淆用户名，并保留关联记录，以便审计和后续重新启用；硬解除配置则是不可逆的永久停用路径。GitHub 公告说明，6 月 1 日启用的新路径没有正确识别 EMU 账号，于是部分本应走“暂停并混淆”的请求错误地落到了删除结果上。

因此，issue、pull request 和审计日志里的作者不再显示为企业内预期的暂停用户记录，而表现为 ghost user。这个现象更像身份记录生命周期被截断，不是仓库内容、PR 权限或评论正文被批量删除。

恢复后企业身份管理要看哪些边界

需要特别注意：GitHub 已说明，大多数受影响账号此前已经处于暂停和 hard-deprovision 状态，按设计不能重新配置；另有少量账号在删除时仍处于 active。这个区分决定了管理员是做影响核对，还是进入正常的新账号配置流程，不能把所有名单都当成可直接恢复登录的用户。

企业管理员的收尾检查清单

1. 导出 2026-06-01 至 2026-06-13 的 EMU 相关审计事件，单独标记 user.delete。
2. 将事件名单与 IdP 的停用、删除、重新配置记录逐项对照。
3. 确认恢复后用户是否回到暂停和混淆状态，不要只看登录失败这一单一现象。
4. 检查 PingFederate、Entra ID 或 REST SCIM 集成是否把普通停用误发成硬删除。
5. 把本次事件窗口、恢复结论和人工处置记录放入身份生命周期变更台账。

常见问题

没有 6 月 1 日至 13 日的 user.delete，还要做什么？

按 GitHub 公告的判断条件，不需要为这次事件做额外恢复。保留一次查询结果即可，避免重复触发账号同步。

恢复后的账号能直接重新登录吗？

不能一概而论。被恢复的记录回到预期暂停和混淆状态；是否能登录仍取决于 IdP 当前状态与正常 SCIM 重新配置流程。

hard-deprovision 的账号能否原地恢复？

不能。GitHub 文档明确说明硬解除配置不可恢复，需要配置新账号，旧账号创建的资源也不会自动并入新账号。