Escenarios SAML avanzados y uso correcto de cip_forest y cip_domain en la aserción SAML
Este artículo describe las configuraciones SAML avanzadas de Citrix Cloud o Workspace que implican múltiples bosques y dominios de Active Directory conectados. Este artículo está dirigido a grandes empresas con implementaciones complejas de AD y debe ser implementado por administradores de Citrix Cloud, IdP y AD con nivel de arquitecto. El uso más común de esta configuración SAML avanzada es en escenarios de fusiones y adquisiciones, donde una gran empresa se forma a partir de muchas organizaciones más pequeñas con diferentes infraestructuras de AD, múltiples bosques y diferentes poblaciones de usuarios de backend de AD con distintos UPN. La autenticación condicional también suele ser necesaria en escenarios de fusiones y adquisiciones.
-
Las aserciones opcionales
cip_forestycip_domainte dan, como administrador de Citrix Cloud, un mayor control sobre qué Citrix Cloud Connectors se utilizan para buscar cuentas de usuario de backend de AD durante la autenticación SAML. Citrix Cloud con SAML admite muchos casos de uso avanzados de asignación de cuentas, que no son posibles con otros métodos de autenticación OIDC federados de Citrix Cloud, como Okta IdP o Entra ID IdP. -
Requisitos previos
- Usa el flujo SAML predeterminado de Citrix Cloud, que utiliza identidades de AD para autenticar al usuario final.
- Una comprensión exhaustiva de la infraestructura de tu bosque o dominio de AD y de dónde se encuentran las identidades de los usuarios finales de Workspace.
- Citrix Cloud Connectors unidos al bosque y dominio de AD correctos y unidos al nivel de dominio de AD adecuado.
- Conocimiento de las ubicaciones de recursos existentes y de los Citrix Cloud Connectors que ya están configurados en tu inquilino de Citrix Cloud.
- Múltiples bosques de AD conectados a Citrix Cloud no deben tener ninguna relación de confianza de Active Directory entre ellos.
- Una comprensión de lo que significa una identidad de usuario de frontend (Entra ID, Okta, Duo) y de backend (AD).
- Las identidades de usuario de frontend y backend deben estar vinculadas a través de UPN coincidentes. No se admite vincular un par de identidades de usuario de frontend y backend que NO tengan UPN coincidentes.
- Una comprensión de dónde reside cada sufijo UPN dentro de Active Directory y si un sufijo UPN particular es ambiguo y existe en múltiples bosques de AD conectados.
- Los VDA de DaaS deben estar unidos al dominio de AD.
- Las aplicaciones y escritorios de DaaS deben publicarse para identidades de AD.
- Los grupos universales de AD son obligatorios al asignar recursos de grupos de entrega a grupos de AD en DaaS.
-
Los grupos de entrega de DaaS deben configurarse para “Restringir el uso de recursos” y deben asignarse a los grupos universales de AD correctos. NO se admite el uso de “Permitir que cualquier usuario autenticado use recursos” dentro de los grupos de entrega de DaaS.
-
Servidores FAS unidos al bosque de AD correcto y unidos al dominio en el nivel de AD adecuado. Los servidores FAS son necesarios para el inicio de sesión único (SSON) en VDA unidos al dominio de AD durante los lanzamientos de DaaS.
- También es posible que debas implementar la autenticación condicional si tienes varias aplicaciones SAML y necesitas una aplicación SAML por cada bosque de AD conectado. Cada aplicación SAML podría requerir un conjunto diferente de valores para
cip_forestycip_domainen escenarios de fusiones y adquisiciones.
Preguntas frecuentes
Si envío cip_sid en la aserción SAML, ¿necesito enviar también las aserciones opcionales cip_forest y cip_domain?
No. Si tu aplicación SAML está configurada para enviar la aserción cip_sid y esta se incluye en la aserción SAML, Citrix Cloud siempre podrá identificar correctamente en qué bosque y dominio se encuentra el usuario de backend de AD. cip_forest y cip_domain no son necesarios.
Importante:
- Escenarios SAML donde no es posible enviar
cip_siden la aserción SAML y que podrían requerir el uso decip_forestycip_domainen su lugar.- Usuarios de frontend que contienen un SID incorrecto, que no coincide con el SID del usuario de backend de AD asignado dentro de los grupos de entrega de DaaS.
- Usuarios de frontend que no tienen ningún SID incrustado, como los usuarios nativos de Okta, Entra ID o Duo que no se crearon en el IdP a través de herramientas de importación de AD.
¿Qué es un sufijo UPN implícito de AD?
El UPN implícito es creado automáticamente por Active Directory y se basa en el sAMAccountName del usuario y el nombre DNS del bosque. Los UPN implícitos son siempre únicos dentro de un bosque de AD porque se derivan del sAMAccountName y del nombre DNS del dominio, que son únicos dentro del bosque de AD. Por ejemplo, @rootforestdomain.local.
¿Qué es un sufijo UPN explícito (ALT) de AD?
Un sufijo UPN explícito es un nombre de dominio personalizado agregado por los administradores de AD en Dominios y Confianzas de Active Directory. Por ejemplo, @rootforestdomain.local.
Importante:
Windows AD PowerShell te permite crear usuarios de AD con cualquier sufijo UPN que especifiques, incluso si ese sufijo UPN no existe dentro de tu bosque de AD. El sufijo UPN alternativo que deseas usar DEBE existir dentro del bosque de AD, ya que los Citrix Cloud Connectors dependen de esta lista para buscar las cuentas de usuario de backend. Si el sufijo UPN alternativo no está configurado en el bosque de AD como se muestra en la captura de pantalla anterior, Citrix Cloud no podrá hacer coincidir tu identidad de frontend con una cuenta de AD de backend adecuada.
¿Qué es la ambigüedad de UPN y por qué es un problema para Citrix Cloud y DaaS?
La ambigüedad de UPN es una situación que puede surgir si duplicateuser@domain.com existe en 2 o más bosques de AD conectados a Citrix Cloud. El sufijo UPN @domain.com por sí solo no se puede usar para determinar el usuario de backend de AD correcto cuando existen dos versiones de duplicateuser@domain.com. Esto puede hacer que los recursos de DaaS no se enumeren en absoluto, o que se muestren recursos de DaaS incorrectos publicados mediante VDA unidos al dominio de AD dentro del espacio de trabajo.
¿Por qué los grupos universales de AD son un requisito?
Los grupos universales de AD se almacenan en el Catálogo Global (GC), lo que los hace visibles para todos los controladores de dominio en todo el bosque. Esto permite utilizarlos para asignar permisos a recursos ubicados en cualquier dominio dentro del mismo bosque.
Importante:
El uso de grupos universales de AD es un requisito para todas las configuraciones SAML, no solo para las configuraciones avanzadas que involucran
cip_forestycip_domain. El uso de otros tipos de grupos de AD, como los globales, puede provocar errores en la enumeración de recursos en Workspace.
-
Te recomendamos que leas este artículo de Microsoft sobre el ámbito de los grupos de AD.
-
¿Por qué no se recomienda el uso de “Permitir que cualquier usuario autenticado use recursos” en los grupos de entrega de DaaS?
Configurar Permitir que cualquier usuario autenticado use recursos hará que los recursos publicados mediante VDA unidos al dominio de AD aparezcan en Workspace para identidades de usuario de AD que no se encuentran en el mismo dominio y bosque. El lanzamiento de recursos desde VDA unidos al dominio en el Bosque 2 utilizando una identidad de usuario final de AD de Workspace en el Bosque 1 no tendrá éxito.
¿Puedo enviar solo cip_forest o solo cip_domain en la aserción SAML?
No. Si deseas especificar un bosque de AD y un contexto de dominio particulares para la búsqueda de usuarios de backend, debes proporcionar ambas aserciones opcionales en la aserción SAML.
Al especificar un valor para cip_forest, ¿qué sufijo UPN debo usar?
Se debe usar el sufijo UPN implícito para el bosque de AD. No especifiques un valor de un sufijo UPN ALT que se haya agregado al bosque de AD dentro de la declaración cip_forest. Esto se debe a que existen topologías de AD donde el mismo sufijo UPN ALT podría haberse agregado a más de un bosque de AD conectado a Citrix Cloud. El sufijo UPN implícito y el DN nunca son ambiguos para Citrix Cloud, a menos que dos bosques de AD diferentes con el mismo DN, como DC=duplicate,DC=com, estén conectados a Citrix Cloud (un escenario poco probable).
¿Cuándo deben ser los valores de cip_forest y cip_domain iguales o diferentes entre sí?
Escenario 1: Tus Citrix Cloud Connectors están unidos al dominio a nivel de raíz del bosque y los usuarios de la cuenta de AD de backend residen dentro del dominio raíz en el bosque de AD conectado.
cip_domain y cip_forest deben tener el mismo valor.
cip_forest = "forestrootdomain.com"
cip_domain = "forestrootdomain.com"
Escenario 2: Tus Citrix Cloud Connectors están unidos a un dominio secundario en la jerarquía del bosque de AD. Los usuarios de AD de backend existen dentro de “childdomain.forestrootdomain.com” en tu bosque de AD.
cip_domain y cip_forest deben tener valores diferentes.
cip_forest = "forestrootdomain.com"
cip_domain = "childdomain.forestrootdomain.com"
¿Puedes codificar los valores de cip_forest y cip_domain directamente en la aserción SAML?
Sí, pero solo si toda la población de usuarios de AD de backend, que están asignados a recursos DaaS, reside en el mismo bosque de AD. Codificar los valores de cip_forest y cip_domain directamente requiere que cada usuario de frontend tenga sus cuentas de AD de backend correspondientes en el mismo bosque y dominio de AD.
¿Puedes especificar valores diferentes para cip_forest y cip_domain en la aserción SAML de forma dinámica?
Sí, si tu proveedor SAML lo permite a través de reglas de transformación de notificaciones. Si tienes diferentes poblaciones de usuarios de frontend con distintos sufijos UPN, es posible especificar los valores de cip_forest y cip_domain de forma dinámica utilizando condiciones de conmutación como la pertenencia a grupos. Esto es posible en las aplicaciones SAML de Entra ID y también podría serlo en otros IdP SAML que admitan reglas de transformación de notificaciones.
¿Dónde debes colocar tus servidores FAS para que el inicio de sesión único (SSON) en los VDA unidos al dominio de AD se realice correctamente?
Los servidores FAS deben estar unidos al dominio y configurados dentro de cada uno de los bosques de AD de backend donde residen las cuentas de AD de backend. Se recomienda que unas tus servidores FAS al dominio raíz del bosque de AD.
Topologías de AD donde cip_forest y cip_domain son necesarios en la aserción SAML
Escenario 1: El UPN del usuario final de SAML es ambiguo y existe en varios bosques de AD conectados a Citrix Cloud
-
El inquilino de Citrix Cloud tiene dos o más ubicaciones de recursos y varios bosques o dominios de AD conectados a Citrix Cloud.
- ResourceLocation1 contiene Citrix Cloud Connectors, que están unidos al dominio
AD forestrootdomain1.coma nivel de raíz del bosque. - ResourceLocation2 contiene Citrix Cloud Connectors que están unidos al dominio
AD forestrootdomain2.coma nivel de raíz del bosque. -
forestrootdomain1.comyforestrootdomain2.comtienen el mismo sufijo UPN@domain.com. - También pueden existir usuarios duplicados dentro de
forestrootdomain1.comyforestrootdomain2.comcon el mismo UPNduplicateuser@domain.compero con diferentes valores de SID y OID.
Problema: el intento de buscar la cuenta de AD de backend correcta utilizando username@duplicatesuffix.com no siempre devuelve el usuario de AD de backend correcto debido a la ambigüedad del UPN. Citrix Cloud no puede determinar qué bosque de AD y Citrix Cloud Connectors usar, por lo que podrían mostrarse recursos DaaS incorrectos en Workspace o no se devolverían recursos DaaS en absoluto.
Solución: configura dos aplicaciones SAML diferentes, una para cada bosque de AD conectado, e incluye los valores cip_domain y cip_forest correspondientes para el bosque de AD correcto en la aserción SAML. Esto proporciona a Citrix Cloud el contexto adicional del bosque y el dominio para asegurar que el usuario de AD de backend correcto sea “buscado” cuando username@duplicatesuffix.com existe en varios bosques conectados.
Aplicación SAML 1 forestrootdomain1.com:
Aplicación SAML 2 forestrootdomain2.com:
Asigna correctamente los dos grupos de entrega de DaaS utilizando los grupos de AD de backend correctos.
Escenario 2: Cloud Connectors unidos a nivel de dominio secundario y usuarios de Workspace a nivel de dominio secundario
El inquilino de Citrix Cloud tiene una ubicación de recursos que contiene dos Citrix Cloud Connectors, los cuales están unidos al dominio a nivel de “childdomain.forestrootdomain.com” en lugar del nivel recomendado “forestrootdomain.com”. Los usuarios de Workspace existen dentro del dominio secundario childdomain.forestrootdomain.com. Los usuarios están configurados para usar el sufijo UPN del dominio raíz, como username@forestrootdomain.com.
Problema: Citrix Cloud realiza la búsqueda de la cuenta de AD utilizando “forestrootdomain.com”, que no coincide con un dominio de AD conectado.
Solución: Especifica el contexto del dominio secundario en la aserción SAML para que el usuario de la cuenta de AD sea “buscado” desde el contexto correcto del dominio secundario y el bosque de AD.
cip_forest = forestrootdomain.com
cip_domain = childdomain.forestrootdomain.com
