Error 2051 and 1553 - executing via REST API

[Skeletitor]

I get the following two errors every time when a MSSQL Check ist executed via REST API

EventID 2051:

Failed to execute API call

An API call could not be processed due to an internal exception.

Object dumps if available:
Cannot process argument transformation on parameter 'SqlPassword'. Cannot create object of type "System.Security.SecureString". "Length" is a ReadOnly property.

EventID 1553:

Failed to query Icinga check over internal REST-Api check handler

A service check could not be executed by using the internal REST-Api check handler. The check either ran into a timeout or could not be processed. Maybe the check was not registered to be allowed for being executed. Further details can be found below.

Object dumps if available:
The remote server returned an error: (500) Internal Server Error.
Invoke-IcingaCheckMSSQLHealth

Name Value

---

SqlPassword System.Security.SecureString
SqlUsername monitoring
Verbosity 3

SQL COmmands are whitelisted

PS C:\Windows\system32> Show-IcingaRESTApiCommands
API Endpoint "apichecks"
################

Whitelisted: Invoke-IcingaCheck*, Invoke-IcingaCheckMSSQL*, Invoke-IcingaCheckMSSQLHealth

Blacklisted: None
Icinga service conf:

apply Service "MSSQL Health" {
  import "generic-service"
  check_command = "Invoke-IcingaCheckMSSQLHealth"
  max_check_attempts = 3
  check_interval = 5m
  retry_interval = 5m
  enable_flapping = true
  command_endpoint = host_name

  if (host.vars.IcingaCheckMSSQLHealth_Int32_Verbosity) {
    vars.IcingaCheckMSSQLHealth_Int32_Verbosity = host.vars.IcingaCheckMSSQLHealth_Int32_Verbosity
  } else {
    vars.IcingaCheckMSSQLHealth_Int32_Verbosity = 3
  }
  if (host.vars.IcingaCheckMSSQLHealth_String_SqlUsername) {
    vars.IcingaCheckMSSQLHealth_String_SqlUsername = host.vars.IcingaCheckMSSQLHealth_String_SqlUsername
  } else {

    vars.IcingaCheckMSSQLHealth_String_SqlUsername = "USER"
  }
  if (host.vars.IcingaCheckMSSQLHealth_Securestring_SqlPassword) {
    vars.IcingaCheckMSSQLHealth_Securestring_SqlPassword = host.vars.IcingaCheckMSSQLHealth_Securestring_SqlPassword
  } else {

    vars.IcingaCheckMSSQLHealth_Securestring_SqlPassword = "PASSWD"
  }

  assign where host.vars.powershell_framework == true && host.vars.mon_mssql1 == true
}

How is ist possible to debug this? Or is there a missconfiguation? Manual executing works without these errors and without using REST API.

[Padahahn]

I second that behaviour.

Calling this check via REST-API always results in the aforementioned events. The check is then falling back to local execution, giving coherent results, so the check by itself is working fine.

[Padahahn]

After some investigation I think I found the root of this behaviour.

The MSSQL-checks demand the SQL-password as securestring, hence the conversion in the call.

When calling the check through the REST-API, the Arguments are rearranged to proper check-arguments and are all interpreted as sole strings in Invoke-IcingaInternalServiceCall.psm1:

As for a solution: I think, except for editing the framework code itself, you're pretty much out of luck.

Edit: On further notice...

The problem is more, that (ConvertTo-IcingaSecureString 'PASSWD') is executed way before the REST call and so the plain value of the securestring "System.Security.SecureString" is used.
However, I am struggeling to find a way to handle this, because turning the whole ConvertTo...-Cmdlet as a string won't get interpreted by the REST-API.

[Skeletitor]

Thx!!

So, as for now... Can we say that MSSQL Checks with basic authentication are not REST-API ready? Or better: We need a framework/Service adjustment to call checks with securestring arguments? I'll try with "-IntegratedSecurity" instead of these basic auth stuff tomorrow.

If this won't work, I'll have to accept these events as false-positives. Blacklisting these MSSQL Checks gives an other event which is a false-positive too. Kudos to the upcomming eventqueue for icinga :)

[Padahahn]

Don't mistake me for staff, I'm just an average Joe giving his thoughts and findings. :)

On that note:

It seems, that basic authentication only works when run locally. The securestring is needed, because the credentials used for the MSSQL-connection are defined by the SqlCredential Class, which itself demands a secure string:

https://docs.microsoft.com/en-us/dotnet/api/microsoft.data.sqlclient.sqlcredential?view=sqlclient-dotnet-standard-4.0

We'll have to wait for an official statement. :)

[LordHepipud]

Sorry for taking so long and for the issue. SecureString arguments will work properly with Icinga for Windows v1.10.0 and the REST-Api.

Release is scheduled for Tuesday, 30th August.