20.6 Dépannage des problèmes de mise à niveau

Le tableau suivant répertorie les problèmes susceptibles de se poser et les actions suggérées pour les résoudre. Si le problème persiste, contactez votre représentant NetIQ.

Problème	Actions suggérées
Vous ne parvenez pas à vous connecter à Identity Applications après avoir exécuté l'utilitaire ConfigUpdate. Le message d'erreur suivant s'affiche dans le fichier journal catalina.out : 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). Ce problème a été constaté dans Identity Manager 4.8.4 (avec eDirectory 9.2.5) lorsque le paramètre Restrictions de liaison pour Cipher est défini sur Utilisez un Cipher SuiteB (128 bits) sur le serveur LDAP. Identity Manager utilise des certificats numériques pour autoriser et communiquer en toute sécurité avec ses composants. Les certificats sont validés en vérifiant les listes de révocation de certificats (CRL) spécifiées par le champ 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'Identity Manager, la connexion au tableau de bord 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.8.5 et versions ultérieures. Connectez-vous au serveur sur lequel Identity Applications est mis à niveau vers la version 4.8.5. 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.8 à 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.8. 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 Identity Manager vers la version de 4.8.1 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.8.1 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 Identity Manager vers la version 4.8 é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é.	Procédez comme suit : 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'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'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 à iManager. Accédez à Rôles et tâches > Accès aux certificats NetIQ > 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 Suivant > 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.