|
Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология Образование Политология Производство Психология Стандартизация Технологии |
|
|
Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология Образование Политология Производство Психология Стандартизация Технологии |
Enable PowerShell RemotingСтр 1 из 6Следующая ⇒
Table of Contents After reading this document, you should be able to author, deploy, use, maintain, and audit a Just Enough Administration (JEA) deployment on Windows Server 2016 PP1. Here are the topics we will cover: 1. Introduction: Briefly review why you should care about JEA. 2. Prerequisites: Set up your environment 3. Using JEA: Start by understanding the operator experience of using JEA. 4. Remake the Demo: Create a JEA Session Configuration from scratch. 5. Role Capabilities: Learn about how to customize JEA capabilities with Role Capability Files. 6. End to End - Active Directory: Make a whole new endpoint for managing Active Directory 7. Multi-machine: Discover how deployment and authoring changes with scale 8. Reporting on JEA: Discover how to audit and report on all JEA actions and infrastructure. 9. Appendix: Important skills and discussion points Introduction Motivation When you grant someone privileged access to your systems, you extend your trust boundary to that person. This is a risk; administrators are an attack surface. Insider attacks and stolen credentials are both real and common. This is not a new problem. You are probably very familiar with the principle of least privilege, and you might use some form of role based access control (RBAC) with applications that provide it. However, limited scope and large grained control limit the effectiveness and manageability of these solutions. Furthermore, there are gaps in RBAC coverage. For example, in Windows, privileged access is largely a binary switch, forcing you to give unnecessary permissions when adding users to the Administrator group. Just Enough Administration (JEA) provides a RBAC platform through Windows PowerShell. It allows specific users to perform specific administrative tasks on servers without giving them administrator rights. This allows you to fill in the gaps between your existing RBAC solutions, and simplifies management of those settings. Scope of this Guide The initial release of JEA, called xJEA, consisted of experimental DSC resources. Our experiences with xJEA helped us refine the JEA concept. Now, many of the capabilities from xJEA are moving into the underlying PowerShell infrastructure. Instead of building JEA on top of PowerShell Session Configurations, we are building JEA capabilities into PowerShell Session Configurations. Windows Server 2016 PP1 marks the first release of these new capabilities. This experience guide is solely concerned with this new underlying infrastructure. Prerequisites Initial State Before starting this section, please ensure the following: 1) You have either: a. An instance of Windows Server 2016 TP4 instance running b. An instance of Windows Server 2012 or 2012R2 with WMF 5.0 RTM 2) You have administrative rights on the server 3) The server is domain joined. See the Creating a Domain Controller section for instructions on creating a standalone domain. Enable PowerShell Remoting Management with JEA occurs through PowerShell Remoting. Run the following in an Administrator PowerShell window to ensure that this process is set up. Enable-PSRemoting
Using JEA This section focuses on understanding the end user experience of using JEA. In the prerequisites section, you created a demo JEA endpoint. We will use this demo to show JEA in action. In later sections, the guide will work backwards -- introducing the actions and files that made that end user experience possible. Key Concepts PowerShell Remoting: PowerShell remoting allows you to run PowerShell commands against remote machines. You can operate against one or many computers, and use either temporary or persistent connections. In this demo, you remoted into your local machine with an interactive session. JEA restricts the functionality available through PowerShell remoting. For more information about PowerShell remoting, run the following command: Get-Help about_Remote
“RunAs” User: When using JEA, a non-administrator “runs as” a privileged “Virtual Account.” The Virtual Account only lasts the duration of the remote session. That is to say, it is created when a user connects to the endpoint, and destroyed when the user ends the session. By default, the Virtual Account is a member of the local administrators group. On a domain controller, it is also a member of Domain Administrators. “Connected” User: The non-administrator user who runs as the “RunAs” user through PowerShell remoting. Remake the Demo Endpoint In this section, you will learn how to generate an exact replica of the demo endpoint you used in the above section. This will introduce core concepts that are necessary to understand JEA, including PowerShell Session Configurations. Test Out Your Endpoint Re-run the steps listed in the “Using JEA” section against your endpoint to confirm that your endpoint is operating as intended. To ensure you are operating against your new endpoint, run the following command instead of STEP 2: Enter-PSSession -ComputerName. -ConfigurationName JEADemo2 -Credential $NonAdminCred Key Concepts PowerShell Session Configuration: Sometimes referred to as PowerShell Endpoint, the figurative “place” where users connect and get access to PowerShell functionality. You can list the registered Session Configurations on your system by running Get-PSSessionConfiguration. When configured in a specific way, a PowerShell Session Configuration can be called a JEA Endpoint.
PowerShell Session Configuration File (.pssc): A file that, when registered, defines settings for a PowerShell Session Configuration. It contains specifications for user roles that can connect to the endpoint, the “run as” Virtual Account, and more. Role Definitions: The field in a Session Configuration File that defines the Role Capabilities granted to connecting users. It defines who can do what as a privileged account. This is the core of JEA’s RBAC capabilities. SessionType: A field in a Session Configuration File that represents default settings for a Session Configuration. For JEA Endpoints, this must be set to RestrictedRemoteServer. Security Descriptor Definition Language (SDDL): The SDDL defines who has access to an Endpoint, and is set when an Endpoint is registered. By default, access to an endpoint is limited to the groups listed in Role Definitions. PowerShell Transcript: A file containing an “over-the-shoulder” view of a PowerShell session. You can set PowerShell to generate transcripts for JEA sessions using the TranscriptDirectory field. For more information on transcripting, check out this blog post. Role Capabilities Overview In the above section, you learned that the RoleDefinitions field defined which groups had access to which Role Capabilities. You may have wondered, “What are Role Capabilities? ” This section will answer that question. Role Capability Contents We will start by examining and modifying the demo Role Capability file you used before. Imagine you have deployed your Session Configuration across your environment, but you have gotten feedback that you need to change the capabilities exposed to users. Operators need the ability to restart machines, and they also want to be able to get information about network settings. In addition, the security team has told you that allowing users to run “Restart-Service” without any restrictions is not acceptable. You need to restrict the services that operators can restart. STEP 1: Using PowerShell ISE running as an Administrator, open the following file: “C: \Program Files\WindowsPowerShell\Modules\Demo_Module\RoleCapabilities\Maintenance.psrc” STEP 2: You need to set the certain fields implement the changes you want to make:
This contains a few interesting examples: 1. You have restricted Restart-Service. Operators will only be able to use Restart-Service with the -Name parameter, and they will only be allowed to provide “Spooler” as an argument to that parameter. If you wanted to, you could also restrict the arguments using a regular expression using a “ValidatePattern”. 2. You have exposed all commands with the “Get” verb from the NetTCPIP module. Because “Get” commands typically don’t change system state, this is a relatively safe action. That being said, we strongly encourage examining every command you expose through JEA. 3. You have expose an executable (ipconfig) using VisibleExternalCommands. You can also expose scripts with this field. STEP 3: Save the file. STEP 4: Re-run the steps listed in the “Using JEA” section against your endpoint to confirm that your endpoint is operating as intended. Because you only modified the Role Capability file, you do not need to re-register the Session Configuration. This is an important point to make; PowerShell will find your updated Role Capability when a user connects. To ensure you are operating against your new endpoint, run the following command instead of STEP 2: Enter-PSSession -ComputerName. -ConfigurationName JEADemo2 -Credential $NonAdminCred STEP 5: Confirm that you can restart the computer by running Restart-Computer with the -WhatIf parameter (unless you actually want to restart the computer). Restart-Computer -WhatIf
STEP 6: Confirm that you can run “ipconfig” ipconfig
STEP 7: Confirm that Restart-Service only works for the Spooler service. Restart-Service Spooler #this should work Restart-Service WSearch #this should fail
STEP 8: Exit the session as before.
Exit-PSSession
Role Capability Creation In the next session, you will create a Session Configuration for AD Help Desk users. To prepare, we will create a blank Role Capability file to fill in for that section. In order to make this work, you will create a new module that will contain the role capability. In order for PowerShell to detect Role Capabilities automatically, you must put them in a “RoleCapabilities” folder in this module. PowerShell Modules are essentially packages of PowerShell functionality. They can contain PowerShell functions, cmdlets, DSC Resources, Role Capabilities, and more. STEP 1: Create a “Contoso_AD_Module” folder the modules directory. New-Item -Path “C: \Program Files\WindowsPowerShell\Modules\Contoso_AD_Module” -ItemType Directory
STEP 2: Create a blank module manifest. This module manifest will contain metadata about the module you are creating. New-ModuleManifest -Path ‘C: \Program Files\WindowsPowerShell\Modules\Contoso_AD_Module\Contoso_AD_Module.psd1’ -RootModule Contoso_AD_Module.psm1
STEP 3: Create a blank script module. You’ll use this file for custom functions in the next section. New-Item -Path “C: \Program Files\WindowsPowerShell\Modules\Contoso_AD_Module\Contoso_AD_Module.psm1” -ItemType File
STEP 4: Create a RoleCapabilities folder in the AD_Module folder. PowerShell can only automatically discover Role Capabilities that are located in a “RoleCapabilities” folder within a module. New-Item -Path “C: \Program Files\WindowsPowerShell\Modules\Contoso_AD_Module\RoleCapabilities” -ItemType Directory
STEP 5: Create a blank Role Capability in your RoleCapabilities folder. Running this command without any additional parameters just creates a blank template. New-PSRoleCapabilityFile -Path ‘C: \Program Files\WindowsPowerShell\Modules\Contoso_AD_Module\RoleCapabilities\ADHelpDesk.psrc’
Congratulations, you have created a blank Role Capability File. It will be used in the next section. Key Concepts Role Capability (.psrc): A file that define “ what ” a user can do at a JEA endpoint. It details a whitelist of things like visible commands, visible applications, and more. In order for PowerShell to detect Role Capabilities automatically, you must put them in a “RoleCapabilities” folder in a valid PowerShell module. PowerShell Module: A package of PowerShell functionality. It can contain PowerShell functions, cmdlets, DSC Resources, Role Capabilities, and more. In order to be automatically loaded, PowerShell Modules must be located on $env: PSModulePath. Prerequisites To follow this section step-by-step, you’ll need to be operating on a domain controller. If you don’t have access to your domain controller, don’t worry. Try to follow along with by working against some other scenario or role with which you are familiar. Find Resources Here is a set of online resources that might have come up in your research on creating an Active Directory Toolkit: · Active Directory PowerShell Overview · CMD to PowerShell Guide for Active Directory Make a List Here is a set of ten actions that you will be working from in the remainder of this section. Keep in mind this is simply an example, your organizations requirements may be different:
Key Concepts NoLanguage Mode: When PowerShell is in “NoLanguage” mode, users may only run commands; they cannot use any language elements. For more information, run Get-Help about_Language_Modes.
RunAsVirtualAccountGroups: You can use this element to set the permissions of the “RunAs” Virtual Account. The token created for the Virtual Account will appear to PowerShell Functions: PowerShell functions are bits of PowerShell code that you can call by name. For more information, run Get-Help about_Functions.
ValidateSet/ValidatePattern: When exposing a command, you can restrict valid arguments for specific parameters. A ValidateSet is a specific list of valid commands. A ValidatePattern is a regular expression that the arguments for that parameter must match. Example Script Here’s an example script for deployment. To use it in your environment, you’ll have to use the names/paths of real file shares and modules. # First, copy the session configuration and modules (containing role capability files) onto a file share you have access to. Copy-Item -Path 'C: \Demo\Demo.pssc' -Destination '\\FileShare\JEA\Demo.pssc' Copy-Item -Path 'C: \Program Files\WindowsPowerShell\Modules\SomeModule\' -Recurse -Destination '\\FileShare\JEA\SomeModule'
# Second, author a setup script (C: \JEA\Deploy.ps1) to run on each individual node # Contents of C: \JEA\Deploy.ps1 New-Item -ItemType Directory -Path C: \JEADeploy Copy-Item -Path '\\FileShare\JEA\Demo.pssc' -Destination 'C: \JEADeploy\' Copy-Item -Path '\\FileShare\JEA\SomeModule' -Recurse -Destination 'C: \Program Files\WindowsPowerShell\Modules' # Remember, Role Capability Files are found in modules if(Get-PSSessionConfiguration -Name JEADemo -ErrorAction SilentlyContinue) { Unregister-PSSessionConfiguration -Name JEADemo -ErrorAction Stop }
Register-PSSessionConfiguration -Name JEADemo -Path 'C: \JEADeploy\Demo.pssc' -SecurityDescriptorSddl 'SDDL From Single Machine Deployment Here' Restart-Service 'WinRM' Remove-Item -Path 'C: \JEADeploy' #Don't forget to clean up!
# Third, invoke the script on all of the target machines. # Note: this requires PowerShell Remoting be enabled on each machine. Enabling PowerShell remoting is a requirement to use JEA as well. Invoke-Command –ComputerName 'Node1', 'Node2', 'Node3', 'NodeN' -FilePath 'C: \JEA\Deploy.ps1'
# Finally, delete the session configuration and role capability files from the file share. Remove-Item -Path '\\FileShare\JEA\Demo.pssc' Remove-Item -Path '\\FileShare\JEA\SomeModule' -Recurse
Modifying Capabilities When dealing with many machines, it’s important that modifications are rolled out in a consistent manner. Once JEA has DSC Resources, this will help ensure your environment is in sync. Until that time, we highly recommend you keep a master copy of your session configurations and redeploy each time you make a modification. Removing Capabilities To remove JEA from your systems, use the following command on each machine: Unregister-PSSessionConfiguration -Name JEADemo Reporting on JEA Because JEA allows non-privileged users to run in a privileged context, logging and auditing are extremely important. In this section, we’ll run through the tools you can use to help you with logging and reporting. Reporting on JEA Actions PowerShell Event Logs When you have module logging turned on, all PowerShell actions are also recorded in regular Windows Event logs. This is slightly messier to deal with when compared to transcripts, but the level of detail it gives you can be useful. In the “PowerShell” operational log, Event ID 4104 will record each command invoked if you have enabled module logging. Other Event Logs Unlike PowerShell logs and transcripts, other logging mechanisms will not capture the “Connected User”. You will need to do some correlation between other logs and PowerShell logs to match up actions taken. In the “Windows Remote Management” operational log, Event ID 193 will record the Connecting User’s SID and Name, as well as the RunAs Virtual Account’s SID to assist with this correlation. You may have also noticed that the name of the RunAs Virtual Account Get-PSSessionConfiguration In order to accurately report on the state of your environment, it’s critical that you be able to report on the number of JEA endpoints you have set up. “Get-PSSessionConfiguration” does this on each machine. Get-PSSessionCapability Manually reporting on the capabilities of any given user through a JEA endpoint can be quite complex. You would potentially need to inspect several role capabilities. Fortunately, the “Get-PSSessionCapability” cmdlet does this. To test this out, run the following command from an administrator PowerShell prompt: Get-PSSessionCapability -Username OperatorUser -ConfigurationName JEADemo2 Conclusion After completing this guide, you should have the tools and vocabulary to create your own JEA endpoint. Thanks for reading! Appendix Prerequisites 1. The machine is on an internal network 2. The machine is not joined to an existing domain 3. The machine has the “xActiveDirectory” module installed (install instructions here) DSC Instructions
Copy the following script in PowerShell to make your machine a Domain Controller in a new domain. Set up Users and Groups If you created a domain from scratch (as per the Creating a Domain Controller section), you can use this section to create a few non-administrator groups and users. #Make Groups $NonAdminOperatorGroup = New-ADGroup -Name " JEA_NonAdmin_Operator" -GroupScope DomainLocal -PassThru $NonAdminHelpDeskGroup = New-ADGroup -Name " JEA_NonAdmin_HelpDesk" -GroupScope DomainLocal -PassThru $TestGroup = New-ADGroup -Name " Test_Group" -GroupScope DomainLocal -PassThru #Make Users $OperatorUser = New-ADUser -Name " OperatorUser" -AccountPassword (ConvertTo-SecureString " pa`$`$w0rd" -AsPlainText -Force) -PassThru Enable-ADAccount -Identity $OperatorUser $HelpDeskUser = New-ADUser -name " HelpDeskUser" -AccountPassword (ConvertTo-SecureString " pa`$`$w0rd" -AsPlainText -Force) -PassThru Enable-ADAccount -Identity $HelpDeskUser #Add Users to Groups Add-ADGroupMember -Identity $NonAdminOperatorGroup -Members $OperatorUser Add-ADGroupMember -Identity $NonAdminHelpDeskGroup -Members $HelpDeskUser New-ADGroup TestGroup -GroupScope DomainLocal
On Blacklisting After playing around with JEA, many customers ask about blacklisting commands. This is an understandable request, but it is not going to happen anytime soon. There are three primary reasons for this. 1. We designed JEA to limit operators to only the actions they need to do. A blacklist is the opposite.
2. PowerShell command authors did not design PowerShell commands with the JEA in mind. On a fresh install of Windows Server 2016 TP3, there are about 1520 commands immediately available. The threat models for these commands did not include the possibility that a user would be running commands as a more privileged account. For example, certain commands allow for code injection by design (e.g. Add-Type and Invoke-Command in the core PowerShell module). JEA can warn you when you expose the specific commands we know about, but we have not re-assessed every other command in Windows based on the new threat model. You must understand the capabilities of the commands you exposing through JEA.
3. Furthermore, even if JEA blocked all commands with code-injection vulnerabilities, there is no guarantee that a malicious user would not be able to carry out a blacklisted action with another related command. Unless you understand all of the commands that you are exposing – it is impossible for you to guarantee that a certain action is not possible. The burden is on you to understand what commands you are exposing, whether they are using a whitelist or a blacklist. The number of commands a blacklist would expose is unmanageable, so JEA does not allow blacklists. Signing PSSC and PSRC Files Functions vs. Cmdlets PowerShell commands written in PowerShell are PowerShell Functions. PowerShell commands written as specialed.NET classes are PowerShell Cmdlets. Typically, built in commands are Cmdlets, but it is best to check the command type by running Get-Command. VisibleProviders You will need to expose the providers your command need. The most common is the FileSystem provider, but you may also need to expose others, like the Registry provider. For an introduction to providers, I recommend this Hey, Scripting Guy blog post: http: //blogs.technet.com/b/heyscriptingguy/archive/2015/04/20/find-and-use-windows-powershell-providers.aspx
Table of Contents After reading this document, you should be able to author, deploy, use, maintain, and audit a Just Enough Administration (JEA) deployment on Windows Server 2016 PP1. Here are the topics we will cover: 1. Introduction: Briefly review why you should care about JEA. 2. Prerequisites: Set up your environment 3. Using JEA: Start by understanding the operator experience of using JEA. 4. Remake the Demo: Create a JEA Session Configuration from scratch. 5. Role Capabilities: Learn about how to customize JEA capabilities with Role Capability Files. 6. End to End - Active Directory: Make a whole new endpoint for managing Active Directory 7. Multi-machine: Discover how deployment and authoring changes with scale 8. Reporting on JEA: Discover how to audit and report on all JEA actions and infrastructure. 9. Appendix: Important skills and discussion points Introduction Motivation When you grant someone privileged access to your systems, you extend your trust boundary to that person. This is a risk; administrators are an attack surface. Insider attacks and stolen credentials are both real and common. This is not a new problem. You are probably very familiar with the principle of least privilege, and you might use some form of role based access control (RBAC) with applications that provide it. However, limited scope and large grained control limit the effectiveness and manageability of these solutions. Furthermore, there are gaps in RBAC coverage. For example, in Windows, privileged access is largely a binary switch, forcing you to give unnecessary permissions when adding users to the Administrator group. Just Enough Administration (JEA) provides a RBAC platform through Windows PowerShell. It allows specific users to perform specific administrative tasks on servers without giving them administrator rights. This allows you to fill in the gaps between your existing RBAC solutions, and simplifies management of those settings. Scope of this Guide The initial release of JEA, called xJEA, consisted of experimental DSC resources. Our experiences with xJEA helped us refine the JEA concept. Now, many of the capabilities from xJEA are moving into the underlying PowerShell infrastructure. Instead of building JEA on top of PowerShell Session Configurations, we are building JEA capabilities into PowerShell Session Configurations. Windows Server 2016 PP1 marks the first release of these new capabilities. This experience guide is solely concerned with this new underlying infrastructure. Prerequisites Initial State Before starting this section, please ensure the following: 1) You have either: a. An instance of Windows Server 2016 TP4 instance running b. An instance of Windows Server 2012 or 2012R2 with WMF 5.0 RTM 2) You have administrative rights on the server 3) The server is domain joined. See the Creating a Domain Controller section for instructions on creating a standalone domain. Enable PowerShell Remoting Management with JEA occurs through PowerShell Remoting. Run the following in an Administrator PowerShell window to ensure that this process is set up. Enable-PSRemoting
|
Последнее изменение этой страницы: 2019-05-04; Просмотров: 196; Нарушение авторского права страницы