¿Cuál es el sentido común en 2014 acerca de la autenticación de Active Directory / integración de servidores Linux y modernos sistemas operativos de Windows Server (CentOS / RHEL-enfocaron)?
En los años transcurridos desde mis primeros intentos de integración en 2004, parece que las mejores prácticas en torno a esto han cambiado. No estoy muy seguro de qué método tiene actualmente el mayor impulso.
En el campo, he visto:
Winbind / Samba
recta de LDAP
veces LDAP Kerberos +
Servicios de Microsoft Windows para Unix (SFU)
Microsoft Identity Management for UNIX
NSLCD
SSSD
FreeIPA
Centrify
powerbroker ( de soltera Del mismo modo )
Winbind siempre parecía terrible y poco confiable. Las soluciones comerciales como Centrify y Likewise siempre funcionaron, pero parecían innecesarias, ya que esta capacidad está integrada en el sistema operativo.
En las últimas instalaciones que realicé, se agregó la función Microsoft Identity Management para Unix a un servidor Windows 2008 R2 y NSLCD en el lado de Linux (para RHEL5). Esto funcionó hasta RHEL6, donde la falta de mantenimiento en NSLCD y problemas de administración de recursos de memoria forzaron un cambio a SSSD. Red Hat también parecía respaldar el enfoque SSSD, por lo que ha estado bien para mi uso.
Estoy trabajando con una nueva instalación donde los controladores de dominio son sistemas principales de Windows 2008 R2 y no tienen la capacidad de agregar la función de gestión de identidad para Unix. Y me dijeron que esta característica está en desuso ya no está presente en Windows Server 2012 R2 .
El beneficio de tener esta función instalada es la presencia de esta GUI, mientras que permite una fácil administración en un solo paso de los atributos del usuario.
Pero...
La opción de Herramientas de servidor para el Servicio de información de red (NIS) de Herramientas de administración remota del servidor (RSAT) está en desuso. Utilice opciones nativas de LDAP, Samba Client, Kerberos o que no sean Microsoft.
Eso hace que sea realmente difícil confiar si puede romper la compatibilidad hacia adelante. El cliente quiere usar Winbind, pero todo lo que veo desde el lado de Red Hat apunta al uso de SSSD.
¿Cuál es el enfoque correcto?
¿Cómo manejas esto en tu entorno?
fuente
Respuestas:
En marzo de 2014, Red Hat publicó una arquitectura de referencia para integrar Red Hat Enterprise Server con Active Directory . (Este material debe ser actual y relevante). Odio publicar esto como respuesta, pero en realidad es demasiado material para transferir al campo de respuesta.
Este documento (corregido) acaba de publicarse, parece centrarse en las nuevas características de Red Hat Enterprise Linux (RHEL) 7. Fue publicado para la Cumbre la semana pasada.
En caso de que este enlace se vuelva obsoleto, avíseme y actualizaré la respuesta en consecuencia.
Personalmente he usado WinBind de manera bastante confiable para la autenticación. Hay una falla de servicio muy infrecuente que requiere que alguien con root u otra cuenta local entre y devuelva winbindd. Esto probablemente podría tratarse a través de un monitoreo adecuado si desea poner el esfuerzo en ello.
Vale la pena señalar que Centrify tiene una funcionalidad adicional, aunque esto puede ser proporcionado por una administración de configuración separada. (Marioneta, etc.)
Editar 16/6/14:
Red Hat Enterprise Linux 7 Guía de integración de Windows
fuente
Bueno, creo que la mayoría de nosotros hemos escuchado durante años que el sistema operativo XYZ finalmente resuelve el rompecabezas de la 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 ...
La realidad es que la mayoría de los entornos no son monolíticos en términos de proveedor y versión del sistema operativo, 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 nuevamente a Windows 2012 R2.
Además, debe tener en cuenta cómo se implementa su AD, por lo que la integración de AD del proveedor del sistema operativo admite controladores de dominio de solo lectura (RODC), fideicomisos unidireccionales, proporciona soporte de bosques múltiples, etc. Y qué pasa si tiene espacio UID existente (que lo hará), ¿hay 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é hay de ... bueno, ya tienes la 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 último sistema operativo de un proveedor, y probablemente pueda funcionar si solo tiene una versión de un sistema operativo de un proveedor y tiene un AD de vainilla 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 de terceros especializada.
fuente
Esto no me sorprende: NIS es evidencia de que Sun nos odiaba y quería que seamos miserables.
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 visto mejoras y desarrollo continuos).
Dado que está preguntando sobre RedHat específicamente, vale la pena señalar que RedHat le ofrece otras alternativas utilizando SSSD.
Si su entorno es todo RedHat (o simplemente tiene una gran cantidad de sistemas RedHat), valdría la pena ver la "Forma de hacer las cosas" de RedHat, oficialmente respaldada.
Como no tengo experiencia con RedHat / SSSD, solo estoy siguiendo los documentos, pero parece ser bastante robusto y bien diseñado.
fuente
De los métodos sugeridos, déjame darte una lista de pros / contras:
Directamente Kerberos / LDAP
Pros: Funciona muy bien cuando se configura correctamente. Raramente se rompe, es resistente y sobrevivirá a fallas en la red. No se necesitan cambios en AD, no hay cambio de esquema, no se necesita acceso de administrador al AD. Gratis.
Contras: Relativamente difícil de configurar. Se deben cambiar varios archivos. No funcionará si el servidor de autenticación (Kerberos / LDAP) no está disponible.
Winbind
Pros: fácil de configurar. Funcionalidad básica de sudo. Gratis.
Contras: Apoyo intensivo. No es resistente a la red. Si hay un problema de red, las máquinas Linux pueden quedar fuera de la AD requiriendo volver a registrar el servidor, una tarea de soporte. Se requiere acceso a la cuenta de administrador de AD. Podría hacer cambios de esquema en AD.
Centrificar / Del mismo modo, etc.
Pros: Relativamente fácil de configurar.
Contras: Cambia la funcionalidad de 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. Red resistente. No es necesario realizar ningún cambio en el esquema de AD. No es necesario tener credenciales de administrador de AD. Gratis, compatible.
Contras: No tiene servicios ganadores como actualizaciones automáticas de DNS. Necesita configurar recursos compartidos CIFS.
Resumen
En cuanto a las ventajas y desventajas, SSSD es el claro ganador. Si es un sistema nuevo, no hay razón para usar otra cosa 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 falla total de la red.
Winbind puede usarse para sistemas existentes si hay demasiado trabajo involucrado para cambiar.
Centrify ha tenido problemas con la integración que podrían ser 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 sistemas más antiguos, el ROI para convertir de Winbind a SSSD es muy alto. A menos que haya una razón específica para no usar SSSD, siempre use SSSD.
fuente
Tengo que comentar sobre esto:
Como alguien que trabaja con Centrify, no estoy seguro de dónde proviene ese comentario. Mire esto y puede ver que hay una gran cantidad de características que no obtiene con una herramienta de administración de configuración ala Puppet. Por ejemplo, soporte para la asignación de múltiples UID a una sola cuenta de AD (Zonas), soporte para dominios de Active Directory completos (que la solución de Red Hat documenta en la página 3 que no admite), 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 hacer 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 desventajas / falta de funcionalidad correspondientes según lo anterior). La ventaja de Centrify Express es que, según los otros comentaristas anteriores, es:
Al final, todo se reduce a si desea rodarlo usted mismo o ir con una solución comercial. Realmente es un asunto dónde y cómo pasas tu tiempo.
fuente