Microsoft Windows Server 2008 R2: Zertifikate zur Förderung der RDS-Sicherheit

  • Artikel

Zertifikate spielen eine große Rolle bei der Sicherung von Verbindungen zwischen Remote Desktop Services Hosts und Clients.

Kristin Griffin

Fragen welche Rollen Zertifikate verwenden, ist irgendwie eine Fangfrage. Die wirkliche Antwort ist "alle von ihnen." Es ist wichtig zu verstehen, wo Sie Zertifikate in Remote Desktop Services (RDS) Bereitstellungen verwenden sollten, und warum Sie sie mit jedem bestimmten RDS-Rollendienst verwenden.

Die meisten Rollen, die Sie benötigen, um zu konfigurieren, aber einige von ihnen, die Sie nicht (wie die RD-Lizenzserver). Standardmäßig Sie müssen in jeder Phase der Verbindung mit einer Sitzung SSL (x. 509) Zertifikate oder gehosteten virtuellen Computer (VM). Sie verwenden diese für drei Hauptziele: sichere Kommunikation zwischen Client und Server, um die Identität des Servers oder der Website, die der Client eine Verbindung herstellt und Zeichen zu bestätigen (Remote Desktop Protocol, RDP) Dateien, damit die Benutzer wissen, die RDP-Datei aus einer vertrauenswürdigen Quelle stammt und nicht verändert wurde.

Hier sind einige Beispiele wie RDS Zertifikate verwendet:

  • Remotedesktop-Sitzungshost-Server verwenden Zertifikate, um ihre Identität zu beweisen. Dies ist Server-Authentifizierung bezeichnet.
  • Remotedesktop-Sitzungshost-Server und Remotedesktop-Virtualisierungshost Server verwenden Zertifikate, um eine sichere Verbindung zwischen Client und Server mit TLS 1.0 einzurichten.
  • RD Session Hostserver verwenden Zertifikate für die Clientauthentifizierung erforderlich für Network Level Authentication (NLA), Single Sign-On (SSO) und Web-SSO-Implementierung.
  • Remotedesktop-Sitzungshost-Server und Remotedesktop-Verbindungsbroker beide verwenden ein SSL-Zertifikat zum Signieren RemoteApps und VM RDP-Dateien, versichert der Benutzer, dass sie eine vertrauenswürdige Datei starten sind.
  • RD-Gateway Server verwenden Zertifikate zum Verschlüsseln der Kommunikation mit Clients mithilfe von TLS 1.0.
  • Sie können die Web Access für Remotedesktop-Website mit einem SSL-Zertifikat, um sicherzustellen, dass Menschen sich als vertrauenswürdige Site (HTTPS) zu sichern.

Aktivieren von RDS-Funktionalität stützt sich auf bestimmte Technologien, die Verwendung von Zertifikaten zu unterstützen (siehe Abbildung 1).

Enabling RDS functionality brings into play certain security technologies

Abbildung 1 ermöglicht RDS Funktionen bringt in spielen bestimmte Sicherheitstechnologien.

Sichern des Kanals

TLS ist der Internet Engineering Task Force (IETF) Standard basiert auf SSL Version 3, herausgegeben von Netscape. Einige Verbesserungen TLS sind neue Nachricht Benachrichtigungen, die Fähigkeit zur Kette von Zertifikaten an ein zwischengeschaltetes Certificate Authority (CA) Zertifikat anstelle der Stamm-Zertifizierungsstellenzertifikat und leicht unterschiedliche Verschlüsselungsalgorithmen von SSL.

Obwohl TLS auf SSL basiert, sind die beiden nicht kompatibel. TLS kann jedoch einen Mechanismus implementieren, durch den es zu SSL Version 3 bei Bedarf zurückgreifen kann. Um einen sicheren Kommunikationskanal zwischen einem Client und einem Server mithilfe von TLS einzurichten, die Client und Server gehen durch einen Prozess der messaging, Reaktion und Verschlüsselung (siehe Abbildung 2).

The two-way encryption process for establishing a secure channel.

Abbildung 2 die bidirektionale Verschlüsselungsprozess für die Einrichtung eines sicheren Kanals.

Es gibt zwei Anforderungen für diesen Vorgang, um richtig zu arbeiten.

  • Der Client muss der Zertifizierungsstelle vertrauen, die der Server SSL-Zertifikat signiert.
  • Die Verbindung zwischen Server und Client muss auf hoher Ebene verwenden (standardmäßig) oder Federal Information Processing Standard (FIPS)-Verschlüsselung. Low-Level-Verschlüsselung verschlüsselt nur den Datenverkehr vom Client an den Server, nicht auf Server, Client, so dass es kein sicherer Weg zum Sicherheitsfunktionen oder gemeinsame geheime Schlüssel senden.

Wenn die Verbindung und Verschlüsselung auf diese beiden Anforderungen erfüllt, herstellen dem Client und dem Server Kommunikation wie folgt:

  1. Der Client sendet eine Hello-Nachricht zusammen mit einem Zufallswert fester Länge. Der Server antwortet mit einem Zufallswert fester Länge. Während dieses Austauschs ist teilt dem Client mit dem Server die Komprimierungsmethoden, Chiffren und Hashes, die es unterstützt. Es sendet auch die Protokollversion und eine Sitzungs-ID an den Server. Die Sitzungs-ID identifiziert die Communi­kation-Kanal — Dies ist nicht die Sitzungs-ID auf einem Host für Remotedesktopsitzungen-Server.
  2. Der Server nimmt die höchsten Verschlüsselungsmethode, die beide unterstützen und eine Chiffre und Hash-Funktion aus der Liste des Clients. Dann es der Client sagt welche man sie Cho hat­Sen. Wenn es ist ein Mindestniveau festlegen für den Server und der Client kann nicht dieses Mindestmaß erfüllen, schlägt die Verbindung fehl.
  3. Der Server sendet ein digitale Zertifikat an den Client. Diese Bescheinigung enthält den Namen des Servers, der vertrauenswürdigen Zertifizierungsstelle, die das Zertifikat und den öffentlichen Schlüssel des Servers signiert.
  4. Der Client überprüft, ob das Zertifikat gültig und vertrauenswürdig ist. Das Server-Zertifikat Signieren verwendete Zertifikat wird im Speicher für vertrauenswürdige Stammzertifizierungsstellen des Clients sein. Anschließend erstellt ein Zufallswert Geheimnis, mit dem öffentlichen Schlüssel des Servers verschlüsselt und sendet es an den Server.
  5. Der Server empfängt und entschlüsselt das Zufallswert Geheimnis mit seinem privaten Schlüssel. Dieser Server ist die einzige, die dies tun kann, denn es der einzige Server mit dem entsprechenden privaten Schlüssel ist.
  6. Der Server und der Client haben Zufallswert geheimen und Zufallszahlen ausgetauscht am Anfang des Prozesses. Sie verwenden diese Werte um zu generieren, die 48-Byte geheimen Hauptschlüssel (auch bekannt als das freigegebene Geheimnis). Nach dem Generieren der geheimen Hauptschlüssel, löschen sie das Zufallswert Geheimnis.
  7. Sowohl Client als auch Server hash der 48-Byte geheimen Hauptschlüssel, und es verwenden, um die MAC-Geheimnis (der Sitzungsschlüssel für das hashing verwendet) und der WRITE-Schlüssel (den Session Key für die Verschlüsselung verwendet) generieren. Diese Schlüssel ver- und Entschlüsseln der Kommunikation für diese Sitzung. Nachdem die Sitzung beendet ist, werden die Schlüssel gelöscht.

Wenn jeder Schritt dieser Sequenz nicht funktioniert, hat nicht die Verbindung vollständig gesichert. Was dann passiert, hängt die erweiterte Einstellungen auf dem Remote Desktop-Connec­Tion (RDC) Client. Im Falle eines Authentifizierungsfehlers können Benutzer die folgenden tun:

  • Trotzdem verbinden Sie ohne Benachrichtigung des Clients beim Authentifizieren des Servers ein Problem aufgetreten.
  • Warnen Sie den Client, aber immer noch erlauben Sie, die Verbindung (die Standardeinstellung).
  • Verweigern Sie die Verbindung, wenn es nicht überprüft werden kann.

Die Ausnahme ist, wenn der Server eine minimale Sicherheitsstufe erforderlich ist. Wenn das der Fall ist und der Client die Mindestanforderungen nicht erfüllen kann, schlägt die Verbindung fehl. Standardmäßig Client und Server auszuhandeln und verwenden die sichersten Verbindungseinstellungen, die sie beide unterstützen.

Anmeldeinformationen zwischenspeichern mit CredSSP

Zwischenspeicherung von Anmeldeinformationen wurde mit Windows Vista und Windows Server 2008 eingeführt. Auf diese Weise können zwei Funktionen – eine, die den Benutzer und eine, die hilft, den Server zu schützen.

Zwischenspeicherung von Anmeldeinformationen hilft Benutzern durch Speichern von Anmeldeinformationen für eine bestimmte Verbindung, so brauchen sie nicht jedes Mal, wenn sie Verbindung mit diesem Server geben (Dies ist SSO). Dies beschleunigt die Verbindung. Andernfalls muss eine vermittelte Verbindung bei jedem Schritt überprüft werden.

Auf der Serverseite bietet der Zwischenspeicherung von Anmeldeinformationen Anmeldeinformationen an den Server bevor es eine Sitzung einrichtet. Dies erspart den Aufwand einer Sitzung, wenn der Benutzer autorisiert ist nicht (Dies ist NLA).

Das Stück, das Anmeldeinformationen zwischenspeichern Arbeit macht ist das Credential Security Service Provider (CredSSP). Dies wird von Windows 7, Windows Vista, Windows Server 2008 und Windows XP SP3 unterstützt. Es ist nicht mit der Version von RDC wird verwendet, weil der CredSSP ist Teil des Betriebssystems verknüpft. CredSSP führt die folgenden Funktionen:

  • CredSSP bietet NLA Rahmen, der einen Benutzer auf einem Host für Remotedesktopsitzungen-Server authentifiziert, bevor voll den Verbindungsaufbau.
  • Für Wiederverbinden mit einer Sitzung in einer Serverfarm, beschleunigt CredSSP den Prozess der Übergabe der Verbindungs an dem richtigen Server mit den Host für Remotedesktopsitzungen-Server finden Sie unter Wer ist anmelden, ohne eine gesamte Sitzung erstellen zu lassen. Ein etwas anderes Szenario verwendet das NLA.
  • Für SSO CredSSP speichert Benutzeranmeldeinformationen und übergibt sie an dem Host für Remotedesktopsitzungen-Server, Anmeldung zu automatisieren.

CredSSP ermöglicht die gegenseitigen Authentifizierung des Servers und der Client (siehe Abbildung 3).

Authenticating both the server and client requires a secure channel.

Abbildung 3 authentifiziert sowohl Server als auch Client erfordert einen sicheren Kanal.

Dieser Authentifizierungsprozess führt die folgenden Schritte.

  1. Der Client initiiert einen sicheren Kanal mit dem Server mithilfe von TLS. Der Server übergibt wieder das Zertifikat mit Name, CA und öffentlichen Schlüssel. Nur der Server identifiziert wird. Der Kunde bleibt an dieser Stelle anonym.
  2. Wenn die Sitzung eingerichtet ist und ein Sitzungsschlüssel erstellt, CredSSP verwendet das Simple and Protected GSS-API Negotiation (SPNEGO) Protokoll zum gegenseitig Gewähr­Cate Server und Client. Dieser Mechanismus ermöglicht im Grunde, Client und Server-Authentifizierungsmechanismus zu vereinbaren, die sie beide, z. B. Kerberos oder Windows NT LAN Manager (NTLM unterstützen).
  3. Wenn gegenseitiger Authentifizierung abgeschlossen ist, CredSSP auf der Clientseite verschlüsselt das Server-Zertifikat mit dem Sitzungsschlüssel während Schritt 2 erstellt wurde, und sendet es an den Server. Der Server empfängt das verschlüsselte Zertifikat, entschlüsselt mit seinem privaten Schlüssel und dann fügt man das signifikanteste Bit von der Zertifikat-Nummer. Dann das Ergebnis verschlüsselt und sendet es an den Client zurück. Der letztere Vorgang sorgt für , dass niemand den Austausch zwischen Client und Server abfangen und den Server fälschen können.
  4. Der Client Bewertungen das verschlüsselte Zertifikat erhielt vom Server und com­pares es auf eigene Zertifikate.
  5. Vorausgesetzt, dass die Ergebnisse übereinstimmen, sendet CredSSP auf Client-Seite die Anmeldeinformationen des Benutzers an den Server.

Die Identität des authentifizierenden Server

Kommunikation mit einem remote-Computer, der Sie um Ihre Anmeldeinformationen erfordert eine Gefahr ist, dass der Server möglicherweise nicht, was Sie denken. Wenn es einen Identitätswechsel eine vertrauenswürdige Rogue-Server ist, könnten Sie den falschen Server versehentlich Ihre Anmeldeinformationen eingeben. Dies würde Angreifer alles geben, was sie benötigen, um Ihre Domäne oder Server herstellen.

RDP gehören Verschlüsselung, aber das Protokoll keine Mittel, um den Server zu authentifizieren. Das ist TLS und CredSSP kommen. Server-Authentifizierung prüft den Namen, den Sie in der Remotedesktopverbindungs-Client (oder RDP-Datei) mit dem Namen im Zertifikat angegeben im RD-Konfigurationstool auf dem Host für Remotedesktopsitzungen-Server ausgestellt eingeben, an den es angeschlossen ist.

Signieren von RDP-Dateien

Sie können Zertifikate zum digitalen Signieren von RemoteApp-Dateien sowie die Verbindung zu einem Pool oder persönliche VM (VDI) RDP-Dateien verwenden. Diese Dateien signieren, versichert der Nutzer, die sie von einer vertrauenswürdigen Quelle erstellt wurden. Es sichert auch die RDP-Datei vor Manipulationen.

Signieren von RemoteApp Dateien ist auch für die Web-SSO-Implementierung erforderlich. Dadurch können Benutzer sich einmal zu Web Access für Remotedesktop-Website anmelden. Dann können sie RemoteApps aus einer Farm zu starten, ohne ihre Anmeldeinformationen erneut eingeben.

CredSSP kann nicht Web Access für Remotedesktop Anmeldeinformationen übergeben. Der Benutzer muss zuerst auf der Website zum Speichern von Anmeldeinformationen anmelden. Sie müssen dann nicht erneut authentifizieren, um RemoteApp-Programme zu starten. Damit dies funktioniert die RemoteApps muss unterzeichnet werden und der Benutzer muss das Zertifikat zum Signieren der RemoteApp verwendet Vertrauen.

RDP-Dateien erstellt, wenn ein Benutzer eine RDP-Verbindung auf der Registerkarte RD Web Access Desktops startet werden dynamisch erstellt. Die Dateien sind nicht signiert. Daher funktioniert nicht-Web-SSO die Verbindung zu Desktops. Der Benutzer muss sich der Endpunkt anmelden, sobald die Verbindung hergestellt ist. Web-SSO wird nicht für Verbindungen mit Pool oder persönliche VMs auch funktionieren.

Sichern von Verbindungen

RD-Gateway verwendet TLS 1.0 für die sichere Kommunikation zwischen Remotedesktopgateway und remote-desktop-Clients, befindet sich in der Regel außerhalb Ihres Unternehmensnetzwerks (über das Internet). TLS, erfordert wie zuvor beschrieben, ein SSL-Zertifikat. Sie können auch sichere Kommunikation zwischen Clients und dem Web Access für Remotedesktop-Server mithilfe eines digitalen Zertifikats zum Verschlüsseln von Sitzungen Website (HTTPS).

Zertifikate sind ein wesentliches Stück einer RDS-Bereitstellung. RDS verwendet Zertifikate, um die sichere Kommunikation und die Funktionen, die sie aktivieren. Nächsten Monat werde ich Einrichten von RDS-Rollendienste, die Zertifikate verwenden behandeln.

Raymond Chen

Kristin Griffin ist ein Remote Desktop Services MVP. Sie moderiert eine Microsoft-Forum zu helfen, die Server-basierten computing-Gemeinschaft (Remote Desktop Services) gewidmet und führt eine RDS-Blog unter blog.kristinlgriffin.com. Sie leistet einen Beitrag zur Mark Minasi "Mastering Windows Server 2008" (Sybex, 2008) und "Mastering Windows Server 2008 R2" (Sybex, 2010). Sie zusammen mit Christa Anderson auch "Microsoft Windows Server 2008 Terminal Services Resource Kit" (Microsoft Press, 2008) und "Microsoft Windows Server 2008 R2 Remote Desktop Services Resource Kit" (Microsoft Press, 2010).

Verwandter Inhalt