| Oracle Access Managerアクセス管理ガイド 10g（10.1.4.3） B55477-01 |
|
 戻る |
 次へ |
この章では、アクセス・システム・コンソールで使用できるアクセス・システムの追加の構成および管理機能について説明します。内容は次のとおりです。
アクセス・システムの管理の詳細は、次を参照してください。
Oracle Access Managerを、『Oracle Access Managerインストレーション・ガイド』の手順に従ってインストールおよび設定しておく必要があります。『Oracle Access Manager概要』を一読し、その他のマニュアルに記載されていないOracle Access Managerの概要を確認してください。また、『Oracle Access Manager IDおよび共通管理ガイド』をよく理解しておいてください。このマニュアルには、アクセス・システムのアプリケーションおよびインストールの簡単な説明、アクセス・システムの構成および管理、ならびに共通の機能、構成および管理が説明されています。
アクセス・システム・コンソールの「システム構成」機能を使用したサーバー設定の表示および管理者の構成については、このマニュアルの前半の章で説明しています。ここでは、その説明は繰り返しません。
この項の残りの内容は次のとおりです。
アクセス・システム・コンソールの「アクセス・システム構成」タブでは、次に示すような様々な機能を使用できます。参照先が明記されていないアクセス・システム構成の機能は、このマニュアルの他の章で説明しています。
アクセス・サーバー・クラスタ: 既存のアクセス・サーバー・クラスタの表示、新規アクセス・サーバー・クラスタの追加と既存のアクセス・サーバー・クラスタの変更、ならびにアクセス・サーバー・クラスタの構成と削除を行います。
アクセス・ゲート構成: 既存のアクセス・ゲートの表示、新規アクセス・ゲートの追加と既存のアクセス・ゲートの変更、ならびにアクセス・ゲートの構成と削除を行います。
アクセス・サーバー構成: 既存のアクセス・サーバーの表示、新規アクセス・サーバーの追加と既存のアクセス・サーバーの変更、キャッシュおよび監査設定の構成を行います。
認証管理: 認証ルールを構成します。
認可管理: 認可ルールを構成します。
ユーザー・アクセス構成: この章の「ユーザー・アクセスの構成」の手順に従って、失効したユーザーをリストし、ユーザー・キャッシュをフラッシュします。
共通情報の構成: 暗号鍵を生成してCookieを暗号化し（この章で説明）、マスター監査ルールを構成し、リソース・タイプ定義を管理し、パスワード・ポリシー・キャッシュをフラッシュし（この章で説明）、重複アクション・ヘッダーを処理します。この章で説明する項目の詳細は、次を参照してください。
ホスト識別子: ホスト識別子を構成します。
アクセス・システム・コンソールには、システム管理操作を実行するためのオプションが複数用意されています。この章では、これらのオプションについて説明します。
診断: 接続情報を含むアクセス・サーバーの詳細を表示します（「診断の実行」を参照）。
レポートの管理: ユーザー・アクセス権限レポートを作成、表示、変更および実行できます（「ユーザー・アクセス権限レポートの管理」を参照）。
同期レコードの管理: 同期レコードをアーカイブまたはパージできます（「同期レコードの管理」を参照）。
|
関連項目: 複数のディレクトリ・サーバーに書込みを行う複数のアクセス・サーバーが存在する場合において、同期レコードの破損を検出してリカバリするためのコマンドライン・ツールを使用する方法については、「複数のディレクトリ・サーバーを含む環境での破損した同期レコードの検出とリストア」を参照してください。 |
診断、監査、レポートおよびロギングの詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。
アクセス・システム・コンソールの「アクセス・システム構成」タブで使用可能な「ユーザー・アクセス構成」機能を使用すると、失効したユーザーを管理し、キャッシュからユーザー・データをフラッシュできます。この項では、次の項目について説明します。
|
注意: ユーザー・アクセスを構成するには、マスター・アクセス管理者または適切な権限を持つ委任アクセス管理者である必要があります。 |
キャッシュの詳細は、「パスワード・ポリシー・キャッシュのフラッシュ」および「アクセス・システムのキャッシュの自動フラッシュ」を参照してください。『Oracle Access Managerデプロイメント・ガイド』も参照してください。
いずれのリソースへのアクセスも禁止されているユーザーのリストを作成および変更できます。このリストは、リソースへのユーザー・アクセスを制御する他の任意のポリシーより優先されます。いったん失効したユーザーがブラウザをリフレッシュしようとした場合や、保護されている別のリソースに移動しようとした場合、このユーザーのアクセスは拒否されます。失効したユーザーがログインしようとすると、次のエラーが表示されます。
ログインで使用される資格証明(userid=xxxxxxxx password=(omitted) Resource=/access/oblix RequesterIP= nn.nn.nnn.nn HostTarget=http://hostname:port Operation=GET)に対応するユーザーは、アクセス・システム管理者によって取り消されました。
アクセス・システム・コンソール、「アクセス・システム構成」をクリックし、「ユーザー・アクセス構成」をクリックします。
「ユーザー・アクセス構成」画面が表示されます。
「失効したユーザー」をクリックします。
失効したユーザーの名前が表示された「ユーザー失効リストの変更」画面が表示されます。失効したユーザーが存在しない場合、「ユーザー失効リストの構成」画面が表示されます。失効したユーザーが存在する場合、「失効したユーザー」リンクの下にその名前が表示されます。
「ユーザーの選択」をクリックし、セレクタ機能（「ユーザーの選択」ボタン）を使用し、失効したユーザーを追加または削除します。
セレクタの使用方法の詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。
変更内容を保存する場合は、「保存」をクリックします。または、保存しないで終了する場合は、「取消」をクリックします。
キャッシュからユーザー・データをフラッシュするには、マスター・アクセス管理者である必要があります。
ユーザー・キャッシュをフラッシュすると、ユーザーのアクセス権での変更が自動的に更新されます。この場合、選択したユーザーに関する情報は、アクセス・ゲートおよびアクセス・サーバーのキャッシュから削除されます。たとえば、属性を表示または変更するためのユーザー権限を変更した後、このユーザーの情報をフラッシュする場合があります。これは、ユーザーがリソースに今すぐアクセスする必要がある場合に役立ちます。
セレクタの使用方法の詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。
アクセス・システム・コンソールで、「アクセス・システム構成」→「ユーザー・アクセス構成」→「ユーザー・キャッシュのフラッシュ」の順に選択します。
「指定されたユーザーのキャッシュされた全情報のフラッシュ」ページが表示されます。
次の手順を実行し、個人を識別して、すべてのキャッシュから情報をフラッシュするユーザーのリストに追加します。
最初の2つのリストから、検索基準を選択します。次に例を示します。
フルネーム
次を含む
戻される名前リストを狭めるため、空のフィールドに入力してから、「実行」をクリックします。次に例を示します。
sch
結果の名前リストで、それぞれの名前の横にある「追加」ボタンをクリックして、キャッシュ・フラッシュ操作に含めます。
選択して追加したユーザーの名前が、ページの右側に表示されます。
手順a〜cを繰り返して、リストの構築を終了します。
目的のリストが完成したら、「完了」をクリックします。
「指定されたユーザーのキャッシュされた全情報のフラッシュ」ページが、選択された名前のリストとともに表示されます。
「キャッシュのフラッシュ」ボタンをクリックします（または「取消」をクリックして操作を終了します）。
決定の確認を求められます。「OK」をクリックすると、ページから名前がクリアされ、これらのユーザーに関する情報がアクセス・ゲートおよびアクセス・サーバーのキャッシュからフラッシュされます。
「OK」をクリックして名前をクリアします（または「取消」をクリックして消去せずに終了します）。
「アクセス・システム構成」の「共通情報の構成」タブで使用可能な「共有シークレット」機能を使用して、アクセス・ゲートからブラウザに送信されるシングル・サインオンCookieを暗号化するための鍵を生成します。
|
注意: 共有シークレット鍵を作成するには、マスター・アクセス管理者である必要があります。Oracle Access Managerのインストール後はできるだけ早く暗号鍵を生成する必要があります。生成しない場合、セキュリティの低いデフォルトの鍵が使用されます。 |
AESは、Oracle Access Manager 7.0に導入された新しい暗号スキームです。Oracle Access Manager 10.1.4の新規インストールを使用している場合、AESがデフォルトの暗号スキームです。Oracle Access Manager 10.1.4ではRC6暗号スキームの使用は推奨されておらず、将来のリリースではサポートされなくなる予定です。
旧バージョンからOracle Access Manager 10.1.4にアップグレードした場合、この旧式の暗号化スキームは保持されます。『Oracle Access Managerアップグレード・ガイド』で説明しているように、古いWebGateと新しいWebGateは共存できます。
バージョン5.xとバージョン7.xのWebGateが共存している場合、RC4を暗号化スキームとして使用します。
バージョン6.xとバージョン7.xのWebGateが共存している場合、RC6を暗号化スキームとして使用します。
AES暗号化スキームを使用するのは、すべてのWebGateおよびアクセス・サーバーがOracle Access Managerバージョン7.0以上にアップグレードされている場合のみにしてください。
|
注意: セッション・タイムアウトより頻繁に共有シークレットが生成される場合、ユーザーのCookieは、3世代以上旧式の共有シークレットを使用して暗号化されている可能性があります。この場合、Cookieは拒否され、ユーザーは再認証するよう強制されます。 |
アクセス・システム・コンソールで、「アクセス・システム構成」→「共通情報の構成」の順にクリックします。
「共通情報の構成」画面が表示されます。
画面上部にある「共有シークレット」タブをクリックします。
「共有シークレットの生成」画面が表示されます。
「変更」をクリックします。
これにより、「共有シークレットの生成」ページで様々な暗号を選択できるようになります。
共有シークレットに適した暗号オプションを選択します（AES暗号を使用することをお薦めします）。
「シークレットの生成」を1回のみクリックします。
新しい暗号鍵が生成され、システム上のアクセス・サーバーごとに配布されます。エンドユーザーに対するサービスを妨げることなく、新しい鍵が既存の鍵に取ってかわります。再認証が行われるのは、セッションがタイムアウトした場合のみです。このプロセスは、グランドファザリング方式と呼ばれます。「シークレットの生成」を複数回クリックすると、IDの共有暗号鍵がポリシー・マネージャの鍵と同期しなくなります。
操作が成功したことを示すメッセージが表示されます。
「パスワード・ポリシー・キャッシュのフラッシュ」機能（「アクセス・システム構成」タブの「共通情報の構成」）を使用して、アクセス・サーバーのキャッシュからすべてのパスワード・ポリシーをフラッシュします。パスワード・ポリシー・キャッシュをフラッシュすると、既存のパスワード・ポリシーが削除され、新しく構成されたポリシーが追加されます。
パスワード・ポリシー・キャッシュをフラッシュすると、既存のパスワード・ポリシーが削除されて新しく構成されたポリシーが追加され、アクセス・サーバー内にキャッシュされたパスワード・ポリシーが自動的に更新されます。これは、パスワード・ポリシーをアイデンティティ・システムから変更して、アクセス・サーバーがパスワード・ポリシーを評価するときに変更が反映されるようにする場合に役立ちます。
リダイレクトURLを構成している場合は、「パスワード・ポリシー・キャッシュのフラッシュ」タブから、パスワード・ポリシー強制に使用されるすべてのリダイレクトURLをフラッシュすることもできます。リダイレクトURLをフラッシュすると、パスワード・ポリシー管理のリダイレクトURLは、アイデンティティ・システムで更新されるたびに自動的に更新されます。アクセス・システムでこの変更を認識するためには、管理者がキャッシュをフラッシュする必要があります。
また、指定したロスト・パスワード管理ポリシーのキャッシュされたすべての情報をフラッシュすることもできます。「パスワード・ポリシー・キャッシュのフラッシュ」タブをクリックすると、「指定したロスト・パスワード管理ポリシーのキャッシュされたすべての情報をフラッシュ」と記載されたセクションが有効になります。キャッシュからフラッシュするロスト・パスワード・ポリシーを、リストから選択できます。ポリシーが1つもない場合は、画面にその旨が表示されます。これは、ロスト・パスワード・ポリシーをアイデンティティ・システムから変更して、アクセス・サーバーがパスワード・ポリシーを評価するときに変更が反映されるようにする場合に役立ちます。
|
注意: パスワード・ポリシー・キャッシュをフラッシュするには、マスター・アクセス管理者である必要があります。また、このキャッシュを自動的に更新することもできます。アクセス・サーバーのキャッシュの更新の詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。 |
パスワード・ポリシー・キャッシュとリダイレクトURLをフラッシュする手順
「アクセス・システム・コンソール」→「アクセス・システム構成」タブの順にクリックし、「共通情報の構成」を選択し、「パスワード・ポリシー・キャッシュのフラッシュ」タブをクリックします。
指定したパスワード・ポリシーのキャッシュされたすべての情報をフラッシュ: 次の手順を実行します。
ラベル（「指定したパスワード・ポリシーのキャッシュされたすべての情報をフラッシュ」）の下のリストから、キャッシュからフラッシュするポリシーの名前を選択します。
「キャッシュのフラッシュ」ボタンをクリックします。
「OK」をクリックして決定を確認します。
パスワード・ポリシーの強制に使用されるすべてのリダイレクトURLをフラッシュします: 「リダイレクトURLのフラッシュ」ボタンをクリックします。
指定したロスト・パスワード管理ポリシーのキャッシュされたすべての情報をフラッシュ: 次の手順を実行します。
ラベル（「指定したパスワード・ポリシーのキャッシュされたすべての情報をフラッシュ」）の下のリストから、キャッシュからフラッシュするポリシーの名前を選択します。
「キャッシュのフラッシュ」ボタンをクリックします。
「OK」をクリックして決定を確認します。
アクセス・システム・コンソールの「システム管理」ページの診断アイテムを使用して、Oracle Access Managerシステムのすべてのアクセス・サーバーまたは選択したアクセス・サーバーに対して診断を実行します。
アクセス・システム・コンソールで、「システム管理」を選択し、「診断」をクリックします。
診断を実行するアクセス・サーバーを選択するよう求められます。
目的のオプションを選択します。
すべてのアクセス・サーバー: 「すべてのアクセス・サーバー」を選択し、「実行」ボタンをクリックします。
特定のアクセス・サーバー: [Ctrl]キーを押したまま、詳細を表示するサーバーの名前をクリックし、「実行」ボタンをクリックします。
アクセス・システム・コンソールの「システム管理」ページにある「レポートの管理」機能を使用して、ユーザー・アクセス権限レポートを管理します。
各アクセス・サーバーは、処理対象のリソース・リクエストに関する監査情報を収集できます。既存のレポートのリストは、「レポートの管理」ページに表示できます。また、次の操作を実行できます。
監査およびレポートの詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。
特定のユーザーが特定の時間に特定のリソースにアクセスできるかどうかを検証するためのユーザー・アクセス権限レポートを作成できます。次の手順で、これらのフィールドへの入力について説明します。
アクセス・システム・コンソールで、「システム管理」を選択し、「レポートの管理」をクリックします。
「ユーザー・アクセス権限レポートの管理」ページで、「追加」ボタンをクリックします。
次のように情報を入力します。
レポート名: 監査レポートを示すわかりやすい名前を選択します。
説明: 必要に応じて、レポートの説明を入力できます。
アクセス・サーバー: レポートの情報を収集するアクセス・サーバーの名前。
結果ストレージ: 監査データをディスク・ファイルとデータベースのどちらに保存するかを示します。
ファイルに保存: このオプションの横にあるボックスを選択し、完全修飾されたパスおよびファイル名を「ファイル名」フィールドで指定します。
データベースに保存: 特定のOracle Access Manager構成の詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。データベースのサポートの詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。
リソースのリスト: このオプションの横にある「追加」ボタンをクリックし、次のスクリーン・ショットに示すように、「リソース・ルールの追加」ページを表示します。
|
注意: レポートには複数のリソースを追加できます。各リソースに関するアクセス情報は、レポートで返されます。 |
「リソース・ルールの追加」ページで、次の項目を指定してルールを作成し、「保存」をクリックして「新規レポートの追加」ページに戻ります。
URL: レポートに追加するターゲット・リソースのURL。
リソース・タイプ: サポートされている選択肢はHTTPとEJBです。
リソース操作: レポートに含めることができる操作の横にチェック・ボックスが表示されます。特定のリソースに対して特定のユーザーが特定の時間に使用可能な操作は、Oracle Access Managerによって決定されます。
「新規レポートの追加」ページで、続けて次の情報を指定します。
開始IPアドレス: オプション。アクセスをテストするクライアント・ブラウザをホストしているコンピュータのIPアドレス。このパラメータはオプションです。
アクセスの日付/時間: ボタンを選択し、現在のレポートによって指定されたユーザーが特定のリソースを使用できる日付/時間を決定します。
任意: 少なくともいずれかの時点でリソースを使用可能にするかどうかがOracle Access Managerによって決定されます。
特定の日時: 特定の時間を指定することにより、この時間にアクセスを許可するかどうかをOracle Access Managerが決定できるようにします。
次のユーザーのアクセス権をチェック: ディレクトリ内のすべてのユーザーまたは指定するユーザーのみのアクセス権をチェックするかどうかを指定します。
選択されたユーザー: 「セレクタ」ページを使用して、特定のユーザーを検索および追加できます。「選択されたユーザー」を選択し、「ユーザーの選択」ボタンをクリックし、検索基準を指定して、特定のユーザーを追加します。
すべてのユーザー: ディレクトリ内のすべてのユーザーのアクセス権をチェックします。
「レポートの追加」ページで「保存」をクリックしてレポートの仕様を保存し、「ユーザー・アクセス権限レポートの管理」ページでリンクとして指定した名前を表示します。
「ユーザー・アクセス権限レポートの管理」ページ（アクセス・システム・コンソールで、「システム管理」を選択し、「レポートの管理」をクリック）では、次のような様々な操作を実行できます。
追加: 新しいレポートを作成します（「レポートの追加」参照）。
削除: 「ユーザー・アクセス権限レポートの管理」ページのレポート名の横にあるボックスを選択し、「削除」ボタンをクリックしてレポートを削除します。レポートを削除するかどうかを尋ねられた場合は確定します。
|
注意: 複数のレポートを同時に削除または実行する場合、操作対象のすべてのボックスを選択し、適切なボタンをクリックします。 |
実行: 「ユーザー・アクセス権限レポートの管理」ページのレポート名の横にあるボックスを選択し、「実行」ボタンをクリックします。レポートを実行するかどうかを尋ねられた場合は確定します。
リフレッシュ: 「リフレッシュ」ボタンをクリックし、「ユーザー・アクセス権限レポートの管理」ページのレポートのリストを更新します。
変更: 「ユーザー・アクセス権限レポートの管理」ページのリンクをクリックして既存のレポートの管理ページを表示し、既存の静的監査レポートのパラメータを変更します。各オプションの詳細は、「レポートの追加」を参照してください。
この項の内容は次のとおりです。
Oracle Access Managerデプロイには、アイデンティティ・サーバー、アクセス・サーバーおよびポリシー・マネージャの複数のインスタンスを含めることができます。ユーザー・プロファイルまたはポリシー情報は、アイデンティティ・システム・コンソールまたはポリシー・マネージャを使用して変更できます。アクセス・サーバーの構成変更は、アクセス・システム・コンソールを使用して行います。システム全体で統合および統一されたビューを確保し、動作の一貫性を確実なものにするため、すべての変更はディレクトリ・サーバーに書き込まれ、すべてのコンポーネントに伝播される必要があります。
ポリシー情報ユーザー・プロファイル情報、ポリシー情報または構成詳細を変更するたびに、対応するグローバルな同期レコードが生成されます。同期レコードは、すべてのコンポーネント間で共有できるように、ディレクトリ・サーバーに格納されます。
次に、ポリシーのグローバルな同期レコードの例を示します。
obSyncRequestNo=<GSN>, cn=PSCMgmt,obapp=PSC,o=Oblix,<config tree>
ここで、GSNは、アクセス・サーバーがポリシー情報やユーザー情報に対する変更を追跡するために使用するグローバルな同期番号です。この番号を使用して、これらの変更をディレクトリ・サーバー内のデータと同期させ、デプロイ内のすべてのインスタンスに対して同じ情報でディレクトリ・サーバーを更新します。
ユーザー・プロファイルの同期レコードは、次の例のようになります。これはcnが異なる点を除いては、ポリシーの同期レコードと同じです。
obSyncRequestNo=<GSN>, cn=UserMgmt,obapp=PSC,o=Oblix,<config tree>
アイデンティティ・システム・コンソールから行ったユーザー・プロファイルの変更は、1つのアイデンティティ・サーバーに取り込まれます。結果のユーザー関連の同期レコードは、次の例のようになります。
Dn: obSyncRequestNo=14,cn=UserMgmt,obapp=PSC,o=Oblix,o=company,c=us
1> obSyncRequestNo: 2;
1> obCompID: 20080526T17521689728;
1> obSyncChangeType: 2;
1> obSyncRequestType: 3;
1> obSyncTime: 1211804638;
2> objectClass: top; oblixSyncRecord;
1> obver: 10.1.4.0;
同期レコードの各行には、変更に関する様々な情報が含まれています。これには、同期レコード番号（obSyncRequestNo）、この同期リクエスト元のコンポーネント（obCompID）、変更のタイプ（この変更が追加、更新、削除のいずれであるかを示すObSyncChangeType）、リクエスト・タイプ値（obSyncRequestType）、変更の時刻（obSyncTime）、オブジェクト・クラス（objectClass: top; oblixSyncRecord）およびOracle Access Managerリリースのバージョン（obver: 10.1.4.0）があります。ポリシー識別子（obCompSDID）は、ユーザー関連の同期レコードには含まれません。これらの属性と値の詳細は、『Oracle Access Managerスキーマ詳細』を参照してください。
同期レコードは時間が経つにつれて蓄積されていきます。特定の日付より前のすべてのレコードを定期的にアーカイブまたはパージすることにより、ディレクトリ・サーバー上でこれらのレコードが占めるスペースを管理できます。
|
注意: Active Directoryでは、アクセス・サーバーのglobalparams.xmlファイル内にあるUserMgmtNodeEnabled（False）の値を使用して、ユーザー・プロファイルの変更を監視することができます。詳細は、「Active Directoryを使用したキャッシュ・フラッシュの問題」を参照してください。 |
追加情報については、次の項を参照してください。
同期レコードをアーカイブするには、マスター・アクセス管理者である必要があります。
同期レコードをアーカイブする場合、情報はIdifファイルに格納されます。通常、ファイルにはnnn.ldifという名前が付いています。ここでnnnは、GSN同期レコード形式（syncrecordsxxxxxxxxxx.YYYYMMDD.HHMMSS）で表される一連の数値です。この形式では、一意の同期レコード番号が割り当てられます。xxxxxxxxxxxは、システムによって割り当てられる一意の番号です。時刻は、協定世界時（UTC）です。次のファイルは2008年7月29日に作成されました。カットオフ時間は、24時間時計に基づいて、時間:分:秒（04:08:44）で表示されます。
syncrecords1090998000.20080729.040844.ldif
ファイルが作成された時刻とレコードのアーカイブまたはパージのカットオフ時間と同様に、名前も一意識別子です。選択したカットオフ時間より前に作成されたすべてのレコードがアーカイブまたはパージされます。
デフォルトでは、アーカイブされたldifファイルは次の場所に格納されます。
PolicyManager_install_dir\access\oblix\data\common
PolicyManager_install_dirは、ポリシー・マネージャをインストールしたディレクトリを表します。
このタスク中に、表示されるリストから年、月、日を選択します。選択した日付より前に作成されたすべてのレコードがアーカイブされます。同期レコードをアーカイブするよう選択した場合は、ユーザーの記録用に、レコードを含むldifファイルの格納場所がメッセージに表示されます。次に例を示します。
Successfully archived 210 sync records generated before the selected date to file /export/home/COREid1014/webcomponent/access/oblix/data/common/syncrecords109099 8000.20080729.040844.ldif
後から、必要に応じてアーカイブされた（エクスポートされた）.ldifファイルを確認できます。これらの同期レコードをインポートする必要はありません。
アクセス・システム・コンソールで、「システム管理」をクリックします。
左側のナビゲーション・ペインで、「同期レコードの管理」をクリックします。
「同期レコードの管理」ページで、表示されるリストから年、月、日を選択し、同期レコードが生成された日付を指定します。
「同期レコードのアーカイブ」ボタンをクリックします。
レコードをアーカイブするかどうか確認する質問に対し、「OK」をクリックしてアクションを実行します。または「取消」をクリックして操作を取り消します。
メッセージに格納場所が表示されたら、これを記録しておきます。次に例を示します。
/export/home/COREid1014/webcomponent/access/oblix/data/common/syncrecords109099 8000.20080729.040844.ldif
同期レコードをパージするには、マスター・アクセス管理者である必要があります。
このタスク中に、表示されるリストから年、月、日を選択します。選択した日付より前に作成されたすべてのレコードがパージされます。パージされたレコードは削除されます。
|
注意: パージする前に同期レコードをアーカイブしておくことをお薦めします。後から、必要に応じてアーカイブされた（エクスポートされた）.ldifファイルを確認できます。これらの同期レコードをインポートする必要はありません。 |
アクセス・システム・コンソールで、「システム管理」をクリックします。
左側のナビゲーション・ペインで、「同期レコードの管理」をクリックします。
「同期レコードの管理」ページで、表示されるリストから年、月、日を選択し、同期レコードが生成された日付を指定します。
「同期レコードのパージ」ボタンをクリックします。
本当にレコードをパージするかどうかの質問に対し、「OK」をクリックしてアクションを実行します。または「取消」をクリックして操作を取り消します。
使用環境に複数のディレクトリ・サーバーに書き込む複数のアクセス・サーバーが含まれていなければ、この項はスキップしてかまいません。この項では、次のトピックとタスクについて説明します。
Oracle Access Managerでは、ディレクトリ・サーバーに次の3種類の情報を格納します。
ユーザー・データ: 複数のディレクトリ・サーバー・インスタンスに配布できます。
構成データ: 複数のディレクトリ・サーバー・インスタンスに配布することはできません。
|
注意: レプリケーションを構成していて、2つのマスター・ディレクトリ・サーバーに同じ構成情報が含まれている場合もあります。これについては、このトピックの後半で説明します。 |
ポリシー・データ: 複数のディレクトリ・サーバー・インスタンスに配布することはできません。
ユーザー・プロファイル情報またはポリシー情報に対して行った変更はすべて、ディレクトリ・サーバーで更新されます。これらの情報を変更した場合は、認証情報および認可情報を最新に保つために、アクセス・サーバーのキャッシュ・フラッシュを行う必要があります。Oracle Access Managerの「キャッシュの更新」機能を有効にすると、ディレクトリ・サーバーにエントリが書き込まれるたびに強制的にキャッシュ・フラッシュが行われます。「キャッシュの更新」を選択しない場合は、アクセス・サーバーのキャッシュは、キャッシュがタイムアウトになって新しい情報をディレクトリ・サーバーから読み取ったときに更新されます。
アクセス・サーバーでキャッシュ・フラッシュ・リクエストを受信するたびに（「キャッシュの更新」機能が有効な場合はエントリがディレクトリ・サーバーに書き込まれるたびに、無効な場合はタイムアウト時と読込み操作時に）、次のように動作します。
最新のoblixGSNエントリをフェッチします。この中にディレクトリ・サーバーから取得したGSNが保持されています（同期レコードをパージしてもこれには影響を与えません）。
oblixGSNオブジェクト・クラスをチェックします。これはキャッシュ・フラッシュのメカニズムで使用されます。
グローバル順序番号（oblixGSNオブジェクト・クラス内のobSeqNo属性の値）をチェックします。これは最後のフラッシュ・リクエスト番号です。
グローバル順序番号（obSeqNo値）を増分し、それを同期レコード（oblixSynchRecord）に格納します。
obSyncRequestNo、ObSyncChangedTypeおよびobSyncTimeを含むキャッシュ・フラッシュ情報を使用して、同期レコードを更新します。
キャッシュ・フラッシュ操作を成功させるには、ディレクトリ・サーバーの同期レコードが一意であり、obSeqNoが単一かつ一意の値であり、oblixGSNオブジェクト・クラスが1つのobSeqNoを含む必要があります。次に例を示します。
obSeqNo=15,cn=obapp=PSC,o=Oblix,<config tree>
GSN情報は、1つのディレクトリ・サーバー・インスタンス内の構成データに格納されています。GSN情報は、oblixGSNオブジェクト・クラスのエントリを参照します。これにはグローバル順序番号（obSeqNo）の値が含まれています。
|
注意: 高可用性環境用に構成されたレプリケーションがある場合は、2つのマスター・ディレクトリ・サーバー・インスタンスに同じ構成情報が含まれることがあります。このような場合は、アクセス・サーバーによってディレクトリ・サーバーの情報が更新されると、ディレクトリ・サーバーで定期的にそのコンテンツが相互に同期化されます。 |
複数のディレクトリ・サーバーに書込みを行う複数のアクセス・サーバーが存在する場合は、特定のエントリ用の同期レコードを持つか、各ディレクトリ・サーバー内で変更を行います。同期レコード（oblixSynchRecord）とグローバル順序番号（obSeqNo）はどちらも同じである必要があります。ただし、これらのレコードは、ディレクトリ・サーバーの同期間のタイムラグのために、同期化されない場合があります。
破損したエントリには、1つのobapp=PSC,o=oblix,<config tree>ノードの下に、複数のobSeqNo値または複数のエントリが存在する場合があります。次に例を示します。
obSeqNo=101,obSeqNo=102,obapp=PSC,o=Oblix,<config tree>
または
obSeqNo=101,obapp=PSC,o=Oblix,<config tree>
obSeqNo=102,obapp=PSC,o=Oblix,<config tree>
破損が発生すると、アクセス・サーバー間で動作に矛盾が生じます。そのため、問題を検出してリカバリする方法が必要になります。リカバリでは、破損したエントリをディレクトリ・サーバーから削除する必要があります。
Oracle Access Managerにより、ディレクトリ・サーバー内の同期レコードの破損を検出し、新しいコマンドライン・ツールを使用してリカバリすることができます。詳細は、「検出とリカバリの概要」を参照してください。
同期レコードの破損の検出とリカバリに使用できるrecovergsncorruptionという名前のコマンドライン・ツールが用意されており、次のパスに格納されています。
PolicyManager_install_dir\access\oblix\tools\recovergsncorruption\
リカバリ処理に必要なすべてのパラメータは、コマンドラインから属性として入力するか、あるいはスクリプトを使用して提供できます。パラメータをコマンドラインから属性として入力しない場合は、値を1つずつ入力するよう要求されます。
表8-1 recovergsncorruptionのパラメータと値
| パラメータ | 値 | 説明 |
|---|---|---|
|
-i |
PolicyManager_install_dir |
recovergsncorruptionユーティリティのインストール・パスを指定します。 |
|
-isCacheFlushDisabled |
次のトピックに示すリカバリ準備のための必須タスクが実行済であることの確認です。 リカバリを実行する場合はこれを使用します。必須タスクは次のとおりです。 |
|
|
-recoverCorruption |
no |
次のように、リカバリなしで破損の検出を開始します。
|
|
-recoverCorruption |
yes 注意: リカバリの前に、準備タスクを実行してキャッシュ・フラッシュ操作を停止する必要があります。isCacheFlushDisabled Yesを参照してください。 |
次の手順で、破損の検出とリカバリを開始します。
|
このツールを使用するスクリプトを作成することもできます。スクリプトの構文は、コマンドラインからユーティリティを実行する場合の構文と類似しています。次に例を示します。
破損を検出する場合:
recovergsncorruption -i PolicyManager_install_dir -isCacheFlushDisabled yes
-recoverCorruption no
破損を検出してリカバリする場合:
recovergsncorruption -i PolicyManager_install_dir -isCacheFlushDisabled yes
-recoverCorruption yes
どちらの場合でも、同期レコードを更新する場合は、リカバリ中に起こりうる問題を回避するために、リカバリの前に必ずキャッシュ・フラッシュ操作を停止しておく必要があります。
リカバリ中には、ディレクトリ・サーバーにある元の同期レコードを使用して、次の手順が実行されます。
手順の概要: リカバリ処理
1つのoblixGSNエントリ内にある重複したobSeqNo値がディレクトリ・サーバーから削除されます（oblixGSNエントリ内のObSeqNo値が、単一かつ一意になります）。
oblixGSNオブジェクト・クラスの重複したエントリがディレクトリ・サーバーから削除されます。
削除されたobSeqNoを含む同期レコードが、新しいobSeqNo値で更新されます。
obSeqNoの更新: 同期レコードの更新後、obSeqNoはoblixGSNエントリ内の最大のObSyncRequestNoで更新されます。
進行状況は、PolicyManager_install_dir\access\oblix\tools\recovergsncorruption\recovergsncorruption.logにあるrecovergsncorruption.logという名前のファイルに記録されます。
リカバリが成功すると、通知されます。この場合、ディレクトリ・サーバーにoblixGSNオブジェクト・クラスの重複したエントリはありません。oblixGSNオブジェクト・クラスに存在するObSeqNo値は、単一かつ一意です。重複した値は削除され、ObSeqNoは更新（増分）されます。重複した同期レコードはありません。削除された値を含む同期レコードは削除されます。詳細は、「同期レコードの破損からのリカバリ」を参照してください。
リカバリが成功しなかった場合は、ディレクトリ・サーバーを前のステータス（リカバリを行う前）に戻すための手順を実行する必要があります。詳細は、「リカバリ処理中に発生したエラーの修正」を参照してください。
タスク概要: 複数のディレクトリ・サーバーでの破損した同期レコードの検出とリストア
次のトピックを確認してください。
このタスク概要の残りの内容
検出: 「同期レコードの破損の検出」のタスクを実行します。
リカバリ: 次のトピックに記載されているタスクを実行します。
アクセス・サーバーの動作に矛盾がある場合は、このタスクを実行します。このタスクを実行するには、マスター・アクセス管理者である必要があります。
コマンドは区切らずに1行で入力します。この手順の例では、書式上の制約から、複数行で入力されているように表示されます。
同期レコードの破損の検出手順
ポリシー・マネージャをホストするコンピュータから、次のパスにあるrecovergsncorruptionコマンドライン・ツールを探します。
PolicyManager_install_dir\access\oblix\tools\recovergsncorruption\
次のコマンドライン引数を使用して、検出プロセスを開始します。
recovergsncorruption -i PolicyManager_install_dir -isCacheFlushDisabled yes
-recoverCorruption no
または、コマンドラインからオプションを付けずにツールを実行して、パラメータ値の入力を求めるツールのプロンプトを表示することもできます。たとえば、recovergsncorruptionにより次のプロンプトが表示されます。
Please enter the Policy Manager installation directory:
Identity and Policy cache flush disabled? [yes|no]:
Do you want recovery if GSN corruption is detected? [yes|no]:
次のような結果のメッセージを確認し、続行方法を決定します。
No Sync Record Corruption was Detected: 終了します。
Sync Record Corruption was Detected: 「アクセス・サーバーのキャッシュ・フラッシュとGSN更新の無効化」に進みます。
GSN破損の検出またはリカバリ後に、このタスクを実行します。参照用にログ・ファイルが作成されます。これには、破損の検出または破損のリカバリのプロセスに関連する情報、つまりアーカイブされた.ldifファイル、検出に関連する詳細事項、リカバリ操作の成功または失敗に関連する情報が含まれます。また、リカバリ操作が失敗した場合は、失敗の理由も特定されます。
ログ・ファイルには、「検出とリカバリの概要」に記載されている名前が付けられており、次の情報を含みます。
recovergsncorruptionコマンドライン・ツールを実行するたびに、ログ・メッセージがログ・ファイルの既存の情報に付加されます。ログ・ファイルはいつでも削除できます。
ログ・ファイルには生成された.ldifファイルの名前が含まれています。このファイルは、必要に応じて後でインポートできます。一般的なログ・ファイルは、次の例のようになります。
############################# Starting #############################.
Writing Sync records in:
D:/install_dir/access/oblix/data/common/GSNsyncrecords20080630.121814.ldif
Successfully ported the sync records
No corruption was detected under: obapp=PSC,o=Oblix,o=company,c=us
Recovery of policy Sync records completed successfully
Corruption was detected under: cn=UserMgmt,obapp=PSC,o=Oblix,o=company,c=us
Deleting following entry
obSeqNo=3,cn=UserMgmt,obapp=PSC,o=Oblix,o=company,c=us
Deleted successfully
Deleting following entry
obSeqNo=2,cn=UserMgmt,obapp=PSC,o=Oblix,o=company,c=us
Deleted successfully
Adding GSN entry
obSeqNo=3,cn=UserMgmt,obapp=PSC,o=Oblix,o=company,c=us
Recovery of user sync records completed successfully
############################# Finished #############################.
GSN破損の検出またはリカバリ後のログ・ファイルのチェック手順
検出またはリカバリを実行したコンピュータ上の次のパスにあるrecovergsncorruption.logを探します。
PolicyManager_install_dir\access\oblix\tools\recovergsncorruption\
メッセージを精査して、検出、削除、追加または失敗がなかったかどうか、またある場合はその理由を確認します。
ログに記録された詳細情報（ツールによって作成された同期レコードへの参照を含む）が不要な場合は、ログを削除してかまいません。
同期レコードの破損が検出された後で、このタスクを実行します。このタスクを実行するには、マスター・アクセス管理者である必要があります。
アクセス・サーバーのキャッシュ・フラッシュを無効にするには、各アイデンティティ・サーバーのbasedbparams.xmlファイルで、doAccessServerFlushパラメータをfalseに設定する必要があります。これで、Access Manager SDKからアクセス・サーバーのキャッシュをフラッシュするリクエストは送信されません。詳細は、『Oracle Access Manager IDおよび共通管理ガイド』で、Access Manager SDKのアイデンティティ・システム用の構成に関する項のトピックを参照してください。
リカバリが成功したら、「キャッシュ・フラッシュ操作のリストア」の説明に従って、この操作を元に戻すことができます。
アイデンティティ・サーバーとアクセス・サーバー間のキャッシュ・フラッシュを無効にする手順
次のアイデンティティ・サーバーのパスにあるbasedbparams.xmlファイルを探します。
IdentityServer_install_dir/identity/oblix/data/common/basedbparams.xml
basedbparams.xmlファイルにあるdoAccessServerFlushパラメータを探し、これをfalseに設定します。
<NameValPair ParamName="doAccessServerFlush" Value="false" />
ファイルを保存します。
アイデンティティ・サーバーを再起動します。
アクセス・サーバーを再起動します。
この手順をすべてのアデンティティ・サーバーで繰り返し、サーバーを1つずつ再起動します。
アイデンティティ・サーバーとアクセス・サーバー間のキャッシュ・フラッシュ操作を無効にした後で、システム・コンソールで定義した設定に基づいて自動的に行われる更新をブロックする必要があります。これを行うには、システム・コンソールで「キャッシュの更新」オプションを無効にします。
キャッシュの更新: このオプションは、次のページで無効にする必要があります。
アイデンティティ・システム・コンソール: アイデンティティ・システム・コンソール内のページには「キャッシュの更新」オプションはありません。
ポリシー・マネージャ: ポリシー・ドメインに関連するほぼすべてのページに「キャッシュの更新」オプションがあります。次を確認してください。
「ポリシー・ドメイン」ページ
「リソース」タブ内のページ
「認可ルール」タブ内のページ
「デフォルト・ルール」タブ内のページ
「ポリシー」タブ内のページ
アクセス・システム・コンソール: 「アクセス・システム構成」タブ内のいくつかのページには「キャッシュの更新」オプションが含まれており、これを無効にする必要があります。次を確認してください。
「認証管理」ページと個々の認証スキームタブ（「一般」、「ステップ」、「認証フロー」）
「共通情報の構成」、「マスター監査ルール」タブ
「ホスト識別子」、「すべてのホスト識別子をリスト」ページ
ポリシー・マネージャAPI: 「キャッシュの更新」オプションを無効にすることに加えて、ポリシー・マネージャAPIがオフであることを確認する必要があります。
|
注意: ポリシー・マネージャAPIとアクセス管理サービスは、システム・コンソールではどちらも同じものとして使用されます。 |
「アクセス・システム構成」の次の各ページでポリシー・マネージャAPI機能を無効にします。
アクセス・サーバー構成
アクセス・サーバー・クラスタ
アクセス・ゲート構成
リカバリが成功したら、「キャッシュ・フラッシュ操作のリストア」の説明に従って、この操作を元に戻すことができます。
ポリシー・マネージャとアプリケーションからの更新をブロックする手順
アクセス・システム・コンソールで、「アクセス・システム構成」タブ→「アクセス・サーバー構成」の順にクリックし、次の手順を実行します。
アクセス・サーバーの名前をクリックします。
必要に応じてアクセス・サーバーの構成を変更し、アクセス管理サービスをオフにします。
これらの手順をすべてのアクセス・サーバーで繰り返します。
「アクセス・システム構成」タブで、「アクセス・サーバー・クラスタ」をクリックし、次の手順を実行します。
クラスタの名前をクリックします。
「ポリシー・マネージャAPIサポート・モード」がオフであることを確認します。
これらの手順をすべてのアクセス・サーバー・クラスタで繰り返します。
「アクセス・システム構成」タブで、「アクセス・ゲート構成」をクリックし、次の手順を実行します。
アクセス・ゲートの名前を探してクリックします。
Access SDK Clientラベルの下にある「アクセス管理サービス」がオフであることを確認します。
これらの手順をアクセス・サーバーを使用するすべてのアクセス・ゲートで繰り返します。
「アクセス・システム構成」タブで、「認証管理」をクリックし、次の手順を実行します。
「認証管理: 認証スキームのリスト」ページで、「キャッシュの更新」オプションが選択されていないことを確認します。
認証スキームの名前をクリックします。
「一般」タブ→「変更」の順にクリックし、「キャッシュの更新」オプションが選択されていないことを確認します。
「プラグイン」タブをクリックし、プラグインの名前をクリックして、「キャッシュの更新」オプションが選択されていないことを確認します。
「ステップ」タブをクリックし、「キャッシュの更新」オプションが選択されていないことを確認します。
「認証フロー」ページで、ステップ名をクリックし、「キャッシュの更新」オプションが選択されていないことを確認します。
定義済の各認証スキームでこれらの手順を繰り返します。
「アクセス・システム構成」タブで、「共通情報の構成」をクリックし、次の手順を実行します。
「マスター監査ルール」タブをクリックします。
「キャッシュの更新」オプションが選択されていないことを確認します。
「アクセス・システム構成」タブで、「ホスト識別子」をクリックし、「すべてのホスト識別子をリスト」ページで、「キャッシュの更新」オプションが選択されていないことを確認します。
このタスクは、ポリシー・マネージャからの更新をブロックした後で実行します。このタスクを実行するには、マスター・アクセス管理者である必要があります。
リカバリ中には、ディレクトリ・サーバーにある元の同期レコードを使用して、次の処理が実行されます。
1つのoblixGSNオブジェクト・クラス内にある重複したobSeqNo値がディレクトリ・サーバーから削除されます（oblixGSNエントリ内のObSeqNo値が、単一かつ一意になります）。
oblixGSNオブジェクト・クラスの重複したエントリがディレクトリ・サーバーから削除されます。
削除されたobSeqNoの同期レコードが更新されます。たとえば、削除された同期レコードもまた、同期後に破損状態である可能性があり（GSNエントリと同じ）、recovergsncorruptionはこれを修復しようとします。
obSeqNoは、最大値または一番大きいObSyncRequestNoで更新されます。
リカバリが成功しなかった場合は、ディレクトリ・サーバーを前のステータス（リカバリを行う前の状態）に戻すための手順を実行する必要があります。詳細は、「リカバリ処理中に発生したエラーの修正」を参照してください。
同期レコードの破損からリカバリする手順
次のパスにあるrecovergsncorruptionコマンドライン・ツールを探します。
PolicyManager_install_dir\access\oblix\tools\recovergsncorruption\
次のコマンドライン引数を使用して、検出とリカバリを開始します。
recovergsncorruption -i PolicyManager_install_dir -isCacheFlushDisabled yes
-recoverCorruption yes
次のように進めます。
リカバリ処理中のエラー: 「リカバリ処理中に発生したエラーの修正」に進みます。
リカバリが正常に終了: すべての破損が解決され、キャッシュ・フラッシュは問題なく続行されます。この場合は、「キャッシュ・フラッシュ操作のリストア」の説明に従って、キャッシュ・フラッシュ操作をリストアすることができます。
同期レコードのリカバリ処理でエラーが発生しなかった場合は、この項目はスキップしてかまいません。このタスクを実行するには、マスター・アクセス管理者である必要があります。
同期レコードのリカバリ中にエラーが発生した場合は、リカバリ処理中にアーカイブされたldifファイルをインポートして、ディレクトリ・サーバーの同期レコードをリストアし、リカバリ開始前の状態にすることができます。ldifファイルには、PSCノードの下にあるoblixgsnオブジェクト・クラスのエントリ（キャッシュ・フラッシュで使用）およびobsyncrecord（フラッシュしたコンポーネントとこれに属するポリシー・ドメインまたはポリシーを記述）が含まれています。これらはリカバリを行う前から存在していました。
リカバリ処理中に作成された同期レコードのldifファイルは、次の場所に格納されています。
PolicyManager_install_dir\access\oblix\data\common\
GSNsyncrecords.年月日.時分秒.ldifの命名規則が使用されます。次に例を示します。
GSNsyncrecords.20080729.040844.ldif
同期レコードのリカバリ処理中に発生したエラーからのリカバリ手順
「アクセス・サーバーのキャッシュ・フラッシュとGSN更新の無効化」の説明に従って、グローバルな同期番号の更新が無効になっていることを確認します。
「AMAPIを使用したポリシー・マネージャとアプリケーションからの更新のブロック」の説明に従って、ポリシー・マネージャとアプリケーションからの更新がブロックされた状態であることを確認します。
リカバリ処理中に作成された同期レコードの.ldifファイルを探します。次に例を示します。
PolicyManager_install_dir\access\oblix\data\common\ GSNsyncrecords.20080729.040844.ldif
ディレクトリ・サーバーに対してコマンドを実行し、ldifファイルをインポートしてディレクトリ・サーバーをリカバリ前の状態にリストアします。
次のように進めます。
成功: 終了します。
失敗: 破損をディレクトリ・サーバーから手動で削除する必要があります。詳細は、ディレクトリ・サーバーのドキュメントを参照してください。
このタスクを実行するには、マスター・アクセス管理者である必要があります。
リカバリが成功したら、各アイデンティティ・サーバーのbasedbparams.xmlファイルにあるdoAccessServerFlushパラメータをtrueに設定し、アクセス・サーバーのキャッシュ・フラッシュを有効にできます。また、ポリシー・マネージャからの更新のブロックを解除する必要があります。
アクセス・サーバーのキャッシュ・フラッシュを有効にする手順
次のアイデンティティ・サーバーのパスにあるbasedbparams.xmlファイルを探します。
IdentityServer_install_dir/identity/oblix/data/common/basedbparams.xml
basedbparams.xmlファイルにあるdoAccessServerFlushパラメータを探し、これをtrueに設定します。
ファイルを保存します。
アイデンティティ・サーバーを再起動します。
アクセス・サーバーを再起動します。
この手順をすべてのアイデンティティ・サーバーで繰り返し、各サーバーを1つずつ再起動します。
ポリシー・マネージャとアプリケーションからの更新のブロックを、更新をブロックしたときと逆の手順で解除します。
キャッシュの更新: アイデンティティ・システム・コンソール、ポリシー・マネージャ、アクセス・システム・コンソールの各ページで、「キャッシュの更新」オプションを有効にします。
ポリシー・マネージャAPI: 「アクセス・サーバー構成」、「アクセス・サーバー・クラスタ」および「アクセス・ゲート構成」の各ページでポリシー・マネージャAPIが有効になっていることを確認します。
|
注意: 「ポリシー・マネージャAPI」と「アクセス管理サービス」という用語は、システム・コンソールではどちらも同じものとして使用されます。 |
詳細は、「AMAPIを使用したポリシー・マネージャとアプリケーションからの更新のブロック」を参照してください。
