Comment configurer les droits d’accès aux dossiers avec PowerShell

Aujourd’hui, nous allons nous pencher sur un script qui simplifie le processus pour modifier et configurer les droits d’accès aux dossiers. S’assurer que les bonnes personnes ont un accès approprié à des fichiers et dossiers spécifiques est primordial dans le domaine de l’informatique. La gestion des autorisations protège efficacement les données sensibles, contribue à la conformité réglementaire et améliore l’efficacité opérationnelle. PowerShell est l’un des outils les plus utilisés pour ce type de tâches.

Contexte

Dans un monde numérique en constante évolution, les professionnels de l’informatique et les fournisseurs de services gérés (MSP) doivent constamment jongler avec de multiples autorisations d’utilisateurs pour divers fichiers et dossiers. Le script suivant est une aubaine dans de tels scénarios. Il offre une grande flexibilité, permettant d’attribuer ou de bloquer des autorisations pour plusieurs utilisateurs sur plusieurs chemins. Ainsi, que vous travailliez avec des fichiers ou bien des répertoires entiers, ce script fonctionne.

Le script

#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 {}

 

Accédez à plus de 700 scripts dans le Dojo NinjaOne

Obtenez l’accès

Description détaillée

À la base, le script fonctionne avec trois paramètres obligatoires : User (utilisateur), Path (chemin d’accès), et Permissions (autorisations).

  • User : Définit l’utilisateur cible pour lequel les autorisations sont définies. Ce paramètre fait l’objet d’une validation pour s’assurer que l’utilisateur existe.
  • Path : Indique le fichier ou le répertoire dont les permissions doivent être modifiées. Son existence est validée.
  • Permissions : Enumère les différents types de permissions qui peuvent être définies, allant de FullControl à des permissions spécifiques telles que ReadData.

Le script propose également des paramètres optionnels :

  • Block: S’il est invoqué, il refuse les autorisations spécifiées.
  • Recursive: Si cette option est spécifiée, les autorisations sont appliquées en fonction de la structure du dossier, ce qui garantit l’héritage.

Lorsqu’il est exécuté, le script vérifie d’abord s’il s’exécute avec des droits d’administrateur. Il évalue ensuite chaque chemin d’accès en fonction des autorisations utilisateur spécifiées, en créant ou en modifiant les règles en conséquence.

Cas d’utilisation potentiels

Imaginez une professionnelle de l’informatique, Jane, qui supervise un projet pour son entreprise. Jane a un dossier contenant des fichiers de projet. Au fur et à mesure de l’avancement du projet, les différents services ont besoin de différents niveaux d’accès à ces fichiers. En utilisant le script, Jane peut facilement s’assurer que le département des ressources humaines ne peut lire que certains documents, tandis que les chefs de projet ont un contrôle total sur tous les fichiers. Cette gestion efficace garantit le bon déroulement du projet tout en préservant la sécurité.

Comparaisons

Les méthodes traditionnelles de configuration des autorisations de dossiers impliquent souvent de naviguer dans des interfaces graphiques complexes ou d’utiliser des logiciels tiers. Bien qu’elles offrent un retour d’information visuel, elles peuvent prendre du temps et être moins efficaces lorsqu’il s’agit de gérer des autorisations à grande échelle. Le script PowerShell offre une approche plus rapide et plus directe. Il est particulièrement pratique pour les informaticiens habitués à la ligne de commande, car il permet de modifier rapidement les autorisations à l’aide de scripts.

FAQ

  • Quelle est la configuration requise pour ce script ? 
    Le script prend en charge Windows 10 et Windows Server 2016 et versions plus récentes.
  • Comment puis-je m’assurer que les autorisations récursives sont appliquées uniquement aux dossiers et non individuellement aux fichiers ? 
    Le script vérifie automatiquement si le chemin d’accès est un conteneur (dossier) et applique alors des autorisations récursives.

Implications

Une gestion efficace des autorisations est essentielle pour la sécurité informatique. Un accès trop élevé peut exposer des données sensibles, tandis que des autorisations restrictives peuvent entraver les processus de travail. Ce script assure un équilibre subtil, permettant un contrôle précis des autorisations. Cependant, des configurations erronées peuvent avoir des conséquences inattendues, c’est pourquoi il convient de toujours revérifier vos paramètres.

Recommandations

  • Effectuez toujours un test dans un environnement contrôlé avant de déployer le script à grande échelle.
  • Sauvegardez les paramètres d’autorisation actuels, offrant ainsi un dispositif de sécurité en cas d’erreur.
  • Mettez à jour et vérifier régulièrement les autorisations des utilisateurs afin de maintenir la sécurité et l’efficacité opérationnelle.

Conclusion

Dans le monde informatique moderne, la gestion des droits d’accès aux dossiers et aux fichiers est un défi de taille. Les scripts PowerShell, comme celui que nous avons exploré aujourd’hui, rendent la tâche plus facile à gérer et plus efficace. Pour ceux qui recherchent des solutions intégrées de gestion informatique, NinjaOne offre des outils et des capacités performantes, facilitant encore la complexité de la gestion des autorisations. Que vous vous appuyiez sur des scripts ou sur des plateformes complètes comme NinjaOne, l’objectif reste le même : des opérations informatiques sûres, efficaces et fluides.

Pour aller plus loin

Créer une équipe informatique efficace et performante nécessite une solution centralisée qui soit l’outil principal pour fournir vos services. NinjaOne permet aux équipes informatiques de surveiller, gérer, sécuriser et prendre en charge tous les appareils, où qu’ils soient, sans avoir besoin d’une infrastructure complexe sur site.

Pour en savoir plus sur NinjaOne Endpoint Management, participez à une visite guidée ou commencez votre essai gratuit de la plateforme NinjaOne.

Catégories :

Vous pourriez aussi aimer

Voir la démo×
×

Voir NinjaOne en action !

En soumettant ce formulaire, j'accepte la politique de confidentialité de NinjaOne.

Termes et conditions NinjaOne

En cliquant sur le bouton « J’accepte » ci-dessous, vous indiquez que vous acceptez les termes juridiques suivants ainsi que nos conditions d’utilisation:

  • Droits de propriété: NinjaOne possède et continuera de posséder tous les droits, titres et intérêts relatifs au script (y compris les droits d’auteur). NinjaOne vous accorde une licence limitée pour l’utilisation du script conformément à ces conditions légales.
  • Limitation de l’utilisation: Les scripts ne peuvent être utilisés qu’à des fins personnelles ou professionnelles internes légitimes et ne peuvent être partagés avec d’autres entités.
  • Interdiction de publication: Vous n’êtes en aucun cas autorisé à publier le script dans une bibliothèque de scripts appartenant à, ou sous le contrôle d’un autre fournisseur de logiciels.
  • Clause de non-responsabilité: Le texte est fourni « tel quel » et « tel que disponible », sans garantie d’aucune sorte. NinjaOne ne promet ni ne garantit que le script sera exempt de défauts ou qu’il répondra à vos besoins ou attentes particulières.
  • Acceptation des risques: L’utilisation du script est sous votre propre responsabilité. Vous reconnaissez qu’il existe certains risques inhérents à l’utilisation du script, et vous comprenez et assumez chacun de ces risques.
  • Renonciation et exonération de responsabilité: Vous ne tiendrez pas NinjaOne pour responsable des conséquences négatives ou involontaires résultant de votre utilisation du script, et vous renoncez à tout droit ou recours légal ou équitable que vous pourriez avoir contre NinjaOne en rapport avec votre utilisation du script.
  • EULA: Si vous êtes un client de NinjaOne, votre utilisation du script est soumise au contrat de licence d’utilisateur final qui vous est applicable (End User License Agreement (EULA)).