RemoteExec depuis une VM Windows sur une Debian Buster : connexions refusées

Bonjour Debian.
Je suis obligé de travailler sur un parc essentiellement Windows, où l’équipe utilise AutoIt pour les scripts et RemoteExec pour les déployer.
J’ai passé mon poste de travail sous Debian Buster, et installé une VM Windows 10 avec KVM pour pouvoir gérer les outils microsoft.

Là je tente de déployer un script autoit qui marche, et j’obtiens systématiquement 80070005:Accès refusé.
Ce sur des machines et pour un script sur lequel le collègue (qui a sa machine sous Windows) n’a pas de souci avec son propre RemoteExec.

D’où peut venir le souci ?

Edit : mon collègue a le même problème s’il essaye de lancer RemoteExec depuis une machine virtuelle sur sa machine Windows.

Bon, rien à voir avec Debian en fait, c’était une configuration oubliée sur RemoteExec (ajouter un compte).

Mais bon si quelqu’un a des alternatives de déploiement de scripts autoIT à partir de logiciel libre, je suis preneur quand même.

A mon taff on utilise Puppet et Ansible conjointement, mais l’un comme l’autre peuvent faire le taff.

1 J'aime

Pour de l’autoIT donc ?
Vu que je dois convaincre mon chef (qui est partiellement réceptif, ce n’est pas tâche impossible) et qu’il ne voudra pas deux outils, tu recommanderais lequel ?

Je ne connais pas du tout Puppet et pour Ansible j’aime beaucoup le principe (j’avais lu un bouquin pour débutants dessus) mais pas eu l’occasion de pratiquer. De plus Ansible passe par SSH et le chef ne veut pas ouvrir le port SSH a priori.

Personnellement je préfère une solution comme Ansible qui ne demande pas d’agent particulier sur les machines mais c’est pas moi qui décide…

Alors là … si tu as du Windows dans le parc machine à gérer, Ansible peux le faire du moment qu’il n’y a pas de vieux coucou.

Concernant l’ouverture du port SSH, des restrictions d’accès sont faciles à mettre en place.
L’utilisation d’un bastion est un gros plus pour gérer les accès de façon sécuriser et auditable à des machines GNU/Linux :wink:

Par contre l’utilisation d’agent (avec puppet rends plus facile la mise en place sur un parc hétérogène, reste à pouvoir gérer le serveur puppet et te faire la main avec les manifests et les hieradata (ce qui peux être une plaie lorsque l’on maîtrise pas :confused: ).

Par contre l’un comme l’autre te permettent d’oublier l’autoit et de gérer via des playbooks ou des manifests.

Cerise sur le gateau, ça permet de maintenir les configurations des machines couplé à un git pour versionner les confs.
Mais là on rentre dans l’automatisation et il y a du taff.

1 J'aime