Quantcast
Channel: Hey, Scripting Guy! Blog
Viewing all articles
Browse latest Browse all 3333

Weekend Scripter: Taking JEA for a Spin—Part 2

$
0
0

Summary: Thomas Rayner explores how to restrict Active Directory management with JEA in Windows Server 2016.

Thomas Rayner, Cloud and Datacenter Management MVP, continues his two-part series about an exciting new feature in Windows Server 2016, Just Enough Admin (JEA). Today we’ll investigate how JEA can be applied in a situation where a limited user has permissions to run specific Active Directory queries.

Yesterday in Taking JEA for A Spin—Part 1, I tackled code promotion. I showed how to configure JEA so that a connecting user could run only a specially crafted script. Today, the example use case I’m using is that I want a limited user to be able to run a few very specific Active Directory-related commands. Maybe these limited users are Help Desk staff who field calls from users with trouble, and I want them to do a little digging before coming to Active Directory admins. Here are my requirements:

Users must be able to:

  • Perform a Get command on any user, but with limited parameters.
  • Get the following properties: MemberOf, LockedOut, Enabled, PasswordLastSet.
  • Use the following filter: Office –like ‘Home*’.

Users must NOT be able to:

  • Interact with other files or systems on the server.
  • Perform any other Active Directory-related actions.

Let’s get to it! I am going to set up a location for this JEA configuration to live.

Image of command output

Now, I’ve got to set up my PowerShell Session Configuration (PSSC) file like yesterday.

Image of command output

My changes here are very limited. I am changing the session type to RestrictedRemoteServer from Default (line 16 in the following image)—otherwise, none of this will work correctly. I’m also assigning my Reg Users group to the role Help Desk (line 31 in the following image). I will define this in a moment. I have a user named Reg Guy in the Reg Users group.

Image of command output

I’m now done with the PSSC so I’ll save and close it. It’s time to set up that Help Desk role. I’ll start by creating a RoleCapabilities folder in the same location as the PSSC and creating a new PowerShell Role Capabilities (PSRC) file. My PSRC’s name must match the RoleCapability I assigned to my Reg Users group in the PSSC.

Image of command output

In ISE, I’m going to enable the Active Directory functionality I described above. On line 19 of the PSRC, I can include modules to import. I’m bringing in the Active Directory module. On line 25, I can enable the specific cmdlets and restrictions I identified previously.

Image of command output

Let’s take a closer look at line 25. I’ll break it down into its parts:

  • VisibleCmdlets = @{ }
    The very first part of this line wraps the rest of the content and labels it as cmdlets that I’m making visible to my limited user. Next, I have to put something between the curly braces.
  • VisibleCmdlets = @{ Name = 'Get-ADUser' }
    As it stands now, I’ve white-listed the Get-ADUser command, without specifying any restrictions on parameters. By default, I’ve white-listed every parameter combination possible. Let’s fix that now.
  • VisibleCmdlets = @{ Name = 'Get-ADUser'; Parameters = @{ Name = 'Identity' } }
    The first parameter I’m specifying is Identity. I’m allowing any account to be retrieved by my limited user, so this particular item isn’t very interesting. Without specifying ValidateSet or ValidatePattern for the Identity parameter, I’m allowing any value to be specified. I’m also restricting the Properties and Filter parameters, though.
  • VisibleCmdlets = @{ Name = 'Get-ADUser'; Parameters = @{ Name = 'Identity' }, @{ Name = 'Properties'; ValidateSet = 'MemberOf','LockedOut','Enabled','PasswordLastSet' }, @{ Name = 'Filter'; ValidateSet = "Office -like 'Home*'" } }

You can see the Properties parameter is being validated against a set of allowed values: MemberOf, LockedOut, Enabled, and PasswordLastSet. The Filter parameter only has one allowable value in its valid set: Office –like ‘Home*’.

Let me now save and apply this JEA configuration to an endpoint.

Image of command output

There are some scary looking warnings that I can safely ignore in my lab. Let’s see what kind of experience Reg Guy gets when he connects to this new JEA constrained session. Reg Guy already has basic rights to create a remote connection to this server.

Image of command output

Everything looks great! Reg Guy is allowed to connect and use Get-ADUser—in this case, for himself. He’s allowed to retrieve the LockedOut property, which isn’t returned by default, but he can’t request all the properties. Reg Guy can also run the filter we allowed. In this case, no users have an Office attribute that matches the pattern.

Thanks for joining me on this weekend scripting adventure, proving some use cases for JEA. I hope I’ll see you again soon.

~Thomas

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy


Viewing all articles
Browse latest Browse all 3333

Trending Articles