Ich habe:
- Ein Windows 7-Clientcomputer. Ich bin kein Administrator für diesen Computer.
- Ein Windows 2008R2-Server, auf dem ich eine Sitzung per Remotedesktop öffnen möchte.
- ARemotedesktopgateway, ebenfalls mit Windows 2008R2.
- Eine Chipkarte.
Der Server ist so konfiguriert, dass die Anmeldung per Smartcard möglich ist. Das Gateway erfordert ebenfalls eine Smartcard-Authentifizierung. Alle Clients und Server kennen und vertrauen allen relevanten CA-Zertifikaten, kein Zertifikat ist abgelaufen, alle CRLs werden dort veröffentlicht, wo sie sein sollten.
Entscheidend, das Zertifikat auf der Chipkarte hat eineErweiterte SchlüsselverwendungErweiterung (EKU), die NICHT die OID „Smartcard-Anmeldung“ enthält. Sie verfügt jedoch über „Client-Authentifizierung“. Der Server und das Gateway wurden so konfiguriert, dass sie das Zertifikat dennoch akzeptieren: Dies ist eine Richtlinieneinstellung namens „Zertifikate ohne erweitertes Schlüsselverwendungs-Zertifikatsattribut zulassen“, wie beschriebenDort.
Das Problem
Der Client verwendet eine .rdp-Datei, in der der Servername angegeben istUndder Gateway-Name. Da es sich bei dem Gateway um ein Gateway und nicht um einen tatsächlichen Remote-Desktop-Server handelt, wird kein „Anmeldebildschirm“ angezeigt. Stattdessen basiert die Smartcard-Authentifizierung auf einer vom Client verwalteten GUI ( mstsc.exedem Standard-RD-Client in Windows), damit der Benutzer seine Smartcard auswählen und seinen PIN-Code eingeben kann. So sollte das Popup aussehen:
(Entschuldigen Sie das französischsprachige Popup; ich habe kein britischsprachiges Windows 7 zur Hand.)
Leider wird das Popup nicht in dieser Form angezeigt. Stattdessen erhalte ich Folgendes:
Analyse
Wie beschriebenHier, lässt die Client-Anwendung (mstsc.exe) das Betriebssystem (Windows 7) die Smartcards „aufzählen“. Das Betriebssystem sucht nach Smartcards mit Zertifikaten, die bestimmte Kriterien erfüllen, insbesondere, dass jede in einem solchen Zertifikat gefundene EKU-Erweiterung die OID „Smartcard-Anmeldung“ enthält. Dies geschieht, bevor tatsächlich versucht wird, mit dem Gateway zu kommunizieren, ganz zu schweigen vom endgültigen Zielserver. Das Gateway und der Server wären mit meinem Zertifikat vollkommen zufrieden; sie wurden so konfiguriert. Das Client-Betriebssystemerzwingtdieselben Regeln, entsprechend der eigenen Konfiguration. In meinem Fall verweigert Windows 7 mir die Nutzung meiner Smartcard, da die lokale Richtlinie das Öffnen einer lokalen Sitzung ablehnen würde (obwohl ich gar nicht versuche, eine lokale Sitzung zu öffnen).
Dies funktionierte früher mit einem Windows XP-Client, da das „Popup zur Smartcard-Auswahl“ von Windows XP diese Prüfungen nicht erzwingt (Windows XP prüft die EKU auf eine noch restriktivere Weise, da es das Fehlen einer EKU-Erweiterung nicht toleriert, diese Prüfungen jedoch nur beim tatsächlichen Versuch erzwingt, eine lokale Sitzung zu öffnen, nicht bei der Auswahl eines Zertifikats für eine Remotesitzung).
Die Lösung, die ich nicht verwenden kann
Die „normale“ Lösung besteht darin, den lokalen Client (Windows 7) mit demselben „Zertifikate ohne erweitertes Schlüsselverwendungs-Zertifikatsattribut zulassen“ wie den Server zu konfigurieren. Auf diese Weise akzeptiert das Popup zur Smartcard-Auswahl nun die Anzeige der Smartcard und alles ist in Ordnung. Ich habe es auf einem anderen System getestet. Auf meinen Zielsystemen kann ich das jedoch nicht tun, da zum Ändern der lokalen Richtlinie Administratorrechte erforderlich sind, die ich nicht habe. Ebenso könnte die Einstellung für Clients, die Teil einer Domäne sind, von einem GPO auf dem AD-Server übertragen werden, was mir aufgrund fehlender entsprechender Berechtigungen ebenfalls verwehrt ist.
Man könnte auch sagen, dass diese Richtlinieneinstellung tatsächlich die Anmeldung auf dem Client-Rechner mit einem Zertifikat erlaubt, das nicht die richtige OID in seiner EKU hat, und das kann als unerwünschter Nebeneffekt betrachtet werden. Ich versuche, eine Sitzung auf einemRemote-Server; ich sollte die Bedingungen für die Eröffnung einer Sitzung nicht ändern müssen auf derlokaler Client.
Ältere Versionen von mstsc.exe (von Windows XP) konnten anscheinend eine Verbindung zum Server herstellen, ohne dass eine Client-Authentifizierung erforderlich war. In diesem Fall zeigte der Remote-Server seinen Anmeldebildschirm (den „großen blau-grünen Bildschirm“) an und kümmerte sich selbst um die Smartcard-Aufzählung. Da der Server über die entsprechende Richtlinie verfügt, würde dies funktionieren. Ich kann eine solche Lösung jedoch aus zwei Gründen nicht verwenden:
- Die mstsc.exe von Windows 7 besteht offenbar darauf, eine Authentifizierung mit eigenen Popups durchzuführen.
- Da ist einTor, der im Gegensatz zum eigentlichen Zielserver keinen "Anmeldebildschirm" anzeigt. Wenn Sie ein Gateway verwenden, das eine Client-Smartcard-Authentifizierung erfordert, wird die Client-Smartcard-Auswahlmussvon der Client-Software verwaltet werden.
Die Frage
Hier ist meine Frage: Gibt es einen Ausweg aus diesem Problem? Idealerweise eine Art Konfigurationseinstellung in mstsc.exe (ein Befehlszeilenschalter oder eine Klausel in einer RDP-Datei), die mstsc.exe anweistNICHTdas OS-Smartcard-Auswahl-Popup zu verwenden, sondern die Aufzählung selbst durchzuführen,ohneversuche, irgendetwas über die EKU durchzusetzen. Ich habe keine Spur einer solchen Funktion gefunden, aber das Fehlen eines Beweises ist kein Beweis für das Fehlen. Vielleicht habe ich es einfach übersehen.
Antwort1
Erstellen Sie eine RDP-Datei für die Verbindung, legen Sie „enablecredsspsupport:i:0“ in der RDP-Datei fest und stellen Sie sicher, dass die Smartcard-Option für die lokale Ressourcenzuordnung aktiviert ist (standardmäßig ist sie aktiviert, das sollte also bereits der Fall sein, sofern Sie die Einstellung nicht explizit geändert haben).
Weitere Einzelheiten finden Sie im folgenden Eintrag: http://blogs.msdn.com/b/rds/archive/2007/01/22/vista-remote-desktop-connection-authentication-faq.aspx#_When_to_use
Ich bin nichtganzIch bin mir sicher, dass dies Ihr Problem wegen des Gateways in der Mitte lösen wird, aber ehrlich gesagt fällt mir keine andere mögliche Lösung für dieses Problem ein.