test

Sun Java System Access Manager 7 2005Q4 管理ガイド

パート III ディレクトリ管理とデフォルトサービス

これは『Sun Java System Access Manager 7 2005Q4 管理ガイド』の第 3 部です。「ディレクトリ管理」の章では、Access Manager を旧バージョンモードで配備するときにディレクトリオブジェクトを管理する方法について説明します。その他の章では、Access Manager の一部のデフォルトサービスを設定および使用する方法について説明します。次の章で構成されています。

第 10 章 ディレクトリ管理

「ディレクトリ管理」タブは、Access Manager を旧バージョンモードでインストールした場合にのみ表示されます。このディレクトリ管理機能は、Sun Java System の Directory Server に対応した Access Manager の配備に必要なアイデンティティー管理ソリューションを提供します。

インストール時の旧バージョンモードオプションについては、『Sun Java Enterprise System 2005Q4 Installation Guide for UNIX』を参照してください。

ディレクトリオブジェクトの管理

「ディレクトリ管理」タブには、Directory Server オブジェクトの表示および管理に必要なすべてのコンポーネントが含まれています。この節では、オブジェクトタイプと、それらを設定する方法の詳細について説明します。Access Manager コンソールまたはコマンド行インタフェースを使用して、ユーザー、ロール、グループ、組織、サブ組織、およびコンテナの各オブジェクトを定義、修正、または削除できます。コンソールには、ディレクトリオブジェクトを作成および管理する権限が異なる、複数のデフォルト管理者が存在しています。ロールに基づいて、管理者を追加作成できます。管理者は、Access Manager でインストールしたときに、Directory Server 内に定義されます。次の Directory Server オブジェクトを管理できます。

組織

組織は、企業が部門とリソースの管理に使用する最上位レベルの階層構造を表します。インストール時に、Access Manager は最上位レベルの組織 (インストール時に定義) を動的に作成して、Access Manager の企業構成を管理します。インストール後に組織を追加作成して、企業を個別に管理できます。作成した組織はすべて、最上位レベルの組織の下に入ります。

Procedure組織を作成する

手順

  1. 「ディレクトリ管理」タブをクリックします。

  2. 「組織」リストで、「新規」をクリックします。

  3. フィールドの値を入力します。「名前」だけが必須です。フィールドは次のとおりです。

    「名前」

    組織の名前の値を入力します。

    「ドメイン名」

    ドメインネームシステム (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 エイリアス名」

    組織の 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)。

    すべてのサブ組織で一意性が要求されます。

  4. 「了解」をクリックします。

    新しい組織が「組織」リストに表示されます。組織の作成時に定義したプロパティーを編集するには、編集対象の組織の名前をクリックし、プロパティーを変更して「保存」をクリックします。

Procedure組織を削除する

手順

  1. 削除する組織名の横にあるチェックボックスを選択します。

  2. 「削除」をクリックします。

    注 –

    削除を実行するときに警告メッセージは表示されません。組織内のエントリがすべて削除されます。この操作を元に戻すことはできません。

ポリシーに組織を追加する

Access Manager オブジェクトは、ポリシーの対象定義を通じてポリシーに追加されます。ポリシーを作成または修正するときに、組織、ロール、グループ、ユーザーを対象として定義できます。対象を定義すると、ポリシーがオブジェクトに適用されます。詳細は、「ポリシーの管理」を参照してください。

コンテナ

コンテナエントリは、オブジェクトクラスおよび属性が異なるために組織エントリが使用できない場合に使用します。Access Manager コンテナエントリと Access Manager 組織エントリは、必ずしも LDAP オブジェクトクラス organizationalUnit および organization と同等とはかぎらないことに留意してください。これらは抽象アイデンティティーエントリです。可能であれば、コンテナエントリではなく組織エントリを使用します。

注 –

コンテナの表示は必要に応じて行います。コンテナを表示するには、「設定」>「コンソールプロパティー」の「管理」サービスでコンテナを表示するようにオプションを選択します。

Procedureコンテナを作成する

手順

  1. 新しいコンテナを作成する組織またはコンテナのリンクを選択します。

  2. 「コンテナ」タブをクリックします。

  3. 「コンテナ」リストで「新規」をクリックします。

  4. 作成するコンテナの名前を入力します。

  5. 「了解」をクリックします。

Procedureコンテナを削除する

手順

  1. 「コンテナ」タブをクリックします。

  2. 削除するコンテナ名の横にあるチェックボックスを選択します。

  3. 「削除」をクリックします。

    注 –

    コンテナを削除すると、そのコンテナに含まれるオブジェクトがすべて削除されます。すべてのオブジェクトとサブコンテナが対象になります。

グループコンテナ

グループコンテナを使用してグループを管理します。グループコンテナにはグループとほかのグループコンテナだけを含めることができます。グループコンテナの「グループ」は、すべての管理されているグループの親エントリとして動的に割り当てられます。必要に応じて、グループコンテナを追加することができます。

注 –

グループコンテナの表示は必要に応じて行います。グループコンテナを表示するには、「設定」>「コンソールプロパティー」の「管理」サービスでグループコンテナを有効にするようにオプションを選択します。

Procedureグループコンテナを作成する

手順

  1. 新しいグループコンテナを追加する組織またはグループコンテナのリンクを選択します。

  2. 「グループコンテナ」タブを選択します。

  3. 「グループコンテナ」リストで「新規」をクリックします。

  4. 「名前」フィールドに値を入力して、「了解」をクリックします。「グループコンテナ」リストに新しいグループコンテナが表示されます。

Procedureグループコンテナを削除する

手順

  1. 削除対象のグループコンテナを含む組織に移動します。

  2. 「グループコンテナ」タブを選択します。

  3. 削除するグループコンテナの横にあるチェックボックスを選択します。

  4. 「削除」をクリックします。

グループ

グループは、共通の機能、特徴、または関心事を持つユーザーの集まりを表します。通常、このグループには関連付けられた権限はありません。グループは、組織内および管理されているほかのグループ内という、2 つのレベルに存在できます。ほかのグループ内に存在するグループは、サブグループと呼ばれます。サブグループは、親グループ内に「物理的に」存在する子ノードです。

Access Manager は、入れ子グループもサポートします。入れ子グループは、1 つのグループに含まれる既存のグループを表します。サブグループとは対照的に、入れ子グループは DIT 内のどこにでも存在できます。入れ子グループは、多数のユーザーに対するアクセス権の設定を簡単にします。

作成できるグループには、静的グループと動的グループの 2 種類があります。ユーザーを手動で追加できるのは静的グループのみです。動的グループでは、フィルタによってユーザーの追加が制御されます。入れ子グループまたはサブグループは、両方に追加できます。

静的グループ

静的グループは、指定した管理されているグループタイプに基づいて作成されます。グループメンバーは、groupOfNames または groupOfUniqueNames オブジェクトクラスを使用してグループエントリに追加されます。

注 –

管理されているグループタイプのデフォルトは dynamic です。このデフォルトは、管理サービス設定で変更できます。

動的グループ

動的グループは、LDAP フィルタを使用して作成されます。エントリはすべてフィルタを通してまとめられ、グループに動的に割り当てられます。フィルタはエントリの属性を検索して、その属性を含むエントリを返します。たとえば、建物番号に基づいてグループを作成する場合、フィルタを使用すると建物番号属性を含むすべてのユーザーのリストを返します。

注 –

Access Manager は、Directory Server とともに参照整合性プラグインを使用するように設定されている必要があります。参照整合性プラグインが有効になっているときは、削除操作や名前の変更操作の直後に、指定された属性について整合性更新が実行されます。これにより、関連するエントリどうしの関係がデータベース全体で維持されます。Directory Server では、データベースインデックスによって検索パフォーマンスが向上します。このプラグインを有効にする方法の詳細は、『Sun Java System Access Manager 6 2005Q1 Migration Guide』を参照してください。

Procedure静的グループを作成する

手順

  1. 新しいグループを作成する組織、グループ、またはグループコンテナに移動します。

  2. 「グループ」リストから「新規静的」をクリックします。

  3. 「グループ名」フィールドにグループの名前を入力します。「次へ」をクリックします。

  4. 「ユーザーのグループ加入を有効」属性を選択すると、ユーザーが自分でそのグループに加入できるようになります。

  5. 「了解」をクリックします。

    グループの作成後、グループの名前を選択して「一般」をクリックすることにより、「ユーザーのグループ加入を有効」属性を編集できます。

Procedure静的グループのメンバーを追加または削除する

手順

  1. 「グループ」リストから、メンバーを追加するグループを選択します。

  2. 「アクションの選択」メニューで実行するアクションを選択します。実行できるアクションは次のとおりです。

    「新規ユーザー」

    このアクションでは、新規ユーザーが作成され、ユーザー情報の保存時にユーザーがグループに追加されます。

    「ユーザーの追加」

    このアクションでは、既存のユーザーがグループに追加されます。このアクションを選択する場合は、追加するユーザーを指定する検索条件を作成します。条件の作成に使用するフィールドでは、「いずれか」または「すべて」演算子を使用します。「すべて」は、指定したすべてのフィールドに一致するユーザーを返します。「いずれか」は、指定したいずれか 1 つのフィールドに一致するユーザーを返します。フィールドを空白のままにすると、そのフィールドの属性に関しては条件を指定しなかったとみなされます。

    検索条件を作成したら、「次へ」をクリックします。返されたユーザーのリストから、追加するユーザーを選択し、「終了」をクリックします。

    「グループを追加」

    このアクションでは、入れ子グループが現在のグループに追加されます。このアクションを選択すると、検索範囲、グループの名前 ("*" ワイルドカードを使用可能) を含む検索条件を作成し、ユーザーが自分でグループに加入できるかどうかを指定できます。情報を入力したら、「次へ」をクリックします。返されたグループのリストから、追加するグループを選択し、「終了」をクリックします。

    「メンバーを消去」

    このアクションでは、グループからメンバー (ユーザーとグループを含む) が消去されますが、メンバー自身の削除はされません。消去するメンバーを選択し、「アクションの選択」メニューから「メンバーを消去」を選択します。

    「メンバーを削除」

    このアクションでは、選択されたメンバー自身のエントリーが Directory Server から物理的に削除されます。削除するメンバーを選択し、「メンバーを削除」を選択します。

Procedure動的グループを作成する

手順

  1. 新しいグループを作成する組織またはグループに移動します。

  2. 「グループ」タブをクリックします。

  3. 「新規動的」をクリックします。

  4. 「グループ名」フィールドにグループの名前を入力します。

  5. LDAP 検索フィルタを作成します。

    デフォルトでは、Access Manager は基本検索フィルタインタフェースを表示します。フィルタの作成に使用する基本フィールドでは、「いずれか」または「すべて」演算子を使用します。「すべて」は、指定したすべてのフィールドに一致するユーザーを返します。「いずれか」は、指定したいずれか 1 つのフィールドに一致するユーザーを返します。フィールドを空白のままにすると、そのフィールドの属性に関しては条件を指定しなかったとみなされます。

  6. 「了解」をクリックすると、検索条件に一致するすべてのユーザーが自動的にグループに追加されます。

Procedure動的グループのメンバーを追加または削除する

手順

  1. 「グループ」リストで、メンバーを追加するグループの名前をクリックします。

  2. 「アクションの選択」メニューで実行するアクションを選択します。実行できるアクションは次のとおりです。

    「グループを追加」

    このアクションでは、入れ子グループが現在のグループに追加されます。このアクションを選択すると、検索範囲、グループの名前 ("*" ワイルドカードを使用可能) を含む検索条件を作成し、ユーザーが自分でグループに加入できるかどうかを指定できます。情報を入力したら、「次へ」をクリックします。返されたグループのリストから、追加するグループを選択し、「終了」をクリックします。

    「メンバーを消去」

    このアクションでは、グループからメンバー (グループを含む) が消去されますが、メンバー自身の削除はされません。消去するメンバーを選択し、「メンバーを消去」を選択します。

    「メンバーを削除」

    このアクションでは、選択されたメンバー自身のエントリーが Directory Server から物理的に削除されます。削除するメンバーを選択し、「メンバーを削除」を選択します。

ポリシーにグループを追加する

Access Manager オブジェクトは、ポリシーの対象定義を通じてポリシーに追加されます。ポリシーを作成または修正するときに、ポリシーの「対象」ページで、組織、ロール、グループ、ユーザーを対象として定義できます。対象を定義すると、ポリシーがオブジェクトに適用されます。詳細は、「ポリシーの管理」を参照してください。

ピープルコンテナ

ピープルコンテナはデフォルトの LDAP 組織単位です。ユーザーはすべて、組織内で作成されるときにその組織単位に割り当てられます。ピープルコンテナは組織レベルで、あるいはサブピープルコンテナとしてピープルコンテナレベルで表示されます。ピープルコンテナにはほかのピープルコンテナとユーザーだけを含めることができます。必要に応じて、ピープルコンテナを組織に追加することができます。

注 –

ピープルコンテナの表示は必要に応じて行います。ピープルコンテナを表示するには、管理サービスで「ピープルコンテナを有効」を選択します

Procedureピープルコンテナを作成する

手順

  1. ピープルコンテナを作成する組織またはピープルコンテナに移動します。

  2. 「ピープルコンテナ」リストで「新規」をクリックします。

  3. 作成するピープルコンテナの名前を入力します。

  4. 「了解」をクリックします。

Procedureピープルコンテナを削除する

手順

  1. 削除対象のピープルコンテナを含む組織またはピープルコンテナに移動します。

  2. 削除するピープルコンテナ名の横にあるチェックボックスを選択します。

  3. 「削除」をクリックします。

    注 –

    ピープルコンテナを削除すると、そのピープルコンテナに含まれるオブジェクトがすべて削除されます。すべてのユーザーとサブピープルコンテナが対象になります。

ユーザー

ユーザーは、個人のアイデンティティーを表します。Access Manager のアイデンティティー管理モジュールを使用して、組織、コンテナ、およびグループに対するユーザーの作成と削除、ロールやグループに対するユーザーの追加と削除が可能です。サービスをユーザーに割り当てることもできます。

注 –

amadmin と同じユーザー ID でサブ組織のユーザーを作成すると、amadmin のログインが失敗します。このような問題が起こったら、管理者はディレクトリサーバーコンソールを使って、そのユーザーの ID を変更する必要があります。これで、管理者がデフォルトの組織にログインできるようになります。さらに、認証サービスの「ユーザー検索の開始 DN」をピープルコンテナ DN に設定し、ログイン処理で一意のユーザーが特定できます。

Procedureユーザーを作成する

手順

  1. ユーザーを作成する組織、コンテナ、またはピープルコンテナに移動します。

  2. 「ユーザー」タブをクリックします。

  3. 「ユーザー」リストで「新規」をクリックします。

  4. 次の値のデータを入力します。

    「ユーザー ID」

    このフィールドは、ユーザーが Access Manager へログインするために使用する名前を取得します。このプロパティーは、DN 以外の値になることがあります。

    「名」

    このフィールドには、ユーザーの名 (ファーストネーム) を指定します。名 (ファーストネーム) の値と姓 (ラストネーム) の値によって、「現在ログイン中」フィールドのユーザーが識別されます。これは必須の値ではありません。

    「姓」

    このフィールドはユーザーの姓 (ラストネーム) を取得します。名 (ファーストネーム) の値と姓 (ラストネーム) の値によってユーザーが識別されます。

    「フルネーム」

    このフィールドはユーザーのフルネームを取得します。

    「パスワード」

    このフィールドには、ユーザーのパスワードを入力します。

    「パスワード (確認)」

    パスワードを確認します。

    「ユーザー状態」

    このオプションは、Access Manager による認証をユーザーに許可するかどうかを指定します。アクティブなユーザーだけが認証を受けることができます。デフォルト値は「アクティブ」です。

  5. 「了解」をクリックします。

Procedureユーザープロファイルを編集する

管理者ロールを割り当てられていないユーザーが Access Manager に認証されると、そのユーザーのユーザープロファイルがデフォルトの表示になります。また、適切な権限を持つ管理者はユーザープロファイルを編集できます。この表示では、ユーザーが各自の個人プロファイルに特有の属性値を編集できます。ユーザープロファイルビューに表示された属性は、展開することができます。オブジェクトおよびアイデンティティーのためにカスタマイズされた属性の追加については、『Access Manager Developer's Guide』を参照してください。

手順

  1. プロファイルが編集されるユーザーを選択します。デフォルトでは、「一般」表示となっています。

  2. 次のフィールドを編集します。

    「名」

    このフィールドには、ユーザーの名 (ファーストネーム) を指定します。

    「姓」

    このフィールドはユーザーの姓 (ラストネーム) を取得します。

    「フルネーム」

    このフィールドはユーザーのフルネームを取得します。

    「パスワード」

    「編集」リンクをクリックして、ユーザーのパスワードを追加し、確認します。

    「電子メールアドレス」

    このフィールドで、ユーザーの電子メールアドレスを指定します。

    「社員番号」

    このフィールドで、ユーザーの社員番号を指定します。

    「電話番号」

    このフィールドで、ユーザーの電話番号を指定します。

    「ホームアドレス」

    このフィールドで、ユーザーのホームアドレスを指定します。

    「ユーザー状態」

    このオプションは、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 2005Q4 Developer’s Guide』を参照してください。

    「アカウント有効期限」

    この属性が存在し、その値が現在の日時以前であれば、認証サービスはログインを無効にします。この属性の形式は次のとおりです。mm/dd/yyyy hh:mm

    「ユーザー認証設定」

    この属性は、ユーザーの認証連鎖を設定します。

    「ユーザーエイリアスリスト」

    このフィールドは、ユーザーに適用される可能性のあるエイリアスを定義します。この属性に設定されたエイリアスを使用するために、iplanet-am-user-alias-list 属性を LDAP サービスのユーザーエントリ検索属性フィールドに追加して、LDAP サービスを修正する必要があります。

    「設定ロケール」

    このフィールドは、ユーザーのロケールを指定します。

    「成功 URL」

    この属性は、認証が成功した場合にユーザーをリダイレクトする URL を指定します。

    「失敗 URL」

    この属性は、認証が失敗した場合にユーザーをリダイレクトする URL を指定します。

    「パスワードリセットオプション」

    ここでは、パスワードを忘れた場合に使用する質問を選択します。パスワードを忘れたときは、選択した質問に答えることで、パスワードを回復できます。

    「ユーザーディスカバリのリソースオファリング」

    ユーザーの、ユーザーディスカバリサービスのリソースオファリングを設定します。

    「MSISDN 番号」

    MSISDN 認証を使用している場合に、ユーザーの MSISDN 番号を定義します。

Procedureロールおよびグループにユーザーを追加する

手順

  1. 「ユーザー」タブをクリックします。

  2. 変更するユーザーの名前をクリックします。

  3. 「ロール」タブまたは「グループ」タブを選択します。

  4. ユーザーを追加するロールまたはグループを選択し、「追加」をクリックします。

  5. 「保存」をクリックします。

    注 –

    ロールまたはグループからユーザーを削除するには、ロールまたはグループを選択し、「削除」をクリックして「保存」をクリックします。

ポリシーにユーザーを追加する

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 では、データベースインデックスによって検索パフォーマンスが向上します。このプラグインを有効にする方法の詳細は、『Sun Java System Access Manager 6 2005Q1 Migration Guide』を参照してください。

ロールには、次の 2 種類があります。

Procedure静的ロールを作成する

手順

  1. ロールを作成する組織に移動します。

  2. 「ロール」タブをクリックします。

    組織の設定時にデフォルトのロールが作成され、「ロール」リストに表示されます。デフォルトのロールは次のとおりです。

    コンテナヘルプデスク管理者: コンテナのヘルプデスク管理者ロールは、組織単位のすべてのエントリに対する読み取りアクセス権、およびそのコンテナ単位だけにあるユーザーエントリの userPassword 属性に対する書き込みアクセス権を持っています。

    組織ヘルプデスク管理者: 組織ヘルプデスク管理者は、組織のすべてのエントリに対する読み取りアクセス権、および userPassword 属性に対する書き込みアクセス権を持っています。

    注 –

    サブ組織を作成するときは、管理者ロールは親組織ではなくサブ組織に作成してください。

    コンテナ管理者: コンテナ管理者ロールは、LDAP 組織単位のすべてのエントリに対する読み取りアクセス権と書き込みアクセス権を持っています。Access Manager では、LDAP 組織単位をコンテナと呼ぶことがあります。

    組織ポリシー管理者: 組織ポリシー管理者は、組織のすべてのポリシーに対する読み取りアクセス権と書き込みアクセス権を持っており、組織内のすべてのポリシーについて作成、割り当て、修正、および削除ができます。

    ピープル管理者 デフォルトで、新規に作成した組織のユーザーエントリはその組織のメンバーです。ピープル管理者は、組織のすべてのユーザーエントリに対する読み取りアクセス権と書き込みアクセス権を持っています。なお、このロールは、ロールおよびグループ DN を含む属性に対する読み取りアクセス権と書き込みアクセス権を持っていないため、ロールまたはグループの属性を変更したり、ロールまたはグループからユーザーを消去したりすることができません。

    注 –

    ほかのコンテナは、Access Manager とともに設定して、ユーザーエントリ、グループエントリ、またはほかのコンテナを保持することができます。組織を構成したあとで、作成されたコンテナに管理者ロールを適用するには、デフォルトのコンテナ管理者ロールまたはコンテナヘルプデスク管理者を使用します。

    グループ管理者: グループ作成時に作成されたグループ管理者は、特定グループのすべてのメンバーに対する読み取りアクセス権および書き込みアクセス権を持っており、新しいユーザーの作成、管理しているグループへのユーザーの割り当て、および作成したユーザーの削除を行うことができます。

    グループを作成すると、そのグループを管理するのに必要な権限を持つグループ管理者ロールが自動的に作成されます。このロールはグループのメンバーに自動的には割り当てられません。グループの作成者、またはグループ管理者ロールへのアクセス権を持つ人が割り当てる必要があります。

    最上位レベル管理者: 最上位レベル管理者は、最上位レベル組織のすべてのエントリに対する読み取りアクセス権と書き込みアクセス権を持っています。言い換えれば、最上位レベル管理者ロールには、Access Manager アプリケーション内のすべての設定主体に対する権限があります。

    組織管理者: 組織管理者は、組織のすべてのエントリに対する読み取りアクセス権と書き込みアクセス権を持っています。組織を作成すると、その組織を管理するのに必要な権限を持つ組織管理者ロールが自動的に作成されます。

  3. 「新規静的」ボタンをクリックします。

  4. ロールの名前を入力します。

  5. ロールの詳細を入力します。

  6. 「タイプ」メニューからロールのタイプを選択します。

    ロールは、管理者ロールまたはサービスロールにすることができます。ロールのタイプは、Access Manager コンソールが、コンソール内でどのユーザーをどの位置から始動させるかを決定するために使用します。管理者ロールは、ロールの所有者が管理者権限を持っていることをコンソールに通知します。サービスロールは、その所有者がエンドユーザーであることをコンソールに通知します。

  7. 「アクセス権」メニューから、ロールに適用する権限のデフォルトセットを選択します。これは、組織内のエントリにアクセスする権限です。ここで示すデフォルトの権限は順不同です。権限は次のとおりです。

    アクセス権なし

    ロールにアクセス権が設定されません。

    組織管理者

    組織管理者は設定済み組織のすべてのエントリに対する読み取りアクセス権と書き込みアクセス権を持っています。

    組織ヘルプデスク管理者

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

    組織ポリシー管理者

    組織ポリシー管理者は、組織のすべてのポリシーに対する読み取りアクセス権と書き込みアクセス権を持っています。組織ポリシー管理者は、ピア組織に対する参照ポリシーを作成できません。

    一般に、「アクセス権なし」ACI をサービスロールに割り当て、管理者ロールにはデフォルト ACI のいずれかを割り当てます。

Procedure静的ロールにユーザーを追加する

手順

  1. ユーザーを追加するロールの名前をクリックします。

  2. 「メンバー」リストで、「アクションの選択」メニューから「ユーザーの追加」を選択します。

  3. 検索条件を入力します。表示される 1 つ以上のフィールドを基に、ユーザーの検索方法を選択できます。フィールドは次のとおりです。

    「一致」

    フィルタ用として含めるフィールドを選択できます。「すべて」は、指定したすべてのフィールドに一致するユーザーを返します。「いずれか」は、指定したいずれか 1 つのフィールドに一致するユーザーを返します。

    「名」

    名 (ファーストネーム) でユーザーを検索します。

    「ユーザー ID」

    ユーザー ID でユーザーを検索します。

    「姓」

    姓 (ラストネーム) でユーザーを検索します。

    「フルネーム」

    フルネームでユーザーを検索します。

    「ユーザー状態」

    ユーザーの状態 (アクティブまたは非アクティブ) でユーザーを検索します。

  4. 「次へ」をクリックすると、検索が始まります。検索結果が表示されます。

  5. ユーザー名の横にあるチェックボックスを選択して、返された名前の中からユーザーを選択します。

  6. 「終了」をクリックします。

    これで、ユーザーがロールに割り当てられます。

Procedure動的ロールを作成する

手順

  1. ロールを作成する組織に移動します。

  2. 「ロール」タブをクリックします。

    組織の設定時にデフォルトのロールが作成され、「ロール」リストに表示されます。デフォルトのロールは次のとおりです。

    コンテナヘルプデスク管理者: コンテナのヘルプデスク管理者ロールは、組織単位のすべてのエントリに対する読み取りアクセス権、およびそのコンテナ単位だけにあるユーザーエントリの userPassword 属性に対する書き込みアクセス権を持っています。

    組織ヘルプデスク管理者: 組織ヘルプデスク管理者は、組織のすべてのエントリに対する読み取りアクセス権、および userPassword 属性に対する書き込みアクセス権を持っています。

    注 –

    サブ組織を作成するときは、管理者ロールは親組織ではなくサブ組織に作成してください。

    コンテナ管理者: コンテナ管理者ロールは、LDAP 組織単位のすべてのエントリに対する読み取りアクセス権と書き込みアクセス権を持っています。Access Manager では、LDAP 組織単位をコンテナと呼ぶことがあります。

    組織ポリシー管理者: 組織ポリシー管理者は、組織のすべてのポリシーに対する読み取りアクセス権と書き込みアクセス権を持っており、組織内のすべてのポリシーについて作成、割り当て、修正、および削除ができます。

    ピープル管理者 デフォルトで、新規に作成した組織のユーザーエントリはその組織のメンバーです。ピープル管理者は、組織のすべてのユーザーエントリに対する読み取りアクセス権と書き込みアクセス権を持っています。なお、このロールは、ロールおよびグループ DN を含む属性に対する読み取りアクセス権と書き込みアクセス権を持っていないため、ロールまたはグループの属性を変更したり、ロールまたはグループからユーザーを消去したりすることができません。

    注 –

    ほかのコンテナは、Access Manager とともに設定して、ユーザーエントリ、グループエントリ、またはほかのコンテナを保持することができます。組織を構成したあとで、作成されたコンテナに管理者ロールを適用するには、デフォルトのコンテナ管理者ロールまたはコンテナヘルプデスク管理者を使用します。

    グループ管理者: グループ作成時に作成されたグループ管理者は、特定グループのすべてのメンバーに対する読み取りアクセス権および書き込みアクセス権を持っており、新しいユーザーの作成、管理しているグループへのユーザーの割り当て、および作成したユーザーの削除を行うことができます。

    グループを作成すると、そのグループを管理するのに必要な権限を持つグループ管理者ロールが自動的に作成されます。このロールはグループのメンバーに自動的には割り当てられません。グループの作成者、またはグループ管理者ロールへのアクセス権を持つ人が割り当てる必要があります。

    最上位レベル管理者: 最上位レベル管理者は、最上位レベル組織のすべてのエントリに対する読み取りアクセス権と書き込みアクセス権を持っています。言い換えれば、最上位レベル管理者ロールには、Access Manager アプリケーション内のすべての設定主体に対する権限があります。

    組織管理者: 組織管理者は、組織のすべてのエントリに対する読み取りアクセス権と書き込みアクセス権を持っています。組織を作成すると、その組織を管理するのに必要な権限を持つ組織管理者ロールが自動的に作成されます。

  3. 「新規動的」ボタンをクリックします。

  4. ロールの名前を入力します。

  5. ロールの詳細を入力します。

  6. 「タイプ」メニューからロールのタイプを選択します。

    ロールは、管理者ロールまたはサービスロールにすることができます。ロールのタイプは、Access Manager コンソール内でどのユーザーをどの位置から始動させるかを決定するために使用します。管理者ロールは、ロールの所有者が管理者権限を持っていることをコンソールに通知します。サービスロールは、その所有者がエンドユーザーであることをコンソールに通知します。

  7. 「アクセス権」メニューから、ロールに適用する権限のデフォルトセットを選択します。これは、組織内のエントリにアクセスする権限です。ここで示すデフォルトの権限は順不同です。権限は次のとおりです。

    アクセス権なし

    ロールにアクセス権が設定されません。

    組織管理者

    組織管理者は設定済み組織のすべてのエントリに対する読み取りアクセス権と書き込みアクセス権を持っています。

    組織ヘルプデスク管理者

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

    組織ポリシー管理者

    組織ポリシー管理者は、組織のすべてのポリシーに対する読み取りアクセス権と書き込みアクセス権を持っています。組織ポリシー管理者は、ピア組織に対する参照ポリシーを作成できません。

    一般に、「アクセス権なし」ACI をサービスロールに割り当て、管理者ロールにはデフォルト ACI のいずれかを割り当てます。

  8. 検索条件を入力します。フィールドは次のとおりです。

    「一致」

    演算子を含めるフィルタのフィールドに、演算子を含めることができます。「すべて」は、指定したすべてのフィールドに一致するユーザーを返します。「いずれか」は、指定したいずれか 1 つのフィールドに一致するユーザーを返します。

    「名」

    名 (ファーストネーム) でユーザーを検索します。

    「ユーザー ID」

    ユーザー ID でユーザーを検索します。

    「姓」

    姓 (ラストネーム) でユーザーを検索します。

    「フルネーム」

    フルネームでユーザーを検索します。

    「ユーザー状態」

    ユーザーの状態 (アクティブまたは非アクティブ) でユーザーを検索します。

  9. 「了解」をクリックして、フィルタ条件を基に、検索を開始します。そのフィルタ条件で定義されたユーザーがロールに自動的に割り当てられます。

Procedureロールからユーザーを消去する

手順

  1. 変更するロールを含む組織に移動します。

    アイデンティティー管理モジュールで「表示」メニューから「組織」を選択し、「ロール」タブを選択します。

  2. 変更するロールを選択します。

  3. 「表示」メニューから「ユーザー」を選択します。

  4. 消去する各ユーザーの横にあるチェックボックスを選択します。

  5. 「アクションの選択」メニューから「ユーザーの消去」をクリックします。

    これで、ロールからユーザーが消去されます。

ポリシーにロールを追加する

Access Manager オブジェクトは、ポリシーの対象定義を通じてポリシーに追加されます。ポリシーを作成または修正するときに、ポリシーの「対象」ページで、組織、ロール、グループ、ユーザーを対象として定義できます。対象を定義すると、ポリシーがオブジェクトに適用されます。詳細は、「ポリシーの管理」を参照してください。

第 11 章 現在のセッション

この章では、Access Manager のセッション管理機能について説明します。セッション管理モジュールでは、ユーザーセッションの情報を確認したり、ユーザーセッションを管理したりする手段を用意しています。さまざまなセッションの時間を追跡するほかに、管理者がセッションを終了することができます。システム管理者は、プラットフォームサーバーリストに表示されたロードバランササーバーを無視してください。

現在のセッションのインタフェース

「現在のセッション」モジュールインタフェースを使用すると、適切な権限を持った管理者は、Access Manager にログインしている任意のユーザーのセッション情報を参照できます。

セッション管理

セッション管理フレームには、現在管理されている Access Manager の名前が表示されます。

セッション情報

セッション情報ウィンドウには、Access Manager に現在ログイン中のすべてのユーザーと、各ユーザーのセッション時間が表示されます。表示フィールドは次のとおりです。

「ユーザー ID」: 現在ログイン中のユーザーのユーザー ID が表示されます。

「残り時間」: ユーザーの再認証までの、セッションの残り時間 (分単位) が表示され ます。

「最大セッション時間」: ユーザーがログインした状態でいられる最大時間 (分単位) が表示されます。この時間が経過すると、セッションが期限切れになり、ユーザーは アクセスするために再度認証を受ける必要があります。

「アイドル時間」: ユーザーがアイドル状態になっている時間 (分単位) が表示されます。

「最大アイドル時間」: ユーザーの再認証が必要になるまでの残りの最大アイドル時間 (分単位) が表示されます。

時間の制限値は、管理者がセッション管理サービスに定義します。

「ユーザー ID」フィールドに入力して「フィルタ」をクリックすれば、特定のユーザーのセッションを表示できます。ワイルドカードも使用できます。

「更新」ボタンをクリックすれば、セッションの表示が更新されます。

セッションの終了

適切な権限を持った管理者は、ユーザーのセッションをいつでも終了させることができます。

Procedureセッションを終了させる

手順

  1. 終了させるユーザーのセッションを選択します。

  2. 「セッションを終了」をクリックします。

第 12 章 パスワードリセットサービス

Access Manager では、Access Manager によって保護されている特定のサービスやアプリケーションにアクセスするためのパスワードをユーザー自身がリセットできるように、パスワードリセットサービスが用意されています。パスワードリセットサービス属性は、最上位レベル管理者が定義します。この属性を使用して、ユーザーを検証するための証明情報 (秘密の質問形式) を制御し、新規または既存のパスワード通知の機構を制御し、不正なユーザーに適用するロックアウト間隔を設定します。

この章は、次の節で構成されています。

パスワードリセットサービスの登録

パスワードリセットサービスは、ユーザーが属しているレルムに対して登録する必要はありません。ユーザーが割り当てられている組織にパスワードリセットサービスが存在しない場合は、「サービス設定」の「パスワードリセットサービス」に定義されている値が継承されます。

Procedure別のレルムに存在するユーザーのパスワードリセットを登録する

手順

  1. そのユーザーのパスワードを登録するレルムに移動します。

  2. レルム名をクリックし、「サービス」タブをクリックします。

    選択したレルムにレルム名が追加されていない場合は、「追加」ボタンをクリックします。

  3. 「パスワードリセット」を選択し、「次へ」をクリックします。

    パスワードリセットサービス属性が表示されます。属性の定義については、オンラインヘルプを参照してください。

  4. 「終了」をクリックします。

パスワードリセットサービスの設定

パスワードリセットサービスの登録が完了したら、管理者権限を持っているユーザーがこのサービスを設定する必要があります。

Procedureサービスを設定する

手順

  1. パスワードリセットサービスが登録されているレルムを選択します。

  2. 「サービス」タブをクリックします。

  3. サービスリストから「パスワードリセット」をクリックします。

  4. 「パスワードリセット」属性が表示され、ここでパスワードリセットサービスの要件を定義できます。パスワードリセットサービスが有効になっていることを確認します (デフォルトでは有効)。少なくとも次の属性を定義する必要があります。

    • ユーザー検証

      • 秘密の質問

      • バインド DN

      • バインドパスワード

        「バインド DN」属性には、パスワードをリセットする権限を持っているユーザー (ヘルプデスク管理者など) を指定する必要があります。Directory Server の制限により、バインド DN が cn=Directory Manager の場合はパスワードリセットは機能しません。

        残りの属性は省略可能です。これらのサービス属性の説明については、オンラインヘルプを参照してください。

      注 –

      Access Manager では、ランダムなパスワードを生成するパスワードリセット Web アプリケーションが自動的にインストールされます。ただし、パスワードの生成や通知を行う独自のプラグインクラスを記述することもできます。このようなプラグインクラスのサンプルについては、次の場所にある Readme.html ファイルを参照してください。

      PasswordGenerator:


      AccessManager-base/SUNWam/samples/console/PasswordGenerator

      NotifyPassword:


      AccessManager-base/SUNWam/samples/console/NotifyPassword

  5. 独自の質問を定義するユーザーには、「個人的な質問を有効」属性を選択します。属性を定義し終えたら、「保存」をクリックします。

パスワードリセットのロックアウト

パスワードリセットサービスには、ユーザーが秘密の質問に正しく回答するまでの回数を制限するために、ロックアウト機能が用意されています。ロックアウト機能は、パスワードリセットサービス属性を使用して設定します。これらのサービス属性の説明については、オンラインヘルプを参照してください。パスワードリセットでは、メモリーロックアウトと物理的なロックアウトの 2 種類がサポートされています。

メモリーロックアウト

これは一時的なロックアウトです。「パスワードリセット失敗のロックアウト持続時間」属性の値が 0 より大きく、「パスワードリセット失敗のロックアウトを有効」属性が有効になっている場合にのみ機能します。ロックアウトされたユーザーは、パスワードリセット Web アプリケーションを使用してもパスワードをリセットできなくなります。「パスワードリセット失敗のロックアウト持続時間」に指定した時間が経過するまで、またはサーバーが再起動されるまで、ロックアウトは持続します。これらのサービス属性の説明については、オンラインヘルプを参照してください。

物理的なロックアウト

メモリーロックアウトより永続的なロックアウトです。「パスワードリセット失敗のロックアウトカウント」属性の値が 0 に設定され、「パスワードリセット失敗のロックアウトを有効」属性が有効になっている場合には、秘密の質問に正しく回答できなかったユーザーのアカウント状態が非アクティブに変更されます。これらのサービス属性の説明については、オンラインヘルプを参照してください。

エンドユーザーから見たパスワードリセット

以降の節では、ユーザーの観点からパスワードリセットサービスについて説明します。

パスワードリセットのカスタマイズ

管理者がパスワードリセットサービスを有効にし、属性を定義したら、ユーザーは Access Manager コンソールにログインして秘密の質問をカスタマイズできます。

Procedureパスワードリセットをカスタマイズする

手順

  1. ユーザー名とパスワードを入力して認証に成功したら、Access Manager コンソールにログインします。

  2. 「ユーザープロファイル」ページで、「パスワードリセットのオプション」を選択します。「質問と回答」画面が表示されます。

  3. 管理者が定義した、このサービスで選択できる質問が表示されます。たとえば、次のような質問が表示されます。

    • ペットの名前は何でしょうか ?

      • 好きなテレビ番組は何でしょうか ?

      • 母親の旧姓は何でしょうか ?

      • よく行くレストランの名前は何でしょうか ?

  4. 秘密の質問を選択します。管理者がこのレルムに定義した最大質問数 (パスワードリセットサービスに定義) まで選択できます。選択した質問への回答を指定します。これらの質問と回答を元に、自分でパスワードをリセットすることができます (次の節を参照)。管理者が「個人的な質問を有効」属性を選択している場合は、自分だけの秘密の質問と回答を入力できるように、テキストフィールドが表示されます。

  5. 「保存」をクリックします。

パスワードを忘れた場合のリセット

パスワードを忘れた場合には、パスワードリセット Web アプリケーションによって新しいパスワードがランダムに生成され、それがユーザーに通知されます。パスワードを忘れた場合の標準的な手順を次に示します。

Procedureパスワードを忘れた場合にリセットする

手順

  1. 管理者から渡された URL を使って、パスワードリセット Web アプリケーションにログインします。次に例を示します。

    http://hostname:port /ampassword (デフォルトのレルムの場合)

    または

    http://hostname: port/deploy_uri /UI/PWResetUserValidation?realm=realmname。realmname はレルムの名前です。

    注 –

    パスワードリセットサービスがサブレルムで有効になっていても、親レルムで無効になっている場合は、次の構文を使ってサービスにアクセスする必要があります。


    http://hostname: port/deploy_uri/UI/PWResetUserValidation?realm=realmname

  2. ユーザー ID を入力します。

  3. パスワードリセットサービスに定義されている質問のうち、パスワードリセット設定をカスタマイズした際にユーザーが選択した質問が表示されます。事前に「ユーザープロファイル」ページにログインしておらず、パスワードリセット設定をカスタマイズしていない場合には、パスワードは生成されません。

    質問に正しく回答すると、新しいパスワードが生成され、電子メールで通知されます。また、回答が正しいかどうかにかかわらず、パスワードをリセットしようとしたことが通知されます。新しいパスワードおよびパスワードをリセットしようとしたことの通知を受け取るには、「ユーザープロファイル」ページに電子メールアドレスを入力しておく必要があります。

パスワードポリシー

安全なパスワードポリシーとして次のような条件をパスワードに適用すると、推測されやすいパスワードによるリスクを最小限に抑えることができます。

Directory Server では、いくつかの方法により、ツリー内の任意のノードにパスワードポリシーを設定できます。詳細は、次の Directory Server のマニュアルを参照してください。

http://docs.sun.com/source/816-6700-10/aci.html#14773

http://docs.sun.com/source/816-6698-10/useracct.html#14386

第 13 章 ログサービス

Sun Java™ System Access Manager 7 2005Q4 には、ユーザーアクティビティー、トラフィックパターン、認証違反などの情報を記録するために、ログサービスが用意されています。また、管理者はデバッグファイルを利用して、インストールの障害追跡を行うことができます。

ログファイル

ログファイルには、ログサービスが監視するイベントが記録されます。管理者は、ログファイルを定期的に確認することをお勧めします。ログファイルのデフォルトのディレクトリは、SPARC システムの場合は /var/opt/SUNWam/logs、Linux システムの場合は /var/opt/sun/identity です。ログサービスのログファイルディレクトリを設定するときには、Access Manager コンソールを使用します。

ログファイルのデフォルトタイプ、記録される情報、ログファイルの形式の詳細については、『Sun Java System Access Manager 7 2005Q4 Technical Overview』の「How the Logging Feature Works」を参照してください。

ログサービスの属性定義については、Access Manager コンソールの「ヘルプ」ボタンをクリックしてオンラインヘルプを参照してください。

Access Manager サービスのログ

サービスログファイルには、アクセスログファイルとエラーログファイルの 2 種類があります。アクセスログファイルには、アクションが実行されたことと正常に実行されたアクションの結果が記録されます。エラーログファイルには、Access Manager サービスで発生したエラーが記録されます。フラットログファイルには、.error または .access という拡張子が付きます。データベース列名の最後には、Oracle データベースの場合は _ERROR または _ACCESS、MySQL データベースの場合は _error または _access が付きます。たとえば、コンソールイベントを記録するフラットファイルログには amConsole.access という名前が付き、コンソールイベントを記録するデータベース列には AMCONSOLE_ACCESS という名前が付きます。以下の節では、ログサービスによって記録されるログファイルについて説明します。

セッションログ

ログサービスでは、次のセッションサービスイベントが記録されます。

セッションログのファイル名は、amSSO で始まります。

コンソールログ

Access Manager コンソールログには、アイデンティティー関連のオブジェクト、ポリシー、およびサービスが作成、削除、および変更されたことが記録されます。たとえば、組織、組織単位、ユーザー、ロール、ポリシー、グループが記録されます。コンソールログには、パスワードなどのユーザー属性が変更されたことや、ロールとグループに対してユーザーが追加または削除されたことも記録されます。また、委託やデータストアのアクティビティーも記録されます。コンソールログのファイル名は、amConsole で始まります。

認証ログ

認証コンポーネントでは、ユーザーのログインおよびログアウトがログとして記録されます。認証ログのファイル名は、amAuthentication で始まります。

連携ログ

連携コンポーネントでは、連携関連のイベントなどがログとして記録されます。たとえば、認証ドメインが作成されたことや、ホストプロバイダが作成されたことが記録されます。連携ログのファイル名は、amFederation で始まります。

ポリシーログ

ポリシーコンポーネントでは、ポリシー関連のイベントなどがログとして記録されます。たとえば、ポリシー管理 (ポリシーの作成、削除、および変更) やポリシー評価が記録されます。ポリシーログのファイル名は、amPolicy で始まります。

エージェントログ

ポリシーエージェントログには、ユーザーがアクセスを許可または拒否されているログリソースに関する例外が記録されます。エージェントログのファイル名は、amAgent で始まります。amAgent ログは、エージェントサーバーだけに存在します。エージェントイベントのログは、Access Manager サーバー上の認証ログに記録されます。この機能の詳細については、ポリシーエージェントのマニュアルを参照してください。

SAML ログ

SAML コンポーネントでは、SAML 関連のイベントなどが記録されます。たとえば、表明およびアーティファクトが作成または削除されたこと、応答および要求の詳細、SOAP エラーなどが記録されます。SAML ログのファイル名は、amSAML で始まります。

amAdmin ログ

コマンド行ログには、コマンド行ツールを使用する操作中に発生したイベントエラーが記録されます。たとえば、サービススキーマがロードされたこと、ポリシーが作成されたこと、ユーザーが削除されたことなどが記録されます。コマンド行ログのファイル名は、amAdmin で始まります。

ログ機能

ログサービスにはいくつかの特殊な機能が用意されていて、追加機能として有効にできます。このような機能として、「セキュリティー保護されたログを有効」、「コマンド行ログ」、および「リモートログ」があります。

セキュリティー保護されたログ

このオプションの機能を追加すると、ログ機能のセキュリティーが強化されます。セキュリティー保護されたログを有効にすると、セキュリティーログに対する未承認の変更や改ざんを検出できます。この機能を使用するために、特にコーディングする必要はありません。セキュリティー保護されたログには、システム管理者が事前に登録した証明書が必要です。この MAC (Manifest Analysis and Certification) は、すべてのログレコードについて生成および格納されます。また、特別な「署名」ログレコードが定期的に挿入されます。このログレコードは、その時点までに書き込まれたログの内容に対する署名となります。これらの 2 つのレコードによって、ログが改ざんされていないことが保証されます。

Procedureセキュリティー保護されたログを有効にする

手順

  1. Logger という名前の証明書を作成し、Access Manager を実行する配備コンテナにインストールします。配備コンテナの詳細については、マニュアルを参照してください。

  2. Access Manager コンソールを使用して「ログサービス」設定の「セキュリティー保護されたログ」を有効にし、変更を保存します。管理者は、「ログサービス」のその他の属性のデフォルト値を変更することもできます。

    ログディレクトリがデフォルトのディレクトリ (/var/opt/SUMWam/logs) から変更されている場合は、アクセス権が 0700 に設定されていることを確認してください。このディレクトリが存在しない場合には、ログサービスによって作成されますが、そのアクセス権は 0755 に設定されます。

    また、デフォルトではないログディレクトリを指定した場合は、Web コンテナの server.policy ファイルで次のパラメータをその 新しいディレクトリに変更する必要があります。

    permission java.io.FilePermission “/var/opt/SUNWam/logs/*”,”delete,write”

  3. AccessManager-base/SUNWam/config ディレクトリに証明書データベースパスワードを含むファイルを作成し、.wtpass という名前を付けます。

    注 –

    ファイル名とそのパスは、AMConfig.properties ファイルに設定できます。詳細については、付録 A 「AMConfig.properties ファイル」の「証明書データベース」を参照してください。

    セキュリティー上の理由から、このファイルへの読み取りアクセス権を持つ管理者だけが配備コンテナを使用できるようにしてください。

  4. サーバーを再起動します。

    このとき、セキュリティー保護されたログディレクトリをクリアすることをお勧めします。セキュリティー保護されたログを開始したときに、誤解を招きやすい検証エラーが /var/opt/SUNWam/debug/amLog ファイルに書き込まれることがあるからです。

    セキュリティーログに対する未承認の変更や改ざんを検出するには、検証プロセスによって /var/opt/SUNWam/debug/amLog に書き込まれたエラーメッセージを探してください。改ざんを手動で確認する場合は、VerifyArchive ユーティリティーを実行します。詳細については、第 19 章「VerifyArchive コマンド行ツール」を参照してください。

コマンド行ログ

amadmin コマンド行ツールを使用して、Directory Server のアイデンティティーオブジェクト (組織、ユーザー、ロールなど) を作成、変更、および削除することができます。このツールを使用して、サービステンプレートをロード、作成、および登録することもできます。-t オプションを指定すれば、ログサービスでこれらのアクションを記録できます。AMConfig.properties の com.iplanet.am.logstatus プロパティーが有効 (ACTIVE) になっている場合は、ログレコードが作成されます。このプロパティーはデフォルトでは有効になっています。コマンド行ログのファイル名は、amAdmin で始まります。詳細については、第 14 章「amadmin コマンド行ツール」を参照してください。

ログプロパティー

AMConfig.properties ファイルには、ログ出力を制御するプロパティーが入っています。

com.iplanet.am.logstatus=ACTIVE

このプロパティーを使用して、ログの有効または無効を切り替えます。デフォルトでは ACTIVE になっています。

iplanet-am-logging.service.level= level

service にはデバッグログを記録するサービス名を指定します。この名前はそのままデバッグファイルの名前になります。level は java.util.logging.Level の値のいずれかであり、記録されるログの詳細レベルを表します。指定できるレベルは、SEVERE、WARNING、INFO、CONFIG、FINE、FINER、および FINEST です。ほとんどのサービスでは、INFO レベルより詳細なログは記録されません。

リモートログ

Access Manager では、リモートログがサポートされます。これにより、Access Manager SDK がインストールされたホストを使用するクライアントアプリケーションが、リモートマシン上に配備された Access Manager インスタンス上にログレコードを作成できるようになります。リモートログは、次のいずれかの場合に開始されます。

  1. ある Access Manager インスタンスのネームサービスのログ URL にリモートの Access Manager インスタンスの URL が指定されていて、2 つのインスタンスの間に信頼関係が設定されている場合に、リモート Access Manager インスタンスにログが記録されます。

  2. Access Manager SDK がリモート Access Manager インスタンスにインストールされていて、SDK サーバーで実行されているクライアント (または Java クラス) がログ API を使用している場合に、リモート Access Manager マシンにログが記録されます。

  3. ログ API が Access Manager エージェントで使用されているとき。

Procedureリモートログを有効にする

手順

  1. Sun Java System Web Server を使用する場合は、server.xml 設定ファイルに次の環境変数を設定する必要があります。

    • java.util.logging.manager=com.sun.identity.log.LogManager

    • java.util.logging.config.file=/AccessManager-base /SUNwam/lib/LogConfig.properties

    • 使用する Java™ 2 Platform, Standard Edition が 1.4 以降である場合にこれを実現するには、コマンド行から次の呼び出しを行います。

      java -cp /AccessManager-base /SUNWam/lib/am_logging.jar:/AccessManager-base /SUNWam/lib/xercesImpl.jar:/AccessManager-base /SUNWam/lib/xmlParserAPIs.jar:/AccessManager-base /SUNWam/lib/jaas.jar:/AccessManager-base /SUNWam/lib/xmlParserAPIs.jar:/AccessManager-base /SUNWam/lib/servlet.jar:/AccessManager-base /SUNWam/locale:/AccessManager-base/SUNWam/lib/am_services.jar:/ AccessManager-base/SUNWam/lib/am_sdk.jar:/ AccessManager-base/SUNWam/lib/jss311.jar:/ AccessManager-base/SUNWam/lib:.

      -Djava.util.logging.manager=com.sun.identity.log.LogManager

      -Djava.util.logging.config.file=/AccessManager-base /SUNwam/lib/LogConfig.properties <logTestClass>

    • 使用する Java 2 Platform, Standard Edition が 1.4 よりも前のものである場合にこれを実現するには、コマンド行から次の呼び出しを行います。

      java -Xbootclasspath/a:/AccessManager-base /SUNWam/lib/jdk_logging.jar -cp /AccessManager-base /SUNWam/lib/am_logging.jar:/AccessManager-base /SUNWam/lib/xercesImpl.jar:/AccessManager-base /SUNWam/lib/xmlParserAPIs.jar:/AccessManager-base /SUNWam/lib/jaas.jar:/AccessManager-base /SUNWam/lib/xmlParserAPIs.jar:/AccessManager-base /SUNWam/lib/servlet.jar:/AccessManager-base /SUNWam/locale:/AccessManager-base/SUNWam/lib/am_services.jar:/ AccessManager-base/SUNWam/lib/am_sdk.jar:/ AccessManager-base/SUNWam/lib/jss311.jar:/ AccessManager-base/SUNWam/lib:.

      -Djava.util.logging.manager=com.sun.identity.log.LogManager

      -Djava.util.logging.config.file=/AccessManager-base /SUNwam/lib/LogConfig.properties <logTestClass>

  2. AccessManager-base/SUNWam/lib の LogConfig.properties に次のパラメータが設定されていることを確認します。

    • iplanet-am-logging-remote-handler=com.sun.identity.

      log.handlers.RemoteHandler

    • iplanet-am-logging-remote-formatter=com.sun.

      identity.log.handlers.RemoteFormatter

    • iplanet-am-logging-remote-buffer-size=1

      リモートログでは、ログレコード数に基づいてバッファー機能がサポートされます。この値には、レコード数でログバッファーサイズを定義します。バッファーがいっぱいになったら、バッファーに保管されたすべてのレコードがサーバーにフラッシュされます。

    • iplanet-am-logging-buffer-time-in-seconds=3600

      この値には、ログバッファーとクリーナのスレッドを呼び出すときの、タイムアウト期間を定義します。

    • iplanet-am-logging-time-buffering-status=OFF

      この値には、ログバッファー (およびバッファークリーナのスレッド) を有効にするかどうかを定義します。デフォルトでは、この機能は無効になっています。

    注 –

    ログファイルが空の場合、セキュリティー保護されたログに「verification failure」と表示される可能性があります。これは、作成されたファイルの数がアーカイブサイズに等しい場合、セキュリティー保護されたログが、このセットからアーカイブし、再起動するからです。ほとんどの場合、このエラーは無視してもかまいません。レコード数がアーカイブサイズに等しくなると、このエラーは表示されなくなります。

エラーログとアクセスログ

Access Manager には 2 種類のログファイルが存在します。アクセスログファイルとエラーログファイルです。

アクセスログファイルには、Access Manager 配備に関する一般的な監査情報が記録されます。ログには、認証の成功など、特定のイベントに対する単一のレコードが含まれる場合があります。またその同じイベントに対する複数のレコードが含まれる場合もあります。たとえば、管理者がコンソールを使って特定の属性の値を変更した場合、ログサービスは、その変更の試みを 1 つのレコードとしてログに記録します。ログサービスはさらに、その変更の実行結果も、2 番目のレコードとしてログに記録します。

エラーログファイルには、アプリケーション内で発生したエラーが記録されます。ある処理のエラーはエラーログに記録されますが、その処理が試みられたことはアクセスログファイルに記録されます。

フラットログファイルには、.error、.access のいずれかの拡張子が付けられます。データベースの列名は、_ERROR、_ACCESS のいずれかで終わります。たとえば、コンソールイベントのログを記録するフラットファイルの名前が amConsole.access である場合、その同じイベントのログを記録するデータベース列の名前は、AMCONSOLE_ACCESS または amConsole_access になります。

次の表では、各 Access Manager コンポーネントが生成するログファイルについて簡単に説明します。

表 13–1 Access Manager コンポーネントのログ

コンポーネント 

ログファイル名のプレフィックス 

ログに記録される情報 

セッション 

amSSO

ログイン時刻、ログアウト時刻、タイムアウト制限などのセッション管理属性値。 

管理コンソール 

amConsole

アイデンティティー関連のオブジェクト、レルム、ポリシーの作成、削除、変更など、管理コンソール経由で実行されるユーザーアクション。 

認証 

amAuthentication

ユーザーのログインとログアウト。 

アイデンティティー連携 

amFederation

認証ドメインの作成やホストプロバイダの作成など、連携関連のイベント。連携ログのファイル名は、amFederation で始まります。

承認 (ポリシー) 

amPolicy

ポリシーの作成、削除、変更やポリシー評価など、ポリシー関連のイベント。 

ポリシーエージェント 

amAgent

特定のユーザーからのアクセスが許可または拒否されたリソースに関する例外。amAgent ログは、ポリシーエージェントがインストールされたサーバー上に存在します。エージェントイベントのログは、Access Manager マシン上の認証ログに記録されます。

SAML 

amSAML

表明、アーティファクトの作成または削除、応答や要求の詳細、SOAP エラーなど、SAML 関連のイベント。 

コマンド行 

amAdmin

コマンド行ツールによる操作中に発生したイベントエラー。例: サービススキーマの読み込み、ポリシーの作成、ユーザーの削除。 

Access Manager のログファイルの一覧と説明については、付録 C 「ログファイルリファレンス」を参照してください。

デバッグファイル

デバッグファイルは、ログサービスの機能ではありません。デバッグファイルは、ログ API とは別の API を使用して記録されます。デバッグファイルは、/var/opt/SUNWam/debug に格納されます。この場所は、デバッグ情報のレベルと一緒に、AccessManager-base/SUNWam/lib/ ディレクトリの AMConfig.properties ファイルで設定できます。デバッグプロパティーの詳細については、付録 A 「AMConfig.properties ファイル」 を参照してください。

デバッグレベル

デバッグファイルに記録できる情報には、いくつかのレベルがあります。デバッグレベルは、AMConfig.properties の com.iplanet.services.debug.level プロパティーを使用して設定します。

  1. off—デバッグ情報は記録されません。

  2. error—このレベルは本稼働環境で使用されます。運用者は、本稼働環境ではデバッグファイルにエラーが記録されることのないように努めてください。

  3. warning—現在、このレベルを使用することは推奨されていません。

  4. message—コードトレースを使用するときに発生する可能性のある問題を警告します。ほとんどの Access Manager モジュールでは、このレベルを使用してデバッグメッセージが送信されます。

    注 –

    warning および message レベルは、本稼働環境では使用してはいけません。パフォーマンスが大きく低下し、大量のデバッグメッセージが送信されます。

デバッグ出力ファイル

デバッグファイルは、モジュールがデバッグファイルに書き込むときに作成されます。したがって、デフォルトの「error」モードでは、デバッグファイルは生成されません。デバッグレベルを「message」に設定した状態で基本的なログインを実行すると、次のデバッグファイルが作成されます。

もっとも頻繁に使用されるファイルは、amSDK、amProfile、および認証に関連するすべてのファイルです。記録される情報には、日付、時刻、およびメッセージタイプ (Error、Warning、Message) などがあります。

デバッグファイルの使用

デバッグレベルは、デフォルトでは「error」に設定されています。デバッグファイルは、管理者が次の作業を行っているときに役立ちます。

デバッグファイルは、今後提供する予定の障害追跡ガイドと一緒に使用することをお勧めします。たとえば、SSL に障害が発生したときには、「message」レベルのデバッグを有効にして、amJSS デバッグファイルで証明書固有のエラーを探してみるとよいでしょう。

複数の Access Manager インスタンスとデバッグファイル

Access Manager には、多数のサーバーインスタンスを設定するときに使用できるように、ammultiserverinstall スクリプトが用意されています。複数のサーバーインスタンスがそれぞれ異なるデバッグディレクトリを使用するように設定されている場合、各インスタンスに対してそれぞれのデバッグディレクトリへの読み取りアクセス権と書き込みアクセス権を割り当てる必要があります。