Microsoft Entra Connect 同步：了解使用者、群組和連絡人
您可能有幾種不同的原因，而擁有多個 Active Directory 樹系並且具有幾種不同的部署拓撲。 常見的模型包括合併與收購之後的帳戶-資源部署與 GAL 同步處理的樹系。 雖然有單純的模型，但混合模型也同樣常見。 Microsoft Entra Connect Sync 中的預設組態不會假設任何特定模型。 不過，根據安裝指南中選擇的使用者比對方式不同，可能會觀察到不同的效果。
在本主題中，我們會詳細解說預設組態在某些拓撲中的運作方式。 我們會詳細解說組態，以及可用來查看組態的同步處理規則編輯器。
組態假設幾個一般規則：
- 無論我們以何種順序從來源 Active Directory 匯入，最後的結果應一律相同。
- 活躍的帳戶會提供登入資訊，包括 userPrincipalName 和 sourceAnchor。
- 如果找不到使用中的帳戶，除非帳戶是連結的信箱，否則停用的帳戶會提供 userPrincipalName 和 sourceAnchor。
- 具有連結信箱的帳戶永遠不會用於userPrincipalName和sourceAnchor。 它假設稍後就會找到使用中的帳戶。
- 連絡人物件可能會佈建到 Microsoft Entra ID 成為連絡人或使用者。 在所有來源 Active Directory 樹系處理完畢之前，您其實無法真正了解。
群組
注意
請記住，當您將使用者從另一個樹系新增至群組時，系統會在 Active Directory 中建立錨點，其中群組存在於特定 OU 內。 此錨點是外部安全性主體，並儲存在 OU‘ForeignSecurityPrincipals’中。 如果您不將此 OU 同步化，使用者就會被移出群組成員資格。
將 Active Directory 的群組同步至 Microsoft Entra ID 時應該注意的重點：
Microsoft Entra Connect 會將內建安全性群組從目錄同步作業中排除。
Microsoft Entra Connect 不支援將主要群組成員資格同步至 Microsoft Entra ID。
Microsoft Entra Connect 不支援將動態通訊群組成員資格同步至 Microsoft Entra ID。
若要將 Active Directory 群組同步至 Microsoft Entra ID 做為啟用電子郵件的群組：
如果群組的 proxyAddress 屬性是空的，其 mail 屬性必須有值
如果群組的 proxyAddress 屬性不是空的，則必須包含至少一個 SMTP Proxy 位址值。 以下列出一些範例：
proxyAddress 屬性值為 {"X500:/0=contoso.com/ou=users/cn=testgroup"} 的 Active Directory 群組在 Microsoft Entra ID 中不會擁有郵件功能。 它沒有 SMTP 位址。
proxyAddress 屬性值為 {"X500:/0=contoso.com/ou=users/cn=testgroup","SMTP:johndoe@contoso.com"} 的 Active Directory 群組在 Microsoft Entra ID 中會擁有郵件功能。
proxyAddress 屬性值為 {"X500:/0=contoso.com/ou=users/cn=testgroup", "smtp:johndoe@contoso.com"} 的 Active Directory 群組在 Microsoft Entra ID 中也會擁有郵件功能。
連絡人
在合併與收購時使用 GALSync 解決方案橋接兩個或多個 Exchange 樹系之後，常會有多個連絡人代表不同樹系中的某個使用者。 連絡人物件一律從連接器空間使用 mail 屬性加入 Metaverse。 如果已經有具相同郵件地址的連絡人物件或使用者物件，則物件會一起加入。 這是在規則 In from AD – Contact Join 中設定。 另外還有一個名為 In from AD - Contact Common 的規則，其屬性流程是使用常數 Contact 提供給 Metaverse 屬性 sourceObjectType。 此規則的優先順序較低，因此，如果有任何使用者對象聯結至相同的 Metaverse 物件，則規則 In from AD – User Common 將 User 值貢獻給此屬性。 使用此規則時，當沒有使用者加入時，此屬性的值為「聯絡人」；如果找到至少一位使用者，則值為「使用者」。
若要將物件布建至 Microsoft Entra ID，當 metaverse 屬性 sourceObjectType 設為 Contact時，輸出規則 Out to Microsoft Entra ID – Contact Join 會建立一個聯繫人物件。 如果此屬性設定為 User，則規則 Out to Microsoft Entra ID – User Join 將改為創建用戶物件。 當有多個來源 Active Directory 匯入並同步處理時，可以將物件從 Contact 升級為 User。
例如，在 GALSync 拓撲中，當我們匯入第一個樹系時，我們會在第二個樹系中找到每個人的連絡人物件。 這會在 Microsoft Entra 連接器中建立新的連絡人物件。 當我們之後匯入和同步處理第二個樹系時，我們會找到真正的使用者，並將他們加入現有的 Metaverse 物件。 然後，我們會刪除 Microsoft Entra ID 中的聯絡人，並改為建立新的使用者物件。
如果您有一個拓撲，其中使用者以連絡人代表，請確定您在安裝指南中選取根據 mail 屬性比對使用者。 如果您選取另一個選項，則您的組態就會與順序有關。 聯繫人物件一律會在郵件屬性上聯結，但如果已在安裝指南中選取此選項，則用戶物件只會聯結郵件屬性。 如果在匯入使用者物件之前先匯入連絡人物件，您在 Metaverse 中就會得到具有相同 mail 屬性的兩種不同物件。 匯出至 Microsoft Entra ID 期間顯示了一項錯誤。 這個行為是設計使然，指出數據不正確或無效，或者拓撲在安裝期間未正確識別。
已停用帳戶
停用的帳戶也同樣會同步處理到 Microsoft Entra ID。 停用的帳戶在 Exchange 中通常代表資源，例如會議室。 例外狀況是具有連結信箱的使用者；如先前所述，這類使用者從不會布建帳戶至Microsoft Entra ID。
假設如果找到已停用的用戶帳戶，我們稍後就不會找到另一個使用中的帳戶。 物件會配置到 Microsoft Entra 識別碼，其中找到了 userPrincipalName 和 sourceAnchor。 如果另一個使用中帳戶加入相同的 Metaverse 物件，則會使用其 userPrincipalName 和 sourceAnchor。
變更 sourceAnchor
當對象導出至 Microsoft Entra ID 時，就不能再變更 sourceAnchor。 導出物件時，metaverse 屬性 的 cloudSourceAnchor 會被設置為 Microsoft Entra ID 所接受的 sourceAnchor 值。 如果變更了 sourceAnchor 且不符合 cloudSourceAnchor，則規則 Out 到 Microsoft Entra ID – User Join 會拋出錯誤：sourceAnchor 屬性已變更 。 在此情況下，必須先更正組態或資料，讓 Metaverse 中再度具有相同的 sourceAnchor，才能再次同步處理物件。