Blog de Amazon Web Services (AWS)

Integrando AppStream 2.0 con AWS Managed Active Directory en escenarios multi-forest: De cero a cien

Por Caio Ribeiro César, Arquitecto de Soluciones na AWS
Ivan Vargas, Arquitecto de Soluciones na AWS

 

Amazon AppStream 2.0 es un servicio administrado de streaming de aplicaciones. Usted administra de forma centralizada las aplicaciones de escritorio en AppStream 2.0, y las entrega de forma segura a cualquier computador. En este modelo, podemos escalar fácilmente a cualquier número de usuarios en todo el mundo sin necesidad de comprar, aprovisionar y operar hardware o infraestructura.

El protocolo NICE DCV ajusta automáticamente cada sesión de streaming según las condiciones de la red para proporcionar una experiencia fluida al usuario. Todos los usuarios acceden a la misma versión de las aplicaciones. Los administradores pueden gestionar de forma centralizada las aplicaciones en AppStream 2.0, en vez de gestionar instalaciones y actualizaciones en cada equipo de usuario.

El servicio Amazon AppStream 2.0 también establece conexiones con Active Directory, con la red, con almacenamiento en la nube y con archivos compartidos. Los usuarios acceden a las aplicaciones utilizando sus credenciales existentes, y las políticas de seguridad existentes administran el acceso. En este artículo analizaremos cómo integrar Amazon AppStream 2.0 con Active Directory en un escenario de confianza multi-forest de AWS Managed AD con Active Directory en el entorno on-premises.

El formato de artículo “De cero a cien” es diferente a los artículos que normalmente publicamos. Esta será una implementación completa paso a paso de la arquitectura, con documentación detallada.

Para esta arquitectura, vamos a:

  1. Crear una federación entre forests (AWS Managed AD y Domain Controllers gestionados [AD OnPremises];
  2. Configurar AppStreams 2.0 con una flota de instancias unidas al dominio;
  3. Configurar ADFS 3.0 con permisos especiales de containers para AWS Managed AD, sirviendo como Proveedor de Identidad (IdP) para AppStreams 2.0.
  4. Habilitar la federación de identidades con ADFS 3.0 (o ADFS 4.0) y Amazon AppStream 2.0

 

 

Esta publicación hace referencia a varios artículos de AWS, principalmente la publicación creada por Matt Guanti.

Un Forest de Active Directory (bosque de AD) es el contenedor más lógico de una configuración de Active Directory, que contiene dominios, usuarios, equipos y políticas de grupo. El modelo de confianza multi-forest es la creación de una relación de confianza entre los bosques, que permite el acceso a algunos recursos que viven en bosques externos.

AWS Managed AD desempeña el papel de “resource forest”, en el que separaremos cuentas y recursos de usuarios en diferentes bosques. Usaremos esta configuración para que cualquier problema con un bosque permita al otro continuar la operación.

Active Directory Federation Services (o ADFS) permitirá la administración de identidades y accesos federados en este entorno multi-forest, ampliando la capacidad de utilizar la funcionalidad de inicio de sesión único (Single Sign On, o SSO) para Amazon AppStream, lo que permitirá a los clientes, partners y proveedores una experiencia de usuario simplificada durante el acceso.

En Amazon AppStream 2.0, una flota (Fleet) consiste en instancias de streaming que ejecutan la imagen especificada. Un “stack” consiste en una flota asociada, políticas de acceso de usuarios y configuraciones de almacenamiento. Fleet Auto Scaling permite cambiar automáticamente el tamaño de su flota para que la oferta de instancias disponibles coincida con la demanda de los usuarios. Dado que un usuario requiere una instancia de flota, el tamaño de la flota determina el número de usuarios que pueden transmitir simultáneamente. Puede definir políticas de escalado que ajusten automáticamente el tamaño de su flota en función de una variedad de métricas de utilización y optimizar el número de instancias disponibles para satisfacer la demanda de los usuarios. También puede optar por desactivar el escalado automático y hacer que la flota funcione con un tamaño fijo.

Usted puede crear una experiencia dinámica, interactiva y personalizada para sus usuarios incorporando una sesión de streaming de AppStream 2.0 en su sitio web. Las sesiones de streaming embebidas (Embedded AppStream Streaming Sessions) permiten a los usuarios interactuar con modelos, mapas y conjuntos de datos 3D directamente desde su sitio web. Por ejemplo, los usuarios pueden visualizar instrucciones de entrenamiento o materiales educativos junto con la sesión de streaming de AppStream 2.0.

Actualmente, el uso del grupos de usuarios SAML 2.0 y AppStream 2.0 no se soportan como métodos de autenticación para sesiones de streaming embebidas de AppStream 2.0 (Embedded AppStream Streaming Session). Para Embeded, podemos utilizar AWS SSO (sin embargo, en el modelo SSO de AWS, los stacks no pueden unirse al dominio).

Inicialmente, vamos a crear una confianza entre bosques de Active Directory administrados y AWS Managed AD.

 

 

Capítulo 1: Relación de confianza entre AWS Managed AD y Active Directory

  1. En el Active Directory del entorno on-premises.

a. En el Active Directory del entorno on-premises, ejecutamos “Active Directory Domains and Trusts” y seleccionamos la opción “Properties“.

 

 

b. En la ventana de propiedades, seleccionamos la opción ”Trusts”.

 

 

c. Seleccionamos la opción “New Trust” y luego en el wizard, “Next”.

 

 

d. Agregamos el nombre del bosque para la confianza. Asegúrese de que el DNS del servidor puede resolver el nombre, ya sea Fully Qualified Domain Name (FQDN) o NETBIOS, del destino. En nuestro escenario, creamos un forwarder condicional con las direcciones IP del DNS de AWS Managed AD.

 

 

e. Seleccionamos la opción ”Forest Trust”:

 

 

f. Seleccionamos la opción “Two-Way”, que sería una confianza bidireccional. Esto se puede ajustar a una confianza en la que sólo Active Directory on-premises confíe en AWS Managed AD.

 

 

g. Seleccionamos la opción de confianza “This domain only”, con el ámbito de autenticación “Forest-wide authentication”.

.

 

 

h. En el paso de contraseña de confianza, vamos a esperar. Iniciaremos la configuración en el servicio de Managed AD.

 

 

2. En AWS Managed AD.

a. En la consola de AWS, vamos a Directory Service y seleccionamos el directorio administrado de Microsoft AD.

 

 

b. Dentro de este directorio, seleccionamos “Networking & Security” y luego la opción “Add trust relationship”.

 

 

c. Configuramos una contraseña y optamos por las mismas opciones de confianza del entorno de origen. En la pestaña de forwader condicional, agregamos las direcciones IP del servidor DNS del entorno on-premises.

 

 

 

3. En el Active Directory del entorno on-premises.

a. Volviendo a Active Directory on-premises, añadiremos la misma contraseña de confianza.

 

 

b. Agregamos un usuario con permisos del entorno de Managed AD para confirmar la confianza.

 

 

c. Una vez que guardemos la configuración, tendremos la confianza creada.

 

 

Capítulo 2: Configuración inicial de AppStream 2.0

Ahora que hemos creado una relación de confianza entre los entornos de AWS Managed AD y Active Directory on-premises, vamos al próximo paso.

  1. En la consola de AWS, seleccionamos el servicio AppStream 2.0.

 

 

2. En “Directory Configs”, seleccionamos la opción “Create Directory Config”.

 

 

3. Creamos el Directory Config seleccionando la estructura de la unidad organizativa (OU) en la que se crearán las instancias de AppStreams 2.0 y la cuenta de servicio con permisos para realizar la creación (AWS Managed AD).

 

 

4. Ahora vamos a crear una imagen usando la opción domain-joined (unida al dominio). Para esto, seleccionamos la opción “Images > Image Builder > Launch Image Builder”.

 

 

5. Seleccionamos la imagen deseada y al final de la página seleccionamos la opción “Next”.

 

 

6. Agregamos un nombre y configuración para vCPU y memoria. Luego seleccionamos “Next”.

 

 

7. Ahora añadiremos la configuración de nuestro dominio en cuestión (AWS Managed AD). Basta seleccionar el Directory Config creado en el paso 3).

 

 

Para que esta imagen pueda unirse al dominio, los grupos de seguridad de AppStream y de AWS Managed AD deben tener los permisos adecuados.

Además, la VPC de esta imagen debe resolver los nombres de todos los bosques  (se recomienda crear un Outbound Endpoint en Amazon Route 53, más información sobre DNS híbrido aquí).

En resumen, necesitamos crear Outbound Endpoints en Route 53 Resolver con una Forwardring Rule para los DNS de cada dominio, por ejemplo:

 

 

Esta regla reenviará las solicitudes de resolución DNS del dominio “domain.corp” a los Domain Controllers de este entorno, que tienen servicios DNS [172.31.41.22 y 172.31.1.110].

 

 

Esta segunda regla las solicitudes de resolución DNS del dominio “Forestb.corp” al Domain Controller de este entorno, que posee el servicio DNS [172.31.43.180].

Si no se realiza la configuración de DNS, la unión al dominio AppStream fallará (normalmente con el código de error 1355 al intentar iniciar sesión).

8. Crearemos una flota de AppStream 2.0 con la misma configuración.

 

 

 

9. Cree un AppStream stack, asignando la flota creada en el paso 8. Utilice el nombre “ExampleStack” ya que vamos a crear reglas de ADFS con este mismo nombre.

 

Capítulo 3: Instalando y Configurando ADFS en un entorno de AWS Managed AD

La federación de usuarios basada en SAML 2.0 es necesaria para el streaming de las aplicaciones domain-joined. Utilizaremos Active Directory Federation Services (ADFS) para que pueda actuar como nuestro proveedor de identidad (IdP) y para que podamos tener funcionalidad domain-joined.

Cuando los usuarios inician sesión con la URL de ADFS, se autentican en AWS Managed AD. Después de la autenticación, el navegador recibe una aserción SAML como respuesta de autenticación de ADFS, que el navegador publica en el extremo SAML entrante de AWS. Después de validar la aserción y los atributos incrustados, se emiten credenciales temporales de seguridad.

Las credenciales temporales se utilizan para crear la dirección URL de entrada. Finalmente, el usuario es redirigido a la sesión de streaming del proveedor de servicios (AppStream 2.0). El siguiente diagrama muestra el proceso:

 

  1. El usuario navega a la URL de la aplicación publicada en ADFS. La página de inicio de sesión solicita autenticación al usuario. Tenga en cuenta que la estación de trabajo puede estar accediendo desde cualquier ubicación a través de Internet y el equipo en cuestión no necesita unirse al dominio.

2. ADFS solicita la autenticación con Active Directory.

3. Active Directory autentica al usuario y devuelve una respuesta de autenticación a ADFS.

4. Con la información de autenticación correcta, ADFS crea una aserción SAML que representa el contexto de seguridad de inicio de sesión del usuario. Debido a que se utilizará un enlace POST, la aserción se firma digitalmente y luego se coloca en un mensaje SAML <Response>.

5. El navegador emite una solicitud HTTP POST para enviar el formulario al endpoint SAML de AWS Sign-In (https://signin.thinkwithwp.com/saml). AWS Sign-In recibe el mensaje SAML, procesa la solicitud y, en consecuencia, autentica al usuario, reenviando el token de autenticación al servicio AppStream 2.0.

6. Usando el token de autenticación, AppStream 2.0 autoriza al usuario y presenta la aplicación en el navegador.

Para este paso del procedimiento, utilizaremos el servicio EC2 para crear nuestro Active Directory Federation Server. Para facilitar la comprensión del escenario, crearemos ADFS en la misma zona de disponibilidad que AWS Managed AD.

Dado que ADFS debe unirse a un dominio, la forma más segura de publicar este servidor será mediante un proxy de aplicación web. Para no prolongar esta publicación, publicaremos ADFS directamente (no recomendado en escenarios de producción).

Tomaremos nota de los prerrequisitos en escenarios multi-forest:

  • El dominio al que se unen los servidores ADFS debe confiar en todos los dominios o bosques que contengan usuarios autenticados en el servicio AD FS.
  • El bosque del que es miembro la cuenta de servicio ADFS debe confiar en todos los bosques de inicio de sesión de usuario.
  • La cuenta de servicio ADFS debe tener permisos para leer atributos de usuario en todos los dominios que contengan usuarios autenticados en el servicio ADFS.

En una instalación estándar de ADFS, éste utiliza dos contenedores que requieren permisos especiales de AD, los que su cuenta administrativa de AWS Microsoft AD no tiene. Para resolver esto, crearemos dos contenedores en nuestra unidad organizativa (OU) para que ADFS los use siguiendo esta documentación.

1. En AWS Managed Active Directory, cree la cuenta de servicio de ADFS.

a. Vaya a la OU de usuarios de AWS Managed AD y seleccione “Nuevo objeto – Usuario”

b. Escriba adfssvc en el cuadro de texto “Nombre completo” y “Nombre de inicio de sesión de usuario”.

c. Haga clic en Siguiente y escriba y confirme una contraseña para el usuario adfssvc.

d. Desactive la casilla de verificación “El usuario debe cambiar la contraseña en el siguiente inicio de sesión”.

e. Haga clic en Siguiente y, a continuación, haga clic en Finalizar.

2. Vamos a crear los contenedores que ADFS utilizará.

a. En un EC2 con acceso a AWS Managed AD, iniciaremos sesión con el usuario domain\admin y generaremos un GUID ejecutando el comando “(New-Guid) .Guid”.

 

 

b. Cree un contenedor denominado ADFS en su OU. La OU se encuentra en la raíz del dominio y tiene el mismo nombre que el nombre NetBIOS que especificó al crear el directorio AWS Microsoft AD [New-ADObject -Name “ADFS” Type Container -Path “OU=yourUninetBIOS, DC=DomainSuffix, DC=DomainRoot”].

 

 

c. Ahora vamos a crear un contenedor dentro de la estructura de ADFS. Esta vez vamos a utilizar el nombre GUID obtenida durante su creación en el paso a) [New-ADObject -Name “GUID” Type Container -Path “CN=ADFS, OU=YourNetBiosName, DC = suDomainSuffix, DC = suDomainRoot”].

 

 

3. En la instancia EC2 creada, instale el servicio Active Directory Federation Services:

 

 

4. Ahora que hemos instalado ADFS, debemos obtener un certificado para ser usado por su servicio ADFS. El certificado de ADFS juega un papel importante en la seguridad de la comunicación entre el adfsserver y los clientes de ADFS, y la protección de los tokens emitidos. AWS recomienda que obtenga un certificado de un proveedor de certificados SSL de confianza. El nombre DNS publicado para el servicio AD FS debe utilizar la dirección IP pública del adfsserver. En este blog, mi servicio ADFS tiene un FQDN de caiocesar.xyz.

 

 

Es importante tener en cuenta que el Nombre común y el Nombre Alternativo del Sujeto (SAN) deben incluir el nombre del servicio de federación que decida utilizar para el servidor ADFS. En mi ejemplo, el nombre es sts.caiocesar.xyz. Para esta publicación de blog, no hemos obtenido un certificado de un proveedor de certificados SSL (estamos utilizando uno auto-firmado para pruebas).

 

 

Copie el valor de huella digital de su certificado público, ya que usaremos esta información en el paso 8.
Para obtener más información sobre los requisitos de ADFS, haga clic aquí.

5. Configuraremos ADFS. Para que este paso funcione, necesitamos configurar ADFS para usar los contenedores creados en el paso 1).

 

$adminConfig = @ {«DKMContainerDN»=»cn=GUID, CN=ADFS, OU=suNetBiosName, DC=suDomainRoot, DC=suDomainRoot»}

 

6. Introduzca las credenciales de la cuenta de usuario predeterminada de ADFS para el usuario ADFSSVC y guárdelas en la variable de secuencia de comandos, $svcCred, recordando que en escenarios multi-forest esta cuenta debe tener permisos para leer atributos de usuario en todos los dominios que contengan usuarios autenticados en el servicio ADFS.

$svccred = (get-credencial)

7. Ahora agregaremos las credenciales de administrador de AWS Microsoft AD y las guardaremos en la variable de script, $LocalAdminCred.

 

$localAdminCD = (get-credencial)

8. Finalmente, configuraremos ADFS, con la información de huella digital de nuestro certificado y las variables de sistema.

 

Install-ADFSFarm -CertificateTumbPrint  <Thumbprint ID> -
FederationServiceName "yourFederationServiceName" -
ServiceAccountCredential $SVCRED -Credential $LocalAdminCD -
OverwriteConfiguration -AdminConfiguration $AdminConfig -
SigningCertificateHumbPrint  <Thumbprint ID> <Thumbprint ID> -
DescryptionCertificateHumbprint

9. Una vez que la instalación se haya realizado correctamente, reinicie ADFS.

 

Capítulo 4: Habilitando la federación de identidades con ADFS 3.0 y Amazon AppStream 2.0

Ahora que hemos terminado la configuración inicial de ADFS, vamos a habilitar la federación de identidades con Amazon AppStream 2.0:

1.Necesitamos el archivo de metadatos del servidor ADFS. El archivo de metadatos es un documento que se utilizará posteriormente para establecer nuestra relación de confianza entre el proveedor de identidades (IdP, ADFS) y el proveedor de servicio (AWS). Para descargar y guardar este archivo, utilizaremos el navegador.

Esto también servirá como la primera prueba para validar que el servicio se está ejecutando y que se puede llegar a la dirección de ADFS a través de Internet, y que no tenemos errores de certificado en la página. Recuerde validar los grupos de seguridad en este paso (HTTPS).

Reemplace el valor de <FQDN_ADFS_SERVER> por el nombre completo del servidor ADFS.

https://<FQDN_ADFS_SERVER>/FederationMetadata/2007-06/FederationMetadata.xml

Para nuestro ADFS, vamos a la dirección: https://sts.caiocesar.xyz/FederationMetadata/2007-06/FederationMetadata.xml y guardamos  el archivo xml.

 

 

2. Ahora iremos a la consola de IAM y crearemos un proveedor de identidad.

 

 

En la página “Configure Provider”, para “Provider Type”, elegimos SAML. Para “Provider Name”, ingresamos el nombre de ADFS y luego cargamos el documento de metadatos previamente descargado.

 

 

También necesitamos el Amazon Resource Name (ARN) del proveedor de identidad (IdP) para configurar las Claim Rules. Para ello, seleccionamos el IdP que acabamos de crear y copiamos el valor al ARN del proveedor. El ARN tiene el siguiente formato:

arn:aws:iam-123123123123:SAML-proveedor/ADFS

3. Ahora tenemos que configurar la política con permisos para AppStream 2.0. Este es el nivel de permisos que los usuarios federados tienen en AWS. En la consola de IAM, elija “Policies, Create Policy” y cree su propia política. Para nuestro ejemplo, seguimos una política de plantilla.




{

  "Version": "2012-10-17",

  "Statement": [

    {

      "Effect": "Allow",

      "Action": "appstream:Stream",

      "Resource": "arn:aws:appstream:REGION-CODE:ACCOUNT-ID-WITHOUT-HYPHENS:stack/STACK-NAME",

      "Condition": {

          "StringEquals": {

              "appstream:userId": "${saml:sub}"           

          }

        }

    }

  ]

}

En esta política, «Action»: «appstream:Stream», es la acción que da a los usuarios de AppStream 2.0 permisos para conectarse a sesiones de streaming en el stack que creamos. SAML Subject NameID, sería el identificador único del usuario que inicia sesión.

Para stacks flotas domain-joined, el valor de NameID para el usuario debe proporcionarse con el formato “domain\username” utilizando sAMAccountName o “username@domain.com” utilizando el valor de userPrincipalName. Si utiliza el formato sAMAccountName, especifique el dominio mediante el nombre NetBIOS o el nombre de dominio (FQDN). Para más información, consulte Uso de Active Directory con AppStream 2.0.

4. En este paso, vamos a crear un rol relacionado con un grupo de Active Directory asignado a los usuarios federados de AppStream 2.0. Para esta configuración, los grupos de Active Directory y las funciones de AWS distinguen entre mayúsculas y minúsculas. Crearemos un rol de IAM llamado “ExampleStack” y un grupo de Active Directory nombrado en formato AWS-AccountNumber-RollenName, por ejemplo AWS-012345678910-ExampleStack.

a. En la consola de IAM, seleccionamos “Roles”, “Create Role”.

 

 

b. Seleccionamos la opción “SAML 2.0 Federation” y, a continuación, la opción “Allow Programmatic and AWS Management Console Access”. El proveedor de identidades creado en el paso 2 debe aparecer como una opción en este paso.

c. En la sección de Permisos, agregue la política creada en el paso 3.

 

 

d. Creamos el rol con el nombre “ExampleStack”. Seguiremos esta plantilla para los pasos restantes.

 

 

e. A continuación, crearemos un grupo de AWS Managed Active Directory en formato AWS-AccountNumber-RolenName utilizando el nombre de la función “ExampleStack” que creamos. Haremos referencia a este grupo de AWS Managed Active Directory en las Claim Rules de ADFS más adelante mediante expresiones regulares.

Para el ámbito del grupo, elegimos la opción “Global” y tipo “Security”.

Nota: Para seguir exactamente este paso a paso, asigne un nombre a su grupo de AWS Managed Active Directory con el formato “AWS-AccountNumber-ExampleStack”, reemplazando AccountNumber por su ID de cuenta de AWS (sin guiones). Por ejemplo:

AWS-012345678910-ExampleStack

 

 

5. Ahora, vamos a crear la relación de confianza entre ADFS y AWS.

a. Vamos a la consola de administración de ADFS.

 

 

b. En “Relying Party Trust”, hacemos clic con el botón derecho y seleccionamos la opción “Add Relying Party Trust”.

 

 

c. Seleccione la opción “Claims Aware” y, a continuación, “Start”.

 

 

d. Agregue la URL de AWS en el campo “Federation metadata address (hostname or URL)” (https://signin.thinkwithwp.com/static/saml-metadata.xml).

 

 

e. Dale un nombre a la relación de confianza.

 

 

 

f. Seleccione la opción de Access Control Policy. Si tiene un RADIUS para MFA, esta opción se puede cambiar.

 

 

g. Revise la configuración y seleccione la opción “Next” y “Close”.

 

 

h. Ahora abriremos las propiedades de Relying Party Trust, eliminaremos la opción “Monitor Relying Party” de la pestaña “Monitoring” y agregaremos la URL https://signin.thinkwithwp.com/saml al “Relying Party Identifier” para que el Relying Party no se actualice automáticamente.

 

 

6. Creando Claim Rules

En esta sección, creamos Claim Rules, que identificarán cuentas, definirán atributos LDAP, obtendrán grupos de Active Directory y los asociarán con el rol creado anteriormente.

Haga clic con el botón derecho en la confianza recién creada, seleccione la opción “Edit Claim Rules” y luego “Add Rule”.

a. Regla 1: NameID.

Esta regla informa a ADFS el tipo de Claim entrante que se espera y cómo enviar el Claim a AWS. Por ejemplo, ADFS recibe el UPN y lo identifica como el ID de nombre cuando se reenvía a AWS.

Claim rule template: Transform an Incoming Claim

Configure Claim Rule values:

Claim Rule Name:  Name ID

Incoming Claim Type:  UPN

Outgoing Claim Type:  Name ID

Outgoing name ID format:  Persistent Identifier

 

b. Regla 2: RolesSessionName.

Esta regla configurará un identificador único para el usuario. En este caso, usaremos el valor de Email-Address. Por lo tanto, los usuarios deben tener atributos de correo.

Claim rule template: Send LDAP Attributes as Claims

Configure Claim Rule values:

Claim rule name:  RoleSessionName

Attribute store:  Active Directory

LDAP Attribute:  E-Mail-Addresses

Outgoing Claim Type:  https://thinkwithwp.com/SAML/Attributes/RoleSessionName

 

 

*Algunos administradores (para facilitar la gestión de claims) utilizan otros valores, como MSDSConsistencyGUID (EmployeeID, etc.). Estos valores también funcionan siempre que sean únicos en la organización y respeten los parámetros de SessionRoleName, correspondiente a [a-za-z_0-9+=, .@-] {2,64} longitud máxima de 64 caracteres.

c. Regla 3: Grupos de Active Directory

Esta regla consulta Active Directory y devuelve los grupos a los que el usuario pertenece.

Claim rule template: Send Claims Using a Custom Rule

Configure Claim Rule values:

Claim Rule Name:  Get Active Directory Groups

Custom Rule: c:[Type == «http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname», Issuer == «AD AUTHORITY»] => add(store = «Active Directory», types = («http://temp/variable»), query = «;tokenGroups;{0}», param = c.Value);

 

d. Regla 4 — Prefijo

Esta regla convierte el valor del grupo de Active Directory empezando por el prefijo “AWS-AccountNumber” en funciones conocidas por AWS. Para esta regla, necesitamos el ARN de IdP de AWS que mencionamos anteriormente.

Claim rule template: Send Claims Using a Custom Rule

Configure Claim Rule values:      

Claim Rule Name:  Roles

Custom Rule:

c:[Type == «http://temp/variable», Value =~ «(?i)^AWS-«]

 => issue(Type = «https://thinkwithwp.com/SAML/Attributes/Role», Value = RegExReplace(c.Value, «AWS-012345678910-«, «arn:aws:iam::012345678910:saml-provider/ADFS01,arn:aws:iam::012345678910:role/»));

* Reemplace arn:aws:iam::012345678910:SAML-Provider/ADFS01 por el ARN de su IdP.

** Reemplace 012345678910 por el ID de su cuenta de AWS.

 

 

7. Activando RelayState y Forms Authentication.

Por defecto, ADFS 3.0 no tiene RelayState activado. AppStream 2.0 usa RelayState para dirigir a los usuarios a su stack. Si está ejecutando ADFS versión 4.0, no haga lo siguiente.

En el servidor ADFS, accedemos al servicehostconfig y hacemos una copia de seguridad del archivo antes de cualquier cambio:

%systemroot%\adfs\Microsoft.IdentityServer.ServiceHost.exe.config

Dentro del archivo (abierto con permisos administrativos), en la sesión “microsoft.identityServer.web”, agregamos la línea

“<useRelayStateForIdpInitiatedSignOn enabled=»true» />“

 

 

8. Versiones de ADFS 4.0: en lugar de personalizar el archivo anterior, simplemente ejecute los comandos siguientes.

rties -EnableIdPInitiatedSignonPage $true

Set-AdfsProperties -EnableRelayStateForIdpInitiatedSignOn $true

 

9. Reiniciar ADFS

net stop adfssrv
net start adfssrv

Capítulo 5: Creación de RelayState en AppStream 2.0

  1. Utilizaremos la planilla creada en este blog para generar la URL.

 

2. Agregaremos un usuario de prueba a nuestro grupo ExampleStack.

 

 

3. Acceda a la URL externamente con este usuario.

 

  1. Después de la autenticación, el usuario debe ser redirigido a la consola de AppStreams 2.0.

 

4. Después de la autenticación, el usuario debe ser redirigido a la consola AppStreams 2.0.

 

 

5. Podemos añadir nuevos stacks y crear una permisos granulares. Por ejemplo, si creamos un nuevo grupo en AWS Managed AD, con el formato “AWS-AccountNumber-ExampleStack2”, reemplazando AccountNumber por su ID de cuenta de AWS (sin guiones) y posteriormente creando el Rol de AWS IAM de forma correcta, tendremos acceso a un nuevo stack.

Nuevo stack

 

AWS Managed AD

 

 

Rol de AWS IAM

 

 

Política de AWS IAM

 

 

Luego probaremos el inicio de sesión con la URL, que también se cambiará por el hecho de que el acceso se hará en otro stack.

 

 

El usuario tendrá la opción de seleccionar el stack para iniciar sesión.

 

 

Capítulo 6: AppStream 2.0 y Multi-Forest

Ahora que tenemos nuestro entorno en funcionamiento, vamos a configurar la parte de multi-forest.

  1. Vaya al bosque de destino (forestB.corp) y seleccione la opción “Delegate Control”.

 

 

2. Agregue el permiso de lectura a la service account de ADFS (bosque de origen) para todos los objetos del bosque de destino.

 

 

3. Crearemos el grupo del Stack tal como lo hicimos antes (plantilla de nombre).

 

 

4 . Acceda usando un miembro de este grupo, a través de la URL personalizada. Usted tendrá acceso al stack través de Internet —

 

 

¡Felicitaciones! Ha iniciado sesión con un usuario de un bosque externo en un stack de AppStream 2.0 de un bosque gestionado por AWS Managed AD.

En este post, discutimos la implementación e integración de AppStream 2.0 en un escenario multi-forest de cero a cien. Para administrar este modelo en Producción:

  • Utilizamos un certificado público para ADFS.
  • Utilizamos una ADFS farm, para tener tolerancia a fallas.
  • Utilizamos dos servidores con el rol de proxy de aplicación web (WAP) para publicar ADFS en Internet. Recordando que la topología de red que tenemos es ADFS en la subred privada comunicándose con WAP en la subred púbica a través de HTTPS.
  • Publicamos los WAP a través de AWS Network Load Balancer, con los protocolos HTTPS y TCP:49443 para la autenticación de certificados.
  • Para infraestructuras masivas (más de 5 servidores ADFS), las empresas necesitan cambiar el modelo de base de datos de ADFS (Windows Internal Database) para utilizar una base de datos SQL.
  • Hay varias formas de implementar MFA en este escenario. Ya sea a nivel ADFS de autenticación personalizada/servicios externos o a nivel de Active Directory, a través de AWS Managed AD con integración RADIUS.
  • Implementado Group Policy Opjects para más funcionalidades.

 

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

 

 

Sobre los autores

 

Caio Ribeiro Cesar actualmente trabaja como arquitecto de soluciones especializado en tecnología de Microsoft en la nube de AWS. Comenzó su carrera profesional como administrador de sistemas, que continuó durante más de 13 años en áreas como seguridad de la información, identidad en línea y plataformas de correo electrónico corporativo. Recientemente se hizo fanático de la computación en la nube de AWS y ayuda a los clientes a aprovechar el poder de la tecnología de Microsoft en AWS.

 

 

 

Ivan Vargas es un arquitecto de soluciones en AWS enfocado en compañías en el segmento digital, que han nacido o tienen la mayoría de sus operaciones en la nube. Funciona ayudando a los clientes a diseñar e influir en soluciones basadas en los servicios de AWS. Con más de 15 años de experiencia en arquitectura, desarrollo web y gestión de TI, Ivan ha trabajado en varios proyectos de desarrollo y modernización de aplicaciones.

 

 

 

Sobre el revisor

Rodrigo Alarcón es Arquitecto de Soluciones Senior en Amazon Web Services, basado en Santiago, Chile.