本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
遷移 Active Directory
Active Directory 為適用於許多企業環境的一般身分識別與存取管理解決方案。DNS、使用者及機器管理的結合使得 Active Directory 成為集中式使用者驗證之 Microsoft 和 Linux 工作負載的理想選擇。當您規劃遷移至雲端或 AWS 的旅程時，會面臨到將 Active Directory 延伸至 AWS 或使用受管服務卸載目錄服務基礎架構之管理的選擇。建議您在決定適合組織的方法時，了解每個選項的風險和優點。
適用於 Active Directory 遷移的策略可符合組織需求，且可讓您利用 AWS 雲端。此策略不僅涉及考量目錄服務本身，也必須考量服務與其他 AWS 服務的互動方式。此外，您必須考量管理 Active Directory 之團隊的長期目標。
除 Active Directory 遷移外，您也必須決定 Active Directory 所在位置的帳戶結構、AWS 帳戶的網路拓撲，以及您計劃使用之需要 Active Directory 的 DNS 整合和其他潛在 AWS 服務。如需有關設計帳戶拓撲和其他遷移策略考量的資訊，請參閱本指南的基礎最佳實務一節。
評估
若要實作成功的遷移，請務必評估您現有的基礎架構，並瞭解環境所需的主要功能。建議您在選擇遷移方式之前，檢閱下列區域：
-
檢閱現有的 AWS 基礎架構設計：如果您仍未了解基礎架構的用量與需求，請按照本指南之 Windows 環境探索一節的指引，並使用評估方法協助檢閱現有的 Active Directory 基礎架構。建議您在 AWS 中針對 Active Directory 基礎架構使用 Microsoft 指定的大小。如果您要將 Active Directory 基礎架構延伸至 AWS，可能只需要 AWS 中部分 Active Directory 驗證用量。因此，除非您將 Active Directory 用量完全移動至 AWS，否則請避免過度擴展環境大小。如需詳細資訊，請參閱 Microsoft 文件中的 Active Directory Domain Services 的容量規劃
。 -
檢閱現有的內部部署 Active Directory 設計：檢閱內部部署 (自我管理) Active Directory 的目前使用率。如果您要將 Active Directory 環境延伸至 AWS，建議您在 AWS 的多個網域控制器中執行 Active Directory (即使延伸至內部部署環境也是如此)。此方式遵循 AWS Well-Architected Framework
，透過在多個可用區域中部署執行個體，以針對潛在失敗進行設計。 -
識別應用程式和聯網中的相依性：在選擇最佳的遷移策略之前，您必須完全了解組織在功能方面所需的所有 Active Directory 功能。如此表示選擇託管服務或自我託管時，必須了解每個服務的選項。決定適合您的遷移時，請考量下列項目：
-
存取需求：存取控制 Active Directory 的需求將會決定適合您的遷移路徑。如果您需要完整存取 Active Directory 網域控制器，來安裝任何類型的代理程式以遵循合規法規，則 AWS Managed Microsoft AD 可能不是適合您的解決方案。相反地，請在 AWS 帳戶內調查從網域控制器至 Amazon EC2 的 Active Directory 擴展。
-
遷移時間軸：如果您延長遷移時間軸，但沒有明確的完成日期，請確認您具有採取緊急應變措施可在雲端和內部部署環境中管理執行個體。驗證為 Microsoft 工作負載用於避免管理問題的重要元件。建議您在遷移初期規劃移動 Active Directory。
-
-
備份策略：如果您使用現有的 Windows 備份來擷取 Active Directory 網域控制器的系統狀態，則可以繼續在 AWS 中使用現有的備份策略。此外，AWS 也提供技術選項，可協助您備份執行個體。例如，AWS Data Lifecycle Manager、AWS Backup
及 AWS Elastic Disaster Recovery 皆為備份 Active Directory 網域控制器的支援技術。若要避免發生問題，請勿仰賴還原 Active Directory。建議的最佳實務為建置具彈性的架構，但如果您需要進行復原，則必須具有備份方法。 -
災難復原 (DR) 需求：如果您要將 Active Directory 遷移至 AWS，則必須針對發生災難時的恢復能力進行設計。如果您要將現有的 Active Directory 移動至 AWS，則可以使用次要 AWS 區域，並透過使用 Transit Gateway 連接這兩個區域，以允許進行複寫。此為一般偏好方法。部分組織對於在隔離環境 (您可以在此環境內中斷主要網站和次要網站之間的連線數天，以測試可靠性) 中測試容錯移轉具有不同需求。如果此為組織的需求，則可能需要時間從 Active Directory 中排除 split-brain 問題。您或許可使用 AWS Elastic Disaster Recovery
作為主動/被動實作，透過此方式將 DR 網站作為容錯移轉環境，而且必須定期隔離測試 DR 策略。評估遷移至 AWS 時，針對組織的復原時間點目標 (RTO) 和復原點目標 (RPO) 需求進行規劃是相當重要的因素。請務必定義需求與測試和容錯移轉計畫以驗證實作。
調動
符合您組織和營運需求的適當策略為將 Active Directory 遷移或延伸至 AWS 的重要元素。選擇與 AWS 服務整合的方式對於採用 AWS 方面至關重要。請務必選擇符合您業務需求之 Active Directory 或 AWS Managed Microsoft AD 的方法擴展。部分服務 (例如，Amazon RDS) 中的功能會仰賴使用 AWS Managed Microsoft AD。請務必評估 AWS 服務限制，以判斷 Amazon EC2 和 AWS Managed Microsoft AD 上的 Active Directory 是否具有相容性限制。建議您考量下列整合點作為規劃程序。
考慮在 AWS 中使用 Active Directory 的下列原因：
-
使 AWS 應用程式可搭配使用 Active Directory
-
使用 Active Directory 登入 AWS 管理主控台
使 AWS 應用程式可搭配使用 Active Directory
您可以啟用多個 AWS 應用程式和服務，例如 AWS Client VPN
您的使用者可透過 Active Directory 憑證登入執行個體。如此一來，您不需要使用個別執行個體登入資料或分佈私有金鑰 (PEM) 檔案。您可更輕鬆地透過利用使用中的 Active Directory 使用者管理工具，立即授予或撤銷使用者存取權。
使用 Active Directory 登入 AWS 管理主控台
AWS Managed Microsoft AD 可讓您授予成員 AWS 管理主控台的目錄存取權。根據預設，您的目錄成員無法存取任何 AWS 資源。您可以將 AWS Identity and Access Management (IAM) 角色指派給目錄成員，讓他們能夠存取各種 AWS 服務和資源。IAM 角色定義您的目錄成員可以存取的服務、資源和層級。
例如，您可以讓使用者透過其 Active Directory 憑證
您的目錄必須具有存取 URL，才能授予主控台存取權給目錄成員。如需有關如何檢視目錄詳細資料和取得存取 URL 的詳細資訊，請參閱《AWS Directory Service 管理指南》中的檢視目錄資訊。如需有關如何建立存取 URL 的詳細資訊，請參閱《AWS Directory Service 管理指南》中的建立存取 URL。如需有關如何建立 IAM 角色並向目錄成員指派 IAM 角色的詳細資訊，請參閱《AWS Directory Service 管理指南》中的授予使用者和群組 AWS 資源的存取權。
請考量 Active Directory 的下列遷移選項：
-
延伸 Active Directory
-
遷移至 AWS Managed Microsoft AD
-
使用信任以透過 AWS Managed Microsoft AD 連接 Active Directory
-
將 Active Directory DNS 與 Amazon Route 53 整合
延伸 Active Directory
如果您已具有 Active Directory 基礎架構，且想在將 Active Directory 感知工作負載遷移至 AWS 雲端時使用，則 AWS Managed Microsoft AD 可提供協助。您可以使用信任將 AWS Managed Microsoft AD 連接至現有的 Active Directory。如此表示您的使用者可透過其內部部署 Active Directory 憑證存取 Active Directory 感知和 AWS 應用程式，而不需要您同步使用者、群組或密碼。例如，您的使用者可以使用現有的 Active Directory 使用 WorkSpaces 者名稱和密碼登入 AWS 管理主控台。此外，當您使用作用中目錄感知應用程式 (例如 SharePoint 搭配 AWS 受管 Microsoft AD) 時，登入的 Windows 使用者可以存取這些應用程式，而無需再次輸入登入資料。
除使用信任之外，您還可透過部署 Active Directory 來延伸 Active Directory，以在 AWS 中的 EC2 執行個體上執行。您可以自行完成，或使用 AWS
遷移至 AWS Managed Microsoft AD
您可以套用兩種在 AWS 中使用 Active Directory 的機制。第一種方法是採用 AWS Managed Microsoft AD 將 Active Directory 物件遷移至 AWS。其中包括使用者、電腦及群組原則等。第二種機制是一種手動方法，您可以透過此方法匯出所有使用者和物件，然後透過使用 Active Directory Migration Tool
以下為移動至 AWS Managed Microsoft Active Directory 的其他原因：
-
AWS 受管 Microsoft AD 是一個實際的 Microsoft Active Directory 網域，可讓您在 AWS 雲端中執行傳統的使用中目錄感知工作負載，例如 Microsoft
遠端桌面授權管理 器 SharePoint、Microsoft 和 Microsoft SQL Server 永遠在 線。 -
AWS Managed Microsoft AD 可透過使用群組受管服務帳戶 (gMSA) 和 Kerberos 限制委派 (KCD)，協助您簡化並改善 Active Directory 整合 .NET 應用程式的安全性。如需詳細資訊，請參閱 AWS 文件中的透過使用 AWS Microsoft AD 簡化遷移和改善 Active Directory 整合 .NET 應用程式的安全性
。
您可以在多個 AWS 帳戶之間共用 AWS Managed Microsoft AD。如此可讓您管理 AWS 服務 (例如，Amazon EC2
透過省去手動將執行個體加入網域或在各個帳戶和 Amazon VPC 中部署目錄的必要作業，您就能在 EC2 執行個體上快速部署目錄感知的工作負載。如需詳細資訊，請參閱《AWS Directory Service 管理指南》中的共用目錄。請記住，共用 AWS Managed Microsoft AD 環境需要付費。您可以透過使用 Amazon VPC 對等或 Transit Gateway 對等，從其他網路或帳戶與 AWS Managed Microsoft AD 環境進行通訊，因此可能不需要共用。如果您打算透過下列服務使用目錄，則必須共用該網域：Amazon Aurora MySQL、Amazon Aurora PostgreSQL、Amazon FSX、Amazon RDS for MariaDB、Amazon RDS for MySQL、Amazon RDS for Oracle、Amazon RDS for PostgreSQL 及 Amazon RDS for SQL Server。
透過 AWS Managed Microsoft AD 使用信任
若要從現有目錄授予使用者 AWS 資源的存取權，您可以透過 AWS Managed Microsoft AD 實作使用信任。您也可以在 AWS Managed Microsoft AD 環境之間建立信任。如需詳細資訊，請參閱 AWS 安全性部落格中的與信任和 AWS Managed Microsoft AD 相關的所有須知資訊
將 Active Directory DNS 與 Amazon Route 53 整合
當您遷移至 AWS 時，可透過使用 Route 53 Resolver 將 DNS 整合至您的環境，以允許存取伺服器 (透過使用其 DNS 名稱)。建議您使用 Route 53 Resolver 端點來完成此作業，而非修改 DHCP 選項集。相較於修改 DHCP 選項集，此為較集中的管理 DNS 組態方法。此外，您可以利用各種解析程式規則。如需詳細資訊，請參閱聯網和內容交付部落格中的將 Directory Service 的 DNS 解析與 Amazon Route 53 Resolver 整合
遷移
當您開始遷移至 AWS 時，建議您考慮使用組態和工具選項來協助遷移。此外，請務必考量環境的長期安全性與運作方向。
請考量下列選項：
-
雲端原生安全性
-
將 Active Directory 遷移至 AWS 的工具
雲端原生安全性
-
適用於 Active Directory 控制器的安全群組組態：如果您使用 AWS Managed Microsoft AD，則網域控制器會提供 VPC 安全性組態，以限制存取網域控制器。您可能需要修改安全群組規則，以允許部分潛在使用案例的存取。如需安全群組組態的詳細資訊，請參閱《AWS Directory Service 管理指南》中的增強 AWS Managed Microsoft AD 網路安全性組態。建議您不要允許使用者修改此類群組，或將其用於任何其他 AWS 服務。如果使用者修改此類群組以封鎖必要的通訊，則允許其他使用者使用此類群組，可能會導致您的 Active Directory 環境服務中斷。
-
與用於活動目錄事件 CloudWatch 日誌的 Amazon 日誌集成 — 如果您正在執行 AWS 受管 Microsoft AD 或使用自我管理的活動目錄，則可以利用 Amazon CloudWatch 日誌集中管理您的活動目錄日誌記錄。您可以使用 CloudWatch 記錄檔將驗證、安全性和其他記錄檔複製到 CloudWatch。如此可讓您以輕鬆方式在單一位置搜尋日誌，並協助滿足部分合規要求。我們建議您與 CloudWatch 日誌整合，因為它可以幫助您更好地回應環境中 future 的事件。如需詳細資訊，請參閱 AWS 目 CloudWatch 錄服務管理指南中的為 AWS 受管活動目錄啟用 Amazon CloudWatch 日誌和 AWS 知識中心的適用於 Windows 事件日誌
的 Amazon 日誌。
將 Active Directory 遷移至 AWS 的工具
建議您使用 Active Directory Migration Tool (ADMT) 和 Password Export Server (PES) 來執行遷移。如此可讓您輕鬆從一個網域將使用者和電腦移動至另一個網域。如果您使用 PES 或從一個受管理的 Active Directory 網域遷移至另一個網域，請記住下列考量事項：
-
適用於使用者、群組及電腦的 Active Directory Migration Tool (ADMT)：您可以使用 ADMT
從自我管理的 Active Directory 將使用者遷移至 AWS Managed Microsoft AD。請務必考量遷移時間軸和安全性識別碼 (SID) 歷史記錄的重要性。遷移期間系統不會傳輸 SID 歷史記錄。如果支援 SID 歷史記錄為重要的需求，則請考慮在 Amazon EC2 中使用自我管理的 Active Directory 而非 ADMT，以便您維護 SID 歷史記錄。 -
Password Export Server (PES)：PES 可用於將密碼遷移至 AWS Managed Microsoft AD 而非從其遷出。如需有關如何從目錄遷移使用者和密碼的詳細資訊，請參閱 AWS 安全性部落格中的 如何使用 ADMT 將內部部署網域遷移至 AWS Managed Microsoft AD
和 Microsoft 文件中的 Password Export Server 3.1 版 (x64) 。 -
LDIF：LDAP Data Interchange Format (LDIF) 是一種檔案格式，可用於延伸 AWS Managed Microsoft AD 目錄的結構描述。LDIF 檔案包含將新物件和屬性新增至目錄的必要資訊。檔案必須符合語法的 LDAP 標準，且必須包含檔案新增之每個物件的有效物件定義。建立 LDIF 檔案之後，您必須將檔案上傳至目錄以延伸其結構描述。如需有關使用 LDIF 檔案延伸 AWS Managed Microsoft AD 目錄之結構描述的詳細資訊，請參閱《AWS Directory Service 管理指南》中的延伸 AWS Managed AD 的結構描述。
-
CSVDE：在部份情況下，您可能需要在未建立信任和使用 ADMT 的情形下，將使用者匯出和匯入目錄。雖然未盡理想，但您可以使用 CSVDE
(命令列工具) 從一個網域將 Active Directory 使用者遷移至另一個網域。若要使用 CSVDE，您必須建立包含使用者資訊 (例如，使用者名稱、密碼及群組成員資格) 的 CSV 檔案。接著，您可以使用 csvde 命令將使用者匯入新網域。您也可以使用此命令從來源網域匯出現有的使用者。如果您要從其他目錄來源 (例如，SAMBA Domain Services) 遷移至 Microsoft Active Directory，此方法可能會有所幫助。如需詳細資訊，請參閱 AWS 安全性部落格中的如何將您的 Microsoft Active Directory 使用者遷移至 Simple AD 或 AWS Managed Microsoft AD 。
其他資源
-
與信任和 AWS Managed Microsoft AD 相關的所有須知資訊
(AWS 安全性部落格) -
如何使用 ADMT 將您的內部部署網域遷移至 AWS Managed Microsoft AD
(AWS 安全性部落格) -
AWS 沉浸日的活動目錄
(AWS 工作坊工作室)
