DNS专题(7)---动态DNS和活动目录③

领测软件测试网

　　 
　　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通信的技术来保证安全。
　　(未完待续)

文章来源于领测软件测试网 https://www.ltesting.net/