Home > Configuration Guides > MySQL LDAP/PAM Connections

MySQL LDAP/PAM Connections

By default most MySQL clients will create a hash of the supplied password and send the hash to the server instead of sending the actual password hash itself. 

This has some limited security benefits such as not allowing an attacker to intercept the password and then use it somewhere else.  It does not of course stop an attacker from grabbing the hash and using that to authenticate to the SQL server the same way, so it is not a substitution for a properly encrypted communications channel.

With LDAP/PAM authentication sending a hash does not work as the LDAP server needs to perform it's own hashing based on it's own (more secure) methods.  Because of this the LDAP server, and thus the MySQL server, needs the original password via the "clear text" method.

All A-Team clusters use SSL encrypted VPNs so this is not a concern, passwords are not sent via clear text.

Storing Passwords

Unless you are using some type of whole-disk encryption (such as TrueCrypt, BitLocker or FileVault) never tell a browser, SQL tool or other program to save LDAP or other critical passwords for you unless it uses MacOS X key chain system (for Windows there is no equivalent, so whole disk encryption is the option).

These one-off "save password" mechanisms are trivial for an attacker to recover and use in the event that your device is stolen or compromised.  Use a proper password vault system.  This is crucial for any tool because of the unified nature of the cluster authentication we use, if one tool exposes your credentials it can lead to an attacker gaining access elsewhere.

Contact A-Team if you have any specific questions about if a program is safe to store a password in.  Assume it is not unless you hear otherwise.

Enable Clear Text

The next sections detail how to enable clear text password authentication in specific tools to allow MySQL and thus LDAP to authenticate you.  Again, due to the VPN your password is not being sent via clear text, it is just not being hashed by MySQL first.

MySQL Command Line

For the command line this is achieved by running the following command before running the  mysql command:

$ export LIBMYSQL_ENABLE_CLEARTEXT_PLUGIN=1

You can then run mysql normally:

$ mysql -u myuser -p -h db1.client.privsub.net

Note: This variable is automatically set when you are logged in to the cluster, doing this is only needed if you are running mysql from your local workstation and you see this error:

ERROR 2059 (HY000): Authentication plugin 'mysql_clear_password' cannot be loaded: plugin not enabled

MySQL Workbench

When creating or editing a connection simply go to the "Advanced" tab and check "Enable Cleartext Authentication Plugin":

Sequel Pro

A popular MacOS client, unfortunately it does not support this feature.

There is a ticket/bug/feature request for it but the developers have closed it:
https://github.com/sequelpro/sequelpro/issues/1836

Their reasoning "this would expose the entire key chain" indicates a deep seated security issue inside how the application stores and manages credentials.  We do not know the specifics but no well implemented application should have issue with this, especially if this used MacOS X's password keychain properly.

For this reason we recommend using MySQL Workbench for MacOS X: http://mysqlworkbench.org/