SECEDIT : Rétablir les paramètres de sécurité avec la console de récupération
8 réponses
Itsejoke
Bonsoir,
J'ai un souci avec poste 2000Pro,
Un utilisateur a modifié le stratégie locale et maintenant, quelque soit le
compte utilisé,
au logon, il a un message : "la stratégie locale ne vous permet pas d'ouvrir
une session interactive"
Même en administrateur local ou en utilisant l'admin du domaine, puisqu'il
est inscrit à un domaine :-(
J'ai bin trouvé l'utilitaire SECEDIT mais, sauf erreur, on ne peut pas
l'utiliser en console de récupération !
Donc, existe-t-il en fait un moyen de remettre des paramètres de sécurité
quand on ne peut plus rentrer sous windows, à part la ré-install :-) ?
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
Fred
"Itsejoke" a écrit dans le message de news: %23mtCK$
Bonsoir,
J'ai un souci avec poste 2000Pro, Un utilisateur a modifié le stratégie locale et maintenant, quelque soit le compte utilisé, au logon, il a un message : "la stratégie locale ne vous permet pas d'ouvrir une session interactive" Même en administrateur local ou en utilisant l'admin du domaine, puisqu'il est inscrit à un domaine :-(
J'ai bin trouvé l'utilitaire SECEDIT mais, sauf erreur, on ne peut pas l'utiliser en console de récupération !
Donc, existe-t-il en fait un moyen de remettre des paramètres de sécurité quand on ne peut plus rentrer sous windows, à part la ré-install :-) ?
Merci de votre aide.
Itsejoke
Bonsoir, Si le poste est dans un domaine, alors le fait de définir cette même stratégie au niveau du domaine devrait supplanter celle définie en local.
"Itsejoke" <itsejoke@wha.com> a écrit dans le message de news:
%23mtCK$MKFHA.1280@TK2MSFTNGP09.phx.gbl...
Bonsoir,
J'ai un souci avec poste 2000Pro,
Un utilisateur a modifié le stratégie locale et maintenant, quelque soit
le
compte utilisé,
au logon, il a un message : "la stratégie locale ne vous permet pas
d'ouvrir
une session interactive"
Même en administrateur local ou en utilisant l'admin du domaine, puisqu'il
est inscrit à un domaine :-(
J'ai bin trouvé l'utilitaire SECEDIT mais, sauf erreur, on ne peut pas
l'utiliser en console de récupération !
Donc, existe-t-il en fait un moyen de remettre des paramètres de sécurité
quand on ne peut plus rentrer sous windows, à part la ré-install :-) ?
Merci de votre aide.
Itsejoke
Bonsoir,
Si le poste est dans un domaine, alors le fait de définir cette même
stratégie au niveau du domaine devrait supplanter celle définie en local.
"Itsejoke" a écrit dans le message de news: %23mtCK$
Bonsoir,
J'ai un souci avec poste 2000Pro, Un utilisateur a modifié le stratégie locale et maintenant, quelque soit le compte utilisé, au logon, il a un message : "la stratégie locale ne vous permet pas d'ouvrir une session interactive" Même en administrateur local ou en utilisant l'admin du domaine, puisqu'il est inscrit à un domaine :-(
J'ai bin trouvé l'utilitaire SECEDIT mais, sauf erreur, on ne peut pas l'utiliser en console de récupération !
Donc, existe-t-il en fait un moyen de remettre des paramètres de sécurité quand on ne peut plus rentrer sous windows, à part la ré-install :-) ?
Merci de votre aide.
Itsejoke
Bonsoir, Si le poste est dans un domaine, alors le fait de définir cette même stratégie au niveau du domaine devrait supplanter celle définie en local.
Itsejoke
"Fred" a écrit dans le message de news:
"Itsejoke" a écrit dans le message de news: %23mtCK$
Bonsoir,
J'ai un souci avec poste 2000Pro, Un utilisateur a modifié le stratégie locale et maintenant, quelque soit le compte utilisé, au logon, il a un message : "la stratégie locale ne vous permet pas d'ouvrir une session interactive" Même en administrateur local ou en utilisant l'admin du domaine, puisqu'il
est inscrit à un domaine :-(
J'ai bin trouvé l'utilitaire SECEDIT mais, sauf erreur, on ne peut pas l'utiliser en console de récupération !
Donc, existe-t-il en fait un moyen de remettre des paramètres de sécurité
quand on ne peut plus rentrer sous windows, à part la ré-install :-) ?
Merci de votre aide.
Itsejoke
Bonsoir, Si le poste est dans un domaine, alors le fait de définir cette même stratégie au niveau du domaine devrait supplanter celle définie en local.
Bonsoir Fred, merci de ta réponse, Oui je suis d'accord avec toi : les droits domaine supplantent des droits locaux. Mais en fait, j'ai le même message quand je me logge aussi bien un et même l' En fait que l'utilisateur a bidouillé ses statégies locales en étant ouvert une session avec un user local qui porte le même nom que son user domaine.
A+ Itsejoke.
"Fred" <nospam@nospam.net> a écrit dans le message de
news:eSNXZENKFHA.3960@TK2MSFTNGP09.phx.gbl...
"Itsejoke" <itsejoke@wha.com> a écrit dans le message de news:
%23mtCK$MKFHA.1280@TK2MSFTNGP09.phx.gbl...
Bonsoir,
J'ai un souci avec poste 2000Pro,
Un utilisateur a modifié le stratégie locale et maintenant, quelque soit
le
compte utilisé,
au logon, il a un message : "la stratégie locale ne vous permet pas
d'ouvrir
une session interactive"
Même en administrateur local ou en utilisant l'admin du domaine,
puisqu'il
est inscrit à un domaine :-(
J'ai bin trouvé l'utilitaire SECEDIT mais, sauf erreur, on ne peut pas
l'utiliser en console de récupération !
Donc, existe-t-il en fait un moyen de remettre des paramètres de
sécurité
quand on ne peut plus rentrer sous windows, à part la ré-install :-) ?
Merci de votre aide.
Itsejoke
Bonsoir,
Si le poste est dans un domaine, alors le fait de définir cette même
stratégie au niveau du domaine devrait supplanter celle définie en local.
Bonsoir Fred, merci de ta réponse,
Oui je suis d'accord avec toi : les droits domaine supplantent des droits
locaux.
Mais en fait, j'ai le même message quand je me logge aussi bien un
user@domaine.fr et même l'administrateur@domaine.fr
En fait que l'utilisateur a bidouillé ses statégies locales en étant ouvert
une session avec un user local qui porte le même nom que son user domaine.
"Itsejoke" a écrit dans le message de news: %23mtCK$
Bonsoir,
J'ai un souci avec poste 2000Pro, Un utilisateur a modifié le stratégie locale et maintenant, quelque soit le compte utilisé, au logon, il a un message : "la stratégie locale ne vous permet pas d'ouvrir une session interactive" Même en administrateur local ou en utilisant l'admin du domaine, puisqu'il
est inscrit à un domaine :-(
J'ai bin trouvé l'utilitaire SECEDIT mais, sauf erreur, on ne peut pas l'utiliser en console de récupération !
Donc, existe-t-il en fait un moyen de remettre des paramètres de sécurité
quand on ne peut plus rentrer sous windows, à part la ré-install :-) ?
Merci de votre aide.
Itsejoke
Bonsoir, Si le poste est dans un domaine, alors le fait de définir cette même stratégie au niveau du domaine devrait supplanter celle définie en local.
Bonsoir Fred, merci de ta réponse, Oui je suis d'accord avec toi : les droits domaine supplantent des droits locaux. Mais en fait, j'ai le même message quand je me logge aussi bien un et même l' En fait que l'utilisateur a bidouillé ses statégies locales en étant ouvert une session avec un user local qui porte le même nom que son user domaine.
A+ Itsejoke.
Fred
"Itsejoke" a écrit dans le message de news:
"Fred" a écrit dans le message de news:
"Itsejoke" a écrit dans le message de news: %23mtCK$
Bonsoir,
J'ai un souci avec poste 2000Pro, Un utilisateur a modifié le stratégie locale et maintenant, quelque soit
le compte utilisé, au logon, il a un message : "la stratégie locale ne vous permet pas d'ouvrir une session interactive" Même en administrateur local ou en utilisant l'admin du domaine, puisqu'il
est inscrit à un domaine :-(
J'ai bin trouvé l'utilitaire SECEDIT mais, sauf erreur, on ne peut pas l'utiliser en console de récupération !
Donc, existe-t-il en fait un moyen de remettre des paramètres de sécurité
quand on ne peut plus rentrer sous windows, à part la ré-install :-) ?
Merci de votre aide.
Itsejoke
Bonsoir, Si le poste est dans un domaine, alors le fait de définir cette même stratégie au niveau du domaine devrait supplanter celle définie en local.
Bonsoir Fred, merci de ta réponse, Oui je suis d'accord avec toi : les droits domaine supplantent des droits locaux. Mais en fait, j'ai le même message quand je me logge aussi bien un et même l' En fait que l'utilisateur a bidouillé ses statégies locales en étant ouvert
une session avec un user local qui porte le même nom que son user domaine.
A+ Itsejoke.
Bonjour, J'ai vérifié ce matin, les stratégies "Ouvrir une session localement" et "Refuser l'ouverture de session" ne sont pas à priori définies par défaut au niveau du domaine. Es-tu sûr de les avoir définies au niveau de l'OU de ce poste pour écraser les stratégies locales ? Si oui, alors je sèche.
"Itsejoke" <itsejoke@wha.com> a écrit dans le message de
news:uRCSmmNKFHA.1308@TK2MSFTNGP15.phx.gbl...
"Fred" <nospam@nospam.net> a écrit dans le message de
news:eSNXZENKFHA.3960@TK2MSFTNGP09.phx.gbl...
"Itsejoke" <itsejoke@wha.com> a écrit dans le message de news:
%23mtCK$MKFHA.1280@TK2MSFTNGP09.phx.gbl...
Bonsoir,
J'ai un souci avec poste 2000Pro,
Un utilisateur a modifié le stratégie locale et maintenant, quelque
soit
le
compte utilisé,
au logon, il a un message : "la stratégie locale ne vous permet pas
d'ouvrir
une session interactive"
Même en administrateur local ou en utilisant l'admin du domaine,
puisqu'il
est inscrit à un domaine :-(
J'ai bin trouvé l'utilitaire SECEDIT mais, sauf erreur, on ne peut pas
l'utiliser en console de récupération !
Donc, existe-t-il en fait un moyen de remettre des paramètres de
sécurité
quand on ne peut plus rentrer sous windows, à part la ré-install :-) ?
Merci de votre aide.
Itsejoke
Bonsoir,
Si le poste est dans un domaine, alors le fait de définir cette même
stratégie au niveau du domaine devrait supplanter celle définie en
local.
Bonsoir Fred, merci de ta réponse,
Oui je suis d'accord avec toi : les droits domaine supplantent des droits
locaux.
Mais en fait, j'ai le même message quand je me logge aussi bien un
user@domaine.fr et même l'administrateur@domaine.fr
En fait que l'utilisateur a bidouillé ses statégies locales en étant
ouvert
une session avec un user local qui porte le même nom que son user domaine.
A+
Itsejoke.
Bonjour,
J'ai vérifié ce matin, les stratégies "Ouvrir une session localement" et
"Refuser l'ouverture de session" ne sont pas à priori définies par défaut au
niveau du domaine. Es-tu sûr de les avoir définies au niveau de l'OU de ce
poste pour écraser les stratégies locales ? Si oui, alors je sèche.
"Itsejoke" a écrit dans le message de news: %23mtCK$
Bonsoir,
J'ai un souci avec poste 2000Pro, Un utilisateur a modifié le stratégie locale et maintenant, quelque soit
le compte utilisé, au logon, il a un message : "la stratégie locale ne vous permet pas d'ouvrir une session interactive" Même en administrateur local ou en utilisant l'admin du domaine, puisqu'il
est inscrit à un domaine :-(
J'ai bin trouvé l'utilitaire SECEDIT mais, sauf erreur, on ne peut pas l'utiliser en console de récupération !
Donc, existe-t-il en fait un moyen de remettre des paramètres de sécurité
quand on ne peut plus rentrer sous windows, à part la ré-install :-) ?
Merci de votre aide.
Itsejoke
Bonsoir, Si le poste est dans un domaine, alors le fait de définir cette même stratégie au niveau du domaine devrait supplanter celle définie en local.
Bonsoir Fred, merci de ta réponse, Oui je suis d'accord avec toi : les droits domaine supplantent des droits locaux. Mais en fait, j'ai le même message quand je me logge aussi bien un et même l' En fait que l'utilisateur a bidouillé ses statégies locales en étant ouvert
une session avec un user local qui porte le même nom que son user domaine.
A+ Itsejoke.
Bonjour, J'ai vérifié ce matin, les stratégies "Ouvrir une session localement" et "Refuser l'ouverture de session" ne sont pas à priori définies par défaut au niveau du domaine. Es-tu sûr de les avoir définies au niveau de l'OU de ce poste pour écraser les stratégies locales ? Si oui, alors je sèche.
Jonathan Bismuth
Bonjour,
Comme tu l'as dit, ouvrir ou refuser une session ne sont effectivement pas définies au niveau du domaine. il conviendrait de la définir au niveau OU du poste (voir de forcer son application au cas où) mais aussi d'attendre que la gpo soit prise en compte.
pour forcer la chose, pourquoi ne pas depuis une machine distante lancer un SECEDIT /REFRESHPOLICY MACHINE_POLICY /ENFORCE par un psexec où un script? Je ne penses pas que ceci soit vu comme ouverture de session locale et devrait bien écraser la stratégie qui pose problème
Cordialement, -- Jonathan BISMUTH MCSE (W2K) 2272252 Beta ID 570978 WSH/Batch Scripter http://www.supinfo-projects.com/fr/authors/?a=Cyber_Hunter pour me contacter http://cerbermail.com/?z5pCI2OyS6
"Fred" a écrit dans le message de news: #
Bonjour, J'ai vérifié ce matin, les stratégies "Ouvrir une session localement" et "Refuser l'ouverture de session" ne sont pas à priori définies par défaut au
niveau du domaine. Es-tu sûr de les avoir définies au niveau de l'OU de ce poste pour écraser les stratégies locales ? Si oui, alors je sèche.
Bonjour,
Comme tu l'as dit, ouvrir ou refuser une session ne sont effectivement pas
définies au niveau du domaine.
il conviendrait de la définir au niveau OU du poste (voir de forcer son
application au cas où) mais aussi d'attendre que la gpo soit prise en
compte.
pour forcer la chose, pourquoi ne pas depuis une machine distante lancer un
SECEDIT /REFRESHPOLICY MACHINE_POLICY /ENFORCE
par un psexec où un script? Je ne penses pas que ceci soit vu comme
ouverture de session locale et devrait bien écraser la stratégie qui pose
problème
Cordialement,
--
Jonathan BISMUTH
MCSE (W2K) 2272252
Beta ID 570978
WSH/Batch Scripter
http://www.supinfo-projects.com/fr/authors/?a=Cyber_Hunter
pour me contacter http://cerbermail.com/?z5pCI2OyS6
"Fred" <nospam@nospam.org> a écrit dans le message de news:
#GHLKdSKFHA.2736@TK2MSFTNGP09.phx.gbl...
Bonjour,
J'ai vérifié ce matin, les stratégies "Ouvrir une session localement" et
"Refuser l'ouverture de session" ne sont pas à priori définies par défaut
au
niveau du domaine. Es-tu sûr de les avoir définies au niveau de l'OU de ce
poste pour écraser les stratégies locales ? Si oui, alors je sèche.
Comme tu l'as dit, ouvrir ou refuser une session ne sont effectivement pas définies au niveau du domaine. il conviendrait de la définir au niveau OU du poste (voir de forcer son application au cas où) mais aussi d'attendre que la gpo soit prise en compte.
pour forcer la chose, pourquoi ne pas depuis une machine distante lancer un SECEDIT /REFRESHPOLICY MACHINE_POLICY /ENFORCE par un psexec où un script? Je ne penses pas que ceci soit vu comme ouverture de session locale et devrait bien écraser la stratégie qui pose problème
Cordialement, -- Jonathan BISMUTH MCSE (W2K) 2272252 Beta ID 570978 WSH/Batch Scripter http://www.supinfo-projects.com/fr/authors/?a=Cyber_Hunter pour me contacter http://cerbermail.com/?z5pCI2OyS6
"Fred" a écrit dans le message de news: #
Bonjour, J'ai vérifié ce matin, les stratégies "Ouvrir une session localement" et "Refuser l'ouverture de session" ne sont pas à priori définies par défaut au
niveau du domaine. Es-tu sûr de les avoir définies au niveau de l'OU de ce poste pour écraser les stratégies locales ? Si oui, alors je sèche.
Ludovik DOPIERALA
Connecte toi à distance par console MMC config stratégie de sécurité.... Modifie ce paramètre => si tu peux pas (grisée) c'est que tu récupère ça du domaine... Si non défini sur le domaine mais défini en locale alors défini pour tous les users qui se connecte ....
Ludovik DOPIERALA http://www.c2points.com
Bonjour,
Comme tu l'as dit, ouvrir ou refuser une session ne sont effectivement pas définies au niveau du domaine. il conviendrait de la définir au niveau OU du poste (voir de forcer son application au cas où) mais aussi d'attendre que la gpo soit prise en compte.
pour forcer la chose, pourquoi ne pas depuis une machine distante lancer un SECEDIT /REFRESHPOLICY MACHINE_POLICY /ENFORCE par un psexec où un script? Je ne penses pas que ceci soit vu comme ouverture de session locale et devrait bien écraser la stratégie qui pose problème
Cordialement, -- Jonathan BISMUTH MCSE (W2K) 2272252 Beta ID 570978 WSH/Batch Scripter http://www.supinfo-projects.com/fr/authors/?a=Cyber_Hunter pour me contacter http://cerbermail.com/?z5pCI2OyS6
"Fred" a écrit dans le message de news: #
Bonjour, J'ai vérifié ce matin, les stratégies "Ouvrir une session localement" et "Refuser l'ouverture de session" ne sont pas à priori définies par défaut au
niveau du domaine. Es-tu sûr de les avoir définies au niveau de l'OU de ce poste pour écraser les stratégies locales ? Si oui, alors je sèche.
Connecte toi à distance par console MMC config stratégie de sécurité....
Modifie ce paramètre => si tu peux pas (grisée) c'est que tu récupère ça du
domaine...
Si non défini sur le domaine mais défini en locale alors défini pour tous
les users qui se connecte ....
Ludovik DOPIERALA
http://www.c2points.com
Bonjour,
Comme tu l'as dit, ouvrir ou refuser une session ne sont effectivement pas
définies au niveau du domaine.
il conviendrait de la définir au niveau OU du poste (voir de forcer son
application au cas où) mais aussi d'attendre que la gpo soit prise en
compte.
pour forcer la chose, pourquoi ne pas depuis une machine distante lancer un
SECEDIT /REFRESHPOLICY MACHINE_POLICY /ENFORCE
par un psexec où un script? Je ne penses pas que ceci soit vu comme
ouverture de session locale et devrait bien écraser la stratégie qui pose
problème
Cordialement,
--
Jonathan BISMUTH
MCSE (W2K) 2272252
Beta ID 570978
WSH/Batch Scripter
http://www.supinfo-projects.com/fr/authors/?a=Cyber_Hunter
pour me contacter http://cerbermail.com/?z5pCI2OyS6
"Fred" <nospam@nospam.org> a écrit dans le message de news:
#GHLKdSKFHA.2736@TK2MSFTNGP09.phx.gbl...
Bonjour,
J'ai vérifié ce matin, les stratégies "Ouvrir une session localement" et
"Refuser l'ouverture de session" ne sont pas à priori définies par défaut
au
niveau du domaine. Es-tu sûr de les avoir définies au niveau de l'OU de ce
poste pour écraser les stratégies locales ? Si oui, alors je sèche.
Connecte toi à distance par console MMC config stratégie de sécurité.... Modifie ce paramètre => si tu peux pas (grisée) c'est que tu récupère ça du domaine... Si non défini sur le domaine mais défini en locale alors défini pour tous les users qui se connecte ....
Ludovik DOPIERALA http://www.c2points.com
Bonjour,
Comme tu l'as dit, ouvrir ou refuser une session ne sont effectivement pas définies au niveau du domaine. il conviendrait de la définir au niveau OU du poste (voir de forcer son application au cas où) mais aussi d'attendre que la gpo soit prise en compte.
pour forcer la chose, pourquoi ne pas depuis une machine distante lancer un SECEDIT /REFRESHPOLICY MACHINE_POLICY /ENFORCE par un psexec où un script? Je ne penses pas que ceci soit vu comme ouverture de session locale et devrait bien écraser la stratégie qui pose problème
Cordialement, -- Jonathan BISMUTH MCSE (W2K) 2272252 Beta ID 570978 WSH/Batch Scripter http://www.supinfo-projects.com/fr/authors/?a=Cyber_Hunter pour me contacter http://cerbermail.com/?z5pCI2OyS6
"Fred" a écrit dans le message de news: #
Bonjour, J'ai vérifié ce matin, les stratégies "Ouvrir une session localement" et "Refuser l'ouverture de session" ne sont pas à priori définies par défaut au
niveau du domaine. Es-tu sûr de les avoir définies au niveau de l'OU de ce poste pour écraser les stratégies locales ? Si oui, alors je sèche.
istejoke
"Ludovik DOPIERALA" a écrit dans le message de news:
Connecte toi à distance par console MMC config stratégie de sécurité.... Modifie ce paramètre => si tu peux pas (grisée) c'est que tu récupère ça du
domaine... Si non défini sur le domaine mais défini en locale alors défini pour tous les users qui se connecte ....
Ludovik DOPIERALA http://www.c2points.com
Bonjour,
Comme tu l'as dit, ouvrir ou refuser une session ne sont effectivement pas
définies au niveau du domaine. il conviendrait de la définir au niveau OU du poste (voir de forcer son application au cas où) mais aussi d'attendre que la gpo soit prise en compte.
pour forcer la chose, pourquoi ne pas depuis une machine distante lancer un
SECEDIT /REFRESHPOLICY MACHINE_POLICY /ENFORCE par un psexec où un script? Je ne penses pas que ceci soit vu comme ouverture de session locale et devrait bien écraser la stratégie qui pose
problème
Cordialement, -- Jonathan BISMUTH MCSE (W2K) 2272252 Beta ID 570978 WSH/Batch Scripter http://www.supinfo-projects.com/fr/authors/?a=Cyber_Hunter pour me contacter http://cerbermail.com/?z5pCI2OyS6
"Fred" a écrit dans le message de news: #
Bonjour, J'ai vérifié ce matin, les stratégies "Ouvrir une session localement" et
"Refuser l'ouverture de session" ne sont pas à priori définies par défaut
au
niveau du domaine. Es-tu sûr de les avoir définies au niveau de l'OU de ce
poste pour écraser les stratégies locales ? Si oui, alors je sèche.
Bonjour Ludovik, Jonathan et Fred, Merci de vos réponses, Comme je ne pouvais pas me connecter sur cette machine via le réseau, J'ai recherché à nouveau sur le net et j'ai trouvé une parade :
"Ludovik DOPIERALA" <LudovikDOPIERALA@discussions.microsoft.com> a écrit
dans le message de
news:7D50BDEC-3756-410B-BD24-97BF20B841C5@microsoft.com...
Connecte toi à distance par console MMC config stratégie de sécurité....
Modifie ce paramètre => si tu peux pas (grisée) c'est que tu récupère ça
du
domaine...
Si non défini sur le domaine mais défini en locale alors défini pour tous
les users qui se connecte ....
Ludovik DOPIERALA
http://www.c2points.com
Bonjour,
Comme tu l'as dit, ouvrir ou refuser une session ne sont effectivement
pas
définies au niveau du domaine.
il conviendrait de la définir au niveau OU du poste (voir de forcer son
application au cas où) mais aussi d'attendre que la gpo soit prise en
compte.
pour forcer la chose, pourquoi ne pas depuis une machine distante lancer
un
SECEDIT /REFRESHPOLICY MACHINE_POLICY /ENFORCE
par un psexec où un script? Je ne penses pas que ceci soit vu comme
ouverture de session locale et devrait bien écraser la stratégie qui
pose
problème
Cordialement,
--
Jonathan BISMUTH
MCSE (W2K) 2272252
Beta ID 570978
WSH/Batch Scripter
http://www.supinfo-projects.com/fr/authors/?a=Cyber_Hunter
pour me contacter http://cerbermail.com/?z5pCI2OyS6
"Fred" <nospam@nospam.org> a écrit dans le message de news:
#GHLKdSKFHA.2736@TK2MSFTNGP09.phx.gbl...
Bonjour,
J'ai vérifié ce matin, les stratégies "Ouvrir une session localement"
et
"Refuser l'ouverture de session" ne sont pas à priori définies par
défaut
au
niveau du domaine. Es-tu sûr de les avoir définies au niveau de l'OU
de ce
poste pour écraser les stratégies locales ? Si oui, alors je sèche.
Bonjour Ludovik, Jonathan et Fred,
Merci de vos réponses,
Comme je ne pouvais pas me connecter sur cette machine via le réseau,
J'ai recherché à nouveau sur le net et j'ai trouvé une parade :
"Ludovik DOPIERALA" a écrit dans le message de news:
Connecte toi à distance par console MMC config stratégie de sécurité.... Modifie ce paramètre => si tu peux pas (grisée) c'est que tu récupère ça du
domaine... Si non défini sur le domaine mais défini en locale alors défini pour tous les users qui se connecte ....
Ludovik DOPIERALA http://www.c2points.com
Bonjour,
Comme tu l'as dit, ouvrir ou refuser une session ne sont effectivement pas
définies au niveau du domaine. il conviendrait de la définir au niveau OU du poste (voir de forcer son application au cas où) mais aussi d'attendre que la gpo soit prise en compte.
pour forcer la chose, pourquoi ne pas depuis une machine distante lancer un
SECEDIT /REFRESHPOLICY MACHINE_POLICY /ENFORCE par un psexec où un script? Je ne penses pas que ceci soit vu comme ouverture de session locale et devrait bien écraser la stratégie qui pose
problème
Cordialement, -- Jonathan BISMUTH MCSE (W2K) 2272252 Beta ID 570978 WSH/Batch Scripter http://www.supinfo-projects.com/fr/authors/?a=Cyber_Hunter pour me contacter http://cerbermail.com/?z5pCI2OyS6
"Fred" a écrit dans le message de news: #
Bonjour, J'ai vérifié ce matin, les stratégies "Ouvrir une session localement" et
"Refuser l'ouverture de session" ne sont pas à priori définies par défaut
au
niveau du domaine. Es-tu sûr de les avoir définies au niveau de l'OU de ce
poste pour écraser les stratégies locales ? Si oui, alors je sèche.
Bonjour Ludovik, Jonathan et Fred, Merci de vos réponses, Comme je ne pouvais pas me connecter sur cette machine via le réseau, J'ai recherché à nouveau sur le net et j'ai trouvé une parade :
arf, tout de suite, si tu utilise la manière lourde :)
-- Jonathan BISMUTH MCSE (W2K) 2272252 Beta ID 570978 WSH/Batch Scripter http://www.supinfo-projects.com/fr/authors/?a=Cyber_Hunter pour me contacter http://cerbermail.com/?z5pCI2OyS6
"istejoke" a écrit dans le message de news: %
Bonjour Ludovik, Jonathan et Fred, Merci de vos réponses, Comme je ne pouvais pas me connecter sur cette machine via le réseau, J'ai recherché à nouveau sur le net et j'ai trouvé une parade :
arf, tout de suite, si tu utilise la manière lourde :)
--
Jonathan BISMUTH
MCSE (W2K) 2272252
Beta ID 570978
WSH/Batch Scripter
http://www.supinfo-projects.com/fr/authors/?a=Cyber_Hunter
pour me contacter http://cerbermail.com/?z5pCI2OyS6
"istejoke" <itsejoke@wha.com> a écrit dans le message de news:
%23f7u2tXKFHA.3864@TK2MSFTNGP10.phx.gbl...
Bonjour Ludovik, Jonathan et Fred,
Merci de vos réponses,
Comme je ne pouvais pas me connecter sur cette machine via le réseau,
J'ai recherché à nouveau sur le net et j'ai trouvé une parade :
arf, tout de suite, si tu utilise la manière lourde :)
-- Jonathan BISMUTH MCSE (W2K) 2272252 Beta ID 570978 WSH/Batch Scripter http://www.supinfo-projects.com/fr/authors/?a=Cyber_Hunter pour me contacter http://cerbermail.com/?z5pCI2OyS6
"istejoke" a écrit dans le message de news: %
Bonjour Ludovik, Jonathan et Fred, Merci de vos réponses, Comme je ne pouvais pas me connecter sur cette machine via le réseau, J'ai recherché à nouveau sur le net et j'ai trouvé une parade :
"Jonathan BISMUTH" a écrit dans le message de news:
arf, tout de suite, si tu utilise la manière lourde :)
-- Jonathan BISMUTH MCSE (W2K) 2272252 Beta ID 570978 WSH/Batch Scripter http://www.supinfo-projects.com/fr/authors/?a=Cyber_Hunter pour me contacter http://cerbermail.com/?z5pCI2OyS6
"istejoke" a écrit dans le message de news: %
Bonjour Ludovik, Jonathan et Fred, Merci de vos réponses, Comme je ne pouvais pas me connecter sur cette machine via le réseau, J'ai recherché à nouveau sur le net et j'ai trouvé une parade :
"Jonathan BISMUTH" <john@NOSPAM.free.fr> a écrit dans le message de
news:e27XQaYKFHA.2748@TK2MSFTNGP09.phx.gbl...
arf, tout de suite, si tu utilise la manière lourde :)
--
Jonathan BISMUTH
MCSE (W2K) 2272252
Beta ID 570978
WSH/Batch Scripter
http://www.supinfo-projects.com/fr/authors/?a=Cyber_Hunter
pour me contacter http://cerbermail.com/?z5pCI2OyS6
"istejoke" <itsejoke@wha.com> a écrit dans le message de news:
%23f7u2tXKFHA.3864@TK2MSFTNGP10.phx.gbl...
Bonjour Ludovik, Jonathan et Fred,
Merci de vos réponses,
Comme je ne pouvais pas me connecter sur cette machine via le réseau,
J'ai recherché à nouveau sur le net et j'ai trouvé une parade :
"Jonathan BISMUTH" a écrit dans le message de news:
arf, tout de suite, si tu utilise la manière lourde :)
-- Jonathan BISMUTH MCSE (W2K) 2272252 Beta ID 570978 WSH/Batch Scripter http://www.supinfo-projects.com/fr/authors/?a=Cyber_Hunter pour me contacter http://cerbermail.com/?z5pCI2OyS6
"istejoke" a écrit dans le message de news: %
Bonjour Ludovik, Jonathan et Fred, Merci de vos réponses, Comme je ne pouvais pas me connecter sur cette machine via le réseau, J'ai recherché à nouveau sur le net et j'ai trouvé une parade :
