本文へジャンプ

TAM問題判別の小部屋

Tivoli Access Manager for e-business version 5.1 及び関連ソフトウェアをお使いいただく中で問題が発生した場合の対処方法を ログ・トレースの取得方法などを中心に説明します。

目次

マニュアル・参考Webサイト

上に戻る

マニュアルには説明されていないオプション


round-trip-test-lcp

これはwebseald-<instance>.conf のオプションです。使い方については、『事例 - 1 同一字形文字に対するコードポイントによる問題』を参照してください。

intra-connection-timeout

これは TAM4.1 FP09 で追加された webseald-<instance>.conf のパラメーターですが、TAM5.1 WebSEAL のマニュアルには記述がありません。

TAM4.1 FP09 Readmeの原文 7.12 Clarification of Client Connection Time-outs (IY47304, IY48098)

The webseald.conf file declares two parameters for controlling time-outs
on client connections but does not describe their significance.  The fix
 to IY48098 adds a third, optional, time-out parameter.  These parameters 
and their meanings are as follows:
 
    client-connect-timeout
        This value is used to time-out the initial read when an accept()
        succeeds, signifying a new connection from a client.  If the
        first message from the client does not arrive within 
        client-connect-timeout seconds then the connection is dropped.
        
    persist-con-timeout
        This value is used to time-out the initial read when attempting
        to reuse a connection after a reply has been sent to a client.
        If another request arrives from the same client within persist-con-
        timeout seconds after the reply has been sent, then the same connec-
        tion will be reused.  This is particularly significant in the case
        of SSL connections as no key renegotiation is needed.
        
    intra-connection-timeout
        This optional parameter is introduced in the fix to IY48098.  Its
        default value is the value of the client-connect-timeout parameter.
        Its value is used to time-out all read/write operations for an SSL
        client connection (and all read operations for a TCP client connection)
        after the initial read.  If such a read or write gets timed-out, then
        a hard close is performed on the connection and a RST packet is sent
        to the client.
        
Note that the effective values of the first two parameters are adjusted down
based on the load (the percent of the total number of the allowed threads that
are active).  Under extreme loads they are reduced to zero, preventing new
connections from being accepted.  Once an SSL client connection is established,
the full value of the intra-connection-timeout parameter is used on all 
subsequent read/write operations.  Once a TCP client connection is established,
the full value of the intra-connection-timeout parameter is used on all 
subsequent read operations.  Write operations on a TCP client connection are 
not timed-out.

上に戻る

各種設定方法


UTF-8の問題に対するトレースの使用法

WebSEAL URLトレース
URLのエンコード関係の問題での有効な問題判別資料として、 pdadmin server task のURLトレースがあります。実行方法は以下の通りです。 

pdadmin>server task <webseald-instance> trace set
 pdweb.url 4 file path=<ファイル名>

上記のコマンドを実行すると、 <ファイル名>に次のような情報が含まれるトレースが生成されます。

TAM 5.1ではURLのエンコーディングは以下のように行われます。
UTF-8でない場合、内部的にUTF-8に変換し、再度ローカル・コード・ページに変換して、元のキャラクターと比較します。
WebSEALがマルチバイトのキャラクター（エンコーディング）を受け取った後、まずUTF-8であるかを判断します。
ここで比較に成功したらvalidとみなします(round-trip-test)。
上記のURLトレースは、round-trip-test のどの過程で問題が発生しているかを知る手がかりになるかもしれません。

WebSEAL snoop トレース
IPトレースの代わりにWebSEALで提供されている snoop トレースを用いて問題が起きているURLを特定する方法があります。 pdadminにログインし, 下記のコマンドを実行します。

pdadmin>server task <webseald-instance> trace set
 pdweb.snoop 2 file path=/tmp/<ファイル名>

結果は, /tmp/<ファイル名>に次のようなトレース出力されます。

snoop.txt

snoopトレースを利用するとSSL(https)による通信を暗号化されずに取得することができます。
IPトレースによるSSL通信の解析は、暗号化されたデータを復号する必要があります。

UTF-8関連の問題事例

事例 - 1 同一字形文字に対するコードポイントによる問題
WebSEALはリクエストでのURLや引数(?以降)でのエンコーディングに対しては, UTF-8とローカル・コードページ以外のエンコーディングは無効とみなします。
また、IBM日本語文字コード・ページ943にはMicrosoft社の日本語文字セットとの互換性を維持するために、83文字のNEC選定文字、および374文字のNEC IBM選定文字が、従来のIBM日本語文字コード・ページ932に追加されています。これらの83文字のNEC選定文字のうち22文字は, 同じ字形のものが、JIS文字またはIBM選定文字が定義されている領域にも定義されており、このような二重定義文字の優先順位は以下の通りです。

  1. JISのコードポイント
  2. IBM 拡張文字のコードポイント
  3. NEC 選定文字のコードポイント

ローマ数字等はNEC選定文字とIBM選定文字間での重複文字領域に入っています。

IBM-943ででは,同一字形文字に対するコードポイントの選択順位がNEC選定文字よりIBM選定文字のほうが高いために発生する問題があります。例えば、ローマ数字?を Windows 環境から AIX に送った場合、Windows が 0x8754 で送っているものが AIXで0xFA4A とマッピングされてしまい、AIX 上の WebSEAL はこれを無効なエンコードとみなして、Bad Request がWindows に返されます。
この場合、webseald-<instance>.conf に "round-trip-test-lcp"パラメーターを設定する事で、round-trip-test を行わせない事が可能です。

[server] 
round-trip-test-lcp = no

このパラメーターはマニュアルには記述されていませんし、デフォルトのwebseald-<instance>.confにも記載がありません。記述が無い場合、round-trip-test-lcp = yes と扱われます。
AM 4.1以前では local codeでのバイトシークエンスのみを上記の問題は発生しません。

事例- 2　 non-shortest文字列による問題
UTF-8 では文字を表現するのに最も短いバイト列のみが使用できます。　この規則によって生じる問題の例を説明します。
UCS-2 から UTF-8へは以下の表によって変換されます。

w、x、y、z は文字コードの2進数ビット表現です。
Shift_JIS半角カナ文字列「タカハシ」のビット列は次の通りですが、これUTF-8の判定に入力された場合を考えます。

11000000 10110110 11001010 10111100

このビット列をUTF-8で解釈すると最初の16ビットは、上の表の2バイト表現UTF-8の形式で、UCS-2 に戻してみると次の通りです。

11000000 10110110 -> 110xxxxx 10yyyyyy -> U+0036

次の16ビットも同様に2バイトUTF-8です。

11001010 10111100 -> 110xxxxx 10yyyyyy -> U+02bc

ここで、最初の16ビットに注目すると、U+0036 は UCS から UTF-8 への変換では1バイトの 36 に変換されるべきビット列です。このように最短表現ではない (Non-shortest) 文字列は、WebSEALがセキュリティー上の理由でBad Requestを返す場合がありますので、半角文字の使用には注意が必要です。

バックアップでの注意点

pdbackup コマンドでは、/opt/PolicyDirector/etc/pdbackup.lst、/opt/pdweb/etc/amwebbackup.lst に記述されているファイルのみがバックアップされます。Fsso.conf などこのリストに無いファイルはリストに追加するか別途バックアップが必要です。

次ページへ

上に戻る