Windows 管理

在 Active Directory 中委派权限

Joel Yoker and Rob Campbell

概览:

• 定义管理角色
• 开发 OU 和安全组模型
• 使用辅助帐户
• 委派权限的工具

Active Directory 中的委派功能非常强大，可以解决大量安全问题并简化管理任务。通过在 Active

Directory® 中正确地委派权限，您可以在环境中强制指定的角色，限制出现管理错误的可能性及其影响，以及在您的整个基础结构中应用最低权限原则。然而，许多依赖 Active Directory 的组织尚未领略到委派的强大力量。从表面来看，部分原因在于为企业部署 Active Directory 委派模型似乎相当复杂。尽管最大的障碍是开发出的委派模型必须满足组织的特殊需要，但事实上仍然存在一些非常简单的模型，这些模型几乎无需修改即可应用到大多数 IT 基础结构中。

虽然每个环境在某些方面（如规模或形式）有所不同，但实际上，大多数大型企业在许多方面是相似的，它们也面临同样的 IT 难题。例如，许多组织都有不同的部门分散在不同的地理区域，它们从独立的 IT 工程或运营支持团队发展而来，且拥有独立的业务单位。并且许多大型组织必须处理诸如权限升级、服务帐户滥用和“信任”等问题。

信任是一个有趣的术语，经常会成为拥有多个 Active Directory 林结构的依据。信任问题通常来源于某个部门或地区的能力，这种能力会影响另一部门或地区的系统可用性。通常来说，不同组织之间的技能水平有所差异，且缺乏对支持特殊地区或业务单位所需的特定系统的深入了解。因此，各部门通常不希望放弃对中央群组的管理权限。

同时，要实施任何 Active Directory，管理员均须对利用 Active Directory 基础结构的应用程序的使用规则加以定义。一个常用的方法（该方法经常在应用程序安装指导中提到）是让服务帐户成为域管理员组的一员。不过，这种方法产生的问题是服务帐户实质上成了通用帐户。在向这些帐户授予域管理员权限时，将会为 IT 环境带来很大的危险。服务帐户很容易被那些恶意或粗心的管理员不当使用，或者被洞悉应用程序内部潜在安全问题的攻击者所利用。

尽管这些障碍看起来不可逾越，但也为实现 Active Directory 委派模型提供了一个最好的方案。开发委派模型是一个交互式的设计过程，建议您遵照以下步骤：

1. 在您的组织内定义 IT 管理角色。
2. 开发组织单位和安全组模型。
3. 为 IT 管理员建立辅助帐户。
4. 委派权限。

让我们进一步了解一下这些步骤。

定义角色

彻底了解服务管理和数据管理是角色定义过程的第一步。这些概念是任何 Active Directory 委派模型的基础。

本质上，服务管理是对关键目录服务基础结构组件的管理，例如 Exchange 服务器和域控制器。数据管理是对对象的管理，例如驻留在这些服务中的邮箱和用户帐户。在 Active Directory 范围内，服务管理员最终对目录服务的交付和可用性负责，而数据管理员则负责管理用户和服务器帐户、组和其他域资源。

Active Directory 支持在组织单位 (OU) 中进行权限的精细委派。OU 通常可以量身定制，以提供与管理员可在现有目录服务或域模型所使用的权限级别相同的权限。但有很重要的一点要了解，某些功能根本无法委派，必须由一个受信任组或实体来管理。

任务分析也很关键。您需要知道哪些任务由管理员执行，以及这些任务如何映射到各个角色。例如，Active Directory 站点创建是服务管理任务，而安全组成员身份的修改则通常由数据管理负责。每项任务的频率、重要性及难度均应予以评估。上述内容是任务定义的重要方面，因为它们决定了权限是否应该委派。那些定期执行、风险低且容易完成的任务是绝佳的候选委派对象。另一方面，那些很少执行、对组织影响很大且需要较高熟练程度的任务，尽量不予委派。实际上，升级（临时将某帐户提升为所需的角色或重新分配任务）对这些任务来说是个不错的选择。

既然大型组织的许多特征是相似的，则不妨假定通用委派模型可以实现。为使本文更具说服力，我们将提供一组角色的示例集，这些角色会启用管理功能，且不超出组织界限并试图防止出现信任问题（例如域控制器等企业资产的可用性）。请注意，此模型只是一个示例，尽管对于在您的组织内进行角色讨论其不失为一个良好的开端，但不应盲目照搬本指南。

有些角色已由 Active Directory 定义，有些角色则必须从头创建以适合委派模型。适合许多大型 Active Directory 环境的角色示例集可能包括用于服务管理的企业管理员、域管理员和 Tier4 管理员，以及用于数据管理的 Tier3 管理员、区域管理员、Tier2 管理员和 Tier1 管理员。有关这些角色及其职责列表，请参阅图 1。

Figure 1 定义角色和职责

服务管理员

让我们进一步了解一下这些服务管理员角色。服务管理员管理关键基础结构组件，所有此类管理员均具有很高的权限。因此，在这种情况下强烈建议使用最小权限策略，即仅授予执行所需任务时所必需的最少权限。

企业和域管理员 Active Directory 定义两组特殊的管理员，他们的安全上下文是目录中的关键功能所需的。这些组（企业管理员和域管理员）负责管理顶级服务。为减少此类高权限组的内在风险，强烈建议您限制这些组的成员身份。事实上，企业管理员组不应具有永久成员，而域管理员组应该仅包含数量不多且容易管理的受信任成员，并且从组织的全职员工中选择这些成员。

当需要执行企业管理任务（比如 DHCP 服务器授权或 Active Directory 站点创建）时，Active Directory 林结构根域中的域管理员可通过管理企业管理员组的成员身份来升级权限。这些权限只能短期授予，以免在企业管理员组中创建永久成员。当然，在给定的 Active Directory 林结构中，域管理员组的所有成员必须获得平等的信任。

部署委派模型时，大多数组织的一个常见缺陷是丧失或削弱这些内置角色。修改默认角色可能会产生不可预见的后果，且不担保服务包修订或产品升级会保留这些设置。此外，此类修改会创建一个超出组织范围且不受支持的环境。一个实用的方法是使用内置的组和角色，但要对其成员身份进行限制。为此，您可能需要为先前依赖组（如域管理员组）中成员身份的管理员创建新角色。

Tier4 管理员 Tier4 管理员组应该由为所有企业服务提供支持的集中服务管理员组成。由于该角色已经创建，因此可以针对您组织的特定需求来量身定制目录服务和系统访问权限。虽然该组的成员是服务管理员，但是他们也可以偶尔在林结构范围内执行数据管理任务。由于系统类繁多且各区域的职责也不尽相同，因此在目录内将 Tier4 角色分成了各种子组。例如，应该创建独立的 Tier4 组，以独立管理特定系统（如 Exchange 服务器）。该组还是数据管理员的升级起点。

通常，人们希望获得域管理员组成员身份的一个原因，是想获取给定域中所有系统的管理权限。要让这些服务管理员在最低权限模式下运行，方法是允许 Tier4 管理员控制企业服务器，但不允许他们成为域管理员。为防止权限升级，不应将域控制器上 BUILTIN\Administrators 组中的成员身份授予 Tier4 管理员，因为该组有许多针对目录服务的底层权限无法分离。例如，某给定域的 BUILTIN\Administrators 组的一名成员可以管理域管理员组的成员身份，允许成员不经任何检查和平衡即升级权限。

切记不得随意更改默认权限的规则，令 Tier4 组成为服务器操作员和 DNS 管理员内置域组的嵌套成员可缓解此风险。这样既可本地管理域控制器，又限制了 Tier4 管理员升级权限的能力。对于大多数系统（域控制器和证书服务器等除外），应该允许 Tier4 管理员组成为本地管理员组中的一员。嵌套的本地组成员身份可利用组策略中的“受限制的组”功能自动获取。

数据管理员

现在，让我们来研究一下数据管理角色。在设计上，这些角色的权限应该是不断累积的，即 Tier2 管理员应该具有 Tier1 管理员的所有权限再加上一些其他权限，以此类推。基于此，我们按照自下至上的顺序来查看这些组。

Tier1 管理员 Tier1 管理员组应提供对先前创建的目录对象的常规管理。本组适用于培训程度最低或执行单独任务（如密码重置）的管理员。在其组织单位内部授予本组权限，如修改用户帐户属性、重置用户帐户密码、解锁帐户、启用/禁用用户帐户、添加和重置工作站计算机帐户以及修改非管理组的组对象成员身份。

Tier2 管理员 本组应有选择性地管理和创建对象，允许仅在 Tier1 管理员的管理范围内创建对象。（例如，安全组只能在 OU 组中创建）。Tier2 管理员可以添加和修改 Tier1 管理员帐户；添加、修改和删除 OU 的用户帐户；删除 Workstation 计算机对象；添加、修改和删除 Server、Contact 和 Shared Folder 对象。

区域管理员 本组被授予对其区域 OU 结构的独占权限。不过，他们不能管理目录内的其他区域 OU 结构。区域管理员帐户应该具有很高的权限，因此，这些帐户存储在独立的 OU 层次结构中，并由 Tier4 Admin 服务管理员管理。区域管理员可以在其 OU 结构内不受限制地创建大部分对象（但无法在其他组织单位中创建对象），由此带来的附加风险是其所创建的对象可能无法在较低的层次中管理。

Tier3 管理员 许多组织拥有集中式服务台，或在上层有服务台。该角色填充数据管理员列表，为所有区域管理员提供数据管理员组。权限并未明确地委派到目录内的这些组中；相反，它们是借助每个区域管理员组中的嵌套成员身份而委派的。这为所有数据管理员提供了一个顶级升级起点，也为升级到服务管理组提供了切入点。

构建 OU 和安全组模型

一旦在组织中定义了角色，就必须定义 OU 和安全组模型。在 Active Directory 中创建 OU 主要有两个原因：委派权限和创建一个可以链接组策略对象的点。OU 在目录内定义管理范围 (SOM)，用来限制各级对象的权限。因此，选择如何委派权限应该是如何实现 OU 结构的一个主要因素。

记住了这一点，就应该直接在域下面创建顶级 OU（或 OU 系列）来存储所有对象。此 OU 的专门用途就是为 Tier4 管理员定义最高级别的 SOM。通过创建顶级 OU，可以在 OU 级别而非域级别显式启动目录服务权限。从顶级 OU 而非域中委派可降低用户通过操作前述内置域组来升级权限的风险。

在顶级 OU 之下，应该创建单独的子 OU 层次结构来表示每个具有独立数据管理团队的地区或业务单位。每个区域子 OU 均应拥有一个通用且不可扩展的 OU 层次结构来管理目录对象。由于许多权限委派将自动进行，因此一致性对于当前的管理很重要。这是一个很严格的要求，因为每个地区可能需要唯一的 OU。但是 IT 管理员必须坚持己见，如果某个地区需要扩展，则子 OU 结构必须对所有地区均进行扩展。刚开始似乎很难，但是如果组织为对象提供通用的存储方式，则情形会逐渐好转起来。

最后，创建子管理员组和帐户，以禁止管理员为每个子 OU 层次结构（如 Tier1 管理员、Tier2 管理员和区域管理员组）升级权限。将这些帐户放在单独的 OU 中，可以限制对其自身级别或下面级别的管理。因而，如果所有 Tier1 管理员帐户和相关的安全组驻留在 OU 中而又没有权限，则这些管理员将无法劫持其他管理员帐户，或将其他管理员的权限升级到与自己相同的级别。例如，域管理员组的任何成员都可以使域中的任何其他用户帐户成为域管理员。但是，使用上述 OU 模型，该风险就会显著降低。OU 结构及相关安全组示例如图 2 所示。

图 2** OU 结构及相关安全组 **

建立辅助账户

一个成功的委派模型，其关键是强制实施最低权限原则。实际上，安全原则意味着只能拥有执行其给定角色所需任务的能力，仅此而已。很可惜，许多 IT 管理员对目录管理和各项日常任务（如 Web 浏览和阅读电子邮件）均使用同样的安全原则。如果具有单独的帐户，分层管理员可降低以下风险：由于误操作而损坏目录服务，或者成为攻击的受害者（这些攻击通过日常应用程序来实施，但目标却是目录管理员）。

要完成上述操作而又无需用户注销和重新登录，可使用 Secondary Logon 服务 (Runas.exe)。当用户在服务器和工作站上执行脚本或可执行文件时，可通过提供一组替代凭据集来升级用户权限。

组织不时会发现，使用最低权限帐户的概念虽然相对简单，但强制实施起来却很困难，因为原有的 IT 习惯往往很难改变。阻止使用具有一定权限的帐户来处理日常任务的直接方法，就是不要在 Exchange Server 中提供对这些帐户进行邮件访问的权限，这可通过组织内的管理策略强制实施。这种相对简单的方法可明显降低使用此类帐户处理日常非管理任务的可能性。

委派权限

开发委派模型的最后一步是在 Active Directory 内实际委派权限。该步骤需要针对目录中存储的数据，对访问控制项 (ACE) 和访问控制列表 (ACL) 进行操作。Active Directory 容器中的 ACL 定义了可以创建的对象以及管理这些对象的方式。权限的委派涉及对象的基本操作，如查看对象、创建指定类的子对象或者读取指定类上的对象的属性和安全信息等能力。除这些基本操作外，Active Directory 还定义了扩展权限，这些权限启用诸如“代理发送”和“管理复制拓扑”之类的操作。

在前面的步骤中，我们讨论了创建映射到已定义组织角色的安全组。这表明，每个角色都有一个相关的子 OU 结构安全组。要实施委派模型，需要针对目录中的对象为这些组分配权限。进行到这一步，您不会希望再重新开始并创建一个高度自定义的环境。相反，如果可能，可尝试利用内置组和权限。比方说，一个特殊的角色需要管理林结构的 DNS 记录。不要试图通过容器和命名与 Active Directory（集成 DNS）相关的上下文来委派权限；相反，只需利用域中的 BUILTIN\DNS 管理员组即可。此外，可通过组策略扩展用户权限和其他权限，以提供给定角色管理特定系统类所需的附加权限。

使用委派分配权限时，应限制甚至避免在目录中使用“拒绝 ACE”。它们会让故障排除变得很棘手。更好的方法是使用显式的“允许 ACE”为代表您角色的自定义组授予权限。记住，用户定义的角色（如 Tier4 管理员）只拥有该角色所定义的显式权限。

继承对 Active Directory 安全而言至关重要，它定义了如何将特定的 ACL 应用至给定容器或子容器中的子对象。确保应用可继承的 ACE 时使之与目标对象尽可能接近，这样就可始终明确继承的范围。应用至父对象的可继承拒绝权限优先于应用至祖父对象的可继承拒绝权限，这也是不建议在实际委派中使用“拒绝 ACE”的主要原因之一。并且，可继承权限不能覆盖对象的显式 ACE。因此，建议您限制或取消分层管理员修改目录对象自由访问控制列表的能力（通过删除“写入 DACL”权限）。（请注意，对象的创建者自然具有这些权限。）经验告诉我们，如果管理员拥有更改对象 DACL 的权限，通常都会尝试一下。不要让侥幸心理和潜在的管理错误，将自己组织实施委派模型的艰苦努力付之东流。

要正确实施 Active Directory 委派模型，您需要用到大量的工具。对于大多数组织而言，使用内置的委派向导在目录中分配权限是一项令人望而却步的任务，各种管理错误可能随时发生。相反，应坚持使用自动化分配以确保委派模型记录良好、可受支持，并且在设置意外丢失或被更改时提供恢复选项。

实施委派所需的主要工具是 DSACLS.EXE，它是命令行工具，用于操作对象的目录服务 ACL。此工具还允许在父对象上为 DACL 指定继承标志。（继承标志包括该对象及子对象、仅子对象，并且仅传播一个级别的可继承权限。）如果继承标志设置不正确，则 DSACLS 命令最终会失败，因此使用此工具时测试变得至关重要。下面是一个 DSACLS 语法示例，委派在目标演示 OU 中创建计算机对象的能力：

dsacls.exe ou=demo,dc=contoso,dc=com /I:T /G contoso\dataadmin:CC;computer

DSACLS 区分对象类型的大小写。也就是说，试图为对象类“cn=Computer”而不是“cn=computer”委派权限将不起作用（请参见图 3）。

图 3** 由于区分大小写而造成的错误 **(单击该图像获得较大视图)

某些对象需要特定的权限集才能创建。这必须处理对象的“必须包含”和“可以包含”属性。据我所知，解释此概念的最形象的比喻是汉堡模型。汉堡必须是一个圆面包夹一片肉可称其为汉堡。它们就是汉堡对象类的“必须包含”属性。像泡菜、番茄酱和莴苣等则是“可以包含”属性。如果我们扩展对象类来定义干酪汉堡，则“必须包含”属性列表中还要加上干酪。

用户对象的工作原理也一样。假设我们要根据汉堡模型来使用下面的 DSACLS 语法创建用户对象：

dsacls ou=demo,dc=contoso,dc=com /I:T /G contoso\demodata:CC;user 

在创建用户对象期间，管理员可能会遇到几个错误。我们需要授予一些必需的权限才能设置所需的用户对象属性，包括设置密码。如下面的附加 DSACLS 语法中所示。

第一步，授予写入“必须包含”属性的权限，方法是将“通用读/通用写”授予用户类的所有属性：

dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:GRGW;;user

下一步，授予更改密码的扩展权限：

dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:CA;"Reset Password";user

最后一步，为“上次设置的密码”属性的“读属性”和“写属性”授予权限：

dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;pwdLastSet;user

委派了正确的权限之后，所定义的角色将会仅限于管理在容器的 DACL 中所定义的对象类。使用先前的计算机对象示例，Active Directory 用户和计算机中的上下文菜单会限制新建对象的列表，这些对象只能由委派了新建权限的用户创建（请参见图 4 中的限制列表）。

图 4** 新建对象限制列表 **

DSACLS 还可以自动部署复杂的权限。下面是一些 DSACLS 命令，这些命令可以委派权限，以在给定容器中操作用户对象的常用地址属性：

dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;c;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;co;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;l;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;postalCode;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;postOfficeBox;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;st;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;streetAddress;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;telephoneNumber;user

像这样的示例通用于大多数委派模型，并可与先前定义的角色联合使用。

另一个用于实施委派的工具是 DSREVOKE.EXE，管理员可以根据对象的特定安全原则，使用该工具在目录中查找和删除委派权限。尽管该工具可能非常有用，但是它特定于安全原则，且不能评估安全组内部的嵌套成员身份。

除这些命令行工具以外，我们还强烈建议将“用户权限分配”和“受限制的组”与组策略同时使用。如前所述，“用户权限分配”允许 IT 管理员在特定目标系统上的针对各种用户组扩展或删除低级权限（比如远程访问和重启系统的权限）。“受限制的组”可用来指定和强制林结构内的本地组和域组成员身份。结合使用这些工具，您可以从容地自动实施 Active Directory 委派模型。

总结

虽然开发 Active Directory 委派模型的任务可能看起来很复杂，而事实上，大多数 IT 基础结构均可采用非常简单的模型。实际部署委派模型时，最重要的步骤之一是明确定义角色。应该定义少量的角色，且不超出管理能力。做到平衡并非易事，因为角色太多会导致角色无法使用，而角色太少又无法进行角色分离。

请记住，定义任务时，请按使用频率、重要程度和难易程度进行分类。定义角色之后，开发一组使用案例，以帮助确定每个角色的职责范围以及实现测试过程自动化。准备充分的使用案例有助于向您组织负责人解释这些角色，并且能够在出现由于自动操作而导致的错误时缓解紧张感。

最后要说的是，在开发委派模型时，灵活采取切实可行的方法始终不失为上策。请记住，简单意味着高可支持度，若要在 Active Directory 环境内部控制管理权限，可支持度高的委派模型会让您大受裨益。

其他资源

• Design Considerations for Delegation of Administration in Active Directory（英文）
• Best Practices for Delegating Active Directory Administration（英文）

Joel Yoker 是 Microsoft Federal 团队的高级顾问。Joel 和 Rob 均专注于为美国联邦政府客户开发和部署安全解决方案。

Rob Campbell 是 Microsoft Federal 团队的高级技术专家。Joel 和 Rob 均专注于为美国联邦政府客户开发和部署安全解决方案。

© 2008 Microsoft Corporation 与 CMP Media, LLC.保留所有权利；不得对全文或部分内容进行复制.