Compartilhar via

Transição para a nuvem

Depois de alinhar sua organização para interromper o crescimento da presença dos Serviços de Domínio Active Directory (AD DS), você pode se concentrar em mover as cargas de trabalho já existentes no local para o Microsoft Entra ID. Este artigo descreve os vários fluxos de trabalho de migração. Você pode executar os fluxos de trabalho neste artigo com base em suas prioridades e recursos.

Um fluxo de trabalho de migração típico tem as seguintes fases:

  • Descobrir: descubra o que você tem atualmente em seu ambiente.

  • Piloto: implante novas funcionalidades de nuvem em um subconjunto pequeno de usuários, aplicativos ou dispositivos, dependendo do fluxo de trabalho.

  • Expansão: expanda o piloto para concluir a transição de uma funcionalidade para a nuvem.

  • Transferir (quando aplicável): pare de usar a carga de trabalho local antiga.

Usuários e grupos

Habilitar autoatendimento de senha

É recomendável usar um ambiente sem senha. Até lá, você pode migrar fluxos de trabalho de autoatendimento de senhas de sistemas locais para o Microsoft Entra ID para simplificar seu ambiente. A redefinição de senha self-service (SSPR) do Microsoft Entra ID dá aos usuários a capacidade de alterar ou redefinir suas senhas, sem o envolvimento do administrador ou da assistência técnica.

Para habilitar recursos de autoatendimento, escolha os métodos de autenticação apropriados para sua organização. Após a atualização dos métodos de autenticação, você deve habilitar a capacidade de senha de self-service do usuário para o seu ambiente de autenticação do Microsoft Entra. Para obter diretrizes de implantação, consulte Considerações sobre a implantação da redefinição de senha self-service do Microsoft Entra.

As considerações adicionais incluem:

Observação

Mover grupos de gerenciamento

Como transformar grupos e listas de distribuição:

  • Para grupos de segurança existentes criados no AD DS que agora são usados exclusivamente para conceder acesso aos recursos de nuvem, use a transferência da Fonte de Autoridade de Grupo (SOA) para tornar esses grupos exclusivamente em nuvem. Gerencie a associação de grupo da nuvem. Em seguida, exclua o grupo do AD DS.
  • Para os grupos de segurança existentes criados no AD DS que ainda necessitam de presença no AD, atualize o escopo do grupo do AD para ser universal (se ainda não for). Em seguida, use o SOA do Grupo para converter esses grupos para serem editáveis na nuvem e gerenciar a associação a partir da nuvem. Por fim, use o provisionamento de grupos no Active Directory Domain Services (AD DS) para atualizar o Active Directory (AD) com quaisquer mudanças feitas na nuvem, garantindo que a associação local permaneça sincronizada.
  • Para a lógica de negócios que atribui usuários a grupos de segurança, avalie se você pode migrar a lógica para a ID do Entra e usar grupos de associação dinâmica.
  • Para funcionalidades de grupos autogerenciados fornecidos pelo Microsoft Identity Manager, substitua a funcionalidade pelo gerenciamento de grupos de autoatendimento.
  • Você pode converter listas de distribuição para grupos do Microsoft 365 no Outlook. Essa abordagem é uma ótima maneira de fornecer às listas de distribuição da sua organização todos os recursos e funcionalidades dos grupos do Microsoft 365.
  • Atualize suas listas de distribuição para grupos do Microsoft 365 no Outlook.

Mover o provisionamento de usuários e grupos para os aplicativos

Você pode simplificar seu ambiente removendo fluxos de provisionamento de aplicativos de sistemas de IDM (gerenciamento de identidades) locais, como o Microsoft Identity Manager. Com base na descoberta do aplicativo, categorize seu aplicativo considerando as seguintes características:

  • Aplicativos em seu ambiente que têm uma integração de provisionamento com a galeria de aplicativos do Microsoft Entra.

  • Aplicações que não estão na galeria, mas dão suporte o protocolo SCIM 2.0. Esses aplicativos são nativamente compatíveis com o serviço de provisionamento em nuvem do Microsoft Entra.

  • Aplicativos locais com um conector ECMA disponível. Esses aplicativos podem ser integrados ao provisionamento de aplicativos locais do Microsoft Entra.

Para obter mais informações, verifique Planejar a implantação do provisionamento automático de usuários para o Microsoft Entra ID.

Mover para o provisionamento de RH na nuvem

É possível reduzir o espaço ocupado no local movendo os fluxos de trabalho de provisionamento de RH dos sistemas IDM locais, como o Microsoft Identity Manager, para o Microsoft Entra ID. Dois tipos de conta estão disponíveis para o provisionamento de RH na nuvem do Microsoft Entra:

  • Para novos funcionários que estejam utilizando exclusivamente aplicativos do Microsoft Entra ID, você pode optar por provisionar contas somente na nuvem. Esse provisionamento ajuda você a conter a pegada do AD DS.

  • Para novos funcionários que precisam de acesso a aplicativos que têm dependência do AD DS, você pode provisionar contas híbridas.

O provisionamento de RH na nuvem do Microsoft Entra também pode gerenciar contas do AD DS para funcionários existentes. Para obter mais informações, consulte Planejar o aplicativo de RH na nuvem para o provisionamento de usuários do Microsoft Entra e Planejar o projeto de implantação.

Migrar fluxos de trabalho do ciclo de vida

Avalie seus fluxos de trabalho e processos existentes para seu ambiente de nuvem do Microsoft Entra, para verificar se são aplicáveis e relevantes. Em seguida você pode simplificar esses fluxos de trabalho e criar novos usando fluxos de trabalho do ciclo de vida.

Mover o gerenciamento de identidades externas

Se sua organização provisionar contas no AD DS ou em outros diretórios locais para identidades externas, como fornecedores, empreiteiros ou consultores, você poderá simplificar seu ambiente gerenciando esses objetos de usuário de terceiros nativamente na nuvem. Veja a seguir algumas possibilidades:

  • Para novos usuários externos, use o ID Externa do Microsoft Entra, que interrompe a pegada do AD DS de usuários.

  • Para contas do AD DS existentes que você provisiona para identidades externas, você pode remover a sobrecarga de gerenciar credenciais locais (por exemplo, senhas) configurando-as para colaboração B2B (entre empresas). Siga as etapas em convidar usuários internos para Colaboração B2B.

  • Use o gerenciamento de direitos do Microsoft Entra para conceder acesso a aplicativos e recursos. A maioria das empresas tem sistemas dedicados e fluxos de trabalho para essa finalidade que agora você pode mover para fora de ferramentas locais.

  • Use as revisões de acesso para remover direitos de acesso e/ou identidades externas que não são mais necessárias.

Dispositivos

Mover estações de trabalho não Windows

É possível integrar estações de trabalho que não sejam Windows ao Microsoft Entra ID para aprimorar a experiência do usuário e se beneficiar dos recursos de segurança baseados em nuvem, como o acesso condicional.

Substituir outras versões do Windows para estações de trabalho

Se você tiver os seguintes sistemas operacionais nas estações de trabalho, considere atualizar para as versões mais recentes para se beneficiar do gerenciamento nativo da nuvem (Microsoft Entra e gerenciamento unificado de pontos de extremidade):

  • Windows 7 ou 8.x

  • Servidor Windows

Solução VDI

Este projeto tem duas iniciativas primárias:

  • Novas implantações: implantar uma solução de VDI (infraestrutura de área de trabalho virtual) gerenciada por nuvem, como o Windows 365 ou a Área de Trabalho Virtual do Azure, que não exige o AD DS local.

  • Implantações existentes: se sua implantação de VDI existente depender do AD DS, use objetivos de negócios e metas para determinar se você mantém a solução ou a migra para a ID do Microsoft Entra.

Para saber mais, veja:

Aplicativos

Para ajudar a manter um ambiente seguro, o Microsoft Entra ID dá suporte a modernos protocolos de autenticação. Para fazer a transição da autenticação de aplicativo do AD DS para a ID do Microsoft Entra, você deve:

  • Determine quais aplicativos podem migrar para o Microsoft Entra ID sem nenhuma modificação.

  • Determinar quais aplicativos têm um caminho de atualização que permite migrar com uma atualização.

  • Determinar quais aplicativos exigem substituição ou alterações significativas de código para migrar.

O resultado da sua iniciativa de descoberta de aplicativo é criar uma lista priorizada para migração de seu portfólio de aplicativos. A lista contém aplicativos que:

  • Exigem upgrade ou atualização do software e um caminho de upgrade está disponível.

  • Exigem upgrade ou atualização do software, mas não há um caminho de upgrade disponível.

Usando a lista, você pode avaliar ainda mais os aplicativos que não têm um caminho de atualização existente. Determine se o valor comercial garante a atualização do software ou se ele deve ser desativado. Se o software precisar ser desativado, decida se você precisa de uma substituição.

Com base nos resultados, você pode redesenhar aspectos da transformação do AD DS para o Microsoft Entra ID. Há abordagens que você pode usar para estender o AD DS local para a infraestrutura como serviço (IaaS) do Azure, utilizando a estratégia de "lift and shift", para aplicativos com protocolos de autenticação sem suporte. Recomendamos que você defina uma política que exija uma exceção para usar essa abordagem.

Descoberta de aplicativo

Depois de segmentar seu portfólio de aplicativos, você poderá priorizar a migração com base no valor comercial e na prioridade de negócios. Você pode usar ferramentas para criar ou atualizar o inventário do aplicativo.

Existem três maneiras principais para categorizar seus aplicativos:

  • Aplicativos de autenticação modernos: esses aplicativos usam protocolos de autenticação modernos (como OIDC, OAuth2, SAML, Web Services Federation) ou que usam Serviços de Federação do Active Directory (AD FS).

  • Ferramentas do WAM (gerenciamento de acesso via Web): esses aplicativos usam cabeçalhos, cookies e técnicas semelhantes para SSO. Esses aplicativos normalmente exigem um provedor de identidade WAM, como o Symantec SiteMinder.

  • Aplicativos herdados: esses aplicativos usam protocolos herdados como Kerberos, LDAP, Radius, Área de Trabalho Remota e NTLM (não recomendado).

O Microsoft Entra ID pode ser utilizado com cada tipo de aplicativo para fornecer níveis de funcionalidade que resultam em diferentes estratégias de migração, complexidade e compensações. Algumas organizações têm um inventário de aplicativos que pode ser usado como uma linha de base de descoberta. (É comum que esse inventário não esteja concluído ou atualizado).

Para descobrir aplicativos de autenticação modernos:

As ferramentas a seguir podem ajudar você a descobrir aplicativos que usam LDAP:

  • Event1644Reader: ferramenta de exemplo para coletar dados em consultas LDAP feitas em controladores de domínio usando os logs de engenharia de campo.

  • Microsoft 365 Defender para Identidade: solução de segurança que usa uma funcionalidade de monitoramento de operações de entrada. (Observe que ele captura associações usando LDAP, não LDAP Seguro.)

  • PSLDAPQueryLogging: ferramenta GitHub para relatórios sobre consultas LDAP.

Migrar o AD FS ou outros serviços de federação

Ao planejar a migração para o Microsoft Entra ID, considere migrar os aplicativos que usam protocolos de autenticação modernos (como SAML e OpenID Connect) primeiro. É possível reconfigurar esses aplicativos para autenticar com o Microsoft Entra ID por meio de um conector interno da Galeria de Aplicativos do Azure ou por meio do registro no Microsoft Entra ID.

Após mover os aplicativos SaaS que foram federados para o Microsoft Entra ID, existem algumas etapas para descomissionar o sistema de federação local:

Importante

Se você estiver usando outros recursos, verifique se esses serviços foram realocados antes de desativar o AD FS.

Mover aplicativos de autenticação WAM

Esse projeto foca na migração da capacidade de SSO dos sistemas WAM para o Microsoft Entra ID. Para obter mais informações, consulte Migrar aplicativos do Symantec SiteMinder para o Microsoft Entra ID.

Definir uma estratégia de gerenciamento para servidor de aplicativos

Em termos de gerenciamento de infraestrutura, os ambientes locais geralmente usam uma combinação de GPOs (objetos de Política de Grupo) e recursos do Microsoft Configuration Manager para tarefas de gerenciamento de segmentos. Por exemplo, as tarefas podem ser segmentadas em gerenciamento de política de segurança, gerenciamento de atualizações, gerenciamento de configuração e monitoramento.

O AD DS é para ambientes de TI locais e a ID do Microsoft Entra é para ambientes de TI baseados em nuvem. A paridade um-para-um dos recursos não está presente aqui, portanto, você pode gerenciar servidores de aplicativos de várias maneiras.

Por exemplo, o Azure Arc ajuda a reunir muitos dos recursos que existem no AD DS em uma única exibição quando você usa a ID do Microsoft Entra para IAM (gerenciamento de identidade e acesso). Você também pode usar o Microsoft Entra DS (Serviços de Domínio) para fazer a junção de domínios de servidores no Microsoft Entra ID, especialmente quando desejar que esses servidores utilizem GPOs por motivos comerciais ou técnicos específicos.

Use a seguinte tabela para determinar quais ferramentas baseadas no Azure você pode usar para substituir o ambiente local:

Área de gerenciamento Recurso do Local (AD DS) Recurso equivalente do Microsoft Entra
Gerenciamento de políticas de segurança GPO, Microsoft Configuration Manager Microsoft 365 Defender para Nuvem
Gerenciamento de atualizações Microsoft Configuration Manager, Windows Server Update Services Gerenciador de Atualizações do Azure
Gerenciamento de configuração GPO, Microsoft Configuration Manager Configuração do Azure Machine
Monitoramento System Center Operations Manager Azure Monitor

Veja mais informações que podem ser usadas para o gerenciamento do servidor de aplicativos:

Se for necessário o gerenciamento de servidores de aplicativos com o Microsoft Configuration Manager, não será possível atender a esse requisito utilizando o Serviços de Domínio do Microsoft Entra. Não há suporte para executar o Microsoft Configuration Manager em um ambiente do Serviços de Domínio do Microsoft Entra. Em vez disso, você precisa estender sua instância do AD DS local para um controlador de domínio em execução em uma VM do Azure. Ou você precisa implantar uma nova instância do AD DS em uma rede virtual iaaS do Azure.

Definir a estratégia de migração para aplicativos herdados

Aplicativos herdados têm dependências como estas no AD DS:

  • Autenticação e autorização do usuário: Kerberos, NTLM, associação LDAP, ACLs.

  • Acesso aos dados de diretório: consultas LDAP, extensões de esquema, leitura/gravação de objetos do directory.

  • Gerenciamento de servidor: conforme determinado pela estratégia de gerenciamento de servidor.

Para reduzir ou eliminar essas dependências, você tem três abordagens principais.

Abordagem 1

Na abordagem preferencial, você executa projetos para migrar de aplicativos herdados para alternativas de SaaS que usam autenticação moderna. Faça com que as alternativas de SaaS se autentiquem diretamente no Microsoft Entra ID:

  1. Implante o Serviços de Domínio do Microsoft Entra em uma rede virtual do Azure e amplie o esquema para incorporar os atributos adicionais necessários pelos aplicativos.

  2. Transfira aplicativos herdados para as VMs na rede virtual do Azure que estão ingressadas no domínio do Serviços de Domínio do Microsoft Entra.

  3. Publique aplicativos herdados na nuvem utilizando o proxy de aplicativos do Microsoft Entra ou um parceiro de acesso híbrido seguro.

  4. À medida que os aplicativos herdados forem desativados por desgaste, passe a desativar o Serviços de Domínio do Microsoft Entra em execução na rede virtual do Azure.

Observação

Abordagem 2

Se a primeira abordagem não for possível e um aplicativo tiver uma forte dependência do AD DS, você poderá estender o AD DS local para o IaaS do Azure.

Você pode reposicionar para dar suporte à hospedagem moderna sem servidor — por exemplo, usar PaaS (plataforma como serviço). Ou você pode atualizar o código para dar suporte à autenticação moderna. Você também pode habilitar o aplicativo para se integrar diretamente ao Microsoft Entra ID. Saiba mais sobre a Biblioteca de Autenticação da Microsoft no plataforma de identidade da Microsoft.

  1. Conecte uma rede virtual do Azure à rede local por meio da VPN (rede virtual privada) ou do Azure ExpressRoute.

  2. Implante novos controladores de domínio para a instância do AD DS local como máquinas virtuais na rede virtual do Azure.

  3. Migrar e transferir aplicativos legados para máquinas virtuais na rede virtual Azure que estão unidas a um domínio.

  4. Publique aplicativos herdados na nuvem utilizando o proxy de aplicativos do Microsoft Entra ou um parceiro de acesso híbrido seguro.

  5. Eventualmente, desative a infraestrutura do AD DS local e execute totalmente o AD DS na rede virtual do Azure.

  6. À medida que os aplicativos herdados deixam de ser usados, eventualmente desativa a instância do AD DS em execução na rede virtual do Azure.

Abordagem 3

Se a primeira migração não for possível e um aplicativo tiver uma forte dependência do AD DS, você poderá implantar uma nova instância do AD DS no IaaS do Azure. Deixar os aplicativos como aplicativos herdados para um futuro próximo ou encerrá-los quando as oportunidades surgirem.

Essa abordagem permite que você desvincula o aplicativo da instância existente do AD DS para reduzir a área de superfície. Recomendamos que isso seja considerada apenas como um último recurso.

  1. Implante uma nova instância do AD DS como máquinas virtuais em uma rede virtual do Azure.

  2. Migre e transponha aplicativos legados para máquinas virtuais (VMs) na rede virtual do Azure que estão associadas ao domínio da nova instância do AD DS.

  3. Publique aplicativos herdados na nuvem utilizando o proxy de aplicativos do Microsoft Entra ou um parceiro de acesso híbrido seguro.

  4. À medida que os aplicativos herdados são desativados gradualmente, eventualmente desative a instância do AD DS em execução na rede virtual do Azure.

Comparação de estratégias

Estratégia Serviços de Domínio do Microsoft Entra Estender o AD DS para IaaS Instância independente do AD DS no IaaS
Desacoplamento dos serviços do Active Directory Domain Services (AD DS) local. Sim Não Sim
Permitindo extensões de esquema Não Sim Sim
Controle administrativo total Não Sim Sim
Possível reconfiguração dos aplicativos necessários (por exemplo, ACLs ou autorização) Sim Não Sim

Mover a autenticação da VPN

Esse projeto foca na mudança da sua autenticação de VPN para o Microsoft Entra ID. É importante saber que há diferentes configurações disponíveis para conexões de gateway de VPN. Você precisa determinar qual configuração melhor atende às suas necessidades. Para obter mais informações sobre como criar uma solução, consulte Criar gateway de VPN.

Aqui estão os principais pontos sobre o uso do Microsoft Entra ID para autenticação de VPN:

Mover acesso remoto para aplicativos internos

Para simplificar seu ambiente, você pode usar parceiros de proxy de aplicativos do Microsoft Entra ou de acesso híbrido seguro para fornecer acesso remoto. Isso permite que você remova a dependência de soluções de proxy reverso locais.

É importante mencionar que a habilitação do acesso remoto a um aplicativo usando as tecnologias anteriores é uma etapa provisória. Você precisa fazer mais trabalho para desacoplar completamente o aplicativo do AD DS.

O Microsoft Entra Domain Services permite migrar servidores de aplicativos para a iaaS de nuvem e desacoplar do AD DS, usando o proxy de aplicativo do Microsoft Entra para habilitar o acesso remoto. Para obter mais informações sobre esse cenário, verifique Implantar o proxy de aplicativos do Microsoft Entra para o Microsoft Entra Domain Services.

Próximas etapas

  • Last updated on