Blog de Amazon Web Services (AWS)

Integración de AppStream 2.0 con AWS Managed Active Directory en escenarios multiforest, 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 de streaming de aplicaciones administrado. Usted puede administrar de forma centralizada las aplicaciones de escritorio en AppStream 2.0 y las entregas de forma segura a cualquier ordenador. En este modelo, podemos escalar fácilmente a cualquier número de usuarios en todo el mundo sin la 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 administrar de forma centralizada las aplicaciones en AppStream 2.0 en lugar de administrar las instalaciones y actualizaciones en cada equipo de usuario.

El servicio Amazon AppStream 2.0 también establece conexiones a Active Directory, red, almacenamiento en la nube y recursos compartidos de archivos. Los usuarios acceden a las aplicaciones utilizando sus credenciales existentes, y las directivas de seguridad actuales administran el acceso. En esta publicación, analizaremos cómo integrar el Amazon AppStream con Active Directory en un escenario de confianza multiforest de AD administrado con Active Directory en el entorno local.

La plantilla de publicación “cero a cien” es diferente de las publicaciones 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 federación entre forests (AWS Managed AD y Managed Domain Controllers [AD OnPremises];
  2. Configurar AppStreams 2.0 con una flota de instancias unidas al dominio;
  3. Configurar ADFS 3.0 con permisos de cuenta especiales para AWS Managed AD, que sirve como proveedor de identidad (IdP) para AppStreams 2.0.
  4. Habilitar la federación de identidades con AD FS 3.0 (o ADFS 4.0) y Amazon AppStream 2.0

 

 

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

Un Active Directory forest (bosque de AD) es el contenedor más lógico de una configuración de Active Directory que contiene dominios, usuarios, equipos y directivas de grupo. El modelo de confianza multiforest 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.

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

Los Servicios de federación de Active Directory (ADFS) habilitarán la administración de identidades y accesos federados en este entorno multibosque, ampliando la capacidad de utilizar la funcionalidad de inicio de sesión único para Amazon AppStream, lo que permitirá a los clientes, socios y proveedores aprovechar un usuario simplificado durante el acceso.

En Amazon Appstream, una flota consiste en instancias de streaming que ejecutan la imagen especificada. Una “stack” consta de una flota asociada, políticas de acceso de usuarios y configuraciones de almacenamiento. El Fleet Auto Scaling le permite cambiar automáticamente el tamaño de su flota para que coincida con la oferta de instancias disponibles a 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 a un tamaño fijo.

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

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

Inicialmente, vamos a crear una confianza entre bosques de Active Directory administrados y Active Directory administrado.

 

 

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

1. Entorno local de Active Directory.

a. En el Active Directory del entorno local, 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 asistente, “Next”.

 

 

d. Se ha agregado el nombre del bosque a la confianza. Asegúrese de que el DNS del servidor puede resolver el nombre en el nombre de dominio completo o NETBIOS del destino. En nuestro escenario, hemos creado un reenviador condicional con direcciones IP DNS de AD administradas.

 

 

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

 

 

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

 

 

g. Seleccionamos la opción solo para el dominio seleccionado con el ámbito de autenticación “This domain only” / “Forest-wide authentication”.

 

 

h. En el paso de contraseña de confianza, esperaremos e iniciaremos la configuración en el servicio de Active Directory administrado.

 

 

2. AWS Managed AD.

a. En la consola de AWS, iremos al servicio de directorio y seleccionaremos el directorio administrado de Microsoft AD.

 

 

b. Dentro de este directorio, seleccionamos “Redes y seguridad” y luego la opción “Agregar relación de confianza”.

 

 

c. Hemos configurado una contraseña y hemos optado por las mismas opciones de confianza que el entorno de origen. En la pestaña Forwader condicional, agregamos las direcciones IP DNS para el entorno local.

 

 

 

3. Entorno local de Active Directory.

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

 

 

b. Agregamos un usuario con permisos del entorno de AD administrado 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 anuncios gestionados de AWS y Active Directory local, demos el siguiente paso.

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

 

 

2. En “Configs de directorio”, seleccionamos la opción “Crear configuración de directorio”.

 

 

3. Hemos creado 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 unida al dominio. Para hacer esto, seleccionamos la opción “Imágenes > Generador de imágenes > Iniciar Creador de imágenes”.

 

 

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

 

 

6. Agregamos un nombre y configuración para vCPU y memoria y luego seleccionamos “Siguiente”.

 

 

7. Ahora añadiremos la configuración de nuestro dominio en cuestión (AWS Managed AD). Simplemente seleccione la configuración del directorio creada en el paso 3).

 

 

Para que esta imagen pueda unirse, los grupos de seguridad de AppStream y AWS Managed AD deben tener la autorización adecuada.

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

En resumen, necesitamos crear extremos salientes en Route 53 resolver con Regla de reenvío para el DNS de cada dominio, por ejemplo:

 

 

Esta regla reenviará DNS desde el dominio “domain.corp” a controladores de dominio en este entorno, que tienen servicios DNS [172.31.41.22 y 172.31.1.110].

 

 

Esta segunda regla reenviará DNS desde el dominio “Forestb.corp” al controlador de dominio de este entorno, que posee el servicio DNS [172.31.43.180].

Si no se realiza el paso 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 una AppStream stack, asignando la flota creada en el paso 8). Utilice el nombre “ExampleStack” ya que vamos a crear reglas ADFS con el mismo nombre.

 

Capítulo 3, Instalación y configuración de ADFS en un entorno de AD administrado de AWS

La federación de usuarios basada en SAML 2.0 es necesaria para las aplicaciones de streaming que están unidas a un dominio. Utilizaremos los Servicios de federación de Active Directory (ADFS) para que pueda actuar como nuestro proveedor de identidad (IdP) y para que podamos tener funcionalidad unida al dominio.

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 ADFS, que el navegador publica en el extremo SAML entrante de AWS. Las credenciales de seguridad temporales se emiten después de la validación de aserción y los atributos incrustados.

Las credenciales temporales se utilizan para crear la dirección URL entrante. 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 a 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 en el punto final SAML de inicio de sesión de AWS (https://signin.aws.amazon.com/saml). AWS Sign-In recibe SAML, procesa la solicitud y, en consecuencia, autentica al usuario reenvía 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 al navegador.

 

Para este paso del procedimiento, utilizaremos el servicio EC2 para crear nuestro servidor de federación de Active Directory. 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 requisitos previos en escenarios multiforestales:

  • El dominio al que se unen los servidores ADFS debe confiar en todos los dominios o bosques que contienen 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 contienen usuarios autenticados en el servicio ADFS.

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

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

a. Vaya a la unidad organizativa de AWS Managed AD Users 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 AD administrado, iniciaremos sesión con el dominio de usuario\ admin y generaremos un GUID ejecutando el comando “(New-Guid) .Guid”.

 

 

b. Cree un contenedor denominado ADFS en su unidad organizativa. La unidad organizativa 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 del marco ADFS. Esta vez vamos a utilizar el nombre GUID recogido en el paso a) para crear [New-ADObject -Name “GUID” Type Container -Path “CN=ADFS, OU=YourNetBiosName, DC = suDomainSuffix, DC = suDomainRoot”].

 

 

3. En EC2 creado, instale el servicio Servicios de federación de Active Directory:

 

 

4. Ahora que hemos instalado ADFS, debemos obtener un certificado para su uso por su servicio ADFS. El certificado ADFS juega un papel importante en la seguridad de la comunicación entre los clientes adfsserver y 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 de asunto (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 un autofirmado para las pruebas).

 

 

 

Copie el valor de huella digital de su certificado público, ya que usaremos esta información en el paso 4).
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 cuenta de usuario ADFS predeterminadas para el usuario ADFSSVC y guárdelo en la variable de secuencia de comandos, $svcCred, recordando que en escenarios de varios bosques, esta cuenta debe tener permisos para leer atributos de usuario en todos los dominios que contienen 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 ThumbPrint de nuestro certificado y 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, Habilitación de 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 servicios (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 ADFS a través de Internet y que no tenemos errores de certificado en la página. Recuerde validar 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 “Configurar proveedor”, para “Tipo de proveedor”, elegimos SAML. Para Nombre del proveedor, ingresamos el nombre de ADFS y luego cargamos el documento de metadatos previamente descargado.

 

 

También necesitamos el nombre de recurso de Amazon (ARN) del proveedor de identidad (IdP) para configurar las reglas de notificación. 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 tienen los usuarios federados en AWS. En la consola de IAM, elija “Directivas, Crear directiva” 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 la stack que creamos. Para SAML Subject NameID, sería el identificador único del usuario que inicia sesión.

Para las stacks con flota unida al dominio, el valor de NameID para el usuario debe proporcionarse con el formato “domain\ username” utilizando SamAccountName o “usuário@domínio.com name” utilizando el valor de UserPrincipalName. Si utiliza el formato SAMAccountName, especifique el dominio mediante el nombre NetBIOS o el nombre de dominio (FQDN). Para obtener 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 denominado en formato AWS-AccountNumber-RollenName, por ejemplo AWS-012345678910-ExampleStack.

a. En la consola de IAM, seleccionamos “Roles”, “Crear rol”.

 

 

b. Seleccionamos la opción “SAML 2.0 Federation” y, a continuación, la opción “Permitir acceso programático y AWS Management Console”. El proveedor de identidades creado en el paso 2) debe aparecer como una opción en este paso.

c. En la ficha Permisos, agregue la directiva creada en el paso 3).

 

 

d. Creamos el desplazamiento 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 reglas de reclamación de ADFS más adelante mediante expresiones regulares.

Para el ámbito del grupo, elegimos la opción “global” y escribimos “seguridad”.

Nota: Para seguir exactamente este paso a paso, asigne un nombre al grupo de Active Directory administrado de AWS 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 “Confianza de parte de confianza”, hacemos clic con el botón derecho y seleccionamos la opción “Agregar confianza de parte de confianza”.

 

 

c. Seleccione la opción “Reclamaciones Aware” y, a continuación, “Iniciar”.

 

 

d. Agregue la URL de AWS en el campo Nombre de host de la dirección de metadatos de la federación o URL ( https://signin.aws.amazon.com/static/saml-metadata.xml).

 

 

e. Dale un nombre al relationship trust.

 

 

 

f. Seleccione la opción Directiva de control de acceso. Si tiene un RADIUS para MFA, esta opción se puede cambiar.

 

 

g. Revise la configuración y seleccione la opción “Siguiente” y “Cerrar”.

 

 

h. Ahoraabriremos las propiedades de confianza de parte de confianza, eliminaremos la opción “Supervisar parte de confianza” de la pestaña “Supervisar” y agregaremos la URL https://signin.aws.amazon.com/saml al “Identificador de parte de confianza” para que la parte de confianza no se actualice automáticamente.

 

 

6. Creación de reglas de notificación.

En esta sección, creamos reglas de reclamación, que identificarán cuentas, establecerá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 “Editar reglas de notificación” y luego “Agregar regla”.

a. Regla 1: ID de nombre.

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

Plantilla de regla de reclamación: Transformar una reclamación entrante
Establecer valores de regla de notificación:
Nombre de regla de notificación:  ID de nombre
Tipo de reclamo entrante:  UPN
Tipo de reclamación saliente:  ID de nombre
Formato de ID de nombre saliente:  Identificador persistente
Pasar a través de todos los valores de reclamación:  seleccionado

 

 

b. Regla 2: RolesSessionName.

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

Plantilla de regla de reclamación: Enviar Atributos LDAP como Reclamaciones
Establecer valores de regla de notificación:
Nombre de la regla de reclamación:  RolessionName
Almacén de atributos:  Directorio Activo
Atributo LDAP:  Direcciones de correo electrónico
Tipo de reclamación saliente: https://aws.amazon.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 en los que el usuario forma parte.

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://aws.amazon.com/SAML/Attributes/Role”, Value = RegExReplace(c.Value, “AWS-012345678910-“, “arn:aws:iam::012345678910:saml-provider/ADFS01,arn:aws:iam::012345678910:role/”));

 

* Cambia el arn:aws:iamde 012345678910:SAML-Provider/ADFS01 a tu IdP ARN.
** Cambie el 012345678910 a su ID de cuenta de AWS.

 

 

7. Habilitar la autenticación RelayState y formularios.

 

De forma predeterminada, ADFS 3.0 no tiene RelayState habilitado. AppStream 2.0 usa RelayState para dirigir a los usuarios a su pila. 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.

Set-AdfsProperties -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 spreadsheet 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.

 

 

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

 

 

5. Podemos añadir nuevas stacks y crear una granularidad de permiso. Por ejemplo, si creamos un nuevo grupo en AWS Managed AD, nombrando este grupo de AWS Managed Active Directory con el formato “AWS-AccountNumber-ExampleStack2”, reemplazando AccountNumber por su ID de cuenta de AWS (sin guiones) y posteriormente creando IAM correctamente, tendremos acceso a una nueva pila.

Nueva pila

 

AD administrado por AWS

 

 

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 otra pila.

 

 

El usuario tendrá la opción de seleccionar la pila 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 multi-bosque.

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

 

 

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

 

 

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

 

 

4 . Acceda a un miembro de este grupo a través de la URL personalizada. Usted tendrá acceso a la pila a través de Internet

 

 

¡Bien hecho! Ha iniciado sesión con un usuario de un bosque externo de un AppStream de un bosque de dominio gestionado por AWS Managed AD.

En este post, discutimos la implementación e integración de AppStream 2.0 en un escenario multi-bosque de cero a uno. Para administrar esta plantilla 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 chateando con WAP en la subred púbica en https.
  • Publicamos los WAP a través de AWS Network Load Balancer, los protocolos https y TCP:49443 para la autenticación de certificados.
  • Con una infraestructura masiva (+5 servidores ADFS), las empresas necesitan cambiar el modelo de base de datos de Windows Internal Database (ADFS) para utilizar una base de datos SQL.
  • Hay varias formas de implementar MFA en este escenario. Ya sea en el nivel ADFS de autenticación personalizada/servicios externos o en el nivel de Active Directory a través de AWS Managed AD con integración RADIUS.
  • Hemos implementado objetos de directiva de grupo para obtener más funcionalidad.

 


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.