J'ai un utilisateur de type "utilisateur avec pouvoir",=20
pour lequel je souhaite interdire l'acc=E8s =E0=20
regedit/regedt32.
Je ne veux pas passer par les strat=E9gies et poledit.
J'ai donc mis le DWORD=20
HKCU\Software\Microsoft\Windows\CurrentVersion\=20
Policies\System\DisableRegistryTools dans sa cl=E9=20
utilisateur et mis cette valeur =E0 1.
Pourtant, mon utilisateur a toujours acc=E8s =E0 regedit.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jean-Claude BELLAMY
Dans le message news:1e6901c5020d$ab9890a0$ , Arnaud G s'est ainsi exprimé:
Bonjour,
J'ai un utilisateur de type "utilisateur avec pouvoir", pour lequel je souhaite interdire l'accès à regedit/regedt32.
Je ne veux pas passer par les stratégies et poledit.
J'ai donc mis le DWORD HKCUSoftwareMicrosoftWindowsCurrentVersion PoliciesSystemDisableRegistryTools dans sa clé utilisateur et mis cette valeur à 1.
Pourtant, mon utilisateur a toujours accès à regedit.
J'ai oublié quelque chose ?
Quand tu as modifié la BDR, c'était sous quel compte ? Le tien ou celui de l'utilisateur ?
Car si tu l'as fait sous ton compte, c'est donc la branche HKCU de TA ruche (NTUSER.DAT) qui a été modifiée, et non pas les autres, à la différence de ce que fait POLEDIT ou GPEDIT.
Pour qu'elles puissent s'appliquer à tous les comptes, les modifs faites par ces applis sont stockées dans des fichiers NTCONFIG.POL (NT4) ou REGISTRY.POL (W2K et au-dela) qui sont lus et traités au démarrage.
-- May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org *
Dans le message news:1e6901c5020d$ab9890a0$a401280a@phx.gbl ,
Arnaud G <anonymous@discussions.microsoft.com> s'est ainsi exprimé:
Bonjour,
J'ai un utilisateur de type "utilisateur avec pouvoir",
pour lequel je souhaite interdire l'accès à
regedit/regedt32.
Je ne veux pas passer par les stratégies et poledit.
J'ai donc mis le DWORD
HKCUSoftwareMicrosoftWindowsCurrentVersion
PoliciesSystemDisableRegistryTools dans sa clé
utilisateur et mis cette valeur à 1.
Pourtant, mon utilisateur a toujours accès à regedit.
J'ai oublié quelque chose ?
Quand tu as modifié la BDR, c'était sous quel compte ?
Le tien ou celui de l'utilisateur ?
Car si tu l'as fait sous ton compte, c'est donc la branche HKCU de TA ruche
(NTUSER.DAT) qui a été modifiée, et non pas les autres, à la différence de
ce que fait POLEDIT ou GPEDIT.
Pour qu'elles puissent s'appliquer à tous les comptes, les modifs faites par
ces applis sont stockées dans des fichiers NTCONFIG.POL (NT4) ou
REGISTRY.POL (W2K et au-dela) qui sont lus et traités au démarrage.
--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
Jean-Claude.Bellamy@wanadoo.fr * JC.Bellamy@free.fr
Dans le message news:1e6901c5020d$ab9890a0$ , Arnaud G s'est ainsi exprimé:
Bonjour,
J'ai un utilisateur de type "utilisateur avec pouvoir", pour lequel je souhaite interdire l'accès à regedit/regedt32.
Je ne veux pas passer par les stratégies et poledit.
J'ai donc mis le DWORD HKCUSoftwareMicrosoftWindowsCurrentVersion PoliciesSystemDisableRegistryTools dans sa clé utilisateur et mis cette valeur à 1.
Pourtant, mon utilisateur a toujours accès à regedit.
J'ai oublié quelque chose ?
Quand tu as modifié la BDR, c'était sous quel compte ? Le tien ou celui de l'utilisateur ?
Car si tu l'as fait sous ton compte, c'est donc la branche HKCU de TA ruche (NTUSER.DAT) qui a été modifiée, et non pas les autres, à la différence de ce que fait POLEDIT ou GPEDIT.
Pour qu'elles puissent s'appliquer à tous les comptes, les modifs faites par ces applis sont stockées dans des fichiers NTCONFIG.POL (NT4) ou REGISTRY.POL (W2K et au-dela) qui sont lus et traités au démarrage.
-- May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org *
Arnaud G
Merci JC, en fait, c'est un peu particulier, j'utilise l'application Zenworks de Novell, qui permet de distribuer des stratégies sans passer par POLEDIT. Je n'ai pas la confirmation sur la manière dont ça fonctionne, mais je pense (à 99,99%) qu'il se contente d'effectuer les modifications du registre sans passer par des vraies notions de stratégies, au sens Microsoft du terme.
Je te confirme que ma modification est bien faite sur le compte utilisateur et non sous mon compte, car je l'ai vérifiée à partir de regedt32 dans lequel j'ai chargé le NTUSER.DAT de mon utilisateur, et consulté la clé concernée, dans sa branche HKCU.
Elle contient bien mon DWORD "DisableRegistryTools" dont la valeur est 1.
A savoir que j'ai déjà fait cette opération dans le passé et ça fonctionnait parfaitement.
Cependant, je ne pense pas que Zenworks soit la source du problème, puisque ce dernier ne fait qu'appliquer des modifications dans le registre.
Quand tu as modifié la BDR, c'était sous quel compte ? Le tien ou celui de l'utilisateur ?
Car si tu l'as fait sous ton compte, c'est donc la
branche HKCU de TA ruche
(NTUSER.DAT) qui a été modifiée, et non pas les autres,
à la différence de
ce que fait POLEDIT ou GPEDIT.
Pour qu'elles puissent s'appliquer à tous les comptes,
les modifs faites par
ces applis sont stockées dans des fichiers NTCONFIG.POL
(NT4) ou
REGISTRY.POL (W2K et au-dela) qui sont lus et traités au
démarrage.
Merci JC, en fait, c'est un peu particulier, j'utilise
l'application Zenworks de Novell, qui permet de
distribuer des stratégies sans passer par POLEDIT. Je
n'ai pas la confirmation sur la manière dont ça
fonctionne, mais je pense (à 99,99%) qu'il se contente
d'effectuer les modifications du registre sans passer par
des vraies notions de stratégies, au sens Microsoft du
terme.
Je te confirme que ma modification est bien faite sur le
compte utilisateur et non sous mon compte, car je l'ai
vérifiée à partir de regedt32 dans lequel j'ai chargé le
NTUSER.DAT de mon utilisateur, et consulté la clé
concernée, dans sa branche HKCU.
Elle contient bien mon DWORD "DisableRegistryTools" dont
la valeur est 1.
A savoir que j'ai déjà fait cette opération dans le passé
et ça fonctionnait parfaitement.
Cependant, je ne pense pas que Zenworks soit la source du
problème, puisque ce dernier ne fait qu'appliquer des
modifications dans le registre.
Quand tu as modifié la BDR, c'était sous quel compte ?
Le tien ou celui de l'utilisateur ?
Car si tu l'as fait sous ton compte, c'est donc la
branche HKCU de TA ruche
(NTUSER.DAT) qui a été modifiée, et non pas les autres,
à la différence de
ce que fait POLEDIT ou GPEDIT.
Pour qu'elles puissent s'appliquer à tous les comptes,
les modifs faites par
ces applis sont stockées dans des fichiers NTCONFIG.POL
(NT4) ou
REGISTRY.POL (W2K et au-dela) qui sont lus et traités au
Merci JC, en fait, c'est un peu particulier, j'utilise l'application Zenworks de Novell, qui permet de distribuer des stratégies sans passer par POLEDIT. Je n'ai pas la confirmation sur la manière dont ça fonctionne, mais je pense (à 99,99%) qu'il se contente d'effectuer les modifications du registre sans passer par des vraies notions de stratégies, au sens Microsoft du terme.
Je te confirme que ma modification est bien faite sur le compte utilisateur et non sous mon compte, car je l'ai vérifiée à partir de regedt32 dans lequel j'ai chargé le NTUSER.DAT de mon utilisateur, et consulté la clé concernée, dans sa branche HKCU.
Elle contient bien mon DWORD "DisableRegistryTools" dont la valeur est 1.
A savoir que j'ai déjà fait cette opération dans le passé et ça fonctionnait parfaitement.
Cependant, je ne pense pas que Zenworks soit la source du problème, puisque ce dernier ne fait qu'appliquer des modifications dans le registre.
Quand tu as modifié la BDR, c'était sous quel compte ? Le tien ou celui de l'utilisateur ?
Car si tu l'as fait sous ton compte, c'est donc la
branche HKCU de TA ruche
(NTUSER.DAT) qui a été modifiée, et non pas les autres,
à la différence de
ce que fait POLEDIT ou GPEDIT.
Pour qu'elles puissent s'appliquer à tous les comptes,
les modifs faites par
ces applis sont stockées dans des fichiers NTCONFIG.POL
(NT4) ou
REGISTRY.POL (W2K et au-dela) qui sont lus et traités au
