10
Credentials verschlüsselt speichern in Powershell
Hallo,
ich möchte vom Host aus auf einer VM ein Skript starten - Hintergrund ist ein Acronis-Sicherungsjob, bei dem bestimmte Software vorher beendet werden muss.
siehe auch https://kb.acronis.com/de/node/63044
Es geht um das Skript, mit dem ein Kommando auf der VM gestartet werden soll:
Ist es möglich, die credentials irgendwie verschlüsselt abzulegen? Mir gefällt nicht, dass sie im Skript als Klartext stehen.
Grüße
lcer
ich möchte vom Host aus auf einer VM ein Skript starten - Hintergrund ist ein Acronis-Sicherungsjob, bei dem bestimmte Software vorher beendet werden muss.
siehe auch https://kb.acronis.com/de/node/63044
Es geht um das Skript, mit dem ein Kommando auf der VM gestartet werden soll:
$password = ConvertTo-SecureString 'MyPassword' -AsPlainText -Force
$credential = New-Object System.Management.Automation.PSCredential ('<VM\user>', $password)
Invoke-Command -VMName <virtual machine name> -ScriptBlock { path_to_the_bat_file_on_VM } -Credential $credentialIst es möglich, die credentials irgendwie verschlüsselt abzulegen? Mir gefällt nicht, dass sie im Skript als Klartext stehen.
Grüße
lcer
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 498205
Url: https://administrator.de/contentid/498205
Printed on: May 4, 2024 at 19:05 o'clock
10 Comments
Latest comment
Moin,
Lies dich hier mal ein:
https://www.pdq.com/blog/secure-password-with-powershell-encrypting-cred ...
Das dürfte exakt das sein, was du benötigst...
Hier werden die credantials erfragt und in einen „verschlüsselten“ String konvertiert und verwendet...
Ob das aber deutlich sicherer ist, weiß ich nicht...
Gruß
em-pie
Lies dich hier mal ein:
https://www.pdq.com/blog/secure-password-with-powershell-encrypting-cred ...
Das dürfte exakt das sein, was du benötigst...
Hier werden die credantials erfragt und in einen „verschlüsselten“ String konvertiert und verwendet...
Ob das aber deutlich sicherer ist, weiß ich nicht...
Gruß
em-pie
Hi,
Sicherer ja, aber nicht deutlich.
E.
Sicherer ja, aber nicht deutlich.
E.
Wenn beide Computer in einer Domäne sind oder in vetrauten Domänen, dann wäre es sinnvoller, das Invoke-Command gleich in einer Shell auszuführen, welche mit einem Domänenkonto gestartet wurde, das diese Aktion auf dem Zielcomputer ausführen darf.
Danke, sowas hab ich gesucht.
Das fühlt sich jedenfalls sicherer an, als wenn ich das Passwort im Klartext lese.
Wobei der folgende Teil interessant ist:
so schlecht ist das gar nicht.
lcer
Das fühlt sich jedenfalls sicherer an, als wenn ich das Passwort im Klartext lese.
Wobei der folgende Teil interessant ist:
This will not stop anybody who knows what they’re doing from decrypting your password or from reusing your encrypted password if they ever are able to compromise your login. The whole point of converting your password to a SecureString and storing it in a file is to keep it out of plain text in your scripts so that it’s not as easily discovered. It’s not foolproof, but it’s pretty good.so schlecht ist das gar nicht.
lcer
Hallo zusammen,
der Stand ist folgender:
Acronis nutzt als Context den Maschienenaccount (SERVER1$).
Daher fällt die Variante "Nutze einen Account der das auf der anderen Maschine darf" aus. Ebenso fällt die oben verlinkte "SecureString"-Variante ohne eigenen Key aus, da diese nur im gleichen Benutzerkontext entschlüsselt werden kann, in dem sie auch verschlüsselt wurde.
Möglich ist dann aber die Variante SecuireString mit eigenem Key:
Das ganze ist erklärt unter https://www.pdq.com/blog/secure-password-with-powershell-encrypting-cred ... dem zweiten Teil des Blogs auf das @em-pie hingewiesen hat.
Damit muss das AES-Key-File auf dem Server liegen. Das habe ich zwar per NTFS-Zugriffsrechte abgesichert, aber so richtig besser als ein Klartext-Passwort ist das eigentlich auch nicht.
nebenbei: Acronis nutzt invoke-command -VMName, was nur ab Server 2016 funktioniert. Ich habe (unter Server 2012R2) deshalb auf Invoke-Command -ComputerName umgestellt.
Grüße
lcer
der Stand ist folgender:
Acronis nutzt als Context den Maschienenaccount (SERVER1$).
Daher fällt die Variante "Nutze einen Account der das auf der anderen Maschine darf" aus. Ebenso fällt die oben verlinkte "SecureString"-Variante ohne eigenen Key aus, da diese nur im gleichen Benutzerkontext entschlüsselt werden kann, in dem sie auch verschlüsselt wurde.
Möglich ist dann aber die Variante SecuireString mit eigenem Key:
$User = "DOMÄNE\user"
$PasswordFile = "C:\backupskripte\etc\password.txt"
$KeyFile = "C:\backupskripte\etc\AES.key"
$key = Get-Content $KeyFile
$credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $User, (Get-Content $PasswordFile | ConvertTo-SecureString -Key $key)
Invoke-Command -ComputerName vm1 -ScriptBlock { F:\Skripte\backupstart.ps1 } -Credential $credentialDamit muss das AES-Key-File auf dem Server liegen. Das habe ich zwar per NTFS-Zugriffsrechte abgesichert, aber so richtig besser als ein Klartext-Passwort ist das eigentlich auch nicht.
nebenbei: Acronis nutzt invoke-command -VMName, was nur ab Server 2016 funktioniert. Ich habe (unter Server 2012R2) deshalb auf Invoke-Command -ComputerName umgestellt.
Grüße
lcer
Daher fällt die Variante "Nutze einen Account der das auf der anderen Maschine darf" aus. Ebenso fällt die oben verlinkte "SecureString"-Variante ohne eigenen Key aus, da diese nur im gleichen Benutzerkontext entschlüsselt werden kann, in dem sie auch verschlüsselt wurde.
Na dann verschlüssle es doch im Kontext des SYSTEM-Kontos.Zitat von @emeriks:
nee, das System-Konto von maschine1 hat keine Rechte auf Maschine2Daher fällt die Variante "Nutze einen Account der das auf der anderen Maschine darf" aus. Ebenso fällt die oben verlinkte "SecureString"-Variante ohne eigenen Key aus, da diese nur im gleichen Benutzerkontext entschlüsselt werden kann, in dem sie auch verschlüsselt wurde.
Na dann verschlüssle es doch im Kontext des SYSTEM-Kontos.Grüße
lcer
Sofern eine Domäne so könnte man das aber einrichten.
ja, will ich das denn ? Das dürfte auch nicht sicherer sein - oder doch?
Variante 1:
Passwort oder AES-Key liegen auf der Festplatte
Variante 2:
Das Systemkonto von maschine1 hat Ausführungsberechtigungen auf maschine2
Grüße
lcer
Variante 1:
Passwort oder AES-Key liegen auf der Festplatte
Variante 2:
Das Systemkonto von maschine1 hat Ausführungsberechtigungen auf maschine2
Grüße
lcer
Glaubensfrage ....
Wenn mir beides zu unsicher wäre, dann könnte ich vielleicht noch einen anderen Weg gehen.
Wenn mir beides zu unsicher wäre, dann könnte ich vielleicht noch einen anderen Weg gehen.
- Freigabe auf dem Computer 2, auf welchem diese Software beendet werden soll
- Auf dem Computer 2 läuft ein Scheduled Task mit PowerShell-Script in der Endlosschleife (mit Sleep-Pause)
- Aus Computer 1 wird bei Bedarf ein Script gestartet, welches in der Freigabe auf Computer 2 eine definierte Steuerdatei erzeugt.
- Das Script auf Computer 2 reagiert auf dieses Steuerdatei (z.B. über eine FileSystemWatcher oder über wiederholte Abfrage), führt definierte Aktion aus und liefert über eine definierte Antwortdatei in dieser Freigabe das Ergebnis.
- Script auf Computer 1 wertet die Antwortdatei aus.
