Erweiterte SAML-Szenarien und die korrekte Verwendung von cip_forest und cip_domain innerhalb der SAML-Assertion
Dieser Artikel beschreibt erweiterte SAML-Konfigurationen für Citrix Cloud oder Workspace, die mehrere verbundene Active Directory-Gesamtstrukturen und -Domänen umfassen. Dieser Artikel richtet sich an große Unternehmen mit komplexen AD-Bereitstellungen und sollte von Citrix Cloud-, IdP- und AD-Administratoren auf Architektenebene implementiert werden. Die häufigste Anwendung dieser erweiterten SAML-Konfiguration findet sich in Fusions- und Übernahmeszenarien, bei denen ein großes Unternehmen aus vielen kleineren Organisationen mit unterschiedlicher AD-Infrastruktur, mehreren Gesamtstrukturen und unterschiedlichen Populationen von AD-Backend-Benutzern mit verschiedenen UPNs gebildet wird. Auch die bedingte Authentifizierung ist in Fusions- und Übernahmeszenarien häufig erforderlich.
-
Die optionalen Claims
cip_forestundcip_domaingeben dem Citrix Cloud-Administrator eine größere Kontrolle darüber, welche Citrix Cloud Connectors verwendet werden, um AD-Backend-Benutzerkonten während der SAML-Authentifizierung nachzuschlagen. Citrix Cloud mit SAML unterstützt viele erweiterte Anwendungsfälle für die Kontenzuordnung, die mit anderen föderierten OIDC-Authentifizierungsmethoden von Citrix Cloud, wie Okta IdP oder Entra ID IdP, nicht möglich sind. -
Voraussetzungen
- Verwenden Sie den standardmäßigen Citrix Cloud SAML-Flow, der AD-Identitäten zur Authentifizierung des Endbenutzers verwendet.
- Ein umfassendes Verständnis Ihrer AD-Gesamtstruktur- oder Domäneninfrastruktur und des Speicherorts der Identitäten Ihrer Workspace-Endbenutzer.
- Citrix Cloud Connectors, die der korrekten AD-Gesamtstruktur und -Domäne beigetreten sind und auf der korrekten AD-Domänenebene beigetreten sind.
- Kenntnisse der vorhandenen Ressourcenstandorte und Citrix Cloud Connectors, die bereits in Ihrem Citrix Cloud-Mandanten konfiguriert sind.
- Mehrere mit Citrix Cloud verbundene AD-Gesamtstrukturen sollten keine Active Directory-Vertrauensstellungen untereinander haben.
- Ein Verständnis davon, was eine Frontend- (Entra ID, Okta, Duo) und Backend-Benutzeridentität (AD) bedeutet.
- Frontend- und Backend-Benutzeridentitäten müssen über übereinstimmende UPNs verknüpft sein. Das Verknüpfen eines Paares von Frontend- und Backend-Benutzeridentitäten, die KEINE übereinstimmenden UPNs haben, wird NICHT unterstützt.
- Ein Verständnis davon, wo sich jedes UPN-Suffix innerhalb von Active Directory befindet und ob ein bestimmtes UPN-Suffix mehrdeutig ist und in mehreren verbundenen AD-Gesamtstrukturen existiert.
- DaaS-VDAs sollten einer AD-Domäne beigetreten sein.
- DaaS-Anwendungen und -Desktops sollten für AD-Identitäten veröffentlicht werden.
- Universelle AD-Gruppen sind obligatorisch, wenn Liefergruppenressourcen AD-Gruppen in DaaS zugeordnet werden.
-
DaaS-Liefergruppen müssen auf “Nutzung von Ressourcen einschränken” eingestellt sein und den korrekten universellen AD-Gruppen zugewiesen werden. Die Verwendung von “Allen authentifizierten Benutzern die Nutzung von Ressourcen erlauben” innerhalb von DaaS-Liefergruppen wird NICHT unterstützt.
-
FAS-Server, die der korrekten AD-Gesamtstruktur und -Domäne beigetreten sind und auf der korrekten AD-Ebene beigetreten sind. FAS-Server werden für SSON zu AD-domänenverbundenen VDAs während DaaS-Starts benötigt.
- Möglicherweise müssen Sie auch eine bedingte Authentifizierung implementieren, wenn Sie mehrere SAML-Apps haben und eine SAML-App pro verbundener AD-Gesamtstruktur benötigen. Jede SAML-App erfordert möglicherweise einen anderen Satz von Werten für
cip_forestundcip_domainin Fusions- und Übernahmeszenarien.
Häufig gestellte Fragen (FAQ)
Wenn ich cip_sid in der SAML-Assertion sende, muss ich dann auch die optionalen Claims cip_forest und cip_domain senden?
Nein. Wenn Ihre SAML-Anwendung so konfiguriert ist, dass sie den cip_sid-Claim sendet und dieser in der SAML-Assertion enthalten ist, kann Citrix Cloud immer korrekt identifizieren, in welcher Gesamtstruktur und Domäne sich der AD-Backend-Benutzer befindet. cip_forest und cip_domain sind nicht erforderlich.
Wichtig:
- SAML-Szenarien, in denen das Senden von
cip_sidin der SAML-Assertion nicht möglich ist und stattdessen die Verwendung voncip_forestundcip_domainerforderlich sein könnte.- Frontend-Benutzer, die eine falsche SID enthalten, die nicht mit der SID des Backend-AD-Benutzers übereinstimmt, der in DaaS-Liefergruppen zugeordnet ist.
- Frontend-Benutzer, die überhaupt keine eingebettete SID haben, wie z. B. native Okta-, Entra ID- oder Duo-Benutzer, die nicht über AD-Importtools im IdP erstellt wurden.
Was ist ein implizites AD-UPN-Suffix?
Das implizite UPN wird automatisch von Active Directory erstellt und basiert auf dem sAMAccountName des Benutzers und dem DNS-Namen der Gesamtstruktur. Implizite UPNs sind innerhalb einer AD-Gesamtstruktur immer eindeutig, da sie vom sAMAccountName und dem DNS-Namen der Domäne abgeleitet werden, die innerhalb der AD-Gesamtstruktur eindeutig sind. Zum Beispiel @rootforestdomain.local
Was ist ein explizites (ALT) AD-UPN-Suffix?
Ein explizites UPN-Suffix ist ein benutzerdefinierter Domänenname, der von AD-Administratoren in Active Directory-Domänen und -Vertrauensstellungen hinzugefügt wird. Zum Beispiel @rootforestdomain.local
Wichtig:
Windows AD PowerShell ermöglicht es Ihnen, AD-Benutzer mit jedem von Ihnen angegebenen UPN-Suffix zu erstellen, auch wenn dieses UPN-Suffix nicht in Ihrer AD-Gesamtstruktur existiert. Das alternative UPN-Suffix, das Sie verwenden möchten, MUSS innerhalb der AD-Gesamtstruktur existieren, da die Citrix Cloud Connectors von dieser Liste abhängen, um die Backend-Kontobenutzer nachzuschlagen. Wenn das alternative UPN-Suffix nicht in der AD-Gesamtstruktur konfiguriert ist, wie im obigen Screenshot gezeigt, kann Citrix Cloud Ihre Frontend-Identität keinem geeigneten Backend-AD-Konto zuordnen.
Was ist UPN-Mehrdeutigkeit und warum ist sie ein Problem für Citrix Cloud und DaaS?
UPN-Mehrdeutigkeit ist eine Situation, die auftreten kann, wenn duplicateuser@domain.com in 2 oder mehr mit Citrix Cloud verbundenen AD-Gesamtstrukturen existiert. Das UPN-Suffix @domain.com allein kann nicht verwendet werden, um den korrekten AD-Backend-Benutzer zu bestimmen, wenn zwei Versionen von duplicateuser@domain.com existieren. Dies kann dazu führen, dass DaaS-Ressourcen überhaupt nicht aufgelistet werden, oder dass falsche DaaS-Ressourcen, die mit AD-domänenverbundenen VDAs veröffentlicht wurden, im Workspace angezeigt werden.
Warum sind universelle AD-Gruppen eine Anforderung?
Universelle AD-Gruppen werden im Globalen Katalog (GC) gespeichert, wodurch sie für alle Domänencontroller in der gesamten Gesamtstruktur sichtbar sind. Dies ermöglicht ihre Verwendung zur Zuweisung von Berechtigungen für Ressourcen, die sich in jeder Domäne innerhalb derselben Gesamtstruktur befinden.
Wichtig:
Die Verwendung von universellen AD-Gruppen ist eine Anforderung für alle SAML-Konfigurationen, nicht nur für erweiterte Konfigurationen, die
cip_forestundcip_domainbetreffen. Die Verwendung anderer AD-Gruppentypen wie global kann zu fehlgeschlagenen Ressourcenauflistungen im Workspace führen.
-
Es wird empfohlen, diesen Microsoft-Artikel zum Thema AD-Gruppenbereich zu lesen.
-
Warum wird die Verwendung von “Allen authentifizierten Benutzern die Nutzung von Ressourcen erlauben” innerhalb von DaaS-Liefergruppen nicht empfohlen?
Die Konfiguration von Allen authentifizierten Benutzern die Nutzung von Ressourcen erlauben führt dazu, dass Ressourcen, die mit AD-domänenverbundenen VDAs veröffentlicht wurden, im Workspace für AD-Benutzeridentitäten angezeigt werden, die sich nicht in derselben Domäne und Gesamtstruktur befinden. Das Starten von Ressourcen von VDAs, die in Gesamtstruktur 2 einer Domäne beigetreten sind, unter Verwendung einer Workspace AD-Endbenutzeridentität in Gesamtstruktur 1 wird nicht erfolgreich sein.
Kann ich cip_forest allein oder cip_domain allein in der SAML-Assertion senden?
Nein. Wenn Sie einen bestimmten AD-Gesamtstruktur- und Domänenkontext für die Backend-Benutzersuche angeben möchten, müssen Sie beide optionalen Claims in der SAML-Assertion bereitstellen.
Welches UPN-Suffix sollte ich verwenden, wenn ich einen Wert für cip_forest angebe?
Der implizite UPN-Suffix für die AD-Gesamtstruktur sollte verwendet werden. Geben Sie keinen Wert eines alternativen UPN-Suffix an, der der AD-Gesamtstruktur innerhalb des cip_forest-Claims hinzugefügt wurde. Dies liegt daran, dass es AD-Topologien gibt, in denen derselbe alternative UPN-Suffix möglicherweise mehreren mit Citrix Cloud verbundenen AD-Gesamtstrukturen hinzugefügt wurde. Der implizite UPN-Suffix und DN ist für Citrix Cloud niemals mehrdeutig, es sei denn, zwei verschiedene AD-Gesamtstrukturen mit demselben DN, wie z. B. DC=duplicate,DC=com, sind mit Citrix Cloud verbunden (ein unwahrscheinliches Szenario).
Wann sollten die Werte für cip_forest und cip_domain gleich oder unterschiedlich sein?
Szenario 1: Ihre Citrix Cloud Connectors sind auf der Gesamtstruktur-Stammdomänenebene in die Domäne eingebunden, und die Benutzerkonten des Backend-AD befinden sich innerhalb der Stammdomäne in der verbundenen AD-Gesamtstruktur.
cip_domain und cip_forest sollten denselben Wert haben.
cip_forest = “forestrootdomain.com”
cip_domain = “forestrootdomain.com”
Szenario 2: Ihre Citrix Cloud Connectors sind in eine untergeordnete Domäne in der AD-Gesamtstrukturhierarchie eingebunden. Die Backend-AD-Benutzer existieren innerhalb von “childdomain.forestrootdomain.com” in Ihrer AD-Gesamtstruktur.
cip_domain und cip_forest sollten unterschiedliche Werte haben.
cip_forest = “forestrootdomain.com”
cip_domain = “childdomain.forestrootdomain.com”
Kann ich die Werte von cip_forest und cip_domain innerhalb der SAML-Assertion fest codieren?
Ja, aber nur, wenn die gesamte Population der Backend-AD-Benutzer, die DaaS-Ressourcen zugeordnet sind, in derselben AD-Gesamtstruktur residiert. Das Festcodieren der Werte von cip_forest und cip_domain erfordert, dass jeder Frontend-Benutzer über seine entsprechenden Backend-AD-Konten in derselben AD-Gesamtstruktur und Domäne verfügt.
Kann ich unterschiedliche Werte für cip_forest und cip_domain innerhalb der SAML-Assertion dynamisch angeben?
Ja, wenn Ihr SAML-Anbieter dies über Anspruchstransformationsregeln zulässt. Wenn Sie unterschiedliche Populationen von Frontend-Benutzern mit unterschiedlichen UPN-Suffixen haben, ist es möglich, die Werte von cip_forest und cip_domain dynamisch mithilfe von Umschaltbedingungen wie der Gruppenmitgliedschaft anzugeben. Dies ist innerhalb von Entra ID SAML-Anwendungen möglich und könnte auch in anderen SAML-IdPs möglich sein, die Anspruchstransformationsregeln unterstützen.
Wo sollte ich meine FAS-Server platzieren, damit der Start von SSON zu in die AD-Domäne eingebundenen VDAs erfolgreich ist?
FAS-Server sollten in die Domäne eingebunden und in jeder der Backend-AD-Gesamtstrukturen konfiguriert werden, in denen sich die Backend-AD-Konten befinden. Es wird empfohlen, Ihre FAS-Server auf der Ebene der AD-Gesamtstruktur-Stammdomäne in die Domäne einzubinden.
AD-Topologien, bei denen cip_forest und cip_domain in der SAML-Assertion erforderlich sind
Szenario 1: Der UPN des SAML-Endbenutzers ist mehrdeutig und existiert in mehreren mit Citrix Cloud verbundenen AD-Gesamtstrukturen
-
Der Citrix Cloud-Mandant verfügt über zwei oder mehr Ressourcenstandorte und mehrere AD-Gesamtstrukturen oder Domänen, die mit Citrix Cloud verbunden sind.
- ResourceLocation1 enthält Citrix Cloud Connectors, die auf der Stamm-Gesamtstrukturebene von AD forestrootdomain1.com in die Domäne eingebunden sind.
- ResourceLocation2 enthält Citrix Cloud Connectors, die auf der Stamm-Gesamtstrukturebene von AD forestrootdomain2.com in die Domäne eingebunden sind.
- forestrootdomain1.com und forestrootdomain2.com haben beide dasselbe UPN-Suffix @domain.com.
- Duplizierte Benutzer können auch innerhalb von forestrootdomain1.com und forestrootdomain2.com mit demselben UPN
duplicateuser@domain.com, aber unterschiedlichen SID- und OID-Werten existieren.
Problem: Der Versuch, das korrekte Backend-AD-Konto mithilfe von username@duplicatesuffix.com nachzuschlagen, liefert aufgrund der UPN-Mehrdeutigkeit nicht immer den korrekten AD-Backend-Benutzer. Citrix Cloud kann nicht bestimmen, welche AD-Gesamtstruktur und welche Citrix Cloud Connectors verwendet werden sollen, sodass möglicherweise die falschen DaaS-Ressourcen in Workspace angezeigt werden oder überhaupt keine DaaS-Ressourcen zurückgegeben werden.
Lösung: Konfigurieren Sie zwei verschiedene SAML-Anwendungen, eine für jede verbundene AD-Gesamtstruktur, und fügen Sie die entsprechenden cip_domain- und cip_forest-Werte für die korrekte AD-Gesamtstruktur in die SAML-Assertion ein. Dies liefert Citrix Cloud den zusätzlichen Gesamtstruktur- und Domänenkontext, um sicherzustellen, dass der korrekte Backend-AD-Benutzer “nachgeschlagen” wird, wenn username@duplicatesuffix.com in mehreren verbundenen Gesamtstrukturen existiert.
SAML-App 1 forestrootdomain1.com:
SAML-App 2 forestrootdomain2.com:
Ordnen Sie die beiden DaaS-Bereitstellungsgruppen korrekt mithilfe der richtigen AD-Backend-Gruppen zu.
Szenario 2: Cloud Connectors auf untergeordneter Domänenebene eingebunden und Workspace-Benutzer auf untergeordneter Domänenebene
Der Citrix Cloud-Mandant verfügt über einen Ressourcenstandort, der zwei Citrix Cloud Connectors enthält, die auf der Ebene “childdomain.forestrootdomain.com” in die Domäne eingebunden sind, anstatt auf der empfohlenen Ebene “forestrootdomain.com”. Workspace-Benutzer existieren innerhalb der untergeordneten Domäne childdomain.forestrootdomain.com. Benutzer sind so konfiguriert, dass sie das UPN-Suffix der Stammdomäne verwenden, z. B. username@forestrootdomain.com.
Problem: Citrix Cloud führt die AD-Kontosuche mithilfe von “forestrootdomain.com” durch, was keiner verbundenen AD-Domäne entspricht.
Lösung: Geben Sie den Kontext der untergeordneten Domäne in der SAML-Assertion an, damit der AD-Kontobenutzer aus dem korrekten AD-Unterdomänen- und Gesamtstrukturkontext “nachgeschlagen” wird.
cip_forest = forestrootdomain.com
cip_domain = childdomain.forestrootdomain.com
