共用方式為

Microsoft Entra Connect 同步：了解使用者、群組和連絡人

  • 發行項

您可能有幾種不同的原因，而擁有多個 Active Directory 樹系並且具有幾種不同的部署拓撲。 常見的模型包括合併與收購之後的帳戶-資源部署與 GAL 同步處理的樹系。 雖然有單純的模型，但混合模型也同樣常見。 Microsoft Entra Connect 同步處理中的預設組態不會採用任何特定的模型，但是根據在安裝指南中選取使用者比對的方式，可以觀察到不同的行為。

在本主題中，我們會詳細解說預設組態在某些拓撲中的運作方式。 我們會詳細解說組態，以及可用來查看組態的同步處理規則編輯器。

組態假設幾個一般規則：

  • 無論我們以何種順序從來源 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 值給這個屬性。 有了這項規則，如果沒有使用者加入，此屬性的值就會是 Contact，如果至少找到了一個使用者，則屬性的值就會是 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 屬性比對使用者。 如果您選取另一個選項，則您的組態就會與順序有關。 連絡人物件永遠會跟隨著 mail 屬性，但如果在安裝指南中選取了此選項，使用者物件就只會跟隨著 mail 屬性。 如果在匯入使用者物件之前先匯入連絡人物件，您在 Metaverse 中就會得到具有相同 mail 屬性的兩種不同物件。 匯出至 Microsoft Entra ID 期間顯示了一項錯誤。 此行為是刻意設計，這樣會指出資料有錯誤，或者在安裝期間未正確識別拓撲。

已停用帳戶

停用的帳戶也同樣會同步處理到 Microsoft Entra ID。 停用的帳戶在 Exchange 中通常代表資源，例如會議室。 例外狀況是具有連結信箱的使用者。如先前所述，這些使用者將永遠不會佈建帳戶到 Microsoft Entra ID。

這個假設是，如果找到停用的使用者帳戶，我們之後就不會找到另一個使用中的帳戶，而物件會使用找到的 userPrincipalName 和 sourceAnchor 佈建到 Microsoft Entra ID。 如果有另一個使用中的帳戶加入相同的 Metaverse 物件，則會使用其 userPrincipalName 和 sourceAnchor。

變更 sourceAnchor

當物件匯出到 Microsoft Entra ID 之後，則不允許再變更 sourceAnchor。 當物件匯出之後，Metaverse 屬性 cloudSourceAnchor 就會設為 Microsoft Entra ID 所接受的 sourceAnchor 值。 如果 sourceAnchor 已變更且不符合 cloudSourceAnchor，規則 Out to Microsoft Entra ID - User Join 將會擲回 sourceAnchor 屬性已經變更的錯誤。 在此情況下，必須先更正組態或資料，讓 Metaverse 中再度具有相同的 sourceAnchor，才能再次同步處理物件。

其他資源