Partilhar via

Solucionar problemas de erro de direitos de acesso insuficientes

  • Artigo

Problema

O provisionamento de usuários de entrada para o Ative 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.

Motivo

A conta provAgentgMSA$ GMSA do Agente de Provisionamento por padrão tem permissão de leitura/gravação para todos os objetos de usuário no domínio. Existem 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 no nível do domínio.
  • Causa-2: O objeto de usuário pertence a um grupo protegido do Ative Directory. Por design, os objetos de usuário são governados por permissões associadas a um contêiner especial chamado AdminSDHolder. Isso explica por que a provAgentgMSA$ conta não consegue atualizar essas contas pertencentes a grupos protegidos do Ative Directory. Você pode tentar substituir e fornecer explicitamente o acesso de gravação da provAgentgMSA$ conta às contas de usuário, mas isso não funcionará. Para proteger contas de usuário privilegiadas contra 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 AdminSDHolder usuários pertencentes a um grupo protegido sejam sempre gerenciados por permissões definidas no contêiner. Mesmo a abordagem de adicionar a provAgentgMSA$ conta 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 Ative Directory.
  2. Selecione a UO associada ao usuário.
  3. Clique com o botão direito do rato e navegue até Propriedades -> Segurança -> Avançadas. Se o botão Ativar herança for mostrado, ele confirmará que a Causa-1 é a origem do problema.
  4. Clique em Ativar herança para que as permissões de nível de domínio sejam aplicáveis a esta UO.

    Nota

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

Se a Causa-1 não for a fonte do problema, então potencialmente a Causa-2 é a origem do problema. Existem duas opções de resolução possíveis.

Opção 1: Remover o usuário afetado do grupo AD protegido Para localizar a lista de usuários regidos por essa 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 reativar a herança em usuários afetados.
  • Use as etapas documentadas neste artigo - Localizar contas órfãs para localizar 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 pode nem sempre funcionar

Há um processo chamado The Security Descriptor Propagation (SDPROP) que é executado a cada hora no controlador de domínio que detém a função FSMO do emulador PDC. É esse processo que define o AdminCount atributo como 1. A principal função do SDPROP é proteger contas altamente privilegiadas do Ative Directory, garantindo que elas não possam ser excluídas ou ter direitos modificados, acidental ou intencionalmente, por usuários ou processos com menos privilégios. Há um processo chamado The Security Descriptor Propagation (SDPROP) que é executado a cada hora no controlador de domínio que detém a função FSMO do emulador PDC. É esse processo que define o AdminCount atributo como 1. A principal função do SDPROP é proteger contas altamente privilegiadas do Ative Directory. O processo SDPROP garante que as contas não possam ser excluídas ou ter direitos acidental ou intencionalmente modificados 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 como esperado, peça ao Cx para verificar com o administrador do AD e os administradores de segurança se eles têm permissão para modificar as permissões padrão do AdminSDHolder contêiner. Este artigo que explica a importância do AdminSDHolder recipiente. Depois que o Cx obtém aprovação interna para atualizar as permissões de AdminSDHolder contêiner, há duas maneiras de atualizar as permissões.

  • Usando ADSIEdit como descrito neste artigo.
  • Usando DSACLS script de linha de comando. Aqui está um script de exemplo que pode ser usado como um ponto de partida e 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 AdminSDHolder com o Microsoft Entra Connect tem mais exemplos sobre o uso de DSACLS.

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

Atribua permissões de Controle Total à provAgentGMSA conta. Recomendamos esta etapa se houver problemas com a movimentação de 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.

Nesse cenário, peça a Cx para concluir as etapas a seguir e testar novamente a operação de movimentação.

  1. Inicie sessão 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 seguinte comando DSACLS que concede Controle Total/Total 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 DN para provAgentgMSA.

Opção 4: Ignorar a conta GMSA e usar a conta de serviço criada manualmente Esta opção só deve ser usada como uma solução 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 de 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óximos passos