瞭解已驗證網域變更期間的大量使用者更新
本文說明稽核記錄顯示已驗證網域變更所觸發的許多 UserPrincipalName 更新的常見案例。 本文說明稽核記錄中在已驗證網域變更期間發生 UserManagement 更新的原因和考量。 本文深入探討可觸發 Microsoft Entra ID 中大量物件變更的後端作業。
徵兆
Microsoft Entra 稽核記錄顯示我的 Microsoft Entra 租用戶中發生的多個使用者更新。 這些事件的「執行者」資訊是空的或顯示 N/A。
大量更新涉及變更針對 UserPrincipalName 已從組織慣用網域變更為預設 *.onmicrosoft.com 網域尾碼的網域。
範例稽核記錄詳細資料
活動日期 (UTC)：2022-01-27 07:44:05
活動：更新使用者
執行者類型：其他
執行者 UPN：N/A
狀態：成功
類別：UserManagement
服務：核心目錄
目標識別碼：aaaaaaaaa-bbbb-0000-11111-bbbbbbbbbbbbb
目標名稱：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 稽核記錄中，此事件會擷取為 [更新使用者] 事件，而且前面有 [新增已驗證網域] 事件。
如果已從 Contoso.onmicrosoft.com 租用戶中移除 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 同步處理服務陰影屬性文章以瞭解陰影屬性。
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 已驗證網域。