Entra Connect: Prazo de Abril de 2027 e o Caminho para o Cloud Sync

Neste artigo:

  1. O prazo que obriga a actualizar
  2. Verificar versão e modo de autenticação
  3. Configurar application-based authentication
  4. Staging server: testar antes de produção
  5. Cloud Sync: como funciona
  6. Pré-requisitos do agente Cloud Sync
  7. Connect ou Cloud Sync: guia de decisão
  8. Troubleshooting
  9. Erros Comuns
  10. Checklist
  11. Artigos Relacionados
  12. Fontes Oficiais

1. O prazo que obriga a actualizar

Tem um prazo com data na documentação oficial: 7 de Abril de 2027. A Microsoft exige que cada servidor com Microsoft Entra Connect Sync corra a versão 2.6.84.0 ou posterior e fique configurado com application-based authentication. Quando a data passa, a autenticação legacy é desativada e quem não cumprir os dois requisitos deixa de sincronizar — o aviso da Microsoft diz que os serviços de sincronização param. A recuperação é a mesma: actualizar e configurar o modo de autenticação.

A regra tem antecedente: a anterior, de Setembro de 2026, pedia a versão 2.5.79.0 ou posterior — a Microsoft apresentou essa actualização como forte recomendação, com corte de serviço para quem ficasse abaixo. Esta, de 7 de Abril de 2027, põe o mínimo em 2.6.84.0 e junta o requisito de autenticação por aplicação. Em simultâneo, o instalador .msi do Connect já só está disponível no centro de administração Microsoft Entra, e o pré-requisito é o .NET Framework 4.7.2 com TLS 1.2. Para quem mantém o Connect a prazo, o calendário é: migrar para 2.6.84.0+ (a 2.6.92.0 é a corrente), configurar o novo modo de autenticação, e decidir se o futuro passa pelo Cloud Sync.

2. Verificar versão e modo de autenticação

Antes de mexer, confirma o ponto de partida. A versão lê-se no assistente ou no painel de controlo (entradas de "Microsoft Entra Connect"). A verificação rápida faz-se no próprio servidor com o assistente: a entrada "Microsoft Entra Connect" no menu Iniciar abre a janela cujo título mostra a versão. A lista de versões suportadas é curta: 2.6.3.0 e 2.6.84.0 caducam em Julho e Setembro de 2027, 2.6.91.0 a 23/09/2027, e a 2.6.92.0 (hotfix de 23/09/2026) é a versão corrente. Na tabela de fim de suporte do version history, ainda suportadas: 2.5.79.0 (23/10/2026), 2.5.190.0 (02/02/2027) e 2.6.1.0 (10/03/2027) não chegam ao mínimo de Abril de 2027. A 2.6.3.0 vai até 07/07/2027 e a 2.6.84.0 até 16/09/2027. Só a 2.6.79.0 foi retirada, depois de conhecido um problema no instalador.

O modo de autenticação confirma-se depois de aberto o assistente: no menu Tasks, escolhe View or export current configuration — se o servidor usa application-based authentication, há um application (client) ID visível — se usar a conta de sincronização legacy, o campo mostra o nome da conta. Em PowerShell, Get-ADSyncEntraConnectorCredential devolve o ConnectorIdentityType: ServiceAccount (legacy) ou Application. A opção sozinha no wizard não prova nada — servidores novos saem da instalação já em application-based, mas os existentes não foram mudados automaticamente: para trocar, corre o assistente e escolhe a opção de configurar application-based authentication.

3. Configurar application-based authentication

A configuração corre no próprio assistente do Entra Connect no servidor. Em versões a partir da 2.6.84.0, o assistente já não cai para a conta legacy silenciosamente quando a configuração falha: pára com o erro “Microsoft Entra Connect could not configure application-based authentication for this server. Setup cannot continue.” — a mensagem é para resolver o problema de fundo (certificados TPM, permissões) antes de repetir. O modo usa um certificado de aplicação registado no Entra ID em vez da password da conta de sincronização, e a partir da 2.6.84.0 o assistente testa a capacidade de assinatura do certificado e trata correctamente certificados assinados por TPM.

Duas consequências práticas: os cmdlets que alteram a configuração cloud (Set-ADSyncAADCompanyFeature, Set-ADSyncAADPasswordSyncState) passam a exigir autenticação de administrador: na 2.6.84.0 com o parâmetro -AADUsername, e desde a 2.6.91.0 sem o parâmetro — abre um prompt interactivo de autenticação. Quem usa Conditional Access com políticas por aplicação deve rever as políticas que apontam a Microsoft.Azure.SyncFabric e ao Microsoft 365 Reporting Service — nota da 2.6.91.0, quando as permissões Microsoft Graph novas foram acrescentadas ao Connect.

Depois da migração, três detalhes do modo application-based valem atenção. O certificado que autentica a aplicação tem vida útil de 90 dias por omissão — o Connect verifica a rotação no scheduler e roda automaticamente, mas se o scheduler estiver suspenso, nada gira (avisos Event ID 1011 por cima dos 70% de vida, erros 1012 no log Application). Terminada a transição e confirmado que a sincronização corre bem, a orientação é remover a conta de serviço legacy DSA por PowerShell — e, se algo correr mal durante a configuração, há um procedimento documentado de rollback para a conta de serviço ServiceAccount (a recriação da conta pode demorar até 15 minutos a surtir efeito).

4. Staging server: testar antes de produção

Se tens um servidor em modo staging (o segundo servidor do par típico PME), é o campo de testes natural: aplica a 2.6.92.0 e a configuração application-based lá primeiro, observa durante um ciclo completo, e só depois tocas no de produção. A nota está no version history desde a 2.5.3.0 (Maio de 2025): alternar o modo staging através de PowerShell com SSPR activo pede credenciais de administrador.

5. Cloud Sync: como funciona

O Entra Cloud Sync é a resposta da Microsoft a dois problemas do Connect Sync: a configuração toda vive no servidor on-premises, e a máquina é um ponto de falha único. No Cloud Sync, a orquestração corre no serviço de provisioning da cloud — a configuração guarda-se no Entra ID, e o ciclo de sincronização dispara a cada 2 minutos, contra os 30 minutos do scheduler do Connect. Do lado do AD fica apenas um agente de provisioning leve, o mesmo em tecnologia do Application Proxy e da Pass-through Authentication: abre só ligações de saída, actualiza-se automaticamente, e corre sob uma conta de serviço gerida (gMSA) em vez de uma conta com password.

São os cenários que o Connect não cobre que explicam a mudança: florestas desconectadas (sem confiança entre elas, cada uma com o seu agente), provisionamento de grupos da cloud para o AD, e recuperação de desastres mais simples — instalar outro agente noutro servidor devolve o serviço sem reconstruir um servidor dedicado. O agente regista-se no serviço, escuta pedidos por uma ligação de saída permanente ao Service Bus, e responde com SCIM. Um bootstrap a cada 10 minutos renova a identidade e os endpoints.

6. Pré-requisitos do agente Cloud Sync

O agente pede um servidor de domínio com Windows Server 2025 ou 2022 como recomendação corrente. Versões mais antigas em suporte estendido são aceites, mas o suporte dessa configuração pode exigir programa de suporte pago. O instalador do Connect por sua vez admite 2019 e 2016, não instala em Server Core (exige GUI completa) e a orientação de segurança manda desligar NTLM no servidor de sync. Completam o mínimo os 4 GB de RAM, o .NET 4.7.2 e o TLS 1.2 activo. Contas: credenciais de Domain/Enterprise Admin para criar a gMSA do agente e uma conta Hybrid Identity Administrator (não guest) para configurar. A política de execução PowerShell fica em Undefined ou RemoteSigned, o serviço Windows Credential Manager (VaultSvc) tem de estar activo, e o schema AD precisa do atributo msDS-ExternalDirectoryObjectId (Windows Server 2016 em diante, por omissão).

Para alta disponibilidade, a recomendação da Microsoft são 3 agentes activos — com vários agentes a correr, a sincronização continua quando um falha. O servidor do agente trata-se como servidor de controlo (tier 0 no modelo de tiers do AD), e instalá-lo num controlador de domínio é suportado. As portas de saída: 80 (listas de revogação de certificados), 443 (toda a comunicação com o serviço) e opcionalmente 8080 para o relatório de estado a cada 10 minutos quando o 443 não está disponível.

7. Connect ou Cloud Sync: guia de decisão

Para uma PME com uma única floresta e sem cenário de M&A, a decisão parte do Connect instalado: o cumprimento do prazo de Abril de 2027 vem primeiro — e, para quem for elegível, a própria Microsoft recomenda o Cloud Sync como caminho. O Cloud Sync compensa quando algum destes casos existe: florestas adicionais desconectadas (o Cloud Sync cobre, o Connect não), grupos da cloud a provisionar para o AD (funcionalidade que exige licenças Microsoft Entra ID P1), vontade de retirar a última máquina com motor de sync on-premises, ou várias filiais com servidores a manter. Se nenhum deles se aplica, o Connect 2.6.92.0 com application-based authentication fica em versão corrente sem data de fim de suporte anunciada — no modelo da Microsoft, cada 2.x reforma-se 12 meses depois do lançamento da versão seguinte (o 23/09/2027 na tabela é o fim da 2.6.91.0) — e a partir da 2.6.91.0 existe um fluxo guiado de migração para o Cloud Sync que faz a avaliação da configuração, a instalação do agente e a activação por fases.

8. Troubleshooting

O diagnóstico corre em três sítios. No portal: Entra ID > Entra Connect > Cloud sync — a página de agentes mostra o estado activo a verde por agente, e os provisioning logs (botão Logs) mostram cada objecto processado com o respectivo erro. No servidor: em services.msc, o Microsoft Entra Provisioning Agent e o Microsoft Entra Connect Agent Updater têm de estar em execução. Os trace logs vivem em C:\ProgramData\Microsoft\Azure AD Connect Provisioning Agent\Trace — e o módulo AADCloudSyncTools junta tudo com Export-AADCloudSyncToolsLogs, com opções para limitar a duração da captura (TracingDurationMins, por omissão 3 minutos) ou saltar os trace verbosos (SkipVerboseTrace).

Nos erros que chegam ao log, dois padrões ajudam: um erro de recurso inválido (por exemplo, HybridIdentityServiceInvalidResource) resolve-se reinscrevendo o agente e recomeçando a configuração no portal. Um HybridIdentityServiceNoAgentsAssigned significa que nenhum agente está atribuído ao domínio — tipicamente o agente foi removido e tem de se reinstalar. Antes de aprofundar, confirmar as portas: as ligações são todas de saída (80, 443 e o 8080 opcional), e um proxy na frente tem de suportar HTTP 1.1 com chunked encoding.

9. Erros Comuns

Sintoma Causa provável Correcção
Agent inactivo no portal, serviço em execução Bootstrap sem resposta ou fila de proxy (verificar ligações de saída no trace) Ligações de saída 80/443 sem inspecção TLS, e URL de proxy no ficheiro .config do agente
Sincronização a cada 2 min não dispara Agente sem ligação ao Service Bus Verificar o bootstrap (10 min) nos trace logs e o estado dos agentes no portal
Utilizador com erro no provisioning log Atributo em falta ou conflito de duplicados Corrigir no AD e forçar novo ciclo — os logs do portal mostram exactamente o atributo
Erro HybridIdentityServiceNoAgentsAssigned Nenhum agente activo atribuído ao domínio Reinstalar o agente ou reatribuir o domínio ao agente no portal
Wizard do Connect falha application-based auth Certificado TPM sem capacidade de assinatura validada a partir da 2.6.84.0 o assistente testa o certificado — ler o erro e resolver cert/permissões antes de repetir
Sync parou após Abril de 2027 (cenário futuro) Autenticação legacy desativada Actualizar para a versão corrente e configurar application-based authentication

10. Checklist

Antes do prazo, por servidor com Entra Connect Sync: □ versão 2.6.92.0 (ou pelo menos 2.6.84.0) confirmada. □ application-based authentication configurada no assistente. □ Conditional Access a rever para Microsoft.Azure.SyncFabric (permissões Graph novas). □ .msi transferida no centro de administração Entra para o próximo upgrade (não há outro sítio). □ staging server actualizado primeiro, produção depois. □ decisão sobre Cloud Sync tomada (se houver florestas desconectadas ou grupos cloud → AD, o plano avança).

11. Artigos Relacionados

12. Fontes Oficiais