共用方式為

轉換至雲端

  • 發行項

將組織調整為不再擴大 Active Directory 規模之後，您可以專注於將現有的內部部署工作負載移至 Microsoft Entra ID。 本文說明各種移轉工作流。 您可以根據優先順序和資源，執行本文中的工作流。

典型的移轉工作流具有下列階段：

  • 探索：找出您目前在環境中有什麼項目。

  • 試驗：視工作流而定，將新的雲端功能部署到一小部分的使用者、應用程式或裝置。

  • 擴增：擴大試驗以完成將功能轉移至雲端。

  • 完全移轉 (適用時)：停止使用舊的內部部署工作負載。

使用者和群組

啟用密碼自助式功能

我們建議無密碼環境。 屆時，您可以將密碼自助工作流從內部部署系統移轉至 Microsoft Entra ID，以簡化您的環境。 Microsoft Entra ID 自助式密碼重設 (SSPR) 可讓使用者直接變更或重設其密碼，而無需系統管理員或技術支援中心介入。

若要啟用自助式功能，請為您的組織選擇適當的驗證方法。 驗證方法更新後，您可以為 Microsoft Entra 驗證環境啟用使用者自助式密碼功能。 如需部屬指導，請參閱 Microsoft Entra 自助式密碼重設的部署考量。

其他考量包括：

注意

移動群組的管理

若要轉換群組和通訊群組清單：

將使用者和群組佈建移至應用程式

您可以從非內部部署身分識別管理 (IDM) 系統中 (例如 Microsoft Identity Manager) 移除應用程式佈建流程，以簡化環境。 根據應用程式探索，依下列特性將應用程式分類：

如需詳細資訊，請參閱為 Microsoft Entra ID 規劃自動使用者佈建部署。

移至雲端 HR 佈建

您可以將 HR 佈建工作流程從內部部署 IDM 系統 (例如 Microsoft Identity Manager) 移至 Microsoft Entra ID，以縮小內部部署規模。 Microsoft Entra 雲端 HR 佈建有兩種帳戶類型：

  • 如果新員工使用的應用程式只用到 Microsoft Entra ID，您可以選擇佈建「僅限雲端帳戶」。 此佈建有功於抑制 Active Directory 的規模。

  • 如果新員工需要存取相依於 Active Directory 的應用程式，您可以佈建「混合式帳戶」。

Microsoft Entra 雲端 HR 佈建也可以管理現有員工的 Active Directory 帳戶。 如需詳細資訊，請參閱規劃雲端 HR 應用程式至 Microsoft Entra 使用者佈建和規劃部署專案。

移動生命週期工作流程

評估您現有的加入者/移動者/離開者、工作流程和過程，以確保其適用性和相關性符合 Microsoft Entra 雲端環境。 然後，您可以使用生命週期工作流程來簡化這些工作流程，並建立新的工作流程。

移動外部身分識別管理

如果組織針對廠商、承包商、顧問等外部身分識別，在 Active Directory 或其他內部部署目錄中佈建帳戶，則您原本就可以在雲端管理這些第三方使用者物件，以簡化環境。 以下是一些可能性：

  • 針對新的外部使用者，請使用 Microsoft Entra 外部識別碼，以停止 Active Directory 使用者規模。

  • 針對您為外部身分識別佈建的現有 Active Directory 帳戶，您可以為企業對企業 (B2B) 共同作業設定本機認證 (例如密碼)，以免除管理本機認證的額外負荷。 請遵循邀請內部使用者加入 B2B 共同作業中的步驟。

  • 使用 Microsoft Entra 權利管理來授與對應用程式和資源的存取。 大部分公司都有此用途的專用系統和工作流程，但現在可以從內部部署工具中移出。

  • 使用存取權檢閱來移除不再需要的存取權限和/或外部身分識別。

裝置

移動非 Windows 工作站

您可以將非 Windows 工作站與 Microsoft Entra ID 整合，以增強使用者體驗，並受益於雲端式安全性功能，例如條件式存取。

取代工作站的其他 Windows 版本

如果您在工作站上有下列作業系統，請考慮升級至最新版本，以受益於雲端原生管理 (Microsoft Entra 加入和統一端點管理)：

  • Windows 7 或 8.x

  • Windows Server

VDI 解決方案

此專案有兩個主要計劃：

  • 新的部署：部署不需要內部部署 Active Directory 的雲端管理虛擬桌面基礎結構 (VDI) 解決方案，例如 Windows 365 或 Azure 虛擬桌面。

  • 現有部署：如果現有的 VDI 部署相依於 Active Directory，請使用商務目標來決定是否維護解決方案或移轉至 Microsoft Entra ID。

如需詳細資訊，請參閱

應用程式

為了協助維護安全的環境，Microsoft Entra ID 支援新式驗證通訊協定。 若要將應用程式驗證從 Active Directory 轉移至 Microsoft Entra ID，您必須：

  • 判斷哪些應用程式可以不經修改就移轉至 Microsoft Entra ID。

  • 判斷哪些應用程式有升級路徑可讓您隨升級一起移轉。

  • 判斷哪些應用程式需要更換或大幅變更程式碼才能移轉。

應用程式探索計劃的成果是建立優先順序清單以移轉應用程式組合。 此清單包含的應用程式：

  • 需要升級或更新軟體，而且有升級路徑。

  • 需要升級或更新軟體，但沒有升級路徑。

您可以使用此清單進一步評估沒有現有升級路徑的應用程式。 判斷商務價值是否保證更新軟體，或者是否應淘汰。 如果應該淘汰軟體，請決定是否需要更換。

根據結果，您可以重新設計從 Active Directory 轉換至 Microsoft Entra ID 的各方面。 如果應用程式使用不支援的驗證通訊協定，您可以使用一些方法將內部部署的 Active Directory 延伸至 Azure 基礎結構即服務 (IaaS) (隨即轉移)。 建議您設定原則來要求例外使用此方法。

應用程式探索

分割應用程式組合後，您可以根據商務價值和商務優先順序來排定移轉的優先順序。 您可以使用工具來建立或重新整理應用程式庫存。

應用程式主要有三種分類方式：

  • 新式驗證應用程式：這些應用程式使用新式驗證通訊協定 (例如 OIDC、OAuth2、SAML 或 WS-同盟)，或使用同盟服務，例如 Active Directory 同盟服務 (AD FS)。

  • Web 存取管理 (WAM) 工具：這些應用程式使用 SSO 的標頭、Cookie 和類似技術。 這些應用程式通常需要 WAM 識別提供者，例如 Symantec SiteMinder。

  • 舊版應用程式：這些應用程式使用舊版通訊協定，例如 Kerberos、LDAP、Radius、遠端桌面、NTLM (不建議)。

Microsoft Entra ID 可用於每一種應用程式，以提供各種層級的功能，因而形成不同的移轉策略、複雜度和取捨。 有些組織有應用程式庫存可作為探索基準。 (此庫存通常不完整或未更新。)

若要探索新式驗證應用程式：

下列工具可協助您探索使用 LDAP 的應用程式：

  • Event1644Reader：範例工具，針對向網域控制站提出的 LDAP 查詢，使用現場工程記錄來收集資料。

  • Microsoft 365 Defender for Identity：使用登入作業監視功能的安全性解決方案。 (請注意，這使用 LDAP 來擷取繫結，而不是使用安全 LDAP。)

  • PSLDAPQueryLogging：用於報告 LDAP 查詢的 GitHub 工具。

移轉 AD FS 或其他同盟服務

規劃移轉至 Microsoft Entra ID 時，不妨先移轉使用新式驗證通訊協定 (例如，SAML 和 OpenID Connect) 的應用程式。 您可以將這些應用程式重新設定為透過 Azure App 資源庫中的內建連接器，或透過在 Microsoft Entra ID 中註冊，以便向 Microsoft Entra ID 進行驗證。

將同盟的 SaaS 應用程式移至 Microsoft Entra ID 後，需要執行一些步驟來解除委任內部部署同盟系統：

重要

如果您使用其他功能，在解除委任 Active Directory 同盟服務之前，請先確認已重新放置這些服務。

移動 WAM 驗證應用程式

此專案專注於將 SSO 功能從 WAM 系統移轉至 Microsoft Entra ID。 若要深入了解，請參閱將應用程式從 Symantec SiteMinder 移轉至 Microsoft Entra ID。

定義應用程式伺服器管理策略

就基礎結構管理而言，內部部署環境通常使用群組原則物件 (GPO) 和 Microsoft Configuration Manager 功能組合來區隔管理職責。 例如，職責可以區隔為安全性原則管理、更新管理、組態管理和監視。

Active Directory 適用於內部部署 IT 環境，而 Microsoft Entra ID 適用於雲端式 IT 環境。 此處沒有一對一的功能同位，因此有幾種方式可以管理應用程式伺服器。

例如，當您使用 Microsoft Entra ID 來管理身分識別與存取 (IAM) 時，Azure Arc 有助於將 Active Directory 中的許多功能結合成單一檢視。 您也可以使用 Microsoft Entra Domain Services 將 Microsoft Entra ID 中的伺服器加入網域，特別是基於特定商務或技術原因而希望這些伺服器使用 GPO 時。

使用下表來決定可用來取代內部部署環境的 Azure 型工具：

管理區域 內部部署 (Active Directory) 功能 對等 Microsoft Entra 功能
安全性原則管理 GPO，Microsoft Configuration Manager Microsoft 365 Defender for Cloud
更新管理 Microsoft Configuration Manager、Windows Server Update Services Azure 自動化更新管理
設定管理 GPO，Microsoft Configuration Manager Azure 自動化狀態設定
監視 System Center Operations Manager Azure 監視器 Log Analytics

以下是可用於應用程式伺服器管理的詳細資訊：

如果您需要使用 Microsoft Endpoint Configuration Manager 來管理應用程式伺服器，則使用 Microsoft Entra Domain Services 無法達成此需求。 不支援在 Microsoft Entra Domain Services 環境中執行 Microsoft Configuration Manager。 相反地，您必須延伸內部部署的 Active Directory 執行個體至 Azure VM 上執行的網域控制站。 或者，您必須部署新的 Active Directory 執行個體到 Azure IaaS 虛擬網路。

定義繼承應用程式的移轉策略

繼承應用程式對 Active Directory 有如下相依性：

  • 使用者驗證和授權：Kerberos、NTLM、LDAP 繫結、ACL。

  • 存取目錄資料：LDAP 查詢、結構描述延伸模組、目錄物件的讀取/寫入。

  • 伺服器管理：由伺服器管理策略決定。

若要減少或消除這些相依性，主要有三種方法。

方法 1

以最可行的方法展開專案，從繼承應用程式移轉至使用新式驗證的 SaaS 替代方案。 讓 SaaS 替代方案直接向 Microsoft Entra ID 進行驗證：

  1. 將 Microsoft Entra Domain Services 部署至 Azure 虛擬網路，並擴充結構描述，以納入應用程式所需的其他屬性。

  2. 將舊版應用程式隨即轉移至 Azure 虛擬網路上已加入 Microsoft Entra Domain Services 網域的 VM。

  3. 使用 Microsoft Entra 應用程式 Proxy 或安全混合式存取合作夥伴，將繼承應用程式發佈至雲端。

  4. 隨著舊版應用程式經由消耗淘汰，最終會解除委任在 Azure 虛擬網路中執行的 Microsoft Entra Domain Services。

注意

方法 2

如果第一種方法不可能，而且應用程式非常依賴 Active Directory，您可以將內部部署的 Active Directory 延伸至 Azure IaaS。

您可以重建平台以支援新式無伺服器裝載，例如，使用平台即服務 (PaaS)。 或者，您可以更新程式碼以支援新式驗證。 您也可以讓應用程式直接與 Microsoft Entra ID 整合。 了解 Microsoft 身分識別平台的 Microsoft 驗證程式庫。

  1. 透過虛擬私人網路將 Azure 虛擬網路連線到內部部署網路 (VPN) 或 Azure ExpressRoute。

  2. 將內部部署的 Active Directory 執行個體的新網域控制站部署為 Azure 虛擬網路中的虛擬機器。

  3. 將繼承應用程式隨即轉移至 Azure 虛擬網路上已加入網域的 VM。

  4. 使用 Microsoft Entra 應用程式 Proxy 或安全混合式存取合作夥伴，將繼承應用程式發佈至雲端。

  5. 最終，解除委任內部部署的 Active Directory 基礎結構，完全在 Azure 虛擬網路中執行 Active Directory。

  6. 隨著舊版應用程式經由消耗淘汰，最終會解除委任在 Azure 虛擬網路中執行的 Active Directory 執行個體。

方法 3

如果第一種移轉不可能，而且應用程式非常依賴 Active Directory，您可以將新的 Active Directory 執行個體部署至 Azure IaaS。 在可預見的未來，將應用程式保留為繼承應用程式，或有機會就淘汰。

此方法可讓您將應用程式與現有的 Active Directory 分離，以縮小介面區。 建議將此方法當作最後手段。

  1. 將新的 Active Directory 執行個體部署為 Azure 虛擬網路中的虛擬機器。

  2. 將繼承應用程式隨即轉移至 Azure 虛擬網路上已加入新 Active Directory 執行個體網域的 VM。

  3. 使用 Microsoft Entra 應用程式 Proxy 或安全混合式存取合作夥伴，將繼承應用程式發佈至雲端。

  4. 隨著舊版應用程式經由消耗淘汰，最終會解除委任在 Azure 虛擬網路中執行的 Active Directory 執行個體。

策略比較

策略 Microsoft Entra 網域服務 將 Active Directory 延伸至 IaaS IaaS 中的獨立 Active Directory 執行個體
與內部部署的 Active Directory 分離 是 無 Yes
允許結構描述延伸模組 No .是 Yes
完整的系統管理控制權 No .是 Yes
可能需要重新設定應用程式 (例如 ACL 或授權) 是 無 Yes

移動 VPN 驗證

此專案著重於將 VPN 驗證移至 Microsoft Entra ID。 請務必知道 VPN 閘道連線有不同的組態可用。 您必須判斷哪一個設定最符合您的需求。 如需設計解決方案的詳細資訊，請參閱 VPN 閘道設計。

以下是使用 Microsoft Entra ID 進行 VPN 驗證的一些重點：

將遠端存取移至內部應用程式

若要簡化環境，您可以使用 Microsoft Entra 應用程式 Proxy 或安全混合式存取合作夥伴來提供遠端存取。 這可讓您移除內部部署反向 Proxy 解決方案的相依性。

必須說明，使用以上技術對應用程式啟用遠端存取只是暫時步驟。 您必須執行更多工作，才能完全分離應用程式與 Active Directory。

Microsoft Entra Domain Services 可讓您將應用程式伺服器移轉至雲端 IaaS 並與 Active Directory 分離，同時使用 Microsoft Entra 應用程式 Proxy 來啟用遠端存取。 若要深入了解此案例，請參閱部署 Microsoft Entra Domain Services 的 Microsoft Entra 應用程式 Proxy。

下一步