Utilisation d'ICACLS pour définir des autorisations sur les répertoires d'utilisateurs
J'essaie de réinitialiser les autorisations sur les répertoires utilisateur et j'ai un peu de mal avec la dernière étape de mon script. Mon script prend essentiellement la propriété de l'ensemble du répertoire utilisateur, réinitialise les autorisations sur tous les fichiers et dossiers du répertoire, accorde explicitement les autorisations dont j'ai besoin, arrête tout héritage des autorisations des dossiers parents, définit le propriétaire légitime (utilisateur spécifié) pour tous les fichiers et les dossiers, puis supprime l'autorisation que je me suis donnée pour pouvoir opérer sur les fichiers. J'ai besoin de cette dernière étape pour me retirer de TOUS les fichiers et sous-dossiers, mais pour le moment, cela me supprime simplement du% userDir% et laisse toutes les autorisations héritées ci-dessous. Il s'agit d'une lacune apparente de l'ICACLS. Quelqu'un connaît-il un autre moyen d'y parvenir?
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%"
Une observation d'abord: chaque fois que vous bloquez l'héritage, vous vous coupez de la flexibilité future. J'évite à tout prix de bloquer l'héritage.
Si vous avez besoin que les utilisateurs puissent répertorier le contenu du dossier de niveau supérieur "E:\Home Directories", par exemple, envisagez l'autorisation suivante:
- SYSTÈME - Contrôle total - Appliqué à ce dossier, sous-dossiers et fichiers
- BUILTIN\Administrators - Full Control - Appliqué à ce dossier, sous-dossiers et fichiers
- BUILTIN\Utilisateurs authentifiés - Lecture et exécution - Appliqué à ce dossier uniquement
La dernière autorisation n'hérite pas dans les sous-dossiers. Dans chaque sous-dossier, l'héritage reste activé et vous spécifiez simplement l'utilisateur avec des droits "Modifier" ou "Contrôle total" (selon ce que vous pensez des utilisateurs qui peuvent définir des autorisations dans leur répertoire personnel). (En règle générale, je définit cette dernière autorisation en ajoutant "Utilisateurs authentifiés" dans la feuille de propriétés de sécurité non "avancée", en décochant les cases "Lire" et "Lire et exécuter". Je passe ensuite à la boîte de dialogue "Avancé" et modifie la Paramètre "Appliquer sur" pour cet ACE à "Ce dossier uniquement". C'est à peu près le moyen le plus simple, en termes de nombre de clics, de le définir.)
Ensuite, votre script devient:
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
Je soupçonne fortement que l'ajout de l'autorisation "Utilisateurs authentifiés" que j'ai décrite ci-dessus avec l'héritage défini sur "Ce dossier uniquement" vous donnera ce que vous recherchez en termes de fonctionnalités et vous donnera une flexibilité future si vous découvrez que vous devez définir une autorisation qui pourrait devoir hériter dans tous les répertoires personnels des utilisateurs à l'avenir.
Il s'agit de mes SOP pour les répertoires personnels des utilisateurs, les dossiers redirigés "Mes documents", "Bureau", etc.) et pour les répertoires de profils d'utilisateurs itinérants. Cela fonctionne très bien.
Éditer
re: votre commentaire sur BUILTIN\Accès administrateurs
J'ai eu divers arguments avec des gens au sujet de mon opinion sur l'octroi de l'accès à BUILTIN\Administrators au fil des ans, et mon opinion est la suivante:
Il est plus facile de résoudre une certaine classe de problèmes d'utilisateurs si vous pouvez accéder à leurs fichiers. Il est difficile de "s'approprier" et peut être assez lent si un grand nombre de fichiers sont également présents.
Comme vous l'avez vu avec ICACLS, BUILTIN\Administrators peut "attribuer" la propriété (en plus de "la prendre") donc il n'y a pas de "sécurité" ajoutée en n'ayant pas les fichiers accessibles à BUILTIN\Administrators en premier lieu.
À moins que vous n'utilisiez l'audit (et que vous passiez au crible un nombre potentiellement énorme d'entrées faussement positives), il n'y aura pas de piste d'audit lorsqu'un utilisateur BUILTIN\Administrators s'approprie des fichiers auxquels il ne devrait pas accéder, les copie, puis renvoie les fichiers à leur "bon" propriétaire et autorisation.
Dans le monde Microsoft, le cryptage du système de fichiers (EFS) est destiné à résoudre le problème d'empêcher l'accès non autorisé à BUILTIN\Administrators. Les ACL NTFS ne résolvent pas ce problème. (Évidemment, EFS n'est pas le seul spectacle en ville. Le cryptage est la vraie réponse pour résoudre le problème de "limiter l'accès de l'administrateur réseau", peu importe la façon dont vous le découpez.)
À mon avis, le fait de ne pas spécifier BUILTIN\Administrators avec accès aux répertoires personnels des utilisateurs (et, en fait, à n'importe quel dossier) signifie que vous augmentez la complexité et le temps nécessaires pour résoudre les problèmes tout en n'offrant qu'une sécurité réelle ("moins que nulle" "car il donne un faux sentiment de sécurité là où il n'y en a pas).
J'ai renoncé à gagner l'argument avec les gens par la logique. Cela semble être un problème émotionnel avec certaines personnes. C'est comme le stupide ACE "Refuser/Recevoir comme" qui est placé à la racine d'une organisation Exchange pour empêcher certains groupes privilégiés d'ouvrir les boîtes aux lettres des utilisateurs. Il n'offre aucune sécurité réelle (car sans audit, on pourrait supprimer/réappliquer l'ACE si nécessaire), un faux sentiment de sécurité et gêne lors de la résolution de problèmes réels.
Même si vous n'aimez pas mon argument à propos de BUILTIN\Administrators ayant accès à vous voulez pour garder la hiérarchie d'héritage intacte en utilisant l'héritage "Ce dossier uniquement" le cas échéant. Le blocage de l'héritage dans les hiérarchies d'autorisations est un signe certain que quelque chose dans la conception est "cassé" (inversé, etc.).
Tout d'abord, merci pour votre extrait de script. J'ai travaillé sur la même chose mais j'étais coincé dans un endroit différent. Sur ma boîte SBS 2008, le code ci-dessous fonctionne pour moi (en supposant qu'il soit exécuté en hauteur, bien sûr). J'ai fait un icacls% userdir%/t d'un tout nouveau dossier utilisateur (par défaut) créé par le système d'exploitation, et je l'ai comparé au icacls% userdir%/t d'un dossier après avoir exécuté ce script et il ressemble à tous les "O et Je suis "ont raison. J'espère que cela fonctionnera aussi pour vous.
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
Meilleures salutations,
-d