EnglishFrançaisDeutschEspañolItaliano日本語한국어NederlandsPortuguês (Brasil)中文 (简体)中文 (繁體, 台灣)
Skip to main content

1. September 2026

First-Gen-Mandanten – Voraussetzungen für die Ausführung des First-Gen-Pod-Bereitstellungsassistenten

Bevor Sie den First-Gen-Pod-Bereitstellungsassistenten ausführen, stellen Sie sicher, dass Ihre Umgebung diese Voraussetzungen erfüllt. Die folgenden Elemente sind erforderlich, damit Sie die angeforderten Werte im Pod-Bereitstellungsassistenten angeben und mit der nächsten Assistentenseite fortfahren können.

Wichtig: Diese Informationen gelten nur, wenn Sie auf eine First-Gen-Mandantenumgebung in der First-Gen-Steuerungsebene zugreifen können. Wie im KB-Artikel 92424 beschrieben, hat die First-Gen-Steuerungsebene das Ende der Verfügbarkeit (End of Availability, EOA) erreicht. Weitere Informationen finden Sie in diesem Artikel.

Wichtig: Bevor Sie den Pod-Bereitstellungsassistenten starten und Ihren Pod bereitstellen, müssen Sie zusätzlich zu den unten aufgeführten Anforderungen die folgenden wichtigen Punkte beachten:

  • Für eine erfolgreiche Pod-Bereitstellung darf keine der Microsoft Azure-Richtlinien, die Sie oder Ihr IT-Team in Ihrer Microsoft Azure-Umgebung festgelegt haben, die Erstellung der Pod-Komponenten blockieren, ablehnen oder einschränken. Außerdem müssen Sie sicherstellen, dass die integrierten Richtliniendefinitionen Ihrer Microsoft Azure-Richtlinien die Erstellung der Pod-Komponenten nicht blockieren, ablehnen oder einschränken. Zwei Beispiele für zulässige Elemente sind: Sie und Ihr IT-Team müssen sicherstellen, dass keine Ihrer Microsoft Azure-Richtlinien die Erstellung von Komponenten auf dem Azure-Speicherkonto blockiert, verweigert oder einschränkt. Außerdem müssen Sie sicherstellen, dass Ihre Microsoft Azure-Richtlinien von Microsoft.MarketplaceOrdering/*zulassenresourceType. Der Pod-Bereitstellungsprozess basiert auf der Annahme von Azure Marketplace-Angeboten von unserer publisherID. Informationen zu Azure-Richtlinien finden Sie in der Dokumentation zu Azure-Richtlinien. Informationen dazu, wie der Dienst den Microsoft.MarketplaceOrdering/* Ressourcentyp verwendet, finden Sie unter Wenn Ihre IT- oder Sicherheitsorganisation Einschränkungen bei der Nutzung von Azure Marketplace-Angeboten oder Marketplace-Bestellungen hat.
  • Der Pod-Bereitsteller erfordert, dass Ihr Azure-Speicherkonto dem Bereitsteller erlaubt, den Azure-Kontotyp StorageV2 in der Ressourcengruppe des Pods im Abonnement zu erstellen. Dieses Speicherkonto wird für die App Volumes-Funktionen des Pods verwendet. Stellen Sie während des Pod-Bereitstellungsvorgangs sicher, dass Ihre Microsoft Azure-Richtlinien die Erstellung von Inhalten, die den Azure-Kontotyp StorageV2 erfordern, nicht einschränken oder ablehnen.
  • Alle mit der Cloud verbundenen Pods müssen zum Zeitpunkt der Bereitstellung dieser Pods für denselben Satz von Active Directory-Domänen sichtbar sein.

Voraussetzungen für alle Bereitstellungen

  • Wenn Sie einen weiteren Pod hinzufügen, können Sie dasselbe Abonnement verwenden, das Sie für die vorherigen Pods verwendet haben. Alternativ können Sie ein anderes Abonnement verwenden, wenn dies in Ihrer Organisation erforderlich ist. Wenn Sie die Verwendung eines anderen Abonnements planen, müssen Sie die im First-Gen-Bereitstellungshandbuch beschriebenen Schritte ausführen, um die Abonnement-ID, die Verzeichnis-ID, die Anwendungs-ID und den Anwendungsschlüssel abzurufen. Sie müssen sicherstellen, dass das verwendete Abonnement die in diesem Handbuch beschriebenen Anforderungen erfüllt, insbesondere, dass der Dienstprinzipal über die entsprechenden Rollenberechtigungen verfügt, die auf den relevanten Ebenen in Ihrem Abonnement gewährt werden.

  • Wenn Ihr Mandant für die Verwendung von Universal Broker für Ihre Pods in Microsoft Azure konfiguriert ist, müssen Sie beim Ausführen des Pod-Bereitstellungsassistenten zum Hinzufügen eines neuen Pods eine Site angeben. Sie können entweder eine vorhandene Site auswählen oder eine neue Site angeben.

  • Stellen Sie sicher, dass in der Region, in der Sie den Pod bereitstellen möchten, ein VNet vorhanden ist, das die unter Konfigurieren des erforderlichen virtuellen Netzwerks in Microsoft Azure beschriebenen Anforderungen erfüllt.

    Wichtig: Nicht alle Microsoft Azure-Regionen unterstützen GPU-fähige virtuelle Maschinen. Wenn Sie den Pod für GPU-fähige Desktops oder Remoteanwendungen verwenden möchten, stellen Sie sicher, dass die Microsoft Azure-Region, die Sie für den Pod auswählen, die VM-Typen der NV-Serie, NVv4-Serie und NCv2-Serie, die Sie verwenden möchten, bereitstellt und dass diese in dieser Horizon Cloud-Version unterstützt werden. Weitere Informationen finden Sie in der Microsoft-Dokumentation unter https://azure.microsoft.com/en-us/regions/services/ .

  • Stellen Sie sicher, dass Ihr VNet so konfiguriert ist, dass es auf einen DNS verweist, der externe Adressen auflösen kann. Der Pod-Bereitsteller muss in der Lage sein, externe Adressen in der Horizon Cloud-Steuerungsebene zu erreichen, um die Pod-Software sicher in Ihre Microsoft Azure-Umgebung herunterzuladen.

  • Stellen Sie sicher, dass die DNS-, Port- und Protokollanforderungen des Pod-Bereitstellers erfüllt sind, wie unter First-Gen-Mandanten – Horizon Cloud on Microsoft Azure-Bereitstellungen – Anforderungen an die Auflösung von Hostnamen, DNS-Namen und First-Gen-Mandanten – Horizon Cloud-Pod – Anforderungen an Ports und Protokolle beschrieben.

  • Wenn Sie einen Proxy für ausgehenden Internetzugriff verwenden müssen, vergewissern Sie sich, dass Sie die Netzwerkinformationen für Ihre Proxy-Konfiguration und ggf. die erforderlichen Anmeldedaten für die Authentifizierung haben. Für den Pod-Bereitstellungsprozess ist ein ausgehender Internetzugriff erforderlich.

    Wichtig: Das Bearbeiten oder Aktualisieren der Proxy-Einstellungen auf einem Pod nach der Bereitstellung des Pods in Microsoft Azure wird derzeit nicht unterstützt. Auch das Hinzufügen einer Proxy-Konfiguration zu einem bereitgestellten Pod, der ohne Proxy-Einstellungen bereitgestellt wurde, wird derzeit nicht unterstützt.

  • Stellen Sie sicher, dass Sie über die Informationen für mindestens einen NTP-Server verfügen, den die Pod-Manager-Instanzen und Unified Access Gateway-Instanzen für die Uhrzeitsynchronisierung verwenden sollen. Der NTP-Server kann ein öffentlicher NTP-Server oder Ihr eigener NTP-Server sein, den Sie für diesen Zweck eingerichtet haben. Der angegebene NTP-Server muss über die virtuellen Netzwerke erreichbar sein, in denen Sie die Pod-Manager-Instanzen und Unified Access Gateway-Instanzen bereitstellen möchten. Wenn Sie beabsichtigen, einen NTP-Server mit seinem Domänennamen anstelle einer numerischen IP-Adresse zu verwenden, müssen Sie außerdem sicherstellen, dass das für das virtuelle Netzwerk konfigurierte DNS den Namen des NTP-Servers auflösen kann.

    Hinweis: Es wird empfohlen, denselben NTP-Server für die Pod-Manager-Instanzen, Unified Access Gateway-Instanzen und Ihre Active Directory-Server zu verwenden. Wenn diese Instanzen verschiedene NTP-Server verwenden, kann es zu Zeitverzögerungen kommen. Solche Zeitverzögerungen können später zu Fehlern führen, wenn das Gateway versucht, Endbenutzersitzungen für ihre Desktops und Anwendungen zu authentifizieren.

  • Wenn Sie nicht möchten, dass der Bereitsteller die erforderlichen Subnetze automatisch erstellt, stellen Sie sicher, dass die erforderlichen Subnetze im Voraus erstellt wurden und im VNet vorhanden sind. Die Schritte zum Erstellen der erforderlichen Subnetze im Voraus finden Sie unter First-Gen-Mandanten – Erstellen der erforderlichen Subnetze des Horizon Cloud-Pods im Vorfeld der Pod-Bereitstellung in Ihrem VNet in Microsoft Azure und First-Gen-Mandanten – Bei Verwendung vorhandener Subnetze für einen Horizon Cloud-Pod in Microsoft Azure.

    VORSICHT:

    Die Subnetze, die Sie in Ihrem VNet für die Pod-Bereitstellung manuell erstellen, müssen leer bleiben. Verwenden Sie keine vorhandenen Subnetze wieder, die bereits Elemente enthalten, die IP-Adressen in diesen Subnetzen verwenden. Wenn eine IP-Adresse bereits in den Subnetzen verwendet wird, treten mit hoher Wahrscheinlichkeit Probleme auf, wie z. B. das Fehlschlagen der Pod-Bereitstellung und andere IP-Konflikte im Nachhinein. Legen Sie keine Ressourcen in diesen Subnetzen ab und verwenden Sie keine der IP-Adressen an anderer Stelle. Dieser Warnhinweis gilt auch für Pods, die über Horizon Cloud bereitgestellt wurden – verwenden Sie keine Subnetze erneut, in denen Sie bereits einen Pod bereitgestellt haben.

    Wichtig: Wenn Sie nach Ihrem ersten Pod weitere Pods bereitstellen, verwenden Sie kein vorhandenes Subnetz, das bereits von einem vorhandenen Pod verwendet wird. Versuchen Sie nicht, ein Subnetz freizugeben, das bereits von einem Pod verwendet wird. Wenn Sie ein Subnetz auswählen, das bereits von einem anderen Pod verwendet wird, unterbricht dies den Pod-Betrieb für diesen vorhandenen Pod und für den Pod, den Sie mit seinem Subnetz bereitstellen.

    Es wird empfohlen, für jeden Pod ein separates VNet zu verwenden. Diese Empfehlung stammt aus der Anleitung, die Anzahl der Pods, die Sie in einem einzelnen Abonnement bereitstellen, sorgfältig zu planen. Diese wird unter Dinge, die Sie vorher wissen sollten und Während Ihrer Verwendung von Horizon Cloud beschrieben. Um Microsoft Azure-Grenzwerte innerhalb eines einzelnen Abonnements zu vermeiden, vermeiden Sie bei einem einzelnen Pod pro Abonnement die Wahrscheinlichkeit, dass diese Grenzwerte erreicht werden. Da Microsoft Azure erfordert, dass jedes Abonnement über ein eigenes VNet verfügt, halten Sie sich bei Einhaltung der Best Practice eines einzelnen Pods pro Abonnement automatisch an die Best Practice der Verwendung eines separaten VNet für jeden Pod.

  • Wenn der Bereitsteller die erforderlichen Subnetze erstellt, stellen Sie sicher, dass Sie die Adressbereiche kennen, die Sie in den Assistenten für das Management-Subnetz, das Desktop-Subnetz und das DMZ-Subnetz eingeben. Das DMZ-Subnetz ist erforderlich, wenn Sie die externe Unified Access Gateway-Konfiguration verwenden möchten. Stellen Sie außerdem sicher, dass sich diese Bereiche nicht überlappen. Die Eingabe der Adressbereiche erfolgt in CIDR-Notation (Classless Inter-Domain Routing Notation). Der Assistent zeigt einen Fehler an, wenn sich die eingegebenen Subnetzbereiche überlappen. Für den Management-Subnetzbereich ist ein CIDR von mindestens /27 erforderlich. Für den DMZ-Subnetzbereich ist mindestens CIDR /28 erforderlich. Wenn Sie die Bereiche Verwaltung und DMZ-Subnetz gemeinsam nutzen möchten, können Sie den Bereich des DMZ-Subnetzes ähnlich wie das Management-Subnetz mit einer angegebenen IP angeben. Wenn das Management-Subnetz beispielsweise 192.168.8.0/27 ist, wäre ein entsprechendes DMZ-Subnetz 192.168.8.32/27.

    Wichtig: Die CIDRs, die Sie in die Felder des Assistenten eingeben, müssen so definiert sein, dass jede Kombination aus Präfix und Bitmaske zu einem IP-Adressbereich mit dem Präfix als Ausgangs-IP-Adresse führt. Microsoft Azure erfordert, dass das CIDR-Präfix den Anfang des Bereichs darstellt. Beispielsweise würde das korrekte CIDR 192.168.182.48/28 zu einem IP-Bereich von 192.168.182.48 bis 192.168.182.63 führen, wobei das Präfix mit der IP-Startadresse (192.168.182.48) identisch ist. Das falsche CIDR 192.168.182.60/28 würde jedoch den IP-Bereich 192.168.182.48 bis 192.168.182.63 ergeben, in dem die IP-Startadresse nicht mit dem Präfix 192.168.182.60 identisch ist. Stellen Sie sicher, dass Ihre CIDRs IP-Adressbereiche ergeben, bei denen die IP-Startadresse mit dem CIDR-Präfix übereinstimmt.

  • Wenn der Bereitsteller die erforderlichen Subnetze erstellt, stellen Sie sicher, dass Subnetze mit diesen Adressbereichen nicht bereits im VNet vorhanden sind. In diesem Szenario erstellt der Bereitsteller selbst die Subnetze automatisch mithilfe der Adressbereiche, die Sie im Assistenten angeben. Wenn der Assistent Subnetze erkennt, in denen diese Bereiche bereits vorhanden sind, zeigt der Assistent einen Fehler über sich überschneidende Adressen an und fährt nicht fort. Wenn Ihr VNet ein Peer ist, stellen Sie außerdem sicher, dass die CIDR-Adressbereiche, die Sie im Assistenten eingeben möchten, bereits im Adressbereich des VNet enthalten sind.

Voraussetzungen für die Unified Access Gateway-Konfigurationen

Wenn Sie möchten, dass der Pod eine Unified Access Gateway-Konfiguration verwendet, müssen Sie Folgendes angeben:

  • Der vollqualifizierte Domänenname (FQDN), den Ihre Endbenutzer für den Zugriff auf den Dienst verwenden werden. Wenn Sie vorhaben, denselben FQDN sowohl für die externe als auch für die interne Gateway-Konfiguration zu verwenden, müssen Sie nach der Bereitstellung des Pods den eingehenden Datenverkehr der Endbenutzer-Clients so konfigurieren, dass er zum entsprechenden Gateway-Lastausgleichsdienst weitergeleitet wird. Das Ziel besteht darin, das Routing so einzurichten, dass der Client-Datenverkehr aus dem Internet an den öffentlichen Microsoft Azure-Lastausgleich des externen Gateways und der Client-Datenverkehr aus Ihrem Intranet an den internen Microsoft Azure-Lastausgleich des internen Gateways weitergeleitet wird. In diesem Szenario, in dem beide Gateways denselben FQDN haben, konfigurieren Sie ein aufgeteiltes DNS (Split Domain Name System), um die Gateway-Adresse entweder zum externen Gateway oder zum internen Gateway aufzulösen, je nach dem Ursprungsnetzwerk der DNS-Abfrage des Endbenutzer-Clients. Dann kann derselbe FQDN, der im Endbenutzer-Client verwendet wird, zum externen Gateway weitergeleitet werden, wenn sich der Client im Internet befindet, und zum internen Gateway, wenn sich der Client in Ihrem internen Netzwerk befindet.

    Wichtig: Dieser FQDN darf keine Unterstriche enthalten. In dieser Version schlagen Verbindungen zu den Unified Access Gateway-Instanzen fehl, wenn der FQDN Unterstriche enthält.

  • Ein signiertes SSL-Serverzertifikat (im PEM-Format) basierend auf diesem FQDN. Die Unified Access Gateway-Funktionen erfordern SSL für Clientverbindungen, wie in der Unified Access Gateway-Produktdokumentation beschrieben. Das Zertifikat muss von einer vertrauenswürdigen Zertifizierungsstelle (CA) signiert sein. Die PEM-Datei muss die gesamte Zertifikatskette mit dem privaten Schlüssel enthalten. Beispielsweise muss die einzelne PEM-Datei das SSL-Serverzertifikat, alle erforderlichen Zwischenzertifizierungsstellen-Zertifikate, das Stamm-Zertifizierungsstellenzertifikat und den privaten Schlüssel enthalten. OpenSSL ist ein Tool, das Sie zum Erstellen der PEM-Datei verwenden können.

    Wichtig: Alle Zertifikate in der Zertifikatskette müssen gültige Zeiträume aufweisen. Für die Unified Access Gateway-VMs ist es erforderlich, dass alle Zertifikate in der Kette, einschließlich aller Zwischenzertifikate, über gültige Zeiträume verfügen. Wenn ein Zertifikat in der Kette abgelaufen ist, können beim Hochladen des Zertifikats in die Unified Access Gateway-Konfiguration später unerwartete Fehler auftreten.

  • Wenn Sie mit einer externen Unified Access Gateway-Konfiguration bereitstellen, müssen Sie ein DMZ-Subnetz (demilitarisierte Zone) angeben. Sie können dieses DMZ-Subnetz auf zwei Arten bereitstellen:

    • Erstellen des DMZ-Subnetzes im Voraus auf dem VNet. Bei dieser Methode müssen Sie auch die Verwaltungs- und Desktop-Mandantensubnetze im Voraus erstellen. Weitere Informationen finden Sie in den Schritten unter First-Gen-Mandanten – Erstellen Sie vor der Pod-Bereitstellung die erforderlichen Subnetze des Horizon Cloud-Pods in Ihrem VNet in Microsoft Azure.

    • Automatische Erstellung des DMZ-Subnetzes durch den Bereitsteller während der Bereitstellung. Bei dieser Methode müssen Sie den Adressbereich in den Assistenten für das DMZ-Subnetz eingeben und sicherstellen, dass sich der Bereich nicht mit den Bereichen für das Management- und Desktop-Mandantensubnetz überschneidet. Die Eingabe der Adressbereiche erfolgt in CIDR-Notation (Classless Inter-Domain Routing Notation). Der Assistent zeigt einen Fehler an, wenn sich die eingegebenen Subnetzbereiche überlappen. Für den DMZ-Subnetzbereich ist mindestens CIDR /28 erforderlich. Wenn Sie die Bereiche Verwaltung und DMZ-Subnetz gemeinsam nutzen möchten, können Sie den Bereich des DMZ-Subnetzes genauso angeben wie das Management-Subnetz mit einer angegebenen IP. Wenn das Management-Subnetz beispielsweise 192.168.8.0/27 ist, wäre ein entsprechendes DMZ-Subnetz 192.168.8.32/27. Beachten Sie auch den wichtigen Hinweis unter Voraussetzungen für alle Bereitstellungen , um sicherzustellen, dass der IP-Adressbereich über eine Kombination aus Präfix und Bitmaske verfügt, die dazu führt, dass der Bereich das Präfix als IP-Startadresse aufweist.

  • Wenn Sie mit einer externen Unified Access Gateway-Konfiguration bereitstellen und verhindern möchten, dass eine öffentliche IP-Adresse für den Lastausgleichsdienst der Konfiguration verwendet wird, müssen Sie eine IP-Adresse angeben, die Sie in Ihren DNS-Einstellungen dem FQDN zugeordnet haben, den Ihre Endbenutzer für PCoIP-Verbindungen in ihren Horizon Clients verwenden sollen.

Weitere Informationen zu den für Unified Access Gateway erforderlichen Überlegungen zur PEM-Datei finden Sie unter First-Gen-Mandanten – Konvertieren einer Zertifikatsdatei in das PEM-Format, das für First-Gen-Horizon Cloud-Pod-Bereitstellungen erforderlich ist.

Voraussetzungen bei der Bereitstellung mit einer externen Unified Access Gateway-Konfiguration unter Verwendung eines eigenen VNet oder Abonnements, das vom VNet oder Abonnement des Pods getrennt ist

Hinweis: Durch die Bereitstellung eines externen Gateways mit einem eigenen VNet wird eine Gateway Connector-VM bereitgestellt. In Port- und Protokollanforderungen für einen Horizon Cloud-Pod enthält der Abschnitt, in dem die Ports und Protokolle der Gateway-Connector-VM beschrieben werden, auch eine Beschreibung dieser Gateway-Connector-VM, die besagt, dass diese Gateway-Connector-VM einen Namen hat, der eine Zeichenfolge wie , hcs-IDenthält, wobei ID die Bereitsteller-ID des Gateways ist, und ein node Teil.

Zusammen mit den obigen Voraussetzungen bei der Bereitstellung mit einer Unified Access Gateway-Konfiguration sind diese Voraussetzungen spezifisch für den Anwendungsfall, in dem das externe Gateway in einem eigenen VNet oder einem eigenen Abonnement bereitgestellt wird. Die Verwendung eines eigenen Abonnements ist ein Sonderfall der Verwendung eines eigenen VNet, da das separate Abonnement über ein eigenes VNet verfügen muss, da VNets auf ein Abonnement beschränkt sind.

Voraussetzungen bei der Bereitstellung mit einer Zwei-Faktor-Authentifizierungskonfiguration

Wenn Sie vorhaben, die Zwei-Faktor-Authentifizierung zu verwenden oder diese mit einem lokalen Zwei-Faktor-Authentifizierungsserver zu verwenden, stellen Sie sicher, dass Sie über die folgenden Informationen aus der Konfiguration Ihres Authentifizierungsservers verfügen, damit Sie sie in den erforderlichen Feldern des Assistenten "Pod hinzufügen" angeben können.

Rufen Sie die folgenden aufgelisteten Informationen je nach Ihrem Typ ab.

  • RADIUS

    Wenn Sie Einstellungen sowohl für einen primären als auch für einen zusätzlichen RADIUS-Server konfigurieren, rufen Sie die Informationen für jeden von ihnen ab.

    • Geben Sie den DNS-Namen oder die IP-Adresse des Authentifizierungsservers ein.

    • Der gemeinsame geheime Schlüssel, der für die Ver- und Entschlüsselung in den Protokollmeldungen des Authentifizierungsservers verwendet wird

    • Portnummern für die Authentifizierung, in der Regel 1812/UDP für RADIUS.

    • Authentifizierungstyp Zu den Authentifizierungstypen gehören PAP (Password Authentication Protocol), CHAP (Challenge Handshake Authentication Protocol), MSCHAP1, MSCHAP2 (Microsoft Challenge Handshake Authentication Protocol, Version 1 und 2).

      Hinweis: Überprüfen Sie in der Dokumentation Ihres RADIUS-Anbieters auf das Authentifizierungsprotokoll, das Ihr RADIUS-Anbieter empfiehlt, und verwenden Sie den angegebenen Protokolltyp. Die Pod-Funktionalität zur Unterstützung der Zwei-Faktor-Authentifizierung mit RADIUS wird von den Unified Access Gateway-Instanzen bereitgestellt, und Unified Access Gateway unterstützt PAP, CHAP, MSCHAP1 und MSCHAP2. PAP ist in der Regel weniger sicher als MSCHAP2. PAP ist auch ein einfacheres Protokoll als MSCHAP2. Obwohl die meisten RADIUS Anbieter mit dem einfacheren PAP-Protokoll kompatibel sind, sind einige RADIUS Anbieter nicht so kompatibel mit dem sichereren MSCHAP2.

  • RSA SecurID

    Hinweis: Der RSA SecurID-Typ wird für Horizon Cloud on Microsoft Azure-Bereitstellungen unterstützt, auf denen Manifest 3139.x oder höher ausgeführt wird. Die Benutzeroberflächenoption zur Angabe des RSA SecurID-Typs in den Assistenten "Pod hinzufügen" und "Pod bearbeiten" wird ab Mitte März 2022 in den Assistenten zur Auswahl angezeigt.

    • SSL-Zertifikat des RSA SecurID Authentication Manager-Servers.
    • Nummer des RSA SecurID-Kommunikationsports. In der Regel 5555, wie in den RSA Authentication Manager-Systemeinstellungen für die RSA SecurID-Authentifizierungs-API festgelegt.
    • Hostname des RSA SecurID Authentication Manager-Servers.
    • Die IP-Adresse des RSA SecurID Authentication Manager-Server.
    • Wenn der RSA SecurID Authentication Manager-Server oder sein Lastausgleichsserver über ein selbstsigniertes Zertifikat verfügt, benötigen Sie das CA-Zertifikat, das im Assistenten "Pod hinzufügen" bereitgestellt werden muss. Das Zertifikat muss im PEM-Format vorliegen (Dateitypen .cer oder.cert oder .pem)

War diese Seite hilfreich?

Feedback zu diesem Thema geben

War dieses Thema hilfreich?

Bitte geben Sie keine personenbezogenen oder vertraulichen Daten an.

Link wird erstellt…