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


    Tags: , ,

    PowerShell RemotingMöchten sich User ohne admini­strative Privi­legien mit einem Remote-PC ver­binden, dann scheitert das an man­geln­den Rechten. Diese Limi­tierung lässt sich mit Hilfe von Session-Konfigurationen be­seitigen. Dabei muss man einem Standard­benutzer nicht Zugriff auf alle Funktionen von PowerShell ge­währen.

    Die Fähigkeit zum Remote-Management ist eine der Stärken von PowerShell. Sie beschränkt sich nicht auf interaktive Sitzungen, in denen man auf dem entfernten Rechner Kommandos absetzt. Vielmehr lassen sich auf diesem Weg auch Scripts ausführen und so Aufgaben automa­tisieren.

    Session Configurations als Komponente von JEA

    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.

    User ohne administrative Rechte können standardmäßig keine Remote-Session mit PowerShell aufbauen.

    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.

    Anzeigen der vorhandenen Session Configurations und ihrer Berechtigungen mit Get-PSSessionConfiguration

    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

    Neue Sitzungskonfiguration erzeugen mit Register-PSSessionConfiguration

    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.

    Berechtigungen für eine Session Configuration verwalten

    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

    Konto angeben, unter dem die Remote-Sitzung laufen soll, wenn sie über Sitzungskonfiguration gestartet wurde.

    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.

    Standardmäßig von New-PSSessionConfigurationFile erstellte Datei

    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

    Konfigurationsdatei erstellen und einer neuen Session Configuration zuordnen.

    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

    Der reduzierte Funktionsumfang reicht nicht für eine interaktive Session.

    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}

    Befehl über Invoke-Command in einer eingeschränkten Sitzung remote absetzen

    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.

    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 Wolfgang Sommergut
    Wolfgang Sommergut hat lang­jährige Erfahrung als Fach­autor, Berater und Kon­ferenz­sprecher zu ver­schie­denen Themen der IT. Da­ne­ben war er als System­ad­mi­ni­stra­tor und Con­sultant tätig.
    // Kontakt: E-Mail, XING, LinkedIn //

    Verwandte Beiträge

    Weitere Links