test

Sun Java System Directory Server Enterprise Edition 6.3 トラブルシューティングガイド

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

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

この章の内容は次のとおりです。

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

ここでは、Identity Synchronization for Windows に関する問題のトラブルシューティングに役立つ一般的なガイドラインを示します。この章は、次の各節で構成されています。

注 –

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

ログの設定と使用

イベントによっては、ログレベルを調整して FINE 以上にするまでは、ログファイルに記録されません。ログレベルを調整するには、『Sun Java System Directory Server Enterprise Edition 6.3 Installation Guide - Ja』の「Configuring Your Log Files」を参照してください。idsync resync 操作の最中は必ずログレベルを INFO のままにしてください。

問題をトラブルシューティングするときは、次のディレクトリにある セントラルエラーログを調べます。


isw-hostname/logs/central/error.log

ほとんどすべてのエラーがセントラルエラーログファイルで報告されます。エラーに関するその他の情報は、audit.log ファイルに含まれている場合があります。関係のあるログエントリ間の相関関係を単純化するため、audit.log ファイルにはエラーログにある情報も含まれます。

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

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

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

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

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

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

コマンドによりコネクタが一覧表示された場合、設定は正常に保存されています。

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

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

  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 から Sun Java System Directory Server へのユーザーの作成が失敗した場合は、Directory Server オブジェクトクラス内のすべての必須属性が作成属性として指定されていて、対応する属性の値が元のユーザーエントリに指定されていることを確認します。

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

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

  10. 同期に失敗するユーザーは、同期ユーザーリストに指定されていますか 。たとえば、それらのユーザーは、同期ユーザーリストのベース DN およびフィルタと一致しますか。Active Directory が含まれる配備では、Sun Java System Directory Server エントリが同期ユーザーリストに指定されていない場合、オンデマンドのパスワード同期は警告なしで失敗します。ほとんどの場合、この問題は同期ユーザーリストのフィルタが正しくないために発生します。

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

  12. すべてのホスト名は適切に指定され、DNS で解決可能ですか。Active Directory ドメインコントローラは、Active Directory コネクタが稼働しているマシンと Sun Java System Directory Server プラグインが稼働しているマシンから、DNS で解決可能にしてください。

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

  14. 複数の同期ユーザーリストが設定されていませんか。設定されている場合、それらが競合していませんか。コンソールを使用して、詳細度がより高い同期ユーザーリストの順序を、詳細度が低い同期ユーザーリストより先にします。

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

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

    該当するサーバーが一時的にダウンしている場合は、「ホスト名とポートを入力してサーバーを指定」フィールドにホスト名とポートを入力します。

    注 –

    Identity Synchronization for Windows は、デフォルトでは短いホスト名を使用しますが、デフォルトのホスト名はこの設定では機能しない場合があります。ホスト名を指定するときは、常に完全修飾名を使用することをお勧めします。

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

インストールがクリーンなマシン上で行われたことを確認します。再インストールを行い、前回のインストールが適切にアンインストールされていない場合は、エラーが発生することがあります。Identity Synchronization for Windows のアンインストールの詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 Installation Guide - Ja』の第 9 章「Removing the Software」を参照してください。

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


isw-hostname/logs/central/

コネクタのインストールに失敗したが、Identity Synchronization for Windows インストールプログラムではコネクタがインストールされているものと見なされる場合、インストールプログラムでコネクタを再インストールすることはできません。

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

ソフトウェアのアンインストール中に次のエラーが表示される場合は、/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 サブコンポーネントのインストール後に再起動する必要があります。

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

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

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

出力にはコネクタ、システムマネージャー、セントラルロガーの ID を含む完全な詳細が表示されます。これは、メモリーを過度に消費しているプロセスがあるかどうかを確認するときに有用です。

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

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

この章の内容は次のとおりです。

コネクタの一般的なトラブルシューティングについて

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

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

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

ターゲットコネクタが変更を処理するかどうかを確認します。

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

コネクタ ID は、セントラルログを使用するか、idsync printstat コマンドを使用することで確認できます。

セントラル監査ログを確認すると、同期させるディレクトリソースのコネクタ ID を調べることができます。起動時に、各コネクタの ID とそれが管理するディレクトリソースのログがセントラルロガーに記録されます。起動バナーの最後のインスタンスを探し、最新情報を確認します。

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


[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)];"

idsync printstat コマンドによるコネクタ ID の確認の詳細については、「idsync printstat コマンドの使用」を参照してください。

コネクタの現在の状態の取得と管理

同期に関連するコネクタの現在の状態を確認するには、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

コネクタはインストールおよび設定されていて、同期中です。 

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

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

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

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

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

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

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

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

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

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

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

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

注 –

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

引き続き問題が発生する場合は、ソースコネクタがユーザーに対する変更を検出するかどうかを確認します。ユーザーが追加または変更したディレクトリソースのコネクタが変更を検出するかどうかを確認するには、セントラル監査ログを使用します。また、ターゲットコネクタが変更を処理するかどうかも確認します。

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 コネクタのドメイン管理者アカウントを使用する必要があります。

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

Identity Synchronization for Windows のウォッチドッグプロセスとコアコンポーネントのトラブルシューティングを行うには、ここで示す情報を使用します。ウォッチドッグプロセスは、セントラルロガー、システムマネージャー、およびコネクタを起動および監視します。コアコンポーネントには、設定ディレクトリ、コマンド行ユーティリティー、システムマネージャー、およびセントラルロガーが含まれます。次のようにオペレーティングシステムごとに情報を示します。

この章の内容は次のとおりです。

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

コネクタ 

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

正しい数のプロセスが実行されていない場合は、次のコマンドを実行してすべての 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 ディレクトリ内に書き込むためのプラグインの機能に問題が発生する可能性が潜在的にあります。これは、Directory Server が logs ディレクトリの所有者とは異なるユーザーとして実行されている場合に発生します。Directory Server プロセスが別のユーザーとして実行されている場合は、ネイティブのオペレーティングシステムコマンドを使用して、プラグインに明示的なアクセス権を与えます。

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

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

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

注 –

ほかのアクティブな Java プロセス (Directory Service Control Center など) が実行されていることがあります。

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

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 つしかないような場合は、インストールログで可能性のあるインストールエラーを調べます。インストールログの場所は、次のようにオペレーティングシステムによって異なります。

ProcedureWindows の隠しフォルダと Temp サブディレクトリを表示する

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

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

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

  4. 「すべてのファイルとフォルダを表示する」チェックボックスにチェックマークを付けます。

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

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

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

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

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

ProcedureWindows NT 監査ログを有効にする

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

  2. イベントビューアで、「イベントログの設定」、「イベントログのラップ」の順に選択します。

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

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

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

ネットワーク接続の確認

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


# 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
#

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

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

この章の内容は次のとおりです。

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 ログで可能性のある問題について調べます。このログの場所は、次のように、使用しているプラットフォームによって異なります。


[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 サービスを開始してブローカを起動します。

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

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

Message Queue ブローカに関するその他の情報の収集

デバッグログを有効にしてブローカを実行すると、問題に関するその他の情報を収集しやすくなります。デバッグログレベルを有効にするには、次のコマンドを実行します。


# imqbrokerd -loglevel DEBUG

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


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

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

Message Queue ブローカは、Identity Synchronization for Windows 設定を格納する Directory Server でクライアントを認証します。ブローカがこの Directory Server に接続できない場合、クライアントは Message Queue に接続できません。ブローカログには、javax.naming.CommunicationException や javax.naming.NameNotFoundException などの javax.naming 例外が記録されます。

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

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

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

メモリー低下状態を回避するには、次の手順を実行します。

ProcedureMessage 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 ブローカを停止します。

    詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 Installation Guide - Ja』の「Starting and Stopping Services」を参照してください。

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

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

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

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

SSL を介した Identity Synchronization for Windows に関する問題のトラブルシューティング

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

この章の内容は次のとおりです。

コアコンポーネント間の 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 ポート番号で再度インストールします。

コネクタと 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 ポートが正しいことを確認します。

Directory Server と Active Directory 間の SSL に関する問題のトラブルシューティング

デフォルトでは、オンデマンドパスワード同期の実行中、Directory Server は SSL を介して Active Directory と通信しません。SSL によってこの通信を保護するようにデフォルトが上書きされた場合は、『Sun Java System Directory Server Enterprise Edition 6.3 Installation Guide - Ja』の第 3 章「Understanding the Product」の説明に従って、Active Directory の CA 証明書を各マスターレプリカの Directory Server 証明書データベースに追加する必要があります。

Active Directory の CA 証明書を追加しないと、「DSA is unwilling to perform」というエラーが表示され、ユーザーは 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 を再起動する必要があります。

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

ここでは、Identity Synchronization for Windows での証明書の使用に関するさまざまな問題のトラブルシューティングの方法について説明します。次の項があります。

この章の内容は次のとおりです。

信頼できない証明

証明書が信頼できないという通知が表示された場合は、セントラル監査ログにアクセスします。たとえば、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 ツールを実行します。このツールの詳細については、「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 オプションは、SSL 証明書検証に CNN100 コネクタの証明書データベースを使用するように ldapsearch に指示します。コネクタの証明書データベースに正しい証明書を追加したあと、ldapsearch が証明書を受け入れることを確認してから、コネクタを再起動します。

ホスト名の不一致

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 の内容が表示されます。

期限切れの証明書

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


[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."

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

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

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