Some AD users work, some have no permissions - using same AD group

Another ‘My Active Directory isn’t behaving how it should’ query, similar to others I’ve found but not quite the same and/or they were from some time ago so probably not relevant.

Running librenms in docker, using latest tag, currently v 23.1.1.

Output from validate:
librenms:/opt/librenms$ ./validate.php
Component | Version
--------- | -------
LibreNMS  | 23.1.1 (2023-02-09T19:33:37+00:00)
DB Schema | 2022_09_03_091314_update_ports_adsl_table_with_defaults (248)
PHP       | 8.1.15
Python    | 3.10.10
Database  | MariaDB 10.11.2-MariaDB-1:10.11.2+maria~ubu2204
RRDTool   | 1.7.2
SNMP      | 5.9.3

[OK]    Installed from package; no Composer required
[OK]    Database connection successful
[OK]    Database Schema is current
[OK]    SQL Server meets minimum requirements
[OK]    lower_case_table_names is enabled
[OK]    MySQL engine is optimal
[OK]    Database schema correct
[OK]    MySQl and PHP time match
[OK]    Active pollers found
[OK]    Dispatcher Service is enabled
[OK]    Locks are functional
[OK]    No python wrapper pollers found
[WARN]  Using database for locking, you should set CACHE_DRIVER=redis
[WARN]  IPv6 is disabled on your server, you will not be able to add IPv6 devices.
[OK]    rrd_dir is writable
[OK]    rrdtool version ok
[WARN]  Non-git install, updates are manual or from package

Myself and my team each have two AD accounts, one for day to day use and one for administrative work. Both of these accounts are in the ‘IT staff’ AD group, which is what I’m using as a librenms filter. Initially I also allowed read access to ‘Staff’ group but I’ve removed that while debugging.

In all cases, our ‘admin’ accounts can sign in to Librenms and have admin rights. Our ‘everyday’ accounts can sign in but have no access. Looking in the database, it sets level=0 for those accounts (level=10 for the admin accounts). I tried editing the database to set level to 10 for my normal account, and it showed as admin in the user list but reset to 0 as soon as I logged in.

auth_test.php runs fine with no errors or warnings and returns level=10 for both accounts, listing ‘IT staff’ in the group list.

librenms:/opt/librenms/scripts# ./auth_test.php -u k******5
Authentication Method: active_directory
AD bind success
Authenticate user k******5:

User (1311):
  user_id => 1311
  username => k******5
  realname => Steve ******
  email => steve.*****@*****.****
  descr =>
  level => 10
  can_modify_passwd => 0
Groups: CN=IT staff,OU=Staff User Groups,OU=Groups,DC=**********
librenms:/opt/librenms/scripts# ./auth_test.php -u steve
Authentication Method: active_directory
AD bind success
Authenticate user steve:

User (7874):
  user_id => 7874
  username => steve
  realname => Steve ****** (Admin)
  email => steve.*******@***.***
  descr =>
  level => 10
  can_modify_passwd => 0
Groups: CN=IT staff,OU=Staff User Groups,OU=Groups,DC=**********

The configuration file for the AD setup:

$config['auth_mechanism'] = 'active_directory';
$config['auth_ad_url'] = 'ldaps://ad1.******** ldaps://ad2.********';
$config['auth_ad_domain'] = '**********';
$config['auth_ad_base_dn'] = 'dc=**************';
$config['auth_ad_check_certificates'] = false;
$config['auth_ad_binduser'] = 'librenmsbind';
$config['auth_ad_bindpassword'] = '***************';
$config['auth_ad_timeout'] = 5;
$config['auth_ad_debug'] = false;
$config['active_directory']['users_purge'] = 30;
$config['auth_ad_require_groupmembership'] = true;
$config['auth_ad_groups']['IT staff']['level'] = 10;

It’s clearly talking to AD, it’s getting the info. The group membership should be the same - clearly auth_test.php is thinking that it is. Running it with verbose/debug output didn’t give anything obvious, and no obvious errors being generated from the container.

The only things that have come to mind are:
Both accounts have the same email address. Although that’s not the case with my other team members, although their email address in AD was blank for the admin account.
The ‘everyday’ accounts are members of ‘IT staff’, while the admin accounts are members of an ‘Admin users’ account which is in turn a member of ‘IT staff’. I could understand it if these accounts didn’t work and the normal ones did, but that isn’t the case.

Does anyone have any ideas?

Just a follow up to see if anyone has any ideas about the above, or things to try?

It’s still an issue with the latest version (23.2.0).

Still auth_test.php shows the user should be level 10 but the application itself puts the user as level 0.
I have noticed though that, although auth_test does show level 10, if I run it with -l to list the users, it only shows the three ‘admin’ user accounts, not our ‘every day’ user accounts, even though they are in the same AD group. There must be some other flag or filter that is causing the normal accounts to be excluded from auth_test -l as well as login within the application?

Just noticed that 23.2.0 is not the latest, but this is what ‘latest’ tag on docker hub gives.
Tried again with a test container running the ‘edge’ tag (23.4.0 - still not latest I know), and it does the same.

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