問题
对大多数用户来说，对 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。
- 右键单击并导航到“属性 - 安全性 ->> 高级”。 如果显示 “启用继承 ”按钮，它会确认原因 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 预配代理，以使用具有适当权限的手动创建的服务帐户。