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 に格納されます。
組織管理者は設定済み組織のすべてのエントリに対する読み取りアクセス権と書き込みアクセス権を持っています。
組織のヘルプデスク管理者は、設定済み組織のすべてのエントリに対する読み取りアクセス権、およびこれらのエントリ内の userPassword 属性に対する書き込みアクセス権を持っています。
組織のポリシー管理者は、組織のすべてのポリシーに対する読み取りアクセス権と書き込みアクセス権を持っています。
これらのロールのいずれかをユーザーに割り当てると、そのロールに与えられたすべてのアクセス権がユーザーに与えられます。
次の表に、Access Manager 管理ロール、および各ロールに適用される権限の要約を示します。
表 3–2 旧バージョンモードでのデフォルトロールおよび動的ロールと各ロールのアクセス権
ロール |
管理サフィックス |
アクセス権 |
---|---|---|
最上位組織の管理者 (amadmin) |
ルートレベル |
最上位組織内のすべてのエントリ (ロール、ポリシー、グループなど) に対する読み取りおよび書き込みアクセス権。 |
最上位組織のヘルプデスク管理者 |
ルートレベル |
最上位組織内のすべてのパスワードに対する読み取りおよび書き込みアクセス権。 |
最上位組織のポリシー管理者 |
ルートレベル |
すべてのレベルのポリシーに対する読み取りおよび書き込みアクセス権。参照ポリシー作成を委任するため、下位組織により使用されます。 |
組織管理者 |
組織のみ |
作成された下位組織内のすべてのエントリ (ロール、ポリシー、グループなど) に対する読み取りおよび書き込みアクセス権のみ。 |
組織のヘルプデスク管理者 |
組織のみ |
作成された下位組織内のすべてのパスワードに対する読み取りおよび書き込みアクセス権のみ。 |
組織ポリシー管理者 (Organization Policy Admin) |
組織のみ |
作成された下位組織内のすべてのポリシーに対する読み取りおよび書き込みアクセス権のみ。 |
コンテナ管理者 (Container Admin) |
コンテナのみ |
作成されたコンテナ内のすべてのエントリ (ロール、ポリシー、グループなど) に対する読み取りおよび書き込みアクセス権のみ。 |
コンテナヘルプデスク管理者 (Container Help Desk Admin) |
コンテナのみ |
作成されたコンテナ内のすべてのパスワードに対する読み取りおよび書き込みアクセス権のみ。 |
グループ管理者 |
グループのみ |
作成されたグループ内のすべてのエントリ (ロール、ポリシー、グループなど) に対する読み取りおよび書き込みアクセス権のみ。 |
ピープルコンテナ管理者 |
ピープルコンテナのみ |
作成されたピープルコンテナ内のすべてのエントリ (ロール、ポリシー、グループなど) に対する読み取りおよび書き込みアクセス権のみ。 |
ユーザー (自己管理者) |
ユーザーのみ |
ユーザーエントリ内のすべての属性に対する読み取りおよび書き込みアクセス権のみ (nsroledn や inetuserstatus などのユーザー属性を除く)。 |
グループベースの ACI の代わりにロールを使用すると、効率を高め、保守の手間を少なくすることができます。フィルタ処理されたロールは、ユーザーの nsRole 属性の確認のみを行うため、LDAP クライアントの処理が簡略化されます。ロールは、そのメンバーの親のピアでなければならない、という範囲制限の影響を受けます。
デフォルトACI については、Access Manager コンソールのオンラインヘルプを参照してください。
Access Manager のインストール時には、次の管理アカウントが作成されます。
管理者ユーザー ID (amadmin) は、Access Manager の最上位管理者で、Access Manager によって管理されるすべてのエントリに無制限にアクセスできます。デフォルト名の amadmin を変更することはできません。
インストール中に、amadmin のパスワードを入力する必要があります。インストール後に amadmin のパスワードを変更するには、Access Manager 管理コンソールを使用します。
LDAP、メンバーシップ、およびポリシーサービスのバインド DN ユーザー ( amldapuser) は、すべての Directory Server エントリに対する読み取りおよび検索アクセス権を持つ管理ユーザーです。デフォルト名の amldapuser を変更することはできません。
インストール中に、amldapuser のパスワードを入力する必要があります。amadmin と同じパスワードは使用しないでください。インストール後に amldapuser のパスワードを変更するには、Directory Server コンソールか ldapmodify ユーティリティーを使用します。
amldapuser のパスワードを変更した場合は、LDAP 認証サービスとポリシー設定サービスにも、この変更を反映させる必要があります。amldapuser は、これらのサービスで使用されているデフォルトユーザーだからです。この変更は、これらのサービスを登録している組織ごとに行う必要があります。
プロキシユーザー (puser) は、任意のユーザー (組織管理者またはエンドユーザーなど) の権限を引き受けることができます。
管理ユーザー (dsameuser) は、Access Manager SDK が、特定のユーザーにリンクされていない Directory Server 上で、サービス設定情報の取得などの操作を実行するときバインドするために使用されます。
puser および dsameuser は関連付けられたパスワードを所有し、それぞれのパスワードは serverconfig.xml に暗号化された形式で格納されています。このファイルは次のディレクトリ内にあります。
Solaris システム: /etc/opt/SUNWam/config
Linux および HP-UX システム: /etc/opt/sun/identity/config
Windows システム: javaes-install-dir\identity\config
javaes-install-dir 変数は Java ES 5 のインストールディレクトリを表します。デフォルト値は C:\Program Files\Sun\JavaES5 です。
インストール後に、puser および dsameuser のパスワードを変更することをお勧めします。ただし、amadmin や amldapuser に使用したものと同じパスワードを使用しないでください。puser または dsameuser のパスワードを変更するには、ampassword ユーティリティーを使用します。
ampassword --admin (または -a) オプションでは、dsameuser のパスワードが変更されます。(このオプションでは、amadmin のパスワードは変更されません。)
ampassword --proxy (または -p) オプションでは、puser のパスワードが変更されます。
puser と dsameuser のどちらのパスワードを変更するかは、ユーザーの配備によって決まります。
Access Manager が単一のホストサーバー上に配備されている場合は、次の手順を実行します。
ampassword ユーティリティーを使用して、Directory Server とローカルの serverconfig.xml ファイル内のそれぞれのパスワードを変更します。
Access Manager Web コンテナを再起動します。
Access Manager が複数のホストサーバー上に配備されている場合は、次の手順を実行します。
最初のサーバー上で、ampassword ユーティリティーを使用して、Directory Server とローカルの serverconfig.xml ファイル内のそれぞれのパスワードを変更します。
ampassword --encrypt (または -e) オプションを使用して、新しいパスワードを暗号化します。
Access Manager の配備されているその他の各サーバー上で、手順 2 で暗号化した新しいパスワードを使用して、serverconfig.xml ファイル内のパスワードを手動で変更します。
パスワードを変更した各サーバー上 (最初のサーバーを含む) で、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 エージェントは、AMAgent.properties ファイルの次のプロパティーを使用して、Access Manager への認証に使用する自身のユーザー名とパスワードを保存します。
com.sun.am.policy.am.username には、Web エージェントが Access Manager にログインするために使用するユーザー名が格納されます。デフォルト名は UrlAccessAgent です。
com.sun.am.policy.am.password には、Web エージェントが Access Manager にログインするために使用するユーザーの暗号化されたパスワードが格納されます。パスワードは crypt_util ユーティリティーを使用して暗号化する必要があります。
Access Manager インスタンスを最初に設定するとき、Java ES インストーラまたは amconfig スクリプトによって、amldapuser ユーザーと同じパスワードを持つ amService-UrlAccessAgent ユーザーが最上位レベルレルムに作成されます。
デフォルトでは、すべての Web エージェントが同じユーザー名とパスワードを使用して Access Manager インスタンスへの認証を行います。セキュリティーを強化し、各 Web エージェントが一意の名前とパスワードを使用できるようにするために、Web エージェントが認証時に使用するエージェントプロファイルを Access Manager 管理コンソールで作成できます。詳細は、「エージェントプロファイルを使用した認証」を参照してください。
J2EE エージェントは、Access Manager 管理コンソールで作成されたエージェントプロファイルによるユーザー名 (エージェント ID) とパスワードを使用して Access Manager と通信します。エージェントプロファイルが作成されると、J2EE エージェントは AMAgent.properties ファイルの次のプロパティーを使用してユーザー名 (エージェント ID) とパスワードを保存します。
com.sun.identity.agents.app.username には、J2EE エージェントが Access Manager へのログインに使用するユーザー名 (エージェント ID) が格納されます。
com.iplanet.am.service.secret には、J2EE エージェントが Access Manager へのログインに使用するユーザー名 (エージェント ID) の暗号化されたパスワードが格納されます。パスワードは agentadmin ユーティリティーと --encrypt オプションを使用して暗号化する必要があります。
エージェントプロファイルについては、次の節を参照してください。
Access Manager への認証を行うには、J2EE エージェントが使用するエージェントプロファイルを Access Manager 管理コンソールで作成する必要があります。Web エージェントもエージェントプロファイルを使用できます。これにより、各 Web エージェントに一意のユーザー名 (エージェント ID) とパスワードを設定できるようになります。エージェントプロファイルの作成手順については、Access Manager コンソールのオンラインヘルプを参照してください。
エージェントプロファイルを使用すると、ポリシーエージェントのパスワードとユーザー名 (エージェント ID) を、配備ごとの必要に応じて変更できるようにもなります。必要な場合にパスワードとユーザー名を変更するには、次の一般的な手順に従います。
Access Manager 管理者 (amadmin) として Access Manager コンソールにログインします。
ポリシーエージェントのエージェントプロファイルで、必要に応じてパスワードとユーザー名 (エージェント ID) を変更します。プロファイルを保存します。
手順 2 で変更した新しいエージェントパスワードを、Web エージェントの場合は crypt_util ユーティリティーを使用して、J2EE エージェントの場合は agentadmin ユーティリティーと --encrypt オプションを使用して暗号化します。
ポリシーエージェントの 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) を設定します。
新しいパスワード (および、変更した場合は新しいユーザー名) を有効にするために、Web エージェントの Web コンテナを再起動します。
エージェントプロファイルの作成および設定とパスワードの暗号化については、Access Manager Policy Agent 2.2 のマニュアルコレクションを参照してください。