排查访问权限不足错误
问题
对大多数用户来说，对 Active Directory 的入站用户预配按预期方式工作。 但对于某些用户，预配日志会显示以下错误：
ERROR: InsufficientAccessRights-SecErr: The user has insufficient access rights.. Access is denied. \nError Details: Problem 4003 - INSUFF_ACCESS_RIGHTS.
OR
ERROR:
"Message":"The user has insufficient access rights.",
"ResponseResultCode":"InsufficientAccessRights",
"ResponseErrorMessage":"00002098: SecErr: DSID-03150F94, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0",
The user has insufficient access rights.
预配日志显示错误代码：HybridSynchronizationActiveDirectoryInsufficientAccessRights。
原因
默认情况下，预配代理 GMSA 帐户 provAgentgMSA$ 对域中的所有用户对象具有读/写权限。 有两个可能的原因可能导致上述错误。
- 原因 1：用户对象是不继承域级权限的 OU 的一部分。
- 原因 2：用户对象属于受保护的 Active Directory 组。 根据设计，用户对象由与名为
AdminSDHolder的特殊容器关联的权限控制。 这解释了provAgentgMSA$帐户无法更新属于受保护 Active Directory 组的这些帐户的原因。 可以尝试替代并显式提供provAgentgMSA$帐户对用户帐户的写入访问权限，但这不会起作用。 为了保护特权用户帐户免受委托权限的滥用，有一个名为 SDProp 的后台进程，该进程每 60 分钟运行一次，并确保属于受保护组的用户始终由AdminSDHolder容器上定义的权限进行管理。 即使是将provAgentgMSA$帐户添加到域管理员组的方法也不起作用。
解决方法
首先确认导致问题的原因。 若要检查原因 1 是否是问题的根源：
- 打开“Active Directory 用户和计算机”控制台。
- 选择与用户关联的 OU。
- 右键单击并导航到“属性”->“安全性”->“高级”。 如果显示了“启用继承”按钮，则它确认 Cause-1 是问题的根源。
- 单击“启用继承”，使域级别权限适用于此 OU。
注意
请记得验证整个层次结构，从域级别到包含受影响帐户的 OU。 所有父 OU/容器都必须启用继承，以便在域级别应用的权限可以向下级联到最终对象。
如果原因 1 不是问题的根源，则原因 2 可能是问题的根源。 有两种可能的解决方法选项。
选项 1：从受保护的 AD 组中移除受影响的用户 若要查找受此 AdminSDHolder 权限控制的用户的列表，Cx 可以调用以下命令：
Get-AdObject -filter {AdminCount -gt 0}
参考文章：
- 下面是一个 PowerShell 脚本示例，可用于清除 AdminCount 标志，并重新启用受影响用户的继承。
- 使用本文 - 查找孤立帐户中所述的步骤查找孤立帐户（不属于受保护组的帐户，但仍将 AdminCount 标志设置为 1）
选项 1 可能并不总是起作用
有一个进程称为安全描述符传播 (SDPROP) 进程，该进程在具有 PDC 模拟器 FSMO 角色的域控制器上每小时运行一次。 正是此进程将 AdminCount 属性设置为 1。 SDPROP 的主要功能是保护具有高度特权的 Active Directory 帐户，确保权限较低的用户或进程不会意外或故意删除或修改这些帐户的权限。
有一个进程称为安全描述符传播 (SDPROP) 进程，该进程在具有 PDC 模拟器 FSMO 角色的域控制器上每小时运行一次。 正是此进程将 AdminCount 属性设置为 1。 SDPROP 的主要功能是保护高特权 Active Directory 帐户。 SDPROP 进程可确保帐户无法被意外删除或权限被具有较少特权的用户或进程有意或无意修改。
详细解释原因的参考文章：
选项 2：修改 AdminSDHolder 容器的默认权限
如果选项 1 不可行且无法按预期工作，请让 Cx 与他们的 AD 管理员和安全管理员核实是否允许他们修改 AdminSDHolder 容器的默认权限。 本文介绍 AdminSDHolder 容器的重要性。 Cx 获得内部批准以更新 AdminSDHolder 容器权限后，可通过两种方式更新权限。
- 使用本文中所述的
ADSIEdit。 - 使用
DSACLS命令行脚本。 下面是一个示例脚本，可用作起点，Cx 可以根据要求对其进行调整。
$dcFQDN = "<FQDN Of The Nearest RWDC Of Domain>"
$domainDN = "<Domain Distinguished Name>"
$domainNBT = "<Domain NetBIOS Name>"
$dsaclsCMD = "DSACLS '\\$dcFQDN\CN=AdminSDHolder,CN=System,$domainDN' /G '$domainNBT\provAgentgMSA$:RPWP;<Attribute To Write To>'"
Invoke-
Expression $dsaclsCMD | Out-Null
如果 Cx 需要更多有关排查本地 AD 权限问题的帮助，请与 Windows Server 支持团队联系。 这篇关于 Microsoft Entra Connect 的 AdminSDHolder 问题的文章提供了有关 DSACLS 用法的更多示例。
选项 3：为 provAgentgMSA 帐户分配完全控制权
为 provAgentGMSA 帐户分配完全控制权限。 如果当用户对象不属于受保护的用户组时，将用户对象从一个容器 OU 移到另一个容器 OU 出现问题，则建议执行此步骤。
在此方案中，请让 Cx 完成以下步骤并重新测试移动操作。
- 以管理员身份登录到 AD 域控制器。
- 使用
run作为管理员打开 PowerShell 命令行。 - 在 PowerShell 提示符下，运行以下 DSACLS 命令，该命令向预配代理 GMSA 帐户授予通用全部/完全控制权限。
dsacls "dc=contoso,dc=com" /I:T /G "CN=provAgentgMSA,CN=Managed Service Accounts,DC=contoso,DC=com:GA"
将 dc=contoso,dc=com 替换为根节点或相应的 OU 容器。 如果使用自定义 GMSA，请更新 provAgentgMSA 的 DN 值。
选项 4：跳过 GMSA 帐户并使用手动创建的服务帐户 在调查和解决 GMSA 权限问题之前，应仅将此选项用作取消阻止的临时解决方法。 建议使用 GMSA 帐户。 可以设置注册表选项以跳过 GMSA 配置，并将 Microsoft Entra Connect 预配代理重新配置为使用具有适当权限的手动创建的服务帐户。