2 RemoteSession ohne SSL

Nachdem die Voraussetzungen aus Kapitel 1 und Kapitel 1.1 geprüft oder gegebenfalls nachgezogen wurden und das Remoting aus dem Zielcomputer, wie in Kapitel 1.2 beschrieben, aktiviert wurde, kann es jetzt mit dem Remoting via Powershell endlich losgehen:

2.1 new-pssession <Clientname>

Starten oder Neuerstellen kann man eine RemoteSession mit den beiden cmdlets "New-PSSession" (permanent) oder "EnterPSSession" (temporär).
Genauer gehe ich auf interaktive Sessions im Kapitel 4.4 ein. Dort versuche ich auch die Unterschiede zwischen dauerhaften und temporären Sessions herauszuarbeiten. Eine etwas andere Art von Remoting sind "implizite Session", die ich hier noch auslasse und auf die ich in Kapitel 4.5 detaillierter eingehen werde.
 

Beispiel 1: Ablauf einer interaktiven Remotesession ohne SSL

Schritt 1

#
$Computer="DC1"
New-PsSession $computer
Id Name            ComputerName    State    ConfigurationName     Availability
 -- ----            ------------    -----    -----------------     ------------
  4 Session4        dc1             Opened   Microsoft.PowerShell     Available

 

Schritt 2

#Beitreten zur Session 4
enter-pssession 4

 

Schritt 3

#Arbeiten am RemoteComputer
[dc1]: PS C:\Users\TestUser.DOM1\Documents> hostname
DC1

 

Schritt 4

#Verlassen der Session 4 (nicht Beenden!)
[dc1]: PS C:\Users\Testuser.DOM1\Documents> exit-pssession

 

Schritt 5

#Einrichten einer weiteren Session
New-PsSession $computer
Id Name            ComputerName    State    ConfigurationName     Availability
 -- ----            ------------    -----    -----------------     ------------
  5 Session5        dc1             Opened   Microsoft.PowerShell     Available


Schritt 6

#Auslisten aller Remotessions
get-pssession
 Id Name            ComputerName    State    ConfigurationName     Availability
 -- ----            ------------    -----    -----------------     ------------
  4 Session4        dc1             Opened   Microsoft.PowerShell     Available
  5 Session5        dc1             Opened   Microsoft.PowerShell     Available

Anmerkung: Mit enter-pssession <computername> kann man in einem Schritt eine neue Session einrichten und dieser beitreten. Allerdings ist diese Session dann temporär und wird mit exit-pssession unwiederbringlich beendet.Powershell Remote
 

Beispiel 2: Beenden aller permanenten Remotessions zu $computer

Remove-PsSession $computer

Es können nur bis zu fünf RemoteSessions auf einem ZielComputer ausgeführt werden. Wenn folgende Meldung beim Aufruf von "new-pssession" erscheint:

"The WS-Management service cannot process the request. This user is allowed a maximum number of 5 concurrent shells, which has been exceeded. Close existing shells or raise the quota for this user."

dann muss man entweder den "remove-pssession" Befehl benutzen um Sessions zu beenden, oder auf dem Remoterechner nach Prozessen des Namens "wsmprovhost"  beispielsweise mit dem Taskmanager suchen und schliessen.
 

3 RemoteSession mit SSL-Verschlüsselung

Ein zusätzliches Plus an Sicherheit beim Remoting kann man erreichen, indem der WinRM die Verbindung zum Remoterechner mit einer zertifikatsbasierten SSL-Verbindung absichert.

Um den Powershellbefehl

New-PsSession dc1 -usessl

erfolgreich ausführen zu können, bedarf es aber noch ein paar Voraussetzungen.
Anhand meiner einfachen Testumgebung, bestehend aus einem Windows2008R2-Server mit den Rollen "ActiveDirectory-Domänendienste" und "Activedirectory-Zertifikatsdienste" und einem Windows7 Client will ich die notwendigen Schritte darstellen.
 

3.1 Kurzbeschreibung SSL

Über das Protokoll Secure Sockets Layer (SSL) finden sich zahlreiche Informationen im Netz und in der Literatur.
Trotzdem möchte ich kurz und nicht so sehr technisch auf die Funktionsweise von SSL eingehen.
Da ich kein Zertifikatscrack bin, konzentriere ich mich mehr auf das prinzipielle Verständnis als auf die tiefe Technik.

SSL kann Anwendungsprotokolle auf OSI-Schicht 6 wie HTTP, SMTS oder das hier interessierende WS-Management Protocol mit einem symmetrischen Schlüssel vrschlüsseln. Zu Beginn jeder SSL-Verbindung wird der SSL-Schlüssel neu ausgehandelt und nach Beendigung verworfen. Besteht die SSL-Verbindung, wird dieser "Symmetrische SSL-Schlüssel" vom Client und vom Server zum Ver- und Entschlüsseln der Verbindung benutzt.

Da symmetrische Verfahren mathematisch einfachere Algorithmen nutzen als asymmetrische Verfahren, können damit auch grössere Datenmengen performant verschlüsselt werden. Verbreitete SSL-Zertifikate benützen heute den SHA1RSA Signaturalgorithmus bei einer Schlüssellänge von 2048 Bits.

Wie kommen beide Seiten an den symmetrischen Schlüssel?
Dazu benötigt nur(!) der Server, also der Rechner auf den wir zugreifen wollen, ein sogenanntes SSL-Zertifikat (nicht geheim) und ein damit mathematisch-verknüpftes Schlüsselpaar bestehend aus einem privaten (geheimen) und öffentlichen (nicht geheimen) Schlüssel. Zertifikat und Schlüsselpaar erhält der Server beispielsweise mithilfe einer Microsoft CA, MSDN: Makecert oder eines anderen kommerziellen Keycenters das Zertifikate auch von Anbietern wie Verisign anbietet.
Im SSL-Zertifikat sind sicherheitstechnisch nur unkritische Informationen enthalten, wie unter anderem

  • ausstellende CA,
  • Signatur der CA,
  • Gültigkeit  (von ... bis ...)
  • Rechnername (FQDN)
  • öffentlicher Schlüssel

Dieses Zertifikat schickt der Server an den anfordernden Clients. Mit Client ist hier genaugenommen der Clientteil des WinRM-Services gemeint, bei SSL-gesicherten Webseiten wäre es der Browser.
Der Client prüft die Gültigkeit des Zertifikats:
 a) anhand der CA-Signatur im Zertifikat. Dazu müssen im Zertifikatsspeicher des Clients das öffentliche Zertifikat der ausgebenden CA, sowie eventuell auch aller darüberliegenden CAs bis hoch zur RootCA (=Zertifikatskette) als vertrauenswürdige Stammzertifizierungsstellen enthalten sein. Die Authentizität des Servers garantiert die ausgebende CA
  b) anhand einer Sperrliste (Certificate Revocation List  oder moderner OCSP), ob das Zertifikat gesperrt wurde. Ist die Seriennummer des Zertifikats auf dieser Liste enthalten, oder kann der Client diese Sperrliste nicht erreichen, akzeptiert er das Zertifikat nicht.
 c) anhand der Daten im Zertifikat, ob das aktuelle Datum in der Gültigkeitsdauer liegt.Zertifikate können so ausgestellt werden, daß sie erst ab einem zukünftigem Datum gültig werden.
 d) anhand des Vergleichs des DNS-Namens und des Namens im Zertifikat (Details -> Antragsstellername)

Fallen a),b),c) und d) positiv aus, so generiert der Client erstens einen sogenannten "pre-master-secret" und zweitens den symmetrischen Schlüssel für die SSL-Verbindung.
Den "pre-master-secret" verschlüsselt der Client mit dem PublicKey des Servers, den er aus dem überprüften Zertifikat entnommen hat und sendet dieses Paket zurück an den Server. Der Server öffnet das Paket mit seinem PrivateKey und generiert aus dem "pre-master-secret" nach dem gleichen Algorithmus wie der Client denselben SSL-Schlüssel.

Meine Literaturquelle ist das PKI-Werk von Brian Komar "Windows Server 2008 - PKI and Certificate Security" aus dem MS-Press Verlag, welches im Kapitel 19 das Unterkapitel "How SSL Works" enthält.
 

3.2.1 Microsoft CA bereitstellen (CA-Server)

Da ich die Installation einer CA bereits dokumentiert habe, beschränke ich mir hier nur auf die Verweise

PSSkripte signieren -> 2.1 eine einfache CA installieren

PSSkripte signieren -> 2.2 Das Rootzertifkat verteilen

3.2.2 Zertifikatsvorlage kopieren und anpassen (optional) (CA-Server)

Um eine SSL-Verbindung erstellen zu können, benötigen wir ein Zertifikat des Remoterechners, welches den CommonName wie "CN=Dom1Win7.Dom1.Intern" enthält. Von Haus aus passend sind beispielsweise die Templates "Computer" oder "Domänencontroller". Wenn kein Enterpriseserver als CA zur Verfügung steht, müssen wir diese Zertifikatsvorlagen benutzen.
Ist hingegen ein EnterpriseServer als CA verfügbar, so können wir exisitierende Templates nach unseren Vorstellungen anpassen. Am besten kopiert man sich ein einigermassen passendes Template, modifiziert die gewünschten Eigenschaften und speichert das Template unter einem passenden Namen.

Das Erstellen eines Zertifikatstemplates zur Codesignatur habe ich in
PSSkripte signieren: 2.3 Zertifikatstemplate erstellen schon beschrieben. Das Vorgehen für ein Computerzertifikat ist identisch, nur daß nicht die Vorlage "Codesignatur", sondern "Computer" oder "Domänencontroller" verwendet wird.

 

-Unter "Antragsstellername" -Format des Antragstellernamens muss "Allgemeiner Name" eingetragen werden.
-Unter "Sicherheit" muss dem Computerkonto das Recht gegeben werden, ein Zertifikat basierend auf der eben erstellten Vorlage anzufordern

 

Jetzt muss die Vorlage als "Auszustellende Vorlage" markiert werden

 

3.2.3 Zertifikat beantragen (RemoteRechner)

Detaillierter beschrieben habe ich diesen Vorgang im Kapitel 2.5 PSSkripte signieren

In der MMC mit dem SnapIn "Zertifikate (Lokaler Computer)" unter "Eigene Zertifikate" -> "Zertifikate" werden alle Computerzertifikate des Zertifikatstores aufgelistet.

3.2.4 Untersuchen des erstellten Zertifikats

Das Zertifikat kann man mit Doppelklick öffnen und die Eigenschaften untersuchen.
- Der Name des Antragstellers muss auf den korrekten CommonName des Rechners lauten. Dies ist der Grund, weshalb bei einer SSL-Verbindung keine IP-Adressen oder Kurznamen erlaubt sind, sondern nur Verbindungen mit dem CN-Namen akzeptiert werden.
- Der Fingerabdruck des Zertifikats kann später helfen, das ausgewählte Zertifikat in der Registry zu identifizieren


 

3.2.5 Listener konfigurieren (RemoteRechner)

Sind die Vorbereitungen soweit abgeschlossen, lassen sich ein oder mehr Listener des WinRM mit einfachen Powershellbefehlen konfigurieren:


Beispiel 1: SSL-Listener für alle IPs auf Port 5986 setzen

Set-WsmanQuickConfig -usessl -force

#Ausgabe (abhängig, was schon konfiguriert wurde)

WinRM ist bereits zum Empfangen von Anforderungen auf diesem Computer konfiguriert.
WinRM wurde für die Remoteverwaltung aktualisiert.
Auf HTTPS://* wurde ein WinRM-Listener erstellt, um die WS-Verwaltungsanforderungen an eine beliebige IP-Adresse auf diesem Computer zu akzeptieren.
Die CertificateThumbprint-Einstellung für den Dienst wurde konfiguriert.

 

Beispiel 2: SSL-Listener für eine IP auf Port 5986 setzen

winrm create winrm/config/Listener?Address=IP:192.168.178.2+Transport=HTTPS
#Ausgabe
ResourceCreated
    Address = schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous
    ReferenceParameters
        ResourceURI = schemas.microsoft.com/wbem/wsman/1/config/listener
        SelectorSet
            Selector: Address = IP:192.168.178.2, Transport = HTTPS

Der Registrykey "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Listener" sollte sich, wie in Kapitel 1.2 beschrieben, verändert haben.


Beispiel 3: weitere Konfigurationsmöglichkeiten des winrm

  • Get-Help winrm
  • New-WSManSessionOption

Der WinRM Dienst ist jetzt bereit, eine SSL-gesicherte Remoteverbindung auf Port 5986 zu akzeptieren, sofern keine Firewall den Zugriff auf den WinRM Dienst verhindert.
 

3.2.6 new-pssession <Clientname> -usessl

Sind alle Voraussetzungen geschaffen, so kann nun von einem lokalen Client eine SSL-gesicherte Powershellsitzung erstellt werden:

Beispiel 1: Einrichten, Benutzen und Beenden einer SSL-RemoteSession

Einrichten

New-PsSession dom1win7.dom1.intern

#Ausgabe

Id Name            ComputerName    State    ConfigurationName     Availability
 -- ----            ------------    -----    -----------------     ------------
  1 Session1        dom1win7.dom... Opened   Microsoft.PowerShell     Available

 

Benutzen

enter-pssession 1
[dom1win7.dom1.intern]: PS C:\Users\test1.DOM1\Documents> hostname

#Ausgabe

Dom1Win7

 

Beenden

exit-pssession


Entfernen

Remove-PsSession dom1win7

Bis auf den Parameter -usessl besteht kein Unterschied im Handling zum Arbeiten ohne SSL, wie in Kapitel 2 "Remote Session ohne SSL" beschrieben.