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:
¿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ón
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.