LDAP User Remains Deactivated After Returning - AuthData Mismatch on IdAttribute Change

Applies to: Mattermost Server v10.5 and later (self-hosted deployments using AD/LDAP authentication)

Symptoms: An LDAP-managed user remains deactivated after returning to the organization, and mmctl user activate fails with "unable to change activation status of user."


🛑 Problem

When an LDAP-managed user leaves an organization and their LDAP entry is removed (or stops matching the configured UserFilter), Mattermost deactivates the user on the next LDAP sync by setting DeleteAt to a non-zero timestamp in the Users table.

If the user later returns and a new LDAP entry is created with a different value for the attribute mapped to IdAttribute (e.g., uidNumber), Mattermost cannot match the returning LDAP entry to the existing deactivated user record. The LDAP sync matches users strictly by AuthData (the stored value of IdAttribute); there is no fallback to email or username. Because no match is found, the sync treats the LDAP entry as a new "foreign user" but cannot create a duplicate since the username/email already exists. The user stays deactivated indefinitely.

Running mmctl user activate does not work for LDAP-managed users because their activation state is controlled exclusively by the LDAP sync process.

Symptoms

Users or administrators experiencing this issue will see:

Error: 1 error occurred:
 * unable to change activation status of user: <user_id>

Additional symptoms:

  • The user appears as "Deactivated" in System Console > User Management > Users and cannot log in.
  • LDAP sync logs at debug level show the user as "Ldap sync foreign user" with the correct attributes, but the user is never reactivated.
  • No error is logged for the specific user during sync; the mismatch is silent.
  • The DeleteAt column for the user in the Users table is non-zero.
  • The AuthData value stored in the Users table does not match the current LDAP IdAttribute value.

âś… Solution

Align the AuthData value stored in the Mattermost database with the user's current LDAP IdAttribute value. Once aligned, the next LDAP sync will match the user and reactivate them automatically.

Confirm the AuthData mismatch

Query the Mattermost database to check the stored AuthData for the affected user:

SELECT Id, Username, AuthService, AuthData, DeleteAt
FROM Users
WHERE Username = '<username>';

Compare the AuthData value returned with the current value from LDAP. You can retrieve the current LDAP value with ldapsearch:

ldapsearch -H ldaps://<ldap_server>:<port> \
  -D "<BindDN>" -W \
  -b "<BaseDN>" \
  "(&<UserFilter>(<LoginIdAttribute>=<username>))" \
  <IdAttribute>

Replace <ldap_server>, <port>, <BindDN>, <BaseDN>, <UserFilter>, <LoginIdAttribute>, and <IdAttribute> with the values from your LdapSettings configuration. If the two values differ, proceed with the fix.

Update AuthData in the database

  1. Take a database backup before making changes.
  2. Update the AuthData column to the current LDAP IdAttribute value:
UPDATE Users SET AuthData = '<new_ldap_id_value>' WHERE Id = '<mattermost_user_id>';
  1. In System Console > Authentication > AD/LDAP, click AD/LDAP Synchronize Now.
  2. Verify the user's DeleteAt is now 0 and the user can log in.

⚠️ Important: Always take a database backup before modifying the database directly. Use the user's Mattermost Id (not username) in the WHERE clause to avoid unintended changes. If your deployment uses a read replica, ensure you run the update against the primary database.

Enable LDAP trace logging (optional, for further diagnosis)

If the user is still not reactivated after updating AuthData, enable LDAP trace logging to capture detailed sync behavior. Add the following to System Console > Environment > Logging > Advanced Logging (the LogSettings.AdvancedLoggingJSON config key):

{
    "ldap-trace": {
        "type": "file",
        "format": "json",
        "levels": [
            {"id": 144, "name": "LDAPTrace"},
            {"id": 143, "name": "LDAPDebug"},
            {"id": 142, "name": "LDAPInfo"},
            {"id": 141, "name": "LDAPWarn", "stacktrace": true},
            {"id": 140, "name": "LDAPError", "stacktrace": true}
        ],
        "options": {
            "filename": "./logs/ldap.log",
            "max_size": 100,
            "max_age": 14,
            "max_backups": 3,
            "compress": false
        },
        "maxqueuesize": 1000
    }
}

Trigger an LDAP sync, then review ./logs/ldap.log for entries related to the affected user.

⚠️ Important: LDAP trace logging is verbose and can impact disk usage. Disable it after collecting the required logs by removing the configuration block and saving.

Additional Resources

For more information, see:

AD/LDAP setup

Authentication configuration settings - ID Attribute

Mattermost logging - LDAP trace logging

Was this article helpful?
0 out of 0 found this helpful

Comments

0 comments

Article is closed for comments.