本文描述了一种常见情况，即审核日志显示许多由已验证的域更改触发的 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
状态：成功
类别：用户管理
服务：核心目录
目标 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 正在更新审核日志中的“Actor”信息，将这些更改识别为已验证域更改所触发的事件。 此操作帮助检查已验证的域更改事件的发生时间，并开始大规模更新其租户中的对象。
在大多数情况下，没有任何用户更改，因为其 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 验证域。