访问控制层安全设置 对于DNS管理来说使用windows DNS进行安全更新的真正的问题在于LDAP协议对于DNS记录更新的成败必须理解windows 安全许可和所有权函数是如何规范的因为正是它们掌握着更新的成败如果理解了对于域区和域区数据的缺省设置是什么以及缺省是如何调节的就可能在缺省配置之外管理动态更新了这一节试图让这个问题变得尽量简单并且假设对前述内容有了一定的背景知识对windows 安全概念有大体的理解包括对访问控制列表和所有权的大致了解 缺省的Outofthebox配置使得授权用户组的任何成员在任何域区里创建记录如A记录或PTR记录当一个记录存在后它能被Everyone组里的任何一个成员访问但也许只能被最初创建者或者被不同类型的管理员或者被系统本身所修改在很多情况下这种改变和删除已存在目录的创建后限制提供了一个可取的行为但有些时候它又会带来问题和产生旧记录图显示了一个集成域区的缺省安全设置注意图给出了一个域区而不是一个资源记录 Everyone组是高亮度的表明了这个组被授予了特殊的配置允许位于它正上方的AuthenticatedUsers组表明了它被允许创建所有的子目标(这种情况下为资源记录)授予Everyone组的特权赋予域区本身的读取访问权包括列表权图显示了同一个域区使用DNS服务器管理控制器而不是图中的活动目录用户和计算机控制器图中编辑器打开指定给Everyone组的安全设置显示了细节通过任何一种管理器接口都能提供这种细节 在更深入地钻研这些之前注意一下图中命名为DNSAdmins的组这是一个在活动目录中预配置的组通过使一个一般用户成为这个组的一员一个管理员可以授予这个用户一个DNS管理员的许可如你猜想的一样一个DNSAdmins成员有足够的能力配置和运行在域控制器上永久驻留的所有DNS服务器上的DNS但是没有对其他特征的管理权除非这些特征通过其他组独立地被授予特权 因此上一段说的是任何能和DNS协商一个安全对话作为认可陈述(授权用户成员)的客户机都可以创建资源记录当一个非安全的更新被协商DNS服务器提供了一个更新的上下文图显示了对A记录缺省创建的安全保障表明了Everyone组被授权Read(读取)许可如果想再深入一点儿看的话如图所示可以找到相同的被授权的Read许可但这种情况下是对一个资源记录而言的 如以上所见应该指出的一点是授权用户可以在域区内创建对象尽管这样创建对象的类型会受到限制但如何进行创建却不受限制如果用户作为一个授权用户使用直接的LDAP方法仿佛就根本不用涉及到DNS服务器换句话说域中任何合法用户都能创建记录甚至可以直接创建 为了改变创建记录时对其授权的许可对活动目录容器和域区的可继承许可可以改变一般来说实际的需求非常复杂对原型或者说对被创建对象类型的对象类也有许可当在其中创建新的记录时这些许可也会被应用不论是对域区还是资源记录在outofthebox设置中模式类dnsZone和dnsNode对新创建的域区或资源记录都会提供授权许可图给出了用于资源记录的dnsNode类的缺省安全描述符dnsZone类是相似的此外它也对授权用户赋予许可去创建子对象 如果我们再深入地研究下去在图中(对一个资源记录)我们会发现Everyone的读取许可和图一模一样这是显然的因为图中的内容正是从图得来的此许可不是从域区ACL继承的并且对域区的ACL的大多数改变都不会影响Everyone组对域区里新的资记录的读取权利 那么迄今为止我们知道了些什么?一个协议定义了进行动态DNS更新时DNS服务器使用的安全上下文任何授权用户都能创建新记录Everyone组的每个成员都能读取一个记录也能列出一个域区在记录被创建以后它只能被管理员或系统或创建此记录的帐户来改变在包含的域区或dnsNode图表对象中对许可的操作可能改变新创建的资源记录的缺省许可最后详述一下如何预先确定由动态DNS产生新记录的安全ACL 任何没有明确提供ACL的新的活动目录对象被创建后它就得到一个ACL这个ACL包含着从它们的容器或从对象原型缺省的安全描述符继承的安全许可除非对它的容器至少有一项特别指定的许可当有指定的许可出现在容器中时原型的许可不被使用因此当创建新记录时不禁止从原型得到许可将得到dnsNode的许可加上记录被创建的域区的任何可用的继承许可下面看一下禁止使用原型许可的指定许可如果容器有任何指定给被创建对象类型的继承许可此类的原型的缺省安全描述符就不会被新对象接受新对象只接受从容器得到的继承许可所以如果域区有可继承的许可并且已经应用于资资源记录(dnsNode类的对象)域区里新的资源记录就只会接受域区里可继承的许可 由微软提供的目前的MSDN中的活动目录程序员指南以文档的方式指出了覆盖一个活动目录对象接受的它的类的缺省安全措施的方法但是因为在windows 的最初版本中管理员接口中不提供关键性的先决条件所以目前还不能禁止来自dnsNode和dnsZone的缺省安全措施不向域区或资源记录对象提供任何指定的许可如果禁止原型安全措施成为可能那么不论你是在想使用许可还是在不想使用时避免使用许可你都得清楚这一点这里有一个预防措施在一个域区被创建之后改变它的许可可以防止缺省的安全描述符(在dnsNode原型上的)被加到新的资源记录上去这也许被期望也许不被期望如果没有应用原型缺省的安全措施就必须保证包含域区中有可继承的许可以提供原型中缺省安全措施中被期望的部分(被禁止的)的 可以看到包含域区中的许可可控制新的被包含对象(资源记录)的安全措施这个控制必须很小心地完成并且有两个方面要考虑包含域区的可继承的许可和来自原型(dnsNode)的缺省许可没有提到的是改变对dnsNode原型的安全措施是一个影响活动目录中每个域的行为(例如假如Everyone的读取权太过头了)不仅仅是这样做还必须理解Everyone为什么赋予这个许可以及为什么在某种程度上它还很难被覆盖如果访问能被破坏的事实能被接受的话改变dnsNode的许可是完成像这样的改变的最简单的方法但是任何架构层的改变都不能轻易地被改变 在一个域区被创建以后加入能被创建任何子对象继承的许可会改变域区里将来会被创建的资源记录的许可因为dnsZone和dnsNode类规定Everyone组和授权用户组分别有读取域区数据和创建的许可正如前所示关于许可方面实在是没什么添加的了所以对原型安全措施的改变暗示着outofthebox设置不适合你的环境这又意味着对架构类改变的许可以及由原型或域区许可提供的期望部分的许可的完全理解 一些实验能使这变得容易理解如果微软或者是通过扩展的第三方使得一个合格的资源记录的指定权限ACE能被应用于域区那就什么事也没有了 从windows 的测试版到最终版一直采用用禁止应用架构类的缺省安全描述的方法然而有了黄金代码似乎有些东西已经改变了但还没有被规范成文档先前可选的一些对象类的例子现在已经不适用了因为安全是一个大问题而复杂性也不小很有可能提供修订信息和期望的方法就像实施windows 的网络环境一样需要从微软得到如何改变域区数据安全性的改进信息现在在这些被印刷前的最后时刻原型的缺省值需要被整理改变原型的缺省值到最不公用的权限集和当需要多于最不公用的权限集时对域区添加可继承的权限是一个可利用的手段对架构类的改变能够通过活动目录架构管理控制器(SCHMMGMTMSC)来完成的对域区的改变能够通过活动目录用户和计算机控制管理(DSAMSC)来实现或者通过DNS服务器管理控制台(DNSMGTMSC)来实现 现在再看一下DNS数据安全的另一方面审计图给出了设置一个域区创建的记录的缺省值以使它们是有审计功能 图中的复选框指出了什么行动会引发审计它们显示为灰色是因为这些设置是从更高层继承的当审计开始后这些设置会引起除了对记录的读取外所有的访问都会被写入一个审计记录 如果再回到图可以注意到对Everyone的读取权限用白色框来显示这是因为源于dnsZone类的权限直接应用于资源记录这表明如果想要改变以这种方式赋予的权限即没有使用继承那最好是在所有对象被创建之前就改变控制设置在对象存在以后改变并且是只改变这些权限就需要单独地访问每一个资源记录对象 (未完待续) |