动态DNS和活动目录（2）

　　7.3DNS域区的活动目录集成

　　听一下销售市场上的欢呼声就能让一个人相信活动目录是给所有事物带来好运的灵丹妙药。也许这听起来很夸张，但它的确很适时地带来了windows 2000 策略对动态更新的安全性。安全DNS动态更新规范（RFC2137）和动态更新规范一起出台，但是研究在继续，新的努力澄清了公共密钥加密术如何用于DNS。无论如何，微软已经选择了一项技术，用来保障动态DNS行为的安全，这个动态DNS行为支持对活动目录的适当的设计工作。查看附录B“与DNS相关的RFC”，草拟了一些建议。这些建议详述了发展早期GSS-API（RFC2078）编码的安全特性的步骤。

　　正如它所示的，域区数据的活动目录集成不仅仅提供了对上一节所讨论的与清洁度难题相对的安全问题的一个尽管不完美但却有用的解决方法，也提供了在交易中更深远的平衡点。

　　7.3.1它如何工作

　　域区数据集成到活动目录中的方法从某个角度来说是很简单的。域区数据仅仅传送到目录对象中去。域区里所有的东西都是一个对象，为了使用目录存储它们需要排序。在域区被集成后，在“活动目录用户与计算机”控制器（必须允许“Advanced”模式）里，只读模式下（指除了可写的安全描述符之处）它对管理员来说是可见的。控制台的“MicrosoftDNS”节点里列出了资源记录（如图7-2所示）。

　　为了实现集成，只用在服务器的属性里点击一个开关即可，这个开关如图11-4所示，在第11章中简要地讨论了从文件存储到活动目录存储的改变。使用域区“属性”对话框（见图11-7）里的“General”控件里的“change（改变）”按钮，可以改变个主域区的存储模式。第一个改变成活动目录存储的主域区会触发服务器属性的改变。除了管理员以外，没有任何其他办法能改变存储模式。

　　7.3.2激活的特征

　　在域区数据作为目录对象被存储以后，会有一些立竿见影的效果。一些是由活动目录的持续存储特性直接产生的，例如有了安全属性；有些是以活动目录的支持服务能使用的形式存在的数据的结果，例如复制技术。这个讨论简单回顾了这两种“被支持”的例外，同时也引出了对域区数据安全问题的相当长而复杂的解释，包括动态更新的安全保障及其缺省的设置。

　　7.3.3复制

　　活动目录使用多主设计使得对于它的大部分责任而言，任何DC（域控制器）同域里的其他DC是完全平等的。因为每台DC之间是相距很远的，所以一个潜在的通信在域区数据向存储在目录中的对象转化的传播中是固有的。在站点内，缺省安装将延迟限制在15分钟内；在站点之间，延迟通常是站点连接方式的函数。

　　这种潜在的通信意味着两台DC的更新也许会冲突，因为更新不是在分布式环境中执行，而是每台DC都认为它自己的数据是当前的，复制技术支持这种多主设计。复制技术采用一种“最后写胜”算法，此算法对冲突解析使用“结合切断”策略。本质是来说，是一个松散会合的紧密连接的系统，系统中的DC并不总是平等的，而在很多情况下它们仿佛是完全相同的克隆，带来了紧密连接。然而，因为独立的改变和复制算法，活动目录的内容是连续地会合的，因为任何特别的改变都可能回退，因而它是一个松散的会合。存储在活动目录中的任何东西通过这种技术自动地集成域区中的所有DC。因而，就象在标准的域区传送中一样，在活动目录集成域区中，有一段时期里，授权于同一个域区的两台不同的DNS服务器对此域区的查询也许会给出不同的回答。

　　7.3.4多主主服务器

　　因为所有的域区数据只是活动目录的内容（或在所有的DC里是复制的），所以大部分情况下对DNS服务器的改变很小是很自然的。结果是当域区数据集成到活动目录中后，DNS也运行在多主模式下。一个域区可能存在于多个平等的主DNS设置里，每台DC上都有这样的设置（因为只有DC包含活动目录）。

　　这对于标准的辅服务器来说也是可能的，只不过是有多个主服务器。当然，这些主服务器按某种规则指定了一个服务器为“主”服务器。例如，别人是如何知道主服务器的？或者在清理时，如果所有的DNS服务器都删除旧记录的话，将是愚蠢而无效的（除非它们分担了任务）。所以哪台服务器最初开始删除并将它传播到其他的服务器？

　　与可获得信息相比，一些类似的问题是不成熟的，其他问题诸如清理的发起者问题是在内部由注册表设置管理的。可以说对DNS采用活动目录存储能够获得多主域区。主要的结果是消除了标准DNS体系结构的易攻击性（主服务器是唯一的失败）。假如辅服务器配置为使用多个根主域名服务器，将让域区的所有DC上的DNS服务继续拒绝域中有过期域区数据的辅服务器。更深远的好处是必须在域中主DNS服务器上进行的动态更新，不需要传授到单个的，有时又很远的机器。

　　7.3.5安全问题

　　在谈论这个话题之前，先回忆一下，除非DNS域区是活动目录集成的，否则windows 2000 对动态更新不提供安全保障。一般说来，动态DNS更新的安全问题在任何环境下都是一个相当复杂的事情。对在windows 2000 接口中被称为安全动态更新能力的实现及使用也是同样的。目标是控制谁或什么机器允许向DNS注册或修改和删除已存在的注册。

　　7.3.6安全的动态DNS过程

　　windows 2000 客户机使用一个协议向DNS服务器建立了一个安全的上下文，转而在DNS服务器试图向DNS数据库写入时也使用这个安全上下文。客户机通过使用TKEY交换来建立这个安全上下文。TKEY交换试图使用Kerberos作为安全保障的提供者。如果成功的话，实际是使用TSIG来向DNS服务器发送已标记的更新请求，以及答复客户机。DNS服务器本身基于已建立的安全上下文使用LDAP协议来进行更新。

　　windows 2000 客户机可以被配置为总是尝试无保障的更新，或总是尝试有保障的更新，或首先尝试无保障更新，然后有必要的话，再尝试有保障的更新。最后一个是缺省配置，缺省配置的动态更新在逻辑上遵循以下步骤：

　　1)客户机尝试无保障的更新。

　　2)如果未成功，客户机协商一个安全方法。

　　3)在同意使用Kerberos作为安全保障提供者后，客户机向它的DNS服务器建立它的“资格证书”。

　　4)客户机使用这个资格证书请求更新。

　　5)DNS服务器模仿客户机使用这个资格证书建立一个LDAP对话。

　　6)DNS服务器使用LDAP方法向DNS数据尝试更新请求。

　　TSIG和TKEY在RFC中找不到TSIG和TKEY，但是可以参考草案“draft-skwan-gss-tsig-0.txt”，RFC2078中指出了它们关系，RFC2535指出了它们的区别。附录B提供了RFC的参考。

　　具体细节更为复杂，包括更新请求的标记和提供授权的返回结果。有意思的是Kerberos作为安全保障提供者的使用，以及DNS服务器使用通常的LDAP方法更新活动目录。DNS服务器作为客户机来执行LDAP更新，允许存在的活动目录安全机制使用适于客户机的安全机制。

　　因为windows 客户机希望使用这种安全的动态更新的方法，它们只能向windows 2000 DNS服务器协商安全的动态DNS更新。如果使用其他的DNS服务来支持windows 2000 ，很有可能你不能得到支持这种安全动态更新方法的DNS服务器。在windows 2000 的最初版本中不提供对客户机配置与RFC2137和RFC2535兼容的方法。不使用windows 2000 DNS服务器的动态DNS，暂时意味着在更新过程中不能保证更新安全但在更新过程之外可以使用诸如IPSec通信的技术来保证安全。

　　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类的权限直接应用于资源记录。这表明如果想要改变以这种方式赋予的权限，即没有使用继承，那最好是在所有对象被创建之前就改变控制设置。在对象存在以后，改变并且是只改变这些权限，就需要单独地访问每一个资源记录对象。