test

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

Access Manager 7 2005Q4 パッチリリース

Access Manager 7 2005Q4 のパッチの最新リビジョンは、SunSolve Online http://sunsolve.sun.com からダウンロードできます。最新のパッチ ID は次のとおりです。

注 –

Access Manager 7 2005Q4 パッチは累積的なパッチです。あらかじめパッチ 1、2、3、4、5、または 6 をインストールしなくてもパッチ 7 をインストールできます。ただし、以前のパッチをインストールしていない場合は、以前のパッチの節で新機能と問題を見直し、使用する配備に当てはまる機能や問題があるかどうかを確認してください。

Access Manager 7 2005Q4 のパッチに関する情報を次に示します。

Access Manager 7 2005Q4 パッチ 7

Access Manager 7 パッチ 7 (リビジョン 07) により、いくつかの問題が修正されます。その一覧はパッチに含まれている README ファイルに記載されています。

パッチ 7 での新機能

CR# 6637806: 再起動後に、Access Manager が無効なアプリケーション SSO トークンをエージェントに送信する

Access Manager サーバーが再起動すると、Access Manager クライアント SDK はエージェントに重要な例外を送信するようになりました。これにより、エージェントは新しいアプリケーションセッションを取得するために、自身を再認証できます。Access Manager 7 2005Q4 パッチ 5 以後、これまで Access Manager クライアント SDK は、Access Manager サーバーの再起動後に無効なアプリケーション SSO トークンをエージェントに送信していました。

この問題は、重複している CR 6496115 で修正されています。パッチ 7 には、制限のあるコンテキストでアプリケーション SSO トークンを送信するオプション (comp.iplanet.dpro.session.dnRestrictionOnly プロパティー) もあります。デフォルトで、エージェントはエージェントがインストールされているサーバーの IP アドレスを送信しますが、DN の厳密なチェックが必要な場合は AMConfig.properties ファイルでこのプロパティーを次のように設定します。

com.iplanet.dpro.session.dnRestrictionOnly=true

CR# 6612609: Session failover works if ネットワークケーブルが Message Queue サーバーから切り離されている場合に、セッションフェイルオーバーが動作する

セッションフェイルオーバー配備で、それぞれの Access Manager インスタンスおよび Message Queue ブローカが同じサーバーにインストールされている場合、ネットワークケーブルがいずれかのサーバーから切り離されていればセッションフェイルオーバーが動作するようになりました。デフォルトでは、Message Queue imqAddressListBehavior 接続ファクトリ属性が PRIORITY に設定されているため、Message Queue はブローカアドレスリストの出現順にアドレスを試行します (例: localhost:7777,server2:7777,server3:7777)。この属性が RANDOM に設定されている場合は、ランダムな順序でアドレスが試行されます。

この属性を RANDOM に設定するには、amsessiondb スクリプトで次のパラメータを設定します。

-DimqAddressListBehavior=RANDOM

Message Queue PRIORITY 属性および RANDOM 属性については、『Sun Java System Message Queue 3.7 UR1 管理ガイド』の「ブローカのアドレスリスト」を参照してください。

CR# 6570409: ロードバランサの背後にある対話型サービスがアイデンティティープロバイダとして正しく動作する

ロードバランサで接続されている 2 台のサーバーが 1 つのアイデンティティープロバイダとして機能している配備では、AMConfig.properties ファイル内の次のプロパティーを設定する必要があります。

com.sun.identity.liberty.interaction.lbWspRedirectHandler
com.sun.identity.liberty.interaction.trustedWspRedirectHandlers

com.sun.identity.liberty.interaction.interactionConfigClass が現在サポートされている唯一のクラスです。そのためデフォルトでは、相互作用構成パラメータにアクセスするときには、Federation Liberty にバンドルされている相互作用構成クラスが使用されます。

CR# 6545176: 認証後処理 SPI プラグインで、リダイレクト URL を動的に設定できる

ログイン成功、ログイン失敗、およびログアウト用の認証後処理 SPI プラグインで、リダイレクト URL を動的に設定できるようになりました。事後処理プラグインが実行されていない場合、事後処理 SPI で設定されたリダイレクト URL は使用されず、その他の方法で設定されたリダイレクト URL が従来どおり実行されます。

詳細は、com.iplanet.am.samples.authentication.spi.postprocess.ISAuthPostProcessSample.java のサンプルを参照してください。

インストール前の注意点

ファイルのバックアップ

重要 現在のインストールでカスタマイズしたファイルがある場合は、パッチをインストールする前にこれらのファイルをバックアップしてください。パッチをインストールしたあと、バックアップしたファイルをこのパッチによってインストールされた新しいファイルと比較して、カスタマイズの内容を特定します。カスタマイズの内容を新しいファイルにマージし、ファイルを保存します。カスタマイズしたファイルの処理方法の詳細については、以下の情報をお読みください。

パッチをインストールする前に、次のファイルもバックアップしてください。

Solaris システム

  • AccessManager-base/SUNWam/bin/amsfo

  • AccessManager-base/SUNWam/lib/amsfo.conf

  • /etc/opt/SUNWam/config/xml/template/ ディレクトリ内の次のファイル。

    idRepoService.xml、amSOAPBinding.xml、amDisco.xml、amAuthCert.xml、amAuth.xml、amSession.xml

  • AccessManager-base/SUNWam/locale/ ディレクトリ内の次のファイル。

    amConsole.properties、 amIdRepoService.properties、amAuthUI.properties、 amAuth.properties、amPolicy.properties、 amPolicyConfig.properties、amSessionDB.properties、 amSOAPBinding.properties、amAdminCLI.properties、 amSDK.properties、amAuthLDAP.properties、 amSession.properties、amAuthContext.properties、 amSAML.properties、amAuthCert.properties

Linux および HP-UX システム

  • AccessManager-base/identity/bin/amsfo

  • AccessManager-base/identity/lib/amsfo.conf

  • /etc/opt/sun/identity/config/xml/template/ ディレクトリ内の次のファイル。

    idRepoService.xml、 amSOAPBinding.xml、amDisco.xml、amAuthCert.xml 、amAuth.xml、amSession.xml

  • AccessManager-base/identity/locale/ ディレクトリ内の次のファイル。

    amConsole.properties、 amIdRepoService.properties、amAuthUI.properties、 amAuth.properties、amPolicy.properties、 amPolicyConfig.properties、amSessionDB.properties、 amSOAPBinding.properties、amAdminCLI.properties、 amSDK.properties、amAuthLDAP.properties、 amSession.properties、amAuthContext.properties、 amSAML.properties、amAuthCert.properties

Windows システム

  • AccessManager-base\identity\setup\AMConfigurator.properties

  • AccessManager-base\identity\bin\amsfo

  • AccessManager-base\identity\lib\amsfo.conf

  • AccessManager-base\identity\config\xml\template ディレクトリ内の次のファイル。

    idRepoService.xml、 amSOAPBinding.xml、amDisco.xml、amAuthCert.xml 、amAuth.xml、amSession.xml

  • AccessManager-base\identity\locale ディレクトリ内の次のファイル。

    amConsole.properties、 amIdRepoService.properties、amAuthUI.properties、 amAuth.properties、amPolicy.properties、 amPolicyConfig.properties、amSessionDB.properties、 amSOAPBinding.properties、amAdminCLI.properties、 amSDK.properties、amAuthLDAP.properties、 amSession.properties、amAuthContext.properties、 amSAML.properties、amAuthCert.properties

AccessManager-base は、ベースインストールディレクトリです。デフォルトのベースインストールディレクトリは、次のようにプラットフォームによって異なります。

  • Solaris システム: /opt

  • Linux および HP-UX システム: /opt/sun

  • Windows システム: javaes-install-directory\AccessManager。例: C:\Program Files\Sun\AccessManager

Access Manager のインストールと設定

本書に記載されている Access Manager パッチでは、Access Manager はインストールされません。パッチをインストールする前に、Access Manager 7 2005Q4 をサーバーにインストールする必要があります。インストールの詳細については、『Sun Java Enterprise System 2005Q4 インストールガイド(UNIX 版)』を参照してください。

Windows システムにパッチをインストールする場合は、『Sun Java Enterprise System 2005Q4 Installation Guide for Microsoft Windows』を参照してください。

また、amconfig スクリプトを実行して Access Manager の配備、再配備、および設定を行う方法についても理解しておいてください。詳細については、『Sun Java System Access Manager 7 2005Q4 管理ガイド』の第 1 章「Access Manager 7 2005Q4 の設定スクリプト」を参照してください。

このパッチによって廃止される Access Manager パッチ、およびこのパッチをインストールする前にインストールする必要のあるパッチの一覧については、このパッチに含まれている README ファイルを参照してください。

注意 – 注意 –

ほかのパッチと同様に、Access Manager パッチはステージングシステムや配備前システムでテストしてから、本稼働環境に配備するようにしてください。また、カスタマイズした JSP ファイルは、パッチインストーラで正しく更新されない場合があります。その場合、Access Manager を正しく機能させるには、これらのファイルを手動で変更する必要があります。

パッチのインストール手順

Solaris システムでのパッチのインストール手順

Solaris 用パッチをインストールする前に、「インストール前の注意点」に示したファイルをバックアップしておく必要があります。

Solaris システムでパッチの追加や削除を行うには、OS で提供されている patchadd コマンドと patchrm コマンドを使用します。

patchadd コマンド

patchadd コマンドは、スタンドアロンシステムにパッチをインストールするために使用します。次に例を示します。

# patchadd /var/spool/patch/120954-07
注 –

Solaris 10 の大域ゾーンに Solaris パッチをインストールする場合は、-G 引数を付けた patchadd コマンドを実行します。次に例を示します。

patchadd -G /var/spool/patch/120954-07

postpatch スクリプトでは、Access Manager アプリケーションの再配備に関するメッセージが表示されます。ただし、Access Manager SDK コンポーネントだけがインストールされているシステムの場合は表示されません。

postpatch スクリプトは、次のディレクトリに amsilent ファイルを作成します。

AccessManager-base は、ベースインストールディレクトリです。デフォルトのベースインストールディレクトリは、Solaris システムの場合は /opt、Linux システムの場合は /opt/sun です。

amsilent は amsamplesilent ファイルを基にしていますが、システムの Access Manager 設定ファイルに従っていくつかの必須パラメータが設定されます。ただし、パスワードパラメータにはデフォルト値が設定されます。配備での必要に応じて、各パスワードパラメータのコメントを解除して値を変更し、このファイル内のほかのパラメータの値も注意深く確認します。

COMMON_DEPLOY_URI パラメータ (共通ドメイン Web アプリケーションの URI プレフィックス) にもデフォルト値が設定されます。この URI をデフォルト以外の値にした場合は、必ずこの値を更新してください。更新しないと、amconfig とパッチが生成した amsilent ファイルによる Web アプリケーションの再配備が失敗します。

次のコマンドを実行します (Access Manager がデフォルトディレクトリにインストールされている場合の例)。

# cd /opt/SUNWam/bin 
# ./amconfig -s /opt/SUNWam/amsilent
注意 – 注意 –

amsilent ファイルには、プレーンテキスト形式の管理者パスワードなどの機密データが含まれているため、配備に合わせてこのファイルを保護する必要があります。

amconfig スクリプトを実行したあと、updateschema.sh スクリプトを実行して XML ファイルと LDIF ファイルを読み込みます。updateschema.sh スクリプトは、パッチ 7 のインストール後に、次のディレクトリから使用できます。

updateschema スクリプトを実行したあと、Access Manager のプロセスを再起動します。次に例を示します。

# cd /opt/SUNWam/bin
# ./amserver stop
# ./amserver start

Access Manager Web コンテナを再起動します。

patchrm コマンド

patchrm コマンドは、スタンドアロンシステムからパッチを削除するために使用します。次に例を示します。

# patchrm 120954-03

backout スクリプトでは、patchadd コマンドと同様のメッセージが表示されます。ただし、Access Manager SDK コンポーネントだけがインストールされているシステムの場合は表示されません。

パッチを削除したあと、AccessManager-base /SUNWam ディレクトリの amsilent ファイ ルを使用して Access Manager アプリケーションを再配備します。AccessManager-base はベースインストールディレクトリです。Solaris システムのデフォルトのベースインストールディレクトリは /opt です。

配備での必要に応じて、amsilent ファイル内のパラメータを設定します。

その後、次のコマンドを実行します (Access Manager が Solaris システムのデフォルトディレクトリにインストールされている場合の例)。

# cd /opt/SUNWam/bin
# ./amconfig -s /opt/SUNWam/amsilent

patchadd コマンドと patchrm コマンドの詳細および使用例については、該当する Solaris マニュアルページを参照してください。

詳細については、「インストール後の注意点」も参照してください。

Solaris 10 ゾーン

Solaris 10 オペレーティングシステムでは、「ゾーン」という新しい概念が導入されました。したがって、パッチを大域ゾーンにのみ追加する新しい -G オプションが patchadd コマンドに追加されています。デフォルトでは、patchadd コマンドは、パッチを適用するパッケージの pkginfo 内で SUNW_PKG_ALLZONES 変数を探します。ただし、すべての Access Manager パッケージに SUNW_PKG_ALLZONES 変数が設定されているとは限らないため、Access Manager 7 2005Q4 が大域ゾーンにインストールされている場合は -G オプションが必要になります。Access Manager が非大域ゾーンにインストールされている場合は、patchadd -G オプションは無効です。

Access Manager 7 2005Q4 のパッチを Solaris システムにインストールする場合は、-G オプションを使用することをお勧めします。次に例を示します。

 # patchadd -G AM7_patch_dir

同様に、Access Manager が大域ゾーンにインストールされている場合は、-G オプションを使用して patchrm コマンドを実行する必要があります。次に例を示します。

# patchrm -G 120954-07

Linux システムでのパッチのインストール手順

Linux 用パッチをインストールする前に、「インストール前の注意点」に示したファイルをバックアップしておく必要があります。

installpatch は、スタンドアロンの Linux システムにパッチをインストールします。次に例を示します。

# ./installpatch

postpatch スクリプトでは、Solaris システムのメッセージと同様のメッセージが出力されます。ただし、Linux システムでパッチを取り消す手順は、Solaris システムでの手順とは異なります。Linux のパッチを取り消す汎用のスクリプトはありません。下位バージョンのパッチが以前にインストールされていた場合は、そのバージョンを再インストールしてから、postpatch の手順に従って、amconfig スクリプトを実行して Access Manager アプリケーションを再配備できます。

amconfig スクリプトを実行したあと、updateschema.sh スクリプト (パッチ 5 以降のパッチ) を実行して XML ファイルと LDIF ファイルを読み込みます。updateschema.sh スクリプトは、パッチ 7 のインストール後に patch-home-directory/120956-07/scripts ディレクトリから使用できます。

amconfig スクリプトと updateschema.sh スクリプトを実行したあと、Access Manager Web コンテナを再起動します。

パッチが Access Manager 7 2005Q4 RTM リリースにインストールされている場合、そのパッチを削除してシステムを RTM 状態に復元するには、reinstallRTM スクリプトを使用して Access Manager の RTM ビットを再インストールする必要があります。このスクリプトは、Access Manager の RTM RPM が格納されているパスを受け取り、その RTM RPM をパッチの適用された RPM の上にインストールします。次に例を示します。

# ./scripts/reinstallRTM path_of_AM7_RTM_RPM_directory

reinstallRTM スクリプトを実行したあと、amconfig スクリプトを実行して Access Manager アプリケーションを再配備し、Web コンテナを再起動します。

詳細については、「インストール後の注意点」も参照してください。

Windows システムでのパッチのインストール手順

Windows 用パッチをインストールするには、次の要件があります。

Windows 用パッチのインストール

Windows 用パッチをインストールする前に、「インストール前の注意点」に示したファイルをバックアップしておく必要があります。

パッチスクリプトに入力するベースディレクトリパスには、スラッシュ (/) を使用します。例: c:/sun

Windows 用パッチをインストールするには、次の手順に従います。

  1. Administrators グループのメンバーとして Windows システムにログオンします。

  2. Windows 用パッチファイルをダウンロードして解凍するためのディレクトリを作成します。例: AM7p7

  3. 前の手順で作成したディレクトリに 124296-07.zip ファイルをダウンロードし、ファイルを解凍します。

  4. Java ES 2005Q4 のすべてのサービスを停止します。

  5. AM7p7\scripts\prepatch.pl スクリプトを実行します。

  6. AM7p7\124296-07.exe を実行してパッチをインストールします。

  7. AM7p7\scripts\postpatch.pl スクリプトを実行します。

  8. Java ES 2005Q4 のサービスを再起動します。

  9. Access Manager アプリケーションを再配備します。詳細については、「インストール後の注意点」を参照してください。

  10. AM7p7\scripts\updateschema.pl スクリプトを実行して Directory Server のサービススキーマを更新します。スクリプトが入力内容を検証し、ファイルを読み込みます。このスクリプトは次のログファイルも書き込みます。

    javaes-install-directory\AccessManager\AM70Patch-upgrade-schema- timestamp

  11. Java ES 2005Q4 のサービスを再起動します。

Windows 用パッチのバックアウト

Windows 用パッチをバックアウトするには、次の手順に従います。

  1. Administrators グループのメンバーとして Windows システムにログオンします。

  2. Uninstall_124296-07.bat ファイルを実行します。

  3. AM7p7\scripts\postbackout.pl スクリプトを実行します。

  4. Access Manager アプリケーションを再配備します。

  5. Java ES 2005Q4 のサービスを再起動します。

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

HP-UX システムでのパッチのインストール手順

HP-UX 用パッチをインストールまたは削除するには、swinstall コマンドまたは swremove コマンドを使用します。たとえば、スタンドアロンシステムにパッチをインストールするには、次のコマンドを使用します。

# swinstall /var/spool/patch/126371-07

また、スタンドアロンシステムからパッチを削除するには、次のコマンドを使用します。

# swremove 126371-07

swinstall コマンドと swremove コマンドの詳細は、swinstall と swremove のマニュアルページを参照してください。

パッチのインストールまたは削除を行なったあとは、「インストール後の注意点」の説明に従って Access Manager アプリケーションを再配備する必要があります。

Access Manager アプリケーションを再配備したあと、updateschema.sh スクリプト (パッチ 5 以降のパッチ) を実行して XML ファイルと LDIF ファイルを読み込みます。updateschema.sh script スクリプトは、パッチ 7 のインストール後に patch-home-directory/120956-07/scripts ディレクトリから使用できます。amconfig スクリプトと updateschema.sh スクリプトを実行したあと、Access Manager Web コンテナを再起動します。

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

HP-UX システムへの Access Manager の配備の詳細については、『Sun Java System Access Manager 7 2005Q4 Release Notes for HP-UX』を参照してください。

インストール後の注意点

Access Manager 7 2005Q4 パッチのインストール後の注意点を次に示します。

CR# 6254355: postpatch スクリプトの Access Manager アプリケーションが Access Manager のパッチで配備されない

カスタマイズされた WAR ファイルの一部がパッチインストーラで保持されず、カスタマイズされていないバージョンで置き換えられる場合があります。WAR ファイルのカスタマイズ内容を特定して手動で更新するには、次の手順に従うとよいでしょう。

次に示す例では、AccessManager-base はベースインストールディレクトリです。デフォルトのベースインストールディレクトリは、Solaris システムの場合は /opt、Linux システムの場合は /opt/sun です。

Windows システムでは、AccessManager-base は javaes-install-directory\AccessManager です。例: C:\Program Files\Sun\AccessManager

パッチが適用される WAR ファイルは次のとおりです。

これらのファイルは、Solaris システムでは AccessManager-base/SUNWam、Linux システムでは AccessManager-base/identity にあります。

Windows システムでは、 パッチが適用される WAR ファイルは AccessManager-base\ にあります。

WAR ファイル内で変更可能な内容は次のとおりです。

すべてのカスタマイズ内容を確実に保持するには、次の手順に従います。ファイルに変更を加える前に、必ずファイルをバックアップします。

  1. パッチをインストールします。

  2. WAR ファイルを一時ディレクトリに展開します。たとえば、Solaris システムのデフォルトディレクトリに Access Manager がインストールされている場合は、次のようにします。

    # cd temporary-directory 
# jar -xvf /opt/SUNWam/console.war
# jar -xvf /opt/SUNWam/services.war
# jar -xvf /opt/SUNWam/password.war

  3. 一時ディレクトリで展開されたファイルをチェックして、カスタマイズ済みファイルがパッチインストーラによって変更されたかどうかを確認し、変更されたファイルに元のカスタマイズ内容を手動で追加します。AccessManager-base/web-src/ ディレクトリにあっても、パッチが適用される WAR ファイルに含まれていないファイルについては、変更を追加し直す必要はありません。

  4. 変更したファイルを使用して WAR ファイルを更新します。たとえば、Solaris システムのデフォルトディレクトリに Access Manager がインストールされている場合は、次のようにします。

    # cd temporary-directory
# jar -uvf /opt/SUNWam/console.war $path/$modified file
# jar -uvf /opt/SUNWam/services.war $path/$modified file
# jar -uvf /opt/SUNWam/password.war $path/$modified file

    手順 2 - 4 の例を次に示します。

    # mkdir /tmp/war.tmp 
# cd /tmp/war.tmp
# jar -xvf /opt/SUNWam/services.war
# vi index.html
# jar -uvf /opt/SUNWam/services.war index.html

  5. パッチによって生成されたサイレント設定ファイル (amsilent) を再利用するか、amsamplesilent テンプレートファイルに基づいてサイレント設定ファイルを新規作成し、そのファイルに次を含む適切な設定変数を設定します。

    • DEPLOY_LEVEL=21

    • DIRECTORY_MODE=5

    • DS_DIRMGRPASSWD、ADMINPASSWD、および AMLDAPUSERPASSWD のパスワード

    • Access Manager Web コンテナの変数

    Windows システムでは、postpatch.pl スクリプトによって生成されたサイレント設定ファイル (amsilent) を再利用し、AccessManager-base\setup\AMConfigurator.properties-tmp に有効な値が設定されていることを確認します。次に、このファイルの名前を AccessManager-base\setup\AMConfigurator.properties に変更します。

    Web コンテナの変数の詳細については、amsamplesilent ファイルを参照してください。このファイルは、Solaris システムでは /opt/SUNWam/bin ディレクトリ、Linux システムでは /opt/sun/identity/bin ディレクトリにあります。

    Windows システムでは、この設定ファイルは AccessManager-base\setup\AMConfigurator.properties です。

  6. amconfig スクリプトを次のように実行します。amconfig を実行するには、Directory Server および Access Manager Web コンテナが稼働している必要があります。たとえば、Access Manager がデフォルトのベースインストールディレクトリにインストールされている Solaris システム上で amconfig を実行するには、次のように入力します。 

    # cd /opt/SUNWam/bin 
# ./amconfig -s /opt/SUNWam/amsilent

  7. amconfig スクリプトを実行したあと、Access Manager のプロセスを再起動します。次に例を示します。

    # cd /opt/SUNWam/bin
# ./amserver stop
# ./amserver start

  8. カスタマイズしたすべての JSP ファイルが AccessManager-base/SUNWam/web-src/ ディレクトリ (Solaris システムの場合) または AccessManager-base/identity/web-src/ (Linux システムの場合) の下の適切なサブディレクトリに配置されていること、およびカスタマイズしたすべてのファイルがバックアップされていることを確認します。

    Windows システムでは、これらのファイルは AccessManager-base\web-src\ にあります。

  9. Access Manager Web コンテナを再起動します。

amconfig スクリプトの実行の詳細については、『Sun Java System Access Manager 7 2005Q4 管理ガイド』の第 1 章「Access Manager 7 2005Q4 の設定スクリプト」を参照してください。

CR# 6436409: 分散認証およびクライアント SDK の WAR ファイルの再配備

分散認証またはクライアント SDK を使用している場合は、パッチをインストールしたあとで、分散認証 WAR ファイルまたはクライアント SDK WAR ファイル、あるいはその両方を再作成して再配備します。詳細については、次のドキュメントを参照してください。

Access Manager 7 2005Q6 パッチ 6

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

パッチ 6 での新機能

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

注 –

パッチ 6 をインストールする前に、次のコンポーネントのアップグレードまたはパッチ適用を行うことをお勧めします。

Access Manager は JDK 1.5 HttpURLConnection setReadTimeout メソッドをサポートする

setReadTimeout メソッドをサポートするために、AMConfig.properties ファイルに次の新しいプロパティーが追加され、読み取りのタイムアウト値を設定できるようになりました。 

com.sun.identity.url.readTimeout

Web コンテナでJDK 1.5 が使用されている場合は、多数の HttpURLConnections が開いてサーバーがハングアップすることを防止するために、このプロパティーを適切な値に設定して接続をタイムアウトさせるようにしてください。デフォルトは 30000 ミリ秒 (30 秒) です。

com.sun.identity.url.readTimeout が AMConfig.properties ファイル内に存在しない場合または空の文字列に設定されている場合、setReadTimeout メソッドは無視されます。

プライマリが復旧すると Access Manager SDK はプライマリ Directory Server にフォールバックする

Sun Java System Directory Server がマルチマスターレプリケーション (MMR) 用に設定されている場合、プライマリサーバーがダウンしたあとで復旧すると、Access Manager SDK はプライマリ Directory Server にフォールバックするようになりました。以前は、プライマリサーバーが復旧した後も Access Manager SDK は引き続きセカンダリ Directory Server にアクセスしていました。

この新しい動作をサポートするために、AMConfig.properties ファイルに次の新しいプロパティーが追加されました。

com.sun.am.ldap.fallback.sleep.minutes

このプロパティーは、プライマリサーバーの復旧後にプライマリサーバーにフォールバックする前の、セカンダリ Directory Server インスタンスのスリープ時間を分単位で設定します。デフォルトは 15 分です。

com.sun.am.ldap.fallback.sleep.minutes プロパティーは隠されています。このプロパティーをデフォルト (15 分) 以外の値に設定するには、このプロパティーを明示的に AMConfig.properties ファイルに追加します。値を 7 分に設定する場合の例を次に示します。

com.sun.am.ldap.fallback.sleep.minutes=7

新しい値を有効にするために、Access Manager Web コンテナを再起動します。

複数の Access Manager インスタンスは個別のログファイルにログを記録する

同じホストサーバーで複数の Access Manager インスタンスが実行されている場合、AMConfig.properties ファイルに次の新しいプロパティーを設定することにより、インスタンスごとに異なるログ用サブディレクトリの個別のログファイルにログを記録できるようになりました。

com.sun.identity.log.logSubdir

デフォルトのログディレクトリを管理コンソールで変更した場合を除き、デフォルトのログディレクトリは次のとおりです。

最初の Access Manager インスタンスは、常にデフォルトのログディレクトリにログを記録します。追加の Access Manager インスタンスに対して別のログ用サブディレクトリを指定するには、追加した各インスタンスごとに AMConfig.properties ファイルで com.sun.identity.log.logSubdir プロパティーを設定します。

たとえば、am-instance-1、am-instance-2、および am-instance-3 という3 つのインスタンスがあり、それらすべてが同じSolaris ホストサーバーで実行されている場合は、プロパティーを次のように設定します。

com.sun.identity.log.logSubdir=am-instance-2
com.sun.identity.log.logSubdir=am-instance-3

com.sun.identity.log.logSubdir プロパティーは隠されています。必要に応じてこのプロパティーを明示的に AMConfig.properties ファイルに追加してから、Access Manager Web コンテナを再起動してサブディレクトリの値を有効にする必要があります。

その後、Access Manager インスタンスは次のディレクトリにログを記録します。

/var/opt/SUNWam/logs/log-files-for-am-instance-1
/var/opt/SUNWam/logs/am-instance-2/log-files-for-am-instance-2
/var/opt/SUNWam/logs/am-instance-3/log-files-for-am-instance-3

Access Manager 7 は複数の Cookie ドメインに対応可能

複数の Cookie ドメインをサポートするために、Access Manager に次の新しいプロパティーが追加されました。

com.sun.identity.authentication.setCookieToAllDomains

デフォルトは true です。この新しいプロパティーは隠されています。値を false に設定するには、このプロパティーを明示的に AMConfig.properties ファイルに追加し てから、Access Manager Web コンテナを再起動します。

Microsoft IIS 6.0 認証後プラグインは SharePoint Server をサポートする

Microsoft Internet Information Services (IIS) 6.0 認証プラグインは、Microsoft Office SharePoint Server をサポートするようになりました。ユーザーは、ユーザー ID またはログイン名で Access Manager にログインできます。ただし、SharePoint Server はログイン名を受け入れるため、ユーザーがユーザー ID を指定すると問題が発生します。

SharePoint Server へのログインを可能にするために、認証後プラグイン (ReplayPasswd.java) で次の新しいプロパティーが使用されるようになりました。

com.sun.am.sharepoint_login_attr_name

この新しいプロパティーは、SharePoint Server での認証に使用されるユーザー属性を指定します。たとえば、次のプロパティーは、認証に共通名 (cn) を使用するように指定します。 

com.sun.am.sharepoint_login_attr_name=cn

認証後プラグインは、com.sun.am.sharepoint_login_attr_name プロパティーを読み取り、そのユーザーに対応する属性値を Directory Server から取得します。次に、プラグインは承認ヘッダーを設定して、ユーザーが SharePoint Server にアクセスできるようにします。

このプロパティーは隠されています。このプロパティーを設定するには、このプロパティーを明示的に AMConfig.properties ファイルに追加してから、Access Manager Web コンテナを再起動して値を有効にします。

Access Manager は Internet Explorer 7 をサポートする

Access Manager 7 2005Q4 パッチ 6 では、Microsoft Windows Internet Explorer 7 がサポートされるようになりました。

CR# 6379325 セッションフェイルオーバー中にコンソールにアクセスすると null ポインタ例外がスローされる

このシナリオでは、Cookie ベースのスティッキー要求ルーティングに対応するように設定されたロードバランサの背後に、複数の Access Manager サーバーがセッションフェイルオーバーモードで配備されています。Access Manager 管理者はロードバランサ経由で Access Manager コンソールにアクセスします。管理者がコンソールにログインすると、Access Manager サーバーの 1 つにセッションが作成されます。そのサーバーがダウンした場合、コンソールセッションは予定どおり別の Access Manager サーバーにフェイルオーバーされます。ただし、管理者はブラウザおよび Web コンテナエラーログに null ポインタ例外が断続的に記録されるという問題に遭遇することがあります。

この問題は、フェイルオーバー時にアクティブになっている Access Manager コンソールセッションのみに影響し、Access Manager サーバーの機能には影響しません。

回避方法: このような null ポインタ例外が断続的に発生することを防ぐには、次の手順を実行します。

CR# 6508103: Windows で管理コンソールの「ヘルプ」をクリックするとアプリケーションエラーが返される

Windows 2003 Enterprise Edition では、Access Manager が英語以外のロケールで Sun Java System Application Server に配備されている場合、レルムモードの管理コンソールで「ヘルプ」をクリックするとアプリケーションエラーが返されます。

回避方法:

  1. javaes-install-dir\share\lib\jhall.jar ファイルを %JAVA_HOME%\jre\lib\ext ディレクトリにコピーします。

    ここで、javaes-install-dir は Windows のインストールディレクトリです

  2. Application Server インスタンスを再起動します。

CR# 6564877: Access Manager 7 パッチをインストールすると SAML v2 ファイルが上書きされる

SAML v2 プラグインがインストールされている場合、パッチをインストールすると SAML v2 の関連ファイルが上書きされ、postpatch スクリプトで次のメッセージが表示されるようになります。

The postpatch script detected that the SAML v2 plug-in is installed in your environment. When you run the amconfig script to redeploy the Access Manager applications, the script will recreate the amserver.war file and the SAML v2 related files will be lost. Therefore, after you run amconfig, recreate and redeploy the amserver.war file, as described in the Sun Java System SAML v2 Plug-in for Federation Services User's Guide.

回避方法: パッチをインストールして amconfig スクリプトを実行したあと、SAML v2 プラグインを使用する Federation Manager やAccess Manager の配備に対して、amserver.war ファイルを再作成および再配備します。

具体的な手順については、『Sun Java System SAML v2 Plug-in for Federation Services User’s Guide』の第 2 章「Installing the SAML v2 Plug-in for Federation Services」を参照してください。

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 コンテナを再起動して、新しい値を有効にします。

Access Manager 7 2005Q4 パッチ 4

Access Manager 7 2005Q4 パッチ 4 (リビジョン 04) では、次の問題を修正します。

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

CR# 6470055: 分散認証 UI サーバーのパフォーマンスの改善

分散認証 UI サーバーユーザーのユーザー属性の読み取り、検索、および比較のパフォーマンスを改善するには、次の手順を実行します。

  1. Makefile.distAuthUI ファイルで、アプリケーションユーザー名を anonymous から別のユーザーに変更します。次に例を示します。 

    APPLICATION_USERNAME=user1

  2. Directory Server で、新しいユーザー (たとえば、user1) と ACI を追加し、ユーザー属性の読み取り、検索、および比較を許可します。次の例では、新しい ACI を追加しています。

    dn:ou=1.0,ou=SunAMClientData,ou=ClientData,dc=example,dc=com 
changetype:modify add:aci 
aci: (target="ldap:///ou=1.0,ou=SunAMClientData,ou=ClientData,dc=example,dc=com")
(targetattr = *")(version 3.0; 
acl "SunAM client data access to a Distributed Auth App User"; 
allow (read, search, compare) 
userdn =  "ldap:///uid=user1,ou=people,dc=example,dc=com";)

CR# 6455079: パスワードが変更されたときに、パスワードリセットサービスから通知エラーが報告される

パスワードが変更されると、Access Manager は資格を取得していない送信者名 Identity-Server を使用して電子メール通知を送信します。その結果、amPasswordReset ログにエラーが書き込まれます。次に例を示します。

07/19/2006 10:26:04:010 AM PDT: Thread[service-j2ee,5,main]
ERROR: Could not send email to user [Ljava.lang.String;@999262
com.sun.mail.smtp.SMTPSendFailedException: 553 5.5.4 <Identity-Server>...
Domain name required for sender address Identity-Server

回避方法: amPasswordResetModuleMsgs.properties ファイルで、次のようにしてホストサーバーの完全修飾ドメイン名が含まれるように from アドレスを変更します。

  1. from アドレスのラベルを変更します。次に例を示します。

    fromAddress.label=<Identity-Server@amhost.example.com>

  2. lockOutEmailFrom プロパティーを変更して、正しい from アドレスがロックアウト通知に確実に使用されるようにします。次に例を示します。

    lockOutEmailFrom=<Identity-Server@amhost.example.com>

    amPasswordResetModuleMsgs.properties ファイルは、Solaris システムの場合は AccessManager-base/SUNWam/locale ディレクトリ、Linux システムの場合は AccessManager-base/identity/locale ディレクトリにあります。

    AccessManager-base は、ベースインストールディレクトリです。デフォルトのベースインストールディレクトリは、Solaris システムの場合は /opt、Linux システムの場合は /opt/sun です。

Access Manager 7 2005Q4 パッチ 3

Access Manager 7 パッチ 3 (リビジョン 03) により、いくつかの問題が修正されます。その一覧はパッチに含まれている README ファイルに記載されています。パッチ 3 には、次に示す新機能と既知の問題があります。

パッチ 3 での新機能

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

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

Access Manager のサイト監視機能に、次に示す新しいプロパティーが追加されています。

プロパティー 

説明 

com.sun.identity.sitemonitor.interval

サイト監視の間隔です (ミリ秒単位)。サイト監視機能は、指定された間隔で各サイトの可用性をチェックします。デフォルト: 60000 ミリ秒 (1 分)。 

com.sun.identity.sitemonitor.timeout

サイトの可用性チェックのタイムアウトです (ミリ秒単位)。サイト監視機能は、指定された時間だけサイトからの応答を待ちます。デフォルト: 5000 ミリ秒 (5 秒)。  

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

  1. 各プロパティーとその値を AMConfig.properties ファイルに追加します。このファイルはプラットフォームによって次のディレクトリにあります。

    • Solaris システム: /etc/opt/SUNWam/config

    • Linux システム: /etc/opt/sun/identity/config

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

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

カスタム実装。また、com.sun.identity.sitemonitor.SiteStatusCheck クラスでは、次のインタフェースを使用して、サイトの可用性チェックに使用する独自の実装をカスタマイズすることもできます。

package com.iplanet.services.naming.WebtopNaming$SiteStatusCheck

各実装クラスは doCheckSiteStatus メソッドを使用する必要があります。

public interface SiteStatusCheck { 
public boolean doCheckSiteStatus(URL siteurl);
}

Liberty Identity Web Services Framework (ID-WSF) 1.1 のサポート

Access Manager 7 パッチ 3 では、ID-WSF のデフォルトのバージョンは WSF1.1 です。ID-WSF をトリガーするために個別の設定を行う必要はありませんが、サンプルでは新しいセキュリティー機構を使用する必要があります。ID-WSF1.1 の新しいセキュリティー機構は次のとおりです。

urn:liberty:security:2005-02:null:X509
urn:liberty:security:2005-02:TLS:X509
urn:liberty:security:2005-02:ClientTLS:X509
urn:liberty:security:2005-02:null:SAML
urn:liberty:security:2005-02:TLS:SAML
urn:liberty:security:2005-02:ClientTLS:SAML
urn:liberty:security:2005-02:null:Bearer
urn:liberty:security:2005-02:TLS:Bearer
urn:liberty:security:2005-02:ClientTLS:Bearer

Liberty ID-WSF サポートの新しいプロパティー

com.sun.identity.liberty.wsf.version プロパティーは、Access Manager が WSC として動作しているときに、受信メッセージやリソースオファリングから Liberty ID-WSF のフレームワークを判定できない場合に、そのフレームワークを決定します。指定できる値は 1.0 または 1.1 で、デフォルトは 1.1 です。

注 パッチのインストールでは、com.sun.identity.liberty.wsf.version プロパティーは AMConfig.properties ファイルに追加されません (CR# 6458184)。この新しいプロパティーを使用するには、パッチのインストール後、このプロパティーを AMConfig.properties ファイルに追加して適切な値を設定し、Access Manager Web コンテナを再起動します。

Access Manager 7 パッチ 3 のインストール後、次のコマンドを実行してスキーマの変更を読み込みます (Access Manager が Solaris システムのデフォルトディレクトリにインストールされている場合の例)。

# /opt/SUNWam/bin/amadmin -u amadmin -w amadmin_password 
-t /etc/opt/SUNWam/wsf1.1_upgrade.xml

ID-WSF 検索登録では、登録時にこれらの新しいセキュリティー機構を使用できます。また、WSC は WSP との通信中に、使用するバージョンを自動的に検出できます。ID-WSF1.1 を設定するには、製品に含まれている Liberty ID-FF sample1 および ID-WSF のサンプルの Readme ファイルに従ってください。

CR# 6463779 分散認証の amProfile_Client ログと Access Manager サーバーの amProfile_Server ログが無害な例外でいっぱいになる

分散認証 UI を介して Access Manager サーバーに要求があると、distAuth/amProfile_Client ログと Access Manager サーバーの debug/amProfile_Server ログに例外が記録されます。多くのセッションのあとでは、amProfile_Client ログは数ギガバイト、Access Manager サーバーの amProfile_Server ログは数メガバイトになる場合があります。このような例外がログに記録されることによって機能が失われることはありませんが、ユーザーに誤ったアラームが発生したり、ハードディスク容量がログでいっぱいになったりする原因になります。

回避方法: ログファイルの内容を null にする cron ジョブを実行します。次に例を示します。

CR# 6460974 デフォルトの分散認証アプリケーションユーザーは amadmin にしないようにする

分散認証 UI サーバーを配備する場合は、分散認証の管理者を amadmin にするべきではありません。デフォルトの分散認証アプリケーションユーザーは、Makefile.distAuthUI ファイルでは amadmin であり、クライアント側で distAuth.war ファイルが配備されたあと AMConfig.properties ファイルでも同様になります。amadmin ユーザーは AppSSOToken を持っていますが、これは amadmin セッションがタイムアウトすると期限切れになり、それによって amSecurity ログファイル (デフォルトでは /tmp/distAuth ディレクトリにある) に FATAL ERROR が記録されることがあります。

回避方法: 分散認証アプリケーションユーザーとして UrlAccessAgent を指定します。次に例を示します。

クライアントの Web コンテナに distAuth.war ファイルを配備する前に、Makefile.distAuthUI ファイルで次のパラメータを変更します。

APPLICATION_USERNAME=UrlAccessAgent
APPLICATION_PASSWORD=shared-secret-password or amldapuser-password

または

クライアントの Web コンテナに distAuth.war ファイルを配備したあとで、各 Access Manager サーバーの AMConfig.properties ファイルで次のプロパティーを変更します。

com.sun.identity.agents.app.username=UrlAccessAgent
com.iplanet.am.service.password=shared-secret-password or amldapuser-password

「CR# 6440697: 分散認証は amadmin ユーザー以外のユーザーで実行するようにする」も参照してください。

CR# 6460576 コンソールのオンラインヘルプの「フィルタを適用したロール」にユーザーサービスへのリンクがない

Access Manager コンソールのオンラインヘルプには、「フィルタを適用したロール」の下にユーザーサービスへのリンクがありません。オンラインヘルプで、「目次」、「フィルタを適用したロール」、「フィルタを作成する」の順に移動します。ページの下へ移動すると、選択したアイデンティティーの種類に応じてサービスの一覧が表示されますが、ユーザーサービスへのリンクは用意されていません。

回避方法: なし

CR# 6460085 reinstallRTM を実行して Web アプリケーションを再配備すると、WebSphere 上のサーバーにアクセスできなくなる

Red Hat Linux AS 3.0 Update 4 で IBM WebSphere Application Server 5.1.1.6 上の DEPLOY_LEVEL=1 配備に Access Manager 7 パッチ 3 を適用したあと、reinstallRTM スクリプトを実行して RTM RPM を復元します。次に、reinstallRTM スクリプトによって生成された amsilent ファイルを編集してから、Web アプリケーションを再配備します。stopServer.sh スクリプトと startServer.sh スクリプトを使用して WebSphere を再起動します。しかし、ログインページにアクセスすると、amlcontroller フィルタに関連する 500 エラーが WebSphere で表示されます。

この問題は、reinstallRTM スクリプトによって生成される新しい server.xml ファイルが破損しているために発生します。

回避方法: amconfig スクリプトでバックアップした server.xml ファイルは有効です。この以前のコピーを次の手順で使用します。

  1. サーバーを停止します。

  2. 破損している server.xml を、amconfig スクリプトでバックアップしておいたコピーで置き換えます。

    amconfig スクリプトでバックアップされた server.xml ファイルの名前は server.xml-orig-pid になります。ここで、pid は amwas51config スクリプトのプロセス ID です。このファイルは、次のディレクトリにあります。

    WebSphere-home-directory/config/cells/WebSphere-cell
/nodes/WebSphere-node/servers/server-name

  3. サーバーを再起動します。

CR# 6455757: アップグレードの前に sunISManagerOrganization マーカークラスを組織に追加する必要がある

Access Manager 7 リリースより前に作成された Access Manager DIT 内の組織は、sunISManagerOrganization オブジェクトクラスを持たない場合があります。また、Access Manager 以外の製品で作成された組織も、その定義に sunISManagerOrganization オブジェクトクラスを持ちません。

回避方法: Access Manager 7 2005Q4 にアップグレードする前に、DIT 内のすべての組織の定義に sunISManagerOrganization オブジェクトクラスが含まれていることを確認します。アップグレードの前に、必要に応じてこのオブジェクトクラスを手動で追加します。

CR# 6454489: Access Manager 7 2005Q4 パッチ 2 のアップグレードによってコンソールの「現在のセッション」タブにエラーが表示される

アップグレードによって、Access Manager コンソールの「現在のセッション」タブに次のエラーが表示されます。

Failed to get valid Sessions from the Specified server

この問題は、o=orgname という形式のルートサフィックスを持つ Access Manager 6 バージョンからアップグレードする配備で発生します。

回避方法: Access Manager 7 2005Q4 のインストール後、Access Manager 7 パッチ 3 を適用してから amupgrade スクリプトを実行して、次のようにデータを移行します。

  1. Access Manager 6 DIT をバックアップします。

  2. ampre70upgrade スクリプトを実行します。

  3. 「あとで設定」オプションを指定して Access Manager 7 2005Q4 をインストールします。

  4. Access Manager Web アプリケーションの配備を取り消します。

  5. Access Manager Web アプリケーションを配備します。

  6. Access Manager 7 パッチ 3 を適用します。ただし、XML/LDIF の変更は適用しないでください。XML/LDIF の変更は、次の手順で amupgrade スクリプトを実行したあとで適用する必要があります。

  7. amupgrade スクリプトを実行します。

  8. Access Manager 7 パッチ 3 の変更のため、Access Manager Web アプリケーションを再配備します。

  9. Access Manager コンソールにアクセスします。

CR# 6452320: クライアント SDK でポーリングを使用すると例外がスローされる

Access Manager クライアント SDK (amclientsdk.jar) を配備してポーリングを有効にすると、次のようなエラーが発生することがあります。

ERROR: Send Polling Error:
com.iplanet.am.util.ThreadPoolException: 
amSessionPoller thread pool's task queue is full.

このようなエラーは、クライアントマシンに分散認証 UI サーバーまたは J2EE エージェントを配備したあと、あるいは、Access Manager クライアント SDK を配備する任意の状況で発生することがあります。

回避方法: 並行セッションの数が数百程度であれば、次のプロパティーと値を AMConfig.properties ファイルまたは AMAgents.properties ファイルに追加します。

com.sun.identity.session.polling.threadpool.size=10
com.sun.identity.session.polling.threadpool.threshold=10000

数千または数万のセッションがある場合は、amtune-identity スクリプト実行後の Access Manager AMConfig.properties ファイル内の通知用の値と同じ値を設定するようにしてください。たとえば、マシンに 4G バイトの RAM がある場合、Access Manager の amtune-identity スクリプトでは次の値が設定されます。

com.sun.identity.session.notification.threadpool.size=28
com.sun.identity.session.notification.threadpool.threshold=76288

4G バイトの RAM を備えたクライアントマシンに分散認証 UI サーバーまたは Access Manager クライアント SDK を配備するときは、AMAgent.properties ファイルまたは AMConfig.properties ファイルで、類似の値をクライアント側に設定します。

CR# 6442905 認証されたユーザーの SSOToken が不正なサイトに公開される可能性がある

認証された Access Manager ユーザーが不正なサイトの URL をクリックすると、その不正なサイトに SSOToken が公開されてしまう可能性があります。

回避方法: 参加しているすべてのポリシーエージェントについて、常に一意のエージェントユーザープロファイルを Access Manger に作成し、サイトが不正でないことを確認します。また、これらの一意のエージェントユーザーで使用されるパスワードが、共有シークレットパスワードまたは amldapuser パスワードと同じでないことを確認します。デフォルトでは、ポリシーエージェントは Access Manager アプリケーション認証モジュールに対して UrlAccessAgent ユーザーとして認証されます。

Access Manager 管理コンソールを使用してエージェントを作成する方法については、『Sun Java System Access Manager 7 2005Q4 管理ガイド』の「エージェント」を参照してください。

CR# 6441918: サイト監視の間隔およびタイムアウトのプロパティー

Access Manager のサイトフェイルオーバーに、次に示す新しいプロパティーが追加されています。

com.sun.identity.sitemonitor.interval
com.sun.identity.sitemonitor.timeout

詳細については、「サイト監視の新しい設定プロパティー」を参照してください。

CR# 6440697: 分散認証は amadmin ユーザー以外のユーザーで実行するようにする

デフォルトの管理ユーザー (amadmin) 以外の、分散認証アプリケーションの認証に使用する分散認証管理者を作成するには、次の手順に従います。

  1. 分散認証管理者の LDAP ユーザーを作成します。次に例を示します。

    uid=DistAuthAdmin,ou=people,o=am

  2. 分散認証管理者を特殊ユーザーのリストに追加します。次に例を示します。

    com.sun.identity.authentication.special.users=cn=dsameuser,
ou=DSAME Users,o=am|cn=amService-UrlAccessAgent,ou=DSAME Users,
o=am|uid=DistAuthAdmin,ou=People,o=am

    このプロパティーをすべての Access Manager サーバーの AMConfig.properties ファイルに追加して、セッションのタイムアウトによって分散認証管理者の AppSSOToken が期限切れにならないようにします。

CR# 6440695: 分散認証 UI サーバーとロードバランサ

複数の分散認証 UI サーバーの前でロードバランサを使用する配備の場合は、WAR ファイルを配備したあと、次のプロパティーを AMConfig.properties ファイルに設定します。

com.iplanet.am.lbcookie.name=DistAuthLBCookieName
com.iplanet.am.lbcookie.value=DistAuthLBCookieValue

CR# 6440651: Cookie 応答には com.sun.identity.session.resetLBCookie プロパティーが必要

Access Manager のセッションフェイルオーバーで Cookie 応答を正しく動作させるには、値を true に設定した com.sun.identity.session.resetLBCookie プロパティーをポリシーエージェントと Access Manager サーバーの両方に追加します。次に例を示します。

com.sun.identity.session.resetLBCookie='true'

注: このプロパティーは、Access Manager のセッションフェイルオーバーを実装した場合にのみ必要です。

CR# 6440648: com.iplanet.am.lbcookie.name プロパティーのデフォルト値は amlbcookie と仮定される

デフォルトでは、ポリシーエージェントと Access Manager サーバーではロードバランサの cookie 名は amlbcookie と仮定されます。バックエンドサーバーで cookie 名を変更する場合は、ポリシーエージェントの AMAgent.properties ファイル内でも同じ名前を使用する必要があります。また、Access Manager クライアント SDK を使用している場合は、バックエンドサーバーで使用されているものと同じ cookie 名を使用する必要があります。

CR# 6440641: com.iplanet.am.lbcookie.value プロパティーは推奨されなくなった

Access Manager では、ロードバランサ cookie をカスタマイズするためのサーバーの com.iplanet.am.lbcookie.value プロパティーはサポートされなくなりました。代わりに、エージェントによって再生される cookie の値と名前に、セッション設定の一部として設定されるサーバー ID を使用するようになりました。

CR# 6429610: ID-FF SSO ユースケースで SSO トークンを作成できない

Liberty Identity Federation Framework (ID-FF) サンプル 1 を設定したあと、連携は成功するが、SSO が失敗します。

回避方法: dsameuser の uuid を AMConfig.properties ファイル内の com.sun.identity.authentication.special.users プロパティーに追加します。アプリケーション認証には、Access Manager サーバーの dsameuser ユーザーの SSO トークンが無期限である必要があります。

CR# 6389564: Access Manager のログイン時に、LDAP v3 データストア内のユーザーのロールメンバーシップに関するクエリーが繰り返し発生する

ユーザーが Access Manager にログインするとき、ユーザーの nsRoleDN 属性に関する LDAP 検索が繰り返し発生します。

回避方法: Access Manager 7 パッチ 3 のインストール後、次のコマンドを実行します (Access Manager が Solaris システムのデフォルトディレクトリにインストールされている場合の例)。

# /opt/SUNWam/bin/amadmin -u amadmin 
-w amadmin_password 
-t /etc/opt/SUNWam/idRepoServiceAddAttrSchemaRequest_Cache.xml

CR# 6385185: 認証モジュールで "goto" URL を上書きして別の URL を指定できる必要がある

認証モジュールでは、"goto" URL を上書きして、ユーザーステータスを検証するために外部 Web サイトの別の URL にリダイレクトするよう要求できます。

認証の完了後に "goto" URL を上書きするには、次の例に示すプロパティーを SSOToken に設定します。このプロパティーを設定するには、AMPostAuthProcessInterface を実装して PostProcess クラスの onLoginSuccess メソッドを使用します。たとえば、"goto" URL を上書きする URL が OverridingURL の場合は、次のように指定します。

public class <..> implements AMPostAuthProcessInterface {  
...
    public void onLoginSuccess(...) {
        try {
            ssoToken.setProperty("PostProcessSuccessURL", OverridingURL);
         } catch (Exception ...) {
         ...         }
...
}

CR# 6385184: SSO トークンがまだ無効な状態での、カスタム認証モジュール内からのリダイレクト

カスタム認証モジュールの新しい RedirectCallback を使用すると、ユーザーを検証するために、認証 UI を介して外部 Web サイトにリダイレクトできます。正常に認証された場合、ユーザーは元の Access Manager サーバーの URL に再びリダイレクトされます。サンプルファイルは次のとおりです。

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

  1. サンプル LoginModuleSample.java を使用して、カスタム認証モジュールを作成します。

  2. このモジュールを Access Manager サーバーに読み込みます。

  3. サンプル LoginModuleSample.xml を使用して、XML ファイルに RedirectCallback を構築します。

  4. モジュールをテストするために、外部 Web サイトとしてサンプル testExtWebSite.jsp ファイルを使用します。

  5. 次の URL を使用してログインします。

    http://example.com/amserver/UI/Login?module=LoginModuleSample

検証のためにユーザー名とパスワードが外部 Web サイトにリダイレクトされます。ユーザー名とパスワードが有効な場合、ユーザーは正常に認証され、元の Access Manager サーバーの URL に再びリダイレクトされます。

たとえば、配備でカスタム認証モジュールを使用してプロビジョニング/クレジットカードサイトにアクセスする、次のようなシナリオが考えられます。

  1. ユーザーがカスタム認証モジュールの認証プロセス/ログインページを呼び出します。

  2. ユーザーは資格情報 (ユーザー名とパスワード) を入力し、カスタム認証モジュールに要求を送信します。

  3. カスタム認証モジュールは、外部のプロビジョニング/クレジットカードサイトにユーザーをリダイレクトして、必要なユーザー情報とともに要求を送信します。

  4. 外部のプロビジョニング/クレジットカードサイトは、ユーザーのステータスを確認し、要求を返します。返送される要求には、成功または失敗の情報が設定されます。

  5. カスタム認証モジュールは、手順 4 で返されたステータスに基づいてユーザーを検証し、対応するステータスを認証サービスに返します。

  6. ユーザーの認証は成功または失敗で完了します。

CR# 6324056: アーティファクトプロファイルを使用したときに連携が失敗する

回避方法: この問題を修正するには、「Core Mobile Access」パッチの最新バージョンを適用します。このバージョンは、プラットフォームに応じて次のようになります。

パッチを適用したあと、Web コンテナを再起動します。

Access Manager 7 2005Q4 パッチ 2

Access Manager 7 2005Q4 パッチ 2 (リビジョン 02) により、いくつかの問題が修正されます。その一覧はパッチに含まれている README ファイルに記載されています。パッチ 2 には、次に示す新機能と既知の問題があります。

パッチ 2 での新機能

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

ユーザー管理、アイデンティティーリポジトリ、およびサービス管理キャッシュの新しいプロパティー

パッチ 2 には、ユーザー管理 (Access Manager SDK)、アイデンティティーリポジトリ (IdRepo)、およびサービス管理キャッシュ用に次のような新しいプロパティーも含まれています。これらのプロパティーを使用すると、配備要件に基づいてさまざまなキャッシュを個別に有効または無効にしたり、キャッシュエントリの有効時間 (TTL) を設定したりできます。

表 3 ユーザー管理、アイデンティティーリポジトリ、およびサービス管理キャッシュの新しいプロパティー

プロパティー 

説明 

キャッシュを有効および無効にするための新しいプロパティー

com.iplanet.am.sdk.caching.enabled

アイデンティティーリポジトリ (IdRepo)、ユーザー管理、およびサービス管理キャッシュを有効 (true) または無効 (false) にするグローバルプロパティー。true であるか、このプロパティーが AMConfig.properties ファイル内に存在しない場合は、3 つのキャッシュすべてが有効になります。

注: 特定のキャッシュを有効または無効にする次の 3 つのプロパティーは、上記のグローバルプロパティーが false に設定されている場合のみ適用されます。

com.sun.identity.amsdk.cache.enabled

ユーザー管理 (Access Manager SDK) キャッシュのみを有効 (true) または無効 (false) にします。 

com.sun.identity.idm.cache.enabled

アイデンティティーリポジトリ (IdRepo) キャッシュのみを有効 (true) または無効 (false) にします。 

com.sun.identity.sm.cache.enabled

サービス管理キャッシュのみを有効 (true) または無効 (false) にします。 

TTL に関する新しいユーザー管理キャッシュのプロパティー

com.iplanet.am.sdk.cache.entry.expire.enabled

ユーザー管理キャッシュの有効時間 (次の 2 つのプロパティーで定義) を有効 (true) または無効 (false) にします。 

com.iplanet.am.sdk.cache.entry.user.expire.time

最終変更後にユーザー管理キャッシュのユーザーエントリを有効なままにしておく時間 (分) を指定します。つまり、(最終変更後またはディレクトリからの読み取り後) 指定した時間を過ぎたら、キャッシュされたエントリのデータは期限切れになります。その後は、これらのエントリのデータに対する新しい要求をディレクトリから読み取る必要があります。 

com.iplanet.am.sdk.cache.entry.default.expire.time

最終変更後にユーザー管理キャッシュのユーザー以外のエントリを有効なままにしておく時間 (分) を指定します。つまり、(最終変更後またはディレクトリからの読み取り後) 指定した時間を過ぎたら、キャッシュされたエントリのデータは期限切れになります。その後は、これらのエントリのデータに対する新しい要求をディレクトリから読み取る必要があります。TTL に関する新しいアイデンティティーリポジトリキャッシュのプロパティー  

com.sun.identity.idm.cache.entry.expire.enabled

IdRepo キャッシュの有効時間 (次のプロパティーで定義) を有効 (true) または無効 (false) にします。  

com.sun.identity.idm.cache.entry.default.expire.time

最終変更後に IdRepo キャッシュのユーザー以外のエントリを有効なままにしておく時間 (分) を指定します。つまり、(最終変更後またはリポジトリからの読み取り後) 指定した時間を過ぎたら、キャッシュされたエントリのデータは期限切れになります。その後は、これらのエントリのデータに対する新しい要求をリポジトリから読み取る必要があります。 

新しいキャッシュプロパティーの使用

Access Manager 7 2005Q4 のパッチでは、新しいキャッシュプロパティーは AMConfig.properties ファイルに自動的に追加されません。

新しいキャッシュプロパティーを使用するには、次の手順に従います。

  1. テキストエディタを使用して、各プロパティーとその値を AMConfig.properties ファイルに追加します。このファイルはプラットフォームによって次のディレクトリにあります。

    • Solaris システム: /etc/opt/SUNWam/config

    • Linux システム: /etc/opt/sun/identity/config

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

連携サービスプロバイダの新しいプロパティー

新しい com.sun.identity.federation.spadapter プロパティーは、com.sun.identity.federation.plugins.FederationSPAdapter の実装クラスを定義します。これは、サービスプロバイダ側で連携処理中にアプリケーション固有の処理を追加するために使用されます。

「CR# 6385696: 既存および新規の IDP と SP が表示されない」も参照してください。

LDAP フィルタ条件のサポート

パッチ 2 には LDAP フィルタ条件のサポートが追加されています。ポリシー管理者は、ポリシーを定義するときに、LDAP フィルタを条件に指定できるようになりました。ユーザーの LDAP エントリが、条件で指定されている LDAP フィルタを満たす場合のみ、ユーザーにポリシーが適用されます。ユーザーの LDAP エントリは、ポリシー設定サービスで指定されているディレクトリから検索されます。

LDAP フィルタ条件を登録して使用するには、Access Manager 7 パッチ 2 のインストール後に次のコマンドを実行します (Access Manager が Solaris システムのデフォルトディレクトリにインストールされている場合の例)。

# /opt/SUNWam/bin/amadmin -u amadmin 
-w amadmin_password 
-s /etc/opt/SUNWam/AddLDAPFilterCondition.xml
# /opt/SUNWam/bin/amadmin -u amadmin 
-w amadmin_password 
-t /etc/opt/SUNWam/amPolicyConfig_mod_ldfc.xml

パッチ 5 に関する注: Access Manager 7 2005Q4 パッチ 5 を追加して updateschema.sh スクリプトを実行した場合は、amadmin を使用してこれらのファイルを読み込む必要はありません。詳細は、「LDIF ファイルと XML ファイルを読み込む新しい updateschema.sh スクリプト」を参照してください。

CR# 6283582: Access Manager インスタンスの間でログイン失敗回数が共有されない

Access Manager 7 パッチ 2 のインストール後、次のコマンドを実行します (Access Manager が Solaris システムのデフォルトディレクトリにインストールされている場合の例)。

# cd DirectoryServer-base/shared/bin
# ./ldapmodify -h DirectoryServerHost -p DirectoryServerPort 
-D "cn=Directory Manager" -w DirectoryMangerPassword 
-a -f /etc/opt/SUNWam/accountLockout.ldif
# /opt/SUNWam/bin/amadmin -u amadmin 
-w amadmin_password 
-t /etc/opt/SUNWam/accountLockoutData.xml

DirectoryServer-base のデフォルト値は、Solaris システムでは /var/opt/mps/serverroot、Linux システムでは /var/opt/sun/directory-server です。

パッチ 5 に関する注: Access Manager 7 2005Q4 パッチ 5 を追加して updateschema.sh スクリプトを実行した場合は、amadmin を使用してこれらのファイルを読み込む必要はありません。詳細は、「LDIF ファイルと XML ファイルを読み込む新しい updateschema.sh スクリプト」を参照してください。

CR# 6293673: セッションタイムアウトの通知を送信するときに元のセッション情報を保持する必要がある

AMConfig.properties ファイル内の新しい com.sun.identity.session.property.doNotTrimList プロパティーは、セッションプロパティー名のリストをコンマ区切り形式で保持できます。セッションがタイムアウトしても、このリストに定義されているプロパティーは削除されず、セッションが破棄されるまではこれらのプロパティーにアクセスできます。次に例を示します。

com.sun.identity.session.property.doNotTrimList=UserId,HostName

CR# 6244578: ブラウザの cookie のサポートが無効または使用不可の場合は、Access Manager でユーザーに警告するようにする

AMConfig.properties ファイル内の新しい com.sun.identity.am.cookie.check プロパティーは、ブラウザで cookie がサポートされ有効になっていることをサーバーでチェックするかどうかを指定します。値が true の場合、サーバーはブラウザで cookie がサポートされ有効になっているかどうかをチェックし、ブラウザで cookie がサポートされていないか有効になっていないときはエラーページをスローします。サーバーが認証機能で cookie なしモードをサポートするように想定されている場合は、この値を (デフォルトの) false に設定するようにしてください。

CR# 6236892: ログイン後に CDCServlet で AuthNResponse を処理するときの画像/テキストのプレースホルダ

次に示す新しいプロパティーが AMConfig.properties ファイルに追加されています。これらは CDCServlet で読み取られます。

CR# 6363157: どうしても必要な場合に、新しいプロパティーで持続検索を無効にする

AMConfig.properties ファイル内の新しい com.sun.am.event.connection.disable.list プロパティーは、無効にできるイベント接続を指定します。指定できる値は次のとおりです。大文字と小文字は区別されません。

aci - LDAP フィルタ (aci=*) を使用した検索における aci 属性の変更。

sm - Access Manager 情報ツリー (またはサービス管理ノード) の変更。これには、sunService または sunServiceComponent マーカーオブジェクトクラスを持つオブジェクトが含まれます。たとえば、保護されたリソースのアクセス権限を定義するためのポリシーを作成する場合や、既存のポリシーのルール、対象、条件、または応答プロバイダを変更する場合があります。

um - ユーザーディレクトリ (またはユーザー管理ノード) の変更。たとえば、ユーザーの名前やアドレスを変更する場合があります。

たとえば、Access Manager 情報ツリー (またはサービス管理ノード) の変更に対する持続検索を無効にする場合は、次のようになります。

com.sun.am.event.connection.disable.list=sm

複数の値を指定する場合は、各値をコンマで区切って記述します。

注意 – 注意 –

持続検索により、Directory Server にパフォーマンスオーバーヘッドが発生します。本稼働環境でこのパフォーマンスオーバーヘッドの一部を削減することが決定的に重要だと判断される場合は、com.sun.am.event.connection.disable.list プロパティーを使用して、1 つ以上の持続検索を無効にできます。

ただし、持続検索を無効にする前に、先に述べた制限事項を理解するようにしてください。どうしても必要な場合以外は、このプロパティーを変更しないことを強くお勧めします。複数の 2.1 J2EE エージェントを使用すると、それぞれのエージェントがこれらの持続検索を確立するため、このプロパティーはそのような場合に Directory Server に対するオーバーヘッドを回避することを主な目的として導入されました。2.2 J2EE エージェントは、これらの持続検索を確立しないため、このプロパティーを使用する必要はない可能性があります。

詳細は、「持続検索の無効化の詳細について (6486927)」を参照してください。

CR# 6385696: 既存および新規の IDP と SP が表示されない

AMConfig.properties ファイル内の新しい com.sun.identity.federation.spadapter プロパティーは、アプリケーションが表明や応答情報を取得できる連携サービスプロバイダアダプタのデフォルトの実装を指定します。次に例を示します。

com.sun.identity.federation.spadapter=com.sun.identity.federation.plugins.FSDefaultSPAdapter

Access Manager 7 2005Q4 パッチ 1

Access Manager 7 2005Q4 パッチ 1 (リビジョン 01) により、いくつかの問題が修正されます。その一覧はパッチに含まれている README ファイルに記載されています。パッチ 1 には、次に示す新機能と既知の問題があります。

デバッグファイルの作成

Access Manager のデバッグファイルは、AMConfig.properties ファイル内の com.iplanet.services.debug.level プロパティーが error に設定されている場合でも、デバッグディレクトリ内にデフォルトで作成されます。Access Manager 7 パッチ 1 がリリースされる前は、最初のデバッグメッセージがデバッグファイルに記録されるときにはじめてファイルが作成されていました。

LDAPv3 プラグインでのロールとフィルタを適用したロールのサポート

Access Manager 7 パッチ 1 では、データを Sun Java System Directory Server に保存する場合の、LDAPv3 プラグインでのロールとフィルタを適用したロールのサポートを追加しています。詳細については、「LDAPv3 プラグインのロールおよびフィルタを適用したロールのサポートについて (6365196)」を参照してください。

CR# 6320475: サーバー側の com.iplanet.am.session.client.polling.enable を true にしてはいけない

AMConfig.properties ファイル内の com.iplanet.am.session.client.polling.enable プロパティーは、サーバー側でデフォルトで false に設定されており、true にリセットしてはいけません。

CR# 6358751: 暗号化鍵にスペースが含まれていると Access Manager 7 パッチ 1 の適用が失敗する

パスワードの暗号化鍵にスペースが含まれていると、パッチの適用が失敗します。

回避方法: スペースを含んでいない新しい暗号化鍵を使用します。暗号化鍵を変更するための詳細な手順については、『Sun Java System Access Manager 7 2005Q4 配備計画ガイド』の付録 B「パスワード暗号化キーの変更」を参照してください。