Salut les geeks ! J’espère que vous allez bien. Pour ma part, je suis content d’arriver à l’été, synonyme de vacances imminentes ! Mais pour le moment, je suis encore au taff, où j’ai eu la tâche ingrate de devoir déterminer si un groupe de sécurité spécifique était présent dans un arborescence où il est coutume de casser l’héritage NTFS depuis des années… beurk, beurk, on n’aime pas ça, si ce n’est pas documenté, ça devient très vite le bronx et il n’est plus possible de savoir comment ont été pensés les droits des différents groupes.

Fort heureusement pour vous, je vais vous présenter deux techniques qui vont vous permettre de lister les permissions NTFS d’une arborescence, afin que vous ne viviez pas les mêmes mésaventures que moi.

La méthode logicielle ou lambda

On n’a pas toujours le temps ou le besoin de pondre un bout de script pour tout et pour rien, vous en conviendrez. C’est pourquoi je vous propose d’utiliser un tool Microsoft, qui doit être conscient de ce manque même dans les versions serveur de Windows: AccessEnum.
L’interface est simple au possible, on donne un répertoire à scanner, il y a 3 options à tout casser dont une bien utile qui permet de comparer deux scans, qu’il aura préalablement fallu enregistrer au format .txt, ce qui est tout de même bien pratique pour suivre l’évolution des droits si changements il y a.
Il est aussi possible de ne lister que les éléments dont les permissions sont différentes du dossier root où vous effectuez votre scan.

La méthode scriptée ou barbue

Si vous avez besoin d’inclure cette démarche dans une tâche récurrente ou si simplement vous êtes adepte de la ligne de commande, vous pouvez vous appuyer sur ce script Powershell auquel il faudra donner en argument le dossier ou fichier à scanner, de la manière suivante:

Il est censé exporter le fruit de son travail dans un fichier nommé « NTFSPermission_Report.csv », bien que dans mon cas les données ne soient pas formatées correctement, je ne sais pas si c’est dû au script ou à Excel, mais les données reportées semblent correctes, donc c’est probablement juste du travail de formatage…

En bonus, si vous vous prenez des messages d’erreur quand vous tentez de lancer le script powershell, c’est probablement que vous devez modifier la politique d’exécution.

On se retrouve bientôt pour un nouvel article !