En este caso práctico vamos a añadir nuestro sistema GNU/Linux Debian 12 CLI al dominio jpedrerom.ex (NombreBase.ex) para que proporcione servicios a la organización a través del dominio que hemos montado en Active Directory con Windows Server 2016.
El primer paso será unir este sistema al dominio, para que pueda acceder a los recursos y objetos del dominio y pueda ser localizado fácilmente por los usuarios del dominio.
Para el proceso de unión podemos seguir los pasos de la entrada Uniendo GNU/Linux Debian 12 a un Dominio de Active Directory.
También uniremos un Sistema Windows 10 al dominio para que podamos practicar más tarde con los servicios proporcionados por nuestro servidor GNU/Linux Debian 12 CLI
Creando instantáneas
Este paso no es estrictamente necesario pero nos viene bien para poder volver atrás en caso de problemas o en caso de querer reutilizar alguno de los sistemas.
Se recomienda realizar una instantanea para las siguientes máquinas virtuales:
- SSOO – Debian 12 CLI Pruebas
- Antes de unir al Dominio jpedrerom.ex
- SSOO – WS2016
- Antes de añadir equipos, usuarios y grupos al dominio
Uniendo el equipo ASO00 al dominio jpedrerom.ex
Vamos a unir el equipo ASO00 al dominio pero para ello, nos vamos a conectar con ssh desde el sistema GNU/Linux Debian 12 con entorno de escritorio.
Además, vamos a tratar de tomar información que pueda ser útil para automatizar la instalación de software y configuración del sistema en lo posible a través de un script aprovechando este caso práctico. Es decir, la idea es obtener información del proceso de unión de un equipo a un dominio para después tratar de automatizarlo con un script.
- Configuración del nombre del equipo
- Configuración de red: IP y DNS
- Instalación del software
- Configuración del sistema y del software
- Uniendo el equipo al dominio
Antes de comenzar el proceso, vamos a echar un vistazo a Usuarios y equipos de Active Directory en el controlador de dominio para comprobar que no hay ningún equipo todavía.
Vamos a trabajar desde GNU/Linux Debian 12 con entorno de escritorio.
Configuración del nombre del equipo
Aunque el nombre ASO00 está bien vamos a cambiarlo por otro para practicar. srv01.
Para cambiar el nombre de un equipo en GNU/Linux Debian tenemos que cambiar el nombre con hostnamectl y además cambiar la entrada de este equipo en el fichero de resolución estática local de nombres: /etc/hosts.
Vemos la infpormación del equipo
Vamos a cambiar el nombre
Ahora tenemos que cambiar la entrada de la dirección ip 127.0.1.1 en /etc/hosts. Esta será la entrada asociada al antiguo nombre del equipo. Tenemos que cambiarla por el nuevo nombre.
Cambiamos con el nuevo nombre
Después de haber realizado este cambio ya no nos muestra el fallo temporal.
Ahora deberíamos cerrar la sesión para que los cambios se apliquen en nuestro entorno de trabajo.
Si nos fijamos en el prompt, el nombre del equipo ha cambiado.
Configuración de la red
Ahora tenemos que asegurarnos de estasr conectados a la misma LAN que el servidor WS2016 y utilizar el servidor DNS de la organización, que está instalado en el servidor WS2016 que hace de controlador de dominio principal.
Vamos a mostrar la configuración de red de nuestras interfaces de red.
Vamos a ver la configuración de red de WS2016. La dirección IP del servidor es 192.168.100.254/24.
Vamos a configurar el cliente DNS de nuestro sistema Debian para que utilice el servidor DNS de la organización cuya dirección IP es la del controlador de dominio, que será 192.168.100.254. Para ello, editamos el fichero /etc/resolv.conf.
Para comprobar que todo ha ido bien, vamos a utilizar el comando ping, pero en lugar de usar la dirección IP del controlador de dominio vamos a usar su FQDN. De esta forma, si ping funciona, comprobamos tanto la conexión al equipo a través de la red como la resolución de nombres DNS.
Instalando el software
Ahora vamos a hacer uso del editor de textos mousepad en nuestro equipo de escritorio para ir tomando nota de los pasos que vamos dando para unir el equipo al dominio.
Copiamos y pegamos los comandos que vayamos ejecutando… Seleccionamos lo que queramos copiar y lo pegamos.
Pegamos
Ahora instalamos la retaila de paquetes necesarios…
Escribimos el nombre del dominio en mayúsculas!
Configuración de systemd-timesyncd
Puede que al instalar ntp nos de un problema, que ya tengamos instalado y activo el servicio time-daemon. En este caso podemos configurarlo.
En este caso no necesitamos instalar ntp, podemos configurar el time-daemon de forma muy sencilla.
Editamos el fichero de configuración
Añadimos una entrada NTP
Reiniciamos el servicio
Comprobamos
Configuración del cliente NTP
Para ello editamos el fichero /etc/ntpsec/ntp.conf. Podemos aprovechar el tabulador para autocompletar la ruta de este tipo de ficheros de configuración.
Añadimos la configuración para el servidor NTP de nuestro dominio, que estará en el controlador de dominio principal y comentamos el resto de servidores NTP configurados en el fichero.
Comentamos las entradas de otros servidores NTP o pools
Salimos de nano y vamos a ver la configuración real que tenemos, para ello mostramos las líneas del fichero sin comentarios.
Reiniciamos ntp para que se conecte con el servidor y comprobamos el estado.
Configurando realmd
Uniendo el equipo al dominio con kinit y realm
Ejecutamos el comando kinit para obtener un «ticket» para unirnos al dominio
Nos unimos
Comprobamos en el controlador de dominio si se ha unido.
Configuramos sssd
Reiniciamos el servicio
Configuramos PAM
Vamos a probar si tenemos conexión real con el dominio.
Reiniciamos el equipo
Añadiendo entrada para el servidor srv01 en el servidor DNS
A diferencia de lo que sucede con los sistemas de escritorio de Windows, al unir el sistema srv01 con GNU/Linux al dominio, no se ha añadido automáticamente una entrada en el DNS para este equipo.
Tendremos que añadir la entrada manualmente.
Añadimos la entrada
Comprobamos la información
Creando UOs, grupos y usuarios
Grupos y usuarios
Developers
Añadimos Windows 10 al dominio
En mi caso no tenía unido ningún sistema Windows de escritorio al dominio. Vamos a unir un Windows 10.
Configuramos la red del sistema Windows 10.
Comprobamos que hay resolución de nombres y conexión con el controlador de dominio.
Ahora lo añadimos al dominio jpedrerom.ex
Nos solicita cuenta de usuario con permisos para añadir un equipo.
Reiniciamos
Iniciamos sesión con marinapg@jpedrerom.ex
Se está creando su perfil de usuario local en el equipo host01.jpedrerom.ex
Ya hemos iniciado sesión, ahora continuamos configurando el servidor de ficheros.
Comprobando conexión con el dominio
Comprobamos conexión con el dominio utilizando id con el nombre de alguno de los usuarios que hemos creado. Si obtenemos información, podríamos utilizarla en los ficheros de configuración de samba para controlar el acceso a determinados recursos compartidos.
Como podemos ver, obtenemos información del usuario marinapg@jpedrerom.ex
Configurando recursos compartidos en Samba (1)
Vamos a empezar con algo sencillo, vamos a configurar recursos compartidos en Samba desde el servidor GNU/Linux Debian 12 CLI.
Comenzaremos con un par de recursos compartidos:
- shared. Compartirá el directorio /jpedrerom/compartido para que cualquier usuario (invitados también) pueda acceder para lectura.
- public. Compartirá el directorio /jpedrerom/uploads para que cualquier usuario del dominio con cuenta en samba pueda acceder para lectura y escritura. No se permiten invitados.
Editamos el fichero de configuración /etc/samba/smb.conf.
Reiniciamos y comprobamos los recursos compartidos disponibles en el sistema.
Creamos los directorios y los configuramos para permitir las operciones desde Samba. Vamos a ser muy flexibles con la configuración de permisos de escritura en el caso del directorio del recurso public.
Ahora vamos a crear un fichero leeme.txt para mostrar información sobre le directorio compartido y, además, permitir que los usuarios puedan trabajar.
Vamos a crear otro fichero, uno que no se podrá modificar ni borrar dados los permisos que vamos a configurar, en el directorio del recurso compartido public.
Ahora vamos a probar los accesos a ambos recursos, desde GNU Linux con smbclient primero y después desde Windows.
Tenemos un problema, que nos da una pista de algo que se nos ha pasado y que deberíamos de buscar una solución: añadir un usuario del dominio a la base de datos de usuarios de samba. Seguro que hay una alternativa a tener que añadir a mano los usuarios del dominio a la base de datos de usuarios de samba.
Mientras tanto, vamos a añadirlo con smbpasswd y después tratamos de solucionarlo.
Vamos a mostrar información de la base de datos de usuarios de samba con pdbedit -L
Ahora vamos a mostrar información extendida de uno de los usuarios, por ejemplo marinapg@jpedrerom.ex
Ahora accedemos de nuevo al recurso public.
Vamos a realizar operaciones de lectura y escritura en el directorio, alguna de las cuales no funcionará.
No ha podido leer el fichero leeme.txt porque no tiene permiso de lectura:
Es interesante ver cómo se ha asignado como propietario a marinapg@jpedrerom.ex y grupo usuarios del dominio@jpedrerom.ex. Esto nos da una pista, sobre todo en el último caso, de como configurar nombres de grupos del dominio.
Cambiamos los permisos de leeme.txt para que los usuarios lo puedan leer.
Vamos a tratar de acceder desde Windows.
Vamos a conectarnos a través del explorador de windows para ver qué recursos tiene compartido este sistema srv01.jpedrerom.ex
Vamos a ver lo que se muestra
Accedemos a public
Probamos con la arroba
Hemos accedido
Vamos a leer el fichero, a crear un directorio y un fichero dentro.
Creamos el directorio
Creamos un fichero dentro del directorio
Vamos a ver los permisos desde GNU/Linux Debian servidor.
Ahora vamos a tratar de acceder al directorio shared.
No podemos realizar operaciones de escritura.
Recursos compartidos con acceso de ciertos usuarios
Ahora toca la parte complicada, vamos a crear un recurso compartido al que solo pueda acceder el usuario marinapg y para que solo puedan acceder los miembros de un grupo.
Nos aseguramos de que marinapg@jpedrerom.ex pertenece a devops.
Configuramos el recurso devops.
Configuramos el sistema
Ahora probamos a acceder desde Linux con smbclient.
Probamos desde windows
Por alguna razón, no nos deja acceder. Vamos a cambiar el valid users del recurso compartido.
Probamos de nuevo
Si tratamos de acceder ahora…
Tenemos un problema con valid users. Vamos a activarlo de nuevo.
Vamos a probar con write list
… vamos a comprobar si obtenemos la información del ADDC.
La Solución: AGDLP
Hemos visto como, por algún motivo, Samba no es capaz de comprobar la pertenencia de usuarios del dominio ni de usuarios del dominio a un grupo del dominio. Este problema puede estar causado por el uso de sssd como demonio o servicio de autenticación de usuarios dentro de un dominio AD.
Sin embargo, desde nuestro sistema GNU/Linux con acceso local si que somos capaces de identificar y autentificar el acceso de usuarios del dominio a los recursos del mismo.
Aquí está la solución, utilizar la estrategia AGDLP, es decir configurar permisos de acceso de forma local con grupos del dominio de tipo Seguridad y ámbito Dominio Local, y configurar el acceso desde Samba de forma totalmente abierta. Al final, los permisos que se aplican
Dejar una respuesta