Páginas

Mostrando entradas con la etiqueta ACLs. Mostrar todas las entradas
Mostrando entradas con la etiqueta ACLs. Mostrar todas las entradas

11 enero, 2022

Instalar y configurar Microsoft LAPS para evitar movimientos laterales (Local Administrator Password Solution)

Microsoft LAPS (Local Administrator Password Solution) se trata de una herramienta de Microsoft que pone solución a la gestión de contraseñas administrador local de los equipos unidos a un dominio. 

Entendiendo el riesgo de seguridad y escenarios comunes en las organizaciones

En la mayoría de compañías es una práctica común establecer la misma contraseña para la cuenta del administrador local en todos los equipos que forman parte de un dominio, principio de localidad entre máquinas, ya puedan ser clientes o servidores (exceptuando los Domain Controller que por defecto carecen de una cuenta de administrador local).

Se considera una reducción del riesgo alto la implementación de este tipo de soluciones que evita configurar una misma contraseña para la cuenta de administrador local en todas las máquinas, al hacer que cada máquina use una contraseña diferente y compleja para la cuenta de administrador local se establece una importante medida defensiva que evita principalmente el movimiento lateral entre equipos (pivoting), una vez se obtuviese una contraseña o un hash NTLM válido en el que poder realizar técnicas de Pass the Hash (PtH).

Este tipo de soluciones es conocida por muchas empresas pero implementada por muy pocas en la realidad, no tanto por su complejidad sino por el impacto significativo que supone en la operativa diaria de gestión del cambio en la administración remota de los equipos, despliegues automáticos mal configurados en las que se haga uso de la contraseña de administrador local parametrizada, mantenimiento en los posibles endpoints que se encuentren fuera de la oficina en la que la conexión con la VPN a la red central se realice en pocas ocasiones y sea necesario gestionarlo a través de una cuenta local privilegiada, etc. 

En cualquier caso para entornos on-premise existen alternativas de gestión remota para estos equipos como puede ser la creación de un grupo en AD en el cual se añada a través de GPO al grupo administradores locales de las máquinas de modo que cada usuario que pertenezca a ese grupo principal pueda autenticarse en el equipo con su contraseña de dominio de forma nominal. En el caso de disponer de un entorno híbrido integrado con algún proveedor cloud MDM no solo se simplifica la gestión de los equipos sino que se gana en monitorización y administración de seguridad de los mismos.

Características de LAPS

LAPS determina si la contraseña de la cuenta del administrador local ha caducado. Si la contraseña ha caducado, cambia la contraseña del administrador local a un nuevo valor aleatorio y transmite la nueva contraseña y la fecha de caducidad a Active Directory donde se almacena en unos atributos especiales asociados con el objeto de equipo de AD. Las contraseñas se almacenan en Active Directory y están protegidas por listas de control de acceso (ACLs) por lo que solo los usuarios elegibles pueden leerlas o solicitar su restablecimiento.
  • Gestión centralizada y almacenamiento de las contraseñas de los administradores locales de forma segura dentro de AD DS.
  • Las contraseñas se almacenan en valores de atributos que sólo estarán visibles para los usuarios o grupos de seguridad que se definan a través de Active Directory.
  • Las contraseñas de los administradores locales son únicas en cada máquina.
  • Las contraseñas se cambian de forma automática, estableciendo contraseñas aleatorias y complejas en base a patrones que previamente estén definidos en su propia plantilla GPO (AdmPwd.admx).
  • Transmite las contraseñas al cliente de manera segura y cifrada.
  • Permite controlar los permisos en usuarios o grupos para el acceso a la visualización y restablecimiento de las contraseñas.
  • Dispone de sus propios ID de eventos para su análisis en auditorías.

Instalación de LAPS

Instalador de LAPS (Local Administrator Password Solution).

En uno de los controladores de dominio, preferiblemente un PDC (Primary Domain Controller), instalamos y agregamos las características del cliente pesado, módulo de PowerShell y las plantillas del editor de políticas de grupo.

GPO CSE (Client-Side Extension) solo deberá estar presente en cada endpoint gestionado.

Figura 1: Instalar características para la gestión LAPS.

Figura 2: LAPS instalado.

Importamos el módulo AdmPwd.ps, se actualiza el esquema de Active Directory, y se definen las unidades organizativas donde se quieran aplicar los permisos para la gestión de LAPS.

Import-Module AdmPwd.ps
Update-AdmPwdADSchema
Set-AdmPwdComputerSelfPermission -Identity "<OU_AD>"

Figura 3: Importar módulo AdmPwd y actualizarlo en el esquema de AD.

El permiso de escritura en los atributos ms-Mcs-AdmPwdExpirationTime y ms-Mcs-AdmPwd de todas las cuentas del equipo tiene que ser añadido a la cuenta integrada. Esto es necesario para que la máquina pueda actualizar la contraseña y la fecha de caducidad de su propia contraseña de administrador local gestionada.

Para visualizar todos los cmdlets disponibles de un módulo podemos usar Get-Command y especificar el módulo.
Get-Command -Module AdmPwd.ps
Figura 4: Ver todos los cmdlets disponibles de un módulo.

Configuración GPO LAPS en Active Directory

Se crea una nueva GPO desde el editor de administrador de políticas de grupo (gpmc.msc). Al instalar la plantilla AdmPwd.admx de LAPS se añaden las nuevas políticas para establecer su configuración.
Computer Configuration > Polices > Administrative Templates > LAPS
Se habilita la política y en el caso de que el administrador local no sea el nombre por defecto (Administrator o Administrador) indicamos el nombre de la cuenta local tipo administrador que esté configurada en los equipos del dominio y los parámetros de las passwords como la: complejidad, longitud y expiración.

Figura 5: Crear y configurar GPO LAPS.

Desplegar el MSI de LAPS al resto de equipos del dominio a través de GPO

Es necesario desplegar el mismo instalador al resto de los equipos del dominio donde se necesite implementar LAPS ya sea en su versión de x64 o x86 y solamente con la característica por defecto habilitada.

La operativa de despliegue dependerá de la herramienta que se estemos usando para la gestión de endpoints de la infraestructura ya sea con SCCM System Center, Microsoft Intune, Puppet, etc.
msiexec /i <PATH>\LAPS.x64.msi /quiet
msiexec /i <PATH>\LAPS.x86.msi /quiet
Para este ejemplo al tratarse de un fichero Microsoft Installer .msi se puede desplegar directamente a través de otra GPO.
Computer Configuration > Policies > Software Settings > Software installation
Se indica la ruta donde está el instalador, el tipo de deployment será "Assigned" (sin modificaciones en sus características de instalación) ya que con la configuración por defecto solo instalaría la característica del cliente (GPO CSE).

Figura 6: Desplegar LAPS a los equipos del dominio a través de GPO. 

Funcionamiento y administración de LAPS

En los objetos tipo "Computer" de la unidad organizativa de Active Directory donde se delegaron los permisos para LAPS podemos comprobar que se han añadido dos nuevos atributos: 
  • ms-Mcs-AdmPwd: Almacena la password local del equipo.
  • ms-Mcs-AdmPwdExpirationTime: Tiempo en la que la password expirará y será renovada por otra password aleatoria cumpliendo los requisitos establecidos en la GPO.
A través del Editor de interfaces de servicios de Active Directory ADSI (adsiedit.msc) comprobamos como se han creado estos atributos y ver su valor desde la pestaña de editor de atributos de la propia ficha del objeto en la consola de Active Directory (dsa.msc).

Figura 7: Atributos de objeto donde se almacenará la password local aleatoria y rotatoria.

LAPS UI es la interfaz gráfica para una gestión más sencilla de LAPS donde podemos buscar por hostname un equipo del dominio para visualizar su password de administrador local, fecha de expiración y también restablecer su password (en caso de que tengamos permisos de escritura sobre los atributos comentados anteriormente).

Otra forma de visualizar la passwords es a través de PowerShell haciendo uso de los cmdlets que se importan a través del módulo AdmPwd.ps en la instalación de LAPS.
Get-AdmPwdPassword <HOSTNAME> | fl
Get-AdmPwdPassword <HOSTNAME>.Password
Figura 8: LAPS UI para ver y restablecer las passwords locales de los equipos de AD.

También es posible restablecer la password de administrador local de un equipo del dominio desde PowerShell.
Reset-AdmPwdPassword -ComputerName:<HOSTNAME>

Establecer permisos específicos según roles (RBAC)

Solo los usuarios privilegiados del dominio como los Domain Admins tienen permisos de lectura y escritura sobre los valores de los atributos donde se almacena la password y la fecha de expiración. 

En el caso de que se necesite conceder la capacidad de poder ver o editar estos valores de atributos a usuarios que no sean administradores, sino usuarios menos privilegiados a nivel de dominio que proporcionen mantenimiento y soporte a otros empleados de la compañía, se pueden crear grupos de seguridad en Active Directory de solo lectura (LAPS_R) y otro de lectura y escritura (LAPS_RW) donde se puedan asignar estos usuarios de soporte y de esta manera tener un control de permisos más granular.

En este caso asignamos el permiso de solo lectura sobre estos atributos al grupo "LAPS_R". Es posible conceder estos permisos de dos modos: 

Una forma automática a través del siguiente cmdlet donde se hará referencia el grupo de AD y la OU.
Set-AdmPwdReadPasswordPermission -Identity "<OU_AD>" -AllowedPrincipals "<Grupo_Solo_Lectura>"
Con el siguiente cmdlet verificamos la asignación de permisos asignados a la OU.
Find-AdmPwdExtendedRights -Identity "<OU_AD>"
Figura 9: Establecer un grupo de permiso de lectura para LAPS. 

La otra opción sería hacerlo de manera manual estableciendo las DACLs de la OU. En este caso agregando el grupo LAPS_R a las propiedades de seguridad de la OU y en los permisos avanzados permitir las siguientes ACEs "Read ms-Mcs-AdmPwd" y "Read ms-Mcs-AdmPwdExpirationTime".

Figura 10: LAPS - ACEs de lectura establecida a un grupo en una OU de AD.

En el caso que necesitemos agregar un grupo de usuarios para poder restablecer passwords, es decir otorgar permisos de escritura sobre los valores de los atributos de LAPS, usaremos el siguiente cmdlet.
Set-AdmPwdResetPasswordPermission -Identity "<OU_AD>" -AllowedPrincipals "<Grupo_Lectura_Escritura>"

Comprobar los permisos establecidos

Para comprobar de los permisos asignados anteriormente, el usuario de dominio "user2" no forma parte del grupo "LAPS_R" por lo tanto desde la consola de Active Directory no podrá visualizar los atributos de LAPS del equipo "PC10D2".

Figura 11: Comprobación de lectura sin permisos en el atributo de password de AD.

Para cambiar esto y conceder permisos de lectura. Se asigna el usuario "user2" al grupo "LAPS_R" de AD, se reinicia sesión con este usuario para aplicar los cambios y vemos como es posible visualizar desde el editor de atributos del tipo de objeto equipo el valor de la contraseña y la fecha de expiración. 

Figura 12: Comprobación de lectura correcta en el atributo de password de AD

Auditoría de eventos LAPS

La activación de auditoría de los usuarios que consultan y leen con éxito la contraseña de Administrador local de un equipo se puede activar mediante el siguiente cmdlet parte del módulo de AdmPwd.ps. 
Set-AdmPwdAuditing -OrgUnit: <OU_AD> -AuditedPrincipals: <GRUPO/USUARIO>
Cuando una contraseña se lee con éxito, se registra un ID de evento 4662 en el registro de seguridad del controlador de dominio.

Figura 13: Auditar eventos LAPS de consulta y lectura exitosa de la contraseña.

Saludos!

12 febrero, 2020

Hardening Linux: Listas de control de acceso en directorios o ficheros [setfacl y getfacl]

Las ACL en Linux son, como en cualquier otro sistema operativo, listas de control de acceso (Access Control List) que nos permiten especificar que usuarios, grupos o procesos del sistema se les otorga unos permisos específicos a los objetos, como pueden ser directorios o ficheros del sistema.

Por defecto en los sistemas de ficheros ext* las ACL ya se encuentran habilitadas. Existen dos comandos para su gestión:
  • getfacl: Muestra información de los permisos de ficheros y carpetas.
  • setfacl: Establece o modifica las ACL de dichos ficheros y carpetas.
Para conocer el detalle de los argumentos disponibles tanto en getfacl como setfacl podemos consultar su ayuda con man.

Para entender mejor su funcionamiento pondré un escenario muy sencillo como ejemplo.

Escenario

Estructura de directorios:
├── Común
├── Pepe
└── Juan 
Con los siguientes usuarios y grupos:

- Usuarios: Pepe, Juan
- Grupo: Compartido
# tail -n 2 /etc/passwd
Pepe:x:1003:1003::/home/Pepe:/bin/bash
Juan:x:1004:1004::/home/Juan:/bin/bash
Maria:x:1005:1005::/home/Maria:/bin/bash
# tail -n 3 /etc/group
Compartido:x:1000:Pepe,Juan
Pepe:x:1003:
Juan:x:1004:
Maria:x:1004:


¿Qué tipo de permisos se deberían aplicar en este escenario?

1. Cada usuario puede acceder su carpeta con permisos de lectura, escritura y ejecución. 
2. Pepe no tendrá ningún tipo de permisos en la carpeta de Juan. Sin embargo, Juan solo tendrá acceso de lectura sobre la carpeta de Pepe. 
3. Todos los usuarios pertenecen al grupo llamado "Compartido", este grupo tendrá acceso total al directorio "Común".
4. Cualquier otro usuario creado en el sistema (Maria) no podrá acceder a ningún recurso. Excepto el usuario root, que si tendrá acceso total para poder modificar permisos y administración de los recursos.

Establecemos los permisos basados en ACLs

# ls -lh
total 12K
drwxr-xr-x 2 root root 4.0K Feb 12 17:53 Común
drwxr-xr-x 2 root root 4.0K Feb 12 17:53 Juan
drwxr-xr-x 2 root root 4.0K Feb 11 23:13 Pepe 
# setfacl -m o::--- Común/ ; setfacl -m o::--- Pepe/ ; setfacl -m o::--- Juan/
# setfacl -m g:Compartido:rwx Común/
# setfacl -m u:Juan:rwx Juan/ ; setfacl -m u:Pepe:--- Juan/
# setfacl -m u:Pepe:rwx Pepe/ ; setfacl -m u:Juan:r-- Pepe/ 

Después de establecer las ACLs podemos apreciar que al listar los directorios en formato lista se añade un nuevo signo "+" en los permisos de Unix, esto nos indica que ese directorio o fichero tiene más información sobre permisos y que podemos ver con getfacl.
# ls -lh
total 12K
drwxr-xr-x+ 2 root root 4.0K Feb 12 17:53 Común
drwxr-xr-x+ 2 root root 4.0K Feb 12 17:53 Juan
drwxr-xr-x+ 2 root root 4.0K Feb 11 23:13 Pepe  
# getfacl *
# file: Común
# owner: root
# group: root
user::rwx
group::---
group:Compartido:rwx
mask::rwx
other::---
# file: Juan
# owner: root
# group: root
user::rwx
user:Pepe:---
user:Juan:rwx
group::---
mask::rwx
other::---
# file: Pepe
# owner: root
# group: root
user::rwx
user:Pepe:rwx
user:Juan:r--
group::---
mask::rwx
other::---


Comprobamos que las reglas se establecieron correctamente

Usuario Pepe
root@rpi:~# su - Pepe
Pepe@rpi:~$ cd /Recursos/

Pepe@rpi:/Recursos$ touch Pepe/test-pepe
Pepe@rpi:/Recursos$ touch Juan/test-pepe
touch: cannot touch 'Juan/test-pepe': Permission denied
Pepe@rpi:/Recursos$ ls Juan/
ls: cannot open directory 'Juan/': Permission denied
Pepe@rpi:/Recursos$ touch Común/test-pepe

Pepe@rpi:/Recursos$ tree -pugh
.
├── [drwxrwx--- root     root     4.0K]  Común
│   └── [-rw-rw-r-- Pepe     Pepe        0]  test-pepe
├── [drwxrwx--- root     root     4.0K]  Juan [error opening dir]
└── [drwxrwx--- root     root     4.0K]  Pepe
    └── [-rw-rw-r-- Pepe     Pepe        0]  test-pepe
3 directories, 2 files

Usuario Juan
root@rpi:~# su - Juan
Juan@rpi:~$ cd /Recursos/

Juan@rpi:/Recursos$ touch Juan/test-juan
Juan@rpi:/Recursos$ touch Pepe/test-juan
touch: cannot touch 'Pepe/test-juan': Permission denied
Juan@rpi:/Recursos$ ls Pepe/
ls: cannot access 'Pepe/test-pepe': Permission denied
test-pepe
Juan@rpi:/Recursos$ touch Común/test-juan

Juan@rpi:/Recursos$ tree -pugh
.
├── [drwxrwx--- root     root     4.0K]  Común
│   ├── [-rw-rw-r-- Juan     Juan        0]  test-juan
│   └── [-rw-rw-r-- Pepe     Pepe        0]  test-pepe
├── [drwxrwx--- root     root     4.0K]  Juan
│   └── [-rw-rw-r-- Juan     Juan        0]  test-juan
└── [drwxrwx--- root     root     4.0K]  Pepe  [error opening dir]
3 directories, 3 files

Usuaria Maria
root@rpi:~# su - Maria
Maria@rpi:~$ cd /Recursos/

Maria@rpi:/Recursos$ touch Común/test-maria
touch: cannot touch 'Común/test-maria': Permission denied
Maria@rpi:/Recursos$ touch Pepe/test-maria
touch: cannot touch 'Pepe/test-maria': Permission denied
Maria@rpi:/Recursos$ touch Juan/test-maria
touch: cannot touch 'Juan/test-maria': Permission denied
Maria@rpi:/Recursos$ ls Común/ ; ls Pepe/ ; ls Juan/
ls: cannot open directory 'Común/': Permission denied
ls: cannot open directory 'Pepe/': Permission denied
ls: cannot open directory 'Juan/': Permission denied

Maria@rpi:/Recursos$ tree -pugh
.
├── [drwxrwx--- root     root     4.0K]  Común [error opening dir]
├── [drwxrwx--- root     root     4.0K]  Juan [error opening dir]
└── [drwxrwx--- root     root     4.0K]  Pepe [error opening dir]
3 directories, 0 files


Backups de las ACLs de directorios o ficheros

Algo interesante es que podemos realizar backups y restauraciones de los permisos ACLs. Siguiedo el escenario anterior.

Para realizar exportar las ACLs del directorio de Juan, usamos el argumento -R.
getfacl -R Juan/ > backup-acl-Juan.txt
Para realizar una restauración de las ACLs del directorio de Juan, usamos el argumento --restore=directorio/fichero.
setfacl --restore=backup-acl-Juan.txt
Esto solamente es un ejemplo muy básico con la idea de mostrar su uso. Lo ideal es aplicarlo en aquellos directorios/ficheros que sabemos que solo deberían acceder determinados usuarios, con el fin de ir fortificando y endureciendo la seguridad en los sistemas de ficheros de nuestros entornos Linux.

Saludos!

15 enero, 2019

Ejecutar WMIC en equipos remotos de la red local (Windows Management Instrumentation)

Si nos surgen problemas para la ejecución sentencias WMIC en máquinas o nodos remotos, mostraré los errores más comunes y como solucionarlos.

Un error puede ser que no esté habilitado las llamadas a procedimientos remotos (RPC).
Error:
Descripción = El servidor RPC no está disponible.
Error - "El servidor RPC no está disponible" (wmic)
Figura 1: Error - "El servidor RPC no está disponible" (wmic).

Otro error común podría ser la falta de permisos para ejecutar WMIC en nodos remotos.
Error:
Descripción = Acceso denegado.
Error - "El servidor RPC no está disponible" (wmic)
Figura 2: Error - "Acceso denegado" (wmic).

Comprobar que el servicio "Instrumental de administración de Windows" (Winmgmt) está habilitado en el tipo de inicio automático y esté en ejecución.

Servicios winmgmt (wmic) en Windows
Figura 3: Servicios winmgmt (wmic) en Windows.

Habilitar la regla por aplicaciones permitidas del firewal (WFAS) de Windows para permitir comunicaciones y llamadas RPC de WMI. Dependiendo cada caso si se trata de una red privada o de dominio.

Reglas del WFAS (Windows Firewall Advanced Security) permitir la comunicación para WMI
Figura 4: Reglas del WFAS (Windows Firewall Advanced Security) permitir la comunicación para WMI.

Verificar que el uso compartido de archivos e impresoras esté activado para el tipo de red según sea el caso. Por defecto en una red de dominio esta característica suele estar activada por defecto cuando un equipo cliente se uno al dominio.

Activar el uso de recurso compartido de archivos e impresoras
Figura 5: Activar el uso de recurso compartido de archivos e impresoras.

Comprobar que en la consola del equipo remoto haya permisos suficientes para el usuario que ejecutará wmic.

Esto se puede modificar en la consola de Microsoft "wmimgmt.msc", en la pestaña de seguridad, se modifican los permisos para permitir la "Llamada remota habilita" y "Ejecutar métodos".

Permisos de seguridad al Control WMI
Figura 6: Permisos de seguridad al Control WMI.

Por último, y algo fundamental según las pruebas que he realizado, es que independientemente de si el equipo cliente remoto en el que se quiere ejecutar WMI forme parte de una red de dominio o una red privada. Será necesario crear un valor en el registro de Windows "LocalAccountTokenFilterPolicy" algo ya comentado en este artículo.

Desde mi punto de vista esto no es aconsejable a métodos de seguridad, no es para nada una buena práctica, pero si se trata de casos puntuales en los que se necesita realizar una serie de acciones remotas simplemente, por seguridad aconsejo volver a eliminar este valor del registro.

Para poder ejecutar este valor en el registro podemos hacerlo ejecutando una CMD en el equipo remoto a través de PsExec (PsTools de Sysinternals). En este artículo se detalla como hacerlo.

El valor LocalAccountTokenFilterPolicy se trata básicamente de "deshabilitar" el UAC (User Account Control) para la ejecución de acciones remotas.

Para añadir el valor LocalAccountTokenFilterPolicy a través de una CMD:
reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f
Para posteriormente eliminar el valor LocalAccountTokenFilterPolicy a través de una CMD:
reg delete HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system /v LocalAccountTokenFilterPolicy /f

En el siguiente ejemplo se puede ver como se ejecuta WMIC remotamente desde un equipo local a un equipo remoto usando "wmic /node", especificando la dirección IP local o el hostname del equipo remoto y un usuario/password con privilegios administrativos en la máquina remota.
wmic /node:ip_hostname /user:usuario /password:password bios get serialnumber
Ejecución remota de "wmic /node"
Figura 7: Ejecución remota de "wmic /node".

Saludos!

06 agosto, 2017

Administrar los permisos de un servicio de Windows sobre un objeto

Definimos objeto a un fichero, carpeta, unidad, etc. Todo aquello en lo que se puedan administrar permisos NTFS en el caso de Windows.

Con los permisos NTFS de Windows podemos gestionar las DACL (Discretionary Access Control List) son lista de control de acceso discrecional en las que se pueden controlar quien es el propietario de un objeto y especifica quién tiene permiso y quién no para acceder a dicho objeto.

Sabemos que se pueden conceder DACL a usuarios locales del sistema, de un dominio, equipos o grupos de usuairos sobre uno o varios objetos (ficheros, carpetas o unidades).

¿Se pueden administrar estos permisos a objetos para un servicio de Windows o de terceros?

Si. Se pueden asignar uno o varios servicios a uno o varios objetos de Windows y establecer permisos sobre ellos. Lo que pasa que no se puede hacer una forma gráfica amigable ni de manera trivial como pasa con los usuarios.

Para conceder permisos a un objeto es necesario conocer el SID (Security Identifier) del usuario, equipo, grupo, etc. Que se va asignar a ese objeto. Por ejemplo en el caso de Windows, buscando el nombre de un usuario y asignándolo a un objeto sería suficiente para administrar las DACL de ese usuario sobre un objeto. De forma subyacente el sistema está reconociendo un SID asociado a ese usuario.

Los SID de los usuarios locales de un equipo se registran en la siguiente rama del registro de Windows.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProfileList
Hay otras formas de conocer los SID de usuarios locales así como también usuarios de dominio y equipos. Para conocer estos SID podemos usar WMIC (Windows Management Instrumentation Command-line).

Para listar todos los usuarios locales filtrando por nombre de usuario y SID.
wmic useraccount get name,sid
Igual que lo anterior pero filtrando un nombre de usuario en concreto.
wmic useraccount where (name='USUARIO') get name,sid
Lo mismo pero para usuarios que pertenezcan a un dominio.
wmic useraccount where (name='USUARIO' and domain='DOMINIO') get name,sid
Con PsGetSid (de Sysinternals) para listar los SID de usuarios locales de equipos remotos y el propio SID de la máquina locales y otras remotas. Para ejecutar cualquier herramienta PsTools de forma remota tendremos que conocer las credenciales de un administrador local o de dominio en la máquina remota.

Comentado todo lo anterior vamos a ver como podemos agregar un servicio a un objeto y gestionar sus permisos.

Lo primero que tenemos que averiguar es el nombre asignado a un servicio. Ya sea de Windows o de una aplicación de terceros la forma de conocerlo sería la misma.

En este caso de ejemplo usaré el servicio de Dropbox para Windows. Abrimos una consola de servicios (services.msc) y buscamos el servicio que queremos utilizar. Cuando abrimos el servicio vemos el apartado "Nombre del servicio" será ese el que usaremos.

Figura 1: Nombre del servicio Dropbox para Windows (DbxSvc).

Para conocer su SID asignado por Windows a un servicio usaremos la herramienta de comandos de Windows SC (Service Controller).
sc showsid DbxSvc
Figura 2: Conocer el SID asignado a un servicio de Windows con SC.

Ahora solo quedaría asociar ese SID a un objeto. De forma gráfica perosnalmente no encontré forma de hacerlo, pero si por la herramienta de comandos de Windows ICACLS. Con la que podemos mostrar y gestionar las listas de control de acceso discrecional (DACL) de un objeto.
En este caso agregaremos a la carpeta llamada "test" (que será el objeto) el servicio de Dropbox mediante el SID obtenido anteriormente.
icacls c:\test /grant *S-1-5-80-315955965-2752282644-3851734118-3415690430-1520210413:(f)
Figura 3: Agregando un servicio a un objeto con ICACLS

Ahora vemos como el servicio DbxSvc ya está integrado en el objeto y podremos manipular los permisos de forma gráfica. 

Figura 4: Administrando de forma gráfica los permisos de un servicio agregado a un objeto.

Saludos!

31 marzo, 2014

Perfiles de usuario en Windows 7 - Definiciones, estructura y comparación con WinXP

Empezamos por decir a groso modo que; cuentas de usuario y perfiles de usuario no es lo mismo, ya que la cuenta vamos a decir y/o entender de algún modo que son las credenciales del usuario y el perfil el contenido en un equipo de este. 

Tipos de Perfiles: Locales, móviles y obligatorios

Perfiles locales (Local Profiles): Es el tipo de perfil que se crea cuando un usuario inicia sesión en un equipo y la información contenida y los cambios realizados solo estarán disponibles en dicho equipo y NO en ningún otro.

El perfil local funciona del siguiente modo:
  • 1.- El usuario inicia sesión.
  • 2.- Windows comprueba la lista de perfiles de usuario en la clave ProfileList si existe o no. En el primer caso, lo usa; en otro caso el sistema realiza una de las siguientes acciones:
  • 2.1.- Si el equipo es un miembro de dominio, Windows busca el recurso compartido NETLOGON en un DC el perfil de usuario predeterminado en la carpeta Default User. Si lo hay, lo copia a %SYSTEMDRIVE%\Usuarios\Nombre_usuario.
  • 2.2.- Si no pertenece a un dominio o Windows no encuentra el perfil en NETLOGON, usa el perfil de usuario predeterminado Local, copiándolo desde: %SYSTEMDRIVE%\Usuarios\Default User a %SYSTEMDRIVE%\Usuarios\Nombre_usuario.
  • 3.- Windows carga la sección del perfil NTUSER.DAT en la clave HKU y enlaza la clave raíz HKCU al mismo.
Cuando el usuario cierra sesión, el sistema guarda los cambios en la carpeta del perfil de usuario. No copia la carpeta de perfil en la red, y también descarga la sección desde el Registro.

Perfiles móviles (Roaming Profiles): Es un tipo de perfil que estará disponible desde cualquier equipo de la red. Los datos o información y cambios realizados se podrán visualizar en cualquier equipo de la red donde se inicie sesión.

Perfiles obligatorios (Mandatory Profiles): (Solo para usuario de dominio en "Active Directory"). Son perfiles de sólo lectura. Para crear un perfil obligatorio, basta con tomar un archivo NTUSER.DAT y cambiarle el nombre por NTUSER.MAN.
En la ventana del usuario de Active Directory, en la ficha "Perfil", especificamos la ubicación del fichero con extensión .MAN. De ese modo, cada vez que el usuario inicie sesión se cargará el perfil ntuser.man, pero NUNCA ser guardará ningún tipo de configuración cuando este cierre sesión.
Esto es una herencia de NT4.0 y hoy es mejor usar las directivas de grupo en su lugar.

El perfil móvil funciona del siguiente modo:
  • 1.- El usuario inicia sesión.
  • 2.- Windows comprueba la lista de perfiles de usuario en la clave ProfileList si existe o no. En el primer caso, el sistema combina la copia del perfil en la red dentro de la carpeta del perfil local; en otro caso el sistema realiza una de las siguientes acciones:
  • 2.1.- Windows comprueba si existe la carpeta de Default User en el recurso compartido NETLOGON de un DC. Si existe, copia la carpeta Default User a %SYSTEMDRIVE%\Usuarios\Nombre_usuario.
  • 2.2.- Si Windows no encuentra la carpeta Default User en NETLOGON , copia %SYSTEMDRIVE%\Usuarios\Default User a %SYSTEMDRIVE%\Usuarios\Nombre_usuario.
  • 3.- Windows carga la sección del perfil NTUSER.DAT en la clave HKU y enlaza la clave raíz HKCU al mismo.
Cuando el usuario cierra sesión, el sistema guarda los cambios en el perfil a la carpeta del perfil local y descarga las secciones de HKU. Después, copia la carpeta de perfil a la ubicación de red especificada. Si esta carpeta ya existe en la red, el sistema combina la local dentro de la copia de red.

A parte de estos tipos de perfiles y de los que se crean cuando el usuario inicia sesión por primera vez en un sistema Windows, también podemos ver otro tipo de perfiles generados por el sistema que podremos definir como:

Tipos de Perfiles especiales

El path de ubicación en el registro de Windows, en el cual podemos encontrar los usuarios por defecto creados por sistema que serían: Public o Acceso público y Default user:
HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\WINDOWS NT\CurrentVersion\ProfileList
En esta clave podemos ver/modificar las rutas de localización por defecto a las que apuntan los directorios de estos perfiles, en el caso de necesitar hacer esto por alguna razón.

Dentro de la carpeta "Users" o "Usuarios" en la raíz C:\. Podemos encontrar los perfiles creados por defecto en Windows 7, para poder visualizarlos todos correctamente tendríamos que tener marcado las opciones de poder "ver todos los ficheros y carpetas ocultas" y "ficheros del sistema ocultos" en las 'Opciones de carpeta' del Explorer.

Acceso Público o Public (Windows 7) o All Users (Windows XP), (Todos los usuarios): Esta carpeta de perfil contiene la configuración que se aplica a todos los usuarios que inicien sesión en el equipo. Contiene una sección de perfil, NTUSER.DAT, que el sistema no carga. Contiene también las carpetas compartidas de documentos y música, accesos del menú de inicio compartidos, accesos directos en el escritorio que apareceran para todos los usuarios y más. 

La clave HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders tiene los vínculos a las subcarpetas de la carpeta del perfil de All Users.

Después otras configuraciones para Acceso Público irían en el path: %systemdrive%\ProgramData es decir en el raíz y no dentro de la carpeta de Acceso Público, esto para el caso de tratarse de Windows 7. En Windows 7 podremos ver un "Default User" con un icono de un "candado en una carpeta", esto es para mantener la compatibilidad con aplicaciones o migraciones de Win 7 a Win XP.

Default (Windows 7) o Default User (Windows XP) Usuario predeterminado: Contiene el perfil de usuario predeterminado que Windows copia cuando crea un nuevo perfil de usuario. Contiene la mayoría de archivos y carpetas que se han visto. Personalizar esta carpeta es una buena vía para iniciar cada usuario que inicia sesión en el equipo con la misma configuración. Windows comprueba primero la existencia de la carpeta de usuario predeterminado en el recurso compartido NETLOGON del servidor antes de usar la misma carpeta local si la copia en red no está disponible. Al personalizarla podemos implementar configuraciones que no queremos administrar. En Windows 7 podremos ver un "Default User" con un icono de un "candado en una carpeta", esto es para mantener la compatibilidad con aplicaciones o migraciones de Win 7 a Win XP.

LocalService (Servicio Local) y NetworkService (Servicio de Red): Son carpetas de perfil para la cuenta integrada de Servicio Local y de Servicio de Red, las cuales usan Service Control Manager para los servicios que no necesitan ejecutarse bajo la cuenta LocalSystem. Son perfiles normales de usuariarios con datos limitados, no lo vemos en el cuadro de diálogo de perfiles de usuario y sus carpetas están super-ocultas. En Windows 7 estas carpetas no se muestran físicamente ni como ocultas, pero existen las cuentas creadas de las mismas en el sistema.

Administrador y/o otros usuarios: Estos son perfiles normales del sistema y depende si ya hubiésemos o no creado dichos perfiles o entráramos alguna vez en ellos.

Carpetas del perfil

En cada perfil creado existe un determinado contenido en su interior que podremos denominar como: las "Carpetas del perfil" muchas de estas permanecen de modo oculto.

Las carpetas de un perfil de usuario contienen los archivos de aplicación por usuario. Por ejemplo, las plantillas instaladas de MS Office y diccionarios personalizados, las cookies almacenadas de IE o navegadores, configuraciones de otras aplicaciones, configuraciones del aspecto del perfil de Windows, accesos directos, etc.

A parte de las ya conocidas en Windows XP, no haré referencia todas las carpetas en profundidad si no que mencionaré las que me parecen más interesantes para la administración y gestión de perfiles de usuario, ya que las típicas

NTUSER.DAT: Es un archivo oculto de registro. Cada archivo NTUSER.DAT de usuario contiene los parámetros de configuración del registro de Windows para esa cuenta en concreto en la cual se almacenan las preferencias del usuario que tenga establecidas a lo largo del tiempo. La configuración de la carpeta de registro "HKEY_CURRENT_USER" está soportada por el actual archivo NTUSER.DAT de usuario.
Este se encuentra en el path del usuario: C:\Users\NOMBRE_USUARIO.

AppData: La cual contiene a tres carpetas: Local, LocalLow y Roaming.

Local
: Denominada así en Windows 7, contiene archivos de aplicaciones que no viajan con el perfil. Los archivos que encontramos aquí son por equipo o demasiado grandes para copiarlos vía red.
En Win XP esta misma carpeta es denominada: Configuración local (Local Settings) y estaba como carpeta oculta en el path: C:\Documents and Settings\%USER%\Configuración local\Datos de programa
  • Datos de Programa (Application Data): Datos específicos de aplicaciones por-equipo.
  • Historial (History): Historial del Internet Explorer.
  • Temp: Archivos temporales por-usuario.
  • Archivos Temporales de Internet (Temporary Internet Files): Archivos desconectados de Internet Explorer.
LocalLow: Es igual que la carpeta 'Local' anterior, pero tiene un nivel de integridad más baja. Por ejemplo, IE8, sólo se puede escribir en la carpeta LocalLow (cuando el modo protegido está activado).

Roaming
: Su contenido son archivos de diversos programas: e-mail, accesos directos, plantillas, etc… Cada distribuidor de software elige que archivos almacena aquí. Todas los temporales, históricos, logs, historiales de conversación de determinadas aplicaciones, plantillas, ficheros que almacenan configuraciones de determinado software, etc. Todo esto y más está guardado en este carpeta. Podremos acceder rápidamente a ella con la variable de entorno %APPDATA%.

Esta carpeta puede redireccionarse a una ubicación de red mediante directivas de grupo. En Win XP esta misma carpeta es Datos de programa (Application Data) en el path: C:\Documents and Settings\%USER%\Datos de programa.

El resto de carpetas cambia un poco la forma de llamarlas y verlas de como era en Windows XP a Windows 7 veremos que existen carpetas ocultas y del estilo de un acceso directo (un tipo de "enlace simbólico"), también llamadas igual que como se llamaban en Win XP. Esto ocurre por motivos de compatibilidad entre sistemas operativos y/o interacción con aplicaciones o migraciones de OS de Win XP a Win 7, de modo que nos ayuda a mantener la integridad y funcionalidad de aplicaciones y sistema operativo.

Por lo que la aclarar este punto anterior no entraré en profundidad en cada una de dichas carpetas restantes situadas en la raíz del perfil, ya que me parece que son suficientemente obvias para explicarlas.

En Windows XP la carpeta SendTo está en la raíz del perfil como oculta: Contiene accesos directos a unidades, carpetas y aplicaciones de destino. Si hacemos doble clic en un objeto y pulsamos en Enviar a, obtenemos una lista de estos destinos, y si pulsamos en cualquiera de ellos el objeto se enviará a esa unidad, carpeta o aplicación. Esta carpeta podemos editarla añadiendo o eliminando accesos directos mapeados a sitios, ya sean paths de alguna ubicación en concreto o atajos para aplicaciones.

En Windows 7, esta carpeta desaparece de la ubicación donde se encontraba en Win XP y pasa al siguiente directorio: C:\Usuarios\%USER%\AppData\Roaming\Microsoft\Windows\SendTo.

Espero que esta entrada aclarase algunas o muchas dudas aquellas personas que las pudiesen tener respeto al tema de como los administra/gestiona Windows.

Saludos!

24 abril, 2011

Permisos NTFS: ACLs en cuentas de usuarios y grupos en Windows

Modificar permisos a usuarios y a grupos sobre objetos, privilegios a cuentas de usuarios y administradores en Windows.

Tenía pensado dividir este artículo en varias partes, ya que es extenso, pero para no tener comentarios en unas entradas y otras sobre el mismo tema, he decido incluir todo lo relacionado en el mismo post. A parte, a la hora de buscar en buscadores y en el blog se reflejará toda la información en un mismo artículo.

Como dije, este artículo es bastante extenso y completo. Por eso, cito un índice con los diferentes apartados o secciones de este post, un índice con enlaces internos (a esta página) que hacen referencia a todos los diferentes apartados.

Índice

Lecturas recomendables


El último enlace al que hago referencia, está muy completo ya que nos dice como modificar permisos de archivos o carpetas a usuarios, y es algo muy parecido a lo que voy comentar posteriormente en este artículo.

1) Definiciones y conceptos

1.A) Acceso a los archivos y directorios

Todo el tema de permisos que aquí muestro y explico se dan gracias al sistema de ficheros: NTFS (New Technology File System), uno de los sistemas de ficheros de Microsoft Windows, que permite un gran avance de seguridad en cuanto a las concesiones de permisos o privilegios de usuarios en Windows.

Herencia: La herencia permite la propagación de ACL posicionadas en objetos contenedores padres a sus hijos. Al crear una ACE, es posible precisar si se va aplicar al objeto, sólo a sus hijos (indicador de herencia solamente o Inherit Only) o al objeto en sí y a sus hijos.

Objetos: Un objeto es simplemente un elemento que puede asegurarse y protegerse mediante permisos. Puede tratarse de un archivo, un directorio, una clave de registro o un objeto de sistema, como una canalización con nombre, un socket, un proceso, un subproceso, etc.

ACL (Access Control List): Es una lista de control de acceso que regula los permisos de acceso a los objetos del sistem. Está compuesta por entradas de controles de acceso ACE

ACE (Access Control Entry): Una entrada de control de acceso es un elemento de una ACL. Una ACE está compuesta por un SID, una máscara de acceso que define los permisos concedidos al SID (ya sean: Lectura, escritura, etc.), un indicador que determina el tipo de ACE y otro indicador que determina a que objetos se refieren estos permisos.
Hay tres tipos de ACE: Acceso concedido, acceso denegado y Audit (para auditar la seguridad del sistema).

SD (Security Descriptor): Un descriptor de seguridad es la estructura vinculada a todo objeto al que se le puede aplicar seguridad que contiene el SID del propietario del objeto, su grupo primario y las dos listas de ACL: DACL y SACL.

DACL (Discretionary Access Control List): Una lista de control de acceso discrecional es la que está controlada por el propietario del objeto. Especifica quién tiene permiso y quién no para acceder a dicho objeto.

SACL (System Access Control List): Una lista de control de acceso de sistema es la que controla la generación de mensajes de auditoría durante los intentos de acceder a un objeto seguro. (Es necesario tener privilegios SE_SECURITY_NAME para modificar una SACL).

SDDL (Security Descriptor Definition Language): Un lenguaje de definición descriptor de seguridad que permite definir y transportar datos almacenados en un descriptor de seguridad en formato de texto.
Por ejemplo, el comando "sc sdshow" muestra el descriptor de seguridad ligado al servicio en formato SDDL.

El orden de interpretación de los permisos es o debería ser el siguiente:
- Accesos denegados explícitos (DENY ONLY).
- Accesos autorizados explícitos (ALLOW ONLY).
- Accesos denegados heredados.
- Accesos autorizados heredados.

Resumen

Un descriptor de seguridad de un recurso contiene el SID del propietario y varias listas de control de acceso. Una ACL es una lista de entradas de control de ACEs, cada una de las cuales identifica una confianza y unos permisos permitidos o denegados.

Las ACLs pueden ser de dos tipos: DACL (Discretionary ACL) o SACL (System ACL). 
  • DACL especifican permisos de acceso -permitidos o denegados- que el propietario del recurso especifica discrecionalmente. 
  • SACL especifican las acciones de confianza que el sistema debe auditar (intentos fallidos o exitosos de acceso según su tipo).
Cada recurso, además de poder incluir sus propias ACLs (ACLs explícitas), puede marcarse para que herede las ACLs de sus recursos antecesores (se indica separadamente para DACL y SACL).

Para determinar si debe concederse un permiso a una confianza del sistema primero ordena las ACEs de las distintas listas. Después las evalúa una a una y cuando encuentra una que se corresponde ya no evalúa el resto.

Si un recurso no tiene DACLs se concede el permiso. Si tiene DACL pero no tiene ACEs se deniega el permiso.

Para ordenar las ACEs el algoritmo tiene en cuenta lo siguiente:
  • Dentro de una lista, las ACEs que deniegan tienen prioridad sobre las que permiten.
  • Las ACLs explícitas tienen prioridad sobre las heredadas.
  • Las ACLs de los padres tienen prioridad sobre las de los abuelos.
Por otra parte:
  • Al anular la herencia el sistema nos permite elegir entre quitar todos los permisos heredados o copiarlos como explícitos.
  • Cuando se crea un nuevo recurso éste hereda todos los permisos (todas las ACLs) de su padre (tanto heredados como explícitos).
  • Al copiar un recurso (o moverlo a otro volumen) creamos un nuevo recurso.
  • Al mover un recurso dentro de un volumen se mantienen los permisos.

1.B) Tipos de cuentas de usuarios (NT AUTHORITY), grupos por defecto en Windows y sus SID

Trusted Installer (Instalador de confianza): No es una cuenta de usuario propiamente dicha, sino que una cuenta de servicio. Su SID (Security Identifier) comienza por S-1-5-80, que corresponde a SECURTIY_SERVICE_ID_BASE_RID. Sirve para ejecutar el servicio que instala los componentes Windows, los hotfixes y los paquetes MSI (Microsoft Installer).

Este SID posee los permisos para todos los archivos de sistema que le permiten actualizar el sistema operativo. TrustedInstaller es un usuario del sistema de "Protección de Recursos de Windows" (WRP Windows Resource Protection), asume el control propietario de ciertos ficheros, carpetas o ciertas claves de registro de Windows para su correcto funcionamiento. No instala programas como tal, como pueda parecer, trabaja bajo el servicio de Windows "Instalador de módulos de Windows" controlado en la clave de registro "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\TrustedInstaller", este habilita la instalación, modificación y eliminación de actualizaciones (Windows Update) y componenetes opciones de Windows, su path físico está en: C:\Windows\servicing\TrustedInstaller.exe.

Tiene acceso completo a los directorios Windows, System32 y Archivos de Programas (Program Files), lo que le confiere permisos necesarios para reemplazar un archivo del sistema cuando ni siquiera los administradores tienen acceso en escritura. De la misma manera, están accesibles en escritura muchas claves del registro que definen clases y objetos COM únicamente en el servicio Trusted Installer. Cuando se llama, el servicio de instalación a MsiExec (fichero que lee la instalación MSI y lanza el asistente).

Creator Group: Utilizado por el subsistema POSIX únicamente, este SID genérico es sustituido durante la evaluación por el grupo principal del propietario del objeto. Concede control total o lo establecidos explícitamente en "permisos especiales" a un objeto sobre un grupo concreto. Esto está más detallado en el apartado: 3.B) Modificar permisos desde la sesión "Usuario raso" (Propietarios de objetos). En la sección de "Propietarios de un objeto".

Creator Owner (SID: S-1-3-0): Este SID genérico es reemplazado por el SID del propietario del objeto durante la evaluación de los permisos. Al igual que el anterior, concede control total o lo establecidos explícitamente en "permisos especiales" a un objeto sobre un grupo concreto. Esto está más detallado en el apartado: 3.B) Modificar permisos desde la sesión "Usuario raso" (Propietarios de objetos). En la sección de "Propietarios de un objeto".

Owner Rights (Derechos del propietario): Es una nueva cuenta (nuevo SID) de Windows Vista y 7. En Windows XP, pero también en Windows 7, el creador de un objeto posee implícitamente el derecho de modificar las ACL en su posible prohibir el acceso a un objeto (un archivo o una clave de registro, entre otros) a un administrador. El administrador tiene derecho a cambiar las ACL para otorgarse los permisos necesarios, como por ejemplo un control total.

A un usuario estándar o raso, ser propietario de un objeto le confiere un control total sobre el objeto e impide que se le pueda restringir el acceso, porque puede manejar y modificar sus ACLs. Un administrador que desee restringir el acceso a un propietario de un objeto deberá, en primer lugar, cambiar el propietario y luego ajustar las ACL del objeto de conformidad con lo deseado.

Windows Vista y Windows 7 introducen, por tanto, un nuevo SID que corresponde a "Derechos del Propietario" (no se corresponde con una nueva cuenta de usuario con la cual es posible iniciar sesión), que puede utilizarse para limitar los derechos del propietario del objeto. Cuando este SID no está en una ACL, se aplica la lógica habitual: el propietario posee los derechos para modificar las ACL de ese objeto. Sin embargo, cuando está presente, el propietario recibe los permisos asociados a este SID.

Se utiliza normalmente para restringir los permisos de los propietarios de forma sencilla y eficaz. Por ejemplo, situando en un directorio los permisos Lectura en el SID derechos del Propietario y lectura/escritura en un grupo dado, el grupo puede crear archivos y directorios que serán de sólo lectura una vez creados, porque el usuario recibirá los derechos del propietario.

Imaginemos que un usuario cambia de servicio, antes podía crear archivos y acceder a ellos en un directorio mediante la pertenencia a un grupo que le daba un control total sobre un directorio dado. Al abandonar el servicio, se le retira de este grupo. Sin embargo, sigue siendo propietario de sus objetos, es decir, de los archivos que creó, y puede, según las ACL establecidas en el directorio, seguir accediendo y modificando las ACL de sus archivos para devolverse a si mismo el control. Si se establece una denegación (DENY) WRITE_DAC en el SID Derechos del Propietario en el directorio raíz, los propietarios ya no pueden cambiar las ACL en los objetos que han creado. Para terminar, cuando un administrador cambia el propietario de un objeto, se deshabilitamos permisos asociados al SID Derechos del Propietario para que un administrador pierda definitivamente el control de un objeto.

Más detalle y un ejemplo en el apartado: 3.B) Modificar permisos desde la sesión "Usuario raso" (Propietarios de objetos). En la parte de "Propietarios de un objeto".

Ahora comentaré un poco los usuarios NT AUTHORITY, son usuarios usados por el sistema para operaciones de privilegios concretos en determinadas funcionalidades, estos usuarios el sistema hace uso de ellos de forma transparente al usuario final.

Figura 1: Usuarios NT AUTHORITY utilizados por Windows 7.

Usuarios autentificados (SID: S-1-5-11): Son Usuarios que pertenecen o forman parte de Active Directory de una red de dominio.

Anonymous Logon (SID: S-1-5-7): Son usuarios que no disponen de una cuenta de usuario en Servicios de dominio de Active Directory, pero que pueden recibir una invitación para participar de forma remota en una conferencia local.

IUSR (SID: S-1-5-17): Este grupo sirve para dar permisos a las cuentas de servicio encargadas de ejecutar los pools de aplicación del servidor Web IIS (Internet Information Services).

Interactive (SID: S-1-5-4): Representa a los usuarios que han abierto sesión localmente en la máquina y que no acceden a un recurso de la máquina a través de la red.

Local Service (SID: S-1-5-19): Los miembros de este grupo tienen permiso para leer el registro de eventos del equipo local.

Dialup (SID: S-1-5-1): Son usuarios conectados a través de una conexión de acceso remoto.

Network (SID: S-1-5-2): Son los usuarios que acceden a un recurso de la máquina a través de la red, a diferencia de los usuarios que han abierto una sesión localmente para acceder a los recursos. No incluye a los usuarios que inicien sesión mediante una sesión de Escritorio remoto (mstsc-Miscroft Terminal Service Connection).

Service (SID: S-1-5-6): Son los usuarios que inician sesión como servicio.

Network service (SID: S-1-5-20): "Servicio de red" es una cuenta utilizada por los servicios que necesitan acceder a recursos en la red bajo la identidad de la cuenta máquina en la cual se ejecutan. Tiene menos privilegios y permisos localmente que el "System Local".

Local service (SID: S-1-5-19): Es una cuenta utilizada por los servicios que necesitan acceder a recursos locales y no por red (se identifica anónimamente en la red). La diferencia entre Local Service y System Local reside en que System Local posee permisos sobre la red (los mismos que Network Service), mientras que Local Service se autentifica anónimamente en la red.
Network Service y System Local se autentifican en Kerberos utilizando la cuenta máquina del equipo definida en el servicio de Active Directory. Muchos servicios de Windows 7 que no necesitan acceder a la red se ejecutan bajo la identidad de Local Service. Este funcionamiento es el que siempre ha existido en los sistemas Microsoft. Con Windows y 2008, nuevas directivas de grupos permiten a la cuenta Local System autentificarse en NTLM en la red, y no de forma anónima. Este comportamiento no está activo de forma predeterminada, sino que es necesario activarlo.

System (SID: S-1-5-18): Representa el sistema operativo. Permite asignar permisos específicos al sistema. Se llama también Sistema Local (Local System). Es la cuenta que tiene más derechos y privilegios en la máquina.

Batch (SID: S-1-5-3): Son las cuentas utilizadas para ejecutar tareas programadas (Control Schedtasks).

Terminal Server User (SID: S-1-5-13): Son los usuario que abren una sesión de terminal server en la máquina.

Remote Interactive Logon (SID: S-1-5-14): Son los usuarios conectados mediante un inicio de sesión de escritorio remoto.

Otros usuarios del sistema para realizar otras funciones determinadas:

Usuarios de Operadores de cifrado: Como sería lógico, los miembros de este grupo tienen permisos para realizar operaciones de cifrado.

Usuarios de Operadores de copia de seguridad: Encargados de realizar las copias de seguridad del equipo programadas o automáticas de Windows o lo que se le hubiese establecido.

Usuarios del monitor de rendimiento: Los miembros de este grupo pueden acceder a los datos del Monitor de rendimiento (perfmon.exe) localmente y en remoto.

Usuarios del registro de rendimiento: Los miembros de este grupo pueden programar el registro de los monitores de rendimiento, activar los proveedores de seguimiento y recoger el seguimiento de eventos simultáneamente de forma local y a través de un acceso a este equipo.

Añado una nota sobre los SID de los usuarios:
  • Administrador: SID: S-1-5-500
  • Invitado: SID: S-1-5-501
  • El resto de usuarios locales, empezarán ordenadamente a partir del siguiente SID: S-1-5-1000, S-1-5-1002 , S-1-5-1003, etc. y así sucesivamente por cada usuario local creado.
Existen muchos más grupos de usuarios predeterminados en Windows, aquí menciono los que para mi son los más usados y relevantes.
Más información sobre los SID (Identificadores de seguridad): http://support.microsoft.com/kb/243330/es

Intentaré explicar de manera clara y sencilla, para que sea entendible por cualquier tipo de usuario: Como modificar ya sea, para conceder o denegar permisos en Windows y como configurar cuentas de usuarios y administradores de Windows.

Existen muchas formas de realizar esto, ya sea por la shell (consola de comandos CMD) de Windows, como de manera gráfica en el sistema. Mencionaré las dos formas de hacerlo, para cada uno de los casos.

Nota: El nombre de usuario que utilizaré para este tutorial será Administrador (por defecto del sistema) y loiswin7 que correrán bajo una máquina virtual con Windows 7 Ultimate.

2) Habilitar o deshabilitar cuenta de Administrador

2.A) De manera gráfica.

[1] - Nos vamos a: Inicio > botón derecho en "Equipo" > Administrar.
Nos aparecerá la ventana de "Administración de equipos".

[2] - Nos vamos a: Usuarios y grupos locales > Usuarios > Administrador > botón derecho "Propiedades".

Se nos mostrará la ventana de "Propiedades: Administrador".
[3] - En la pestaña "General" desmarcamos (para activar la cuenta, en caso contrario marcaríamos el checkbox) el checkbox que dice: "La cuenta está deshabilitada", Aplicamos los cambios y Aceptamos.

[4] - Cerramos la ventana "Administrador de equipos" y cerramos sesión para poder entrar como Administrador al sistema.

Figura 2: Habilitar o deshabilitar cuenta administrador desde lusrmgr.msc.

2.B) Con la consola de comandos (CMD), Shell de Windows

[1] - Nos vamos a: Inicio > escribimos: CMD > esperamos a la búsqueda > botón derecho sobre: cmd.exe > Ejecutar como administrador. Se nos abrirá la Shell de Windows (CMD).

[2] - Aquí tipearémos o escribirémos la siguiente linea de comandos:
net user administrador /active:yes
(para activar la cuenta administrador del sistema)

net user administrador /active:no
(para desactivar la cuenta administrador del sistema)
[3] - Pulsamos Enter y cerramos la consola con el comando Exit, o simplemente cerrando la ventana.

[4] - Cerramos sesión para poder entrar como Administrador al sistema.

Figura 3: Habilitar o deshabilitar cuenta administrador a través de consola, cmd.exe.

En algunos casos, puede dar errores. Uno muy frecuente es:

Error de Sistema 5 (System error 5):
Se refiere a que no tenemos los permisos adecuados.
Soluciones:
  • Comprobar los permisos de la cuenta.
  • Realizar un logueo en la maquina remota, para que las credencias queden el cache (un error muy típico).
  • Comprobar que el servicio netlogon este corriendo.
Estas dos maneras que mencioné, tanto gráficamente como mediante comandos con la Shell de Windows, son válidas. Aclaro que esto solamente es para activar o desactivar la cuenta Administrador del sistema.

3) Modificar permisos o privilegios de usuarios o grupos locales

3.A) Modificar permisos desde la sesión Administrador.

En cualquiera de los dos casos que hubiésemos realizado anteriormente.
Cuando cerramos sesión, veremos ya habilitada la cuenta Administrador, entramos como Administrador al sistema.

Figura 4: Inicio de sesión como administrador.

Una vez iniciada la sesión como Administrador:

[1] - Nos vamos al "Explorador de Windows" (Tecla Win + E) o doble clic en Equipo.

[2] - Hacemos clic derecho sobre el disco local C: (que por defecto en la mayoría de los casos suele ser la asignación de letra de unidad C:) > Propiedades.

Figura 5: Acceder a las propiedades de %systemdrive% para configurar la seguridad de permisos.

[3] - En ventana de "Propiedades: Disco local (C:)". Nos vamos a:

Seguridad > Editar... > (Se nos abrirá la ventana: "Permisos de Disco local (C:)") ahí seleccionamos el grupo "Usuarios" o "Administradores" y concedemos (en este caso) o denegamos privilegios o permisos a dichos grupos, marcando los checkbox que deseemos o simplemente si queremos conceder o denegar todos, marcamos el checkbox de "Control total".

Si no vemos la opción de Seguridad en una solapa o pestaña de esta ventana. Deberemos activar lo siguiente:

En la "Barra de Herramientas" de 'Mi PC' o 'Explorador de Windows' (Pulsamos F10 o 'Alt') > Herramientas > Opciones de carpeta > Ver > buscamos 'Utilizar uso compartido simple de archivos' y desmarcamos este checkbox > Aceptar. Ahora ya podremos ver la ficha de Seguridad.


[4] - Aplicamos los cambios, se nos mostrará una ventana en la que nos dice si estamos seguros de la operación, le decimos que si. Y aceptamos.
Veremos como después de aplicar la operación en la ventana "Propiedades: Disco local (C:)" se nos muestran todos los tics en "Permitir" en el grupo que seleccionáramos (Usuarios o Administradores).

Figura 6: Edición de permisos para "Usuarios" y otros.

3.B) Modificar permisos desde la sesión de un "Usuario raso" (Propietarios de objetos)

En este caso, omitiríamos desde el principio de este post hasta este apartado los pasos y las diferentes maneras de hacerlo sin necesidad de habilitar la cuenta Administrador.

Dentro de nuestra sesión de usuario normal:

[1] - Nos vamos al "Explorador de Windows" (Tecla Win + E) o doble clic en Equipo.

[2] - Hacemos clic derecho sobre el disco local C: (que por defecto en la mayoría de los casos suele ser la asignación de letra de unidad C:) > Propiedades.

[3] - En ventana de "Propiedades: Disco local (C:)" nos vamos a:
Seguridad > Opciones avanzadas.
 
[4] - Se nos mostrará la ventana: "Configuración de seguridad avanzada para Disco local (C:)". Nos vamos a: Propietario > Editar....

En la ficha propietario el usuario tendría que estar en el "Grupo de Administradores" locales para poder realizar algunas de estas funciones

Cuando un fichero o carpeta tiene a un administrador local como propietario en este fichero y/o carpeta no podremos eliminar, modificar, mover, cambiar permisos, etc., es debido a que quizás ese administrador NO esté como propietario del fichero o carpeta, ya que puede que ni siquiera esté en el grupo administradores, y sea simplemente un usuario normal-raso.

Si conseguimos añadir el usuario que queramos en la ficha de Propietario de un fichero/carpeta y remplazamos el que ya está (que esto nos lo permite si el que actualmente está es administrador pero pese a eso no nos permite borrar el fichero por decirlo de algún modo) añadiendo otro user con privilegios y reemplazando la propiedad del fichero conseguiremos realizar todo tipo de acciones sobre dicho fichero/carpeta como por ejemplo borrar esos ficheros o carpetas que Windows en ocasiones bloquea.

Es importante que después de seleccionarlo y aplicar nos fijemos de que donde aparece "Propietario actual", en la casilla de texto de abajo esté asignado o establecido el correspondiente usuario que queremos hacer propietario. (Ya que "en ocasiones" pasa que seleccionas y los cambios parece que surgen efecto y en realidad no es así).

Tendremos también que marcar los checkbox para "incluir todos los permisos heredables del objeto primario de este objeto".

Figura 7: Cambiando propietario, algo importante para la manipulación total de un objeto.

Se nos abrirá otra ventana en la que:

[5] - Seleccionamos el usuario del sistema con el que tenemos iniciada sesión (es decir, el usuario normal).
 
[6] - Marcamos el checkbox que dice: "Reemplazar propietarios en subcontenedores y objetos". Aplicamos y Aceptamos.
Cuando apliquemos se nos mostrará una ventana en la que realizará las operaciones necesarias, esperamos a que acaben de realizarse.

Que me ofrece ser propietario de un objeto?

Hacer un usuario propietario de un objeto o de los siguientes objetos (subcontenedores) no hace que tenga control total sobre dicho objeto sino, que pueda tener control para CAMBIAR los permisos de dicho objeto a su antojo, y de ese modo poderse dar así mismo más permisos. Esta es básicamente la única característica de ser propietario o no de un objeto.
Aunque veremos como aprovechar esto y ponerlo en práctica, en un próximo ejemplo de un posible escenario como funciona el ser propietario de un objeto usando los usuarios por defecto de Windows (Owners) y como afectan a sus ACEs en futuros objetos creados por dichos usuarios.

Figura 8: Reemplazando propietario en subcontenedores y objetos.

Si tenemos el siguiente escenario:

Los usuarios "Pepe" y "Lili" forman parte del grupo "Empleados" y a este grupo se le da permisos especiales de crear y solo lectura sobre los objetos carpeta y ficheros, este grupo solo va poder crear y leer estos ficheros. Pero sin embargo añadimos el usuario por defecto de Windows "Creator Owner" y a este le damos control total sobre los objetos carpetas y ficheros, quiere decir que el usuario, "Lili" por ejemplo, cree dicho objeto tendrá control total sobre este independiente de si forma parte del grupo de creación y solo lectura (empleados) ya que al crear dicho objeto a este usuario se le establecen las ACLs del "Creator Owner", con esto conseguimos que un objeto solo sea manipulable desde su creador y que solo lo puedan leer desde otros usuarios del sistema, esto es gracias a las ACLs establecidas en el grupo "Empleados" y a las del "Creator Owner".
 
Lo mismo pasaría con el "Creator Group" pero en ese caso orientado a un grupo en concreto en vez de a un usuario.

Figura 9: Añadiendo "Creator Owner" a un objeto.

Figura 10: Editando permisos especiales de solo carpeta y archivos al "Creator Owner".

Cuando acabe el proceso, volveremos a la ventana anterior. Pero esta vez nos vamos a:
 
[7] - La ficha de "Permisos" > seleccionamos nuestro usuario > Cambiar permisos... > (se nos abrirá otra ventana) seleccionamos nuestro usuario nuevamente > Editar...


Figura 11: Modificación de permisos de usuarios.

Se nos abrirá una la ventana: "Entrada de permiso para Disco local (C:)".

[8] - En el menú desplegable "Aplicar a" Seleccionamos la opción: "Esta carpeta, subcarpetas y archivos" (Esta opción está marcada por defecto, pero nos aseguramos de que esté seleccionada).

[9] - Después simplemente nos queda Permitir o Denegar privilegios o permisos al usuario, en este caso permitimos y concedemos los privilegios al usuario seleccionado anteriormente. Marcamos el checkbox Control total en permitir, para directamente seleccionar todos los campos. Sería lo mismo para la denegación, pero lógicamente marcando el checkbox contrario (en la columna de "Denegar").

[10] - Pulsamos Aceptar, se nos mostrará una ventana realizando las operaciones necesarias para efectuar los cambios en el sistema, esperamos y Aceptamos una ventana que se mostrará al terminar dicho proceso.
Aceptamos también todas las ventanas abiertas. Reiniciamos. Y listo!

Figura 12: Modificación de permisos de usuarios de forma avanzada.

Ahora tendremos el control total del sistema y podremos conceder y denegar privilegios a otros usuarios de manera normal. Como se muestra en la sección de este post "3.A) - Modificar permisos como Administrador"

No voy a pararme a explicar que hacen o deja de hacer cada uno de los permisos ya que para eso las propias webs a las que hice referencia al principio de esta guía, las cuales Microsoft las detalla como los artículos: KB-981949 y KB-308419. Explican perfectamente para que valen y que hacen cada una de las características de los permisos.

3.C) Conflictos en permisos para un mismo usuario: Permitir y denegar

Abro un pequeño apartado explicativo sobre esta cuestión. Planteo el siguiente escenario:
Si tenemos un usuario "pepe" y otros usuarios del que forma parte del grupo "empleados" y un objeto (carpeta compartida) común para almacenar información personal. Si se le da permisos de SOLO LECTURA al grupo empleados del que forma parte pepe, pero sin embargo explícitamente se le dan permisos de ESCRITURA a pepe sobre ese contenedor este va poder leer y escribir, pero el resto de usuarios que forman parte del grupo empleados solo van poder leer.

Por lo que podemos entender de que si a un un usuario que pertenece a un grupo le das unos permisos y después a ese usuario de forma independiente le añades otros permisos, el sistema de permisos NTFS de Windows da prioridad a los permisos explícitos a ese usuario en concreto y no al establecido en el grupo del que también forma parte dicho usuario.

3.D) Permisos heredables de objetos primarios

Destacar también que tenemos las opciones de "Incluir permisos heredables del objeto primario al objeto actual", esto nos dice que si tenemos una: CarpetaA con X permisos y dentro de esta creamos una CarpetaB, la CarpetaB tendrá por defecto los mismos permisos que tiene la carpeta padre-raíz (objeto primario).

Pero si quiero que la CarpetaB no herede dichos permisos solamente para esa carpeta y sus objetos ya existentes tendremos que desmarcar y agregar los permisos heredables para que esto no se aplique a las siguientes subcarpetas y/o ficheros.

Nos puede pasar que queramos eliminar de un objeto (carpeta o fichero) el grupo de "usuarios" o "usuarios autentificados" y no podamos hacerlo, así como intentar agregar o quitar otros usuarios y grupos por defecto del sistema. Esto es debido a que los permisos son heredados de los objetos padres, por lo que tenemos que desheredar dichos permisos y después proceder a eliminar esos grupos de ese objeto en cuestión.

Si desmarcamos el checkbox (que está marcado por defecto) de "Incluir todos los permisos del objeto primario de este objeto", aparecerá un cuadro de advertencia en el que se nos dice si queremos "Agregar" o "Quitar" esta herencia.

Agregar: Nos mantiene los mismos usuarios y grupos pero quita la herencia del objeto primario padre.

Quitar: Quita todos los usuarios y grupos del objeto, de modo que no quede ninguno asignado a dicho objeto, eso conlleva a que también se elimine la herencia. 

Figura 13: Permisos heredables del objeto primario de este ojeto

Microsoft nos dice lo siguiente:

"Incluir todos los permisos heredables del objeto primario de este objeto":
Si se selecciona, cada objeto secundario tendrá permisos heredados de su objeto primario.
Si se anula la selección, los permisos aplicados al objeto primario no se aplicarán a su objeto u objetos secundarios.

"Reemplazar todos los permisos heredables existentes en todos los descendientes con permisos heredables de este objeto":
Si se selecciona, los permisos de este objeto primario reemplazarán los de los objetos descendientes.
Si se anula la selección, los permisos de cada objeto (tanto de los primarios como de sus descendientes) pueden ser únicos.

Ahora, a modo de comentario detallo un poco para completar la información sobre las dos fichas que quedan restantes: Permisos efectivos y Auditoría.

En la ficha o pestaña "Permisos efectivos" nos servirá sencillamente para visualizar o mostrar los permisos por un usuario específico o grupo de usuarios. Pero no es más que ver los permisos que se permiten o deniegan en la ventana de edición de permisos de un objeto como la que se muestra anteriormente.
En el caso de la imagen que vemos a continuación podemos ver el usuario "pepeprueba" (un usuario raso dentro del grupo "Usuarios locales"), los concesión de permisos que tiene.

Figura 14: Visualización de permisos aplicados al usuario seleccionado.

En la ficha o pestaña "Auditoría", pues creo que está claro que es para poder auditar los objetos y el acceso a ellos para un usuario específico o un grupo de usuarios.

Figura 15: Auditando acceso o modificación a objetos a un usuario específico.

Lo cual para poder hacer esto y poder examinar o ver el Visor de eventos (eventvwr.msc) de Windows Vista/7, tendremos que tener habilitada una directiva en el "Editor de directivas de grupo local" (gpedit.msc). La cual nos permite auditar el acceso correcto o erróneo a objetos, esta se encuentra en:

Configuración de equipo > Configuración de Windows > Configuración de seguridad > Directivas locales > Directiva de auditoría.

Figura 16: Aplicando la GPO para auditar objetos en gpedit.msc.

4) Cambiar el tipo de cuenta: Usuarios o Administrador

Si queremos omitir el apartado de este post "2) - Habilitar o deshabilitar cuenta de Administrador" y el "3.B) - Modificar permisos desde la sesión "Usuario raso"  (Propietarios de objetos).

Directamente podemos asignar el "Grupo Administradores" la cuenta de usuario que estemos utilizando o deseemos, de manera muy sencilla. De este modo concederemos o denegaremos permisos de manera normal (siendo Administrador) como se muestra en la sección de este post "3.A) - Modificar permisos desde la sesión Administrador" (pero sin necesidad de entrar en la sesión de Administrador, ya que lo haremos todo desde la sesión usuario).

[1] - Nos vamos a: Inicio > Panel de control > Cuentas de usuario y protección infantil > Cuentas de usuario > Seleccionamos nuestra cuenta de usuario (o la que deseemos) > cambiar el tipo de cuenta > Administrador > pulsamos en el botón que dice: "Cambiar el tipo de cuenta".

Figura 17: Cambiando el tipo de cuenta de un usuario de forma gráfica. 

De este modo la cuenta seleccionada pasará a ser parte del "Grupo Administradores" y ya seremos Administrador del sistema, con lo cual tendremos los privilegios para conceder o denegar permisos a otros usuarios. En el apartado de este post "3.A) - Modificar permisos desde la sesión Administrador" veremos como modificar los permisos, pero sin necesidad de entrar en la sesión de Administrador, ya que lo haremos todo desde la sesión de la cuenta de usuario que estemos usando en Windows.

Esto anterior es la manera elegante que nos proporciona Windows de hacer de la manera tradicional y que personalmente siempre uso ya es exactamente los mismo.
Se trata de administrar y gestionar esto desde una consola de Microsft "MSC" (MicroSoft Console). Como es el caso del fichero de consola: Inicio > Ejecutar: lusrmgr.msc (Editor de usuarios y grupos locales).

Aquí podemos realizar lo mismo e incluso más funciones ya que podremos ver todos los usuarios y grupos creados en nuestro sistema, modificar así como crearlos y borrar otros (aunque tener cuidado cuales se borran ya que algunos hace uso Windows de ellos). Esta consola nos permite visualizarlo las cuentas y grupos de usuario de un modo digamos ordenado y claro, a mi parecer, más detallado, completo, igual de eficaz y a la vez hacerlo de forma rápida y sencilla.

Figura 18: La "forma más correcta" de cambiar la pertenencia de usuarios a grupos.

5) Habilitar y conceder permisos de Administrador mediante la Shell de Windows (CMD)

En este apartado, omitiremos todo lo mencionado desde el principio de este post hasta esta sección, excepto la sección "4) - Cambiar el tipo de cuenta: Usuarios o Administrador".

En esta parte, explicaré como modificar (conceder o denegar) permisos (en este caso conceder) de control total en el sistema al grupo Administradores del equipo. Mediante dos simples lineas de comandos, que escribiremos en en la consola o símbolo del sistema CMD de Windows.

[1] - Si ya cambiamos el tipo de cuenta a Administrador, abrimos la Shell de Windows como Administrador (ya que para ejecutar las siguientes instrucciones de comandos necesitamos privilegios de una cuenta del tipo Administrador), para ello, nos vamos a:
Inicio > Todos los programas > Accesorios > botón derecho sobre Símbolo de Sistema > botón derecho sobre ejecutar como Administrador
Se nos abrirá la shell de Windows CMD.

[2] - Aquí escribimos los siguiente.
takeown /F "%SYSTEMDRIVE%\*" /R /D S
Pulsamos Enter. y esperaremos a que el sistema realice todo el proceso necesario (tendría que terminar con una lista extensa, poniendo en todas las líneas que fue procesando: "CORRECTO").

[3] - A continuación, escribimos esta otra línea de comandos:
icacls "%SYSTEMDRIVE%\*" /grant Administradores:(D,WDAC) /T
Pulsamos Enter, y esperamos a que el sistema termine el proceso.

[4] - Si todo lo procesado salió correctamente, salimos de la consola, escribiendo exit y reiniciamos el equipo.
  • takeown: es para indicar el propietario.
  • icacls: es para indicar los permisos del propietario que pusimos en takeown.
Ahora el análisis de las propiedades o atributos de las dos líneas de comandos:
takeown /F "%SYSTEMDRIVE%\*" /R /D S
/F: Indica el archivo/carpeta al que queremos cambiar el propietario (en este caso es %SYSTEMDRIVE%).
%SYSTEMDRIVE%: Es la variable de entorno del disco duro principal desde donde se ejecuta Windows, es decir "C:\" (por defecto, lo más común).
*: Con el símbolo asterisco indicamos todos los archivos de esa carpeta (Archivos, no carpetas, pero combinado con /R es igual a: Todos los archivos de todas las carpetas del disco duro (en este caso)).
/R: Realiza el cambio de propietario en los subdirectorios (En este caso sería en todo el disco duro).
/D S: En algunas carpetas puede surgir una pregunta al intentar indicar el propietario donde dice que si quieres darle permisos, pues "/D S" lo único que hacen en este caso es contestar "Si" automáticamente a esa pregunta, para no tener que hacerlo manualmente.
icacls "%SYSTEMDRIVE%\*" /grant Administradores:(D,WDAC) /T
%SYSTEMDRIVE%: Como ya dijimos anteriormente, "C:\" (En este caso). 
* > (símbolo asterisco) Todos los archivos de esa carpeta (Archivos, no carpetas, pero combinado con /T es igual a: Todos los archivos de todas las carpetas del disco duro).
/T: Realiza el cambio de permisos en los subdirectorios (En este caso sería en todo el disco duro).
/grant: Es la opción para indicar que se le quieren conceder permisos a un usuario. (Lo que quiero decir, es que en vez de /Grant se podria usar /Deny para denegar permisos por ejemplo.)
Administradores: El grupo de usuarios (en este caso), (Administrador).
(D,WDAC): Los permisos a conceder. (en este caso "D" y "WDAC").

Algunos permisos importantes:
D: acceso de eliminación
WDAC: escribir DAC
F: acceso total
M: acceso de modificación
RX: acceso de lectura y ejecución

Un ejemplo de sintaxis básica de ICACLS:
icacls [PATH] [/grant|/deny] [grupo|usuario]:(herencia2)(herencia1)(permiso1,permiso2,) [otros_argumentos /?]
icacls c:\carpetapublica /inheritance:r /grant wuser:(OI)(CI)(F) /grant todos:(OI)(CI)(AD,RX)  /Q
Para ICACLS una lista de permisos simples:
  • N - sin acceso
  • F - acceso total
  • M - acceso de modificación
  • RX - acceso de lectura y ejecución
  • R - acceso de solo lectura
  • W - acceso de solo escritura
  • D - acceso de eliminación
Una lista de permisos más específica:
  • DE - eliminar
  • RC - control de lectura
  • WDAC - escribir DAC
  • WO - escribir propietario
  • S - sincronizar
  • AS - acceso al sistema de seguridad
  • MA - máximo permitido
  • GR - lectura genérica
  • GW - escritura genérica
  • GE - ejecución genérica
  • GA - todo genérico
  • RD - leer datos/lista de directorio
  • WD - escribir datos/agregar archivo
  • AD - anexar datos/agregar subdirectorio
  • REA - leer atributos extendidos
  • WEA - escribir atributos extendidos
  • X - ejecutar/atravesar
  • DC - eliminar secundario
  • RA - leer atributos
  • WA - escribir atributos
Lista de herencias:
  • (OI) - herencia de objeto
  • (CI) - herencia de contenedor
  • (IO) - solo herencia
  • (NP) - no propagar herencia
  • (I) - permiso heredado del contenedor principal
Lista de parámetros aplicables para las herencias de objetos (OI IO CI) con ICALCS (explicado):
  • OI: (Object Inherit) Afecta a carpeta que se gestiona y ficheros que tiene dentro.
  • CI: (Container Inherit) Afecta a carpeta y subcarpetas (no a ficheros).
  • IO: (Inherit Only) NO AFECTA a fichero o carpeta que se gestiona sólo los que están dentro (solo subcarpetas).
  • OI CI: Afecta a carpeta, subcarpeta y ficheros. (suele ser la herencia de permisos por defecto y habitual)
  • CI IO: Sólo afecta a subcarpetas.
  • OI IO: Sólo afecta a los ficheros contenidos en la carpeta que se gestiona.
  • CI IO OI: Afecta a los ficheros que tiene dentro y a las subcarpetas.
Para más información de las propiedades de estos dos comandos consultar la ayuda de los mismos. Escribir en una consola CMD:
Takeown /?
Icacls /?

6) UAC (User Account Control "Control de cuentas de usuario")

No tiene que ver con privilegios establecidos en un objeto o permisos ni tipos de cuentas. La relación está en que si eres administrador el sistema ya no te sobresaltará tanto con las típicas ventanas de Windows. Me refiero, aquellas que en el momento de instalar alguna aplicación o realizar alguna otra operación en el sistema, aparecen unas ventanas de advertencia, del estilo: Estas seguro que quieres ejecutar xxx? Se requieren permisos de Administrador... (Aceptar o Cancelar) o introducir el usuario y su contraseña con privilegios más altos del sistema.

Pues con el UAC deshabilitado del todo (en su nivel más bajo de seguridad) lo que se consigue es que siendo un usuario normal sin apenas privilegios en el sistema, dichas ventanas no sobresalten. Esto siempre y cuando el dicho usuario esté incluido en el grupo administradores locales del sistema. Si se trata desde otra sesión de usuario en el grupo usuarios por ejemplo la ventana de UAC seguirá mostrándose para elevar dichos privilegios. Como ya dije esto no tiene que ver con permisos (escritura, lectura, ejecución, modificación, etc.).

El UAC básicamente es una tecnología que nos notifica con advertencias de una elevación de privilegios necesaria para la ejecución de algo. Aunque lo podremos configurar el UAC mediante distintos niveles de seguridad indicando como se tiene que comportar ante ciertas advertencias informativas.

Por seguridad es muy recomendado tenerlo en su nivel más alto de seguridad "notificar siempre".

Finalmente, recomiendo este hilo del foro oficial de soporte de Microsoft (social.technet.microsoft.com), en el que Jose Manuel Tella Llop da respuesta a algunos problemas de los usuarios:
http://social.technet.microsoft.com/Forums/es-ES/wcvistaes/thread/95da492a-13bd-405d-a782-e2daffa4b893

Saludos!

Entradas Populares