Donner accès à un sous-répertoire sans donner accès aux répertoires parents


12

J'ai un scénario impliquant un serveur de fichiers Windows où le "propriétaire" veut distribuer des autorisations à un groupe d'utilisateurs du type suivant:

  • \\server\dir1\dir2\dir3: lire, écrire et exécuter
  • \\server\dir1\dir2: pas de permissions
  • \\server\dir1: pas de permissions
  • \\server: lire et exécuter

À ma connaissance ( mise à jour : tout ce paragraphe est faux!), Il n'est pas possible de le faire car une Read & Executeautorisation doit être accordée à tous les répertoires parents d'une chaîne de répertoires pour que le système d'exploitation puisse «voir» l'enfant. répertoires et y accéder. Sans cette autorisation, vous ne pouvez même pas obtenir le jeton de contexte de sécurité lorsque vous essayez d'accéder au répertoire imbriqué, même si vous avez un accès complet au sous-répertoire.

Nous recherchons des moyens de contourner ce problème, sans déplacer les données de \\server\dir1\dir2\dir3vers \\server\dir4.

Une solution de contournement à laquelle j'ai pensé, mais dont je ne sais pas si cela fonctionnera, consiste à créer une sorte de lien ou de jonction \\server\dir4qui est une référence \\server\dir1\dir2\dir3. Je ne sais pas laquelle des options disponibles (le cas échéant) fonctionnerait à cette fin si l'utilisateur n'a pas d' Read & Executeautorisation sur \\server\dir1\dir2ou \\server\dir1, mais pour autant que je sache, les options sont les suivantes:

  • Lien symbolique NTFS,
  • Jonction,
  • Lien dur.

Donc les questions:

  • Certaines de ces méthodes conviennent-elles pour atteindre mon objectif?
  • Existe-t-il d'autres méthodes de liaison ou de référencement indirect d'un répertoire, que je n'ai pas énumérées ci-dessus, qui pourraient convenir?
  • Y a-t- il des directs solutions qui ne nécessite pas d' accorder Read & Executeà \\server\dir1ou , \\server\dir2mais en permettant l' accès à \\server\dir1\dir2\dir3?

C'est possible. L'utilisateur verrait le répertoire mais s'il n'est pas autorisé à lire, il ne peut pas du tout voir le contenu du répertoire, assez facile à configurer.
Ramhound

C'était aussi ma question. Merci d'avoir soulevé la discussion. Et d'avoir mis à jour votre question pour refléter immédiatement que votre supposition était fausse.
tyron

Réponses:


15

Vous vous trompez dans votre hypothèse d'origine, ce qui rend le reste de votre question théorique.

L'autorisation minimale dont un utilisateur aurait besoin dir1et dir2est Traverse Directory. Ce sera très probablement problématique pour vos utilisateurs, donc je recommanderais Traverse Directory et List Folders . Ils pourront naviguer dans les deux principaux répertoires et arriver dir3là où ils ont le plus d'autorisations, mais ne verront même pas quels fichiers existent dans les deux principaux répertoires.

Les autorisations comme Read & Executeet ne Modifysont que des collections d'autorisations individuelles. Ils sont la première chose que vous voyez, car ils sont les plus couramment utilisés. Si vous devez être très précis (comme dans cette situation), cliquez sur le Advancedbouton et explorez les options qui y sont répertoriées.


Excellente information (2)! Mais il y a quelque chose que je n'ai pas rattrapé: "Ce sera très probablement problématique pour vos utilisateurs". Pourquoi serait-ce problématique? La dénomination est assez simple dans le sens où "Traverse" semble la seule autorisation nécessaire. À quel type de problèmes les utilisateurs doivent-ils s'attendre?
tyron

12

Étonnamment, si l'individu a le chemin d'accès complet à un sous-dossier sur lequel il dispose d'au moins des autorisations R, il ne nécessite AUCUNE autorisation sur aucun des dossiers parents, même pas traversé. Ils peuvent simplement y accéder en utilisant l'UNC. (Ils doivent, bien sûr, avoir des autorisations de lecture sur le partage; mais pas sur les dossiers au-dessus du niveau auquel ils veulent accéder).

Je ne le croyais pas quand on me l'a dit, mais les tests le prouvent.

Cela va à l'encontre de ce que je pensais connaître des autorisations dans le monde Windows, et je pense que cela surprendra beaucoup de gens.

\ server \ folder1 \ folder2 \ folder3

S'il n'y a aucune autorisation pour Bilbo sur dossier1 et sur dossier2, mais que Bilbo a modifié (par exemple) sur dossier3, \ serveur \ dossier1 \ dossier2 \ dossier3 le mènera là, pas de problème.


Cela fonctionne lorsque les folder1autorisations SHARE et NTFS sont définies sur folder3Donc, cela \\server\c$\folder1\folder2\folder3ne fonctionnera pas.
user2304170

1
Pour ajouter à cette réponse, cette «capacité» implicite de parcourir les dossiers parents vers un sous-dossier, aussi profond soit-il, auquel vous avez accès est accordée par le droit d'utilisateur appelé «Contournement de la vérification des chemins» accordé par défaut dans la stratégie de groupe pour la plupart / tous les utilisateurs dans la plupart des cas. Voir itprotoday.com/management-mobility/… car je ne peux pas en coller suffisamment ici pour capturer la liste de ce qui obtient l'autorisation dans quelles circonstances.
Tour

Bypass Traverse Checking en tant que droit existe également en tant qu'amélioration des performances NTFS pour permettre d'ignorer la vérification des autorisations de chaque dossier dans l'arborescence sur la façon d'ouvrir le dossier / fichier final souhaité, il n'est donc pas suggéré de le supprimer sauf si vous savez que vous avez besoin ce niveau de sécurité extrêmement élevé.
Tour

1

Une solution similaire à MDMarra consiste à définir les autorisations NTFS comme suit:

  1. dir1 : Accorder le contenu du dossier de la liste (dossier de cheminement / fichier d'exécution, dossier de liste / lecture des données, lecture des attributs, lecture des attributs étendus, autorisations de lecture)
  2. MAIS sélectionnez ce dossier uniquement pour la liste déroulante Appliquer à
  3. dir2 : Accorder le contenu du dossier de la liste et appliquer à ce dossier uniquement
  4. dir3 : Accordez les autorisations de lecture / écriture souhaitées et Appliquer à ce dossier, sous-dossiers et fichiers ou Sous-dossiers et fichiers uniquement

Le résultat final est que l'utilisateur / groupe peut lire chaque dossier parent individuel et explorer le dossier enfant sans aucun autre dossier ou fichier.


Ce n'est pas similaire à la réponse de MDMarra, qui est la réponse de MDMarra, précisées plus en détail.
Scott

0

J'ai donc testé cela dans l'environnement suivant car je voulais obtenir une réponse finale et testée, sur les autorisations minimales requises pour parcourir simplement les dossiers via la navigation (c'est-à-dire via l'Explorateur de fichiers Windows). Voici les résultats pour ceux qui veulent verrouiller les choses.

Je n'ai pas encore testé cela en production pour voir s'il y a des effets secondaires étranges en réduisant le modèle de droits de traversée "standard" bien testé de

  • Dossier transversal
  • Dossier de liste
  • Lire les attributs
  • Lire Ext. Les attributs
  • Lire les autorisations

... qui est fondamentalement juste des autorisations normales de "lecture et exécution" limitées à "ce dossier". Cela dit, les tests à petite échelle ont été complètement satisfaisants jusqu'à présent pour les utilisateurs qui se contentent de déplacer, copier et supprimer des fichiers sur le serveur et les utilisateurs qui travaillent complètement à partir des copies de documents du serveur, etc.


Environnement:

  • Serveur : Windows 2008 R2 - Peu ou pas de stratégie de groupe, rien n'a changé concernant les droits des utilisateurs, configuré comme contrôleur de domaine, DNS intégré à AD, configuration très standard / basique.
  • Client : Windows 7 SP1 - Nettoyer l'installation dans une machine virtuelle, redémarrée entre toutes les modifications pour garantir que la connexion au serveur a été entièrement recréée à chaque fois.
  • Les deux installations ont été corrigées au moins jusqu'à la fin de 2017, donc probablement à jour pour tout ce qui concerne les autorisations qui sont très intégrées à ce stade de la chronologie de Windows.
  • Cela accédait à un dossier partagé monté en tant que lecteur réseau persistant (\ server \ share -> S :) dans la machine virtuelle. Les autorisations de partage étaient le groupe Lecture + Modification pour les utilisateurs authentifiés, qui couvre l'utilisateur test et tous les autres susceptibles d'avoir besoin d'un accès à un moment donné.
  • Après chaque modification, je redémarrais la machine virtuelle, ouvrais l'explorateur de fichiers et parcourais simplement le partage normalement, en suivant un chemin que je savais que l'utilisateur de test avait ces droits de traversée sur ceux qu'il n'avait pas.

Résultats:

  • Requis sur le dossier racine : ListFolder-ReadData + ReadAttributes (2x autorisations)
  • Obligatoire sur les sous - dossiers : ListFolder-ReadData (autorisation 1x)
  • Facultatif : TraverseFolder - ExecuteFile

    -> Cette autorisation facultative n'a d'importance que si le droit d'utilisateur de contournement de la vérification de la traversée a été explicitement refusé, car il est activé par défaut dans 99% des cas. Autrement dit, l'activation du droit d'utilisateur "Contourner la vérification de cheminement" (exposé dans la stratégie de groupe, pas dans les autorisations de fichier / dossier NTFS) supprime complètement ce privilège et rend effectivement ce privilège activé partout par défaut. Remarque: Je n'ai pas testé pour voir si un refus explicite de ce droit, à son tour, empêcherait le droit d'utilisateur de contournement de la vérification transversale de prendre effet dans cette instance particulière, mais cela pourrait le faire).

Informations supplémentaires: Le droit d'utilisateur "Contourner la vérification de cheminement" permet à une personne de passer passivement à un sous-dossier, quelle que soit la profondeur de son accès, (c'est-à-dire que les autorisations sont définies sur ce fichier / dossier, mais pas nécessairement ailleurs plus haut) le chemin du fichier).

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.