Approaching user adds and edits with Ansible

I am going to be attached to a small project that basically organizes the users in a cluster of AWS Linux servers. The servers users assigned have different UIDS and maybe different GUIDs. I am hoping to use Ansible to fix this up and organize users better. I can get Ansible to run on a test environment but one thing has got me nervous is that /etc/passwd gets completely screwed up! So my questions are as follows:

• Would a better approach be to overwrite /etc/passwd using Ansible. So basically I have a template of /etc/passwd and use a combination of Jinja2 and Ansible vault to rewrite the values in /etc/passwd (I am currently doing this with sudoers and it works well)? If this is the case, would I need to do anything with /etc/shadow or am I safe there?

• Is Ansible smart enough where I won't need to use /etc/passwd? For example, I have user bob assigned to UID 5001 when he should be consistently assigned 5002. If I was to readd the user using the users module and specifically assign 5002 to his UID, would that work better?

Please let me know if you need any more information.

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 > 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.

StackExchange DevOps Q#2394, answer score: 4