40

Dealing with hundreds of RHEL servers, how can we maintain local root accounts and network user accounts? Is there an active directory type solution that manages these from a central location?

Christian Hudon
  • 541
  • 4
  • 10
Ronaldo Nascimento
  • 483
  • 1
  • 5
  • 8

6 Answers6

37

One central component of Active Directory is LDAP, which is available on Linux in the form of OpenLDAP and 389DS (and some others). Also, the other major component Kerberos is available in the form of MIT Kerberos and Heimdal. Finally, you can even connect your machines to AD.

Thomas
  • 791
  • 1
  • 8
  • 16
Sven
  • 97,248
  • 13
  • 177
  • 225
  • 2
    For the sake of comlpeteness, the agent on the client side, [SSSD](http://fedoraproject.org/wiki/Features/SSSD), should be mentioned too. – fuero Jan 30 '13 at 16:38
  • What about the root account? – Daniel Serodio Jan 30 '13 at 19:21
  • 1
    @DanielSerodio: This is up to the organization and how they handle root access in the first place. For hundreds of servers, I would likely use something like Puppet anyway and use this, either to manage the password as such or `sudoers` rules (or both). – Sven Jan 30 '13 at 20:03
26

You can try with puppet for managing user:

Why Use Puppet to Manage User Accounts? (and not NIS, LDAP, etc)

One of the benefits to managing user accounts in puppet is the fact that it is decentralized. Each user account is just a normal user account on the managed server. There is nothing special about the user accounts puppet creates other than the fact they were created by puppet and not by a human administrator. The nice thing about this is that if the main host dies, we do not lose authentication. Which means that our puppetmaster server (or NIS/LDAP server) need not have any special uptime requirements. If an emergency happens, we can focus on getting our production servers up, and focus on getting the puppetmaster up on an “as needed” basis. The downside to this is that puppet is not necessarily really designed to manage “normal” login user accounts (as opposed to system accounts). The biggest way this comes up is that, although you can set the password in puppet, puppet continually monitors system settings (good) and if it notices that the password has changed, will reset it. (bad) I do not want to monitor user passwords on our network, so there needs to be a way to set a password and have puppet stop monitoring this password. Fortunately, once you figure out the trick, this is actually really quite easy. But first, let’s get some definitions out of the way.

http://docs.puppetlabs.com/pe/2.5/console_auth.html

Community
  • 1
Suku
  • 2,006
  • 13
  • 15
  • This is a valid solution when combined with LDAP, IME. – Tom O'Connor Jan 30 '13 at 17:04
  • @TomO'Connor It's perfectly valid for maintaining local-only accounts in my opinion. – gertvdijk Jan 30 '13 at 23:12
  • This is a very bad idea ... which doesn't enable serious user management, with quick ability to change granted access, neither time framed access management. Definitely not suitable to manage thousands of account like in a university for example. – jmary Dec 18 '17 at 08:55
5

As SvenW mentions, there is 389DS and Kerberos. Since RHEL 6.2, Red Hat have included IPA in the distribution (and thus is in CentOS too). This is a full identity management suite which incorporates 389DS and Kerberos, with policy based control over authentication and authorization, and optionally DNS. It can even be configured for one-way or two-way sync with Active Directory.

IPA pretty much requires SSSD on RHEL hosts but it works without it. I've even tested connecting Solaris 10 to IPA (works, but a bit fiddly). IPA is pretty straightforward to setup for RHEL hosts.

This is based on the FreeIPA project.

James O'Gorman
  • 5,249
  • 2
  • 23
  • 28
1

For your network user accounts OpenLDAP like SvW mentioned.

You should also look at "Configuration Management Systems" for managing your local accounts and everything else on your servers. Take a look at CFEngine, Bcfg2, Puppet, and Chef. If you are using AWS, they have a Chefy thing with OpsWorks.

If you really need to manage 100+ servers, either you have 10 Sysadmins or you use Configuration Management software.

Matías
  • 447
  • 1
  • 6
  • 16
1

This may be an obvious answer, but 'use active directory'. You need to modify our AD schema a little, to include unix specific fields, but once you do, you have a single directory of all your user accounts that works cross platform.

Perhaps less useful if you're a Unix only shop - but I haven't actually seen many of those. But AD is actually a fairly good meshing of the key elements of LDAP and Kerberos. I find that bit ironic actually.

But what you'll get 'for free' is cross platform accounts, and Kerberos integration so you can do NFSv4 exports applying 'CIFS recognised' ACLs, and krb5i/p NFS mounts, with strong(er) user authentication.

Sobrique
  • 3,697
  • 2
  • 14
  • 34
0

As mentioned by @Sven LDAP is the main component for authentication.
We can even consider the below tools for doing central user management in Linux SSSD, FreeIPA, Identity manager by redhat, Centrify Zero trust privilege, Jumpcloud etc. If you have more than 100+ servers please go for Redhat solution ( Identity manager ) & if servers are less than 100 we can choose FreeIPA.

We can even do trust setup with AD using FreeIPA (https://www.freeipa.org/page/Main_Page) or IDM with which we can consider users present is AD can login to your servers.

As you mentioned you have RHEL servers only then you can go ahead with IDM and for maintaining root account disable the direct login for root and any user should not switch to root. For password management of root users consider password manager.

Santosh Garole
  • 383
  • 2
  • 11