test

Sun Java System Access Manager 7 2005Q4 リリースノート

Access Manager 7 2005Q4 パッチ 5

Access Manager 7 パッチ 5 (リビジョン 05) により、いくつかの問題が修正されます。その一覧はパッチに含まれている README ファイルに記載されています。パッチ 5 には、次の新機能、問題、および変更されたマニュアルが含まれています。

パッチ 5 での新機能

パッチ 5 での既知の問題点と制限事項

国際化 (g11n) に関する問題

変更されたマニュアル

HP-UX システムのサポート

パッチ 126371 は、HP-UX システムに対するサポートを提供します。詳細については、次のトピックを参照してください。

HP-UX システムへのインストールについては、『Sun Java Enterprise System 2005Q4 インストールガイド(UNIX 版)』を参照してください。

Microsoft Windows システムのサポート

パッチ 124296 は、Windows システムに対するサポートを提供します。詳細については、次のトピックを参照してください。

Windows システムへのインストールについては、『Sun Java Enterprise System 2005Q4 Installation Guide for Microsoft Windows』を参照してください。

LDIF ファイルと XML ファイルを読み込む新しい updateschema.sh スクリプト

パッチ 5 以降のパッチには、次のファイルを読み込んで Directory Server サービススキーマを更新する updateschema.sh スクリプトが含まれています。

Access Manager の以前のリリースでは、これらのファイルを手動で読み込む必要がありました。

updateschema.sh スクリプトを実行するには、次の手順に従います。

  1. スーパーユーザー (root) としてログインします。

  2. パッチディレクトリに移動します。

  3. スクリプトを実行します。Solaris システムの場合の例を示します。

    # cd /120954-07 
# ./updateschema.sh

    Windows システムでは、このスクリプトの名前は updateschema.pl です。

  4. スクリプトからユーザーの入力を要求されたら、次の項目を入力します。

    • Directory Server のホスト名とポート番号

    • Directory Server の管理ユーザー DN とパスワード

    • amadmin DN とパスワード

  5. スクリプトが入力内容を検証し、ファイルを読み込みます。このスクリプトは次のログファイルも書き込みます。

    • Solaris システム: /var/opt/SUMWam/logs/AM70Patch.upgrade.schema. timestamp

    • Linux システム: /var/opt/sun/identity/logs/AM70Patch.upgrade.schema. timestamp

  6. スクリプトの実行が終了したら、Access Manager Web コンテナを再起動します。

注: パッチ 5 をバックアウトした場合、updateschema.sh スクリプトによって追加されたスキーマの変更は Directory Server から削除されません。ただし、パッチをバックアウトしたあとで、これらの変更が Access Manager の機能や使い勝手に影響を与えることはないため、これらの変更を手動で削除する必要はありません。

特定のアプリケーションのアイドルセッションタイムアウト値のサポート

パッチ 5 では、アプリケーションごとに異なるセッションアイドルタイムアウト値を設定できます。企業では、セッションサービスに指定されたセッションアイドルタイムアウトより小さいセッションアイドルタイムアウト値が一部のアプリケーションで必要になる場合があります。たとえば、セッションサービスのセッションアイドルタイムアウト値を 30 分に指定したが、HR アプリケーションはユーザーが 10 分以上アイドル状態だったらタイムアウトするべきである場合などです。

この機能を使用するための要件は、次のとおりです。

この機能を使用するには、次の手順に従います。

たとえば次の認証方式条件を持つポリシー http://host.sample.com/hr/* があるとします。

HR アプリケーションのリソースを保護するために定義されたポリシーが複数ある場合は、すべてのポリシーに条件を追加してください。

個別のセッション内のユーザーが Access Manager エージェントによって保護された HR アプリケーションにアクセスしようとすると、そのユーザーは LDAP 方式への認証を要求されます (ユーザーがまだ認証されていない場合)。

ユーザーがすでに LDAP 方式に認証されている場合は、最後に認証が行われた時間またはそのユーザーが HR アプリケーションに最後にアクセスした時間から 10 分以上経過していなければ、そのユーザーにアクセスが許可されます。それ以外の場合は、ユーザーがアプリケーションにアクセスしようとすると、再度 LDAP 方式への認証が要求されます。

CDC サーブレットは、分散認証 UI サーバーに配備できる

DMZ 内で CDC サーブレットと分散認証 UI サーバーを共存させることにより、クロスドメインシングルサインオン (CDSSO) を使用可能にできます。Access Manager サーバーは、ファイアウォールの背後に配備できるため、CDSSO を実現するために行われる Access Manager へのすべてのアクセスは、分散認証 UI サーバー内の CDC サーブレットによって処理されます。CDSSO を使用可能にするには、各ポリシーエージェントのマニュアルを参照し、次の追加手順を実行してください。

CDC サーブレットが Access Manager のログイン URL にリダイレクトされる場合はレルムを指定できる

CDC サーブレットに対してレルム名を指定すると、Access Manager のログイン URL へのリダイレクトが発生したときにレルム名が取り込まれ、ユーザーは特定のレルムにログインできます。次に例を示します。

com.sun.am.policy.agents.config.cdcservlet.url=
    http://lb.example.com/amserver/cdcservlet?org=realm1

証明書認証でユーザープロファイルのマッピングに UPN 値を使用できる

従来の証明書認証では、ユーザープロファイルをマップするために subjectDN の dn コンポーネントだけが使用されていました。現在の Access Manager では、プロファイルのマッピングに SubjectAltNameExt のユーザー主体名 (UPN) の値を使用できます。

複数サーバー環境でログアウトの認証ポストプロセスが発生する

複数サーバー環境で、ユーザーが最初にログインしたサーバーとは別のサーバーをログアウトすると、セッションフェイルオーバーが設定されているかどうかに関係なく、認証ポストプロセスが発生します。

SAML による新しい名前 ID SPI のサポート

SAML は、サイトが SAML 表明に含まれる名前 ID をカスタマイズできるように、新しい名前 ID サービスプロバイダインタフェース (SPI) をサポートします。サイトは、新しい NameIdentifierMapper インタフェースを実装することにより、ユーザーアカウントを SAML 表明の対象に含まれる名前 ID にマップできます。

サイト監視の新しい設定プロパティー

Access Manager のサイト監視機能に、サイト状態チェックの動作を指定できる次の新しいプロパティーが追加されています。

プロパティー 

説明 

com.sun.identity.urlchecker.invalidate.interval

停止したサイトや無応答のサイトを認識するための時間間隔 (ミリ秒単位)。 

デフォルト: 70000 ミリ秒 (70 秒)。 

com.sun.identity.urlchecker.sleep.interval

サイト状態チェックをスリープさせる間隔 (ミリ秒単位)。 

デフォルト: 30000 ミリ秒 (30 秒)。 

com.sun.identity.urlchecker.targeturl

Access Manager のプロセスステータスを確認するための別のターゲット URL。 

デフォルト: "/amserver/namingservice".

パッチでは、これらのプロパティーは AMConfig.properties ファイルに追加されません。これらの新しいプロパティーをデフォルト値以外の値で使用するには、次の手順に従います。

  1. AMConfig.properties ファイルにプロパティーとその値を追加します。ポリシーエージェントの場合は、これらのプロパティーを AMAgents.properties ファイルに追加します。

  2. Access Manager Web コンテナを再起動して、値を有効にします。

ユーザーは認証チェーンで 2 回認証する必要がない

たとえば、次のような場合です。サイトに、3 つの LDAP モジュールを使用して認証チェーンが設定されています。すべてのモジュールが SUFFICIENT に設定され、iplanet-am-auth-shared-state-enabled オプションと iplanet-am-auth-store-shared-state-enabled オプションがどちらも true に設定されています。次に例を示します。

<AttributeValuePair>
   <Value>A-LDAP SUFFICIENT iplanet-am-auth-shared-state-enabled=true
iplanet-am-auth-store-shared-state-enabled=true</Value>
   <Value>B-LDAP SUFFICIENT iplanet-am-auth-shared-state-enabled=true
iplanet-am-auth-store-shared-state-enabled=true</Value>
   <Value>C-LDAP SUFFICIENT iplanet-am-auth-shared-state-enabled=true
iplanet-am-auth-store-shared-state-enabled=true</Value>
</AttributeValuePair>

パッチ 5 では、新しいモジュールオプションとして iplanet-am-auth-shared-state-behavior-pattern オプションが追加されます。このオプションに指定できる値は、 tryFirstPass (デフォルト) と useFirstPass の 2 つです。

ユーザーが (前のシナリオに示したように) 認証を受けるためにユーザー ID とパスワードを 2 回入力しなければならない状況を避けるには、チェーン内のすべてのモジュールで、この新しいオプションを useFirstPass に設定します。従来は、3 番目の LDAP インスタンスにしか存在しないユーザーは、認証を受けるために、ユーザー ID とパスワードを 2 回入力する必要がありました。

パフォーマンスチューニングスクリプトの変更

パッチ 5 には、パフォーマンスチューニングスクリプトに対する次の変更が含まれています。

「CR# 6527663: com.sun.identity.log.resolveHostName プロパティーのデフォルト値を true ではなく false にする」も参照してください。

チューニングスクリプトによるパスワードファイルのサポート

パッチ 5 では、チューニングスクリプトのパスワードをテキストファイルで指定できます。従来は、コマンド行引数としてパスワードを入力するしかなく、セキュリティー上の問題がありました。パスワードファイルを使用するには、必要に応じて次の変数をパスワードファイルに設定します。

DS_ADMIN_PASSWORD=DirectoryServer-admin-password
AS_ADMIN_PASSWORD=ApplicationServer8-admin-password

たとえば、Application Server 8 を調整する場合は、次のようにします。

# ./amtune-as8 password-file

password-file には、Application Server 8 の管理者パスワードに設定された AS_ADMIN_PASSWORD が含まれます。

チューニングスクリプトは、Directory Server の ldapmodify、ldapsearch、db2index、および dsconf ユーティリティーを呼び出すときに、-j password-file オプションを使用します。

チューニングスクリプトで Directory Server から不要な ACI を削除する

Access Manager 7 2005Q4 がレルムモードでインストールされている場合は、委譲権限を使用してアクセス権が決定されるため、一部の Directory Server ACI が不要です。Access Manager 7 2005Q4 パッチ 5 では、amtune-prepareDSTuner スクリプトを実行することにより、不要な ACI を削除できます。このスクリプトは、remacis.ldif ファイルから ACI のリストを読み取り、ldapmodify ユーティリティーを呼び出してそれらの ACI を削除します。

amtune-prepareDSTuner スクリプトを実行して、Solaris、Linux、HP-UX、および Windows システム上の不要な ACI を削除できます。スクリプトの実行方法を含む詳細は、『Technical Note: Sun Java System Access Manager ACI Guide』を参照してください。

チューニングスクリプトで分散認証 UI サーバー Web コンテナを調整できる

分散認証 UI サーバーを Web コンテナに配備したあと、Access Manager のチューニングスクリプトを実行することにより、Web コンテナを調整できます。次の表に示すチューニングスクリプトは、該当する Web コンテナの JVM やその他のチューニングオプションを設定します。

表 2 Access Manager Web コンテナのチューニングスクリプト

Web コンテナ 

チューニングスクリプト 

amtune-ws61

Web Server 6.1 

amtune-as7

Application Server 7 

amtune-as8

Application Server Enterprise Edition 8.1 

分散認証 UI サーバーの Web コンテナを調整するには、次の手順に従います。

  1. 分散認証 UI サーバーが配備されているシステムには Access Manager サーバーがインストールされていないため、(上の表に示した) 該当する Web コンテナのチューニングスクリプト、amtune-env 設定ファイル、および amtune-utils スクリプトを Access Manager サーバーインストールからコピーします。Solaris または Linux オペレーティングシステムを調整する場合は、amtune-os スクリプトもコピーします。

  2. amtune-env 設定ファイルのパラメータを編集して、Web コンテナとチューニングのオプションを指定します。スクリプトを REVIEW モードで実行するため、amtune-env ファイルに AMTUNE_MODE=REVIEW を設定します。

  3. Web コンテナのチューニングスクリプトを REVIEW モードで実行します。REVIEW モードでは、スクリプトは amtune-env ファイルの値に従ってチューニングによる変更箇所を示しますが、配備に対する実際の変更は行いません。

  4. デバッグログファイルで、推奨されるチューニングを確認します。必要な場合は、この実行結果に基づいて amtune-env ファイルに変更を加えます。

  5. チューニングによる変更を行うため、amtune-env ファイルに AMTUNE_MODE=CHANGE を設定します。

  6. チューニングスクリプトを CHANGE モードで実行し、配備に対してチューニングによる変更を行います。

チューニングスクリプトを実行して Access Manager Web コンテナを調整する方法の詳細は、『Sun Java System Access Manager 7 2005Q4 Performance Tuning Guide』の第 2 章「Access Manager Tuning Scripts」を参照してください。

amtune-os スクリプトだけで Solaris OS と Linux OS の両方を調整する

パッチ 5 には、Solaris OS と Linux OS の両方を調整する amtune-os スクリプトが含まれています。このスクリプトは、uname -s コマンドの結果から OS の種類を判定します。従来の Access Manager には、各 OS を調整するために別々の amtune-os スクリプトが用意されていました。

Solaris 10 のローカルゾーンでもチューニングスクリプトが最後まで実行される

Solaris 10 のローカルゾーンに Access Manager がインストールされている場合は、amtune-os 以外のすべてのチューニングスクリプトをローカルゾーンで実行できます。amtune-os スクリプトは、ローカルゾーンでは警告メッセージを表示し、OS のチューニングを行いません。その後、要求されたほかのチューニングスクリプトの実行を継続します。従来は、ローカルゾーンでは、amtune-os スクリプトは中断し、要求された後続のチューニングスクリプトは実行されませんでした。

Solaris 10 の大域ゾーンでは、amtune スクリプトが実行を要求されたほかのスクリプトとともに amtune-os を呼び出して OS を調整します。

Windows システムで使用できるチューニングスクリプト

パッチ 5 には、Windows システム用のチューニングスクリプトが含まれています。Windows システムでのチューニングスクリプトの実行は、Solaris システムや Linux システムでの実行とほぼ同じですが、次のような違いがあります。

Sun Fire T1000 および T2000 サーバーのチューニングに関する注意点

Access Manager が Sun Fire T1000 または T2000 サーバーにインストールされている場合、パッチ 5 の Web Server 6.1 および Application Server 8 用のチューニングスクリプトは、JVM GC ParallelGCThreads パラメータを 8 に設定します。

-XX:ParallelGCThreads=8

このパラメータは、32 スレッドを実行可能なシステムでは不必要に多い可能性があるガベージコレクションスレッドの数を減らします。ただし、Sun Fire T1000 または T2000 サーバーなどの 32 仮想 CPU マシンで、フルガベージコレクションのアクティビティーが最小限に抑えられている場合は、この値を 16 - 20 まで増やすことができます。

また、CoolThreads テクノロジによる CMT プロセッサを搭載した Solaris SPARC システムでは、/etc/opt/SUNWam/config/AMConfig.properties ファイルの末尾に次のプロパティーを追加することをお勧めします。

com.sun.am.concurrencyRate=value

value のデフォルトは 16 ですが、Sun Fire T1000 または T2000 サーバーのコア数に応じて、このプロパティーをさらに小さい値に設定できます。

IIS 6.0 ポリシーエージェントの基本認証

Microsoft Internet Information Services (IIS) 6.0 の基本認証を有効にするには、ポリシーエージェントがユーザーの名前とパスワードを取得する必要があります。パッチ 5 には、ユーザーのパスワードの DES 暗号化を使用してこの機能を有効にする次の新しいクラスが含まれています。

IIS 6.0 の基本認証を使用するには、Access Manager サーバー側と IIS 6.0 ポリシーエージェント側の両方の手順を実行する必要があります。

Access Manager サーバー側では、次の手順に従います。

  1. DESGenKey.java を実行して、パスワードの暗号化と復号化に使用する一意の暗号化鍵を生成します。DESGenKey.java ファイルは、Solaris システムでは /opt/SUNWam/lib ディレクトリの am_sdk.jar に含まれている com/sun/identity/common ディレクトリの下にあります。たとえば、次のコマンドで暗号化鍵を生成します。

    # cd /opt/SUNWam/lib
# java -cp am_sdk.jar com.sun.identity.common.DESGenKey

  2. 手順 1 で得られた暗号化鍵を AMConfig.properties ファイルの com.sun.am.replaypasswd.key プロパティーに割り当てます。

  3. ReplayPasswd.java を認証後プラグインとして配備します。プラグインを設定するときは、次のように完全なクラス名を使用します。 com.sun.identity.authentication.spi.ReplayPasswd

IIS 6.0 ポリシーエージェント側では、次の手順に従います。

  1. サーバー側で得られた暗号化鍵の値を AMAgent.properties ファイルの com.sun.am.replaypasswd.key プロパティーに割り当てます。Access Manager サーバーと IIS 6.0 ポリシーエージェントの両方で同じ暗号鍵を使用してください。

  2. IIS 6.0 マネージャーで、基本認証を有効にします。

IIS 6.0 ポリシーエージェントがセッションの応答から暗号化されたパスワードを読み取り、com.sun.am.replaypasswd.key プロパティーからパスワードを復号化し、認証ヘッダーを設定することにより、基本認証の実行が可能になります。

IIS 6.0 ポリシーエージェントについては、『Sun Java System Access Manager Policy Agent 2.2 Guide for Microsoft Internet Information Services 6.0』を参照してください。

CR# 6567746: HP-UX システムでパスワード再試行回数を超過した場合、Access Manager パッチ 5 は間違ったエラーコード値を報告する

ユーザーのアカウントがロックされている場合、パスワード再試行回数を超過すると、HP-UX システムの Access Manager 7 2005Q4 パッチ 5 は errorCode = 107 ではなく errorCode = null を報告します。

回避方法: なし。

CR# 6527663: com.sun.identity.log.resolveHostName プロパティーのデフォルト値を true ではなく false にする

amtune-identity チューニングスクリプトを実行する前に、false に設定した次のプロパティーを AMConfig.properties ファイルに追加することをお勧めします。

com.sun.identity.log.resolveHostName=false

値を false にすることで、ホスト名解決の負担が最小限に抑えられ、パフォーマンスが向上します。ただし、クライアントマシンのホスト名を amAuthentication.access ログに出力する場合は、この値を true に設定してください。

CR# 6527528: パッチを削除すると、クリアテキスト形式の amldapuser パスワードを含む XML ファイルが残る

Access Manager のフルサーバーインストールからパッチ 5 を削除すると、amAuthLDAP.xml ファイルと amPolicyConfig.xml ファイルに、クリアテキスト形式の amldapuser パスワードが含まれています。これらのファイルは、使用中のプラットフォームに応じて、次のディレクトリにあります。

回避方法: amAuthLDAP.xml ファイルと amPolicyConfig.xml ファイルを編集して、クリアテキスト方式のパスワードを削除します。

CR# 6527516: WebLogic 上のフルサーバーでは JAX-RPC 1.0 JAR ファイルがクライアント SDK と通信する必要がある

Access Manager 7 2005Q4 パッチでは、BEA WebLogic Server 用の Access Manager 設定スクリプト (amwl81config) が WebLogic インスタンスの classpath に JAX-RPC 1.1 JAR ファイルを追加します。この変更は Sun Java System Portal Server などの製品には有用ですが、WebLogic Server に配備されたフルサーバーインストール (DEPLOY_LEVEL=1) はクライアント SDK インストールと通信できないため、それ以降は例外が発生します。

Access Manager 7 2005Q4 サーバーが BEA WebLogic Server にインストールされている場合は、startWebLogic.sh スクリプトの CLASSPATH を、Access Manager のクライアント SDK と通信する JAX-RPC 1.0 JAR ファイルの場所に設定する必要があります。

回避方法: Access Manager パッチを適用する前に、WebLogic Server インスタンスが JAX-RPC 1.1 JAR ファイルではなく JAX-RPC 1.0 JAR ファイルを使用するように、startWebLogic.sh スクリプトの CLASSPATH を設定します。

  1. Access Manager サーバーで、スーパーユーザー (root) としてログインするか、スーパーユーザーになります。

  2. startWebLogic.sh スクリプトを編集し、JAX-RPC 1.0 JAR ファイルを使用するように CLASSPATH を置き換えます。次に例を示します。

現在の値:

CLASSPATH=/etc/opt/SUNWam/config:
AccessManager-base/AccessManager-package-dir/lib/jax-qname.jar:
AccessManager-base/AccessManager-package-dir/lib/namespace.jar:
AccessManager-base/AccessManager-package-dir/lib/jaxrpc-api.jar:
AccessManager-base/AccessManager-package-dir/lib/jaxrpc-spi.jar:
AccessManager-base/AccessManager-package-dir/lib/jaxrpc-impl.jar:

新しい値:

CLASSPATH=/etc/opt/SUNWam/config:
AccessManager-base/AccessManager-package-dir/lib/jax-qname.jar:
AccessManager-base/AccessManager-package-dir/lib/namespace.jar:
AccessManager-base/AccessManager-package-dir/lib/jaxrpc_1.0/jaxrpc-api.jar:
AccessManager-base/AccessManager-package-dir/lib/jaxrpc-ri.jar:

AccessManager-base は、ベースインストールディレクトリです。デフォルト値は、Solaris システムでは /opt、Linux システムおよび HP-UX システムでは /opt/sun です。AccessManager-package-dir は、Access Manager のパッケージディレクトリです。

5. WebLogic Server インスタンスを再起動します。

CR# 6523499: パッチ 5 の amsilent ファイルが Linux システム上のすべてのユーザーに対して読み込み可能になっている

Linux システムでは、postpatch スクリプトは、すべてのユーザーに読み取りアクセスを許可する 644 のアクセス権で /opt/sun/identity/amsilent ファイルを作成します。

回避方法: installpatch スクリプトを実行したあとで、所有者だけに読み取りと書き込みのアクセスを許可するように amsilent ファイルのアクセス権を変更します。次に例を示します。

# chmod 600 /opt/sun/identity/amsilent

CR# 6520326: 同じサーバー上の 2 つめの Access Manager インスタンスにパッチ 5 を適用すると、1 つめのインスタンスの serverconfig.xml が上書きされる

この配備シナリオでは、2 つの Access Manager インスタンスが同じホストサーバーに配備され、各インスタンスは異なる Web コンテナインスタンス上にあります。次の手順を実行します。

  1. パッチ 5 を適用します。

  2. amsilent ファイルを変更し、1 つめの Access Manager インスタンスを再配備します。

  3. 2 つめの Access Manager インスタンスのために再度 amsilent を変更し、そのインスタンスを再配備します。

amsilent ファイルに NEW_INSTANCE=false が設定されていると、1 つめの Access Manager インスタンス用の serverconfig.xml ファイルが 2 つめの Access Manager インスタンスの情報で上書きされます。それ以降、1 つめの Access Manager インスタンスの再起動は失敗します。serverconfig.xml ファイルは、使用中のプラットフォームに応じて、次のディレクトリにあります。

回避方法: 2 つめの Access Manager を配備するときに、amsilent ファイルに NEW_INSTANCE=true を設定します。2 つめの Access Manager インスタンス用の serverconfig.xml ファイルが正しい情報で更新され、1 つめの Access Manager インスタンス用の serverconfig.xml ファイルが上書きされません。

CR# 6520016: パッチ 5 の SDK のみのインストールで、samples ディレクトリ内の Makefile が上書きされる

パッチ 5 を SDK のみのマシンに適用すると、samples ディレクトリ内の Makefile が上書きされます。

回避方法: パッチ 5 を SDK のみのマシンに適用するときは再設定の必要はありませんが、samples ディレクトリ内の Makefile を使用する場合は、次の手順に従って samples ディレクトリ内の Makefile の LDIF ファイルとプロパティーファイルを更新します。つまり、タグスワッピングを実行します。

  1. DEPLOY_LEVEL=14 で amconfig スクリプトを実行することにより、SDK をアンインストールして Web コンテナを設定解除します。

  2. DEPLOY_LEVEL=4 で amconfig スクリプトを実行することにより、SDK を再インストールして Web コンテナを再設定します。

CR#6515502: LDAPv3 リポジトリプラグインがエイリアス検索属性を正しく処理しないことがある

ほとんどの検索では、この問題は修正されています。ただし、エイリアス検索属性を設定するときは注意してください。エイリアス検索属性の値を組織内で一意にする必要があります。複数のエイリアス検索属性が設定された場合は、データストア内のあるエントリが一方の属性に一致し、別のエントリがもう一方の属性に一致する可能性があります。このような場合、Access Manager サーバーは次のエラーをスローします。

An internal authentication error has occurred. Contact your system administrator.

回避方法: なし

CR# 6515383: 分散認証と J2EE エージェントが同じ Web コンテナで動作しない

分散認証 UI サーバーと J2EE ポリシーエージェントは、同じ Web コンテナにインストールすると動作しません。

回避方法: 2 つめの Web コンテナインスタンスを作成し、分散認証 UI サーバーと J2EE ポリシーエージェントを Web コンテナの異なるインスタンスに配備します。

CR# 6508103: Windows システム上の Application Server で、オンラインヘルプにアプリケーションエラーが返される

Windows システム上の Sun Java System Application Server に Access Manager を配備した場合、レルムモードコンソールで「ヘルプ」をクリックすると、ヘルプ画面の左側のパネルにアプリケーションエラーが返されます。

回避方法: javaes-install-dir\share\lib\jhall.jar ファイルを JAVA_HOME\jre\lib\ext ディレクトリにコピーし、Application Server を再起動します。

CR# 6507383 および CR# 6507377: 分散認証には明示的な goto URL パラメータが必要である

明示的な goto URL パラメータを指定しなかった場合、分散認証 UI サーバーは Access Manager に指定された成功 URL の goto にリダイレクトしようとします。このリダイレクトは、次の理由で失敗することがあります。

回避方法: 分散認証 UI サーバーに対して、常に明示的な goto URL パラメータを指定します。

CR# 6402167: LDAP JDK 4.18 によって LDAP クライアント/Directory Server に問題が発生する

Access Manager 7 2005Q4 は、Java ES 2005Q4 リリースの一部である LDAP JDK 4.18 とともにリリースされましたが、その結果、Access Manager と Directory Server の通信にさまざまな問題が発生しました。

回避方法: 次のいずれかの Sun Java System LDAP Java Development Kit パッチを適用します。

これらのパッチは、SunSolve Online (http://sunsolve.sun.com) から入手できます。

CR# 6352135: 分散認証 UI サーバーのファイルが誤った場所にインストールされる

Solaris システムでは、Java ES インストーラが分散認証 UI サーバーの Makefile.distAuthUI ファイル、README.distAuthUI ファイル、および amauthdistui.war ファイルを誤った場所 (/opt/SUNComm/SUNWam) にインストールします。

回避方法: 上記のファイルを正しい場所 (/opt/SUNWam) にコピーします。

注: パッチで修正された分散認証 UI サーバーの問題は、/opt/SUNComm/SUNWam/amauthdistui.war ファイルに格納されるため、Access Manager サーバーにパッチを適用し、この WAR ファイルを再構築して配備する場合は、上記のファイルも /opt/SUNWam ディレクトリにコピーしてください。

CR# 6522720: Windows および HP-UX システム上では、複数バイト文字を用いてコンソールオンラインヘルプの検索ができない

Access Manager が日本語などの複数バイト文字を使用するロケールで Windows システムまたは HP-UX システムにインストールされている場合、複数バイト文字を使用して入力されたキーワードによるコンソールオンラインヘルプの検索はできません。

回避方法: なし

パッチ 6 での更新情報: Windows システムでは、この問題は Access Manager 7 2005Q4 パッチ 6 で修正されます。ただし、HP-UX システムではこの問題が引き続き存在します。

CR# 6524251: Windows システム上での Access Manager の設定中に、出力メッセージ内の複数バイト文字が文字化けする

Access Manager が日本語や中国語などの Windows システムにインストールされている場合、Access Manager の設定中に端末ウィンドウに出力されるメッセージ内の複数バイト文字が文字化けします。

回避方法: なし。ただし、この問題は設定自体には影響しません。

CR# 6526940: 英語以外のロケールの Windows システムに対するパッチ 5 のインストール中に、メッセージテキストではなくプロパティーキーが表示される

英語以外のロケールの Windows システムにパッチ 5 (124296-05) をインストールすると、インストールパネルの一部の文字列が実際のメッセージテキストではなくプロパティーキーとして表示されます。表示されるプロパティーキーは、たとえば、PRODUCT_NAME、JES_Patch_FinishPanel_Text1、JES_Patch_FinishPanel_Text2 などです。

回避方法: なし

CR# 6513653: com.iplanet.am.session.purgedelay プロパティーの設定で問題が発生する

Access Manager の amtune スクリプトは、できるだけ多くの Access Manager セッションを許可するため、com.iplanet.am.session.purgedelay プロパティーを 1 に設定します。このプロパティーは、パージセッション操作を遅延する時間を分単位で指定します。ただし、Sun Java System Portal Server などのクライアントでは、値が 1 では不十分な場合があります。

回避方法: amtune スクリプトを実行したあとで、次のようにして com.iplanet.am.session.purgedelay プロパティーをリセットします。

  1. AMConfig.properties ファイルで、このプロパティーを新しい値に設定します。次に例を示します。

    com.iplanet.am.session.purgedelay=5

  2. Access Manager Web コンテナを再起動して、新しい値を有効にします。