Après avoir effectué la mise à niveau vers VMware Identity Manager 3.2.0.1, vous devrez peut-être configurer certains paramètres.

Programme d'amélioration du produit

Ce produit participe au CEIP, le programme d'amélioration du produit de VMware. Les détails concernant les données recueillies via le CEIP et les fins auxquelles elles sont utilisées par VMware sont définis dans le Centre d'approbation et d'assurance à l'adresse https://www.vmware.com/fr/solutions/trustvmware/ceip.html.

Dès lors que vous avez effectué la mise à niveau vers VMware Identity Manager 3.2.0.1 et que vous vous êtes connecté à la console d'administration, l'option Rejoindre le Programme d'amélioration du produit VMware s'affiche sur la bannière. Si vous ne souhaitez pas participer au Programme d'amélioration de ce produit VMware, décochez la case et cliquez sur OK.



Option CEIP sur la bannière


La bannière est conservée jusqu'à ce que vous cliquiez sur OK ou que vous fermiez la bannière. Vous pouvez rejoindre ou quitter le CEIP à tout moment depuis la page Paramètres du dispositif > Télémétrie.

Migration d'Elasticsearch

Remarque :

Ces informations s'appliquent à la mise à niveau vers la version 3.2.x à partir de versions précédentes. Elles ne s'appliquent pas à la mise à niveau de la version 3.2 vers la version 3.2.0.1.

Elasticsearch, un moteur de recherche et d'analyse, est intégré à VMware Identity Manager pour l'audit, la génération de rapports et la recherche. VMware Identity Manager 3.2.x inclut Elasticsearch 2.3.5, alors que les versions précédentes incluaient Elasticsearch 1.75. Les enregistrements d'Elasticsearch sont migrés lors de la mise à niveau vers VMware Identity Manager 3.2.x.

Une fois la mise à niveau de VMware Identity Manager terminée, une tâche en arrière-plan commence à migrer les enregistrements d'audit et de recherche existants, qui sont gérés par Elasticsearch, vers le nouveau format. Le démarrage de ce processus peut être retardé d'une heure au maximum après la fin de la mise à niveau. Après le démarrage, la tâche est en général rapide, mais peut prendre entre 1 et 2 heures, selon le nombre d'enregistrements.

Vous pouvez afficher le fichier analytics-service.log, qui se trouve dans le répertoire /opt/vmware/horizon/workspace/logs, pour voir les messages sur la progression de la migration.

  • Lorsque la migration démarre, le message La dernière version du schéma d'audit est la version 4. est journalisé.

  • Comme la migration des données a lieu chaque jour, les messages commençant par Réindexation des documents depuis sont journalisés.

  • Lorsque la migration est terminée, le message Vérification du schéma d'audit terminée. est journalisé.

Avant la fin de la migration, aucun enregistrement n'est disponible ou seulement quelques anciens. Ainsi, le tableau de bord et le rapport d'audit n'indiquent pas les enregistrements plus anciens et la recherche et la saisie semi-automatique ne fonctionnent pas. Toutefois, de nouveaux enregistrements d'audit sont générés et traités, indépendamment de la migration. Par conséquent, le tableau de bord et le rapport d'audit doivent afficher les nouvelles connexions, etc. Si les nouveaux enregistrements d'audit n'apparaissent pas dans le rapport d'audit, vérifiez l'intégrité du cluster Elasticsearch.

Pour vérifier l'intégrité du cluster Elasticsearch :

  1. ssh dans n'importe quel nœud et exécutez la commande suivante :

    curl http://localhost:9200/_cluster/health?pretty

    Si le champ "status" est "yellow" ou "green", recherchez les erreurs dans le journal analytics-service. Si le champ "status" est "red", vous devez redémarrer le nœud maître.

  2. Pour redémarrer le nœud maître :

    1. Déterminez le nœud maître en exécutant la commande suivante :

      curl http://localhost:9200/_cluster/state/master_node,nodes?pretty

    2. Recherchez la valeur du champ "master_node", puis recherchez la valeur correspondante dans la liste des nœuds afin de déterminer son adresse IP. Par exemple, dans cet exemple de sortie, le nœud maître est "Gq-ITVBKRJKz1816XqrRKw", dont l'adresse IP est "1.1.1.2" :

      {
         "cluster_name" : "horizon",
         "master_node" : "Gq-ITVBKRJKz1816XqrRKw",
         "nodes" : {
            "mzWHVMZuTXyFsO61NLpHnA" : {
               "name" : “Node1”,
               "transport_address" : “1.1.1.1:9300",
               "attributes" : { }
         },
         "Gq-ITVBKRJKz1816XqrRKw" : {
               "name" : “Node2”,
               "transport_address" : “1.1.1.2:9300",
               "attributes" : { }
         },
         "pkREX2D9R1a-lqf69PQMKQ" : {
               "name" : “Node3”,
               "transport_address" : “1.1.1.3:9300",
               "attributes" : { }
         }
      }
    3. ssh dans le nœud maître Elasticsearch et redémarrez Elasticsearch :

      service elasticsearch restart

    4. Une fois qu'Elasticsearch a redémarré, vérifiez de nouveau l'intégrité du cluster :

      curl http://localhost:9200/_cluster/health?pretty

      La commande peut afficher l'état "yellow" au début. Exécutez de nouveau la commande jusqu'à ce qu'affiche l'état “green”.

Conflits de mappage Elasticsearch

Elasticsearch 2.3.5 dans VMware Identity Manager 3.2.x ne démarre pas s'il existe des conflits de mappage dans les index. Si vous n'avez pas supprimé les index qui présentaient des conflits de mappage avant la mise à niveau, en suivant la procédure décrite dans Recherche des conflits de mappage Elasticsearch, Elasticsearch ne démarre pas.

Le fichier journal d'Elasticsearch, /opt/vmware/elasticsearch/logs/horizon.log, inclut un message pour les index affectés, comme illustré ci-dessous :

[2018-04-24 13:13:41,722][ERROR][bootstrap                ] Guice Exception: java.lang.IllegalStateException: unable to upgrade the mappings for the index [v3_2018-03-16], reason: [Mapper for [tenantId] conflicts with existing mapping in other types:

Pour résoudre ce problème, supprimez manuellement les index de tous les nœuds VMware Identity Manager.

  1. Sur tous les nœuds, assurez-vous qu'Elasticsearch est arrêté :

    service elasticsearch stop

  2. Sur tous les nœuds, supprimez les fichiers d'index du disque :

    rm -rf /db/elasticsearch/horizon/nodes/0/indices/<INDEX_NAME>

  3. Sur tous les nœuds, redémarrez Elasticsearch :

    service elasticsearch start

La recherche ne fonctionne pas après la mise à niveau

Si, après la mise à niveau, les rapports d'audit et les tableaux de bord fonctionnent, mais que la recherche ne fonctionne pas, l'index de recherche n'est peut-être pas correct.

Pendant la mise à niveau, l'ensemble des utilisateurs, groupes et applications sont réindexés dans le nouvel index de recherche. En cas de problèmes avec Elasticsearch, comme des conflits de mappage, la réindexation peut ne pas se dérouler correctement.

Pour résoudre le problème, forcez manuellement la réindexation avec l'option Aucune coupure de service en utilisant la valeur du cookie HZN, ou avec l'option Aucune coupure de service en modifiant la valeur directement dans la base de données.

Pour forcer manuellement une réindexation à l'aide de l'option Aucune coupure de service :

  1. Connectez-vous au service VMware Identity Manager en tant qu'administrateur locataire, c'est-à-dire, l'administrateur par défaut qui a été créé dans le domaine système lorsque vous avez installé VMware Identity Manager pour la première fois.

  2. Obtenez la valeur du cookie HZN à partir du cache des cookies de votre navigateur.

    Par exemple, sous Firefox :

    1. Accédez à Options > Confidentialité et sécurité.

    2. Sous Historique, cliquez sur le lien de suppression des cookies individuels.

    3. Dans la boîte de dialogue Cookies, recherchez HZN.

    4. Sélectionnez le cookie HZN dans les résultats de la recherche, puis copiez sa valeur dans le champ Contenu.

  3. ssh dans n'importe quel nœud VMware Identity Manager, puis effectuez l'appel REST suivant, en remplaçant <cookie_value> par la valeur du cookie HZN obtenue à partir du navigateur.

    /usr/local/horizon/bin/curl -k -XPUT -H "Authorization:HZN <cookie_value>" -H "Content-Type: application/vnd.vmware.horizon.manager.systemconfigparameter+json" https://localhost/SAAS/jersey/manager/api/system/config/SearchCalculatorMode -d '{ "name": "SearchCalculatorMode", "values": { "values": ["REINDEX"] } }'

Pour forcer manuellement une réindexation à l'aide de l'option Aucune coupure de service :

  1. Arrêtez le service VMware Identity sur tous les nœuds :

    service horizon-workspace stop

  2. Exécutez la commande suivante sur un des nœuds :

    hznAdminTool reindexSearchData

  3. Redémarrez le service VMware Identity Manager sur tous les nœuds :

    service horizon-workspace start

Pour vérifier que la réindexation a démarré, recherchez dans le fichier /opt/vmware/horizon/workspace/logs/horizon.log un message tel que celui-ci :

com.vmware.horizon.search.SearchCalculatorLogic - Keep existing index. Search calculator mode is: REINDEX

La réindexation devrait se terminer quelques minutes.

Fichiers de configuration Log4j

Si des fichiers de configuration Log4j dans une instance de VMware Identity Manager ont été modifiés, les nouvelles versions de ces fichiers ne sont pas installées automatiquement lors de la mise à niveau. Par conséquent, après la mise à niveau, les journaux contrôlés par ces fichiers ne fonctionnent pas.

Pour résoudre ce problème :

  1. Connectez-vous au dispositif virtuel.

  2. Recherchez les fichiers log4j dotés du suffixe .rpmnew.

    find / -name "**log4j.properties.rpmnew"

  3. Pour chaque fichier trouvé, copiez le nouveau fichier dans l'ancien fichier log4j correspondant sans le suffixe .rpmnew.

Paramètre du service de cache sur les dispositifs du centre de données secondaire

Si vous avez configuré un centre de données secondaire, ses instances de VMware Identity Manager sont configurées pour l'accès en lecture seule avec l'entrée "read.only.service = true" du fichier /usr/local/horizon/conf/runtime-config.properties. Une fois que vous avez mis à niveau un tel dispositif, le service ne parvient pas à démarrer.

Pour résoudre ce problème :

  1. Connectez-vous au dispositif virtuel.

  2. Ajoutez la ligne suivante dans le fichier /usr/local/horizon/conf/runtime-config.properties :

    cache.service.type = ehcache

  3. Redémarrez le service.

    service horizon-workspace restart

Contrôle d'accès basé sur des rôles

Le contrôle d'accès basé sur des rôles a été introduit dans VMware Identity Manager 3.2. Pour voir les problèmes connus, consultez les Notes de mise à jour de VMware Identity Manager 3.2.

Intégration de Citrix

Pour l'intégration de Citrix dans VMware Identity Manager 3.2, tous les connecteurs externes doivent être à la version 2018.1.1.0 (version du connecteur dans la version 3.2) ou ultérieures.

Vous devez également effectuer une mise à niveau vers Integration Broker 3.2 ou version ultérieure.

Modifications dans les versions antérieures

Modifications de la version 3.1

  • À partir de la version 3.1, une nouvelle fonctionnalité a été introduite qui a changé la manière dont les groupes d'utilisateurs sont synchronisés. Après avoir effectué à la mise à niveau vers VMware Identity Manager 3.1 ou version ultérieure, assurez-vous que des droits sont attribués pour tous les groupes d'utilisateurs déjà ajoutés avant la mise à niveau. Les nouveaux groupes d'utilisateurs ajoutés après la mise à niveau ne sont pas synchronisés avec le service VMware Identity Manager tant que le groupe n'est pas autorisé à accéder à une ressource, ajouté à une règle de stratégie d'accès ou, à partir de la version 3.2, synchronisé manuellement sur la page Groupe > Utilisateurs du groupe.

    Si vos droits sont définis sur TOUS LES UTILISATEURS, les utilisateurs des nouveaux groupes créés après la mise à niveau ne seront pas inclus si les utilisateurs n'ont pas encore été synchronisés. Ajoutez des droits pour les nouveaux groupes.

    Pour plus d'informations, consultez Comment la synchronisation de groupe fonctionne après la mise à niveau vers VMware Identity Manager 3.1.

  • Si vous intégrez des ressources publiées Citrix à VMware Identity Manager 3.1, procédez à la mise à niveau vers Integration Broker 3.1. VMware Identity Manager 3.1 et VMware Identity Manager Connector 2017.12.1.0 (version du connecteur dans la version 3.1) nécessitent Integration Broker 3.1.

Modifications de la version 3.0

  • Si vous intégrez des ressources publiées Citrix à VMware Identity Manager, effectuez la mise à niveau vers Integration Broker 3.0 . VMware Identity Manager 3.0 et VMware Identity Manager Connector 2017.8.1.0 (la version de connecteur dans la version 3.0) ne sont pas compatibles avec les anciennes versions d'Integration Broker.

    Tableau 1. Versions prises en charge

    Version VMware Identity Manager ou Connector

    Version d'Integration Broker prise en charge

    VMware Identity Manager 3.0

    3.0

    VMware Identity Manager Connector 2017.8.1.0 (version de Connector dans VMware Identity Manager 3.0)

    3.0

    VMware Identity Manager 2.9.1 ou version antérieure

    2.9.1 ou version antérieure

    VMware Identity Manager Connector 2.9.1 ou version antérieure

    2.9.1 ou version antérieure

  • Si vous intégrez des postes de travail et des applications Horizon dans VMware Identity Manager et que vous avez déployé un cluster VMware Identity Manager, vous devez configurer de nouveau l'intégration d'Horizon.

    • Dans le connecteur principal, où vous avez enregistré et synchronisé des ressources Horizon, supprimez tous les espaces Horizon, ajoutez-les de nouveau et cliquez sur Enregistrer et synchroniser.

    • Dans les autres connecteurs, où vous avez enregistré la configuration des ressources Horizon, supprimez tous les espaces Horizon, ajoutez-les de nouveau et cliquez sur Enregistrer.

Modifications dans les versions antérieures à la version 3.0

  • Modifications de la synchronisation en bloc dans VMware Identity Manager 2.9.1 et versions ultérieures

    Dans les versions antérieures, la synchronisation en bloc a été traitée avec 4 threads par CPU via un paramètre de configuration globale dans la base de données nommée bulkSyncThreadLimitPerCPU=4.

    À partir de la version 2.9.1, le nombre de threads de traitement de la synchronisation en bloc n'est pas basé sur le CPU. C'est un nombre absolu, qui est le même que le nombre de CPU sur un nœud par défaut.

    Si vous synchronisez un grand nombre d’utilisateurs et de groupes et que vous remarquez que la synchronisation est lente après la mise à niveau, vous pouvez préciser le nombre de threads en définissant le paramètre de configuration globale appelé bulkSyncSharedThreadCount.

    Définir la valeur de thread dans la base de données à l’aide de l’API REST suivante, puis redémarrez les nœuds pour que la modification prenne effet.

    Demande HTTP :

    Operation: PUT
    URI: bulkSyncSharedThreadCount

    En-têtes HTTP :

    Content-Type: application/vnd.vmware.horizon.manager.systemconfigparameter+json
    Accept: application/vnd.vmware.horizon.manager.systemconfigparameter+json
    Authorization: HZN <operator token>

    Corps de la demande (avec 8 threads, par exemple) :

    {
        "name": "bulkSyncSharedThreadCount",
        "values": {
            "values": [
                "8"
            ]
        }
    }

  • Activez la nouvelle interface utilisateur du portail.

    1. Dans la console d'administration, cliquez sur la flèche dans l'onglet Catalogue et sélectionnez Paramètres.

    2. Sélectionnez Nouvelle interface utilisateur du portail de l'utilisateur final dans le volet de gauche et cliquez sur Activer la nouvelle interface utilisateur du portail.

  • Si vous avez configuré un cluster VMware Identity Managerpour un basculement avec deux nœuds, il est recommandé de mettre ce dernier à jour vers trois nœuds. Cela est dû à une limite d'Elasticsearch, un moteur de recherche et d'analyse intégré au dispositif VMware Identity Manager. Vous pouvez continuer à utiliser deux nœuds, mais vous devez connaître quelques-unes des limites liées à Elasticsearch. Pour plus d'informations, consultez « Configuration du basculement et de la redondance » dans Installation et configuration de VMware Identity Manager.

  • Le protocole Transport Layer Security 1.0 (TLS) est désactivé par défaut dans VMware Identity Manager. TLS 1.1 et 1.2 sont pris en charge.

    Les problèmes avec les produits externes lorsque TLS 1.0 est désactivé sont connus. Il est recommandé d'effectuer la mise à jour de vos autres configurations de produit pour utiliser TLS 1.1 ou 1.2. Toutefois, si ces produits ont une dépendance à TLS 1.0, vous pouvez activer TLS 1.0 dans VMware Identity Manager en suivant les instructions dans l'article 2144805 de la base de connaissances.