Question Start-Process : -Credential et -Wait

Hello,

Pouvez-vous regarder ce post sur Microsoft Connect ?

Pour moi, Michal Gajda avait raison et pourtant le dossier est fermé car \"non reproductible\" :

connect.microsoft.com/PowerShell/feedbac...th-other-credential#

C'est effectivement reproductible si le compte utilisé pour lancer la commande Start-Process n'a pas les privilèges suffisants... De mon avis, le -Wait doit utiliser le compte courrant et non pas celui précisé via le paramétre -Credential.

A moins que je n'ai loupé un wagon.

@ +

Matthew<br><br>Message édité par: Matthew BETTON, à: 10/05/12 22:16

Je vais regarder ça au boulot demain, là j'ai pas de domaine, aucun mot de passe spécifié donc c'est compliqué.

Mais sur le principe je suis assez d'accord avec toi su le fait que le -wait ne doit pas utiliser le $cred, mais bien les pouvoirs du compte qui à lancer la console powershell.

Quand je disais \&quot;dois utiliser\&quot; je voulais dire que cela doit être à cause de ça que cela ne fonctionne pas. Pour pouvoir utiliser un WaitForExit() il me semble qu'il faille disposer de droits suffisant.

Ca doit donc être à cause de ça qu'on ne peut pas utiliser le -Wait en même temps que le -Credential, si on précise un compte qui dispose de plus de droits.

C'est du coup bien dommage

Pour le reproduire :

-Poste de travail en XP SP3 ;
-Session ouverte avec un compte sans privilège, qui n'est donc pas Admin local du poste ;
-Ouverture de la console PoSh (avec ce compte) ;
-Exécution de la commande avec les 2 paramètres et pour le Credential, spécifier un compte Admin.<br><br>Message édité par: Matthew BETTON, à: 9/05/12 21:03

J'ai jamais eu besoin d'éxécuter un script/soft avec des credentials différents car je m'arrange toujours pour éviter ce genre de problématique lors de mes industrialisations.

Mais je suis d'accord avec toi sur le principe, je trouve par contre que c'est tordu comme façon de faire.

C'est surement pour une question de sécurité, mais si le mec qui exécute le script connait les identifiants, pourquoi pas se logger avec ces mêmes identifiants ?

Enfin c'est peut être moi qui ne suis pas assez tordu

Bonsoir,

benduru écrit:

C'est surement pour une question de sécurité, mais si le mec qui exécute le script connait les identifiants, pourquoi pas se logger avec ces mêmes identifiants ?

Important : parce qu'on n'ouvre pas de session sur un simple poste de travail avec un compte administrateur du domaine. Même chose avec un compte ayant des droits \&quot;évolués\&quot;.

Dans les Scripting Games, il est très souvent demandé d'implémenter ces fonctionnalités :

- Contrôler que le script est exécuté avec des droits d'Admin

[code:1]If (-not ([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] \&quot;Administrator\&quot;«»)){
Write-Warning \&quot;This script requires Admin Rights. Please run this script with an account that has sufficient rights.\&quot;
exit
}[/code:1]

- Récupérer les Credentials du compte courant et rendre possible la saisie d'un Credential différent.

[code:1][CmdletBinding()]
param(
[Parameter(Position=0,Mandatory=$False,ValueFromPipeline=$True,ValueFromPipelineByPropertyName=$True)]
[Alias(\&quot;cn\&quot;,\&quot;Computer\&quot;«»)]
[String[]]$ComputerName = \&quot;.\&quot;,
[Parameter(Mandatory=$False)]
[System.Management.Automation.PSCredential]$Credential = [System.Management.Automation.PSCredential]::Empty
)[/code:1]


Parce que le script pourra par la suite être partagé et que quelque soit le contexte :

-Exécution dans une console \&quot;exécutée en tant que\&quot;
-Exécution depuis un serveur avec le compte admin courant
-Exécution dans une console ouverte avec des droits d'utilisateur standard mais en précisant un Credential différent via le paramètre Credential
-Exécution dans une tâche planifiée, avec un compte de service

...il pourra être utilisé et il fonctionnera.

Dans tous les cas, de nombreuses Cmdlets acceptent le paramètre Credential, pour du remoting, ou pas, et ça c'est bien

@+
Matthew<br><br>Message édité par: Matthew BETTON, à: 10/05/12 21:21