LDAP sync deactivates user unexpectedly

Summary

Since upgrading to 5.1.0, a specific user is incorrectly deactivated on every LDAP sync.

Steps to reproduce

Server 5.1.0, E10. Configure AD sync (with the suggested filter to exclude disabled accounts). Sync with AD. Other required conditions unknown

Expected behavior

If the user is not disabled in AD, they should not be deactivated in mattermost

Observed behavior

User is deactivated on every AD sync. Logs show:

2018-08-07T17:29:23.027+1000    info    ldap/ldap_sync_job.go:225    Mattermost user was deactivated by LDAP server    {"workername": "EnterpriseLdapSync", "user_id": "9xuurhe6xb839fyr4ibemhojqo",

They are then re-activated at later random times not aligned with AD sync (perhaps when they attempt to log in?):

2018-08-07T20:31:14.984+1000    info    ldap/ldap.go:234    Mattermost user was updated by AD/LDAP server.    {"user_id": "9xuurhe6xb839fyr4ibemhojqo", 

This cycle keeps repeating.

An observation I suspect is relevant: with debug logs enabled, I saw (anonymised(:

2018-08-07T21:54:14.272+1000    debug    ldap/ldap_sync_job.go:125    Ldap sync foreign user    {"workername": "EnterpriseLdapSync", "ldap_user": {"id":"","delete_at":0,"username":"auser","auth_data":"Auser","auth_service":"ldap","email":"a.user@some.where","email_verified":true,"nickname":"","first_name":"A","last_name":"User","position":"","roles":"","locale":"","timezone":null}}

I note that the auth_data value has a capital initial letter. This is not true for any other user. The AuthData column in the mattermost DB has no initial capital, so they may not match up. Mattermost is configured to use sAMAccountName for the username, login name, and id fields.

Hi @gubbins! Thanks for reaching out.

Can you help share these additional details related to LDAP: https://docs.mattermost.com/process/support.html#ldap-issues.

Can you also help take a look at this section in our docs if the tips there are helpful:

I confirmed that the user has a sAMAccountName in AD starting with a capital letter, e.g. Auser (unlike all our other users). We reset this to auser and did another AD sync in mattermost which did not deactivate him. Fingers crossed that’s the end of that one.

It seems that in mattermost 4 the account name was used in a case-insensitive way and matched the AuthData = auser in the database, while in mattermost 5.1 the account name is used case-sensitive and so it no longer matched the user. Can anyone confirm?

Hi @gubbins - We have a ticket open here related to this, does it seem to describe the issue you are seeing: https://mattermost.atlassian.net/browse/MM-11525?

@amy.blais yes that sounds like the same issue, thanks