SAML verwendet Azure AD für Gast- und B2B-Identitäten für die Workspaceauthentifizierung

Bevor Sie mit diesem Artikel fortfahren, müssen Sie unbedingt verstehen, ob B2B SAML für Ihren Authentifizierungsanwendungsfall 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, beachten Sie die Szenarien, in denen B2B SAML geeignet ist, und die Arten von Identitäten, die 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 B2B SAML erhöht die Belastung der Citrix Cloud-Connectors, da diese für jede Workspace-Endbenutzeranmeldung die E-Mail-Adresse, SID und OID des Benutzers nachschlagen müssen, anstatt diese Werte durch die SAML-Assertion bereitzustellen. Das Senden aller vier cip_*-Attribute in der SAML-Assertion ist aus Leistungssicht des Citrix Cloud-Connectors vorzuziehen, wenn B2B-SAML nicht wirklich erforderlich ist.

Voraussetzungen

• Eine speziell für die Verwendung mit B2B SAML konfigurierte SAML-Anwendung, die zur Authentifizierung innerhalb der SAML-Assertion nur cip_upn 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.
• Verwenden Sie entweder den impliziten UPN oder fügen Sie ein alternatives UPN-Suffix zum Back-End-AD-Forest hinzu, in dem 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 B2B 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. B2B SAML ermöglicht die Verwendung nativer oder Gast-Frontend-Identitäten, die innerhalb der AD-Domäne, in der DaaS-Ressourcen veröffentlicht werden, nicht vorhanden sind.

Was ist B2B 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. B2B 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 weiterhin notwendig, displayName für alle SAML-Flows zu senden, einschließlich B2B 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 innerhalb Ihres SAML-Anbieterverzeichnisses 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 ein B2B-Benutzer, der aus einem anderen Entra ID-Mandanten importiert wurde?

Ein B2B-Benutzer ist ein Entra ID-Benutzer, der als Mitglied innerhalb von Entra ID-Mandant 1 existiert und als Gastbenutzer zu anderen Entra ID-Mandanten wie Entra ID-Mandant 2 eingeladen wird. Die B2B-SAML-App ist im Entra-ID-Mandanten 2 konfiguriert und als SAML-IdP mit Citrix Cloud verbunden. B2B-Benutzer benötigen passende AD-Backend-Schattenkonten, um DaaS-Ressourcen auflisten und starten zu können. Der B2B-Benutzer muss einem entsprechenden Schattenkonto im Active Directory zugeordnet werden.

Ausführliche Informationen zu B2B-Benutzern sowie Informationen zum Einladen von Mitgliedsbenutzern aus anderen Entra ID-Mandanten als Gastbenutzer zu Ihrem Entra ID-Mandanten finden Sie in der Microsoft-Dokumentation.

Übersicht: B2B-Zusammenarbeit mit externen Gästen für Ihre Belegschaft Eigenschaften eines Microsoft Entra B2B-Zusammenarbeitsbenutzers

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. Für diese Benutzer sind keine AD-Backend-Schattenkonten erforderlich, da sie lokale SIDs und OIDs enthalten und daher DaaS-Ressourcen auflisten und starten können, die mit VDAs veröffentlicht wurden, die einer AD-Domäne beigetreten sind.

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 Vertragsarbeiter als auch festangestellte Mitarbeiter in Ihrer Identitätsplattform haben, funktioniert B2B SAML für beide Arten von Frontend-Identitäten, ist aber nur obligatorisch, wenn Sie einige Konten vom Typ “native SAML-Benutzeridentität” haben.

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 B2B SAML nicht verwenden und 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 B2B 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.

B2B SAML verhindert das Auftreten des “SID-Mismatch-Problems”. 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 Schattenkontobenutzern wird mit dem UPN des Front-End-Benutzers durchgeführt, der dann dem entsprechenden Back-End-Schattenkontobenutzer zugeordnet wird.

Beispiel für das SID-Mismatch-Problem: FrontEnd-Benutzer wurde von Entra ID Connect erstellt und wird von 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.

B2B-SAML-Anwendung in Entra ID für externe Gastkonten konfigurieren

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 B2B SAML UPN Only.

   

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 Europa, 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 Citrix Cloud Government-Region 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 Europa, 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 Citrix Cloud Government-Region 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 Europa, 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 Citrix Cloud Government-Region 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. Klicken Sie im Abschnitt Attribute & Ansprüche auf 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. Legen Sie für den Anspruch Unique User Identifier (Name ID) das Namenskennungsformat auf “nicht angegeben§ und das Quellattribut auf user.localuserprincipalname fest.
   2. Belassen Sie für den Anspruch cip_upn den Standardwert user.localuserprincipalname.
   3. Belassen 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 die Dreipunktschaltfläche (…) 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 & 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.

    

    

Citrix Cloud B2B SAML-Verbindung konfigurieren

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. Während DaaS-Starts können Vertragsbenutzer die Windows-Anmeldeinformationen nicht manuell eingeben, um den Start abzuschließen, da sie das Kennwort des AD-Schattenkontos 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 handelt es sich aus Gründen der Benutzerfreundlichkeit um denselben Wert, aber UPN und E-Mail können häufig unterschiedliche Werte haben und sind in unterschiedlichen Active Directory-Attributen und innerhalb unterschiedlicher Entra-ID-Benutzerattribute definiert. Diese Lösung basiert auf einem UPN-Abgleich zwischen Frontend- und Backend-Identitäten und nicht auf einem E-Mail-Abgleich.

Sie können das implizite UPN-Suffix für Ihre Domäne verwenden, wenn es im DNS öffentlich routbar ist, oder ein passendes alternatives UPN-Suffix für jeden externen FrontEnd-Benutzer hinzufügen, den Sie zu Ihren Okta- oder Azure AD-Mandanten einladen möchten. Wenn AD yourdomain.local als impliziten UPN verwendet, müssen Sie ein alternatives UPN-Suffix wie yourdomain.com wählen. Entra ID erlaubt Ihnen nicht, yourdomain.local in benutzerdefinierte Domänennamen einzufügen.

Wenn Sie beispielsweise einen externen Benutzer contractoruser@hotmail.co.uk einladen und diesen mit einem Back-End-AD-Schattenkonto contractoruser@yourforest.com verknüpfen möchten, fügen Sie yourforest.com als ALT-UPN-Suffix innerhalb Ihres AD-Forests 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 Dialogfeld Ausführen, geben Sie domain.msc ein und klicken Sie anschließend 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-->

AD-Schattenkonto in Ihrem Backend-AD-Forest konfigurieren

1. Erstellen Sie einen neuen AD-Schattenkontobenutzer.

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

   

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

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

3. Der UPN des Schattenkontobenutzers muss genau mit dem UPN des externen FrontEnd-Identitätsbenutzers übereinstimmen.
4. Testen Sie die Anmeldung des FrontEnd-Benutzers bei Workspace.
5. Überprüfen Sie, ob alle erwarteten Ressourcen im Workspace aufgelistet sind, nachdem die Anmeldung erfolgreich war. Ressourcen, die dem AD-Schattenkonto zugeordnet sind, sollten angezeigt werden.

UPN des Gast-Entra-ID-Benutzers übereinstimmend mit dem UPN des AD-Schattenkontos konfigurieren

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 B2B 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 zu 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 annimmt.

   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 für die SAML-Authentifizierung keine UPNs verwenden, die das Zeichen # enthalten.

3. Installieren Sie die erforderlichen Azure PowerShell-Graphmodule, damit Sie Entra-ID-Benutzer verwalten können.

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

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

   Wichtig:

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

         Connect-MgGraph -Scopes Directory.AccessAsUser.All
   <!--NeedCopy-->
   

5. Aktualisieren Sie den Entra-ID-Benutzer mit einem UPN, der mit dem UPN übereinstimmt, den Sie für Ihr AD-Schattenkonto konfiguriert haben.

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

6. Holen Sie sich die vollständige Liste der externen Gastbenutzer innerhalb Ihres Entra ID-Mandanten (optional).

   

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

7. Rufen Sie die Gastbenutzeridentität ab, deren UPN aktualisiert werden muss, und aktualisieren Sie anschließend 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-->
   

8. Überprüfen Sie, ob die Identität des Gastbenutzers anhand des neu aktualisierten UPN gefunden werden kann.

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

B2B-SAML-Lösung testen

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 einer B2B-SAML-Assertion, die nur cip_upn zur mit SAML Tracer erfassten Authentifizierung verwendet.

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.

   Anmeldung des Entra ID-Gastbenutzers: Der Auftragnehmerbenutzer, 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ützter Entra-ID-Benutzer/Native Entra-ID-Benutzeranmeldung: Diese Entra-ID-Benutzer haben UPNs im Format 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.

Fehlerbehebung bei der B2B-SAML-Lösung

Falscher UPN wird innerhalb der SAML-Assertion gesendet

Ursache: Dies kann nur für B2B-Konten auftreten, die von Entra ID-Mandant 1 in Entra ID-Mandant 2 importiert wurden. Bei Verwendung von B2B-Benutzern, die aus anderen Entra ID-Mandanten importiert wurden, kann innerhalb der SAML-Assertion der falsche UPN gesendet werden. Wenn user.userprincipalname verwendet wird und sich der Endbenutzer mit einem B2B-Benutzer anmeldet, der aus einem anderen Entra ID-Mandanten importiert wurde, wird in der SAML-Assertion der falsche Wert für cip_upn gesendet. Der in der SAML-Assertion verwendete Wert für cip_upn stammt vom Quell-Entra-ID-Mandanten, der den B2B-Benutzer als Mitglied enthält. Die Verwendung von user.localuserprincipalname stellt sicher, dass der Wert für cip_upn aus dem Entra ID-Mandanten übernommen wird, wobei der B2B-Benutzer als Gast eingeladen wird.

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 SAML und verbinden Sie es erneut, 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] angefordert SID S-1-5-21-000000000-0000000000-0000000001-0001, aber die Suche hat SID S-1-5-21-000000000-0000000000-0000000001-0002 zurückgegeben. [correlation: cc#967472c8-4342-489b-9589-044a24ca57d1]

Ursache: Ihre B2B-SAML-Bereitstellung leidet unter dem “SID-Mismatch-Problem”. 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 AD-Gesamtstruktur des Schattenkontos in Entra ID importiert wurden.

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

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

Ursache: Ihre B2B-SAML-Bereitstellung leidet unter dem “UPN-Mehrdeutigkeitsproblem”. 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.

Citrix Cloud SAML-Verbindung konfigurieren

Alle Citrix-Anmeldeabläufe müssen vom Service Provider über eine Workspace-URL oder eine Citrix Cloud GO-URL initiiert werden.

Holen Sie sich die SAML-Endpunkte der Entra ID SAML-Anwendung von Ihrem Entra ID-Portal, um in Citrix Cloud zu gelangen.

Beispiele für Entra ID SAML-Endpunkte zur Verwendung innerhalb der Citrix Cloud SAML-Verbindung

Wichtig:

EntraID SSO- und Logout-SAML-Endpunkte haben dieselbe URL.

• Entitäts-ID des Identitätsanbieters: https://sts.windows.net/<yourEntraIDTenantID>
• URL des SSO-Dienstes des Identitätsanbieters: https://login.microsoftonline.com/<yourEntraIDTenantID>/saml2
• Abmelde-URL des Identitätsanbieters: https://login.microsoftonline.com/<yourEntraIDTenantID>/saml2