Overview of Indirect Active Directory Integration Using Identity Management (IdM)

The main alternative to direct integration of Linux/UNIX systems into Active Directory (AD) environments is the indirect approach – where Linux systems are first connected to a central server and this server is then somehow connected to AD. This approach is not new. Over the years many environments have deployed LDAP servers to manage their Linux/UNIX systems (using this LDAP server) while users were stored in AD. To reconcile this issue and to enable users from AD to access Linux systems – users and their passwords were routinely synchronized from AD. While this approach is viable – it’s also quite limited and prone to error. In addition, there is little value in having a separate LDAP server. The only reason for such a setup is to have a separation of duties between Linux and Windows administrators. The net result is that the overhead is quite high while the value of such an approach is quite low.

When IdM (Identity Management in Red Hat Enterprise Linux based on FreeIPA technology) emerged, many environments were either considering direct integration or were “in-process” with respect to adoption. How, exactly, does IdM work? IdM provides a domain controller for Linux & UNIX that is similar to AD but speaks in the native protocols and exposes the native objects that Linux and UNIX clients expect. Native protocols in conjunction with the central management of policies like host based access control, sudo, auto mount or SELinux user mappings and Kerberos based enterprise SSO make IdM a very attractive option for central management of a Linux environment. The only (remaining) drawback is the need to sync users from AD to IdM in order for AD users to access resources in IdM domain.

With introduction of FreeIPA 3.3 in Red Hat Enterprise Linux 7 the preferred way of integrating IdM with AD becomes cross forest Kerberos trusts. With trusts, users authenticate in their home AD domain and use Kerberos tickets as proof of authentication to access the systems and services in the trusted IdM domain. There is no password or user account synchronization. The Kerberos ticket exchanges are completed following the standard Kerberos protocol in the same way exchanges are completed between AD forests. IdM has thus eliminated all the negative aspects of indirect integration leaving only benefits, namely:

  • Linux clients are centrally managed. The authentication, identity, and policy management happens on a central server – often accomplishing a compliance goal.
  • Linux clients are managed via native Linux protocols and via traditional Linux/UNIX means (LDAP, Kerberos, POSIX) – fostering improved interoperability.
  • The authentication of AD users happens in AD – helping organizations meet audit requirements.
  • Management of the Linux systems can be easily delegated to Linux administrators. A clear separation of duties and delegation of privileges between different functions can be accomplished with ease. Each group has control over its part of the infrastructure reducing the time (and cost) that is usually associated with the need for coordination between AD and Linux groups within the same company.
  • Linux environments can organically grow to address business needs of the enterprise without necessarily generating additional cost.
  • There is no need for user and/or password synchronization.

The above listed benefits are significant in cases where a company deploying a solution has a dedicated Linux management group. This is usually the case with big enterprises. In smaller environments, where there may be no such group, running a separate server might be overhead so starting with direct integration using SSSD or even employing a third party solution (if advanced functionality is a requirement), is definitely an option.

If you are testing waters with Linux, starting small with direct integration is the way to go. However, as your environment grows and as requirements become more (and more) complex… deploying IdM as a central administration hub for your Linux based infrastructure may be worth your consideration.  As always, if you have questions or comments – I encourage you to use the comments section (below).  Also, stay tuned for my next post where I will talk about trusts in greater detail.

  1. I enjoyed this series, it have a good overview of the different options out there, most of which I had discovered myself while researching the topic. The only disadvantage I would suggest you get with Trusts, is that Linux and Windows servers need to be in separate domains. Either at the same level, or with one being a subdomain of the other.

    A question I would pose is: is there any clearly defined migration path from direct integration to indirect (or viceversa), and from these two to a cross forest trust setup?

    Thank you.

    1. Hello Eric,

      The official Red Hat documentation is in works but here is a pointer to the community page that has the core of the information you are looking for [1].

      But there are different paths:
      – From IdM with sync to IdM with trust
      – From LDAP to IdM
      – From NIS to IdM
      Those are documented or have guidelines and tools.
      – From IdM to direct – this is a redeployment of the clients so there is really no migration possible.

      What are other scenarios that you are interested in?


      [1] http://www.freeipa.org/page/V4/Migrating_existing_environments_to_Trust

      1. Hello Dimirti,

        Thanks for this great article, is there any way to use a idM server on the same domin without the need to create a subdomin ar different domain for the Linux hosts to use the same DNS zone as the maim AD uses?

        Best regards

      2. Hello, Rolland

        Thanks for the comment.
        Currently it is not possible but I suspect what you actually asking is: Is there any way to avoid moving my Linux clients from the DNS domain they are already in, which is the AD domain, if I want to implement IdM with AD trust.
        The answer to that question is: It is not possible in the current shipping versions but we are working on a solution that might become available later this year. In the solution the IdM server will still be in a different domain but clients would be configured in such a way that they will know how to talk to IdM servers and AD servers being members of the IdM domain while still having AD DNS name.

        Thank you,

  2. Dmitri

    Can you provide a bit more detail about the solution in question – what versions of IdM (or FreeIPA) it is expected in and where one can find more details of what it will look like?

    1. Hello,

      The solution in question – IdM is available as a part of Red Hat Enterprise Linux without extra charge. It piloted in Red Hat Enterprise Linux 6.4 as a tech preview and then became fully supported as part of 7.0. Current shipping version is 7.2 and we are working on 7.3. There are couple articles further in this blog that cover new features of 7.1 and 7.2 releases. So to start you just need to install packages and run the installation script. Please see https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide for more details.

      Thank you,

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s