Just Enough Administration is a new feature of PowerShell in Windows Server 2016 and WMF 5.x which we can leverage across many enterprise applications, including SharePoint. It allows you to assign rights with “just enough” permission to perform a specific task or function. For example, we might want to allow a group of individuals to execute a timer job, but not change Managed Metadata Service Application settings, drop Content Databases, and so forth. Enter JEA! We’ll walk through a simple scenario of how to configure JEA for SharePoint. This scenario can be greatly expanded upon and does not cover all possible scenarios you may want to accomplish via JEA. The first step to configuring JEA is to create an Active Directory Security Group and add the members to the group for which JEA should apply. The next step is to enable PowerShell Remoting. On your SharePoint server, run . As we’ll be using a local account for JEA, explained in more detail below, we’ll need to add the machine account as a Shell Administrator. On your SharePoint server, create a new directory under called . Within that directory, create a new file, with the below contents. Next, again in the directory , create a new folder named (the name can be anything, but follow the example on your first run through). Within the directory, create a new directory named . We’ll create another module. The module file name must match the directory name, or in our example. Within the directory, create a file. In PowerShell, create a module manifest based off of our new module. We do not need to make any changes to either of these files. The next step is to generate our Role Capabilities file. This file will define what cmdlets the defined group will have access to. Open this file in your favorite text editor. You’ll see there are quite a few lines commented out. We can either replace those lines with our specified text, or we can just create new line entries. Either route you go, make sure you only have one Key = Value pair for each named key. First, we’ll add the . This will import our module that loads the SharePoint snapin we previously created in the Modules folder. The next step is to define the cmdlets we want our users to have access to, changing the value. In this example, we’ll allow the users to run and . Save the file, these are the only changes we’ll make. The next step is to create our PowerShell Session Configuration file. First, define the roles. This value is based off of the Active Directory Security Group, for example, . The RoleCapabilities value, , is the same name as our previously created Role Capabilities file. You can have multiple Role Capabilities files with different definitions (e.g. GroupA might have access to cmdlets while GroupB might have access to cmdlets). A single group can also have access to multiple Role Capabilities. In this example, we’re only specifying a single group and capability file. If you need to specify multiple groups or Role Capabilities, just separate them with a comma. Next, create the configuration file. You’ll see a few different parameters in this cmdlet. The is a parameter which, in essence, creates a Local Administrator session. We need Local Administrator for most, but not all, SharePoint cmdlets. This is the best way to use JEA, although there are other options such as gMSA, which I will not go into here. The parameter is a directory (which must exist) that stores session commands. This allows you to review all executed cmdlets within the JEA sessions. The transcripts are written by LocalSystem and this folder should be locked down to prevent unauthorized access. Lastly, we’re passing in our variable to . You can further edit this file via your favorite text editor, if required. Next, make sure you test your session configuration file! This can be accomplished via the below command. It must return True. If it returns False, you have an invalid configuration file. The last step server-side is to register the configuration file and restart WinRM. On your client workstation, run the following command to create a new remote session scoped to the JEA configuration. When connected, run . This should only list the default commands that are provided via JEA along with and from our example. Executing those commands should yield the expected output as if you were running them through a standard PowerShell session. JEA does have limitations. JEA sessions run in PowerShell No Language mode. This means you can’t use variables. Instead, you can craft functions that users of the JEA session can call. For example, let’s say you wanted to run the simple command . This would error out in the JEA session. The alternative is to create a function, such as the below function. While not best practice, for our example, add this function to the module we previously created, at any point below the line. Edit the file . Add a new line to expose our function. Enter a new JEA session and you can run the new function successfully, e.g. or . This will show us the Application Pool information for the User Profile Service Application and Managed Metadata Service Application. While most changes to JEA configuration only require one to end and create a new remote session, changes to the Session Configuration File require that you unregister and register the configuration file again. A restart of WinRM may also be required. To complete this, run the below script based off of our example. Hopefully this will be useful to segregate personnel who need to have full administrative access to the farm, where JEA provides no value, versus those who need selective access to administer the farm, where JEA can play a valuable role in providing exactly the amount of access they require.
The post Just Enough Administration for SharePoint PowerShell appeared first on The SharePoint Farm.
