JEA Session Configuration: Remote-Sitzungen in PowerShell für Standardbenutzer erlauben, Funktionen beschränken

Per Voreinstellung steht diese Möglichkeit aber Standardbenutzern nicht offen, ihre Anfragen werden vom Zielrechner abgewiesen. Möchte man jedoch Aufgaben an Mitarbeiter ohne administrative Privilegien delegieren, dann muss man diese strikte Regelung lockern.

Diesem Zweck dient eine Session Configuration. Sie bestimmt, wer zu einem Rechner eine Session aufbauen darf. Diese Funktion nimmt sie auch im Rahmen von Just Enough Administration (JEA) wahr. Die Definition, was die User dann dort machen dürfen, erfolgt bei JEA über die zusätzlichen Role Capabilities.

In vielen Fällen muss man sich das komplette JEA aber nicht antun, sondern kann das Zugriffsrecht und die verfügbaren Sprachelemente gleich über eine Session Configuration festlegen.

Restriktive Standardkonfigurationen

Sitzungs­konfigurationen regeln immer den PowerShell-Zugriff auf einen Rechner, auch wenn man keine eigene angelegt hat. Standard­mäßig sind drei Session Configurations auf jedem Windows-Rechner vorhanden, nämlich microsoft.power­shell, micro­soft.power­shell.work­flow und micro­soft.win­dows.ser­ver­manager­work­flows.

Erzeugt man eine neue Sitzung, etwa mit Enter-PSSession, und spezifiziert keine bestimmte Configuration, dann greift per Voreinstellung microsoft.powershell. Wie der Aufruf von

Get-PSSessionConfiguration

auf dem Zielrechner zeigt, ist diese Session-Konfiguration Administratoren und Mitgliedern der lokalen Gruppe Remote­verwaltungs­benutzer vorbehalten.

Eigene Configurations definieren

Theoretisch könnte man nun einfach die Sicherheits­einstellungen dieser Konfiguration so ändern, dass sie auch ausgewählte Standard­benutzer verwenden dürfen. Davon sollte man aber absehen und eine funktio­nierende Konfiguration für Admins beibehalten.

Stattdessen empfiehlt es sich, eigene Session Configurations zu erstellen. Im einfachsten Fall führt man dazu am Zielrechner, im JEA-Jargon auch Endpunkt genannt, einen Befehl nach diesem Muster aus:

Register-PSSessionConfiguration -Name HelpDesk

Mit diesem Aufruf ist aber noch nicht viel gewonnen, weil die neue Konfiguration nur eine Kopie von microsoft.powershell ist und keinen Benutzern außer Admins den Zugriff auf den Rechner erlaubt. Daher kann man gleich beim Anlegen der Configuration auch die Berechtigungen definieren.

Berechtigungen festlegen

Dies erfolgt entweder über den Parameter SecurityDescriptorSddl, der allerdings die Berechtigungen in der Syntax der Security Descriptor Definition Language erwartet. Wer nicht allzu oft Session Configurations erzeugen muss, kann sich diesen Aufwand sparen und stattdessen den Parameter ShowSecurity­DescriptorUI nehmen:

Register-PSSessionConfiguration -Name HelpDesk -ShowSecurityDescriptorUI

Dies öffnet den Dialog, wie man ihn etwa schon von der Vergabe der Dateiberechtigungen her kennt.

Damit legt man fest, wer diese Konfiguration nutzen kann, indem man lokale bzw. AD-Gruppen hinzufügt und ihnen die gewünschten Privilegien zuteilt. Für das Ausführen einer Remote-Session reicht hier das Recht Ausführen.

RunsAs-Benutzer definieren

Damit hat man bereits bestimmt, wer mit Hilfe dieser Konfiguration eine Sitzung auf diesem Remote-Rechner starten darf. Zusätzlich kann man noch festlegen, unter welcher Benutzer­kennung das passieren soll, indem man die betreffende Kennung an den Parameter RunAsCredential übergibt:

Register-PSSessionConfiguration -Name HelpDesk -RunAsCredential contoso\meier

PowerShell fragt dann das Passwort ab und speichert es in der Konfiguration. Verbindet sich ein Benutzer dann mittels einer Session Configuration mit dem Ziel-PC, dann arbeitet er dort automatisch im Kontext dieses Kontos. Verzichtet man auf diese Option, dann erfolgt die Verbindung unter dem lokal angemeldeten User.

Einschränkungen für Sessions erzwingen

Damit erhält er dessen Berechtigungen im Dateisystem, aber funktionale Ein­schränkungen durch eine Sitzungs­konfiguration gelten unabhängig vom verwendeten Account. Das RunsAs-Konto benötigt somit keine Berechtigungen im SecurityDescriptor der Session Configuration.

Das Cmdlet Register-PSSessionConfiguration stellt mehrere Parameter zur Verfügung, über die sich der Spielraum der Benutzer eingrenzen lässt:

• MaximumReceived­DataSizePerCommandMB: legt die maximale Datenmenge in MB fest, die mit einem Befehl übertragen werden kann (Vorgabe: 50MB).
• MaximumReceived­ObjectSizeMB: bestimmt die maximale Größe eines einzelnen Objekts, das übertragen werden kann (Vorgabe: 10MB)
• SessionType: entscheidet, welche Module und Snap-Ins in der Session zur Verfügung stehen. Mit dem Wert empty sind es keine (und müssen etwa über den Parameter ModulesToImport explizit hinzugefügt werden). Default erlaubt den Benutzern, mit Hilfe von Import-Module selbst die Funktionalität zu erweitern. RestrictedRemoteServer schließlich bietet ein halbes Dutzend Cmdlets.

Alle hier beschriebenen Parameter mit Ausnahme von Name kann man auch nachträglich verwenden, um die Konfiguration mit Hilfe von Set-SessionConfiguration anzupassen.

Weitere Optionen durch Configuration File

Mit den Mitteln von Register-PSSessionConfiguration kann man in vielen Fällen schon den notwendigen Kontext für Benutzer schaffen, die bestimmte Aufgaben auf dem Remote-Host übernehmen sollen. Hilfreich ist dabei auch die Möglichkeit, gleich beim Start der Session ein Script auszuführen (Parameter StartupScript).

Wem das aber noch nicht reicht, dem stehen mittels einer Configuration File noch weitere Optionen zur Verfügung. Eine solche lässt sich mit dem Cmdlet New-PSSessionConfigurationFile erzeugen. Diesem übergibt man die gewünschten Einstellungen entweder als Parameter (siehe hier die komplette Liste) oder man ruft es in dieser minimalistischen Form auf, wobei die Endung .pssc erforderlich ist:

New-PSSessionConfigurationFile -Path .\MyConfig.pssc

Danach öffnet man die Datei in einem Texteditor und fügt die gewünschten Einstellungen hinzu, einige sind in auskommentierter Form bereits vorhanden.

Für die Beschränkung der User-Freiräume sind von besonderem Nutzen:

• LanguageMode mit den Werten FullLanguage, RestrictedLanguage, ConstrainedLanguage, NoLanguage: Letzteres erlaubt nur die Ausführung von Cmdlets und Funktionen, andere Sprachmittel stehen nicht zur Verfügung. FullLanguage bietet den ganzen Sprachumfang, die beiden anderen liegen zwischen diesen beiden Polen.
• VisibleAliases, VisibleCmdlets, VisibleFunctions, VisibleProviders: Damit lässt sich festlegen, welche Aliases, Cmdlets, Funktionen und Provider in der Session verfügbar sind. Hier lassen sich Wildcards verwenden und mehrere Werte in Form eines Arrays angeben.

Zugriff auf Cmdlets limitieren

Um die verfügbaren Cmdlets auf jene einzuschränken, die nur lesen und nicht schreiben, könnte man den Ausdruck "Get*", "Select*" verwenden:

New-PSSessionConfigurationFile -Path .\MyConfig.pssc -VisibleCmdlets "Get*","Select*"

Anschließend passt man die Session Configuration auf Basis dieser Datei an:

Set-PSSessionConfiguration -Name HelpDesk -Path .\MyConfig.pssc

Wenn man nun versucht, eine interaktive Remote-Session mit dem Rechner aufzubauen, dann wird man scheitern, weil dafür nicht alle nötigen Befehle zur Verfügung stehen:

Enter-PSSession -ComputerName remote-pc -ConfigurationName HelpDesk

Daher ist ein Benutzer mit dieser Session Configuration darauf beschränkt, Befehle remote abzusetzen, etwa nach diesem Muster:

Invoke-Command -ComputerName remote-pc-ConfigurationName Helpdesk {Get-ChildItem}

Configuration zu Session zuordnen

Wie die beiden obigen Aufrufe zeigen, muss man die gewünschte Session Configuration über den Parameter ConfigurationName angeben. Tut man das nicht, dann greift microsoft.powershell und nicht-administrative User müssen draußen bleiben. Welche Konfiguration standardmäßig verwendet wird, kann man aber mit der Variablen $PSSessionConfigurationName festlegen.

Schließlich kann man nicht mehr benötigte Session Configurations mit dem Cmdlet Unregister-PSSessionConfiguration entfernen. Es verlangt als Argumente nur den Namen der Konfiguration.