Kennwörter sicher speichern und abfragen mit Powershell

Vermutlich hat es sich inzwischen herumgesprochen, dass in Skripten (egal ob Powershell, Python, Batch oder welche Sprache auch immer) keine Kennwörter im Klartext abgespeichert sein sollen. Das ist alles ganz schön, aber wie soll man dann Kennwörter und Anmeldeinformationen speichern? In Powershell gibt es hierfür einige Möglichkeiten. In diesem Artikel möchte ich alle vorstellen, die ich kenne. Falls Sie noch andere kennen, wäre ich für einen Hinweis dankbar.

Secure Strings exportieren 

Die vermutlich einfachste Variante ist es, einen Secure String zu exportieren. Ein Secure String ist die Standard-Variante, um in Powershell Kennwörter zu speichern. Es ist nichts anderes, als ein per DPAPI verschüsselter Text. Exportieren Sie den String mit dem Commandlet Export-CliXml. CliXml steht für ClientXml und ist ein Format, das explizit zum Exportieren von Powershell-Objekten ins Dateisystem geschaffen wurde.

ConvertTo-SecureString -String 'Passw0rd' -AsPlainText -Force | Export-Clixml -Path c:\Creds\Password.xml 

Der Inhalt der Datei sieht dann so aus:

<Objs Version="1.1.0.1" xmlns="http://schemas.microsoft.com/powershell/2004/04">
  <SS>01000000d08c9ddf0115d1118c7a00c04fc297eb0100000061a7c5b155d749418addbd5ddf54c96b0000000002000000000010660000000100002000000036450867348a0a6ebee8431b504ae4bdf245252671f33d6cada09ef98f764085000000000e8000000002000020000000abced04e8eaed3d6551af2dc57b36a8396e998eca2b1f23153c2e680c954b80920000000f748148ecf8c8046ad896cf2edaa6f454fa1ec526bbe6ee4c5ef289cef0ee4e3400000000b17ae8643d32baeebe62b4b63b3a3c6127df7323bc761059b4927e7c5043c77a16e3df937fe949b9b466633bbf92f97807efd553358566678cabfaed270fcd8</SS>
</Objs> 

Powershell hat den Secure String genauso exportiert, wie er im Arbeitsspeicher steht - verschlüsselt. Der verschlüsselte String steht im <ss>-Tag und kann nur von dem Benutzer importiert werden, der ihn auch exportiert hat, da nur er im Besitz des Masterkeys ist, der den Schlüssel wieder entschlüsseln kann. Dafür verwenden Sie einfach das Cmdlet Import-CliXml.

Meistens benötigen Sie aber nicht nur einen verschlüsselten String, sondern Anmeldeinformationen (Credentials) in Form eines PSCredential-Objekts. Das können Sie genauso einfach exportieren, indem Sie das Cmdlet Get-Credential verwenden. Das PSCredential-Objekt verfügt auch über eine Methode, um das Kennwort wieder zu entschlüsseln - GetNetworkCredential().

Get-Credential | Export-CliXml -Path C:\Cred\AdminCred.xml

# und importieren

$Credential = Import-CliXml -Path C:\Cred\AdminCred.xml
$Credential.GetNetworkCredential() 

Kennwörter asymmetrisch (mit Zertifikat) verschlüsseln

Die Verschlüsselung per DPAPI ist sehr simpel, hat aber einen Haken - sie ist nicht transportabel, sondern an den Benutzer gebunden, der das Kennwort als Secure String erzeugt hat. Wenn das verschlüsselte Kennwort von verschiedenen Benutzerkonten aus entschlüsselbar sein muß, können Sie stattdessen mit asymmetrischer (Public-Private-Key) Verschlüsselung in Form von Zertifikaten arbeiten. 

Für die asymmetrische Verschlüsselung wird ein Verschlüsselungsverfahren Namens RSA benutzt. Es verwendet zwei Schlüssel für die Verschlüsselung von Daten - einen Schlüssel zum Ver- und einen zum Entschlüsseln. Der Clou ist, dass Daten, die mit einem der beiden Schlüssel codiert wurden, nur mit dem jeweils anderen Schlüssel entschlüsselt werden können. Gängigerweise wird einer der beiden Schlüssel öffentlich gemacht und in ein Zertifikat verpackt, das den Besitzer des Schlüssels ausweist, sowie ein Ablaufdatum und einen Verwendungszweck. Da Daten, die mit einem Schlüssel verschlüsselt wurden, nur mit dem jeweils komplementären Schlüssel wieder entschlüsselt werden können, kann jeder, der im Besitz des Zertifikats ist, Daten verschlüsseln - nur der Besitzer der privaten Schlüssels kann die Daten wieder decodieren. Mehr zur Funktionsweise der asymmetrischen Verschlüsselung finden Sie in der Wikipedia.

Zertifikate werden von Zertifizierungsstellen (Certificate Authority oder CA) ausgestellt. Man reicht dafür einen öffentlichen Schlüssel bei einer CA in Form einer Zertifikatsanforderung (Certficate Request) ein und erhält nach einer Prüfung der Richtigkeit der Daten einen zertifizierten Schlüssel zurück. Beachten Sie - der private Schlüssel wird nicht eingereicht, er bleibt die ganze Zeit bei Ihnen. 

Der Sinn des Zertifikates ist es, den Besitzer eindeutig identifizieren und Daten über die Schlüssel speichern zu können. Mit ihm kann man die Gültigkeit eines öffentlichen Schlüssels prüfen. Wenn Sie aber gerade keine Zertifizierungsstelle zur Hand haben, können Sie sich ein Schlüsselpaar mit Zertifikat auch mit Powershell selber generieren. Der einzige Haken ist, dass das Zertifikat nur auf dem Rechner vertrauenswürdig ist, auf dem Sie es erzeugt haben, sowie auf allen Maschinen, auf denen Sie es importiert haben. Sie verwenden hierfür das Cmdlet New-SelfsignedCertificate.

# Die Parameter für das Cmdlet in einer Hash-Table definieren. 
# Das passiert nur aus kosmetischen Gründen
$CertParam = @{
    Subject = 'MyEncryptionCertificate' 
    KeyUsage = 'KeyEncipherment','DataEncipherment' 
    CertStoreLocation = 'Cert:\CurrentUser\My' 
    FriendlyName = 'Encryption' 
    Type = 'DocumentEncryptionCert'
}

# Erstellen des Schlüsselpaars und des Zertifikats
$EncryptionCert = New-SelfSignedCertificate @CertParam 

Das Zertifikat braucht die Verwendungszwecke 'KeyEncipherment' und 'DataEncipherment' sowie den erweiterten Verwendungszweck 'DocumentEncryption', um zur Verschlüsselung von Daten verwendet werden zu dürfen. Sie legen Sie über die Parameter Keyusage und Type fest. Die Certstorelocation legt fest, wo das Zertifikat gespeichert werden soll - in diesem Fall für den Benutzer, der das Cmdlet aufgerufen hat. Außerdem braucht das Zertifikat verpflichtend ein Subject. Der Friendlyname ist optional, hilft aber, das Zertifikat besser zuordnen zu können. Die Parameter werden hier über eine Hash-Table zugewiesen, um den Code nicht in eine Zeile schreiben zu müssen. Das Feature wird auch als Splatting bezeichnet - achten Sie darauf, dass Sie die Hashtable nicht mit $CertParam angeben, sondern mit @CertParam. Alternativ können Sie die Parameter auch hintereinander weg hinter New-SelfsignedCertificate schreiben:

New-SelfsignedCertificate -Subject 'MyCert' -Keyusage 'KeyEncipherment' ...
 

Nachdem Sie das Zertifikat erstellt haben, können Sie zum Ver- und Entschlüsseln von Daten die Cmdlet Protect-CmsMessage und Unprotect-CmsMessage verwenden.

$SecureMessage = Protect-CmsMessage -Content $Password -To $EncryptionCert
Unprotect-CmsMessage -Content $SecureMessage -To $EncryptionCert 

Sie können das Zertifikat mit privatem Schlüssel jetzt exportieren, um es auf anderen Maschinen wieder zu importieren. Sie verwenden hierfür das pkcs #12-Format. Es ist verschlüsselt und benötigt ein Kennwort in Form eines Secure Strings

$Password = ConvertTo-SecureString -String 'Passw0rd' -AsPlainText -Force
$EncryptionCert | Export-PfxCertificate -Password 'Geheim' -FilePath C:\creds\PPKeys.pfx  

Ab Windows Server 2012 / Windows 8 können Sie die .pfx-Datei auch schützen, indem Sie Benutzerkonten angeben, die die Datei öffnen dürfen. Das vereinfacht in einer Domänenumgebung den Import, weil Sie auf das Kennwort verzichten können, dass Sie ja wieder selbst verschlüsseln müßten. Import-PfxCertificate kann das für Sie erledigen.

# Verwenden Sie statt eines Kennworts den Parameter -ProtectTo
# Die können mehrere Benutzer und auch Gruppen angeben
$EncryptionCert | Export-PfxCertificate -ProtectTo 'NetzWeise\PowershellScripter' -FilePath C:\Temp\PPKeys.pfx

# Auf dem Zielrechner mit einem Benutzer, der in -ProtectTo angegeben wurde
Import-PfxCertificate -CertStoreLocation Cert:\CurrentUser\My\ -FilePath C:\temp\PPKeys.pfx 

Zuguterletzt ein Hinweis - wenn Sie das pkcs #12-File nur über Berechtigungen sichern, verwendet Windows im Hintergrund - die DPAPI. Sie müssen sich also wieder auf die Sicherheit dieses Mechanismus verlassen, und der hängt auch davon ab, wie sicher Ihre Domäne ist.

Credential Manager und Credential Vault  als Kennwortspeicher

Windows bietet zwei integrierte Kennwort-Safes an, die Sie zum sicheren Ablegen von Kennwörtern verwenden können - den Credential Locker und seit Windows 8 außerdem den Credential Vault. Im Gegensatz zum Credential Locker kann das Credential Vault den Zugriff für Apps selektiv speichern - sie können also einer App das Speichern von Kennwörtern im Vault erlauben, aber festlegen, dass die App aus dem Vault nur Ihre eigenen Kennwörter abrufen kann. So eine Anwendungsspezifische Steuerung ist mit dem Credential Locker nicht möglich - jede Anwendung, die in Ihrem Benutzerkontext läuft, kann immer alle Anmeldeinformationen abrufen. Während der Credential Vault alle Kennwörter einzeln im Dateisystem speichert, verwaltet das Credential Vault mehre Kennwörter in einer einzelnen Datei. Die Anmeldeinformationsverwaltung, also die GUI, mit der man die Kennwörter verwalten kann, kann dabei auf beide Speicher zugreifen. Außerdem können Sie mit den Tool cmdkey.exe den Credential Locker auch von der Kommandozeile verwenden. Für den Credential-Vault steht Ihnen VaultCmd.exe zur Verfügung.

Credential Locker 

Wenn Sie Kennwörter im Credential Locker ablegen wollen, verwenden Sie am einfachsten das Powershell-Modul CredentialManager aus der Powershell-Gallery, da der Zugriff auch über das .NET-Framework nicht trivial ist. Das Modul macht den Zugriff einfach, denn es hat nur 4 Cmdlets und bildet die Funktionalität von cmdkey.exe in Powershell ab.

Get-StrongPassword hat zwei Parameter, -Length und -NumberOfSpeicalCharacter, über die Eigenschaften des Kennworts generien kann. Es liefert einen String zurück. 

New-StoredCredential speichert Credentials in Credential-Manager. Es ist relativ komplex und hat eine Reihe von nichtssagenden Parametern, deren Namen sich aus den Parametern von cmdkey.exe ergeben. 

• Target: Der Computer, für den die Anmeldeinformationen gelten. Wird eine Verbindung mit dem Target hergestellt, werden automatisch die hinterlegten Anmeldeinformationen verwendet. 
• Username: Der Benutzername, der gespeichert werden soll
• Password: Das Kennwort, das gespeichert werden soll, im Klartext
• SecurePassword: Das Kennwort, das gespeichert werden soll, als Secure String (alternativ zum Klartext-Kennwort)
• Credentials: Statt Benutzername und Kennwort kann auch ein PSCredential-Objekt übergeben werden, wie es z.B. Get-Credential erzeugt
  
• Type: Die Art des Kennworts - z.B. DomainPassword oder Generic. Unterstützt werden Generic, DomainPassord und DomainCertifcate. Alle anderen angebotenen Typen werden von Windows nicht mehr unterstützt
• Persist: Legt fest, ob die Anmeldedaten nur während der aktuellen Anmeldung (Session), dauerthaft auf dem gleichen Rechner für alle Sitzungen des Benutzers (LocalMachine) oder auch auf anderen Rechnern der Domäne (Enterprise) sichtbar sein sollen. Wird Enterprise ausgewählt, muß der Benutzer über ein servergespeichertes Profil verfügen, da der Parameter letztlich nur festlegt, ob die Anmeldeinformationen unter $home\AppData\Local\Microsoft\Credentials (LocalMachine) oder unter $home\AppData\Roaming\Microsoft\Credentials (Enterprise) gespeichert werden.

Get-StrongPassword -Length 12 -NumberOfSpecialCharacters 3

# Ein Generisches Credential 
$Cred = Get-Credential
New-StoredCredential -Credentials $Cred -Comment "Generische Daten" -Persist LocalMachine

# Anmeldeinformationen für Server1.netz-weise.de als Domäneninformationen hinterlegen. Wird eine Verbindung zum Zielsystem per NTLM, 
# Kerberos oder als aushandelbares Auth. hergestellt, werden automatisch die hinterlegten Anmeldeinformationen verwendet. 
# -Persist Enterprise speichert die Daten im Raomind-Teil es Profils.
New-StoredCredential -Target Server1.netz-weise.de -UserName netz-weise\hans -Password $Password -Type DomainPassword -Persist Enterprise 

Wenn Sie Anmeldeinformationen zum späteren Abrufen aus einem Powershell-Skript speichern wollen, verwenden Sie am Besten generische Anmeldeinformationen. Da die Anmeldeinformationen auch nicht zum automatischen Verbinden genutzt werden sollen, brauchen Sie auch kein Target angeben. Zum Abrufen nutzen Sie Get-StoredCredential. Achten Sie darauf, dass Get-StoredCredential nur nach dem Target filtern kann. Um einen spezifischen Account zu finden, müssen Sie die Ausgabe mit Where-Object filtern. Als Ergebnis erhalten Sie ein Credential-Objekt zurück. Das Löschen mit Remove-Credential ist leicht Buggy und funktioniert nur, wenn für das Credential ein Target angegeben wurde. Da Remove-Credential auch nicht Pipelinefähig ist, müssen Sie zudem Foreach-Object benutzen. 

New-StoredCredential -UserName Netz-weise\PoshGeneric -Password "Passw0rd" -Comment "Powershell Generic" -Persist LocalMachine
# Abfragen des Credentials mit Get-StoredCredential
$Cred = Get-StoredCredential -Type Generic | 
    Where-Object -FilterScript { $_.username -eq "netz-weise\PoshGeneric"  }

# Und löschen - durch die Brust ins Auge    
Get-StoredCredential -Type Generic | 
    Where-Object -FilterScript { $_.username -eq "netz-weise\PoshGeneric"  } |
    Foreach-Object -Process  { Remove-StoredCredential -Target $_.Target } 

Der Vorteil des Credential Locker liegt darin, dass Sie unterschiedliche Anmeldeinformationen an einer Stelle hinterlegen können. Wenn Sie ein Target angeben, kann die Verbindung außerdem automatisch ohne vorherigen Abruf des Credentials stattfinden. Außerdem können die Credential über mehrere Rechner synchronisiert werden, wenn Sie servergespeicherte Profile verwenden.

Links:

cmdkey Verwendung

CredentialFileView von nirsoft mit Hintergrund zum Credential-Locker

CREDENTIALA structure (Objektbeschreibung des Credential-Objekts im Credential Locker, beschreibt viele Optionen)

Credential Vault 

Das Credential Vault funktioniert ähnlich wie der Credential Locker, speichert aber alle Anmeldeinformationen in einer Datei, anstatt für jede Anmeldeinformation eine eigene Datei abzulegen. Außerdem kann das Credential Vault Anwendungsspezifisch speichern und ist relativ einfach per .Net aufzurufen, so dass ein Extra-Modul nicht notwendig ist. Man spart sich also im Zweifel eine Extra-Abhängigkeit im Skript. Da es sich um eine Windows-Runtime-Klasse handelt, müssen Sie sie vorher laden.

Legen Sie Initial eine neue Instanz des Typs Windows.Security.Credentials.PasswordVault an. Das Objekt stellt Ihnen anschließend Methoden zur Verfügung, um das Vault zu bearbeiten. Die relevanten Methoden sind Retrieve(), RetrieveAll(), FindAllByResource(), FindAllByUserName(), Add() und Remove().

# Laden der Windows Runtime Klasse
[Windows.Security.Credentials.PasswordVault,Windows.Security.Credentials,ContentType=WindowsRuntime]
$Vault = New-Object Windows.Security.Credentials.PasswordVault

# Alle Anmeldeinformationen abrufen
$Vault.RetrieveAll()

# Das Vault verwaltet keine Powershell- sondern Password-Credentials. Es muß also immer erst ein Password-Credential 
# erzeugt werden, dass dann dem Vault hinzugefügt werden kann. Der Konstruktor hat 3 Parameter: Resource (Anwendung),
# Username und password. Das Passwort wird dabei als Klartext übergeben. Anschließend kann das Password-Credential
# der add()-Methode als Argument übergeben werden.
$Cred = Get-Credential
$Cred = new-object -Type Windows.Security.Credentials.PasswordCredential -ArgumentList 'Powershell','Holger','Passw0rd'
$Vault.Add($Cred)

# Neben Retrieve kann man auch nach einzelnen Anmeldeinformationen suchen:
$Vault.FindAllByUserName('Holger')
$Vault.FindAllByResource('Powershell')

# Zum Entfernen muß wieder ein Password-Credential-Objekt übergeben werden
$Vault.Remove($Cred) 

Grundsätzlich ist der Umgang mit dem Credential Vault meiner Meinung nach vorzuziehen, da er einfach ist und kein zusätzliches Modul benötigt. Voraussetzung ist mindestens Windows 8 / Server 2012. Egal ob Sie Credential Vault oder Credential Locker verwenden - in jedem Fall arbeitet auch hier im Hintergrund wieder die Microsoft DPAPI. Auch das Credential Vault kann man übrigens mit Vaultcmd.exe auch direkt über die Kommandozeile steuern.

Links:

VauldPasswordView von nirsoft mit Hintergrund zum Credential Vault

Password Vault Klasse

Password Vault Modul in der Powershell Gallery

Alternatives Password Vault Modul bei Github

Mit Powershell Kennwörter in Password Safe speichern 

Die letzte gute Variante, mit der Kennwörter gespeichert werden können, ist das Open-Soure-Tool Keepass. 

Keepass ist ein kostenfreier Open-Source Password-Safe mit vielen Funktionen. Keepass verwaltet Anmeldeinformationen ähnlich wie das Credential Vault in Dateien oder Datenbanken. Die Datenbanken sind mit AES 256 oder ChaCha20 verschlüsselt. Bei beiden Verfahren handelt es sich um derzeit faktisch nicht knackbare symmetrische Algorithmen. Die Datenbanken können auf verschiedene Arten entschlüsselt werden, wie z.B. mit Kennwort, mit Fido-Keys, mit Schlüsseldateien oder dem angemeldeten Windows Benutzer. Die einzige Variante, die im Zusammenhang mit Powershell Sinn macht, ist natürlich die Verschlüsselung über die Benutzeranmeldung (DPAPI). Zusätzlich können Sie die Datenbank mit einer Schlüsseldatei absichern, wodurch Sie faktisch eine Multifaktor-Authentifizierung erreichen.

Um Kennwörter von Powershell aus in Keepass speichern zu können, benötigen Sie nur das PoshKeePass-Modul aus der Powershell-Gallery. Das Modul bringt alle notwendigen Keepass-Dateien in Form einer .dll mit. Um auf Nummer sicher zu gehen, können Sie die .dlls aber auch durch von Ihnen geprüfte Keepass-Dateien ersetzen. Anschließend können Sie mit dem CmdLet New-KeePassDatabase eine neue Datenbank anlegen.

Install-Module -Name PoshKeePass -Force
# Anlegen einer Datenbank, die über den Windows-Login gesichert ist
New-KeePassDatabase -DatabasePath C:\creds\posh.kdbx -UseNetworkAccount 

Wenn Sie eine Datenbank mit Schlüsseldatei erzeugen möchten, müssen Sie die GUI von KeePass bemühen. Starten Sie dafür KeePass und öffnen die neu erstellte Datenbank über "FIle > Open". Alternativ können Sie über "File > New" die Datenbank auch direkt hier erstellen. Anschließend wählen Sie "File > Chang Masterkey" und aktivieren die Checkbox "Show Expert Options". Entfernen Sie den Haken bei "Master Password", setzen Sie den Haken bei "Windows User Account" und "Key file / provider" wählen Sie den Button "Create".

Als nächstes geben Sie den Pfad für die Schlüsseldatei an. Die Schlüsseldatei enthält ein zufällig generiertes Kennwort. Um echten "Zufall" zu generieren, müssen Sie Text eingeben und die Maus über ein "White Noise"-Bild bewegen.  

Anschließend beenden Sie den Dialog mit OK und beenden den Dialog zum Ändern der Verschlüsselung ebenfalls mit OK. Keepass fragt Sie nun, ob Sie die Datenbank sichern wollen. Bestätigen Sie das ebenfalls.Sie können jetzt den Sicherheitsschlüssel drucken, mit dem Sie die Datenbank wiederherstellen können, sollten die Schlüsseldatei verloren gehen. Anschließend können Sie Keepass beenden.

Nachdem Sie eine Datenbank erstellt haben, können Sie ein Datenbankprofil erzeugen. Das Profil wird im Modul-Ordner als "KeePassConfiguration.xml" angelegt und automatisch beim Laden des Moduls eingelesen. Mit Hilfe einer Konfiguration brauchen Sie beim Erstellen oder Einlesen eines Eintrags nicht jedes mal alle Daten angeben, sondern können einfach auf die Konfiguration verweisen. 

Keepass erlaubt es außerdem, Kennwörter zu gruppieren. Mit dem Cmdlet New-KeePassGroup legen Sie Gruppen an. Gruppen verhalten sich wie Ordner und können auch Untergruppen enthalten. Die erste Ebene heißt wie der Name, den Sie Ihrer Datenbank vergeben haben - in unserem Beispiel Posh. 

# Anlegen einer Konfiguration
New-KeePassDatabaseConfiguration -DatabaseProfileName Demo -DatabasePath C:\creds\posh.kdbx -UseNetworkAccount -Default
# Wenn Sie eine Schlüsseldatei verwendet haben, geben Sie den Pfad mit "KeyPath" an
New-KeePassDatabaseConfiguration -DatabaseProfileName Demo -DatabasePath C:\creds\posh.kdbx -KeyPath C:\creds\posh.key -UseNetworkAccount -PassThru

# Anschließend können Sie auf die Konfiguration verweisen
New-KeePassGroup -DatabaseProfileName Demo -KeePassGroupName Azure -KeePassGroupParentPath Posh
# Sie können auch Icons hinterlegen, was für eine rein von Powershell genutzte DB aber wenig Sinn macht
# Notizen können aber helfen, den Überblick zu behalten
New-KeePassGroup -KeePassGroupName O365  -DatabaseProfileName Demo -KeePassGroupParentPath Posh -IconName World -Notes "Office 365 Accounts" 

Neue Einträge erzeugen Sie mit New-KeePassEntry. Achten Sie darauf, dass das KeePass-Modul als Kennwörter wie üblich nur Secure Strings übernimmt. Wenn Sie eine Gruppe angeben, verwenden Sie den / (Slash), nicht Backslash wie im Dateisystem. PoshKeePass quittiert das sonst mit einer Fehlermeldung. Zum Abrufen verwenden Sie das Cmdlet Get-KeePassEntry.

$Pw = ConvertTo-SecureString -String "Passw0rd" -AsPlainText -Force
New-KeePassEntry -KeePassEntryGroupPath posh/azure -Title "Global Admin" -UserName Admin -KeePassPassword $Pw -Notes "Mein erstes Password" -URL portal.azure.de -IconName World -DatabaseProfileName Demo

# Um alle Einträge einer Gruppe abzurufen, geben Sie beim Abruf nur den Gruppennamen an
Get-KeePassEntry -KeePassEntryGroupPath posh/Azure -DatabaseProfileName Demo

# Um einen spezifischen Eintrag zu bekommen, filtern Sie auf den Titel, den Username oder beides
# Sie können den Guppe auch auslassen.
Get-KeePassEntry -DatabaseProfileName DemoKeyFile -Title "Global Admin" -UserName Admin

# Sie können sich das Kennwort auch direkt als Klartext ausgeben lassen. 
Get-KeePassEntry -KeePassEntryGroupPath posh/Azure -DatabaseProfileName DemoKeyFile -Title "Global Admin" -UserName Admin -AsPlainText

# Wenn Sie ein PSCredential-Objekt brauchen, kann PoshKeePass Ihnen das direkt erzeugen
$cred = Get-KeePassEntry -KeePassEntryGroupPath posh/Azure -DatabaseProfileName DemoKeyFile -Title "Global Admin" -UserName Admin -AsPlainText
$cred.Credential

# Zum Löschen verwenden Sie Remove-KeePassentry mit dem -cofirm:false
Get-KeePassEntry -KeePassEntryGroupPath posh/Azure -DatabaseProfileName DemoKeyFile -Title "Global Admin" -UserName Admin | 
    Remove-KeePassEntry -Confirm:$false 

Weitere Methoden und abschließende Gedanken 

Neben den hier vorgestellen Methoden gibt es außerdem natürlich die Möglichkeit, externe Kennwort-Dienste zu verwenden, wie z.B. den Azure Key Vault. Hierfür stellt Microsoft im Azure-Modul eine Reihe von Cmdlets zur Verfügung, die den Zugriff auf Secrets (Kennwörter, private Schlüssel undd Zertifikate) in Azure sehr einfach machen. Ich will auf diese Methode aus zwei Gründen aber nicht im Detail eingehen - zum einen hat Microsoft das Selber ganz wunderbar beschrieben, zum anderen gibt es hier das Henne-Ei-Problem - der Zugriff auf den Key-Vault benötigt nämlich eine Initiale Authentifizierung, die wiederum erfordert, dass man das Kennwort des Azure-Accounts irgendwo gespeichert hat. Und hierfür benötigt man dann eine der oben beschriebenen Methoden. Das grundsätzliche Problem ist also, dass man initial immer einen Weg braucht, um den Start-Schlüssel, mit dem alle folgenden Informationen gesichert sind, abzulegen. Und egal, welche von den oben beschriebenen Methoden Ihnen am Besten zusagt, am Ende landen Sie immer wieder bei der Microsoft Data Protection API. Einzig mit KeePass haben Sie die Möglichkeit, einen zweiten Faktor in die Authentifizierung einzubringen, so dass Sie sich nicht zu 100% auf die DPAPI verlassen müssen. Denn die DPAPI ist eine Abstraktionsschicht, die die Benutzung von kryptografischen Verfahren für Benutzer und (!) Programmierer einfacher machen soll. Aber diese Abstraktion bringt auch Sicherheitsprobleme mit sich, denn sobald man Zugriff auf das Benutzerkonto bekommt, kann man sich auch den Master-Key aneignen. Wenn man Zugriff auf das AD bekommt, kann man sich sogar den Universalschlüssel aneignen, mit dem die Master-Keys aller Benutzer zu entschlüsseln sind. Sollte man deshalb die DPAPI meiden? Wohl kaum, denn wenn der Master-Key in unbefugte Hände gelangt, ist technisch gesehen eh alles hinüber, da alle anderen Sicherheitsverfahren wie z.B. Public/Private-Key-Verschlüsselung sich ebenfalls auf die DPAPI verlassen. Im Prinzip ist es also egal, welche der obigen Methoden Sie verwenden. Müssen Sie nur ein einziges Credential schützen, ist es also durchaus sinnvoll, das Objekt einfach als CliXml-Datei zu speichern. Müssen Sie viele Schlüssel verwenden, nutzen Sie den Windows Key Vault, denn der Zugriff braucht keine zusätzlichen Module oder Abhängigkeiten und ist mit dem .Net-Framework mit wenigen Zeilen Code implementiert. Wenn Sie mehr Sicherheit und Komfort wollen und Ihnen die Abhängigkeiten egal sind, verwenden Sie PoshKeePath. Den Credential Vault würde ich nicht mehr verwenden, da er ein zusätzliches Modul oder gute C#-Kenntnisse voraussetzt und keine weiteren Vorteile mit sich bringt.