在部署AD域信任关系前先来理解域信任关系是个什么玩意
在同一个域内，成员服务器根据Active Directory中的用户账号，可以很容易地把资源分配给域内的用户。但一个域的作用范围毕竟有限，有些企业会用到多个域，那么在多域环境下，我们该如何进行资源的跨域分配呢？也就是说，我们该如何把A域的资源分配给B域的用户呢？一般来说，我们有两种选择，一种是使用镜像账户。也就是说，我们可以在A域和B域内各自创建一个用户名和口令都完全相同的用户账户，然后在B域把资源分配给这个账户后，A域内的镜像账户就可以访问B域内的资源了。
镜像账户的方法显然不是一个好的选择，至少账户的重复建设就很让管理员头疼。资源跨域分配的主流方法还是创建域信任关系，在两个域之间创建了信任关系后，资源的跨域分配就非常容易了。域信任关系是有方向性的，如果A域信任B域，那么A域的资源可以分配给B域的用户；但B域的资源并不能分配给A域的用户，如果想达到这个目的，需要让B域信任A域才可以。
如果A域信任了B域，那么A域的域控制器将把B域的用户账号复制到自己的Active Directory中，这样A域内的资源就可以分配给B域的用户了。从这个过程来看，A域信任B域首先需要征得B域的同意，因为A域信任B域需要先从B域索取资源。这点和我们习惯性的理解不同，信任关系的主动权掌握在被信任域手中而不是信任域。
A域信任B域，意味着A域的资源有分配给B域用户的可能性，但并非必然性！如果不进行资源分配，B域的用户无法获得任何资源！有些朋友误以为只要两个域之间存在信任关系，被信任域的用户就一定可以无条件地获得信任域内的所有资源，这个理解是错误的。之前时在一家港资企业担任网络管理工作，企业的香港公司是一个域，深圳公司也是一个域。有一次我们需要把两家公司的Exchange服务器进行站点连接，这个操作需要两个域建立信任关系，但当时一位老工程师坚决不同意建立信任关系。他的理由是只要建立信任关系，香港公司的资料就全被深圳公司的员工看到了。这个理由很山寨，很明显对域信任关系的理解有些是是而非。我通过一个实验纠正了他的错误概念，事实证明，深圳公司和香港公司建立了域信任关系后，安全性并没有因此降低。
在NT4的域时代，信任关系是不具有传递性的。也就是说如果A域信任B域，B域信任C域，那么A域和C域没有任何关系。如果信任关系有传递性，那么我们就可以推导出A域是信任C域的。信任关系没有传递性极大地降低了灵活性，你可以想象一下如果70个域都要建立完全信任关系，那么需要多么大的工作量。而且这种牺牲灵活性的做法也没有获得安全上的补偿，因此微软在Win2000发布时，允许在域树和域林内进行信任关系的传递，在Win2003中更是允许在域林之间进行信任关系的传递。
工作中遇到的问题
在同一个域内，成员服务器根据Active Directory中的用户账号，可以很容易地把资源分配给域内的用户。
但一个域的作用范围毕竟有限，有些企业会用到多个域，那么在多域环境下，我们该如何进行资源的跨域分配呢？
解决方法
１.镜像账户
如何把A域的资源分配给B域的用户呢？
方法：在A域和B域内各自创建一个用户名和口令都完全相同的用户账户，然后在B域把资源分配给这个账户后，A域内的镜像账户就可以访问B域内的资源了。
存在问题：账户的重复建设等
2.创建域信任关系 具体建立方法参考Windows域信任关系建立
1.域信任关系是有方向性的，如果A域信任B域，那么A域的资源可以分配给B域的用户；但B域的资源并不能分配给A域的用户，如果想达到这个目的，需要让B域信任A域才可以。 2.如果A域信任了B域，那么A域的域控制器将把B域的用户账号复制到自己的Active Directory中，这样A域内的资源就可以分配给B域的用户了。从这个过程来看，A域信任B域首先需要征得B域的同意，因为A域信任B域需要先从B域索取资源。
域信任关系
域的信任关系的主动权掌握在被信任域手中而不是信任域。
A域信任B域，意味着A域的资源有分配给B域用户的可能性，但并非必然性！如果不进行资源分配，B域的用户无法获得任何资源！
NT4到Windows2000的域关系的转变
NT4的域时代
信任关系是不具有传递性的。
也就是说如果A域信任B域，B域信任C域，那么A域和C域没有任何关系。
Windows2000之后
允许在域树和域林内进行信任关系的传递
在Win2003中更是允许在域林之间进行信任关系的传递。
域树
域树针对以上问题进行了很好的解决，域树的父域和子域之间由于使用了层次分明的DNS域名，只要根据域名我们就可以判断出两个域的隶属关系，例如有两个域abc.com和test.abc.com，我们可以很轻易地判断出后者是前者的子域。
域树在信任关系上也有很好的改进，域树内的各个域之间会自动建立起双向可传递的信任关系，显然这是一个效率上的重大改进。
AD域组策略
概念
组策略是一个允许执行针对用户或计算机进行配置的基础架构。 其实通俗地说，组策略和注册表类似，是一项可以修改用户或计算机设置的技术。
组策略和注册表的区别
- 注册表只能针对一个用户或一台计算机进行设置
- 组策略却可以针对多个用户和多台计算机进行设置。
举例: 在一个拥有1000用户的企业中，如果我们用注册表来进行配置，我们可能需要在1000台计算机上分别修改注册表。但如果改用组策略，那只要创建好组策略，然后通过一个合适的级别部署到1000台计算机上就可以了。
组策略和Active Directory结合使用，可以部署在OU，站点和域的级别上，当然也可以部署在本地计算机上，但部署在本地计算机并不能使用组策略中的全部功能，只有和Active Directory配合，组策略才可以发挥出全部潜力。 组策略部署在不同级别的优先级是不同的，本地计算机<站点<域<OU。 我们可以根据管理任务，为组策略选择合适的部署级别。
什么是组策略对象？
组策略是通过“组策略对象（GPO）”来设定的，只要将GPO连接到指定的站点、域或OU、该GPO内的设定值就会影响到该站点，域或OU内的所有用户于计算机。
组策略存储位置
- 链接GPO的Active Directory容器
- 域控制器上的Sysvol文件夹
组策略对象GPO的组成
- 组策略容器(GPC)
GPC包含GPO的属性信息，
存储在域中每台域控制器活动目录中 - 组策略模板(GPT)
GPT 包含GPO 的数据，
存储在Sysvol 的 /Policies 子目录下
组策略管理
组策略管理可以通过组策略编辑器和组策略管理控制台（GPMC）
组策略编辑器是Windows操作系统中自带的组策略管理工具，可以修改GPO中的设置。 GPMC则是功能更强大的组策略编辑工具，GPMC可以创建，管理，部署GPO，最新的GPMC可以从微软网站下载。
组策略应用
-
帐户策略的设定
例如设定用户密码的长度、复杂度、使用的期限，帐号锁定策略等。 -
本地策略的设定
例如审核策略的设定、用户权限的指派、安全性的设定
3.部署软件
思路 1.把要部署的软件存储在文件服务器的共享文件夹中 2.然后通过组策略告知用户用户或计算机，某某服务器的某某文件夹有要安装的软件，赶紧去下载安装。 3.设置好组策略，就可以等待客户机自动进行软件安装了，完全不用在客户机上一一进行部署了。