Question Changer des droits via le compte system

Bonjour bonjour !

J'aurai besoin d'un coup de main

Je débute un peu sur Powershell. Je suis sorti de l'IMIE avec le titre T2SI et je continu à l'ENI en ASR
J'ai donc vu les bases de powershell 2 fois via 2 écoles. J'utilise déjà un peu de powershell pour extraire des données d'exchange ou de d'une AD... rien de bien méchant. Donc voilà, j'ai encore du taf


Je pose le décor :

- 3 serveurs RDS avec profils itinérant de bureau à distance qui pointent sur un 4ème serveur ou sont donc stockés les profils.

- les droits de chaque profils (V2) sont en full pour le propriétaire et le système.

Le problème est qu'il y a beaucoup de profils qui sont pollué et/ou sont victime de mauvaise pratique informatique. J'aimerai les nettoyer via des scripts powershell. Je n'ai aucun droits sur ces dossiers profils (sauf les nouveaux, rendu accessible via une gpo qui ajoute le compte admin')

J'ai donc tenté de lancer un script via le planificateur de tâche avec le compte système mais sans succès.


Voici un bout de code piqué sur le net remixé (bricolé ?) par mes soins.
[code:1]#constantes
$inherit = [System.Security.AccessControl.InheritanceFlags]\"ContainerInherit, ObjectInherit\"
$propagation = [System.Security.AccessControl.PropagationFlags]\"None\"

#chemin
$chemin=\"D:\Profilts\test\"

$reps = get-childitem $chemin -Recurse

foreach($rep in $reps)
{
$SecIdentity = \"Administrateurs\"
$AccessRights = \"FullControl\"
$AccessControlType = \"allow\"
$acl = Get-Acl $rep.fullname #-ErrorVariable ErrGetACL
$ar = New-Object System.Security.AccessControl.FileSystemAccessRule($SecIdentity, $AccessRights, $inherit, $propagation, $AccessControlType)
$acl.AddAccessRule($ar)
set-Acl -Path $rep.FullName -AclObject $acl
}
$aclD=Get-Acl $chemin
$aclD.AddAccessRule($ar)
Set-Acl -Path $chemin -AclObject $aclD[/code:1]
Ce script fonctionne avec powershell ISE sur une machine local juste pour le rajout de droits sur un dossier dont j'ai déjà l'accès.

Voilà donc s'il y a des idées je prends, des idées neuves je prends aussi. Sinon j'avais pensé changer le propriétaire temporairement, appliquer les droits et rebasculer sur le propriétaire original... bref

Merci d'avance <br><br>Message édité par: Fabz, à: 30/12/15 16:47

salut fabz

Sinon j'avais pensé changer le propriétaire temporairement, appliquer les droits et rebasculer sur le propriétaire original... bref

c'est évidemment le plus simple et le plus rapide, le retour du propriétaire d'origine n'est pas indispensable sauf si tu doit recherché l'origine d'un fichier !

sauf les nouveaux, rendu accessible via une gpo qui ajoute le compte 'admin'

je suppose que tu a mis le compte 'admin' à la base de tes dossiers profils, qui va ce propagé automatiquement sur les dossiers des profils automatiquement si dans ta GPO tu a désactivé dans la redirection de dossiers option \&quot;Accorder à l’utilisateur des droits exclusifs sur ... AppData(Roaming)\&quot;
a tu regardé l'option \&quot;Ajouter le groupe de sécurité administrateurs aux profils itinérants utilisateurs\&quot; dans \&quot;ordinateur/Stratégies/Modèles d’administrationafficher/Système/Profil des utilisateursafficher\&quot; expliqué ici chez microsft
tu n'aura donc plus besoin de ton script !

sur cette article , trouvera quelques explications pour ça solution de l'itinérance ou il rajoute la redirection des dossiers utilisateurs mais n'a pas fini l'article par contre le site contient de nombreux tutos sur de nombreux sujets comme l'AD, powershell, ...

Salut ! Merci pour ta réponse

J'avais des craintes concernant le \&quot;switchage\&quot; de propriétaire pour le fonctionnement des profils RDS, je ne sais pas quel impact ça pourrait avoir.


Pour ce qui est des nouveau, je n'ai rien rajouté en faite. C'est une GPO spécifique pour cette action en particulier. J'ai vu ça sur le labo-microsoft . C'est bien la GPO dont tu me parle sauf que cette GPO est valable que pour les nouveaux profils pas ceux existant. Donc au final, j'ai bien besoin d'un script

J'ai eu l'idée d'une tâche planifiée via cette page , en bas.

Créez un script (par exemple, à l'aide de Windows PowerShell) exécutant les actions suivantes :

S'exécute en tant que SYSTEM sur la machine du partage (host.name.fqdn dans cet exemple)

Ajoute le groupe de sécurité Administrateurs à la liste de contrôle d'accès (ACL) des dossiers de profil avec propagation à tous les sous-dossiers et fichiers.

Ajoute le groupe de sécurité Administrateurs avec le Contrôle total à la liste de contrôle d'accès (ACL) aux dossiers de profil et hérite de l'autorisation de tous les sous-dossiers et fichiers.

A l'heure actuelle il y a déjà des redirections de dossier pour les documents, à terme il en faudrait d'autre car le dossier téléchargement ou même le bureau est parfois rempli... du coup, quand on purge les profils, le transfert est parfois long

Je vais chercher pour changer d'owner... tester vite fais avant si en gardant \&quot;administrateurs\&quot; ça dégrade pas le bon fonctionnement d'une session.

to be continued

J'avais des craintes concernant le \&quot;switchage\&quot; de propriétaire pour le fonctionnement des profils RDS, je ne sais pas quel impact ça pourrait avoir.

j'ai eu le même soucis de profils RDS pour des besoins d'assistances à distances et de copies de documents directement dans les profils sur mes premiers profils TSE.
j'avais forcé le changements de propriétaires sans effet negatif sur les utilisateurs !
mais il me semble me souvenir (déjà 3 ans) que l'héritage des permissions n'est pas actif par default, il faut donc aussi s'en occupé !
moi je l'avais fait à la main pour la dizaines qui avais été créé à l'époque pour les tests, mais maintenant ce serais plus possibles.
Ou alors tu casse les droits par défaut pour tous les dossiers de tous les profils en forçant la propagations des droits depuis le dossier de base.
ta solution semble donc plus efficace en temps de travail et surtout moins brutale !

J'ai eu l'idée d'une tâche planifiée via cette page, en bas.

pour le point 3 ok même si une GPO execution d'un script à l'ouverture de session suffit
mais pour le point 2 (S'exécute en tant que SYSTEM sur la machine du partage) je vois pas comment tu va faire avec les tâches planifiées ? il n'est pas prévu d'exécution en tant que system ! mais j'ai jamais fais !
par contre une GPO au démarrage du serveur oui, ça lance les script en tant que system.
vu qu'il faut l'exécuté qu'une seule fois, ça peut suffire si tu peut arrête le serveur !

n'oublie pas de faire des tests sur un serveur de test bien sur, et de ne pas faire aveuglément ce que tu trouve sur les forums, y compris mes conseils !!! <br><br>Message édité par: 6ratgus, à: 31/12/15 15:23