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 de Store impliquant plusieurs forêts et domaines Active Directory connectés. Cet article est destiné aux grandes entreprises avec des 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 à partir de nombreuses organisations plus petites 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 backend AD lors de l’authentification SAML. Citrix Cloud avec SAML prend en charge de nombreux cas d’utilisation avancés de mappage de comptes, ce qui n’est pas possible avec d’autres méthodes d’authentification OIDC fédérées de Citrix Cloud telles qu’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 votre infrastructure de forêt ou de domaine AD et de l’emplacement des identités de vos utilisateurs finaux de magasin.
- Connecteurs Citrix Cloud joints à la forêt et au domaine AD corrects et joints au niveau de domaine AD correct.
- 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 correct. 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 dans quelle forêt et quel domaine 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é au sein des 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 automatiquement créé 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 dans la forêt AD, car les Citrix Cloud Connectors 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 le bon utilisateur backend AD lorsque deux versions de duplicateuser@domain.com existent. Cela peut entraîner l’échec de l’énumération des ressources DaaS, ou des ressources DaaS incorrectes publiées à l’aide de VDA joints au domaine AD peuvent apparaître dans le magasin.
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 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 le magasin.
Il est recommandé de lire cet article 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’affichage des ressources publiées à l’aide de VDA joints au domaine AD dans le magasin 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 du magasin 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 la valeur d’un suffixe UPN ALT 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 ALT peut avoir été ajouté à plus d’une forêt AD connectée à 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 de la 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 seulement 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 ait 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 des revendications. Si vous avez différentes populations d’utilisateurs front-end avec différents suffixes UPN, il est possible de spécifier les valeurs de cip_forest et cip_domain dynamiquement en utilisant des conditions de basculement comme l’appartenance à un groupe. Cela est possible au sein des applications SAML Entra ID et pourrait également l’être dans d’autres IdP SAML qui prennent en charge les règles de transformation des revendications.
Où dois-je placer mes serveurs FAS pour que le lancement du 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 au niveau du 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 Citrix Cloud Connectors, qui sont joints au domaine AD forestrootdomain1.com au niveau de la forêt racine.
- ResourceLocation2 contient des Citrix Cloud Connectors qui sont joints au domaine AD forestrootdomain2.com au niveau de la forêt racine.
- forestrootdomain1.com et forestrootdomain2.com ont tous deux le même suffixe UPN @domain.com.
- Des utilisateurs en double peuvent également exister au sein de 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 bon compte AD backend à 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 Citrix Cloud Connectors utiliser, de sorte que les mauvaises ressources DaaS pourraient être affichées dans le magasin ou qu’aucune ressource DaaS ne soit renvoyée du tout.
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 en utilisant les groupes de backend AD appropriés.
Scénario 2 : Connecteurs cloud joints au niveau du domaine enfant et utilisateurs stockés 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 du magasin 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 en utilisant « forestrootdomain.com », ce 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 domaine enfant AD et du contexte de forêt corrects.
cip_forest = forestrootdomain.com
cip_domain = childdomain.forestrootdomain.com
