Securing your infrastructure with Just Enough Administration

I was giving a talk about Just Enough Administration (JEA) at PSConfEU 2018 in Hannover and I also wanted to share my thoughts with you writing this blog post.

My PSConfEU presentation and demo code can be found on GitHub. The recording on the session will be released soon on the official PSConfEU YouTube channel (I will update this link, once the recording of my session is released).

Current Threat Landscape

When speaking to decision makers in IT, often I hear the statement "But we are having a hardware firewall and an antivirus software! Of course we are having a good security!!!".

Actually that was true fifteen years ago, but isn't anymore. Of course, firewall and antivirus vendors have secured their systems according to known threats. To breach a hardware firewall is really hard for an attacker (well, except if they have an implemented backdoor, but let's not talk about this).

So attackers moved on. Most attackers choose the easy way: They don't want to spend too much resources or time, if there are easier ways to exploit. And the easiest link in the chain is the human being, so they target the identities of an organization.

Once they find a way in, it takes only few hours to complete the attack, but several hundred days until they get detected. If they get detected.

Often Administrators are logging on least trust systems, using less secure connection methods like RDP, leaving their credentials behind. When credentials are left behind, an attacker can easily extract them and use them to lateral move and to log in onto other systems.

Most organizations also don't separate their assets and accounts into Tiers. Like this an attacker can easily escalate his privileges to finally gain access to your most valuable assets in a Windows Domain: Your domain controllers and other Tier 0 devices. Once he gained control over your DCs, he has almost complete control over your whole environment.

How can Just Enough Administration mitigate the risk?

Just Enough Administration is a PowerShell Security feature, which helps you to reduce the number of  full administrators having privileges on your systems. You define which commands your administrators are able to run and JEA enforces it for you. Cool, isn't it?

And having the current threat landscape of attackers, it can also help you protecting against credential theft, if you use it wisely.

As you are able to configure which accounts connect to your target system when using JEA, you can configure a virtual local account to do the work for you. So, you're not leaving your own credentials on your target machine and as this account is destroyed, once you terminate your session, it has no value to a potential attacker.

Use Cases

JEA is a great option to restrict high privileged operations which you'd like to outsource or to restrict service accounts and other users.

It is also a great idea if you prevent accounts leaving their hashes behind, as either a local virtual account is used or a group managed service account. Having a local virtual account configured, the account will be destroyed, once you terminate the session.

Potential use cases:

• High privileged operations outsourced
  • Junior Administrators
  • Supporter
  • Server Operators
• Service Accounts
• Client Help Desk
• Multi-Tenant Administration
• Auditing
• Lower trust system operations
• Securing “in-Tier” Credentials
• …and many more…

But please remember: JEA is not the blue pill to protect you from everything - JEA can also be bypassed, if there are vulnerabilities in your configuration. Therefore: if you outsource operations on high value systems, I'd still recommend using PAWs for performing those operations.

How does it work?

For configuring JEA, two configuration files are required:

• Role Capability File
• Session Configuration File

Role Capability File (= What)

In the role capability file you configure what commands can be performed by a role. You can define your own functions, define which modules are loaded and many more.

You may create a skeleton Role Capability File to have a first look at the possibilities:

 New-PSRoleCapabilityFile -Path c:\JEA-Test\PSRoleCapabilityFile.psrc

Session Configuration File (= Who)

In the Session Configuration file you assign your configured Role Capability to a user or a group. You may also configure some additional session options.

Create a skeleton Session Configuration File to have a look at the session configuration options:

 New-PSSessionConfigurationFile -Path c:\JEA-Test\PSSessionConfigurationFile.pssc

Registering JEA

Now that you created both configuration files (and hopefully configured a bit more than only the skeleton file), you have to register the JEA configuration to let the magic happen. You can do this either manual or via DSC.

Register JEA manually (here: registering the Operator Role from my demo):

 Register-PSSessionConfiguration -Name Operator -Path "$path\Operator-SessionConfigurationFile.pssc"

After Registering, you should restart WMI for your configuration to become active:

 Restart-Service -name Winrm

Establishing a JEA connection

When registering the JEA configuration, a new session configuration is created.

You may establish a remote session, but you can also connect locally via JEA:

 Enter-PSSession –ComputerName localhost –ConfigurationName Operator -Credential $DomainNetbiosName\Operator

Planning for the deployment

To implement a proper JEA configuration, you should identify which commands your users are using. In a second step you create your role capability and session configuration files to restrict your JEA pilot administrators. Deploy the configuration, test it and go back to the first step if needed - to configure even more granular commands.

Risks and misconfiguration

JEA can help you a lot to mitigate risks in your environment, but if there are flaws in your configuration, an attacker still can exploit JEA and take control over your environment.

Some examples of a bad configuration:

• Granting the connecting user admin privileges to bypass JEA

 PS> Add-LocalGroupMember -Member 'CONTOSO\jdoe' -Group 'Administrators’

 Add-ADGroupMember, Add-LocalGroupMember, net.exe, dsadd.exe

• Running arbitrary code, such as malware, exploits, or custom scripts to bypass protections

 PS> Start-Process -FilePath '\\san\share\malware.exe’

 Start-Process, New-Service, Invoke-Item, Invoke-WmiMethod, Invoke-CimMethod, Invoke-Expression, Invoke-Command, New-ScheduledTask, Register-ScheduledJob

• Wildcard configuration is evil
• Be careful when using the JEA helper tool
• Use signing to protect role capability files from tampering.
• Secure transcript files and event logs following the guidance in the blog post PowerShell ♥ the Blue Team.

And, if you don't remove other connection methods like remote desktop, none of this matters as JEA restricts only your PowerShell sessions.

JEA FAQ – most common concerns

When I'm talking about JEA, most of the time I hear the same concerns:

• Oh, it’s difficult to implement
• …is there a GUI?

Yes it is difficult to find out who uses which commands, but I'm already working with some friends on a solution which should ease the implementation. Also feel free to submit your Role Capability Configuration on GitHub.

...is there a GUI?

For a long time, that was the point when I had to (quietly) say 'no' and move on. But with the last release of Windows Admin Center (formerly Project Honolulu), the Windows Admin Center team implemented JEA support!

When I heard this, I was so euphoric and shouted out that now there is a GUI for JEA. But then I played around with Windows Admin Center and my joy faded, as there were only three predefined roles for JEA and no possibility to create custom roles.

At the time of writing this article (May 2018) only those three JEA roles were implemented yet in Windows Admin Center:

• Windows Admin Center Administrators: Allows users to view and manage most tools.
• Windows Admin Center Hyper-V-Administrators: Allows users to manage Hyper-V virtual machines and switches. Other tools are available in read-only mode.
• Windows Admin Center Readers: Allows users to view most tools, but doesn't allow them to make any changes.

But as I would love to have Windows Admin Center support also custom JEA roles, I created a UserVoice request: UserVoice Request for individual JEA roles in Windows Admin Center

So if you also think that individual JEA roles for Windows Admin Center would be an awesome idea, I really appreciate if you could vote for my UserVoice Request. I'm looking forward to the implementation to finally provide a GUI to administrators who are not familiar using PowerShell.

Further Security Mitigations

JEA is great, but please remember that it is not the blue pill for all your security problems. To secure your infrastructure, you should also consider several other mitigations, which are also described in the Securing Privileged Access Roadmap.

But always remember...