Praxisbeispiel für JEA: Management von Storage Spaces Direct (S2D) delegieren

Just Enough Administration basiert auf JEA-Endpunkten, mit denen sich der Bediener verbindet, um in seiner Sitzung via PowerShell Remoting zu operieren. Der dabei erzeugte temporäre virtuelle Account verfügt über administrative Rechte, verliert am Ende der Sitzung jedoch seine Gültigkeit und wird wieder gelöscht. Der Weg bis dahin gliedert sich in meinem Lab wie folgt:

• Einrichtung einer Sicherheitsgruppe in AD für den Cluster-Support
• Erstellung eines Role Capability File (*.psrc) und eines Session Configuration File (*.pssc)
• Anpassung beider Dateihüllen und Auffüllen mit Cmdlets bzw. Schaltern
• Registrierung der Endpoints
• Herstellen der Remote-Verbindung in PowerShell (Enter-PSSession) von einem Windows-10-Client

Einrichtung einer Gruppe in AD

Zuerst lege ich für JEA eine Gruppe in Active Directory an, in der sich später alle vorgesehenen Bediener für den JEA-Endpunkt versammeln. Nur ihnen ist es möglich, definierte Cmdlets bzw. Funktionen auf dem Endpunkt auszuführen.

In meinem Beispiel ist Amylie Baum Mitglied dieser Gruppe. Unter realen Bedingungen empfiehlt es sich, dass diese Domänenbenutzer für eine JEA einen separaten Account in AD erhalten.

Erstellung von Dateien für Role Capability und Session Configuration

Zwei Cmdlets helfen uns, die nötigen Dateien zu erzeugen. Für das Role Capability File sieht ein Aufruf wie folgt aus:

New-PSRoleCapabilityFile -Path "C:\Program Files\WindowsPowerShell\Modules\JEA\RoleCapabilities\RC-JEA-ENDP-A.psrc"

Für ein neues Session Configuration File sorgt ein Befehl nach diesem Muster:

New-PSSessionConfigurationFile -Path "C:\JEA\SessionConfig\SC-JEA-ENDP-A.pssc"

Die Rollen für eine JEA behandelt PowerShell wie Module und daher sollten diese in einem bestimmten Ordner vorliegen ($env:PSModulePath). Meine PSRC-Datei speichere ich dementsprechend unterhalb %ProgramFiles%\WindowsPowerShell\Modules in RoleCapabilities (siehe hier folgenden Screenshot). Achten Sie auf die richtige Schreibweise für den Ordner RoleCapabilities.

Diese Dateien können mit einem Texteditor oder sinnvoller mit der ISE bearbeitet werden. Beim Erzeugen der Files legt PowerShell sie gleich samt auskommentiertem Inhalt an, welcher sich dann folgend anpassen lässt.

Konfiguration der Role Capability Datei

In meinem Beispiel möchte ich dem Support-Team die Möglichkeiten geben, grundlegende Informationen für ein Troubleshooting des S2D-Verbundes einzusammeln. Dazu zählen jene des Health Service, der Fehler und Metriken bei Storage Spaces Direct liefert.

Die dafür erforderlichen Funktionen bzw. Cmdlets nehme ich daher in die PSRC auf (siehe Abb. oben). Unter Visible Functions finden sich hier:

• Get-StorageHealthReport
• Get-StorageSubSystem
• Debug-StorageSubSystem

Datei für Session Configuration konfigurieren, Endpunkt definieren

Innerhalb der Session Configuration sind drei Angaben entscheidend. Zum einen der Session Type, welcher hier auf Restricted Remote Server festgelegt wird. Er erlaubt per Voreinstellung den Einsatz von nur 8 Cmdlets, darunter solche wie Clear-Host, Exit-PSSession oder Select-Object.

Dann sorge ich über den Parameter RunAsVirtualAccount dafür, dass die Remote-Session mit dem bereits angesprochenen virtuellen Account initiiert wird.

Schließlich verknüpfen wir diese Session Configuration mit unserer Role Capability und der bereits definierten AD-Gruppe. In unserem Fall existiert eine Rollenfunktion, es können hier jedoch mehrere verlinkt werden:

RoleDefinitions = @{'KUEPPERS\JEA-USER' = @{ RoleCapabilities = 'RC-JEA-ENDP-A'}}

Die Angaben zu den Role Capabilities werden dann im Ordner PowerShell Modules automatisch den entsprechenden PRSC-Dateien zugeordnet.

Registrieren des Endpunktes

Durch die Registrierung des Endpunktes akzeptiert dieser dann Verbindungen in Remote Sessions. Dazu wird das zuvor konfigurierte Session Configuration File benötigt und gleichzeitig ein Name für diesen Endpunkt definiert:

Register-PSSessionConfiguration -Name JEA-USER -Path "C:\JEA\SessionConfig\SC-JEA-ENDP-A.pssc"

Damit ist die Kette vom Endpunkt zur Rollenfunktion samt AD-Gruppe komplett, jene gerade registrierte Schnittstelle steht auf Standby. Über

Get-PSSessionConfiguration

lässt sich diese verifizieren und mit

Unregister-PSSessionConfiguration -Name JEA-USER

wieder abschalten.

Aufbau einer Session für eine JEA

Zu guter Letzt möchte ich hier eine JEA demonstrieren und die konfigurierten Labor-Funktionen auf die Probe stellen. Die dazu verwendete virtuelle Client-Workstation führt Windows 10 aus und eine Anmeldung findet mit dem Benutzer-Account KUEPPERS\abaum statt.

Über whoami /groups lässt sich nun erkennen, dass dieser Benutzer keiner administrativen Gruppe angehört. Der folgende Aufruf startet dann die Remote Session mit dem angemeldeten Benutzer zu unserem erklärten Endpunkt auf einem S2D-Knoten:

Enter-PSSession -ComputerName HC-NODE-A -ConfigurationName JEA-USER

Ein erneuter Aufruf von whoami in dieser interaktiven Session zeigt hier die temporäre Sitzung mit einem virtuellen Account. Eine Abfrage mit Get-Command liefert jetzt zuvor zugelassene Cmdlets und Funktionen.

Der Support-Mitarbeiter muss bei deren Eingabe genau auf die Syntax achten, da eine Auto-Vervollständigung über die Tabulator-Taste nicht greift. Schlussendlich besteht für den Cluster-Support jetzt die Möglichkeit, über

Get-StorageSubSystem Cluster* | Get-StorageHealthReport

Metriken des S2D-Verbundes abzufragen und eingeschränkt mit dem Verbund zu arbeiten.