Access Manager 7 パッチ 5 (リビジョン 05) により、いくつかの問題が修正されます。その一覧はパッチに含まれている README ファイルに記載されています。パッチ 5 には、次の新機能、問題、および変更されたマニュアルが含まれています。
パッチ 5 での新機能
パッチ 5 での既知の問題点と制限事項
「CR# 6567746: HP-UX システムでパスワード再試行回数を超過した場合、Access Manager パッチ 5 は間違ったエラーコード値を報告する」
「CR# 6527663: com.sun.identity.log.resolveHostName プロパティーのデフォルト値を true ではなく false にする」
「CR# 6527528: パッチを削除すると、クリアテキスト形式の amldapuser パスワードを含む XML ファイルが残る」
「CR# 6527516: WebLogic 上のフルサーバーでは JAX-RPC 1.0 JAR ファイルがクライアント SDK と通信する必要がある」
「CR# 6523499: パッチ 5 の amsilent ファイルが Linux システム上のすべてのユーザーに対して読み込み可能になっている」
「CR# 6520016: パッチ 5 の SDK のみのインストールで、samples ディレクトリ内の Makefile が上書きされる」
「CR# 6508103: Windows システム上の Application Server で、オンラインヘルプにアプリケーションエラーが返される」
「CR# 6507383 および CR# 6507377: 分散認証には明示的な goto URL パラメータが必要である」
「CR# 6402167: LDAP JDK 4.18 によって LDAP クライアント/Directory Server に問題が発生する」
「CR# 6513653: com.iplanet.am.session.purgedelay プロパティーの設定で問題が発生する」
国際化 (g11n) に関する問題
「CR# 6522720: Windows および HP-UX システム上では、複数バイト文字を用いてコンソールオンラインヘルプの検索ができない」
「CR# 6524251: Windows システム上での Access Manager の設定中に、出力メッセージ内の複数バイト文字が文字化けする」
「CR# 6526940: 英語以外のロケールの Windows システムに対するパッチ 5 のインストール中に、メッセージテキストではなくプロパティーキーが表示される」
変更されたマニュアル
パッチ 126371 は、HP-UX システムに対するサポートを提供します。詳細については、次のトピックを参照してください。
HP-UX システムへのインストールについては、『Sun Java Enterprise System 2005Q4 インストールガイド(UNIX 版)』を参照してください。
パッチ 124296 は、Windows システムに対するサポートを提供します。詳細については、次のトピックを参照してください。
Windows システムへのインストールについては、『Sun Java Enterprise System 2005Q4 Installation Guide for Microsoft Windows』を参照してください。
パッチ 5 以降のパッチには、次のファイルを読み込んで Directory Server サービススキーマを更新する updateschema.sh スクリプトが含まれています。
AddLDAPFilterCondition.xml
amPolicyConfig_mod_ldfc.xml
accountLockoutData.xml
accountLockout.ldif
idRepoServiceAddAttrSchemaRequest_Cache.xml
wsf1.1_upgrade.xml
amAuth_mod.xml
amAuthCert_mod.xml
Access Manager の以前のリリースでは、これらのファイルを手動で読み込む必要がありました。
updateschema.sh スクリプトを実行するには、次の手順に従います。
スーパーユーザー (root) としてログインします。
パッチディレクトリに移動します。
スクリプトを実行します。Solaris システムの場合の例を示します。
# cd /120954-07 # ./updateschema.sh
Windows システムでは、このスクリプトの名前は updateschema.pl です。
スクリプトからユーザーの入力を要求されたら、次の項目を入力します。
Directory Server のホスト名とポート番号
Directory Server の管理ユーザー DN とパスワード
amadmin DN とパスワード
スクリプトが入力内容を検証し、ファイルを読み込みます。このスクリプトは次のログファイルも書き込みます。
Solaris システム: /var/opt/SUMWam/logs/AM70Patch.upgrade.schema. timestamp
Linux システム: /var/opt/sun/identity/logs/AM70Patch.upgrade.schema. timestamp
スクリプトの実行が終了したら、Access Manager Web コンテナを再起動します。
注: パッチ 5 をバックアウトした場合、updateschema.sh スクリプトによって追加されたスキーマの変更は Directory Server から削除されません。ただし、パッチをバックアウトしたあとで、これらの変更が Access Manager の機能や使い勝手に影響を与えることはないため、これらの変更を手動で削除する必要はありません。
パッチ 5 では、アプリケーションごとに異なるセッションアイドルタイムアウト値を設定できます。企業では、セッションサービスに指定されたセッションアイドルタイムアウトより小さいセッションアイドルタイムアウト値が一部のアプリケーションで必要になる場合があります。たとえば、セッションサービスのセッションアイドルタイムアウト値を 30 分に指定したが、HR アプリケーションはユーザーが 10 分以上アイドル状態だったらタイムアウトするべきである場合などです。
この機能を使用するための要件は、次のとおりです。
アプリケーションを保護するエージェントは、Access Manager から URL ポリシー決定を適用するように設定する必要があります。
エージェントは、自己ポリシー決定キャッシュモードで動作するように設定する必要があります。次のプロパティーを参照してください。
Web エージェントの場合: com.sun.am.policy.am.fetch_from_root_resource
J2EE エージェントの場合: com.sun.identity.policy.client.cacheMode
Access Manager の AMConfig.properties ファイルで、条件が最後に評価されるようにポリシーコンポーネントの評価順序を指定する必要があります。次のプロパティーを参照してください。
com.sun.identity.policy.Policy.policy_evaluation_weights
エージェントがローカルにキャッシュされた決定に基づいて許可したアプリケーションアクセスは、Access Manager の条件では認識されません。このため、実際のアプリケーションアイドルタイムアウトの範囲は、アプリケーションのアイドルタイムアウト値から、アプリケーションのアイドルタイムアウトからエージェントのキャッシュ期間を引いた値までになります。
この機能を使用するには、次の手順に従います。
アプリケーション固有のセッションアイドルタイムアウトを必要とするアプリケーションを保護するポリシーに認証方式条件を追加します。
認証方式条件にアプリケーション名とタイムアウト値を指定します。
アプリケーションのリソースに適用されるすべてのポリシーで、同じアプリケーション名とタイムアウト値を使用します。
タイムアウト値は分単位で指定します。値が 0 であるか、セッションサービスに指定されたセッションアイドルタイムアウト値より大きい場合、その値は無視され、セッションサービスのタイムアウトが適用されます。
たとえば次の認証方式条件を持つポリシー http://host.sample.com/hr/* があるとします。
認証方式: LDAP
アプリケーション名: HR
タイムアウト値: 10
HR アプリケーションのリソースを保護するために定義されたポリシーが複数ある場合は、すべてのポリシーに条件を追加してください。
個別のセッション内のユーザーが Access Manager エージェントによって保護された HR アプリケーションにアクセスしようとすると、そのユーザーは LDAP 方式への認証を要求されます (ユーザーがまだ認証されていない場合)。
ユーザーがすでに LDAP 方式に認証されている場合は、最後に認証が行われた時間またはそのユーザーが HR アプリケーションに最後にアクセスした時間から 10 分以上経過していなければ、そのユーザーにアクセスが許可されます。それ以外の場合は、ユーザーがアプリケーションにアクセスしようとすると、再度 LDAP 方式への認証が要求されます。
DMZ 内で CDC サーブレットと分散認証 UI サーバーを共存させることにより、クロスドメインシングルサインオン (CDSSO) を使用可能にできます。Access Manager サーバーは、ファイアウォールの背後に配備できるため、CDSSO を実現するために行われる Access Manager へのすべてのアクセスは、分散認証 UI サーバー内の CDC サーブレットによって処理されます。CDSSO を使用可能にするには、各ポリシーエージェントのマニュアルを参照し、次の追加手順を実行してください。
エージェントの AMAgent.properties ファイルを変更して、分散認証側 (クライアント) の CDC サーブレットをポイントします。たとえば、Web エージェントの場合は、次のプロパティーを変更します。
com.sun.am.policy.agents.config.cdcservlet.url= http://DAhost.DAdomain:DAport/DISTAUTH_DEPLOY_URI/cdcservlet
Access Manager で、エージェントで保護する必要があるリソースのポリシーを必要に応じて定義します。たとえば、エージェントが host.example.com:80 にある場合は、リソースのポリシーを http://host.example.com:80/* として定義します。
CDC サーブレットに対してレルム名を指定すると、Access Manager のログイン URL へのリダイレクトが発生したときにレルム名が取り込まれ、ユーザーは特定のレルムにログインできます。次に例を示します。
com.sun.am.policy.agents.config.cdcservlet.url= http://lb.example.com/amserver/cdcservlet?org=realm1
従来の証明書認証では、ユーザープロファイルをマップするために subjectDN の dn コンポーネントだけが使用されていました。現在の Access Manager では、プロファイルのマッピングに SubjectAltNameExt のユーザー主体名 (UPN) の値を使用できます。
複数サーバー環境で、ユーザーが最初にログインしたサーバーとは別のサーバーをログアウトすると、セッションフェイルオーバーが設定されているかどうかに関係なく、認証ポストプロセスが発生します。
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 ファイルに追加されません。これらの新しいプロパティーをデフォルト値以外の値で使用するには、次の手順に従います。
AMConfig.properties ファイルにプロパティーとその値を追加します。ポリシーエージェントの場合は、これらのプロパティーを AMAgents.properties ファイルに追加します。
Access Manager Web コンテナを再起動して、値を有効にします。
たとえば、次のような場合です。サイトに、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 オプションを使用します。
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 コンテナに配備したあと、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 コンテナを調整するには、次の手順に従います。
分散認証 UI サーバーが配備されているシステムには Access Manager サーバーがインストールされていないため、(上の表に示した) 該当する Web コンテナのチューニングスクリプト、amtune-env 設定ファイル、および amtune-utils スクリプトを Access Manager サーバーインストールからコピーします。Solaris または Linux オペレーティングシステムを調整する場合は、amtune-os スクリプトもコピーします。
amtune-env 設定ファイルのパラメータを編集して、Web コンテナとチューニングのオプションを指定します。スクリプトを REVIEW モードで実行するため、amtune-env ファイルに AMTUNE_MODE=REVIEW を設定します。
Web コンテナのチューニングスクリプトを REVIEW モードで実行します。REVIEW モードでは、スクリプトは amtune-env ファイルの値に従ってチューニングによる変更箇所を示しますが、配備に対する実際の変更は行いません。
デバッグログファイルで、推奨されるチューニングを確認します。必要な場合は、この実行結果に基づいて amtune-env ファイルに変更を加えます。
チューニングによる変更を行うため、amtune-env ファイルに AMTUNE_MODE=CHANGE を設定します。
チューニングスクリプトを CHANGE モードで実行し、配備に対してチューニングによる変更を行います。
チューニングスクリプトを実行して Access Manager Web コンテナを調整する方法の詳細は、『Sun Java System Access Manager 7 2005Q4 Performance Tuning Guide』の第 2 章「Access Manager Tuning Scripts」を参照してください。
パッチ 5 には、Solaris OS と Linux OS の両方を調整する amtune-os スクリプトが含まれています。このスクリプトは、uname -s コマンドの結果から OS の種類を判定します。従来の Access Manager には、各 OS を調整するために別々の amtune-os スクリプトが用意されていました。
Solaris 10 のローカルゾーンに Access Manager がインストールされている場合は、amtune-os 以外のすべてのチューニングスクリプトをローカルゾーンで実行できます。amtune-os スクリプトは、ローカルゾーンでは警告メッセージを表示し、OS のチューニングを行いません。その後、要求されたほかのチューニングスクリプトの実行を継続します。従来は、ローカルゾーンでは、amtune-os スクリプトは中断し、要求された後続のチューニングスクリプトは実行されませんでした。
Solaris 10 の大域ゾーンでは、amtune スクリプトが実行を要求されたほかのスクリプトとともに amtune-os を呼び出して OS を調整します。
パッチ 5 には、Windows システム用のチューニングスクリプトが含まれています。Windows システムでのチューニングスクリプトの実行は、Solaris システムや Linux システムでの実行とほぼ同じですが、次のような違いがあります。
Windows のスクリプトは Perl で作成されているため、Active Perl 5.8 を実行する必要があります。
Directory Server を調整する場合は、amtune-prepareDSTuner.pl スクリプトを実行したあと、amtune-utils.pl、amtune-directory.pl、remacis.ldif、および amtune-samplepassordfile ファイルを Directory Server システムにコピーしてください。これは、このスクリプトがこれらのファイルを圧縮できないためです。
Windows オペレーティングシステムを調整するスクリプトは用意されていません。
ゾーンのサポートは提供されていません。
スクリプトを実行する前に、amtune-env.pl ファイルの $BASEDIR パラメータを Access Manager のインストールディレクトリに設定してください。
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 サーバーのコア数に応じて、このプロパティーをさらに小さい値に設定できます。
Microsoft Internet Information Services (IIS) 6.0 の基本認証を有効にするには、ポリシーエージェントがユーザーの名前とパスワードを取得する必要があります。パッチ 5 には、ユーザーのパスワードの DES 暗号化を使用してこの機能を有効にする次の新しいクラスが含まれています。
DESGenKey.java は、ユーザーのパスワードの暗号化と復号化に使用される一意の鍵を生成します。
ReplayPasswd.java は、AMConfig.properties ファイルの com.sun.am.replaypasswd.key プロパティーから暗号化鍵の値を読み取り、パスワードを暗号化し、それを sunIdentityUserPassword セッションプロパティーに割り当てます。
IIS 6.0 の基本認証を使用するには、Access Manager サーバー側と IIS 6.0 ポリシーエージェント側の両方の手順を実行する必要があります。
Access Manager サーバー側では、次の手順に従います。
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
手順 1 で得られた暗号化鍵を AMConfig.properties ファイルの com.sun.am.replaypasswd.key プロパティーに割り当てます。
ReplayPasswd.java を認証後プラグインとして配備します。プラグインを設定するときは、次のように完全なクラス名を使用します。 com.sun.identity.authentication.spi.ReplayPasswd
IIS 6.0 ポリシーエージェント側では、次の手順に従います。
サーバー側で得られた暗号化鍵の値を AMAgent.properties ファイルの com.sun.am.replaypasswd.key プロパティーに割り当てます。Access Manager サーバーと IIS 6.0 ポリシーエージェントの両方で同じ暗号鍵を使用してください。
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』を参照してください。
ユーザーのアカウントがロックされている場合、パスワード再試行回数を超過すると、HP-UX システムの Access Manager 7 2005Q4 パッチ 5 は errorCode = 107 ではなく errorCode = null を報告します。
回避方法: なし。
amtune-identity チューニングスクリプトを実行する前に、false に設定した次のプロパティーを AMConfig.properties ファイルに追加することをお勧めします。
com.sun.identity.log.resolveHostName=false
値を false にすることで、ホスト名解決の負担が最小限に抑えられ、パフォーマンスが向上します。ただし、クライアントマシンのホスト名を amAuthentication.access ログに出力する場合は、この値を true に設定してください。
Access Manager のフルサーバーインストールからパッチ 5 を削除すると、amAuthLDAP.xml ファイルと amPolicyConfig.xml ファイルに、クリアテキスト形式の amldapuser パスワードが含まれています。これらのファイルは、使用中のプラットフォームに応じて、次のディレクトリにあります。
Solaris システム: /etc/opt/SUNWam/config/xml
Linux および HP-UX システム: /etc/opt/sun/identity/config/xml
回避方法: amAuthLDAP.xml ファイルと amPolicyConfig.xml ファイルを編集して、クリアテキスト方式のパスワードを削除します。
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 を設定します。
Access Manager サーバーで、スーパーユーザー (root) としてログインするか、スーパーユーザーになります。
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 インスタンスを再起動します。
Linux システムでは、postpatch スクリプトは、すべてのユーザーに読み取りアクセスを許可する 644 のアクセス権で /opt/sun/identity/amsilent ファイルを作成します。
回避方法: installpatch スクリプトを実行したあとで、所有者だけに読み取りと書き込みのアクセスを許可するように amsilent ファイルのアクセス権を変更します。次に例を示します。
# chmod 600 /opt/sun/identity/amsilent
この配備シナリオでは、2 つの Access Manager インスタンスが同じホストサーバーに配備され、各インスタンスは異なる Web コンテナインスタンス上にあります。次の手順を実行します。
パッチ 5 を適用します。
amsilent ファイルを変更し、1 つめの Access Manager インスタンスを再配備します。
2 つめの Access Manager インスタンスのために再度 amsilent を変更し、そのインスタンスを再配備します。
amsilent ファイルに NEW_INSTANCE=false が設定されていると、1 つめの Access Manager インスタンス用の serverconfig.xml ファイルが 2 つめの Access Manager インスタンスの情報で上書きされます。それ以降、1 つめの Access Manager インスタンスの再起動は失敗します。serverconfig.xml ファイルは、使用中のプラットフォームに応じて、次のディレクトリにあります。
Solaris システム: /etc/opt/SUNWam/config
Linux システム: /etc/opt/sun/identity/config
回避方法: 2 つめの Access Manager を配備するときに、amsilent ファイルに NEW_INSTANCE=true を設定します。2 つめの Access Manager インスタンス用の serverconfig.xml ファイルが正しい情報で更新され、1 つめの Access Manager インスタンス用の serverconfig.xml ファイルが上書きされません。
パッチ 5 を SDK のみのマシンに適用すると、samples ディレクトリ内の Makefile が上書きされます。
回避方法: パッチ 5 を SDK のみのマシンに適用するときは再設定の必要はありませんが、samples ディレクトリ内の Makefile を使用する場合は、次の手順に従って samples ディレクトリ内の Makefile の LDIF ファイルとプロパティーファイルを更新します。つまり、タグスワッピングを実行します。
DEPLOY_LEVEL=14 で amconfig スクリプトを実行することにより、SDK をアンインストールして Web コンテナを設定解除します。
DEPLOY_LEVEL=4 で amconfig スクリプトを実行することにより、SDK を再インストールして Web コンテナを再設定します。
ほとんどの検索では、この問題は修正されています。ただし、エイリアス検索属性を設定するときは注意してください。エイリアス検索属性の値を組織内で一意にする必要があります。複数のエイリアス検索属性が設定された場合は、データストア内のあるエントリが一方の属性に一致し、別のエントリがもう一方の属性に一致する可能性があります。このような場合、Access Manager サーバーは次のエラーをスローします。
An internal authentication error has occurred. Contact your system administrator.
回避方法: なし
分散認証 UI サーバーと J2EE ポリシーエージェントは、同じ Web コンテナにインストールすると動作しません。
回避方法: 2 つめの Web コンテナインスタンスを作成し、分散認証 UI サーバーと J2EE ポリシーエージェントを Web コンテナの異なるインスタンスに配備します。
Windows システム上の Sun Java System Application Server に Access Manager を配備した場合、レルムモードコンソールで「ヘルプ」をクリックすると、ヘルプ画面の左側のパネルにアプリケーションエラーが返されます。
回避方法: javaes-install-dir\share\lib\jhall.jar ファイルを JAVA_HOME\jre\lib\ext ディレクトリにコピーし、Application Server を再起動します。
明示的な goto URL パラメータを指定しなかった場合、分散認証 UI サーバーは Access Manager に指定された成功 URL の goto にリダイレクトしようとします。このリダイレクトは、次の理由で失敗することがあります。
URL が相対的で、対応するページが分散認証 UI サーバーに用意されていない
URL が絶対的で、ブラウザが URL に到達できない
回避方法: 分散認証 UI サーバーに対して、常に明示的な goto URL パラメータを指定します。
Access Manager 7 2005Q4 は、Java ES 2005Q4 リリースの一部である LDAP JDK 4.18 とともにリリースされましたが、その結果、Access Manager と Directory Server の通信にさまざまな問題が発生しました。
回避方法: 次のいずれかの Sun Java System LDAP Java Development Kit パッチを適用します。
Solaris OS、SPARC、および x86 プラットフォーム: 119725-04
Linux OS: 120834-02
これらのパッチは、SunSolve Online (http://sunsolve.sun.com) から入手できます。
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 ディレクトリにコピーしてください。
Access Manager が日本語などの複数バイト文字を使用するロケールで Windows システムまたは HP-UX システムにインストールされている場合、複数バイト文字を使用して入力されたキーワードによるコンソールオンラインヘルプの検索はできません。
回避方法: なし
パッチ 6 での更新情報: Windows システムでは、この問題は Access Manager 7 2005Q4 パッチ 6 で修正されます。ただし、HP-UX システムではこの問題が引き続き存在します。
Access Manager が日本語や中国語などの Windows システムにインストールされている場合、Access Manager の設定中に端末ウィンドウに出力されるメッセージ内の複数バイト文字が文字化けします。
回避方法: なし。ただし、この問題は設定自体には影響しません。
英語以外のロケールの Windows システムにパッチ 5 (124296-05) をインストールすると、インストールパネルの一部の文字列が実際のメッセージテキストではなくプロパティーキーとして表示されます。表示されるプロパティーキーは、たとえば、PRODUCT_NAME、JES_Patch_FinishPanel_Text1、JES_Patch_FinishPanel_Text2 などです。
回避方法: なし
Access Manager の amtune スクリプトは、できるだけ多くの Access Manager セッションを許可するため、com.iplanet.am.session.purgedelay プロパティーを 1 に設定します。このプロパティーは、パージセッション操作を遅延する時間を分単位で指定します。ただし、Sun Java System Portal Server などのクライアントでは、値が 1 では不十分な場合があります。
回避方法: amtune スクリプトを実行したあとで、次のようにして com.iplanet.am.session.purgedelay プロパティーをリセットします。
AMConfig.properties ファイルで、このプロパティーを新しい値に設定します。次に例を示します。
com.iplanet.am.session.purgedelay=5
Access Manager Web コンテナを再起動して、新しい値を有効にします。