SSO defaults to user=librenms

Hi, I got an almost working SSO implementation with LibreNMS and ngnix/authelia. Using sso mode with headers, but the username defaults to “librenms” for all SSO logins. Other attributes from the logged in user are correct(real name, email). Logging in with another username just updates the existing librenms user with correct name and email.

Need some help to troubleshoot this :slight_smile:

If another user logs in, librenms user gets updated info on real name and email.

Setup is as follows, all runs in containers/stacks.
nginx-reverse proxy, connected to authelia for ldap and 2-fa.
Librenms runs in container:


Component Version
LibreNMS 23.8.0 (2023-08-29T08:54:42+02:00)
DB Schema 2023_08_02_120455_vendor_ouis_unique_index (255)
PHP 8.1.22
Python 3.10.13
Database MariaDB 10.5.19-MariaDB-1:10.5.19+maria~ubu2004
RRDTool 1.7.2
SNMP 5.9.3

SSO section in config.php
$config[‘auth_mechanism’] = “sso”;
$config[‘sso’][‘mode’] = “header”;
$config[‘sso’][‘group_strategy’] = “static”;
$config[‘sso’][‘static_level’] = 10;
$config[‘sso’][‘trusted_proxies’] = [‘’, ‘’, ‘’, ‘’];
$config[‘sso’][‘user_attr’] = ‘USER’;
$config[‘sso’][‘realname_attr’] = ‘NAME’;
$config[‘sso’][‘email_attr’] = ‘EMAIL’;
$config[‘sso’][‘create_users’] = true;
$config[‘sso’][‘update_users’] = true;

nginx config
location / {
include /etc/nginx/mime.types;
proxy_pass http://librenms:8200/;
auth_request /authelia;
auth_request_set $target_url $scheme://$http_host$request_uri;
auth_request_set $user $upstream_http_remote_user;
auth_request_set $groups $upstream_http_remote_groups;
auth_request_set $name $upstream_http_remote_name;
auth_request_set $email $upstream_http_remote_email;
error_page 401 =302$target_url;
proxy_http_version 1.1;
proxy_set_header Host $host:$server_port;
proxy_set_header X-Forwarded-Proto “https”;
proxy_set_header X-Forwarded-Port $server_port;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
add_header X-Content-Type-Options nosniff;
proxy_set_header USER $user; #$user/name/email from authelia
proxy_set_header NAME $name;
proxy_set_header EMAIL $email;
proxy_headers_hash_max_size 512;
proxy_headers_hash_bucket_size 128;

Confirmed http headers in wireshark in traffic sent from nginx to librenms get sets correctly.

RVóQGET /css/MarkerCluster.css HTTP/1.1
Host: librenms:443
X-Forwarded-Proto: https
X-Forwarded-Port: 443
X-Forwarded-Proto: https
USER: nomas
NAME: nomas
EMAIL: [email protected]

My guess is USER conflicts with something else. Try using a different attribute, such as USERNAME.

Hi, thanks for the input.

I have now tested a few different attributes instead of “USER”, pairing ngnix -proxy_set_header- and librenms $config[‘sso’][‘user_attr’]

“USERNAME” → Librenms.log shows “Auth Error (sso): No user () []”
“LIBRE” → Librenms.log shows “Auth Error (sso): No user () []”
"UID → Librenms.log shows “Auth Error (sso): No user () []”

Trying with the default attribute “REMOTE_USER” throws
“REMOTE_USER” → Librenms.log shows “Auth Error (sso): No user () []”
2023/09/19 08:47:19 [info] 1546#1546: *150 client sent invalid header line: “REMOTE_USER: nomas” while reading client request headers, client:, server: , request: “GET /images/favicon-16x16.png HTTP/1.1”, host: “librenms:443”

An attribute that includes an underscore “_” gets the “client sent invalid header line” error in librenms.

Should I create a new issue at github?

Ok, there seems to be an issue in SSOAuthorizer.php where function authSSOGetAttr does not work as expected when using headers.

The function public function authSSOGetAttr($attr, $prefix = ‘HTTP_’)

does not prefix the HTTP_ to the $header_key which makes the function return null.

# $header_key = $prefix . str_replace(‘-’, ‘_’, strtoupper($attr));

I changed it to
$prefixnew = “HTTP_”;
$header_key = $prefixnew . $attr;

And now it works, at least the correct user is show in the GUI. This change uncovers that the static level for permissions does not work either.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.