Bonjour,  
 
J'ai une application sur un PC professionnel (Windows 10) qui ne peut marcher qu'en mode "administrateur". Le PC est dans un domaine "entreprise" et les utilisateurs qui utilisent les PC n'ont pas les droits "administrateur".
 
La solution que j'ai trouvée et de lancer l'application avec une commande .BAT du style :
C:\Windows\System32\runas.exe "/user:NOMPC\Administrator" /savecred "C:\program.exe"
 
A la première utilisation, une fenêtre DOS apparaît et demande le mot de passe (en aveugle) et le sauvegarde.
Les fois suivantes, il ne redemande pas le mot de passe.
Nickel, ça marche ...
 
Mais de temps en temps, le mot de passe de "administrator" disparaît et quand le .BAT est relancé, une fenêtre DOS demande le mot de passe mais celui qui a été enregistré initialement n'est pas reconnu !
Je suis obligé d'aller sur le PC, aller dans le panneau de configuration en mode "Administrateur"' avec mon identifiant "administrateur de domaine", gestion des administrateurs et réinitialiser le mot de passe de "Administrator" local.
Ensuite, quand je relance le .BAT, il ne demande pas de mot de passe et ça marche.
 
Je n'ai jamais réussi à trouver de corrélation entre un événement particulier, une durée, ... quelque chose qui ferait que le mot de passe disparaît ainsi.
 
Auriez-vous une très bonne idée :
- soit pour que le mot de passe ne disparaisse pas
- soit une autre méthode fiable pour lancer le programme en mode "Administrateur" sans que l'utilisateur ait les droits "administrateur".
 
Merci de vos conseils, partage d'expérience, exemples, ...  
 

Dans un monde idéal, aucune appli n'a besoin des droits d'admin (sauf éventuellement à l'installation, et encore).
Seul le système lui même peut modifier ses données et cette séparation sert à le protéger.
 
Pour une grande partie des applications, il suffit de les installer dans un endroit hors des dossiers "protégés" du système (le C:\ pour simplifier).
 
Ensuite il y a encore trop d'éditeurs de logiciels qui n'ont pas compris le fonctionnement de l'OS vis à vis de la ségrégation des contextes d'exécution et des droits.
 
Si on oublie un peu cette théorie et qu'on retourne dans la réalité crasseuse, ton souci de perte des credentials peut éventuellement venir d'une politique de gestion des mots de passe (GPO par exemple).
 
Enfin tout ça pour dire que c'est un peu au cas par cas suivant comment l'application a été développée/installée.

C'est une très mauvaise idée, un contournement vraiment crade en terme de sécurité.
 
@jlchaps : c'est toi qui gère l'informatique dans cette entreprise ?

Et pourquoi ça ?

Là je ne parle que des questions de droits d'installation dans Program Files par exemple.
Le lancement de l'application reste dans le contexte utilisateur et n'a donc pas plus de droits que lui.

Le seul contournement est celui d'un installeur mal gaulé demandant des droits d'admin juste pour poser ses fichiers alors que l'application n'en aurait pas besoin.
C'est d'ailleurs pour ça que beaucoup d'applications s'installent maintenant dans le dossier AppData de l'utilisateur (dans son contexte donc) et n'ont donc pas besoin de droits d'admin à l'installation.
L'appli reste soumise à toutes les règles de sécurité ainsi que de l'antivirus.

Oui je suis administrateur local mais pas maître de la GPO qui géré par des administrateurs groupe.
Le logiciel pilote une machine de contrôle et a plus de 15 ans. Il a été développé au départ pour XP et il y a des cartes spéciales pour piloter moteurs et capteurs. Je pense que c'est pour cela que le logiciel a besoin de droits admin. En plus le logiciel qui a une base encore plus ancienne que XP est installé directement dans un dossier sur C:
J'ai essayé de donner des droits aux dossiers utilisés mais sans succès.  
Voilà pour plus de précisions.  

Justement parce que Program Files dispose de protections supplémentaires par rapport à C: En la déplaçant tu la transformes en backdoor que peut utiliser un malware sans résoudre le fond du problème.
 
@jlchaps, ce que tu es en train de faire est très dangeureux, c'est un des scénarios possibles pour faire tomber une infrastructure complète si la machine venait  à être compromise (et tu serais bien sûr désigné responsable si tu n'as jamais alerté).
 
Il faut identifier pour quelles raisons l'appli a besoin de droits admin et n'est pas compatible Windows 10 nativement, il y a des outils pour cela (BugLight pour identifier les incompatibilités notamment). Ensuite la redévelopper (ou acquérir un équivalent).
 
En attendant, tu peux la configurer avec un compte admin et un autologon mais en la sortant du domaine et en la déconnectant du réseau. Et alerter par écrit les équipes métier et l'IT interne sur les risques (techniques et financiers) et les besoins liés à cette appli.
 
 

La machine ne sert qu'à contrôler des pièces et je ne vois pas ce qui pourrai la corrompre.  
 
En plus, le fait d'être dans le domaine lui permet de bénéficier de toutes les protections nécessaires : mises à jour de sécurité, antivirus, contrôle d'accès, ...

Pas du tout, justement parce que tu est dans ton contexte utilisateur limité et non dans un contexte contrôlé par le système.
Une application lancée n'aura pas plus de droits (et de potentiel de nuisance) que l'utilisateur.

Le fait que ce soit une application conçue à la sauce XP explique les soucis de demande de droits et je suis complètement d'accord que dans l'idéal il faudrait la faire évoluer ou la changer pour une application moderne et supportée.
Problème : souvent ce genre d'applis n'ont pas eu de suivi et n'ont pas d'équivalent, à moins de racheter les machines qu'elle pilote en même temps. Ce qui est difficilement envisageable.

Pour moi les solutions dans ces cas là sont dans l'ordre :
- voir s'il existe une version mise à jour compatible Windows 10
- tenter les modes de compatibilité, mais ça va poser les mêmes soucis de demande de droits.
- conserver cette application sur l'OS compatible, mais en la sortant du réseau et du domaine (en supposant que l'appli n'en ait pas besoin) et en prévoyant sauvegardes et matériel compatible de rechange tout en anticipant le remplacement de tout ça rapidement pour garantir la continuité du service et de la maintenance. (proposition de nebulios)

En gros les soucis auxquels tu es confronté sont que :
- l'utilisation d'un compte admin est dangereux car il a "tout pouvoir" sur le système et peut le corrompre, le casser, etc ... sans garde fou.
- l'utilisation d'un OS obsolète sur le réseau de l'entreprise est dangereux en cas de faille exploitée comme il y en a eu ces dernières années. Elle pourrait être attaquée (étant un maillon faible du SI), mais aussi servir de vecteur d'attaque par la suite. Note qu'un antivirus ne sécurise pas les failles, seul un patch de l'OS si'il est encore supporté le peut.

Merci pour votre aide.  
On a plusieurs machines et chacune a son logiciel local. Les PC sont connectés au réseau et au domaine afin d'assurer les mises à jour de sécurité de Windows 10, la gestion antivirus et les contrôles d'accès au utilisateurs. Mais aussi avoir accès à un dossier réseau pour sauvegarder des résultats et enfin de pouvoir imprimer sur une imprimante réseau.
Les changer ? => plus de 20k€ par machine !!!
 
Je cherchais une explication technique à un problème technique, avec une solution technique … la solution est là mais pourquoi donc le mot de passe de l'administrateur local disparaît de temps en temps !  
 
Sans cela, ça marcherait tout le temps très bien.
 
En parallèle bien sûr, j'ai activé une demande auprès du fournisseur du matériel … mais ça traine ...

20k€ par machine peut-être, mais j'espère quand même que leur cycle de vie (et donc leur remplacement) a été anticipé.
Qu'est-ce qui est prévu si une de ces machine tombe en panne et n'est plus réparable ? Ou n'est plus fonctionnelle ? Ou n'est plus supportée ?

Pour ta question sur la demande de mot de passe, es-tu allé voir les politiques en place concernant l'authentification ?
Dans le même ordre d'idée, tu es allé voir les journaux d'événements et d'audit de Windows ?

Merci nex84 de te soucier de mon travail mais ne t"inquiète pas ... on sait gérer le remplacement et la polyvalence de nos matériels.  
Là on s'éloigne de ma question "technique".
 
Pour ce problème d'authentification, beaucoup de pistes et d'explorations ont été suivies, dans les journaux et autres logs système.
Si je viens sur ce forum, c'est pour essayer d'avoir d'autres avis et surtout le partage d'expérience de personnes ayant eu le même problème.

Si vous saviez gérer l'obsolescence de vos matériels, vous n'auriez pas de problèmes à remplacer des machines à 20k € qui sont la depuis 15 à 20 ans. C'est justement un sous-investissement qui vous amène à cette impasse, de même qu'une inconscience des impacts en terme de sécu et un certain jemenfoutisme : que tes bricolages puissent couler ta boite ne te perturbe pas plus que ça.
 
La solution à ton problème, on l'a déjà dit, c'est de migrer l'application vers Windows 10. Même en pétant toute la sécurité de l'os tu ne parviendra pas forcément à la faire fonctionner.
Je pense que ton histoire de mot de passe vient d'une sécurité appliquée par l'IT groupe. Si c'est le cas il va falloir vivre avec.

c'est vraiment du grand n'importe quoi de porter ce genre de jugement totalement hors sujet et qui n'apporte absolument aucune avancée.
Comment peut-on se permettre de porter ce genre de jugement sans rien connaître du contexte, du métier et des contraintes s'y afférant.  
Après 40 ans d'informatique c'est la première fois que je reçois ce genre de réponse. C'est trop facile d'accuser depuis son clavier.
Je préfère en rester là... adieu nebulios.  

Pour revenir dans le sujet : si le fait de mettre les droits en lecture/écriture sur le dossier de l'application ne suffisent pas, il manque certainement d'autres types de droits.
 
Est-ce que tu as essayé d'utiliser le système de compatibilité ? (clic droit / Propriétés / compatibilité).
 
Autre alternative : ce PC est-il connecté au réseau, ou peut-il en être déconnecté ? As-tu envisagé d'autres solutions comme l'isoler du réseau et revenir à un OS plus ancien (et compatible) ?

Merci Wolfman pour ces infos.  
 
L'accès au réseau est important pour récupération des données, backup des programmes de contrôle et utilisation d'une imprimante réseau.
 
Sinon le truc du "clic droit ..." a été essayé sans succès.
 
Je sais que ce n'est pas facile et c'est pour cela que je pose des questions.  
L'objet principal est de comprendre comment et pourquoi le mot de passe de l'administrateur local peut disparaître. En principe, il est "local" comme son nom l'indique et aucune règle "Groupe" ne devrait l'affecter.

C'est toujours le même compte utilisateur qui est utilisé sur ce PC ? Parce qu'il faut prendre en compte le fait que le mot de passe est enregistré dans le coffre-fort d'identifiants de l'utilisateur. Donc si tu change d'utilisateur, forcément, le mot de passe n'est plus disponible et doit être saisi de nouveau.

La gestion du compte administrateur local peut parfaitement être effectuée par l'IT Groupe, il existe même des outils dédiés à cet usage comme LAPS.

L'utilisateur est toujours le même et c'est toujours le même compte administrateur qui sert pour la runas

Ton problème ressemble un peu à un pbm que j'ai eu, la différence est que dans mon cas, ce qui était démarré était un service Windows, lancé par un compte local à la machine.
 
Quasiment tous les matins, le service ne démarrait pas, et il fallait re-saisir le mot de passe au niveau de l'authentification du service.  
On avait alors le popup " Le compte Machin à obtenu le privilège Ouvrir une session en tant que service", et on pouvait alors démarrer le service.
 
Le problème venait du rafraichissement des GPO en provenance de l'AD à intervalles réguliers.
 
On a compris ce que c'était quand on s'est rendu compte qu'en forçant la ré-application des GPO en faisan un gpupdate /force sur la machine, on perdait le droit.
 
Pour le vérifier, lancer secpol.msc sur la machine en question,  
Aller ensuite dans Stratégies locales\attribution des droits utilisateurs et regarder la rubrique ouvrir une session en tant que service
On retrouvait  dans la liste notre compte de lancement du service.
 
on faisait un gpupdate /force => le compte disparaissait de la liste.
 
On a donc lancé un gpresult -v>result.txt juste après le gpupdate /force pour avoir la liste des stratégies appliquées, et on a pu déterminer que ça venait de la stratégie par défaut (default domain Policy)
 
On est donc allé sur le Controleur de domaine, dans l'outil de gestion des stratégies de groupe , ouvrir la stratégie par défaut, et dans Configuration ordinateur \ stratégies\ paramètres windows\paramètres de sécurité\stratégies locales\attribution des droits utilisateurs on a trouvé a rubrique Ouvrir une session en tant que service.
 
Par défaut, cette rubrique est désactivé, mais si elle est activée, lors de chaque rafraichissement de l'AD, la liste des comptes autorisés à démarrer un service est écrasée par celle spécifiée à ce niveau.
Et comme on ne peut y mettre que de comptes du domaine, les comptes locaux perdent le droit de démarrer un service.
 
Il faudrait voir s'il n'y as pas un truc dans le même genre "lancer un programme en tant que" qui serait écrasé à chaque redescente de l'AD.

Merci pour ces détails... je vais aller vers cette piste.