The authentication process used by MariaDB's PAM authentication plugin goes like this:

• First, it calls pam_authenticate. This step causes the server to authenticate the user account by evaluating all auth module types in the provided PAM service configuration.

https://github.com/MariaDB/server/blob/54caaf684801c332a7130d478023aa7706a69aa1/plugin/auth_pam/auth_pam.c#L154

https://linux.die.net/man/3/pam_authenticate

• Second, it calls pam_acct_mgmt. This step causes the server to verify the user account by evaluating all *account* module types in the provided PAM service configuration.

https://github.com/MariaDB/server/blob/54caaf684801c332a7130d478023aa7706a69aa1/plugin/auth_pam/auth_pam.c#L157

https://linux.die.net/man/3/pam_acct_mgmt

This process is complicated somewhat when the pam_user_map module is included in the PAM service configuration. The pam_user_map module calls pam_sm_authenticate, which means that it is a auth module type, and it is evaluated when the plugin calls pam_authenticate.

https://github.com/MariaDB/server/blob/2ad51a0bd8380fba3d03a4cebd43860329b7fbaa/plugin/auth_pam/mapper/pam_user_map.c#L135

https://linux.die.net/man/3/pam_sm_authenticate

When group mapping is used along with pam_user_map, this means that the user being verified during the pam_acct_mgmt step is not the original user. If a user account with the same name does not exist, this can cause problems.

To give a concrete example, let's say that you have the following PAM service configuration:

#%PAM-1.0

auth required pam_sss.so

account sufficient pam_unix.so

account sufficient pam_sss.so

auth required pam_user_map.so debug

And /etc/security/user_map.conf looks like this:

@dba: dba

If no system user called "dba" exists, then authentication will fail during the pam_acct_mgmt step, and the syslog will have messages like this:

Sep 27 17:17:05 dbserver1 mysqld: pam_user_map(mysql:auth): Opening file '/etc/security/user_map.conf'.

Sep 27 17:17:05 dbserver1 mysqld: pam_user_map(mysql:auth): Incoming username 'alice'.

Sep 27 17:17:05 dbserver1 mysqld: pam_user_map(mysql:auth): User belongs to 4 groups [dba,mongod,mongodba,mysql].

Sep 27 17:17:05 dbserver1 mysqld: pam_user_map(mysql:auth): Check if user is in group 'mysql': YES

Sep 27 17:17:05 dbserver1 mysqld: pam_user_map(mysql:auth): User mapped as 'dba'

Sep 27 17:17:05 dbserver1 mysqld: pam_unix(mysql:account): could not identify user (from getpwnam(dba))

Sep 27 17:17:05 dbserver1 mysqld: pam_sss(mysql:account): Access denied for user dba: 10 (User not known to the underlying authentication module)

Sep 27 17:17:05 dbserver1 mysqld: 2018-09-27 17:17:05 72 [Warning] Access denied for user 'alice'@'localhost' (using password: NO)

This can be solved by simply adding a system user with the same name as the group being mapped:

useradd dba -g dba

But I wonder whether this limitation can be lifted, and if so, whether we would want to lift it. One possible solution would be to implement pam_sm_acct_mgmt for pam_user_map, so that group mapping could optionally happen as a account module type, rather than an auth module type, and it would be evaluated when the plugin called pam_acct_mgmt.

https://linux.die.net/man/3/pam_sm_acct_mgmt

I see that the user is actually changed with pam_set_item, and it looks like that can be called from any module type.

https://github.com/MariaDB/server/blob/2ad51a0bd8380fba3d03a4cebd43860329b7fbaa/plugin/auth_pam/mapper/pam_user_map.c#L220

https://linux.die.net/man/3/pam_set_item

However, I don't know enough about PAM to know for sure that this would make the problem go away.