4. 管理单元与委派管理

在上一节中，我们已经理解了租户、订阅与资源组之间的层级关系。但当我们把视角从"资源"转向"人"时，会发现一个现实问题：资源组能隔离虚拟机、存储账户这类资源，却无法隔离用户、组和设备这些目录对象。一个拥有"用户管理员"角色的帮助台人员，默认可以管理整个租户里的所有用户——包括财务部、法务部甚至高管账户。这显然不符合最小权限原则。

Microsoft Entra ID 提供的管理单元（Administrative Units，简称 AU）正是为解决这一问题而设计的容器。它可以把目录对象（用户、组、设备）划分到不同的边界内，再配合作用域限定的角色分配，让被委派者只能在自己负责的范围内执行管理操作。本节我们就围绕"隔离部门用户 + 委派帮助台"这一典型场景，把管理单元从概念到落地完整走一遍。

管理单元解决的是什么问题

先明确一个关键区别：管理单元不是安全组，也不是组织单位（OU）。安全组用于批量授权访问资源，OU 是本地 AD 的概念，而管理单元是 Entra ID 原生的管理边界。它的核心价值在于两点：

• 对象隔离：一个管理单元内只包含被显式加入的成员，默认不包含其他任何对象。
• 权限收窄：角色分配可以限定到某个管理单元，被委派者只在该单元内拥有对应权限。

举例来说，如果为"上海分公司"创建一个管理单元，并把该分公司的 200 名用户加入其中，那么被授予"用户管理员"角色且作用域限定为该管理单元的帮助台人员，就只能重置这 200 人的密码、修改他们的属性，而无法触碰其他部门的任何账户。

管理单元的类型与成员规则

Entra ID 中的管理单元分为两类，选择哪一类直接决定了后续的委派方式：

静态管理单元的成员需要手动维护，适合人数不多、变动不频繁的场景。动态管理单元则基于属性规则（例如 department -eq "Finance"）自动计算成员，适合人员流动大的组织。需要注意的是，动态管理单元目前主要支持用户和设备，且规则语法与动态组成员规则一致。

委派帮助台：从角色到作用域

创建好管理单元后，下一步是委派。Entra ID 中可被限定作用域的内置角色包括"用户管理员""帮助台管理员""密码管理员""组管理员"等。以帮助台场景为例，最常用的组合是：

• 密码管理员：只能重置密码，不能改属性、不能建用户，权限最小。
• 帮助台管理员：可重置密码、管理部分用户属性、读取基本信息。
• 用户管理员：权限更宽，可创建、删除、修改用户及组。

实际委派时，我们通常不会把"用户管理员"这种高权限角色直接给一线帮助台，而是优先使用"密码管理员"或"帮助台管理员"，把权限压到刚好够用。下面这张图展示了整个隔离与委派的结构关系：

实操：创建管理单元并委派帮助台

下面以 PowerShell（Microsoft Graph 模块）为例，演示从创建到委派的完整过程。假设我们要为"上海分公司"建立隔离边界，并委派一名帮助台人员。

# 1. 连接 Graph
Connect-MgGraph -Scopes "AdministrativeUnit.ReadWrite.All","User.ReadWrite.All","RoleManagement.ReadWrite.Directory"

# 2. 创建静态管理单元
$au = New-MgDirectoryAdministrativeUnit -DisplayName "上海分公司" -Description "上海分公司用户隔离边界"

# 3. 将部门用户批量加入管理单元（按 department 属性筛选）
$users = Get-MgUser -Filter "department eq '上海分公司'" -All
foreach ($u in $users) {
    New-MgDirectoryAdministrativeUnitMemberByRef -AdministrativeUnitId $au.Id -BodyParameter @{
        "@odata.id" = "https://graph.microsoft.com/v1.0/directoryObjects/$($u.Id)"
    }
}

# 4. 获取"密码管理员"角色模板
$role = Get-MgDirectoryRoleTemplate -Filter "displayName eq 'Password Administrator'"

# 5. 将角色限定到该管理单元，并分配给帮助台用户
$helpdesk = Get-MgUser -UserId "helpdesk@contoso.com"
New-MgDirectoryRole -RoleTemplateId $role.Id
New-MgDirectoryRoleScopedMember -DirectoryRoleId $role.Id -BodyParameter @{
    "@odata.id" = "https://graph.microsoft.com/v1.0/directoryObjects/$($helpdesk.Id)"
    "directoryScopeId" = "/administrativeUnits/$($au.Id)"
}

关键点在第 5 步的 directoryScopeId：它把角色分配的作用域从"整个租户"收窄到"这个管理单元"。如果没有这一行，帮助台就会获得租户级的密码重置权限，隔离就失效了。

验证隔离是否生效

配置完成后，必须验证边界是否真正起作用。验证方法有两种：

1. 以帮助台身份登录，尝试重置上海分公司某用户的密码——应成功；再尝试重置财务部用户密码——应收到"权限不足"错误。
2. 用 Graph 查询该帮助台的有效角色分配，确认 directoryScopeId 指向管理单元而非 /。

# 查看某用户的有效角色分配及作用域
Get-MgUserTransitiveMemberOf -UserId "helpdesk@contoso.com" |
  Where-Object { $_.AdditionalProperties["@odata.type"] -eq "#microsoft.graph.directoryRole" } |
  Select-Object Id, DisplayName

动态管理单元与自动化治理

如果上海分公司人员流动频繁，手动维护成员会很快失控。此时可改用动态管理单元，规则示例：

user.department -eq "上海分公司" -and user.accountEnabled -eq true

规则生效后，新入职员工只要部门属性填对，就会自动进入管理单元并落入帮助台的管理范围；离职或调岗后自动移出，权限随之回收。这种"属性驱动"的方式把治理动作前移到了 HR 数据源头，是规模化组织更推荐的做法。

设计时的几个判断依据

• 边界怎么划：按部门、按地区还是按职能？优先选择与 HR 组织架构一致、且属性稳定的维度。
• 角色给多大：一线帮助台优先"密码管理员"；需要改属性再升到"帮助台管理员"；"用户管理员"只给二线或团队负责人。
• 静态还是动态：成员少于 50 且变动少用静态；超过 50 或频繁变动用动态。
• 是否嵌套：管理单元支持嵌套，但嵌套会放大权限继承的复杂度，非必要不嵌套。

把管理单元用对，本质上是在 Entra ID 里为"人"建立了一层与资源组平行的治理边界。资源组管资源，管理单元管目录对象，两者配合作用域限定角色，才能既让帮助台高效处理日常工单，又不让它越界触碰不该碰的账户。