Transição para a nuvem

  • Artigo

Depois de alinhar sua organização para interromper o crescimento da pegada do Ative Directory, você pode se concentrar em mover as cargas de trabalho locais existentes 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 os seguintes estágios:

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

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

  • Dimensionamento: expanda o piloto para concluir a transição de um recurso para a nuvem.

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

Utilizadores e grupos

Ativar autosserviço de senha

Recomendamos um ambiente sem senha. Até lá, você pode migrar fluxos de trabalho de autoatendimento de senha de sistemas locais para o Microsoft Entra ID para simplificar seu ambiente. A redefinição de senha de autoatendimento (SSPR) do Microsoft Entra ID oferece aos usuários a capacidade de alterar ou redefinir sua senha, sem envolvimento de administrador ou suporte técnico.

Para habilitar os recursos de autoatendimento, escolha os métodos de autenticação apropriados para sua organização. Depois que os métodos de autenticação forem atualizados, você poderá habilitar o recurso de senha de autoatendimento do usuário para seu ambiente de autenticação do Microsoft Entra. Para obter diretrizes de implantação, consulte Considerações de implantação para a redefinição de senha de autoatendimento do Microsoft Entra.

Considerações adicionais incluem:

  • Implante a Proteção por Senha do Microsoft Entra em um subconjunto de controladores de domínio com o modo de Auditoria para coletar informações sobre o impacto das políticas modernas.
  • Habilite gradualmente o registro combinado para autenticação multifator SSPR e Microsoft Entra. Por exemplo, distribua por região, subsidiária ou departamento para todos os usuários.
  • Passe por um ciclo de alteração de senha para todos os usuários para liberar senhas fracas. Após a conclusão do ciclo, implemente o tempo de expiração da política.
  • Alterne a configuração de Proteção por Senha nos controladores de domínio que têm o modo definido como Imposto. Para obter mais informações, consulte Habilitar a proteção por senha do Microsoft Entra local.

Nota

Gestão de movimentos de grupos

Para transformar grupos e listas de distribuição:

  • Para grupos de segurança, use sua lógica de negócios existente que atribui usuários a grupos de segurança. Migre a lógica e a capacidade para o Microsoft Entra ID e grupos dinâmicos.

  • Para recursos de grupo autogerenciados fornecidos pelo Microsoft Identity Manager, substitua o recurso pelo gerenciamento de grupo 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 e encerre seu servidor Exchange local.

Mover o provisionamento de usuários e grupos para aplicativos

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

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

  • Aplicativos que não estão na galeria, mas suportam o protocolo SCIM 2.0. Esses aplicativos são compatíveis nativamente com o serviço de provisionamento de nuvem Microsoft Entra.

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

Para obter mais informações, consulte Planejar uma implantação de provisionamento automático de usuário para o Microsoft Entra ID.

Mude para o provisionamento de RH na nuvem

Você pode reduzir sua pegada local movendo os fluxos de trabalho de provisionamento de RH de 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 usam exclusivamente aplicativos que usam o Microsoft Entra ID, você pode optar por provisionar contas somente na nuvem. Esse provisionamento ajuda a conter a pegada do Ative Directory.

  • Para novos funcionários que precisam de acesso a aplicativos que dependem do Ative Directory, você pode provisionar contas híbridas.

O provisionamento de RH na nuvem do Microsoft Entra também pode gerenciar contas do Ative Directory 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.

Mover fluxos de trabalho do ciclo de vida

Avalie seus fluxos de trabalho e processos existentes de marceneiro/movimentador/abandono quanto à aplicabilidade e relevância ao seu ambiente de nuvem Microsoft Entra. Em seguida, você pode simplificar esses fluxos de trabalho e criar novos usandofluxos de trabalho do ciclo de vida.

Mover o gerenciamento de identidades externas

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

  • Para novos usuários externos, use o Microsoft Entra External ID, que interrompe a pegada dos usuários do Ative Directory.

  • Para contas existentes do Ative Directory provisionadas para identidades externas, você pode remover a sobrecarga de gerenciamento de credenciais locais (por exemplo, senhas) configurando-as para colaboração entre empresas (B2B). 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 e fluxos de trabalho dedicados para essa finalidade, que agora você pode sair das 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 que não sejam Windows

Pode integrar estações de trabalho que não sejam Windows com o Microsoft Entra ID para melhorar a experiência do utilizador e beneficiar de funcionalidades de segurança baseadas na nuvem, como o Acesso Condicional.

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

Se você tiver os seguintes sistemas operacionais em estações de trabalho, considere atualizar para as versões mais recentes para se beneficiar do gerenciamento nativo da nuvem (Microsoft Entra join e unified endpoint management):

  • Windows 7 ou 8.x

  • Windows Server

Solução VDI

Este projeto tem duas iniciativas principais:

  • Novas implantações: implante uma solução de VDI (infraestrutura de área de trabalho virtual) gerenciada na nuvem, como o Windows 365 ou a Área de Trabalho Virtual do Azure, que não exija o Ative Directory local.

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

Para obter mais informações, consulte:

Aplicações

Para ajudar a manter um ambiente seguro, o Microsoft Entra ID suporta protocolos de autenticação modernos. Para fazer a transição da autenticação do aplicativo do Ative Directory para o Microsoft Entra ID, você deve:

  • Determine quais aplicativos podem migrar para o Microsoft Entra ID sem modificações.

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

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

O resultado de sua iniciativa de descoberta de aplicativos é criar uma lista de prioridades para migrar seu portfólio de aplicativos. A lista contém aplicações que:

  • Requer uma atualização ou atualização para o software e um caminho de atualização está disponível.

  • Requer uma atualização ou atualização para o software, mas um caminho de atualização não está disponível.

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

Com base nos resultados, você pode redesenhar aspetos da sua transformação do Ative Directory para o Microsoft Entra ID. Há abordagens que você pode usar para estender o Ative Directory local para a infraestrutura como serviço (IaaS) do Azure (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.

Deteção de aplicações

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

Há três maneiras principais de categorizar seus aplicativos:

  • Aplicativos de autenticação modernos: esses aplicativos usam protocolos de autenticação modernos (como OIDC, OAuth2, SAML ou WS-Federation) ou que usam um serviço de federação, como os Serviços de Federação do Ative Directory (AD FS).

  • Ferramentas de gerenciamento de acesso à Web (WAM): esses aplicativos usam cabeçalhos, cookies e técnicas semelhantes para SSO. Esses aplicativos geralmente 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 usado 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 completo ou atualizado.)

Para descobrir aplicativos de autenticação modernos:

  • Se estiver a utilizar o AD FS, utilize o relatório de atividade da aplicação AD FS.

  • Se você estiver usando um provedor de identidade diferente, use os logs e a configuração.

As ferramentas a seguir podem ajudá-lo a descobrir aplicativos que usam LDAP:

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

  • Microsoft 365 Defender for Identity: Solução de segurança que utiliza uma capacidade de monitorização de operações de início de sessão. (Observe que ele captura ligações usando LDAP, não Secure LDAP.)

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

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

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

Depois de mover aplicativos SaaS que foram federados para o Microsoft Entra ID, há algumas etapas para encerrar o sistema de federação local:

Importante

Se você estiver usando outros recursos, verifique se esses serviços foram realocados antes de encerrar os Serviços de Federação do Ative Directory.

Mover aplicativos de autenticação WAM

Este projeto se concentra na migração da capacidade de SSO de sistemas WAM para o Microsoft Entra ID. Para saber mais, consulte Migrar aplicativos do Symantec SiteMinder para o Microsoft Entra ID.

Definir uma estratégia de gerenciamento de servidor de aplicativos

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

O Ative Directory é para ambientes de TI locais e o Microsoft Entra ID é para ambientes de TI baseados em nuvem. A paridade de recursos um-para-um 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 existentes no Ative Directory em um único modo de exibição quando você usa o Microsoft Entra ID para gerenciamento de identidade e acesso (IAM). Você também pode usar os Serviços de Domínio do Microsoft Entra para ingressar em servidores de domínio na ID do Microsoft Entra, especialmente quando quiser que esses servidores usem GPOs por motivos comerciais ou técnicos específicos.

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

Área de gestão Recurso local (Ative Directory) Recurso equivalente do Microsoft Entra
Gestão de políticas de segurança GPO, Gerenciador de Configuração da Microsoft Microsoft 365 Defender para nuvem
Gestão de atualizações Microsoft Configuration Manager, Windows Server Update Services Gestão de Atualizações da Automatização do Azure
Gestão de configuração GPO, Gerenciador de Configuração da Microsoft Configuração do Estado de Automação do Azure
Monitorização System Center Operations Manager Azure Monitor Log Analytics

Veja mais informações que você pode usar para o gerenciamento do servidor de aplicativos:

Se você precisar de gerenciamento de servidores de aplicativos com o Microsoft Configuration Manager, não poderá atender a esse requisito usando os Serviços de Domínio Microsoft Entra. Não há suporte para execução do Microsoft Configuration Manager em um ambiente de Serviços de Domínio Microsoft Entra. Em vez disso, você precisa estender sua instância do Ative Directory local para um controlador de domínio em execução em uma VM do Azure. Ou, você precisa implantar uma nova instância do Ative Directory em uma rede virtual IaaS do Azure.

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

Os aplicativos herdados têm dependências como estas para o Ative Directory:

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

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

  • 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 preferida, você realiza projetos para migrar de aplicativos herdados para alternativas SaaS que usam autenticação moderna. Faça com que as alternativas SaaS se autentiquem diretamente no Microsoft Entra ID:

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

  2. Levante e transfira aplicativos herdados para VMs na rede virtual do Azure que ingressaram no domínio dos Serviços de Domínio do Microsoft Entra.

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

  4. À medida que os aplicativos herdados se desativam por desgaste, acabe desativando os Serviços de Domínio Microsoft Entra em execução na rede virtual do Azure.

Nota

Abordagem 2

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

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

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

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

  3. Levante e mude aplicativos herdados para VMs na rede virtual do Azure que ingressaram no domínio.

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

  5. Eventualmente, descomissione a infraestrutura local do Ative Directory e execute totalmente o Ative Directory na rede virtual do Azure.

  6. À medida que os aplicativos herdados são desativados por desgaste, acabe encerrando a instância do Ative Directory 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 Ative Directory, você poderá implantar uma nova instância do Ative Directory na IaaS do Azure. Deixe os aplicativos como aplicativos legados para o futuro previsível ou deixe-os cair quando a oportunidade surgir.

Essa abordagem permite separar o aplicativo da instância existente do Ative Directory para reduzir a área de superfície. Recomendamos que o considere apenas como último recurso.

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

  2. Levante e mude aplicativos herdados para VMs na rede virtual do Azure que ingressaram no domínio para a nova instância do Ative Directory.

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

  4. À medida que os aplicativos herdados são desativados por desgaste, acabe encerrando a instância do Ative Directory em execução na rede virtual do Azure.

Comparação de estratégias

Estratégia Microsoft Entra Domain Services Estenda o Ative Directory para IaaS Instância independente do Ative Directory em IaaS
Desacoplamento do Ative Directory local Sim No Sim
Permitindo extensões de esquema Não Sim Sim
Controlo administrativo total Não Sim Sim
Possível reconfiguração de aplicativos necessários (por exemplo, ACLs ou autorização) Sim No Sim

Mover autenticação VPN

Este projeto se concentra em mover sua autenticação VPN para o Microsoft Entra ID. É importante saber que diferentes configurações estão disponíveis para conexões de gateway VPN. Deve determinar qual das configurações se adequa melhor às suas necessidades. Para obter mais informações sobre como projetar uma solução, consulte Design de gateway VPN.

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

Mova o acesso remoto para aplicativos internos

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

É importante mencionar que habilitar o acesso remoto a um aplicativo usando as tecnologias anteriores é uma etapa provisória. Você precisa fazer mais trabalho para dissociar completamente o aplicativo do Ative Directory.

Os Serviços de Domínio Microsoft Entra permitem migrar servidores de aplicativos para a nuvem IaaS e desacoplar do Ative Directory, enquanto usa o proxy de aplicativo Microsoft Entra para habilitar o acesso remoto. Para saber mais sobre esse cenário, verifique Implantar proxy de aplicativo Microsoft Entra para Serviços de Domínio Microsoft Entra.

Próximos passos