Group/user accounts management across big list of different server

Latest response


I wonder if you guys could share your experience in the above topic.
What I mean is that how do you cope with requirements like:
- create user account for new users: U1, U2, ..., Ux on servers S1, S2, ..., Sx
- create user account for new users: U1, U2, ..., Ux on servers S1, S2, ..., Sx
- give access to group of users (U100, U101, ...) on servers S100, S101, ..., Xy
- lock the following users: U200, U201, ... on the following servers S....
- give sudo access for this groups G1, G2, ... on servers S1, S100, Sx
where number of users and server can be quite long.
I am looking for solution which is going to work on both RH 5 and 6.
I know there some LDAP, AD integrated, IPA, ... solutions for this kind of tasks.

But can you compare them ?

Which of these solutions really work and doesn't involve a lot of time maintaining the software ?



If you've got an AD infrastructure already, AD integrating them is definitely the way to go - especially if you pop for the non-free versions of the various vendors' "open" (free) products. The "Enterprise" editions frequently include the kind of additional functionality that lets you centrally manage everything about your users (when they can log in, central management of automounted home directories, centralized management of `sudo` capabilities-sets, etc - and all usually from a nice GUI).

Granted you can do similar with the free stuff and accomplish a number of the same things with a basic LDAP source, it's just a lot less drool-n-click. And, if you've already got an AD infrastructure, you can pawn your user/rights-management tasks onto someone else and go about less mundane things.

In general, I tend to prefer integrated solutions as it gives me yet another avenue for checking if a system is still part of my enterprise configuration. If you're using something kerberized like winbind/Centrify/Likewise for your integration, a quick query of your AD can tell you how long its been since a given computer's machine-account went inactive. If you're using static DHCP, you can tell the last time a given computer refreshed its IP configuration information (and, if that was longer ago than the lease-length, that the system's likely not in a proper state).

Yeah, you should probably have an SNMP/WBEM infrastructure in place to tell you that before you discover staleness in your other tools, but it never hurts to have multiple places for finding problems.

Hi Tom,

yes, we do have AD infrastructure already so it seems that it would be the way to go as you said. I don't think we could buy any non-free software right now so we have to stick with free software for a while (at least ...).

Which of the (free) software integrating with AD is reliable and doesn't require a lot of maintenance ?

I believe Red Hat Identity Management (Formerly IPA) is included with your RHEL subscription.  It has hooks to specifically allow what I think you are trying to do.  It is cross-platform and the authentication with Red Hat hosts is built in.

In my experience, it is a solid solution and is not overly-complex.  It does require some investment to get "up to speed" with how it works, however.  I anticipate that it will become more tightly-couple with the entire Red Hat stack as time goes on.


most of our servers are still RH 5. Would it work well with this release ?

Does it integrate with AD ? And why wouldn't integrate nodes with AD without IPA ?

What features IPA gives me ?

Just wanted to add a +1 for Active Directory since you have it in place already.

Here's a pre-written Red Hat solution that may be helpful to you:

Hi guys,

thank you for your answers :-) I thought of using existing AD but wasn't sure it this solution is reliable enough.

In manuals everything works but in reality it is not always so easy ;-)

RHEL 5 definitely is a supported release.  freeIPA is the community project that feeds Red Hat Identity Management.  The feature list is pretty extensive - therefore it is difficult to provide a list of features that it would provide (and I don't want to sell the product short of it's capabilities ;-)

The AD passthru is definitely a nice feature, but IdM also provides support for managing netgroups, host-based access, auto-mounts, AD to Linux UID/GID mapping.  A significant advantage also is the caching ability.

You certainly can directly integrate to AD - my personal hesitation when I considered options was the frequency that Microsoft made significant changes to the way that AD worked and that made me fearful that it would somehow disrupt my Linux authentication services.  I like the abstraction that RH IdM provides - almost like a protective barrier between AD and my Linux hosts.

Red Hat Identity Management is a tremendous solution and I would recommend spending some time with your Red Hat team to discuss your requirements and your environment so that they can make sure you understand what their IdM can provide.

I am a bit confused betweet the two solutions:

  1. IPA-based
  2. non-IPA

Do I understand correctly that both are based on existing AD server but in 1. solution the IPA is a sort of broker/agent between user accounts and AD ? If so what is the value added by IPA ?

It comes down to the size and complexity of your Active Directory forrest.

Single domain forrest with only a few thousand objects can be easily accommodated by the Winbind components in RHEL (if you're doing RHEL 5 and AD 2008, you'll want the winbind from the Samba 3x release; if you're doing RHEL 5 and AD 2003, then the standard winbind 3 will do). The RHEL sysconfig-auth tools will give you a GUI for setting it all up.

If you're trying to integrate with a multi-domain forrest thats several tens to hundreds of thousands of objects in size, you'll need to do either winbind from the Samba 4 release tree (if RH haven't put it in their main release-stream, it's probably available via EPEL) or something like Likewise/PowerBroker or Centrify. Likewise and Centrify both offer configuration GUIs, but, if you're trying to set up a bunch of RHEL clients against AD, you're better off scripting the installation, join and configuration tasks.

Samba's initial setup can be kind of a pain if you're looking to have consistent ID maping across hosts. The default behavior is to use local id-mapping. If you want consistent userids/groupids across RHEL systems, you'll want to ensure that you've: A) configured RID mapping; and, B) set up your RID ranges the same across nodes.

Centrify and Likewise both default to RID-mapping but use slightly different formulas for deriving the RIDs. The RIDs give you consistent UIDs/GIDs across all the nodes attached to your domain controllers (critical if you're using network shares for home directories - speaking of which, if your home directories are CIFS rather than NFS, and you opt for the free versions of Centrify or Likewise, you'll probably want to look into pam_smbmount or similar utilities). 

The benefit of the client-side integration tools like winbind, Centrify and Likewise is that you don't need to stand up any server-level connector pieces. IPA's a great product, but having to set up a bridgehead into your AD domain is more work than is typically necessary to support basic user-management type tasks. 

If it's of any help, our AD forrests are multi-domain forrests consisting of 100,000+ AD-managed user accounts, a similar number of security groups and thousands of computer/machine objects projected around the globe across a few hundred domain controllers (we have lots of "edge"/satellite facilities that used to be connected via unreliable links, thus more DCs than might be found in a network with more reliably-connected edge facilities). Our ADs are too big for the RHEL-shipped winbind versions but work well under Likewise (and Centrify and a few other products that were deployed prior to our formal enterprise unification effort).

Only major issue we've encountered have been in our larger virtualization environments during online-migration events. That's more a Kerberos issue than an issue with the connector software. Kerberos gets a bit pissy when there are time inconsistencies - the kind that can happen during online-migration events. It's most problematic on hosts that are doing large numbers of attribute-checks per minute (e.g. NetBackup servers).

IPA is free. IPA gives you the type of centralized policy-management that AD gives to native Windows clients (and that the "enterprise" versions of the free software solutions give by extending your AD schema and adding management-plugins/tabs to your domain controllers). Basically, with IPA, you could have GPO-type functionality on your Linux clients the way you have it on your Windows clients.

If you need the GPO-type functionality but don't have the budget to do it within AD via for-cost extensions, IPA is the way to go. If, on the other hand, all you're really looking for is basic user-management and SSO type of functionality, IPA adds more management-overhead to your overall directory services than might really be necessary.

Hi all,

thank you for all your answers - they really clears up this picture.

But how about the worst case when the same users exists on different servers with different UIDs on each ? Which approach would be the best to unify all UIDs/GIDs for existing user accounts ? The case when we create a new user is the easiest one. How about deploying AD/IPA based solutions in existing environement which are not really standardized ? Which solution can cope with such "mess" with a little effort ?

Numerical identifiers will be different from domain-to-domain. Use proper RID-mapping in whichever solution you're using to pull AD data and you won't have numerical collisions.

Logical userids and groupids pulled from AD are fully-qualified. Typically, you'll use either NTLM-style or Kerberos-style userids. Only real potential for collisions will be if trying to leverage a default domain to yield POSIX-style IDs. That said, you can generally only set one default domain to derive POSIX-style userids. Users in other domains will need to be fully-qualified - avoiding collisions in logical userids/groupids.

The other reason to avoid default domains: don't have to worry about your files-based userids colliding with your AD-based userids.

As to a user (as in a single human) that exists in multiple domains - that's far outside the scope of "how do I pull data from AD". AD-merge questions are best discussed on an AD-centric forum.

I've used/configured SSSD to AD and for me is simplest and easist to manage solution.   If company has a policy that all unix accounts should authenticate against your company corp AD then this works very well.

Here's a good guide from RHN - Integrating RHEL with AD  - good chapter on SSSD

Great! Thanks for including the link Todd

Most of our RH servers are still 5.*. Do you have any similar manual for RH 5 ?

Most of the RHEL 6 with SSSD will work with RHEL 5. I iniatally installed/configured all my sssd on rhel 5 to AD 2k3 then again to 2k8. 

Here's some additional links, hope they help:

Using SSSD -RHEL 6 Deployment Guide

Using SSSD - RHEL 5 Deployment Guide

also if authentication against AD, depending on 2k3 or 2k8, make sure your windows guys configure AD as needed, usually Microsoft Services for UNIX , msSFU, or the Identity Management for UNIX Role Service.

Non RHEL Guide

LINUX to Windows 2k8R2 Part 1

Thanks Todd for all the links - I will speak with our windows guys and make sure all the needed tools are installed.

Thanks again :-)