MENU
  1. Accueil
  2. Windows
  3. Windows Server
  4. Windows/AD : Lecteur C disparu après ajout à un groupe — diagnostic GPO & ACL, correctifs pas‑à‑pas

Windows/AD : Lecteur C disparu après ajout à un groupe — diagnostic GPO & ACL, correctifs pas‑à‑pas

Windows Server

Un utilisateur Active Directory voit le lecteur C: disparaître d’Explorateur Windows après son ajout à un groupe de sécurité. Voici un guide complet pour identifier la GPO ou les ACL en cause et restaurer l’accès.

Sommaire

Vue d’ensemble de la question

Scénario typique en environnement d’entreprise : un compte AD fraîchement créé accède normalement au lecteur local C:\. Dès que ce compte est ajouté à un ou plusieurs groupes de sécurité, l’icône du lecteur n’apparaît plus dans l’Explorateur Windows. Dans la grande majorité des cas, cela résulte soit d’une stratégie de groupe (GPO) configurée pour masquer ou bloquer l’accès aux lecteurs, soit d’autorisations NTFS appliquées sur la racine du disque via GPO (ou manuellement), soit encore d’un mappage/redirection qui modifie l’expérience d’Explorateur.

Objectifs de ce guide :

  • Isoler précisément la GPO, le filtrage sécurité ou le ciblage WMI impliqué.
  • Diagnostiquer s’il s’agit d’un simple masquage (icône cachée) ou d’un vrai refus d’accès (ACL).
  • Corriger durablement sans impacter les autres utilisateurs.
  • Outiller l’équipe IT avec des scripts, tableaux et check-lists.

Diagnostic rapide : distinguer « masqué » vs « bloqué »

Symptôme observéCause la plus probableTest immédiatAction prioritaire
Le lecteur C: n’apparaît pas dans « Ce PC » mais C:\ s’ouvre via la barre d’adresse ou Win+R > C:\Masquage par stratégie : Hide these specified drives / NoDrivesTaper C:\ dans Exécuter ou l’explorateur : si l’arborescence s’ouvre, c’est un masquageIdentifier la GPO utilisateur/ordinateur qui positionne NoDrives/NoViewOnDrive et la corriger
Accès refusé (« Accès refusé »)ACL NTFS trop restrictives sur C:\ appliquées par GPO (File System)icacls C:\ ou onglet Sécurité : vérifier droits Users / utilisateurRétablir les droits NTFS minimums (Read & Execute) et corriger la GPO « File System »
Disparition corrélée à l’ajout au groupe XFiltrage sécurité GPO, ciblage WMI ou item-level targeting conditionné au groupe Xwhoami /groups puis gpresult /h pour voir Winning GPOAdapter le filtrage (Autoriser/Refuser « Apply Group Policy ») ou revoir la logique de ciblage

Réponse & solution : procédure détaillée

Isoler la GPO responsable

  1. Depuis le poste impacté, générer un rapport des stratégies réellement appliquées : gpresult /h C:\Temp\rapport-gpo.html gpresult /scope user /v gpresult /scope computer /v rsop.msc Ouvrez le rapport HTML : repérez la section User Settings et Computer Settings, puis recherchez « File Explorer », « Windows Explorer », « NoDrives » et « NoViewOnDrive » pour identifier la Winning GPO (celle qui applique la valeur effective).
  2. Dans la GPMC, inspectez les emplacements clés :
    • User Configuration → Administrative Templates → Windows Components → File Explorer
      Paramètres Hide these specified drives in My Computer et Prevent access to drives from My Computer.
    • Également, vérifiez l’équivalent sous Computer Configuration → Administrative Templates → Windows Components → File Explorer (prend effet côté ordinateur, ou via loopback).
    • User Configuration → Windows Settings → Folder Redirection et Preferences → Windows Settings → Drive Maps (mappages pouvant altérer l’affichage).
    • Computer Configuration → Windows Settings → Security Settings → File System (ACL imposées sur C:\).
  3. Vérifiez la boucle de traitement utilisateur si des GPO « User » se déclenchent en fonction de l’OU de l’ordinateur : Computer Configuration → Administrative Templates → System → Group Policy → User Group Policy loopback processing mode (Modes Merge ou Replace).

Contrôler les groupes de sécurité

  • Exécutez whoami /groups sur le poste pour lister les groupes effectifs. Comparez l’état « avant » et « après » ajout au groupe.
  • Dans la GPMC, ouvrez la GPO suspecte et examinez Security Filtering, les Delegations et les WMI Filters. Il est courant qu’un filtrage « Apply Group Policy » ou un ciblage WMI/élément soit conditionné à l’appartenance à un groupe.
  • Test de corrélation : retirez temporairement l’utilisateur du groupe soupçonné. Après gpupdate /force et reconnexion, si C: réapparaît, vous avez identifié la piste.
  • Correctifs recommandés :
    • Si la GPO ne doit pas viser cet utilisateur : retirez-le du filtrage, ou appliquez-lui Deny: Apply Group Policy.
    • Si la GPO est trop large : créez un groupe « cible » explicitement listé dans le filtrage, et excluez les autres.
    • Révisez les GPO liées avec Enforced et l’order des liens (la GPO « Enforced » prévaut en conflit).

Vérifier et corriger les autorisations NTFS

Sur la racine C:\, un utilisateur standard doit disposer au minimum de Read & Execute et List folder contents. Une GPO « File System » peut écraser ces droits.

  1. Inspectez les ACL : icacls C:\ Vérifiez la présence de BUILTIN\Users (ou du groupe de l’utilisateur) avec des droits de lecture/exécution. S’il n’y a qu’Administrators et SYSTEM, l’utilisateur pourra voir C: masqué ou non, mais l’accès échouera.
  2. Si une GPO a imposé de mauvaises ACL :
    • Dans la GPO : Computer Configuration → Windows Settings → Security Settings → File System, corrigez les entrées (héritage, propagation, droits).
    • Appliquez gpupdate /force et testez à nouveau.
  3. Attention : éviter les remises à zéro massives du système (ex. icacls C:\ /reset /t /c ou secedit) en production sans sauvegarde et fenêtre de maintenance. Préférez corriger précisément la GPO.

Inspecter le Registre pour les clés de masquage

Deux valeurs contrôlent le masquage et le blocage via l’Explorateur :

  • HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\NoDrives
  • HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\NoViewOnDrive

Les mêmes peuvent exister sous HKLM\... (portée ordinateur). Une valeur non nulle indique un masquage/bloquage. Exemple de lecture rapide :

reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer" /v NoDrives
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer" /v NoViewOnDrive

Comprendre la valeur binaire (bitmask)

Chaque lettre de lecteur correspond à un bit (A=bit 0, B=bit 1, C=bit 2, … Z=bit 25). Exemples fréquents :

Lecteurs cachésDécimal (DWORD)Hexa
C: uniquement40x00000004
D: uniquement80x00000008
A: et B:30x00000003
A:, B:, C:70x00000007
A:, B:, C:, D:150x0000000F
Tous les lecteurs (A–Z)671088630x03FFFFFF

Pour remettre à zéro le masquage côté utilisateur (après sauvegarde de la ruche) :

reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer" /v NoDrives /t REG_DWORD /d 0 /f
reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer" /v NoViewOnDrive /t REG_DWORD /d 0 /f

Si les clés reviennent après connexion, c’est qu’une GPO les réapplique, d’où l’importance d’identifier la Winning GPO.

Analyser les journaux d’événements

  • Observateur d’événements → Applications and Services Logs → Microsoft → Windows → GroupPolicy → Operational pour suivre l’application des GPO (succès/échec, liste des GPO appliquées, ordre).
  • System et Application : erreurs de traitement de stratégie, de redirection de dossiers, ou d’accès au Registre/FS.
  • Si vous auditez les changements de groupes, corrélez l’heure d’ajout de l’utilisateur au groupe et le premier logon où C: disparaît.

Réplication et actualisation

  • Vérifiez la réplication AD (contrôleurs de domaine) pour s’assurer que la modification de groupes est propagée.
  • Sur le poste : gpupdate /force, puis fermeture/rouverture de session (voire redémarrage) pour valider.

Playbook opérationnel (pas-à-pas reproductible)

  1. Constater : l’utilisateur ne voit pas C: dans l’Explorateur mais vient d’être ajouté au groupe G1.
  2. Tester : Win+R > C:\.
    • Si l’arborescence s’ouvre → cas « masquage » (GPO).
    • Si « Accès refusé » → cas « ACL ».
  3. Capteurs : gpresult /h (utilisateur & ordinateur), whoami /groups, icacls C:\.
  4. Isoler la GPO : dans le rapport, repérer « Hide these specified drives »/« Prevent access to drives » ou une entrée File System sur C:\ avec des ACL restrictives.
  5. Valider la corrélation groupe⇄GPO : retirons temporairement l’utilisateur de G1 ou excluons G1 de la GPO (Deny Apply) → gpupdate → test.
  6. Corriger :
    • Pour le masquage non désiré : désactiver le paramètre ou limiter la portée de la GPO (filtrage sécurité/WMI).
    • Pour l’accès bloqué : rétablir les ACL standard sur C:\ via la GPO File System (au moins Read & Execute pour les utilisateurs).
  7. Stabiliser : documenter la dépendance GPO↔groupes, créer un compte témoin pour tests futurs, et mettre en place une policy baseline.

Scripts utiles (diagnostic & audit)

PowerShell : décoder NoDrives/NoViewOnDrive

# Exécuter en tant qu'utilisateur impacté
$paths = @(
  'HKCU:\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer',
  'HKLM:\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer'
)
foreach ($p in $paths) {
  if (Test-Path $p) {
    '--- ' + $p + ' ---'
    Get-ItemProperty -Path $p -Name NoDrives,NoViewOnDrive -ErrorAction SilentlyContinue |
      ForEach-Object {
        $_.PSObject.Properties | Where-Object { $_.Name -in 'NoDrives','NoViewOnDrive' } | ForEach-Object {
          $val = [int64]$_.Value
          $letters = 0..25 | Where-Object { $val -band (1 -shl $_) } | ForEach-Object { [char]([byte](65+$_)) + ':' }
          '{0} = {1} ({2}) → {3}' -f $_.Name,$val,('0x{0:X8}' -f $val),($letters -join ' ')
        }
      }
  }
}

PowerShell : lister les GPO contenant NoDrives/NoViewOnDrive

# Nécessite GPMC (module GroupPolicy)
$report = Get-GPOReport -All -ReportType Xml
[xml]$xml = '<root>' + ($report -join '') + '</root>'
$hits = $xml.root.GPO | Where-Object {
  $_.User.ExtensionData.Extension.Policy |
  Where-Object { $_.name -match 'NoDrives|NoViewOnDrive' }
}
$hits | ForEach-Object {
  $_.DisplayName
}

CMD : groupes effectifs, GPO appliquées, droits C:\

whoami /groups
gpresult /r
gpresult /h C:\Temp\rapport-gpo.html
icacls C:\

Points d’attention et bonnes pratiques

  • Masquer n’est pas protéger : le paramètre « Masquer ces lecteurs spécifiés » ne modifie pas les droits. Le lecteur reste accessible par chemin direct si l’ACL le permet.
  • Durcissement : pour un environnement réellement restreint, complétez par AppLocker ou une stratégie d’accès aux applications, et un durcissement NTFS ciblé (au lieu d’un masquage global).
  • Loopback : en mode Merge ou Replace, des paramètres « User » peuvent s’appliquer en fonction de l’OU de l’ordinateur. Vérifiez toujours la présence de loopback sur les machines concernées.
  • Ordre des liens & Enforced : une GPO « Enforced » peut gagner sur d’autres. L’ordre des liens dans l’OU et l’héritage bloqué influent sur le résultat final.
  • Mappages & Redirections : une redirection de dossiers mal conçue, combinée à des mappages via GPP, peut donner l’impression que des lecteurs « disparaissent ». Débranchez temporairement ces éléments pour isoler la cause.
  • Documentation : consignez la logique « GPO ↔ groupes cibles » (qui, quoi, où, pourquoi). Ajoutez un « compte témoin » par OU pour rejouer les tests.

Modèles de correction courants

Cas 1 : masquage accidentel via « Hide these specified drives »

Symptôme : C: n’apparaît pas, mais l’accès direct fonctionne.

Correction : dans la GPO identifiée, positionnez « Hide these specified drives » sur Not configured (ou une valeur n’excluant pas C:), et supprimez NoDrives/NoViewOnDrive si configurés via Preferences.

Cas 2 : blocage via ACL sur C:\

Symptôme : « Accès refusé » sur C:\ y compris par le chemin direct.

Correction : dans la GPO « File System », restaurez au minimum Read & Execute pour Users, vérifiez l’héritage et évitez de casser les ACL système. Validez sur un groupe pilote avant déploiement global.

Cas 3 : GPO appliquée via loopback

Symptôme : seuls les PC d’une OU donnée masquent C:, quel que soit l’utilisateur.

Correction : ajustez la GPO au niveau ordinateur, ou remontez la GPO « utilisateur » hors du périmètre loopback. Dans le doute, scindez les paramètres User/Computer en GPO distinctes.

Tableau de correspondance (Registre & GPO)

GPO (ADMX)Registre (clé/valeur)EffetPortée
Hide these specified drives in My Computer…\Policies\Explorer\NoDrives (DWORD)Masque l’icône des lecteurs ciblésUtilisateur ou Ordinateur (selon emplacement)
Prevent access to drives from My Computer…\Policies\Explorer\NoViewOnDrive (DWORD)Empêche l’accès via l’ExplorateurUtilisateur ou Ordinateur
File System (Security Settings)ACL NTFS sur C:\Autorise/refuse réellement l’accèsOrdinateur

Checklist de validation après correction

  • gpupdate /force exécuté, session refermée/rouverte.
  • gpresult /h : le paramètre fautif n’apparaît plus comme « appliqué ».
  • reg query : NoDrives = 0 et NoViewOnDrive = 0 (ou inexistants).
  • Explorateur : C: visible et accessible. Accès direct C:\ fonctionnel.
  • Pas d’effet de bord sur les autres utilisateurs/GPO (échantillon pilote validé).

Bonnes pratiques de gouvernance GPO

  • Séparer les paramètres par rôle : GPO « User Experience » (UX) distincte des GPO « Security/ACL ».
  • Nommer clairement : préfixes UX-, SEC-, APP-, etc. Ajoutez la portée (User/Computer) et l’OU cible.
  • Contrôle de changement : processus d’approbation, tests en lab, puis ring deployment (pilote → large).
  • Documentation : schéma d’héritage et de filtrage, justification du loopback, WMI filters, item-level targeting.
  • Surveillance : journal GroupPolicy/Operational sur un échantillon de machines, plus un rapport périodique Get-GPOReport.

FAQ éclair

Q : Masquer C: suffit-il pour empêcher l’exécution d’applications ?
R : Non. Le masquage ne change pas les droits. Utilisez AppLocker/WDAC et durcissez NTFS pour contrôler ce qui s’exécute et ce qui est accessible.

Q : Pourquoi l’utilisateur A voit C: sur PC1 mais pas sur PC2 ?
R : Probablement une GPO appliquée à l’OU de PC2, ou un mode loopback actif. Comparez gpresult entre les deux machines.

Q : Comment exclure un seul groupe de l’effet d’une GPO ?
R : Dans Delegation ou Security Filtering, ajoutez le groupe et cochez Deny: Apply group policy (avec parcimonie) ou, mieux, reformulez le ciblage en liste blanche explicite.

Résumé exécutif

Si le lecteur C: disparaît après l’ajout à un groupe, vous êtes face à une mécanique de stratégie conditionnée par l’appartenance à ce groupe (filtrage sécurité, WMI, item targeting), ou à des ACL NTFS sur C:\ poussées par GPO. Le chemin court : gpresult pour la Winning GPO, whoami /groups pour confirmer la corrélation, icacls pour qualifier masquage vs blocage, puis ajustement précis du filtrage ou des droits. Documentez, validez, et normalisez vos pratiques GPO pour éviter la régression.

Informations complémentaires utiles

  • Le paramètre « Masquer ces lecteurs spécifiés » n’altère pas les ACL : il peut retirer l’icône tout en laissant l’accès via C:\ ou \\localhost\c$ (pour les administrateurs).
  • Pour un environnement réellement restreint, privilégiez AppLocker/WDAC, des ACL NTFS adaptées et, si nécessaire, la virtualisation d’applications.
  • Documentez les dépendances GPO, testez avec un compte témoin par OU, et conservez un rapport Get-GPOReport versionné.

Checklist imprimable

  1. Le lecteur C: est-il visible via C:\ (exécution directe) ?
  2. gpresult /h montre-t-il une GPO « Hide/Prevent access to drives » appliquée ?
  3. Des clés NoDrives/NoViewOnDrive non nulles existent-elles en HKCU/HKLM ?
  4. Les ACL de C:\ autorisent-elles Users en lecture/exécution ?
  5. Existe-t-il un loopback sur l’OU du poste ?
  6. Le groupe nouvellement ajouté est-il dans le filtrage sécurité/WMI de la GPO ?
  7. Après correction : gpupdate, reconnexion et validation utilisateur.
Windows Server
Active Directory Windows PowerShell troubleshooting GPO
Sommaire