This content originally appeared on DEV Community and was authored by Diana Castro

Fecha Estelar 2: AWS Directory Services y Federation

Dentro de la preparación para el AWS Certified Security — Specialty, descubrí que un tema clave merece especial atención: la integración entre Active Directory (AD) y AWS, así como la federación de identidades.

Por eso decidí estructurar un repaso práctico: comprender cómo se conectan los directorios corporativos con AWS sin necesidad de replicar identidades, y qué implicaciones tiene para habilitar un acceso seguro y centralizado a los recursos.

AWS Directory Services

Microsoft Active Directory (AD)

Es básicamente el sistema de identidad y autenticación centralizado que usan una gran mayoría de empresas para gestionar usuarios, computadoras y recursos de red en un entorno Windows. Es el gran libro de contactos de la empresa o visto como un edificio el guardia de seguridad que te detiene en la entrada y decide si puedes entrar o no y a qué parte de las instalaciones te puedes dirigir.

¿Cuál es su función?

• Autenticación: Verifica quién eres cuando tratas de ingresar al edificio – el portero o guardia te solicita tu carnet de empleado y verifica tu identidad (equivale a usuario y contraseña)

• Autorización: Define a qué pisos y oficinas puedes acceder una vez dentro – tu carnet tiene permisos específicos: tal vez puedes entrar a contabilidad, pero no a recursos humanos (equivale al acceso a carpetas, aplicaciones, servidores)

• Gestión centralizada: El departamento de seguridad del edificio mantiene una base de datos central con todos los empleados, sus niveles de acceso y las políticas del edificio (no fumar, no ingresar sin carnet, horarios de acceso). Desde ahí controlan quién puede ir dónde y cuándo.

• Directorio de objetos: Es como el directorio telefónico interno del edificio que almacena información sobre todos los empleados (nombre, departamento, extensión, nivel de acceso), equipos (impresoras, computadoras), salas de juntas, y otros recursos del edificio.

¿Por qué es importante el tema para nosotros?

Como lo mencioné anteriormente muchas empresas ya tienen AD on-premises y pueden tener necesidades como las siguientes:

• Extender su identidad existente a la nube
• Usar las mismas credenciales para recursos AWS y on-premises
• Mantener políticas de seguridad consistentes
• Permitir Single Sign-On (SSO)

AWS Directory Services permite integrar o replicar esta funcionalidad en la nube, ya sea conectándote a un AD existente o creando uno nuevo completamente gestionado por AWS y tenemos a nuestra disposición diferentes sabores.

Los conceptos básicos detrás de Active Directory que debemos conocer

Revisaremos los conceptos fundamentales de Active Directory, ya que al estudiar AWS Directory Services nos encontraremos con términos técnicos como Kerberos, LDAP, entre otros. Mantendremos nuestra analogía del edificio corporativo para explicar estos conceptos de manera sencilla.

Consideremos al Controlador de Dominio (DC) como el guardia o portero del edificio.

El segundo concepto que estudiaremos es Kerberos, este corresponde al protocolo de autenticación principal en AD. En la entrada el DC te dará un boleto firmado que dice: “Diana es Diana y puede visitar el edificio el día de hoy hasta las 5 p.m.”. Cuando lleguemos a la sala de reuniones o al comedor solo tendremos que mostrar el boleto y podremos entrar, en este caso cuando quieras abrir una aplicación como QuickSight o SharePoint o las decenas de aplicaciones que usas en el día a día, no hay que realizar todo el protocolo solo enseñamos el boleto firmado es decir no ingreso mi contraseña 20 veces al día.

El tercer concepto corresponde a LDAP (Lightweight Directory Access Protocol) es el protocolo que usan apps/servicios para consultar información del directorio. Es decir, es el directorio o guía del edificio, y funciona así cuando yo quiero entrar a la sala de junta directiva la secretaria me mira y llama al responsable de la seguridad y le dice tengo a Diana tratando de entrar a la Sala de la Junta Directiva y este le responderá que ni lo sueñe no la encuentro en el directorio como autorizada en ese grupo privilegiado, pero cuando intente entrar al comedor el responsable de la puerta consultará y me dejará ingresar. Cuando yo trato de acceder a QuickSight, este le pregunta al DC: “Dame la lista de todos los usuarios que son del grupo Analistas que son quienes tienen derecho a usar esta aplicación” y DC responde usando LDAP.

En algunos edificios la seguridad es extrema y te pedirán otro elemento para identificarte, un segundo factor por ejemplo tu huella, aquí entra RADIUS (Remote Authentication Dial-In User Service) es un protocolo usado para autenticación centralizada y MFA. RADIUS es el segundo elemento de autenticación es el guarda extra que te pide coloques tu dedo índice para verificar que tú eres tú realmente con un segundo elemento.

Nos queda un elemento importante que veremos más adelante Trusts (confianza) imaginemos que tenemos dos edificios, los guardias de seguridad de cada edificio acuerdan que dejarán ingresar personas del otro edificio siempre que vengan identificadas. La confianza puede ser en un sentido por ejemplo, el guarda del edificio más grande deja pasar a los inquilinos del más pequeño, pero al revés no o en dos vías ambos guardias dejan pasar a los inquilinos de cualquiera de los edificios.

En resumen:

• Kerberos: nos ayuda a evitar la fatiga de escribir la contraseña para cada aplicación que tratamos de acceder
• LDAP: indica qué permisos tengo y quién soy
• RADIUS: agrega una capa de seguridad consultando por algo que tengo
• Trust: Confianza, tus amigos son mis amigos también

Los diferentes sabores de AWS Directory Services

AWS Directory Service es un servicio administrado que proporciona capacidades de directorio en la nube AWS y ofrece diversas opciones:

• AWS Managed Microsoft AD: Active Directory completo en AWS
• AD Connector: Proxy que conecta con AD on-premises existente
• Simple AD: Directorio LDAP básico basado en Samba 4

AD Connector

Imaginemos ahora la empresa abre una sucursal (AWS Cloud) pero no quiere replicar toda la infraestructura de seguridad del edificio principal (datacenter on-premises).

Entonces implementamos un mecanismo sencillo que aproveche los recursos que ya tenemos, contratamos a un guardia o portero especializado AD Connector en la sucursal que no tiene acceso directo a la base de datos de empleados y realiza los siguientes pasos:

• Cuando alguien quiere entrar, el portero llama por teléfono/radio al edificio principal para verificar credenciales
• Si el edificio principal confirma, el portero autoriza el acceso

La siguiente figura ilustra en términos técnicos este flujo

Beneficios:

• No es necesario replicar controladores de dominio en AWS
• Los empleados usan sus credenciales corporativas
• Redirige consultas LDAP/Kerberos al AD original
• Permite acceso a WorkSpaces, QuickSight, EC2 Windows y Consola AWS

AD Connector es un proxy service que mantiene toda la información de usuarios en un solo lugar – el Active Directory original. La clave está en que no copia, ni sincroniza usuarios: redirige autenticación y consultas (LDAP/Kerberos) a los controladores de dominio existentes. Así puedes usar tus mismas credenciales corporativas para iniciar sesión en servicios como Amazon WorkSpaces, QuickSight, unir EC2 Windows al dominio, e incluso entrar a la Consola de AWS.

Características

• Multi-AZ: el conector se despliega por alta disponibilidad en dos subnets en AZ distintas
• Tamaños: Small o Large depende de la cantidad de usuarios y el tamaño de la carga small se recomienda hasta para 500 usuarios y large hasta para 5000
• Cifrado/compatibilidad Kerberos: soporta AES-256/128 HMAC y RC4-HMAC
• Sitios y subredes de AD: mapea las subnets de tu VPC en Active Directory Sites and Services para que el conector “descubra” DCs cercanos (evita latencias cruzadas)
• 1:1 por dominio: necesitas un AD Connector por cada dominio (incluye child domains) y cada conector usa su propia cuenta de servicio
• No replica ni sincroniza objetos; no guarda contraseñas
• MFA vía RADIUS existente
• Depende de la conectividad (VPN/Direct Connect) entre VPC y la infraestructura on-premise; si el enlace cae, también caerá la autenticación por AD Connector
• La latencia de la red afecta directamente el rendimiento
• Algunas funciones avanzadas de AD no están disponibles

La siguiente tabla nos ayudar a clarificar cuando debemos hacer uso de AD Connector y cuando es mejor evitarlo

AWS Managed Microsoft AD

Cuando hablamos de AWS Managed Microsoft AD, nos referimos a un Active Directory real ejecutándose como servicio administrado en AWS. No es una “compatibilidad” ni un sustituto: es un AD completo, con controladores de dominio (DCs) corriendo en Windows Server, soportando todas las funciones que conocemos: grupos, trusts, Kerberos, LDAP, GPOs, OUs, etc.

La clave está en el modelo de responsabilidad compartida:

• Nosotros administramos el directorio, usuarios, grupos, políticas (GPOs), y estructura organizativa (OUs)
• AWS se encarga de la infraestructura subyacente: sistema operativo, parches, backups, recuperación ante desastres y disponibilidad

Características destacadas

1. Alta disponibilidad: por defecto despliega dos Domain Controllers en distintas zonas de disponibilidad, garantizando resiliencia automática

2. Multi-región: puede implementarse como extensión de tu AD on-premises o bien desplegarse en múltiples regiones para mayor cercanía y continuidad

3. Escalable: Podemos pasar de pocos objetos a miles para eso tenemos Versión Standard: hasta 30,000 objetos (ideal para PYMEs) y Versión Enterprise hasta 500,000 objetos (grandes corporaciones)

4. Integración nativa con AWS: se conecta de forma transparente con servicios como Amazon RDS for SQL Server, QuickSight, FSx for Windows File Server, WorkSpaces, entre otros. (Dato clave: RDS no es compatible con AD Connector, pero sí con Managed Microsoft AD).

5. Trusts (confianzas): permite establecer confianzas bidireccionales con tu AD on-premises, lo que facilita que usuarios locales accedan a recursos en AWS sin duplicar credenciales

¿Qué problemas resuelve?

• Elimina la necesidad de administrar tus propios Domain Controllers en la nube
• Facilita la autenticación en aplicaciones que requieren Kerberos o NTLM
• Permite extender tu AD corporativo a AWS de manera transparente y segura
• Soporta la migración de aplicaciones legadas que dependen de AD, sin obligarte a mantener infraestructura on-premises solo para ellas

AWS Managed Microsoft AD es la opción para organizaciones que necesitan toda la potencia y compatibilidad de Active Directory, pero desean delegar en AWS la operación, seguridad, alta disponibilidad y escalabilidad del servicio.

La siguiente tabla nos ayudará a identificar situaciones en las que nos será útil y cuando por el contrario sería contraproducente.

Simple AD

El sabor light de la familia. Y ojo, que no por eso debe subestimarse. Está diseñado pensando en pequeñas empresas o startups que necesitan lo esencial de un Active Directory sin toda la complejidad —y el costo— de uno completo.

Su mayor virtud es precisamente esa: ser la opción económica y práctica. Con Simple AD puedes manejar usuarios, grupos, unir instancias Windows a un dominio y aplicar algunas GPOs básicas. Si lo que buscas es cubrir lo fundamental sin pagar por funciones que nunca vas a usar, este servicio encaja perfecto en la premisa de “usa solo lo que realmente necesitas”.

Además, se despliega automáticamente en dos zonas de disponibilidad dentro de la misma región, lo que le da un nivel de alta disponibilidad muy conveniente para su propósito.

Eso sí, tiene limitaciones claras: no soporta trusts con AD on-premises, no se integra con todos los servicios de AWS (el más doloroso, en mi opinión, es que no funciona con RDS para SQL Server), tiene un límite de 5,000 usuarios y solo puede vivir en una región. Y si me preguntas, lo que más me molesta es que no soporte MFA… pero bueno, ahí ya entramos en preferencias personales.

Resumen comparativo

Federation

Antes de introducir el concepto permítanme a citar a Les Luthiers pues el tema es similar al anterior pero:

“Parecido no es lo mismo caballero”

Federación significa que con una sola identidad puedo acceder a múltiples servicios sin tener que crear cuentas separadas en cada uno. Veámoslo así: Federation aplica cuando quiero entrar a AWS con mi cuenta corporativa (o la de un proveedor de identidades) sin tener que crear usuarios IAM para cada persona.

En su lugar, otorgamos accesos temporales y seguros mediante STS.

Ahora bien, existen diversos proveedores de identidad, como ADFS, Okta, Azure AD o Google Workspace, que pueden cumplir ese rol de “recepción central” de nuestras identidades.

Conceptos básicos detrás del concepto de federación

Regresemos a los edificios. Pensemos que ahora tenemos alianzas con empresas externas y, definitivamente, los guardias de esos otros edificios no quieren complicarse registrando a tus inquilinos en su directorio.

El guardia del edificio aliado confiará en ti: si tú le dices que Diana trabaja en tu edificio, él te creerá y le dejará pasar. Aquí intervienen todos los conceptos importantes de Federation:

IdP — Identity Provider: Corresponde a la recepción del edificio corporativo. Emitirá un pase para que tus empleados visiten los edificios aliados Este pase puede ser un SAML Assertion o un token OIDC. Ejemplos de IdP: _ADFS, Okta, Azure AD, Google Workspace
_. Piensa en el IdP como la recepción que sabe quién eres y te da un pase confiable.

Service Provider: Es el edificio aliado. En nuestro caso, la nube de AWS, que no quiere tener un usuario IAM para cada inquilino. Confía en lo que tu IdP le diga y acepta el pase que emitiste. El guardia del edificio aliado no conoce a Diana personalmente, pero confía en el sello de tu recepción.

Protocolos– Es el pase _SAML*_ un pase o tiquete sellado utilizado por aplicaciones corporativas _OIDC*_un pase más moderno basado en OAuth2, como un QR que llevas en tu celular. Ambos permiten que el Service Provider verifique tu identidad sin que tengas que crear usuarios locales.

AWS STS — Security Token Service: Cuando ingresas al otro edificio, el guardia interno emite un boleto temporal. Por ejemplo, válido por una hora. Este boleto es una credencial temporal ligada a un rol específico (AssumeRole). Puedes imaginarlo como ponerte una chaqueta o casco que diga “Analista” o “Cocinera”, que determina qué puedes hacer dentro del edificio. Esto garantiza que incluso si pierdes el pase, tu acceso temporal expira y nadie puede usarlo indebidamente.

Muchos conceptos y ¿Por qué no Kerberos?

Kerberos solo funciona para recursos internos, dentro de tu AD.

• Si todo está administrado por tu AD, Kerberos permite SSO en la red interna
• Pero si tenemos recursos externos, como aliados o la nube, necesitamos un pase temporal que sea reconocido fuera del dominio

Es como la diferencia entre identificación nacional y pasaporte: tu DNI te sirve dentro del país, pero para viajar necesitas un documento que otros países reconozcan.

En Resumen

• El IdP dice quién eres.
• El Service Provider te deja pasar temporalmente
• STS + AssumeRole te entrega credenciales temporales con permisos específicos.
• Kerberos funciona dentro de tu dominio; Federation es para acceder a recursos externos sin crear usuarios locales.

Un flujo vía Federation

Esta vez Ana será nuestro conejillo de indias:

1. Ana llega al edificio (AWS Console)

   • Ana se presenta en la recepción del edificio aliado — es decir abre la página de AWS Console
   • La pregunta obvia: “¿Quién eres? Yo no te conozco.” Y llaman al edificio del que enviaron a ANA. AWS redirige la autenticación hacia el Identity Provider (IdP) configurado, por ejemplo ADFS en su empresa

2. Va a la recepción de su empresa (IdP)

   • Ana ingresa su usuario y contraseña corporativa en la recepción central (ADFS)
   • El recepcionista confirma: “Sí, Ana trabaja aquí, aquí está su pase.” Técnicamente ADFS autentica contra Active Directory (con Kerberos) y emite un token SAML firmado digitalmente

3. Recibe el pase universal (SAML Assertion)

   • La recepción le da un pase con sello de confianza que dice: “Esta es Ana, del departamento de Finanzas, tiene permiso para acceder como ‘Analista’.” El token SAML contiene atributos (nombre, grupos, roles permitidos)

4. Entrega el pase en la ventanilla de seguridad interna (AWS STS)

   • Ana llega a AWS con el pase. AWS STS lo revisa: “Este pase viene de ADFS, que es de confianza. Todo bien.” AWS STS (Security Token Service) valida el SAML assertion

5. Le dan una tarjeta temporal con un rol (AssumeRole)

   • La ventanilla de AWS le da una tarjeta temporal de visitante con su rol: “Analista — válido por 1 hora.” STS devuelve credenciales temporales ligadas al rol IAM correspondiente

6. Accede al piso correcto (recursos en AWS)

   • Con su tarjeta temporal, Ana entra al piso de “Reportes Financieros” en AWS. Cuando la tarjeta expira, debe volver a pedir otra. Acceso controlado con roles temporales si se filtra una credencial, expira rápidamente

Beneficios

• Solo se usa credenciales corporativas no más usuarios en AWS
• La empresa mantiene el control en un solo directorio
• AWS nunca guarda usuarios solo confía en el pase SAML de su IdP
• Los accesos son temporales y seguros

Conclusión

Ya exploramos tres formas de integrar Active Directory con AWS y vimos cómo funciona la federation para permitir un acceso seguro y transparente a los usuarios. La clave está en evaluar tus necesidades: el tamaño de la organización, la complejidad que estás dispuesto a manejar y el presupuesto disponible.

Como siempre, la premisa es clara: usa solo lo que realmente necesitas. Elegir la opción adecuada garantiza seguridad, eficiencia y escalabilidad, sin sobrecargar tu infraestructura ni complicar la administración.

This content originally appeared on DEV Community and was authored by Diana Castro