WSFC AD权限规划
长久以来老王一直发现一个问题，似乎有很多人对于WSFC群集的权限存在一些误解，以为只有域administrator才可以装，或者要Domain admins才可以装
其实WSFC的安装并不需要那么大的权限，在本文中老王将为大家分享WSFC AD权限规划，我们将尽可能采用最小化权限的原则来进行设计。
主要围绕两种场景
1.最小化权限
2.预先置备CNO
之前博客中也曾经和大家提到过群集的创建过程，以WSFC 2012时代之后为例，当我们输入群集名称后，群集会使用我们当前的执行账号去AD里面创建CNO对象，去DNS中创建CNO DNS记录，默认情况下AD里面的普通用户也可以去DNS中注册记录，所以对于CNO的DNS记录我们不用Care，我们需要关心的就是CNO的权限与VCO的权限。
首先创建一个群集用户cluadmin 权限默认
将该账户通过组策略下发也好或手动添加也好加入到群集各节点本地管理员组
这是第一个要添加的权限因为执行创建群集向导必须要本地管理员权限才可以
第一步做完之后我们接着来思考，既然你创建群集向导要连到AD创建CNO，那么肯定是需要对AD有写入权限吧，这个写入的权限其实并不需要直接给赋予domain admins 或enterprise admins那么大的权限，群集管理账户或群集管理账户组只需要对于OU具备 创建计算机对象 及 读取所有属性 权限即可创建CNO对象完成需要的工作。
在2008时代创建CNO默认只会在默认计算机OU生成，WSFC 2012时×××始默认情况下将跟随节点，在群集节点计算机对象所在OU创建CNO，我们也可以在创建群集过程中指定要把CNO创建到具体哪个OU下面，后面老王会为大家演示。
打开ADUC -> 选定CNO要被生成在的OU -> 属性 -> 安全
添加cluadmin 赋予 创建计算机对象 及 读取所有属性权限
到这里对于我们创建CNO对象的最小权限设计就已经完成了，这就是创建群集这一步所需要的权限，现在我们在群集节点上使用cluadmin用户登录就可以在指定的OU下面创建CNO
可以看到在WSFC 2012之后支持创建群集CNO在指定OU下
创建完成后可以正常看到CNO及DNS记录
事件管理器中可以看到并无报错，群集得到了正常的生成
到这里我们使用最小化权限完成了WSFC群集的搭建
那么下一步我们需要在WSFC上面跑应用创建VCO，之前我们说过VCO的创建管理是由CNO来负责，那么我们还需要在OU上面赋予CNO计算机账户创建VCO的权限。
同样CNO只需要对于OU的 创建计算机对象 及 读取所有属性权限，因为从2012开始VCO默认和CNO创建在相同OU下，所以我们只要对CNO所在OU赋予CNO的权限即可。
除了AD外VCO还需要DNS记录，VCO的DNS记录也是由CNO负责创建维护，因此需要确保CNO计算机账户对于DNS区域有 修改权限 创建权限，删除权限可选，如不选择到时可能需手动清理CNO DNS记录。
赋予完成CNO的OU权限和DNS权限后，下面创建VCO发现已经可以正常写入AD和DNS
到这里我们就通过了最小化的权限来成功的创建了群集并且完成了群集上层的应用搭建，这就是群集创建起来所需要的所有权限 That's it That's all
让我们来总结下
对于群集创建账户要求是各节点本地管理组成员
创建计算机对象 及 读取所有属性权限
群集CNO对于所在OU具备创建计算机对象 及 读取所有属性权限
群集CNO对于DNS区域具备创建记录修改记录权限
CNO对象对VCO对象需具备重设密码权限默认情况下通过CNO创建的VCO具备该权限
今后您再创建群集不再需要每次都使用administrator或domain admins，您可以通过这样权限更小的账号来完成创建群集的工作。
不过这种模式虽然安全了一点 但也有它随之带来的麻烦即AD管理员需要为群集赋予权限两次
赋予创建群集的用户权限
群集创建完成后赋予CNO权限
这里的关键在于，一旦我们选择了这种模型就代表了AD管理员信赖群集管理员把群集创建的工作交给了群集管理员完成，我可以给它这样低的权限，它也可以完成工作，这很好，对于AD管理员来说这比以前让他们使用administrator好多了，但是每次需要赋予两次权限这个或多或少都有一点麻烦，因为第二步CNO对象的权限赋予 只有在创建完成群集后才能产生CNO
所以~ 除了这种传统方式外我们还有预置群集计算机账号的方式
传统方式下是由AD管理员赋予个权限然后让群集管理员连到AD创建
通过预置我们可以事先就在AD里面创建好CNO对象
例如，群集管理员把要建立的群集名称告诉AD管理员，AD管理员事先在某个规划好的OU下面创建CNO计算机对象 并禁用。
之后群集管理员创建群集时，直接连接到AD，自动激活启用事先创建好的CNO对象。
AD管理员也可以事先就把CNO创建VCO的OU权限赋予好，因为CNO已经预置好了，这样只需要赋予一次权限就可以了，也更加省事。
这种预置方案特别适合那些对于创建变更要求严格的地方，要求一切都按照事先规划好的完成，那么预置是最好的选择了。
通过预置也减少了群集管理员误操作的风险，一切都使用事先规划好的对象
如果我们通过预置方案甚至可以不必为cluadmin授予创建计算机的权限，因为创建计算机的操作会事先由AD管理员进行。
预置CNO对象操作步骤
AD管理员按照 群集管理员 告知的名称 创建计算机对象 并禁用
点击计算机对象->属性->安全赋予cluadmin账户对于CNO对象具备完全控制权限
如果接下来群集还需要创建VCO对象，那么您有两种方案可以选择
手动赋予CNO对象对于所在OU具备 创建计算机对象 及 读取所有属性权限，应用于范围此对象"和"所有后代"
预置VCO对象
由于手动赋予权限的办法我们上面已经做过，所以这里不再演示，唯一区别在于如果不预置，我们需要等待创建完成群集后，再次赋予CNO创建VCO的权限，使用预置我们可以直接一次做掉交付给群集管理员。
预置VCO对象操作步骤
创建VCO计算机对象并禁用
赋予CNO计算机对象对于VCO计算机对象具备完全控制权限
赋予CNO对象对于DNS区域具备修改及创建权限
按照规划好的名称创建群集
检测到使用的cluadmin账户已经赋予对目标CNO对象具备完全控制权限，自动联机激活之前已被创建好的禁用CNO计算机账户
DNS记录也已经得到正确注册
按照事先规划好的名称创建DTC VCO对象
群集检测到当前VCO对象存在 且CNO对象对于VCO对象具备权限 将自动联机启动预置VCO对象
VCO DNS记录也得到正确创建
回顾一下WSFC传统AD模型的权限需求
创建群集的执行账户要求是各节点本地管理员
创建群集的账户需要对目标OU具备创建计算机对象 及 读取所有属性权限
创建VCO的CNO对象需要对所在OU具备创建计算机对象 及 读取所有属性权限
创建VCO的CNO对象需要对DNS区域具备创建修改权限
确认CNO对象对VCO对象具备重设密码权限默认情况下通过CNO创建的VCO具备
只要满足这五个条件，我们就可以创建一个正常的AD依赖群集及上层应用。
如果采用预置对象的方案，我们可以不用授予创建群集执行账户权限与CNO对于OU的权限，直接赋予创建群集执行账户具备CNO完全控制权限，授予CNO对于VCO具备完全控制权限即可，DNS区域权限仍需赋予但使用预置对象方案让WSFC AD权限对象更加合规化
以上为老王实际验证而得对于传统WSFC群集AD权限的需求处理，以及如何使用最小化权限实现WSFC权限需求，希望能够为感兴趣的朋友带来收获
