WSFC AD&SMB依賴性討論

   WSFC雖然只是Window Server上面的一個功能，但其實這個產品內部的組件協同性以及和微軟其它解決方案的協同性特別強，對比微軟其它產品，老王認為WSFC的MSDN blog做得非常好，寫過很多篇關于WSFC內部組件運作機理的博客，主要用心閱讀加以實踐就能很快的掌握，至于和其它產品的協同性，例如WSFC會和AD，SMB協同，以提供群集基本運作，上層應用又有exchange dag，sql ag基于WSFC實現應用高可用，外層管理又有SCVMM，Honolulu，OMS，SCOM，SCO等管理套件，可以說WSFC即是數據中心運作的邏輯高可用實現，又是一個應用持續運作避免不了的中轉站

  這篇文章中老王想和大家探討下WSFC基本運作中所依賴的AD與SMB，究竟什么情況下會依賴，為什么要依賴它們，如果沒有它們會產生怎樣的效果。

  首先先談AD，沒什么好說的，相信大家或多或少對微軟AD域都有一些了解，也是微軟為數不多可以拿出手的產品之一，AD最主要的用途就是集中身份驗證，通過一套身份數據庫，就可以為環境里面的用戶，計算機，應用程序統一提供身份驗證，進一步還可以針對于工作環境做集中管理，策略分發，資源分發。

  和WSFC最直接相關聯的就是身份驗證了，我們知道現在WSFC部署可以分為正常AD集成， RODC，無CNO，工作組，多域部署，其中無CNO，工作組模式，多域部署模式類似，都是不在群集中產生計算機對象，這樣導致的效果就是群集應用不能執行Kerberos身份驗證，只能走NTLM驗證，或單獨的驗證機制，例如SQL SA驗證，這三種部署模式部署出來的群集所能夠支持的應用也受限，例如不支持MSMQ，對于文件服務器群集不能使用kerberos身份驗證，hyper-v群集不支持實時遷移

  其根本原因是因為群集里面沒有CNO對象，我們都知道高可用群集的一個主要實現是要做到對外就像是一臺計算機一樣，應用不知道我是在和一個群集交互，只知道我在一個一個計算機交互，并且我應該是可以一直和它進行交互的，但實際上這個計算機是邏輯構建的，背后會由群集組件協調不同節點提供服務，正常來講這個對外計算機應該要有自己的netbios名稱，dns名稱，計算機對象，才算一個可以完整的可以進行訪問和身份驗證的計算機，如果我們采用無CNO，工作組模式，多域部署，則這個群集邏輯計算機對外就只有一個DNS名稱，而不能提供身份驗證服務。

  在一個AD域環境中，當用戶發送登陸域請求時，本地Local Secutity Subsystem首先會向域控申請用戶的session ticket，如果用戶賬戶密碼正確，則頒發，拿到用戶ticket后，LSS還會向域控申請計算機的session ticket，校驗計算機密碼是否正確，如果和AD中符合則頒發session ticket，本地LSS拿到這兩個ticket后，才會為這次登陸構建access token令牌，后續用戶才可以使用這個token去執行程序，得知這個過程是非常關鍵的，這樣即是說每次身份驗證登陸都需要和AD拿用戶的ticket和計算機ticket，一旦其中一個失效，則這次驗證失敗，無法登陸。

 在WSFC環境中這同樣很重要，舉個例子，正常情況下，如果我配置了一個DTC群集，外面的程序要想訪問，是可以直接通過DTC群集的CNO對外進行身份驗證，這樣做的目的是為了給用戶提供一個統一邏輯，當后臺一個節點宕機，用戶還是使用同樣的名稱訪問，只不過是另外一個節點提供服務。但是，如果DTC當前所在的節點，計算機對象出現了問題，例如計算機對象被誤刪除了，這時候通過cluster log可以看到日志，RHS會定期檢測機器網絡名稱，會一直檢測到這個機器網絡名稱無法訪問，當前節點無法與AD聯系，無法登陸，這時候，群集并不會因此發生故障轉移。但用戶程序可以感知到，這時候訪問到群集無法執行身份驗證了，由此看來雖然我們有了邏輯的CNO，但仍需要關注各節點的AD計算機狀態，因此具體身份驗證還是會涉及到應用所在節點，這時產生的直接效果就是DTC這個群集應用無法執行身份驗證，因為所在節點無法正常登陸到AD拿到計算機ticket，處理方式就是最終排錯發現問題，先把DTC轉移至其它正常可以和DC拿到ticket的的節點上，恢復正常身份驗證，然后再從AD恢復被刪除的計算機對象。

節點域計算機對象的正常是否，可以直接影響到需要身份驗證的群集應用，因此群集應用的服務賬戶，計算機對象，CNO對象同樣重要，都是群集在AD中需要重點關注的內容

除了對于計算機ticket的依賴，WSFC還會依賴AD實現Kerberos驗證，例如SQL群集，SQL Server使用Windows身份驗證時，SQL Server通過Windows安全支持提供程序接口（SSPI）間接支持Kerberos，默認情況下SQL 會首先嘗試通過SSPI和AD協商，如果可以執行Kerberos驗證，則通過Kerberos驗證，如果無法通過則回退為NTLM驗證，因此很多SQL管理員很多時候遇到的驗證問題往往都和SPN有關，SQL群集配置的時候會寫入服務賬戶特有的SPN值，如果寫入失敗，或后期被誤刪除，無法校驗SPN，則Kerberos驗證將失敗，因此對于使用Kerberos驗證的程序，也需要關注其服務賬戶以及CNO VCO對象的SPN值，可以在健康的時候進行記錄下來，以便日后恢復時增補

CNO VCO會寫入AD計算機的三個屬性：

DnsHostName ：FQDN值

ServicePrincipalName：SPN值

HOST / 虛擬服務器的NetBIOS名稱
HOST / FQDN的虛擬服務器
MSClusterVirtualServer / 虛擬服務器的NetBIOS名稱
MSClusterVirtualServer / FQDN的虛擬服務器
MSServerCluster / 虛擬服務器的NetBIOS名稱（此SPN僅為默認群集名稱創建）
MSServerCluster / FQDN（此SPN僅為默認群集名稱創建）

DisplayName ：網絡名稱資源的NetBIOS名稱

上述SPN值為群集安裝后默認注冊的SPN，如果基于群集上層跑了一些應用，應用如果需要進行kerberos驗證，也會注冊SPN到CNO或VCO，以前曾經有一些第三方軟件會在注冊的時候僅針對單節點注冊SPN，導致故障轉移后用戶還需要訪問新的名稱進行驗證，后來開始大部分應用都會直接注冊群集CNO名稱，當一個節點宕機，自動切換至另外一個節點驗證

以上是老王認為WSFC對于AD主要的兩點依賴，如果你的程序訪問賬戶密碼正確，但就是無法正常驗證群集應用，可以進一步查看是否由于應用所在節點計算機對象不正常，或未按照預期的kerberos驗證，請查看服務賬戶和VCO對象的SPN值是否正確，如果使用沒有VCO則檢查CNO，這里需要注意的是，群集并不會因為你的節點計算機對象丟失或SPN值丟失而進行故障轉移，所以如果基于群集的應用驗證出現問題還需要去檢查程序和AD，群集只是能做到提供一個統一的對外名稱，一個節點宕機，你可以繼續通過這個統一對外名稱來完成驗證。

另外還有一點，AD組策略的計算機密碼重置期限有時會影響到計算機對象或CNO對象無法正常聯機，因此建議把群集計算機對象和節點對象統一放置到單獨OU，針對此OU單獨設置一個計算機嗎重置期限，可以長一些，在群集OU對象或CNO對象上面配置防刪。

上述簡單為大家介紹了下老王一時想起的WSFC對于AD的依賴，CNO，VCO，登陸憑證驗證，計算機密碼重置策略，Kerberos驗證，SPN，如有不全之處歡迎大家補充

對于SMB，相信大家都有所了解，它是一個網絡文件共享協議，允許應用程序和終端用戶從遠端的文件服務器訪問文件資源，區別于FTP，SMB是可以直接互相傳輸，而不需要有上傳下載的過程

在之前的版本2003 2000 2008中，大家對于SMB的理解大概就是一個共享傳輸協議，我兩個機器之間做共享互相拷貝文件走的是SMB協議，主要用作客戶端互傳，文件服務器共享，DFS等等，但是到了2012開始，SMB協議變的越來越重要，例如引入了SMB多通道，SMB Direct(RDMA)，SOFS模型，性能開始有了很大提升，更多的加入到企業級場景中，2012R2開始，官方正式宣布，群集內部CSV元數據傳輸與CSV重定向流量由走SMB協議，2016宣布存儲復制各節點走SMB協議。

我們首先來關注CSV部分對于SMB的依賴，2012R2開始，CSV使用SMB作為各節點間元數據交互與重定向IO的流量，這里簡單和大家介紹介紹下CSV，以2012R2架構為例，CSV給管理員的感覺好像是它被掛載在所有節點，所有節點都可以訪問CSV卷，但事實上，真正CSV同一時刻只實際被掛載到一個節點，這個節點稱為協調者節點，只有協調節點得可以直接和下層的NTFS文件系統交互，其它節點如果希望執行文件操作，創建文件，關閉文件，重命名文件，更改文件屬性，刪除文件，更改文件大小，任何文件系統控制等，都需要把要執行的操作，以及目標文件，這些元數據信息反饋給協調者節點，最終由協調者節點完成真正的對文件系統操作，CSV并不是一個文件系統，它只是一個編排層，編排各節點按照順序讀取寫入NTFS或REFS文件系統，還有一種流量則是重定向流量，這種流量是比較可怕的，當該節點失去到物理磁盤的資格，所有寫入讀取操作，都將被轉發到協調者節點執行，這會給協調者節點帶來巨大流量，同時失去資格的節點上面應用也將低效運作，這種重定向流量也會使用SMB協議傳輸。

針對于元數據交互和重定向IO，2012開始SMB引入多通道機制，群集會挑選網絡度量值最低的作為CSV流量，兩個相近度量值得網絡會通過SMB多通道執行，默認情況下僅群集通信網絡度量值最低，度量值得數字評定2012開始也和網卡是否支持RDMA,RSS有關，管理員也可以手動指定網絡度量值，CSV流量可以利用SMB多通道和SMB RDMA等技術。

以上為官方的說法，那么如果群集沒有CSV，沒有使用文件共享見證，也不提供文件共享服務，是否就可以關閉SMB端口了呢，因為去年病毒鬧得好多公司安全部門提出關閉445端口的需求，那么群集這邊是否可以支持，老王做了個嘗試，當前群集無CSV，沒有使用文件共享見證，也不提供文件共享服務，老王直接禁用掉SMB服務

關閉方法

1、運行regedit打開注冊表

2、依次依次點擊注冊表選項”HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\NetBT\Parameters

3、在右邊空白處右擊新建“QWORD（64位）值”，然后重命名為“SMBDeviceEnabled”，再把這個子鍵的值改為0

4、禁用系統Server服務

5、重啟電腦 SMB 445端口不再偵聽

配置完成后雖然群集可以正常啟動，但可以看到工作已經很不正常，例如DTC應用無法聯機，查看日志提示DCOM無法連接到DTC VCO對象

事實上老王已經猜到可能會是這樣的結果，因為SMB協議運作多年，依賴它的服務眾多，例如此外CIFS，SMB，RPC，DFS，Netlogon等等，這種徹底關掉的方式還需要停止Server服務，很多依賴該服務的功能都將停止運作

另外官網沒說的還有兩點，其一，客戶端登陸到域的過程會從netlogon獲取開機登陸啟動腳本，如果由組策略下發，用戶也會從SYSVOL目錄去獲取組策略GPT，而這兩個目錄都是在域控上面的共享目錄，用戶勢必要通過SMB協議去訪問，如果禁止SMB，則新的組策略下發將不正常

其二，老王發現過一個有意思的事情，群集節點net share除了可以看到默認C盤會共享外，如果自身有見證磁盤，也會把見證磁盤進行共享，群集不會無緣無故設計成這樣，雖然我們關閉SMB之后，群集可以正常啟動，但見證磁盤不再共享，老王猜想還是會對群集產生一些影響。

總結來看如果要關閉SMB端口，首先確保群集沒有應用CSV，其二可能承擔無法應用組策略風險，其三上層應用可能會不正常工作，具體還要根據不同的群集應用進行測試，只有確保肯定不依賴于SMB，Server服務的應用才可以正常工作

還有一種途徑即更改群集的SMB端口，網上有已經寫好的修改SMB端口教程，但是按照網上的方式修改后，所有要和群集節點通信的設備必須也將SMB端口改為和群集端口一致，我舉個例子，例如SQL群集把SMB端口改為555，那么需要和AD下載組策略把，但是DC默認是445端口，所以也需要把DC的SMB端口修改為555，連SQL的應用也要修改SMB端口為555，如果是后端SOFS群集改SMB端口，則前端HV也要修改，如此一來未免過于麻煩，如果在沒有域的單機環境下，修改SMB端口以維持SMB協議也許可行，但是在域環境下涉及到牽一發動全身的問題。

因此在老王看來，WSFC，AD，SMB這三個組件相結合的非常緊密，關閉端口或者修改SMB端口目前看來都不是最佳的方案，還是要從物理架構和安全策略調整，例如為核心數據庫應用構建在DMZ區域，與其他服務器通過防火墻嚴格控制通信，更新病毒補丁等層面進行處理。