test

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

マニュアルに関する情報

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 ファイルが必要) を参照してください。