Cómo unir un sistema Linux a un dominio de Active Directory

Active Directory (AD) de Microsoft es el servicio de directorio de referencia para muchas organizaciones. Si usted y su equipo son responsables de un entorno mixto de Windows y Linux, probablemente le gustaría centralizar la autenticación para ambas plataformas. Cubriré cómo agregar computadoras Linux a un dominio de Active Directory.

Active Directory y la necesidad de una gestión de acceso centralizada

Active Directory de Microsoft, más conocido popularmente como AD, ha ocupado la mayor parte del mercado de gestión de acceso empresarial durante muchos años. Es utilizado por instituciones e individuos de todo el mundo para controlar de forma centralizada el acceso a los recursos que pertenecen a la organización. Le brinda la capacidad de administrar usuarios, contraseñas, recursos como computadoras y dictar quién tiene acceso a qué. Para algunos de ustedes que leen este artículo, especialmente aquellos que trabajan en grandes instituciones, han interactuado con AD antes. Por lo general, la interacción utiliza un conjunto de credenciales de inicio de sesión para iniciar sesión en cualquier estación de trabajo de la organización. Eso es solo la punta de un gran iceberg.

Imagine una colección de 40 sistemas informáticos y 70 usuarios en una empresa. Algunos empleados trabajan por turnos mientras que otros trabajan en horarios regulares. Algunos tienen acceso a la imprenta; otros no. La forma tradicional de trabajar es crear cuentas de usuario locales en cada computadora a la que el usuario necesita acceder. Imagine la carga de trabajo del equipo de soporte al usuario final. Cuando un usuario cambia su contraseña por cualquier motivo, ese usuario tiene que cambiar la contraseña en todas las computadoras a las que tenía acceso anteriormente, para mantener las cosas sincronizadas. En poco tiempo, habrá caos. Ahora, imagine que dos miembros del personal renuncian. No necesito decirles el trabajo monótono que debe repetirse cada vez que hay un cambio en el personal o en las estaciones de trabajo. Para los equipos de TI, esto es una pesadilla. El tiempo que podría utilizarse para tareas innovadoras ahora se dedica a reinventar la rueda. Ni siquiera he hablado de gestionar el acceso a las impresoras.

Aquí es donde prospera un servicio de directorio como Active Directory. Literalmente puede ser un salvavidas. Con Active Directory, cada usuario se crea de forma única como un objeto en una base de datos central, con un solo conjunto de credenciales. Cada sistema informático también se crea como un objeto. Automáticamente, cada usuario puede acceder a cada estación de trabajo con el mismo conjunto de credenciales. Cualquier cambio de cuenta que deba realizarse se realiza una vez en la base de datos central. Los miembros del personal pueden acceder a las impresoras utilizando el mismo conjunto de credenciales. El mecanismo de autenticación de las impresoras se puede combinar con AD para lograrlo. Usuarios felices, equipo de TI feliz.

Mediante el uso de grupos y unidades organizativas, se puede personalizar y mantener el acceso a diversos recursos. Se pone aún mejor. Este directorio puede almacenar números de teléfono del personal, direcciones de correo electrónico y puede ampliarse para almacenar otra información. ¿Qué pasa si alguien renuncia? No hay problema. Simplemente deshabilite la cuenta del usuario. El acceso de esa persona a todos los recursos se anula en el acto. Cuanto más grande es la organización, mayor es la necesidad de una gestión centralizada. Ahorra tiempo; salva las emociones.

En esencia, un servicio de directorio es solo una forma organizada de detallar todos los recursos de una organización al mismo tiempo que facilita el acceso a esos recursos. Básicamente, AD es un tipo de base de datos distribuida, a la que se accede de forma remota a través del Protocolo ligero de acceso a directorios (LDAP). LDAP es un protocolo abierto para acceder de forma remota a los servicios de directorio a través de un medio orientado a la conexión, como TCP/IP. AD no es el único servicio de directorio basado en el estándar x.500, o al que se puede acceder mediante LDAP. Otros servicios de directorio incluyen OpenLDAP y FreeIPA. Sin embargo, AD es un servicio maduro basado en Windows que viene incorporado con los sistemas Windows Server. En otras palabras, será el ganador automático cuando su organización tenga muchos sistemas Windows. Esta es una de las razones de su ubicuidad. Los servicios de directorio como FreeIPA están basados ​​en Linux y brindan un servicio excelente para un establo de Linux. Cuando la goma llega a la carretera, la elección se reduce a cuál de los dos puede configurar rápidamente, dado su entorno actual y el conjunto de habilidades de su equipo.

[ También te puede interesar: Interoperabilidad de Windows y Linux:un vistazo a Samba ]

Pero, ¿qué sucede cuando elige AD y tiene algunos servidores CentOS y no desea mantener un conjunto separado de credenciales para sus usuarios de Linux? Esa sobrecarga es completamente evitable. Lo que debe hacer es unir los servidores Linux al dominio AD, como lo haría con un servidor Windows.

Si eso es lo que necesita hacer, siga leyendo para descubrir cómo hacerlo. Es posible unir un sistema Windows a un dominio FreeIPA, pero eso está fuera del alcance de este artículo.

Requisitos previos

Este artículo presupone que tiene al menos cierta experiencia de nivel introductorio con Active Directory, especialmente en lo que respecta a la administración de cuentas de usuarios y computadoras. Aparte de eso, se deben cumplir los siguientes requisitos obvios:

• Una cuenta en AD que tiene los privilegios necesarios para unir un sistema al dominio.
• Un servidor Linux (para esta demostración se utilizó un servidor CentOS 7).
• Un controlador de dominio.
• Asegúrese de que su servidor Linux sepa cómo encontrar el controlador de dominio a través de DNS.

Para que este artículo sea más fácil para todos, aquí hay una lista de detalles clave. Así es como está configurado el laboratorio que utilicé para este artículo, por lo que debe modificarlo en consecuencia.

• Nombre de dominio AD:Hope.net
• Cuenta de usuario para unirse al dominio:fkorea (Nombre completo - Fiifi Corea)
• Nombre de host del servidor Linux:centy2

Paquetes para instalar

Para esta configuración, el paquete esencial para instalar es realmd . Aparte de realmd , hay una gran cantidad de paquetes que deben instalarse para que esto funcione.

# yum install sssd realmd oddjob oddjob-mkhomedir adcli samba-common samba-common-tools krb5-workstation openldap-clients policycoreutils-python

Realmd proporciona una forma simplificada de descubrir e interactuar con los dominios de Active Directory. Emplea sssd para realizar las búsquedas reales requeridas para la autenticación remota y otros trabajos pesados ​​de interacción con el dominio. En aras de la brevedad, no me detendré en los otros paquetes de la lista.

Sin embargo, para aquellos interesados ​​en los detalles, una búsqueda rápida en Google debería ser de gran ayuda.

Realmd (interactuando con el dominio)

Ahora que se han instalado todos los paquetes, lo primero que debe hacer es unir el sistema CentOS al dominio de Active Directory. Usamos el realm solicitud para eso. El realm el cliente se instala al mismo tiempo que realmd . Se utiliza para unirse, eliminar, controlar el acceso y realizar muchas otras tareas. Esta es la sintaxis esperada para una unión de dominio simple:

realm join --user=[domain user account] [domain name]

El espacio entre la cuenta de usuario y la cuenta de dominio no es un error tipográfico. Al insertar los detalles correspondientes, obtenemos el siguiente comando:

# realm join --user=fkorea hope.net

Proporcione la contraseña cuando aparezca el mensaje y espere a que finalice el proceso.

No se deje engañar por la breve ausencia de salida. Hay una serie de operaciones que se llevan a cabo como parte del proceso. Puede agregar -v interruptor para una salida más detallada. Sin embargo, la mejor manera de verificar si la computadora ahora es miembro del dominio es ejecutando la realm list dominio. El comando intenta mostrar el estado actual del servidor con respecto al dominio. Es una forma rápida y sucia de saber qué grupos o usuarios pueden acceder al servidor.

Echa un vistazo a su salida:

También es bastante trivial colocar el objeto de computadora AD recién creado en una unidad organizativa (OU) específica desde el principio. Dejaré eso para leer más, pero, como consejo, puede consultar la página de manual. Usando el realm cliente, puede conceder o revocar el acceso a los usuarios y grupos del dominio. Una inmersión profunda en el uso de realmd de una manera más detallada es suficiente para hacer otro artículo. Sin embargo, no estaré fuera de lugar para seleccionar algunos parámetros para su atención, a saber, el software del cliente y el software del servidor. A estas alturas, debería entender por qué tuvimos que instalar tantos paquetes.

Para abandonar el dominio por completo, necesita dos palabras:realm leave

Configuración adicional

Entonces, ahora que el servidor Linux es parte del dominio AD, los usuarios del dominio pueden acceder al servidor con sus credenciales habituales. Hemos terminado, ¿verdad? Equivocado. "¿Cuál es el problema?" Te escucho decir.

Bueno, para empezar, esta es la configuración básica para ponerlo en funcionamiento. Pero la experiencia es torpe, por decir lo menos. Necesitamos configurar más el servicio para darle una verdadera sensación de AD. Debería ser como iniciar sesión en una estación de trabajo de Windows 10 unida a un dominio.

En segundo lugar, está el gran elefante en la habitación para los administradores de sistemas llamado Actualizaciones de DNS Dinámico (DynDNS). Si no está configurado correctamente, creamos una sobrecarga adicional al tener que mantener los registros DNS manualmente. Para un entorno que depende en gran medida de DNS, eso podría ser un problema. Para los sistemas Windows, unir un sistema al dominio significa que dos entradas se administran y mantienen automáticamente en el servidor DNS. Cuando las direcciones IP cambian, el cambio se refleja automáticamente en el DNS. Esto significa que puede cambiar las direcciones IP de los sistemas sin incurrir en el costo del mantenimiento manual. Esto solo tendrá sentido para las personas que ya aprovechan el DNS en sus entornos. Aparte de las notables ganancias de productividad de la automatización, es útil que los entornos Windows y Linux funcionen de la misma manera.

El tercer problema es la limpieza de DNS. En un dominio de Active Directory, los controladores de dominio suelen proporcionar el DNS. Cada sistema unido al dominio tiene una entrada DNS automática con una dirección IP correspondiente. Esto es muy conveniente. Automáticamente, en un intervalo específico, los registros DNS obsoletos se eliminan para evitar paquetes mal dirigidos y también para cuidar los objetos de la computadora eliminados. Esto se conoce como búsqueda , y no está activado de forma predeterminada en AD. Sin embargo, si está encendido, debemos configurarlo. Por lo general, el intervalo de barrido es de siete días. Si transcurrido ese plazo no se ha producido ninguna actualización del registro, se elimina, salvo que se trate de un registro estático. Para los sistemas Windows, la característica de actualizaciones dinámicas se configura automáticamente. Sin embargo, con los servidores Linux, es necesario realizar algunas modificaciones. Sin hacer eso, los servicios dejarán de funcionar después de un tiempo porque sus registros se eliminarán del DNS y nadie sabrá cómo acceder a sus componentes.

Ahora que conocemos algunos de los posibles problemas que debemos abordar, echemos un vistazo a algunas de las cosas que podemos modificar para brindar una experiencia más fluida al usuario final y al administrador del sistema.

SSSD (inicios de sesión más fáciles y actualizaciones dinámicas)

sssd en un sistema Linux es responsable de permitir que el sistema acceda a los servicios de autenticación desde una fuente remota como Active Directory. En otras palabras, es la interfaz principal entre el servicio de directorio y el módulo que solicita los servicios de autenticación, realmd . Su archivo de configuración principal se encuentra en /etc/sssd/sssd.conf . De hecho, este es el archivo de configuración principal que modificaremos.

Echemos un vistazo a su contenido antes de la configuración. Una vez que se une al dominio, se modifica inmediatamente para contener la información mínima requerida para un inicio de sesión exitoso. Mi archivo se veía así:

Para resolver los tres problemas que mencioné anteriormente, edite su archivo para que se vea como el siguiente:

La mayoría de las opciones se explican por sí mismas, y puede modificar las suyas en consecuencia mientras analizamos lo que representan algunas de las opciones clave. Se puede obtener más información sobre todas las opciones consultando la página del manual. Creo que está bien escrito. Simplemente escriba man 5 sssd.conf en la línea de comando. También puede ver la página man de sssd_ad para más información.

En primer lugar, el archivo de configuración se divide en dos secciones. La sección global, bajo [sssd] y la sección de opciones específicas del dominio, [dominio/[nombre de dominio]] .

La sección global contiene opciones que afectan el comportamiento general de sssd , como la información de la versión y los servicios relacionados. A continuación se muestra un parámetro clave en esta sección:

• sufijo_de_dominio_predeterminado - Establézcalo en el nombre de dominio si no desea tener que escribir el nombre completo de la cuenta de usuario al iniciar sesión. En lugar de tener que escribir [email protected] siempre, puedes escribir fkorea y la contraseña. Esto ayuda mucho cuando tienes un nombre de dominio largo.

La sección específica del dominio contiene parámetros que son específicos del dominio al que se ha unido. Los parámetros clave son:

• proveedor_de_acceso - Le permite seleccionar un proveedor optimizado y utilizado para interactuar con los servidores AD con fines de autenticación. Debe establecerse en ad . Otros valores que se pueden usar aquí son ldap y ipa , suponiendo que utilice esos servicios de directorio.
• proveedor_id - Le permite seleccionar un proveedor optimizado y utilizado para interactuar con servidores AD con fines de identificación. Debe establecerse en ad .
• nombre_host_del_anuncio - Este debe ser el nombre de host completo del servidor. Debe configurarse si el nombre de host del sistema es diferente al nombre de dominio completo. Si esto no está configurado y el sssd no tiene acceso al nombre de host completo, las actualizaciones dinámicas fallarán.
• dominio_anuncio - Este debe ser el nombre de dominio completo (hope.net en este caso).
• caché_credenciales - Esto permite a los usuarios de AD iniciar sesión cuando el controlador de dominio está fuera de línea. Cuando se establece en verdadero , las credenciales se almacenan en caché durante un período tal que la autenticación no falla cuando el back-end está fuera de línea. El período de almacenamiento también es configurable.
• fallback_homedir - Esto lo ayuda a establecer un directorio de inicio para los usuarios de AD que no tienen un atributo de directorio de inicio en AD. Esto es diferente del override_home parámetro que funciona cuando se establece un directorio de inicio en AD para los usuarios.
• dyndns_actualización - Esto habilita las actualizaciones dinámicas de DNS y acepta verdadero o falso como un valor. Cuando las actualizaciones dinámicas están habilitadas, las actualizaciones ocurren principalmente bajo tres condiciones:
  • Cuando se reinicia el servidor Linux.
  • Cuando el proveedor se conecta.
  • Cuándo vence el intervalo de actualización.
• dyndns_refresh_interval - Este valor está en segundos con un mínimo práctico de 60 segundos. Acepta valores enteros y tiene un valor predeterminado de 24 horas (86400s). En este ejemplo, lo configuramos en 12 horas. Si nada más activa una actualización, se realiza una actualización regularmente entre.
• dyndns_update_ptr - Un valor booleano que especifica si el registro PTR asociado debe actualizarse en cada ciclo de actualización. Los registros PTR se utilizan para búsquedas inversas y, a menos que haya una buena razón, se debe establecer en verdadero. .
• dyndns_auth - Especifica si las actualizaciones dinámicas deben realizarse de forma segura o no. La configuración depende del modo aceptado por AD. Si AD está configurado para Aceptar solo actualizaciones seguras , este valor debe establecerse en GSS-TSIG . De lo contrario, y no le interesan los beneficios de seguridad de las actualizaciones dinámicas seguras (a pesar de la fuerte advertencia en AD), este valor se puede establecer en ninguno .

Una vez completada la configuración, reinicie sssd para aplicar la configuración inmediatamente.

# systemctl restart sssd

En este punto, estamos listos. Ahora podemos iniciar sesión como lo haríamos en una estación de trabajo o servidor de Windows.

Visudo (otorgar privilegios de administrador)

Los usuarios a los que se les otorga acceso tienen acceso sin privilegios al servidor Linux. Para todos los efectos, todas las cuentas de Active Directory ahora son accesibles para el sistema Linux, de la misma manera que las cuentas locales creadas de forma nativa son accesibles para el sistema. Ahora puede realizar las tareas regulares de administrador del sistema de agregarlos a grupos, convertirlos en propietarios de recursos y configurar otras configuraciones necesarias. Si el usuario intenta cualquier actividad que requiera sudo acceso, se presenta el error familiar. Como se puede ver en el recuadro, nuestro usuario no está en los sudoers archivo.

En ese sentido, podemos editar los sudoers archivo directamente para otorgarles privilegios de superusuario. Este no es un artículo sobre cómo otorgar privilegios de superusuario, pero podemos usar el visudo herramienta para interactuar de forma segura con los sudoers archivo.

Alternativamente, podríamos haber agregado al usuario a la wheel grupo. El punto es que la cuenta de usuario ahora está disponible para ser utilizada por el sistema.

[ ¿La red se sale de control? Consulte Automatización de redes para todos, un libro gratuito de Red Hat. ] 

Resumir

Pruebe esto en su organización o entorno de laboratorio. Es obvio que acabo de tocar la superficie de este tema, pero esto lo llevará bastante lejos en el proceso. Consulte la documentación respectiva si desea explorar opciones que no se tratan en este artículo.

Unir un sistema Linux a un dominio de Active Directory le permite obtener lo mejor de ambos mundos. El proceso es muy simple y se puede programar con Bash o automatizar con Ansible, especialmente durante la configuración inicial del sistema. Si todavía está administrando un grupo de más de cinco sistemas sin un servicio de directorio y por una buena razón, hágase un favor y configure uno. Puedes agradecerme más tarde.