文章段落
代管式 Active Directory 是什麼？如果你覺得在雲端上建置 Active Directory 網域服務步驟很多很麻煩，那能讓在雲端上建立 Microsoft Active Directory（AD）變得更安全、簡單的代管式 AD 絕對是不可不認識的工具！下面就跟著 Cloud Ace 一起從頭認識這項工具，以及雲地混和的 AD 架構吧！
代管式 Active Directory 是什麼？不用可以嗎？
Microsoft Active Directory（AD）是微軟生態系裡最重要的用戶管理系統。過去許多用戶在由地轉雲的過程中，都會碰到要將地端的 AD 系統搬遷上雲端的複雜網路架構問題，更不用說雲地混合的使用情境了。而在雲端建置 AD 也是磕磕碰碰，從 VM 開始一步步慢慢地設定上去。還沒有嘗試過的讀者可以參考《AD 帳號登入 GCP 方法攻略！用 Cloud Identity 與 GCDS/PS 移轉帳號資料》這篇文章，感受一下建置的凝滯感。
而既然我們已經上雲端了，不就該追求現代化的基礎建設嗎？雲端環境最大的吸引力不就在減少管理成本，進而達到全面 PaaS 與 SaaS 的目標嗎？基於這樣的需求，GCP 推出了代管式 AD 服務，也就是 Managed Microsoft Active Directory（Managed AD），讓我們不須再耗費大量的時間和心力處理基礎設定及維護，更專注於公司產品的商業邏輯。
Managed AD 最大優點：簡化網域服務建置步驟
那這邊就先來比較一下在雲端使用 VM 自建 AD，和透過 Managed AD 創建服務，兩者在建置流程有哪些差異吧！從下圖我們可以看到自建 AD 必須從規劃設定網路環境、選定主機規格（還需要考慮未來擴展需求）開始，一路到安裝 AD 及雲端網路環境整合，全套做完至少需要八個步驟。而使用 Managed AD，我們僅需將 Managed AD 服務啟動並設定管理用的 VM。整套流程少了一半以上的設置內容，看完後是否覺得輕鬆很多呢？
Managed AD 6大優勢
這裡為大家歸納六個使用 Managed AD 的好處（不含創建方便這項喔！）。包含「分離的專案 VPC 環境」、「支援 Multi-region 管理」、「雲端原生的 DNS 環境」、「簡潔的操作介面」、「自動建立的管理群組」和「代管的主機維護服務」這6項。
首先第1項：分離的專案 VPC 環境。如同其他代管式服務，一旦我們建立服務後就不用擔心會影響現行的雲端環境。因為 GCP 會自動產生一個 Private Service 專案並建立完整的網路連線及服務。而其網路流量都透過 GCP 內網傳輸，所以一來可妥善發揮 GCP 強大的內網速度，二來又可確保 AD 處在安全的封閉環境中。
而第2項：支援 Multi-region 管理。Managed AD 因為支援 GCP 內網的跨域服務，所以我們不需再建立 Region 對 Region 的 VPC peering 或 VPN 連線，就可輕易達到 High Availability（HA） 與 Global 的延伸性。
另外談到網路環境又不得不提到 AD 核心的 DNS 服務，所以第3項：雲端原生的 DNS 環境，指的是不同於自建 AD 需手動串接 Cloud DNS，Managed AD 會自動為我們創建好所有的 DNS Forwarding 與 Peering Zones，而這正是 GCP 代管服務的魅力所在！
接著第4點：簡潔的操作介面。這是因為 GCP Web Console 維持其簡便風格，Managed AD 可透過 UI 介面快速修改管理員密碼、新增服務網域，並建立與其他 AD 的 Domain Trust，整體介面相當簡潔實用。
而第5點：自動建立的管理群組，則是指在我們建立 Managed AD 後，服務會自動為創建一系列權限功能群組。所以我們在基本的用戶權限設定上可減少許多繁瑣的操作，直接將用戶加入對應權限的群組即可。
最後第6點：代管的主機維護服務。與所有代管式服務相同的一大重點就是硬體升級與維護都由 GCP 為我們處理，且一切都在不影響功能運作的情況下默默進行，有效節省地端維護的人力與時間成本。大家看完以上的優點後是否已經心動了呢？下面我們就正式來了解 Managed AD 的架構及組成吧！
Managed AD 服務架構與組成元件
前面介紹了 Managed AD 提供的服務，那接著就來探討當我們啟用 Managed AD 後，GCP 完成了哪些動作？創建了哪些服務與元件？讓我們可以更快速方便地享受 AD 的功能，且不需擔心原有的雲端架構受到影響。
Managed AD 代管雲端服務架構說明
首先我們來看看 GCP 自動創建的 Managed AD 網路環境。當我們創建 Managed AD Domain，系統會自動建立一個代管專案與獨立的 VPC 網路環境，並且透過 VPC Peering 的方式將需要 AD 服務的 VPC 與其串接。
但 VPC Peering 僅提供 Routing 的對接，對於 Domain Name 解析的運作還是要靠 Cloud DNS 進行。而 Cloud DNS 則需要透過 DNS Peering Zone 的方式與代管的 Cloud DNS 串接，再由代管的 Cloud DNS 將 Domain Query 轉發至 AD 的 DNS Server，如此一來受服務的 VPC 環境才能正確解析到 AD Domain server 的位置，從而進行帳戶驗證。當然這些操作在 GCP 上可一鍵完成，大家只需知道透過 Managed AD 可以省掉大量繁瑣的流程就好了。
Managed AD 服務實例與管理元件說明
上面說明了 Managed AD 在雲端網路環境執行的代管服務建置內容，接著我們來看看在 AD 服務內 Managed AD 又做了哪些事情吧。首先所有 Managed AD 創建的 VM 皆使用 Public Compute Engine Windows Server 2019 映像檔，這個檔案因為支援 GCP 的 Shield VM 服務所以可確保系統底層的安全性。
而除此之外，針對 Windows 服務裡最讓人擔心的 Patch 更新包，Managed AD 也會先做過測試才更新，確保服務不中斷。當然，AD 系統處理的通常是一些較敏感的用戶資料，所以 GCP 也對資料做了許多的加密與連線限制，讓內部工程師只有在特殊情境需求下才能進入 Domain Controller（DC）。
接著來看看 Managed AD 為我們創建了哪些管理元件。當我們啟用一個新的 Domain，Managed AD 就會自動為我們創建一系列的 AD 群組物件，並給予不同的權限劃分。這讓我們能輕易地將不同需求的用戶加入對應的權限群組，達到集中管理的目的。
那這些 AD 物件的建立，首先可分為 Cloud 與 Cloud Service Objects（CSO）兩種組織單位（OU）。Cloud OU 存放所有我們自建的 AD 物件，如自定義的用戶及群組，且我們擁有絕對的控制權。而 CSO OU 則是存放 Managed AD 創建的管理群組物件，即下圖的群組。我們可將用戶加進群組中以獲取權限，而在 CSO OU 中，只有 GCP 能建立物件，用戶只能修改部分的物件設定。
©2021 Google
Managed AD 延伸網路環境架構概述
上面介紹了 Managed AD 提供的服務與背後運作原理，接下來我們要談談在雲端上如何規劃 Managed AD 的網路架構，當中需要用到哪些雲端服務來達到雲地延伸與跨專案延伸的 AD Domain 管理服務，使既有的 AD 服務能與 Managed AD 系統串接整合。
雲地混合的 Managed AD 網路架構
我們先從簡單的雲地延伸服務架構開始。下圖我們可看到三個網路環境，分別是 On-premise（地端）、VPC-B（雲端專案）及 Managed-VPC（代管專案）。雲端專案與代管專案的對接原理我們在前面有提過這裡就不贅述，地端與雲端的網路環境對接最常見的做法是透過 Interconnect 或是 Site to Site VPN 對接來建立通道。而這樣的連線服務可讓地端透過 VPC-B 與 Managed-VPC 間的 VPC Peering 來使用 Managed-VPC 提供的 AD 服務，這當中我們唯一需要考量的點就是地端 DNS 與 VPC-B Cloud DNS 的對接方式。
要讓地端的 DNS Server 能解析到 Cloud DNS 的 Private Zone，我們需要設定一條 Conditional Forwarder，將通向 Managed AD Domain 的 Query 轉發至 Cloud DNS，而要設定 Conditional Forwarder 則需要提供 Cloud DNS 的 Server IP 來做指向。我們無法直接拿到 Cloud DNS 的 Server IP，所以需要設定一條 Inbound Forwarding Policy 來拿到用於轉發至 Cloud DNS 的靜態 IP，使地端能透過這個 IP 查詢 Cloud DNS 的 Private Zone，獲取 Managed AD 的 DNS Server IP，再透過 Interconnect 獲取雲端 AD 資訊來達到雲地延伸。
跨專案（VPC）的 Managed AD 網路架構
上面分析了雲地延伸的框架設計與使用的網路服務，接著我們要來看看跨專案的 AD 延伸架構。在下圖我們可見到三個不同的 VPC 環境，分別是 VPC-A （自建的 AD 專案）、VPC-B（啟用 Managed AD 專案）、Managed-VPC（代管專案）。這裡我們可以看到 VPC-A 與 VPC-B 之間的連線是透過 VPC Peering 達成，透過 VPC Peering 我們可使用 GCP 的內部網路傳輸，進而節省網速與流量費用。當然，如果使用 Site to Site VPN 搭配 Custom Route 就可以比照地端延伸的架構執行，但卻會產生外部的流量費用，所以這裡以最節省預算的方式來規劃網路架構。
但使用 VPC Peering 會產生一個問題，那就是 VPC Peering 有著 Transit 限制！舉例來說 VPC-A 與 VPC-B Peering；VPC-B 與 VPC-C Peering，那麼 VPC-A 是無法連接到 VPC-C 的，必須為 VPC-A 與 VPC-C 建立一條直連的 Peering 才行。所以如上圖所示，我們需要建立一條 VPC-A 與 Managed-VPC 的 VPC-Peering，並建立 VPC-A Cloud DNS 與 VPC-B Cloud DNS 的 DNS Peering，這樣兩邊的雲端網路環境才能串通。而接下來就和地端 DNS Server 設定一樣，建立 Conditional Forwarder 指向 VPC-B Inbound Forwarding Policy 後，就能完成跨專案的 AD 延伸服務。
Managed AD 介紹與架構解析結論
上面我們比較了使用 Managed AD 與自建 AD 的差別，讓大家體會代管服務的便利性！另外也介紹了 Managed AD 的服務組成與雲地混合架構，希望讓大家理解不同專案環境下的 AD 服務延伸方法。而在說明完架構與原理後，下一篇《代管式 Active Directory 教學― AD 網域服務及雲地混和環境實作》就要帶大家進入 Managed AD 的實作。讓我們一起來以地雲環境的 AD 延伸架構建立 One-way Forest Trust 吧！
那以上就是代管式 Microsoft AD 和地雲架構的基本介紹。希望大家不論過去知不知道代管式 Microsoft AD，閱讀完今天的文章後都能對這項方便的工具有更進一步認識！ 而如果想更了解 GCP 與代管式 Microsoft AD，或是對上述服務有相關需求都歡迎聯絡我們獲得更進一步的資訊！今天就分享到這，我們下次實作分享見掰掰！
▋延伸閱讀：
・比 SSH 連線 GCE 更好管理！輕鬆以 OS Login 掌握用戶資訊
・AD 帳號登入 GCP 方法攻略！用 Cloud Identity 與 GCDS/PS 移轉帳號資料
・AD 帳號登入 GCP 方法攻略！運用 ADFS 作為 GCP 外部身分認證
・什麼是 Cloud IAM
・GCP上如何建立Organization ？ 透過Cloud Identity Free 幫你實現
