虛擬機器中的活動目錄：可能被忽視很久的問題和答案（1）

餘二五發表於2017-11-07
虛擬機
寫在題外
很多人在今天把虛擬化及雲端計算的概念混淆掉了，但其實不容忽視的是虛擬機器已經滲透到了大大小小的資料中心中，成為各種業務的“基石”，可能小到一個測試系統，大到一個完整的Hadoop叢集負載。因此不管怎樣理解，個人認為對虛擬化做深入的實踐在今天以至於可期待的將來都是非常有必要的。
 
今天想較為深入的討論一下虛擬機器中的活動目錄需要注意的問題，以及如何通過Windows Server 2012中提供的守護者服務解決的。
下一篇部落格將繼續完成對虛擬機器環境下的域控制器克隆和快速複製的方法。

實際上，活動目錄與域控制器已經存在於虛擬化世界多年了，因此也積累了很多最佳實踐的方法，例如這篇詳細如何將域控制器部署於Hyper-V之上的技術文章。
那麼其中較為明確需要謹慎設計和考慮的地方主要集中於：
1. 對於虛擬機器環境下的域控制器如何應用快照
2. 對於執行域控制器的虛擬機器進行匯出
3. 拷貝域控制器虛擬磁碟檔案如VHD等
不知道，各位看官是否注意過上述問題和最佳實踐的提示，反正作為在從事的工作中搭建包括域控制器在內的環境時的確從來沒有注意過這個問題；我推測可能很多虛擬化環境的管理員也很可能忽視了這個潛在的問題。
 
在展開討論和回答之前，我們先闡述一下為什麼會有上述問題呢？快照難道不是虛擬機器特有的備份方式嗎？
對於活動目錄這種特殊的應用，存在活動目錄的複製關係，而這種複製關係是通過邏輯時鐘進行感知和控制的更新的，在活動目錄中邏輯時鐘叫做USN (update sequence number)，通過USN來記錄每個域控制器上的更新序列，每個域控制器都有自己獨有的標識改變來源，被叫做InvocationID。
 
image
因此，快照的恢復和容易造成USN漂移不正確，如果不能感知這種變化就很可能會造成通常被稱為”USN氣泡“的問題，併產生諸如：
  • 殘留物件
  • 不一致密碼
  • 不一致的屬性值
  • Schema FSMO回滾時Schema不一致
更嚴重的問題，甚至會造成安全主題SID重複或失效，在一段時間內的非授權的資源訪問或最終受影響的使用者無法正常登入域等。
 
看看下面這種情況，域中存在兩個域控制器（DC1和DC2），
1. 在時間T1，我們在DC1的虛擬機器上建立了一個快照，此時的USN是100，DC的InvocationID是A，安全主體SID池為 （域中唯一ID）RID 500到1000。
image
 
2. 在時間T2，管理建立了了100個新使用者，此時USN為200，DC的InvocationID是A，安全主體SID池為 （域中唯一ID）RID 600到1000，DC2收到DC1的更新並複製USN大於100的更新到USN200。
image
 
3. 在時間T2到T3之間，DC1出現故障，管理員在時間T3通過虛擬機器快照回滾DC1的虛擬機器，此時DC1的USN恢復至100，DC的InvocationID是A，安全主體SID池仍然回到 （域中唯一ID）RID 500到1000。請注意此時DC2已經複製了最新的DC1（A）的USN200的更新。
image
 
4. 在時間T4，管理員在DC1控制器新增了150個使用者，USN是250，DC的InvocationID是A，安全主體SID池為 （域中唯一ID）RID 650到1000；可是請注意DC2已經收到了來自DC1到USN200的更新，而並不知道DC1已經在T3時間通過虛擬機器快照回滾了！因此目前DC2只會接受來自DC1從USN200-250的更新；最終造成問題是匯聚後只有50個使用者到了DC2，其他的使用者在DC1和DC2中各有100個使用者，這部分使用者的安全主體SID是衝突的！這就是USN氣泡問題產生了。
image
 
那麼上述可能被忽視的活動目錄存在於虛擬化環境的問題，在新的Windows Server 2012中得到了解決，Windows Server 2012中引入了針對虛擬化環境活動目錄安全性的設計。
一種叫做虛擬機器生成ID(VM-Generation ID或VMGID)的機制被Hypervisor虛擬機器平臺層所採用，來賓虛擬機器作業系統和應用可以通過Windows Server 2012驅動提供的一個128位的特殊識別符號來區分；而虛擬機器中的Windows Server 2012的域控制器可以跟蹤VMGID的改變來檢測和保護活動目錄。
VMGID儲存在活動目錄資料庫（DIT）中，非複製屬性儲存在域控制器的計算機物件中，因此在提交本地DIT的更新前，域控制器會執行：
對比儲存在DIT中的VMGID於執行時環境的VMGID，如果兩者不同，則域控制器將在提交更新前重置域控制器的invocation ID以及失效的RID池。
上述過程也會發生在每次域控制器啟動的過程中。
對於具有FSMO操作主機角色的域控制器快照回滾這樣的操作，在複製週期完成之前FSMO角色和功能將不會開啟。
VMGID的功能對於虛擬化環境至關重要，通過這個功能可以確保在虛擬化操作中導致活動目錄執行上下文 （從一個以前時間點回滾的後設資料） 需要重新執行或重用的操作，必須提供一個新的VMGID!
 
好了，結束了抽象的描述，我們回到上面的例子再看一下：
域中的兩個域控制器（DC1和DC2），
1. 在時間T1，我們在DC1的虛擬機器上建立了一個快照，此時的USN是100，DC的InvocationID是A，儲存在DC1的DIT中的VMGID是G1，而從Hypervisor驅動執行時的VMGID也是G1。
image
 
2. 在時間T2，管理建立了了100個新使用者，此時USN為200，DC的InvocationID是A，儲存在DC1的DIT中的VMGID是G1，而從Hypervisor驅動執行時的VMGID也是G1，DC2收到DC1的更新並複製USN大於100的更新到USN200。
image
 
3. 在時間T2到T3之間，DC1出現故障，管理員在時間T3通過虛擬機器快照回滾DC1的虛擬機器，此時DC1的USN恢復至100，DC的InvocationID是A，儲存在DC1的DIT中的VMGID是G1，而從Hypervisor驅動感知回滾操作，執行時的VMGID更新為G2。（此時DC2已經複製了最新的DC1到USN200的更新。）
image
 
4. 在時間T4，管理員在DC1控制器新增了150個使用者，由於VMGID檢測到了差異，因此開始使用安全機制，新的USN101-250，DC的InvocationID改為B，並且重置VMGID為新的G2。
image
5. DC2將重新接受DC1(B) USN>100的更新，因此接受更新USN到250，之前複製到DC2的USN100-200的更新則可以反向更新到恢復快照後丟失這部分資訊的DC1上，因此USN 重用機制確保了USN回滾後的保護工作 ，最終匯聚後所有的使用者在所有的域控制器中都正常了：-）
image
 
目前可以支援虛擬化域控制器和VMGID的虛擬化產品見下表：
虛擬化產品
支援虛擬化域控制器及VMGID
Microsoft Windows Server 2012 server with Hyper-V Feature
是
Microsoft Windows Server 2012 Hyper-V Server
是
Microsoft Windows 8 with Hyper-V Client Feature
是
Windows Server 2008 R2 and Windows Server 2008
否
非微軟虛擬化解決方案
N/A
*對於第三方的虛擬化產品是否支援虛擬化域控制器及VMGID功能，需要檢視第三方的產品說明。
另外虛擬化執行的是微軟的 Hyper-V的Hypervisor必須是Windows Server 2012。
驗證是否支援可以通過裝置管理器介面，可以通過開啟虛擬機器域控制器作業系統的裝置管理器 Devmgmt.msc檢查系統裝置下已安裝的Microsoft Hyper-V 裝置和驅動，看是否包含Hyper-V生成計數器驅動 (vmgencounter.sys)。
image
 
關於在虛擬環境中的活動目錄就先討論這麼多，下一篇部落格將分享一下怎樣利用守護者服務來完成虛擬化環境中的域控制器的快速克隆和複製。
本文轉自 翟老貓 51CTO部落格，原文連結：http://blog.51cto.com/3387405/1180003，如需轉載請自行聯絡原作者


相關文章