Sun Java ロゴ     前へ      目次      索引      次へ     

Sun ロゴ
Sun Java System Identity Synchronization for Windows 1 2004Q3 インストールおよび設定ガイド 

第 9 章
トラブルシューティング

この章では、Identity Synchronization for Windows の使用時に発生する可能性のある問題の解決に役立つ情報を提供します。この章で説明する内容は、次とおりです。

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

注

管理者 : 問題のデバッグを行うときは、ログレベル (「ログファイルの設定」を参照) を調整し、問題の原因として考えられるすべてのイベントがログに記録されるようにします。

ユーザーが SUL に指定されていないために、プログラムがユーザー変更の同期に失敗する場合など、一部のイベントはログレベルを FINE 以上に設定するまでログに記録されません。idsync resync を利用したすべての操作では、ログレベルを INFO の状態に保ちます。

Identity Synchronization for Windows をインストール、設定するときは、idsync printstat コマンドが便利です。printstat を実行すると (「printstat の使用」を参照)、インストールと設定の完了までに残されている手順がリスト表示されます。

  1. セントラルエラーログファイル (error.log) に記録されている問題はありますか ?

    2. isw-<hostname>/logs/central/error.log

    ほとんどのエラーはセントラルエラーログファイルに記録されます。また、通常はエラーに関する追加情報が audit.log ファイルに記録されます。関連するログエントリの追跡を容易にするために、エラーログのすべてのエントリは audit.log ファイルにも記録されます。

  2. 「リリースノート」には既知の問題点が数多く記載されています。発生した問題は、そこで説明されていますか ?
  3. インストールは新規インストールとして行われましたか ?以前の設定が完全にアンインストールされていない場合、この製品の再インストール時に問題が発生する可能性があります。過去のインストールをクリーンアップする方法については、第 8 章「ソフトウェアの削除」を参照してください。
  4. コアは正しくインストールされていますか ? コアが正しく完全にインストールされていれば、isw-<hostname>/logs/central/ ディレクトリにログファイルが存在します。
  5. リソースの設定時に Directory Server は稼動していましたか ?
  6. Message Queue とシステムマネージャを含め、コアは現在稼動していますか ?Windows 環境では、適切なサービス名を確認します。Solaris 環境では、適切なデーモン名を確認します。Message Queue とシステムマネージャがアクティブであるかどうかを確認するには、idsync printstat コマンドを使用します。
  7. 設定は正しく保存されていますか ?idsync printstat コマンドを実行してコネクタのリストが出力されれば、設定は正しく保存されています。
  8. コネクタはすべてインストールされていますか ?同期対象のディレクトリソースごとに 1 つのコネクタをインストールする必要があります。
  9. サブコンポーネントはすべてインストールされていますか ? Directory Server と Windows NT のコネクタは、サブコンポーネントを必要とします。サブコンポーネントは、コネクタのインストール後にインストールします。Directory Server のそれぞれのレプリカには、Directory Server プラグインをインストールする必要があります。
  10. インストール後の手順は実行しましたか ? Directory Server プラグインのインストール後は、Directory Server を再起動する必要があります。また、Windows NT サブコンポーネントのインストール後は、Windows NT 主ドメインコントローラを再起動する必要があります。
  11. コンソールとコマンド行のいずれかから同期を開始しましたか ?
  12. すべてのコネクタが現在稼動していますか ?
  13. コンソールまたは idsync printstat コマンド行ユーティリティを使用して、すべてのコネクタの状態が SYNCING であることを確認します。
  14. 同期対象のディレクトリソースは現在稼動していますか ?
  15. コンソールを使用して、修正、作成、またはその両方が指定どおりの同期方向で同期されていることを確認します。
  16. いずれか一方のディレクトリソースに存在するユーザーを同期させる場合、idsync resync コマンドを使用してこれらのユーザーをもう一方のディレクトリソースに作成しましたか ?

    注

    既存ユーザーが存在する場合は、常に idsync resync を実行する必要があります。既存ユーザーを再同期させない場合、再同期の動作は未定義のまま残ります。

  17. 同期対象ユーザーが両方のディレクトリソースに存在する場合、idsync resync コマンドを使用してこれらのユーザーをリンクさせましたか ?
  18. Active Directory または Windows NT から Sun Java System Directory Server へのユーザー作成が失敗した場合は、Directory Server オブジェクトクラス内のすべての必須属性が作成属性として指定され、対応する属性の値がソース側ユーザーエントリに用意されていることを確認します。
  19. Directory Server から Windows NT に作成を同期させる場合に、ユーザー作成には成功しても、アカウントが使用不可能となるときは、ユーザー名が Windows NT の要件に違反していないことを確認します。

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

  20. Windows NT SAM 変更ディテクタサブコンポーネントを有効にするには、NT 監査ログを有効にする必要があります。「スタート」 > 「プログラム」 > 「管理ツール」 > 「ユーザーマネージャ」を選択し、「原則」 > 「監査の原則」を選択します。「監査するイベント」を選択し、「ユーザーとグループの管理」で「成功」と「失敗」の両方を選択します。

    21. 「イベントビューア」で「イベントログの設定」を選択し、「ログサイズが最大値に達したときの操作」の「必要に応じてイベントを上書きする」を選択します。

  21. 同期に失敗するユーザーは、同期ユーザーリストに指定されていますか ? たとえば、それらのユーザーは、同期ユーザーリストに指定されているベース DN およびフィルタと一致しますか ?Active Directory が含まれる配備では、Sun Java System Directory Server エントリが同期ユーザーリストに指定されていない場合、オンデマンドのパスワード同期は警告なしで失敗します。多くの場合、この問題は同期ユーザーリストのフィルタが正しくないために発生します。
  22. 同期設定は変更されていませんか ?Active Directory から Sun Java System Directory Server へのユーザーの同期を、Directory Server から Active Directory へのユーザーの同期に変更した場合は、コネクタの証明書データベースに Active Directory SSL CA 証明書を追加する必要があります。idsync certinfo コマンドを実行すると、現在の SSL 設定でインストールが必要な SSL 証明書が示されます。
  23. すべてのホスト名は正しく指定され、DNS 解決されていますか ? Active Directory ドメインコントローラは、Active Directory コネクタが稼動するマシン、および Sun Java System Directory Server プラグインが稼動しているマシンから DNS 解決できる必要があります。
  24. Active Directory ドメインコントローラの IP アドレスは、コネクタがコントローラの接続に使用する名前に解決されますか ?
  25. ソースコネクタは、ユーザーに加えられた変更を検出していますか ? ユーザーが追加または修正されたディレクトリソースのコネクタが変更を検出するかどうかを確認するときは、セントラル監査ログ (audit.log) を調べます。
  26. ターゲットコネクタは、この変更を処理していますか ?
  27. 複数の同期ユーザーリストが設定されていませんか ?設定されている場合、それらは競合していませんか ? コンソールを使用して、詳細度がより高い同期ユーザーリストの順序を、詳細度が低い同期ユーザーリストより先にします。
  28. 同期フローを双方向、または Sun から Windows に設定し、配備に Active Directory データソースが含まれる場合、コネクタは SSL 通信を使用するように設定されていますか ?
  29. Solaris 環境でメモリの問題が発生したと考えられる場合は、プロセスを調べます。どのコンポーネントが別プロセスとして実行されているかを確認するときは、次のように入力します。

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

    コネクタの ID、システムマネージャ、セントラルロガーなど、すべての詳細情報が出力されます。これは、いずれかのプロセスがメモリを過度に消費していないかどうかを調べる場合に便利です。

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

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

    注

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

  31. アンインストールプログラムの実行時に次のエラーメッセージが出力されますか ?

    32. ./runInstaller.sh

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

    java.io.IOException: Not enough space

    /tmp にマウントされるスワップファイルのサイズを大きくします。

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

ここでは、コネクタに関連する問題のトラブルシューティングについて説明します。ここで説明する内容は次のとおりです。

ディレクトリソースを管理するコネクタの ID を特定する方法

コネクタ ID は、次のいずれかの方法で特定することができます。

セントラルログの使用

セントラル監査ログ (audit.log) を調べ、同期させるディレクトリソースのコネクタ ID を特定します。起動時に、セントラルロガーは各コネクタと、それが管理するディレクトリソースの ID をログに記録します。最新の情報を確認するには、起動バナーの最後のインスタンスについて調べます。

たとえば、次のログメッセージでは 2 つのコネクタを確認できます。

idsync printstat の使用

コネクタの ID と状態は、idsync printstat コマンドを使用して確認することもできます (「printstat の使用」を参照)。

次に、このコマンドの出力例を示します。

Connector ID: CNN100
   Type:Active Directory
   Manages: airius.com (ldaps://host2.airius.com:636)
   State:READY

Connector ID: CNN101
   Type:     Sun Java System Directory
   Manages: dc=airius,dc=com (ldap://host1.airius.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

コネクタの現在の状態を確認する方法

同期に関与するコネクタの現在の状態を調べるときは、コンソールの「状態」パネル、または前述の idsync printstat コマンドを使用するか、セントラル監査ログ (audit.log) を調べます。

コネクタの状態を示す最後のメッセージを audit.log ファイルで検索します。たとえば、次のメッセージでは、コネクタ CNN101 の状態が READY であることがわかります。

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

表 9-1 は、コネクタの各種状態を説明しています。

表 9-1 コネクタの状態の意味

状態

意味

UNINSTALLED

コネクタはインストールされていない

INSTALLED

コネクタはインストールされているが、設定を受信していない

READY

コネクタはインストールされ、設定も受信しているが、同期のために起動されていない

SYNCING

コネクタはインストールされ、設定も受信し、同期のための起動も試みられている

コネクタの状態が UNINSTALLED である場合の対応

コネクタをインストールします。

コネクタのインストールに失敗したが、再インストールできない場合の対応

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

idsync resetconn を実行してコネクタの状態を UNINSTALLED (アンインストール済み) にリセット (「resetconn の使用」を参照) してからコネクタを再インストールします。

コネクタの状態が INSTALLED である場合の対応

コネクタの状態が長期間インストール済みとされるときは、ほとんどの場合は稼動していないか、Message Queue と通信できない状態にあります。

コネクタがインストールされているマシンで、発生した可能性のあるエラーについて、コネクタのログ (audit.log と error.log) を調べます。コネクタが Message Queue に接続できない場合は、エラーメッセージがここに記録されます。この場合は、考えられる原因について「Message Queue のトラブルシューティング」を参照してください。

監査ログの最後のメッセージの日時が古い場合は、おそらくそのコネクタは稼動していません。「コンポーネントのトラブルシューティング」を参照してください。

コネクタの状態が READY である場合の対応

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

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

コネクタの状態が SYNCING である場合の対応

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

Active Directory コネクタが SSL 経由で 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.

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

コンポーネントのトラブルシューティングには、ここに示す情報を使用します。ここで説明する内容は次のとおりです。

Solaris 環境

/usr/ucb/ps -auxww | grep com.sun.directory.wps コマンドを実行すると、実行されているすべての Identity Synchronization for Windows プロセスがリスト表示されます。次の表は、稼動している必要のあるプロセスを示しています。

表 9-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

WatchDog プロセスが稼動していても、想定される数の java.exe プロセスが実行されていない場合は、「WatchList.properties の調査」を参照し、すべてのコンポーネントが正しくインストールされていることを確認します。

その他のシステムコンポーネントと同様に、Sun Java System Directory Server プラグインも、ユーザーが表示できるようにセントラルロガーが管理するバスを経由してログレコードを送信します。ただし、サブコンポーネントがコネクタに接続できない場合など、プラグインはこのバスを経由せずに一部のメッセージをログに記録します。この場合、ログメッセージは次のような形式で、ファイルシステム内のプラグインの logs ディレクトリだけに記録されます。

<serverroot>/isw-<hostname>/logs/SUBC<id>

プラグインは Directory Server プロセスと共に実行されるため、プラグインが logs ディレクトリへの書き込みを試みるときに問題が発生する可能性があります。この問題は、logs ディレクトリの所有者以外のユーザーとして Directory Server が実行される場合に生じます。この場合、そのディレクトリのアクセス権、またはネイティブオペレーティングシステムコマンドを使用する所有者を変更し、プラグインにアクセス権を明示的に与えることが必要となる可能性があります。

Windows 環境

「サービス」コントロールパネルを使用して、「Sun Java System Identity Synchronization for Windows」サービスが開始されていることを確認します。開始されていない場合、そのマシンでは Identity Synchronization for Windows は稼動していないので、開始する必要があります。サービスが開始されている場合は、タスクマネージャを使用して、pswwatchdog.exe (Watchdog プロセス) が実行されていることと、想定される数の次の java.exe プロセスが実行されていることを確認します。

注

Directory Server コンソール用など、その他の java プロセスが稼動していることも考えられます。pswwatchdog.exe が稼動していない場合は、「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 デーモンまたはサービスを開始し直します。

2 つのコネクタがインストールされているのに 1 つのエントリしか表示されない場合など、WatchList.properties に含まれるエントリの数が想定される数より少ない場合は、インストールの失敗についてインストールログを調べます。

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

配備に含まれるサブコンポーネントのトラブルシューティングには、次のチェックリストを使用します。

  1. すべてのサブコンポーネントがインストールされていますか ?

    2. サブコンポーネントのインストールは、コネクタのインストール後に行う必要があります。

    • Active Directory コネクタでは、サブコンポーネントはインストールされない
    • Sun Java System Directory Server コネクタでは、同期対象の Sun Java System Directory Server にプラグインをインストールする必要がある
    • Windows NT コネクタでは、同期対象の Windows NT ドメインごとに変更ディテクタとパスワードフィルタのサブコンポーネントを主ドメインコントローラにインストールする必要がある。これら 2 つのサブコンポーネントは、Windows NT コネクタのインストール後にまとめてインストールされる

      • 注

      Windows NT SAM 変更ディテクタサブコンポーネントを有効にするには、NT 監査ログを有効にする必要があります。「スタート」 > 「プログラム」 > 「管理ツール」 > 「ユーザーマネージャ」を選択し、「原則」 > 「監査の原則」を選択します。「監査するイベント」を選択し、「ユーザーとグループの管理」で「成功」と「失敗」の両方を選択します。

      「イベントビューア」で「イベントログの設定」を選択し、「ログサイズが最大値に達したときの操作」の「必要に応じてイベントを上書きする」を選択します。

  2. サブコンポーネントのインストール後の操作手順は完了していますか ?

    3. Directory Server プラグインを Sun Java System Directory Server にインストールした後は、サーバーを再起動する必要があります。また、NT 変更ディテクタとパスワードフィルタを主ドメインコントローラにインストールした後はサーバーを再起動する必要があります。

  3. サブコンポーネントは稼動していますか ?

    4. プラグインがインストールされている Directory Server は稼動していますか ?変更ディテクタとパスワードフィルタがインストールされた主ドメインコントローラは稼動していますか ?

  4. サブコンポーネントはコネクタとのネットワーク接続を確立していますか ?

    5. コネクタが実行されているマシンで netstat -n -a を実行し、コネクタがサブコンポーネントの接続を待機していることを確認します。次の例は、異なる 3 つの配備でのこのコマンドの実行例を示しています。コネクタは、ポート 9999 で待機するように設定されています。

    1. 想定どおりにコネクタは接続を待機し、サブコンポーネントは正常に接続している

      2. 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

    2. コネクタは接続を待機しているが、サブコンポーネントは接続していない

      3. # netstat -n -a | grep 9999

           *.9999               *.*    0   0 65536    0 LISTEN

      サブコンポーネントが稼動していることを確認し、問題についてサブコンポーネントのローカルログを調べます。

    3. コネクタが接続を待機していない

      4. # netstat -n -a | grep 9999

      <no output>

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

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

Sun Java System Message Queue ブローカが実行されていることを確認します。Message Queue ブローカが稼動しているマシンとポートに対して telnet コマンドを実行すると、アクティブな Message Queue サービスのリストが返されます。

# telnet localhost 7676

Trying 127.0.0.1...

Connected to localhost.

Escape character is '^]'.

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.

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 環境では /etc/init.d/imq start を実行することで稼動を開始できます。Windows 環境では iMQ Broker Windows サービスを開始します。

Message Queue を Solaris 8 にインストールするときに、mquinstall を実行してすべてのパッケージをインストールする場合は、ソフトウェアが正しいバージョンの Java を認識するように、mqinstall を実行する前に IMQ_JAVAHOME を設定する必要があります。

まだコアをインストールしていない場合は、使用する JVM が Identity Synchronization for Windows のインストールプログラムによって Message Queue に指定されるため、IMQ_JAVAHOME を設定する必要はありません。

ブローカと設定ディレクトリの通信に関するトラブルシューティング

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

このような状況の発生を回避するには、次のように対応します。

ブローカの使用可能メモリがなくなった場合に復元するには、次の手順を実行します。

  1. 適切なディレクトリで持続的なメッセージストアを調べ、ブローカに未配信メッセージのバックログがあることを確認します。
    • Solaris 環境 : /var/imq/instances/psw-broker/filestore/message/
    • Windows 環境 : <installation_root>¥isw-<machine_name>¥imq¥var¥ instances¥isw-broker¥filestore¥message¥
  2. このディレクトリ内の各ファイルには、1 つの未配信メッセージが含まれます。このディレクトリ内のファイル数が 10000 を超える場合、ブローカはメッセージのバックログを持ちます。1バックログが存在しない場合は、ブローカに別の問題があります。
  3. メッセージのバックログは、idsync resync の動作に関連するログファイルの中で、おそらく安全に削除できる唯一のログファイルです。
  4. 「サービスの開始と停止」で説明した方法で Message Queue ブローカを停止します。
  5. 持続的メッセージストア内のすべてのファイルを削除します。これらのファイルを削除する最も簡単な方法は、message/ ディレクトリを一度削除し、作成し直すことです。
  6. Message Queue ブローカを開始し直します。

ブローカの使用可能メモリがなくならないように、ここで説明した操作方法を実行します。

SSL の問題に関するトラブルシューティング

SSL に関する問題を診断するときは、Identity Synchronization for Windows のコンポーネント間で SSL を設定する方法について説明している第 11 章「セキュリティの設定」も参照してください。ここで説明する内容は次のとおりです。

コアコンポーネント間の SSL

Identity Synchronization for Windows のインストールプログラムは、コアのインストール時に指定された SSL ポートが正しいかどうかを検証できません。コアのインストール時に誤った SSL ポート番号を指定した場合、コアコンポーネントは正しく通信できません。設定を最初に保存するときまで、この問題に気がつかない可能性があります。コンソールには、次の警告が表示されます。

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/2003:14:02:48.911 -0600] WARNING 14  CNN100 host1  "failed to open connection to ldaps://host2.airius.com:636."

コンソールを開き、「拡張セキュリティオプションの指定」パネルを調べます (詳細情報を参照)。

信頼されない証明書

セントラル監査ログでは、これ以上の情報を確認できます。たとえば、LDAP サーバーの SSL 証明書が信頼されていない場合は、次のようなメッセージが記録されます。

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

ほとんどの場合は、コネクタの証明書データベースに CA 証明書が追加されていないことが原因です。これは、Directory Server に付属する certutil プログラムを実行することで確認できます。2

注

SUNWtlsu パッケージには、Directory Server にバンドルされていない certutil などの証明書管理ユーティリティが含まれます。このパッケージは、Sun Microsystems のサイトから無償でダウンロードできます。

このパッケージをダウンロードすると、次の場所に certutil が保存されます。

/usr/sfw/bin/certutil

次に、証明書データベースに証明書がひとつも含まれていない場合の例を示します。3

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

airius.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,,」である必要があります。証明書が存在し、信頼性フラグが正しく設定されていても、コネクタが接続できない場合は、まず、証明書の追加後にコネクタを再起動したことを確認し、問題の診断のために Sun Java System Directory Server に付属する 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.)

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

ホスト名のミスマッチ

すべての証明書を信頼する設定を無効にした状態で Identity Synchronization for Windows が SSL 接続を確立しようとすると、Identity Synchronization for Windows のコネクタは、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=*)"

コマンド行に指定したホスト名 (host2.example.com) と、証明書に埋め込まれたホスト名が一致しない場合は、次のエラーメッセージが出力されます。

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/2003:14:06:47.130 -0600] INFO    20  CNN100 host1  "failed to open connection to ldaps://host2.airius.com:636, error(91): Cannot connect to the LDAP server, reason: SSL_ForceHandshake failed: (-8181) Peer's Certificate has expired."

この場合は、サーバーは新しい証明書の発行を受ける必要があります。

Directory Server プラグインと Active Directory の間の SSL

デフォルトでは、オンデマンドパスワード同期の実行時に Directory Server は Active Directory と SSL 経由で通信しません。この通信を SSL で保護するためにデフォルトの設定を変更したときは、第 11 章「セキュリティの設定」で説明するように、各マスターレプリカの Directory Server 証明書データベースに Active Directory CA 証明書を追加する必要があります。この証明書が追加されていない場合、「DSA is unwilling to perform.」というエラーが出力され、ユーザーは Directory Server へのバインドに失敗します。プラグインのログ (たとえば isw-<hostname>/logs/SUBC100/pluginwps_log_0.txt) には、次のようなエントリが記録されます。

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

このような場合は、Directory Server の証明書データベースに Active Directory CA 証明書を追加し、Directory Server を再起動します。

コントローラの問題に関するトラブルシューティング

Active Directory ドメインコントローラをバックアップファイルから復元した場合、一部のカウンタはリセットされません。

すべてのカウンタを正しくリセットするには、Active Directory ドメインコントローラの復元後にすべてのユーザーを再同期させます。



前へ      目次      索引      次へ     

Part No: 817-7846   Copyright 2004 Sun Microsystems, Inc. All rights reserved.