[Autogenerated] now let's tackle Windows PowerShell just
enough administration or JIA for short, what is the use case for?
PowerShell JIA,
well I mentioned that when a Windows server is enabled for
PowerShell remoting you have these session configuration,
endpoints and by default they're all the same.
That is the connecting user will normally identify with their
credentials and they will have whatever privileges their
credentials convey on that machine.
However, in the name of delegated administration,
that may not be what you want,
you may have say a support person who you want to give the
ability to connect to maybe an alternate session.
endpoint on that server that's heavily constrained to where that user might
be able to restart a service or might be able to check the status of a
service but not do anything else on that machine.
Your admins who should have full administrator privileges
would make sure to connect to the admin,
endpoint on that server?
This is the G a use case Just enough administration where we
can support PowerShell remoting in both administrative and
non administrative contexts.
The high level overview of configuring JIA on a server is as follows,
you need to create a couple PowerShell script files
that have their own extensions,
you'll see how this works in more detail in the demo but
first we have the role capability, script?
This is going to define what is available on that constrained,
endpoint are you allowing just certain cmdlet It's probably yes.
Are you allowing any compiled executable is to be used for
instance who am I ping trace route you may want to enable
some but then block all the rest.
This is a role capability script.
We then have the session configuration script that ties that role
capability script with a particular group or groups.
Long story short in order to connect to that constrained JIA
endpoint The user would have to be in a group that's allowed based
on that JIA configuration and once that happens they establish a
connection to that endpoint and they've been allowed in based on
their group membership.
They then would have all the privileges that are conveyed
only by that role capability script.
I'm getting a little ahead of myself After you create and
deploy your role capability and session configuration
scripts to the target server.
Normally you'll store them in the PowerShell modules path.
You would then register the geo session configuration with the server
and then lastly you make a remoting connection,
specifying that session configuration.
So that would be a training issue.
You would need your support personnel to know or maybe you just
give them a connection script that references the appropriate geo
session configuration that they would use with their enter PS
session where new session command. Now let's do that demo