Compartilhar via

Solucionar problemas de erro de direitos de acesso insuficientes

  • Artigo

Problema

O provisionamento de usuário de entrada para o Active Directory está funcionando conforme o esperado para a maioria dos usuários. Mas para alguns usuários, os logs de provisionamento exibem o seguinte erro:

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.

Os logs de provisionamento exibem o código de erro: HybridSynchronizationActiveDirectoryInsufficientAccessRights.

Causa

Por padrão, a conta GMSA do Agente de Provisionamento provAgentgMSA$ tem permissão de leitura/gravação para todos os objetos de usuário no domínio. Há duas causas possíveis que podem levar ao erro acima.

  • Causa-1: o objeto de usuário faz parte de uma UO que não herda permissões de nível de domínio.
  • Causa-2: o objeto de usuário pertence a um grupo protegido do Active Directory. Por design, os objetos de usuário são controlados por permissões associadas a um contêiner especial chamado AdminSDHolder. Isso explica por que a conta provAgentgMSA$ não consegue atualizar essas contas pertencentes a grupos protegidos do Active Directory. Você pode tentar substituir e fornecer explicitamente o provAgentgMSA$ acesso de gravação da conta às contas de usuário, mas isso não funcionará. Para proteger contas de usuário com privilégios de um uso indevido de permissões delegadas, há um processo em segundo plano chamado SDProp que é executado a cada 60 minutos e garante que os usuários pertencentes a um grupo protegido sejam sempre gerenciados por permissões definidas no contêiner AdminSDHolder. Até mesmo a abordagem de adicionar a conta provAgentgMSA$ ao grupo Administrador do Domínio não funcionará.

Resolução

Primeiro confirme o que está causando o problema. Para verificar se a Causa-1 é a origem do problema:

  1. Abra o Console de gerenciamento de usuários e computadores do Active Directory.
  2. Selecione a UO associada ao usuário.
  3. Clique com o botão direito do mouse e navegue até Propriedades –> Segurança –> Avançado. Se o botão Habilitar herança for mostrado, isso confirma que a Causa-1 é a origem do problema.
  4. Clique em Habilitar Herança para que as permissões de nível de domínio sejam aplicáveis a essa UO.

    Observação

    Lembre-se de verificar toda a hierarquia do nível de domínio até a UO que contém as contas afetadas. Todas as OUs/Contêineres Pai devem ter a herança habilitada para que as permissões aplicadas no nível do domínio possam ser colocadas em cascata até o objeto final.

Se a Causa-1 não for a origem do problema, potencialmente a Causa-2 será a origem do problema. Há duas opções de resolução possíveis.

Opção 1: Remover usuário afetado do grupo AD protegido Para encontrar a lista de usuários regidos por esta AdminSDHolder permissão, Cx pode invocar o seguinte comando:

Get-AdObject -filter {AdminCount -gt 0}

Artigos de referência:

  • Veja um exemplo de script do PowerShell que pode ser usado para limpar o sinalizador AdminCount e reabilitar a herança em usuários afetados.
  • Use as etapas documentadas neste artigo – Localizar Contas Órfãs para encontrar contas órfãs (contas que não fazem parte de um grupo protegido, mas ainda têm o sinalizador AdminCount definido como 1)

A opção 1 talvez não funcione sempre

Há um processo chamado Propagação de Descritor de Segurança (SDPROP) que é executado a cada hora no controlador de domínio que contém a função FSMO do emulador PDC. É esse processo que define o atributo AdminCount como 1. A função principal do SDPROP é proteger contas altamente privilegiadas do Active Directory, garantindo que elas não possam ser excluídas ou tenham direitos modificados, acidental ou intencionalmente, por usuários ou processos com menos privilégios. Há um processo chamado Propagação de Descritor de Segurança (SDPROP) que é executado a cada hora no controlador de domínio que contém a função FSMO do emulador PDC. É esse processo que define o atributo AdminCount como 1. A principal função do SDPROP é proteger contas altamente privilegiadas do Active Directory. O processo SDPROP garante que as contas não possam ser excluídas ou ter direitos modificados acidental ou intencionalmente por usuários ou processos com menos privilégios.

Artigos de referência que explicam o motivo em detalhes:

Opção 2: modificar as permissões padrão do contêiner AdminSDHolder

Se a opção 1 não for viável e não funcionar conforme o esperado, peça ao Cx para verificar com seus administradores de segurança e administradores do AD, se eles tiverem permissão para modificar as permissões padrão do contêiner AdminSDHolder. Este artigo que explica a importância do contêiner AdminSDHolder. Depois que o Cx obtém aprovação interna para atualizar as permissões do contêiner AdminSDHolder, há duas maneiras de atualizar as permissões.

  • Usando ADSIEdit conforme descrito neste artigo.
  • Usar o script de linha de comando DSACLS. Aqui está um exemplo de script que pode ser usado como ponto de partida, e o Cx pode ajustá-lo de acordo com seus requisitos.

$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 o Cx precisar de mais ajuda para solucionar problemas de permissões do AD local, entre em contato com a equipe de Suporte do Windows Server. Este artigo sobre problemas do AdminSDHolder com o Microsoft Entra Connect tem mais exemplos sobre o uso do DSACLS.

Opção 3: Atribuir controle total à conta provAgentgMSA

Atribua permissões de Controle Total à provAgentGMSA conta. Recomendamos esta etapa se houver problemas ao mover um objeto de usuário de uma UO de contêiner para outra quando o objeto de usuário não pertencer a um grupo de usuários protegido.

Neste cenário, peça ao Cx que conclua as etapas a seguir e teste novamente a operação de movimentação.

  1. Faça logon no controlador de domínio do AD como administrador.
  2. Abra a linha de comando do PowerShell com run como administrador.
  3. No prompt do PowerShell, execute o comando DSACLS a seguir que concede Controle Total/Tudo Genérico à conta GMSA do agente de provisionamento. dsacls "dc=contoso,dc=com" /I:T /G "CN=provAgentgMSA,CN=Managed Service Accounts,DC=contoso,DC=com:GA"

Substitua o dc=contoso,dc=com pelo nó raiz ou pelo contêiner de UO apropriado. Se você estiver usando um GMSA personalizado, atualize o valor de DN de provAgentgMSA.

Opção 4: ignorar a conta GMSA e usar a conta de serviço criada manualmente Essa opção só deve ser usada como uma solução alternativa temporária para desbloquear até que o problema de permissão do GMSA seja investigado e resolvido. Nossa recomendação é usar a conta GMSA. Você pode definir a opção do registro para ignorar a configuração do GMSA e reconfigurar o agente de provisionamento do Microsoft Entra Connect para usar uma conta de serviço criada manualmente com as permissões corretas.

Próximas etapas