Solução de problemas de sincronização de nuvem

A sincronização na nuvem tem muitas dependências e interações diferentes, o que pode originar vários problemas. Este artigo ajuda você a solucionar esses problemas. Ela mostra as áreas típicas para você se concentrar, como reunir informações adicionais e as várias técnicas que você pode usar para rastrear problemas.

Problemas do agente

Ao solucionar problemas do agente, você verifica se o agente foi instalado corretamente e se ele se comunica com o ID do Microsoft Entra. Em particular, as primeiras verificações que convém fazer no agente são:

• Ele está instalado?
• O agente está em execução localmente?
• O agente está no portal?
• O agente foi marcado como íntegro?

Você pode verificar esses itens no portal e no servidor local que está executando o agente.

Verificação do agente do centro de administração do Microsoft Entra

Dica

As etapas neste artigo podem variar ligeiramente com base no portal do qual você começa.

Para verificar se o Azure detecta o agente e se o agente está íntegro, siga estas etapas:

1. Entre no Centro de administração do Microsoft Entra como, no mínimo, um administrador híbrido.
2. Navegue até Identidade>Gerenciamento híbrido>Microsoft Entra Connect>Sincronização na nuvem.

3. Selecione sincronização na nuvem.
4. Você deverá ver os agentes que instalou. Verifique se o agente em questão está instalado. Em caso positivo, você verá o status ativo (verde) do agente.

Verificar as portas abertas necessárias

Verifique se o agente de provisionamento do Microsoft Entra consegue se comunicar com os data centers do Azure. Se houver um firewall no caminho, verifique se as seguintes portas para o tráfego de saída estão abertas:

Número da porta	Como ele é usado
80	Download das listas de certificados revogados (CRLs), enquanto valida o certificado TLS/SSL.
443	Manipulando toda a comunicação de saída com o serviço Proxy de Aplicativo.

Se o firewall impor o tráfego de acordo com os usuários de origem, abra também as portas 80 e 443 para o tráfego de serviços do Windows executados como um serviço de rede.

Permitir acesso às URLs

Permita o acesso às seguintes URLs:

URL	Porta	Como ele é usado
*.msappproxy.net *.servicebus.windows.net	443/HTTPS	Comunicação entre o conector e o serviço de nuvem do Proxy de Aplicativo.
crl3.digicert.com crl4.digicert.com ocsp.digicert.com crl.microsoft.com oneocsp.microsoft.com ocsp.msocsp.com	80/HTTP	O conector usa essas URLs para verificar certificados.
login.windows.net secure.aadcdn.microsoftonline-p.com *.microsoftonline.com *.microsoftonline-p.com *.msauth.net *.msauthimages.net *.msecnd.net *.msftauth.net *.msftauthimages.net *.phonefactor.net enterpriseregistration.windows.net management.azure.com policykeyservice.dc.ad.msft.net ctldl.windowsupdate.com www.microsoft.com/pkiops	443/HTTPS	O conector usa essas URLs durante o processo de registro.
ctldl.windowsupdate.com	80/HTTP	O conector usa essa URL durante o processo de registro.

Você poderá permitir conexões com *.msappproxy.net, *.servicebus.windows.net, e outras URLs anteriores, se o firewall ou proxy possibilitar a configuração de regras de acesso com base em sufixos de domínio. Caso contrário, será necessário permitir acesso aos Intervalos de IP do Azure e às marcas de serviço - nuvem pública. Os intervalos de IP são atualizados a cada semana.

Importante

Evite todas as formas de inspeção e interrupção embutida nas comunicações TLS de saída entre os conectores de rede privada do Microsoft Entra e os serviços em nuvem do proxy de aplicativos do Microsoft Entra.

Resolução de nomes DNS para pontos de extremidade de proxy de aplicativo do Microsoft Entra

Os registros DNS públicos para pontos de extremidade de proxy de aplicativo do Microsoft Entra são registros CNAME encadeados, apontando para um registro A. Isso garante a flexibilidade e a tolerância a falhas. É garantido que o conector de rede privada do Microsoft Entra sempre acesse nomes de host com os sufixos de domínio *.msappproxy.net ou *.servicebus.windows.net.

No entanto, durante a resolução de nomes, os registros CNAME podem conter registros DNS com nomes do host e sufixos diferentes. Devido a isso, é necessário garantir que o dispositivo possa resolver todos os registros da cadeia e permitir a conexão com os endereços IP resolvidos. Como os registros DNS na cadeia podem ser alterados periodicamente, não podemos fornecer nenhum registro DNS de lista.

No servidor local

Para verificar se o agente está em execução, siga estas etapas:

1. No servidor com o agente instalado, abra Serviços. Para fazer isso, vá para Iniciar>Executar>Services.msc.

2. Em Serviços, verifique se o Atualizador do agente do Microsoft Entra Connect e Agente de provisionamento do Microsoft Entra estão lá. Confirme também se o status deles é Em execução.

   

Problemas comuns de instalação do agente

As seções a seguir descrevem alguns problemas comuns de instalação do agente e as resoluções típicas desses problemas.

O agente falhou ao iniciar

Você pode receber uma mensagem de erro que declara:

Falha ao iniciar o serviço “Agente de Provisionamento do Microsoft Entra”. Verifique se você tem privilégios suficientes para iniciar serviços do sistema."

Esse problema geralmente é causado por uma política de grupo. A política pode impedir que as permissões sejam aplicadas à conta de entrada do Serviço do NT local criada pelo instalador (NT SERVICE\AADConnectProvisioningAgent). Essas permissões são necessárias para iniciar o serviço.

Para resolver esse problema, siga estas etapas:

1. Entre no servidor com uma conta de administrador.

2. Abra Serviços, vá para Iniciar>Executar>Services.msc.

3. Em Serviços, clique duas vezes no Agente de Provisionamento do Microsoft Entra.

4. Na guia Logon, altere Essa conta para um administrador de domínio. Em seguida, reinicie o serviço.

   

O agente atinge o tempo limite ou o certificado não é válido

Você pode receber a seguinte mensagem de erro ao tentar registrar o agente.

Esse problema geralmente ocorre porque o agente não consegue se conectar ao serviço de identidade híbrida. Para resolver esse problema, configure um proxy de saída.

O agente de provisionamento dá suporte para uso de um proxy de saída. Você pode configurá-lo editando o seguinte arquivo .config do agente: C:\Program Files\Microsoft Azure AD Connect Provisioning Agent\AADConnectProvisioningAgent.exe.config.

Adicione as seguintes linhas a ele, no final do arquivo, antes da marca </configuration> de fechamento. Substitua as variáveis [proxy-server] e [proxy-port] pelo nome do servidor proxy e pelos valores da porta.

    <system.net>
        <defaultProxy enabled="true" useDefaultCredentials="true">
            <proxy
                usesystemdefault="true"
                proxyaddress="http://[proxy-server]:[proxy-port]"
                bypassonlocal="true"
            />
        </defaultProxy>
    </system.net>

Falha no registro do agente com erro de segurança

Você pode receber uma mensagem de erro ao instalar o agente de provisionamento de nuvem. Esse problema normalmente é causado porque o agente não consegue executar os scripts de registro do PowerShell devido às políticas de execução locais do PowerShell.

Para resolver este problema, altere as políticas de execução do PowerShell no servidor. É necessário ter as políticas de usuário e computador definidas como Undefined ou RemoteSigned. Se elas estiverem definidas como Unrestricted, você verá esse erro. Para obter mais informações, consulte as políticas de execução do PowerShell.

Arquivos de log

Por padrão, o agente emite mensagens de erro mínimas e informações de rastreamento de pilha. Você pode encontrar esses logs de rastreamento na seguinte pasta: C:\ProgramData\Microsoft\Azure AD Connect Provisioning Agent\Trace.

Para coletar detalhes adicionais para solucionar problemas relacionados ao agente, siga estas etapas.

1. Instale o módulo AADCloudSyncTools PowerShell.
2. Use o Export-AADCloudSyncToolsLogs cmdlet do PowerShell para capturar as informações. Você pode usar as opções a seguir para ajustar a coleta de dados.
   • SkipVerboseTrace para exportar somente os logs atuais sem capturar logs detalhados (padrão = falso).
   • TracingDurationMins para especificar uma duração de captura diferente (padrão = 3 minutos).
   • OutputPath para especificar um caminho de saída diferente (padrão = pasta Documentos do usuário).

Problemas de sincronização de objeto

No portal, é possível usar os logs de provisionamento para ajudar a rastrear e solucionar os problemas de sincronização de objetos. Para exibir os logs, selecione Logs.

Os logs de provisionamento fornecem diversas informações sobre o estado dos objetos que estão sendo sincronizados entre seu ambiente do Active Directory local e o Azure.

Você pode filtrar a exibição para concentrar em problemas específicos, como datas. Você também pode pesquisar nos logs as atividades relacionadas a um objeto do Active Directory usando o ObjectGuid do seu Active Directory. Clique duas vezes em um evento individual para ver informações adicionais.

Essas informações fornecem etapas detalhadas e onde o problema de sincronização está ocorrendo. Dessa forma, você pode identificar o ponto exato do problema.

Objetos ignorados

Se tiver sincronizado usuários e grupos do Active Directory, talvez você não consiga localizar um ou mais grupos no Microsoft Entra ID. Isso pode se dever a uma sincronização que ainda não foi concluída ou ainda não foi atualizada com relação à criação do objeto no Active Directory, a um erro de sincronização que está bloqueando o objeto que está sendo criado no Microsoft Entra ID ou a uma regra de definição do escopo de regras de sincronização que pode ter sido aplicada excluindo o objeto.

Se você reiniciar a sincronização e, a seguir, quando o ciclo de provisionamento for concluído, pesquise no log de provisionamento as atividades relacionadas a um objeto que esteja usando o ObjectGuid do Active Directory desse objeto. Se um evento com uma identidade contendo apenas uma ID de Origem e um status Skipped estiver presente no log, isso poderá indicar que o agente filtrou o objeto do Active Directory porque ele estava fora do escopo.

Por padrão, as regras de definição de escopo excluem os seguintes objetos da sincronização com o Microsoft Entra ID:

• usuários, grupos e contatos com o IsCriticalSystemObject definido como TRUE, incluindo muitos dos grupos e usuários integrados no Active Directory
• objetos vítimas de replicação

Restrições adicionais podem estar presentes no esquema de sincronização.

Limite de exclusão de objeto do Microsoft Entra

Se você tiver uma topologia de implementação com o Microsoft Entra Connect e a Sincronização na nuvem do Microsoft Entra, ambos exportando para o mesmo locatário do Microsoft Entra, ou se você tiver migrado totalmente do Microsoft Entra Connect para a Sincronização na nuvem Microsoft Entra, poderá receber a seguinte mensagem de erro de exportação ao excluir ou mover vários objetos para do escopo definido:

Esse erro não está relacionado ao recurso de prevenção de exclusões acidentais da Sincronização na nuvem do Microsoft Entra Connect. Ele é disparado pelo recurso de prevenção de exclusão acidental definido no diretório do Microsoft Entra pelo Microsoft Entra Connect. Se você não tiver um servidor do Microsoft Entra Connect instalado do qual possa alternar o recurso, poderá usar o módulo "AADCloudSyncTools" do PowerShell instalado com o agente de sincronização na nuvem do Microsoft Entra Connect para desabilitar a configuração no locatário e permitir que as exclusões bloqueadas sejam exportadas após a confirmação de que são esperadas e devem ser permitidas. Use o seguinte comando:

Disable-AADCloudSyncToolsDirSyncAccidentalDeletionPrevention -tenantId "aaaabbbb-0000-cccc-1111-dddd2222eeee"

Durante o próximo ciclo de provisionamento, os objetos marcados para exclusão serão excluídos do diretório do Microsoft Entra.

Provisionamento de problemas em quarentena

A sincronização na nuvem monitora a integridade da configuração e coloca os objetos não íntegros em um estado de quarentena. Se a maioria ou todas as chamadas feitas no sistema de destino falharem consistentemente devido a um erro (por exemplo, credenciais de administrador inválidas), o trabalho de sincronização será marcado como em quarentena.

Ao selecionar o status, você poderá ver informações adicionais sobre a quarentena. Você também pode obter o código de erro e a mensagem.

Clicar com o botão direito do mouse no status exibirá opções adicionais para:

• Exibir os logs de provisionamento.
• Exibir os agentes.
• Limpar a quarentena.

Resolver uma quarentena

Há duas maneiras diferentes de resolver uma quarentena. Você pode limpar a quarentena ou reiniciar o trabalho de provisionamento.

Limpar a quarentena

Para limpar a marca d'água e executar uma sincronização delta no trabalho de provisionamento após a verificação, clique com o botão direito do mouse no status e selecioneLimpar quarentena.

Você verá um aviso de que a quarentena está sendo limpa.

Em seguida, você deve ver o status do seu agente como íntegro.

Reiniciar o trabalho de provisionamento

Use o portal para reiniciar o trabalho de provisionamento. Na página de configuração do agente, selecione Reiniciar a sincronização.

Como alternativa, é possível usar o Microsoft Graph para reiniciar o trabalho de provisionamento. Você tem o controle total sobre o que reinicia. Você pode optar por limpar:

• O caução, para reiniciar o contador de caução acumulado no status de quarentena.
• A quarentena, para remover o aplicativo da quarentena.
• As marcas d'água.

Envie a seguinte solicitação:

POST /servicePrincipals/{id}/synchronization/jobs/{jobId}/restart

Reparar a conta de serviço de sincronização na nuvem

Se for necessário reparar a conta de serviço de sincronização na nuvem, você poderá usar o comando Repair-AADCloudSyncToolsAccount.

1. Instale o módulo AADCloudSyncTools PowerShell.

2. Em uma sessão do PowerShell com privilégios administrativos, digite ou copie e cole o seguinte:

   Connect-AADCloudSyncTools
   

3. Insira suas credenciais de Administrador Global do Microsoft Entra.

4. Digite ou copie e cole o seguinte:

   Repair-AADCloudSyncToolsAccount
   

5. Quando concluído, uma informação de que a conta foi reparada com êxito será exibida.

write-back de senha

Para habilitar e usar o write-back de senha com sincronização na nuvem, tenha em mente o seguinte:

• Se for necessário atualizar as permissões de gMSA, poderá demorar uma hora ou mais até que essas permissões sejam replicadas em todos os objetos no diretório. Se você não atribuir essas permissões, o write-back poderá parecer configurado corretamente, mas, os usuários poderão encontrar erros ao atualizar as senhas locais da nuvem. As permissões precisam ser aplicadas para que esse objeto e todos os objetos descendentes de Não Permitir Expiração de Senha sejam exibidos.
• Se as senhas de algumas contas de usuário não forem gravadas no diretório local, verifique se a herança não está desabilitada para a conta no ambiente do AD DS (Serviços de Domínio Active Directory) local. As permissões de gravação para senhas devem ser aplicadas aos objetos descendentes para que o recurso funcione corretamente.
• As políticas de senha no ambiente AD DS local podem impedir que as redefinições de senha sejam processadas corretamente. Se você estiver testando esse recurso e quiser redefinir as senhas dos usuários mais de uma vez por dia, a política de grupo para a idade mínima da senha deve ser definida como 0. Você pode encontrar essa configuração no seguinte local: Configuração do Computador>Políticas>Configurações do Windows>Configurações de Segurança>Políticas de Conta, em gpmc.msc.
  • Se você atualizar a política de grupo, aguarde a política atualizada ser replicada ou use o comando gpupdate /force.
  • Para que as senhas sejam alteradas imediatamente, a idade mínima da senha deverá ser definida como 0. No entanto, se os usuários aderirem às políticas locais, e a idade mínima da senha for definida como um valor maior que 0, o write-back de senha não funcionará depois que as políticas locais forem avaliadas.

Próximas etapas

• Limitações conhecidas
• Códigos de erro