5

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:

  1. 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?
  2. 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.

chicks
  • 1,848
  • 1
  • 12
  • 29
ryekayo
  • 151
  • 3
  • 2
    I'd try the user module first. You might end up with local users that aren't in the central list that shouldn't get overwritten. Replacing /etc/passwd would cause those users to get lost. – chicks Oct 23 '17 at 16:55
  • Well one concern i have is trying to organize the UIDs for existing users and making sure they UIDs get correctly overwritten and stay consistent throughout the cluster of servers I have.. – ryekayo Oct 23 '17 at 18:01
  • What is unclear in ansible user management documentation about forcing the uid ? – Tensibai Oct 24 '17 at 07:57
  • @Tensibai I never said i was unclear about Ansible's documentation. In fact, Ansible is well documented. What I was asking is if reassigning a UID for already created users would have any side effects and if i would be better off rewriting /etc/passwd. But I think at this point, I am fine with just using Ansible's user module to overwrite the UIDs – ryekayo Oct 24 '17 at 13:49
  • Changing a user uid will not change files ownership, so yes there's an impact, whatever the solution you go for. – Tensibai Oct 24 '17 at 13:58

1 Answers1

4

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

  1. collect your passwd, shadow, and group files on a secure server with the nss_db Makefile
  2. build the nss passwd and group db files using the provided nss_db Makefile

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

  4. distribute the files to somewhere appropriate on your target servers (maybe /var/db/authdb/*.db)

  5. set up the target servers' pam.conf and nsswitch.conf files to use these db files

  6. 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.
Tensibai
  • 11,366
  • 2
  • 35
  • 62
Jeremy
  • 314
  • 1
  • 5
  • For 3, the stdin redirection is superfluous, awk can read a file directly: awk -F: '{print $1;print$2}' shadow > users.txt is enough – Tensibai Oct 24 '17 at 07:53
  • I chose this syntax @Tensibai it is only superfluous to the shell, commands. It communicates intent a little more – Jeremy Oct 24 '17 at 14:58
  • feel free to edit it back in, I was mainly editing for the code block at first. (I'm against unnecessary context changes and stream abuse where not needed) – Tensibai Oct 24 '17 at 15:16
  • Not worth the quibble on my end. Thanks for caring though! – Jeremy Oct 25 '17 at 18:19