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

Avant d’appliquer les recommandations de cet article, il est essentiel de savoir si l’authentification SAML B2B convient à votre cas d’utilisation. 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 poursuivre, assurez-vous de bien comprendre les scénarios dans lesquels l’authentification SAML B2B est appropriée et quels types d’identités 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’authentification SAML B2B augmente la charge des connecteurs Citrix Cloud, car ils doivent rechercher l’adresse e-mail, le SID et l’OID des utilisateurs pour chaque ouverture de session Workspace au lieu de transmettre ces valeurs dans l’assertion SAML. Si l’authentification SAML B2B ne s’avère pas particulièrement nécessaire, il est préférable de transmettre les quatre attributs cip_* dans l’assertion SAML afin de garantir les performances de Citrix Cloud Connector.

Logiciels requis

• Une application SAML spécifiquement configurée pour l’authentification SAML B2B, qui envoie uniquement l’attribut cip_upn à des fins d’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 autre suffixe UPN ajouté à la forêt AD principale dans laquelle 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 utiliser SAML B2B ?

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 au contractant un accès temporaire à Citrix Workspace en utilisant l’identité existante de l’utilisateur, telle que l’adresse e-mail d’un contractant ou une adresse e-mail extérieure à votre organisation. 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 SAML B2B ?

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 être présents dans l’assertion SAML et renseignés à l’aide des attributs utilisateur AD. 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 demeure toujours nécessaire de transmettre l’attribut displayName pour tous les flux SAML, y compris 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é utilisateur qui n’existe que dans le répertoire de votre fournisseur 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 dans le locataire Entra ID 1 et qui est invité à rejoindre d’autres locataires Entra ID tels que le locataire Entra ID 2 en tant qu’utilisateur invité. L’application SAML B2B 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ôme correspondants au compte AD principal 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 sur la manière d’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 Propriétés d’un utilisateur Microsoft Entra B2B Collaboration

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ôme du compte AD principal ne sont pas nécessaires 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 des 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 contractants et des employés permanents au sein de votre plateforme d’identité, l’authentification B2B SAML fonctionnera pour les deux types d’identités frontend, mais n’est obligatoire que si certains comptes utilisent un 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 de recourir à l’authentification B2B SAML ni de créer des comptes AD fantômes 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 SAML B2B ?

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-concordance des 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 de l’utilisateur du compte fantôme s’effectue à l’aide de l’UPN de l’utilisateur frontend, qui est ensuite mis en correspondance avec l’utilisateur du compte fantôme principal associé.

Exemple de problème de non-concordance des 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.

Configuration de l’application SAML B2B 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. Entrez 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 de l’Europe, des États-Unis et du sud de l’Asie-Pacifique, entrez https://saml.cloud.com.
      • Pour la région du Japon, entrez https://saml.citrixcloud.jp.
      • Pour la région Citrix Cloud Government, entrez 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 de l’Europe, des États-Unis et du sud de l’Asie-Pacifique, entrez https://saml.cloud.com/saml/acs.
      • Pour la région du Japon, entrez https://saml.citrixcloud.jp/saml/acs.
      • Pour la région Citrix Cloud Government, entrez 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 de l’Europe, des États-Unis et du sud de l’Asie-Pacifique, entrez https://saml.cloud.com/saml/logout/callback.
      • Pour la région du Japon, entrez https://saml.citrixcloud.jp/saml/logout/callback.
      • Pour la région Citrix Cloud Government, entrez 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 de l’identifiant utilisateur unique (ID de nom), définissez le format de l’identifiant de nom sur Non spécifié et son attribut source sur user.localuserprincipalname.
   2. Pour la revendication cip_upn, laissez la valeur par défaut de user.localuserprincipalname.
   3. Pour displayName, laissez la valeur par défaut de user.displayname.

   4. Dans la section Autres revendications, pour toutes les revendications restantes avec l’espace de noms http://schemas.xmlsoap.org/ws/2005/05/identity/claims, cliquez sur le bouton représentant des 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.

      Lorsque vous avez terminé, la section Attributs et revendications 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 et 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 à Citrix Cloud via l’authentification SAML B2B

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. En effet, pour lancer les services DaaS, ces utilisateurs ne pourront pas saisir manuellement les informations d’identification Windows , 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 identique à l’adresse e-mail de l’utilisateur. Dans de nombreux cas, leur valeur est la même afin de faciliter l’utilisation, mais l’UPN et l’adresse e-mail peuvent souvent avoir des valeurs différentes, car ils sont définis dans différents attributs Active Directory et dans différents attributs utilisateur Entra ID. Cette solution dépend de la correspondance de l’UPN et des identités frontend et backend, et non de la correspondance des adresses e-mail.

Vous pouvez utiliser le suffixe UPN implicite pour votre domaine s’il est routable publiquement dans le DNS ou ajouter un autre suffixe UPN 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 devez choisir un autre suffixe UPN tel que 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 à un compte fantôme AD principal contractoruser@yourforest.com, ajoutez yourforest.com comme suffixe alternatif d’UPN 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, tapez 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 fantôme AD dans la 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 d’UPN pour 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’identité frontend de l’utilisateur externe.
4. Testez la connexion de l’utilisateur frontend à Workspace.
5. Une fois la connexion réussie, vérifiez que toutes les ressources attendues sont énumérées dans Workspace. Les ressources mappées au compte fantôme AD devraient alors s’afficher.

Configurer l’UPN utilisateur Guest Entra ID de sorte qu’il corresponde à l’UPN du compte AD fantôme

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 externe Entra ID se verra automatiquement attribuer le suffixe d’UPN @Entra IDtenant.onmicrosoft.com, qui ne convient pas à l’utilisation de l’authentification SAML B2B et ne correspond pas au compte AD fantôme. 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 d’UPN alternatif que vous avez ajouté à votre forêt AD.

   

2. Invitez un utilisateur, tel que contractoruser@hotmail.co.uk, et assurez-vous qu’il accepte l’invitation Microsoft adressée 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. Pour pouvoir gérer les utilisateurs Entra ID, installez les modules Azure PowerShell Graph requis.

   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 avec l’étendue Directory.AccessAsUser.All.

   Important :

   Si vous utilisez un compte avec des privilèges moindres ou si vous 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 correspondant à l’UPN 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 l’UPN doit être mis à jour, puis mettez à jour son suffixe.

   $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 se retrouver à l’aide de l’UPN récemment mis à jour.

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

Test de la solution d’authentification SAML B2B

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’assertion SAML B2B utilisant uniquement l’attribut cip_upn pour l’authentification capturée à l’aide d’un 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.

   Ouverture de session utilisateur invité Entra ID : l’utilisateur contractant que vous avez invité à rejoindre votre locataire Entra ID possède 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

   Utilisateur Entra ID basé sur AD ou connexion 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 liés à la solution SAML B2B

UPN incorrect envoyé dans l’assertion SAML

Cause : cela peut se produire uniquement 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 depuis d’autres locataires Entra ID. Si user.userprincipalname est utilisé et que l’utilisateur se connecte avec un utilisateur B2B importé depuis un autre locataire Entra ID, la valeur incorrecte pour cip_upn est envoyée dans l’assertion SAML. La valeur de cip_upn utilisée dans l’assertion SAML provient 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 provient 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] Le serveur [CC:FASServer] a demandé l’UPN [frontenduser@yourforest.com] SID S-1-5-21-000000000-0000000000-0000000001-0001, mais la recherche a renvoyé SID S-1-5-21-000000000-0000000000-0000000001-0002. [corrélation : cc #967472c8-4342-489b-9589-044a24ca57d1]

Cause : votre déploiement SAML B2B présente un « problème de non-concordance des 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. L’ouverture de session échoue lorsque des utilisateurs basés sur AD et importés dans Entra ID depuis une forêt AD différente de celle du compte fantôme AD sont utilisés.

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

La forêt AD 2 contient les comptes fantômes principaux dotés d’UPN tels que frontenduser@yourforest.com.

Cause : votre déploiement SAML B2B 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.