Your Red Hat account gives you access to your member profile and preferences, and the following services based on your customer status:
Not registered yet? Here are a few reasons why you should be:
- Browse Knowledgebase articles, manage support cases and subscriptions, download updates, and more from one place.
- View users in your organization, and edit their account information, preferences, and permissions.
- Manage your Red Hat certifications, view exam history, and download certification-related logos and documents.
Your Red Hat account gives you access to your member profile, preferences, and other services depending on your customer status.
For your security, if you're on a public computer and have finished using your Red Hat services, please be sure to log out.Log out
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.
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.