Active Directory and Identity Management (IdM) Trusts – Exactly Where Are My Users?

As this is my sixth post on Identity Management I thought it would (first) be wise to explain (and link back to) my previous efforts.  My first post kicked off the series by outlining challenges associated with interoperability in the modern enterprise.  My second post explored  how the integration gap between Linux systems and Active Directory emerged, how it was formerly addressed, and what options are available now.  My third post outlined the set of criteria with which one is able to examine various integration options.  And my most recent entries, post four and five, reviewed options for direct and indirect integration, respectively.

Delving deeper into the world of indirect integration (i.e. utilizing a trust-based approach) – two of the biggest questions are often: “Where are my users?” and “Where does authentication actually happen?” As opposed to a solution that relies upon synchronization, authentication, in the trust-based approach, actually happens wherever the user entry and his or her respective password are stored. If the AD user is authenticating (regardless which resource he or she is accessing) they will be authenticated by the AD domain that they belong to. This is accomplished by the client software (e.g. SSSD) being intelligent enough to realize that the user is stored in AD – while the system (itself) may be a member server of IdM. In this scenario, SSSD will interact with AD directly to perform user authentication.

One of the only caveats is that IdM has to deal with old Linux and UNIX systems that (often times) do not have latest version of SSSD. To address the needs of the Linux and UNIX legacy clients IdM acts as a proxy server by caching identity data. In fact, IdM uses SSSD on the server in a special configuration to collect information from AD and perform authentication – exposing data in a so-called compatibility tree.

IdM

To learn more about what’s going on “under the hood” – FreeIPA hosts an information slide deck here.

Finally, it’s worth noting that the above mentioned functionality is a part of IdM and is available today as a part of Red Hat Enterprise Linux 7.  For additional information you can review the available documentation in the Red Hat Customer Portal.

  1. Mr. Pal; Great series of articles. I am a Linux Engineer working on a project in which the general direction is toward an enterprise AD system. I am in favor of using the most effective solution. I’m thinking that with our use of some older machines (RHEL5) and the fact that we have a dedicated Unix/Linux team that IdM would be a good solution for us rather than a direct AD approach. Could you possibly provide a little more of a head-to-head of the Direct to AD solution versus an IdM + AD solution? Also, would Solaris clients incorporate well into a RHEL-based IdM domain? Thanks in advance! -L.Kimmel

      1. Yes, that does add a little fidelity. I am still somewhat unclear about policy centralization using the direct method. Your article “Overview of Direct Integration Options” seems to say that this is done with 3rd party options (not ideal) and the “contemporary (SSSD)” option. However, the SSSD illustration seems to say that the policy is managed by some tool such as Puppet whereas the summary table simply says “yes” for whether this option allows for policy management via AD/GPO. Does SSSD allow policy management in AD via GPO? If so is it rather complicated as compared to IdM. I assume it’s even more complicated for older systems (RHEL5 and older)?

        Thanks again,
        -L.Kimmel

      2. Hello,

        SSSD supports basic host based access control via AD GPO policies. Also SSSD can potentially read SUDO rules from your AD if you decide to load and manage them there though this crosses into uncharted territory a bit. People have done this but it is not “officially” supported configuration. The rest of policies need to be applied via other means. With IdM you have all of them in one place as shown on the slides.

        Thanks
        Dmitri

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