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
DeleteAtcolumn for the user in theUserstable is non-zero. - The
AuthDatavalue stored in theUserstable does not match the current LDAPIdAttributevalue.
âś… 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
- Take a database backup before making changes.
- Update the
AuthDatacolumn to the current LDAPIdAttributevalue:
UPDATE Users SET AuthData = '<new_ldap_id_value>' WHERE Id = '<mattermost_user_id>';
- In System Console > Authentication > AD/LDAP, click AD/LDAP Synchronize Now.
- Verify the user's
DeleteAtis now0and 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 theWHEREclause 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:
Comments
Article is closed for comments.