34.4 Résolution des problèmes liés à la mise à niveau

Le tableau suivant répertorie les problèmes que vous risquez de rencontrer et les actions suggérées pour les résoudre. Si le problème persiste, contactez votre représentant OpenText.

Problème	Actions suggérées
Après la mise à niveau d'OpenText Identity Manager vers la version 24.4 (4.10), iManager ne fonctionne plus s'il est installé avec d'autres composants. Lorsque vous essayez de lancer une version précédemment installée, iManager affiche une page vierge.	installez et utilisez OpenText Identity Console à la place d'iManager. Toutefois, si vous souhaitez continuer à utiliser iManager après la mise à niveau d'OpenText Identity Manager vers la version 24.4 (4.10), assurez-vous que les conditions suivantes sont remplies : iManager est installé sur un serveur autonome. Le serveur dispose d'une version de Java prise en charge. Par exemple : iManager 3.2.6.0200 sur Java JDK 1.0.8 Update 342 dans Identity Manager 4.8.6 Effectuez les étapes suivantes pour réutiliser les anciens fichiers Java : Créez un répertoire à l'aide de la commande suivante : mkdir -p /opt/novell/iManager/java_iman Copiez les fichiers Java existants d'iManager dans le nouveau répertoire : cp -r /opt/netiq/common/jre/ /opt/novell/iManager/java_iman Pour modifier la propriété du nouveau répertoire, exécutez la commande suivante: chown -R novlwww:novlwww /opt/novell/iManager/java_iman Accédez à /etc/opt/novell/tomcat9/ et mettez à jour JAVA_HOME et JRE_HOME avec le nouveau chemin d'accès Java dans le fichier tomcat9.conf. Redémarrez Tomcat à l'aide de la commande suivante : rcnovell-tomcat9 restart
lors de la mise à niveau du composant Identity Applications, si vous choisissez l'option write to file (écrire dans un fichier) pour créer un schéma de base de données, le programme d'installation crée des fichiers databasechema.sql et wfedatabaseschema.sql vides. Étant donné que ces fichiers sont vides, vous ne pouvez pas les utiliser pour créer un schéma de base de données une fois la mise à niveau terminée.	Téléchargez le fichier .jar de base de données approprié pour votre base de données Identity Applications à partir d'un site Web tiers. Installez-le sur un système distinct ou un serveur avec Identity Applications. Lorsque le programme d'installation vous invite à entrer le chemin d'accès au fichier JAR JDBC de la base de données d'Identity Applications et du moteur de workflow lors de la mise à jour d'Identity Applications, spécifiez l'emplacement du fichier .jar de la base de données installée.
Lors de la mise à niveau d'OpenText Identity Manager vers la version 24.4 (4.10) sur un serveur exécutant RHEL 8.x ou RHEL 9.x (où x est la version prise en charge dans 4.10), OSP ne démarre pas en raison d'un problème de connexion à la base de données. Cela se produit généralement lorsque le processus de génération de clé aléatoire prend plus de temps que prévu pendant le déploiement d'OSP. Par conséquent, les services Tomcat ne démarrent pas non plus.	modifiez les lignes suivantes dans le fichier java.security à l'emplacement /opt/netiq/common/jre/conf/security et redémarrez Tomcat : REMARQUE :avant d'appliquer la solution de contournement, reportez-vous à la documentation RHEL pour plus d'informations sur les générateurs de nombres aléatoires. Remplacez securerandom.source=file:/dev/random par securerandom.source=file:/dev/./urandom Remplacez securerandom.strongAlgorithms=NativePRNGBlocking:SUN par securerandom.strongAlgorithms=SHA1PRNG:SUN
Lors de la mise à niveau du moteur OpenText Identity Manager sous Open Enterprise Server (OES) 24.2, l'erreur suivante est signalée dans idmupgrade.log : [SEVERE]: Could not connect to the server Exception: Connect ErrorLDAPException: I/O Exception on host <IP_address>, port <port_number> Connect Error java.net.SocketException: Connection or outbound has closed	Ignorez cette erreur. Elle ne provoque aucune perte de fonctionnalité.
OpenText Identity Manager autorise et communique en toute sécurité avec ses composants à l'aide de certificats numériques. Les certificats du coffre-fort d'identité doivent être importés dans les fichiers keystore idm.jks et tomcat.ks. Toutefois, lorsque vous tentez d'accéder à Identity Applications après l'importation des certificats, vous risquez de rencontrer l'erreur suivante : javax.net.ssl.SSLHandshakeException: PKIX path validation failed: java.security.cert.CertPathValidatorException: Could not determine revocation status. (javax.net.ssl.SSLHandshakeException: PKIX path validation failed: java.security.cert.CertPathValidatorException: impossible de déterminer l'état de révocation). Les certificats sont validés en vérifiant les listes de révocation de certificats (CRL) spécifiées par le champ CRL Distribution Point (Point de distribution CRL, CDP) qui détermine si le certificat a été révoqué ou non. Les points de distribution CRL sont disponibles dans le certificat racine ainsi que dans les certificats intermédiaires présents dans les fichiers keystore tomcat.ks et idm.jks. La vérification de la révocation des certificats est toutefois désactivée par défaut. Le gestionnaire d'approbation PKIX ne peut donc pas déterminer l'état de révocation des certificats.	Pour résoudre ce problème, activez la vérification du point de distribution CRL en définissant la propriété -Dcom.sun.security.enableCRLDP sur true. Pour définir la propriété, effectuez les opérations suivantes : Arrêtez Tomcat. Accédez au fichier setenv.sh situé dans le répertoire bin de Tomcat. Par exemple, /opt/netiq/idm/apps/tomcat/bin/setenv.sh. Ajoutez la propriété -Dcom.sun.security.enableCRLDP = true à CATALINA_OPTS comme suit : export CATALINA_OPTS="-Dcom.sun.security.enableCRLDP=true" Démarrez Tomcat.
Après la mise à niveau d'OpenText Identity Manager, la connexion au tableau de bord OpenText Identity Manager est extrêmement lente pour les utilisateurs non-administrateurs. Le chargement des pages Applications et Tableau de bord est très long. Ce problème se produit en raison de la recherche de groupes imbriqués qui est activée par défaut. L'application recherche les autorisations héritées par l'utilisateur connecté via l'adhésion à un groupe imbriqué, peu importe que des groupes imbriqués soient présents dans l'environnement ou non.	(Conditionnel) Les étapes suivantes s'appliquent à Identity Manager 4.9 : Connectez-vous au serveur sur lequel Identity Applications est mis à niveau vers la version 4.9. Accédez au répertoire /opt/netiq/idm/apps/tomcat/conf/. Ouvrez le fichier ism-configuration.properties dans un éditeur de texte. À la fin du fichier, ajoutez la propriété suivante : DirectoryService/realms/jndi/params/USE_NESTED_GROUPS=false Enregistrez le fichier et redémarrez Tomcat.
Après la mise à niveau d'Identity Applications vers la version 4.10 à partir d'une version antérieure, le moteur de rendu de formulaire ne fonctionne pas comme prévu. Ce problème a été constaté lorsque le contexte de déploiement IDMProv par défaut est modifié en contexte personnalisé.	Pour éviter ce problème, procédez comme suit : Connectez-vous au serveur sur lequel Identity Applications est mis à niveau vers la version 4.9. Accédez au répertoire /opt/netiq/idm/apps/sites. Modifiez le fichier ServiceRegistry.json. Remplacez le contexte de déploiement IDMProv par le contexte personnalisé spécifié avant la mise à niveau. Enregistrez le fichier ServiceRegistry.json. Accédez au répertoire /opt/netiq/idm/apps/sites/forms/. Modifiez le fichier main.<version>.js, où <version> est la valeur alphanumérique générée de manière aléatoire. Remplacez le contexte de déploiement IDMProv par le contexte personnalisé spécifié avant la mise à niveau. Enregistrez le fichier main.<version>.js. Relancez Tomcat.
Après avoir mis à niveau OpenText Identity Manager vers la version de 4.10 dans un environnement distribué, la connexion à Identity Applications échoue. Le message d'erreur suivant s'affiche : Your login process did not complete successfully. (Votre procédure de connexion ne s'est pas déroulée correctement.) La connexion à Identity Applications exige des certificats approuvés pour établir une connexion sécurisée entre Identity Applications et OSP. Un certificat approuvé doit contenir l'extension des contraintes de base avec le type d'objet défini sur l'autorité de certification (CA). Identity Manager utilise la propriété jdk.security.allowNonCaAnchor pour valider les ancres d'approbation dans le certificat. Par défaut, cette propriété est définie sur false (faux). Ainsi, lorsqu'aucune ancre d'approbation n'est trouvée dans les certificats, la connexion entre Identity Applications et OSP ne peut pas être établie et la connexion échoue. Vous remarquerez l'exception suivante dans le fichier journal idm-osp.log : sun.security.validator.ValidatorException: TrustAnchor with subject "CN=*, L=, O=" is not a CA certificate (sun.security.validator.ValidatorException: TrustAnchor ayant comme objet "CN=, L=, O=*" n'est pas un certificat d'une autorité de certification)	Pour résoudre ce problème, vous devez respecter l'une des conditions suivantes : Assurez-vous que les certificats utilisés pour établir une connexion sécurisée entre Identity Applications et OSP proviennent d'autorités de certification approuvées et que leur extension de contraintes de base est correcte. Dans le cas de certificats auto-signés et personnalisés approuvés par les clients, vous pouvez modifier la propriété jdk.security.allowNonCaAnchor pour autoriser les certificats ne provenant pas d'autorités de certification sans extension des contraintes de base. Effectuez les opérations suivantes pour modifier les paramètres de sécurité Java : Accédez au répertoire /opt/netiq/common/jre/lib/security/java.security. Définissez la valeur de la propriété jdk.security.allowNonCaAnchor=true. Enregistrez le fichier.
Après la mise à niveau vers la version 4.10 d'Identity Applications, vous ne pouvez pas ouvrir de formulaires pendant que vous demandez des autorisations dans le tableau de bord d'Identity Applications.	Pour résoudre ce problème, redémarrez manuellement les services NGNIX et Golang à l'aide des commandes suivantes : NGNIX : /opt/netiq/common/ngnix/ngnix Golang : /etc/init.d/netiq-golang.sh Identity Applications utilise le service NGNIX pour afficher les formulaires dans le tableau de bord d'Identity Applications.
Une fois Identity Reporting mis à niveau vers une version Standard Edition, le paramètre is_prov du fichier configupdate.sh.properties est défini comme true (vrai). Étant donné qu'Identity Applications n'est pas disponible dans une version Standard Edition, la valeur de ce paramètre doit être définie sur false (faux).	Définissez manuellement le paramètre is_prov sur false (faux) dans le fichier configupdate.sh.properties.
Impossible de réexécuter le programme d'installation du moteur Identity Manager si la mise à niveau précédente du moteur Identity Manager échoue. Par exemple, si la mise à niveau du moteur OpenText Identity Manager vers la version 4.9 échoue lors de la première tentative et que vous tentez à nouveau de mettre à niveau le moteur Identity Manager, le processus de mise à niveau ne peut pas être déclenché.	Effectuez la procédure suivante : Mettez à niveau le moteur Identity Manager vers la version précédente à l'aide du RPM novell-DXMLengnx. Mettez à niveau le moteur Identity Manager.
Après la mise à niveau d'Identity Manager, la propriété suivante est ajoutée au fichier ism-configuration.properties. com.netiq.idm.osp.ldap.admin-dn = cn=admin,ou=sa,o=system	Ajoutez la propriété en commentaire dans le fichier ism-configuration.properties, puis redémarrez Tomcat. Elle ne provoque aucune perte de fonctionnalité.
Après la mise à niveau d'OpenText Identity Manager, la propriété SSPR suivante est ajoutée au fichier ism-configuration.properties, même si SSPR n'est pas présent dans votre déploiement : com.netiq.sspr.redirect.url = https://___SSPR_IP___:___SSPR_TOMCAT_HTTPS_PORT___/sspr/public/oauth	Ajoutez la propriété en commentaire dans le fichier ism-configuration.properties, puis redémarrez Tomcat. Elle ne provoque aucune perte de fonctionnalité.
Après la mise à niveau d'OpenText Identity Manager, le fichier ism-configuration.properties duplique certaines valeurs la propriété java.protocol.handler.pkgs.	Aucune perte de fonctionnalité n'est à signaler. Pour résoudre ce problème, procédez comme suit : Accédez au fichier ism-configuration.properties situé dans le répertoire /opt/netiq/idm/apps/tomcat/conf. Modifiez le fichier ism-configuration.properties, puis supprimez les valeurs en double de la propriété java.protocol.handler.pkgs. Enregistrez le fichier et redémarrez Tomcat.
Impossible de démarrer Tomcat après la mise à niveau d'Identity Manager. Vous remarquerez quelques exceptions dans les journaux Tomcat et un échec de communication entre le moteur de workflow et le coffre-fort d'identité.	Connectez-vous à OpenText Identity Console. Accédez à Certificate Management (Gestion des certificats) > Server Certificate Management (Gestion des certificats de serveur). Cochez la case DNS du certificat SSL, puis cliquez sur Exporter. Dans la liste déroulante Certificats, sélectionnez DNS du certificat SSL. Décochez la case Exporter la clé privée. Assurez-vous que le format d'exportation est défini sur DER. Cliquez sur OK > Save the exported certificate (Enregistrer le certificat exporté) pour télécharger le certificat sur votre système. Connectez-vous au serveur Identity Applications. Arrêtez Tomcat. Accédez au répertoire opt/netiq/common/jre/bin et importez le certificat dans le fichier idm.jks à l'aide de la commande suivante : opt/netiq/common/jre/bin/keytool -import -trustcacerts -alias <nom_alias_certificat> -keystore /opt/netiq/idm/apps/tomcat/conf/idm.jks -file <fichier_certificat_téléchargé> Relancez Tomcat.