3. 用户与组生命周期管理
当组织规模从几十人扩展到几百甚至上千人时，逐个在门户里点“新建用户”已经不可行。用户与组的生命周期管理，本质上是把“入职—变更—离职”这条人事主线，映射为 Microsoft Entra ID 中可重复、可审计、可自动化的对象操作。本节围绕四个关键能力展开：批量创建用户、动态组成员规则、组嵌套限制，以及基于组的许可分配自动化。
批量创建用户：CSV 与 Graph 两条路径
批量创建用户最直接的方式是使用 Entra 门户的“批量创建”功能：下载 CSV 模板，按列填写 User name、Display name、Initial password、Usage location 等字段，上传后系统逐行处理并返回结果文件。这种方式适合一次性导入，但字段有限，且无法处理复杂属性。
更可控的方式是调用 Microsoft Graph。下面是一个使用 PowerShell 批量创建用户的示例，输入为一份 CSV，每行代表一名新员工：
Connect-MgGraph -Scopes "User.ReadWrite.All","Directory.ReadWrite.All"
$users = Import-Csv .\new-hires.csv
foreach ($u in $users) {
$passwordProfile = @{
Password = $u.InitialPassword
ForceChangePasswordNextSignIn = $true
}
New-MgUser -DisplayName $u.DisplayName `
-UserPrincipalName $u.UPN `
-MailNickname $u.MailNickname `
-AccountEnabled:$true `
-UsageLocation $u.UsageLocation `
-Department $u.Department `
-JobTitle $u.JobTitle `
-PasswordProfile $passwordProfile
}关键点有三个：Usage location 必须填写，否则后续无法分配需要位置信息的许可证；初始密码应强制下次登录修改；UPN 必须全局唯一，建议用“工号+域名”或“姓名拼音+域名”规则生成，避免重名冲突。执行后可通过 Get-MgUser -Filter "startswith(department,'Sales')" 验证结果。
动态组：用规则代替人工维护
动态组（Dynamic Membership Group）通过一条成员规则，让 Entra ID 自动计算成员。规则基于用户或设备的属性，例如部门、职位、城市、员工类型等。一个典型的销售团队动态组规则如下：
(user.department -eq "Sales") and (user.accountEnabled -eq true)
and (user.usageLocation -eq "CN")规则语法支持 -eq、-ne、-startsWith、-contains、-in 等操作符，以及 -and、-or、-not 逻辑组合。需要注意：动态组不能手动添加或删除成员，成员完全由规则决定；规则变更后，成员计算不是瞬时的，通常需要几十秒到几分钟，可在组概览页查看“处理状态”。
动态组的一个常见误区是把它当作“静态组的替代品”。实际上，动态组适合属性稳定、规则清晰的场景，例如“所有正式员工”“某城市的所有销售”；而对于项目组、临时协作组这类成员频繁手工调整的场景，静态组反而更合适。
组嵌套限制：为什么不能无限套娃
Entra ID 支持组嵌套，即一个组可以作为另一个组的成员。但嵌套有明确边界：动态组不能作为其他组的成员，也就是说，动态组只能是“叶子组”，不能嵌套进另一个组。此外，通过组进行许可分配时，嵌套组中的成员不会自动继承许可证——许可只作用于直接成员。
这意味着，如果你设计了一个“部门组 → 团队组 → 项目组”的三层结构，并希望许可证从顶层向下传递，实际是不会生效的。正确的做法是：把需要分配许可的组作为“许可组”，让用户直接成为其成员，或者使用基于组的许可并确保目标组是直接成员关系。
许可分配自动化：从组到用户
基于组的许可（Group-based licensing）是 Entra ID 中分配 Microsoft 365 等许可证的推荐方式。管理员只需把许可证分配给一个组，组内所有直接成员自动获得许可；用户加入组时自动获得，离开组时自动回收。这比逐个用户分配更易管理，也更容易审计。
配置时需要注意几个参数：Usage location 必须在用户对象上设置，否则分配会失败；许可证 SKU 要选择正确的产品，例如 ENTERPRISEPACK 对应 Microsoft 365 E3；分配错误会在组的“许可证”页显示，常见原因包括位置缺失、SKU 数量不足、服务计划冲突等。
下面是一个使用 Graph 为组分配许可证的示例：
$group = Get-MgGroup -Filter "displayName eq 'Sales-Team'"
$sku = Get-MgSubscribedSku | Where-Object { $_.SkuPartNumber -eq "ENTERPRISEPACK" }
Set-MgGroupLicense -GroupId $group.Id `
-AddLicenses @(@{ SkuId = $sku.SkuId }) `
-RemoveLicenses @()执行后，可在组页面的“许可证”选项卡查看已分配 SKU 和成员处理状态。若某成员未获得许可，优先检查其 usageLocation 是否为空，以及该 SKU 的可用数量是否已耗尽。
把四件事串成一条可执行的主线
实际落地时，建议按以下顺序组织：先用 CSV 或 Graph 批量创建用户，确保 usageLocation、department、jobTitle 等属性准确；再根据属性建立动态组，让成员自动归集；然后为需要许可的组分配 SKU，并确认组是扁平结构、用户是直接成员；最后在离职流程中，先禁用账户，再将其从组中移除，许可随组关系自动回收。
这条主线的价值在于：用户属性是源头，动态组是规则层，许可分配是结果层。只要源头属性准确，规则层和结果层就能自动运转；一旦属性缺失或规则写错，问题会沿着链路向下传导，表现为“用户没进组”或“许可分配失败”。因此，排障时优先检查用户属性，再检查动态组规则，最后检查许可 SKU 和位置设置。