Diese Seite ist eine Referenz für alle möglichen Ports und Protokolle, die für die Kommunikation innerhalb einer typischen First-Gen-Horizon Cloud Service on Microsoft Azure-Bereitstellung verwendet werden. Verwenden Sie diese Tabellen, um sicherzustellen, dass Ihre Netzwerkkonfiguration und Firewalls den Kommunikationsdatenverkehr zulassen, der für eine erfolgreiche Pod-Bereitstellung und den täglichen Betrieb erforderlich ist.
Über diese Seite
Die für Ihre spezielle Bereitstellung erforderlichen Ports und Protokolle hängen teilweise davon ab, welche Funktionen Sie für Ihre Horizon Cloud Service on Microsoft Azure-Bereitstellung auswählen. Wenn Sie eine bestimmte Komponente oder ein bestimmtes Protokoll nicht verwenden möchten, ist der erforderliche Kommunikationsdatenverkehr für Ihre Zwecke nicht erforderlich, und Sie können die mit dieser Komponente verknüpften Ports ignorieren. Beispiel: Wenn Ihre Endbenutzer nur das Blast Extreme-Anzeigeprotokoll verwenden, ist das Zulassen der PCoIP-Ports keine Voraussetzung.
Der Netzwerkdatenverkehr muss bestimmte Hostnamen erreichen. Wenn die Bereitstellung so konfiguriert ist, dass ein Proxy verwendet wird, wird erwartet, dass einige Netzwerkdienste den Proxy verwenden und andere Netzwerkdienste den direkten Weg nehmen. Weitere Informationen zum Netzwerkdatenverkehr zu Hostnamen finden Sie unter First-Gen-Mandanten – Horizon Cloud on Microsoft Azure-Bereitstellungen – Anforderungen an die Auflösung von Hostnamen, DNS-Namen.
Informationen über andere Ports, die für VMware-Produkte unterstützt werden, finden Sie unter VMware Ports and Protocols.
Im Rahmen des Pod-Bereitstellungsvorgangs erstellt der Bereitsteller Netzwerksicherheitsgruppen (NSGs) auf den Netzwerkkarten (NICs) auf allen bereitgestellten VMs. Weitere Informationen zu den in diesen NSGs definierten Regeln finden Sie unter Standardregeln für Netzwerksicherheitsgruppen für die VMs in einem Horizon Cloud-Pod.
Ports und Protokolle, die von Schlüssel-Pod-Komponenten für laufende Vorgänge benötigt werden
Zusätzlich zu den DNS-Anforderungen werden die in den folgenden Tabellen aufgeführten Ports und Protokolle benötigt, damit der Pod nach der Bereitstellung im laufenden Betrieb ordnungsgemäß funktioniert. Einige dieser Tabellen enthalten außerdem Ports und Protokolle, die für bestimmte Szenarien oder bei Aktivierung bestimmter Funktionen auf dem Pod erforderlich sind.
Im Microsoft Azure-Portal verfügen die Pod-Manager-VMs über Namen, die eine Komponente wie vmw-hcs- podID enthalten, wobei podID die UUID des Pods ist, sowie eine node-Komponente.
Die Verwendung eines Microsoft Azure-Lastausgleichsdiensts mit Pod-Manager-VMs durch das System startete mit der Dienstversion vom September 2019 ab Manifest 1600. Daher verfügen alle Pods, die ab Manifest 1600 neu bereitgestellt werden, über einen Microsoft Azure-Pod-Lastausgleichsdienst. Pods, die zuerst vor dem Manifest 1600 bereitgestellt und anschließend auf spätere Manifeste aktualisiert wurden, verfügen auch über einen Microsoft Azure-Pod-Lastausgleichsdienst. Die Tabellenzeilen, in denen der Lastausgleichsdienst des Pods erwähnt wird, gelten für alle diese Pods.
| Quelle | Ziel | Ports | Protokoll | Zweck |
|---|---|---|---|---|
| Pod-Manager-VM | Andere Pod-Manager-VM des Pods | 4101 | TCP | Dieser Datenverkehr ist JMS-Routing zwischen den Pod-Manager-VMs. |
| Pod-Manager-VM | Unified Access Gateway-VMs | 9443 | HTTPS | Dieser Port wird von der Pod Manager-VM über das Verwaltungssubnetz verwendet, um die Einstellungen in der Unified Access Gateway-Konfiguration des Pods zu konfigurieren. Diese Portanforderung gilt, wenn Sie einen Pod anfänglich mit einer Unified Access Gateway-Konfiguration bereitstellen und wenn Sie einen Pod dahingehend bearbeiten, dass Sie eine Unified Access Gateway-Konfiguration hinzufügen oder Einstellungen für diese Unified Access Gateway-Konfiguration aktualisieren. |
| Microsoft Azure-Pod-Lastausgleich | Pod-Manager-VM | 8080 | HTTP | Integritätsprüfungen der VMs im Back-End-Pool des Lastausgleichs. Bei vor Version v2204 bereitgestellten Pods ohne festgelegte Hochverfügbarkeitsoption und ohne hinzugefügte Hochverfügbarkeit weist der Lastausgleichsdienst eine Pod-Manager-VM auf, deren Back-End-Pool überprüft werden muss. |
| Pod-Manager-VM | Domänencontroller | 389 | TCP UDP |
Die Registrierung Ihres Horizon Cloud-Mandanten bei einem Active Directory ist Voraussetzung. Der Workflow „AD-Domäne registrieren“ der Konsole muss nach dem Onboarding Ihres ersten Pods ausgeführt werden. Dieser Port ist für LDAP-Dienste erforderlich, wenn LDAP in diesem Workflow angegeben wird. LDAP ist die Standardeinstellung für die meisten Mandanten. Ziel ist der Server, der eine Domänencontrollerrolle in der Active Directory-Konfiguration enthält. |
| Pod-Manager-VM | Globaler Katalog | 3268 | TCP | Die Registrierung Ihres Horizon Cloud-Mandanten bei einem Active Directory ist Voraussetzung. Der Workflow „AD-Domäne registrieren“ der Konsole muss nach dem Onboarding Ihres ersten Pods ausgeführt werden. Dieser Port ist für LDAP-Dienste erforderlich, wenn LDAP das angegebene Protokoll in diesem Workflow ist. LDAP ist die Standardeinstellung für die meisten Mandanten. Ziel ist der Server, der die globale Katalogrolle in der Active Directory-Konfiguration enthält. |
| Pod-Manager-VM | Domänencontroller | 88 | TCP UDP |
Kerberos Dienstleistungen. Ziel ist der Server, der eine Domänencontrollerrolle in einer Active Directory-Konfiguration enthält. Die Registrierung des Pods bei einem Active Directory ist Voraussetzung. |
| Pod-Manager-VM | Domänencontroller | 636, 3269 | TCP | Die Registrierung Ihres Horizon Cloud-Mandanten bei einem Active Directory ist Voraussetzung. Der Workflow „AD-Domäne registrieren“ der Konsole muss nach dem Onboarding Ihres ersten Pods ausgeführt werden. Diese Ports sind für LDAP über SSL (LDAPS)-Dienste nur dann erforderlich, wenn LDAPS als Protokoll in der Konfiguration für dieses registrierte AD angegeben wird. LDAPS kann nur für das registrierte AD angegeben werden, wenn Ihr Mandant für die Verwendung der LDAPS-Funktion des Diensts aktiviert ist. Andernfalls ist LDAP standardmäßig die Anforderung. |
| Pod-Manager-VM | DNS-Server | 53 | TCP UDP |
DNS-Dienste |
| Pod-Manager-VM | NTP-Server | 123 | UDP | NTP-Dienste. Server, der die NTP-Zeitsynchronisierung ermöglicht. |
| Pod-Manager-VM | Echter True SSO-Registrierungsserver | 32111 | TCP | Echter True SSO-Registrierungsserver. Erforderlich, wenn Sie True SSO mit Ihren Horizon-Pods verwenden. 32111 ist der Standardport, der bei der Installation des Registrierungsservers verwendet wird. Diese Portnummer kann während des Registrierungsserver-Installationsvorgangs gemäß Ihren Anforderungen konfiguriert werden. Weitere Informationen finden Sie auch im Abschnitt SSO- und Zertifikatsverwaltung und Horizon Cloud on Microsoft Azure-Bereitstellungen in diesem Thema. |
| Pod-Manager-VM | Workspace ONE Access-Dienst | 443 | HTTPS |
Hinweis: Diese Zeile gilt für Umgebungen, in denen Einzel-Pod-Brokering konfiguriert ist. Diese Informationen gelten nicht für Umgebungen mit einer Universal Broker-Konfiguration. In einer Umgebung, in der Einzel-Pod-Brokering konfiguriert ist, kommuniziert der
Workspace ONE Access Connector mit einem Pod, um die Endbenutzerberechtigungen (die Zuweisungen) zu erhalten.
Optional, wenn Sie Workspace ONE Access nicht mit dem Pod integrieren. In einer Umgebung, in der Einzel-Pod-Brokering konfiguriert ist, wird diese Verbindung verwendet, um eine Vertrauensbeziehung zwischen dem Pod und dem Workspace ONE Access-Dienst herzustellen, mit der der Workspace ONE Access Connector mit dem Pod synchronisiert wird. Stellen Sie sicher, dass der Pod die von Ihnen verwendete Workspace ONE Access-Umgebung über Port 443 erreichen kann. Wenn Sie den Workspace ONE Access-Clouddienst verwenden, informieren Sie sich auch im VMware Knowledge Base-Artikel 2149884 in der Liste der Workspace ONE Access-Dienst-IP-Adressen, auf die der Workspace ONE Access Connector und der Pod Zugriff haben müssen. |
Ports und Protokollanforderungen für Connector-VMs des Gateways
Diese Tabelle gilt für die Connector-VM des Gateways, die verwendet wird, wenn Sie das externe Gateway in einem separaten VNet bereitgestellt haben. Zusätzlich zu den DNS-Anforderungen werden die Ports und Protokolle in der folgenden Tabelle benötigt, damit das externe Gateway für den laufenden Betrieb nach der Bereitstellung ordnungsgemäß funktioniert.
In der folgenden Tabelle bezieht sich der Begriff „Connector-VM“ auf die Connector-VM des Gateways, die die Verbindung zwischen der Cloud-Verwaltungsebene und dem externen Gateway verwaltet. Im Microsoft Azure-Portal verfügt diese VM über einen Namen, der einen Teil wie vmw-hcs-ID enthält (wobei ID die ID des Gateway-Bereitstellers ist), sowie einen node-Teil.
| Quelle | Ziel | Ports | Protokoll | Zweck |
|---|---|---|---|---|
| Connector-VM | DNS-Server | 53 | TCP UDP |
DNS-Dienste |
| Connector-VM | NTP-Server | 123 | UDP | NTP-Dienste. Server, der die NTP-Zeitsynchronisierung ermöglicht. |
VM-Ports und Protokollanforderungen für Unified Access Gateway
Zusätzlich zum DNS und den oben genannten primären Ports und Protokollanforderungen beziehen sich die Ports und Protokolle in den folgenden Tabellen auf die Gateways, die Sie auf dem Pod konfiguriert haben, um den ordnungsgemäßen Betrieb bei laufenden Prozessen nach der Bereitstellung zu gewährleisten.
Für Verbindungen über einen Pod mit aktivierter Hochverfügbarkeit, der mit Unified Access Gateway-Instanzen konfiguriert ist, muss der Datenverkehr von den Unified Access Gateway-Instanzen des Pods zu den Zielen wie in der folgenden Tabelle aufgeführt zugelassen werden. Während der Pod-Bereitstellung wird in Ihrer Microsoft Azure-Umgebung eine Netzwerksicherheitsgruppe (NSG) erstellt, die von der Unified Access Gateway-Instanzen des Pods verwendet wird.
| Quelle | Ziel | Port | Protokoll | Zweck |
|---|---|---|---|---|
| Unified Access Gateway | Microsoft Azure-Pod-Lastausgleich | 8443 | TCP | Traffic zur Anmelde-Authentifizierung. Der Datenverkehr von den Unified Access Gateway-Instanzen erreicht die Pod-Manager-VM über den Lastausgleichsdienst des Pods. |
| Unified Access Gateway | NTP-Server | 123 | UDP | NTP-Dienste. Server, der die NTP-Zeitsynchronisierung ermöglicht. Wenn Ihr Mandant für die Verwendung von Universal Broker konfiguriert ist, stellen Sie sicher, dass folgende Voraussetzungen erfüllt sind:
Wenn der Dienst folglich eine Zeitabweichung zwischen den Unified Access Gateway-Appliances und dem NTP-Server des Universal Broker erkennt, auf dem UTC (Coordinated Universal Time) ausgeführt wird, werden Sie per E-Mail aufgefordert, die Zeitabweichung zu beheben. Zeitabweichungen zwischen Universal Broker und den Unified Access Gateway-Appliances können zu fehlerhaften Endbenutzerverbindungen führen. Wenn die Konfigurationen des internen Unified Access Gateway nicht mit einem NTP-Server aus dem Mandantensubnetz verbunden sind, treten solche Zeitabweichungen eher auf, da sich diese Unified Access Gateway-Appliances ohne einen NTP-Server nach der Uhrzeit der zugrundeliegenden VM richten. Wenn es sich bei dem zu verwendenden NTP-Server um einen internen NTP-Server handelt und Kommunikation über die DMZ-Schnittstelle nicht zulässig ist, reichen Sie eine Support-Anfrage ein, damit das VMware Horizon Cloud Service-Team im Anschluss an die Bereitstellung Routen zur Unified Access Gateway-Konfiguration hinzufügen und somit Kommunikation zwischen dem Unified Access Gateway und dem NTP-Server ermöglichen kann. Das VMware Horizon Cloud Service-Team verfügt über API-Aufrufe, um die Routen hinzuzufügen.
Tipp: Wenn Ihr Mandant für die Verwendung von Einzel-Pod-Brokering konfiguriert ist, werden die oben genannten Voraussetzungen als Best Practices betrachtet, da in einem Szenario mit einem einzelnen Pod-Broker die Zeitabweichung mit den Unified Access Gateway-Appliances keine Auswirkungen auf die Endbenutzerverbindungen hat.
|
| Unified Access Gateway | Horizon Agent in den Desktop- oder Farm-RDSH-VMs | 4172 | TCP UDP |
PCoIP |
| Unified Access Gateway | Horizon Agent in den Desktop- oder Farm-RDSH-VMs | 22443 | TCP UDP |
Blast Extreme Bei der Verwendung von Blast Extreme wird standardmäßig der CDR-Verkehr (Client Drive Redirection) und der USB-Verkehr über diesen Port geleitet. Wenn Sie es vorziehen, kann der CDR-Verkehr auf den TCP 9427-Port und der USB-Umleitungsverkehr auf den TCP 32111-Port aufgeteilt werden. |
| Unified Access Gateway | Horizon Agent in den Desktop- oder Farm-RDSH-VMs | 9427 | TCP | Optional für Clientlaufwerksumleitung (CDR) und Multimedia-Umleitung (MMR) Verkehr. |
| Unified Access Gateway | Horizon Agent in den Desktop- oder Farm-RDSH-VMs | 32111 | TCP | Optional für USB-Umleitungsverkehr. |
| Unified Access Gateway | Ihre RADIUS-Instanz | 1812 | UDP | Wenn Sie mit dieser Unified Access Gateway-Konfiguration die RADIUS-Zwei-Faktor-Authentifizierung verwenden. Der Standardwert für RADIUS wird hier angezeigt. |
| Unified Access Gateway | Ihr RSA SecurID Authentication Manager-Server | 5555 | TCP | Bei Verwendung der RSA SecurID-Zwei-Faktor-Authentifizierung mit dieser Unified Access Gateway-Konfiguration. Hier wird der Standardwert angezeigt, der für den Kommunikationsport für RSA SecurID-Authentifizierungs-API-Agents für die Agent-Authentifizierung verwendet wird. |
Für Universal Broker erforderliche Ports und Protokolle
Um die Verwendung von Universal Broker für das Brokering von Endbenutzerzuweisungen von einem Pod zu unterstützen, müssen Sie Port 443 wie in der folgenden Tabelle beschrieben konfigurieren. Der aktive Pod-Manager stellt eine persistente WebSocket-Verbindung mit dem Universal Broker-Dienst über Port 443 her und empfängt Verbindungsanforderungen vom Universal Broker-Dienst über einen zufällig ausgewählten Port.
| Quelle | Quellport | Ziel | Zielport | Protokoll | Zweck |
|---|---|---|---|---|---|
| Aktiver Pod-Manager | Zufällig aus verfügbaren Ports ausgewählt | Universal Broker-Dienst | 443 | Anfangs HTTPS, dann WebSocket | Stellt eine persistente WebSocket-Verbindung mit dem Universal Broker-Dienst her |
Port- und Protokollanforderungen für Datenverkehr über Endbenutzerverbindungen
Um von ihren Geräten aus eine Verbindung zu den vom Pod bereitgestellten virtuellen Desktops und Remoteanwendungen herzustellen, verwenden Ihre Endbenutzer einen kompatiblen installierten VMware Horizon Client oder ihren Browser (bekannt als Horizon HTML Access-Client). Die Ports, die für den Datenverkehr von den Clients der Endbenutzer geöffnet werden müssen, um die von den Pods bereitgestellten virtuellen Desktops und Remoteanwendungen zu erreichen, hängen von der Wahl ab, die Sie für die Verbindung Ihrer Endbenutzer treffen:
- Bei Auswahl der Bereitstelleroption für die Verwendung einer Konfiguration mit externem Gateway im eigenen VNet des Pods
-
Der Bereitsteller stellt
Unified Access Gateway-Instanzen in Ihrer Microsoft Azure-Umgebung zusammen mit einer
Microsoft Azure-Lastausgleichsressource für diese Instanzen im Backend-Pool dieses Lastausgleichsdiensts bereit. Dieser Lastausgleich kommuniziert mit den Netzwerkkarten dieser Instanzen im DMZ-Subnetz und ist als
öffentlicher Lastausgleich in Microsoft Azure konfiguriert.
Das Diagramm Abbildung der Horizon-Cloud-Pod-Architektur, bei der der Pod sowohl über externe als auch über interne Gateway-Konfigurationen verfügt, wobei das externe Gateways in demselben VNet bereitgestellt wird wie der Pod, drei Netzwerkkarten auf den externen Gateway-VMs, zwei Netzwerkkarten auf den internen Gateway-VMs und eine öffentliche IP-Adresse, die für den Lastausgleichsdienst des externen Gateways aktiviert ist zeigt die Position dieses öffentlichen Lastausgleichs und der Unified Access Gateway-Instanzen. Wenn Ihr Pod über diese Konfiguration verfügt, wird der Datenverkehr von Ihren Endbenutzern im Internet an diesen Lastausgleich geleitet, der die Anforderungen an die Unified Access Gateway-Instanzen verteilt. Bei dieser Konfiguration müssen Sie sicherstellen, dass diese Endbenutzerverbindungen diesen Lastausgleich über die unten aufgeführten Ports und Protokolle erreichen können. Nach der Bereitstellung befindet sich der Lastausgleichsdienst des externen Gateways in der Ressourcengruppe mit dem Namen
vmw-hcs-podID-uag, wobei podID die UUID des Pods ist. - Bei Auswahl der Bereitstelleroption für die Verwendung einer internen Unified Access Gateway-Konfiguration
-
Eine Konfiguration mit internem Gateway wird standardmäßig im eigenen VNet des Pods bereitgestellt. Der Bereitsteller stellt
Unified Access Gateway-Instanzen in Ihrer Microsoft Azure-Umgebung zusammen mit einer
Microsoft Azure-Lastausgleichsressource für diese Instanzen in deren Backend-Pool bereit. Dieser Lastausgleich kommuniziert mit den Netzwerkkarten dieser Instanzen im Mandanten-Subnetz und ist als
interner Lastausgleich in Microsoft Azure konfiguriert.
Das Diagramm Abbildung der Horizon-Cloud-Pod-Architektur, bei der der Pod sowohl über externe als auch über interne Gateway-Konfigurationen verfügt, wobei das externe Gateways in demselben VNet bereitgestellt wird wie der Pod, drei Netzwerkkarten auf den externen Gateway-VMs, zwei Netzwerkkarten auf den internen Gateway-VMs und eine öffentliche IP-Adresse, die für den Lastausgleichsdienst des externen Gateways aktiviert ist zeigt die Position dieses internen Lastausgleichs und der Unified Access Gateway-Instanzen. Wenn Ihr Pod über diese Konfiguration verfügt, wird der Datenverkehr von Ihren Endbenutzern in Ihrem Unternehmensnetzwerk an diesen Lastausgleich geleitet, der die Anforderungen an die Unified Access Gateway-Instanzen verteilt. Bei dieser Konfiguration müssen Sie sicherstellen, dass diese Endbenutzerverbindungen diesen Lastausgleich über die unten aufgeführten Ports und Protokolle erreichen können. Nach der Bereitstellung befindet sich der Lastausgleichsdienst des internen Gateways in der Ressourcengruppe mit dem Namen
vmw-hcs-podID-uag-internal, wobei podID die UUID des Pods ist. - Bei Auswahl der Bereitstelleroption entweder für eine Konfiguration mit externem Gateway im eigenen VNet statt im VNet der Pods oder für die Verwendung des eigenen Abonnements (wobei es sich um einen Sonderfall der Verwendung des eigenen VNet handelt, das VNets keine Abonnements umfassen)
-
Der Bereitsteller stellt
Unified Access Gateway-Instanzen in Ihrer Microsoft Azure-Umgebung zusammen mit einer
Microsoft Azure-Lastausgleichsressource für diese Instanzen im Backend-Pool dieses Lastausgleichsdiensts bereit. Dieser Lastausgleich kommuniziert mit den Netzwerkkarten dieser Instanzen im DMZ-Subnetz und ist als
öffentlicher Lastausgleich in Microsoft Azure konfiguriert.
Das Diagramm Veranschaulichung der Elemente der Architektur des externen Gateways, wenn das externe Gateway in einem eigenen, vom VNet des Pods getrennten VNet bereitgestellt wird zeigt den Standort dieses öffentlichen Lastausgleichsdiensts und der Unified Access Gateway-Instanzen im eigenen VNet des Gateways. Wenn Ihr Pod über diese Konfiguration verfügt, wird der Datenverkehr von Ihren Endbenutzern im Internet an diesen Lastausgleich geleitet, der die Anforderungen an die Unified Access Gateway-Instanzen verteilt. Bei dieser Konfiguration müssen Sie sicherstellen, dass diese Endbenutzerverbindungen diesen Lastausgleich über die unten aufgeführten Ports und Protokolle erreichen können. Nach der Bereitstellung befindet sich der Lastausgleichsdienst des externen Gateways in der Ressourcengruppe mit dem Namen
vmw-hcs-ID-uag, wobei ID der Wert ist, der im Feld Bereitsteller-ID auf der Detailseite des Pods angezeigt wird. Wie im Administratorhandbuch beschrieben, gelangen Sie über die Seite „Kapazität“ der Konsole zur Detailseite des Pods. - Wenn auf dem Pod keine Unified Access Gateway-Konfigurationen vorhanden sind
-
Hinweis: Für Produktionsumgebungen, in denen der Mandant für die Verwendung von Einzel-Pod-Brokering konfiguriert ist, empfiehlt es sich, für interne Endbenutzerverbindungen eine interne Unified Access Gateway-Gateway-Konfiguration auf dem Pod zu verwenden. Diese Verbindungen gehen im Einzel-Pod-Brokering-Szenario zu dieser Gateway-Konfiguration über.In einer Konfiguration mit Einzel-Pod-Brokering, in der Workspace ONE Access mit dem Pod integriert ist, müssen sich Ihre Endbenutzer in der Regel über Workspace ONE Access verbinden. In diesem Szenario müssen Sie Workspace ONE Access konfigurieren und der Workspace ONE Access Connector muss direkt auf den Pod verweisen. Ihre Endbenutzer stellen mithilfe von Workspace ONE Access eine Verbindung zu ihren vom Pod bereitgestellten Ressourcen her. Für diese Konfiguration laden Sie ein SSL-Zertifikat von der Übersichtsseite des Pods in der Konsole auf die Pod-Manager-VMs hoch, wie im Administratorhandbuch für VMware Horizon Cloud Service beschrieben. Anschließend führen Sie die Schritte zur Integration von Workspace ONE Access in den Pod aus.
| Quelle | Ziel | Port | Protokoll | Zweck |
|---|---|---|---|---|
| Horizon Client | Microsoft Azure-Lastausgleich für diese Unified Access Gateway-Instanzen | 443 | TCP | Traffic zur Anmelde-Authentifizierung. Kann auch Clientlaufwerksumleitung (CDR), Multimedia-Umleitung (MMR), USB-Umleitung und getunnelten RDP-Traffic übertragen. SSL (HTTPS-Zugang) ist standardmäßig für Clientverbindungen aktiviert. Port 80 (HTTP-Zugriff) kann in einigen Fällen verwendet werden. |
| Horizon Client | Microsoft Azure-Lastausgleich für diese Unified Access Gateway-Instanzen | 4172 | TCP UDP |
PCoIP über PCoIP Secure Gateway auf Unified Access Gateway |
| Horizon Client | Microsoft Azure-Lastausgleich für diese Unified Access Gateway-Instanzen | 8443 oder 443, je nachdem, was in Ihrer Bereitstellung festgelegt ist | TCP | Blast Extreme über Blast Secure Gateway auf Unified Access Gateway für den Datenverkehr von als Horizon Client. Bei einem Horizon Cloud-Pod wird dieser Port über das Menü Blast Extreme TCP-Port im Bereitstellungsassistenten ausgewählt. Stellen Sie sicher, dass Ihr Netzwerk den Clients den ausgehenden Zugriff auf den von Ihnen für das externe Gateway angegebenen ermöglicht. Diese URL wird von den Clients verwendet, um die Horizon Blast-Sitzung mit den Unified Access Gateway-Instanzen über den Lastausgleichsdienst einzurichten, der sich vor diesen Instanzen befindet. Ab der Dienstversion vom Oktober 2021 bietet der Bereitsteller für neue Bereitstellungen einer Gateway-Konfiguration die Möglichkeit, entweder 8443 oder 443 für den Blast Extreme-TCP-Port auszuwählen, den der Bereitsteller in der entsprechenden Unified Access Gateway-Konfiguration konfiguriert. Zuvor konfigurierte der Bereitsteller standardmäßig 443, ohne eine Wahlmöglichkeit zu bieten. Wenn Ihre Gateway-Konfiguration vor dem Datum der Dienstversion vom Oktober 2021 bereitgestellt wurde, ist in der Konfiguration in der Unified Access Gateway-Verwaltungseinstellung normalerweise der Port 443 im Feld Externe Blast-URL festgelegt.
Hinweis: Port 8443 wird bevorzugt, da er effizienter ist, eine bessere Leistung bietet und weniger Ressourcen auf den
Unified Access Gateway-Instanzen verwendet. Port 443 ist weniger effizient und weniger leistungsfähig. Die Verwendung von Port 443 führt zu einer Überlastung der CPU in den Instanzen. Port 443 würde in Ihrer Bereitstellung nur dann verwendet werden, wenn Ihre Organisation clientseitige Beschränkungen festgelegt hat, z. B. wenn Ihre Organisation nur 443 für ausgehende Verbindungen zulässt und nicht 8443.
|
| Horizon Client | Microsoft Azure-Lastausgleich für diese Unified Access Gateway-Instanzen | 443 | UDP | Blast Extreme über das Unified Access Gateway für den Datenverkehr. |
| Horizon Client | Microsoft Azure-Lastausgleich für diese Unified Access Gateway-Instanzen | 8443 | UDP | Blast Extreme über Blast Secure Gateway auf Unified Access Gateway für den Datenverkehr (adaptiver Datenverkehr). |
| Browser | Microsoft Azure-Lastausgleich für diese Unified Access Gateway-Instanzen | 443 | TCP | Traffic zur Anmelde-Authentifizierung. Kann auch Clientlaufwerksumleitung (CDR), Multimedia-Umleitung (MMR), USB-Umleitung und getunnelten RDP-Traffic übertragen. SSL (HTTPS-Zugang) ist standardmäßig für Clientverbindungen aktiviert. Port 80 (HTTP-Zugriff) kann in einigen Fällen verwendet werden. |
| Browser | Microsoft Azure-Lastausgleich für diese Unified Access Gateway-Instanzen | 8443 oder 443, je nachdem, was in Ihrer Bereitstellung festgelegt wurde | TCP | Blast Extreme über Blast Secure Gateway auf Unified Access Gateway für den Datenverkehr vom Horizon HTML Access-Client (Webclient). Bei einem Horizon Cloud-Pod wird dieser Port über das Menü Blast Extreme TCP-Port im Bereitstellungsassistenten ausgewählt. Stellen Sie sicher, dass Ihr Netzwerk den Clients den ausgehenden Zugriff auf den von Ihnen für das externe Gateway angegebenen ermöglicht. Diese URL wird vom Horizon HTML Access-Client im Browser verwendet, um die Horizon Blast-Sitzung für die Unified Access Gateway-Instanzen über den Lastausgleichsdienst einzurichten, der sich vor diesen Instanzen befindet. Ab der Dienstversion vom Oktober 2021 bietet der Bereitsteller für neue Bereitstellungen einer Gateway-Konfiguration die Möglichkeit, entweder 8443 oder 443 für den Blast Extreme-TCP-Port auszuwählen, den der Bereitsteller in der entsprechenden Unified Access Gateway-Konfiguration konfiguriert. Zuvor konfigurierte der Bereitsteller standardmäßig 443, ohne eine Wahlmöglichkeit zu bieten. Wenn Ihre Gateway-Konfiguration vor dem Datum der Dienstversion vom Oktober 2021 bereitgestellt wurde, ist in der Konfiguration in der Unified Access Gateway-Verwaltungseinstellung normalerweise der Port 443 im Feld Externe Blast-URL festgelegt.
Hinweis: Port 8443 wird bevorzugt, da er effizienter ist, eine bessere Leistung bietet und weniger Ressourcen auf den
Unified Access Gateway-Instanzen verwendet. Port 443 ist weniger effizient und weniger leistungsfähig. Die Verwendung von Port 443 führt zu einer Überlastung der CPU in den Instanzen. Port 443 würde in Ihrer Bereitstellung nur dann verwendet werden, wenn Ihre Organisation clientseitige Beschränkungen festgelegt hat, z. B. wenn Ihre Organisation nur 443 für ausgehende Verbindungen zulässt und nicht 8443.
|
| Quelle | Ziel | Port | Protokoll | Zweck |
|---|---|---|---|---|
| Horizon Client | Microsoft Azure-Lastausgleich für diese Unified Access Gateway-Instanzen | 443 | TCP | Traffic zur Anmelde-Authentifizierung. Kann auch Clientlaufwerksumleitung (CDR), Multimedia-Umleitung (MMR), USB-Umleitung und getunnelten RDP-Traffic übertragen. SSL (HTTPS-Zugang) ist standardmäßig für Clientverbindungen aktiviert. Port 80 (HTTP-Zugriff) kann in einigen Fällen verwendet werden. Weitere Informationen finden Sie unter dem Thema zum Verständnis der URL-Inhaltsumleitung im Administratorhandbuch für VMware Horizon Cloud Service. |
| Horizon Client | Microsoft Azure-Lastausgleich für diese Unified Access Gateway-Instanzen | 4172 | TCP UDP |
PCoIP über PCoIP Secure Gateway auf Unified Access Gateway |
| Horizon Client | Microsoft Azure-Lastausgleich für diese Unified Access Gateway-Instanzen | 8443 oder 443, je nachdem, was in Ihrer Bereitstellung festgelegt wurde | TCP | Blast Extreme über Blast Secure Gateway auf Unified Access Gateway für den Datenverkehr von als Horizon Client. Bei einem Horizon Cloud-Pod wird dieser Port über das Menü Blast Extreme TCP-Port im Bereitstellungsassistenten ausgewählt. Stellen Sie sicher, dass Ihr Netzwerk den Clients den ausgehenden Zugriff auf den von Ihnen für das externe Gateway angegebenen ermöglicht. Diese URL wird von den Clients verwendet, um die Horizon Blast-Sitzung mit den Unified Access Gateway-Instanzen über den Lastausgleichsdienst einzurichten, der sich vor diesen Instanzen befindet. Ab der Dienstversion vom Oktober 2021 bietet der Bereitsteller für neue Bereitstellungen einer Gateway-Konfiguration die Möglichkeit, entweder 8443 oder 443 für den Blast Extreme-TCP-Port auszuwählen, den der Bereitsteller in der entsprechenden Unified Access Gateway-Konfiguration konfiguriert. Zuvor konfigurierte der Bereitsteller standardmäßig 443, ohne eine Wahlmöglichkeit zu bieten. Wenn Ihre Gateway-Konfiguration vor dem Datum der Dienstversion vom Oktober 2021 bereitgestellt wurde, ist in der Konfiguration in der Unified Access Gateway-Verwaltungseinstellung normalerweise der Port 443 im Feld Externe Blast-URL festgelegt.
Hinweis: Port 8443 wird bevorzugt, da er effizienter ist, eine bessere Leistung bietet und weniger Ressourcen auf den
Unified Access Gateway-Instanzen verwendet. Port 443 ist weniger effizient und weniger leistungsfähig. Die Verwendung von Port 443 führt zu einer Überlastung der CPU in den Instanzen. Port 443 würde in Ihrer Bereitstellung nur dann verwendet werden, wenn Ihre Organisation clientseitige Beschränkungen festgelegt hat, z. B. wenn Ihre Organisation nur 443 für ausgehende Verbindungen zulässt und nicht 8443.
|
| Horizon Client | Microsoft Azure-Lastausgleich für diese Unified Access Gateway-Instanzen | 443 | UDP | Blast Extreme über das Unified Access Gateway für den Datenverkehr. |
| Horizon Client | Microsoft Azure-Lastausgleich für diese Unified Access Gateway-Instanzen | 8443 | UDP | Blast Extreme über Blast Secure Gateway auf Unified Access Gateway für den Datenverkehr (adaptiver Datenverkehr). |
| Browser | Microsoft Azure-Lastausgleich für diese Unified Access Gateway-Instanzen | 443 | TCP | Traffic zur Anmelde-Authentifizierung. Kann auch Clientlaufwerksumleitung (CDR), Multimedia-Umleitung (MMR), USB-Umleitung und getunnelten RDP-Traffic übertragen. SSL (HTTPS-Zugang) ist standardmäßig für Clientverbindungen aktiviert. Port 80 (HTTP-Zugriff) kann in einigen Fällen verwendet werden. |
| Browser | Microsoft Azure-Lastausgleich für diese Unified Access Gateway-Instanzen | 8443 oder 443, je nachdem, was in Ihrer Bereitstellung festgelegt wurde | TCP | Blast Extreme über Blast Secure Gateway auf Unified Access Gateway für den Datenverkehr vom Horizon HTML Access-Client (Webclient). Bei einem Horizon Cloud-Pod wird dieser Port über das Menü Blast Extreme TCP-Port im Bereitstellungsassistenten ausgewählt. Stellen Sie sicher, dass Ihr Netzwerk den Clients den ausgehenden Zugriff auf den von Ihnen für das externe Gateway angegebenen ermöglicht. Diese URL wird vom Horizon HTML Access-Client im Browser verwendet, um die Horizon Blast-Sitzung für die Unified Access Gateway-Instanzen über den Lastausgleichsdienst einzurichten, der sich vor diesen Instanzen befindet. Ab der Dienstversion vom Oktober 2021 bietet der Bereitsteller für neue Bereitstellungen einer Gateway-Konfiguration die Möglichkeit, entweder 8443 oder 443 für den Blast Extreme-TCP-Port auszuwählen, den der Bereitsteller in der entsprechenden Unified Access Gateway-Konfiguration konfiguriert. Zuvor konfigurierte der Bereitsteller standardmäßig 443, ohne eine Wahlmöglichkeit zu bieten. Wenn Ihre Gateway-Konfiguration vor dem Datum der Dienstversion vom Oktober 2021 bereitgestellt wurde, ist in der Konfiguration in der Unified Access Gateway-Verwaltungseinstellung normalerweise der Port 443 im Feld Externe Blast-URL festgelegt.
Hinweis: Port 8443 wird bevorzugt, da er effizienter ist, eine bessere Leistung bietet und weniger Ressourcen auf den
Unified Access Gateway-Instanzen verwendet. Port 443 ist weniger effizient und weniger leistungsfähig. Die Verwendung von Port 443 führt zu einer Überlastung der CPU in den Instanzen. Port 443 würde in Ihrer Bereitstellung nur dann verwendet werden, wenn Ihre Organisation clientseitige Beschränkungen festgelegt hat, z. B. wenn Ihre Organisation nur 443 für ausgehende Verbindungen zulässt und nicht 8443.
|
| Quelle | Ziel | Port | Protokoll | Zweck |
|---|---|---|---|---|
| Horizon Client | Microsoft Azure-Pod-Lastausgleich | 443 | TCP | Traffic zur Anmelde-Authentifizierung. Der Datenverkehr von den Clients erreicht die Pod-Manager-VMs über den Lastausgleichsdienst des Pods. |
| Horizon Client | Horizon Agent in den Desktop- oder Farm-RDSH-VMs | 4172 | TCP UDP |
PCoIP |
| Horizon Client | Horizon Agent in den Desktop- oder Farm-RDSH-VMs | 22443 | TCP UDP |
Blast Extreme |
| Horizon Client | Horizon Agent in den Desktop- oder Farm-RDSH-VMs | 32111 | TCP | USB-Umleitung |
| Horizon Client | Horizon Agent in den Desktop- oder Farm-RDSH-VMs | 9427 | TCP | Client-Drive-Umleitung (CDR) und Multimedia-Umleitung (MMR) |
| Browser | Horizon Agent in den Desktop- oder Farm-RDSH-VMs | 443 | TCP | HTML Access |
Anforderungen an Port und Protokolle für den Datenverkehr von in der Basis-VM installierten Agents, in VDI-Desktop-VMs und Farm-RDSH-VMs
Die folgenden Ports müssen den Datenverkehr zwischen der in den Basis-VMs, Desktop-VMs und Farm-RDSH-VMs installierten Agent-bezogenen Software und den Pod-Manager-VMs zulassen.
| Quelle | Ziel | Port | Protokoll | Zweck |
|---|---|---|---|---|
| Horizon Agent in der Basis-Import-VM, in Golden Images, Desktop-VMs, Farm-RDSH-VMs | Pod-Manager-VM | 4001 | TCP | Java Message Service (JMS, Nicht-SSL), der vom Agenten in der VM zur Kommunikation mit dem Pod als Teil der Verifizierung des Zertifikatfingerabdrucks und zum Austausch verwendet wird, um eine SSL-Verbindung mit dem Pod zu sichern. Nachdem die Schlüssel ausgehandelt und zwischen der VM und dem Pod-Manager ausgetauscht wurden, verwendet der Agent Port 4002, um eine gesicherte SSL-Verbindung zu erstellen. Beispielsweise erfordert die Aktion Agentenpaarung zurücksetzen auf der Seite „Importierte VMs“ die Kommunikation über Port 4001 für den Workflow zur Agentenpaarbildung zwischen der Basis-Import-VM und dem Pod.
Hinweis: Die beiden Ports 4001 und 4002 sind für Vorgänge mit einem stabilen Zustand erforderlich. Es gibt Zeiten, in denen der Agent möglicherweise eine erneute Schlüsselerstellung für den Pod benötigt, sodass Port 4001 offen gehalten werden muss.
|
| Horizon Agent in der Basis-Import-VM, die Golden Images, Desktop-VMs, Farm-RDSH-VMs | Pod-Manager-VM | 4002 | TCP | Java Message Service (JMS, SSL), der vom Agenten in diesen VMs verwendet wird, um über eine gesicherte SSL-Verbindung mit dem Pod zu kommunizieren. |
| Horizon Agent in den Desktop-VMs, Farm-RDSH-VMs | VMware Cloud Services-Hostname scapi.vmware.com | 443 | TCP | Wird für das VMware Service Usage Data-Programm verwendet. Vom Mandantensubnetz ausgehender Datenverkehr, der vom Horizon Agent an den VMware Cloud Services-Hostnamen scapi.vmware.com gesendet wird. |
| FlexEngine-Agent (der Agent für VMware Dynamic Environment Manager) auf den Desktop- oder Farm-RDSH-VMs | Die Dateifreigaben, die Sie für die Verwendung durch den FlexEngine-Agent eingerichtet haben, der in Desktop- oder Farm-RDSH-VMs ausgeführt wird | 445 | TCP | FlexEngine-Agent-Zugriff auf Ihre SMB-Dateifreigaben, wenn Sie die VMware Dynamic Environment Manager-Funktionen verwenden. |
Für App Volumes-Funktionen erforderliche Ports und Protokolle
Wie in App Volumes-Anwendungen für Horizon Cloud on Microsoft Azure – Überblick und Voraussetzungen angegeben, müssen Sie, um die Verwendung der App Volumes-Funktionen zu unterstützen, die für die Verwendung mit einem Horizon Cloud-Pod unterstützt werden, Port 445 für den TCP-Protokollverkehr im Mandanten-Subnetz des Pods konfigurieren. Port 445 ist der KMU-Standardport für den Zugriff auf eine KMU-Dateifreigabe unter Microsoft Windows. Die AppStacks werden in einer SMB-Dateifreigabe gespeichert, die sich in derselben Ressourcengruppe wie die Pod-Manager-VMs befindet.
Wie in First-Gen-Mandanten – Horizon Cloud on Microsoft Azure-Bereitstellungen – Anforderungen an die Auflösung von Hostnamen, DNS-Namen beschrieben, weist Azure Cloud bei der Bereitstellung dieser SMB-Dateifreigabe außerdem einen vollqualifizierten Domänennamen (FQDN) nach dem Muster *.file.core.windows.net zu, wobei * der von Azure generierte Name des Speicherkontos der SMB-Dateifreigabe ist. Dieser FQDN muss von Ihrem DNS-Server auflösbar sein, damit App Volumes auf diese Dateifreigaben zugreifen, sie mounten und die AppStacks abrufen kann. Sie müssen sicherstellen, dass Ihr DNS-Server diesen FQDN jederzeit für die App Volumes Manager -Prozesse, die in den Pod-Manager-Instanzen ausgeführt werden, und für den App Volumes Agent, der auf den VDI-Desktops läuft, auflöst.
| Quelle | Ziel | Port | Protokoll | Zweck |
|---|---|---|---|---|
| App Volumes-Agent in der Basis-Import-VM, die Golden Images, Desktop-VMs, Farm-RDSH-VMs | SMB-Dateifreigabe in der Ressourcengruppe des Pod-Managers | 445 | TCP | Im Mandanten-Subnetz des Pods, für den Zugriff auf die App Volumes-AppStacks, die in der SMB-Dateifreigabe gespeichert sind. |
Integration mit Workspace ONE Assist for Horizon – DNS, Ports und Protokollanforderungen
Workspace ONE Assist for Horizon ist ein Produkt aus der Workspace ONE UEM-Produktfamilie. Wenn bestimmte Anforderungen erfüllt sind, können Sie ab der Horizon Cloud-Version vom August 2021 die Verwendung dieses Produkts in VDI-Desktops integrieren, die über die Pods Ihres Horizon Cloud-Mandanten bereitgestellt werden. Vollständige Informationen zu den Anforderungen finden Sie im Handbuch VMware Workspace ONE Assist for Horizon, das sich im Bereich der Dokumentation zu VMware Workspace ONE Assist befindet.
Die Verwendung der Unterstützungsfunktionen erfordert ausgehende Kommunikation zwischen den VDI-Desktop-VMs und dem Workspace ONE Assist-Server, der die Integration mit Ihrem Horizon Cloud-Mandanten unterstützt.
- DNS-Anforderungen
- Stellen Sie sicher, dass der DNS-Name Ihres Workspace ONE Assist-Servers über die Mandantensubnetze des Pods, in denen sich die VDI-Desktop-VMs befinden, auflösbar und erreichbar ist. Im zuvor erwähnten Handbuch VMware Workspace ONE Assist for Horizon werden die DNS-Namen der Workspace ONE Assist-Server bereitgestellt.
- Ports und Protokollanforderungen
- Ausgehender Datenverkehr über Port 443, TCP und HTTPS, muss von den VDI-Desktop-VMs zugelassen werden, auf denen die Workspace ONE Assist for Horizon-Anwendung installiert ist.
Wenn für eine aktive Support-Anfrage erforderlich, temporäre Jumpbox-Ports und ‑Protokolle
Wenn Sie eine Support-Anfrage an VMware stellen und das Supportteam feststellt, dass diese Anfrage durch die Bereitstellung einer temporären Jumpbox-VM für die SSH-Kommunikation mit den von VMware verwalteten Appliances bearbeitet werden kann, benötigt diese Jumpbox die hier beschriebenen Ports und Protokolle.
Für eine supportbezogene Jumpbox-Bereitstellung werden Sie um Erlaubnis gefragt. Das VMware-Supportteam informiert Sie in jeder Support-Situation über die entsprechenden Kommunikationsanforderungen.
Diese supportbezogene Jumpbox-VM ist so konzipiert, dass sie als Quelle mit den folgenden Zielen kommuniziert.
- Port 22 der Pod-Manager-VMs des Pods über SSH und Port 22.
- Port 9443 der Unified Access Gateway-VMs unter Verwendung von HTTPS.
- Der Port 22 der Gateway-Connector-VM über SSH, in einer Bereitstellung, bei der das externe Gateway in seinem eigenen VNet bereitgestellt wird.
Die Art der Support-Anfrage und die in der Bereitstellung verwendeten Appliances bestimmen, welche spezifische(n) von VMware verwaltete(n) Appliance(s) als Ziel für die Kommunikation zugelassen werden müssen.
| Quelle | Ziel | Ports | Protokoll | Zweck |
|---|---|---|---|---|
| Jumpbox-VM |
|
22 | SSH | Wenn der VMware Support diese Kommunikation mit einer oder mehreren der aufgeführten Appliances benötigt, um Ihre Support-Anfrage zu bearbeiten, kommuniziert die Jumpbox-VM über das Management-Subnetz mit Port 22 auf der Ziel-Appliance. |
| Jumpbox-VM | Unified Access Gateway-VMs | 9443 | HTTPS | Wenn der VMware Support diese Kommunikation benötigt, um Ihre Support-Anfrage zu bearbeiten, kommuniziert die Jumpbox-VM über das Management-Subnetz, um Einstellungen in der Unified Access Gateway-Konfiguration vorzunehmen. |
Da diesen VMs dynamisch IP-Adressen zugewiesen werden, können die folgenden Netzwerkregeln die beschriebene Kommunikation bereitstellen. Erkundigen Sie sich während der Support-Anforderungen stets beim VMware Support nach den Anforderungen für die supportbezogene Jumpbox-Bereitstellung.
- Das Management-Subnetz CIDR als Quelle und Ziel, mit Zielport 22, Quellport beliebig und Protokoll TCP.
- Das Management-Subnetz CIDR als Quelle und Ziel, mit Zielport 9443, Quellport beliebig und Protokoll TCP, wenn eine Unified Access Gateway-Konfiguration involviert ist.
SSO- und Zertifikatsverwaltung und Horizon Cloud on Microsoft Azure-Bereitstellungen
Die vom Horizon Cloud-Pod bereitgestellten Desktop-VMs kommunizieren nicht direkt mit dem Registrierungsserver. Die aktive Pod-Manager-VM der Horizon Cloud on Microsoft Azure-Bereitstellung leitet die Zertifikatsanforderungen an den Registrierungsserver weiter. Sobald das Zertifikat erhalten wurde, verwendet der Horizon Agent in den Desktop-VMs dieses Zertifikat, um den Zertifikatsanmeldevorgang im Namen des Desktop-Benutzers durchzuführen.
Die Anfrage/Antwort-Architektur für die Pod Manager-VM einer Horizon Cloud on Microsoft Azure-Bereitstellung ist identisch mit der für den Horizon Connection Server einer Horizon-Bereitstellung. In einer Horizon Cloud on Microsoft Azure-Bereitstellung verfügen die Pod-Manager-VMs über Verbindungen zu den Desktop-VMs im primären VM-Subnetz (auch Mandantensubnetz genannt) und in allen zusätzlichen VM-Subnetzen, die der VDI-Administrator möglicherweise mit dem Workflow „Pod bearbeiten“ hinzugefügt hat.
Zwei Zertifikatsklassen werden von verschiedenen Komponenten validiert: Benutzerzertifikate und Kanalzertifikate. True SSO fügt ein Benutzerzertifikat hinzu, das durch den Authentifizierungsserver validiert wird. In diesem Fall einer Horizon Cloud on Microsoft Azure-Bereitstellung ist der Authentifizierungsserver ein Microsoft Active Directory-Server. Da die Microsoft-Architektur festlegt, welche Portnummern für diese Zertifikatsvalidierung verwendet werden können, kann eine breite Palette von Portnummern für diese Validierung verwendet werden, da die Ports Teil der Microsoft-Architektur selbst sind und nicht spezifisch für die Horizon Cloud on Microsoft Azure-Bereitstellung selbst.
Bei der Verwendung von True SSO in einer Horizon Cloud on Microsoft Azure-Bereitstellung generiert der Horizon Agent eine CSR und sendet sie über den bereits bestehenden Kommunikationskanal zwischen dieser Pod-Manager-VM und dem Horizon Agent an die aktive Pod-Manager-VM der Bereitstellung. Die Pod-Manager-VM leitet die Anforderung über einen sicheren, SSL-verschlüsselten TCP-Kanal (Port 32111 oder der vom Kunden bei der Installation des Registrierungsservers konfigurierte Port) an den Registrierungsserver weiter. Der Registrierungsserver generiert eine CMC-Anforderung, fügt die CSR und den vom Pod-Manager angegebenen Benutzernamen hinzu, signiert die CMC mit dem Zertifikat des Registrierungs-Agents und sendet sie über das MS-DCOM (RPC)-Protokoll an die Zertifizierungsstelle.
Der Horizon Agent empfängt das Zertifikat, serialisiert es als Anmeldedaten und leitet es an den Windows-Anmeldevorgang weiter. Die LSASS-Windows-Komponente empfängt das Zertifikat, validiert es (prüft, ob es gültig und vertrauenswürdig ist und ob die lokale Maschine den privaten Schlüssel für das Zertifikat besitzt) und sendet es dann an einen Domänencontroller (DC). Der DC kann sich dafür entscheiden, die CRL zu prüfen, wie im Benutzerzertifikat angegeben.
Visuell ansprechende Netzwerkdiagramme
Eine übersichtliche Darstellung der Beziehungen zwischen diesen Komponenten, Ports und Protokollen finden Sie in den Netzwerkdiagrammen und Beschreibungen der VMware Digital Workspace Tech Zone unter https://techzone.vmware.com/resource/vmware-horizon-cloud-service-microsoft-azure-network-ports-diagrams.
