test

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

既知の問題点と制限事項

この節では、リリース時での、次の既知の問題点、および利用可能な場合は回避方法について説明します。

互換性の問題

Java ES 2004Q2 サーバーと Java ES 2005Q4 上の IM との間に互換性がない (6309082)

次の配備シナリオでは問題が発生します。

imconfig ユーティリティーを実行してサーバー-4 上の Instant Messaging を設定しても、設定は成功しません。サーバー -4 上の Instant Messaging (IM) で使用される Access Manager 7 2005Q4 SDK は、Java ES 2004Q2 リリースと互換性がありません。

回避方法: Access Manager サーバーおよび Access Manager SDK は、同じリリースであることが理想的です。詳細は、『Sun Java Enterprise System 2005Q4 アップグレードガイド』を参照してください。

旧バージョンモードでコア認証モジュールに非互換性が存在する (6305840)

Access Manager 7 2005Q4 旧バージョンモードでは、Access Manager 6 2005Q1 からのコア認証モジュールに次の非互換性があります。

回避方法: なし。

「組織にプロファイルがない」ために、エージェントがログインできない (6295074)

Access Manager コンソールで、エージェントをレルムモードで作成します。ログアウトしてからエージェント名を使用してもう一度ログインすると、エージェントはレルムにアクセスする権限がないため、Access Manager はエラーを返します。

回避方法: エージェントに対して読み取り/書き込みアクセスができるように、アクセス権を変更します。

Delegated Administrator commadmin ユーティリティーがユーザーを作成しない (6294603)

Delegated Administrator commadmin ユーティリティーを -S mail,cal オプションで使用すると、デフォルトドメインにユーザーが作成されません。

回避方法: この問題は、Access Manager をバージョン 7 2005Q4 にアップブレードして Delegated Administrator をアップグレードしなかった場合に発生します。Delegated Administrator のアップグレードについては、『Sun Java Enterprise System 2005Q4 アップグレードガイド』を参照してください。

Delegated Administrator をアップグレードする予定がない場合は、次の手順を実行します。

  1. UserCalendarService.xml ファイルで、mail、icssubcribed、および icsfirstday 属性を必須ではなく省略可能としてマークします。このファイルはデフォルトで、Solaris システム上の /opt/SUNWcomm/lib/services/ ディレクトリにあります。

  2. Access Manager で次のように amadmin コマンドを実行して、既存の XML ファイルを削除します。

    # ./amadmin -u amadmin -w password -r UserCalendarService

  3. Access Manager で、更新した XML ファイルを次のように追加します。

    # ./amadmin -u amadmin -w password 
-s /opt/SUNWcomm/lib/services/UserCalendarService.xml

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

Delegated Administrator commadmin ユーティリティーが組織を作成しない (6292104)

Delegated Administrator commadmin ユーティリティーを -S mail,cal オプションで使用すると、組織が作成されません。

回避方法: 前の問題の回避方法を参照してください。

インストールに関する問題

パッチ 1 の適用後、/tmp/amsilent ファイルがすべてのユーザーの読み取りアクセスを許可する (6370691)

パッチ 1 の適用後、/tmp/amsilent ファイルはすべてのユーザーに読み取りアクセスを許可します。

回避方法: パッチの適用後、Access Manager 管理者のみ読み取りアクセスを許可するように、ファイルのアクセス権をリセットします。

SDK インストールでコンテナ設定を行う際に、通知 URL が正しくない (6327845)

SDK のインストールをコンテナ設定 (DEPLOY_LEVEL=4) とともに実行すると、通知 URL が正しくありません。

回避方法:

  1. AMConfig.properties ファイルで、次のプロパティーを設定します。

    com.iplanet.am.notification.url=
protocol://fqdn:port/amserver/servlet/com.iplanet.services.comm.client.
PLLNotificationServlet

  2. Access Manager を再起動すると、新しい値が有効になります。

Access Manager classpath が、有効期限の切れた JCE 1.2.1 パッケージを参照する (6297949)

Access Manager classpath が、2005 年 7 月 27 日に期限が切れた Java Cryptography Extension (JCE) 1.2.1 パッケージ (署名証明書) を参照しています。

回避方法: なし。パッケージ参照が classpath にあっても、Access Manager はそのパッケージを使用しません。

Access Manager を既存の DIT にインストールすると、Directory Server のインデックスの再作成が必要になる (6268096)

検索のパフォーマンスを改善するため、Directory Server ではいくつかの新しいインデックスを用意しています。

回避方法: Access Manager を既存の Directory Information Tree (DIT) とともにインストールした後、Directory Server のインデックスを db2index.pl スクリプトを実行して再作成します。次に例を示します。

# ./db2index.pl -D "cn=Directory Manager" -w password -n userRoot

db2index.pl スクリプトは DS-install-directory/slapd-hostname/ ディレクトリから利用可能です。

root ではないユーザーのログディレクトリおよびデバッグディレクトリのアクセス権が正しくない (6257161)

サイレントインストール設定ファイルで root ではないユーザーが指定された場合、デバッグ、ログ、および起動ディレクトリのアクセス権が適切に設定されません。

回避方法: root ではないユーザーのアクセスが許可されるように、これらのディレクトリのアクセス権を変更します。

Access Manager と Directory Server を別のマシンにインストールすると、認証サービスが初期化されない (6229897)

インストール時に classpath およびその他の Access Manager Web コンテナ環境変数は更新されますが、インストールプロセスでは Web コンテナが再起動されません。インストール後、Web コンテナが再起動する前に、Access Manager にログインしようとすると、次のエラーが返されます。 

Authentication Service is not initialized. 
Contact your system administrator.

回避方法: Access Manager にログインする前に、Web コンテナを再起動します。ログインする前に、Directory Server も実行している必要があります。

インストーラが既存のディレクトリインストールにプラットフォームエントリを追加しない (6202902)

Java ES インストーラは、既存のディレクトリサーバーのインストール (DIRECTORY_MODE=2) にプラットフォームエントリを追加しません。

回避方法: レルム/DNS エイリアスおよびプラットフォームサーバーリストエントリを手動で追加します。手順については、『Sun Java System Access Manager 7 2005Q4 配備計画ガイド』の「プラットフォームサーバーリストおよびレルムまたは DNS エイリアスへのインスタンスの追加」を参照してください。

アップグレードに関する問題

Access Manager の ampre70upgrade スクリプトがローカライズ版のパッケージを削除しない (6378444)

Access Manager を Access Manager 7 2005Q4 にアップグレードする場合、ampre70upgrade スクリプトによって、システムにインストールされているローカライズ版のパッケージが削除されません。

回避方法: Access Manager 7 2005Q4 にアップグレードする前に、pkgrm コマンドを使用して、システムにインストールされている Access Manager のローカライズ版パッケージをすべて手動で削除します。

AMConfig.properties ファイルに Web コンテナ用の古いバージョンが含まれている (6316833)

Access Manager および Application Server を Java ES 2005Q4 バージョンにアップグレードした後、Access Manager の AMConfig.properties ファイルには Application Server の古いバージョンが含まれます。

回避方法: Delegated Administrator 設定プログラム (config-commda) を実行する前に、AMConfig.properties ファイルの次のプロパティーを変更します。 

com.sun.identity.webcontainer=IAS8.1

ノードエージェント server.policy ファイルが、Access Manager アップグレードの一部として更新されない (6313416)

Access Manager をアップグレードしたあと、ノードエージェントの server.policy ファイルが更新されません。

回避方法: ノードエージェント用の server.policy ファイルを次のファイルと置き換えます。

/var/opt/SUNWappserver/domains/domain1/config/server.policy

アップグレードの後、条件リストの中に「セッションプロパティー条件」がない (6309785)

Access Manager をバージョン 2005Q1 からバージョン 2005Q4 へアップグレードした後、条件をポリシーに追加しようとしても、「セッションプロパティー条件」がポリシー条件リストの中に選択肢として表示されません。

回避方法: 対応するレルムで、ポリシー設定サービスのテンプレート内の「セッションプロパティー条件」タイプを選択します。

アップグレードの後、ポリシー対象リストに「アイデンティティー対象」タイプがない (6304617)

Access Manager をバージョン 2005Q1 からバージョン 2005Q4 へアップグレードした後、新しく追加されたポリシー対象タイプである「アイデンティティー対象」が、ポリシー対象リスト内に選択肢として表示されません。

回避方法: ポリシー設定サービスのテンプレートで、「アイデンティティー対象」タイプをデフォルトの対象タイプとして選択します。

classpath が移行されないため、Access Manager のアップグレードが失敗する (6284595)

Access Manager を Java ES 2004Q2 から Java ES 2005Q4 へのアップグレード中、Java ES 2004Q2 から Java ES 2005Q1 へのアップグレードは失敗します。Access Manager が配備されていた Application Server も Java ES 2004Q2 から Java ES 2005Q4 へアップグレードされるため、アップグレード後の domain.xml ファイル内の classpath に、Access Manager JAR ファイルのパスがないことが原因です。

回避方法: 次の手順を実行します。

  1. comm_dssetup.pl スクリプトには問題があるため、amupgrade スクリプトを実行する前に、Directory Server のインデックスを再作成します。

  2. Access Manager のエントリをノードエージェントの server.policy ファイルに追加します。デフォルトのサーバーポリシー (/var/opt/SUNWappserver/domains/domain1/config/server.policy) からの server.policy のコピーで十分です。

  3. ノードエージェントの domain.xml ファイル内の classpath を、次の手順で更新します。server.xml ファイルにある java-config 要素の server-classpath 属性から、classpath-suffix および該当する classpath を、domain.xml の java-config 要素のそれぞれの属性にコピーします。java-config 要素は、domain.xml 内の config 要素の下にあります。

アップグレードの後、amadmin コマンドで間違ったバージョンの表示が返される (6283758)

Access Manager をバージョン 6 2005Q1 からバージョン 7 2005Q4 へアップグレードした後、amadmin --version コマンドが間違ったバージョン Sun Java System Access Manager version 2005Q1 を返します。

回避方法: Access Manager をアップグレードした後、amconfig スクリプトを実行して Access Manager を設定します。amconfig を実行する場合、設定ファイル (amsamplesilent) のフルパスを指定します。たとえば、Solaris システムの場合は次のように指定します。 

# ./amconfig -s ./config-file

または

# ./amconfig -s /opt/SUNWam/bin/config-file

データ移行後に ContainerDefaultTemplateRole 属性を追加する (4677779)

Access Manager で作成されていないユーザーのロールは組織の下に表示されません。デバッグモードで、次のメッセージが表示されます。

ERROR: DesktopServlet.handleException()
com.iplanet.portalserver.desktop.DesktopException:
DesktopServlet.doGetPost(): no privilige to execute desktop

このエラーは Java ES インストーラ移行スクリプトを実行すると、明らかになります。組織を既存のディレクトリ情報ツリー (DIT) またはほかのソースから移行した場合に、ContainerDefaultTemplateRole 属性は自動的に組織に追加されません。

回避方法: Directory Server コンソールを使用して、別の Access Manager の組織から ContainerDefaultTemplateRole 属性をコピーし、影響を受ける組織に追加します。

設定に関する問題

Application Server 8.1 server.policy ファイルは、デフォルトでない URI を使用する場合は編集する必要がある (6309759)

Access Manager 7 2005Q4 を Application Server 8.1 に配備し、サービス、コンソール、およびパスワード Web アプリケーションのそれぞれのデフォルトである amserver、amconsole、および ampassword ではない URI を使用している場合、Web ブラウザ経由で Access Manager にアクセスする前にアプリケーションサーバードメインの server.policy ファイルを編集する必要があります。

回避方法: server.policy ファイルを次のように編集します。

  1. Access Manager が配備されている Application Server インスタンスを停止します。

  2. /config ディレクトリに移動します。次に例を示します。

    cd /var/opt/SUNWappserver/domains/domain1/config

  3. server.policy ファイルのバックアップコピーを作成します。次に例を示します。

    cp server.policy server.policy.orig

  4. server.policy ファイルで、次のポリシーを探します。

    grant codeBase "file:\${com.sun.aas.instanceRoot}/
applications/j2ee-modules/amserver/-" { ... 
};
grant codeBase "file:\${com.sun.aas.instanceRoot}/
applications/j2ee-modules/amconsole/-" { ...
};
grant codeBase "file:\${com.sun.aas.instanceRoot}/
applications/j2ee-modules/ampassword/-" { ...
};

  5. 次の行で、amserver をサービス Web アプリケーションで使用するデフォルトでない URI に置き換えます。

    grant codeBase "file:\${com.sun.aas.instanceRoot}/
applications/j2ee-modules/amserver/-" {

  6. 旧バージョンモードのインストールの場合、次の行で amconsole をコンソール Web アプリケーションで使用するデフォルトでない URI に置き換えます。

    grant codeBase "file:\${com.sun.aas.instanceRoot}/
applications/j2ee-modules/amconsole/-" {

  7. 次の行で、ampassword をパスワード Web アプリケーションで使用するデフォルトでない URI に置き換えます。

    grant codeBase "file:\${com.sun.aas.instanceRoot}/
applications/j2ee-modules/ampassword/-" {

  8. Access Manager が配備されている Application Server インスタンスを起動します。

プラットフォームサーバーリストおよび FQDN エイリアス属性が更新されない (6309259、6308649)

複数のサーバー配備では、Access Manager を 2 番目 (およびそれ以降) のサーバーにインストールした場合、プラットフォームサーバーリストおよび FQDN エイリアス属性が更新されません。

回避方法: レルム/DNS エイリアスおよびプラットフォームサーバーリストエントリを手動で追加します。手順については、『Sun Java System Access Manager 7 2005Q4 配備計画ガイド』の「プラットフォームサーバーリストおよびレルムまたは DNS エイリアスへのインスタンスの追加」を参照してください。

サービス内の必須属性のデータ妥当性検査 (6308653)

Access Manager 7 2005Q4 では、サービス XML ファイルの必須属性には、デフォルト値が割り当てられていなければなりません。

回避方法: 値のない必須属性のあるサービスが存在する場合、属性に値を追加してからサービスを再読み込みします。

セキュリティー保護された WebLogic 8.1 インスタンス上に配備する際の問題に対する回避方法 (6295863)

Access Manager 7 2005Q4 をセキュリティー保護された (SSL が有効な) BEA WebLogic 8.1 SP4 インスタンスに配備する場合、それぞれの Access Manager Web アプリケーションの配備中に例外が発生します。

回避方法: 次の手順を実行します。

  1. BEA から入手可能な WebLogic 8.1 SP4 パッチ JAR CR210310_81sp4.jar を適用します。

  2. /opt/SUNWam/bin/amwl81config スクリプト (Solaris システム) または /opt/sun/identity/bin/amwl81config スクリプト (Linux システム) で、doDeploy 関数および undeploy_it 関数を更新してパッチ JAR のパスを wl8_classpath の先頭に追加します。これは Access Manager Web アプリケーションの配備および配備取消しに使用される classpath を含む変数です。

    wl8_classpath を含む次の行を検索します。

    wl8_classpath= ...

  3. 手順 2 で検索した行のすぐ後に、次の行を追加します。

    wl8_classpath=path-to-CR210310_81sp4.jar:$wl8_classpath

amconfig スクリプトが、レルム/DNS エイリアスおよびプラットフォームサーバーリストのエントリを更新しない (6284161)

複数サーバーの配備では、amconfig は追加の Access Manager インスタンスに対してレルム/DNS エイリアスおよびプラットフォームサーバーリストのエントリを更新しません。

回避方法: レルム/DNS エイリアスおよびプラットフォームサーバーリストエントリを手動で追加します。手順については、『Sun Java System Access Manager 7 2005Q4 配備計画ガイド』の「プラットフォームサーバーリストおよびレルムまたは DNS エイリアスへのインスタンスの追加」を参照してください。

デフォルトの Access Manager モードが設定状態ファイルテンプレートでレルムに設定されている (6280844)

デフォルトでは、Access Manager モード (AM_REALM 変数) は設定状態ファイルテンプレートで enable に設定されています。

回避方法: Access Manager を旧バージョンモードでインストールまたは設定するには、状態ファイルの変数を次のようにセットし直します。

AM_REALM = disabled

RSA キーを使用した場合に、IBM WebSphere でURL署名が失敗する (6271087)

IBM WebSphere で RSA キーを使用すると、URL 文字列の署名が次の例外を発行して失敗します。 

ERROR: FSSignatureUtil.signAndReturnQueryString: FSSignatureException 
occured while signing query string: no such provider: SunRsaSign

回避方法: SunRsaSign プロバイダは WebSphere バンドル版の JDK に含まれていません。この問題を修正するには、websphere_jdk_root/jre/lib/security/java.security ファイルを編集し、次の行を追加して、プロバイダの 1 つとして SunRsaSign を有効にします。

security.provider.6=com.sun.rsajca.Provider

Access Manager コンソールに関する問題

SAML で、信頼パートナーをコンソールで複製すると、エラーが発生する (6326634)

Access Manager コンソールで、SAML 信頼パートナーを「連携」>「SAML」タブから作成します。次に、同じ信頼パートナーを複製しようとすると、エラーが発生します。

回避方法: なし。この問題はパッチ 1 で修正されています。特定のプラットフォームにパッチを適用する方法については、「Access Manager 7 2005Q4 パッチ 1」を参照してください。

amConsole.access および amPasswordReset.access でリモートログが機能していない (6311786)

リモートログを設定すると、amConsole.access およびパスワードリセット情報の amPasswordReset.access 以外のすべてのログは、リモートの Access Manager インスタンスに書き込まれます。しかし、ログレコードはどこにも書き込まれません。

回避方法: なし。

コンソールで amadmin プロパティーをさらに追加すると、amadmin ユーザーパスワードが変更される (6309830)

管理コンソールの amadmin ユーザーの一部のプロパティーを追加または編集すると、amadmin ユーザーパスワードが変更されます。

回避方法: なし。この問題はパッチ 1 で修正されています。特定のプラットフォームにパッチを適用する方法については、「Access Manager 7 2005Q4 パッチ 1」を参照してください。

新しい Access Manager コンソールは CoS テンプレート優先度を設定できない (6309262)

新しい Access Manager 7 2005Q4 コンソールでは、サービスクラス (CoS) のテンプレート優先度を設定または変更できません。

回避方法: Access Manager 6 2005Q1 コンソールにログインし、CoS テンプレート優先度を設定または変更します。

ポリシー管理ユーザーとしてグループをユーザーに追加すると例外エラーが発生する (6299543)

Access Manager コンソールは、ポリシー管理ユーザーとしてグループをユーザーに追加すると、例外エラーを返します。

回避方法: なし。

旧バージョンモードで、ロールからすべてのユーザーを削除できない (6293758)

旧バージョンモードでは、ロールからすべてのユーザーを削除しようとすると、1 人のユーザーが残ります。

回避方法: もう一度ロールからユーザーを削除します。

ディスカバリサービスリソースオファリングを追加、削除、変更できない (6273148)

Access Manager 管理コンソールでは、ユーザーがユーザー、ロール、またはレルムのリソースオファリングを追加、削除、変更することを許可していません。

回避方法: なし。この問題はパッチ 1 で修正されています。特定のプラットフォームにパッチを適用する方法については、「Access Manager 7 2005Q4 パッチ 1」を参照してください。

対象検索で、間違った LDAP バインドパスワードを使用すればエラーが発生するはずである (6241241)

Access Manager 管理コンソールは、間違った LDAP バインドパスワードが使用された場合にエラーを返しません。

回避方法: なし。

旧バージョンモードで、Access Manager はコンテナに組織を作成できない (6290720)

コンテナを作成して、コンテナに組織を作成しようとすると、Access Manager は「一意性の違反エラー」を返します。

回避方法: なし。

Portal Server 関連のサービスを追加すると、古いコンソールが表示される (6293299)

Portal Server および Access Manager は同じサーバーにインストールされます。旧バージョンモードでインストールされた Access Manager で、/amserver を使用して新しい Access Manager コンソールにログインします。既存のユーザーを選択して NetFile または Netlet などのサービスを追加しようとすると、古い Access Manager コンソール (/amconsle) が突然表示されます。

回避方法: なし。Portal Server の現在のバージョンには、Access Manager 6 2005Q1 コンソールが必要です。

リソース制限に達すると、コンソールは Directory Server から設定した結果を返さない (6239724)

Directory Server をインストールしてから Access Manager を既存の DIT オプションでインストールします。Access Manager コンソールにログインし、グループを作成します。グループ内のユーザーを編集します。たとえば、フィルタ uid=*999* でユーザーを追加します。その結果表示されるリストボックスは空で、コンソールはエラー、情報または警告のメッセージをまったく表示しません。

回避方法: グループのメンバーシップは、Directory Server 検索サイズの上限よりも多くすることはできません。グループのメンバーシップが多い場合、それに応じて検索サイズの上限を変更します。

SDK およびクライアントに関する問題

サブレルムでセッションサービス設定を削除できない (6318296)

最上位のレルムのサブレルムを作成した後で、サブレルムにセッションサービスを追加すると、続いてセッションサービス設定を削除しようとした場合にエラーメッセージが表示されます。

回避方法: デフォルトの最上位 ID リポジトリである AMSDK1 を削除し、このリポジトリを再び設定に追加します。

この問題はパッチ 1 で修正されています。特定のプラットフォームにパッチを適用する方法については、「Access Manager 7 2005Q4 パッチ 1」を参照してください。

ポリシー条件を指定したとき、CDC サーブレットが無効なログインページにリダイレクトする (6311985)

CDSSO モードの Apache エージェント 2.2 では、エージェントの保護されたリソースにアクセスするとき、CDC サーブレットはデフォルトのログインページではなく匿名認証ページにリダイレクトします。

回避方法: なし。この問題はパッチ 1 で修正されています。特定のプラットフォームにパッチを適用する方法については、「Access Manager 7 2005Q4 パッチ 1」を参照してください。

サーバーを再起動した後、クライアントが通知を受け取れない (6309161)

クライアント SDK (amclientsdk.jar) を使用して書かれたアプリケーションは、サーバーを再起動しても通知を受け取れません。

回避方法: なし。

サービススキーマの変更の後、SDK クライアントを再起動する必要がある (6292616)

任意のサービススキーマを変更した場合、ServiceSchema.getGlobalSchema は新しいスキーマではなく古いスキーマを返します。

回避方法: サービススキーマを変更した後、クライアントを再起動します。

この問題はパッチ 1 で修正されています。特定のプラットフォームにパッチを適用する方法については、「Access Manager 7 2005Q4 パッチ 1」を参照してください。

コマンド行ユーティリティーに関する問題

Access Manager が Directory Proxy をポイントする場合、null 属性によるLDAP 検索でエラーが返される (6357975)

Sun Java System Directory Proxy Server を使用している場合は、null 属性による LDAP 検索を行うとエラーが返されます。次に例を示します。

# ldapsearch -b base-dn uid=user ""

Access Manager が LDAP ディレクトリサーバーを直接ポイントする場合、この検索は成功します。

回避方法: Directory Proxy Server を使用している場合は、検索で null 属性検索を使用可能にするか、検索のための属性名を指定します。

amserveradmin スクリプトに新しいスキーマファイルがない (6255110)

インストール後に、amserveradmin スクリプトを実行して Directory Server にサービスを読み込む必要がある場合、defaultDelegationPolicies.xml スキーマファイルおよび idRepoDefaults.xml スキーマファイルがスクリプトにありません。

回避方法: amadmin CLI ツールで -t オプションを指定して使用し、defaultDelegationPolicies.xml ファイルおよび idRepoDefaults.xml ファイルを手動で読み込みます。

Internet Explorer 6.0 でエスケープ文字のある XML ドキュメントを保存できない (4995100)

特殊文字 (「&」の隣に文字列 「amp;」など) を XML ファイルに追加した場合、ファイルは正常に保存されますが、あとで Internet Explorer 6.0 を使用して XML プロファイルを取得するとファイルが正しく表示されません。もう一度プロファイルを保存しようとすると、エラーが返されます。

回避方法: なし。

認証に関する問題

UrlAccessAgent SSO トークンの有効期限が切れる (6327691)

アプリケーションモジュールが特殊ユーザー DN を返さないため、UrlAccessAgent SSO トークンの有効期限が切れます。その結果、特殊ユーザー DN 一致と有効期限の切れないトークンの設定に失敗します。

回避方法: なし。この問題はパッチ 1 で修正されています。特定のプラットフォームにパッチを適用する方法については、「Access Manager 7 2005Q4 パッチ 1」を参照してください。

パスワードを訂正した後、LDAPV3 プラグイン/動的プロファイルでサブレルムにログインできない (6309097)

レルムモードでは、ldapv3 データストアを「間違った」パスワードでレルムに作成して、あとで amadmin としてパスワードを変更した場合、変更後のパスワードでログインしようとしても、プロファイルが存在しないというメッセージが表示され、ログインが失敗します。

回避方法: なし。

旧バージョン (互換) モードでの統計サービスに関する Access Manager デフォルト設定の非互換性 (6286628)

Access Manager を旧バージョンモードでインストールしたあと、統計サービスのデフォルト設定が変更されています。

回避方法: なし。

最上位の組織で、ネーミング属性の一意性が壊れる (6204537)

Access Manager をインストールした後、amadmin としてログインし、o、sunPreferredDomain、associatedDomain、sunOrganizationAlias、uid、および mail 属性を「一意の属性リスト」に追加します。2 つの組織を同じ名前で作成した場合、操作は失敗しますが、予期した「属性の一意性に違反しています」のメッセージではなく「その組織はすでに存在します」のメッセージが表示されます。

回避方法: なし。正しくないメッセージを無視してください。Access Manager は正常に動作しています。

セッションおよび SSO に関する問題

タイムゾーンを越えた Access Manager インスタンスがほかのユーザーセッションをタイムアウトにする (6323639)

異なるタイムゾーンを越えて同じトラストサークル内に Access Manager インスタンスがインストールされている場合、ユーザーセッションのタイムアウトが発生します。

セッションフェイルオーバー (amsfoconfig) スクリプトには Linux 2.1 システムに対して不正なアクセス権が設定されている (6298433)

セッションフェイルオーバーの設定スクリプト (/opt/sun/identity/bin/amsfoconfig ) には不正なアクセス権が設定されいるため、Linux 2.1 システム上で実行できません。

回避方法: アクセス権を変更して amsfoconfig スクリプトを実行できるようにします (たとえば、755)。

この問題はパッチ 1 で修正されています。特定のプラットフォームにパッチを適用する方法については、「Access Manager 7 2005Q4 パッチ 1」を参照してください。

セッションフェイルオーバー (amsfoconfig) スクリプトが Linux 2.1 システムで失敗する (6298462)

タブ文字 (\t) が正しく解釈されないため、Linux 2.1 サーバー上でセッションフェイルオーバーの設定スクリプト (amsfoconfig) が失敗します。

回避方法: セッションフェイルオーバーを手動で設定します。詳細は、『Sun Java System Access Manager 7 2005Q4 配備計画ガイド』の「セッションフェイルオーバーの手動での設定」を参照してください。

この問題はパッチ 1 で修正されています。特定のプラットフォームにパッチを適用する方法については、「Access Manager 7 2005Q4 パッチ 1」を参照してください。

ロードバランサに SSL 終了を設定した場合に、システムが無効なサービスホスト名を作成する (6245660)

ロードバランサに SSL 終了を設定した Web コンテナとしての Web Server に Access Manager が配備されている場合、クライアントは正しい Web Server ページにダイレクトされません。Access Manager コンソールで「セッション」タブをクリックしても、ホストが無効なためエラーが返されます。

回避方法: 次の例では、Web Server はポート 3030 で待機します。ロードバランサはポート 80 で待機し、要求を Web Server にリダイレクトします。

web-server-instance-name/config/server.xml ファイルで、使用している Web Server のリリースに従って servername 属性をロードバランサを示すように変更します。

Web Server 6.1 Service Pack (SP) リリースでは、servername 属性を次のように編集します。

<LS id="ls1" port="3030" servername="loadbalancer.example.com:80" 
defaultvs="https-sample" security="false" ip="any" blocking="false" 
acceptorthreads="1"/>

Web Server 6.1 SP2 (または以降) では、プロトコルを http から https または https から http へと切り替えることができます。つまり、servername を次のように編集します。

<LS id="ls1" port="3030" 
servername="https://loadbalancer.example.com:443" defaultvs="https-sample" 
security="false" ip="any" blocking="false" acceptorthreads="1"/>

サードパーティー Web コンテナで HttpSession を使用する (CR 番号なし)

認証用にセッションを維持するデフォルトの方法は、HttpSession ではなく、「内部セッション」です。無効なセッションの最大時間値は、デフォルトの 3 分で十分です。amtune スクリプトは、Web Server または Application Server の場合に、この値を 1 分に設定します。ただし、サードパーティー Web コンテナ (IBM WebSphere または BEA WebLogic Server) とオプションの HttpSession を使用する場合は、Web コンテナの最大 HttpSession 時間を制限して、パフォーマンスの問題を避ける必要がある可能性があります。

ポリシーに関する問題

ポリシー設定サービスで動的属性を削除すると、ポリシーの編集で問題が発生する (6299074)

ポリシー設定サービスで動的属性を削除すると、次のシナリオのポリシーの編集で問題が発生します。

  1. ポリシー設定サービスで 2 つの動的属性を作成します。

  2. ポリシーを作成し、(手順 1 からの) 動的属性を応答プロバイダで選択します。

  3. ポリシー設定サービスで動的属性を削除し、属性をさらに 2 つ作成します。

  4. 手順 2 で作成したポリシーを編集します。

上記の手順を実行するとエラーとなり、「エラー 無効な動的プロパティーが設定されています」というメッセージが返されます。デフォルトでは、表示されるポリシーはありません。検索が終了した後、ポリシーが表示されますが、既存のポリシーを編集または削除したり、新しいポリシーを作成したりすることはできません。

回避方法: ポリシー設定サービスから動的属性を削除する前に、ポリシーからこれらの属性への参照を削除します。

サーバーの起動に関する問題

Access Manager の起動時に、デバッグエラーが発生する (6309274, 6308646)

Access Manager 7 2005Q4 の起動では、amDelegation および amProfile デバッグファイルにデバッグエラーを返します。

回避方法: なし。このメッセージは無視できます。

Web コンテナとしての BEA WebLogic Server の使用

BEA WebLogic Server を Web コンテナとして使用して Access Manager を配備した場合、Access Manager にアクセスできないことがあります。

回避方法: WebLogic Server を 2 回再起動すると Access Manager にアクセスできるようになります。

Linux OS に関する問題

Application Server 上で Access Manager を実行すると、JVM の問題が生じる (6223676)

Red Hat Linux で Application Server 8.1 を実行している場合、Application Server 用に Red Hat OS が作成するスレッドのスタックサイズは 10M バイトですが、Access Manager ユーザーセッション数が 200 に達すると、JVM リソースの問題が発生する可能性があります。

回避方法: Application Server を起動する前に、ulimit コマンドを実行して、Red Hat OS が操作するスタックサイズを 2048K バイトまたは 256K バイトなどの小さな値に設定します。ulimit コマンドは、Application Server の起動に使用する同じコンソールで実行します。次に例を示します。 

# ulimit -s 256;

連携および SAML に関する問題

Web サービスサンプルを実行すると「Resource offering not found」が返される (6359900)

Access Manager を AccessManager-base/SUNWam/samples/phase2/wsc ディレクトリ (Solaris システムの場合) または AccessManager-base /identity/samples/phase2/wsc ディレクトリ (Linux システムの場合) にある Web サービスサンプルにアクセスするように設定している場合、ディスカバリサービスを照会したり、リソースオファリングを変更したりすると、次のエラーメッセージが返されます。

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

回避方法:

  1. Solaris システムの場合は AccessManager-base /SUNWam/samples/phase2/wsc ディレクトリ、Linux システムの場合は AccessManager-base/identity/samples/phase2/wsc ディレクトリに移動します。

  2. index.jsp ファイルで、次の文字列を検索します。

    com.sun.org.apache.xml.security.utils.XMLUtils.outputDOM

  3. 前の手順で見つけた文字列を含む行の直前に、次の新しい行を挿入します。

    com.sun.org.apache.xml.security.Init.init();

  4. サンプルを再実行します。Access Manager を再起動する必要はありません。

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

アイデンティティープロバイダ (IDP) およびサービスプロバイダ (SP) を設定し、ブラウザのアーティファクトプロファイルを使用するように通信プロトコルを変更してから、IDP および SP の間でユーザーを連携しようとすると、連携が失敗します。

回避方法: なし。

SAML ステートメント中の特殊文字 (&) は、エンコードされるはずである (6321128)

Access Manager をソースサイトおよびデスティネーションサイトとして SSO を設定すると、SAML ステートメント中の特殊文字 ( &) がエンコードされず、表明のパースが失敗するため、デスティネーションサイトでエラーが発生します。

回避方法: なし。この問題はパッチ 1 で修正されています。特定のプラットフォームにパッチを適用する方法については、「Access Manager 7 2005Q4 パッチ 1」を参照してください。

ディスカバリサービスをロールに追加しようとすると、例外が発生する (6313437)

Access Manager コンソールで、リソースオファリングをディスカバリサービスに追加しようとすると、不明な例外が発生します。

回避方法: なし。

認証コンテキスト属性が、その他の属性を設定して保存するまで設定できない (6301338)

認証コンテキスト属性は、その他の属性を設定して保存するまで設定できません。

回避方法: 認証コンテキスト属性を設定する前に、プロバイダプロファイルを設定し保存します。

ルートサフィックスに & 文字が含まれている場合、EP サンプルが動作しない (6300163)

Directory Server のルートサフィックスに「&」文字が含まれている場合、「Employee Profile Service」リソースオファリングを追加しようとすると例外がスローされます。

回避方法: なし。

連携でログアウトエラーが発生する (6291744)

レルムモードで、アイデンティティープロバイダ (IDP) およびサービスプロバイダ (SP) でユーザーアカウントを連携し、連携を終了してログアウトするとエラーが発生して「エラー: サブ組織が見つかりません。」というメッセージが返されます。

回避方法: なし。

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

ユーザーのロケール設定が、管理コンソール全体に適用されない (6326734)

Access Manager 管理コンソールの一部は、ユーザーロケールの設定に従わず、ブラウザのロケール設定を使用します。この問題は、「バージョン」およびオンラインヘルプの内容とともに、「バージョン」、「ログアウト」、およびオンラインヘルプボタンに影響します。

回避方法: ブラウザの設定をユーザー設定と同じロケールに変更します。

Access Manager が IBM WebSphere に配備されている場合、ヨーロッパ言語のオンラインヘルプが完全には利用できない (6325024)

すべてのヨーロッパ言語ロケール (スペイン語、ドイツ語、およびフランス語) では、Access Manager が IBM WebSphere の Application Server インスタンスに配備されている場合、オンラインヘルプが完全には利用できません。オンラインヘルプでは、次のフレームで「アプリケーションエラー」が表示されます。

回避方法: ブラウザの言語設定を英語に設定してページを更新し、左側のフレームにアクセスします。ただし、上部のフレームは「アプリケーションエラー」が引き続き表示されます。

Access Manager が IBM WebSphere に配備されている場合、バージョン情報が空白になる (6319796)

Access Manager が IBM WebSphere Application Server インスタンスに配備されているとき、どのロケールの場合でも「バージョン」ボタンをクリックしても製品バージョンは利用できません。代わりに空白のページが表示されます。

回避方法: なし。

クライアントディテクションで UTF-8 の削除が動作しない (5028779)

「クライアントディテクション」機能は正常に動作しません。Access Manager 7 2005Q4 コンソールに加えられた変更は、自動的にブラウザに送られません。

回避方法: 2 つの回避方法があります。

複数バイト文字がログファイルで疑問符として表示される (5014120)

/var/opt/SUNWam/logs ディレクトリ内のログファイルにある複数バイトのメッセージが疑問符 (?) として表示されます。ログファイルはネイティブなエンコーディングで、常に UTF-8 ではありません。Web コンテナインスタンスを特定のロケールで起動すると、ログファイルはそのロケールのネイティブなエンコーディングになります。別のロケールに切り替えて Web コンテナインスタンスを再起動すると、それ以降のメッセージは現在のロケールのネイティブなエンコーディングになりますが、それ以前のエンコーディングのメッセージは疑問符として表示されます。

回避方法: 常に同じネイティブなエンコーディングを使用して Web コンテナインスタンスを起動するようにします。

マニュアルに関する情報

Access Manager がレルムモードから旧バージョンモードに戻らないことについて (6508473)

Access Manager 7 2005Q4 をレルムモードでインストールした場合は、旧バージョンモードに戻すことができません。

しかし、Access Manager 7 2005Q4 を旧バージョンモードでインストールした場合は、-M オプションを指定して amadmin コマンドを実行することにより、レルムモードに変更できます。次に例を示します。

amadmin -u cn=amAdmin,ou=People,dc=example,dc=com -w amadmin-password -M dc=example,dc=com

持続検索の無効化の詳細について (6486927)

Access Manager は、変更された Sun Java System Directory Server エントリに関する情報を受け取るために持続検索を使用します。デフォルトでは、Access Manager はサーバーの起動時に次の持続検索接続を作成します。

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

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

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

注意 – 注意 –

これらのコンポーネントの持続検索を無効にすることはお勧めできません。これは、無効にした持続検索が Directory Server からの通知を受信しなくなるためです。その結果、Directory Server で行われたそのコンポーネントに関する変更がコンポーネントキャッシュに通知されず、コンポーネントキャッシュが無効になります。

たとえば、ユーザーディレクトリの変更に対する持続検索 (um) を無効にすると、Access Manager サーバーは Directory Server から通知を受け取りません。このため、エージェントも Access Manager から通知を受け取らず、そのローカルユーザーキャッシュを新しい値のユーザー属性で更新しません。この場合、アプリケーションがエージェントにユーザー属性を照会すると、アプリケーションはその属性の古い値を受け取る可能性があります。

このプロパティーは、特殊な状況でどうしても必要な場合に限って使用してください。たとえば、(セッションサービスや認証サービスなどのサービスに対する値の変更に関して) サービス設定の変更が本稼働環境で発生しないことがわかっている場合は、サービス管理 (sm) コンポーネントに対する持続検索を無効にできます。ただし、いずれかのサービスに関して変更が発生した場合は、サービスを再起動する必要があります。aci や um で指定されるほかの持続検索にも、同じ条件が適用されます。

詳細は、「CR# 6363157: どうしても必要な場合に、新しいプロパティーで持続検索を無効にする」を参照してください。

Access Manager がサポートする権限とサポートしない権限について (2143066)

権限とは、レルム内に存在するロールやグループのメンバーである管理者のアクセス権を定義したものです。Access Manager では、次の管理者タイプに対するアクセス権を設定できます。

次の権限がサポートされています。

Cookie ベースのスティッキー要求ルーティングについて (6476922)

Access Manager サーバーがロードバランサの背後に配備されている場合は、Cookie ベースのスティッキー要求ルーティングにより、クライアント要求が誤った Access Manager サーバー (つまり、該当するセッションをホストしていないサーバー) に経路指定されなくなります。この機能は、Access Manager 7 2005Q4 パッチ 3 で実装されました。

従来の動作では、Cookie ベースのスティッキー要求ルーティングが行われないため、非ブラウザベースのクライアント (リモートの Access Manager クライアント SDK を使用するポリシーエージェントやクライアント) からの要求が、該当するセッションをホストしていない Access Manager サーバーに誤って経路指定されていました。そのため、要求を正しいサーバーに送信するには、Access Manager サーバーがバックチャネル通信を使用してセッションの妥当性検査を行う必要があり、通常はそれがパフォーマンス低下の原因になっていました。Cookie ベースのスティッキー要求ルーティングでは、このバックチャネル通信を行う必要がないため、Access Manager のパフォーマンスが向上します。

Cookie ベースのスティッキー要求ルーティングを実装するには、Access Manager の配備をサイトとして設定してください。詳細は、『Sun Java System Access Manager 7 2005Q4 配備計画ガイド』の「サイトとしての Access Manager 配備の設定」を参照してください。

Cookie ベースのスティッキー要求ルーティングを設定するには、次の手順に従います。

  1. Cookie 名を指定するため、AMConfig.properties ファイルに com.iplanet.am.lbcookie.name プロパティーを設定します。Access Manager が 2 バイトのサーバー ID (01、02、03 など) を使用してロードバランサの Cookie 値を生成します。Cookie 名を指定しなかった場合は、Access Manager がデフォルト名である amlbcookie と 2 バイトのサーバー ID を使用してロードバランサの Cookie 値を生成します。

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

    注: Access Manager が 2 バイトのサーバー ID を使用して Cookie 値を設定するため、com.iplanet.am.lbcookie.value プロパティーは設定しないでください。

  2. 手順 1 で設定された Cookie 名を使用してロードバランサを設定します。Access Manager の配備にハードウェアロードバランサまたはソフトウェアロードバランサを使用することができます。

  3. セッションフェイルオーバーが実装されている場合は、ポリシーエージェントと Access Manager サーバーの両方で com.sun.identity.session.resetLBCookie プロパティーを有効にします。

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

    • Access Manager サーバーの場合は、このプロパティーを AMConfig.properties ファイルに追加して有効にします。

    次に例を示します。

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

    フェイルオーバーの状況が発生した場合は、セカンダリ Access Manager サーバーにセッションが経路指定され、セカンダリ Access Manager サーバーのサーバー ID を使用してロードバランサの Cookie 値が設定されます。該当するセッションの後続の要求は、セカンダリ Access Manager サーバーに経路指定されます。

Windows 2003 の Windows デスクトップ SSO の設定について (6487361)

Windows 2003 で Windows デスクトップ SSO を設定するには、『Sun Java System Access Manager 7 2005Q4 管理ガイド』の「Windows デスクトップ SSO の設定」で説明されているように、次の ktpass コマンドを使用します。

ktpass /out filename /mapuser username 
/princ HTTP/hostname.domainname /crypto encryptiontype /rndpass 
/ptype principaltype /target domainname

次に例を示します。

ktpass /out demo.HTTP.keytab 
/mapuser http /princ HTTP/demo.identity.sun.com@IDENTITY.SUN.COM 
/crypto RC4-HMAC-NT /rndpass /ptype KRB5_NT_PRINCIPAL /target IDENTITY.SUN.COM

構文の定義については、次のサイトを参照してください。

http://technet2.microsoft.com/WindowsServer/en/library/64042138-9a5a-4981-84e9-d576a8db0d051033.mspx?mfr=true

分散認証 UI サーバーのパスワードの設定手順について (6510859)

次の手順は、Access Manager サーバーと通信する分散認証 UI サーバーに対して暗号化されたパスワードを設定する方法を説明したものです。

分散認証 UI サーバーにパスワードを設定するには、次の手順に従います。

  1. Access Manager サーバーで、次の手順を実行します。

    1. ampassword -e ユーティリティーを使用して amadmin パスワードを暗号化します。Solaris システムの場合の例を示します。

      # cd /opt/SUNWam/bin 
# ./ampassword -e amadmin-password 
AQIC0K3omEozd544XEJIg25GT2wi1D7UAQLX

      暗号化された値を保存します。

    2. Access Manager サーバーの AMConfig.properties ファイルから am.encryption.pwd プロパティーの値をコピーして保存します。次に例を示します。

      am.encryption.pwd=ydV8JXhJF2J35vpxjZRiGt7SH/7mUr+Y

  2. 分散認証 UI サーバーで、AMConfig.properties ファイルに対して次の変更を行います。

    1. com.iplanet.am.service.password プロパティーをコメントにします。

    2. com.iplanet.am.service.secret プロパティーを手順 1a で暗号化された amadmin パスワードに設定します。

    3. 手順 1b でコピーした am.encryption.pwd と暗号化された値を追加します。次に例を示します。

      com.sun.identity.agents.app.username=username 
#com.iplanet.am.service.password=password 
com.iplanet.am.service.secret=AQIC0K3omEozd544XEJIg25GT2wi1D7UAQLX 
am.encryption.pwd=ydV8JXhJF2J35vpxjZRiGt7SH/7mUr+Y

  3. 分散認証 UI サーバーを再起動します。

「新しいサイト名を作成する」のオンラインヘルプ情報を詳細化する必要がある (2144543)

Access Manager コンソールのオンラインヘルプの「設定」>「システムプロパティー」>「プラットフォーム」にある「新しいサイト名を作成する」には、保存手順が記載されていません。新しいサイト名を追加したあとで、「保存」をクリックせずにインスタンス名を追加しようとすると、処理が失敗します。このため、サイト名を追加したあとは、必ず「保存」をクリックしてからインスタンス名を追加してください。

Windows システムの管理者パスワードの設定パラメータが ADMIN_PASSWD であることについて (6470793)

Solaris システムと Linux システムの amsamplesilent ファイルでは、Access Manager の管理者 (amadmin) パスワードの設定パラメータは ADMINPASSWD です。しかし、Windows システムの AMConfigurator.properties ファイルでは、このパラメータは ADMIN_PASSWD です。

Windows システムで amconfig.bat を実行する場合は、ADMINPASSWD ではなく ADMIN_PASSWORD パラメータを使用して AMConfigurator.properties ファイルの amadmin パスワードを設定してください。

リリースノートの既知の問題点に対する回避方法に誤った記述がある (6422907)

「Web サービスサンプルを実行すると「Resource offering not found」が返される (6359900)」 の回避方法の手順 3 が修正されました。

AMConfig.properties 内のドキュメント com.iplanet.am.session.protectedPropertiesList (6351192)

com.iplanet.am.session.protectedPropertiesList パラメータを使用すると、特定のコアまたは内部セッションプロパティーを、セッションサービスの SetProperty メソッドによるリモート更新から保護できます。この「非表示」キーセキュリティーパラメータを設定することで、認証や Access Manager のその他の機能が利用できるようにセッション属性をカスタマイズできます。このパラメータを使用するには、次の手順に従います。

  1. テキストエディタで、このパラメータを AMConfig.properties ファイルに追加します。

  2. 保護する必要のあるセッションプロパティーに、このパラメータを設定します。次に例を示します。

    com.iplanet.am.session.protectedPropertiesList = 
PropertyName1,PropertyName2,PropertyName3

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

LDAPv3 プラグインのロールおよびフィルタを適用したロールのサポートについて (6365196)

各パッチを適用後、データを Sun Java System Directory Server に保存する場合に、LDAPv3 プラグインにロールおよびフィルタを適用したロールを設定できます (CR 6349959 を修正)。Access Manager 7 2005Q4 管理コンソールで、「LDAPv3 プラグインでサポートされるタイプおよび操作」フィールドの LDAPv3 の設定に、次のような値を入力します。

role: read,edit,create,delete
filteredrole: read,edit,create,delete

LDAPv3 の設定で使用するロールやフィルタを適用したロールに応じて、上のエントリのいずれかまたは両方を入力できます。

AMConfig.properties ファイルの未使用のプロパティーについて (6344530)

AMConfig.properties ファイルの次のプロパティーは使用されていません。 

com.iplanet.am.directory.host
com.iplanet.am.directory.port

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

AMConfig.properties ファイル内の com.iplanet.am.session.client.polling.enable プロパティーは、サーバー側で true に設定してはいけません。

回避方法: このプロパティーはデフォルトで false に設定されており、true にリセットしてはいけません。

コンソールのオンラインヘルプで、デフォルトの成功 URL が正しくない (6296751)

service.scserviceprofile.iplanetamauthservice.html オンラインヘルプファイル内にある「デフォルト成功 URL」が正しくありません。「デフォルト成功 URL」フィールドは、正常に認証された後に、リダイレクトされる URL を指定した複数の値が含まれるリストを受け入れます。この属性のフォーマットは clientType|URL で、URL の値だけを指定できますが、デフォルトタイプは HTML を前提としています。

デフォルト値「/amconsole」は正しくありません。

回避方法 正しいデフォルト値は「/amserver/console」です。

XML 暗号化を有効にする方法について (6275563)

Bouncy Castle JAR ファイルを使用して、Access Manager または Federation Manager で XML 暗号化を有効にしてトランスポートキーを生成するには、次の手順に従います。

  1. JDK 1.5 より前の JDK バージョンを使用している場合は、Bouncy Castle サイト (http://www.bouncycastle.org/) から Bouncy Castle JCE プロバイダをダウンロードします。たとえば、JDK 1.4 の場合、bcprov-jdk14-131.jar ファイルをダウンロードします。

  2. 前の手順で JAR ファイルをダウンロードした場合は、ファイルを jdk_root/jre/lib/ext ディレクトリにコピーします。

  3. JDK の国内版の場合、Sun サイト (http://java.sun.com) から、お使いの JDK のバージョンに対応する JCE Unlimited Strength Jurisdiction Policy Files をダウンロードします。IBM WebSphere の場合は、対応する IBM サイトに移動し、必要なファイルをダウンロードします。

  4. ダウンロードした US_export_policy.jar および local_policy.jar ファイルを jdk_root/jre/lib/security ディレクトリにコピーします。

  5. JDK 1.5 より前の JDK のバージョンを使用している場合は、jdk_root/jre/lib/security/java.security ファイルを編集し、プロバイダの 1 つとして Bouncy Castle を追加します。次に例を示します。

    security.provider.6=org.bouncycastle.jce.provider.BouncyCastleProvider

  6. AMConfig.properties ファイルで、次のプロパティーを true に設定します。

    com.sun.identity.jss.donotInstallAtHighestPriority=true

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

詳細については、問題 ID 5110285 (XML 暗号化には Bouncy Castle JAR ファイルが必要) を参照してください。