18.3 Fehlersuche bei der Installation und Deinstallation

Die nachfolgende Tabelle enthält die möglichen Probleme und Vorschläge für Gegenmaßnahmen. Falls das Problem weiterhin auftritt, wenden Sie sich an Ihren zuständigen NetIQ-Ansprechpartner.

Problem	Empfohlene Vorgehensweise
Sie können sich nach der Ausführung des ConfigUpdate-Dienstprogramms nicht mehr bei Identity Applications anmelden. In der Protokolldatei catalina.out wird folgender Fehler angezeigt: javax.net.ssl.SSLHandshakeException: PKIX-Pfadüberprüfung fehlgeschlagen: java.security.cert.CertPathValidatorException: Widerrufstatus konnte nicht ermittelt werden. Dieses Problem tritt in Identity Manager 4.8.4 (mit eDirectory 9.2.5) auf, wenn Bindungseinschränkungen für Cipher auf dem LDAP-Server auf SuiteB Cipher (128-bit) verwenden festgelegt ist. Identity Manager verwendet digitale Zertifikate zur Autorisierung und sicheren Kommunikation mit seinen Komponenten. Beim Validieren der Zertifikate werden die Zertifikatswiderrufslisten (CRLs) überprüft, die durch das Feld CRL-Verteilungspunkt (CDP) angegeben sind. Dadurch wird festgelegt, ob das Zertifikat widerrufen wurde oder nicht. Die CRLDPs sind sowohl im Stammzertifikat als auch in den Zwischenzertifikaten verfügbar, die sich in den Keystore-Dateien tomcat.ks und idm.jks befinden. Die Überprüfung von Zertifikaten auf Widerruf ist jedoch standardmäßig deaktiviert. Infolgedessen ist der PKIX Trust Manager nicht in der Lage, den Widerrufstatus der Zertifikate zu ermitteln.	Zur Behebung dieses Problems aktivieren Sie die Überprüfung der CRL-Verteilungspunkte, indem Sie die Eigenschaft -Dcom.sun.security.enableCRLDP auf true festlegen. Gehen Sie zum Festlegen der Eigenschaft folgendermaßen vor: Halten Sie Tomcat an. Rufen Sie die Datei setenv.sh auf, die sich im bin-Ordner von Tomcat befindet. Beispiel: C:\NetIQ\idm\apps\tomcat\bin\setenv.bat. Fügen Sie in CATALINA_OPTS die Eigenschaft -Dcom.sun.security.enableCRLDP=true hinzu: export CATALINA_OPTS="-Dcom.sun.security.enableCRLDP=true" Starten Sie Tomcat.
Nach dem Aufrüsten von Identity Manager ist die Anmeldung beim Identity Manager-Dashboard für Benutzer, die keine Administratoren sind, extrem langsam. Das Laden der Anwendungen und der Dashboard-Seiten wird erheblich verzögert. Dieses Problem tritt aufgrund der verschachtelten Gruppensuche auf, die standardmäßig aktiviert ist. Die Anwendung sucht nach den Berechtigungen, die der angemeldete Benutzer über die verschachtelte Gruppenzugehörigkeit übernommen hat, unabhängig davon, ob es in der Umgebung verschachtelte Gruppen gibt.	(Bedingt) Die folgenden Schritte gelten für Identity Manager 4.8.5 und höher. Melden Sie sich bei dem Server an, auf dem Identity Applications auf die Version 4.8.5 aufgerüstet wurde. Navigieren Sie zum Speicherort C:\NetIQ\IDM\apps\tomcat\conf. Öffnen Sie die Datei ism-configuration.properties in einem Texteditor. Fügen Sie am Ende der Datei folgende Eigenschaft hinzu: DirectoryService/realms/jndi/params/USE_NESTED_GROUPS=false Speichern Sie die Datei und starten Sie Tomcat neu.
Nachdem Sie Identity Applications auf die Version 4.8.x aufgerüstet haben, können Sie sich nicht mehr beim Identity Applications-Dashboard anmelden. Dieses Problem tritt auf, wenn der Truststore-Pfad des Identitätsdepots während des Aufrüstens von Identity Applications nicht auf den richtigen Speicherort der Keystore-Datei (cacerts) aktualisiert wird. In der Datei catalina.out wird folgende Ausnahme protokolliert: 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=*" ist kein Zertifikat einer Zertifizierungsstelle" Identity Applications verwendet die Umgebungsvariable JAVA_HOME, die auf <install_path>\Common\JRE festgelegt ist. Wenn der Truststore-Pfad in JAVA_HOME nicht auf die Datei cacerts festgelegt ist, schlägt die SSL-Kommunikation fehl. Dies führt zu einem SSL-Fehler in Verbindung mit 'TrustAnchor' (Trust Anchor wird als erweiterte Java-Sicherheitsprüfung für SSL-Zertifikate verwendet).	Gehen Sie wie folgt vor, um dieses Problem zu beheben: Halten Sie den Tomcat-Dienst an. Melden Sie sich am Identity Applications-Server an und starten Sie das Dienstprogramm configupdate, das sich unter <Installationspfad>\idm\apps\configupdate befindet. Gehen Sie auf der Registerkarte Benutzeranwendung zu Identitätsdepot-Zertifikate und vergewissern Sie sich, dass der Truststore-Pfad auf <Installationspfad>\Common\JRE\lib\security\cacerts festgelegt ist. Starten Sie den Tomcat-Dienst.
Nach dem Aufrüsten von Identity Manager auf Version 4.8.1 in einer verteilten Umgebung schlägt die Anmeldung bei Identity Applications fehl. Die folgende Fehlermeldung wird angezeigt: Ihr Anmeldevorgang wurde nicht erfolgreich abgeschlossen. Die Anmeldung bei Identity Applications erfordert Vertrauensanker-Zertifikat für die Herstellung einer sicheren Verbindung zwischen den Identity Applications und dem OSP. Ein Vertrauensanker-Zertifikat muss die Basiseinschränkungserweiterung enthalten, wobei als Subjekttyp „CA“ festgelegt ist. Identity Manager verwendet die Eigenschaft jdk.security.allowNonCaAnchor, um die Vertrauensanker im Zertifikat zu validieren. Standardmäßig ist diese Eigenschaft auf false festgelegt. Wenn die Vertrauensanker in den Zertifikaten nicht gefunden werden, kann daher die Verbindung zwischen Identity Applications und OSP nicht hergestellt werden, und die Anmeldung schlägt fehl. In der Datei idm-osp.log bemerken Sie außerdem die folgende Ausnahme: sun.security.validator.ValidatorException: TrustAnchor with subject "CN=*, L=, O=**" is not a CA certificate	Um dieses Problem zu lösen, müssen Sie eine der folgenden Bedingungen erfüllen: Stellen Sie sicher, dass es sich bei den Zertifikaten, die zum Aufbau einer sicheren Verbindung zwischen den Identity Applications und dem OSP verwendet werden, um verbürgte Zertifizierungsstellenzertifikate mit der entsprechenden Basiseinschränkungserweiterung handelt. Bei selbstsignierten und benutzerdefinierten Zertifikaten, denen die Clients vertrauen, können Sie die Eigenschaft jdk.security.allowNonCaAnchor ändern, um nicht von einer Zertifizierungsstelle stammende Zertifikate ohne die Basiseinschränkungserweiterung zuzulassen. Führen Sie die folgenden Aktionen durch, um die Java-Sicherheitseinstellungen zu ändern: Navigieren Sie zum Verzeichnis C:\NetIQ\idm\apps\jre\lib\security\java.security. Legen Sie folgenden Eigenschaftswert fest: jdk.security.allowNonCaAnchor=true. Speichern Sie die Datei.
Nach dem Aufrüsten von Identity Applications auf Version 4.8.1 können Sie keine Formulare öffnen, während Sie im Identity Applications-Dashboard Berechtigungen anfordern.	Gehen Sie wie folgt vor, um dieses Problem zu beheben: Drücken Sie Windows + R auf Ihrer Tastatur, geben Sie services.msc ein und wählen Sie OK, um die Schnittstelle für Windows-Dienste zu öffnen. Suchen Sie nach den Dienstnamen, NetIQ Nginx-Dienst und NetIQ IGA-Formular-Renderer-Dienst. Klicken Sie mit der rechten Maustaste auf den Dienst und wählen Sie die Option Neu starten aus. In Identity Applications wird der NGNIX-Dienst zum Rendern von Formularen im Identity Applications-Dashboard verwendet.
Nach dem Aufrüsten von Identity Applications oder Identity Reporting auf die Version 4.8 werden mehrere Einträge von PostgreSQL in der Systemsteuerung angezeigt.	Deinstallieren Sie die Vorversionen von PostgreSQL über die Systemsteuerung.
Die Deinstallation meldet, dass der Deinstallationsvorgang nicht abgeschlossen wurde, in der Protokolldatei sind jedoch keine Fehler vermerkt.	Der Deinstallationsvorgang hat das Verzeichnis netiq, in dem sich standardmäßig die Installationsdateien befindet, nicht gelöscht. Sobald Sie die gesamte NetIQ-Software vom Computer entfernt haben, können Sie das Verzeichnis löschen.
Nach dem Aufrüsten von Identity Manager wird die folgende Eigenschaft der Datei ism-configuration.properties hinzugefügt: com.netiq.idm.osp.ldap.admin-dn = cn=admin,ou=sa,o=system	Kommentieren Sie die Eigenschaft in der Datei ism-configuration.properties aus und starten Sie Tomcat neu. Die Funktionsfähigkeit wird nicht eingeschränkt.
Nach dem Aufrüsten von Identity Manager wird die folgende SSPR-Eigenschaft der Datei ism-configuration.properties hinzugefügt, auch wenn SSPR in Ihrer Bereitstellung nicht enthalten ist: com.netiq.sspr.redirect.url = https://___SSPR_IP___:___SSPR_TOMCAT_HTTPS_PORT___/sspr/public/oauth	Kommentieren Sie die Eigenschaft in der Datei ism-configuration.properties aus und starten Sie Tomcat neu. Die Funktionsfähigkeit wird nicht eingeschränkt.
Tomcat kann nach dem Aufrüsten von Identity Manager nicht gestartet werden. Sie stellen fest, dass die Tomcat-Protokolle einige Ausnahmen und einen Kommunikationsfehler zwischen der Workflow-Engine und dem Identitätsdepot enthalten.	Melden Sie sich bei iManager an. Navigieren Sie zu Rollen und Aufgaben > Zugriff auf NetIQ-Zertifikate > Serverzertifikate. Aktivieren Sie das Kontrollkästchen SSL CertificateDNS und klicken Sie auf Exportieren. Wählen Sie in der Dropdown-Liste Zertifikate die Option SSL CertificateDNS aus. Deaktivieren Sie das Kontrollkästchen Privaten Schlüssel exportieren. Stellen Sie sicher, dass Exportformat auf DER festgelegt ist. Klicken Sie auf Weiter > Exportiertes Zertifikat speichern, um das Zertifikat auf Ihr System herunterzuladen. Melden Sie sich beim Identity Applications-Server an. Halten Sie Tomcat an. Navigieren Sie zum Verzeichnis C:\NetIQ\Common\JRE\bin\ und importieren Sie das Zertifikat mit dem folgenden Befehl in die Datei idm.jks: <Installationspfad>\NetIQ\Common\JRE\bin\keytool -import -trustcacerts -alias <Zertifikat-Aliasname> -keystore <idm.jks> -file <heruntergeladene Zertifikatdatei> Starten Sie Tomcat neu.
Nach dem Aufrüsten von Identity Manager 4.7.4 auf 4.8 wird der Tomcat-Dienst nicht gestartet und in den Protokolldateien werden keine Fehler gemeldet. Dieses Problem tritt auf, wenn der Heartbeat-Zeitgeber in der afenginestate-Tabelle der igaworkflow-Datenbank nicht richtig aktualisiert wurde.	Um dieses Problem zu lösen, melden Sie sich bei einem Datenbank-Verwaltungswerkzeug wie pgAdmin an. Führen Sie die folgende Abfrage aus, um den Heartbeat-Zeitgeber in der afenginestate-Tabelle der igaworkflow-Datenbank manuell zu aktualisieren. update afenginestate set heartbeat=now()::timestamp;