了解已验证域更改期间的批量用户更新
本文描述了一种常见情况，即审核日志显示许多由已验证的域更改触发的 UserPrincipalName 更新。 本文介绍在已验证域更改期间发生的审核日志中 UserManagement 更新的原因和注意事项。 该文章深入探讨了触发 Microsoft Entra ID 中大规模对象更改的后端操作。
现象
Microsoft Entra 审核日志显示 Microsoft Entra 租户中发生了多个用户更新。 这些事件的行动者信息为空或显示 N/A。
批量更新涉及将 UserPrincipalName 的域从组织的首选域更改为默认的 *.partner.onmschina.cn 域后缀。
示例审核日志详细信息
活动日期 (UTC)：2022-01-27 07:44:05
活动：更新用户
行动者类型：其他
行动者 UPN：N/A
状态：成功
类别：UserManagement
服务：核心目录
目标 ID：aaaaaaaaa-bbbb-0000-11111-bbbbbbbbbbbbb
目标名称：user@contoso.com
目标类型：用户
在审核日志条目的完整详细信息中，查找 modifiedProperties 部分。 此部分显示对用户对象进行的更改。 oldValue 和 newValue 字段显示域更改。
"modifiedProperties":
"displayName": "UserPrincipalName",
"oldValue": "[\"user@contoso.partner.onmschina.cn\"]",
"newValue": "[\"user@contoso.com\"]"
原因
大量对象更改背后的一个常见原因是非同步后端操作。 此操作确定在 Microsoft Entra 用户、组或联系人中更新的相应 UserPrincipalName 和 proxyAddresses。
此后端操作旨在确保 Microsoft Entra ID 中的 UserPrincipalName 和 proxyAddresses 随时保持一致。 显式更改（如已验证的域更改）会触发此操作。
例如，如果将已验证的域 Fabrikam.com 添加到 Contoso.partner.onmschina.cn 租户，则此操作会在租户中的所有对象上触发后端操作。 Microsoft Entra 审核日志中将此事件捕获为“更新用户”事件，其前面是“添加已验证的域”事件。
如果已从 Contoso.partner.onmschina.cn 租户中删除 Fabrikam.com，则所有“更新用户”事件前面都是“删除已验证的域”事件。
解决方法
如果遇到此问题，可以使用 Microsoft Entra Connect 在本地目录和 Microsoft Entra ID 之间同步数据。 此操作可确保 UserPrincipalName 和 proxyAddresses 在两个环境中保持一致。
尝试手动添加或维护这些对象时，将面临另一个后端操作触发批量更改的风险。
查看以下文章以熟悉这些概念：
注意事项
此后端操作不会导致符合以下条件的特定对象发生更改：
- 没有有效的 Microsoft Exchange 许可证
MSExchRemoteRecipientType设置为 Null- 不被视为共享资源
共享资源是指当 CloudMSExchRecipientDisplayType 包含以下值之一的情况：
MailboxUser（共享）PublicFolderConferenceRoomMailboxEquipmentMailboxArbitrationMailboxRoomListTeamMailboxUserGroupMailboxSchedulingMailboxACLableMailboxUserACLableTeamMailboxUser
为了在这两个不同的事件之间建立更多的关联，Microsoft 正在努力更新审核日志中的“行动者”信息，以将这些更改识别为由已验证的域更改触发。 此操作帮助检查已验证的域更改事件的发生时间，并开始大规模更新其租户中的对象。
在大多数情况下，没有任何用户更改，因为其 UserPrincipalName 和 proxyAddresses 是一致的，因此，我们只在审核日志中显示那些导致对象实际更改的更新。 此操作会阻止审核日志中出现干扰，并帮助管理员将其余用户更改与已验证的域更改事件关联。
深入探索
想要了解幕后发生的情况？ 下面深入探讨了触发 Microsoft Entra ID 中大规模对象更改的后端操作。 在深入了解之前，请查看 Microsoft Entra Connect Sync 服务影子属性一文，了解影子属性。
UserPrincipalName
对于仅限云的用户，UserPrincipalName 设置为已验证的域后缀。 处理不一致的 UserPrincipalName 时，此操作会将其转换为默认的 partner.onmschina.cn 后缀，例如 username@Contoso.partner.onmschina.cn。
对于已同步的用户，UserPrincipalName 设置为已验证的域后缀，并与本地值 ShadowUserPrincipalName 匹配。 处理不一致的 UserPrincipalName 时，该操作还原为与 ShadowUserPrincipalName 相同的值，或者，如果已从租户中移除域后缀，则会将其转换为默认的 *.partner.onmschina.cn 域后缀。
ProxyAddresses
对于仅限云的用户，一致性意味着 proxyAddresses 与已验证的域后缀匹配。 处理不一致的 proxyAddresses 时，后端操作会将其转换为默认的 *.partner.onmschina.cn 域后缀，例如：SMTP:username@Contoso.partner.onmschina.cn。
对于已同步的用户，一致性意味着 proxyAddresses 与本地 proxyAddresses 值（即 ShadowProxyAddresses）相匹配。 proxyAddresses 应与 ShadowProxyAddresses 同步。 如果向已同步的用户分配了 Exchange 许可证，则云和本地值必须匹配。 这些值还必须与已验证的域后缀匹配。
在此方案中，后端操作会清理具有未验证的域后缀的不一致 proxyAddresses，并从 Microsoft Entra ID 中的对象中移除。 如果该未验证的域稍后通过了验证，则后端操作重新计算 proxyAddresses，并将其从 ShadowProxyAddresses 添加回 Microsoft Entra ID 中的对象。
注意
对于已同步的对象，若要避免后端操作逻辑计算出意外的结果，最好将 proxyAddresses 设置为本地对象上的 Microsoft Entra 验证域。