この章では、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 監査ログを有効にする必要があります。
「スタート」メニューから「プログラム」、「管理ツール」、「ユーザー マネージャ」の順に選択します。
「ポリシー」、「監査ポリシー」の順に選択します。
「監査するイベント」を選択し、「ユーザーとグループの管理」の「成功」および「失敗」チェックボックスにチェックマークを付けます。
イベントビューアの「イベントログのラップ」メニューで「イベントログの設定」を選択します。次に、「必要に応じてイベントを上書きする」を選択します。
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 |
コマンドによりコネクタが一覧表示された場合、設定は正常に保存されています。
このチェックリストには、トラブルシューティングのプロセスで役立つ確認事項が含まれています。
リソースの設定中に Directory Server は実行中でしたか。
Message Queue や System Manager などのコアは現在実行中ですか 。Windows の場合は、適切なサービス名を確認します。Solaris および Linux の場合は、適切なデーモン名を確認します。idsync printstat コマンドを使用して、Message Queue と System Manager がアクティブであることを確認します。
同期は Identity Synchronization for Windows コンソールから開始しましたか、それともコマンド行から開始しましたか。
同期させるディレクトリソースは現在実行中ですか 。
Identity Synchronization for Windows コンソールを使用して、変更と作成が正しい方向に同期されることを確認します。
1 つのディレクトリソースのみに存在していたユーザーとグループを同期中だった場合、idsync resync コマンドを使用してこれらのユーザーとグループをほかのディレクトリソースに作成しましたか。
idsync resync を実行して、ユーザーとグループが存在しているかどうかを確認する必要があります。既存のユーザーを再同期しない場合、再同期の動作は未定義のままになります。
両方のディレクトリソースに存在していたユーザーを同期中だった場合、idsync resync コマンドを使用してこれらのユーザーをリンクしましたか。
Active Directory または Windows NT から Sun Java System Directory Server へのユーザーの作成が失敗した場合は、Directory Server オブジェクトクラス内のすべての必須属性が作成属性として指定されていて、対応する属性の値が元のユーザーエントリに指定されていることを確認します。
Directory Server から Windows NT に作成を同期中で、ユーザーの作成は成功したがアカウントを使用できない場合は、ユーザー名が Windows NT 要件に違反していないか確認します。
たとえば、Windows NT で許容される長さの最大値を超える名前を指定すると、ユーザーは NT 上に作成されますが、ユーザーの名前を変更 (「ユーザー」->「名前の変更」) するまで使用または編集することはできません。
同期に失敗するユーザーは、同期ユーザーリストに指定されていますか 。たとえば、それらのユーザーは、同期ユーザーリストのベース DN およびフィルタと一致しますか。Active Directory が含まれる配備では、Sun Java System Directory Server エントリが同期ユーザーリストに指定されていない場合、オンデマンドのパスワード同期は警告なしで失敗します。ほとんどの場合、この問題は同期ユーザーリストのフィルタが正しくないために発生します。
同期設定が変更されていませんか。Active Directory から Sun Java System Directory Server へのユーザーの同期から、Directory Server から Active Directory へのユーザーの同期に同期設定を変更した場合は、コネクタの証明書データベースに Active Directory SSL CA 証明書を追加する必要があります。idsync certinfo コマンドを実行すると、現在の SSL 設定に基づいてインストールする必要がある SSL 証明書が示されます。
すべてのホスト名は適切に指定され、DNS で解決可能ですか。Active Directory ドメインコントローラは、Active Directory コネクタが稼働しているマシンと Sun Java System Directory Server プラグインが稼働しているマシンから、DNS で解決可能にしてください。
Active Directory ドメインコントローラの IP アドレスは、コネクタがコントローラに接続するために使用するものと同じ名前に解決されますか。
複数の同期ユーザーリストが設定されていませんか。設定されている場合、それらが競合していませんか。コンソールを使用して、詳細度がより高い同期ユーザーリストの順序を、詳細度が低い同期ユーザーリストより先にします。
フローを双方向、または Sun から Windows に設定し、配備に Active Directory データソースが含まれる場合、コネクタは SSL 通信を使用するように設定されていますか。
Sun Java System ディレクトリソースを作成または編集中に、Directory Server の「既知のサーバーの選択」ドロップダウンリストが表示されない場合は、その Directory Server が稼働していることを確認します。使用可能なホストのドロップダウンリストに表示される Directory Server は、稼働している必要があります。
該当するサーバーが一時的にダウンしている場合は、「ホスト名とポートを入力してサーバーを指定」フィールドにホスト名とポートを入力します。
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 は、セントラルログを使用するか、idsync printstat コマンドを使用することで確認できます。
セントラル監査ログを確認すると、同期させるディレクトリソースのコネクタ 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)];" |
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"." |
状態 |
定義 |
---|---|
UNINSTALLED |
コネクタはインストールされていません。 |
INSTALLED |
コネクタはインストールされていますが、設定されていません。 |
READY |
コネクタはインストールおよび設定されていますが、同期していません。 |
SYNCING |
コネクタはインストールおよび設定されていて、同期中です。 |
コネクタが UNINSTALLED 状態の場合は、コネクタをインストールする必要があります。
コネクタが長期間 INSTALLED 状態のままの場合は、実行されていないか、Message Queue と通信できない可能性があります。
コネクタがインストールされているマシンで、可能性のあるエラーを監査およびエラーログで確認します。たとえば、コネクタが Message Queue に接続できない場合は、そのエラーログに問題が報告されます。コネクタが Message Queue に接続できない場合は、「Message Queue コンポーネントのトラブルシューティング」で考えられる原因を確認してください。
監査ログ内の最新メッセージが古い場合は、コネクタが実行されていない可能性があります。コネクタの起動については、「ウォッチドッグプロセスとコアコンポーネントのトラブルシューティング」を参照してください。
コネクタに接続されたすべてのサブコンポーネントで同期が始まるまで、コネクタは READY 状態のままです。同期が開始されていない場合は、Identity Synchronization for Windows コンソールまたはコマンド行ユーティリティーを使用して開始します。
同期を開始してもコネクタが SYNCING 状態にならない場合は、サブコンポーネントのいずれかに問題がある可能性があります。詳細については、「コネクタサブコンポーネントのトラブルシューティング」を参照してください。
すべてのコネクタが SYNCING 状態になっていても、変更が同期されていない場合は、同期設定が正しいことを確認します。
Identity Synchronization for Windows コンソールを使用して、変更と作成が正しい方向、たとえば Windows から Directory Server に同期されることを確認します。また、変更される属性が同期された属性であることを確認します。作成されたユーザーエントリが同期されていない場合は、Identity Synchronization for Windows コンソールでユーザー作成フローが有効になっているか確認します。
パスワードは常に同期されます。
引き続き問題が発生する場合は、ソースコネクタがユーザーに対する変更を検出するかどうかを確認します。ユーザーが追加または変更したディレクトリソースのコネクタが変更を検出するかどうかを確認するには、セントラル監査ログを使用します。また、ターゲットコネクタが変更を処理するかどうかも確認します。
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 のウォッチドッグプロセスとコアコンポーネントのトラブルシューティングを行うには、ここで示す情報を使用します。ウォッチドッグプロセスは、セントラルロガー、システムマネージャー、およびコネクタを起動および監視します。コアコンポーネントには、設定ディレクトリ、コマンド行ユーティリティー、システムマネージャー、およびセントラルロガーが含まれます。次のようにオペレーティングシステムごとに情報を示します。
この章の内容は次のとおりです。
次のコマンドは、現在実行中のすべての 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 プロセスが別のユーザーとして実行されている場合は、ネイティブのオペレーティングシステムコマンドを使用して、プラグインに明示的なアクセス権を与えます。
「サービス」コントロールパネルを使用して、Sun Java System Identity Synchronization for Windows サービスが開始されていることを確認します。開始されていない場合は、Identity Synchronization for Windows を起動する必要があります。
サービスが開始されている場合は、タスクマネージャーを使用して、ウォッチドッグプロセス pswwatchdog.exe が実行されていて、正しい数の java.exe プロセスが実行されていることを確認します。java.exe プロセスは、マシンにインストールされているコネクタごとに 1 つずつあります。コアコンポーネントがインストールされている場合は、次のものにもそれぞれ 1 つずつ java.exe プロセスがあります。
Message Queue ブローカ用に 1 つ
システムマネージャー用に 1 つ
セントラルロガー用に 1 つ
ほかのアクティブな Java プロセス (Directory Service Control Center など) が実行されていることがあります。
ウォッチドッグプロセスが実行されていない場合は、Sun Java System Identity Synchronization for Windows サービスを再開します。ウォッチドッグプロセスは実行中だが、正しい数の java.exe プロセスが実行されていない場合は、すべてのコンポーネントが適切にインストールされていることを確認します。コンポーネントの確認については、「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 フォルダは隠しフォルダです。隠しフォルダを表示するには、次の手順に従います。
Windows エクスプローラを開きます。
「ツール」メニューから「フォルダ オプション」を選択します。
「フォルダ オプション」ダイアログボックスが表示されたら、「表示」タブを選択します。
「すべてのファイルとフォルダを表示する」チェックボックスにチェックマークを付けます。
ここでは、コネクタサブコンポーネントに関する問題のトラブルシューティングのための手順について、順を追って説明します。始める前に次のことを確認してください。
サブコンポーネントは実行されていますか。
プラグインがインストールされている Directory Server は実行されていますか 。変更検出機能とパスワードフィルタがインストールされているプライマリドメインコントローラは実行されていますか。
すべてのサブコンポーネントがインストールされていることを確認します。サブコンポーネントのインストールは、コネクタのインストール後に行う必要があります。インストールされているサブコンポーネントは、次のように、使用されるコネクタによって異なります。
Active Directory コネクタの場合、サブコンポーネントはインストールされません。
Directory Server コネクタの場合は、同期される Directory Server で Directory Server プラグインが有効になっている必要があります。
Windows NT コネクタの場合、Windows 変更検出機能サブコンポーネントとパスワードフィルタサブコンポーネントを、同期される各 Windows NT ドメインのプライマリドメインコントローラにインストールする必要があります。これらのサブコンポーネントは、Windows NT コネクタのインストール後にインストールする必要があります。
Windows NT SAM 変更検出サブコンポーネントが有効な場合は、Windows NT 監査ログを有効にする必要があります。監査ログを有効にするには、次の手順を実行してから、「ポリシー」->「監査ポリシー」の順に選択します。「監査するイベント」を選択し、「ユーザーとグループの管理」の「成功」と「失敗」の両方のチェックボックスにチェックマークを付けます。
「スタート」メニューで、「プログラム」、「管理ツール」、「ユーザー マネージャ」の順に選択します。
イベントビューアで、「イベントログの設定」、「イベントログのラップ」の順に選択します。
「必要に応じてイベントを上書きする」を選択します。
サブコンポーネントをインストールしたら、正しいインストール後処理手順を行ったことを確認します。たとえば、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 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 サービスを開始してブローカを起動します。
Message Queue を Solaris 8 にインストールし、mquinstall コマンドを実行してすべてのパッケージをインストールする場合は、mqinstall コマンドを実行する前に必ず IMQ_JAVAHOME プロパティーを設定してください。これにより、ソフトウェアが確実に正しいバージョンの Java を選択します。
まだコアコンポーネントをインストールしていない場合は、どのバージョンの Java を使用すべきかを Identity Synchronization for Windows インストールプログラムが Message Queue ブローカに指示するため、IMQ_JAVAHOME プロパティーを設定する必要はありません。
デバッグログを有効にしてブローカを実行すると、問題に関するその他の情報を収集しやすくなります。デバッグログレベルを有効にするには、次のコマンドを実行します。
# imqbrokerd -loglevel DEBUG |
次のコマンドを使用して、ブローカのデバッグダンプを取得します。
imqcmd dump bkr -edebug -u admin -o file=filename |
Message Queue ブローカは、Identity Synchronization for Windows 設定を格納する Directory Server でクライアントを認証します。ブローカがこの Directory Server に接続できない場合、クライアントは Message Queue に接続できません。ブローカログには、javax.naming.CommunicationException や javax.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 プロパティーが正しいことを確認します。
ルートサフィックスにスペースが含まれている場合は、ブローカがエントリを検索できないことがあります。ルートサフィックスにスペースが含まれていないことを確認します。
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 |
メモリー低下状態を回避するには、次の手順を実行します。
『Sun Java System Directory Server Enterprise Edition 6.3 リリースノート』の説明に従って、ブローカのメモリー制限を 1G バイトまたは 2G バイトに増やします。
idsync resync 操作の最中は、ログレベルを INFO に設定したままにします。ログレベルを FINE 以上に変更すると、セントラルロガーに送信されるログメッセージが増え、ブローカの負荷が大きくなります。
一度に 1 つの同期ユーザーリストに対して idsync resync コマンドを実行します。
ブローカに未配信メッセージのバックログがあることを確認します。
使用しているオペレーティングシステムの適切なディレクトリにある、ブローカの持続メッセージストアを調べます。
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 操作に関連するログファイルが含まれ、それらは安全に削除できます。
Message Queue ブローカを停止します。
詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 Installation Guide - Ja』の「Starting and Stopping Services」を参照してください。
持続メッセージストア内のすべてのファイルを削除します。
これらのファイルを削除するもっとも簡単な方法は、message/ ディレクトリを再帰的に削除してから再度作成することです。
Message Queue ブローカを再起動します。
将来メモリー不足にならないようにするには、この節の前のほうで説明した手順を実行します。
ここでは、SSL を介した Identity Synchronization for Windows の使用に関する問題のトラブルシューティングの方法について説明します。項目は、次のとおりです。
この章の内容は次のとおりです。
「コネクタと Directory Server または Active Directory 間の SSL に関する問題のトラブルシューティング」
「Directory Server と Active Directory 間の 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 ポート番号で再度インストールします。
コネクタが 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 は 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 ドメインコントローラを復元したあとですべてのユーザーを再同期します。