« la Connexion Bureau à Distance ne peut pas vérifier l’identité » depuis un Mac/OSX vers Windows 2008+

Fri, 05 Jun 2015 13:36:49 +0000

On ne peut pas dire que je sois un grand partisan d’Apple, mais il arrive parfois que des VIPs souhaitent se connecter sur les serveurs Windows en bureau à distance (RDP). Et quand on n’y connait rien car on n’en utilise pas, c’est parfois un peu déroutant.

Ici, le mac refusait de se connecter au serveur Windows 2008, qui autorisait pourtant les connexions RDP. En fait, le souci se situait au niveau de l’acceptation du certificat délivré par le serveur 2008r2 (qui venait d’être migré depuis un 2003, qui ne dispose pas de cette sécurité).

Symptôme

Le message d’erreur suivant apparait suite à l’authentification sur la mire d’un serveur Windows 2008 ou plus sur un Mac. Le serveur répond bien au ping (puisqu’on a la mire). On s’est assuré que le mot de passe entré est correct.

Résolution

Comme je l’ai dis en introduction, il s’agit ici d’un défaut du client RDP sur OSX qui gère mal les authentifications avancées de Windows 7 et 2008R2 et plus. Pour résoudre ce problème, il y a plusieurs manipulations à effectuer.

Suppression des entrées dans le trousseau

La première chose à faire est d’abord de supprimer toutes les entrées correspondantes aux connexions RDP dans le trousseau de compte Mac

Ouvrir le finder
Aller dans Applications
Aller dans le dossier Utilitaires
Ouvrir trousseaux d’accès
Supprimer les lignes avec « remote desktop connection »

ATTENTION : faire un clic droit sur la ligne pour supprimer et ne pas utiliser le menu dans le haut. Sinon il y a risque de supprimer tous les enregistrements.

Lors de la prochaine connexion, ne pas cocher d’ajouter les informations au trousseau.

Modification du .rdp

Si le problème persiste, il est probable que les informations de connexion soient contenues dans le RDP. Lorsque l’authentification échoue, ouvrir les préférences du fichier RDP en cliquant sur CBD en haut à gauche, puis sur Préférences

Dans l’onglet Session, vider la case Domaine et décocher les cases

Dans l’onglet Sécurité, cocher la case Toujours se connecter

Quitter les préférences et enregistrer quand le Mac le demande pour mettre à jour le .rdp

Echec déploiement package OVF: Cette tâche a été annulée par un utilisateur

Mon, 30 Mar 2015 21:18:12 +0000

[Edit]MAJ le 19/10 avec quelques captures d’écran[/Edit]

Une manière simple de créer et de déployer des templates sous ESXi lorsqu’on ne dispose pas du vCenter et de la licence qui va bien est d’utiliser les templates OVF/OVA (cf un de mes tous premiers articles). Je l’utilise d’ailleurs toujours aujourd’hui pour pallier le manque de licences sur certains sites distants/secondaires.

Cependant, depuis la version 5 (ou peut être 5.1), j’ai été confronté à plusieurs reprises à l’erreur suivante lors du déploiement de l’OVA :

Echec déploiement package OVF: Cette tâche a été annulée par un utilisateur

WTF ? Pas de code d’erreur, et un message pas vraiment loquasse…

J’ai eu beaucoup de mal à trouver la réponse à cette erreur en Français et il a d’ailleurs fallu que je le traduise mot pour mot en anglais pour trouver des ressources pour m’aider :

Failed to deploy OVF package: The task was canceled by a user.

[Edit] En 5.5, j’ai également rencontré le message suivant qui donne un peu plus d’informations sur le problème réel :

OVF Deployment Failed: File ds:///vmfs/volumes/uuid/_deviceImage-0.iso was not found

[/Edit]

Et là on commence à trouver un peu d’aide sur le web. Parmi les liens intéressants sur le sujet, on peut citer le KB de VMware et lukebarklimore qui rentre un peu dans le détail de l’anatomie d’un OVF/OVA de chez VMware :

KB VMware (lien mort, comme d’habitude)
lukebarklimore.wordpress.com/2012/10/25/esxi-5-1-fixing-failed-to-deploy-ovf-package-the-task-was-canceled-by-a-user/

Ce qu’il faut en retenir, c’est :

un OVA n’est en fait qu’une simple archive tar (qu’on peut donc ouvrir avec un « tar xf » ou un 7zip pour les Windowsiens
Il contient un fichier .ovf au format XML qui respecte la norme des OVF (enfin, si on peut appeler ça une norme ! troll) et qui est en fait un descripteur du matériel virtuel de votre VM
un ou plusieurs fichiers .vmdk, vos disques durs virtuels
un fichier .mf qui ne contient en fait que le hash sha1 du fichier, pour le contrôle de la cohérence

Pour en venir au problème en lui même : il se produit lorsque les VMware Tools sont mal démontés ou se sont mal installés (ou mal terminé d’installer). La machine virtuelle garde en mémoire la présence de l’ISO et celui ci reste inscrit dans le descripteur OVF. Lorsqu’on déploie la VM, l’ISO n’est plus présent sur le serveur de destination et on obtient l’erreur susnommée.

Pour résoudre le problème, il faut donc :

Extraire le fichier OVF de l’archive OVA
Editer le fichier OVF, et remplacer la mention vmware.cdrom.iso par la valeur vmware.cdrom.atapi ou vmware.cdrom.remotepassthrough
Recalculer le nouveau hash SHA1 du fichier OVF édité
Recréer une archive et y ajouter DANS CET ORDRE les fichiers .ovf PUIS .mf et .vmdk.

tar xf maVM.ova #extraction des fichiers de l'archive
rm maVM.ova
vi maVM.ovf #si vous êtes sages je vous donnerai un "sed" pour éviter d'avoir à éditer le fichier
sha1sum maVM.ovf #récupérer le retour et remplacer le hash de l'OVF par la nouvelle valeur dans le fichier maVM.mf
tar cf maVM.ova maVM.ovf #recréation de l'archive
tar uf maVM.ova *.mf *.vmdk

Si vous omettez de recalculer le checksum, VMware vous expliquera bien gentiment que le checksum n’est pas bon, et donc l’archive toute entière, donc pas de flemme !

Et si vous ne les mettez pas dans cet ordre, vous aurez une autre erreur, très explicite cette fois ci qui vous expliquera que votre OVA est invalide car les fichiers ne sont pas dans le bon ordre… Oui… Vraiment.

Échec on Zwindler's Reflection

« la Connexion Bureau à Distance ne peut pas vérifier l’identité » depuis un Mac/OSX vers Windows 2008+

Symptôme

Résolution

Suppression des entrées dans le trousseau

Modification du .rdp

Echec déploiement package OVF: Cette tâche a été annulée par un utilisateur