API Token Creation Fails for LDAP/AD Users - "Selected user does not exist" Error

Summary

When using LDAP authentication with Active Directory, the API token creation page fails with "Selected user does not exist" for all LDAP users. The root cause is a combination of empty user_id values returned by the LDAP user list and a validation check that requires a matching record in the local users database table.

Steps to Reproduce

1. Configure Observium with auth_mechanism = "ldap" against Active Directory
2. # Set auth_ldap_attr['uidNumber'] = "objectSid" (or leave it unset)
3. # Log in as an admin user
4. # Navigate to the API Tokens page
5. # Select any LDAP user from the "User Account" dropdown
6. # Enter a token name and click "Generate Token"
7. # Error: "Selected user does not exist"

   Root Cause Analysis

Issue 1: Empty user_id from LDAP User List

The function ldap_auth_user_list() in html/includes/authentication/ldap.inc.php calls ldap_internal_auth_user_id() to derive a numeric ID for each user. When auth_ldap_attr['uidNumber'] is set to objectSid, the binary SID-to-RID conversion fails silently, resulting in an empty value:

LDAP[UserID][Attribute uidNumber yields user ID ]

This means every LDAP user in the dropdown has an empty or invalid user_id.

Issue 2: Token Page Validates Against Local DB

Line 47 of html/pages/api_tokens.inc.php performs this check:

} elseif (!dbExist('users', 'user_id = ?', [$user_id])) {

    $error = "Selected user does not exist";

The dropdown is populated by auth_user_list(), which returns LDAP-derived user_id values. However, the users table is never automatically populated for LDAP users. The user_id sent by the dropdown therefore never matches a row in the database.

Developer Acknowledgement

The developers are already aware of this limitation, as noted on line 122 of the same file:

/// FIXME. WARNING, current DB schema for tokens fits to mysql auth only!

/// (not for AD/LDAP, because it's not have user_id in DB)

Impact

• API tokens cannot be created for any LDAP/AD user through the web UI
• * This blocks all API integrations (monitoring scripts, NetBox sync, Grafana dashboards, etc.) for environments using LDAP authentication
• * Workarounds require direct database manipulation and custom scripts

  Suggested Fix

Short-Term Fix (Patch)

In auth_user_list() inside html/includes/authenticate-functions.inc.php, after the LDAP user list is fetched but before it is processed, look up each user's user_id from the local users table:

// Add before the array_sort_by() call:

foreach ($user_list_sort as &$_user) {

    $_db_uid = dbFetchCell(

        "SELECT user_id FROM users WHERE username = ?",

        array($_user["username"])

    );

    if ($_db_uid) {

        $_user["user_id"] = (int)$_db_uid;

    }

}

unset($_user);

Long-Term Fix (Recommended)

1. Fix the objectSid to RID conversion in ldap_internal_auth_user_id() so that LDAP users always receive a valid numeric user_id. The binary SID decoding logic exists in the codebase (ldap_bin_to_str_sid()) but does not appear to be invoked correctly for all AD configurations.
2. # Auto-create local DB records for LDAP users on first login, storing the SID-derived RID as the user_id. This ensures the users table is always in sync with LDAP.
3. # Alternatively, modify the token system to validate against LDAP directly (via auth_user_exists()) instead of requiring a users table entry, aligning with how the rest of the LDAP authentication flow works.

   Environment Details

• Observium Version: 26.2.14654 (rolling)
• * OS: Ubuntu (Apache2 + PHP)
• * LDAP Server: Active Directory (Windows Server)
• * LDAP Config: groupmembertype = fulldn, objectclass = user, uid = sAMAccountName
• * Affected Users: All LDAP-authenticated users