Migración de Azure Active Directory a Microsoft AD administrado por AWS – Parte 2

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

AWS Directory Service le permite ejecutar Microsoft Active Directory (AD) como un servicio administrado. AWS Directory Service para Microsoft Active Directory, también conocido como AWS Managed Microsoft AD, está habilitado por Windows Server 2012 R2. Cuando selecciona e inicia este tipo de directorio, se crea como un par de controladores de dominio de alta disponibilidad conectados a la nube privada virtual (VPC). Los controladores de dominio se ejecutan en diferentes zonas de disponibilidad en una región de su elección y tienen funcionalidad de varias regiones . AWS configura y administra automáticamente la supervisión y recuperación del host, la replicación de datos, las instantáneas y las actualizaciones de software.

En esta publicación de blog, discutiremos cómo migrar de Azure Active Directory a AWS Managed Microsoft AD en diferentes escenarios. Separemos los mensajes en 3 partes:

• Parte 1) Conectividad.
• Parte 2) Uso de Azure Active Directory (AD) cuando el entorno se integra con un servicio de dominio de Active Directory (AD) y la herramienta Azure AD Connect (está aquí ?).
• Parte 3) Uso de Azure Active Directory Domain Services (AD DS), que proporciona el servicio de dominio administrado, integrándose con Azure AD.

Parte 2) Uso de Azure Active Directory (AD) cuando su entorno se integra con una herramienta de Servicios de dominio de Active Directory (AD) y Azure AD Connect.

Para entender la migración de este escenario, primero tenemos que entender la arquitectura. En este entorno, tenemos:

a. Controladores de dominio que se ejecutan en un entorno local (o en la nube). Estos Controladores de Dominio son lo que llamamos “Source of Authority”, o “fuentes de autoridad”. Tienen los datos de objetos (usuarios, grupos, equipos) en la organización.

b. Azure AD Connect como método de aprovisionamiento de objetos para Azure Active Directory. Esta herramienta sincronizará usuarios, grupos, hashes de contraseña y contactos con Azure AD.

c. Azure AD como el servicio Identity Cloud.

En otras palabras, los objetos se almacenarán en el “Source of Authority”, que serán los Controladores de dominio (DC). A continuación, Azure AD Connect: (1) importa estos objetos en su propia base de datos (metaverse), (2) aprovisionar estos objetos a Azure AD a través de una tarea de exportación.

Uno de los enfoques comunes de migración es el uso de CSVDE.  Esta herramienta no migrará atributos como contraseñas de usuario. Esto dificulta la migración y requiere esfuerzo manual para gran parte de la migración, lo que puede causar desafíos operativos y de seguridad al migrar a un nuevo directorio.

Otra estrategia de migración sería extender el Source of Authority (DCs) a AWS promoviendo instancias de Windows EC2 como controladores de dominio (en diferentes zonas de disponibilidad). De hecho, esto mejorará la resistencia de la capa de autenticación en la nube de AWS, pero en el escenario propuesto, migraremos directamente al servicio Active Directory de Microsoft AD administrado por AWS (AWS Managed Microsoft AD).

Para esta migración, utilizaremos Active Directory Migration Tool (ADMT) junto con Password Export Service (PES) para migrar objetos de Active Directory a AWS Managed Microsoft AD. Esto permitirá la migración de objetos AD (usuarios, grupos, equipos) y también contraseñas (hash de contraseña) para que los usuarios finales no tengan un impacto en la migración.

Para realizar la migración, utilizaré la cuenta de usuario administrador de mi AWS Microsoft AD administrado por AWS (admin). AWS crea la cuenta de usuario administrador y delega los permisos administrativos a la cuenta en una unidad organizacional (OU) del dominio AWS Managed Microsoft AD. Esta cuenta tiene la mayoría de los permisos necesarios para administrar su dominio y todos los permisos necesarios para completar esta migración.

En este ejemplo, tengo un dominio de origen llamado example.source.  Este ambiente se ejecuta en Microsoft Azure y migraré mis usuarios, grupos y equipos a un dominio de destino en AWS Managed Microsoft AD.

Comencemos a crear el dominio de destino en AWS Managed Microsoft AD (example.corp). Vaya a la consola de AWS, seleccione “Directory Service”, compruebe que está en la sesión “Active Directory” y haga clic en “Configurar directorio”. En esta pantalla, asegúrese de haber seleccionado “AWS Managed Microsoft AD” y haga clic en “Next”.

En este proximo paso, seleccione si desea la versión Standard o Enterprise y agregue la información de AWS Managed Microsoft AD. En nuestro ejemplo, el dominio se llamará example.corp, recuerde establecer y escribir la contraseña del usuario “admin” que se creará:

Por último, seleccione la VPC creada en la Parte 1 de esta serie, “Conectividad”

En la última pantalla, revise la información y haga clic en “create directory”. Una vez finalizado, debe ver su AWS Managed Microsoft AD con el estado “Active” como se indica a continuación:

Para migrar usuarios de Azure a AWS, necesitaremos un host de migración que sea miembro del dominio Azure example.source en el que ejecutaremos ADMT. En las imágenes de abajo, tenemos dos usuarios (joao y c4iocesar) en el forest example.source, miembros de un grupo (Group1) y una cuenta de equipo “server1”.

Paso 1) Relación de confianza

Para migrar usuarios, grupos, objetos de equipo y contraseñas del dominio de origen que se encuentra en Azure a Microsoft AD administrado por AWS, necesitamos un Two-way tust forest (Trust).  La relacion de confianza del dominio de origen para AWS Managed Microsoft AD nos permite agregar la cuenta de administrador de AWS Managed Microsoft AD que se agregará al dominio de origen.

Esto es necesario para que podamos conceder permisos de cuenta de administrador de Microsoft AD administrados por AWS en el directorio de origen de Azure AD para que pueda leer los atributos de la migración. Siguiendo los pasos de esta guía, creamos la relación de confianza.

En los Domain Controllers (SoA) de Azure, creamos un Conditional Forwarder con el FQDN y las IPs administradas por AWS de Microsoft AD:

Después de crear el Conditional Forwarder, en un equipo que sea miembro del dominio de origen, realice una prueba simple de nslookup para confirmar que la resolución de nombres entre dominios funciona:

Aún en el entorno de Azure, vaya a Active Directory Domains and Trusts y cree una solicitud de relacion de confianza desde el entorno de origen ( example.source ) para AWS Managed Microsoft AD ( example.corp ).

Para hacer esto, haga clic en su dominio de origen y seleccione propiedades:

Luego seleccione la pestaña “Tusts” y haga clic en “New Trust”:

Esto abrirá el asistente de configuración de confianza “New Trust Wizard”. En la primera interfaz, simplemente haga clic en “Next”:

Agregue NetBIOS desde el dominio de destino y haga clic en “Next”:

Seleccione la opción “Forest Trust” y haga clic en “Next”:

Informar que será una relación “Two-way” y haga clic en “Next”:

Seleccione la opción “This domain only” y haga clic en “Next”:

Elija la opción de “Forest-wide-authentication. Esto permitirá la autenticación de nuestro usuario “admin” de Microsoft AD administrado por AWS en el dominio de origen. Haga clic en “Next”:

Registre una contraseña para su confianza y haga clic en “Next”:

Después de esto, debería ver una pantalla de éxito en la creación de la confianza. Ahora simplemente haga clic en “Finish”:

Ahora, en la consola de AWS, en AWS Managed Microsoft AD, seleccione la opción “Add a trust relationship”. Al igual que lo hizo en Azure, seleccione la opción “Forest trust” y rellene con su dominio de origen y contraseña en el archivo:

Seleccione la opción de relación bidireccional “Two-Way” y en el campo “Conditional Forwarder” ingrese la IP local del controlador de dominio de Microsoft Azure. Explicaremos la razón en el siguiente paso. Haga clic en “Add”:

Esto creará la confianza que se mostrará en su pantalla, de la siguiente manera:

Este paso ya realiza la creación de un Conditional Forwarder. Puede confirmar abriendo la herramienta DNS y validando las IPs administradas por AWS de Microsoft AD:

Después de unos minutos, el estado de la relación de confianza debe actualizarse a “Verified”:

Ahora que tenemos una confianza, vamos al grupo de administradores de bosque integrado en Azure (ejemplo.source) y agreguemos el usuario administrador de AWS Managed Microsoft AD:

Paso 2) Instalación de ADMT

La herramienta ADMT debe instalarse en un equipo que no sea un controlador de dominio en el dominio de destino (example.corp). Para ello, crearemos una nueva instancia EC2 en la misma VPC donde está el controlador de dominio, y la agregaremos al dominio.corp example.corp (ya sea manualmente o con Seamless Domain Join en el paso de  Lunch instance).

Como requisito previo para ADMT, necesitamos instalar Microsoft SQL Express 2016 en este servidor. Descargaremos la versión 2016 Express SP2 e instalaremos en el equipo que ejecutará ADMT.

Ahora que tengo instalado SQL Server Express , descargaremos ADMT v3.2 e instalaremos esta herramienta. Para obtener más información de soporte al respecto, haga clic aquí o descargue la documentación completa aquí.

En la configuración de ADMT, agregamos la información de conexión para SQL Server 2016 y creamos una nueva base de datos ADMT:

Paso 3) Configuración de ADMT y PES

Utilizaremos el Password Export Service (PES) para la migración de contraseñas. Pero antes de configurar esto, necesitamos crear una clave de cifrado que se usará durante este proceso para cifrar la migración de contraseñas.

En la instancia EC2 donde instalamos ADMT, utilizaremos la linea de comandos con privilegios (admin) y el siguiente comando para crear la clave de cifrado:

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

Por ejemplo, el comando en nuestro ambiente se vería así:

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

Ahora, descargamos e instalemos PES en el controlador de dominio del ambiente de origen (example.source). También utilizaremos el archivo “.pes” que acabamos de crear desde la máquina que ejecuta ADMT.

Se agregó la contraseña que se utilizó para generar el archivo “.pes” e instalamos el PES:

Después de reiniciar el controlador de dominio, navegamos a services.msc (podemos usar el acceso directo Run, con el conjunto de teclas Windows + R) y cambiar el servicio PES a “Automatic”,  para evitar que un reinicio futuro del DC haga que el PES obtenga el estado “Stopped”.

Ahora de vuelta a ADMT (EC2), vamos a abrir la herramienta de migración en Control Panel > System and Security > Administrative Tools > Active Directory Migration Tool”:

Paso 4) Migración de objetos mediante ADMT

Ahora podemos migrar Usuarios, Grupos, Cuentas de Servicio y Cuentas de Equipo. Haga clic derecho en “Active Directory Migration Tool” y selecionamos “User Account Migration Wizard”.

En la siguiente opción, seleccionamos la opción “ Select users from domain”:

Em la OU (Organizational Unit) de destino, seleciono sa OU de mi AWS Managed Microsoft AD:

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

En la siguiente opción, seleccionamos “Migrate passwords”, que se conectará con el PES que se ejecuta en el controlador de dominio del entorno de origen.

En la página “Account Transition Options”, tenemos que decidir cómo manejar la migración de objetos de usuario. En este ejemplo, estamos replicando el estado del dominio de origen. Migrar el historial de SID resulta beneficioso cuando se realizan migraciones largas y paso a paso en las que los usuarios pueden necesitar acceder a recursos en el dominio de origen y destino antes de que finalice la migración. Sin embargo, en este momento, AWS Managed Microsoft AD no admite la migración de SID de usuario.

Seleccionamos la opción “Target same as source” y luego “Next”.

Seleccione opciones para migrar grupos asociados a usuarios:

No eliminemos las propiedades del objeto de la migración:

Es probable que tenga más pasos de migración, por lo que es importante elegir cómo manejar los objetos existentes. En este ejemplo, realizaremos la migración en un solo paso; pero es un comportamiento común no migrar si el objeto ya existe. Si estamos realizando varios pasos, es importante validar las opciones que implican la fusión de objetos en conflicto. El método que seleccione dependerá de su caso de uso. Si no sabe por dónde comenzar, lea este artículo.

Después de eso, se mostrará la pantalla de resumen de las opciones seleccionadas. Simplemente haga clic en “Finish” para iniciar la migración:

Como podemos ver, teníamos un usuario migrado (joao) y un grupo (group1). El usuario c4iocesar no se migró intencionalmente, ya que ya existía en el forest de destino.

Validación en AWS Managed Microsoft AD:

Ahora, vamos a cambiar el nombre del usuario c4iocesar desde el bosque example.source y ejecutar un nuevo batch de migración:

En este nuevo batch, solo se debe migrar el objeto c4iocesar2. También es importante tener en cuenta que los usuarios nativos (“built-in”) no se migrarán. El archivo de registro se puede ubicar en “C:\Windows\ADMT\Logs” y contiene información importante de la tarea de migración.

[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.

Ahora iniciemos sesión con el usuario c4iocesar2 o joao, usando la misma contraseña que tenía en el ambiente example.source (solo ahora en su nueva residencia, example.corp):

Recordando que estamos hablando de una operación de migración/copia, entonces los objetos de origen no seran “eliminados” del entorno de origen.

Ahora, vamos a migrar objetos de computadora. Vuelva a abrir ADMT y seleccione la opción “Computer Migration Wizard”:

Seleccionamos la OU correcta, ya que en AWS Managed Microsoft AD no tenemos acceso a equipos “Computers built-in” , sino a “Computers” de nuestra organización gestionada:

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

Al igual que con la migración de usuarios, es importante seleccionar las opciones deseadas de acuerdo con su caso de uso.

Registros de registro de 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 el batch, iniciaremos sesión en el servidor de origen y recopilaremos información como el nombre de host, confirmando que este servidor es miembro del dominio example.source.

Comenzaremos la migración y después de unos segundos podremos ver:

[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.

Al hacer clic en “Close” se abrirá una nueva ventana. Ahora realizaremos un seguimiento del registro de migración porque para los equipos, el agente de ADMT se instalará en el servidor y realizará un domain unjoin del example.source y un join en el example.corp.

Podemos seleccionar la opción “View Migration Log”  y realizar un seguimiento del estado de las acciones del agente de 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 reiniciar el paso de pre-check y migración, simplemente seleccione la opción “run pre-check and agent operation”:

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

Una vez que “post-check” este como “Waiting for Reboot”, podemos volver a iniciar sesión en servidor1 y confirmar que en las opciones de dominio, el servidor ya está en example.corp :

Para finalizar la tarea, realizaremos un reinicio del sistema operativo. Ahora iniciaremos sesión de nuevo com el usuário admin del AWS Managed AD (example.corp):

Nota: Si su organización utiliza Office 365, este servicio dependerá de Azure AD para la autenticación.  Todavía puede pensar en una migración a AWS Managed Microsoft AD, pero en este modelo sólo sería un cambio de su Source of Authority (SoA, Domain Controllers) para el AWS Managed Microsoft AD, quedando: AWS Managed Microsoft AD (SoA) -> Azure AD Connect -> Azure AD..

En el siguiente post, finalizaremos los posibles escenarios de migración con la última parte: Uso de Azure Active Directory Domain Services (AD DS), que proporciona el servicio de dominio administrado, integrándose con Azure AD.

Para acceder a la parte 3, haga clic aquí

Este artículo fue traducido del Blog de AWS en Portugués

Sobre el autor

Caio Ribeiro Cesar es Arquitecto de Soluciones Especialista en Microsoft en AWS Brasil.

Revisor

Daniel Maldonado es Arquitecto de Soluciones en AWS México.