Tags: PowerShell, Remote-Verwaltung, Rechteverwaltung
Möchten sich User ohne administrative Privilegien mit einem Remote-PC verbinden, dann scheitert das an mangelnden Rechten. Diese Limitierung lässt sich mit Hilfe von Session-Konfigurationen beseitigen. Dabei muss man einem Standardbenutzer nicht Zugriff auf alle Funktionen von PowerShell gewä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 automatisieren.
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.
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
Sitzungskonfigurationen regeln immer den PowerShell-Zugriff auf einen Rechner, auch wenn man keine eigene angelegt hat. Standardmäßig sind drei Session Configurations auf jedem Windows-Rechner vorhanden, nämlich microsoft.powershell, microsoft.powershell.workflow und microsoft.windows.servermanagerworkflows.
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 Remoteverwaltungsbenutzer vorbehalten.
Eigene Configurations definieren
Theoretisch könnte man nun einfach die Sicherheitseinstellungen dieser Konfiguration so ändern, dass sie auch ausgewählte Standardbenutzer verwenden dürfen. Davon sollte man aber absehen und eine funktionierende 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 ShowSecurityDescriptorUI 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 Benutzerkennung 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 Einschränkungen durch eine Sitzungskonfiguration 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:
- MaximumReceivedDataSizePerCommandMB: legt die maximale Datenmenge in MB fest, die mit einem Befehl übertragen werden kann (Vorgabe: 50MB).
- MaximumReceivedObjectSizeMB: 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.
Täglich Know-how für IT-Pros mit unserem Newsletter
Verwandte Beiträge
- JEA: Rollenfunktionen definieren und einer PowerShell Session Configuration zuordnen
- ThinPrint 13 unterstützt Microsofts V4-Druckertreiber und MMC
- Ordner freigeben mit PowerShell
- Exchange Impersonation: Service-Benutzer auf Postfächer berechtigen
- PowerShell 7.3: JEA über SSH, Cmdlet für Setup, erweiterte ARM-Unterstützung
Weitere Links