Unable to authenticate on API

[bleizg]

Since the update to Icinga v2.16, the authentication on the Icinga API is not working properly (tested with Perl and Powershell)

To Reproduce

$Username = "user1"
$Password = "Amazing_Password_12345"
$SecuredPassword = Convertto-SecureString -String $Password -AsPlainText -Force
$Credentials = New-Object System.Management.Automation.PSCredential($Username, $SecuredPassword)

$HttpHeaders = @{
    "X-HTTP-Method-Override" = "GET"
    "accept"                 = "application/json"
}

Invoke-RestMethod `
    -Uri "https://api.icinga.company.com:5665/v1/status" `
    -Method "POST" `
    -Credential $Credentials `
    -ContentType "application/json" `
    -Headers $HttpHeaders 

Raised exception:
Invoke-RestMethod : {"error":401,"status":"Unauthorized. Please check your user credentials."}

This is the same issue with Perl if we use the credentials attribute of LWP::UserAgent class.

PERL version

use Data::Dumper;

require URI;
require HTTP::Request;
require HTTP::Headers;
require LWP::UserAgent;
require IO::Socket::SSL;
require MIME::Base64;

use JSON qw{ encode_json decode_json };

my $endpoint = 'api.icinga.company.com';
my $user = 'user1';
my $pass = 'Amazing_Password_12345';

my $Request = HTTP::Request->new( 'POST', "https://$endpoint:5665/v1/status" );
$Request->header( 'Accept'                 => 'application/json' );
$Request->header( 'X-HTTP-Method-Override' => 'GET' );
$Request->content_type( 'application/json' );

my $Agent = LWP::UserAgent->new(
        ssl_opts => {
                verify_hostname => 0,
                SSL_verify_callback => sub { 1 },
        },
);
!$Agent and return $Agent;

$Agent->credentials( "$endpoint:5665", 'Icinga 2', $user, $pass );

my $Response = $Agent->request( $Request );

print Dumper $Response->content;

What is working

Powershell

$HttpHeaders = @{
    "X-HTTP-Method-Override" = "GET"
    "accept"                 = "application/json"
    "Authorization"          = "Basic " + $([Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes("$($Username):$($Password)")))
}

Invoke-RestMethod `
    -Uri "https://api.icinga.company.com:5665/v1/status" `
    -Method "POST" `
    -ContentType "application/json" `
    -Headers $HttpHeaders

Perl

use Data::Dumper;

require URI;
require HTTP::Request;
require HTTP::Headers;
require LWP::UserAgent;
require IO::Socket::SSL;
require MIME::Base64;

use JSON qw{ encode_json decode_json };

my $endpoint = 'api.icinga.company.com';
my $user = 'user1';
my $pass = 'Amazing_Password_12345';

my $Request = HTTP::Request->new( 'POST', "https://$endpoint:5665/v1/status" );
$Request->header( 'Accept'                 => 'application/json' );
$Request->header( 'X-HTTP-Method-Override' => 'GET' );
$Request->header( 'Authorization'          => 'Basic ' . MIME::Base64::encode_base64( "$user:$pass", '' ) );
$Request->content_type( 'application/json' );

my $Agent = LWP::UserAgent->new(
        ssl_opts => {
                verify_hostname => 0,
                SSL_verify_callback => sub { 1 },
        },
);
!$Agent and return $Agent;

my $Response = $Agent->request( $Request );

print Dumper $Response->content;

To Reproduce

Provide a link to a live example, or an unambiguous set of steps to reproduce this bug. Include configuration, logs, etc. to reproduce, if relevant.

1. Update to Icinga2 v2.16
2. Call the Icinga2 API (TCP/5665) with -credential parameter

Expected behavior

Icinga API should returns a 200 http code.

Your Environment

Include as many relevant details about the environment you experienced the problem in

Version used

# icinga2 --version
icinga2 - The Icinga 2 network monitoring daemon (version: r2.16.0-1)

Copyright (c) 2012-2026 Icinga GmbH (https://icinga.com/)
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl-3.0.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

System information:
  Platform: Debian GNU/Linux
  Platform version: 12 (bookworm)
  Kernel: Linux
  Kernel version: 5.15.203-vps-grsec-zfs-classid
  Architecture: x86_64

Build information:
  Compiler: GNU 12.2.0
  Build host: runner-aa2jha3hm-project-575-concurrent-1
  OpenSSL version: OpenSSL 3.0.19 27 Jan 2026

Application information:

General paths:
  Config directory: /etc/icinga2
  Data directory: /var/lib/icinga2
  Log directory: /var/log/icinga2
  Cache directory: /var/cache/icinga2
  Spool directory: /var/spool/icinga2
  Run directory: /run/icinga2

Old paths (deprecated):
  Installation root: /usr
  Sysconf directory: /etc
  Run directory (base): /run
  Local state directory: /var

Internal paths:
  Package data directory: /usr/share/icinga2
  State path: /var/lib/icinga2/icinga2.state
  Modified attributes path: /var/lib/icinga2/modified-attributes.conf
  Objects path: /var/cache/icinga2/icinga2.debug
  Vars path: /var/cache/icinga2/icinga2.vars
  PID path: /run/icinga2/icinga2.pid

Operating System and version:

# cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

Enabled features (`icinga2 feature list`):

icinga2 feature list

Disabled features: command compatlog debuglog elasticsearch gelf graphite influxdb influxdb2 journald opentsdb perfdata statusdata syslog
Enabled features: api checker icingadb livestatus mainlog notification

[julianbrost]

What is working

Do I understand correctly that if you manually send the Authorization: Basic ... header, everything works as expected?

Apart from TLS client certificates, that's the type of authentication Icinga 2 excepts. So not sure what -Credential is doing then.

This is the same issue with Perl if we use the

Looks like you did not finish that sentence. If you can reproduce the issue with Perl, can you share that as well? I think I'll probably have a better understanding of Perl than PowerShell.

[bleizg]

Oops I've edited my message, sorry for that.
I confirm you that when I send the Authorization: Basic ... header manually, everything works as usual.

[log1-c]

Yes I can confirm that as well.
This is the same case for API requests done via PowerShell (Invoke-WebRequest) and Ansible (modules "uri" and "win_uri").

What the internet told me is that both methods (Ppowershell and Anbile) first send an unauthenticated request, and only if the API then responds with a 401 Unauthorized they send the Authentication info in a second request.

Not sure what changed on the Icinga API side, that the connection now seemingly gets closed directly and the above mentioned "two-step requests (granted not a good practice) now don't work anymore.

So, both variants now need the Authorization: Basic ... header supplied, otherwise the Icinga API closes the connection.
For PowerShell this can be done as above, with Base64 encoding the credentials.
For the Ansible modules a force_basic_auth: true must be supplied.

side note: The former "two-step" requests seem to still work (at least via Ansible), when not sending an "Accept": "application/json" header

without_accept_header.txt
with_accept_header.txt

[jschmidt-icinga]

What the internet told me is that both methods (Ppowershell and Anbile) first send an unauthenticated request, and only if the API then responds with a 401 Unauthorized they send the Authentication info in a second request.

Reading the code, it makes sense why that doesn't work here:

icinga2/lib/remote/httpserverconnection.cpp

Lines 313 to 326 in f50f6ec

	response.result(http::status::unauthorized);
	response.set(http::field::www_authenticate, "Basic realm=\"Icinga 2\"");
	response.set(http::field::connection, "close");
	if (request[http::field::accept] == "application/json") {
	HttpUtility::SendJsonError(response, nullptr, 401, "Unauthorized. Please check your user credentials.");
	} else {
	response.set(http::field::content_type, "text/html");
	response.body() << "<h1>Unauthorized. Please check your user credentials.</h1>";
	}
	response.Flush(yc);
	return false;

We should send back the right response, but then we close the connection, not necessarily because of the "close" there, but because we return false and that leads us to exit the connection loop, shutting down the connection:

icinga2/lib/remote/httpserverconnection.cpp

Lines 530 to 532 in f50f6ec

	if (!EnsureAuthenticatedUser(request, response, yc)) {
	break;
	}

What I don't get at first glance is how that is supposed to have changed in 2.16.0. We changed a lot about the internals of the HTTP code, but that shouldn't be affected. On 2.15 it also sets "close" and returns false here, exiting the loop and thus shutting down the connection.

The solution however could be as simple as changing that break into a continue .