SAML utilisant Azure AD pour les invités et les identités B2B pour l’authentification de l’espace de travail

Il est essentiel que vous déterminiez si l’authentification B2B SAML est appropriée à votre cas d’utilisation d’authentification avant de suivre cet article. Lisez attentivement les descriptions des cas d’utilisation et les questions fréquentes avant de décider de mettre en œuvre cette solution SAML adaptée à des cas particuliers. Avant de continuer, assurez-vous de bien comprendre les scénarios dans lesquels l’authentification B2B SAML est appropriée et les types d’identités que vous devez utiliser. Dans la plupart des cas d’utilisation de SAML, vous pouvez configurer l’authentification SAML en suivant d’autres articles dédiés et en transmettant les quatre attributs cip_* d’authentification.

Remarque :

L’utilisation de l’authentification B2B SAML augmente la charge placée sur les connecteurs Citrix Cloud, car ils doivent rechercher l’e-mail de l’utilisateur, le SID et l’OID pour chaque connexion d’utilisateur à Workspace au lieu que ces valeurs soient fournies par l’assertion SAML. L’envoi des quatre attributs cip_* dans l’assertion SAML est préférable du point de vue des performances de Citrix Cloud Connector si l’authentification B2B SAML n’est pas réellement requise.

Conditions préalables

• Une application SAML spécifiquement configurée pour être utilisée avec l’authentification B2B SAML qui envoie uniquement cip_upn pour l’authentification dans l’assertion SAML.
• Des utilisateurs frontend au sein de votre fournisseur SAML.
• Un emplacement de ressources contenant une paire de connecteurs Citrix Cloud connectés à la forêt AD et au domaine dans lequel les comptes fantôme AD sont créés.
• Utilisez l’UPN implicite ou ajoutez un suffixe UPN alternatif ajouté à la forêt AD principale où les comptes fantômes AD sont créés.
• Des comptes fantôme AD principaux avec leurs UPN correspondants.
• Des ressources DaaS ou CVAD mappées aux utilisateurs du compte fantôme AD.
• Un ou plusieurs serveurs FAS liés au même emplacement de ressources.

Questions fréquentes

Pourquoi devrais-je utiliser l’authentification B2B SAML ?

Il est très fréquent pour les grandes entreprises d’inviter des contractants et des employés temporaires sur leur plateforme d’identité. L’objectif est d’accorder aux contractants un accès temporaire à Citrix Workspace en utilisant une identité utilisateur existante, telle que l’adresse e-mail d’un contractant ou une adresse e-mail extérieure à votre entreprise. L’authentification B2B SAML permet l’utilisation d’identités frontend natives ou invitées qui n’existent pas dans le domaine AD où les ressources DaaS sont publiées.

Qu’est-ce que l’authentification B2B SAML ?

En règle générale, lors de la connexion à Citrix Workspace, quatre attributs SAML cip_* et leurs attributs d’utilisateur AD correspondants sont utilisés pour authentifier les utilisateurs. Ces quatre attributs SAML doivent normalement figurer dans l’assertion SAML et être renseignés via les attributs d’utilisateur AD. L’authentification B2B SAML fait référence au fait que seul l’attribut SAML cip_upn est requis pour que l’authentification réussisse.

Les trois autres attributs d’utilisateur AD, objectSID, objectGUID et l’adresse e-mail, requis pour l’authentification sont obtenus via des connecteurs Citrix Cloud associés au domaine AD où existe le compte fantôme AD. Il n’est donc plus nécessaire de les inclure dans l’assertion SAML lors d’un flux de connexion SAML à Workspace ou Citrix Cloud.

Important :

Il est toujours nécessaire d’envoyer le displayName pour tous les flux SAML y compris le flux B2B SAML. L’interface utilisateur de Workspace a besoin de l’attribut displayName pour afficher correctement le nom complet de l’utilisateur de Workspace.

Qu’est-ce qu’une identité utilisateur SAML native ?

Un utilisateur SAML natif est une identité d’utilisateur qui existe uniquement dans votre annuaire de fournisseurs SAML, par exemple Entra ID ou Okta. Ces identités ne contiennent pas d’attributs utilisateur locaux, car elles ne sont pas créées via des outils de synchronisation AD tels qu’Entra ID Connect. Elles nécessitent des comptes fantôme correspondant au compte AD principal pour pouvoir énumérer et lancer des ressources DaaS. L’utilisateur SAML natif doit être mappé à un compte correspondant dans Active Directory.

Qu’est-ce qu’un utilisateur B2B importé depuis un autre locataire Entra ID ?

Un utilisateur B2B est un utilisateur Entra ID qui existe en tant que membre au sein du locataire Entra ID 1 et est invité auprès d’autres locataires Entra ID tels que le locataire Entra ID 2 en tant qu’utilisateur invité. L’application B2B SAML est configurée dans le locataire Entra ID 2 et est connectée à Citrix Cloud en tant que fournisseur d’identité SAML. Les utilisateurs B2B ont besoin de comptes fantômes principaux AD correspondants pour pouvoir énumérer et lancer des ressources DaaS. L’utilisateur B2B doit être mappé à un compte fantôme correspondant dans Active Directory.

Consultez la documentation Microsoft pour plus de détails sur les utilisateurs B2B et savoir comment inviter des utilisateurs membres d’autres locataires Entra ID dans votre locataire Entra ID en tant qu’utilisateurs invités.

Vue d’ensemble : collaboration B2B avec des invités externes pour votre main d’œuvre Comprendre et gérer les propriétés des utilisateurs invités B2B

Qu’est-ce qu’une identité utilisateur SAML basée sur AD ?

Un utilisateur SAML basé sur AD est une identité utilisateur qui existe à la fois dans le répertoire de votre fournisseur SAML, comme Entra ID ou Okta, et dans votre forêt AD locale. Ces identités contiennent des attributs utilisateur locaux, car elles sont créées via des outils de synchronisation AD tels qu’Entra ID Connect. Les comptes fantômes principaux AD ne sont pas requis pour ces utilisateurs, car ils contiennent des SID et des OID locaux, et peuvent donc énumérer et lancer des ressources DaaS publiées à l’aide de VDA joints au domaine AD.

Qu’est-ce qu’une identité frontend ?

Une identité frontend est l’identité utilisée pour se connecter à la fois au fournisseur SAML et à Workspace. Les identités frontend ont des attributs utilisateur différents selon la manière dont elles ont été créées au sein du fournisseur SAML.

1. Identité utilisateur SAML native
2. Identité utilisateur SAML basée sur AD

Votre fournisseur SAML peut avoir une combinaison de ces deux types d’identités. Par exemple, si vous avez à la fois des sous-traitants et des employés permanents au sein de votre plate-forme d’identité, l’authentification B2B SAML fonctionnera pour les deux types d’identités frontend, mais n’est obligatoire que si vous avez des comptes de type identité utilisateur SAML native.

Qu’est-ce qu’un compte fantôme AD principal ?

Un compte fantôme AD principal est un compte AD utilisé par le DaaS et mappé à une identité frontend correspondante au sein de votre fournisseur SAML.

Pourquoi est-il nécessaire de créer des comptes fantôme AD principaux ?

L’énumération de ressources DaaS ou CVAD publiées à l’aide de VDA joints à un domaine AD nécessite de créer des comptes AD au sein de la forêt Active Directory à laquelle les VDA sont joints. Mappez les ressources de votre groupe de mise à disposition DaaS aux utilisateurs des comptes fantôme ainsi qu’aux groupes AD contenant des comptes fantôme au sein du domaine AD auquel vous avez connecté vos VDA.

Important :

Seuls les utilisateurs SAML natifs sans attributs de domaine AD ont besoin de comptes fantôme AD correspondants. Si vos identités frontend sont importées depuis Active Directory, vous n’avez pas besoin d’utiliser l’authentification B2B SAMLet n’avez pas besoin de créer de comptes fantômes AD principaux.

Comment associer une identité frontend au compte fantôme AD principal correspondant ?

La méthode permettant de lier l’identité frontend à l’identité principale consiste à utiliser les UPN correspondants. Les deux identités liées doivent avoir des UPN identiques afin que Workspace puisse déterminer qu’elles représentent bien le même utilisateur qui se connecte à Workspace pour énumérer et lancer des ressources DaaS.

Citrix FAS est-il nécessaire pour l’authentification B2B SAML ?

Oui. Le service d’authentification fédérée (FAS) est requis pour l’authentification unique auprès du VDA lors du lancement lorsque vous vous connectez à Workspace à l’aide d’une méthode d’authentification fédérée.

Qu’est-ce que le « problème de non-concordance des SID » et quand peut-il survenir ?

Le « problème de non-concordance des SID » se produit lorsque l’assertion SAML contient un SID d’utilisateur frontend qui ne correspond pas au SID de l’utilisateur du compte fantôme AD. Cela peut se produire lorsque le compte qui se connecte à votre fournisseur SAML possède un SID local différent du SID de l’utilisateur du compte fantôme. Ce problème ne se produit que lorsque l’identité frontend est fournie par des outils de synchronisation AD tels qu’Entra ID Connect à partir d’une forêt AD différente de celle où le compte fantôme a été créé.

L’authentification B2B SAML empêche le « problème de non-correspondance de SID » de se produire. Le SID correct de l’utilisateur du compte fantôme est toujours récupéré via les connecteurs Citrix Cloud joints au domaine AD principal. La recherche d’utilisateur de compte fantôme est effectuée à l’aide de l’UPN de l’utilisateur frontend, qui est ensuite associé à son utilisateur de compte fantôme principal correspondant.

Exemple de problème de non-correspondance de SID : L’utilisateur frontend a été créé par Entra ID Connect et est synchronisé depuis la forêt AD 1. S-1-5-21-000000000-0000000000-0000000001-0001

Utilisateur du compte fantôme principal créé dans la forêt AD 2 et mappé aux ressources DaaS S-1-5-21-000000000-0000000000-0000000002-0002

L’assertion SAML contient les quatre attributs cip_* et cip_sid contient la valeur S-1-5-21-000000000-0000000000-0000000001-0001, qui ne correspond pas au SID du compte fantôme, ce qui déclenche une erreur.

Configurer l’application B2B SAML dans Entra ID pour les comptes invités externes

1. Connectez-vous au portail Azure.
2. Dans le menu du portail, sélectionnez Entra ID.
3. Dans le volet de gauche, sous Gérer, sélectionnez Applications d’entreprise.
4. Sélectionnez Créer votre propre application.

5. Saisissez un nom approprié pour l’application SAML, tel que Citrix Cloud SAML SSO Production B2B SAML UPN Only.

   

6. Dans le volet de navigation de gauche, sélectionnez Authentification unique puis, dans le volet de travail, cliquez sur SAML.
7. Dans la section Configuration SAML de base, sélectionnez Modifier et configurez les paramètres suivants :
   1. Dans la section Identifiant (ID d’entité), sélectionnez Ajouter un identifiant, puis entrez la valeur associée à la région dans laquelle se trouve votre locataire Citrix Cloud :
      • Pour les régions Europe, États-Unis et Asie-Pacifique Sud, saisissez https://saml.cloud.com.
      • Pour la région Japon, saisissez https://saml.citrixcloud.jp.
      • Pour la région Citrix Cloud Government, saisissez https://saml.cloud.us.
   2. Dans la section URL de réponse (URL du service consommateur d’assertion), sélectionnez Ajouter une URL de réponse, puis entrez la valeur associée à la région dans laquelle se trouve votre client Citrix Cloud :
      • Pour les régions Europe, États-Unis et Asie-Pacifique Sud, saisissez https://saml.cloud.com/saml/acs.
      • Pour la région Japon, saisissez https://saml.citrixcloud.jp/saml/acs.
      • Pour la région Citrix Cloud Government, saisissez https://saml.cloud.us/saml/acs.
   3. Dans la section URL de connexion, entrez votre URL Workspace.
   4. Dans la section URL de déconnexion (facultatif), entrez la valeur associée à la région dans laquelle se trouve votre client Citrix Cloud :
      • Pour les régions Europe, États-Unis et Asie-Pacifique Sud, saisissez https://saml.cloud.com/saml/logout/callback.
      • Pour la région Japon, saisissez https://saml.citrixcloud.jp/saml/logout/callback.
      • Pour la région Citrix Cloud Government, saisissez https://saml.cloud.us/saml/logout/callback.

   5. Dans la barre de commandes, cliquez sur Enregistrer. La section Configuration SAML de base apparaît comme suit :

      

8. Dans la section Attributs et revendications, cliquez sur Modifier pour configurer les revendications suivantes. Ces revendications apparaissent dans l’assertion SAML contenue dans la réponse SAML. Après avoir créé l’application SAML, configurez les attributs suivants.

   

   1. Pour la revendication d’identifiant d’utilisateur unique (ID de nom), définissez le format d’identifiant de nom comme non spécifié et son attribut source comme user.localuserprincipalname.
   2. Pour la revendication cip_upn, conservez la valeur par défaut user.localuserprincipalname.
   3. Pour displayName, conservez la valeur par défaut user.displayname.

   4. Dans la section Revendications supplémentaires, pour toutes les revendications restantes avec l’espace de noms http://schemas.xmlsoap.org/ws/2005/05/identity/claims, cliquez sur les points de suspension (…), puis sur Supprimer. Il n’est pas nécessaire d’inclure ces revendications car elles sont des doublons des attributs utilisateur ci-dessus.

      Une fois terminée, la section Attributs et réclamations apparaît comme illustré ci-dessous :

      

   5. Obtenez une copie du certificat de signature SAML Citrix Cloud à l’aide de cet outil en ligne tiers.
   6. Entrez https://saml.cloud.com/saml/metadata dans le champ URL, puis cliquez sur Charger.

   

9. Faites défiler la page vers le bas et cliquez sur Télécharger.

   

   

10. Configurez les paramètres de signature de l’application SAML Azure Active Directory.
11. Charger le certificat de signature SAML de production obtenu à l’étape 10 dans l’application SAML Azure Active Directory
    1. Activez Exiger des certificats de vérification.

    

    

Configurer la connexion B2B SAML Citrix Cloud

Par défaut, Citrix Cloud s’attend à ce que les attributs cip_upn, cip_email, cip_sid et cip_oid soient présents dans l’assertion SAML et empêchera la connexion SAML s’il ne sont pas transmis. Pour éviter ce problème, supprimez les vérifications de ces attributs lorsque vous créez votre nouvelle connexion SAML.

1. Créez une connexion SAML en utilisant les paramètres par défaut.
2. Accédez à la section Configuration des mappages d’attributs SAML en bas et modifiez les paramètres avant d’enregistrer la nouvelle configuration SAML.
3. Supprimez le nom d’attribut SAML de chacun des champs cip_email, cip_sidet cip_oid.
4. Ne supprimez pas cip_upn de son champ.
5. Ne supprimez aucun autre attribut de leurs champs respectifs. L’attribut displayName est toujours nécessaire pour l’interface utilisateur de Workspace et ne doit pas être modifié.

Configurer l’emplacement de ressources et les connecteurs du compte fantôme AD

Il est nécessaire de configurer un emplacement de ressources et une paire de connecteurs au sein de la forêt AD du compte fantôme principal. Citrix Cloud fait appel à ces connecteurs au sein de la forêt AD pour rechercher les identités et les attributs cip_email, cip_sid et cip_oid des utilisateurs des comptes fantôme, lorsque seul l’attribut cip_upn est transmis directement dans l’assertion SAML.

1. Créez un emplacement de ressources qui contiendra les connecteurs Citrix Cloud joints à la forêt AD du compte fantôme principal.

   

2. Nommez l’emplacement de ressources en fonction de la forêt AD où résident les comptes fantômes AD principaux que vous souhaitez utiliser.
3. Configurez une paire de connecteurs Citrix Cloud dans l’emplacement de ressources nouvellement créé.

Par exemple ccconnector1.shadowaccountforest.com ccconnector2.shadowaccountforest.com

Configurer le service d’authentification fédérée dans la forêt AD principale

Les contractants utilisateurs du compte principal auront bel et bien besoin du FAS. Lors des lancements DaaS, les utilisateurs sous-traitants ne pourront pas saisir manuellement les informations d’identification Windows pour terminer le lancement, car ils ne connaîtront probablement pas le mot de passe du compte fantôme AD.

1. Configurez un ou plusieurs serveurs FAS dans la forêt AD principale dans laquelle vos comptes fantôme ont été créés.
2. Ensuite, liez les serveurs FAS au même emplacement de ressources qui contient une paire de connecteurs Citrix Cloud joints à la forêt AD principale dans laquelle vos comptes fantôme ont été créés.

Configurer des suffixes d’UPN alternatifs dans le domaine AD

Important :

Un UPN n’est pas la même chose que l’adresse e-mail des utilisateurs. Dans de nombreux cas, ils ont la même valeur pour une facilité d’utilisation, mais l’UPN et l’e-mail peuvent souvent avoir des valeurs différentes et sont définis dans différents attributs Active Directory et dans différents attributs d’utilisateur Entra ID. Cette solution dépend de la correspondance de l’UPN entre les identités frontend et principale, et non de la correspondance des e-mails.

Vous pouvez utiliser le suffixe UPN implicite pour votre domaine s’il est routable publiquement dans DNS ou ajouter un suffixe UPN alternatif correspondant pour chaque utilisateur frontend externe que vous souhaitez inviter dans vos locataires Okta ou Azure AD. Si AD utilise yourdomain.local comme UPN implicite, vous devrez choisir un suffixe UPN alternatif comme yourdomain.com. Entra ID ne vous permettra pas d’ajouter yourdomain.local dans les noms de domaine personnalisés.

Par exemple, si vous invitez un utilisateur externe contractoruser@hotmail.co.uk et que vous souhaitez l’associer au compte fantôme AD principal contractoruser@yourforest.com, ajoutez yourforest.com comme suffixe UPN secondaire dans votre forêt AD.

Ajouter des suffixes d’UPN alternatifs dans Active Directory à l’aide de l’interface utilisateur Active Directory Domains and Trusts

1. Connectez-vous à un contrôleur de domaine au sein de votre forêt AD principale.
2. Ouvrez la boîte de dialogue Exécuter, saisissez domain.msc, puis cliquez sur OK.
3. Dans la fenêtre Active Directory Domains and Trusts, cliquez avec le bouton droit sur Active Directory Domains and Trusts, puis sélectionnez Propriétés.

4. Sous l’onglet Suffixes d’UPN, dans la zone « Suffixes d’UPN alternatifs », ajoutez un autre suffixe d’UPN, puis sélectionnez Ajouter.

   

5. Cliquez sur OK.

Gérer les suffixes d’UPN de votre forêt AD principale à l’aide de PowerShell

Pour créer les UPN de compte fantôme nécessaires, vous devrez peut-être ajouter un grand nombre de nouveaux suffixes d’UPN à votre forêt AD principale. Le nombre de suffixes d’UPN alternatifs à ajouter à la forêt AD principale dépend du nombre d’utilisateurs externes que vous souhaitez inviter dans votre locataire de fournisseur SAML.

Voici quelques commandes PowerShell à utiliser si vous devez créer un grand nombre de suffixes d’UPN alternatifs.

  # 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-->

Configurer un compte AD Shadow dans votre forêt AD principale

1. Créez un utilisateur de compte fantôme AD.

2. L’UPN implicite de la forêt AD tel que yourforest.local est sélectionné par défaut pour les nouveaux utilisateurs AD. Sélectionnez le suffixe d’UPN alternatif approprié créé précédemment. Par exemple, sélectionnez yourforest.com comme suffixe UPN de l’utilisateur du compte fantôme.

   

   Vous pouvez également mettre à jour l’UPN de l’utilisateur du compte fantôme via PowerShell.

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

3. L’UPN de l’utilisateur du compte fantôme doit correspondre exactement à l’UPN de l’utilisateur de l’identité frontend externe.
4. Testez la connexion de l’utilisateur frontend à Workspace.
5. Vérifiez que toutes les ressources attendues sont énumérées dans Workspace une fois la connexion réussie. Les ressources mappées au compte fantôme AD devraient alors s’afficher.

Configurer l’UPN de l’utilisateur Entra ID invité pour qu’il corresponde à l’UPN du compte fantôme AD

Lorsque des utilisateurs externes sont invités à rejoindre un locataire Entra ID, un UPN est automatiquement généré pour indiquer qu’il s’agit d’utilisateurs externes. L’utilisateur Entra ID externe se verra automatiquement attribuer le suffixe UPN @Entra IDtenant.onmicrosoft.com, qui ne convient pas à une utilisation avec B2B SAML et ne correspondra pas à votre compte fantôme AD. L’UPN devra être mis à jour de sorte qu’il corresponde à un domaine DNS importé dans Entra ID et au suffixe d’UPN alternatif que vous avez créé dans votre forêt AD.

1. Importez un domaine personnalisé dans Entra ID qui correspond au suffixe UPN secondaire que vous avez ajouté à la forêt AD.

   

2. Invitez un utilisateur invité tel que contractoruser@hotmail.co.uk et assurez-vous que l’utilisateur invité accepte l’invitation Microsoft au locataire Entra ID.

   Exemple de format d’UPN pour un utilisateur invité externe généré par Microsoft. contractoruser_hotmail.co.uk#EXT#@yourEntra IDtenant.onmicrosoft.com

   

   

   Important :

   Citrix Cloud et Workspace ne peuvent pas utiliser d’UPN contenant le caractère # pour l’authentification SAML.

3. Installez les modules Azure PowerShell Graph nécessaires pour vous permettre de gérer les utilisateurs Entra ID.

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

4. Connectez-vous à votre locataire Entra ID à l’aide d’un compte administrateur global et avec l’étendue Directory.AccessAsUser.All.

   Important :

   Si vous utilisez un compte moins privilégié ou ne spécifiez pas l’étendue Directory.AccessAsUser.All, vous ne pourrez pas terminer l’étape 4 et mettre à jour l’UPN de l’utilisateur invité.

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

5. Mettez à jour l’utilisateur Entra ID avec un UPN qui correspond à l’UPN que vous avez configuré pour votre compte fantôme AD.

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

6. Obtenez la liste complète des utilisateurs invités externes au sein de votre locataire Entra ID (facultatif).

   

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

7. Obtenez l’identité de l’utilisateur invité dont le nom UPN doit être mis à jour, puis mettez à jour son suffixe 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. Vérifiez que l’identité de l’utilisateur invité peut être trouvée à l’aide de son UPN récemment mis à jour.

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

Test de la solution B2B SAML

Une fois que toutes les étapes de ce document ont été effectuées dans AD, Citrix Cloud et votre fournisseur SAML, vous devez tester la connexion et vérifier que la liste de ressources correcte est affichée pour l’utilisateur invité dans Workspace.

Citrix recommande d’utiliser l’extension de navigateur SAML-tracer pour tous les débogages SAML. Cette extension est disponible pour la plupart des navigateurs Web courants. L’extension décode les requêtes et les réponses codées en Base64 en langage XML SAML, et les fournit donc en dans un format intelligible.

Exemple d’une assertion B2B SAML utilisant uniquement cip_upn pour l’authentification capturée à l’aide du traceur SAML.

1. Mappez les ressources DaaS appropriées aux utilisateurs ou groupes des comptes basés sur AD ou aux groupes qui les contiennent.

2. Démarrez l’extension de l’outil de navigateur SAML-Tracer et capturez l’intégralité du flux d’ouverture et de fermeture de session.

3. Connectez-vous à Workspace à l’aide de l’attribut spécifié dans le tableau pour l’utilisateur de type frontend que vous souhaitez tester.

   Connexion de l’utilisateur invité Entra ID : l’utilisateur sous-traitant que vous avez invité dans votre locataire Entra ID en tant qu’utilisateur invité a l’adresse e-mail contractoruser@hotmail.co.uk.

   Entrez l’adresse e-mail de l’utilisateur invité lorsque vous y êtes invité par Entra ID.

   OU

   Connexion utilisateur Entra ID reposant sur AD/utilisateur Entra ID natif : ces utilisateurs Entra ID auront des UPN au format adbackeduser@yourforest.com ou nativeuser@yourforest.com.

   Entrez l’UPN de l’utilisateur lorsque vous y êtes invité par Entra ID.

4. Vérifiez que l’assertion ne contient que l’attribut cip_upn pour l’authentification, ainsi que l’attribut displayName requis par l’interface utilisateur de Workspace.

5. Vérifiez que les ressources DaaS nécessaires s’affichent bien dans l’interface utilisateur.

Résolution des problèmes de la solution B2B SAML

UPN incorrect envoyé dans l’assertion SAML

Cause : cela ne peut se produire que pour les comptes B2B importés du locataire Entra ID 1 vers le locataire Entra ID 2. L’UPN incorrect peut être envoyé dans l’assertion SAML lors de l’utilisation d’utilisateurs B2B importés d’autres locataires Entra ID. Si user.userprincipalname est utilisé et que l’utilisateur final se connecte avec un utilisateur B2B importé d’un autre locataire Entra ID, la valeur incorrecte pour cip_upn sera envoyée dans l’assertion SAML. La valeur de cip_upn utilisée dans l’assertion SAML proviendra du locataire Entra ID source qui contient l’utilisateur B2B en tant que membre. L’utilisation de user.localuserprincipalname garantit que la valeur de cip_upn est extraite du locataire Entra ID avec l’utilisateur B2B invité en tant qu’invité.

Erreurs d’attribut cip_* manquant

Cause 1 : L’attribut SAML n’est pas présent dans l’assertion SAML mais Citrix Cloud est configuré pour s’attendre à le recevoir. Vous n’avez pas réussi à supprimer les attributs cip_* inutiles de la connexion SAML Citrix Cloud dans la section Attributs SAML. Déconnectez et reconnectez SAML pour supprimer les références aux attributs cip_* inutiles.

Cause 2 : Cette erreur peut également se produire s’il n’existe aucun compte fantôme AD associé que les connecteurs Citrix Cloud peuvent rechercher dans la forêt AD principale. Vous avez peut-être correctement configuré l’identité frontend, mais l’identité du compte fantôme AD principal associée à un UPN n’existe pas ou est introuvable.

La connexion réussit, mais aucune ressource DaaS ne s’affiche une fois l’utilisateur connecté à Workspace

Cause : Cela est probablement dû à des mappages d’UPN incorrects entre les identités frontend et principale.

Assurez-vous que l’UPN des deux identités frontend et principale sont exactement identiques et représentent le même utilisateur qui se connecte à Workspace. Vérifiez que le groupe de mise à disposition DaaS contient des mappages vers les bons utilisateurs du compte fantôme AD ou les groupes AD qui les contiennent.

Lors du lancement des ressources DaaS, l’authentification unique via le FAS auprès des VDA joints au domaine AD échoue

Lorsque les utilisateurs de Workspace tentent de lancer des ressources DaaS, ils sont invités à saisir leurs informations d’identification Windows dans GINA. L’ID d’événement 103 s’affiche également dans les journaux d’événements Windows de vos serveurs FAS.

[S103] Server [CC:FASServer] requested UPN [frontenduser@yourforest.com] SID S-1-5-21-000000000-0000000000-0000000001-0001, but lookup returned SID S-1-5-21-000000000-0000000000-0000000001-0002. [correlation: cc#967472c8-4342-489b-9589-044a24ca57d1]

Cause : votre déploiement B2B SAML souffre du « problème de non-correspondance de SID ». Des identités frontend contiennent des SID provenant d’une forêt AD différente de la forêt AD du compte fantôme principal.
Ne transmettez pas l’attribut cip_sid dans l’assertion SAML.

L’ouverture de session échoue pour les utilisateurs connectés à AD lorsque le même suffixe d’UPN existe dans plusieurs forêts AD connectées

Citrix Cloud possède plusieurs emplacements de ressources et connecteurs associés à différentes forêts AD. La connexion échoue lorsque des utilisateurs de comptes basés sur AD importés dans Entra ID à partir d’une forêt AD différente de la forêt AD du compte fantôme sont utilisés.

La forêt AD 1 est synchronisée avec Entra ID pour créer des utilisateurs frontend avec des UPN tels que frontenduser@yourforest.com.

La forêt AD 2 contient les comptes fantômes principaux avec des UPN tels que frontenduser@yourforest.com.

Cause : votre déploiement B2B SAML présente un « problème d’ambiguïté d’UPN ». Citrix Cloud ne parvient pas à déterminer les connecteurs à utiliser pour rechercher l’identité principale de l’utilisateur.

Ne transmettez pas l’attribut cip_sid dans l’assertion SAML.
L’UPN de votre utilisateur existe dans plusieurs forêts AD connectées à Citrix Cloud.

Configurer la connexion SAML Citrix Cloud

Tous les flux de connexion Citrix doivent être initiés par le fournisseur de services à l’aide d’une URL d’espace de travail ou d’une URL Citrix Cloud GO.

Obtenez les points de terminaison SAML de l’application SAML Entra ID à partir de votre portail Entra ID pour accéder à Citrix Cloud.

Exemples de points de terminaison SAML Entra ID à utiliser dans la connexion SAML Citrix Cloud

Important :

Les points de terminaison SAML EntraID SSO et de déconnexion sont la même URL.

• ID d’entité du fournisseur d’identité : https://sts.windows.net/<yourEntraIDTenantID>
• URL du service SSO du fournisseur d’identité : https://login.microsoftonline.com/<yourEntraIDTenantID>/saml2
• URL de déconnexion du fournisseur d’identité : https://login.microsoftonline.com/<yourEntraIDTenantID>/saml2