Nagios: Monitoring Windows with PowerShell and NCPA

The following article is just a portion of my SANS GSNA Gold Paper. Please see the PDF for the full paper.

Windows PowerShell is an extremely powerful way to maintain a modern Windows system. Nagios is an even more powerful way to monitor an entire network of systems. Put them together and, with the help of a Nagios agent such as NCPA, you can make enormous strides in reducing the off-hour calls from frustrated users. Forewarned is forearmed, after all. But Windows isn’t going to let you run PowerShell scripts without a little finagling. So let’s get to it.

Permitting the execution of PowerShell scripts requires us to first change the execution policy of the system and, since we don’t want to diminish the security posture of the system excessively, we will require that all PowerShell scripts be signed.

Signing PowerShell scripts is not particularly difficult. We will use the Certificates MMC snap-in to generate a code signing certificate. We will also make the private key exportable so that we can use the certificate on multiple systems. Begin by installing the Certificates snap-in for the Current User in MMC.

generate certificate request
Generate Certificate Request

Right-click the Certificates folder under Personal and choose All Tasks -> Advanced Operations -> Create Custom Request…

Click Next and then Proceed without Enrollment Policy and click Next. Note: If you have a corporate PKI infrastructure you may have preconfigured Enrollment Policies. Follow your corporate standards for requesting a code signing certificate.

Leave the default Template (No template) CNG key and Request format PKCS #10 and click Next. Expand the Details of the Custom request and click Properties. Fill out the following 5 screens, ensuring you meet any corporate or organizational standards relevant to your environment:

general properties
General Properties

Enter some simple information in the General Properties tab. This information will be used to identify the certificate once it is in our certificate store.

subject properties
Subject Properties

On the Subject Properties tab fill in the specifics for your organization. Depending on who your Certificate Authority is, certain fields may be required. The fields entered in the screen capture indicate those that were required by my Linux-based OpenSSL CA (for self-signing).

key properties
Key Properties
extended key properties
Extended Key Properties

On the Extensions tab we need to fill out both the standard and extended key usage sections. For code signing we need, at a minimum, Digital Signatures and Code Signing.

private key properties
Private Key Propeties

Finally, set the Key options on the Private Key tab. It’s recommended that you use a 2048 bit key. If you wish to use this key on multiple systems, make sure to select “Make private key exportable”.

Click OK and save the certificate. At this point you can provide the certificate request to your CA and, when the certificate is ready, install it on your servers in the Personal area of your certificate store by navigating to the Personal\Certificates folder in the MMC Certificates snap-in, choosing Import, and following the prompts. This will allow PowerShell to find the certificate to sign the script. We still need to have the system trust the certificate in order to execute the script.

For an enterprise with a PKI infrastructure, the code signing certificate will likely be distributed via Group Policy Object (GPO) to the Local System\Trusted Publishers folder in the certificate store. For the purposes of this paper we will manually install it there.

Within MMC add the Certificates snap-in, this time using Local Computer as the target. Navigate to Trusted Publishers, right-click and choose All Tasks -> Import… Navigate to the code signing certificate you imported earlier and complete the wizard.

Now that we have a trusted signing certificate, we are ready to sign our scripts. Given a script called MyScript.ps1 in the current directory, this can be done using the following syntax:

PS1> $codeCert = dir cert:currentuser\My | where {$_.Subject -like "*Nagios*"}
PS1> Set-AuthenticodeSignature .\MyScript.ps1 $codeCert

Note that using the above code will result in a script that will cease working if/when the certificate expires. There are numerous timestamp options available that should be considered for the needs of your environment, including setting the script to never expire.

Now that we have a code signing certificate and some signed code we can set the execution policy for the server. This needs to be set from a PowerShell with Administrator rights. Locate the Windows PowerShell utility on your Start menu, right-click on it and choose Run as administrator. When prompted by User Account Control (UAC), click Yes. At the prompt execute:

PS1> Set-ExecutionPolicy AllSigned

The system is now able to execute signed (and only signed) PowerShell scripts. Next we will install the NCPA Nagios Agent so that our monitoring server can communicate with the Windows system and perform checks. Prior to installation, however, configure Windows to allow the agent to run correctly.

If it is not already enabled, enable the disk performance counters, as the current installer (1.7.2) will silently fail to install the services if they aren’t enabled.

C:\> diskperf -y

Next, configure the Windows firewall to permit communications with the agent. It is recommended that communication to the agent be restricted to just the Nagios server. Open a Command Prompt as Administrator and run the netsh command, substituting the IP Address for your Nagios server.

C:\> netsh advfirewall firewall add rule name="Allow NCPA" dir=in action=allow protocol=TCP localport=5693 remoteip=<nagiosip>

After downloading the latest NCPA installer from the Nagios website, we install it, providing it with an Active Specifications Token, which is used as a form of authorization. For the purposes of this document we will use the following token: ncpatoken. Following a successful installation you should see port tcp/5693 listening when you run netstat.

With NCPA running and a bit of code signed, you should be ready to start monitoring. Simply copy the signed PowerShell script into the plugins folder created by the installer, e.g. C:\Program Files (x86)\Nagios\NCPA\plugins.

From the Nagios server, assuming you’ve installed the script and configured the necessary check commands, you should be ready to monitor your Windows system by executing PowerShell scripts. While I am by no means an expert scripter, here’s an example script that checks if a registry key is set the way we want it to be and provides the proper output for Nagios.


# Validate Registry Setting

# Pass in a Registry key, value, and expected setting

# ok: return 0

# bad: return current setting



$regkey = $args[0]

$regval = $args[1]

$regset = $args[2]


$actual = (Get-ItemProperty -Path $regkey).$regval

if ($actual){

if ($actual -eq $regset){

Write-Host "OK"

exit 0

} else {

Write-Host "WARNING - Value is $actual should be $regset"

exit 1


} else {

Write-Host "CRITICAL - Value NOT FOUND"

exit 2


Hopefully you are now able to execute PowerShell checks on your Windows system from Nagios. Questions or feedback? Please use the comments section below.

2 thoughts on “Nagios: Monitoring Windows with PowerShell and NCPA

  • March 12, 2015 at 7:25 pm

    I have signed script:

    SignerCertificate Status Path
    —————– —— —-
    AEF0C8DEAC77CE54A4B5206AF74B67AFCCBE0E47 Valid pcsensor_temperature.ps1

    execution plicy:
    Scope ExecutionPolicy
    —– —————
    LocalMachine AllSigned

    then try nscp test – works fine, but when i start nscp as service (net start nscp)

    doesn’t work.

    error: The term ‘\\\\server\\admin\\files\\pcsensor_temperature.ps1’ is not recognized

    any ideas?

    • March 12, 2015 at 7:33 pm

      Looks like it’s having a problem finding the script – is it not handling the doubled-up \\ correctly? For instance, at the Windows level that path should be \\server\admin\files\pcsensor_temperature.ps1 (assuming server resolves to a proper Windows name and admin is a share accessible to the account nscp is running under.). I’m rusty on my nscp – might try it without the extra slashes to see if that work.


Talk Back

This site uses Akismet to reduce spam. Learn how your comment data is processed.