18.3 Dépannage des problèmes liés à l'installation et à la désinstallation

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 dossier bin de Tomcat. Par exemple, C:\NetIQ\idm\apps\tomcat\bin\setenv.bat. 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 à l'emplacement C:\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.x, vous ne parvenez pas à vous connecter au tableau de bord d'Identity Applications. Ce problème se produit lorsque le chemin du fichier Truststore du coffre-fort d'identité n'est pas mis à jour à l'emplacement approprié du fichier keystore (cacerts) lors de la mise à niveau d'Identity Applications. L'exception suivante est consignée dans le fichier catalina.out : com.netiq.idm.auth.oauth.AuthenticationCommunicationException: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path validation failed: sun.security.validator.ValidatorException: TrustAnchor with subject "CN=*, OU=idm, O=, L=, ST=, C=" is not a CA certificate" (com.netiq.idm.auth.oauth.AuthenticationCommunicationException: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: échec de validation du chemin PKIX : sun.security.validator.ValidatorException: TrustAnchor with subject "CN=, OU=idm, O=, L=, ST=, C=*" n'est pas un certificat approuvé par une autorité de certification"). Identity Applications utilise la variable d'environnement JAVA_HOME définie sur <chemin_installation >\Common\JRE. Lorsque le chemin du fichier Truststore n'est pas défini sur le fichier cacerts dans JAVA_HOME, la communication SSL échoue, ce qui entraîne une erreur SSL associée à « TrustAnchor » (l'ancre d'approbation sert de vérification de sécurité Java renforcée pour les certificats SSL).	Pour résoudre ce problème, procédez comme suit : Arrêtez le service Tomcat. Connectez-vous au serveur Identity Applications et lancez l'utilitaire configupdate situé à l'emplacement suivant : <chemin_installation>\idm\apps\configupdate Sous l'onglet Application utilisateur, accédez à Certificats du coffre-fort d'identité et assurez-vous que le chemin du fichier Truststore est défini sur <chemin_installation>\Common\JRE\lib\security\cacerts. Démarrez le service 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 également 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 C:\NetIQ\idm\apps\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, procédez comme suit : Appuyez sur Windows + R sur le clavier, saisissez services.msc et sélectionnez OK pour ouvrir l'interface Services Windows. Recherchez les noms de service NetIQ Nginx Service et NetIQ IGA Form Renderer Service. Cliquez avec le bouton droit sur le service et sélectionnez l'option Redémarrer. Identity Applications utilise le service NGNIX pour afficher les formulaires dans le tableau de bord d'Identity Applications.
Après la mise à niveau d'Identity Applications ou d'Identity Reporting vers la version 4.8, plusieurs entrées de PostgreSQL sont affichées dans le panneau de configuration.	Désinstallez les versions précédentes de PostgreSQL à partir du panneau de configuration.
Un message indique que la procédure de désinstallation est incomplète, mais le fichier journal n'indique aucun échec.	La procédure n'a pas pu supprimer le répertoire netiq qui contient les fichiers d'installation par défaut. Vous pouvez supprimer ce répertoire si vous avez supprimé tous les logiciels NetIQ de votre ordinateur.
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é.
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 C:\NetIQ\Common\JRE\bin\ et importez le certificat dans le fichier idm.jks à l'aide de la commande suivante : <chemin_installation>\NetIQ\Common\JRE\bin\keytool -import -trustcacerts -alias <nom_alias_certificat> -keystore <idm.jks> -file <fichier_certificat_téléchargé> Relancez Tomcat.
Après la mise à niveau d'Identity Manager 4.7.4 vers la version 4.8, le service Tomcat ne se lance pas et aucune erreur n'est signalée dans les fichiers journaux. Ce problème se produit lorsque la minuterie de pulsation n'est pas mise à jour correctement dans la table afenginestate de la base de données igaworkflow.	Pour résoudre ce problème, connectez-vous à un outil d'administration de base de données tel que pgAdmin. Exécutez la requête suivante pour mettre à jour manuellement la minuterie de pulsation dans la table afenginestate de la base de données igaworkflow. update afenginestate set heartbeat=now()::timestamp;