Approaching user adds and edits with Ansible
If editing critical flat-files across multiple servers in one place is too scary..

One approach I have often recommended is to let system users reside in /etc/passwd files, and to add an additional Name Service Switch (NSS) source for humans that need to log in. For big projects (lots of users authenticating against the PAM user data), that means LDAP, and for small ones (few can be hundreds of such users), nss_db + pam_userdb.

With multiple NSS and PAM sources for users, you can avoid disabling a server when the human user accounts distribution fails for whatever reason. Services (like your privileged Ansible account) should always depend ONLY on the standard /etc/passwd files. LDAP (or even MySQL) is probably overkill for some cases (like yours). 

Consider the old BDB backed gems, designed originally (for big FTP file distribution servers) to provide faster logins than /etc files, but otherwise work nearly the same. They store the same passwd and groups flat files' content, but loaded into a (now non GPL) BerkeleyDB NOSQL key/value database file which is faster to read. For this purpose, it's just an extra place to store user/group authentication/authorization data.

NSS

https://en.wikipedia.org/wiki/Name_Service_Switch

https://www.systutorials.com/docs/linux/man/5-nsswitch.conf/

https://sourceforge.net/p/nssdb/home/Home/

PAM

https://en.wikipedia.org/wiki/Linux_PA

https://www.systutorials.com/docs/linux/man/8-pam_userdb/

https://www.cyberciti.biz/tips/centos-redhat-vsftpd-ftp-with-virtual-users.html

steps


collect your passwd, shadow, and group files on a secure server with
the nss_db Makefile
build the nss passwd and group db files using the provided nss_db
Makefile
extract the users and password hashes from shadow file and build PAM db file

awk -F: '{print $1;print$2}' shadow &gt; users.txt # used like the vsftpd vusers.txt example

db_load -T -t hash -f users.txt pam-users.db

distribute the files to somewhere appropriate on your target servers
(maybe /var/db/authdb/*.db)
set up the target servers' pam.conf and nsswitch.conf files to use
these db files
Steps 1-4 are the repeatable build/deploy process.


why?


Once you have working pam/nss configs, your risk of breaking services
by updating/corrupting user auth/auth is very low.
User authentication will work on each server with no external network dependencies like LDAP or MySQL etc.
You can treat the DB files as immutable artifacts on the farm to reduce/prevent user auth snowflakes even if you can't have immutable servers.