L’utilisateur aura accès physiquement au serveur ?
Si c’est le cas, créé lui un compte local (hors domaine) avec les droits utilisateurs, voir invité, et dans les stratégies de sécurité local, tu donnes le droit à ces utilisateurs d’éteindre le serveur.
Sinon, je te rappelle que même à distance tu peux éteindre un serveur avec la commande shutdown, et tu peux te connecter dessus avec le TSE “d’administration”.
Par contre, le serveur sur lequel je veux que l’utilisateur se connecte et auquel il a accès physiquement, est un controleur secondaire en win2003. Je n’ai donc pas accès à la gestion des comptes utilisateurs. Je ne peux donc ni en rajouter, ni rajouter cet utilisateur au groupe de ceux qui sont autorisés à s’y connecter en tse.
Comme je te l’ai dis, si ce n’est pas un serveur TSE (licences payantes), seuls les administrateurs ont le droit de se connecter en TSE à un serveur (max. 2 simultanées).
Ouvre la console de stratégie de groupe (gpedit.msc ou gpmc.msc).
Si tu passer par une GPO du domaine, crées-en une (ou prends celle) qui soit limité au serveur en question.
Ensuite Configuration de l’ordinateur > Paramètres Windows > Paramètres de sécurité > Stratégies locales > Attribution des droits utilisateurs > Arrêter le système
Et là tu ajoutes ton utilisateur à la liste. Il est probable que cette liste soit gérée par une GPO, donc gpedit.msc pourrait ne pas fonctionner.
Ca m’énerve les réaction type " N’importe quoi!!". Tout le monde peut se tromper, donc en général, j’évite.
Tu parles de passer par GPEdit pour modifier la stratégie locale d’un DC? Elle n’est pas modifiable sur la partie sécurité pour un DC car la default domain group policy la configure.
Et même si tu la configurait; elle serait réécrasée.
Et le déplacement d’un DC dans une autre OU pour lui appliquer une GPO spécifique n’est pas supporté.
Par contre, ça me fait penser qu’en ajoutant une deuxième GPO au même nivveau que la default domain controller policy, et en appliquant un filtre WMI, ça pourrait le faire (jamais essayé mais ça doit marcher)
La nouvelle GPO doit être configurée pour accepter ton utilisateur et passer en priorité sur la default domain controller policy.
Le filtre wmi doit être mis sur le nom du serveur auquel ça s’applique.
Edité le 19/08/2009 à 22:15
J’ai déjà dit tout ça dans mon post, et oui ça marche.
Par contre la nouvelle GPO, si nouvelle GPO il y a n’a pas à inclure l’utilisateur. Cette GPO ne doit être appliquée que par le contrôleur de domaine adéquat (utiliser le GUI de gpmc pour les ACL) car nous appliquons la sécurité à une machine et non à un utilisateur.
Edité le 20/08/2009 à 00:08
Bien sûr que c’est une gpo machine, je dis juste de configurer la gpo pour accepter l’utilisateur (en allow logon locally)
Oui enfin dans ton post tu dis de faire un truc et ensuite tu dis que ça risque de ne pas fonctionner.
J’ai donc donné une solution pour que ça fonctionne (par wmi)
Edité le 20/08/2009 à 08:46
Pour info, j’ai procédé de la facon suivante et cela fonctionne :
Dans « Paramètres de sécurité du contrôleur de domaine par défaut / Stratégie locale / Attribution des droits utilisateurs je l’ai rajouté aux groupes :
Accéder à cet ordinateur à partir du réseau
Ajouter des stations de travail au domaine
Arrêter le système
Autoriser louverture de session par les services Terminal Server
