Comme le savent tous ceux qui ont traité des autorisations de serveur de fichiers, NTFS a une fonctionnalité/faille de conception intéressante connue sous le nom de problème de déplacement/copie.
Comme expliqué dans cet article MS KB , les autorisations pour un dossier ou un fichier n'héritent pas automatiquement du parent si le dossier est déplacé et que la source et la destination se trouvent sur le même volume NTFS. Les autorisations sont héritées si le dossier est copié ou si la source et la destination se trouvent sur des volumes différents.
Voici un petit exemple:
Vous avez deux dossiers partagés sur le même volume NTFS appelés "Techniciens" et "Gestionnaires". Le groupe Techniciens a un accès RW au dossier Techniciens et le groupe Managers a un accès RW au dossier "Managers". Si quelqu'un a accès aux deux et déplace un sous-dossier du dossier "Managers" vers le dossier "Technicians", le dossier déplacé n'est toujours accessible qu'aux utilisateurs du groupe "Managers". Le groupe "Techniciens" ne peut pas accéder au sous-dossier même s'il se trouve sous le dossier "Techniciens" et doit hériter des autorisations par le haut.
Comme vous pouvez l'imaginer, cela provoque des appels de support, des tickets et des cycles inutiles pour résoudre ces problèmes d'utilisateurs finaux, sans parler du nid de permissions que vous pouvez vous retrouver si les utilisateurs déplacent souvent des dossiers entre différents dossiers/zones sécurisés sur le même volume.
Les questions sont:
Quelle est la meilleure façon de contourner cette faille de conception NTFS et comment la gérez-vous dans votre environnement?
Je sais que l'article de la base de connaissances lié parle de certaines clés de registre pour modifier le comportement par défaut de l'Explorateur Windows, mais elles sont côté client et nécessitent que les utilisateurs aient la possibilité de modifier les autorisations auxquelles je pense la plupart des environnements est un non-démarreur si vous souhaitez garder le contrôle sur les autorisations de votre serveur de fichiers (et votre santé mentale en tant qu'administrateur système).
Mon approche consiste à ne pas utiliser les autorisations de fichier au niveau du fichier/répertoire; utiliser les autorisations au niveau du partage de fichiers et définir le lecteur de données du système de fichiers du serveur entier sur Tout le monde (qui devient théorique).
Au fil des ans (10+), j'ai constaté que les autorisations NTFS sont plus complexes et entraînent plus d'erreurs. Si les autorisations sont mal définies ou que l'héritage est rompu, vous exposez les données et leur difficulté à les trouver et à les voir. De plus, vous êtes exposé au problème de déplacement/copie comme vous le dites.
Emplacements où vous devez utiliser les ACL de niveau répertoire/fichier; Je ne connais pas d'autre solution que de vérifier régulièrement la santé de la chose.
Et bien ce n'est pas vraiment un défaut. Cette règle de gestion des autorisations lors du déplacement de fichiers est en place depuis au moins la version bêta 2 de NT3.1 (bien que ce ne soit évidemment pas un héritage car cela n'a été ajouté qu'avec Windows 2000). C'est à peu près aussi connu que n'importe quelle fonctionnalité de Windows. J'ai beaucoup de sympathie pour votre point de vue, car il peut y avoir peu d'entre nous qui n'ont pas été brûlés par cela à un moment donné. Mais c'est quelque chose que l'administrateur système apprend rapidement.
JR
Nous utilisons NTFS depuis NT 3.51 et bien que nous ayons vu ce "problème" (comme presque tout le monde), cela ne nous a pas causé beaucoup de problèmes:
Solutions de contournement auxquelles je peux penser:
Avis de non-responsabilité - Je viens d'un arrière-plan Unix (et j'ai mis en œuvre le dernier pour corriger différentes failles d'autorisations - cela semble icky, mais fait le travail), il peut donc y avoir une bien meilleure solution.
J'utilise la stratégie de groupe/les politiques de sécurité/le système de fichiers pour suivre les autorisations compliquées. (N'utilisez JAMAIS les "autorisations de remplacement" dans la stratégie).
Planifiez un CACLS pour réinitialiser toutes les autorisations pendant la nuit suivi d'un gpupdate/force pour réappliquer l'autorisation de la stratégie. Fonctionne comme un charme.
Lorsque je me déplace en tant qu'administrateur, j'utilise xcopy/s/e/c/h/r/k/y - tout sauf la propriété du fichier et l'ACL, ce qui signifie que l'héritage de l'ACL entre automatiquement en jeu. Je n'ai jamais vraiment eu à faire face à une situation où un utilisateur déplacé des choses cependant.
Depuis Windows 7 (ou peut-être Windows Vista), les autorisations pour un dossier ou un fichier héritent du parent si le dossier est déplacé et la source et la destination sont sur le même volume NTFS - si un fichier ou un dossier est copié via l'Explorateur. Dans un système d'exploitation antérieur, vous pouvez utiliser Far Manager - il permet d'activer l'héritage des autorisations de la destination (avec des tonnes d'autres fonctionnalités). Bien que Far puisse sembler peu convivial pour un utilisateur général.
Une solution très simple consiste à simplement compresser les fichiers et à les décompresser dans le répertoire de destination.