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区域，与其他服务器通过防火墙严格控制通信，更新病毒补丁等层面进行处理。