Sun Java System Access Manager 7.1 配備計画ガイド

管理ユーザー

Access Manager 配備の技術要件を評価するときは、次の管理ユーザーおよび管理アカウントについて考慮します。

Access Manager の管理ロール

レルムモードの管理ロール

Access Manager のレルムモードでは、委任プラグインがアイデンティティーリポジトリプラグインと連携して、ネットワーク管理者の権限の有効範囲を決定します。デフォルトの管理者ロールはアイデンティティーリポジトリプラグインで定義されます。委任プラグインは、個々のネットワーク管理者の権限の有効範囲を記述するルールを形成するとともに、そのルールが適用されるロールを指定します。次の表に、アイデンティティーリポジトリで定義されるロールと、委任プラグインが各ロールに適用するデフォルトルールの一覧を示します。

表 3–1 レルムモードでの Access Manager のロールと権限の有効範囲

アイデンティティーリポジトリのロール 

委任ルール 

レルム管理者 

Access Manager 情報ツリーのすべてのレルム内にあるすべてのデータにアクセスできます。 

サブレルム管理者 

Access Manager 情報ツリーの特定のレルム内にあるすべてのデータにアクセスできます。 

ポリシー管理者 

Access Manager 情報ツリーのすべてのレルム内にあるすべてのポリシーにアクセスできます。 

ポリシーレルム管理者 

Access Manager 情報ツリーの特定レルム内部にあるポリシーのみにアクセスできます。 

認証サービスとポリシーサービスは、集積されたデータを使用して認証および承認のプロセスを実行します。委任プラグインおよびアイデンティティーリポジトリプラグインのコードは、Access Manager で公開されていません。

旧バージョンモードの管理ロール

Access Manager の旧バージョンモードでは、LDAP エントリの委任管理 (Access Manager 内の各アイデンティティー関連オブジェクトにマップされる) は、定義済みのロールおよびアクセス制御命令 (ACI) を使用して実装されます。デフォルトの管理ロールおよびその定義済み ACI は、Access Manager のインストール時に作成され、Access Manager コンソールを使用して表示および管理できます。Access Manager 7.1 のレルムモードでは、ロールは ACI ではなくポリシーに依存します。

Access Manager のアイデンティティー関連オブジェクトが作成されると、適切な管理ロール (および対応する ACI) も作成され、そのオブジェクトの LDAP エントリに割り当てられます。そのあと、ロールは、そのオブジェクトのノード制御を管理する個々のユーザーに割り当てることができます。たとえば、Access Manager が組織を新規作成すると、いくつかのロールが自動的に作成され、Directory Server に格納されます。

これらのロールのいずれかをユーザーに割り当てると、そのロールに与えられたすべてのアクセス権がユーザーに与えられます。

次の表に、Access Manager 管理ロール、および各ロールに適用される権限の要約を示します。

表 3–2 旧バージョンモードでのデフォルトロールおよび動的ロールと各ロールのアクセス権

ロール 

管理サフィックス 

アクセス権 

最上位組織の管理者 (amadmin) 

ルートレベル 

最上位組織内のすべてのエントリ (ロール、ポリシー、グループなど) に対する読み取りおよび書き込みアクセス権。 

最上位組織のヘルプデスク管理者 

ルートレベル 

最上位組織内のすべてのパスワードに対する読み取りおよび書き込みアクセス権。 

最上位組織のポリシー管理者 

ルートレベル 

すべてのレベルのポリシーに対する読み取りおよび書き込みアクセス権。参照ポリシー作成を委任するため、下位組織により使用されます。 

組織管理者 

組織のみ 

作成された下位組織内のすべてのエントリ (ロール、ポリシー、グループなど) に対する読み取りおよび書き込みアクセス権のみ。 

組織のヘルプデスク管理者 

組織のみ 

作成された下位組織内のすべてのパスワードに対する読み取りおよび書き込みアクセス権のみ。 

組織ポリシー管理者 (Organization Policy Admin) 

組織のみ 

作成された下位組織内のすべてのポリシーに対する読み取りおよび書き込みアクセス権のみ。 

コンテナ管理者 (Container Admin) 

コンテナのみ 

作成されたコンテナ内のすべてのエントリ (ロール、ポリシー、グループなど) に対する読み取りおよび書き込みアクセス権のみ。 

コンテナヘルプデスク管理者 (Container Help Desk Admin) 

コンテナのみ 

作成されたコンテナ内のすべてのパスワードに対する読み取りおよび書き込みアクセス権のみ。 

グループ管理者 

グループのみ 

作成されたグループ内のすべてのエントリ (ロール、ポリシー、グループなど) に対する読み取りおよび書き込みアクセス権のみ。 

ピープルコンテナ管理者 

ピープルコンテナのみ 

作成されたピープルコンテナ内のすべてのエントリ (ロール、ポリシー、グループなど) に対する読み取りおよび書き込みアクセス権のみ。 

ユーザー (自己管理者) 

ユーザーのみ 

ユーザーエントリ内のすべての属性に対する読み取りおよび書き込みアクセス権のみ (nsroledninetuserstatus などのユーザー属性を除く)。

グループベースの ACI の代わりにロールを使用すると、効率を高め、保守の手間を少なくすることができます。フィルタ処理されたロールは、ユーザーの nsRole 属性の確認のみを行うため、LDAP クライアントの処理が簡略化されます。ロールは、そのメンバーの親のピアでなければならない、という範囲制限の影響を受けます。

デフォルトACI については、Access Manager コンソールのオンラインヘルプを参照してください。

Access Manager の管理アカウント

Access Manager のインストール時には、次の管理アカウントが作成されます。

puser および dsameuser は関連付けられたパスワードを所有し、それぞれのパスワードは serverconfig.xml に暗号化された形式で格納されています。このファイルは次のディレクトリ内にあります。

インストール後に、puser および dsameuser のパスワードを変更することをお勧めします。ただし、amadminamldapuser に使用したものと同じパスワードを使用しないでください。puser または dsameuser のパスワードを変更するには、ampassword ユーティリティーを使用します。

puserdsameuser のどちらのパスワードを変更するかは、ユーザーの配備によって決まります。

Access Manager が単一のホストサーバー上に配備されている場合は、次の手順を実行します。

  1. ampassword ユーティリティーを使用して、Directory Server とローカルの serverconfig.xml ファイル内のそれぞれのパスワードを変更します。

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

Access Manager が複数のホストサーバー上に配備されている場合は、次の手順を実行します。

  1. 最初のサーバー上で、ampassword ユーティリティーを使用して、Directory Server とローカルの serverconfig.xml ファイル内のそれぞれのパスワードを変更します。

  2. ampassword --encrypt (または -e) オプションを使用して、新しいパスワードを暗号化します。

  3. Access Manager の配備されているその他の各サーバー上で、手順 2 で暗号化した新しいパスワードを使用して、serverconfig.xml ファイル内のパスワードを手動で変更します。

  4. パスワードを変更した各サーバー上 (最初のサーバーを含む) で、Access Manager Web コンテナを再起動します。

ampassword ユーティリティーについては、『Sun Java System Access Manager 7.1 Administration Reference 』を参照してください。

ポリシーエージェントの管理ユーザー

Access Manager Policy Agent 2.2 ソフトウェアセットのポリシーエージェントは、その AMAgent.properties ファイルに保存されたユーザー名とパスワードを使用して Access Manager への認証を行います。このプロセスは 「Web エージェント」「J2EE エージェント」では似ている部分もありますが、多少の違いがあります。

Web エージェント

Web エージェントは、AMAgent.properties ファイルの次のプロパティーを使用して、Access Manager への認証に使用する自身のユーザー名とパスワードを保存します。

Access Manager インスタンスを最初に設定するとき、Java ES インストーラまたは amconfig スクリプトによって、amldapuser ユーザーと同じパスワードを持つ amService-UrlAccessAgent ユーザーが最上位レベルレルムに作成されます。

デフォルトでは、すべての Web エージェントが同じユーザー名とパスワードを使用して Access Manager インスタンスへの認証を行います。セキュリティーを強化し、各 Web エージェントが一意の名前とパスワードを使用できるようにするために、Web エージェントが認証時に使用するエージェントプロファイルを Access Manager 管理コンソールで作成できます。詳細は、「エージェントプロファイルを使用した認証」を参照してください。

J2EE エージェント

J2EE エージェントは、Access Manager 管理コンソールで作成されたエージェントプロファイルによるユーザー名 (エージェント ID) とパスワードを使用して Access Manager と通信します。エージェントプロファイルが作成されると、J2EE エージェントは AMAgent.properties ファイルの次のプロパティーを使用してユーザー名 (エージェント ID) とパスワードを保存します。

エージェントプロファイルについては、次の節を参照してください。

エージェントプロファイルを使用した認証

Access Manager への認証を行うには、J2EE エージェントが使用するエージェントプロファイルを Access Manager 管理コンソールで作成する必要があります。Web エージェントもエージェントプロファイルを使用できます。これにより、各 Web エージェントに一意のユーザー名 (エージェント ID) とパスワードを設定できるようになります。エージェントプロファイルの作成手順については、Access Manager コンソールのオンラインヘルプを参照してください。

エージェントプロファイルを使用すると、ポリシーエージェントのパスワードとユーザー名 (エージェント ID) を、配備ごとの必要に応じて変更できるようにもなります。必要な場合にパスワードとユーザー名を変更するには、次の一般的な手順に従います。

  1. Access Manager 管理者 (amadmin) として Access Manager コンソールにログインします。

  2. ポリシーエージェントのエージェントプロファイルで、必要に応じてパスワードとユーザー名 (エージェント ID) を変更します。プロファイルを保存します。

  3. 手順 2 で変更した新しいエージェントパスワードを、Web エージェントの場合は crypt_util ユーティリティーを使用して、J2EE エージェントの場合は agentadmin ユーティリティーと --encrypt オプションを使用して暗号化します。

  4. ポリシーエージェントの AMAgent.properties ファイルで、次のプロパティーを設定します。

    • Web エージェントの場合: com.sun.am.policy.am.password プロパティーに、手順 3 で新しく暗号化したパスワードを設定します。ユーザー名 (エージェント ID) も変更した場合は、com.sun.am.policy.am.username プロパティーに、手順 2 で変更した新しいユーザー名 (エージェント ID) を設定します。

    • J2EE エージェントの場合: com.iplanet.am.service.secret プロパティーに、手順 3 で新しく暗号化したパスワードを設定します。ユーザー名 (エージェント ID) も変更した場合は、com.sun.identity.agents.app.username プロパティーに、手順 2 で変更した新しいユーザー名 (エージェント ID) を設定します。

  5. 新しいパスワード (および、変更した場合は新しいユーザー名) を有効にするために、Web エージェントの Web コンテナを再起動します。

エージェントプロファイルの作成および設定とパスワードの暗号化については、Access Manager Policy Agent 2.2 のマニュアルコレクションを参照してください。

http://docs.sun.com/coll/1322.1