この節では、リリース時での、次の既知の問題点、および利用可能な場合は回避方法について説明します。
「Java ES 2004Q2 サーバーと Java ES 2005Q4 上の IM との間に互換性がない (6309082)」
「Delegated Administrator commadmin ユーティリティーがユーザーを作成しない (6294603)」
「Delegated Administrator commadmin ユーティリティーが組織を作成しない (6292104)」
次の配備シナリオでは問題が発生します。
サーバー-1: Java ES 2004Q2: Directory Server
サーバー-2: Java ES 2004Q2: Application Server、Access Manager、および Portal Server
サーバー-3: Java ES 2004Q2: Calendar Server と Messaging Server
サーバー-4: Java ES 2005Q4: Application Server、Instant Messaging、および Access Manager SDK
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 アップグレードガイド』を参照してください。
Access Manager 7 2005Q4 旧バージョンモードでは、Access Manager 6 2005Q1 からのコア認証モジュールに次の非互換性があります。
組織認証モジュールが旧バージョンモードで削除されています。
「管理者認証設定」および「組織認証設定」の表示方法が変更されました。Access Manager 7 2005Q4 コンソールでは、ドロップダウンリストの ldapService がデフォルトで選択されています。Access Manager 6 2005Q1 コンソールでは、「編集」ボタンが表示され、LDAP モジュールはデフォルトで選択されませんでした。
回避方法: なし。
Access Manager コンソールで、エージェントをレルムモードで作成します。ログアウトしてからエージェント名を使用してもう一度ログインすると、エージェントはレルムにアクセスする権限がないため、Access Manager はエラーを返します。
回避方法: エージェントに対して読み取り/書き込みアクセスができるように、アクセス権を変更します。
Delegated Administrator commadmin ユーティリティーを -S mail,cal オプションで使用すると、デフォルトドメインにユーザーが作成されません。
回避方法: この問題は、Access Manager をバージョン 7 2005Q4 にアップブレードして Delegated Administrator をアップグレードしなかった場合に発生します。Delegated Administrator のアップグレードについては、『Sun Java Enterprise System 2005Q4 アップグレードガイド』を参照してください。
Delegated Administrator をアップグレードする予定がない場合は、次の手順を実行します。
UserCalendarService.xml ファイルで、mail、icssubcribed、および icsfirstday 属性を必須ではなく省略可能としてマークします。このファイルはデフォルトで、Solaris システム上の /opt/SUNWcomm/lib/services/ ディレクトリにあります。
Access Manager で次のように amadmin コマンドを実行して、既存の XML ファイルを削除します。
# ./amadmin -u amadmin -w password -r UserCalendarService
Access Manager で、更新した XML ファイルを次のように追加します。
# ./amadmin -u amadmin -w password -s /opt/SUNWcomm/lib/services/UserCalendarService.xml
Access Manager Web コンテナを再起動します。
Delegated Administrator commadmin ユーティリティーを -S mail,cal オプションで使用すると、組織が作成されません。
回避方法: 前の問題の回避方法を参照してください。
「パッチ 1 の適用後、/tmp/amsilent ファイルがすべてのユーザーの読み取りアクセスを許可する (6370691)」
「Access Manager classpath が、有効期限の切れた JCE 1.2.1 パッケージを参照する (6297949)」
「Access Manager を既存の DIT にインストールすると、Directory Server のインデックスの再作成が必要になる (6268096)」
「Access Manager と Directory Server を別のマシンにインストールすると、認証サービスが初期化されない (6229897)」
パッチ 1 の適用後、/tmp/amsilent ファイルはすべてのユーザーに読み取りアクセスを許可します。
回避方法: パッチの適用後、Access Manager 管理者のみ読み取りアクセスを許可するように、ファイルのアクセス権をリセットします。
SDK のインストールをコンテナ設定 (DEPLOY_LEVEL=4) とともに実行すると、通知 URL が正しくありません。
回避方法:
AMConfig.properties ファイルで、次のプロパティーを設定します。
com.iplanet.am.notification.url= protocol://fqdn:port/amserver/servlet/com.iplanet.services.comm.client. PLLNotificationServlet
Access Manager を再起動すると、新しい値が有効になります。
Access Manager classpath が、2005 年 7 月 27 日に期限が切れた Java Cryptography Extension (JCE) 1.2.1 パッケージ (署名証明書) を参照しています。
回避方法: なし。パッケージ参照が classpath にあっても、Access Manager はそのパッケージを使用しません。
検索のパフォーマンスを改善するため、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 ではないユーザーが指定された場合、デバッグ、ログ、および起動ディレクトリのアクセス権が適切に設定されません。
回避方法: root ではないユーザーのアクセスが許可されるように、これらのディレクトリのアクセス権を変更します。
インストール時に classpath およびその他の Access Manager Web コンテナ環境変数は更新されますが、インストールプロセスでは Web コンテナが再起動されません。インストール後、Web コンテナが再起動する前に、Access Manager にログインしようとすると、次のエラーが返されます。
Authentication Service is not initialized. Contact your system administrator.
回避方法: Access Manager にログインする前に、Web コンテナを再起動します。ログインする前に、Directory Server も実行している必要があります。
Java ES インストーラは、既存のディレクトリサーバーのインストール (DIRECTORY_MODE=2) にプラットフォームエントリを追加しません。
回避方法: レルム/DNS エイリアスおよびプラットフォームサーバーリストエントリを手動で追加します。手順については、『Sun Java System Access Manager 7 2005Q4 配備計画ガイド』の「プラットフォームサーバーリストおよびレルムまたは DNS エイリアスへのインスタンスの追加」を参照してください。
「Access Manager の ampre70upgrade スクリプトがローカライズ版のパッケージを削除しない (6378444)」
「AMConfig.properties ファイルに Web コンテナ用の古いバージョンが含まれている (6316833)」
「ノードエージェント server.policy ファイルが、Access Manager アップグレードの一部として更新されない (6313416)」
「classpath が移行されないため、Access Manager のアップグレードが失敗する (6284595)」
Access Manager を Access Manager 7 2005Q4 にアップグレードする場合、ampre70upgrade スクリプトによって、システムにインストールされているローカライズ版のパッケージが削除されません。
回避方法: Access Manager 7 2005Q4 にアップグレードする前に、pkgrm コマンドを使用して、システムにインストールされている Access Manager のローカライズ版パッケージをすべて手動で削除します。
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
Access Manager をアップグレードしたあと、ノードエージェントの server.policy ファイルが更新されません。
回避方法: ノードエージェント用の server.policy ファイルを次のファイルと置き換えます。
/var/opt/SUNWappserver/domains/domain1/config/server.policy
Access Manager をバージョン 2005Q1 からバージョン 2005Q4 へアップグレードした後、条件をポリシーに追加しようとしても、「セッションプロパティー条件」がポリシー条件リストの中に選択肢として表示されません。
回避方法: 対応するレルムで、ポリシー設定サービスのテンプレート内の「セッションプロパティー条件」タイプを選択します。
Access Manager をバージョン 2005Q1 からバージョン 2005Q4 へアップグレードした後、新しく追加されたポリシー対象タイプである「アイデンティティー対象」が、ポリシー対象リスト内に選択肢として表示されません。
回避方法: ポリシー設定サービスのテンプレートで、「アイデンティティー対象」タイプをデフォルトの対象タイプとして選択します。
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 ファイルのパスがないことが原因です。
回避方法: 次の手順を実行します。
comm_dssetup.pl スクリプトには問題があるため、amupgrade スクリプトを実行する前に、Directory Server のインデックスを再作成します。
Access Manager のエントリをノードエージェントの server.policy ファイルに追加します。デフォルトのサーバーポリシー (/var/opt/SUNWappserver/domains/domain1/config/server.policy) からの server.policy のコピーで十分です。
ノードエージェントの domain.xml ファイル内の classpath を、次の手順で更新します。server.xml ファイルにある java-config 要素の server-classpath 属性から、classpath-suffix および該当する classpath を、domain.xml の java-config 要素のそれぞれの属性にコピーします。java-config 要素は、domain.xml 内の config 要素の下にあります。
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
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)」
「セキュリティー保護された WebLogic 8.1 インスタンス上に配備する際の問題に対する回避方法 (6295863)」
「amconfig スクリプトが、レルム/DNS エイリアスおよびプラットフォームサーバーリストのエントリを更新しない (6284161)」
「デフォルトの Access Manager モードが設定状態ファイルテンプレートでレルムに設定されている (6280844)」
Access Manager 7 2005Q4 を Application Server 8.1 に配備し、サービス、コンソール、およびパスワード Web アプリケーションのそれぞれのデフォルトである amserver、amconsole、および ampassword ではない URI を使用している場合、Web ブラウザ経由で Access Manager にアクセスする前にアプリケーションサーバードメインの server.policy ファイルを編集する必要があります。
回避方法: server.policy ファイルを次のように編集します。
Access Manager が配備されている Application Server インスタンスを停止します。
/config ディレクトリに移動します。次に例を示します。
cd /var/opt/SUNWappserver/domains/domain1/config
server.policy ファイルのバックアップコピーを作成します。次に例を示します。
cp server.policy server.policy.orig
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/-" { ... };
次の行で、amserver をサービス Web アプリケーションで使用するデフォルトでない URI に置き換えます。
grant codeBase "file:\${com.sun.aas.instanceRoot}/ applications/j2ee-modules/amserver/-" {
旧バージョンモードのインストールの場合、次の行で amconsole をコンソール Web アプリケーションで使用するデフォルトでない URI に置き換えます。
grant codeBase "file:\${com.sun.aas.instanceRoot}/ applications/j2ee-modules/amconsole/-" {
次の行で、ampassword をパスワード Web アプリケーションで使用するデフォルトでない URI に置き換えます。
grant codeBase "file:\${com.sun.aas.instanceRoot}/ applications/j2ee-modules/ampassword/-" {
Access Manager が配備されている Application Server インスタンスを起動します。
複数のサーバー配備では、Access Manager を 2 番目 (およびそれ以降) のサーバーにインストールした場合、プラットフォームサーバーリストおよび FQDN エイリアス属性が更新されません。
回避方法: レルム/DNS エイリアスおよびプラットフォームサーバーリストエントリを手動で追加します。手順については、『Sun Java System Access Manager 7 2005Q4 配備計画ガイド』の「プラットフォームサーバーリストおよびレルムまたは DNS エイリアスへのインスタンスの追加」を参照してください。
Access Manager 7 2005Q4 では、サービス XML ファイルの必須属性には、デフォルト値が割り当てられていなければなりません。
回避方法: 値のない必須属性のあるサービスが存在する場合、属性に値を追加してからサービスを再読み込みします。
Access Manager 7 2005Q4 をセキュリティー保護された (SSL が有効な) BEA WebLogic 8.1 SP4 インスタンスに配備する場合、それぞれの Access Manager Web アプリケーションの配備中に例外が発生します。
回避方法: 次の手順を実行します。
BEA から入手可能な WebLogic 8.1 SP4 パッチ JAR CR210310_81sp4.jar を適用します。
/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= ...
手順 2 で検索した行のすぐ後に、次の行を追加します。
wl8_classpath=path-to-CR210310_81sp4.jar:$wl8_classpath
複数サーバーの配備では、amconfig は追加の Access Manager インスタンスに対してレルム/DNS エイリアスおよびプラットフォームサーバーリストのエントリを更新しません。
回避方法: レルム/DNS エイリアスおよびプラットフォームサーバーリストエントリを手動で追加します。手順については、『Sun Java System Access Manager 7 2005Q4 配備計画ガイド』の「プラットフォームサーバーリストおよびレルムまたは DNS エイリアスへのインスタンスの追加」を参照してください。
デフォルトでは、Access Manager モード (AM_REALM 変数) は設定状態ファイルテンプレートで enable に設定されています。
回避方法: Access Manager を旧バージョンモードでインストールまたは設定するには、状態ファイルの変数を次のようにセットし直します。
AM_REALM = disabled
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
「amConsole.access および amPasswordReset.access でリモートログが機能していない (6311786)」
「コンソールで amadmin プロパティーをさらに追加すると、amadmin ユーザーパスワードが変更される (6309830)」
「リソース制限に達すると、コンソールは Directory Server から設定した結果を返さない (6239724)」
Access Manager コンソールで、SAML 信頼パートナーを「連携」>「SAML」タブから作成します。次に、同じ信頼パートナーを複製しようとすると、エラーが発生します。
回避方法: なし。この問題はパッチ 1 で修正されています。特定のプラットフォームにパッチを適用する方法については、「Access Manager 7 2005Q4 パッチ 1」を参照してください。
リモートログを設定すると、amConsole.access およびパスワードリセット情報の amPasswordReset.access 以外のすべてのログは、リモートの Access Manager インスタンスに書き込まれます。しかし、ログレコードはどこにも書き込まれません。
回避方法: なし。
管理コンソールの amadmin ユーザーの一部のプロパティーを追加または編集すると、amadmin ユーザーパスワードが変更されます。
回避方法: なし。この問題はパッチ 1 で修正されています。特定のプラットフォームにパッチを適用する方法については、「Access Manager 7 2005Q4 パッチ 1」を参照してください。
新しい Access Manager 7 2005Q4 コンソールでは、サービスクラス (CoS) のテンプレート優先度を設定または変更できません。
回避方法: Access Manager 6 2005Q1 コンソールにログインし、CoS テンプレート優先度を設定または変更します。
Access Manager コンソールは、ポリシー管理ユーザーとしてグループをユーザーに追加すると、例外エラーを返します。
回避方法: なし。
旧バージョンモードでは、ロールからすべてのユーザーを削除しようとすると、1 人のユーザーが残ります。
回避方法: もう一度ロールからユーザーを削除します。
Access Manager 管理コンソールでは、ユーザーがユーザー、ロール、またはレルムのリソースオファリングを追加、削除、変更することを許可していません。
回避方法: なし。この問題はパッチ 1 で修正されています。特定のプラットフォームにパッチを適用する方法については、「Access Manager 7 2005Q4 パッチ 1」を参照してください。
Access Manager 管理コンソールは、間違った LDAP バインドパスワードが使用された場合にエラーを返しません。
回避方法: なし。
コンテナを作成して、コンテナに組織を作成しようとすると、Access Manager は「一意性の違反エラー」を返します。
回避方法: なし。
Portal Server および Access Manager は同じサーバーにインストールされます。旧バージョンモードでインストールされた Access Manager で、/amserver を使用して新しい Access Manager コンソールにログインします。既存のユーザーを選択して NetFile または Netlet などのサービスを追加しようとすると、古い Access Manager コンソール (/amconsle) が突然表示されます。
回避方法: なし。Portal Server の現在のバージョンには、Access Manager 6 2005Q1 コンソールが必要です。
Directory Server をインストールしてから Access Manager を既存の DIT オプションでインストールします。Access Manager コンソールにログインし、グループを作成します。グループ内のユーザーを編集します。たとえば、フィルタ uid=*999* でユーザーを追加します。その結果表示されるリストボックスは空で、コンソールはエラー、情報または警告のメッセージをまったく表示しません。
回避方法: グループのメンバーシップは、Directory Server 検索サイズの上限よりも多くすることはできません。グループのメンバーシップが多い場合、それに応じて検索サイズの上限を変更します。
最上位のレルムのサブレルムを作成した後で、サブレルムにセッションサービスを追加すると、続いてセッションサービス設定を削除しようとした場合にエラーメッセージが表示されます。
回避方法: デフォルトの最上位 ID リポジトリである AMSDK1 を削除し、このリポジトリを再び設定に追加します。
この問題はパッチ 1 で修正されています。特定のプラットフォームにパッチを適用する方法については、「Access Manager 7 2005Q4 パッチ 1」を参照してください。
CDSSO モードの Apache エージェント 2.2 では、エージェントの保護されたリソースにアクセスするとき、CDC サーブレットはデフォルトのログインページではなく匿名認証ページにリダイレクトします。
回避方法: なし。この問題はパッチ 1 で修正されています。特定のプラットフォームにパッチを適用する方法については、「Access Manager 7 2005Q4 パッチ 1」を参照してください。
クライアント SDK (amclientsdk.jar) を使用して書かれたアプリケーションは、サーバーを再起動しても通知を受け取れません。
回避方法: なし。
任意のサービススキーマを変更した場合、ServiceSchema.getGlobalSchema は新しいスキーマではなく古いスキーマを返します。
回避方法: サービススキーマを変更した後、クライアントを再起動します。
この問題はパッチ 1 で修正されています。特定のプラットフォームにパッチを適用する方法については、「Access Manager 7 2005Q4 パッチ 1」を参照してください。
「Access Manager が Directory Proxy をポイントする場合、null 属性によるLDAP 検索でエラーが返される (6357975)」
「Internet Explorer 6.0 でエスケープ文字のある XML ドキュメントを保存できない (4995100)」
Sun Java System Directory Proxy Server を使用している場合は、null 属性による LDAP 検索を行うとエラーが返されます。次に例を示します。
# ldapsearch -b base-dn uid=user ""
Access Manager が LDAP ディレクトリサーバーを直接ポイントする場合、この検索は成功します。
回避方法: Directory Proxy Server を使用している場合は、検索で null 属性検索を使用可能にするか、検索のための属性名を指定します。
インストール後に、amserveradmin スクリプトを実行して Directory Server にサービスを読み込む必要がある場合、defaultDelegationPolicies.xml スキーマファイルおよび idRepoDefaults.xml スキーマファイルがスクリプトにありません。
回避方法: amadmin CLI ツールで -t オプションを指定して使用し、defaultDelegationPolicies.xml ファイルおよび idRepoDefaults.xml ファイルを手動で読み込みます。
特殊文字 (「&」の隣に文字列 「amp;」など) を XML ファイルに追加した場合、ファイルは正常に保存されますが、あとで Internet Explorer 6.0 を使用して XML プロファイルを取得するとファイルが正しく表示されません。もう一度プロファイルを保存しようとすると、エラーが返されます。
回避方法: なし。
「パスワードを訂正した後、LDAPV3 プラグイン/動的プロファイルでサブレルムにログインできない (6309097)」
「旧バージョン (互換) モードでの統計サービスに関する Access Manager デフォルト設定の非互換性 (6286628)」
アプリケーションモジュールが特殊ユーザー DN を返さないため、UrlAccessAgent SSO トークンの有効期限が切れます。その結果、特殊ユーザー DN 一致と有効期限の切れないトークンの設定に失敗します。
回避方法: なし。この問題はパッチ 1 で修正されています。特定のプラットフォームにパッチを適用する方法については、「Access Manager 7 2005Q4 パッチ 1」を参照してください。
レルムモードでは、ldapv3 データストアを「間違った」パスワードでレルムに作成して、あとで amadmin としてパスワードを変更した場合、変更後のパスワードでログインしようとしても、プロファイルが存在しないというメッセージが表示され、ログインが失敗します。
回避方法: なし。
Access Manager を旧バージョンモードでインストールしたあと、統計サービスのデフォルト設定が変更されています。
サービスがデフォルトでオンになっています (com.iplanet.services.stats.state=file )。以前はオフでした。
デフォルトの間隔 (com.iplanet.am.stats.interval) が 3600 から 60 に変更されています。
デフォルトの統計ディレクトリ (com.iplanet.services.stats.directory ) が /var/opt/SUNWam/debug から /var/opt/SUNWam/stats に変更されています。
回避方法: なし。
Access Manager をインストールした後、amadmin としてログインし、o、sunPreferredDomain、associatedDomain、sunOrganizationAlias、uid、および mail 属性を「一意の属性リスト」に追加します。2 つの組織を同じ名前で作成した場合、操作は失敗しますが、予期した「属性の一意性に違反しています」のメッセージではなく「その組織はすでに存在します」のメッセージが表示されます。
回避方法: なし。正しくないメッセージを無視してください。Access Manager は正常に動作しています。
「タイムゾーンを越えた Access Manager インスタンスがほかのユーザーセッションをタイムアウトにする (6323639)」
「セッションフェイルオーバー (amsfoconfig) スクリプトには Linux 2.1 システムに対して不正なアクセス権が設定されている (6298433)」
「セッションフェイルオーバー (amsfoconfig) スクリプトが Linux 2.1 システムで失敗する (6298462)」
異なるタイムゾーンを越えて同じトラストサークル内に Access Manager インスタンスがインストールされている場合、ユーザーセッションのタイムアウトが発生します。
セッションフェイルオーバーの設定スクリプト (/opt/sun/identity/bin/amsfoconfig ) には不正なアクセス権が設定されいるため、Linux 2.1 システム上で実行できません。
回避方法: アクセス権を変更して amsfoconfig スクリプトを実行できるようにします (たとえば、755)。
この問題はパッチ 1 で修正されています。特定のプラットフォームにパッチを適用する方法については、「Access Manager 7 2005Q4 パッチ 1」を参照してください。
タブ文字 (\t) が正しく解釈されないため、Linux 2.1 サーバー上でセッションフェイルオーバーの設定スクリプト (amsfoconfig) が失敗します。
回避方法: セッションフェイルオーバーを手動で設定します。詳細は、『Sun Java System Access Manager 7 2005Q4 配備計画ガイド』の「セッションフェイルオーバーの手動での設定」を参照してください。
この問題はパッチ 1 で修正されています。特定のプラットフォームにパッチを適用する方法については、「Access Manager 7 2005Q4 パッチ 1」を参照してください。
ロードバランサに 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"/>
認証用にセッションを維持するデフォルトの方法は、HttpSession ではなく、「内部セッション」です。無効なセッションの最大時間値は、デフォルトの 3 分で十分です。amtune スクリプトは、Web Server または Application Server の場合に、この値を 1 分に設定します。ただし、サードパーティー Web コンテナ (IBM WebSphere または BEA WebLogic Server) とオプションの HttpSession を使用する場合は、Web コンテナの最大 HttpSession 時間を制限して、パフォーマンスの問題を避ける必要がある可能性があります。
ポリシー設定サービスで動的属性を削除すると、次のシナリオのポリシーの編集で問題が発生します。
ポリシー設定サービスで 2 つの動的属性を作成します。
ポリシーを作成し、(手順 1 からの) 動的属性を応答プロバイダで選択します。
ポリシー設定サービスで動的属性を削除し、属性をさらに 2 つ作成します。
手順 2 で作成したポリシーを編集します。
上記の手順を実行するとエラーとなり、「エラー 無効な動的プロパティーが設定されています」というメッセージが返されます。デフォルトでは、表示されるポリシーはありません。検索が終了した後、ポリシーが表示されますが、既存のポリシーを編集または削除したり、新しいポリシーを作成したりすることはできません。
回避方法: ポリシー設定サービスから動的属性を削除する前に、ポリシーからこれらの属性への参照を削除します。
Access Manager 7 2005Q4 の起動では、amDelegation および amProfile デバッグファイルにデバッグエラーを返します。
amDelegation: 委譲のためのプラグインのインスタンスを取得できません
amProfile: 委譲の例外を取得します
回避方法: なし。このメッセージは無視できます。
BEA WebLogic Server を Web コンテナとして使用して Access Manager を配備した場合、Access Manager にアクセスできないことがあります。
回避方法: WebLogic Server を 2 回再起動すると Access Manager にアクセスできるようになります。
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;
Access Manager を AccessManager-base/SUNWam/samples/phase2/wsc ディレクトリ (Solaris システムの場合) または AccessManager-base /identity/samples/phase2/wsc ディレクトリ (Linux システムの場合) にある Web サービスサンプルにアクセスするように設定している場合、ディスカバリサービスを照会したり、リソースオファリングを変更したりすると、次のエラーメッセージが返されます。
AccessManager-base は、ベースインストールディレクトリです。デフォルトのベースインストールディレクトリは、Solaris システムの場合は /opt、Linux システムの場合は /opt/sun です。
回避方法:
Solaris システムの場合は AccessManager-base /SUNWam/samples/phase2/wsc ディレクトリ、Linux システムの場合は AccessManager-base/identity/samples/phase2/wsc ディレクトリに移動します。
index.jsp ファイルで、次の文字列を検索します。
com.sun.org.apache.xml.security.utils.XMLUtils.outputDOM
前の手順で見つけた文字列を含む行の直前に、次の新しい行を挿入します。
com.sun.org.apache.xml.security.Init.init();
サンプルを再実行します。Access Manager を再起動する必要はありません。
アイデンティティープロバイダ (IDP) およびサービスプロバイダ (SP) を設定し、ブラウザのアーティファクトプロファイルを使用するように通信プロトコルを変更してから、IDP および SP の間でユーザーを連携しようとすると、連携が失敗します。
回避方法: なし。
Access Manager をソースサイトおよびデスティネーションサイトとして SSO を設定すると、SAML ステートメント中の特殊文字 ( &) がエンコードされず、表明のパースが失敗するため、デスティネーションサイトでエラーが発生します。
回避方法: なし。この問題はパッチ 1 で修正されています。特定のプラットフォームにパッチを適用する方法については、「Access Manager 7 2005Q4 パッチ 1」を参照してください。
Access Manager コンソールで、リソースオファリングをディスカバリサービスに追加しようとすると、不明な例外が発生します。
回避方法: なし。
認証コンテキスト属性は、その他の属性を設定して保存するまで設定できません。
回避方法: 認証コンテキスト属性を設定する前に、プロバイダプロファイルを設定し保存します。
Directory Server のルートサフィックスに「&」文字が含まれている場合、「Employee Profile Service」リソースオファリングを追加しようとすると例外がスローされます。
回避方法: なし。
レルムモードで、アイデンティティープロバイダ (IDP) およびサービスプロバイダ (SP) でユーザーアカウントを連携し、連携を終了してログアウトするとエラーが発生して「エラー: サブ組織が見つかりません。」というメッセージが返されます。
回避方法: なし。
「Access Manager が IBM WebSphere に配備されている場合、ヨーロッパ言語のオンラインヘルプが完全には利用できない (6325024)」
「Access Manager が IBM WebSphere に配備されている場合、バージョン情報が空白になる (6319796)」
Access Manager 管理コンソールの一部は、ユーザーロケールの設定に従わず、ブラウザのロケール設定を使用します。この問題は、「バージョン」およびオンラインヘルプの内容とともに、「バージョン」、「ログアウト」、およびオンラインヘルプボタンに影響します。
回避方法: ブラウザの設定をユーザー設定と同じロケールに変更します。
すべてのヨーロッパ言語ロケール (スペイン語、ドイツ語、およびフランス語) では、Access Manager が IBM WebSphere の Application Server インスタンスに配備されている場合、オンラインヘルプが完全には利用できません。オンラインヘルプでは、次のフレームで「アプリケーションエラー」が表示されます。
上部のフレームで、実際は「ヘルプ」および「閉じる」ボタンがある場所。
左側のフレームで、実際は「目次」、「インデックス」および「検索」ボタンがある場所。
回避方法: ブラウザの言語設定を英語に設定してページを更新し、左側のフレームにアクセスします。ただし、上部のフレームは「アプリケーションエラー」が引き続き表示されます。
Access Manager が IBM WebSphere Application Server インスタンスに配備されているとき、どのロケールの場合でも「バージョン」ボタンをクリックしても製品バージョンは利用できません。代わりに空白のページが表示されます。
回避方法: なし。
「クライアントディテクション」機能は正常に動作しません。Access Manager 7 2005Q4 コンソールに加えられた変更は、自動的にブラウザに送られません。
回避方法: 2 つの回避方法があります。
「クライアントディテクション」セクションに変更を加えた後で、Access Manager Web コンテナを再起動します。
または
Access Manager コンソールで、次の手順を実行します。
「設定」タブの下にある「クライアントディテクション」をクリックします。
「genericHTML」の「編集」リンクをクリックします。
「HTML」タブの下の、「genericHTML」リンクをクリックします。
文字セットのリストで、エントリとして UTF-8;q=0.5 を入力します (UTF-8 q 係数がロケールのその他の文字セットよりも小さくなるようにする)。
保存してログアウトし、もう一度ログインします。
/var/opt/SUNWam/logs ディレクトリ内のログファイルにある複数バイトのメッセージが疑問符 (?) として表示されます。ログファイルはネイティブなエンコーディングで、常に UTF-8 ではありません。Web コンテナインスタンスを特定のロケールで起動すると、ログファイルはそのロケールのネイティブなエンコーディングになります。別のロケールに切り替えて Web コンテナインスタンスを再起動すると、それ以降のメッセージは現在のロケールのネイティブなエンコーディングになりますが、それ以前のエンコーディングのメッセージは疑問符として表示されます。
回避方法: 常に同じネイティブなエンコーディングを使用して Web コンテナインスタンスを起動するようにします。
「Windows システムの管理者パスワードの設定パラメータが ADMIN_PASSWD であることについて (6470793)」
「AMConfig.properties 内のドキュメント com.iplanet.am.session.protectedPropertiesList (6351192)」
「サーバー側の com.iplanet.am.session.client.polling.enable を true にしてはいけない (6320475)」
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
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 では、次の管理者タイプに対するアクセス権を設定できます。
レルム管理者は、アイデンティティーリポジトリ (データストア) の定義、認証の設定、ポリシーの定義など、レルムに関するすべてのタスクを実行できます。
ポリシー管理者は、既存のレルムのポリシーを設定できます。
次の権限がサポートされています。
すべてのレルムプロパティーおよびポリシープロパティーに対する読み取りおよび書き込みアクセス。レルム管理者に対して読み取りおよび書き込みアクセス権を定義します。
ポリシープロパティーのみに対する読み取りおよび書き込みアクセス。ポリシー管理者に対して読み取りおよび書き込みアクセス権を定義します。
サポートされている権限の組み合わせ: ポリシープロパティーのみに対する読み取りおよび書き込みのアクセス、およびデータストアに対する読み取り専用アクセス。ほかの権限の組み合わせはサポートされていません。
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 ベースのスティッキー要求ルーティングを設定するには、次の手順に従います。
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 プロパティーは設定しないでください。
手順 1 で設定された Cookie 名を使用してロードバランサを設定します。Access Manager の配備にハードウェアロードバランサまたはソフトウェアロードバランサを使用することができます。
セッションフェイルオーバーが実装されている場合は、ポリシーエージェントと 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 を設定するには、『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
構文の定義については、次のサイトを参照してください。
次の手順は、Access Manager サーバーと通信する分散認証 UI サーバーに対して暗号化されたパスワードを設定する方法を説明したものです。
分散認証 UI サーバーにパスワードを設定するには、次の手順に従います。
Access Manager サーバーで、次の手順を実行します。
ampassword -e ユーティリティーを使用して amadmin パスワードを暗号化します。Solaris システムの場合の例を示します。
# cd /opt/SUNWam/bin # ./ampassword -e amadmin-password AQIC0K3omEozd544XEJIg25GT2wi1D7UAQLX
暗号化された値を保存します。
Access Manager サーバーの AMConfig.properties ファイルから am.encryption.pwd プロパティーの値をコピーして保存します。次に例を示します。
am.encryption.pwd=ydV8JXhJF2J35vpxjZRiGt7SH/7mUr+Y
分散認証 UI サーバーで、AMConfig.properties ファイルに対して次の変更を行います。
com.iplanet.am.service.password プロパティーをコメントにします。
com.iplanet.am.service.secret プロパティーを手順 1a で暗号化された amadmin パスワードに設定します。
手順 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
分散認証 UI サーバーを再起動します。
Access Manager コンソールのオンラインヘルプの「設定」>「システムプロパティー」>「プラットフォーム」にある「新しいサイト名を作成する」には、保存手順が記載されていません。新しいサイト名を追加したあとで、「保存」をクリックせずにインスタンス名を追加しようとすると、処理が失敗します。このため、サイト名を追加したあとは、必ず「保存」をクリックしてからインスタンス名を追加してください。
Solaris システムと Linux システムの amsamplesilent ファイルでは、Access Manager の管理者 (amadmin) パスワードの設定パラメータは ADMINPASSWD です。しかし、Windows システムの AMConfigurator.properties ファイルでは、このパラメータは ADMIN_PASSWD です。
Windows システムで amconfig.bat を実行する場合は、ADMINPASSWD ではなく ADMIN_PASSWORD パラメータを使用して AMConfigurator.properties ファイルの amadmin パスワードを設定してください。
「Web サービスサンプルを実行すると「Resource offering not found」が返される (6359900)」 の回避方法の手順 3 が修正されました。
com.iplanet.am.session.protectedPropertiesList パラメータを使用すると、特定のコアまたは内部セッションプロパティーを、セッションサービスの SetProperty メソッドによるリモート更新から保護できます。この「非表示」キーセキュリティーパラメータを設定することで、認証や Access Manager のその他の機能が利用できるようにセッション属性をカスタマイズできます。このパラメータを使用するには、次の手順に従います。
テキストエディタで、このパラメータを AMConfig.properties ファイルに追加します。
保護する必要のあるセッションプロパティーに、このパラメータを設定します。次に例を示します。
com.iplanet.am.session.protectedPropertiesList = PropertyName1,PropertyName2,PropertyName3
Access Manager Web コンテナを再起動して、値を有効にします。
各パッチを適用後、データを 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 ファイルの次のプロパティーは使用されていません。
com.iplanet.am.directory.host com.iplanet.am.directory.port
AMConfig.properties ファイル内の com.iplanet.am.session.client.polling.enable プロパティーは、サーバー側で true に設定してはいけません。
回避方法: このプロパティーはデフォルトで false に設定されており、true にリセットしてはいけません。
service.scserviceprofile.iplanetamauthservice.html オンラインヘルプファイル内にある「デフォルト成功 URL」が正しくありません。「デフォルト成功 URL」フィールドは、正常に認証された後に、リダイレクトされる URL を指定した複数の値が含まれるリストを受け入れます。この属性のフォーマットは clientType|URL で、URL の値だけを指定できますが、デフォルトタイプは HTML を前提としています。
デフォルト値「/amconsole」は正しくありません。
回避方法 正しいデフォルト値は「/amserver/console」です。
Bouncy Castle JAR ファイルを使用して、Access Manager または Federation Manager で XML 暗号化を有効にしてトランスポートキーを生成するには、次の手順に従います。
JDK 1.5 より前の JDK バージョンを使用している場合は、Bouncy Castle サイト (http://www.bouncycastle.org/) から Bouncy Castle JCE プロバイダをダウンロードします。たとえば、JDK 1.4 の場合、bcprov-jdk14-131.jar ファイルをダウンロードします。
前の手順で JAR ファイルをダウンロードした場合は、ファイルを jdk_root/jre/lib/ext ディレクトリにコピーします。
JDK の国内版の場合、Sun サイト (http://java.sun.com) から、お使いの JDK のバージョンに対応する JCE Unlimited Strength Jurisdiction Policy Files をダウンロードします。IBM WebSphere の場合は、対応する IBM サイトに移動し、必要なファイルをダウンロードします。
ダウンロードした US_export_policy.jar および local_policy.jar ファイルを jdk_root/jre/lib/security ディレクトリにコピーします。
JDK 1.5 より前の JDK のバージョンを使用している場合は、jdk_root/jre/lib/security/java.security ファイルを編集し、プロバイダの 1 つとして Bouncy Castle を追加します。次に例を示します。
security.provider.6=org.bouncycastle.jce.provider.BouncyCastleProvider
AMConfig.properties ファイルで、次のプロパティーを true に設定します。
com.sun.identity.jss.donotInstallAtHighestPriority=true
Access Manager Web コンテナを再起動します。
詳細については、問題 ID 5110285 (XML 暗号化には Bouncy Castle JAR ファイルが必要) を参照してください。