none
Exécution d'un script en tant qu'administrateur puis bascule sur le compte d'un autre utilisateur. RRS feed

  • Întrebare

  • Bonjour à tous,

    Je suis en remplacement d'un collègue très malade et je rencontre un problème que je n'ai pu solutionner au moyen des recherches que j'ai effectué alors j'en appel à votre aide.

    J'ai un script qui me copie chaque matin un fichier de sauvegarde (il s'agit d'une machine virtuelle) sur  2 machines, une fois cela fait, j'exécute via le bureau à distance l'importation de la machine en question.

    Mon côté informaticien me dit que je dois pouvoir automatiser le tout mais je pêche sur comment lancer la commande en tant qu'un autre utilisateur.

    Mon script se lance manuellement pour le moment mais j'envisage de l'automatiser via les tâches planifiées avec un compte de service.

    Je n'ai rédigé qu'un petit bout de code pour le moment qui me permet de faire la copie du fichier sur le poste distant alors je ne suis pas en mesure de vous partager le script et je reste bloqué sur comment faire pour exécuter mon fichier *.exe en tant qu'autre utilisateur.

    J'ai bien vu des tutos qui pourrait ressembler à ce dont j'ai besoin mais je dois avouer que je n'ai pas compris la lecture du script car je débute en powershell.

    Merci d'avance pour votre aide.

    joi, 12 septembrie 2019 10:29

Toate mesajele

  • Bonjour Flo,

    si je te suis bien ton script ferait

    - copie d'un fichjier sur une (des) machine distante

    $serveurs = Get-Content -Path "c:\Scripts\Serveurs.txt" # liste de tes serveurs
    
    Foreach ($serveur in $Serveurs)
        {
        $Source = "C:\scripts\Monscript.ps1"
        $Destination = "\\$Serveur\c$\scripts" #note que je passe par le partage administratif
        Copy-Item -Path $Source -Destination $Destination -Force # -force pour écraser si existant
        }


    - exécuter le dit fichier sur la machine distante

    Invoke-Command -ComputerName $serveurs -FilePath C:\myFolder\myScript.ps1

    - récupérer le fichier généré par le script

    $RemoteBackupPath = "c:\backup"
        $LocalBackupPath = "\\MaMachine\c$\backup\$serveur"
        Copy-Item -Path $RemoteBackupPath -Destination $LocalBackupPath

    On met tout ça en musique

    $Source = "C:\scripts\Monscript.ps1"   # mon script à exécuter
    $serveurs = Get-Content -Path "c:\Scripts\Serveurs.txt" # ma liste de serveurs
    $RemoteBackupPath = "c:\backup" # path ou va se situer le (les) fichiers résultant de l'exécution du script de manière distante
    $LocalBackupPath = "\\MaMachine\c$\backup\$serveur" # Path ou vont se loger la copie locale que tu veux récupérer
    
    Foreach ($serveur in $Serveurs)
        {
        Write-Verbose "Copie du script sur $serveur"
        $Destination = "\\$Serveur\c$\scripts" #note que je passe par le partage administratif
        Copy-Item -Path $Source -Destination $Destination -Force # -force pour écraser si existant
        
        Write-Verbose "exécution du script remote pour $serveur"
        Invoke-Command -ComputerName $serveur -FilePath C:\myFolder\myScript.ps1 # Invoke-Command permet l'exécution sur la machine distante
    
        Write-Verbose "récupération de la sauvegarde de $serveur en local"
        Invoke-Command -ComputerName $serveur -ScriptBlock {Copy-Item -Path $RemoteBackupPath -Destination $LocalBackupPath}
        }

    Il reste à gérer les erreurs, ... enfin tout ce que doit faire un script bien foutu mais il y a la base. 

    En ce qui concerne l'exécution du tout. 

    Ce que tu as es donc un script (fichier ps1) que tu peux faire exécuter très simplement via une tâche planifiée. Dans ton cas, la tâche s'éxécuterait sur ton poste.

    Oui mais avec quel compte ?

    Définis ta tache planifiée pour tourner avec un "compte de service". Ce compte de domaine doit disposer des droits Admin sur ton poste (pour exécuter la tâche planifiée et le script) ainsi que sur les machines distantes. Aucun privilège particulier n'est requis sur le domaine.

    Bref, tu créés dans ton AD un compte ScheduledTasks, tu lui colles un mot de passe que tu sauvegarde bien précieusement dans un coffre avec des parois de 20 cm min (un keypass fera l'affaire, moins lourd à transporter :-). Tu n'oublies pas de cocher "password never expire" et "de décocher "l'utlisateur doit changer de mot de passe à la 1ère connexion". Membre de : Domain Users, rien de plus.

    Nota : tu n'oublies pas de mettes une note dans l'entrée du Keypass indiquant  sur quelles machines et avec pour quel usage (droits sur la machine ici) est utilisé ce compte. Ca servira le jour où ... tu changeras le mot de passe par ex. Tu peux utliser ce même compte pour faire le même type d'activité sur pleins de machines.

    Tu vas ensuite sur ta machine, ainsi que sur les machines remote et tu ajoutes ce compte dans le groupe administrators local.

    Ca devrait le faire (pour peu que tu n'ai pas une GPO "groupes restreints"). Je dis ça pour Sylvain ou Philippe qui ne vont pas manquer de réagir :-) Oui, en effet NT Autority\System suffit pour exécuter une tache planifiée, et un script local, mais n'a aucun droit sur les machines distantes, alors ça ne le fera pas pour la copie, l'exécution du script remote et touti quanti.

    Je ne te propose même pas d'utiliser un GMSA pour faire tourner ta tache planifiée. Ca serait plus secure, mais je vais arrêter le romain ici :-)

    Olivier

    joi, 12 septembrie 2019 11:52
  • Bonjour,

    Si j'ai bien compris, vous souhaitez scripter 2 actions :

     1. Copier une machine virtuelle depuis une source vers 2 destinations : cela peut se réaliser avec un compte administrateur en effet, pas de problèmes

     2. Ensuite, vous souhaitez exécuter une session de bureau à distance pour importer la VM dans l'environnement : là, ça se corse !

    Tout d'abord, je ne suis pas sûr que le bureau à distance soit la meilleure solution : en effet, je ne vois pas comment un script pourra interagir avec la session RDS...

    > J'opterai plutôt pour une connexion Powershell à distance pour réaliser l'importation... Mais il faut en savoir plus sur l'environnement...

    La machine virtuelle est une VM Hyper-V ou bien d'un autre éditeur?


    Cordialement,

    Sylvain (MCP, MCTS Windows Server 2008 R2 Server Virtualization, MCTS Exchange 2010)

    http://snsv.consulting

    Blog : http://sylvaincoudeville.fr

    joi, 12 septembrie 2019 11:57
  • Merci pour la réponse...

    Effectivement, vous avez compris l'idée du script. J'ai codé le déploiement et suis en train de réaliser le code en prenant en compte les erreurs etc... pour cette partie, je n'ai pas trop de problème.

    J'ai pris en compte la problématique du compte de service également.

    La ou les choses se corsent, c'est lorsque j'importe la machine virtuelle sur ma machine cliente.

    Nous utilisons une solution gratuite de virtualisation qui s'appelle Boîte Virtuelle (pour ne pas faire de pub)...

    Une fois ma sauvegarde effectuée, j'importe la VM en utilisante une ligne de commande via un batch.

    L'inconvénient de cette méthode et que cela m'impose d'être loggé avec le compte qui sera utilisé pour voir apparaître ma VM dans le logiciel. Je ne peux donc utiliser mon compte administrateur ou le compte de service.

    Je pensais effectuer quelque-chose comme cela :

    Exécution de différents tests de connexion, etc...

    Si tout va bien, on copie la sauvegarde sur le 1er client,

    Une fois la copie terminée, exécuter la commande d'importation en utilisant le compte utilisateur1

    Suite pour la machine2

    joi, 12 septembrie 2019 12:10
  • Merci pour votre réponse,

    C'est ça, je souhaite 2 actions distinctes :

    1ère étape : Copie de la sauvegarde, écrasant la sauvegarde initiale, etc... jusque la, j'arrive à gérer.

    2ème étape : Exécuter une commande MS-DOS pour lancer un fichier .exe avec des paramètres en utilisant un compte utilisateur, utilisé sur la machine cliente.

    La ça se corse, je ne sais pas et ne trouve pas comment exécuter cette opération.

    joi, 12 septembrie 2019 12:13
  • mais quel est cet .exe sur le poste distant qu'il faut impérativement lancer avec un compte utilisateur ?

    Y a -t-il une raison particulière à ça ?

    joi, 12 septembrie 2019 14:12
  • Je ne voulais pas faire de publicité pour le logiciel en question mais pour la bonne compréhension, je n'ai pas d'autre choix.

    J'utilise VirtualBox et l'exe en question se trouve être VBoxManage.exe.

    Lorsque je fais l'import de ma machine virtuelle avec mon compte administrateur, l'import de la machine se fait dans le compte Administrateur alors que je voudrais qu'il se fasse dans le compte utilisateur d'où la nécessité de lancer la commande avec le compte utilisateur en question.

    joi, 12 septembrie 2019 14:24
  • Je ne voulais pas faire de publicité pour le logiciel en question mais pour la bonne compréhension, je n'ai pas d'autre choix.

    J'utilise VirtualBox et l'exe en question se trouve être VBoxManage.exe.

    Lorsque je fais l'import de ma machine virtuelle avec mon compte administrateur, l'import de la machine se fait dans le compte Administrateur alors que je voudrais qu'il se fasse dans le compte utilisateur d'où la nécessité de lancer la commande avec le compte utilisateur en question.

    Bonjour,

    Dans ce cas, je pense que vos scripts devraient plutôt s'exécuter depuis les machines de destination :

    1. Le script copie la VM depuis la source (il suffit que le compte utilisateur ait les droits de lecture sur la source)

    2. Le script exécute VBoxManage pour importer la VM dans l'environnement utilisateur.

    En gros, dans un Batch, cela donnerait quelque chose du genre :

    @echo off
    net use z: \\serveur\partage
    
    REM Copie depuis le serveur source, vers le serveur local : tous les fichiers, écraser, copier seulement ce qui a changé
    xcopy z:\vmsource\*.* c:\mavm\ /e /c /y /d
    
    REM Import de la VM dans l'environnement utilisateur
    VBoxManage VBoxManage import MaVM.ovf

    L'avantage de cette méthode est que vous pouvez l'exécuter dans le contexte utilisateur de destination, et que c'est simple - plus c'est simple, mieux ça fonctionne !


    Cordialement,

    Sylvain (MCP, MCTS Windows Server 2008 R2 Server Virtualization, MCTS Exchange 2010)

    http://snsv.consulting

    Blog : http://sylvaincoudeville.fr

    vineri, 13 septembrie 2019 06:20