Seit längerer Zeit ist das Importieren von PowerShell-Sessions von PCs gängige Praxis. Um nicht direkt auf den Exchange-Server zu müssen, kann man beispielsweise den Berechtigungen entsprechend einfach die Session importieren. Es lassen sich schließlich dieselben Befehle ausführen wie auch auf dem Server selbst.
Was aber, wenn man auf einen Rechner zugreifen muss, der nicht in derselben Domäne steht? Es gibt hierbei ein paar Hürden zu überwinden. Wie das funktioniert, möchte ich in diesem Artikel kurz aufzeigen.
Index
Trust einrichten
Zwei PCs in der derselben Domäne vertrauen sich untereinander, da sie schließlich aus derselben Domäne stammen. Somit wissen sie, wer der jeweils andere ist. Genauso funktioniert es zwischen zwei Rechnern in zwei verschiedenen Domänen, während zwischen letzteren allerdings ein Trust eingerichtet wurde. Ist das nicht der Fall, vertrauen sich die beiden Rechner auch nicht. Das heißt, im ersten Schritt muss man ein Trust zwischen ihnen herstellen.
Um die Erklärung ein wenig zu vereinfachen, nennen wir den Rechner, auf dem die PowerShell bzw. das Skript ausgeführt werden soll, Rechner A. Und die PowerShell-Session wird von Rechner B importiert. Damit ein Trust zwischen den beiden Rechnern entsteht, müssen wir Rechner B in die Liste der Trusted Hosts von Rechner A aufnehmen.
Wenn Sie ein Skript ohne Nutzerinteraktion ausführen, das die importierte Session benötigt, müssen Sie diesen Schritt – die Einrichtung des Trusts – auf jeden Fall vorher ausführen und nicht als Bestandteil des Skripts. Denn hier wird eine Nutzerinteraktion von Ihnen benötigt, die Sie aus Sicherheitsgründen nicht automatisieren können.
→ mehr zu: PowerShell Skripte mit Nutzerinteraktion
Zunächst müssen Sie wissen, wie Sie Rechner B erreichen können. Ist er dem DNS-Server bekannt, so reicht natürlich der Name. Falls nicht, dann brauchen Sie die IP-Adresse. Im Zweifelsfall können Sie auch beide bereithalten und der TrustedHosts-Liste hinzufügen. Öffnen Sie dazu Ihre PowerShell mit Administrator-Berechtigungen und geben Sie folgenden Befehl ein:
1 |
Set-Item wsman:\localhost\Client\TrustedHosts -Value "<IP-Adresse>,<Servername>" |
Wenn entweder nur die IP-Adresse oder den Namen haben, dann tragen Sie im Value-Parameter nur entsprechend den Wert ohne Komma ein. Danach sollte PowerShell sie nach einer Bestätigung fragen, die sie mit J beantworten müssen.
Anschließend können Sie mit dem Befehl
1 |
Get-Item wsman:\localhost\Client\TrustedHosts |
herausfinden, welche Einträge sich in Ihrer TrustedHosts-Liste befinden. Wenn Sie einen neuen Eintrag hinzufügen möchten, ohne die alten zu überschreiben, können Sie das dann mit folgenden Befehl tun:
1 |
Set-Item WSMan:\localhost\Client\TrustedHosts -Value "<IPAdresseOderServername>" –Concatenate |
PS-Remoting eingeschaltet?
Dies gilt zwar auch für Rechner in derselben Domäne, sollte aber auch hier überprüft werden. Auf Rechner B muss das PS-Remoting eingeschaltet sein, damit man von einem Remote-Rechner – also Rechner A – eine PS-Session importieren kann.
Öffnen Sie dazu eine PowerShell mit Administrator-Rechten auf Rechner B und geben Sie den Befehl
1 |
Enable-PSRemoting |
ein und bestätigen Sie anschließend mit Enter.
Zugangsdaten übergeben
Wenn Rechner A und B in derselben Domäne sind, reicht es aus, wenn die PowerShell bzw. das Skript mit einem Account ausgeführt werden, der in der Domäne PowerShell ausführen darf. Da das in unserem Beispiel so nicht der Fall ist, muss dem New-PSSession CmdLet zudem ein Credential übergeben werden. Dieses muss erstellt werden, bevor es übergeben werden kann.
Credential abfragen
Führen Sie die PowerShell-Befehle direkt in der Konsole aus, ist das kein Problem. Mit einem einfachen
1 |
$credential = Get-Credential |
erzeugen Sie eine Nutzerabfrage, in die Sie die entsprechenden Zugangsdaten eingeben. Das damit erzeugte Credential wird dann in der Variablen gespeichert.
Führen Sie den Befehl aber in einem nicht-interaktiven Skript aus, so bleibt das Skript an dieser Stelle natürlich hängen. Wir müssen also das Credential irgendwie automatisiert erzeugen. Die Hürde dabei ist, dass das Passwort als Secure-String benötigt wird. Den könnten Sie einfach aus einem normalen String direkt im Quelltext erzeugen. Das heißt allerdings, dass sie das Passwort im Klartext im Skript-Code hinterlegen müssten. Da dies natürlich ein enormes Sicherheitsrisiko darstellt, sollte dies vermieden werden.
Credential automatisiert erzeugen
Stattdessen können wir das Passwort relativ gut verschlüsselt hinterlegen und nach Bedarf wieder einlesen. So konvertieren Sie einen String in einen Secure-String und speichern ihn anschließend verschlüsselt in einer Datei ab:
1 2 |
$file = "C:\password.txt" "<Password>" | ConverTo-SecureString –AsPlainText –Force | ConvertFrom-SecureString | Out-File $file |
Achtung: Zwar wird das Passwort verschlüsselt abgespeichert, d.h. jemand der die Datei öffnet, kann das Passwort nicht lesen. Allerdings kann jeder mit Zugriff auf die Datei sie in sein eigenes PS-Skript einlesen und verwenden. Seien Sie sich dieses Risikos bewusst und lassen Sie die Datei niemals auf ungesicherten Rechnern liegen!
Jetzt müssen wir das Passwort wieder einlesen und können daraus dann unser Credential erzeugen. Das sieht folgendermaßen aus:
1 2 3 4 |
$username = "<Domäne>\<Nutzername>" $file = "C:\password.txt" $pw = Get-Content $file | ConvertTo-SecureString $credential = New-Object System.Management.Automation.PSCredential($username,$pw) |
Die Session importieren
Nun schließlich zum letzten Schritt, um PowerShell-Sessions von domänenfremden PCs zu importieren. Denn jetzt haben wir alles, was wir für die PS-Session von Rechner B brauchen. Mit diesem Befehl eröffnen wir eine neue Session:
1 |
$session = New-PSSession –Computername "<Rechner B>" – Credential $credential |
Jetzt können wir die gesamte Session mit einem einfachen
1 |
Import-PSSession $session |
importieren. Oder, wenn Sie etwas Ressourcenschonenderes mögen, dann können Sie trotzdem auch einzelne CmdLets in der Session von Rechner B mit Invoke-Command ausführen. So können Sie beispielsweise einen Windows-Service auf Rechner B stoppen:
1 |
Invoke-Command -ScriptBlock { Stop-Service -DisplayName $args[0]} -ArgumentList “<Service-Anzeigename>” -Session $session |
Abschließend, wenn Sie alle gewünschten Aktionen durchgeführt haben, sollten Sie die Session auch explizit wieder entfernen:
1 |
Remove-PSSession $session |
PowerShell-Sessions von domänenfremden PCs-Komplettes Skript
Zum Schluss noch einmal alle Befehle im Überblick:
Vorbereitung:
1 2 |
#Rechner A Set-Item wsman:\localhost\Client\TrustedHosts -Value "<IP-Adresse>,<Servername>" |
1 2 |
#Rechner B Enable-PSRemoting |
Wenn Sie ein nicht-interaktives Skript ausführen wollen:
1 2 3 |
#Rechner A $file = "C:\password.txt" "<Password>" | ConverTo-SecureString –AsPlainText –Force | ConvertFrom-SecureString | Out-File $file |
Die Remote-Session eröffnen und nutzen:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
#Rechner A #Bei interaktiver Nutzung $credential = Get-Credential #Bei nicht-interaktiven Skripten $username = "<Domäne>\<Nutzername>" $file = "C:\password.txt" $pw = Get-Content $file | ConvertTo-SecureString $credential = New-Object System.Management.Automation.PSCredential($username,$pw) $session = New-PSSession –Computername "<Rechner B>" – Credential $credential #Gesamte Session importieren.. Import-PSSession $session #..oder einzelne Kommandos in der Session ausführen Invoke-Command -ScriptBlock { Stop-Service -DisplayName $args[0]} -ArgumentList "<Service-Anzeigename>" -Session $session Remove-PSSession $session |
Damit können wir das Thema PowerShell-Sessions von domänenfremden PCs als abgeschlossen betrachten. Sollten Sie anschließend noch weiterführende Informationen benötigen, kontaktieren Sie uns.
FirstAttribute AG – Ihr Microsoft Consulting Partner
Wir unterstützen Sie bei AZURE Fragen
Nehmen Sie Kontakt zu uns auf, wir hören Ihnen gern zu.
1 Comment
Leave your reply.