Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

A searched for answers but have found nothing on here...

Long story short: a non-profit organization is in dire need of modernizing its infrastructure. First thing is to find an alternatives to managing user accounts on a number of Linux hosts.

We have 12 servers (both physical and virtual) and about 50 workstations. We have 500 potential users for these systems. The individual who built and maintained the systems over the years has retired. He wrote his own scripts to manage it all. It still works. No complaints there. However, a lot of the stuff is very manual and error-prone. Code is messy and after updates often needs to be tweaked. Worst part is there is little to no docs written. There are just a few ReadMe's and random notes which may or may not be relevant anymore. So maintenance has become a difficult task.

Currently accounts are managed via /etc/passwd on each system. Updates are distributed via cron scripts to correct systems as accounts are added on the "main" server. Some users have to have access to all systems (like a sysadmin account), others need access to shared servers, while others may need access to workstations or only a subset of those.

Is there a tool that can help us manage accounts that meets the following requirements?

  • Preferably open source (i.e. free as budget is VERY limited)
  • mainstream (i.e. maintained)
  • preferably has LDAP integration or could be made to interface with LDAP or AD service for user authentication (will be needed in the near future to integrate accounts with other offices)
  • user management (adding, expiring, removing, lockout, etc)
  • allows to manage what systems (or group of systems) each user has access to - not all users are allowed on all systems
  • support for user accounts that could have different homedirs and mounts available depending on what system they are logged into. For example
    • sysadmin logged into "main" server has main://home/sysadmin/ as homedir and has all shared mounts
    • sysadmin logged into staff workstations would have nas://user/s/sysadmin as homedir(different from above) and potentially limited set of mounts,
    • a logged in client would have his/her homedir at different location and no shared mounts.
  • If there is an easy management interface that would be awesome.
  • And if this tool is cross-platform (Linux / MacOS / *nix), that will be a miracle!

I have searched the web and so have found nothing suitable. We are open to any suggestions. Thank you.

EDIT: This question has been incorrectly marked as a duplicate. The linked to answer only talks about having same homedirs on all systems, whereas we need to have different homedirs based on what system user is currently logged into(MULTIPLE homedirs). Also access needs to be granted only to some machinees not the whole lot. Mods, please understand the full extent of the problem instead of merely marking it as duplicate for points...

share|improve this question
'Points' aren't awarded for marking duplicate. Your question wasn't clear enough that 5 people considered it duplicate. – Iain Jun 12 '13 at 8:04
Didn't know. Ok, thanks. However, it was marked a duplicate in haste. Please read the point-form requirements that clearly state what is needed. This is not a duplicate. The provided link to "solution" allows indiscriminate access to all systems (we need to limit who has access and to what system or groups of systems). Actual homedir location is dependent what system is being accessed. Same user might have different homedirs AND mounts depending on what system he/she is logged into. – Swartz Jun 12 '13 at 8:05
Just to clarify: in the above mentioned sysadmin example, main and nas are different servers? So, the same user would have access to different homedirs depending on the homedir he logs into? – Marco Bizzarri Jun 26 '13 at 1:17
@MarcoBizzarri : not sure I understand. The system that the user is logged into determines the homedir. SysA and SysB might both have /home/bob in /etc/passwd, while homdir for Bob on SysC might be /someplace/else/bob. The two locations will contain different data. The system user is logged into determines what other mounts are available. This would allow only staff systems to access shared staff mounts. Where as "publicly" available systems will be limited to other mounts. Thus a staff has to be on staff-designated pc to access staff mounts. A bit of compartmentalization... – Swartz Jun 28 '13 at 0:05
Ok, so there are two different points here: the homedir is fixed, and can be somewhere (either on the same server or another one) but it is always that. I mean, SysA has always his homedir on serverX, no matter what. After that, there is a shared dir among the staff, let's call it staff_dir, which should be available when staff people logs into staff_workstation, but not when you log in into normal_workstation; is that correct? – Marco Bizzarri Jun 29 '13 at 8:09

FreeIPA is probably what you're looking for. It's to Linux what Active Directory is to Windows. (It can also talk to AD if you have a heterogeneous environment, but shouldn't be used to manage Windows machines directly. Use AD for that.)

Red Hat's documentation (they call it Identity Management) is very thorough and easy to follow, and should be mostly applicable even if you aren't using Red Hat-derived systems.

share|improve this answer
+1 freeipa is awesome. – Sirex Jun 25 '13 at 0:15
I will be looking at FreeIPA. Thanks for the tip. Question: does FreeIPA support having different homedirs on different systems? Example: user Bob has (NFS-exported) homedir at /shared/home/xyz when logged into SystemA and SystemB, but when on SystemC /whatever/special is Bob's homedir. – Swartz Jun 27 '13 at 23:45
Did you look at automounts? This should get you about 90% of the way there, with the remaining 10% being minor changes to your existing environment. – Michael Hampton Jun 27 '13 at 23:53
Yes, the existing systems do use automounting. These are manually configured for each type of system. Sadly our existing environment is too cumbersome to maintain. Especially after updates or when creating new system images. Although its core does work, there is always something that needs tweaking to make it work. – Swartz Jun 28 '13 at 5:41
Well, then. Now you have a good opportunity to start cleaning stuff up. – Michael Hampton Jun 28 '13 at 6:12

I would suggest a good local consultant to assess the particulars of your situation...


There may be other business requirements or nuances that people on this forum may not recognize or be invested-enough to consider. A dedicated resource is your best bet... Otherwise, we're just throwing product recommendations at you for something that's easily out of scope for a simple Q&A.

Despite that, my approach would be to leverage Microsoft Active Directory and tie the Linux systems in using SSSD or LDAP. FreeIPA is fine in an all-Linux house, but even though you say "non-profit", that doesn't necessarily exclude Windows. You're going to encounter Active Directory somewhere along the path. You may want to augment this with automounted home directories, but the specifics of who gets mounted when or where aren't clear.

Even in the 99% Linux private-cloud environments I build now, I still rely on Active Directory for ease of management and centralized authentication. Groups and access permissions are easy, password policy and account aging is straightforward. Any concerns about maintainability, mindshare and compatibility are covered by the Microsoft solution. Replication is built-in, it's well-documented, and there's a bit of future-proofing inherent to the technology.

There are some details missing from your original question, though...

  • What particular Linux distributions are present in the environment? Are the versions consistent?
  • Do you require the same level of management granularity for your Macintosh systems (most organizations don't attempt to fully manage Apple computers)?
  • Are there remote users?
  • You mention "*nix" - What type of *nixes are present?
share|improve this answer
it's prolly worth nothing that freeipa can do all of those things for linux machines (replication, password policy, groups etc) and its very easy to setup (really!). It also does bi-directional replication against active directory (pretty sure new users are uni-directional due to AD having extra fields), but if you do have windows machines you'll prolly want AD regardless as it's so central to the windows way of life. Also, documentation in freeipa is a little lacking still imho. – Sirex Jun 27 '13 at 20:31
Sadly there is no budget for a consultant. There are no Windows machines (only if staff brings their own). All systems are CentOS (some 5.x others are 6.x). The organization is in the process of getting some older (2007-ish) iMacs, hence it would be nice to have a tool that works on OSX and Linux. One nice thing: no need to worry about Windows. – Swartz Jun 27 '13 at 23:51
Agree with Active Directory suggestion -- if licensing costs are an issue, Samba4 is a free alternative, and uses the same management tools/infrastructure as a native Windows-hosetd AD. Almost anything else can be configured to authenticate against AD through PAM, winbind, LDAP, etc.. For configuration management for the entire infrastructure, check out Salt (…) – nedm Jul 1 '13 at 22:47

Current system works but difficult to manage. I'm guessing there are other problems too for managing those servers if everything was done manually. I'd take a different approach by not replacing something that works (user management) and solve the administration problem of the servers.

I recommend using something like cfengine (free edition there) to "modernise" your system administration, not just user management. It's a good opportunity to try it because your current system works very much like using cfengine to distribute configuration to servers, in your case the /etc/passwd. So instead of replacing, your migrate those scripts to cfengine. Hopefully the impact would be very minimal because you're still using the same /etc/passwd.

Once you're comfortable with the cfengine, you can build more recipes to solve more problems like having a completely new user management system and you have the tool to manage the configuration on the servers.

To help get you started, I found this link that show how to distribute /etc/passwd and related files.

Even if you wanted to replace user management system now, you still need an administration tool to manage those server. It's better to have administration tool sooner than later and reconfigure your user management under an administration tool.

share|improve this answer

Just a few quick things to add -

I have been using Puppet in my deployment - similar idea to cfengine -

This could also do your user management and general configuration/server management.

If you wanted to try something as versatile as Samba, it could have the possibilities to do the management of the directories with some configuration as well as the possibility of using an LDAP backend for configuration. Samba 4 has matured a lot and could actually provide an integrated environment with Windows and Linux for management/authentication.

Samba works with AD or as a replacement for AD as well.

There is also a product called Centrify that I looked at some time ago. I never got too far with it, but I believe they have a freeware/opensource version of it as well. If I recall it had potential for a mixed environment, providing Windows and Linux management, and possibly Mac.

I would second the suggestion of a consultant. These deployments can get very complicated to set up very fast, but easy to maintain once they are documented and configured.

Best of Luck

share|improve this answer
I have looked at Puppet and Chef for config management early on. Puppet allows for 10 free nodes, with Chef you get 5 free. After that point Puppet Labs charges $99/node/year. It would be a few thousand for us. Deal breaker. Although I don't remember Chef's pricing, but it's the same idea. Not in the budget. :( – Swartz Jul 3 '13 at 15:18

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.