「ディレクトリ管理」タブは、Access Manager を旧バージョンモードでインストールした場合にのみ表示されます。このディレクトリ管理機能は、Sun Java System の Directory Server に対応した Access Manager の配備に必要なアイデンティティー管理ソリューションを提供します。
インストール時の旧バージョンモードオプションについては、『Sun Java Enterprise System 5 インストールガイド (UNIX 版)』を参照してください。
「ディレクトリ管理」タブには、Directory Server オブジェクトの表示および管理に必要なすべてのコンポーネントが含まれています。この節では、オブジェクトタイプと、それらを設定する方法の詳細について説明します。Access Manager コンソールまたはコマンド行インタフェースを使用して、ユーザー、ロール、グループ、組織、サブ組織、およびコンテナの各オブジェクトを定義、修正、または削除できます。コンソールには、ディレクトリオブジェクトを作成および管理する権限が異なる、複数のデフォルト管理者が存在しています。ロールに基づいて、管理者を追加作成できます。管理者は、Access Manager でインストールしたときに、Directory Server 内に定義されます。次の Directory Server オブジェクトを管理できます。
組織は、企業が部門とリソースの管理に使用する最上位レベルの階層構造を表します。インストール時に、Access Manager は最上位レベルの組織 (インストール時に定義) を動的に作成して、Access Manager の企業構成を管理します。インストール後に組織を追加作成して、企業を個別に管理できます。作成した組織はすべて、最上位レベルの組織の下に入ります。
「ディレクトリ管理」タブをクリックします。
「組織」リストで、「新規」をクリックします。
フィールドの値を入力します。「名前」だけが必須です。フィールドは次のとおりです。
組織の名前の値を入力します。
ドメインネームシステム (DNS) を使用している場合は、DNS の完全な名前を入力します。
「アクティブ」または「非アクティブ」の状態を選択します。デフォルトは「アクティブ」です。これは、その組織の存続期間中であればいつでも、「プロパティー」アイコンを選択して変更できます。「非アクティブ」を選択すると、その組織にログインした場合、ユーザーアクセスが無効になります。
このフィールドでは、組織のエイリアス名を指定します。URL ログインで、認証にエイリアスを使用できるようになります。たとえば exampleorg という組織があり、エイリアスとして 123 および abc を指定すると、次の URL を使用して組織にログインできます。
http://machine.example.com/amserver/UI/Login?org=exampleorg
http://machine.example.com/amserver/UI/Login?org=abc
http://machine.example.com/amserver/UI/Login?org=123
組織のエイリアス名は、組織全体で一意でなければなりません。「一意の属性リスト」を使用して一意性を実現できます。
組織の DNS 名にエイリアス名を追加できます。この属性では、実際のドメインエイリアスだけを使用できます。ランダムな文字列は使用できません。たとえば example.com という DNS があり、exampleorg という組織のエイリアスとして example1.com および example2.com を指定すると、次の URL を使用して組織にログインできます。
http://machine.example.com/amserver/UI/
Login?org=exampleorg
http://machine.example1.com/amserver/
UI/Login?org=exampleorg
http://machine.example2.com/amserver/
UI/Login?org=exampleorg
組織内のユーザー用に一意の属性名リストを追加できます。たとえば、電子メールアドレスを示す一意の属性名を追加した場合、同一の電子メールアドレスを持つ 2 人のユーザーを作成できなくなります。このフィールドには、コンマ区切りのリストも指定できます。リスト内の属性名は、どれも一意性を定義します。たとえば、このフィールドに次の属性名リストが指定されたとします。
PreferredDomain, AssociatedDomain
また、特定のユーザーに対して、PreferredDomain は http://www.example.com と定義されています。この場合、コンマ区切りのリスト全体が、その URL に関して一意であると定義されます。「一意の属性リスト」にネーミング属性「ou」を追加しても、デフォルトの groups、people コンテナでは一意性は要求されません。(ou=Groups、ou=People)。
すべてのサブ組織で一意性が要求されます。
一意の属性はレルムモードには設定できません。また、一意の属性は、7.0 または 7.1 ベースのコンソールで旧バージョンモードに設定することもできません。一意の属性リストを作成するには、6.3 ベースのコンソールにログインする必要があります。詳細は、「旧バージョンモード 6.3 コンソール」を参照してください。
「了解」をクリックします。
新しい組織が「組織」リストに表示されます。組織の作成時に定義したプロパティーを編集するには、編集対象の組織の名前をクリックし、プロパティーを変更して「保存」をクリックします。
削除する組織名の横にあるチェックボックスを選択します。
「削除」をクリックします。
削除を実行するときに警告メッセージは表示されません。組織内のエントリがすべて削除されます。この操作を元に戻すことはできません。
Access Manager オブジェクトは、ポリシーの対象定義を通じてポリシーに追加されます。ポリシーを作成または修正するときに、組織、ロール、グループ、ユーザーを対象として定義できます。対象を定義すると、ポリシーがオブジェクトに適用されます。詳細は、「ポリシーの管理」を参照してください。
コンテナエントリは、オブジェクトクラスおよび属性が異なるために組織エントリが使用できない場合に使用します。Access Manager コンテナエントリと Access Manager 組織エントリは、必ずしも LDAP オブジェクトクラス organizationalUnit および organization と同等とはかぎらないことに留意してください。これらは抽象アイデンティティーエントリです。可能であれば、コンテナエントリではなく組織エントリを使用します。
コンテナの表示は必要に応じて行います。コンテナを表示するには、「設定」>「コンソールプロパティー」の「管理」サービスでコンテナを表示するようにオプションを選択します。
新しいコンテナを作成する組織またはコンテナのリンクを選択します。
「コンテナ」タブをクリックします。
「コンテナ」リストで「新規」をクリックします。
作成するコンテナの名前を入力します。
「了解」をクリックします。
「コンテナ」タブをクリックします。
削除するコンテナ名の横にあるチェックボックスを選択します。
「削除」をクリックします。
コンテナを削除すると、そのコンテナに含まれるオブジェクトがすべて削除されます。すべてのオブジェクトとサブコンテナが対象になります。
グループコンテナを使用してグループを管理します。グループコンテナにはグループとほかのグループコンテナだけを含めることができます。グループコンテナの「グループ」は、すべての管理されているグループの親エントリとしてダイナミックに割り当てられます。必要に応じて、グループコンテナを追加することができます。
グループコンテナの表示は必要に応じて行います。グループコンテナを表示するには、「設定」>「コンソールプロパティー」の「管理」サービスでグループコンテナを有効にするようにオプションを選択します。
新しいグループコンテナを追加する組織またはグループコンテナのリンクを選択します。
「グループコンテナ」タブを選択します。
「グループコンテナ」リストで「新規」をクリックします。
「名前」フィールドに値を入力して、「了解」をクリックします。「グループコンテナ」リストに新しいグループコンテナが表示されます。
グループは、共通の機能、特徴、または関心事を持つユーザーの集まりを表します。通常、このグループには関連付けられた権限はありません。グループは、組織内および管理されているほかのグループ内という、2 つのレベルに存在できます。ほかのグループ内に存在するグループは、サブグループと呼ばれます。サブグループは、親グループ内に「物理的に」存在する子ノードです。
Access Manager は、入れ子グループもサポートします。入れ子グループは、1 つのグループに含まれる既存のグループを表します。サブグループとは対照的に、入れ子グループは DIT 内のどこにでも存在できます。入れ子グループは、多数のユーザーに対するアクセス権の設定を簡単にします。
作成できるグループには、静的グループと動的グループの 2 種類があります。ユーザーを手動で追加できるのは静的グループのみです。動的グループでは、フィルタによってユーザーの追加が制御されます。入れ子グループまたはサブグループは、両方に追加できます。
静的グループは、指定した管理されているグループタイプに基づいて作成されます。グループメンバーは、groupOfNames または groupOfUniqueNames オブジェクトクラスを使用してグループエントリに追加されます。
管理されているグループタイプのデフォルトは dynamic です。このデフォルトは、管理サービス設定で変更できます。
動的グループ
動的グループは、LDAP フィルタを使用して作成されます。エントリはすべてフィルタを通してまとめられ、グループに動的に割り当てられます。フィルタはエントリの属性を検索して、その属性を含むエントリを返します。たとえば、建物番号に基づいてグループを作成する場合、フィルタを使用すると建物番号属性を含むすべてのユーザーのリストを返します。
Access Manager は、Directory Server とともに参照整合性プラグインを使用するように設定されている必要があります。参照整合性プラグインが有効になっているときは、削除操作や名前の変更操作の直後に、指定された属性について整合性更新が実行されます。これにより、関連するエントリ間の関係がデータベース全体で維持されます。Directory Server では、データベースインデックスによって検索パフォーマンスが向上します。このプラグインを有効にする方法の詳細は、『Sun Java System Access Manager 6 Migration Guide』を参照してください。
新しいグループを作成する組織、グループ、またはグループコンテナに移動します。
「グループ」リストから「新規静的」をクリックします。
「グループ名」フィールドにグループの名前を入力します。「次へ」をクリックします。
「ユーザーのグループ加入を有効」属性を選択すると、ユーザーが自分でそのグループに加入できるようになります。
「了解」をクリックします。
グループの作成後、グループの名前を選択して「一般」をクリックすることにより、「ユーザーのグループ加入を有効」属性を編集できます。
「グループ」リストから、メンバーを追加するグループを選択します。
「アクションの選択」メニューで実行するアクションを選択します。実行できるアクションは次のとおりです。
このアクションでは、新規ユーザーが作成され、ユーザー情報の保存時にユーザーがグループに追加されます。
このアクションでは、既存のユーザーがグループに追加されます。このアクションを選択する場合は、追加するユーザーを指定する検索条件を作成します。条件の作成に使用するフィールドでは、「いずれか」または「すべて」演算子を使用します。「すべて」は、指定したすべてのフィールドに一致するユーザーを返します。「いずれか」は、指定したいずれか 1 つのフィールドに一致するユーザーを返します。フィールドを空白のままにすると、その属性に関してはすべてのエントリが一致したとみなされます。
検索条件を作成したら、「次へ」をクリックします。返されたユーザーのリストから、追加するユーザーを選択し、「終了」をクリックします。
このアクションでは、入れ子グループが現在のグループに追加されます。このアクションを選択すると、検索範囲、グループの名前 ("*" ワイルドカードを使用可能) を含む検索条件を作成し、ユーザーが自分でグループに加入できるかどうかを指定できます。情報を入力したら、「次へ」をクリックします。返されたグループのリストから、追加するグループを選択し、「終了」をクリックします。
このアクションでは、グループからメンバー (ユーザーとグループを含む) が消去されますが、メンバー自身の削除はされません。消去するメンバーを選択し、「アクションの選択」メニューから「メンバーを消去」を選択します。
このアクションでは、選択されたメンバー自身のエントリーが Directory Server から物理的に削除されます。削除するメンバーを選択し、「メンバーを削除」を選択します。
新しいグループを作成する組織またはグループに移動します。
「グループ」タブをクリックします。
「新規動的」をクリックします。
「グループ名」フィールドにグループの名前を入力します。
LDAP 検索フィルタを作成します。
デフォルトでは、Access Manager は基本検索フィルタインタフェースを表示します。フィルタの作成に使用する基本フィールドでは、「いずれか」または「すべて」演算子を使用します。「すべて」は、指定したすべてのフィールドに一致するユーザーを返します。「いずれか」は、指定したいずれか 1 つのフィールドに一致するユーザーを返します。フィールドを空白のままにすると、その属性に関してはすべてのエントリが一致したとみなされます。
「了解」をクリックすると、検索条件に一致するすべてのユーザーが自動的にグループに追加されます。
「グループ」リストで、メンバーを追加するグループの名前をクリックします。
「アクションの選択」メニューで実行するアクションを選択します。実行できるアクションは次のとおりです。
このアクションでは、入れ子グループが現在のグループに追加されます。このアクションを選択すると、検索範囲、グループの名前 ("*" ワイルドカードを使用可能) を含む検索条件を作成し、ユーザーが自分でグループに加入できるかどうかを指定できます。情報を入力したら、「次へ」をクリックします。返されたグループのリストから、追加するグループを選択し、「終了」をクリックします。
このアクションでは、グループからメンバー (グループを含む) が消去されますが、メンバー自身の削除はされません。消去するメンバーを選択し、「メンバーを消去」を選択します。
このアクションでは、選択されたメンバー自身のエントリーが Directory Server から物理的に削除されます。削除するメンバーを選択し、「メンバーを削除」を選択します。
Access Manager オブジェクトは、ポリシーの対象定義を通じてポリシーに追加されます。ポリシーを作成または修正するときに、ポリシーの「対象」ページで、組織、ロール、グループ、ユーザーを対象として定義できます。対象を定義すると、ポリシーがオブジェクトに適用されます。詳細は、「ポリシーの管理」を参照してください。
ピープルコンテナはデフォルトの LDAP 組織単位です。ユーザーはすべて、組織内で作成されるときにその組織単位に割り当てられます。ピープルコンテナは組織レベルで、あるいはサブピープルコンテナとしてピープルコンテナレベルで表示されます。ピープルコンテナにはほかのピープルコンテナとユーザーだけを含めることができます。必要に応じて、ピープルコンテナを組織に追加することができます。
ピープルコンテナの表示は必要に応じて行います。ピープルコンテナを表示するには、管理サービスで「ピープルコンテナを有効」を選択します
削除対象のピープルコンテナを含む組織またはピープルコンテナに移動します。
削除するピープルコンテナ名の横にあるチェックボックスを選択します。
「削除」をクリックします。
ピープルコンテナを削除すると、そのピープルコンテナに含まれるオブジェクトがすべて削除されます。すべてのユーザーとサブピープルコンテナが対象になります。
ユーザーは、個人のアイデンティティーを表します。Access Manager のアイデンティティー管理モジュールを使用して、組織、コンテナ、およびグループに対するユーザーの作成と削除、ロールやグループに対するユーザーの追加と削除が可能です。サービスをユーザーに割り当てることもできます。
amadmin と同じユーザー ID でサブ組織のユーザーを作成すると、amadmin のログインが失敗します。このような問題が起こったら、管理者はディレクトリサーバーコンソールを使って、そのユーザーの ID を変更する必要があります。これで、管理者がデフォルトの組織にログインできるようになります。さらに、認証サービスの「ユーザー検索の開始 DN」をピープルコンテナ DN に設定し、ログイン処理で一意のユーザーが特定できます。
ユーザーを作成する組織、コンテナ、またはピープルコンテナに移動します。
「ユーザー」タブをクリックします。
「ユーザー」リストで「新規」をクリックします。
次の値のデータを入力します。
このフィールドには、ユーザーが Access Manager へログインするために使用する名前を指定します。このプロパティーは、DN 以外の値になることがあります。
このフィールドには、ユーザーの名 (ファーストネーム) を指定します。名 (ファーストネーム) の値と姓 (ラストネーム) の値によって、「現在ログイン中」フィールドのユーザーが識別されます。これは必須の値ではありません。
このフィールドには、ユーザーの姓 (ラストネーム) を指定します。名 ( ファーストネーム) の値と姓 ( ラストネーム) の値によってユーザーが識別されます。
このフィールドには、ユーザーのフルネームを指定します。
このフィールドには、「ユーザー ID」フィールドで指定した名前のパスワードを指定します。
パスワードを確認します。
このオプションは、Access Manager による認証をユーザーに許可するかどうかを指定します。アクティブなユーザーだけが認証を受けることができます。デフォルト値は「アクティブ」です。
「了解」をクリックします。
管理者ロールを割り当てられていないユーザーが Access Manager に認証されると、そのユーザーのユーザープロファイルがデフォルトの表示になります。また、適切な権限を持つ管理者はユーザープロファイルを編集できます。この表示では、ユーザーが各自の個人プロファイルに特有の属性値を編集できます。ユーザープロファイルビューに表示された属性は、展開することができます。オブジェクトおよびアイデンティティーのためにカスタマイズされた属性の追加については、『Access Manager Developer's Guide』を参照してください。
プロファイルが編集されるユーザーを選択します。デフォルトでは、「一般」表示となっています。
次のフィールドを編集します。
このフィールドには、ユーザーの名 (ファーストネーム) を指定します。
このフィールドには、ユーザーの姓 (ラストネーム) を指定します。
このフィールドには、ユーザーのフルネームを指定します。
「編集」リンクをクリックして、ユーザーのパスワードを追加し、確認します。
このフィールドには、ユーザーの電子メールアドレスを指定します。
このフィールドには、ユーザーの社員番号を指定します。
このフィールドには、ユーザーの電話番号を指定します。
このフィールドには、ユーザーのホームアドレスを指定します。
このオプションは、Access Manager による認証をユーザーに許可するかどうかを指定します。アクティブなユーザーだけが Access Manager を使用して認証を受けることができます。デフォルト値は「アクティブ」です。プルダウンメニューから次のどちらかを選択することができます。
「アクティブ」— ユーザーは Access Manager を使用して認証を受けることができます。
「非アクティブ」— ユーザーは Access Manager を使用して認証を受けることはできませんが、ユーザープロファイルはそのままディレクトリに格納されます。
ユーザー状態を「非アクティブ」に変えても、Access Manager による認証に影響するだけです。Directory Server は、nsAccountLock 属性を使用してユーザーアカウント状態を判別しますが、Access Manager での「ユーザー状態」の設定は、nsAccountLock 属性には影響しません。Access Manager にて、ユーザー状態を「非アクティブ」にしたユーザーアカウントでも、Access Manager を必要としないタスクは実行できます。Access Manager 認証だけではなく、ディレクトリのユーザーアカウントも無効にするには、nsAccountLock の値を「false」に設定します。サイトの委託管理者がユーザーを定期的に無効にしている場合は、nsAccountLock 属性を Access Manager のユーザープロファイルページに追加することを検討してください。詳細は、『Sun Java System Access Manager 7.1 Developer’s Guide』を参照してください。
この属性が存在し、その値が現在の日時以前であれば、認証サービスはログインを無効にします。この属性の形式は次のとおりです。mm/dd/yyyy hh:mm
この属性は、ユーザーの認証連鎖を設定します。
このフィールドは、ユーザーに適用される可能性のあるエイリアスを定義します。この属性に設定されたエイリアスを使用するために、iplanet-am-user-alias-list 属性を LDAP サービスのユーザーエントリ検索属性フィールドに追加して、LDAP サービスを修正する必要があります。
このフィールドは、ユーザーのロケールを指定します。
この属性は、認証が成功した場合にユーザーをリダイレクトする URL を指定します。
この属性は、認証が失敗した場合にユーザーをリダイレクトする URL を指定します。
ここでは、パスワードを忘れた場合に使用する質問を選択します。パスワードを忘れたときは、選択した質問に答えることで、パスワードを回復できます。
ユーザーの、ユーザーディスカバリサービスのリソースオファリングを設定します。
MSISDN 認証を使用している場合に、ユーザーの MSISDN 番号を定義します。
「ユーザー」タブをクリックします。
変更するユーザーの名前をクリックします。
「ロール」タブまたは「グループ」タブを選択します。
ユーザーを追加するロールまたはグループを選択し、「追加」をクリックします。
「保存」をクリックします。
ロールまたはグループからユーザーを削除するには、ロールまたはグループを選択し、「削除」をクリックして「保存」をクリックします。
Access Manager オブジェクトは、ポリシーの対象定義を通じてポリシーに追加されます。ポリシーを作成または修正するときに、ポリシーの「対象」ページで、組織、ロール、グループ、ユーザーを対象として定義できます。対象を定義すると、ポリシーがオブジェクトに適用されます。詳細は、「ポリシーの管理」を参照してください。
ロールとは、グループの概念に似た、Directory Server の 1 つのエントリメカニズムです。グループにはメンバーがあるように、ロールにもメンバーがあります。ロールのメンバーは、ロールを持つ LDAP エントリです。ロール自体の基準は、属性を持つ LDAP エントリとして定義されます。このエントリは、エントリの識別名 (DN) 属性で特定されます。Directory Server にはさまざまなタイプのロールがありますが、Access Manager で管理できるのは、管理ロールだけです。
そのほかの Directory Server ロールタイプもディレクトリの配備で使用できますが、Access Manager コンソールで管理することはできません。ポリシーの対象定義にほかの Directory Server タイプを使用することもできます。ポリシー対象については、「ポリシーの作成」を参照してください。
ユーザーには 1 つ以上のロールを持たせることができます。たとえば、セッションサービスとパスワードリセットサービスの属性を持つ契約社員ロールを作成できます。新しい契約社員が入社したときに、管理者は契約社員エントリの別の属性を設定しなくても、契約社員にこのロールを割り当てることができます。契約社員がエンジニアリング部門に属し、エンジニアリング社員に適用可能なサービスとアクセス権が必要な場合は、管理者は契約社員にエンジニアリングロールおよび契約社員ロールを割り当てることができます。
Access Manager では、ロールを使用して、アクセス制御の命令を適用します。Access Manager をはじめてインストールしたときに、管理者アクセス権を定義するアクセス制御命令 (ACI) が定義されます。次にこれらの ACI をロール (組織管理者ロール、組織ヘルプデスク管理者ロールなど) に割り当てます。このロールをユーザーに割り当てると、ユーザーのアクセス権が定義されます。
ユーザーは、管理サービスで「ユーザープロファイルページにロールを表示」属性が有効である場合だけ、割り当てられたロールを確認できます。
Access Manager は、Directory Server とともに参照整合性プラグインを使用するように設定されている必要があります。参照整合性プラグインが有効になっているときは、削除操作や名前の変更操作の直後に、指定された属性について整合性更新が実行されます。これにより、関連するエントリどうしの関係がデータベース全体で維持されます。Directory Server では、データベースインデックスによって検索パフォーマンスが向上します。
ロールには、次の 2 種類があります。
静的ロール — 静的ロールは、ロールの作成時にユーザーを追加せずに作成されます。ロールを作成したあとで、特定のユーザーをそのロールに追加できます。これにより、ユーザーを指定されたロールに追加するときにより細かく制御できます。
動的ロール – 動的ロールは、LDAP フィルタを使用して作成されます。ユーザーはすべてフィルタを通してまとめられ、ロールの作成時にそのロールに割り当てられます。フィルタはエントリの属性と値のペア (ca=user* など) を検索して、その属性を含むユーザーをロールに自動的に割り当てます。
ロールを作成する組織に移動します。
「ロール」タブをクリックします。
組織の設定時にデフォルトのロールが作成され、「ロール」リストに表示されます。デフォルトのロールは次のとおりです。
コンテナヘルプデスク管理者: コンテナのヘルプデスク管理者ロールは、組織単位のすべてのエントリに対する読み取りアクセス権、およびそのコンテナ単位だけにあるユーザーエントリの userPassword 属性に対する書き込みアクセス権を持っています。
組織ヘルプデスク管理者: 組織ヘルプデスク管理者は、組織のすべてのエントリに対する読み取りアクセス権、および userPassword 属性に対する書き込みアクセス権を持っています。
サブ組織を作成するときは、管理者ロールは親組織ではなくサブ組織に作成してください。
コンテナ管理者: コンテナ管理者ロールは、LDAP 組織単位のすべてのエントリに対する読み取りアクセス権と書き込みアクセス権を持っています。Access Manager では、LDAP 組織単位をコンテナと呼ぶことがあります。
組織ポリシー管理者: 組織のポリシー管理者は、組織のすべてのポリシーに対する読み取りアクセス権と書き込みアクセス権を持っており、組織内のすべてのポリシーについて作成、割り当て、修正、および削除ができます。
ピープル管理者: デフォルトで、新規に作成した組織のユーザーエントリはその組織のメンバーです。ピープル管理者は、組織のすべてのユーザーエントリに対する読み取りアクセス権と書き込みアクセス権を持っています。なお、このロールは、ロールおよびグループ DN を含む属性に対する読み取りアクセス権と書き込みアクセス権を持っていないため、ロールまたはグループの属性を変更したり、ロールまたはグループからユーザーを消去したりすることができません。
ほかのコンテナは、Access Manager とともに設定して、ユーザーエントリ、グループエントリ、またはほかのコンテナを保持することができます。組織を構成したあとで、作成されたコンテナに管理者ロールを適用するには、デフォルトのコンテナ管理者ロールまたはコンテナヘルプデスク管理者を使用します。
グループ管理者: グループ作成時に作成されたグループ管理者は、特定グループのすべてのメンバーに対する読み取りアクセス権および書き込みアクセス権を持っており、新しいユーザーの作成、管理しているグループへのユーザーの割り当て、および作成したユーザーの削除を行うことができます。
グループを作成すると、そのグループを管理するのに必要な権限を持つグループ管理者ロールが自動的に作成されます。このロールはグループのメンバーに自動的には割り当てられません。グループの作成者、またはグループ管理者ロールへのアクセス権を持つ人が割り当てる必要があります。
最上位レベル管理者: 最上位レベル管理者は、最上位レベル組織のすべてのエントリに対する読み取りアクセス権と書き込みアクセス権を持っています。言い換えれば、最上位レベル管理者ロールには、Access Manager アプリケーション内のすべての設定主体に対する権限があります。
組織管理者: 組織管理者は、組織のすべてのエントリに対する読み取りアクセス権と書き込みアクセス権を持っています。組織を作成すると、その組織を管理するのに必要な権限を持つ組織管理者ロールが自動的に作成されます。
「新規静的」ボタンをクリックします。
ロールの名前を入力します。
ロールの詳細を入力します。
「タイプ」メニューからロールのタイプを選択します。
ロールは、管理者ロールまたはサービスロールにすることができます。ロールのタイプは、Access Manager コンソールが、コンソール内でどのユーザーをどの位置から始動させるかを決定するために使用します。管理者ロールは、ロールの所有者が管理者権限を持っていることをコンソールに通知します。サービスロールは、その所有者がエンドユーザーであることをコンソールに通知します。
「アクセス権」メニューから、ロールに適用する権限のデフォルトセットを選択します。これは、組織内のエントリにアクセスする権限です。ここで示すデフォルトの権限は順不同です。権限は次のとおりです。
ロールにアクセス権が設定されません。
組織管理者は設定済み組織のすべてのエントリに対する読み取りアクセス権と書き込みアクセス権を持っています。
組織ヘルプデスク管理者は、設定済み組織のすべてのエントリに対する読み取りアクセス権、および userPassword 属性に対する書き込みアクセス権を持っています。
組織のポリシー管理者は、組織のすべてのポリシーに対する読み取りアクセス権と書き込みアクセス権を持っています。組織のポリシー管理者は、ピア組織に対する参照ポリシーを作成できません。
一般に、「アクセス権なし」ACI をサービスロールに割り当て、管理者ロールにはデフォルト ACI のいずれかを割り当てます。
ユーザーを追加するロールの名前をクリックします。
「メンバー」リストで、「アクションの選択」メニューから「ユーザーの追加」を選択します。
検索条件を入力します。表示される 1 つ以上のフィールドを基に、ユーザーの検索方法を選択できます。フィールドは次のとおりです。
フィルタ用として含めるフィールドを選択できます。「すべて」は、指定したすべてのフィールドに一致するユーザーを返します。「いずれか」は、指定したいずれか 1 つのフィールドに一致するユーザーを返します。
名 (ファーストネーム) でユーザーを検索します。
ユーザー ID でユーザーを検索します。
姓 (ラストネーム) でユーザーを検索します。
フルネームでユーザーを検索します。
ユーザーの状態 (アクティブまたは非アクティブ) でユーザーを検索します。
「次へ」をクリックすると、検索が始まります。検索結果が表示されます。
ユーザー名の横にあるチェックボックスを選択して、返された名前の中からユーザーを選択します。
「終了」をクリックします。
これで、ユーザーがロールに割り当てられます。
ロールを作成する組織に移動します。
「ロール」タブをクリックします。
組織の設定時にデフォルトのロールが作成され、「ロール」リストに表示されます。デフォルトのロールは次のとおりです。
コンテナヘルプデスク管理者: コンテナのヘルプデスク管理者ロールは、組織単位のすべてのエントリに対する読み取りアクセス権、およびそのコンテナ単位だけにあるユーザーエントリの userPassword 属性に対する書き込みアクセス権を持っています。
組織ヘルプデスク管理者: 組織ヘルプデスク管理者は、組織のすべてのエントリに対する読み取りアクセス権、および userPassword 属性に対する書き込みアクセス権を持っています。
サブ組織を作成するときは、管理者ロールは親組織ではなくサブ組織に作成してください。
コンテナ管理者: コンテナ管理者ロールは、LDAP 組織単位のすべてのエントリに対する読み取りアクセス権と書き込みアクセス権を持っています。Access Manager では、LDAP 組織単位をコンテナと呼ぶことがあります。
組織ポリシー管理者: 組織のポリシー管理者は、組織のすべてのポリシーに対する読み取りアクセス権と書き込みアクセス権を持っており、組織内のすべてのポリシーについて作成、割り当て、修正、および削除ができます。
ピープル管理者: デフォルトで、新規に作成した組織のユーザーエントリはその組織のメンバーです。ピープル管理者は、組織のすべてのユーザーエントリに対する読み取りアクセス権と書き込みアクセス権を持っています。なお、このロールは、ロールおよびグループ DN を含む属性に対する読み取りアクセス権と書き込みアクセス権を持っていないため、ロールまたはグループの属性を変更したり、ロールまたはグループからユーザーを消去したりすることができません。
ほかのコンテナは、Access Manager とともに設定して、ユーザーエントリ、グループエントリ、またはほかのコンテナを保持することができます。組織を構成したあとで、作成されたコンテナに管理者ロールを適用するには、デフォルトのコンテナ管理者ロールまたはコンテナヘルプデスク管理者を使用します。
グループ管理者: グループ作成時に作成されたグループ管理者は、特定グループのすべてのメンバーに対する読み取りアクセス権および書き込みアクセス権を持っており、新しいユーザーの作成、管理しているグループへのユーザーの割り当て、および作成したユーザーの削除を行うことができます。
グループを作成すると、そのグループを管理するのに必要な権限を持つグループ管理者ロールが自動的に作成されます。このロールはグループのメンバーに自動的には割り当てられません。グループの作成者、またはグループ管理者ロールへのアクセス権を持つ人が割り当てる必要があります。
最上位レベル管理者: 最上位レベル管理者は、最上位レベル組織のすべてのエントリに対する読み取りアクセス権と書き込みアクセス権を持っています。言い換えれば、最上位レベル管理者ロールには、Access Manager アプリケーション内のすべての設定主体に対する権限があります。
組織管理者: 組織管理者は、組織のすべてのエントリに対する読み取りアクセス権と書き込みアクセス権を持っています。組織を作成すると、その組織を管理するのに必要な権限を持つ組織管理者ロールが自動的に作成されます。
「新規動的」ボタンをクリックします。
ロールの名前を入力します。
ロールの詳細を入力します。
「タイプ」メニューからロールのタイプを選択します。
ロールは、管理者ロールまたはサービスロールにすることができます。ロールのタイプは、Access Manager コンソール内でどのユーザーをどの位置から始動させるかを決定するために使用します。管理者ロールは、ロールの所有者が管理者権限を持っていることをコンソールに通知します。サービスロールは、その所有者がエンドユーザーであることをコンソールに通知します。
「アクセス権」メニューから、ロールに適用する権限のデフォルトセットを選択します。これは、組織内のエントリにアクセスする権限です。ここで示すデフォルトの権限は順不同です。権限は次のとおりです。
ロールにアクセス権が設定されません。
組織管理者は設定済み組織のすべてのエントリに対する読み取りアクセス権と書き込みアクセス権を持っています。
組織ヘルプデスク管理者は、設定済み組織のすべてのエントリに対する読み取りアクセス権、および userPassword 属性に対する書き込みアクセス権を持っています。
組織のポリシー管理者は、組織のすべてのポリシーに対する読み取りアクセス権と書き込みアクセス権を持っています。組織のポリシー管理者は、ピア組織に対する参照ポリシーを作成できません。
一般に、「アクセス権なし」ACI をサービスロールに割り当て、管理者ロールにはデフォルト ACI のいずれかを割り当てます。
検索条件を入力します。フィールドは次のとおりです。
演算子を含めるフィルタのフィールドに、演算子を含めることができます。「すべて」は、指定したすべてのフィールドに一致するユーザーを返します。「いずれか」は、指定したいずれか 1 つのフィールドに一致するユーザーを返します。
名 (ファーストネーム) でユーザーを検索します。
ユーザー ID でユーザーを検索します。
姓 (ラストネーム) でユーザーを検索します。
フルネームでユーザーを検索します。
ユーザーの状態 (アクティブまたは非アクティブ) でユーザーを検索します。
「了解」をクリックして、フィルタ条件を基に、検索を開始します。そのフィルタ条件で定義されたユーザーがロールに自動的に割り当てられます。
変更するロールを含む組織に移動します。
アイデンティティー管理モジュールで「表示」メニューから「組織」を選択し、「ロール」タブを選択します。
変更するロールを選択します。
「表示」メニューから「ユーザー」を選択します。
消去する各ユーザーの横にあるチェックボックスを選択します。
「アクションの選択」メニューから「ユーザーの消去」をクリックします。
これで、ロールからユーザーが消去されます。
Access Manager オブジェクトは、ポリシーの対象定義を通じてポリシーに追加されます。ポリシーを作成または修正するときに、ポリシーの「対象」ページで、組織、ロール、グループ、ユーザーを対象として定義できます。対象を定義すると、ポリシーがオブジェクトに適用されます。詳細は、「ポリシーの管理」を参照してください。