Veja como reduzir prompts de MFA no Microsoft Entra ID (antigo Azure AD) apenas durante a janela de migração com o BitTitan, entender por que isso nem sempre resolve e quais caminhos seguros usar para concluir migrações de e‑mail e OneDrive/SharePoint com Autenticação Moderna.
Índice
Visão geral
Em cenários de migração com ferramentas como o BitTitan/MigrationWiz, é comum a pergunta: “como desativar temporariamente a MFA no Microsoft Entra para permitir a autenticação da ferramenta?”. A resposta curta é: mesmo desligando MFA, a migração pode continuar a falhar, especialmente para OneDrive/SharePoint, porque a Microsoft descontinuou a Basic Authentication nos serviços do Microsoft 365. Em outras palavras, não basta ‘desligar MFA’; a ferramenta precisa falar “o idioma” correto: OAuth 2.0 (Autenticação Moderna).
O que mudou e por que isso importa
- Basic Auth descontinuada em Exchange Online, SharePoint Online e outros serviços do M365. Reativar Security Defaults ou mexer em MFA não “traz de volta” a Basic Auth.
- Autenticação Moderna (OAuth 2.0) é o padrão: tokens, consentimento de aplicativo, permissões por escopo e, quando possível, app-only.
- Conditional Access avalia múltiplas políticas; exigir MFA em qualquer política ou “bloquear acesso” prevalece. Exclusão explícita é o que impede que a política atinja a conta da migração.
Resumo da experiência prática
Consolidamos abaixo o que foi tentado, o resultado observado e a provável causa‑raiz quando o prompt de MFA insiste em aparecer e/ou a migração falha.
| Item | O que foi feito | Resultado | Provável causa‑raiz |
|---|---|---|---|
| Security Defaults | Desativar “Padrões de segurança” no Entra | Prompt de MFA ainda ocorria em alguns cenários | Outras políticas de CA ativas e/ou registro de MFA ainda exigido |
| Conditional Access (CA) | Criar políticas “não exigir MFA” e/ou ajustes diversos | Sem efeito quando outras políticas exigiam MFA | CA avalia múltiplas políticas; “exigir MFA” em qualquer uma vale; é preciso excluir o usuário |
| Per-user MFA (legado) | Verificar se “enforced/enable” estava ativo | Em alguns locatários, ainda forçava o registro | Portal legado de MFA por usuário ativo; registrar métodos ainda pendente |
| MigrationWiz para OneDrive/SharePoint | Tentar com MFA “desligado” | Falhas persistentes | Ferramenta/session usando protocolos não suportados; exige OAuth e permissões corretas |
| Plano alternativo | Migração manual | Concluído com esforço adicional | Ferramenta/versão sem suporte total a Modern Auth |
Passo a passo temporário e com risco para reduzir o prompt de MFA
Aviso: use apenas durante a janela de migração, com janela de mudança aprovada, e reverta 100% ao final. Não desabilite MFA no locatário inteiro. Prefira sempre adequar a ferramenta a Modern Auth.
Verificar e, se necessário, desativar Security Defaults
Caminho: Identidade (Microsoft Entra) → Propriedades → Gerir padrões de segurança (Security defaults) → Desativado.
- Security Defaults também bloqueiam credenciais legadas, mas desativá‑los não reativa Basic Auth no Exchange/SharePoint.
- Documente o antes/depois e justifique o período de exceção.
Acesso Condicional com exclusões explícitas
- Crie um grupo
Migração-Excluídose adicione somente as contas usadas pela ferramenta. - Nas políticas de CA que exigem MFA, adicione o grupo em Users and groups → Exclude.
- Lembre: criar uma política “não exigir MFA” não anula outra que exija; a exclusão evita o prompt.
- Revise Grant controls (Exigir MFA, exigir dispositivo compatível, app aprovado), Client apps, Locations, Device state e Authentication strength. Se qualquer um bloquear, exclua as contas de migração ali também.
MFA por utilizador (portal legado)
- Confirme se as contas de migração não estão com MFA “enforced” no portal de Per-user MFA.
- Se estiver “enabled/enforced”, altere para Disabled durante a janela (e documente a reversão).
Outros gatilhos frequentes de prompt
- Campanha de registo de métodos (Authentication Methods → Registration campaign) pode forçar cadastro de MFA mesmo sem política de CA.
- Identity Protection (políticas de risco de usuário/sessão) pode exigir MFA com base em risco.
- Funções administrativas (RBAC) frequentemente têm políticas especiais com MFA obrigatório.
- Regras de CA como “exigir app aprovado” ou “dispositivo compatível” bloqueiam ferramentas que rodam fora do ecossistema gerenciado.
- Frequência de sessão ou sign-in frequency reduzida pode reemitir prompts inesperados.
Para cada um, exclua temporariamente as contas de migração nessas políticas/configurações sem expor usuários finais.
Checklist rápido de preparo
- Conta de serviço dedicada (sem privilégios desnecessários).
- Senha forte e lifetime mínimo, com rotação assim que a janela terminar.
- Exclusão por grupo em todas as políticas relevantes de CA, Identity Protection e campanhas de registro.
- Se possível, restrição por Local nomeado/IP na política de exceção para reduzir superfície de ataque.
- Log de mudanças: quem, o quê, quando e como reverter.
Por que, mesmo assim, a migração pode falhar
A desativação de MFA reduz prompts, mas não resolve incompatibilidade de protocolo. A maioria dos serviços Microsoft 365 exige OAuth. Se a ferramenta não suportar Modern Auth para o workload (Exchange, OneDrive, SharePoint), a autenticação continuará a falhar. Em especial:
- Exchange Online: EWS/Graph via OAuth (delegated ou app-only). IMAP/POP/SMTP AUTH foram bloqueados na maioria dos locatários.
- SharePoint/OneDrive: Graph/SharePoint API com permissões de aplicativo (app-only) ou delegadas, com consentimento de administrador.
Caminhos viáveis para concluir a migração
Usar Autenticação Moderna na ferramenta
Antes de iniciar lotes volumosos, verifique se a sua versão do BitTitan/MigrationWiz está configurada para OAuth 2.0 para cada workload:
- Exchange Online: preferir EWS com OAuth ou Microsoft Graph. Típico: registrar um aplicativo no Entra, obter Client ID, Tenant ID e segredo/certificado. Conceder permissões de Application apropriadas e limitar o escopo com Application Access Policy quando possível.
- SharePoint/OneDrive: usar permissões Application como Sites.ReadWrite.All (temporariamente), ou Sites.Selected para delimitar acesso a sites/OneDrives específicos (trabalho adicional de delegação, porém mais seguro).
Exemplo de política para limitar e auditar acesso no Exchange Online
# Conectar ao Exchange Online
Connect-ExchangeOnline
Limitar o app a um grupo com caixas‑postais de origem/target
New-ApplicationAccessPolicy ` -AppId <ClientId-do-App>`
-PolicyScopeGroupId \ ` -AccessRight RestrictAccess`
-Description "Escopo de Migração - Temporário"
Validar o escopo
Test-ApplicationAccessPolicy -AppId \ -Identity [usuario@dominio.com](mailto:usuario@dominio.com) Exemplo de criação de lote de migração (Exchange)
# Conectar ao Exchange Online
Connect-ExchangeOnline
Criar um lote (exemplo ilustrativo; ajuste ao seu cenário)
New-MigrationBatch ` -Name "Migração-IMAP-para-EXO"`
-SourceEndpoint "Endpoint-OAuth" ` -CSVData ([System.IO.File]::ReadAllBytes("C:\Migração\usuarios.csv"))`
-AutoStart
Acompanhar e concluir
Get-MigrationBatch "Migração-IMAP-para-EXO"
Complete-MigrationBatch "Migração-IMAP-para-EXO" Exemplo para SharePoint/OneDrive com Sites.Selected (opcional e mais seguro)
# Conceito: conceder ao app acesso seletivo a sites
Requer uso de cmdlets/PNP adequados e mapeamento de cada site/OneDrive ao app
Pseudocomandos (ilustrativos)
Connect-PnPOnline -ClientId \<id> -Tenant \<tenant> -CertificatePath \<cert>
Atribuir permissão Write apenas ao site da origem:
Grant-PnPAzureADAppSitePermission -AppId \<id> -Site [https://contoso.sharepoint.com/sites/Origem](https://contoso.sharepoint.com/sites/Origem) -Permissions Write
Repetir para cada site/OneDrive necessário. Remover ao fim.
Ferramentas nativas da Microsoft
- E‑mail: Exchange Admin Center → Migration (lotes com OAuth) ou
New-MigrationBatchvia PowerShell. - OneDrive/SharePoint: SharePoint Migration Tool (SPMT) ou Migration Manager no centro de administração do SharePoint.
Essas opções suportam MFA/Modern Auth, reduzindo a necessidade de afrouxar seus controles.
Alternativa operacional
Para ambientes pequenos, a migração manual é possível. É demorada e sujeita a erros, exigindo validação pós‑migração detalhada (permissões, versões, metadados, itens ignorados).
Como diagnosticar quando o prompt insiste em aparecer
Use os Registos de início de sessão do Entra para entender o motivo exato. Procure por:
- Conditional Access: qual política aplicou “Grant: Require multifactor authentication” ou “Block access”.
- Client app: se a tentativa veio de “Legacy Authentication” ou “Modern authentication clients”.
- Authentication Requirement: “MFA required” por qual razão.
- Failure reason: códigos AADSTS ajudam a mapear o problema.
Tabela de mensagens e correções típicas
| Código/Mensagem | Interpretação | Ação recomendada |
|---|---|---|
| AADSTS50076 | O recurso exige MFA | Confirme exclusão na CA e no Per-user MFA; verifique campanha de registro |
| AADSTS53003 | Condições de CA não atendidas (ex.: dispositivo compatível) | Excluir a conta de migração dessa exigência ou ajustar a política para a janela |
| AADSTS50105 | Usuário não atende às políticas de CA | Ver motivos detalhados; incluir em exclusão por grupo |
| AADSTS700016/7000218 | App inválido/segredo inválido | Corrigir Client ID/secret/certificado e permissões; renovar segredo |
| AADSTS65001/65004 | Consentimento necessário | Efetuar consentimento de administrador e confirmar escopos |
| AADSTS700082 | Token expirado/inativo | Relogar a conexão da ferramenta; confirme frequência de sessão |
Modelo prático de política de exceção
Se você realmente precisa operar sem MFA para as contas de migração durante a janela — e aceita o risco — uma configuração pragmática é:
- Grupo:
Migração-Excluídoscontendo apenas as contas de serviço. - Política de “Exigir MFA” existente: adicionar esse grupo em Exclude.
- Políticas de dispositivo/aplicativo/local: também excluir o grupo, ou criar políticas condicionais específicas permitindo acesso somente a partir de um IP nomeado do servidor de migração.
- Validação: testes de login no portal/token e verificação dos Registos de início de sessão para comprovar quais políticas foram avaliadas e ignoradas por exclusão.
Boas práticas de segurança para a janela de migração
- Menor privilégio: conceda apenas as permissões mínimas suficientes para leitura/gravação durante a migração.
- Limite temporal: defina data para remoção de permissões e segredos. Documente no change record.
- Controle de origem: restrinja por local nomeado/IP quando possível.
- Registos e auditoria: monitore eventos, falhas e sucesso por aplicativo, usuário e endereço IP.
- Segmentação: migre por lotes menores para isolar problemas sem paralisar o todo.
Plano de reversão e limpeza
- Remover o grupo
Migração-Excluídosdas exclusões em todas as políticas ajustadas. - Reativar Security Defaults (se estavam ativos originalmente) ou reimpor políticas padrão da organização.
- Revogar tokens do app e excluir segredos criados para a migração.
- Remover permissões Application amplas (Sites.ReadWrite.All, por exemplo) e, se aplicável, excluir o registro do aplicativo utilizado.
- Se usou Application Access Policy no Exchange, manter registradas para auditoria ou desabilitar se não houver uso futuro.
- Rotacionar senhas da conta de serviço e, se o app permanecer, considerar migração para autenticação por certificado.
- Exportar os logs e anexar às evidências da mudança.
Validação do sucesso
- Exchange: lotes finalizados, sem skips críticos; pastas e itens esperados no destino; auditoria de throttling e reprocessamentos.
- OneDrive/SharePoint: permissões herdadas, versões e metadados preservados; acessos testados com usuário final.
- Segurança: políticas de CA reativadas; nenhuma conta de serviço mantém exceções indevidas; Zero segredos órfãos.
Perguntas frequentes
Desligar MFA no locatário inteiro resolve?
Não. Além de aumentar o risco, não reativa Basic Auth. Se a ferramenta não falar OAuth, continuará falhando.
Posso criar uma política “não exigir MFA” e pronto?
Não. CA aplica múltiplas políticas. Uma exigindo MFA em qualquer ponto prevalece. A forma correta é excluir explicitamente as contas de migração das políticas que exigem MFA ou outras condições incompatíveis.
Per-user MFA ainda importa?
Sim, em locatários que ainda usam o portal legado. Confirme que as contas de migração não estão com “enforced”.
Qual é a melhor abordagem para OneDrive/SharePoint?
Usar a ferramenta com Autenticação Moderna e permissões de aplicativo (app-only) devidamente consentidas. Para segurança, preferir Sites.Selected em vez de permissões amplas, quando viável.
E para Exchange Online?
Usar EWS/Graph com OAuth. Se usar permissões de aplicativo, limite com Application Access Policy a um conjunto de caixas‑postais.
Exemplo de plano de migração com segurança por camadas
- Descoberta: listar contas, caixas‑postais, sites/OneDrives e volumes.
- Ferramenta: confirmar suporte a OAuth para cada workload e preparar app registration.
- Exceções de CA: criar grupo de exclusão e aplicar somente às contas de serviço; restringir por IP.
- Testes piloto: validar 5–10% dos usuários e pelo menos um site/OneDrive por perfil.
- Lotes: executar por ondas com janelas de reversão definidas.
- Fechamento: reverter políticas, revogar tokens/segredos e emitir relatório final.
Quadro comparativo de abordagens
| Abordagem | Prós | Contras | Quando usar |
|---|---|---|---|
| Exclusão por CA para contas de migração | Rápida, controlável por grupo, auditável | Risco temporário; precisa de disciplina na reversão | Quando a ferramenta já suporta OAuth e só precisa evitar prompts |
| Ferramentas nativas Microsoft | Compatíveis com MFA/Modern Auth, suporte oficial | Curva de aprendizado; casos avançados exigem tuning | Sempre que possível, especialmente para SharePoint/OneDrive |
| Migração manual | Sem dependência de app externo | Lenta, sujeita a erros, sem automação | Ambientes pequenos ou como último recurso |
Roteiro de solução de problemas focado em BitTitan/MigrationWiz
- Exchange: autenticação OK mas dados não fluem? Verificar throttling, limites de EWS e escopo do app (Application Access Policy).
- OneDrive/SharePoint: erros 401/403? Conferir permissões do app e consentimento. Se usar Sites.Selected, confirmar a concessão por site.
- Registro do app: Client ID/Secret corretos? Certificado válido? Redirect URI conforme a ferramenta?
- Conditional Access: há política exigindo app aprovado ou dispositivo compatível? Excluir contas de migração.
- Rede: validar resolução DNS, saída de Internet e IP de origem (para aplicar localização nomeada na CA).
Dicas finais
- Planeje janelas de migração com mudança programada, ponto de reversão e aprovação.
- Mantenha um quadro Kanban de exclusões/reversões e valide com auditoria cruzada após o término.
- Teste autenticação e permissões para cada workload antes de disparar o lote completo.
Conclusão
- Desativar MFA no locatário não é aconselhável e, com o fim da Basic Auth, não resolve migrações que exigem Modern Auth.
- A abordagem via Conditional Access com exclusões por grupo pode remover prompts de MFA temporariamente, porém o sucesso depende de a ferramenta suportar OAuth.
- Quando houver incompatibilidade, use as soluções nativas da Microsoft ou atualize/ajuste a ferramenta para Autenticação Moderna; como último recurso, execute migração manual.