Microsoft Entra Connect：當您有現有的租用戶時
大多數有關如何使用 Microsoft Entra Connect 的主題假設您是從一個新的 Microsoft Entra 租用戶開始，且那裡沒有任何使用者或其他物件。 但是，如果您已開始使用 Microsoft Entra 租用戶，並且填充了使用者和其他物件，而現在想要使用 Connect，那麼本主題就適合您。
基本概念
Microsoft Entra 識別碼中的物件是在雲端或內部部署中管理。 針對單一物件，您無法在本地管理某些屬性，同時在Microsoft Entra ID中管理其他屬性。 每個物件都有一個旗標，指出物件在何處受管理。
您可以管理既有內部部署使用者，也可以管理雲端中的使用者。 此設定的常見案例是一個組織，其中混合了會計工作者和銷售人員。 會計工作者有內部部署 AD 帳戶，但銷售人員沒有，但兩者都有Microsoft Entra 標識碼中的帳戶。 您會在內部部署管理一些使用者，並在 Microsoft Entra ID 中管理一些使用者。
當您開始管理那些同時存在於內部部署的 Microsoft Entra ID 使用者時，您需要考慮一些額外的因素，並且稍後可能會想要使用 Microsoft Entra Connect。
與 Microsoft Entra 識別碼中的現有使用者同步
當您開始與 Microsoft Entra Connect 同步處理時，Microsoft Entra 服務 API 會檢查每個新的傳入物件，並嘗試尋找符合的現有物件。 此程式使用三個屬性：userPrincipalName、proxyAddresses和 sourceAnchor/immutableID。 userPrincipalName 或 proxyAddresses 的比對稱為「軟比對」。sourceAnchor 的比對被稱為「硬式比對」。針對 proxyAddresses 屬性，只會使用包含 SMTP：的值，也就是主要電子郵件地址，用於評估。
比對僅針對來自本地端 AD 的新物件進行評估。 如果您變更現有的物件，使其符合任一上述屬性，您將會看到錯誤。
如果Microsoft Entra ID 找到一個物件，其中屬性值與 Microsoft來自 entra Connect 的新傳入物件相同，則會接管 Microsoft Entra ID 中的物件，而先前的雲端管理物件會轉換成內部部署受控物件。 Microsoft Entra ID 中具有內部部署 AD 值的所有屬性都會以對應的內部部署值覆寫。
警告
由於Microsoft Entra ID 中的所有屬性都會由內部部署值覆寫，因此請確定您在內部部署中擁有良好的數據。 例如，如果您在 Microsoft 365 中只有受控電子郵件位址，且未在內部部署 AD DS 中保持更新，那麼 Microsoft Entra ID / Microsoft 365 中的任何資料若在 AD DS 中不存在，您將會遺失這些資料。
重要
如果您使用密碼雜湊同步，而 Express 安裝總是會啟用此功能，那麼來自內部部署的 Active Directory 的密碼雜湊將覆寫 Microsoft Entra ID 中的密碼雜湊。 如果您的使用者習慣於管理不同的密碼，那麼您需要告知他們應該使用內部部署 AD 密碼。
在規劃中必須考慮上一節和警告。 如果您在 Microsoft Entra ID 做了許多變更，而這些變更未在內部部署的 AD DS 中反映，為了防止數據遺失，您需要在使用 Microsoft Entra Connect 同步物件之前，先規劃如何將 Microsoft Entra ID 中的更新值匯入 AD DS。
如果您使用了軟性比對與對象匹配，則會將 sourceAnchor 新增到 Microsoft Entra 識別碼中的物件，以便稍後使用強制比對。
重要
Microsoft強烈建議不要將內部部署帳戶與Microsoft Entra ID中已存在的系統管理帳戶進行同步。
硬比對與軟比對
根據預設，物件的SourceAnchor值，例如 「abcdefghijklmnopqrstuv=」，是內部部署 Active Directory 物件中 mS-Ds-ConsistencyGUID 屬性的 Base64 字串表示法（或 ObjectGUID）。 此值會設定為 Microsoft Entra ID 中對應的 ImmutableId。
當 Microsoft Entra Connect 或 Cloud Sync 新增新物件時，Microsoft Entra ID 服務會嘗試以傳入物件的 sourceAnchor 值，匹配 Entra ID 中現有物件的 ImmutableId 屬性。 如果有相符專案，Microsoft Entra Connect 會接管該物件的來源或授權機構（SoA），並以 硬性匹配的方式更新傳入內部部署 Active Directory 物件的屬性。 當 Microsoft Entra ID 找不到任何符合 SourceAnchor 值的 ImmutableId 物件時，它會嘗試使用傳入物件的 userPrincipalName 或主要 SMTP 位址來尋找相符項目，這被稱為“軟匹配。”
硬比對和軟比對都嘗試將新的傳入物件（代表相同的內部部署實體）與已在 Microsoft Entra ID 中存在和管理的物件進行匹配。 如果 Microsoft Entra ID 無法為內送物件找到 硬比對 或 軟比對，它會在 Microsoft Entra ID 目錄中布建一個新物件。
如果 Microsoft Entra ID 能夠以主要 SMTP 位址為基礎，透過「軟比對」找到已存在的管理物件，但新內送的物件具有不同的 sourceAnchor 值，則在嘗試建立新物件時，這通常會導致衝突，使得 Microsoft Entra ID 無法創建該新物件。 發生此衝突的情況，例如：
在已同步至 Entra ID 的原始內部部署 AD 使用者上，
mS-Ds-ConsistencyGuid屬性中設定了不同的 sourceAnchor 值。已建立一個新的內部部署 AD 使用者，其 UPN 和主要 SMTP 位址與之前相同，但 sourceAnchor 和 SID 不同。
在這種情況下，Microsoft Entra Connect 或 Cloud Sync 中會發生 AttributeValueMustBeUnique 導出錯誤。根據傳入的使用者屬性，此錯誤可能會參考下列其中一個屬性衝突：
AttributeConflictName = OnPremiseSecurityIdentifier：新的傳入物件有不同的 sourceAnchor，但其 OnPremiseSecurityIdentifier（SID）和主要 SMTP 位址與 Entra ID 目錄中已存在的使用者相同。
AttributeConflictName = ProxyAddresses：新的進來的物件有不同的 sourceAnchor 和 SID，但與 Entra ID 目錄中存在的使用者具有相同的主 SMTP 位址。
注意
在某些罕見的情況下，可能會發生 OnPremiseSecurityIdentifier 衝突，這是因為內部部署的 AD RID 集區發生問題（例如，從備份復原的網域控制器），這會產生具有相同 SID 的新使用者。 在這種情況下，嘗試配置使用者時，會引發 AttributeValueMustBeUnique 錯誤，這不是因為“軟性匹配”嘗試，而是因為 Entra ID 目錄中的 OnPremiseSecurityIdentifier 必須是唯一的。
這些案例通常表示您嘗試重新配置相同的使用者。 若要解決衝突，您應該更新內部部署使用者的 mS-Ds-ConsistencyGuid 屬性，以符合與現有雲端使用者的 ImmutableID 相同的值。 這項變更可讓 Microsoft Entra ID 進行精確的「硬式匹配」。
封鎖Microsoft Entra標識符中的硬式比對
我們已新增組態選項，以停用 Microsoft Entra ID 中的硬式比對功能。 我們建議客戶停用嚴格匹配功能，除非客戶需要用它來接管僅限於雲端的帳戶。
若要停用強制比對，請使用 Update-MgDirectoryOnPremiseSynchronization Microsoft Graph PowerShell cmdlet：
Connect-MgGraph -Scopes "OnPremDirectorySynchronization.ReadWrite.All"
$OnPremSync = Get-MgDirectoryOnPremiseSynchronization
$OnPremSync.Features.BlockCloudObjectTakeoverThroughHardMatchEnabled = $true
Update-MgDirectoryOnPremiseSynchronization `
-OnPremisesDirectorySynchronizationId $OnPremSync.Id `
-Features $OnPremSync.Features
阻止 Microsoft Entra ID 中的軟性匹配
同樣地，我們新增了組態選項，以停用 Microsoft Entra ID 中的軟體比對選項。 我們建議客戶停用軟比對，除非客戶需要它接管僅限雲端的帳戶。
若要停用軟性比對，請使用 Update-MgDirectoryOnPremiseSynchronization Microsoft Graph PowerShell cmdlet：
Connect-MgGraph -Scopes "OnPremDirectorySynchronization.ReadWrite.All"
$OnPremSync = Get-MgDirectoryOnPremiseSynchronization
$OnPremSync.Features.BlockSoftMatchEnabled = $true
Update-MgDirectoryOnPremiseSynchronization `
-OnPremisesDirectorySynchronizationId $OnPremSync.Id `
-Features $OnPremSync.Features
注意
如果針對租用戶啟用了 BlockCloudObjectTakeoverThroughHardMatchEnabled 和 BlockSoftMatchEnabled 這兩個功能，則會封鎖所有物件的比對。 在租戶需要比對程序的期間，建議客戶僅在此時停用這些功能。 此旗標應該在所有匹配完成且不再需要後，重新設定為 True。
使用者以外的其他物件
針對已啟用郵件的群組和聯繫人，您可以根據 proxyAddresses 進行模糊比對。 在此情況下不適用完全匹配，因為您只能在使用者上更改 sourceAnchor/immutableID（使用 PowerShell）。 對於不具備郵件功能的群組，目前不支持軟匹配或硬匹配。
管理員角色考量
為了防止來自未受信任的內部部署使用者的風險，Microsoft Entra ID 不會將其與具有系統管理員角色的雲端使用者進行配對。 此行為預設為 。 若要解決此問題，您可以執行下列步驟：
從僅限雲端的用戶物件中移除目錄角色。
將在雲端中建立的新隔離物件永久刪除。
觸發新的同步處理週期。
選擇性地，在比對完成後，將目錄角色新增回雲端中的用戶物件。
從 Microsoft Entra 識別碼中的數據建立新的內部部署 Active Directory
有些客戶從具有 Microsoft Entra ID 的僅限雲端解決方案開始，而且他們沒有內部部署 AD。 稍後，他們想取用內部部署資源，並想要根據 Microsoft Entra 數據建置內部部署 AD。 Microsoft Entra Connect 無法協助您處理此案例。 它不會在內部部署建立使用者，而且無法將內部部署密碼設定為與 Microsoft Entra ID 中的相同。
如果您打算新增內部部署 AD 的唯一原因是支援 LOB（企業營運應用程式），則也許您應該考慮改用 Microsoft Entra Domain Services。