問題
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$新增至 Domain Admin 群組的方法即使如此也無法運作。
解決辦法
首先確認造成問題的原因。 若要檢查 Cause-1 是否為問題的來源：
- 開啟 Active Directory 使用者和電腦管理控制台。
- 選取與使用者相關聯的 OU。
- 以滑鼠右鍵按兩下並流覽至 [屬性 -> 安全性 -> 進階]。 如果顯示 [ 啟用繼承] 按鈕，它會確認 [原因 1] 是問題的來源。
- 選取 [啟用繼承 ]，讓網域層級許可權適用於此 OU。
備註
請記得確認整個階層，從網域層級到包含受影響帳戶的部門單位（OU）。 所有父 OU/容器都必須啟用繼承，因此在網域層級套用的許可權可能會串聯至最終物件。
如果 Cause-1 不是問題的來源，則可能原因 2 是問題的來源。 有兩個可能的解決選項。
選項 1：從受保護的 AD 群組移除受影響的使用者 若要尋找此 AdminSDHolder 權限所控管的使用者清單，Cx 可以叫用下列命令：
Get-AdObject -filter {AdminCount -gt 0}
參考文章：
- 以下是可用來清除 AdminCount 旗標並重新啟用受影響用戶繼承的 PowerShell 腳本範例 。
- 使用本文所述的步驟 - 尋找孤立帳戶 來尋找孤立帳戶（不屬於受保護群組的帳戶，但仍將 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"
使用您的根節點或適當的 OU 容器替換dc=contoso,dc=com。 如果您使用自定義 GMSA，請更新 provAgentgMSA 的 DN 值。
選項 4：略過 GMSA 帳戶並使用手動建立的服務帳戶 只有在調查並解決 GMSA 許可權問題之前，此選項才應作為解除封鎖的暫時因應措施。 我們建議使用 GMSA 帳戶。 您可以設定登錄選項 來略過 GMSA 設定 ，並重新設定 Microsoft Entra Connect 布建代理程式，以使用具有正確許可權的手動建立服務帳戶。