Bonjour,
 
Sur mon Active Directory (AD), j'ai créé un groupe de sécurité nommé "Gd-AdminLocal", qui est membre du groupe "Administrateurs locaux" sur le serveur "SRV001" exécutant Windows Server 2012.
 
Normalement, les membres du groupe "Gd-AdminLocal" devraient être administrateurs locaux sur le serveur "SRV001".
 
Cependant, lorsque j'accède au disque C:, certains répertoires, tels que les profils utilisateurs, affichent un message d'erreur : "Vous ne disposez pas des autorisations requises pour accéder à ce dossier. Cliquez sur Continuer pour accéder en permanence à ce dossier."
 
Le groupe "Administrateurs locaux" a bien les droits en lecture/écriture sur ces répertoires.
 
L'étrange, c'est que lorsque j'utilise le compte administrateur local du serveur, je n'ai aucun problème d'accès. En revanche, si j'ajoute un utilisateur AD au groupe "Administrateurs locaux" du serveur, cela ne fonctionne pas. De même, si j'ajoute un utilisateur AD au groupe "Gd-AdminLocal", qui est lui-même membre du groupe "Administrateurs locaux" du serveur, le problème persiste.
 
Je ne comprends pas pourquoi ce message d'erreur apparaît dans ces situations.
 
Pourriez-vous m'aider à comprendre la raison de ce problème ?
 
Merci d'avance pour vos retours

Ca s'appelle l'UAC et ça existe depuis Vista.
Ca permet d'éviter d'avoir les droits admin locaux tout en ayant un compte admin.
Sur le système de fichier ça veut dire des accès refusés. Il faut donc soit explicitement se donner les droits, soit donner les droits à ton groupe gd-adminlocal, soit élever ses privilèges pour avoir le token administrators, soit désactiver l'uac (en gros en dernier recours)

Merci pour ce retour.

C'est étonnant, l'UAC était déjà désactivé sur ce serveur !

Donc le mieux est que je donne des droits en lecture/écriture à mon groupe "Gd-AdminLocal" sur les répertoires correspondants. (Je sais que cela fonctionne)

Tu me confirmes ?

 
il a été désactivé comment ? (la seule manière de le désactiver pour de bon c'est manipuler la valeur de registre EnableLUA avec reboot derrière)
 
Le paramétrage de l'UAC permet une configuration spécifique pour le compteur Administrateur local, ce qui semble bien être le cas vu ce que tu décris, donc l'UAC doit bien être actif.

Le mieux est que tu ne touches pas à ce genre de permissions. Désactiver l'UAC n'est pas supporté et va générer de nombreux problèmes.
Quel est ton besoin à la base, pour aller modifier ce genre de dossiers ?

 
c'est tout à fait supporté    
 
https://learn.microsoft.com/en-us/w [...] -enablelua
 
par contre pas du tout recommandé. Et en 2023 ça ne devrait plus être nécessaire.

Non, c'est toujours techniquement possible mais ce n'est plus supporté depuis un bail.

Bonjour,
 
Désolé du temps de réponse, j'étais en congés.
 
Au final, je pense qu'il est mieux que je donne explicitement les droits.
 
Si j'applique mon groupe AD à la racine du disque C:\, ca devrai le faire. Voyez-vous une méthode plus propre , plus recommandée ?
 

 
Absolument pas.
 
L'héritage des permissions est désactivé sur beaucoup de répertoires sensibles que tu mentionnes comme le système, les profils utilisateurs, etc, donc ça ne marchera pas, les droits correspondants à ton groupe ne seront pas propagés. En plus, ce n'est ni propre, ni recommandé.

Quelle solution alors ?

tu n'as pas précisé pourquoi tu dois accèder à ces répertoires protégés. Quel est le besoin ?
 
En général si j'ai besoin de faire ça moi je passe en ligne de commande depuis un CMD élevé à travers l'UAC.

Nous avons nos développeurs qui doivent accéder aux serveurs avec des droits administrateur local.
Pour éviter de mettre chacun de leurs logins AD dans le groupe "administrateur local" de chaque serveur, nous avons un groupe AD qui regroupe nos développeurs. J'aurai aimé donner des droits admin local sur ces serveur via ce groupe AD, histoire de centralisé la gestion sur l'AD

tu ne réponds pas à la question : ça ne dit pas ce qu'ils ont à faire dans les répertoires protégés. A quoi ils ont besoin d'accèder là dedans ?
 
Une délégation admin local c'est une problématique bateau.

Ils doivent modifier des fichiers dans c:\Users

ben ils passent par un prompt élevé dans ce cas et dedans ils lancent le script ou l'outil pour faire les modifs.
 
Les ACL standard sur un profil user c'est Administrators, SYSTEM et le compte auquel appartient le profil en full control, et l'héritage est bloqué sur le dossier parent du profil (C:\users\TOTO).

Leurs demander de faire ça, même pas envisageable ! C'est très compliqué avec cette population.

 
perso je suis à court de "bonne" solution alors.
 
Ca m'inquiète juste un peu quand tu dis que ce sont des devs mais qu'une manoeuvre relativement simple à exécuter et automatiser n'est pas envisageable...

Alors, j'ai quand même testé cette solution :
 
Utilisateur dans un groupe AD. Ce groupe AD dans le groupe administrateur local du serveur.
 
Avec cette utilisateur je me connecte en RDP sur le serveur. J'ouvre l'explorateur Windows avec une élévation de droit.
 
Je vais sur "C:\users\TOTO" et j'ai ce message :
 

 
En ligne de commande (CMD), aucun problème, avec une élévation de droit. Sans élévation, j'ai un accès refusé (normal).
 
Je n'ai pas ce message avec mon compte admin du domaine.

J'ai pas souvenir qu'on puisse élever l'explorateur

En faisait comme ceci :
 

 
Mais cela n'a aucun effet positif.

 
A la racine de c:\users ?
 
Si oui que font ces fichiers à cet emplacement ?

Dans les profils d'utilisateurs   .  
 
Le dev à besoin de purger des fichiers via script présent dans les profils utilisateurs

C'est zarb comme truc.
Mais bon comme indiqué, un script qui se lance via un raccourci et cela fait le job.

Par défaut on ne donne pas de droits admin à des personnes qui ne comprennent rien à l'admin système.
S'il faut juste purger des fichiers via script, pas besoin de délégation AD sur des machines.
Un simple script poussé par GPO/GPP et c'est bon...
Il faut que tu commences par identifier avec précision ce qui doit être purgé, pourquoi, à quel moment et dans quel emplacement.