Weisheiten - der Netz-Weise Blog

"Ein Überblick darüber, wie Powershell Daten ausgibt, und wie sie dieses Verhalten steuern können. Wenn Sie in Powershell Daten an der Konsole ausgeben wollen, stehen Ihnen eine ganze Reihe von Commandlets zur Verfügung. Die wichtigsten sind:

Außerdem gibt es noch das gerne genutzte, aber leider böse Write-Host. Warum Write-Host böse ist, werden Sie gleich verstehen. Die 5 vorgestellten Commandlets haben alle eigene ""Ausgabeströme"" oder Kanäle, in denen die Daten ausgegeben werden. Man kann sich das vorstellen wie 5 parallele Straßen, auf denen der Verkehr geregelt wird. Die Linke Spur ist für LKW vorgesehen, die 2. Spur für Busse, die 3. für Taxen, die 4. für normalen Personenverkehr und die 5. für Einsatzfahrzeugt. Normalerweise sind die Spuren komplett voneinander getrennt, kommen sich also nicht in Gehege. Der normale Ausgabestrom wird auch von der Pipeline genutzt. Daten, die mit Write-Output in den Ausgabestrom geschrieben werden, landen in der Pipeline und können dort weiterverarbeitet werden. Alle anderen Ausgaben (Fehler, Debugmeldungen usw.) landen nicht in der Pipeline, da die Pipeline nur am Standard-Ausgabestrom hängt. Dadurch können alle in der Pipeline nicht benötigten Daten aus Ihr heraus gehalten werden. Genau wie auf einer Straße die Spuren gewechselt werden können, kann man in der Powershell auch Daten umleiten. Dafür gibt es den Umleitungsoperator >&. Vor dem > steht der Strom, der umgeleitet werden soll, hinter dem & steht der Strom, auf den umgeleitet werden soll. Die Ströme sind eindeutig durchnummeriert: 1 Output 2 Error 3 Warning 4 Verbose 5 Debug Das Kommando

$VerboseMessage = Write-Verbose -message "Dies ist eine Ausgabe" -verbose 4>&1

schreibt die Ausgabe des Write-Verbose-Befehls in eine Variable. Geben Sie nur

$VerboseMessage = Write-Verbose -message "Dies ist eine Ausgabe" -verbose

ohne den Umleitungsoperator an, wird die Nachricht ausgegeben, aber nicht in der Variablen gespeichert. (Der Parameter -verbose ist übrigens dafür da, ausführliche Nachrichten überhaupt erst auszugeben. Write-Verbose Ausgaben werden nur angezeigt, wenn die Variable $VerbosePreference auf Stop, Inquire oder Continue gesetzt ist, oder im Commandlet explizit der Parameter -verbose gesetzt wurde.) Das die Ausgabe nur mit dem Zuweisungsoperator 4>&1 gespeichert wird, liegt daran, dass in Variablen immer nur der Standard-Ausgabestrom gespeichert wird. Dadurch werde Fehlermeldungen usw. aus den Variablen heraus gehalten. Wollen Sie alle Ausgaben in eine Datei speichern, so hilft Ihnen die Umleitung *> c:\outputfile.txt Diese Ausgabe leitet sämtliche Ausagen in die Zieldatei um. Aber dummerweise nicht die Ausgaben, die write-host generiert. Write-Host nutzt nämlich keinen der Ausgabeströme, sondern schreibt direkt in die Konsole. Dadurch geht sämliche Kontrolle über die Ausgabe verloren. Nutzen Sie daher am Besten, soweit möglich, immer write-output für Ihre Ausgaben. "

Heute habe ich das neue Kapitel über Group Policy Preferences für die Neuauflage meines Gruppenrichtlnienbuchs beendet. Dabei habe ich ein sehr schönes Beispiel für den Einsatz der Registry-Einstellungen gefunden.

Die Sprachleiste ist in den meisten Fällen ein sehr überflüssiges Feature, denn sie erlaubt das Umschalten zwischen verschiedenen Tastaturlayouts. Welchen Sinn das haben soll, ist mir bis heute verborgen geblieben, denn ich wechsel eigentlich nie mal zwischendurch für ein frischeres Erlebnis auf eine chinesische Tastatur. Trotz allem dürfen wir dieses tolle Feature seit vielen Windows-Generationen genießen. Wenn die Funktion einfach nur da wäre, wäre das ja nicht weiter schlimm, aber dummerweise implementiert Sie auch noch die unseelige Tastenkombination Shift+Alt, die das Tastaturlayout automatisch umschaltet. Wie viele Helpdesk-Tickets aufgrund eines versehentlich aktivierten englischen Tastaturlayouts aufgemacht wurden, möchte ich nicht wissen. Glücklicherweise hat Microsoft in der aktellen Version 1803 von Windows 10 zumindest eine Option vorgesehen, das hinzufügen weiterer Layouts zu überspringen.

Die Sprachleiste wird über die Registry gesteuert, und zwar über den Schlüssel HKEY_CURRENT_USER\Keyboard Layout\Preload. Hier ist für jede Sprache ein Werte hinterlegt, wobei der Wertname der Priorität entspricht, und der Wert selber den Sprachcode bestimmt. Bei ITProToday finden Sie eine Liste der Sprachcodes. Bei mir finden sich zwei Einträge in der Liste:

Der Wert 407 entspricht dem deutschen Layout, 409 ist das US-Englische Tastaturlayout.

Um die Sprachleiste zu entfernen, müssen Sie lediglich den kompletten Schlüssel Preload entfernen. Dies kann mit einem Powershell-Skript einfach erledigt werden, oder mit Gruppenrichtlinen-Einstellungen.

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: ********

Wenn ein Domänen-Computer gestartet wird, sucht er im Netzwerk zuerst nach einem Domänen-Controller, indem der den DNS-Server nach den LDAP-Service-Records seiner Domäne fragt. Anschließend versucht er, mit dem Domänencontroller einen Secure Channel, also eine verschlüsselte, sichere Datenverbindung aufzubauen. Dies geschieht über einen RPC Netlogon. RPC ist ein Challenge-Response-Protokoll, bei dem der Client und der Server sich gegenseitig einen zufälligen 64 Bit-Zufallswert, den Client- bzw. Server Challenge, zuschicken, aus denen mit Hilfe des Computerkennworts (wegen gegenseitige Authentifizierung sowohl auf dem Client als auch auf dem Server) ein Session-Key berechnet wird. Das funktioniert, weil sowohl der Client als auch der Domänencontroller über das Computerkennwort des Clients verfügen. Wenn der Domänencontroller und der Client nicht das gleiche Kennwort gespeichert haben, schlägt die Erstellung des Secure Channels allerdings fehl und dem Client wird die Verbindung zum Domänencontroller verweigert. Stattdessen wird eine Fehlermeldung angezeigt, die vermutlich jeder Administrator schon einmal gesehen hat: „The trust relationship between this workstation and the primary domain failed” bzw. "Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden".

Wie und wo wird das Computerkennwort verwaltet

Der Client generiert beim Aufnehmen in die Domäne ein komplexes Kennwort, dass er ab Windows 2000 alle 30 Tage automatisch ändert. Da Computerkonten sind von den Kennwortrichtlinien der Domäne ausgenommen sind, können Sie auch nicht gesperrt werden, wenn sie länger offline sind.
Die Kennwortänderung führt der Client zuerst zuerst lokal aus. Danach ändert er sein Kennwort im AD. Schlägt die Aktualisierung im AD fehl, setzt er wieder das alte Kennwort. Das aktuelle Kennwort und sein Vorgänger werden im geschützten Kennwortschlüssel HKLM\SECURITY\Policy\Secrets\$machine.ACC gespeichert. Im AD sind die Kennwörter in den Attributen unicodepwd und lmpwdHistory abgelegt.
Ob und wie oft der Client sein Kennwort ändert, kann in der Systemregistrierung unter HKLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters konfiguriert werden. Für die Konfiguration sind drei Schlüssel verantwortlich:

MaximumPasswordAge: Der Eintrag MaximumPasswordAge legt fest, nach welchem Zeitraum der Netlogon-Dienst versucht, das Kennwort zu ändern. Der Standardwert ist 30 (Tage).

ScavengeInterval: Das Scavengeinterval legt fest, wie häufig der Computer prüfen soll, ob das maximale Kennwortalter erreicht ist. Der Standardwert beträgt 900 (Sekunden), also 15 Minuten. Der Eintrag ist nicht in der Registry hinterlegt, kann hier aber geändert werden. Der Typ des Eintrags ist REG_DWORD.

DisablePasswordChange: Sie können die Kennwortänderung des Computers mit diesem Schlüssel auch komplett deaktivieren, indem Sie den Wert auf 1 setzen.

Das Sperren von Benutzerkonten ist ein bewährtes Mittel, um Brute-Force-Attacken gegen Kennwörter im Unternehmen zu verhindern. Allerdings empfehlen sowohl Microsoft als auch das BSI inzwischen, Kontosperrungen nicht zu verwenden, da eine Malware oder ein Hacker durch das Sperren sämtlicher Benutzerkonten ein Netzwerk komplett lahm lagen kann - man spricht auch von einem denial of Service.

Die alternative Empfehlung lautet, lange Kennwörter in Form von Passphrases und am Besten Multifaktor-Authentifizierung einzusetzen. Grundsätzlich ist das ein vernünftiger Ansatz, aber leider scheitert er in vielen Netzwerken immer noch an der Praxis. Zum einen muß man den Benutzern erklären, dass Sie jetzt lange komplexe Kennwort-Sätze verwenden sollen, zum Anderen muß man mit dieser Variante auch für eine ordentliche Anmeldungs-Überwachung sorgen, da ein großangelegter Angriff auf die Benutzerkennwörter sonst gar nicht auffällt. Mit aktivierter Kennwortsperrung merkt man normalerweise sehr schnell, dass etwas nicht stimmt.

Mein pragmatischer alternativer Ansatz, um die Kontosperrungen weiterhin nutzen zu können, arbeitet mit automatisierten Prozessen und Powershell. Denn mit Powershell ist es sehr schnell und einfach möglich, Benutzerkonten zu entsperren. Verwenden Sie dafür die Cmdlets Search-ADAccount und Unlock-ADAccount. Search-ADAccount kann mit dem Parameter -Lockedout alle gesperrten Benutzerkonten in einem Rutsch auflisten, Unlock-ADAccount kann sie  direkt entsperren. Mit Hilfe des Cmdlets Out-Gridview können Sie sich auch gleich noch eine grafische Benutzeroberfläche einrichten, um nur ausgewählte Benutzer zu entsperren.

Search-ADAccount -Lockedout | Out-Gridview -Passthru | Unlock-ADAccount

Damit wird das Entsperren nach einem Denial of Service zu einem Kinderspiel. Allerdings muß noch ein zweites Problem gelöst werden. Wenn Sie nämlich das Standard-Administratorkonto auf der Domäne deaktivieren, haben Sie eventuell gar keine Möglichkeit mehr, die Domäne zu entsperren, weil Ihr Administrator auch gesperrt ist. Deswegen legen Sie sich nun ein niedrig privilegiertes Konto an, dass neben dem Entsperren von Benutzern in der Domäne nichts kann, aber nicht gesperrt wird.

Windows 10 kennt zwei verschiedene Anwendungstypen - die klassischen Anwendungen und Apps. Apps gibt es seit Windows 8, und sie sind vom App-Konzept von Apple und Google übernommen. Apps unterscheiden sich in einigen grundlegenden Dingen von Anwendungen:

Zumindest der letzte Punkt könnte sich ändern, denn Microsoft hat ein neues Format für die automatische Installation entwickelt, nämlich msix. Trotzdem möchte nicht jeder Administrator Apps in seiner Umgebung bereitstellen. Um die bereits mit Windows mitgelieferten Apps loszuwerden, muß man allerdings einige konzeptuelle Dinge verstehen:

Grundsätzlich werden Apps pro Benutzer installiert. Man spricht von Appx-Paketen. Um Appx-Pakete zu verwalten, können Sie Powershell-Cmdlets verwenden:

Dies ist ein Auschnitt aus der Neuauflage meines Gruppenrichtlinien-Buchs "Gruppenrichtlinien in Windows Server 2019 und Windows 10, das vermutlich im Oktober 2018 erscheinen wird

Übermittlungsoptimierung oder Delivery Optimiziation (DO) ist ein neues Feature, das Microsoft mit Windows 10 eingeführt hat, und das die Menge an Daten, die von Windows Update und dem Windows Store heruntergeladen werden, massiv reduziert. Das Verfahren basiert auf Peer To Peer Technologie, Clients teilen bereits heruntergeladene Daten also mit anderen Clients (Peers) im gleichen Netzwerk (oder auch über das Internet). Dafür werden Dateien in Blöcke aufgeteilt, gehashed (es wird eine eindeutige ID erzeugt), und dann Blockweise verteilt anstatt als Monolithische Datei. Damit ein Client tatsächlich nur Original-Daten erhält, sind die Dateien digital signiert, der Client kann also nach Empfang der kompletten Datei prüfen, ob er ein unverändertes Update erhalten hat.

Wenn ein Client ein Update von einem Update-Server herunterladen möchte und die Übermittlungsoptimierung aktiviert ist, erhält er vom Update-Service über die URL *.do.dsp.mp.microsoft.com eine Liste von Rechnern, die bereits Blöcke der Update-Datei bezogen haben. Auf Windows 10 Pro und Enterprise ist die Einstellung dabei standardmäßig so konfiguriert, dass ein PC Daten nur von Peers aus seinem eigenen lokalen Netzwerk empfängt (s. Bild 1.2). Der Update-Service ermittelt über die IP des sich verbindenden Rechners (normalerweise die öffentliche IP des Routers oder Proxys, über den der Client sich verbindet), mit welchen Peers er Daten austauschen darf. Zusätzlich greift der Dienst auf die AD-Standortdaten zurück oder, wenn diese nicht verfügbar sind, auf die Domäne. Man kann diese automatische Gruppierung aber auch überschreiben und manuell festlegen, welche Clients miteinander Daten austauschen dürfen, indem man eine Group-ID festlegt. Die Group-ID wird dann als einziges Kriterium verwendet, um zu ermitteln, welche Clients Daten austauschen dürfen. Das ist wichtig, wenn man bereits mit IPv6 arbeitet (alle Clients haben eine öffentliche IP-Adresse) oder der Zugriff nach außen über Proxy-Arrays oder Load-Balancing stattfindet, so dass ein Standort nicht über eine eindeutige ID verfügt. Die Group-ID ist eine GUID (Globally Unique Identifier), die man z.B. mit dem Powershell-Cmdlet New-GUID zufällig generieren kann.

Die Übermittlungsoptimierung arbeitet höchst effizient und teilt Daten deutlich schneller als die Alternative Branchcache. Sind die Daten erst einmal im lokalen Netzwerk, dauert es nur Sekunden, bis Clients lokale Peers als Quelle verwenden können. Die Daten werden dann mit voller lokaler Netzwerkgeschwindigkeit geteilt. Der Übermittlungsoptimierungsdienst verwendet hierfür Port 7680 im lokalen Netzwerk, für den Datentausch mit Internet-Peers Port 3544 (Teredo-Protokoll, eine IPv6-Übergangstechnologie).

Übermittlungsoptimierung ist vor allem für große Dateien effektiv und kostet außerdem Client-Ressourcen, weshalb Branch-Cache standardmäßig erst aktiviert wird, wenn der Client mindestens über 4 GB RAM und 32 GB freien Speicherplatz auf dem Cache-Laufwerk verfügt. Alle diesen Daten können über Gruppenrichtlinien angepasst werden, die Sie in der Computerkonfiguration unter ADMINISTRATIVE VORLAGEN - WINDOWS-KOMPONENTEN - WINDOWS UPDATE - ÜBERMITTLUNGSOPTIMIERUNG finden.

Mehr zum Thema Gruppenrichtlinien finden Sie auch in meinem Buch Gruppenrichtlinien in Windows 10 und Windows Server 2019, das voraussichtlich im Oktober in der Neuauflage erscheint.

Jedes Windows 10 Feature-Release bringt neue Funktionen und neue Gruppenrichtlinien mit. Welche Richtlinien in welcher Version neu dazugekommen sind, können Sie im Group Policy Settings Reference-File nachschauen, das Microsoft zum Download anbietet.

Manche Richtlinien sind leider nicht wirklich kompatibel zueinander. Z.B. hat Microsoft mit dem Feature Release 1607 die Nutzungszeit eingeführt und auf 12 Stunden festgelegt. Ab 1703 sind es aber maximal 18 Stunden. Sie können die Nutzungszeit auch per Gruppenrichtlinie festlegen, aber die Maximalwerte von 1703 kann 1607 nicht verarbeiten. Die Lösung sind zwei Gruppenrlichtlinienobjekte (GPOs), die per WMI-Filter "Ihre" Version aussortieren.

Aber auf welchen Wert kann man filtern? Die offizielle Nummer des Feature-Release kann man per WMI-Filter nicht erfragen. Stattdessen kann man aber die Build-Nummer verwenden, die sich mit jedem Feature-Release ändert. Eine Liste der aktuellen Build-Nummern finden Sie bei Wikipedia unter https://en.wikipedia.org/wiki/Windows_10_version_history. In der ersten Tabelle finden Sie in der Spalte Builds die jeweilige Build-Nummer.

Per WMI ermitteln Sie die Build-Nummer über die Klasse Win32_OperatingSystem und die Eigenschaft BuildNumber.

Seit Windows 8.1 gibt es das administrative Startmenü (im englischen Power User Menü genannt), das man über Windows-Taste+X oder über das Kontextmenü des Startbuttons erreichen kann. Das Startmenü ist ausgesprochen praktisch, wenn es um das Aufrufen von administrativen Werkzeugen geht. Außerdem hat man hier die Möglichkeit, den Rechner sowohl herunterzufahren als auch eine Abmeldung durchzuführen, ohne unterschiedliche Menüs verwenden zu müssen.

Leider gibt es keine Bordmittel, um das Menü anzupassen. Prinzipiell kann man auf manuellem Weg mit ein paar Tricks die Einstellungen vornehmen, um eigene Tools im Menü zu verlinken. Es gibt aber auch einen angenehmen Weg, nämlich den Win+X-Editor. Er kann kostenlos bei WinAero heruntergeladen werden. Achten Sie darauf, dass Sie den richtigen Link erwischen, er ist ein wenig versteckt. Eine kleine Anleitung inklusiver der Handgriffe, die man ausführen muß, um die Anpassungen manuell durchzuführen, finden Sie bei Digital Citizen: All the ways to customize the WinX menu in Windows 10 (and Windows 8.1).

Um den Computernamen zu ermitteln, kann man den Kommandozeilenbefehl Hostname verwenden. Es gibt in Powershell aber keine direkte Möglichkeit, den DNS-Namen eines Computers abzufragen. Hier hilft die DNS-Klasse aus dem .Net Framework aus:

Hostname # Zeigt den Netbios-Computernamen an
$ComputerSystem = [System.Net.Dns]::GetHostByName(($env:computerName))

Das zurückgelieferte Objekt hat drei Eigenschaften, Hostname, Aliases und Addresslist

HostName          Aliases AddressList
--------          ------- -----------
DC1.netz-weise.eu {}      {10.1.0.200}