Usando ICACLS para establecer permisos en directorios de usuarios


16

Estoy tratando de restablecer los permisos en los directorios de usuarios y tengo algunos problemas con el último paso de mi script. Mi script básicamente toma posesión de todo el directorio de usuarios, restablece los permisos en todos los archivos y carpetas para el directorio, otorga explícitamente los permisos que necesito, detiene toda herencia de permisos de las carpetas principales, establece el propietario legítimo (usuario especificado) para todos los archivos y carpetas, y luego elimina el permiso que me di a mí mismo para poder operar en los archivos. Necesito este último paso para eliminarme de TODOS los archivos y subcarpetas, pero por el momento solo me elimina del% userDir% y deja todos los permisos heredados a continuación. Esta es una deficiencia aparente en ICACLS. ¿Alguien sabe de alguna otra manera de lograr esto?

set /p userDir=Enter the login of the user's directory you're modifying permissions for. (i.e. jDoe)
TAKEOWN /f "E:\Home Directories\%userDir%" /r /d y
ICACLS "E:\Home Directories\%userDir%" /reset /T
ICACLS "E:\Home Directories\%userDir%" /grant:r "MYDOMAIN\%userDir%":(OI)(CI)F /grant:r "SYSTEM":(OI)(CI)F /grant:r "MYDOMAIN\%username%":(OI)(CI)F
ICACLS "E:\Home Directories\%userDir%" /inheritance:r
ICACLS "E:\Home Directories\%userDir%" /setowner "MYDOMAIN\%userDir%" /T
ICACLS "E:\Home Directories\%userDir%" /remove "MYDOMAIN\%username%"

Estoy jugando con el script XCACLS.vbs no compatible creado por Microsoft y tuve la suerte de usarlo para la última línea de mi script. En lugar de esto ICACLS "E: \ Home Directorios \% userDir%" / remove "MYDOMAIN \% username%" Lo he reemplazado con cscript.exe xcacls.vbs "e: \ Test" / E / R "MYDOMAIN \% username% "Esto funciona, pero realmente me gustaría evitar el uso de XCACLS.vbs ya que tiene graves problemas de rendimiento. ¿Alguna otra idea?
pk.

Respuestas:


18

Una observación primero: cada vez que bloquea la herencia, se corta la flexibilidad futura. Evito bloquear la herencia a toda costa.

Si necesita que los usuarios puedan enumerar el contenido de la carpeta "E: \ Directorios principales" de nivel superior, por ejemplo, considere el siguiente permiso:

  • SISTEMA - Control total - Aplicado a esta carpeta, subcarpetas y archivos
  • BUILTIN \ Administrators - Control total - Aplicado a esta carpeta, subcarpetas y archivos
  • BUILTIN \ Usuarios autenticados - Leer y ejecutar - Aplicado solo a esta carpeta

El último permiso no se hereda en las subcarpetas. En cada subcarpeta, la herencia permanece habilitada y simplemente especifica al usuario con los derechos "Modificar" o "Control total" (dependiendo de cómo se sienta acerca de que los usuarios puedan establecer permisos dentro de su directorio de inicio). (Por lo general, establezco ese último permiso agregando "Usuarios autenticados" en la hoja de propiedades de seguridad no "Avanzada", desmarcando las casillas de verificación "Leer" y "Leer y ejecutar". Luego procedo al cuadro de diálogo "Avanzado" y cambio la casilla Configuración "Aplicar en" para ese ACE a "Esta carpeta solamente". Esa es la forma más fácil, en términos de número de clics, para configurarlo.)

Entonces, tu guión se convierte en:

set /p userDir=Enter the login of the user's directory you're modifying permissions for. (i.e. jDoe)
TAKEOWN /f "E:\Home Directories\%userDir%" /r /d y
ICACLS "E:\Home Directories\%userDir%" /reset /T
ICACLS "E:\Home Directories\%userDir%" /grant:r "MYDOMAIN\%userDir%":(OI)(CI)F
ICACLS "E:\Home Directories\%userDir%" /setowner "MYDOMAIN\%userDir%" /T

Sospecho firmemente que la adición del permiso "Usuarios autenticados" que describí anteriormente con la herencia establecida en "Esta carpeta solamente" le dará lo que está buscando en funcionalidad y le dará flexibilidad futura si se entera que debe establecer un permiso que podría necesitar heredar en todos los directorios principales de los usuarios en el futuro.

Este es mi SOP para directorios de inicio de usuarios, carpetas redirigidas de "Mis documentos", "Escritorio", etc., y para directorios de perfil de usuario itinerantes. Funciona muy bien

Editar

re: su comentario sobre el acceso BUILTIN \ Administrators

He tenido varias discusiones con la gente sobre mi opinión sobre la concesión de acceso a BUILTIN \ Administrators a lo largo de los años, y mi opinión es esta:

  • Es más fácil resolver una cierta clase de problemas de usuario si puede acceder a sus archivos. Es difícil "tomar posesión" y puede ser bastante lento si también hay una gran cantidad de archivos presentes.

  • Como ha visto con ICACLS, BUILTIN \ Administrators puede "asignar" la propiedad (además de "tomarla") para que no se agregue "seguridad" al no tener los archivos accesibles para BUILTIN \ Administrators en primer lugar.

  • A menos que esté utilizando la auditoría (y seleccionando una cantidad potencialmente enorme de entradas positivas falsas), no habrá un seguimiento de auditoría cuando un usuario BUILTIN \ Administradores tome posesión de los archivos a los que no debería acceder, los copia y luego devuelve los archivos a su propietario y permiso "adecuado".

  • En el mundo de Microsoft, el sistema de cifrado de archivos (EFS) está destinado a resolver el problema de evitar el acceso no autorizado de BUILTIN \ Administrators. Las ACL de NTFS no resuelven ese problema. (Obviamente, EFS no es el único programa en la ciudad. El cifrado es la verdadera respuesta para resolver el problema de "limitar el acceso del administrador de la red" sin importar cómo lo corte).

En mi opinión, no especificar BUILTIN \ Administradores con acceso a los directorios de inicio de los usuarios (y, de hecho, a cualquier carpeta) significa que está aumentando la complejidad y el tiempo necesarios para resolver problemas al tiempo que proporciona menos seguridad real ("menos que ninguno "porque imparte una falsa sensación de seguridad donde no la hay).

He dejado de tratar de ganar la discusión con la gente por lógica. Parece ser un problema emocional con algunas personas. Es como el tonto ACE "Denegar / Recibir como" que se coloca en la raíz de una organización de Exchange para evitar que ciertos grupos privilegiados abran los buzones de los usuarios. No ofrece seguridad real (ya que sin una auditoría se podría eliminar / volver a aplicar el ACE según sea necesario), una falsa sensación de seguridad y se interpone en el camino al resolver problemas reales.

Incluso si no le gusta mi argumento acerca de que BUILTIN \ Los administradores tienen acceso, desea mantener intacta la jerarquía de herencia mediante el uso de la herencia "Esta carpeta solamente" cuando corresponda. El bloqueo de la herencia en las jerarquías de permisos es una señal segura de que algo sobre el diseño está "roto" (invertido, etc.).


1
¿Recomienda dar a BUILTIN \ Administradores acceso completo a toda la estructura de directorios? Soy de la opinión de que nosotros (los administradores) realmente no deberíamos tener acceso completo a los directorios / perfiles de usuarios de todos sin tomar posesión.
pk.

+1, me encantan los puntos sobre la falsa sensación de seguridad ...
DCookie

1

Primero, gracias por tu extracto del guión. He estado trabajando en lo mismo pero estaba atrapado en un lugar diferente. En mi cuadro SBS 2008, el siguiente código funciona para mí (suponiendo que se ejecute elevado, por supuesto). Hice un icacls% userdir% / t de una carpeta de usuario nueva (predeterminada) creada por el sistema operativo, y lo comparé con el icacls% userdir% / t de una carpeta después de ejecutar este script y parece que todas las "O" y Yo "son correctos. Espero que funcione para ti también.

set /p userDir=Enter the login of the user's directory you're modifying permissions for. (i.e. jDoe)
TAKEOWN /f "E:\Home Directories\%userDir%" /r /d y
ICACLS "E:\Home Directories\%userDir%" /reset /T
ICACLS "E:\Home Directories\%userDir%" /grant:r "MYDOMAIN\%userDir%":(oi)(ci)f
ICACLS "E:\Home Directories\%userDir%\*.*" /grant:r "SYSTEM":(OI)(CI)F /grant:r "MYDOMAIN\%userDir%":(OI)(CI)F /grant:r "MYDOMAIN\%username%":(OI)(CI)F
ICACLS "E:\Home Directories\%userDir%\*.*" /inheritance:r
ICACLS "E:\Home Directories\%userDir%\*.*" /setowner "MYDOMAIN\%userDir%" /T
ICACLS "E:\Home Directories\%userDir%" /remove "MYDOMAIN\%username%" /t

Atentamente,

 -d

Asegúrese de verificar la línea final de su secuencia de comandos. Según mi experiencia, ICACLS no eliminará con éxito los permisos heredados. Elimina la entrada en la carpeta "MYDOMAIN \% username%", pero los permisos de las subcarpetas permanecen intactos. Por lo tanto, "MYDOMAIN \% username%" seguirá teniendo acceso a las subcarpetas si se accede directamente, simplemente no podrá buscarlas. XCACLS.vbs resolvió esto por mí. cscript.exe xcacls.vbs "e: \ Test" / E / R "MYDOMAIN \% username%"
paquete

Ahí es donde el . parte entró en mi edición. haciendo / herencia: r en la carpeta principal, tuve el mismo problema. pero haciéndolo . en la carpeta principal parecía hacer el truco. Después de ejecutar lo anterior,% userdir% tiene% username%, system y administradores, pero todo lo que hay debajo es solo% username% y system, que es cómo el servidor los configuró inicialmente, justo lo que quería.

-1

Necesito su ayuda para modificar este comando de acuerdo a mi requerimiento si eso es técnicamente posible.

Aquí esta la estructura

\ Server \ Parent \ UserA \ unix

\ Server \ Parent \ UserB \ unix

\ Server \ Parent \ UserC \ unix .... y así sucesivamente ...

Debajo de cada una de las carpetas User $ hay una carpeta llamada "unix".

Quiero agregar un usuario o grupo con permisos completos en todas las carpetas $ Usuario enumeradas en la carpeta "Principal" (nombres tomados de la estructura anterior) pero quiero excluir permisos solo en la carpeta "unix".

Tengo este comando que funciona bien para mí en perspectiva de la aplicabilidad de los permisos requeridos, pero no puedo agregar la función de exclusión en esto.

icacls "\\ Server \ Parent \ UserA" / grant Domain \ Group: (OI) (CI) F / T

¿Serás capaz de guiar en este escenario?


1
Hola y bienvenido a Server Fault! Por favor no haga preguntas por respuesta. Use el botón Preguntar para publicar su solicitud.
Sr. Shunz
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.