Welcome,
Iniciar sesión en su cuenta de Red Hat
Con su cuenta de Red Hat puede acceder a su perfil de miembro y sus preferencias, además de a los siguientes servicios teniendo en cuenta su estado de cliente:
- Portal de clientes
- Red Hat Connect para partners empresariales
- Gestión de usuarios
- Central de certificación
¿Aún no se ha registrado? Le ofrecemos varios motivos por los que debería hacerlo:
- Consulte artículos de la base de conocimiento, gestione casos de soporte y suscripciones, descargue actualizaciones y mucho más desde una misma ubicación.
- Consulte los usuarios de la organización, y edite la información, preferencias y permisos de sus cuentas.
- Gestione sus certificaciones de Red Hat, consulte el historial de exámenes y descargue logotipos y documentos relacionados con las certificaciones.
Con su cuenta de Red Hat puede acceder a su perfil de miembro, sus preferencias y otros servicios dependiendo de su estado de cliente.
Por seguridad, si está en un equipo de acceso público y ya ha terminado de utilizar los servicios de Red Hat, cierre sesión.
Cerrar sesiónBlog de Red Hat
Blog menu
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.