Búsqueda de una verdadera integración de Active Directory

Búsqueda de una verdadera integración de Active Directory

Antes de que te rías de mí y digas: "Si quieres Active Directory, usa Windows" o me digas que use Google, escúchame.

Mi empresa depende en gran medida de AD. No, estamos casados ​​con eso en este momento y, como empresa Fortune 10, eso no va a cambiar. Sin embargo, tenemos muchos sistemas *nix en nuestro entorno (principalmente RHEL y SLES) y todavía tengo que encontrar un buen mecanismo para integrarlo con Active Directory como fuente de identidad. Como mínimo, necesito algo que proporcione lo siguiente:

  1. Autenticación a través de credenciales AD (permitir que un usuario entre por la puerta)
  2. Autorización una vez autenticado (otorgar a un usuario acceso a áreas del sistema)
  3. Auditoría (poder vincular las acciones de los usuarios con sus credenciales de AD)
  4. Soporte para grupos AD (no solo LDAP básico y tener que agregar/eliminar usuarios individuales en los sistemas)
  5. No es una fuente de identidad duplicada/reflejada basada en la confianza de AD (no necesito dos sistemas enormes)

Las principales soluciones que he encontrado son las siguientes:

  1. Centrificar
  2. PowerBroker Open (PBIS Open, anteriormente Same-Open)
  3. SSSD+SELinux

Centrificar. . . es simplemente feo. Nunca he sido un verdadero fan. Además, para las necesidades de mi empresa, no podemos usar Centrify-Express, por lo que no es gratuito y no hay una licencia ilimitada. Sin embargo, es la mejor solución que hemos encontrado y estoy desesperado por encontrar algo más.

PBIS Open es hacia lo que me inclino. Es lo que usa VMware en el backend de vShield y funciona bastante bien. Solo requiere unos pocos comandos para configurarse, admite grupos de AD y no hay un sistema de administración de identidad secundario: se comunica directamente con AD. La única razón por la que no sigo ese camino es que me gustan las soluciones nativas, y si hay una mejor manera de hacerlo que ya esté incluida en las distribuciones modernas, estoy totalmente a favor.

SSSD+SELinux sonaba genial. Es complicado de configurar, pero es flexible, nativo y compatible con la mayoría de las distribuciones modernas. Lo único que le falta (según tengo entendido) es soporte para grupos de AD. Muchos artículos sugieren aprovechar FreeIPA o algo similar para agregar esta funcionalidad, pero al leer más, esto viola el requisito 5 y básicamente crea un servicio de identidad de intermediario. Básicamente, no estoy interesado en duplicar AD o establecer confianza en un servicio de identidad secundario.

Otras opciones de error que he descartado incluyen el uso de Puppet (que usamos) para enviar archivos /etc/password,shadow,group a los puntos finales, pero eso requiere desarrollo, es increíblemente indirecto y pude ver que algo va mal. Una mejor opción sería agregar SSSD+SELinux a la idea de Puppet. Si bien simplificaría el desastre, sigue siendo un desastre.

¿Qué me falta, qué estás usando y cuál es el "nuevo atractivo" que no he tenido en cuenta para resolver el dolor de cabeza de la integración de Linux AD?

Respuesta1

Sus soluciones aquí son FreeIPA o Centrify/PowerBroker. FreeIPA es parte de su suscripción estándar de RHEL, por lo que ya existen algunos ahorros.

FreeIPA se puede ejecutar en un modo en el que todos los usuarios y grupos puedan provenir de Active Directory. Solo mantendría el mapeo de esos usuarios y grupos a entornos específicos de POSIX en FreeIPA, como reglas SUDO, claves SSH públicas, definiciones de control de acceso basadas en host, asignaciones de contexto SE Linux, etc. Para hacerlo, necesitará asignar algunos de sus usuarios/grupos de AD a algunos grupos en FreeIPA, pero eso no es una duplicación de la información, sino que la modifica con las partes que no son específicas de AD.

La forma en que FreeIPA implementa la compatibilidad con Active Directory es presentándose como una especie de bosque compatible con Active Directory. Es suficiente permitir que los usuarios de AD consuman los recursos de FreeIPA a través de la confianza entre bosques, pero no lo suficiente como para permitir que los usuarios de FreeIPA accedan a los sistemas Windows en el otro lado de la confianza. Parece que estás interesado en la primera parte, así que debería estar bien.

Con FreeIPA 4.1, que ya forma parte de RHEL 7.1 beta (con suerte, RHEL 7.1 saldrá "pronto"), tenemos un poderoso mecanismo para mantener las anulaciones para usuarios y grupos de AD en FreeIPA y SSSD es capaz de descubrirlos todos en granularidad por servidor.

Respuesta2

Realmente me gustaría saber qué quiere decir con "grupos AD reales" cuando habla de SSSD. Las versiones más nuevas de SSSD no requieren que los grupos tengan atributos POSIX y en su mayoría leen las membresías de grupo de TokenGroups si se utiliza el proveedor de AD.

Además, en RHEL-7.1 (upstream 1.12+), el SSSD obtuvo la capacidad de realizar comprobaciones de control de acceso utilizando políticas de GPO.

No dude en venir y escribir a la lista de usuarios de sssd si tiene una pregunta específica.

Respuesta3

La oferta de Redhat se trata bien aquí:
¿Sabiduría común sobre la autenticación de Active Directory para servidores Linux?

En mis instalaciones recientes, esto se ha hecho a través de filtros de grupo SSSD (integrados) y ldap o sssd.conf.

¿Qué necesitan exactamente sus usuarios de Linux?haceren los sistemas?

Respuesta4

¿Qué pasa con winbind + samba + kerberos?

  • Autenticación a través de credenciales AD (permitir que un usuario entre por la puerta)

comprobado

  • Autorización una vez autenticado (otorgar a un usuario acceso a áreas del sistema)

comprobado

  • Auditoría (poder vincular las acciones de los usuarios con sus credenciales de AD)

/var/log/secure? comprobado

  • Soporte para grupos AD (no solo LDAP básico y tener que agregar/eliminar usuarios individuales en los sistemas)

permite tanto grupos de anuncios como usuarios de anuncios en grupos locales, marcado

  • No es una fuente de identidad duplicada/reflejada basada en la confianza de AD (no necesito dos sistemas enormes)

freeipa no es necesaria, marcada

información relacionada