Exécuter script en admin avec compte standard

Version imprimable

15/12/2014, 09h47
nesswaw

Exécuter script en admin avec compte standard

Bonjour,

Je dois faire un script, qui va vérifier l'état d'un service avant de lancer un programme, si le service est planté alors il le redémarrer et lance le programme.

Tout fonctionne bien, sauf qu'il faut être admin pour redémarrer le service, et ce script devra être utilisé avec des compte non-admin, y-a-t-il un moyen que le script fonctionne quand on est pas admin?

Merci d'avance
17/12/2014, 14h08
nesswaw

Up?
18/12/2014, 18h32
Laurent Dardenne

Citation:

Envoyé par nesswaw

y-a-t-il un moyen que le script fonctionne quand on est pas admin?

L'exécution du script oui, mais pas l'opération.
Au cas où consulte ce post.
Il existe aussi la délégation, par exemple avec un workflow. Mais cela dépend de ton environnement, de tes contraintes,...
20/01/2015, 15h46
nesswaw

Bonjour,

Merci pour votre réponse.

Donc pas moyen qu'un user non-admin exécute un script en admin? Même avec une config spécial (un programme ou autre?)

Merci
26/01/2015, 12h15
pitchalov

Bonjour,

Vous pouvez utiliser l'utilitaire psexec de sysinternals, qui vous permet de lancer fournir un login / password pour lancer une commande sous un autre compte (à la manière d'un runas).
Par contre, un login / mot de passe sera visible dans le code du script lancé par des utilisateurs non-administrateur (possibilité d'utiliser AutoIt pour compiler le script et ne plus avoir le mot de passe visible, mais pas infaillible non-plus...)

Bonne continuation
26/01/2015, 13h02
fiftytwo

Citation:

Envoyé par pitchalov

Bonjour,

Vous pouvez utiliser l'utilitaire psexec de sysinternals, qui vous permet de lancer fournir un login / password pour lancer une commande sous un autre compte (à la manière d'un runas).
Par contre, un login / mot de passe sera visible dans le code du script lancé par des utilisateurs non-administrateur (possibilité d'utiliser AutoIt pour compiler le script et ne plus avoir le mot de passe visible, mais pas infaillible non-plus...)

Bonne continuation

et dans une DLL ? ca peux passer ?
26/01/2015, 17h28
pitchalov

Bonjour,

Je ne sais pas répondre à cette question, ça dépasse mes connaissances, je vais donc laisser les autres membres se positionner sur ce sujet.
Sinon, j'ai envie de dire pourquoi pas, il suffit de tester non?

Du coup n'hésite pas à nous faire part de tes tests et des résultats.
27/01/2015, 10h38
nesswaw

Bonjour,

Merci pour vos réponses.

@pitchalov: Si on peux découvrir le mot de passe, alors non ce n'est pas une bonne solution pour nous.

@pitchalov: Dans un DLL? Pouvez-vous détaillé le principe de fonctionnement?

Merci d'avance

Citation:

Envoyé par nesswaw

@pitchalov: Dans un DLL? Pouvez-vous détaillé le principe de fonctionnement?

Je me permets de répondre, peu importe le conteneur, le pb reste l'association du compte et le mot de passe dans un fichier.

Un exemple de délégation qui n'est pas sécurisé :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 # With PowerShell V3, you can specify credentials for a session configuration #TEST dans une session USER $s = New-PSSession -ConfigurationName microsoft.powershell32 Invoke-Command $s { Start-Service MySvc } Remove-PSSession $s #CONFIGURATION PAR UN ADMIN # Go to the plugin configuration and see the new properties Push-Location WSMan:\localhost\plugin\microsoft.powershell32 Get-ChildItem # Delegate a set of credentials (Admin) $cred = Get-Credential Set-Item .\RunAsUser $cred Restart-Service WinRM #Change Remoting User Access Set-PSSessionConfiguration -Name Microsoft.PowerShell32 -showSecurityDescriptorUI #Add user account read+Execute (invoke) #EXECUTION PAR UN USER # Now see which user the session is using $s = New-PSSession -ConfigurationName microsoft.powershell32 # Start-Service MySvc #-> access denied Invoke-Command $s { Start-Service MySvc } #-> OK #CONFIGURATION PAR UN ADMIN # cleanup Clear-Item .\RunAsUser; Restart-Service WinRM; Pop-Location; Remove-PSSession $s
Ensuite il faut contraindre le runspace où s'exécute la commande 'Start-Service MySvc'.
Sinon un compte utilisateur a full access via la configuration de session modifiée. La création d'une config dédié est peut être préférable, mais je n'ai pas trop le temps en ce moment de creuser ou de rédiger un tuto sur le sujet. A voir.

Il faut Powershell v3 et ceci modifie tout de même la config du poste.

Testé en local avec PS v4 sous Seven.

27/01/2015, 15h05
Mister Nono

Lancer le script via la stratégie du compte sur le domaine, le fichier script ayant les droits administrateur du domaine.

Du coup, l'exécution sur un client donnera des droits supérieurs qu'un simple script utilisateur ? A moins que je me trompe...

A suivre... :mouarf:

A+ ;)
28/01/2015, 13h58
pitchalov

Bonjour,

Comme le dit Laurent Dardenne, si un code comprend des login/password en dur, peu importe le conteneur (exe, dll ou autre), et que la compilation est réversible alors le risque est présent.
La solution de Mister Nono ne me semble pas résoudre le problème, du fait qu'une GPO de type User va lancer un script de connexion avec les droits de l'utilisateur en question, il me semble, à vérifier.

Après les idées de Laurent Dardenne et de Mister Nono me conduisent à une autre proposition (c'est du bricolage mais bon si ça répond à ton besoin ça pourrait le faire) :
Tu crée un script qui se lance au démarrage en tant qu'administrateur (par GPO, service, tâche planifiée ou ce que tu veux), et qui va lire en boucle infinie (toutes les 30 sec par exemple) un fichier flag que l'utilisateur va pouvoir modifier/créer pour donner le go au script de lancer ses opérations (et même pourquoi pas au travers d'un script afin d'automatiser les actions).
Dès lors que ton script voit le flag à "OK", il va lancer la vérification+ relance de service, et repasser le flag en mode "WAIT".

Ainsi le seul droit de l'utilisateur nécessaire, c'est de créer / modifier un fichier dans une arborescence définie.
Je sais pas si je me suis fait comprendre.

En espérant que ça convienne, ou que ça amène d'autres réflexions moins bricole.
Bonne continuation.
28/01/2015, 14h26
Mister Nono

A vérifier :

Dans PSTools de Mark Russinovich, il y a un utilitaire PSExec. Cet utilitaire semble pouvoir lancer des commandes à distance en passant en même temps le password.

A+ ;)
04/02/2015, 12h55
nesswaw

Bonjour,

Non pas GPO je peux pas, car le script se lance au début de la session, je dois pouvoir lancer le script "à la demande" de l'utilisateur

C'est quand même fou qu'on ne peut pas faire ça "assez facilement" depuis Windows...

Après investigation, je suis sur une piste en faisant une tâche planifiée, qui se lance avec un user admin, mais j'ai encore plein de soucis, Powershell doit afficher des message à l'utilisateur, mais comme il est pas lancer avec le current user, rien ne s'affiche...

Il n'existe pas des programmes qui permette de gérer ces genre de cas?

Merci
04/02/2015, 13h45
Laurent Dardenne

Citation:

Envoyé par nesswaw

Après investigation, je suis sur une piste en faisant une tâche planifiée, qui se lance avec un user admin, mais j'ai encore plein de soucis, Powershell doit afficher des message à l'utilisateur, mais comme il est pas lancer avec le current user, rien ne s'affiche...

Ici ce n'est pas seulement un pb de compte, mais de conception. De plus une tâche planifiée pose un autre problème.

Citation:

Envoyé par nesswaw

Il n'existe pas des programmes qui permette de gérer ces genre de cas ?
i

Je n'en connais pas. Au cas où, regarde si AutoHotkey peut t'aider.

En quoi la solution de délégation proposée basée sur PS ne convient pas ?
04/02/2015, 13h45
Mister Nono

Citation:

Envoyé par nesswaw

C'est quand même fou qu'on ne peut pas faire ça "assez facilement" depuis Windows...

Encore Windows. :aie:

Bon courage. ;)
04/02/2015, 15h27
nesswaw

Citation:

Envoyé par Laurent Dardenne

Ici ce n'est pas seulement un pb de compte, mais de conception. De plus une tâche planifiée pose un autre problème.

Je n'en connais pas. Au cas où, regarde si AutoHotkey peut t'aider.

En quoi la solution de délégation proposée basée sur PS ne convient pas ?

Dans votre solution, vous dites que ce n'est pas sécurisé, je ne peut donc pas l'exploiter.

Une autre piste: Créer un service Windows qui tourne en admin (généralement le compte système) et faire une commande qui va interroger ce service, suivant le status, ce service admin redémarre le service qui doit être redémarrer?

Merci
04/02/2015, 16h07
Mister Nono

Citation:

Envoyé par nesswaw

Dans votre solution, vous dites que ce n'est pas sécurisé, je ne peut donc pas l'exploiter.

Une autre piste: Créer un service Windows qui tourne en admin (généralement le compte système) et faire une commande qui va interroger ce service, suivant le status, ce service admin redémarre le service qui doit être redémarrer?

Merci

Pourquoi faire simple quand on peut faire compliqué ? :mouarf:

A+ ;)
04/02/2015, 16h13
nesswaw

Citation:

Envoyé par Mister Nono

Pourquoi faire simple quand on peut faire compliqué ? :mouarf:

A+ ;)

Avez-vous une solution simple?
04/02/2015, 16h23
Mister Nono

Citation:

Envoyé par nesswaw

Avez-vous une solution simple?

Oui : LINUX :mouarf:

A+ ;)
04/02/2015, 17h00
Laurent Dardenne

Citation:

Envoyé par nesswaw

Dans votre solution, vous dites que ce n'est pas sécurisé, je ne peut donc pas l'exploiter.

L'exemple donné oui, mais pas l'approche. Il manque à cette exemple le code qui autorise uniquement le traitement de redémarrage du service.
Il faut le coder...
05/02/2015, 10h29
nesswaw

Citation:

Envoyé par Mister Nono

Oui : LINUX :mouarf:

A+ ;)

J'ai dit que je chercherais une solution fiable :D :D :zoubi:

Plus sérieusement, non pas de Linux, notre parc est sous Windows.

@Laurent Dardenne: Le but de ton exemple est que on exécute le script avec le current user et que uniquement la commande pour redémarrer le service se fasse en admin c'est bien?

Merci

Citation:

Envoyé par nesswaw

@Laurent Dardenne: Le but de ton exemple est que on exécute le script avec le current user et que uniquement la commande pour redémarrer le service se fasse en admin c'est bien?

Oui tout à fait.
Un autre exemple rapido pour masquer une commande :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 $DeniedCommands = @( "Stop-Process", "Restart-Computer" ) $ExecutionContext.SessionState.Applications.Clear() $ExecutionContext.SessionState.Scripts.Clear() #Accès indirect au cmdlet function Reboot {Restart-Computer -WhatIf} Get-Command -CommandType Cmdlet, alias, function | Where {$DeniedCommands -contains $_.Name} | Foreach {$_.Visibility="Private"} #$ExecutionContext.SessionState.LanguageMode="NoLanguage" $ExecutionContext.SessionState.LanguageMode="RestrictedLanguage" # Stop-Process 'introuvable' gcm -Noun process #Ceci n'est pas persistant #Fermer et relancer une autre session.
L'idée est que l'utilisateur accède a sa console PS normalement avec ses droits, et il peut via une session configurée/restreinte exécuter la commande Restart-Service avec les droits admin.
Il n'accède pas à la commande mais à une fonction RestartServiceTruc qui paramètre l'appel : Restart-Service -Name ServiceTruc.
Cela permet de déléguer des activités nécessitant des droits d'admin à des utilisateurs, par exemple du support.
Ce qu'il reste à coder est la configuration de cette session (la protéger), ainsi l'utilisateur peut la manipuler, mais ne peut rien faire d'autre avec.
C'est sûr que ce type d'approche touche à l'infra et à l'organisation...

Il existe aussi le redémarrage automatique de service.

06/02/2015, 09h43
nesswaw

Je comprend pas comment "on peut cacher" une commande dans Powershell...le script doit de toute façon être stocké à un endroit et être accessible en lecture pour être exécuter, donc l'utilisateur peut le visualiser.