VSphere on Zwindler's Reflection

Sécurité des mots de passes ESXi 5.X et 6.X

Mon, 06 Apr 2020 06:50:00 +0000

Pourquoi tu nous parles d’ESXi 5 ?

En voilà une bonne question ! Comme la majorité des blogueurs tech, j’ai dans mes brouillons une bonne 30aines d’articles en attente depuis plus ou moins longtemps (demandez à Seboss666 ce qu’il en pense).

Ca fait presque deux ans que je n’ai pas touché à un serveur VMware et pourtant, cette doc était pratiquement “prête à poster”. Tout comme “Intégrer un RHEL 7 dans un Active Directory avec Ansible” et “Mise en place de DRBD 8.4 sous CentOS 6.3”, mais c’est une autre histoire…

Et comme je n’aime pas gâcher, je “profite” du confinement pour déconfiner des vieilles docs avant qu’elles ne soient plus définitivement plus d’actualité (trop tard, vSphere 7 vient de sortir).

Les mots de passe dans vSphere

Un truc que je n’ai pas trouvé très très clair et qu’il est possible dans VMware d’avoir des comptes utilisateurs internes à l’ESXi avec des mots de passe plutôt bof complexes. En effet, il est tout à fait possible d’avoir un mot de passe avec que des lettres minuscules (voire même des chiffres ??) ce qui -nous sommes d’accord- est absolument catastrophique.

Lorsqu’on sait qu’on a parfois besoin de se loguer sur la console à distance et que l’émulation des terminaux KVM des constructeurs est une bouse intergalactique qui vous transforme votre AZERTY en un gloubiboulga à mis chemin entre le QWERTY et DVORAK, c’est parfois tentant…

Bref, j’ai voulu comprendre la logique de VMware pour l’acceptation de la longueur des mots de passe.

En fait, tout est expliqué, en fonction des versions, dans ce KB (lien mort, comme tout chez VMware).

Password quality-control PAM module

Je ne savais pas, mais VMware utilise tout simplement le module PAM Password quality-control PAM. Il permet de réaliser des contrôles simples sur la qualité des mots de passe choisi pour les utilisateurs Linux.

Globalement, on dispose, via ce module, de différents flags pour valider une politique simple de gestion de mot de passe sur un système Linux (car oui, ESXi c’est un Linux).

Les arguments retenus par VMware sont uniquement basés sur une taille minimale de mots de passe en fonction du nombre de type de caractères différents dont dispose ce mot de passe. Voilà à quoi ça ressemble :

password requisite /lib/security/$ISA/pam_passwdqc.so retry=N min=N0,N1,N2,N3,N4

Par défaut, voici ce que vous allez trouver dans vSphere 6 :

retry=3 : Un utilisateur a droit à trois tentatives pour entrer un mot de passe suffisant.
N0=12 : Le mot de passe comportant des caractères d’une seule classe doit contenir au moins 12 caractères.
N1=9 : Le mot de passe comportant des caractères de deux classes doit contenir au moins neuf caractères, mais qui n’est pas éligibles aux conditions des passphrases.
N2=8 : Le mot de passe respecte les conditions des passphrases. Il comporte des caractères de deux classes et doit contenir au moins huit caractères.
N3=7 : Le mot de passe comportant des caractères de trois classes doit contenir au moins sept caractères.
N4=6 : Le mot de passe comportant des caractères des quatre classes doit contenir au moins six caractères.

Procédure pour modifier la politique de sécurité

Si pour une raison ou pour une autre, vous souhaitez modifier ces paramètres (pour les durcir, hein !), voici la marche à suivre :

Connectez-vous au Shell ESXi et obtenez les privilèges root.
Ouvrez le fichier passwd avec un éditeur de texte.

vi /etc/pam.d/passwd

Modifiez la ligne suivante :

password requisite /lib/security/$ISA/pam_passwdqc.so retry=3 min=disabled,20,20,15,10

Cette commande vous permettra de désactiver la possibilité d’ajouter des utilisateurs dans ESXi dont les mots de passe n’ont qu’une classe de caractères et de complexifier fortement les autres types de mots de passe.

Il existe de nombreux autres paramètres. Je vous invite à aller lire la page man de ce module pour améliorer encore la sécurité des mots de passe dans vos ESXi.

Bonus GUI pour ESXi 6.0

Si vous êtes allergique à la console jaune et noire d’ESXi (ou que vous n’avez pas la main sur un KVM), sachez que depuis ESXi 6.0, il est possible de modifier directement les valeurs du module PAM depuis la console vSphere. Ça se passe dans les options avancées de l’hôte (cf cet article de Vladan).

Password Complexity Rules – change here where In previous versions of ESXi, password complexity changes had to be made by hand-editing the /etc/pam.d/passwd file on each ESXi host. In vSphere 6.0 now this can be done by adding an entry in Host Advanced System Settings, enabling centrally managed setting changes for all hosts in a cluster.

Ouah, cébo !

Sources

VMware KB 1012033 (lien mort, comme tout chez VMware)
Doc vSphere 5, en français (lien mort, comme tout chez VMware)
Page man de pam_passwdqc
Vladan : ESXi 6.0 Security and Password Complexity Changes

vSphere Web Client : VMware Lookup Service SSL certificate verification Failed

Tue, 08 Aug 2017 11:30:25 +0000

Qui a entendu du VMware Lookup Service ?

[Aparté]M4vr0x ayant pas mal monopolisé le temps de parole sur Proxmox VE, je retourne un peu sur VMware histoire de changer un peu, mais rassurez vous, d’autres articles sur le clustering vont suivre ;-).[/Aparté]

Un matin d’astreinte comme les autres. On me réveille aux aurores car un serveur Business Object est encore dans les choux. Le serveur Windows qui l’héberge (je ne vous donnerai pas la version, vous allez vous moquer) est encore en carafe, encore pour une raison obscure (pas de pb de RAM, pas de charge CPU, pas de pic d’IO… normal ?).

C’est une vieille infra client, sur laquelle je n’ai plus trop mon mot à dire : elle n’est plus sous ma responsabilité directe, en dehors de l’astreinte. Mais j’ai quand même encore les accès en console VMware pour me connecter et regarder ce qui ne va pas.

Dans le doute, reboot. Si ça rate, reformate.

Un des hymnes de l’IT au bureau. Roy et Moss approuveraient.

Depuis quelques temps, j’ai des soucis avec mon client lourd vSphere. La console ne s’affiche pas en entier, du coup je ne vois que le quart supérieur gauche de l’écran, ce qui est relativement handicapant.

![](/2017/08/vsphere.avif

Ok je fais comment là ?

De toute façon comme il est déprécié et censé disparaitre depuis des années (la 5.5 je crois ?), je n’ai pas pris la peine de chercher pourquoi et n’utilise plus que le client Web, malgré sa lenteur épique sur les plus vieilles versions.

Manque de chance, un message d’erreur m’attend au login !

Failed to connect to VMware Lookup Service. SSL certificate verification failed

L’erreur a le mérite d’être assez clair. Quelque part, il y a un service qui se charge de vérifier un certificat et ce certificat est mauvais ! Heureusement on trouve pas mal de ressources en anglais sur le sujet, notamment chez Yellow bricks (pour la 5.1, lui).

« Lorsque vous modifiez le nom d’hôte de vCenter Server Appliance, une erreur Lookup Service apparaît lorsque vous redémarrez le dispositif. »

OK. Qui est le saucisson qui a modifié le hostname mais ne s’est pas logué après pour vérifier que ça fonctionnait ?

C’est donc tout simplement un certificat qui n’est plus valide car le nom d’hôte a changé.

On peut facilement corriger le problème en se connecter sur l’application d’administration de la VCSA. Vous l’avez utilisée lors de l’installation de l’appliance, via l’URL https://@IP_ou_FQDN_vcenter:5480.

Il faut se connecter avec le compte root de l’appliance, choisi au moment de l’installation.

Naviguez jusqu’à trouver l’onglet Admin. A partir de là, sur la 5.5, il y a un bouton radio qui permet de régénérer automatiquement les certificats si nécessaire. Passez le à « oui ». Idéalement il faudra penser à l’enlever une fois le problème réglé, pour d’évidentes raisons de sécurité.

La documentation officielle indique que redémarrer les services ne suffisent pas. Il est donc réellement nécessaire de rebooter complètement l’appliance car la régénération des certificats se fait au reboot.

Ne cliquez pas sur « Reset », ça efface tous le champs. J’en aurai une bonne à vous raconter à ce sujet d’ailleurs ;-).

Après le reboot, l’erreur sur le vsphere web client sur https://@IP_ou_FQDN_vcenter:9443 devrait avoir disparue !

Unable to connect to server

Tout est bien qui fini bien ? Non ! Si vous essayez comme moi de retourner sur le serveur de configuration du vCenter (pour prendre des captures d’écran et faire un article de wiki ou de blog par exemple), vous ne pourrez plus vous connecter. Après le login vous aurez le message suivant qui apparaitra en rouge :

Unable to connect to server

En réalité, c’est simplement un problème de cache de votre navigateur web. Il faut vider votre cache navigateur et accepter le nouveau certificat qui vient d’être régénéré.

Source

www.yellow-bricks.com/2012/12/19/failed-to-connect-to-vmware-lookup-service-ssl-certificate-verification-failed/
pubs.vmware.com/vsphere-51/index.jsp?topic=%2Fcom.vmware.vsphere.troubleshooting.doc%2FGUID-D9ACB836-2BB4-4DDC-9383-91EF6E546A30.html (lien mort comme absolument tout chez VMware)

Configurer l’ILO depuis ESXi (et sans reboot !)

Thu, 15 Jun 2017 12:00:02 +0000

Un KVM sur IP pour les contrôler tous

Une des fonctionnalités vitales pour l’administrateur de serveurs (physiques) est la capacité de pouvoir réaliser des modifications sur un serveur comme si on était physiquement devant la machine, vissé devant le kit clavier-souri-écran. Non, ce n’est pas (que) de la flemme. On ne peut pas toujours aller en salle serveur dès qu’un serveur a besoin d’une maintenance !

Ça c’est ce qu’on voit dans les séries TV, des techies qui tirent des KVM intégrés dans les racks pour intervenir. Ça arrive parfois, mais en vrai, mais 95% du temps on ne va pas jusqu’au datacenter, on utilise l’ILO ;-)

Ces technologies sont particulièrement utiles lorsque les systèmes d’exploitation sont crashés et que la seule solution pour reprendre la main sur le serveur est de le rebooter en appuyant virtuellement sur le bouton Power.

Dans les technos du marché, on peut citer ILO (pour Integrated Lights-Out) chez HP, iDRAC chez Dell-EMC, mais il existe bien d’autres solutions plus ou moins avancées.
Pour la route je citerai les technos que j’ai envisagé pour mon serveur perso, à savoir BMC sur certaines cartes mère Asrock, le protocole IPMI, ou alors la solution d’Intel AMT disponible sur les i5 et plus pour peu que vous ayez la bonne carte mère compatible « vPRO ».

Aparté : vous avez peut être entendu parler d’AMT récemment à cause de plusieurs failles qui ont rendu nombre de systèmes vulnérables (ici et plus récemment ici).

ILO : un 2ème OS en parallèle

Alors évidemment pour que ça marche, ça nécessite nécessairement que l’ILO (ou équivalent) fonctionne en parallèle de l’OS principal du serveur. C’est ce qui différencie l’ILO et l’iDRAC de Remote Desktop Protocol de Micro$oft ou VNC, qui ne vous servent plus à rien en cas de plantage ou d’extinction du serveur.

Mais qui dit système parallèle dit potentiellement que l’un ne puisse pas communiquer avec l’autre ! Pour revenir à mon exemple de l’ILO d’un serveur ESXi, généralement la première configuration (adresse IP, etc) se fait en interrompant la séquence de boot du serveur. En théorie, si on voulait faire une modification a posteriori de la même manière, il serait donc nécessaire de rebooter le serveur ESXi et donc de couper toutes les VMs qui sont hébergées dessus.

Heureusement, pour éviter de devoir faire ça, HP a mis à disposition des outils ! Et en plus, ces binaires sont directement intégrés dans la version modifiée de l’ISO ESXi d’HP.

Pour ceux qui ne savent pas de quoi je parle, il s’agit d’images dites « custom HP » et qui contiennent notamment des outils HP dédiés à l’administration et à l’intégration dans l’écosystème HP, mais surtout les pilotes compatibles avec le matériel HP. Cette version custom est donc celle qui est conseillée si vous avez un serveur HP, même si elle n’est pas exempte de bugs parfois !!! Vous pouvez les retrouver en recherchant dans Google « ESXi HP custom » ou sur le site d’HPe.

C’est d’ailleurs ces modifications qui permettent de remonter des informations sur l’état de santé du serveur physique dans les données de vSphere.

Piloter l’ILO depuis l’OS de l’ESXi

Rentrons dans le vif du sujet. Ça dépend des versions de vSphere (5.5, 6.0, 6.5), mais en version 6.0, sur les images ESXi custom HP, les binaires spécifiques sont déposés dans le dossier /opt/hp/tools. Le binaire qui nous intéresse est hponcfg.

~ # cd /opt/hp/tools
/opt/hp/tools # ls
conrep hpbootcfg hponcfg hptestevent_esxcli
conrep.xml hpbootcfg_esxcli hptestevent

Pour modifier la configuration, le plus simple est d’exporter la configuration actuelle, de la modifier, puis de la réimporter. On peut l’exporter avec la commande suivante :

/opt/hp/tools # ./hponcfg -w /tmp/current_ilo.cfg
HP Lights-Out Online Configuration utility
Version 4.4-0 (c) Hewlett-Packard Company, 2014
Firmware Revision = 1.81 Device type = iLO 2 Driver name = hpilo
iLO IP Address: x.x.x.x
Management Processor configuration is successfully written to file "/tmp/current_ilo.cfg"

Et si vous regardez le contenu de ce fichier, vous aurez un retour similaire :

/opt/hp/tools # cat /tmp/current_ilo.cfg
<!-- HPONCFG VERSION = "4.4-0.0" -->
<!-- Generated 5/9/2017 9:56:44 -->
<RIBCL VERSION="2.1">
<LOGIN USER_LOGIN="Administrator" PASSWORD="XXXXXXXX">
[...]
<RIB_INFO MODE="write">
<MOD_NETWORK_SETTINGS>
<SPEED_AUTOSELECT VALUE = "Y"/>
<NIC_SPEED VALUE = "10"/>
<FULL_DUPLEX VALUE = "N"/>
<IP_ADDRESS VALUE = "x.x.x.x"/>
<SUBNET_MASK VALUE = "255.255.255.0"/>
<GATEWAY_IP_ADDRESS VALUE = "x.x.x.y"/>
<DNS_NAME VALUE = "ILO-XXXX"/>
[...]

Il ne vous reste plus qu’à modifier ces valeurs pour refléter vos nouveaux besoins et de l’appliquer avec la commande suivante :

./hponcfg -f /tmp/current_ilo.cfg

Source

Le tutoriel sur VMwarearena (EN)

Créer un modèle/template VM Windows XP sous ESXi sans vCenter

Sun, 20 Mar 2011 21:58:23 +0000

VMare a beau prétendre proposer un hyperviseur gratuit, la plupart des fonctions vitales d’un hyperviseur y sont absentes si on ne dispose pas d’une licence, contrairement aux concurrents (libres ou non). Sans prôner le libre à tout prix (je veux bien comprendre qu’il faut vivre de son produit, et ajouter des fonctionnalités selon les licences n’est pas une stratégie marketing dénuée de sens), il est quand même vraiment dommage de proposer un produit gratuit sans donner la possibilité de l’utiliser dans un environnement réel. Ça donne un peu le gout amer de shareware…

Parmi ces fonctions vitales qui n’ont aucunes raisons d’être payantes selon moi, j’ai nommé :

La possibilité de disposer d’un moyen de copier facilement des machines virtuelles pour déployer en peu de temps un SI virtualisé. Rien de plus horrible que de devoir se taper une demi heure de réponses débiles dans l’écran d’installation d’un OS. N’importe quel admin système a désespérément besoin de cette fonctionnalité, aussi petit soit le SI en question, et sans laquelle la virtualisation perd une bonne partie de son avantage en terme de gain de temps par rapport à une architecture physique…

Mais heureusement, il y a une petite astuce assez simple pour s’en affranchir.

Ne cherchez pas dans votre vSphere, la fonctionnalité pour copier des VMs n’apparaitra pas si vous ne disposez pas d’un vCenter. Cependant, en fouillant bien, on retrouve des fonctionnalités utilisant une notion un peu similaire, qui est la notion de template…

vSphere propose de créer et d’importer des virtuals appliances. Pour faire simple, ce sont des machines virtuelles « prêtes à fontionner », généralement diffusées sur Internet dans le but de fournir des produits logiciels un peu complexe sans installation (OS de supervision prêt à l’emploi, VM faisant office de pare feu, …).

En détournant cette fonctionnalité à notre avantage, il est donc possible de créer des templates (littéralement « modèle » ou « gabarit ») qui représentent des copies complètes de machines virtuelles à un instant donné. A partir de ce template, il sera donc possible de recréer autant de machines virtuelles identiques que l’on souhaite. CQFD

Voici donc un petit tuto dans la lignée du précédent (rien de techniquement agressif et probablement beaucoup trop détaillé) pour créer un template de VM Windows XP en prenant garde de modifier les paramètres qui doivent rester uniques. En effet, deux machines virtuelles créées à partir d’un template ne peuvent pas fonctionner sur un même réseau, pour les raisons suivantes :

Si la carte réseau virtuelle était configurée avec une adresse IP, elles auront la même adresse IP
Si elles hébergent un système d’exploitation Windows :
- Elles auront le même identifiant supposé unique (SID)
- Elles auront le même nom complet sur le réseau

Comme les données du disque dur sont enregistrées dans le template, il est conseillé de créer des templates avec le moins de données possible sur le disque dur, autant pour des raisons d’économie de l’espace disque que pour gagner en temps de création/déploiement.

Ainsi, il deviendra possible de recréer en quelques minutes des machines virtuelles minimalistes préconfigurées pour une tâche. Attention à ne pas tomber dans l’excès non plus : il est tout de même malin d’installer toutes les mises à jour et tous les logiciels susceptibles d’être installé sur tous les postes, le but de la création de template étant de gagner du temps!

Pour faciliter le déploiement de VM sous Windows, il est conseillé d’ajouter l’utilitaire NewSID.exe qui sera bine utile pour modifier les identifiants uniques de la machine avant de l’introduire sur le réseau.

Créer un template à partir du client vSphere

Choisir une machine à exporter en template, et l’éteindre
Sélectionner la machine virtuelle choisie
Cliquer sur File/Export/Export OVF Template
Entrer un nom et un répertoire de destination pour le template [Next]
Choisir le format d’enregistrement (OVF ou OVA) [Finish]

Ces deux formats sont tous les deux des valeurs possibles. OVF (Open Virtualization Format) est plus standard que OVA, il sera donc plus simple d’importer des fichiers OVF sur un autre système de virtualisation. Cependant, OVA offre la possibilité de tout stocker dans un seul fichier, contrairement à OVF qui génèrera plusieurs fichiers (configuration et disque dur).

Exporter un template à partir du client vSphere

Cliquer sur File/Deploy OVF Template
Choisir un template sur le disque ou depuis une url [Next]
L’assistant affiche une description du template [Next]
Entrez un nom pour la nouvelle machine virtuelle (qui n’existe pas déjà sur le serveur de virtualisation!) [Next]
Choisir dans quel pool la machine virtuelle doit être affectée [Next]
Choisir un Datastore dans lequel la machine virtuelle et sa configuration seront stockées [Next]
[Finish]

Une fois ces opérations terminées, la machine virtuelle est prête à être démarrée par le serveur ESXi. Cependant, il reste quelques opérations à effectuer :

Si la machine est sous Windows :
- Il faut changer le SID de la machine car cet SID est supposé unique. Or, toutes les machines déployées avec ce template auront le même SID : il faut donc en générer un nouveau. Ceci peut être fait à l’aide du programme NewSID.exe (voir la section « utilisation de NewSID.exe »). La modification de ce paramètre ne peut prendre effet qu’après redémarrage de la machine.
- Il faut donner un nouveau nom complet à la machine, car ce nom est supposé unique sur le réseau, et des noms identiques pourraient provoquer des conflits. L’utilitaire NewSID.exe permet de changer ce nom complet, après avoir généré un nouvel SID. Une autre manière de le faire est de d’effectuer l’opération suivante : Panneau de configuration/Système/Nom de l’ordinateur/Modifier et entrer un nom unique sur le réseau. La modification de se paramètre ne peut prendre effet qu’après redémarrage de la machine.
Attribuer à l’interface réseau virtuelle une adresse IP unique en fonction du plan d’adressage du réseau, un masque de réseau adéquat et l’adresse IP du serveur DNS.
Intégrer la machine nouvellement configurée au domaine. Pour se faire, il faut effectuer l’opération suivante : Panneau de configuration/Système/Nom de l’ordinateur/Modifier, sélectionner Membre de Domaine, et entrez le nom du domaine à intégrer.

Utilisation de NewSID.exe

Pour pouvoir modifier le SID et le nom complet de la machine, il faut suivre les étapes suivantes :

Exécuter NewSID.exe [Next]
L’utilitaire affiche le SID actuel, et propose d’en générer un nouveau [Next]
[Next]
L’utilitaire propose de renommer la machine, entrer un nouveau nom complet [Next]
[Next]

Normalement, après ces étapes, le SID sera modifié dans le registre, le nom complet sera modifié, et la machine redémarrera d’elle-même à la fin de la procédure.