18.3 インストールとアンインストールのトラブルシューティング

次の表に、発生する可能性のある問題とそれを解決するための推奨されるアクションを示します。問題が続く場合は、NetIQの担当者にお問い合わせください。

項目

推奨されるアクション

ConfigUpdateユーティリティを実行した後で、Identity Applicationsにログインできません。次のエラーメッセージがcatalina.outログファイルに表示されます。

javax.net.ssl.SSLHandshakeException: PKIX path validation failed: java.security.cert.CertPathValidatorException: Could not determine revocation status.

この問題は、LDAPサーバでBind Restrictions for Cipher (暗号のバインド制限)Use SuiteB Cipher (128-bit) (SuiteB暗号を使用 (128ビット))に設定されている場合に、Identity Manager 4.8.4 (edirectory 9.2.5)で発生します。Identity Managerはデジタル証明書を使用して、そのコンポーネントを認証して安全に通信します。証明書は、[CRL Distribution Point (CDP) (CRL配布ポイント(CDP)]フィールドで指定されている証明書取り消しリスト(CRL)をチェックして検証されます。このフィールドでは、証明書が取り消されているかどうかを判断します。CRLDPは、ルート証明書と、キーストアファイルtomcat.ksおよびidm.jksに存在する中間証明書の両方で使用できます。ただし、証明書取り消しチェックは、デフォルトで無効になっています。その結果、PKIX信頼マネージャは証明書の取り消しステータスを判断できません。

この問題を修正するには、-Dcom.sun.security.enableCRLDPプロパティをtrueに設定して、CRL配布ポイントチェックを有効にします。

このプロパティを設定するには、次のアクションを実行してください。

  1. Tomcatを停止します。

  2. Tomcatのbinフォルダにあるsetenv.shファイルに移動します。たとえば、C:\NetIQ\idm\apps\tomcat\bin\setenv.batです。

  3. CATALINA_OPTSに次のようにプロパティ-Dcom.sun.security.enableCRLDP=trueを追加します。

    export CATALINA_OPTS="-Dcom.sun.security.enableCRLDP=true"
  4. Tomcatを起動します。

Identity Managerをアップグレードした後、管理者以外のユーザはIdentity Managerダッシュボードへのログインに非常に時間がかかります。アプリケーションページとダッシュボードページのロードには、かなりの遅延があります。

この問題は、デフォルトで有効になっているネストされたグループ検索が原因で発生します。アプリケーションは、環境内にネストされたグループがあるかどうかに関係なく、ネストされたグループメンバーシップを介してログインしたユーザによって継承された許可を検索します。

(状況によって実行)次の手順は、Identity Manager 4.8.5以降に適用されます。

  1. Identity Applicationsが4.8.5バージョンにアップグレードされたサーバにログインします。

  2. C:\NetIQ\IDM\apps\tomcat\confの場所に移動します。

  3. テキストエディタでism-configuration.propertiesファイルを開きます。

  4. ファイルの末尾に、次のプロパティを追加します。

    DirectoryService/realms/jndi/params/USE_NESTED_GROUPS=false

  5. ファイルを保存し、Tomcatを再起動します。

Identity Applicationsを4.8.xバージョンにアップグレードした後で、Identity Applicationsダッシュボードにログインできなくなります。この問題は、Identity Applicationsのアップグレード中に、アイデンティティボールトのトラストストアパスが適切なキーストア(cacerts)ファイルの場所に更新されない場合に発生します。次の例外が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"

Identity Applicationsは、<install_path>\Common\JREに設定されたJAVA_HOME環境変数を使用します。トラストストアパスがJAVA_HOMEcacertsファイルに設定されていない場合、SSL通信は失敗し、「TrustAnchor」に関連するSSLエラーが発生します(トラストアンカーはSSL証明書の拡張Javaセキュリティチェックとして使用されます)。

この問題を解決するには、次のアクションを実行してください。

  1. Tomcatサービスを停止します。

  2. Identity Applicationsサーバにログインし、<install_path>\idm\apps\configupdateにあるconfigupdateユーティリティを起動します。

  3. [ユーザアプリケーション]タブで、Identity Vault Certificates (アイデンティティボールト証明書)に移動し、Truststore path (トラストストアパス)<install_path>\Common\JRE\lib\security\cacertsに設定されていることを確認します。

  4. Tomcatサービスを開始します。

分散環境のIdentity Managerを4.8.1バージョンにアップグレードした後で、Identity Applicationsへのログインに失敗します。以下のようなエラーメッセージが表示されます。

Your login process did not complete successfully.

Identity Applicationsにログインするには、Identity ApplicationsとOSP間のセキュアな接続を確立するためのトラストアンカー証明書が必要です。トラストアンカー証明書には、サブジェクトタイプがCAに設定された基本制約拡張が含まれている必要があります。Identity Managerは、プロパティjdk.security.allowNonCaAnchorを使用して、証明書のトラストアンカーを検証します。デフォルトでは、このプロパティはfalseに設定されています。したがって、トラストアンカーが証明書で見つからない場合は、Identity ApplicationsとOSP間の接続を確立することができず、ログインに失敗します。また、idm-osp.logファイルで次の例外に気づくでしょう。

sun.security.validator.ValidatorException: TrustAnchor with subject "CN=***, L=***, O=***" is not a CA certificate

この問題を解決するには、次の条件のいずれかを満たす必要があります。

  • Identity ApplicationsとOSP間のセキュアな接続を確立するために使用される証明書は、適切な基本制約拡張を含む信頼できるCA証明書であることを確認します。

  • クライアントによって信頼される自己署名証明書およびカスタム証明書の場合、基本制約拡張を含まないCA以外の証明書を許可するように、プロパティjdk.security.allowNonCaAnchorを変更できます。次のアクションを実行して、Javaセキュリティ設定を変更します。

  1. C:\NetIQ\idm\apps\jre\lib\security\java.securityディレクトリに移動します。

  2. プロパティjdk.security.allowNonCaAnchor=trueの値を設定します。

  3. ファイルを保存します。

Identity Applications 4.8.1バージョンにアップグレードした後で、Identity Applicationsダッシュボードで許可の要求中に、フォームを開くことができません。

この問題を解決するには、次の手順を実行してください。

  1. キーボードで<Windows> + <R>キーを押して、「services.msc」と入力し、OKを選択して、Windowsサービスインタフェースを開きます。

  2. サービス名、NetIQ Nginx ServiceNetIQ IGA Form Renderer Serviceを検索します。サービスを右クリックして、Restart (再起動)オプションを選択します。

Identity ApplicationsはIdentity ApplicationsダッシュボードでフォームをレンダリングするためにNGNIXサービスを使用します。

Identity ApplicationsまたはIdentity Reportingを4.8バージョンにアップグレードすると、コントロールパネルにPostgreSQLの複数のエントリが表示されます。

コントロールパネルから以前のバージョンのPostgreSQLをアンインストールします。

アンインストールプロセスが未完了と報告されるが、ログファイルには何もエラーが表示されない。

インストールファイルがデフォルトで保存されるnetiqディレクトリがプロセス中に削除されていません。このディレクトリは、コンピュータからNetIQソフトウェアをすべて削除している場合は削除できます。

Identity Managerをアップグレードした後で、次のプロパティがism-configuration.propertiesファイルに追加されます。

com.netiq.idm.osp.ldap.admin-dn = cn=admin,ou=sa,o=system

ism-configuration.propertiesファイルのプロパティをコメントアウトして、Tomcatを再起動します。機能が損なわれることはないからです。

Identity Managerをアップグレードすると、展開にSSPRがない場合でも、次のSSPRプロパティがism-configuration.propertiesファイルに追加されます。

com.netiq.sspr.redirect.url = https://___SSPR_IP___:___SSPR_TOMCAT_HTTPS_PORT___/sspr/public/oauth

ism-configuration.propertiesファイルのプロパティをコメントアウトして、Tomcatを再起動します。機能が損なわれることはないからです。

Identity Managerアップグレードの後で、Tomcatを起動できません。Tomcatログにはいくつかの例外があり、ワークフローエンジンとアイデンティティボールト間で通信障害が発生しています。

  1. iManagerにログインします。

  2. Roles and Tasks (役割とタスク) > NetIQ Certificate Access (NetIQ証明書アクセス) > Server Certificates (サーバ証明書)の順に移動します。

  3. SSL CertificateDNS (SSL証明書DNS)チェックボックスをオンにして、エクスポートをクリックします。

  4. 証明書ドロップダウンリストで、[SSL CertificateDNS]を選択します。

  5. Export private key (秘密鍵のエクスポート)チェックボックスをクリアします。Export format (エクスポート形式)DERに設定されていることを確認します。

  6. 次へ > Save the exported certificate (エクスポートされた証明書の保存)をクリックして、システムに証明書をダウンロードします。

  7. Identity Applicationsサーバにログインします。

  8. Tomcatを停止します。

  9. C:\NetIQ\Common\JRE\bin\ディレクトリに移動して、次のコマンドを使用して、証明書をidm.jksファイルにインポートします。

    <Installed_path>\NetIQ\Common\JRE\bin\keytool -import -trustcacerts -alias <certificate_alias_name> -keystore <idm.jks> -file <certificate_file_downloaded>

  10. Tomcatを再起動します。

Identity Managerを4.7.4から4.8にアップグレードした後で、Tomcatサービスが起動せず、ログファイルにエラーが報告されません。この問題は、igaworkflowデータベースのafenginestateテーブルでハートビートタイマーが適切に更新されていないときに発生します。

この問題を解決するには、pgAdminなどのデータベース管理ツールにログインします。次のクエリを実行して、igaworkflowデータベースのafenginestateテーブルのハートビートタイマーを手動で更新します。

update afenginestate set heartbeat=now()::timestamp;