Cómo establecer permisos de carpeta con PowerShell

Garantizar que las personas adecuadas tengan el acceso apropiado a archivos y carpetas específicos es primordial en TI. La gestión de permisos protege eficazmente los datos confidenciales, contribuye al cumplimiento de la normativa y mejora la eficacia operativa. Una herramienta popular para gestionar este tipo de tareas es PowerShell, y hoy, nos sumergimos en profundidad en un script que agiliza el proceso de modificación de permisos de carpeta. 

Antecedentes

En un panorama digital en constante evolución, los profesionales de TI y los proveedores de servicios gestionados (MSP) hacen malabarismos constantemente con múltiples permisos de usuario en varios archivos y carpetas. El script proporcionado es un regalo del cielo en estos casos. Ofrece flexibilidad, ya que permite asignar o bloquear permisos a varios usuarios en varias rutas. Esto significa que, tanto si trabajas con archivos individuales como con directorios enteros, este script te cubre todas las necesidades.

El script para establecer permisos de carpeta


#Requires -Version 5.1

<#
.SYNOPSIS
    Modify User Permissions for files and folder.
.DESCRIPTION
    Modify User Permissions for files and folder. You can assign or block multiple permissions to multiple users, and multiple files and folders.
.EXAMPLE
     -User "Test" -Path "C:Test" -Permissions FullControl
    Gives FullControl permissions to the user Test for just the folder C:Test
.EXAMPLE
     -User "Test1", "Test2" -Path "C:Test" -Permissions FullControl
    Gives FullControl permissions to the user Test1 and Test2 for just the folder C:Test
.EXAMPLE
     -User "Test1", "Test2" -Path "C:Test", "C:Temp" -Permissions FullControl
    Gives FullControl permissions to the user Test1 and Test2 for just the folders C:Test and C:Temp
.EXAMPLE
     -User "Test" -Path "C:TestDocument.docx" -Permissions FullControl
    Gives FullControl permissions to the user Test for just the file C:TestDocument.docx
.EXAMPLE
     -User "Test" -Path "C:TestDocument.docx" -Permissions ReadData, Modify
    Gives ReadData and Modify permissions to the user Test for just the file C:TestDocument.docx
.EXAMPLE
     -User "Test" -Path "C:TestDocument.docx" -Permissions FullControl -Block
    Blocks FullControl permissions from the user Test for just the file C:TestDocument.docx
.EXAMPLE
     -User "Test" -Path "C:Test" -Permissions FullControl -Recursive
    Gives FullControl permissions to the user Test for the folder C:Test and any folder or file under it will inherit FullControl
.EXAMPLE
    PS C:> .Modify-User-Permissions.ps1 -User "Test" -Path "C:Test" -Permissions FullControl -Recursive
    Gives FullControl permissions to the user Test for the folder C:Test and any folder or file under it will inherit FullControl
.INPUTS
    Inputs (User,Path,Permissions)
.OUTPUTS
    FileSecurity
.NOTES
    Minimum OS Architecture Supported: Windows 10, Windows Server 2016
    Release Notes:
    Initial Release
By using this script, you indicate your acceptance of the following legal terms as well as our Terms of Use at https://www.ninjaone.com/terms-of-use.
    Ownership Rights: NinjaOne owns and will continue to own all right, title, and interest in and to the script (including the copyright). NinjaOne is giving you a limited license to use the script in accordance with these legal terms. 
    Use Limitation: You may only use the script for your legitimate personal or internal business purposes, and you may not share the script with another party. 
    Republication Prohibition: Under no circumstances are you permitted to re-publish the script in any script library or website belonging to or under the control of any other software provider. 
    Warranty Disclaimer: The script is provided “as is” and “as available”, without warranty of any kind. NinjaOne makes no promise or guarantee that the script will be free from defects or that it will meet your specific needs or expectations. 
    Assumption of Risk: Your use of the script is at your own risk. You acknowledge that there are certain inherent risks in using the script, and you understand and assume each of those risks. 
    Waiver and Release: You will not hold NinjaOne responsible for any adverse or unintended consequences resulting from your use of the script, and you waive any legal or equitable rights or remedies you may have against NinjaOne relating to your use of the script. 
    EULA: If you are a NinjaOne customer, your use of the script is subject to the End User License Agreement applicable to you (EULA).
.COMPONENT
    ManageUsers
#>

[CmdletBinding()]
param (
    [Parameter(Mandatory = $true)]
    [ValidateScript(
        {
            # Validate that the User(s) exist
            if ($(Get-LocalUser -Name $_)) { $true } else { $false }
        }
    )]
    [String[]]
    # The user name of the user you want to apply Permissions to a Path(s)
    $User,
    [Parameter(Mandatory = $true)]
    [ValidateScript({ Test-Path -Path $_ })]
    [String[]]
    # File path that you want to apply Permissions to
    $Path,
    [Parameter(Mandatory = $true)]
    # Permission to set the path(s) for the user(s)
    # This accepts the following:
    #  ListDirectory, ReadData, WriteData, CreateFiles, CreateDirectories, AppendData, ReadExtendedAttributes,
    #  WriteExtendedAttributes, Traverse, ExecuteFile, DeleteSubdirectoriesAndFiles, ReadAttributes,
    #  WriteAttributes, Write, Delete, ReadPermissions, Read, ReadAndExecute, Modify, ChangePermissions,
    #  TakeOwnership, Synchronize, FullControl
    [System.Security.AccessControl.FileSystemRights[]]
    $Permissions,
    # Block the specified Permissions for the specified $User
    [Switch]
    $Block,
    # Apply the Permissions down through a folder structure, i.e. inheritance
    [Switch]
    $Recursive
)

begin {
    function Test-IsElevated {
        $id = [System.Security.Principal.WindowsIdentity]::GetCurrent()
        $p = New-Object System.Security.Principal.WindowsPrincipal($id)
        if ($p.IsInRole([System.Security.Principal.WindowsBuiltInRole]::Administrator))
        { Write-Output $true }
        else
        { Write-Output $false }
    }
}

process {
    if (-not (Test-IsElevated)) {
        Write-Error -Message "Access Denied. Please run with Administrator privileges."
        exit 1
    }
    $Acl = Get-Acl -Path $Path
    if ($true -in $Acl.AreAccessRulesProtected) {
        Write-Error "ACL rules are protected for one of the specified paths."
        exit 1
    }
    $script:HasError = $false
    $Path | ForEach-Object {
        $CurPath = Get-Item -Path $_
        $User | ForEach-Object {
            $NewAcl = Get-Acl -Path $CurPath
            # Set properties
            $identity = Get-LocalUser -Name $_
            $fileSystemRights = $Permissions
            $type = $(if ($Block) { [System.Security.AccessControl.AccessControlType]::Deny }else { [System.Security.AccessControl.AccessControlType]::Allow })
            $fileSystemRights | ForEach-Object {
                # Create new rule
                Write-Host "Creating $type $_ rule for user: $identity"
                # Check if Recursive was used and that the current path is a folder
                if ($CurPath.PSIsContainer -and $Recursive) {
                    $inheritanceFlags = 'ObjectInherit,ContainerInherit'
                    $NewAcl.SetAccessRuleProtection($false, $true)
                }
                else {
                    $inheritanceFlags = [System.Security.AccessControl.InheritanceFlags]::None
                }
                $propagationFlags = [System.Security.AccessControl.PropagationFlags]::None
                $fileSystemAccessRuleArgumentList = $identity, $_, $inheritanceFlags, $propagationFlags, $type
                $fileSystemAccessRule = New-Object -TypeName System.Security.AccessControl.FileSystemAccessRule -ArgumentList $fileSystemAccessRuleArgumentList

                # Apply new rule
                $NewAcl.SetAccessRule($fileSystemAccessRule)
                try {
                    Set-Acl -Path $CurPath -AclObject $NewAcl -Passthru
                }
                catch {
                    Write-Error $_
                    $script:HasError = $true
                }
            }
        }
    }
    if ($script:HasError) {
        exit 1
    }
}

end {}

 

Accede a más de 300 scripts en el Dojo de NinjaOne

Obtén acceso

Análisis detallado

En esencia, el script funciona con tres parámetros obligatorios: User, Path y Permissions.

  • User: define el usuario de destino para el que se establecen los permisos. Este parámetro se somete a validación para garantizar que el usuario existe.
  • Path: indica el fichero o directorio cuyos permisos deben modificarse. Se valida su existencia.
  • Permissions: enumera los distintos tipos de permisos que se pueden establecer, desde FullControl hasta permisos específicos como ReadData.

El script también ofrece parámetros opcionales:

  • Block: si se invoca, deniega los permisos especificados.
  • Recursive: si se especifica esta opción, los permisos se aplican según la estructura de carpeta, garantizando la herencia.

Cuando se ejecuta, el script comprueba primero si se está ejecutando con privilegios administrativos. A continuación, evalúa cada ruta en función de los permisos de usuario especificados, creando o modificando las reglas en consecuencia.

Posibles casos de uso

Imagina a una profesional de TI, Marta, encargada de supervisar un proyecto para su organización. Marta tiene una carpeta con los archivos del proyecto. A medida que avanza el proyecto, los distintos departamentos necesitan distintos niveles de acceso a estos archivos. Con el script, Marta puede asegurarse sin esfuerzo de que el departamento de RRHH sólo pueda leer determinados documentos, mientras que los jefes de proyecto tienen pleno control sobre todos los archivos. Esta gestión eficaz garantiza el buen funcionamiento del proyecto al tiempo que mantiene la seguridad.

Comparaciones

Los métodos tradicionales de configuración de permisos de carpeta suelen implicar navegar por intrincadas interfaces GUI o emplear software de terceros. Aunque ofrecen información visual, pueden llevar mucho tiempo y ser menos eficaces cuando se trata de permisos masivos. El script PowerShell ofrece un enfoque más rápido y directo. Resulta especialmente útil para los profesionales de TI familiarizados con la línea de comandos, ya que permite realizar cambios rápidos en los permisos mediante scripts.

FAQ

  • ¿Cuáles son los requisitos del sistema operativo para este script? 
    El script es compatible con Windows 10 y Windows Server 2016 y posteriores.
  • ¿Cómo puedo asegurarme de que los permisos recursivos se aplican sólo a las carpetas y no a los archivos individuales? 
    El script comprueba automáticamente si la ruta es un contenedor (carpeta) y sólo entonces aplica permisos recursivos.

Implicaciones

Una gestión eficaz de los permisos es fundamental para la seguridad de TI. Establecer un acceso demasiado permisivo puede exponer datos sensibles, mientras que los permisos restrictivos pueden obstaculizar los procesos de trabajo. Este script proporciona un delicado equilibrio, permitiendo un control preciso de los permisos. Sin embargo, los errores de configuración pueden tener implicaciones no deseadas, por lo que siempre hay que comprobar dos veces la configuración.

Recomendaciones

  • Realiza siempre una prueba en un entorno controlado antes de desplegar el script ampliamente.
  • Haz una copia de seguridad de la configuración actual de permisos, así contarás con una red de seguridad en caso de errores.
  • Actualiza y audita periódicamente los permisos de los usuarios para mantener la seguridad y la eficacia operativa.

Reflexiones finales

En el mundo de la TI moderna, la gestión de los derechos de acceso a carpetas y archivos es un reto importante. Los scripts de PowerShell, como el que hemos analizado hoy, hacen que la tarea sea más manejable y eficiente. Para quienes buscan soluciones integradas de gestión de TI, NinjaOne ofrece herramientas y capacidades sólidas, que facilitan aún más las complejidades de la gestión de permisos. Tanto si te basas en scripts como en plataformas integrales como NinjaOne, el objetivo sigue siendo el mismo: operaciones de TI seguras, eficientes y simplificadas.

Próximos pasos

La creación de un equipo de TI próspero y eficaz requiere contar con una solución centralizada que se convierta en tu principal herramienta de prestación de servicios. NinjaOne permite a los equipos de TI supervisar, gestionar, proteger y dar soporte a todos sus dispositivos, estén donde estén, sin necesidad de complejas infraestructuras locales.

Obtén más información sobre NinjaOne Endpoint Management, echa un vistazo a un tour en vivoo tu prueba gratuita de la plataforma NinjaOne.

Categorías:

Quizá también te interese…

Ver demo×
×

¡Vean a NinjaOne en acción!

Al enviar este formulario, acepto la política de privacidad de NinjaOne.

Términos y condiciones de NinjaOne

Al hacer clic en el botón «Acepto» que aparece a continuación, estás aceptando los siguientes términos legales, así como nuestras Condiciones de uso:

  • Derechos de propiedad: NinjaOne posee y seguirá poseyendo todos los derechos, títulos e intereses sobre el script (incluidos los derechos de autor). NinjaOne concede al usuario una licencia limitada para utilizar el script de acuerdo con estos términos legales.
  • Limitación de uso: solo podrás utilizar el script para tus legítimos fines personales o comerciales internos, y no podrás compartirlo con terceros.
  • Prohibición de republicación: bajo ninguna circunstancia está permitido volver a publicar el script en ninguna biblioteca de scripts que pertenezca o esté bajo el control de cualquier otro proveedor de software.
  • Exclusión de garantía: el script se proporciona «tal cual» y «según disponibilidad», sin garantía de ningún tipo. NinjaOne no promete ni garantiza que el script esté libre de defectos o que satisfaga las necesidades o expectativas específicas del usuario.
  • Asunción de riesgos: el uso que el usuario haga del script corre por su cuenta y riesgo. El usuario reconoce que existen ciertos riesgos inherentes al uso del script, y entiende y asume cada uno de esos riesgos.
  • Renuncia y exención: el usuario no hará responsable a NinjaOne de cualquier consecuencia adversa o no deseada que resulte del uso del script y renuncia a cualquier derecho o recurso legal o equitativo que pueda tener contra NinjaOne en relación con su uso del script.
  • CLUF: si el usuario es cliente de NinjaOne, su uso del script está sujeto al Contrato de Licencia para el Usuario Final (CLUF).