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 de la tienda que implican múltiples bosques y dominios de Active Directory conectados. Este artículo está destinado a grandes empresas con implementaciones complejas de AD y debe ser implementado por administradores de Citrix Cloud, IdP y AD de nivel arquitecto. El uso más común de esta configuración SAML avanzada se da 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 diferentes UPN. La autenticación condicional también suele ser necesaria en escenarios de fusiones y adquisiciones.
Las notificaciones opcionales cip_forest y cip_domain otorgan al administrador de Citrix Cloud un mayor control sobre qué Citrix Cloud Connectors se utilizan para buscar cuentas de usuario de back-end 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
- Utilice el flujo SAML predeterminado de Citrix Cloud, que utiliza identidades de AD para autenticar al usuario final.
- Un conocimiento exhaustivo de la infraestructura de su bosque o dominio de AD y de dónde se encuentran las identidades de los usuarios finales de su tienda.
- Citrix Cloud Connectors unidos al bosque y dominio de AD correctos y unidos al nivel de dominio de AD correcto.
- Conocimiento de las ubicaciones de recursos existentes y de los Citrix Cloud Connectors que ya están configurados en su inquilino de Citrix Cloud.
- Varios bosques de AD conectados a Citrix Cloud no deben tener ninguna confianza de Active Directory entre ellos.
- Una comprensión de lo que significa una identidad de usuario de front-end (Entra ID, Okta, Duo) y de back-end (AD).
- Las identidades de usuario de front-end y back-end deben estar vinculadas a través de UPN coincidentes. No se admite la vinculación de un par de identidades de usuario de front-end y back-end 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 varios 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 de AD universales son obligatorios al asignar recursos de grupos de entrega a grupos de AD en DaaS.
-
Los grupos de entrega de DaaS deben configurarse en “Restringir el uso de recursos” y deben asignarse a los grupos de AD universales correctos. El uso de “Permitir que cualquier usuario autenticado use recursos” dentro de los grupos de entrega de DaaS NO es compatible.
-
Servidores FAS unidos al bosque de AD correcto y unidos al dominio en el nivel de AD correcto. Los servidores FAS son necesarios para el inicio de sesión único (SSON) en los VDA unidos al dominio de AD durante los lanzamientos de DaaS.
- También es posible que deba implementar la autenticación condicional si tiene varias aplicaciones SAML y requiere una aplicación SAML por cada bosque de AD conectado. Cada aplicación SAML podría requerir un conjunto diferente de valores para cip_forest y cip_domain en escenarios de fusiones y adquisiciones.
Preguntas frecuentes
¿Si envío cip_sid en la aserción SAML, también necesito enviar las reclamaciones opcionales cip_forest y cip_domain?
No. Si su aplicación SAML está configurada para enviar la reclamación cip_sid y esta se incluye en la aserción SAML, entonces 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 en los que no es posible enviar cip_sid en la aserción SAML y que podrían requerir el uso de cip_forest y cip_domain en su lugar.
- Usuarios de front-end que contienen un SID incorrecto, que no coincide con el SID del usuario de AD de backend asignado dentro de los grupos de entrega de DaaS.
- Usuarios de front-end que no tienen ningún SID incrustado, como usuarios nativos de Okta, Entra ID o Duo que no se crearon dentro del IdP mediante 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 añadido por los administradores de AD en Dominios y Confianzas de Active Directory. Por ejemplo @rootforestdomain.local
Importante:
Windows AD PowerShell le permite crear usuarios de AD con cualquier sufijo UPN que especifique, incluso si ese sufijo UPN no existe dentro de su bosque de AD. El sufijo UPN alternativo que desea utilizar DEBE existir dentro del bosque de AD, ya que los Citrix Cloud Connectors dependen de esta lista para buscar a los usuarios de la cuenta 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 su identidad de front-end 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 utilizar para determinar el usuario de backend de AD correcto cuando existen dos versiones de duplicateuser@domain.com. Esto puede provocar que los recursos de DaaS no se enumeren en absoluto, o que los recursos de DaaS incorrectos publicados mediante VDA unidos a un dominio de AD se muestren en la tienda.
¿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 los 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_forest y cip_domain. El uso de otros tipos de grupos de AD, como los globales, puede provocar errores en la enumeración de recursos en la tienda.
Se recomienda leer 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 utilice recursos” dentro de los grupos de entrega de DaaS?
Configurar Permitir que cualquier usuario autenticado utilice recursos hará que los recursos publicados mediante VDA unidos a un dominio de AD aparezcan en la tienda para identidades de usuario de AD que no se encuentran dentro del mismo dominio y bosque. El lanzamiento de recursos desde VDA unidos a un dominio en el Bosque 2 utilizando una identidad de usuario final de AD de la tienda en el Bosque 1 no tendrá éxito.
¿Puedo enviar solo cip_forest por sí solo o solo cip_domain por sí solo en la aserción SAML?
No. Si desea especificar un bosque de AD y un contexto de dominio particulares para la búsqueda de usuarios de backend, debe proporcionar ambas aserciones opcionales en la aserción SAML.
¿Qué sufijo UPN debo usar al especificar un valor para cip_forest?
Se debe usar el sufijo UPN implícito para el bosque de AD. No especifique un valor de un sufijo UPN ALT que se haya agregado al bosque de AD dentro de la aserció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: Sus Citrix Cloud Connectors están unidos a un dominio a nivel de raíz del bosque y los usuarios de la cuenta de AD de backend residen dentro del dominio raíz dentro del bosque de AD conectado.
cip_domain y cip_forest deben tener el mismo valor.
cip_forest = “forestrootdomain.com”
cip_domain = “forestrootdomain.com”
Escenario 2: Sus 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” dentro de su bosque de AD.
cip_domain y cip_forest deben tener valores diferentes.
cip_forest = “forestrootdomain.com”
cip_domain = “childdomain.forestrootdomain.com”
¿Puedo codificar los valores de cip_forest y cip_domain 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 de DaaS, reside en el mismo bosque de AD. La codificación de los valores de cip_forest y cip_domain requiere que cada usuario de front-end tenga sus cuentas de AD de backend correspondientes en el mismo bosque y dominio de AD.
¿Puedo especificar valores diferentes para cip_forest y cip_domain dentro de la aserción SAML de forma dinámica?
Sí, si su proveedor SAML lo permite a través de reglas de transformación de notificaciones. Si tiene diferentes poblaciones de usuarios front-end con diferentes sufijos UPN, es posible especificar los valores de cip_forest y cip_domain dinámicamente utilizando condiciones de conmutación como la pertenencia a grupos. Esto es posible dentro de las aplicaciones SAML de Entra ID y también podría ser posible en otros IdP SAML que admitan reglas de transformación de notificaciones.
¿Dónde debo colocar mis servidores FAS para que el lanzamiento de SSON a VDAs unidos a un dominio de AD tenga éxito?
Los servidores FAS deben estar unidos a un 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 una sus servidores FAS al dominio a nivel de dominio raíz del bosque de AD.
Topologías de AD donde se requieren cip_forest y cip_domain 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.com a nivel de bosque raíz.
- ResourceLocation2 contiene Citrix Cloud Connectors que están unidos al dominio AD forestrootdomain2.com a nivel de bosque raíz.
- forestrootdomain1.com y forestrootdomain2.com tienen el mismo sufijo UPN @domain.com.
- También pueden existir usuarios duplicados dentro de forestrootdomain1.com y forestrootdomain2.com con el mismo UPN
duplicateuser@domain.compero diferentes valores de SID y OID.
Problema: el intento de buscar la cuenta de AD de backend correcta usando username@duplicatesuffix.com no siempre devuelve el usuario de AD 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 es posible que se muestren recursos DaaS incorrectos en la tienda o que no se devuelva ningún recurso DaaS.
Solución: configure dos aplicaciones SAML diferentes, una para cada bosque de AD conectado, e incluya los valores correspondientes de cip_domain y cip_forest para el bosque de AD correcto en la aserción SAML. Esto proporciona a Citrix Cloud el contexto adicional de bosque y dominio para garantizar que el usuario de AD 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:
Asigne correctamente los dos grupos de entrega de DaaS utilizando los grupos de backend de AD correctos.
Escenario 2: Cloud Connectors unidos a nivel de dominio secundario y usuarios de almacén a nivel de dominio secundario
El inquilino de Citrix Cloud tiene una ubicación de recursos que contiene dos Citrix Cloud Connectors, que están unidos al dominio a nivel de “childdomain.forestrootdomain.com” en lugar del nivel recomendado “forestrootdomain.com”. Los usuarios de almacén 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: Especifique el contexto del dominio secundario en la aserción SAML para que el usuario de la cuenta de AD se “busque” en el dominio secundario de AD y el contexto del bosque correctos.
cip_forest = forestrootdomain.com
cip_domain = childdomain.forestrootdomain.com
