educación, informática y demás

Sistemas Operativos en Red

Jugando con Active Directory. 2 – Recurso compartido.

Introducción

Vamos a seguir con el caso práctico que hemos iniciado en la entrada Jugando con Active Directory. Ya hemos creado las unidades organizativas que nos servirán para estructurar los objetos de nuestro dominio, hemos creado grupos de seguridad de ámbito global para modelar las agrupaciones presentes en la organización, en nuestro caso un grupo para cada departamento. Hemos creado un par de cuentas de usuario de plantilla y un par de cuentas de usuario del dominio. Por último, hemos configurado perfiles móviles para algunos usuarios, en concreto para la plantilla de administradores y para el usuario alfredoff. El resto de usuarios utilizan perfiles locales de usuario.

En este documento vamos a crear un par de recursos compartidos para que los usuarios del dominio puedan almacenar y compartir ficheros a través de la red.

Enunciado

Los empleados del departamento de informática que se dedican al desarrollo utilizarán perfiles locales debido a que tienen que utilizar herramientas que ocupan mucho en sus perfiles de usuario y se ha decidido que utilicen equipos específicos para cada uno dónde tendrán dichas herramientas.

No obstante necesitan poder compartir información entre ellos para llevar a cabo desarrollos compartidos. Así que se ha decidido crear un recurso compartido en el servidor que esté disponible tan solo para los usuarios que sean miembros de los desarrolladores.

Tendrás que crear un directorio, compartirlo y, posiblemente, crear un nuevo grupo global para el nuevo tipo de usuario.

Por ahora no vamos a utilizar la estrategia AGDLP para configurar los premisos de acceso al recurso.

Desarrollo

Lo primero que tendríamos que hacer es crear un directorio en el sistema de ficheros de nuestro servidor para poder compartir dicho directorio como un recurso compartido en Red.

Si nos fijamos, tenemos disponible dos particiones con sistemas de ficheros NTFS en nuestro servidor. La primera partición tiene 25 GB y es dónde está almacenado el sistema operativo. La segunda partición tiene 35 GB libres.

En previsión de que en un futuro tengamos que compartir más directorios con otros usuarios del dominio, vamos a crear un directorio llamado Shared en el raíz de la unidad E: y dentro crearemos un directorio llamado Desarrolladores que será el que compartamos en esta ocasión para los usuarios desarrolladores.

Directorio para compartir con los Desarrolladores

Una vez creado el directorio Desarrolladores, ahora toca compartirlo como recurso compartido. Lo vamos a llamar Desarrolladores.

Configuramos los permisos de acceso remoto para que solo los usuarios del dominio Desarrolladores puedan acceder.

El problema que nos surge ahora es que no tenemos un grupo para los usuarios Desarrolladores. La solución es crearlo.

Si accedemos a los recursos compartidos en el equipo dc01.educatica.ex nos encontramos los siguientes:

Tenemos tanto el directorio Desarrolladores, que acabamos de compartir, como el directorio Perfiles, que contendrá los perfiles móviles de los usuarios del dominio.

Según la configuración de permisos remotos del directorio Desarrolladores, tan solo podrán acceder para realizar cualquier operación sobre el contenido del directorio los miembros del grupo desarrolladores que acabamos de crear.

Ahora mismo, el único usuario Desarrollador es marinapg. Así que vamos a añadir este usuario en el grupo de Desarrolladores.

Si nos fijamos, no hemos configurado los permisos de acceso local del directorio E:\Shared\Desarrolladores. Este directorio tiene los permisos que haya heredado por defecto de su directorio padre. En realidad, estos permisos locales son abiertos, aunque no permiten escritura a Desarrolladores.

En la ACL no está el grupo Desarrolladores, sin embargo está el grupo Usuarios que tiene permiso de lectura y ejecución.

Para que los desarrolladores puedan tener control total, tendremos que dárselo en los permisos del directorio.

El grupo Desarrolladores ya puede realizar operaciones de lectura y escritura.

No obstante… según los permisos cualquier usuario podrá acceder para leer, es decir perdemos la Confidencialidad.

Si quisiéramos podríamos configurar los permisos locales de forma restrictiva y los remotos de forma más abierta. Esto es lo que vamos a hacer. Vamos a quitar los permisos de acceso a los Usuarios del dominio. Podemos dejar a los administradores y System para facilitar el mantenimiento de los directorios, pero quitamos a Usuarios.

Según esta configuración de permisos, aparte de los Administradores y el sistema, tan solo podrán acceder los usuarios del grupo Desarrolladores.

Con esta configuración, que sería la que deberíamos haber hecho inicialmente, podemos utilizar una configuración de acceso a través de la red mucho más sencilla. Por ejemplo, dejar que todos los usuarios del dominio tengan acceso de control total sobre el recurso.

Configuración que usamos al principio

¿Cómo es posible? Todo el mundo podría acceder a través de la red, pero al llegar al directorio concreto en el sistema de ficheros, el sistema operativo comproibará los permisos locales y es ahí dónde si no es miembro del grupo Desarrolladores (Administradores o System) no podrá hacer nada. Al final, se aplican los permisos más restrictivos.

Permisos reales = LoMasRestrictivo(Permisos locales + Permisos remotos)

Dejar una respuesta