ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Directory Server Enterprise Editionトラブルシューティング・ガイド
11g リリース 1 (11.1.1.7.0)
B72443-01
  目次へ移動
目次
索引へ移動
索引

前
 
次
 

7 Identity Synchronization for Windowsのトラブルシューティング

この章では、Identity Synchronization for Windowsの使用中に発生する可能性のある問題のトラブルシューティングに役立つ情報について説明します。含まれる内容は、次のとおりです。

この章は次の項で構成されています:

7.1 一般的なトラブルシューティングのガイドライン

この項では、Identity Synchronization for Windowsに関する問題のトラブルシューティングに役立つ一般的なガイドラインを示します。この章の内容は次のとおりです。


注意:

問題のトラブルシューティングを開始する前に、リリース・ノードで既知の問題についての説明およびパッチ要件に関する情報を確認してください。


7.1.1 ログの構成および使用方法

一部のイベントは、ログ・レベルをFINE以上に調整しないかぎり、ログ・ファイルには含まれません。ログ・レベルの調整については、『Identity Synchronization for Windows 6インストレーション・ガイド』ログ・ファイルの構成に関する説明を参照してください。すべてのidsync resync操作中は、ログ・レベルをINFOにしておく必要があります。

問題をトラブルシューティングする場合は、次のディレクトリにある集中エラー・ログを確認します。

isw-hostname/logs/central/error.log

ほぼすべてのエラーが集中エラー・ログにレポートされます。エラーに関する追加情報は、audit.logファイルに含まれている場合があります。関連するログ・エントリ間の相関関係を単純化するために、エラー・ログにある情報がaudit.logにも含まれます。

Windows NT SAMの変更検出サブコンポーネントを有効にする場合は、次のようにNT監査ログを有効にする必要があります。

  1. 「スタート」メニューから、「プログラム」、「管理ツール」、「ユーザー マネージャ」の順に選択します。

  2. 「ポリシー」、「監査ポリシー」の順に選択します。

  3. 「監査するイベント」を選択して、「ユーザーとグループ管理」の「成功」および「失敗」チェック・ボックスを選択します。

  4. 「イベント ビューア」の「イベント ログの処理」メニューで「イベント ログの設定」を選択します。次に、「必要に応じてイベントを上書きする」を選択します。

7.1.2 idsync printstatコマンドの使用方法

idsync printstatコマンドは、各コネクタのコネクタIDおよび状態を表示します。出力には、インストールおよび構成プロセスを完了するために実行する必要のある残りの手順のリストも表示されます。この状態情報は、Identity Synchronization for Windowsに関する問題のトラブルシューティングに利用できます。

たとえば、次のようにこのコマンドを実行します。

# idsync printstat

Connector ID: CNN100
Type:     Active Directory
Manages:  example.com (ldaps://host2.example.com:636)
State:    READY
Connector ID: CNN101
Type:     Sun Java System Directory
Manages: dc=example,dc=com 
(ldap://host1.example.com:389)
State:    READY
Sun Java System 
Message Queue Status:  Started
Checking the System Manager status over the Sun Java System
Message Queue.
System Manager Status:  Started SUCCESS

コマンドによってコネクタがリストされた場合は、構成は正常に保存されています。

7.1.2.1 クイック・チェックリストのトラブルシューティング

このチェックリストには、トラブルシューティングのプロセスで役立つ事項が含まれています。

  1. リソースの構成中にDirectory Serverは実行中でしたか。

  2. Message Queue、System Managerなどのコアは、現在実行中ですか。Windowsでは、適切なサービス名を確認します。SolarisおよびLinuxでは、適切なデーモン名を確認します。idsync printstatコマンドを使用して、Message QueueおよびSystem Managerがアクティブであることを確認します。

  3. 同期は、Identity Synchronization for Windowsコンソールから開始しましたか、それともコマンドラインからですか。

  4. 同期するディレクトリ・ソースは現在実行中ですか。

  5. Identity Synchronization for Windowsのコンソールを使用して、変更および作成が予測される方向に同期されることを確認します。

  6. 1つのディレクトリ・ソースにのみ存在するユーザーおよびグループを同期する場合に、これらのユーザーおよびグループは、idsync resyncコマンドを使用して他のディレクトリ・ソースで作成されましたか。


    注意:

    既存のユーザーおよびグループがある場合は、idsync resyncを実行する必要があります。既存のユーザーを再同期しない場合、再同期動作は未定義のままになります。


  7. 両方のディレクトリ・ソースに存在するユーザーを同期する場合に、idsync resyncコマンドを使用してこれらのユーザーをリンクしましたか。

  8. Active DirectoryまたはWindows NTからDirectory Serverへのユーザーの作成が失敗した場合は、Directory Serverオブジェクト・クラスのすべての必須属性が作成属性として指定されていること、および対応する属性の値が元のユーザー・エントリに存在することを確認します。

  9. Directory ServerからWindows NTへの作成の同期で、ユーザー作成は成功したが、アカウントが使用できない場合は、ユーザー名がWindows NT要件に違反していないことを確認します。

    たとえば、Windows NTで許容される最大の長さを超える名前を指定した場合、ユーザーはNT上に作成されますが、ユーザー名を変更(「ユーザー」→「名前の変更」)するまで使用または編集できません。

  10. 同期に失敗したユーザーは同期ユーザー・リストに含まれていますか。たとえば、彼らはベースDNおよび同期ユーザー・リストのフィルタに一致しますか。Active Directoryを含むデプロイメントでは、Directory Serverエントリが同期ユーザー・リストにない場合、オンデマンドのパスワード同期は警告なしで失敗します。ほとんどの場合、これは、同期ユーザー・リストのフィルタが正しくないために発生します。

  11. 同期設定が変更されましたか。同期設定をActive DirectoryからDirectory Serverへのユーザーの同期のみから、Directory ServerからActive Directoryへのユーザーの同期に変更した場合、Active Directory SSL CA証明書をコネクタの証明書データベースに追加する必要があります。idsync certinfoコマンドでは、現在のSSL設定に基づいて、インストールする必要のあるSSL証明書がレポートされます。

  12. すべてのホスト名が適切に指定され、DNSで解決できますか。Active Directoryドメイン・コントローラは、Active Directoryコネクタが動作しているマシンおよびDirectory Serverのプラグインが動作しているマシンからDNSで解決できるようにする必要があります。

  13. Active Directoryドメイン・コントローラのIPアドレスは、コネクタが接続に使用するものと同じ名前に解決されますか。

  14. 複数の同期ユーザー・リストが構成されていますか。その場合、それらは競合していますか。コンソールを使用して、より詳細な同期ユーザー・リストの順序を詳細度の低いリストの前にします。

  15. フローがSunからWindowsに対して、または双方向に設定され、デプロイメントにActive Directoryデータ・ソースが含まれる場合、コネクタはSSL通信を使用するように構成されていますか。

  16. ディレクトリ・ソースを作成または編集中に、Directory Serverの「既知のサーバーの選択」ドロップダウン・リストが表示されない場合は、そのDirectory Serverが動作していることを確認します。使用可能なホストのドロップダウン・リストに表示されるには、Directory Serverが実行中である必要があります。

    問題のサーバーが一時的に停止している場合は、「ホスト名とポートを入力してサーバーを指定」フィールドに、ホストおよびポートを入力します。


    注意:

    Identity Synchronization for Windowsでは、デフォルトで短いホスト名を使用しますが、デフォルトの短いホスト名は構成で機能しない場合があります。ホスト名を指定するように求められた場合は、完全修飾名を使用することをお薦めします。


7.1.3 Identity Synchronization for Windowsのインストールの問題のトラブルシューティング

インストールが、クリーンなマシン上で実行されたことを確認します。再インストールを行ったり、前回のインストールが正常にアンインストールされなかった場合に、エラーが発生する可能性があります。Identity Synchronization for Windowsのアンインストールの詳細は、『Identity Synchronization for Windows 6インストレーション・ガイド』の第7章「ソフトウェアの削除」を参照してください。

コアが正しくインストールされたかどうかの情報については、次のディレクトリにあるログ・ファイルを確認してください。

isw-hostname/logs/central/

コネクタのインストールは失敗したが、Identity Synchronization for Windowsのインストール・プログラムがコネクタがインストールされているとみなす場合は、インストール・プログラムによってコネクタの再インストールは許可されません。

idsync resetconnコマンドを実行して、コネクタの状態をUNINSTALLEDにリセットします。次に、コネクタを再インストールします。

ソフトウェアのアンインストール中に次のエラーが表示された場合は、/tmpにマウントされているスワップ・ファイルのサイズを増やす必要があります。

./runInstaller.sh
IOException while making /tmp/SolarisNativeToolkit_5.5.1_1  
executable:java.io.IOException: Not enough space java.io.IOException: Not enough space

インストール後、すべてのサブコンポーネントがインストールされていることを確認します。Directory ServerおよびWindows NTのコネクタでは、コネクタのインストールの後にサブコンポーネントがインストールされる必要があります。Directory Serverのプラグインは、各Directory Serverレプリカにインストールする必要があります。

Directory Serverのプラグインのインストール後に、Directory Serverを再起動する必要があります。Windows NTプライマリ・ドメイン・コントローラは、Windows NTサブコンポーネントのインストール後に再起動する必要があります。

7.2 メモリーの問題のトラブルシューティング

SolarisまたはLinux環境でメモリーの問題が疑われる場合は、プロセスを確認します。様々なプロセスとして実行されているコンポーネントを表示するには、次のように入力します。

/usr/ucb/ps -gauxwww | grep com.sun.directory.wps

出力には、コネクタ、システム・マネージャおよび集中ログ出力のIDに関する詳細が表示されます。これは、過剰なメモリーを消費しているプロセスがあるかどうかを確認するのに役立ちます。

7.3 コネクタの問題のトラブルシューティング

この項の情報を使用して、コネクタに関する問題をトラブルシューティングします。この項の内容は次のとおりです。

この章は次の項で構成されています:

7.3.1 コネクタの一般的なトラブルシューティングのヒント

すべてのコネクタがインストールされていることを確認します。同期しているディレクトリ・ソースごとに1つのコネクタをインストールする必要があります。

ソース・コネクタが、ユーザーに対する変更を検出することを確認します。ユーザーが追加または変更されたディレクトリ・ソースのコネクタが変更を検出するかどうかを確認するには、集中監査ログを使用します。

Identity Synchronization for Windowsコンソールまたはidsync printstatコマンドを使用して、すべてのコネクタがSYNCING状態であることを確認します。

宛先コネクタが変更を処理するかどうかを確認します。

7.3.2 ディレクトリ・ソースを管理するコネクタIDの確認

集中ログを使用するか、idsync printstatコマンドを使用して、コネクタIDを確認できます。

集中監査ログを確認することで、同期されるディレクトリ・ソースのコネクタIDを検索できます。起動時に、集中ログ出力は、各コネクタのIDおよびそれが管理するディレクトリ・ソースを記録します。最新の情報については、起動バナーの最後のインスタンスを検索します。

たとえば、次のログ・エントリには、2つのコネクタIDが含まれています。

  • CNN101は、dc=example,dc=comを管理するDirectory Serverコネクタです

  • CNN100は、example.comドメインを管理するActive Directoryコネクタです

[2006/03/19 00:00:00.722 -0600] INFO    16
"System Component Information:
SysMgr_100 is the system manager (CORE);
console is the Product Console User Interface;
CNN101 is the connector that manages
[dc=example,dc=com (ldap://host1.example.com:389)];
CNN100 is the connector that manages
[example.com (ldaps://host2.example.com:636)];"

コネクタIDを確認するためのidsync printstatコマンドの使用方法の詳細は、idsync printstatコマンドの使用方法」を参照してください。

7.3.3 コネクタの現行の状態の取得および管理

同期に関連するコネクタの現行の状態は、Identity Synchronization for Windowsコンソールの「ステータス」ペインを使用するか、idsync printstatコマンドを使用するか、集中監査ログを確認することで確認できます。

監査ログを使用するには、コネクタの状態をレポートする最後のメッセージを検索します。たとえば、次の監査ログ・エントリは、コネクタCNN101がREADY状態であることを示します。

[2006/03/19 10:20:16.889 -0600]
 INFO    13  SysMgr_100 host1
  "Connector [CNN101] is now in state "READY"."

表7-1 コネクタ状態の定義

状態 定義

UNINSTALLED

コネクタはインストールされていません。

INSTALLED

コネクタはインストールされていますが、構成されていません。

READY

コネクタはインストールされ構成されていますが、同期されていません。

SYNCING

コネクタはインストールおよび構成され、同期中です。


7.3.3.1 UNINSTALLED状態のコネクタのトラブルシューティング

コネクタがUNINSTALLED状態の場合、コネクタをインストールする必要があります。

7.3.3.2 INSTALLED状態のコネクタのトラブルシューティング

コネクタが長期間INSTALLED状態のままの場合、動作していないかMessage Queueと通信できない可能性があります。

コネクタがインストールされたマシンで、監査ログおよびエラー・ログで潜在的エラーを確認します。たとえば、コネクタがMessage Queueに接続できない場合は、エラー・ログに問題がレポートされます。コネクタがMessage Queueに接続できない場合は、「Message Queueコンポーネントのトラブルシューティング」を参照して考えられる原因を確認してください。

監査ログの最新のメッセージが古い場合は、コネクタが動作していない可能性があります。コネクタの起動に関する詳細は、「ウォッチドッグ・プロセスおよびコア・コンポーネントのトラブルシューティング」を参照してください。

7.3.3.3 READY状態のコネクタのトラブルシューティング

コネクタに接続されたすべてのサブコンポーネントの同期が開始されるまで、コネクタはREADY状態のままです。同期が開始されない場合は、Identity Synchronization for Windowsコンソールまたはコマンドライン・ユーティリティを使用して開始します。

同期が開始されてもコネクタがSYNCING状態にならない場合は、サブコンポーネントの1つに問題がある可能性があります。詳細は、「コネクタのサブコンポーネントのトラブルシューティング」を参照してください。

7.3.3.4 SYNCING状態のコネクタのトラブルシューティング

すべてのコネクタがSYNCING状態で、変更が同期されない場合は、同期設定が正しいことを確認します。

Identity Synchronization for Windowsのコンソールを使用して、変更および作成が期待される方向(たとえば、WindowsからDirectory Serverへ)に同期されることを確認します。また、変更された属性が同期された属性であることを確認します。作成されたユーザー・エントリが同期されない場合は、ユーザー作成フローがIdentity Synchronization for Windowsコンソールで有効化されていることを確認します。


注意:

パスワードは常に同期されます。


引き続き問題が発生する場合は、ソース・コネクタが、ユーザーに対する変更を検出するかどうかを確認します。ユーザーが追加または変更されたディレクトリ・ソースのコネクタが変更を検出するかどうかを確認するには、集中監査ログを使用します。宛先コネクタが変更を処理することも確認します。

7.3.4 Active Directoryコネクタの問題のトラブルシューティング

Active DirectoryコネクタがSSLを介したActive Directoryへの接続に失敗し、次のエラー・メッセージが表示された場合は、Active Directoryドメイン・コントローラを再起動します。

Failed to open connection to
ldaps://server.example.com:636,
error(91): Cannot connect to the LDAP server,
reason: SSL_ForceHandshake failed: (-5938)
Encountered end of file.

Active Directoryでの変更の検出および適用に失敗した場合は、権限が不十分である可能性があります。Active Directoryコネクタに対して管理者以外のアカウントが使用されている場合、このユーザーのデフォルトの権限は十分ではありません。Active DirectoryからDirectory Serverへの同期プロセスなどの一部の操作は成功しますが、Active Directoryでの変更の検出および適用などのその他の操作は突然失敗します。たとえば、Active DirectoryからDirectory Serverに削除を同期する場合、完全な権限であっても不十分です。この問題を解決するには、Active Directoryコネクタに対してドメイン管理者アカウントを使用する必要があります。

7.4 ウォッチドッグ・プロセスおよびコア・コンポーネントのトラブルシューティング

この項の情報を使用して、Identity Synchronization for Windowsのウォッチドッグ・プロセスおよびコア・コンポーネントに関する問題をトラブルシューティングします。ウォッチドッグ・プロセスは、集中ログ出力、システム・マネージャおよびコネクタを起動して監視します。コア・コンポーネントには、構成ディレクトリ、コマンドライン・ユーティリティ、システム・マネージャおよび集中ログ出力が含まれます。オペレーティング・システムごとに、次のように情報が提供されています。

この章は次の項で構成されています:

7.4.1 SolarisまたはLinux上のプロセスのトラブルシューティング

次のコマンドでは、現在実行中のIdentity Synchronization for Windowsのすべてのプロセスがリストされます。

# /usr/ucb/ps -auxww | grep com.sun.directory.wps

次の表では、実行する必要のあるプロセスについて説明します。

表7-2 Identity Synchronization for Windowsプロセス

Javaプロセス・クラス名 コンポーネント 存在するタイミング

com.sun.directory.wps.watchdog.server.WatchDog

ウォッチドッグ・プロセス

常時

com.sun.directory.wps.centrallogger.CentralLoggerManager

集中ログ出力

コアがインストールされている場合のみ

com.sun.directory.wps.manager.SystemManager

システム・マネージャ

コアがインストールされている場合のみ

com.sun.directory.wps.controller.AgentHarness

コネクタ

インストールされているコネクタごとに1つ


予測される数のプロセスが実行されていない場合は、次のコマンドを発行してすべてのIdentity Synchronization for Windowsプロセスを再起動します。

# /etc/init.d/isw stop
# /etc/init.d/isw start

ウォッチドッグ・プロセスは実行中で、予測される数のjava.exeプロセスが実行されていない場合は、すべてのコンポーネントが適切にインストールされていることを確認します。コンポーネントの確認の詳細は、WatchList.propertiesファイルの確認」を参照してください。

他のシステム・コンポーネントと同様に、Directory Serverのプラグインもエンドユーザーが確認できるように、集中ログ出力で管理されるバス経由でログ・レコードを送信します。ただし、プラグインでは、サブコンポーネントがコネクタに接続できないときに書き込まれるメッセージなどの、バスを介して表示されない可能性のあるメッセージも記録します。これらのログ・メッセージは、ファイル・システムにあるプラグインのlogsディレクトリのみに含まれ、次のような内容です。

serverroot/isw-hostname/logs/SUBCid

このプラグインはDirectory Serverプロセスとともに実行されるため、logsディレクトリに書き込むためのプラグインの機能に問題が発生する可能性が潜在的にあります。これは、logsディレクトリの所有者とは異なるユーザでDirectory Serverが実行されている場合に発生します。Directory Serverプロセスを別のユーザーで実行する場合は、オペレーティング・システム固有のコマンドを使用して、プラグインに明示的な権限を与えます。

7.4.2 Windows上のプロセスのトラブルシューティング

「サービス」コントロール・パネルを使用して、Sun Java System Identity Synchronization for Windowsサービスが開始されていることを確認します。開始されていない場合は、Identity Synchronization for Windowsを起動する必要があります。

サービスが開始されている場合は、タスク・マネージャを使用してウォッチドッグ・プロセス(pswwatchdog.exe)が実行されていて、予測される数のjava.exeプロセスが実行されていることを確認します。マシンにインストールされているコネクタごとに1つのjava.exeプロセスが必要です。コア・コンポーネントがインストールされている場合は、次のそれぞれにもjava.exeプロセスが1つずつ必要です。

  • Message Queueブローカ用に1つ

  • システム・マネージャ用に1つ

  • 集中ログ出力用に1つ


注意:

Directory Service Control Centerなどのその他のJavaプロセスが実行されている場合があります。


ウォッチドッグ・プロセスが実行されていない場合は、Sun Java System Identity Synchronization for Windowsサービスを再開します。ウォッチドッグ・プロセスは実行中で、予測される数のjava.exeプロセスが実行されていない場合は、すべてのコンポーネントが適切にインストールされていることを確認します。コンポーネントの確認の詳細は、WatchList.propertiesファイルの確認」を参照してください。

7.4.3 WatchList.propertiesファイルの確認

Identity Synchronization for Windowsコンポーネントがインストールされている各マシンで、そのマシン上で実行される必要のあるコンポーネントがisw-machine_name/resources/WatchList.propertiesファイルに列挙されます。process.name[n]プロパティは、実行されている必要のあるコンポーネントの名前を示します。

コア・コンポーネントがインストールされているマシンでは、次のように、集中ログ出力およびシステム・マネージャのエントリがWatchList.propertiesファイルに含まれます。

process.name[1]=Central Logger
process.name[2]=System Manager

コネクタがインストールされているマシンでは、次のように、コネクタごとに個別のエントリがWatchList.propertiesファイルに含まれます。process.nameプロパティはコネクタIDです。

process.name[3]=CNN100
process.name[4]=CNN101

WatchList.propertiesファイルに含まれるエントリと実際に実行されているプロセスが同じでない場合は、Identity Synchronization for Windowsデーモンまたはサービスを再起動します。

WatchList.propertiesファイルに含まれているエントリの数が少なすぎる場合、たとえば、2つインストールされている場合にコネクタ・エントリが1つしかない場合は、インストール・ログで可能性のあるインストールの失敗を調べます。インストール・ログの場所は、次のように、オペレーティング・システムによって異なります。

  • Solarisでは、インストール・ログは/opt/SUNWiswに書き込まれます

  • Linuxでは、インストール・ログは/var/opt/sun/isw/logsに書き込まれます

  • Windowsでは、インストール・ログは%TEMP%ディレクトリに書き込まれ、これは、次の場所にあるLocal Settingsフォルダのサブディレクトリです

    C:\Documents and Settings\Administrator
    

    Windows 2000 Advanced Serverなどの一部のWindowsシステムでは、Local Settingsフォルダは隠しフォルダです。次の手順は、隠しフォルダの表示方法を示します。

7.4.3.1 Windows上の隠しフォルダおよびTempサブディレクトリの表示手順

  1. Windowsエクスプローラを開きます。

  2. 「ツール」メニューから、「フォルダ オプション」を選択します。

  3. 「フォルダ オプション」ダイアログ・ボックスが表示されたら、「表示」タブを選択します。

  4. 「すべてのファイルとフォルダを表示する」チェック・ボックスを選択します。

7.5 コネクタのサブコンポーネントのトラブルシューティング

この項では、コネクタのサブコンポーネントに関する問題のトラブルシューティングの手順を紹介します。開始する前に、次のことを確認してください。

7.5.1 サブコンポーネントのインストールの確認

すべてのサブコンポーネントがインストールされていることを確認します。サブコンポーネントのインストールは、コネクタのインストール後に行う必要があります。インストールされているサブコンポーネントは、次のように、使用されるコネクタによって異なります。

  • Active Directoryコネクタでは、サブコンポーネントはインストールされません。

  • Directory Serverコネクタでは、同期されるDirectory ServerでDirectory Serverのプラグインが有効になっている必要があります。

  • Windows NTコネクタでは、同期される各Windows NTドメインのプライマリ・ドメイン・コントローラに、Windowsの変更検出およびパスワード・フィルタ・サブコンポーネントをインストールする必要があります。これらのサブコンポーネントは、Windows NTコネクタのインストール後にインストールされます。

Windows NT SAMの変更検出サブコンポーネントを有効にする場合は、NT監査ログを有効にする必要があります。監査ログを有効にするには、次の手順を使用してから、「ポリシー」→「監査ポリシー」の順に選択します。「監査するイベント」を選択して、「ユーザーとグループ管理」の「成功」および「失敗」の両方のボックスを選択します。

7.5.1.1 Windows NTの監査ログを有効にするための手順

  1. 「スタート」メニューで、「プログラム」、「管理ツール」、「ユーザー マネージャ」の順に選択します。

  2. 「イベント ビューア」で、「イベント ログの処理」を選択してから「イベント ログの設定」を選択します。

  3. 「必要に応じてイベントを上書きする」を選択します。

7.5.2 インストール後のサーバーの再起動の確認

サブコンポーネントをインストールしたら、正しいインストール後処理手順を行ったことを確認します。たとえば、Directory Serverプラグインをインストール後に、サーバーを再起動する必要があります。プライマリ・ドメイン・コントローラに、Windows NTの変更検出およびパスワード・フィルタ・サブコンポーネントをインストール後に、サーバーを再起動する必要があります。

7.5.3 ネットワーク接続の確認

サブコンポーネントで引き続き問題が発生する場合は、コネクタとのネットワーク接続が確立されていることを確認します。コネクタが実行されているマシンで、次のコマンドを実行して、コネクタがサブコンポーネントの接続をリスニングしていることを確認します。

# netstat -n -a

たとえば、netstatコマンドでは、コネクタがポート9999で受信接続をリスニングしていて、サブコンポーネントが正常に接続されていることが次のように示されます。

# netstat -n -a | grep 9999
*.9999
*.*    0   0 65536    0 LISTEN
12.13.1.2.44397 12.13.1.2.9999
73620 0 73620    0 ESTABLISHED
12.13.1.2.9999
12.13.1.2.44397 73620 0 73620
0 ESTABLISHED

ただし、サブコンポーネントが接続されていない場合は、netstatコマンドは、かわりに次のように示します。

# netstat -n -a | grep 9999
*.9999
*.*    0   0 65536    0 LISTEN

サブコンポーネントが実行されていることを確認後、サブコンポーネントのローカル・ログで可能性のある問題について調べます。

正しいポート番号が指定されているを確認します。コネクタが実行されていて、READY状態であることを確認します。コネクタのローカル・ログで可能性のある問題について調べます。

コネクタが受信接続をリスニングしていない場合、netstatコマンドの出力は次のようになります。

# netstat -n -a | grep 9999
#

7.6 Message Queueコンポーネントのトラブルシューティング

この項では、Message Queueコンポーネントおよびそのブローカに関する問題をトラブルシューティングする方法について説明します。内容は次のとおりです。

この章は次の項で構成されています:

7.6.1 telnetを使用したMessage Queueブローカが実行していることの確認

Message Queueブローカが実行されていることを確認します。telnetコマンドを使用して、Message Queueブローカが実行されているマシンおよびポートに接続すると、アクティブなMessage Queueサービスのリストが返されます。

# telnet localhost 7676
Trying 127.0.0.1...
Connected to localhost.
Escape character is \q^]\q.
101 psw-broker 3.0.1
cluster tcp CLUSTER 32914
admin tcp ADMIN 32912
portmapper tcp PORTMAPPER 7676
ssljms tls NORMAL 32913
jms tcp NORMAL 32911
Connection closed by foreign host.

出力にssljms tcp NORMALサービスがリストされていない場合は、Message Queueログで可能性のある問題について調べます。ログの場所は、次のように、使用しているプラットフォームによって異なります。

  • Solarisの場合、ログは/var/imq/instances/psw-broker/log/log.txtにあります

  • Linuxの場合、ログは/var/opt/sun/mq/instances/isw-broker/log/log.txtにあります

  • Windowsの場合、ログはinstallation_root\isw-machine_name\imq\var\instances\isw-broker\log\log.txtにあります

    telnetコマンドが失敗した場合、ブローカが実行されていない、または誤ったポートが指定されています。ブローカのログでポート番号を確認します。たとえば、ログには、次のようにブローカのポートの行があります。

[13/Mar/2003:18:17:09 CST] [B1004]:
'Starting the portmapper service using tcp
[ 7676, 50 ]
with min threads 1 and max threads of 1'

ブローカが実行されていない場合、SolarisおよびLinuxでは、/etc/init.d/imq startコマンドを実行して起動します。Windowsでは、iMQ Broker Windowsサービスを開始して、ブローカを起動します。

Solaris 8にMessage Queueをインストールし、mquinstallコマンドを実行してパッケージをすべてインストールする場合は、mqinstallコマンドを実行する前にIMQ_JAVAHOMEプロパティを設定してください。これにより、ソフトウェアによって正しいバージョンのJavaが選択されます。

コア・コンポーネントをまだインストールしていない場合は、Identity Synchronization for Windowsインストール・プログラムによって、どのバージョンのJavaを使用すべきかがMessage Queueブローカに指示されるため、IMQ_JAVAHOMEプロパティを設定する必要はありません。

7.6.2 Message Queueブローカに関する追加情報の収集

デバッグ・ログを有効にしてブローカを実行すると、問題に関する追加情報の収集に役立てることができます。デバッグ・ログ・レベルを有効にするには、次のコマンドを使用します。

# imqbrokerd -loglevel DEBUG

次のコマンドを使用して、ブローカのデバッグ・ダンプを取得できます。

imqcmd dump bkr -edebug -u admin -o file=filename

7.6.3 Directory Serverとの通信の問題のトラブルシューティング

Message Queueブローカは、Identity Synchronization for Windows構成を格納するDirectory Serverを使用してクライアントを認証します。ブローカがこのDirectory Serverに接続できない場合は、クライアントはMessage Queueに接続できません。ブローカ・ログには、javax.naming.CommunicationExceptionjavax.naming.NameNotFoundExceptionなどのjavax.naming例外が含まれます。

javax.naming例外が発生した場合は、次の手順を実行します。

  • /var/imq/instances/isw-broker/props/config.propertiesファイルのすべてのimq.user_repository.ldap propertiesの値が正しいことを確認します。いずれかの値が正しくない場合は、Message Queueブローカを停止します。エラーを修正し、ファイルを保存して、ブローカを再起動します。Message Queueブローカが実行されているマシンでは、Directory Serverホスト名が解決できる必要があることに注意してください。

  • /etc/imq/passfileファイルのimq.user_repository.ldap.passwordプロパティが正しいことを確認します。

  • ルート・サフィックスに空白が含まれている場合は、ブローカがエントリを検索できない場合があります。ルート・サフィックス名に空白が含まれていないことを確認します。

7.6.4 メモリーの問題のトラブルシューティング

通常の操作中、Message Queueブローカは、適度な量のメモリーを消費します。ただし、idsync resync操作では、ブローカのメモリー要件が増加します。ブローカがメモリー制限に達すると、未配信のメッセージが蓄積され、idsync resync操作の速度が急激に低下したり、Identity Synchronization for Windowsが応答しなくなる可能性があります。

ブローカがメモリー不足状態になると、ログに次のメッセージが表示されます。

[03/Nov/2003:14:07:51 CST] [B1089]:
In low memory condition,
Broker is attempting to f
ree up resources [03/Nov/2003:14:07:51 CST] [B1088]:
Entering Memory State [B0024]:
RED  from previous state [B0023]:
ORANGE - current memory is 1829876K,
90% of total memory

メモリー不足状態を避けるには、次の手順を実行します。

  • Oracle Directory Server Enterprise Editionリリース・ノートの説明に従って、ブローカのメモリー制限を1GBまたは2GBに増やします。

  • idsync resync操作中、ログ・レベルの設定をINFOに維持します。ログ・レベルをFINE以上に変更すると、集中ログ出力に送信されるログ・メッセージが増え、ブローカの負荷が増大します。

  • 一度に1つの同期ユーザー・リストごとにidsync resyncコマンドを実行します。

7.6.5 Message Queueブローカのメモリー不足状態からのリカバリ手順

  1. ブローカに未配信メッセージのバックログがあることを確認します。

    使用しているオペレーティング・システムの適切なディレクトリにある、ブローカの永続メッセージ・ストアを確認します。

    • Solarisの場合: /var/imq/instances/psw-broker/filestore/message/

    • Linuxの場合: /var/opt/sun/mq/instances/isw-broker/filestore/message/

    • Windowsの場合: installation_root\isw-machine_name\imq\var\instances\isw-broker\filestore\message\

    このディレクトリの各ファイルには、1つの未配信メッセージが含まれています。このディレクトリに10,000を超えるファイルがある場合は、ブローカにはメッセージのバックログがあります。そうでない場合、ブローカに関する問題は未配信メッセージのバックログが原因ではありません。

    メッセージ・バックログには、通常、idsync resync操作に関連するログ・ファイルが含まれており、それらは安全に削除できます。

  2. Message Queueブローカを停止します。

    詳細は、『Identity Synchronization for Windows 6インストレーション・ガイド』サービスの開始および停止に関する説明を参照してください。

  3. 永続メッセージ・ストアのすべてのファイルを削除します。

    これらのファイルを削除する最も簡単な方法は、message/ディレクトリを再帰的に削除してから再作成することです。

  4. Message Queueブローカを再起動します。

    将来、メモリー不足にならないようにするには、この項で前述した手順を実行します。

7.7 SSLを介したIdentity Synchronization for Windowsのインストールの問題のトラブルシューティング

この項では、SSLを介したIdentity Synchronization for Windowsの問題をトラブルシューティングする方法について説明します。内容は次のとおりです。

この章は次の項で構成されています:

7.7.1 コア・コンポーネント間のSSLの問題のトラブルシューティング

Identity Synchronization for Windowsインストール・プログラムでは、コア・インストール中に指定されたSSLポートが正しいかどうかは確認できません。コア・インストール中にSSLポートを間違って入力した場合、コア・コンポーネントは適切に通信することができません。構成を最初に保存しようとするときまで、問題に気が付かない可能性があります。Identity Synchronization for Windowsコンソールに、次の警告が表示されます。

The configuration was successfully saved,
however, the System Manager could not be
notified of the new configuration.

システム・マネージャのログには、次のエントリがあります。

[10/Nov/2003:10:24:35.137 -0600] WARNING 14
example  "Failed to connect
to the configuration directory because "Unable to connect: (-5981)
Connection refused by peer."
Will retry shortly."

これらの警告およびエラー・メッセージが表示された場合は、コアをアンインストールし、正しいSSLポート番号で再度インストールします。

7.7.2 コネクタおよびDirectory ServerまたはActive Directory間のSSLの問題のトラブルシューティング

コネクタがSSLを介してDirectory ServerまたはActive Directoryに接続できない場合は、集中エラー・ログに、次のメッセージが表示されます。

[06/Oct/2006:14:02:48.911 -0600]
WARNING 14  CNN100 host1
"failed to open connection
to ldaps://host2.example.com:636."

Identity Synchronization for Windowsコンソールを開いて、「拡張セキュリティ・オプションの指定」パネルに移動します。SSLポートが正しいことを確認します。

7.7.3 Directory ServerおよびActive Directory間のSSLの問題のトラブルシューティング

デフォルトでは、オンデマンド・パスワード同期の実行時に、Directory Serverは、SSLを介してActive Directoryとは通信しません。SSLを使用したこの通信を保護するためにデフォルトが上書きされた場合は、『Identity Synchronization for Windows 6インストレーション・ガイド』の第1章「製品の理解」の説明に従って、Active DirectoryのCA証明書を各マスター・レプリカのDirectory Server証明書データベースに追加する必要があります。

Active DirectoryのCA証明書が追加されない場合、エラー「ディレクトリ・サービス・エージェントが実行不可の状態です。」が表示され、ユーザーはDirectory Serverのバインドに失敗します。プラグインのログisw-hostname /logs/SUBC100/pluginwps_log_0.txtに、次のようにレポートされます。

[06/Nov/2006:15:56:16.310 -0600]
INFO    td=0x0376DD74 logCode=81 
ADRepository.cpp:310
"unable to open connection to Active Directory server 
at ldaps://host2.example.com:636, reason: "

これらのエラーが発生した場合は、Active DirectoryのCA証明書をDirectory Serverの証明書データベースに追加し、Directory Serverを再起動する必要があります。

7.7.4 証明書の問題のトラブルシューティング

この項では、Identity Synchronization for Windowsの証明書の使用に関する様々な問題をトラブルシューティングする方法について説明します。この章の内容は、次のとおりです。

この章は次の項で構成されています:

7.7.4.1 信頼できない証明書

証明書が信頼できないという通知を受信した場合は、集中監査ログにアクセスします。たとえば、LDAPサーバーのSSL証明書が信頼できない場合、このメッセージは次のように記録されます。

[06/Oct/2006:14:02:48.951 -0600] INFO
14  CNN100 host1  "failed to open connection to 
ldaps://host2.example.com:636, error(91):
Cannot connect to the LDAP server,
reason: SSL_ForceHandshake failed:
(-8179) Peer's Certificate issuer
is not recognized."

この種のエラーが発生するのは、多くの場合、CA証明書がコネクタの証明書データベースに追加されていないことが原因です。certutilツールを実行して、証明書が追加されているかどうかを確認します。このツールの詳細は、ssltapツールについて」を参照してください。

この例では、証明書データベースに証明書は含まれていません。

# /usr/sunone/servers/shared/bin/certutil
 -L -d /usr/sunone/servers/
 isw-host1/etc/CNN100
Certificate Name             Trust Attributes
p    Valid peer
P    Trusted peer (implies p)
c    Valid CA
T    Trusted CA to issue client certs (implies c)
C    Trusted CA to certs(only server certs for ssl) (implies c)
u    User cert
w    Send warning

次の例では、証明書データベースには、Active DirectoryのCA証明書のみが含まれています。

# /usr/sunone/servers/shared/bin/certutil -L -d
/usr/sunone/servers/ isw-host1/etc/CNN100
Certificate Name                                 Trust Attributes
example.com CA                                    C,c,
p    Valid peer
P    Trusted peer (implies p)
c    Valid CA
T    Trusted CA to issue client certs (implies c)
C    Trusted CA to certs(only server certs for ssl) (implies c)
u    User cert
w    Send warning

ここに示すとおり、CA証明書の信頼フラグはC,,である必要があります。証明書が存在し、信頼フラグが正しく設定されていても、まだコネクタが接続できない場合は、証明書を追加した後にコネクタが再起動されたことを確認します。ldapsearchコマンドを使用して、問題の診断に役立てます。ldapsearchが証明書を受け入れない場合は、コネクタも受け入れません。たとえば、それらが信頼できない場合、次のように、ldapsearchは証明書を拒否する場合があります。

# /usr/sunone/servers/shared/bin/ldapsearch 
-Z -P /usr/sunone/ servers/isw-host1/etc/CNN100
-h host2 -b "" -s base "(objectclass=*)
"ldap_search: Can't contact LDAP server
SSL error -8179 
Peer's Certificate issuer is not recognized.)

-Pオプションは、ldapsearchに対して、SSL証明書の検証にCNN100コネクタの証明書データベースを使用するように指示します。コネクタの証明書データベースに正しい証明書を追加した後、ldapsearchが証明書を受け入れることを確認してから、コネクタを再起動します。

7.7.4.2 ホスト名の不一致

Identity Synchronization for WindowsがSSL通信の確立を試みると、コネクタは、サーバーのホスト名がSSLネゴシエーション・フェーズでサーバーから提示された証明書内のホスト名と一致するかどうかを確認します。ホスト名が一致しない場合は、コネクタは接続の確立を拒否します。

Identity Synchronization for Windows構成ファイルのディレクトリ・ソースのホスト名は、そのディレクトリ・ソースで使用される証明書に埋め込まれているホスト名と常に一致する必要があります。

次のようにldapsearchを使用して、ホスト名が一致することを確認できます。

/var/mps/serverroot/shared/bin/ldapsearch.exe
-Z -P /var/opt/SUNWisw/etc/CNN100 -3
-h host2.example.com -p 636 
-s base -b "" "(objectclass=*)"

ldapsearchコマンドラインで指定されたホスト名と、証明書に埋め込まれたホスト名が同じでない場合、次のエラー・メッセージが表示されます。

ldap_search: Can't contact LDAP server 
SSL error -12276
(Unable to communicate securely with peer: requested 
do main name does not match 
the server's certificate.)

ホスト名が一致する場合は、ldapsearchコマンドが成功し、ルートDSEのコンテンツが表示されます。

7.7.4.3 期限切れの証明書

サーバーの証明書が期限切れの場合、次のメッセージがログに表示されます。

[06/Oct/2006:14:06:47.130 -0600]
INFO    20  CNN100 host1 
"failed to open connection to ldaps://host2.example.com:636,
error(91): Cannot connect to the LDAP server,
reason: SSL_ForceHandshake failed: 
(-8181) Peer's Certificate has expired."

ログ・ファイルにこのメッセージを受信した場合は、サーバーに新しい証明書を発行する必要があります。

7.8 Active Directoryドメイン・コントローラの問題のトラブルシューティング

Active Directoryドメイン・コントローラは、フォレスト内のすべてのドメインからのオブジェクトを格納するグローバル・カタログ・サーバーです。Active Directoryドメイン・コントローラをバックアップ・ファイルからリストアする場合、一部のカウンタはリセットされません。すべてのカウンタを適切にリセットするには、Active Directoryドメイン・コントローラのリストア後にすべてのユーザーを再同期します。