Making JEA Great Again (And accessible, while we're at it) – Friedrich Weinmann – PSConfEU 2023

I, Fred, a Cloud Solution Architect at Microsoft, introduce myself and explain that we will be discussing Just Enough Administration (JEA) and its benefits. I mention that JEA allows us to delegate sensitive tasks without granting users sensitive privileges, solving the challenges of granting traditional system rights to helpdesk users.

Moving forward, I discuss the deployment process of JEA at scale, which is a pain point that Microsoft has not addressed before. To start the process, I explain the need for the G-Analyzer PowerShell module, which helps deploy JEA endpoints and avoids mistakes. I mention the specific permissions we want to allow for troubleshooting, accessing the event log, getting service state, and restarting the spooler service.

Next, I create a new GR module called “Service Admin” and fill it with the necessary permissions. I mention the need to create a new GR role and add the required group to it. Once the module is ready for deployment, I provide details about the module export and share module path.

We have developed a PowerShell module that contains all the necessary logic for a GR endpoint. Additionally, the module includes a register command that installs it on the user’s machine.

However, there are challenges associated with the installation process. One challenge is the presence of a previous session with the same name, which we check for and unregister if necessary. Another challenge is the restarting of the WinRAM service when registering a GI endpoint, which can lead to disconnected sessions and service failures.

To address these challenges, we set up a scheduled task that starts the service and removes itself after a specified time. This ensures a smooth user experience. Once the service is running, we register the PS session configuration, making the GI endpoint ready for use.

To ensure proper functionality, the module needs to be moved to the program files in the PowerShell modules directory. Using the “copy item” command, we achieve this and then finalize the setup of the GI endpoint by calling the “register grind point” command.

With the GI endpoint up and running, we can test it by entering a PS session with the specified computer name and configuration name. By using the “getCommand” command, we can see the expected commands and even a function called “restartService” with specific parameters.

During the discussion, I also highlight the potential harmful commands that should be avoided, such as “invoke expression” and “start process.” We have implemented a command that identifies these commands in a script or script file.

To simplify the deployment process, we have created a tool called “GRModuleLit” that automates the installation of the GR module on multiple machines in a domain. By specifying the computer names and using the “get ID computer” command, we can deploy the module to all computers in the domain.

In this part of the conversation, we discuss different deployment mechanisms for the GR endpoints. One option is remote deployment, but there may be warnings and errors if DivinerM is restarted before being closed. We can deploy the script content to any package manager that supports PowerShell scripts, including the GR code, configuration files, and dependent modules.

Another deployment mechanism discussed is group policy, which is useful for on-prem attendees. The Server Configuration Manager project allows users to deploy group policy with a scheduled task that launches a launcher script. This script looks for configuration in a specified folder and performs designated actions. While setting up this mechanism can be complicated, documentation is available.

I also mention a bootstrap logic script for the Server Configuration Manager and demonstrate its use. However, there is an issue with PowerShell resource get not supporting SMB shares. I showcase the modules published on the share and the SysVol scripts for …