Sudo sous Windows : comment devenir simplement administrateur en ligne de commandes

Sudo sous Windows : comment devenir simplement administrateur en ligne de commandes

En attendant qu'elle soit portée comme ssh et curl

Avatar de l'auteur
David Legrand

Publié dans

Logiciel

07/05/2019 3 minutes
34

Sudo sous Windows : comment devenir simplement administrateur en ligne de commandes

Certaines commandes pratiques sous Linux n'ont pas d'équivalents aussi simples sous Windows. Sudo est un bon exemple même si des alternatives existent, permettant de se faciliter la vie. 

Dans les systèmes d'exploitation modernes, plusieurs comptes peuvent être utilisés, chacun avec des droits propres. Ainsi, il peut y avoir des utilisateurs simples, d'autres qui ont accès à certains dossiers/fichiers, parfois en lecture et/ou en écriture, peuvent utiliser ou non telle application, etc. Puis il y a l'administrateur, ou root dans les systèmes UNIX.

Il a en général accès à tout et peut tout faire, notamment installer de nouvelles applications, mettre à jour le système, accéder aux données de configuration, etc. Selon les OS, l'accès à ce compte est géré différemment.

Administrateur sous Linux/Windows : ce n'est pas toujours si différent

Sous Windows par exemple, l'utilisateur principal est en général l'administrateur. Il peut ainsi décider de lancer des applications de manière classique ou avec les droits administrateur, via un clic droit sur l'icône de l'application.

Dans de nombreuses distributions Linux, on trouve une mécanique similaire. Il est ainsi possible de ne pas avoir de compte root actif au profit d'utilisateurs classiques pouvant endosser ce rôle de manière temporaire. Ce qui permet d'éviter une connexion constante à un compte ayant tous les droits, avec les risques que cela comporte.

Dans la pratique, cela passe par l'exécution de la commande sudo (Substitute User Do). Par exemple sous Debian, on peut effectuer la recherche d'un paquet comme un utilisateur classique, mais l'installer avec les droits administrateur :

apt search vlc
sudo apt install vlc

Sous Windows, il n'y a pas d'équivalent si direct en ligne de commandes. Des alternatives doivent donc être utilisées.

Sudo sous Windows : comment faire ?

Car les droits administrateurs ne sont pas toujours nécessaires. On a donc plutôt tendance à utiliser l'invite de commandes de manière classique. Lorsqu'ils le deviennent, on doit lancer une nouvelle fenêtre avec un clic droit pour les activer, un clic de confirmation étant nécessaire (pour l'UAC). Une démarche fastidieuse.

On peut alors opter pour une commande permettant elle aussi d'effectuer une action avec un autre compte, comme celui d'un administrateur. Elle a l'avantage de fonctionner depuis n'importe quel compte du système, mais la syntaxe est un peu longue à retenir. On pourra alors passer par un alias pour se simplifier la vie.

runas /noprofile /user:Utilisateur_Administrateur "commande_à_exécuter"

Avec le temps, certains ont travaillé à de petites applications complémentaires comme Elevate ou des adaptations de sudo pour Windows qui ne sont plus toujours maintenues (voir ici ou ). D'autres ont planché sur une solution multiplateforme comme exec-root de Syed Jafri, qui s'installe comme un module NPM ou Yarn à intégrer à vos applications. 

Une solution pratique est le paquet de Jan Hebnes qui est assez complet et s'installe facilement via Chocolatey. On peut en effet l'utiliser sous différentes formes, que ce soit pour lancer une commande non pas en se substituant à un autre compte, mais en endossant les droits administrateur :

sudo commande

Le faire en restant dans le dossier courant, avec ou sans la fenêtre de contexte :

sudo . commande
sudo _ commande

Lancer un invite de commandes avec les droits administrateur :

sudo .

Écrit par David Legrand

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Administrateur sous Linux/Windows : ce n'est pas toujours si différent

Sudo sous Windows : comment faire ?

Commentaires (34)


Ca fait un peu solution en plâtre ouvragé et ciselé sur jambe de bois.


Bah comme dit, il y a plusieurs méthode : la commande Windows, l’alias ou le module complémentaire. A chacun de voir ce qu’il préfère ;) 


La commande Windows est juste horrible :)



Sinon, j’aime bien tous ces petits dossiers astuces Windows / Linux, est-ce qu’il y a un moyen simple de filtrer les news pour ne voir que ces dossiers  ? Genre une catégorie tuto ?

Je vois dans l’image un tag “tuto”, j’ai eu envie de cliquer dessus :)


C’est dit de manière très implicite, mais sudo ou runas ont aussi comme grand intérêt d’exécuter des actions avec un autre profil utilisateur, pas que root/admin.



Sudo permet ainsi d’exécuter une action au nom d’un utilisateur qui a l’instruction nologin et donc inutilisable en direct.

Exemple : www-data qui est créé avec Apache par défaut sur Debian et qui n’autorise pas la connexion. (et la blinde d’autres comptes de services verrouillés)



Un détail intéressant pour runas aussi, issu de vieux souvenirs mais qui je pense sont toujours d’actu, c’est que ça peut aussi permettre de jouer entre comptes de domaines et comptes locaux sur un Windows.

Avec l’instruction /user:\jeanmichel ou /user:localhost\jeanmichel



Je ne sais pas si vous avez prévu de parler plus en détail du sudoers, mais ça permet aussi de faire des trucs bien puissants et fins pour des gestes d’administration encadrés.


merci !




Ce qui permet d’éviter une connexion constante à un compte ayant tous les droits, avec les risques que cela comporte



Je ne comprends pas la remarque.

Si on crée un compte admin sous Windows ce n’est pas pour l’utiliser en permanence.

D’ailleurs la plupart du temps on peut installer les logiciels directement à partir d’un compte non admin avec un clic droit et “exécuter en tant que”, voire on peut lancer une invite de commandes en tant qu’administrateur.



Ou alors je n’ai pas compris la problématique.


Je suppose que le but est faire tout cela en ligne de commande sans lancer une invite de commande en tant qu’administrateur.








carbier a écrit :



Je ne comprends pas la remarque.

Si on crée un compte admin sous Windows ce n’est pas pour l’utiliser en permanence.

D’ailleurs la plupart du temps on peut installer les logiciels directement à partir d’un compte non admin avec un clic droit et “exécuter en tant que”, voire on peut lancer une invite de commandes en tant qu’administrateur.



Ou alors je n’ai pas compris la problématique.





Dans le passage j’évoque le cas de sudo avec un compte root non actif, ce qui permet d’éviter d’avoir un utilisateur qui se connecte à la machine en root et l’utilise tel que en permanence.



Il y a tout de même une différence d’importance sous Windows en cas d’utilisateur unique (souvent le cas pour un usage grand public) : il est administrateur, et lorsqu’il est connecté l’UAC ne lui demandera qu’un clic pour confirmer son statut plutôt qu’un mot de passe régulièrement à la sudo. 







Notice me Sempai a écrit :



Je suppose que le but est faire tout cela en ligne de commande sans lancer une invite de commande en tant qu’administrateur.





Sans qu’elle soit forcément lancée au départ oui. Comme dit dans l’article, souvent on se retrouve à lancer un invite de commande classique vu que plus n’est pas nécessaire.



Si on veut un accès administrateur il faut relancer un invite avec ces droits ce qui demande une manip à la souris (trouver la fenêtre, clic droit, lancer un invit en mode administrateur, UAC, fenêtre à part). Là on peut le faire avec un sudo . ou en lançant directement la commande via sudo commande. 



Beaucoup ont encore le sale réflexe de “sudo su - ” et YOLO.

C’est un peu comme ceux qui font direct chmod 777 au moindre problème de droit, une vermine à exterminer. <img data-src=" />








SebGF a écrit :



Beaucoup ont encore le sale réflexe de “sudo su - ” et YOLO.





Quelle idée alors que sudo -s suffit ! <img data-src=" />



Autant je plussoie pour le chmod, autant faire un sudo -i / sudo su ça a du sens, quand tu dois faire un grand nombre d’opérations en root.



Typiquement en tant qu’admin sys, sur les serveurs que j’administre, je passe tout mon temps en root, quasiment. Taper sudo à chaque ligne pendant 10 minutes (ou plus), c’est vite gonflant.


+1&nbsp;








Br31zh a écrit :



Autant je plussoie pour le chmod, autant faire un sudo -i / sudo su ça a du sens, quand tu dois faire un grand nombre d’opérations en root.&nbsp;





Sauf que « sudo su », c’est sale, et à bannir. Pour passer root depuis un autre compte, tu as soit « su - », soit « sudo -i », soit « sudo -s » (selon ce que tu veux comme variables d’environnement : celle de ton utilisateur ou celles de celui auquel tu veux te connecter).



Je rejoins Br31zh, avant de m’exterminer*, je serais curieux de savoir en quoi il serait plus pertinent de préfixer toutes les commandes que tu as à faire par un sudo plutôt que de passer en root le temps de passer les commandes avant de revenir à la session utilisateur. La seule justification que je puisse y voir, c’est de conserver les commandes dans son historique bash plutôt que de polluer celui du compte root.



Par contre, j’irais même plus loin sur la possibilité offerte à une utilisateur de faire un « sudo su - », ça veut surtout dire que le système a été troué en amont par l’administrateur — consciemment ou non vu que certaines distributions le font d’office avec un root sans mot de passe — puisque le sudoers autorise quelqu’un à exécuter n’importe quelle commande en tant que root, avec ses identifiants réguliers.



Pour moi, il est ici le véritable danger, pouvoir exécuter directement une commande nécessitant des privilèges particuliers avec les seuls identifiants de l’utilisateur. Dit autrement, un programme malveillant réussissant à obtenir le mot de passe de l’utilisateur fait son escalade de privilèges comme bon lui semble sans se prendre la tête le thread.



Ce qui m’amène à mon « * » du début, en fait j’utilise systématiquement une élévation classique avec su quand c’est possible, « sudo -i »/« sudo su - » c’est vraiment juste pour les cas exceptionnel où je n’ai pas le mot de passe root et c’est généralement temporaire.


En quoi « sudo -i » et « sudo su - » seraient si radicalement différent au point que l’un soit plus à bannir que l’autre ? Même question avec « sudo -s » et « sudo su », que j’aurais pour le coup tendance à délaisser au profit des deux premières.








David_L a écrit :



Dans le passage j’évoque le cas de sudo avec un compte root non actif, ce qui permet d’éviter d’avoir un utilisateur qui se connecte à la machine en root et l’utilise tel que en permanence.



Il y a tout de même une différence d’importance sous Windows en cas d’utilisateur unique (souvent le cas pour un usage grand public) : il est administrateur, et lorsqu’il est connecté l’UAC ne lui demandera qu’un clic pour confirmer son statut plutôt qu’un mot de passe régulièrement à la sudo.





Mais cela relève plus d’une mauvaise pratique qu’autre chose. Windows offre la possibilité de faire une distinction et de créer un profil dédié admin.

La différence c’est qu’à l’installation Windows te crée directement un profil administrateur alors que Linux te crée un profil utilisateur sudoer.



Pour moi cela ne change pas grand chose en termes de sécurité: les pires cas que j’ai pu voir autour de moi c’est quand une famille avait un compte unique sur le PC et que les gamins ont installé tout et n’importe quoi dessus. Mais si ton compte familial a le profil sudoer, cela n’aurait pas changé grand chose au final.



Perso je vois plus un problème de sensibilisation du grand public à la sécurité sur PC qu’autre chose.







David_L a écrit :



Sans qu’elle soit forcément lancée au départ oui. Comme dit dans l’article, souvent on se retrouve à lancer un invite de commande classique vu que plus n’est pas nécessaire.



Si on veut un accès administrateur il faut relancer un invite avec ces droits ce qui demande une manip à la souris (trouver la fenêtre, clic droit, lancer un invit en mode administrateur, UAC, fenêtre à part). Là on peut le faire avec un sudo . ou en lançant directement la commande via sudo commande.





Invite de commande épinglée au bureau: clic droit, lancer une invit en mode administrateur, mot de passe et fenêtre. Cela revient à faire un su - uniquement sur la fenêtre et évite de devoir retaper le mot de passe à chaque x commandes sudo.







SebGF a écrit :



Beaucoup ont encore le sale réflexe de “sudo su - ” et YOLO.

C’est un peu comme ceux qui font direct chmod 777 au moindre problème de droit, une vermine à exterminer. <img data-src=" />





+1

Et cela sera d’ailleurs le problème pour le grand public si c’est celui dont on parle.

Sans parler des distros linux qui t’installent le système avec un compte root sans mot de passe au départ









SebGF a écrit :



Beaucoup ont encore le sale réflexe de “sudo su - ” et YOLO.

C’est un peu comme ceux qui font direct chmod 777 au moindre problème de droit, une vermine à exterminer. <img data-src=" />





Edit trop tard



Cependant un su - a un intérêt pour les admins lors d’une longue séance d’installation / mise à jour / configuration.

De toute façon tu peux configurer sudo pour ne redemander le mot de passe qu’après x temps, ce qui revient en parti au même vu que tu passeras toutes tes commandes avec un sudo en préfixe.









carbier a écrit :



Mais cela relève plus d’une mauvaise pratique qu’autre chose. Windows offre la possibilité de faire une distinction et de créer un profil dédié admin.



La différence c'est qu'à l'installation Windows te crée directement un profil administrateur alors que Linux te crée un profil utilisateur sudoer.&nbsp;







C’est la pratique par défaut de Windows quand tu installes le système surtout, la mauvaise pratique vient de là, un peu comme Bitlocker réservé aux Pro. Mais ça doit faire partie des choix “parce que sinon c’est trop compliqué pour l’utilisateur” (déjà que certains désactivent l’UAC…



Après tu peux faire le choix de créer un compte secondaire en utilisateur uniquement, mais dans 99% des cas (hors entreprises) ce n’est pas le cas. Pour Linux, ça dépend des distributions. Debian te propose de créer ou pas un compte root, Ubuntu ne le fait pas par défaut (mais tu peux, via le preseed notamment).&nbsp;









carbier a écrit :



Invite de commande épinglée au bureau: clic droit, lancer une invit en mode administrateur, mot de passe et fenêtre. Cela revient à faire un su - uniquement sur la fenêtre et évite de devoir retaper le mot de passe à chaque x commandes sudo.&nbsp;





Oui, si tu n’a rien d’ouvert, m’enfin ça arrive souvent d’avoir un invite ouvert mais sans les droits administrateur. sudo . te permet d’ouvrir en une ligne de commande, sudo de juste exécuter une commande si tu n’as rien besoin de plus. Au pire il y a l’alias sur runas.



&nbsp;Après il y a ceux qui préféreront une méthode plutôt qu’un autre, je ne dis pas que l’un est meilleur. Juste qu’un équivalent de sudo simple est un manque pour l’invite de commandes windows et qu’il y a des solutions pour ça.&nbsp;









carbier a écrit :



La différence c’est qu’à l’installation Windows te crée directement un profil administrateur alors que Linux te crée un profil utilisateur sudoer.



Il y a tout de même d’autres différences avec l’UAC de windows, dont une qui n’est pas sans conséquences. La fenêtre de consentement qu’il affiche est un processus système et n’est accessible qu’en ayant les privilèges suffisant : un programme tiers n’ayant pas les privilèges suffisants ne sera pas en mesure de valider la demande. Fort heureusement, les périphériques HID (souris, clavier, …) ont les privilèges nécessaires pour permettre à l’utilisateur physiquement présent sur la machine de valider la demande.









David_L a écrit :



Oui, si tu n’a rien d’ouvert, m’enfin ça arrive souvent d’avoir un invite ouvert mais sans les droits administrateur. sudo . te permet d’ouvrir en une ligne de commande, sudo de juste exécuter une commande si tu n’as rien besoin de plus. Au pire il y a l’alias sur runas.



C’est bien l’une des raisons qui me pousse à toujours afficher la barre « Quick Launch », je mets toujours dedans un raccourcis vers « %windir%\system32\cmd.exe /K “CD /D %HOMEDRIVE%%HOMEPATH%“ » avec l’option exécuter en tant qu’administrateur cochée, comme ça j’ai toujours le raccourcis à portée de main — enfin sauf sur les écrans secondaires, vu que Windows 10 n’est toujours pas fichu de cloner l’intégralité de la barre des tâches.



Pour runas, je serai curieux de savoir comment tu peux arriver à l’utiliser par contre quand tu n’as pas un autre compte admin protégé par un mot de passe, si je l’utilise avec mon propre compte pour relancer un cmd par exemple, je n’ai pas de consentement qui s’ouvre et je suis toujours simple utilisateur dans le nouvel invite de commandes.



Je pensais que le “et YOLO” serait suffisamment explicite (avec l’exemple du chmod) pour laisser entendre que la bascule en root ne peut se faire sans maîtrise.



J’ai trop souvent vu des comportements du style passage en root et copier/coller de commandes sans même savoir ce que ça fait… Raison pour laquelle j’aime sortir un petit “t’es sûr de ce que tu fais ?” sur un ton anxiogène quand je vois pratiquer ce genre de chose <img data-src=" />


C’est sûr que le comportement plus grand dangereux, c’est bien celui de reproduire naïvement des opérations sans même chercher à comprendre ce qu’elles font ni pourquoi les exécuter — et ce n’est d’ailleurs pas valable qu’en informatique. <img data-src=" />



Un autre exemple de méconnaissance flagrante qui se répand comme une trainée de poudre dans les tutos pour créer un utilisateur MySQL/MariaDB, c’est le « FLUSH PRIVILEGES » juste après un « GRANT […] », « juste au cas où ». Les conséquences sont anecdotiques par rapport au fameux « chmod 777 », mais c’est très symptomatique du « on m’a dit que, et comme ça me permet de, alors je le fais bêtement ». <img data-src=" />


Sinon faut faire un alias yolo &gt; sudo su - <img data-src=" />


Je ne suis pas sûr de comprendre la remarque, mais le comportement de la barre des tâches dans les configurations multi-écrans est paramétable, pour reproduire ou non d’un écran à l’autre.&nbsp;


Idéale pour jouer à la roulette russe <img data-src=" />


<img data-src=" />


J’ai absolument aucune idée de pourquoi tu dis ça, je me suis jamais posé la question. Perso je lance sudo -i parce qu’à une époque j’avais trouvé ça bien de faire directement tout via une seule commande au lieu de lancer su via sudo, mais c’est plus intuitif qu’autre chose.



J’utilise le « -s » pour lancer bash si un petit malin a décidé de mettre autre chose que bash comme shell pour root, sinon.


Justement, il n’y a quasiment rien de paramétrable pour les écrans secondaires, hormis de dire si tu veux faire afficher juste les fenêtres de l’écran, ou l’ensemble des applications. Si tu optes pour la première option, tu as le strict minimum :





  • à gauche, le menu démarrer, cortana/rechercher et le bouton « Applications actives » si activé,

  • les fenêtres ouvertes sur l’écran,

  • et à droite, l’horloge avec le bouton Windows Ink si activé.





    Dans le second cas, tu aussi récupères les applications épinglées et… c’est tout ! <img data-src=" />



    Peu importe les réglages, tu n’as strictement rien d’autre, aucune barre d’outils additionnelle, pas de zone de notification, ni même le centre de notifications ou tout autre bouton activable via un clic droit sur la barre des tâches (contacts, clavier et pavé tactile). Actuellement, la seule solution à ma connaissance est de passer par des programmes tiers, tous payants, pour véritablement dupliquer à l’identique la barre des tâches sur tous les écrans.



    La seule autre chose que l’on puisse faire, c’est de déplacer la barre des tâches complète vers un des écrans secondaires, mais du coup tu récupères la version minimaliste sur ton écran principal tant que tu restes en multi-écrans. <img data-src=" />


Perso j’utilise Cmder qui permet d’ouvrir de nombreux shell, y compris un linux embed dans Windows.



Et on peut pré-prévoir l’ouverture d’un shell en mode admin. Tout beau, tout propre.


Voir ici ;)








SebGF a écrit :



Beaucoup ont encore le sale réflexe de “sudo su - ” et YOLO.

C’est un peu comme ceux qui font direct chmod 777 au moindre problème de droit, une vermine à exterminer. <img data-src=" />





(pour info, je suis Unixien depuis le début des années 90, j’ai commencé par Solaris et j’ai vu l’arrivée de NetBSD, puis FreeBSD et Linux. <img data-src=" /> )



Effectivement, au début quand je suis passé de Mandriva à Ubuntu et qu’il n’y avait plus de mot de passe root en tant que tel, je faisais “sudo su -” au lieu du simple “su -” que je faisais avant pour passer root. Au bout d’un moment j’ai vu que “sudo -i” faisait la même chose, mais je ne crois pas que ça change quoi que ce soit en pratique : on doit entrer le mot de passe, et on se retrouve dans le même environnement.



Sinon, je n’ai jamais fait le “chmod 777”, sauf dans certains cas particuliers.



Pour moi, une vraie sale habitude, c’est le “kill -9” (sale et à faire en dernière extrémité), alors qu’il faut d’abord faire “kill”, puis “kill -INT” (simule CTRL-C), voire “kill -USR1” (certains programmes le choppent), ce qui permet au programme de quitter un peu proprement selon sa conception. Quand tout a échoué, je fais un “kill -KILL” (je ne tape pas de chiffre, ce n’est pas toujours portable selon les Unix).







fred42 a écrit :



Quelle idée alors que sudo -s suffit ! <img data-src=" />





Je ne pratique pas, car je veux retrouver mon environnement root que je fais le “su”, j’ai certains alias particuliers, et certains scripts aussi dans le “HOME” (/root).







Br31zh a écrit :



Autant je plussoie pour le chmod, autant faire un sudo -i / sudo su ça a du sens, quand tu dois faire un grand nombre d’opérations en root.





Clairement.

Drôle d’idée de tout taper avec “su” devant, ça n’a aucun sens.

Les admins Unix jusqu’aux années 2010 (environ) ont toujours ouvert des shells en root pour faire leur boulot, c’était la manière normale de procéder.







cedricpc a écrit :



Je rejoins Br31zh, avant de m’exterminer*, je serais curieux de savoir en quoi il serait plus pertinent de préfixer toutes les commandes que tu as à faire par un sudo plutôt que de passer en root le temps de passer les commandes avant de revenir à la session utilisateur. La seule justification que je puisse y voir, c’est de conserver les commandes dans son historique bash plutôt que de polluer celui du compte root.





Je pense au contraire que c’est mieux d’avoir un historique séparé pour root.







Trit’ a écrit :



Sauf que « sudo su », c’est sale, et à bannir. Pour passer root depuis un autre compte, tu as soit « su - », soit « sudo -i », soit « sudo -s » (selon ce que tu veux comme variables d’environnement : celle de ton utilisateur ou celles de celui auquel tu veux te connecter).





En quoi “sudo su” c’est sale ? C’est juste inutile car un “su” de “su”.







carbier a écrit :



+1

Et cela sera d’ailleurs le problème pour le grand public si c’est celui dont on parle.

Sans parler des distros linux qui t’installent le système avec un compte root sans mot de passe au départ





Comme quelles distros ?



Si vous avez psexec, vous pouvez même ouvrir une ligne de commande pour l’utilisateur System (le VRAI root de Windows) :



runas /user:Administrateur “psexec -s cmd.exe”



Ou si vous avez besoin de pouvoir lancer des fenêtres (par exemple pouvoir lancer regedit en tant que System depuis la ligne de commande), ajouter -i :

runas /user:Administrateur “psexec -i -s cmd.exe”

&nbsp;

Ne pas mettre /noprofile pour le runas sinon psexec ne fonctionnera pas.



De rien :-)


Bizarre je ne peux plus éditer mon message.



Je voulais juste ajouter :



C:\WINDOWS\system32&gt;whoami

autorite nt\système