Sun Java System Access Manager 7 2005Q4 配備計画ガイド

Access Manager スキーマ

スキーマとは、データに課されるルールセットのことで、通常はデータの格納方法の定義に利用されます。Sun Java System Directory Server は LDAP (Lightweight Directory Access Protocol) スキーマを使用して、データの格納方法を定義します。オブジェクトクラスは、LDAP スキーマ内の属性を定義します。Directory Server では、各データエントリは、内部の属性セットを記述および定義するオブジェクトのタイプを指定するため、1 つ以上のオブジェクトクラスを保持する必要があります。基本的に、各エントリは、属性セットとその対応する値、およびこれらの属性に対応するオブジェクトクラスのリストになります。

Access Manager は、Sun Java System Directory Server をデータリポジトリとして使用します。このリポジトリには Directory Server スキーマを拡張する Access Manager スキーマが組み込まれています。Access Manager のインストール時に、ds_remote_schema.ldif と sunone_schema2.ldif のファイルで構成される Access Manager スキーマは、Directory Server スキーマと統合されます。ds_remote_schema.ldif ファイルは、Access Manager が固有に使用するLDAP オブジェクトクラスと属性を定義します。sunone_schema2.ldif ファイルは、Access Manager LDAP スキーマのオブジェクトクラスと属性をロードします。

ds_remote_schema.ldif、sunone_schema2.ldif 、およびその他の Access Manager LDIF ファイルは、以下のディレクトリにあります。

Solaris システム: /etc/opt/SUNWam/config/ldif
Linux システム: /etc/opt/sun/identity/config/ldif

マーカーオブジェクトクラス

Access Manager コンソールを使用して作成し、Directory Server 内に格納したアイデンティティーエントリには、マーカーオブジェクトクラスが追加されます。マーカーオブジェクトクラスは、指定されたエントリを Access Manager が管理するエントリとして定義します。オブジェクトクラスは、サーバーやハードウェアなど、ディレクトリツリーのほかの面には影響を与えません。また、既存のアイデンティティーエントリは、これらのオブジェクトクラスを含めるようにエントリを変更しない限り、Access Manager を使用して管理することはできません。マーカーオブジェクトクラスについては、『Access Manager 開発者ガイド』を参照してください。既存の Directory Server データを Access Manager で使用するために移行する方法については、『 Sun Java Access Manager 6 2005Q1 Migration Guide』を参照してください。

管理ロール

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

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

組織管理者は設定済み組織のすべてのエントリに対する読み取りアクセス権と書き込みアクセス権を持っています。
組織のヘルプデスク管理者は、設定済み組織のすべてのエントリに対する読み取りアクセス権、およびこれらのエントリ内の userPassword 属性に対する書き込みアクセス権を持っています。
組織のポリシー管理者は、組織のすべてのポリシーに対する読み取りアクセス権と書き込みアクセス権を持っています。

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

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

表 3–1 デフォルトおよび動的なロールとそのアクセス権


ロール	管理サフィックス	アクセス権
最上位組織の管理者 (amadmin)	ルートレベル	最上位組織内のすべてのエントリ (ロール、ポリシー、グループなど) に対する読み取りおよび書き込みアクセス権。
最上位組織のヘルプデスク管理者	ルートレベル	最上位組織内のすべてのパスワードに対する読み取りおよび書き込みアクセス権。
最上位組織のポリシー管理者	ルートレベル	すべてのレベルのポリシーに対する読み取りおよび書き込みアクセス権。参照ポリシー作成を委任するため、下位組織により使用されます。
組織管理者	組織のみ	作成された下位組織内のすべてのエントリ (ロール、ポリシー、グループなど) に対する読み取りおよび書き込みアクセス権のみ。
組織のヘルプデスク管理者	組織のみ	作成された下位組織内のすべてのパスワードに対する読み取りおよび書き込みアクセス権のみ。
組織ポリシー管理者 (Organization Policy Admin)	組織のみ	作成された下位組織内のすべてのポリシーに対する読み取りおよび書き込みアクセス権のみ。
コンテナ管理者 (Container Admin)	コンテナのみ	作成されたコンテナ内のすべてのエントリ (ロール、ポリシー、グループなど) に対する読み取りおよび書き込みアクセス権のみ。
コンテナヘルプデスク管理者 (Container Help Desk Admin)	コンテナのみ	作成されたコンテナ内のすべてのパスワードに対する読み取りおよび書き込みアクセス権のみ。
グループ管理者	グループのみ	作成されたグループ内のすべてのエントリ (ロール、ポリシー、グループなど) に対する読み取りおよび書き込みアクセス権のみ。
ピープルコンテナ管理者	ピープルコンテナのみ	作成されたピープルコンテナ内のすべてのエントリ (ロール、ポリシー、グループなど) に対する読み取りおよび書き込みアクセス権のみ。
ユーザー (自己管理者)	ユーザーのみ	ユーザーエントリ内のすべての属性に対する読み取りおよび書き込みアクセス権のみ (`nsroledn` や `inetuserstatus` などのユーザー属性を除く)。

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

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

Access Manager の管理アカウント

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

管理者ユーザー ID (amadmin) は、Access Manager の最上位管理者で、Access Manager によって管理されるすべてのエントリに無制限にアクセスできます。デフォルト名の amadmin を変更することはできません。

インストール中に、amadmin のパスワードを入力する必要があります。インストール後に amadmin のパスワードを変更するには、Directory Server コンソールか ldapmodify ユーティリティーを使用します。
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 システム: /etc/opt/sun/identity/config

インストール後に、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 2005Q4 管理ガイド』を参照してください。

スキーマの制限

Access Manager は、管理するエントリを抽象的に表現します。したがって、たとえば、Access Manager 内の組織は、Directory Server 内の組織とは必ずしも同じにはなりません。特定の DIT (Directory Infromation Tree) を管理できるかどうかは、ディレクトリエントリを表すまたは管理する方法と、DIT が各 Access Manager タイプの制限に適しているかどうかによります。

以下の項で、Access Manager スキーマに課される制限について説明します。この節の最後には、「サポートされない DIT の例」も複数記載しています。

組織としてマークできるエントリのタイプは 1 つに限られる

Access Manager sunISManagedOrganization 予備クラスを、任意のエントリに追加することにより、 Access Manager では、このエントリを組織であるように管理できます。ただし、組織としてマークできるエントリのタイプは 1 つに限られます。たとえば、DIT にエントリ o=sun と別のエントリ dc=ibm がある場合、両方のエントリを組織としてマークすることはできません。

次の例では、dc と o の両方のエントリを組織にしようとしていますが、この DIT 構造は Access Manager で管理できません。

ただし、Access Manager ルートサフィックスでのエントリは、1 つのエントリには数えられません。したがって、次の例のDIT 構造は、Access Manager で管理できます。

o=continent1 の下に dc=company1 を追加した場合、dc がコンテナとしてマークされている場合にのみ、このDIT の管理が可能になります。コンテナは、Access Manager の別の抽象タイプであり、通常、OrganizationalUnit にマッピングされます。ほとんどの DIT では、 iplanet-am-managed-container エントリをすべての OrganizationlUnits に追加します。

ただし、このマーカーオブジェクトクラスはどのエントリタイプにも追加できます。次の例の DIT 構造が可能です。

この例では、o= と ou= の両方のエントリを組織としてマークすることはできないため、o= エントリを organization としてマークし、ou= エントリを containers としてマークしています。コンソールに表示されるときに、組織とコンテナで利用できるオプションは同じです。従属または下位区分、ピープルコンテナ、グループ、ロール、およびユーザーは、両方の内部で作成できます。

ピープルコンテナをユーザーの親エントリにする必要がある

もう 1 つの抽象エントリタイプはピープルコンテナです。Access Manager タイプは、このエントリがユーザーの親エントリであると想定します。ピープルコンテナとしてエントリに iplanet-am-managed-people-container のマークが付けられていると、UI は、このコンテナには下位ピープルコンテナまたはユーザーだけが存在すると見なします。属性 OrganizationUnit が通常、ピープルコンテナとして使用されますが、iplanet-am-managed-people-container オブジェクトクラスを保有し、Access Manager の管理可能な親タイプの organization または container を保持する限り、Access Manager のどのエントリでもピープルコンテナとして使用できます。

Access Manager XML で可能な組織の説明は 1 つに限られる

Access Manager の組織は、amEntrySpecific.xml で定義されます。このファイルでは、1 つの組織の説明だけを記述できます。この結果、ディレクトリエントリのプロパティーをカスタマイズしたり、管理ページや検索ページを UI 内に作成すると、カスタム属性は Access Manager 設定全体に適用されます。この Access Manager 要件は、特にホスティングサービスを行う企業など、配備における組織ごとに異なる表示属性を必要とする諸企業のニーズに合わない場合があります。

次の例で、Edison-Watson 社はホスティング企業として、インターネットサービスを多数の企業に提供しています。企業 A では、ユーザーの姓、名、バッジ番号を入力するフィールドを表示する必要があります。企業 B では、ユーザーの姓、名、社員番号を入力するフィールドを表示する必要があります。

組織の説明は、組織レベルではなくルートレベル (o=EdisonWatson) で定義されます。デフォルトでは、企業 A と企業 B の両方の UI を同一にする必要があります。また、すべてのサービスは、下位スキーマタイプユーザーの属性になるように、属性をグローバルに定義します。したがって、企業 A が、予備クラス CompanyA-user にそのユーザー用の属性を保持し、企業 B が、CompanyB-user に属性を保持している場合、企業 B の属性は上書きされ、表示されません。

回避策としては、ユーザー表示に対処するように ACI を修正する方法があります。ただしこの回避策は、「検索」および「作成」ウィンドウでの属性には対処しません。

サポートされない DIT の例

次の例では、次の 3 タイプの組織マーカーが必要になります。o、ou、および l。 l=california および l=alabama がピープルコンテナではないと見なされるため、この DIT は Access Manager では動作しません。

次の例では、3 タイプの Access Manager マーカー (dc、o、ou)、およびピープルコンテナ (ou=people) が必要になります。この条件下では、DIT は Access Manager で動作しません。