LDAP auth fails, while LDAP server gives the right answer

Troubleshooting
1

For feature requests, please see: http://www.mattermost.org/feature-requests/.

For troubleshooting questions, please post in the following format:

Summary

We want to introduce Mattermost, but LDAP auth (which is essential) fails (“User not registered on AD/LDAP server”), while the LDAP-Server gives back the right answer.

Detailed description

Using version Mattermost 5.10.0 and OpenLDAP 2.4.45 on a Univention installation, the LDAP auth, which works with a handful other services properly, doesn’t work with MM. The only info, also in DEBUG mode, is this line

({“level”:“error”,“ts”:1576593395.9385178,“caller”:“mlog/log.go:172”,“msg”:“User not registered on AD/LDAP server”,“path”:"/api/v4/users/login",“request_id”:“spmf4zhpwbbzme8chjrqj9ub4r”,“ip_addr”:“x.y.z.11”,“user_id”:"",“method”:“POST”,“err_where”:“findUser”,“http_code”:401,“err_details”:“username=”})

while I can see on the LDAP log, that MM gets the right answer, but closes the connection not properly (LDAP-Server says: connection lost), and though LDAP gives back one proper entry (nentries=1), MM obviously doesn’t accept this and tries other properties which cannot work. Unfortunately I get no debug log on what MM receives and why it discards the answer.

Dec 16 19:20:51 server slapd[16882]: conn=1146 fd=28 TLS established tls_ssf=256 ssf=256
Dec 16 19:20:51 server slapd[16882]: conn=1146 op=0 BIND dn=“cn=matte-23,cn=memberserver,cn=computers,dc=fxt,dc=de” method=128
Dec 16 19:20:51 server slapd[16882]: conn=1146 op=0 BIND dn=“cn=matte-23,cn=memberserver,cn=computers,dc=fxt,dc=de” mech=SIMPLE ssf=0
Dec 16 19:20:51 server slapd[16882]: conn=1146 op=0 RESULT tag=97 err=0 text=
Dec 16 19:20:51 server slapd[16882]: conn=1146 op=1 SRCH base=“dc=fxt,dc=de” scope=2 deref=3 filter="(&(uid=chris.moller)(&(objectClass=mattermostUser)(mattermostActivated=1)))"
Dec 16 19:20:51 server slapd[16882]: conn=1146 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
Dec 16 19:20:51 server slapd[16882]: conn=1146 fd=28 closed (connection lost)
Dec 16 19:20:51 server slapd[16882]: conn=1147 fd=28 TLS established tls_ssf=256 ssf=256
Dec 16 19:20:51 server slapd[16882]: conn=1147 op=0 BIND dn=“cn=matte-23,cn=memberserver,cn=computers,dc=fxt,dc=de” method=128
Dec 16 19:20:51 server slapd[16882]: conn=1147 op=0 BIND dn=“cn=matte-23,cn=memberserver,cn=computers,dc=fxt,dc=de” mech=SIMPLE ssf=0
Dec 16 19:20:51 server slapd[16882]: conn=1147 op=0 RESULT tag=97 err=0 text=
Dec 16 19:20:51 server slapd[16882]: conn=1147 op=1 SRCH base=“dc=fxt,dc=de” scope=2 deref=3 filter="(&(?uidNumber=)(&(objectClass=mattermostUser)(mattermostActivated=1)))"
Dec 16 19:20:51 server slapd[16882]: conn=1147 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text=

What is going wrong?

2

@christo Would there be an issue for you to upgrade your server version? Our latest stable version is v5.17.0 https://docs.mattermost.com/administration/changelog.html#release-v5-17-quality-release.

3

Hello, @christo

On top of the suggestion by Amy to upgrade to the latest version, I would like to confirm how AD / LDAP is currently being configured on your Mattermost instance based on the following error:

Please refer to the following questions below:

  • Will it be possible for you to attach a snippet of the LdapSettings section with the sensitive information removed so we can take a look at it?
cat /opt/mattermost/config/config.json | grep -A30 "LdapSettings"
  • Can you run the ldap_check.sh script located here from inside the /opt/mattermost directory to double check that the user is on the LDAP server?
  • While the LDAP configuration values are case-sensitive, can you also verify that the config file has the right cases for the LDAP and SAML fields based on how your server is configured?
  • Can you also run the SQL query below to verify if there are any LDAP users in the system as of now?
SELECT Username, AuthData, AuthService FROM Users WHERE AuthService = "ldap";
4

Hi ahmaddanial,

thanks for your support! Further analysis following your remarks showed up, that it seems to be a ldap-server problem. Mattermost can connect on one port, but not search, while from another server (I couldn’t use ldap-check, because no ldapsearch is available in the docker container) I cannot connect on the port mattermost can connect, but can connect and search on the port mattermost fails.

I close here.

BR, Christian