We have been using LDAP for authentication for over a year, and there was no problem.
Recently I noticed new users cannot login to Metabase, and current users cannot log back in if they log out of Metabase.
The error is this:
ERROR metabase.api.session Problem connecting to LDAP server, will fall back to local authentication
DEBUG metabase.middleware.log POST /api/session 400 151.0 ms (1 DB calls) {:errors {:password "did not match stored password"}}
The first error line, doesn’t say why it couldn’t connect (there is usually a sentence after this message that says what was the issue).
The second line of error (“did not match stored password”) seems to be because of the LDAP connection problem in the first line. So it doesn’t provide info on what the problem is either.
I noticed the problem when we were using 0.36.3. Then I upgraded to the latest version, and the problem persisted.
My problem is that I don’t know what to debug, as the error message doesn’t say why it couldn’t connect.
@King_Edward Okay, that helps, since we can rule that PR out then.
Are you using hostname, FQDN or IPs for the address in Admin > Settings > Authentication > LDAP?
The problem is that there’s very little debug-strings in the LDAP code, so even enabling debug logging will probably not give any additional information. But you could try.
Otherwise do regular network testing by connecting to the container and see if you can ping/telnet to the LDAP server. And make sure there isn’t some firewall on the LDAP server, which is blocking, so check if you can see any type of connection attempts on that side.
Thanks @flamber.
We are using hostname in Admin > Settings > Authentication > LDAP.
Enabling debug logging didn’t produce extra info.
I SSHed to the EC2 instance that EB is using for deployment of Metabase, and pinged our AD server hostname, and it was ok.
When I change settings in Admin > Settings > Authentication > LDAP, and click “Save Changes” it succeeds. Does this confirm that MB can indeed connect with the AD server?
No, the settings are just saved without validation (different from the data sources).
Hmmm… could it be that some AD update have changed something, which broke something?
Have you tried using the direct IP instead of hostname?
So while secure connections are really important, they are also a pain to debug, since you can’t just run a simple tcpdump/wireshark to sniff the LDAP traffic and see what’s going on.
But it sounds like the problem is likely not Metabase, but somewhere else.
Which was the last version of Metabase, where you know it worked? Then try loading that version.
By “secure connections” do you mean HTTPS or LDAP Security in Admin > Settings > Authentication > LDAP? For LDAP Security setting we have used None so far.
I installed WireShark and filtered data to show packets related to the IP of AD server. I see some packets sent to and received from that IP when I try to login to Metabase. Somewhere in the details of the packets it says Non-authenticated data: Unacceptable. Not sure if this is related to the problem though.
It turned out my DN in our AD server had changed recently. Since I was using my DN as the Lookup User in Admin>Settings>Authentication>LDAP, nobody could login.
So, I guess it is safe to say that when we get “did not match stored password” where Metabase uses LDAP authentication, one of the following settings in Admin>Settings>Authentication>LDAP is not set properly (assuming that we entered the password correctly, and there is no Firewall issue):