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

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. Separaremos los mensajes en 3 partes:

• Parte 1) Conectividad.
• Parte 2) Uso de Azure Active Directory (AD) cuando el entorno se integra con los Servicios de dominio de Active Directory (AD) y la herramienta Azure AD Connect.
• Parte 3) Uso de los Servicios de dominio de Azure Active Directory (AD DS), que proporciona el servicio de dominio administrado, integrándose con Azure AD (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.

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

a. Servicio de dominio de Azure Active Directory habilitado.

b. Azure AD DS* integrado con Azure AD.

*Crearemos un dominio administrado utilizando un bosquede recursos.  Sólo los bosques de recursos pueden crear confianzas con entornos de AD DS locales.  Además, tendremos que utilizar el SKU empresarial para el dominio administrado, específicamente para la funcionalidad de confianza entre Azure AD DS y AWS Managed Microsoft AD.  Si es necesario, cambia el SKU de un dominio gestionado.  Preste atención al uso dediferentes NETBIOS y CIDRs para cada bosque.

Ahora que hemos explicado mejor en las partes 1 y 2 de esta secuencia de artículos a cómo migrar objetos, este escenario se vuelve un poco más simple. Los supuestos son los mismos (conectividad, confianza y ADMT).

En nuestro entorno de Microsoft Azure, tenemos un servicio de dominio de Azure AD denominado “empresa.corp”. Simplemente inicie una máquina virtual para este dominio administrado e instale las herramientas administrativas de Active Directory.

Al acceder con un servidor miembro de dominio, podemos enumerar los objetos de Azure AD DS:

También podemos crear los conditional forwarders para el AWS Managed Microsoft AD:

Teniendo en cuenta que ya tenemos una relación de confianza de trabajo (incluido el reenviador condicional DNS) entre los bosques empresa.corp y example.corp , podemos iniciar el proceso de migración.

Para crear una relación de confianza entre Azure AD DS y AWS Managed Microsoft AD, seleccionamos la opción “Trusts” en Azure AD DS y, a continuación, “Add”.

DS no esté ejecutando la versión Enterprise (necesaria) o que no se haya creado con la opción de bosque de recursos.

 En AWS Managed Microsoft AD, creamos una confianza example.corp para empresa.corp, con la misma contraseña utilizada en el paso anterior:

Aquí, a diferencia de la parte 2 de nuestro artículo, la relación de confianza debe ser “One-Way: incoming”:

Obs. : Las direcciones IP de los controladores de dominio de Azure AD DS se pueden encontrar en la ficha de propiedades del servicio.

Después de unos minutos, pudimos ver el estado de confianza de ambos entornos (AWS MAD y Azure AD DS):

Ahora que tenemos la relación de confianza, utilizaremos la Herramienta de migración de Active Directory (ADMT) para la migración. Aprovecharemos la misma máquina que la Parte 2, veremos que es un dominio unido al mismo dominio example.corp y podemos migrar desde diferentes bosques de “Source”.

En ADMT, seleccionamos “User Account Migration Wizard”, agregamos Azure AD DS Forest (empresa.corp) y elegimos la opción “Select users from domain”:

Seleccionamos los objetos que se van a migrar, junto con la opción de migrar los grupos de los que forman parte. En la OU (Organizational Unit) de destino, seleccionamos la unidad organizacional personalizada de AWS Managed AD de Microsoft (LDAP://example.corp/OU=Users,OU=EXAMPLE,DC=example,DC=corp).

Dado que no tenemos acceso a los controladores de dominio de Azure AD DS y no tenemos privilegios de administrador de dominio en el dominio administrado proporcionado por Azure AD Domain Services, no podemos instalar la herramienta Password Export Service (PES). Seleccionamos la opción para crear contraseñas complejas.

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. Pero 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 eliminaremos 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.

Podemos ver en el progreso de la migración que los objetos de usuario se migran, junto con los grupos de los que forman parte:

Al filtrar el registro, podemos ver la creación de los objetos y también el error en la creación de grupos integrados, que es un comportamiento 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.

Ahora, en AWS Managed Microsoft AD, podemos enumerar los usuarios y grupos migrados:

Ahora vamos a seguir los mismos pasos que Part2) para migrar el objeto de equipo “EMPRESASERVER” + domain unjoin y join en el nuevo bosque.

En la herramienta ADMT, seleccionaremos la opción de migración de computadora. Con la premisa de que el usuario que ejecuta la herramienta es miembro del grupo local de administradores del servidor y tiene acceso a c$ (\\server\c$) e admin$ (\\server\admin$), iniciamos la migración.

Escenario 3: Azure Active Directory.

Agregamos un “punto” para enfatizar que hay clientes que usan la tecnología Azure Active Directory sin administrar objetos con Active Directory y Azure AD Connect y sin Azure AD DS. Este escenario, aunque no es muy común, puede ocurrir – por lo general son empresas que “nacieron” en la nube y nunca han tenido una necesidad de gestión de controladores de dominio.

En este modelo, hay dos opciones:

a. Habilite Azure AD DS para que se integre con Azure AD y, a continuación, siga los pasos de esta publicación (recomendado).

b. Utilice CSVDE para la migración.

En esta serie de 3 entradas de blog, analizamos la migración de entornos de Microsoft Azure AD a Microsoft AD administrado por AWS. Los clientes grandes con dominios de origen o bosques complejos pueden tener procesos más elaborados implicados para asignar usuarios, grupos y equipos al único marco de OU de Microsoft AD administrado por AWS (por ejemplo, migrar unidades organizativas en ondas de migración). Los clientes con bosques de dominio único pueden migrar en menos pasos. Las opciones que podemos seleccionar en ADMT varían en función de lo que queremos lograr.

Le mostramos cómo migrar usuarios y sus contraseñas, grupos y objetos informáticos desde un entorno de Microsoft Azure Active Directory a nuestro AD de Microsoft totalmente gestionado por AWS.

Creamos una instancia de administración donde ejecutamos SQL Server Express y ADMT, creamos un Trust de bosque para conceder permisos a una cuenta para usarla en ADMT con el fin de mover usuarios y configurar ADMT junto con la herramienta PES. A continuación, realizamos la migración usando ADMT. Esta herramienta nos ofrece una excelente manera de migrar a nuestro servicio administrado de Microsoft AD, que permite una poderosa personalización de la migración de una manera más segura a través de la sincronización de contraseñas cifradas

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.