Weisheiten - der Netz-Weise Blog

In Powershell ist es oft  notwendig, einen Secure-String zu erzeugen. SecureStrings werden z.B. zum Erstellen eines AD-Benutzers verwendet, oder für alle möglichen Arten von Anmeldeinformationen. Das Geheimnis eines SecureStrings besteht darin, dass er über die Microsoft DPAPI (Data Protection API) durch das Konto des Benutzers geschützt ist, der den SecureString erzeugt hat. Dadurch kann nur er auf das Kennwort des SecureStrings zugreifen. 

Manchmal gibt es aber die Situation, in der man das Kennwort eines Securestrings gerne wieder im Klartext hätte. Als Beispiel dafür soll Read-Host herhalten, das Benutzereingaben von der Konsole liest. Ruf man Read-Host mit dem Parameter -Prompt auf, kann man den Benutzer zu einer Eingabe auffordern: 

$Password = Read-Host -Prompt "Bitte geben Sie ein Kennwort ein"

Das Kennwort wird als String in der Variablen $Password gespeichert. Leider wird das Kennwort aber bei der Eingabe im Klartext angezeigt. Das kann man über den Parameter -AsSecurestring verhindern. Dadurch wird die Eingabe in einen SecureString konvertiert und die Eingabe wird durch das * maskiert:

$Password = Read-Host -Prompt "Bitte geben Sie ein Kennwort ein" -AsSecureString
Bitte geben Sie ein Kennwort ein: ********

Ich stand am Wochenende vor der Aufgabe, unseren Fileserver zu migrieren, der auch als DHCP-Server fungiert. Anstatt alle Scopes neu anzulegen, habe ich mit Powershell eine sehr einfache Möglichkeit gefunden, alle DHCP-Scopes, Leases und Einstellungen auf einen Rutsch zu migrieren. Alles, was dafür getan werden muß, ist die DHCP-Einstellungen per 

Export-DHCPServer -File <Export.xml>

zu exportieren. Die Konfiguration wird in eine XML-Datei exportiert und kann auf dem Zielserver einfach über 

Import-DHCPServer -File <Export.xml> 

wieder importiert werden. 

Update: Eine Version mit Hilfe des .NET-Frameworks finden Sie im Artikel Sichere Kennwörter in Powershell generieren, jetzt mit dem .NET Framework

Kennwörter braucht man in Skripten an allen Ecken und Enden, speziell dann, wenn man Benutzer erstellen möchten. Bei einer größeren Anzahl von Konten kann da ein Skript ganz hilfreich sein, dass zufällige Kennwörter generiert. Das ist mit Powershell relativ einfach gemacht. Alles, was man benötigt, ist eine Funktionalität zum Erstellen von Zufallswerten und die Möglichkeit, Zahlen in Buchstaben umzuwandeln. Das Cmdlet Get-Random liefert Zufallszahlen zurück:

Get-Random -Min 10 -Max 100

Die vollständige Auflistung der Funktionen Get-Random können Sie in der Powershell-Hilfe nachlesen. Für uns interessant ist der Parameter -Inputobject, über den man Get-Random ein Array mit Werten übergeben kann, aus denen der Zielwert gewählt wird. 

$ZufallsListe = 65..90
$Zufallszahl = Get-Random -InputObject $Zufallsliste

Powershell stellt mit den Validate-Schlüsselwörtern eine großartige Möglichkeit zur Verfügung, Benutzereingaben in Skripten zu prüfen, und den Code dabei übersichtlich zu halten. Hierfür stehen diverse [Validate]-Attribute zur Verfügung. Folgendes Beispiel prüft z.B. ob ein Parameter sich innerhalb eines bestimmten Wertebereichs befindet:

param(
   [ValidateRange(1,6)]
   [int]$Wuerfelergebnis
)

Rufen Sie den Parameter jetzt z.B. mit 7 auf, erhalten Sie folgende Meldung und das Skript bricht ab:

test : Das Argument für den Parameter "Wuerfelergebnis" kann nicht überprüft werden. Das 7-Argument ist größer als der maximal zulässige Bereich von 6. Geben Sie ein Argument an, das kleiner oder gleich 6
ist, und führen Sie dann den Befehl erneut aus.

Es gibt eine ganze Reihe von Validierungs-Attributen. Eine vollständige Auflistung finden Sie, wenn Sie in der Powershell 

Im letzten Tipp habe ich gezeigt, wie man Zertifikate mit Powershell Base64-kodiert aus dem Zertifikatsspeicher exportieren kann. Wenn man versucht, mit dem Cmdlet Export-Certificate eine pfx-Datei zu erstellen, - die pfx-Datei ist ein Container, der neben dem Zertifikat auch den privaten Schlüssel enthält und tatsächlich eigentlich das PKCS #12-Formate enthält - stellt man allerdings fest, dass das Cmdlet dazu nicht in der Lage ist. Tatsächlich ist es aber kein Problem - man muß nur das richtige Cmdlet verwenden. Denn zum Export als .pfx-Datei verwendet man Export-PFXCertificate. Die Datei muß allerdings mit einem Kennwort gesichert werden, um den privaten Schlüssel zu  sichern:

$pwd = ConvertTo-SecureString -String "geheim" -AsPlainText -Force

Get-ChildItem -Path Cert:\CurrentUser\My\ | Where-Object { $_.subject -eq "cn=NWCertRoot" } |

    Export-PfxCertificate -FilePath $home\NwcertRoot.pfx -Password $pwd 

Mit Powershell auf den Zertifikatsspeicher zurückzugreifen, ist sehr simpel, denn Powershell stellt für den Zugriff auf Zertifikate einen Powershell-Provider bereit. Durch den Provider ist es möglich, Zertifikate wie Dateien zu behandeln. Der Provider legt hierfür ein "Laufwerk" mit Namen Cert: an. Möchten Sie z.B. die Zertifikate des aktuellen Benutzers sehen, geben Sie ein:

PS C:\Users\Holger> Get-ChildItem -Path Cert:\CurrentUser\My\

PSParentPath: Microsoft.PowerShell.Security\Certificate::CurrentUser\My

Thumbprint                               Subject
----------                               -------
A83FA591D2D909D7465768ED4F7DE4019026F74D CN=Holger
7154EBF108BEB11587B1136B06EC5C24E3E6CAEA CN=NWCertRoot
6C0CEA5EC15CA5E6350CB9E7D02D90C9AA1DEBE3 CN=NwClientCert

Zurückgeliefert wird der eindeutige Thumbprint des Zertifikats, sowie dessen Name. Um ein Zertifikat ins Dateisystem zu exportieren, verwenden Sie das Cmdlet Export-Certificate:

Manchmal steht man vor der Aufgabe, das einzelne mails aus einem Benutzerpostfach gelöscht werden sollen, z.B. weil Sie Schadcode enthalten, oder auch, weil das Postfach geleert werden soll. Mit Hilfe der Exchange-eigenen Cmdlet Search-Mailbox geht das sehr einfach.

Starten Sie die Exchange Management-Shell. Eine Anleitung der Installation der Shell finden Sie im Artikel "Exchange Cmdlet in Powershell nutzen". Achten Sie darauf, dass Sie das Cmdlet "Search-Mailbox" nicht sehen, solange Sie nicht Mitglieder der Rolle "Mailbox Import Export" sind - das gilt sogar dann, wenn Sie als Organisationsadministrator angemeldet sind. Alternativ können Sie das Problem auch umgehen, indem Sie die Exchange-Snapins direkt importieren. 

Anschliessend rufen Sie das Cmdlet Search-Mailbox auf. Der Parameter Identity gibt dabei an, welche Mailbox(en) Sie suchen. Alternativ können Sie die Mailboxen auch per Pipeline an Search-Mailbox übergeben. Mit Hilfe des Parameters -Searchquery geben Sie an, welche Nachrichten gesucht werden. Das Cmdlet verwendet für die Definition der Suchabfragen die KQL (Keyword Query Language). Ein einfaches Beispiel für eine Suche nach dem Begriff "Verrat" in allen mails aller mailboxen sieht so aus: 

Get-Mailbox | Search-Mailbox -SearchQuery 'Verrat' -TargetMailbox 'Administrator' -TargetFolder 'NSA' 

Wenn Sie Exchange 2013 oder 2016 per Powershell remote administrieren wollen, ohne sich auf den Exchange-Server per Powershell Remoting zu verbinden, oder wenn Sie Scripte von einer Management-Maschine aus starten wollen, brauchen Sie die Exchange-Snapins. Diese müssen Sie von den Exchange-Quellen nachinstallieren. Um die Installation starten zu können, müssen Sie allerdings eine Reihe von Software-Komponenten installiert haben. Am einfachsten geht dies über den Powershell-Befehl "Enable-WindowsoptionalFeature" auf dem Client bzw. Install-WindowsFeature auf dem Server:

Enable-WindowsOptionalFeature -Name IIS-WebServerRolead,IIS-WebServerManagementTools,IIS-IIS6ManagementCompatibility,IIS-Metabase,IIS-ManagementConsole,IIS-LegacySnapIn

Danach können Sie (für Exchange 2013) einfach über das Setup die automatisiert Installation der Exchange Management-Shell aufrufen:

Setup.exe /Role:ManagementTools /IAcceptExchangeServerLicenseTerms

Für die Installation können Sie einfach das aktuellste Exchange CU (Cumulative Update) nutzen, da das CU die komplette Exchange-Installation beinhaltet. 

Wenn Sie ein Gruppenrichtlinienbackup erstellen, wird für jede GPO ein eigener Sicherungsordner angelegt. Der Sicherungsordner trägt allerdings nicht den Namen der GPO, sondern es wird für jede Sicherung eine eigene GUID erstellt.

Wenn Sie die Sicherung in der Domäne wiederherstellen möchten, in der Sie die Sicherung angelegt haben, ist das nicht problematisch, da die GPMC Ihnen über "Manage Backups" auf den Container "Group Policy Objects" die Details Ihrer Backups anzeigt. Wenn Sie die Backups allerdings auf eine andere Domäne übertragen wollen, fehlen Ihnen diese Informationen. Vor allem bei umfangreichen Backups hilft dann nur eine gute Dokumenation oder die folgenden beiden Funktionen, die einen Backup-Ordner einlesen und die relevanten Informationen auslesen können.

ConvertFrom-GPVersion konvertiert die 32-Bit Versionsnummern der Computer- bzw. Benutzerkonfiguration in einen dezimalen Versionswert. Sie wird von Get-GPOBackupInfoFromXML verwendet, um die korrekte Version der User-bzw. Computerkonfiguration zu berechnen. Beide Funktionen sind auch Bestandteil des aktuellen GPHelper-Powershellmoduls. 

function ConvertFrom-GPVersion

{

Leider bietet das Powershell AD-Modul keine Möglichkeit, auf das Vorhandensein einer Organizational Unit zu testen. Diese Funktion lässt sich aber einfach nachrüsten. 

Grundsätzlich kann man die Existenz einer OU testen, indem man einfach das Cmdlet Get-OrganizationalUnit verwendet. Prüft man die Abfrage in einer IF-Bedingung, wird der Scriptblock des IF ausgeführt, wenn die OU existiert. Das Ganze hat allerdings einen Haken, denn Get-ADOrganizationalUnit bricht die Skriptverarbeitung mit einem unbehandelten Fehler ab, wenn die OU nicht existiert.

If ( Get-ADOrganizationalUnit -Identity "OU=test,DC=Netz-Weise,DC=DE" ) { $true }
get-adorganizationalUnit : Directory object not found

Dieses Verhalten kann man sich zunutze machen, indem man die Ausführung des Get-ADOrganizationalUnit mit Try-Catch ausführt. Wird ein unbehandelter Fehler ausgeführt, wird die Catch-Block aufgerufen und ausgeführt. In diesem muß man jetzt nur noch einen $False zurück liefern. 

function Test-ADOrganizationalUnit