Der AVD Verbindungsaufbau erklärt
Azure Virtual Desktop (AVD) bietet die Möglichkeit Applikationen als RemoteApp oder Desktop Sessions via RDP auf einen in Azure bereitgestellten Session Host zum Benutzer zu bringen. Somit kann der Benutzer seinen Windows Desktop oder auch nur eine Applikation an seinem lokalen Gerät nutzen.
Das folgende Diagramm bietet eine Übersicht über den Verbindungsaufbau zwischen dem Client des Benutzers und dem Session Host.
Verbindung
Azure Virtual Desktop verwendet das Remotedesktopprotokoll (RDP), um die Sessions bereitzustellen und Bild und Eingabe zu übermitteln. RDP wurde mit Windows NT 4.0 Terminal Server Edition veröffentlicht und entwickelte sich mit jedem Release von Microsoft Windows und Windows Server kontinuierlich weiter. Von Anfang an wurde RDP so entwickelt, dass es vom Protokoll unabhängig ist und ermöglicht heute so auch den Einsatz von TCP oder UDP inkl. Erweiterungen.
Die Session wird jedoch nicht mit dem Windows RDP Client hergestellt, sondern bedingt den Einsatz des AVD Clients.
Reverse Verbindungstransport
Azure Virtual Desktop verwendet den Reverse Verbindungstransport zum Einrichten der Remotesession und für den Transport des RDP-Datenverkehrs. Im Gegensatz zu Bereitstellungen der lokalen Remotedesktopdienste verwendet der Reverse Verbindungstransport keinen TCP-Listener, um eingehende RDP-Verbindungen zu empfangen. Stattdessen wird die ausgehende Verbindung mit der Azure Virtual Desktop-Infrastruktur über eine https Verbindung realisiert.
Kommunikationskanal des Session Hosts
Beim Start des Azure Virtual Desktop Session Hosts, richtet der Remote Desktop Agent Loader-Dienst den permanenten Kommunikationskanal des Azure Virtual Desktop-Brokers ein. Dieser Kommunikationskanal überlagert eine sichere TLS-Verbindung (Transport Layer Security) und fungiert als Bus für den Dienstnachrichtenaustausch zwischen Session Host und Azure Virtual Desktop-Infrastruktur.
Der Verbindungsaufbau im Detail
- Der Azure Virtual Desktop Benutzer abonniert den Azure Virtual Desktop Workspace über den bereitgestellten Feed Dienst.
- Azure Active Directory authentifiziert den Benutzer und gibt das Token zurück, das es dann dem Client ermöglicht die dem Benutzer zur Verfügung stehenden Ressourcen anzuzeigen.
- Der Client übergibt das Token an den Feed Dienst von Azure Virtual Desktop.
- Der Feed Dienst von Azure Virtual Desktop überprüft das Token.
- Der Feed Dienst von Azure Virtual Desktop übergibt die Liste der verfügbaren Desktops und RemoteApps in Form einer digital signierten Verbindungskonfiguration zurück an den Client.
- Der Client speichert die Verbindungskonfiguration für jede verfügbare Ressource in lokalen RDP-Dateien.
- Wenn ein Benutzer die Ressource zum Verbinden auswählt, verwendet der Client die zugehörige RDP-Datei, stellt die sichere TLS 1.2-Verbindung mit der nächstgelegenen Azure Virtual Desktop-Gateway Instanz her und übergibt die Verbindungsinformationen. Das nächstgelegene Gateway wird über Azure Front Door auf Basis der Geo Lokation des Clients ermittelt.
- Das Azure Virtual Desktop-Gateway überprüft die Anforderung und fordert den Azure Virtual Desktop-Broker auf, die Verbindung zu orchestrieren.
- Der Azure Virtual Desktop-Broker identifiziert den Session Host und verwendet den zuvor eingerichteten permanenten Kommunikationskanal, um die Verbindung zu initialisieren.
- Der RDP Stack initiiert die TLS 1.2-Verbindung mit derselben Azure Virtual Desktop-Gatewayinstanz, die vom Client verwendet wird.
- Nachdem sowohl der Client als auch der Session Host mit dem Gateway verbunden sind, beginnt das Gateway mit der Übermittlung der Rohdaten zwischen beiden Endpunkten. Dadurch wird der grundlegende Reverse Verbindungstransport für RDP festgelegt.
- Nachdem der Basistransport ausgehandelt wurde, startet der Client den RDP-Handshake.
Verbindungssicherheit
TLS 1.2 wird für alle Verbindungen verwendet, die von den Clients und Session Host mit den Komponenten der Azure Virtual Desktop-Infrastruktur initiiert werden.
Azure Virtual Desktop verwendet dasselbe TLS 1.2-Verschlüsselungsverfahren wie Azure Front Door. Es ist wichtig, sicherzustellen, dass sowohl Clientcomputer als auch Session Host diese Verschlüsselungsverfahren verwenden können.
Für den Reverse Verbindungstransport stellen sowohl der Client als auch der Session Host eine Verbindung mit dem Azure Virtual Desktop-Gateway her. Nach dem Einrichten der TCP-Verbindung überprüft der Client oder Session Host das Zertifikat des Azure Virtual Desktop-Gateways.
Nachdem der Basistransport eingerichtet wurde, stellt RDP unter Verwendung der Zertifikate des Session Host eine geschachtelte TLS-Verbindung zwischen Client und Sitzungshost her.
Standardmäßig wird das Zertifikat, das für die RDP-Verschlüsselung verwendet wird, vom Betriebssystem bei der Bereitstellung selbst generiert. Bei Bedarf können Kunden zentral verwaltete Zertifikate bereitstellen, die von der Unternehmenszertifizierungsstelle ausgestellt werden.