web-dev-qa-db-fra.com

Exécuter le bloc de code localement en tant qu'utilisateur différent dans le script powershell

C'est quelque chose d'incroyablement simple, mais je ne peux tout simplement rien faire fonctionner. Je veux exécuter un code de bloc dans un script PowerShell sous un utilisateur spécifique. Le mot clé est localement et j'utilise powershell 2.0.

Invoke-Command semble nécessiter un hôte distant? Je lance ce qui suit et le message d'erreur que je vois semble suggérer autant:

$strScriptUser = "DOMAIN\USER"
$strPass = "PASSWERD"
$PSS = ConvertTo-SecureString $strPass -AsPlainText -Force
$cred = new-object system.management.automation.PSCredential $strScriptUser,$PSS
Invoke-Command -ComputerName "." -scriptblock {
write-output "HI!"
} -Credential $cred

Start-Job avec -ScriptBlock n'est pas pris en charge avec powershell 2.0? Je lance ce qui suit et le message d'erreur que je vois semble suggérer autant:

$strScriptUser = "DOMAIN\USER"
$strPass = "PASSWERD"
$PSS = ConvertTo-SecureString $strPass -AsPlainText -Force
$cred = new-object system.management.automation.PSCredential $strScriptUser,$PSS
Start-Job -ScriptBlock {
write-output "HI!"
} -Credential $cred

Est-ce que je fais quelque chose de mal ou y a-t-il un autre moyen?

Ajouté: Voici ce que j'essaie de faire en premier lieu. Je crée une tâche planifiée qui s'exécute lorsqu'un utilisateur se connecte à/déverrouille un terminal qui écrit les informations de connexion dans un fichier. La tâche planifiée s'exécute en tant qu'utilisateur local afin d'obtenir les informations de nom d'utilisateur, de profil, etc. Les informations de connexion sont ensuite écrites dans un fichier journal à l'aide d'un compte d'utilisateur différent, qui est le seul compte à pouvoir modifier le fichier. Pour empêcher l'accès aux informations d'identification de connexion dans le script, je convertis le script en fichier EXE à l'aide de PS2EXE.

windowspowershell
8
wrieedx

Voici un autre moyen.

# Get the other user's credentials
$credential = Get-Credential

# Execute a scriptblock as another user
$commands = @'
    $env:username
    # ... more commands ...
'@
Start-Process -FilePath Powershell -LoadUserProfile -Credential $credential -ArgumentList '-Command', $commands

# Execute a file as another user 
$script = '.\path\name.ps1'
Start-Process -FilePath Powershell -LoadUserProfile -Credential $credential -ArgumentList '-File', $script

Avec le commutateur -LoadUserProfile, le profil de l'utilisateur, s'il n'existe pas déjà, présente l'avantage.

2
Nathan Hartley

Il serait utile de voir les messages d'erreur que vous ne nous affichez pas, mais je pense que la réponse à votre question est d'utiliser PowerShell Remoting comme vous l'avez essayé avec Invoke-Command. Le nom d'ordinateur . convient, tout comme localhost, mais vous devez activer la communication à distance sur votre ordinateur pour le faire.

Pour activer la communication à distance, exécutez Enable-PSRemoting dans powershell ou exécutez winrm quickconfig dans une invite de commande normale.

Si vous avez déjà activé la communication à distance, vous essayez peut-être de faire la communication à distance avec un utilisateur non administrateur. Si c'est le cas, jetez un coup d'œil au résultat de Get-PSSessionConfiguration. Vous obtiendrez une liste des points de terminaison et des autorisations appliquées.

Le point de terminaison auquel vous vous connectez par défaut s'appelle Microsoft.Powershell et vous pouvez modifier les autorisations avec Set-PSSessionConfiguration (veillez à utiliser le paramètre -ShowSecurityDescriptorUI à moins que vous ne vouliez jouer avec SDDL).

Mais au lieu de faire cela, il devrait déjà y avoir un accès donné au groupe appelé BUILTIN\Remote Management Users auquel vous pouvez ajouter votre utilisateur limité.

Si cela ne vous aide pas, donnez plus de détails et des messages d'erreur.

Modifier

Après avoir vu l'explication de ce que vous essayez ultimement d'accomplir, j'ai une autre suggestion à vous faire.

  1. Votre tâche planifiée existante écrit les informations dans un emplacement connu.
  2. Une tâche planifiée différente exécutée sous le compte d'utilisateur privilégié récupère ces informations et les place dans le fichier auquel l'utilisateur limité ne peut pas accéder.
  3. Bonus: démarre la deuxième tâche de la première tâche.

Cela pourrait être un compromis rapide pour faire ce que vous voulez sans accès distant et sans exposer les informations d'identification de l'utilisateur privilégié.

Problèmes liés à l'approche actuelle:

Le principal problème que j'ai avec votre idée initiale est qu'il vous faudra incorporer les informations d'identification dans le script, afin que l'utilisateur limité ait accès aux informations d'identification du compte permettant de modifier le fichier de toute façon.

Idéalement:

Vous disposez d'un service Web que vous pouvez appeler avec votre script PowerShell à utilisateur limité, dans lequel vous pouvez uniquement lui fournir les informations de connexion et ne rien obtenir en retour. Donc, vous tapez une URL et faites une POST ou quoi que ce soit avec les données que vous souhaitez consigner, mais cet utilisateur ne peut jamais récupérer aucune information. Cela pourrait être un peu au-delà de ce que vous êtes prêt à faire pour cela.

1
briantist

Une autre approche est l’imprégnation, c’est une bonne option si vous ne souhaitez pas activer la communication à distance.

Vérifiez ceci - https://web.archive.org/web/20170410101407/poshcode.org/1867

Vous devriez simplement importer ce module et mettre votre code entre 

Push-ImpersonationContext $ credential

et 

Pop-ImpersonationContext

1
olegk