Bonjour,
 
J'ai une petite problématique sous la main.
Dans mon entreprise, nous avons un logiciel utilisateur qui nécessite des droits d'administrateur afin de tourner correctement. (d'où l'impossibilité de mettre des restrictions : tous les utilisateurs sont administrateurs de leur poste)
J'ai déjà vu sur un poste de l'université un cmd qu'on lançait, qui possédait des droits d'exécution d'administrateur. Le programme était compilé, les informations de connexion n'étaient pas disponibles en l'ouvrant au notepad.
En gros j'aimerais, avec un peu de prog (j'imagine que c# serait le plus facile), fabriquer un lien vers une application, le lien authentifiant automatiquement en Administrateur.
--> en gros il y a dans le programme : "run c:\programme.exe as administrator with username==plop && password==plop"
Je voudrais savoir si quelqu'un a déjà eu une idée comme celle-là, qu'il puisse donner un ou deux conseils par ou chercher, si je me plante pas de direction ...
 
Merci !

Tu dois parler de la commande runas.

C'est évidemment pas recommandé.

Es-tu sur que ton application ne peux pas tourner en mode utilisateur?
La plupart du temps cela nécessite simplement d'augmenter les permissions ntfs pour les utilisateurs afin d'écrire dans le répertoire d'installation de l'appli par exemple.

Le mieux pour vérifier tout cela est de monitorer avec ProcMon les accès refusés lors du lancement de l'application.

+1 pour procmon, il te dira exactement où ca bloque

+1 pour un équivalent à runas, en scripter.
J'utilise psexec dans du script compilé en AutoIT pour ne pas que le mot de passe admin circule trop facilement.

+1 pour statoon54
il y a toujours un moyen, l'utilisation d'un compte admin pour tourner est une aberration, sinon appeler l'éditeur.

Y a rien de pire effectivement, c'est comme décidé de lancer par défaut sur un serveur Unix toutes les commandes en sudo... Imagine qu'un petit malin désassemble ton prog et arrive à traduire le password admin...

Bah par rapport à mon cas, c'était pour lancer de la commande bien particulière, avec devcon et psexec.
Après je ne dis pas que c'est "la" solution, il y a un risque potentiel effectivement. Mais c'est déjà mieux que de donner les droits à tout le monde et sur tous les programmes.

+1 sur procmon
 
note : voir aussi les droits sur le registre.
 
Je bosse dans une boite avec 350 PC , on a une 20 de grosse appli et plein de petites. On migre de XP à W7 actuellement. Sur XP installé avant mon arrivé tout le monde était admin. La sur 7 on a déployé plus de 200 postes et plus personnes ne l'est.
Pour les appli on a regardé avec procmon et repéré les dossiers et les éléments du registre qui posaient problème.

sous AutoIT tu as la commande RunAs
Ne pas oublier "d'obstenfuquer" après la compilation pour rendre difficile la décompilation

RunAs n'a pas fonctionné dans mon cas (pourtant dernière version d'AutoIT)
Néanmoins avec psexec on s'en sort facilement.

marrant moi ca a toujours fonctionner, la seule astuce avec la fonction RunAs est d'utiliser la variable @ComputerName à la place du domaine si on veut se logguer avec un utilisateur local

Bah avec moi ça ne fonctionnait pas, devcon n'en voulait pas.
Après à l'époque j'avais pas envi de m'enquiquiner 107 ans pour un truc qui devait durer 3 mois, alors j'ai fait "osef ça fonctionne avec psexec et un Run "

plop merci pour toutes ces réponses
Au final j'ai trouvé un petit programme : cpau.exe qui permet de faire tourner un programme avec des droits différents.
 
Le bat contient ça
cpau -file \\serveur\scripts\script.txt -dec -profile
On pourra même le compiler en .com il me semble
 
Et le fichier script.txt qui contient le programme et les logins sont cryptés, le fichier commence par :
365357205311BF5325113354D46114112112112107107114105104107102101103100B76102C76A73...
Ce ne sont pas nos utilisateurs qui réussiront à cracker ca.
Au pire, le compte que nous utiliserions pour lancer le programme n'a que des droits sur les machines locales, aucun sur les serveurs, l'AD.
 
 

merci pour le retour d'info, c'est intéressant à savoir.

PErso il m'a fallut entre 10 et 30 minutes par appli pour connaitre les clés de registre et les dossiers à autoriser avec procmon, et ca évite de mettre les mdp dans un script même crypté.
 
Bon étant donnée que ton compte n'a que des droits locaux cela reste un risque acceptable.
 
Comment sont cryptés les mdp ? algorithme réversible sans clé ?

cpau.exe : appli compatible XP/2003
Le développement semble s'être arrêté en 2005...
 
J'irai jamais mettre ça en prod. La manière propre (= analyser pourquoi l'appli a besoin de droits d'admin et y remédier) me paraît la plus pertinente.