Al tratar con cientos de servidores RHEL, ¿cómo podemos mantener cuentas raíz locales y cuentas de usuario de red? ¿Existe una solución de tipo de directorio activo que los administre desde una ubicación central?
Al tratar con cientos de servidores RHEL, ¿cómo podemos mantener cuentas raíz locales y cuentas de usuario de red? ¿Existe una solución de tipo de directorio activo que los administre desde una ubicación central?
Respuestas:
Un componente central de Active Directory es LDAP, que está disponible en Linux en forma de OpenLDAP y 389DS (y algunos otros). Además, el otro componente principal Kerberos está disponible en forma de MIT Kerberos y Heimdal . Finalmente, incluso puede conectar sus máquinas a AD.
sudoersreglas (o ambas).
Puede probar con Puppet para administrar usuarios:
¿Por qué usar Puppet para administrar cuentas de usuario? (y no NIS, LDAP, etc.)
Uno de los beneficios de administrar cuentas de usuario en Puppet es el hecho de que está descentralizado. Cada cuenta de usuario es solo una cuenta de usuario normal en el servidor administrado. No hay nada especial en las cuentas de usuario que Puppet crea, aparte del hecho de que fueron creadas por Puppet y no por un administrador humano. Lo bueno de esto es que si el host principal muere, no perdemos la autenticación. Lo que significa que nuestro servidor puppetmaster (o servidor NIS / LDAP) no necesita tener ningún requisito de tiempo de actividad especial. Si ocurre una emergencia, podemos concentrarnos en poner en funcionamiento nuestros servidores de producción, y enfocarnos en poner en funcionamiento al puppetmaster "según sea necesario". La desventaja de esto es que Puppet no necesariamente está realmente diseñado para administrar cuentas de usuario de inicio de sesión "normales" (a diferencia de las cuentas del sistema). La mayor forma en que esto surge es que, aunque puede establecer la contraseña en puppet, puppet monitorea continuamente la configuración del sistema (buena) y si nota que la contraseña ha cambiado, la restablecerá. (malo) No quiero monitorear las contraseñas de los usuarios en nuestra red, por lo que debe haber una manera de establecer una contraseña y que Puppet deje de monitorear esta contraseña. Afortunadamente, una vez que descubres el truco, esto es realmente bastante fácil. Pero primero, saquemos algunas definiciones del camino.
Como menciona SvenW, hay 389DS y Kerberos. Desde RHEL 6.2, Red Hat ha incluido IPA en la distribución (y, por lo tanto, también está en CentOS). Esta es una suite de gestión de identidad completa que incorpora 389DS y Kerberos, con control basado en políticas sobre autenticación y autorización, y opcionalmente DNS. Incluso se puede configurar para sincronización unidireccional o bidireccional con Active Directory.
IPA casi requiere SSSD en hosts RHEL pero funciona sin él. Incluso he probado la conexión de Solaris 10 a IPA (funciona, pero un poco complicado). IPA es bastante sencillo de configurar para hosts RHEL.
Esto se basa en el proyecto FreeIPA .
Para sus cuentas de usuario de red, se menciona OpenLDAP como SvW.
También debe consultar "Sistemas de administración de configuración" para administrar sus cuentas locales y todo lo demás en sus servidores. Eche un vistazo a CFEngine, Bcfg2, Puppet y Chef. Si está utilizando AWS, tienen algo de Chefy con OpsWorks.
Si realmente necesita administrar más de 100 servidores, tiene 10 Sysadmins o usa el software Configuration Management.
Esta puede ser una respuesta obvia, pero 'usa el directorio activo'. Debe modificar un poco nuestro esquema de AD, para incluir campos específicos de Unix, pero una vez que lo haga, tendrá un único directorio de todas sus cuentas de usuario que funciona multiplataforma.
Quizás sea menos útil si eres una tienda de Unix, pero en realidad no he visto muchos de esos. Pero AD es en realidad una combinación bastante buena de los elementos clave de LDAP y Kerberos. Me parece un poco irónico en realidad.
Pero lo que obtendrá 'gratis' es cuentas multiplataforma e integración de Kerberos para que pueda hacer exportaciones NFSv4 aplicando ACL 'reconocidas por CIFS' y montajes NFS krb5i / p, con autenticación de usuario fuerte (er).