Como eliminar MFA repetido no Microsoft 365

Ambiente comum em empresas de pequeno e médio porte: domínio Active Directory local, Microsoft 365 Business Standard e Pass-through Authentication (PTA) configurado porque a empresa ainda controla horário de acesso pelo AD. O sintoma que motiva este artigo também é comum: o usuário loga no Windows, abre o Outlook e é solicitado MFA. Abre o Teams, pede de novo. Abre o OneDrive, pede uma terceira vez. Marcar “Sim, aplicar a todos os aplicativos” na tela de MFA do Windows não resolve nada.

A causa não é o MFA em si — é a ausência de SSO no dispositivo. Sem o Microsoft Entra Hybrid Join, cada aplicativo negocia sua própria sessão com o Entra ID, sem nenhum artefato local que prove “este dispositivo e este usuário já provaram quem são”. Este artigo reconstrói o diagnóstico e a configuração completa, com foco em ambientes sem Entra ID P1 (sem Acesso Condicional), onde algumas proteções legadas precisam ser mantidas por não haver substituto disponível.

O sintoma e por que ele acontece

É fácil confundir dois mecanismos que parecem semelhantes, mas operam em camadas diferentes:

• KMSI (Keep Me Signed In) é o “manter conectado” que aparece no navegador depois do login web. Ele grava um cookie de sessão no navegador. Esse cookie não cruza para aplicativos desktop (Outlook, Teams, OneDrive) porque eles não autenticam via navegador — autenticam via WAM (Web Account Manager), o broker de identidade do Windows.
• PRT (Primary Refresh Token) é o token que o WAM usa para dar SSO a todos os aplicativos desktop de uma vez. Ele só existe se o dispositivo tiver uma identidade registrada no Entra ID e o usuário tiver feito um logon interativo no Windows depois disso.

Sem Hybrid Join, o dispositivo não tem identidade no Entra ID, não há PRT, e cada aplicativo cai no fluxo interativo completo — incluindo MFA — de forma independente. Corrigir isso não é uma questão de “afrouxar” a política de MFA; é uma questão de dar ao dispositivo os meios de fazer SSO de verdade.

Diagnóstico com dsregcmd /status

Antes de mexer em qualquer configuração, rode em um prompt de comando na estação afetada:

dsregcmd /status

Os campos que importam para este diagnóstico:

Campo	O que significa
AzureAdJoined	Se o dispositivo tem um objeto de identidade no Entra ID (Hybrid Join ou Azure AD Join nativo).
DomainJoined	Ingresso tradicional no AD local. Continua YES o tempo todo neste cenário.
WorkplaceJoined	Registro no nível de conta (Azure AD Registered), geralmente criado sozinho quando o usuário assina o Office. Não é identidade de máquina.
AzureAdPrt	Se o dispositivo possui um PRT válido neste momento.
WamDefaultSet	Se o Web Account Manager tem uma conta padrão configurada — anda junto com a emissão do PRT.
DeviceAuthStatus	Resultado da última tentativa de autenticação do objeto de dispositivo.
KeySignTest	Verifica se a chave privada do dispositivo consegue assinar corretamente — um teste de saúde da credencial usada para emitir o PRT.

O “antes” típico deste cenário:

AzureAdJoined : NO
DomainJoined : YES
WorkplaceJoined : YES
AzureAdPrt : NO

WorkplaceJoined: YES engana muita gente — parece que “já tem alguma coisa registrada no Entra”, mas esse registro vive na conta do usuário, não no objeto de máquina, e nunca emite PRT. É por isso que o MFA continua se repetindo mesmo com esse campo positivo.

Desfazendo confusões comuns

PTA não é SSO. Pass-through Authentication define onde a senha é validada (os agentes PTA encaminham a validação para os controladores de domínio locais). Hybrid Join define se o dispositivo tem identidade no Entra ID. São camadas independentes — dá para ter PTA com ou sem Hybrid Join, e o mesmo vale para Password Hash Sync (PHS).

Hybrid Join não muda o método de autenticação (continua PTA) e não interfere no controle de horário de logon do AD — essas restrições continuam sendo aplicadas no momento da emissão do ticket Kerberos, independentemente de o dispositivo ter ou não uma identidade na nuvem.

Aviso: no assistente do Microsoft Entra Connect, não entre em “Change user sign-in” sem necessidade. Essa tela é onde se troca o método de autenticação do tenant inteiro — é fácil, por engano, sair de PTA e cair em PHS. A configuração de Hybrid Join fica em um caminho totalmente separado (“Configure device options”).

Pré-requisito: sufixo UPN roteável

Um domínio AD local .local não é um sufixo roteável/verificável publicamente, então não pode ser usado como está para autenticação no Entra ID. Isso normalmente já foi resolvido adicionando um sufixo UPN alternativo (o domínio .com.br verificado no Microsoft 365) via Active Directory Domains and Trusts, e atribuindo esse sufixo às contas de usuário.

Antes de prosseguir, audite a distribuição real de sufixos:

Get-ADUser -Filter * -Properties UserPrincipalName |
  Group-Object { ($_.UserPrincipalName -split '@')[1] } |
  Select Name, Count

Em um ambiente típico desse porte, o resultado mostra algo como 209 contas já com @contoso.com.br e um punhado de contas de serviço ainda em @contoso.local. Essas contas de serviço podem — e devem — continuar como estão: elas não fazem logon interativo no Windows, não precisam de Hybrid Join, e trocar o UPN delas só cria risco de quebrar autenticações de aplicações, tarefas agendadas ou SPNs vinculados, sem nenhum benefício real.

Verificando e criando o Service Connection Point (SCP)

O SCP é o objeto no AD (na partição de configuração da floresta) que informa aos dispositivos Windows ingressados no domínio onde fica o tenant do Entra ID, para que eles saibam que devem tentar o Hybrid Join. Verifique se ele já existe:

$cfg = (Get-ADRootDSE).configurationNamingContext
Get-ADObject -Identity "CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,$cfg" -Properties keywords

Um erro ObjectNotFound aqui significa apenas que o SCP ainda não foi criado — é o estado esperado antes da configuração inicial, não uma falha.

Para criar: no assistente do Microsoft Entra Connect, vá em Configure > Configure device options > Configure Hybrid Microsoft Entra join, selecione Windows 10 or later domain-joined devices, marque a floresta correspondente, defina Authentication Service = Microsoft Entra ID (não ADFS) e adicione as credenciais de um Enterprise Admin daquela floresta.

É normal o campo azureADName aparecer como <tenant>.onmicrosoft.com, mesmo que o domínio principal do tenant seja contoso.com.br — esse é só o domínio de roteamento padrão. O que efetivamente amarra o SCP ao tenant certo é o azureADId (o Tenant ID, um GUID).

Como funciona o sync join (tenant gerenciado, sem ADFS)

Esta é a parte que mais gera dúvida em tenants gerenciados (PTA ou PHS, sem ADFS). O fluxo tem três etapas, nesta ordem:

1. A própria máquina gera um par de chaves e um certificado, e grava esse certificado no atributo userCertificate do seu próprio objeto de computador no AD local.
2. O Microsoft Entra Connect, no ciclo de sincronização seguinte, sincroniza esse objeto de computador para o Entra ID, criando o objeto de dispositivo correspondente na nuvem.
3. Só então a máquina consegue completar o join — a etapa final valida a chave contra o objeto de dispositivo que agora existe no Entra ID.

Enquanto a etapa 2 ainda não aconteceu, é normal ver, no Visualizador de Eventos, em Aplicativos e Serviços > Microsoft > Windows > User Device Registration, eventos como:

registrationType: fallback_sync
subcode: error_missing_device
"The device object by the given id (...) is not found."

Esse erro é esperado nessa fase e não indica problema de configuração — significa apenas que o Entra Connect ainda não sincronizou o objeto de computador.

Verificações úteis:

(Get-ADComputer NOME-DA-MAQUINA -Properties userCertificate).userCertificate.Count

Um valor maior que zero confirma que a etapa 1 já aconteceu (a máquina já gerou seu certificado local). Se estiver zerado, o problema está antes disso — verifique a tarefa agendada de registro de dispositivo ou a política de grupo que a habilita.

Confira também o escopo de sincronização de domínio/UO no Entra Connect: a UO onde ficam os computadores e o container padrão Computers precisam estar dentro do escopo sincronizado. Esse é o bloqueio real mais comum — objetos de computador que existem, mas nunca são sincronizados porque ficaram de fora do filtro de OU.

Para forçar a propagação em vez de esperar o próximo ciclo automático:

Start-ADSyncSyncCycle -PolicyType Initial

Use Initial, não Delta, ao validar uma configuração nova — o ciclo completo garante que mudanças de escopo (OUs recém-incluídas) sejam realmente reavaliadas.

Os eventos 420 e 274 (relacionados a Kerberos/KDC proxy) que também podem aparecer nesse mesmo log são ruído do caminho federado e do provisionamento de Windows Hello for Business — não são bloqueadores neste cenário de sync join.

Validando o resultado no Microsoft Entra admin center

Em Entra ID > Dispositivos, procure o nome da máquina. Um estado Pendente significa que o objeto já foi sincronizado (existe na nuvem), mas o aperto de mão final ainda não foi concluído pelo cliente — ele deve virar “Habilitado” na próxima tentativa de registro da máquina.

O campo Proprietário em branco é correto para um dispositivo hybrid joined: ele pertence à organização, não a um usuário específico (diferente de um dispositivo Azure AD Registered/BYOD, que sempre mostra um proprietário).

Também é normal ver duas entradas para a mesma máquina por um tempo: o registro antigo “Microsoft Entra registered” (o Workplace Join anterior, no nível de conta) convivendo com o novo “Microsoft Entra hybrid joined” (no nível de dispositivo). São inofensivos e podem ser limpos depois, sem pressa.

A emissão do PRT: o ponto que mais gera confusão

O PRT só é emitido durante um logon interativo do Windows — ou seja, no momento em que o usuário digita a senha ou o PIN na tela de bloqueio, não em segundo plano com a sessão já aberta.

Isso tem uma consequência prática importante: se o dispositivo completou o registro enquanto uma sessão já estava aberta, essa sessão específica nunca vai ganhar um PRT. É necessário fazer logoff (ou reiniciar) e logar novamente para que o Windows solicite e armazene o PRT nesse novo logon interativo. O campo WamDefaultSet vira YES junto com essa emissão bem-sucedida.

Vale documentar com honestidade o comportamento de transição: logo após o registro e um novo logon, os aplicativos ainda podem pedir senha e MFA mais uma vez — isso é esperado, porque os tokens estão sendo reemitidos sob a nova identidade de dispositivo. Em alguns casos, é necessário mais de um ciclo de logon até o PRT se estabilizar de fato em todos os aplicativos. Não prometa que o problema desaparece garantidamente no primeiro reboot — na prática, costuma levar um ou dois ciclos de logon.

PRT é por usuário e por dispositivo, não por máquina

Um mal-entendido comum: “se a máquina virou confiável, ninguém mais precisa fazer MFA nela”. Não é assim. O PRT é emitido por combinação de usuário + dispositivo. Cada usuário que logar interativamente numa máquina hybrid joined recebe o próprio PRT e passa pelo próprio MFA na primeira vez.

Cenário	Precisa de MFA?
Mesmo usuário, mesma máquina, logons seguintes	Não — PRT já emitido e válido
Outro usuário, mesma máquina (primeiro logon dele)	Sim — esse usuário ainda não tem PRT nessa máquina
Mesmo usuário, outra máquina (não registrada)	Sim — aquela máquina não tem PRT nenhum
Mesmo usuário, celular pessoal (app Outlook/Teams mobile)	Depende das políticas de MFA/conta do aplicativo, não do PRT do PC

Lembrar MFA por 90 dias: como funciona de verdade

Outro entendimento equivocado comum: “só pede MFA de novo se eu ficar 90 dias sem logar”. Não é uma janela de inatividade — é um prazo fixo que começa a contar no momento em que o MFA é satisfeito, por dispositivo/navegador específico. Esse prazo é revogado antes do fim se a senha do usuário mudar ou se os métodos de MFA cadastrados forem alterados.

Compare com o PRT: sua validade é de 14 dias, mas em janela deslizante — cada uso renova o prazo automaticamente, então uma máquina usada com regularidade praticamente nunca chega a expirar.

Nuance de licenciamento importante: para quem tem Entra ID P1, a Microsoft recomenda abandonar esse recurso legado em favor de Frequência de Entrada no Acesso Condicional, que é mais granular e auditável. Para quem tem apenas Microsoft 365 Business Standard — sem P1 — esse recurso deve ser mantido ativo, porque é a única ferramenta disponível para reduzir a frequência de prompts de MFA no navegador.

Higiene de segurança que ainda fica pendente

Senhas de aplicativo são um bypass completo de MFA, usadas por protocolos de autenticação legada (IMAP, POP, SMTP antigo, alguns clientes desktop antigos). Quem tem uma senha de aplicativo em mãos não passa por MFA nenhum naquele protocolo. Antes de desabilitar, confira nos logs de entrada (Entra ID > Sign-in logs, filtrando por autenticação legada) quais contas ainda dependem delas, para não quebrar uma integração legítima ao desligar o recurso.

IPs confiáveis (recurso legado de MFA por usuário) também merece revisão. Com Entra ID P1, o caminho correto é substituir por Locais Nomeados dentro do Acesso Condicional. Sem P1, é importante entender a troca que está sendo feita: pular o MFA dentro da rede interna enfraquece a defesa contra movimentação lateral — se um único dispositivo interno for comprometido, o invasor herda esse mesmo privilégio de “rede confiável”.

Limitação honesta: a restrição de horário de logon do AD é aplicada no momento da autenticação (emissão do ticket Kerberos). Tokens do Microsoft 365 já emitidos continuam válidos pela sua duração normal (cerca de 1 hora, mais os refresh tokens), então bloquear alguém no AD não corta o acesso dele ao Microsoft 365 instantaneamente. Um corte imediato de sessão ativa só é possível com Acesso Condicional (Entra ID P1), que não está disponível neste cenário.

Impacto operacional e reversibilidade

Não é necessário reingressar nenhuma máquina no domínio, nem tocar estação por estação. Os dispositivos se registram sozinhos conforme são reiniciados dentro do ciclo normal de patches/reinicializações — a propagação completa pela frota costuma levar de 24 a 48 horas.

Perfis de usuário, GPOs, mapeamentos de rede e a tela de login DOMINIO\usuario não mudam em nada. O Hybrid Join adiciona uma identidade na nuvem a uma máquina que já está ingressada no domínio local — ele não substitui nem reseta nada localmente.

A mudança também é reversível: removendo o objeto SCP da partição de configuração do AD, novos dispositivos deixam de tentar o Hybrid Join (as máquinas já registradas continuam funcionando normalmente até que seu estado local expire).

Troubleshooting

Sintoma	Causa provável	Ação
AzureAdJoined: NO, sem erro aparente	SCP ausente ou mal configurado	Repetir a verificação do SCP; recriar pelo assistente do Entra Connect
error_missing_device nos logs de registro	Objeto de computador ainda não sincronizado (fora do escopo de OU, ou sync ainda não rodou)	Conferir o escopo de domínio/OU no Entra Connect; forçar Start-ADSyncSyncCycle -PolicyType Initial
AzureAdPrt: NO mesmo com o join concluído	A sessão atual é anterior ao registro do dispositivo	Fazer logoff/reiniciar e logar novamente
WorkplaceJoined antigo conflitando	Registro de conta (Workplace Join) anterior ainda presente	Remover em Configurações > Contas > Acessar trabalho ou escola > Desconectar. Nunca usar dsregcmd /leave para isso — esse comando desfaz o Hybrid Join, não o Workplace Join
Dispositivo nunca chega a tentar o registro	Bloqueio de rede para os endpoints do Entra ID	Liberar enterpriseregistration.windows.net, device.login.microsoftonline.com, login.microsoftonline.com e autologon.microsoftazuread-sso.com

Checklist de validação

• UPN de todos os usuários (exceto contas de serviço) em um sufixo verificado e roteável
• SCP criado e apontando para o Tenant ID correto (azureADId)
• OU de computadores e o container Computers dentro do escopo de sincronização do Entra Connect
• userCertificate populado no objeto de computador (etapa local concluída)
• Objeto de dispositivo visível em Entra ID > Dispositivos (mesmo que “Pendente”)
• dsregcmd /status mostrando AzureAdJoined: YES após reboot
• Logoff/logon realizado após o registro, para forçar a emissão do PRT
• AzureAdPrt: YES e WamDefaultSet: YES confirmados
• Teste com um segundo usuário na mesma máquina, para confirmar que o MFA dele é independente
• Revisão de senhas de aplicativo e IPs confiáveis, com base nos logs de entrada, antes de desativar

Para aprofundar, vale consultar a documentação oficial da Microsoft sobre “How Microsoft Entra device registration works”, “Configure Hybrid Microsoft Entra join” (Microsoft Entra Connect) e a documentação de “Authentication methods policy” / configurações legadas de MFA por usuário, disponíveis no Microsoft Learn.