Erstmals veröffentlicht auf TECHNET am Jan 24, 2014
Guten Morgen AskPerf! Kiran hier mit einer Frage an Sie: Warum brauchen wir Zertifikate? Nun, Zertifikate werden verwendet, um die Kommunikation zwischen zwei Maschinen zu signieren. Wenn ein Client eine Verbindung zu einem Server herstellt, wird die Identität des Servers, der die Verbindung empfängt, und wiederum die Informationen vom Client mithilfe von Zertifikaten überprüft.
Dies geschieht, um mögliche Man-in-the-Middle-Angriffe zu verhindern. Wenn ein Kommunikationskanal zwischen dem Client und dem Server eingerichtet wird, bürgt die Behörde, die das Zertifikat ausstellt / generiert, dafür, dass der Server authentisch ist.
Solange der Client dem Server vertraut, mit dem er kommuniziert, werden die Daten, die an und von dem Server gesendet werden, als sicher angesehen. Das bringt mich zur nächsten Frage:
Welche Art von Zertifikat ist für RDS erforderlich?
Der folgende Blog enthält Informationen zur Art der Zertifikate und wie Sie diese mit der internen Zertifizierungsstelle der Domäne erstellen können.
http://blogs.msdn.com/b/rds/archive/2010/04/09/configuring-remote-desktop-certificates.aspx
Grundlegende Anforderungen für Remotedesktopzertifikate:
- Das Zertifikat wird im „Persönlichen“ Zertifikatsspeicher des Computers installiert.
- Das Zertifikat hat einen entsprechenden privaten Schlüssel.
- Die Erweiterung „Erweiterte Schlüsselverwendung“ hat den Wert „Serverauthentifizierung“ oder „Remotedesktopauthentifizierung“ (1.3.6.1.4.1.311.54.1.2). Zertifikate ohne die Erweiterung „Enhanced Key Usage“ können ebenfalls verwendet werden.
Wie die ausgeführte Funktion nahelegt, benötigen wir ein ‚Server Authentication‘-Zertifikat. Dieses Zertifikat kann mit der Vorlage ‚Workstation Authentication‘ generiert werden (falls erforderlich).
Hier ist der genaue Vorgang:
- Öffnen Sie CERTSRV.Erstellen und konfigurieren Sie Zertifikate.
- Offene Zertifizierungsstelle.
- Erweitern Sie im Detailbereich den Namen des Instruktorcomputers.
- Klicken Sie mit der rechten Maustaste auf Zertifikatvorlagen, und wählen Sie Verwalten. Klicken Sie mit der rechten Maustaste auf Workstation-Authentifizierung und dann auf Vorlage duplizieren.
- Ändern Sie auf der Registerkarte Allgemein den Anzeigenamen der Vorlage in Client-Server-Authentifizierung, und aktivieren Sie Zertifikat in Active Directory veröffentlichen.
- Klicken Sie auf der Registerkarte Erweiterungen auf Anwendungsrichtlinien und dann auf Bearbeiten. Klicken Sie auf Hinzufügen und wählen Sie dann Serverauthentifizierung aus. Klicken Sie auf OK, bis Sie zum Dialogfeld Eigenschaften der neuen Vorlage zurückkehren.
- Klicken Sie auf die Registerkarte Sicherheit. Klicken Sie für Domänencomputer auf das Kontrollkästchen ‚Autoenroll zulassen‘. OK. Schließen Sie die Konsole Zertifikatvorlagen.
- Klicken Sie im Snap-In certsrv mit der rechten Maustaste auf Zertifikatvorlagen, und wählen Sie Neu und dann auszustellende Zertifikatvorlage aus.
- Wählen Sie Client-Server-Authentifizierung und klicken Sie dann auf OK.
Dies wird sichtbar, wenn Sie das Zertifikat im MMC-Snap-In ‚Zertifikate‘ anzeigen (siehe unten:
Wenn Sie das Zertifikat öffnen, enthält die Registerkarte ‚Allgemein‘ auch den Zweck dieses Zertifikats als ‚Serverauthentifizierung‘, wie unten gezeigt:
Eine andere Möglichkeit, dies zu überprüfen, besteht darin, zum Abschnitt ‚Details‘ des Zertifikats zu gehen und sich die Eigenschaft ‚Erweiterte Schlüsselverwendung‘ anzusehen:
Der einfachste Weg, ein Zertifikat zu erhalten, wenn Sie die Clientcomputer steuern, die eine Verbindung herstellen, ist die Verwendung von Active Directory-Zertifikatdiensten. Sie können Ihre eigenen Zertifikate anfordern und bereitstellen, denen jeder Computer in der Domäne vertraut.
Wenn Sie Benutzern erlauben, sich extern zu verbinden, und sie nicht Teil Ihrer Domäne sind, müssen Sie Zertifikate von einer öffentlichen Zertifizierungsstelle bereitstellen. Beispiele, einschließlich, aber nicht beschränkt auf: GoDaddy, Verisign, Entrust, Thawte, DigiCert
Nachdem Sie nun wissen, welche Art von Zertifikat Sie benötigen, sprechen wir über den Inhalt des Zertifikats.
In Windows 2008/2008 R2 stellen Sie eine Verbindung zum Farmnamen her, der gemäß DNS Round Robin zuerst an den Redirector neben dem Verbindungsbroker und schließlich an den Server weitergeleitet wird, auf dem Ihre Sitzung gehostet wird.
In Windows 2012 stellen Sie eine Verbindung zum Verbindungsbroker her, der Sie mithilfe des Sammlungsnamens zur Sammlung weiterleitet.
Die Zertifikate, die Sie bereitstellen, müssen einen Betreff-Namen oder einen alternativen Betreff-Namen haben, der mit dem Namen des Servers übereinstimmt, mit dem der Benutzer eine Verbindung herstellt. Für die Veröffentlichung muss das Zertifikat beispielsweise die Namen aller RDSH-Server in der Sammlung enthalten. Das Zertifikat für RDWeb muss den FQDN der URL enthalten, basierend auf dem Namen, mit dem die Benutzer eine Verbindung herstellen. Wenn Sie Benutzer haben, die sich extern verbinden, muss dies ein externer Name sein (muss mit dem übereinstimmen, mit dem sie sich verbinden). Wenn Benutzer eine interne Verbindung zu RDWeb herstellen, muss der Name mit dem internen Namen übereinstimmen. Für Single Sign On muss der Betreff-Name wiederum mit den Servern in der Sammlung übereinstimmen.
In unserem Beispiel soll meine RDS-Bereitstellung die folgenden Maschinen enthalten:
RDSH1.RENDER.COM Sitzungshost mit konfigurierten Remote-Apps
RDSH2.RENDER.COM Sitzungshost mit konfigurierten Remote-Apps
RDVH1.RENDERING.COM-Virtualisierungshost mit konfigurierten VDI-VMs
RDVH2.RENDER.COM Virtualisierungshost mit konfigurierten VDI-VMs
RDCB.RENDER.COM Verbindungsbroker
RDWEB.RENDER.COM RDWeb- und Gateway-Server
Wenn mein Client intern eine Verbindung herstellt, gibt er den FQDN des Servers ein, der die Webseite hostet, dh: RDWEB.RENDER.COM .
Der Name des Zertifikats muss dieser Name der URL sein, zu der der Benutzer die Verbindung herstellen wird. Aber wir müssen uns daran erinnern, dass die Verbindung nicht nur hier endet. Die Verbindung fließt dann vom Webserver zu einem der Sitzungshosts oder Virtualisierungshosts und auch zum Verbindungsbroker.
Das Zertifikat kann auf allen diesen Servern verwendet werden. Aus diesem Grund wird empfohlen, dass der alternative Betreff-Name des Zertifikats die Namen aller anderen Server enthält, die Teil der Bereitstellung sind.
Kurz gesagt, das Zertifikat für meine Umgebung wäre wie folgt:
Typ: Serverauthentifizierung
Name: RDWEB.RENDER.COM
SAN: RDSH1.RENDER.COM; RDSH2.RENDER.COM; RDVH1.RENDER.COM ; RDVH2.RENDERING.KOM; RDCB.RENDER.COM
Dies ist alles, was Sie benötigen, solange Sie 5 oder weniger Server in der Bereitstellung haben. Aber wir haben ein Problem, wenn wir mehr Server in der Bereitstellung haben. Dies liegt daran, dass der SAN (Subject Alternate Name) eines Zertifikats nur 5 Servernamen enthalten kann. Wenn Sie mehr davon haben, müssen Sie ein Platzhalterzertifikat ausstellen lassen, um alle Server in der Bereitstellung abzudecken. Hier ändert sich mein Zertifikat wie folgt:
Typ: Serverauthentifizierung
Name: RDWEB.RENDER.COM
SAN: *.RENDERING.COM
Wir stoßen immer noch auf einige Herausforderungen, wenn es um das folgende Szenario geht. Beachten Sie, dass dies nur zutrifft, wenn Sie über externe Benutzer verfügen, die auf die Bereitstellung zugreifen.
Externer Name: RDWEB.RENDER.com
Interner Name: RDWEB.RENDERING.local
Hier, wenn Sie ein Zertifikat mit RDWEB.RENDER.COM im Namen werden die Zertifikatfehler weiterhin angezeigt. Dies liegt daran, dass das Zertifikat einen Server mit dem FQDN validieren soll: ‚RDWEB.RENDER.COM ‚. Ihr Server ist jedoch ‚RDWEB.RENDERING.LOKAL‘ und die ‚.com‘ zu ‚.local‘ magic passiert nur an Ihrer öffentlichen Firewall / Router mit Port-Forwarding (am häufigsten Szenario).
In solchen Szenarien wurde zuvor empfohlen, dass der Name auf dem Zertifikat den Namen ‚.com‘ und das SAN den Namen ‚ enthält.lokaler Name.
In letzter Zeit stellen alle öffentlichen Zertifikatanbieter die Ausstellung von Zertifikaten mit ‚ ein.LOKAL‘ in ihnen. Ab Windows 8 und Windows Server 2012 müssen die externen und internen Namen nicht mehr im Zertifikat enthalten sein.
In Szenarien, in denen externe Clients eine Verbindung herstellen und ein privates internes Domänensuffix (DOMÄNE.LOCAL), können Sie ein Zertifikat von einer öffentlichen CA mit dem externen (RDWEB.DOMAIN.COM ) benennen Sie es und binden Sie es an die RD-Webzugriffs- und RD-Gateway-Rollen, da dies die einzigen Rollen sind, die dem Internet ausgesetzt sind. Für RD Connection Broker – Publishing und RD Connection Broker – Enable Single Sign On können Sie ein internes Zertifikat mit der DOMÄNE verwenden.LOKALER Name darauf. Dies funktioniert jedoch, wie bereits erwähnt, nur mit Clients, die über RDC 8.0 oder höher verbunden sind.
Der RD-Gateway- und Remotedesktopclient Version 8.0 (und höher) stellt den externen Benutzern eine sichere Verbindung zur Bereitstellung bereit. Einmal mit der Bereitstellung verbunden, das interne Zertifikat mit dem ‚.local‘ name kümmert sich um Remote-App-Signierung (Veröffentlichung) und Single Sign-On.
Schauen wir uns nun an, wo wir das Zertifikat konfigurieren, das wir haben:
Öffnen Sie den Server-Manager auf dem Verbindungsbroker-Server und klicken Sie im linken Bereich auf Remotedesktopdienste.
Sobald Sie hier sind, sehen Sie Ihre Bereitstellung wie in der folgenden Abbildung dargestellt. Klicken Sie auf Aufgaben und wählen Sie „Bereitstellungseigenschaften bearbeiten“
Dadurch wird das Eigenschaftenblatt der Bereitstellung angezeigt. Wählen Sie im linken Bereich die Option Zertifikate aus:
Wie bereits erwähnt, können Sie nun das erstellte Zertifikat über die Schaltfläche ‚Vorhandenes Zertifikat auswählen‘ am unteren Bildschirmrand auswählen.
Zeigen Sie einfach auf ‚.pfx-Datei und lassen Sie das Zertifikat für die Rolle importieren.
Sie können ein einzelnes Zertifikat für alle Rollen verwenden, wenn Ihre Clients nur domänenintern sind, indem Sie ein einfaches Platzhalterzertifikat (*.RENDERING.LOKAL) und bindet es an alle Rollen.
Selbst wenn Sie mehrere Server haben, die Teil dieser Bereitstellung sind, importiert der Servermanager das Zertifikat auf alle Server in der Bereitstellung, platziert sie im vertrauenswürdigen Stammverzeichnis der Maschinen und bindet sie an die jeweiligen Rollen.
-Kiran Kadaba
