[MXS-334] Enable Pam.d Support Created: 2015-08-26  Updated: 2020-08-25  Resolved: 2017-08-07

Status: Closed
Project: MariaDB MaxScale
Component/s: mariadbbackend
Affects Version/s: None
Fix Version/s: 2.2.0

Type: New Feature Priority: Major
Reporter: kevin oswald Assignee: Esa Korhonen
Resolution: Fixed Votes: 4
Labels: None

Issue Links:
Relates
relates to MXS-1432 PAM.D authentication Closed
relates to MXS-1758 Support PAM group mapping, like Maria... Closed
relates to MXS-2267 Document which accounts PAM authentic... Closed
relates to MXS-2269 Document user and group mapping suppo... Closed
relates to MXS-2292 Allow PAM user and group mapping to w... Closed
relates to MXS-2294 Document how to configure user and gr... Closed
relates to MXS-2383 Support PAM authentications involving... Closed
relates to MXS-2478 Support mysql_clear_password for PAMA... Closed
relates to MXS-2479 Don't throw error for PAM_TEXT_INFO i... Closed
relates to MXS-673 Separate authentication form data Closed
Sprint: 2017-36, 2017-37, 2017-38

 Description   

We currently use pam.d to authenticate users against are database, so have one central user management solution. MariaDB plugin works great for this, but would be nice if could use the same users while utilizing Maxscale.



 Comments   
Comment by John W Smith [ 2016-08-19 ]

While lack of this feature isn't critical for deploying in our environment, it makes management much more difficult. Currently all of our users are auth'd via pam+ldap to our AD domain. We only have a couple of DB admins, so no big deal in production, but on the development side, we have many developers that need access to the development DB's to allow query analisys, index creation, etc. Since we adhere to most banking regulations regarding security of DBs, files, etc, we require frequent password changes. Since we currently have no method of syncing a password change to the DB users, we have to depend on the users to change the passwords on the DB servers themselves, not an ideal situation to say the least.

Comment by Esa Korhonen [ 2017-06-22 ]

Adding a PAM authentication plugin similar to the one on the server to MaxScale should be possible. This would allow the client (assuming the client UI/command line supports PAM communication) to login to MaxScale. However, after this MaxScale needs to login to the backend servers using the client's username while the host machine changes from the client machine to the MaxScale machine. This MaxScale-to-backend login must be doable autonomously. Also, contrary to a normal sql login, MaxScale would have no other information about the user other than the username.

Here are some possibilities for the backend login:
1) Each backend allows MaxScale to login without a password for select users. Unsecure.
2) We implement a new PAM plugin that would run on the backends. This plugin would contact the MaxScale machine and ask if the user is currently logged in and accept the login if that is the case. Would require using non-standard PAM-plugins on the server.
3) Could the MaxScale machine obtain a token for the user from the ldap server and use that to login? Or could the backends check from ldap that the user is logged in and accept his login from MaxScale-IP? My knowledge on ldap is superficial, so I don't know if these are possible.

In any case, more information on what would MaxScale actually need to do is required to implement PAM support. JWSmith

Comment by Esa Korhonen [ 2017-08-07 ]

A very limited implementation.

Generated at Thu Feb 08 03:58:31 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.