SAML con Azure AD para identidades de invitado y B2B para la autenticación de espacios de trabajo

Antes de seguir con este artículo, es esencial que comprenda si SAML B2B es apropiado para su caso de uso de autenticación. Lea detenidamente las descripciones de los casos de uso y las preguntas frecuentes antes de decidir si implementar esta solución SAML para casos de uso en particular. Antes de continuar, asegúrese de que entiende perfectamente los casos en los que SAML B2B es apropiado y los tipos de identidades que debe usar. La mayoría de los casos de uso de SAML se pueden completar siguiendo otros artículos sobre SAML y enviando los cuatro atributos cip_* para la autenticación.

Nota:

El uso de SAML B2B aumenta la carga que soportan los Citrix Cloud Connectors, ya que tienen que buscar, el SID, el OID y el correo electrónico de los usuarios para cada inicio de sesión de usuario final en Workspace, en lugar de buscar estos valores en la aserción SAML. Desde el punto de vista del rendimiento del Citrix Cloud Connector, es preferible enviar los cuatro atributos cip_* en la aserción SAML si realmente no se requiere SAML B2B.

Requisitos previos

• Una aplicación SAML configurada específicamente para usarse con SAML B2B que solo envía cip_upn para la autenticación dentro de la aserción SAML.
• Usuarios de front-end de su proveedor de SAML.
• Una ubicación de recursos que contenga un par de Citrix Cloud Connectors unidos al bosque y al dominio de AD donde se crean las cuentas sombra de AD.
• Usar el UPN implícito o agregar un sufijo UPN alternativo agregado al bosque de AD del back-end donde se crean las cuentas sombra de AD.
• Cuentas sombra de AD del back-end con UPN coincidentes.
• Recursos de DaaS o CVAD asignados a los usuarios de las cuentas sombra de AD.
• Uno o más servidores FAS vinculados a la misma ubicación de recursos.

Preguntas frecuentes

¿Por qué debo usar SAML B2B?

Es muy común que las grandes organizaciones inviten a contratistas y empleados temporales a su plataforma de identidades. El objetivo es conceder al contratista acceso temporal a Citrix Workspace usando la identidad existente del usuario, como la dirección de correo electrónico del contratista o una dirección de correo electrónico ajena a la organización. B2B SAML permite el uso de identidades de front-end nativas o de invitado que no existen en el dominio de AD donde se publican los recursos de DaaS.

¿Qué es SAML B2B?

Normalmente, al iniciar sesión en Citrix Workspace, se usan cuatro atributos cip_* de SAML y sus correspondientes atributos de usuario de AD para autenticar al usuario final. Se espera que estos cuatro atributos SAML estén presentes en la aserción SAML y se rellenen con atributos de usuario de AD. B2B SAML se refiere al hecho de que solo se requiere el atributo cip_upn de SAML para que la autenticación funcione correctamente.

Los otros tres atributos de usuario de AD, ObjectSID, ObjectGUID y Mail, necesarios para la autenticación, se obtienen mediante los Citrix Cloud Connectors unidos al dominio de AD donde reside la cuenta sombra de AD. Ya no es necesario incluirlos en la aserción SAML durante un flujo de inicio de sesión de SAML para Workspace o Citrix Cloud.

Importante:

Sigue siendo necesario enviar el nombre simplificado, displayName, para todos los flujos de SAML, incluido B2B SAML. La interfaz de usuario de Workspace requiere displayName para mostrar correctamente el nombre completo del usuario de Workspace.

¿Qué es una identidad de usuario de SAML nativa?

Un usuario de SAML nativo es una identidad de usuario que solo existe en el directorio de su proveedor de SAML, por ejemplo, Entra ID u Okta. Estas identidades no contienen atributos de usuario locales, ya que no se crean mediante herramientas de sincronización de AD como Entra ID Connect. Requieren cuentas sombra de back-end de AD coincidentes para poder enumerar e iniciar los recursos de DaaS. El usuario de SAML nativo debe estar asignado a la cuenta correspondiente dentro de Active Directory.

¿Qué es un usuario B2B importado de otro arrendatario de Entra ID?

Un usuario B2B es un usuario de Entra ID que existe como miembro dentro del arrendatario 1 de Entra ID y está invitado a otros arrendatarios de Entra ID, como el arrendatario 2 de Entra ID, como usuario invitado. La aplicación SAML B2B se configura en el arrendatario 2 de Entra ID y se conecta a Citrix Cloud como un proveedor de identidades de SAML. Los usuarios B2B necesitan cuentas sombra de backend de AD coincidentes para poder enumerar e iniciar los recursos de DaaS. El usuario B2B debe estar asignado a una cuenta sombra correspondiente en Active Directory.

Consulte la documentación de Microsoft para obtener más información sobre los usuarios B2B y cómo invitar a usuarios miembros de otros arrendatarios de Entra ID a su arrendatario de Entra ID como usuarios invitados.

Introducción: Colaboración B2B con invitados externos para su personal Propiedades de un usuario de colaboración B2B de Microsoft Entra

¿Qué es una identidad de usuario de SAML respaldada por AD?

Un usuario de SAML respaldado por AD es una identidad de usuario que existe en el directorio de su proveedor de SAML, como Entra ID u Okta, y también en su bosque de AD local. Estas identidades contienen atributos de usuario locales, ya que se crean mediante herramientas de sincronización de AD como Entra ID Connect. No se requieren cuentas sombra de back-end de AD para estos usuarios, ya que contienen SID y OID locales y, por lo tanto, pueden enumerar e iniciar recursos publicados de DaaS usando VDA unidos a un dominio de AD.

¿Qué es una identidad de front-end?

Una identidad de front-end es la identidad que se usa para iniciar sesión tanto en el proveedor de SAML como en Workspace. Las identidades de front-end tienen diferentes atributos de usuario en función de cómo se crearon en el proveedor de SAML.

1. Identidad de usuario de SAML nativa
2. Identidad de usuario de SAML respaldada por AD

Su proveedor de SAML puede tener una combinación de estos dos tipos de identidades. Por ejemplo, si tiene contratistas y empleados permanentes en su plataforma de identidades, B2B SAML funcionará para ambos tipos de identidades de front-end, pero solo es obligatorio si tiene algunas cuentas que son de tipo identidad de usuario de SAML nativa.

¿Qué es una cuenta sombra de AD de back-end?

Una cuenta sombra de AD de back-end es una cuenta de AD que DaaS usa, la cual se asigna a la identidad de front-end correspondiente dentro de su proveedor de SAML.

¿Por qué son necesarias las cuentas sombra de AD de back-end?

Para enumerar los recursos de DaaS o CVAD publicados mediante los VDA unidos a un dominio de AD, se requieren las cuentas de AD del bosque de Active Directory a las que están unidos los VDA. Asigne los recursos de su grupo de entrega de DaaS a los usuarios de cuentas sombra y a los grupos de AD que contengan cuentas sombra en el dominio de AD al que unió sus VDA.

Importante:

Solo los usuarios nativos de SAML sin atributos de dominio de AD necesitan cuentas sombra de AD coincidentes. Si sus identidades de front-end se importan de Active Directory, no necesita usar B2B SAML ni crear cuentas sombra de AD de back-end.

¿Cómo vinculamos la identidad de front-end a la cuenta sombra de AD de back-end correspondiente?

Para vincular la identidad del front-end a la identidad del back-end se usan UPN coincidentes. Las dos identidades vinculadas deben tener UPN idénticos para que Workspace pueda saber que representan al mismo usuario final que necesita iniciar sesión en Workspace y enumerar e iniciar los recursos de DaaS.

¿Se necesita Citrix FAS para SAML B2B?

Sí. Se requiere Servicio de autenticación federada (FAS) para el inicio único de sesión en el VDA cuando se usa cualquier método de autenticación federada para iniciar sesión en Workspace.

¿Qué es el “problema de discordancia de SID” y cuándo puede ocurrir?

El “problema de discordancia de SID” se produce cuando la aserción SAML contiene un SID para un usuario de front-end que no coincide con el SID del usuario de la cuenta sombra de AD. Esto puede ocurrir cuando la cuenta que inicia sesión en su proveedor de SAML tiene un SID local distinto del SID de usuario de la cuenta sombra. Esto solo puede ocurrir cuando la identidad de front-end se aprovisiona mediante herramientas de sincronización de AD, como Entra ID Connect, y desde un bosque de AD diferente de aquel en el que se creó la cuenta sombra.

B2B SAML impide que se produzca el “problema de discordancia de SID”. Se obtiene siempre el SID correcto para el usuario de la cuenta sombra a través de los Citrix Cloud Connectors unidos al dominio de AD de back-end. La búsqueda de usuarios de cuentas sombra se realiza mediante el UPN de usuario del front-end, que se empareja con su usuario de la cuenta sombra del back-end correspondiente.

Ejemplo del problema de discordancia del SID: El usuario del front-end lo creó Entra ID Connect y se sincroniza con el bosque 1 de AD. S-1-5-21-000000000-0000000000-0000000001-0001

El usuario de la cuenta sombra del back-end se creó en el bosque 2 de AD y se asignó a recursos de DaaS S-1-5-21-000000000-0000000000-0000000002-0002

La aserción SAML contiene los cuatro atributos cip_* y cip_sid contiene el valor S-1-5-21-000000000-0000000000-0000000001-0001, que no coincide con el SID de la cuenta sombra y desencadena un error.

Configurar la aplicación SAML B2B en Entra ID para cuentas de invitados externos

1. Inicie sesión en Azure Portal.
2. En el menú del portal, seleccione Entra ID.
3. En el panel de la izquierda, en Manage, seleccione Enterprise Applications.
4. Seleccione Create your own application.

5. Introduzca un nombre adecuado para la aplicación SAML, como Citrix Cloud SAML SSO Production B2B SAML UPN Only.

   

6. En el panel de navegación izquierdo, seleccione Single sign-on y, en el panel de trabajo, haga clic en SAML.
7. En la sección Basic SAML Configuration, haga clic en Edit y configure estos parámetros:
   1. En la sección Identifier (Entity ID), seleccione Add identifier y, a continuación, introduzca el valor asociado a la región en la que se encuentra el arrendatario de Citrix Cloud:
      • Para las regiones de Europa, Estados Unidos y Asia-Pacífico Sur, introduzca https://saml.cloud.com.
      • Para la región de Japón, introduzca https://saml.citrixcloud.jp.
      • Para la región de Citrix Cloud Government, introduzca https://saml.cloud.us.
   2. En la sección Reply URL (Assertion Consumer Service URL), seleccione Add reply URL y, a continuación, introduzca el valor asociado a la región en la que se encuentra su arrendatario de Citrix Cloud:
      • Para las regiones de Europa, Estados Unidos y Asia-Pacífico Sur, introduzca https://saml.cloud.com/saml/acs.
      • Para la región de Japón, introduzca https://saml.citrixcloud.jp/saml/acs.
      • Para la región de Citrix Cloud Government, introduzca https://saml.cloud.us/saml/acs.
   3. En la sección URL de inicio de sesión, introduzca la URL de su espacio de trabajo.
   4. En la sección Logout URL (Optional), introduzca el valor asociado a la región en la que se encuentra el arrendatario de Citrix Cloud:
      • Para las regiones de Europa, Estados Unidos y Asia-Pacífico Sur, introduzca https://saml.cloud.com/saml/logout/callback.
      • Para la región de Japón, introduzca https://saml.citrixcloud.jp/saml/logout/callback.
      • Para la región de Citrix Cloud Government, introduzca https://saml.cloud.us/saml/logout/callback.

   5. En la barra de comandos, haga clic en Guardar. La sección Configuración básica de SAML se muestra de esta manera:

      

8. En la sección Attributes & Claims, haga clic en Edit para configurar estas notificaciones. Estas notificaciones aparecen en la aserción SAML incluida en la respuesta SAML. Tras crear la aplicación SAML, configure estos atributos.

   

   1. Para la notificación de identificador único de usuario (ID de nombre), defina el formato del identificador de nombre como no especificado y su atributo de origen como user.localuserprincipalname.
   2. Para la notificación cip_upn, deje el valor predeterminado de user.localuserprincipalname.
   3. Para displayName, deje el valor predeterminado de user.displayname.

   4. En la sección Additional claims, para las notificaciones restantes con el espacio de nombres http://schemas.xmlsoap.org/ws/2005/05/identity/claims, haga clic en el botón de puntos suspensivos (…) y, a continuación, haga clic en Delete. No es necesario incluir estas notificaciones, ya que son duplicados de los atributos de usuario anteriores.

      Al terminar, la sección Attributes & Claims aparece como se ilustra a continuación:

      

   5. Obtenga una copia del certificado de firma SAML de Citrix Cloud con esta herramienta en línea de terceros.
   6. Introduzca https://saml.cloud.com/saml/metadata en el campo URL y haga clic en Cargar.

   

9. Desplácese al final de la página y haga clic en Descargar.

   

   

10. Configure los parámetros de firma de la aplicación SAML de Azure Active Directory.
11. Cargue el certificado de firma SAML de producción obtenido en el paso 10 en la aplicación SAML de Azure Active Directory
    1. Habilite Exigir certificados de verificación.

    

    

Configurar la conexión SAML B2B de Citrix Cloud

De forma predeterminada, Citrix Cloud espera que cip_upn, cip_email, cip_sid y cip_oid estén presentes en la aserción SAML y no podrá iniciar sesión en SAML si no se envían estos atributos. Para evitarlo, quite las comprobaciones de estos atributos cuando cree la nueva conexión SAML.

1. Cree una nueva conexión SAML con los parámetros predeterminados.
2. Vaya a la sección SAML Attribute Mappings Configuration en la parte inferior y haga los cambios necesarios antes de guardar la nueva configuración de SAML.
3. Quite el nombre del atributo SAML de cada uno de los campos cip_email, cip_sid y cip_oid.
4. No quite cip_upn de su campo.
5. No quite ningún otro atributo de sus campos respectivos. La interfaz de usuario de Workspace sigue necesitando displayName y no debe cambiarse.

Configure la ubicación de recursos y los conectores de su cuenta sombra de AD

Se requiere una ubicación de recursos y un par de conectores dentro del bosque de AD de la cuenta oculta del back-end. Citrix Cloud requiere conectores de este bosque de AD para buscar las identidades y los atributos de los usuarios de las cuentas sombra, como cip_email, cip_sid y cip_oid, cuando solo se proporciona cip_upn directamente en la aserción SAML.

1. Cree una nueva ubicación de recursos que contenga Citrix Cloud Connectors unidos al bosque de AD de la cuenta sombra del back-end.

   

2. Asigne un nombre a la ubicación de recursos, de manera que coincida con el bosque de AD que contiene las cuentas sombras de AD del back-end que quiere usar.
3. Configure un par de Citrix Cloud Connectors en la ubicación de recursos recién creada.

Por ejemplo ccconnector1.shadowaccountforest.com ccconnector2.shadowaccountforest.com

Configurar FAS en el bosque de AD del back-end

Los usuarios contratistas del front-end definitivamente necesitarán FAS. Durante los inicios de DaaS, los usuarios contratistas no podrán introducir manualmente las credenciales de Windows para completar el inicio, ya que es probable que no conozcan la contraseña de la cuenta sombra de AD.

1. Configure uno o más servidores de FAS en el bosque de AD del back-end donde se crearon las cuentas sombra.
2. Vincule los servidores de FAS a la misma ubicación de recursos que contiene un par de Citrix Cloud Connectors unidos al bosque de AD del back-end donde se crearon las cuentas sombra.

Configurar sufijos de UPN alternativos en su dominio de AD

Importante:

Un UPN no es lo mismo que la dirección de correo electrónico del usuario. En muchos casos, tienen el mismo valor para facilitar su uso, pero el UPN y el correo electrónico a menudo pueden tener valores diferentes y se definen en diferentes atributos de Active Directory y dentro de diferentes atributos de usuario de Entra ID. Esta solución depende de la coincidencia de UPN entre las identidades del front-end y del back-end y no de la coincidencia del correo electrónico.

Puede usar el sufijo de UPN implícito para su dominio si se puede redireccionar públicamente en DNS o agregar un sufijo UPN alternativo coincidente para cada usuario externo del front-end que quiera invitar a sus arrendatarios de Okta o Azure AD. Si AD usa yourdomain.local como UPN implícito, tendrá que elegir un sufijo UPN alternativo como yourdomain.com. Entra ID no le permitirá agregar yourdomain.local en nombres de dominio personalizados.

Por ejemplo, si invita a un usuario externo contractoruser@hotmail.co.uk y quiere asociarlo a una cuenta sombra de AD del back-end contractoruser@yourforest.com, agregue yourforest.com como sufijo ALT de UPN en su bosque de AD.

Agregar sufijos de UPN alternativos en Active Directory mediante la interfaz de usuario de Active Directory Domains and Trusts

1. Inicie sesión en un controlador de dominio dentro de su bosque de AD de back-end.
2. Abra el cuadro de diálogo Run, escriba domain.msc y, a continuación, haga clic en OK.
3. En la ventana Active Directory Domains and Trusts, haga clic con el botón secundario en Active Directory Domains and Trusts y, a continuación, seleccione Properties.

4. En la ficha UPN Suffixes, en el cuadro Alternative UPN Suffixes, agregue un sufijo de UPN alternativo y, a continuación, seleccione Add.

   

5. Haga clic en Aceptar.

Administrar sufijos de UPN de un bosque de AD de back-end con PowerShell

Es posible que tenga que agregar una gran cantidad de sufijos UPN nuevos a su bosque de AD de back-end para crear los UPN de cuenta sombra necesarios. La cantidad de sufijos de UPN alternativos que tendrá que agregar a su bosque de AD de back-end dependerá de la cantidad de usuarios externos diferentes que decida invitar a su arrendatario de proveedores de SAML.

Aquí se incluye el código de PowerShell para hacerlo si es necesario crear una gran cantidad de nuevos sufijos de UPN alternativos.

# Get the list of existing ALT UPN suffixes within your AD Forest
(Get-ADForest).UPNSuffixes

# Add or remove ALT UPN Suffixes
$NewUPNSuffixes = @("yourforest.com","externalusers.com")

# Set action to "add" or "remove" depending on the operation you wish to perform.
$Action = "add"
foreach($NewUPNSuffix in $NewUPNSuffixes)
{
    Get-ADForest | Set-ADForest -UPNSuffixes @{ $Action=$NewUPNSuffix }
}
<!--NeedCopy-->

Configurar una cuenta sombra de AD en su bosque de AD de back-end

1. Crea un nuevo usuario de cuenta sombra de AD.

2. El UPN implícito del bosque de AD, por ejemplo, yourforest.local, aparece seleccionado de forma predeterminada para los nuevos usuarios de AD. Seleccione el sufijo de UPN alternativo correspondiente que creó anteriormente. Por ejemplo, seleccione yourforest.com como sufijo de UPN del usuario de la cuenta sombra.

   

   El UPN de usuario de la cuenta sombra también se puede actualizar a través de PowerShell.

   Set-ADUser "contractoruser" -UserPrincipalName "contractoruser@yourforest.com"
   <!--NeedCopy-->
   

3. El UPN de usuario de la cuenta sombra debe coincidir exactamente con el UPN de usuario externo de la identidad de front-end.
4. Pruebe el inicio de sesión del usuario de front-end en Workspace.
5. Verifique que todos los recursos previstos aparecen enumerados en Workspace una vez que se haya realizado correctamente el inicio de sesión. Deberían aparecer los recursos asignados a la cuenta sombra de AD.

Configurar el UPN de usuario invitado de Entra ID para que coincida con el UPN de la cuenta sombra de AD

Cuando se invita a usuarios externos a un arrendatario de Entra ID, se genera automáticamente un UPN que indica que el usuario es externo. Al usuario externo de Entra ID se le asignará automáticamente el sufijo de UPN @Entra IDtenant.onmicrosoft.com, que no es adecuado para su uso con SAML B2B y no coincidirá con su cuenta sombra de AD. Deberá actualizarse para que coincida con un dominio de DNS importado en Entra ID y con el sufijo de UPN alternativo que creó en su bosque de AD.

1. Importe un dominio personalizado en Entra ID que coincida con el sufijo de UPN alternativo que agregó a su bosque de AD.

   

2. Invite a un usuario, por ejemplo, contractoruser@hotmail.co.uk, y asegúrese de que el usuario invitado acepta la invitación de Microsoft al arrendatario de Entra ID.

   Ejemplo de formato de UPN de usuario invitado externo generado por Microsoft. contractoruser_hotmail.co.uk#EXT#@yourEntra IDtenant.onmicrosoft.com

   

   

   Importante:

   Citrix Cloud y Workspace no pueden usar UPN que contengan el carácter # para la autenticación SAML.

3. Instale los módulos de Azure PowerShell Graph necesarios para poder administrar usuarios de Entra ID.

   Install-Module -Name "Microsoft.Graph" -Force
   Get-InstalledModule -Name  "Microsoft.Graph"
   <!--NeedCopy-->
   

4. Inicie sesión en su arrendatario de Entra ID con una cuenta de administrador global y con el ámbito Directory.AccessAsUser.All.

   Importante:

   Si usa una cuenta con menos privilegios o no especifica el ámbito Directory.AccessAsUser.All, no podrá completar el paso 4 ni actualizar el UPN del usuario invitado.

   Connect-MgGraph -Scopes Directory.AccessAsUser.All
   <!--NeedCopy-->
   

5. Actualice el usuario de Entra ID con un UPN que coincida con el UPN que configuró para su cuenta sombra de AD.

   $GuestUserId = (Get-MgUser -UserId "contractoruser_hotmail.co.uk#EXT#@yourentraidtenant.onmicrosoft.com").Id
   Update-MgUser -UserId $GuestUserId -UserPrincipalName "contractoruser@your.com"
   <!--NeedCopy-->
   

6. Obtenga la lista completa de usuarios invitados externos de su arrendatario de Entra ID (opcional).

   

   Get-MgUser -filter "userType eq 'Guest'" | Select Id,DisplayName,UserPrincipalName,Mail
   <!--NeedCopy-->
   

7. Obtenga la identidad de usuario invitado cuyo UPN necesita actualizar y, a continuación, actualice su sufijo de UPN.

   $GuestUserId = (Get-MgUser -UserId "contractoruser_hotmail.co.uk#EXT#@yourEntra IDtenant.onmicrosoft.com").Id
       
   Update-MgUser -UserId $GuestUserId -UserPrincipalName "contractoruser@yourforest.com"
   <!--NeedCopy-->
   

8. Compruebe que se puede encontrar la identidad del usuario invitado utilizando su UPN recién actualizado.

   Get-MgUser -UserId "contractoruser@yourforest.com"
   <!--NeedCopy-->
   

Prueba de la solución SAML B2B

Una vez que se hayan completado todos los pasos documentados en AD, Citrix Cloud y su proveedor de SAML, debe probar el inicio de sesión y verificar que se muestra la lista correcta de recursos para el usuario invitado en Workspace.

Citrix recomienda usar la extensión de explorador web SAML-tracer para todas las depuraciones de SAML. Esta extensión está disponible para los exploradores web más comunes. La extensión decodifica solicitudes y respuestas codificadas en Base64 en XML SAML, lo que las hace legibles para las personas.

Ejemplo de una aserción SAML B2B que usa solo cip_upn para la autenticación capturada con SAML-tracer.

1. Asigne los recursos de DaaS correctos a los usuarios o grupos de cuentas sombra y respaldados por AD que los contienen.

2. Inicie la extensión de explorador SAML-tracer y capture todo el flujo de inicio y cierre de sesión.

3. Inicie sesión en Workspace con el atributo especificado en la tabla para el tipo de usuario de front-end que quiere probar.

   Inicio de sesión de usuario invitado de Entra ID: El usuario contratista al que invitó a su arrendatario de Entra ID como usuario invitado tiene la dirección de correo electrónico contractoruser@hotmail.co.uk.

   Introduzca la dirección de correo electrónico del usuario invitado cuando Entra ID se lo pida.

   O BIEN:

   Inicio de sesión de usuario de Entra ID respaldado por AD o usuario nativo de Entra ID: Estos usuarios de Entra ID tendrán un UPN con el formato adbackeduser@yourforest.com o nativeuser@yourforest.com.

   Introduzca el UPN del usuario cuando Entra ID se lo pida.

4. Compruebe que la aserción solo contenga el atributo cip_upn para la autenticación y que también contenga el atributo displayName que requiere la interfaz de usuario de Workspace.

5. Compruebe que el usuario puede ver los recursos de DaaS necesarios en la interfaz de usuario.

Solución de problemas de la solución SAML B2B

Envío de un UPN incorrecto en la aserción SAML

Causa: Esto solo puede ocurrir con cuentas B2B importadas del arrendatario 1 de Entra ID al arrendatario 2 de Entra ID. Se puede enviar un UPN incorrecto en la aserción SAML cuando se utilizan usuarios B2B importados de otros arrendatarios de Entra ID. Si se usa user.userprincipalname y el usuario final inicia sesión con un usuario B2B importado de otro arrendatario de Entra ID, se enviará un valor incorrecto para cip_upn en la aserción SAML. El valor de cip_upn usado en la aserción de SAML procederá del arrendatario de Entra ID de origen que contiene al usuario B2B como miembro. El uso de user.localuserprincipalname garantiza que el valor de cip_upn se obtenga del arrendatario de Entra ID con el usuario B2B como invitado.

Errores de falta de atributos cip_*

Causa 1: El atributo SAML no está presente en la aserción SAML, pero Citrix Cloud está configurado para esperar recibirlo. No ha quitado los atributos cip_* innecesarios de la conexión SAML de Citrix Cloud en la sección de atributos de SAML. Desconecte SAML y vuelva a conectarlo para quitar las referencias a los atributos cip_* innecesarios.

Causa 2: Este error también puede producirse si no hay una cuenta sombra de AD correspondiente para que los Citrix Cloud Connectors la busquen en su bosque de AD de back-end. Es posible que haya configurado correctamente la identidad del front-end, pero la identidad de la cuenta sombra de AD del back-end con un UPN coincidente no existe o no se puede encontrar.

El inicio de sesión se realiza correctamente, pero no se muestra ningún recurso de DaaS después de que el usuario haya iniciado sesión en Workspace

Causa: Lo más probable es que se deba a una asignación de UPN de identidad de front-end a back-end incorrecta.

Asegúrese de que los 2 UPN de las identidades de front-end y back-end coincidan exactamente y representen al mismo usuario final que inicia sesión en Workspace. Compruebe que el grupo de entrega de DaaS contenga asignaciones a los usuarios correctos de la cuenta sombra de AD o a los grupos de AD que los contienen.

Durante el inicio de los recursos de DaaS, se produce un error en el SSON de FAS en los VDA unidos al dominio de AD

Al intentar iniciar recursos de DaaS, se solicita al usuario final de Workspace que introduzca sus credenciales de Windows en GINA. Además, el ID de evento 103 aparece en los registros de eventos de Windows de sus servidores FAS.

[S103] El servidor [CC:FASServer] solicitó el UPN [frontenduser@yourforest.com] SID S-1-5-21-000000000-0000000000-0000000001-0001, pero la búsqueda devolvió SID S-1-5-21-000000000-0000000000-0000000001-0002. [correlación: cc#967472c8-4342-489b-9589-044a24ca57d1]

Causa: Su implementación de SAML B2B tiene un “problema de discordancia de SID”. Tiene identidades de front-end que contienen SID de un bosque de AD que es distinto del bosque de AD de la cuenta sombra de back-end.
No envíe cip_sid en la aserción SAML.

El inicio de sesión falla para los usuarios respaldados por AD cuando existe el mismo sufijo UPN en varios bosques de AD conectados

Citrix Cloud tiene varias ubicaciones de recursos y conectores unidos a diferentes bosques de AD. El inicio de sesión falla cuando se usan usuarios respaldados por AD importados en Entra ID desde un bosque de AD diferente del bosque de AD de la cuenta sombra.

El bosque de AD 1 se sincroniza con Entra ID para crear usuarios de front-end con UPN como frontenduser@yourforest.com.

El bosque de AD 2 contiene las cuentas sombra de back-end con UPN como frontenduser@yourforest.com.

Causa: Su implementación de SAML B2B tiene un “problema de ambigüedad de UPN”. Citrix Cloud no puede determinar qué conectores usar para buscar la identidad de back-end del usuario.

No envíe cip_sid en la aserción SAML.
El UPN de su usuario existe en más de un bosque de AD conectado a Citrix Cloud.