Risolvere l'errore relativo ai diritti di accesso insufficienti

  • Articolo

Problema

Il provisioning utenti in ingresso in 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

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

  • 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. È possibile provare a eseguire l'override e fornire in modo esplicito all'account l'accesso provAgentgMSA$ 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 AdminSDHolder contenitore. Anche l'approccio di aggiunta dell'account provAgentgMSA$ al gruppo domain Amministrazione non funzionerà.

Risoluzione

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

  1. Aprire Utenti e computer di Active Directory Management Console.
  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. Fare clic su 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 di utenti regolati da questa AdminSDHolder autorizzazione, Cx può richiamare il comando seguente:

Get-AdObject -filter {AdminCount -gt 0}

Articoli di riferimento:

  • Ecco un esempio di script di PowerShell che può essere usato per cancellare il flag Amministrazione Count e riabilitare l'ereditarietà sugli utenti interessati.
  • Usare i passaggi descritti in questo articolo - Trovare account orfani per trovare account orfani (account che non fanno parte di un gruppo protetto, ma hanno ancora il flag Amministrazione Count 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, assicurandosi che non possano essere eliminati o avere 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 Amministrazione SDHolder

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

  • Uso ADSIEdit di come descritto in questo articolo.
  • Uso dello DSACLS script della riga di comando. 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 Amministrazione SDHolder con Microsoft Entra Connessione include altri esempi sull'utilizzo di DSACLS.

Opzione 3: Assegnare il controllo completo all'account provAgentgMSA

Assegnare autorizzazioni 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 con il nodo radice o il contenitore dell'unità dc=contoso,dc=com 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 alternativa temporanea per sbloccare fino a quando non viene esaminato e risolto il problema di autorizzazione GMSA. È consigliabile usare l'account GMSA. È possibile impostare l'opzione del Registro di sistema per ignorare la configurazione GMSA e riconfigurare l'agente di provisioning di Microsoft Entra Connessione per usare un account del servizio creato manualmente con le autorizzazioni appropriate.

Passaggi successivi