Migrando do Azure Active Directory para o AWS Managed Microsoft AD – Parte 3

Por: Caio Ribeiro César, Principal Microsoft Specialist Solutions Architect, LATAM

O AWS Directory Service permite que você execute o Microsoft Active Directory (AD) como um serviço gerenciado. O AWS Directory Service para Microsoft Active Directory, também conhecido como AWS Managed Microsoft AD, é habilitado pelo Windows Server 2012 R2. Quando você seleciona e inicia esse tipo de diretório, ele é criado como um par altamente disponível de controladores de domínio conectados à sua nuvem privada virtual (VPC). Os controladores de domínio são executados em diferentes zonas de disponibilidade em uma região de sua escolha, além de possuir a funcionalidade de multi-região. O monitoramento e a recuperação de host, a replicação de dados, os snapshots e as atualizações de software são configurados e automaticamente gerenciados pela AWS.

Neste Blog Post, iremos discutir como migrar do Azure Active Directory para o AWS Managed Microsoft AD, em diferentes cenários. Iremos separar as postagens em 3 partes:

• Parte 1) Conectividade.
• Parte 2) Utilizando o Azure AD (Azure Active Directory) quando o ambiente possui integração com um Active Directory Domain Services (AD), e a ferramenta de Azure AD Connect.
• Parte 3) Utilizando o Azure AD DS (Azure Active Directory Domain Services), que fornece o serviço de domínio gerenciado, integrando com o Azure AD (você está aqui ?).

Parte 3) Utilizando o Azure AD DS (Azure Active Directory Domain Services), que fornece o serviço de domínio gerenciado, integrando com o Azure AD.

Para entender a migração deste cenário, vamos primeiro entender a arquitetura. Neste ambiente, temos:

1. Serviço do Azure Active Directory Domain Services habilitado.
2. Azure AD DS* integrado com o Azure AD.

*Criaremos um domínio gerenciado usando uma floresta de recursos. Somente as florestas de recursos podem criar relações de confiança com ambientes do AD DS locais. Além disso, precisaremos usar o SKU Enterprise para o domínio gerenciado, especificamente para a funcionalidade de relação de confiança entre o Azure AD DS e o AWS Managed Microsoft AD. Se necessário, altere o SKU de um domínio gerenciado. Preste atenção para usar NETBIOS e CIDRs diferentes para cada floresta.

Agora que já explicamos melhor nas partes 1 e 2 desta sequência de artigos a como migrar objetos, este cenário fica um pouco mais simples. As premissas são iguais (conectividade, relação de confiança e ADMT).

No nosso ambiente do Microsoft Azure, temos um Azure AD Domain Services chamado “empresa.corp”. Basta iniciarmos uma VM para este domínio gerenciado e instalar as ferramentas administrativas de Active Directory.

Acessando com um servidor membro do domínio, podemos listar os objetos do Azure AD DS:

Também podemos criar os conditional forwarders para o AWS Managed Microsoft AD:

Tendo as premissas de que já temos uma relação de confiança funcionando (incluindo o DNS conditional forwarder) entre as florestas empresa.corp e example.corp, podemos iniciar o processo de migração.

Para criarmos uma relação de confiança entre o Azure AD DS e o AWS Managed Microsoft AD, selecionamos a opção “Trusts” no Azure AD DS, e então “Add”.

Anote a senha cadastrada, iremos precisar dela. Caso você não tenha a opção de trusts, o seu Azure AD DS pode não estar com a versão Enterprise (requerido), ou não foi criado com a opção de floresta de recurso.

 No AWS Managed Microsoft AD, criamos uma relação de confiança do example.corp para o empresa.corp, com a mesma senha utilizada no passo anterior

Aqui, diferente da parte 2 do nosso artigo, a relação de confiança deverá ser “One-Way: incoming”:

Obs.: Os endereços IPs dos Domain Controllers do Azure AD DS podem ser localizados na aba de propriedades do serviço.

Após alguns minutos, conseguimos ver o status da relação de confiança de ambos os ambientes (AWS MAD e Azure AD DS):

Agora que temos a relação de confiança, iremos utilizar o ADMT (Active Directory Migration Tool) para a migração. Iremos aproveitar a mesma máquina da Parte 2, vide que ela está domain joined ao mesmo domínio example.corp e podemos migrar de diferentes florestas “source”.

No ADMT, selecionamos “User Account Migration Wizard”, adicionamos a Floresta do Azure AD DS (empresa.corp), e escolhemos a opção “Select users from domain”:

Selecionamos os objetos que serão migrados, juntamente com a opção de migrar os grupos que eles fazem parte. Na OU (Organizational Unit) de destino, selecionamos a OU customizada do AWS Managed Microsoft AD (LDAP://example.corp/OU=Users,OU=EXAMPLE,DC=example,DC=corp).

Como não possuímos acesso aos Domain Controllers do Azure AD DS e não temos privilégios de administrador de domínio no domínio gerenciado fornecido pelo Azure AD Domain Services, não podemos efetuar a instalação da ferramenta de Password Export Service (PES). Selecionamos a opção para criar senhas complexas.

Na página “Account Transition Options”, temos que decidir como lidar com a migração de objetos de usuário. Neste exemplo, estamos replicando o estado do domínio de origem. Migrar o histórico do SID é benéfico quando você está fazendo migrações longas e em etapas, nas quais os usuários podem precisar acessar recursos no domínio de origem e de destino antes que a migração seja concluída. Porém no momento, o AWS Managed Microsoft AD não oferece suporte à migração de SIDs de usuário.

Selecionamos a opção “Target same as source” e, em seguida, “Next”.

Selecione as opções para migrar os grupos associados aos usuários:

Não excluiremos as propriedades de objetos da migração:

É provável que você tenha mais etapas de migração, portanto, escolher como lidar com os objetos existentes é importante. Neste exemplo, executaremos a migração em uma única etapa, mas é um comportamento comum não migrar se o objeto já existir. Se estivermos executando várias etapas, é importante validar as opções que envolvem a fusão de objetos conflitantes. O método que você selecionar dependerá do seu caso de uso. Se você não sabe por onde começar, leia este artigo.

Podemos observar no progresso da migração que os objetos de usuários são migrados, juntamente com os grupos que eles fazem parte:

Filtrando o log, podemos ver a criação dos objetos e também a falha para a criação de grupos built-in, que é um comportamento esperado:

[Object Migration Section]

2021-04-06 20:59:04 Starting Account Replicator.

2021-04-06 20:59:09 CN=Billy             – Created

2021-04-06 20:59:13 WRN1:7873 Disabled the “user cannot change password” account option for account ‘CN=Billy’.

2021-04-06 20:59:13   CN=Billy             – Strong password generated.

2021-04-06 20:59:13 CN=Joao              – Created

2021-04-06 20:59:14 WRN1:7873 Disabled the “user cannot change password” account option for account ‘CN=Joao’.

2021-04-06 20:59:14   CN=Joao              – Strong password generated.

2021-04-06 20:59:15 CN=John Snow         – Created

2021-04-06 20:59:15 WRN1:7873 Disabled the “user cannot change password” account option for account ‘CN=John Snow’.

2021-04-06 20:59:15   CN=John Snow         – Strong password generated.

2021-04-06 20:59:16 CN=UserOne           – Created

2021-04-06 20:59:16   CN=UserOne           – Strong password generated.

2021-04-06 20:59:17 CN=UserTwo           – Created

2021-04-06 20:59:17   CN=UserTwo           – Strong password generated.

2021-04-06 20:59:19 CN=Desenvolvedores   – Created

2021-04-06 20:59:21 WRN1:7372 ADMT does not process BUILTIN accounts or change the membership of BUILTIN groups (Administrators, etc.). Skipping LDAP://empresa.corp/CN=Group Policy Creator Owners,CN=Users,DC=empresa,DC=corp

2021-04-06 20:59:21 Operation completed.

Agora no AWS Managed Microsoft AD, podemos listar os usuários e grupos migrados:

Agora, seguiremos os mesmos passos da Parte2) para a migração do objeto de computador “EMPRESASERVER” + domain unjoin e join na nova floresta.

Na ferramenta ADMT, vamos selecionar a opção de migração de computador. Com a premissa que o usuário executando a ferramenta é membro do grupo de administradores locais do servidor e possui acesso ao c$ (\\server\c$) e admin$ (\\server\admin$), iniciamos a migração.

Cenário 3: Azure Active Directory.

Adicionamos um “ponto” para enfatizar que existem clientes que utilizam a tecnologia de Azure Active Directory sem a gestão de objetos com um Active Directory e um Azure AD Connect e sem um Azure AD DS. Este cenário, embora não muito comum, pode ocorrer – geralmente, são empresas que “nasceram” na cloud e nunca possuíram uma necessidade de gestão para os Domain Controllers.

Neste modelo, existem duas opções:

a. Habilitar o Azure AD DS para integrar com o Azure AD e então seguir os passos deste post (recomendado).

b. Utilizar o CSVDE para a migração.

Nesta série de 3 blog posts, discutimos a migração de ambientes Microsoft Azure AD para o AWS Managed Microsoft AD. Clientes de grande porte com domínios de origem ou florestas complexas podem ter processos mais elaborados envolvidos para mapear usuários, grupos e computadores para a estrutura única de OU do AWS Managed Microsoft AD (por exemplo, migração de OUs em ondas de migração). Clientes com florestas de domínio único podem migrar em menos etapas. As opções que podemos selecionar no ADMT variam de acordo com o que queremos realizar.

Mostramos como migrar usuários e suas senhas, grupos e objetos de computador de um ambiente Microsoft Azure Active Directory para nosso Microsoft AD totalmente gerenciado pela AWS.

Criamos uma instância de gerenciamento na qual executamos o SQL Server Express e o ADMT, criamos um trust de floresta para conceder permissões a uma conta para usar no ADMT, a fim de mover usuários, e configuramos o ADMT em conjunto com a ferramenta PES. Em seguida, conduzimos a migração usando o ADMT. Esta ferramenta nos oferece uma ótima maneira de migrar para nosso serviço Microsoft AD gerenciado, que permite uma personalização poderosa da migração, de maneira mais segura por meio da sincronização de senha criptografada.

Sobre o autor

Caio Ribeiro Cesar atualmente trabalha como arquiteto de soluções especializadas em tecnologia da Microsoft na nuvem AWS. Ele iniciou sua carreira profissional como administrador de sistemas, que continuou por mais de 14 anos em áreas como Segurança da Informação, Identity Online e Plataformas de Email Corporativo. Recentemente, se tornou fã da computação em nuvem da AWS e auxilia os clientes a utilizar o poder da tecnologia da Microsoft na AWS.

Revisor

Bruno Lopes é Senior Technical Trainer na AWS Brasil.

Roberto Haramita é Senior Technical Account Manager na AWS Brasil.