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 Stores, 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 ist in Fusions- und Übernahmeszenarien, in denen ein großes Unternehmen aus vielen kleineren Organisationen mit unterschiedlicher AD-Infrastruktur, mehreren Gesamtstrukturen und unterschiedlichen Populationen von AD-Backend-Benutzern mit unterschiedlichen UPNs gebildet wird. Bedingte Authentifizierung ist auch häufig in Fusions- und Übernahmeszenarien erforderlich.
Die optionalen Ansprüche cip_forest und cip_domain geben 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 wo sich die Identitäten Ihrer Store-Endbenutzer befinden.
- Citrix Cloud Connectors, die der richtigen AD-Gesamtstruktur und -Domäne beigetreten sind und auf der richtigen 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 Front-End- (Entra ID, Okta, Duo) und Back-End-Benutzeridentität (AD) bedeutet.
- Front-End- und Back-End-Benutzeridentitäten müssen über übereinstimmende UPNs verknüpft werden. Das Verknüpfen eines Paares von Front-End- und Back-End-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-Bereitstellungsgruppen müssen auf „Nutzung von Ressourcen einschränken“ eingestellt sein und sollten den korrekten universellen AD-Gruppen zugewiesen werden. Die Verwendung von „Allen authentifizierten Benutzern die Nutzung von Ressourcen erlauben“ innerhalb von DaaS-Bereitstellungsgruppen wird NICHT unterstützt.
-
FAS-Server, die dem korrekten AD-Forest beigetreten sind und auf der korrekten AD-Ebene der Domäne 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-Anwendungen haben und eine SAML-Anwendung pro verbundenem AD-Forest benötigen. Jede SAML-Anwendung benötigt möglicherweise einen anderen Satz von Werten für cip_forest und cip_domain in Szenarien von Fusionen und Übernahmen.
Häufig gestellte Fragen
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, dann kann Citrix Cloud immer korrekt identifizieren, in welchem Forest und welcher 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_sid in der SAML-Assertion nicht möglich ist und stattdessen die Verwendung von cip_forest und cip_domain erfordern könnten.
- Front-End-Benutzer, die die falsche SID enthalten, die nicht mit der SID des Backend-AD-Benutzers übereinstimmt, der in DaaS-Bereitstellungsgruppen zugeordnet ist.
- Front-End-Benutzer, die überhaupt keine eingebettete SID haben, wie native Okta-, Entra ID- oder Duo-Benutzer, die nicht innerhalb des IdP über AD-Import-Tools 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 des Forests. Implizite UPNs sind innerhalb eines AD-Forests immer eindeutig, da sie vom sAMAccountName und dem DNS-Namen der Domäne abgeleitet werden, die innerhalb des AD-Forests 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, selbst wenn dieses UPN-Suffix nicht in Ihrer AD-Gesamtstruktur vorhanden ist. 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 nicht mit einem geeigneten Backend-AD-Konto abgleichen.
Was ist UPN-Ambiguität und warum ist sie ein Problem für Citrix Cloud und DaaS?
UPN-Ambiguität ist eine Situation, die entstehen 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 können oder dass falsche DaaS-Ressourcen, die mit AD-domänenverbundenen VDAs veröffentlicht wurden, im Store 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_forest und cip_domain betreffen. Die Verwendung anderer AD-Gruppentypen wie global kann zu fehlgeschlagenen Ressourcenaufzählungen im Store 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“ in DaaS-Bereitstellungsgruppen nicht empfohlen?
Das Konfigurieren von Allen authentifizierten Benutzern die Nutzung von Ressourcen erlauben führt dazu, dass Ressourcen, die mit AD-domänenverbundenen VDAs veröffentlicht wurden, im Store 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 domänenverbunden sind, unter Verwendung einer Store-AD-Endbenutzeridentität in Gesamtstruktur 1 wird nicht erfolgreich sein.
Kann ich nur cip_forest oder nur 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 angeben.
Welches UPN-Suffix sollte ich verwenden, wenn ich einen Wert für cip_forest angebe?
Das implizite UPN-Suffix für die AD-Gesamtstruktur sollte verwendet werden. Geben Sie keinen Wert eines alternativen UPN-Suffixes an, das der AD-Gesamtstruktur innerhalb des cip_forest-Claims hinzugefügt wurde. Dies liegt daran, dass es AD-Topologien gibt, in denen dasselbe alternative UPN-Suffix zu mehr als einer mit Citrix Cloud verbundenen AD-Gesamtstruktur hinzugefügt worden sein könnte. Das implizite UPN-Suffix und der DN sind 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 Backend-AD-Kontobenutzer befinden sich in der Stammdomäne innerhalb 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 einer untergeordneten Domäne in der AD-Gesamtstrukturhierarchie beigetreten. 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 in 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 seine entsprechenden Backend-AD-Konten in derselben AD-Gesamtstruktur und Domäne hat.
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 Gruppen von Front-End-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 in 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: Das 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 mit Citrix Cloud verbundene AD-Gesamtstrukturen oder -Domänen.
- ResourceLocation1 enthält Citrix Cloud Connectors, die auf der Ebene der Stammgesamtstruktur in die AD-Stammgesamtstrukturdomäne1.com eingebunden sind.
- ResourceLocation2 enthält Citrix Cloud Connectors, die auf der Ebene der Stammgesamtstruktur in die AD-Stammgesamtstrukturdomäne2.com eingebunden sind.
- forestrootdomain1.com und forestrootdomain2.com haben beide dasselbe UPN-Suffix @domain.com.
- Doppelte 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 zu suchen, 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 im Store 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 versorgt Citrix Cloud mit dem zusätzlichen Gesamtstruktur- und Domänenkontext, um sicherzustellen, dass der korrekte Backend-AD-Benutzer „gesucht“ 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 unter Verwendung der korrekten AD-Backend-Gruppen zu.
Szenario 2: Cloud Connectors auf Ebene der untergeordneten Domäne beigetreten und speichern Benutzer auf Ebene der untergeordneten Domäne
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”. Store-Benutzer existieren innerhalb der untergeordneten Domäne childdomain.forestrootdomain.com. Benutzer sind so konfiguriert, dass sie das UPN-Suffix der Stammdomäne verwenden, wie z. B. username@forestrootdomain.com.
Problem: Citrix Cloud führt die AD-Kontosuche unter Verwendung von “forestrootdomain.com” durch, was nicht mit einer verbundenen AD-Domäne übereinstimmt.
Lösung: Geben Sie den Kontext der untergeordneten Domäne in der SAML-Assertion an, damit der AD-Kontobenutzer aus der korrekten untergeordneten AD-Domäne und dem Gesamtstrukturkontext “nachgeschlagen” wird.
cip_forest = forestrootdomain.com
cip_domain = childdomain.forestrootdomain.com
