Follow

Configuring Windows Server for Monitoring via WinRM

About

This article will describe how to prepare Windows servers for monitoring using the Microsoft Windows ZenPack using two methods, Group Policy (GPO) and Individual Server configuration.  This will cover Windows Server version 2008, 2012, 2016.  The options are identical in each version, but how one accesses a Group Policy Object will differ from version to version.  This article assumes one has a sufficient level of knowledge with Windows administration.  If you are unsure of how to proceed, you should contact your Windows Administrators.

Applies To

Windows Server 2008 & R2

Windows Server 2012 & R2

Windows Server 2016

About Windows Authentication for WinRM Monitoring

Like any monitoring system, Zenoss must authenticate to the Windows systems it will monitor using either local system or Windows domain credentials. The Windows user account used for WinRM authentication must have specific permissions granted on each Windows system to be monitored. By default, Windows Administrator accounts already have the necessary permissions, but best practices dictate that Administrator accounts not be used for purposes such as WinRM monitoring. Instead, a dedicated User account (a “service account”) should be created specifically for the purpose of WinRM monitoring with only the necessary permissions granted to the account.

Instead of manually editing the necessary permissions, a Windows PowerShell®, hereafter referred to as PowerShell, script can be used to modify the necessary permissions in a single step. For administrator convenience, Zenoss has created a sample script that modifies the permissions necessary for an example service account (“zenny” in the case of a domain user, or “benny” in the case of a local user account). The zenoss-lpu.ps1 script can be downloaded from https://github.com/zenoss/microsoft.tools/tree/develop/lpu. The file can be edited as necessary to suit specific production environments.

Note: The sample script includes two lines that must be located and deleted before the functions in the script will execute. These lines have been deliberately included to encourage administrators to thoroughly review the script before deploying it to ensure (i) that administrators fully understand the functions it performs and (ii) they have made any necessary edits before deploying it. 

The relevant sections below describe methods to configure Windows system permissions using a PowerShell script such as zenoss-lpu.ps1 that has been tailored to a specific environment.

Configuring Windows Server Using Group Policy

  1. Log on to a domain controller as a user with 'Domain Admin' privileges.
  2. Open Group Policy Management.
  3. Navigate to your target domain.
  4. Right-click Group Policy Objects and select New. In the form that displays:
    1. Enter a name for your new Group Policy Object, for example, WinRM_Monitoring.
    2. Leave "(none)" in the Source Starter GPO field.
    3. Click OK to save and exit the form.
  5. Select your new Group Domain Policy Object, WinRM_Monitoring, for example.
  6. Right click your new Group Domain Policy Object and select Edit to open the Group Policy Management Editor.
  7. Expand the Computer Configuration section of the tree and navigate the tree to:
    • Policies\Administrative Templates:Policy...\Windows Components\Windows Remote Management(WinRM)
  8. Enable remote server management:
    1. Click on WinRM Service to access the WinRM Service Group Policy settings in the right pane.
    2. Double-click the Allow remote server management through WinRM property.
    3. Click the Enabled radio button.
    4. Place an asterisk as a wildcard (' * ') in the IPv4 filer and IPv6 fields or specify a range of IP addresses on which WinRM will listen.
    5. Click OK at the bottom to submit the form.
  9.  Authentication:
    1. Domain:
      1. No changes needed. Kerberos is enabled by default and uses encrypted traffic.
    2. Basic:
      1. Enable authentication:
        • Double-click the Allow Basic authentication property in the right pane.
        • Select the Enabled radio button.
        • Click OK at the bottom to submit the form.
      2. Specify unencrypted traffic:
        • Double-click the Allow unencrypted traffic
        • Select the Enabled radio button.
        • Click OK at the bottom to submit the form.
  10. Select Windows Remote Shell in the left pane to set its Group Policy This is located in the group policy tree in the following location (which might be located right below WinRM service in the tree):
    • Computer Configuration\Policies\Administrative Templates\Windows Components\Windows Remote Shell
  11. Configure remote shell access:
    1. In the right pane, double-click Allow Remote Shell Access.
    2. Select the Enabled radio button.
    3. Click OK at the bottom to submit the form.
  12. Configure shell processes to allow for multiple processes to be run simultaneously:
    1. In the right pane, double-click Specify maximum number of processes per Shell.
    2. Select the Enabled radio button.
    3. Enter the value 2000000000(without commas or spaces) in the MaxProcessPerShell field.
    4. Click OK at the bottom to submit the form.
  13. Configure the number of remote shells per user:
    1. In the right pane, double-click Specify maximum number of remote shells per user.
    2. Select the Enabled radio button.
    3. Enter the value 2000000000(without commas or spaces) in the MaxShellsPerUser field.
    4. Click OK at the bottom to submit the form.
  14. Configure idle shell timeout value to automatically kill any orphaned shells:
    1. In the Right pane, double-click Specify Shell Timeout.
    2. Select the Enabled radio button.
    3. Enter the value 600000 (without commas or spaces) in the ShellTimeOut field.
      • Shells can be orphaned due to zenpython or zenmodeler daemons stopping while performing queries.  This setting will kill an idle remote shell after 10 minutes.
    4. Click OK at the bottom to submit the form.

Configuring Firewall Group Policies

WinRM listens on port 5985 when data payload encryption is not used and on port 5986 when encryption is used. Additionally, ICMP (ping) requests must be enabled because Zenoss uses them as a source of availability monitoring.

The appropriate port must be opened on the firewalls of monitored servers. You can use Group Policy to open the required ports on all servers across the organization.

  1. In the Group Policy Manager Editor, navigate to:

Computer Configuration\Policies\Windows Settings\Security Settings\Windows Firewall with Advanced Security\Windows Firewall with Advanced Security - LDAP;...\Inbound Rules

  1. Create a new Inbound Rules policy for Windows Remote Management:
    1. Right click Inbound Rules in the left pane.
    2. Select New Rule...
    3. Select the Predefined radio button.
    4. Select Windows Remote Management from the drop down list.
    5. Click Next.
    6. Ensure that all items in the list are checked.
    7. Click Next.
    8. Ensure that the Allow the connection radio button is selected.
    9. Click Finish.
  1. Create a new Inbound Rules policy for Echo Request ICMP (ping) requests:
    1. Right click Inbound Rules in the left pane.
    2. Select New Rule... Select the Predefined radio button.
    3. Select File and Printer Sharing from the drop down list.
    4. Click Next.
    5. Ensure the check boxes for the following items are selected:
      • File and Printer Sharing (Echo Request-ICPMv4-IN)
      • File and Printer Sharing (Echo Request-ICPMv6-IN)
      • You can de-select any additional check boxes unless you require them specifically.
      • Click Next.
      • Ensure that the Allow the connection radio button is selected.
      • Click Finish.
  1. Exit the Group Policy Management Editor.
  2. Link your new GPO to one or more Organizational Units (OU) containing servers to which you wish to have the policies applied. Alternatively, you can apply the policies to all Windows servers in the domain by linking the new GPO to the domain itself. To link the GPO to the domain, complete the following process.  Note: Substitute a specific OU for the domain if you want to link only to a subset of servers.
    1. Right-click your domain in the left pane of the Group Policy Management
    2. Choose Link an Existing GPO...
    3. Select your new GPO, WinRM_Monitoring for example, from the list that displays.
    4. Click OK to complete the process.
  3. Exit the Group Policy Management window.
  4. Before adding servers to Zenoss for monitoring, wait a sufficient amount of time for Group Policy to automatically refresh on the server(s). Alternatively, you can manually refresh Group Policy from the command prompt of target servers using this command:
    • gpupdate /force

Configuring Windows Credentials in Zenoss

When one or more servers are ready for addition to Zenoss, perform the following steps within the Zenoss web interface. If the same user account name was created on each server, the following procedure will specify it for all servers in the device class: 

  1. Navigate to the Infrastructure page.
  2. Select the Server/Microsoft/Windows device class.
  3. Click the Details icon.
  4. Click Configuration Properties in the left pane.
  5. In the right pane, set the configuration properties for zWinRMUser and zWinRMPassword, supplying the appropriate Windows credentials.
    • For domain accounts, zWinRMUser must be in user@domain.com format, and zWinKDC must be specified.

Note: For ease of setup and testing, the local Administrator account can be used in test environments. For production environments, the use of a less privileged service account is recommended. See the section above titled About Windows Authentication for WinRM Monitoring  for more on WinRM authentication. 

To configure Windows to allow monitoring using a non-Administrator service account, see the section below titled  Configuring a WinRM Service Account.  

  1. Click See All.
  2. Add windows servers using the web interface or ZenBatchload.

Note: If the user names and passwords used on servers are different, each server must be added and its individual zWinRMUser and zWinRMPassword configuration properties must be set. Perform the following steps to add the server information:

  1. Add the server to the Server/Microsoft/Windows device class, but opt out of modeling the device when adding as follows:
    • If you are adding via the web interface, leave the Model Device: box unchecked.
    • If you are adding through the zenbatchload command, be sure the device has the --nomodel flag set.
  2. When the device displays in the device list, click on its name.
    • Click on Configuration Properties in the left pane, and set the configuration properties for zWinRMUser and zWinRMPassword, supplying the appropriate Windows credentials.
  3. Model the device by clicking the Action Wheel (gear-shaped) icon in the lower left and select Model Device...

Notes on using domain authentication

  • Kerberos will always perform a forward and reverse DNS lookup on a target server.  If there are multiple PTR records for a server, in incorrect name could be used by kerberos to obtain authentication to use the WSMAN service on a given server.  To be sure that the correct name is used, administrators can use some/all of the following if necessary:
    • Configure the Zenoss server to access the Windows DNS server for DNS resolutions.
    • Ensure that the PTR records are correct for each server.
    • Manually enter PTR records for each server in to the /etc/hosts file.
      • e.g. 77.77.77.77 r2d2.example.com
    • Use the zWinRMServerName property.  This property can be either the fully qualified domain name of the server or the tales expression ${here/titleOrId}.
  • If many Windows servers in your environment do not have DNS PTR records that match Active Directory, it is recommended that you:
    • set the zWinRMDisableRDNS property to True at the /Server/Microsoft device class level.
      • This will disable reverse DNS lookups in kerberos.
    • set the monitored device's title to be the fully-qualified Active Directory name in Zenoss
    • set zWinRMServerName to ${here/titleOrId} at the /Server/Microsoft device class level.

Configuring WinRM and WinRS on Individual Servers

Perform the following steps to configure WinRM and WinRS:

  1. Log on to the target server as a user with Domain Admin or local Admin
  2. Start a Windows PowerShell session
    1. Configure the system to accept WS-Management requests from other systems. Enter the following at the command prompt:
      • winrm quickconfig
    2. Encryption:
      • No changes necessary if using a domain account.
      • For local authentication, enter the following command:
        • winrm s winrm/config/service '@{AllowUnencrypted="true"}'
    3. Configure the maximum number of concurrent operations per user. Use the following command:
      • winrm s winrm/config/service '@{MaxConcurrentOperationsPerUser="4294967295"}'
    4. Configure the maximum number of shells per user. Enter the following command:
      • winrm s winrm/config/winrs '@{MaxShellsPerUser="2147483647"}'
    5. Configure the idle timeout. Enter the following command:
      • winrm s winrm/config/winrs '@{IdleTimeout="600000"}'
    6. Authentication:
      • Kerberos authentication is the default. No changes necessary for a domain user.
      • For local (Basic) authentication, specify Basic Authentication. Enter the following command:
        • winrm s winrm/config/service/auth '@{Basic="true"}'
    7. Exit PowerShell:
      • exit
  3. Configure the firewall to allow connections on port 5985.
    1. Open Server Manager
    2. From the tools menu, select Windows Firewall with Advanced Security
    3. Click Local Server on the left.
    4. Edit the firewall profile currently in use.  Click the value to the right of Windows Firewall to change it.  For example, "Windows Firewall" might display in grey font and to the right of it, in blue colored font, "Domain: On." In this case, click the blue Domain On value to display the Windows Firewall page.
    5. In the left pane of the Windows Firewall page, click Allow an app or feature through Windows Firewall.
    6. Scroll down through the list that displays and confirm that Windows Remote Management is checked for the current firewall profile in use (and any other profiles required). Note: Remote management includes allowing connections on port 5985.
    7. Click OK.
  4. If your firewall settings are NOT set by group policy, perform the following, depending on your server, to enable response to ping requests that are necessary for Zenoss to perform availability monitoring:
    1. In Server Manager, click Local Server in the left pane.
    2. In the right pane, click the entry for Windows Firewall Domain: On (in blue letters) to display the Windows Firewall
    3. Click Allow an app or feature through Windows Firewall to display the Allowed apps
    4. Click File and Printer Sharing.
    5. Click Next.
    6. Ensure the boxes are checked for:
      • File and Printer Sharing (Echo Request - ICMPv6-In)
      • File and Printer Sharing (Echo Request - ICMPv4-In)
      • This enables the response to ping requests, you can uncheck any additional boxes unless you require them specifically.
    7. Click OK.

Improving Individual Server Security - Specify SSL for WinRM & WinRS

To successfully encrypt the payload between Resource Manager and Windows clients, you must install a Server Authentication certificate on each monitored server. Log on to your Certificate Authority server as a user with Administrator privileges to create a Certificate Template for use in creating each server's certificate. This step only needs to be completed once because the new Certificate Template is then used repeatedly to create each server's certificate. In the following steps, the standard Web Server Certificate Template is duplicated to create a new Certificate Template.

  1. Launch the Microsoft Management Console (mmc).
    • Within the mmc create the duplicate template:
      1. Click the File menu, and select Add/Remove Snap-in... to display the Add or Remove Snap-ins dialog.
      2. From the list on the left, select Certificate Templates.  Note: If the Certificate Templates option does not display in the list, you must add the CA role to your server.
      3. Click the Add> button in the middle of the window to add it to the Selected snap-ins list on the right.
      4. Click OK.
      5. Click on Certificate Templates ([server name]) in the window on the left to display the full list of Certificate Templates.
      6. Scroll down the list and locate Web Server.
      7. Right click the Web Server template and select Duplicate Template to display the Properties of New Template Window.
      8. Select the Request Handling tab, and check the box next to Allow private key to be exported.
      9. Select the General tab and specify a value for Template display name.
      10. Select the Security tab and add the certificate authority computer account to the template with at minimum Enroll permissions.
      11. Click OK to save the changes and exit the Properties of New Template
  2. In the mmc, configure the Certificate Template:
    1. Click the File menu, and select Add/Remove Snap-in... to display the Add or Remove Snap-ins dialog.
    2. Select Add/Remove Snap-in...
    3. From the list on the left, select Certification Authority.
    4. Click the Add> button in the middle of the window to add it to the Selected snap-ins list on the right.
      • If a window titled Certification Authority displays:
        1. Select the radio button next to Local computer under This snap-in will always manage:
        2. Click Finish.
        3. Click OK.
    5. Expand the list under Certification Authority (Local) and the list under your server name.
    6. Right click Certificate Templates in the list under your server name. vii. Select New => Certificate Template to Issue.
    7. In the Enable Certificate Templates window, select the new template you created in the previous steps.
    8. Click OK.
  3. Exit the mmc

Creating a Certificate for Each Server

In the following steps, use the new certificate template to create a certificate for each server you want to monitor using SSL encryption. These steps are repeated for each server.

  1. If necessary, launch the Microsoft Management Console (mmc). 
    1. From the File menu, select Add/Remove Snap-in...
    2. From the list on the left, select Certificates.
    3. Click the Add> button in the middle of the window to add it to the Selected snap-ins list on the right.
    4. In the Certificates snap-in window, select Compute account under This snap-in will always manage certificates for:
    5. Click Next (or Finish if your using an existing mmc console).
    6. Click Local computer under This snap-in will always manage: if you are presented with the Select Computer dialogue (which occurs if opening a new mmc console).
    7. Click Finish.
    8. Click OK.
  2. Request and enroll the new certificate. In the Certificate mmc:
    1. Navigate to Console Root > Certificates (Local Computer) > Personal > Certificates.
    2. Select Action in the menus at the top of the mmc to display the drop down list.
    3. Select All Tasks > Request New Certificate.
    4. Click Next to display the next window with Active Directory Enrollment Policy
    5. Click Next.
    6. Place a check mark in the box next to your copied certificate template and click the link to launch the Properties edit window.
      1. In the Subject tab, choose Common name from the Type: drop-down of the Subject name field. Enter the fully qualified domain name of the server to be monitored (for example, mytestmachine.mynetwork.com) in the Value: field.
      2. Click Add.
      3. If desired, enter additional identification information, including the organization, street address, etc., in the same manner.
      4. Select the General tab and populate the friendly name field.
    7. Click OK.
    8. Click Enroll.
    9. Click Finish.
  3. Expand the tree under Certificates.
  4. Expand the tree under Personal.
  5. Click on Certificates to highlight it and display a list of certificates on the right.
  6. Right click the new certificate and select All Tasks.
    1. Select Export.
    2. In the Certificate Export Wizard window, click Next. iii. Select the radio button next to Yes, export the private key.
    3. Click Next.
  7. On the next page:
    1. Verify that the radio button next to Personal Identification Exchange - PKCS #12 (.pfx) is selected.
    2. Verify that the checkbox next to Include all certificates in the certification path if possible is checked.
    3. Click Next.
  8. On the Security page of the wizard:
    1. Check the box next to Password.
    2. Create a password to secure the private key.
    3. Click Next.
  9. On the File to Export page:
    1. Select a destination for the key export.
    2. Create a file name.
    3. Click Save
    4. Click Next.
  10. On the Completing the Certificate Export Wizard page, click Finish.
  11. Click OK to close the Certificate Export Wizard.
  12. Move or copy the exported certificate to the target (monitored) server.

Installing the Certificate on the Target Computer 

  1. On the target computer, launch the Microsoft Management Console (mmc).
  2. In the mmc:
    1. From the File menu, select Add/Remove Snap-in...
    2. From the list on the left, select Certificates.
    3. Click the Add> button in the middle of the window to add it to the Selected snap-ins list on the right.
    4. In the Certificates snap-in window, select Computer account under This snap-in will always manage certificates for:.
    5. Click Next.
    6. On the Select a computer page, click the radio button next to Local computer.
    7. Click Finish.
    8. Click OK on the Add or Remove Snap-ins page.

Importing the Certificate

  1. In the mmc console, expand the Certificates (Local Computer) branch of the tree.
  2. Right click Personal.
  3. Select All Tasks => Import.
  4. On the first page of the Certificate Import Wizard, click Next.
  5. On the File to import page:
    1. Click Browse.
    2. Navigate to the location of the certificate copied to the target system above.
    3. Select the file.  Note: You might need to change the file type in the file browser window to Personal Information Exchange for the file to display.
    4. Select the certificate file.
    5. Click Open.
    6. Click Next.
  6. On the Private key protection page:
    1. Enter the password for the key.
    2. Verify that the checkboxes for Include all Extended Properties and Mark this key as exportable are selected.
    3. Click Next.
  7. On the Certificate Store page:
    1. Select the radio button next to Place all certificates in the following store.
    2. Verify that Personal appears in the field for Certificate Store.
    3. Click Next.
  8. On the Completing the Certificate Import Wizard page, click Finish.
  9. Click OK to exit the Certificate Wizard.

Verifying the Details and Copying the Thumbprint 

  1. In the mmc console:
    1. Expand the Certificates (Local Computer) branch of the tree.
    2. Expand Personal.
    3. Click on Certificates.
    4. Double click on the certificate to view its details.
  2. In the General tab of the Certificate window:
    1. Verify that the hostname is correct for the target server.
    2. Select the Details tab
    3. Scroll down to Thumbprint in the Field list.
    4. Click on Thumbprint.
    5. Copy the thumbprint from the lower window for use in later steps.
  3. If the server has not been previously configured for monitoring using WinRM, complete the steps listed above in the section Configuring WinRM and WinRS on Individual Servers above and omit the step that specifies allowing unencrypted traffic.

Substitute the steps in the following section, Configuring the Firewall (below) for firewall configuration.  If the server has previously been configured for monitoring but without using SSL, proceed directly to the section, Configuring the Firewall (below).

Configuring the Firewall

  1. Configure the firewall to allow connections on port 5986 on individual servers. If desired, use these instructions to instead modify a Group Policy object to make the change on large numbers of servers.
    1. Open the Server Manager
    2. Click Local Server on the left.
    3. Edit the Firewall profile currently in use. Click the value to the right of Windows Firewall to change the value.  For example, you might see Windows Firewall in grey font and to the right of it, in blue font, Domain: On.
    4. In this case, click the blue Domain On value.
    5. Click on Advanced Settings on the left.
  2. In the Windows Firewall with Advanced Security window:
    1. Click on Inbound Rules on the left.
    2. Click on New Rule... on the far right under Actions.
  3. In the New Inbound Rule Wizard window:
    1. Select the radio button next to Port.
    2. Click Next.
    3. Verify that the radio buttons next to TCP and Specific local ports are selected.
    4. Enter the value 5986 in the field for Specific local ports.
    5. Click Next.
    6. On the next page, verify that the radio button next to Allow the connection is selected.
    7. Click Next.
    8. On the next page, select the firewall profiles for which the rule should apply.
    9. Click Next.
    10. On the next page, give the rule a name.
    11. Click Finish.

Creating the WinRM Listener Using SSL

  1. Open Windows PowerShell.
  2. At the PowerShell command line, type the following command, substituting your values for the certificate thumbprint and serverfqdn (server fully qualified domain name of the monitoring server):

winrm create winrm/config/Listener?Address=*+Transport=HTTPS  '@{Hostname="[serverfqdn]";CertificateThumbprint="[thumbprint]"}'

for example:

winrm create winrm/config/Listener?Address=*+Transport=HTTPS '@{Hostname=" mytestmachine.mynetwork.com";CertificateThumbprint="07bfff656edab6d9b4dd27f02 0f768f54fee5eb8"}'

Note: The thumbprint value must be entered without the spaces displayed in the Detail tab of the Certificate information window. For example, the displayed value: 07 bf ff 65 6e da … must be entered as:  07bfff656eda…

  • Ensure that encryption is enabled. Enter the following command:

winrm s winrm/config/service '@{AllowUnencrypted="false"}'

Note: If this is already controlled through a policy, an error displays. In that case, modify the appropriate GPO. The instructions earlier in this document can be used as a guide.

Adding the Server to Zenoss

In the Zenoss web UI:

  1. Navigate to the Infrastructure
  2. If the server has not yet been added to Zenoss, add it the Server/Microsoft/Windows device class and opt out of modeling.
  3. Click on the name of the target (monitored) server (or on the Server/Microsoft/Windows device class if you would like these changes to apply to all Windows servers).
  4. Click on Configuration Properties.
  5. Edit the configuration property for zWinScheme to be https.
  6. Edit the value for zWinRMPort to be 5986.
  7. Verify that the values for zWinRMUser and zWinRMPassword are correct. Correct means the appropriate Windows credentials. Edit as necessary.
  8. To verify that all settings are correct, model the device. Click the Action Wheel (gear-shaped) icon in the lower left and select Model Device...

Configuring a WinRM Service Account

A monitoring user account must be either an Administrator or a least privileged user, domain or local.  Because there are no local accounts on a domain controller, a domain account must be used.

The Least Privileged User requires the following privileges and permissions:

  • Enable, Method Execute, Read Security, Remote Access to the following WMI namespaces
    • "Root"
    • "Root/CIMv2"
    • "Root/DEFAULT"
    • "Root/RSOP"
    • "Root/RSOP/Computer"
    • "Root/WMI"
    • "Root/CIMv2/Security/MicrosoftTpm"

If IIS is installed, one of the following namespaces depending upon IIS version

  • IIS 6:
    • "Root/Webadministration"
  • IIS 7 or above:
    • "Root/microsoftiisv2"
  • Permission to use the winrm service
  • ReadPermissions, ReadKey, EnumerateSubKeys, QueryValues rights to the following registry keys
    • "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib",
    • "HKLM:\system\currentcontrolset\control\securepipeservers\winreg",
    • "HKLM:\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002bE10318}",
    • "HKLM:\SYSTEM\CurrentControlSet\Services\Blfp\Parameters\Adapters",
    • "HKLM:\Software\Wow6432Node\Microsoft\Microsoft SQL Server",
    • "HKLM:\Software\Microsoft\Microsoft SQL Server"
  • Membership in the following local groups or domain level groups for a Domain Controller
    • "Performance Monitor Users",
    • "Performance Log Users",
    • "Event Log Readers",
    • "Distributed COM Users",
    • "WinRMRemoteWMIUsers__"
  • “Read Folder” access to "C:\Windows\system32\inetsrv\config" if it exists
  • Each service needs the following permissions
    • SERVICE_QUERY_CONFIG
    • SERVICE_QUERY_STATUS
    • SERVICE_INTERROGATE
    • READ_CONTROL
    • SERVICE_START

These permissions can be applied through your organization's Group Policy.

Alternatively, you can apply these permissions on individual servers or via GPO through the PowerShell script mentioned above, zenoss-lpu.ps1, found on github.  There are two lines in the file you must remove in order for the script to execute.  We recommend you thoroughly read through the script to understand what changes it will make.  More information on the Least Privileged User can be found here.

Individual Server Script Deployment

  1. Download zenoss-lpu.ps1 to a location such as C:\temp.
  2. Open PowerShell
  3. After examining the changes the script will make and removing the lines that will allow the script to execute, run the script:
    • Local user named benny:
      • C:\temp\zenoss-lpu.ps1 -u benny
    • Domain user named benny in domain.com:
      • C:\temp\zenoss-lpu.ps1 -u benny@domain.com
  4. If you see an error such as:
    • File C:\temp\zenoss-lpu-ps1 cannot be loaded because running scripts is disabled on this system...
    • You will need to bypass the security restrictions by including the -executionpolicy bypass option
      • powershell -executionpolicy bypass -file c:\temp\zenoss-lpu.ps1 -u benny

 

Group Policy PowerShell Script Deployment

Perform the following procedure to create a new GPO and to deploy the PowerShell script.

  1. Create your service account configuration script (or edit, as appropriate, the sample script referenced above in the section titled About Windows Authentication for WinRM Monitoring).
  2. Copy the script (for example “zenoss-lpu.ps1”) to a Netlogon folder such as \\yourdomain\SYSVOL\yourdomain\scripts.
  3. Open Group Policy Management, from the Server Manager console.
  4. Create a new policy, see previous section in this document for creating a GPO.
  5. Edit your new policy.
    1. In the left pane of the Group Policy Management window, navigate to:                                Computer Configuration\Policies\Windows Settings\Scripts (Startup/Shutdown)
    2. Click Scripts (Startup/Shutdown).
    3. In the right pane (Scripts (Startup/Shutdown), double-click Startup to launch the Startup Properties dialog.
    4. In the Startup Properties dialog box, select the PowerShell Scripts tab.
    5. Click Add to display the Add a Script dialog box:
      1. Specify the script name and path. In the Script Name field, enter the path to the script, or click Browse to locate the script file. Note: Scripts should be located in the Netlogon shared folder on the domain controller. For example: \\yourdomain\SYSVOL\yourdomain\scripts
      2. Select the zenoss-lpu.ps1 PowerShell script.
      3. Click Open.
      4. In the Script Parameters box, enter -u yourusername@yourdomain for a domain user  or -u yourusername for basic authentication of a local computer account user. Note: Basic authentication relies on local computer accounts. To successfully authenticate to any particular computer, you must have a local account on that machine.
      5. Click OK to save the information and exit the Add a Script window.
      6. Click OK to exit the Startup Properties
  6. Exit the Local Group Policy Editor
  7. Link your new GPO to one or more Organizational Units (OU) containing servers to which you want to have the policies applied. Alternatively, you can apply the policies to all Windows servers in the domain by linking the new GPO to the domain itself. To link the GPO to the domain, complete the following process.  Note: Substitute a specific OU for the domain if you want to link only to a subset of servers.
    1. Right-click your domain in the left pane of the Group Policy Management
    2. Choose Link an Existing GPO...
    3. Select your new GPO from the list that displays.
    4. Click OK to complete the process.
  8. Exit the Group Policy Management window.
  9. Manually refresh Group Policy from the command prompt of target servers:
    • gpupdate /force
  10. Reboot your member servers to have the script run for the first time. 

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request

Comments

Powered by Zendesk