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,

  3. Hi Dimitri,

    Loved your series of interoperability challenges. Could you please provide bit more detail on differences between “Direct Integration with AD” and “Indirect Integration with AD using IDM” approach.

    Advantage that I can see of “indirect integration” over “direct” approach is only centralized management of policies ( sudo and selinux ). Now it seems like, sudo policies can be managed centrally through AD. And if we are thinking of not using selinux much, only few changes with selinux, is there other advantages of “indirect” approach?

    Thank you

    1. Hello,

      Well sudo can be managed in AD but SSSD does not support that option from AD. You can use it directly from sudo via LDAP but then you do not get advantages of the SSSD caching and you would need to distribute and maintain local files for the fail-over. But setting selinux and sudo aside here are several other things you need to keep in mind:
      – Where do you manage you POSIX attributes? Do you want to do it in AD? What tools you are going to use for that? The MMC console to do that was deprecated. There are some web tools that you can tune up. It is yet unclear if this will be sufficient.
      – Managing host based access control is much easier with indirect integration
      – If you have systems that need SSH keys, automount and netgroups – these objects can be provided by IdM and have simple means to manage
      – IdM provides PKI infra that you can use for your Linux systems and applications. It can be a stand alone CA or a sub-CA. It now supports virtual sub-CAs for different namespaces
      – IdM can federate several forests, direct integration with SSSD does not allow multiple forests, you can use winbind but then you hit other limitations.
      – IdM has a vault that can be used as a keystore for your keys and secrets
      – Client side components like sssd, certmonger, custodia (in works) integrate with IdM to deliver automation with enrollment and provisioning of new Linux systems
      Besides technical there are organizational benefits. I have later blogs about that. Please check them out.


  4. Hi Dmitri. I’ve read this series, and i’ve also watched a video lecture that you gave. it was very informative. I am using IPA 4.4.0 and I am trying to trust a newly created 2012 AD. Our purpose is to provide freeipa user access to windows resources, such as remote desktop connection. (i.e. RDP with your freeipa username and password) It appears as though the documentation as well as these posts are geared toward using AD as the central repository for IDM, and integrating freeipa into that. We would like to go in reverse as our windows foot print is very small and Linux is quite large. Is it possible to use freeipa as the central IDM and have a small deployment of windows 2012 AD in which the majority of users only live in freeipa? I hope this was clear.

    1. Hello,

      Yes it is clear. Unfortunately it is not possible yet. For this to be possible IdM needs to implement a service called Global Catalog. It is on the roadmap but not complete yet. You can follow the evolution and progress using freeipa.org and https://pagure.io/freeipa/issue/3125, if you want to contribute you are welcome to join the community and participate in the effort.


  5. Hello Dmitri, I am having a hard time understanding how can I manage my local Unix users/accounts with IDM. I have a test IDM server and couple of clients ( All RHEL 7.4 and 6.9 servers ). For now, we are managing those user’s password etc. locally ( we do not have AD ). Now, let’s say I want to manage these users/accounts from my IDM server so that when I change a user’s password on IDM server, it gets replicated to all of the client servers ( all clients are RHEL 6.9 and RHEL 7.4 servers ). How can I achieve this? I mean how can I integrate these existing users on all of my Unix machines with IDM so that I do not have to go on each machine and change password from there? Thank you.

    1. Hello,

      1. Install IdM (https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/installing-ipa)
      2. Install client side components and join client systems to IdM using ipa-client-install or realmd on 7.x (https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/setting-up-clients).
      3. Create a user account, set its password
      4. Login on the joined clients with this account
      5. Change password, log on a different joined client to see that it a new password is in play.

      The client side component that talks to IdM server is SSSD.
      When you use IdM you _stop_using local accounts. You move them to IdM so you will need to remove accounts that you currently manage locally and have them in IdM. SSSD will pull them down and expose these accounts to to all the components that use user accounts on a system. For applications it is a transparent change. You do not need to do anything specific here.


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