Authentifizierung und Verarbeitung von Credentials in PowerShell


    Tags: ,

    PowerShell-Cmdlets ermöglichen für Zugriffe über das Netzwerk verschiedene Formen der Authenti­fizierung. Neben Kerberos, das standardmäßig für die Anmeldung an eine Domäne verwendet wird, ist die Authentifizierung über Benutzername und Kennwort die gebräuchlichste Form der Authenti­fizierung (der Standard­wert für den Authentication-Parameter, den es bei 18 der insgesamt 236 Cmdlets gibt, lautet „Default“).

    Bei allen auf WS-Management basierenden Cmdlets wie Invoke-Command oder New-PsSession ist über den CertificateThumbprint-Parameter auch eine Authentifizierung über ein Zertifikat möglich (allerdings kann dieses Zertifikat nur einem lokalen Benutzerkonto zugeordnet werden, was die Bedeutung dieser Authenti­fizierungs­varianten deutlich einschränkt).

    Trotz dieser Variantenauswahl, die zentrale Form der Authentifizierung geschieht über den Credential-Parameter, dem ein Paar aus Benutzername und Kennwort in Gestalt eines PSCredential-Objekts übergeben werden. Wer mit der PowerShell am Anfang steht, dem wird eine kleine Unstimmigkeit, die mit diesem Parameter einhergeht, zunächst nicht auffallen.

    Credential-Parameter erwartet PSCredential-Objekt

    Folgt auf den Credential-Parameter nur ein Benutzername, erscheint automatisch ein Anmeldedialog, in dem das fehlende Kennwort eingegeben wird. Aus Benutzername und Kennwort wird danach ein PSCredential-Objekt gebildet.

    Die erwähnte kleine Unstimmigkeit resultiert aus dem Umstand, dass der Credential-Parameter offiziell immer ein PSCredential-Objekt als Parameterwert erwartet. Als eine Art Eingabeerleichterung akzeptiert der Parameter aber auch einen String.

    Erzeugung von PSCredential-Objekten

    Es gibt zwei Möglichkeiten, an ein solches PSCredential-Objekt zu kommen: Über das Get-Credential-Cmdlet und über das New-Object-Cmdlet. Im ersten Fall werden Benutzername und Kennwort abgefragt, im zweiten Fall wird das Objekt angelegt, ohne dass eine Eingabe erforderlich ist.

    Einen kleinen Haken gibt es aber auch hier. Das Kennwort muss als SecureString-Wert übergeben werden. Der Aufruf lautet daher:

    $Cred = New-Object System.Management.Automation.PSCredential $UserName, $Pw

    Erstellen eines SecureString

    $Pw ist die Variable, die den SecureString enthält. Doch wie kommt man einen SecureString? Auch dafür gibt es mehrere Möglichkeiten, genauer gesagt sind es drei:

    1. Über das Read-Host-Cmdlet mit dem AsSecure-Parameter. In diesem Fall muss das Kennwort über die Tastatur eingegeben werden.
    2. Über das ConvertTo-SecureString-Cmdlet und seinen Parametern String, AsPlainText und Force. In diesem Fall liegt das Kennwort im Skript als Klartext vor, was nicht immer optimal ist (wenngleich dieser Umstand bei temporären Kennwörtern auch kein allzu großes Sicherheitsrisiko darstellt).
    3. In dem man das Kennwort einmal über Variante 1 entgegennimmt und es per ConvertFrom-Secure-String-Cmdlet in eine Textform konvertiert, die dann per Set-Content in eine Datei gespeichert wird. Diese Datei wird danach jedes Mal über Get-Content eingelesen und per ConvertTo-SecureString in einen SecureString konvertiert.

    Ein kleiner Tipp zum Schluss. Bei einem PSCredential-Objekt gibt es die unscheinbare Methode GetNeworkCredential(). Sie liefert ein Objekt, dessen Password-Property das Kennwort im Klartext enthält. Soviel zum Thema Sicherheit bei Kennwörtern.

    Eine echte Sicherheitslücke ist es jedoch nicht, denn der SecureString kann ohnehin nur vom dem Benutzer wieder entschlüsselt werden, der den String ursprünglich verschlüsselt hat und das auch nur auf dem Computer, auf dem der String verschlüsselt wurde, da bei der Verschlüsselung sowohl die SID des Benutzers als auch des Computers verwendet werden.

    Täglich Know-how für IT-Pros mit unserem Newsletter

    Wir ver­wenden Ihre Mail-Adresse nur für den Ver­sand der News­letter.
    Es erfolgt keine per­sonen­be­zogene Auswertung.

    Bild von Peter Monadjemi

    Peter Monadjemi lebt als freier IT-Journalist, Buchautor und Trainer mit Schwerpunkten PowerShell und .NET-Programmierung in Esslingen am Neckar.

     

    Verwandte Beiträge

    Weitere Links