Blog de Amazon Web Services (AWS)

Cómo conectar su Active Directory On-Premises con AWS utilizando AD Connector

Por Jeremy Cowan, Bright Dike, David Selberg y Abhra Sinha
El AD Connector fue diseñado para proporcionar una forma sencilla de establecer una relación de confianza entre Active Directory y AWS. Cuando el AD Connector está configurado, es posible:

  • Iniciar sesión en aplicaciones de AWS como Amazon WorkSpaces, Amazon WorkDocs y Amazon WorkMail, con sus credenciales de Active Directory.
  • Unir fácilmente instancias de Windows a su dominio de Active Directory mediante el Amazon EC2 Launch Wizard o programáticamente mediante la API de EC2 Simple System Manager (SSM).
  • Proporcionar un inicio de sesión federado en la consola de administración de AWS mapeando identidades de Active Directory a los roles (funciones) de AWS Identity and Access Management (IAM).

AD Connector no se puede usar con sus aplicaciones customizadas, ya que solo es usado para la integración segura de AWS para los tres casos de uso mencionados anteriormente. Las aplicaciones customizadas que dependen del Active Directory on-premises deben comunicarse directamente con los controladores de dominio.

Con AD Connector, puede simplificar la administración de identidades extendiendo las identidades de usuario desde Active Directory. También le permite reutilizar las políticas de seguridad de Active Directory existentes, como la de caducidad de contraseñas, historial de contraseñas y bloqueo de cuentas. Además, tus usuarios ya no tendrán que recordar otra combinación de nombre de usuario y contraseña. Y, dado que AD Connector no depende de tecnologías complejas de sincronización de directorios o Active Directory Federation Services (AD FS), puede evitar el costo y la complejidad adicional de alojar una infraestructura de federación basada en SAML. En resumen, AD Connector ayuda a promover un entorno híbrido, permitiéndole aprovechar sus inversiones on-premises existentes para controlar diferentes aspectos de AWS.

En este post se mostrará cómo funciona AD Connector además de explicar cómo habilitar el acceso federado a la consola, asignar usuarios a roles y unir fácilmente una instancia de EC2 a un dominio de Active Directory.

AD Connector – Detrás de escena  

AD Connector es un servicio proxy de zona de doble disponibilidad que conecta las aplicaciones de AWS a su directorio on-premises. AD Connector reenvía las solicitudes de inicio de sesión a los controladores de dominio de Active Directory para su autenticación y permite a las aplicaciones consultar datos en el directorio. Al configurar AD Connector, le proporciona las credenciales de la cuenta de servicio que AWS almacena de forma segura. AWS utiliza esta cuenta para habilitar la funcionalidad de unir al dominio, single sign-on (SSO) y las aplicaciones de AWS (WorkSpaces, WorkDocs y WorkMail). Como AD Connector funciona como proxy, no almacena localmente ni en caché las credenciales de usuario. En cambio, todas las solicitudes de autenticación, búsqueda y administración son gestionadas por su Active Directory.

Para crear un conector AD, también debe proporcionar un par de direcciones IP DNS durante la configuración. AD Connector las utiliza para recuperar registros de servicios DNS (SRV) para localizar los controladores de dominio más cercanos a los cuales dirigir las solicitudes. Las instancias de proxy de AD Connector utilizan un algoritmo similar al locator process de los controladores de dominio de Active Directory para decidir a qué controladores de dominio conectarse para las solicitudes de LDAP y Kerberos.

Para la autenticación en las aplicaciones de AWS y en la consola de AWS, puede configurar una URL de acceso en la consola de AWS Directory Service. Esta URL de acceso tiene el formato https://<alias>.awsapps.com y proporciona una página de inicio de sesión de acceso público. Puede visitar https://<alias>.awsapps.com/workdocs para iniciar sesión en WorkDocs y https://<alias>.awsapps.com/console para iniciar sesión en la consola de administración de AWS. La siguiente imagen muestra la página de inicio de sesión de AWS Management Console.

Figure 1: Login

Figure 1: Login

Para mayor seguridad, puede habilitar la autenticación multifactorial (MFA – Multifactor Authentication en inglés) para el AD Connector, pero necesitará tener una infraestructura RADIUS existente en su on-premises configurada para aprovechar esta función. Consulte Requisitos previos de AD Connector para obtener más información sobre los requisitos y la configuración. Si el MFA está activado con AD Connector, la página de inicio de sesión alojada en su URL de inicio de sesión solicitará a los usuarios un código de MFA además de sus credenciales de inicio de sesión estándar.

El AD Connector está disponible en dos tamaños: pequeño y grande. Un AD Connector grande utiliza recursos informáticos más potentes y es más caro que un AD Connector pequeño. Según el volumen del tráfico de proxy de AD Connector, deberá seleccionar el tamaño adecuado para sus necesidades.

Figure 2: Directory size

AD Connector es altamente disponible, lo que significa que los servidores de infraestructura se ejecutan detrás de escena en varias zonas de disponibilidad de la región en la que se implementa. En caso de que se produzca un error a nivel de host, el AWS Directory Service sustituirá a los hosts que hayan fallado. AWS Directory Service también aplica automáticamente las actualizaciones de rendimiento y seguridad al AD Connector.

El siguiente diagrama ilustra el flujo de autenticación y la ruta de red cuando se habilita el acceso a la consola de AWS:

  1. El usuario abre la página de inicio de sesión personalizada y segura y proporciona su nombre de usuario y contraseña de Active Directory.
  2. La solicitud de autenticación se envía mediante SSL al AD Connector.
  3. AD Connector realiza la autenticación LDAP en Active Directory.
    Nota: AD Connector busca los controladores de dominio más cercanos consultando los registros del servicio DNS (SRV) del dominio.
  4. Tras la autenticación del usuario, AD Connector llama al método STS AssumeRole para obtener credenciales de seguridad temporales para ese usuario. Con estas credenciales de seguridad temporales, AD Connector crea una URL de entrada que los usuarios utilizan para acceder a la consola.
    Nota: Si un usuario está asignado a varios roles, el usuario puede elegir en el momento del inicio de sesión qué rol quiere asumir. De forma predeterminada, la sesión del usuario es válida durante 1 hora. Puede utilizar este procedimiento para cambiar la duración a un máximo de 12 horas por sesión.

Antes de empezar a configurar AD Connector para el acceso federado a la consola de AWS, asegúrese de leer y comprender los requisitos previos de AD Connector. Por ejemplo, debe haber una conexión VPN o Direct Connect instalada entre su VPC y su entorno on-premises. El dominio también debe estar ejecutándose en el nivel funcional de Windows 2003 o posterior. Además, deben estar abiertos varios puertos entre la VPC y el entorno on-premises para permitir que el AD Connector se comunique con su directorio on-premises.

Configurando AD Connector para el acceso federado a la consola de AWS

Habilitar acceso a la consola

Para permitir que los usuarios inicien sesión con sus credenciales de Active Directory, se debe habilitar explícitamente el acceso a la consola. Para ello, abra la consola de AWS Directory Service y haga clic en el ID del directorio.

Esto abre la página de detalles del directorio, donde encontrará un botón Actions dentro de la pestaña Application management para habilitar el directorio para el acceso a la consola de AWS:
Para ello, haga clic en Actions > Enable en la AWS Management Console:
 
 


Una vez que haya habilitado el acceso a la consola, estará listo para empezar a configurar roles y asociar usuarios y grupos de Active Directory a estos roles.
Siga estos pasos para crear un nuevo rol de IAM para usarlo con AWS Directory Service.  El siguiente ejemplo de código muestra la política de confianza de IAM para el rol, después de que es creado.

{
   "Version": "2012-10-17",
   "Statement": [
     {
       "Sid": "",
       "Effect": "Allow",
       "Principal": {
         "Service": "ds.amazonaws.com"
       },
       "Action": "sts:AssumeRole",
       "Condition": {
         "StringEquals": {
           "sts:externalid": "482242153642"
	  }
	}
     }
   ]
}

Asignar usuarios a roles

Ahora que AD Connector está configurado y ha creado un rol, la siguiente tarea es asignar usuarios o grupos a esos roles de IAM.  El mapeo de roles es lo que controla los recursos a los que un usuario tiene acceso en AWS.  Para ello, necesitará:

1. Abra la consola de AWS Directory Service y haga clic en la pestaña Application Management:

2. En la sección AWS Management Console, haga clic en el rol de IAM (que se creó anteriormente en estos pasos) para agregar usuarios:

3. En la sección Manage users and groups for this role, haga clic en Add:

4. Escriba el nombre de un usuario o grupo de Active Directory en el campo de búsqueda.

5. Seleccione el usuario o el grupo y haga clic en Add:

Al terminar, verás el nombre del usuario o grupo junto con el ID correspondiente a ese objeto, tal y como se muestra en la imagen anterior.

La próxima vez que el usuario inicie sesión en la consola de AWS desde la página de inicio de sesión personalizada, iniciará sesión con el rol de seguridad de  DS_Admins.

Unir fácilmente una instancia a un dominio de Active Directory

Otra ventaja de usar AD Connector es la posibilidad de unir instancias de Windows (EC2) directamente a su dominio de Active Directory. Esto le permite unir un servidor Windows al dominio mientras se aprovisiona la instancia, en lugar de utilizar un script o hacerlo manualmente. Esta sección de este post explicará los pasos necesarios para habilitar esta función en su entorno y también cómo funciona el servicio.

Paso 1: Crear un rol

Anteriormente, había que crear manualmente una política de IAM para permitir que una instancia de EC2 se comunicara con SSM, un servicio de AWS que permite configurar las instancias de Windows mientras se están ejecutando y en el primer inicio. Ahora AWS administra dos políticas:  AmazonSSMManagedInstanceCore y AmazonSSMDirectoryServiceAccess que puede utilizar. El rol que va a crear se asignará a una instancia de EC2 cuando se aprovisione, donde el rol AmazonSSMManagedInstanceCore contiene los permisos mínimos para acceder al servicio SSM yAmazonSSMDirectoryServiceAccesstendrá los permisos necesarios para asociar instancias a  un Active Directory administrado por AWS Directory Services.

Para crear el rol:

  1. Abra la consola de IAM.
  2. En el panel de navegación de la izquierda, en Access Management, haga clic en Roles.
  3. Haz clic en Create role.
  4. En Select trusted entity seleccione AWS Service y a continuación, seleccione   Amazon EC2 en Use Case y haga clic en Next.
  5. En la página Add permissions, seleccione las políticas administradas AmazonSSMManagedInstanceCore y AmazonSSMDirectoryServiceAccess. (Para filtrar en la lista, escriba SSM en el campo de filtro)

6. Escriba un nombre para el nuevo rol en el Rol Name.

7. Para terminar, haz clic en Create role.

Al hacer clic en el rol que ha creado, verá una política de confianza (Trusted entity) para EC2, similar al siguiente ejemplo de código.

Política de confianza predeterminada de Amazonec2RoleForSSM:

{
     "Version": "2012-10-17",
     "Statement": [
       {
         "Sid": "",
         "Effect": "Allow",
         "Principal": {
           "Service": "ec2.amazonaws.com"
         },
         "Action": "sts:AssumeRole"
       }
     ]
}

Paso 2: Crear una nueva instancia de Windows en la consola Amazon EC2

Con el rol definido, ahora puede unir a una instancia de Windows a su dominio a través del asistente del Amazon EC2 launch wizard. Para obtener una explicación detallada de cómo hacerlo, consulte Únase sin problemas a una instancia EC2 de Windows.

Sin embargo, si vas a crear una instancia de API nueva, tendrás que crear un documento de configuración de SSM y subirlo previamente al servicio SSM.  Realizaremos ese proceso a continuación.

Nota:  La instancia necesitará acceso a Internet para comunicarse con el servicio SSM.

Al crear una nueva instancia de Windows desde el launch wizard de EC2, el asistente crea automáticamente el documento de configuración de SSM a partir de la información almacenada en el AD Connector. Actualmente, el launch wizard de EC2 no permite especificar en qué unidad organizativa (OU – Organizational Unit) desea desplegar el servidor miembro.

Paso 3: Cree un documento SSM (para unir facilmente un servidor al dominio a través de la API de AWS)

Si desea aprovisionar nuevas instancias de Windows desde la CLI o la API de AWS o desea especificar la OU de destino para sus instancias, deberá crear un documento de configuración de SSM.  Este documento es un archivo JSON que contiene varios parámetros que se utilizan para configurar las instancias.  El siguiente ejemplo de código es un documento de configuración para unirse a un dominio.

{
	"schemaVersion": "1.0",
	"description": "Exemplo de configuração para ingressar uma instância em um domínio",
	"runtimeConfig": {
	   "aws:domainJoin": {
	       "properties": {
	          "directoryId": "d-1234567890",
                  "directoryName": "teste.exemplo.com.br",
                  "directoryOU": "OU=teste,DC=exemplo,DC=com,DC=br",
                  "dnsIpAddresses": [
                     "198.51.100.1",
                     "198.51.100.2"
               ]
            }
        }
    }
 }

En este documento de configuración:

  • directoryId es el ID del AD Connector que creó anteriormente.
  • directoryName es el nombre de dominio (por ejemplo, test.com.br).
  • directoryOU es la OU del dominio.
  • dnsIpAddresses son las direcciones IP de los servidores DNS que especificó al crear el AD Connector.

Para obtener más información, consulte aws:DomainJoin. Cuando haya terminado de crear el archivo, guárdelo como archivo JSON.
Nota:  El nombre del archivo debe tener un mínimo de 1 carácter y un máximo de 64 caracteres.

Paso 4: Cargue el documento de configuración a SSM

Este paso requiere que el usuario tenga permiso para usar SSM para configurar una instancia.  Si no tiene una política que incluya estos permisos, cree una nueva política con el siguiente JSON y asígnela a un usuario o grupo de IAM.

{
   "Version": "2012-10-17",
   "Statement": [
     {
       "Effect": "Allow",
       "Action": "ssm:*",
       "Resource": "*"
     }
   ]
}

Después de iniciar sesión con un usuario asociado a la política de SSM IAM que creó, ejecute el siguiente comando en la CLI de AWS.

aws ssm create-document --content file://path/to/myconfigfile.json --name "My_Custom_Config_File"

Nota:  En los sistemas Linux/Mac, debe añadir un “/” al principio de la ruta (por ejemplo, file: ///Users/user/temp).

Este comando carga el documento de configuración que creó en el servicio SSM, lo que le permite hacer referencia a él al crear una nueva instancia de Windows desde la CLI de AWS o el asistente de inicio de EC2.

Conclusión

En este post se mostró cómo puede simplificar la administración de cuentas mediante Active Directory para el acceso federado a la consola de AWS. También se analizó cómo puede habilitar hybrid IT mediante AD Connector para unir fácilmente las instancias de Windows a su dominio de Active Directory.  Al disponer de esta información, puede crear una relación de confianza entre su Active Directory y AWS. Además, ahora dispone de una forma rápida y sencilla para habilitar single sign-on sin tener que replicar identidades ni implementar infraestructura adicional on-premises.

 

Este artículo se tradujo del Blog Post de AWS en inglés.

 


Acerca de los autores

Jeremy Cowan es Specialist Solutions Architect para contenedores dentro de AWS, sin embargo, su familia piensa que vende “espacio en la nube”. Antes de sumarse a AWS, Jeremy trabajo para diferentes empresas de software como VMWare, Microsoft e IBM. Cuando no esta trabajando, podrás encontrarlo disfrutando de la naturaleza, alejado de la tecnología.

 

 

 

 

Bright Dike es Solutions Architect en AWS. Él trabaja con clientes y partners ayudando a la mejora de sus posturas de seguridad, como así también ejecutando técnicas automatizadas de remediación. Entre sus áreas de influencia se encuentran la detección de amenazas, respuesta a incidentes y Security Hub.
 

 

 

 

 

David Selberg es Solutions Architect en AWS, apasionado por ayudar a sus clientes a construir soluciones bien arquitectadas en la nube de AWS. Con amplia experiencia en ciberseguridad, David ama investigar y profundizar en problemáticas relacionadas con la seguridad, siempre y cuando no esté creando contenido técnico para su canal de Twitch “All Things AWS”.
 

 

 

 

 

Abhra Sinha es Solutions Architect basado en Toronto. Abhra disfruta ser un punto de contacto de confianza para sus clientes, trabajando de cerca con ellos para resolver sus desafíos técnicos y ayudándolos a construir arquitecturas seguras y escalables en AWS. En su tiempo libre disfruta la fotografía y explorar nuevos restaurantes.
 

 

 

 

 

 

Revisores

Breno Silva es Arquitecto de Soluciones en AWS trabajando para el sector Enterprise. Trabajó con clientes de CPG, minoristas, industriales y automotrices. Forma parte de las comunidades de Ciber-Security e IoT. En su tiempo libre, le gusta automatizar su casa, tocar la guitarra y practicar deportes al aire libre.

 

 

 

 

Eduardo Inoue trabaja como Technical Account Manager en AWS, empoderando a los clientes en su transición a la nube. Cuenta con más de 13 años de experiencia en tecnologías de infraestructura, como computación, redes y almacenamiento. Apasionado por la tecnología, siempre busca aprender nuevas soluciones.
 

 

 

 

Liz Menichetti es Technical Account Manager en AWS. Desde 2019 ayuda a clientes de AWS con arquitecturas y proyectos relevantes en los sectores más variados de la industria, no solo brindando apoyo, sino también aportando valor a sus negocios con buenas prácticas de seguridad, escalabilidad, resiliencia, rendimiento y excelencia operativa.

 

 

 

 

Adrian Diaz se desempeña actualmente como Technical Account Manager, apoyando a clientes de Enterprise Support en su viaje a la nube de AWS. Cuenta con más de 15 años de experiencia en TI, habiéndose desempeñado como administrador de sistemas e ingeniero de infraestructura, en donde ha participado de proyectos de networking, telefonía IP, virtualización, migración de centro de cómputos, entre otros.