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 中設定。 AD 中也有一個名為 In 的規則 ： Contact Common，其屬性會流向 metaverse 屬性，sourceObjectType 常數 Contact。 此規則的優先順序較低，因此，如果有任何使用者對象聯結至相同的 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 時，物件可能會從聯絡人升階為使用者。
例如，在 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。
變更來源錨點
當對象導出至 Microsoft Entra ID 時，就不能再變更 sourceAnchor。 導出物件時，metaverse 屬性 cloudSourceAnchor 會被設置為 Microsoft Entra ID 所接受的 sourceAnchor 值。 如果變更了 sourceAnchor 並且沒有符合 cloudSourceAnchor，則規則 Out 到 Microsoft Entra ID – User Join 會拋出錯誤：sourceAnchor 屬性已更改。 在此情況下，必須先更正組態或資料，讓 Metaverse 中再度具有相同的 sourceAnchor，才能再次同步處理物件。