De Active Directory On-Premises ao Microsoft 365: Identidade, E-mail e Endpoints em 4 Meses

Resumo executivo

Este estudo de caso documenta uma transformação de infraestrutura realizada em aproximadamente quatro meses.

O ponto de partida não era um ambiente híbrido. A organização operava com Active Directory local como diretório principal, um serviço de e-mail separado da plataforma Microsoft 365 e uma base de identidades que havia crescido sem um padrão único de nomes, funções e organização do diretório.

A modernização começou antes do Intune. Primeiro foi necessário definir um modelo de identidade, sanear o Active Directory, mapear contas existentes e consolidar corretamente as identidades locais e cloud. Em paralelo, o Exchange Online foi preparado para assumir o e-mail corporativo e substituir o serviço legado sem criar uma ruptura perceptível para os usuários.

Somente depois dessa fundação a estratégia avançou para provisionamento Windows, Microsoft Entra Hybrid Join, Microsoft Intune, Microsoft Defender, conformidade, Conditional Access e modernização dos dados dos usuários.

A implementação real permanece privada. Nomes internos, identificadores, credenciais, topologia detalhada, grupos, políticas específicas e demais informações sensíveis foram omitidos ou generalizados.

Meu papel

Conduzi ponta a ponta o desenho e a execução técnica desta modernização ao longo de aproximadamente quatro meses. O trabalho incluiu definição do modelo de identidade, saneamento e reorganização do Active Directory, mapeamento e consolidação das contas existentes, preparação e migração do fluxo de e-mail para Exchange Online e, na etapa seguinte, automação do provisionamento Windows e implantação do gerenciamento moderno com Intune e Defender.

O desafio não era apenas configurar produtos. Era alterar componentes centrais de identidade, mensageria e endpoints em uma sequência que preservasse a continuidade operacional e permitisse validar cada etapa antes de ampliar o escopo.

Antes → Depois

Ponto de partida

O ambiente havia sido construído ao longo do tempo em torno do Active Directory local. O diretório cumpria sua função operacional, mas não possuía uma estrutura suficientemente padronizada para servir como origem confiável de uma integração ampla com serviços cloud.

Havia contas com convenções diferentes, identidades pessoais e endereços funcionais que precisavam ser diferenciados, atributos inconsistentes e uma organização de OUs que exigia revisão.

O e-mail também seguia uma trilha independente. O domínio corporativo era atendido por uma plataforma separada, enquanto Microsoft 365 e Teams já introduziam novas identidades e serviços cloud.

Antes de sincronizar tudo, era necessário responder uma pergunta básica: qual identidade representa cada pessoa em cada sistema?

Identidade antes da sincronização

A primeira decisão foi tratar identidade como um modelo de governança, e não apenas como um atributo técnico.

Foram definidos padrões para nome de usuário e UPN, endereço de e-mail principal, aliases, endereços funcionais, shared mailboxes, separação entre contas administrativas e contas de uso diário e tratamento documentado de exceções.

Uma identidade pessoal deveria representar uma pessoa. Endereços associados a uma área ou função deveriam permanecer como aliases ou caixas compartilhadas quando esse modelo fosse mais adequado.

Essa separação melhora onboarding, offboarding e auditoria porque reduz o acoplamento entre o colaborador atual e uma função organizacional permanente.

Saneamento e reorganização do Active Directory

A consolidação com a nuvem não começou pela ferramenta de sincronização. Começou pela correção da fonte.

O Active Directory foi revisado em ondas controladas. Nomes, UPNs, atributos, grupos e organização de OUs foram ajustados antes de ampliar a integração com Microsoft 365.

A estrutura final concentra as identidades e objetos corporativos relevantes sob uma hierarquia de diretório única e previsível. No estudo público, o caminho operacional exato é omitido; o ponto arquitetural é que o escopo deixou de ser fragmentado e passou a possuir uma raiz corporativa clara para políticas, sincronização e automação.

Essa reorganização também tornou mais simples definir o que pertence ao escopo de sincronização, onde novos objetos devem ser criados e quais políticas devem ser aplicadas a cada classe de dispositivo ou identidade.

Mapeamento das identidades existentes

O ambiente já possuía dados e histórico distribuídos entre sistemas diferentes. Por isso, a consolidação exigiu mapear as identidades antes de tentar associá-las automaticamente.

Para cada colaborador, a análise relacionou conta no Active Directory, UPN atual e desejado, identidade Microsoft 365 existente, licenciamento, uso de Teams, caixa de e-mail legada, aliases e endereços funcionais, contas administrativas e o status e risco da migração.

Esse inventário reduziu o risco de duplicar identidades ou associar uma conta local à conta cloud errada.

A mudança foi executada em lotes pequenos, com registro de estado anterior, estado posterior e possibilidade de rollback antes da próxima onda.

Da identidade on-premises à identidade híbrida

Depois do saneamento, as identidades locais puderam assumir de forma controlada as contas cloud que deveriam ser preservadas.

Essa etapa transformou o Active Directory de um diretório isolado em uma fonte integrada à identidade Microsoft, sem tratar a sincronização como um simples envio indiscriminado de objetos para a nuvem.

O objetivo era preservar contas e dados corretos, eliminar ambiguidades e estabelecer uma relação previsível entre:

Pessoa
  ↓
Active Directory
  ↓
Microsoft Entra ID
  ↓
Microsoft 365

Essa base posteriormente passou a suportar também identidade de dispositivo, enrollment e políticas de acesso.

Migração do e-mail para Exchange Online

A modernização da identidade ocorreu junto da preparação do novo ambiente de e-mail.

Antes de alterar o recebimento do domínio, o Exchange Online foi preparado com os destinatários esperados, licenças, mailboxes, aliases, caixas compartilhadas e histórico que precisava ser preservado.

A migração separou claramente identidades pessoais de endereços funcionais. Isso evitou carregar para o novo ambiente um problema antigo em que o endereço de uma área podia ser confundido com a identidade primária de uma pessoa.

O corte do fluxo de e-mail foi planejado somente depois dessa preparação. O serviço legado deixou de ser o ponto de entrada do domínio e o Exchange Online passou a assumir o recebimento.

Na prática, a transição ocorreu com impacto operacional mínimo para os usuários. O objetivo não era apenas mover caixas postais, mas alterar a plataforma de mensageria sem transformar a migração em uma interrupção perceptível do trabalho.

Depois do corte, o onboarding também mudou. Criar um novo colaborador deixou de depender da criação paralela de identidades independentes em sistemas diferentes e passou a seguir uma cadeia mais consistente de diretório, sincronização, licença e mailbox.

A modernização de endpoints começa depois da identidade

Com a identidade corporativa consolidada e o Microsoft 365 assumindo um papel central, o próximo problema passou a ser o ciclo de vida dos computadores.

Um computador ingressado no domínio não é necessariamente um endpoint gerenciado. Da mesma forma, um dispositivo presente no Intune não é automaticamente seguro ou elegível para acessar todos os recursos corporativos.

A arquitetura passou a tratar instalação e preparação do Windows, Domain Join, Microsoft Entra Hybrid Join, enrollment no Intune, distribuição de políticas e aplicações, proteção e telemetria, conformidade e decisão de acesso como estados relacionados, mas independentes.

Fronteira com o Windows Unattended Provisioning

A automação da instalação do Windows, Domain Join e Hybrid Microsoft Entra Join é tratada separadamente no projeto Windows Unattended Provisioning.

Esse projeto cobre a fase de bootstrap. O presente case study continua a jornada quando o dispositivo já possui uma base operacional e precisa entrar no ciclo contínuo de gerenciamento.

Windows Setup
    ↓
Domain Join
    ↓
Microsoft Entra Hybrid Join
    ↓
Microsoft Intune Enrollment
    ↓
Políticas e Aplicações
    ↓
Endpoint Security
    ↓
Compliance
    ↓
Conditional Access

Gerenciamento moderno do endpoint

O enrollment foi tratado como a transição entre identidade do dispositivo e gerenciamento contínuo. Depois do primeiro acesso corporativo, o endpoint passa a receber configurações e aplicações atribuídas pelo Intune. Como diversas operações são assíncronas, o simples aparecimento do dispositivo no portal não é considerado evidência de que todo o estado operacional foi alcançado.

A distribuição de software também foi centralizada utilizando o método mais adequado para cada aplicação: aplicações Microsoft, catálogo gerenciado, aplicações web e pacotes Win32 quando configuração e detecção personalizadas são necessárias. Um exemplo dessa abordagem é documentado no projeto RustDeskIntuneDeployment, que trata instalação, configuração e detecção como estados distintos.

A baseline do Windows passou a incorporar controles que antes dependiam de tratamento local ou processos separados. Windows LAPS reduz a dependência de credenciais administrativas compartilhadas; BitLocker adiciona proteção de dados em repouso e um sinal mensurável de conformidade; Update Rings tornam o ciclo de atualização mais previsível e permitem separar mudanças com perfis de risco diferentes, como sistema operacional e drivers.

O resultado é que enrollment, aplicação de políticas, instalação de software, administração local, criptografia e atualização passam a fazer parte de um modelo operacional centralizado e verificável.

Proteção e postura de segurança

Microsoft Defender for Business adicionou uma camada central de proteção, telemetria e resposta aos endpoints gerenciados. O piloto avaliou capacidades como antivírus, proteção em tempo real, EDR, firewall local, proteção contra adulteração, proteção web e resposta remota.

Controles com maior risco de incompatibilidade foram introduzidos gradualmente. Network Protection, Controlled Folder Access e regras de Attack Surface Reduction foram avaliados em modo de auditoria antes de qualquer decisão de bloqueio em produção. Esse padrão permite observar comportamento legítimo, incompatibilidades e falsos positivos antes de transformar hardening em enforcement.

A gestão de vulnerabilidades foi incorporada pelo mesmo princípio: recomendações são sinais para priorização e remediação, não ordens para executar automaticamente qualquer mudança sugerida pelo portal. Cada ação ainda precisa de contexto técnico, validação do patch e um método de implantação compatível com o risco operacional.

Confiança e controle de acesso

A política de conformidade cria uma distinção explícita entre dois estados: Managed, quando o dispositivo é administrado pela plataforma, e Compliant, quando também atende aos requisitos mínimos definidos pela organização.

Essa camada transforma características técnicas do endpoint em sinais reutilizáveis por outros controles de segurança.

Conditional Access foi validado inicialmente sem enforcement direto, permitindo observar como dispositivos gerenciados e não gerenciados seriam avaliados antes de bloquear usuários. A arquitetura passa a combinar identidade do usuário e estado do dispositivo, evitando que a posse de uma credencial válida seja o único sinal relevante para acesso a recursos corporativos.

Extensões da arquitetura

A modernização dos endpoints também incluiu a redução da dependência de armazenamento de perfil vinculado exclusivamente à rede local. OneDrive Known Folder Move foi avaliado como parte dessa transição, mantendo sincronização, retenção e backup como preocupações separadas.

O mesmo modelo conceitual foi estendido a dispositivos Android corporativos utilizando Android Enterprise. Enrollment, aplicações, restrições, proteção do endpoint e conformidade compõem uma cadeia equivalente à utilizada no Windows, respeitando limitações específicas de fabricantes e aplicações móveis.

A frente Android possui material suficiente para um estudo técnico separado e, por isso, permanece aqui apenas como extensão da arquitetura maior.

Estratégia de piloto e rollout

A implantação foi estruturada para evitar mudanças globais sem evidência prévia. O padrão foi começar com escopo controlado, validar funcionamento técnico e impacto operacional, utilizar Audit ou Report-only quando aplicável, documentar exceções e limitações, expandir em ondas e manter critérios de rollback antes de aumentar o raio de impacto.

Esse mesmo princípio havia sido utilizado no saneamento das identidades e na migração de e-mail: mudanças pequenas e observáveis antes de ampliar o escopo.

Resultados

Em aproximadamente quatro meses, a iniciativa mudou mais do que a ferramenta utilizada pela TI.

O ambiente saiu de uma arquitetura baseada em identidade local e mensageria separada para uma base integrada ao Microsoft 365, com Active Directory reorganizado e escopo corporativo previsível, identidades pessoais e funcionais tratadas de forma distinta, contas locais e cloud consolidadas sob um modelo único, Exchange Online como plataforma principal de e-mail, identidade híbrida para usuários e dispositivos, provisionamento Windows automatizado, gerenciamento centralizado por Intune, proteção e telemetria por Defender, conformidade mensurável e controles de acesso capazes de considerar o estado do dispositivo.

O computador deixa de ser apenas uma máquina ingressada no domínio e passa a ser tratado como uma entidade com identidade, gerenciamento, configuração, proteção, telemetria, conformidade e elegibilidade de acesso próprias.

Limitações e próximos passos

Alguns controles exigem períodos maiores de observação antes de enforcement. Outros dependem de compatibilidade de aplicações, comportamento de fabricantes ou decisões de política que precisam ser tomadas pela organização.

Os próximos passos naturais são evoluir políticas em Audit ou Report-only para enforcement controlado, consolidar critérios de saída de cada onda de rollout e aprofundar a gestão dos dispositivos Android em um estudo separado.

A governança de identidade também permanece um processo contínuo: o valor da reorganização do diretório depende de manter padrões de onboarding, offboarding, aliases, caixas compartilhadas e contas administrativas nas próximas mudanças do ambiente.

Projetos públicos relacionados

• Windows Unattended Provisioning — pipeline de instalação e identidade híbrida que prepara o dispositivo para o gerenciamento moderno.
• RustDeskIntuneDeployment — exemplo de empacotamento e validação de uma aplicação Win32 distribuída pelo Intune.

O que este estudo de caso demonstra

O ponto central desta modernização não foi adotar uma coleção de produtos Microsoft.

A sequência importou mais do que as ferramentas: primeiro organizar a identidade, depois consolidar diretórios e e-mail, em seguida automatizar o provisionamento e somente então utilizar o estado real dos endpoints como parte da segurança.

Essa abordagem permitiu transformar em poucos meses um ambiente tradicionalmente on-premises em uma arquitetura híbrida e gerenciada, sem depender de uma migração única e disruptiva e sem transportar toda a desorganização anterior para a nuvem.