明明白白AdminSDHolder对象

你是否遇到过在活动目录（AD）对象上面已经设置好了各种权限，然而不久以后那些权限就神秘地消失不见了？大多数在AD方面做支持的系统管理员都会对这样的经历感到棘手。那么它是由什么导致形成的呢？网络中有“鬼”吗？系统管理员不负责任吗？实际上，它更可能是由于AdminSDHolder对象造成的。AdminSDHolder是一个很少为人知道的功能，在AD中用于保护与系统安全相关特定的特权组对象和用户对象。我们将要研究AdminSDHolder并且教会你如何来改变它的行为并避免这个缺陷。

问题示例
为了举例说明，让我们拿一个AdminSDHolder对象起作用的简单例子来做讲解。Joe从事IT终端服务工作并且是Service Desk组的成员。其被委派的权限为重新设置名字叫Wellington Users的组织单元（OU）中所有用户的密码。当Joe试图改变用户James Smith的密码时，他收到了一条“Access is Denied（拒绝访问）”的错误提示。经过适当的技术思考，Joe打开管理控制台（MMC）中的“活动目录用户和计算机”管理单元来比较James Smith的安全设置，如图1所示。图2显示的是可以正常进行密码重置的Don Murphy的安全设置。

图1：James Smith的AD安全设置

图2：Don Murphy的AD安全设置

在Don Murphy的安全设置中，Joe看见Service Desk组有重设密码的权限。对比James Smith的安全设置，这个权限就不存在。同时也显示了权限的继承是未进行的。这样的现象看起来有些奇怪，Joe请求一位AD系统管理员把James Smith的安全设置按照Don Murphy进行更改。Joe稍后收到来自AD系统管理员的通知，告之James Smith的安全设置已经按照需求进行了更改。Joe再尝试重新设置James Smith的密码，又一次感受到了挫折，仍旧收到了“Access is Denied（拒绝访问）”的错误提示。他气冲冲的喊来那名系统管理员，管理员告诉他已经真正的按照Joe的需求重新设置了James Smith的安全权限。那么究竟发生了什么呢？
Joe进一步的检查James Smith的账号，结果显示出他是Domain Admins组的成员。出自于系统安全原因，AD会保护特定的几个组和用户的特权。其中就包括Domain Admins组。表1列出了这些组和用户。保护措施也拓展到了这些组的所有成员，嵌套组的成员。在我们的例子中，Joe有权力来重置一个属于Domain Admins组成员的账号密码是不安全的。因为这样他能很容易的使用他自己的账号在Domain Admins组中创建一个属于他自己的成员，他可以创建一个新的账号来提高他的权限或者进行类似的操作。从安全的观点来看，适当的保护一下内置的对象是很有意义的。

什么是AdminSDHolder？
许多人往往使用术语“AdminSDHolder”来指AD保护有特权的组和用户对象的方法。但是，它不只是一个AD对象的名称。AdminSDHolder对象是一个容器对象，在域地址目录用CN=AdminSDHolder，CN=System，<Domain DN>划分——例如，CN=AdminSDHolder，CN=System，DC=north，DC=com.
AdminSDHolder作为对象本身，它并没有任何特殊性，但是他会担当一个受限制对象安全描述信息的位置标志符。图3显示了一个AdminSDHolder对象的安全描述信息的例子。每个小时，后台的SAM任务会在域控制器上运行，保存着主域控制器模拟器的单主机操作任务（FSMO）。这个任务是这样的，在其中，负责检查被保护的组和用户对象的安全描述信息与那些AdminSDHolder对象是否匹配。如果描述信息不同，AdminSDHolder任务会使用AdminSDHolder的安全描述信息覆盖那些在设置上有问题的组和用户对象的权限。在我们早先的例子中，AdminSDHolder任务就取代了AD管理员，重新设置了James Smith账户继承权限。当然这样的安全设置管理分析起来就比较混乱了。

图3：AdminSDHolder安全描述信息

AdminSDHolder任务也会设置用户或者组的adminCount属性，会由<Not Set>设置为“1”。图4显示了通过ADSI Edit tool浏览James Smith属性的例子。

图4：James Smith的属性浏览

你可以用AdminSDHolder对象来改变安全描述信息的关联，虽然我不建议这样做。谨记，这个改变会更新较新的安全描述信息到所有的被保护的用户和组。所以不要轻易的做出那样的改变；一个计划不周全的配置会给你的AD环境带来损害。例如，在AdminSDHolder对象中指派Domain Users组“完全控制”权限将会帮助域中的任何成员潜在的提升他们的组中的成员到Domain Admins。

避免安全描述信息的重置
作为一个最好的实践练习，我建议你不要使组成员用户的标准账户被AdminSDHolder对象保护。“标准”的账户——我的解释是那些有代表性的用户，用于每天从工作站登录到域环境中进行工作的账户，例如创建Word办公文档或者Email工作者。如果一个用户需要执行管理的任务，分配这个用户另一个账户达到他的目的就可以了。通过这样做，你就可以避免像我在文章开头描述的那种情况的发生。让我们来补救开头提到的问题，你可以分配James Smith一个额外的账户用于管理目的，使他的新账户成为Domain Admins组的一个成员并且把这个账户放置在一个独立的，Service Desk组不能授权修改权限的OU中。

改变AdminSDHolder的计划任务
依照你的环境，你可以决定通过更频繁的运行AdminSDHolder任务来提高安全机制。你可以通过改变注册表来做到这点，如下所示（注意，改变注册表通常都会有警告提示的）：
1．查找HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\Services\NTDS\ Parameters子键
2．如果这个子键不存在，增加一个新的“DWORD”值，命名为“AdminSDProtectFrequency”并且设置这个值。（数字，以秒为单位）取值的范围是最小一分钟（60秒），最大120分钟（7200秒）。
你应该意识到AdminSDHolder任务是非常耗费系统资源的，因此在你决定改变默认设置前应该仔细考虑清楚。我已经注意到当AdminSDHolder任务在主域控制器（PDC）上运行的时候CPU的占用率往往会达到峰值。也注意到你是不能强迫AdminSDHolder任务手动运行的，这两点请注意。

从被保护的组中移除账户
在典型的AD环境中，管理员都是有规律的在被保护的组中增加和移除账户。例如，一个账户可能临时需求提高权限来执行特别的任务。在这个例子中，AdminSDHolder任务应用安全描述信息关联这个AdminSDHolder对象——但是，当这个账户被从保护的组中移除的时候并不会恢复到之前的安全描述信息。另外，AdminSDHolder任务也不能将数值改变为“1”的adminCount属性移除。我的看法是，我们只能接受这个并非是理想的结果，因为它发生在一个安全描述信息之后，这样的安全信息描述权限继承被禁止并且产生一个adminCount属性的数值。如果用于LDAP的需求方面这样就会产生潜在的混乱。我真的希望发生了AdminSDHolder任务后它自己可以做精确整理工作——将adminCoun健值移除。但是，遗憾的是，对于当前所有的Windows版本而言，这只是种奢求。

做好AdminSDHolder任务更改对象的确认工作
大部分通常有效的确定账户和组是否已经被AdminSDHolder任务更改的方法就是在DC的主域控制器模拟器中看登录的安全日志，在“账户管理审计”中查找“事件 ID 684”的键值。图5显示了那样的一个日志键值 。注意你必须首先启动“账户管理审计”才能使系统记录需求的事件。

图5：Event ID 684安全事件日志示例

还有一个可供选择的方法，你能查询安全描述信息传播（SDPROP）组织的记录。AdminSDHolder任务和SDPROP是互不相干的，但是无论何时一个安全描述信息（SD）更新出现的时候，SDPROP都会试图改变子对象的属性。换言之，SDPROP报告的事件会给出对象是否被AdminSDHolder任务改变的提示，仍旧要明确，SDPROP还会潜在的记录其他信息，这些都是互不相干的。
SDPROP不会在目录服务（DS）事件日志中记录报告的事件，除非你在默认状态提升诊断日志的等级。要启动SDPROP报告的事件，要再一次在DC的主域控制器模拟器中设置Internal Processing的键值从“9”到“5（数字）”注册表的位置在：HKEY_ LOCAL_MACHINE\SYSTEM\CurrentControl Set\Services\NTDS\Diagnostics。当你已经启动提升了日志等级后，就可以在DS事件日志中找到事件为IDs 1257和1258的事件，他们都会在目标源中标有NTDS SDPROP。事件将会包含被SDPROP更新的对象名称。注意一点，提升日志等级会产生大量的日志事件，因此你应该仅仅在针对一个特殊问题的进行排错时这样做，当你完成了排错工作后最好再次降低日志的等级。
第三种方法就是在adminCount属性健值为“1”的域中，对所有的对象发布一个LDAP请求。然而，这个方法也是不可靠，不准确的，原因我已经说过了——那就是事实上当对象不再属于一个保护组的成员时AdminSDHolder任务不会移除adminCount属性的健值。在下面的例子中，我使用ADFind（来自joeware .net的一个非常好的基于命令行的免费工具，可以在http://www.joeware.net下载到它）来运行LDAP查询。查询会寻找默认分区目录（域分区）并且会返回所有的adminCount属性健值为“1”的用户对象。（查询语句显示到了多行，这是因为显示空间的限制，但是你应该在一行中输入它，而不要手动换行。）
adfind -default -f "(&(objectClass=user)
  (objectCategory=Person)(adminCount=1))"

消除缺陷
AdminSDHolde任务起到了杠杆的作用，安全描述信息关联了AdminSDHolder容器对象来保护特定的几个AD对象来避免损害。虽然这个功能对于安全方面是必需的，但是它会为系统管理员们在某些授权方案中带来混乱。理解AdminSDHolder的行为能帮助系统管理员避免这些缺陷并且也能在疑难解答中获取帮助。你也可以通过做一些实践工作来预先记录下一些共通的问题，这样会更好地为一些次级授权账户提供管理目的的需求。