Microsoft Entra Connect 同步：了解使用者、群組和連絡人
您有多個 Active Directory 樹系的原因有很多，而且有數個不同的部署拓撲。 常見模型包括合併和收購後帳戶資源部署和 GAL 同步處理樹系。 但是，即使有純模型，混合式模型也是常見的。 Microsoft Entra 連線 Sync 中的預設設定不會假設任何特定模型，但視安裝指南中選取使用者比對的方式而定，可以觀察到不同的行為。
在本主題中，我們會逐步解說預設組態在特定拓撲中的運作方式。 我們會進行設定，並使用同步處理規則編輯器來查看設定。
設定假設有一些一般規則：
- 無論我們從來源 Active Directory 匯入的順序為何，最終結果應該一律相同。
- 使用中的帳戶一律會提供登入資訊，包括 userPrincipalName 和 sourceAnchor。
- 停用的帳戶會參與 userPrincipalName 和 sourceAnchor，除非它是連結的信箱，否則找不到作用中的帳戶。
- 具有連結信箱的帳戶永遠不會用於userPrincipalName和sourceAnchor。 假設稍後會找到作用中的帳戶。
- 聯繫人物件可能會以聯繫人或使用者身分佈建至 Microsoft Entra ID。 在處理所有來源 Active Directory 樹系之前，您才真正知道。
群組
注意
請記住，當您將使用者從另一個樹系新增至群組時，會在 Active Directory 中建立錨點，其中群組存在於特定 OU 內。 此錨點是外部安全性主體，並儲存在 OU 'ForeignSecurityPrincipals' 內。 如果您未同步處理此 OU，則會從群組成員資格中移除的使用者。
將群組從 Active Directory 同步處理至 Microsoft Entra 識別符時要注意的重要事項：
Microsoft Entra Connect 會將內建安全性群組從目錄同步作業中排除。
Microsoft Entra 連線 不支援將主要群組成員資格同步處理至 Microsoft Entra ID。
Microsoft Entra 連線 不支援將動態通訊群組成員資格同步處理至 Microsoft Entra 識別符。
若要將 Active Directory 群組同步處理至 Microsoft Entra ID 做為已啟用郵件的群組：
如果群組的 proxyAddress 屬性是空的，其郵件屬性必須有值
如果群組的 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”的 Active Directory 群組，“smtp：johndoe@contoso.com”} 也會在 Microsoft Entra ID 中啟用郵件功能。
連絡人
在合併與收購之後，代表不同樹系中用戶的聯繫人很常見，其中 GALSync 解決方案會橋接兩個或多個 Exchange 樹系。 連絡人物件一律從連接器空間使用 mail 屬性加入 Metaverse。 如果已經有具相同郵件地址的連絡人物件或使用者物件，則物件會一起加入。 這是在規則 In from AD – Contact Join 中設定。 也有一個名為 In 的規則 從 AD – 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 連線 or 中分階段新的聯繫人物件。 當我們稍後匯入並同步處理第二個樹系時，我們會找到真正的使用者，並將它們加入現有的Metaverse物件。 然後，我們會刪除 Microsoft Entra ID 中的聯繫人物件，並改為建立新的用戶物件。
如果您有一個拓撲，其中使用者以連絡人代表，請確定您在安裝指南中選取根據 mail 屬性比對使用者。 如果您選取另一個選項，則您有訂單相依的組態。 連絡人物件永遠會跟隨著 mail 屬性，但如果在安裝指南中選取了此選項，使用者物件就只會跟隨著 mail 屬性。 如果在匯入使用者物件之前先匯入連絡人物件，您在 Metaverse 中就會得到具有相同 mail 屬性的兩種不同物件。 匯出至 Microsoft Entra 識別碼期間，會顯示錯誤。 此行為是刻意設計，這樣會指出資料有錯誤，或者在安裝期間未正確識別拓撲。
已停用帳戶
已停用的帳戶也會同步處理至 Microsoft Entra ID。 停用的帳戶通常代表 Exchange 中的資源，例如會議室。 例外狀況是具有連結信箱的使用者;如先前所述，這些帳戶永遠不會布建至 Microsoft Entra ID。
假設如果找到停用的用戶帳戶，則稍後我們找不到另一個使用中的帳戶，而且物件會布建至 Microsoft Entra ID，且找到 userPrincipalName 和 sourceAnchor。 如果另一個使用中帳戶加入相同的 Metaverse 物件，則會使用其 userPrincipalName 和 sourceAnchor。
變更sourceAnchor
當對象匯出至 Microsoft Entra 識別符時，就不能再變更 sourceAnchor。 導出物件時，metaverse 屬性 cloudSourceAnchor 會以 Microsoft Entra ID 所接受的 sourceAnchor 值進行設定。 如果 sourceAnchor 已變更且不符合 cloudSourceAnchor，規則 Out to Microsoft Entra ID – User Join 將會擲回錯誤 sourceAnchor 属性已變更。 在此情況下，必須更正組態或數據，讓相同的 sourceAnchor 再次存在於 Metaverse 中，然後才能再次同步處理物件。