3

I need some usermanagement for a serverfarm of +/- 30 linux servers. Normally I would think of something like LDAP, but we don't want to rely on a global server to which we need to authenticate, in case of downtime or broken connections.

So I was thinking of writing some scripts that synchronise /etc/passwd and /etc/shadow and checks if homedirectories exists. Including the posibility to exclude some users at some of the servers.

But... I couldn't imagine that I'm the only person in the world that would need something like this. So does someone know an opensource project that does such a thing?

blauwblaatje
  • 953
  • 1
  • 6
  • 19

9 Answers9

6

I still say LDAP, even given your caveats. Centralized authentication single-point-of-failure is a problem that's been known for some years, which is why Windows got rid of the PDC/BDC model of WinNT and went with a multi-master distributed model as of Active Directory. Novell's eDirectory (a very fine LDAP server among other things) has been doing multi-master for over 15 years now. Both can function well transiently separated from the rest of the authentication network, over slow WAN links, and function in spite of the usual hang/reboot/rebuild process that marks all IT. With the exception of extended downtimes (day or more) this is a largely solved problem.

Just not as much in the open-source space, that I've seen. OpenLDAP does have replication between multiple LDAP servers which gives you your fault tolerance.

Branching out a bit, if you do have an Active Directory environment to work with Samba comes with ways to work with AD that'll do multi-master identity processing. If one DC is down, it'll talk to other ones. If you're not afraid of the still in development Samba 4, you can even set up a completely linux-based AD environment, and use winbind on your client servers to handle distributed auth.

sysadmin1138
  • 133,124
  • 18
  • 176
  • 300
4

I have not seen an open source solution, but we have rolled our own before. It is relatively simple to have root run rsync and synchronise /etc/passwd, /etc/shadow and home directories containing authorized SSH keys.

One thing to keep in mind though - the "master" copy of /etc/passwd and /etc/shadow need to have the details of all users on all systems. This means if you have 1 machine with MySQL and another with Apache, the passwd/shadow file will need to contain both the mysql user and the www-data user. This leads to there being more entries in passwd/shadow on some machines than there needs to be.

Another note: it is best to do this as early in deployment/set up as possible, as you may end up dealing with UID collision when creating the "master". If you implement this on systems that are already running, you will need to figure out which user has which UID, and change directory/file permissions on each system accordingly.

Peter Sankauskas
  • 698
  • 6
  • 11
  • 21
  • What you're describing is what I had in mind. Although not with rsync, but generate a passwd-file and push them to the other servers. – blauwblaatje Aug 04 '09 at 17:16
3

The simplest solution would be to have a master system, and a cron job that runs on the individual nodes to rsync the passwd, shadow, and group files on a regular basis. It feels like a nasty, dirty hack, though.

In a broader sense you could use puppet as an all encompassing configuration management tool. This includes user accounts. In effect you define all the user attributes and group memberships globally. Then on a machine group, or per machine, basis you define the groups, or individual users, that have access to the system. Since the authentication and authorization is taking place locally, even if your puppetmaster is down users can still login. You would only lose change propagation.

Since puppet only manages those files and services you explicitly define, it makes it easy to centrally manage some aspects, whilst locally managing others.

Scott Pack
  • 14,907
  • 10
  • 53
  • 83
2

This is why Active Directory requires (well, nearly anyway) multiple servers. So that when one of them dies, you're not screwed.

If you've got a user base of any size, you do not want to rely on de-centralized management, even if it is through something like puppet. Moves Adds and Changes (MACs) will be no fun. At all. Plus, without centralized authentication, you'll need to manage local accounts, samba accounts, htaccess accounts...where as you /could/ centrally authenticate everyone at once.

Please, reconsider centralized authentication for your own sanity.

Matt Simmons
  • 20,396
  • 10
  • 68
  • 116
  • Despite my previous answer, I do agree with this. One of my most common recommendations is centralized authentication/authorization with a fine print 'whenever reasonably possible'. – Scott Pack Aug 04 '09 at 15:11
  • Yeah, it's just too good to pass on. I have somewhere around 60 linux servers and two windows servers. Can you guess what they're doing? Active Directory, to manage the authentication on the Linux servers (plus 15 user desktops) – Matt Simmons Aug 04 '09 at 15:24
1

Would something like this work? Apparently they use MySQL to scale an OpenLDAP installation and replicate it.

I think Kerberos can also be set up to be distributed. This is an older article that discusses a little about it.

I don't know if you have any Windows AD systems in your network, but if you do you can set up modules for authenticating against that.

Bart Silverstrim
  • 31,172
  • 9
  • 67
  • 87
1

I still say LDAP is the easiest / best choice. Insanely reliable, very easy to maintain. I've been running master/slave LDAP pairs in production for several years now without a fault. At my previous job they provided authentication for 20 - 30 servers and hundreds of workstations. To the best of my knowledge, they never failed over as a result of a fault. When I would deliberately fail over (reboot / upgrade / etc) no one noticed.

That being said, there is a solution that does almost exactly what you describe but with the advantage of being centrally managed: NIS. It distributes passwd, hosts, group, etc. via a a client-server protocol but is, as I understand it, fully capable of continuing to function if the server goes away. It's a little complex but is supported by every *nix-like OS that I can think of.

Insyte
  • 9,394
  • 3
  • 28
  • 45
1

LDAP is great, but it does add some complexity that you might not be equipped to handle. Also, you will have to build tools and configuration management on the servers to work with LDAP. While PAM modules (Pluggable Authentication Modules) in Linux go a long way in supporting some of your needs, they may not meet them all.

I might also suggest the use of something like puppet (http://reductivelabs.com/products/puppet/). While I haven't used it much, it may be good as a total solution for you instead of LDAP or as a means for adding tools and addressing cases that LDAP does not.

Jim
  • 576
  • 2
  • 8
0

although it's not a nice one, you can replicate the ldap database (or a part of it) on the ldap clients (actually, the servers)

the weakness of this is that the database gets corrupted as the ldap clients gets corrupted, the advantage is that you will have plenty of replicas, making your data incredibly safe and if connection drops between the master and slave databases, you can continue using the replica instead

asdmin
  • 2,050
  • 17
  • 28
0

I'll chime in with the rest and suggest LDAP. If you really want local passwd files, though, consider generating them from the LDAP. You could either generate them somewhere centrally and then distribute them (puppet, rsync, etc.), or you could have each client generate its own. If the LDAP server is unavailable, the local passwd file is still there to fall back on. Having the LDAP server there and maintaining the information allows you to go ahead and use or create the tools you need for provisioning and user management, so if you ever do decide to trust your network/set up redundant servers, you have a very simple migration path.

Chad Huneycutt
  • 2,116
  • 1
  • 16
  • 14