3. 用户与用户组治理

在 Windchill 中，权限最终落到“主体”上，而主体主要由用户和用户组构成。用户是权限的最小承载单元，用户组则是权限批量授予与继承的载体。治理的目标不是把每个人都单独配一遍权限，而是让权限通过组结构稳定地流动：人进组、组继承、权限生效；人离组、权限回收、审计留痕。本节围绕用户创建、组嵌套、动态组、目录服务集成与账号生命周期管理五个环节，说明如何把“人”这一维度治理清楚。

用户创建：先定身份，再定归属

Windchill 中创建用户通常有两种路径：管理员在“参与者管理”中手工新建，或通过目录服务批量导入。手工创建时，关键字段包括用户名（Name）、全名（Full Name）、电子邮件、默认域（Domain）、以及所属组。用户名一旦被业务对象引用（如检出者、创建者、审批人），就不应再修改，否则历史记录会出现断链。默认域决定该用户创建的对象默认落在哪个域中，域又影响该对象的访问控制与索引策略，因此新建用户时必须确认其默认域与所在组织的域规划一致。

一个常见的教学示例是：为“结构设计部”新建用户 zhangsan，全名“张三”，默认域设为 /Default/Engineering，并加入组 CN_Design_Struct。创建完成后，用该账号登录并新建一个部件，检查部件的“域”字段是否为 /Default/Engineering，以此验证默认域配置生效。这一步看似简单，却是后续权限继承是否正确的起点。

组嵌套：用层级代替重复授权

组嵌套是 Windchill 权限治理中最有效的杠杆。其原理是：子组自动继承父组的权限，而父组不需要知道子组里有哪些人。典型结构是“公司级组 → 部门级组 → 项目级组”。例如 CN_Company 下挂 CN_Design，CN_Design 下挂 CN_Design_Struct 与 CN_Design_Elec。当公司发布一条“所有设计人员可读取通用标准库”的策略时，只需把权限授予 CN_Design，两个子组自动获得，无需逐组配置。

嵌套的深度建议控制在三到四层。层数过深会导致权限来源难以追溯：某用户为什么能访问某对象，需要沿组链逐层回溯。Windchill 提供“参与者权限报告”可以查看某用户的有效权限及其来源组，排障时应优先使用该报告，而不是凭记忆猜测。

动态组：让成员资格随属性自动变化

静态组需要管理员手工维护成员，人员一多就容易出现“人已转岗、组里还在”的脏数据。动态组通过规则自动计算成员：规则基于用户属性（如部门、职位、状态、地点）进行匹配，属性变化时成员资格自动更新。例如定义动态组 DG_Active_Designers，规则为“部门 = 结构设计 且 状态 = 在职”，则新入职的结构设计师只要属性正确，登录后即自动获得该组权限，无需管理员干预。

动态组的代价是规则复杂度与性能。规则条件越多，成员计算越慢；若规则引用了目录服务中不稳定的属性，还可能出现成员忽进忽出。因此建议动态组只用于“属性明确、变化可预期”的场景，例如按部门、按在职状态划分；而项目级、临时性的授权仍用静态组，便于精确控制。

目录服务集成：单一身份源

企业通常已有 AD 或 LDAP 作为统一身份源。Windchill 通过 JNDI 连接目录服务，可配置用户与组的同步。集成时要明确三件事：同步范围（哪些 OU 下的用户进入 Windchill）、属性映射（AD 的 sAMAccountName 映射为 Windchill 用户名，department 映射为部门属性）、同步方向（通常只读，Windchill 不反向写回 AD）。

一个可参考的配置片段如下，用于说明连接参数的组织方式（示例参数，非实测值）：

wt.org.ldap.serverUrl = ldap://ad.example.com:389
wt.org.ldap.baseDn = OU=Users,DC=example,DC=com
wt.org.ldap.userAttrMap = sAMAccountName=name, mail=email, department=department
wt.org.ldap.syncInterval = 3600
wt.org.ldap.readOnly = true

集成后应验证：在 AD 中新建一个测试用户，等待同步周期后，在 Windchill 参与者管理中确认该用户已出现，且部门属性正确；再将该用户在 AD 中禁用，确认 Windchill 侧同步为禁用状态。若同步失败，优先检查连接账号权限、BaseDN 是否正确、以及属性映射是否存在拼写差异。

账号生命周期管理：入职、在职、转岗、离职

账号治理要覆盖完整生命周期。入职时创建或同步账号并加入基础组；在职期间通过组变更调整权限，而不是直接给个人授权；转岗时先移出旧组、再加入新组，避免权限叠加；离职时禁用账号并移出所有组，但不要删除账号，因为历史对象仍引用该用户，删除会导致审计断链。

为便于执行，可参考以下账号生命周期检查清单（示例模板，可按组织调整）：

最后强调一个判断依据：任何用户权限问题，都应先查“有效权限报告”，确认权限来自哪个组、哪条策略，再决定是改组、改策略还是改用户属性。用户与用户组治理的本质，是让权限通过组结构流动，而不是散落在个人身上。做到这一点，后续的生命周期与权限审计才有稳定的基础。