none
Probleme Permissions NTFS sur la racine d'un lecteur RRS feed

  • Question

  • Bonjour à tous,

    Je ne comprends pas le fonctionnement de l'héritage des permissions NTFS depuis la racine d'un lecteur. Prenons l'exemple ci dessous :

    Formattage d'un disque dur ayant la lettre D: sur un serveur de fichier WS2016 membre d'un domaine Active Directory. Les droits NTFS positionnés par défaut après le formatage sont les suivants :

    -"Tout le monde" : lecture seule

    - Groupe Administrateurs local : Contrôle Total

    - Groupe utilisateurs locaux : modifications

    - créateur propriétaire : contrôle total

    Voici la problématique :

    Si un compte ad, membre du groupe domains admin (domains admin est membre du groupe administrateurs local du serveur) créé un dossier sous D: , son compte user se positionne dans les permissions NTFS du dossier créé. Hors, ce n'est pas normal et logique. Le compte étant membre du groupe administrateurs, il ne doit pas s'ajouter aux permissions NTFS.

    Ce problème parait ne pas en être un au premier abord, mais imaginons qu'un admin, membre du groupe domains admins souhaite résoudre un problème de permissions NTFS sur un partage contenant une arborescence complexe avec des milliers de fichiers. le compte admin en question, en rentrant dans le dossier racine du partage, va se positionner sur l'ensemble des dossiers, sous dossiers et fichier de l'arborescence, ce qui peut poser problème et provoquer des dysfonctionnement dans l'héritage des permissions.

    Il y a t-il une solution pour éviter qu'un compte membre du groupe admin ne se positionne pas dans les permissions NTFS lors de la création ou consultation de la ressource ?


    • Modifié NICOLOUSC vendredi 11 octobre 2019 07:35
    jeudi 10 octobre 2019 20:57

Toutes les réponses

  • Bonjour,

    Ce comportement est totalement normal puisqu'il y a un droit "CREATEUR PROPRIETAIRE" positionné sur le parent.

    Du coup, tout élément créé sur ce volume disposera, pas défaut, d'un droit "Contrôle Total" pour l'utilisateur ayant créé l'élément.

    Pour ne pas avoir ce comportement, il faut retirer l'entrée "CREATEUR PROPRIETAIRE" des droits NTFS du volume.


    Cordialement,

    Sylvain (MCP, MCTS Windows Server 2008 R2 Server Virtualization, MCTS Exchange 2010)

    WWW : http://snsv.consulting | Blog : http://sylvaincoudeville.fr

    "Aléatoire" et "Mystérieux" sont des qualificatifs inventés par l'Homme pour éviter de dire qu'il n'a pas trouvé la root cause du problème...

    • Proposé comme réponse matteu31400 dimanche 13 octobre 2019 11:53
    vendredi 11 octobre 2019 06:09
  • J'ai trouvé une solution de contournement : En désactivant le démarrage des comptes administrateurs en mode ' Approval" (dans les Policy local du serveur ou via GPO), les comptes admins ne se positionnent plus sur les permissions NTFS, seul le groupe Administrateurs est présent.
    vendredi 11 octobre 2019 13:37
  •  Hors, ce n'est pas normal et logique. Le compte étant membre du groupe administrateurs, il ne doit pas s'ajouter aux permissions NTFS.

    C'est tout à fait normal et voulu. Par défaut, même un administrateur est simple utilisateur et il doit confirmer lorsqu'il veut utiliser ses droits d'admins (UAC).

    Donc si tu as un dossier ou les utilisateurs n'ont pas accès, lorsque l'admin y accède il a une notification de ce genre :

    En validant cela rajoute nominativement le compte admin dans les listes d'autorisations, et même s'il fait parti du groupe administrateurs déjà membre.

    Je suppose que tu parles de ce paramètre dans les GPO ?

    https://docs.microsoft.com/fr-fr/windows/security/threat-protection/security-policy-settings/user-account-control-admin-approval-mode-for-the-built-in-administrator-account

    En modifiant le paramètre tu reduis la sécurité du poste...

    vendredi 11 octobre 2019 14:09
  • Oui c'est bien ce paramètre et je te rejoins concernant la réduction de la sécurité.

    Nous avons un serveur DFS configuré dans notre société, où le paramètre "admin approval mode" est bien activé.

    Pour autant, lorsque nous consultons les répertoires de ce serveur avec un compte admin du domaine, le compte ne se positionne pas dans les permissions NTFS. La configuration des permissions NTFS est pourtant identique, d'où mon interrogation.

    Merci pour ton aide.

    vendredi 11 octobre 2019 15:13
  • L'UAC ne contrôle que l'utilisation du groupe administrateurs. Si tu mets dans les permissions NTFS le groupe admins du domaine ou un autre groupe dont l'utilisateur est membre, tu n'aura pas le phénomène. 

    La modification par le contrôle et qui ajoute le compte nominativement, permet au compte d'accéder aux contenus sans utiliser les droits administrateurs. La confirmation n'est demandé que la première fois afin d'ajouter les droits à l'utilisateurs.

    L'utilisateurs membre de admins du domaine lorsqu'il ouvre la session sur le serveur reçoit un jeton avec tous les groupes dont il est membre et hérités. Seul l'utilisation de l'identifiant lié à "administrateurs" est contrôlé. 

    Tu peux voir les groupes dans le jeton avec Whoami /groups

    vendredi 11 octobre 2019 17:01
  • Bonsoir, je viens de faire le test :

    - en ajoutant le groupe admins du domaine dans les permissions NTFS de la ressource, le phénoméne se produit toujours: le compte admin se positionne sur l'ensemble des sous dossiers et des fichiers dans l'arborescence.

    - création d'un groupe de sécurité nommé "GG-ADMINS" /Ajout du compte adm en tant que membre de ce groupe/ Positionnement de ce groupe à la racine de la ressource avec comme permissions NTFS "FULL CONTROL" : avec cette façon de procéder, le phénomène ne se produit plus, le compte admin peut explorer l'arborescence, son compte n'est pas ajouté aux permissions NTFS de l'arborescence.

    Merci pour cet échange Philippe. Bonne soirée,

    Nicolas.


    • Modifié NICOLOUSC vendredi 11 octobre 2019 19:06
    vendredi 11 octobre 2019 19:02