匯出 (0) 列印
全部展開

在 Azure 虛擬機器中部署 Windows Server Active Directory 的指導方針

更新日期: 2014年11月

本文說明在內部部署環境及 Microsoft Azure 虛擬機器 (VM) 上部署 Windows Server Active Directory 網域服務 (AD DS) 和 Active Directory Federation Services (AD FS) 之間的重要差異。

目錄

本文的適用對象是在內部部署環境中擁有部署 Active Directory 經驗的人。本文涵蓋了在 Microsoft Azure 虛擬機器/Azure 虛擬網路和傳統內部部署 Active Directory 部署環境中部署 Active Directory 的差異。Azure 虛擬機器和 Azure 虛擬網路為基礎結構即服務 (IaaS) 方案的一部分,可讓組織充分利用雲端的運算資源。

如果您不熟悉 AD 部署,請視情況參閱 AD DS 部署指南規劃 AD FS 部署

本文假設讀者已熟悉下列概念:

  • Windows Server AD DS 部署和管理

  • 支援 Windows Server AD DS 基礎結構的 DNS 部署和組態

  • Windows Server AD FS 部署和管理

  • 部署、設定及管理可使用 Windows Server AD FS Token 的信賴憑證者應用程式 (網站和 Web 服務)

  • 一般虛擬機器概念,例如如何設定虛擬機器、虛擬磁碟和虛擬網路

本文強調混合式部署案例的要求,其中 Windows Server AD DS 或 AD FS 的一部分會部署在內部部署環境,一部分則部署在 Azure 虛擬機器。本文一開始會先涵蓋在 Azure 虛擬機器與內部部署環境執行 Windows Server AD DS 和 AD FS 的重大差異,以及影響設計和部署的重要決策。本文的其餘部分會更詳細說明每一個決策要點的指導方針,以及如何在各種部署狀況中套用指導方針。

本文將不會討論 Azure Active Directory 的組態;Active Directory 是一種 REST 型服務,可為雲端應用程式提供識別管理及存取控制功能。但是,Azure Active Directory (AD) 和 Windows Server AD DS 設計為可一起搭配使用,以針對目前混合式 IT 環境和現代化應用程式提供身分識別及存取管理方案。為了幫助您了解 Windows Server AD DS 與 Azure AD 之間的差異和關係,請考量以下事項:

  1. 當您使用 Azure 將內部部署資料中心擴充至雲端時,您可能會在 Azure 虛擬機器上執行雲端中的 Windows Server AD DS。

  2. 您可以使用 Azure AD,為使用者提供軟體即服務 (SaaS) 應用程式的單一登入。例如,Microsoft Office 365 會使用這項技術,而且在 Azure 或其他雲端平台中執行的應用程式也可以使用此技術。

  3. 您可以使用 Azure AD (其存取控制服務) 讓使用者從 Facebook、Google、Microsoft 及裝載於雲端或內部部署環境之應用程式的其他身分識別提供者登入。

如需有關這些差異的詳細資訊,請參閱<Azure 身分識別>。

在 Azure 虛擬機器上部署 Windows Server Active Directory 的基本要求與在內部部署環境的虛擬機器中 (在某個程度上為實體電腦) 部署的要求沒有很大的差異。例如,在 Windows Server AD DS 的情況下,假如您在 Azure 虛擬機器上部署的網域控制站 (DC) 是現有內部部署公司網域/樹系中的複本,則處理 Azure 部署的方式大部分都可以比照其他任何 Windows Server Active Directory 網站來處理。也就是說,子網路必須定義在 Windows Server AD DS 中,也必須建立網站、將子網路連結至該網站,並使用適當的網站連結連接到其他網站。但是,所有 Azure 部署都有一些共同的差異,也有一些差異會因為特定部署情況而有所不同。底下概述兩個基本差異,並於隨後的段落中更詳細地說明:

  1. 提供與內部部署公司網路之間的連線可能需要 Azure 虛擬機器。

    將 Azure 虛擬機器連回到內部部署公司網路需要 Azure 虛擬網路,虛擬網路包括能夠順暢連接 Azure 虛擬機器和內部部署電腦的站對站或站對點虛擬私人網路 (VPN) 元件。這個 VPN 元件也可讓內部部署網域成員電腦存取 Windows Server Active Directory 網域,該網域的網域控制站會獨家裝載於 Azure 虛擬機器上。但是要注意很重要的一點,如果 VPN 失敗,相依於 Windows Server Active Directory 的驗證和其他作業也會失敗。雖然使用者可能會使用現有的快取認證登入,但是尚未發出票證或已經過時的所有點對點或用戶端對伺服器驗證嘗試將會失敗。

    如需示範影片以及逐步教學課程清單,包括��管理入口網站中設定站對站 VPN,請參閱虛擬網路

    note附註
    您也可以在與內部部署網路之間沒有連線的 Azure 虛擬網路上部署 Windows Server Active Directory。但是,本主題的指導方針會假設使用 Azure 虛擬網路,因為它會提供 Windows Server 所必要的 IP 定址功能。

  2. 靜態 IP 位址必須使用 Azure PowerShell 來設定。

    動態位址會依預設配置,但請改用 Set-AzureStaticVNetIP Cmdlet 來指派靜態 IP 位址。以此方式設定,靜態 IP 位址將可在服務修復和 VM 關機/重新啟動後繼續存留。如需詳細資訊,請參閱設定 VM 的靜態內部 IP 位址 (DIP)

以下的非完整詞彙清單會定義各種相關的 Azure 技術,而且將幫助您理解本文件。

  • Azure 虛擬機器:Azure 中的 IaaS 方案可讓客戶部署幾乎執行任何傳統式內部部署伺服器工作負載的 VM。

  • Azure 虛擬網路:Azure 中的網路服務可讓客戶在 Azure 中建立及管理虛擬網路,並使用虛擬私人網路 (VPN) 將虛擬網路安全地連結到他們自己的內部部署網路基礎結構。

  • 虛擬 IP 位址 (VIP):未繫結至特定電腦或網路介面卡的面向網際網路 IP 位址。系統會指派 VIP 給雲端服務,以便接收重新導向 Azure VM 的網路流量。VIP 是雲端服務的一個屬性,雲端服務可包含一部或多部 Windows Azure 虛擬機器。也請注意一點,Azure 虛擬網路可包含一個或多個雲端服務。VIP 提供原生負載平衡功能。

  • 動態 IP 位址 (DIP):此為僅供內部使用的 IP 位址。此位址應設定為主控 DC/DNS 伺服器角色之 VM 的靜態 IP 位址 (使用 Set-AzureStaticVNetIP Cmdlet)。

  • 服務修復:Azure 在偵測到服務失敗之後自動讓服務再次返回執行中狀態的程序。服務修復是 Azure 支援可用性和恢復功能的其中一個層面。雖然不太可能發生,但是在 VM 上執行之 DC 的服務修復事件之後的結果,將會與非計畫中的重新啟動類似,但是有一些副作用:

    • VM 中的虛擬網路介面卡將會變更

    • 虛擬網路介面卡的 MAC 位址將會變更

    • VM 的處理器/CPU 識別碼將會變更

    • 如果 VM 連接到虛擬網路,且 VM 的 IP 位址是靜態的,虛擬網路介面卡的 IP 組態將不會變更。

    但是,這些行為都不會影響 Windows Server Active Directory,因為它不會依存於 MAC 位址或處理器/CPU 識別碼,而且我們建議 Azure 上的所有 Windows Server Active Directory 部署都應在 Azure 虛擬網路上執行,如前所述。

在 Azure 虛擬機器上部署 Windows Server Active Directory DC 要根據在虛擬機器上的內部部署環境執行 DC 的相同指導方針。只要依照備份和還原 DC 的指導方針進行,執行虛擬化 DC 就是一個安全的作法。如需有關執行虛擬化 DC 之限制和指導方針的詳細資訊,請參閱<在 Hyper-V 執行網域控制站>。

Hypervisor 提供或忽略的技術可能會對許多分散式系統造成問題,包括 Windows Server Active Directory。例如,在實體伺服器上,您可以複製磁碟或使用不支援的方法回復伺服器的狀態,包括使用 SAN 等方式,但是在實體伺服器上這樣做要比在 Hypervisor 中還原虛擬機器快照集困難得多。Azure 提供的功能會導致同樣讓人困擾的狀況;例如,您不應該複製 DC 的 VHD 檔案而不執行定期備份,因為還原這些檔案會導致與使用快照集還原功能類似的狀況。

這類回復會引進 USN 泡沫,而可能導致 DC 之間永久的分歧狀態。這可能會導致以下情況:

  • 延遲物件

  • 不一致的密碼

  • 不一致的屬性值

  • 如果回復架構主機,則架構就會不相符

如需有關 DC 如何受到影響的詳細資訊,請參閱<USN 和 USN 回復>。

自 Windows Server 2012 起,AD DS 已具有內建的額外保護措施。只要基礎 Hypervisor 平台支援 VM-GenerationID,這些保護措施即可保護虛擬化網域控制站,使其避免發生前述問題。Azure 支援 VM-GenerationID,這表示在 Azure 虛擬機器上執行 Windows Server 2012 或更新版的網域控制站具有額外的保護措施。

note附註
在客體作業系統內的 Azure 中執行網域控制站角色的 VM 應先關閉再重新啟動,而不應使用 Azure 管理入口網站中的 [關機] 選項。現在,使用管理入口網站關閉 VM,會造成 VM 無法取消配置。取消配置的 VM 具有不會產生費用的優點,但也會重設 VM-GenerationID,這對於 DC 並不是適當設定。當 VM-GenerationID 重設時,AD DS 資料庫的 invocationID 也會重設、RID 集區會被捨棄,而 SYSVOL 會標示為「非代表性」。如需詳細資訊,請參閱 Active Directory 網域服務 (AD DS) 虛擬化 (層級 100) 簡介安全地虛擬化 DFSR

許多 Windows Server AD DS 部署情況非常適合在 Azure 上部署為 VM。例如,假設您在歐洲有一家公司需要驗證位於亞洲遠端位置的使用者。由於部署的成本以及管理伺服器後置部署的專業知識受限的緣故,此公司之前未曾在亞洲部署 Windows Server Active Directory DC。因此,來自亞洲的驗證要求是由位於歐洲的 DC 提供服務,其結果為次佳。在此情況下,您可以將 DC 部署在您已經指定必須於亞洲 Azure 資料中心內執行的 VM 上。將該 DC 連接至與遠端位置直接連接的 Azure 虛擬網路將會提高驗證效能。

Azure 也非常適合替代耗費成本的災害復原 (DR) 網站。以成本相對低的方式在 Azure 上裝載少量的網域控制站和單一虛擬網路,也就代表了很有吸引力的替代方案。

最後,您可能會想要在 Azure 上部署需要 Windows Server Active Directory,但是不相依於內部部署網路或公司 Windows Server Active Directory 的網路應用程式,例如 SharePoint。在此情況下,在 Azure 上部署隔離的樹系來符合 SharePoint 伺服器的要求是最佳作法。同樣地,部署需要連接內部部署網路和公司 Active Directory 的網路應用程式也受到支援。

note附註
由於它會提供 layer-3 連接,所以提供 Azure 虛擬網路與內部部署網路之間連線的 VPN 元件,也可以讓內部部署環境中執行的成員伺服器充分利用 DC,這些 DC 在 Azure 虛擬網路上會當做 Azure 虛擬機器來執行。但是因為無法使用 VPN,所以內部部署電腦與 Azure 架構網域控制站之間的通訊將無法運作,因而導致驗證和其他各種錯誤發生。 

  • 在包含多部 VM 的任何 Windows Server Active Directory 部署案例中,必須使用 Azure 虛擬網路達到 IP 位址的一致性。請注意,本指南假設 DC 在 Azure 虛擬網路上執行。

  • 如同內部部署 DC,我們同樣建議使用靜態 IP 位址。靜態 IP 位址只能使用 Azure PowerShell 來設定。請參閱設定 VM 的靜態內部 IP 位址 (DIP)。如果您有監控系統或其他解決方案會檢查客體作業系統內的靜態 IP 位址組態,您可以將相同的靜態 IP 位址指派給 VM 的網路介面卡內容。但請注意,如果 VM 經歷了服務修復或在管理入口網站中關閉,而使其位址取消配置,網路介面卡將會被捨棄。在此情況下,將必須重設客體內的靜態 IP 位址。

  • 在虛擬網路上部署 VM 不表示 (或需要) 連接回內部部署網路,虛擬網路只會啟用這個機會。您必須建立虛擬網路,才能在 Azure 與內部部署網路之間擁有私密通訊。您必須在內部部署網路上部署 VPN 端點。VPN 會從 Azure 開啟到內部部署網路。如需詳細資訊,請參閱虛擬網路概觀在管理入口網站中設定站對站 VPN

    note附註
    建立點對站 VPN 是可以直接連接個別 Windows 電腦到 Azure 虛擬網路的選項。

  • 不論您是否建立虛擬網路,Azure 都會收取輸出流量的費用,但是不會收取輸入流量的費用。各種 Windows Server Active Directory 設計選擇都會影響部署所產生的輸出流量。例如,部署 RODC 會限制輸出流量,因為它在傳出時不會複寫。但在決定是否部署 RODC 時,您必須權衡是否需要對 DC 執行寫入作業,以及站台中的應用程式和服務是否與 RODC 相容。如需有關流量費用的詳細資訊,請參閱 Azure 定價一覽

  • 雖然您可以在 Azure 上完全控制哪些伺服器資源用於內部部署環境的 VM,例如多少 RAM、磁碟大小等等,您還是必須從預先設定的伺服器規模清單中選擇。對於 DC 而言,除了作業系統磁碟以外還需要資料磁碟,以便儲存 Windows Server Active Directory 資料庫。

沒錯,您可以在 Azure 虛擬機器上部署 Windows Server AD FS,而且 AD FS 部署的最佳作法內部部署也同樣適用於 Azure 上的 AD FS 部署。但有部分的最佳作法 (例如負載平衡和高可用性) 需要用到 AD FS 本身所未提供的技術。它們必須由基礎結構提供。我們將檢視這些最佳作法,並了解如何使用 Azure VM 和 Azure VNet 加以達成。

  1. 一律不將安全性權杖服務 (STS) 伺服器直接公開至網際網路。

    這個作法很重要,因為 STS 角色會發出安全性 Token。因此,應該為 STS 伺服器 (例如 AD FS 伺服器) 使用與網域控制站相同的保護層級。如果犧牲 STS 伺服器,惡意的使用者就可以對信任組織的信賴憑證者應用程式以及其他 STS 伺服器發出存取權杖 (其中可能包含他們的選擇宣告)。

  2. 為與 AD FS 伺服器相同之網路中的所有使用者網域部署 Active Directory 網域控制站。

    AD FS 伺服器使用 Active Directory 網域服務來驗證使用者。建議您在與 AD FS 伺服器相同的網路上部署網域控制站。這可在 Azure 網路與您的內部網路之間的連結已中斷時提供營運持續性,並且可縮短延遲和提高登入的效能。

  3. 部署多個 AD FS 節點以達到高可用性和負載平衡。

    在許多情況下,AD FS 啟用的應用程式失敗是無法接受的,因為需要安全性權杖的應用程式通常非常關鍵。也因為如此,AD FS 此時存在於存取關鍵任務應用程式的重要路徑中,所以 AD FS 服務必須透過多個 AD FS Proxy 和 AD FS 伺服器而達到高度的可用性。為了要達到要求的平均分配,負載平衡器通常會在 AD FS Proxy 和 AD FS 伺服器前面進行部署。

  4. 部署用於網際網路存取的一或多個 Web 應用程式 Proxy 節點。

    當使用者需要存取受 AD FS 服務保護的應用程式時,AD FS 服務必須可從網際網路存取。這可藉由部署 Web 應用程式 Proxy 服務來達成。強烈建議部署多個節點,以達到高可用性和負載平衡。

  5. 限制 Web 應用程式 Proxy 節點對內部網路資源的存取。

    若要允許外部使用者從網際網路存取 AD FS,您需要部署 Web 應用程式 Proxy 節點 (在舊版的 Windows Server 中稱為 AD FS Proxy)。Web 應用程式 Proxy 節點會直接公開至網際網路。它們不一定要加入網域,而且只需要透過 TCP 連接埠 443 和 80 對 AD FS 伺服器的存取。強烈建議封鎖對所有其他電腦 (尤其是網域控制站) 的通訊。

    這在內部部署中通常會藉由 DMZ 來達成。防火牆會使用作業的白名單模式,限制從 DMZ 到內部部署網路的流量 (亦即,僅允許來自指定 IP 位址,並透過指定連接埠傳輸的流量,並會封鎖所有其他流量)。

下圖顯示這在傳統內部部署 AD FS 部署中的外觀。

使用 DMZ 的 ADFS On Prem

不過,因為 Azure 未提供原生而功能完整的防火牆功能,因此必須使用其他選項來限制流量。下表顯示每個選項及其優缺點。

 

選項 優點 缺點

Azure 網路 ACL

較不昂貴又簡單的初始組態

如果將任何新的 VM 新增至部署,則需要額外的網路 ACL 設定。

Barracuda NG Firewall

作業的白名單模式,並不需要網路 ACL 設定

成本較高,初始設定較複雜。

在此情況下部署 AD FS 的高階步驟如下所示:

  1. 使用 VPN 或 ExpressRoute 建立具有跨單位連線的虛擬網路

  2. 在虛擬網路上部署網域控制站。此步驟是選用的,但建議執行。

  3. 在虛擬網路上部署已加入網域的 AD FS 伺服器。

  4. 建立內部負載平衡集,其中包含 AD FS 伺服器,並在虛擬網路 (DIP) 內使用新的私人 IP 位址。

    1. 更新 DNS,以建立指向內部負載平衡之私人 IP 位址 (DIP) 的 FQDN。

  5. 建立 Web 應用程式 Proxy 節點的雲端服務 (或個別的虛擬網路)。

  6. 在雲端服務或虛擬網路中部署 Web 應用程式 Proxy 節點

    1. 建立外部負載平衡集,其中包含 Web 應用程式 Proxy 節點。

    2. 更新外部 DNS 名稱 (FQDN),以指向雲端服務公用 IP 位址 (VIP)。

    3. 設定 AD FS Proxy,以使用與 AD FS 伺服器的內部負載平衡集相對應的 FQDN。

    4. 更新宣告型網站,以將外部 FQDN 用於其宣告提供者。

  7. 限制 Web 應用程式 Proxy 與 AD FS 虛擬網路內任何電腦之間的存取。

若要限制流量,僅需針對傳輸至 TCP 連接埠 80 和 443 的流量設定 Azure 內部負載平衡器的負載平衡集,而捨棄所有其他對負載平衡集合之內部 DIP 的流量

ADFS 網路 ACLs

只有下列來源會允許對 AD FS 伺服器的流量:

  • Azure 內部負載平衡器。

  • 系統管理員在內部部署網路上的 IP 位址。

Warning警告
設計必須防止 Web 應用程式 Proxy 節點存取 Azure 虛擬網路中的其他 VM,或內部部署網路上的任何位置。在 Express Route 連線在內部部署應用裝置中設定防火牆規則,或設定站對站 VPN 連線的 VPN 裝置,即可達到此目的。

這個選項的缺點是需要為多個裝置設定網路 ACL,包括內部負載平衡器、AD FS 伺服器,和任何其他新增至虛擬網路的伺服器。若有任何裝置在新增至部署時未設定網路 ACL 以限制其流量,整個部署都可能承受風險。如果 Web 應用程式 Proxy 節點的 IP 位址有所變更,則必須重設網路 ACL (也就是說,Proxy 應該設定為使用靜態 DIP)。

使用網路 ACL 的 ADFS On Azur

另一個選項是使用Barracuda NG 防火牆應用裝置,以控制 AD FS Proxy 伺服器與 AD FS 伺服器之間的流量。這個選項會符合安全性和高可用性的最佳作法,且在初始安裝之後需要較少的管理,因為 Barracuda NG 防火牆應用裝置提供防火牆管理的白名單模式,而且可以直接安裝在 Azure 虛擬網路上。如此,無論在何時將新伺服器新增至部署,都無須再設定網路 ACL。但這個選項會增加初始部署的複雜性和成本。

在此情況下將會部署兩個虛擬網路,而不是一個。VNet 1 包含 Proxy,而 VNet2 包含 STS 和網路連回公司網路的網路連線;VNet1 因此在實體上會與 VNet2 隔離,進而與公司網路隔離。接著,VNet 1 會透過名為傳輸獨立網路架構 (TINA) 的特殊通道技術連接到 VNet2。TINA 通道會透過 Barracuda NG 防火牆連結至每個 Vnet — 每個 Vnet 各一個 Barracuda。若要達到高可用性,建議您在每個 VNet 上部署兩個 Barracuda。一個主動,另一個被動。它們可提供非常豐富的防火牆功能,讓我們在 Azure 中模擬傳統內部部署 DMZ 的作業。

使用防火牆的 ADFS On Azure

如需詳細資訊,請參閱2. AD FS:將可感知宣告的內部部署前端應用程式擴充到網際網路

AD FS 部署在目標只有 Office 365 SSO 時的替代方式

如果您的目標只是為了能夠登入 Office 365,則有另一個替代方式可部署 AD FS。在此情況下,您只需使用密碼同步內部部署來部署 DirSync,即可在最低的部署複雜性之下達到同樣的結果,因為這種方法不需要 AD FS 或 Azure。

下表比較部署 AD FS 和沒有部署時的登入程序如何運作。

 

使用 AD FS 和 DirSync 進行 Office 365 單一登入 使用 DirSync + 密碼同步同樣登入 Office 365
  1. 使用者登入公司網路,並進行 Windows Server Active Directory 驗證。

  2. 使用者嘗試存取 Office 365 (I am @contoso.com)。

  3. Office 365 將使用者重新導向至 Azure AD。

  4. 因為 Azure AD 無法驗證使用者及了解 AD FS 內部部署信任,它會將使用者重新導向 AD FS

  5. 使用者傳送 Kerberos 票證至 AD FS STS。

  6. AD FS 會將 Kerberos 票證轉換成所需的 Token 格式/宣告,並將使用者重新導向 Azure AD。

  7. 使用者會驗證 Azure AD (另一個轉換發生時)。

  8. Azure AD 將使用者重新導向至 Office 365。

  9. 使用者以無訊息模式登入 Office 365

  1. 使用者登入公司網路,並進行 Windows Server Active Directory 驗證。

  2. 使用者嘗試存取 Office 365 (I am @contoso.com)。

  3. Office 365 將使用者重新導向至 Azure AD。

  4. Azure AD 不能直接接受 Kerberos 票證,且沒有存在信任關係,因此會要求使用者輸入認證。

  5. 使用者輸入相同的內部部署密碼,且 Azure AD 以 DirSync 所同步的使用者名稱和密碼進行驗證。

  6. Azure AD 將使用者重新導向至 Office 365。

  7. 使用者可以使用 Azure AD Token 登入 Office 365 和 OWA。

如果 Office 365 具有使用密碼同步的 DirSync (沒有 AD FS),則「單一登入」會取代為「相同登入」,其中,「相同」表示使用者在存取 Office 365 時必須重新輸入其相同的內部認證。請注意,瀏覽器可記住這項資料,以減少後續的提示。在 DirSync + 密碼同步案例中 (沒有 AD FS),「單一登入」會取代為「相同登入」,其中,「相同」表示使用者在存取 Office 365 時必須重新輸入其相同的內部認證。請注意,瀏覽器可記住這項資料,以減少後續的提示。

其他考量

  • 如果您在 Azure 虛擬機器上部署 AD FS Proxy,則需要連接到 AD FS 伺服器。如果其位於內部部署環境,建議您利用虛擬網路提供的站對站 VPN 連線,好讓 Web 應用程式 Proxy 節點與其 AD FS 伺服器通訊。

  • 如果您在 Azure 虛擬機器上部署 AD FS 伺服器,則必須連接到 Windows Server Active Directory 網域控制站、屬性存放區和組態資料庫,而且 Azure 虛擬網路與內部部署網路之間可能也需要 ExpressRoute 或站對站 VPN 連線。

  • 所有來自 Azure 虛擬機器的流量 (輸出流量) 都需要收取費用。如果成本是驅動因素,建議您在 Azure 上部署Web 應用程式 Proxy 節點,而將 AD FS 伺服器保留在內部部署中。如果 AD FS 伺服器也部署在 Azure 虛擬機器上,將會產生額外成本以驗證內部部署使用者。輸出流量無論是否周遊 ExpressRoute 或 VPN 站對站連線,都會產生成本。

  • 如果您決定為 AD FS 伺服器的高度可用性使用 Azure 的原生伺服器負載平衡功能,請注意負載平衡會提供探查,用來判斷雲端服務中的虛擬機器健全狀況。在 Azure 虛擬機器的情況下 (與 Web 角色或背景工作角色相反),必須使用「自訂探查」,因為「預設探查」回應的代理程式不存在於 Azure 虛擬機器上。為簡單起見,您可以使用自訂 TCP 探查,這只會要求成功建立 TCP 連接 (使用 TCP SYN ACK 區段傳送及回應 TCP SYN 區段),以判斷虛擬機器健全狀況。您可以設定自訂探查,以使用虛擬機器主動接聽的任何 TCP 連接埠。若要這麼做,請參閱設定負載平衡集

    note附註
    需要公開同一組連接埠 (例如連接埠 80 和 443) 以便直接連接網際網路的電腦無法共用相同雲端服務。因此,建議您為 Windows Server AD FS 伺服器建立專用的雲端服務,以避免應用程式與 Windows Server AD FS 的連接埠要求可能重疊。

下列各節概述常見的部署狀況,這些狀況讓您必須考量一些重要因素。每個案例都有關於決策和考量因素之詳細資料的連結。

僅限雲端的 AD DS 部署

圖 1

SharePoint 會部署在 Azure 虛擬機器上,而且應用程式不相依於公司網路資源。此應用程式確實需要 Windows Server AD DS,但是不需要公司 Windows Server AD DS。不需要任何 Kerberos 或同盟信任,因為使用者可透過應用程式自行佈建至 Windows Server AD DS 網域,此網域也裝載於雲端的 Azure 虛擬機器上。

  • 網路拓撲:建立 Azure 虛擬網路,而沒有跨單位連線 (也稱為站對站連線)。

  • DC 部署組態:將新的網域控制站部署到新的單一網域,也就是 Windows Server Active Directory 樹系。這應該與 Windows DNS 伺服器一起部署。

  • Windows Server Active Directory 網站拓撲:使用預設的 Windows Server Active Directory 網站 (所有電腦都會在 Default-First-Site-Name 中)

  • IP 定址和 DNS:

    • 使用 Set-AzureStaticVNetIP Azure PowerShell Cmdlet,設定 DC 的靜態 IP 位址。

    • 在 Azure 的網域控制站上安裝和設定 Windows Server DNS。

    • 使用裝載 DC 和 DNS 伺服器角色之 VM 的名稱和 IP 位址來設定虛擬網路屬性。

  • 通用類別目錄:樹系中的第一個 DC 必須是通用類別目錄伺服器。此外,也應該要設定其他 DC 當做 GC,因為在單一網域樹系中,通用類別目錄不需要 DC 執行任何額外的工作。

  • Windows Server AD DS 資料庫和 SYSVOL 的位置:將資料磁碟加入至做為 Azure VM 執行的 DC,以便儲存 Windows Server Active Directory 資料庫、記錄檔和 SYSVOL。

  • 備份和還原:判斷您要在何處儲存系統狀態備份。必要時,請將其他資料磁碟加入至 DC VM 來儲存備份。

具有跨單位連線的同盟

圖 2

已經在內部部署環境成功部署而且由公司使用者使用之可感知宣告的應用程式可直接從網際網路存取。此應用程式會當做 SQL Database 的 Web 前端,它會在此資料庫中儲存和擷取資料。應用程式所使用的 SQL Server 也位於公司網路上。兩部 Windows Server AD FS STS 和負載平衡器都已經部署在內部部署,以便提供存取權給公司使用者。應用程式現在需要透過網際網路提供額外的存取權,以供使用自己公司身分識別的商業夥伴和現有公司使用者使用。

為了簡化及符合這個新要求的部署和組態需求,我們決定將兩個額外的 Web 前端和兩部 Windows Server AD FS Proxy 伺服器安裝在 Azure 虛擬機器上。所有的四部 VM 都將會直接公開到網際網路,而且將會使用 Azure 虛擬網路的站對站 VPN 功能提供與內部部署網路的連線。

  • 網路拓撲:建立 Azure 虛擬網路及設定跨單位連線

    note附註
    對於每一個 Windows Server AD FS 憑證,請確定憑證範本中定義的 URL 及產生的憑證可由 Azure 中執行的 Windows Server AD FS 執行個體聯繫。這可能需要跨單位連線到 PKI 基礎結構的一部分。例如,如果 CRL 的端點是根據 LDAP,而且獨家裝載於內部部署環境,就需要跨單位連線。如果不想要這樣,可能必須使用 CA 所發出的憑證,該 CA 的 CRL 可透過網際網路存取。

  • 雲端服務組態:確定您有兩個雲端服務,以便提供兩個負載平衡的 VIP。第一個雲端服務的 VIP 將會導向連接埠 80 和 443 上的兩部 Windows Server AD FS Proxy VM。Windows Server AD FS Proxy VM 將會設定為指向可面對 Windows Server AD FS STS 之內部部署負載平衡器的 IP 位址。第二個雲端服務的 VIP 將會導向兩部 VM,這兩部 VM 同樣在連接埠 80 和 443 上執行 Web 前端。設定自訂探查可確保負載平衡器只會將流量導向正常運作的 Windows Server AD FS Proxy 和 Web 前端 VM。

  • 同盟伺服器組態:設定 Windows Server AD FS 做為同盟伺服器 (STS),針對雲端中所建立的 Windows Server Active Directory 樹系產生安全性 Token。與您想要接受身分識別之其他來源合作夥伴之間設定同盟宣告提供者信任關係,並與您想要產生 Token 之其他目標應用程式之間設定信賴憑證者信任關係。

    在大多數情況下,Windows Server AD FS Proxy 伺服器會因為安全性目的而部署在面對網際網路的容量中,但是其對應的 Windows Server AD FS 同盟伺服器則依然隔離在直接網際網路連線之外。不論您的部署情況為何,您都必須使用 VIP 設定雲端服務,VIP 將會提供公開的 IP 位址以及能夠橫跨兩個 Windows Server AD FS STS 執行個體或 Proxy 執行個體進行負載平衡的連接埠。

  • Windows Server AD FS 高可用性組態:建議在部署 Windows Server AD FS 伺服器陣列時,至少要有兩部伺服器可供容錯移轉和負載平衡。您可以考慮將 Windows 內部資料庫 (WID) 用於 Windows Server AD FS 組態資料,並使用 Azure 的內部負載平衡功能,將傳入的要求分散至伺服器陣列中的不同伺服器。

    如需詳細資訊,請參閱 AD DS 部署指南

跨單位 AD DS 部署

圖 3

支援 Windows 整合式驗證及使用 Windows Server AD DS 當做組態和使用者設定檔資料儲存機制的可感知 LDAP 應用程式會部署在 Azure 虛擬機器上。應用程式必須利用現有公司 Windows Server AD DS,並提供單一登入。此應用程式無法感知宣告。使用者也可能需要直接從網際網路存取此應用程式。為了讓效能和成本最佳化,我們決定要連同 Azure 上的應用程式一起部署兩個額外的網域控制站當做公司網域的一部分。

  • 網路拓撲:建立具有跨單位連線的 Azure 虛擬網路。

  • 安裝方法:從公司 Windows Server Active Directory 網域部署複本 DC。對於複本 DC 而言,您可以在 VM 上安裝 Windows Server AD DS,並選擇性地使用「從媒體安裝」(IFM) 功能來減少在安裝期間需要複寫到新的 DC 的資料數量。如需教學課程,請參閱在 Azure 上安裝複本 Active Directory 網域控制站。即使您使用 IFM,在內部部署環境建立虛擬 DC 並將整個 VHD 移至雲端可能會比較有效率,而不是在安裝期間複寫 Windows Server AD DS。基於安全性考量,建議您在 VHD 複製到 Azure 之後,就從內部部署網路將它刪除。

  • Windows Server Active Directory 網站拓撲:在 Active Directory 網站及服務中建立新的 Azure 網站。建立 Windows Server Active Directory 子網路物件來代表 Azure 虛擬網路,並將此子網路加入至網站。建立新的網站連結來包含新的 Azure 網站以及 Azure 虛擬網路 VPN 端點所在的網站,以便控制和最佳化 Windows Server Active Directory 與 Azure 之間的往返流量。

  • IP 定址和 DNS:

    • 使用 Set-AzureStaticVNetIP Azure PowerShell Cmdlet,設定 DC 的靜態 IP 位址。

    • 在 Azure 的網域控制站上安裝和設定 Windows Server DNS。

    • 使用裝載 DC 和 DNS 伺服器角色之 VM 的名稱和 IP 位址來設定虛擬網路屬性。

  • 分散在不同地理位置的 DC:視需要設定額外的虛擬網路。若根據您的 Active Directory 站台拓撲,DC 必須位於與不同 Azure 區域相對應的地理位置中,您就必須據以建立 Active Directory 站台。

  • 唯讀 DC:您可以根據針對 DC 執行寫入作業的需求以及網站中應用程式和服務與 RODC 之間的相容性,將 RODC 部署在 Azure 網站上。如需有關應用程式相容性的詳細資訊,請參閱<唯讀網域控制站的應用程式相容性指南>。

  • 通用類別目錄:服務多重網域樹系中的登入要求需要 GC。如果您未在 Azure 網站中部署 GC,就會發生輸出流量成本,因為驗證要求會在其他網站中產生查詢 GC。若要將流量減至最低,您可以在 Active Directory 網站及服務中啟用 Azure 網站的萬用群組成員資格快取。

    如果您部署 GC,請設定網站連結和網站連結成本,好讓需要複寫相同部分網域分割區的其他 GC 不會將 Azure 網站中的 GC 當做來源 DC 的首選。

  • Windows Server AD DS 資料庫和 SYSVOL 的位置:將資料磁碟加入至 Azure VM 上執行的 DC,以便儲存 Windows Server Active Directory 資料庫、記錄檔和 SYSVOL。

  • 備份和還原:判斷您要在何處儲存系統狀態備份。必要時,請將其他資料磁碟加入至 DC VM 來儲存備份。

下表摘要列出先前案例中受到影響的 Windows Server Active Directory 技術領域,以及要考量的對應決策和下方更多詳細資料的連結。一些技術領域可能不適用於每個部署情況,對於某個部署情況而言,某些技術領域可能比其他技術領域更為重要。

例如,如果您在虛擬網路上部署複本 DC,而且您的樹系只有單一網域,則在這種情況下選擇部署通用類別目錄伺服器對於此部署情況並不重要,因為它將不會產生任何額外的複寫要求。另一方面,如果樹系有幾個網域,則在虛擬網路上部署通用類別目錄的決定可能會影響可用的頻寬、效能、驗證、目錄查閱等等。

 

項目編號

Windows Server Active Directory 技術領域

決策

因素

1

網路拓撲

您要建立虛擬網路嗎?

需要存取公司資源

驗證

帳戶管理

2

DC 部署組態

  • 在沒有任何信任下部署個別樹系?

  • 部署包含同盟的新樹系?

  • 部署新的樹系而且包含 Windows Server Active Directory 樹系對 Kerberos 的信任?

  • 部署複本 DC 來擴充公司樹系?

  • 部署新的子網域或網域樹狀結構來擴充公司樹系?

安全性

相容性

成本

恢復功能和容錯能力

應用程式相容性

3

Windows Server Active Directory 網站拓撲

您要如何使用 Azure 虛擬網路設定子網路、網站與網站連結,好讓流量最佳化並讓成本降至最低?

子網路與網站定義

網站連結屬性和變更通知

複寫壓縮

4

IP 定址和 DNS

如何設定 IP 位址和名稱解析?

請使用 Set-AzureStaticVNetIP Cmdlet 指派靜態 IP 位址

安裝 Windows Server DNS 伺服器,並以主控 DC 和 DNS 伺服器角色之 VM 的名稱和 IP 位址設定虛擬網路內容。

5

分散在不同地理位置的 DC

如何複寫到不同虛擬網路上的 DC?

若根據您的 Active Directory 站台拓撲,DC 必須位於與不同 Azure 區域相對應的地理位置中,您就必須據以建立 Active Directory 站台。設定 VNet 對 VNet 連線,以在個別 VNet 上的網域控制站之間進行複寫。

6

唯讀 DC

使用唯讀或可寫入 DC?

篩選 HBI/PII 屬性

篩選密碼

限制傳出流量

7

通用類別目錄

安裝通用類別目錄?

如果是單一網域樹系,則讓所有 DC 都成為 GC

如果是多重網域樹系,驗證將需要 GC

8

安裝方法

如何在 Azure 中安裝 DC?

  • 使用 Windows PowerShell 或 Dcpromo 安裝 AD DS

- 或 -

  • 移動內部部署虛擬 DC 的 VHD

9

Windows Server AD DS 資料庫和 SYSVOL 的位置

要將 Windows Server AD DS 資料庫、記錄檔和 SYSVOL 存放在哪裡?

變更 Dcpromo.exe 預設值

Important重要事項
這些重要 Active Directory 檔案必須放在 Azure 資料磁碟上,而不是實作寫入快取的作業系統磁碟上。

10

備份和還原

如何保護及復原資料?

建立系統狀態備份

11

同盟伺服器組態

在雲端中部署包含同盟的新樹系?

在雲端中部署 AD FS 內部部署及公開 Proxy?

安全性

相容性

成本

商業夥伴對應用程式的存取

12

雲端服務組態

當您初次建立虛擬機器時,系統會以隱含的方式部署雲端服務。您需要部署其他雲端服務嗎?

VM 需要直接暴露在網際網路上嗎?

服務需要負載平衡嗎?

13

公用和私人 IP 定址 (DIP 與 VIP) 的同盟伺服器需求

Windows Server AD FS 執行個體必須直接從網際網路聯繫嗎?

在雲端部署的應用程式需要其面對網際網路的 IP 位址與連接埠嗎?

針對您的部署需要的每個 VIP 建立一個雲端服務

14

Windows Server AD FS 高可用性組態

我的 Windows Server AD FS 伺服器陣列中有多少節點?

我的 Windows Server AD FS Proxy 伺服器陣列中要部署多少節點?

恢復功能和容錯能力

為了符合 Windows Server AD DS 的 IP 位址一致性和 DNS 要求,必須先建立 Azure 虛擬網路,並將您的虛擬機器與它連結。在其建立期間,您必須決定是否選擇將連線擴充到您的內部部署公司網路,此網路會以透明方式將 Azure 虛擬機器與內部部署電腦連接,這是利用傳統 VPN 技術來達成,而且需要將 VPN 端點公開在公司網路的邊緣。也就是說,VPN 是從 Azure 起始,並連接到公司網路,反向就不成立。

請注意,將虛擬網路擴充到內部部署網路時需要支付額外費用,因為這樣會超出每部 VM 所適用的標準收費。具體而言,Azure 虛擬網路閘道需要支付 CPU 時間的費用,而橫跨 VPN 與內部部署電腦通訊的每部 VM 所產生的輸出流量也需要付費。如需有關網路流量費用的詳細資訊,請參閱 Azure 定價一覽

您設定 DC 的方式取決於您想要在 Azure 上執行之服務的需求。例如,您可能會部署新的樹系 (與自己公司的樹系隔離) 來測試概念的證明、新的應用程式,或是需要目錄服務但不是內部公司資源之特定存取權的某個短期專案。

隔離的樹系 DC 不會與內部部署 DC 一起複寫,這樣會使系統本身產生較少的傳出網路流量,並直接降低成本,這是一項優點。如需有關網路流量費用的詳細資訊,請參閱 Azure 定價一覽

在另一個範例中,假設您對某項服務有隱私權要求,但是此服務取決於您內部 Windows Server Active Directory 的存取權。如果您可以在雲端裝載此服務的資料,您可能會在 Azure 上為您的內部樹系部署新的子網域。在此情況下,您可以為新的子網域部署 DC (沒有通用類別目錄,以便處理隱私權問題)。此案例連同複本 DC 部署將需要虛擬網路,以便連線到內部部署 DC。

如果您建立新的樹系,請選擇是要使用 Active Directory 信任還是同盟信任。平衡相容性、安全性、規範、成本和恢復功能所需的要求。例如,若要利用選擇性驗證,您可以選擇在 Azure 上部署新的樹系,並在內部部署樹系與雲端樹系之間建立 Windows Server Active Directory 信任。但是,如果應用程式可感知宣告,您可以部署同盟信任,而不是 Active Directory 樹系信任。另一個因素為將內部部署 Windows Server Active Directory 擴充至雲端而複寫更多資料或是因為驗證和查詢負載而產生更多傳出流量的成本。

可用性及容錯能力的需求也會影響您的選擇。例如,如果連結中斷了,利用 Kerberos 信任或同盟信任的應用程式可能都會完全中斷,除非您已經在 Azure 上部署足夠的基礎結構。類似複本 DC (可寫入或 RODC) 的替代部署組態會增加能夠容忍連結中斷的可能性。

您必須正確定義網站與網站連結,才能讓流量最佳化並讓成本降到最低。網站、網站連結和子網路會影響 DC 之間的複寫拓撲及驗證流量的流動。請考量下列流量費用,然後根據您的部署情況需求來部署和設定 DC:

  • 閘道本身每小時需支付工本費:

    • 可以根據您的需要將它啟動及停止

    • 如果將它停止,Azure VM 就會與公司網路隔離

  • 傳入流量免費

  • 傳出流量會根據 Azure 定價一覽收費。您可以將內部部署網站與雲端網站之間的網站連結屬性最佳化,如下所示:

    • 如果您使用多個虛擬網路,請適當地設定網站連結與其成本,以免 Windows Server AD DS 將 Azure 網站的優先順序排在可以免費提供相同服務層級的網站之前。您也可以考慮停用 [橋接所有網站連結 (BASL)] 選項 (此選項預設為啟用狀態)。如此可確保只有直接連接的網站才會彼此複寫。過渡連接網站中的 DC 無法再彼此直接複寫,而是必須透過共同網站複寫。如果中介網站因為某個原因而無法使用,則當網站之間的連線可用時,過渡連接網站中 DC 之間的複寫將無法進行。最後,在依然需要過渡複寫行為的區段時,建立包含適當網站連結和網站 (例如內部部署的公司網路網站) 的網站連結橋接器。

    • 適當地設定網站連結成本,以免發生意想不到的流量。例如,如果啟用 [嘗試下一個最接近的網站] 設定,請藉由提高與網站連結物件相關的成本 (此物件會將 Azure 網站連接回公司網路) 來確定虛擬網路網站不是下一個最接近的網站。

    • 根據一致性要求和物件變更的速率設定網站連結間隔排程。將複寫排程與延遲容許度配合。DC 只會複寫值的上一個狀態,所以在物件變更速率足夠時,減少複寫間隔可節省成本。

  • 如果讓成本降至最低具有較高的優先順序,請確定複寫已排程而且變更通知未啟用,這是在網站之間複寫時的預設組態。如果您在虛擬網路上部署 RODC,這就不重要了,因為 RODC 將不會複寫任何傳出的變更。但是,如果您部署可寫入的 DC,您應該確定網站連結未設定為依照不必要的頻率複寫更新。如果您部署通用類別目錄伺服器 (GC),請確定每隔一個包含 GC 的網站都會複寫網站中來源 DC 的網域分割區,此網站會連接到 Azure 網站中成本比 GC 低的網站連結。

  • 您可以變更複寫壓縮演算法來進一步減少網站之間複寫所產生的網路流量。壓縮演算法是由 REG_DWORD 登錄項目 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Replicator 壓縮演算法所控制。預設值為 3,此值與 Xpress Compress 演算法相互關聯。您可以將此值變更為 2,這樣會將演算法變更為 MSZip。在大多數情況下,這樣會增加壓縮,但會犧牲 CPU 使用量。如需詳細資訊,請參閱<Active Directory 複寫拓撲的運作方式>。

Azure 虛擬機器預設會配置「DHCP 租用位址」。因為 Azure 虛擬網路動態位址在虛擬機器的存留期間都會存在,因此符合 Windows Server AD DS 的需求。

因此,當您在 Azure 上使用動態位址時,您實際上是使用靜態 IP 位址,因為此位址在租用期間可路由傳送,而且租用期間就等於雲端服務的存留期間。

但是,如果關閉 VM,則會取消配置動態位址。若要避免取消配置 IP 位址,您可以使用 Set-AzureStaticVNetIP 指派靜態 IP 位址

針對名稱解析,部署您自己 (或利用現有的) DNS 伺服器基礎結構。Azure 提供的 DNS 不符合 Windows Server AD DS 的進階名稱解析需求。例如,它不支援動態 SRV 記錄等等。名稱解析對於 DC 和加入網域的用戶端而言,都是重要的組態項目。DC 必須能夠註冊資源記錄及解析其他 DC 的資源記錄。

基於容錯和效能理由,將 Windows Server DNS 服務安裝在 Azure 上執行的 DC 是最佳的作法。然後使用 DNS 伺服器的名稱和 IP 位址來設定 Azure 虛擬網路屬性。當虛擬網路上的其他 VM 啟動時,其 DNS 用戶端解析程式設定會將 DNS 伺服器設定為動態 IP 位址配置的一部分。

note附註
您不能將內部部署電腦加入 Windows Server AD DS Active Directory 網域,此網域會直接透過網際網路裝載於 Azure 上。Active Directory 的連接埠需求和網域加入作業會以不實際的方式將它轉譯,因而直接對網際網路公開必要的連接埠 (實際上就是整個 DC)。

當名稱變更時,VM 在啟動時會自動註冊其 DNS 名稱。

如需有關這個範例以及示範如何佈建第一個 VM 以及在其上安裝 AD DS 之另一個範例的詳細資訊,請參閱在 Windows Azure 上安裝新的 Active Directory 樹系。如需有關使用 Windows PowerShell 的詳細資訊,請參閱 Azure PowerShell 使用者入門Windows Azure 管理 Cmdlet

在不同的虛擬網路上裝載多個 DC 時,Windows Azure 會提供一些優點:

  • 多重站台容錯功能

  • 實體上接近分公司辦公室 (較低延遲)

如需在虛擬網路之間設定直接通訊的相關資訊,請參閱設定 VNet 對 VNet 連線

您必須選擇是要部署唯讀還是可寫入的 DC。您可能比較傾向於部署 RODC,因為您對它們不會有實體控制權,但是 RODC 設計目的是要部署在實體安全性有風險的位置,例如分公司辦公室。

Windows Azure 沒有分公司辦公室的實體安全性風險,但是 RODC 經過證明可能還是比較具成本效益,因為其所提供的功能非常適合這些環境,雖然原因不盡相同。例如,RODC 沒有傳出複寫,而且能夠選擇性地填入密碼。在缺點方面,當使用者或電腦進行驗證時,缺少這些密碼可能需要隨選傳出流量加以驗證。但是,密碼可以選擇性地預先填入及快取。

RODC 針對 HBI 和 PII 顧慮方面提供一個額外的優點,因為您可以將包含敏感性資料的屬性加入至 RODC 篩選過的屬性集 (FAS)。FAS 是一組可自訂的屬性,這些屬性不會複寫到 RODC。如果您不被允許或不想要在 Windows Azure 上儲存 PII 或 HBI,您可以使用 FAS 當做保護。如需詳細資訊,請參閱<RODC 篩選過的屬性集>。

請確定應用程式與您打算使用的 RODC 相容。許多具有 Windows Server Active Directory 功能的應用程式都可搭配 RODC 順利運作,但是某些應用程式如果無法存取可寫入的 DC,執行效率可能會很差或甚至失敗。如需詳細資訊,請參閱<唯讀網域控制站的應用程式相容性指南>。

您必須選擇是否安裝通用類別目錄。在單一網域樹系中,您應該將所有 DC 設定為通用類別目錄 (GC) 伺服器。它將不會增加成本,因為沒有任何額外複寫流量。

在多重網域樹系中,驗證過程中必須有 GC 才能擴充萬用群組成員資格。如果您未部署 GC,在每個驗證嘗試期間,虛擬網路上針對 Windows Azure 上的 DC 驗證的工作負載將會間接產生傳出驗證流量來查詢內部部署的 GC。

與 GC 相關的成本比較無法預測,因為它們會裝載每個網域 (部分方式)。如果工作負載裝載面對網際網路的服務,而且向 Windows Server AD DS 驗證使用者,則成本可能完全無法預測。為了在驗證期間減少雲端網站之外的 GC 查詢,您可以啟用萬用群組成員資格快取

您必須選擇要如何在虛擬網路上安裝 DC:

只將「Azure 虛擬機器」用於 DC (與 Windows Azure Web 角色或「背景工作」角色 VM 相反)。它們很持久,而且需要 DC 狀態的持久性。Azure 虛擬機器是針對類似 DC 的工作負載所設計。

請勿使用 SYSPREP 部署或複製 DC。從 Windows Server 2012 開始才能使用複製 DC 的功能。複製功能需要基礎 Hypervisor 中的 VMGenerationID 支援。Windows Server 2012 中的 Hyper-V 和 Windows Azure 虛擬網路都支援 VMGenerationID,就如同虛擬化軟體廠商一樣。

選取要在何處尋找 Windows Server AD DS 資料庫、記錄檔和 SYSVOL。它們必須在 Azure 資料磁碟上部署。“

note附註
Azure 資料磁碟受限為 1 TB。

資料磁碟機預設不會快取寫入。連接到 VM 的資料磁碟機會使用「寫通快取」。寫通快取會從 VM 的作業系統觀點來確保,在交易完成「之前」,持久的 Azure 儲存體會認可寫入。它會以稍微較慢的寫入速度為代價來提供持久性。

這對於 Windows Server AD DS 很重要,因為事後寫入磁碟快取會讓 DC 做的假設失效。Windows Server AD DS 會嘗試停用寫入快取,但由磁碟 IO 系統決定要不要接受。在某些情況下,無法停用寫入快取可能會引進 USN 回復,導致物件逗留和其他問題。

對虛擬 DC 而言的最佳作法是執行下列作業:

  • 將 Azure 資料磁碟的 [主機快取偏好設定] 設定為 [無]。如此可避免 AD DS 作業的寫入快取發生問題。

  • 將資料庫、記錄檔和 SYSVOL 存放在相同的資料磁碟或不同的資料磁碟。一般而言,這個磁碟與用於作業系統本身的磁碟不同。結論重點就是 Windows Server AD DS 資料庫和 SYSVOL 不得儲存在 Azure 作業系統磁碟類型上。根據預設,AD DS 安裝程序會將這些元件安裝在 %systemroot% 資料夾中,但是 Azure 不建議這樣做。

請注意,DC 的備份和還原通常會支援以及不支援哪些項目,更具體來說,就是 VM 中執行的項目。請參閱<虛擬網域控制站的備份和還原考量>。

只使用特別能感知 Windows Server AD DS 備份需求的備份軟體 (例如 Windows Server Backup) 來建立系統狀態備份。

請勿複製 DC 的 VHD 檔案來取代正常的備份執行。萬一需要還原,請使用複製的 VHD 來還原而不要使用 Windows Server 2012,支援的 Hypervisor 將會引進 USN 泡沫。

Windows Server AD FS 同盟伺服器 (STS) 的組態一部分取決於您想要部署在 Azure 上的應用程式是否需要存取內部部署網路的資源。

如果應用程式符合下列條件,您可以在與內部部署網路隔離的環境中部署應用程式。

  • 它們可接受 SAML 安全性 Token

  • 它們可向網際網路公開

  • 它們不會存取內部部署資源

在此情況下,請依照以下方式設定 Windows Server AD FS STS:

  1. 在 Azure 中設定隔離的單一網域樹系。

  2. 設定 Windows Server AD FS 同盟伺服器陣列來提供對樹系的同盟存取權。

  3. 在內部部署樹系中設定 Windows Server AD FS (同盟伺服器陣列和同盟 Proxy 伺服器陣列)。

  4. 建立內部部署環境與 Windows Server AD FS 的 Azure 執行個體之間的同盟信任關係。

另一方面,如果應用程式需要存取內部部署資源,您可以使用 Azure 上的應用程式來設定 Windows Server AD FS,如下所示:

  1. 設定內部部署網路與 Azure 之間的連線。

  2. 在內部部署樹系中設定 Windows Server AD FS 同盟伺服器陣列。

  3. 在 Azure 上設定 Windows Server AD FS 同盟 Proxy 伺服器陣列。

這個組態具有減少內部部署資源曝光的優點,類似於使用周邊網路的應用程式設定 Windows Server AD FS。

請注意,不管是哪一種情況,如果需要企業對企業的共同作業,您都可以建立與更多識別提供者的信任關係。

如果您想要直接將 VM 向網際網路公開或公開面對網際網路的負載平衡應用程式,將需要雲端服務。這是可行的,因為每個雲端服務都會提供單一可設定的 VIP。

每部 Azure 虛擬機器都會收到一個 DIP。DIP 是只能在 Azure 中存取的私人位址。但是在大多數情況下,需要為您的 Windows Server AD FS 部署設定 VIP。將 Windows Server AD FS 端點公開至網際網路需要 VIP,同盟的合作夥伴和用戶端會使用 VIP 進行驗證和持續管理。VIP 是雲端服務的一個屬性,雲端服務可包含一部或多部 Azure 虛擬機器。如果在 Azure 和 Windows Server AD FS 上部署之可感知宣告的應用程式面對網際網路並且共用共同的連接埠,每個應用程式都會需要自己的 VIP,因此必須為應用程式建立一個雲端服務,並且為 Windows Server AD FS 建立第二個雲端服務。

如需 VIP 和 DIP 詞彙的定義,請參閱<詞彙和定義>。

雖然部署獨立的 Windows Server AD FS 同盟服務是可行的,但是建議您部署至少有兩個節點的伺服器陣列,這兩個節點用於 AD FS STS 和生產環境的 Proxy。

請參閱<AD FS 2.0 設計指南>中的<AD FS 2.0 部署拓撲考量>,以決定哪一個部署組態選項最適合您的特定需求。

note附註
若要讓 Azure 上的 Windows Server AD FS 端點獲得負載平衡,請在相同的雲端服務中設定 Windows Server AD FS 伺服器陣列的所有成員,並將 Azure 的負載平衡功能用於 HTTP (預設為 80) 和 HTTPS 連接埠 (預設為 443)。如需詳細資訊,請參閱<Azure 負載平衡器探查>。

Azure 不支援 Windows Server 網路負載平衡 (NLB)。

顯示:
© 2015 Microsoft