本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 與 Microsoft Active Directory 整合
Amazon WorkSpaces 應用程式映像建置器和機群可與 Microsoft Active Directory 整合。這可讓您為使用者身分驗證、授權提供集中式方法，並將 Active Directory 群組政策套用至加入網域的 WorkSpaces 應用程式執行個體。使用加入網域的 WorkSpaces 應用程式機群，可提供與內部部署環境相同的管理優勢。這包括集中管理網路檔案共享、使用者應用程式權利、漫遊設定檔、印表機存取和其他以政策為基礎的設定。
將 WorkSpaces 應用程式環境與 Active Directory 整合時，請務必注意WorkSpaces 應用程式堆疊的初始身分驗證仍由 SAML2.0 IdP 管理。在使用者成功驗證 IdP 之後，當使用者啟動工作階段時，他們必須輸入其網域密碼或 Active Directory 網域的智慧卡身分驗證。
設計將與 WorkSpaces 應用程式搭配使用的 Active Directory Domain Services (ADDS) 環境時，有兩種服務選項和許多部署案例可供使用。此外，請確定已與您的 Active Directory 網站拓撲擁有者一起檢閱 WorkSpaces 應用程式聯網。
## 服務選項
Active Directory 也可以使用 [https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html) (AD) 部署。 AWS Managed Microsoft AD 是一種全受管服務，可讓您執行 Microsoft Active Directory。Microsoft Active Directory 也可以在 EC2 或內部部署上執行的自我託管環境中使用。
## 部署案例
下列部署案例是 WorkSpaces 應用程式與 Microsoft Managed AD 或客戶自我管理 Active Directory 的常用和建議整合選項。以下列出的所有架構圖都使用核心 Amazon 建構。
+ **Amazon Virtual Private Cloud (VPC)** — 建立專用於 WorkSpaces 應用程式服務的 Amazon VPC，其中至少有四個私有子網路分散在四個AZs。兩個私有子網路用於 WorkSpaces 應用程式機群和映像建置器。其餘兩個子網路用於 EC2 或 Microsoft Managed AD 上的網域控制站）。
+ **動態主機組態協定 (DHCP) 選項集** — 提供將組態資訊傳遞至 WorkSpaces 應用程式機群和映像建置器的標準，該機群將在 VPC 中佈建。DHCP 選項集是在 VPC 層級定義。它可讓客戶定義指定的網域名稱和 DNS 設定，這些設定將與佈建時所執行個體的 WorkSpaces 應用程式搭配使用。
+ **AWS Directory Services** — Amazon Microsoft Managed AD 可以部署到兩個私有子網路中，這些子網路將與 WorkSpaces 應用程式工作負載搭配使用。
+ **WorkSpaces 應用程式機群** — WorkSpaces 應用程式機群或映像建置器託管在 AWS 受管 VPC 中。每個 WorkSpaces 應用程式執行個體都有兩個彈性網路界面 (ENI)。主要界面 (`eth0`) 用於管理目的，並透過串流閘道代理最終使用者與執行個體的連線。次要界面 (`eth1`) 會注入到客戶 VPC 中，可用於存取自訂 VPC 或內部部署中的其他資源。
### 案例 1：現場部署的 Active Directory Domain Services (ADDS)
所有身分驗證流量都會周遊從客戶 VPC 到客戶閘道的 VPN 或 Direct Connect 連線。此案例的優點是使用可能已部署的 AD 環境，而無需在客戶 VPC 中佈建額外的網域控制站。缺點是依賴 VPN 或 Direct Connect 來驗證和授權 WorkSpaces 應用程式機群的使用者。如果有任何網路連線問題，WorkSpaces 應用程式機群或映像建置器會直接受到影響。提供具有不同路徑的雙 VPN 通道或 Direct Connect 連線可降低此潛在風險。
*案例 1：現場部署的 Active Directory Domain Services (ADDS)*
### 案例 2：將作用中網域服務 (ADDS) 擴展到 AWS 客戶 VPC
Active Directory 會擴展至您的客戶 VPC。應為客戶 VPC 中的新網域控制站建立 Active Directory 網站。身分驗證流量會路由到 AWS 客戶 VPC 中的網域控制站，而不是周遊 VPN 或 Direct Connect 連線。
*案例 2 — 將作用中網域服務擴展到 AWS 客戶虛擬私有雲端*
### 案例 3： AWS 受管 Microsoft Active Directory
AWS Managed Microsoft AD 部署在 中， AWS 雲端 並用作 WorkSpaces 應用程式機群和映像建置器的身分和資源網域。
*案例 3 — 受 AWS 管 Active Directory*
## Active Directory 服務網站拓撲
Active Directory 服務網站拓撲是實體網路的邏輯表示法。
網站拓撲可協助您有效率地路由用戶端查詢和 Active Directory 複寫流量。設計完善且維護良好的網站拓撲可協助您的組織實現下列優點：
+ 在內部部署和 之間同步時，將複寫 Active Directory 資料的成本降至最低 AWS 雲端。
+ 最佳化用戶端電腦尋找最近資源的能力，例如網域控制站。這有助於透過慢速廣域網路 (WAN) 連結減少網路流量、改善登入和登出程序，以及加速資源存取操作。
介紹 WorkSpaces 應用程式服務時，請確定用於 WorkSpaces 應用程式執行個體子網路的地址範圍已指派給您環境的正確網站。
對於案例 1 和案例 2，網站和服務是在登入時間和 Active Directory 資源存取時間方面獲得最佳使用者體驗的關鍵元件。
站點拓撲負責控制同一站點內及跨站點邊界的網域控制站之間的 Active Directory 複寫。
定義正確的網站拓撲可確保用戶端親和性，這表示用戶端 （在此情況下為 WorkSpaces 應用程式串流執行個體） 使用其偏好的本機網域控制站。
*Active Directory 網站和服務 — 用戶端親和性*
**提示**
最佳實務是為內部部署 AD DS 和 AWS 雲端之間的網站連結定義高成本。上圖是您應該指派給網站連結的成本範例 （成本 100)，以確保與網站無關的用戶端親和性。
如需網站拓撲的詳細資訊，請參閱[https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/designing-the-site-topology](https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/designing-the-site-topology)。
## Active Directory 組織單位
AWS 建議將組織單位 (OUs) 儲存在單一 WorkSpaces 應用程式目錄 Config 物件中設定。每個 WorkSpaces 應用程式堆疊都有自己的 OU 是最佳實務。這可讓您靈活地擁有每個堆疊的特定 GPOs。確保 OUs專用於 WorkSpaces 應用程式電腦物件，以避免將 WorkSpaces 應用程式特定的政策與內部部署桌面混合。請考慮為您 AWS 區域 部署 WorkSpaces 應用程式的每個 使用 sub-OUs。
## Active Directory 電腦物件清除
WorkSpaces 應用程式執行個體是暫時性的。隨著機群向外擴展和向內擴展，機群會建立和重複使用 Active Directory 電腦物件。
AWS 建議建立 AD 清除程序，以刪除移除 WorkSpaces 應用程式機群後可能存在的過時 Active Directory 電腦物件。