Utilisation d'ICACLS pour définir des autorisations sur les répertoires d'utilisateurs


16

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%"

Je joue avec le script XCACLS.vbs non pris en charge créé par Microsoft et j'ai eu de la chance de l'utiliser pour la dernière ligne de mon script. Au lieu de ce ICACLS "E: \ Home Directories \% userDir%" / supprimer "MYDOMAIN \% username%", je l'ai remplacé par cscript.exe xcacls.vbs "e: \ Test" / E / R "MYDOMAIN \% username% "Cela fonctionne, mais j'aimerais vraiment éviter l'utilisation de XCACLS.vbs car il a de graves problèmes de performances. D'autres idées?
pk.

Réponses:


18

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 les 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é 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 mon SOP pour les répertoires personnels des utilisateurs, les dossiers "Mes documents", "Bureau", etc. redirigés 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 comment 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 voie de logique. Cela semble être un problème émotionnel avec certaines personnes. C'est comme le stupide ACE "Deny / Receive As" 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 l'accès à BUILTIN \ Administrators, vous souhaitez conserver 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.).


1
Recommandez-vous de donner à BUILTIN \ Administrators un accès complet à toute la structure de répertoires? Je suis d'avis que nous (administrateurs) ne devrions vraiment pas avoir un accès complet aux répertoires / profils utilisateur de tout le monde sans en prendre possession.
pk.

+1, j'aime les points sur le faux sentiment de sécurité ...
DCookie

1

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

Assurez-vous de vérifier la dernière ligne de votre script. D'après mon expérience, ICACLS ne supprimera pas correctement les autorisations héritées. Il supprime l'entrée du dossier "MYDOMAIN \% username%", mais les autorisations des sous-dossiers ne sont pas modifiées. Par conséquent, "MYDOMAIN \% username%" aura toujours accès aux sous-dossiers si vous y accédez directement, vous ne pourrez tout simplement pas y accéder. XCACLS.vbs a résolu ce problème pour moi. cscript.exe xcacls.vbs "e: \ Test" / E / R "MYDOMAIN \% username%"
pk.

C'est là que le . une partie est venue sur mon montage. faire / héritage: r sur le dossier parent, j'ai eu le même problème. mais le faire . dans le dossier parent semblait faire l'affaire. Après avoir exécuté ce qui précède,% userdir% a% username%, le système et les administrateurs, mais tout ce qui se trouve en dessous n'est que% username% et system, c'est ainsi que le serveur les a configurés initialement - exactement ce que je voulais.

-1

J'ai besoin de votre aide pour modifier cette commande en fonction de mes besoins si cela est techniquement possible.

Voici la structure

\ Server \ Parent \ UserA \ unix

\ Server \ Parent \ UserB \ unix

\ Server \ Parent \ UserC \ unix .... et ainsi de suite ..

Sous chaque dossier User $ se trouve un dossier nommé "unix".

Je veux ajouter un utilisateur ou un groupe avec des autorisations complètes sur tous les dossiers User $ répertoriés sous le dossier "Parent" (noms pris dans la structure ci-dessus) mais je veux exclure les autorisations uniquement sur le dossier "unix".

J'ai cette commande qui fonctionne bien pour moi dans la perspective de l'applicabilité des autorisations requises, mais je ne peux pas ajouter de fonction d'exclusion dans cela.

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

Serez-vous capable de guider dans ce scénario?


1
Bonjour et bienvenue sur Server Fault! Veuillez ne pas poser de questions via la réponse. Utilisez le bouton Poser une question pour publier votre demande.
M. Shunz
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.