Powershell Output via NCPA API missing

[onegative]

G 'Day Nagios Support,

I am performing some testing and have found something I consider odd...perhaps you can explain the reason behind it and as to whether this appears to be a bug or not.

Thanks for your attention,
Danny

So I have a small powershell script as shown below I am running as a plugin

Code: Select all

$NCPA_PATH = Get-Process -Name ncpa_passive | Select -expand Path
Write-Host "${NCPA_PATH} " -NoNewline
$NCPA_DRIVE = "$NCPA_PATH" -split "ncpa_passive" | Select -First 1
Write-Host "${NCPA_DRIVE} " -NoNewline
$NCPA_TEMP = "${NCPA_DRIVE}var\log\"
Write-Host "${NCPA_TEMP} " -NoNewline 
$SCRIPT_NAME = $MyInvocation.MyCommand.Name
Write-Host "${SCRIPT_NAME} " -NoNewline
$SEEK_FILENAME = "${SCRIPT_NAME}.seek"
Write-Host "${SEEK_FILENAME} " -NoNewline
$SEEK_PATH = "${NCPA_TEMP}${SEEK_FILENAME}"
Write-Host ${SEEK_PATH}

Note that if I run from the command line the following output is produced:
C:\DCOM\Nagios\ncpa_passive.exe C:\DCOM\Nagios\ C:\DCOM\Nagios\var\log\ displayEnv.ps1 displayEnv.ps1.seek C:\DCOM\Nagios\var\log\displayEnv.ps1.seek

But when executed through the NCPA API the following output is produced:
Using check_ncpa.py

var\log\ displayEnv.ps1 displayEnv.ps1.seek var\log\displayEnv.ps1.seek

Using the NCPA Web Services Gui:

{
"returncode": 0,
"stdout": "var\\log\\ displayEnv.ps1 displayEnv.ps1.seek var\\log\\displayEnv.ps1.seek"
}

Please note that the output being produced through the API is removing portions of the output as displayed in Red font below:
C:\DCOM\Nagios\ncpa_passive.exe C:\DCOM\Nagios\ C:\DCOM\Nagios\var\log\ displayEnv.ps1 displayEnv.ps1.seek C:\DCOM\Nagios\var\log\displayEnv.ps1.seek

[jdunitz]

This may be an interesting problem. To find out, can we have a look at your ncpa.cfg file? Feel free to redact any secrets.
Also, what version of NCPA are you using?
And just to be extra-sure, are you using Powershell v4?

Thanks

[onegative]

@jdunitz

So here are the particulars:

[nagios@dcom-nagiosxi-p1 ~]$ /usr/local/nagios/libexec/check_ncpa.py -H dg0123-ibm-4048.amc.uwmedicine.org -P 3181 -t '*********' -M 'system/agent_version'

OK: Agent_version was ['2.2.0']


[ADMIN]: PS C:\dcom\nagios\plugins> $PSVersionTable.PSVersion

Major Minor Build Revision
----- ----- ----- --------
5 1 17763 1007


ncpa.cfg file contents:

Code: Select all

#
#   NCPA Main Config File
#   ---------------------
#

#
# -------------------------------
# General Configuration
# -------------------------------
#

[general]

check_logging = 1
check_logging_time = 30

#
# -------------------------------
# Listener Configuration (daemon)
# -------------------------------
#

[listener]

uid = nagios
gid = nagios

ip = 0.0.0.0
port = 3181

ssl_version = TLSv1_2
certificate = adhoc

loglevel = info
logfile = var/log/ncpa_listener.log
pidfile = var/run/ncpa_listener.pid

admin_gui_access = 0

admin_password = **********

admin_auth_only = 1

#
# -------------------------------
# Listener Configuration (API)
# -------------------------------
#

[api]

community_string = *********

#
# -------------------------------
# Passive Configuration (daemon)
# -------------------------------
#

[passive]

handlers = nrdp

uid = nagios

gid = nagios

sleep = 300

loglevel = info

logfile = var/log/ncpa_passive.log

pidfile = var/run/ncpa_passive.pid

#
# -------------------------------
# Passive Configuration (NRDS)
# -------------------------------
#

[nrds]

#
# NRDS CONFIGURATION DOES NOT WORK YET. MORE TO COME IN VERSION 2.1.0.
#

#
# NRDS connection information
#
url = 
token = 
config_name = 
config_version = 
update_config = 1
update_plugins = 1

#
# -------------------------------
# Plugin Configuration
# -------------------------------
#

[plugin directives]

plugin_path = plugins/

#
# Extensions for plugins
# ----------------------
# The extension for the plugin denotes how NCPA will try to run the plugin. Use this
# for setting how you want to run the plugin in the command line.
#
# NOTE: Plugins without an extension will be ran in the cmdline as follows:
#       $plugin_name $plugin_args
#
# Defaults:
# .sh = /bin/sh $plugin_name $plugin_args
# .py = python $plugin_name $plugin_args
# .ps1 = powershell -ExecutionPolicy Bypass -File $plugin_name $plugin_args
# .vbs = cscript $plugin_name $plugin_args //NoLogo
# .bat = cmd /c $plugin_name $plugin_args
#
# Since windows NCPA is 32-bit, if you need to use 64-bit powershell, try the following for
# the powershell plugin definition:
# .ps1 = c:\windows\sysnative\windowspowershell\v1.0\powershell.exe -ExecutionPolicy Unrestricted -File $plugin_name $plugin_args
#

# Linux / Mac OS X
.sh = /bin/sh $plugin_name $plugin_args
.py = python $plugin_name $plugin_args
.pl = perl $plugin_name $plugin_args

# Windows
.ps1 = powershell -ExecutionPolicy Bypass -File $plugin_name $plugin_args
.vbs = cscript $plugin_name $plugin_args //NoLogo
.bat = cmd /c $plugin_name $plugin_args
.pl = perl $plugin_name $plugin_args


#
# -------------------------------
# Passive Configuration (NRDP)
# -------------------------------
#

[nrdp]
# Select one or the other for directing events to Test or Production
# Test Environment
parent = https://nagiosxi-test.nagiosxi.my.fqdn.com/nrdp

token = a1h234sf234s

# Add following entry for computername
hostname = dg0123-ibm-4048 

[mbellerue]

If you go into Services and to the properties of NCPA Listener and Passive, are they set to logon as the system account, or a named user account?

[onegative]

@mbellerue

In this particular case they are running as a domain service account which has been added to the native Performance Monitoring group in Windows on the system. I also gave the service account rw access recursively to the installation directory. The reason I have it set that way is to allow the ncpa agent the ability to test UNC Path dynamically without having to pass credentials which works really well.

As a test, I will place the script on a system running the services under the Local System account and check the results and let you know...

I will post the results as soon as I can get to it...

Thanks for the suggestion,
Danny

[onegative]

So I just tried this on a system where the services are running as the Local System account and the returned data was complete...

{
"returncode": 0,
"stdout": "C:\\DCOM\\Nagios\\ncpa_passive.exe C:\\DCOM\\Nagios\\ C:\\DCOM\\Nagios\\var\\log\\ displayEnv.ps1 displayEnv.ps1.seek C:\\DCOM\\Nagios\\var\\log\\displayEnv.ps1.seek"
}

So why would this be the case?

Dazed and Confused,
Danny

[onegative]

So I modified the service account to be Administrator and it worked...but this is not a desired access state that I can allow the service account to exist. Since you obviously had an idea why this is happening, is it possible to change something with regard to the service account permissions other than allowing the Administrator Rights to be assigned?

Let me know and thanks,
Danny

[mbellerue]

So I modified the service account to be Administrator and it worked...but this is not a desired access state that I can allow the service account to exist.

I agree whole heartedly, and I can only dream of a day when more people consider what account their services are running as. It can be a HUGE nightmare if a service running as local system, or an account with local administrator privileges is breached.

Anyway. With that aside, with your service account at its desired premissions state, it has access to read and launch your Powershell plugin. Which is great. It just needs a little more access in order to come back with the information you need.

Looking at the script much more closely now, it looks like the service account just isn't being allowed to run the Get-Process cmdlet in Powershell. Do you have access to launch a Powershell window as the service account? You would need the password for it to do this. But if you could do that, you could try to run get-process -name ncpa_passive and that would tell you for certain.

After that, it's just a matter of finding out what permissions the service account needs to run that cmdlet.

[onegative]

@mbellerue

Okay that sounds like a plan...I did change the permissions of the svc_account to Power User as well and it still didn't work. I can sign-on using the svc_account which I will try tomorrow and update the Post.

Thanks for your help,
Danny

[onegative]

@mbellerue

So after sleeping on it last night, I realized that this is not due to a restriction of Powershell execution. The reason I state that is because I have other Powershell scripts that run successful on this exact server as the same svc_account. I therefore just copied the script that was failing and simply changed the specific process to another one, in this case Powershell. As the below results from the ncpa api show it executes correctly and displays the paths correctly. This leads me to think that the problem lies within the output side of the ncpa_listener and perhaps based on the %NCPA_HOME% or however it is referenced within the internals on the listener portion of the agent.

Please observe, same script just different process to query:


{
"returncode": 0,
"stdout": "C:\\Windows\\SysWOW64\\WindowsPowerShell\\v1.0\\powershell.exe C:\\Windows\\SysWOW64\\Windows C:\\Windows\\SysWOW64\\Windowsvar\\log\\ displayEnvPowershell.ps1 displayEnvPowershell.ps1.seek C:\\Windows\\SysWOW64\\Windowsvar\\log\\displayEnvPowershell.ps1.seek"
}


So the script executes just fine and it is only the display of the %NCPA_HOME% being removed from the output that appears to be lacking.
Since I provided the script and examples this should be easily replicated.

Please let me know and thanks,
Danny