瞭解已驗證網域變更期間的大量使用者更新
本文說明稽核記錄顯示由已驗證網域變更觸發的許多 UserPrincipalName 更新的常見案例。 本文說明在已驗證網域變更期間發生的稽核記錄中 UserManagement 更新的原因和考慮。 本文提供深入探討後端作業，以觸發 Microsoft Entra 標識碼中的大量物件變更。
徵兆
Microsoft Entra 稽核記錄顯示我的 Microsoft Entra 租用戶中發生多個使用者更新。 這些 事件的動作項目 資訊是空的，或顯示 N/A。
大量更新牽涉到將 變更的網域 UserPrincipalName 從組織的慣用網域變更為預設 *.onmicrosoft.com 網域後綴。
範例稽核記錄詳細數據
活動日期 （UTC）： 2022-01-27 07：44：05
活動：更新使用者
動作項目類型：其他
動作專案 UPN：N/A
狀態：成功
類別：UserManagement
服務：核心目錄
目標標識碼：aaaaaaaaa-bbbb-0000-11111-bbbbbbbbbbb
目標名稱： user@contoso.com
目標類型：使用者
在稽核記錄專案的完整詳細數據中，尋找 區 modifiedProperties 段。 本節顯示對用戶物件所做的變更。 oldValue和 newValue 欄位會顯示網域變更。
"modifiedProperties":
"displayName": "UserPrincipalName",
"oldValue": "[\"user@contoso.onmicrosoft.com\"]",
"newValue": "[\"user@contoso.com\"]"
原因
大量物件變更背後的一個常見原因是非同步後端作業。 此工作會決定 Microsoft Entra 使用者、群組或聯絡人中已更新的適當 UserPrincipalName 和 proxyAddresses 。
此後端作業的目的可確保 UserPrincipalName 和 proxyAddresses 隨時在 Microsoft Entra ID 中保持一致。 明確變更，例如已驗證的網域變更，會觸發這項作業。
例如，如果您將已驗證的網域 Fabrikam.com 新增至 Contoso.onmicrosoft.com 租使用者，此動作會觸發租使用者中所有物件的後端作業。 此事件會在 Microsoft Entra 稽核記錄中擷取，因為 更新使用者 事件之前有 新增已驗證的網域 事件。
如果 Fabrikam.com 已從 Contoso.onmicrosoft.com 租使用者中移除，則所有 更新使用者 事件前面都會有 移除已驗證的網域 事件。
解決方法
如果您遇到此問題，可能受益於使用 Microsoft Entra 連線，在內部部署目錄與 Microsoft Entra ID 之間同步處理數據。 此動作可確保 UserPrincipalName 和 proxyAddresses 在這兩個環境中都保持一致。
當您嘗試手動新增或維護這些物件時，您會執行另一個觸發大量變更的後端作業風險。
請檢閱下列文章，以熟悉這些概念：
考量
此後端作業不會對下列特定物件造成變更：
- 沒有作用中的 Microsoft Exchange 授權
- 已
MSExchRemoteRecipientType設定為 Null - 不會被視為共享資源
共用資源包含下列其中一個值時 CloudMSExchRecipientDisplayType ：
MailboxUser（共用）PublicFolderConferenceRoomMailboxEquipmentMailboxArbitrationMailboxRoomListTeamMailboxUserGroupMailboxSchedulingMailboxACLableMailboxUserACLableTeamMailboxUser
為了在這兩個不同事件之間建立更多相互關聯，Microsoft 正努力更新 稽核記錄中的動作項目 資訊，以識別這些變更，如已驗證網域變更所觸發。 此動作有助於檢查驗證的網域變更事件何時發生，並開始大量更新租使用者中的物件。
在大部分情況下，使用者不會變更為和UserPrincipalNameproxyAddresses一致，因此我們只在稽核記錄中顯示導致對象實際變更的更新。 此動作可防止稽核記錄中的雜訊，並協助系統管理員將其餘用戶變更與已驗證網域變更事件相互關聯。
深入探索
想要深入瞭解幕後發生了什麼事？ 以下是深入探討在 Microsoft Entra ID 中觸發大量物件變更的後端作業。 在您深入探討之前，請參閱 Microsoft Entra 連線 Sync 服務陰影屬性一文，以瞭解陰影屬性。
UserPrincipalName
針對僅限雲端的使用者，UserPrincipalName 會設定為已驗證的網域後綴。 處理不一致的 UserPrincipalName 時，作業會將它轉換成預設 onmicrosoft.com 後綴，例如： username@Contoso.onmicrosoft.com。
針對同步處理的使用者，UserPrincipalName 會設定為已驗證的網域後綴，並符合內部部署值 ShadowUserPrincipalName。 處理不一致的 UserPrincipalName 時，作業會還原為與 ShadowUserPrincipalName 相同的值，或者，如果網域後綴已從租用戶移除，請將它轉換成預設 *.onmicrosoft.com 網域後綴。
ProxyAddresses
針對僅限雲端的使用者，一致性表示 proxyAddresses 符合已驗證網域後綴。 處理不一致的 proxyAddresses 時，後端作業會將它轉換成預設 *.onmicrosoft.com 網域後綴，例如： SMTP:username@Contoso.onmicrosoft.com。
對於同步處理的使用者，一致性表示 proxyAddresses 符合內部部署 proxyAddresses 值（亦即 ShadowProxyAddresses）。 proxyAddresses 應該與 ShadowProxyAddresses 同步。 如果同步處理的使用者已指派 Exchange 授權，則雲端和內部部署值必須相符。 這些值也必須符合已驗證的定義域後綴。
在此案例中，後端作業會以未驗證的網域後綴來清理不一致的 proxyAddresses，並從 Microsoft Entra ID 中的 物件中移除。 如果稍後驗證該未驗證的網域，後端作業會重新計算，並將 ProxyAddresses 從 ShadowProxyAddresses 新增回 Microsoft Entra ID 中的物件。
注意
針對同步處理的物件，若要避免後端作業邏輯計算非預期的結果，最好將 proxyAddresses 設定為內部部署物件的 Microsoft Entra 已驗證網域。