第07章域的组织和管理.docx
《第07章域的组织和管理.docx》由会员分享，可在线阅读，更多相关《第07章域的组织和管理.docx（15页珍藏版）》请在冰豆网上搜索。
第07章域的组织和管理
域的组织和管理
概述
当我们完成了域的建立工作后，马上面临的就是如何去管理域。
因为在Windows2000中域作为一个分布式的大型信息库，里面的信息量是可能非常庞大的。
在这里，我们把这个工作分为两个部分，也可以认为是两个阶段，就是组织和管理。
组织的目的是让域中的信息变得整齐有序，然后才能顺利地完成对域的管理。
在域中，组织的工具是组织单元OrganizationalUnit，而管理的工具是控制授权DelegationofControl。
域的组织
进入一个域，就如同进入了一个档案库。
档案库绝对不会是乱作一团，必然有各种档案柜，档案架，档案夹等，将所有档案存放得整整齐齐。
我们当然需要我们的域也是一样的有条理，否则肯定无法有良好的管理。
域的组织，实际上就是对域中的对象的组织。
域中的对象
当我们完成了域的建立工作以后，就可以开始管理域中的对象了。
我们使用的是ActiveDirectoryUsersandComputers管理工具。
打开这个管理工具，我们看到是一个象硬盘的资源管理器的一样的画面，里面已经有了很多东西。
这些东西都是存放在域数据库中的对象。
我们可以在其中点击鼠标右键，选择New，就可以看到我们能够在域中创建的对象的种类。
这些对象有：
♦Computer加入到域中的使用Windows2000/NT的计算机都有相应着一个帐号，这个对象就在AD的数据库中代表了这些计算机
♦Contact相当于一种记录个人信息的名片
♦Group某类用户的组织
♦OrganizationalUnitAD中的容器对象
♦Printer在AD中发布的打印机
♦User用户对象，代表域中的用户
♦SharedFolder在AD中发布的共享文件夹
这些都是ActiveDirectory中定义的对象类型。
当然AD提供了完善的可扩展性，用户可以建立自己的对象。
其他的一些服务，如ExchangeServer2000,ISAServer2000等，都会在AD中建立自己的对象。
对象的组织
一个域可以是一个庞大的数据库，其中包含了大量各种类型的对象，包括用户、组、计算机、打印机等内置类型的对象，也可以包括用户自己定义的对象。
这么多的对象聚在一起，如果没有一个合理的存放方式，就好像没有文件柜和文件架的档案库，可以想象你根本无法找到你所需要的档案。
如何存放和组织这数量庞大的对象呢？
在计算机中，有一种存放东西的方法是我们非常熟悉的。
在我们的硬盘分区中，同样存放了大量的档案，也就是各种文件。
我们用什么来组织这些文件呢？
用的是树型结构的文件夹和子文件夹。
文件系统结构
对于域中的对象，采用了同样的结构来组织，即树型的对象容器和子容器，相当于文件系统中的文件夹和子文件夹。
这种结构能够清楚地分类和存放各种档案，并且最重要的是，这种方式是我们非常熟悉和能够有效使用的方式，因为我们都习惯了用这种方式来组织我们的数量巨大的文件。
这对于提高工作的效率是非常有好处的。
域的组织结构
在文件系统中，组织的关键角色是文件夹，在域中，组织的关键角色就是组织单位——OrganizationalUnit,简称为OU。
OU的特性
如果我们将整个ActiveDirectory的数据库看成是一个硬盘分区，那么OU就是这个分区上的文件夹。
所以OU和文件夹是非常相似的。
OU是ActiveDirectory中的容器（Container）对象。
所谓容器对象，就是说其他的对象可以放在这个对象中。
例如在AD中我们建立了一个用户（User）对象，起名叫Mike，这个对象就代表了域中的一个人。
作为一个域中的对象，他必须被放在某个地方，这个地方就是一个容器。
客气一点讲，我们可以说这是这个人住的房间。
一旦我们把这个人安排在了指定的房间，他就不可能出现在其他房间中了。
其他的对象也是一样的。
所以对域中的任何一个对象，都必须位于一个指定的容器当中。
如果系统管理员将某个对象移动到了另一个容器，则你在原来的容器中就看不到这个对象了。
OU和文件夹的对比
为了进一步加深对OU的理解，我们将OU和文件夹做一个对比：
♦他们都是各自系统中（ActiveDirectory和文件系统）的容器，可以在里面放置其它对象
♦他们都可以建立树形的结构，文件夹中可以包含子文件夹，OU中可以包含子OU
♦他们都是用来组织各自系统中的对象
♦他们都是用类似的安全属性对自己及内部对象的访问进行控制
内置的容器
我们在提到ActiveDirectory中的容器时，并没有直接称容器为OU，因为在AD中，除了OU外，还存在着少数几个特殊的容器对象。
它们不是OU，但它们也是容器。
这些容器是ActiveDirectory中系统内置的容器对象，各自有特定的用途。
内置的容器对象主要有以下几个：
♦Builtin存放了一组内置的LocalGroup对象，如AdministratorsGroup,UsersGroup,GuestsGroup等
♦Computers存放所有加入到域中的计算机的Computer帐户对象
♦Users缺省存放所有用户对象的容器，内有一些内置的用户对象和域中的GlobalGroup对象，如DomainAdminsGroup,DomainUsersGroup,DomainGuestsGroup等
除了这几个内置容器以外，其他的容器就都是OU了。
一般情况下OU都是用户自己建立的，除了有一个OU。
这个OU的名字是DomainControllers，其中存放的是域中的所有域控制器DC的计算机帐户对象。
这个OU是在建立域的时候由系统自动建立的。
实际上在AD中还有一些隐藏的容器，平时看不见，但是当你在View菜单中选择AdvancedFeatures后，这些容器就会出现在域中。
♦LostAndFound某些系统无法处理的对象会移到此容器中
♦System存放所有系统对象的容器
建立OU
OU的建立和配置非常简单，操作如下：
1.打开ActiveDirectoryUsersandComputers
2.在域中或任何一个OU中，点击鼠标右键，选择OrganizationalUnit
3.输入OU的名字
域的管理
我们建立OrganizationalUnit的第一个目的，是为了将ActiveDirectory中的对象组织起来，就像面对一个巨大的档案库，你必须使用各种档案柜和档案袋一样，这样才能清楚地管理档案。
现在这第一个目的已经达到了，但是组织的下一个目标是什么呢？
是为了更好的管理。
和NTFS文件系统中的文件夹类似，OU也可以配置访问的权限（Permission）。
每个OU都有自己的访问控制列表（AccessControlList,ACL），其中记录了用户对此OU，对OU中的对象，以及继承到下级OU的各种权限。
管理实际上就是对访问权限的设置。
DelegationofControl
在AD中，管理OU的一个主要目的就是为了分权。
在一个很大的域中，如果让administrator一个人来做所有的维护工作是很困难的，工作量大必然会造成响应的延迟，降低工作效率。
OU的建立为解决这个问题提供了一个有效的方法。
例如，在公司中有一个比较大的部门是销售部门，由于人数较多，所以日常的管理工作也比较多。
这个部门有自己的IT支持人员。
在AD中，为这个部门建立了一个OU，名字叫SalesDepartment。
现在所谓控制授权（DelegationofControl）的意思就是要将对于SalesDepartmentOU的管理工作交给这个部门自己的IT人员，这样在这个OU中建立新的用户，修改和删除用户信息，建立和管理其它对象等工作，包括邮箱的建立，都可以由这个人完成，不必再要求域的管理员来响应了。
DelegationofControl实质上就是OU访问权限的赋予。
例如要授权某人可以在OU中建立新的用户，那就是要给于这个人在OU中新建用户对象的权利；如果要委托某人全权管理某个OU，则要给这个人在OU中更大的权限直至完全控制。
DelegationofControlWizard
AD为授权提供了一个专门的工具，叫做DelegationofControlWizard。
这个工具可以用来帮助域管理员方便快捷地完成常用的授权工作。
在OU上点击鼠标右键，选择DelegateControl，这个Wizard就开始运行。
首先需要指定要授予管理权限的对象，也就是OU的被授权的管理员。
在Wizard中，提供了几类常用的授权，包括：
♦Create,deleteandmanageuseraccounts
♦Resetpasswordsonuseraccounts
♦Readalluserinformation
♦Create,deleteandmanagegroups
♦Modifythemembershipofagroup
♦Managegrouppolicylinks
从名字上来看，这些授权的目的是很清楚的，这些授权基本上能够满足一般要求。
如果需要赋予一些特殊的权限，那么就需要选择Createacustomtaskdelegate。
使用这种方式授权，就需要对ActiveDirectory的安全管理机制有更深入的了解。
ActiveDirectory安全机制
在DelegationofControlWizard中修改的结果，最终体现在OU和OU内包含的对象的安全性控制上，也就是对象的访问控制列表ACL中。
AD中使用的安全控制方式和NTFS文件系统中的安全方式完全相同，只存在着一些细节上的差别。
访问控制（AccessControl）的概念
在访问控制中，有一些重要的概念需要了解：
♦SecurityPrinciple安全主体SecurityPrinciple指的是AD中用户，组，计算机和服务。
这几个对象都有帐户（Account）。
我们可以给SecurityPrinciple赋予权限。
♦SecurityIdentifier（SID）SID是每个安全主体都具有的一个属性，用于在安全控制时标识这个安全主体。
SID是一个数字，每个SID在森林中是唯一的。
SID存放在每个对象的Object-SID属性中。
在Windows2000中，所有的对象都有自己的GUID。
由于GUID比SID更能够保证唯一性，所以AD中用来标识对象。
之所以在安全控制中没有使用GUID而采用了SID，米的是为了保持和WindowsNT4.0的兼容，因为在NT4中使用的是SID。
♦SecurityDescriptor这是位于AD对象中的用来完成安全控制的一个数据结构。
在SecurityDescriptor中的信息包括用SID来指定的本对象的所有者（Owner），用于控制用户访问权限的DACL，和用于系统审核的SACL。
AccessControlSettings配置窗口
在AD的对象上单击鼠标右键，选择Properties，然后在对象的属性窗口的Security页中，点击Advanced按钮，就可以打开AccessControlSettings窗口。
这个窗口实际上就是SecurityDescriptor的表现，上面的三个属性页Permissions,Auditing和Owner分别代表了SecurityDescriptor中的DACL,SACL和Owner。
注意：
属性窗口中的Security页只在选择了View菜单的AdvancedFeatures项后才会出现。
访问控制列表
在AD中的每个对象，包括OU，都有两个访问控制列表，分别为DACL（DiscretionaryAccessControlList）和SACL（SystemAccessControlList）。
DACL用于指定用户对本对象的各种权限，分为Allow和Deny两种情况。
在AD对象的属性页的Security属性中，点击Advance按钮，就可以看到DACL。
实际上这就是AccessControlSettings窗口的Permissions页。
AccessControlSettings窗口（DACL）
DACL由多行组成，每一行定义了一种访问控制，称为一个ACE（AccessControlEntry）。
每个ACE包含以下的值：
♦ACE的类型，即Allow或Deny
♦SID，指定此ACE的作用对象，一般为用户或组的SID
♦访问掩码，指定访问的权限
♦继承标志，指定此ACE的继承方式
双击AccessControlSettings窗口的Permissions页面中的任何一条ACE，就可以编辑这条ACE的详细信息。
在此处要注意的是这个ACE的作用范围（Applyonto）。
作用范围可以分为两类，一般作用范围和对象作用范围。
不同的作用范围有不同的可配置权限。
一般作用范围通常有两种情况，容器对象和非容器对象。
相对于非容器对象，容器对象如OU和文件夹有一些容器特有的可分配权限，如列出容器中的对象，在容器中建立和删除对象等。
一般作用范围常见的包括：
♦Thisobjectonly
♦Thisobjectandallchildobjects
♦Childobjectsonly
对象作用范围可以有进一步的权限管理，可以作用到某一类对象，或对象的某个属性或属性集。
例如对于OU，我们可以将某权限的范围限定在OU中的所有用户（User）对象。
♦Userobjects
♦Contactobjects
♦Computerobjects
♦Computerpolicyobjects
♦Groupobjects
♦GroupPolicyContainerObjects
还有更多的作用范围都各有自己特定的用途，并且随着更多的软件使用AD来存放信息，它们会在AD中建立自己的对象，同时也会出现它们特定的作用范围。
权限的继承
Windows2000在权限方面相对于以前的WindowsNT4.0最大的一个变化是现在的权限是可以继承的了。
所谓继承，就是在父容器中设置的权限可以作用到子容器和子容器包含的对象上。
权限的继承只出现在容器的权限设置上，因为非容器对象是最末端的对象，不再包含子对象，所以也没有向下继承权限的必要。
当然它可以从所在容器及上级容器中继承设置的权限。
权限的可继承性大大方便了对系统的管理。
前面已经说到，所谓权限的管理，实际上就是由一组针对用户或组设置了不同权限的ACE组成，这些ACE位于对象的DACL中并控制着对此对象的访问。
也就是说，每个对象只受到对象自己所带的SecurityDescriptor中的DACL中ACE列表的控制。
那么继承是如何实现的呢？
Thisobjectandallchildobjects之类的作用范围又如何起作用呢？
实际上这都由Applyonto指定的作用范围决定。
每个ACE在建立（定义）时，都需要指定一个作用范围并作为ACE的组成部分之一。
我们来看看不同作用范围的不同结果。
PermissionEntry窗口（ACE）
如果我们在高一级的一个OU上新建了一个ACE（通过OU的属性窗口->Security属性页的Advanced按钮->AccessControlSettings窗口->Permissions属性页的Add按钮），选择的Applyonto是Thisobjectonly，则系统只在此OU的DACL中增加了一条ACE，此ACE只对这个OU起作用。
如果我们在这个OU上建立一条新的ACE，这次的Applyonto是Thisobjectandallchildobjects，系统首先也是在此OU的DACL增加了一条ACE，然后由于这条ACE的作用范围是所有的子对象，所以在此OU包含的所有对象（包括所有子OU及其中的对象）的DACL中，都会增加一条ACE。
所以控制对象安全的仍然是对象自己的DACL中的ACE，只不过这条ACE是从上级对象复制过来的。
这就是继承的真相。
同样如果Applyonto是Childobjectsonly，结果也是一样的，只不过这条ACE虽然位于建立它的OU的DACL中，但是受作用范围的限制，它不影响此OU，只影响此OU包含的所有对象。
那么作用范围是Userobjects呢？
结果是OU及所有子对象的DACL中都会增加这一条ACE，但是只有当对象类型是User时，ACE才起作用。
对于非User对象，虽然它的DACL中也有这条ACE，但是此ACE被忽略。
继承自上级对象的ACE在子对象中是不能修改的，我们在ACL中看到的这些ACE是灰色的。
要修改这些ACE，必须在建立它们的对象上修改，然后修改的结果，也就是新的ACE，会被复制到所有子对象并替换原来的ACE。
删除操作也是一样的情况。
那么在AD中新建一个对象又会发生什么情况呢？
首先在Schema中存放的对象定义中，包含了一个缺省的SecurityDescriptor，其中有一些预先定义的好的ACE。
建立新的AD对象时，首先从建立它的进程中获得DACL，然后再检查它所在的容器对象，从容器对象的DACL中复制所有可被继承的ACE，最后再从Schema中定义的缺省DACL中复制ACE。
所以一般我们可以看到新建的对象的DACL都非常庞大。
权限的继承并非完全一路到底的，有一个设置和能否继承相关。
在OU对象的属性窗口的Security属性页中，有一个Allowinheritablepermissionsfromparenttopropagatetothisobject选项。
如果这一选项没有选择（unchecked），则此OU不再继承来自上级的权限，继承链在此断开。
此OU的下级对象只继承来自此OU的权限，而不管再上级的权限了。
这一选项在AccessControlSettings窗口的下段也有，它们是同一个设置。
另外还有一个设置和继承相关，在编辑OU的每个ACE的窗口（PermissionEntry窗口）下端，有一个Applythesepermissionstoobjectsand/orcontainerswithinthiscontaineronly选项。
这一选项是用来控制ACE的作用范围的。
选择了这个选项的ACE只能作用到OU的直接下级对象，包括OU和其他对象，但是不再往更下级传递。
这个ACE复制到下级OU后，作用范围就办成了Thisobjectonly。
文件系统
前面提到的都是在AD中的权限的设置和继承，在此我们顺便回忆一下文件系统。
文件系统的权限设置的工作原理和AD的上的工作原理是完全类似的，区别在于具体的权限设置和作用范围略有不同。
NTFS的文件权限远没有AD多，因为AD中对象的管理权限会不断增加，尤其在安装了其他使用AD的软件，如Exchange2000等以后。
因为这些软件将它们自己的对象也存放到了AD中，AD就一视同仁进行管理。
文件权限的作用范围同样不太一样，主要有：
♦Thisfolderonly
♦Thisfolder,subfolderandfiles
♦Thisfolderandsubfolders
♦Thisfolderandfiles
♦Subfoldersandfilesonly
♦Subfoldersonly
♦Filesonly
我们可以对照前面的内容和这些设置清楚地了解它们的作用方式。
OU的规划
OrganizationalUnit是我们用来建立域中的组织结构的工具，OU的建立直接构成了域的结构。
所以我们必须有建立OU的详细规划。
OU的特点
我们先来回顾一下OU的特点：
♦OU可以嵌套，即OU中可以包含子OU
♦OU可以用于管理授权和访问控制
♦OU不是安全主体，虽然OU中包含对象，但是我们不能给OU赋予访问其它对象的权限
♦组策略和OU关联，组策略关联的对象是Site,Domain和OU，关于组策略在后续章节讲解
OU的目的不是让用户查看对象。
虽然OU象文件夹一样可以让用户清楚地查找对象，但是OU的建立目的并非用于最终用户。
用户在AD中查找对象的最有效的方法是通过GlobalCatalog。
OU结构和业务结构
我们已开始在考虑建立OU时，往往希望用OU来反映公司的业务结构，如分支，部门，项目等。
这当然也是一种规划方法，但是可能会造成以后管理的困难。
OU最重要的目的我们在前面已经提到过了，是为了管理授权（DelegationofAdministration）。
所以OU的结构应该反映公司的管理结构，这可能和业务结构会有所不同。
你可能会希望用业务结构的方式来组织OU，这样就能够基于业务单元生成用户的列表。
但是使用OU只是方法之一。
一般建立用户列表的目的都是为了控制对资源的访问，如某一项目的成员能够使用某一台文件服务器，所以我们可以使用Group而不是OU来反映公司的业务结构。
OU规划步骤
我们在建立OU的结构时，应该参照如下的优先级：
♦为管理授权而建立OU
♦为组策略而建立OU
以管理授权优先和以组策略优先建立的OU结构可能完全不同，不过我们可以有多种方式实现组策略，但是只有一种方式实现管理授权。
所以这个先后顺序是非常重要的。
你的OU结构可能会增长得非常快，所以在建立一个新的OU时，必须仔细考虑，提出充分的理由。
这将帮你确认每个OU的目的，清晰OU结构。
在建立域的OU规划时，建议你和下列人或组织联系：
♦当前负责用户帐户、安全组和计算机帐户的域管理员
♦当前资源域的所有者和管理员
在OU结构建立完成后，再建立新的OU，或者在域中移动OU，在OU间移动对象，删除OU等都是非常简单的操作。
但是要注意的是，移动对象会使对象失去以前继承自OU的权限，转而从新的OU继承权限。
移动对象同样会对组策略造成影响。
所以在OU间移动对象一定要有仔细的评估。
总结
得不到很好的组织和管理的域会造成资源的浪费，降低工作的效率。
我们用OU来建立域的组织结构，然后用管理授权来更好地管理OU。
在技术上我们需要清楚地了解OU的特征，了解如何建立访问控制和管理授权；在规划上，我们需要清楚建立OU的目的，根据公司的管理结构来建立域的组织结构。
Windows2000在访问控制上的增强是非常有用的，尤其是在管理量比较大的时候。
有兴趣建议自己多试验一下访问控制，加深理解。
升级会员 