educatica!

educación, informática y demás

Clases de informática, Informática, Sistemas operativos

Windows 10 – Usuarios, grupos y permisos

Primeros pasos con el sistema

Vamos a hacer algunas cosillas con Windows 10 recién instalado. Podemos quitar «el cable de red» en la máquina virtual para que el sistema vaya un poco más fluido. Si necesitamos red más adelante, podemos volver a conectarlo.

Lanzamos el explorador de windows.

Al no ser un fichero de texto plano, lo que nos muestra es algo raro. La información está en el fichero, pero está guardada con algún formato propio, no en texto plano (ASCII).

Vamos a ver las propiedades del fichero.

Botón derecho en el botón de Windows, configuración

alfredoff

Ahora desde panel de control

La tercera forma de crear cuentas de usuario sería utilizando la herramienta administrativa, Administración de equipos.

La flecha hacia abajo nos indica que esas cuentas están deshabilitadas, es decir existen pero no se puede iniciar sesión con ellas.

Vamos a ver las propiedades del usuario alumno, que es el que hemos creado durante el proceso de instalación y que, por tanto, tiene permisos de administrador del sistema.

La cuenta de alumno tiene permisos de administración porque pertenece al grupo Administradores.

Este grupo es un grupo de usuarios especial que tiene casi todos los permisos del sistema.

Vamos a crear tres nuevos usuarios: ramonam, jesusrp y monicamz. Para ello pulsamos con el botón derecho en una zona libre del panel central o bien hacemos clic en el menú Acción.

Visión de futuro… también podemos crear cuentas de usuario desde la consola de comandos o símbolo del sistema. Para ello tenemos que abrir un símbolo del sistema como administrador.

Hacemos clic derecho sobre el icono de símbolo del sistema para que aparezca un menú contextual que nos permitirá ejecutar el programa como administrador.

Si nos fijamos el directorio actual o de trabajo no es el perfil del usuario actual, sino que es C:\Windows\system32.

Vamos a utilizar un comando que veremos más adelante, así que vamos a hacer un salto de fe y copiaremos lo que viene a continuación:

Lo que hemos hecho es crear un nuevo usuario (/add) cuyo nombre es anagp y como contraseña utilizará ClaveRoot#20.

También podemos usar net user para comprobar las cuentas de usuario del sistema.

Si vamos a administración de equipos no aparece el nuevo usuario. Esto es porque la información no está actualizada, tenemos que actualizarla seleccionando Actualizar en el menú contextual (botón derecho).

¿Qué ventaja tiene el uso de comandos para crear cuentas de usuario?

La ventaja de los comandos es que podemos crear un script o bien podemos reutilizarlos con los cursores.

¡Los perfiles de los usuarios!

Como sabemos un perfil de usuario es un directorio que almacena los datos, ficheros y directorios, y la configuración de un usuario. Hemos creado unos cuantos de usuarios en Windows, vamos a ver sus perfiles de usuario.

Como también sabemos, los perfiles de ususario en Windows 10 por defecto se guardan en C:\Users.

Solo existe el perfil del usuario alumno, ¿dónde está el resto? Windows solo crea el perfil de un nuevo usuario cuando este incia sesión por primera vez. Por eso ahora mismo no hay más perfiles de usuario creados en el sistema, puesto que no hemos inciado sesión con el resto de usuarios.

Cambiando de usuario

Sin cerrar nuestra sesión, vamos a iniciar sesión en el sistema con otro usuario distinto, por ejemplo marinapg.

En este proceso, el sistema operativo está creando e inicializando el perfil del usuario marinapg.

Vamos a nuestro perfil de usuario y vamos a cambiar opciones de carpeta.

Realmente el perfil del usuario guarda los documentos del usuario y también información de configuración, tanto del sistema como de aplicaciones.

Por ejemplo, las aplicaciones del sistema se guardan en el directorio Archivos de programa que está en el raíz de la unidad C: por defecto. Estos ficheros son los ficheros estáticos de los programas, es decir los ejecutables y recursos necesarios de la aplicación.

Sin embargo, estamos en un sistema operativo multiusuario, varios usuarios comparten el sistema y las aplicaciones instaladas. Los programas no cambian, pero la configuración y datos individuales de cada usuario si. Estos datos se guardan en el perfil de cada usuario, dentro del directorio AppData.

Ahí está la configuración Local de este usuario para las aplicaciones que esté utilizando.

Instalando nuevo Software

Vamos a enredar un poco, vamos a instalar un par de aplicaciones para comprobar cómo estas aplicaciones se instalan en el directorio de programas y, además, guardan datos propios en los perfiles de los usuarios.

Vamos a descargar e instalar Mozilla firefox y después Notepad++.

Lanzamos Microsoft Edge para buscar en www.google.es Mozilla Firefox

Comprobamos en la URL que nos lleve al sitio web del desarrollador.

Descargamos Firefox

Le vamos a dar a guardar para ver dónde se descarga el instalador.

Al abrir carpeta nos llevará a la ubicación en la que se ha descargado el instalador. ¿Qué directorio es?

Hmmm… Aparece Este equipo > Descargas. Pero nos hemos descargado este instalador, porque es un programa de instalación, utilizando la cuenta alumno, lo más lógico es que el fichero esté dentro del perfil de usuario de este usuario.

Vamos a comprobarlo. ¿Cuál es la ruta del perfil de usuario del usuario alumno? Posiblemente, seguro, sea C:\Users\alumno. Vamos a acceder a ese directorio.

Podemos hacerlo directamente desde el explorador de windows en la barra de direcciones.

Vamos a entrar en el directorio Descargas.

Realmente el fichero se ha guardado en el directorio Descargas del perfil del usuario actual, es decir el usuario alumno. No obstante, el sistema operativo no nos indicaba eso, para no complicar o mejor dicho tratar de simplificar el uso del sistema al usuario. Un usuario normal, según Microsoft, no tiene porque saber qué es un perfil de usuario. Sin embargo nosotros como administradores si debemos conocer estos entresijos del sistema.

Bien, ahora vamos a ejecutar el instalador de Mozilla Firefox. Para ello, hacemos doble clic sobre el programa de instalación para que se ejecute.

Aquí nos fiamos de la aplicación. Por eso es importante descargarla del sitio original del desarrollador.

Una vez instalado Firefox , vamos a usarlo para instalar otra nueva aplicación: notepad++.

Antes de seleccionar que versión de notepad++ vamos a descargar, vamos a mirar la versión de Windows 10 que estamos utilizando. Para ello, consultamos Sistema. Podemos utilizar el acelerador de teclado WND + PAUSE. Tambi´én podemos acceder a sistema a través de panel de control, sistema y seguridad, sistema.

Estamos utilizando una versión de 32b de Windows 10

Como estamos usando una versión de 32b vamos a descargar la versión de 32b de Notepad++.

Una vez descargado, podemos acceder a él desde Descargas – directorio Download dentro del perfil del usuario actual.

Instalamos el notepad++ y una vez instalado, los ficheros necesarios para que el programa se ejecute deberán estar en nuestro sistema. La pregunta ahora es, ¿dónde están?

Deberían estar en Archivos de programa. Vamos a mirar en este directorio.

En estos directorios están los ficheros que no cambian, estáticos, de las aplicaciones que acabamos de instalar. Sin embargo, cada usuario del sistema puede tener su configuración personal para estas aplicaciones. Por ejemplo, en el caso de Mozilla Firefox cada usuario del sistema tendrá sus marcadores y sus favoritos. ¿dónde se guarda esta información? En el perfil de cada usuario, posiblemente dentro de algún directorio oculto en el perfil del usuario. Dentro de AppData es una buena opci´ón.

Los ficheros estáticos, ejecutables, librerías, configuración, recursos, etc.

Vamos a configurar el entorno de notepad++ para el usuario alumno con el modo oscuro.

Vamos a cambiar de usuario, por ejemplo a marinapg.

Cambiamos de usuario a marinapg

Si intentamos acceder al perfil de alumno, el sistema no nos va a dejar. Porque ahora mismo somos otro usuario, estamos como el usuario marinapg.

El perfil de marinapg estará dentro de C:\Users con el nombre del usuario, es decir marinapg.

Ahora se muestra el perfil del usuario marinapg.

Para este usuario, la configuración del Explorer no muestra los directorios ocultos como el directorio AppData. Vamos a intentar una cosa, como nosotros sabemos que ese directorio existe, vamos a ponerlo en la ruta del explorador de windows.

Escribimos la ruta del directorio

Que un directorio esté oculto no significa que no se pueda acceder, significa que no se mostrará.

Vamos a ejecutar el programa notepad++ con marinapg.

La interfaz de usuario es distinta de la de alumno.

Configuración de notepad++ para el usuario marinapg

Esta configuración se almacena dentro del directorio personal o perfil del usuario marinapg. en este caso dentro de AppData\Roaming

Volvemos a la cuenta de usuario alumno.

Permisos de acceso en NTFS

Como ya sabemos Microsoft tiene varios sistemas de ficheros nativos. Un sistema de ficheros nativo de un sistema operativo es un sistema de ficheros que se creó para ser utilizado en dicho sistema operativo. En el caso de Microsoft, existen varios sistemas de ficheros nativos, creados para ser utilizados en los sistemas operativos Windows. Los principales para nostros ahora mismo son: FAT32 y NTFS.

FAT32 tiene un par de limitaciones, aparte de la eficiencia, que en muchos casos harán que no lo utilicemos en los sistemas Windows.

  • Limitación de tamaño de fichero. Un fichero en FAT32 como mucho podrá ocupar 4GB.
  • Limitación de permisos. Los ficheros en FAT32 no tienen nigún tipo de permisos de acceso.

Vamos a jugar con los sistemas de ficheros FAT32 y NTFS. Primero vamos a comprobar que sistemas de ficheros utilizan las particiones que tenemos en nuestro sistema.

Lanzamos Administración de equipos y vemos en administración de discos los sistemas de ficheros que usamos.

Vamos a ver si nos queda espacio sin asignar en nuestro disco duro y, si es posible, vamos a crear un par de particiones una con sistema de ficheros NTFS y otra con sistema de ficheros FAT32.

Primero crearemos una partición de 10 GB con sistema de ficheros NTFS.

¿Qué ha pasado?. Esta última partición se muestra dentro de una partición verde!. El programa ha detectado que ya teniamos creadas tres particiones primarias y el límite de particiones primarias en un disco duro con MBR es cuatro. Si hubiera creado la cuarta partción como primaria, no se podrían crear más particiones en este disco duro y quedarían sin asignar unos 60GB que se desperdician.

Lo que ha hecho el programa es crear una partici´ón extendida con los 67 GB que quedaban sin asignar y dentro de esta partición extendida, ha creado una partición lógica.

A efectos de uso, a nosotros nos da igual que las particiones de datos sean primarias o lógicas. El caso es poder utilizarlas para almacenar información.

Vamos al explorador de Windows y nos dirigimos a equipo.

Ahora se muestran dos unidades lógicas nuevas que representan los sistemas de ficheros de las dos particiones que acabamos de crear. Vamos a la partición «Datos» es decir E:

Creamos un nuevo directorio llamado Empresa,.

Dentro de Empresa, es decir E:\Empresa, vamos a crear dos nuevos directorios: alumno y marinapg.

Configurando permisos

Ahora vamos a configurar los permisos de acceso de estos directorios de forma que tan solo el usuario cuyo nombre aparece en el directorio pueda acceder a ellos.

Para ello accederemos a la configuraci´ón de seguridad de cada uno de estos directorio.

Nos vamos a la pestaña Seguridad.

En este cuadro de dialogo podemos comprobar y modificar los permisos de acceso sobre este objeto. En este caso, el objeto es un directorio cuya ruta es E:\Empresa\alumno, como se refleja en el propio cuadro de dialgo.

En la parte superior, aparece un panel con una lista de elementos, usuarios o grupos, sobre los que se establecerán permisos de acceso en este directorio. Esta lista es una lista de control de acceso para este directorio.

Si un usuario no está en la lista de control de acceso de un objeto, fichero o directorio, no tiene ningún permiso.

Los elementos de la lista pueden ser un usuario o un grupo. Para cada elemento de la lista se establecen una serie de permisos que se muestran al seleccionarlo en el panel que aparece en la parte inferior del cuadro de dialogo.

Por ejemplo, segun la configuración que se muestra todos los usuarios miembros del grupo Usuarios autentificados pueden realizar las operaciones que se marcan en el panel inferior.

Cómo podemos modificar estos permisos.

Vamos a aprovechar la configuración que hay, la copiamos para poderla modificar.

Quitamos los grupos Usuarios y Usuarios autentificados.

Ahora mismo nos quedan en la ACL solo dos elementos administradores, que pueden hacer lo que quieran siempre, y System, que representa al sistema.

Sin embargo, nosotros queremos que el usuario alumno pueda acceder con control total.

Si no recordamos el nombre del usuario(s) o grupo(s) podemos buscarlo en Opciones avanzadas..

Ahora seleccionamos los usuarios o grupos que queremos añadir a la ACL (Lista de control de acceso). Al darle a aceptar nos lleva al cuadro de dialogo anterior.

También podríamos haber escrito el nombre del usuario.

Los permisos quedarían de esta forma: En la ACL solo hay tres elementos de seguridad: Administradores, System y alumno. Los tres tienen permisos de Control total. El resto de usuarios y grupos que no están en la ACL no tienen ning´ún permiso. Le damos a aceptar y repetimos el proceso con marinapg.

Quitamos la herencia copiando los permisos establecidos.

Quitamos a los grupos Usuarios y Usuarios autentificados y añadimos a marinapg.

Si ahora intentamos acceder con alumno no nos dejará.. inicialmente.

Si pulsamos continuar, al pertenecer al grupo administradores el usuario alumno, el sistema va a configurar los permisos de este directorio añadiendo al usuario alumno a la ACL. Desde ese momento podrá acceder para realizar cualquier operación.

Vamos a comprobar lo que ha pasado mirando las propiedades del directorio marinapg.

Ahora vamos a copiar el directorio E:\Empresa

Vamos a pegar el directorio E:\Emp`resa en F:\ Ahora vamos a acceder a los permisos de seguridad..

No hay!!!

Por que estamos en un sistema de ficheros FAT32, dónde no hay permisos.

Usuarios y grupos locales

Ya hemos visto como podemos administrar cuentas de usuario local en un sistema Windows 10 utilizando la herramienta administración de equipos. Ahora vamos a trabajar con los grupos de usuarios.

Un grupo de usuario local es un contenedor de usuarios que tiene un nombre que lo identifica. Gracias al uso de grupos los administradores de sistemas podemos establecer permisos de acceso o denegarlos de forma mucho más simple.

Vamos a echar un vistazo a los grupos locales en la herramienta de administración de equipos.

Vamos a acceder a Administración de equipos desde Equipo accediendo al menú contextual haciendo clic con el botón secundario.

Para que nos muestre la opción de Usuarios y grupos locales la herramienta de administración de equipos tenemos que estar utilizando un versión Pro o superior de Windows. En Windows Home no tenemos acceso a estas herramientas

Vamos a echar un vistazo a los grupos.

Si nos fijamos existen varias cuentas de grupo predeterminadas en el sistema que han sido creadas al instalarlo. Estas cuentas se utilizan para proporcionar ciertos permisos en el sistema de forma rápida. Si hacemos a un usuario miembro del grupo administrador, le estaremos dando permisos de acceso avanzados – casi ilimitados – en el sistema. Si añadimos un usuario al grupo Usuarios avanzados, este usuario tendrá algunos permisos extra por encima de los permisos que tengan los usuarios del grupo Usuarios – usuarios estándar.

Si queremos obtener más información sobre qué hace o para qué se utiliza cada uno de estos grupos predeterminados, podemos consultar la ayuda.

Vamos a echar un vistazo al grupo Usuarios.

Como podemos observar los miembros de este grupo son las cuentas de usuario que hemos creado hasta ahora.

Vamos a crear dos grupos de usuarios: Developers y SysAdmins. En el grupo Developers: albertorm, alfredoff , anagp y marinapg; y en el grupo SysAdmins: jesusrp, mariamp, marinagp y monicamz.

Botón derecho sobre un área vacía y seleccionamos Grupo nuevo
Rellenamos el identificador del grupo y una pequeña descripción

En el cuadro de dialogo de selección de usuarios directamente escribimos los nombres de los usuarios a agregar al grupo separados por «;».

Al pulsar aceptar, el sistema busca a estos usuarios y los hace miembros del grupo.

Si ahora pulsamos el botón Crear se creará el grupo y mostrará un nuevo cuadro de dialogo vacío para que sigamos insertando nuevos grupos locales.

Ahora vamos a buscarlos, porque no recordamos bien quienes eran los miembros de este grupo.

Como ya hemos terminado, después de pulsar el botón crear, cuando aparezca el cuadro de dialogo vacío pulsamos cerrar.

Supongamos que queremos cambiar de grupo al usuario anagp, lo sacamos de Developers y lo vamos a hacer miembro de SysAdmins.

Para ello accedemos a propiedades del grupo Developers, seleccionamos al usuario y pulsamos el botón Quitar. Después tendremos que aceptar para que se apliquen los cambios.

Ahora vamos a añadir al usaurio al grupo SysAdmins, para ello podriamos utilizar propiedades del grupo SysAdmins y Agregar al usuario. No obstante, esta vez utilizaremos la opción Agregar a grupo.. del menú contextual que nos muestra al pulsar con el botón secundario sobre un grupo.

Podemos pulsar aplicar para que se apliquen los cambios y continuar trabajando en este cuadro de dialogo, pero si hemos terminado de trabajar con él lo ideal es pulsar aceptar.

¿Para qué valen los grupos? – Caso práctico de usuarios, grupos y permisos

El uso de grupos de usuario facilita la administración de permisos del sistema a los administradores. Gracias al uso de grupos podemos establecer permisos de acceso que se aplicarán a todos los miembros de un grupo sin importar o sin conocer a priori que usuario pertenecen a dicho grupo.

A medida que el sistema evoluciona, los miembros de los grupos pueden cambiar, pero los permisos establecidos utilizando esos grupos no tienen por qué hacerlo y si hubiera que cambiarlos, bastaría con cambiar los permisos para todo el grupo.

Esto que estáis leyendo es teoría, la mejor forma de entender la teoría es utilizarla, así que vamos a practicar con un pequeño caso práctico.

Dentro del directorio E:\Empresa, vamos a crear los directorios Developers, SysAdmins, Privado y Publico.

Nos gustaría contar con una serie de directorios con cierto nivel de seguridad en el sistema. Estos directorios son los directorios que acabamos de crear que tendrán las siguientes características:

  • Developers. A este directorio tan solo podrán acceder los miembros del grupo Developers. Podrán realizar cualquier tipo de operación de lectura y escritura – Control total.
  • SysAdmins. A este directorio tan solo podrán acceder los miembros del grupo SysAdmins. Podrán realizar cualquier tipo de operación de lectura y escritura – Control total.
  • Privado. A este grupo tan solo podrán acceder los usuarios alfredoff y marinapg pudiendo realizar cualquier operación.
  • Publico. A este grupo tan solo podrán acceder los miembros del grupo Developers y SysAdmins pudiendo realizar cualquier operación – Control total.

Primero creamos los directorios. Para agilizar la creación de directorios podemos utilizar el acelerador de teclado CTRL+SHIFT+N lo que creará un directorio dentro del directorio actual.

Ahora establecemos los permisos en cada uno de ellos. Empezaremos con Developers.

Para acceder a la configuración de permisos, pulsamos con el botón derecho sobre el directorio, seleccionamos propiedades y nos vamos a la pestaña de Seguridad.

Según la configuración actual, cualquier usuario del sistema puede acceder a este directorio pudiendo realizar cualquier operación sobre él.

Nosotros queremos configurar este directorio para que tan solo el grupo Developers pueda realizar cualquier operación. Lo primero que tenemos que hacer es quitar la herencia, es más lo primero que deberíamos hacer es comprobar si los permisos son heredados – nosotros lo sabemos, son heredados, pero vamos a verlo…

Vamos a tener que entrar en Opciones Avanzadas si queremos quitar los grupos de usaurios de la ACL si hay herencia, así que entramos de todas formas y lo comrobamos.

Vamos a Deshabilitar la herencia… En las opciones que se muestran elegimos, esta vez por cambiar, que borre la lista.

En este cuadro de dialogo se trata de dar solución al problema que se genera cuando se quita la herencia con los permisos del directorio, el sistema no sabe qué permisos establecer. Aquí tenemos dos opciones, bien copiamos los permisos que teníamos en la herencia como propios y luego los modificamos o bien se quitan todos los permisos.

Esta vez, sin ser lo más habitual, vamos a quitar todos los permisos por practicar.

Los permisos están en blanco, vacíos, ahora agregamos usuarios o grupos sobre los que establecer permisos.

«Los permisos se establecen con grupos, siempre con grupos, salvo que sea necesario utilizar un usuario concreto… y aún así»

En este caso, como tan solo el grupo Developers será el que tenga acceso con control total, tan solo tenemos que añadir a este grupo.

Si nos fijamos el único elemento de la ACL es Developers, que tiene control total. El resto de usuarios del sistema que no pertenezcal grupo Developers no tendrá ningún permiso.

«Solo los usuarios y grupos que aparezcan en la ACL tendrán permisos sobre el recurso.«

En versiones anteriores de Windows era recomeendable, para evitar trabajo extra en un futuro, dejar en la lista de control de acceso a los Administradores. En este caso, para practicar y ver los efectos, vamos a dejar solo al grupo Developers.

Todo ha funcionado correctamente y si intentamos acceder con un usuario que es miembro de administradores a dicho directorio el sistema lo añade a la ACL con todos los permisos, como hemos visto anteriormente.

SysAdmins

Privado

Publico

Vamos a comprobar que esto funciona, para ello cambiaremos de usuario a anagp, que pertenece al grupo SysAdmins

Si intentamos entrar en el directorio alumno se nos muestra este mensaje:

Nos pide acceso como administrador.

Vamos a intentar entrar en SysAdmins y crear un directorio llamado AnaGP

Si intentamos entrar en Developers o en privado no podremos hacerlo.

Vamos a acceder a Publico y cremos un directorio llamado AnaGP.

Volvemos a la cuenta de alumno y accedemos a Opciones avanzadas de seguridad del directorio Developers.

En acceso efectivo podemos comprobar qué permisos tiene un usuario del sistema o un grupo. Pulsamos seleccionar un usuario y elegimos a anagp

Podemos cambiar de usuario pulsando de nuevo en Seleccionar un usuario y pulsando en Ver acceso efectivo para que se actualice la información.

Vamos a comprobar un grupo, en este caso SysAdmins

La ventaja que tiene utilizar grupos en las ACL de permisos de acceso es que una vez establecidos los permisos utilizando grupos, ahora podemos proporcionar permiso de acceso a un usuario tan solo añadiéndolo al grupo.

Por ejemplo, si el usuario anagp, en los próximos meses va a trabajar como una desarrolladora en la empresa, pero también como administradora de sistema, tan solo tenemos que añadir a anagp al grupo Developers para que tenga los mismos permisos que el resto de miembros del grupo.

Vamos a comprobar los permisos sobre Developers

Los permisos no se han cambiado, sin embargo, al haber hecho miembro al usuario anagp del grupo Developers, para este usuario el acceso es distinto.

ACLs mejor solo con grupos

Ya hemos comentado en varias ocasiones que es muy recomendable utilizar solo grupos de usuarios en las ACL de recursos. Esto es así porque facilita mucho su mantenimiento.

No obstante, habrá ocasiones en las que no nos quede más remedio que utilizar cuentas de usuario. Por ejemplo si nos dicen que tan solo los jefes de departamento de SysAdmin y Developers, que son marinapg y alfredoff, pueden acceder, tendremos que utilizar usuarios individuales… o no.

Si es necesario y lo ves conveniente, hay varios usuarios en una ACL con los mismos permisos, se puede crear un grupo, añadir los usuarios al dicho grupo y darle los permisos. Por ejemplo un grupo llamado Directorios o un grupo AccesoPrivado que sea solo para los usuarios que tengan acceso a dicho directorio.

Existe una metodología llamada estrategia AGDLP que se utiliza sobre todo en entornos de Sistemas Operativos en Red. Esta estrategia consiste en crear tantos grupos (de dominio local) como sea necesario para gestionar los permisos de acceso a un recurso. Esto lo estudaremos más adelante.

Ahora mismo, a nosotros nos vale con que nos quedemos con el uso de grupos siempre que sea posible y solo en casos puntuales usar cuentas de usuario en las ACLs.

¿Administradores?

Voy a añadir a ramonam como administrador y voy a hacer un par de pruebas… Lo vamos a hacer con comandos, para que veáis como se puede hacer usando comandos.

Usando comandos las operaciones son más rápidas, no hay que lanzar administración de equipos, seleccionar grupos, seleccionar Administradores y agregar al usuario. Tan solo con un comando lo hemos añadido.
Vamos a comprobar que realmente ha funcionado, aunque ya lo habíamos hecho con el comando «net localgroup administradores», pero ahora lo haremos desde la herramienta gráfica.

Cambiamos de usuario a ramonam.

Pero… ¿por qué con el usuario alumno si podía acceder a cualquiera de los directorios y con ramonam no podemos si también es administrador?

El tema está en los permisos, de nuevo. Alumno es el usuario propietario de los directorios con los que hemos estado trabajando, puesto que ha sido este usuario el que ha creado los directorios. Por eso, cuando el sistema nos mostraba la ventana de que Actualmente no tenemos permiso, al pulsar en Continuar, se podía añadir a la ACL al usuario alumno, porque es el propietario.

No obstante, ramonam no es el propietario del directorio y por tanto no puede agregarse a la ACL.

¿Qué podemos hacer? Vamos a editar la seguridad del directorio.

¡Si somos administradores!. Opciones avanzadas…

Podemos cambiar el propietario del objeto y, una vez que somos el propietario del objeto, podemos cambiar las ACLs

¡Por fin!

¿Qué ha pasado? Como ahora el propietario es ramonam, el usuario actual, el sistema ha podido cambiar la ACL añadiendo una nueva entrada: ramonam, a la que le habrá dado control total.

Por este tipo de operaciones es recomendable dejar a Administradores en la ACL con control total, sobre todo si somos administradores, para evitar tener que realizar trabajo extra para acceder a un directorio :D.

Realmente, no siempre es buena idea dejar a Administradores en la ACL de un directorio. Si queremos dotar de seguridad a ciertos directorios, es recomendable NO meter a los Administradores en la ACL: Por ejemplo en los perfiles de usuario o directorios privados.

Deja un comentario

Tema creado por Anders Norén