none
Connexion avec localhost\utilisateur ne fonctionne pas RRS feed

  • Question

  • Bonjour,

    Nous avons plusieurs serveursw 2016 sur lesquels on ne peut pas se conncecter en utilisant les utilisateurs sous la forme localhost\utilisateur ou 127.0.0.1\utilisateurs.

    Quand on essaye, la connexion ne passe pas (mauvais utilisateur ou mot de passe).

    Mais si on utilise la forme .\utilisateur or nomdeserveur\utilisateur on se conncete sans problème.

    J'ai cherché sur differents forum mais sans succès.

    Nous avons besoin d'utiliser localhost\utilisateur car un de nos logiciels se sert de cette syntaxe et malheureusement c'est codé en dur.

    Merci


    mardi 16 février 2021 11:41

Toutes les réponses

  • Bonjour Thomas,

    Tu es sur un forum Fr, la langue est le français. Tu vas te faire reprendre. Modifies ton titre et le contenu de ton post.Tu peux poster en anglais si tu veux mais sur le forum US.

    Cordialement

    Olivier

    mardi 16 février 2021 12:23
  • Merci

    Traduction faite.

    mardi 16 février 2021 13:24
  • re-Bonjour Thomas,

    Au vu de tes explications, il s'agit d'une connexion local et pas RDP.

    Il pourrait d'agir d'une GPO qui bloque l'utilisation de comptes locaux pour ouvrir les sessions. TU ne serais pas le premier à qui cela arrive.

    Comment vérifier cela :

    • Ouvre une session (localement ou RDP) avec un compte de domaine autorisé à le faire
    • Fais un Gpresult ou un rsop afin d'identifier le nom de la GPO qui bloque
    • L'entrée à chercher se situerait alors ici : Computer Configuration > Policies > Security Settings > Local Policies > User Rights Assignment > puis Deny Log On Locally
    • Ensuite, il suffira juste d'ajouter un filtre WMI sur la GPO afin qu'elle ne s'applique pas sur cette machine
    • Le filtre resemblerait à cela :

    SELECT NAME FROM Win32_ComputerSystem WHERE NOT (Name LIKE 'HostName')

    # avec HostName le nom de ta machine

    [...Nous avons besoin d'utiliser localhost\utilisateur car un de nos logiciels se sert de cette syntaxe et malheureusement c'est codé en dur....]

    Quoi ? Doit-on comprendre que l'applicatif en question tourne sur un serveur en mode user et pas comme un service ? Si tel est le cas, ce n'est pas admissible. Et je pourrais expliquer en long, en large et en travers  pourquoi cela ne doit jamais être ainsi, si besoin est.

    J'espère que cela te sera utile

    Cordialement

    Olivier

    mardi 16 février 2021 14:32
  • Bonjour Olivier,

    Merci pout la réponse rapide.

    Le souci est identique que j'essaye depuis le serveur en direct (via Vsphere) ou via RDP.

    Je vais vérifier tout de meme la GPO comme tu le suggères.

    Je te tiens au courant.

    Pour info le logiciel en question est teès très très vieux.

    Par contre je veux bien ton explication si tu as le temps (pour ma comprehension générale).

    Merci


    mardi 16 février 2021 14:59
  • Une 'tite histoire ?

    Chouette j'adore ça, raconter des histoires ;-)

    Il y a ... fort longtemps, un des mes clients avait fait le choix d'une app spécifique (pilotage de caméra IP, mais peu importe). Il a demandé au constructeur/éditeur de faire l'installation du soft. De mon côté, j'ai été mandaté part le client, pour fournir le serveur d'hébergement, de veiller à ce que l'installation se fasse dans les règles de l'art, et que les livrables soient effectivement fournis comme prévu au contrat.

    Installation du soft par l'intervenant : un setup classique qui avait été fait avec un compte disposant de privilèges Admin (en l'ocurence le compte admin local). Ensuite, il créé - attention le chiffre - 7 raccourcis sur le bureau (des .bat) et m'explique gentiment qu'il faut les lancer un par un pour que tous les modules de l'app. fonctionnent ... et dans un ordre particulier s'il vous plait. Le gus avait même pris obligeance de les nommer 1, 2, 3, ... Il m'explique également que je ne dois en aucun cas fermer la session car cela kill l'appli. Et les docs ? Un vulgaris doc générique (doc commercial), pas de doc d'architecture, pas de doc d'install, pas de doc de configuration, ... Son Bon à payer qui n'attendait que ma signature et bien, ... il l'a attendu (avec copie et accord client bien entendu).

    Pause de l'histoire.

    Un serveur fourni des services. Services qui peuvent être assurés par des app, mais ces app. doivent s'exécuter en tant que service et pas en "mode user" (comme n'importe quelle app qu'un utilisateur lance sur un poste de travail). Pourquoi ? Simple, tu fermes la session, l'app est liée à ta session et l'appli est kill.

    Prenons un serveur : reboot planifié ou non (update, coupure électrique, ...) bref la vie d'un serveur. Il redémarre, mais pas l'appli. Il faut ouvrir une session, lancer l'app, puis verrouiller la session. Ingérable sur le long terme. Il arrivera forcément, un jour ou l'autre, ou un admin ne fera pas ces gestes, pour une raison ou une autre, aussi valable les unes que les autres. Ca porte un nom ça d'ailleurs : La (trop) fameuse Loi de Murphy, appelé également Loi de l'emmerdement maximum.

    Maintenant, prenons la même app qui tourne comme un service, en mode auto bien entendu. Même cause (reboot), mais pas les mêmes conséquences. L'app reprend toute seule. Certes, il y a eu une interruption de service, mais il y a reprise. Pas dans le premier cas.

    Reprise de l'histoire (chouette :-) )

    Dans mon compte rendu, j'ai demandé à ce que l'app soit repackagée afin qu'elle s'installe et tourne comme un service. Il m'était certes possible de le faire moi-même, mais quand on paie pour une prestation, on a certaines attentes et exigences, qui généralement sont dans le contrat de service. 3 semaines plus tard, ... toujours à cette lointaine époque, le mec revenait pour réinstaller l'app, avec un setup  revu et corrigé. Et les dev' avaient fait bien les choses : 1 seule service qui lançait les 7 modules nécessaires à l'app. Le dit service, configuré en mode auto by design. Et les livrables demandés. Ils avaient été entièrement été préparés à l'avance (docs génériques), mais ont été customisés sur place au fur et à mesure pour correspondre à ce que réellement déployé. Plus aucune opposition, signature du Bon à Payer. Prestataire content et Client content également avec remerciements en plus. Ma satisfaction ? Le retour du  prestataire - qui avait compris le besoin (bizarre que personne n'ai demandé cela avant) avec mes explications - et qui me dit qu'il a du faire le forcing en interne dans sa boite pour que les dev' revoient leur copie et qui ajoute "d'ailleurs, ça a tellement été apprécié en haut lieu, que cela devient la norme pour tous nos autres produits logiciels, et ils sont tous planifiés pour fonctionner dans ce mode sous peu". Et oui, quand une boite qui fait du hardware se met au software et n'a aucune démarche process et qualité produit (respect des Best-Practices, sécurité by-design, ...) pour le développement logiciel, on arrive à ce type d'aberration.

    En résumé : Sur un poste, les app tournent - du moins pour la plupart - en "mode user" et se lancent par l'utilisateur. Sur un serveur, les app tournent en tant que service et démarrent automatiquement.

    et comment on fait pour encapsuler une app pour tourner comme un service ?

    Un exemple, mais ce n'est pas le seul moyen de faire, il y en a de nombreux autres, dont certains sont plus ou moins élégants et "secure".

    https://www.howtogeek.com/50786/using-srvstart-to-run-any-application-as-a-windows-service/

    Alors elle te plait mon histoire, Thomas ?

    Cordialement

    Olivier

    mardi 16 février 2021 20:07