Condividi tramite

Risolvere l'errore relativo ai diritti di accesso insufficienti

  • Articolo

Questione

Il provisioning degli utenti in ingresso verso Active Directory funziona come previsto per la maggior parte degli utenti. Tuttavia, per alcuni utenti, i log di provisioning visualizzano l'errore seguente:

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.

I log di provisioning visualizzano il codice di errore: HybridSynchronizationActiveDirectoryInsufficientAccessRights.

Causa

L'account GMSA dell'agente di provisioning provAgentgMSA$ per impostazione predefinita dispone dell'autorizzazione di lettura/scrittura per tutti gli oggetti utente nel dominio. Esistono due possibili cause che potrebbero causare l'errore dichiarato in precedenza.

  • Causa-1: l'oggetto utente fa parte di un'unità organizzativa che non eredita le autorizzazioni a livello di dominio.
  • Causa 2: l'oggetto utente appartiene a un gruppo di Active Directory protetto . Per impostazione predefinita, gli oggetti utente sono regolati dalle autorizzazioni associate a un contenitore speciale denominato AdminSDHolder. Questo spiega perché l'account provAgentgMSA$ non è in grado di aggiornare questi account appartenenti ai gruppi di Active Directory protetti. Potresti provare a sovrascrivere e fornire esplicitamente all'account provAgentgMSA$ l'accesso in scrittura agli account utente, ma questo non funzionerà. Per proteggere gli account utente con privilegi da un uso improprio delle autorizzazioni delegate, esiste un processo in background denominato SDProp che viene eseguito ogni 60 minuti e garantisce che gli utenti appartenenti a un gruppo protetto siano sempre gestiti dalle autorizzazioni definite nel contenitore AdminSDHolder. Anche l'approccio all'aggiunta dell'account provAgentgMSA$ al gruppo Domain Admin non funzionerà.

Risoluzione

Verificare prima di tutto ciò che causa il problema. Per verificare se Cause-1 è l'origine del problema:

  1. Apri la Console di gestione Utenti e Computer di Active Directory.
  2. Selezionare l'unità organizzativa associata all'utente.
  3. Fare clic con il pulsante destro del mouse e passare a Proprietà - Sicurezza> -> Avanzate. Se viene visualizzato il pulsante Abilita ereditarietà, conferma che Cause-1 è l'origine del problema.
  4. Selezionare Abilita ereditarietà in modo che le autorizzazioni a livello di dominio siano applicabili a questa unità organizzativa.

    Nota

    Ricordarsi di verificare l'intera gerarchia dal livello di dominio fino all'unità organizzativa che contiene gli account interessati. Per tutte le unità organizzative/contenitori padre deve essere abilitata l'ereditarietà, in modo che le autorizzazioni applicate a livello di dominio vengano propagate all'oggetto finale.

Se Cause-1 non è l'origine del problema, potenzialmente Cause-2 è l'origine del problema. Esistono due possibili opzioni di risoluzione.

opzione 1: Rimuovere l'utente interessato dal gruppo di Active Directory protetto Per trovare l'elenco degli utenti regolati da questa autorizzazione AdminSDHolder, Cx può richiamare il comando seguente:

Get-AdObject -filter {AdminCount -gt 0}

Articoli di riferimento:

  • Ecco un esempio di script PowerShell che può essere usato per rimuovere il flag AdminCount e riabilitare l'ereditarietà per gli utenti interessati.
  • Usare i passaggi descritti in questo articolo di - Trovare account orfani per trovare account orfani (account che non fanno parte di un gruppo protetto, ma hanno ancora il flag AdminCount impostato su 1)

l'opzione 1 potrebbe non funzionare sempre

Esiste un processo denominato Processo di propagazione del descrittore di sicurezza (SDPROP) eseguito ogni ora nel controller di dominio che contiene il ruolo FSMO dell'emulatore PDC. Si tratta di questo processo che imposta l'attributo AdminCount su 1. La funzione principale di SDPROP consiste nel proteggere gli account Active Directory con privilegi elevati. Garantisce che questi account non possano essere eliminati o abbiano i diritti modificati, accidentalmente o intenzionalmente, da utenti o processi con privilegi inferiori. Esiste un processo denominato Processo di propagazione del descrittore di sicurezza (SDPROP) eseguito ogni ora nel controller di dominio che contiene il ruolo FSMO dell'emulatore PDC. Si tratta di questo processo che imposta l'attributo AdminCount su 1. La funzione principale di SDPROP consiste nel proteggere gli account Active Directory con privilegi elevati. Il processo SDPROP garantisce che gli account non possano essere eliminati o avere diritti accidentalmente o modificati intenzionalmente da utenti o processi con privilegi inferiori.

Articoli di riferimento che illustrano in dettaglio il motivo:

opzione 2: modificare le autorizzazioni predefinite del contenitore AdminSDHolder

Se l'opzione 1 non è fattibile e non funziona come previsto, chiedere a Cx di rivolgersi all'amministratore di Active Directory e agli amministratori della sicurezza, se è autorizzato a modificare le autorizzazioni predefinite del contenitore AdminSDHolder. Questo articolo che illustra l'importanza del contenitore AdminSDHolder. Quando Cx ottiene l'approvazione interna per aggiornare le autorizzazioni del contenitore AdminSDHolder, esistono due modi per aggiornare le autorizzazioni.

  • Utilizzo di ADSIEdit come descritto nell'articolo .
  • Utilizzo dello script della riga di comando DSACLS. Di seguito è riportato uno script di esempio che può essere usato come punto di partenza e Cx può modificarlo in base ai requisiti.

$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

Se Cx necessita di assistenza per la risoluzione dei problemi relativi alle autorizzazioni di Active Directory locali, contattare il team di supporto di Windows Server. Questo articolo sui problemi di AdminSDHolder con microsoft Entra Connect include altri esempi sull'utilizzo di DSACLS.

opzione 3: Assegnare il controllo completo all'account provAgentgMSA

Assegnare autorizzazioni di controllo completo all'account provAgentGMSA. È consigliabile eseguire questo passaggio se si verificano problemi con lo spostamento di un oggetto utente da un'unità organizzativa contenitore a un'altra quando l'oggetto utente non appartiene a un gruppo di utenti protetto.

In questo scenario, chiedere a Cx di completare i passaggi seguenti e ripetere l'operazione di spostamento.

  1. Accedere al controller di dominio di Active Directory come amministratore.
  2. Aprire la riga di comando di PowerShell con run come amministratore.
  3. Al prompt di PowerShell eseguire il comando DSACLS seguente che concede Generic All/Full Control all'account GMSA dell'agente di provisioning. dsacls "dc=contoso,dc=com" /I:T /G "CN=provAgentgMSA,CN=Managed Service Accounts,DC=contoso,DC=com:GA"

Sostituire il dc=contoso,dc=com con il nodo radice o il contenitore dell'unità organizzativa appropriato. Se si usa un GMSA personalizzato, aggiornare il valore DN per provAgentgMSA.

opzione 4: ignorare l'account GMSA e usare l'account del servizio creato manualmente Questa opzione deve essere usata solo come soluzione temporanea per sbloccare fino a quando il problema di autorizzazione GMSA non viene esaminato e risolto. È consigliabile usare l'account GMSA. È possibile impostare l'opzione del Registro di sistema su ignorare la configurazione di GMSA e riconfigurare l'agente di provisioning di Microsoft Entra Connect per usare un account del servizio creato manualmente con le autorizzazioni appropriate.

Passaggi successivi