xxx企业AD规划建议书

XXX企业AD 综合管理策略建议书总页数17正文14附录生效日期：2004-4-1编制： 审核：版本：2 引言Active Directory 作为目前微软网络系统的基础架构管理系统，随着应用系统得增加，AD 本身的管理直接影响到其他应用的管理；所以AD管理是基础中的基础，本文是针对XXX企业 5000人规模的AD作的一些指导性的管理规则。 阅读对象/企业信息主管基于应用程序的管理者的管理人员目录引言2阅读对象21帐号管理51.1计算机帐号命名规则51.2员工帐号命名规则51.3用户Logon Name 的命名规则：61.4其他帐号属性填写规则61.5帐号安全策略规则61.6停用删除帐号规则71.7帐号管理者71.8Administrator 管理规则72组管理72.1域模式规则82.2内置组的管理82.3基于管理角色的自定义组建立规则92.4分发组管理102.5组的使用基本原则113组织单元管理113.1的层次结构规划113.2帐号OU规划123.3成员服务器管理OU的建立规则143.4基于资源的OU管理153.5权限委派管理原则164组策略管理174.1规划GPO原则174.2GPO的管理原则175域控制器及站点部署规则185.1DC 规划管理原则：185.2AD管理帐号组的建立规则185.3Site 规划管理原则：195.4DC 硬件配置需求206小结1 帐号管理在AD 管理中，有两种帐号，计算机帐号和用户帐号，对于XXX企业 5，000员工的规模，基本上每个员工对应一个计算机帐号和用户帐号，部分员工甚至对应多个帐号，这样大约有10，000多个帐号需要管理，考虑到企业的增长和人员变动情况，下面我们分别讨论对应的管理策略。1.1 计算机帐号命名规则缺省的情况下：AD中的计算机帐号就是加入到域中的计算机的NetBIOS名；我们也可以通过创建一个计算机帐号对应目标计算机的GUID，虽然计算机帐号的名字可以超过15位，但实际的管理中，AD只取前15位；所以，对计算机帐号的管理我们建议按照NetBIOS名的规范去做即可：1 计算机名的长度不能超过15位2 计算机名应尽可能反映出物理使用者的信息，如可以通过以下的规则定义： XX_YYY_ZZZZZZZZ其中：XX 代表物理site YYY 代表部门名 ZZZZZZZZ 可以用不超过8位的字母代表用户，基本上能让管理者能方便的查询到用户。如：HZ_IT_Zhangsan 代表杭州IT部的张三的计算机；1.2 员工帐号命名规则员工帐号是AD管理的一个重点，因为帐号有许多的属性，需要作统一规范；考虑到XXX企业 是跨国公司，其企业文化按照美国文化为主，建议规则如下：First name：如果有英文名则用英文名，否则用汉语拼音全名；Last name ：如果有英文姓则用英文姓，否则用汉语拼音姓；Display name ：取系统自动，可以加其他字符作区分。如中文名例：张三First name：JerryLast name：ZhangDisplay name：Jerry Zhang (张三)1.3 用户Logon Name 的命名规则：目前采用的是员工号为Logon Name；这样可以保证用户名在全球企业范围内的唯一；对临时员工或外包员工，在必要的情况下可以按以下规则建立帐号：V-Username ,其中V-代表是临时、外包性质，Username 取用户通用名，保证其唯一性即可；1.4 其他帐号属性填写规则AD账户的属性，在基于AD的应用中有着丰富的作用，建议以下属性填写正确的内容： 所属部门：按照HR规定的缩写 电话号码：分级号码 移动电话：个人移动电话号 办公室位置：中（英）文信息，详细到楼层；1.5 帐号安全策略规则为保证必要的安全性，减少网络入侵的可能性，建议通过组策略，强制以下账户策略： 使用强密码； 最小密码长度5位 密码每60天必须改变 密码保留历史纪录为3个 密码锁定阈值 5 次，自动解锁时间3分中 并对以下时间作审计：n 审核策略更改n 审核登录事件n 审核帐户登录事件n 审核帐户管理1.6 停用删除帐号规则一般不轻易删除帐号，对离职员工帐号作“禁用”设置；1.7 帐号管理者为降低管理成本，可以同过委派的方式，将帐号的完全管理权限委派给以下组： HelpDesk_Account_Admin HR_CreatAccount 并且严格控制其组成员，建议每个物理站点不超过2个成员；1.8 Administrator 管理规则由于Administrator的特殊地位，依照安全性原则，建议如下：1 更改名字到普通的用户名2 建立一个假的administrator 账号3 每30天更换一次真administrator 账号口令4 平时不用administrator 作交互式登录和网络访问，必要时用“Runas”命令实现切换；2 组管理在AD 的管理范畴中，组是用来组织管理用户的，组又分为安全组合分发组，下面我们具体讨论。2.1 域模式规则为更好的发挥安全组的作用，域模式建议采用纯模式（Native Mode）。安全组是用来分发权限的，在 AD 中，有三种安全组：域本地组、域全局组和通用组，在先前兼容的模式混合模式下（Mix Mode），同以类组之间是不能嵌套，组成员也有限制，最多5000个成员。在纯模式下（Native Mode）没有该限制，而且通用组只能存在于纯模式。下。2.2 内置组的管理AD 有8 个系统内置组，主要是做系统维护管理的，缺省的情况下，用好内置组，80% 管理工作。如下图：图2.2 系统内置组内置组的管理策略，见下表：组名目的建议增强安全性成员Administrators成员可以执行操作系统支持的所有功能严格控制成员数目；建议 3个；可通过组策略严格控制成员列表Backup Operators成员可以备份和恢复计算机上的文件，而不管这些文件的权限如何。他们还可以登录计算机和关闭计算机，但不能更改安全性设置。建议每物理站点1个成员可通过组策略严格控制成员列表；可以考虑把备份的权利和恢复的权利独立分开，付给不同的用户角色，以提高安全性；Server Operators管理域中的服务器组成员为：给地理分支的Service Account可通过组策略严格控制成员列表；Account Operators管理域中帐号组成员是：HelpDesk_Account_Admin 和HR_CreatAccount 可通过组策略严格控制成员列表；print Operators管理域中的打印机建议每物理站点1个成员可通过组策略严格控制成员列表；Replicator该组用于配置目录复制服务。清空可通过组策略严格控制成员列表；guests该组提供对系统资源的有限访问。除系统成员帐号外，不添加任何帐号可通过组策略严格控制成员列表；users 所有域中的用户保留缺省表2 内置组的管理策略2.3 基于管理角色的自定义组建立规则在实际工作中，仅仅靠AD的系统内置组还不能完全实现高效管理，建议按照管理角色来建立相应的安全组，通过把日常的任务角色化，可以实现规范化管理。如：Help-desk 的管理员可能只需要修改用户密码的权限而不需要完整的管理员权限。所以可以定义这样一个角色拥有修改密码的单一权限，然后付给某一个组。结合XXX企业 目前的业务系统，推荐如下表：管理组目的成员Site _Topology Admins可以管理 Active Directory Site Topology，负责Site间、内的AD复制 Machine_Account Creation可以有把计算机加入到域中的权力ut_user_admins管理企业的用户帐号ut_group_admins管理企业的用户组ut_computer_admins管理企业的计算机帐号ut_ou_admins管理企业的OUHelpDesk_reset_pw重设用户密码的权力VPN_Account_Creation可以建立VPN的拨入用户Mail_account_creation 可以建立邮箱帐号其他基于AD应用的管理角色可以委派相应管理任务表2.3 基于管理角色的管理组设计策略建立规则如下： 组名尽量反映建组目的，但长度不要超过30字符； 所有的自定义管理角色组缺省都是域本地组，成员为其他基于组织目的的域全局组和成员； 域本地组之间不嵌套； 域全局组可以嵌套，建议不要超过2层，必要的时候可以使用通用组来满足复杂的管理需求；2.4 分发组管理分发组是相对于安全组的，不用于AD权限得分配，主要应用在Exchange 中，可以实现邮件分发的作用。根据XXX企业 的现状，可以考虑按照部门建立其对应的分发组，实现邮件分发，通过邮件的形式来讨论问题。推荐如下表：分发组的建立目的成员基于技术的各种分发组；可参考现有的BBS讨论组用户自愿加入和委派加入基于行政的各种分发组；基本上按照组织机构建立按照HR的分配基于管理/应用需要的分发组按照管理/应用的需求表2.4 分发组的设计策略 2.5 组的使用基本原则对企业来说，用户的管理往往借助于组的管理来实现的，其基本原则是“A G （U） DL P”的思想，就是通过全局组把需要授权的用户组织起来，通过本地组跟具体的权限邦定，然后把组织好的全局组加入到相应的付好权限的本地组中。在必要的情况下；可以使用域全局组的嵌套，或多域情况下使用通用组来实现大规模的人员组织情况。3 组织单元管理组织单元（OU）是一个容器对象，我们可以把域中的对象组织成逻辑组，所以OU纯粹是一个逻辑概念，它可以帮助我们简化管理工作。3.1 的层次结构规划在AD中我们的管理单元基本就是OU，通过权限委派和组策略来实现管理。所以如何管理OU是非常重要的。在这里我们可以依照以下原则来建立：的建立基本上可以以物理机构和行政组织为基础划分的建立目的是从管理的角度出发的，绝不是行政组织的简单对应最小的单元建立原则是以可以独立的管理、安全为边界分割的虽然的逻辑结构是树状的，可以无限扩充，但从管理效率上考虑，不建议嵌套的层次超过五层按照XXX企业 的实际，我们建议采用按照地理组织、管理需求的混合组织方法，建立OU层次框架，如下图： 图3.1 OU规划框架其中 Account_OU 是按照地理组织划分的，如：杭州、上海、北京、西安等Resouce_OU 是按照资源和应用需求划分的，如：Edoc、ERP、搬迁 等详细的规划，请见后面相关部分。3.2 帐号OU规划为方便日常维护管理，按照实际物地理分布，建立以地理位置命名的OU，并建立以下子OU用于管理目的，：Users: 存放该地理组织内的所有成员帐号，建议按照人事部门组织的形式划分子OU；Service Account: 存放该地理组织内的系统服务需要的服务帐号，一般都需要加入到Server Operators ，实现其特权；Computers: 存放该地理组织内的所有计算机帐号；Member Servers: 存放该地理组织内的所有成员服务器帐号，一般按照服务器角色划分子；Groups: 存放该地理组织内的所有组帐号；Admins: 存放该地理组织内的所有管理员帐号；以杭州为例其结构如下图： 图3.2 Account_OU管理框架上图是按照杭州为模版建立的，其他各地可以依次规划。这样管理的好处是，方便统一部署，如一些基于策略的实施和升级等操作，或某些成员服务器安全加固等；结合SMS管理将更加方便。注： 对于经常移动的用户，一般情况下以归属地为主要的命名依据，在集中管理上，我们也可以根据DHCP分割的地址段位管理范围，从而达到逻辑和物理上的统一。3.3 成员服务器管理OU的建立规则随着业务应用的不断发展，公司必然有大量的成员服务器，目前XXX企业 大约有近150台服务器，这些服务器帐号的管理，也非常重要；按照管理需求，建议把所有的成员服务器帐号按照实际功能设计从缺省的“Computer”容器移动到与其物理位置一致的OU中的独立的按照服务器角色设计组织单元（OU）树中-Member Servers，其结构如图一。结合XXX企业 的实情，建议建立基于服务的OU，详见下表：OU/Container目的DNS ServersContains objects relating to DNS network service.WINS (Standalone) ServersContains the WINS infrastructure service-related objects.IIS ServersContains objects relating to IIS Cluster1 services.File ServersContains the file service-related objects.Print ServersContains the print service-related objects.Backup ServersContains the backup infrastructure service-related objects.ISA ServersContains the ISA service-related objects.Proxy ServersContains objects relating to proxy infrastructure services.Intranet Web ServersContains the IIS service-related objects.Internet Web ServersContains the IIS service related-objects.Management ServersContains objects relating to management services.Certificate Authority ServersContains the certificate authority infrastructure service-related objects.Application ServersContains the application infrastructure service-related objects.SQL ServersContains objects relating to SQL Server services.Database ServersContains the SQL service-related objects.Database ClustersContains the SQL clustered service-related objects.Radius ServersContains the RADIUS service-related objects.Client VPN ServersContains objects relating to virtual private network (VPN) network services for client VPN access.Site-to-site VPN ServersContains objects relating to VPN network services for site-to-site connectivity.SMTP ServersContains objects relating to Simple Mail Transfer Protocol (SMTP) services.Security ServersContains objects relating to security services, such as IDS and so on.表3.3 建立基于应用服务的OU框架建议服务器角色尽量单一，如果是某台服务器承担多个角色，需要在文档中注释清楚。3.4 基于资源的OU管理OU可以跟实际中的IT资源/应用捆绑在一起，这样的目的是为了更好的管理资源。建议的资源OU可以按下表的模式建立；OU管理组名控制权限成员类别_ou_adminsFull controlAll objects_ou_user_adminsFull controlUser objects_ou_user_adminsFull controlUser objects_group_adminsFull controlGroup objects表3.4 基于资源的OU管理组设计策略以当前的EDOC 应用为例，我们需要给Edoc单独设立一个OU，分成管理者OU和普通用户OU，然后按照应用角色，细分若干子OU，通过把相应的管理组移动到相应的Ou实现管理委派。在OU的组织上表现如下图：图3.4 资源OU的设计3.5 权限委派管理原则权限委派是组织单元的一个强大应用，主要可以解决给予范围的权限分配的问题，将活动目录部分对象的具体权限委派给某些用和组，并通过建立和布置定制的MMC控制台进行部署，从而减轻了集中管理的负担。权限委派可以通过使用 委派控制向导来完成。在XXX企业 的应用中，结合易于资源的OU设计和基于角色的管理组设计两部分，按照管理需求共同实现，由于权限委派结果查询不方便，建议管理规则为： 按照层级实现权限委派，不要跨级； 建立报告制度，没级管理员定期（一个月）献上级管理员汇报委派情况4 组策略管理组策略（）是AD管理中强大使用的管理手段，使用组策略可以做到： 站点/域级别的集中管理，OU级别分散的管理 控制用户的系统软件环境 通过控制用户和计算机环境，降低管理成本通常可以同过组策略编辑器来定制需要的策略，必要的情况也可以自定义开发，通过.inf 文件导入组策略编辑器。结合XXX企业 的实际应用，目前我们可以按照微软提供的基本模版完成一些常规的GPO设置和实施，以下时规划和管理GPO时需要参考的原则：4.1 规划GPO原则 在最高层应用GPO，这样很好应用了GPO的继承性； 降低GPO的数目，在带宽允许的情况下，尽可能用GPO Link 而不是重建GPO； 定制GPO的设置，最好一个GPO只负责一个管理需求； 当GPO只针对用户和计算机一项的时候，禁用掉另一项以提高性能； 只有必要的时候才使用“阻止继承”（Block Inheritance）和“禁止替代”（No Override）和筛选（security filtering）4.2 GPO的管理原则 建立GPO管理组：建立GPO_admin 和 GPO_link 两个域本地组，GPO_admin的成员可以管理所有GPO，建议成员数目不要超过3个；GPO-Link 组的成员只能连接GPO，建议每一个地理分支OU有一个成员； 按照管理需求建立GPO维护组，并通过权限委派实现降低管理负荷；如：可以规划以下范围的GPO管理维护组： 用户配置管理 数据管理 软件分发 。 建立GPO的审计规划，以确保GPO的执行效果； 推广一个GPO前一定要通过测试，并且应该有详细文档；5 域控制器及站点部署规则域控制器（DC）和站点（Site）都是AD的物理实体，在规划上我们需要严格遵需以下原则：5.1 DC 规划管理原则： 严格控制AD管理帐号组成员； 严格控制 DC的物理安全，DC不能存放于不安全的地方； 严格控制 DC的备份资料，备份资料不能存放于不安全的地方； 每3个月做一次AD恢复测试； DC上装的软件和应用要尽量少；5.2 AD管理帐号组的建立规则目录服务的管理被分成5个角色，如下： Forest owner: Enterprise Admin Forest owner: Schema Admin Site topology owner Domain owner Organizational unit owner其中森林所有者有2个角色构成，Schema Admin 和 Enterprise Admin，下表将详细描述这些角色：角色名职责 成员Forest Owner: Enterprise Admin传递目录服务，并控制Forest的配置信息更改，如：添加新域后者改变Site拓扑。Built-in user group (Enterprise Admins).Forest Owner: Schema Admin传递目录服务，并控制Forest的schema配置信息更改。Built-in user group (Schema Admins).Site Topology Owner 传递目录服务，并控制Forest的site topology配置信息更改。 如：DC的IP、subnet、location、router-cost 的改变信息。自定义一角色组：Global