SAML avec Entra ID pour les identités d’invités et B2B pour l’authentification de l’espace de travail

• Il est essentiel que vous compreniez si le SAML B2B est approprié pour votre cas d’utilisation d’authentification avant de suivre cet article. Lisez attentivement les descriptions des cas d’utilisation et la FAQ avant de décider de mettre en œuvre cette solution SAML de cas particulier. Avant de continuer, assurez-vous de bien comprendre les scénarios où le SAML B2B est approprié et les types d’identités que vous devez utiliser.

• Prérequis

• Une application SAML spécifiquement configurée pour être utilisée avec le SAML B2B qui envoie uniquement cip_upn pour l’authentification au sein de l’assertion SAML.
• Utilisateurs FrontEnd au sein de votre fournisseur SAML.
• Un emplacement de ressources contenant une paire de connecteurs Citrix Cloud™ joints à la forêt et au domaine AD où les comptes fantômes AD sont créés.
• Utilisez soit l’UPN implicite, soit ajoutez un suffixe UPN alternatif à la forêt AD backend où les comptes fantômes AD sont créés.
• Comptes fantômes AD backend avec des UPN correspondants. - Ressources DaaS ou CVAD mappées aux utilisateurs des comptes fantômes AD. - Un ou plusieurs serveurs FAS liés au même emplacement de ressources.

FAQ

Pourquoi devrais-je utiliser le SAML B2B ?

Il est très courant pour les grandes organisations d’inviter des sous-traitants et des employés temporaires sur leur plateforme d’identité. L’objectif est d’accorder au sous-traitant un accès temporaire à Citrix Workspace™ en utilisant l’identité existante de l’utilisateur, telle qu’une adresse e-mail de sous-traitant, ou une adresse e-mail externe à votre organisation. Le B2B SAML permet l’utilisation d’identités frontend natives ou d’invités qui n’existent pas dans le domaine AD où les ressources DaaS sont publiées.

Qu’est-ce que le SAML B2B ?

Les trois autres attributs utilisateur AD, objectSID, objectGUID et mail, requis pour l’authentification, sont obtenus à l’aide des connecteurs Citrix Cloud joints au domaine AD où le compte fantôme AD existe. Ils n’ont plus besoin d’être inclus dans l’assertion SAML lors d’un flux de connexion SAML pour Workspace ou Citrix Cloud.

Important :

Il est toujours nécessaire d’envoyer le displayName pour tous les flux SAML, y compris le B2B SAML. Le displayName est requis par l’interface utilisateur de Workspace pour afficher correctement le nom complet de l’utilisateur Workspace.

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

Un utilisateur SAML natif est une identité d’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 sur site car elles ne sont pas créées via des outils de synchronisation AD comme Entra ID Connect. Elles nécessitent des comptes fantômes AD backend correspondants pour pouvoir énumérer et lancer des ressources DaaS ; l’utilisateur SAML natif doit être mappé à un compte correspondant au sein d’Active Directory.

Qu’est-ce qu’un utilisateur B2B importé d’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 est invité dans 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 qu’IdP SAML. Les utilisateurs B2B nécessitent des comptes fantômes AD backend correspondants pour pouvoir énumérer et lancer des ressources DaaS. L’utilisateur B2B doit être mappé à un compte fantôme correspondant au sein d’Active Directory.

Reportez-vous à la documentation Microsoft pour plus de détails sur les utilisateurs B2B et sur la façon 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 personnel Propriétés d’un utilisateur de collaboration B2B Microsoft Entra

Qu’est-ce qu’une identité d’utilisateur SAML adossée à AD ?

Un utilisateur SAML adossé à AD est une identité d’utilisateur qui existe dans le répertoire de votre fournisseur SAML, comme Entra ID ou Okta, et également dans votre forêt AD sur site. Ces identités contiennent des attributs utilisateur sur site car elles sont créées via des outils de synchronisation AD comme Entra ID Connect. Les comptes fantômes AD backend ne sont pas requis pour ces utilisateurs car ils contiennent des SID et OID sur site 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 façon dont elles ont été créées au sein du fournisseur SAML.

1. Identité d’utilisateur SAML native
2. Identité d’utilisateur SAML adossée à AD

Votre fournisseur SAML peut avoir un mélange 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 plateforme d’identité, le B2B SAML fonctionnera pour les deux types d’identités Frontend, mais n’est obligatoire que si vous avez des comptes de type identité d’utilisateur SAML native.

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

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

Pourquoi les comptes fantômes AD backend sont-ils nécessaires ?

Pour énumérer les ressources DaaS ou CVAD publiées à l’aide de VDA joints à un domaine AD, des comptes AD au sein de la forêt Active Directory à laquelle les VDA sont joints sont nécessaires. Mappez les ressources de votre groupe de mise à disposition DaaS aux utilisateurs de comptes fantômes et aux groupes AD contenant des comptes fantômes au sein du domaine AD auquel vous avez joint vos VDA.

Important : - > - > Seuls les utilisateurs SAML natifs sans attributs de domaine AD nécessitent des comptes fantômes AD correspondants. Si vos identités FrontEnd sont importées d’Active Directory, vous n’avez pas besoin d’utiliser B2B SAML et n’avez pas besoin de créer de comptes fantômes AD Backend.

Comment lier l’identité FrontEnd au compte fantôme AD Backend correspondant ?

    -  La méthode utilisée pour lier l'identité FrontEnd et l'identité Backend consiste à utiliser des UPN correspondants. Les deux identités liées doivent avoir des UPN identiques afin que Workspace puisse déterminer qu'elles représentent le même utilisateur final qui doit se connecter à Workspace, et pour énumérer et lancer les ressources DaaS.

Important

    -  > Une seule identité frontend ne peut être mappée qu'à une seule identité backend dans une seule forêt/domaine AD. L'énumération des ressources DaaS se fera en utilisant une seule valeur SID obtenue à partir de la recherche de compte fantôme AD effectuée par les connecteurs Citrix Cloud corrects. Vous ne pouvez pas créer une relation un à plusieurs en utilisant un seul utilisateur frontend qui correspond à plusieurs comptes fantômes AD avec le même suffixe UPN. Le compte fantôme AD backend ne doit exister que dans une seule forêt/domaine AD.
    -  >
    -  > Pris en charge en utilisant une correspondance UPN non ambiguë entre les identités Frontend et Backend Utilisateur FrontEnd `(user@yourforest.com)` > Utilisateur Backend dans la forêt AD 1 `(UPN user@yourforest.com)`

Non pris en charge car il y a une ambiguïté UPN lors de la tentative de faire correspondre une identité Frontend à une identité Backend Utilisateur FrontEnd (user@yourforest1.com) > Utilisateur Backend dans la forêt AD 1 (UPN user@yourforest1.com) > Utilisateur Backend dans la forêt AD 2 (UPN user@yourforest1.com)

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

Oui. FAS est requis pour le SSON vers le VDA lors du lancement, lorsque toute méthode d’authentification fédérée est utilisée pour se connecter à Workspace.

Qu’est-ce que le « problème d’incompatibilité SID » et quand peut-il se produire ?

Le « problème d’incompatibilité SID » se produit lorsque l’assertion SAML contient un SID pour un utilisateur FrontEnd qui ne correspond pas au SID de l’utilisateur du compte fantôme AD. Cela peut arriver lorsque le compte se connectant à votre fournisseur SAML possède un SID sur site, qui n’est pas le même que le SID de l’utilisateur du compte fantôme. Cela ne peut se produire que lorsque l’identité Frontend est provisionnée par des outils de synchronisation AD comme Entra ID Connect et à partir d’une forêt AD différente de celle où le compte fantôme a été créé.

B2B SAML empêche le « problème d’incompatibilité SID » de se produire. Le SID correct est toujours récupéré pour l’utilisateur du compte fantôme via les connecteurs Citrix Cloud joints au domaine AD backend. La recherche de l’utilisateur du compte fantôme est effectuée à l’aide de l’UPN de l’utilisateur FrontEnd, qui est ensuite mis en correspondance avec son utilisateur de compte fantôme backend correspondant.

Exemple du problème d’incompatibilité 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

L’utilisateur du compte fantôme Backend a été créé au sein de 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 et déclenche une erreur.

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

1. Connectez-vous au portail Azure.
2. Dans le menu du portail, sélectionnez Entra ID.
3. Dans le volet 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 gauche, sélectionnez Authentification unique et, dans le volet de travail, cliquez sur SAML.
7. Dans la section Configuration SAML de base, cliquez sur Modifier et configurez les paramètres suivants :
   1. Dans la section Identificateur (ID d’entité), sélectionnez Ajouter un identificateur, puis saisissez 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 saisissez 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/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, saisissez l’URL de votre Workspace.
   4. Dans la section URL de déconnexion (facultatif), saisissez 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/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. Après la création de l’application SAML, configurez les attributs suivants.

   1. Pour la revendication Identificateur d’utilisateur unique (ID de nom), définissez le format d’identificateur de nom comme non spécifié et son attribut source comme user.localuserprincipalname.
   2. Pour la revendication cip_upn, laissez la valeur par défaut user.localuserprincipalname.
   3. Pour displayName, laissez la valeur par défaut user.displayname.
   4. Pour la revendication givenName, mettez à jour la valeur par défaut pour qu’elle soit user.givenname.
   5. Pour la revendication familyName, mettez à jour la valeur par défaut pour qu’elle soit user.surname.

   6. Dans la section Revendications supplémentaires, pour toute revendication restante avec l’espace de noms http://schemas.xmlsoap.org/ws/2005/05/identity/claims, cliquez sur le bouton des points de suspension (…) et cliquez 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é, la section Attributs et revendications apparaît comme illustré ci-dessous :

      

   7. Obtenez une copie du certificat de signature SAML Citrix Cloud à l’aide de cet outil en ligne tiers.
   8. Saisissez https://saml.cloud.com/saml/metadata dans le champ URL et cliquez sur Charger.

   

9. Faites défiler la page jusqu’en bas et cliquez sur Télécharger.

   

   

10. Configurez les paramètres de signature de l’application SAML Entra ID.
11. Téléchargez le certificat de signature SAML de production obtenu à l’étape 10 dans l’application SAML Entra ID.

12. Activez Exiger des certificats de vérification.

    

    

Configurer la connexion SAML B2B de Citrix Cloud

Par défaut, Citrix Cloud s’attend à ce que cip_upn, cip_email, cip_sid et cip_oid soient présents dans l’assertion SAML et la connexion SAML échouera si ces attributs ne sont pas envoyés. Pour éviter cela, supprimez les vérifications de ces attributs lorsque vous créez votre nouvelle connexion SAML.

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

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

Un emplacement de ressources et une paire de connecteurs au sein de la forêt AD du compte fantôme backend sont nécessaires. Citrix Cloud a besoin de connecteurs au sein de cette forêt AD pour rechercher les identités et les attributs des utilisateurs du compte fantôme, tels que cip_email, cip_sid et cip_oid, lorsque seul cip_upn est fourni directement dans l’assertion SAML.

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

   

2. Nommez l’emplacement des ressources de manière à ce qu’il corresponde à la forêt AD qui contient les comptes fantômes AD backend que vous souhaitez utiliser.
3. Configurez une paire de connecteurs Citrix Cloud au sein de l’emplacement de ressources nouvellement créé.

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

Configurer FAS au sein de la forêt AD backend

Les utilisateurs frontend sous-traitants nécessiteront impérativement FAS. Lors des lancements DaaS, les utilisateurs sous-traitants ne pourront pas saisir manuellement les informations d’identification Windows pour finaliser 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 au sein de la forêt AD backend où vos comptes fantômes ont été créés.
2. Liez les serveurs FAS au même emplacement de ressources qui contient une paire de connecteurs Citrix Cloud joints à la forêt AD backend où vos comptes fantômes ont été créés.

Configurer des suffixes UPN alternatifs au sein de votre domaine AD

Important :

Un UPN n’est pas la même chose que l’adresse e-mail de l’utilisateur. Dans de nombreux cas, ils ont la même valeur pour faciliter l’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 utilisateur Entra ID. Cette solution dépend de la correspondance des UPN entre les identités frontend et backend et non de la correspondance des e-mails.

Vous pouvez utiliser le suffixe UPN implicite de 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 Entra ID. 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 à un compte fantôme AD backend contractoruser@yourforest.com, ajoutez yourforest.com comme suffixe UPN ALT au sein de votre forêt AD.

Ajouter des suffixes UPN alternatifs dans Active Directory à l’aide de l’interface utilisateur Domaines et approbations Active Directory

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

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

   

5. Cliquez sur OK.

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

Vous devrez peut-être ajouter un grand nombre de nouveaux suffixes UPN à votre forêt AD backend afin de créer les UPN de compte fantôme nécessaires. Le nombre de suffixes UPN alternatifs que vous devrez ajouter à votre forêt AD backend dépendra du nombre d’utilisateurs externes différents que vous choisissez d’inviter dans votre locataire de fournisseur SAML.

Voici un script PowerShell pour y parvenir si un grand nombre de nouveaux suffixes UPN alternatifs doivent être créés.

# 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 au sein de votre forêt AD backend

1. Créez un nouvel 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 UPN alternatif approprié que vous avez créé précédemment. Par exemple, sélectionnez yourforest.com comme suffixe UPN de l’utilisateur du compte fantôme.

   

   L’UPN de l’utilisateur du compte fantôme peut également être mis à jour via PowerShell.

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

   Important

   Windows AD PowerShell vous permettra de créer des utilisateurs de compte fantôme avec n’importe quel suffixe UPN que vous spécifiez, même si ce suffixe UPN n’existe pas dans votre forêt AD. Le suffixe UPN alternatif que vous souhaitez utiliser doit exister au sein de la forêt AD, car les connecteurs Citrix Cloud dépendent de cette liste pour rechercher les utilisateurs de compte fantôme backend. Si le suffixe UPN alternatif n’apparaît pas dans la forêt AD comme indiqué dans la capture d’écran ci-dessus, Citrix Cloud ne pourra pas faire correspondre votre identité frontend à un compte fantôme AD backend approprié.

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 après la réussite de la connexion. Les ressources mappées au compte fantôme AD devraient apparaître.

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

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

1. Importez un domaine personnalisé dans Entra ID qui correspond au suffixe UPN alternatif que vous avez ajouté à votre 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 UPN d’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 les 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 d’administrateur global et avec l’étendue Directory.AccessAsUser.All.

   Important :

   Si vous utilisez un compte moins privilégié ou si vous ne spécifiez pas l’étendue Directory.AccessAsUser.All, vous ne pourrez pas effectuer 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 l’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 nouvellement mis à jour.

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

Test de la solution SAML B2B

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

Citrix recommande l’utilisation de 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 encodées en Base64 en XML SAML, ce qui les rend lisibles par l’homme.

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

1. Mappez les ressources DaaS correctes aux utilisateurs ou groupes de comptes AD et fantômes qui les contiennent.

2. Démarrez l’extension de navigateur SAML tracer et capturez l’intégralité du flux de connexion et de déconnexion.

3. Connectez-vous à Workspace en utilisant l’attribut spécifié dans le tableau pour le type d’utilisateur frontal que vous souhaitez tester.

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

   Saisissez l’adresse e-mail de l’utilisateur invité lorsque Entra ID vous y invite.

   OU

   Connexion des utilisateurs Entra ID adossés à AD/utilisateurs Entra ID natifs : Ces utilisateurs Entra ID auront des UPN au format adbackeduser@yourforest.com ou nativeuser@yourforest.com.

   Saisissez l’UPN de l’utilisateur lorsque Entra ID vous y invite.

4. Vérifiez que l’assertion contient uniquement l’attribut cip_upn pour l’authentification et qu’elle contient également l’attribut displayName requis par l’interface utilisateur de Workspace.

5. Vérifiez que l’utilisateur peut voir les ressources DaaS requises dans l’interface utilisateur.

Dépannage de la solution SAML B2B

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 tirée 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’y a pas de compte fantôme AD correspondant que les connecteurs Citrix Cloud peuvent rechercher dans votre forêt AD backend. Vous avez peut-être correctement configuré l’identité frontend, mais l’identité du compte fantôme AD backend avec un UPN correspondant n’existe pas ou ne peut pas être trouvée.

La connexion réussit, mais aucune ressource DaaS n’est affichée après que l’utilisateur s’est connecté à Workspace

Cause : Cela est très probablement dû à des mappages UPN d’identité frontend-backend incorrects.

Assurez-vous que les 2 UPN pour les identités frontend et backend correspondent exactement et représentent le même utilisateur final qui se connecte à Workspace. Vérifiez que le groupe de mise à disposition DaaS contient des mappages vers les utilisateurs de compte fantôme AD corrects ou les groupes AD qui les contiennent.

Lors du lancement des ressources DaaS, le SSON FAS vers les VDA joints au domaine AD échoue

Lors de la tentative de lancement des ressources DaaS, l’utilisateur final de Workspace est invité à saisir ses informations d’identification Windows dans le GINA. De plus, l’ID d’événement 103 apparaît dans les journaux d’événements Windows sur 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. [correlation: cc#967472c8-4342-489b-9589-044a24ca57d1]

Cause : Votre déploiement SAML B2B souffre du « problème d’inadéquation des SID ». Vous avez des identités frontend qui contiennent des SID d’une forêt AD différente de la forêt AD du compte fantôme backend. N’envoyez pas cip_sid dans l’assertion SAML.

La connexion échoue pour les utilisateurs adossés à AD lorsque le même suffixe UPN existe dans plusieurs forêts AD connectées

Citrix Cloud dispose de plusieurs emplacements de ressources et de connecteurs joints à différentes forêts AD. La connexion échoue lorsque des utilisateurs adossés à 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 backend avec des UPN tels que frontenduser@yourforest.com.

Cause : Votre déploiement SAML B2B souffre du « problème d’ambiguïté UPN ». Citrix Cloud ne peut pas déterminer quels connecteurs utiliser pour rechercher l’identité backend de l’utilisateur. N’envoyez pas cip_sid dans l’assertion SAML. L’UPN de votre utilisateur existe dans plus d’une forêt AD connectée à 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 Workspace ou d’une URL GO Citrix Cloud.

Obtenez les points de terminaison SAML de l’application SAML Entra ID depuis votre portail Entra ID pour les saisir dans Citrix Cloud.

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

Utilisez les valeurs par défaut recommandées pour la connexion SAML dans Gestion des identités et des accès > Authentification > Ajouter un fournisseur d’identité > SAML.

Important :

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