evento
9/04, 15 - 10/04, 12
Codifique o futuro com IA e conecte-se com colegas e especialistas em Java no JDConf 2025.
Registar-se agoraSolução de problemas de sincronização na nuvem
A sincronização na nuvem tem muitas dependências e interações diferentes, o que pode dar origem a vários problemas. Este artigo ajuda você a solucionar esses problemas. Ele apresenta as áreas típicas nas quais você deve se concentrar, como coletar informações adicionais e as várias técnicas que você pode usar para rastrear problemas.
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, algumas das primeiras coisas que você deseja verificar com o agente são:
- Está instalado?
- O agente está a funcionar localmente?
- O agente está no portal?
- O agente está marcado como saudável?
Você pode verificar esses itens no portal e no servidor local que está executando o agente.
Para verificar se o Azure deteta o agente e se o agente está íntegro, siga estas etapas:
- Entre no centro de administração do Microsoft Entra como pelo menos um Administrador Híbrido.
- Navegue até Identidade>Gerenciamento Híbrido>Microsoft Entra Connect>Sincronização na Nuvem.
- Selecione sincronização na nuvem.
- Você deve ver os agentes que você instalou. Verifique se o agente em questão está lá. Se tudo estiver bem, você verá o status ativo (verde) para o agente.
Verifique se o agente de provisionamento do Microsoft Entra é capaz de se comunicar com êxito com os datacenters 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 é utilizado |
|---|---|
| 80 | Descarregando listas de revogação de certificados (CRLs) ao validar o certificado TLS/SSL. |
| 443 | Gerir toda a comunicação de saída com o serviço de Proxy de Aplicação. |
Se o firewall impõe o tráfego de acordo com os usuários de origem, abra também as portas 80 e 443 para o tráfego dos serviços do Windows executados como um serviço de rede.
Permita acesso aos seguintes URLs:
| URL | Porto | Como é utilizado |
|---|---|---|
*.msappproxy.net *.servicebus.windows.net |
443/HTTPS | Comunicação entre o conector e o serviço de cloud do Aplicativo Proxy. |
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ê pode permitir conexões com *.msappproxy.net, *.servicebus.windows.nete outras URLs anteriores, se seu firewall ou proxy permitir que você configure regras de acesso com base em sufixos de domínio. Caso contrário, você precisará permitir o acesso aos intervalos de IP e tags de serviço do Azure - nuvem pública. Os intervalos de IP são atualizados a cada semana.
Importante
Evite todas as formas de inspeção e terminação em linha em comunicações TLS de saída entre conectores de rede privada do Microsoft Entra e serviços de nuvem de proxy de aplicativo Microsoft Entra.
Os registos DNS públicos dos endpoints do proxy de aplicação Microsoft Entra são registos CNAME encadeados, que apontam para um registo A. Isso garante tolerância a falhas e flexibilidade. É garantido que o conector de rede privada Microsoft Entra sempre aceda a nomes de anfitrião 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 de host e sufixos diferentes. Devido a isso, você deve garantir que o dispositivo pode resolver todos os registros na cadeia e permite a conexão com os endereços IP resolvidos. Como os registros DNS na cadeia podem ser alterados de tempos em tempos, não podemos fornecer nenhuma lista de registros DNS.
Para verificar se o agente está em execução, siga estas etapas:
No servidor com o agente instalado, abra Services. Faça isso indo para Iniciar>Executar>Services.msc.
Em Services, verifique se Microsoft Entra Connect Agent Updater e Microsoft Entra Provisioning Agent estão lá. Confirme também se o seu estado é em execução.
As seções a seguir descrevem alguns problemas comuns de instalação do agente e resoluções típicas desses problemas.
Poderá receber uma mensagem de erro que indique:
Falha ao iniciar o serviço 'Microsoft Entra Provisioning Agent'. Verifique se você tem privilégios suficientes para iniciar os serviços do sistema.
Esse problema geralmente é causado por uma diretiva de grupo. A política impediu que as permissões fossem aplicadas à conta de entrada do Serviço NT local criada pelo instalador (NT SERVICE\AADConnectProvisioningAgent). Essas permissões são necessárias para iniciar o serviço.
Para resolver este problema, siga estes passos:
Entre no servidor com uma conta de administrador.
Abra os Services indo para o Iniciar>Executar>Services.msc.
Em Services, clique duas vezes em Microsoft Entra Provisioning Agent.
No separador Início de Sessão, altere Esta conta para um administrador de domínio. Em seguida, reinicie o serviço.
Poderá receber a seguinte mensagem de erro quando tentar registar o agente.
Esse problema geralmente é causado pelo agente não conseguir se conectar ao serviço de identidade híbrida. Para resolver esse problema, configure um proxy de saída.
O agente de provisionamento oferece suporte ao uso de um proxy de saída. Você pode configurá-lo editando o seguinte arquivo de .config do agente: C:\Program Files\Microsoft Azure AD Connect Provisioning Agent\AADConnectProvisioningAgent.exe.config.
Adicione as seguintes linhas ao ficheiro, próximo ao final, imediatamente antes da tag de encerramento </configuration>. 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>
Você pode receber uma mensagem de erro ao instalar o agente de provisionamento de nuvem. Esse problema geralmente é causado pelo agente não conseguir executar os scripts de registro do PowerShell, devido às políticas de execução locais do PowerShell.
Para resolver esse problema, altere as políticas de execução do PowerShell no servidor. Você precisa ter políticas de máquina e usuário definidas como Undefined ou RemoteSigned. Se eles estiverem definidos como Unrestricted, você verá esse erro. Para obter mais informações, consulte políticas de execução do PowerShell.
Por padrão, o agente emite mensagens mínimas de erro 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 reunir detalhes adicionais para solucionar problemas relacionados ao agente, siga estas etapas.
- Instale o módulo do PowerShell AADCloudSyncTools.
- Use o cmdlet
Export-AADCloudSyncToolsLogsPowerShell para capturar as informações. Você pode usar as opções a seguir para ajustar sua coleta de dados.-
SkipVerboseTracepara exportar apenas logs correntes sem capturar logs verbosos (padrão = false). -
TracingDurationMinsespecificar uma duração de captura diferente (padrão = 3 minutos). -
OutputPathespecificar um caminho de saída diferente (padrão = pasta Documentos do usuário).
-
No portal, você pode usar logs de provisionamento para ajudar a rastrear e solucionar problemas de sincronização de objetos. Para visualizar os logs, selecione Logs.
Os logs de provisionamento fornecem muitas informações sobre o estado dos objetos que estão sendo sincronizados entre seu ambiente local do Ative Directory e o Azure.
Você pode filtrar a exibição para se concentrar em problemas específicos, como datas. Você também pode pesquisar nos logs por atividades relativas a um objeto do Active Directory usando seu Active Directory ObjectGuid. 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. Desta forma, você pode identificar o local exato do problema.
Se você estiver sincronizando usuários e grupos do Ative Directory, talvez não consiga localizar um ou mais grupos no Microsoft Entra ID. Isso pode ser devido ao facto de a sincronização ainda não estar concluída ou ainda não ter acompanhado a criação do objeto no Active Directory, a um erro de sincronização que está a bloquear a criação do objeto no Microsoft Entra ID, ou a uma regra de escopo de sincronização que pode ter sido aplicada, excluindo o objeto.
Se você reiniciar a sincronização e, em seguida, quando o ciclo de provisionamento for concluído, pesquise no log de provisionamento atividades relacionadas a um objeto usando o Ative Directory desse objeto ObjectGuid. Se um evento com uma Identidade contendo apenas uma ID de Origem e um Status de Skipped estiver presente no log, isso poderá indicar que o agente filtrou o objeto do Ative Directory porque ele estava fora do escopo.
Por padrão, as regras de escopo excluem os seguintes objetos de serem sincronizados com o Microsoft Entra ID:
- utilizadores, grupos e contactos com
IsCriticalSystemObjectdefinidos como TRUE, incluindo muitos dos utilizadores e grupos internos no Active Directory - Objetos afetados pela replicação
Restrições adicionais podem estar presentes no esquema de sincronização .
Se você tiver uma topologia de implementação com o Microsoft Entra Connect e o Microsoft Entra Cloud Sync, ambos exportando para o mesmo locatário do Microsoft Entra, ou se tiver mudado completamente do uso do Microsoft Entra Connect para o Microsoft Entra Cloud Sync, poderá receber a seguinte mensagem de erro de exportação ao excluir ou mover vários objetos para fora do escopo definido:
Este erro não está relacionado com a funcionalidade de prevenção de eliminações acidentais da sincronização na nuvem do Microsoft Entra Connect. Ele é acionado pela funcionalidade de prevenção de eliminações acidentais definida no diretório Microsoft Entra do Microsoft Entra Connect. Se você não tiver um servidor Microsoft Entra Connect instalado a partir do qual você pode alternar o recurso, você pode usar o módulo "AADCloudSyncTools" PowerShell instalado com o agente de sincronização de nuvem do Microsoft Entra Connect para desabilitar a configuração no locatário e permitir que as exclusões bloqueadas sejam exportadas depois de confirmar 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 que foram marcados para exclusão devem ser excluídos do diretório do Microsoft Entra com êxito.
A sincronização na nuvem monitoriza o estado de funcionamento da sua configuração e coloca objetos não íntegros num 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ê pode 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 rato no estado irá abrir opções adicionais para:
- Exiba os logs de provisionamento.
- Veja os agentes.
- Remova a quarentena.
Existem duas maneiras diferentes de resolver uma quarentena. Você pode limpar a quarentena ou reiniciar o trabalho de provisionamento.
Para limpar a marca d'água e executar uma sincronização delta no trabalho de provisionamento após a sua verificação, basta clicar com o botão direito do mouse no status e selecionar Limpar quarentena.
Você verá um aviso de que a quarentena está sendo liberada.
Então você deve ver o status em seu agente como saudável.
Use o portal para reiniciar o trabalho de provisionamento. Na página de configuração do agente, selecione Reiniciar sincronização.
Como alternativa, pode-se usar o Microsoft Graph para reiniciar o trabalho de provisionamento. Você tem controle total sobre o que reinicia. Você pode optar por limpar:
- "Escrows, para reiniciar o contador de escrows que acumula para o estado de quarentena."
- Quarentena, para remover o aplicativo da quarentena.
- Marcas d'água.
Use a seguinte solicitação:
POST /servicePrincipals/{id}/synchronization/jobs/{jobId}/restart
Se precisar reparar a conta do serviço de sincronização na nuvem, você pode usar o comando Repair-AADCloudSyncToolsAccount.
Em uma sessão do PowerShell com privilégios administrativos, digite ou copie e cole, o seguinte:
Connect-AADCloudSyncToolsInsira suas credenciais de Administrador Global do Microsoft Entra.
Digite ou copie e cole o seguinte:
Repair-AADCloudSyncToolsAccountDepois que isso for concluído, deve dizer que a conta foi reparada com sucesso.
Para habilitar e usar o write-back de senha com a sincronização na nuvem, lembre-se do seguinte:
- Se precisar atualizar as permissões gMSA , poderá demorar uma hora ou mais para que estas permissões sejam replicadas em todos os objetos do seu diretório. Se você não atribuir essas permissões, o write-back pode parecer estar configurado corretamente, mas os usuários podem encontrar erros quando atualizam suas senhas locais da nuvem. As permissões devem ser aplicadas a este objeto e a todos os objetos descendentes para que a opção Tornar Senha Válida Novamente apareça.
- Se as senhas de algumas contas de usuário não forem gravadas de volta no diretório local, verifique se a herança não está desabilitada para a conta no ambiente local dos Serviços de Domínio Ative Directory (AD DS). As permissões de gravação para senhas devem ser aplicadas a 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 senhas para 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>Diretivas>Configurações do Windows>Configurações de Segurança>Diretivas de Conta, dentro do gpmc.msc.
- Se você atualizar a política de grupo, aguarde até que a política atualizada seja replicada ou use o comando
gpupdate /force. - Para que as senhas sejam alteradas imediatamente, a idade mínima da senha deve 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.
- Se você atualizar a política de grupo, aguarde até que a política atualizada seja replicada ou use o comando