平行和合併的身分識別基礎結構選項- Microsoft Entra

多重雲端和多重組織身分識別的案例

合併和收購（M&A） - 是指通常公司 A 購買公司 B 的情況。

品牌重塑：公司名稱或品牌變更，通常會包含電子郵件網域名稱的變更。

Microsoft Entra ID 或 Office 365 租用戶合併 - 具有多個 Office 365 租使用者的公司可能會因為合規性或歷史需求而想要合併。

Active Directory 網域或樹系合併 - 正在評估執行 Active Directory 網域或樹系合併的公司。

分化 – 公司的部門或業務群組被出售或成為獨立的地方。

使用者信息隱私權 – 公司需要讓特定數據（屬性）無法公開顯示，且只有正確的委派群組或使用者可以讀取、變更及更新數據。

源自這些情境的需求

藉由建立中央或 通用目錄 ，將所有使用者和群組的數據帶入單一位置，包括會議排程的電子郵件和狀態可用性。

藉由實作單一登錄，維護 單一使用者名稱和認證 ，同時減少跨所有應用程式輸入使用者名稱和密碼的需求。

簡化用戶上線，使其不需要數周或數月的時間。

為未來的併購和存取管理需求做好準備。

啟用和改善跨公司共同作業和生產力。

使用集中且一致地部署安全策略，降低安全性缺口或數據外洩的可能性！

本文未涵蓋的案例

部分併購。例如，組織會購買另一個組織的一部分。

剝離或分割組織

重新命名組織。

合資企業或臨時合作夥伴

本文概述各種多重雲端或多組織身分識別環境，包括Microsoft支援的 M&A 案例，並概述組織如何根據組織如何進行匯總來選取正確的技術。

假設併購案例的整合方案

下列各節涵蓋假設 M&A 案例的四個主要案例：

假設 Contoso 是企業客戶，且其 IT 擁有單一（內部部署）HR 系統、單一 Active Directory 樹系、單一租戶的 Microsoft Entra ID 用於其應用程式，運行如預期。使用者會從其 HR 系統帶入 Active Directory，並投影到 Microsoft Entra ID，然後從該處帶入 SaaS 應用程式。下圖說明此案例，其中箭號顯示身分識別資訊的流程。相同的模型也適用於雲端 HR 系統的客戶，例如 Workday 或 SuccessFactors 布建 Active Directory，而不只是使用 Microsoft Identity Manager （MIM）的客戶。

接下來，Contoso 已開始與 Litware 進行合併，而 Litware 之前一直獨立運行他們自己的 IT。 Contoso IT 將處理合併，並預期 Contoso 的 IT 會繼續讓 Contoso 的應用程式保持不變，但他們想要讓 Litware 的用戶能夠存取這些應用程式，並在這些應用程式中共同作業。對於Microsoft應用程式、第三方 SaaS 和自定義應用程式，最終狀態應該是 Contoso 和 Litware 使用者概念上可以存取相同的數據。

第一個IT決策是想要結合基礎結構多少。他們可以選擇不依賴任何 Litware 的身分識別基礎結構。或者，他們可以考慮使用 Litware 的基礎設施，並逐步整合，同時將對 Litware 環境的干擾降到最低。在某些情況下，客戶可能會想要讓 Litware 的現有身分識別基礎結構保持獨立，而不會將其聚合，同時仍使用它來為 Litware 員工提供 Contoso 應用程式的存取權。

如果客戶選擇保留部分或全部的 Litware 身分識別基礎結構，則在多大程度上使用 Litware 的 Active Directory Domain Services 或 Microsoft Entra ID 以使 Litware 的使用者能夠存取 Contoso 資源時，會產生不同的權衡。本節會基於 Contoso 為 Litware 使用者選擇的方案來探討可行的選項：

案例 A - 請勿使用任何 Litware 的身分識別基礎結構。

情境 B - 使用 Litware 的 Active Directory 樹系，但不使用 Litware 的 Microsoft Entra ID（如果他們有的話）

案例 C - 使用 Litware 的 Microsoft Entra 標識碼。

案例 D - 使用 Litware 的非Microsoft身分識別基礎結構（如果 Litware 未使用 Active Directory /Microsoft Entra ID）

下表概述每個選項，包含客戶可用來達成這些結果的技術、限制以及每個選項的優點。

A1：單一 HR、單一 IAM 和租戶 A2：個別 HR、單一 IAM 和租戶 B3：Active Directory 樹系信任、單一Microsoft Entra Connect B4：Microsoft Entra 將其 Active Directory 連線到單一租戶 B5：Microsoft Entra Connect 將他們的 Active Directory 進行雲端同步 C6：將多個租戶平行配置至應用程式 C7：從其租用戶中讀取資料，B2B 將邀請其使用者 C8：根據需要單一化 IAM 和 B2B 使用者 D9：DF 及其使用的非 Azure AD IDP

隱私權和數據功能會顯示解決方案是否允許支援地理位置和數據界限。

隔離會顯示此解決方案是否提供分隔或委派系統管理員模型的能力。

共同作業功能顯示解決方案所支援的共同作業層級，更整合的解決方案可提供更高的團隊合作精確度。

IT 系統管理員模型會顯示系統管理模型是否需要集中式或可分散。

限制：任何值得列出的挑戰問題。

使用下列判定樹來協助您決定哪一個案例最適合您的組織。

本文件的其餘部分將概述 A-D 的四個案例，其中包含各種支持它們的選項。

案例 A - 如果 Contoso 不想依賴 Litware 的現有身分識別基礎結構

針對此選項，Litware 可能沒有任何身分識別系統（例如小型企業），或客戶可能想要關閉 Litware 的基礎結構。或者，他們希望保留 Litware 員工的驗證方式不變，讓他們繼續使用 Litware 的應用程式進行驗證，同時為 Litware 員工提供 Contoso 的新身分。例如，如果 Alice Smith 是 Litware 員工，她可能有兩個身分識別 – Alice@litware.com 和 ASmith123@contoso.com。這些身份與彼此完全不同。

選項 1 - 結合成單一 HR 系統

一般而言，客戶會將 Litware 員工帶入 Contoso HR 系統。此選項會觸發這些員工取得帳戶及 Contoso 目錄和應用程式的正確存取權限。 Litware 使用者接著會擁有新的 Contoso 身分識別，其可用來要求存取正確的 Contoso 應用程式。

選項 2 - 保留 Litware HR 系統

有時可能不可能聚合 HR 系統，至少短期內也不可能。相反地，客戶會將他們的佈建系統連接起來，例如 MIM，去從 這兩個 HR 系統中讀取資料。在此圖中，頂端 HR 是現有的 Contoso 環境，而第二個 HR 則是 Litware 新增整體基礎結構。

相同的情境也可以使用 Microsoft Entra Workday 或 SuccessFactors 匯入，Contoso 可以從 Litware Workday HR 來源引進使用者，並合併現有的 Contoso 員工。

合併所有身分識別基礎結構的結果

減少 IT 基礎結構，只管理一個身分識別系統，除了 HR 系統之外，沒有網路連線需求。

一致的終端使用者和系統管理體驗

合併所有身分識別基礎結構的條件約束

源自 Litware 的 Contoso 員工所需的任何數據，都必須移轉至 Contoso 環境。

Contoso 需要的任何來自 Litware 的 Active Directory 或 Microsoft Entra 整合式應用程式，都必須重新設定為 Contoso 環境。此重新設定可能需要變更組態，用於存取的群組，或可能需要對應用程式本身進行更改。

案例 B - 如果 Contoso 想要保留 Litware 的 Active Directory 樹系，但不要使用 Litware 的 Microsoft Entra 標識符

Litware 可能有許多現有的 Active Directory 型應用程式，因此 Contoso 可能想要繼續讓 Litware 員工在現有的 AD 中保留自己的身分識別。 Litware 員工接著會使用其現有的身分識別來驗證其現有資源和 Contoso 資源。在此案例中，Litware 在 Microsoft Online Services 中沒有任何雲端身分識別 – Litware 不是 Microsoft Entra 客戶，任何 Litware 的雲端資產都不會與 Contoso 共用，或 Contoso 將 Litware 的雲端資產移轉至 Contoso 租使用者的一部分。

選項 3 - 與已取得森林的森林信託

使用 Active Directory 樹系信任，Contoso 和 Litware 可以連線其 Active Directory 網域。此信任可讓 Litware 用戶驗證 Contoso 的 Active Directory 整合應用程式。此外，Microsoft Entra Connect 也可以從 Litware 的 Active Directory 樹系讀取，讓 Litware 使用者向 Contoso 的 Microsoft Entra 整合式應用程式進行驗證。此部署拓撲要求在兩個網域之間設定網路路由，並確保任何 Litware 使用者與 Contoso Active Directory 整合的應用程式之間的 TCP/IP 網路連線。設定雙向信任也很簡單，讓 Contoso 使用者可以存取 Litware AD 整合應用程式（如果有的話）。

建立森林信託的結果

所有 Litware 員工都可以驗證 Contoso 的 Active Directory 或 Microsoft Entra 整合式應用程式，而 Contoso 可以使用目前的 AD 型工具來管理授權。

設定森林信任的限制

需要在已加入某個樹系的使用者與已加入另一個樹系的資源之間具備 TCP/IP 連線能力。

需要 Contoso 樹系中的 Active Directory 型應用程式具備多重樹系感知

選項 4 - 設定 Microsoft Entra Connect 至未信任樹系的已取得樹系

客戶也可以將 Microsoft Entra Connect 設定為從另一個樹系讀取。此設定可讓 Litware 使用者向 Contoso 的 Microsoft Entra 整合應用程式進行驗證，但無法將 Contoso 的 Active Directory 整合應用程式存取權提供給 Litware 使用者 – 這些 Contoso 應用程式無法辨識 Litware 使用者。此部署拓撲需要Microsoft Entra Connect 與 Litware 域控制器之間的 TCP/IP 網路連線。例如，如果 Microsoft Entra Connect 位於 Contoso IaaS VM 上，他們也必須建立通道給 Litware 的網路。

使用 Microsoft Entra Connect 佈建單一租用戶的限制

Contoso Microsoft Entra Connect 與 Litware 的 Active Directory 網域之間需要 TCP/IP 連線。

不允許 Litware 使用者存取 Contoso 的 Active Directory 應用程式

選項 5 - 在新取得的樹系中部署 Microsoft Entra Connect 雲端同步

Microsoft Entra Connect 雲端布建可以移除網路連線需求，但在 Microsoft Entra ID 的雲端同步處理中，每位使用者只能有一個 Active Directory 連結。Litware 使用者可以認證 Contoso 的 Microsoft Entra 整合應用程式，但是無法對 Contoso 的 Active Directory 整合應用程式進行認證。此拓撲不需要 Litware 與 Contoso 內部部署環境之間的任何 TCP/IP 連線。

在取得的樹系中部署Microsoft Entra Connect 雲端同步的結果

所有 Litware 員工都可以驗證 Contoso Microsoft Entra 整合式應用程式。

在取得的樹系中使用 Microsoft Entra Connect 雲端同步的條件約束

不允許 Litware 使用者存取 Contoso 的 AD 型應用程式

案例 C - 如果 Contoso 想要保留 Litware 的 Microsoft Entra 識別符

Litware 可能是 Microsoft Online Services 或 Azure 客戶，或可能有一或多個依賴的 Entra ID 應用程式。因此，Contoso 可能會想要繼續讓 Litware 員工保留自己的身分識別，以存取這些資源。 Litware 員工接著會使用其現有的身分識別來驗證其現有資源和 Contoso 資源。

此案例適用於下列情況：

Litware 在 Azure 或 Microsoft Online Services 擁有廣泛的投資項目，包括多個 Office 365 訂閱租戶，因為其成本昂貴或耗時，使移轉至其他租戶變得困難。

Litware 可能將來會被分拆出來，或作為一個將獨立運作的合夥企業。

Litware 沒有內部部署基礎結構

選項 6 - 在每個 Microsoft Entra ID 中維持應用程式的平行布建和 SSO

其中一個選項是讓每個Microsoft Entra ID 獨立提供 SSO，並將使用者從目錄配置到目標應用程式。例如，如果 Contoso IT 使用 Salesforce 之類的應用程式，他們會提供 Litware 系統管理許可權，以在相同的 Salesforce 訂用帳戶中建立使用者。

如果使用同盟，則需要應用程式支援相同訂用帳戶的多個同盟提供者。

無法套用於 Microsoft 應用程式，如 Office 或 Azure

Contoso 無法在 Microsoft Entra ID 看見 Litware 使用者的應用程式存取權限。

選項 7 - 為來自已併購租戶的使用者設定 B2B 帳戶

如果 Litware 一直在運行自己的租戶，那麼 Contoso 可以從該租戶讀取使用者，並透過 B2B API 邀請這些使用者加入 Contoso 租戶。（例如，此大量邀請程式可以透過 MIM 圖形連接器來完成。如果 Contoso 也有想要提供給 Litware 使用者的 AD 型應用程式，則 MIM 也可以在 Active Directory 中建立使用者，以對應至 Microsoft Entra 使用者的 UPN，讓應用程式 Proxy 可以代表 Contoso Active Directory 中 Litware 使用者的表示方式執行 KCD。

然後，當 Litware 員工想要存取 Contoso 應用程式時，他們可以藉由向自己的目錄進行驗證，並由資源租戶分配存取權。

Litware 使用者可以向 Contoso 應用程式進行驗證，而 Contoso 可控制其租使用者中的存取權。

Litware 和 Contoso 具有統一的 GAL。

對 Litware 的 Active Directory 或 Microsoft Entra 識別碼沒有變更

從一般 HR 系統供應來源設定 B2B 來賓用戶的限制

需要變更 Contoso 的布建，將用戶傳送至 Litware 的 Active Directory，並建立 Litware 網域與 Contoso 網域之間的連線。

要求應用程式具備 B2B 的 SSO 功能。

案例 D - 如果 Litware 使用非 Active Directory 基礎結構

最後，如果 Litware 使用內部部署或雲端中的另一個目錄服務，Contoso IT 仍然可以設定 Litware 員工進行驗證，而且可以使用現有的身分識別來存取 Contoso 的資源。

選項 9 - 使用 B2B 直接同盟（公開預覽）

在此案例中，假設 Litware 具有：

某些現有的目錄，例如 OpenLDAP，甚至是包含電子郵件地址的 SQL 資料庫或一般使用者檔案，可以與 Contoso 定期共享。

支援SAML的識別提供者，例如 PingFederate 或OKTA。

公開路由的 DNS 網域，例如 Litware.com，以及在該網域中具有電子郵件地址的使用者

在此方法中，Contoso 會設定其租戶與 Litware 身分識別提供者之間的直接同盟關聯，然後定期從其目錄系統中讀取 Litware 使用者的更新，以將 Litware 的使用者邀請到 Contoso 的 Microsoft Entra 帳戶。此更新可以使用 MIM Graph 連接器來完成。如果 Contoso 也有想要提供給 Litware 使用者的 Active Directory 型應用程式，則 MIM 也可以在 Active Directory 中建立使用者，以對應至 Microsoft Entra 使用者的 UPN，讓應用程式 Proxy 可以代表 Contoso Active Directory 中 Litware 使用者的表示方式執行 KCD。

使用 B2B 直接同盟的結果

Litware 使用者使用他們的現有身分識別提供者向 Contoso 的 Microsoft Entra ID 進行身分驗證，以存取 Contoso 的雲端及內部部署的 Web 應用程式。

使用 B2B 直接聯盟的約束條件

需要 Contoso 應用程式支援 B2B 使用者的 SSO 功能。

什麼是 Microsoft Entra Connect 雲端同步設定 Microsoft Entra ID 的輸入佈建設定 B2B 直接同盟多租戶使用者管理選項什麼是應用程式佈建？