Les plus attentifs d’entre vous aurons noté que j’ai récemment fait un billet sur l’utilisation de l’outil certificate-manager en ligne de commande. Mais il s’avère que mon CSR n’avait pas le niveau de sécurité requis et je n’ai pas trouvé l’option pour modifier la taille de la clé.

il y a bien le fichier certool.cfg pour modifier la configuration mais rien ne semble documenter la longueur de la clé. J’aurai simplement pu générer ma demande avec openssl, mais j’avais la ferme intention d’utiliser les produits mis à disposition par VMware.

Je suis donc partie sur l’utilisation de la GUI pour réaliser l’opération car le changement de la taille de la clé y est accessible:

La génération du csr se passe très bien, mais les soucis apparaissent à l’importation:

En effet, l’assistant nous demande de lui fournir la clé privée générée lors de notre demande de csr, sauf qu’à aucun moment, il ne nous indique le chemin en question. Impossible de trouver le chemin dans la documentation officielle VMware.

C’est en parcourant d’autres blogs à la recherche du chemin que je suis tombé sur l’article de Bryan van Eeden : Where is my private key when using the vSphere UI? – vCloud Vision

Il y décrit, avec la même surprise que moi, la demande de la clé privée mal documenté, et indique la commande pour récupérer le précieux :

/usr/lib/vmware-vmafd/bin/vecs-cli entry getkey --store MACHINE_SSL_CERT --alias __MACHINE_CSR

Copier les informations avec —–BEGIN CERTIFICATE REQUEST—– et —–END CERTIFICATE REQUEST—– dans un fichier et vous pourrez l’utiliser pour l’importation, ou copier les directement dans le menu VMware dans la section Private Key :

Pour la section « Chain of trusted root certificates » copier les informations du certificat de l’autorité de certification ou de la chaine complète qui a signé la demande.

Après redémarrage des services, le certificat devrait correctement en place.

Après une installation des plus classiques, j’avais besoin de personnaliser les certificats d’un nouveau vCenter.

Après avoir lancé certificate-manager la procédure s’arrêtait sur le message : Certificate Manager tool do not support vCenter HA systems

Je n’utilise pas vCenter HA donc j’étais très surpris du message, mais après une rapide recherche un post sur le forum VMware m’a apporté la solution -> Cert Manager Tool Not Working / VCSA Web UI Not Ac… – VMware Technology Network VMTN

Je n’ai eu qu’a créer le répertoire manquant avec mkdir /var/tmp/vmware et l’opération se poursuit sans erreur.

Suite à la migration de nos vCenters 6.5.x vers 6.7.x, la topologie supportée et recommandée par VMware consiste à intégrer le Platform Services Controller (PSC) au vCenter Server Appliance (VCSA), même en Enhanced Linked mode (ELM). Autant dire que j’étais content de diviser par deux les infras. Voici, un peu en vrac, les petits soucis que j’ai rencontrés pour ces opérations.

Lire la suite de

Je suis finalement parti sur le modèle hybride, afin de sécuriser les composants web accessibles, sans pour autant avoir à certifier tous les hôtes ESXi. Ce qui aurait généré une énorme charge de travail sans réellement augmenter le niveau de sécurité, car ils sont tous dans un réseau isolé. Quant à l’autre mode, il était tout simplement inenvisageable d’un point de vue sécurité que le composant VMware Certificate Authority (VMCA) soit autorité de certification intermédiaire de l’organisation.

Si comme moi, vous rencontrez un petit problème pendant l’opération voilà ce qui pourrait vous dépanner.

Lire la suite de

Depuis la migration de l’infrastructure VMware en 6.5, nous avions un comportement différent de la 5.5 avec un prompt des credentials utilisateurs en powercli, malgré l’utilisation d’un compte disposant des droits et n’ayant aucun souci pour se connecter au WebClient.

Le premier message d’erreur est un classique : « Could not determine user name and/or password for server ». Puis, avec un argument verbose on obtient : « Connect using SSPI was unsuccessful ».

Plusieurs cas similaires sont référencés sur le forum VMware mais aucune des solutions proposées ne réglaient notre cas. La meilleure solution consistait en un workaround décrit par LucD. Need assistance with creating and then using stored credentials.

Par contre, le post d’aaronwsmith sur le sujet logon sessions in powercli for vsphere appliance 6.5 m’a bien aiguillé.

Dans une configuration avec PSC Externe, même l’appliance VCSA doit être jointe au domaine et comme il l’indique, l’option n’est pas forcement disponible depuis le WebClient.

Pour ma part, les comptes ordinateurs étaient bien présent dans notre AD, mais en exécutant la commande « /opt/likewise/bin/domainjoin-cli query »  le retour ne faisait pas apparaitre le chemin complet avec l’OU qui était censée héberger le compte machine.

Impossible de joindre la machine au domaine. Le compte ordinateur est encore présent dans l’AD et, j’obtiens une erreur LW_ERROR_LDAP_INSUFFICIENT_ACCESS (code 0x00009d8b]

Impossible également de supprimer le compte ordinateur avec la commande « /opt/likewise/bin/domainjoin-cli leave« , malgré le succès de l’opération.

Il faut donc supprimer directement le compte ordinateur depuis l’AD, attendre quelques instants que la réplication se propage, puis exécuter la ligne de commande pour l’ajouter.

/opt/likewise/bin/domainjoin-cli join domain.com Domain_Administrator Password

Voici la syntaxe que j’utilise pour ajouter directement dans la bonne OU :

/opt/likewise/bin/domainjoin-cli join –ou « CHEMIN/OU » « domain.com » « CompteAutorisé@domain.com » « Password‘ »

Si tout se passe bien, vous devriez avoir un succès, et le compte ordinateur devrait être visible dans l’OU de destination.

Sur nos infrastructures, il faut bien attendre 30 secondes pour que la commande fonctionne.

Ci-dessous le « avant/ après ». L’authentification est de nouveau transparente.