Solución 1:
En marzo de 2014, Red Hat publicó una arquitectura de referencia para integrar Red Hat Enterprise Server con Active Directory. (Este material ciertamente debe ser actual y relevante). Odio publicar esto como una respuesta, pero en realidad es demasiado material para transferirlo al campo de respuesta.
Este documento (corregido) recién salido de la imprenta parece centrarse en las nuevas funciones de Red Hat Enterprise Linux (RHEL) 7. Se publicó para la cumbre la semana pasada.
Si este enlace se vuelve obsoleto, házmelo saber y actualizaré la respuesta en consecuencia.
Personalmente, he usado WinBind de manera bastante confiable para la autenticación. Hay fallas de servicio muy poco frecuentes que requieren que alguien con una cuenta raíz u otra cuenta local ingrese y rebote winbindd. Esto probablemente podría solucionarse a través de un control adecuado si se esfuerza en ello.
Vale la pena señalar que Centrify tiene una funcionalidad adicional, aunque esto puede proporcionarse mediante una administración de configuración separada. (Títeres, etc.)
Editar 16/6/14:
Guía de integración de Red Hat Enterprise Linux 7 Windows
Solución 2:
re:"Las soluciones comerciales como Centrify y Similar siempre funcionaron, pero parecían innecesarias, ya que esta capacidad está integrada en el sistema operativo".
Bueno, creo que la mayoría de nosotros hemos escuchado durante años que el sistema operativo XYZ finalmente resuelve el rompecabezas de integración de AD. En mi humilde opinión, el problema es que para el proveedor del sistema operativo, la integración de AD es una función de casilla de verificación, es decir, necesitan entregar algo que funcione para obtener esa casilla de verificación, y esa casilla de verificación generalmente solo funciona en...
- su plataforma OS y
- la versión actual de esa plataforma y
- contra una versión más reciente de Active Directory.
La realidad es que la mayoría de los entornos no son monolíticos en términos de proveedor de SO y versión de SO, y tendrán versiones anteriores de AD. Es por eso que un proveedor como Centrify debe admitir más de 450 versiones de UNIX/Linux/Mac/etc. contra Windows 2000 a Windows 2012 R2, no solo RHEL 7 contra Windows 2012 R2.
Además, debe tener en cuenta cómo se implementa su AD, al igual que la integración de AD del proveedor del sistema operativo que admite controladores de dominio de solo lectura (RODC), confianzas unidireccionales, proporciona compatibilidad con varios bosques, etc. espacio de UID existente (que lo hará), existen herramientas de migración para migrar los UID a AD. ¿Y el soporte de AD del proveedor del sistema operativo aborda la capacidad de asignar múltiples UID a un solo AD en situaciones en las que su espacio de UID no es plano? Y qué tal... bueno, ya te haces una idea.
Luego está la cuestión del apoyo...
El punto es que la integración de AD puede parecer fácil conceptualmente y puede ser "gratuita" con el sistema operativo más reciente de un proveedor, y probablemente funcione si solo tiene una versión de un sistema operativo de un proveedor y tiene un AD estándar que es la última versión, y tiene un contrato de soporte premium con el proveedor del sistema operativo que hará todo lo posible para solucionar cualquier problema que surja. De lo contrario, es posible que desee considerar una solución especializada de terceros.
Solución 3:
La opción Servidor para herramientas de servicio de información de red (NIS) de Herramientas de administración de servidor remoto (RSAT) está obsoleta.
Esto no me sorprende:NIS es evidencia de que Sun nos odiaba y quería que fuéramos miserables.
Utilice opciones nativas de LDAP, Samba Client, Kerberos o que no sean de Microsoft.
Este es un buen consejo. Dadas las opciones, diría "Usar LDAP nativo (sobre SSL, por favor)" - hay muchas opciones disponibles para esto, las dos con las que estoy más familiarizado son pam_ldap + nss_ldap (de PADL), o la combinación nss-pam- ldapd (que se originó como una bifurcación y ha experimentado un desarrollo y mejoras continuos).
Dado que está preguntando específicamente sobre RedHat, vale la pena señalar que RedHat le brinda otras alternativas usando SSSD.
Si su entorno es totalmente RedHat (o simplemente tiene una gran cantidad de sistemas RedHat), definitivamente valdría la pena investigar la "Forma de hacer las cosas de RedHat" con soporte oficial.
Como no tengo experiencia con RedHat/SSSD, solo me baso en los documentos, pero parece bastante robusto y bien diseñado.
Solución 4:
De los métodos sugeridos, déjame darte una lista de pros y contras:
Directo a Kerberos/LDAP
Pros:Funciona muy bien cuando se configura correctamente. Rara vez se rompe, resistente, sobrevivirá a fallas en la red. No se necesitan cambios en AD, no hay cambio de esquema, no se necesita acceso de administrador a AD. Gratis.
Contras:Relativamente difícil de configurar. Es necesario cambiar varios archivos. No funcionará si el servidor de autenticación (Kerberos/LDAP) no está disponible.
Winbind
Ventajas:Fácil de configurar. Funcionalidad básica de sudo. Gratis.
Desventajas:Apoyo intensivo. No resistente a la red. Si hay un problema de red, las máquinas Linux podrían quedar fuera del AD y requerir volver a registrar el servidor, una tarea de soporte. Se requiere acceso a la cuenta de administrador de AD. Podría necesitar hacer cambios de esquema en AD.
Centrificar/Del mismo modo, etc.
Pros:Relativamente fácil de configurar.
Contras:Cambia la funcionalidad sudo a propietaria, más difícil de soportar. Costo de licencia por servidor. Necesita habilidades adicionales para administrar.
SSSD
Pros:un archivo de configuración, fácil de configurar. Funciona con todos los métodos de autenticación presentes y futuros. Escalable, crece con el sistema. Funcionará en modo desconectado. Resistente a la red. No es necesario realizar ningún cambio en el esquema de AD. No se necesitan credenciales de administrador de AD. Gratis, compatible.
Contras:no tiene servicios de ganar como actualizaciones automáticas de DNS. Necesidad de configurar recursos compartidos CIFS.
Resumen
En cuanto a las ventajas y desventajas, SSSD es el claro ganador. Si se trata de un sistema nuevo, no hay motivo para utilizar otro que no sea SSSD. Es un integrador que funciona con todos los métodos de autenticación actuales y puede crecer con el sistema porque se pueden agregar nuevos métodos cuando estén disponibles. Utiliza métodos nativos de Linux y es mucho más confiable y rápido. Si el almacenamiento en caché está activado, los sistemas funcionarán incluso en sistemas completamente desconectados con una falla total de la red.
Winbind se puede usar para sistemas existentes si hay demasiado trabajo involucrado para cambiar.
Centrify ha tenido problemas con la integración que podrían resultar costosos. La mayoría de los errores se corrigieron en la nueva versión, pero todavía hay algunos que causan dolores de cabeza.
He trabajado con todos estos métodos y SSSD es el claro ganador. Incluso para los sistemas más antiguos, el ROI de la conversión de Winbind a SSSD es muy alto. A menos que haya una razón específica para no usar SSSD, use siempre SSSD.
Solución 5:
Tengo que comentar sobre esto:
Vale la pena señalar que Centrify tiene una funcionalidad adicional, aunque esto puede proporcionarse mediante una administración de configuración separada. (Marioneta, etc.)
Como alguien que trabaja con Centrify, no estoy seguro de dónde proviene ese comentario. Mire esto y podrá ver que hay un montón de funciones que no obtiene con una herramienta de gestión de configuración como Puppet. Por ejemplo, soporte para el mapeo de múltiples UID a una sola cuenta de AD (Zonas), soporte para confianzas completas de dominio de Active Directory (que la solución de Red Hat documenta en la página 3 que no es compatible), etc.
Pero volvamos a esta guía de Red Hat. Es genial que Red Hat esté publicando esto, las opciones son buenas. Tenga en cuenta que le da al cliente 10 opciones para realizar una integración básica de AD. La mayoría de las opciones son variaciones de Winbind, y la página 15 enumera las ventajas y desventajas de cada una, y hay un montón de pasos manuales necesarios para cada una (con las correspondientes desventajas/falta de funcionalidad según lo anterior). La ventaja de Centrify Express es que según los otros comentaristas anteriores es:
- es fácil de instalar sin todos los pasos manuales y...
- es gratis y...
- no se limita a Red Hat V7, lo cual es importante ya que la pregunta tenía que ver con Linux, no solo con una variante:Centrify admite más de 300 variantes de *nix y...
- admite todas las variantes de Windows AD, no solo Windows 2008. Publicaron una comparación de Centrify vs. Winbind aquí, pero no es de código abierto.
Al final, todo se reduce a si desea enrollarlo usted mismo o optar por una solución comercial. Realmente es una cuestión de dónde y cómo pasas tu tiempo.