セキュリティーのためのシングル・サインオン構成のトラブルシューティングのヒント
WebSphere® Application Server と Lotus Domino Server 間のシングル・サインオン (SSO) 構成中に、 いくつかの共通問題が発生する場合があります。 このような問題としては、Lotus Domino Web SSO 構成の保存の失敗、 保護リソースへのアクセス中の認証障害、および保護リソースへのアクセス中の SSO 障害などがあります。 なんらかのアクションを行って、これらのエラー状態を訂正して SSO を復元することができます。
- Lotus Domino Web SSO 構成文書の保存に失敗します。
クライアントは、 接続している SSO Lotus Domino Server の Lotus Domino Server 文書を検出できなければなりません。Web SSO 構成文書は、ユーザーが指定するサーバーに対して暗号化されています。 クライアントのロケーション・レコードによって示されているホーム・サーバーは、 接続しているサーバーのある Lotus Domino ドメイン内のサーバーを指している必要があります。 このポインターにより、検索でサーバーの公開鍵が確実に検出されます。
接続している Lotus Domino Server を 1 つも検出できないというメッセージを受信する場合、 それらのサーバーは、Web SSO 構成文書を暗号化解除できず、SSO も実行できません。
Web SSO 構成文書が保存される際、ステータス・バーは、文書にリストされたサーバー、 作成者、および管理者を検出することによって、文書の暗号化に使用された公開鍵の数を示します。
- Lotus Domino Server コンソールが Lotus Domino HTTP Server の始動時に Web SSO 構成文書のロードに失敗します。
SSO の構成時に、サーバー文書は、「Session Authentication」フィールドでマルチサーバーに対して構成されます。Lotus Domino HTTP Server は、 始動時に Web SSO 構成文書の検索とロードを試行します。 有効な文書が検出され、暗号化解除された場合、Lotus Domino Server コンソールは、次の情報を報告します: HTTP: Successfully loaded Web SSO Configuration
サーバーが Web SSO 構成文書をロードできない場合は、SSO は機能しません。 この場合、サーバーは、次のメッセージを報告します。HTTP: Error Loading Web SSO configuration. Reverting to single-server session authentication.
Lotus Domino ディレクトリーの「Web Configurations」ビュー および「$WebSSOConfigs」隠しビューに、Web SSO 構成文書が 1 つしか存在しないことを確認してください。 資料を複数作成することはできませんが、複製時に追加の資料を挿入することはできます。
Web SSO 構成文書を 1 つしか検証できない場合は、別の条件を検討してください。 サーバー文書の公開鍵が ID ファイル内の公開鍵と一致しない場合は、同じエラー・メッセージが表示されます。 この場合、Web SSO 構成文書を暗号化解除しようとすると失敗し、エラー・メッセージが生成されます。
この状態は、ID ファイルが複数回作成されたものの、Server 資料が正常に更新されていない場合に発生することがあります。 通常は、公開鍵がサーバー ID と一致しないという エラー・メッセージが Lotus Domino Server コンソール上に表示されます。 この状態が発生した場合、SSO は機能しません。これは、文書が公開鍵で暗号化されており、 サーバーはその公開鍵に対応する秘密鍵を持っていないためです。
鍵の不一致の問題を修正するには、以下のようにします。- 公開鍵をサーバー ID ファイルからコピーし、それを Server 資料に貼 り付けます。
- Web SSO 構成文書を再度作成します。
- 保護リソースへのアクセス時に認証が失敗します
Web ユーザーに対し、 ユーザー ID とパスワードを要求するプロンプトが何度も表示される場合は、SSO が機能していません。 これは、Lotus Domino または WebSphere Application Server のセキュリティー・サーバーの どちらかが、Lightweight Directory Access Protocol (LDAP) サーバーのユーザーを認証できないためです。 以下の点をチェックしてください。
- LDAP サーバーが Lotus Domino Server マシンからアクセス可能であることを検査します。 TCP/IP ping ユーティリティーを使用して TCP/IP 接続を検査し、 ホスト・マシンが稼働していることを確認します。
- LDAP ユーザーが LDAP ディレクトリー内で定義されていることを検査します。
idsldapsearch ユーティリティーを使用して、
ユーザー ID が存在していること、およびパスワードが正しいことを確認します。例えば、
以下のコマンドを単一の行に入力して実行できます。
OS/400® Qshell、UNIX シェル、 または Windows DOS プロンプトを使用できます。
パーセント文字 (%) は、プロンプトを表しています。コマンドの一部ではありません。 ディレクトリー・エントリーのリストが表示されます。 発生する可能性があるエラー状態および原因は、以下のリストのとおりです。% ldapsearch -D "cn=John Doe, ou=Rochester, o=IBM, c=US" -w mypassword -h myhost.mycompany.com -p 389 -b "ou=Rochester, o=IBM, c=US" (objectclass=*)
- 「No such object」: このエラーは、-D オプションに続いて指定された ユーザーの識別名 (DN) 値、または -b オプションに続いて指定された 基本 DN 値のいずれかによって参照されたディレクトリー・エントリーが 存在しないことを示します。
- 「Credentials that are not valid」: このエラーは、パスワードが有効でないことを示します。 is not valid.
- 「Cannot contact the LDAP server」: このエラーは、 サーバーに対して指定されたホスト名またはポートが有効でないか、 あるいは LDAP サーバーが稼働していないことを示します。
- 空のリストは、-b オプションで指定した基本ディレクトリーがディレクトリー・エントリーを含んでいないことを意味します。
- 識別名の代わりにユーザーのショート・ネームまたはユーザー ID を使用している場合は、 ディレクトリー・エントリーがショート・ネームで構成されていることを確認します。 Lotus Domino ディレクトリーの場合、Person 文書の「Short name/UserID」フィールドを検査します。他の LDAP ディレクトリーの場合、ディレクトリー・エントリーのユーザー ID プロパティーを検査します。
- Lotus Domino ディレクトリー以外の LDAP ディレクトリーを
使用しているときに、Lotus Domino 認証が失敗する場合は、Directory アシスタンス・データベース内にある
Directory アシスタンス文書の LDAP サーバーの構成設定値を確認します。
また、Server 文書が、正しい Directory アシスタンス文書を参照しているかどうかについても検査します。
以下に示す、Directory アシスタンス文書内で指定された LDAP 値は、WebSphere Application Server 管理可能ドメイン内のユーザー・レジストリーに対して指定された値と一致する必要があります。
- ドメイン・ネーム
- LDAP ホスト名
- LDAP ポート
- 基本 DN
以下の行をサーバーの notes.ini ファイルに追加することによって、LDAP サーバーに対する Lotus Domino Server の要求をトレースすることができます。
Lotus Domino Server を再始動した後は、Web ユーザーが Lotus Domino Server に対して認証を試行するときに、 トレース・メッセージが Lotus Domino Server のコンソールに表示されます。webauth_verbose_trace=1
- 保護リソースへのアクセス時に許可が失敗します
正常に認証された後に、許可エラー・メッセージが表示される場合は、 セキュリティーが正しく構成されていません。 以下の点をチェックしてください。
- Lotus Domino データベースの場合、ユーザーがデータベースのアクセス制御の設定で定義されていることを検査します。 ユーザーの DN を指定する正しい方法については、Lotus Domino 管理資料を参照してください。 例えば、DN cn=John Doe, ou=Rochester, o=IBM, c=US の場合、アクセス制御リストの値は John Doe/Rochester/IBM/US に設定されていなければなりません。
- WebSphere Application Server によって保護されているリソースの場合、
セキュリティー権限が正しく設定されていることを検査します。
- 選択されたグループに許可を与えている場合は、 リソースにアクセスしようとしているユーザーがそのグループのメンバーであることを確認してください。 例えば、ディレクトリーの内容を表示する以下の Web サイトを使用して、グループのメンバーを検査できます。Ldap://myhost.mycompany.com:389/ou=Rochester, o=IBM, c=US??sub
- 許可の設定以降に、WebSphere Application Server 管理ドメイン内で LDAP 構成情報 (ホスト、ポート、 および基本 DN) を変更した場合は、既存の許可はおそらく有効でないため、 再作成の必要があります。
- 保護リソースへのアクセス時に SSO が失敗します
Web ユーザーに対して、リソースごとに認証のプロンプトが表示される場合 は、SSO が正しく構成されていません。 以下の点をチェックしてください。
- WebSphere Application Server と Lotus Domino Server の両方が、 同じ LDAP ディレクトリーを使用するように構成します。SSO に使用される HTTP Cookie には、ユーザーの完全 DN (cn=John Doe, ou=Rochester, o=IBM, c=US など) およびドメイン・ネーム・サービス (DNS) ドメインが保管されます。
- Lotus Domino ディレクトリーが使用されている場合、階層名に基づいて Web ユーザーを定義します。 例えば、Person 文書の「ユーザー名」フィールドを更新して、この形式の名前を John Doe/Rochester/IBM/US のように最初の値として組み込みます。
- SSO 用に構成された Lotus Domino Server および WebSphere Application Server に対して発行される Web サイトには、 単にホスト名や TCP/IP アドレスを指定するのではなく、完全な DNS サーバー名を指定します。 ブラウザーがサーバーのグループに Cookies を送信するためには、DNS ドメインが Cookies に組み込まれていて、その Cookies 内の DNS ドメインが Web アドレスに一致する必要があります。 TCP/IP ドメイン間で Cookie を使用できないため、この要件があります。
- Lotus Domino と WebSphere Application Server の両方が、同じ DNS ドメインを使用するように構成します。 DNS ドメイン値が、大文字化も含めて完全に同じであることを検査してください。 WebSphere Application Server が構成されている DNS ドメインの名前が必要です。 詳しくは、 LTPA Cookies を使用した認証のためのシングル・サインオンを参照してください。
- クラスター化された Lotus Domino Server のサーバー文書で、ホスト名に完全な DNS サーバー名が指定されていることを確認します。
Domino Internet Cluster Manager (ICM) は、
完全な DNS サーバー名を使用して、SSO を使用するクラスター・メンバーにリダイレクトします。
このフィールドが移植されていない場合、デフォルトで ICM は、サーバーのホスト名のみを
使用して、Web アドレスをクラスター化された Web サーバーにリダイレクトします。
ICM は SSO Cookie を送信できません。これは、DNS ドメインが Web アドレスに組み込まれていないためです。
この問題を訂正するには、以下のようにします。
- Server 資料を編集します。
- とクリックします。
- サーバーの完全 DNS 名を「ホスト名」フィールドに入力します。
- LDAP サーバーのポート値が WebSphere Application Server 管理可能ドメインに対して指定される場合は、Lotus Domino Web SSO 構成文書を編集し、「LDAP Realm」フィールドの値のコロン記号 (:) の前に円記号 (¥) を挿入してください。例えば、myhost.mycompany.com:389 を myhost.mycompany.com¥:389 で置き換えます。
- HTTP セッションのタイマーが期限切れになると、ユーザーがログアウトされません。
WebSphere Application Server のユーザーがアプリケーションにログオンし、指定された HTTP セッション・タイムアウト値より長い時間アイドル状態であった場合、ユーザー情報は無効にならず、LTPA トークンがタイムアウトになるまでユーザー・クレデンシャルはアクティブのままです。
PK25740 の適用後、以下のステップを実行すると、HTTP セッションが期限切れとなった後にユーザーをアプリケーションからログアウトさせることができます。重要: com.ibm.ws.security.web.logoutOnHTTPSessionExpire プロパティーは、フォーム・ログインを使用しているアプリケーションにのみ適用されます。- 管理コンソールで、「セキュリティー」>「グローバル・セキュリティー」とクリックします。
- 「カスタム・プロパティー」の下で、「新規」をクリックします。
- 「名前」フィールドに、com.ibm.ws.security.web.logoutOnHTTPSessionExpire と入力します。
- 「値」フィールドに true と入力します。
- 「適用」および「保存」をクリックして、構成の変更を保存します。
- サーバーを再同期して再始動します。
予期しない再認証: com.ibm.ws.security.web.logoutOnHTTPSessionExpire カスタム・プロパティーを true に設定すると、複数の Web アプリケーションを操作しているときに予期しない再認証が発生することがあります。デフォルトでは、各 Web アプリケーションには独自の HTTP セッションがありますが、Web ブラウザーが持っているのは 1 つのセッション Cookie です。この問題に対処するには、固有のセッション Cookie 名またはパス設定をアプリケーションそれぞれに与えることによって、HTTP セッション構成を変更できます。 その結果、各アプリケーションは独自のセッション Cookieを持ちます。または、同じ HTTP セッションを共有するよう、同じエンタープライズ・アプリケーションで複数の Web アプリケーションを構成できます。詳しくは、トピック『セッション・データを共有可能にするアセンブル』の説明を参照してください。 - SSO が使用可能で Firefox v3.6.11 がサード・パーティー Cookie を許可するように構成されている場合に問題が発生する可能性があります。
SSO が使用可能になっている場合、Firefox v3.6.11 を使用すると、以下のいずれかの状態になります。
- 有効期限切れになるか Firefox を閉じるまで、保持しているサード・パーティー Cookie を許可するように構成される
- 1 つのセッションが開かれているが、さまざまなアプリケーションに切り替えられている
- それぞれに異なるユーザーの許可が必要な各アプリケーションに対し、複数のセッションが開かれる
次のエラー・メッセージが表示される場合があります。Error 403: AuthorizationFailed。
このエラーを解決するには、新しいアプリケーションを起動する前に、次のようにしてサード・パーティー Cookie をクリアします。- Firefox の を選択します。
- 履歴が「履歴を記憶させる」に設定されていることを確認します。
- 「Cookie を個別に削除」をクリックして Cookie を削除します。
Firefox を閉じるまで、保持しているサード・パーティー Cookie を受け入れるように Firefox が構成されている場合、他のセッションを閉じることもできます。