Who Goes There? Identity Management in Red Hat Enterprise Linux 7 Beta

It seems that the daily news is full of the fallout that results when companies fail to protect online identities. The ability to limit access to sensitive applications and information to the right people with the right credentials is critical to ensuring the overall security of your infrastructure; critical… but not always easy.

Until recently, options for centralized identity management for the Linux environment were limited. There was no turnkey domain controller-like solution for the Linux/UNIX environment. Some Linux shops integrated open source tools like Kerberos and DNS to create centralized Linux-based identity management, but this option could be time-consuming to develop and expensive to maintain. Others integrated Linux clients directly into Microsoft Active Directory, but this option limited their ability to take advantage of some useful native Linux functionality like sudo and automount.

Identity Management in Red Hat Enterprise Linux

Since the 6.4 release, Red Hat Enterprise Linux has included the Identity Management (IdM) feature set to provide a centralized and clear way to manage identities for users, machines, and services within large Linux/Unix enterprise environments. In addition, Identity Management provides a way to define access control policies to govern those identities. Identity Management, based on work done in the upstream open source community FreeIPA, provides a unifying skin for standards-defined, common network services, including PAM, LDAP, Kerberos, DNS, NTP, and certificate services. This allows Red Hat Enterprise Linux systems to serve as domain controllers in Linux environments. Because Identity Management is an integrated feature of Red Hat Enterprise Linux, it is easy and cost-effective to introduce identity and policy management wherever it’s needed.

What’s new in the beta of Red Hat Enterprise Linux 7?

Active Directory / Identity Management Integration

For many organizations, Active Directory (AD) is the central hub for the user identity management inside the enterprise. Yet it is often the case that all systems that AD users can access (including Linux) need access to AD to perform authentication and identity lookups.

Identity Management in the Red Hat Enterprise Linux 7 beta provides two paths to integrate Linux systems into the Active Directory environment:

  • Direct Integration – Linux systems can be connected to Active Directory directly by configuring a component called SSSD. This component acts as an identity and authentication gateway into a central identity store. SSSD can be easily configured using a new component called realmd. Realmd detects an available domain based on the DNS records and configures SSSD to interact with the right identity source. Realmd can connect the Linux system to either IdM or AD as shown below. Once the system is joined into the domain users managed by this domain can access the joined systems. They can authenticate and their POSIX attributes as well as group membership will be recognized by the Linux system. The SSSD in this setup replaces the formerly used winbind component. Note, however, that if you plan to use CIFS file sharing on Linux systems, you need to configure winbind following existing reference architecture materials.


  • Indirect Integration – Direct integration is limited to using only the authentication and identity information related to users. Systems do not get policies and data, which limits their identity and access control potential in the enterprise environment. Linux systems can get policies like sudo, host-based access control rules, automount, netgroups, SELinux user mappings and other capabilities from a central identity management server. The identity management server provides centralized management of Linux systems giving them identity, credentials and providing centrally managed policies for the Linux features listed above. In most environments, users that are stored and authenticated by Active Directory need to have access to Linux resources. That can be accomplished by establishing a trust relationship between the identity management server and Active Directory. This diagram below shows how users from an Active Directory forest gain access to the Linux systems joined into the identity management (IdM) domain.


Other New Features

Identity Management in the Red Hat Enterprise Linux 7 beta delivers other new features for both the SSSD (client) and Identity Management Server that make identity management in Red Hat Enterprise Linux more functional and easier to manage, including support of domain trusts, UI improvements, and a prototype back-up and restore procedure.

For those with existing subscriptions or who have already downloaded Red Hat Enterprise Linux 7 beta, the identity management team invites you to try out the direct and indirect paths to Active Directory integration and any of the other new client or server capabilities. Please leave me feedback in the comments below – I look forward to hearing from you!

  1. i love ipa guys. They listen same music as i can’t live without as. They do things as i expected they will. Their projects and kids working for us without any questions.. So i’m awaiting the day when they will publish third part of freeipa….. the AUDIT.

  2. You are right that audit is a critical pillar of security. However, audit has much wider application across the enterprise than just identity and access control features. We think of audit as a separate component from freeIPA, one that freeIPA should take advantage of, but not one that freeIPA should develop in isolation. There are several audit choices, both open source and proprietary, that can be used to support the audit and compliance needs of the organization as whole. We concentrate on identity and access control in freeIPA.

  3. I agree with both of you. Until IPA has the functionality to audit in a respectable way we will not be able to use this technology effectively within a PCI environment. The IPA team is great, so I hope they add the functionality in there soon.

  4. HI, after we integrated sssd with AD server (e.g. Win2008) the getapt password can not read out the users/groups of the AD server, one workaround is to add a enumerate=true into the sssd.conf manually, how to let realm configure it automatically or is there any other workaround to resolve this? thanks a lot

    1. Hi Ajax – thank you for your feedback. We are not 100% sure what you mean by “getapt password”. Perhaps you could explain / expand upon your situation and use case? Note: you can always file a support ticket if your SSSD is running on Red Hat Enterprise Linux or ask a question on the sssd-users@lists.fedorahosted.org list. All that being said, as we are not 100% sure what you mean, we can only speculate… To prevent performance problems, SSSD (by default) does not pull all of the data from the central source using a lot of heuristics. In fact, we do not recommend turning on enumeration by default unless there is some application that relies on enumerating users that never logged into the system to make some decision. This is a very rare case. If you mean “getent passwd” it in fact returns only local users (at least for me) if your NSS configuration is passwd: files sss. Out of curiosity, why do you need
      it other than for testing that SSSD works?

      1. hi Dan, thank you for your reply.
        yes, i meant getent passwd indeed.
        we have tested the sssd works with realmd by default configurations. however our application needs 1)list out all users and groups from AD domain for admin purpose 2) need to point a default domain controller for Sssd, and want all these can be enabled or activated dynamicly e.g. by a script invoke through realm command. is there any way to overwrite or add more sssd configuration parameters to reach this?

      2. Hi Ajax, if you prefer to have all data delivered to the system you can enable enumeration. That said, this is not recommended due to performance implications on the server, client, and network so we suggest that you carefully evaluate the reasons for why it may be needed. For most cases, in our experience, it is an artificial requirement. The man pages for sssd.conf explain how to turn on enumeration.

        Regarding your application’s second need – realmd does not modify sssd.conf directly. You have different options on how to modify the file after reamld does its part. You can script it with basic shell tools and Augeas or use Puppet/Satellite to deliver the configuration file you need. The ability to fine tune sssd.conf via command line tools is in works with no firm delivery time set yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s