Scénarios SAML avancés et utilisation correcte de cip_forest et cip_domain dans l’assertion SAML
Cet article décrit les configurations SAML avancées de Citrix Cloud ou Workspace impliquant plusieurs forêts et domaines Active Directory connectés. Cet article est destiné aux grandes entreprises dotées de déploiements AD complexes et doit être mis en œuvre par des administrateurs Citrix Cloud, IdP et AD de niveau architecte. L’utilisation la plus courante de cette configuration SAML avancée se trouve dans les scénarios de fusions et acquisitions, où une grande entreprise est formée de nombreuses petites organisations avec des infrastructures AD différentes, plusieurs forêts et différentes populations d’utilisateurs AD BackEnd avec des UPN différents. L’authentification conditionnelle est également souvent requise dans les scénarios de fusions et acquisitions.
-
Les revendications facultatives cip_forest et cip_domain donnent à l’administrateur Citrix Cloud un contrôle accru sur les connecteurs Citrix Cloud utilisés pour rechercher les comptes d’utilisateurs AD backend lors de l’authentification SAML. Citrix Cloud avec SAML prend en charge de nombreux cas d’utilisation avancés de mappage de comptes, qui ne sont pas possibles avec d’autres méthodes d’authentification OIDC fédérées de Citrix Cloud, telles que Okta IdP ou Entra ID IdP.
-
Prérequis
- Utilisez le flux SAML par défaut de Citrix Cloud, qui utilise les identités AD pour authentifier l’utilisateur final.
- Une compréhension approfondie de l’infrastructure de votre forêt ou domaine AD et de l’emplacement des identités de vos utilisateurs finaux Workspace.
- Des connecteurs Citrix Cloud joints à la forêt et au domaine AD corrects, et joints au niveau de domaine AD approprié.
- La connaissance des emplacements de ressources existants et des connecteurs Citrix Cloud déjà configurés au sein de votre locataire Citrix Cloud.
- Plusieurs forêts AD connectées à Citrix Cloud ne doivent pas avoir de relations d’approbation Active Directory entre elles.
- Une compréhension de ce que signifie une identité d’utilisateur front-end (Entra ID, Okta, Duo) et backend (AD).
- Les identités d’utilisateur front-end et backend doivent être liées par des UPN correspondants. La liaison d’une paire d’identités d’utilisateur front-end et backend qui n’ont PAS d’UPN correspondants n’est PAS prise en charge.
- Une compréhension de l’emplacement de chaque suffixe UPN dans Active Directory et de la question de savoir si un suffixe UPN particulier est ambigu et existe dans plusieurs forêts AD connectées.
- Les VDA DaaS doivent être joints au domaine AD.
- Les applications et bureaux DaaS doivent être publiés pour les identités AD.
- Les groupes AD universels sont obligatoires lors du mappage des ressources de groupe de mise à disposition aux groupes AD dans DaaS.
-
Les groupes de mise à disposition DaaS doivent être configurés sur « Restreindre l’utilisation des ressources » et doivent être attribués aux groupes AD universels corrects. L’utilisation de « Autoriser tout utilisateur authentifié à utiliser les ressources » au sein des groupes de mise à disposition DaaS n’est PAS prise en charge.
-
Serveurs FAS joints à la forêt AD correcte et joints au domaine au niveau AD approprié. Les serveurs FAS sont nécessaires pour le SSON vers les VDA joints au domaine AD lors des lancements DaaS.
- Vous pourriez également être amené à implémenter l’authentification conditionnelle si vous avez plusieurs applications SAML et que vous avez besoin d’une application SAML par forêt AD connectée. Chaque application SAML pourrait nécessiter un ensemble de valeurs différent pour cip_forest et cip_domain dans les scénarios de fusions et acquisitions.
FAQ
Si j’envoie cip_sid dans l’assertion SAML, dois-je également envoyer les revendications facultatives cip_forest et cip_domain ?
Non. Si votre application SAML est configurée pour envoyer la revendication cip_sid et qu’elle est incluse dans l’assertion SAML, alors Citrix Cloud sera toujours en mesure d’identifier correctement la forêt et le domaine dans lesquels se trouve l’utilisateur backend AD. cip_forest et cip_domain ne sont pas requis.
Important :
- Scénarios SAML où l’envoi de cip_sid dans l’assertion SAML n’est pas possible et pourrait nécessiter l’utilisation de cip_forest et cip_domain à la place.
- Utilisateurs front-end qui contiennent un SID incorrect, qui ne correspond pas au SID de l’utilisateur AD Backend mappé dans les groupes de mise à disposition DaaS.
- Utilisateurs front-end qui n’ont aucun SID intégré, tels que les utilisateurs natifs Okta, Entra ID ou Duo qui n’ont pas été créés dans l’IdP via des outils d’importation AD.
Qu’est-ce qu’un suffixe UPN implicite AD ?
L’UPN implicite est créé automatiquement par Active Directory et est basé sur le sAMAccountName de l’utilisateur et le nom DNS de la forêt. Les UPN implicites sont toujours uniques au sein d’une forêt AD car ils sont dérivés du sAMAccountName et du nom DNS du domaine, qui sont uniques au sein de la forêt AD. Par exemple, @rootforestdomain.local
Qu’est-ce qu’un suffixe UPN explicite (ALT) AD ?
Un suffixe UPN explicite est un nom de domaine personnalisé ajouté par les administrateurs AD dans Domaines et approbations Active Directory. Par exemple, @rootforestdomain.local
Important :
Windows AD PowerShell vous permet de créer des utilisateurs AD 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 comptes backend. Si le suffixe UPN alternatif n’est pas configuré dans la forêt AD comme indiqué dans la capture d’écran ci-dessus, Citrix Cloud ne pourra pas faire correspondre votre identité front-end à un compte AD BackEnd approprié.
Qu’est-ce que l’ambiguïté UPN et pourquoi est-ce un problème pour Citrix Cloud et DaaS ?
L’ambiguïté UPN est une situation qui peut survenir si duplicateuser@domain.com existe dans 2 forêts AD ou plus connectées à Citrix Cloud. Le suffixe UPN @domain.com seul ne peut pas être utilisé pour déterminer l’utilisateur backend AD correct lorsque deux versions de duplicateuser@domain.com existent. Cela peut entraîner l’échec total de l’énumération des ressources DaaS, ou des ressources DaaS incorrectes publiées à l’aide de VDA joints au domaine AD pourraient apparaître dans l’espace de travail.
Pourquoi les groupes AD universels sont-ils une exigence ?
Les groupes AD universels sont stockés dans le catalogue global (GC), ce qui les rend visibles pour tous les contrôleurs de domaine de la forêt. Cela leur permet d’être utilisés pour attribuer des autorisations aux ressources situées dans n’importe quel domaine au sein de la même forêt.
Important :
L’utilisation des groupes universels AD est une exigence pour toutes les configurations SAML, pas seulement les configurations avancées impliquant cip_forest et cip_domain. L’utilisation d’autres types de groupes AD, tels que les groupes globaux, peut entraîner des échecs d’énumération des ressources dans Workspace.
-
Il est recommandé de lire cet article de Microsoft concernant l’étendue des groupes AD.
-
Pourquoi l’utilisation de « Autoriser tout utilisateur authentifié à utiliser les ressources » n’est-elle pas recommandée dans les groupes de mise à disposition DaaS ?
La configuration de Autoriser tout utilisateur authentifié à utiliser les ressources entraînera l’apparition de ressources publiées à l’aide de VDA joints au domaine AD dans Workspace pour les identités d’utilisateur AD qui ne se trouvent pas dans le même domaine et la même forêt. Le lancement de ressources à partir de VDA joints au domaine dans la Forêt 2 à l’aide d’une identité d’utilisateur final AD Workspace dans la Forêt 1 échouera.
Puis-je envoyer uniquement cip_forest ou uniquement cip_domain dans l’assertion SAML ?
Non. Si vous souhaitez spécifier un contexte de forêt et de domaine AD particulier pour la recherche d’utilisateur backend, vous devez fournir les deux revendications facultatives dans l’assertion SAML.
Lors de la spécification d’une valeur pour cip_forest, quel suffixe UPN dois-je utiliser ?
Le suffixe UPN implicite de la forêt AD doit être utilisé. Ne spécifiez pas de valeur de suffixe UPN alternatif qui a été ajouté à la forêt AD dans la revendication cip_forest. En effet, il existe des topologies AD où le même suffixe UPN alternatif peut avoir été ajouté à plusieurs forêts AD connectées à Citrix Cloud. Le suffixe UPN implicite et le DN ne sont jamais ambigus pour Citrix Cloud, à moins que deux forêts AD différentes avec le même DN, tel que DC=duplicate,DC=com, ne soient connectées à Citrix Cloud (un scénario peu probable).
Quand les valeurs de cip_forest et cip_domain doivent-elles être identiques ou différentes ?
Scénario 1 : Vos connecteurs Citrix Cloud sont joints au domaine au niveau racine de la forêt et les utilisateurs du compte AD backend résident dans le domaine racine au sein de la forêt AD connectée.
cip_domain et cip_forest doivent avoir la même valeur.
cip_forest = "forestrootdomain.com"
cip_domain = "forestrootdomain.com"
Scénario 2 : Vos connecteurs Citrix Cloud sont joints à un domaine enfant dans la hiérarchie de la forêt AD. Les utilisateurs AD backend existent dans « childdomain.forestrootdomain.com » au sein de votre forêt AD.
cip_domain et cip_forest doivent avoir des valeurs différentes.
cip_forest = "forestrootdomain.com"
cip_domain = "childdomain.forestrootdomain.com"
Puis-je coder en dur les valeurs de cip_forest et cip_domain dans l’assertion SAML ?
Oui, mais uniquement si l’ensemble de la population d’utilisateurs AD backend, qui sont mappés aux ressources DaaS, réside dans la même forêt AD. Le codage en dur des valeurs de cip_forest et cip_domain exige que chaque utilisateur frontal dispose de ses comptes AD backend correspondants dans la même forêt et le même domaine AD.
Puis-je spécifier dynamiquement des valeurs différentes pour cip_forest et cip_domain dans l’assertion SAML ?
Oui, si votre fournisseur SAML le permet via des règles de transformation de revendications. Si vous avez différentes populations d’utilisateurs frontaux avec différents suffixes UPN, il est possible de spécifier dynamiquement les valeurs de cip_forest et cip_domain en utilisant des conditions de commutation comme l’appartenance à un groupe. Cela est possible dans les applications SAML Entra ID et pourrait également être possible dans d’autres IdP SAML qui prennent en charge les règles de transformation de revendications.
Où dois-je placer mes serveurs FAS pour que le lancement SSON vers les VDA joints au domaine AD réussisse ?
Les serveurs FAS doivent être joints au domaine et configurés au sein de chacune des forêts AD backend où résident les comptes AD backend. Il est recommandé de joindre vos serveurs FAS au domaine racine de la forêt AD.
Topologies AD où cip_forest et cip_domain sont requis dans l’assertion SAML
Scénario 1 : L’UPN de l’utilisateur final SAML est ambigu et existe dans plusieurs forêts AD connectées à Citrix Cloud
-
Le locataire Citrix Cloud dispose de deux ou plusieurs emplacements de ressources et de plusieurs forêts ou domaines AD connectés à Citrix Cloud.
- ResourceLocation1 contient des connecteurs Citrix Cloud, qui sont joints au domaine AD forestrootdomain1.com au niveau racine de la forêt.
- ResourceLocation2 contient des connecteurs Citrix Cloud qui sont joints au domaine AD forestrootdomain2.com au niveau racine de la forêt.
- forestrootdomain1.com et forestrootdomain2.com ont tous deux le même suffixe UPN @domain.com.
- Des utilisateurs en double peuvent également exister dans forestrootdomain1.com et forestrootdomain2.com avec le même UPN
duplicateuser@domain.commais des valeurs SID et OID différentes.
Problème : la tentative de recherche du compte AD backend correct à l’aide de username@duplicatesuffix.com ne renvoie pas toujours le bon utilisateur AD backend en raison de l’ambiguïté de l’UPN. Citrix Cloud ne peut pas déterminer quelle forêt AD et quels connecteurs Citrix Cloud utiliser, de sorte que les ressources DaaS incorrectes peuvent être affichées dans Workspace ou qu’aucune ressource DaaS n’est renvoyée.
Solution : configurez deux applications SAML différentes, une pour chaque forêt AD connectée, et incluez les valeurs cip_domain et cip_forest correspondantes pour la forêt AD correcte dans l’assertion SAML. Cela fournit à Citrix Cloud le contexte de forêt et de domaine supplémentaire pour garantir que le bon utilisateur AD backend est « recherché » lorsque username@duplicatesuffix.com existe dans plusieurs forêts connectées.
Application SAML 1 forestrootdomain1.com :
Application SAML 2 forestrootdomain2.com :
Mappez correctement les deux groupes de mise à disposition DaaS à l’aide des groupes AD backend corrects.
Scénario 2 : Connecteurs Cloud joints au niveau du domaine enfant et utilisateurs Workspace au niveau du domaine enfant
Le locataire Citrix Cloud dispose d’un emplacement de ressources, qui contient deux connecteurs Citrix Cloud, joints au domaine au niveau « childdomain.forestrootdomain.com » au lieu du niveau recommandé « forestrootdomain.com ». Les utilisateurs Workspace existent dans le domaine enfant childdomain.forestrootdomain.com. Les utilisateurs sont configurés pour utiliser le suffixe UPN du domaine racine tel que username@forestrootdomain.com.
Problème : Citrix Cloud effectue la recherche de compte AD à l’aide de « forestrootdomain.com », qui ne correspond pas à un domaine AD connecté.
Solution : Spécifiez le contexte du domaine enfant dans l’assertion SAML afin que l’utilisateur du compte AD soit « recherché » à partir du contexte correct du domaine enfant et de la forêt AD.
cip_forest = "forestrootdomain.com"
cip_domain = "childdomain.forestrootdomain.com"
