Good day, Cloud Gurus, and welcome back.
In this lesson, we're going to take a look
at the wonderful Just Enough Administration, or JEA.
Let's take a look at what we're going to cover.
First up, I'll introduce you to JEA and why it's so great,
and then we'll take a look at what's involved
to get it set up, and then finally, we'll take a look
at a demo where we will configure
and use Just Enough Administration.
I can't wait.
Let's get started.
So, we've taken a look at how you can use PowerShell
remoting to remotely manage your Windows server.
But one of the challenges of PowerShell remoting
is that by default it requires administrator privileges
on the remote computer,
and in some cases, this might be okay,
but in most it's not recommended.
A security best practice to be aware of
is the principle of least privilege,
which is a concept where you should restrict
a user's permissions to only those permissions
they require to complete the tasks required
for their job role,
and we know that granting everyone
administrative privileges on every server
in our environment is most definitely not least privilege.
So, how can we implement least privilege
in Windows server?
While you can use privilege groups in Active Directory,
or on the local server,
but often these include broad permissions.
But what if you wanted to be really specific?
For example, only allow your help desk staff
to reset user passwords and clear the DNS cache
on your domain controllers.
That's not really possible with Active Directory groups.
I mean, you could delegate administrative control
in Active Directory, but to allow your users
to manage Active Directory integrated DNS servers,
you would need to grant them domain admin privileges,
so they can connect to the domain controller
and manage DNS using the consult tools
or PowerShell remoting.
The good news is that when a user connects to a server
using PowerShell remoting,
they use a default session configuration,
but you can change the session configuration
used when they connect.
And these session configurations can be customized.
Just Enough Administration allows you to granularly control
who can connect to a server using PowerShell remoting
and what actions they can perform once they're connected.
And who can connect and what level
of privileges they have when they connect,
is defined in what's known as a session configuration file.
And what actions they can perform once they are connected
is defined in a role capability file.
So, what do we need in order
to use Just Enough Administration?
Well, we need to have at least Windows Server 2016,
or Windows 10 to get Just Enough Administration
support out of the box.
For earlier versions of Windows, you'll need to have
Windows management framework 5.1 installed,
and you'll also need administrative privileges
on the remote computer to set up JEA.
And the last requirement is kind of obvious,
but you'll need to have PowerShell remoting configured.
To configure JEA you first log on to the remote computer
and create a PowerShell module folder and manifest
using the new module manifest PowerShell commandlet,
and then you configure the role capabilities
using the new PS role capability file commandlet,
and then you configure the session configuration
using the New-PSSession configuration file commandlet,
and then, finally, you register the session configuration
using the register PS session configuration
PowerShell commandlet.
Now, make sure you take note of the PowerShell
file extensions used here.
When we create a module manifest,
we use a PSD1 extension.
When we create a PowerShell role capability file
we use a PSRC file extension,
and when we create a new session configuration file,
we use the PSSC file extension.
All right, let's take a look at a demo of configuring
Just Enough Administration.
In this demo we will configure an Active Directory
group, help desk admins using the principle of least
privilege, so they can perform only account unlocks
and clear the DNS cache on our domain controller
CORP-BNE-DC01, and to do this, we will define
the role capabilities and create a session configuration
on CORP-BNE-DC01, and then we will log on
to our administrative server as a member
of the help desk admins group and use PowerShell remoting
to test Just Enough Administration.
Let's take a look at the demo.
All right, so, here I am logged onto our corporate
domain controller and note that our domain controller
is running server core and so we could use
the PowerShell ISE in this demo.
To make it easier to follow, I've installed the server app
compatibility features on demand on this server core
installation, but you can perform all of these functions
using PowerShell remoting.
It just will be easier to follow,
if I use the ISE directly on this domain controller.
Now, let's get a list of all the users in the help desk
admins group that we're going to use to delegate control
using Just Enough Administration.
To do that, we're going to run the Get-ADGroupMember,
PowerShell cmdlet.
We'll specify help desk admins as the group name,
and then we'll select just the names
of the users in that group.
All right, and we can see that Lia is in
the help desk admins group.
So, let's use Lia to test JEA.
Okay, that was not intentional.
Let's move on.
Let's first, go ahead and create a new PowerShell module.
To do that, we're going to create it
in the PowerShell module path.
Now, PowerShell will look for modules anywhere
that's defined in the environmental variable PS module path.
So, let's take a look at the PS module path
environmental variable and then we'll use one
of the directories from that location.
All right, and we can see we've got a semicolon
separated list of the locations that PowerShell
will look for modules.
Let's go ahead and use the modules directory in system 32.
So, we'll go ahead and select the last one
in this list and we'll copy that,
and then we'll change directory using Set-Location
to that path.
All right, now, let's create a module folder
for our JEA session configuration.
To do that, we're going to use the new item
PowerShell cmdlet.
We'll specify the name of help desk admin
and we'll specify that we want to create a directory.
All right, and now let's change our directory
into that new directory we've just created,
and I'll just use tab to complete that directory name,
and now we need to create a new module and to do that,
we need to create a manifest.
So, we're going to do that using the new module manifest
PowerShell cmdlet and we'll use the current path,
and specify a name of help desk admin.psd1.
Now, PowerShell is going to look in the modules folder
for modules that contain a role capabilities folder.
So, let's go ahead and create a new role capabilities
folder within our module folder.
To do that, we'll use new item again,
and now let's change directory into that role capabilities
directory and we'll just use tab to complete that again.
Now, let's create a role capability file using
the new PS role capability file and we'll specify a path
in this current directory and use the extension PSRC,
but before we do that, the screen's getting
a little bit messy, so let's go ahead
and clear this screen and then we'll run that command.
So, we're going to go ahead and run new PS role capability
file and specify the path in the current directory.
Now, let's go ahead and edit that file,
and we'll use the PowerShell ISE to do that.
So, we'll just run ISE and then the name of the file,
and we'll use tab complete to get the name of the file.
Now, when the users connect using this role capability file,
we need to specify which modules to import for the users.
So, to do that, we'll modify the modules to import property.
So, we'll just take out this comment,
and then we will specify our own list of modules here,
and we're going to set this
to Active Directory and DNS server.
And now, we also want to allow our users
to run the clear DNS certification PowerShell cmdlet.
So, let's run Get-Command, Clear-DnsServerCache,
and we can see here that the command type
is a function, so we can make it available
using the visible functions property.
So, let's go ahead and edit that,
and we'll go ahead and set this to Clear-DnsServerCache,
and now, we also want to allow users to unlock Active
Directory accounts, and we want to allow them to do that
using the unlock AD account PowerShell cmdlet.
So, let's run get command, Unlock-ADAccount,
and determine whether it is a function or a cmdlet,
and we can see that this command type is a cmdlet.
So, let's go ahead and add that to the visible cmdlets.
So, we'll remove the comment from visible cmdlets,
and we'll specify one visible cmdlet
as Unlock-ADAccount.
Now, in the real world, you also might want
to allow your help desk to reset user passwords,
but you'll likely want to restrict that further.
Now, you can do that by allowing only specific parameters
to be run when the cmdlet is executed,
so that they can't reset the password for admin accounts,
but for our purposes this is fine.
So, let's go ahead and save and close this.
Now, that we've defined what can be done,
let's define who can do it,
and to do that, we're going to create a new session
configuration file, using the name helpdeskAdmin.pssc.
Now, let's go ahead and open that file
in the PowerShell ISE.
The first change we need to make here is we need
to change the session type to restricted remote server.
So, we'll just copy that from here,
and we're not going to change this setting,
but just be aware that you can set a transcript directory,
so that all of the commands that are executed
in this session can be logged to a specific directory
on this server.
The other thing that we do need to change, though,
is we need to specify that we want to run
as a virtual account.
So, I'm going to uncomment this RunAs
VirtualAccount property,
and this will allow the user to execute commands
on that target computer as an administrator.
Now, on domain controllers, this virtual administrator
account is a domain admin.
So, you need to be very careful which commands
you're allowing the users to execute
against a domain controller.
And now, it's also important to point out here
that if you wanted to have a more secure configuration,
you could use a group managed service account instead,
which I'd recommend in a production environment.
Now, the last property that we need to change
is the RoleDfinitions property,
and this specifies which users in groups
are allowed to use which role capabilities.
So, we'll go ahead and uncomment RoleDefinitions,
and then we're going to specify help desk admins
is allowed to use the help desk admin role
capability that we created earlier.
So, I'll go ahead and modify this line here,
and then we can go ahead
and delete the remainder of this line,
making sure we leave the additional curly braces
and the semicolon on the end of this.
So, we can go ahead and save and close this,
and now we need to register the session configuration
using the register PS session configuration PowerShell
commandlet and we need to specify the name,
and the path to our session configuration file.
And we need to make sure that we specify the file extension
of the session configuration file, which is PSSC.
So, we'll go ahead and run that command.
All right, we've now registered that session configuration.
We now need to restart the Windows remote
management servers, and to do that we're going to use
the restart service PowerShell cmdlet
and specify the servers name, WinRM.
All right, now let's connect to this domain controller
from our administrative server using our delegated
user Lia Forney, and we'll connect using PowerShell remoting
and specify the configuration.
All right, let's launch PowerShell,
and we'll say yes to the user account control prompt,
and now we can connect using PowerShell remoting
using the Enter-PSSession session PowerShell cmdlet,
and connect using Just Enough Administration using
the session configuration help desk admin that we created.
We need to specify a configuration name parameter
when we enter this PS session.
All right, we're now connected using the session
configuration that we specified.
Now, let's run Get-Command to see which commands
are available to Lia in this remote session.
To do that, we'll use Get-Command, and we can see here,
there's a very limited number of PowerShell cmdlets
available, but the 2 that we specified
in the role capability file are available.
So, let's go ahead and test out one of those cmdlets.
We'll use Clear-DNSServerCache,
and we'll say yes to confirm that.
All right, and we've successfully cleared
the DNS server cache on this domain controller
using a user that is not a member of the domain admins
or the administrators group on that domain controller.
All right, that concludes this demo.
Let's wrap up with a bit of a summary
of what we've covered in this lesson.
All right, so what have we covered in this lesson?
The principle of least privilege is about restricting
permissions to only those required for a task or a role.
And Just Enough Administration, or JEA,
allows you to implement the principle
of least privilege with PowerShell remoting,
and you can configure Just Enough Administration
by creating a new role capability file with the New-
PSRoleCapabilityFile PowerShell cmdlet
to define what can be done in a JEA remote session,
and this file has the extension PSRC.
Remember that one for the exam.
And you also need to create a session configuration file
with the New-PSSession configuration file PowerShell
commandlet to define who can use the defined roles,
and this creates a dot PSSC file.
And then, finally, you register the session configurations
with the Register-PSSession configuration
PowerShell commandlet.
All right, that concludes this lesson.
Thanks for being with me.
I hope you found it useful,
and I look forward to seeing you in the next lesson.