Security Considerations about granting to many rights to the MSA

[TimPeTwo]

Assume I got a script for the help desk to reset password on an ADUser. So the Managed Service Account that runs WebJea will need to have the permission to reset passwords. Another script can change the group membership of an ADuser. The MSA needs that permission two. As time goes on, more on more scripts will be run with WebJea, the MSA gets more permissions and become a SuperUser that can control the entire it-infrastructure.

Are there any approaches or ideas to prevent this?

Best regards Tim

[markdomansky]

You have a valid concern and it is something to consider. There are some not-so-elegant solutions like running multiple WebJEA instances on the same or different servers. Running multiple instances should be possible, though it isn't something I've tested.

At least with MSAs, that account can only authenticate from the server it's authorized, which limits lateral movement and if the system itself has been compromised, then separate MSAs doesn't help either.

From my perspective, the issue with adding lots of permissions to the MSA is more about tracking which permissions are still needed when you remove a function from WebJEA.

This is something I'm considering for a future enhancement.

[fr0mtheinternet]

I've successfully tested multiple application instances on a single IIS site.

I modified the DSCDeploy.ps1 to allow for this, and it works as intended. I'm willing to share the changes I've made, but I think I need to understand how to use git first....

[toasti2000]

This would be very interesting - please share when possible. But no rush...

[fgodskesen]

You could use JEA in conjunction with WebJEA

Create JEA endpoints on another server for specific commands that require elevation (e.g. on a Domain Controller for user administration). WebJEA then works just as a proxy for the actual functions.

For example:

• User X is member of Group Y

• Group Y is permitted to call "unlock user account" script in WebJEA

• User X calls WebJEA to execute "unlock user account"

• the script runs as gMSA on ServerA

• The script only contains a call similar to : Invoke-Command -ConfigurationName "JEA-UnlockUserFunction" -ComputerName ServerB -ScriptBlock { UnlockUserFunction @args } -ArgumentList $PSBoundParameters

• On ServerB (a Domain Controller) a JEA configuration is created, with the name "JEA-UnlockUserFunction" which allows calling "Invoke-UnlockUserFunction".

• Since parameters from WebJEA are passed on directly to Invoke-Function, as long as you use positional arguments, they will match up with whatever parameters you expose in the WebJEA script.

https://docs.microsoft.com/en-us/powershell/scripting/learn/remoting/jea/overview?view=powershell-7.2

Effectively, you limit the scope of the permission to whatever commands you have exposed on the JEA endpoints that the gMSA can call. Cleaning up permissions is a matter of looking through the JEA configurations on the DC.

It must be assumed that the WebJEA server is trustworthy of course, so you need to consider what it is you are trying to protect yourself from... If you trust the WebJEA gMSA, do you also trust the contents of the scripts that is executes? If you do not explicitly trust the gMSA / WebJEA server, you can use JEA to pull the elevation out of WebJEA and add some additional validation to the scripts somewhere else.