共用方式為


存取權限不足錯誤疑難排解

問題

將輸入使用者佈建至 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 是否為問題的來源:

  1. 請開啟 Active Directory 使用者和電腦管理主控台
  2. 選取與使用者相關聯的 OU。
  3. 以滑鼠右鍵按一下並瀏覽至 屬性 ->安全性 -> 進階。 如果顯示 [啟用繼承] 按鈕,則可確認 [原因-1] 是問題的來源。
  4. 按一下 [啟用繼承],讓網域層級權限適用於此 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 支援小組。 本文在 AdminSDHolder Microsoft Entra Connect 上有更多 DSACLS 使用方式範例。

選項 3:將完全控制權限指派給 provAgentgMSA 帳戶

完全控制權限指派至 provAgentGMSA 帳戶。 如果當使用者物件不屬於受保護的使用者群組時,將使用者物件從一個容器 OU 移至另一個容器 OU 時,建議您執行此步驟。

在此案例中,要求 Cx 完成下列步驟並重新測試移動作業。

  1. 以系統管理員身分登入 AD 網域控制站。
  2. 以系統管理員身分使用 run 開啟 PowerShell 命令列。
  3. 在 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 佈建代理程式,以使用正確權限手動建立服務帳戶。

下一步