Hinter den 7 Bergen bei den 7 Zwergen: PowerShell von ganz weit weg

Eigentlich ein alter Hut. Aber ich musste mich im Rahmen eines Projektes mit Remote-PowerShell beschäftigen und stieß dabei auf einige Probleme:

Prinzipiell braucht man Windows 7 und höher oder Windows 2008 und höher um mit Remote PowerShell arbeiten zu können. Für Exchange muss dann außerdem noch der Remote-User entsprechend berechtigt werden, damit er den Exchange Server von Remote administrieren darf:

set-user jan.geisbauer -RemotePowerShellEnabled $true

Am einfachsten nimmt man daraufhin den Weg der Piraten und entert eine Session:

Enter-PSSession -ConnectionURI http://CAS-Server/PowerShell -Credentials $C -Authentication Kerberos (-SessionOption $SO)

Das funktioniert innerhalb einer Domain (Client und Remote Computer sind in der selben Domain) sehr gut. Ist aber der Client nicht in der selben Domain wie der Server, fangen die Probleme an:

Für die Authentication kann man entweder "Kerberos" oder "Basic" wählen.

Basic

Wählt man "Basic" und gibt die ConnectionURI mit http statt mit https an, bekommt man den dezenten Hinweis, dass "unencrypted traffic" nicht erlaubt sei und man dies erst konfigurieren müsse. Gibt man die URI mit https an, lauern andere Probleme: Per default will die PowerShell die Certificate Revocation List (CRL) des dabei verwendeten Zertifikats überprüfen. Das schlägt oft fehl, weil das über Domain (Forest) Grenzen hinweg nicht sauber gepublished ist oder ein Proxy einem in die Suppe spuckt. Entweder man überwindet also diese Hürden oder man schaltet den CRL Check aus:

$SO = New-PSSessionOption -SkipRevocationCheck

(Man kann sich die anderen Optionen dieses Cmdlets genauer ansehen und findet ggf. noch weitere "Skips")

Kerberos

Kerberos wirft eine Fehlermeldung "No Logon Servers Available" wenn man versucht von einem nicht-domain Client aus der Ferne auf eine PowerShell Session zuzugreifen. Um diesen nicht vertrauenswürdigen Clients den Remote-Zugriff zu erlauben, muss man sie als "Trusted Hosts" konfigurieren:

set-item WSMan:\localhost\Cient\TrustedHosts -value ComputerName

So klappt dann der Remote-Zugriff mit Kerberos Authentifizierung.

Ansonsten müssen natürlich die entsprechenden Netzwerk Ports offen sein und die Verbindung stehen. Für die Kerberos Authentication braucht man schonmal Port 88 (TCP/UDP) und vermutlich auch 389 (LDAP). Außerdem muss die DNS Name Resolution durchgehen (Port 53) und die PowerShell braucht für die eigentliche Arbeit auf dem IIS Port 443 oder 80.

In meinen Test reichte es nicht auf den beiden Systemen mit Hosts File Einträgen der jeweils anderen Domain zu arbeiten. Vermutlich braucht man die Möglichkeit SRV Records aufzulösen. Ich habe mir dann Conditional Forwarder für die jeweils andere Domain eingerichtet.