Droits d'accès et psExec

Le
Fred
Bonjour,

Sur un serveur de développement win2003, certains utlisateurs ont les
autorisations de se connecter en TSe pour lancer en local des scripts
vbs. Pour cela, ils sont admin de la machine.

Le problèmes est qu'ils sont de plus en plus nombreux à avoir besoin de
se connecter ainsi et du coup, les 2 accès TSE sont saturés en permanence.

Je pensais leur faire utiliser psExec mais je n'arrive pas à attribuer
les bons droits pour qu'ils puissent lancer un vbs avec psExec mais
qu'ils ne puissent plus accéder au serveur via TSE.

Quelqu'un aurait-il une piste pour régler ce problème ?

Merci,

@+

Fred
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
kurtz_le_pirate
Le #17273571
Fred wrote:
Bonjour,

Sur un serveur de développement win2003, certains utlisateurs ont les
autorisations de se connecter en TSe pour lancer en local des scripts
vbs. Pour cela, ils sont admin de la machine.

Le problèmes est qu'ils sont de plus en plus nombreux à avoir besoin
de se connecter ainsi et du coup, les 2 accès TSE sont saturés en
permanence.
Je pensais leur faire utiliser psExec mais je n'arrive pas à attribuer
les bons droits pour qu'ils puissent lancer un vbs avec psExec mais
qu'ils ne puissent plus accéder au serveur via TSE.

Quelqu'un aurait-il une piste pour régler ce problème ?

Merci,

@+

Fred



tu as du installer le serveur en mode "administration".
pour vérifier, va voir dans "paramètres du serveur" dans "configuration
des services ts".

pour basculer dans l'autre mode, tu vas dans "ajout/suppression de
prog",et tu ajoutes "gestionnaire des licences tse".



--
klp
"bug : probleme d'interface entre la chaise et le clavier"
Fred
Le #17298091
kurtz_le_pirate a écrit :
Fred wrote:



Je pensais leur faire utiliser psExec mais je n'arrive pas à attribuer
les bons droits pour qu'ils puissent lancer un vbs avec psExec mais
qu'ils ne puissent plus accéder au serveur via TSE.







tu as du installer le serveur en mode "administration".
pour vérifier, va voir dans "paramètres du serveur" dans "configuration
des services ts".

pour basculer dans l'autre mode, tu vas dans "ajout/suppression de
prog",et tu ajoutes "gestionnaire des licences tse".






En fait, le serveur sert de serveur web de dev, donc je n'ai pas besoin
de plus des 2 sessions TSE d'admin.
Par contre, il faudrait qu'un utilisateur X puisse utiliser psExec, mais
qu'il ne puisse pas se connecter au bureau à distance.

@+

Fred
TDBear
Le #17302621
Bonjour,

Si j'ai bien compris:
* Tu utilises le mode d'administration de TSE pour lancer des vbs sur un
serveur de dev.
* Tu souhaites supprimer l'utilisation TSE pour lancer les vbs.

En relisant l'article microsoft de PsExec, on voit qu'il est possible de
spécifier un utilisateur et un mot de passe lors de l'execution de la ligne
de commande. Donc la première question à ce poser est: Quelle est
l'autorisation minimum nécessaire requise par vos scripts vbs: est-ce que
l'autorisation "utilisateur avec pouvoir est suffisante" ? Si ca suffit, ta
question est règlée: En tant qu'utilisateur avec pouvoir, ils n'auront pas
accès au mode prise de controle à distance. Il suffira de leur créer un
login/password du genre toto/titi et ils n'auront qu'à lancer la ligne de
commande du genre:
psexec \Ton_serveur_de_dev -u toto -i titi -l cmd
Le -l étant pour limité (autorisation non administrateur).

cf:
http://www.microsoft.com/france/technet/sysinternals/ProcessesAndThreads/PsExec.mspx

Maintenant si ca ne suffit pas il faut faire la différence entre 2 choses:
* Avoir les droits administrateur.
* Avoir le droit d'ouvrir une session TSE.
Ce n'est pas parce qu'on est administrateur qu'on a forcément le droit
d'ouvrir une session TSE. En fait cela se configure dans les stratégies de
groupe. Dans le cas d'un serveur TSE standard il faut que les utilisateurs
(ou l'un des groupes au(x)quel(s) ils sont rattachés) aient le droit
"Autoriser l'ouverture d'une session par les services Terminal server". Pour
accèder à cette option:
A partir de ton serveur:
lancer gpedit.msc
Aller dans :
Configuration ordinateur
->Paramètres Windows
-> Paramètres de sécurié
-> Stratégies locales
-> Attribution des droits utilisateur
Par défaut les membres de administrateurs ont se droit, dans ton cas (si
c'est comme dans un mode "normal" de TSE) il te faudra supprimer le groupe
administrateurs de cette règle et rajouter ton compte administrateur (sinon
tu pourras plus non plus te connecter). Ensuite il te restera plus qu'a
vérifier que tes utilisateurs ne font pas également parti d'un autre groupe
qui est cité dans cette règle.

Tiens nous au courant.

TDBear

"Fred"
Bonjour,

Sur un serveur de développement win2003, certains utlisateurs ont les
autorisations de se connecter en TSe pour lancer en local des scripts vbs.
Pour cela, ils sont admin de la machine.

Le problèmes est qu'ils sont de plus en plus nombreux à avoir besoin de se
connecter ainsi et du coup, les 2 accès TSE sont saturés en permanence.

Je pensais leur faire utiliser psExec mais je n'arrive pas à attribuer les
bons droits pour qu'ils puissent lancer un vbs avec psExec mais qu'ils ne
puissent plus accéder au serveur via TSE.

Quelqu'un aurait-il une piste pour régler ce problème ?

Merci,

@+

Fred



Emmanuel Dreux
Le #17311111
psexec crée un service sur l'ordinateur distant.
Il faut donc être administrateur de la machine distante pour utiliser psexec
à distance.

On ne retire pas de permissions à un administrateur puisque pour éviter
qu'il se tire une balle dans le pied, un administrateur peut se réaccorder
les droits qui lui on été supprimé.
Donc, tes administrateurs déterminés pourront se réoctroyer les droits
retirés.

--
Cordialement,
Emmanuel Dreux
http://www.ilinfo.fr


"TDBear" a écrit :

Bonjour,

Si j'ai bien compris:
* Tu utilises le mode d'administration de TSE pour lancer des vbs sur un
serveur de dev.
* Tu souhaites supprimer l'utilisation TSE pour lancer les vbs.

En relisant l'article microsoft de PsExec, on voit qu'il est possible de
spécifier un utilisateur et un mot de passe lors de l'execution de la ligne
de commande. Donc la première question à ce poser est: Quelle est
l'autorisation minimum nécessaire requise par vos scripts vbs: est-ce que
l'autorisation "utilisateur avec pouvoir est suffisante" ? Si ca suffit, ta
question est règlée: En tant qu'utilisateur avec pouvoir, ils n'auront pas
accès au mode prise de controle à distance. Il suffira de leur créer un
login/password du genre toto/titi et ils n'auront qu'à lancer la ligne de
commande du genre:
psexec \Ton_serveur_de_dev -u toto -i titi -l cmd
Le -l étant pour limité (autorisation non administrateur).

cf:
http://www.microsoft.com/france/technet/sysinternals/ProcessesAndThreads/PsExec.mspx

Maintenant si ca ne suffit pas il faut faire la différence entre 2 choses:
* Avoir les droits administrateur.
* Avoir le droit d'ouvrir une session TSE.
Ce n'est pas parce qu'on est administrateur qu'on a forcément le droit
d'ouvrir une session TSE. En fait cela se configure dans les stratégies de
groupe. Dans le cas d'un serveur TSE standard il faut que les utilisateurs
(ou l'un des groupes au(x)quel(s) ils sont rattachés) aient le droit
"Autoriser l'ouverture d'une session par les services Terminal server". Pour
accèder à cette option:
A partir de ton serveur:
lancer gpedit.msc
Aller dans :
Configuration ordinateur
->Paramètres Windows
-> Paramètres de sécurié
-> Stratégies locales
-> Attribution des droits utilisateur
Par défaut les membres de administrateurs ont se droit, dans ton cas (si
c'est comme dans un mode "normal" de TSE) il te faudra supprimer le groupe
administrateurs de cette règle et rajouter ton compte administrateur (sinon
tu pourras plus non plus te connecter). Ensuite il te restera plus qu'a
vérifier que tes utilisateurs ne font pas également parti d'un autre groupe
qui est cité dans cette règle.

Tiens nous au courant.

TDBear

"Fred"
> Bonjour,
>
> Sur un serveur de développement win2003, certains utlisateurs ont les
> autorisations de se connecter en TSe pour lancer en local des scripts vbs.
> Pour cela, ils sont admin de la machine.
>
> Le problèmes est qu'ils sont de plus en plus nombreux à avoir besoin de se
> connecter ainsi et du coup, les 2 accès TSE sont saturés en permanence.
>
> Je pensais leur faire utiliser psExec mais je n'arrive pas à attribuer les
> bons droits pour qu'ils puissent lancer un vbs avec psExec mais qu'ils ne
> puissent plus accéder au serveur via TSE.
>
> Quelqu'un aurait-il une piste pour régler ce problème ?
>
> Merci,
>
> @+
>
> Fred
>





Fred
Le #17326431
Merci à vous pour vos explications.

En fait, la direction a décidé, malgré mes réserves, que les
développeurs administreraient eux-même la machine dans son ensemble et
non plus uniquement le lancement de script.

je sais, c'est bizarre, mais c'esst comme ça :-( .

@+

Fred


Emmanuel Dreux a écrit :
psexec crée un service sur l'ordinateur distant.
Il faut donc être administrateur de la machine distante pour utiliser psexec
à distance.

On ne retire pas de permissions à un administrateur puisque pour éviter
qu'il se tire une balle dans le pied, un administrateur peut se réaccorder
les droits qui lui on été supprimé.
Donc, tes administrateurs déterminés pourront se réoctroyer les droits
retirés.

--
Cordialement,
Emmanuel Dreux
http://www.ilinfo.fr


"TDBear" a écrit :

Bonjour,

Si j'ai bien compris:
* Tu utilises le mode d'administration de TSE pour lancer des vbs sur un
serveur de dev.
* Tu souhaites supprimer l'utilisation TSE pour lancer les vbs.

En relisant l'article microsoft de PsExec, on voit qu'il est possible de
spécifier un utilisateur et un mot de passe lors de l'execution de la ligne
de commande. Donc la première question à ce poser est: Quelle est
l'autorisation minimum nécessaire requise par vos scripts vbs: est-ce que
l'autorisation "utilisateur avec pouvoir est suffisante" ? Si ca suffit, ta
question est règlée: En tant qu'utilisateur avec pouvoir, ils n'auront pas
accès au mode prise de controle à distance. Il suffira de leur créer un
login/password du genre toto/titi et ils n'auront qu'à lancer la ligne de
commande du genre:
psexec \Ton_serveur_de_dev -u toto -i titi -l cmd
Le -l étant pour limité (autorisation non administrateur).

cf:
http://www.microsoft.com/france/technet/sysinternals/ProcessesAndThreads/PsExec.mspx

Maintenant si ca ne suffit pas il faut faire la différence entre 2 choses:
* Avoir les droits administrateur.
* Avoir le droit d'ouvrir une session TSE.
Ce n'est pas parce qu'on est administrateur qu'on a forcément le droit
d'ouvrir une session TSE. En fait cela se configure dans les stratégies de
groupe. Dans le cas d'un serveur TSE standard il faut que les utilisateurs
(ou l'un des groupes au(x)quel(s) ils sont rattachés) aient le droit
"Autoriser l'ouverture d'une session par les services Terminal server". Pour
accèder à cette option:
A partir de ton serveur:
lancer gpedit.msc
Aller dans :
Configuration ordinateur
->Paramètres Windows
-> Paramètres de sécurié
-> Stratégies locales
-> Attribution des droits utilisateur
Par défaut les membres de administrateurs ont se droit, dans ton cas (si
c'est comme dans un mode "normal" de TSE) il te faudra supprimer le groupe
administrateurs de cette règle et rajouter ton compte administrateur (sinon
tu pourras plus non plus te connecter). Ensuite il te restera plus qu'a
vérifier que tes utilisateurs ne font pas également parti d'un autre groupe
qui est cité dans cette règle.

Tiens nous au courant.

TDBear

"Fred"
Bonjour,

Sur un serveur de développement win2003, certains utlisateurs ont les
autorisations de se connecter en TSe pour lancer en local des scripts vbs.
Pour cela, ils sont admin de la machine.

Le problèmes est qu'ils sont de plus en plus nombreux à avoir besoin de se
connecter ainsi et du coup, les 2 accès TSE sont saturés en permanence.

Je pensais leur faire utiliser psExec mais je n'arrive pas à attribuer les
bons droits pour qu'ils puissent lancer un vbs avec psExec mais qu'ils ne
puissent plus accéder au serveur via TSE.

Quelqu'un aurait-il une piste pour régler ce problème ?

Merci,

@+

Fred









Publicité
Poster une réponse
Anonyme