Contenidos
Contexto
Hasta ahora hemos unido un equipo GNU/Linux Debian 12 CLI (Command Line Interface, sin interfaz gráfica de usuario). Este equipo tiene un servidor Samba instalado que nos permitirá compartir recursos en red.
Vamos a configurar un par de recursos compartidos a través de este equipo GNU/Linux con toda la organización, pero aplicando una serie de permisos de acceso utilizando la estrategia AGDLP que ya hemos estudiado.
Para este caso práctico, vamos a utilizar las siguientes máquinas virtuales:
- SSOO – WS2016 (Controlador del dominio jpedrerom.ex)
- SSOO – Debian 12 CLI (El equipo que compartirá recursos en red)
- SSOO – Windows 10 (El equipo que hará las veces de SOR Cliente)
Enunciado
En nuestra organización contamos con dos grupos claros de usuarios, los usuarios administradores y los desarrolladores. Para organizarlos ya hemos creado UOs dentro de una UO principal. Dentro de cada UO hemos creado un grupo global para cada departamento y usuarios del dominio.
Vamos a añadir un par de usuarios: ramonam (developers) y miguelmp (devops)
Creando nuevos usuarios
Para crear los usuarios nuevos vamos a aprovechar que tenemos configuradas las cuentas de marinapg y alfredoff de forma genérica dentro de los grupos de usuarios globales a los que pertenecen.
Comprobamos la configuración de marinapg
Copiamos el usuario miguelmp desde la cuenta de usuario marinapg@jpedrerom.ex.
Comprobamos que ambos pertenecen al grupo devops.
Hacemos lo mismo con la cuenta de usuario alfredoff@jpedrerom.ex, comprobamos y la usamos de base para crear una nueva cuenta de usuario.
Copiamos el usuario
Recursos compartidos
Ahora toca compartir recursos en red. Lo vamos a hacer aprovechando el sistema GNU/Linux Debian 12 y Samba. Los recursos en red serán los siguientes con las características que se dan a continuación:
- developers. ruta: /educatica/developers. Podrán acceder los miembros del grupo del dominio developers para realizar operaciones de lectura y escritura (Control Total). Además, marinapg podrá acceder para realizar operaciones de solo lectura.
- devops. ruta: /educatica/devops. Podrán acceder los miembros del grupo del dominio devops para realizar operaciones de lectura y escritura (Control Total). Además, alfredoff podrá acceder para realizar operaciones de solo lectura.
Pista
Vamos a configurar los permisos de acceso utilizando acl en el sistema de ficheros local. En Samba seremos muy permisivos dejando que los permisos efectivos que se apliquen, los mas restrictivos, sean los permisos locales.
Metodología AGDLP
Hemos visto como hay dos recursos compartidos y cada uno de ellos tiene dos tipos de acceso: Control total y solo lectura. Atendiendo a esta información tenemos que pensar los grupos de Dominio Local que vamos a necesitar crear y configurar para gestionar el acceso a los recursos compartidos.
Si recordamos AGDLP para cada recurso compartido debemos crear tantos grupos de Dominio Local como tipos de acceso queramos aplicar. Una vez sepamos los tipos de acceso que queremos permitir, tan solo tendremos que crear un grupo de Dominio Local con el nombre del recurso compartido seguido del tipo de acceso. Siguiendo esta nomenclatura es fácil identificar el uso que daremos de cada uno de los grupos.
Vamos a comenzar por el recurso compartido developers. Según el enunciado tendremos dos tipos de acceso: Control total y solo lectura. Si seguimos la nomenclatura propuesta para los grupos DL tendríamos los siguientes grupos:
- Developers_CT. Control total para Developers
- Developers_L. Solo lectura para Developers
Vamos a por el segundo recurso compartido. También tiene dos tipos de acceso: Control total y solo lectura, por tanto tendremos que crear dos grupos DL para gestionar estos accesos:
- Devops_CT. Control total sobre el recurso Devops
- Devops_L. Solo lectura sobre el recurso Devops.
¡Vamos a crear los grupos! Si queremos, podemos crear una nueva UO dónde almacenar todos los grupos DL que utilicemos para configurar permisos de acceso sobre recursos compartidos.
Ahora toca añadir a cada grupo los usuarios o grupos del dominio que tendrán el acceso para el que se ha creado cada grupo.
Developers_CT. Este grupo controla el acceso de Control Total para el recurso Developers. Los miembros del grupo Developers deberían tener acceso de Control total. Por tanto, los añadimos como miembros de este grupo.
Developers_L. Este grupo controla el acceso de Lectura para el recurso Developers. El usuario del dominio marinap@jpedrerom.ex debería tener acceso de Lectura. Por tanto, los añadimos como miembros de este grupo.
Devops_CT. Este grupo controla el acceso de Control Total para el recurso Devops. Los miembros del grupo Devops deberían tener acceso de Control total. Por tanto, los añadimos como miembros de este grupo.
Devops_L. Este grupo controla el acceso de Lectura para el recurso Devops. El usuario del dominio alfredoff@jpedrerom.ex debería tener acceso de Lectura. Por tanto, los añadimos como miembros de este grupo.
Compartiendo los recursos en GNU/Linux
Vamos a iniciar sesión en la máquina de GNU/Linux Debian 12 y comprobaremos que tenemos acceso a la información de usuarios y grupos del dominio. Para ello, podemos utilizar el comando id.
Vamos a ver los datos de miguelmp@jpedrerom.ex
Instalando soporte acl para nuestro sistema de ficheros
Para poder trabajar con permisos con ACLs del estilo de Windows en los sistemas de ficheros que las soporten (ext4 lo hace) tenemos que realizar una pequeña configuración del sistema de ficheros y, además, instalar paquetes de software que nos permitan configurar estos permisos desde GNU/Linux con comandos.
El paquete de software que vamos a instalar es acl.
Instalamos acl.
Con esto tenemos acceso a dos comandos interesantes: setfacl y getfacl. Si queremos información sobre cualquiera de estos dos comandos podemos consultar la ayuda de cada comando o su página de manual.
Vamos a ver la página de manual de setacl.
Ahora que tenemos soporte acl, vamos a utilizar setfacl para configurar permisos de acceso en directorios de nuestro sistema de ficheros. No obstante, para asegurarnos de que podemos aplicar estos permisos de acceso sobre el sistema de ficheros raiz, tendríamos que haberlo montado con la opción acl.
Podemos comprobar si está activado acl en el sistema de ficheros raiz, que esta en /dev/sda1
en principio, tiene pinta de que se está usando acl en /dev/sda1, que es el sistema de ficheros raíz. No obstante, si queremos asegurarnos tendríamos que añadir la opción acl en las opciones de montaje de este sistema de ficheros / en el fichero /etc/fstab.
Vamos a ver la configuración actual del fichero y nos centraremos en la línea de configuración del sistema de ficheros raíz.
Tenemos que añadir la opción acl, lo haremos delante de errors=remount-ro (esta opción indica que en caso de error al montar este sistema de ficheros que intente montarlo de nuevo pero ahora en modo solo lectura).
Ahora reiniciamos para requeteasegurarnos de que se podrán utilizar acls de forma correcta en el sistema de ficheros raiz.
Una vez reiniciado el sistema, vamos a crear los directorios y los configuraremos para que tengan los permisos que esperamos.
Creamos los directorios:
Solo con los permisos POSIX de GNU/Linux no tenemos suficiente para configurar los permisos AGDLP que queremos utilizar. Por eso, utilizaremos ACLs.
Vamos a echar un vistazo a los permisos con acl del directorio /educatica/developers
Vamos a añadir el grupo Developers_CT con permisos de Control total (rwx) al directorio /educatica/developers.
También añadiremos el grupo Developers_L@jpedrerom.ex con permisos de solo lectura (rx) al directorio /educatica/developers.
Vamos a comprobar que la configuración es correcta.
Se nos ha pasado quitar permisos a los otros para que nadie pueda acceder excepto los que estén en los grupos de Dominio Local que gestionan el acceso.
Repetimos el proceso con el directorio /educatica/devops: Devops_CT y Devops_L.
El último paso, sería crear los recursos compartidos en Samba devops y developers que compartan los directorios /educatica/devops y /educatica/developers respectivamente. Los permisos que configuraremos serán muy permisivos, puesto que los permisos que queremos que se apliquen los hemos configurado en cada directorio usando los grupos de Dominio Local creados para ello.
Vamos a ver si están compartidos los recursos.
Ahora vamos a probar a conectarnos a uno de los recursos usando: un usuario que pueda acceder con control total, otro que solo pueda acceder para lectura y otro que no pueda acceder. Elegiremos el recurso developers.
Antes de conectarnos, vamos a comprobar que tenemos a los usuarios en la base de datos de usuarios de samba.
Hemos añadido a miguelmp@jpedrerom.ex puesto que necesitamos un tercer usuario que no tenga acceso. Ya que estamos, añadimos también a ramonam
Accedemos con alfredoff@jpedrerom.ex que podrá realizar cualquier operación.
¿Por qué alfredoff@jpedrerom.ex puede realizar cualquier operación? ¿Pertenece alfredoff@jpedrerom.ex al grupo developers_CT?
Alfredoff@jpedrerom.ex pertenece a developers@jpedrerom.ex, pero no a developers_ct@jpedrerom.ex. Lo que sucede es que el grupo developers@jpedrerom.ex, si pertenece al grupo developers_ct@jpedrerom.ex y por tanto, alfredoff@jpedrerom.ex también pertenece a este grupo.
Vamos a ver si podemos acceder con marinapg@jpedrerom.ex.
De la misma forma que pasaba con alfredoff@jpedrerom.ex, marinapg@jpedrerom.ex pertenece al grupo developers_L@jpedrerom.ex por lo que podrá acceder para realizar operaciones de solo lectura.
Vamos a probar ahora con el usuario miguelmp que no pertenece a ninguno de los dos grupos de dominio local que gestionan el acceso a este recurso.
Nos conectamos
Samba deja que el usuario inicie sesión, que se conecte, puesto que desde samba no hay restricciones. No obstante, como no tiene ningún tipo de permisos desde el sistema de ficheros local, este usuario no puede realizar ninguna operación: las intenta, pero no tiene permisos en local.
Vamos a probar desde Windows.
Dejar una respuesta