Konfigurieren von vereinfachtem SAML für die Verwendung mit nativen und Gast-SAML-Benutzern

Bevor Sie die Schritte in diesem Artikel befolgen, sollten Sie sich unbedingt vergewissern, ob “vereinfachtes SAML” für Ihren Anwendungsfall bei der Authentifizierung geeignet ist. Lesen Sie die Anwendungsfallbeschreibungen und häufig gestellten Fragen gründlich durch, bevor Sie sich für die Implementierung dieser speziellen SAML-Lösung für Sonderfälle entscheiden. Bevor Sie fortfahren, stellen Sie sicher, dass Sie die Szenarien, in denen vereinfachtes SAML angemessen ist, vollständig verstanden haben und wissen, welche Arten von Identitäten Sie verwenden müssen. Die meisten SAML-Anwendungsfälle können erreicht werden, indem Sie andere SAML-Artikel befolgen und alle vier cip_*-Attribute zur Authentifizierung senden.

Hinweis:

Die Verwendung von “vereinfachtem SAML” erhöht die Belastung der Citrix Cloud Connectors, da sie die Benutzer-E-Mail, SID und OID für jede Workspace-Endbenutzeranmeldung nachschlagen müssen, statt dass diese Werte von der SAML-Assertion bereitgestellt werden. Das Senden aller vier cip_*-Attribute in der SAML-Assertion ist aus Sicht der Citrix Cloud Connector-Leistung vorzuziehen, wenn vereinfachtes SAML nicht tatsächlich erforderlich ist.

Voraussetzungen

• Eine SAML-Anwendung, die speziell für die Verwendung mit vereinfachtem SAML konfiguriert wurde und nur cip_upn zur Authentifizierung innerhalb der SAML-Assertion sendet.
• Frontend-Benutzer innerhalb Ihres SAML-Anbieters.
• Ein Ressourcenstandort, der ein Paar Citrix Cloud Connectors enthält, die mit der AD-Gesamtstruktur und der Domäne verbunden sind, in der die AD-Schattenkonten erstellt werden.
• Alternative UPN-Suffixe wurden der Backend-AD-Gesamtstruktur hinzugefügt, in der die AD-Schattenkonten erstellt werden.
• Backend-AD-Schattenkonten mit passenden UPNs.
• DaaS- oder Citrix Virtual Apps and Desktops-Ressourcen, die den Benutzern des AD-Schattenkontos zugeordnet sind.
• Ein oder mehrere FAS-Server, die mit demselben Ressourcenstandort verknüpft sind.

Häufig gestellte Fragen

Warum sollte ich vereinfachtes SAML verwenden?

Es ist üblich, dass große Unternehmen Auftragnehmer und Zeitarbeitskräfte in ihre Identitätsplattform einladen. Ziel ist es, dem Auftragnehmer temporären Zugriff auf Citrix Workspace unter Verwendung der vorhandenen Benutzeridentität zu gewähren, z. B. einer Auftragnehmer-E-Mail-Adresse oder einer E-Mail-Adresse außerhalb Ihrer Organisation. Vereinfachtes SAML ermöglicht die Verwendung von nativen oder Gast-Frontend-Identitäten, die in der AD-Domäne, in der DaaS-Ressourcen veröffentlicht werden, nicht existieren.

Was ist vereinfachtes SAML?

Normalerweise werden bei der Anmeldung bei Citrix Workspace vier SAML-Attribute cip_* und die entsprechenden AD-Benutzerattribute verwendet, um den Endbenutzer zu authentifizieren. Es wird erwartet, dass diese vier SAML-Attribute in der SAML-Assertion vorhanden sind und mithilfe von AD-Benutzerattributen aufgefüllt werden. Vereinfachtes SAML bezieht sich auf die Tatsache, dass für eine erfolgreiche Authentifizierung nur das SAML-Attribut cip_upn erforderlich ist.

Die anderen drei AD-Benutzerattribute objectSID, objectGUID und mail, die für die Authentifizierung erforderlich sind, werden mithilfe der Citrix Cloud Connectors abgerufen, die mit der AD-Domäne verbunden sind, in der das AD-Schattenkonto vorhanden ist. Sie müssen während eines SAML-Anmeldeflusses für Workspace oder Citrix Cloud nicht mehr in die SAML-Assertion eingeschlossen werden.

Wichtig:

Es ist für alle SAML-Flüsse weiterhin erforderlich, den displayName zu senden. Dies gilt auch für vereinfachtes SAML. Der displayName wird von der Workspace-Benutzeroberfläche benötigt, um den vollständigen Namen des Workspace-Benutzers korrekt anzuzeigen.

Was ist eine native SAML-Benutzeridentität?

Ein nativer SAML-Benutzer ist eine Benutzeridentität, die nur in Ihrem SAML-Anbieterverzeichnis existiert, z. B. Entra ID oder Okta. Diese Identitäten enthalten keine lokalen Benutzerattribute, da sie nicht über AD-Synchronisierungstools wie Entra ID Connect erstellt werden. Sie benötigen passende AD-Backend-Schattenkonten, um DaaS-Ressourcen auflisten und starten zu können. Der native SAML-Benutzer muss einem entsprechenden Konto in Active Directory zugeordnet sein.

Was ist eine AD-gestützte SAML-Benutzeridentität?

Ein AD-gestützter SAML-Benutzer ist eine Benutzeridentität, die in Ihrem SAML-Anbieterverzeichnis wie Entra ID oder Okta und auch in Ihrer lokalen AD-Gesamtstruktur existiert. Diese Identitäten enthalten lokale Benutzerattribute, da sie über AD-Synchronisierungstools wie Entra ID Connect erstellt werden. AD-Backend-Schattenkonten sind für diese Benutzer nicht erforderlich, da sie lokale SIDs und OIDs enthalten und daher DaaS-Ressourcen auflisten und starten können.

Was ist eine Frontend-Identität?

Eine Frontend-Identität ist die Identität, die für die Anmeldung sowohl beim SAML-Anbieter als auch bei Workspace verwendet wird. Frontend-Identitäten haben unterschiedliche Benutzerattribute, je nachdem, wie sie innerhalb des SAML-Anbieters erstellt wurden.

1. Native SAML-Benutzeridentität
2. AD-gestützte SAML-Benutzeridentität

Ihr SAML-Anbieter verfügt möglicherweise über eine Kombination dieser beiden Arten von Identitäten. Wenn Sie beispielsweise sowohl Auftragnehmer als auch festangestellte Mitarbeiter in Ihrer Identitätsplattform haben, funktioniert vereinfachtes SAML für beide Arten von Frontend-Identitäten, ist aber nur erforderlich, wenn Sie einige Konten haben, die vom Typ native SAML-Benutzeridentität sind.

Was ist ein Backend-AD-Schattenkonto?

Ein Backend-AD-Schattenkonto ist ein von DaaS verwendetes AD-Konto, das einer entsprechenden Frontend-Identität innerhalb Ihres SAML-Anbieters zugeordnet ist.

Warum werden Backend-AD-Schattenkonten benötigt?

Um DaaS- oder CVAD-Ressourcen aufzulisten, die mithilfe von der AD-Domäne beigetretenen VDAs veröffentlicht wurden, sind AD-Konten innerhalb der Active Directory-Gesamtstruktur erforderlich, der die VDAs beigetreten sind. Ordnen Sie Ressourcen innerhalb Ihrer DaaS-Bereitstellungsgruppe Schattenkontobenutzern und AD-Gruppen zu, die Schattenkonten innerhalb der AD-Domäne enthalten, der Ihre VDAs beigetreten sind.

Wichtig:

Nur native SAML-Benutzer ohne AD-Domänenattribute benötigen übereinstimmende AD-Schattenkonten. Wenn Ihre Frontend-Identitäten aus Active Directory importiert werden, müssen Sie vereinfachte SAML nicht verwenden und auch keine Backend-AD-Schattenkonten erstellen.

Wie verknüpfen wir die Frontend-Identität mit dem entsprechenden Backend-AD-Schattenkonto?

Die Methode, die verwendet wird, um die Frontend-Identität und die Backend-Identität zu verknüpfen, besteht darin, passende UPNs zu verwenden. Die beiden verknüpften Identitäten müssen identische UPNs haben, damit Workspace erkennen kann, dass sie denselben Endbenutzer repräsentieren, der sich bei Workspace anmelden muss, und damit DaaS-Ressourcen aufgelistet und gestartet werden können.

Wird Citrix FAS für vereinfachtes SAML benötigt?

Ja. FAS ist für SSON beim VDA während des Starts erforderlich, wenn Sie eine Verbundauthentifizierungsmethode verwenden, um sich bei Workspace anzumelden.

Was ist das “SID-Nichtübereinstimmungsproblem” und wann kann es auftreten?

Das “SID-Nichtübereinstimmungsproblem” wird verursacht, wenn die SAML-Assertion eine SID für einen Frontend-Benutzer enthält, die nicht mit der SID des AD-Schattenkontobenutzers übereinstimmt. Dies kann vorkommen, wenn das Konto, das sich bei Ihrem SAML-Anbieter anmeldet, eine lokale SID hat, die nicht mit der SID des Schattenkontobenutzers identisch ist. Dies kann nur passieren, wenn die Frontend-Identität von AD-Synchronisierungstools wie Entra ID Connect bereitgestellt wird und aus einer anderen AD-Gesamtstruktur als der stammt, in der das Schattenkonto erstellt wurde.

Vereinfachtes SAML verhindert das Auftreten des “SID-Nichtübereinstimmungsproblems”. Die richtige SID wird für den Schattenkontobenutzer immer über die Citrix Cloud Connectors abgerufen, die mit der Backend-AD-Domäne verbunden sind. Die Suche nach dem Schattenkontobenutzer wird anhand des UPN des Frontend-Benutzers durchgeführt, der dann mit dem entsprechenden Backend-Schattenkontobenutzer abgeglichen wird.

Beispiel für das SID-Nichtübereinstimmungsproblem: Der Frontend-Benutzer wurde von Entra ID Connect erstellt und über die AD-Gesamtstruktur 1 synchronisiert. S-1-5-21-000000000-0000000000-0000000001-0001

Der Backend-Schattenkontobenutzer wurde in AD-Gesamtstruktur 2 erstellt und DaaS-Ressourcen zugeordnet S-1-5-21-000000000-0000000000-0000000002-0002.

Die SAML-Assertion enthält alle vier cip_*-Attribute und cip_sid enthält den Wert S-1-5-21-000000000-0000000000-0000000001-0001, der nicht mit der SID des Schattenkontos übereinstimmt und einen Fehler auslöst.

Konfigurieren von vereinfachtem SAML mithilfe der Entra ID für externe Gastkonten

1. Melden Sie sich beim Azure-Portal an.
2. Wählen Sie im Portalmenü die Option Entra ID aus.
3. Wählen Sie im linken Bereich unter Verwalten die Option Unternehmensanwendungen.
4. Wählen Sie Eigene Anwendung erstellen aus.

5. Geben Sie einen geeigneten Namen für die SAML-Anwendung ein, z. B. Citrix Cloud SAML SSO Production Simplified SAML.

   

6. Wählen Sie im linken Navigationsbereich Single Sign-On aus und klicken Sie im Arbeitsbereich auf SAML.
7. Klicken Sie im Abschnitt Grundlegende SAML-Konfiguration auf die Option Bearbeiten und konfigurieren Sie die folgenden Einstellungen:
   1. Wählen Sie im Abschnitt Bezeichner (Entitäts-ID) die Option Bezeichner hinzufügen und geben Sie dann den Wert für die Region ein, in der sich der Citrix Cloud-Mandant befindet:
      • Geben Sie für die Regionen Europäische Union, USA und Asien-Pazifik Süd https://saml.cloud.com ein.
      • Geben Sie für die Region Japan https://saml.citrixcloud.jp ein.
      • Geben Sie für die Region Citrix Cloud Government https://saml.cloud.us ein.
   2. Wählen Sie im Abschnitt Antwort-URL (Assertionsverbraucherdienst-URL) die Option Antwort-URL hinzufügen und geben Sie dann den Wert für die Region ein, in der sich der Citrix Cloud-Mandant befindet:
      • Geben Sie für die Regionen Europäische Union, USA und Asien-Pazifik Süd https://saml.cloud.com/saml/acs ein.
      • Geben Sie für die Region Japan https://saml.citrixcloud.jp/saml/acs ein.
      • Geben Sie für die Region Citrix Cloud Government https://saml.cloud.us/saml/acs ein.
   3. Geben Sie im Abschnitt Anmelde-URL Ihre Workspace-URL ein.
   4. Geben Sie im Abschnitt Abmelde-URL (optional) den Wert für die Region ein, in der sich der Citrix Cloud-Mandant befindet:
      • Geben Sie für die Regionen Europäische Union, USA und Asien-Pazifik Süd https://saml.cloud.com/saml/logout/callback ein.
      • Geben Sie für die Region Japan https://saml.citrixcloud.jp/saml/logout/callback ein.
      • Geben Sie für die Region Citrix Cloud Government https://saml.cloud.us/saml/logout/callback ein.

   5. Klicken Sie in der Befehlsleiste auf Speichern. Der Abschnitt Grundlegende SAML-Konfiguration sieht wie folgt aus:

      

8. Wählen Sie im Abschnitt Attribute und Ansprüche die Option Bearbeiten, um die folgenden Ansprüche zu konfigurieren. Diese Ansprüche erscheinen in der SAML-Assertion der SAML-Antwort. Konfigurieren Sie nach der Erstellung der SAML-App die folgenden Attribute.

   

   1. Übernehmen Sie für den Anspruch Eindeutiger Benutzerbezeichner (Namens-ID) den Standardwert user.userprincipalname.
   2. Lassen Sie für den Anspruch cip_upn den Standardwert user.userprincipalname.
   3. Lassen Sie für displayName den Standardwert user.displayname.

   4. Klicken Sie im Abschnitt Zusätzliche Ansprüche für alle verbleibenden Ansprüche mit dem Namespace http://schemas.xmlsoap.org/ws/2005/05/identity/claims auf das Menü (…) und dann auf Löschen. Diese Ansprüche müssen nicht aufgenommen werden, da es sich um Duplikate der oben genannten Benutzerattribute handelt.

      Wenn Sie fertig sind, wird der Abschnitt Attribute und Ansprüche wie unten dargestellt angezeigt:

      

   5. Besorgen Sie sich mit diesem Online-Tool eines Drittanbieters eine Kopie des Citrix Cloud SAML-Signaturzertifikats.
   6. Geben Sie https://saml.cloud.com/saml/metadata in das URL-Feld ein und klicken Sie auf Laden.

   

9. Scrollen Sie zum Ende der Seite und klicken Sie auf Download.

   

   

10. Konfigurieren Sie die Signatureinstellungen der Azure Active Directory-SAML-Anwendung.
11. Laden Sie das in Schritt 10 erhaltene SAML-Signaturzertifikat für die Produktion in die SAML-Anwendung von Azure Active Directory hoch
    1. Aktivieren Sie die Option Verifizierungszertifikate erforderlich.

    

    

Konfigurieren der vereinfachten SAML-Verbindung für Citrix Cloud

Standardmäßig erwartet Citrix Cloud, dass cip_upn, cip_email, cip_sid und cip_oid in der SAML-Assertion vorhanden sind, und die SAML-Anmeldung schlägt fehl, wenn diese Attribute nicht gesendet werden. Um dies zu verhindern, deaktivieren Sie die Kontrollkästchen für diese Attribute, wenn Sie Ihre neue SAML-Verbindung erstellen.

1. Erstellen Sie eine neue SAML-Verbindung mit den Standardeinstellungen.
2. Navigieren Sie unten zum Abschnitt für die Konfiguration der SAML-Attributzuordnungen und nehmen Sie Änderungen vor, bevor Sie die neue SAML-Konfiguration speichern.
3. Entfernen Sie den SAML-Attributnamen aus jedem der Felder cip_email, cip_sid und cip_oid.
4. Entfernen Sie cip_upn nicht aus seinem Feld.
5. Entfernen Sie keine anderen Attribute aus den jeweiligen Feldern. Der displayName wird weiterhin von der Workspace-Benutzeroberfläche benötigt und darf nicht geändert werden.

Konfigurieren des Ressourcenstandorts und der Connectors Ihres AD-Schattenkontos

Ein Ressourcenstandort und ein Connector-Paar innerhalb der AD-Gesamtstruktur des Backend-Schattenkontos ist erforderlich. Citrix Cloud benötigt Connectors in dieser AD-Gesamtstruktur, um Schattenkonto-Benutzeridentitäten und Attribute wie cip_email, cip_sid und cip_oid nachzuschlagen, wenn nur cip_upn direkt in der SAML-Assertion bereitgestellt wird.

1. Erstellen Sie einen neuen Ressourcenstandort, der Citrix Cloud Connectors enthält, die der AD-Gesamtstruktur des Backend-Schattenkontos beigetreten sind.

   

2. Benennen Sie den Ressourcenstandort so, dass er der AD-Gesamtstruktur mit den Backend-AD-Schattenkonten entspricht, die Sie verwenden möchten.
3. Konfigurieren Sie ein Paar Citrix Cloud Connectors innerhalb des neu erstellten Ressourcenstandorts.

Beispiel: ccconnector1.shadowaccountforest.com ccconnector2.shadowaccountforest.com

Konfigurieren von FAS innerhalb der Backend-AD-Gesamtstruktur

Contractor Frontend-Benutzer benötigen auf jeden Fall FAS. Bei DaaS-Starts können Auftragnehmer-Benutzer Windows-Anmeldeinformationen nicht manuell eingeben, um den Start durchzuführen, da sie das AD-Schattenkonto-Passwort wahrscheinlich nicht kennen.

1. Konfigurieren Sie einen oder mehrere FAS-Server innerhalb der Backend-AD-Gesamtstruktur, in der Ihre Schattenkonten erstellt wurden.
2. Verknüpfen Sie die FAS-Server mit demselben Ressourcenstandort, der ein Paar Citrix Cloud Connectors enthält, die mit der Backend-AD-Gesamtstruktur verbunden sind, in der Ihre Schattenkonten erstellt wurden.

Konfigurieren alternativer UPN-Suffixe in der AD-Domäne

Wichtig:

Ein UPN ist nicht dasselbe wie die E-Mail-Adresse des Benutzers. In vielen Fällen haben sie aus Gründen der Benutzerfreundlichkeit den gleichen Wert, aber UPN und E-Mail werden intern unterschiedlich verwendet und sind in unterschiedlichen Active Directory-Attributen definiert.

Das UPN-Suffix (User Principal Name) ist Teil des Anmeldenamens in AD. Wenn Sie ein neues Konto erstellen, verwendet es standardmäßig das implizite UPN-Suffix Ihrer AD-Gesamtstruktur, z. B. yourforest.com. Sie müssen für jeden externen Frontend-Benutzer, den Sie zu Ihren Okta- oder Azure AD-Mandanten einladen möchten, ein passendes alternatives UPN-Suffix hinzufügen.

Wenn Sie beispielsweise einen externen Benutzer contractoruser@hotmail.co.uk einladen und diesen mit einem Backend-AD-Schattenkonto contractoruser@yourforest.com verknüpfen möchten, fügen Sie yourforest.com als ALT UPN-Suffix in Ihrer AD-Gesamtstruktur hinzu.

Hinzufügen alternativer UPN-Suffixe in Active Directory mithilfe der Benutzeroberfläche von Active Directory-Domänen und -Vertrauensstellungen

1. Melden Sie sich bei einem Domänencontroller in Ihrer Backend-AD-Gesamtstruktur an.
2. Öffnen Sie das Fenster “Ausführen”, geben Sie den Text domain.msc ein und klicken Sie dann auf OK.
3. Klicken Sie im Fenster “Active Directory-Domänen und -Vertrauensstellungen” mit der rechten Maustaste auf Active Directory-Domänen und -Vertrauensstellungen, und wählen Sie dann Eigenschaften aus.

4. Fügen Sie auf der Registerkarte UPN-Suffixe im Feld “Alternative UPN-Suffixe” ein alternatives UPN-Suffix hinzu, und wählen Sie dann Hinzufügen aus.

   

5. Klicken Sie auf OK.

Verwalten der UPN-Suffixe Ihrer Backend-AD-Gesamtstruktur mithilfe von PowerShell

Möglicherweise müssen Sie Ihrer Backend-AD-Gesamtstruktur eine große Anzahl neuer UPN-Suffixe hinzufügen, um die erforderlichen UPNs für Schattenkonten zu erstellen. Die Anzahl der alternativen UPN-Suffixe, die Sie Ihrer Backend-AD-Gesamtstruktur hinzufügen müssen, hängt davon ab, wie viele verschiedene externe Benutzer Sie in Ihren SAML-Anbieter-Mandanten einladen möchten.

Hier finden Sie einige PowerShell-Suffixe, um dies zu erreichen, wenn eine große Anzahl neuer alternativer UPN-Suffixe erstellt werden muss.

# 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-->

Konfigurieren eines AD-Schattenkontos in der Backend-AD-Gesamtstruktur

1. Erstellen Sie einen neuen AD-Schattenkontobenutzer.

2. Der implizite UPN der AD-Gesamtstruktur, z. B. yourforest.local, ist standardmäßig für neue AD-Benutzer ausgewählt. Wählen Sie das entsprechende alternative UPN-Suffix aus, das Sie zuvor erstellt haben. Wählen Sie beispielsweise yourforest.com als das UPN-Suffix des Schattenkontobenutzers aus.

   

   Der UPN des Schattenkontobenutzers kann auch über PowerShell aktualisiert werden.

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

3. Der UPN des Schattenkontobenutzers muss exakt dem UPN des externen Frontend-Identitätsbenutzers entsprechen.
4. Testen Sie die Anmeldung des Frontend-Benutzers bei Workspace.
5. Stellen Sie sicher, dass alle erwarteten Ressourcen in Workspace aufgeführt sind, nachdem die Anmeldung erfolgreich war. Ressourcen, die dem AD-Schattenkonto zugeordnet sind, sollten angezeigt werden.

Konfigurieren des Benutzer-UPN für die Gast-Entra-ID, sodass er dem UPN des AD-Schattenkontos entspricht

Wenn externe Gastbenutzer zu einem Entra ID-Mandanten eingeladen werden, wird ein automatisch generierter UPN erstellt, der angibt, dass es sich um einen externen Benutzer handelt. Dem externen Entra ID-Benutzer wird automatisch das UPN-Suffix @Entra IDtenant.onmicrosoft.com zugewiesen, das für die Verwendung mit vereinfachtem SAML ungeeignet ist und nicht mit Ihrem AD-Schattenkonto übereinstimmt. Es muss aktualisiert werden, damit es einer importierten DNS-Domäne innerhalb von Entra ID und dem alternativen UPN-Suffix entspricht, das Sie in Ihrer AD-Gesamtstruktur erstellt haben.

1. Importieren Sie eine benutzerdefinierte Domäne in Entra ID, die dem alternativen UPN-Suffix entspricht, das Sie Ihrer AD-Gesamtstruktur hinzugefügt haben.

   

2. Laden Sie einen Gastbenutzer wie contractoruser@hotmail.co.uk ein und stellen Sie sicher, dass der eingeladene Gastbenutzer die Microsoft-Einladung zum Entra ID-Mandanten akzeptiert.

   Beispiel für ein von Microsoft generiertes UPN-Format für externe Gastbenutzer. contractoruser_hotmail.co.uk#EXT#@yourEntra IDtenant.onmicrosoft.com

   

   

   Wichtig:

   Citrix Cloud und Workspace können keine UPNs, die das #-Zeichen enthalten, für die SAML-Authentifizierung verwenden.

3. Installieren Sie die erforderlichen Azure PowerShell Graph-Module, um Entra ID-Benutzer verwalten zu können.

   Install-Module -Name "Microsoft.Graph" -Force
   Get-InstalledModule -Name  "Microsoft.Graph"
   <!--NeedCopy-->
   

4. Melden Sie sich mit einem globalen Administratorkonto und mit dem Geltungsbereich Directory.AccessAsUser.All bei Ihrem Entra ID-Mandanten an.

   Wichtig:

   Wenn Sie ein Konto mit weniger Rechten verwenden oder den Geltungsbereich Directory.AccessAsUser.All nicht angeben, können Sie Schritt 4 nicht abschließen und den UPN des Gastbenutzers nicht aktualisieren.

   $EntraTenantID = "<yourEntraTenantID>"
   Connect-MgGraph -Tenant $EntraTenantID -Scopes "Directory.AccessAsUser.All"
   <!--NeedCopy-->
   

5. Rufen Sie die gesamte Liste der externen Gastbenutzer in Ihrem Entra ID-Mandanten ab (optional).

   

   Get-MgUser -filter "userType eq 'Guest'" | Select Id,DisplayName,UserPrincipalName,Mail
   <!--NeedCopy-->
   

6. Rufen Sie die Gastbenutzeridentität ab, deren UPN aktualisiert werden muss, und aktualisieren Sie dann das UPN-Suffix.

   $GuestUserId = (Get-MgUser -UserId "contractoruser_hotmail.co.uk#EXT#@yourEntra IDtenant.onmicrosoft.com").Id
       
   Update-MgUser -UserId $GuestUserId -UserPrincipalName "contractoruser@yourforest.com"
   <!--NeedCopy-->
   

7. Prüfen Sie, ob die Gastbenutzeridentität anhand des neu aktualisierten UPN gefunden werden kann.

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

Testen der vereinfachten SAML-Lösung

Sobald alle dokumentierten Schritte in AD, Citrix Cloud und Ihrem SAML-Anbieter abgeschlossen sind, müssen Sie die Anmeldung testen und sicherstellen, dass die richtige Ressourcenliste für den Gastbenutzer in Workspace angezeigt wird.

Citrix empfiehlt die Verwendung der Browsererweiterung SAML-tracer für das gesamte SAML-Debugging. Die Erweiterung ist für die meisten der gängigen Webbrowser verfügbar. Die Erweiterung decodiert Base64-Anfragen und -Antworten in SAML-XML, wodurch sie für Menschen lesbar werden.

Beispiel für eine vereinfachte SAML-Assertion, bei der nur cip_upn für die Authentifizierung verwendet wird, die mit dem SAML-Tracer erfasst wurde.

1. Ordnen Sie AD-gestützten Benutzern und Schattenkontobenutzern oder Gruppen, die diese enthalten, die richtigen DaaS-Ressourcen zu.

2. Starten Sie die SAML-Tracer-Browsererweiterung und erfassen Sie den gesamten An- und Abmeldeablauf.

3. Melden Sie sich mit dem in der Tabelle angegebenen Attribut für den Frontend-Benutzertyp, den Sie testen möchten, bei Workspace an.

   Entra ID-Gastbenutzeranmeldung: Der Auftragnehmer, den Sie als Gastbenutzer zu Ihrem Entra ID-Mandanten eingeladen haben, hat die E-Mail-Adresse contractoruser@hotmail.co.uk.

   Geben Sie die E-Mail-Adresse des Gastbenutzers ein, wenn Sie von Entra ID dazu aufgefordert werden.

   ODER

   AD-gestützte EntraID-Benutzer/native EntraID-Benutzeranmeldung: Diese Entra ID-Benutzer erhalten UPNs im Format von adbackeduser@yourforest.com oder nativeuser@yourforest.com.

   Geben Sie den UPN des Benutzers ein, wenn Sie von Entra ID dazu aufgefordert werden.

4. Stellen Sie sicher, dass die Assertion nur das Attribut cip_upn für die Authentifizierung enthält und dass sie auch das für die Workspace-Benutzeroberfläche erforderliche Attribut displayName enthält.

5. Stellen Sie sicher, dass der Benutzer die erforderlichen DaaS-Ressourcen in der Benutzeroberfläche sehen kann.

Problembehandlung für die vereinfachte SAML-Lösung

Fehler wegen fehlendem Attribut cip_*

Ursache 1: Das SAML-Attribut ist in der SAML-Assertion nicht vorhanden, aber Citrix Cloud ist so konfiguriert, dass es erwartet wird. Sie haben es versäumt, die unnötigen cip_*-Attribute aus der Citrix Cloud-SAML-Verbindung im Abschnitt “SAML-Attribute” zu entfernen. Trennen Sie die SAML-Verbindung und stellen Sie sie her, um Verweise auf die unnötigen cip_*-Attribute zu entfernen.

Ursache 2: Dieser Fehler kann auch auftreten, wenn es kein entsprechendes AD-Schattenkonto gibt, nach dem die Citrix Cloud Connectors in Ihrer Backend-AD-Gesamtstruktur suchen können. Möglicherweise haben Sie die Frontend-Identität korrekt konfiguriert, aber die Backend-AD-Schattenkontoidentität mit einem übereinstimmenden UPN ist nicht vorhanden oder kann nicht gefunden werden.

Die Anmeldung ist erfolgreich, aber es werden keine DaaS-Ressourcen angezeigt, nachdem sich der Benutzer bei Workspace angemeldet hat

Ursache: Dies wird höchstwahrscheinlich durch falsche UPN-Zuordnungen der Frontend-Identität zum Backend verursacht.

Stellen Sie sicher, dass die beiden UPNs für die Frontend- und Backend-Identitäten genau übereinstimmen und denselben Endbenutzer darstellen, der sich bei Workspace anmeldet. Stellen Sie sicher, dass die DaaS-Bereitstellungsgruppe Zuordnungen zu den richtigen AD-Schattenkontobenutzern oder AD-Gruppen enthält, die diese enthalten.

Beim Start der DaaS-Ressourcen schlägt das FAS-SSON zur den VDAs fehl, die der AD-Domäne beigetreten sind

Beim Versuch, DaaS-Ressourcen zu starten, wird der Workspace-Endbenutzer aufgefordert, seine Windows-Anmeldeinformationen in der GINA einzugeben. Außerdem erscheint die Ereignis-ID 103 in den Windows-Ereignisprotokollen auf Ihren FAS-Servern.

[S103] Server [CC:FASServer] hat UPN [frontenduser@yourforest.com] SID S-1-5-21-000000000-0000000000-0000000001-0001 angefordert, aber das Lookup gab SID S-1-5-21-000000000-0000000000-0000000001-0002 zurück. [Korrelation: cc#967472c8-4342-489b-9589-044a24ca57d1]

Ursache: Ihre vereinfachte SAML-Bereitstellung ist von dem “SID-Nichtübereinstimmungsproblem” betroffen. Sie haben Frontend-Identitäten, die SIDs aus einer AD-Gesamtstruktur enthalten, die sich von der AD-Gesamtstruktur des Backend-Schattenkontos unterscheidet.
Senden Sie in der SAML-Assertion nicht cip_sid.

Die Anmeldung schlägt für AD-gestützte Benutzer fehl, wenn dasselbe UPN-Suffix in mehreren verbundenen AD-Gesamtstrukturen vorhanden ist

Citrix Cloud verfügt über mehrere Ressourcenstandorte und Connectors, die mit verschiedenen AD-Gesamtstrukturen verbunden sind. Die Anmeldung schlägt fehl, wenn AD-gestützte Benutzer verwendet werden, die aus einer anderen AD-Gesamtstruktur als der Schattenkonto-AD-Gesamtstruktur in Entra ID importiert wurden.

AD-Gesamtstruktur 1 wird mit Entra ID synchronisiert, um Frontend-Benutzer mit UPNs wie frontenduser@yourforest.com zu erstellen.

AD-Gesamtstruktur 2 enthält die Backend-Schattenkonten mit UPNs wie frontenduser@yourforest.com.

Ursache: Ihre vereinfachte SAML-Bereitstellung ist von dem “UPN-Zweideutigkeitsproblem” betroffen. Citrix Cloud kann nicht ermitteln, welche Connectors verwendet werden sollen, um die Backend-Identität des Benutzers nachzuschlagen.

Senden Sie in der SAML-Assertion nicht cip_sid.
Der UPN Ihres Benutzers ist in mehr als einer AD-Gesamtstruktur vorhanden, die mit Citrix Cloud verbunden ist.