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

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, vamos discutir como migrar do Azure Active Directory para o AWS Managed Microsoft AD, em diferentes cenários. Vamos 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 (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.

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.

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

a. Domain Controllers sendo executados em um ambiente on-premises (ou na nuvem). Estes Domain Controllers são o que chamamos de “Source of Authority”, ou “fontes de autoridade”. Eles possuem os dados de objetos (usuários, grupos, computadores) da organização.

b. Azure AD Connect como o método de provisionamento de objetos para o Azure Active Directory. Esta ferramenta irá sincronizar usuários, grupos, hashes de senha e contatos com o Azure AD.

c. Azure AD como o serviço em Nuvem de identidade.

Em outras palavras, os objetos estarão armazenados no Source of Authority que serão os DCs (Domain Controllers). O Azure AD Connect então: (1)importa estes objetos para uma base de dados própria (metaverse), (2)efetua o provisionamento destes objetos para o Azure AD, via uma tarefa de exportação.

Uma das abordagem de migração comum é a utilização do CSVDE.  Esta ferramenta não irá migrar atributos como senhas de usuário. Isso torna a migração difícil e exige esforço manual para grande parte da migração, o que pode causar desafios operacionais e de segurança ao migrar para um novo diretório.

Outra estratégia de migração seria efetuar a extensão do Source of Authority (DCs) para a AWS via a promoção de instâncias EC2 Windows como Domain Controllers (em diferentes zonas de disponibilidade). Isso de fato melhorará a resiliência da camada de autenticação na nuvem AWS, porém no cenário proposto, migraremos diretamente para o serviço gerenciado de Active Directory da AWS (AWS Managed Microsoft AD).

Para esta migração, utilizaremos o Active Directory Migration Tool (ADMT) juntamente com o Password Export Service (PES) para migrar os objetos do Active Directory para o AWS Managed Microsoft AD. Isso irá permitir a migração de objetos do AD (usuários, grupos, computadores) e também as senhas (hash de senhas) para que os usuários finais não sofram impacto na migração.

Para realizar a migração, utilizarei a conta de usuário administrador do meu Microsoft AD gerenciado pela AWS (admin). A AWS cria a conta do usuário administrador e delega permissões administrativas à conta para uma unidade organizacional (OU) no domínio AWS Managed Microsoft AD. Esta conta tem a maioria das permissões necessárias para gerenciar seu domínio e todas as permissões necessárias para concluir esta migração.

Neste exemplo, eu tenho um domínio de origem chamado example.source. Este ambiente está sendo executado no Microsoft Azure e irei migrar meus usuários, grupos e computadores para um domínio de destino no AWS Managed Microsoft AD.

Vamos iniciar com a criação do domínio de destino no AWS Managed Microsoft AD (example.corp). Navegue até a console AWS, selecione “Directory Service”, verifique se está na sessão de “Active Directory” e clique em “Set up directory”. Nesta tela, tenha certeza de ter selecionado “AWS Managed Microsoft AD” e clique em “Next”.

Neste próximo passo, selecione se você deseja a versão Standard ou Enterprise e adicione as informações do seu AWS Managed Microsoft AD. No nosso exemplo, o domínio se chamará example.corp, lembre-se de definir e anotar a senha do usuário “admin” que será criado:

Por fim, selecione a VPC criada na parte 1 dessa série, “Conectividade”

Na última tela, revise as informações e clique em “create directory”. Ao término, você deverá visualizar seu AWS Managed Microsoft AD com o status “active” conforme abaixo:

Para migrar usuários do Azure para a AWS, precisaremos de um host de migração que seja membro do domínio do Azure example.source, no qual executaremos o ADMT. Nas imagens abaixo, temos dois usuários (joao e c4iocesar) na floresta example.source, membros de um grupo (Grupo1) e uma conta de computador “server1”.

Passo 1) Relação de confiança (Trust Relationship)

Para migrar usuários, grupos, objetos de computadores e senhas do domínio de origem que está no Azure para o AWS Managed Microsoft AD, precisamos de um trust de floresta bidirecional (relação de confiança). A confiança do domínio de origem para o AWS Managed Microsoft AD nos permite que a conta de administrador do AWS Managed Microsoft AD seja adicionada ao domínio de origem.

Isso é necessário para que possamos conceder permissões de conta de administrador do Microsoft AD gerenciado pela AWS no diretório de origem do Azure AD a fim de que ele possa ler os atributos para a migração. Seguindo os passos deste guia, criamos a relação de confiança.

Nos Domain Controllers (SoA) do ambiente Azure, criamos um Conditional Forwarder com o FQDN e IPs do AWS Managed Microsoft AD:

Após a criação do Conditional Forwarder, em um computador que seja membro do domínio de origem, execute um simples teste de nslookup para confirmar que a resolução de nomes entre os domínios está funcionando:

Ainda no ambiente Azure, acesse o Active Directory Domains and Trusts e crie uma solicitação de relação de confiança do ambiente de origem (example.source) para o AWS Managed Microsoft AD (example.corp).

Para fazer isso, clique no seu domínio de origem e selecione propriedades:

Selecione então a aba “Trusts” e clique em “New Trust”:

Isso irá abrir o assistente de configuração de relação de confiança “New Trust Wizard”. Na primeira interface, basta clicar em “Next”:

Adicione o NetBIOS do domínio de destino e clique em “Next”:

Selecione a opção de “Forest Trust” e clique em “Next”:

Informe que será uma relação bidirecional “two-way” e clique em “Next”:

Selecione a opção de “Apenas neste domínio” e clique em “Next”:

Escolha a opção de “Forest-wide authentication”. Isso permitirá a autenticação do nosso usuário “admin” do AWS Managed Microsoft AD no domínio de origem. Clique em “Next”:

Cadastre uma senha para a sua relação de confiança e clique em “Next”:

Após isso, você deverá visualizar uma tela de sucesso na criação da relação de confiança. Agora, basta clicar em “Finish”:

Agora, na console AWS, no AWS Managed Microsoft AD, selecione a opção de “Add trust relationship”. Assim como foi feito no Azure, selecione a opção de “Forest trust” e preencha com o domínio de origem e a senha cadastrada:

Selecione a opção de relação bidirectional “Two-Way” e no campo de “Conditional forwarder” informe o IP local do controlador de domínio do Microsoft Azure. Explicaremos o motivo no próximo passo. Clique em “Add”:

Isso criará a relação de confiança que será exibida em sua tela, conforme abaixo:

Esta etapa já efetua a criação de um conditional forwarder. Você pode confirmar ao abrir a ferramenta de DNS e validar os IP’s do AWS Managed Microsoft AD:

Após alguns minutos, o status da relação de confiança deve ser atualizado para “Verified”:

Agora que temos uma relação de confiança, vamos até o grupo built-in de Administrators da floresta no Azure (example.source) e adicionamos o usuário admin do AWS Managed Microsoft AD:

Passo 2) Instalando o ADMT

A ferramenta ADMT deve ser instalada em um computador que não seja um controlador de domínio no domínio de destino (example.corp). Para isso, criaremos uma nova instância EC2 na mesma VPC onde está o controlador de domínio, e a adicionarei ao domínio example.corp (manualmente ou com o Seamless Domain Join, na etapa de launch instance).

Como pré-requisito para o ADMT, precisamos instalar o Microsoft SQL Express 2016 neste servidor. Faremos o download da versão 2016 Express SP2 e instalaremos no computador que irá executar o ADMT.

Agora que já tenho o SQL Server Express instalado, faremos o download do ADMT v3.2 e instalaremos esta ferramenta. Para mais informações de suporte deste, clique aqui ou baixe a documentação completa aqui.

Na configuração do ADMT, adicionamos as informações de conexão para o SQL Server 2016 e criamos uma nova ADMT database:

Passo 3) Configurando o ADMT e o PES

Utilizaremos o PES (Password Export Service) para a migração de senhas. Mas antes de configurar isto, precisamos criar uma chave de criptografia que será usada durante este processo para criptografar a migração das senhas.

Na instância EC2 onde instalamos o ADMT, usaremos o Prompt de Comando elevado (admin) e o seguinte comando para criar a chave de criptografia:

admt key /option:create /sourcedomain:<SourceDomain> /keyfile:<KeyFilePath>
/keypassword:{<password>|*}

Por exemplo, o comando no nosso ambiente ficaria assim:

admt key /option:create /sourcedomain:example.source /keyfile:c:\
 /keypassword:password123

Agora, vamos baixar e instalar o PES no Domain Controller do ambiente de origem (example.source). Também utilizaremos o arquivo “.pes” que acabamos de criar da máquina que executa o ADMT.

Adicionamos a senha que foi utilizada na geração do arquivo “.pes” e instalamos o PES:

Após a reinicialização do Domain Controller, navegamos até o Services.msc (podemos usar o atalho do Run, com o conjunto de teclas Windows + R) e alteramos o serviço do PES para “Automatic”, para evitar que uma reinicialização futura do DC faça com que o serviço de PES fique com o status “Stopped”.

Agora de volta ao ADMT (EC2), vamos abrir a ferramenta de migração em “Control Panel > System and Security > Administrative Tools > Active Directory Migration Tool”:

Passo 4) Migrando Objetos usando o ADMT

Agora podemos migrar Usuários, Grupos, Service Accounts e Computer Accounts. Clicamos com o botão direito em “Active Directory Migration Tool” e selecionamos “User Account Migration Wizard”

Na opção seguinte, selecionamos a opção “Select users from domain”:

Na OU (Organizational Unit) de destino, seleciono a OU do meu AWS Managed Microsoft AD:

LDAP://example.corp/OU=Users,OU=EXAMPLE,DC=example,DC=corp

Na opção seguinte, selecionamos “Migrate passwords”, que irá conectar com o PES que está em execução no Domain Controller do ambiente de origem.

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 vamos excluir 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.

Após isso, será a exibida a tela de resumo das opções que você selecionou. Basta clicar em “Finish” para iniciar a migração:

Como podemos ver, tivemos um usuário migrado (joao) e um grupo (grupo1). O usuário c4iocesar não foi migrado propositalmente, pois já existia na floresta de destino.

Validando no AWS Managed Microsoft AD:

Agora, vamos renomear o usuário c4iocesar da floresta example.source e executar um novo batch de migração:

Neste novo batch, apenas o objeto c4iocesar2 deverá ser migrado. É importante também ressaltar que usuários nativos (“built-in”) não serão migrados. O arquivo de log pode ser localizado em “C:\Windows\ADMT\Logs” e contém informações importantes da tarefa de migração.

[Object Migration Section]

2021-04-05 19:38:30 Starting Account Replicator.

2021-04-05 19:38:33 CN=c4iocesar2        – Created

2021-04-05 19:38:34   CN=c4iocesar2        – Password Copied.

2021-04-05 19:38:34 WRN1:7874 Disabled the “password never expires” account option for account ‘CN=c4iocesar2’.

2021-04-05 19:38:35 Operation completed.

Agora vamos realizar um logon com o usuário c4iocesar2 ou joao, utilizando a mesma senha que ele possuía no ambiente example.source (só que agora em sua nova residência, example.corp ?):

Lembrando que estamos falando de uma operação de migração/cópia, então os objetos source não serão “eliminados” do ambiente de origem.

Agora, vamos migrar objetos de computador. Abra novamente o ADMT e selecione a opção “Computer Migration Wizard”:

Selecionamos a OU correta, tendo em vista que no AWS Managed Microsoft AD não temos acesso ao “Computers built-in” (nativo), mas sim um “Computers” de dentro da nossa organização gerenciada:

LDAP://example.corp/OU=Computers,OU=EXAMPLE,DC=example,DC=corp

Assim como na migração dos usuários, é importante selecionar as opções desejadas de acordo com seu caso de uso.

Registros do log do ADMT:

Computer Migration

General Settings

Logfile: c:\Windows\ADMT\Logs\Migration.log

Account Migration

1 objects are selected for migration.

Objects of the following classes will be copied:

     Computer accounts

The source object will not be migrated if a conflict is detected in the target domain.

New target accounts will be enabled or disabled to match source accounts’ state.

Translate objects from example.source and listed in the migrated object table.

Antes de iniciar o batch, faremos um login no servidor de origem e coletaremos informações como o hostname, confirmando que este servidor é membro do domínio example.source.

Iniciaremos a migração e após alguns segundos já poderemos constatar:

[Object Migration Section]

2021-04-05 19:58:44 Starting Account Replicator.

2021-04-05 19:58:47 CN=SERVER1           – Created

2021-04-05 19:58:47      – Set password for CN=SERVER1.

2021-04-05 19:58:47 Operation completed.

Ao clicar em “Close”, uma nova janela será aberta. Agora acompanharemos o log de migração, pois para computadores, o agente do ADMT será instalado no servidor e irá efetuar um domain unjoin do example.source e um join no example.corp.

Podemos selecionar a opção “View Migration Log” e acompanhar o status das ações do agente ADMT.

[Agent Dispatch Section]

2021-04-05 19:59:28 Installing agent on 1 servers

2021-04-05 19:59:28 The Active Directory Migration Tool Agent will be installed on server1.example.source

Caso o agente responda com um erro de acesso negado, isso significa que o usuário admin não possui acesso ao C$ ou Admin$:

2021-04-05 20:01:47 ERR2:7006 Failed to install agent on \\server1.example.source, rc=5   Access is denied.

2021-04-05 20:01:47 ERR2:7674 Unable to determine the local path for ADMIN share on the machine ‘server1.example.source’.  rc=-2147024891

Para reiniciarmos a etapa de pre-check e migração, basta selecionar a opção “run pre-check and agent operation”:

2021-04-05 20:06:47 Started job:  server1.example.source 000007_SERVER1 {1707F5A0-A76C-47D8-A0F8-AC8808183CB8}

Assim que o “post-check” estiver com “Waiting for Reboot”, podemos efetuar um novo login no server1 e confirmar que nas opções de domínio, o servidor já está no example.corp:

Para finalizar a tarefa, efetuaremos uma reinicialização do Sistema Operacional. Agora efetuaremos um novo login, com o usuário admin do AWS Managed Microsoft AD (example.corp):

Observação: caso a sua organização utilize o Office 365, este serviço irá depender do Azure AD para autenticação. Você ainda pode efetuar uma migração para o AWS Managed Microsoft AD, porém neste modelo seria apenas a troca do seu Source of Authority (SoA, Domain Controllers) para o AWS Managed Microsoft AD, ficando: AWS Managed Microsoft AD (SoA) -> Azure AD Connect -> Azure AD.

No próximo post, vamos finalizar os cenários possíveis de migração com a última parte: 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 acessar a parte 3, clique aqui

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.