Cette semaine, j’ai été confronté à un incident plutôt particulier suite à un upgrade d’une appliance vCenter (6.5 vers 6.7 u3f – build 15976714). En effet, après l’upgrade, j’étais incapable de me reconnecter en utilisant mon login ActiveDirectory, pas plus qu’en utilisant un autre compte lié à ce même ActiveDirectory. Cependant, la connexion avec l’utilisateur local fonctionne bien.
Les vérifications de base ne donnent rien de particulier :
- L’appliance existe bien dans l’ActiveDirectory en tant qu’objet Computer (je n’utilise pas de compte pour faire la connexion)
- Les entrées DNS directes et reverse sont bien correctes
La sortie et réintégration à l’ActiveDirectory de l’appliance n’ont rien donné non plus, cependant il y a du mieux : tous les comptes renseignés en dur dans les autorisations globales peuvent ouvrir une session sur le vCenter. Cependant les comptes qui sont membres des groupes étant dans les autorisations ne fonctionnent toujours pas. De plus, l’appel aux webservices SOAP est toujours impossible par un compte sur l’ActiveDirectory (Veeam utilise ces webservices pour interagir avec le vCenter afin de sauvegarder les VM).
Étant donné le caractère plutôt urgent de la résolution de cet incident puisqu’il impacte les sauvegardes, nous avons contacté le support VMware qui nous a confirmé que ce dysfonctionnement pouvait arriver de manière aléatoire lors d’un upgrade de VCSA vers ce dernier build (6.7 update 3f) et que ce bug sera corrigé lors d’une prochaine release.
Malgré tout, le support ne nous a pas permis de trouver la cause du dysfonctionnement ; en faisant jouer nos réseaux, nous avons été mis sur la piste du fichier /etc/resolve.conf, que j’aurais dû vérifier en me connectant en SSH sur l’appliance (si je peux avoir une excuse, il était plus de 22h quand je me suis penché sur le sujet en urgence !).
Pour ce faire, ouvrir une session SSH sur le VCSA, puis saisir shell dans le prompt afin d’accéder au prompt standard de PhotonOS qui est le système d’exploitation socle de vCenter (basé sur GNU/Linux), puis saisir la commande suivante :
more /etc/resolve.conf
Cette instruction doit imprimer le contenu du fichier qui doit à minima contenir l’IP loopback et les DNS renseignés, ainsi que les zones DNS dans lesquelles chercher les enregistrements. Et c’est précisément ici que ça coinçait puisque notre zone ActiveDirectory n’était pas renseignée dans le paramètre search, alors qu’elle l’était sur l’ancienne appliance.
Une fois la zone ActiveDirectory renseignée et un redémarrage complet de l’appliance plus tard, la connexion avec des comptes LDAP était fonctionnelle et les sauvegardes opérationnelles.