Ampliar su infraestructura de Active Directory en AWS con Okta Identity Cloud

Por Lucas Henrique Garcia, Arquitecto de Soluciones de SMB en AWS,
Diego Voltz, Arquitecto de Soluciones de Enterprise en AWS,
Pavankumar Kasani, Arquitecto de Soluciones en AWS y
Xiaozang Li, Arquitecto de Soluciones en AWS

¿Está listo para ampliar su entorno de Active Directory (A.D) local a AWS y reducir el trabajo pesado de administrar la infraestructura de AD? ¿Le gustaría mantener un entorno de Active Directory de alta disponibilidad en AWS para usarlo junto con otras aplicaciones? Algunos de nuestros clientes que utilizan la aplicación Okta Identity Cloud para aplicaciones internas y externas (y que necesitan objetos de Active Directory sincronizados con la aplicación para la autenticación) pueden hacer uso de una arquitectura centralizada para el acceso local y para las aplicaciones en la nube a través de la configuración de una extensión del entorno local de Active Directory mediante el servicio AWS Managed Microsoft Active Directory y una configuración de relación de confianza (Trust Relationship).

En este artículo, le mostraremos una de las arquitecturas que puede usar para sincronizar objetos entre su entorno de Active Directory local y un dominio configurado en AWS Managed Microsoft Active Directory. Uno de los componentes principales de esta arquitectura es el agente de Active Directory de la aplicación Okta Identity Cloud que se utilizará para realizar la sincronización de grupos y usuarios entre estos dominios. El agente de AD de Okta se puede instalar y configurar en servidores locales que sean miembros de un dominio o en instancias EC2 en AWS, como se detalla a continuación (Figura 01).

Figura 01. Flujo de sincronización entre los dominios locales y en AWS y Okta Identity Cloud.

Antes de continuar, nos gustaría detallar un poco más los servicios involucrados y sus características principales.

AWS Directory Services le permite crear un entorno de Active Directory como un servicio administrado, compatible con los servidores de controladores de dominio R2 de Windows Server 2012. Cuando selecciona y crea este tipo de directorio, se crea un entorno de controladores de dominio de alta disponibilidad mediante la estructura de red redundante de Amazon Virtual Private Cloud (VPC) mediante el uso de zonas de disponibilidad.

Okta identity Cloud, por otro lado, es una solución de gestión de identidad empresarial que es compatible con varias aplicaciones locales y nativas de la nube. Okta Agent AD es el componente que permite la integración de Okta Identity Cloud con su entorno de Active Directory, garantizando así que utilice aplicaciones SaaS compatibles con Okta, garantizando así una simplificación y centralización de la gestión de usuarios y sus credenciales de acceso con otras aplicaciones.

Recuerde que las instancias basadas en las AMI de Windows Server creadas por AWS, como las instancias bajo demanda, las instancias spot, las instancias reservadas o incluso las instancias que usan planes de ahorro también tienen incorporado el costo de la licencia para usar Windows Server.

La conectividad de red entre su centro de datos y las regiones de AWS.

Antes de comenzar con las configuraciones necesarias para crear una relación de confianza entre su entorno de AD local y AWS Managed Microsoft Active Directory, es importante que revise y valide los requisitos previos necesarios para crear relaciones de confianza publicados en nuestra documentación. en este enlace. Por ejemplo, le recomendamos encarecidamente que configure una solución VPN o AWS Direct Connect entre su VPC y su entorno local.

Para entender cómo crear una conexión VPN flexible en AWS, consulte nuestra Guía del usuario de VPN de sitio a sitio. La VPN de sitio a sitio de AWS es un servicio administrado que utiliza túneles IPSec para crear una red segura entre su centro de datos u oficina y sus recursos publicados en AWS. Al utilizar conexiones VPN de sitio a sitio, podemos crear conexiones a las VPC de AWS y también a AWS Transit Gateway. Se crean dos túneles por conexión para garantizar la redundancia. Para comprender mejor las conexiones dedicadas de AWS Direct Connect y sus configuraciones, consulte nuestra guía publicada en este enlace.

Creación de relaciones de confianza entre los dominios de Active Directory on-premise y de AWS Managed AD

Una confianza es un vínculo entre dos dominios diferentes (identificados como “Trusted Domain” y “Trusting Domain”). Estas relaciones se pueden configurar de diferentes maneras para permitir tipos específicos de acceso entre estos mismos dominios. Por ejemplo, un escenario configurado como “One-Way Trust” permite que las cuentas de usuario del dominio clasificado como “Trusted Domain” accedan a los recursos del dominio “Trusting Domain”. En un escenario de “Two-Way Trust”, las cuentas de ambos dominios pueden acceder a los recursos publicados en cada dominio, lo que garantiza una conexión bidireccional.

Las relaciones de “Two-Way Trust” son las más comunes al configurar extensiones entre el entorno local de Active Directory y AWS Managed Microsoft Active Directory, lo que permite que varias aplicaciones se integren con los servicios de directorio, garantizando así el acceso en ambos dominios mediante un inicio de sesión unificado mediante el inicio de sesión único (SSO). AWS Managed Microsoft Active Directory admite confianzas externas y de bosque con su entorno local de los siguientes tipos (direcciones):

Entrada unidireccional: One-Way Incoming
Saliente unidireccional – One-Way Outgoing
Bidireccional (Two-Way Bidirectional)

Para crear una relación de confianza, siga los pasos a continuación:

Prepare su dominio local para la relación de confianza. Esto incluye realizar configuraciones de firewall, habilitar la autenticación previa para el protocolo Kerberos y configurar reenviadores condicionales de DNS (Conditional Forwarder)
Prepare su entorno de AWS Managed Microsoft AD para la relación de configuración. Esto incluye configurar las subredes de la VPC, los grupos de seguridad y habilitar la autenticación previa para el protocolo Kerberos.
Cree una relación de confianza entre su dominio de Active Directory local y su dominio de AWS Managed Microsoft Active Directory (AD).

Instalación y configuración del agente de Okta para Active Directory

En primer lugar, descargue e instale el agente de Okta AD en una instancia EC2, que debe configurarse como miembro del dominio configurado en su entorno de AWS Managed Microsoft AD. Un agente de Okta se puede asociar a varios dominios. Cuando exista una relación de confianza entre su dominio local y su dominio creado en AWS, puede asociar esos dominios con el agente configurado en su instancia EC2, en lugar de crear varios servidores con diferentes agentes que apunten a dominios específicos.

Para brindar alta disponibilidad a esta arquitectura, se recomienda la configuración de un agente de Okta configurado en su entorno local. Esto reducirá el impacto si se produce una interrupción de la red entre el centro de datos local y AWS. Okta también recomienda que se instalen más agentes en los servidores para una mayor redundancia y protección en caso de fallo. Para comprender mejor las opciones de instalación y configuración del agente de Okta y su integración con Active Directory, le recomendamos que lea esta guía.

Validación de objetos de Active Directory

Una vez que el agente de Okta esté instalado y configurado en la instancia de EC2, inicie sesión en la consola y en la administración de Okta. En la pestaña “Provisioning” importe los usuarios (Full Import) listados en su directorio de AWS Managed AD (consulte la figura 02 y la figura 03). La sincronización de otros objetos creados posteriormente se puede realizar configurando importaciones programadas con un intervalo mínimo de una hora. Una vez finalizado el proceso de importación, si tiene alguna cuenta de usuario que se superponga entre AWS Managed AD y Okta, puede asociar estos objetos manualmente. Además, puede configurar reglas de pertenencia para asignar automáticamente a estos usuarios si lo desea. Consulte los pasos para realizar esta configuración en la guía “Import AD Users to Okta”.

Figura 02. Importación de usuarios de Active Directory en Okta Identity Cloud

Figura 03. Resultados del proceso de importación de objetos de Active Directory en la consola de Okta Identity Cloud.

Puede importar grupos de cualquier bosque o dominio conectado a Okta. Esto se debe a que el agente de AD de Okta detecta automáticamente todos los grupos en los dominios u OU que ha seleccionado. Si registra el agente de AD de Okta para más de un dominio y ha seleccionado la unidad organizativa raíz para todos ellos, se importan todos los grupos. Consulte la guía “Import Ad Groups to Okta” para comprender mejor cómo sincronizar estos grupos.

Sicronización de contraseñas con Okta

Cuando inicia sesión en Okta con sus credenciales de Active Directory, el proceso de autenticación se delega en el dominio de Active Directory. Esto significa que Okta no analiza ni almacena ninguna credencial.

En algunos casos, las credenciales deben sincronizarse entre Active Directory y Okta para que las use una aplicación en particular. Si un usuario cambia su contraseña de dominio en Active Directory e intenta acceder a las aplicaciones en una sesión de inicio de sesión único existente, por ejemplo, encontrará errores de contraseña incorrectos. Esto se debe a que la nueva contraseña aún no se ha sincronizado y se requerirá un nuevo proceso de inicio de sesión para validar el acceso. Para evitar experiencias disruptivas como esta, puede usar el agente de sincronización de contraseñas de AD de Okta, que realizará un seguimiento de los cambios realizados y los sincronizará con Okta y sus otras aplicaciones integradas. Para obtener más información sobre cómo funciona este proceso de sincronización y el desglose de cómo el agente de sincronización de contraseñas de Okta Password Sync Agent realiza un seguimiento de todo el flujo de restablecimiento de contraseñas, consulte esta guía dedicada.

Índice

En este artículo, ejemplificamos una de las formas de sincronizar las credenciales de un entorno de Active Directory local y AWS Managed AD con la solución Okta Identity Cloud. Con esta sincronización, podrá centralizar el acceso de sus aplicaciones en la nube y en las instalaciones y garantizar un acceso transparente a las aplicaciones que admiten los servicios de Active Directory en AWS. Nuestros clientes también pueden realizar una migración completa de su entorno local al servicio administrado de AWS Managed Microsoft AD mediante herramientas como la herramienta de migración de Active Directory (ADMT) junto con el servicio PES (Password Export Service).

Sobre os autores

Lucas Henrique Garcia es arquitecto de soluciones para el equipo de pymes y anteriormente trabajó en el equipo de soporte premium de AWS en Dublín. Se centra en ayudar a los clientes de AWS a resolver sus problemas y a diseñar arquitecturas para su empresa.

Diego Voltz se desempeña como arquitecto de soluciones sénior en el segmento empresarial de AWS. Se desempeñó durante 15 años como director de tecnología de empresas emergentes en el segmento de alojamiento web y salud, centrándose en la virtualización, el almacenamiento y los contenedores, ayudando hoy a los clientes de AWS en el proceso de adopción de la nube y a optimizar los costos.

Pavankumar Kasani es un arquitecto de soluciones de AWS con sede en la ciudad de Nueva York. Le apasiona ayudar a los clientes a diseñar soluciones escalables, bien diseñadas y modernizadas en la nube de AWS. Fuera del trabajo, le encanta pasar tiempo con su familia, jugar al cricket, tenis de mesa y también probar nuevas recetas en la cocina.

Xiaozang Li es arquitecto de soluciones en Amazon Web Services (AWS), donde está obsesionado con ayudar a los clientes empresariales a iniciar su viaje a la nube para lograr agilidad, elasticidad e innovación más rápida. Antes de AWS, Xiaozang trabajó en el espacio de la red de entrega de contenido (CDN), ayudando a las empresas a entregar contenido web y de transmisión de una manera rápida, confiable y segura. Xiaozang vive en Boston y pasa el invierno haciendo snowboard y esquiando en las montañas.

Blog de Amazon Web Services (AWS)