Partage via

Résoudre l’erreur des droits d’accès insuffisants

  • Article

Problème

Le provisionnement d’utilisateurs entrants vers Active Directory fonctionne comme prévu pour la plupart des utilisateurs. Toutefois, pour certains utilisateurs, les journaux d’approvisionnement affichent l’erreur suivante :

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.

Les journaux d’approvisionnement affichent le code d’erreur : HybridSynchronizationActiveDirectoryInsufficientAccessRights.

Cause

Par défaut, le compte provAgentgMSA$ GMSA de l’agent d’approvisionnement dispose d’une autorisation de lecture/écriture sur tous les objets utilisateur du domaine. Il existe deux causes possibles qui peuvent entraîner l’erreur ci-dessus.

  • Cause 1 : L’objet utilisateur fait partie d’une unité d’organisation qui n’hérite pas des autorisations au niveau du domaine.
  • Cause 2 : l’objet utilisateur appartient à un groupe Active Directory protégé. De par leur conception, les objets utilisateur sont régis par des autorisations associées à un conteneur spécial appelé AdminSDHolder. Cela explique pourquoi le provAgentgMSA$ compte ne peut pas mettre à jour ces comptes appartenant à des groupes Active Directory protégés. Vous pouvez essayer de remplacer et de fournir explicitement au compte provAgentgMSA$ un accès en écriture aux comptes d'utilisateurs, mais cela ne fonctionnera pas. Pour sécuriser les comptes d’utilisateurs privilégiés contre une mauvaise utilisation des autorisations déléguées, il existe un processus en arrière-plan appelé SDProp qui s’exécute toutes les 60 minutes et garantit que les utilisateurs appartenant à un groupe protégé sont toujours gérés par les autorisations définies sur le AdminSDHolder conteneur. Même l’approche consistant à ajouter le provAgentgMSA$ compte au groupe Domain Administration ne fonctionnera pas.

Résolution

Commencez par vérifier ce qui est à l’origine du problème. Pour vérifier si la cause 1 est la source du problème :

  1. Ouvrez la console de gestion des utilisateurs et ordinateurs Active Directory.
  2. Sélectionnez l’unité d’organisation associée à l’utilisateur.
  3. Cliquez avec le bouton droit et accédez à Propriétés -> Sécurité -> Avancé. Si le bouton Activer l'héritage s'affiche, ça confirme que la Cause-1 est la source du problème.
  4. Cliquez sur Activer l’héritage pour que les autorisations au niveau du domaine s’appliquent à cette unité d’organisation.

    Notes

    N’oubliez pas de vérifier l’ensemble de la hiérarchie, du niveau du domaine jusqu’à l’unité d’organisation qui contient les comptes affectés. L’héritage doit être activé pour toutes les unités d’organisation/conteneurs parentes afin que les autorisations appliquées au niveau du domaine puissent descendre en cascade vers l’objet final.

Si la Cause 1 n’est pas la source du problème, la cause 2 est potentiellement la source du problème. Il existe deux options de résolution possibles.

Option 1 : Supprimer l'utilisateur concerné du groupe AD protégé. Pour trouver la liste des utilisateurs régis par cette autorisation AdminSDHolder, Cx peut appeler la commande suivante :

Get-AdObject -filter {AdminCount -gt 0}

Articles de référence :

  • Voici un exemple de script PowerShell qui peut être utilisé pour effacer l’indicateur AdminCount et réactiver l’héritage sur les utilisateurs concernés.
  • Utilisez les étapes décrites dans cet article : Rechercher des comptes orphelins pour rechercher des comptes orphelins (les comptes qui ne font pas partie d’un groupe protégé, mais dont l’indicateur AdminCount est toujours défini sur 1)

L’option 1 peut ne pas toujours fonctionner

Il existe un processus appelé Processus SDPROP (Security Descriptor Propagation) qui s’exécute toutes les heures sur le contrôleur de domaine qui détient le rôle FSMO de l’émulateur PDC. C’est ce processus qui définit l’attribut AdminCount sur 1. La fonction main de SDPROP consiste à protéger les comptes Active Directory hautement privilégiés, en veillant à ce qu’ils ne puissent pas être supprimés ou modifiés, accidentellement ou intentionnellement, par des utilisateurs ou des processus avec moins de privilèges. Il existe un processus appelé Processus SDPROP (Security Descriptor Propagation) qui s’exécute toutes les heures sur le contrôleur de domaine qui détient le rôle FSMO de l’émulateur PDC. C’est ce processus qui définit l’attribut AdminCount sur 1. La fonction principale de SDPROP est de protéger les comptes Active Directory hautement privilégiés. Le processus SDPROP garantit que les comptes ne peuvent pas être supprimés ou que leurs droits ne sont pas modifiés accidentellement ou intentionnellement par des utilisateurs ou des processus disposant de moins de privilèges.

Articles de référence qui expliquent la raison en détail :

Option 2 : Modifier les autorisations par défaut du conteneur AdminSDHolder

Si l’option 1 n’est pas possible et ne fonctionne pas comme prévu, demandez à Cx de vérifier avec leur administrateur AD et leurs administrateurs de sécurité s’ils sont autorisés à modifier les autorisations par défaut du AdminSDHolder conteneur. Cet article explique l’importance du AdminSDHolder conteneur. Une fois que Cx obtient l’approbation interne pour mettre à jour les autorisations de AdminSDHolder conteneur, il existe deux façons de mettre à jour les autorisations.

  • Utilisez ADSIEdit comme présenté dans cet article.
  • Utilisez l’outil en ligne de commande DSACLS. Voici un exemple de script qui peut être utilisé comme point de départ et Cx peut l’ajuster en fonction de ses besoins.

$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

Si le Cx a besoin d’aide supplémentaire pour résoudre les problèmes liés aux autorisations AD locales, faites appel à l’équipe du support technique Windows Server. Cet article sur les problèmes AdminSDHolder avec Microsoft Entra Connect contient d’autres exemples d’utilisation de DSACLS.

Option 3 : Affecter le contrôle total au compte provAgentgMSA

Attribuez des autorisations de contrôle total au provAgentGMSA compte. Nous recommandons cette étape en cas de problèmes liés au déplacement d’un objet utilisateur d’une unité d’organisation de conteneur à une autre lorsque l’objet utilisateur n’appartient pas à un groupe d’utilisateurs protégé.

Dans ce scénario, demandez à Cx d’effectuer les étapes suivantes et de retester l’opération de déplacement.

  1. Connectez-vous au contrôleur de domaine AD en tant qu’administrateur.
  2. Ouvrez la ligne de commande PowerShell avec run en tant qu'administrateur.
  3. À l’invite PowerShell, exécutez la commande DSACLS suivante qui accorde le contrôle général/total générique au compte GMSA de l’agent d’approvisionnement. dsacls "dc=contoso,dc=com" /I:T /G "CN=provAgentgMSA,CN=Managed Service Accounts,DC=contoso,DC=com:GA"

Remplacez par dc=contoso,dc=com votre nœud racine ou le conteneur d’unité d’organisation approprié. Si vous utilisez un GMSA personnalisé, mettez à jour la valeur DN pour provAgentgMSA.

Option 4 : Ignorer le compte GMSA et utiliser un compte de service créé manuellement Cette option doit uniquement être utilisée comme solution de contournement temporaire pour débloquer la situation jusqu’à ce que le problème d’autorisation GMSA soit examiné et résolu. Nous vous recommandons d’utiliser le compte GMSA. Vous pouvez définir l’option de Registre pour ignorer la configuration GMSA et reconfigurer l’agent d’approvisionnement Microsoft Entra Connect pour utiliser un compte de service créé manuellement avec les autorisations appropriées.

Étapes suivantes