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