SAML unter Verwendung von Identitäten für Azure AD für Gäste und B2B-Identitäten für die Workspace-Authentifizierung

Bevor Sie die Schritte in diesem Artikel befolgen, sollten Sie sich unbedingt vergewissern, ob “B2B 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 B2B 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 “B2B 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 B2B SAML nicht tatsächlich erforderlich ist.

Voraussetzungen

• Eine SAML-Anwendung, die speziell für die Verwendung mit B2B 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.
• Verwenden Sie entweder den impliziten UPN oder fügen Sie ein alternatives UPN-Suffix hinzu, das der Backend-AD-Gesamtstruktur hinzugefügt wurde, 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 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 von nativen oder Gast-Frontend-Identitäten, die nicht innerhalb der AD-Domäne existieren, in der die DaaS-Ressourcen veröffentlicht werden.

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 mit 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 für alle SAML-Flüsse weiterhin erforderlich, den displayName zu senden. Dies gilt auch für vereinfachte SAML-Flüsse, 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 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 ein B2B-Benutzer, der von einem anderen Entra ID-Mandanten importiert wurde?

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

In der Microsoft-Dokumentation finden Sie Einzelheiten zu B2B-Benutzern und dazu, wie Sie Mitgliedsbenutzer von anderen Entra-ID-Mandanten als Gastbenutzer in Ihren Entra-ID-Mandanten einladen können.

Überblick: B2B-Zusammenarbeit mit externen Gästen für Ihre Belegschaft Eigenschaften eines Microsoft Entra B2B-Collaboration-Benutzers

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-Spiegelkonten sind für diese Benutzer nicht erforderlich, da sie lokale SIDs und OIDs enthalten und daher DaaS-Ressourcen, die mit in die AD-Domäne eingebundenen VDAs 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 B2B 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 B2B 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 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-Fehlanpassungsproblems”. 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 Sie die B2B-SAML-Anwendung innerhalb 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 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 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. Legen Sie für den Anspruch “Unique User Identifier (Name ID)” das Name-Identifier-Format auf “nicht spezifiziert” und das Quellattribut auf user.localuserprincipalname fest.
   2. Lassen Sie für den Anspruch cip_upn den Standardwert user.localuserprincipalname.
   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 Sie die Citrix Cloud B2B SAML-Verbindung

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 können oft unterschiedliche Werte haben und sind in unterschiedlichen Active Directory-Attributen und in verschiedenen Entra-ID-Benutzerattributen definiert. Diese Lösung hängt vom UPN-Abgleich zwischen Frontend- und Backend-Identitäten ab und nicht vom E-Mail-Abgleich.

Sie können das implizite UPN-Suffix für Ihre Domäne verwenden, wenn es im DNS öffentlich routbar ist, oder für jeden externen Frontend-Benutzer, den Sie in Ihre Okta- oder Azure AD-Mandanten einladen möchten, ein passendes alternatives UPN-Suffix hinzufügen. Wenn AD yourdomain.local als impliziten UPN verwendet, müssen Sie ein alternatives UPN-Suffix wie yourdomain.com wählen. Mit der Entra-ID können Sie yourdomain.local in benutzerdefinierten Domänennamen nicht 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 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 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.

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

5. Aktualisieren Sie den Entra-ID-Benutzer mit einem UPN, der dem UPN entspricht, den Sie für Ihr AD Shadow-Konto 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. 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-->
   

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

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

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

Testen der B2B-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 B2B 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 Entra ID-Benutzer/native Entra ID-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.

Fehlerbehebung bei der B2B-SAML-Lösung

Falscher UPN wird in der SAML-Assertion gesendet

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

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