Oracle® Fusion Middleware

Oracle Internet Directory管理者ガイド

11g リリース1 (11.1.1)

B55919-08(原本部品番号:E56468-03)

2018年8月

Oracle Internet Directoryの管理者向けドキュメントであり、Oracle Directory Services Manager (ODSM)、Oracle Enterprise Manager Fusion Middleware Controlおよびコマンド行ユーティリティを使用してOracle Internet Directoryを管理する方法について説明しています。

Oracle Fusion Middleware Oracle Internet Directory管理者ガイド, 11gリリース1(11.1.1)

B55919-08

Copyright © 1999, 2018, Oracle and/or its affiliates. All rights reserved.

原本著者: Devanshi Mohan

原本協力著者: Sandhya US

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があり、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、このソフトウェアまたはハードウェアを安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

図一覧

表一覧

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

Oracle Internet Directoryの新機能

- Oracle Internet Directory 11gリリース1(11.1.1.9.0)で導入された新機能

- Oracle Internet Directory 11gリリース1(11.1.1.7.0)で導入された新機能

- Oracle Internet Directory 11gリリース1(11.1.1.6.0)で導入された新機能

- Oracle Internet Directory 11g リリース1(11.1.1.4.0)で導入された新機能

- Oracle Internet Directory 11gリリース1(11.1.1)で導入された新機能

- Oracle Internet Directory 10g(10.1.4.1)で導入された新機能

- Oracle Internet Directory 10gリリース2(10.1.2)で導入された新機能

第I部 ディレクトリ・サービスの理解

1 ディレクトリ・サービスの概要

- 1.1 ディレクトリとは

- 1.1.1 拡大するオンライン・ディレクトリの役割

- 1.1.2 問題点: 特別な用途を指定されたディレクトリが多すぎる場合

- 1.2 Lightweight Directory Access Protocol(LDAP)とは

- 1.2.1 LDAPと単純化されたディレクトリ管理

- 1.2.2 LDAPバージョン3

- 1.3 Oracle Internet Directoryとは

- 1.3.1 Oracle Internet Directoryの概要

- 1.3.2 Oracle Internet Directoryのコンポーネント

- 1.3.3 Oracle Internet Directoryの利点

- 1.3.3.1 スケーラビリティ

- 1.3.3.2 高可用性

- 1.3.3.3 セキュリティ

- 1.3.3.4 Oracle環境との統合

- 1.4 Oracle製品によるOracle Internet Directoryの使用

- 1.4.1 簡単で対費用効果の高いOracle製品の管理

- 1.4.2 セキュリティ・ポリシーの集中管理によるセキュリティの強化

- 1.4.3 複数ディレクトリの統合

2 Oracle Fusion Middleware内のOracle Internet Directoryの理解

- 2.1 WebLogic Serverドメイン

- 2.2 システム・コンポーネントとしてのOracle Internet Directory

- 2.3 Oracle Internet Directoryのデプロイメント・オプション

- 2.4 Middlewareホーム

- 2.5 WebLogic Serverホーム

- 2.6 Oracle共通ホーム

- 2.7 Oracleホーム

- 2.8 Oracleインスタンス

- 2.9 Oracle Enterprise Manager Fusion Middleware Control

- 2.10 ロギング、監査および診断

- 2.11 MBeanおよびWebLogic Scripting Tool

3 Oracle Internet Directoryの概念およびアーキテクチャの理解

- 3.1 Oracle Internet Directoryのアーキテクチャ

- 3.1.1 Oracle Internet Directoryのノード

- 3.1.2 Oracleディレクトリ・サーバー・インスタンス

- 3.1.3 Oracle Internet Directoryのポート

- 3.1.4 ディレクトリ・メタデータ

- 3.2 Oracle Internet Directoryによる検索リクエストの処理方法

- 3.2.1 標準LDAP検索操作

- 3.2.2 永続LDAP検索操作

- 3.3 ディレクトリ・エントリ

- 3.3.1 識別名(DN)とディレクトリ情報ツリー(DIT)

- 3.3.2 エントリ・キャッシング

- 3.4 属性

- 3.4.1 属性情報の種類

- 3.4.2 単一値と複数値の属性

- 3.4.3 一般的なLDAP属性

- 3.4.4 属性の構文

- 3.4.5 属性の一致規則

- 3.4.6 属性オプション

- 3.5 オブジェクト・クラス

- 3.5.1 サブクラス、スーパークラスおよび継承

- 3.5.2 オブジェクト・クラスの型

- 3.5.2.1 構造型オブジェクト・クラス

- 3.5.2.2 補助型オブジェクト・クラス

- 3.5.2.3 抽象型オブジェクト・クラス

- 3.6 ネーミング・コンテキスト

- 3.7 セキュリティ

- 3.8 グローバリゼーション・サポート

- 3.9 分散ディレクトリ

- 3.9.1 ディレクトリ・レプリケーション

- 3.9.2 ディレクトリ・パーティション化

- 3.10 ナレッジ参照と参照

- 3.11 Oracle Delegated Administration ServicesとOracle Internet Directoryセルフサービス・コンソール

- 3.12 サービス・レジストリとサービス・ツー・サービス認証

- 3.13 Oracle Directory Integration Platform

- 3.14 Oracle Internet Directoryとアイデンティティ管理

- 3.14.1 アイデンティティ管理について

- 3.14.2 アイデンティティ管理レルム

- 3.14.2.1 デフォルトのアイデンティティ管理レルム

- 3.14.2.2 アイデンティティ管理ポリシー

- 3.15 TCPキープ・アライブ

- 3.16 リソース情報

- 3.16.1 リソース・タイプ情報

- 3.16.2 リソース・アクセス情報

- 3.16.3 DIT内のリソース情報の位置

4 Oracle Internet Directoryコンポーネントのプロセス制御の理解

- 4.1 Oracle Internet Directoryのプロセス制御アーキテクチャ

- 4.2 ODS_PROCESS_STATUS表

- 4.3 Oracle Internet Directoryのプロセスの起動、停止およびモニタリング

- 4.3.1 opmn.xmlのOracle Internet Directoryスニペット

- 4.3.2 Oracle Internet Directoryを起動するOPMN

- 4.3.3 Oracle Internet Directoryを停止するOPMN

- 4.3.4 プロセスのモニタリング

- 4.4 Oracle Internet Directoryレプリケーション・サーバーの制御およびフェイルオーバー

- 4.4.1 OIDモニターおよびレプリケーション・サーバー・フェイルオーバーの理解

- 4.4.2 Oracle Internet Directoryプロセスのフェイルオーバーの有効化

- 4.5 Oracle Internet Directoryプロセス制御のベスト・プラクティス

5 Oracle Internet Directory編成の理解

- 5.1 ディレクトリ情報ツリーの計画

- 5.2 ディレクトリ構造全体の計画

- 5.3 ユーザーおよびグループのネーミングおよび編成の計画

- 5.3.1 ユーザーの編成

- 5.3.2 グループの編成

- 5.4 DITビューの指定

- 5.5 サード・パーティ・ディレクトリからのDITの移行

6 Oracle Internet Directoryレプリケーションの理解

- 6.1 レプリケーションを使用する理由

- 6.2 レプリケーションの概念

- 6.2.1 レプリケートされるコンテンツ: 完全または部分

- 6.2.2 方向: 一方向、双方向またはpeer-to-peer

- 6.2.3 転送メカニズム: LDAPまたはOracle Databaseアドバンスト・レプリケーション

- 6.2.4 ディレクトリ・レプリケーション・グループ(DRG)タイプ: 単一マスター、マルチマスターまたはファンアウト

- 6.2.4.1 単一マスター・レプリケーションの例

- 6.2.4.2 マルチマスター・レプリケーションの例

- 6.2.4.3 ファンアウト・レプリケーションの例

- 6.2.5 ゆるやかな一貫性モデル

- 6.2.6 レプリケーションの概念の組合せ方法

- 6.2.7 ファンアウトを使用したマルチマスター・レプリケーション

- 6.3 必要なレプリケーションの種類

第II部 基本的な管理

7 Oracle Internet Directoryのスタート・ガイド

- 7.1 システムへのパッチ適用による11gリリース1 (11.1.1.9.0)へのアップグレード

- 7.1.1 ディレクトリ・レプリケーション・グループのアップグレード

- 7.2 インストール後のタスクおよび情報

- 7.2.1 環境の設定

- 7.2.2 OLTS_CT_STOREおよびOLTS_ATTRSTORE表領域へのデータファイルの追加

- 7.2.3 Windowsサービスの設定の変更

- 7.2.4 Oracleスタックの起動と停止

- 7.2.5 デフォルトのURLおよびポートの識別

- 7.2.6 Oracle Internet Directoryのチューニング

- 7.2.7 匿名バインドの有効化

- 7.2.8 Oracle Internet Directoryの特権ポートでの実行の有効化

- 7.2.9 Oracle Databaseタイムゾーンの検証

- 7.3 Fusion Middleware Controlを使用したOracle Internet Directoryの管理

- 7.4 Oracle Directory Services Managerの使用

- 7.4.1 Oracle Directory Services Managerの概要

- 7.4.1.1 Oracle Directory Services ManagerでのJAWSスクリーン・リーダーの使用

- 7.4.1.2 Oracle Directory Services Managerへの非スーパーユーザー・アクセス

- 7.4.1.3 Oracle Directory Services Managerとのシングル・サインオン統合

- 7.4.2 SSO統合用ODSMの構成

- 7.4.3 ODSM統合用SSOサーバーの構成

- 7.4.4 ODSM-SSO統合用のOracle HTTP Serverの構成

- 7.4.5 Oracle Directory Services Managerの起動

- 7.4.6 Oracle Directory Services Managerからサーバーへの接続

- 7.4.6.1 Oracle Directory Services Managerからディレクトリ・サーバーへのログイン

- 7.4.6.2 SSLを使用したOracle Directory Services Managerからディレクトリ・サーバーへのログイン

- 7.4.6.3 SSO認証済ユーザーとしてのSSO対応ディレクトリへの接続

- 7.4.7 Oracle Directory Services Managerセッション・タイムアウトの構成

- 7.4.8 Oracle WebLogic ServerクラスタでOracle Directory Services ManagerをサポートするためのOracle HTTP Serverの構成

- 7.5 コマンド行ユーティリティを使用したOracle Internet Directoryの管理

- 7.5.1 標準LDAPユーティリティの使用方法

- 7.5.2 バルク・ツールの使用

- 7.5.3 WLSTの使用

- 7.6 Oracle Internet Directoryを構成および管理するための基本タスク

8 Oracle Internet Directoryインスタンスの管理

- 8.1 Oracle Internet Directoryインスタンスの管理の概要

- 8.1.1 インスタンス固有の構成エントリ

- 8.1.2 最初のOracle Internet Directoryインスタンスの作成

- 8.1.3 Oracle Internet Directoryインスタンスの追加作成

- 8.1.4 OracleインスタンスまたはコンポーネントのWebLogic Serverへの登録

- 8.2 Fusion Middleware Controlを使用したOracle Internet Directoryコンポーネントの管理

- 8.2.1 Fusion Middleware Controlを使用したアクティブ・サーバーの情報の表示

- 8.2.2 Fusion Middleware Controlを使用したOracle Internet Directoryサーバーの起動

- 8.2.3 Fusion Middleware Controlを使用したOracle Internet Directoryサーバーの停止

- 8.2.4 Fusion Middleware Controlを使用したOracle Internet Directoryサーバーの再起動

- 8.3 opmnctlを使用したOracle Internet Directoryコンポーネントの管理

- 8.3.1 opmnctlを使用したOracle Internet Directoryコンポーネントの作成

- 8.3.2 opmnctlを使用したOracleインスタンスの登録

- 8.3.3 opmnctlを使用したOracleインスタンスの登録解除

- 8.3.4 opmnctlを使用したOracleインスタンスのコンポーネント登録の更新

- 8.3.5 opmnctlを使用したOracle Internet Directoryコンポーネントの削除

- 8.3.6 opmnctlを使用したアクティブ・サーバー・インスタンスの情報の表示

- 8.3.7 opmnctlを使用したOracle Internet Directoryサーバーの起動

- 8.3.8 opmnctlを使用したOracle Internet Directoryサーバーの停止

- 8.3.9 opmnctlを使用したOracle Internet Directoryサーバーの再起動

- 8.3.10 opmn.xmlのOracle Database情報の変更

- 8.4 OIDCTLを使用したレプリケーション・サーバーのインスタンスの起動

- 8.5 レプリケーション・サーバーの起動と停止の方法について

9 システム構成属性の管理

- 9.1 システム構成属性の管理の概要

- 9.1.1 構成属性とは

- 9.1.2 操作属性とは

- 9.1.3 インスタンス固有の構成エントリの属性

- 9.1.4 DSA構成エントリの属性

- 9.1.5 DSEの属性

- 9.2 Fusion Middleware Controlを使用したシステム構成属性の管理

- 9.2.1 サーバー・プロパティの構成

- 9.2.2 共有プロパティの構成

- 9.2.3 その他のパラメータの構成

- 9.3 WLSTを使用したシステム構成属性の管理

- 9.4 LDAPツールを使用したシステム構成属性の管理

- 9.4.1 ldapmodifyを使用したシステム構成属性の設定

- 9.4.2 ldapsearchによる構成属性のリスト

- 9.5 ODSMデータ・ブラウザを使用したシステム構成属性の管理

- 9.5.1 インスタンス固有の構成エントリへの移動

- 9.5.2 DSA構成エントリへの移動

- 9.5.3 DSEルートへの移動

10 IPアドレスの管理

- 10.1 IPアドレスの管理の概要

- 10.2 IP V6、コールド・フェイルオーバー・クラスタまたは仮想IP用のIPアドレスの構成

- 10.3 クラスタ内通知用のIPアドレスの構成

11 ネーミング・コンテキストの管理

- 11.1 ネーミング・コンテキストの管理の概要

- 11.2 公開されたネーミング・コンテキストの検索

- 11.3 ネーミング・コンテキストの公開

12 アカウントおよびパスワードの管理

- 12.1 アカウントおよびパスワードの管理の概要

- 12.2 コマンド行ツールを使用したアカウントおよびパスワードの管理

- 12.2.1 コマンド行ツールを使用したアカウントの有効化と無効化

- 12.2.2 コマンド行ツールを使用したアカウントのロック解除

- 12.2.3 コマンド行ツールを使用したパスワードの強制変更

- 12.3 セルフサービス・コンソールを使用したアカウントおよびパスワードの管理

- 12.3.1 Oracle Internet Directoryセルフサービス・コンソールを使用したアカウントの有効化と無効化

- 12.3.2 Oracle Internet Directoryセルフサービス・コンソールを使用したアカウントのロック解除

- 12.3.3 Oracle Internet Directoryセルフサービス・コンソールを使用したパスワードの再設定

- 12.4 Oracle Directory Services Managerを使用したロックされたアカウントのリストおよびロック解除

- 12.5 Fusion Middleware Controlを使用したスーパーユーザー・パスワードの変更

- 12.6 スーパーユーザー権限を持つ別のアカウントの作成

- 12.7 ldapmodifyを使用したスーパーユーザー・パスワードの管理

- 12.8 Oracle Internet Directoryデータベース・パスワードの変更

- 12.9 スーパーユーザーのパスワードの再設定

- 12.10 EMD管理者アカウントのパスワードの変更

- 12.11 ODSSM管理者アカウントのパスワードの変更

13 ディレクトリ・エントリの管理

- 13.1 ディレクトリ・エントリの管理の概要

- 13.2 Oracle Directory Services Managerを使用したエントリの管理

- 13.2.1 Oracle Directory Services Managerを使用したエントリの表示

- 13.2.2 Oracle Directory Services Managerを使用したエントリの検索

- 13.2.3 Oracle Directory Services Managerを使用したLDIFファイルのエントリのインポート

- 13.2.4 Oracle Directory Services Managerを使用したLDIFファイルへのエントリのエクスポート

- 13.2.5 Oracle Directory Services Managerを使用した特定エントリの属性の表示

- 13.2.6 Oracle Directory Services Managerを使用した新規エントリの追加

- 13.2.7 Oracle Directory Services Managerを使用したエントリまたはサブツリーの削除

- 13.2.8 Oracle Directory Services Managerの既存エントリを利用したエントリの追加

- 13.2.9 Oracle Directory Services Managerを使用したエントリの変更

- 13.3 LDAPコマンド行ツールを使用したエントリの管理

- 13.3.1 ldapsearchを使用したディレクトリのすべての属性のリスト

- 13.3.2 ldapsearchを使用した操作属性のリスト

- 13.3.3 ldapsearch出力における属性の大/小文字

- 13.3.4 ldapaddを使用したユーザー・エントリの追加

- 13.3.5 ldapmodifyを使用したユーザー・エントリの変更

- 13.3.6 ldapmodifyを使用した属性オプションの追加

- 13.3.7 ldapmodifyを使用した属性オプションの削除

- 13.3.8 ldapsearchを使用した属性オプション付きエントリの検索

14 動的グループと静的グループの管理

- 14.1 動的グループと静的グループの管理の概要

- 14.1.1 静的グループ

- 14.1.1.1 静的グループ作成のためのスキーマ要素

- 14.1.2 動的グループ

- 14.1.2.1 キャッシュされている動的グループおよびされていない動的グループ

- 14.1.2.2 Oracle Internet Directoryでの動的グループの拡張機能および制限事項

- 14.1.2.3 動的グループ作成のためのスキーマ要素

- 14.1.3 階層

- 14.1.4 グループ・エントリの問合せ

- 14.1.5 orclMemberOf属性

- 14.1.6 各グループを使用すべき場合

- 14.2 Oracle Directory Services Managerを使用したグループ・エントリの管理

- 14.2.1 Oracle Directory Services Managerを使用した静的グループ・エントリの作成

- 14.2.2 Oracle Directory Services Managerを使用した静的グループ・エントリの変更

- 14.2.3 Oracle Directory Services Managerを使用した動的グループ・エントリの作成

- 14.2.4 Oracle Directory Services Managerを使用した動的グループ・エントリの変更

- 14.3 コマンド行を使用したグループ・エントリの管理

- 14.3.1 ldapaddを使用した静的グループ・エントリの作成

- 14.3.2 ldapmodifyを使用した静的グループの変更

- 14.3.3 ldapaddを使用した動的グループ・エントリの作成

- 14.3.3.1 labeledURI属性を使用したキャッシュされた動的グループの作成

- 14.3.3.2 labeledURI属性を使用したキャッシュされない動的リストの作成

- 14.3.3.3 CONNECT BY文字列を使用した動的グループの作成

- 14.3.4 ldapmodifyを使用した動的グループの変更

15 バルク操作の実行

- 15.1 バルク操作の実行の概要

- 15.2 サーバー・モードの変更

- 15.2.1 Fusion Middleware Controlを使用したサーバー・モードの設定

- 15.2.2 ldapmodifyを使用したサーバー・モードの設定

- 15.3 bulkloadを使用したスキーマへのデータのロード

- 15.3.1 bulkloadを使用したLDIFファイルのインポート

- 15.3.2 bulkloadを使用した増分または追加モードでのデータのロード

- 15.3.3 bulkloadを使用した索引検証の実行

- 15.3.4 bulkloadを使用した索引の再作成

- 15.3.5 bulkloadを使用したロード失敗後のデータのリカバリ

- 15.4 bulkmodifyを使用した多数のエントリの属性の変更

- 15.4.1 指定ネーミング・コンテキストの下の全エントリへの説明の追加

- 15.4.2 フィルタと一致する指定ネーミング・コンテキストの下のエントリへの属性の追加

- 15.4.3 指定ネーミング・コンテキストの下の全エントリの属性の置換

- 15.5 bulkdeleteを使用したエントリの削除

- 15.5.1 bulkdeleteを使用した指定ネーミング・コンテキストの下の全エントリの削除

- 15.5.2 ネーミング・コンテキストの下のエントリの削除とツームストン・エントリとしての設定

- 15.6 ldifwriteを使用したOracle Internet Directoryからファイルへのデータのダンプ

- 15.6.1 一部の指定ネーミング・コンテキストのLDIFファイルへのダンプ

- 15.6.2 指定ネーミング・コンテキストの下のエントリのLDIFファイルへのダンプ

- 15.7 catalogを使用した既存の属性の索引の作成および削除

- 15.7.1 検索可能属性の検索不可能属性への変更

- 15.7.2 検索不可能属性の検索可能属性への変更

16 集合属性の管理

- 16.1 集合属性の概要

- 16.1.1 RFCでの定義およびOracleによる拡張機能

- 16.1.1.1 RFC 3671

- 16.1.1.2 Oracleの拡張機能

- 16.1.2 集合属性サブエントリの定義

- 16.1.3 subtreeSpecificationの使用

- 16.1.3.1 ベース

- 16.1.3.2 最小および最大

- 16.1.3.3 特定の除外

- 16.1.4 集合属性のオーバーライド

- 16.2 コマンド行を使用した集合属性の管理

- 16.2.1 ldapaddを使用したサブエントリの追加

- 16.2.2 ldapmodifyを使用したサブエントリの変更

17 計算属性の管理

- 17.1 計算属性の概要

- 17.2 計算属性の構成

- 17.2.1 計算属性に使用されるルールおよび構文

- 17.2.1.1 計算属性のルールでの特殊文字の使用

- 17.3 LDAPコマンド行ツールを使用した計算属性の例

- 17.3.1 属性値の大文字での返却

- 17.3.2 属性値の部分文字列の返却

- 17.3.3 属性値の置換

- 17.3.4 URIベースの構成の指定

- 17.3.5 様々なルールの組合せの使用

- 17.3.6 OR(|)演算子の使用

- 17.3.7 connectByインタフェースの使用

- 17.3.8 connectByを使用した階層グループの作成

18 別名エントリの管理

- 18.1 別名エントリの管理の概要

- 18.2 別名エントリの追加

- 18.3 別名エントリによるディレクトリの検索

- 18.3.1 別名エントリによるベースの検索

- 18.3.2 別名エントリによる1レベルの検索

- 18.3.3 別名エントリによるサブツリーの検索

- 18.4 別名エントリの変更

- 18.5 別名間接参照に関するメッセージの解釈

19 属性一意性制約エントリの管理

- 19.1 属性一意性制約エントリの管理の概要

- 19.2 重複する属性値のクリーンアップ

- 19.3 属性一意性制約エントリの指定

- 19.3.1 属性一意性制約での複数の属性名の指定

- 19.3.2 属性一意性制約での複数のサブツリーの指定

- 19.3.3 属性一意性制約での複数の有効範囲の指定

- 19.3.4 属性一意性制約での複数のオブジェクト・クラスの指定

- 19.3.5 属性一意性制約での複数のサブツリー、有効範囲およびオブジェクト・クラスの指定

- 19.4 Oracle Directory Services Managerを使用した属性一意性制約エントリの管理

- 19.4.1 ODSMを使用した属性一意性制約エントリの作成

- 19.4.2 ODSMを使用した属性一意性制約エントリの変更

- 19.4.3 ODSMを使用した属性一意性制約エントリの削除

- 19.5 コマンド行を使用した属性一意性制約エントリの管理

- 19.5.1 コマンド行ツールを使用したディレクトリ全体を対象とする属性一意性の作成

- 19.5.2 コマンド行ツールを使用した1つのサブツリーを対象とする属性一意性の作成

- 19.5.3 コマンド行ツールを使用した1つのオブジェクト・クラスを対象とする属性一意性の作成

- 19.5.4 コマンド行ツールを使用した属性一意性制約エントリの変更

- 19.5.5 コマンド行ツールを使用した属性一意性制約エントリの削除

- 19.5.6 コマンド行ツールを使用した属性一意性の有効化と無効化

20 ナレッジ参照と参照の管理

- 20.1 ナレッジ参照と参照の管理の概要

- 20.2 スマート参照の構成

- 20.3 デフォルト参照の構成

21 ディレクトリ・スキーマの管理

- 21.1 ディレクトリ・スキーマの管理の概要

- 21.1.1 ディレクトリ内のスキーマ情報の格納場所

- 21.1.2 オブジェクト・クラスの理解

- 21.1.2.1 オブジェクト・クラスの追加について

- 21.1.2.2 オブジェクト・クラスの変更について

- 21.1.2.3 オブジェクト・クラスの削除について

- 21.1.3 属性の理解

- 21.1.3.1 属性の追加について

- 21.1.3.2 属性の変更について

- 21.1.3.3 属性の削除について

- 21.1.3.4 属性の索引付けについて

- 21.1.4 エントリと関連付けられた属性数の拡大

- 21.1.4.1 ディレクトリでエントリを作成する前の属性数の拡大

- 21.1.4.2 補助型オブジェクト・クラスの作成による既存エントリの属性数の拡大

- 21.1.4.3 コンテンツ・ルールの作成による既存エントリの属性数の拡大

- 21.1.4.4 コンテンツ・ルールを作成および変更するための規則

- 21.1.4.5 コンテンツ・ルール使用時のスキーマ制約

- 21.1.4.6 コンテンツ・ルールにリストされたオブジェクト・クラスの検索

- 21.1.5 属性別名の理解

- 21.1.6 LDAP操作でのオブジェクト識別子のサポート

- 21.2 Oracle Directory Services Managerを使用したディレクトリ・スキーマの管理

- 21.2.1 Oracle Directory Services Managerを使用したオブジェクト・クラスの検索

- 21.2.2 Oracle Directory Services Managerを使用したオブジェクト・クラスの追加

- 21.2.3 Oracle Directory Services Managerを使用したオブジェクト・クラスの変更

- 21.2.4 Oracle Directory Services Managerを使用したオブジェクト・クラスの削除

- 21.2.5 Oracle Directory Services Managerを使用したオブジェクト・クラスのプロパティの表示

- 21.2.6 Oracle Directory Services Managerを使用した新規属性の追加

- 21.2.7 Oracle Directory Services Managerを使用した属性の変更

- 21.2.8 Oracle Directory Services Managerを使用した属性の削除

- 21.2.9 Oracle Directory Services Managerを使用したすべてのディレクトリ属性の表示

- 21.2.10 Oracle Directory Services Managerを使用した属性の検索

- 21.2.11 Oracle Directory Services Managerを使用した新規属性への索引の追加

- 21.2.12 Oracle Directory Services Managerを使用した既存の属性への索引の追加

- 21.2.13 Oracle Directory Services Managerを使用した属性からの索引の削除

- 21.2.14 Oracle Directory Services Managerを使用したコンテンツ・ルールの作成

- 21.2.15 Oracle Directory Services Managerを使用したコンテンツ・ルールの変更

- 21.2.16 Oracle Directory Services Managerを使用した一致規則の表示

- 21.2.17 Oracle Directory Services Managerを使用した構文の表示

- 21.3 コマンド行を使用したディレクトリ・スキーマの管理

- 21.3.1 ldapsearchを使用したスキーマの表示

- 21.3.2 コマンド行ツールを使用した新規オブジェクト・クラスの追加

- 21.3.3 コマンド行ツールを使用した補助型またはユーザー定義のオブジェクト・クラスへの新規属性の追加

- 21.3.4 コマンド行ツールを使用したオブジェクト・クラスの変更

- 21.3.5 ldapmodifyを使用した属性の追加と変更

- 21.3.6 ldapmodifyを使用した属性の削除

- 21.3.7 ldapmodifyを使用した属性の索引付け

- 21.3.8 ldapmodifyを使用した属性からの索引の削除

- 21.3.9 カタログ管理ツールを使用した属性の索引付け

- 21.3.10 コマンド行を使用した複数の属性別名を持つ新規属性の追加

- 21.3.11 コマンド行を使用した既存の属性の属性別名の追加または変更

- 21.3.12 コマンド行を使用した属性別名の削除

- 21.3.13 属性別名とLDAPコマンドの使用方法

- 21.3.13.1 属性別名とldapsearchの使用方法

- 21.3.13.2 属性別名とldapaddの使用方法

- 21.3.13.3 属性別名とldapmodifyの使用方法

- 21.3.13.4 属性別名とldapdeleteの使用方法

- 21.3.13.5 属性別名とldapmoddnの使用方法

- 21.3.14 コマンド行ツールを使用したコンテンツ・ルールの管理

- 21.3.15 ldapsearchを使用した一致規則の表示

- 21.3.16 ldapsearchを使用した構文の表示

22 参照整合性の構成

- 22.1 参照整合性の構成の概要

- 22.2 Fusion Middleware Controlを使用した参照整合性の有効化

- 22.3 Fusion Middleware Controlを使用した参照整合性の無効化

- 22.4 コマンド行を使用した参照整合性の有効化

- 22.5 コマンド行を使用した参照整合性に関する特定の属性の構成

- 22.6 コマンド行を使用した参照整合性の無効化

- 22.7 参照整合性違反の検出および修正

23 監査の管理

- 23.1 監査の概要

- 23.1.1 監査ストアの構成

- 23.1.2 Oracle Internet Directoryの監査構成

- 23.1.3 レプリケーションとOracle Directory Integration Platformの監査構成

- 23.1.4 監査レコードのフィールド

- 23.1.5 監査レコード記憶域

- 23.1.6 監査レポートの生成

- 23.2 Fusion Middleware Controlを使用した監査の管理

- 23.2.1 Oracle Internet Directoryの機密データ属性の監査

- 23.3 WLSTを使用した監査の管理

- 23.4 コマンド行からの監査の管理

- 23.4.1 コマンド行からの監査構成の表示

- 23.4.2 コマンド行からのOracle Internet Directory監査の構成

- 23.4.3 レプリケーションおよびOracle Directory Integration Platformの監査の有効化

24 ロギングの管理

- 24.1 ロギングの概要

- 24.1.1 Oracle Internet Directoryデバッグ・ロギングの機能

- 24.1.2 ログ・メッセージの解釈

- 24.1.2.1 特定のLDAP操作に関するログ・メッセージ

- 24.1.2.2 特定のLDAP操作と関連付けられていないログ・メッセージ

- 24.1.2.3 例: Oracle Internet Directoryサーバー・ログ・ファイル内のトレース・メッセージ

- 24.2 Fusion Middleware Controlを使用したロギングの管理

- 24.2.1 Fusion Middleware Controlを使用したログ・ファイルの表示

- 24.2.2 Fusion Middleware Controlを使用したロギングの構成

- 24.3 コマンド行からのロギングの管理

- 24.3.1 コマンド行からのログ・ファイルの表示

- 24.3.2 コマンド行を使用したデバッグ・ロギング・レベルの設定

- 24.3.3 コマンド行を使用したデバッグ操作の設定

- 24.3.4 ログ・ファイルへのトレース情報のフラッシュの強制

25 Oracle Internet Directoryのモニタリング

- 25.1 Oracle Internet Directoryサーバーのモニタリングの概要

- 25.1.1 Oracle Internet Directoryサーバー管理機能

- 25.1.2 Oracle Internet Directoryサーバー管理機能のアーキテクチャとコンポーネント

- 25.1.3 セキュリティ・イベントおよび統計エントリのパージ

- 25.1.4 サーバー管理機能情報にアクセスするために使用されるアカウント

- 25.2 Fusion Middleware Controlを使用した統計収集の設定

- 25.2.1 Fusion Middleware Controlを使用したディレクトリ・サーバー統計収集の構成

- 25.2.2 Fusion Middleware Controlを使用した統計収集のためのユーザーの構成

- 25.3 Fusion Middleware Controlを使用した統計情報の表示

- 25.3.1 Oracle Internet Directoryホームページでの統計情報の表示

- 25.3.2 Oracle Internet Directory「パフォーマンス」ページでの情報の表示

- 25.4 Oracle Directory Services Managerホームページでの統計情報の表示

- 25.5 コマンド行を使用した統計収集の設定

- 25.5.1 健全性統計、一般統計およびパフォーマンス統計の属性の構成

- 25.5.2 セキュリティ・イベント追跡の構成

- 25.5.3 コマンド行からのユーザー統計収集の構成

- 25.5.4 コマンド行からのイベント・レベルの構成

- 25.5.5 コマンド行を使用した統計収集のためのユーザーの構成

- 25.6 OIDDIAGツールによる情報の表示

26 Oracle Internet Directoryのバックアップとリストア

第III部 拡張管理: セキュリティ

27 Secure Sockets Layer(SSL)の構成

- 27.1 Secure Sockets Layer(SSL)の構成の概要

- 27.1.1 サポートされている暗号スイート

- 27.1.2 サポートされているプロトコルのバージョン

- 27.1.3 SSL認証モード

- 27.1.4 11g リリース1(11.1.1)でのSSLの使用制限事項

- 27.1.5 Oracle Wallet

- 27.1.6 その他のコンポーネントとSSL

- 27.1.7 SSL相互運用性モード

- 27.1.8 StartTLS

- 27.2 Fusion Middleware Controlを使用したSSLの構成

- 27.2.1 Fusion Middleware Controlを使用したウォレットの作成

- 27.2.2 Fusion Middleware Controlを使用したSSLパラメータの構成

- 27.2.3 Fusion Middleware Controlを使用したSSLパラメータの設定

- 27.3 WLSTを使用したSSLの構成

- 27.4 LDAPコマンドを使用したSSLの構成

- 27.5 Oracle Directory Services Managerを使用したSSL接続のテスト

- 27.6 コマンド行によるSSL接続のテスト

- 27.6.1 暗号化のみのSSLのテスト

- 27.6.2 サーバー認証を必要とするSSLのテスト

- 27.6.3 クライアントおよびサーバー認証を必要とするSSLのテスト

- 27.7 SSL相互運用性モードの構成

28 データ・プライバシの構成

- 28.1 表領域の暗号化の概要

- 28.2 表領域の暗号化の有効化と無効化

- 28.3 Database VaultとOracle Internet Directoryの使用方法の概要

- 28.4 Oracle Database Vaultの構成によるOracle Internet Directoryデータの保護

- 28.4.1 Oracle Database Vaultの登録

- 28.4.2 Oracle Internet Directory用のDatabase Vaultレルムおよびポリシーの追加

- 28.4.3 Oracle Internet Directory用のOracle Database Vault構成の管理

- 28.4.4 Oracle Internet Directory用のDatabase Vaultポリシーの削除

- 28.4.5 Oracle Internet Directoryデータベース用のOracle Database Vaultの無効化

- 28.5 Database VaultとOracle Internet Directoryの使用方法のベスト・プラクティス

- 28.6 機密の属性の概要

- 28.6.1 機密の属性のリスト

- 28.6.2 機密の属性の暗号化アルゴリズム

- 28.7 受信した機密の属性のプライバシの構成

- 28.8 ハッシュ属性の概要

- 28.9 ハッシュ属性の構成

- 28.9.1 Fusion Middleware Controlを使用したハッシュ属性の構成

- 28.9.2 ldapmodifyを使用したハッシュ属性の構成

29 パスワード・ポリシーの管理

- 29.1 パスワード・ポリシーの管理の概要

- 29.1.1 パスワード・ポリシーとは

- 29.1.2 パスワード・ポリシーの作成および適用に必要な手順

- 29.1.3 細かなパスワード・ポリシー

- 29.1.4 デフォルトのパスワード・ポリシー

- 29.1.5 パスワード・ポリシーの属性

- 29.1.6 パスワード・ポリシー関連の操作属性

- 29.1.7 パスワード・ポリシー情報のディレクトリ・サーバー検証

- 29.1.8 パスワード・ポリシーのエラー・メッセージ

- 29.1.9 10g(10.1.4.0.1)より前のリリース

- 29.2 Oracle Directory Services Managerを使用したパスワード・ポリシーの管理

- 29.2.1 Oracle Directory Services Managerを使用したパスワード・ポリシーの表示

- 29.2.2 Oracle Directory Services Managerを使用したパスワード・ポリシーの変更

- 29.2.3 ODSMを使用したパスワード・ポリシーの作成およびサブツリーへの割当て

- 29.3 コマンド行ツールを使用したパスワード・ポリシーの管理

- 29.3.1 コマンド行ツールを使用したパスワード・ポリシーの表示

- 29.3.2 コマンド行ツールを使用した新規パスワード・ポリシーの作成

- 29.3.3 コマンド行ツールを使用したサブツリーへのパスワード・ポリシーの適用

- 29.3.4 コマンド行ツールを使用したパスワード・ポリシーの設定

- 29.3.5 コマンド行ツールを使用したパスワード・ポリシー・エントリの限定

- 29.3.6 コマンド行ツールを使用したOracle Internet Directoryの期限切れユーザーの判別

30 ディレクトリ・アクセス制御の管理

- 30.1 ディレクトリ・アクセス制御の管理の概要

- 30.1.1 アクセス制御管理の構造体

- 30.1.1.1 アクセス制御ポリシー・ポイント(ACP)

- 30.1.1.2 規定のアクセス制御のためのorclACI属性

- 30.1.1.3 エントリ・レベルのアクセス制御のためのorclEntryLevelACI属性

- 30.1.1.4 セキュリティ・グループ

- 30.1.2 アクセス制御情報のコンポーネント

- 30.1.2.1 オブジェクト: アクセス権を付与するオブジェクト

- 30.1.2.2 サブジェクト: アクセス権を付与する対象

- 30.1.2.3 操作: 付与するアクセス権の種類

- 30.1.3 LDAP操作のアクセス・レベル要件

- 30.1.4 ACL評価の動作

- 30.1.4.1 ACLの評価に使用される優先順位規則

- 30.1.4.2 同一オブジェクトに対する複数ACIの使用

- 30.1.4.3 ディレクトリ・オブジェクトに対する排他的アクセス権

- 30.1.4.4 グループの場合のACL評価

- 30.2 Oracle Directory Services Managerを使用したアクセス制御の管理

- 30.2.1 Oracle Directory Services Managerを使用したACPの表示

- 30.2.2 Oracle Directory Services Managerを使用したACPの追加

- 30.2.2.1 タスク1: ACPにするエントリの指定

- 30.2.2.2 タスク2: 構造型アクセス項目の構成

- 30.2.2.3 タスク3: コンテンツ・アクセス項目の構成

- 30.2.2.4 構造型アクセス項目またはコンテンツ・アクセス項目の削除

- 30.2.3 ODSMのアクセス制御管理を使用したACPの変更

- 30.2.4 ODSMのデータ・ブラウザを使用したACPの追加または変更

- 30.2.5 ODSMのデータ・ブラウザを使用したエントリ・レベルのアクセスの設定または変更

- 30.3 コマンド行ツールを使用したアクセス制御の管理

- 30.3.1 ユーザーが追加できるエントリの種類の制限

- 30.3.2 ldapmodifyを使用した継承可能なACPの設定

- 30.3.3 ldapmodifyを使用したエントリ・レベルのACIの設定

- 30.3.4 ldapmodifyを使用したLDIFファイルでのワイルド・カードの使用方法

- 30.3.5 識別名によるエントリの選択

- 30.3.6 属性セレクタとサブジェクト・セレクタの使用方法

- 30.3.7 読取り専用アクセス権の付与

- 30.3.8 グループ・エントリへの自己書込みアクセス権の付与

- 30.3.9 ポリシーの無視を禁止する完全な自律型ポリシーの定義

31 パスワード・ベリファイアの管理

- 31.1 Directoryに対する認証用パスワード・ベリファイアの概要

- 31.1.1 ユーザー・パスワード・ベリファイアおよびディレクトリに対する認証

- 31.1.2 ユーザー・パスワード・ベリファイアを作成するためのハッシング・スキーム

- 31.2 Directoryに対する認証用パスワード・ベリファイアのハッシング・スキームの管理

- 31.3 コンポーネントに対する認証用パスワード・ベリファイアの概要

- 31.3.1 Oracleコンポーネントに対する認証用パスワード・ベリファイアについて

- 31.3.2 Oracleコンポーネントに対する認証用パスワード・ベリファイアの格納用属性

- 31.3.3 Oracleコンポーネントのデフォルトのベリファイア

- 31.3.4 Oracleコンポーネントに対するパスワード検証の動作

- 31.4 ODSMを使用したOracleコンポーネント用パスワード・ベリファイア・プロファイルの管理

- 31.5 コマンド行ツールを使用したコンポーネント用パスワード・ベリファイア・プロファイルの管理

- 31.5.1 コマンド行ツールを使用したパスワード・ベリファイア・プロファイルの表示

- 31.5.2 例: コマンド行ツールを使用したパスワード・ベリファイア・プロファイルの変更

- 31.6 動的パラメータを使用したベリファイアの生成の概要

- 31.7 動的パスワード・ベリファイアを生成するためのOracle Internet Directoryの構成

32 Oracle Identity Managementの権限の委任

- 32.1 Oracle Identity Managementの権限の委任の概要

- 32.1.1 委任の仕組み

- 32.1.2 Oracle Fusion Middleware環境での委任

- 32.1.3 デフォルトの構成について

- 32.1.4 Oracleテクノロジ・スタックの管理権限

- 32.2 ユーザーおよびグループの管理権限の委任

- 32.2.1 ユーザーおよびグループのデータ管理権限の委任方法

- 32.2.2 ユーザー・データを管理するためのデフォルトの権限

- 32.2.2.1 レルムに対するユーザーの作成

- 32.2.2.2 ユーザー属性の変更

- 32.2.2.3 ユーザーの削除

- 32.2.2.4 ユーザー管理の委任

- 32.2.3 グループ・データを管理するためのデフォルトの権限

- 32.2.3.1 グループの作成

- 32.2.3.2 グループ属性の変更

- 32.2.3.3 グループの削除

- 32.2.3.4 グループ管理の委任

- 32.3 Oracleコンポーネントのデプロイメント権限の委任

- 32.3.1 デプロイメント権限の付与方法

- 32.3.2 Oracle Application Server管理者

- 32.3.3 ユーザー管理アプリケーション管理者

- 32.3.4 トラステッド・アプリケーション管理者

- 32.4 コンポーネントの実行時権限の委任

- 32.4.1 ユーザー・パスワードの読取りおよび変更を行うためのデフォルトの権限

- 32.4.2 ユーザー・パスワードを比較するためのデフォルトの権限

- 32.4.3 パスワード・ベリファイアを比較するためのデフォルトの権限

- 32.4.4 エンド・ユーザーのプロキシとなるためのデフォルトの権限

- 32.4.5 Oracleコンテキストを管理するためのデフォルトの権限

- 32.4.6 共通ユーザー属性を読み取るためのデフォルトの権限

- 32.4.7 共通グループ属性を読み取るためのデフォルトの権限

- 32.4.8 サービス・レジストリを読み取るためのデフォルトの権限

- 32.4.9 サービス・レジストリを管理するためのデフォルトの権限

33 認証の管理

- 33.1 認証の概要

- 33.1.1 直接認証

- 33.1.2 間接認証

- 33.1.3 外部認証

- 33.1.4 Simple Authentication and Security Layer(SASL)

- 33.1.4.1 SASL対応クライアントがMD5ダイジェストを使用してディレクトリ・サーバーに対して認証する方法

- 33.1.4.2 SASL対応クライアントが外部認証を使用してディレクトリ・サーバーに対して認証する方法

- 33.2 Fusion Middleware Controlを使用した証明書認証方式の構成

- 33.3 Fusion Middleware Controlを使用したSASL認証の構成

- 33.4 コマンド行ツールを使用した証明書認証方式の構成

- 33.5 コマンド行を使用したSASL認証の構成

- 33.6 匿名ユーザーによるバインドの概要

- 33.7 匿名ユーザーによるバインドの管理

- 33.7.1 Fusion Middleware Controlを使用した匿名ユーザーによるバインドの管理

- 33.7.2 コマンド行を使用した匿名ユーザーによるバインドの管理

- 33.8 Oracle Internet Directoryサーバーに対するユーザーのバインドの制限

- 33.9 未認証バインドの管理

- 33.9.1 未認証バインドの構成

- 33.9.2 コマンド行を使用した未認証バインドの管理

第IV部 拡張管理: ディレクトリ・デプロイメントの管理

34 レルムの計画、デプロイおよび管理

- 34.1 レルムの計画、デプロイおよび管理の概要

- 34.1.1 アイデンティティ管理レルムの計画

- 34.1.2 企業内デプロイメントにおけるアイデンティティ管理レルム

- 34.1.2.1 企業における単一アイデンティティ管理レルム

- 34.1.2.2 企業における複数アイデンティティ管理レルム

- 34.1.3 ホスティングされたデプロイメントにおけるアイデンティティ管理レルム

- 34.1.4 Oracle Internet Directoryでのアイデンティティ管理レルムの実装

- 34.1.5 デフォルトのディレクトリ情報ツリーおよびアイデンティティ管理レルム

- 34.2 デフォルトのアイデンティティ管理レルムのカスタマイズ

- 34.2.1 ユーザーおよびグループの既存の検索ベースを更新する手順

- 34.2.2 追加の検索ベースの設定

- 34.2.3 Oracle Single Sign-Onのリフレッシュ

- 34.2.4 プロビジョニング・プロファイルの再構成

- 34.3 ホスティングされたデプロイメントでのアイデンティティ管理レルムの追加作成

- 34.4 DITビューの作成

- 34.4.1 DITビューの構文

- 34.4.2 DITビューの条件

- 34.4.3 DITビューの例

35 Oracle Internet Directoryのチューニングとサイズ設定

36 ガベージ・コレクションの管理

- 36.1 ガベージ・コレクションの管理の概要

- 36.1.1 Oracle Internet Directoryガベージ・コレクション・フレームワークのコンポーネント

- 36.1.1.1 ガベージ・コレクション・プラグイン

- 36.1.1.2 バックグラウンドのデータベース・プロセス

- 36.1.2 Oracle Internet Directoryガベージ・コレクションの動作

- 36.1.3 ガベージ・コレクタ・エントリとOracle Internet Directory統計情報コレクタ・エントリ

- 36.1.4 変更ログのパージ

- 36.2 ガベージ・コレクション用のOracle Databaseタイムゾーンの設定

- 36.3 Oracle Internet Directoryガベージ・コレクタの変更

- 36.3.1 Oracle Directory Services Managerを使用したガベージ・コレクタの変更

- 36.3.2 コマンド行ツールを使用したガベージ・コレクタの変更

- 36.3.2.1 例1: ガベージ・コレクタの変更

- 36.3.2.2 例2: ガベージ・コレクタの変更ログの使用禁止

- 36.3.3 Oracle Internet Directory統計情報コレクタの変更

- 36.4 Oracle Internet Directoryガベージ・コレクタのロギングの管理

- 36.4.1 Oracle Internet Directoryガベージ・コレクタのロギングの有効化

- 36.4.2 Oracle Internet Directoryガベージ・コレクタのロギングの無効化

- 36.4.3 ガベージ・コレクションのロギングのモニタリング

- 36.5 時間ベースの変更ログのパージの構成

37 他のデータ・リポジトリからのデータの移行

- 37.1 他のデータ・リポジトリからのデータの移行の概要

- 37.2 LDAP準拠のディレクトリからのデータの移行

- 37.2.1 LDIFファイルとbulkloadを使用したLDAPデータの移行

- 37.2.2 syncProfileBootstrapを直接使用したLDAPデータの移行

- 37.2.3 LDIFファイルとsyncProfileBootstrapを使用したLDAPデータの移行

- 37.2.4 syncProfileBootstrap、bulkloadおよびLDIFファイルを使用したLDAPデータの移行

- 37.2.5 Oracle Directory Integration Platform Serverを使用したLDAPデータの移行

- 37.3 ユーザー・データのアプリケーション固有リポジトリからの移行

- 37.3.1 中間テンプレート・ファイル

- 37.3.2 アプリケーション・リポジトリ内のデータとディレクトリの既存データとの調停

- 37.3.3 アプリケーション固有のリポジトリからデータを移行するためのタスク

- 37.3.3.1 タスク1: 中間テンプレート・ファイルの作成

- 37.3.3.2 タスク2: OID移行ツールの実行

38 ディレクトリ・サーバー・チェーンの構成

- 38.1 サーバー・チェーンの構成の概要

- 38.1.1 外部ディレクトリ・サーバーのサポート

- 38.1.2 統合されたOracle製品

- 38.1.2.1 Oracle Single Sign-On 10g (10.1.4.3.0)以上

- 38.1.2.2 Enterprise User Security 10gのみ

- 38.1.3 サポートされる操作

- 38.1.4 サーバー・チェーンとレプリケーション

- 38.2 サーバー・チェーンの構成

- 38.2.1 Oracle Directory Services Managerを使用したサーバー・チェーンの構成

- 38.2.2 コマンド行からのサーバー・チェーンの構成

- 38.3 サーバー・チェーン構成エントリの作成

- 38.3.1 構成エントリ属性

- 38.3.2 ユーザー・コンテナとグループ・コンテナの要件

- 38.3.3 属性マッピング

- 38.3.4 Active Directoryの例

- 38.3.5 SSLを使用したActive Directoryの例

- 38.3.6 新規属性を使用したActive Directoryの例

- 38.3.7 Oracle Directory Server Enterprise EditionおよびSun Java System Directory Server(iPlanet)の例

- 38.3.8 SSLを使用したOracle Directory Server Enterprise EditionおよびSun Java System Directory Server(iPlanet)の例

- 38.3.9 eDirectoryの例

- 38.3.10 SSLを使用したeDirectoryの例

- 38.4 サーバー・チェーンのデバッグ

- 38.5 パスワード変更通知のActive Directoryプラグインの構成

39 DITマスキングの管理

- 39.1 マスキングの構成

- 39.2 マスキングの例

- 39.2.1 コンテナ名によるアクセス制限

- 39.2.2 エントリ・データによるアクセス制限

- 39.2.3 ディレクトリ全体からのコンテナに対するアクセスの禁止

第V部 拡張管理: ディレクトリ・レプリケーション

40 レプリケーションの設定

- 40.1 レプリケーションの設定の概要

- 40.1.1 レプリケーション転送メカニズム

- 40.1.2 レプリケーション設定方法

- 40.1.2.1 レプリケーション・ウィザード

- 40.1.2.2 コマンド行ツール

- 40.1.2.3 データベース・コピー・プロシージャ

- 40.1.3 ブートストラップ規則

- 40.1.4 レプリケーション承諾

- 40.1.5 その他のレプリケーション構成属性

- 40.1.6 レプリケーション・プロセスとアーキテクチャ

- 40.1.7 LDAPベースのレプリケーションの構成に関する規則

- 40.1.8 レプリケーションのセキュリティ

- 40.1.8.1 認証およびディレクトリ・レプリケーション・サーバー

- 40.1.8.2 Secure Sockets Layer(SSL)とOracle Internet Directoryレプリケーション

- 40.1.9 部分レプリケーションのためのLDAPレプリケーションのフィルタリング

- 40.1.9.1 LDAPレプリケーションのフィルタリングに含まれるネーミング・コンテキストと除外されるネーミング・コンテキスト

- 40.1.9.2 ネーミング・コンテキストを制御する属性

- 40.1.9.3 LDAPレプリケーションのフィルタリングの規則

- 40.1.9.4 LDAPレプリケーションのフィルタリングの例

- 40.1.9.5 ネーミング・コンテキストおよび属性の管理規則

- 40.1.9.6 部分レプリケーションのネーミング・コンテキストの最適化によるパフォーマンスの向上

- 40.2 アドバンスト・レプリケーション・ベースの承諾のLDAPベースの承諾への変換

- 40.3 レプリケーション・ウィザードを使用したLDAPベースのレプリケーション承諾の設定

- 40.4 Oracle Directory Services Managerを使用したレプリケーションのテスト

- 40.5 コマンド行を使用したLDAPベースのレプリケーションの設定

- 40.5.1 ldifwriteとbulkloadを使用したLDAPデータのコピー

- 40.5.2 カスタム設定を使用したLDAPベースのレプリカの設定

- 40.5.2.1 自動ブートストラップを使用したLDAPベースのレプリカの設定

- 40.5.2.2 ldifwriteツールを使用したLDAPベースのレプリカの設定

- 40.5.3 パスワード・ポリシーとファンアウト・レプリケーション

- 40.5.4 LDAPベースのレプリカの削除

- 40.5.4.1 タスク1: 削除するノードでのディレクトリ・レプリケーション・サーバーの停止

- 40.5.4.2 タスク2: レプリケーション・グループからのレプリカの削除

- 40.6 ファンアウトと組み合せたマルチマスター・レプリケーション・グループの設定

41 レプリケーション・フェイルオーバーの設定

- 41.1 レプリケーション・フェイルオーバーの概要

- 41.1.1 レプリケーション・フェイルオーバーに関する制限事項と警告

- 41.1.2 使用するレプリケーション・フェイルオーバーのタイプの決定

- 41.2 ステートレス・レプリケーション・フェイルオーバーの実行

- 41.2.1 タスク1: 関連ノードでのすべてのディレクトリ・レプリケーション・サーバーの停止

- 41.2.2 タスク2: 旧レプリケーション承諾の破棄と新規承諾の設定

- 41.2.3 タスク3: 最後に適用された変更番号の保存

- 41.2.4 タスク4: 新規サプライヤとコンシューマの比較および調整

- 41.2.5 タスク5: 新規承諾の最後に適用された変更番号の更新

- 41.2.6 タスク6: 旧サプライヤでの旧承諾のクリーンアップ

- 41.2.7 タスク7: 関連ノードでのすべてのディレクトリ・レプリケーション・サーバーの起動

- 41.3 時間ベース・レプリケーション・フェイルオーバーの実行

- 41.3.1 タスク1: 新規サプライヤでの変更ログ・ガベージ・コレクション・オブジェクトの構成

- 41.3.2 タスク2: 新規サプライヤの最後に適用された変更番号の保存

- 41.3.3 タスク3: 新規サプライヤでの変更ログ再生成の有効化

- 41.3.4 タスク4: 希望する期間が経過するのを待機

- 41.3.5 タスク5: 関連ノードでのすべてのディレクトリ・レプリケーション・サーバーの停止

- 41.3.6 タスク6: 旧レプリケーション承諾の破棄と新規承諾の設定

- 41.3.7 タスク7: 新規承諾の最後に適用された変更番号の更新

- 41.3.8 タスク8: 旧サプライヤでの旧承諾のクリーンアップ

- 41.3.9 タスク9: 関連ノードでのすべてのディレクトリ・レプリケーション・サーバーの起動

42 レプリケーション構成属性の管理

- 42.1 レプリケーション構成属性の概要

- 42.1.1 レプリケーション構成コンテナ

- 42.1.2 レプリカ・サブエントリ

- 42.1.3 レプリケーション承諾エントリ

- 42.1.3.1 レプリケーション承諾エントリの属性

- 42.1.3.2 Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーション承諾

- 42.1.3.3 LDAPレプリケーション承諾

- 42.1.3.4 双方向LDAPレプリケーション承諾

- 42.1.4 レプリケーションのネーミング・コンテキスト・コンテナ・エントリ

- 42.1.5 レプリケーションのネーミング・コンテキスト・オブジェクト・エントリ

- 42.1.6 レプリケーション構成セット

- 42.1.7 ディレクトリ内のレプリケーション構成オブジェクトの例

- 42.2 Fusion Middleware Controlを使用したレプリケーション構成属性の構成

- 42.2.1 「共有プロパティ」、「レプリケーション」タブの構成属性

- 42.2.2 レプリケーション・ウィザード・パラメータの構成

- 42.3 コマンド行からのレプリケーション構成属性の管理

43 レプリケーションの管理およびモニタリング

- 43.1 レプリケーションの管理およびモニタリングの概要

- 43.1.1 LDAPベースの部分レプリケーションでのレプリケート対象の変更

- 43.1.2 ワーカー・スレッドの管理

- 43.1.3 ディレクトリ・レプリケーションの変更ログ

- 43.1.4 ディレクトリ・レプリケーションの変更ログのパーティション化

- 43.1.4.1 変更ログのパーティション化の方法

- 43.1.4.2 変更ログのパーティション化の構成

- 43.1.5 管理者操作キュー

- 43.1.5.1 キューの管理

- 43.1.5.2 キュー統計

- 43.1.5.3 管理者操作キュー・ツールで処理されるエントリ数

- 43.1.6 パイロット・モード

- 43.1.7 Oracleレプリケーションにおける競合の解消

- 43.1.7.1 レプリケーション競合が発生するレベル

- 43.1.7.2 競合の自動解消

- 43.1.7.3 競合の自動解消の動作

- 43.2 ODSMおよびFusion Middleware Controlを使用したレプリケーションの管理およびモニタリング

- 43.2.1 Fusion Middleware Controlを使用した変更ログ生成の有効化または無効化

- 43.2.2 Oracle Directory Services Managerを使用したローカル変更ログの表示

- 43.2.3 レプリカのネーミング・コンテキスト・オブジェクトの表示および変更

- 43.2.4 レプリケーション・ウィザードを使用したレプリケーション設定の表示または変更

- 43.2.5 レプリケーション・ウィザードを使用したLDAPベースのレプリケーション承諾の削除

- 43.2.6 Fusion Middleware Controlを使用したレプリケーション属性の構成

- 43.2.7 Fusion Middleware Controlを使用したレプリケーション・サーバーのアクティブ化または非アクティブ化

- 43.2.8 Fusion Middleware Controlを使用したレプリケーションのデバッグ・レベルの構成

- 43.2.9 Fusion Middleware Controlを使用したレプリカ詳細の構成

- 43.2.10 Fusion Middleware Controlを使用したキュー統計の表示

- 43.2.11 Fusion Middleware Controlを使用した変更ログ処理の管理

- 43.2.12 Fusion Middleware Controlを使用した競合解消メッセージのモニタリング

- 43.3 コマンド行を使用したレプリケーションの管理およびモニタリング

- 43.3.1 コマンド行を使用した変更ログ生成の有効化と無効化

- 43.3.2 ldapsearchを使用した変更ログの表示

- 43.3.3 ldapmodifyを使用したレプリカ・サブエントリの属性の構成

- 43.3.4 remtoolを使用したレプリカのパイロット・モードの指定

- 43.3.5 ldapmodifyを使用したレプリケーション承諾の属性の構成

- 43.3.6 ldapmodifyを使用したレプリカのネーミング・コンテキスト・オブジェクト・パラメータの変更

- 43.3.7 ldapmodifyを使用したレプリケーション構成セットの属性の構成

- 43.3.8 コマンド行を使用した競合解消メッセージのモニタリング

- 43.3.9 管理者操作キューの管理

- 43.3.10 remtool -pthputを使用したディレクトリ・レプリケーション・グループでのレプリケーションの進行状況のモニタリング

- 43.3.11 remtoolを使用したキュー統計の表示およびレプリケーションの検証

- 43.3.12 管理者操作キュー・ツールで処理できるエントリの数の管理

- 43.3.13 アドバンスト・レプリケーションのレプリケーション管理者パスワードの変更

- 43.3.14 orclEntryExclusionFilter属性を使用したレプリケーション・フィルタリングの構成

- 43.4 一貫性のないデータのoidcmprecによる比較調整

- 43.4.1 競合の例

- 43.4.2 oidcmprecでサポートされる操作

- 43.4.3 oidcmprecからの出力

- 43.4.4 oidcmprecの動作

- 43.4.5 ソース・ディレクトリと宛先ディレクトリの設定

- 43.4.6 操作のDITの選択

- 43.4.7 操作属性の選択

- 43.4.8 変更ログ生成の制御

- 43.4.9 テキストまたはXMLパラメータ・ファイルの使用

- 43.4.10 ディレクトリ・スキーマの包含

- 43.4.11 事前に定義された競合解消規則の無視

- 43.4.12 ユーザー定義の比較調整操作の使用

- 43.4.13 oidcmprecツールの既知の制限事項

第VI部 拡張管理: ディレクトリ・プラグイン

44 カスタマイズされたパスワード・ポリシー・プラグインの構成

- 44.1 カスタマイズされたパスワード・ポリシー・プラグインの構成の概要

- 44.2 カスタマイズされたパスワード・ポリシー・プラグインのインストール、構成および有効化

- 44.2.1 PL/SQLプログラムのロードおよび登録

- 44.2.2 パスワード・ポリシー・プラグインのコード化

- 44.2.3 パスワード・ポリシー・プラグインのデバッグ

- 44.2.4 サンプルPL/SQLパッケージpluginpkg.sqlの内容

45 Oracle Internet Directoryサーバー・プラグインの開発

- 45.1 Oracle Internet Directoryサーバー・プラグインの開発の概要

- 45.1.1 JVMへのオプション渡し

- 45.1.2 サーバー・プラグインの言語のサポート

- 45.1.3 サーバー・プラグインの前提条件

- 45.1.4 サーバー・プラグインの利点

- 45.1.5 プラグイン設計のガイドライン

- 45.1.6 サーバー・プラグイン・フレームワーク

- 45.1.7 ディレクトリでサポートされているLDAP操作およびタイミング

- 45.1.7.1 操作前サーバー・プラグイン

- 45.1.7.2 操作後サーバー・プラグイン

- 45.1.7.3 操作時サーバー・プラグイン

- 45.1.7.4 操作時置換サーバー・プラグイン

- 45.1.8 レプリケーション環境でのプラグインの使用

- 45.2 プラグインの作成

- 45.3 コマンド行でのプラグインの登録

- 45.3.1 プラグイン構成エントリの作成

- 45.3.2 コマンド行ツールによるプラグイン構成エントリの追加

- 45.4 Oracle Directory Services ManagerおよびOracle Enterprise Manager Fusion Middleware Controlを使用したプラグインの管理

- 45.4.1 Oracle Directory Services Managerを使用した新しいプラグインの作成

- 45.4.2 Oracle Directory Services Managerによるプラグインの登録

- 45.4.3 Oracle Directory Services Managerによるプラグインの編集

- 45.4.4 Oracle Directory Services Managerによるプラグインの削除

- 45.4.5 Oracle Enterprise Manager Fusion Middleware Controlを使用したJVMオプションの管理

46 カスタマイズされた外部認証プラグインの構成

- 46.1 カスタマイズされた外部認証プラグインの構成の概要

- 46.2 外部認証プラグインのインストール、構成および有効化

- 46.3 外部認証プラグインのデバッグ

- 46.4 PL/SQLパッケージoidexaup.sqlの作成

第VII部 付録

A 10gと11gの違い

- A.1 インスタンスの作成とプロセスの管理

- A.2 構成属性の場所

- A.3 デフォルト・ポート

- A.4 サーバー・デバッグの有効化

- A.5 コマンド行ツール

- A.6 パス名

- A.7 グラフィカル・ユーザー・インタフェース

- A.8 監査

- A.9 参照整合性

- A.10 サーバー・チェーン

- A.11 レプリケーション

- A.12 Oracle Directory Integration Platform

- A.13 Oracle Single Sign-OnとOracle Delegated Administration Services

- A.14 Javaコンテナ

B OIDCTLを使用したOracle Internet Directoryインスタンスの管理

- B.1 OIDCTLを使用したOracle Internet Directoryの管理の概要

- B.2 OIDCTLを使用したOracle Internet Directoryサーバー・インスタンスの作成と起動

- B.3 OIDCTLを使用したOracle Internet Directoryサーバー・インスタンスの停止

- B.4 OIDCTLを使用したOracle Internet Directoryサーバー・インスタンスの起動

- B.5 OIDCTLを使用したステータス情報の表示

- B.6 OIDCTLを使用したOracle Internet Directoryサーバー・インスタンスの削除

C Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーションの設定

- C.1 Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーションの設定の概要

- C.1.1 データベース・バージョンの互換性

- C.1.2 部分レプリケーションのためのアドバンスト・レプリケーションのフィルタリング

- C.1.2.1 除外されるネーミング・コンテキスト

- C.1.2.2 アドバンスト・レプリケーションのフィルタリングの規則

- C.2 アドバンスト・レプリケーション・ベースのレプリケーションの設定

- C.2.1 アドバンスト・レプリケーションの設定の規則

- C.2.2 アドバンスト・レプリケーション・ベースのマルチマスター・レプリケーション・グループの設定

- C.2.2.1 タスク1: マスター定義サイト(MDS)へのOracle Internet Directoryのインストール

- C.2.2.2 タスク2: リモート・マスター・サイト(RMS)へのOracle Internet Directoryのインストール

- C.2.2.3 タスク3: ディレクトリ・レプリケーション・グループ用のアドバンスト・レプリケーションの設定

- C.2.2.4 タスク4(オプション): ディレクトリへのデータのロード

- C.2.2.5 タスク5: 全ノードでOracleディレクトリ・サーバー・インスタンスが起動していることの確認

- C.2.2.6 タスク6: DRGの全ノードでのレプリケーション・サーバーの起動

- C.2.2.7 タスク7: ディレクトリ・レプリケーションのテスト

- C.2.3 アドバンスト・レプリケーション・ベースのマルチマスター・レプリケーションのノードの追加

- C.2.3.1 Oracle Net Services環境の準備

- C.2.3.2 タスク1: 全ノードでのディレクトリ・レプリケーション・サーバーの停止

- C.2.3.3 タスク2: スポンサ・ノードの特定とOracle Internet Directoryのインストール

- C.2.3.4 タスク3: スポンサ・ノードの読取り専用モードへの切替え

- C.2.3.5 タスク4: ldifwriteを使用したスポンサ・ノードのバックアップ

- C.2.3.6 タスク5: アドバンスト・レプリケーションのノード追加設定の実行

- C.2.3.7 タスク6: スポンサ・ノードの更新可能モードへの切替え

- C.2.3.8 タスク7: 新規ノード以外の全ノードでのディレクトリ・レプリケーション・サーバーの起動

- C.2.3.9 タスク8: bulkloadを使用した新規ノードへのデータのロード

- C.2.3.10 タスク9: 新規ノードでのディレクトリ・サーバーの起動

- C.2.3.11 タスク10: 新規ノードでのディレクトリ・レプリケーション・サーバーの起動

- C.2.4 マルチマスター・レプリケーション・グループからのノードの削除

- C.2.4.1 タスク1: 全ノードでのディレクトリ・レプリケーション・サーバーの停止

- C.2.4.2 タスク2: 削除するノード内の全Oracle Internet Directoryプロセスの停止

- C.2.4.3 タスク3: マスター定義サイトからのノードの削除

- C.2.4.4 タスク4: 全ノードでのディレクトリ・レプリケーション・サーバーの起動

D レプリケーションの動作

- D.1 Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーションの機能

- D.2 Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーションのアーキテクチャ

- D.3 LDAPベースのレプリケーションのアーキテクチャ

- D.4 LDAPのレプリカ状態

- D.5 レプリケーション・プロセス

- D.5.1 マルチマスター・レプリケーション・プロセスがコンシューマに新規エントリを追加する動作

- D.5.2 マルチマスター・レプリケーション・プロセスがエントリを削除する動作

- D.5.3 マルチマスター・レプリケーション・プロセスがエントリを変更する動作

- D.5.4 マルチマスター・レプリケーション・プロセスが相対識別名を変更する動作

- D.5.5 マルチマスター・レプリケーション・プロセスが識別名を変更する動作

E Javaサーバー・プラグイン開発者リファレンス

- E.1 Javaプラグインの利点

- E.2 Javaプラグインの設定

- E.3 JavaプラグインAPI

- E.3.1 サーバーとプラグイン間の通信

- E.3.2 Javaプラグインの構造

- E.3.3 PluginDetail

- E.3.3.1 Server

- E.3.3.2 LdapBaseEntry

- E.3.3.3 LdapOperation

- E.3.3.4 PluginFlexfield

- E.3.4 PluginResult

- E.3.5 ServerPluginインタフェース

- E.3.5.1 LdapbindのServerPluginメソッド

- E.3.5.2 LdapcompareのServerPluginメソッド

- E.3.5.3 LdapaddのServerPluginメソッド

- E.3.5.4 LdapmodifyのServerPluginメソッド

- E.3.5.5 LdapmoddnのServerPluginメソッド

- E.3.5.6 LdapsearchのServerPluginメソッド

- E.3.5.7 LdapdeleteのServerPluginメソッド

- E.4 Javaプラグイン・エラーおよび例外処理

- E.4.1 ランタイム例外の例

- E.4.2 ランタイム・エラーの例

- E.4.3 PluginExceptionの例

- E.5 Javaプラグインのデバッグおよびロギング

- E.6 Javaプラグインの例

- E.6.1 例1: パスワード検証プラグイン

- E.6.1.1 パスワード検証プラグインの構成エントリ

- E.6.1.2 パスワード検証プラグインのコード例

- E.6.2 例2: Active Directoryの外部認証プラグイン

- E.6.2.1 外部認証プラグインの構成エントリ

- E.6.2.2 外部認証プラグインのコード

F PL/SQLサーバー・プラグイン開発者リファレンス

- F.1 PL/SQLサーバー・プラグインの設計、作成および使用

- F.1.1 PL/SQLプラグインの注意事項

- F.1.1.1 PL/SQLプラグイン操作のタイプ

- F.1.1.2 PL/SQLプラグインの名前付け

- F.1.2 PL/SQLプラグインの作成

- F.1.2.1 プラグイン・モジュール・インタフェースのパッケージ仕様

- F.1.3 PL/SQLプラグインのコンパイル

- F.1.3.1 依存性

- F.1.3.2 プラグインの再コンパイル

- F.1.4 PL/SQLプラグインの管理

- F.1.4.1 プラグインの変更

- F.1.4.2 プラグインのデバッグ

- F.1.5 PL/SQLプラグインの有効化と無効化

- F.1.6 PL/SQLプラグインにおける例外処理

- F.1.6.1 エラー処理

- F.1.6.2 Oracle Internet Directoryとプラグインとの間のプログラム制御処理

- F.1.7 PL/SQLプラグインLDAP API

- F.1.8 PL/SQLプラグインおよびデータベース・ツール

- F.1.9 PL/SQLプラグインのセキュリティ

- F.1.10 PL/SQLプラグインのデバッグ

- F.1.11 PL/SQLプラグインLDAP APIの仕様

- F.2 PL/SQLプラグインの例

- F.2.1 例1: 検索問合せの記録

- F.2.2 例2: 2つのDITの同期化

- F.3 PL/SQLプラグイン・フレームワークでのバイナリ・サポート

- F.3.1 ldapmodifyでのバイナリ操作

- F.3.2 ldapaddでのバイナリ操作

- F.3.3 ldapcompareでのバイナリ操作

- F.4 データベース・オブジェクト・タイプの定義

- F.5 PL/SQLプラグイン・プロシージャの仕様

G LDAPフィルタ定義

H アクセス制御ディレクティブ書式

- H.1 orclACIのスキーマ

- H.2 orclEntryLevelACIのスキーマ

I ディレクトリにおけるグローバリゼーション・サポート

- I.1 文字セットおよびディレクトリについて

- I.1.1 Unicodeについて

- I.1.2 OracleとUTF-8について

- I.1.3 Oracle Internet Directoryのアップグレード時のUTF8からAL32UTF8への移行

- I.2 環境変数NLS_LANG

- I.3 非AL32UTF8データベースの使用方法

- I.4 LDIFファイルでのグローバリゼーション・サポートの使用方法

- I.4.1 ASCII文字列のみを含むLDIFファイル

- I.4.2 UTF-8エンコーディング文字列を含むLDIFファイル

- I.4.2.1 ケース1: ネイティブ文字列(非UTF-8)

- I.4.2.2 ケース2: UTF-8文字列

- I.4.2.3 ケース3: BASE64でエンコードされたUTF-8文字列

- I.4.2.4 ケース4: BASE64でエンコードされたネイティブ文字列

- I.5 コマンド行LDAPツールでのグローバリゼーション・サポートの使用方法

- I.5.1 各ツールを使用するときの-E引数の指定

- I.5.2 例: コマンド行LDAPツールでの-E引数の使用方法

- I.6 クライアント環境におけるNLS_LANGの設定

- I.7 バルク・ツールでのグローバリゼーション・サポートの使用方法

- I.7.1 bulkloadでのグローバリゼーション・サポートの使用方法

- I.7.2 ldifwriteでのグローバリゼーション・サポートの使用方法

- I.7.3 bulkdeleteでのグローバリゼーション・サポートの使用方法

- I.7.4 bulkmodifyでのグローバリゼーション・サポートの使用方法

J ユーザーおよびグループの作成ベースおよび検索ベースに対するアクセス制御の設定

- J.1 ユーザー検索ベースおよびユーザー作成ベースに対するアクセス制御の設定

- J.2 グループ検索ベースおよびグループ作成ベースに対するアクセス制御の設定

K ディレクトリでのユーザー証明書の検索

- K.1 証明書のマッピング

- K.2 検索タイプ

L データベース・コピー・プロシージャを使用したディレクトリ・ノードの追加

- L.1 定義

- L.2 前提条件

- L.3 スポンサ・ディレクトリ・サイトの環境

- L.4 新規ディレクトリ・サイトの環境

- L.5 ディレクトリ・ノードの追加

M Oracle Authentication Services for Operating Systems

N Oracle Internet DirectoryでサポートされているRFC

O Oracle Directory Services ManagerのJavaキーストアの管理

- O.1 ODSMのJavaキーストアの管理の概要

- O.2 ODSMのJavaキーストア・パスワードの取得

- O.2.1 Enterprise Manager Fusion Middleware Controlの使用

- O.2.2 Pythonスクリプトの使用

- O.3 odsm.cer Javaキーストアの内容のリスト

- O.4 期限が切れた証明書の削除

- O.4.1 証明書の有効期限の決定

- O.4.2 証明書の削除

P Oracleスタックの起動と停止

- P.1 スタックの起動

- P.2 スタックの停止

Q ローリング・アップグレードの実行

- Q.1 ローリング・アップグレードの前提条件

- Q.2 ローリング・アップグレードの実行

- Q.3 ローリング・アップグレード例

R Oracle Internet Directoryに関するトラブルシューティング

- R.1 問題と解決方法

- R.1.1 インストール時のエラー

- R.1.2 Oracleデータベース・サーバー・エラー

- R.1.2.1 Oracleデータベース・サーバー接続が停止している

- R.1.2.2 クライアント接続の中断が原因のOracleデータベース・サーバー・エラー

- R.1.2.3 スキーマ変更が原因のOracleデータベース・サーバー・エラー

- R.1.2.4 Oracle Database TNSリスナー・エラー(ORA-12520)

- R.1.3 ディレクトリ・サーバーのエラー・メッセージとその原因

- R.1.3.1 不適切な認証エラー

- R.1.3.2 ユーザーまたはグループを編集したか、レルムを作成したことが原因の制約違反エラー

- R.1.3.3 Oracleディレクトリ・サーバーから戻される標準エラー・メッセージ

- R.1.3.4 ディレクトリ・サーバーのその他のエラー・メッセージ

- R.1.4 Oracle Internet Directoryのクラッシュ時のコア・ダンプとスタック・トレースの取得

- R.1.5 TCP/IPの問題

- R.1.5.1 Windows 2003 Server上でサーバーの可用性をモニタリングするときはTCPベースのモニタリングを使用しない

- R.1.5.2 DaimondCS Port Explorerをインストールしない

- R.1.6 パスワード・ポリシーに関するトラブルシューティング

- R.1.6.1 パスワード・ポリシーが適用されない

- R.1.6.2 パスワード・ポリシーのエラー・メッセージ

- R.1.7 ディレクトリのパフォーマンスに関するトラブルシューティング

- R.1.7.1 LDAP検索のパフォーマンスが不十分

- R.1.7.2 LDAP追加または変更のパフォーマンスが不十分

- R.1.7.3 Oracleデータベース・サーバーのパフォーマンスが不十分

- R.1.7.4 AWRレポートを使用したデータベース・パフォーマンス問題に関するトラブルシューティング

- R.1.8 ポート構成に関するトラブルシューティング

- R.1.9 opmnctlを使用したOracle Internet Directoryコンポーネントの作成に関するトラブルシューティング

- R.1.10 Oracle Internet Directoryの起動に関するトラブルシューティング

- R.1.10.1 Oracle Internet Directoryが停止している

- R.1.10.2 Oracle Internet Directoryが読取り専用

- R.1.11 クライアント接続の中断が原因のOracle Internet Directoryエラー

- R.1.12 ディレクトリ・サーバーの起動、停止および再起動に関するトラブルシューティング

- R.1.12.1 ディレクトリ・サーバー・インスタンスを起動、停止および再起動するためのツールについて

- R.1.12.2 ディレクトリ・サーバーの起動、停止および再起動に関する問題

- R.1.13 Oracle Internet Directoryレプリケーションに関するトラブルシューティング

- R.1.13.1 レプリケーション・サーバーが起動しない

- R.1.13.2 レプリケーションのブートストラップに関するエラー

- R.1.13.3 変更がレプリケートされない

- R.1.13.4 レプリケーション操作の停止

- R.1.14 変更ログのガベージ・コレクションに関するトラブルシューティング

- R.1.15 動的パスワード・ベリファイアに関するトラブルシューティング

- R.1.16 Oracle Internet Directoryパスワード・ウォレットに関するトラブルシューティング

- R.1.16.1 Oracle Internet Directoryサーバーが起動しない

- R.1.16.2 パスワードが同期されない

- R.1.17 bulkloadに関するトラブルシューティング

- R.1.18 bulkdelete、bulkmodifyおよびldifwriteに関するトラブルシューティング

- R.1.19 catalogに関するトラブルシューティング

- R.1.20 remtoolに関するトラブルシューティング

- R.1.21 サーバー・チェーンに関するトラブルシューティング

- R.1.22 バージョン情報の表示

- R.1.23 Fusion Middleware ControlとWLSTに関するトラブルシューティング

- R.1.24 Oracle Directory Services Managerに関するトラブルシューティング

- R.1.24.1 Fusion Middleware ControlからODSMを起動できない

- R.1.24.2 複数のNICおよびDHCPが有効な環境でFusion Middleware ControlからODSMを起動できない

- R.1.24.3 様々なフェイルオーバーの問題

- R.1.24.4 ODSMがエラー・メッセージを表示する

- R.1.24.5 カーソルがフォーカスを失う

- R.1.25 ロックされたユーザー・アカウントに関するトラブルシューティング

- R.1.26 ポリシー・ストアの移行に関するトラブルシューティング

- R.1.26.1 Oracle ZFSでのポリシー・ストアの移行に関するトラブルシューティング

- R.2 その他の情報

- R.2.1 Oracle Internet Directoryデバッグ・ログの提供

図一覧

- 1-1 Oracle Internet Directoryの概要

- 3-1 一般的なOracle Internet Directoryのノード

- 3-2 Oracleディレクトリ・サーバー・インスタンスのアーキテクチャ

- 3-3 ディレクトリ情報ツリー

- 3-4 Anne Smithのエントリの属性

- 3-5 適切なネーミング・コンテキストと不適切なネーミング・コンテキスト

- 3-6 パーティション化されたディレクトリ

- 3-7 ナレッジ参照を使用したネーミング・コンテキストの指示

- 3-8 DIT内のリソース・アクセス情報およびリソース・タイプ情報の配置

- 4-1 Oracle Internet Directoryのプロセス制御

- 5-1 ディレクトリ情報ツリーの計画

- 6-1 レプリケート・ディレクトリ

- 6-2 部分レプリケーションの例

- 6-3 単一マスター・レプリケーションの例

- 6-4 マルチマスター・レプリケーションの例

- 6-5 ファンアウト・レプリケーションの例

- 6-6 ファンアウトを使用するマルチマスター・レプリケーションの例

- 8-1 2つのインスタンス固有の構成エントリを示すDIT

- 8-2 Oracle Internet Directoryのプロセス制御

- 18-1 別名エントリの例

- 18-2 My_file.ldifの作成結果を示すツリー

- 19-1 ディレクトリ情報ツリーの例

- 21-1 subSchemaSubentryタイプのエントリでのスキーマ・コンポーネントの位置

- 25-1 Oracle Internet Directoryサーバー管理機能のアーキテクチャ

- 29-1 パスワード・ポリシー・エントリの位置

- 29-2 パスワード・ポリシーの識別名が移入されたpwdPolicyサブエントリ属性

- 31-1 パスワード・ベリファイア・プロファイル・エントリの位置

- 31-2 認証モデル

- 31-3 パスワード検証の動作

- 32-1 Oracle Fusion Middleware環境での委任の流れ

- 33-1 間接認証

- 34-1 アイデンティティ管理レルムの例

- 34-2 企業での使用例: 単一アイデンティティ管理レルム

- 34-3 企業での使用例: 複数アイデンティティ管理レルム

- 34-4 ホスティングされたデプロイメントでの使用例

- 34-5 デフォルトのアイデンティティ管理レルム

- 36-1 例: 変更ログ・エントリのガベージ・コレクション

- 36-2 DIT内のガベージ・コレクション・エントリ

- 37-1 LDIFファイルとbulkloadの使用

- 37-2 syncProfileBootstrapの直接の使用

- 37-3 LDIFファイルとsyncProfileBootstrapの使用

- 37-4 syncProfileBootstrap、bulkloadおよびLDIFファイルの使用

- 37-5 Oracle Directory Integration Serverの使用

- 37-6 中間ユーザー・ファイルの構造

- 40-1 ネーミング・コンテキストのサンプル

- 40-2 ネーミング・コンテキスト・オブジェクト1

- 40-3 ネーミング・コンテキスト・オブジェクト2

- 40-4 ネーミング・コンテキスト・オブジェクトの1と2を組み合せた結果

- 40-5 ネーミング・コンテキスト・オブジェクト3

- 40-6 ネーミング・コンテキスト・オブジェクト4

- 40-7 ネーミング・コンテキスト・オブジェクトの3と4を組み合せた結果

- 40-8 ネーミング・コンテキスト・オブジェクト5

- 40-9 ネーミング・コンテキスト・オブジェクト6

- 40-10 ネーミング・コンテキスト・オブジェクト7

- 40-11 ファンアウト・レプリケーションの例

- 41-1 レプリケーション・フェイルオーバーの使用例

- 41-2 LDAPにより旧サプライヤに接続されるコンシューマと新規サプライヤ

- 41-3 同じアドバンスト・レプリケーション・グループ内の新旧のサプライヤ

- 41-4 レプリカ・タイプを維持するフェイルオーバー

- 41-5 接続レプリカすべての比較および調整

- 42-1 例: マルチマスター・レプリケーションおよびファンアウト・レプリケーション

- 42-2 例: ノードCについてのレプリケーション構成エントリ

- 42-3 例: ノードDについてのレプリケーション構成エントリ

- 45-1 Oracle Internet Directoryプラグイン・フレームワーク

- B-1 2つのインスタンスで構成されるコンポーネント

- C-1 ネーミング・コンテキスト・コンテナおよびオブジェクトの例

- D-1 アドバンスト・レプリケーション・プロセス

- D-2 LDAPレプリケーション・プロセス

- E-1 サーバーとJavaプラグインの間の通信

- O-1 getPortableCredential操作

- O-2 getPortableCredential操作

表一覧

- 1-1 オンライン・ディレクトリとリレーショナル・データベースの比較

- 3-1 Oracle Internet Directoryのノード

- 3-2 新規エントリごとに作成される属性

- 3-3 一般的なLDAP属性

- 4-1 ODS_PROCESS_STATUS表のプロセス制御項目

- 6-1 完全または部分レプリケーション

- 6-2 レプリケーションの方向

- 6-3 転送プロトコル

- 6-4 ディレクトリ・レプリケーション・グループのタイプ

- 6-5 ディレクトリ・レプリケーション・グループでのノード間のデータ転送のタイプ

- 7-1 「Oracle Internet Directory 」メニューの使用

- 8-1 コンポーネント登録の更新が必要な属性変更

- 9-1 インスタンス固有の構成エントリの属性

- 9-2 DSA構成エントリの属性

- 9-3 DSEの属性

- 9-4 「サーバー・プロパティ」ページ、「一般」タブの構成属性

- 9-5 「サーバー・プロパティ」ページ、「パフォーマンス」タブの構成属性

- 9-6 「共有プロパティ」、「一般」タブの構成属性

- 9-7 Oracle Internet Directoryに関連するMBean

- 12-1 「共有プロパティ」、「スーパーユーザー・パスワードの変更」タブの構成属性

- 14-1 Connect ByアサーションのためのorclDynamicGroup属性

- 14-2 静的グループと動的グループについての考慮事項

- 17-1 計算属性のルールで使用される構文要素

- 18-1 別名エントリによるディレクトリの検索のフラグ

- 18-2 エントリ別名間接参照メッセージ

- 19-1 属性一意性制約エントリ

- 21-1 例で使用されている属性別名

- 21-2 コンテンツ・ルールのパラメータ

- 23-1 Oracle Internet Directoryの監査構成属性

- 23-2 Fusion Middleware Controlの監査構成属性

- 24-1 Oracle Internet Directoryログ・ファイルの位置

- 24-2 「サーバー・プロパティ」ページ、「ロギング」タブの構成属性

- 24-3 OrclDebugFlagの値

- 24-4 orcldebugop属性を設定するためのデバッグ操作

- 25-1 Oracle Internet Directoryサーバー管理機能のコンポーネント

- 25-2「サーバー・プロパティ」ページ、「統計」タブの構成属性

- 25-3 orcloptracklevelの値

- 25-4 各orcloptracklevel値により記録されるメトリック

- 25-5 イベント・レベル

- 27-1 Oracle Internet DirectoryでサポートされるSSL暗号化スイート

- 27-2 プロトコル・マッピング

- 27-3 SSL認証モード

- 27-4 Fusion Middleware ControlのSSL関連の属性

- 27-5 SSL属性

- 28-1 orclencryptedattributesに格納されている機密の属性

- 28-2 orclhashedattributesの属性に対するLDAP操作およびバルク操作

- 29-1 パスワード・ポリシーの属性

- 29-2 パスワード・ポリシー関連の操作属性

- 30-1 サンプル・セキュリティ・グループ

- 30-2 アクセスのタイプ

- 30-3 LDAP操作および各操作の実行に必要なアクセス権

- 30-4 ACL評価時の属性の状態

- 30-5 例で使用される識別名

- 31-1 ユーザー・エントリにパスワード・ベリファイアを格納するための属性

- 32-1 すべての人および各ユーザーに付与されるデフォルトの権限

- 32-2 Oracleテクノロジ・スタックの管理権限

- 32-3 サブスクライバDASユーザー作成グループの特性

- 32-4 サブスクライバDASユーザー編集グループの特性

- 32-5 DASユーザー削除グループの特性

- 32-6 ユーザー権限割当てグループの特性

- 32-7 グループ作成グループの特性

- 32-8 グループ編集グループの特性

- 32-9 グループ削除グループの特性

- 32-10 グループ権限割当てグループの特性

- 32-11 Oracle Application Server管理者グループの特性

- 32-12 ユーザー管理アプリケーション管理者グループの特性

- 32-13 トラステッド・アプリケーション管理者グループの特性

- 32-14 ユーザー・セキュリティ管理者グループの特性

- 32-15 認証サービス・グループの特性

- 32-16 ベリファイア・サービス・グループの特性

- 32-17 ユーザー・プロキシ権限グループの特性

- 32-18 Oracleコンテキスト管理者グループの特性

- 32-19 共通ユーザー属性グループの特性

- 32-20 共通グループ属性グループの特性

- 32-21 サービス・レジストリのビューア・グループの特性

- 32-22 共通グループ属性グループの特性

- 33-1 「サーバー・プロパティ」、「SASL」タブの構成属性

- 33-2 SASL認証属性

- 33-3 SASL認証モード

- 33-4 orclanonymousbindsflagの値とディレクトリ・サーバーの動作

- 34-1 Oracle Identity Managementオブジェクト

- 34-2 デフォルトのアイデンティティ管理レルムのカスタマイズ

- 34-3 DITビューの構文

- 37-1 bulkloadとsyncProfileBootstrapの機能

- 37-2 ユーザー・エントリの必須属性

- 38-1 サーバー・チェーンの構成エントリ属性

- 38-2 Active Directoryに対するデフォルトの属性マッピング

- 38-3 Sun Java System Directory Serverに対するデフォルトの属性マッピング

- 38-4 Novell eDirectoryに対するデフォルトの属性マッピング

- 39-1 構成属性のマスキング

- 40-1 ldifwrite/bulkloadを使用したデータ移行と自動ブートストラップを使用したデータ移行の比較

- 40-2 OIDUpgradePasswordPoliciesに対するコマンド行パラメータ

- 40-3 部分レプリケーション・デプロイメント例におけるノード

- 42-1 レプリカ・サブエントリの属性

- 42-2 レプリケーション承諾エントリの属性

- 42-3 レプリケーション・ネーミング・コンテキスト・エントリの属性

- 42-4 レプリケーション構成セットの属性

- 42-5 「共有プロパティ」、「レプリケーション」タブの構成属性

- 42-6 レプリケーション・スケジュール属性

- 43-1 ワーカー・スレッドを制御する構成属性

- 43-2 レプリケーション競合のタイプ

- 43-3 「変更ログ」ページのプロパティ

- 43-4 「共有プロパティ」、「レプリケーション」タブの「レプリケーション・コンフィグセット」の属性

- 43-5 「共有プロパティ」、「レプリケーション」タブの「レプリケーション・サーバー・ステータス」の属性

- 43-6 「共有プロパティ」、「レプリケーション」タブの「レプリカ詳細」

- 43-7 変更ログの重要な属性

- 43-8 レプリカ・サブエントリの属性

- 43-9 レプリケーション承諾のオプション

- 43-10 レプリケーション構成の属性

- 43-11 レプリケーションのデバッグ・レベル

- 43-12 競合解消メッセージ

- 45-1 プラグイン構成オブジェクトおよび属性

- A-1 10gの属性の新しい場所

- A-2 変更されたパス名の例

- D-1 LDAPのレプリカ状態

- E-1 プラグイン名および対応するパス

- E-2 各LDAP操作のDN情報の内容

- E-3 Operation Result Codeの動作

- E-4 LdapOperationのサブクラスおよびクラス固有の情報

- E-5 各プラグインのタイミングに対するLdapEntry情報の動作

- E-6 各プラグインのタイミングに対するAttributeNameの動作

- E-7 各プラグインのタイミングに対するAttribute Valueの動作

- E-8 各プラグインのタイミングに対するDelete DNの動作

- E-9 各プラグインのタイミングに対するNew Parent DN情報の動作

- E-10 各プラグインのタイミングに対するNew Relative DN情報の動作

- E-11 各プラグインのタイミングに対するDelete Old RDN情報の動作

- E-12 各プラグインのタイミングに対するLdapModification情報の動作

- E-13 各プラグインのタイミングに対するRequired Attributesの動作

- E-14 各プラグインのタイミングに対するScopeの動作

- E-15 各プラグインのタイミングに対するSearchResultSetの動作

- E-16 Javaプラグインのロギングのデバッグ・レベル

- F-1 プラグイン・モジュール・インタフェース

- F-2 操作ベースと属性ベースのプラグイン・プロシージャのシグネチャ

- F-3 プラグインのリターン・コードの有効な値

- F-4 プラグイン例外発生時のプログラム制御処理

- F-5 LDAP操作障害時のプログラム制御処理

- I-1 Unicodeの実装

- I-2 NLS_LANGパラメータのコンポーネント

- I-3 例: コマンド行ツールでの-E引数の使用方法

- N-1 サポートされているRFC

- R-1 標準エラー・メッセージ

- R-2 その他のエラー・メッセージ

- R-3 パスワード・ポリシー違反のエラー・メッセージ

- R-4 動的パスワード・ベリファイアのエラー・メッセージ

はじめに

『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』へようこそ。この章に含まれる内容は次のとおりです。

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

対象読者

このマニュアルは、Oracle Internet Directoryの管理タスクを実行するユーザーを対象としています。ラインモード・コマンドと例を理解するには、UNIXオペレーティング・システムまたはMicrosoft Windowsオペレーティング・システムをよく理解している必要があります。コマンド行ユーティリティを使用してすべてのタスクを実行でき、オペレーティング・システムに依存しないOracle Directory Services ManagerおよびOracle Enterprise Manager Fusion Middleware Controlを使用してほとんどのタスクを実行できます。

このマニュアルを使用するには、Lightweight Directory Access Protocol(LDAP)をある程度理解している必要があります。

ドキュメントのアクセシビリティについて

オラクル社のアクセシビリティへの取組みの詳細は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

サポートをご購入のOracleのお客様は、My Oracle Supportにアクセスして電子サポートを受けることができます。詳細は、http://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoまたはhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs (聴覚障害者向け)を参照してください。

関連ドキュメント

詳細は、次のドキュメントを参照してください。

- Oracle Directory Services ManagerおよびOracle Fusion Middlewareを介して使用可能なオンライン・ヘルプ。

- Oracle Fusion MiddlewareおよびOracle Databaseのドキュメント・セット。特に次のマニュアルを参照してください。

- Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド

- Oracle Fusion Middleware Oracle Identity Managementリファレンス

- Oracle Fusion Middleware Oracle Directory Integration Platform管理者ガイド

- Oracle Fusion Middleware Oracle Virtual Directory管理者ガイド

- Oracle Fusion Middleware Oracle Identity Managementアプリケーション開発者ガイド

詳しい情報は、次のドキュメントを参照してください。

- David Chadwick著Understanding X.500—The DirectoryThomson Computer Press、1996年

- Tim HowesおよびMark Smith著LDAP: Programming Directory-enabled Applications with Lightweight Directory Access ProtocolMacmillan Technical Publishing、1997年

- Tim Howes、Mark SmithおよびGordon Good著『Understanding and Deploying LDAP Directory Services』Macmillan Technical Publishing、1999年

- Internet Assigned Numbers Authorityのホームページ(http://www.iana.org)のオブジェクト識別子に関する情報

- http://www.ietf.orgで入手可能なInternet Engineering Task Force(IETF)のドキュメント、特に次のものを参照してください。

- LDAPEXTのCharterおよびLDAPのDraft

- LDAPのCharterおよびDraft

- RFC 2254、「The String Representation of LDAP Search Filters」

- RFC 1823、「The LDAP Application Program Interface」

- OpenLDAP Community (http://www.openldap.org)

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

Oracle Internet Directoryの新機能

この項では、Oracle Internet Directoryの最新リリースで導入された新機能について簡単に説明し、各新機能の関連項目を記載します。

この章では、次のリリースについて説明します。

- Oracle Internet Directory 11gリリース1(11.1.1.9.0)で導入された新機能

- Oracle Internet Directory 11gリリース1(11.1.1.7.0)で導入された新機能

- Oracle Internet Directory 11gリリース1(11.1.1.6.0)で導入された新機能

- Oracle Internet Directory 11g リリース1(11.1.1.4.0)で導入された新機能

- Oracle Internet Directory 11gリリース1(11.1.1)で導入された新機能

- Oracle Internet Directory 10g(10.1.4.1)で導入された新機能

- Oracle Internet Directory 10gリリース2(10.1.2)で導入された新機能

Oracle Internet Directory 11gリリース1(11.1.1.9.0)で導入された新機能

- 永続検索操作: 永続検索操作は、初期検索の結果がOracle Internet DirectoryサーバーからLDAPクライアントに返された後も継続する拡張検索です。初期検索の終了後も、サーバーに対する接続は、クライアントが操作をバインド解除するか中止するまで維持されます。永続検索操作によって、クライアントは、検索範囲のエントリが変更された場合に通知を受信できます。
第3.2.2項「永続LDAP検索操作」を参照してください。

- Oracle Directory Services Manager (ODSM)セッション・タイムアウト: 現在、ODSMセッション・タイムアウトのデフォルトは、5分です。異なる値を構成するには、WebLogic Server管理コンソールを使用します。
第7.4.7項「Oracle Directory Services Managerセッション・タイムアウトの構成」を参照してください。

- 結果セットおよびメタデータ・キャッシュ構成: 新しいorclcachemaxsize構成属性では、結果セットおよびメタデータ・キャッシュのサイズを指定し、Oracle Internet DirectoryサーバーからそのOracle Databaseへの読取り/書込み操作のパフォーマンスを向上できます。
第9.1.4項「DSA構成エントリの属性」を参照してください。

- 拡張ロギング: 新しいorcltraceconndnおよびorcltraceconnipというインスタンス固有の構成属性では、それぞれ接続識別名(DN)とIPアドレスに基づいてロギングを指定できます。
第9.1.3項「インスタンス固有の構成エントリの属性」を参照してください。

- 新しいDSA構成属性:

- orclblockdnip属性は、新しい接続を拒否してそのIPアドレスからの既存の接続をOracle Internet Directoryサーバーにクローズさせます。

- orclmaxlatencylog属性は、その時間を超えるとOracle Internet Directoryサーバーの操作がアラート・ログに記録される時間(マイクロ秒)を指定します。

第9.1.4項「DSA構成エントリの属性」を参照してください。

- サーバーに対するバインドの制限。新しいbindAuthPriv属性では、Oracle Internet Directoryサーバーにバインド可能なユーザーを指定できます。
第33.8項「Oracle Internet Directoryサーバーに対するユーザーのバインドの制限」を参照してください。

- 計算属性のconnectByインタフェース: orclComputedAttributeのconnectByインタフェースでは、2つ以上の他のエントリの属性を接続して、属性を計算できます。
第17章「計算属性の管理」を参照してください。

- DITビュー: 異なるDITまたはソースDITのエントリを表示した仮想ビューまたはネームスペースであるDITビューを作成できます。
第34.4項「DITビューの作成」を参照してください。

- LDAPレプリケーション・フィルタ: Oracle Internet Directoryサーバーおよびレプリケーション・サーバーでは、レプリケーション承諾のorclEntryExclusionFilter属性で構成されたLDAPフィルタ文字列に基づいて、特定のエントリのフィルタリングがサポートされます。
第42.1.3.1項「レプリケーション承諾エントリの属性」を参照してください。

- トラブルシューティングの新規情報と改訂情報: 付録R「Oracle Internet Directoryに関するトラブルシューティング」を参照してください。

- 変更ログのパーティション化: Oracle Internet Directoryでは、変更ログ表のパーティション化の概念が導入されています。
第43.1.4項「ディレクトリ・レプリケーションの変更ログのパーティション化」を参照してください。

- 新しいインスタンス固有の構成エントリ:

- orclskipspecialinfilter属性は、Oracle Internet Directoryで検索操作中にフィルタ値に指定された特殊文字の処理をスキップするかどうかを評価します。

第9.1.3項「インスタンス固有の構成エントリの属性」を参照してください。

- 集合属性のspecificationFilterの範囲の拡張: Oracle Internet Directoryでは、サブツリー仕様のLDAPフィルタを定義できるようになりました。
第16.1.3.3項「特定の除外」を参照してください。

Oracle Internet Directory 11gリリース1(11.1.1.7.0)で導入された新機能

- 拡張されたパフォーマンス・チューニング:

- 選択可能な新しいcatalogコマンドのIOTオプションにより、追加索引を作成することなく、指定する属性についてIndex Organized Table(IOT)が作成されます。IOTオプションは、通常のLDAP操作の読取りおよび書込みのパフォーマンスをともに向上させ、記憶域の使用を軽減します。第15.7項「catalogを使用した既存の属性の索引の作成および削除」を参照してください。

- Oracle Internet Directoryサーバーでは、attr_uniqueness_log表内の重複する属性値がレポートされます。attr_uniqueness_log表をスキャンすることによって重複する値を特定した後、クリーンアップできます。第19.2項「重複する属性値のクリーンアップ」を参照してください。

- 診断機能の強化: Oracle Internet Directoryサーバーが対応するOracle Databaseにキープ・アライブ・メッセージを送信するためにOCIPing()をコールするように指定できます。こうしたメッセージの頻度は、新しいorclMaxTcpIdleConnTime属性によって決定されます。
orclMaxTcpIdleConnTime属性に、Oracle Internet DirectoryサーバーとOracle Database間のファイアウォールのタイムアウト値よりも小さい値を設定することによって、データベース接続の切断が避けられます。

第9.1.4項「DSA構成エントリの属性」を参照してください。

- 検索フィルタでのorclMemberOfのサポート: orclMemberOfは、そのエントリが属するグループを含む複数値属性です。検索フィルタでorclMemberOfを使用できるようになりました。
第14.1.5項「orclMemberOf属性」を参照してください。

- LDAPレプリケーションの強化: LDAPレプリケーションのデータ・フローは、適用キューを含む適用フェーズのみから構成されます。トランスポート・キューを含むトランスポート・フェーズは使用されなくなりました。
付録D「レプリケーションの動作」を参照してください。

- 計算属性のサポート: 新しいorclComputedAttribute属性は、1つ以上のルールに基づいて構成可能な属性およびその値を動的に計算するためのメカニズムを提供します。
第17章「計算属性の管理」を参照してください。

- エントリ・キャッシュおよび結果セット・キャッシュの両方が有効: orclecacheenabled属性により、エントリ・キャッシュおよび結果セット・キャッシュの両方を有効および無効にできます。
第9.1.4項「DSA構成エントリの属性」を参照してください。

Oracle Internet Directory 11gリリース1(11.1.1.6.0)で導入された新機能

- トランザクション・サポート: Oracle Internet Directory SDKは、RFC 5805に定義されているトランザクションをサポートするようになりました。『Oracle Fusion Middleware Oracle Identity Managementアプリケーション開発者ガイド』のLDAPトランザクションの使用に関する説明を参照してください。

- 共有エントリ・キャッシュ: エントリ・キャッシュが共有メモリー上に置かれるようになったため、同じホスト上の複数のOracle Internet Directoryサーバー・インスタンスでキャッシュを共有できます。ホストがクラスタの一部である場合、1台のホスト上でエントリが変更されたときに、すべてのホストに対してエントリを削除するよう通知されます。すべての検索タイプがキャッシュされるわけではなく、パフォーマンスの向上による効果がある検索タイプのみがキャッシュされます。キャッシュを構成するための属性は、DSA構成エントリ内に置かれるようになりました。詳細は、『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』の「Oracle Internet Directory」の章にある、サーバー・エントリ・キャッシュに関する説明を参照してください。

- 自動カタログ: リリース1(11.1.1.6.0)の新規インストールでは、デフォルトで、新しい自動カタログ機能が有効化されます。この機能を有効にすると、属性を検索したときに、Oracle Internet Directoryで自動的にcatalogコマンドが起動され、属性が索引付けされます。
自動カタログ機能を有効化しないで、カタログ化されていない以前の属性を検索フィルタで使用する場合は、以前のリリースと同様に、その属性をカタログ・エントリに追加する必要があります。catalogのかわりにldapmodifyを使用して、属性に索引付けできるようになりました。ldapmodifyコマンドによりcatalogが起動し、操作が実行されます。

第21.1.3.4項「属性の索引付けについて」を参照してください。

- DITマスキング: Oracle Internet Directoryサーバー・インスタンスで公開されるDITコンテンツを制限できるようになりました。これにより、ユーザーが接続しているインスタンスに応じて、異なるユーザーに異なるDIT表示を提示できます。第39項「DITマスキングの管理」を参照してください。

Oracle Internet Directory 11g リリース1(11.1.1.4.0)で導入された新機能

- セキュリティ拡張機能

- 機密の属性のAES暗号化: 機密の属性を暗号化するアルゴリズムがAESになりました。「機密の属性の暗号化アルゴリズム」を参照してください。

- より多くのSHA-2バリアントのサポート: ユーザー・パスワードの保護にSHA-2ハッシング・アルゴリズムの複数のバリアントを使用できるようになりました。第31章「パスワード・ベリファイアの管理」を参照してください。

- 非アクティブな期間に基づくアカウントの有効期限: ユーザーが非アクティブであることに基づいてアカウントを期限切れにすることができます。「パスワード・ポリシーの属性」を参照してください。

- IPアドレスに制約されたアクセス制御: クライアントのIPアドレスに対する制約のあるACIを作成できます。付録H「アクセス制御ディレクティブ書式」の「バインドIPフィルタ」を参照してください。

- Oracle Directory Services Managerの機能

- SSO統合: シングル・サインオン用のOracle Access Manager 11gまたはOracle Access Manager 10gを使用するようにODSMを構成できます。「Oracle Directory Services Managerとのシングル・サインオン統合」を参照してください。

- ロックされたアカウントのロック解除: ODSMからロックされたアカウントをリストし、ロック解除することができます。「Oracle Directory Services Managerを使用したロックされたアカウントのリストおよびロック解除」を参照してください。

- LDIFファイルからのエントリのインポートおよびLDIFファイルへのエントリのエクスポート: LDIFファイルからエントリをインポートしたり、LDIFファイルにエントリをエクスポートできます。「Oracle Directory Services Managerを使用したLDIFファイルのエントリのインポート」および「Oracle Directory Services Managerを使用したLDIFファイルへのエントリのエクスポート」を参照してください。

- サブツリーの削除: サブツリー全体を一度に削除できます。「Oracle Directory Services Managerを使用したエントリまたはサブツリーの削除」を参照してください。

- 構成可能なセッション・タイムアウト: 非アクティブなセッションがタイムアウトになるまでの時間を制御できます。「Oracle Directory Services Managerセッション・タイムアウトの構成」を参照してください。

- LDAPプロトコル機能

- +オプションのサポート: このオプションを使用して、検索で操作属性を返すことができます。「ldapsearchを使用した操作属性のリスト」を参照してください。

- 集合属性のサポート: 複数のエントリに共通の属性を構成できます。第16章「集合属性の管理」を参照してください。

- グループ機能

- キャッシュされていない動的グループのサポート: 動的グループに類似したキャッシュされていないグループを動的にリストします。「動的グループ」を参照してください。

- OrclMemberOf属性のサポート: 一部のタイプのグループのメンバーには、この属性の値が自動的に割り当てられます。「orclMemberOf属性」を参照してください。

- アップグレード要件

- ディレクトリ・レプリケーション・グループのローリング・アップグレード: 既存のOracle Internet Directory環境にマルチマスター・レプリケーションが構成されている場合は、付録Q「ローリング・アップグレードの実行」の手順に従う必要があります。

- パフォーマンスおよびフットプリントの改善

- パフォーマンスの改善: LDAP追加、LDAP検索および権限グループ更新におけるパフォーマンスが強化されました。

- 記憶域フットプリントの削減: 値が複数ある特定の属性が、1行に格納されるようになりました。

- oidstats.sqlの自動実行: 管理者が手動でoidstats.sqlを実行する必要がなくなりました。データベース内の更新回数に基づいて、OIDMONが実行します。『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』のoidstats.sqlを使用したデータベース統計の更新に関する説明を参照してください。

Oracle Internet Directory 11gリリース1(11.1.1)で導入された新機能

- WebLogic Serverの統合: 11g リリース1(11.1.1)のOracle Internet Directoryは、管理サービスにWebLogic管理ドメインを使用できるシステム・コンポーネントです。

関連項目:

- 第2章「Oracle Fusion Middleware内のOracle Internet Directoryの理解」

- Oracle Fusion Middlewareコンセプト・ガイド

- Fusion Middleware Control: Oracle Enterprise Manager Fusion Middleware Controlというグラフィカル・ユーザー・インタフェースを使用してOracle Internet Directoryを管理できます。

関連項目:
第7章「Oracle Internet Directoryのスタート・ガイド」

- Oracle Directory Services Manager: ディレクトリ管理用の以前のグラフィカル・ユーザー・インタフェースであるOracle Directory Managerは、このWebベースの管理ツールに置き換えられました。これを使用してOracle Internet DirectoryおよびOracle Virtual Directoryを管理します。Oracle Enterprise Manager Fusion Middleware Controlから直接起動できます。

関連項目:
第7章「Oracle Internet Directoryのスタート・ガイド」

- LDAPベースのマルチマスター・レプリケーション: マルチマスター・ディレクトリ・レプリケーション・グループ用としてLDAPベースのレプリケーションを使用できるようになりました。この目的でOracle Databaseアドバンスト・レプリケーション・ベースのレプリケーションを使用する必要がなくなりました。ただし、Oracle Single Sign-Onをレプリケートする必要がある場合、Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーションを使用する必要があります。

関連項目:
第6章「Oracle Internet Directoryレプリケーションの理解」

- 改良されたレプリケーション管理機能: Oracle Enterprise Manager Fusion Middleware Controlのレプリケーション・ウィザードを使用してLDAPベースのレプリケーションを設定および管理できます。個別の「レプリケーション」ページでレプリケーション・サーバーを制御する属性を調整できます。

関連項目:
第V部「拡張管理: ディレクトリ・レプリケーション」

- サイズ設定とチューニング・ウィザード: Oracle Enterprise Manager Fusion Middleware Controlでサイズ設定とチューニング・ウィザードを実行し、チューニングとサイズ設定に関する推奨事項を得ることができます。

関連項目:
『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』の「Oracle Internet Directory」の章

- 共通監査インフラストラクチャとの統合: Oracle Internet DirectoryがOracle Fusion Middlewareの共通監査インフラストラクチャと統合されました。コマンド行またはOracle Enterprise Manager Fusion Middleware Controlを使用して監査を構成できます。

関連項目:
第23章「監査の管理」

- 参照整合性の向上: 参照整合性が完全に実装しなおされました。コマンド行またはOracle Enterprise Manager Fusion Middleware Controlを使用して構成できます。

関連項目:
第22章「参照整合性の構成」

- パスワード・ポリシー制御およびエラー・メッセージの更新: 新しい制御とエラー・メッセージがLDAP APIに追加されました。

関連項目:

- 『Oracle Fusion Middleware Oracle Identity Managementアプリケーション開発者ガイド』の「LDAPプロトコルに対する拡張機能」、パスワード・ポリシーに関する項

- 第29章「パスワード・ポリシーの管理」

- 構成パラメータの変更: LDAPサーバーの構成属性の大半が2つのエントリに存在するようになりました。インスタンス固有の属性はインスタンス固有の構成エントリにあり、共有属性はDSA構成エントリにあります。この大半は、Oracle Enterprise Manager Fusion Middleware ControlまたはOracle Directory Services Managerを使用して管理できます。

関連項目:
第9章「システム構成属性の管理」

- 属性とエントリ別名のサポートの向上: Oracle Internet Directoryで、検索での別名の間接参照にいくつかの異なるオプションがサポートされるようになりました。

関連項目:
第18章「別名エントリの管理」

- 検索フィルタの拡張可能一致: Oracle Internet Directoryでは、attr:dn:=valueという形式の検索フィルタをサポートできるようになりました。このフィルタを使用すると、dn属性が検索を目的としたエントリの一部とみなされるようになります。Oracle Internet Directoryは、フィルタに指定した一致規則を使用した拡張可能一致はサポートしていません。
Oracle Internet Directoryでは拡張可能フィルタがサポートされますが、ldapsearchおよびOracle LDAP APIではサポートされません。この種のフィルタを使用するには、JNDIなどの別のAPIを使用する必要があります。

関連項目:
『Oracle Fusion Middleware Oracle Identity Managementアプリケーション開発者ガイド』の「標準的なLDAP APIを使用したアプリケーションの開発」

- 10g(10.1.4.3.0)以上のOracle Single Sign-OnおよびOracle Delegated Administration Servicesのサポート: Oracle Fusion Middleware 11g リリース1(11.1.1)には、Oracle Single Sign-OnもOracle Delegated Administration Servicesも含まれていません。ただし、Oracle Internet Directory 11g リリース1(11.1.1)は10g(10.1.4.3.0)以上のOracle Single Sign-OnおよびOracle Delegated Administration Servicesと互換性があります。

Oracle Internet Directory 10g(10.1.4.1)で導入された新機能

- 手順情報へのリンク: このドキュメントには、重要なタスクへのリンクの表が含まれています。

- Identity Management Grid Control Plug-in: この新しいインタフェースでは、Oracle Enterprise Manager 10g Grid Controlコンソールの機能を使用してOracle Internet Directory、Oracle Single Sign-On、Oracle Delegated Administration ServicesおよびOracle Directory Integration Platformをモニターおよび管理できます。

- 改良されたバルク・ツール: 次のバルク・ツールが、C言語実行可能ファイルに変換されました。

- bulkload

- bulkmodify

- bulkdelete

- catalog

- ldifwrite

このマニュアルと『Oracle Fusion Middleware Oracle Identity Managementリファレンス』の例や説明は、これらのツールの新機能を反映するために更新されました。

関連項目:

- 第15章「バルク操作の実行」

- 『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のOracle Internet Directoryサーバー管理ツールに関する章

- アプリケーション固有のスキーマ・コンテナ: Oracle Internet Directoryにスキーマを追加する製品は、cn=subSchemaSubentryの下に独自のsubSchemaSubentryを持つことができます。

関連項目:
第21章「ディレクトリ・スキーマの管理」の「ディレクトリ・スキーマの管理の概要」

- 属性別名のサポート: 属性名にわかりやすい別名を作成できます。

関連項目:
第21章「ディレクトリ・スキーマの管理」の「属性別名の理解」

- 動的グループのキャッシング: 動的グループが追加されると、その動的グループのメンバーが計算され、動的グループを後で変更したときに、メンバー・リストの一貫性が維持されます。

関連項目:
第14章「動的グループと静的グループの管理」の「動的グループ」

- ラージ・グループ・エントリ検索の最適化: エントリ・キャッシュを無効にせず、エントリ・キャッシュのサイズを増やすことで、検索を最適化するテクニックが加わりました。

関連項目:
『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』の「Oracle Internet Directory」の章

- 参照整合性: 参照整合性を有効にした場合、ディレクトリ内のエントリを更新すると、そのエントリを参照する他のエントリもサーバーによって更新されます。

関連項目:
第22章「参照整合性の構成」

- サーバー管理を容易にするための新しいモニタリング機能: 追加の状況統計、ユーザー統計およびセキュリティ・イベント追跡を有効にできます。

関連項目:
第25章「Oracle Internet Directoryのモニタリング」

- 新しいパスワード・ポリシー機能: 任意のサブツリー、または単一エントリにもパスワード・ポリシーを適用できます。選択対象のパスワード・ポリシー属性も増えました。

関連項目:
第29章「パスワード・ポリシーの管理」

- サーバー・チェーン: この機能を使用すると、サード・パーティのLDAPディレクトリにあるエントリを、ディレクトリ・ツリーの一部にマップし、同期やデータの移行なしに、Oracle Internet Directoryを介してアクセスできます。

関連項目:
第38章「ディレクトリ・サーバー・チェーンの構成」

- LDAP検索結果のページングおよびソート: ldapsearchコマンドに、ソート用の-Tオプションとページング用の-jオプションが使用できるようになりました。

関連項目:

- 『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のldapsearchコマンド行のリファレンス

- 『Oracle Fusion Middleware Oracle Identity Managementアプリケーション開発者ガイド』のLDAPプロトコルに対する拡張機能に関する章

- 新しいレプリケーション機能: Oracle Internet Directoryレプリケーションは、次の機能により強化されました。

- 双方向LDAPベース・レプリケーション: この機能により、ファンアウト・レプリケーション・グループをデプロイできます。このグループでは、レプリケーションが双方向に流れ、どのノードで更新が行われてもグループ全体にレプリケートされます。

- レプリケーション・フェイルオーバー: あるサプライヤから別のサプライヤへのLDAPレプリカのフェイルオーバーが、管理者の操作によりサポートされます。

- Oracle Internet Directory比較調整ツール: 機能が改善された新しいoidcmprecコマンドが、従来のoidreconcileツールにかわりました。

関連項目:

- 第40章「レプリケーションの設定」

- 第43章「レプリケーションの管理およびモニタリング」

- 『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のoidcmprecコマンド行ツールのリファレンス

- Java Serverプラグイン: Oracle Internet Directory Plug-in Frameworkでは、JavaとPL/SQLで書かれたプラグインをサポートするようになりました。

関連項目:
第45章「Oracle Internet Directoryサーバーのプラグインの開発」

Oracle Internet Directory 10gリリース2(10.1.2)で導入された新機能

注意:

次の章は、『Oracle Fusion Middleware高可用性ガイド』に移動しました。

- 「高可用性とフェイルオーバーに関する考慮事項」

- 「Oracle Application Server Cluster(Identity Management)構成」

- 「Oracle Application Server Cold Failover Cluster(Identity Management)」

- 「Oracle Real Application Clusters環境でのディレクトリ」

次の付録は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』の章として書きなおされています。

- 「LDIFおよびコマンド行ツールの構文」

- 「Oracle Internet Directoryのスキーマ要素」

- 他のコンポーネントとの改善された統合機能: 新機能では、Oracle Collaboration Suiteなどのコンポーネントとの統合性が向上しています。これらの機能には、サービスツーサービス認証、サービス・レジストリ、および動的パラメータを使用したベリファイアの生成があります。

関連項目:

- 「サービス・レジストリとサービス・ツー・サービス認証」

- 「動的パラメータを使用したベリファイアの生成の概要」

- 証明書の一致規則のサポート: 証明書を使用した外部認証では、完全一致と証明書ハッシュのどちらかの形式を選択できるようになりました。完全一致では、ユーザー認証を行うためにクライアント証明書のサブジェクトDNが使用されます。証明書ハッシュでは、クライアント証明書がハッシュされ、ディレクトリに格納されている証明書ハッシュと比較されます。

関連項目:
「直接認証」

- レプリケーション・デプロイメントの容易性: レプリケーションのインストール、構成および管理が非常に簡単になりました。

関連項目:

- 第40章「レプリケーションの設定」

- クラスタ・デプロイメントの容易性: クラスタ構成のインストール、構成および管理が非常に簡単になりました。

- Oracle Internet Directoryスーパーユーザーに対するアクセス制御の適用: スーパーユーザーも他のユーザーと同様にアクセス制御ポリシーの適用対象になりました。新しいACLキーワードを使用すると、権限グループを使用してスーパーユーザーのアクセスを制限できます。

関連項目:
第30章「ディレクトリ・アクセス制御の管理」

- Oracle Internet Directoryサーバー診断ツール: OID診断ツールにより、Oracle Internet Directoryで報告される優先順序決定の問題に役立つ診断情報を収集できます。

関連項目:
『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のoiddiagコマンド行ツールのリファレンス

第I部

ディレクトリ・サービスの理解

第I部では、Oracle Internet Directoryの概要と使用する前に知っておく必要のある概念について説明します。次の各章で構成されています。

- 第1章「ディレクトリ・サービスの概要」

- 第2章「Oracle Fusion Middleware内のOracle Internet Directoryの理解」

- 第3章「Oracle Internet Directoryの概念およびアーキテクチャの理解」

- 第4章「Oracle Internet Directoryコンポーネントのプロセス制御の理解」

- 第5章「Oracle Internet Directory編成の理解」

- 第6章「Oracle Internet Directoryレプリケーションの理解」

1 ディレクトリ・サービスの概要

この章では、オンライン・ディレクトリ、Lightweight Directory Access Protocol (LDAP)バージョン3の概要、およびOracle Internet Directory固有の機能と利点について説明します。

この章の内容は次のとおりです。

- 第1.1項「ディレクトリとは」

- 第1.2項「Lightweight Directory Access Protocol(LDAP)とは」

- 第1.3項「Oracle Internet Directoryとは」

- 第1.4項「Oracle製品によるOracle Internet Directoryの使用」

1.1 ディレクトリとは

ディレクトリとは、同様の属性を持つエントリが階層的に編成された集合です。ディレクトリは、リソース(たとえば、人、図書館の本、百貨店の商品など)のリストで、それぞれに関する詳細情報が得られます。ディレクトリは、オフライン(たとえば、電話帳、百貨店のカタログ)、オンラインのいずれでも使用できます。

オンライン・ディレクトリは、分散コンピュータ・システムを持つ企業が、迅速な検索、ユーザーとセキュリティの管理、および複数のアプリケーションとサービスの統合の目的で使用しています。オンライン・ディレクトリは、E-Businessおよびホスティングされた環境の双方にとっても重要なものになっています。

この項の項目は次のとおりです。

- 第1.1.1項「拡大するオンライン・ディレクトリの役割」

- 第1.1.2項「問題点: 特別な用途を指定されたディレクトリが多すぎる場合」

1.1.1 拡大するオンライン・ディレクトリの役割

オンライン・ディレクトリは、オブジェクトに関する一連の情報を格納して検索する特殊なデータベースです。このような情報として、管理が必要なあらゆるリソースに関する情報(従業員名、役職、セキュリティ資格証明、パートナ情報、会議室やプリンタなどの共有ネットワーク・リソースに関する情報)があります。

オンライン・ディレクトリは、次のような様々なユーザーやアプリケーションによって、様々な用途で使用されます。

- 会社の個人別電話帳情報を検索し、メール・クライアントでアドレス帳から電子メール・アドレスを調べる従業員

- ユーザーのメール・サーバーの位置を特定する、メッセージ転送エージェントなどのアプリケーション

- ユーザーのロール情報を識別するデータベース・アプリケーション

オンライン・ディレクトリはデータベース(データの構造化された集合)ですが、リレーショナル・データベースにはなっていません。次の表はオンライン・ディレクトリをリレーショナル・データベースと対比しています。

表1-1 オンライン・ディレクトリとリレーショナル・データベースの比較

オンライン・ディレクトリ

リレーショナル・データベース

比較的小規模な単位のデータで比較的単純なトランザクションを処理するように設計されています。たとえば、アプリケーションがディレクトリを使用して、電子メール・アドレス、電話番号またはデジタル画像の格納および検索のみを行う場合があります。

大規模な単位のデータで多数の操作を利用しながら、多様で大量のトランザクションを処理するように設計されています。

ロケーション非依存となるよう設計されています。ディレクトリ対応アプリケーションでは、問合せ中のサーバーに関係なく、デプロイメント環境全体にわたって常に同じ情報を参照していると想定しています。問合せ先のサーバーで情報がローカルに格納されていない場合、そのサーバーはその情報を取得するか、またはクライアント・アプリケーションにその情報を透過的に示す必要があります。

一般的にはロケーション固有に設計されています。リレーショナル・データベースは分散が可能ですが、通常は特定のデータベース・サーバーに常駐します。

情報をエントリに格納するように設計されています。これらのエントリは、従業員、E-Commerceパートナ、会議室、プリンタのような共有ネットワーク・リソースなど、顧客が管理する必要があるリソースを表します。各エントリには複数の属性が関連付けられており、属性ごとに1つ以上の値が割り当てられる場合があります。たとえば、personエントリの一般的な属性には、姓名、電子メール・アドレス、常用メール・サーバーのアドレス、パスワードやその他のログイン資格証明、デジタル化された画像などがあります。

リレーショナル表に行として情報を格納するように設計されています。

1.1.2 問題点: 特別な用途を指定されたディレクトリが多すぎる場合

過去において、一部の大企業は、それぞれが特別な用途を指定された100を超えるディレクトリを使用していました。また、一部のアプリケーションには、それぞれユーザー名を割り当てた固有のディレクトリが使用されていました。

専用のディレクトリを多数管理していると、次のような問題が発生する可能性がありました。

- 高い管理費用: 管理者は、複数の場所で基本的には同じ情報をメンテナンスする必要がありました。たとえば、ある企業が新しい従業員を雇用するとき、管理者は新しいユーザー・アイデンティティをネットワークに作成し、新しい電子メール・アカウントを作成し、そのユーザーを従業員データベースに追加し、そして従業員が必要とするすべてのアプリケーション(開発、テストおよび本番データベース・システムのユーザー・アカウントなど)を設定する必要がありました。その従業員が退社した場合は、管理者はこれらのユーザー・アカウントをすべて無効にするために逆の処理を行う必要がありました。

- 一貫性のないデータ: 大きな管理オーバーヘッドのため、複数のシステムに冗長な情報を入力している複数の管理者にとっては、この従業員の情報をすべてのシステムで同期化させることが困難な場合がありました。結果として、企業内で一貫性のないデータが発生することになりました。

- セキュリティの問題: 各ディレクトリには、独自のパスワード・ポリシーがありました。つまり、ユーザーは、システムごとに異なる様々なユーザー名とパスワードを覚える必要がありました。

今日の企業には、様々なアプリケーションとサービスをサポートするために、共通の規格に基づいた汎用性の高いディレクトリのインフラストラクチャが必要です。

1.2 Lightweight Directory Access Protocol(LDAP)とは

LDAPは、ディレクトリ・クライアントとサーバーが通信に使用する標準的で拡張可能なディレクトリ・アクセス・プロトコルです。

この項の項目は次のとおりです。

- 第1.2.1項「LDAPと単純化されたディレクトリ管理」

- 第1.2.2項「LDAPバージョン3」

1.2.1 LDAPと単純化されたディレクトリ管理

LDAPは、インターネットに対応する軽量実装として考案された、国際標準化機構(ISO)のディレクトリ・サービスに関するX.500規格です。クライアント側で必要なネットワーキング・ソフトウェアを最小限に抑えられるため、インターネットベースのシン・クライアント・アプリケーションにとって特に有用です。

LDAP規格は、ディレクトリ情報の管理を次の3つの方法で単純化します。

- 拡張可能な単一のディレクトリ・サービスに対し、正しく定義された単一の標準インタフェースを企業内のすべてのユーザーとアプリケーションに提供します。これによって、ディレクトリに対応したアプリケーションの迅速な開発とデプロイが簡単になります。

- 企業内に散在する複数のサービスへの、冗長な情報の入力と調整の必要性を低減します。

- 正しく定義されたプロトコルと一連のプログラム・インタフェースによって、ディレクトリを活用するインターネット対応のアプリケーションのデプロイがより実用的になります。

1.2.2 LDAPバージョン3

最新バージョンのLDAPバージョン3は、1997年12月、Internet Engineering Task Force(IETF)によって、インターネット標準の案として承認されました。LDAPバージョン3では、次のいくつかの重要な領域においてLDAPバージョン2の内容が改善されています。

- グローバリゼーション・サポート: LDAPバージョン3では、世界中の言語で使用されている文字を、サーバーとクライアントの両方でサポートできます。

- ナレッジ参照(参照とも呼ばれる): LDAPバージョン3の参照機能によって、サーバーは、ディレクトリ問合せの結果として、参照を他のサーバーに返すことができます。これにより、ディレクトリ情報ツリー(DIT)を複数のLDAPサーバーにわたってパーティション化して、ディレクトリをグローバルに分散できます。

- セキュリティ: LDAPバージョン3では、Simple Authentication and Security Layer(SASL)をサポートするための標準機能が追加され、データ・セキュリティに関する総合的で拡張可能なフレームワークが提供されています。

- 拡張性: LDAPバージョン3では、ベンダーは、制御と呼ばれるメカニズムを使用して既存のLDAP操作を拡張できます。これらは、既存の操作に付随する追加情報で、操作の動きを変更します。クライアント・アプリケーションから標準LDAPコマンドとともに制御が渡されると、命令された操作の動きがそれに応じて変更されます。たとえば、クライアントからディレクトリ内の非表示メタ情報を変更するには、LDAPコマンドに加えてmanageDSAIT制御を送信します。

- 機能およびスキーマの開示: LDAPバージョン3では、他のLDAPサーバーやクライアントに役立つ情報(サポートされるLDAPプロトコルやディレクトリ・スキーマの説明など)を公開できます。

関連項目:

- IETFのRFC(Requests for Comments)2251から2256。http://www.ietf.orgで入手可能です。

- 付録N「Oracle Internet DirectoryでサポートされているRFC」

- LDAPに関する参考資料の追加リストは、「関連ドキュメント」を参照してください。

- ディレクトリ情報ツリーおよびナレッジ参照の概念の説明は、第3章「Oracle Internet Directoryの概念およびアーキテクチャの理解」を参照してください。

- Oracle Internet Directoryでサポートしている制御のリストおよび説明の詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のLDAP制御に関する説明を参照してください。

1.3 Oracle Internet Directoryとは

Oracle Internet Directoryは、分散したユーザーおよびネットワーク・リソースに関する情報の高速検索と集中管理を可能にする汎用ディレクトリ・サービスです。これは、Lightweight Directory Access Protocol(LDAP)バージョン3と、Oracle Databaseの高いパフォーマンス、スケーラビリティ、堅牢性および可用性を組み合せたものです。

この項の項目は次のとおりです。

- 第1.3.1項「Oracle Internet Directoryの概要」

- 第1.3.2項「Oracle Internet Directoryのコンポーネント」

- 第1.3.3項「Oracle Internet Directoryの利点」

1.3.1 Oracle Internet Directoryの概要

Oracle Internet Directoryは、Oracle Database上のアプリケーションとして動作します。オペレーティング・システムに依存しないOracleのデータベース接続ソリューションであるOracle Net Servicesを使用して、データベースと通信します。データベースのホストが異なっていてもかまいません。図1-1に、この関係を示します。

図1-1 Oracle Internet Directoryの概要

1.3.2 Oracle Internet Directoryのコンポーネント

Oracle Internet Directoryには、次のものがあります。

- Oracleディレクトリ・サーバー。人員とリソースの情報に関するクライアントのリクエストに応答します。また、TCP/IPを介し、複数層アーキテクチャを直接使用して、その情報を更新します。

- Oracleディレクトリ・レプリケーション・サーバー。Oracleディレクトリ・サーバー間で、LDAPデータをレプリケートします。

- ディレクトリ管理ツールには、次のものがあります。

- Oracle Enterprise Manager Fusion Middleware ControlのOracle Internet Directoryページ

- Oracle Directory Services Manager

- コマンド行管理およびデータ管理ツール

- Oracle Internet Directory Software Developer's Kit。

関連項目:
Oracle Internet Directory Software Developer's Kitの詳細は、『Oracle Fusion Middleware Oracle Identity Managementアプリケーション開発者ガイド』を参照してください。

1.3.3 Oracle Internet Directoryの利点

Oracle Internet Directoryの大きな利点は、スケーラビリティ、高可用性、セキュリティおよびOracle環境との緊密な統合です。

1.3.3.1 スケーラビリティ

Oracle Internet Directoryは、Oracle Databaseの高機能を活用して、TB単位に及ぶディレクトリ情報のサポートを可能にします。さらに、共有LDAPサーバーやデータベース接続プーリングなどのテクノロジによって、千単位の同時クライアントであっても、わずかな検索レスポンス時間を実現します。

Oracle Internet Directoryの物理アーキテクチャは、複数スレッド、複数プロセスおよび複数インスタンスです。これによって、デプロイメント・オプションの柔軟性が高まります。Oracle Internet Directoryは、SMPまたはNUMAハードウェア上の多数のCPUに応じて拡張できます。Oracle RACデータベースとOracle Internet Directoryのクラスタ構成を使用して、複数のハードウェア・ノードに対して1つのディレクトリをデプロイし、水平スケーラビリティを実現します。

関連項目:
Oracle Fusion Middleware高可用性ガイド

Oracle Internet Directoryは、Oracle Directory Services Managerや様々なコマンド行ツールなど、大量のLDAPデータを操作するためのデータ管理ツールも提供します。

1.3.3.2 高可用性

Oracle Internet Directoryによって、最も包括的な高可用性構成が提供されます。ディレクトリ・レプリケーション、アクティブ/パッシブ・クラスタ構成、Oracle RAC Databaseを使用したアクティブ/アクティブ・クラスタ構成、Oracle Data Guardを使用した障害時リカバリ機能があります。

Oracle Internet Directoryは、Oracle Databaseの可用性機能もすべて活用しています。ディレクトリ情報は、Oracle Databaseに安全に格納されるため、Oracleのバックアップ機能によって保護されます。また、Oracle Databaseは、大規模なデータストアおよび高負荷で実行されていても、システム障害からすぐにリカバリできます。

関連項目:
Oracle Fusion Middleware高可用性ガイド

1.3.3.3 セキュリティ

Oracle Internet Directoryは、広範囲にわたる柔軟なアクセス制御を提供します。管理者は、特定のディレクトリ・オブジェクトまたはディレクトリ・サブツリー全体に対するアクセス権限を付与または制限できます。さらに、Oracle Internet Directoryは、匿名、パスワード・ベース、およびSecure Sockets Layer (SSL)バージョン3を使用した証明書ベースという3つのレベルのユーザー認証を実装し、認証アクセスおよびデータ・プライバシが保障されています。

Oracle Database Vaultを使用して、Oracle Internet Directoryで管理者および特権ユーザーのディレクトリ・データへのアクセスを制限できます。Oracle Transparent Data Encryptionを使用して、Oracle Internet Directoryでディスクおよびバックアップのデータを確実に保護できます。

1.3.3.4 Oracle環境との統合

Oracle Internet Directoryは、Oracle Directory Integration Platformを介して、Oracle環境と他のディレクトリ(NOSディレクトリ、サード・パーティのエンタープライズ・ディレクトリ、アプリケーション固有のユーザー・リポジトリなど)の間で1箇所の統合ポイントを提供します。

1.4 Oracle製品によるOracle Internet Directoryの使用

Oracle製品は、容易な管理、厳重なセキュリティ、複数のディレクトリの簡単な統合を実現するためにOracle Internet Directoryを使用します。

この項の項目は次のとおりです。

- 第1.4.1項「簡単で対費用効果の高いOracle製品の管理」

- 第1.4.2項「セキュリティ・ポリシーの集中管理によるセキュリティの強化」

- 第1.4.3項「複数ディレクトリの統合」

1.4.1 簡単で対費用効果の高いOracle製品の管理

Oracle Platform Security Servicesにより、ユーザーおよびグループは、組み込まれたLDAPリポジトリにデフォルトで格納されます。ただし、LDAPリポジトリ(Oracle Internet Directoryなど)のアイデンティティ・データを使用するよう、ドメインを構成できます。さらに、Oracle WebLogic Serverでは、他のLDAPサーバーで使用できる汎用のLDAPオーセンティケータを提供しています。OPSSは、デフォルトで、ポリシーと資格証明をファイルベースのストアに格納します。これらのストアは、Oracle Internet DirectoryサーバーまたはOracle Virtual Directoryサーバーの支援を受けるLDAPリポジトリに変更(再関連付け)できます。

Oracle Webcenter SuiteのセキュリティはOPSSに基づいています。このため、アイデンティティ、ポリシーおよび資格証明の格納をOracle Internet Directoryで行うことができます。LDAPコマンドを使用すると、ユーザーを追加または変更したり、ディレクトリを検索することができるため、ユーザー・アカウントをエクスポートおよびインポートする場合に役立ちます。

Oracle Access Managerでは、ユーザー、構成およびポリシー・データのOracle Internet Directoryなど(複数レルム)のディレクトリへの格納がサポートされます。データは、同一ディレクトリ・サーバーにまとめて格納することも、異なるディレクトリ・サーバーに格納することもできます。

Oracle Net ServicesではOracle Internet Directoryを使用して、データベース・サービスと、これを表すネット・サービス名と呼ばれる単純名を格納および解決します。

1.4.2 セキュリティ・ポリシーの集中管理によるセキュリティの強化

Oracle Databaseでは、Oracle Internet Directoryを使用して、エンタープライズ・ロールなどの認可情報とともにユーザー名およびパスワードが格納されます。また、Oracle Internet Directoryを使用して、各ユーザーのエントリとともにパスワード・ベリファイアが格納されます。

Oracle Enterprise User Securityは、次の目的でOracle Internet Directoryを使用します。

- ユーザー認証資格証明の集中管理
Oracle Advanced Securityは、ユーザーのデータベース・パスワードを各データベースに格納するのではなく、ディレクトリという1箇所に格納します。パスワードはユーザー・エントリの属性として格納されます。

- ユーザー認可の集中管理
Oracle Advanced Securityは、エンタープライズ・ロールと呼ばれるディレクトリ・エントリを使用して、共有または所有にかかわらず指定のスキーマ内でエンタープライズ・ユーザーに付与されている権限を判断します。エンタープライズ・ロールは、データベース固有のグローバル・ロールのコンテナです。たとえば、あるユーザーを事務のエンタープライズ・ロールに割り当て、このロールに、人事のグローバル・ロールと人事管理データベースに対する付随権限、および分析のグローバル・ロールと給与管理データベースに対する付随権限を含めることができます。

- 共有スキーマへのマッピング
Oracle Advanced Securityは、マッピング(個別のアカウントではなく、データベース上の共有アプリケーション・スキーマをエンタープライズ・ユーザーに指し示すディレクトリ・エントリ)を使用します。たとえば、複数のエンタープライズ・ユーザーを、ユーザー名の個別のアカウントではなく、スキーマsales_applicationに対してマップできます。

- 単一パスワード認証
Oracle DatabaseではOracle Advanced Securityによって、エンタープライズ・ユーザーが、集中管理された単一のパスワードを使用して複数のデータベースに対する認証を実行できます。パスワードは、ユーザーのエントリの属性としてディレクトリに格納され、暗号化とアクセス制御リストによって保護されます。これによって、ユーザーは、クライアントでのSecure Sockets Layer(SSL)を設定し、複数のパスワードを記憶する必要がなくなります。

- PKI資格証明の集中格納
Oracle DatabaseとOracle Application Serverでは、ユーザー・ウォレットをユーザーのエントリの属性としてディレクトリに格納できます。この方法でウォレットを格納することにより、モバイル・ユーザーは、エンタープライズ・ログイン・アシスタントを使用してウォレットを取得して開くことができます。ウォレットが開いている間は認証が透過的に行われるため、ユーザーはスキーマを所有または共有しているデータベースに再認証せずにアクセスできます。

1.4.3 複数ディレクトリの統合

別のディレクトリ・サービス製品であるOracle Virtual Directoryでは、LDAPプロトコルやXMLプロトコルを介して、複数のデータ・ソースへの動的な単一アクセス・ポイントを提供します。このことは、リアルタイムのデータ結合、および単一の論理ディレクトリを公開する抽象化レイヤーを提供することによって行われ、データを同期化したりネイティブの場所から移動する必要はありません。Oracle Virtual Directoryでは、Oracle Internet Directory、Microsoft Active Directory、Sun Java Systems Directoryなどのインスタンスに格納されているアイデンティティ・データのアプリケーション固有のビューが複数提供されており、Oracle Virtual Directoryを使用してアプリケーション固有のソースへのデータ・アクセスを保護し、既存データ・ソースに対する高可用性を向上させることができます。これらの機能により、迅速にアプリケーションのデプロイメントを行うことができ、アプリケーションをデプロイする前にユーザー情報を統合する必要がないため、費用が削減されます。Oracle Virtual Directoryを使用すると、ユーザー・リポジトリの追加、変更または削除によって変化するアイデンティティ全体に、これらのアプリケーションを適応させることができます。Oracle Virtual Directoryには、次の利点があります。

- 複数のディレクトリの整理統合

- ディレクトリ・サービスの仮想化および配布の提供

- 管理コストの削減とセキュリティの向上

- エンタープライズ・アプリケーションの迅速な拡張

- 情報に対するユビキタスなアクセスの提供

- 実装のコスト削減

関連項目:
Oracle Fusion Middleware Oracle Virtual Directory管理者ガイド

Oracle Directory Integration Platformは、インタフェースとサービスの集合であり、Oracle Internet Directoryおよび関連するプラグインやコネクタを使用して複数のディレクトリを統合します。これには次の利点があります。

- すべてのOracleコンポーネントでは、Oracle Internet Directoryを使用することが事前に認証されています。

- サード・パーティの各ディレクトリをOracle Internet Directoryに統合することによって、Oracle環境全体をサード・パーティ・ディレクトリに簡単に統合できます。したがって、各アプリケーションを各ディレクトリと統合する必要はありません。

関連項目:
Oracle Fusion Middleware Oracle Directory Integration Platform管理者ガイド

2 Oracle Fusion Middleware内のOracle Internet Directoryの理解

この章では、Oracle Internet Directoryに影響を与えるOracle Fusion Middlewareのいくつかの機能について説明します。11gリリース1 (11.1.1)では、Oracle Internet Directoryは、Oracle Fusion Middleware (Oracle WebLogic Serverを使用する共通管理インフラストラクチャ)に統合されています。

この章の内容は次のとおりです。

- 第2.1項「WebLogic Serverドメイン」

- 第2.2項「システム・コンポーネントとしてのOracle Internet Directory」

- 第2.3項「Oracle Internet Directoryのデプロイメント・オプション」

- 第2.4項「ミドルウェア・ホーム」

- 第2.5項「WebLogic Serverホーム」

- 第2.7項「Oracleホーム」

- 第2.8項「Oracleインスタンス」

- 第2.9項「Oracle Enterprise Manager Fusion Middleware Control」

- 第2.10項「ロギング、監査および診断」

- 第2.11項「MBeanおよびWebLogic Scripting Tool」

関連項目:
『Oracle Fusion Middleware管理者ガイド』のOracle Fusion Middlewareの概念の理解に関する項

2.1 WebLogic Serverドメイン

WebLogic Server管理ドメインは、論理的に関連するJavaコンポーネントのグループです。ドメインには、管理サーバーと呼ばれる特別なWebLogic Serverインスタンスが含まれ、これがドメイン内のすべてのリソースを構成および管理する中心です。通常、管理対象サーバーと呼ばれるその他のWebLogic Serverインスタンスを含むようドメインを構成します。Webアプリケーション、Webサービスやその他のリソースなどのJavaコンポーネントを管理対象サーバーにデプロイし、管理サーバーを構成および管理用途にのみ使用します。管理対象サーバーはクラスタにまとめることができます。

2.2 システム・コンポーネントとしてのOracle Internet Directory

Oracle Internet Directoryはシステム・コンポーネントです。つまり、Oracle WebLogic Serverではない管理可能なプロセスです。システム・コンポーネントは、Oracle Enterprise Manager Fusion Middleware Control、監査フレームワーク、MBeanを使用した構成管理、Secure Sockets Layerとウォレットの管理などの管理サービスにWebLogic管理ドメインを使用できます。Oracle WebLogic Server管理サーバーは、OPMNを介してOracle Internet Directoryと他のシステム・コンポーネントを制御します。

Oracle Internet Directory自体はCベースのプロセスです。実行時に依存するのはOracle Databaseのみです。Oracle Internet DirectoryをOracle Fusion Middleware管理フレームワークで管理するには、インストール時またはインストール後にコマンド行からローカルまたはリモートのOracle WebLogic Server管理ドメインに登録する必要があります。このため、Oracle Internet Directory 11gのインストールには、ローカルまたはリモートのOracle WebLogic Serverインストールが必要です。また、ディレクトリ管理ユーザー・インタフェースであるODSMは、Oracle WebLogic ServerにデプロイされているJavaコンポーネントです。

コマンド行ツールおよびリモートのODSMのみを使用してデプロイメント内のOracle Internet Directoryを管理する必要がある場合、Oracle WebLogic Serverドメインに登録せずにOracle Internet Directoryをインストールおよび構成することもできます。

2.3 Oracle Internet Directoryのデプロイメント・オプション

インストール時、Oracle Internet Directoryには次の4つのデプロイメント・オプションがあります。

1. 新規ドメインの作成: ローカルのOracle WebLogic Serverドメインを使用するOracle Internet Directory。Oracle WebLogic ServerがOracle Internet Directoryとともにローカルにインストールされ、Oracle Internet Directory用に管理ドメインが作成されます。

2. 既存のドメインの拡張: リモートのOracle WebLogic Serverドメインを使用するOracle Internet Directory。Oracle WebLogic Server管理サーバーとドメインは別途インストールおよび作成され、Oracle Internet Directoryはリモートでドメインに登録されます。

3. クラスタを開く: 高可用性のための、Oracle WebLogic ServerクラスタでのOracle Internet Directory。このオプションについてはここでは説明しません。

4. ドメインなしの構成: Oracle WebLogic ServerドメインがないOracle Internet Directory。Oracle Internet DirectoryはOracle WebLogic Serverなしでインストールおよび構成され、Oracle WebLogic Server管理ドメインに登録されません。この場合にOracle Internet Directoryは、Oracle Enterprise Manager Fusion Middleware Control、Oracle WebLogic Scripting Tool (WLST)または他の通常のOracle Fusion Middleware管理サービスによって管理することはできません。opmnctlなどのコマンド行ユーティリティやLDAPツールを使用する必要があります。ODSMを別途デプロイし、Oracle Internet Directoryの管理に使用できます。

ドメインの新規作成または既存のドメインの拡張を選択すると、作成するOracle Internet Directoryコンポーネントはインストールの完了時にそのドメインに登録されます。

「ドメインなしの構成」を選択すると、Oracle Internet Directoryコンポーネントは、インストールの完了時にどのドメインにも登録されません。コマンド行ツールopmnctlを使用してコンポーネントをWebLogicドメインに登録するまで、Oracle Enterprise Manager Fusion Middleware Controlを使用してOracle Internet DirectoryまたはそのOracleインスタンスの他のコンポーネントを管理することはできません。

2.4 ミドルウェア・ホーム

ミドルウェア・ホームは、WebLogic Serverホームと、オプションである1つ以上のその他のOracle製品のホーム(Oracleホームとも呼ばれる)で構成されます。ミドルウェア・ホームはローカル・ファイル・システム、またはNFSを介してアクセスするリモート共有ディスクにあります。Oracle Fusion Middlewareホームは、パス名ではMW_HOMEと表されます。

2.5 WebLogic Serverホーム

WebLogic Serverホームには、WebLogic Serverのホスティングに必要なファイルがインストールされています。WebLogic Serverホーム・ディレクトリは、ミドルウェア・ホーム・ディレクトリ下の他のOracleホーム・ディレクトリのピアです。パス名では、WLS_HOMEと表されます。

2.6 Oracle共通ホーム

Oracleホームには、Oracle Enterprise Manager Fusion Middleware ControlおよびJava Required Files(JRF)で必要なバイナリ・ファイルとライブラリ・ファイルが含まれています。各Middlewareホームに配置できるOracle共通ホームは1つだけです。パス名では、ORACLE_COMMON_HOMEと表されます。

2.7 Oracleホーム

Oracleホームには、特定のソフトウェア・スイートのホスティングに必要なファイルがインストールされています。Oracleホームは、ミドルウェア・ホームのディレクトリ構造の内部にあります。各Oracleホームは複数のOracleインスタンスと関連付けることができます。

Oracleホームは、通常パス名ではORACLE_HOMEと表されます。各Oracleホームは複数のOracleインスタンスまたはWebLogic Serverドメインと関連付けることができます。

2.8 Oracleインスタンス

11g リリース1では、製品構成データは製品バイナリとは区別されます。製品バイナリはOracleホーム(ORACLE_HOME)にあり、更新可能ファイルはOracleインスタンス(パス名ではORACLE_INSTANCEと表される)にあります。

大半のOracle Internet Directoryコマンドで、環境変数ORACLE_INSTANCEをORACLE_INSTANCEの値に設定する必要があります。この変数は、UNIXまたはLinuxシステムでは$ORACLE_INSTANCEとして、Windowsでは%ORACLE_INSTANCE%として間接参照します。

構成ファイル、リポジトリ、ログ・ファイル、デプロイされたアプリケーションおよび一時ファイルは、すべてOracleインスタンスに格納されます。更新可能なファイルを更新不可のファイルと別にすると、パッチ適用、アップグレード、バックアップとリストア、クローニングなどの管理タスクが容易になります。これにより、管理者は実行時とインストール時のバイナリを個々のライフ・サイクルにあわせることができます。

Oracleインスタンスはディスクの物理的な場所を参照するのみでなく、関連するプロセスも含みます。Oracleインスタンスには、Oracle Virtual Directory、Oracle Internet Directoryなどの1つ以上のアクティブなミドルウェア・システム・コンポーネントが含まれます。インストール時、または後のインスタンスの作成および構成時に、どのコンポーネントをインスタンスの一部にするかを決定します。

Oracle Internet Directoryをホスト・コンピュータにインストールすると、Oracle Identity Management 11gインストーラによってタイプOIDのOracle Fusion Middlewareコンポーネントが新規または既存のOracleインスタンスに作成されます。最初のOracle Internet Directoryコンポーネントのコンポーネント名はoid1です。

Oracle Internet Directoryのインストール時、Oracle Identity Management 11gインストーラによって次のようないくつかのディレクトリもOracleインスタンスの下のファイル・システム内に作成されます。

ORACLE_INSTANCE/config/OID/componentName
ORACLE_INSTANCE/diagnostics/logs/OID/componentName
ORACLE_INSTANCE/diagnostics/logs/OID/tools
ORACLE_INSTANCE/OID/admin
ORACLE_INSTANCE/OID/admin/SSLwallet-name
ORACLE_INSTANCE/OID/load
ORACLE_INSTANCE/tmp

2.9 Oracle Enterprise Manager Fusion Middleware Control

リリース11gでは、Oracle Internet Directoryの多数の機能の作成、構成および管理には、Oracle Enterprise Manager Fusion Middleware ControlとOracle Directory Services Managerを使用します。

Fusion Middleware Controlでは、すべてのOracle製品を1つのユーザー・インタフェースから構成および管理できます。コマンド行で実行できるほとんどの構成機能は、Fusion Middleware Controlで実行できます。Oracle Enterprise Manager Fusion Middleware Controlには、レプリケーションの設定や、サイズ設定およびチューニングの要件の見積りを行うウィザードも含まれています。

Oracle Directory Services Managerは、Oracle Internet DirectoryおよびOracle Virtual Directory用の追加管理インタフェースです。これには、Oracle Enterprise Manager Fusion Middleware Controlからアクセスしたり、固有のURLから直接アクセスできます。

2.10 ロギング、監査および診断

Oracle Enterprise Manager Fusion Middleware Controlを使用すると、Oracle Internet Directory Serverや、関連するコンポーネントおよびアクティビティをモニターできます。

モニタリング機能を使用して、合計ログイン数、成功および失敗したログイン数、平均ログイン時間、リクエスト待機時間、LDAP接続など、システム・アクティビティとパフォーマンスに関する詳細を確認できます。

次をモニターできます。

- メトリック: システム状態のモニター

- 一般: ロード、パフォーマンス、セキュリティ、ログイン、CPU使用率、その他データの高度なロールアップ

- パフォーマンス: ディレクトリ・サーバーおよびそのホストの主要なメトリック

- レポート: 操作の成功および失敗に関するデータ

- トポロジ: Oracle HTTP Serverインスタンス、ディレクトリ・サーバー・インスタンス、関連付けられているデータベースおよび他のコンポーネントに関する情報

2.11 MBeanおよびWebLogic Scripting Tool

Oracle WebLogic Scripting Tool (WLST)は、Oracle WebLogic Serverドメインの作成、管理およびモニターに使用するコマンド行スクリプト環境です。これは、Javaのスクリプト・インタプリタであるJythonがベースとなっています。WLSTを使用して一部のOracle Internet Directory管理操作を実行できます。

マネージドBean(MBean)は、分散環境でのアプリケーション、サービス、コンポーネント、デバイスなどのJMX管理可能なリソースを表すJavaオブジェクトです。Oracle Internet DirectoryをOracle WebLogic Server管理ドメインに登録すると、Oracle Internet Directory MBeanがOracle WebLogic Server管理サーバーにデプロイされます。これらのMBeanによって、Oracle Enterprise Manager Fusion Middleware ControlまたはWLSTを使用したOracle Internet Directory構成の管理が可能になります。

関連項目:
Oracle Fusion Middleware管理者ガイド

3 Oracle Internet Directoryの概念およびアーキテクチャの理解

この章では、Oracle Internet Directoryのアーキテクチャと、Oracle Internet Directoryの基本要素(ディレクトリ・エンティティ、属性、オブジェクト・クラス、ネーミング・コンテキスト、セキュリティ管理など)の概念について説明します。

この章の内容は次のとおりです。

- 第3.1項「Oracle Internet Directoryのアーキテクチャ」

- 第3.2項「Oracle Internet Directoryによる検索リクエストの処理方法」

- 第3.3項「ディレクトリ・エントリ」

- 第3.4項「属性」

- 第3.5項「オブジェクト・クラス」

- 第3.6項「ネーミング・コンテキスト」

- 第3.7項「セキュリティ」

- 第3.8項「グローバリゼーション・サポート」

- 第3.9項「分散ディレクトリ」

- 第3.10項「ナレッジ参照と参照」

- 第3.11項「Oracle Delegated Administration ServicesとOracle Internet Directoryセルフサービス・コンソール」

- 第3.12項「サービス・レジストリとサービス・ツー・サービス認証」

- 第3.13項「Oracle Directory Integration Platform」

- 第3.14項「Oracle Internet Directoryとアイデンティティ管理」

- 第3.15項「TCPキープ・アライブ」

- 第3.16項「リソース情報」

関連項目:
LDAP準拠のディレクトリに関する参考文献のリストは、「関連ドキュメント」を参照してください。

3.1 Oracle Internet Directoryのアーキテクチャ

この項の項目は次のとおりです。

- 第3.1.1項「Oracle Internet Directoryのノード」

- 第3.1.2項「Oracleディレクトリ・サーバー・インスタンス」

- 第3.1.3項「Oracle Internet Directoryのポート」

- 第3.1.4項「ディレクトリ・メタデータ」

3.1.1 Oracle Internet Directoryのノード

Oracle Internet Directoryのノードは、同じディレクトリ・ストアに接続された1つ以上のディレクトリ・サーバー・インスタンスで構成されます。ディレクトリ・ストア(ディレクトリ・データのリポジトリ)は、Oracle Databaseです。

注意:
同じドメイン内のすべてのOracle Internet Directoryインスタンスは、同じOracle Databaseに接続します。

図3-1は、単一ノードで実行される様々なディレクトリ・サーバーの要素とその関係を示しています。

Oracleデータベース・サーバーと次のものとの接続には、いずれもOracle Net Servicesが使用されます。

- Oracleディレクトリ・サーバー非SSLポート(デフォルトでは3060)

- Oracleディレクトリ・サーバーSSL対応ポート(デフォルトでは3131)

- OIDモニター

LDAPは、ディレクトリ・サーバーと次のものとの間の接続に使用されます。

- Oracle Directory Services Manager

- Oracleディレクトリ・レプリケーション・サーバー

Oracleディレクトリ・サーバー・インスタンスとOracleディレクトリ・レプリケーション・サーバーは、オペレーティング・システム経由でOIDモニターに接続します。

注意:
Oracle Internet Directory 11 gリリース1(11.1.1.7.0)以降、Oracle Databaseにキープ・アライブ・メッセージを送信するためにOracle Internet DirectoryサーバーでOCIPing()をコールするように指定できます。こうしたメッセージの頻度は、新しいorclMaxTcpIdleConnTime属性によって決定されます。
この属性に、Oracle Internet DirectoryサーバーとOracle Database間のファイアウォールのタイムアウト値よりも小さい値を設定することによって、データベース接続の切断が避けられます。

詳細は、第9.1.4項「DSA構成エントリの属性」を参照してください。

図3-1 一般的なOracle Internet Directoryのノード

図3-1に示すとおり、Oracle Internet Directoryのノードには、次の主なコンポーネントがあります。

表3-1 Oracle Internet Directoryのノード

要素

説明

Oracleディレクトリ・サーバー・インスタンス

LDAPサーバー・インスタンスまたはディレクトリ・サーバー・インスタンスとも呼ばれ、特定のTCP/IPポートでリスニングする単一のOracle Internet Directoryディスパッチャ・プロセスを介して、ディレクトリ・リクエストに応答します。1つのノードに、異なるポートでリスニングする複数のディレクトリ・サーバー・インスタンスを設定できます。

Oracleディレクトリ・レプリケーション・サーバー

レプリケーション・サーバーとも呼ばれ、他のOracle Internet Directoryシステム内のレプリケーション・サーバーの変更を追跡し、その内容を送信します。1つのノード上に設定できるレプリケーション・サーバーは1つのみです。レプリケーション・サーバーを構成するかどうかは選択できます。

Oracleデータベース・サーバー

ディレクトリ・データを格納します。データベースは、ディレクトリ・サーバー・インスタンスと同じノードに置くことができます。

注意: 顧客データのサイズが増大するにつれてOracle Internet Directoryで大量のデータ容量が必要になる可能性に備え、またデータベース問合せの最適なパフォーマンスを常に実現するために、データベースをこのディレクトリ専用に使用することを強くお薦めします。

Oracle Process Manager and Notification Server(OPMN)

Oracle Internet DirectoryをOracle Fusion Middlewareシステム・コンポーネントとして管理します。OPMNは、ORACLE_INSTANCE/config/OPMN/opmn/opmn.xmlのOIDコンポーネント・スニペット内のディレクティブを使用し、必要に応じてOIDMONおよびOIDCTLを起動します。コマンド行ユーティリティは、ORACLE_INSTANCE/bin/opmnctlです。

OIDモニター(OIDMON)

LDAPサーバー・プロセスおよびレプリケーション・サーバー・プロセスを開始、モニターおよび終了します。oidctl、opmnctlなどのプロセス管理コマンドを呼び出す場合、またはFusion Middleware Controlを使用してサーバー・インスタンスを起動または停止する場合は、このプロセスによってコマンドが解釈されます。

また、OIDMONはサーバーをモニターし、異常な理由で実行が停止した場合に再起動させます。

OIDMONは、OIDLDAPDのデフォルトのインスタンスを起動します。OIDLDAPDのデフォルト・インスタンスがOIDCTLコマンドを使用して停止されると、OIDMONはインスタンスを停止します。ただし、OPMNによってOIDMONが再起動すると、OIDMONはデフォルトのインスタンスを再起動します。

OIDモニターのすべてのアクティビティは、
ORACLE_INSTANCE/diagnostics/logs/OID/Component_Name/oidmon-xxxx.logファイルに記録されます。このファイルは、Oracle Internet Directoryサーバー・ファイル・システム上にあります。

OIDモニターは、オペレーティング・システムに用意されているメカニズムを通して、サーバーの状態をチェックします。

OID制御ユーティリティ(OIDCTL)

Oracle Internet Directoryのサーバー表にメッセージ・データを格納することによって、OIDモニターと通信します。このメッセージ・データには、各Oracleディレクトリ・サーバー・インスタンスの実行に必要な構成パラメータが含まれています。通常は、レプリケーション・サーバーを起動および停止するためにのみ、コマンド行から使用されます。OIDCTLは、Oracle Internet Directoryのステータスの確認にも使用されます。

Oracleディレクトリ・レプリケーション・サーバーはLDAPを使用して、Oracleディレクトリ(LDAP)サーバー・インスタンスと通信します。データベースとの通信には、すべてのコンポーネントでOCI/Oracle Net Servicesを使用します。Oracle Directory Services Managerとコマンド行ツールは、LDAPを介してOracleディレクトリ・サーバーと通信します。

3.1.2 Oracleディレクトリ・サーバー・インスタンス

図3-2に、LDAPサーバー・インスタンスとも呼ばれるOracleディレクトリ・サーバー・インスタンスを示します。

図3-2 Oracleディレクトリ・サーバー・インスタンスのアーキテクチャ

1つのインスタンスは、1つのディスパッチャ・プロセスと1つ以上のサーバー・プロセスで構成されます。Oracle Internet Directoryのディスパッチャ・プロセスとサーバー・プロセスでは、複数のスレッドを使用して負荷が分散されます。LDAPクライアントは、ポートでLDAPコマンドをリスニングしているOracle Internet Directoryリスナー/ディスパッチャ・プロセスにLDAPリクエストを送信します。

Oracle Internet Directoryリスナー/ディスパッチャは、起動時に構成されている数のサーバー・プロセスを起動します。サーバー・プロセスの数は、インスタンス固有の構成エントリのorclserverprocs属性によって制御されます。orclserverprocsのデフォルト値は1です。複数のサーバー・プロセスを使用することで、Oracle Internet Directoryでマルチ・プロセッサ・システムの利点を活かすことができます。

Oracle Internet Directoryディスパッチャ・プロセスは、Oracle Internet Directoryサーバー・プロセスへのLDAP接続をラウンドロビン方式で送信します。各サーバーに受け入れられるLDAP接続の最大数は、デフォルトでは1024です。この数は、次の形式の識別名を持つインスタンス固有の構成エントリの属性orclmaxldapconnsを変更することで増やすことができます。

cn=componentname,cn=osdldapd,cn=subconfigsubentry

3.1.3 Oracle Internet Directoryのポート

Oracle Internet Directoryコンポーネントは、Oracle Identity Management 11gインストーラによっても、コマンド行ツールでも作成できます。Oracle Internet Directoryを作成するプログラムは特定の手順に従ってSSLおよび非SSLポートを割り当てます。まず、非SSLポートとして3060の使用を試みます。そのポートが使用できない場合、3061から3070の範囲のポートを試し、次に13060から13070の範囲のポートを試します。

同様に、Oracle Internet Directoryを作成するプログラムは、SSLポートとして3131を試し、次に3132から3141の範囲のポート、その後13131から13141の範囲のポートを試します。

3.1.4 ディレクトリ・メタデータ

ディレクトリ・メタデータは、ディレクトリ・サーバーが実行中にLDAPリクエストを処理するために使用する情報です。基礎となるデータ・リポジトリに格納されます。起動中に、ディレクトリ・サーバーはこの情報を読み取って、ローカル・メタデータ・キャッシュに格納します。実行中にこのキャッシュを使用して、着信LDAP操作リクエストを処理します。

注意:
メタデータ・キャッシュはライトスルー・キャッシュです。LDAP操作では、最初にデータベースに書き込み、次に対応するキャッシュ・エントリを無効化します。このエントリをその後検索すると、キャッシュがリフレッシュされます。

ディレクトリ・サーバーのローカル・メタデータ・キャッシュには、次の種類のメタデータが格納されます。

- ディレクトリ・スキーマ
ディレクトリ・サーバーによりサポートされるオブジェクト・クラス、属性、一致規則の定義。ディレクトリ・サーバーは、ディレクトリ・オブジェクトの作成および変更時にこの情報を使用します。ディレクトリ・オブジェクトとは、オブジェクト・クラスおよびそれに関連付けられた属性と一致規則の集合です。第21章「ディレクトリ・スキーマの管理」を参照してください。

- アクセス制御ポリシー・ポイント(ACP)
ドメインにある情報へのアクセスを定義し、制御するためのディレクトリ管理ドメイン。ディレクトリ・サーバーは、特定のLDAP操作をユーザーが実行できるかどうかを判断するときにACPを使用します。第30章「ディレクトリ・アクセス制御の管理」を参照してください。

- ルートDSEエントリ
ルートDSE(ディレクトリ・サービス・エージェント固有のエントリ)には、ディレクトリ・サーバー自体に関する情報を格納する複数の属性が入っています。これらの属性には次のような情報項目が含まれます。

- ネーミング・コンテキスト識別名

- サブ・スキーマ・サブエントリ識別名

- 上位参照(参照)識別名

- Oracle Internet Directory構成コンテナやレジストリ・コンテナのような特殊なエントリ識別名

- 変更ログ・コンテナや変更ステータス・コンテナのような特殊なエントリ識別名

- レプリケーション承諾コンテナの識別名

「DSEの属性」を参照してください。

- 権限グループ
アクセス制御ポリシーで使用できるグループ。

ディレクトリ・スキーマは、標準のgroupofuniquenamesオブジェクト・クラスとgroupofnamesオブジェクト・クラスによってディレクトリ・グループ・オブジェクトをサポートします。これらのオブジェクト・クラスは、配布リストやメーリング・リストのようなグループに関する情報を格納します。

Oracle Internet Directoryは、orclprivilegegroupと呼ばれる補助オブジェクト・クラスによって、これらの標準グループ・オブジェクトを拡張します。このオブジェクト・クラスは、アクセス制御ポリシーで使用できる権限グループをサポートし、ユーザーのグループに対するアクセスの許可や拒否を柔軟に行えるようにします。ディレクトリ・サーバーはこの情報を次の場合に使用します。

- 特定のユーザーに関してサブスクライブされた権限グループを検索するためのLDAPバインド操作

- 権限が付与されたグループに対するアクセスを許可または拒否するディレクティブがポリシーにあるかどうかのアクセス制御ポリシーの評価

関連項目:
第14章「動的グループと静的グループの管理」

- カタログ・エントリ
基礎となるデータベースで索引付けされた属性に関する情報を入れる特別なエントリ。ディレクトリは、ディレクトリ検索操作中にこの情報を使用します。「属性の索引付けについて」を参照してください。

- 共通エントリ
ホスティングされた企業に関する情報を入れる特別なエントリ。ホスティングされた企業とは、別の企業からサービスを提供される企業です。このエントリのメタデータには、ホスティングされた企業の識別名、ユーザー検索ベース、ニックネームなどの属性が入っています。詳細は、第34章「レルムの計画、デプロイおよび管理」を参照してください。

- プラグイン・エントリ
プラグイン・イベントをトリガーする操作の種類と、操作のどの時点でそのプラグインをトリガーするかに関する情報を入れる特別なエントリ。この詳細は、第45章「Oracle Internet Directoryサーバー・プラグインの開発」を参照してください。

- パスワード検証エントリ
暗号タイプとベリファイア属性タイプに関する情報を入れる特別なエントリ。この詳細は、第31章「パスワード・ベリファイアの管理」を参照してください。

- パスワード・ポリシー・エントリ
ユーザー・パスワード資格証明についてディレクトリ・サーバーにより施行されるポリシーに関する情報の入った、1つ以上の特別なエントリ。ディレクトリ・サーバーは、パスワード・ポリシーを施行するために実行時にこの情報を使用します。第29章「パスワード・ポリシーの管理」を参照してください。

3.2 Oracle Internet Directoryによる検索リクエストの処理方法

この項では、次の検索操作について説明します。

- 第3.2.1項「標準LDAP検索操作」

- 第3.2.2項「永続LDAP検索操作」

3.2.1 標準LDAP検索操作

この例では、Oracle Internet Directoryがどのように検索リクエストを処理するかを示します。

1. ユーザーまたはクライアントが検索リクエストを入力します。検索条件は、次の1つ以上のオプションによって決まります。

- SSL: クライアントとサーバーは、SSLの暗号化と認証またはSSLの暗号化のみを使用するセッションを確立できます。SSLが使用されていない場合、クライアントのメッセージは平文で送信されます。

- ユーザーのタイプ: ユーザーは、要求する機能の実行に必要な権限を持っているかどうかによって、特定のユーザーまたは匿名ユーザーのいずれかでディレクトリへのアクセスを要求できます。

- フィルタ: ユーザーは、1つ以上の検索フィルタを使用して検索条件を絞り込むことができ、検索フィルタには、ブール条件and、or、notの他に、greater than、equal to、less thanなどの演算子を使用するものがあります。

2. C APIは、LDAPプロトコルを使用して、ディレクトリへの接続リクエストをディレクトリ・サーバー・インスタンスに送信します。

3. ディレクトリ・サーバーはユーザーを認証し、このプロセスはバインドと呼ばれます。ディレクトリ・サーバーは、アクセス制御リスト(ACL)もチェックして、そのユーザーが、リクエストした検索の実行を許可されているかどうかを検証します。

4. ディレクトリ・サーバーは、LDAPからの検索リクエストをOracle Call Interface (OCI)およびOracle Net Servicesに変換し、Oracle Databaseに送信します。

5. Oracle Databaseは、情報を取得し、その情報をディレクトリ・サーバー、C API、クライアントの順に返します。

注意:
検索フィルタに指定できる属性の最大数は255です。

3.2.2 永続LDAP検索操作

リリース11gR1 (11.1.1.9)以降では、Oracle Internet Directoryで永続検索操作がサポートされます。永続検索は、初期検索の結果がOracle Internet DirectoryサーバーからLDAPクライアントに返された後も継続します。初期検索の終了後も、サーバーに対する接続は、クライアントが操作をバインド解除するか中止するまで維持されます。

永続検索操作によって、クライアントは、検索範囲のエントリが変更された場合に通知を受信できます。エントリが変更されると、サーバーは、そのエントリの新しいコピーをLDAPクライアントに送信し、リクエストがあれば、その変更を記述したエントリ変更通知制御を含めます。

永続検索操作では、次の制御を使用します。

- 永続検索制御 - LDAPクライアントは、Oracle Internet Directoryサーバーに対して、検索結果を返すための特定のオプションを含む永続検索リクエストとともにこの制御を送信します。

- エントリ変更通知制御 - クライアントからリクエストされると、サーバーは、検索リクエストの検索基準に一致する変更されたエントリごとに、クライアントにこの制御を返します。

永続検索は、構成エントリ、参照、エントリ別名などの特殊なエントリではサポートされません。

永続検索では、LDAPクライアントからサーバーへの接続を維持する必要があります。そのため、永続検索が大量に実行されると、LDAPの接続制限に達して新しい接続を確立できなくなる可能性があります。この状況の発生を避けるには、インスタンス固有の属性であるorclmaxpsearchconnsによって、LDAP永続検索操作に対して許可する最大接続数を指定します。

Oracle Internet DirectoryのLDAP永続検索操作の手順は、次のとおりです。

1. LDAPクライアントは、Oracle Internet Directoryサーバーに対して認証を行います。

2. クライアントは、アタッチされた永続検索制御とともに永続検索リクエストを発行します。この制御には、次の情報が指定されます。

- changesOnly - このフィールドがFALSEの場合、サーバーは、検索基準に一致する結果の初期セットを返します。または、このフィールドがTRUEの場合、サーバーはそれらのエントリを返しません。

- changeTypes - このフィールドは、クライアントが追跡する変更のタイプを指定します。検索基準に一致するエントリに対して後続の変更が行われると、サーバーは、それらの変更されたエントリをクライアントに返します。
changeTypesフィールドは、次の1つ以上の値の論理ORです。

- add: 1

- delete: 2

- modify: 4

- moddn: 8

- returnECs - このフィールドがTRUEの場合、サーバーは、変更された各エントリとともにエントリ変更通知制御も返します。

3. OIDサーバーは、前の手順で説明したオプションを使用して永続検索リクエストを処理します。
接続は、クライアントが操作をバインド解除するか中止するまで維持する必要があるため、サーバーはクライアントにSearchResultDoneメッセージを返しません。

4. サーバーが検索結果を返すと、クライアントは、必要に応じてそれらの結果を処理します。

5. LDAPクライアントは、バインド解除または中止のリクエストを送信して、永続検索操作を終了します。

関連項目:

- orclmaxpsearchconns属性の詳細は、表9-1「インスタンス固有の構成エントリの属性」を参照してください。

- 永続検索制御とエントリ変更通知制御の詳細は、『Oracle Fusion Middleware Oracle Identity Managementアプリケーション開発者ガイド』の「LDAPプロトコルに対する拡張機能」を参照してください。

- Internet Engineering Task Force (IETF)ドキュメント - 永続検索: 単純なLDAP変更通知メカニズム
http://tools.ietf.org/id/draft-ietf-ldapext-psearch-03.txt

3.3 ディレクトリ・エントリ

オンライン・ディレクトリでは、オブジェクトに関する情報の集合はエントリと呼ばれます。エントリには、社員、会議室、E-Commerceパートナ、プリンタなどの共有ネットワーク・リソースに関する情報などが含まれます。

この項の項目は次のとおりです。

- 第3.3.1項「識別名(DN)とディレクトリ情報ツリー(DIT)」

- 第3.3.2項「エントリ・キャッシング」

3.3.1 識別名(DN)とディレクトリ情報ツリー(DIT)

オンライン・ディレクトリ内の各エントリは、識別名(DN)で一意に識別されます。識別名は、ディレクトリ階層におけるそのエントリの位置を正確に伝えます。この階層は、ディレクトリ情報ツリー(DIT)で示されます。

識別名とディレクトリ情報ツリーとの関係を理解するには、図3-3を参照してください。

図3-3 ディレクトリ情報ツリー

図3-3のDITには、Acme Corporationに所属する、Anne Smithという同じ名前を持つ2人の従業員のエントリが含まれています。この図のディレクトリ情報ツリーは、地理的および組織的な線で構造化されています。左のブランチに含まれているAnne Smithは、米国の販売部門に勤務しています。もう一方のAnne Smithは、英国のサーバー開発部門に勤務しています。

右のブランチのAnne Smithは、Anne Smithという一般名(cn)を持っています。彼女は、組織(o)がAcme、国(c)が英国(uk)で、Server Developmentという組織単位(ou)に勤務しています。

このAnne Smithエントリの識別名(DN)は次のとおりです。

cn=Anne Smith,ou=Server Development,c=uk,o=acme

通常、識別名の形式は、最下位のDITコンポーネントを左側に配置し、下位のコンポーネントからルートに向かって順番に配置します。

識別名内の最下位コンポーネントは、相対識別名(RDN)と呼ばれます。たとえば、前述のAnne Smithのエントリの相対識別名はcn=Anne Smithです。同様に、Anne Smithの相対識別名のすぐ上のエントリに対応する相対識別名はou=Server Development、ou=Server Developmentのすぐ上のエントリに対応する相対識別名はc=ukです。したがって、DNはDITでの親子関係を反映したRDNの連結です。DN内では、RDNはカンマで区切ります。

DIT全体の中で特定エントリを検索するために、クライアントは、そのエントリの相対識別名のみではなく、完全な識別名を使用することによって、エントリを一意に識別します。たとえば、図3-3のグローバル組織内で、この2人のAnne Smithを混同しないように、それぞれの完全な識別名を使用します。同一組織単位内に同名の従業員が2人いる可能性がある場合は、一意の識別番号で各従業員を識別するなど、補助的な方法を使用してください。

3.3.2 エントリ・キャッシング

エントリに対して迅速で効率的な操作を行うために、Oracle Internet Directoryはエントリ・キャッシングを使用します。この機能を有効にした場合、Oracle Internet Directoryは、各エントリに一意の識別子を割り当て、指定された数の識別子をキャッシュ・メモリーに格納します。ユーザーがエントリに対する操作を行うと、ディレクトリ・サーバーは、キャッシュ内でエントリ識別子を検索し、対応するエントリをディレクトリから取得します。

注意:

- リリース11g R1(11.1.1.6)から、エントリ・キャッシュが共有メモリーに配置されるようになったため、同じホスト上の複数のOracle Internet Directoryサーバー・インスタンスで同じキャッシュを共有できます。キャッシュを構成するための属性は、DSA構成エントリ内に置かれるようになりました。

- エントリ・キャッシュはライトスルー・キャッシュです。LDAP操作では、最初にデータベースに書き込み、次に対応するキャッシュ・エントリを無効化します。このエントリをその後検索すると、キャッシュがリフレッシュされます。

関連項目:

- 『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』の「Oracle Internet Directory」の章にある、サーバー・エントリ・キャッシュに関する説明の項

- 第20章「ナレッジ参照と参照の管理」

3.4 属性

一般的な電話帳の場合、個人に関するエントリには住所や電話番号などの情報項目が含まれます。オンライン・ディレクトリでは、このような情報項目は属性と呼ばれます。一般的な従業員エントリの属性には、役職名、電子メール・アドレス、電話番号などがあります。

たとえば、図3-4では、英国(uk)のAnne Smithのエントリには、複数の属性が含まれており、それぞれAnne Smith固有の情報を提供します。これらはツリーの右側の円の中にリストされ、emailaddrs、printername、jpegPhotoおよびapp preferencesなどが含まれます。さらに、図3-4の各円も、それぞれの属性は表示されませんが、複数の属性が含まれたエントリです。

図3-4 Anne Smithのエントリの属性

各属性は、属性タイプと1つ以上の属性値で構成されます。属性タイプとは、その属性に含まれている情報の種類(jobTitleなど)です。属性値は、そのエントリで表される情報の具体的な内容です。たとえば、jobTitle属性に対する値にはmanagerがあります。

この項の項目は次のとおりです。

- 第3.4.1項「属性情報の種類」

- 第3.4.2項「単一値と複数値の属性」

- 第3.4.3項「一般的なLDAP属性」

- 第3.4.4項「属性の構文」

- 第3.4.5項「属性の一致規則」

- 第3.4.6項「属性オプション」

3.4.1 属性情報の種類

属性には2種類の情報があります。

- アプリケーション属性
この情報は、ディレクトリ・クライアントによってメンテナンスおよび取得が行われ、ディレクトリの操作には影響しません。例として電話番号があります。

- システム構成属性
この情報は、ディレクトリ自体の操作に関係します。一部の操作情報(エントリの作成または変更のタイム・スタンプや、エントリを作成または変更するユーザーの名前など)は、サーバーを制御するディレクトリによって指定されます。アクセス情報などのその他の操作情報は、管理者が定義し、ディレクトリ・プログラムの処理時に、そのプログラムによって使用されます。

関連項目:
システム構成属性の詳細は、第9章「システム構成属性の管理」を参照してください。

エントリをディレクトリに追加すると、エントリの検索能力を強化するために、Oracle Internet Directoryが自動的にいくつかのシステム構成属性を作成します。次のポリシーが含まれます。

表3-2 新規エントリごとに作成される属性

属性

説明

creatorsName

エントリ作成者の名前

createTimestamp

UTC(協定世界時)でのエントリの作成時間

modifiersName

エントリ変更者の名前

modifyTimestamp

UTCでの最後のエントリ変更時間

ユーザーがエントリを変更すると、Oracle Internet Directoryでは自動的にmodifiersName属性がエントリを変更したユーザーの名前に、modifyTimestamp属性がUTCで表したエントリ変更時間にそれぞれ更新されます。

関連項目:
システム構成属性の構成方法は、第9章「システム構成属性の管理」を参照してください。

3.4.2 単一値と複数値の属性

属性は、単一値または複数値のいずれかです。単一値の属性には1つの値のみ設定でき、複数値の属性には複数の値を設定できます。複数値の属性の例には、グループ全員の名前を載せたグループ・メンバーシップ・リストがあります。

3.4.3 一般的なLDAP属性

Oracle Internet Directoryは、標準的なLDAP属性をすべて実装しています。表3-3に、Internet Engineering Task Force (IETF)のRFC 2798に定義されている、一般的なもののいくつかを示します。

表3-3 一般的なLDAP属性

属性タイプ

属性の文字列

説明

commonName

cn

エントリの一般的な名前(Anne Smithなど)。

domainComponent

dc

ドメイン・ネーム・システム(DNS)にあるコンポーネントの識別名(dc=uk,dc=acme,dc=comなど)。

jpegPhoto

jpegPhoto

JPEGフォーマットの写真イメージ。バイナリ形式で格納されます。

organization

o

組織の名前(my_companyなど)。

organizationalUnitName

ou

組織内の単位の名前(Server Developmentなど)。

owner

owner

エントリの所有者を識別する名前(cn=Anne Smith, ou=Server Development, o= Acme, c=ukなど)。

surname、sn

sn

ユーザーの姓(Smithなど)。

telephoneNumber

telephoneNumber

電話番号((650) 123-4567、6501234567など)。

関連項目:
Oracle Internet Directoryが提供する複数の属性のリストは、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のOracle Identity Management LDAP属性のリファレンスを参照してください。

3.4.4 属性の構文

属性の構文とは、各属性にロード可能なデータの形式です。たとえば、telephoneNumber属性の構文の場合、電話番号は空白やハイフンを含む一続きの数値である必要があります。しかし、別の属性の構文では、そのデータを日付書式で表すか、または数値のみで表すかの指定が必要な場合もあります。各属性の構文は必ず1つのみです。

Oracle Internet Directoryは、Internet Engineering Task Force(IETF)のRFC 2252で指定されているほとんどの構文を認識するため、そのドキュメントに記述されている構文の大部分を属性に関連付けることができます。Oracle Internet Directoryは、RFC 2252構文の認識に加え、一部のLDAP構文も適用します。Oracle Internet Directoryですでにサポートされているこれらの構文以外に、新規の構文を追加することはできません。

関連項目:
『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のLDAP属性の構文についての説明

3.4.5 属性の一致規則

ディレクトリ・サーバーは、クライアントのリクエストに応じて、検索と比較の操作を実行します。この操作時に、ディレクトリ・サーバーは関連する一致規則を調査し、検索対象の属性値と、格納されている属性値との間の等価性を判断します。たとえば、telephoneNumber属性に関連付けられた一致規則では、(650) 123-4567を(650) 123-4567または6501234567のいずれか、あるいはその両方と一致させることができます。属性の作成時に、属性を一致規則と関連付けます。

Oracle Internet Directoryは、標準的なLDAP一致規則をすべて実装しています。Oracle Internet Directoryですでにサポートされているこれらの一致規則に、新規の一致規則を追加することはできません。

関連項目:

- 一致規則の表示の詳細は、第21章「ディレクトリ・スキーマの管理」を参照してください。

- 『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のLDAP一致規則についての説明。

3.4.6 属性オプション

属性タイプには様々なオプションがあり、検索または比較操作でその属性の値をどのように使用できるかを指定できます。たとえば、ある従業員がロンドンとニューヨークという2つの住所を持っているとします。その従業員のaddress属性のオプションを使用すると、両方の住所を格納できます。

さらに、属性オプションは言語コードを含むことができます。たとえば、John DoeのgivenName属性のオプションを使用すると、彼の名前をフランス語と日本語の両方で格納できます。

オプション付きの属性とその基本属性は、明確に区別できます。オプションがない場合、両者は同じ属性です。たとえば、givenName;lang-fr=Jeanでは、基本属性はgivenNameであり、この基本属性のフランス語の値はgivenName;lang-fr=Jeanです。

1つ以上のオプションを持つ属性は、そのベース属性のプロパティ(一致規則、構文など)を継承します。前述の例を踏まえると、オプション付きの属性cn;lang-fr=Jeanは、cnのプロパティを継承します。

注意:
属性オプションは識別名内では使用できません。たとえば、識別名cn;lang-fr=Jean, ou=sales,o=acme,c=ukは不適切です。

関連項目:
第13章「ディレクトリ・エントリの管理」

3.5 オブジェクト・クラス

オブジェクト・クラスは、エントリの構造を定義する属性のグループです。ディレクトリ・エントリを定義するときは、1つ以上のオブジェクト・クラスを割り当てます。これらのオブジェクト・クラスの属性には、必須で値を指定する必要があるものもあれば、オプションで値を指定しなくてよいものもあります。

たとえば、organizationalPersonオブジェクト・クラスには、必須属性のcommonName (cn)とsurname (sn)が含まれており、オプション属性としてtelephoneNumber、uid、streetAddressおよびuserPassword.が含まれています。organizationalPersonオブジェクト・クラスを使用してエントリを定義するときは、commonName (cn)およびsurname (sn)に値を指定する必要があります。telephoneNumber、uid、streetAddressおよびuserPasswordに値を指定する必要はありません。

この項の項目は次のとおりです。

- 第3.5.1項「サブクラス、スーパークラスおよび継承」

- 第3.5.2項「オブジェクト・クラスの型」

3.5.1 サブクラス、スーパークラスおよび継承

サブクラスは、別のオブジェクト・クラスから導出されたオブジェクト・クラスです。サブクラスが導出されるオブジェクト・クラスは、そのスーパークラスと呼ばれます。たとえば、オブジェクト・クラスorganizationalPersonは、オブジェクト・クラスpersonのサブクラスです。逆に、オブジェクト・クラスpersonは、オブジェクト・クラスorganizationalPersonのスーパークラスです。

サブクラスは、そのスーパークラスの属性をすべて継承します。たとえば、サブクラスorganizationalPersonは、そのスーパークラスpersonの属性を継承しています。エントリも、そのスーパークラスが継承した属性を継承します。

注意:
オブジェクト・クラス自体に値は含まれていません。値を持つのは、オブジェクト・クラスのインスタンス、つまりエントリのみです。サブクラスがスーパークラスから属性を継承するときは、スーパークラスの属性定義のみを継承します。

topと呼ばれる、スーパークラスを持たない特別なオブジェクト・クラスが1つあります。これは、ディレクトリ内のすべてのオブジェクト・クラスのスーパークラスの1つであり、その属性定義はすべてのエントリに継承されます。

3.5.2 オブジェクト・クラスの型

オブジェクト・クラスには次の3つの型があります。

- 構造型

- 補助型

- 抽象型

3.5.2.1 構造型オブジェクト・クラス

構造型オブジェクト・クラスは、オブジェクトの基本的側面を記述します。使用するオブジェクト・クラスの大部分は構造型オブジェクト・クラスであり、すべてのエントリは少なくとも1つの構造型オブジェクト・クラスに属している必要があります。構造型オブジェクト・クラスの例としては、personやgroupOfNamesがあります。

これらのオブジェクト・クラスは、実社会のエンティティと、その物理的属性および論理的属性をモデルとしています。たとえば、人、プリンタ、データベース接続などがあります。

構造型オブジェクト・クラスは、構造規則を使用して、特定のオブジェクト・クラスの下に作成可能なオブジェクトの種類に制限を与えます。たとえば、構造規則では、organization(o)オブジェクト・クラスの下にあるすべてのオブジェクトはorganizational unit(ou)であることが要求されます。この規則に従うと、personオブジェクトをorganizationオブジェクト・クラスのすぐ下に入力することはできません。同様に、構造規則では、personオブジェクトの下にorganizational unit(ou)オブジェクトを置くことはできません。

3.5.2.2 補助型オブジェクト・クラス

補助型オブジェクト・クラスは、オプションの属性をグループ化したもので、エントリ内の既存の属性リストを拡張します。構造型オブジェクト・クラスと異なり、エントリを格納する場所に関する制限はなく、DITでのエントリの位置に関係なく、任意のエントリに置くことができます。

注意:
Oracle Internet Directoryは、構造規則を強制しません。したがって、構造型オブジェクト・クラスと補助型オブジェクト・クラスは同様に処理されます。

3.5.2.3 抽象型オブジェクト・クラス

抽象型オブジェクト・クラスは、仮想のオブジェクト・クラスです。これは、便宜上、オブジェクト・クラス階層の最上位レベルを指定する際にのみ使用されます。エントリに対する唯一のオブジェクト・クラスにすることはできません。たとえば、オブジェクト・クラスtopは抽象型オブジェクト・クラスです。これは、すべての構造型オブジェクト・クラスに対するスーパークラスとして必要ですが、単独では使用できません。

topオブジェクト・クラスには、必須属性であるobjectClassの他に、次のオプション属性があります。top内のオプション属性は次のとおりです。

- orclGuid: エントリが移動しても変わらないグローバル識別子

- creatorsName: オブジェクト・クラス作成者の名前

- createTimestamp: オブジェクト・クラスが作成された時間

- modifiersName: オブジェクト・クラスを最後に変更したユーザーの名前

- modifyTimestamp: オブジェクト・クラスが最後に変更された時間

- orclACI: この属性が定義されているアクセス制御ポリシー・ポイント(ACP)の下のサブツリーにあるすべてのエントリに適用されるアクセス制御リスト(ACL)ディレクティブ

- orclEntryLevelACI: 特殊なユーザーなどの特定のエンティティのみに関連するアクセス制御ポリシー

関連項目:

- アクセス制御ポリシーおよびACLの詳細は、第3.8項「グローバリゼーション・サポート」

- エントリにコンテンツを追加する方法の詳細は、第21.1.3項「属性の理解」

3.6 ネーミング・コンテキスト

ディレクトリ・ネーミング・コンテキストは、全体が1つのサーバーに存在するサブツリーです。完全なサブツリーである必要があります。つまり、サブツリーの頂点となるエントリから始まり、下位方向にリーフ・エントリまたは従属ネーミング・コンテキストへの参照のいずれかまでを範囲とする必要があります。単一エントリからディレクトリ情報ツリー(DIT)全体までをサイズの範囲とすることができます。

図3-5に、適切なネーミング・コンテキストと不適切なネーミング・コンテキストを示します。左側の適切なコンテキストは連続しており、右側の不適切なコンテキストは連続していないことに注意してください。

図3-5 適切なネーミング・コンテキストと不適切なネーミング・コンテキスト

ユーザーが特定のネーミング・コンテキストを検出できるようにするには、ldapmodifyを使用して、Oracle Internet Directoryでそれらのネーミング・コンテキストを公開する必要があります。

関連項目:
ネーミング・コンテキストの公開方法は、第11章「ネーミング・コンテキストの管理」を参照してください。

3.7 セキュリティ

Oracle Internet Directoryは、Oracle Identity Managementの重要な要素です。これを使用すると、複数のOracleコンポーネントをOracle Internet Directoryの共有インスタンスに対して機能するようにデプロイできます。この共有により、企業はすべてのアプリケーションでセキュリティ管理を単純化できます。

Oracle Identity Managementインフラストラクチャで果す役割に加えて、Oracle Internet Directoryは情報を保護するための多数の強力な機能を提供します。

Oracle Internet Directory自体に、次のようなセキュリティ機能があります。

- Secure Sockets Layer: 伝送中にデータが変更、削除または再現されていないことを保証します。

- データ・プライバシ: データがOracle Internet Directoryに格納されている間に不適切に参照されていないことを保証します。

- パスワード・ポリシー: パスワードの定義方法と使用方法に関する規則を確立し、適用することを保証します。

- 認可:ユーザーが権限を持つ情報のみを読み取りまたは更新することを保証します。

- パスワード保護: 第三者がパスワードを簡単に解読できないことを保証します。

- 認証: ユーザー、ホストおよびクライアントのアイデンティティが正しく検証されていることを保証します。

これらの機能をすべて使用して、Oracle Internet Directoryを使用できる複数のアプリケーションに一貫したセキュリティ・ポリシーを適用できます。企業またはホスティングされた環境ではこのようにすることをお薦めします。このためには、管理業務の委任を行うためのディレクトリをデプロイします。このデプロイメントによって、たとえば、グローバル管理者は、部門にあるアプリケーションのメタデータに対するアクセスをその部門の管理者に委任できます。その結果、部門の管理者が自部門のアプリケーションへのアクセスを制御できるようになります。

基礎となるOracle Databaseのセキュリティ機能(透過的データ暗号化、Database Vaultなど)を使用しても、Oracle Internet Directoryデータを保護できます。

関連項目:
第III部「拡張管理: セキュリティ」

3.8 グローバリゼーション・サポート

Oracle Internet Directoryは、LDAPバージョン3国際化(I18N)規格に準拠しています。この規格では、ディレクトリ・データを格納するデータベースでUnicode Transformation Format 8-bit(UTF-8)文字セットを使用する必要があります。Oracle9iでは、AL32UTF8と呼ばれる新しいUTF-8文字セットを追加しました。このデータベース文字セットは、最新の補助文字を含む最新バージョンのUnicode(3.2)をサポートしています。これにより、Oracle Internet Directoryは、Oracleグローバリゼーション・サポートがサポートするほとんどすべての言語の文字データを格納できます。また、Oracle Internet Directoryの実装では異なるApplication Program Interface(API)がいくつか含まれていますが、Oracle Internet Directoryでは、各APIに正しい文字エンコーディングが使用されることを保証しています。

グローバリゼーション・サポートとは、シングルバイト文字とマルチバイト文字の双方をサポートすることを意味します。シングルバイト文字は、1バイトのメモリーで表されます。たとえば、ASCIIテキストはシングルバイト文字を使用します。一方、マルチバイト文字は、複数バイトで表すことができます。たとえば、簡体字中国語はマルチバイト文字を使用します。簡体字中国語のディレクトリ・エントリ定義のASCII表現は次のとおりです。

dn: o=\274\327\271\307\316\304,c=\303\300\271\372
objectclass: top
objectclass: organization
o: \274\327\271\307\316\304

属性値は、簡体字中国語のディレクトリ・エントリ定義のASCII表現に対応します。

デフォルトでは、Oracle Internet Directoryの主なコンポーネントであるOIDモニター(OIDMON)、OID制御ユーティリティ(OIDCTL)、Oracleディレクトリ・サーバー(OIDLDAPD)およびOracleディレクトリ・レプリケーション・サーバー(OIDREPLD)は、UTF-8文字セットのみを使用します。Oracle文字セット名はAL32UTF8です。

Oracleディレクトリ・サーバーとデータベース・ツールの実行をUTF8データベース上に限定していた、従来の制限はなくなりました。ただし、Oracle Internet Directoryサーバーの基礎となるデータベースがAL32UTF8またはUTF8でない場合は、クライアント文字セットにあるすべての文字(文字コードが同じかどうかにかかわらず)がデータベース文字セットに含まれていることを確認する必要があります。そうでない場合は、クライアント・データをデータベース文字セットにマップできないと、LDAPの追加、削除、変更または識別名の変更の各操作でデータが消失する可能性があります。

Oracle Directory Services Managerは、Unicode(固定幅の16ビットUnicodeであるUTF-16)を使用します。国際化文字セットをサポートできます。

関連項目:

- 付録I「ディレクトリにおけるグローバリゼーション・サポート」

- グローバリゼーション・サポートの詳細は、Oracle Databaseドキュメント・ライブラリの『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください。

3.9 分散ディレクトリ

オンライン・ディレクトリは論理的に集中管理されていますが、物理的には複数のサーバーに分散できます。この分散によって、サーバーが1つのみの場合に実行する必要のある作業が削減され、ディレクトリにより多くのエントリを格納できるようになります。

分散ディレクトリは、レプリケートまたはパーティション化できます。情報がレプリケートされると、同じネーミング・コンテキストが複数のサーバーに格納されます。情報がパーティション化されると、他と重複しない1つ以上のネーミング・コンテキストが各ディレクトリ・サーバーに格納されます。分散ディレクトリでは、情報の一部がパーティション化されたりレプリケートされたりする場合があります。

この項の項目は次のとおりです。

- 第3.9.1項「ディレクトリ・レプリケーション」

- 第3.9.2項「ディレクトリ・パーティション化」

3.9.1 ディレクトリ・レプリケーション

レプリケーションは、複数のディレクトリ・サーバーに同じネーミング・コンテキストをコピーし、管理するプロセスです。レプリケーションの概念は、第6章「Oracle Internet Directoryレプリケーションの理解」を参照してください。

3.9.2 ディレクトリ・パーティション化

パーティション化は、ディレクトリ情報を分散するもう1つの方法です。パーティション化では、他と重複しないネーミング・コンテキストが1つ以上、各ディレクトリ・サーバーに格納されます。

図3-6に、異なるサーバーにいくつかのネーミング・コンテキストが存在している、パーティション化されたディレクトリを示します。

図3-6 パーティション化されたディレクトリ

図3-6では、サーバーAに次の4つのネーミング・コンテキストが存在しています。

- dc=acme,dc=com

- c=us,dc=acme,dc=com

- c=uk,dc=acme,dc=com

- c=au,dc=acme,dc=com

サーバーAにある次の2つのネーミング・コンテキストは、サーバーBにレプリケートされています。

- dc=acme,dc=com

- c=au,dc=acme,dc=com

ディレクトリは、サーバーBにリクエストした情報がサーバーAに常駐している場合に、1つ以上のナレッジ参照を使用して情報を検索します。この情報を参照形式でクライアントに渡します。

3.10 ナレッジ参照と参照

ナレッジ参照は、別のパーティションに保持されている様々なネーミング・コンテキストの名前とアドレスを提供します。たとえば、図3-6で、サーバーBは、ナレッジ参照を使用して、サーバーA上のネーミング・コンテキストc=usとc=ukを指し示します。サーバーBがサーバーAに常駐している情報の要求を受けると、サーバーBは1つ以上のサーバーAへの参照を返します。クライアントは、これらの参照を使用してサーバーAと通信できます。

一般的に、各ディレクトリ・サーバーには、上位ナレッジ参照と従属ナレッジ参照の両方があります。上位ナレッジ参照では、DIT内でルートに向かう上位方向が指し示されます。この参照は、パーティション化されたネーミング・コンテキストをその親に結び付けます。従属ナレッジ参照では、DIT内で他のパーティションへの下位方向が指し示されます。

たとえば、図3-7では、サーバーBに4つのネーミング・コンテキストがあり、そのうちの2つは他のネーミング・コンテキストの上位にあります。この2つの上位ネーミング・コンテキストは、従属ナレッジ参照を使用して、その従属ネーミング・コンテキストを指し示しています。逆に、サーバーA上のネーミング・コンテキストは、サーバーBに直属の上位ネーミング・コンテキストを持っています。したがって、サーバーAは、上位ナレッジ参照を使用してサーバーB上の親を指し示しています。

図3-7 ナレッジ参照を使用したネーミング・コンテキストの指示

当然のことですが、DITの最上位で始まるネーミング・コンテキストは、上位ネーミング・コンテキストへのナレッジ参照を持つことはできません。

注意:

- ナレッジ参照の有効性を実施するためのインターネット規格は現在存在せず、Oracle Internet Directoryでも同様です。管理者が、エンタープライズ・ネットワーク内の複数のナレッジ参照間の一貫性を確保する必要があります。

- ナレッジ参照エントリの管理権限は、スキーマやアクセス制御などの他の重要な権限管理機能と同様に制限することをお薦めします。

参照には次の2つの種類があります。

- スマート参照
これらは、ナレッジ参照エントリが検索の有効範囲内にあるときにクライアントに返されます。リクエストされた情報が格納されているサーバーをクライアントに示します。

たとえば、次のような場合があります。

- サーバーAには、ネーミング・コンテキストou=server development,c=us,o=acmeがあり、さらにサーバーBへのナレッジ参照があります。

- サーバーBには、ネーミング・コンテキストou=sales,c=us,o=acmeがあります。

ou=sales,c=us,o=acmeにある情報のリクエストを、クライアントがサーバーAに送信すると、サーバーAはサーバーBへの参照をユーザーに提供します。

- デフォルト参照
デフォルト参照は、ベース・オブジェクトがディレクトリになく、さらに操作が別のサーバー上のネーミング・コンテキストで実行されたときに返されます。デフォルト参照では、通常、ディレクトリ・パーティション化配置に関するより多くの情報を持つサーバーにクライアントを送信します。

たとえば、サーバーAが次のものを保持するとします。

- ネーミング・コンテキストc=us,o=acme

- ディレクトリ・パーティション化配置全般についてより多くのナレッジを持つサーバーPQRへのナレッジ参照

クライアントがc=uk,o=acmeにある情報をリクエストしたとします。サーバーAは、c=uk,o=acmeネーミング・コンテキストを持っていないことを認識すると、そのクライアントにサーバーPQRへの参照を提供します。クライアントは、リクエストしたネーミング・コンテキストを保持しているサーバーをそこから検索できます。

関連項目:
第20章「ナレッジ参照と参照の管理」

3.11 Oracle Delegated Administration ServicesとOracle Internet Directoryセルフサービス・コンソール

Oracle Delegated Administration Servicesは、ユーザーのかわりにディレクトリ操作を実行するために事前定義されたWebベースのユニットのセットです。このサービスのセットは、ディレクトリ管理者が他の管理者やエンド・ユーザーに対して特定の機能を委任できるようにすることによって、ディレクトリ管理の日常的な作業からディレクトリ管理者を解放します。これにより、ユーザー・エントリの作成、グループ・エントリの作成、エントリの検索、ユーザー・パスワードやその他の従業員固有のデータの変更など、ディレクトリ対応アプリケーションに必要な大部分の機能が提供されます。

注意:
この章で言及するOracle Delegated Administration Servicesはすべて、Oracle Delegated Administration Services 10g(10.1.4.3.0)以上のことです。

Oracle Delegated Administration Servicesを使用して、ディレクトリ内のアプリケーション・データを管理するための独自のツールを開発できます。また、Oracle Internet Directoryセルフサービス・コンソール(Oracle Internet Directoryに含まれる、Oracle Delegated Administration Servicesに基づいたすぐに使えるツール)を使用することもできます。このコンソールは、委任管理を提供するために複数のOracleコンポーネントで使用されます。

関連項目:
10g (10.1.4.0.1)ライブラリの『Oracle Identity Management委任管理ガイド』。

3.12 サービス・レジストリとサービス・ツー・サービス認証

サービス・レジストリおよびサービス・ツー・サービス認証フレームワークとはOracle Internet Directoryの機能であり、サービスを相互にリクエストするOracleテクノロジ・コンポーネント間の統合を促進します。サービス・レジストリは、コンポーネントが互いに検出できるように情報の格納場所を提供します。サービス・ツー・サービス認証フレームワークは、一方のコンポーネントから他方のコンポーネントを認証できるようにして、互いの信頼関係を確立します。

サービス・レジストリとはOracle Internet Directoryの(cn=Services, Cn=OracleContextの下にある)コンテナであり、コンポーネントがプロトコルやサービス・タイプなどの接続情報を格納する場所です。インストールの際、それぞれのOCSコンポーネントがこのレジストリに情報を登録します。実行時には、このコンポーネントが他のコンポーネントの登録情報を検出します。サービス・レジストリ・オブジェクトは、Oracle Internet DirectoryのDITで、rootOracleContextのコンポーネント固有のサービス・コンテナに格納されます。

サービス・ツー・サービス認証は、一方のサービスから他方のサービスを認証できるようにして、サービス間の信頼関係を確立するフレームワークです。インストールの際、各クライアント・サービスにはOracle Internet Directoryのユーザー名とパスワードがプロビジョニングされます。さらに、それぞれのターゲット・サービスがOracle Internet Directoryでの権限ロールを定義して、どのコンポーネントを信頼すべきかを制御します。一方のコンポーネントが他方のコンポーネントのサービスをリクエストする場合、リクエスト側は独自のアイデンティティと資格証明を使用して、他のクライアントと同様にターゲット・サービスに対して認証する必要があります。またリクエスト・サービスは、ターゲット・サービスのトラステッド・アプリケーション・グループにリスト表示される必要があります(デフォルト・グループは対比アプリケーション、カウンターポイズ、cn=OracleContextです)。さらにリクエスト・サービスは、ターゲット・サービスがユーザーも認証できるように、ユーザーのアイデンティティを送信する必要があります。このデータは、Digest認証もしくはターゲット・サービスに備わっているセキュア認証のいずれかにより、安全に送信されます。

3.13 Oracle Directory Integration Platform

Oracle Directory Integration Platformを使用して、企業はアプリケーションやその他のディレクトリをOracle Internet Directoryに統合できます。これは、Oracle Internet Directoryのデータとエンタープライズ・アプリケーションや接続ディレクトリのデータとの一貫性を維持するために必要なすべてのインタフェースとインフラストラクチャを提供します。また、サード・パーティ・ベンダーや開発者にとっては、独自の接続エージェントの開発とデプロイが容易になります。

たとえば、企業では人事管理データベースの従業員レコードとOracle Internet Directoryとの同期が必要な場合があります。また、変更がOracle Internet Directoryに適用されるたびに通知が必要なLDAP対応のアプリケーション(Oracle Portalなど)がデプロイされている可能性もあります。

統合の性質に基づいて、Oracle Directory Integration Platformは2つの異なるサービスを提供します。

- 同期化統合サービスは、接続ディレクトリと中央のOracle Internet Directoryとの一貫性を維持します。

- プロビジョニング統合サービスは、ユーザーやグループなど、重要なエントリに対する変更を反映するために、ターゲット・アプリケーションに通知を送信します。

関連項目:
Oracle Fusion Middleware Oracle Directory Integration Platform管理者ガイド

3.14 Oracle Internet Directoryとアイデンティティ管理

この項の項目は次のとおりです。

- 第3.14.1項「アイデンティティ管理について」

- 第3.14.2項「アイデンティティ管理レルム」

3.14.1 アイデンティティ管理について

アイデンティティ管理とは、通常は、組織のアプリケーション・ユーザーの管理です。セキュリティ・ライフサイクルの手順には、アカウント作成、一時停止、権限変更、アカウント削除があります。管理対象エンティティには、デバイス、プロセス、アプリケーション、ネットワーク環境で対話するために必要なその他のものも含まれます。組織外のユーザー、たとえば顧客、取引先、Webサービスなども含まれることがあります。

アイデンティティ管理は、管理コストを削減すると同時にセキュリティを向上できるため、ITデプロイメントにとって重要です。

Oracle Identity Management製品によって、企業内のすべてのエンタープライズ・アイデンティティと各種アプリケーションに対するそのアクセスを集中的かつ安全に管理するためのデプロイメントが可能になります。アイデンティティ管理は、次のタスクで構成されています。

- 企業規模の単一コンソールを使用したエンタープライズ・アイデンティティの作成およびアイデンティティの共有プロパティの管理

- エンタープライズ・アイデンティティのグループの作成

- 企業で利用できる各種サービスでのこれらのアイデンティティのプロビジョニング。次のサービスが含まれます。

- アカウント作成

- アカウント一時停止

- アカウント削除

- これらのアイデンティティに関連付けられたポリシーの管理。次のポリシーが含まれます。

- 認可ポリシー

- 認証ポリシー

- 既存アイデンティティに委任された権限

注意:
Oracle Identity Managementの詳細および追加リソースは、Oracle Technology Network (OTN) Webサイト(http://www.oracle.com/technetwork/index.html)を参照してください。

3.14.2 アイデンティティ管理レルム

アイデンティティ管理レルムは、あるアイデンティティ管理ポリシーがデプロイメントにより定義され、施行される企業内での有効範囲を定義します。次で構成されています。

- 有効範囲の定義されたエンタープライズ・アイデンティティの集合(USドメインのすべての従業員など)。

- これらのアイデンティティに関連付けられたアイデンティティ管理ポリシーの集合。アイデンティティ管理ポリシーの例としては、すべてのユーザー・パスワードに少なくとも1文字の英数字を含む必要があることなどがあります。

- グループの集合、すなわちアイデンティティの集約。アイデンティティ管理ポリシーの設定を簡素化します。

同じOracle Identity Managementインフラストラクチャ内で複数のアイデンティティ管理レルムを定義できます。複数のレルムによって、ユーザーの集団を区別し、各レルムで異なるアイデンティティ管理ポリシー(パスワード・ポリシー、ネーミング・ポリシー、自己変更ポリシーなど)を施行できます。

各アイデンティティ管理レルムには、他のレルムと区別するために固有の名前が付けられます。また、レルムに対して完全な管理制御を行うために、レルム固有の管理者も決められます。

3.14.2.1 デフォルトのアイデンティティ管理レルム

すべてのOracleコンポーネントが機能するには、アイデンティティ管理レルムが必要です。Oracle Internet Directoryのインストール中に作成される特別なレルムは、デフォルトのアイデンティティ管理レルムと呼ばれます。これは、レルムの名前が指定されていない場合に、Oracleコンポーネントが、ユーザー、グループおよび関連付けられたポリシーを検索する場所です。

デフォルトのアイデンティティ管理レルムは、ディレクトリに1つのみです。デプロイメントに、複数のアイデンティティ管理レルムが必要である場合、その1つをデフォルトとして選択する必要があります。

3.14.2.2 アイデンティティ管理ポリシー

Oracle Identity Managementインフラストラクチャは、一連の柔軟な管理ポリシーをサポートします。これは、次の要素で構成されます。

- ディレクトリ構造ポリシーとネーミング・ポリシー。これにより次のことが可能になります。

- デプロイメントに合せてOracle Internet Directoryのディレクトリ構造をカスタマイズ

- 各種アイデンティティが置かれる場所と、それを一意に識別する方法を指定

- Oracle Identity Managementインフラストラクチャによりサポートされる認証方式とプロトコルを指定できる認証ポリシー

- 権限のある特定のサービスへのアクセスを制御し、必要に応じて管理を委任できるアイデンティティ管理認可

注意:
Oracle Internet Directoryリリース9.0.2で使用した「サブスクライバ」は、「アイデンティティ管理レルム」と同じ用語です。

3.15 TCPキープ・アライブ

Oracle Internet Directoryでは、TCPキープ・アライブ・メカニズムがオペレーティング・システム・レベルで有効化されている場合、デフォルトでTCPキープ・アライブがサポートされます。特定のOracle Internet Directory構成は不要です。

ただし、Oracle Virtual DirectoryがOracle Internet Directoryサーバーとともに構成されている場合、TCPキープ・アライブは、リスナー(LDAPクライアントの接続先)とアダプタ(Oracle Internet Directoryまたは他のLDAPサーバー)間で分割されます。この使用例では、次の構成が必要です。

- オペレーティング・システム・レベルで、TCPキープ・アライブ・メカニズムを有効化します。

- Oracle Virtual Directoryで、vde.soTimeoutBackend JVMパラメータを設定し、接続をクローズする前にOracle Virtual DirectoryがOracle Internet Directoryからのレスポンスを待機する時間を指定します。つまり、このパラメータによって、パラメータで指定された時間の経過後に非アクティブなソケットをクローズするようにOracle Virtual Directoryに指示します。
vde.soTimeoutBackendパラメータを構成すると、リモート・クライアントまたはサーバー障害が原因で孤立してしまったサーバー接続をOracle Virtual Directoryが検出して安全にクローズするために役立ちます。これによって、サーバーのパフォーマンスが大幅に向上します。

vde.soTimeoutBackendパラメータの値は、次のようにJava APIを使用して作成されたソケットに渡されます。

public void setSoTimeout(int timeout)
throws SocketException

前述の方法では、timeout制限パラメータ(ミリ秒単位)を指定してSO_TIMEOUTを有効または無効にできます。このオプションを0以外のタイム・アウトに設定すると、このSocketに関連付けられたInputStreamのread()呼出しが、その時間の間だけブロックされます。タイム・アウトの期限が切れると、Socketがまだ有効であってもjava.net.SocketTimeoutExceptionが発行されます。このオプションは、ブロック処理に入る前に有効にしておく必要があります。タイムアウトは0より大きい値を指定する必要があります。タイム・アウト0は無限のタイム・アウトとして解釈されます。

3.16 リソース情報

Oracleコンポーネントの中には、ユーザーのリクエストを実行するために、様々なリポジトリおよびサービスからデータを収集するものがあります。データを収集するために、これらのコンポーネントでは次の情報が必要です。

- データの収集元となるリソースのタイプを指定する情報。たとえば、Oracle Databaseなどです。これは、リソース・タイプ情報と呼ばれます。

- リソースに対するユーザーの接続および認証のための情報。これは、リソース・アクセス情報と呼ばれます。

この項の項目は次のとおりです。

- 第3.16.1項「リソース・タイプ情報」

- 第3.16.2項「リソース・アクセス情報」

- 第3.16.3項「DIT内のリソース情報の位置」

3.16.1 リソース・タイプ情報

ユーザーのリクエストを処理するためにアプリケーションが使用するリソースの情報をリソース・タイプ情報と呼びます。リソース・タイプには、Oracle DatabaseやプラガブルなJava Database Connectivityデータ・ソースなどがあります。リソース・タイプ情報には、ユーザーの認証に使用するクラス、ユーザー識別子、パスワードなどの項目が含まれます。

Oracle Internet Directoryセルフサービス・コンソールを使用して、リソース・タイプ情報を指定します。

3.16.2 リソース・アクセス情報

データベースに対するユーザーの接続および認証に関する情報は、リソース・アクセス情報と呼ばれます。これは、様々なOracleコンポーネントで取得および共有できるリソース・アクセス記述子(RAD)と呼ばれるエントリに格納されます。

たとえば、販売レポートに関するユーザーのリクエストを処理するために、Oracle Reportsは複数のデータベースに問い合せます。データベースへの問合せでは、次の処理が実行されます。

1. RADからの必要な接続情報の取得

2. 取得した情報を使用した、データベースへの接続およびデータをリクエストしているユーザーの認証

この処理が終了すると、レポートがコンパイルされます。

Oracle Internet Directoryセルフサービス・コンソールを使用して、リソース・アクセス情報を指定します。リソース・アクセス情報をユーザーごとに指定することも、すべてのユーザーに共通に指定することもできます。後者の場合、指定されたアプリケーションに接続するすべてのユーザーは、デフォルトで同じ情報を使用して必要なデータベースに接続します。たとえば、各ユーザーが一意のシングル・サインオン・ユーザー名でアプリケーション内に定義されている場合など、アプリケーションに独自の統合アカウント管理がある場合は、デフォルトのリソース・アクセス情報を定義することをお薦めします。

3.16.3 DIT内のリソース情報の位置

図3-8に、DIT内のリソース情報の位置を示します。

図3-8 DIT内のリソース・アクセス情報およびリソース・タイプ情報の配置

図3-8に示すとおり、リソース・アクセス情報およびリソース・タイプ情報は、Oracleコンテキストに格納されます。

各ユーザーのリソース・アクセス情報は、Oracleコンテキスト内のcn=User Extensionsノードに格納されます。この例では、cn=User Extensionsノードには、デフォルトのユーザーおよび特定のユーザーの両方のリソース・アクセス情報が含まれています。後者の場合、リソース・アクセス情報には、SalesデータベースおよびBugデータベースの両方へのアクセスで必要な情報が含まれます。

各アプリケーションのリソース・アクセス情報は、アプリケーション名で識別されるオブジェクトに格納されます。この例では、cn=Oracle Reports Services, cn=Products,cn=Oracle Context,dc=us,dc=acme,dc=comです。これは、その製品に固有のユーザー情報です。

リソース・タイプ情報は、コンテナcn=resource types, cn=common,cn=products,cn=Oracle Contextに格納されます。

関連項目:

- エンド・ユーザーによるリソース・アクセス情報の指定手順は、10g (10.1.4.0.1)ライブラリの『Oracle Identity Management委任管理ガイド』にある、自身のリソース情報の管理、ユーザー・エントリの作成、デフォルト・リソースの構成および新規リソース・タイプの作成に関する説明の項を参照してください

- 『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のプラグイン・スキーマ要素に関する説明

- Oracle Fusion Middleware Publishing Reports to the Web with Oracle Reports Services

4 Oracle Internet Directoryコンポーネントのプロセス制御の理解

この章では、LDAPサーバーおよびレプリケーション・サーバー・プロセスに関するOracle Internet Directoryのプロセス制御アーキテクチャと関連概念について説明します。ここには、Oracle Internet Directoryプロセスの起動、停止およびモニタリングと、プロセス制御のいくつかのベスト・プラクティスが含まれます。

この章の内容は次のとおりです。

- 第4.1項「Oracle Internet Directoryのプロセス制御アーキテクチャ」

- 第4.2項「ODS_PROCESS_STATUS表」

- 第4.3項「Oracle Internet Directoryのプロセスの起動、停止およびモニタリング」

- 第4.4項「Oracle Internet Directoryレプリケーション・サーバーの制御およびフェイルオーバー」

- 第4.5項「Oracle Internet Directoryプロセス制御のベスト・プラクティス」

Oracle Internet Directoryサーバー・インスタンスの作成および破棄の詳細は、第8章「Oracle Internet Directoryインスタンスの管理」を参照してください。

Oracle Directory Integration and Provisioningサーバーの起動および停止の詳細は、『Oracle Fusion Middleware Oracle Directory Integration Platform管理者ガイド』の「Oracle Directory Integration and Provisioningサーバーの管理」の章を参照してください。

4.1 Oracle Internet Directoryのプロセス制御アーキテクチャ

Oracle Process Manager and Notification Server (OPMN)は、Oracle Internet Directoryを含むOracle Fusion Middlewareシステム・コンポーネントをモニターするデーモン・プロセスです。Oracle Enterprise Manager Fusion Middleware ControlではOPMNを使用して、Oracle Internet Directoryのインスタンスを起動または停止します。コマンド行からOracle Internet Directoryコンポーネントを起動または停止する場合、OPMNへのコマンド行インタフェースであるopmnctlを使用します

関連項目:

- 第8章「Oracle Internet Directoryインスタンスの管理」

- Oracle Process Manager and Notification Serverの詳細は、『Oracle Fusion Middleware Oracle Process Manager and Notification Server管理者ガイド』を参照してください。

OPMNは、デーモン・プロセスOIDMON(ORACLE_HOME/bin/oidmon)を直接、起動、停止、再起動、および監視します。OIDMONは、Oracle Internet Directoryインスタンスのプロセス制御を行います。11g リリース1では、同一ノードの同一Oracleインスタンスに複数のOracle Internet Directoryインスタンスを設定できます。Oracle Internet Directoryインスタンスを新規作成する方法としては、タイプOIDのOracle Fusion Middlewareコンポーネントを作成することをお薦めします。この方法で作成した各Oracle Internet Directoryインスタンスには、独自のOIDMONがあります。

図4-1に、Oracle Internet Directoryのプロセス制御の全体的なアーキテクチャを示します。タイプOIDのOracle Fusion Middlewareコンポーネントごとに、OPMNにより、OIDMONプロセスが生成されます。この図は、2つのコンポーネントとしてoid1とoid2を示しています。OIDMONはOIDLDAPDディスパッチャ・プロセスを生成し、OIDLDAPDディスパッチャ・プロセスは1つ以上のOIDLDAPDサーバー・プロセスを生成します。

Oracle Internet Directory 11g リリース1(11.1.1.7.0)以降、OIDLDAPDプロセスはOIDDISPD(ディスパッチャ)プロセスとOIDLDAPD(サーバー)プロセスに分割されます。ただしUNIXシステムおよびLinuxシステムでは、これらのプロセスはともに、実行時にps -efコマンドにより引き続きOIDLDAPDとして表示されます。

このインスタンスにレプリケーションが構成されている場合、OIDMONはレプリケーション・サーバー・プロセスを生成します。各ディスパッチャ・プロセスには、リクエストを受信するための独自の非SSLおよびSSLポートがあります。コンポーネントごとにディスパッチャが生成するOIDLDAPDサーバー・プロセスの数は、コンポーネントのインスタンス固有の構成エントリ内のorclserverprocs属性によって制御されます。

注意:
orclmaxlogfilesizeで指定された設定に関係なくログ・ファイルのサイズが1MBを超えて増加した場合、Oracle Internet Directoryインスタンスの再起動後に、OIDモニター(OIDMON)およびOIDDISPD (ディスパッチャ)ログ・ファイルがローテーションされます。

図4-1 Oracle Internet Directoryのプロセス制御

関連項目:
Oracle Internet Directoryインスタンスの新規作成の詳細は、第8章「Oracle Internet Directoryインスタンスの管理」を参照してください。

4.2 ODS_PROCESS_STATUS表

Oracle Internet Directoryのプロセス情報は、ODSデータベース・ユーザー・スキーマのODS_PROCESS_STATUS表で管理されます。OIDMONは、指定された間隔で表の内容を読み取り、その表の内容が伝える目的に従って動作します。この間隔は、OIDMON起動時に使用されたsleepコマンド行の引数の値によって制御され、デフォルト値は10秒です。

表4-1に、ODS_PROCESS_STATUS表内のプロセス制御に関する情報を示します。

表4-1 ODS_PROCESS_STATUS表のプロセス制御項目

項目

意味

Instance

指定されたホスト上の指定されたサーバーIDに対する一意のインスタンス番号

PID

稼働中のサーバーのプロセスID

ServerID

サーバーID(2=OIDLDAPD、3=OIDREPLD)

Flags

サーバー・インスタンスに渡す必要のあるコマンド行引数

Hostname

このサーバーが存在している必要のあるホスト名

状態

サーバー・インスタンスの状態(0=停止、1=起動、2=実行中、3=再起動、4=シャットダウン、5=フェイルオーバー済、7=削除、8=追加)。OIDMONが状態を更新します。

RetryCount

サーバー・インスタンスが正常に起動するまでの起動試行回数

Instancename

サーバー・インスタンスの名前(server1など)

Compname

サーバー・コンポーネントの名前(OID1など)

注意:

- Instance、Instancename、Compname、ServerIDおよびHostnameには一意性制約があります。

- ここでは、情報を示す目的のみでODS_PROCESS_STATUSの詳細を説明しています。この表を直接変更しないようにしてください。

4.3 Oracle Internet Directoryのプロセスの起動、停止およびモニタリング

この項では、OPMNによるOracle Internet Directoryの起動時および停止時に発生するイベントについて説明します。また、プロセスのモニタリングについても説明します。この項では、次の項目について説明します。

- 第4.3.1項「opmn.xmlのOracle Internet Directoryスニペット」

- 第4.3.2項「Oracle Internet Directoryを起動するOPMN」

- 第4.3.3項「Oracle Internet Directoryを停止するOPMN」

- 4.3.4「プロセスのモニタリング」

4.3.1 opmn.xmlのOracle Internet Directoryスニペット

OPMNはOIDMONを起動するときに、OPMN構成ファイルORACLE_INSTANCE/config/OPMN/opmn/opmn.xmlのOracle Internet Directoryスニペットに基づいて、使用する引数を決定します。次に、Oracle Internet Directoryスニペットの例を示します。

<ias-component id="<componentName>">
<process-type id="OID" module-id="OID">
<process-set id="OID" numprocs="1">
<environment>
<variable id="TNS_ADMIN" value="ORACLE_INSTANCE/config" />
<variable id="DB_CONNECT_STR" value="db_alias" />
</environment>
<module-data>
<category id="oidmon-parameters">
<data id="start-cmdline-opts" value="connect=$DB_CONNECT_STR start"/>
<data id="stop-cmdline-opts" value="connect=$DB_CONNECT_STR stop"/>
</category>
</module-data>
</process-set>
</process-type>
</ias-component>

次の2つのタグはOracle Internet Directoryに固有のものです。

- OPMN用のOracle Internet Directoryコンポーネント固有のディレクティブは、タグ<ias-component id="OID" status="enabled>の下にあります。

- OIDMON関連の要件は、タグ<category id="oidmon parameters">の下にあります。このようなディレクティブは1つのみである必要があります。

4.3.2 Oracle Internet Directoryを起動するOPMN

Oracle Internet Directoryは、次のように起動されます。

- Oracle Enterprise Manager Fusion Middleware Controlまたはコマンドopmnctlを使用してOracle Internet Directoryインスタンスを起動します。

関連項目:

- 第8.2.2項「Fusion Middleware Controlを使用したOracle Internet Directoryサーバーの起動」

- 第8.3.7項「opmnctlを使用したOracle Internet Directoryサーバーの起動」

- OPMNは、opmn.xml内のOIDスニペットのoidmon parametersで指定されている適切な引数を付けたoidmon startコマンドを発行します。

- 次に、OIDMONは、ODS_PROCESS_STATUS表のstate値が1または4であり、OPMNによって設定されている環境パラメータとORACLE_INSTANCE、COMPONENT_NAME、INSTANCE_NAME値が合致するすべてのOracle Internet Directoryサーバー・インスタンスを起動します。

注意:
opmnctlを使用してOracle Internet Directoryインスタンスのみを起動する場合、opmn.xmlパラメータは、opmnctl startallを使用するときと同じ状態ではリロードされません。ファイルORACLE_INSTANCE/config/OPMN/opmn/opmn.xmlの変更をリロードするには、opmnctl reloadを実行します。

4.3.3 Oracle Internet Directoryを停止するOPMN

Oracle Internet Directoryは、次のように停止されます。

- Oracle Enterprise Manager Fusion Middleware Controlまたはopmnctlを使用してOracle Internet Directoryインスタンスを停止します。

関連項目:

- 第8.2.3項「Fusion Middleware Controlを使用したOracle Internet Directoryサーバーの停止」

- 第8.3.8項「opmnctlを使用したOracle Internet Directoryサーバーの停止」

- OPMNはoidmon stopコマンドを発行します。

- 環境パラメータORACLE_INSTANCE、COMPONENT_NAMEおよびINSTANCE_NAMEと合致するODS_PROCESS_STATUS表の行ごとに、oidmon stopコマンドは、OIDMON、OIDLDAPDおよびOIDREPLDプロセスを中断し、状態を4に更新します。

注意:
opmnctlを使用してOracle Internet Directoryインスタンスのみを起動する場合、opmn.xmlパラメータは、opmnctl startallを使用するときと同じ状態ではリロードされません。ファイルORACLE_INSTANCE/config/OPMN/opmn/opmn.xmlの変更をリロードするには、opmnctl reloadを実行します。

4.3.4 プロセスのモニタリング

OPMNは、サーバー・プロセスを直接モニターしません。OPMNはOIDMONをモニターし、OIDMONはサーバー・プロセスをモニターします。プロセスは次のとおりです。

- OPMNを介してOIDMONを起動すると、OPMNはOIDMONを起動し、OIDMONが稼働中であることを確認します。

- なんらかの理由でOIDMONが停止した場合、OPMNはOIDMONを稼働状態に戻します。

- OIDMONは、Oracle Internet Directoryディスパッチャ・プロセス、LDAPサーバー・プロセス、およびレプリケーション・サーバー・プロセスのステータスをモニターし、このステータスをOPMNとFusion Middleware Controlで使用できるようにします。OIDMONがOPMNに情報を送信するため、opmnctl statusコマンドはOIDLDAPDプロセスPIDを示すことができます。

4.4 Oracle Internet Directoryレプリケーション・サーバーの制御およびフェイルオーバー

この項では、最大可用性アーキテクチャ(MAA)でのOracle Internet Directoryレプリケーション・サーバー(oidrepld)の次のようなプロセス制御およびフェイルオーバーについて説明します。

- 第4.4.1項「OIDモニターおよびレプリケーション・サーバー・フェイルオーバーの理解」

- 第4.4.2項「Oracle Internet Directoryプロセスのフェイルオーバーの有効化」

4.4.1 OIDモニターおよびレプリケーション・サーバー・フェイルオーバーの理解

各ノードで、OIDモニター・プロセス(oidmon)の直接的な起動、停止、再起動およびモニタリングを担当するのは、Oracle Process Manager and Notification Server (OPMN)です。その後は、OIDモニターが、LDAPサーバー・プロセスやレプリケーション・サーバー(oidrepld)・プロセス(レプリケーションがインスタンス用に構成されている場合)などのOracle Internet Directoryコンポーネントのプロセス制御を担当します。

最大可用性アーキテクチャ(MAA)では、これらのプロセスが次のように実行されます。

- 複数のOIDモニター・プロセスを1つのノードで実行可能で、同じOracle Databaseに接続できます。各OIDモニターは、oid1やoid2などのOracle Internet Directoryコンポーネントを担当します。ただし、高可用性操作を実行するOIDモニターは、1つのみです。

- レプリケーションが構成されている場合、レプリケーション・サーバー・プロセスは、常に1つのノードでのみ実行される必要があります。

60秒ごとに、OIDモニターは、Oracle Databaseにメッセージを送信して稼働中であることをレポートします。また、OIDモニターは、他のいずれかのノードが停止していないかどうかを判断するため、データベースをポーリングします。OIDモニターは、ODS_PROCESS_STATUS表とODS_SHM表を使用して、ノード全体でプロセスの起動と停止およびメタデータの変更を伝達します。

レプリケーション・サーバーが実行されているノードで、OIDモニターは、応答のないレプリケーション・サーバーを検出し、その再起動を試みます。再起動に失敗すると、レプリケーション・サーバーは、次のロジックを使用して存続ノードの1つで起動されます。

- プル・ロジック: OIDモニターは、別のノードで別のOIDモニターが構成済の時間(orclfailoverenabled属性で指定)を超えて停止していることを検出すると、そのノードに障害が発生したものとして扱い、そのノードでレプリケーション・サーバーを起動します。

- プッシュ・ロジック: ノード上のローカルOIDモニターは、他のノード上のOIDモニターにプロセスを起動するようにリクエストして、障害レプリケーション・サーバーを別のノードにプッシュできます。OIDモニターは、別のノード上のレプリケーション・サーバー・プロセスを起動することはできません。

その後、障害ノードが元に戻り、OIDモニターがそのノードで再起動されると、OIDモニターは、別のノードがレプリケーション・サーバーを実行していることを検出します。次に、OIDモニターは、他のノード上のOIDモニターにレプリケーション・サーバーを停止するようにリクエストして、元のノードでレプリケーション・サーバーを起動します。

4.4.2 Oracle Internet Directoryプロセスのフェイルオーバーの有効化

orclfailoverenabled属性は、Oracle Internet Directoryプロセスのフェイルオーバーを構成する構成エントリ("cn=configset,cn=oidmon,cn=subconfigsubentry")です。

この属性は、OIDモニターが存続ノードで失敗したプロセスを開始するまでのフェイルオーバー時間を分数で指定します。デフォルトのフェイルオーバー時間は5分です。ゼロ(0)の値は、Oracle Internet Directoryプロセスを別のノードにフェイルオーバーしないことを指定します。

たとえば、ノードBのOIDモニターが、orclfailoverenabledによって指定された時間を経過してもノードAが応答しないことを検出すると、ノードBはノードAに障害が発生したとみなします。次に、ノードBは、ノードAで実行されていたOracle Internet Directoryプロセスに関する必要な情報をOracle Databaseから取得し、ノードBでそれらを起動しようと試みます。

現在のフェイルオーバー時間をorclfailoverenabled属性で確認するには、次のようにします。

ldapsearch -h oid_host  p oid_port -D "cn=orcladmin" -q -s base \
-b "cn=configset,cn=oidmon,cn=subconfigsubentry" objectclass=* orclfailoverenabled

別のフェイルオーバー時間を指定するには、orclfailoverenabled属性の値を設定します。たとえば、フェイルオーバー時間を10分に設定するには、次のようにします。

ldapmodify -h oid_host  p oid_port -D "cn=orcladmin" -q -f enablerepl.ldif

enablerepl.ldifには、次の内容が含まれています。

dn: cn=configset,cn=oidmon,cn=subconfigsubentry
changetype: modify
replace: orclfailoverenabled
orclfailoverenabled: 10

4.5 Oracle Internet Directoryプロセス制御のベスト・プラクティス

opmnctlおよびoidctlの使用に関してお薦めする方法は、次のとおりです。

- opmnctlを使用して、Oracle Internet Directoryをコンポーネントとして停止または起動します。つまり、このコマンドを使用して、すべてのOracle Internet Directory LDAPおよびレプリケーション・サーバー・インスタンスを停止または起動します。

- opmnctlを使用してOracle Internet Directoryを停止すると、OPMNによってoidmon stopが発行されます。この結果、OIDMONにより、構成されているすべてのLDAPおよびレプリケーション・サーバー・インスタンスが停止されます。

- opmnctlを使用してOracle Internet Directoryを起動すると、OPMNによってoidmon startが発行されます。この結果、OIDMONにより、構成されているすべてのLDAPおよびレプリケーション・サーバー・インスタンスが起動されます。

関連項目:

- 第8章「Oracle Internet Directoryインスタンスの管理」

- Oracle Internet Directoryの起動と停止の詳細は、第40章「レプリケーションの設定」を参照してください。

- 関連付けられているOIDMONとOIDMONによって管理されているLDAPサーバー・インスタンスに影響を与えずにOracle Internet Directoryレプリケーション・サーバー・インスタンスを停止および起動するには、oidctlを使用します。

関連項目:

- レプリケーション・サーバーの起動と停止の詳細は、第40章「レプリケーションの設定」を参照してください。

- 付録B「OIDCTLを使用したOracle Internet Directoryインスタンスの管理」。

5 Oracle Internet Directory編成の理解

この章では、Oracle Internet Directoryのディレクトリ情報の論理編成を設計する際の考慮事項(ディレクトリ情報ツリー(DIT)、ディレクトリ構造全体、およびユーザーとグループの名前と編成の計画を含む)について説明します。また、サード・パーティ・ディレクトリからのDITの移行についても説明します。

この章の内容は次のとおりです。

- 第5.1項「ディレクトリ情報ツリーの計画」

- 第5.2項「ディレクトリ構造全体の計画」

- 第5.3項「ユーザーおよびグループのネーミングおよび編成の計画」

- 第5.4項「DITビューの指定」

- 第5.5項「サード・パーティ・ディレクトリからのDITの移行」

5.1 ディレクトリ情報ツリーの計画

Oracle Internet Directoryは、Oracle Identity Managementインフラストラクチャ全体の共有リポジトリとして機能します。ディレクトリの論理構造を慎重に計画することによって、次のことが可能になります。

- デプロイメントの要件を満たすセキュリティ・ポリシーの適用

- ディレクトリ・サービスの効率的な物理的デプロイメント

- サード・パーティのディレクトリをOracle Internet Directoryと同期化させる場合の簡単な構成

図5-1に、アイデンティティ管理をデプロイしているMyCompanyという架空の会社のディレクトリ情報ツリーを示します。

図5-1 ディレクトリ情報ツリーの計画

MyCompanyは、米国内でのデプロイメントにおけるディレクトリの論理編成に関して次の事項を決定しています。

- ドメイン名ベースのスキームは、DIT階層全体を表す。アイデンティティ管理インフラストラクチャがusドメイン内で展開されるため、dc=us,dc=mycompany,dc=comがDITのルートとなる。

- 選択したネーミング・コンテキスト内部では、すべてのユーザーがcn=usersというコンテナの下に表示される。このコンテナ内部では、すべてのユーザーが同一レベルで表示され、組織ベースの階層は存在しない。また、すべてのユーザーの一意の識別子としてuid属性を選択する。

- 選択したネーミング・コンテキスト内部では、すべての企業グループがcn=groupsというコンテナの下に表示される。このコンテナ内部では、すべての企業グループが同一レベルで表示される。すべてのグループ・エントリのネーミング属性をcnとする。

- コンテナdc=usを、アイデンティティ管理レルムのルートとして選択する。この場合、レルムの名前はusとする。デプロイメントでは、usレルムの範囲に該当するすべてのユーザーに対して、同様のセキュリティ・ポリシーを施行することを想定する。

Oracle Identity Managementのディレクトリの論理編成の計画には、次のものが含まれます。

- ディレクトリ情報ツリー構造全体の計画

- ユーザーおよびグループのディレクトリ格納とネーミングの計画

- アイデンティティ管理レルムの計画

5.2 ディレクトリ構造全体の計画

このタスクでは、企業内のすべてのアイデンティティ管理統合アプリケーションで使用される基本的なディレクトリ情報ツリーを設計します。この設計を行う場合は、次の考慮事項に注意してください。

- ディレクトリ編成によって、明確で効果的なアクセス制御が簡単に実行できるようになる必要があります。完全レプリケーションまたは部分レプリケーションのいずれかのレプリケーションを計画した場合、レプリケーションに対して適切な境界およびポリシーを施行できるのは、DITが分離するように設計された場合のみです。

- 別のディレクトリ・サーバーとの統合を行う企業では、Oracle Internet DirectoryのDITの設計と既存のDITを一致させることをお薦めします。
他のディレクトリ・サーバーには、Oracle Unified Directory、Oracle Directory Server Enterprise EditionなどのOracle製品、Microsoft Active Directoryなどのサード・パーティ製ディレクトリ・サーバーが含まれます。

この考慮事項は、現在Oracle Internet Directoryを展開し、後で別のディレクトリ・サーバー(Microsoft社のソフトウェアの操作に必要なActive Directoryなど)を展開するデプロイメントにも該当します。

いずれの場合でも、統合ディレクトリ・サーバーに対して一貫性のあるOracle Internet Directoryのディレクトリ情報ツリーの設計を採用すると、Oracle Delegated Administration Servicesおよび他の中間層アプリケーションを使用した、ユーザー・オブジェクトおよびグループ・オブジェクトの管理をより簡単にできます。

- 単一企業の使用例では、企業のDNSドメイン名と一致するDIT設計を選択すると、十分な結果が得られます。たとえば、mycompany.comというドメイン名を持つ企業でOracle Internet Directoryを設定する場合は、dc=mycompany,dc=comというルートを持つディレクトリ構造を使用することをお薦めします。部門または組織レベルのドメイン・コンポーネント(engineering.mycompany.comのengineeringなど)は使用しないことをお薦めします。

- X500ディレクトリ・サービスを使用し、他のサード・パーティのLDAPディレクトリが本番環境に存在しない企業では、国ベースのDIT設計を選択することをお薦めします。たとえば、o=mycompany, c=USというルートを持つDIT設計は、すでにX.500ディレクトリ・サービスを使用している企業に適しています。

- ディレクトリは、Oracleおよびサード・パーティの複数のアプリケーションで使用できるため、DIT構造全体を構成する相対識別名(RDN)で使用されるネーミング属性を、予約済属性に制限する必要があります。通常、次の属性は、ほとんどのディレクトリ対応アプリケーションで予約済です。

- c: 国の名前

- dc: DNSドメイン名のコンポーネント

- l: 地域(都市、郡、その他の地域など)の名前

- o: 組織の名前

- ou: 組織単位の名前

- st: 州またはその他の地方行政区画の名前

- 企業の部門構造または組織構造のいずれかを反映するようDITを設計するのは、よくある間違いです。ほとんどの企業が再編成や部門の再構築を頻繁に行うため、これはお薦めしません。企業のディレクトリは、できるかぎり組織変更と分離しておくことが重要です。

5.3 ユーザーおよびグループのネーミングおよび編成の計画

この項では、Oracle Internet Directoryでユーザーおよびグループのモデリングを行う場合の考慮事項について説明します。DIT設計全体に関係する設計時の考慮事項のほとんどは、ユーザーおよびグループのネーミングと格納にも当てはまります。

5.3.1 ユーザーの編成

Oracle Identity Managementインフラストラクチャでは、すべてのユーザーのアイデンティティのリポジトリとしてOracle Internet Directoryを使用します。企業内の複数のアプリケーションにアクセスするアカウントを持つユーザーの場合も、そのユーザーのアイデンティティを示すエントリはOracle Internet Directory内に1つのみです。DIT全体でのこれらのエントリの位置と内容は、Oracle Internet DirectoryおよびOracle Identity Managementインフラストラクチャの他のコンポーネントをデプロイする前に計画する必要があります。

- 前の項で説明したように、現在の部門関係や階層に基づいてユーザーを編成する傾向があります。ただし、ほとんどの企業は再編成や部門の再構築を頻繁に行うため、これはお薦めしません。個人のディレクトリ・エントリの属性として個人の組織情報を捉えると、管理しやすくなります。

- 部門関係や管理系統に基づいた階層でユーザー編成を行った場合、パフォーマンスは向上しません。ユーザーを格納するDITは、できるかぎり浅い階層にしておくことをお薦めします。

- デプロイメントに様々なユーザーの集団が含まれ、それぞれの集団が異なる組織によってメンテナンスおよび管理される場合は、それらの管理境界に基づいてユーザーをいくつかのコンテナに分けることをお薦めします。これによって、アクセス制御の設定が簡単になり、レプリケーションが必要になった場合に役立ちます。

- 検索操作でユーザーを一意に識別するためのデフォルトのニックネーム属性は、uidです。これはログインで使用するデフォルトの属性です。識別名を構成するためのデフォルトのネーミング属性は、cnです。

- ユーザーを一意に識別するためのデフォルトの属性は、cnまたはCommonNameです。CommonNameの一般的な値は、そのユーザーのフルネームです。ただし、名前や電子メール・アドレスは変わることがあるため、この属性の値には適さない場合があります。可能であれば、従業員IDなど、ユーザーを一意に識別できる変更のない値を選択してください。

- 通常、ほとんどの企業には、従業員に一意の名前と番号を割り当てる規則を定める人事部門があります。ディレクトリ・エントリに対して一意のネーミング・コンポーネントを選択する場合、この管理インフラストラクチャを活用し、そのポリシーを使用するのが有効です。

- ディレクトリ内に作成するすべてのユーザー・エントリは、inetOrgPersonおよびorclUserV2というオブジェクト・クラスのメンバーである必要があります。

- サード・パーティのディレクトリがすでに存在する場合、または将来それを統合する場合は、Oracle Internet Directoryでのユーザーのネーミングとディレクトリの格納を、サード・パーティのディレクトリ内で使用されるものと一致させるのが効果的です。これによって、分散ディレクトリの同期化およびそれ以降の管理が簡単になります。

注意:
Oracle Internet Directoryリリース9.0.2では、nickname属性のデフォルト値はcnでした。リリース9.0.4以上では、この属性のデフォルト値はuidです。

5.3.2 グループの編成

Oracle Identity Managementインフラストラクチャと統合されたアプリケーションの一部では、Oracle Internet Directoryでのデプロイメントによって作成された企業全体にわたるグループに基づいて認可を行うこともできます。ユーザー・エントリ同様、これらのグループ・エントリの位置と内容も慎重に計画する必要があります。グループ設計時の考慮事項は、次のとおりです。

- 部門関係や所有権に基づいた階層で企業グループ編成を行った場合、パフォーマンスは向上しません。グループを格納するDITは、できるかぎり浅い階層にしておくことをお薦めします。これによって、すべてのアプリケーションによるグループの検出が簡単になり、アプリケーション間でのこれらのグループの共有が促進されます。

- エントリの各セットに個別の管理ポリシーを適用できるように、DIT内のユーザーおよびグループを分けることをお薦めします。

- グループを一意に識別するには、cnまたはCommonName属性を使用する必要があります。

- 企業がディレクトリ内に作成するすべてのグループ・エントリは、groupOfUniqueNamesおよびorclGroupというオブジェクト・クラスに属している必要があります。前者のオブジェクト・クラスは、グループを表すインターネット標準です。後者のオブジェクト・クラスは、Oracle Internet Directoryセルフサービス・コンソールを使用してグループを管理する場合に有効です。

- 企業全体にわたるグループごとに新しいディレクトリ・アクセス制御を作成するのではなく、次のように対応することを検討してください。

1. グループのowner属性を使用して、グループの所有者であるユーザーを示します。

2. owner属性で示されたすべてのユーザーに、様々な操作を実行する特別な権限を付与する上位レベルのアクセス制御ポリシーを作成します。

- description属性には、グループの目的をユーザーが理解できるように情報を書き込みます。

- オブジェクト・クラスorclGroupでのdisplayName属性の使用を検討します。この属性によって、Oracle Delegated Administration ServicesおよびOracle Internet Directoryセルフサービス・コンソールで読みやすいグループ名を表示できます。

- 様々なグループのセットがあり、それぞれのセットが独自の管理ポリシーを持つ異なる組織によってメンテナンスおよび管理される場合は、それらの管理境界に基づいてグループをいくつかのコンテナに分けます。これにより、アクセス制御の設定が簡単になります。また、レプリケーションが必要な場合にも役立ちます。

- サード・パーティのディレクトリがすでに存在する場合、または将来それを統合する場合は、Oracle Internet Directoryでのグループのネーミングとディレクトリの格納を、サード・パーティのディレクトリ内で使用されるものと一致させます。これによって、分散ディレクトリの同期化およびそれ以降の管理が簡単になります。

5.4 DITビューの指定

11gリリース1 (11.1.1.9.0)以降では、異なるDITまたはソースDITのエントリを表示した仮想ビューまたはネームスペースであるDITビューを指定できます。DITビューによって、テナント全体の共通エントリに対するクラウド環境の記憶域フットプリント全体が削減されます。DITビューでは、次の項目がソースDITからターゲットDITビューのネームスペースに変換されます。

- エントリ内の識別名とすべての識別名属性

- DITビューで指定されている相対識別名マッピング

詳細は、第34.4項「DITビューの作成」を参照してください。

5.5 サード・パーティ・ディレクトリからのDITの移行

サード・パーティ・ディレクトリからDITを移行するには、第37章「他のデータ・リポジトリからのデータの移行」および『Oracle Fusion Middleware Oracle Directory Integration Platform管理者ガイド』に記載した方法で、サード・パーティのメタディレクトリ・ソリューションとの同期化およびサード・パーティ・ディレクトリとの統合を行います。

Microsoft Active Directory環境からDITを移行する場合は、Microsoft Active Directory環境との統合の章も参照してください。Oracle Internet DirectoryのDITがサード・パーティのDITと同一になるように構成することをお薦めします。

6 Oracle Internet Directoryレプリケーションの理解

この章では、複数のディレクトリ・サーバーに同じネーミング・コンテキストをコピーして管理するプロセスであるOracle Internet Directoryレプリケーションの概要について説明します。レプリケーションでは、問合せを処理するサーバーの数が増え、クライアントの近くにデータを持ってくるため、パフォーマンスが向上します。また、レプリケーションでは、シングル・ポイント障害に関連するリスクを排除することで信頼性も向上します。

この章では、次の項目について説明します。

- 第6.1項「レプリケーションを使用する理由」

- 第6.2項「レプリケーションの概念」

- 第6.3項「必要なレプリケーションの種類」

図6-1に、レプリケート・ディレクトリを示します。

図6-1 レプリケート・ディレクトリ

関連項目:

- 第V部「拡張管理: ディレクトリ・レプリケーション」

- 付録C「Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーションの設定」

- 付録D「レプリケーションの動作」

6.1 レプリケーションを使用する理由

レプリケーションを実装する理由の多くは、次のようなものです。

- ローカルなアクセス可能性とパフォーマンス要件
多くの企業は世界中の様々な地域で活動しており、それらの活動には共通ディレクトリが必要です。複数の中継ルーターを含む、低帯域幅のリンクで各地域が相互接続されているとします。地域の外部からディレクトリ・サーバーにアクセスしているクライアントは、長い待機時間や不十分なスループットを体験する場合があります。このような場合には、地域レプリカが必要です。

- ロード・バランシング
ディレクトリ・アクセスが既存のサーバーの容量を超えると、追加のサーバーが負荷を共有できます。デプロイメントが負荷を満たしている場合でも、1つのハイエンド・システムよりも2つの比較的安価なシステムをメンテナンスする方が、費用がかからない場合があります。

- 障害許容度とシステム全体の高可用性
ディレクトリ・レプリケーションを実装する最も重要な理由の1つは、システム全体の可用性を増すことです。1つのサーバーが使用できない場合、通信量は他の使用可能なサーバーに送られます。これはクライアントには透過的です。

6.2 レプリケーションの概念

この項では、レプリケーションの基本的な概念を簡単に紹介します。

この項の内容は次のとおりです。

- 第6.2.1項「レプリケートされるコンテンツ: 完全または部分」

- 第6.2.2項「方向: 一方向、双方向またはpeer-to-peer」

- 第6.2.3項「転送メカニズム: LDAPまたはOracle Databaseアドバンスト・レプリケーション」

- 第6.2.4項「ディレクトリ・レプリケーション・グループ(DRG)タイプ: 単一マスター、マルチマスターまたはファンアウト」

- 第6.2.5項「ゆるやかな一貫性モデル」

- 第6.2.6項「レプリケーションの概念の組合せ方法」

- 第6.2.7項「ファンアウトを使用したマルチマスター・レプリケーション」

6.2.1 レプリケートされるコンテンツ: 完全または部分

レプリケーションの設定時には、DITを1つのノードから別のノードにどの程度レプリケートするかを決定する必要があります。選択肢は次の2つです。

表6-1 完全または部分レプリケーション

レプリケートするコンテンツ

説明

完全

DIT全体を別のノードに伝播します。

部分

DIT全体ではなく、1つ以上のサブツリーを別のノードに伝播します。

完全レプリケーションでは、DIT全体を別のノードに伝播します。このタイプのレプリケーションでは、ディレクトリ全体の高可用性が保証されます。このレプリケーションを使用して、ディレクトリ全体の操作を様々なノードに分散することもできます。完全レプリケーションは、LDAPまたはOracle Databaseアドバンスト・レプリケーションのどちらかに基づきます。

部分レプリケーションでは、DIT全体ではなく、1つ以上のサブツリーを別のノードに伝播できます。この方法でディレクトリを分散することによって、サーバー間の作業負荷を均衡化し、フォルト・トレランスおよびフェイルオーバー機能を備え、可用性に優れた分散ディレクトリを構築することができます。コマンド行ツールまたはOracle Enterprise Managerのレプリケーション・ウィザードを使用して、部分レプリケーションを設定できます。部分レプリケーションは、ほとんどの場合LDAPベースです。

図6-2に、部分レプリケーションの例を示します。

図6-2 部分レプリケーションの例

6.2.2 方向: 一方向、双方向またはpeer-to-peer

レプリケーションの方向には、一方向、双方向またはpeer-to-peerがあります。

表6-2 レプリケーションの方向

方向

説明

一方向

一方のノードがサプライヤとして、もう一方がコンシューマとして構成されます。コンシューマは読取り専用です。

双方向

どちらのノードも、サプライヤとコンシューマの両方の役割を果します。読取りと書込みの両方が可能、つまり更新可能です。

peer-to-peer

レプリケーション・グループ内のすべてのノードが、他のノードすべてに対してサプライヤでありコンシューマでもあります。

読取り専用や読取り/書込みという用語は、レプリケーションの方向を説明するために使用されることがあります。一方向レプリケーション承諾では、コンシューマ・ノードは読取り専用と言われます。つまり、他のノードに対する変更をそのノードに書き込むことで伝播できません。双方向レプリケーション承諾では、両方のノードが読取り/書込み兼用と考えられます。読取り/書込みは、更新可能とも呼ばれます。

場合によっては、peer-to-peerにかわりにマルチマスターという用語が使用されます。マルチマスターは、第6.2.4項「ディレクトリ・レプリケーション・グループ(DRG)タイプ: 単一マスター、マルチマスターまたはファンアウト」に示すように、実際にはレプリケーション・グループのタイプを示します。

6.2.3 転送メカニズム: LDAPまたはOracle Databaseアドバンスト・レプリケーション

Oracle Internet Directoryでは、1つのノードから別のノードへのデータのレプリケーションに使用できる2つのプロトコルをサポートしています。プロトコルは次のとおりです。

表6-3 転送プロトコル

転送メカニズム

説明

LDAP

業界標準のLightweight Directory Access Protocolバージョン3を使用します。これは、Oracle Single Sign-Onレプリケーションも実行する場合を除き、レプリケーションに使用する推奨プロトコルです。

Oracle Databaseアドバンスト・レプリケーション

Oracle Databaseのレプリケーション機能を使用します。アドバンスト・レプリケーションとも呼ばれます。現在、Oracle Single Sign-Onレプリケーションではこのレプリケーション・プロトコルが必要です。

LDAPレプリケーションは、peer-to-peer、一方向または双方向のいずれかに構成できます。アドバンスト・レプリケーションは、通常peer-to-peerです。

6.2.4 ディレクトリ・レプリケーション・グループ(DRG)タイプ: 単一マスター、マルチマスターまたはファンアウト

指定したネーミング・コンテキストのレプリケーションの対象となるディレクトリ・サーバーは、ディレクトリ・レプリケーション・グループ(DRG)を形成します。DRGを構成するディレクトリ・サーバー間の関係は、各ノード上でレプリケーション承諾と呼ばれる特別なディレクトリ・エントリによって表されます。レプリケーション承諾は、一方向または双方向のいずれかです。

サーバー内に格納されているネーミング・コンテキストの各コピーは、レプリカと呼ばれます。他のサーバーに更新情報を送信するサーバーをサプライヤといいます。その更新情報を受け取るサーバーをコンシューマといいます。サーバーは、サプライヤとコンシューマのどちらにもなることができます。

ディレクトリ・レプリケーション・グループは、表6-4で説明するように、単一マスター、マルチマスターまたはファンアウトになります。

表6-4 ディレクトリ・レプリケーション・グループのタイプ

グループ

説明

単一マスター

1つ以上のコンシューマに変更をレプリケートするサプライヤが1つのみ存在します。クライアントはマスター・ノードのみを更新でき、コンシューマのデータの読取りのみを行うことができます。このタイプのグループでは、通常はLDAPを使用します。1つのグループ内で1ノードを除くすべてのノードを読取り専用モードに切り替えることにより、アドバンスト・レプリケーションを単一マスターとして構成することもできます。

マルチマスター

同等のものとして機能する複数のサイトが、レプリケートされたデータのグループを管理できるようにします。マルチマスター・レプリケーション環境では、各ノードはサプライヤとコンシューマ・ノードのどちらにもなります。マルチマスター・レプリケーションでは、転送メカニズムとしてLDAPまたはアドバンスト・レプリケーションを使用できます。完全なDITが各ノードにレプリケートされます。レプリケーションは常にpeer-to-peerです。

ファンアウト

point-to-pointレプリケーション・グループとも呼ばれ、コンシューマに直接レプリケートするサプライヤが含まれています。コンシューマは1つ以上の他のコンシューマにレプリケートできます。ファンアウト・レプリケーションでは、転送メカニズムにLDAPを使用します。レプリケーションには、完全レプリケーションと部分レプリケーションがあります。これは一方向または双方向のいずれかです。

6.2.4.1 単一マスター・レプリケーションの例

図6-3「単一マスター・レプリケーションの例」に、単一マスター・レプリケーション環境を示します。

図6-3 単一マスター・レプリケーションの例

図6-3の各円は、Oracle Internet Directoryのノードを表しています。ノードAはサプライヤであり、コンシューマ・ノードBおよびCをレプリケートします。ノードAは読取り/書込み可能、ノードBとCは読取り専用です。データ転送プロトコルはLDAPです。

6.2.4.2 マルチマスター・レプリケーションの例

図6-4の例に、マルチマスター・レプリケーション・グループ内で相互に更新する3つのノード(A、B、C)を示します。ノード間のレプリケーションは双方向です。

図6-4 マルチマスター・レプリケーションの例

図6-4では、すべてのレプリケーションは双方向です。

注意:
Oracle Single Sign-Onでサポートされているレプリケーション方式はマルチマスター・レプリケーションのみです。詳細は、10g (10.1.4.0.1)ライブラリの『Oracle Application Server Single Sign-On管理者ガイド』の高可用性に関する章でレプリケーション用Oracle Single Sign-Onの構成に関する項を参照してください。

6.2.4.3 ファンアウト・レプリケーションの例

図6-5に、ファンアウト・レプリケーション環境を示します。

図6-5 ファンアウト・レプリケーションの例

表6-5で、サプライヤAは、BとCの2つのコンシューマに対してレプリケーションを行います。コンシューマ・ノードBにはAの部分レプリカが含まれ、コンシューマ・ノードCにはAの完全レプリカが含まれます。

続いてこれらの各ノードが、データを他の2つのコンシューマに対してレプリケートするサプライヤとして機能し、ノードBはノードDおよびEに対して部分レプリケーションを行い、ノードCはノードFおよびGに対して完全レプリケーションを行います。ノードDおよびFは読取り専用です。

ファンアウト・レプリケーションでは、ノードはLDAPを使用してデータを転送します。

6.2.5 ゆるやかな一貫性モデル

ディレクトリ・レプリケーション・アーキテクチャはゆるやかな一貫性モデルに基づいており、レプリケーション承諾がなされた2つのレプリケートされたノードが、リアルタイムで一貫性を持つかどうかは保証されません。これにより、相互接続されたすべてのノードが使用可能でなくてもクライアントでデータを変更できるため、ディレクトリ・ネットワークの全体的な柔軟性と可用性が向上します。たとえば、1つのノードが使用できないか、または高負荷であるとします。マルチマスター・レプリケーションを使用すると、操作を代替ノードで実行でき、相互接続されたすべてのノードは徐々に同期化されます。

6.2.6 レプリケーションの概念の組合せ方法

表6-5は、LDAPとOracle Databaseアドバンスト・レプリケーションの2つの転送メカニズムを示すとともに、各タイプを他のレプリケーションの概念と組み合せる方法を示しています。

表6-5 ディレクトリ・レプリケーション・グループでのノード間のデータ転送のタイプ

概念

LDAPベースのレプリケーション

Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーション

レプリケートされるコンテンツ

完全レプリカ

部分レプリカ

完全レプリカ(通常)

レプリケーションの方向

peer-to-peer

一方向

双方向

peer-to-peer

DRGタイプ

マルチマスター・レプリケーション

単一マスター・レプリケーション

ファンアウト・レプリケーション

マルチマスター・レプリケーション

単一マスター・レプリケーション(マルチマスター構成内の1つを除く他のすべてのマスターを読取り専用モードに切り替えた場合)

6.2.7 ファンアウトを使用したマルチマスター・レプリケーション

Oracle Internet Directoryは、マルチマスター・レプリケーション・グループ内の任意のノードが、ファンアウト・レプリケーション承諾の対象にもなるようにします。マルチマスター・レプリケーション承諾内では、ノード間のデータ転送はOracle Databaseアドバンスト・レプリケーションまたはLDAPを介して行われます。ファンアウト・レプリケーション承諾内では、サプライヤからコンシューマへのデータ転送はLDAPを介して行われ、一方向または双方向のどちらも可能です。

図6-6に、ファンアウト・レプリケーションとともに使用するマルチマスター・レプリケーションの例を示します。

図6-6 ファンアウトを使用するマルチマスター・レプリケーションの例

図6-6の例では、ノードA、B、Cがマルチマスター・レプリケーション・グループを形成しています。これらのノード間では、LDAPまたはアドバンスト・レプリケーションを使用してデータを転送します。

ノードBは、ディレクトリ全体のレプリカであるノードDに変更を提供します。ノードDは、LDAPベースのレプリケーションを使用して、ノードFおよびGに変更を提供します。ノードFおよびGは、ディレクトリ全体のレプリカです。同様にノードEはノードCの完全なレプリカです。ノードEは、LDAPベースのレプリケーションを使用して、ディレクトリ全体のレプリカであるノードHおよび部分レプリカであるノードIに変更を提供します。ノードFおよびHは、読取り専用です。

関連項目:
ファンアウト・レプリケーションの詳細は、29-23ページの「LDAPベースのレプリケーション」を参照

6.3 必要なレプリケーションの種類

必要なレプリケーションのタイプは、その企業の重要な機能によって異なります。この項では、ローカルな可用性、ロード・バランシングおよび高可用性の3つの機能を満たすために使用するレプリケーションのタイプについて説明します。

ローカルな可用性

ローカルな可用性は次の状況で重要になります。

- ローカル・サイトに固有のマスター・データのローカル・コピーが必要な場合。このようなローカル・コピーには、DITの全体または一部が考えられます。

- 複数のサーバーに作業負荷を分散することで実現可能なスケーラビリティとパフォーマンスの強化が必要な場合。

- ユーザーがローカル・サイトからマスター・サイトに接続することで生じるネットワークの依存性と負荷を軽減する場合。

ローカル・サイトでデータを更新しない場合、マスター・ノードからローカル・ノードへの一方向レプリケーションを使用します。

ローカル・サイトはデータの更新を必要とせず、マスター・サイトに更新を再度レプリケートする必要がある場合、マスター・ノードとローカル・ノードの間で双方向レプリケーションを使用します。

ロード・バランシング

ロード・バランシングは次の状況で重要になります。

- 複数のサーバーに作業負荷を分散することでスケーラビリティとパフォーマンスを強化する場合。

- 特定のサーバーを、シングル・サインオンまたは電子メールなどの特定のアプリケーション専用にする場合。

- ネットワークのロード・バランシングが必要な場合。

LDAPマルチマスター・レプリケーションを使用すると、2つ以上のノード間でデータをレプリケートできます。Oracle Single Sign-On 10g(10.1.4.3.0)以上もインストールされており、Oracle Single Sign-Onスキーマをロード・バランシングでレプリケートする必要がある場合は、Oracle Databaseアドバンスト・レプリケーション・ベースのマルチマスター・レプリケーションを使用します。それ以外の場合は、LDAPベースのマルチマスター・レプリケーションを使用できます。

注意:
レプリケーションで使用するためにロード・バランサを構成する場合は、ラウンドロビン・ルーティングではなくスティッキー・ルーティングを使用します。本来、レプリケーションは非同期であるため、一方のノードに行った変更が、他方のノードで即座に有効になるわけではありません。

高可用性

高可用性は次の状況で重要になります。

- 単一サーバー障害による損失を防ぐために1つ以上のバックアップ・サーバーを備えた高可用性ソリューションが必要な場合。

- デプロイメントを地理的に分散することによって災害からアプリケーションを守る障害回復ソリューションが必要な場合。

通常、LDAPベースのマルチマスター・レプリケーションを使用すると、2つ以上のノード間でデータをレプリケートできます。ただし、Oracle Internet DirectoryとともにOracle Single Sign-On 10g (10.1.4.3.0)以上もインストールされている場合は、Oracle Databaseアドバンスト・レプリケーション・ベースのマルチマスター・レプリケーションを使用します。

第II部

基本的な管理

ここでは、一般的なOracle Internet Directoryの構成とメンテナンスのタスクについて説明します。次の各章で構成されています。

- 第7章「Oracle Internet Directoryのスタート・ガイド」

- 第8章「Oracle Internet Directoryインスタンスの管理」

- 第9章「システム構成属性の管理」

- 第10章「IPアドレスの管理」

- 第11章「ネーミング・コンテキストの管理」

- 第12章「アカウントおよびパスワードの管理」

- 第13章「ディレクトリ・エントリの管理」

- 第14章「動的グループと静的グループの管理」

- 第15章「バルク操作の実行」

- 第16章「集合属性の管理」

- 第18章「別名エントリの管理」

- 第19章「属性一意性制約エントリの管理」

- 第20章「ナレッジ参照と参照の管理」

- 第21章「ディレクトリ・スキーマの管理」

- 第22章「参照整合性の構成」

- 第23章「監査の管理」

- 第24章「ロギングの管理」

- 第25章「Oracle Internet Directoryのモニタリング」

- 第26章「Oracle Internet Directoryのバックアップとリストア」

7 Oracle Internet Directoryのスタート・ガイド

この章では、Oracle Internet Directoryでの作業を開始する方法(Oracle Internet Directory管理者として実行する必要のある最初のタスクなど)について説明します。これらのタスクには、システムへのパッチ適用、インストール後のタスクの実行、およびOracle Enterprise Manager Fusion Middleware Control、Oracle Directory Services Manager (ODSM)、コマンド行ユーティリティなどの管理インタフェースの使用が含まれます。

注意:
この章のタスクを実行する前に、『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』の説明に従ってOracle Internet Directoryをインストールして構成する必要があります。

この章には、次の項が含まれます。

- 第7.1項「システムへのパッチ適用による11gリリース1 (11.1.1.9.0)へのアップグレード」

- 第7.2項「インストール後のタスクおよび情報」

- 第7.3項「Fusion Middleware Controlを使用したOracle Internet Directoryの管理」

- 第7.4項「Oracle Directory Services Managerの使用」

- 第7.5項「コマンド行ユーティリティを使用したOracle Internet Directoryの管理」

- 第7.6項「Oracle Internet Directoryを構成および管理するための基本タスク」

7.1 システムへのパッチ適用による11gリリース1 (11.1.1.9.0)へのアップグレード

既存のシステムにパッチを適用して11gリリース1 (11.1.1.9.0)にアップグレードするには、『Oracle Fusion Middlewareパッチ適用ガイド』の手順に従います。これに加えて、次のタスクを実行します。

7.1.1 ディレクトリ・レプリケーション・グループのアップグレード

レプリケーションが既存のOracle Internet Directory環境で構成されている場合は、付録Q「ローリング・アップグレードの実行」の手順に従う必要があります。

7.2 インストール後のタスクおよび情報

Oracle Internet Directoryのインストールおよび基本構成の完了後、次のタスクを実行します。

- 第7.2.1項「環境の設定」

- 第7.2.2項「OLTS_CT_STOREおよびOLTS_ATTRSTORE表領域へのデータファイルの追加」

- 第7.2.3項「Windowsサービスの設定の変更」

- 第7.2.4項「Oracleスタックの起動と停止」

- 第7.2.5項「デフォルトのURLおよびポートの識別」

- 第7.2.6項「Oracle Internet Directoryのチューニング」

- 第7.2.7項「匿名バインドの有効化」

- 第7.2.8項「Oracle Internet Directoryの特権ポートでの実行の有効化」

- 第7.2.9項「Oracle Databaseタイムゾーンの検証」

7.2.1 環境の設定

第7.5項「コマンド行ユーティリティを使用したOracle Internet Directoryの管理」の冒頭に記載のように環境変数を設定します。

7.2.2 OLTS_CT_STOREおよびOLTS_ATTRSTORE表領域へのデータファイルの追加

Oracle Internet Directory 11g リリース1(11.1.1.6.0)以上が新規インストールされている場合は、この手順をスキップできます。この場合、Oracle Internet Directoryスキーマは、リリース1(11.1.1.6.0)以上のRCUおよびconfig.shを使用して作成されます。

11g リリース1(11.1.1.6.0)より前のリリースのインストール中に作成されたスキーマでは、Oracle Internet Directoryに100万エントリを超えて追加する予定がある場合に、OLTS_CT_STOREおよびOLTS_ATTRSTORE表領域にデータファイルを追加する必要があります。この手順は、bulkloadまたはldapadd操作の前に実行します。詳細は、『Oracle Database管理者ガイド』のデータファイルの作成および表領域への追加に関する項を参照してください。

7.2.3 Windowsサービスの設定の変更

Windowsサービス(Oracle Database、TNS Listener、OPMN)の「スタートアップの種類」を「自動」から「手動」に変更します。これは、サービスを正しい順序で開始するために必要です。

7.2.4 Oracleスタックの起動と停止

詳細は、付録P「Oracleスタックの起動と停止」を参照してください。

7.2.5 デフォルトのURLおよびポートの識別

この項に、デフォルトのURLとポートをリストします。

URLまたはポート

デフォルト値

Oracle Directory Service Manager(ODSM)

http://host:7005/odsm

Oracle Enterprise Manager Fusion Middleware Control

http://host:7001/em/

Oracle WebLogic Server管理コンソール

http://host:7001/console/

Oracle Internet Directory LDAP

3060

Oracle Internet Directory LDAPS

3131

7.2.6 Oracle Internet Directoryのチューニング

Oracle Internet Directoryのデフォルト構成では、ほとんどすべてのデプロイメントでチューニングを必要とします。デプロイメントに応じて特定の構成属性の値を変更する必要があります。『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』の「Oracle Internet Directory」の章の基本的なチューニング推奨事項に関する説明(特にOracle Databaseインスタンス・パラメータの最小値およびLDAPサーバーの属性のチューニングに関する説明)を参照してください。

チューニングの詳細は、『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』の「Oracle Internet Directory」の章を参照してください。すべての属性の説明は、第9章「システム構成属性の管理」および第42章「レプリケーション構成属性の管理」を参照してください。

7.2.7 匿名バインドの有効化

ルートDSE以外に対する匿名検索はデフォルトでは無効になっています。一部には、クライアントでルートDSE以外へのアクセスが必要なデプロイメント環境もあります。そのようなデプロイメントの場合、orclanonymousbindsflag属性を1に設定します。詳細は、「匿名ユーザーによるバインドの管理」を参照してください。

関連項目:
Oracle Database Net Services管理者ガイド

7.2.8 Oracle Internet Directoryの特権ポートでの実行の有効化

多くのオペレーティング・システムでは、スーパーユーザー権限で実行されているプロセスのみが1024よりも小さいポート番号を使用できます。デフォルトでは、Oracle Identity Management 11gのインストーラはOracle Internet Directoryに特権ポートを割り当てませんが、staticports.iniを使用してデフォルトをオーバーライドできます。(『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』を参照。)

SSLおよび非SSLポートを、インストール後に特権付きの範囲の番号に変更する場合、次の手順に従います。

1. rootユーザーでORACLE_HOME/oidRoot.shを実行します。

2. 次のいずれかの方法でポート番号を再度割り当てます。

- 「サーバー・プロパティの構成」に記載のように、Oracle Enterprise Manager Fusion Middleware Controlの「サーバー・プロパティ」ページの「一般」タブで、「SSLポート」および「非SSLポート」の値を変更します。

- 第9.4.1項「ldapmodifyを使用したシステム構成属性の設定」に記載のように、ldapmodifyを使用してインスタンス固有の構成エントリのorclnonsslportおよびorclsslportの値を変更します。

3. 第8.3.4項「opmnctlを使用したOracleインスタンスのコンポーネント登録の更新」に記載のように、opmnctl updatecomponentregistrationを実行します。(Oracle Internet Directoryのスタンドアロン・インスタンスを実行している場合は、「Oracle Internet Directoryインスタンスの追加作成」に記載のように、この手順は不要です。)

4. 第8.2.4項「Fusion Middleware Controlを使用したOracle Internet Directoryサーバーの再起動」または第8.3.9項「opmnctlを使用したOracle Internet Directoryサーバーの再起動」に記載のように、Oracle Internet Directoryを再起動します。

7.2.9 Oracle Databaseタイムゾーンの検証

Oracle Internet Directoryガベージ・コレクション・ロジックが正しく動作していることを確認するには、第36.2項「ガベージ・コレクション用Oracle Databaseタイムゾーンの設定」の説明に従って、Oracle Databaseのdbtimezoneパラメータを検証します。

7.3 Fusion Middleware Controlを使用したOracle Internet Directoryの管理

Oracle Enterprise Manager Fusion Middleware Controlは、Oracle Fusion Middlewareに対して包括的なシステム管理プラットフォームを提供するグラフィカル・ユーザー・インタフェースです。Fusion Middleware Controlでは、様々なパフォーマンス・データおよび管理機能を、ドメイン、Oracleインスタンス、ミドルウェア・システム・コンポーネントおよびアプリケーション用の個別のWebベースのホームページへと編成します。

注意:

- Oracle Internet Directoryのインストール時にドメインを要求されたときに「ドメインなしで構成」を選択した場合は、Oracle Enterprise Manager Fusion Middleware Controlを使用できなくなります。

- Oracle Enterprise Manager Fusion Middleware Controlは、そのSSLポートを介してOracle Internet Directoryを管理します。Oracle Internet DirectoryのSSLポートは、認証なしまたはサーバー認証用に構成されている必要があります。また、構成する暗号には、次のDiffie-Hellman認証なし暗号が1つ以上含まれている必要があります。

- SSL_DH_anon_WITH_3DES_EDE_CBC_SHA

- SSL_DH_anon_WITH_RC4_128_MD5

- SSL_DH_anon_WITH_DES_CBC_SHA

Oracle Enterprise Manager Fusion Middleware Controlは、そのSSLポートを介してOracle Internet Directoryを管理します。サーバーを構成するためにWLSTまたはOracle Enterprise Manager Fusion Middleware Controlを使用する場合は、orclsslenableを1または2に設定します。「SSL認証モード」を参照してください。

Oracle Internet DirectoryのSSLポートが誤って構成されている場合、または適切な暗号が構成されていない場合は、WLSTまたはOracle Enterprise Manager Fusion Middleware Controlを使用してOracle Internet Directoryのパラメータを変更することはできません。第27.1.3項「SSL認証モード」を参照してください。

- Fusion Middleware ControlおよびOracle Directory Services Managerでサポートされているブラウザの詳細は、http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.htmlからリンクされている、Oracle Fusion Middleware 11gR1のシステム要件およびサポートされているプラットフォームに関する説明を参照してください。

Oracle Internet Directoryは、Oracle Enterprise Manager Fusion Middleware Controlのターゲット・タイプです。Oracle Internet Directoryのインタフェースを使用する手順は、次のとおりです。

1. Fusion Middleware Controlに接続します。
URLの形式は次のとおりです。

http://host:port/em

2. 左パネルのトポロジ・ツリーで、ドメインを展開して、「Fusion Middleware」→「Identity and Access」を選択します。あるいは、ドメインのホームページから「Fusion Middleware」→「Identity and Access」と展開します。Oracle Internet Directoryのインスタンスが両方の箇所に表示されます。コンポーネント・インスタンスの完全名を表示するには、インスタンス名の上にマウスを移動します。

3. 管理するOracle Internet Directoryコンポーネントを選択します。

4. 「Oracle Internet Directory」メニューを使用してタスクを選択します。

表7-1に示すとおり、「Oracle Internet Directory」メニューを使用して、Oracle Internet Directory用の他のFusion Middleware Controlページに移動したり、Oracle Internet Directory用のOracle Directory Services Managerページに移動したり、他のタスクを実行できます。

表7-1 「Oracle Internet Directory 」メニューの使用

タスク

選択

ホームページへの戻り

ホーム

パフォーマンス・サマリーの表示

「モニタリング中」→「パフォーマンス」

Oracle Internet Directoryコンポーネントの起動、停止または再起動

「コントロール」から、それぞれ「起動」、「停止」または「再起動」

Oracle Internet Directoryのログの表示

「ログ」→「ログ・メッセージの表示」

非SSLおよびSSLポート情報の表示。

「ポートの使用状況」

このOracle Internet Directoryコンポーネントに固有のプロパティの管理

「管理」→「サーバー・プロパティ」

同じOracle Databaseに接続しているすべてのOracle Internet Directoryコンポーネントで共有されるプロパティの管理

「管理」→「共有プロパティ」

レプリケーションの設定

「管理」→「レプリケーション管理」

チューニングおよびサイズ設定の推奨事項の取得

「管理」→「チューニングとサイズ設定」

Oracle Directory Services Managerを使用したOracle Internet Directoryエントリの管理

「Directory Services Manager」→「データ・ブラウザ」

Oracle Directory Services Managerを使用したOracle Internet Directoryスキーマの管理

「Directory Services Manager」→「スキーマ」

Oracle Directory Services Managerを使用したOracle Internet Directoryセキュリティの管理

「Directory Services Manager」→「セキュリティ」

Oracle Directory Services Managerを使用したOracle Internet Directory拡張機能の管理

「Directory Services Manager」→「拡張」

Oracle Internet Directoryに対する監査の構成

「セキュリティ」→「監査ポリシー設定」

Oracle Internet Directoryに対するウォレットの作成

「セキュリティ」→「ウォレット」

ターゲット名、ソフトウェアのバージョン、Oracleホーム、Oracleインスタンス、Oracle Enterprise Manager Fusion Middleware Controlエージェントおよびホストの表示

「一般情報」。

7.4 Oracle Directory Services Managerの使用

この項の内容は次のとおりです。

- 第7.4.1項「Oracle Directory Services Managerの概要」

- 第7.4.2項「SSO統合用ODSMの構成」

- 第7.4.3項「ODSM統合用SSOサーバーの構成」

- 第7.4.4項「ODSM-SSO統合用のOracle HTTP Serverの構成」

- 第7.4.5項「Oracle Directory Services Managerの起動」

- 第7.4.6項「Oracle Directory Services Managerからサーバーへの接続」

- 第7.4.7項「Oracle Directory Services Managerセッション・タイムアウトの構成」

- 第7.4.8項「Oracle WebLogic ServerクラスタでOracle Directory Services ManagerをサポートするためのOracle HTTP Serverの構成」

関連項目:
付録O「Oracle Directory Services ManagerのJavaキーストアの管理」

7.4.1 Oracle Directory Services Managerの概要

Oracle Directory Services Managerは、Oracle Internet DirectoryインスタンスとOracle Virtual Directoryインスタンスの管理用のWebベースのインタフェースです。非推奨となったOracle Directory Managerにかわるものです。Oracle Directory Services Managerでは、ディレクトリ構造の構成、ディレクトリ内のオブジェクトの定義、ユーザー、グループおよびその他のエントリの追加と構成ができます。ODSMは、エントリ、スキーマ、セキュリティおよび他のディレクトリ機能を管理するために使用するインタフェースです。

ODSMを使用してシステム構成属性を管理することもできます。これは、Fusion Middleware Controlを利用できない場合やFusion Middleware Controlインタフェースがない属性を変更する必要がある場合に便利です。第9.5項「ODSMデータ・ブラウザを使用したシステム構成属性の管理」および第13.2項「Oracle Directory Services Managerを使用したエントリの管理」を参照してください。

7.4.1.1 Oracle Directory Services ManagerでのJAWSスクリーン・リーダーの使用

ODSMでJAWSを使用する場合、新規ウィンドウがポップアップ表示されるたびに、JAWSはポップアップを読み取ります。ページ全体を読み取るには、[Insert]キーを押しながら[b]キーを押します。

7.4.1.2 Oracle Directory Services Managerへの非スーパーユーザー・アクセス

Oracle Directory Services Managerでは、ディレクトリで有効な識別名およびパスワードを持つ任意のユーザーとしてOracle Internet Directoryに接続できます。スーパーユーザーcn=orcladminとして、またはcn=DirectoryAdminGroup,cn=oracle internet directoryのメンバーであるユーザーとして接続している場合は、インタフェースのすべてのタブにアクセスできます。その他のユーザーとしてログインしている場合は、「ホーム」タブ、「スキーマ」タブおよび「データ・ブラウザ」タブのみにアクセスできます。

7.4.1.3 Oracle Directory Services ManagerとのSingle Sign-On統合

シングル・サインオン(SSO)を使用するようにOracle Directory Services Managerを構成できます。SSOで構成すると、Oracle Directory Services Managerでは、SSOサーバーによって認証されたユーザーは、SSO対応ディレクトリを管理する権限を持っている場合、ログインせずにそのディレクトリに接続できます。

Oracle Directory Services Managerは、SSO認証済ユーザーが管理できるOracle Internet Directoryサーバーのリストを維持します。SSO認証済ユーザーがOracle Internet Directoryの管理に必要な権限を持っているかどうかを検証するために、Oracle Directory Services ManagerはSSO認証済ユーザーをOracle Internet Directoryサーバー内の識別名にマップします。

Oracle Directory Services Managerは、プロキシ認証を使用してディレクトリに接続します。プロキシ・ユーザーの識別名およびパスワードは、資格証明ストア・フレームワーク(CSF)と呼ばれるセキュアなストレージ・フレームワークに格納されます。

SSO認証済ユーザーをマップするために、Oracle Directory Services Managerは、プロキシ権限を持つユーザーの資格証明を使用して、Oracle Internet Directoryサーバーに対して認証します。次に、Oracle Directory Services ManagerはSSO認証済ユーザーの一意識別子をOracle Internet Directoryユーザーの一意識別子にマップしようとします。

WLS管理者は、プロキシ・ユーザーの資格証明、一意の識別子属性、およびOracle Directory Services ManagerがCSFに格納されているユーザーを検索するベース識別名を構成します。Oracle Directory Services Managerは、有効な識別名を取得すると、SSO認証済ユーザーをその識別名にマップします。SSO認証済ユーザーが有効な識別名にマップされると、Oracle Directory Services Managerは、プロキシ認証を使用して、SSO認証済ユーザーのマップされた識別名でOracle Internet Directoryサーバーに接続します。

SSO統合を構成するには、次の項を参照してください。

- 第7.4.2項「SSO統合用ODSMの構成」

- 第7.4.3項「ODSM統合用SSOサーバーの構成」

- 第7.4.4項「ODSM-SSO統合用のOracle HTTP Serverの構成」

7.4.2 SSO統合用ODSMの構成

ODSM-SSO統合を構成するには、http://host:port/odsm-configにあるODSMプロキシ・バインド構成画面を使用します。WebLogic管理者としてログインします。

この画面で、SSOユーザーが管理できるディレクトリ・サーバーのセットをOracle Directory Services Managerに提供します。この画面には、シングル・サインオンによりアクセス可能なディレクトリが示されます。

「表示」リストを使用して、列の数および順序を変更します。既存のディレクトリを削除するには、「削除」をクリックします。

既存のディレクトリを変更するには、「変更」をクリックします。

シングル・サインオンによりアクセス可能なディレクトリを新たに追加するには、「追加」をクリックします。

「変更」または「追加」をクリックすると、「ディレクトリ詳細」画面が表示されます。次のようにします。

1. 「ポート・タイプ」リストから「非SSL」または「SSL」を選択します。

2. 「ディレクトリ・タイプ」リストから「OID」または「OVD」を選択します。

3. 次の情報を入力します。

- ディレクトリのホストおよびポート。

- プロキシ・ユーザーのDNおよびパスワード: Oracle Directory Services Managerがプロキシ認証に使用する識別名およびパスワード。

- ユーザー・コンテナDN: ディレクトリでユーザー・エントリが配置される識別名。

- ユーザー参照属性: ディレクトリ内のユーザーの識別名を参照するための一意属性。たとえば、SSOサーバーがユーザーのメールIDをそのユーザーの一意識別子としてOracle Directory Services Managerに送信した場合、mailをユーザー参照属性として構成できます。

4. 「検証」をクリックして、ディレクトリ接続の詳細を検証します。
Oracle Directory Services Managerは、提供された資格証明を使用してディレクトリ・サーバーに対して認証します。

5. 「適用」をクリックして選択内容を適用します。
選択を中止する場合は、「元に戻す」をクリックします。

6. 「SSOログアウトURL」テキスト・ボックスでSSOサーバーの「ログアウトURL」を指定します。
たとえば、http://myoamhost.mycompany.com:14100/oam/server/logoutは、Oracle Access Manager 11gサーバーのデフォルトのログアウトURLです。このフィールドのみを構成した場合、Oracle Directory Services Managerにより、Oracle Directory Services Managerページの右上の隅に「ログイン」リンクが表示されます。

7.4.3 ODSM統合用SSOサーバーの構成

SSO-ODSM統合を適切に機能させてパフォーマンスを向上するには、特定のODSM URLを保護対象、非保護または除外として構成する必要があります。

ODSMのホーム・ページは、非保護のURLである必要があります。つまり、SSO認証プロセスを経ていないユーザーを含め、すべてのユーザーがODSMホーム・ページにアクセスできる必要があります。

/odsm/odsm-sso.jspのURLは、SSOサーバーによって保護されている必要があります。ユーザーがホーム・ページの右上の隅に表示される「ログイン」リンクをクリックすると、ユーザーは/odsm/odsm-sso.jspにリダイレクトされます。SSOサーバーは、そのユーザーがまだ認証されていない場合、ユーザーのユーザー名およびパスワードを調べます。認証に成功すると、ユーザーはODSMホーム・ページに戻されます。

ODSM URLを次のように構成します。

- 保護: /odsm/odsm-sso.jsp

- 非保護: /odsm/faces/odsm.jspx

- 除外: /odsm/.../

CSS、JavaScriptおよびグラフィック(/odsm/.../)ファイルを除外に設定すると、これらのファイルがOracle Access Managerによって検証されなくなり、デプロイメントのパフォーマンスを改善できます。

Oracle Access Manager 11gまたはOracle Access Manager 10gをSSOプロバイダとして使用できます。

SSO認証済ユーザーの一意識別子をHTTPヘッダーを介してOracle Directory Services Managerに送信するようにOracle Access Managerサーバーを構成する必要があります。Oracle Directory Services ManagerはOAM_REMOTE_USER HTTPヘッダーを探します。Oracle Access Managerサーバーは、デフォルトでOAM_REMOTE_USERヘッダーを設定します。このヘッダーを使用できない場合、Oracle Directory Services Managerはodsm-sso-user-unique-id HTTPヘッダーを探します。Oracle Directory Services Managerがこれらのヘッダーのいずれも見つけることができない場合、Oracle Directory Services Manager SSO統合は機能しません。

ユーザーの一意識別子をHTTPヘッダーを介して送信する以外に、オプションで、次のHTTPヘッダーを送信するようにOracle Access Managerを構成できます。

- ユーザーの名を送信するようにodsm-sso-user-firstname HTTPヘッダーを構成します。

- ユーザーの姓を送信するようにodsm-sso-user-lastname HTTPヘッダーを構成します。

これらのヘッダーが使用可能な場合、ユーザーの名および姓がOracle Directory Services Managerの右上の隅にある「次としてログイン」セクションに表示されます。名または姓を使用できない場合は、ユーザーの一意識別子が「次としてログイン」セクションに表示されます。

Oracle Access Manager 11gを構成するには、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のOAM 11g SSOソリューションのデプロイに関する項を参照してください。

7.4.4 ODSM-SSO統合用のOracle HTTP Serverの構成

Oracle HTTP ServerをSSOサーバーのWebゲート・エージェントのホスティングに使用している場合、およびODSMをホスティングするWebLogicサーバーへのフロントエンドとして使用している場合は、ODSMをホスティングするWebLogicサーバーに/odsmで始まるすべてのリクエストを転送するようにOracle HTTP Serverのmod_wl_ohsモジュールを構成する必要があります。mod_wl_ohsモジュールにより、Oracle HTTP ServerからOracle WebLogic Serverへのリクエストをプロキシ処理できます。

mod_wl_ohsを構成するには、『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』のmod_wl_ohsモジュールの構成に関する項を参照してください。

7.4.5 Oracle Directory Services Managerの起動

Oracle Directory Services Managerの起動は、直接、またはOracle Enterprise Manager Fusion Middleware Controlから実行できます。

注意:

- Oracle Internet Directoryのインストール時にドメインを要求されたときに「ドメインなしで構成」を選択した場合、Oracle Directory Services Managerは使用できなくなります。

- Fusion Middleware ControlおよびOracle Directory Services Managerでサポートされているブラウザの詳細は、http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.htmlからリンクされている、Oracle Fusion Middleware 11gR1のシステム要件およびサポートされているプラットフォームに関する説明を参照してください。

- Oracle Directory Services Managerを直接起動するには、次のURLをブラウザのアドレス・フィールドに入力します。

http://host:port/odsm

Oracle Directory Services ManagerにアクセスするURLで、hostはOracle Directory Services Managerが稼働している管理対象サーバーの名前で、portはWebLogicサーバーからの管理対象サーバーのポート番号です。正確なポート番号は、$Fusion_Middleware_Home/Oracle_Identity_Management_domain/servers/wls_ods/data/nodemanager/wls_ods1.urlファイル( Fusion_Middleware_HomeはFusion Middlewareがインストールされているルート・ディレクトリ)で確認できます。

- Fusion Middleware ControlからOracle Directory Services Managerを起動するには、Oracle Internet Directoryターゲットの「Oracle Internet Directory」メニューから「Directory Services Manager」を選択し、「データ・ブラウザ」、「スキーマ」、「セキュリティ」または「拡張」を選択します。(同様の方法で、Oracle Virtual Directoryメニューから接続できます。)
ODSMのようこそ画面を含む新規ブラウザ・ウィンドウがポップアップ表示されます。次の項の説明に従って、サーバーに接続します。

関連項目:
第R.1.24項「Oracle Directory Services Managerに関するトラブルシューティング」

7.4.6 Oracle Directory Services Managerからサーバーへの接続

ODSMのようこそ画面が表示されたら、Oracle Internet DirectoryサーバーまたはOracle Virtual Directoryサーバーに接続できます。

この項の内容は次のとおりです。

- 第7.4.6.1項「Oracle Directory Services Managerからディレクトリ・サーバーへのログイン」

- 第7.4.6.2項「SSLを使用したOracle Directory Services Managerからディレクトリ・サーバーへのログイン」

注意:

- ODSMにログインした後は、複数のディレクトリ・インスタンスに同じブラウザ・ウィンドウから接続できます。

- 同じブラウザ・プログラムの複数のウィンドウを使用して異なるディレクトリに同時に接続することは避けてください。このような接続によって、Target unreachableエラーが発生する場合があります。

- Internet ExplorerとFirefoxなど、異なるブラウザ・プログラムから同じODSMインスタンスにログインし、それぞれを別のディレクトリ・インスタンスに接続することが可能です。

- ブラウザの言語設定を変更する場合、新しい設定を使用するにはセッションを更新する必要があります。セッションを更新するには、「URL」フィールドにODSM URLを再入力して[Enter]を押すか、ブラウザを終了して再起動します。

7.4.6.1 Oracle Directory Services Managerからディレクトリ・サーバーへのログイン

次のようにしてOracle Directory Services Managerからディレクトリ・サーバーの非SSLポートにログインします。

1. ラベル「クリックしてディレクトリに接続」の右にある小さな矢印をクリックします。次のセクションが含まれたダイアログ・ボックスが開きます。

- ライブ接続: 戻ることのできる現在の接続。

- 切断されている接続: 一度接続した後、切断したディレクトリ・サーバーのリスト。Oracle Directory Services Managerでは、以前に使用した接続に関する情報を保存し、オプション名別またはサーバー別にリストし、その接続を再選択できるようにします。

注意:
接続情報(サーバーのポート番号など)が変更されると、Oracle Directory Services Managerの接続情報が不正確になり、接続に失敗します。接続情報は編集できないため、リストから接続を削除して新しい接続を作成する必要があります。

- 新規接続: 新規接続の開始に使用されます。

SSO認証済であるユーザーには、第7.4.6.3項「SSO認証済ユーザーとしてのSSO対応ディレクトリへの接続」で説明しているように、追加セクションが表示される場合があります。

2. ライブ接続に再接続するには、クリックします。
切断されている接続を選択するには、エントリをクリックします。大部分のフィールドが入力された簡易版のログイン・ダイアログが表示されます。選択をリストから削除するには、選択後「削除」を選択します。

新規ディレクトリ・サーバーへの接続を開始するには、「新規接続の作成」をクリックするか、[Ctrl]キーを押しながら[N]キーを押します。「新規接続」ダイアログが表示されます。

3. 「OID」または「OVD」を選択します。

4. オプションで、このエントリを切断されている接続リストで識別する別名を入力します。

5. 管理するOracle Internet DirectoryまたはOracle Virtual Directoryのインスタンスのサーバーおよび非SSLポートを入力します。

6. 「SSL有効」の選択を解除します。

7. ユーザー(通常はcn=orcladmin)とパスワードを入力します。

8. ログイン後に開く「開始」ページを選択します。

9. 「接続」をクリックします。

Oracle Internet DirectoryまたはOracle Virtual Directoryサーバーにログインした後は、ナビゲーション・タブを使用して他のページを選択できます。

Oracle Internet DirectoryおよびOracle Virtual Directory用のOracle Directory Services Managerホームページには、ディレクトリとデータベースに加えて、Oracle Directory Services Manager自体のバージョン情報も示されています。統計情報も直接示されます。

関連項目:
第R.1.24項「Oracle Directory Services Managerに関するトラブルシューティング」

7.4.6.2 SSLを使用したOracle Directory Services Managerからディレクトリ・サーバーへのログイン

SSL認証モードについてよく知らない場合は、「SSL認証モード」を参照してください。

サーバーのSSLポートにログインする場合は、手順5でSSLポートを指定している場合、および手順6で「SSL有効」の選択を解除していない場合を除き、第7.4.6.1項「Oracle Directory Services Managerからディレクトリ・サーバーへのログイン」の手順に従ってください。手順9で「接続」をクリックした後、SSL認証のタイプによっては証明書が提示される場合があります。

7.4.6.2.1 SSL認証なし

ディレクトリ・サーバーがSSL認証なしモード(デフォルト)で稼働している場合、証明書は提示されません。SSL認証なしでは、データの機密性と整合性は保証されますが、X509証明書を使用した認証は行われません。

7.4.6.2.2 SSLサーバーのみ認証

ディレクトリ・サーバーでSSLサーバー認証のみモードを使用している場合、手順9で「接続」をクリックすると、サーバーの証明書が提示されます。サーバー証明書の正統性を手動で確認した後、証明書を恒久的に受け入れるか、現在のセッションに対してのみ受け入れるか、証明書を拒否します。証明書を恒久的に受け入れる場合、証明書はJavaキーストア(JKS)に格納されます。以降は、そのサーバーに接続する際、証明書を受け入れるよう要求されません。現在のセッションに対してのみ受け入れた場合、サーバーに接続するたびに証明書を受け入れるか拒否するかを確認されます。証明書を拒否した場合、ODSMでサーバーへの接続を閉じます。

関連項目:
第O.1項「ODSMのJavaキーストアの管理の概要」

7.4.6.2.3 SSLクライアントとサーバー認証

サーバーでSSLクライアントとサーバー認証モードを使用している場合、手順9で「接続」をクリックすると、証明書が提示されます。第7.4.6.2.2項「SSLサーバーのみ認証」の指示に従ってください。

ODSMはサーバーの証明書を受け入れた後、認証用に自身の証明書をサーバーに送信します。その証明書が信頼できる証明書のリスト内にある場合、サーバーでODSMの証明書が受け入れられます。

ODSMの証明書の識別名がサーバー内にある場合、接続ダイアログでユーザー名とパスワードを入力する必要がありません。

ODSMの証明書の識別名がサーバー内にない場合、ユーザー名とパスワードを入力する必要があります。

ODSMの証明書は自己署名証明書です。CAによって署名された証明書をODSMに割り当てるには、keytoolコマンドを使用する必要があります。付録O「Oracle Directory Services ManagerのJavaキーストアの管理」を参照してください。

7.4.6.3 SSO認証済ユーザーとしてのSSO対応ディレクトリへの接続

シングル・サインオン・サーバーによってすでに認証されている場合、ODSMでは、SSO対応ディレクトリにエントリを持っている場合は、ログインせずにそのディレクトリに接続できます。ODSMのようこそページにアクセスしたときに、1つのSSO対応ディレクトリのみにエントリがある場合、ODSMによってそのディレクトリに接続されます。複数のSSO対応ディレクトリにエントリがある場合、ODSMでは、次のように接続するディレクトリを選択できます。

ラベル「クリックしてディレクトリに接続」の右にある小さな矢印をクリックします。この場合、ダイアログ・ボックスには、接続する権限があるSSO対応ディレクトリがリストされた追加のセクションが表示されます。必要なディレクトリを選択します。ODSMは、ユーザー名やパスワードを要求せずにユーザーを接続します。

接続しているポートがSSLポートである場合は、第7.4.6.2.1項「SSL認証なし」、第7.4.6.2.2項「SSLサーバーのみ認証」または第7.4.6.2.3項「SSLクライアントとサーバー認証」の適切な手順を実行する必要があります。

7.4.7 Oracle Directory Services Managerセッション・タイムアウトの構成

Oracle Internet Directory 11gリリース1 (11.1.1.9.0)以降では、Oracle Directory Services Manager (ODSM)のデフォルトのセッション・タイムアウトは、5分(300秒)です。

ODSMセッション・タイムアウトを異なる値に設定するには、WebLogic Server管理コンソールを使用します。(以前のリリースでは、web.xmlデプロイメント記述子の<session-config>要素を編集してタイムアウトを設定していました。)

ODSMのセッション・タイムアウトを構成する手順は、次のとおりです。

1. WebLogic Server管理コンソールにログインします。

2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

3. 左ペインで、「デプロイメント」をクリックします。

4. 「デプロイメント」で、「odsm (11.1.1.2.0)」を展開します。

5. 「モジュール」で、「/odsm」をクリックします。

6. 「構成」タブを選択します。

7. 「セッション・タイムアウト」を必要な値に設定します。例: 600秒。

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

9. 「デプロイメント・プラン保存アシスタント」で、「OK」をクリックしてPlan.xmlファイルに変更を保存します。

10. 「チェンジ・センター」で、「変更のアクティブ化」をクリックします。

変更をテストするには、ODSMにアクセスし、ディレクトリ・サーバーにログインして、セッション・タイムアウトに指定した時間(600秒など)が経過するまでセッションをアイドル状態のままにします。指定した時間が経過するとセッションがタイムアウトし、ODSMにセッション・タイムアウトのポップアップ・メッセージが表示されます。

7.4.8 Oracle WebLogic ServerクラスタでOracle Directory Services ManagerをサポートするためのOracle HTTP Serverの構成

クラスタ化されたOracle WebLogic Server環境でOracle Directory Services Managerのリクエストを複数のOracle WebLogic ServerにルーティングするようOracle HTTP Serverを構成するには、次の手順に従います。

1. Oracle HTTP Serverのhttpd.confファイルのバックアップ・コピーを作成します。この手順の実行後に問題が起きた場合、バックアップ・コピーがあると、元の状態に戻すことができます。

2. 次のテキストをOracle HTTP Serverのhttpd.confファイルの最後に追加し、変数プレースホルダ値を環境に固有のホスト名と管理対象サーバー・ポート番号に置き換えます。エントリの最初の行として<Location /odsm/ >を必ず使用します。<Location /odsm/faces >または<Location /odsm/faces/odsm.jspx >を使用すると、Oracle Directory Services Managerインタフェースの外観に問題が起こることがあります。

<Location /odsm/ >
SetHandler weblogic-handler
WebLogicCluster host-name-1:managed-server-port,host-name_2:managed_server_port
</Location>

3. Oracle HTTP Serverを停止してから起動し、構成の変更を有効にします。

注意:
接続先のクラスタ内のOracle WebLogic Serverが停止すると、Oracle Directory Services Managerで接続が失われ、セッション・タイムアウト・メッセージが表示されます。Oracle Directory Services Managerにログインしなおすと、Oracle Directory Services Managerのリクエストは、httpd.confファイルで指定したクラスタ内の2番目のOracle WebLogic Serverにルーティングされます。

7.5 コマンド行ユーティリティを使用したOracle Internet Directoryの管理

sqlplusなどのデータベース・クライアント・ユーティリティやOracle Internet Directoryコマンド行ユーティリティを使用するには、通常、次の環境変数を設定する必要があります。

- ORACLE_HOME - Oracle Identity Managementのインストール内の書込み不可ファイルの場所。

- ORACLE_INSTANCE - Oracle Identity Managementのインストール内の書込み可能ファイルの場所。

- TNS_ADMIN - データベース接続文字列がtnsnames.oraファイルに定義されているディレクトリ。デフォルトでは$ORACLE_INSTANCE/configディレクトリになります。tnsnames.oraに定義されているデータベース接続の別名は、デフォルトではOIDDBになります。

- NLS_LANG (APPROPRIATE_LANGUAGE.AL32UTF8) - インストール時のデフォルトの言語セットはAMERICAN_AMERICAです。

- PATH - 次のディレクトリ位置をPATHに追加する必要があります。
$ORACLE_HOME/bin

$ORACLE_HOME/ldap/bin

$ORACLE_INSTANCE/bin

コマンド行で実行できる多くのアクティビティは、Oracle Enterprise Manager Fusion Middleware ControlまたはOracle Directory Services Managerでも実行できます。一部の機能には、コマンド行以外では実行できないものもあります。

7.5.1 標準LDAPユーティリティの使用方法

Oracle Internet Directoryでは標準LDAPコマンド行ユーティリティ(ldapadd、ldapaddmt、ldapbind、ldapcompare、ldapdelete、ldapmoddn、ldapmodify、ldapmodifymtおよびldapsearch)がサポートされます。次に例を示します。

ldapbind -D "cn=orcladmin" -q -h "myserver.example.com" -p 3060

ldapsearch -b "cn=subschemasubentry" -s base "objectclass=*" -p 3060 \
-D "cn=orcladmin" -q

このマニュアルには、LDAPツールの使用方法の例が多数含まれています。

関連項目:

- 第13.3項「LDAPコマンド行ツールを使用したエントリの管理」

- 各ツールの詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』の「Oracle Internet Directoryデータ管理ツール」の章を参照してください。

セキュリティ上の理由から、コマンド行でパスワードを入力することはできるかぎり避けてください。コマンド行で入力したパスワードは画面上に表示され、ログ・ファイルや、psコマンドからの出力に表示される場合があります。

プロンプトでパスワードを入力すると、画面上やps出力またはログ・ファイルには表示されません。-P passwordオプションや-w passwordオプションは使用しないで、かわりにそれぞれ-Qオプションや-qオプションを使用してください。ウォレット・パスワードが存在せず、-Qオプションを使用している場合は、パスワードのプロンプトが表示されたときにEnterキーを押します。

LDAPツールは、環境変数LDAP_PASSWORD_PROMPTONLYがTRUEまたは1に設定されている場合、オプション-w passwordおよび-P passwordを無効にするよう変更されています。この機能をできるかぎり使用してください。

関連項目:
『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のコマンド行ツールでのパスワードの使用に関する説明

7.5.2 バルク・ツールの使用

Oracle Internet Directoryには、多数のエントリの管理に役立つ複数のツールが用意されています。第15章「バルク操作の実行」を参照してください。

関連項目:
各ツールの詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』の「Oracle Internet Directoryデータ管理ツール」の章を参照してください。

7.5.3 WLSTの使用

Oracle WebLogic Scripting Tool(WLST)は、Jythonベースのコマンド行スクリプト環境であり、WebLogic Serverドメインの管理およびモニターに使用できます。これを使用してOracle Internet Directoryを管理およびモニターするには、Oracle Internet Directoryが配置されているカスタムMBeanツリーに移動する必要があります。そこで、Oracle Internet Directoryリソースを表すマネージドBean(MBean)のリストの作成、値の取得および値の変更が可能です。第9.3項「WLSTを使用したシステム構成属性の管理」および第27.3項「WLSTを使用したSSLの構成」を参照してください。

注意:
WLSTは、そのSSLポートを介してOracle Internet Directoryを管理します。サーバーを構成するためにWLSTまたはOracle Enterprise Manager Fusion Middleware Controlを使用する場合は、orclsslenableを1または2に設定します。「SSL認証モード」を参照してください。

7.6 Oracle Internet Directoryを構成および管理するための基本タスク

次に、Oracle Internet Directoryの基本環境を構成および管理するために実行する必要のある手順の概要を示します。

1. LDAPサーバーを起動および停止します。第8章を参照してください。

2. システム構成属性を管理します。第9章を参照してください。

3. ディレクトリ・エントリを管理します。第13章を参照してください。

4. ディレクトリ・スキーマを管理します。第21章を参照してください。

5. 監査を構成します。第23章を参照してください。

6. ログ・ファイルを管理します。第24章を参照してください。

7. SSLを構成します。第27章を参照してください。

8. パスワード・ポリシーを構成します。第29章を参照してください。

9. アクセス制御を構成します。第30章を参照してください。

10. Oracle Internet Directoryのデプロイメントに関するサイズ設定とチューニングの推奨事項を取得します。『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』の「Oracle Internet Directory」の章のチューニングとサイズ設定ウィザードを使用した推奨事項の取得に関する説明を参照してください。

11. レプリケーションを設定します。第40章および付録Cを参照してください。

12. アドバンスト・レプリケーション・ベースのレプリケーション承諾からLDAPベースのレプリケーション承諾へ変換します。第40.2項「アドバンスト・レプリケーション・ベースの承諾のLDAPベースの承諾への変換」を参照してください。

13. 既存のレプリケーション設定を変更します。第43章を参照してください。

このガイドでは、実際のOracle Fusion Middleware環境に応じて実行する必要があるタスクなど、他のタスクについても説明しています。

8 Oracle Internet Directoryインスタンスの管理

この章では、Oracle Internet Directoryサーバー・インスタンスについて説明し、それらのインスタンスをOracle Enterprise Manager Fusion Middleware ControlとopmnctlおよびOIDCTLユーティリティを使用して作成および管理する方法について説明します。

この章の内容は次のとおりです。

- 第8.1項「Oracle Internet Directoryインスタンスの管理の概要」

- 第8.2項「Fusion Middleware Controlを使用したOracle Internet Directoryコンポーネントの管理」

- 第8.3項「opmnctlを使用したOracle Internet Directoryコンポーネントの管理」

- 第8.4項「OIDCTLを使用したレプリケーション・サーバーのインスタンスの起動」

- 第8.5項、「レプリケーション・サーバーの起動と停止の方法について」

関連項目:
付録B「OIDCTLを使用したOracle Internet Directoryインスタンスの管理」

8.1 Oracle Internet Directoryインスタンスの管理の概要

この概要の項目は次のとおりです。

- 第8.1.1項「インスタンス固有の構成エントリ」

- 第8.1.2項「最初のOracle Internet Directoryインスタンスの作成」

- 第8.1.3項「Oracle Internet Directoryインスタンスの追加作成」

- 第8.1.4項「OracleインスタンスまたはコンポーネントのWebLogic Serverへの登録」

8.1.1 インスタンス固有の構成エントリ

11gリリース1 (11.1.1)では、Oracle Internet Directoryインスタンスの構成情報は、次の形式の識別名を持つインスタンス固有の構成エントリにあります。

cn=componentname,cn=osdldapd,cn=subconfigsubentry

componentnameは、Type=OIDのOracle Fusion Middlewareシステム・コンポーネントの名前(oid1、oid2など)です。

インスタンス固有の構成エントリは手動で作成しません。そのかわりに、Type=OIDのOracle Fusion Middlewareシステム・コンポーネントを作成します。これによって、oid1という名前のインスタンス固有の構成エントリが自動的に作成されます。

図8-1に、DIT内の2つのOracle Internet Directoryコンポーネントの構成エントリを示します。インスタンス固有の構成エントリの識別名は、次のようになります。

cn=oid1,cn=osdldapd,cn=subconfigsubentry
cn=oid2,cn=osdldapd,cn=subconfigsubentry

図8-1 2つのインスタンス固有の構成エントリを示すDIT

インスタンス固有の構成の属性では、ホスト名、ポート、監査対象のイベント、子プロセスの数、セキュリティ構成などの情報を指定します。全一覧は、第9.1.3項「インスタンス固有の構成エントリの属性」を参照してください。

8.1.2 最初のOracle Internet Directoryインスタンスの作成

Oracle Internet Directoryをホスト・コンピュータにインストールすると、Oracle Identity Management 11gインストーラによってType=OIDのOracle Fusion Middlewareシステム・コンポーネントが新規または既存のOracleインスタンス(ASINST)に作成されます。

OIDコンポーネントについて、デフォルトのインスタンス固有の構成エントリoid1が次のように作成されます。

cn=oid1,cn=osdldapd,cn=subconfigsubentry

次の両方のシナリオで、このデフォルトのoid1構成エントリが作成されます。

- 「インストールと構成」オプションを使用して、インストーラを実行します。

- 「ソフトウェアのインストール - 構成なし」オプションを使用してインストーラを実行し、後ほど構成ウィザード(config.shまたはconfig.batスクリプト)を実行してOIDコンポーネントを構成します。

Oracle Internet Directoryコンポーネントには、OIDMONプロセスとOracle Internet Directoryインスタンス(inst=1)が含まれています。インストール中にインスタンス名が選択されます。通常はasinst_1です。Oracle Internet Directoryインスタンスは、1つのディスパッチャ・プロセスと1つ以上のOIDLDAPDプロセスで構成されます。

Oracle Internet Directory 11g リリース1(11.1.1.7.0)以降、OIDLDAPDプロセスはOIDDISPD(ディスパッチャ)プロセスとOIDLDAPD(サーバー)プロセスに分割されます。ただしUNIXシステムおよびLinuxシステムでは、これらのプロセスはともに、実行時にps -efコマンドにより引き続きOIDLDAPDとして表示されます。

また、Oracle Identity Management 11gインストーラは、Oracleインスタンス・ディレクトリの下にいくつかのファイル・システム・ディレクトリを作成します。作成されるパス名の一部は、コンポーネント名に固有のものとなります。たとえば、UNIXまたはLinux上のOracleインスタンス下のパス名は次のようになります。

ORACLE_INSTANCE/config/OID/oid1
ORACLE_INSTANCE/diagnostics/logs/OID/oid1

インストール時に「新規ドメインの作成」または「既存のドメインの拡張」を選択した場合、Oracle Internet DirectoryコンポーネントはWebLogicドメインに登録されます。インストール時に「ドメインなしで構成」を選択した場合、Oracle Internet Directoryコンポーネントはドメインに登録されません。後でコマンド行から登録できます。この場合、ドメインへの登録はオプションです。

注意:
Oracle Internet Directoryは、異なるホスト上のインスタンスがすべて同じOracle Databaseに接続されているクラスタに構成されることがよくあります。Oracle Identity Management 11gインストーラは、他のOIDコンポーネントが同じOracle Databaseを使用していることを検出し、新しいコンポーネントのコンポーネント名を1増分します。つまり、クラスタ内に連続してインストールすると、コンポーネント名はoid2、oid3のようになります。

8.1.3 Oracle Internet Directoryインスタンスの追加作成

別のOracle Internet Directoryインスタンスを追加する方法としては、Type=OIDの追加のシステム・コンポーネントをOracleインスタンス内に追加することをお薦めします。

そのためには、opmnctl createcomponentを使用して、コンポーネント・タイプType=OID、新規コンポーネントのコンポーネント名、およびOracleインスタンスのインスタンス名を指定します。この新しいOracle Internet Directoryコンポーネントは、OIDMONプロセス、OIDLDAPDディスパッチャ・プロセスおよび1つ以上のOIDLDAPDサーバー・プロセスで構成されます。たとえば、図8-2の下部のias_component=oid2を見てください。

図8-2 Oracle Internet Directoryのプロセス制御

OPMNコマンドのopmnctl createcomponentを使用して、DIT内にインスタンス固有の構成エントリを新規に作成します。新しいコンポーネント名がoid2の場合、新規エントリは次のようになります。

cn=oid2,cn=osdldapd,cn=subconfigsubentry

このエントリ内の値を変更してインスタンスをカスタマイズできます。

opmnctlコマンドでは、ORACLE_INSTANCEディレクトリ下のファイル・システムにOracleインスタンスasinst_1の追加のパス名も作成されます。新しいコンポーネント名がoid2の場合、パス名は次のようなものになります。

ORACLE_INSTANCE/config/OID/oid2
ORACLE_INSTANCE/diagnostics/logs/OID/oid2

opmnctlプロセス制御コマンドを使用して、コンポーネントoid1とoid2を個々に管理できます。新規Oracle Internet DirectoryインスタンスのWebLogicドメインへの登録は、作成時に行うことも作成後に行うこともできます。

注意:
WebLogicドメインの一部としてではなく、スタンドアロン・サーバーとしてOracle Internet Directoryが稼働している場合、oidctlを使用してインスタンスを作成できます。oidctlを使用してインスタンスを作成した場合、oidctlを使用してそのインスタンスを停止および起動する必要があります。oidctlを使用して作成したOracle Internet Directoryインスタンスは、WebLogicサーバーに登録できないため、Oracle Enterprise Manager Fusion Middleware Controlを使用してインスタンスを管理できません。付録B「OIDCTLを使用したOracle Internet Directoryインスタンスの管理」を参照してください。

関連項目:

- OPMNおよびopmnctlコマンドの詳細は、『Oracle Fusion Middleware Oracle Process Manager and Notification Server管理者ガイド』を参照してください。

- Oracle Internet Directoryプロセスの詳細は、第4章「Oracle Internet Directoryコンポーネントのプロセス制御の理解」を参照してください。

8.1.4 OracleインスタンスまたはコンポーネントのWebLogic Serverへの登録

Oracle Internet DirectoryコンポーネントをOracle Enterprise Manager Fusion Middleware Controlに登録する場合、コンポーネントとこれを含むOracleインスタンスWebLogicドメインに登録する必要があります。OracleインスタンスのWebLogicドメインへの登録は、インストール時またはOracleインスタンスの作成時に行えますが、必ずそうする必要はありません。OracleがWebLogicドメインに以前に登録されていない場合、opmnctl registerinstanceを使用して登録できます。

Oracleインスタンスがすでに登録されている場合、新規Oracle Internet Directoryシステム・コンポーネントをOracleインスタンスに追加すると、opmnctlでそのOracleインスタンスの一部としてコンポーネントが自動的に登録されます。

登録されているコンポーネントの構成を変更した場合、opmnctl updatecomponentregistrationを実行して情報を更新する必要があります。「opmnctlを使用したOracle Internet Directoryコンポーネントの管理」を参照してください。

関連項目:
「WebLogic Serverドメイン」

8.2 Fusion Middleware Controlを使用したOracle Internet Directoryコンポーネントの管理

Oracle Internet Directoryコンポーネントは、Oracle Enterprise Manager Fusion Middleware Controlを使用して表示、停止および起動できます。この項の内容は次のとおりです。

- 第8.2.1項「Fusion Middleware Controlを使用したアクティブ・サーバーの情報の表示」

- 第8.2.2項「Fusion Middleware Controlを使用したOracle Internet Directoryサーバーの起動」

- 第8.2.3項「Fusion Middleware Controlを使用したOracle Internet Directoryサーバーの停止」

- 第8.2.4項「Fusion Middleware Controlを使用したOracle Internet Directoryサーバーの再起動」

8.2.1 Fusion Middleware Controlを使用したアクティブ・サーバーの情報の表示

Oracle Internet Directoryコンポーネントの情報(タイプ、デバッグ・レベル、ホスト名、構成パラメータなど)を表示するには、Oracle Enterprise Manager Fusion Middleware Controlを使用します。この手順は、次のとおりです。

1. 第7.3項「Fusion Middleware Controlを使用したOracle Internet Directoryの管理」の説明に従って、Oracle Enterprise Manager Fusion Middleware Controlに接続します。

2. ドメインのホームページに、Oracle Internet Directoryを含むコンポーネントのステータスが表示されます。

3. 表示するOracle Internet Directoryコンポーネントを選択します。

4. Oracle Internet Directoryホームページでステータス情報を確認します。

8.2.2 Fusion Middleware Controlを使用したOracle Internet Directoryサーバーの起動

Oracle Internet Directoryは次のように起動します。

1. Oracle Enterprise Manager Fusion Middleware ControlのOracle Internet Directoryのホームページに移動します。

2. 「Oracle Internet Directory」メニューから、「制御」、「起動」の順に選択します。

3. 確認ダイアログが表示された後、「OK」をクリックします。

Fusion Middleware Controlでサーバーを起動できない場合は、エラー・ダイアログが表示されます。

8.2.3 Fusion Middleware Controlを使用したOracle Internet Directoryサーバーの停止

Oracle Internet Directoryは次のように停止します。

1. Oracle Enterprise Manager Fusion Middleware ControlのOracle Internet Directoryのホームページに移動します。

2. 「Oracle Internet Directory」メニューから、「制御」、「停止」の順に選択します。

3. 確認ダイアログが表示された後、「OK」をクリックします。

Fusion Middleware Controlでサーバーを停止できない場合は、エラー・ダイアログが表示されます。

8.2.4 Fusion Middleware Controlを使用したOracle Internet Directoryサーバーの再起動

Oracle Internet Directoryは次のように再起動します。

1. Oracle Enterprise Manager Fusion Middleware ControlのOracle Internet Directoryのホームページに移動します。

2. 「Oracle Internet Directory」メニューから、「制御」、「再起動」の順に選択します。

3. 確認ダイアログが表示された後、「OK」をクリックします。

Fusion Middleware Controlでサーバーを再起動できない場合は、エラー・ダイアログが表示されます。

8.3 opmnctlを使用したOracle Internet Directoryコンポーネントの管理

opmnctlを使用して次のOracle Internet Directory関連のタスクをコマンド行から行えます。

- 第8.3.1項「opmnctlを使用したOracle Internet Directoryコンポーネントの作成」

- 第8.3.2項「opmnctlを使用したOracleインスタンスの登録」

- 第8.3.3項「opmnctlを使用したOracleインスタンスの登録解除」

- 第8.3.4項「opmnctlを使用したOracleインスタンスのコンポーネント登録の更新」

- 第8.3.5項「opmnctlを使用したOracle Internet Directoryコンポーネントの削除」

- 第8.3.6項「opmnctlを使用したアクティブ・サーバー・インスタンスの情報の表示」

- 第8.3.7項「opmnctlを使用したOracle Internet Directoryサーバーの起動」

- 第8.3.8項「opmnctlを使用したOracle Internet Directoryサーバーの停止」

- 第8.3.9項「opmnctlを使用したOracle Internet Directoryサーバーの再起動」

- 第8.3.10項「opmn.xmlのOracle Database情報の変更」

注意:
opmnctlの引数は、大/小文字を区別します。示されているとおりに正確に文字列を入力してください。たとえば、createcomponentはすべて小文字である必要があり、-adminUsernameは文字Uのみが大文字である必要があります。
opmnctlコマンドのオプションの詳細は、次のように入力して確認します。

ORACLE_INSTANCE/bin/opmnctl usage command

次に例を示します。

$ORACLE_INSTANCE/bin/opmnctl usage createcomponent

関連項目:

- この例で使用するコマンド構文の詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のOracle Internet Directory管理ツールに関する説明を参照してください。

- opmnctl createinstanceなどのopmnctlの詳細は、『Oracle Fusion Middleware Oracle Process Manager and Notification Server管理者ガイド』を参照してください。

8.3.1 opmnctlを使用したOracle Internet Directoryコンポーネントの作成

Oracle Internet Directoryシステム・コンポーネントは、opmnctl createcomponentを使用してOracleインスタンスに作成できます。このコマンドでは、インスタンスが登録済状態の場合、コンポーネントの作成時にコンポーネントがWebLogicドメインに自動的に登録されます。構文は次のとおりです。

ORACLE_INSTANCE/bin/opmnctl createcomponent
-componentType OID
-componentName componentName
-adminHost webLogicHostName
-adminPort webLogicPort
[-adminUsername weblogicAdminUsername]
[-adminPasswordFile text_file_containing_admin_password]
-Db_info "DBHostName:Port:DBSvcName"
[-Ods_Password_File 'File_with_DB_ODS_USER_PASSWORD']
[-Sm_Password_File 'File_with_DB_ODSSM_USER_PASSWD']
[-Admin_Password_File 'File_with_OID_Admin_Passwd']
-Namespace "dc=domain_component1,dc=domain_component2..."
[-Port nonSSLPort]
[-Sport SSLPort]

-DB_infoパラメータに対するDBHostName:Port:DBSvcName引数は、インストール時に指定される引数と同じである必要があります。そうでない場合、コマンドは失敗します。この値は、ファイルORACLE_INSTANCE/config/tnsnames_copy.oraにあります。

Oracle DatabaseがReal Application Clustersに基づいている場合、-DB_infoパラメータに対する引数は次の形式となります。

DBHostName1:Port1^DBHostName2:Port2@DBSvcName

opmnctlコマンドでは、WebLogic管理者ユーザー名を指定しない場合、そのユーザー名の入力を求められます。コマンド行にパスワード・ファイル名を指定しない場合、パスワードの入力も求められます。第3.1.3項「Oracle Internet Directoryのポート」で説明されているように、opmnctlコマンドでは、-Portまたは-Sportを指定しない場合には使用可能なポートも使用されます。

8.3.2 opmnctlを使用したOracleインスタンスの登録

Oracle Internet Directoryのインストール時、Oracle Identity Management 11gインストーラはドメイン情報を要求します。「ドメインなしで構成」を選択すると、Oracle Internet DirectoryインスタンスはWebLogicドメインに登録されません。インストールの完了後、opmnctl registerinstanceを使用してOracleインスタンスとそのOracleインスタンス内のすべてのコンポーネントを登録するよう選択できます。構文は次のとおりです。

ORACLE_INSTANCE/bin/opmnctl registerinstance
-adminHost hostname
-adminPort weblogic_port
-adminUsername weblogic_admin_username

WebLogic管理者のユーザー名とパスワードが要求されます。

次に例を示します。

ORACLE_INSTANCE/bin/opmnctl registerinstance \
-adminHost myhost \
-adminPort 7001 \
-adminUsername weblogic \

WebLogic管理サーバーのデフォルトの管理ポートは7001です。

8.3.3 opmnctlを使用したOracleインスタンスの登録解除

インストール時にOracleインスタンスをWebLogicドメインに登録した場合、インストールの完了後、これを登録解除できます。Oracle Internet Directoryをスタンドアロン・モードで使用する場合、これを行います。(スタンドアロン・モードでは、Oracle Internet Directoryの管理にFusion Middleware Controlまたはwlstを使用できません。)

OracleインスタンスとそのOracleインスタンス内のすべてのコンポーネントの登録を解除するには、opmnctl unregisterinstanceを使用します。構文は次のとおりです。

ORACLE_INSTANCE/bin/opmnctl unregisterinstance
-adminHost hostname
-adminPort weblogic_port
-adminUsername weblogic_admin

WebLogic管理者のユーザー名とパスワードを指定しないと、入力を要求されます。

次に例を示します。

$ORACLE_INSTANCE/bin/opmnctl unregisterinstance \
-adminHost myhost \
-adminPort 7001 \
-adminUsername weblogic \

WebLogic管理サーバーのデフォルトの管理ポートは7001です。

8.3.4 opmnctlを使用したOracleインスタンスのコンポーネント登録の更新

表8-1に示す構成属性を変更した場合、登録済OracleインスタンスのOracle Internet Directoryコンポーネントの登録を更新する必要があります。コンポーネント登録を更新しないと、Fusion Middleware Controlまたはwlstを使用してコンポーネントを管理できません。

表8-1 コンポーネント登録の更新が必要な属性変更

属性

関連項目

orclhostname

第9.1.3項「インスタンス固有の構成エントリの属性」

orclnonsslport

第9.1.3項「インスタンス固有の構成エントリの属性」

orclsslport

第9.1.3項「インスタンス固有の構成エントリの属性」

userpassword

第12.10項「EMD管理者アカウントのパスワードの変更」

Oracle Internet Directoryコンポーネントの登録を更新するには、opmnctl updatecomponentregistrationを使用します。構文は次のとおりです。

ORACLE_INSTANCE/bin/opmnctl updatecomponentregistration
-adminHost hostname
-adminPort weblogic_port
-adminUsername weblogic_admin
-componentType OID
-componentName compName
-Port non-sslport
-Sport sslport

次に例を示します。

$ORACLE_INSTANCE/bin/opmnctl updatecomponentregistration \
-adminHost myhost \
-adminPort 7001 \
-adminUsername weblogic \
-componentType OID  \
-componentName oid2 \
-Port 3061 \
-Sport 3131

WebLogic管理者のユーザー名とパスワードを指定しないと、入力を要求されます。

WebLogic管理サーバーのデフォルトの管理ポートは7001です。

非SSLポートとSSLポートの両方を指定する必要があります。

8.3.5 opmnctlを使用したOracle Internet Directoryコンポーネントの削除

Oracle Internet Directoryコンポーネントを削除するには、opmnctl deletecomponentを使用します。これによって、コンポーネントのWebLogicサーバーでの登録も解除されます。構文は次のとおりです。

$ORACLE_INSTANCE/bin/opmnctl deletecomponent
-adminHost webLogicHostName
-adminPort webLogicPort
-adminUsername weblogicAdminUsername
-adminPasswordFile text_file_containing_admin_password
-componentType OID
-componentName componentName

WebLogic管理者のユーザー名とパスワードを指定しないと、入力を要求されます。

8.3.6 opmnctlを使用したアクティブ・サーバー・インスタンスの情報の表示

opmnctlを使用してコンポーネントおよびプロセスのステータスを表示するには、次のように入力します。

opmnctl status -l

次に例を示します。

$ ./opmnctl status -l

Processes in Instance: asinst_2
---------------------------------+--------------------+---------+----------+------------+----------+-----------+------
ias-component                    | process-type       |     pid | status   |        uid |  memused |    uptime | ports---------------------------------+--------------------+---------+----------+------------+----------+-----------+------
oid2                             | oidldapd           |   24760 | Alive    |  988238800 |   102744 |   0:01:12 | N/A
oid2                             | oidldapd           |   24756 | Alive    |  988238799 |    55052 |   0:01:12 | N/A
oid2                             | oidmon             |   24745 | Alive    |  988238796 |    48168 |   0:01:14 | LDAPS:6789,LDAP:6788

oid1                             | oidldapd           |   21590 | Alive    |  988238048 |   103716 |  19:51:48 | N/A
oid1                             | oidldapd           |   21586 | Alive    |  988238047 |    54420 |  19:51:49 | N/A
oid1                             | oidmon             |   21577 | Alive    |  988238046 |    48168 |  19:51:49 | LDAPS:3133,LDAP:3060

8.3.7 opmnctlを使用したOracle Internet Directoryサーバーの起動

最初のOracle Internet Directoryコンポーネントのコンポーネント名はoid1です。

最初のOracle Internet Directoryインスタンスを起動するには、次のように入力します。

opmnctl startproc ias-component=oid1

すべてのOracle Internet Directoryインスタンスを起動するには、次のように入力します。

opmnctl startproc process-type=OID

すべてのコンポーネントを起動するには、次のように入力します。

opmnctl startall

8.3.8 opmnctlを使用したOracle Internet Directoryサーバーの停止

最初のOracle Internet Directoryサーバー・コンポーネントを停止するには、次のように入力します。

opmnctl stopproc ias-component=oid1

すべてのOracle Internet Directoryインスタンスを停止するには、次のように入力します。

opmnctl stopproc process-type=OID

すべてのコンポーネントを停止するには、次のように入力します。

opmnctl stopall

8.3.9 opmnctlを使用したOracle Internet Directoryサーバーの再起動

最初のOracle Internet Directoryインスタンスを再起動するには、次のように入力します。

opmnctl restartproc ias-component=oid1

すべてのOracle Internet Directoryインスタンスを再起動するには、次のように入力します。

opmnctl restartproc process-type=OID

8.3.10 opmn.xmlのOracle Database情報の変更

デフォルトでは、ORACLE_INSTANCE/config/OPMN/opmn/opmn.xmlには、デフォルトのOracle Internet Directory LDAPサーバー・インスタンスを起動するときにopmnctlが使用するXMLスニペットが含まれています。場合によっては、このopmn.xmlファイルの編集が必要になることもあります。たとえば、ORACLE_INSTANCE/config/tnsnames.oraでOracle Databaseインスタンスを変更した場合、Oracle Database DB_CONNECT_STRをORACLE_INSTANCE/config/OPMN/opmn/opmn.xmlに追加する必要があります。テキスト・エディタを使用するとopmn.xmlを編集できます。

関連項目:
第4.3.1項「opmn.xmlのOracle Internet Directoryスニペット」

8.4 OIDCTLを使用したレプリケーション・サーバーのインスタンスの起動

Oracle Internet Directoryレプリケーション・サーバーのインスタンスを構成するには、server=oidrepldを指定してoidctl startコマンドを使用します。ベスト・プラクティスは、レプリケーション用にOracle Internet Directoryのインスタンスを別途作成することです。

最初に、第8.1.3項「Oracle Internet Directoryインスタンスの追加作成」の説明に従って、Oracle Internet Directoryの新しいインスタンスを作成します。次に、環境変数ORACLE_INSTANCEが設定されていることを確認し、次を入力します。

oidctl connect=connStr server=oidrepld inst=1 componentname=Component_Name \
name=Instance_Name start

componentname値は、稼働しているoidldapdサーバーのコンポーネント名です。name値は、稼働しているoidldapdサーバーのインスタンス名です。

ホストでoidrepldのインスタンスを複数起動しないでください。同じOracle Databaseを共有する複数のOracle Internet Directoryインスタンスでoidrepldを起動しないでください。

注意:
oidctlコマンドを実行してレプリケーション・サーバーを起動または停止する前に、環境変数ORACLE_INSTANCE、ORACLE_HOMEおよびCOMPONENT_NAMEを設定する必要があります。

関連項目:

- 第6章「Oracle Internet Directoryレプリケーションの理解」

- 第40章「レプリケーションの設定」

8.5 レプリケーション・サーバーの起動と停止の方法について

Oracle Internet Directoryでレプリケーション・サーバーを起動および停止する方法には、oidctlとOracle Enterprise Manager Fusion Middleware Controlの2つがあります。

oidctlを使用してレプリケーション・サーバーを起動する場合は、インスタンスの値を自然数にする必要があります。つまりinstance=nで、n>=1です。oidctlを使用してinstance=0でレプリケーションを開始することはできません。

instance=0はOracle Enterprise Manager Fusion Middleware Control専用です。したがって、Oracle Enterprise Manager Fusion Middleware Controlのみがinstance=0でレプリケーションを開始できます。また、Oracle Enterprise Manager Fusion Middleware Controlは0以外のインスタンスでレプリケーションを開始/停止できません。

oidctlを使用してレプリケーション・サーバーを起動する場合、停止にもoidctlを使用する必要があります。Oracle Enterprise Manager Fusion Middleware Controlを使用してこれを停止しようとすると、失敗します。同様に、Oracle Enterprise Manager Fusion Middleware Controlを使用してレプリケーション・サーバーを起動した場合は、Oracle Enterprise Manager Fusion Middleware Controlを使用してレプリケーション・サーバーを停止する必要があります。

oidctlコマンドライン・ユーティリティとOracle Enterprise Manager Fusion Middleware Controlコンソールが独立したクライアントとして機能してレプリケーション・サーバーを制御します。一方のツールでもう一方が起動したレプリケーション・サーバーを起動/停止することはできません。

9 システム構成属性の管理

この章では、Oracle Internet Directory LDAPサーバーを制御する構成属性について説明し、それらの属性をOracle Enterprise Manager Fusion Middleware Control、WebLogic Scripting Tool (wlst)、LDAPツールおよびOracle Directory Services Manager (ODSM)を使用して管理する方法について説明します。

Oracle Internet Directoryレプリケーション・サーバーを制御する属性の詳細は、第42章「レプリケーション構成属性の管理」を参照してください。

この章の内容は次のとおりです。

- 第9.1項「システム構成属性の管理の概要」

- 第9.2項「Fusion Middleware Controlを使用したシステム構成属性の管理」

- 第9.3項「WLSTを使用したシステム構成属性の管理」

- 第9.4項「LDAPツールを使用したシステム構成属性の管理」

- 第9.5項「ODSMデータ・ブラウザを使用したシステム構成属性の管理」

関連項目:
第3.4.1項「属性情報の種類」

9.1 システム構成属性の管理の概要

この概要の項目は次のとおりです。

- 第9.1.1項「構成属性とは」

- 第9.1.2項「操作属性とは」

- 第9.1.3項「インスタンス固有の構成エントリの属性」

- 第9.1.4項「DSA構成エントリの属性」

- 第9.1.5項「DSEの属性」

9.1.1 構成属性とは

大部分のOracle Internet Directory構成情報は、ディレクトリ自体に格納されます。情報は、特定の構成エントリの属性として格納されます。システム構成属性を設定するには、スーパーユーザー権限を持っている必要があります。

一部の構成属性は、Oracle Internet Directoryサーバーの個々のインスタンスに固有の属性です。インスタンス固有の属性は、Oracle Internet Directoryインスタンス・エントリの特定のサブエントリである、インスタンス固有の構成エントリにあります。図8-1「2つのインスタンス固有の構成エントリを示すDIT」は、これらのエントリのDIT内の位置を示しています。

一部の構成属性は、同じデータベースに接続される、WebLogicサーバー・ドメイン内のすべてのOracle Internet Directoryサーバー・インスタンスによって共有されます。共有属性はDSA構成エントリにあります。レプリケーション固有の属性は、レプリカ・サブエントリ、レプリケーション構成エントリおよびレプリケーション承諾エントリにあります。

一部の属性はDSEルートにあります。これらの属性のほとんどは構成できません。

関連項目:
第4章「Oracle Internet Directoryコンポーネントのプロセス制御の理解」

注意:
Oracle Internet Directory構成属性(インスタンス固有属性または共有属性のいずれか)は、レプリケートされません。たとえば、OrclComputedAttributeからの計算属性定義は、DSA構成エントリに格納されます。レプリケートはされません。デプロイメントで構成属性のレプリケートが必要な場合、手動でレプリケートする必要があります。

すべての構成属性はコマンド行から管理できます。また、構成属性の多くは、Oracle Enterprise Manager Fusion Middleware ControlまたはOracle Directory Services Managerに特定のタスク指向の管理インタフェースを持っています。Oracle Directory Services Managerのデータ・ブラウザ機能を使用してエントリを直接管理することもできます。

関連項目:

- 第9.2項「Fusion Middleware Controlを使用したシステム構成属性の管理」

- 第9.4項「LDAPツールを使用したシステム構成属性の管理」

- 第9.5項「ODSMデータ・ブラウザを使用したシステム構成属性の管理」

9.1.2 操作属性とは

構成属性を操作属性と混同しないようにしてください。操作属性はディレクトリ・サーバーにとって特別な意味があり、サーバー自体で処理を行ったり、サーバーで管理されている(クライアントから明示的に提供されることのない)その他のデータを保持するために必要な情報を格納する場合に使用されます。これらはサーバーによって管理される属性であり、エントリについてサーバーが管理する情報を反映したり、サーバー操作に影響を与えます。

操作属性は、検索リクエストで名前を指定するか、または+オプションを使用して具体的にリクエストしないかぎり、検索操作によって返されることはありません。詳細は、第13.3.2項「ldapsearchを使用した操作属性のリスト」を参照してください。

操作属性の例として、第29.1.6項「パスワード・ポリシー関連の操作属性」で説明されているように、エントリのタイムスタンプ、パスワード・ポリシーの適用に必要な状態の値などがあります。操作属性は変更できません。

リリース11.1.1.9.0以降では、Oracle Internet Directoryサーバーによって、numsubordinate操作属性が返されます。これは、特定のベース識別名の子エントリの数を指定します。

注意:
デフォルトでは、numsubordinate操作属性は、検索リクエストに+オプションを指定したときに返されません。cn=dsaconfig,cn=configsets,cn=oracle internet directoryエントリで、orcldseecompatibleフラグを明示的に1に設定する必要があります。

9.1.3 インスタンス固有の構成エントリの属性

インストール時、Oracle Identity Management 11gインストーラにより、最初のOracle Internet Directoryインスタンスに対してインスタンス固有の構成エントリが作成されます。cn=configset0の下にある読取り専用エントリからデフォルト値がコピーされます。(インストール時に、SSLポートと非SSLに対して異なる値を指定できます。)

インスタンス固有の構成エントリの識別名の形式は次のとおりです。

cn=componentname,cn=osdldapd,cn=subconfigsubentry

たとえば、サーバー・インスタンスのコンポーネント名がoid1の場合、インスタンス固有の構成エントリのDITは次のようになります。

cn=oid1,cn=osdldapd,cn=subconfigsubentry

表9-1に、インスタンス固有の構成エントリの属性を示します。更新メカニズムの列には、次の略称が含まれています。

- EM - Oracle Enterprise Manager Fusion Middleware Control。第9.2項「Fusion Middleware Controlを使用したシステム構成属性の管理」を参照してください。

- WLST–WebLogic Scripting tool。第9.3項「WLSTを使用したシステム構成属性の管理」を参照してください。

- LDAP - LDAPコマンド行ツール(ldapmodifyやldapaddなど)。第9.4項「LDAPツールを使用したシステム構成属性の管理」を参照してください。

表9-1 インスタンス固有の構成エントリの属性

属性

説明

更新メカニズム

デフォルト

使用可能な値

orclmaxpsearchconns

LDAP永続検索操作に許可される最大接続数。

「永続LDAP検索操作」を参照してください。

EM、LDAP、WLST

0

1024までの整数。

orclserverprocs

サーバー・プロセスの数

変更した後、サーバーを再起動します。

第4章を参照してください。

EM、LDAP、WLST

1

1024までの整数。

orclreqattrcase

ldapsearchリクエストで指定された必須属性名の大/小文字を保持します。

第7章を参照してください。

EM、LDAP

0

0: 属性の大/小文字は保持されません

1: 属性の大/小文字を保持します

orclhostname

ホスト名またはIPアドレス。

第10章を参照してください。

ホスト名を変更する場合は、opmnctl updatecomponentregistrationを実行してサーバーを再起動します。第8章「Oracle Internet Directoryインスタンスの管理」を参照してください。

LDAP

インストール時に設定

ホストまたはIPアドレス

orclnonsslport

非SSLポート

第9.2.1項「サーバー・プロパティの構成」を参照してください。ポート番号を変更する場合は、サーバーを再起動し、opmnctl updatecomponentregistrationを実行します。第8章「Oracle Internet Directoryインスタンスの管理」を参照してください。

EM、LDAP、WLST

3060

ポート番号

orclsslport

SSLポート

第9.2.1項「サーバー・プロパティの構成」を参照してください。ポート番号を変更する場合は、サーバーを再起動し、opmnctl updatecomponentregistrationを実行します。第8章「Oracle Internet Directoryインスタンスの管理」を参照してください。

EM、LDAP、WLST

3131

ポート番号

orcltraceconndn

orclDebugFlagがゼロ(0)以外の値に設定されている場合に、指定された接続DNによって実行される操作のメッセージをOracle Internet Directoryサーバーに記録させる接続の識別名(DN)。

EM、LDAP、WLST

なし

1つ以上の接続DNを指定できる複数値属性。

orcltraceconnip

orclDebugFlagがゼロ(0)以外の値に設定されている場合に、指定された接続IPアドレスによって実行される操作のメッセージをOracle Internet Directoryサーバーに記録させる接続IPアドレス。

EM、LDAP、WLST

なし

1つ以上の接続IPアドレスを指定できる複数値属性。

orcltxntimelimit

1つのトランザクションで許容される最大時間(秒)。『Oracle Fusion Middleware Oracle Identity Managementアプリケーション開発者ガイド』のLDAPトランザクションの使用に関する説明、および第9.2.1項「サーバー・プロパティの構成」を参照してください。

EM、LDAP、WLST

0

正の整数(秒)

orcltxnmaxoperations

1つのトランザクションで許容される操作の最大数。『Oracle Fusion Middleware Oracle Identity Managementアプリケーション開発者ガイド』のLDAPトランザクションの使用に関する説明、および第9.2.1項「サーバー・プロパティの構成」を参照してください。

EM、LDAP、WLST

0

正の整数

orclservermode

サーバー・モード

第15章を参照してください。

EM、LDAP、WLST

rw

R: 読取り専用

rw: 読取り/書込み

rm: 読取り/更新

orclaudcustevents

監査されるイベント名とカテゴリ名のカンマ区切りのリスト。カスタム・イベントは、orclAudFilterPresetがCustomの場合のみ適用できます。第23章を参照してください。

EM、LDAP、WLST

空

次に例を示します。

Authentication.SUCCESSESONLY,
Authorization(Permission -eq 'CSFPermission')

orclaudfilterpreset

10g(10.1.4.0.1)以前のリリースで使用されていた監査レベルを置き換えます。第23章を参照してください。

EM、LDAP、WLST

なし

None、Low、Medium、AllおよびCustom。

orclaudsplusers

orclAudFilterPresetがNoneの場合でも、監査が常に有効化されるユーザーのカンマで区切られたリスト。第23章を参照してください。

EM、LDAP、WLST

空

有効なユーザー。次に例を示します。

cn=orcladmin

orclcachenotifyip

キャッシュされたデータが変更されたときに、クラスタ環境でOracle Internet Directoryサーバーが相互に通信できるように、IPアドレスにポート番号を関連付けます。

LDAP

なし

ポート番号およびIPアドレス

第10.3項「クラスタ内通知用のIPアドレスの構成」を参照してください。

orcldebugflag

デバッグ・フラグ

第24章を参照してください。

EM、LDAP、WLST

0

0 ~ 117440511

表24-3を参照してください。

orcldebugforceflush

強制フラッシュ・デバッグ・メッセージ

第24章を参照してください。

LDAP

0

0: 無効

1: 有効

orcldebugop

デバッグ操作の有効化

第24章を参照してください。

EM、LDAP、WLST

511

表24-4「orcldebugop属性を設定するためのデバッグ操作」を参照してください。

orclmaxlogfiles

ローテーション状態を保つログ・ファイルの最大数

第24章を参照してください。

EM、LDAP、WLST

100

整数

orclmaxlogfilesize

最大ログ・ファイル・サイズ(MB)

第24章を参照してください。

EM、LDAP、WLST

1MB

サイズ(MB)

orcleventlevel

統計収集のイベント・レベル

第25章を参照してください。

EM、LDAP、WLST

0

表25-5「イベント・レベル」を参照してください。

orcloptracklevel

セキュリティ・イベント追跡レベル

第25章を参照してください。

EM、LDAP、WLST

0

表25-3「orcloptracklevelの値」

orclstatsflag

OID統計データをオンまたはオフにするフラグ

第25章を参照してください。

EM、LDAP、WLST

1

0: 無効

1: 有効

orclstatslevel

ユーザー統計収集の有効化

第25章を参照してください。

EM、LDAP、WLST

0

0: 無効

1: 有効

orclstatsperiodicity

統計をデータベースにフラッシュする頻度

第25章を参照してください。

EM、LDAP、WLST

30

60

orclsslauthentication

SSL認証

変更した後、サーバーを再起動します。

第27章を参照してください。

EM、LDAP、WLST

1

1: SSL認証なし

32: 一方向認証

64: 双方向認証

orclsslciphersuite

SSL暗号スイート

変更した後、サーバーを再起動します。

第27章を参照してください。

EM、LDAP、WLST

空

表27-1「Oracle Internet DirectoryでサポートされるSSL暗号スイート」の左列を参照してください。

orclsslenable

SSL有効化

変更した後、サーバーを再起動します。WLSTまたはEMを使用してサーバーを構成する場合、orclsslenableを1または2に設定します。

第27章を参照してください。

EM、LDAP、WLST

2

0: 非SSLのみ

1: SSLのみ

2: 非SSLおよびSSLモード

orclsslinteropmode

SSL相互運用性モード

変更した後、サーバーを再起動します。

第27章を参照してください。

LDAP

0

0: 無効

1: 有効

orclsslversion

SSLバージョン

変更した後、サーバーを再起動します。

第27章を参照してください。

EM、LDAP、WLST

3

3

orclsslwalleturl

SSLウォレットURL

変更した後、サーバーを再起動します。

第27章を参照してください。

EM、LDAP、WLST

ファイル

SSLウォレット・ファイルの場所。

orclanonymousbindsflag

匿名ユーザーによるバインドを許可

第33章を参照してください。

EM、LDAP、WLST

2

表33-4「orclanonymousbindsflagの値とディレクトリ・サーバーの動作」を参照してください。

orclsaslauthenticationmode

SASL認証

モードを変更した後、サーバーを再起動します。

第33章を参照してください。

EM、LDAP、WLST

1

auth、auth-int、auth-conf。3つとも、あるいは3つのサブセットをカンマ区切りの文字列で指定します。

orclsaslcipherchoice

SASL暗号選択

変更した後、サーバーを再起動します。

第33章を参照してください。

EM、LDAP、WLST

Rc4-56、rc4-40、rc4、des、3des

Rc4-56、des、3des、rc4、rc4-40の任意の組合せ

orclsaslmechanism

SASLメカニズム

変更した後、サーバーを再起動します。

第33章を参照してください。

EM、LDAP、WLST

DIGEST-MD5、EXTERNAL

DIGEST-MD5、EXTERNAL

orclmaskrealm

DITマスキング

第39章を参照してください。

LDAP

値なし

DITサブツリーのリスト

orclmaskfilter

DITマスキング

第39章を参照してください。

LDAP

値なし

LDAP属性フィルタ

orclmaskattribute

DITマスキング

第39章を参照してください。

LDAP

値なし

属性のリスト(先頭に!が付く可能性あり)

orcldispthreads

1サーバー・プロセス当たりのディスパッチャ・スレッドの最大数

『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』の「Oracle Internet Directory」の章を参照

変更した後、サーバーを再起動します。

EM、LDAP、WLST

1

整数(最大16)

orclldapconntimeout

LDAP接続タイムアウト(分単位)

『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』の「Oracle Internet Directory」の章を参照してください。

EM、LDAP、WLST

0

整数

注意: 統計追跡用に構成されているユーザーはこの設定に従ってタイムアウトしません。

orclmaxcc

DB接続の最大数

変更した後、サーバーを再起動します。

『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』の「Oracle Internet Directory」の章を参照してください。

EM、LDAP、WLST

2

128までの整数

orclmaxconnincache

キャッシュされたユーザー・グループ接続の最大数

『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』の「Oracle Internet Directory」の章を参照してください。

EM、LDAP、WLST

100000

整数

orclmaxldapconns

1サーバー・プロセス当たりの同時接続の最大数

『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』の「Oracle Internet Directory」の章を参照してください。

EM、LDAP、WLST

1024

Int(プロセス当たりの最大システムの最大ファイル記述子)

orclmaxserverresptime

サーバー・プロセスがディスパッチャ・プロセスに応答する最大時間(秒)

『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』の「Oracle Internet Directory」の章を参照してください。

EM、LDAP、WLST

300秒

秒数

0: ディスパッチャはサーバーのハングを検出しません。

orclnwrwtimeout

LDAPクライアントによる読取り/書込み操作への応答に対するOIDサーバーの最大待機時間(秒)。

『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』の「Oracle Internet Directory」の章を参照してください。

EM、LDAP、WLST

30秒

整数

orcloptrackmaxtotalsize

セキュリティ・イベント追跡で各タイプの操作に使用できるRAMの最大バイト数。

『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』の「Oracle Internet Directory」の章を参照してください。

LDAP

100000000バイト

使用可能なRAM(バイト)

orcloptracknumelemcontainers;1stlevel

操作を行っているユーザーに関する情報を格納するインメモリー・キャッシュ・コンテナの数。

『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』の「Oracle Internet Directory」の章を参照してください。

LDAP

256

整数

orcloptracknumelemcontainers;2ndlevel

詳細比較操作統計がプログラムされている場合に、パスワードを比較および追跡する対象のユーザーに関する情報を格納するインメモリー・キャッシュ・コンテナの数。

『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』の「Oracle Internet Directory」の章を参照してください。

LDAP

256

整数

orclpluginworkers

1サーバー・プロセス当たりのプラグイン・ワーカー・スレッドの最大数

変更した後、サーバーを再起動します。

『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』の「Oracle Internet Directory」の章を参照してください。

EM、LDAP、WLST

2

整数(最大64)

orclsizelimit

ldapsearchの結果で返すことができるエントリの最大数

『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』の「Oracle Internet Directory」の章を参照してください。

LDAP

10000

整数

orcltimelimit

特定のldapsearch操作でサーバーが使用できる最大時間

EM、LDAP、WLST

3600

整数(秒)

orclsdumpflag

スタック・ダンプを生成します。

付録Rを参照してください。

LDAP

0

0: スタック・トレース・ファイルを生成します。

1: スタック・トレース・ファイルは生成しませんが、コア・ファイルは生成します。

orclskipspecialinfilter

Oracle Internet Directoryで検索操作中にフィルタ値に指定された特殊文字の処理をスキップするかどうかを評価します。

LDAP

0

0: フィルタ値に指定された特殊文字を処理します。

1: フィルタ値に指定された特殊文字を処理しません。

orclcryptoversion

使用するSSL/TLSバージョンを指定できます。

LDAP

0

0: サポートされているすべてのプロトコル(デフォルト)

2: SSL v3.0の場合

4: TLS 1.0の場合

8: TLS 1.1の場合

16: TLS 1.2の場合

注意: 属性の性質は、加算方式です。つまり、対応する値を指定することで、複数のプロトコルを追加できます。詳細は、第27.1.2項「サポートされているプロトコルのバージョン」を参照してください。

9.1.4 DSA構成エントリの属性

DSA構成エントリには、次のような識別名があります。

cn=dsaconfig,cn=configsets,cn=oracle internet directory

表9-2に、DSA構成エントリの共有属性を示します。更新メカニズムの列には、次の略称が含まれています。

- EM - Oracle Enterprise Manager Fusion Middleware Control。第9.2項「Fusion Middleware Controlを使用したシステム構成属性の管理」を参照してください。

- LDAP - LDAPコマンド行ツール(ldapmodifyやldapaddなど)。第9.4項「LDAPツールを使用したシステム構成属性の管理」を参照してください。

注意:
DSAは、ディレクトリ・サーバーを意味するX.500用語です。

表9-2 DSA構成エントリの属性

属性

説明

更新メカニズム

デフォルト

使用可能な値

orclblockdnip

新しい接続を拒否してそのIPアドレスからの既存の接続をOracle Internet DirectoryサーバーにクローズさせるIPアドレス。

EM,LDAP

なし

IPアドレス

orclcomputedattribute

特定のルールに基づいて構成可能な属性およびその値を動的に計算するメカニズム。

第17章を参照してください。

LDAP

なし

複数値属性

orclmaxlatencylog

その時間を超えるとOracle Internet Directoryサーバーの操作がアラート・ログに記録される時間(マイクロ秒)。

EM,LDAP

500マイクロ秒

最小は10マイクロ秒です。

マイクロ秒。

orclmaxtcpidleconntime

Oracle Internet Directoryサーバーが対応するOracle Databaseにキープ・アライブ・メッセージを送信するためにOCIPing()をコールする頻度(分)。この属性に、Oracle Internet DirectoryサーバーとOracle Database間のファイアウォールのタイムアウト値(通常は30分)よりも小さい値を設定することによって、データベース接続の切断が避けられます。

LDAP

20分

整数

0: OCIPing()なし

ダウンタイムなしのパッチ適用を実現するには、orclmaxtcpidleconntime; ttlを5に設定し、データベースがオフになるまで数サイクル待機します。数サイクルが完了すると、データベースは初期設定値が0になってオフになります

この属性の値は分単位です。

LDAP

0

整数

0: 無効

orclmaxfiltsize

最大フィルタ・サイズ

第9.2.2項「共有プロパティの構成」を参照してください。

EM、LDAP

24576

整数

orclrefreshdgrmems

動的グループ・メンバーシップのリフレッシュ。第14章を参照してください。

LDAP

0

1: リフレッシュを実行します。サーバーによって0にリセットされます。

orclautocatalog

最初の検索で属性を索引付けします。第21.1.3.4項「属性の索引付けについて」を参照してください。

EM、LDAP

1

0: 無効

1: 有効

orclrienabled

参照整合性。第22章を参照してください。

EM、LDAP

0

0: 無効

1: 有効

orclstatsdn

統計収集用ユーザー識別名。第25章を参照してください。

EM、LDAP

空

エントリの識別名

orcldataprivacymode

返す際に機密の属性を暗号化

第28章を参照してください。

LDAP

0

0: 無効

1: 有効

orclencryptedattributes

機密の属性を暗号化形式で格納

第28章を参照してください。

LDAP

表28-1を参照してください。

属性

orclhashedattributes

属性をハッシュされた形式で格納。

第28章を参照してください。

EM、LDAP

空

属性

orclpkimatchingrule

ユーザーのPKI証明書の識別名をそのユーザーのエントリ識別名にマッピングするためのPKI一致ルール。第33章を参照してください。

EM、LDAP

2

0: 完全一致。

1: 証明書検索。

2: 0と1の組合せ。

3: マッピング・ルールのみ。

4: 3、2の順に試行

orclgeneratechangelog

ユーザー操作の変更ログを生成するかどうか。

第43章および『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』の「Oracle Internet Directory」の章を参照してください。

LDAP

1

1: 有効

0: 無効

orcljvmoptions

サーバー・プラグインが起動されたときに、JVMに渡されるオプション。第45章を参照してください。

EM、LDAP

-Xmx64M

有効なJVMオプション

orclinmemfiltprocess

メモリーで処理される検索フィルタの詳細は、『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』の「Oracle Internet Directory」の章を参照してください。

EM、LDAP

『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』のリストを参照

有効な検索フィルタ

orclmatchdnenabled

検索のベース識別名が存在しないときに、詳細な一致DN情報を提供するかどうか。『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』の「Oracle Internet Directory」の章を参照してください。

EM、LDAP

1

0: 一致なしですが、データベースにベース識別名が存在するかどうかを検証します。

1: 一致

2: ベース識別名が存在するかどうかについてDBを確認しません。

orclskewedattribute

スキュー属性。

変更後サーバーを再起動することをお薦めします。

『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』の「Oracle Internet Directory」の章を参照してください。

EM、LDAP

objectclass

属性のリスト

orclskiprefinsql

検索の参照をスキップします。

変更後サーバーを再起動することをお薦めします。『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』の「Oracle Internet Directory」の章を参照してください。

EM、LDAP

0

0: 無効

1: 有効

orcltlimitmode

正確な時間か、おおよその時間のいずれかの最大検索時間モードを指定。『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』の「Oracle Internet Directory」の章を参照してください。

LDAP

0

0: 正確な時間

1: おおよその時間

orclcachemaxsize

サブタイプ(rsまたはmd)で指定される結果セット・キャッシュまたはメタデータ・キャッシュのサイズ(バイト)。

有効にするにはサーバーの再起動が必要です。

LDAP

結果セット・キャッシュ: 64MB (64MBは最小キャッシュ・サイズです)

メタデータ・キャッシュ: 128MB (128MBは最小キャッシュ・サイズです)。

サブタイプ: rs (結果セット・キャッシュ)またはmd (メタデータ・キャッシュ)

サイズ: M (MB)またはG (GB)。

orclecacheenabled

エントリ・キャッシュまたは結果セット・キャッシュを有効または無効にします。『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』の「Oracle Internet Directory」の章を参照してください。

EM、LDAP、WLST

2

0: 両方のキャッシュを無効にします。

1: エントリ・キャッシュのみを有効にします

2: 両方のキャッシュを有効にします。

4: サーバーの起動時またはキャッシュの破棄時にキャッシュ・データを事前ロードします。Oracle Internet Directoryサーバーは、orclecacheenabledが4に設定されている場合、キャッシュを再構築します。

注意: エントリ・キャッシュの事前ロードは、orclrscacheattr設定に基づきます。

orclecachemaxentries

エントリ・キャッシュ内の最大エントリ。『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』の「Oracle Internet Directory」の章を参照してください。

EM、LDAP、WLST

100000

整数

orclecachemaxsize

エントリ・キャッシュ・サイズ(バイト)。『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』の「Oracle Internet Directory」の章を参照してください。

EM、LDAP、WLST

200000000バイト

サイズ: M (MB)またはG (GB)。

例: 200M

orclrscacheattr

結果セット・キャッシュ属性

『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』の「Oracle Internet Directory」の章を参照してください。

EM、LDAP、WLST

cn

uid

mail

orclguid

結果セット・キャッシュの属性を指定する複数値属性。

通常、これらの属性はエントリの存続期間中変更できません。参照整合性を有効にした属性は、使用すべきではありません。

orclenablegroupcache

グループ・キャッシュの有効化/無効化

『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』の「Oracle Internet Directory」の章を参照してください。

LDAP

1

1: 有効。

0: 無効

orcldseecompatible

orcldseecompatibleが1に設定されている場合、検索リクエストに+必須属性が含まれると、属性numsubordinatesが返されます。

なし

9.1.5 DSEの属性

DSA固有のエントリ(DSE)はDITのルートです。Oracle Internet Directoryは、ネーミング・コンテキスト、サポートされている制御、一致規則などの自身の情報をここに公開します。大部分のDSEの属性は直接変更できません。

注意:
Oracle Internet Directory 11g リリース1(11.1.1.6.0)以降では、orclcompatibleversion DSE属性にはOracle Internet Directoryのバージョンが含まれます。この属性は、複数値です。値は次のとおりです。

- orclcompatibleversion: 11.1.1.6.0

- orclcompatibleversion: 11.1.1.7.0

orclcompatibleversionは変更しないでください。対応するスキーマで動作するにはOracle Internet Directoryに存在する必要があります。

表9-3に、変更の必要の可能性があるDSE属性をリストします。

表9-3 DSEの属性

属性

説明

更新メカニズム

デフォルト

使用可能な値

namingcontexts

ネーミング・コンテキスト。第11章を参照してください。

LDAP

c=us

dc=com

有効なネーミング・コンテキスト。

ref

参照の指定。第20章を参照してください。

LDAP

orclaci

ルートDSEレベルでのアクセス制御。第30章を参照してください。

LDAP

orclcryptoscheme

パスワードを保護するハッシング・アルゴリズム。第31章を参照してください。

LDAP

SSHA

MD4、MD5、SHA、SSHA、SHA256、SHA384、SHA512、SSHA256、SSHA384、SSHA512、SMD5、UNIX Crypt

subentry

DSEルートを規定するパスワード・ポリシーの識別名を指定。第29章を参照してください。

LDAP

cn=default,cn=pwdPolicies,cn=Common,cn=Products,cn=OracleContext

orclsimplemodchglogattributes

変更ログにすべての値のリストではなく変更のみを含む複数値属性のリスト。第43.1.3項「ディレクトリ・レプリケーションの変更ログ」を参照してください。

LDAP

member, uniqueMember

複数値属性

9.2 Fusion Middleware Controlを使用したシステム構成属性の管理

Oracleディレクトリ・サーバーのほとんどの構成属性は、Oracle Enterprise Manager Fusion Middleware Controlを使用して表示および設定できます。

この項の内容は次のとおりです。

- 第9.2.1項「サーバー・プロパティの構成」

- 第9.2.2項「共有プロパティの構成」

- 第9.2.3項「その他のパラメータの構成」

9.2.1 サーバー・プロパティの構成

インスタンス固有の構成エントリのほとんどの属性は、次のように、Fusion Middleware ControlのOracle Internet Directoryの「サーバー・プロパティ」ページを使用して構成できます。

1. 「Oracle Internet Directory」メニューから「管理」を選択し、「サーバー・プロパティ」を選択します。

2. 構成するパラメータに応じて、「一般」、「パフォーマンス」、「SASL」、「統計」、「ロギング」のいずれかを選択します。

3. 構成を変更した後、「適用」を選択します。

表9-4に、「サーバー・プロパティ」ページの「一般」タブでのサーバー・プロパティと構成属性の対応関係を示します。

一般

表9-4 「サーバー・プロパティ」ページ、「一般」タブの構成属性

フィールドまたはヘッダー

構成属性

サーバー・モード

orclservermode

検索で返される最大エントリ数

orclsizelimit

検索の完了までに許可された最大時間(秒)

orcltimelimit

検索リクエストで指定した必須属性名の大/小文字区別を保持

orclreqattrcase

匿名バインド

orclanonymousbindsflag

1つのトランザクションで許容される最大時間(秒)。

orcltxntimelimit

1つのトランザクションで許容される操作の最大数。

orcltxnmaxoperations

非SSLポート

orclnonsslport

SSLポート

orclsslport

パフォーマンス

表9-5に、「サーバー・プロパティ」ページの「パフォーマンス」タブでのサーバー・プロパティと構成属性の対応関係を示します

表9-5 「サーバー・プロパティ」ページ、「パフォーマンス」タブの構成属性

フィールドまたはヘッダー

構成属性

OID LDAPサーバー・プロセス数

orclserverprocs

1サーバー・プロセス当たりのDB接続の数

orclmaxcc

権限グループのメンバーシップ・キャッシュ内のユーザー数

orclmaxconnincache

LDAPアイドル接続タイムアウト

orclldapconntimeout

OIDサーバー・ネットワーク読込み/書込み再試行タイムアウト

orclnwrwtimeout

1サーバー・プロセス当たりのLDAP接続の最大数

orclmaxldapconns

サーバー・プロセスがディスパッチャ・プロセスに応答する最大時間(秒)

orclMaxServerRespTime

1サーバー・プロセス当たりのディスパッチャ・スレッドの数

orcldispthreads

1サーバー・プロセス当たりのプラグイン・スレッドの数

orclpluginworkers

変更ログの生成の有効化

orclgeneratechangelog

orclserverprocs、orclmaxcc、orcldispthreadsまたはorclpluginworkersを変更した後、サーバーを再起動します。

SASL

「サーバー・プロパティ」ページの「SASL」タブのサーバー・プロパティと構成属性の対応は、表33-1「「サーバー・プロパティ」ページ、「SASL」タブの構成属性」に示します。

統計

「サーバー・プロパティ」ページの「統計」タブのサーバー・プロパティと構成属性の対応は、表25-2「「サーバー・プロパティ」ページ、「統計」タブの構成属性」に示します。

ロギング

「サーバー・プロパティ」ページの「ロギング」タブのサーバー・プロパティと構成属性の対応は、表24-2「「サーバー・プロパティ」ページ、「ロギング」タブの構成属性」に示します。

9.2.2 共有プロパティの構成

DSA構成エントリの一部の共有システム構成属性は、Fusion Middleware ControlのOracle Internet Directoryの「共有プロパティ」ページを使用して構成できます。「Oracle Internet Directory」メニューの「管理」を選択し、「共有プロパティ」を選択してから、「一般」、「スーパーユーザー・パスワードの変更」または「レプリケーション」を選択します。構成を変更した後、「適用」を選択します。対応関係は次のとおりです。

一般

表9-6 「共有プロパティ」、「一般」タブの構成属性

フィールドまたはヘッダー

構成属性

ユーザーDN

orclstatsdn

検索の参照のスキップ

orclskiprefinsql

スキュー属性

orclskewedattribute

メモリーで処理される検索フィルタ

orclinmemfiltprocess

ハッシュ属性

orclhashedattributes

一致DN

orclMatchDnEnabled

PKI一致ルール

orclPKIMatchingRule

参照整合性

orclrienabled

最大フィルタ・サイズ

orclmaxfiltsize

エントリ・キャッシュの有効化

orclecacheenabled

エントリ・キャッシュ内の最大エントリ

orclecachemaxentries

最大エントリ・キャッシュ・サイズ(MB)

orclecachemaxsize

EMページ上にない権限グループのメンバーシップ・キャッシュ内のユーザー数

orclmaxconnincache

結果セット・キャッシュ属性

orclrscacheattr

JavaプラグインVMオプション

orcljvmoptions

orclskiprefinsqlまたはorclskewedattributeの変更後は、サーバーを再起動することをお薦めします。

スーパーユーザー・パスワードの変更

第12.5項「Fusion Middleware Controlを使用したスーパーユーザー・パスワードの変更」を参照してください。

レプリケーション

レプリケーションに関連する属性は、第42章「レプリケーション構成属性の管理」で説明されています。第42.2.1項「「共有プロパティ」、「レプリケーション」タブの構成属性」を参照してください。

9.2.3 その他のパラメータの構成

Oracle Internet Directoryの「SSL構成」ページを使用して、SSLパラメータを構成できます。第27.2項「Fusion Middleware Controlを使用したSSLの構成」を参照してください。SSL構成の変更を反映するには、サーバーを再起動する必要があります。

Oracle Internet Directoryの「監査ポリシー設定」ページを使用して、監査属性を構成できます。第23.2項「Fusion Middleware Controlを使用した監査の管理」を参照してください。

9.3 WLSTを使用したシステム構成属性の管理

マネージドBean(MBean)は、分散環境でのアプリケーション、サービス、コンポーネント、デバイスなどのJMX管理可能なリソースを表すJavaオブジェクトです。WebLogicサーバーでは、Oracle Internet DirectoryなどのOPMNで管理されるコンポーネントのインタフェースとしてカスタムMBeanを使用します。Oracle共通ホームのWebLogic Scripting Tool(wlst)を使用して、Oracle Enterprise Manager Fusion Middleware Controlインタフェースを備えたOracle Internet Directoryインスタンス固有の構成エントリの属性を管理できます。

注意:
WLSTは、そのSSLポートを介してOracle Internet Directoryを管理します。Oracle Internet DirectoryのSSLポートは、認証なしまたはサーバー認証用に構成されている必要があります。Oracle Internet Directory SSLポートが相互認証用に構成されている場合、WLSTを使用してOracle Internet Directory属性を変更することはできません。第27.1.3項「SSL認証モード」を参照してください。

関連項目:

- Oracle Fusion Middleware管理者ガイド

- Oracle Fusion Middleware Oracle WebLogic Scripting Tool

- 第27.3項「WLSTを使用したSSLの構成」

- 第23.3項「WLSTを使用した監査の管理」

WLSTの使用方法は次のとおりです。

1. WLSTを起動します。

ORACLE_COMMON_HOME/common/bin/wlst.sh

2. WebLogicサーバーに接続します。

connect('username', 'password', 'localhost:7001')

3. カスタムMBeanツリーにナビゲートするには、次のように入力します。

custom()

これをwlstプロンプトで入力します。

4. カスタムMBeanツリーでMBeanの1レベル・リストを取得するには、次のように入力します。

ls()

ls()出力では、Oracle Internet Directory構成に関連するMBeanを含む2つのドメインが表示されます。ドメインは、oracle.as.management.mbeans.registerとoracle.as.oidです。

5. ドメインに移動するには、cd()コマンドを使用します。次に例を示します。

cd('oracle.as.management.mbeans.register')

または

cd('oracle.as.oid')

ls()と入力すると、そのドメインのMBeanのリストが表示されます。Oracle Internet Directory構成に関連するMBeanは、oracle.as.management.mbeans.registerに3つ、oracle.as.oidに2つあります。表9-7にこれを示します。

表9-7 Oracle Internet Directoryに関連するMBean

MBean名

MBeanドメイン

ls()出力のMBean書式

ルート・プロキシMBean

oracle.as.management.mbeans.register

oracle.as.management.mbeans.register:type=component,name=COMPONENT_NAME,instance=INSTANCE

非SSLポートMBean

oracle.as.management.mbeans.register

oracle.as.management.mbeans.register:type=component.nonsslport,name=nonsslport1,instance=INSTANCE,component=COMPONENT_NAME

監査MBean

oracle.as.management.mbeans.register

oracle.as.management.mbeans.register:type=component.auditconfig,name=auditconfig1,instance=INSTANCE,component=COMPONENT_NAME

SSLポートMBean

oracle.as.oid

oracle.as.oid:type=component.sslconfig,name=sslport1,instance=INSTANCE,component=COMPONENT_NAME

キーストアMBean

oracle.as.oid

oracle.as.oid:type=component.keystore,name=keystore,instance=INSTANCE,component=COMPONENT_NAME

INSTANCEとCOMPONENT_NAMEはそれぞれ、Oracle Internet Directoryコンポーネントを含むOracleインスタンスとコンポーネントの名前を表します。

注意:
監査MBeanは、完全を期すためにここに示されていますが、wlstを使用した監査の管理には別のコマンドを使用します。「WLSTを使用した監査の管理」を参照してください。

6. 特定のMBeanに移動するには、次のように入力します。

cd('MBEAN_NAME')

たとえば、ドメインoracle.as.management.mbeans.registerにいて、Oracleインスタンスinstance1のOracle Internet Directoryコンポーネントoid1のルート・プロキシMBeanを管理する場合、次のように入力します。

cd('oracle.as.management.mbeans.register:type=OID,name=oid1,instance=instance1')

7. 目的のMBeanにナビゲートした後、次のように入力して属性の現在値を取得できます。

get('ATTRIBUTE_NAME')

たとえば、orclserverprocsの値を取得するには、次のように入力します。

get('orclserverprocs')

8. 属性を変更する前に、MBeanに現在のサーバー構成が設定されていることを確認する必要があります。これを行うには、Oracle Internet Directoryサーバーから構成をMBeanにロードします。次のように入力します。

invoke('load',jarray.array([],java.lang.Object),jarray.array([],java.lang.String))

9. これで、setコマンドを使用して特定の属性を設定できます。次のように入力します。

set('ATTRIBUTE_NAME', ATTRIBUTE_VALUE)

たとえば、orclserverprocs = 12を設定するには、次のように入力します。

set('orclserverprocs', 12)

10. 変更後は、Oracle Internet DirectoryサーバーにMBean構成を保存する必要があります。次のように入力します。

invoke('save',jarray.array([],java.lang.Object),jarray.array([],java.lang.String))

9.4 LDAPツールを使用したシステム構成属性の管理

ほとんどのシステム構成属性は、コマンド行からldapmodifyを使用して変更できます。ほとんどのシステム構成はldapsearchを使用してリストできます。この項では、次の項目について説明します。

- 第9.4.1項「ldapmodifyを使用したシステム構成属性の設定」

- 第9.4.2項「ldapsearchによる構成属性のリスト」

9.4.1 ldapmodifyを使用したシステム構成属性の設定

表9-1、表9-2および表9-3の属性のほとんどはコマンド行を使用して変更できます。

ldapmodify -D cn=orcladmin -q -p portNum -h hostname -f ldifFile

LDIFファイルの内容は、識別名および実行されている操作によって異なります。

インスタンス固有のエントリ内のorclgeneratechangelog属性の値を1に変更するLDIFファイルは、次のようになります。

dn: cn=componentname,cn=osdldapd,cn=subconfigsubentry
changetype: modify
replace: orclgeneratechangelog
orclgeneratechangelog: 1

DSA構成エントリにorclinmemfiltprocess属性を追加する場合、LDIFファイルは次のようになります。

dn: cn=dsaconfig, cn=configsets, cn=oracle internet directory
changetype: modify
add: orclinmemfiltprocess
orclinmemfiltprocess: (objectclass=inetorgperson)(orclisenabled=TRUE)

注意:

- 11g リリース1(11.1.1)では、orcldebugflagとorcloptracklevelの連続設定は加算方式です。

- orclskiprefinsql、orclskewedattribute、orclserverprocs、orcldispthreads、orclmaxcc、orclpluginworkersまたは"orclssl"や"orclsasl"で始まる名前の属性の変更後、サーバーを再起動します。

- orclnonsslportまたはorclsslportの変更後、第8.3.4項「opmnctlを使用したOracleインスタンスのコンポーネント登録の更新」に記載のとおり、サーバーを再起動し、opmnctl updatecomponentregistrationを実行します。

関連項目:

- LDIFファイルの例の詳細は、『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』の「Oracle Internet Directory」の章を参照してください。

- ldapmodifyの詳細とそのオプションのリストは、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のldapmodifyコマンド行ツールのリファレンスを参照してください。

- 変更可能なシステム構成属性の詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のOracle Identity Management LDAP属性のリファレンスを参照してください。

9.4.2 ldapsearchによる構成属性のリスト

ldapsearchを使用してほとんどの属性をリストできます。

インスタンス固有の構成エントリ

サーバー・インスタンスのコンポーネント名がoid1の場合、コマンド行で次のように指定してインスタンス固有の構成エントリ属性をリストできます。

ldapsearch -p 3060 -h myhost.example.com -D cn=orcladmin -q \
-b "cn=oid1,cn=osdldapd,cn=subconfigsubentry" -s base "objectclass=*"

DSA構成エントリ

コマンド行で次のように指定して属性をリストできます。

ldapsearch -p 3060 -h myhost.example.com -D cn=orcladmin -q \
-b "cn=dsaconfig,cn=configsets,cn=oracle internet directory" \
-s base "objectclass=*"

DSE

コマンド行で次のように指定して属性をリストできます。

ldapsearch -p 3060 -h myhost.example.com  -D cn=orcladmin -q \
-b "" -s base "objectclass=*"

9.5 ODSMデータ・ブラウザを使用したシステム構成属性の管理

Oracle Enterprise Manager Fusion Middleware Controlは、システム構成属性を管理するために推奨されるグラフィカル・ユーザー・インタフェースです。また、ODSMを使用してシステム構成属性を管理することもでき、これは、Fusion Middleware Controlを利用できない場合やFusion Middleware Controlインタフェースがない属性を変更する必要がある場合に便利です。

ディレクトリ・エントリ属性の変更方法の詳細は、第13.2項「Oracle Directory Services Managerを使用したエントリの管理」を参照してください。以降の項では、システム構成属性を含むエントリへODSMで移動する方法を説明します。

9.5.1 インスタンス固有の構成エントリへの移動

「データ・ブラウザ」タブのナビゲーション・ツリーで、subconfigsubentry、osdldapdの順に展開します。次に、管理するOracle Internet Directoryコンポーネントの名前を選択します。

9.5.2 DSA構成エントリへの移動

「データ・ブラウザ」タブのナビゲーション・ツリーで、oracle internet directoryを展開してからconfigsetsを展開し、次に、エントリdsaconfigを選択します。

9.5.3 DSEルートへの移動

「データ・ブラウザ」タブのナビゲーション・ツリーで「ルート」をクリックし、DSEを選択します。

10 IPアドレスの管理

この章では、Oracle Internet DirectoryのIPアドレスと、それらのIPアドレスをIPV6、コールド・フェイルオーバー・クラスタ、仮想IPまたはクラスタ内通知のために構成する方法について説明します。

この章の内容は次のとおりです。

- 第10.1項「IPアドレスの管理の概要」

- 第10.2項「IP V6、コールド・フェイルオーバー・クラスタまたは仮想IP用のIPアドレスの構成」

- 第10.3項「クラスタ内通知用のIPアドレスの構成」

10.1 IPアドレスの管理の概要

デュアル・スタック(IPV4/IPV6)ホストにOracle Internet Directoryをインストールすると、Oracle Internet Directoryは両方のアドレスをリスニングします。Oracle Databaseへの接続にIPV4アドレスが必要であるため、Oracle Internet DirectoryをIPV6アドレスのみを使用するホストにインストールできません。

Oracle Internet DirectoryをIPV4ホストにインストールした後、ホストのアドレスをIPV6に変更する場合、インスタンス固有の構成エントリのorclhostname属性を変更して、Oracle Internet DirectoryのIPアドレスを別途IPV6アドレスについて構成する必要があります。

他の理由からOracle Internet Directoryが特定のアドレスでリスニングする必要がある場合も、インスタンス固有の構成エントリのorclhostname属性を変更して行います。

10.2 IP V6、コールド・フェイルオーバー・クラスタまたは仮想IP用のIPアドレスの構成

次の手順を実行し、Oracle Internet Directoryが特定のIPアドレスをリスニングするように構成します。

1. 次のようなLDIFファイルを作成します。

dn: cn=COMPONENT_NAME, cn=osdldapd, cn=subconfigsubentry
changetype: modify
replace: orclhostname
orclhostname: IP_address

2. 次のldapmodifyコマンドを実行します。

ldapmodify -D cn=orcladmin -q -p portNum -h hostname -f ldifFile

3. 次のようにopmnctlを使用して、Oracle Internet Directoryを再起動します。

opmnctl stopall
opmnctl startall

4. 第8.3.4項「opmnctlを使用したOracleインスタンスのコンポーネント登録の更新」に記載のとおり、Oracle Internet Directoryコンポーネントの登録を更新します。次に例を示します。

$ORACLE_INSTANCE/bin/opmnctl updatecomponentregistration \
-adminHost myhost \
-adminPort 7001 \
-adminUsername weblogic \
-componentType OID  \
-componentName oid2\
-Port 3061
-Sport 3131

この処理を行わないと、Fusion Middleware Controlまたはwlstを使用してコンポーネントを管理できません。

インスタンス固有の構成エントリ内のorclhostname属性を変更するときは、ODSMも使用できます。第9.5項「ODSMデータ・ブラウザを使用したシステム構成属性の管理」を参照してください。

10.3 クラスタ内通知用のIPアドレスの構成

クラスタ環境では、キャッシュされたデータが変更されたときに、Oracle Internet Directoryサーバーが相互に通信する必要があります。これらのサーバーは、LDAPプロトコルを使用して通信します。したがってクラスタ環境では、この通信のために少なくとも1つの非SSLポートが使用可能であることが必要です。

パフォーマンスの向上のために、専用のIPアドレスおよびOracle Internet Directoryインスタンスを通知に使用します。次のように、新しいコンポーネントを作成した後、インスタンス構成を追加します。

ldapmodify -p oidPort -D cn=orcladmin -w adminPasswd -f ldiffile

この例では、ldiffileの内容は次のとおりです。

dn: cn=oid-instance,cn=osdldapd,cn=subconfigsubentry
changetype: modify
add: orclcachenotifyip;port-number-to-use
orclcachenotifyip;port-number-to-use: IP-address-to-use

各項目の意味は次のとおりです。

- oid-instanceは、oid1、oid2、oid3などの専用Oracle Internet Directoryコンポーネントです。

- port-number-to-useは、通知に使用するポート番号です。

- IP-address-to-useは、通知に使用するIPアドレスです。

たとえば、ノード1上に2つのIPアドレス10.10.10.1および10.10.10.2があり、10.10.10.2を通知に使用する場合は、次の構成を実行します。ここでoid1は、ノード1上のコンポーネント名です。

ldapmodify -p oidPort -D cn=orcladmin -w adminPasswd -f ldiffile

この例では、ldiffileの内容は次のとおりです。

dn: cn=oid1,cn=osdldapd,cn=subconfigsubentry
changetype: modify
add: orclcachenotifyip
orclcachenotifyip: 10.10.10.2

同様に、ノード2上で2つのIPアドレス10.10.10.3および10.10.10.4があり、10.10.10.4を通知に使用する場合は、次の構成を実行します。ここでoid2は、ノード2上のコンポーネント名です。

ldapmodify -p oidPort -D cn=orcladmin -w adminPasswd -f ldiffile

この例では、ldiffileの内容は次のとおりです。

dn: cn=oid2,cn=osdldapd,cn=subconfigsubentry
changetype: modify
add: orclcachenotifyip
orclcachenotifyip: 10.10.10.4

注意:
orclcachenotifyipをOracle Internet Directoryインスタンス用に構成する場合、そのインスタンスを実行しているノードにローカルなIPアドレスであることが必要です。
たとえば、ノード1上のOracle Internet Directoryがcn=oid1,cn=osdldapd,cn=subconfigsubentryであり、ノード2上のOracle Internet Directoryがcn=oid2,cn=osdldapd,cn=subconfigsubentryである場合、ノード1上のOracle Internet Directoryはノード2の構成情報(cn=oid2,cn=osdldapd,cn=subconfigsubentry)をチェックします。

ノード1上でOracle Internet Directoryサーバーを開始すると、この情報を使用してノード2(10.10.10.4)上のOracle Internet Directoryに接続します。

本番トラフィックに対する通知LDAPトラフィックの影響を避けたい場合は、各ノード上で新しいOIDインスタンスを作成します。たとえば、次のようにして、ノード1上でポート番号5678によりoid3を作成します。

ldapmodify -p oidPort -D cn=orcladmin -w adminPasswd -f ldiffile

この例では、ldiffileの内容は次のとおりです。

dn: cn=oid3,cn=osdldapd,cn=subconfigsubentry
changetype: modify
add: orclcachenotifyip;5678
orclcachenotifyip;5678: 10.10.10.2

ノード2上でも同じ手順を繰り返し、次のようにしてポート番号5678によりoid4インスタンスを作成します。

ldapmodify -p oidPort -D cn=orcladmin -w adminPasswd -f ldiffile

この例では、ldiffileの内容は次のとおりです。

dn: cn=oid4,cn=osdldapd,cn=subconfigsubentry
changetype: modify
add: orclcachenotifyip;5678
orclcachenotifyip;5678: 10.10.10.4

11 ネーミング・コンテキストの管理

この章では、ネーミング・コンテキストの検索方法や、ネーミング・コンテキストを公開してユーザーが特定のネーミング・コンテキストを検索できるようにする方法など、Oracle Internet Directoryのネーミング・コンテキストについて説明します。

この章の内容は次のとおりです。

- 第11.1項「ネーミング・コンテキストの管理の概要」

- 第11.2項「公開されたネーミング・コンテキストの検索」

- 第11.3項「ネーミング・コンテキストの公開」

11.1 ネーミング・コンテキストの管理の概要

ネーミング・コンテキストの詳細は、「ネーミング・コンテキスト」を参照してください。

ネーミング・コンテキストを公開するには、各ネーミング・コンテキストの最上位エントリを、ルートDSEのnamingContexts属性の値として指定します。たとえば、3つの主なネーミング・コンテキストを持ったDITがあり、それらの最上位エントリがc=uk、c=usおよびc=deであるとします。これらのエントリがnamingContexts属性の値として指定されている場合、適切なフィルタを指定することによって、ユーザーはルートDSEの検索によってそれらの情報を検索できます。ユーザーは、特にc=deネーミング・コンテキストに絞り込むなど、検索条件を詳細に指定できます。

11.2 公開されたネーミング・コンテキストの検索

公開されたネーミング・コンテキストを検索するには、検索フィルタとしてobjectClass =*を指定して、ルートDSEでベース検索を実行します。検索された情報には、namingContexts属性で指定したエントリが含まれています。次に例を示します。

ldapsearch -p 3060 -q -D cn=orcladmin -b "" -s base -L "objectclass=*" \   namingcontexts

注意:
ネーミング・コンテキストが公開されている場合を除いて、このコマンドでは何も返されません。

ネーミング・コンテキストを公開する前に、次のことを確認してください。

- 自分がルートDSEへの必要なアクセスを持ったディレクトリ管理者であること

- そのネーミング・コンテキストの最上位エントリがディレクトリに存在すること

11.3 ネーミング・コンテキストの公開

ネーミング・コンテキストの公開にはldapmodifyを使用します。namingContexts属性は複数値なので、複数のネーミング・コンテキストを指定できます。

次のコマンド行を使用して、namingContextsを変更できます。

ldapmodify -D cn=orcladmin -q -p portNum -h hostname -f ldifFile

次のサンプルLDIFファイルは、ネーミング・コンテキストとしてエントリc=ukを指定しています。

dn:
changetype: modify
add: namingcontexts
namingcontexts: c=uk

12 アカウントおよびパスワードの管理

この章では、コマンド行ツール、セルフサービス・コンソール、Oracle Directory Services ManagerおよびOracle Enterprise Manager Fusion Middleware Controlを使用して、Oracle Internet Directoryのアカウントとパスワードを管理する方法について説明します。また、スーパーユーザー・アカウント、EMD管理者およびOracle Internet Directoryデータベースのパスワードを管理する方法について説明します。

この章の内容は次のとおりです。

- 第12.1項「アカウントおよびパスワードの管理の概要」

- 第12.2項「コマンド行ツールを使用したアカウントおよびパスワードの管理」

- 第12.3項「セルフサービス・コンソールを使用したアカウントおよびパスワードの管理」

- 第12.4項「Oracle Directory Services Managerを使用したロックされたアカウントのリストおよびロック解除」

- 第12.5項「Fusion Middleware Controlを使用したスーパーユーザー・パスワードの変更」

- 第12.6項「スーパーユーザー権限を持つ別のアカウントの作成」

- 第12.7項「ldapmodifyを使用したスーパーユーザー・パスワードの管理」

- 第12.8項「Oracle Internet Directoryデータベース・パスワードの変更」

- 第12.9項「スーパーユーザーのパスワードの再設定」

- 第12.10項「EMD管理者アカウントのパスワードの変更」

- 第12.11項「ODSSM管理者アカウントのパスワードの変更」

12.1 アカウントおよびパスワードの管理の概要

この章では、アカウントおよびパスワードに関する管理タスクについて説明します。

関連項目:

- 第13章「ディレクトリ・エントリの管理」

- 第29章「パスワード・ポリシーの管理」

- 第43.3.13項「アドバンスト・レプリケーションのレプリケーション管理者パスワードの変更」

注意:
この章で言及するセルフサービス・コンソールはすべて、Oracle Delegated Administration Services 10g(10.1.4.3.0)以上に含まれるコンソールのことであり、このコンソールはOracle Internet Directory 11g リリース1(11.1.1)と互換性があります。詳細は、10g (10.1.4.0.1)ライブラリの『Oracle Identity Management委任管理ガイド』を参照してください。

コマンド行ツールまたはセルフサービス・コンソールを使用して、ユーザー・アカウントを一時的に無効にし、その後再び有効にすることができます。セキュリティ管理者グループのメンバーの場合、ユーザーのパスワードを再設定せずに、アカウントのロックを解除できます。これによって、ユーザーに新規パスワードを明示的に知らせる必要がなくなります。ユーザーは、旧パスワードを使用してログインできます。

コマンド行ツールを使用して、ユーザーが初めてログインする場合、ユーザーに対してパスワードの変更を強制できます。

パスワードを忘れた場合や、アカウントがロックアウトされた場合は、パスワードを再設定できます。これは、セルフサービス・コンソールを使用して実行できます。この場合、パスワード検証属性セットに値を入力して、サーバーに対して本人確認を行う必要があります。この操作は、以前回答を指定したパスワードのヒントの質問に答えるという形をとります。

スーパーユーザーは、ディレクトリ情報への完全なアクセス権限を持つ特別なディレクトリ管理者です。スーパーユーザーのデフォルトのユーザー名はorcladminです。パスワードはインストール時に管理者によって設定されます。

注意:
このパスワードは、インストール後にすぐに変更することをお薦めします。

Oracle Enterprise Managerまたはldapmodifyのどちらかを使用して、スーパーユーザーのパスワードを管理できます。

関連項目:
アクセス権限の設定方法は、第30章「ディレクトリ・アクセス制御の管理」を参照してください。

もう1つの特権アカウントはadministrator ("cn=emd admin,cn=oracle internet directory")です。このアカウントは、Oracle Internet Directoryサーバーの管理機能情報の収集を開始および停止するために使用されます。Oracle Enterprise Manager Fusion Middleware ControlでOracle Internet Directoryの構成を変更する場合にも使用されます。これらの変更はセキュアな接続を介して行われます。

このアカウントのパスワードを変更する唯一の方法は、第12.10項「EMD管理者アカウントのパスワードの変更」で説明されている手順を使用する方法です。oidpasswdツールでは、このパスワードの変更はサポートされていません。

12.2 コマンド行ツールを使用したアカウントおよびパスワードの管理

この項の項目は次のとおりです。

- 第12.2.1項「コマンド行ツールを使用したアカウントの有効化と無効化」

- 第12.2.2項「コマンド行ツールを使用したアカウントのロック解除」

- 第12.2.3項「コマンド行ツールを使用したパスワードの強制変更」

12.2.1 コマンド行ツールを使用したアカウントの有効化と無効化

コマンド行ツールを使用して、ユーザー・アカウントを一時的に無効にし、その後再び有効にすることができます。

アカウントを永続的に無効にするには、orclisenabled属性をDISABLEDに設定します。この属性に他の値を設定すると、アカウントは有効になります。

アカウントを無効にした後、有効にするには、この属性をエントリから削除します。

特定の期間、アカウントを有効にするには、ユーザー・エントリ内のorclActiveStartDateおよびorclActiveEndDate属性を、UTC (協定世界時)書式による適切な値に設定します。たとえば、次のようなコマンド行を使用できます。

ldapmodify -p port -h host -D cn=orcladmin -q -v -f my.ldif

この場合、my.ldifには次が含まれます。

dn:cn=John Doe,cn=users,o=my_company,dc=com
orclactivestartdate:20030101000000z
orclactiveenddate: 20031231000000z

この例で、John Doeは、2003年1月1日から2003年12月31日までの期間ログインできます。2003年1月1日より前、または2003年12月31日より後はログインできません。これらの日付にはさまれた期間について彼のアカウントを無効にする場合は、orclisenabled属性をDISABLEDに設定します。

12.2.2 コマンド行ツールを使用したアカウントのロック解除

セキュリティ管理者グループのメンバーの場合、ユーザーのパスワードを再設定せずに、アカウントのロックを解除できます。これによって、ユーザーに新規パスワードを明示的に知らせる必要がなくなります。ユーザーは、旧パスワードを使用してログインできます。

アカウントのロックを解除するには、orclpwdaccountunlock属性を1に設定します。

次の例では、John Doeというユーザーのアカウントのロックを解除します。

ldapmodify -p port -h host -D cn=orcladmin -q -v -f file.ldif

この場合、file.ldifには次が含まれます。

dn: cn=John Doe,cn=users,o=my_company,dc=com
changetype: modify
add: orclpwdaccountunlock
orclpwdaccountunlock: 1

12.2.3 コマンド行ツールを使用したパスワードの強制変更

ユーザーが初めてログインする場合、ユーザーに対してパスワードの変更を強制できます。これを行うには、pwdpolicyエントリ内のpwdMustChange属性を1に設定し、パスワードを再設定します。この場合、ユーザーがログインしてパスワードを変更できるように、ユーザーに新しいパスワードを明示的に通知する必要があります。

関連項目:

- パスワードを再設定する方法は、第12.3.3項「Oracle Internet Directoryセルフサービス・コンソールを使用したパスワードの再設定」を参照してください。

- パスワード・ポリシーの属性の設定方法は、第29.3.4項「コマンド行ツールを使用したパスワード・ポリシーの設定」を参照してください。

12.3 セルフサービス・コンソールを使用したアカウントおよびパスワードの管理

管理者にとって、Oracle Directory Services Managerはユーザーおよびパスワードを管理するための主要なツールです。

Oracle Identity Managerを使用して、Oracle Internet Directory 11g リリース1(11.1.1)に対するユーザーおよびアカウントのプロビジョニングを集中管理することもできます。エンド・ユーザー・セルフサービスにとって、Oracle Identity Managerは推奨されるソリューションです。Oracle Identity Managerドキュメントは、次のOracle Technology Networkで入手できます。

http://www.oracle.com/technology/documentation/oim.html

Oracle Delegated Administration Servicesがすでに自分の環境に存在する顧客は、Oracle Internet Directory 11g リリース1(11.1.1)でのエンド・ユーザー・セルフサービスに使用できます。ただし、10gはOracle Delegated Administration Servicesのターミナル・リリースであり、そのコンポーネントは11g以上のリリースでは非推奨となっています。

この項の項目は次のとおりです。

- 第12.3.1項「Oracle Internet Directoryセルフサービス・コンソールを使用したアカウントの有効化と無効化」

- 第12.3.2項「Oracle Internet Directoryセルフサービス・コンソールを使用したアカウントのロック解除」

- 第12.3.3項「Oracle Internet Directoryセルフサービス・コンソールを使用したパスワードの再設定」

12.3.1 Oracle Internet Directoryセルフサービス・コンソールを使用したアカウントの有効化と無効化

Oracle Internet Directoryセルフサービス・コンソールを使用して、ユーザー・アカウントを一時的に無効にし、その後再び有効にすることができます。

関連項目:
Oracle Internet Directoryセルフサービス・コンソールを使用してアカウントを有効化および無効化する手順は、10g (10.1.4.0.1)ライブラリの『Oracle Identity Management委任管理ガイド』のアカウントの管理に関する項を参照してください

12.3.2 Oracle Internet Directoryセルフサービス・コンソールを使用したアカウントのロック解除

セキュリティ管理者グループのメンバーの場合、アカウントがロックされると、ユーザーのパスワードを再設定せずに、アカウントのロックを解除できます。これによって、ユーザーに新規パスワードを明示的に知らせる必要がなくなります。ユーザーは、旧パスワードを使用してログインできます。

関連項目:
Oracle Internet Directoryセルフサービス・コンソールを使用してアカウントのロックを解除する手順は、10g (10.1.4.0.1)ライブラリの『Oracle Identity Management委任管理ガイド』のアカウントの管理に関する項を参照してください

12.3.3 Oracle Internet Directoryセルフサービス・コンソールを使用したパスワードの再設定

パスワードを忘れた場合や、アカウントがロックアウトされた場合は、パスワードを再設定できます。この場合、パスワード検証属性セットに値を入力して、サーバーに対して本人確認を行う必要があります。この操作は、以前回答を指定したパスワードのヒントの質問に答えるという形をとります。

関連項目:
Oracle Internet Directoryセルフサービス・コンソールを使用してパスワードを再設定する手順は、10g (10.1.4.0.1)ライブラリの『Oracle Identity Management委任管理ガイド』のパスワードを忘れた場合の再設定に関する項を参照してください

12.4 Oracle Directory Services Managerを使用したロックされたアカウントのリストおよびロック解除

Oracle Directory Services Managerを使用して、ロックされたアカウントをリストしたりロック解除することができます。

1. 第7.4.5項「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動します。

2. タスク選択バーで、「データ・ブラウザ」を選択します。

3. 第13.2.2項「Oracle Directory Services Managerを使用したエントリの検索」の説明に従い、検索文字列(pwdaccountlockedtime=*)を使用して簡易検索を実行します。ロックされたアカウントを含むエントリのリストが表示されます。

4. ロック解除するアカウントを含むエントリを選択します。

5. アカウントがロックされている場合、「適用」ボタンおよび「元に戻す」ボタンの前に、「アカウントのロックを解除」が表示されます。「アカウントのロックを解除」をクリックします。

12.5 Fusion Middleware Controlを使用したスーパーユーザー・パスワードの変更

Oracle Enterprise Manager Fusion Middleware Controlを使用してスーパーユーザーのパスワードを変更する手順は、次のとおりです。

1. 「Oracle Internet Directory」メニューから「管理」を選択し、「共有プロパティ」を選択します。

2. 「スーパーユーザー・パスワードの変更」タブをクリックします。

3. 古いパスワードを指定します。

4. 新しいパスワードを指定します。

5. 新しいパスワードを確認します。

6. 「適用」をクリックします。

表12-1 「共有プロパティ」、「スーパーユーザー・パスワードの変更」タブの構成属性

フィールドまたはヘッダー

構成属性

スーパーユーザー・パスワード

orclsupassword

構成属性orclsupasswordはDSEルートの属性です。

12.6 スーパーユーザー権限を持つ別のアカウントの作成

スーパーユーザーcn=orcladminは、複数の権限グループ内のメンバーシップから権限を取得します。これらのグループを問い合せるには、次のldapsearchコマンドを使用します。

ldapsearch -h host -p port -D "cn=orcladmin" -q -b "" -L \
-s sub "(|(uniquemember=cn=orcladmin)(member=cn=orcladmin))" dn

スーパーユーザー権限を持つ2つ目のアカウントを作成するには、同じグループに属する別のユーザー・エントリを作成します。さらに、グループcn=directoryadmingroup,cn=oracle internet directoryのメンバーとして、そのユーザーを追加します。

注意:
「セキュリティ」および「拡張」タブを含むすべてのODSM機能を使用するには、新しいスーパーユーザー・アカウントはDirectoryAdminGroupグループのダイレクト・メンバーである必要があります。新しいスーパーユーザー・アカウントは、DirectoryAdminGroupグループのメンバーとなるグループのメンバーであることはできません。この構成では、スーパーユーザーはODSMの「ホーム」、「スキーマ」および「データ・ブラウザ」タブにのみアクセスできます。

スーパーユーザー権限を持つ追加のユーザーを作成した後は、Oracle Internet Directoryの管理にcn=orcladminを使用する必要はありません。権限を持つアカウントがあれば十分です。ただし、属性orclsunameには値cn=orcladminを設定する必要があります。

関連項目:
ユーザー・エントリの作成方法の詳細は第13章「ディレクトリ・エントリの管理」、グループへのユーザーの追加方法の詳細は第14章「動的グループと静的グループの管理」を参照してください。

注意:
システム・セキュリティを保持するには、権限ユーザーの数を最小限に抑えるとともに、すべての権限アカウントが監査されていることを確認します。第23章「監査の管理」を参照してください。

12.7 ldapmodifyを使用したスーパーユーザー・パスワードの管理

スーパーユーザーの名前は変更しないでください。orclsunameの値はcn=orcladminのまま維持する必要があります。

スーパーユーザーのパスワードを設定または変更するには、ldapmodifyを使用して、DSEルートの属性orclsunameまたはorclsupasswordをそれぞれ変更します。スーパーユーザーのユーザー名の変更は非常に影響が大きく、お薦めしません。

スーパーユーザーのパスワードをsuperuserpasswordに変更するには、次のように記述したLDIFファイルを使用します。

dn:
changetype:modify
replace:orclsupassword
orclsupassword:superuserpassword

関連項目:
ldapmodifyの構文と使用方法は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のldapmodifyコマンド行ツールのリファレンスを参照してください。

12.8 Oracle Internet Directoryデータベース・パスワードの変更

Oracle Internet Directoryは、独自に指定されたOracleデータベースへの接続時にパスワードを使用します。Oracle Internet Directoryインストール時のこのパスワードのデフォルトは、Oracle Fusion Middleware管理者のパスワードと同じです。oidpasswdを使用して、このパスワードを変更できます。

次の例は、データベースは同じマシン上にあるものと仮定した場合の、Oracle Internet Directoryデータベースのパスワードの変更方法を示しています。

oidpasswd connect=OIDDB change_oiddb_pwd=true
current password: oldpassword
new password: newpassword
confirm password: newpassword
password set.

関連項目:
『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のoidpasswdコマンド行ツールのリファレンス

注意:
ここで説明したアカウントは、サーバー管理機能情報へのアクセスに使用されるODSSMアカウントとは異なります。このアカウントは、第25.1.4項「サーバー管理機能情報にアクセスするために使用されるアカウント」で説明されています。このアカウントの変更方法は、第12.11項「ODSSM管理者アカウントのパスワードの変更」を参照してください。

12.9 スーパーユーザーのパスワードの再設定

Oracle Internet Directoryスーパーユーザー(cn=orcladmin)のパスワードを忘れた場合は、oidpasswdツールを使用してパスワードを再設定できます。Oracle Internet Directoryデータベースのパスワードを指定する必要があります。Oracle Internet Directoryを初めてインストールする場合、スーパーユーザーのパスワードとOracle Internet Directoryデータベースのパスワードは同じです。ただし、インストール後は、ldapmodifyを使用してOracle Internet Directoryスーパーユーザーのパスワードを変更できます。Oracle Internet Directoryスーパーユーザーのパスワードを忘れた場合は、oidpasswdツールを使用してパスワードを再設定できます。

次の例は、Oracle Internet Directoryスーパーユーザーのパスワードを再設定する方法を示しています。oidpasswdツールは、Oracle Internet Directoryデータベースのパスワードを要求します。

例:

oidpasswd connect=OIDDB reset_su_password=true
OID DB user password: oid_db_password
password: new_su_password
confirm password: new_su_password
OID superuser password reset successfully

12.10 EMD管理者アカウントのパスワードの変更

EMD管理者アカウント(cn=emd admin,cn=oracle internet directory)の特権は非常に制限されており、主に、Oracle Internet Directoryサーバーの管理機能情報の収集を開始および停止するために使用されます。

関連項目:
Oracle Internet Directoryサーバーの管理機能情報の収集の詳細は、第25章「Oracle Internet Directoryのモニタリング」を参照してください。

EMD管理者のパスワードを変更するには、Oracle Internet Directoryでこのパスワードを変更してから、WebLogicドメインのサーバーとドメイン内の各Oracleインスタンスの両方でこのパスワードを変更する必要があります。次の手順に従ってください。

1. ldapmodifyを使用して、Oracle Internet Directoryのアカウントcn=emd admin,cn=oracle internet directoryのuserpasswordを変更します。

2. wlstを起動してWebLogicサーバーに接続します。

java weblogic.WLST
connect('weblogic', 'weblogic_user_password', 'protocol:host:port')

3. 次のWLSTコマンドを実行します。

upupdateCred(map='emd',keu='EMD_instance_name', password='newpassword',user='EMD')

4. WebLogicドメインの各Oracleインスタンスで、次のコマンド行を実行します。

ORACLE_HOME/ldap/bin/oidcred emd update [instanceName]

5. 第8.3.4項「opmnctlを使用したOracleインスタンスのコンポーネント登録の更新」に記載のとおり、Oracleインスタンスのコンポーネント登録を更新します。

12.11 ODSSM管理者アカウントのパスワードの変更

Oracle Internet Directoryは、スキーマの作成時にODSスキーマに対して指定されたパスワードを使用してOracle Databaseに接続します。また、同様にスキーマの作成時に、ODSSMスキーマ・パスワードを使用して接続し、そのメトリックを取得します。インストール終了時のOracle Enterprise Manager Fusion Middleware Controlのデフォルト・パスワードは、ODSSMパスワードと同じです。

注意:
11gでは、EMAgentはODSSMパスワードを動的に取得します。そのため、ODSSMパスワードの変更手順を実行する前に、まずEMAgentを停止する必要があり、その場合にのみ作業を進めることができます。

ODSSM管理者のパスワードを変更するには、Oracle Databaseでこのパスワードを変更してから、WebLogicドメインのサーバーとドメイン内の各Oracleインスタンスの両方でこのパスワードを変更する必要があります。次の手順に従ってください。

1. SQLPlusまたは同様のツールを使用して、データベースでパスワードを変更します。

2. ORACLE_HOME/common/binに移動して、次のコマンドを実行します。

sh wlst.sh

3. WebLogic管理サーバーに接続します。

connect('weblogic_username','pwd', 't3://host:port')

4. 次のupdateCred()コマンドを実行します。

updateCred(map='odssm', key='ODSSM_instance_name', password='newpassword', user='ODSSM')

ここで、instance_nameはインストール時に指定されたインスタンス名(asinst_1など)です。

5. WebLogicドメインの各Oracleインスタンスで、次のコマンド行を実行します。

ORACLE_HOME/ldap/bin/oidcred odssm update [instance_name]

6. 第8.3.4項「opmnctlを使用したOracleインスタンスのコンポーネント登録の更新」に記載のとおり、Oracleインスタンスのコンポーネント登録を更新します。

Oracle Directory Integration Platformがインスタンス内にも構成されている場合、この新しいODSSMパスワードを1つの追加の場所で更新する必要があります。次のようにします。

1. WebLogic管理コンソール(http://host:port/console)にログインします。

2. 「データ・ソース」->「schedulerDS」->「接続プール」を選択します。

3. 画面の左上隅の「ロックして編集」をクリックします。

4. 「パスワード」フィールドおよび「パスワードの確認」フィールドに、新しいパスワードを入力します。
「保存」をクリックします。

5. 「変更のアクティブ化」をクリックします。

注意:
EMAgentの起動後もODSSMアカウントのロックが続く場合、Oracle Internet Directory資格証明ストアで新しいパスワードが正しく更新されていない可能性があります。
次のスクリプトを使用してODSSMパスワードを検証してください。

%perlbin%/perl $ORACLE_HOME/sysman/admin/scripts/iam/getCSFPassword.pl
$ORACLE_HOME $ORACLE_INSTANCE [CANONICAL_PATH] ldap

13 ディレクトリ・エントリの管理

この章では、Oracle Directory Services ManagerおよびLDAPコマンド行ユーティリティを使用して、Oracle Internet Directoryのディレクトリ・エントリを管理する方法について説明します。

この章の内容は次のとおりです。

- 第13.1項「ディレクトリ・エントリの管理の概要」

- 第13.2項「Oracle Directory Services Managerを使用したエントリの管理」

- 第13.3項「LDAPコマンド行ツールを使用したエントリの管理」

13.1 ディレクトリ・エントリの管理の概要

ほとんどのディレクトリの主な機能は、ユーザーに関する情報を格納し、リクエストに応じてこの情報を返すことです。ディレクトリ・サーバーの情報をリクエストするアプリケーションは、サーバーのクライアントと呼ばれます。

管理者は、Oracle Directory Services Managerまたはコマンド行ツールを使用して、ユーザー、グループ、およびその他のタイプのエントリを管理します。

関連項目:
エントリ、オブジェクト・クラスおよび属性の概要は、第3章「Oracle Internet Directoryの概念およびアーキテクチャの理解」を参照してください。

13.2 Oracle Directory Services Managerを使用したエントリの管理

ユーザーやグループなどのエントリを表示するには、Oracle Directory Services Managerのデータ・ブラウザを使用します。

この章では、ユーザーとその他のタイプのエントリについて主に説明します。グループとグループ・エントリの詳細は、第14章「動的グループと静的グループの管理」を参照してください。

この項の項目は次のとおりです。

- 第13.2.1項「Oracle Directory Services Managerを使用したエントリの表示」

- 第13.2.2項「Oracle Directory Services Managerを使用したエントリの検索」

- 第13.2.3項「Oracle Directory Services Managerを使用したLDIFファイルのエントリのインポート」

- 第13.2.4項「Oracle Directory Services Managerを使用したLDIFファイルへのエントリのエクスポート」

- 第13.2.5項「Oracle Directory Services Managerを使用した特定エントリの属性の表示」

- 第13.2.7項「Oracle Directory Services Managerを使用したエントリまたはサブツリーの削除」
第13.2.6項「Oracle Directory Services Managerを使用した新規エントリの追加」

- 第13.2.8項「Oracle Directory Services Managerの既存エントリを利用したエントリの追加」

- 第13.2.9項「Oracle Directory Services Managerを使用したエントリの変更」

関連項目:

- 第30.2.4項「ODSMのデータ・ブラウザを使用したACPの追加または変更」

- 第30.2.5項「ODSMのデータ・ブラウザを使用したエントリ・レベルのアクセスの設定または変更」

エントリに対するアクセス制御の設定または変更の詳細は、これらの項目を参照してください。

13.2.1 Oracle Directory Services Managerを使用したエントリの表示

Oracle Directory Services Managerのデータ・ブラウザを使用してエントリを表示する手順は、次のとおりです。

1. 第7.4.5項「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動し、Oracle Internet Directoryサーバーに接続します。

2. タスク選択バーで、「データ・ブラウザ」を選択します。

3. 必要に応じて、左側のパネルのデータ・ツリーで項目を展開し、各サブツリーのエントリを表示します。
オブジェクト・クラスの中には、データ・ツリーのエントリに汎用アイコンが付けられるものがあります。特定のアイコン付きで表示されるものもあります。次に例を示します。

オブジェクト・クラス

アイコン

ユーザー

グループ

組織単位

組織

ドメイン

国

汎用

エントリにアクセス制御リスト(ACL)が設定されている場合、アイコンが右隣に鍵が表示されたものに変わります。次に例を示します。

オブジェクト・クラス

ACL付きアイコン

ユーザー

グループ

関連項目:
第30章「ディレクトリ・アクセス制御の管理」。

4. 必要に応じて、ツールバーの各アイコンの上にマウスを移動し、アイコンのアクションを確認します。

5. 右側のペインのエントリのみをリフレッシュするには、「エントリのリフレッシュ」アイコンを選択します。選択したエントリの子エントリをリフレッシュするには、「サブツリー・エントリをリフレッシュします」アイコンを選択します。

6. サブツリーに表示されるエントリの数を制限するには、サブツリーのルートにあるエントリを選択し、子エントリのフィルタ・アイコンをクリックし、次のようにフィルタを指定します。

1. 「最大結果数」フィールドで、返されるエントリの最大数を示す1から1000の数値を指定します。

2. 検索基準バーの一番左のリストから、表示するエントリの属性を選択します。

3. 検索基準バーの中央のリストから、フィルタを選択します。

4. 検索基準バーの一番右のテキスト・ボックスに、選択した属性の値を入力します。たとえば、選択した属性がcnの場合は、検索する個々の一般名を入力します。

5. 「+」をクリックし、この検索基準を「LDAP問合せ」フィールドに追加します。

6. 選択したLDAPフィルタを表示するには、「LDAPフィルタの表示」を選択します。

7. 検索基準をさらに詳細に指定するには、論理積(AND、OR、NOT ANDおよびNOT OR)のリストと検索基準バーのリストとテキスト・フィールドを使用して、別の検索基準を追加します。「+」をクリックし、検索基準を「LDAP問合せ」フィールドに追加します。「X」をクリックし、検索基準を「LDAP問合せ」フィールドから削除します。

7. 検索基準の構成を完了した後、「OK」をクリックします。フィルタと一致する子エントリが、選択したエントリの下に表示されます。フィルタはサブツリー全体ではなく、第1レベルの子にのみ適用されます。フィルタを削除するには、「リフレッシュ」アイコンをクリックします。

13.2.2 Oracle Directory Services Managerを使用したエントリの検索

ディレクトリ・エントリを検索する手順は、次のとおりです。

1. 第7.4.5項「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動します。

2. タスク選択バーで、「データ・ブラウザ」を選択します。

3. 単純なキーワード検索を実行するには、「検索」アイコンの横のフィールドにテキストを入力し、検索するキーワードをcn、uid、sn、givenname、mailおよびinitialsの属性で指定します。

4. テキスト・フィールドの右側の「簡易検索」の矢印をクリックし、[Enter]キーを押します。データ・ツリーの下に検索結果が表示されます(見つかった場合)。この検索に関する情報を表示するには、「情報」アイコンをクリックします。結果をリフレッシュするには、「検索結果エントリをリフレッシュします」アイコンをクリックします。検索を終了するには、検索結果を閉じるアイコンをクリックします。

5. より複雑な検索を行うには、「拡張」をクリックします。「検索ダイアログ」が表示されます。

6. 「検索のルート」フィールドに、検索のルートの識別名を入力します。
たとえば、AmericasにあるIMC組織のManufacturing部門に勤務する従業員を検索するとします。検索のルートの識別名は、次のようになります。

ou=Manufacturing,ou=Americas,o=IMC,c=US

この識別名を「検索のルート」テキスト・ボックスに入力します。

データ・ツリーを参照して検索のルートを選択することもできます。この手順は、次のとおりです。

1. 「検索のルート」フィールドの右側の「参照」をクリックします。「識別名(DN)パスの選択:ツリー表示」ダイアログ・ボックスが表示されます。

2. ツリー表示で項目を展開し、そのエントリを表示します。

3. 検索のルートのレベルを表すエントリまで、ナビゲートします。

4. そのエントリを選択して、「OK」をクリックします。検索のルートの識別名が、右側のペインの「検索のルート」テキスト・ボックスに表示されます。

7. 「最大結果件数」ボックスに、検索で取り出すエントリの最大数を入力します。デフォルトは200です。ここで設定できるディレクトリ・サーバーのエントリ数は、最大1000です。

8. 「最長検索時間(秒)」ボックスに、検索の最大時間を秒数で入力します。ここで入力する値は、少なくともデフォルト値の25以上にする必要があります。ここで指定できるディレクトリ・サーバーの最大検索時間は、1時間です。

9. 「検索の深さ」リストで、検索するDITのレベルを選択します。
オプションは次のとおりです。

- ベース: 特定のディレクトリ・エントリを取り出します。この検索レベルの場合は、検索基準バーを使用して、属性objectClassとフィルタ「存在」を選択します。

- 1レベル: 検索のルートの1レベル下から始まるすべてのエントリに検索を制限します。

- サブツリー: 検索のルートを含め、サブツリー全体のエントリを検索します。これはデフォルトです。

10. 検索基準を設定します。
必要に応じて、「LDAPフィルタの表示」を選択し、「LDAP問合せ」テキスト・フィールドに問合せ文字列を直接入力します。

または、検索基準バーのリストとテキスト・フィールドを使用して、検索を絞り込みます。

1. 検索基準バーの一番左のリストから、検索するエントリの属性を選択します。各エントリですべての属性が使用されているわけではないため、指定した属性が、検索しているエントリの属性に実際に一致していることを確認する必要があります。そうでない場合は、検索に失敗します。

2. 検索基準バーの中央のリストから、フィルタを選択します。

3. 検索基準バーの一番右のテキスト・ボックスに、選択した属性の値を入力します。たとえば、選択した属性がcnの場合は、検索する個々の一般名を入力します。

4. 「+」をクリックし、この検索基準を「LDAP問合せ」フィールドに追加します。

5. 選択したLDAPフィルタを表示するには、「LDAPフィルタの表示」を選択します。

6. 検索基準をさらに詳細に指定するには、論理積(AND、OR、NOT ANDおよびNOT OR)のリストと、検索基準バーのリストとテキスト・フィールドを使用して、別の検索基準を追加します。「+」をクリックし、検索基準を「LDAP問合せ」フィールドに追加します。「X」をクリックし、検索基準を「LDAP問合せ」フィールドから削除します。

11. 「検索」をクリックします。データ・ツリーの下に検索結果が表示されます(見つかった場合)。LDAPエラー・アイコンが表示されたら、その上にマウスを移動し、エラーを表示します。必要に応じて、別の基準で再度検索し、エラーを修正します。検索に関する情報を表示するには、「検索フィルタ」アイコンをクリックします。結果をリフレッシュするには、「検索結果エントリをリフレッシュします」アイコンをクリックします。検索結果を閉じるアイコンをクリックすると、検索結果を削除できます。

関連項目:
検索で表示するエントリ数と検索の制限時間の設定方法は、第8.3.6項「opmnctlを使用したアクティブ・サーバー・インスタンスの情報の表示」を参照してください。

13.2.3 Oracle Directory Services Managerを使用したLDIFファイルのエントリのインポート

次のようにして、LDIFファイルからエントリをインポートできます:

1. 第7.4.5項「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動し、Oracle Internet Directoryサーバーに接続します。

2. 「データ・ブラウザ」タブをクリックします。

3. 「LDIFのインポート」アイコンをクリックします。「ファイルのインポート」ダイアログが表示されます。

4. インポートするLDIFファイルへのパスを入力するか、または「参照」をクリックしてファイルにナビゲートし、ブラウザ・ウィンドウで「オープン」をクリックします。

5. 「ファイルのインポート」ダイアログで、「OK」をクリックします。「LDIFのインポート進行状況」ウィンドウに操作の進行が表示されます。「インポート進捗表の表示」を展開して詳細な進捗状況を確認します。
エントリのインポートを停止するには、「取消」をクリックします。すでにインポートされているエントリは中断されません。

データ・ブラウザ・ツリーがリフレッシュされ、新規エントリが表示されます。

13.2.4 Oracle Directory Services Managerを使用したLDIFファイルへのエントリのエクスポート

LDIFファイルにエントリをエクスポートするには、次の手順を実行します。

1. 第7.4.5項「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動し、Oracle Internet Directoryサーバーに接続します。

2. 「データ・ブラウザ」タブをクリックします。

3. エクスポートするサブツリーの最上位レベルの識別名にナビゲートします。

4. 「LDIFのエクスポート」アイコンをクリックします。「エクスポート・ファイル」ダイアログが開きます。操作属性をエクスポートする場合は、「操作属性のエクスポート」を選択します。

5. 「OK」をクリックします。「LDIFファイルのダウンロード」ダイアログが表示されます。デフォルトでは、エントリは、Oracle Directory Services Managerがデプロイされているマシン上の一時ファイルにエクスポートされます。LDIFファイルのコピーをコンピュータに保存する必要がある場合は、「ここをクリックしてLDIFファイルを開きます」をクリックしてファイルを保存します。
「OK」をクリックします。

13.2.5 Oracle Directory Services Managerを使用した特定エントリの属性の表示

特定のエントリの属性を表示する手順は、次のとおりです。

1. 第7.4.5項「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動し、Oracle Internet Directoryサーバーに接続します。

2. 第13.2.2項「Oracle Directory Services Managerを使用したエントリの検索」に記載のとおり、データ・ツリーでエントリに移動するか、検索してエントリを特定します。

3. エントリをクリックします。右側のペインにそのエントリの属性が表示されます。エントリの表示には、「属性」、「サブツリー・アクセス」および「ローカル・アクセス」の少なくとも3つのタブが含まれています。エントリが個人である場合、右側のペインの表示には基本ユーザー情報を示す「個人」タブも表示されます。エントリがグループである場合、表示には基本グループ情報を示す「グループ」タブが表示されます。

4. エントリの属性を表示するには、「属性」タブをクリックします。

5. 「ビュー」リストを使用すると、「管理対象属性」と「すべて表示」を切り替えることができます。

6. 管理対象属性として表示されている属性のリストを変更するには、「オプション属性」のアイコンをクリックします。「すべての属性」リストから「表示された属性」リストに移動する属性を選択し、「移動」および「すべて移動」の矢印を使用して属性を移動します。「表示された属性」リストから「すべての属性」リストに移動する属性を選択し、「削除」および「すべて削除」の矢印を使用して属性を移動します。「属性の追加」をクリックして変更を有効にするか、「取消」をクリックして変更を破棄します。「属性の追加」をクリックすると、「表示された属性」リストにあった属性のみが「管理対象属性」ビューに表示されます。

7. 「サブツリー・アクセス」および「ローカル・アクセス」タブを使用したアクセス制御設定の表示の詳細は、第30.2.4項「ODSMのデータ・ブラウザを使用したACPの追加または変更」を参照してください。

13.2.6 Oracle Directory Services Managerを使用した新規エントリの追加

Oracle Directory Services Managerでエントリを追加または削除するには、親エントリに対する書込みアクセス権限があり、新規エントリの識別名を認識している必要があります。

注意:
エントリを追加または削除する場合、Oracleディレクトリ・サーバーではエントリ属性値の構文検証は行われません。

グループ・エントリを追加するには、第14.2項「Oracle Directory Services Managerを使用したグループ・エントリの管理」の手順に従います。その他のエントリ・タイプについては、次のように進めます。

1. 第7.4.5項「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動し、Oracle Internet Directoryサーバーに接続します。

2. タスク選択バーで、「データ・ブラウザ」を選択します。

3. ツールバーで、「エントリを新規作成します。」アイコンを選択します。または、任意のエントリを右クリックして、「作成」を選択します。
新規エントリの作成ウィザードが表示されます。

4. 新規エントリのオブジェクト・クラスを指定します。「追加」アイコンをクリックし、「オブジェクト・クラスの追加」ダイアログを使用して、オブジェクト・クラスのエントリを選択します。必要に応じて、検索ボックスを使用してオブジェクト・クラスのリストをフィルタリングします。オブジェクト・クラスを追加するには、オブジェクト・クラスを選択して「OK」をクリックします。(このオブジェクト・クラスからtopまでのすべてのスーパークラスも追加されます。)

注意:
Oracle Delegated Administration ServicesのOracle Internet Directoryセルフサービス・コンソールにユーザー・エントリを表示するには、エントリをinetOrgPersonオブジェクト・クラスに割り当てる必要があります。

5. 「エントリの親」フィールドで、作成するエントリの親エントリの完全な識別名を指定できます。「参照」をクリックして、追加するエントリの親の識別名を特定し、選択することもできます。「エントリの親」フィールドを空白のままにすると、ルート・エントリの下にエントリが作成されます。

6. 「次へ」をクリックします。

7. このエントリの相対識別名値となる属性を選択し、その属性の値を入力します。使用するオブジェクト・クラスの必須属性には、それらがRDN値でない場合でも値を入力する必要があります。たとえば、オブジェクト・クラスinetorgpersonの場合、属性cn(一般名)もsn(姓)も相対識別名ではありませんが、必須です。

8. 「次へ」をクリックします。このウィザードの次のページが表示されます。(あるいは、「戻る」をクリックして前のページに戻ります。)

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

10. オプションの属性を管理するには、先ほどデータ・ツリーに作成したエントリに移動します。

11. エントリが個人の場合、「個人」タブをクリックして基本ユーザー属性の管理に使用します。「適用」をクリックして変更を保存するか、「元に戻す」をクリックして変更を破棄します。

エントリがグループの場合は、第14.2項「Oracle Directory Services Managerを使用したグループ・エントリの管理」を参照してください。

12. これが個人のエントリの場合、写真をアップロードできます。「参照」をクリックして写真に移動し、「オープン」をクリックします。写真を更新するには、「更新」をクリックして同じ手順に従います。写真を削除するには、「削除」アイコンをクリックします。

13. オブジェクト・クラスと、個人またはグループ・エントリに固有ではない属性を管理するには、「属性」タブをクリックします。

14. オブジェクト・クラスを追加する手順は、次のとおりです。

1. 「属性」タブをクリックします。

2. objectclassの横の「追加」アイコンをクリックし、「オブジェクト・クラスの追加」ダイアログを使用してオブジェクト・クラスのエントリを選択します。必要に応じて、検索ボックスを使用してオブジェクト・クラスのリストをフィルタリングします。オブジェクト・クラスを追加するには、そのオブジェクト・クラスをクリックして「OK」をクリックします。

15. オブジェクト・クラスを削除する手順は、次のとおりです。

1. 「属性」タブをクリックします。

2. 削除するオブジェクト・クラスを選択します。

3. objectclassの横の「削除」アイコンをクリックします。「オブジェクト・クラスの削除」ダイアログに、そのクラスとともに削除される属性が表示されます。

4. 続行するには「削除」をクリックします。

16. デフォルトでは、空でない属性のみが表示されます。「ビュー」リストを使用すると、「管理対象属性」と「すべて表示」を切り替えることができます。

17. 管理対象属性として表示されている属性のリストを変更するには、「オプション属性」のアイコンをクリックします。「すべての属性」リストから「表示された属性」リストに移動する属性を選択し、「移動」および「すべて移動」の矢印を使用して属性を移動します。「表示された属性」リストから「すべての属性」リストに移動する属性を選択し、「削除」および「すべて削除」の矢印を使用して属性を移動します。「属性の追加」をクリックして変更を有効にするか、「取消」をクリックして変更を破棄します。「属性の追加」をクリックすると、「表示された属性」リストにあった属性のみが「管理対象属性」ビューに表示されます。

18. オプション・プロパティの値を指定します。必須プロパティの値を変更することもできます。複数値属性の場合、「追加」および「削除」アイコンを使用して複数の値を追加および削除できます。

19. 「適用」をクリックして変更を保存するか、「元に戻す」をクリックして変更を破棄します。

20. 「サブツリー・アクセス」および「ローカル・アクセス」タブを使用したアクセス制御の設定の詳細は、第30.2.4項「ODSMのデータ・ブラウザを使用したACPの追加または変更」を参照してください。

13.2.7 Oracle Directory Services Managerを使用したエントリまたはサブツリーの削除

エントリ(サブツリー全体を含む)を削除するには、次の手順を実行します。

1. 第7.4.5項「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動し、Oracle Internet Directoryサーバーに接続します。

2. タスク選択バーで、「データ・ブラウザ」を選択します。

3. 削除するエントリにナビゲートします。

4. このエントリのみを削除するには、「削除」アイコンをクリックします。「削除」ダイアログが表示されたら、「はい」クリックします。このエントリにサブエントリが含まれていない場合、削除は成功します。このエントリにサブエントリが含まれている場合、削除は失敗してODSMにエラー・メッセージが表示されます。エラー・メッセージを終了させるには、「OK」をクリックします。
サブツリー全体を削除するには、「選択したエントリとそのサブツリーを削除します」というラベルが付いたアイコンをクリックします。「サブツリーの削除」ダイアログが表示されたら、ダイアログの内容を読みます。削除を続行するには「はい」をクリックし、中断するには「いいえ」をクリックします。

注意:
多数のエントリを含むサブツリー全体を削除する前に、削除操作のための十分な領域が得られるように復元表領域のサイズを構成します。
詳細は、『Oracle Database管理者ガイド』の「UNDOの管理」を参照してください。

13.2.8 Oracle Directory Services Managerの既存エントリを利用したエントリの追加

Oracle Directory Services Managerでは、既存エントリをコピーしてその識別名を変更する方法で、新規エントリを作成できます。この操作を行う場合は、名前やアドレスなどの属性も、新規識別名に対応するように変更してください。エントリを追加するには、その親に対する書込みアクセス権限が必要です。

ヒント:
検索ペインで他の類似エントリを参照して、新規識別名用のテンプレートを検索できます。

グループ・エントリを追加するには、第14.2項「Oracle Directory Services Managerを使用したグループ・エントリの管理」の手順に従います。その他のエントリ・タイプについては、次のように進めます。

1. 第7.4.5項「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動し、Oracle Internet Directoryサーバーに接続します。

2. タスク選択バーで、「データ・ブラウザ」を選択します。

3. データ・ツリーで、テンプレートとして使用するエントリにナビゲートします。または、「拡張検索」をクリックし、これを使用して、テンプレートとして使用するエントリを検索します。

4. 左側のパネルで、「このエントリに類似したエントリを新規作成します。」アイコンをクリックします。または、テンプレートとして使用するエントリをクリックして右クリックし、「類似作成」を選択します。新規エントリ: 類似作成ウィザードが表示されます。オブジェクト・クラスと親エントリの識別名は、すでに入力されています。

5. オブジェクト・クラスを追加する手順は、次のとおりです。

1. 「属性」タブをクリックします。

2. objectclassの横の「追加」アイコンをクリックし、「オブジェクト・クラスの追加」ダイアログを使用してオブジェクト・クラスのエントリを選択します。必要に応じて、検索ボックスを使用してオブジェクト・クラスのリストをフィルタリングします。オブジェクト・クラスを追加するには、そのオブジェクト・クラスをクリックして「OK」をクリックします。

6. オブジェクト・クラスを削除する手順は、次のとおりです。

1. 「属性」タブをクリックします。

2. 削除するオブジェクト・クラスを選択します。

3. objectclassの横の「削除」アイコンをクリックします。「オブジェクト・クラスの削除」ダイアログに、そのクラスとともに削除される属性が表示されます。

4. 続行するには「削除」をクリックします。

7. テキスト・ボックスの内容を変更するか、「参照」ボタンを使用して別の識別名を見つけることにより、親エントリの識別名を指定します。

8. 「次へ」をクリックします。このウィザードの次のページが表示されます。

9. このエントリの相対識別名値となる属性を選択し、その属性の値を入力します。使用するオブジェクト・クラスの必須属性には、それらがRDN値でない場合でも値を入力する必要があります。たとえば、オブジェクト・クラスinetorgpersonの場合、属性cn(一般名)もsn(姓)も相対識別名ではありませんが、必須です。

10. 「次へ」をクリックします。

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

12. オプションの属性を管理するには、先ほどデータ・ツリーに作成したエントリに移動し、第13.2.6項「Oracle Directory Services Managerを使用した新規エントリの追加」の手順11に進みます。

13.2.9 Oracle Directory Services Managerを使用したエントリの変更

既存エントリに補助型オブジェクト・クラスを追加できます。

注意:
エントリを追加または削除する場合、Oracleディレクトリ・サーバーではエントリ属性値の構文検証は行われません。

グループ・エントリを変更するには、第14.2項「Oracle Directory Services Managerを使用したグループ・エントリの管理」の手順に従います。その他のエントリ・タイプについては、次のように進めます。

1. 第7.4.5項「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動し、Oracle Internet Directoryサーバーに接続します。

2. タスク選択バーで、「データ・ブラウザ」を選択します。

3. データ・ツリーのエントリにナビゲートします。あるいは、第13.2.2項「Oracle Directory Services Managerを使用したエントリの検索」の説明に従って、変更するエントリの検索を実行します。左側のペインの検索結果で、変更するエントリを選択します。

4. 相対識別名を編集するには、データ・ツリーの上の「RDNの編集」アイコンを選択します。あるいは、データ・ツリーでエントリを選択し、右クリックして「RDNの編集」を選択します。
新しいRDN値を指定します。複数値RDNの場合、「古いRDNの削除」チェック・ボックスを使用してRDNを削除するかどうかを指定します。「OK」を選択して変更を保存するか、「取消」を選択して変更を破棄します。

5. オブジェクト・クラスを追加する手順は、次のとおりです。

1. 「属性」タブをクリックします。

2. objectclassの横の「追加」アイコンをクリックし、「オブジェクト・クラスの追加」ダイアログを使用してオブジェクト・クラスのエントリを選択します。必要に応じて、検索ボックスを使用してオブジェクト・クラスのリストをフィルタリングします。オブジェクト・クラスを追加するには、そのオブジェクト・クラスをクリックして「OK」をクリックします。

6. オブジェクト・クラスを削除する手順は、次のとおりです。

1. 「属性」タブをクリックします。

2. 削除するオブジェクト・クラスを選択します。

3. objectclassの横の「削除」アイコンをクリックします。「オブジェクト・クラスの削除」ダイアログに、そのクラスとともに削除される属性が表示されます。

4. 「削除」をクリックして続けるか、「取消」をクリックして削除を取り消します。

7. エントリが個人の場合、「個人」タブをクリックして基本ユーザー属性の管理に使用します。「適用」をクリックして変更を保存するか、「元に戻す」をクリックして変更を破棄します。
エントリがグループの場合は、第14.2項「Oracle Directory Services Managerを使用したグループ・エントリの管理」を参照してください。

8. これが個人のエントリの場合、写真をアップロードできます。「参照」をクリックして写真に移動し、「オープン」をクリックします。写真を更新するには、「更新」をクリックして同じ手順に従います。写真を削除するには、「削除」アイコンをクリックします。

9. 個人またはグループに固有ではない属性の値を変更するには、右側のペインで「属性」タブをクリックし、目的の変更を行います。
デフォルトでは、空でない属性のみが表示されます。「ビュー」リストを使用すると、「管理対象属性」と「すべて表示」を切り替えることができます。

10. 管理対象属性として表示されている属性のリストを変更するには、「オプション属性」のアイコンをクリックします。「すべての属性」リストから「表示された属性」リストに移動する属性を選択し、「移動」および「すべて移動」の矢印を使用して属性を移動します。「表示された属性」リストから「すべての属性」リストに移動する属性を選択し、「削除」および「すべて削除」の矢印を使用して属性を移動します。「属性の追加」をクリックして変更を有効にするか、「取消」をクリックして変更を破棄します。「属性の追加」をクリックすると、「表示された属性」リストにあった属性のみが「管理対象属性」ビューに表示されます。

11. オプション・プロパティの値を指定します。必須プロパティの値を変更することもできます。複数値属性の場合、「追加」および「削除」アイコンを使用して複数の値を追加および削除できます。

12. すべての変更を完了したら、「適用」をクリックして変更を有効にします。あるいは、「元に戻す」をクリックして変更を破棄します。

13. 「サブツリー・アクセス」および「ローカル・アクセス」タブを使用して、このエントリに対してアクセス制御ポイント(ACP)を設定できます。手順は、第30.2.4項「ODSMのデータ・ブラウザを使用したACPの追加または変更」および第30.2.5項「ODSMのデータ・ブラウザを使用したエントリ・レベルのアクセスの設定または変更」を参照してください。

13.3 LDAPコマンド行ツールを使用したエントリの管理

この項の内容は次のとおりです。

- 第13.3.1項「ldapsearchを使用したディレクトリのすべての属性のリスト」

- 第13.3.2項「ldapsearchを使用した操作属性のリスト」

- 第13.3.3項「ldapsearch出力における属性の大/小文字」

- 第13.3.4項「ldapaddを使用したユーザー・エントリの追加」

- 第13.3.5項「ldapmodifyを使用したユーザー・エントリの変更」

- 第13.3.6項「ldapmodifyを使用した属性オプションの追加」

- 第13.3.7項「ldapmodifyを使用した属性オプションの削除」

- 第13.3.8項「ldapsearchを使用した属性オプション付きエントリの検索」

13.3.1 ldapsearchを使用したディレクトリのすべての属性のリスト

次のコマンドラインを使用して、値がないものも含めてすべての属性を表示します。

ldapsearch -p port -h host -D "cn=orcladmin" -q -b "cn=subschemasubentry" \
-s base "objectclass=*"

13.3.2 ldapsearchを使用した操作属性のリスト

デフォルトの場合、ldapsearchは操作属性を返しません。ただし、文字+を検索リクエストの属性リストに追加すると、ldapsearchによってすべての操作属性が返されます。

+を使用したエントリの検索では、操作属性のみが返されます。次に例を示します。

$ ldapsearch -h adc2190517 -p 3060 -D cn=orcladmin -w welcome -b "c=uk" -L -s base "(objectclass=*)" +
dn: c=UK
orclguid: 8EB5730F5852DECBE040E80A7452694E
creatorsname: cn=orcladmin
createtimestamp: 20100826065339z
modifytimestamp: 20100826065339z
modifiersname: cn=orcladmin
orclnormdn: c=uk

比較すると、*を使用するが+は使用しない検索では、すべてのユーザー属性が返されます。

$ ldapsearch -h adc2190517 -p 3060 -D cn=orcladmin -w welcome -b "c=uk" -L -s base "(objectclass=*)"
dn: c=UK
c: uk
objectclass: top
objectclass: country

13.3.3 ldapsearch出力における属性の大/小文字

ldapsearchコマンドからの出力では、インスタンス固有の構成エントリにおける属性orclReqattrCaseが0の場合、属性名は小文字で表示されます。orclReqattrCaseが1に設定されている場合、出力における属性名はコマンド行に入力したものと同じ大/小文字で表示されます。

例:

ldapsearch -h localhost -p 389 -b "dc=oracle,dc=com" -s base -L "objectclass=*" DC

orclReqattrCaseが0の場合、出力は次のようになります。

dn: dc=oracle,dc=com
dc: oracle

orclReqattrCaseが1の場合、出力は次のようになります。

dn: dc=oracle,dc=com
DC: oracle

属性が同じコマンド行で2回以上指定されている場合、出力における属性名は最初の属性仕様の大/小文字と一致します。

13.3.4 ldapaddを使用したユーザー・エントリの追加

次の例では、Johnという従業員のエントリを追加する方法を示します。

ldapaddを次のように使用します。

ldapadd -p port_number -h host -D cn=orcladmin -b -q -f entry.ldif

entry.ldifは次のようになります。

dn: cn=john, c=us
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
cn: john
cn;lang-fr:Jean
cn;lang-en-us:John
sn: Doe
jpegPhoto: /photo/john.jpg
userpassword: password

このファイルには、cn、sn、jpegPhotoおよびuserpasswordの各属性が含まれています。

cn属性については、cn;lang-frとcn;lang-en-usの2つのオプションが指定されます。これらのオプションにより、French(フランス語)またはAmerican English(米語)での一般名が返されます。

jpegPhoto属性では、エントリの属性として組み込む、対応するJPEGイメージのパスとファイル名を指定しています。

注意:

- エントリを追加または削除する場合、Oracleディレクトリ・サーバーではエントリ属性値の構文検証は行われません。

- ユーザー名にチルダ(~)は挿入できません。

13.3.5 ldapmodifyを使用したユーザー・エントリの変更

次の例では、ユーザーのパスワードを新しい値に変更します。前述の例と同様に、このユーザー・エントリ用のデータはentry.ldifファイルに記述されています。このファイルの内容は次のとおりです。

dn: cn=audrey,c=us
changetype: modify
replace: userpassword
userpassword: password

ファイル内のpasswordに新しいパスワードを代入します。

ファイルを変更するには、次のコマンドを発行します。

ldapmodify -p 3060 -D "cn=orcladmin" -q -v -f entry.ldif

-vは冗長モードを指定します。

注意:
エントリを追加または削除する場合、Oracleディレクトリ・サーバーではエントリ属性値の構文検証は行われません。

13.3.6 ldapmodifyを使用した属性オプションの追加

次のエントリでは、Johnに相当するスペイン語のエントリを追加します。このユーザー・エントリのデータはentry.ldifファイルにあります。このファイルの内容は次のとおりです。

dn: cn=john,c=us
changetype: modify
add: cn;lang-sp
cn;lang-sp: Juan

ファイルを変更するには、次のコマンドを発行します。

ldapmodify -D "cn=orcladmin" -q -p 3060 -v -f entry.ldif

13.3.7 ldapmodifyを使用した属性オプションの削除

次の例では、Johnのエントリからcn;lang-fr属性オプションを削除します。前述の例と同様に、このユーザー・エントリ用のデータはentry.ldifファイルに記述されています。このファイルの内容は次のとおりです。

dn: cn=john, c=us
changetype: modify
delete: cn;lang-fr
cn;lang-fr: Jean

ファイルを変更するには、次のコマンドを発行します。

ldapmodify -D "cn=orcladmin" -q -p 3060 -v -f entry.ldif

13.3.8 ldapsearchを使用した属性オプション付きエントリの検索

次の例では、言語コード属性オプションを指定するオプションのある一般名(cn)属性を使用して、エントリを取り出します。この例の場合には、一般名がフランス語で、Rで始まるエントリを取り出します。

ldapsearch -D "cn=orcladmin" -q -p 3060 -h myhost -b "c=US" -s sub "cn;lang-fr=R*"

Johnのエントリで、cn;lang-it言語コード属性オプションに値が設定されていないと想定します。この場合、次の例は失敗します。

ldapsearch -D "cn=orcladmin" -q -p 3060 -h myhost -b "c=us" \
-s sub "cn;lang-it=Giovanni"

関連項目:
第3.4.6項「属性オプション」

ldapsearchに-Xまたは-Bオプションを使用すると、バイナリ値を出力できます。

関連項目:
『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のldapsearchコマンドのリファレンスを参照してください。

14 動的グループと静的グループの管理

この章では、Oracle Directory Services Manager (ODSM)およびLDAPコマンド行ユーティリティを使用して、Oracle Internet Directoryで静的グループと動的グループの両方を管理する方法について説明します。

この章の内容は次のとおりです。

- 第14.1項「動的グループと静的グループの管理の概要」

- 第14.2項「Oracle Directory Services Managerを使用したグループ・エントリの管理」

- 第14.3項「コマンド行を使用したグループ・エントリの管理」

14.1 動的グループと静的グループの管理の概要

Oracle Internet Directoryでは、静的グループと動的グループの2種類のグループでメンバーシップを割り当てて管理できます。各タイプのグループは、それぞれ異なる目的に適しています。

注意:
グループの階層を作成する場合は、第14.1.3項「階層」で説明したとおり、必ず正しい階層にしてください。

関連項目:

- グループ・エントリのアクセス制御ポリシーの設定方法の詳細は、第30.1.1.4項「セキュリティ・グループ」を参照してください。

- アクセス権限の詳細は、第3.8項「グローバリゼーション・サポート」および第30章「ディレクトリ・アクセス制御の管理」を参照してください。

この項の項目は次のとおりです。

- 第14.1.1項「静的グループ」

- 第14.1.2項「動的グループ」

- 第14.1.3項「階層」

- 第14.1.4項「グループ・エントリの問合せ」

- 第14.1.5項「orclMemberOf属性」

- 第14.1.6項「各グループを使用すべき場合」

14.1.1 静的グループ

静的グループは、明示的に管理するメンバーのリストを含むエントリで構成されるグループです。

静的グループに対しては、管理者がそのメンバーシップを明示的に管理する必要があります。たとえば、メンバーが名前を変更した場合、管理者はそのメンバーが属する各グループでそのユーザーの識別名を変更する必要があります。このため、静的グループは、メンバーシップの変更が頻繁に行われないグループに適しています。

14.1.1.1 静的グループ作成のためのスキーマ要素

この種のグループのエントリを作成する場合は、エントリをgroupOfNamesオブジェクト・クラスまたはgroupOfUniqueNamesオブジェクト・クラスのいずれかと関連付けます。

いずれのオブジェクト・クラスにも、グループ・メンバーの名前を格納するための複数値属性があります。ユーザーをグループのメンバーとして割り当てるには、各メンバーの識別名を対応する複数値属性に追加します。逆に、グループからメンバーを削除するには、そのメンバーの識別名を対応する属性から削除します。この複数値属性は、groupOfNamesオブジェクト・クラスではmemberで、groupOfUniqueNamesオブジェクト・クラスではuniqueMemberです。

14.1.2 動的グループ

動的グループは、そのメンバーシップがリストで管理されるのではなく、指定した規則およびアサーションに基づいて計算されるグループです。Oracle Internet Directoryでは、グループのメンバーシップを動的に計算するために次の方法がサポートされています。

- orclDynamicGroupオブジェクト・クラスおよびlabeleduri属性の使用

- orclDynamicGroupオブジェクト・クラスおよびCONNECT_BY属性の使用

- orclDynamicListオブジェクト・クラスおよびlabeleduri属性(動的リストと呼ばれます)の使用

動的グループは、静的メンバーと動的メンバーを持つことができます。静的メンバーは、memberまたはuniquemember属性の値として表示されます。

14.1.2.1 キャッシュされている動的グループおよびされていない動的グループ

動的グループはキャッシュされる場合もされない場合もあります。キャッシュされることにより、動的グループが追加されると、その動的グループのメンバーが計算されて格納され、動的グループを後で変更したときに、メンバー・リストの一貫性が維持されます。エントリが追加、変更、削除されたり、名前の変更が行われたりすると、すべての動的グループのメンバー・リストの一貫性が維持されます。たとえば、c=usの下にすべてのpersonエントリを含む動的グループがある場合、cn=user1,c=usを追加すると、そのエントリは動的グループのメンバー・リストに自動的に追加されます。同様に、cn=user1,c=usを削除すると、エントリは動的グループのメンバー・リストから削除されます。この機能により、動的グループの検索が実行された場合はいつでも、格納されているデータから追加の計算なしでメンバー・リストをフェッチできます。キャッシュされた動的グループの検索パフォーマンスは、静的グループの場合とほぼ同じになります。

キャッシュされる動的グループ

Oracle Internet Directory 10g (10.1.4.0.1)より、labeleduri属性を使用したorclDynamicGroupオブジェクト・クラスに基づく動的グループは、キャッシュされるようになりました

キャッシュされない動的グループ

- CONNECT_BY属性を使用したorclDynamicGroupオブジェクト・クラスに基づく動的グループはキャッシュされません。

- Oracle Internet Directory 11gリリース1(11.1.1.4)以降では、labeleduri属性に基づく動的グループの2番目のタイプを使用できます。これは動的リストと呼ばれ、このメンバーはキャッシュされません。第14.1.2.3項「動的グループ作成のためのスキーマ要素」の説明に従って、グループが関連付けられている補助型オブジェクト・クラスのタイプを選択し、labeleduri属性に基づく動的グループがキャッシュされるかされないかを決定します。キャッシュされるグループが必要な場合は、グループを補助型オブジェクト・クラスorclDynamicGroupに関連付けます。キャッシュされないグループが必要な場合は、グループを補助型オブジェクト・クラスまたはorclDynamicListオブジェクト・クラスに関連付けます。

注意:

- 有効範囲がbaseのlabeledURI属性に基づく動的グループは追加できません。有効範囲subとoneのみがサポートされています。

- orclDynamicGroupオブジェクト・クラスおよびlabeleduri属性を使用して、動的グループのメンバーシップを動的グループに対してリフレッシュするには、DSA構成エントリのorclrefreshdgrmems属性を1に設定します。Oracle Internet Directoryは、すべての動的グループのメンバー・リストを再計算し、orclrefreshdgrmemsの値を0に再設定します。グループが多数ある場合、この操作の完了には時間がかかることがあります。

- あるユーザーが属するグループを問い合せると、labeledURI属性に基づく動的グループは自動的にその結果に含まれます。CONNECT_BYアサーションおよび動的リストに基づく動的グループは、明示的に問い合せる必要があります。たとえば、nc=jdoe,cn=users,o=oracleが、labeleduri動的グループdgrouplab1、CONNECT BY動的グループdgroupcby1および動的リストdlist1の3つのグループのメンバーであると仮定します。検索uniquemember=cn=jdoe,cn=users,o=oracleによって、キャッシュされたlabeleduri動的グループdgrouplab1のみが検索されます。

関連項目:

- Oracle Internet Directoryで使用される制御の詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のLDAP制御に関する説明を参照してください。

- 『Oracle Fusion Middleware Oracle Identity Managementアプリケーション開発者ガイド』の「C API」

- 『Oracle Fusion Middleware Oracle Identity Managementアプリケーション開発者ガイド』の階層検索の実行に関する項

14.1.2.2 Oracle Internet Directoryでの動的グループの拡張機能および制限事項

Oracle Internet Directory 10g(10.1.4.1)以降のリリースでは、動的グループを静的グループと同様に使用できます。たとえば、動的グループは次のもので使用できます。

- アクセス制御リスト。グループをorclACPgroupまたはorclPrivilegeGroupオブジェクト・クラスのいずれかと関連付けます。

- 階層グループ解決の問合せ

動的グループには、Oracle Internet Directoryで次の制限事項があります。

- 階層問合せと、メンバーの特定の属性関連の問合せは、キャッシュされた動的グループに対してのみ行うことができます。

- 動的グループを追加できるのは、ldapaddまたはODSMを使用した場合のみです。bulkloadを使用して追加することはできません。

- labeleduriのLDAPフィルタ部分で使用される属性は、索引付けされている必要があります。第21.3.7項「ldapmodifyを使用した属性の索引付け」、第15.7項「catalogを使用した既存の属性の索引の作成および削除」および第21.1.3.4項「属性の索引付けについて」を参照してください。

- グループを作成した後に、動的グループのオブジェクト・クラスを変更することはできません。グループを削除して再作成する必要があります。

- uniquemember属性の検索では、動的リストまたはCONNECT BYアサーションベースの動的グループは取得されません。

14.1.2.3 動的グループ作成のためのスキーマ要素

動的グループを作成する場合も、静的グループの作成と同様に、まずエントリをgroupOfNamesオブジェクト・クラスまたはgroupOfUniqueNamesオブジェクト・クラスのいずれかに関連付けます。次に、そのオブジェクト・クラスを補助型オブジェクト・クラスorclDynamicGroupまたはorclDynamicListと関連付けます。

この補助型オブジェクト・クラスorclDynamicGroupには、グループのメンバーシップを動的に計算するための2つの方法(labeledURI属性を使用する方法とCONNECT BYアサーションを使用する方法)のいずれかを指定する各種属性があります。補助型オブジェクト・クラスorclDynamicListでは、メンバーシップを計算するlabeledURI属性を使用した方法のみがサポートされています。

メンバーシップを計算する2つの方法は、次のとおりです。

- labeledURI属性を使用する方法
補助型オブジェクト・クラスorclDynamicGroupおよびorclDynamicListには、labeledURI属性が含まれています。グループをorclDynamicGroupに関連付けて、labeledURI属性を使用してメンバーシップを計算する場合、そのグループはキャッシュされます。グループをorclDynamicListに関連付けて、labeledURI属性を使用してメンバーシップを計算する場合、そのグループはキャッシュされません。このorclDynamicListオブジェクト・クラスを使用したキャッシュされないタイプは、動的リストと呼ばれます。

labeledURIの方法を使用する場合、ディレクトリ・サーバーにより、DIT階層に基づいた標準検索が実行されます。この場合、orclDynamicGroupまたはorclDynamicListオブジェクト・クラスの属性(labeledURI)のうちいずれかに対して値を指定する必要があります。この属性では、問合せ、フィルタおよび必要な任意の属性のベースを指定します。たとえば、labeledURI属性に対して次の値を入力したとします。

labeledURI:ldap://host:port/ou=NewUnit,o=MyCompany,c=US??sub?(objectclass=person)

この方法を使用した場合、エントリの検索では、グループの全メンバーのエントリが返されます。

labeledURI属性メソッドを使用する場合は、orclConnectByAttributeやorclConnectByStartingValueを設定しないでください。

注意:
labeledURI属性において、host:portセクションは構文表示専用です。labeledURI属性でのホスト設定およびポート設定にかかわらず、ディレクトリ・サーバーでは、常にローカル・ディレクトリ・サーバーから動的グループのメンバーが計算されます。ここでは、他のディレクトリ・サーバーからメンバーを取得することはできません。

関連項目:
『The LDAP URL Format』(RFC 2255)。T. Howes, M. Smith, December 1997。このRFCでは、labeledURI属性などでLDAP URLを表示する方法について説明しています。これは、http://www.ietf.orgで入手できます。

- CONNECT BYアサーションを使用する方法
labeledURI属性の方法とは異なり、この方法ではDIT階層を使用しないで、エントリを暗黙的に相互接続している属性を、DITでのエントリの位置にかかわらず使用します。たとえば、manager属性により、従業員のエントリがそのマネージャのエントリと接続されるため、この接続はDITでの従業員エントリの位置に関係なく適用されます。この方法では、CONNECT BY句を使用して、階層を作成するために使用する属性(managerなど)およびそのような階層の開始値(cn=Anne Smith,cn=users,dc=example,dc=com)を指定します。

関連項目:
『Oracle Fusion Middleware Oracle Identity Managementアプリケーション開発者ガイド』の階層検索の実行に関する項

具体的には、このメソッドを使用する場合、表14-1に示す単一値属性の各値をorclDynamicGroupオブジェクト・クラスに指定します。

表14-1 Connect ByアサーションのためのorclDynamicGroup属性

属性

説明

orclConnectByAttribute

問合せのフィルタとして使用する属性(例: manager)。この属性は、索引付けされている必要があります。

orclConnectByStartingValue

orclConnectByAttribute属性に指定した属性の識別名。例: cn=Anne Smith,cn=users,dc=example,dc=com

たとえば、米国のMyOrganizational UnitのAnne Smithの部下であるすべての従業員のエントリを取得するには、前述の属性に対して次のような値を設定します。

orclConnectByAttribute=manager
orclConnectByStartingValue=
"cn=Anne Smith,ou=MyOrganizationalUnit,o=MyCompany,c=US"

CONNECT BYアサーション・メソッドを使用する場合は、labeledURIを設定しないでください。

また、すべてのメンバーの特定の属性(email属性など)の値を取得することを指定するアプリケーションを開発することもできます。

関連項目:
特定の属性の値を取得するアプリケーションを開発する方法の詳細は、『Oracle Fusion Middleware Oracle Identity Managementアプリケーション開発者ガイド』を参照してください。

次の例は、2種類の動的グループ・エントリを示しています。

例: labeledURI属性を使用した動的グループ・エントリ

次の例は、labeledURI属性を使用した動的グループ・エントリを示しています。

dn: cn=dgroup1
cn: dgroup1
description: this is an example of a dynamic group
labeleduri:ldap://hostname:7777/ou=oid,l=amer,dc=oracle,
dc=dgrptest??sub?objectclass=person
objectclass: orcldynamicgroup
objectclass: groupOfUniqueNames
objectclass: top

このグループには、サブツリーou=oid,l=amer,dc=oracle,dc=dgrptest内のオブジェクト・クラスpersonに関連付けられている、すべてのエントリの識別名となるuniquemember値が指定されます。

例: labeledURI属性を使用した動的リスト・エントリ

次の例は、labeledURI属性を使用した動的リスト・エントリを示しています。(動的リストはキャッシュされません。)これは、補助型オブジェクト・クラスがorclDynamicGroupではなくorclDynamicListであるという点を除き、前述の例と同じです。

dn: cn=dgroup1
cn: dgroup1
description: this is an example of a dynamic group
labeleduri:ldap://hostname:7777/ou=oid,l=amer,dc=oracle,
dc=dgrptest??sub?objectclass=person
objectclass: orcldynamiclist
objectclass: groupOfUniqueNames
objectclass: top

このグループには、サブツリーou=oid,l=amer,dc=oracle,dc=dgrptest内のオブジェクト・クラスpersonに関連付けられている、すべてのエントリの識別名となるuniquemember値が指定されます。ただし、uniquemember属性の検索では、動的リストは取得されません。

例: CONNECT BYアサーションを使用した動的グループ・エントリ

次の例は、CONNECT_BYアサーションを使用した動的グループ・エントリを示しています。

dn: cn=dgroup2
cn: dgroup2
description: this is connect by manager assertion dynamic group
orclconnectbyattribute: manager
orclconnectbystartingvalue: cn=john doe sr,l=amer,dc=oracle,dc=dgrptest
objectclass: orcldynamicgroup
objectclass: groupOfUniqueNames
objectclass: top

この動的グループは、固有のメンバーとして、manager属性が間接または直接cn=john doe sr.であるすべてのエントリの識別名を値に持ちます。複数の個人の上司としてcn=john doe JR.が指定されており、さらにその上司としてcn=john doe SR.が指定されている場合、下位のすべての個人が返されます。

14.1.3 階層

階層は、明示的または暗黙的のいずれかにできます。

明示的階層では、DITのエントリの位置によって関係が決まります。たとえば、グループAはDITでグループBより上位にあります。

暗黙的階層では、エントリ間の関係は、DIT内の位置によってではなく、特定の属性の値によって決まります。たとえば、John DoeのエントリがAnne Smithと同じレベルの階層にあるDITがあるとします。ただし、John Doeのエントリでは、manager属性にAnne Smithが彼の上司として指定されているとします。この場合、DITでの両方の位置は同レベルですが、Anne SmithはJohn Doeの上司として指定されているため、階層のランクは同一ではありません。

注意:
暗黙的階層に基づく問合せでは、クライアントは検索リクエストに制御2.16.840.1.113894.1.8.3を指定できます。この問合せのフィルタにより、暗黙的階層の作成に使用する属性が指定されます。たとえば、(manager=cn=john doe, o=foo)では、直接的または間接的にJohn Doeの部下であるすべての人への問合せが指定されます。暗黙的階層は、manager属性に基づいています。このような問合せでは、検索のベースは無視されます。
Oracle Internet Directoryで使用される制御の詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のLDAP制御に関する説明を参照してください。

関連項目:
『Oracle Fusion Middleware Oracle Identity Managementアプリケーション開発者ガイド』の「C API」

14.1.4 グループ・エントリの問合せ

アプリケーションは、いずれかのグループに問い合せて、次の操作を実行できます。

- グループのすべてのメンバーをリスト

- あるユーザーがメンバーであるすべてのグループをリスト

- あるユーザーが特定のグループのメンバーであるかどうかをチェック

また、指定するメンバー属性について、動的グループに問合せできますが、静的グループには問合せできません。

関連項目:
『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のLDAP制御に関する説明のGSL_REQDATTR_CONTROLエントリを参照してください。

14.1.5 orclMemberOf属性

orclMemberOfは、そのエントリが属するグループを含む複数値属性です。orclMemberOf内のグループには、静的グループおよびlabeleduriベースの動的グループが含まれています。CONNECT BYアサーションベースの動的グループおよび動的リストは含まれていません。メンバーシップには、直接グループおよびネストされたグループの両方が含まれています。

たとえば、Maryが静的グループdirectorsのメンバーであり、グループdirectorsが静的グループmanagersのメンバーであるとします。MaryのDNで属性orclMemberOfに対して特定の問合せを行った場合、値にはmanagersおよびdirectorsの両方が含まれます。

この属性値は、検索中に計算されず、また格納されません。orclMemberOfは、名前を指定して明示的にリクエストしないかぎり、検索では返されません。

Oracle Internet Directory 11g リリース1(11.1.1.7.0)では、orclMemberOfは検索フィルタで使用できます。複合的なフィルタでは、orclmemberofが非常に役立ちます。以前は、複数のグループに属しているユーザーを検索する最もよい方法は、データをフェッチするために複数の検索問合せを実行した後、結果を計算するためにクライアント側アプリケーションのロジックを使用することでした。検索フィルタでorclmemberofを使用できるようになったので、単一の検索問合せによりこうした処理が可能になりました。いくつかの例には、こうした問合せが含まれます。

orclMemberOfには、Active DirectoryおよびOracle Directory Server Enterprise Edition(以前のSun Java System Directory ServerおよびSunONE iPlanet)との互換性を確保するために、memberofとismemberofという別名があります。これらの別名は代替使用可能であり、orclmemberofのかわりにこの2つの別名を使用してすべての検索問合せを実行することもできます。

注意:
属性orclMemberOfは仮想属性であり、次の目的で使用することはできません。

- 動的なグループまたは動的なリストを作成するためのlabeleduri属性のLDAPフィルタの一部として。

- orclinmemfiltprocessを使用してメモリー内で処理されるフィルタの一部として。orclinmemfiltprocessの詳細は、Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイドのOracle Internet Directoryに関する章を参照してください。

例:

- シングル・ユーザーの検索:

ldapsearch -h host -p 3060 -D binddn -q -b "cn=jdoe,cn=users,o=oracle" -s base "(objectclass=*)" orclmemberof

- memberof別名による検索:

ldapsearch -h host -p 3060 -D binddn -q -b "cn=jdoe,cn=users,o=oracle" -s base "(objectclass=*)" memberof

- すべての属性およびorclmemberofの取得:

ldapsearch -h host -p 3060 -D binddn -q -b "cn=jdoe,cn=users,o=oracle" -s base "(objectclass=*)" orclmemberof  *

- 複数のユーザーの検索:

ldapsearch -h host -p 3060 -D binddn -q -b "cn=users,o=oracle" -s sub "(objectclass=person)" orclmemberof

- 検索フィルタでの使用:

- ユーザーJohn DoeがHR従業員グループのメンバーであるかどうかを判断するには、orclmemberofにHR従業員グループが含まれるかどうかをチェックするフィルタによりユーザーに対するベース検索を実行します。

ldapsearch -h localhost -p 3060 -D binddn -q -b "cn=johndoe,cn=users,o=oracle" -s base "(orclmemberof=cn=hr,cn=groups,o=oracle)" dn

- HR従業員グループのメンバーであるすべてのユーザーを検索するには、orclmemberofにHR従業員グループを含むすべてのエントリについてuserコンテナでサブツリー検索を実行します。

ldapsearch -h localhost -p 3060 -D binddn -q -b "cn=users,o=oracle" -s sub "(orclmemberof=cn=hr,cn=groups,o=oracle)" dn

- 複数のグループのメンバーであるユーザーを検索するには、複数のorclmemberof条件をANDで組み合せるフィルタを使用します。これによって、2つのグループ・メンバーシップの共通部分が得られます。次の検索は、HR従業員およびManagersグループの両方のメンバーであるユーザーを検索します。

ldapsearch -h localhost -p 3060 -D binddn -q -b "cn=users,o=oracle" -s sub "(&(orclmemberof=cn=hr,cn=groups,o=oracle)(orclmemberof=cn=managers,cn=groups,o=oracle))" dn

- HR従業員またはManagersグループのいずれかのメンバーであるユーザーを検索するには、複数のorclmemberof条件をORで組み合せるフィルタを使用します。これによって、2つのグループ・メンバーシップの結合が得られます。3つ以上のグループに対してこの方法を使用することもできます。

ldapsearch -h localhost -p 3060 -D binddn -q -b "cn=users,o=oracle" -s sub "(|(orclmemberof=cn=hr,cn=groups,o=oracle)(orclmemberof=cn=managers,cn=groups,o=oracle))" dn

- HRグループに属し、所在地がカリフォルニアであり、役職がHR Administratorであるすべての従業員を特定するには、次の問合せを使用します。

ldapsearch -h localhost -p 3060 -D binddn -q -b "cn=users,o=oracle" -s sub "(&(orclmemberof=cn=hr,cn=groups,o=oracle)(l=ca)(title=HR Administrator))" dn

- 次の例では、検索フィルタでorclmemberofではなくmemberofの別名を使用しています。

ldapsearch -h localhost -p 3060 -D binddn -q -b "cn=users,o=oracle" -s sub "(memberof=cn=hr,cn=groups,o=oracle)" dn

関連項目:
第18章「別名エントリの管理」

14.1.6 各グループを使用すべき場合

使用するグループについて検討する場合は、管理の容易性とパフォーマンスの効率を比較検討する必要があります。たとえば、動的グループは管理が容易ですが、パフォーマンスが低下します。表14-2に、静的グループを使用すべきか動的グループを使用すべきかを検討する場合の考慮事項を示します。

表14-2 静的グループと動的グループについての考慮事項

考慮事項

静的グループ

動的グループ

管理の容易性

グループのメンバーシップが大きく、頻繁に変更がある場合は管理が困難

特に、グループのメンバーシップが大きく、頻繁に変更がある場合に有効

検索パフォーマンス

メンバーシップ・リストを明示的に管理するため、パフォーマンスが向上

静的グループと比較すると、labeleduriを使用した動的グループの場合にはメンバーシップがキャッシュされるため、パフォーマンスはわずかに劣るレベルかほぼ同等。静的グループおよびキャッシュされる動的グループと比較すると、キャッシュされないグループを使用する場合にはメンバーシップが必要に応じて計算されるため、パフォーマンスが低下。

14.2 Oracle Directory Services Managerを使用したグループ・エントリの管理

静的および動的グループ・エントリを管理するには、Oracle Directory Services Managerの「データ・ブラウザ」ページを使用します。第13.2項「Oracle Directory Services Managerを使用したエントリの管理」の手順に従って、グループ・エントリの表示、グループの検索およびグループの表示を実行できます。グループの作成および変更の手順は、この項で説明します。この項の内容は次のとおりです。

- 第14.2.1項「Oracle Directory Services Managerを使用した静的グループ・エントリの作成」

- 第14.2.2項「Oracle Directory Services Managerを使用した静的グループ・エントリの変更」

- 第14.2.3項「Oracle Directory Services Managerを使用した動的グループ・エントリの作成」

- 第14.2.4項「Oracle Directory Services Managerを使用した動的グループ・エントリの変更」

14.2.1 Oracle Directory Services Managerを使用した静的グループ・エントリの作成

静的グループ・エントリがgroupOfNamesオブジェクト・クラスに属する場合は、複数値属性memberに識別名を追加してグループのメンバーシップを決定します。エントリがgroupOfUniqueNamesオブジェクト・クラスに属する場合は、複数値属性uniqueMemberに識別名を追加してグループのメンバーシップを決定します。

静的グループ・エントリを追加する手順は、次のとおりです。

1. 第7.4.5項「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動し、Oracle Internet Directoryサーバーに接続します。

2. タスク選択バーで、「データ・ブラウザ」を選択します。

3. ツールバーの「エントリを新規作成します。」アイコンを選択します。または、任意のエントリを右クリックして、「作成」を選択します。
あるいは、作成するグループに類似したグループを選択してから、「このエントリに類似したエントリを新規作成します。」アイコンを選択します。または、任意のエントリを右クリックして、「作成」を選択します。

新規エントリの作成ウィザードが表示されます。

4. 新規エントリのオブジェクト・クラスを指定します。「追加」アイコンをクリックし、「オブジェクト・クラスの追加」ダイアログを使用して、groupOfNamesまたはgroupOfUniqueNamesを選択します。(このオブジェクト・クラスからtopまでのすべてのスーパークラスも追加されます。)
「OK」をクリックします。

5. 「エントリの親」フィールドで、作成するエントリの親エントリの完全な識別名を指定できます。「参照」をクリックして、追加するエントリの親の識別名を見つけて選択し、「選択」をクリックすることもできます。
「エントリの親」フィールドを空白のままにすると、ルート・エントリの下にエントリが作成されます。

6. 「次へ」をクリックします。

7. このエントリの相対識別名値となる属性を選択し、その属性の値を入力します。cn属性がRDN値でない場合でも、この値を入力する必要があります。

8. 「次へ」をクリックします。このウィザードの次のページが表示されます。(あるいは、「戻る」をクリックして前のページに戻ります。)

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

10. 所有者またはメンバーを追加するには、先ほどデータ・ツリーに作成したグループ・エントリに移動します。

11. 「グループ」タブを選択します。

12. グループに所有者を追加するには、「所有者」ボックスの横にある「追加」アイコンをクリックします。

13. 所有者のDNを入力するか、またはボタンをクリックして所有者として追加するエントリ(通常はユーザーまたはグループ・エントリ)を識別名パスの選択ダイアログで選択します。
「OK」をクリックします。

14. グループにメンバーを追加するには、「メンバー」テキスト・ボックスの横にある「追加」アイコンをクリックします。

15. メンバーのDNを入力するか、またはボタンをクリックしてメンバーとして追加するエントリ(通常はユーザーまたはグループ・エントリ)を識別名パスの選択ダイアログで選択します。
「OK」をクリックします。

16. 必要に応じてエントリの説明を入力します。

17. 「適用」を選択して変更を適用するか、「元に戻す」を選択して変更を破棄します。

18. グループ・エントリに他の変更を行うには、第14.2.2項「Oracle Directory Services Managerを使用した静的グループ・エントリの変更」を参照してください。

関連項目:

- 第14.1.2項「動的グループ」

- 第30.1.1.4項「セキュリティ・グループ」

- 第3.8項「グローバリゼーション・サポート」

14.2.2 Oracle Directory Services Managerを使用した静的グループ・エントリの変更

グループ・エントリの属性(メンバー・リストなど)を変更する手順は、次のとおりです。

1. データ・ツリーでグループを選択します。

2. 所有者またはメンバーを追加または削除するには、「グループ」タブまたは「属性」タブを選択します。

3. グループにメンバーを追加するには、「メンバー」テキスト・ボックスの横にある「追加」アイコンをクリックします。

4. メンバーとして追加するエントリ(通常はユーザーまたはグループ・エントリ)を識別名パスの選択ダイアログで選択します。
「OK」をクリックします。

5. グループに所有者を追加するには、「所有者」テキスト・ボックスの横にある「追加」アイコンをクリックします。

6. 所有者として追加するエントリ(通常はユーザーまたはグループ・エントリ)を識別名パスの選択ダイアログで選択します。
「OK」をクリックします。

7. 所有者またはメンバーを削除するには、リストで選択し、「削除」アイコンをクリックします。

8. 所有者またはメンバー以外の属性を追加または変更するには、「属性」タブを選択します。

9. デフォルトでは、空でない属性のみが表示されます。「ビュー」リストを使用すると、「管理対象属性」と「すべて表示」を切り替えることができます。

10. 管理対象属性として表示されている属性のリストを変更するには、「オプション属性」のアイコンをクリックします。「すべての属性」リストから「表示された属性」リストに移動する属性を選択し、「移動」および「すべて移動」の矢印を使用して属性を移動します。「表示された属性」リストから「すべての属性」リストに移動する属性を選択し、「削除」および「すべて削除」の矢印を使用して属性を移動します。「属性の追加」をクリックして変更を有効にするか、「取消」をクリックして変更を破棄します。「属性の追加」をクリックすると、「表示された属性」リストにあった属性のみが「管理対象属性」ビューに表示されます。

11. オプション・プロパティの値を指定します。必須プロパティの値を変更することもできます。複数値属性の場合、「追加」および「削除」アイコンを使用して複数の値を追加および削除できます。

12. 「適用」をクリックして変更を保存するか、「元に戻す」をクリックして変更を破棄します。

13. 「サブツリー・アクセス」および「ローカル・アクセス」タブを使用して、このエントリに対してアクセス制御ポイント(ACP)を設定できます。手順は、第30.2.4項「ODSMのデータ・ブラウザを使用したACPの追加または変更」および第30.2.5項「ODSMのデータ・ブラウザを使用したエントリ・レベルのアクセスの設定または変更」を参照してください。

14.2.3 Oracle Directory Services Managerを使用した動的グループ・エントリの作成

動的グループは、静的メンバーと動的メンバーを持つことができます。静的メンバーは、memberまたはuniquemember属性の値として表示されます。動的グループ・エントリがgroupOfNamesオブジェクト・クラスに属する場合は、複数値属性memberに識別名を追加してグループに静的メンバーを追加します。動的グループ・エントリがgroupOfUniqueNamesオブジェクト・クラスに属する場合は、複数値属性uniqueMemberに識別名を追加してグループに静的メンバーを追加します。

動的グループの場合、グループのメンバーシップの算出方法を指定するための属性も設定する必要があります。グループのメンバーシップの動的な計算には、labeledURIまたはCONNECT BYメソッドを選択する必要があります。両方の方法を使用することはできません。labeledURIメソッドを使用する場合は、labeledURI属性を設定する必要がありますが、orclConnectByAttribute属性とorclConnectByStartingValue属性を設定する必要はありません。CONNECT BYメソッドを使用する場合は、orclConnectByAttribute属性とorclConnectByStartingValue属性を設定する必要がありますが、labeledURI属性を設定する必要はありません。

動的グループ・エントリを追加する手順は、次のとおりです。

1. 第7.4.5項「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動し、Oracle Internet Directoryサーバーに接続します。

2. タスク選択バーで、「データ・ブラウザ」を選択します。

3. ツールバーの「エントリを新規作成します。」アイコンを選択します。新規エントリの作成ウィザードが表示されます。

4. 新規エントリのオブジェクト・クラスを指定します。少なくとも次のオブジェクト・クラス・エントリを選択します。

- groupOfNamesまたはgroupOfUniqueNames

- orclDynamicGroupまたはorclDynamicList

labeledURIに基づくキャッシュされる動的グループまたはCONNECT BYに基づく動的グループに対しては、orclDynamicGroupを使用します。labeledURIに基づくキャッシュされない動的リストに対しては、orclDynamicListを使用します。

「追加」アイコンをクリックし、「オブジェクト・クラスの追加」ダイアログを使用して、オブジェクト・クラスのエントリを選択します。必要に応じて、検索ボックスを使用してオブジェクト・クラスのリストをフィルタリングします。オブジェクト・クラスを追加するには、オブジェクト・クラスを選択して「OK」をクリックします。(このオブジェクト・クラスからtopまでのすべてのスーパークラスも追加されます。)

5. 「エントリの親」フィールドで、作成するエントリの親エントリの完全な識別名を指定できます。「参照」をクリックして、追加するエントリの親の識別名を見つけ、「選択」をクリックすることもできます。
「エントリの親」フィールドを空白のままにすると、ルート・エントリの下にエントリが作成されます。

6. 「次へ」をクリックします。

7. このエントリの相対識別名値となる属性を選択し、その属性の値を入力します。cn属性がRDN値でない場合でも、この値を入力する必要があります。

8. 「次へ」をクリックします。このウィザードの次のページが表示されます。(あるいは、「戻る」をクリックして前のページに戻ります。)

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

10. 所有者またはメンバーを追加するには、先ほどデータ・ツリーに作成したグループ・エントリに移動します。(新規エントリを表示するには、「リフレッシュ」アイコンをクリックする必要がある場合があります)。

11. 「グループ」タブを選択します。

12. グループに所有者を追加するには、「所有者」ボックスの横にある「追加」アイコンをクリックします。

13. 所有者として追加するエントリ(通常はユーザーまたはグループ・エントリ)を識別名パスの選択ダイアログで選択します。
「OK」をクリックします。

14. グループにメンバーを追加するには、「メンバー」テキスト・ボックスの横にある「追加」アイコンをクリックします。

15. メンバーとして追加するエントリ(通常はユーザーまたはグループ・エントリ)を識別名パスの選択ダイアログで選択します。
「OK」をクリックします。

16. 必要に応じてエントリの説明を入力します。

17. 「適用」を選択して変更を適用するか、「元に戻す」を選択して変更を破棄します。

18. 「属性」タブを選択します。

19. 「ビュー」リストを使用すると、「管理対象属性」と「すべて表示」を切り替えることができます。

20. 管理対象属性として表示されている属性のリストを変更するには、「オプション属性」のアイコンをクリックします。「すべての属性」リストから「表示された属性」リストに移動する属性を選択し、「移動」および「すべて移動」の矢印を使用して属性を移動します。「表示された属性」リストから「すべての属性」リストに移動する属性を選択し、「削除」および「すべて削除」の矢印を使用して属性を移動します。「属性の追加」をクリックして変更を有効にするか、「取消」をクリックして変更を破棄します。「属性の追加」をクリックすると、「表示された属性」リストにあった属性のみが「管理対象属性」ビューに表示されます。

21. labeledURIメソッドを使用してグループのメンバーシップを動的に計算する場合は、labeledURI属性を設定する必要がありますが、orclConnectByAttribute属性とorclConnectByStartingValue属性を設定する必要はありません。「属性」タブ・ページの「labeledURI」フィールドで、次のように指定します。

ldap:ldap_URL

次に例を示します。

ldap://my_host:3000/ou=MyNeworganizationalUnit,
o=MyCompany,c=US??sub?(objectclass=person)

CONNECT BYメソッドを使用してグループのメンバーシップを動的に計算する場合は、orclConnectByAttribute属性とorclConnectByStartingValue属性を設定する必要がありますが、labeledURI属性を設定する必要はありません。「orclConnectByAttribute」フィールドで、問合せのフィルタとして使用する属性(managerなど)を指定します。「orclConnectByStartingValue」フィールドで、orclConnectByAttribute属性で指定した属性の識別名(cn=Anne Smithなど)を指定します。

「属性」タブ・ページに表示される他の属性の指定方法の詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のユーザーおよびグループ・スキーマ要素に関する説明を参照してください。

22. 「適用」をクリックして変更を保存するか、「元に戻す」をクリックして変更を破棄します。

23. 「サブツリー・アクセス」および「ローカル・アクセス」タブを使用して、このエントリに対してアクセス制御ポイント(ACP)を設定できます。手順は、第30.2.4項「ODSMのデータ・ブラウザを使用したACPの追加または変更」および第30.2.5項「ODSMのデータ・ブラウザを使用したエントリ・レベルのアクセスの設定または変更」を参照してください。

関連項目:

- 「動的グループ」

- 「セキュリティ・グループ」

- 「グローバリゼーション・サポート」

14.2.4 Oracle Directory Services Managerを使用した動的グループ・エントリの変更

グループ内のメンバーシップの動的な計算にはlabeledURIまたはCONNECT BYメソッドを選択する必要があります。両方の方法を使用することはできません。labeledURIメソッドを使用する場合は、labeledURI属性を設定する必要がありますが、orclConnectByAttribute属性とorclConnectByStartingValue属性を設定する必要はありません。CONNECT BYメソッドを使用する場合は、orclConnectByAttribute属性とorclConnectByStartingValue属性を設定する必要がありますが、labeledURI属性を設定する必要はありません。

動的グループ・エントリの属性を変更するには、第14.2.2項「Oracle Directory Services Managerを使用した静的グループ・エントリの変更」の説明に従って、静的グループ・エントリの手順を実行します。静的メンバーを動的グループに追加できますが、そうすることは必須ではありません。

14.3 コマンド行を使用したグループ・エントリの管理

LDAPツールを使用して、コマンド行から静的グループと動的グループを管理できます。この項の内容は次のとおりです。

- 第14.3.1項「ldapaddを使用した静的グループ・エントリの作成」

- 第14.3.2項「ldapmodifyを使用した静的グループの変更」

- 第14.3.3項「ldapaddを使用した動的グループ・エントリの作成」

- 第14.3.4項「ldapmodifyを使用した動的グループの変更」

注意:

- グループを作成する場合、メンバーの指定はオプションです。ここでは完全を期すために示します。

- これに静的メンバーシップが含まれることはまれです。

14.3.1 ldapaddを使用した静的グループ・エントリの作成

LDIFファイルの構文は、次のとおりです。

dn: DN_of_group_entry
objectclass: top
objectclass: groupOfNames | groupOfUniqueNames
member: DN of member 1
member: DN of member 2
.
.
.
member: DN of member N

次のコマンドは、このLDIFファイルのグループおよびメンバーをディレクトリに追加します。

ldapadd -p port_number -h host -D cn=orcladmin -q -f file_name.ldif

例: ldapaddを使用した静的グループ・エントリの作成 次の例は、MyStaticGroupというグループのエントリ用のmyStaticGroup.ldifというLDIFファイルを示しています。

dn: cn=myStaticGroup,c=us
objectclass: top
objectclass: groupOfNames
member: cn=John Doe
member: cn=Anne Smith

次のコマンドは、このLDIFファイルのグループおよびメンバーをディレクトリに追加します。

ldapadd -p 3060 -h myhost -D cn=orcladmin -q -f myStaticGroup.ldif

14.3.2 ldapmodifyを使用した静的グループの変更

グループにメンバーを追加する場合、LDIFファイルの構文は次のようになります。

dn: DN_of_group_entry
changetype: modify
add: member
member: DN of member entry

グループからメンバーを削除する場合、LDIFファイルの構文は次のようになります。

dn: DN of group entry
changetype: modify
delete:member
member:DN of member entry

ファイルを変更するには、次のコマンドを発行します。

ldapmodify -D "cn=orcladmin" -q -p 3060 -v -f file_name.ldif

-vは冗長モードを指定します。

例: ldapmodifyを使用した静的グループの変更 次の例では、John DoeをMyStaticGroupというグループに追加します。前述の例と同様に、このユーザー・エントリに関するデータはmyStaticGroup.ldifファイルに記述されています。このファイルの内容は次のとおりです。

dn: cn=myStaticGroup,c=us
changetype: modify
add:member
member: cn=John Doe

ファイルを変更するには、次のコマンドを発行します。

ldapmodify -D "cn=orcladmin" -q -p 3060 -v -f myStaticGroup.ldif

-vは冗長モードを指定します。

注意:
エントリを追加または変更する場合、Oracleディレクトリ・サーバーではエントリの存在は検証されません。ただし、属性値に識別名を含める必要がある場合、ディレクトリ・サーバーは識別名が指定されていることを検証します。

14.3.3 ldapaddを使用した動的グループ・エントリの作成

コマンド行からldapaddを使用して、動的グループを作成できます。

14.3.3.1 labeledURI属性を使用したキャッシュされた動的グループの作成

labeledURI属性を使用してキャッシュされる動的グループを作成する場合、LDIFファイルの構文は次のとおりです。

dn: DN_of_group_entry
objectclass: top
objectclass: groupOfNames | groupOfUniqueNames
objectclass: orcldynamicgroup
labeledURI:ldap:ldap_URL
member: DN of member 1
member: DN of member 2
.
.
.
member: DN of member N

次のコマンドを使用して、このLDIFファイルのグループおよびメンバーをディレクトリに追加します。

ldapadd -p port_number -h host -f file_name.ldif

14.3.3.2 labeledURI属性を使用したキャッシュされない動的リストの作成

labeledURI属性を使用してキャッシュされない動的リストを作成する場合、LDIFファイルの構文は次のとおりです。

dn: DN_of_group_entry
objectclass: top
objectclass: groupOfNames | groupOfUniqueNames
objectclass: orcldynamiclist
labeledURI:ldap:ldap_URL
member: DN of member 1
member: DN of member 2
.
.
.
member: DN of member N

前述の例と同じコマンドを使用して、このLDIFファイルのグループおよびメンバーをディレクトリに追加します。

ldapadd -p port_number -h host -f file_name.ldif

14.3.3.3 CONNECT BY文字列を使用した動的グループの作成

CONNECT BY文字列を使用する場合、LDIFファイルの構文は次のようになります。

dn: DN_of_group_entry
objectclass: top
objectclass: groupOfNames | groupOfUniqueNames
objectclass: orclDynamicGroup
orclConnectByAttribute:attribute_name
orclConnectByStartingValue:DN_of_attribute
member: DN of member 1
member: DN of member 2
.
.
.
member: DN of member N

この構文でエントリを指定する場合は、識別名を二重引用符で囲まないでください。

次の例は、動的グループのエントリ用のLDIFファイルを示しています。

dn: cn=myDynamicGroup,c=us
objectclass: top
objectclass: groupOfNames
objectclass: orcldynamicgroup
labeledURI:ldap://my_host:3000/ou=MyNeworganizationalUnit,
o=MyCompany,c=US??sub?(objectclass=person)
member: cn=John Doe
member: cn=Anne Smith

次のコマンドは、このLDIFファイルをディレクトリに追加します。

ldapadd -p 3060 -h myhost -f myDynamicGroup.ldif

14.3.4 ldapmodifyを使用した動的グループの変更

前述の例で作成したグループの組織単位を変更する場合、LDIFファイルの構文は次のようになります。

dn: DN_of_group_entry
changetype: modify
replace:labeledURI
labeledURI:ldap://my_host:3000/
ou=MyNeworganizationalUnit,o=MyCompany,c=US??sub?(objectclass=person)

注意:
エントリを追加または削除する場合、Oracleディレクトリ・サーバーではエントリ属性値の構文検証は行われません。

15 バルク操作の実行

この章では、Oracle Internet Directoryのバルク操作を実行して、オブジェクト・クラス、属性、属性別名および属性索引を管理する方法について説明します。また、サーバー・モードを変更する方法や、bulkload、bulkmodify、bulkdelete、カタログ管理ツール、LDAPコマンド行ユーティリティなどのツールを使用してバルク操作を実行する方法について説明します。

この章の内容は次のとおりです。

- 第15.1項「バルク操作の実行の概要」

- 第15.2項「サーバー・モードの変更」

- 第15.3項「bulkloadを使用したスキーマへのデータのロード」

- 第15.4項「bulkmodifyを使用した多数のエントリの属性の変更」

- 第15.5項「bulkdeleteを使用したエントリの削除」

- 第15.6項「ldifwriteを使用したOracle Internet Directoryからファイルへのデータのダンプ」

- 第15.7項「catalogを使用した既存の属性の索引の作成および削除」

15.1 バルク操作の実行の概要

大量のデータを処理する場合は通常、バルク操作は標準的なLDAP操作より効率的です。バルク操作は、コマンド行バルク・ツールを使用してのみ実行できます。

Oracle Identity Managementコマンド行ツールの使用を開始する前に、環境を構成する必要があります。これには、適切な環境変数の設定が含まれます。

このガイドに記載された構文と例を使用するには、環境変数を次のように設定する必要があります。

- ORACLE_HOME - Oracle Identity Managementのインストール内の書込み不可ファイルの場所。

- ORACLE_INSTANCE - Oracle Identity Managementのインストール内の書込み可能ファイルの場所。

- NLS_LANG (APPROPRIATE_LANGUAGE.AL32UTF8) - インストール時のデフォルトの言語セットはAMERICAN_AMERICAです。

- WLS_HOME - WebLogic Serverがインストールされている場所。この環境変数はOracle Directory Integration Platformコマンドには必要ですが、Oracle Internet Directoryコマンドには必要ありません。

- PATH - 次のディレクトリ位置をPATHに追加する必要があります。
ORACLE_HOME/bin

ORACLE_HOME/ldap/bin

ORACLE_HOME/ldap/admin

注意:

- バルク・ツールでは、属性一意性はサポートされていません。

- 11g リリース1(11.1.1.6.0)より前のリリースのインストール中に作成されたスキーマでは、Oracle Internet Directoryに100万エントリを超えて追加する予定がある場合に、OLTS_CT_STOREおよびOLTS_ATTRSTORE表領域にデータファイルを追加する必要があります。この手順は、bulkloadまたはldapadd操作の前に実行します。詳細は、『Oracle Database管理者ガイド』を参照してください。

バルク・ツールについては、この章の他に、次の項でも説明しています。

- 第21.3.9項「カタログ管理ツールを使用した属性の索引付け」

- 第24.1項「ロギングの概要」

- 第37.2項「LDAP準拠のディレクトリからのデータの移行」

- 第40章「レプリケーションの設定」

関連項目:
『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のOracle Internet Directory管理ツールに関する章

注意:

- bulkloadを使用する前に、すべてのOracle Internet Directoryインスタンスを停止してください。他のバルク・ツールを使用する前には、すべてのOracle Internet Directoryインスタンスを停止するか、エントリ・キャッシュを無効にしてください。

- バルク・ツールの実行中は、Oracle Internet Directoryを起動しないでください。

ヒント:
この章の構文説明では、TRUEまたはFALSE引数を次の形式で表します。

check="TRUE"

trueまたはfalseは大文字または小文字で入力することも、先頭の文字のみを指定することも、二重引用符を省略することもできます。つまり、次はすべて同じものを指定します。

check=t
check=true
check="true"
check=T
check=TRUE
check="TRUE"

15.2 サーバー・モードの変更

一部のバルク・ツール操作およびレプリケーション設定手順では、Oracle Internet Directoryインスタンスを読取り/書込みモードから読取り専用モードに、または読取り専用モードから読取り/書込みモードに切り替える必要があります。この切替えは、Oracle Enterprise Manager Fusion Middleware Controlまたはldapmodifyを使用して行うことができます。

サーバーが読取り専用モードの間は、管理者cn=orcladminのみがディレクトリへの書込みを実行できます。このため、ディレクトリを変更するには、cn=orcladminとしての接続を可能にするユーティリティを使用する必要があります。次のポリシーが含まれます。

- Oracle Directory Services Manager

- コマンド行ツール

サーバーが読取り専用モードの間は、WLSTまたはOracle Enterprise Manager Fusion Middleware Controlを使用して変更を実行できません。これらのユーティリティではユーザーcn=emd admin, cn=oracle internet directoryとしてOracle Internet Directoryサーバーに接続するためです。

15.2.1 Fusion Middleware Controlを使用したサーバー・モードの設定

Fusion Middleware Controlを使用してサーバー・モードを読取り専用に設定する手順は、次のとおりです。

1. 「Oracle Internet Directory」メニューから「管理」を選択し、「サーバー・プロパティ」を選択します。

2. 「一般」を選択します。

3. 「サーバー・モード」で「読取り専用」を選択します。

4. 「適用」をクリックします。

Fusion Middleware Controlを使用してサーバー・モードを読取り/書込みモードに設定するには、同じ手順を実行しますが、手順3で「読取り/書込み」を選択します。

15.2.2 ldapmodifyを使用したサーバー・モードの設定

ldapmodifyを使用してサーバー・モードを読取り専用に設定するには、次のコマンドを実行します。

ldapmodify -D "cn=orcladmin" -q -h host_name \
-p port -f change_mode.ldif

ここで、ファイルchange_mode.ldifの内容は次のとおりです。

dn: cn=componentname,cn=osdldapd,cn=subconfigsubentry
changetype: modify
replace: orclservermode
orclservermode: r

ldapmodifyを使用してサーバー・モードを読取り/書込みに設定するには、同じコマンドを使用しますが、LDIFファイルの最終行を次のように変更します。

orclservermode: rw

15.3 bulkloadを使用したスキーマへのデータのロード

バルク・ローダーbulkloadは、バルク管理ツールです。このツールは、LDIFまたはSQL*Loader形式の入力データを取得し、このデータをメタデータ・リポジトリにあるOracle Internet Directoryのスキーマに直接ロードします。これには、check、generateおよびloadの3つの主要フェーズがあります。

checkフェーズでは、bulkloadがLDIF入力データをスキーマのために解析および検証します。

generateフェーズでは、bulkloadがSQL*Loader形式で中間ファイルを生成します。

loadフェーズでは、bulkloadは、バルク・モード・ロードまたは増分モード・ロードのいずれかの方法でロードできます。

- バルク・モード・ロードを使用する場合、bulkloadは生成された中間ファイルをデータベースにロードします。その際、古い索引を削除し、新しい索引を生成します。

- 増分モード・ロードを使用する場合、bulkloadは中間ファイルを挿入モードでデータベースの表にロードします。データをロードする際に、bulkloadは索引を更新します。

バルク・モード・ロードは、増分モード・ロードより高速です。

バルク・ローダーでは、次の機能もサポートしています。

- 生成フェーズとロード・フェーズの間に並列処理ができるように、スレッド数を指定できます。

- データを他の言語で使用できるようにするencodeオプションがあります。

- LDIFファイルで指定した操作属性を保持できるrestoreオプションがあります。

- 索引を再作成するindexオプションと、欠落している索引を作成するmissingオプションがあります。

- bulkloadの失敗からのリカバリに役立つrecoverオプションがあります。

- 既存のディレクトリにデータを追加するとき、bulkloadでは、バルク・モードと増分モードの両方のロードをサポートします。

- appendオプションを使用すると、LDAPサーバーの稼働中にデータをロードできます。

generateフェーズの初めに、インスタンス固有の構成エントリ内のサーバーのorclServerModeが、read/writeからread-modifyに変わります。generateフェーズの終わりには、read-modify状態のままであるため、generateフェーズとloadフェーズの間にエントリをOracle Internet Directoryに追加することはできません。これは内部の順序番号を保持するために必要です。loadフェーズは、generateフェーズの直後に実行します。loadフェーズの終わりに、サーバーのorclServerModeは、read/writeの設定に戻されます。bulkloadをrecoverオプションとともに使用しても、orclServerModeはread/writeに戻ります。

ロード操作の開始時、bulkloadはorclRIenabledの現在の構成値を確認し、参照整合性を無効にします。ロード・フェーズの最後に、bulkloadはorclRIenabledを元の値に戻します。ただし、参照整合性違反があった場合、参照整合性は無効にされ、次のメッセージが表示されます。

There is a violation of Referential Integrity and hence it is Disabled now. Run the OIDDIAG tool with diagnostic option to collect the Entries which have dangling DN attribute values and Fix the violation

違反を修正し、orclRIenabledを希望する値に設定します。

bulkloadツールは、次の出力ファイルをORACLE_INSTANCE/diagnostics/logs/OID/toolsディレクトリに生成します。

- 出力ログ、bulkload.log

- 重複識別名のリスト、duplicateDN.log

- 中間ファイル、*.ctlおよび*.dat

bulkloadツールは、次の出力ファイルをORACLE_INSTANCE/OID/loadディレクトリに生成します。

- 不正なLDIFエントリのリスト、badentry.ldif

- ldapadd、dynGrp.ldifを使用して追加できるすべての動的グループ・エントリのリスト

- SQL*Loaderによって生成された中間ログ・ファイル、bsl_*.log

注意:

- ディレクトリ・サーバー・インスタンスがレプリケーション承諾のメンバーの場合、ノードへのデータの追加にbulkloadツールを使用しないでください。かわりにldapaddを使用してください。

- bulkloadを使用する前に、環境変数ORACLE_INSTANCEがOracleインスタンスのフルパス名に設定されていることを確認してください。

- bulkload load操作を実行すると、サーバー・モードが読取り/書込みに設定されます。別のモードが必要な場合は、load操作の実行後にモードをリセットしてください。

- 適用されるパスワード・ポリシーでpwdmustchange属性が1に設定されている場合、bulkloadによってロードされるすべての新規エントリでは、pwdreset属性がデフォルトで1に設定されます。詳細は、第29章「パスワード・ポリシーの管理」を参照してください。

- ディレクトリへのデータの移入にbulkloadユーティリティを使用しない場合は、oidstats.sqlツールを実行して、検索パフォーマンスの大幅低下を回避する必要があります。

関連項目:
oidstats.sqlツールの説明と構文は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のoidstats.sqlコマンド行ツールのリファレンスを参照してください。

bulkloadツールの構文は、次のとおりです。

bulkload [connect=connect_string]
{[check="TRUE"|"FALSE" [file=ldif_file]] [generate="TRUE"|"FALSE"
[append="TRUE"|"FALSE"] [restore="TRUE"|"FALSE"] [thread=num_of_threads]
file=ldif_file] [load="TRUE"|"FALSE" [append="TRUE"|"FALSE"]
[threads=num_of_threads]] [index="TRUE"|"FALSE"] [missing="TRUE"|"FALSE"]
[recover="TRUE"|"FALSE"]} [encode=character_set] [debug="TRUE"|"FALSE"]
[verbose="TRUE"|"FALSE"]

パラメータの組合せには、有効なものもあれば、無効なものもあります。

環境変数ORACLE_INSTANCEを設定する必要があります。中間ファイルが生成されるOracleインスタンスへの完全修飾パスを設定してください。

bulkloadの起動時には、check、generate、load、append、recoverまたはindexのアクションのうち少なくとも1つを指定する必要があります。

checkがTRUEの場合、bulkloadはスキーマ・チェックを実行します。

generateがTRUEの場合、bulkloadは中間ファイルを生成します。

checkまたはgenerateアクションを使用する場合、LDIFデータ・ファイルへのパス名を指定する必要があります。

loadがTRUEの場合、bulkloadは中間ファイルをロードします。

appendがTRUEの場合、bulkloadはサーバーの稼働中にアクションを実行できます。

restoreフラグは、LDIFファイルにorclguidやcreatorsnameなどの操作属性が含まれる場合にのみ使用します。restoreフラグが指定されていない場合、またはFALSEに設定されている場合は、LDIFファイルに操作属性を含めないでください。

recoverを他のオプションとともに指定しないでください。

check indexのオプションの組合せは、既存の索引を検証します。

15.3.1 bulkloadを使用したLDIFファイルのインポート

LDIFファイルをインポートするには、bulkloadユーティリティを使用します。この項では、bulkloadでLDIFファイルを処理するタスクについて説明します。

関連項目:
『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のbulkloadコマンド行ツールのリファレンス

この項の項目は次のとおりです。

- タスク1: Oracle Internet Directoryプロセスの停止

- タスク2: Oracleデータベース・サーバーのバックアップ

- タスク3: Oracle Internet Directoryのパスワードの準備

- タスク4: スキーマ違反とデータ整合性違反に関する入力チェックとSQL*Loader用の入力ファイルの生成

- タスク5: 入力ファイルのロード

タスク1: Oracle Internet Directoryプロセスの停止

Fusion Middleware Controlまたはコマンド行を使用して、すべてのOracle Internet Directoryサーバー・インスタンスを停止します。

関連項目:
第8章「Oracle Internet Directoryインスタンスの管理」

タスク2: Oracleデータベース・サーバーのバックアップ

ファイルをインポートする前に、安全対策としてOracleデータベース・サーバーをバックアップします。

関連項目:
Oracle Databaseドキュメント・ライブラリの『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』

タスク3: Oracle Internet Directoryのパスワードの準備

bulkloadを使用するには、Oracle Internet DirectoryのODSスキーマのパスワードを指定する必要があります。

関連項目:
『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のoidpasswdコマンド行ツールのリファレンス

タスク4: スキーマ違反とデータ整合性違反に関する入力チェックとSQL*Loader用の入力ファイルの生成

UNIXでは、bulkloadツールは通常は$ORACLE_HOME/ldap/binにあります。Microsoft Windowsでは、このツールは通常はORACLE_HOME\ldap\binにあります。

入力ファイルをチェックし、SQL*Loader用のファイルを生成するには、次のように入力します。

bulkload connect="connect_string" \
check="TRUE" generate="TRUE" file="full_path_to_ldif-file_name"

checkオプションとgenerateオプションの両方を指定すると、エントリのスキーマが正しいかどうかが確認されます。

check関連のすべてのエラーは、コマンド行出力として報告されます。すべてのスキーマ違反が、ORACLE_INSTANCE/diagnostics/logs/OID/tools/bulkload.logに記録されます。すべての不正エントリは、ORACLE_INSTANCE/OID/load/badentry.ldifに記録されます。

エントリが重複している場合は、その識別名がORACLE_INSTANCE/diagnostics/logs/OID/tools/duplicateDN.logに記録されます。これは単に参考のためです。bulkloadツールは、重複するエントリに対して重複データは生成しません。重複エントリは無視されます。

テキスト・エディタを使用してすべての不正エントリを修正し、checkオプションとgenerateオプションを指定してbulkloadを再実行します。エラーがなくなるまで、または許容できるエラーのみになるまで、この手順を繰り返します。たとえば、ldapaddを使用して少数のエントリをロードすると便利な場合があります。

bulkloadツールにより、ORACLE_INSTANCE/OID/loadディレクトリに中間ファイル*.ctlおよび*.datが生成されます。エラーが発生しても、bulkloadは、checkエラーのないエントリに対して中間ファイルを生成します。

bulkloadが正常に完了した場合、または許容できるエラーのみで終了した場合、SQL*Loaderでは中間ファイルをloadモードで使用できます。このファイルは変更できません。

注意:
check関連のエラーを無視する場合は、checkオプションとgenerateオプションを必ず併用してください。checkオプションを使用せずにgenerateオプションを使用すると、検証は行われません。この場合、中間ファイルにはエラーのあるエントリが含まれます。このようなファイルをロードすると、データの不整合や索引作成のエラーが発生することがあります。

タスク5:入力ファイルのロード

入力ファイルの生成後、loadオプションを指定してbulkloadを実行します。この手順で、Oracle SQL*Loader固有の形式の*.datファイルがbulkloadによってデータベースにロードされ、属性索引が作成され、データベース統計が生成されます。構文は次のとおりです。

bulkload connect="connect_string" load="TRUE"

エラーがある場合は、ツールによって画面上に表示されます。ロード時のエラーはすべてORACLE_INSTANCE/diagnostics/logs/OID/toolsディレクトリに報告されます。これらはbulkload.logおよびSQL*Loaderで生成されたファイル*.badとbsl_*.logに記録されます。loadに失敗した場合は、データベースが一貫性のない状態になる可能性があります。bulkloadをrecoverオプションとともに使用するか、bulkloadを起動する前に取ったバックアップからOracle Internet Directoryディレクトリをリストアして、データベースをbulkload操作前の状態に戻します。その後、次のコマンドを繰り返します。

bulkload connect="connect_string" load="TRUE"

索引付けフェーズ中にエラーが発生した場合は、次のコマンドを使用できます。

bulkload coonect="con_str" index=true

このコマンドにより、すべての索引が再作成されます。

データベース統計の生成中にエラーが発生した場合は、oidstats.sqlコマンドを使用して統計を生成できます。

関連項目:
『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のoidstats.sqlコマンドのリファレンス

15.3.2 bulkloadを使用した増分または追加モードでのデータのロード

すでにデータが格納されているOracle Internet Directoryサーバーにエントリを追加し、同時にそのサーバーを稼働させておく場合、増分または追加モードを使用する必要があります。このモードは通常、ディレクトリにエントリを追加する他の方法より高速です。ただし、Oracle Internet Directory LDAPインスタンスが読取り/更新モードであり、bulkloadでデータを追加できることを確認する必要があります。

次のようなコマンドにより、bulkloadを増分または追加モードで起動します。

bulkload connect="conn_str" \
check="TRUE" generate="TRUE" append="TRUE" file="LDIF_file"
bulkload connect="conn_str" \
load="TRUE" append="TRUE"

15.3.3 bulkloadを使用した索引検証の実行

bulkload操作では、索引を更新または作成できます。しかし、bulkloadで索引を正しく更新あるいは作成できないことがあります。これは通常、不適切なサイズ設定などの問題が原因です。このような問題が発生した場合は、bulkloadを使用してすべての索引を検証し、再作成できます。

次の構文を使用して、索引の検証のためにbulkloadを起動します。

bulkload connect="conn_str" \
check="TRUE" index="TRUE"

15.3.4 bulkloadを使用した索引の再作成

索引を再作成するには、次の構文を使用します。

bulkload connect="conn_str" index="TRUE"

15.3.5 bulkloadを使用したロード失敗後のデータのリカバリ

ディスクの不適切なサイズ設定などの問題が原因で、bulkloadのloadフェーズが失敗する可能性があります。そのような失敗の後には、ディレクトリ・データの一貫性がなくなる可能性があります。recoverオプションを使用すれば、ディレクトリ・データをbulkload前の状態に戻せます。構文は次のとおりです。

bulkload connect="conn_str" recover="TRUE"

15.4 bulkmodifyを使用した多数のエントリの属性の変更

bulkmodifyツールは、既存のディレクトリ内にある多数のエントリの属性を変更する場合に役立ちます。これは、属性値に対して追加操作と置換操作を実行できます。ネーミング・コンテキストに対する操作もできます。フィルタを使用すれば、指定したネーミング・コンテキストの下のいくつかのエントリに対して選択的に操作を行うこともできます。

bulkmodifyツールは、次の属性に対してはaddまたはreplace操作を行えません。

- dn (かわりにldapmoddnを使用)

- cn(かわりにldapmodifyを使用)

- userpassword (かわりにldapmodifyを使用)

- orclpassword (かわりにldapmodifyを使用)

- orclentrylevelaci (かわりにldapmodifyを使用)

- orclaci (かわりにldapmodifyを使用)

- orclcertificatehash

- orclcertificatematch

- すべてのバイナリ属性

- すべての操作属性

objectclass属性に対してはreplace操作ができません。

単一値属性にaddは使用できません。

bulkmodifyからの出力は、ORACLE_INSTANCE/diagnostics/logs/OID/tools/bulkmodify.logに記録されます。

関連項目:
『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のbulkmodifyコマンド行ツールのリファレンス

bulkmodifyの構文は、次のとおりです。

bulkmodify connect=connect_string basedn=Base_DN
{[add="TRUE"|"FALSE"]|[replace="TRUE"|"FALSE"]} attribute=attribute_name
value=attribute_value [filter=filter_string] [size=transaction_size]
[threads=num_of_threads] [debug="TRUE"|"FALSE"] [encode=character_set]
[verbose="TRUE"|"FALSE"]

プロセッサ数の1から6倍のスレッド数が必要です。

addまたはreplaceオプションのいずれかを選択します。デフォルトでは、どちらもFALSEに設定されています。

注意:
bulkmodifyを使用する前に、環境変数ORACLE_INSTANCEがOracleインスタンスのフルパス名に設定されていることを確認してください。

15.4.1 指定ネーミング・コンテキストの下の全エントリへの説明の追加

この例では、"c=us"の下のすべてのエントリに説明を追加します。

bulkmodify connect="connect_str" basedn="c=us" add="TRUE" \
attribute="description" value="US citizen" filter="objectclass=*"

15.4.2 フィルタと一致する指定ネーミング・コンテキストの下のエントリへの属性の追加

この例では、Anne Smithがマネージャである"c=us"の下のすべてのエントリにtelephonenumberを追加します。

bulkmodify connect="connect_str" basedn="c=us" add="TRUE" \
attribute="telephoneNumber" \
value="408-123-4567" filter="manager=cn=Anne Smith"

15.4.3 指定ネーミング・コンテキストの下の全エントリの属性の置換

この例では、"c=us"の下のすべてのエントリでpwdresetを置換します。

bulkmodify connect="connect_str"  basedn="c=us" replace="TRUE" \
attribute="pwdreset" value="1" filter="objectclass=*"

15.5 bulkdeleteを使用したエントリの削除

bulkdeleteは、既存のディレクトリ内にある多数のエントリを削除する場合に役立ちます。bulkdeleteは、ネーミング・コンテキストの下で指定したエントリを削除できます。デフォルトでは、エントリを完全に削除します。データベースからエントリのすべての痕跡を削除します。オプションcleandb FALSEを使用すると、bulkdeleteはすべてのエントリを完全に削除するかわりに、ツームストン・エントリに変えます。

bulkdeleteの出力は、ORACLE_INSTANCE/diagnostics/logs/OID/tools/bulkdelete.logに記録されます。

関連項目:
『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のbulkdeleteコマンド行ツールのリファレンス

bulkdeleteツールの構文は、次のとおりです。

bulkdelete connect=connect_string {[basedn=Base_DN] | [file=file_name]}
[cleandb="TRUE"|"FALSE"] [size=transaction_size] [encode=character_set]
[debug="TRUE"|"FALSE"] [threads=num_of_threads] [verbose="TRUE"|"FALSE"]

basednまたはfileオプションのいずれかを選択します。cleandbがTRUEの場合、bulkdeleteはエントリをデータベースから完全に削除します。デフォルトでは、cleandbはTRUEに設定されています。CPU数の1から6倍のスレッド数が必要です。

注意:

- bulkdeleteを使用する前に、環境変数ORACLE_INSTANCEがOracleインスタンスのフルパス名に設定されていることを確認してください。

- 指定したネーミング・コンテキスト内の削除対象のエントリ数が多い場合、『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』の「Oracle Internet Directory」の章に示されているようにOracle Databaseをチューニングする必要があります。

15.5.1 bulkdeleteを使用した指定ネーミング・コンテキストの下の全エントリの削除

この例では、"c=us"の下のすべてのエントリを削除します。

bulkdelete connect="connect_str" basedn="c=us" cleandb="TRUE"

15.5.2 ネーミング・コンテキスト下のエントリの削除とツームストン・エントリとしての設定

この例では、"c=us"の下のすべてのエントリを削除し、それらをツームストン・エントリとして残します。

bulkdelete connect="connect_str" basedn="c=us" cleandb=FALSE

この例では、ファイルで指定された特定のベース識別名の下のすべてのエントリを削除し、それらをツームストン・エントリとして残します。

bulkdelete connect="connect_str" file="file" cleandb=FALSE

15.6 ldifwriteを使用したOracle Internet Directoryからファイルへのデータのダンプ

ldifwriteツールは、Oracle Internet Directoryストアから1つのファイルにデータをダンプするために使用します。データを1ファイルにまとめると、レプリケーションまたはバックアップ・ストレージ用に別のノードへデータをロードすることが容易になります。出力ファイルへの書込みの際に、ldifwriteツールは、指定した識別名の下のすべてのエントリと識別名自体を含むサブツリーの検索を実行します。データをLDIF形式でダンプします。指定したレプリケーション承諾識別名の下のエントリもダンプできます。

ldifwriteツールは、指定したフィルタを使用して検出したエントリをダンプできます。ldifwriteの出力は、ORACLE_INSTANCE/diagnostics/logs/OID/tools/ldifwrite.logに記録されます。

関連項目:
『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のldifwriteコマンド行ツールのリファレンス

ldifwriteツールの構文は、次のとおりです。

ldifwrite connect=connect_string basedn=Base_DN ldiffile=LDIF_Filename
[filter=LDAP_Filter] [threads=num_of_threads] [debug="TRUE"|"FALSE"]
[encode=character_set] [verbose="TRUE"|"FALSE"]

basednオプションを使用して、ベース識別名またはレプリケーション承諾識別名を指定します。

CPU数の1から6倍のスレッド数が必要です。

注意:
ldifwriteを使用する前に、環境変数ORACLE_INSTANCEがOracleインスタンスのフルパス名に設定されていることを確認してください。

15.6.1 一部の指定ネーミング・コンテキストのLDIFファイルへのダンプ

この例では、部分レプリケーションで定義した次のネーミング・コンテキスト・オブジェクトを使用します。

dn: cn=includednamingcontext000001, cn=replication namecontext,
orclagreementid=000001, orclreplicaid=node replica identifier,
cn=replication configuration
orclincludednamingcontexts: c=us
orclexcludednamingcontexts: ou=Americas, c=us
orclexcludedattributes: userpassword
objectclass: top
objectclass: orclreplnamectxconfig

この例では、c=usの下のエントリは、ou=Americas,c=usを除いてすべてバックアップが取られます。userpassword属性も除外されます。コマンドは次のとおりです。

ldifwrite connect="conn_str"  \
basedn="cn=includednamingcontext000001, cn=replication namecontext, \
orclagreementid=000001,orclreplicaid=node replica identifier,\
cn=replication configuration" ldiffile="ldif_file_name"

15.6.2 指定ネーミング・コンテキストの下のエントリのLDIFファイルへのダンプ

この例では、"ou=Europe, o=imc, c=us"の下でLDAP検索フィルタ基準を満たすエントリをすべてoutput.ldifファイルに書き込みます。

ldifwrite connect="connect_str" basedn="ou=Europe, o=imc, c=us"\
filter="uid=abc" ldiffile="output.ldif"

15.7 catalogを使用した既存の属性の索引の作成および削除

Oracle Internet Directory 11g リリース1(11.1.1.6.0)では、新規インストールで新しい自動カタログ機能がデフォルトで有効化されます。以前のリリースからアップグレードした場合も、これを有効にできます。この機能を有効にすると、属性を検索したときに、Oracle Internet Directoryで自動的にcatalogコマンドが起動され、属性が索引付けされます。自動カタログ機能を有効化しないで、カタログ化されていない以前の属性を検索フィルタで使用する場合は、以前のリリースと同様に、その属性をカタログ・エントリに追加する必要があります。

ldapmodifyを使用して、索引を作成および削除できるようになりました。第21.3.7項「ldapmodifyを使用した属性の索引付け」を参照してください。ldapmodifyコマンドによりcatalogが起動し、操作が実行されます。この目的のために引き続きcatalogを使用できます。

catalogツールは、既存の属性の索引を作成する場合や、既存の属性から索引を削除する場合に役立ちます。catalogツールで、属性が検索可能になります。catalogからの出力は、ORACLE_INSTANCE/diagnostics/logs/OID/tools/catalog.logに記録されます。

catalogの構文は、次のとおりです。

catalog connect=connect_string {[add="TRUE"|"FALSE"]|[delete="TRUE"|"FALSE"]}
{[attribute=attribute_name]|[file=file_name]} [logging="TRUE"|"FALSE"]
[threads=num_of_threads] [debug="TRUE"|"FALSE"] [iot="TRUE"|"FALSE"] [verbose="TRUE"|"FALSE"]

addまたはdeleteオプションのいずれかを選択します。デフォルトでは、どちらもFALSEに設定されています。

CPU数の1から6倍のスレッド数が必要です。

loggingがTRUEの場合、catalogはREDOログを生成します。

コマンド行では、一度に1つしかattribute引数を指定できません。1つのコマンドの起動で複数の属性を追加または削除するには、fileオプションを使用し、ファイル内の属性のリストを指定します。次のように、属性を1行ずつ指定します。

description
sn
title

注意:

- Oracle Internet Directory 11g リリース1(11.1.1.6.0)では、LDAPツールldapmodifyを使用して、属性に索引を作成したり、属性から索引を削除することができます。第21.3.7項「ldapmodifyを使用した属性の索引付け」を参照してください。ldapmodifyツールにより実際にはcatalogが起動し、この目的のために引き続きcatalogを使用できます。

- catalogを使用する前に、環境変数ORACLE_INSTANCEがOracleインスタンスのフルパス名に設定されていることを確認してください。

- catalogコマンドは、一度に1000を超える属性の索引を作成できません。1000を超える属性がファイル内に存在すると、ツールによりエラーがスローされます。1000を超える属性の索引を作成する必要がある場合は、複数のファイルを使用します。

- Oracle Internet Directory 11gリリース1(11.1.1.7.0)では、パフォーマンス向上のためにIOTオプションを指定できます。詳細は、Oracle Fusion Middleware Oracle Identity ManagementリファレンスのOracle Internet Directoryデータ管理ツールに関する章を参照してください。

15.7.1 検索可能属性の検索不可能属性への変更

この例では、title属性から索引を削除します。

catalog connect="connect_str" delete="TRUE" attribute="title"

注意:
Oracle Internet Directoryでインストールされたベース・スキーマによって作成された索引ではないことが確信できない場合は、catalog delete=Tオプションを使用して属性から索引を削除しないように注意してください。ベース・スキーマ属性から索引を削除すると、Oracle Internet Directoryの操作に悪影響を及ぼす場合があります。

15.7.2 検索不可能属性の検索可能属性への変更

この例では、title属性に索引を追加します。

catalog connect="connect_str" add="TRUE" attribute="title"

関連項目:

- 第21.3.9項「カタログ管理ツールを使用した属性の索引付け」

- 第21.2.11項「Oracle Directory Services Managerを使用した新規属性への索引の追加」

- 第21.2.12項「Oracle Directory Services Managerを使用した既存の属性への索引の追加」

- 第22.5項「コマンド行を使用した参照整合性に関する特定の属性の構成」

16 集合属性の管理

この章では、Oracle Internet Directoryの集合属性について説明し、LDAPコマンド行ツールを使用してそれらを管理する方法について説明します。

この章の内容は次のとおりです。

- 第16.1項「集合属性の概要」

- 第16.2項「コマンド行を使用した集合属性の管理」

16.1 集合属性の概要

エントリのコレクションで構成されるエントリによって共有される属性は、集合属性と呼ばれます。集合属性の値は表示可能ですが、コレクション内のエントリにアクセスするクライアントによって更新することはできません。管理者は、関連付けられている集合属性サブ・エントリを定義および変更することで、集合属性を管理します。

関連項目:
詳細は、http://www.ietf.orgにあるRFC 3671「Collective Attributes in the Lightweight Directory Access Protocol (LDAP)」およびRFC 3672「Subentries in the Lightweight Directory Access Protocol (LDAP)」を参照してください。

16.1.1 RFCでの定義およびOracleによる拡張

RFC 3671では、集合属性の特定のスキーマについて説明しています。RFCで説明されているのとまったく同じ集合属性スキーマを定義して使用することもできます。ただし、Oracle Internet Directoryでは、より簡単に使用できるように、集合属性の定義を拡張しています。

16.1.1.1 RFC 3671

各集合属性スキーマは、集合サブエントリで使用する前に、RFC 3671に従って定義する必要があります。たとえば、電話番号属性を集合属性として使用する場合は、次のように、ディレクトリでc-telephoneNumberのスキーマを定義します。

( 2.5.4.20.1 NAME 'c-TelephoneNumber' SUP telephoneNumber COLLECTIVE )

また、集合属性は複数値である必要があります。

16.1.1.2 Oracleの拡張機能

使用方法は次のように拡張されています。

- 集合属性用のスキーマ定義は必要ありません。任意の属性を集合属性として使用できます。

- 属性を集合属性にするには、サブタイプcollectiveを使用して集合サブエントリに属性を作成します。

- 集合属性は、複数値または単一値のどちらにすることもできます。

この章のこれ以降の部分では、Oracle Internet Directoryでの使用方法について説明します。

16.1.2 集合属性サブエントリの定義

サブエントリを定義することで、集合属性を作成します。次の例では、dc=mycompany,dc=comの下のエントリに集合サブエントリを定義します。このサブエントリによって、TelephoneNumberおよびpostalCodeが、dc=mycompany,dc=comの下のすべてのエントリに集合属性として含まれるようになります。

Dn: cn=collective attributes, dc=mycompany,dc=com
Cn: collective attributes
Objectclass: subentry
Objectclass: collectiveAttributeSubentry
Objectclass: top
Objectclass: extensibleobject
TelephoneNumber;collective: 1234560000
PostalCode;collective: 98765

16.1.3 subtreeSpecificationの使用

どのエントリが集合属性を実際に取得するかを制御できます。これは、subtreeSpecification属性を集合サブエントリで使用して実行できます。subtreeSpecification属性が集合サブエントリで指定されていない場合、集合属性は、この集合サブエントリが定義されているすべての子エントリ内に含まれています。

関連項目:
subtreeSpecification属性の詳細は、http://www.ietf.orgにあるRFC 3672「Subentries in the Lightweight Directory Access Protocol(LDAP)」を参照してください。

次の3つの項では、subtreeSpecification属性の使用方法の例を示します。

16.1.3.1 ベース

baseキーワードをsubtreeSpecificationで使用して、サブツリーに対する集合属性を制限できます。

たとえば、集合属性をサブツリーcn=users,dc=mycompany,dc=comのみに制限するには、前に示したdc=mycompany,dc=comのサブツリーを使用できますが、次のようにbase値を集合サブエントリのsubtreeSpecification属性に追加します。

SubtreeSpecification: {base "cn=users"}

16.1.3.2 最小および最大

minimumキーワードとmaximumキーワードをsubtreeSpecification属性で使用して、集合属性が適用される、baseのRDN数を制御します。

たとえば、集合属性をou=Americas,cn=users,dc=mycompany,dc=comの下のエントリに追加するが、cn=users,dc=mycompany,dc=comの1レベル下の子エントリ、またはcn=users, dc=mycompany,dc=comから2レベル下の子エントリには追加しない場合は、subtreeSpecificationを次のように定義します。

SubtreeSpecification: {base "cn=users", minimum 2, maximum 4}

この構成では、cn=john doe, ou=Americas,cn=users,dc=mycompany,dc=comは集合属性を取得しますが、cn=inbox,cn=2009,cn=emailFolder,cn=john doe, ou=Americas,cn=users,dc=mycompany,dc=comは集合属性を取得しません。これは、base cn=usersからの距離が4レベルを超えているためです。

16.1.3.3 特定の除外

specificExclusions、chopBeforeおよびchopAfterキーワードを使用して、特定のエントリからさらに集合属性を除外できます。たとえば、集合属性をou=Europeには追加しない場合は、次のようにsubtreeSpecificationを定義します。

SubtreeSpecification: {base "cn=users", minimum 2, maximum 4, specificExclusions { chopBefore: "ou=Europe"} }

集合属性を親の識別名に含めるが、その子エントリには含めない場合、次のような仕様フィルタを定義します。

SubtreeSpecification: {base "cn=users", minimum 2, maximum 4, specificExclusions { chopBefore: "ou=Europe", chopAfter: "cn=Global User" } }

この例では、エントリcn=Global User,ou=all region,cn=users,dc=mycompany,dc=comは集合属性を取得しますが、エントリcn=emailFolder, cn=GlobalUser,ou=all region,cn=users,dc=mycompany,dc=comは集合属性を取得しません。

集合属性を特定のオブジェクト・クラスのみに含める場合は、そのオブジェクト・クラスのオブジェクト識別子または名前をsubtreeSpecicfication属性のspecificationFilterに指定します。たとえば、集合属性をobjectclass personのみに含める場合は、次のように仕様フィルタを定義します。

SubtreeSpecification: {base "cn=users", minimum 2, maximum 4, specificExclusions { chopBefore: "ou=Europe", chopAfter: "cn=GlobalUser"},  specificationFilter item:person }

または、次のように使用することもできます。

SubtreeSpecification: {base "cn=users", minimum 2, maximum 4, specificExclusions { chopBefore: "ou=Europe", chopAfter: "cn=GlobalUser"},  specificationFilter item:2.5.6.6 }

ここで、2.5.6.6はobjectclass personのオブジェクト識別子です。

SpecificationFilterの例

キーワードand、orおよびnotを使用して、次のようにsubtreeSpecicficationをさらに詳細に指定できます。

SubtreeSpecification: {base "cn=users", minimum 2, maximum 4, specificExclusions { chopBefore: "ou=Europe", chopAfter: "cn=GlobalUser"},  specificationFilter and:{ item:2.5.6.6, item:2.5.6.7} }

SubtreeSpecification: {base "cn=users", minimum 2, maximum 4, specificExclusions { chopBefore: "ou=Europe", chopAfter: "cn=GlobalUser"},  specificationFilter or:{ item:2.5.6.6, item:2.5.6.7} }

SubtreeSpecification: {base "cn=users", minimum 2, maximum 4, specificExclusions { chopBefore: "ou=Europe", chopAfter: "cn=GlobalUser"},  specificationFilter not:{ item:2.5.6.7} }

11.1.1.9.0以降では、LDAPフィルタを含むようにspecificationFilterの範囲が拡張されたことで、ターゲットにするエントリをより詳細に制御できます。subtreespecification属性でキーワードfilterを使用するには、次のようにします。

subtreespecification: {base  "ou=people", filter: orclaccountstatus=enabled }

次の例では、フィルタの定義方法について説明します。

dn: cn=building,dc=us,dc=oracle,dc=com
cn: building
subtreespecification: {base "ou=people_grp" , filter: mail=user.1@example.com }
objectclass: top
objectclass: extensibleobject
objectclass: subentry
objectclass: collectiveattributesubentry
street;collective: 200 ABC Street

前述の例で、集合属性値streetが表示されるのは、user.1@example.comというmail属性を持つエントリのみです。

16.1.4 集合属性のオーバーライド

一部のエントリに、集合属性値ではなく独自の属性値を指定する場合、その属性をそれらのエントリに特別に追加し、属性collectiveExclusions:attributeNameをそのエントリに追加します。すべての集合属性を除外する必要がある場合は、属性excludeAllCollectiveAttributes: trueをそれらのエントリに追加します。これにより、集合属性値の値がオーバーライドされます。たとえば、TelephoneNumber属性およびexcludeAllCollectiveAttributes: true属性をエントリcn=jane smith, ou=Americas,cn=users,dc=mycompany,dc=comに追加した場合、このエントリは、集合属性ではなく、独自のTelephoneNumber値を持つようになります。

16.2 コマンド行を使用した集合属性の管理

他のディレクトリ・エントリと同様、コマンド行から集合属性サブエントリを管理できます。

16.2.1 ldapaddを使用したサブエントリの追加

集合属性を作成するには、次のようにldapaddを使用してLDIFファイルに集合サブエントリを定義します。

ldapadd -p port_number -h host -D cn=orcladmin -q -f subentry.ldif

ここで、subentry.ldifの内容は、次のようになります。

Dn: cn=collective attributes, dc=mycompany,dc=com
Cn: collective attributes
Objectclass: subentry
Objectclass: collectiveAttributeSubentry
Objectclass: top
Objectclass: extensibleobject
TelephoneNumber;collective: 1234560000
PostalCode;collective: 98765
SubtreeSpecification: {base "cn=users", minimum 2, maximum 4, specificExclusions { chopBefore: "ou=Europe", chopAfter: "cn=GlobalUser"},  specificationFilter not:{ item:2.5.6.7} }

16.2.2 ldapmodifyを使用したサブエントリの変更

ファイルを変更するには、次のコマンドを発行します。

ldapmodify -p 3060 -D "cn=orcladmin" -q -f mod_subentry.ldif

ここで、mod_subentry.ldifは次のようになります。

dn: cn=collective attributes, dc=mycompany,dc=com
changetype: modify
replace: PostalCode;collective
PostalCode;collective: 98768

17 計算属性の管理

この章では、計算属性について説明し、LDAPコマンド行ツールを使用してOrclComputedAttribute属性を構成し、計算属性を管理する方法について説明します。

この章の内容は次のとおりです。

- 第17.1項「計算属性の概要」

- 第17.2項「計算属性の構成」

- 第17.3項「LDAPコマンド行ツールを使用した計算属性の例」

17.1 計算属性の概要

11gリリース1 (11.1.1.7.0)以降のOracle Internet Directoryサーバーでは、1つ以上のルールに基づいて構成可能な属性およびその値を動的に計算するためのメカニズムとしてOrclComputedAttribute属性を提供しています。したがって、ディレクトリ・ストア内で属性を永続化しなくても、実際に必要なときに属性を計算できます。計算属性は、テストから本番デプロイメントへの移行で役立ちます。

OrclComputedAttribute属性は、DSA構成エントリの構成属性です。

cn=dsaconfig,cn=configsets,cn=oracle internet directory

OrclComputedAttributeは、複数値属性であるため、複数の属性とその個々の値を動的に計算できます。

OrclComputedAttribute値は、ルールで定義される次の項目または次の項目の組合せから導出できます。

- RFC 4516で定義された標準LDAP URI

- 事前に決定された文字列

- 属性値

- 属性値の関数

- 11gリリース1 (11.1.1.9.0)以降では、2つ以上のエントリから属性を取得するため、connectBy句を含めることができます。この機能では、PRIOR式を含むSQLのCONNECT BY条件という基礎となるデータベース機能を使用します。
たとえば、組織でconnectBy句を使用して、実際には従業員のレコードにマネージャのデータを永続化することなく、従業員レコードに従業員のマネージャの情報(メールや電話番号などの連絡先情報)を含めることができます。

次に、OrclComputedAttributeを使用する場合の考慮事項をいくつか示します。

- 計算属性の名前は、スキーマで定義する必要があります。

- 計算属性には、値の復帰を抑止するアクセス制御ポリシーが存在する場合があります。

- 計算属性は、ルックアップおよび検索操作のためにのみ取得されます。結果エントリに構成済計算属性がある場合、Oracle Internet Directoryサーバーでは属性計算がスキップされます。

- エントリ内の既存値を削除または置換する更新操作が可能です。

17.2 計算属性の構成

ldapmodify、Oracle Directory Services Manager (ODSM)、サード・パーティLDAPブラウザなどのLDAPツールを使用してOrclComputedAttributeを構成できます。

この項では、次の内容を説明します。

- 第17.2.1項「計算属性に使用されるルールおよび構文」

- 第17.3項「LDAPコマンド行ツールを使用した計算属性の例」

17.2.1 計算属性に使用されるルールおよび構文

計算属性のルールでは、次の構文を使用して属性値を計算します。

OrclComputedAttribute;ComputedAttrName;dn;Filter: ldapURI

OrclComputedAttribute;ComputedAttrName;dn;Filter: "anyString"

OrclComputedAttribute;ComputedAttrName;dn;Filter: AttributeName

OrclComputedAttribute;ComputedAttrName;dn;Filter: Func(attrName)

OrclComputedAttribute;ComputedAttrName;dn;Filter: connectBy(dnAttr,Direction,Level,[computed-attribute-rules],ldapFilter)

表17-1で、こうしたルールで使用される要素について説明します。

これらのルールの組合せを使用して値を計算する場合、第17.2.1.1項「計算属性のルールでの特殊文字の使用」を参照してください。

表17-1 計算属性のルールで使用される構文要素

要素

説明

ComputedAttrName

エントリで返される属性の名前。計算属性の名前は、スキーマで定義する必要があります。またこの属性は、値の計算後にACL評価の対象になります。

dn

識別名。属性は、このDNの子エントリについて計算されます。

Filter

フィルタ値。属性は、このフィルタ値に属するエントリについて計算されます。

ldapURI

RFC 4516に記載された構文に準拠する次のようなURI。

ldap:///baseDN?ReqdAttribute??scope?filter

ReqdAttributeは、必須属性の単一の属性名です。

ldapURI構成に空白文字が含まれる場合、RFC 4516に記載されているように、空白を%20としてエンコードする必要があります。

"anyString"

含める文字列。二重引用符で囲む必要があります。

AttributeName

属性値を示す属性名を使用する必要があります。

Func(attr)

値に対して実行する関数の名前。次のファンクションを使用できます。

lower(attrName)

upper(attrName)

substr(attrName,pos,len)

replace(attrName,"str")

trunc(attrName, "c")

NVL(attr, "StringVal")

注意: NVL関数では、attr属性がエントリから欠落している場合、Oracle Internet Directoryサーバーによって、デフォルトの文字列値StringValを使用して計算属性が生成されます。

connectBy

connectBy句では次の構文を使用します。

connectBy(dnAttr,Direction,Level,[computed-attribute-rules],ldapFilter)

- dnAttrは、ターゲット・エントリの属性の識別名構文です。例: manager、ownerまたはuniquemember。これは必須パラメータです。

- Directionは、結果を返すディレクトリの方向です。
0 - 下位方向

1 - 上位方向

これは必須パラメータです。

- Levelは、結果を返すディレクトリの下位方向または上位方向の再帰レベルの数です。これは必須パラメータです。

- computed-attribute-rulesは、connectBy句の結果としてフェッチされる各エントリに適用されます。これらのルールは、大カッコ[]で囲まれています。これはオプション・パラメータです。

- ldapFilterでは、フィルタ条件がターゲット・エントリで一致する場合にのみ、計算属性が生成されます。これはオプション・パラメータです。

17.2.1.1 計算属性のルールでの特殊文字の使用

計算属性のルールで特殊文字を使用する場合の考慮事項は、次のとおりです。

- 複数のルールを指定する場合、各ルールを区切るために空白文字を使用する必要があります。

- ルールまたは文字列を追加または連結するには、プラス記号(+)を使用します。

- 第1のルール評価の結果により値を決定するには、OR演算子(|)を使用します。

- アスタリスク(*)はワイルドカード文字であり、ldapURI内でのみ使用できます。この演算子がURIのDN部分で表示される場合、*はエントリのDNを評価する有効範囲から導出されたものです。

17.3 LDAPコマンド行ツールを使用した計算属性の例

この項では、計算属性の次の例を示します。

- 第17.3.1項「属性値の大文字での返却」

- 第17.3.2項「属性値の部分文字列の返却」

- 第17.3.3項「属性値の置換」

- 第17.3.4項「URIベースの構成の指定」

- 第17.3.5項「様々なルールの組合せの使用」

- 第17.3.6項「OR(|)演算子の使用」

- 第17.3.7項「connectByインタフェースの使用」

- 第17.3.8項「connectByを使用した階層グループの作成」

17.3.1 属性値の大文字での返却

次の例ではcn属性を大文字として計算し、upperattrとして属性を返します。

dn: cn=dsaconfig,cn=configsets,cn=oracle internet directory
changetype: modify
add: orclcomputedattribute;upperattr;dc=acme,dc=com;objectclass=person
orclcomputedattribute;upperattr;ou=EuroSInet Suite,o=IMC,c=US;objectclass=person: upper(cn)

upperattrのスキーマ定義を定義する必要があります。

17.3.2 属性値の部分文字列の返却

次の例では、属性値の部分文字列を計算し、位置1から次の3文字のdescription値としての値を含む属性substrattrを返します。

dn: cn=dsaconfig,cn=configsets,cn=oracle internet directory
changetype: modify
add: orclcomputedattribute;substrattr;dc=acme,dc=com;objectclass=person
orclcomputedattribute;substrattr;dc=acme,dc=com;objectclass=person: substr(description, 1,3)

17.3.3 属性値の置換

次の例では、newTitleの属性値を計算して置換します。

dn: cn=dsaconfig,cn=configsets,cn=oracle internet directory
changetype: modify
add: orclcomputedattribute;newTitle;cn=john doe,dc=acme,dc=com;objectclass=person
orclcomputedattribute;newTitle;ou=EuroSInet Suite,o=IMC,c=US;objectclass=person:  replace(title, "Clerk", "Manager")

17.3.4 URIベースの構成の指定

次の例では、dc=acme,dc=comの下にある各エントリにcommonTelephoneNumberを追加します。

dn: cn=dsaconfig,cn=configsets,cn=oracle internet directory
changetype: modify
add: orclcomputedattribute;commonTelephoneNumber;dc=acme,dc=com;objectclass=person
orclcomputedattribute;commonTelephoneNumber;dc=acme,dc=com,c=US;objectclass=person: "Common PhoneNumber is " +
ldap:///cn=common%20attributes,dc=com?telephonenumber??base?objectclass=*

17.3.5 様々なルールの組合せの使用

空白文字によって区切られた様々なルールを+(プラス記号)を使用して連結します。

dn: cn=dsaconfig,cn=configsets,cn=oracle internet directory
changetype: modify
add: orclcomputedattribute;combinationAttribute;ou=EuroSInet Suite,o=IMC,c=US;objectclass=person
orclcomputedattribute;combinationAttribute;dc=acme,dc=com;objectclass=person: "telephone number from common entry:" +  ldap:///cn=common Entry,?telephonenumber??base?objectclass=* +
" appending replace of title attr with clerk/manager " +
replace(title, "Clerk", "Manager")

dn: cn=dsaconfig,cn=configsets,cn=oracle internet directory
changetype: modify
add: orclcomputedattribute;combinationAttr2;dc=acme,dc=com;objectclass=person
orclcomputedattribute;combinationAttr2;dc=acme,dc=com;objectclass=person: "Telephone number  from common entry " +
ldap:///cn=commonEntry,dc=acme,dc=com?telephonenumber??base?objectclass=* +
" appending truncate of description for space char " + trunc(description, " ")

17.3.6 OR(|)演算子の使用

エントリにtelephoneNumber属性がある場合はcontactNumber属性をtelephoneNumberとして追加し、それ以外の場合は値6505067000をコピーします。

dn: cn=dsaconfig,cn=configsets,cn=oracle internet directory
changetype: modify
add: orclcomputedattribute;contactNumber;cn=employees,dc=acme,dc=com;(objectclass=person)
orclcomputedattribute;contactNumber;cn=employees,dc=acme,dc=com;(objectclass=person): telephonenumber | 6505067000

注意:
OR演算子(|)については、計算属性定義では次の構文がサポートされます。

definition-1 | definition-2 | ... definition-n

各項目の意味は次のとおりです。

- definition-1は複合的なルールでもかまいません。

- definition-2からdefinition-nは、ハードコード化された文字列や属性値などの簡単なルールのみであることが必要です。これらの定義で、関数式または式ルールの組合せを使用することはできません。

たとえば、次のルールでは、エントリに対するuidが存在しない場合に、その結果はエントリ内の属性cnの発生数にかかわりなく、計算値"cn="になります。

orclcomputedattr;myattr;cn=employees;(objectclass=inetorgperson): "uid=" + uid | "cn=" + cn

17.3.7 connectByインタフェースの使用

次の例では、ターゲット・エントリの属性(manager)からの値が割り当てられ、ディレクトリの下位方向の最大10レベルでそのマネージャのレポートのAllReports計算属性が生成されます。マネージャのDNは次のとおりです。

dn: uid=Manager,ou=people,dc=us,dc=example,dc=com

dn: cn=dsaconfig,cn=configsets,cn=oracle internet directory
changetype: modify
add: orclcomputedattribute;AllReports;dc=com;objectclass=person
orclcomputedattribute;AllReports;dc=com;objectclass=person:connectby(manager,0,10)

各計算属性には、個々の従業員のuidが含まれます。次に例を示します。

AllReports=uid=employee1,ou=people,dc=us,dc=example,dc=com
...
AllReports=uid=employee6,ou=people,dc=us,dc=example,dc=com

次の例では、ディレクトリの上位方向の最大15レベルで各従業員のAllManagers計算属性が生成されます。DNは次のとおりです。

dn: uid=manager,ou=people,dc=us,dc=example,dc=com

dn: cn=dsaconfig,cn=configsets,cn=oracle internet directory
changetype: modify
add: orclcomputedattribute;AllManagers;dc=com;objectclass=person
orclcomputedattribute;AllManagers;dc=com;objectclass=person: connectBy(manager,1,15, [ "EmpNum " + employeenumber + " " + upper(orclnormdn) ])

各計算属性には、個々のマネージャのemployeenumberと、エントリの正規化された識別名(orclnormdn属性)が大文字で含まれます。次に例を示します。

AllManagers=EmpNum1 UID=NAME1,OU=PEOPLE,DC=US,DC=EXAMPLE,DC=COM
...
AllManagers=EmpNum5 UID=NAME5,OU=PEOPLE,DC=US,DC=EXAMPLE,DC=COM

次の例は、前述の例にフィルタ(objectclass=inetorgperson)が追加されています。

dn: cn=dsaconfig,cn=configsets,cn=oracle internet directory
changetype: modify
add: orclcomputedattribute;AllManagers;dc=com;objectclass=person
orclcomputedattribute;AllManagers;dc=com;objectclass=person:connectBy(manager,1,15, [ "EmpNum " + employeenumber + " " + upper(orclnormdn) ],
(objectclass=inetorgperson))

17.3.8 connectByを使用した階層グループの作成

次の例は、再帰(階層)グループのconnectBy句を示しています。

dn: cn=dsaconfig,cn=configsets,cn=oracle internet directory
changetype: modify
add: orclcomputedattribute;uniquemember;dc=com;objectclass=groupOfUniquenames
orclcomputedattribute;uniquemember;dc=com;objectclass=groupOfUniquenames:connectBy(uniquemember,1,25, [uniquemember])

次の例は、Oracle Internet Directoryサーバーによって計算された静的グループと階層グループを示しています。マネージャの直属の部下を含む2つの静的グループ・エントリが追加されています。

グループ・エントリに静的な一意のメンバーが格納されている場合、この例によって、uniquemember属性のディレクトリの上位方向にネストされた結果が返されます。次に例を示します。

dn: cn=manager1_org,cn=groups,dc=us,dc=example,dc=com
objectclass: groupofuniquenames
objectclass: top
cn: manager1_org
uniquemember: uid=manager1,ou=People,dc=us,dc=example,dc=com
uniquemember: uid=emp1,ou=People,dc=us,dc=example,dc=com
uniquemember: uid=emp2,ou=People,dc=us,dc=example,dc=com
uniquemember: uid=emp3,ou=People,dc=us,dc=example,dc=com
uniquemember: uid=emp4,ou=People,dc=us,dc=example,dc=com
uniquemember: cn=emp2_org,cn=groups,dc=us,dc=example,dc=com

および

dn: cn=emp2_org,
cn=groups,dc=us,dc=example,dc=com
objectclass: groupofuniquenames
objectclass: top
cn: emp2_org
uniquemember: uid=emp5,ou=People,dc=us,dc=example,dc=com
uniquemember: uid=emp6,ou=People,dc=us,dc=example,dc=com

エントリ"cn=manager1_org,cn=groups,dc=us,dc=example,dc=com"が検索されると、Oracle Internet Serverサーバーによってuniquemember属性が再帰的に自動計算されます。次に例を示します。

cn=manager1,cn=groups,dc=us,dc=example,dc=com
uniquemember=cn=emp2_org,cn=groups,dc=us,dc=example,dc=com
uniquemember=uid=manager1,ou=people,dc=us,dc=example,dc=com
uniquemember=uid=emp1,ou=people,dc=us,dc=example,dc=com
uniquemember=uid=emp2,ou=people,dc=us,dc=example,dc=com
uniquemember=uid=emp3,ou=people,dc=us,dc=example,dc=com
uniquemember=uid=emp4,ou=people,dc=us,dc=example,dc=com
uniquemember=uid=emp5,ou=people,dc=us,dc=example,dc=com
uniquemember=uid=emp6,ou=people,dc=us,dc=example,dc=com

18 別名エントリの管理

この章では、Oracle Internet Directoryの別名エントリについて説明し、LDAPコマンド行ツールを使用して別名エントリを追加、検索および変更する方法について説明します。また、別名間接参照に関するメッセージを解釈する方法についても説明します。

この章の内容は次のとおりです。

- 第18.1項「別名エントリの管理の概要」

- 第18.2項「別名エントリの追加」

- 第18.3項「別名エントリによるディレクトリの検索」

- 第18.4項「別名エントリの変更」

- 第18.5項「別名間接参照に関するメッセージの解釈」

属性別名の詳細は、第21.1.5項「属性別名の理解」を参照してください。

18.1 別名エントリの管理の概要

エントリの中には、長く複雑な識別名を持つものがあります。Oracle Internet Directoryでは別名オブジェクトを使用して長い名前の管理を容易にします。別名を使用してオブジェクトを検索(参照)すると、別名が間接参照され、その別名が指し示すオブジェクトが返されます。たとえば、別名Server1は、完全修飾された識別名dc=server1,dc=us,dc=myCompany,dc=comを指し示すように間接参照できます。この機能によって、厳密には階層構造でない構造も開発できます。

別名エントリは、オブジェクト・クラスaliasを使用して、ディレクトリ内のオブジェクト・エントリと区別します。このオブジェクト・クラスの定義は次のとおりです。

(2.5.6.1 NAME 'alias' SUP top STRUCTURAL MUST aliasedObjectName)

別名エントリにはaliasedObjectName属性も含まれており、この属性には、別名が指し示すオブジェクトの識別名が含まれています。この属性の定義は次のとおりです。

(2.4.5.1 NAME 'aliasedObjectName" EQUALITY distinguishedNmameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE)

注意:
aliasedObjectName属性は、ディレクトリ情報ツリー(DIT)・ビューの識別名を参照できません。

図18-1およびその後に続く説明では、別名エントリの間接参照の例を示します。

図18-1 別名エントリの例

図18-1で、ou=uk sales,ou=global sales,o=myCompany,c=usは、ou=sales,o=myCompany,c=ukエントリを指し示す別名エントリです。

ou=uk sales,ou=global sales,o=oracle,c=usを参照すると、その参照は、ディレクトリ・サーバーによって実際のエントリou=sales,o=oracle,c=ukに自動的に変更されます。

18.2 別名エントリの追加

別名エントリを追加するには、LDIFの通常のエントリ、および実際のエントリを指し示す別名エントリを作成します。この例の手順を実行すると、図18-2に示すツリーが生成されます。

1. 次のエントリを持つサンプルLDIFファイルMy_file.ldifを作成します。

dn: c=us
c: us
objectclass: country

dn: o=MyCompany, c=us
o: MyCompany
objectclass:organization

dn: ou=Area1, c=us
objectclass: alias
objectclass: extensibleobject
ou: Area1
aliasedObjectName: o=MyCompany, c=us

dn: cn=John Doe, o=MyCompany, c=us
cn: John Doe
sn: Doe
objectclass: person

dn: cn=President, o=MyCompany, c=us
objectclass: alias
objectclass: extensibleobject
cn: President
aliasedobjectname: cn=John Doe, o=MyCompany, c=us

2. 次のコマンドを使用して、これらのエントリをディレクトリに追加します。

ldapadd -p port -h host -D cn=orcladmin -q -f My_file.ldif

注意:
親が別名エントリである別名エントリを追加しようとすると、ディレクトリ・サーバーはエラーを返します。

関連項目:
エラー・メッセージは、第18.5項「エントリ別名間接参照メッセージ」を参照してください。

図18-2 My_file.ldifの作成結果を示すツリー

図18-2の文字Aは、別名エントリを表します。

- ou=Area1は、o=MyCompanyを指し示す別名です。

- cn=Presidentは、cn=John Doeを指し示す別名です。

18.3 別名エントリによるディレクトリの検索

指定する検索ごとに設定できるフラグがあります。表18-1に示すように、検索は指定したフラグに基づいて実行されます。

表18-1 別名エントリによるディレクトリの検索のフラグ

フラグ

LDAPサーバーの検索の動作

-a never

別名を間接参照しません。

-a find

検索でベース・オブジェクトを間接参照しますが、そのベースの下にある別名エントリは間接参照しません。

-a search

検索でベース・オブジェクトの下位にある別名は間接参照しますが、検索のベース・オブジェクトのロケーティングでは別名を間接参照しません。

-a always

検索で別名を間接参照し、検索のベース・オブジェクトのロケーティングでも別名を間接参照します。

デフォルトでは、ldapsearchの間接参照フラグは-a neverで、ディレクトリ・サーバーは別名エントリに対する間接参照を行いません。

18.3.1 別名エントリによるベースの検索

ベース検索は、指定した別名エントリの最上位レベルを検索します。

間接参照フラグ-a findを使用したベース検索

次の例は、間接参照フラグを-a findに設定し、フィルタとして"objectclass=*"を使用してou=Area1,c=usのベース検索を行う場合を示しています。

ldapsearch -p port -h host -b "ou=Area1,c=us" -a find -s base "objectclass=*"

ディレクトリ・サーバーは、ベース検索時に、検索リクエストに指定されたベースを検索し、その位置をユーザーに戻します。ただし、この例のようにベースが別名エントリで、検索リクエストに-a findが指定されている場合、ディレクトリ・サーバーは、別名エントリを自動的に間接参照し、その別名エントリが指し示すエントリを返します。この例では、検索でou=Area1,c=us(別名エントリ)が間接参照され、o=MyCompany,c=usが返されます。

間接参照フラグ-a searchを使用したベース検索

次の例は、間接参照フラグを-a searchに設定し、フィルタとして"objectclass=*"を使用してou=Area1,c=usのベース検索を行う場合を示しています。

ldapsearch -p port -h host -b "ou=Area1,c=us" -a search -s base "objectclass=*"

ディレクトリ・サーバーは、ベース検索時に、間接参照せずに検索リクエストに指定されたベースを検索し、その位置をユーザーに戻します。これにより、ou=Area1,c=usが返されます。

間接参照フラグ-a alwaysを使用したベース検索

次の例は、間接参照フラグを-a alwaysに設定し、フィルタとして"objectclass=*"を使用してou=Area1,c=usのベース検索を行う場合を示しています。

ldapsearch -p port -h host -b "ou=Area1,c=us" -a always -s base "objectclass=*"

ディレクトリ・サーバーは、ベース検索時に、検索リクエストで指定されたベースを検索します。ベースが別名エントリである場合、ディレクトリ・サーバーは別名エントリを自動的に間接参照し、その別名エントリが指し示すエントリを返します。この例では、検索でou=Area1,c=us(別名エントリ)が間接参照され、o=MyCompany,c=usが返されます。

18.3.2 別名エントリによる1レベルの検索

1レベル検索では、指定したベース・レベルの子のみを検索します。

間接参照フラグ-a findを使用した1レベル検索

次の例は、間接参照フラグを-a findに設定し、フィルタに"objectclass=*"を使用した"ou=Area1,c=us"の1レベル検索を示しています。

ldapsearch -p port -h host -b "ou=Area1,c=us" -a find -s one "objectclass=*"

ディレクトリ・サーバーは、フィルタ基準と一致するベースの下にある1レベル・エントリを返します。この例では、検索リクエストに-a findが指定されているため、ディレクトリ・サーバーは、ベースの検索(最初の手順)中に自動的に間接参照しますが、ベース下の1レベルの別名エントリは間接参照しません。したがって、この検索ではou=Area1,c=us(別名エントリ)が間接参照され、o=MyCompany,c=us下の1レベル・エントリが検索されます。1レベル・エントリの1つは、間接参照されずにそのまま返されるcn=President,o=MyCompany,c=usです。

したがって、この検索では、cn=President,o=MyCompany,c=usおよびcn=John Doe,o=MyCompany,c=usが返されます。

間接参照フラグ-a searchを使用した1レベル検索

次の例は、間接参照フラグを-a searchに設定し、フィルタとして"objectclass=*"を使用して"ou=Area1,c=us"の1レベル検索を行う場合を示しています。

ldapsearch -p port -h host -b "ou=Area1,c=us" -a search -s one "objectclass=*"

ディレクトリ・サーバーは、検索リクエストで指定されたベースを検索します。ベース・エントリが別名エントリの場合は、何も返されません。(別名エントリは子を持つことができません。)それ以外の場合は、ベース・エントリの直下の子が間接参照後に返されます。この例では、ベース・エントリが別名エントリの"ou=Area1,c=us"であるため、検索では何も返されません

間接参照フラグ-a alwaysを使用した1レベル検索

次の例は、間接参照フラグを-a alwaysに設定し、フィルタとして"objectclass=*"を使用して"ou=Area1,c=us"の1レベル検索を行う場合を示しています。

ldapsearch -p port -h host -b "ou=Area1,c=us" -a always -s one "objectclass=*"

この例では、検索リクエストに-a alwaysが指定されているため、ディレクトリ・サーバーは、ベースの検索(最初の手順)中に自動的に間接参照し、ベースの1レベル下の別名エントリを間接参照します。したがって、この検索ではou=Area1,c=us(別名エントリ)が間接参照され、o=MyCompany,c=us下の1レベル・エントリが検索されます。1レベル・エントリの1つは、cn=President,o=MyCompany,c=usです。これは間接参照され、cn=John Doe,o=MyCompany,c=usとして返されます。他の1レベル・エントリにはcn=John Doe,o=MyCompany,c=usがあり、これはすでに返されています。

したがって、この検索ではcn=John Doe,o=MyCompany,c=usが返されます。

18.3.3 別名エントリによるサブツリーの検索

サブツリー検索は、ベース、子および孫を検索します。

間接参照フラグ-a findを使用したサブツリー検索

次の例は、間接参照フラグを-a findに設定し、フィルタとして"objectclass=*"を使用して"ou=Area1,c=us"のサブツリーの検索を行う場合を示しています。

ldapsearch -p port -h host -b "ou=Area1,c=us" -a find -s sub "objectclass=*"

ディレクトリ・サーバーは、フィルタ基準と一致するベースの下にあるすべてのエントリを返します。この例では、検索リクエストに-a findが指定されているため、ディレクトリ・サーバーは、ベースの検索(最初の手順)中に自動的に間接参照しますが、ベース下の別名エントリは間接参照しません。したがって、検索では、ou=Area1,c=us(別名エントリ)が間接参照され、o=MyCompany,c=us下のエントリが検索されます。エントリの1つは、間接参照されずにそのまま返されるcn=President,o=MyCompany,c=usです。

したがって、この検索では次の情報が返されます。

- o=MyCompany,c=us

- cn=John doe,o=MyCompany,c=us

- cn=President,o=MyCompany,c=us

間接参照フラグ-a searchを使用したサブツリー検索

次の例は、間接参照フラグを-a searchに設定し、フィルタとして"objectclass=*"を使用して"ou=Area1,c=us"のサブツリーの検索を行う場合を示しています。

ldapsearch -p port -h host -b "ou=Area1,c=us" -a search -s sub "objectclass=*"

ディレクトリは、検索リクエストで指定されたベースを検索します。ベースが別名エントリの場合、間接参照せずにそのベース・エントリが返されます。(別名エントリは子を持つことができません。)それ以外の場合は、そのベースの下にあるすべてのエントリが返されます。別名エントリが見つかる場合は間接参照され、その下にあるすべてのエントリも返されます。

この例では、ベース・エントリが別名エントリのou=Area1,c=usであるため、ou=Area1,c=usが返されます。

間接参照フラグ-a alwaysを使用したサブツリー検索

次の例は、間接参照フラグを-a alwaysに設定し、フィルタとして"objectclass=*"を使用して"ou=Area1,c=us"のサブツリーの検索を行う場合を示しています。

ldapsearch -p port -h host -b "ou=Area1,c=us" -a always -s sub "objectclass=*"

ディレクトリ・サーバーは、ベース・エントリを間接参照して返します。また、間接参照されたベースの下にあるすべてのエントリも返されます。別名エントリが見つかる場合は間接参照され、その下にあるすべてのエントリも返されます。

この例では、ベース・エントリはou=Area1,c=usであり、o=MyCompany,c=usに間接参照されて返されます。o=MyCompany,c=usの下には2つのエントリがあります。1つはcn=President,o=MyCompany,c=usで、このエントリは返され、さらにcn=John Doe,o=MyCompany,c=usに間接参照されて返されます。o=MyCompany,c=usの下のもう1つのエントリはすでに返されています。したがって、結果はo=MyCompany,c=usおよびcn=John Doe,o=MyCompany,c=usとなります。

18.4 別名エントリの変更

この例は、別名エントリを変更する方法を示しています。ここでは、次のエントリを持つサンプルLDIFファイル
My_file.ldifを作成します。

dn: cn=President, o=MyCompany, c=us
changetype : modify
replace: aliasedobjectname
aliasedobjectname: cn=XYZ, o=MyCompany, c=us

次のコマンドを使用して、別名エントリを変更します。

ldapmodify -D "cn=orcladmin" -q -p port -h host -f My_file.ldif

18.5 別名間接参照に関するメッセージの解釈

表18-2は、別名エントリの間接参照に関するメッセージと、各メッセージの意味を示しています。

表18-2 エントリ別名間接参照メッセージ

メッセージ

意味

別名に問題があります。

次のいずれかの問題が発生しました。

- 別名を間接参照しましたが、その別名がDIT内のエントリを指し示していません。

- 親が別名である別名エントリを追加しようとしました。

別名の参照解除に問題があります。

アクセス制御上の問題であるため、別名を間接参照できません。

該当するオブジェクトがありません。

検索リクエストに指定されたベース識別名をサーバーで検索できません。

DN構文に誤りがあります。

aliasedObjectNameに指定された値に無効な識別名の構文が含まれている場合に別名エントリを追加または変更すると、ディレクトリ・サーバーがクライアントにこのエラー・メッセージを返します。

成功

クライアント操作が正常に完了しました。

間接参照ターゲットが見つかり、検索リクエストに指定したフィルタと一致しない場合、サーバーは一致エントリなしで成功メッセージを返します。

不十分なアクセス権限

ユーザーが間接参照されたエントリへのアクセス権限を持っていません。

19 属性一意性制約エントリの管理

この章では、Oracle Internet Directoryの属性一意性について説明し、Oracle Directory Services Manager (ODSM)およびLDAPコマンド行ユーティリティを使用して、重複した属性値をクリーンアップする方法、属性一意性制約を指定する方法、および属性一意性エントリを管理する方法について説明します。

この章の内容は次のとおりです。

- 第19.1項「属性一意性制約エントリの管理の概要」

- 第19.2項「重複する属性値のクリーンアップ」

- 第19.3項「属性一意性制約エントリの指定」

- 第19.4項「Oracle Directory Services Managerを使用した属性一意性制約エントリの管理」

- 第19.5項「コマンド行を使用した属性一意性制約エントリの管理」

19.1 属性一意性制約エントリの管理の概要

LDAPツールを使用する場合、属性一意性機能は、属性値の追加時および変更時に属性値が重複しないようにします。たとえば、すでに別の従業員に割り当てられている識別子を新しい従業員に割り当てることを防止します。かわりに、ディレクトリ・サーバーは操作を中止し、エラー・メッセージを返します。

次の対象に属性一意性を定義できます。

- ディレクトリ全体
たとえば、mail属性を持つディレクトリ内のすべてのエントリが、その属性に対して一意の値を持つようにするには、mailと関連付けられた属性一意性のインスタンスを作成します。

- 属性ごとの1つのサブツリー全体
たとえば、MyCompanyがSubscriberCompany1とSubscriberCompany2用のディレクトリをホスティングしているとします。SubscriberCompany1のみに属性一意性を適用することを選択できます。

- 1つのオブジェクト・クラス全体
たとえば、IDが、machineオブジェクト・クラスとpersonオブジェクト・クラスの両方で属性になっているとします。属性一意性を有効にすると、ディレクトリ・サーバーは、同じIDを持つ2台のマシンまたは2人のユーザーの追加を防止します。ただし、既存のpersonのID属性と同じ値を持つmachineのID属性を追加することはできます。同様に、既存のmachineのID属性を同じ値を持つpersonのID属性を追加できます。

注意:
LDAPツールでは、属性一意性がサポートされます。バルク・ツールではサポートされません。

属性一意性を実装するには、表19-1に示す属性の値を指定する属性一意性制約エントリを作成します。

属性一意性制約エントリは、cn=unique,cn=Common,cn=Products,cn=OracleContextの下に格納されます。

表19-1 属性一意性制約エントリ

属性名

必須

有効値

デフォルト値

デフォルト有効範囲

orcluniqueattrname

はい

任意の文字列

該当なし

該当なし

orcluniquescope

いいえ

次のいずれかの値

- base: ルート・エントリのみを検索

- onelevel: 1レベルのみを検索

- sub: ディレクトリ全体を検索

sub

ディレクトリ全体を検索

orcluniqueenable

いいえ

0(無効)または1(有効)

0

属性一意性を無効化

orcluniquesubtree

いいえ

任意の文字列

" "

ディレクトリ全体を検索

orcluniqueobjectclass

いいえ

任意の文字列

" "

すべてのオブジェクト・クラスを検索

エントリを作成し、属性を指定した場合、ディレクトリ・サーバーは、エントリに対する操作を実行する前に次のことを行います。

- 属性一意性制約を使用したすべての更新操作のチェック

- モニター対象の属性、サブツリーまたはオブジェクト・クラスに操作を適用するかどうかの決定

モニター対象の属性、接尾辞またはオブジェクト・クラスに操作を適用して、2つのエントリに同じ属性値が含まれた場合、ディレクトリ・サーバーは操作を中止し、制約違反エラー・メッセージをクライアントに返します。

注意:
属性一意性機能は、索引付き属性でのみ機能します。

属性一意性制約がOracle Internet Directoryレプリケーション環境にある場合は、各サーバーでの属性一意性制約の構成は慎重に行ってください。

この項の項目は次のとおりです。

- 第19.1項「単純なレプリケーション使用例」

- 第19.1項「マルチマスター・レプリケーション使用例」

単純なレプリケーション使用例

クライアント・アプリケーションによる変更はすべてサプライヤ・サーバーで実行されるため、サプライヤ・サーバーで属性一意性制約を使用可能にしてください。コンシューマ・サーバーで属性一意性制約を使用可能にする必要はありません。コンシューマ・サーバーで属性一意性制約を使用可能にした場合、ディレクトリ・サーバーの正しい動作を妨害することはありませんが、パフォーマンスが低下する可能性があります。

マルチマスター・レプリケーション使用例

マルチマスター・レプリケーション使用例では、ノードが同じレプリカのサプライヤとコンシューマの両方として機能します。マルチマスター・レプリケーションでは、ゆるやかな一貫性を持つレプリケーション・モデルを使用します。

1台のサーバーの属性一意性制約を使用可能にしても、指定された時間に両方のマスターで属性値が一意であることは保証されません。1台のサーバーのみで属性一意性制約を使用可能にすると、各レプリカに保持されているデータに不整合が発生する可能性があります。

属性一意性制約は、両方のマスターで使用可能にする必要があります。ただし、それでも不整合な状態になる可能性があります。たとえば、両方のマスターで、それぞれのエントリを同じ属性値に変更することができます。ただし、後で変更が別のノードにレプリケートされるときに、この競合が表面化します。この種の競合解消も考慮する必要があります。競合解消をレプリケーション・サーバー側の責任とするかどうかを判断してください。

19.2 重複する属性値のクリーンアップ

Oracle Internet Directory 11gリリース1(11.1.1.7.0)以降では、Oracle Internet Directoryサーバーによりattr_uniqueness_log表内の重複する属性値がレポートされます。attr_uniqueness_log表をスキャンすることによって重複する値を特定した後、クリーンアップできます。

以前のリリースでは、属性の一意性を有効にする前にディレクトリに重複する属性値が存在した場合に、Oracle Internet Directoryサーバーではこうした重複値についてエラーをレポートしませんでした。

Oracle Internet Directory 11gリリース1(11.1.1.7.0)へのアップグレード時に、データがattr_uniqueness表にコピーされます。このアップグレード・プロセス中に、重複する値はattr_uniqueness表ではなくattr_uniqueness_log表にコピーされます。

Oracle Internet Directoryの新規インストールの後、属性の一意性を有効にしたときに既存のデータも重複値を持つことがあります。

重複する属性値を持つエントリを特定するには、次の手順に従います。

1. SQL*Plusを使用して重複する属性値のリストを取得します。次に例を示します。

sqlplus ods@oiddb
spool duplicateVals.out
select attrvalue from attr_uniqueness_log ;
spool off
quit

プロンプトが表示された場合、Oracle Databaseのパスワードを入力します。

2. duplicateVals.outの各重複値について、デプロイメントに応じて適切な処置を講じます。
重複する値を持つエントリを検索するには、ldapsearchを使用します。次に例を示します。

ldapsearch -p -D cn=orcladmin -q -b " " -s sub "attributeName=duplicateValue"

たとえば、エントリから重複する値を削除すること、新しい値に置き換えること、またはすべてのエントリを削除することができます。

19.3 属性一意性制約エントリの指定

属性一意性制約エントリは、cn=unique,cn=Common,cn=Products,cn=OracleContextの下に格納されます。

この項では、属性一意性制約の作成時に適用される規則について、例を使用して説明します。この項の内容は、次のとおりです。

- 第19.3.1項「属性一意性制約での複数の属性名の指定」

- 第19.3.2項「属性一意性制約での複数のサブツリーの指定」

- 第19.3.3項「属性一意性制約での複数の有効範囲の指定」

- 第19.3.4項「属性一意性制約での複数のオブジェクト・クラスの指定」

- 第19.3.5項「属性一意性制約での複数のサブツリー、有効範囲およびオブジェクト・クラスの指定」

この項の例を理解するには、図19-1を参照してください。

図19-1 ディレクトリ情報ツリーの例

19.3.1 属性一意性制約での複数の属性名の指定

複数の属性一意性制約でorcluniqueattrnameの値が異なる場合、その影響は互いに無関係です。

たとえば、ユーザーが、次のような2つの属性一意性制約を定義するとします。

制約1:

orcluniqueattrname: employee_id

制約2:

orcluniqueattrname: email_id

この例で、制約1と制約2は、それぞれの属性一意性の有効範囲内で指定された属性に対して一意性を適用します。制約1と制約2は、互いに無関係です。

19.3.2 属性一意性制約での複数のサブツリーの指定

複数の属性一意性制約で、orcluniqueattrname、orcluniquescopeおよびorcluniqueobjectclassの値が同一で、orcluniquesubtreeの値が異なる場合は、それらの属性一意性制約で指定されたサブツリーの有効範囲が個々にチェックされます。

たとえば、図19-1を参照してください。ユーザーが、次のような2つの属性一意性制約を定義するとします。

制約1:

orcluniqueattrname: employee_id
orcluniquesubtree: o=sales, c=us, cn=root
orcluniquescope: onelevel

制約2:

orcluniqueattrname: employee_id
orcluniquesubtree: o=hr, c=euro, cn=root
orcluniquescope: onelevel

この例で、employee_idの属性一意性は、サブツリーo=sales,c=us,cn=rootの下にあるすべてのエントリに対して適用されます。employee_idの属性一意性も、サブツリーo=sales,c=us,cn=rootの下にあるエントリとは関係なく、o=hr,c=euro,cn=rootの下にあるすべてのエントリに対して適用されます。つまり、ディレクトリ・サーバーは、employee_id属性の一意の値をemployee3およびemployee4に対して適用します。employee7とemployee8にも一意のemployee_idが適用されますが、employee7はemployee4と同じemployee_idを持つ場合があります。

19.3.3 属性一意性制約での複数の有効範囲の指定

複数の属性一意性制約で、orcluniqueattrname、orcluniquesubtreeおよびorcluniqueobjectclassの値が同一で、orcluniquescopeの値が異なる場合は、有効範囲が最大の属性一意性制約が有効になります。

たとえば、図19-1で、ユーザーが、次のような2つの属性一意性制約を定義するとします。

制約1:

orcluniqueattrname: employee_id
orcluniquesubtree: c=us, cn=root
orcluniquescope: onelevel

制約2:

orcluniqueattrname: employee_id
orcluniquesubtree: c=us, cn=root
orcluniquescope: sub

この例で、employee_idの属性一意性は、サブツリーc=us,cn=rootの下にあるすべてのエントリおよびエントリc=us,cn=root自体に対して適用されます。これは、ユーザーが制約2のみを定義した場合も同様であることに注意してください。

19.3.4 属性一意性制約での複数のオブジェクト・クラスの指定

複数の属性一意性制約で、orcluniqueattrname、orcluniquesubtreeおよびorcluniquescopeの値が同一で、orcluniqueobjectclassの値が異なる場合は、それらのオブジェクト・クラスに属する属性を結合したものがチェックされます。

たとえば、図19-1を参照してください。ユーザーが、次のような2つの属性一意性制約を定義するとします。

制約1:

orcluniqueattrname: employee_id
orcluniquesubtree: c=us, cn=root
orcluniqueobjectclass: person

制約2:

orcluniqueattrname: employee_id
orcluniquesubtree: c=us, cn=root

この例で、employee_idの属性一意性は、エントリが属するオブジェクト・クラスに関係なく、サブツリーc=us,cn=rootの下にあるすべてのエントリと、エントリc=us,cn=root自体に対して適用されます。制約2はorcluniqueobjectclass属性を指定していません。これはすべてのオブジェクト・クラスを指定した場合と同じです。

19.3.5 属性一意性制約での複数のサブツリー、有効範囲およびオブジェクト・クラスの指定

複数の属性一意性制約で、orcluniqueattrnameの値が同一で、orcluniquesubtree、orcluniquescopeおよびorcluniqueobjectclassの値が異なる場合は、異なる制約の属性一意性の有効範囲に属するエントリが個々にチェックされます。

たとえば、図19-1で、ユーザーが、次のような2つの属性一意性制約を定義するとします。

制約1:

orcluniqueattrname: employee_id
orcluniquesubtree: o=sales, c=us, cn=root
orcluniquescope: onelevel
orcluniqueobjectclass: person

制約2:

orcluniqueattrname: employee_id
orcluniquesubtree: c=euro, cn=root
orcluniquescope: sub
orcluniqueobjectclass: organization

この例で、employee_idの属性一意性は、次のそれぞれに対して互いに無関係に適用されます。

- オブジェクト・クラスがpersonであるエントリo=sales,c=us,cn=rootの1レベル下のすべてのエントリ

- オブジェクト・クラスがorganizationであるサブツリーc=euro,cn=rootの下のすべてのエントリおよびエントリc=euro,cn=root自体

19.4 Oracle Directory Services Managerを使用した属性一意性制約エントリの管理

属性一意性制約ポリシーは、Oracle Directory Services Managerを使用して管理できます。

19.4.1 ODSMを使用した属性一意性制約エントリの作成

1. 第7.4.5項「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動し、Oracle Internet Directoryサーバーに接続します。

2. タスク選択バーで、「拡張」を選択します。

3. 左側のペインで「属性一意性」を展開します。

4. ツールバーの「属性一意性制約の作成」アイコンを選択します。「新規制約」ウィンドウが表示されます。

5. 「新規制約」ダイアログ・ボックスで、テキスト・フィールドに値を入力し、「一意属性の有効範囲」を選択します。「参照」をクリックすると「一意属性のサブツリー」を選択できます。

6. ここで制約を有効化する場合、「一意属性の有効化」をクリックします。

7. 「OK」を選択します。作成したエントリが、左側のパネルの属性一意性制約エントリのリストに表示されます。

8. 「適用」をクリックしてこの制約を適用するか、「元に戻す」をクリックして新規エントリの作成前の状態に戻します。

19.4.2 ODSMを使用した属性一意性制約エントリの変更

1. 第7.4.5項「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動し、Oracle Internet Directoryサーバーに接続します。

2. タスク選択バーで、「拡張」を選択します。

3. 左側のペインで「属性一意性」を展開します。

4. 既存の一意性制約を選択します。これにより、属性一意性制約ウィンドウの「一般」タブが表示されます。

5. 値を入力または変更します。

6. ここで制約を有効化する場合、「一意属性の有効化」をクリックします。

7. 「適用」をクリックしてこの変更を適用するか、「元に戻す」をクリックしてエントリの変更前の状態に戻します。

19.4.3 ODSMを使用した属性一意性制約エントリの削除

属性一意性制約ポリシーを削除する手順は次のとおりです。

1. 第7.4.5項「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動し、Oracle Internet Directoryサーバーに接続します。

2. タスク選択バーで、「拡張」を選択します。

3. 左側のペインで「属性一意性」を展開します。

4. 左側のパネルで、削除する属性一意性制約エントリを選択します。

5. 「削除」アイコンを選択し、確認を求めるプロンプトで削除を確認します。削除したエントリは、左側のパネルの属性一意性制約エントリのリストに表示されなくなります。

6. 「適用」をクリックしてこの変更を適用するか、「元に戻す」をクリックしてエントリの削除前の状態に戻します。

19.5 コマンド行を使用した属性一意性制約エントリの管理

属性一意性制約ポリシーは、コマンド行を使用して管理できます。

19.5.1 コマンド行ツールを使用したディレクトリ全体を対象とする属性一意性の作成

ディレクトリ全体を対象とする属性一意性のインスタンスを作成するには、値の一意性を適用する属性名を指定します。

たとえば、MyCompanyの米国の全従業員に対して一意の従業員識別子を作成する手順は、次のとおりです。

1. 次のように、属性一意性制約エントリを(LDIFフォーマットで)作成します。

dn: cn=constraint1, cn=unique, cn=common, cn=products, cn=oraclecontext
objectclass: orclUniqueConfig
orcluniqueattrname: employeenumber
orcluniquesubtree: o=MyCompany, c=US
orcluniqueobjectclass: person

2. 次のような属性一意性制約エントリをロードして、属性一意性機能を適用します。

ldapadd –h host -p port -D DN -q -f constraint1.ldif

3. ディレクトリ・サーバーを再起動します。

例:

次のLDIFファイルuniquenessConstraint.ldifによって、一意性制約をorclcommonusernickname属性に指定します。

# Use this LDIF file to set up a uniqueness constraint on the nickname
# attribute within the user search base.
# Before running the script, change the following parameters in the LDIF file.
#  <userid_attribute> -  Specify the name of the attribute that holds the user
# id. This value should be the same as the orclcommonusernickname attribute
# configured for the realm.#  <dn _f_user_serach_base> - Specify the user search base in which the
# uniqueness constraint should be enforced.
#
dn: cn=<userid_attribute> ,cn=unique,cn=common,cn=Products, cn=OracleContext
changetype: add
objectclass: orclUniqueConfig
orcluniqueattrname: <userid _ttribute>
orcluniquesubtree: <dn_of_user_search_base>
orcluniqueenable:1

19.5.2 コマンド行ツールを使用した1つのサブツリーを対象とする属性一意性の作成

1つ以上のサブツリーを対象とする属性一意性のインスタンスを作成するには、次の項目を指定します。

- 値の一意性を適用する属性名

- 一意性制約を適用するサブツリーの位置

たとえば、MyCompanyがSubscriberCompany1とSubscriberCompany2をホスティングしていて、SubscriberCompany1のみに従業員識別子属性の一意性を適用するとします。uid=dlin,ou=people,o=SubscriberCompany1,dc=MyCompany,dc=com
などのエントリを追加する場合は、o=SubscriberCompany1,dc=MyCompany,dc=comサブツリーでのみ一意性を適用する必要があります。これを行うには、属性一意性制約の構成で、サブツリーの識別名を明示的に列挙します。

この場合、LDIFファイルは次のようになります。

dn: cn=constraint1, cn=unique, cn=common, cn=products, cn=oraclecontext
objectclass: orclUniqueConfig
orcluniqueattrname: employeenumber
orcluniquesubtree: o=SubscriberCompany1,dc=MyCompany,     dc=com

19.5.3 コマンド行ツールを使用した1つのオブジェクト・クラスを対象とする属性一意性の作成

1つのオブジェクト・クラスを対象とする属性一意性のインスタンスを作成するには、次の項目を指定します。

- 値の一意性を適用する属性名

- オブジェクト・クラス名

この場合、LDIFファイルは次のようになります。

dn: cn=constraint1, cn=unique, cn=common, cn=products, cn=oraclecontext
objectclass: orclUniqueConfig
orcluniqueattrname: employeenumber
orcluniqueobjectclass: person

ldapaddを使用してエントリを追加します。

ldapadd -D "cn=orcladmin" -q -p port -D user -f file_name

19.5.4 コマンド行ツールを使用した属性一意性制約エントリの変更

属性一意性エントリを変更するには、エントリのLDIFファイルを作成し、その後ldapmodifyを使用してそのファイルをディレクトリにアップロードします。

たとえば、次のような既存の属性一意性制約エントリがあるとします。

dn: cn=constraint1, cn=unique, cn=common, cn=products, cn=oraclecontext
objectclass: orclUniqueConfig
orcluniqueattrname: employeenumber
orcluniquesubtree: o=MyCompany, c=US
orcluniqueobjectclass: person

この制約をo=MyCompanyではなくc=USに適用する手順は、次のとおりです。

1. LDIFエントリを作成して、orcluniquenesssubtreeエントリを次のように変更します。

dn: cn=constraint1, cn=unique, cn=common, cn=products, cn=oraclecontext
changetype: modify
replace: orcluniquesubtree
orcluniquesubtree: o=Oracle Corporation, c=US

2. ldapmodifyを使用して、この変更をディレクトリ・サーバーに適用します。

ldapmodify -D "cn=orcladmin" -q -p port -D user -f file_name

3. ディレクトリ・サーバーを再起動して、この変更を有効にします。

19.5.5 コマンド行ツールを使用した属性一意性制約エントリの削除

属性一意性制約ポリシーを削除するには、ldapdeleteコマンド行ツールを使用します。

1. ldapdeleteを使用して、ディレクトリから属性一意性制約エントリを削除します。

ldapdelete -D "cn=orcladmin" -q -p port -D bind_DN \
"cn=constraint1,cn=unique,cn=common,cn=products,cn=oraclecontext"

2. ディレクトリ・サーバーを再起動して、この変更を有効にします。

19.5.6 コマンド行ツールを使用した属性一意性の有効化と無効化

既存の属性一意性制約エントリに対する属性一意性を有効または無効にできます。

既存の属性一意性制約エントリに対する属性一意性を有効にする手順は、次のとおりです。

1. ldapmodifyを使用して、orcluniqueenable属性を1に設定します。

2. ディレクトリ・サーバーを再起動して、ポリシーを有効にします。

属性一意性を無効化する手順は、次のとおりです。

1. ldapmodifyを使用して、orcluniqueenable属性を0に設定します。

2. ディレクトリ・サーバーを再起動して、ポリシーを無効にします。

20 ナレッジ参照と参照の管理

この章では、Oracle Internet Directoryのナレッジ参照と参照について説明し、スマート参照およびデフォルト参照を構成する方法について説明します。

この章の内容は次のとおりです。

- ナレッジ参照と参照の管理の概要

- 第20.2項「スマート参照の構成」

- 第20.3項「デフォルト参照の構成」

関連項目:
ディレクトリ・エントリ、ディレクトリ情報ツリー、識別名および相対識別名の概要は、第3.10項「ナレッジ参照と参照」を参照してください。

20.1 ナレッジ参照と参照の管理の概要

ナレッジ参照は参照とも呼ばれ、特定のタイプのエントリとしてディレクトリ内で表されます。ナレッジ参照エントリを作成するときには、referralオブジェクト・クラスおよびextensibleObjectオブジェクト・クラスにそのエントリを関連付けます。通常、ナレッジ参照エントリは、パーティションを確立するDIT内の場所に作成されます。

ナレッジ参照は、LDAP URLを含む参照をユーザーに提供します。このURLを、ref属性の値として入力してください。任意のナレッジ参照エントリに複数のref属性が指定されている場合があります。同様に、DITに複数のナレッジ参照エントリがある場合もあります。

関連項目:
ディレクトリ・パーティション化とナレッジ参照の概要およびスマート・ナレッジ参照とデフォルト・ナレッジ参照の詳細は、第3章「Oracle Internet Directoryの概念およびアーキテクチャの理解」を参照してください。

参照キャッシングとは、参照情報へのアクセスを簡単に繰り返すことができるように、その情報を格納するプロセスです。クライアントがサーバーAに問い合せ、サーバーAがサーバーBに参照を返すとします。クライアントはこの参照を追跡して、操作を実行し、クライアントに結果を返すサーバーBと通信します。参照キャッシングが行われていない場合、クライアントが次回同じ問合せをサーバーAに対して行うと、手順全体が繰り返され、時間とシステム・リソースを必要以上に消費することになります。

参照情報をキャッシュできる場合は、以降の各問合せで、参照情報をキャッシュから取り出し、サーバーBと直接通信できます。これによって、操作にかかる時間を短縮できます。

クライアント側の参照キャッシングによって、各クライアントは、参照情報をキャッシュして使用し、参照処理にかかる時間を短縮できます。

参照エントリは、クライアントの構成ファイルに格納されます。クライアントは、セッション確立時に、この構成ファイルから参照情報を読み取ってキャッシュに格納します。このキャッシュは静的状態を保持し、セッション中に更新の追加は行われません。これ以降、クライアントは、操作を行うたびにキャッシュ内の参照情報を検索します。

クライアントが使用するこの構成ファイルは、ディレクトリ管理者が準備します。

注意:
構成ファイルは、クライアントにとってはオプションです。ファイルが存在しない場合でも、参照に関係するクライアント操作は正常に行われます。したがって、このファイルの準備は、管理者の必須作業ではありません。構成ファイルを使用する利点は、参照に関係するクライアント/サーバーの操作時間を短縮できることです。

構成ファイルは、1つ以上の参照セットで構成されます。それぞれの参照セットは、次の要素で構成されます。

- 特定のディレクトリ・サーバーが稼働しているホスト名

- そのサーバーに存在する1つ以上のエントリ

各参照エントリは一連の行で構成され、それぞれの行は1つの参照URLに対応します。行セパレータは、CRまたはLFです。

ref_file=ref_file_content
ref_file_content=1*(referral_set)
referral_set=hostname       SEP      ref_entry_set   SEP
ref_entry_set=ref_entry     *(SEP    ref_entry)
ref_entry=1*(referralurl    SEP)
SEP=CR LF / LF
CR=0x0D
LF=0x0A

たとえば、ホスト・サーバーXで稼働しているディレクトリ・サーバーに次の2つの参照エントリがあるとします。

dn: dc=example, dc=com
ref: ldap://serverA:3060/dc=example, dc=com
ref: ldap://serverB:3060/dc=example, dc=com

dn: dc=oracle, dc=com
ref: ldap://serverC:3060/dc=oracle, dc=com
ref: ldap://serverD:3060/dc=oracle, dc=com

ホスト・サーバーYで稼働しているディレクトリ・サーバーには、次の参照エントリがあるとします。

dn: dc=fiction, dc=com
ref: ldap://serverE:3060/dc=fiction, dc=com

対応するreferral.oraファイルは、次のようになります。

ServerX
ldap://serverA:3060/dc=example, dc=com
ldap://serverB:3060/dc=example, dc=com

ldap://serverC:3060/dc=oracle, dc=com
ldap://serverD:3060/dc=oracle, dc=com

ServerY
ldap://serverE:3060/dc=fiction, dc=com

20.2 スマート参照の構成

検索結果には、ナレッジ参照とともに通常のエントリも含まれる場合があります。ユーザーが検索操作を実行すると、Oracle Internet Directoryは指定された検索の適用範囲内でナレッジ参照エントリを探します。ナレッジ参照が見つかった場合、Oracle Internet Directoryは参照をクライアントに返します。

ユーザーがナレッジ参照エントリの下に置かれたエントリに対して追加、削除または変更操作を実行すると、Oracle Internet Directoryは参照を返します。

たとえば、ディレクトリ・サーバーの地理的な場所に基づいたDITを分割するとします。この例では、次のように仮定します。

- c=usネーミング・コンテキストは、米国のサーバーAとサーバーBにローカルに保持されています。

- c=ukネーミング・コンテキストは、英国のサーバーCとサーバーDにローカルに保持されています。

ここで、この2つのネーミング・コンテキスト間のナレッジ参照を、次のように構成するとします。

1. 米国のサーバーAとサーバーBで、サーバーCとサーバーDのc=ukオブジェクトのナレッジ参照を構成します。

dn: c=uk
c: uk
ref: ldap://host C:3060/c=uk
ref: ldap://host D:600/c=uk
objectclass: top
objectclass: referral
objectClass: extensibleObject

2. 同様に英国のサーバーCとサーバーDで、サーバーAとサーバーBのc=usオブジェクトのナレッジ参照を構成します。

dn: c=us
c: us
ref: ldap://host A:4000/c=us
ref: ldap://host B:5000/c=us
objectclass: top
objectclass: referral
objectClass: extensibleObject

コマンド行ツールを使用します。

ldapmodify -D cn=orcladmin -q -p portNum -h hostname -f ldifFile

結果は、次のようになります。

- サーバーAまたはサーバーBにベースo=foo,c=ukで問い合せるクライアントは、参照を受信します。

- サーバーCまたはサーバーDにベースo=foo,c=usで問い合せるクライアントは、参照を受信します。

- サーバーAまたはサーバーBでのo=foo,c=ukの追加操作は失敗します。かわりに、Oracle Internet Directoryは参照を返します。

20.3 デフォルト参照の構成

Oracle Internet Directoryは、サーバーによってローカルに保持されているすべてのディレクトリ・ネーミング・コンテキストを、DSEのnamingcontext属性を使用して判断します。namingContext属性には、ネーミング・コンテキスト情報を正しく反映させてください。

関連項目:
第11章「ネーミング・コンテキストの管理」

DSEエントリのref属性の値を入力して、デフォルト参照を指定します。ref属性がDSEエントリにない場合は、デフォルト参照は返されません。

デフォルト参照を構成するときは、LDAP URLの識別名を指定しないでください。

たとえば、サーバーAのDSEエントリに、次のnamingContext値が含まれているとします。

namingcontext: c=us

さらに、デフォルト参照が次のとおりと仮定します。

Ref: ldap://host PQR:3060

ユーザーが、サーバーAでネーミング・コンテキストc=canadaにベース識別名を持つ操作を入力したとします。たとえば、次のとおりです。

ou=marketing,o=foo,c=canada

このユーザーはホストPQRへの参照を受信することになります。これは、サーバーAがc=canadaベース識別名を保持しておらず、そのDSEのnamingContext属性が値c=canadaを保持していないためです。

関連項目:
ナレッジ参照の概念の説明は、第3.10項「ナレッジ参照と参照」を参照してください。

21 ディレクトリ・スキーマの管理

この章では、Oracle Directory Services Manager (ODSM)およびLDAPコマンド行ユーティリティを使用して、ディレクトリ・スキーマでOracle Internet Directoryのオブジェクト・クラスと属性を管理する方法について説明します。

この章の内容は次のとおりです。

- 第21.1項「ディレクトリ・スキーマの管理の概要」

- 第21.2項「Oracle Directory Services Managerを使用したディレクトリ・スキーマの管理」

- 第21.3項「コマンド行を使用したディレクトリ・スキーマの管理」

21.1 ディレクトリ・スキーマの管理の概要

ディレクトリ内のベース・スキーマの追加または変更を行う前に、ディレクトリのコンポーネントの基本概念を理解しておいてください。

ディレクトリ・スキーマには、次の機能があります。

- ディレクトリに格納できるオブジェクトの種類に関する規則を含んでいます。

- 検索などの処理時にディレクトリ・サーバーとクライアントが情報を扱う方法の規則を含んでいます。

- ディレクトリに格納されているデータの整合性と品質をメンテナンスするのに役立ちます。

- データの重複を削減します。

- ディレクトリに対応したアプリケーションがディレクトリ・オブジェクトにアクセスしたり変更したりするための、予測可能な方法を提供します。

注意:
Oracle Internet Directoryのスキーマ・オブジェクトには、それぞれ特定の制限があります。たとえば、一部のオブジェクトは変更できません。これらの制限事項は、ここでは制約や規則として説明しています。

この項の内容は次のとおりです。

- 第21.1.1項「ディレクトリ内のスキーマ情報の格納場所」

- 第21.1.2項「オブジェクト・クラスの理解」

- 第21.1.3項「属性の理解」

- 第21.1.4項「エントリと関連付けられた属性数の拡大」

- 第21.1.5項「属性別名の理解」

- 第21.1.6項「LDAP操作でのオブジェクト識別子のサポート」

関連項目:
『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のLDAPスキーマの概要に関する説明

21.1.1 ディレクトリ内のスキーマ情報の格納場所

ディレクトリ・スキーマには、DIT内のデータを編成する方法に関するすべての情報(オブジェクト・クラス、属性、一致規則、構文などのメタデータ)が含まれています。この情報は、サブエントリと呼ばれる特別なクラスのエントリに格納されます。Oracle Internet Directoryは、LDAPバージョン3の規格に従って、タイプsubSchemaSubentryのサブエントリにこの情報を格納します。

subSchemaSubentryタイプのサブエントリに新規のオブジェクト・クラスと属性タイプを追加できます。Oracle Internet Directoryですでにサポートされているこれらのもの以外に、新規の一致規則や構文を追加することはできません。

10g(10.1.4.0.1)の前は、ルートDSEエントリcn=subSchemaSubentryの直下にsubSchemaSubentryが1つしかなく、常にオブジェクト・クラスと属性タイプを直接追加していました。10g(10.1.4.0.1)では、エントリcn=subSchemaSubentryに下位エントリを設定できるようになりました。スキーマ・コンポーネントを追加する必要のある、Oracle Internet Directoryを使用するアプリケーションはいずれも、cn=subSchemaSubentryの下に固有のsubSchemaSubentryを作成し、そこにスキーマ・コンポーネントを追加できます。図21-1は、cn=userdefined1,cn=subschemasubentryやcn=userdefined2,cn=subschemasubentryなど、アプリケーションによって定義されたsubSchemaSubentryエントリをいくつか示しています。

ベスト・プラクティスは、アプリケーションまたはアプリケーションのグループごとにsubschemasubentryの下に1つの下位エントリを作成することです。アプリケーションに関連するすべてのattributeTypesおよびobjectClassesは、cn=subschemasubentryの下の対応するエントリの下に配置する必要があります。

スキーマ・エントリはすべて、ルートDSE属性subschemasubentryに示されています。

図21-1 subSchemaSubentryタイプのエントリでのスキーマ・コンポーネントの位置

subSchemaSubentryエントリの追加には、bulkloadを使用できません。ldapaddを使用する必要があります。

21.1.2 オブジェクト・クラスの理解

エントリを追加する場合は、そのエントリを1つ以上のオブジェクト・クラスと関連付けます。各オブジェクト・クラスには、新規エントリと関連付ける属性が含まれています。たとえば、従業員に関するエントリを作成する場合は、そのエントリをpersonオブジェクト・クラスと関連付けることができます。このオブジェクト・クラスには、その従業員エントリと関連付ける多くの属性(名前、住所、電話番号など)が含まれています。

注意:
Oracle Directory Services Managerの「スキーマ」タブの属性ページには、属性を直接参照するオブジェクト・クラスを示す「参照元」セクションがあります

各オブジェクト・クラスは、スーパークラスの階層から派生し、これらのスーパークラスからの属性を継承します。デフォルトでは、すべてのオブジェクト・クラスはtopオブジェクト・クラスから継承します。オブジェクト・クラスをエントリに割り当てると、エントリは、そのオブジェクト・クラスとそのオブジェクト・クラスのスーパークラスの両方の属性をすべて継承します。

エントリがスーパークラスから継承する属性は、必須またはオプションのいずれかです。オプション属性の値は、ディレクトリ・エントリに存在している必要はありません。

オブジェクト・クラスに対して、属性が必須またはオプションのいずれであるかを指定できますが、指定した特性はそのオブジェクト・クラスに対してのみバインドされます。その属性を別のオブジェクト・クラスに配置する場合は、このオブジェクト・クラスに対してその属性が必須またはオプションのいずれであるかを再度指定できます。次の内容を実行できます。

- 標準以外の新規オブジェクト・クラスの追加と既存属性の割当て

- 既存の標準オブジェクト・クラスからの選択

- 既存のオブジェクト・クラスの変更、異なる属性のセットへの割当て

- 既存の属性の追加と変更

関連項目:
Oracle Internet Directoryとともにインストールされるスキーマ要素のリストは、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のLDAPスキーマの概要に関する説明を参照してください。

エントリはトップダウン順序で追加する必要があります。つまり、エントリを追加するときに、そのすべての親エントリがディレクトリ内に存在している必要があります。同様に、オブジェクト・クラスと属性を参照するエントリを追加する場合は、参照されるオブジェクト・クラスと属性がディレクトリ・スキーマに存在している必要があります。通常は、ディレクトリ・サーバーには標準のディレクトリ・オブジェクトの完全なセットが用意されているため、このことは問題になりません。

エントリに操作を追加または実行する場合、そのエントリに関連付けられたスーパークラスの階層全体を指定する必要はありません。リーフ・オブジェクト・クラスの指定のみで済みます。Oracle Internet Directoryは、リーフ・オブジェクト・クラスの階層を解決して、情報モデル制約を適用します。これは多くの場合、オブジェクト・クラスの増加と呼ばれます。たとえば、inetOrgPersonオブジェクト・クラスは、そのスーパークラスとして、top、personおよびorganizationalPersonを持っています。ある人物を表すエントリを作成する場合、オブジェクト・クラスとして指定する必要があるのはinetOrgPersonのみです。Oracle Internet Directoryは、各スーパークラスtop、personおよびorganizationalPersonによって定義されたスキーマ制約を適用します。

21.1.2.1 オブジェクト・クラスの追加について

オブジェクト・クラスを追加するときは、次の点に注意してください。

- すべての構造型オブジェクト・クラスには、スーパークラスとしてtopを設定する必要があります。

- オブジェクト・クラスの名前とオブジェクト識別子は、すべてのスキーマ・コンポーネントを通して一意であることが必要です。実際の属性名と属性名の別名は、すべての属性名と属性別名を通して一意であることが必要です。オブジェクト識別子は一意の識別子、2.16.840.1.113894で始まり、その後ろにOracle指定の接頭辞.9999か、サイト固有の接頭辞が続いている必要があります。

- オブジェクト・クラスで参照されるスキーマ・コンポーネント(スーパークラスなど)は、すでに存在している必要があります。

- 抽象型オブジェクト・クラスの場合は、スーパークラスも抽象型であることが必要です。

- スーパークラスの必須属性は、新規オブジェクト・クラスでオプション属性に再定義することが可能です。同様に、スーパークラスのオプション属性は、新規オブジェクト・クラスで必須属性に再定義できます。

関連項目:
これらの用語の概念の説明は、第3.5.1項「サブクラス、スーパークラスおよび継承」を参照してください。

21.1.2.2 オブジェクト・クラスの変更について

この項では、既存のオブジェクト・クラスに対して実行できる変更のタイプについて説明します。変更は、Oracle Directory Services Managerおよびコマンド行ツールを使用して実行できます。

オブジェクト・クラスに対しては、次の変更を実行できます。

- 必須属性からオプション属性への変更

- オプション属性の追加

- スーパークラスの追加

- 抽象型オブジェクト・クラスから構造型または補助型オブジェクト・クラスへの変換(その抽象型オブジェクト・クラスが、別の抽象型オブジェクト・クラスのスーパークラスではない場合)

オブジェクト・クラスを変更するときは、次のガイドラインに注意してください。

- 標準のLDAPスキーマの一部であるオブジェクト・クラスは変更できません。ユーザー定義のオブジェクト・クラスは変更できます。

- 必要な属性が既存のオブジェクト・クラスに設定されていない場合は、補助型オブジェクト・クラスを作成して、必要な属性をそのオブジェクト・クラスに関連付けることができます。

- 既存のオブジェクト・クラスに、必須属性を追加できません。

- ベース・スキーマのオブジェクト・クラスは変更できません。

- 既存のオブジェクト・クラスから属性またはスーパークラスを削除できません。

- 構造型オブジェクト・クラスは、他の型のオブジェクト・クラスに変換できません。

- エントリがすでに関連付けられているオブジェクト・クラスは変更しないでください。

21.1.2.3 オブジェクト・クラスの削除について

オブジェクト・クラスの削除に関しても、いくつかの制限事項があります。

- ベース・スキーマからオブジェクト・クラスを削除できません。

- ベース・スキーマ内にないオブジェクト・クラスは、他のスキーマ・コンポーネントから直接または間接的に参照されていないかぎり削除できます。たとえば、このようなオブジェクト・クラスを参照するディレクトリ・エントリがいくつか存在するとします。このオブジェクト・クラスを削除すると、これらのエントリにはアクセスできなくなります。

21.1.3 属性の理解

属性を扱う操作を実行する前に、概念的な観点から属性を理解する必要があります。

多くの場合、ベース・スキーマにある属性で、ユーザーの組織のニーズを満たすことができます。ベース・スキーマにない属性を使用する場合は、新規属性の追加または既存属性の変更が可能です。

デフォルトでは、属性は複数値です。Oracle Directory Services Managerまたはコマンド行ツールを使用して、属性を単一値に指定できます。

注意:
非バイナリ属性の最大長は4000バイトです。

関連項目:

- 属性の概念の説明は、第3.4項「属性」を参照してください。

- 属性オプションの詳細は、第3.4.6項「属性オプション」を参照してください。

- 属性値のサイズを指定する構文の使用方法の詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』の属性の構文に関する説明を参照してください。

21.1.3.1 属性の追加について

属性の追加に関しては、次の規則があります。

- 属性の名前とオブジェクト識別子は、すべてのスキーマ・コンポーネントを通して一意であることが必要です。

- 構文と一致規則は、整合性がとれている必要があります。

- スーパー属性はすでに存在している必要があります。

- 属性名の長さは127文字までです。

21.1.3.2 属性の変更について

属性の変更に関しては、次の規則があります。

- 属性の名前とオブジェクト識別子は、すべてのスキーマ・コンポーネントを通して一意であることが必要です。

- 属性の構文は変更できません。

- 単一値の属性は複数値の属性に変更できますが、複数値の属性を単一値の属性に変更することはできません。

- ベース・スキーマの属性は、変更または削除できません。

21.1.3.3 属性の削除について

属性の削除に関しては、次の規則があります。

- 削除できるのはユーザー定義属性のみです。ベース・スキーマの属性は削除しないでください。

- 他のスキーマ・コンポーネントから直接または間接的に参照されていない属性は、削除することができます。
エントリの参照先である属性を削除すると、そのエントリはディレクトリ操作に使用できなくなります。

注意:
Oracle Directory Services Managerの「スキーマ」タブの属性ページには、属性を直接参照するオブジェクト・クラスを示す「参照元」セクションがあります

関連項目:
属性値のサイズを指定する構文の使用方法の詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』の属性の構文に関する説明を参照してください。

21.1.3.4 属性の索引付けについて

Oracle Internet Directoryは、索引を使用して属性を検索できるようにしています。Oracle Internet Directoryのインストール時に、検索で使用できる属性のリストがエントリcn=catalogsに表示されます。

Oracle Internet Directory 11g リリース1(11.1.1.6.0)では、新規インストールで新しい自動カタログ機能がデフォルトで有効化されます。以前のリリースからアップグレードした場合も、これを有効にできます。この機能を有効にすると、属性を検索したときに、属性がOracle Internet Directoryによって自動的に索引付けされます。DSA構成エントリのorclautocatalog属性を0に設定すると、この機能を無効化できます。コマンド行からこの属性を変更するには、第9.4.1項「ldapmodifyを使用したシステム構成属性の設定」を参照してください。Oracle Enterprise Manager Fusion Middleware Controlを使用してこの属性を変更するには、第9.2.2項「共有プロパティの構成」を参照してください。

自動カタログ機能を有効化しないで、追加の属性を検索フィルタで使用する必要がある場合は、それらをカタログ・エントリに追加する必要があります。

ldapmodifyまたはcatalogを使用して、属性に索引付けしたり、属性から索引を削除することができます。また、Oracle Directory Services Managerを使用して属性の索引を管理することもできます。

注意:

- 自動カタログが無効の場合に、必須属性として指定された、索引付けされていない属性を使用して検索を実行しようとすると、サーバーから「この機能は組み込まれていません」または「ディレクトリ・サービス・エージェントが実行不可の状態です。」エラーが返されます。

- 有効なユーザーがOracle Internet Directoryに接続した場合にのみ、自動カタログが実行されます。匿名バインド検索では、自動カタログ機能はトリガーされません。また、このイベントは監査されます。2つ以上のクライアントが、索引付けされていない同じ属性を同時に検索した場合は、1つのスレッドでのみカタログ・プロセスが開始されます。他のスレッドは、LDAPエラー53および追加情報OID-5018: 属性のカタログ作成はすでに進行中ですを返します。カタログ作成スレッドは、(別の)カタログ作成プロセスが完了するのを待機するか、または構成したorclmaxserverresptimeまで待機します。orclmaxserverresptimeが経過すると、カタログ作成スレッドはLDAPエラー53および追加情報OID-5018: 属性のカタログ作成はすでに進行中ですを返します。各属性のカタログが作成されるのはディレクトリごとに1回だけであるため、このことが行われるのはカタログ化されていない属性ごとに1回だけです。クライアント側のタイムアウトや明示的なkillコマンドが原因で検索が中断された場合、進行中のカタログ作成は続行され、カタログ作成プロセスが完了すると、同じ属性に対する後続の検索は正常に行われます。

- Oracle Directory Services Managerでは、属性がまだ使用されていない場合にのみその属性に索引を付けることができます。Oracle Directory Services Managerを使用して、すでに使用されている属性に索引を付けることはできません。使用中の属性に索引付けするには、第21.3.7項「ldapmodifyを使用した属性の索引付け」の説明に従ってldapmodifyを使用するか、第21.3.9項「カタログ管理ツールを使用した属性の索引付け」の説明に従ってカタログ管理ツールを使用します。

注意:
次の条件を満たす属性のみ索引を付けることができます。

- 等価の一致規則

- Oracle Internet Directoryでサポートされる一致規則は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』の属性の一致規則に関する説明を参照してください。

- 属性名が127文字以下

21.1.4 エントリと関連付けられた属性数の拡大

エントリの属性数を拡大できます。使用する方法は、エントリがすでに存在するかどうかによって異なります。

エントリがまだない場合、ディレクトリにエントリを作成する前に属性数を拡大できます。

既存エントリの場合、関連付ける属性数の拡大方法には2通りあります。

- 各エントリのobjectclass属性のリストにオブジェクト・クラスの名前を追加します。ディレクトリが比較的小さい場合は、属性に基づいてエントリを検索できるため、この方法が適しています。一方、ディレクトリが大きい場合は、objectclass属性へのオブジェクト・クラスの名前の入力が、非常に複雑な作業になる場合があります。

- コンテンツ・ルールを使用します。大きいディレクトリでエントリの内容を拡大する場合、この方が効率的な場合があります。

この項の項目は次のとおりです。

- 第21.1.4.1項「ディレクトリでエントリを作成する前の属性数の拡大」

- 第21.1.4.2項「補助型オブジェクト・クラスの作成による既存エントリの属性数の拡大」

- 第21.1.4.3項「コンテンツ・ルールの作成による既存エントリの属性数の拡大」

21.1.4.1 ディレクトリでエントリを作成する前の属性数の拡大

Oracle Internet Directoryは、インストール時に、標準的なLDAPオブジェクト・クラスといくつかの専用オブジェクト・クラスを用意します。この事前に定義されたオブジェクト・クラスに属している属性のセットには、必須属性を追加できません。エントリに必要なすべての属性が所定のオブジェクト・クラスに含まれていない場合には、次のうちのいずれかを行います。

- 新規の(ベース)オブジェクト・クラスの定義

- オブジェクト・サブクラスの定義

関連項目:

- Oracle Internet Directoryとともにインストールされるスキーマに含まれるオブジェクト・クラスのリストは、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のOracle Identity Management LDAPオブジェクト・クラスに関する説明を参照してください。

- 新規のオブジェクト・クラスまたはオブジェクト・サブクラスを定義する方法は、第21.2.2項「Oracle Directory Services Managerを使用したオブジェクト・クラスの追加」を参照してください。

21.1.4.2 補助型オブジェクト・クラスの作成による既存エントリの属性数の拡大

エントリに必要な追加属性を含む補助型オブジェクト・クラスを作成し、その補助型オブジェクト・クラスをエントリと関連付けることができます。補助型オブジェクト・クラスをエントリと関連付けるには、エントリのobjectclass属性でそれを指定します。

関連項目:

- 補助型オブジェクト・クラスの作成方法の詳細は、第21.2.2項「Oracle Directory Services Managerを使用したオブジェクト・クラスの追加」を参照してください。

- オブジェクト・クラスをエントリと関連付ける方法の詳細は、第13章「ディレクトリ・エントリの管理」を参照してください。

21.1.4.3 コンテンツ・ルールの作成による既存エントリの属性数の拡大

コンテンツ・ルールは、仕様に従って、特定の構造型オブジェクト・クラスと関連付けられたエントリで使用されるコンテンツの種類を決定します。たとえば、personオブジェクト・クラスと関連付けられたエントリは、そのオブジェクト・クラスの属性だけでなく、他の属性も持つ必要があることを指定できます。追加属性は、補助型オブジェクト・クラスの必須またはオプションの属性にできます。

エントリには補助型クラスをリストする必要があります(これはかなりの管理負荷になることがあります)が、コンテンツ・ルールをリストする必要はありません。

コンテンツ・ルールには、コンテンツ・ルールが適用される構造型オブジェクト・クラスだけでなく、次のものも含めることができます。

- 規則によって制御されるエントリで使用可能な補助型オブジェクト・クラス

- 構造型および補助型オブジェクト・クラスに必要な属性に加え、DITコンテンツ・ルールによって制御されるエントリで必要な必須属性

- 構造型および補助型オブジェクト・クラスに必要な属性に加え、DITコンテンツ・ルールによって制御されるエントリで使用可能なオプション属性

この項では、Oracle Directory Services Managerおよびコマンド行ツールを使用してコンテンツ・ルールを管理する方法を説明します。

新しいコンテンツ・ルールの定義中に、ディレクトリ・サーバーは構文を検証し、コンテンツ・ルールにリストされた属性およびオブジェクト・クラスがディレクトリで定義済であることを確認します。

コンテンツ・ルールは、構造型オブジェクト・クラスに対してのみ指定できます。オブジェクト・クラスの名前では、大文字と小文字が区別されます。

各構造型オブジェクト・クラスに複数のコンテンツ・ルールを指定できます。ただし、コンテンツ・ルールは、オブジェクト・クラスごとに異なるラベルで関連付ける必要があります。

コンテンツ・ルールの既存の定義を変更する場合、クライアントは既存の定義を削除した後で、新しい定義を追加する必要があります。replaceコマンドを使用してコンテンツ・ルールを単純に置き換えることはできません。

コンテンツ・ルールを削除する場合、クライアントは構造型オブジェクト・クラスおよびコンテンツ・ルールの英数字のオブジェクト識別子のみを指定する必要があります。オプションで、削除するコンテンツ・ルールの関連バージョンを指定することもできます。

21.1.4.4 コンテンツ・ルールを作成および変更するための規則

コンテンツ・ルールは、サブスキーマ・サブエントリ(cn=subschemasubentry)のDITContentRule属性の値として定義されます。これらは、次の規則に準拠する必要があります。

- エントリの構造型オブジェクト・クラスは、エントリに適用可能なコンテンツ・ルールを識別します。構造型オブジェクト・クラスに対するコンテンツ・ルールが存在しない場合、そのオブジェクト・クラスと関連付けられたエントリには、構造型オブジェクト・クラス定義によって許可された属性のみが含まれます。

- コンテンツ・ルールは構造型オブジェクト・クラスと関連付けられるため、同じ構造型オブジェクト・クラスのすべてのエントリが、DITでの位置に関係なく、同じコンテンツ・ルールを持ちます。

- エントリのコンテンツは、そのエントリのobjectClass属性にリストされたオブジェクト・クラスの一貫性を維持している必要があります。具体的には、次の条件を満たしている必要があります。

- objectClass属性にリストされたオブジェクト・クラスの必須属性は、常にエントリ内に存在する必要があります。

- コンテンツ・ルールで指定された補助型オブジェクト・クラスのオプション属性は、objectClass属性にそれらの補助型オブジェクト・クラスがリストされていない場合でも存在できます。

関連項目:
コンテンツ・ルールの作成と管理の詳細は、第21.1.4.2項「補助型オブジェクト・クラスの作成による既存エントリの属性数の拡大」を参照してください。

21.1.4.5 コンテンツ・ルール使用時のスキーマ制約

スキーマ整合性についてオブジェクトを検証する場合、ディレクトリ・サーバーはエントリの構造型オブジェクト・クラスのコンテンツ・ルールを使用します。また、エントリにリストされたその他すべてのオブジェクト・クラスも使用します。

オブジェクト・クラスに複数のコンテンツ・ルールが存在する場合は、エントリの追加または変更時、あるいはデータのバルク・ロード時に、次の規則が適用されます。

- エントリには、各種コンテンツ・ルールにリストされたすべての補助型オブジェクト・クラスからの属性を含めることができます。コンテンツ・ルールにオブジェクト・クラスが指定されていない場合、クライアントは、制限なくディレクトリ・エントリの補助型オブジェクト・クラスを明示的に追加できます。

- エントリには、次のものにリストされたすべての必須属性の値を含める必要があります。

- コンテンツ・ルール

- エントリと関連付けられたオブジェクト・クラス

- エントリに適用可能なコンテンツ・ルールにリストされた補助型オブジェクト・クラス

- オプションで、次のものにリストされたオプション属性の一部またはすべての値をエントリに含めることができます。

- コンテンツ・ルール

- エントリにリストされたオブジェクト・クラス

- エントリに適用可能なコンテンツ・ルールにリストされた補助型オブジェクト・クラス

- 必須と指定された属性は、その属性をオプションと定義する他のすべての定義をオーバーライドします。

21.1.4.6 コンテンツ・ルールにリストされたオブジェクト・クラスの検索

コンテンツ・ルールにリストされた補助型オブジェクト・クラスは、エントリのobjectclass属性にリストされないため、それらのオブジェクト・クラスをエントリ検索時にフィルタとしてリストすることはできません。かわりに、関連する構造型オブジェクト・クラスに基づいて検索します。補助型オブジェクト・クラスに基づいて検索する必要がある場合は、その補助型オブジェクト・クラスをユーザー・オブジェクトのobjectclass属性に明示的に追加します。

たとえば、構造型オブジェクト・クラスinetOrgPersonのコンテンツ・ルールは、補助型オブジェクト・クラスorclUserを指定できます。ただし、これは、ディレクトリ内のすべてのinetOrgPersonエントリにorclUserがobjectclass属性の値として含まれることを意味しません。したがって、フィルタobjectclass=orclUserを使用した検索は失敗します。コンテンツ・ルールに含まれる補助型オブジェクト・クラスを問い合せるかわりに、objectclass=inetOrgPersonなどの構造型オブジェクト・クラスを問い合せる必要があります。

objectclass=orcluserに基づいて検索するには、各エントリのobjectclass属性の値の1つとしてorclUserを追加します。

この注意事項は、アクセス制御ポリシーで使用するフィルタにも適用されます。追加の補助型オブジェクト・クラスと関連付けられたコンテンツ・ルールを使用している場合、検索フィルタでは構造型オブジェクト・クラスのみを使用します。

21.1.5 属性別名の理解

10g(10.1.4.0.1)では、属性名の別名を作成できます。たとえば、属性snに対して、わかりやすい別名surnameを作成できます。属性名に別名を作成すると、ユーザーはLDAP操作で属性名のかわりに別名を指定できます。

属性のLDAPスキーマ定義で、属性に対して別名を定義します。ディレクトリ・スキーマの操作属性attributeTypesが強化され、属性名リストに別名を含めることができるようになりました。これまでのリリースでは、属性名リストの形式は、次のようなものでした。

attributeTypes=( ObjectIdentifier NAME 'AttributeName'  ... )

10g(10.1.4.0.1)では、オプションで次のように指定できます。

attributeTypes=( ObjectIdentifier NAME ( 'AttributeName' 'Alias1' 'Alias2' ...) ... )

これは、RFC 2251およびRFC 2252で指定されているように、LDAPプロトコルと一致します。属性名リストでは、最初の項目は属性の名前として認識され、リストの残りの項目は属性別名として認識されます。たとえば、属性snに別名surnameを指定するには、snのスキーマ定義について次の変更を行います。

attributeTypes=( 2.5.4.4 NAME 'sn' SUP name )

次のように変更します。

attributeTypes=( 2.5.4.4 NAME ( 'sn' 'surname') SUP name )

次の規則が属性別名に適用されます。

- 属性別名は、すべてのスキーマ・コンポーネントにわたり、実際の属性名とその他の属性別名すべてを通して一意である必要があります。属性を定義する場合、attributeTypes定義のNAMEフィールドの最初の値は、実際の属性名である必要があります。実際の属性名の後に、NAMEフィールドで属性別名を定義します。

- 属性別名は、属性名と同じ構文規則に従います。

- 別名のない属性を再定義することにより、属性別名を削除します。

第21.3項「コマンド行を使用したディレクトリ・スキーマの管理」を参照してください。

関連項目:
別名エントリの詳細は、第18章「別名エントリの管理」を参照してください。

21.1.6 LDAP操作でのオブジェクト識別子のサポート

ユーザーは、属性別名と同じように、属性名のかわりにオブジェクト識別子を使用できます。

21.2 Oracle Directory Services Managerを使用したディレクトリ・スキーマの管理

この項の内容は次のとおりです。

- 第21.2.1項「Oracle Directory Services Managerを使用したオブジェクト・クラスの検索」

- 第21.2.2項「Oracle Directory Services Managerを使用したオブジェクト・クラスの追加」

- 第21.2.4項「Oracle Directory Services Managerを使用したオブジェクト・クラスの削除」

- 第21.2.5項「Oracle Directory Services Managerを使用したオブジェクト・クラスのプロパティの表示」

- 第21.2.6項「Oracle Directory Services Managerを使用した新規属性の追加」

- 第21.2.7項「Oracle Directory Services Managerを使用した属性の変更」

- 第21.2.8項「Oracle Directory Services Managerを使用した属性の削除」

- 第21.2.9項「Oracle Directory Services Managerを使用したすべてのディレクトリ属性の表示」

- 第21.2.10項「Oracle Directory Services Managerを使用した属性の検索」

- 第21.2.11項「Oracle Directory Services Managerを使用した新規属性への索引の追加」

- 第21.2.12項「Oracle Directory Services Managerを使用した既存の属性への索引の追加」

- 第21.2.12項「Oracle Directory Services Managerを使用した既存の属性への索引の追加」

- 第21.2.14項「Oracle Directory Services Managerを使用したコンテンツ・ルールの作成」

- 第21.2.15項「Oracle Directory Services Managerを使用したコンテンツ・ルールの変更」

- 第21.2.16項「Oracle Directory Services Managerを使用した一致規則の表示」

- 第21.2.17項「Oracle Directory Services Managerを使用した構文の表示」

21.2.1 Oracle Directory Services Managerを使用したオブジェクト・クラスの検索

Oracle Directory Services Managerを使用してオブジェクト・クラスを検索する手順は、次のとおりです。

1. 第7.4.5項「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動し、Oracle Internet Directoryサーバーに接続します。

2. タスク選択バーで、「スキーマ」を選択します。

3. 左側の「オブジェクト・クラス」パネルを展開します。

4. 「検索」フィールドにキーワードを入力し、「実行」をクリックします。キーワードと一致するオブジェクト・クラスのリストが左側のパネルに表示されます。
ワイルドカードとして"*"および"?"を使用できます。たとえば、*personと入力すると、検索によってpersonで終わるすべてのオブジェクト・クラスが返されます。

検索を終了し、オブジェクト・クラスの全一覧に戻るには、「検索テキストのクリア」を選択します。

21.2.2 Oracle Directory Services Managerを使用したオブジェクト・クラスの追加

Oracle Directory Services Managerを使用してオブジェクト・クラスを追加する手順は、次のとおりです。

1. 「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動し、Oracle Internet Directoryサーバーに接続します。

2. タスク選択バーで、「スキーマ」を選択します。

3. 左側の「オブジェクト・クラス」パネルを展開し、ツールバーの「作成」を選択します。「新規オブジェクト・クラス」ダイアログ・ボックスが表示されます。
または、「オブジェクト・クラス」パネルで、作成するオブジェクト・クラスに類似しているオブジェクト・クラスを選択した後、「類似作成」を選択する方法もあります。「新規オブジェクト・クラス」ダイアログ・ボックスに選択したオブジェクト・クラスの属性が表示されます。このオブジェクト・クラスをテンプレートとして使用して、新規のオブジェクト・クラスを作成できます。

4. 「新規オブジェクト・クラス」ダイアログ・ボックスで、フィールドに情報を入力します。

5. 「作成」を選択します。

関連項目:

- 第3.5.2項「オブジェクト・クラスの型」

- 第3.5.1項「サブクラス、スーパークラスおよび継承」

- オブジェクト・クラスを追加する方法の詳細は、Oracle Directory Services Managerのオンライン・ヘルプを参照してください。

21.2.3 Oracle Directory Services Managerを使用したオブジェクト・クラスの変更

すでにエントリで使用されているオブジェクト・クラスには、オプション属性は追加できますが、必須属性は追加できません。すでに使用されているオブジェクト・クラスにオプション属性を追加する場合、特別なルールは適用されず、属性は空の属性としてエントリに追加されます。

オブジェクト・クラスを変更する手順は、次のとおりです。

1. 第7.4.5項「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動し、Oracle Internet Directoryサーバーに接続します。

2. タスク選択バーで、「スキーマ」を選択します。

3. 左側の「オブジェクト・クラス」パネルを展開します。スクロールバーを使用して、オブジェクト・クラスのアルファベット順のリストを移動します。第21.2.1項「Oracle Directory Services Managerを使用したオブジェクト・クラスの検索」に記載のように、オブジェクト・クラスを検索することもできます。

4. 変更するオブジェクト・クラスをクリックします。ページの右側に「オブジェクト・クラス」タブが表示されます。

5. スーパークラスまたは属性を追加または削除するには、「スーパークラス」、「必須属性」または「オプション属性」リストで選択し、リストの上にあるツールバーの「追加」または「削除」を選択します。
「必須属性」ツールバーの「オプションの作成」を選択し、属性をオプションにします。

スーパークラスまたは属性を編集するには、「スーパークラス」、「必須属性」または「オプション属性」リストで選択し、「編集」を選択します。「オブジェクト・クラス」または「属性」ダイアログが表示されます。これを使用してスーパークラスまたは属性を変更します。「オブジェクト・クラス」ダイアログで、スーパークラス、あるいはスーパークラスの必須属性またはオプション属性を追加、削除または編集できます。変更後、各ダイアログで「OK」をクリックします。

6. 「オブジェクト・クラス」ページで「適用」を選択して変更を適用するか、「元に戻す」を選択して変更を破棄します。

関連項目:

- 第3.5項「オブジェクト・クラス」

- 第3.5.1項「サブクラス、スーパークラスおよび継承」

注意:
属性は、補助型オブジェクト・クラスまたはユーザー定義の構造型オブジェクト・クラスに追加できます。
関連項目: 補助型オブジェクト・クラスへの属性の追加例は、第21.3.3項「コマンド行ツールを使用した補助型またはユーザー定義のオブジェクト・クラスへの新規属性の追加」を参照してください。

21.2.4 Oracle Directory Services Managerを使用したオブジェクト・クラスの削除

注意:
ベース・スキーマからはオブジェクト・クラスを削除しないことをお薦めします。エントリの参照先であるオブジェクト・クラスを削除すると、そのエントリにアクセスできなくなります。
ベース・スキーマからオブジェクト・クラスを削除すると、Oracle Directory Services Managerの不具合の原因になることもあります。

Oracle Directory Services Managerを使用してオブジェクト・クラスを削除する手順は、次のとおりです。

1. 第7.4.5項「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動し、Oracle Internet Directoryサーバーに接続します。

2. タスク選択バーで、「スキーマ」を選択します。

3. 「オブジェクト・クラス」の横の「+」をクリックし、「オブジェクト・クラス」パネルを展開します。スクロールバーを使用して、「オブジェクト・クラス」のアルファベット順のリストを移動します。

4. 削除するオブジェクト・クラスを選択します。

5. ツールバーから「削除」を選択し、確認ダイアログ・ボックスで「削除」をクリックします。

21.2.5 Oracle Directory Services Managerを使用したオブジェクト・クラスのプロパティの表示

スキーマ内のすべてのオブジェクト・クラスを表示する手順は、次のとおりです。

1. 第7.4.5項「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動し、Oracle Internet Directoryサーバーに接続します。

2. タスク選択バーで、「スキーマ」を選択します。

3. 「オブジェクト・クラス」の横の「+」をクリックし、「オブジェクト・クラス」パネルを展開します。スクロールバーを使用して、「オブジェクト・クラス」のアルファベット順のリストを移動します。

4. 表示するオブジェクト・クラスをクリックします。ページの右側に「オブジェクト・クラス」タブが表示されます。

5. オブジェクト・クラスのスーパークラスまたは属性の詳細を表示するには、対象を選択して「編集」をクリックします。オブジェクト・クラス・パネルに戻るには、「取消」をクリックします。

21.2.6 Oracle Directory Services Managerを使用した新規属性の追加

新規属性を追加する手順は、次のとおりです。

1. 第7.4.5項「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動し、Oracle Internet Directoryサーバーに接続します。

2. タスク選択バーで、「スキーマ」を選択します。

3. 必要に応じて、左側の「属性」ペインを展開し、ツールバーの「作成」ボタンを選択します。「新規属性の型」ダイアログ・ボックスが表示されます。
または、「属性」パネルで、作成する属性に類似している属性を選択した後、「類似作成」を選択する方法もあります。「新規属性の型」ダイアログ・ボックスに選択した属性の属性が表示されます。この属性をテンプレートとして使用して、新規の属性を作成できます。

ヒント:
等価、構文および一致規則は数が多く複雑であるため、これらの特性は、類似の既存属性からコピーすると作業が簡単になります。

4. 各フィールドに値を入力します。

5. 「適用」を選択します。

注意:
この属性を使用するには、オブジェクト・クラスに対する属性セットの一部であることを必ず宣言してください。これは、「オブジェクト・クラス」ペインで実行します。詳細は、第21.2.3項「Oracle Directory Services Managerを使用したオブジェクト・クラスの変更」および第21.3.4項「コマンド行ツールを使用したオブジェクト・クラスの変更」を参照してください。

21.2.7 Oracle Directory Services Managerを使用した属性の変更

Oracle Directory Services Managerを使用して属性を変更する手順は、次のとおりです。

1. 第7.4.5項「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動し、Oracle Internet Directoryサーバーに接続します。

2. タスク選択バーで、「スキーマ」を選択します。

3. 「属性」パネルで、変更する属性を選択します。右側に「属性」ページが表示されます。

4. 属性タブで、必要に応じて編集可能なフィールド内の情報を変更または追加します。

5. 「適用」を選択します。

21.2.8 Oracle Directory Services Managerを使用した属性の削除

注意:
ベース・スキーマから属性またはオブジェクト・クラスを削除しないことをお薦めします。
ベース・スキーマから属性またはオブジェクト・クラスを削除すると、Oracle Directory Services Managerの不具合の原因になることがあります。

属性を削除する方法は次のとおりです。

1. 第7.4.5項「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動し、Oracle Internet Directoryサーバーに接続します。

2. タスク選択バーで、「スキーマ」を選択します。

3. 「属性」パネルで、削除する属性を選択します。

4. 左側のパネルのツールバーから「削除」を選択し、確認ダイアログ・ボックスで「削除」をクリックします。

21.2.9 Oracle Directory Services Managerを使用したすべてのディレクトリ属性の表示

Oracle Directory Services Managerを使用して属性を表示する手順は、次のとおりです。

1. 第7.4.5項「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動し、Oracle Internet Directoryサーバーに接続します。

2. タスク選択バーで、「スキーマ」を選択します。

3. 「属性」を展開します。

4. 「属性」パネルでスクロールバーを使用してアルファベット順のリストを移動します。

関連項目:
特定のオブジェクト・クラスの属性を表示する方法は、第21.2.5項「Oracle Directory Services Managerを使用したオブジェクト・クラスのプロパティの表示」を参照してください。

21.2.10 Oracle Directory Services Managerを使用した属性の検索

Oracle Directory Services Managerを使用して属性を検索する手順は、次のとおりです。

1. 第7.4.5項「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動し、Oracle Internet Directoryサーバーに接続します。

2. タスク選択バーで、「スキーマ」を選択します。

3. 左側のペインで「属性」リストを展開します。

4. 左側のペインの「検索」フィールドに検索条件を入力します。アスタリスク(*)または疑問符(?)をワイルドカードとして使用できます。「実行」アイコンをクリックするか、キーボードの[Enter]を押します。

5. 検索結果は左側のペインのリストに表示されます。検索を終了して属性の全一覧に戻るには、「検索テキストのクリア」アイコンをクリックします。

21.2.11 Oracle Directory Services Managerを使用した新規属性への索引の追加

属性に索引を追加する手順は、次のとおりです。

1. 第21.2.6項「Oracle Directory Services Managerを使用した新規属性の追加」または第21.3.5項「ldapmodifyを使用した属性の追加と変更」で説明されているように、属性を作成します。

2. 「新規属性タイプ」ダイアログ・ボックスの「索引付け」ボックスを選択します。

21.2.12 Oracle Directory Services Managerを使用した既存の属性への索引の追加

Oracle Directory Services Managerでは、既存の属性がまだ使用されていない場合にのみその属性に索引を追加できます。

既存の属性に索引を追加する手順は、次のとおりです。

1. 第7.4.5項「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動し、Oracle Internet Directoryサーバーに接続します。

2. タスク選択バーで、「スキーマ」を選択します。

3. 現在索引付けされていない、索引の追加先の属性を選択します。

4. 「属性がカタログ化/カタログから削除されます。」アイコンをクリックします。確認ダイアログが表示された後、「確認」をクリックします。

5. 「索引付け」ボックスに属性が索引付けされたことが示されます。

21.2.13 Oracle Directory Services Managerを使用した属性からの索引の削除

属性から索引を削除する手順は、次のとおりです。

1. 第7.4.5項「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動し、Oracle Internet Directoryサーバーに接続します。

2. タスク選択バーで、「スキーマ」を選択します。

3. 現在索引付けされており、索引の削除対象の属性を選択します。

4. 「属性がカタログ化/カタログから削除されます。」アイコンをクリックします。確認ダイアログが表示された後、「確認」をクリックします。

5. 「索引付け」ボックスに、属性がもう索引付けされていないことが示されます。

21.2.14 Oracle Directory Services Managerを使用したコンテンツ・ルールの作成

コンテンツ・ルールを作成する手順は次のとおりです。

1. 第7.4.5項「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動し、Oracle Internet Directoryサーバーに接続します。

2. タスク選択バーで、「スキーマ」を選択します。

3. 左側のペインで「コンテンツ・ルール」リストを展開します。

4. 「作成」を選択します。「新規コンテンツ・ルール」ダイアログ・ボックスが表示されます。

5. 「新規コンテンツ・ルール」ダイアログ・ボックスの「構造化オブジェクト・クラス」および「オブジェクトID」フィールドに情報を追加します。オプションでラベルを追加します。
「補助クラス」、「必須属性」または「オプション属性」リストの上にあるツールバーの「追加」、「削除」または「編集」アイコンを選択し、項目を追加または削除します。追加の場合、ダイアログから補助クラス、必須属性またはオプション属性を選択します。必要に応じて検索機能を使用します。

6. または、「コンテンツ・ルール」パネルで、作成するコンテンツ・ルールに類似しているコンテンツ・ルールを選択した後、「類似作成」を選択する方法もあります。「新規コンテンツ・ルール」ダイアログ・ボックスに選択したコンテンツ・ルールの属性が表示されます。このコンテンツ・ルールをテンプレートとして使用して、新規のコンテンツ・ルールを作成できます。

7. コンテンツ・ルールを追加するには、「OK」を選択します。

21.2.15 Oracle Directory Services Managerを使用したコンテンツ・ルールの変更

コンテンツ・ルールを変更する手順は次のとおりです。

1. 第7.4.5項「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動し、Oracle Internet Directoryサーバーに接続します。

2. タスク選択バーで、「スキーマ」を選択します。

3. 左側のペインで「コンテンツ・ルール」リストを展開します。

4. 変更するコンテンツ・ルールを選択します。オブジェクト・クラスを検索する場合と同様に検索フィールドにキーワードを入力して、コンテンツ・ルールを検索できます。第21.2.1項「Oracle Directory Services Managerを使用したオブジェクト・クラスの検索」を参照してください。

5. コンテンツ・ルール・タブの適切なフィールドで値を変更します。
「補助クラス」、「必須属性」または「オプション属性」リストの上にあるツールバーの「追加」、「削除」または「編集」アイコンを選択し、項目を追加または削除します。追加の場合、ダイアログから補助クラス、必須属性またはオプション属性を選択します。必要に応じて検索機能を使用します。

6. 「適用」を選択して変更を有効にするか、「元に戻す」を選択して変更を破棄します。

21.2.16 Oracle Directory Services Managerを使用した一致規則の表示

注意:
一致規則は変更できません。

1. 第7.4.5項「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動し、Oracle Internet Directoryサーバーに接続します。

2. タスク選択バーで、「スキーマ」を選択します。

3. 「一致ルール」リストを展開します。リストに一致規則が表示されます。

4. オブジェクト・クラスを検索する場合と同様に検索フィールドにキーワードを入力して、一致規則を検索できます。第21.2.1項「Oracle Directory Services Managerを使用したオブジェクト・クラスの検索」を参照してください。

5. 一致規則を選択し、右側の「一致ルール」タブ・ページにその詳細を表示します。

21.2.17 Oracle Directory Services Managerを使用した構文の表示

注意:
構文は変更できません。

Oracle Directory Services Managerを使用して構文を表示する手順は、次のとおりです。

1. 第7.4.5項「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動し、Oracle Internet Directoryサーバーに接続します。

2. タスク選択バーで、「スキーマ」を選択します。

3. 「構文」リストを展開します。リストに構文名が表示されます。

4. 構文を選択し、右側の「構文」タブ・ページにその詳細を表示します。

21.3 コマンド行を使用したディレクトリ・スキーマの管理

この項の内容は次のとおりです。

- 第21.3.1項「ldapsearchを使用したスキーマの表示」

- 第21.3.2項「コマンド行ツールを使用した新規オブジェクト・クラスの追加」

- 第21.3.3項「コマンド行ツールを使用した補助型またはユーザー定義のオブジェクト・クラスへの新規属性の追加」

- 第21.3.4項「コマンド行ツールを使用したオブジェクト・クラスの変更」

- 第21.3.5項「ldapmodifyを使用した属性の追加と変更」

- 第21.3.6項「ldapmodifyを使用した属性の削除」

- 第21.3.7項「ldapmodifyを使用した属性の索引付け」

- 第21.3.8項「ldapmodifyを使用した属性からの索引の削除」

- 第21.3.9項「カタログ管理ツールを使用した属性の索引付け」

- 第21.3.10項「コマンド行を使用した複数の属性別名を持つ新規属性の追加」

- 第21.3.11項「コマンド行を使用した既存の属性の属性別名の追加または変更」

- 第21.3.12項「コマンド行を使用した属性別名の削除」

- 第21.3.13項「属性別名とLDAPコマンドの使用方法」

- 第21.3.14項「コマンド行ツールを使用したコンテンツ・ルールの管理」

- 第21.3.15項「ldapsearchを使用した一致規則の表示」

- 第21.3.16項「ldapsearchを使用した構文の表示」

21.3.1 ldapsearchを使用したスキーマの表示

次のように入力して、スキーマをファイルに書き込むことができます。

ldapsearch -h OID_host -p OID_port -q -L -D "cn=orcladmin" \
-b "cn=subschemasubentry" -s base "objectclass=*" > schema.ldif

21.3.2 コマンド行ツールを使用した新規オブジェクト・クラスの追加

この例では、LDIF入力ファイルnew_object_class.ldifに、次のようなデータが含まれています。

dn: cn=subschemasubentry
changetype: modify
add: objectclasses
objectclasses: ( 2.16.840.1.113894.9999.12345 NAME 'myobjclass' SUP top STRUCTURAL MUST ( cn $ sn )
MAY ( telephonenumber $ givenname $ myattr ) )

左右のカッコとオブジェクト識別子の間には、必ず空白を入れてください。

このファイルをロードするには、次のコマンドを入力します。

ldapmodify -D "cn=orcladmin" -q -h myhost -p 3060 -f new_object_class.ldif

この例では、次の操作を行います。

- structuralオブジェクト・クラスmyobjclassを追加します。

- オブジェクト識別子に2.16.840.1.113894.9999.12345を指定します。

- スーパークラスとしてtopを指定します。

- 必須属性としてcnとsnを指定します。

- オプション属性としてtelephonenumber、givennameおよびmyattrを許可します。

記述されている属性すべてが、コマンドの実行前に存在している必要があることに注意してください。

abstractオブジェクト・クラスを作成するには、前出の例に従い、語句STRUCTURALを語句ABSTRACTで置き換えます。

21.3.3 コマンド行ツールを使用した補助型またはユーザー定義のオブジェクト・クラスへの新規属性の追加

補助型オブジェクト・クラスまたはユーザー定義の構造型オブジェクト・クラスに新規属性を追加するには、ldapmodifyを使用します。この例では、複合変更操作で、古いオブジェクト・クラス定義を削除して新規の定義を追加します。変更はディレクトリ・サーバーによって1回のトランザクションでコミットされます。既存のデータは影響されません。入力ファイルには次のように指定します。

dn: cn=subschemasubentry
changetype: modify
delete: objectclasses
objectclasses: old value
-
add: objectclasses
objectclasses: new value

たとえば、既存のオブジェクト・クラスcountryに属性changesを追加する場合、入力ファイルは次のようになります。

dn: cn=subschemasubentry
changetype: modify
delete: objectclasses
objectclasses:
( 2.16.840.1.113894.9999.12345 NAME 'country' SUP top STRUCTURAL MUST c MAY
( searchGuide $ description  )  )
-
add: objectclasses
objectclasses:
( 2.16.840.1.113894.9999.12345 NAME 'country' SUP top STRUCTURAL MUST c MAY
( searchGuide $ description  $ changes )  )

このファイルをロードするには、次のコマンドを入力します。

ldapmodify -D "cn=orcladmin" -q -h myhost -p 3060 -f new_attribute.ldif

21.3.4 コマンド行ツールを使用したオブジェクト・クラスの変更

スキーマ・コンポーネントを追加または変更するには、ldapmodifyを使用します。

関連項目:
『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のldapmodifyコマンド行ツールのリファレンス

21.3.5 ldapmodifyを使用した属性の追加と変更

ldapmodifyを使用して新規属性をスキーマに追加するには、システム・プロンプトで次のようなコマンドを入力します。

ldapmodify -D "cn=orcladmin" -q -h host -p port -f ldif_file_name

LDIFファイルには、次のようなデータが含まれています。

dn: cn=subschemasubentry
changetype: modify
add: attributetypes
attributetypes: ( 1.2.3.4.5 NAME 'myattr' SYNTAX
'1.3.6.1.4.1.1466.115.121.1.38' )

属性を単一値として指定するには、LDIFファイルの属性定義エントリに、空白で囲んだキーワードSINGLE-VALUEを含めます。

Oracle Directory Services Managerまたはldapsearchコマンド行ツールを使用して、指定した構文のオブジェクトIDを検索できます。

関連項目:

- ldapmodifyとそのオプションの詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のldapmodifyコマンド行ツールのリファレンスを参照してください。

- Oracle Directory Services Managerまたはldapsearchを使用した構文の表示方法は、第21.3.16項「ldapsearchを使用した構文の表示」を参照してください。

21.3.6 ldapmodifyを使用した属性の削除

注意:
削除できるのはユーザー定義属性のみです。ベース・スキーマの属性は削除しないでください。

ldapmodifyを使用して属性を削除するには、システム・プロンプトで次のようなコマンドを入力します。

ldapmodify -D "cn=orcladmin" -q -h host -p port -f ldif_file_name

LDIFファイルには、次のようなデータが含まれています。

dn: cn=subschemasubentry
changetype: modify
delete: attributetypes
attributetypes: ( 1.2.3.4.5 NAME 'myattr' SYNTAX
'1.3.6.1.4.1.1466.115.121.1.38' )

Oracle Directory Services Managerまたはldapsearchコマンド行ツールを使用して、指定した構文のオブジェクトIDを検索できます。

関連項目:

- ldapmodifyとそのオプションの詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のldapmodifyコマンド行ツールのリファレンスを参照してください。

- 構文の表示方法は、第21.3.16項「ldapsearchを使用した構文の表示」または第21.2.17項「Oracle Directory Services Managerを使用した構文の表示」を参照してください。

21.3.7 ldapmodifyを使用した属性の索引付け

Oracle Internet Directory 11g リリース1(11.1.1.6.0)では、新規インストールで新しい自動カタログ機能がデフォルトで有効になります。以前のリリースからアップグレードした場合も、これを有効にできます。この機能を有効にすると、属性を検索したときに、Oracle Internet Directoryで自動的にcatalogコマンドが起動され、属性が索引付けされます。自動カタログ機能を有効化しないで、カタログ化されていない以前の属性を検索フィルタで使用する場合は、以前のリリースと同様に、その属性をカタログ・エントリに追加する必要があります。

ldapmodifyを使用して、カタログ・エントリに属性を追加できます。

属性を追加するには、ldapmodifyを使用してLDIFファイルをインポートします。たとえば、属性displayNameを索引付けするには、ldapmodifyを使用して次のLDIFファイルをインポートします。

dn: cn=catalogs
changetype: modify
add: orclindexedattribute
orclindexedattribute: displayName

システム・プロンプトで次のようなコマンドを入力します。

ldapmodify -D "cn=orcladmin" -q -h host -p port -f ldif_file_name

属性を索引付けするために、ldapmodifyコマンドでカタログ管理ツールcatalogが起動されます。このツールの詳細は、第15.7項「catalogを使用した既存の属性の索引の作成および削除」を参照してください。

21.3.8 ldapmodifyを使用した属性からの索引の削除

ldapmodifyを使用して属性から索引を削除するには、LDIFファイルでdeleteを指定します。次に例を示します。

dn: cn=catalogs
changetype: modify
delete: orclindexedattribute
orclindexedattribute: displayName

関連項目:
『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のldapmodifyコマンド行ツールのリファレンス

21.3.9 カタログ管理ツールを使用した属性の索引付け

ldapmodifyのかわりにカタログ管理ツールを使用して、属性に索引付けしたり、属性から索引を削除することができます。第15.7項「catalogを使用した既存の属性の索引の作成および削除」を参照してください。

関連項目:
『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のcatalogコマンド行ツールのリファレンス

注意:
Oracle Internet Directoryでインストールされたベース・スキーマによって作成された索引ではないことが確信できない場合は、catalog delete=Tオプションを使用して属性から索引を削除しないように注意してください。ベース・スキーマ属性から索引を削除すると、Oracle Internet Directoryの操作に悪影響を及ぼす場合があります。

21.3.10 コマンド行を使用した複数の属性別名を持つ新規属性の追加

LDIFファイルを作成し、ldapmodifyを次の構文で使用することにより、属性別名の追加、変更または削除を行います。

ldapmodify -D "cn=orcladmin" -q -h host -p port -f ldif_file_name

注意:
識別名は属性ではありません。スキーマ内ではdnを定義できません。したがって、dnの別名を作成できません。

次のLDIFファイルでは、複数の属性別名myalias1とmyalias2を持つ属性myattrを追加します。

dn: cn=subschemasubentry
changetype: modify
add: attributetypes
attributetypes: ( 1.2.3.4.5 NAME ( 'myattr' 'myalias1' 'myalias2' ) SYNTAX
'1.3.6.1.4.1.1466.115.121.1.38' )

21.3.11 コマンド行を使用した既存の属性の属性別名の追加または変更

次のLDIFファイルでは、属性別名surnameとmysurNameを、既存の属性snに追加します。

dn: cn=subschemasubentry
changetype: modify
delete: attributeTypes
attributeTypes: ( 2.5.4.4 NAME 'sn' SUP name )
-
add: attributeTypes
attributeTypes: ( 2.5.4.4 NAME ( 'sn' 'surname' 'mysurName' ) SUP name )

システム・プロンプトで次のようなコマンドを入力します。

ldapmodify -D "cn=orcladmin" -q -h host -p port -f ldif_file_name

21.3.12 コマンド行を使用した属性別名の削除

属性別名の削除にはldapmodifyコマンドを使用します。次のLDIFファイルでは、属性snから属性別名mysurNameは削除しますが、属性別名surNameは削除しません。

dn: cn=subschemasubentry
changetype: modify
delete: attributeTypes
attributeTypes: ( 2.5.4.4 NAME ( 'sn' 'surname' 'mysurName' ) SUP name )
-
add: attributeTypes
attributeTypes: ( 2.5.4.4 NAME ( 'sn' 'surname' ) SUP name )

次のLDIFファイルでは、属性別名のsurnameとmysurNameの両方を属性snから削除します。

dn: cn=subschemasubentry
changetype: modify
delete: attributeTypes
attributeTypes: ( 2.5.4.4 NAME ( 'sn' 'surname' 'mysurName' ) SUP name )
-
add: attributeTypes
attributeTypes: ( 2.5.4.4 NAME 'sn' SUP name )

21.3.13 属性別名とLDAPコマンドの使用方法

LDAPスキーマで属性別名を定義した後、ユーザーはLDAP操作で属性名に別名を代入できます。次の例は、使用するコマンドと予想される結果を示します。

- 第21.3.13.1項「属性別名とldapsearchの使用方法」

- 第21.3.13.2項「属性別名とldapaddの使用方法」

- 第21.3.13.3項「属性別名とldapmodifyの使用方法」

- 第21.3.13.4項「属性別名とldapdeleteの使用方法」

- 第21.3.13.5項「属性別名とldapmoddnの使用方法」

表21-1は、例で使用されている別名と、別名が表す属性名を示しています。

表21-1 例で使用されている属性別名

別名

属性名

userid

uid

organizationalunit

ou

country

c

organization

o

surname

sn

commonname

cn

phone

telephonenumber

21.3.13.1 属性別名とldapsearchの使用方法

LDAPサーバーは、ldapsearch操作で、検索フィルタ文字列、ベース識別名、必須属性リスト内の属性別名を認識します。ユーザーが必須属性リストを使用して別名を明示的に要求しなければ、検索結果には実際の属性名が含まれます。たとえば、ユーザーが、ベース識別名で別名organizationalUnit、countryおよびorganizationを、フィルタ文字列で別名surnameを使用して、次の検索を指定するとします。

ldapsearch -p 3060 -h myhost \
-b "organizationalUnit=dev,country=us,organization=myorg" \
-s sub "surname=brown"

検索は次のような結果を返します。

uid=mbrown,ou=dev,c=us,o=myorg
uid=mbrown
sn=Brown
cn=Mark Brown
telephonenumber;office=444006
telephonenumber;mobile=555006
objectclass=organizationalPerson
objectclass=top
objectclass=person

次に、ユーザーが、別名surname、commonnameおよびuseridを次のように必須属性リストに含めることにより、明確に別名を要求するとします。

ldapsearch -p 3060 -h myhost \
-b "organizationalUnit=dev,country=us,organization=myorg" \
-s sub "surname=brown" surname commonname userid phone

ユーザーが別名を明確に含めたので、検索は次のような結果を返します。

uid=mbrown,ou=dev,c=us,o=myorg
surname=Brown
commonname=Mark Brown
userid=mbrown
phone;office=444006
phone;mobile=555006

21.3.13.2 属性別名とldapaddの使用方法

LDAPサーバーは、追加操作中に、属性名のかわりに属性別名を認識します。LDAPサーバーはエントリを保存する際、別名を実際の属性名に置換します。

コマンド行の書式は、次のとおりです。

ldapadd -h host -p port -D cn=orcladmin -q -f ldif_file_name

ユーザーはLDIFファイルを次のように指定できます。

dn: userid=mbrown,organizationalUnit=dev,country=us,organization=myorg
objectclass: account
objectclass: organizationalPerson
userID: mbrown
surname: Brown
commonName: Mark Brown
userpassword: password
phone;office: 444006
phone;mobile: 555006

エントリは、ファイルに別名のかわりに属性名が含まれているかのように保存されます。ただし、後続のLDAP検索では、追加または変更時に識別名が入力されたので、識別名が返されます。

dn: userid=mbrown,organizationalUnit=dev,country=us,organization=myorg

これはLDAP検索結果を得るための標準動作です。識別名は常に、エントリの作成時に使用されたものと同じ書式で返されます。

21.3.13.3 属性別名とldapmodifyの使用方法

LDAPサーバーは、変更操作中に、属性名のかわりに属性別名を認識します。

コマンド行の書式は、次のとおりです。

ldapmodify -D "cn=orcladmin" -q -h host -p port -f ldif_file_name

ユーザーはLDIFファイルを次のように指定できます。

dn:
userid=mbrown,organizationalUnit=dev,country=us,organization=myorg
changetype: modify
replace: surname
surname: davis

エントリは、ファイルに別名のかわりに属性名が含まれているかのように保存されます。ただし、後続のLDAP検索では、追加または変更時に識別名が入力されたので、識別名が返されます。

dn: userid=mbrown,organizationalUnit=dev,country=us,organization=myorg

これはLDAP検索結果を得るための標準動作です。識別名は常に、エントリの作成時に使用されたものと同じ書式で返されます。

21.3.13.4 属性別名とldapdeleteの使用方法

LDAPサーバーは、削除操作に指定された識別名で属性別名を認識します。たとえば、ユーザーが次のように検索フィルタで別名userid、organizationalUnit、countryおよびorganizationを指定してリクエストをするとします。

ldapdelelete -D "cn=orcladmin" -q -p 3060 \
-h myhost  "userid=mbrown,organizationalUnit=dev,country=us,organization=myorg"

サーバーは、ユーザーが次のように入力したものとしてエントリを削除します。

ldapdelelete -D "cn=orcladmin" -q -p 3060 \
-h myhost  "uid=mbrown,ou=dev,c=us,o=myorg"

21.3.13.5 属性別名とldapmoddnの使用方法

LDAPサーバーは、識別名、新規相対識別名および新規親識別名のオプションで、属性別名を認識します。たとえば、ユーザーが次のコマンド行を入力するとします。

ldapmoddn -D "cn=orcladmin" -q \
-b "userid=mbrown,organizationalUnit=dev,country=us,organization=myorg"\
-R "userid=mdavis"

LDAPサーバーは、コマンド行をユーザーが次のように入力しものとして解釈します。

ldapmoddn -D "cn=orcladmin" -q -b "uid=mbrown,ou=dev,c=us,o=myorg" \
-R "uid=mdavis"

エントリは、ファイルに別名のかわりに属性名が含まれているかのように保存されます。ただし、後続のLDAP検索では、追加または変更時に識別名が入力されたので、識別名が返されます。

dn: userid=mbrown,organizationalUnit=dev,country=us,organization=myorg

これはLDAP検索結果を得るための標準動作です。識別名は常に、エントリの作成時に使用されたものと同じ書式で返されます。

21.3.14 コマンド行ツールを使用したコンテンツ・ルールの管理

コンテンツ・ルールの形式は次のとおりです。

DITContentRule  ::=  SEQUENCE  {

oids                             ALPHA-NUMERIC-OID,
structuralObjectClass            OBJECT-CLASS,
LABEL                            CONTENT-LABEL OPTIONAL,
auxiliaries                      SET (1..MAX) OF OBJECT-CLASS OPTIONAL,
mandatory                        SET (1..MAX) OF ATTRIBUTE OPTIONAL,
optional                         SET (1..MAX) OF ATTRIBUTE OPTIONAL,
precluded                        SET (1..MAX) OF ATTRIBUTE OPTIONAL
}

ldapmodifyで次のようなLDIFファイルを指定してコンテンツ・ルールを追加できます。

dn: cn=subschemasubentrychangetype: modify
add: contentrules
contentrules: (  2.16.840.1.113894.9999.1.1 OBJECTCLASS 'exampleObjClassName' LABEL abc AUX exampleAuxObjClassName MUST businessCategory MAY ( description $ host ) )

表21-2に、パラメータを示します。属性およびオブジェクト・クラスの名前では、大文字と小文字が区別されることに注意してください。

表21-2 コンテンツ・ルールのパラメータ

パラメータ

説明

oids

オブジェクト・クラスまたは属性定義のオブジェクト識別子と同様の、コンテンツ・ルールの一意のオブジェクト識別子(oids)。これは、2.16.840.1.113894で始まり、その後ろに.9999またはサイト固有の接頭辞が続いている一意な数値である必要があります。

LABEL

ディレクトリで適用されるコンテンツ・ルールのコンテンツ・ラベル。

structuralObjectClass

コンテンツ・ルールが適用される構造型オブジェクト・クラス。

auxiliaries

コンテンツ・ルールが適用されるエントリで使用可能な補助型オブジェクト・クラス。

mandatory

コンテンツ・ルールが適用されるエントリに含まれるユーザー属性タイプ。これは、指定された構造型および補助型オブジェクト・クラスとの関連付けの結果としてエントリに含まれる必須属性に対する追加の属性です。

optional

コンテンツ・ルールが適用されるエントリに含めることができるユーザー属性タイプ。これは、指定された構造型および補助型オブジェクト・クラスとの関連付けの結果としてエントリに含めることができる属性に対する追加の属性です。

21.3.15 ldapsearchを使用した一致規則の表示

注意:
一致規則は変更できません。

一致規則を表示するには、次のように入力します。

ldapsearch -L -D "cn=orcladmin" -p port -q -b "cn=subschemasubentry" -s base "objectclass=*" matchingrules

関連項目:
『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のldapsearchコマンド行ツールのリファレンス

21.3.16 ldapsearchを使用した構文の表示

注意:
構文は変更できません。

構文を表示するには、次のように入力します。

ldapsearch -L -D "cn=orcladmin" -p port -q -b "cn=subschemasubentry" -s base "objectclass=*" ldapsyntaxes

関連項目:
『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のldapsearchコマンド行ツールのリファレンス

22 参照整合性の構成

この章では、Oracle Enterprise Manager Fusion Middleware ControlおよびLDAPコマンド行ユーティリティを使用して、Oracle Internet Directoryで参照整合性を有効化、無効化および構成する方法について説明します。また、参照整合性違反を検出して修正する方法についても説明します。

この章の内容は次のとおりです。

- 第22.1項「参照整合性の構成の概要」

- 第22.2項「Fusion Middleware Controlを使用した参照整合性の有効化」

- 第22.3項「Fusion Middleware Controlを使用した参照整合性の無効化」

- 第22.4項「コマンド行を使用した参照整合性の有効化」

- 第22.5項「コマンド行を使用した参照整合性に関する特定の属性の構成」

- 第22.6項「コマンド行を使用した参照整合性の無効化」

- 第22.7項「参照整合性違反の検出および修正」

22.1 参照整合性の構成の概要

参照整合性とは、データ・セット間で一貫した関係を維持するプロセスです。Oracle Internet Directoryで参照整合性を有効にした場合、ディレクトリ内のエントリを更新すると、そのエントリを参照する他のエントリもサーバーによって更新されます。たとえば、ユーザーのエントリをディレクトリから削除し、そのユーザーがあるグループのメンバーだとすると、サーバーはユーザーをグループからも削除します。参照整合性が無効の場合、ユーザーは手動で削除されるまでそのグループのメンバーであり続けます。参照整合性はデフォルトでは無効です。

注意:
レプリケーションのブートストラップ・プロセス中に、参照整合性を無効にします。参照整合性が有効になると、ブートストラップは失敗します。

参照整合性は、次の2つの状況で効力を生じます。

- 削除: エントリが削除されると、このエントリ識別名を参照するすべての識別名属性が削除されます。

- 変更: エントリの識別名が変更(名前変更)されると、このエントリ識別名を参照するすべての属性が変更されます。

11g リリース1(11.1.1)以降、Oracle Internet Directoryサーバーにより、参照整合性が適用されます。LDAPの追加、変更、削除および名前変更操作のすべてについて、サーバーによりリクエストがモニターされ、必要な識別名参照が更新されます。

参照整合性は、orclRIenabledおよびorclRIattrの2つの構成パラメータによって制御されます。

- パラメータorclRIenabledは、参照整合性レベルを制御します。orclRIenabledの値は、次のとおりです。

- 0: 参照整合性は無効です。

- 1: 参照整合性は、memberおよびuniquemember属性に対してのみ有効です。

- 2: 参照整合性は、属性memberおよびuniquememberのorclRIattrで指定された識別名構文属性のリストに対して有効です。

- orclRIenabledを2に設定すると、パラメータorclRIattrの値は有効になります。orclRIattrの値は、参照整合性が有効な属性のリストです。

参照整合性が有効になると、厳密に適用されます。たとえば、memberまたはuniquememberが現在DITの一部ではないグループ・エントリは追加できません。

22.2 Fusion Middleware Controlを使用した参照整合性の有効化

Oracle Enterprise Manager Fusion Middleware Controlを使用して参照整合性を構成し、有効にするには、次の手順を実行します。

1. Oracle Internet Directoryのメニューから「管理」、「共有プロパティ」を選択し、「一般」を選択します。

2. 「参照整合性」リストから値を選択します。

- GroupOfNameおよびGroupOfUniqueNameの有効化

- GroupOfName、GroupOfUniqueNameおよび構成済のDN属性の有効化

3. 「適用」を選択します。

22.3 Fusion Middleware Controlを使用した参照整合性の無効化

Oracle Enterprise Manager Fusion Middleware Controlを使用して参照整合性を無効にするには、次の手順を実行します。

1. Oracle Internet Directoryのメニューから「管理」、「共有プロパティ」を選択し、「一般」を選択します。

2. 参照整合性の有効化リストから「無効」を選択します。

22.4 コマンド行を使用した参照整合性の有効化

ディレクトリ内の参照整合性を有効化するには、ldapmodifyを使用してDSA構成エントリ内のパラメータorclRIenabledの値を変更します。

cn=dsaconfig,cn=configsets,cn=oracle internet directory.

値は1または2に設定できます。

値を1に設定すると、GroupofNamesおよびGroupofUniqueNamesに対して参照整合性が有効になります。

orclRIenabledの値を2に設定すると、GroupofNames、GroupofUniqueNamesおよび特定の構成済属性に対して参照整合性が有効になります。次の項では、特定の属性の構成について説明します。

たとえば、次のようなコマンド行を使用します。

ldapmodify -D cn=orcladmin -q -p portNum -h hostname -f ldifFile

この場合、次のようなLDIFファイルを使用します。

dn: cn=dsaconfig, cn=configsets, cn=oracle internet directory
changetype: modify
replace: orclRIenabled
orclRIenabled: 2

orclRIenabledに対する変更はすぐに有効になります。

22.5 コマンド行を使用した参照整合性に関する特定の属性の構成

orclRIenabledの値を2に設定すると、GroupofNames、GroupofUniqueNamesおよび特定の構成済属性に対して参照整合性が有効になります。

参照整合性に関する特定の属性は、catalogに引数rienable=TRUE、add=trueおよびattribute=name_of_attributeを指定して構成できます。これにより、参照整合性が適用される識別名構文属性のリストが含まれるorclRIattrに属性が追加されます。参照整合性に関する特定の属性は、catalogに引数rienable=TRUE、delete=trueおよびattribute=name_of_attributeを指定して削除できます。これによってorclRIattrから属性が削除されます。

注意:

- ldapmodifyを使用してorclRIattrの値を変更することはできません。catalogコマンドを使用する必要があります。

- catalogを使用する場合、ORACLE_INSTANCE環境変数を設定する必要があることに注意してください。

次の例は、属性managerに対して参照整合性を有効にしています。

catalog connect="connect_str" add=true rienable="TRUE" attribute="manager"

次の例では、属性managerに対して参照整合性を無効にします。

catalog connect="connect_str" delete=true rienable="TRUE" attribute="manager"

22.6 コマンド行を使用した参照整合性の無効化

ディレクトリ内の参照整合性を無効化するには、DSA構成エントリでorclRIenabledの値を0に設定します。

cn=dsaconfig,cn=configsets,cn=oracle internet directory.

22.7 参照整合性違反の検出および修正

DITに根本的な違反がある場合、参照整合性を有効化しようとすると、エラーが発生します。oiddiagツールを実行して違反を確認し、修正してから、参照整合性を有効にする必要があります。oiddiagツールには、すべての参照整合性違反をLDIF形式で報告するオプションOidDiagDC10があります。ldapmodifyツールとともにLDIFファイルを使用することにより、報告されたすべてのエントリを修正できます。この手順は次のとおりです。

1. oiddiagをオプションlistdiags=trueとともに実行します。デフォルトの出力ファイルは、ORACLE_INSTANCE/diagnostics/logs/OID/tools/oiddiag.txtです。

2. 出力ファイルoiddiag.txtを編集し、次の行のみが含まれるようにします。

oracle.ldap.oiddiag.dc.OidDiagDC10

3. oiddiagをオプションcollect_sub=trueとともに実行します。

関連項目:

- 『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のoiddiagコマンドのリファレンス

- oiddiagの使用メッセージ。次のように入力します。

oiddiag -help

注意:
Windowsでは、oiddiagコマンドのファイル名はoiddiag.bat.です。

23 監査の管理

この章では、Oracle Enterprise Manager Fusion Middleware Control、Oracle WebLogic Scripting Tool (WLST)およびLDAPコマンド行ユーティリティを使用して、Oracle Internet Directoryに固有の情報の監査を管理する方法について説明します。

監査の管理タスクの詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。

この章の内容は次のとおりです。

- 第23.1項「監査の概要」

- 第23.2項「Fusion Middleware Controlを使用した監査の管理」

- 第23.3項「WLSTを使用した監査の管理」

- 第23.4項「コマンド行からの監査の管理」

23.1 監査の概要

この概要の項目は次のとおりです。

- 第23.1.1項「監査ストアの構成」

- 第23.1.2項「Oracle Internet Directoryの監査構成」

- 第23.1.3項「レプリケーションとOracle Directory Integration Platformの監査構成」

- 第23.1.4項「監査レコードのフィールド」

- 第23.1.5項「監査レコード記憶域」

- 第23.1.6項「監査レポートの生成」

監査とは、セキュリティ要求およびその要求に対する結果に関連する情報を収集および格納するプロセスです。これにより、否認防止を目的として、選択されたシステム・アクティビティの電子証跡が提供されます。監査は一定の監査基準に基づいて、特定のセキュリティ・イベントや管理操作を追跡するように構成できます。監査レコードは集中型リポジトリ(LDAP、データベースまたはファイル)に保持され、これを使用して監査レポートを作成、表示および格納できます。11gリリース1 (11.1.1)のリリースでは、Oracle Internet DirectoryでOracle Fusion Middlewareと統合された監査フレームワークが使用されています。Oracle Internet Directoryは、このフレームワークを使用してセキュリティ関連の重要な操作を監査します。このフレームワークの機能は次のとおりです。

- ASコンポーネントから監査情報を収集するAPI

- すべてのASコンポーネントで使用される共通監査レコード形式

- 企業内のコンポーネントによって生成される監査レコードを収集する監査リポジトリ・データベース(顧客はオプションでAudit Vaultをリポジトリとして使用することもできます)

- 監査機能によって取得した情報のタイプを制御するための管理インタフェース

この章を読む前に、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の監査に関する章を参照してください。

新しいOracle Internet Directory監査フレームワークには、次の利点があります。

- 他のOracle Application Serverコンポーネントと同じレコード形式を使用します。

- パフォーマンスとセキュリティの向上のため、レコードはOracle Databaseの表に格納されます。

- レコードをAudit Vaultに格納して、セキュリティをさらに向上できます。

- 管理者として、Enterprise Managerを使用して監査レコードに取得される情報のタイプを構成できます。

- 構成変更はすぐに有効になります。

- 管理者は監査レコードを表示できます。

- Enterprise Manager

- XMLパブリッシャに基づくサマリー・レポート

インスタンス管理者によって行われるすべての監査構成が監査されます。これは無効にすることができません。

関連項目:
監査リポジトリおよび監査フィルタの構成の詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。

23.1.1 監査ストアの構成

監査レコードがデータベースに確実に保存されるように監査ストアを構成する必要があります。監査の管理タスクの詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の「監査の構成および管理」の章の次の項を参照してください。

- 監査ストアの管理

- データベース・ストアの拡張管理

23.1.2 Oracle Internet Directoryの監査構成

Oracle Internet Directoryの監査構成は、インスタンス固有のエントリの3つの属性から構成されます。

cn=componentname,cn=osdldapd,cn=subconfigsubentry

表23-1にこれらの属性を示します。

表23-1 Oracle Internet Directoryの監査構成属性

属性

説明

orclAudFilterPreset

プリセットは、None、Low、Medium、AllおよびCustomです。Lowは、アカウント管理、パスワード変更およびデータ項目属性の変更イベントを指定し、Mediumは、Lowのすべてのイベントと認証失敗イベントを指定します。

orclAudCustEvents

監査されるイベント名とカテゴリ名のカンマ区切りのリスト。次に例を示します。

Authentication.SUCCESSESONLY,
Authorization(Permission -eq 'CSFPermission")

カスタム・イベントは、orclAudFilterPresetがCustomの場合のみ適用できます。

orclAudSplUsers

orclAudFilterPresetがNoneの場合でも、監査が常に有効化されるユーザーのカンマで区切られたリスト。次に例を示します。

cn=orcladmin.

詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。

23.1.3 レプリケーションとOracle Directory Integration Platformの監査構成

レプリケーションとOracle Directory Integration Platform監査は、インスタンス固有の構成エントリの属性orclextconfflagの値を変更することで有効にできます。デフォルト値は3で、レプリケーションとOracle Directory Integration Platform監査の両方が無効です。両方を有効にするには、7に変更します。これがorclextconfflagに行える唯一の変更で、これ以外は内部属性です。

第23.4.3項「レプリケーションおよびOracle Directory Integration Platformの監査の有効化」を参照してください。

23.1.4 監査レコードのフィールド

監査レコードには次のフィールドがあります。

- イベント・カテゴリ: イベントのクラス(認証、認可など)

- イベント名

- イニシエータ: 操作を開始するユーザー

- ステータス: 成功または失敗

- 認証方式

- セッションID: 接続ID

- ターゲット: 操作の実行対象となるユーザー

- イベント日時

- リモートIP: クライアントのソースIPアドレス

- コンポーネント・タイプ: OID

- ECID

- リソース: 操作が行われるエントリまたは属性。

23.1.5 監査レコード記憶域

監査情報は、最終的な場所に書き込まれる前に、バスストップと呼ばれる場所に一時的に格納されます。

このファイルは、ディレクトリORACLE_INSTANCE/auditlogs/componentType/componentNameにあります。

監査ファイルは、XMLファイルまたはデータベースに永続的に格納されます。XMLファイルは、監査レコードのデフォルトの記憶域メカニズムです。Oracleインスタンスごとに1つのXMLリポジトリがあります。特定のOracleインスタンス内で実行されるすべてのコンポーネントについて生成される監査レコードは、同じリポジトリに格納されます。データベース・リポジトリを使用している場合、ドメイン内のすべてのOracleインスタンス内のすべてのコンポーネントによって生成される監査レコードは、同じリポジトリに格納されます。

23.1.6 監査レポートの生成

監査レポートの生成の詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の監査の分析およびレポートに関する章を参照してください。Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイドの章「監査の構成と管理」に、Oracle Internet Directoryの例が掲載されています。

23.2 Fusion Middleware Controlを使用した監査の管理

11gリリース1 (11.1.1)で導入されたOracle Fusion Middleware監査フレームワークでは、Oracle Internet Directoryなどのシステム・コンポーネントを含むOracleミドルウェア製品の集中管理された監査フレームワークが提供されます。

監査の管理には、Oracle Enterprise Manager Fusion Middleware Controlを使用できます。インタフェースは、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』に記載されているように、すべてのOracle Fusion Middlewareコンポーネントに対して基本的に同じです。

Oracle Internet Directory監査を管理する手順は、次のとおりです。

1. Oracle Enterprise Manager Fusion Middleware Controlにログインします。

2. 「Oracle Internet Directory」メニューから、「セキュリティ」を選択し、「監査ポリシー設定」を選択します。

3. 「監査ポリシー」リストから、「カスタム」を選択して独自のフィルタを構成するか、または事前設定済フィルタ(「なし」、「低」または「中」のいずれか)を選択します。(Fusion Middleware ControlからはAllを設定できません。)

4. 障害のみを監査する場合は、「障害のみ選択」をクリックします。この手順は、前の手順で「カスタム」を選択している場合にのみ可能です。

5. フィルタを構成するには、フィルタ名の横にある「編集」アイコンをクリックします。そのフィルタに対して「フィルタの編集」ダイアログが表示されます。

6. フィルタ条件は、ボタン、メニューからの選択、および文字列の入力で指定します。条件の対象には、HostID、HostNwaddr、InitiatorDN、TargetDN、Initiator、Remote IPおよびRolesがあります。条件のテストには、-contains、-contains_case、endswith、endswith_case、-eq、-ne、-startswithおよび-startswith-caseがあります。テストに使用する値は文字列として入力します。グループ化する場合はカッコを、組合せを作成する場合はANDおよびORを使用します。

7. 条件を追加するには、「追加」アイコンをクリックします。

8. フィルタが完了したら、「適用」をクリックして変更を保存するか、「元に戻す」をクリックして変更を破棄します。

Oracle Internet Directoryでは、その監査構成は表23-1「Oracle Internet Directoryの監査構成属性」に示すインスタンス固有の3つの構成エントリ属性に格納されます。「監査ポリシー」ページのフィールドと属性の対応を表23-2に示します。

表23-2 Fusion Middleware Controlの監査構成属性

フィールドまたはヘッダー

構成属性

監査ポリシー

orclAudFilterPreset

名前、障害のみ選択、監査の有効化、フィルタ

orclAudCustEvents

常時監査するユーザー

orclAudSplUsers

23.2.1 Oracle Internet Directoryの機密データ属性の監査

Oracle Fusion Middleware監査フレームワークを使用してOracle Internet Directoryのカスタム監査ポリシーを定義し、アクセス制御、ユーザー資格証明、構成などの機密データに関連付けられた属性をモニターできます。

たとえば、アクセス制御ポリシー・ポイント(ACP)に対する変更を監査するため、orclaciやorclentrylevelaciなどの属性のModifyDataItemAttributesイベント・タイプを取得するように監査ポリシーを構成できます。

ModifyDataItemAttributesイベント・タイプは、ldapmodify操作によって生成されます。このイベントのイニシエータ属性は、LDAP操作を実行するユーザーの識別名で、リソース属性は、操作が実行されるLDAP属性のエントリ識別名です。

ModifyDataItemAttributesイベント・タイプを取得することで、属性に対するすべてのACP変更をモニターできます。たとえば、orclaci属性やorclentrylevelaci属性が変更されたかどうかを確認できます。

orclaci属性やorclentrylevelaci属性に対する変更をモニターする監査ポリシーを作成する手順は、次のとおりです。

1. Oracle Enterprise Manager Fusion Middleware Controlにログインします。

2. 左側のパネルで、監査するOracle Internet Directoryインスタンスを右クリックします。例: oid1

3. Oracle Internet Directoryのコンポーネント・メニューで、「セキュリティ」→「監査ポリシー」に移動します。「監査ポリシー設定」ページが表示されます。

4. 「監査レベル」のドロップダウン・リストから「カスタム」を選択します。

5. DataAccessイベント・カテゴリおよびModifyDataItemAttributesイベント・タイプの「監査の有効化」を確認します。

6. 成功した変更または失敗した変更(あるいはその両方)のどちらを監査するかに応じて、「監査の有効化」列の適切なチェック・ボックスを選択します。

7. 監査ポリシーにフィルタを追加するため、「フィルタの編集」鉛筆アイコンをクリックしてフィルタを構成します。

1. 「条件」を「リソース」に設定します。

2. 演算子を-eqに設定します。

3. リソース属性をorclaciとして指定します。

4. 「追加」アイコンをクリックします。フィルタは次のようになります。

Resource -eq "orclaci"

5. orclentrylevelaci属性をフィルタに追加するため、「OR」をクリックし、新しい条件(リソース、-eq、orclentrylevelaci)を定義して「追加」をクリックします。フィルタは次のようになります。

Resource -eq "orclaci" -or Resource -eq "orclentrylevelaci"

8. 「適用」をクリックして監査ポリシーを保存します(または、「元に戻す」をクリックして破棄します)。

デプロイメントで必要な場合、このポリシーに他の属性を追加したり、属性、操作およびアクティビティを監査する他のポリシーを作成できます。詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のFusion Middleware Controlによるシステム・コンポーネントの監査ポリシーの管理に関する項を参照してください。

23.3 WLSTを使用した監査の管理

『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のWLSTを使用した監査ポリシーの管理に関する項に記載のように、wlstを使用して監査を管理できます。コマンドgetAuditPolicy()、setAuditPolicy()またはlistAuditEvents()を使用します。

Oracle Internet Directoryなど監査ポリシーをローカルで管理するコンポーネントについては、コマンドの引数としてMBean名を含める必要があります。監査MBeanの名前の形式は次のとおりです。

oracle.as.management.mbeans.register:type=component.auditconfig,name=auditconfig1,instance=INSTANCE,component=COMPONENT_NAME

次に例を示します。

oracle.as.management.mbeans.register:type=component.auditconfig,name=auditconfig1,instance=instance1,component=oid1

使用する必要のある別のwlstコマンドはinvoke()です。第9.3項「WLSTを使用したシステム構成属性の管理」に記載のとおり、属性に変更を加える前にMBeanが現在のサーバー構成を持っていることを確認する必要があります。これを行うには、invoke()コマンドを使用してOracle Internet DirectoryサーバーからMBeanに構成をロードする必要があります。変更後、invoke()コマンドを使用してOracle Internet DirectoryサーバーにMBean構成を保存する必要があります。このようにinvoke()を使用するには、ツリーのルート・プロキシMBeanに移動する必要があります。ルート・プロキシMBeanの名前の形式は次のとおりです。

oracle.as.management.mbeans.register:type=component,name=COMPONENT_NAME,instance=INSTANCE

次に例を示します。

oracle.as.management.mbeans.register:type=component,name=oid1,instance=instance1

次に、setAuditPolicy()およびinvoke()を使用したwlstセッションの例を示します。

ORACLE_COMMON_HOME/common/bin/wlst.sh
connect('username', 'password', 'protocol://localhost:7001', 'localhost:7001')
custom()
cd('oracle.as.management.mbeans.register')
cd('oracle.as.management.mbeans.register:type=component,name=oid1,instance=instance1')
invoke('load',jarray.array([],java.lang.Object),jarray.array([],java.lang.String))
setAuditPolicy(filterPreset='None',
on='oracle.as.management.mbeans.register:type=component.auditconfig,
name=auditconfig1,instance=instance1,component=oid1')
invoke('save',jarray.array([],java.lang.Object),jarray.array([],java.lang.String))

23.4 コマンド行からの監査の管理

LDAPツールを使用して監査を管理できます。

23.4.1 コマンド行からの監査構成の表示

ldapsearchを使用して監査構成を表示できます。次に例を示します。

ldapsearch -p 3060 -h myhost.example.com -D cn=orcladmin -q \
-b "cn=oid1,cn=osdldapd,cn=subconfigsubentry" \
-s base "objectclass=*" > /tmp/oid1-config.txt
grep orclaud oid1-config.txt
orclaudsplusers=cn=orcladmin
orclaudcustevents=UserLogin.FAILURESONLY, UserLogout, CheckAuthorization,
ModifyDataItemAttributes, CompareDataItemAttributes, ChangePassword.FAILURESONLY
orclaudfilterpreset=custom

23.4.2 コマンド行からのOracle Internet Directory監査の構成

ldapmodifyコマンドを使用して監査を管理できます。LDIFファイルを作成して、属性orclAudFilterPreset、orclAudCustEventsおよびorclAudSplUsersに対して必要な変更を加える必要があります。

コマンドは次のとおりです。

ldapmodify -D cn=orcladmin -q -p portNum -h hostname -f ldifFile

たとえば、ユーザー・ログイン・イベントについてのみ監査を有効にするには、前述のldapmodifyコマンドに次のLDIFファイルを使用します。

dn: cn=componentname,cn=osdldapd,cn=subconfigsubentry
changetype: modify
replace: orclaudFilterPreset
orclaudFilterPreset: Custom
-
replace: orclaudcustevents
orclaudcustevents: UserLogin

詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。

23.4.3 レプリケーションおよびOracle Directory Integration Platformの監査の有効化

次のLDIFファイルでは、レプリケーションとOracle Directory Integration Platform監査の両方が有効になります。

dn: cn=oid1,cn=osdldapd,cn=subconfigsubentry
changetype: modify
replace: orclextconfflag
orclextconfflag: 7

次のLDIFファイルでは両方が無効になります。

dn: cn=oid1,cn=osdldapd,cn=subconfigsubentry
changetype: modify
replace: orclextconfflag
orclextconfflag: 3

次のようなコマンド行を使用します。

ldapmodify -h host -p port -D "cn=orcladmin" -q -f ldiffile

24 ロギングの管理

この章では、Oracle Enterprise Manager Fusion Middleware ControlおよびLDAPコマンド行ユーティリティを使用してログ・ファイルを表示する方法やデバッグ・ロギングを構成する方法など、Oracle Internet Directoryによるロギングについて説明します。

Oracle Fusion Middlewareでのロギングに関する一般情報は、『Oracle Fusion Middleware管理者ガイド』の「ログ・ファイルと診断データの管理」の章を参照してください。

この章の内容は次のとおりです。

- 第24.1項「ロギングの概要」

- 第24.2項「Fusion Middleware Controlを使用したロギングの管理」

- 第24.3項「コマンド行からのロギングの管理」

24.1 ロギングの概要

他のOracle Fusion Middlewareコンポーネントと同様に、Oracle Internet Directoryは診断ログ・ファイルをOracle Diagnostic Logging形式(ODL)で書き込みます。

関連項目:
ODLの詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

Oracle Internet Directoryツールとサーバーは、ログとトレースの情報をORACLE_INSTANCEのログ・ファイルに出力します。表24-1では、各コンポーネントおよび対応するログ・ファイルの位置を示します。

表24-1 Oracle Internet Directoryログ・ファイルの位置

ツールまたはサーバー名

ログ・ファイル名

バルク・ローダー(bulkload)

ORACLE_INSTANCE/diagnostics/logs/OID/tools/bulkload.log

バルク・モディファイア(bulkmodify)

ORACLE_INSTANCE/diagnostics/logs/OID/tools/bulkmodify.log

バルク削除ツール(bulkdelete)

ORACLE_INSTANCE/diagnostics/logs/OID/tools/bulkdelete.log

カタログ管理ツール(catalog)

ORACLE_INSTANCE/diagnostics/logs/OID/tools/catalog.log

データ・エクスポート・ツール(ldifwrite)

ORACLE_INSTANCE/diagnostics/logs/OID/tools/ldifwrite.log

ディレクトリ・レプリケーション・サーバー(oidrepld)

ORACLE_INSTANCE/diagnostics/logs/OID/ componentName/oidrepld-XXXX.log。XXXXは0000からorclmaxlogfilesの範囲の数値です。

ディレクトリ・サーバー(oidldapd)

ORACLE_INSTANCE/diagnostics/logs/OID/componentName/oidldapd01sPID-XXXX.log

- 01はインスタンス番号です(デフォルトは01)。

- sはサーバーを表します。

- PIDはサーバー・プロセスの識別子です。

- XXXXは0000からorclmaxlogfilesの範囲の数値です

ORACLE_INSTANCE/diagnostics/logs/OID/componentName/oidstackInstNumberPID.log

注意: oidstackInstNumberログ・ファイルは、SIGSEGV/SIGBUS追跡に関係します。また、ディレクトリ・インスタンスの起動時に空ファイルがこの名前で作成されますが、無視できます。

LDAPディスパッチャ(oidldapd)

ORACLE_INSTANCE/diagnostics/logs/OID/componentName/oidldapd01-XXXX.log。01はインスタンス番号(デフォルトは01)、XXXXは0000からorclmaxlogfilesの範囲の数値です。

OIDモニター(OIDMON)

ORACLE_INSTANCE/diagnostics/logs/OID/componentName/oidmon-XXXX.log。XXXXは0000からorclmaxlogfilesの範囲の数値です。

注意:orclmaxlogfilesizeで指定された設定に関係なくログ・ファイルのサイズが1MBを超えて増加した場合、Oracle Internet Directoryインスタンスの再起動後に、OIDモニター(OIDMON)およびOIDDISPD (ディスパッチャ)ログ・ファイルがローテーションされます。

24.1.1 Oracle Internet Directoryデバッグ・ロギングの機能

Oracle Internet Directoryによって、次のことが可能になります。

- ディレクトリ・サーバー、ディレクトリ・レプリケーション・サーバー、Directory Integration Serverに関するロギング情報の表示

- ロギング・レベルの設定

- ロギングする操作の指定

- 致命的エラーおよび重大エラーに対する対処方法を判断するための標準形式のメッセージの検索

- 重大度と重要性の度合いによるトレース・メッセージの表示

- エントリの識別名、ACP評価、操作のコンテキストなどに関する関連情報の入ったトレース・メッセージを調べることによるOracle Internet Directoryコンポーネントの診断

24.1.2 ログ・メッセージの解釈

この項では、特定のLDAP操作に関連付けられたログ・メッセージおよび関連付けられていないログ・メッセージについて説明します。トレース・ログの例およびその解釈方法を示します。

他のOracle Fusion Middlewareコンポーネントと同様に、Oracle Internet Directoryは診断ログ・ファイルをOracle Diagnostic Logging形式(ODL)で書き込みます。ODL形式の詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

24.1.2.1 特定のLDAP操作に関するログ・メッセージ

特定の操作に対するログ・メッセージは、トレース・オブジェクトとして格納されます。このオブジェクトにより、各種のOracle Internet Directoryモジュールにわたって、操作の開始から終了までが追跡されます。これは、次のいずれかの状態が発生した場合に、ログ・ファイルに記録されます。

- LDAP操作が完了したとき

- 優先度の高いメッセージが記録されたとき

- トレース・メッセージ・バッファが一杯になったとき

各スレッドは、操作ごとに連続的な情報ブロックを1つ持ち、そのブロックは明確に区切られます。したがって、共有サーバー環境でも、異なるスレッド、操作、接続に関するメッセージの追跡が容易です。

内部メッセージのバッファ・オーバーフローのため、単一のトレース・オブジェクトに1つの操作に関するすべての情報を格納できない場合、この情報は複数のトレース・オブジェクトに分散されます。分散された情報の各部分は明確に区切られており、共通のヘッダーが付けられています。操作の進行を追跡するには、トレース・オブジェクトおよびその共通ヘッダーを最後までたどります(「操作が完了しました」というトレース・メッセージで示されます)。

24.1.2.2 特定のLDAP操作と関連付けられていないログ・メッセージ

どのLDAP操作とも関連付けられていないメッセージは、オブジェクトベースではない単純な形式で表示されます。これは、操作が完了するか、または優先度の高いメッセージが発生したときにログ・ファイルに記録されます。

操作を実行しないスレッドでは、トレース・メッセージのみが記録されます。そのヘッダーには、日付、時間およびスレッド識別子が含まれます。ここには、実行コンテキストID(ECID)または接続および操作関連情報は含まれません。

トレース・オブジェクトは、キーワードBEGINで始まり、キーワードENDで終わります。

24.1.2.3 例: Oracle Internet Directoryサーバー・ログ・ファイル内のトレース・メッセージ

[2008-11-14T15:28:01-08:00] [OID] [NOTIFICATION:16] [] [OIDLDAPD] [host: srvhst.us.abccorp.com] [pid: 7043] [tid: 0] Main:: Starting up the OiD Server, on node srvhst.us.abccorp.com.

[2008-11-14T15:28:01-08:00] [OID] [NOTIFICATION:16] [] [OIDLDAPD] [host: srvhst.us.abccorp.com] [pid: 7043] [tid: 0] Main:: Oid Server Connected to DB store via inst1 connect string.

[2008-11-14T15:28:01-08:00] [OID] [NOTIFICATION:16] [] [OIDLDAPD] [host: srvhst.us.abccorp.com] [pid: 7043] [tid: 0] Main:: Loading Root DSE ...

[2008-11-14T15:28:01-08:00] [OID] [NOTIFICATION:16] [] [OIDLDAPD] [host: srvhst.us.abccorp.com] [pid: 7043] [tid: 0] Main:: Loading subschema subentry ...

[2008-11-14T15:28:01-08:00] [OID] [NOTIFICATION:16] [] [OIDLDAPD] [host: srvhst.us.abccorp.com] [pid: 7043] [tid: 0] Main:: Loading catalog entry ...

[2008-11-14T15:28:01-08:00] [OID] [NOTIFICATION:16] [] [OIDLDAPD] [host: srvhst.us.abccorp.com] [pid: 7043] [tid: 0] Main:: OiD LDAP server started.

[2008-11-14T15:28:02-08:00] [OID] [NOTIFICATION:16] [] [OIDLDAPD] [host: srvhst.us.abccorp.com] [pid: 7043] [tid: 2] ServerDispatcher : Thread Started

[2008-11-14T15:28:02-08:00] [OID] [NOTIFICATION:16] [] [OIDLDAPD] [host: srvhst.us.abccorp.com] [pid: 7043] [tid: 1] ServerDispatcher : Thread Started

[2008-11-14T15:28:02-08:00] [OID] [NOTIFICATION:16] [] [OIDLDAPD] [host: srvhst.us.abccorp.com] [pid: 7043] [tid: 3] ServerWorker (REG): Thread Started

[2008-11-14T15:28:02-08:00] [OID] [NOTIFICATION:16] [] [OIDLDAPD] [host: srvhst.us.abccorp.com] [pid: 7043] [tid: 4] ServerWorker (REG): Thread Started

[2008-11-14T15:28:02-08:00] [OID] [NOTIFICATION:16] [] [OIDLDAPD] [host: srvhst.us.abccorp.com] [pid: 7043] [tid: 5] ServerWorker (SPW): Thread Started

[2008-11-14T15:28:47-08:00] [OID] [TRACE:16] [] [OIDLDAPD] [host: srvhst.us.abccorp.com] [pid: 7043] [tid: 3] [ecid: 004MuuNFY7UCknT6uBU4UH0001i30000Ee,0] ServerWorker (REG):[[
BEGIN
ConnID:87 mesgID:2 OpID:1  OpName:bind ConnIP:170.90.11.210 ConnDN:cn=orcladmin
15:28:47-08:00 * gslfbiADoBind * Entry
15:28:47-08:00 * gslfbiGetControlInfo * Entry
15:28:47-08:00 * gslfbiGetControlInfo * Exit
15:28:47-08:00 * gslfbidbDoBind *  Version=3 BIND dn="cn=orcladmin" method=128
15:28:47-08:00 * gslsbnrNormalizeString * String to Normalize: "orcladmin"
15:28:47-08:01 * gslsbnrNormalizeString * Normalized value: "orcladmin"
15:28:47-08:01 * gslfrsBSendLdapResult * Entry
15:28:47-08:01 * gslfrsASendLdapResult2 * Entry
15:28:47-08:01 * sgslunwWrite * Entry
15:28:47-08:01 * sgslunwWrite * Exit
15:28:47-08:01 * gslfrsASendLdapResult2 * Exit
15:28:47-08:01 * gslfrsBSendLdapResult * Exit
15:28:47-08:01 * gslfbiADoBind * Exit
TOTAL Worker time :  4402  micro sec
END
]]

[2008-11-14T15:28:56-08:01] [OID] [TRACE:16] [] [OIDLDAPD] [host: srvhst.us.abccorp.com] [pid: 7043] [tid: 4] [ecid: 004MuuNqbefCknT6uBU4UH0001i30000Lf,0] ServerWorker (REG):[[
BEGIN
ConnID:126 mesgID:1 OpID:0  OpName:bind ConnIP:170.90.11.210 ConnDN:Anonymous
15:28:56-08:01 * gslfbiADoBind * Entry
15:28:56-08:01 * gslfbiGetControlInfo * Entry
15:28:56-08:01 * gslfbiGetControlInfo * Exit
15:28:56-08:01 * gslfbidbDoBind *  Version=3 BIND dn="" method=128
15:28:56-08:01 * gslfrsBSendLdapResult * Entry
15:28:56-08:01 * gslfrsASendLdapResult2 * Entry
15:28:56-08:01 * sgslunwWrite * Entry
15:28:56-08:02 * sgslunwWrite * Exit
15:28:56-08:02 * gslfrsASendLdapResult2 * Exit
15:28:56-08:02 * gslfrsBSendLdapResult * Exit
15:28:56-08:02 * gslfbiADoBind * Exit
TOTAL Worker time :  2591  micro sec
END
]]

24.2 Fusion Middleware Controlを使用したロギングの管理

Oracle Enterprise Manager Fusion Middleware Controlを使用すると、ログ・ファイルの表示やデバッグ・ロギングの構成が可能です。

24.2.1 Fusion Middleware Controlを使用したログ・ファイルの表示

表示するログ・メッセージを選択するには、次の手順を実行します。

1. 「Oracle Internet Directory」メニューから、「ログ」を選択し、「ログ・メッセージの表示」を選択します。「ログ・メッセージ」ページが表示されます。

2. 表示するログの日付範囲を選択します。「最新」、分単位、時間単位または日単位を選択できます。また、「時間間隔」を選択し、開始日時と終了日時を指定することもできます。

3. 表示する「メッセージ・タイプ」を選択します。

4. 「最大表示行数」を指定します。

5. 「表示」リストから、「列」を選択して表示列を変更します。「列の並替え」を選択して列の順序を変更します。

6. 各列内では、列ヘッダーの上矢印または下矢印を選択することで、昇順と降順を切り替えることができます。

7. 「表示」リストから、表示対象として、全メッセージ、メッセージ・タイプ別サマリーまたはメッセージID別サマリーを選択します。

8. 特定の検索を実行するには、「フィールドの追加」を選択し、検索するフィールドを追加します。各フィールドに対し、基準をリストから選択した後、テキストをボックスに入力します。フィールドを削除するには、赤いXを選択します。フィールドを追加するには、「フィールドの追加」を選択します。基準の追加が終了した後、「検索」を選択します。

9. ドメインに関するメッセージを表示するには、「広範囲のターゲット・スコープ」リストを使用します。

10. ログ・メッセージをXML、テキストまたはカンマ区切りのリストとしてファイルにエクスポートするには、「メッセージをファイルにエクスポート」を選択します。

11. 個々のログ・ファイルに関する情報を表示するには、「ターゲット・ログ・ファイル」をクリックします。

12. 表示をリフレッシュするタイミングを指定できます。右上のリストから「手動リフレッシュ」、「30秒リフレッシュ」または「1分間リフレッシュ」を選択します。

13. リストされている列の変更や列の並替えには、「表示」リストを使用します。

14. メッセージのグループ分けの変更には、「表示」リストを使用します。

15. ログ・メッセージのリストのみを表示するには、「検索」ラベルを閉じます。

16. ログ・ファイルの内容を表示するには、「ログ・ファイル」列でファイル名をダブルクリックします。「ログ・ファイルの表示: filename」ページが表示されます。「時間」、「メッセージ・タイプ」および「メッセージID」で上向きまたは下向きの矢印を使用してファイル内のレコードを並べ替えることができます。

24.2.2 Fusion Middleware Controlを使用したロギングの構成

表24-2 「サーバー・プロパティ」ページ、「ロギング」タブの構成属性

フィールドまたはヘッダー

構成属性

デバッグ・レベル

orcldebugflag

デバッグ操作の有効化

orcldebugop

最大ログ・ファイル・サイズ(MB)

orclmaxlogfilesize

ローテーション状態を保つログ・ファイルの最大数

orclmaxlogfiles

ロギングを構成するには、次の手順を実行します。

1. Oracle Internet Directoryのメニューから、「管理」→「サーバー・プロパティ」→「ロギング」を選択します。

2. 「デバッグ・レベル」の下で、記録するアクティビティのタイプを選択します。

3. 「デバッグ操作の有効化」の下で、記録するLDAP操作を有効にします。

4. 「ロギング」の下で、「最大ログ・ファイル・サイズ(MB)」と「ローテーション状態を保つログ・ファイルの最大数」の値を指定します。デフォルトは、それぞれ1MBと100ログ・ファイルです。

注意:
「サーバー・プロパティ」ページの「ロギング」タブで設定する値によって、LDAPサーバー・デバッグが制御されます。レプリケーション・サーバー・デバッグの値を設定するには、第43.2.8項「Fusion Middleware Controlを使用したレプリケーションのデバッグ・レベルの構成」で説明しているように、「共有プロパティ」ページの「レプリケーション」タブを使用します。

24.3 コマンド行からのロギングの管理

この項の内容は次のとおりです。

- 第24.3.1項「コマンド行からのログ・ファイルの表示」

- 第24.3.2項「コマンド行を使用したデバッグ・ロギング・レベルの設定」

- 第24.3.3項「コマンド行を使用したデバッグ操作の設定」

- 第24.3.4項「ログ・ファイルへのトレース情報のフラッシュの強制」

24.3.1 コマンド行からのログ・ファイルの表示

Oracle Internet Directoryログ・ファイルはテキスト・エディタで表示できます。第24.1項「Oracle Internet Directoryログ・ファイルの位置」を参照してください。

24.3.2 コマンド行を使用したデバッグ・ロギング・レベルの設定

デバッグ・ロギング・レベルを設定するには、ldapmodifyコマンドを使用します。

デバッグ・レベルは加算方式であるため、アクティブ化する機能を表す数値を加算し、その合計値をコマンド行オプションに使用する必要があります。

デフォルトでは、デバッグ・ログは記録されません。有効にするには、インスタンス固有の構成エントリで属性orcldebugflagを必要なレベルに変更します。

注意:
インスタンス固有の構成エントリの識別名の形式は次のとおりです。

cn=componentname,cn=osdldapd, cn=subconfigsubentry

デバッグ・レベルは、次のレベルのいずれかに構成できます。

表24-3に、OrclDebugFlagの値を示します。

表24-3 OrclDebugFlagの値

値

操作

1

大容量トレースのデバッグ

128

パケット・ハンドリングのデバッグ

256

接続管理

512

検索フィルタの処理

1024

エントリの解析

2048

構成ファイルの処理

8192

アクセス制御リストの処理

491520

DBとの通信のログ

524288

スキーマ関連の操作

4194304

レプリケーション固有の操作

8388608

各接続のエントリ、操作および結果のログ

16777216

ファンクション・コール引数のトレース

67108864

このサーバーに接続されているクライアントの数とアイデンティティ

117440511

すべての可能な操作とデータ

134217728

Javaプラグイン・フレームワーク関連のすべてのJavaプラグイン・デバッグ・メッセージと内部サーバー・メッセージ

268435456

ServerLogオブジェクトを使用してJavaプラグインによって渡されるすべてのメッセージ

402653184

上の両方

たとえば、検索フィルタの処理(512)と接続管理(256)をトレースするには、デバッグ・レベルとして768 (512 + 256 = 768)と入力します。

orcldebugflagを使用して、ロギングを有効または無効にできます。たとえば、インスタンスoid1についてorcldebugflagの値を1に設定することによりロギングをオンにするには、次のコマンドを使用します。

ldapmodify -p oidPort -D cn=orcladmin -w adminPasswd -f debugOn.ldif

debugOn.ldifには、次の内容が含まれています。

dn: cn=oid1,cn=osdldapd,cn=subconfigsubentry
changetype: modify
replace: orcldebugflag
orcldebugflag: 1

ロギングを無効にするには、インスタンスのorcldebugflagの値を0に設定します。たとえば、インスタンスoid1のデバッグを無効にするには、次のコマンドを使用します。

ldapmodify -p oidPort -D cn=orcladmin -w adminPasswd -f debugOff.ldif

この場合、debugOff.ldifには次が含まれます。

dn: cn=oid1,cn=osdldapd,cn=subconfigsubentry
changetype: modify
replace: orcldebugflag
orcldebugflag: 0

注意:
orcldebugflagの値は、LDAPサーバー・デバッグを制御します。レプリケーション・サーバー・デバッグを制御するには、第43.3.7項「ldapmodifyを使用したレプリケーション構成セットの属性の構成」で説明しているように、orcldebuglevelの値を設定します。

24.3.3 コマンド行を使用したデバッグ操作の設定

特定のディレクトリ・サーバー操作にロギングを制限してロギングをより絞り込むには、orcldebugop属性を使用して、記録するデバッグ操作を指定します。

表24-4の値のサブセットを構成するには、各コードを加算します。たとえば、ldapbind操作とldapadd操作のデバッグを設定するには、orcldebugopを5 (1 + 4 = 5)に設定します。

表24-4 orcldebugop属性を設定するためのデバッグ操作

デバッグ操作

提供される情報

1

ldapbind

2

ldapunbind

4

ldapadd

8

ldapdelete

16

ldapmodify

32

ldapmodrdn

64

ldapcompare

128

ldapsearch

256

ldapabandon

511

すべてのLDAP操作

複数の操作を記録するには、そのディメンションの値を加算します。たとえば、ldapbind(1)、ldapadd(4)およびldapmodify(16)の操作をトレースする場合、orcldebugop属性を21(1 + 4 + 16 = 21)に設定したLDIFファイルを作成します。このLDIFファイルは、次のようになります。

dn: cn=componentname,cn=osdldapd,cn=subconfigsubentry
changetype:modify
replace:orcldebugop
orcldebugop:21

このファイルをロードするには、次のように入力します。

ldapmodify -D "cn=orcladmin" -q -h host_name -p port_number -f file_name

24.3.4 ログ・ファイルへのトレース情報のフラッシュの強制

I/O操作のパフォーマンス・オーバーヘッドを最小限にするため、デバッグ・メッセージは、メッセージがディレクトリ・サーバーに記録されるたびにではなく、定期的にログ・ファイルにフラッシュされます。ログ・ファイルへの書込みは、次のいずれかの状態が発生した場合に実行されます。

- LDAP操作が完了したとき

- 優先度の高いメッセージが記録されたとき

- トレース・メッセージ・バッファが一杯になったとき

ただし、定期的なフラッシュを待たずに、トレース・メッセージが記録されたときにログ・ファイルでそれを検証することもできます。これを行うには、インスタンス固有の構成エントリ属性orcldebugforceflushを1に設定します。次の例に示すとおり、ldapmodifyを使用して、これを行います。

例24-1 強制フラッシュの有効化

ldapmodifyを使用して強制フラッシュを使用可能にする手順は、次のとおりです。

1. 次のようなLDIFファイルを作成します。

dn: cn=componentname,cn=osdldapd,cn=subconfigsubentry
changetype: modify
replace: orcldebugforceflush
orcldebugforceflush: 1

2. 次のように入力して、このファイルをロードします。

ldapmodify -D "cn=orcladmin" -q -h host_name -p port_number -f file_name

注意:

- 強制フラッシュが使用可能な場合、各操作のトレース・メッセージ・オブジェクトの形式は断片化されたものになります。

- デフォルトでは、強制フラッシュは無効です。必要な情報をログ・ファイルにフラッシュした後は、強制フラッシュを無効にしてください。

関連項目:
orcldebugforceflush属性の詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のOracle Identity ManagementのLDAP属性参照に関する説明を参照してください。

25 Oracle Internet Directoryのモニタリング

この章では、Oracle Internet Directoryの統計をモニターできるOracle Internet Directory管理機能フレームワークについて説明します。また、Oracle Enterprise Manager Fusion Middleware Controlを使用して統計収集を構成および表示する方法、LDAPコマンド行ユーティリティを使用して統計を構成する方法、Oracle Directory Services Manager (ODSM)およびoiddiagツールを使用して統計を表示する方法について説明します。

この章の内容は次のとおりです。

- 第25.1項「Oracle Internet Directoryサーバーのモニタリングの概要」

- 第25.2項「Fusion Middleware Controlを使用した統計収集の設定」

- 第25.3項「Fusion Middleware Controlを使用した統計情報の表示」

- 第25.4項「Oracle Directory Services Managerホームページでの統計情報の表示」

- 第25.5項「コマンド行を使用した統計収集の設定」

- 第25.6項「OIDDIAGツールによる情報の表示」

他のOracle Fusion Middlewareコンポーネントのモニタリングの詳細は、『Oracle Fusion Middleware管理者ガイド』の「Oracle Fusion Middlewareのモニタリング」の章を参照してください。

25.1 Oracle Internet Directoryサーバーのモニタリングの概要

この概要の項目は次のとおりです。

- 第25.1.1項「Oracle Internet Directoryサーバー管理機能」

- 第25.1.2項「Oracle Internet Directoryサーバー管理機能のアーキテクチャとコンポーネント」

- 第25.1.3項「セキュリティ・イベントおよび統計エントリのパージ」

- 第25.1.4項「サーバー管理機能情報にアクセスするために使用されるアカウント」

25.1.1 Oracle Internet Directoryサーバー管理機能

Oracle Internet Directoryサーバー管理機能フレームワークにより、次のディレクトリ・サーバー統計を監視できます。

- LDAPリクエスト・キュー、CPU使用率、メモリー、LDAPセッションおよびデータベース・セッションに関するサーバー状況統計。たとえば、ある期間のアクティブなデータベース・セッションの数を表示できます。ある期間にOracle Internet Directoryサーバー・インスタンスに対してオープンされた接続の合計数も表示できます。

- パフォーマンス統計。ある期間にわたり、バインド、比較、メッセージング検索およびすべての検索の操作に平均待機時間(ミリ秒)が指定されます。

- 特定のサーバー操作(追加、変更、削除などの操作)に関する一般統計。たとえば、ある期間のディレクトリ・サーバー操作の数を表示できます。失敗したバインド操作件数も表示できます。

- ディレクトリおよび各操作を実行するユーザーに対する、成功および失敗した操作を含むユーザー統計。すべてのLDAP操作は、構成されたユーザーについて追跡されます。また、統計収集期間の最後の時点でユーザーが保持している接続が追跡されます。

- システム・リソースとセキュリティに関するクリティカル・イベント(ユーザーがパスワードを間違えた場合や、操作の実行に十分なアクセス権限を持っていない場合など)。その他のクリティカル・イベントには、予想されるエラー(1、100または1403など)以外のORAエラーとLDAPサーバーの異常終了が含まれます。

- ユーザーの成功および失敗したバインド操作およびユーザーパスワード比較操作を追跡するセキュリティ・イベント。
バインドおよびユーザーのパスワード比較は、最もセキュリティを意識する必要がある操作であるため、これら2つの操作の追跡には排他的カテゴリ・セキュリティ・イベントが使用されます。このイベントは、LDAPユーザーおよびアプリケーションが実行したこれらの操作の数を追跡します。記録される基本情報は、ユーザーの識別名とソースのIPアドレスです。失敗したパスワードの比較の場合、追加の情報、特に所定のIPアドレスでの特定のユーザーと別のユーザーを比較したパスワード失敗数が追跡されます。

- ディレクトリ・サーバーとディレクトリ・レプリケーション・サーバーのステータス情報(ディレクトリ・レプリケーション・サーバーが呼び出された日時など)

25.1.2 Oracle Internet Directoryサーバー管理機能のアーキテクチャとコンポーネント

ディレクトリ・サーバー管理機能の各種コンポーネント間の関係については、図25-1とその後の表25-1で説明します。

図25-1 Oracle Internet Directoryサーバー管理機能のアーキテクチャ

表25-1 Oracle Internet Directoryサーバー管理機能のコンポーネント

コンポーネント

説明

Oracle Internet Directory

クライアントからのディレクトリ・リクエストに応答します。これには、コントローラ、ワーカー、ディスパッチャおよびリスナーの4種類の機能スレッドがあります。クライアントからのLDAPリクエストを受信して処理し、クライアントにLDAPレスポンスを返信します。

Oracle Internet Directoryサーバー管理機能フレームワークを使用して実行時モニタリング機能を設定すると、サーバーの4種類の機能スレッドが、指定された情報を記録し、それをローカル・メモリーに格納します。

関連項目: ディレクトリ・サーバーの詳細は、第3.1.2項「Oracleディレクトリ・サーバー・インスタンス」を参照してください。

メモリー常駐ストレージ

これは、ローカル・プロセス・メモリーです。Oracle Internet Directoryサーバー管理機能フレームワークは、統計、トレースおよびセキュリティ・イベントにそれぞれ1つを割り当てます。それぞれのストレージは、ローカル・メモリー・ストレージで管理される独自のデータ構造を持ちます。

優先度の低い書込みスレッド

これらの書込み専用スレッドは、サーバー統計、セキュリティ・イベント・ロギングおよびトレース情報をリポジトリに書き込むサーバー機能スレッドとは異なります。システム・オーバーヘッドを少なくするため、その優先度は低く保たれます。

外部モニタリング・アプリケーション

このモジュールは独自のもので、サーバー管理機能フレームワークの外部にあります。これは、集められた統計をディレクトリ・サーバーの標準LDAPインタフェースを通じて収集し、それを専用のリポジトリに格納します。

サーバー管理情報のための外部リポジトリ

これは、収集されたディレクトリ・サーバー統計を格納するためにモニタリング・エージェントが使用するリポジトリです。モニタリング・エージェントがこのリポジトリの実装方法を決定します。

Fusion Middleware Control

統計とイベントのリポジトリから、モニターされたデータを抽出し、それをWebベースのグラフィカル・ユーザー・インタフェースで表示します。ユーザーは通常のブラウザでデータを表示できます。リポジトリは、収集されたデータを一般問合せとカスタム問合せのために格納できます。

ロギング・リポジトリ(ファイル・システム)

このリポジトリは、ファイル・システムを使用して、ディレクトリ・サーバーの各種モジュールでトレースされた情報を格納します。この目的のためにファイル・システムを使用することにより、Oracle Internet Directoryサーバー管理機能フレームワークはオペレーティング・システムの機能とセキュリティを使用できます。

ディレクトリ・データ・リポジトリ

このリポジトリには、ユーザーが入力したすべてのデータ(ユーザー・エントリやグループ・エントリなど)が格納されます。

統計とイベントのリポジトリ

このリポジトリは、ファイル・システムにではなく、ディレクトリ・データ・リポジトリと同じデータベースに情報を格納する点を除き、トレース・リポジトリと同じです。この方法で、Oracle Internet Directoryサーバー管理機能フレームワークは次の機能を使用できます。

- 通常のLDAP操作による情報の格納と取得

- 既存のアクセス制御ポリシーによる収集済情報のセキュリティの管理

ディレクトリ管理機能フレームワークは、この2つを別々に格納することにより、収集された情報をディレクトリ・データから分離します。

25.1.3 セキュリティ・イベントおよび統計エントリのパージ

不要な統計エントリは、第36章「ガベージ・コレクションの管理」で説明されているOracle Internet Directoryパージ・ツールによりOracle Internet Directoryから削除されます。

25.1.4 サーバー管理機能情報にアクセスするために使用されるアカウント

Oracle Internet Directoryデータベース・アカウントODSSMが、データベースからサーバー管理機能情報にアクセスするために使用されます。インストール時、このアカウントのパスワードはユーザーがプロンプトで指定した値に設定されます。このアカウントのパスワードなどの資格証明は、Oracle Enterprise Manager Fusion Middleware Controlファイルtargets.xmlのOracle Internet Directoryスニペットに格納されます。

このアカウントのパスワードを変更する唯一の方法は、第12.11項「ODSSM管理者アカウントのパスワードの変更」で説明されている手順を使用する方法です。oidpasswdツールでは、このパスワードの変更はサポートされていません。

25.2 Fusion Middleware Controlを使用した統計収集の設定

この項の内容は次のとおりです。

- 第25.2.1項「Fusion Middleware Controlを使用したディレクトリ・サーバー統計収集の構成」

- 第25.2.2項「Fusion Middleware Controlを使用した統計収集のためのユーザーの構成」

25.2.1 Fusion Middleware Controlを使用したディレクトリ・サーバー統計収集の構成

Oracle Enterprise Manager Fusion Middleware Controlを使用して統計収集を構成する手順は、次のとおりです。

1. 「Oracle Internet Directory」メニューから「管理」を選択し、「サーバー・プロパティ」を選択してから、「統計」を選択します。

2. 統計収集を有効にするには、そのページの「一般」セクションで「統計フラグ」を選択します。

3. 「統計頻度」フィールドに分単位の時間を入力して、統計収集の頻度を指定します。

4. 「セキュリティ・イベント追跡のバインド」リストと「セキュリティ・イベント追跡の比較」リストから値を選択します。

5. ユーザーに関する統計を収集するには、そのページの「ユーザー統計」セクションで「ユーザー統計収集」を選択します。

6. そのページの「イベント・レベル」セクションで、追跡するイベントを選択します。

表25-2 「サーバー・プロパティ」ページ、「統計」タブの構成属性

フィールドまたはヘッダー

構成属性

統計フラグ

orclstatsflag

統計頻度(分)

orclstatsperiodicity

セキュリティ・イベント追跡のバインドおよびセキュリティ・イベント追跡の比較

orcloptracklevel

ユーザー統計

orclstatslevel

イベント・レベル

orcleventlevel

注意:

- 「ユーザー統計収集」を有効にした場合、統計収集のための個人ユーザーも指定する必要があります。第25.2.2項「Fusion Middleware Controlを使用した統計収集のためのユーザーの構成」を参照してください。

- イベント・レベルとして「スーパー・ユーザー・ログイン」を選択しない場合、Oracle Internet Directoryホームページでの対応するセキュリティ値は常に0です。

- 11g リリース1(11.1.1)では、orcldebugflagとorcloptracklevelの連続設定は加算方式です。

25.2.2 Fusion Middleware Controlを使用した統計収集のためのユーザーの構成

注意:
『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』の「Oracle Internet Directory」の章に記載のように、一定期間の経過後アイドルLDAP接続を閉じるようorclldapconntimeoutを構成した場合、統計収集用に構成されているユーザーに対する接続は、この設定どおりにタイムアウトしないことに注意してください。

サーバー管理機能で特定のユーザーの統計を収集するためにユーザーを構成する手順は、次のとおりです。

1. 「Oracle Internet Directory」メニューから「管理」を選択し、「共有プロパティ」を選択します。

2. 「一般」タブを選択します。

3. ユーザーの識別名を「ユーザーDN」に追加します(これにより、ユーザーの識別名が属性orclstatsdnに追加されます)。次に例を示します。

cn=Mary Lee, ou=Product Testing, c=uscn=Michael Smith, ou=Product Testing, c=uscn=Raj Sharma, ou=Human Resources, c=us

25.3 Fusion Middleware Controlを使用した統計情報の表示

この項で説明するように、Oracle Enterprise Manager Fusion Middleware Controlを使用して、多数のOracle Internet Directoryサーバー管理機能を表示できます。

関連項目:
レプリケーションのキュー統計の詳細は、第43.2.10項「Fusion Middleware Controlを使用したキュー統計の表示」を参照してください。

25.3.1 Oracle Internet Directoryホームページでの統計情報の表示

Oracle Internet Directoryホームページには、次の情報が表示されます。

- パフォーマンス

- 平均操作レスポンス時間(ミリ秒)

- メッセージング検索レスポンス時間(ミリ秒)

- バインド・レスポンス時間(ミリ秒)

- ロード

- LDAP接続の合計

- 操作完了

- 操作進行中

- セキュリティ

- 失敗したバインド操作

- スーパー・ユーザーの失敗したログイン数

- スーパーユーザーの正常なログイン数

- リソース使用率

- CPU使用率%

- メモリー使用率%

- 平均レスポンスおよび負荷

- LDAPserverResponse

- numCompletedOps

表形式で値を表示する場合は、「表ビュー」をクリックします。

ページの「セキュリティ」セクションにある「失敗したバインド操作」、「スーパー・ユーザーの失敗したログイン数」および「スーパー・ユーザーの正常なログイン」の値は、これらのメトリックの収集を有効にしていない場合は0です。詳細は、第25.2項「Fusion Middleware Controlを使用した統計収集の設定」を参照してください。

25.3.2 Oracle Internet Directory「パフォーマンス」ページでの情報の表示

「Oracle Internet Directory」メニューから「モニタリング中」→「パフォーマンス・サマリー」を選択します。デフォルトでは、次のメトリックが表示されます。

- サーバー・レスポンス

- 合計操作数

- メッセージング検索操作レスポンス時間

- バインド操作レスポンス時間

- 比較操作レスポンス時間

- パージ・キュー内のセキュリティ・イベント・オブジェクトの総数

- パージ・キュー内のセキュリティ・リフレッシュ・イベント・オブジェクトの総数

- パージ・キュー内のシステム・リソース・イベント・オブジェクトの総数

他のメトリックを表示するには、ウィンドウの右隅にある矢印をクリックして、メトリック・パレットを展開します。メトリック・パレットを閉じるには、ウィンドウの左隅にある矢印をクリックします。

デフォルトの時間間隔は15分です。時間間隔を変更するには、「スライダ」をクリックし、そのスライダを使用して時間間隔を設定します。または、「日付と時間」アイコンをクリックし、「日付と時間を入力」ダイアログで開始日時と終了日時を入力して、「OK」をクリックします。

ページをリフレッシュするには、「リフレッシュ」アイコンをクリックします。

「表示」リストを使用すると、チャートを表示したり、保存できます。

「オーバーレイ」リストを使用すると、異なるOracle Internet Directoryターゲットのメトリックをオーバーレイできます。

注意:

- クリティカルでないイベントの場合、対応するメトリックが更新されるまで数分からorclstatsperiodicityまでのタイム・ラグがあります。

- 更新されたメトリックを表示するには、「リフレッシュ」アイコンをクリックする必要があります。

25.4 Oracle Directory Services Managerホームページでの統計情報の表示

Oracle Internet DirectoryのOracle Directory Services Managerホームページには、次の情報が表示されます。

- 稼働時間

- LDAP接続

- OIDプロセス

- エントリ数

- LDAP変更ログ・エントリ

- レプリケーション承諾

- デバッグ有効

- 操作待ち時間

25.5 コマンド行を使用した統計収集の設定

この項の内容は次のとおりです。

- 第25.5.1項「健全性統計、一般統計およびパフォーマンス統計の属性の構成」

- 第25.5.2項「セキュリティ・イベント追跡の構成」

- 第25.5.3項「コマンド行からのユーザー統計収集の構成」

- 第25.5.4項「コマンド行からのイベント・レベルの構成」

- 第25.5.5項「コマンド行を使用した統計収集のためのユーザーの構成」

25.5.1 健全性統計、一般統計およびパフォーマンス統計の属性の構成

ldapmodifyおよびldapsearchを使用して、統計収集関連の構成属性を設定および表示できます。第9章「システム構成属性の管理」で説明されているように、これらの属性はインスタンス固有の構成エントリにあります。

健全性統計、一般統計およびパフォーマンス統計の収集を有効にするには、orclStatsFlag属性とorclStatsPeriodicity属性を設定します。

たとえば、コンポーネントoid1に対してOracle Internet Directoryサーバー管理機能フレームワークを使用可能にするには、次のようなLDIFファイルを作成します。

dn:cn=oid1,cn=osdldapd,cn=subconfigsubentry
changetype: modify
replace: orclstatsflag
orclstatsflag:1

このファイルをアップロードするには、次のコマンドを入力します。

ldapmodify -h host -p port_number -D bind_DN -q -f file_name

ここで、サーバー管理機能構成を実行する権限を持つバインド識別名は、cn=emd admin,cn=oracle internet directoryです。

25.5.2 セキュリティ・イベント追跡の構成

セキュリティ・イベント追跡を構成するには、属性orcloptracklevelを設定します。第9章「システム構成属性の管理」で説明されているように、この属性はインスタンス固有の構成エントリにあります。表25-3に、異なるレベルのバインドおよび比較情報収集を構成するためのorcloptracklevelの値を示します。

表25-3 orcloptracklevelの値

orcloptracklevelの値

構成

1

バインド識別名のみ

2

バインド識別名とIPアドレス

4

比較識別名のみ

8

比較識別名とIPアドレス

16

比較識別名、IPアドレスおよび失敗の詳細

各orcloptracklevel値により記録されるメトリックは、次の表に示すとおりです。

表25-4 各orcloptracklevel値により記録されるメトリック

構成

記録されるメトリック

識別名のみ

日時スタンプ

操作を実行する識別名のEID

成功回数

失敗回数

識別名とIPアドレス

識別名の下にのみ示されたすべてのメトリック

ソースIPアドレス

識別名、IPアドレスおよび失敗の詳細

識別名とIPアドレスの下に示されたすべてのメトリック

個別の成功回数

個別の失敗回数

IPアドレスからパスワードの比較を実行する各識別名の失敗の詳細

- 日時スタンプ

- ソースIPアドレス

- パスワードが比較される識別名のEID

- 失敗回数

属性orcloptrackmaxtotalsizeおよびorcloptracknumelemcontainersにより、統計とイベントの追跡に使用されるメモリーをチューニングできます。『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』の「Oracle Internet Directory」の章を参照してください。

25.5.3 コマンド行からのユーザー統計収集の構成

ユーザー統計を有効にするには、orclstatslevel属性を1に設定します。ユーザー統計収集を開始するには、orclStatsPeriodicity属性も設定する必要があります。

注意:
Oracle Enterprise Manager Fusion Middleware Controlの統計を収集している場合は、orclStatsPeriodicityをEnterprise Managerエージェントの収集周期と同じ値(デフォルトでは10分)に設定します。

統計収集のためのユーザーを構成する方法は、第25.5.5項「コマンド行を使用した統計収集のためのユーザーの構成」を参照してください。

25.5.4 コマンド行からのイベント・レベルの構成

イベント・レベルの追跡を実行するには、orclstatsflag属性を1に設定する必要があります。

イベント・レベルを構成するには、ldapmodifyを使用して、orcleventlevel属性を表25-5に示すイベント・レベルのいずれか1つ以上に設定します。第9章「システム構成属性の管理」で説明されているように、属性orcleventlevelはインスタンス固有の構成エントリにあります。

表25-5 イベント・レベル

レベル値

クリティカル・イベント

提供される情報

1

スーパーユーザー・ログイン

スーパーユーザーのバインド(成功または失敗)

2

プロキシ・ユーザー・ログイン

プロキシ・ユーザーのバインド(失敗)

4

レプリケーション・ログイン

レプリケーションのバインド(失敗)

8

追加アクセス

追加アクセス違反

16

削除アクセス

削除アクセス違反

32

書込みアクセス

書込みアクセス違反

64

ORA 3113エラー

データベースからの切断

128

ORA 3114エラー

データベースからの切断

256

ORA 28エラー

ORA-28エラー

512

ORAエラー

予想される1、100または1403以外のORAエラー

1024

Oracle Internet Directoryサーバーの終了回数

2047

すべてのクリティカル・イベント

25.5.5 コマンド行を使用した統計収集のためのユーザーの構成

注意:
『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』の「Oracle Internet Directory」の章に記載のように、一定期間の経過後アイドルLDAP接続を閉じるようorclldapconntimeoutを構成した場合、統計収集用に構成されているユーザーに対する接続は、この設定どおりにタイムアウトしないことに注意してください。

コマンド行を使用してユーザーを構成するには、ldapmodifyコマンド行ツールを使用して、ユーザーの識別名をDSA構成セット・エントリの複数値属性orclstatsdn (DN: cn=dsaconfig,cn=configsets,cn=oracle internet directory)に追加します。たとえば、このLDIFファイルではMary Leeがorclstatsdnに追加されます。

dn: cn=dsaconfig,cn=configsets,cn=oracle internet directory
changetype:modify
add: orclstatsdn
orclstatsdn: cn=Mary Lee, ou=Product Testing, c=us

次の形式のコマンド行を使用します。

ldapmodify -h host -p port -f ldifFile -D cn=orcladmin -q

25.6 OIDDIAGツールによる情報の表示

すべての統計のレポートは、oiddiagツールを次のように使用すれば表示できます。

セキュリティ・イベント

oiddiag audit_report=true [outfile=file_name]

すべての統計およびイベント

oiddiag collect_all=true, [outfile=file_name]

統計およびイベントのサブセット

oiddiag collect_sub=true [infile=input_file_name, outfile=file_name ]

input_file_nameは、次の出力を取得して作成します。

oiddiag listdiags=true

次に、不要な統計クラスを削除します。

注意:
Windowsでは、oiddiagコマンドのファイル名はoiddiag.bat.です。

関連項目:

- 『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のoiddiagコマンド・ツールのリファレンス

- 『Oracle Fusion Middleware管理者ガイド』の管理ツールに関する章

26 Oracle Internet Directoryのバックアップとリストア

バックアップおよびリストアが必要なすべてのOracle Internet Directoryデータは、基礎となるOracle Database内にあります。小さいディレクトリまたは特定のネーミング・コンテキストのバックアップには、ldifwriteユーティリティを使用できます。

Oracle Databaseのバックアップおよびリストアの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

OracleホームおよびOracleインスタンスをバックアップおよびリストアするには、『Oracle Fusion Middleware管理者ガイド』を参照してください。

注意:
Oracle Internet Directoryの旧リリース(10gリリース2 (10.1.2.0.2)など)のデータのバックアップを取り、それを10g (10.1.4.0.1)以降が稼働中のノードでリストアする場合、パスワード・ポリシー・エントリを、第40.5.3項「パスワード・ポリシーとファンアウト・レプリケーション」で説明しているように更新する必要があります。

第III部

拡張管理: セキュリティ

ここでは、次の内容について説明します。

- ディレクトリ内のデータの保護

- 企業およびホスティングされた環境内のアプリケーションを管理するアクセス制御の確立

- パスワードの管理ポリシーの設定および管理

- 他のOracleコンポーネントへのユーザーの認証に使用するパスワード・ベリファイアの管理

- ユーザー、グループおよびサービスに関するデータの1つのリポジトリへの格納、およびそのデータ管理の様々な管理者への委任

次の各章で構成されています。

- 第27章「Secure Sockets Layer(SSL)の構成」

- 第28章「データ・プライバシの構成」

- 第29章「パスワード・ポリシーの管理」

- 第30章「ディレクトリ・アクセス制御の管理」

- 第31章「パスワード・ベリファイアの管理」

- 第32章「Oracle Identity Managementの権限の委任」

- 第33章「認証の管理」

27 Secure Sockets Layer(SSL)の構成

この章では、Oracle Enterprise Manager Fusion Middleware Control、WebLogic Scripting Tool (wlst)およびLDAPコマンド行ユーティリティを使用して、Oracle Internet Directoryで使用するためにSecure Sockets Layer (SSL)を構成する方法について説明します。また、Oracle Directory Services Manager (ODSM)およびLDAPコマンド行ユーティリティを使用してSSL接続をテストする方法や、11gリリース1 (11.1.1)より前に開発されたOracleコンポーネントとの互換性を確保するためにSSL相互運用性モードを設定する方法についても説明します。

Oracle Internet DirectoryでSSLを使用する場合、厳密認証、データ整合性およびデータ・プライバシも構成できます。

この章には次の項が含まれます:

- 第27.1項「Secure Sockets Layer(SSL)の構成の概要」

- 第27.2項「Fusion Middleware Controlを使用したSSLの構成」

- 第27.3項「WLSTを使用したSSLの構成」

- 第27.4項「LDAPコマンドを使用したSSLの構成」

- 第27.5項「Oracle Directory Services Managerを使用したSSL接続のテスト」

- 第27.6項「コマンド行によるSSL接続のテスト」

- 第27.7項「SSL相互運用性モードの構成」

関連項目:

- Oracle Internet Directoryに関連するSSLの概念の概要は、第3.7項「セキュリティ」を参照してください。

- 第33章「認証の管理」

- 『Oracle Fusion Middleware管理者ガイド』の「SSL構成サービス」の章。

- 『Oracle Fusion Middleware管理者ガイド』の「SSL自動化ツール」の章。SSL自動化ツールを使用すると、ドメイン固有のCAを使用して複数のコンポーネントにSSLを構成できます。

27.1 Secure Sockets Layer(SSL)の構成の概要

Oracle Internet Directoryは、Secure Sockets Layer(SSL)を使用して、送信時にデータの変更、削除または再現が行われないことを保証します。SSLは、暗号方式のセキュアなメッセージ・ダイジェストを、MD5アルゴリズムまたはSecure Hash Algorithm(SHA)を使用する暗号チェックサムを使用して生成し、ネットワーク上で送信される各パケットに組み込みます。SSLでは、メッセージ・ダイジェストを使用して認証、暗号化、データ整合性を提供します。

この概要の項目は次のとおりです。

- 第27.1.1項「サポートされている暗号スイート」

- 第27.1.2項「サポートされているプロトコルのバージョン」

- 第27.1.3項「SSL認証モード」

- 第27.1.4項「11g リリース1(11.1.1)でのSSLの使用制限事項」

- 第27.1.6項「その他のコンポーネントとSSL」

- 第27.1.7項「SSL相互運用性モード」

- 第27.1.8項「StartTLS」

Oracle Internet Directoryは、SSLとともに使用可能な公開鍵暗号を使用して、送信時にデータが開示されないことを保証します。公開鍵暗号では、メッセージの送信側が受信側の公開鍵を使用してメッセージを暗号化します。メッセージが送達されると、受信側は、受信側の秘密鍵を使用して、メッセージを復号化します。

27.1.1 サポートされている暗号スイート

暗号スイートは、ネットワーク・ノード間のメッセージ交換に使用される認証、暗号化およびデータ整合性アルゴリズムのセットです。SSLハンドシェイク時に、2つのノード間で折衝し、メッセージを送受信するときに使用する暗号スイートを確認します。

表27-1に、Oracle Internet DirectoryでサポートされるSSL暗号スイートと、各暗号スイートに対応する認証、暗号化およびデータ整合性のメカニズムを示します。これらは、インスタンス固有の構成エントリの属性orclsslciphersuiteに格納されています。

注意:
JDK 7を使用している場合、Oracle Internet Directoryでは、楕円曲線暗号(ECC)やServer Name Indication (SNI)拡張は認識されません。そのため、SSLまたはTLSエラーを回避するには、次のJVMオプションを環境に追加します。

- -Dcom.sun.net.ssl.enableECC=false

- -Djsse.enableSNIExtension=false

表27-1 Oracle Internet DirectoryでサポートされるSSL暗号スイート

暗号スイート

認証

暗号化

データ整合性

SSL_RSA_WITH_AES_256_GCM_SHA384

RSA

AES

SHA

SSL_RSA_WITH_AES_128_GCM_SHA256

RSA

AES

SHA

SSL_RSA_WITH_AES_256_CBC_SHA256

RSA

AES

SHA

SSL_RSA_WITH_AES_128_CBC_SHA256

RSA

AES

SHA

SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

ECDHE_ECDSA

AES

SHA

SSL_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

ECDHE_ECDSA

AES

SHA

SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

ECDHE_ECDSA

AES

SHA

SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

ECDHE_ECDSA

AES

SHA

SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

ECDHE_ECDSA

AES

SHA

SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

ECDHE_ECDSA

AES

SHA

SSL_RSA_WITH_AES_256_CBC_SHA

RSA

AES

SHA

SSL_RSA_WITH_AES_128_CBC_SHA

RSA

AES

SHA

SSL_RSA_WITH_3DES_EDE_CBC_SHA

RSA

3DES

SHA

SSL_RSA_WITH_RC4_128_SHA

RSA

RC4

SHA

SSL_RSA_WITH_RC4_128_MD5

RSA

RC4

SHA

SSL_DH_anon_WITH_3DES_EDE_CBC_SHA

なし

3DES

SHA

SSL_DH_anon_WITH_RC4_128_MD5

なし

RC4

MD5

27.1.2 サポートされているプロトコルのバージョン

Oracle Internet Directoryでは、次のTLS/SSLプロトコルをサポートしています。

- SSLv3

- TLSv1

Oracle Internet Directoryでは、SSLv2をサポートしていません。

TLSv1では、表27-1にリストされているすべての暗号スイートを使用できます。SSLv3およびSSLv2 Helloを使用したSSLv3では、表27-1にリストされている暗号スイートの最初の10種類を使用できます。これらの場合、AES暗号(SSL_RSA_WITH_AES_128_CBC_SHAまたはSSL_RSA_WITH_AES_256_CBC_SHA)は使用できません。

11g (11.1.1.9)以降では、orclcryptoversion属性を使用してSSL/TLSバージョンを指定できます。

orclcryptoversion属性によって、対応する値を指定して属性に移入することで、複数のプロトコルを有効化できます。表27-2に、プロトコル・マッピングとその対応する値を示します。

orclcryptoversionの値を28に変更するには、次のようにldapmodifyを使用します。

ldapmodify -D cn=orcladmin -q -p portNum -h hostname -f ldifFile

ldifFileには、次のものが含まれます。

dn: cn=oid1,cn=osdldapd,cn=subconfigsubentry

changetype: modify

replace: orclcryptoversion

orclcryptoversion: 28

表27-2 プロトコル・マッピング

有効化されるプロトコル

Attribute Value

サポートされているすべてのプロトコル(デフォルト)

0

SSL v3

2

TLS 1.0

4

TLS 1.0またはSSL v3

6

TLS 1.1

8

TLS 1.1またはSSL v3

10

TLS 1.1またはTLS 1.0

12

TLS 1.1またはTLS 1.0またはSSL v3

14

TLS 1.2

16

TLS 1.2またはSSL v3

18

TLS 1.2またはTLS 1.0

20

TLS 1.2またはTLS 1.0またはSSL v3

22

TLS 1.1またはTLS 1.2

24

TLS 1.2またはTLS 1.1またはSSL v3

26

TLS 1.0またはTLS 1.1またはTLS 1.2

28

TLS 1.0またはTLS 1.1またはTLS 1.2またはSSL v3

30

27.1.3 SSL認証モード

SSLプロトコルでは、認証、整合性および機密保護を含むトランスポート層セキュリティがクライアントとサーバーとの間の接続に提供されます。表27-3に示す3つの認証モードがサポートされています。SSL認証モードは、インスタンス固有の構成エントリ内のorclsslauthentication属性によって制御されます。

表27-3 SSL認証モード

SSL認証方式

orclsslauthenticationの値

認証動作

SSL認証なしモード、機密保護モード

1

クライアントとサーバーのいずれも、相手に対して自己認証を行いません。証明書の送信または交換は行われません。SSL暗号化および復号化のみが使用されます。

SSLサーバー認証のみモード

32

ディレクトリ・サーバーが、クライアントに対して自己認証を行います。ディレクトリ・サーバーは、そのサーバーのアイデンティティを示す証明書をクライアントに送信します。

SSLクライアントとサーバーの認証モード

64

クライアントとサーバーは相互に自己認証を行い、それぞれ相手側に証明書を送信します。

デフォルトでは、Oracle Internet DirectoryはSSL認証なしモード(orclsslauthentication=1)を使用します。

クライアントとサーバーの双方が相互に自己認証を行うと、SSLはX.509 v3デジタル証明書から必要なアイデンティティ情報を取得します。

関連項目:
第33章「認証の管理」。

注意:

- デフォルトでは、SSL認証モードは1 (暗号化のみ、認証なし)に設定されます。
Oracle Delegated Administration Services 10g、または匿名SSL暗号用に構成された暗号化SSLポート上でOracle Internet Directoryと通信するOracle FormsおよびOracle Reportsのレガシー・バージョンなどその他のクライアント・アプリケーションを使用している場合、少なくとも1つのOracle Internet Directoryサーバー・インスタンスをこのデフォルト認証モード用に構成する必要があります。

そうしない場合は、認証モード1および匿名SSL暗号が要求されず、Oracle Internet Directoryが機能しません。使用可能にするSSLポートのタイプおよびSSLポートが受け入れる暗号は、固有のデプロイメント要件に依存します。

- レプリケーションは、SSLサーバー認証またはSSLクライアントとサーバー認証では機能しません。

ディレクトリ・サーバー・インスタンスの起動時に、SSLプロファイルのパラメータを含む一連の構成パラメータがディレクトリに読み込まれます。

サーバー・インスタンスをセキュア・モードで実行するには、LDAPSを使用して通信を行うための単一のリスニング・エンドポイントを構成します。同じインスタンスで非保護接続を同時に実行するには、LDAPを使用して通信を行うための2番目のリスニング・エンドポイントを構成します。

Oracle Internet Directoryのインストール時、Oracle Identity Management 11gインストーラは特定の手順に従ってSSLおよび非SSLポートを割り当てます。まず、非SSLポートとして3060の使用を試みます。そのポートが使用できない場合、3061から3070の範囲のポートを試し、次に13060から13070の範囲のポートを試します。同様に、SSLポートとして3131を試し、次に3132から3141のポート、その後13131から13141のポートを試します。

注意:
Oracle Internet Directoryの旧バージョンから11g リリース1(11.1.1)へアップグレードする場合、旧バージョンのポート番号が保持されます。

異なるSSLパラメータを使用して、異なる値で複数のOracle Internet Directoryインスタンスを作成および変更できます。これは、セキュリティ要件の異なるクライアントを制御する便利な方法です。

関連項目:
新規サーバー・インスタンスの作成の詳細は、第8章「Oracle Internet Directoryインスタンスの管理」を参照してください。

27.1.4 11g リリース1(11.1.1)でのSSLの使用制限事項

Oracleディレクトリ・レプリケーション・サーバーは、双方向(相互)認証をサポートするSSL対応のLDAPサーバーと直接通信できません。LDAPサーバーがSSL相互認証用に構成されていると、レプリケーション・サーバーの起動は失敗し、停止します。

27.1.5 Oracle Wallet

Oracle Walletは、X509証明書、秘密鍵および信頼できるCA証明書の格納に使用されるセキュアなソフトウェア・コンテナです。自己署名証明書は、企業内のOracle Walletに格納できます。

インスタンス固有の構成からウォレットへの参照を削除する前に、orclsslenableを0に設定してSSLを無効にする必要があります。

関連項目:
ミドルウェア・コンポーネントとともにOracle Walletを使用する方法は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

orclsslwalleturl属性に定義されている、現在使用中のウォレットはファイル・システムから削除しないでください。そうすると、サーバーが正常に起動できなくなります。このファイルを削除する前に、ウォレットに対する参照をインスタンス固有の構成エントリ属性orclsslwalleturlから削除してください。

11gでは、SSL構成サービスで抽出されるため、WLSTおよびOracle Enterprise Manager Fusion Middleware Controlでorclsslwalleturlを直接操作する必要はありません。SSL構成サービスを使用して行う場合、SSL構成サービスでウォレット削除の試行がトラップされます。

27.1.6 その他のコンポーネントとSSL

インストール時、Oracle Internet Directoryはデュアル・モードで起動します。つまり、非SSL接続を使用してOracle Internet Directoryにアクセス可能なコンポーネントもあれば、SSLを使用してディレクトリに接続するコンポーネントもあります。デフォルトでは、Oracle Application Serverコンポーネントは、Oracle Internet Directoryとの通信をこのデュアル・モード環境で実行するように構成されます。必要であれば、非SSLモードを取り除き、すべてのミドルウェア・インスタンスでSSLを使用するように変更できます。

エンタープライズ・ユーザー・セキュリティやカスタマ・アプリケーションでは、デフォルトでの構成とは異なるSSLチャネルが必要な場合があります。たとえば、SSLサーバー認証モードやSSL相互認証モードが必要な場合などです。この場合、異なるSSLモード・ポートでリスニングする別のOracle Internet Directoryコンポーネント・インスタンスを作成する必要があります。

関連項目:
サーバー・インスタンスの構成方法の詳細は、第8章「Oracle Internet Directoryインスタンスの管理」を参照してください。

エンタープライズ・ユーザー・セキュリティのSSL構成の詳細は『Oracle Databaseエンタープライズ・ユーザー管理者ガイド』のエンタープライズ・ユーザー・セキュリティの構成に関する項を参照してください。

27.1.7 SSL相互運用性モード

非認証モードの場合、レガシーLDAP Cクライアントなど、11gリリース1 (11.1.1)より前に開発されたOracleレガシー・コンポーネントは、相互運用性モードが有効な(orclsslinteropmode = 1)インスタンスを使用してのみOracle Internet Directoryに接続できます。

Oracle Internet Directory 11g リリース1(11.1.1.7.0)以降、SSL相互運用性モードのデフォルト値は、JDK SSLに完全に準拠するために無効です(orclsslinteropmode=0)。

JSSE(Java Secure Socket Extensions)を使用した新規クライアントやOracle以外のクライアントの場合、相互運用性モードが無効なSSLインスタンスが必要です。SSL相互運用性モードが無効(orclsslinteropmode = 0)であることを前提として、Oracle Internet DirectoryはSun JDKのSSLに完全に準拠しています。

Oracle Internet Directoryがクライアントに不適切なモードで設定されている場合、クライアントからサーバーへのSSL接続で決定的ではない障害がまれに発生する可能性があります。

関連項目:
「SSL相互運用性モードの構成」

27.1.8 StartTLS

11g リリース1(11.1.1)以降、Oracle Internet Directoryは、startTLSをサポートしています。この機能を使用すると、非SSLポートでSSLセッションのオンデマンド・ネゴシエーションが有効になります。非SSLポートには特別な構成は必要ありません。Oracle Internet DirectoryでSSLエンドポイントが構成されている場合、クライアントは非SSLポートでstartTLSを使用して、SSLポートと同じ構成を持つ非SSLポートでSSL接続のネゴシエーションを実行できます。つまり、SSLポートで相互認証を使用する場合、startTLSは非SSLのポートで相互認証のネゴシエーションを実行しようとします。

27.2 Fusion Middleware Controlを使用したSSLの構成

Fusion Middleware Controlを使用したSSLの構成は、3つの基本的なタスクから構成されます。

1. Fusion Middleware Controlを使用したウォレットの作成

2. Fusion Middleware Controlを使用したSSLパラメータの構成

3. Oracle Internet Directoryの再起動。

関連項目:

- サーバーの停止および起動方法は、第8章「Oracle Internet Directoryインスタンスの管理」を参照してください。

- 「Fusion Middleware Controlを使用した証明書認証方式の構成」

- SSLパラメータの詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』を参照してください。

27.2.1 Fusion Middleware Controlを使用したウォレットの作成

SSLの構成時に使用する自己署名付きウォレットを作成するには、次の手順を実行します。

1. 「Oracle Internet Directory」メニューから、「セキュリティ」、「ウォレット」を選択します。ウォレットが存在する場合、リストが表示されます。

2. 新規ウォレットを作成するには、「自己署名付きウォレットの作成」を選択します。「自己署名付きウォレットの作成」ページが表示されます。

3. 「自己署名付きウォレットの作成」ページで、小文字のみを使用して新規ウォレットの名前を入力します。

4. 自動ログイン・ウォレットの場合、「自動ログイン」を選択します。Oracle Internet Directory用に構成されたウォレットは、自動ログインが有効になっている必要があります。

5. 「自動ログイン」の選択を解除した場合、2つのフィールドにパスワードを入力します。

6. 「共通名」に、インスタンスのホスト名を入力します。

7. リストからキー・サイズを選択します。

8. 「発行」をクリックします。

9. 確認メッセージが表示され、ウォレットのリストに新規ウォレットが表示されます。

関連項目:
Oracle Walletの詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

27.2.2 Fusion Middleware Controlを使用したSSLパラメータの構成

SSLを構成するためのウォレットを作成した後、次の手順を実行します。

1. 「Oracle Internet Directory」メニューから「管理」を選択し、「サーバー・プロパティ」を選択します。

2. 「SSL設定の変更」をクリックします。

3. 「SSL設定」ダイアログで次のようにします。

- 「SSLの有効化」を選択します。

- ウォレットを選択します。

- これが自動ログイン・ウォレットでない場合、ウォレット・パスワードを「サーバー・ウォレット・パスワード」フィールドに入力します。

- 必要に応じて、「拡張SSL設定」を展開します。

- 「SSL認証」を「サーバー」に設定します。

- 「暗号スイート」を「すべて」に設定します。

- 「SSLプロトコル・バージョン」を適切なバージョン(通常「v3」)に設定します。

- 「OK」をクリックします。

注意:
現在、TLS v1.1およびTLS v1.2プロトコルとそれに対応する暗号をOID Enterprise Manager Fusion Middleware Controlから構成する方法はありません。
回避策として、ldapmodifyコマンドを使用して属性orclcryptoversionを変更できます。第27.1.2項「サポートされているプロトコルのバージョン」を参照してください。

4. 「Oracle Internet Directory」→「可用性」→「再起動」と移動し、Oracle Internet Directoryインスタンスを再起動します。

相互認証モードでのSSL有効化の手順は、「SSL設定」ダイアログで「SSL認証」を「サーバー」ではなく相互に設定する点以外同じです。

注意:
アクティブ・インスタンスのパラメータを直接変更することはできません。

27.2.3 Fusion Middleware Controlを使用したSSLパラメータの設定

表27-4に、Oracle Internet Directoryに適用可能なOracle Enterprise Manager Fusion Middleware ControlのSSLパラメータを示します。これらはすべて、次の形式の識別名を持つインスタンス固有の構成エントリ内にあります。

"cn=componentname,cn=osdldapd,cn=subconfigsubentry."

注意:
Oracle Internet DirectoryでTLSを設定しているときは、orclsslversionの値を変更せず、デフォルト値の3のままにしてください。

SSL属性

表27-4 Fusion Middleware ControlのSSL関連の属性

フィールドまたはヘッダー

構成属性

サーバーSSLプロトコル・バージョン

orclsslversion

SSLウォレットURL

orclsslwalleturl

SSLの有効化

orclsslenable

SSL認証モード

orclsslauthentication

サーバー暗号スイート

orclsslciphersuite

SSL構成の変更を有効にするには、サーバーを再起動する必要があります。

27.3 WLSTを使用したSSLの構成

SSLを構成するには、次の手順を実行する必要があります。

1. Oracle Walletを作成します。

2. SSLパラメータを構成します。

3. Oracle Internet Directoryを再起動します。

wlstを使用してOracle Walletを作成し、SSLパラメータを構成するには、次の手順を実行します。

1. WebLogic管理サーバーのユーザー名、パスワードおよびポートを指定し、wlstを起動してホストに接続します。

ORACLE_COMMON_HOME/common/bin/wlst.sh
connect('username', 'password', 'protocol:localhost:7001')

2. 第9.3項「WLSTを使用したシステム構成属性の管理」の説明に従って、カスタムMBeanツリーから特定のMBean oracle.as.oidへと移動します。

custom()
ls()
cd('oracle.as.oid')
ls()

3. キーストアMBean内にすでにある証明書(存在する場合)を確認します。表9-7「Oracle Internet Directoryに関連するMBean」を参照してください。

listWallets('app_server_instance', 'oid_component', 'oid')

次に例を示します。

listWallets('inst1', 'oid1', 'oid')

4. 必要に応じて、自己署名付き証明書を新規作成します。

createWallet('inst1',
'oid1',
'oid',
'WALLET_NAME',
'WALLET_PASSWORD')

5. サーバー証明書として使用する自己署名付き証明書をウォレットに追加します。

addSelfSignedCertificate('inst1',
'oid1',
'oid',
'WALLET_NAME',
'WALLET_PASSWORD',
'cn=INSTANCE_HOST_NAME',
'key_size',
'alias=server-cert')

自己署名証明書ではなく、サード・パーティまたはカスタムの認証局発行の証明書を使用する場合、まず証明書をインポートする必要があります。手順については、『Oracle Fusion Middleware管理者ガイド』のキーストア、ウォレットおよび証明書の管理に関する章を参照してください。

6. 適切な認証モードを指定し、oid1コンポーネント・ノードのSSL用のリスナー/ポートを構成します。

configureSSL('app_server_instance',
'oid_component',
'oid',
'sslport1',
'property_file.prop')

Oracle Internet Directoryコンポーネントの場合、リスナー・ポートは常にsslport1であり、コンポーネント・タイプは常にoidです。次に例を示します。

configureSSL('inst1',
'oid1',
'oid',
'sslport1',
'myfile.prop')

この場合、myfile.propには次が含まれます。

KeyStore=WALLET_NAME
AuthenticationType=auth-type
SSLVersions=version
Ciphers=cipher
SSLEnabled=true

SSLのプロパティ・ファイルの詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

7. 第8章「Oracle Internet Directoryインスタンスの管理」の説明に従って、Oracle Internet Directoryを再起動し、変更をアクティブ化します。

8. 第8.3.4項「opmnctlを使用したOracleインスタンスのコンポーネント登録の更新」に記載のとおりopmnctl updatecomponentregistrationを実行します。

9. 第27.5項「Oracle Directory Services Managerを使用したSSL接続のテスト」および第27.6項「コマンド行によるSSL接続のテスト」で説明されている方法を使用して、SSLが有効であるかどうかを確認します。

注意:
WLSTは、そのSSLポートを介してOracle Internet Directoryを管理します。Oracle Internet DirectoryのSSLポートは、認証なしまたはサーバー認証用に構成されている必要があります。Oracle Internet Directory SSLポートが相互認証用に構成されている場合、WLSTを使用してOracle Internet Directoryパラメータを変更することはできません。第27.1.3項「SSL認証モード」を参照してください。

関連項目:

- wlstコマンドの詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

- ミドルウェア・コンポーネントとともにOracle Walletを使用する方法は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

27.4 LDAPコマンドを使用したSSLの構成

SSLを構成するには、次の手順を実行する必要があります。

1. Oracle Walletを作成します。

2. SSLパラメータを構成します。

3. Oracle Internet Directoryを再起動します。

関連項目:

- サーバーの停止および起動方法は、第8章「Oracle Internet Directoryインスタンスの管理」を参照してください。

- 第33.4項「コマンド行ツールを使用した証明書認証方式の構成」

- SSLパラメータの詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』を参照してください。

注意:
orapkiを使用してウォレットを構成することもできます。詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

すでにウォレットを作成している場合、wlstのかわりにldapmodifyを使用してSSLパラメータを変更できます。

たとえば、インスタンスoid1についてorclsslinteropmodeの値を1に変更するには、次のように入力します。

ldapmodify -D cn=orcladmin -q -p portNum -h hostname -f ldifFile

この場合、ldifFileには次が含まれます。

dn: cn=oid1,cn=osdldapd,cn=subconfigsubentry
changetype: modify
replace: orclsslinteropmode
orclsslinteropmode: 1

SSLパラメータは、インスタンス固有の構成エントリの属性です。これらの構成エントリには、次の形式の識別名があります。

cn=componentname,cn=osdldapd,cn=subconfigsubentry

次に例を示します。

cn=oid1,cn=osdldapd,cn=subconfigsubentry

表27-5にSSL属性を示します。

表27-5 SSL属性

属性

意味

orclsslversion

SSLバージョン

orclsslwalleturl

SSLウォレットURL

orclsslenable

SSL有効化

orclsslauthentication

SSL認証

orclsslinteropmode

SSL相互運用性モード

orclsslciphersuite

SSL暗号スイート

ldapsearchコマンドを使用して、SSL属性およびその値をリストできます。たとえば、oid1インスタンスで文字列orclsslを含む属性をリストするには、次のように入力します。

ldapsearch -p 3060 -D cn=orcladmin -q \
-b "cn=oid1,cn=osdldapd,cn=subconfigsubentry" \
-s base "objectclass=*" | grep -i orclssl

SSLパラメータを構成した後、第8章「Oracle Internet Directoryインスタンスの管理」の説明に従って、Oracle Internet Directoryを再起動します。

注意:
Oracle Enterprise Manager Fusion Middleware ControlまたはWLSTを使用してOracle Internet Directoryを管理する場合は、orclsslenableを1(SSLのみ)または2(非SSLおよびSSLモード)に設定してください。

27.5 Oracle Directory Services Managerを使用したSSL接続のテスト

Oracle Directory Services Managerを使用してSSL接続をテストする手順は、次のとおりです。

1. 第7.4.5項「Oracle Directory Services Managerの起動」の説明に従って、ODSMを起動します。

2. Oracle Internet Directoryサーバーに接続します。ログイン画面で、SSLを有効化し、SSLポートを指定します。

接続できた場合は、SSL接続は正常に機能しています。

27.6 コマンド行によるSSL接続のテスト

ldapbindコマンドを使用して、SSL接続をテストできます。UNIXでの構文は、次のとおりです。

ldapbind -D cn=orcladmin -q -U authentication_mode -h host -p SSL_port \
-W "file://DIRECTORY_CONTAINING_WALLET" -Q

Windowsでの構文は、次のとおりです。

ldapbind -D cn=orcladmin -q -U authentication_mode -h host -p SSL_port \
-W "file:device:\DIRECTORY_CONTAINING_WALLET" -Q

ここで、authentication_modeは、次のいずれかです。

数値

認証

1

SSL認証なしを必要とします。

2

一方向(サーバーのみ)のSSL認証を必要とします。

3

双方向(クライアントとサーバー)のSSL認証を必要とします。

関連項目:
『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のldapbindコマンド行ツールのリファレンス。

27.6.1 暗号化のみのSSLのテスト

SSL認証なしを必要とするSSL構成をテストするには、この方法を使用します。構文は次のとおりです。

ldapbind -D cn=orcladmin -q -U 1 -h host -p SSL_Port

27.6.2 サーバー認証を必要とするSSLのテスト

SSLサーバー認証の設定されたSSL構成をテストするには、この方法を使用します。クライアントがサーバー認証をリクエストするかどうかは、任意に選択できます。

サーバー認証を使用した匿名バインド用の構文は、次のとおりです。

ldapbind -U 2 -h host -p SSL_Port -W "file:DIRECTORY_CONTAINING_WALLET" -Q

ユーザーcn=orcladmin、ウォレット・ファイルORACLE_INSTANCE/OID/admin/mywalletおよびサーバー認証を使用したバインド用の構文は、次のとおりです。

ldapbind -D cn=orcladmin -q -U 2 -h SSL_Port -p port \
-W "file:ORACLE_INSTANCE/OID/admin/mywallet" -Q

SSL認証を使用しないバインド用の構文は、次のとおりです。

ldapbind -D cn=orcladmin -q -U 1 -h host -p SSL_Port

27.6.3 クライアントおよびサーバー認証を必要とするSSLのテスト

SSLクライアントおよびサーバー認証の設定されたSSL構成をテストするには、この方法を使用します。

Oracle Internet Directoryでは、証明書の一致規則がサポートされます。ldapbindコマンド行で渡される識別名とパスワードは、無視されます。認証に使用されるのは、証明書または証明書ハッシュの識別名のみです。

関連項目:
第33.1.1項「直接認証」

クライアント証明書のバインド識別名(DN)を使用するための構文は、次のとおりです。

ldapbind -U 3 -h host -p SSL_Port -W "file:DIRECTORY_CONTAINING_WALLET" -Q

27.7 SSL相互運用性モードの構成

相互運用性モードの詳細は、第27.1.7項「SSL相互運用性モード」を参照してください。

11g リリース1(11.1.1)より前に開発されたOracleコンポーネントとの互換性を確保するためにSSL相互運用性モードを設定するには、次のコマンドを使用します。

ldapmodify -D cn=orcladmin -q -p portNum -h hostname -f ldifFile

この場合、ldifFileには次が含まれます。

dn: cn=oid1,cn=osdldapd,cn=subconfigsubentry
changetype: modify
replace: orclsslinteropmode
orclsslinteropmode: 1

SSLパラメータを構成した後、第8章「Oracle Internet Directoryインスタンスの管理」の説明に従って、Oracle Internet Directoryを再起動します。

28 データ・プライバシの構成

この章では、データ・プライバシについて説明し、Oracle Internet Directoryがデータの受信後にそれを保護する仕組みについて説明します(送信中のデータはSSLによって保護されるため)。具体的には、Oracle Databaseの透過的データ暗号化(TDE)を使用して表領域の暗号化を有効化および無効化する方法、Oracle Database Vaultを構成してOracle Internet Directoryデータを保護する方法、および機密の属性とハッシュ属性を構成する方法について説明します。

この章の内容は次のとおりです。

- 第28.1項「表領域の暗号化の概要」

- 第28.2項「表領域の暗号化の有効化と無効化」

- 第28.3項「Database VaultとOracle Internet Directoryの使用方法の概要」

- 第28.4項「Oracle Database Vaultの構成によるOracle Internet Directoryデータの保護」

- 第28.5項「Database VaultとOracle Internet Directoryの使用方法のベスト・プラクティス」

- 第28.6項「機密の属性の概要」

- 第28.7項「受信した機密の属性のプライバシの構成」

- 第28.8項「ハッシュ属性の概要」

- 第28.9項「ハッシュ属性の構成」

28.1 表領域の暗号化の概要

Oracle Databaseの透過的データ暗号化(TDE)は、Oracle Enterprise User Securityの1コンポーネントであり、ディスクへの書込み時のデータ暗号化と認可ユーザーによる読取り時の復号化を透過的に行います。TDEは、ストレージ・メディアまたはデータ・ファイルが盗まれた場合に、メディア上に格納されたデータの保護に役立ちます。アプリケーションの変更は不要であり、ストレージ・メディア上のデータの暗号化はユーザーには透過的に行われます。

Oracle Database 11g Advanced Securityの透過的データ暗号化では、データベースの表領域の暗号化を新たにサポートしています。暗号化された表領域内に作成されたオブジェクトはすべて自動的に暗号化されます。暗号化された表領域内のデータはすべて、暗号化された形式でディスク上に格納されます。データ・ブロックは、Oracle Databaseによるアクセス時に透過的に復号化されます。表領域の暗号化によって、列の暗号化の外部キー制限が解消され、暗号化されたデータの索引レンジ・スキャンが可能になります。

28.2 表領域の暗号化の有効化と無効化

Oracle Internet Directoryで使用するOracle Databaseの表領域の暗号化を有効化または無効化する手順は、次のとおりです。

注意:
以前に表領域の暗号化を有効化または無効化したことがあり、再度有効化する場合、手順7に進みます。

1. Oracle Internet Directoryインスタンスで使用するOracle Databaseのコールド・バックアップを作成します。

2. データベースのOracleホームにJava VMパッケージとXML Developer's Kitパッケージがインストールされていることを確認します。
指定のパッケージがインストールされているかどうかを確認するには、次のSQL*Plusを実行します。

SELECT comp_id, status FROM dba_registry;

次のPL/SQLプロシージャを実行します。

sys.dbms_metadata_util.load_stylesheets

3. SYSTEM権限のあるユーザーとしてSQL*Plusにログインし、次のコマンドを実行します。

GRANT CREATE ANY DIRECTORY TO ods;

4. Oracle Data Pumpユーティリティのディレクトリ・オブジェクト、ダンプ・ファイルに使用するログ・ディレクトリ・オブジェクトおよびログ・ファイルを作成します。ODSユーザーとしてSQL*Plusにログインし、次のコマンドを実行します。

CREATE OR REPLACE DIRECTORY directory_object_name as directory_path;
CREATE OR REPLACE DIRECTORY log_directory_object_name as log_directory_path;

5. directory_pathとlog_directory_pathをファイル・システムに作成します。

6. データベース・ウォレットの場所をデータベースのOracleホームのsqlnet.ora内に設定します。

注意:
データベース・ウォレットを、第27章で説明しているOracle Internet Directoryウォレットと混同しないでください。

表領域の暗号化専用に個別のウォレットを使用することをお薦めします。

1. 表領域の暗号化用に個別のデータベース・ウォレットを使用するには、sqlnet.oraにパラメータENCRYPTION_WALLET_LOCATIONを設定します。次に例を示します。

ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/install/db11g/dbs)))

2. すべてのOracleコンポーネントで同じデータベース・ウォレットを共有して使用するには、sqlnet.oraにパラメータWALLET_LOCATIONを設定します。次に例を示します。

WALLET_LOCATION= (SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/install/db11g/dbs)))

7. Oracle DatabaseのOracleホームを使用しているすべてのOracle Internet Directoryインスタンスを停止します。

8. Oracle DatabaseのOracleホームで表領域の暗号化を初めて有効化する場合は、ALTER SYSTEM権限のあるユーザーとしてSQL*Plusにログインし、次のコマンドを実行します。

ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY yourwalletpassword;

9. Oracle Databaseを停止して再起動するたびに、ALTER SYSTEM権限のあるユーザーとしてSQL*Plusにログインし、次のコマンドを実行します。

ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY yourwalletpassword;

Oracle Internet Directoryを起動する前と、手順12に示すPerlスクリプトを実行する前に、このコマンドを必ず実行してください。

10. 環境変数ORACLE_HOMEをOracle Databaseのホームに設定します。

11. 環境変数NLS_LANGをOracle Databaseサーバーの文字セットに設定します。

12. コンピュータ上のperl5の場所と一致するようPerlスクリプトORACLE_HOME/ldap/datasecurity/oidtbltde.pl内のperl5実行可能ファイルのパスを編集します。

13. Perl用のデータベース非依存インタフェース・モジュール(DBI)とPerl用のOracle DBDドライバがインストールされていない場合は、この2つをインストールします。

14. Perlスクリプトoidtbltde.plを実行し、Oracle Internet DirectoryのTDEを有効化または無効化します。

28.3 Database VaultとOracle Internet Directoryの使用方法の概要

Oracle Internet Directoryでは、LDAPプロトコル層でアクセス制御を適用します。ただし、DBAなどの特権ユーザーは通常、基礎となるデータベース内のOracle Internet DirectoryデータにSQL*Plusでアクセスできます。

Oracle Database Vaultを使用すると、特権ユーザーによるOracle Internet Directoryデータへの不正アクセスを防止できます。このためには、Oracle Database Vaultをインストールして有効化し、Oracle Internet Directoryで使用するODSデータベース・スキーマを含むDatabase Vaultレルムを設定し、ODSデータベース・アカウントのみにデータ・アクセスを許可するポリシーを設定する必要があります。

関連項目:

- Oracle Database Vaultのインストール、有効化および無効化のクイック・ガイドは、『Oracle Database 2日でセキュリティ・ガイド』を参照してください

- Oracle Database Vaultの管理の詳細は、『Oracle Database Vault管理者ガイド』を参照してください

28.4 Oracle Database Vaultの構成によるOracle Internet Directoryデータの保護

Oracle Database Vaultは、Oracle Internet Directory用に構成する前にインストールおよび登録する必要があります。Database Vaultは、Oracle Databaseインストールの一部としてインストールします。

28.4.1 Oracle Database Vaultの登録

Oracle Database VaultがOracle Database 11gにインストールされているかどうか不明な場合は、次のように入力します。

SELECT * FROM V$OPTION WHERE PARAMETER = 'Oracle Database Vault';

入力は、SQL*Plusプロンプトで行います。この問合せにOracle Database Vaultと返された場合、Oracle Database Vaultはインストールおよび登録されています。この問合せは大/小文字が区別されることに注意してください。

Oracle Database VaultがOracle Database 11gに登録されていない場合、次の手順を実行します。

1. 『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』の説明に従って、Oracle Internet Directoryをインストールします。

2. 『Oracle Database Vault管理者ガイド』の説明に従って、Oracle Database Vaultを登録します。

3. Oracle Databaseのバージョンが11.1.0.7である場合は、バグ7244497のパッチをダウンロードしてインストールします。これは、より新しいバージョンのOracle Databaseでは必要ありません。

4. Oracle Databaseのバージョンが11.1.0.7である場合は、バグ7291157のパッチをダウンロードしてインストールします。これは、より新しいバージョンのOracle Databaseでは必要ありません。

Oracle Database VaultがOracle Databaseに登録されている場合、次の手順を実行します。

1. Oracle Database Vaultが有効化されている場合は、無効化します。『Oracle Database Vault管理者ガイド』の「Oracle Database Vaultの無効化および有効化」を参照してください。

2. 『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』の説明に従って、Oracle Internet Directoryをインストールします。

3. 『Oracle Database Vault管理者ガイド』の説明に従って、Database Vaultを有効化します。

4. Oracle Database 11.1.0.7を使用している場合は、バグ7244497のパッチをダウンロードしてインストールします。

5. Oracle Database 11.1.0.7を使用している場合は、バグ7291157のパッチをダウンロードしてインストールします。

28.4.2 Oracle Internet Directory用のDatabase Vaultレルムおよびポリシーの追加

Oracle Internet Directoryには、必要なDatabase Vaultポリシーを適用するためのスクリプトが用意されています。これらのスクリプトは、$ORACLE_HOME/ldap/datasecurityの下にあるOracle Internet Directoryのインストール・ディレクトリに含まれています。

Database VaultポリシーをOracle Internet Directoryデータベースに適用するには、Oracle Internet Directory用のデフォルトのDatabase Vaultレルムを次のように作成する必要があります。

1. dbv_oid_rule.sqlをテキスト・エディタで開き、Check ods connectionsルールとCheck ods connections 2ルール内のダミーIPアドレスを次のアドレスに置き換えます。
Oracle Internet Directoryが実行されているコンピュータのIPアドレス

2. データベースにDatabase Vault所有者として接続し、dbv_create_oid_policies.sqlを実行します。

dbv_create_oid_policies.sql内のポリシーにより、Oracle Internet DirectoryデータベースへのSQL*Plusアクセスが完全に禁止されます。一部のタスクでは、ODSユーザーとしてSQL*Plusでデータベースにアクセスする必要があります。この場合、Oracle Internet DirectoryデータベースへのSQL*Plusアクセスを特定のホストからのみ許可します。

Oracle Internet Directoryデータベースへの接続を許可する手順は、次のとおりです。

1. dbv_oid_rule_sqlplus.sqlをテキスト・エディタで開きます。Check ods connections 3ルール内のダミーIPアドレスを、Oracle Internet DirectoryデータベースへのSQL*Plusアクセスを許可するホストのIPアドレスに置き換えます。

2. データベースにDatabase Vault所有者として接続し、dbv_oid_rule_sqlplus.sqlを実行します。

ある時点でOracle Internet DirectoryデータベースへのSQL*Plusアクセスを完全にブロックする場合は、Database Vault所有者としてデータベースに接続し、dbv_oid_delete_rule_sqlplus.sqlを実行します。

28.4.3 Oracle Internet Directory用のOracle Database Vault構成の管理

データ・ディクショナリ・ビューの使用方法は、『Oracle Database Vault管理者ガイド』の「Oracle Database Vaultオブジェクト」を参照してください。この項では、Oracle Internet Directory関連の情報を報告するいくつかのビューについて説明します。

Oracle Internet Directoryで使用するDatabase Vaultレルムの名前はOID Realmです。このレルムの存在は、DBA_DV_REALMデータ・ディクショナリ・ビューに問合せを実行すると確認できます。

Oracle Internet Directory用に定義されているDatabase Vaultルールは、Check ods connections、Check ods connections 2、Check odssm connectionsおよびAllow other connectionsです。dbv_oid_rule_sqlplus.sqlを実行すると、ルールCheck ods connection 3も定義されます。これらのルールは、OID App Accessという名前のルール・セットに追加されます。既存のルールの名前を確認するには、DBA_DV_RULE_SET_RULEビューに問合せを実行します。

CONNECTコマンド・ルールにより、このルール・セットが起動されます。これは、DBA_DV_COMMAND_RULEビューに問合せを実行すると確認できます。このCONNECTルールでは、インストールされている既存のOracle Database VaultでOracle Internet Directoryスクリプトを実行する際、既存のCONNECTコマンド・ルールが上書きされません。

28.4.4 Oracle Internet Directory用のDatabase Vaultポリシーの削除

前述の項でインストールしたOID用のDatabase Vaultポリシーを削除するには、データベースにDatabase Vault所有者として接続している間にdbv_delete_oid_policies.sqlを実行します。

28.4.5 Oracle Internet Directoryデータベース用のOracle Database Vaultの無効化

『Oracle Database Vault管理者ガイド』の「Oracle Database Vaultの有効化および無効化」を参照してください。

28.5 Database VaultとOracle Internet Directoryの使用方法のベスト・プラクティス

Oracle Database Vaultの使用時は、次の管理タスクに特別な注意が必要です。

- 製品のアップグレードおよびパッチ・セットのインストール: Oracle Internet DirectoryまたはOracle Databaseをアップグレードする前、またはパッチ・セットをインストールする前に、Oracle Database Vaultを無効化します。アップグレードまたはインストールの完了後、Oracle Database Vaultを再度有効化します。

- データのバルク・ロード: Oracle Database Vaultが有効化されている場合、SQL*Loaderのダイレクト・パス・モードは使用できなくなり、bulkloadツールのパフォーマンスが低下します。100KBを超えるデータ、または100万を超えるエントリをロードする場合は、bulkloadを使用する前にOracle Database Vaultを無効化します。操作の完了後、Oracle Database Vaultを再度有効化します。

- マルチマスターDRGの変更: Oracle Databaseアドバンスト・レプリケーション・ベースのマルチマスター・ディレクトリ・レプリケーション・グループ内のノードを追加または削除する前に、そのノードでOracle Database Vaultを無効化します。操作の完了後、Oracle Database Vaultを再度有効化します。

28.6 機密の属性の概要

Oracle Internet Directoryは、機密の属性を暗号化形式で格納します。機密の属性の例としては、orclpasswordattribute、orclrevpwd、プラグイン属性orclpluginsecuredflexfieldおよびサーバー・チェーン属性orclOIDSCExtPasswordがあります。

28.6.1 機密の属性のリスト

機密の属性のリストは、DSA構成エントリ内の属性orclencryptedattributesに格納されています。このリストを表28-1に示します。

表28-1orclencryptedattributesに格納されている機密の属性

機密の属性

属性の使用方法

orclpluginsecuredflexfield

プラグインに渡される機密の属性。第45章を参照してください。

orcloidscextpassword

プラグイン接続用のサーバー管理パスワード。

第45章を参照してください。

orcloidscwalletpassword

プラグインのsslwalletパスワード。第38章を参照してください。

orclrevpwd

可逆暗号化形式のユーザー・パスワード。第31章を参照してください。

orclunsyncrevpwd

関連するuserpasswordと同期されない可逆暗号化パスワード。第31章を参照してください。

orclodipprofileinterfaceconnectinformation

Oracle Directory Integration Platform: イベント伝播用のアプリケーションとの接続に使用される情報。

orclodipcondiraccesspassword

Oracle Directory Integration Platform: ディレクトリに接続するためにサード・パーティ・ディレクトリによって使用されます。

orclodipagentpassword

Oracle Directory Integration Platform: ディレクトリへのバインドに同期プロファイルで使用するパスワード。

最後の3エントリの詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』の「属性リファレンス」の章を参照してください。

orcldataprivacymode属性は、データの受信時にこれらの属性を暗号化するかどうかを制御します。orcldataprivacymodeが有効な場合、機密の属性は暗号化されます。プライバシ・モードが無効の場合、機密のデータはクリアテキストで返されます。

暗号化された属性を機密の属性のリストに追加する場合、新しい属性が機密の属性の新しいリストに追加され、サーバーによって認識されるように、Oracle Internet Directoryサーバー・インスタンスを再起動する必要があります。

注意:
表28-1「orclencryptedattributesに格納されている機密の属性」の属性は、Oracleでの使用のみを目的としています。Oracleサポートによって要求されないかぎり、この表に示される属性の追加または変更は行わないでください。

28.6.2 機密の属性の暗号化アルゴリズム

11g リリース1(11.1.1.4.0)より前は、Oracle Internet Directoryは機密の属性の格納に3DES暗号化アルゴリズムを使用していました。11g リリース1(11.1.1.4.0)以上では、Oracle Internet DirectoryはAES-256を使用しています。

以前のリリースの顧客は、システムにパッチを適用している場合、3DESアルゴリズムで暗号化された格納値をすでに持っている可能性があります。このような場合は、次の規則が適用されます。

- 復号化するときに、Oracle Internet Directoryは適切なアルゴリズム(3DESまたはAES-256)を使用して値を復号化します。

- 暗号化するときに、Oracle Internet Directoryは常にAES-256を使用して暗号化します。

これにより、時間の経過とともに、暗号化されたすべての値が確実にAES-256に変換されます。

28.7 受信した機密の属性のプライバシの構成

プライバシ・モードはデフォルトでは無効です。つまり、orcldataprivacymodeの値は0です。セキュリティ保護を提供するには、DSA構成エントリでorcldataprivacymodeの値を0から1に変更することで、プライバシ・モードを有効にする必要があります

orcldataprivacymodeの値を決定するには、次の検索を実行します。

$ORACLE_HOME/bin/ldapsearch -h host -p port -D cn=orcladmin -q \
-b "cn=dsaconfig,cn=configsets,cn=oracle internet directory" -s base \
"objectclass=*" orcldataprivacymode

プライバシ・モードを有効にするには、次のエントリが含まれるLDIFファイルを使用します。

dn: cn=dsaconfig,cn=configsets,cn=oracle internet directory
changetype: modify
replace: orcldataprivacymode
orcldataprivacymode: 1

LDIFファイルを次のようなコマンド行によりロードします。

$ORACLE_HOME/bin/ldapmodify -h host -p port -D cn=orcladmin -q -v \
-f LDIF_file_name

28.8 ハッシュ属性の概要

暗号化とは異なり、ハッシングは一方向操作です。ハッシュ値から元の値を導出することはできません。Oracle Internet Directoryは、機密の属性に加えて、ハッシュ属性もサポートしています。ハッシュ属性のリストは、DSA構成エントリの複数値属性であるorclhashedattributesに含まれています。ハッシングは、ルートDSE属性orclcryptoschemeで設定されている暗号スキームを使用して実行されます。

LDAP操作およびbulkloadは、表28-2で説明している変換を自動的に実行します。ハッシュ属性を指定してbulkmodifyコマンドを使用することはできません。

表28-2 orclhashedattributesの属性に対するLDAP操作とバルク操作

操作

着信属性値がすでにハッシュされている場合

着信属性値がハッシュされていない場合

ldapadd

値をそのまま使用します。

操作を実行する前に、orclcryptoschemeを使用して着信値をハッシュします。

ldapmodify

値をそのまま使用します。

追加操作または置換操作の場合は、操作を実行する前に、orclcryptoschemeを使用して着信値をハッシュします。

削除操作の場合、操作を実行する前に、属性がディレクトリに格納されたときに使用されていた暗号スキームを使用して着信値をハッシュします。

ldapcompare

着信値を、ディレクトリに格納されている値と比較します。

属性がディレクトリに格納されたときに使用された暗号スキームを使用して着信値をハッシュし、それを格納値と比較します。

bulkload

値をそのまま使用します。

操作を実行する前に、orclcryptoschemeを使用して着信値をハッシュします。

bulkmodify

bulkmodifyは許可されていません。

bulkmodifyは許可されていません。

注意:

- orclhashedattributesとorclencryptedattributesの両方に同じ属性を含めないでください。

- 単一値属性のみをハッシュ属性にすることができます。

28.9 ハッシュ属性の構成

Oracle Enterprise Manager Fusion Middleware Controlまたはコマンド行を使用して、orclhashedattributesの属性のリストを管理できます。

28.9.1 Fusion Middleware Controlを使用したハッシュ属性の構成

Oracle Enterprise Manager Fusion Middleware Controlの「共有プロパティ」ページを使用して、ハッシュ属性を構成できます。

「Oracle Internet Directory」メニューから「管理」を選択し、「共有プロパティ」を選択します。

28.9.2 ldapmodifyを使用したハッシュ属性の構成

コマンド行を使用してハッシュ属性を構成するには、その属性名をDSA構成エントリの複数値属性orclhashedattributeに追加します。

たとえば、次のLDIFファイルでは、3つの属性がorclhashedattributesに追加されます。

dn: cn=dsaconfig,cn=configsets,cn=oracle internet directory
changetype:modify
add: orclhashedattributes
orclhashedattributes: attributeName1
orclhashedattributes: attributeName2
orclhashedattributes: attributeName3

LDIFファイルを次のようなコマンド行によりロードします。

$ORACLE_HOME/bin/ldapmodify -h host -p port -D cn=orcladmin -q -v \
-f LDIF_file_name

29 パスワード・ポリシーの管理

この章では、パスワードの使用方法を制御するルールのセットであるパスワード・ポリシーをOracle Internet Directoryで管理する方法について説明します。具体的には、デフォルト・ポリシーと細かなポリシーを含むパスワード・ポリシーについて説明し、Oracle Directory Services Manager (ODSM)およびLDAPコマンド行ユーティリティを使用してパスワード・ポリシーを管理する方法について説明します。

この章の内容は次のとおりです。

- 第29.1項「パスワード・ポリシーの管理の概要」

- 第29.2項「Oracle Directory Services Managerを使用したパスワード・ポリシーの管理」

- 第29.3項「コマンド行ツールを使用したパスワード・ポリシーの管理」

注意:
この章で言及するOracle Delegated Administration Servicesはすべて、Oracle Delegated Administration Services 10g(10.1.4.3.0)以上のことです。

29.1 パスワード・ポリシーの管理の概要

パスワード・ポリシーとは、パスワードの使用方法を定めた一連の規則のことです。ユーザーがディレクトリへのバインドを試みると、ディレクトリ・サーバーは、ユーザーのパスワードがパスワード・ポリシーの様々な要件に適合するかを確認します。

パスワード・ポリシーを確立する際は、次のような規則を設定します。なお、この規則はほんの一部です。

- 指定されたパスワードの最長有効期間

- パスワードの最小必須文字数

- パスワードに必要な数字の文字数

この項の項目は次のとおりです。

- 第29.1.1項「パスワード・ポリシーとは」

- 第29.1.2項「パスワード・ポリシーの作成および適用に必要な手順」

- 第29.1.3項「細かなパスワード・ポリシー」

- 第29.1.4項「デフォルトのパスワード・ポリシー」

- 第29.1.5項「パスワード・ポリシーの属性」

- 第29.1.6項「パスワード・ポリシー関連の操作属性」

- 第29.1.7項「パスワード・ポリシー情報のディレクトリ・サーバー検証」

- 第29.1.8項「パスワード・ポリシーのエラー・メッセージ」

- 第29.1.9項「10g (10.1.4.0.1)より前のリリース」

29.1.1 パスワード・ポリシーとは

パスワード・ポリシーとは、パスワードの構文および使用方法を管理する規則のセットです。Oracle Internet Directoryによって施行されるパスワード・ポリシーには、次のものがあります。

- 指定されたパスワードの最長有効期間

- パスワードの最小必須文字数

- パスワードに必要な数字の最小数

- アルファベット文字の最小数

- 繰返し文字の最小数

- 大文字および小文字の使用

- 英数字以外の文字(特殊文字)の最小数

- ユーザーによる定期的なパスワードの変更

- パスワード変更の最小および最大間隔

- パスワードの期限切れ(時間またはログイン回数による)後のログインの猶予期間

- 以前使用したパスワードのユーザーによる再利用禁止

29.1.2 パスワード・ポリシーの作成および適用に必要な手順

パスワード・ポリシーを設定する手順は、次のとおりです。

1. 該当するコンテナにパスワード・ポリシー・エントリを作成し、それをpwdpolicyオブジェクトと関連付けます。(Oracle Internet Directoryを初めてインストールする場合、デフォルトのエントリが存在します。)

2. 手順1で作成したエントリのpwdpolicyオブジェクト・クラスの下で定義された属性の値を設定して、希望するポリシーを作成します。

3. orclepwdpolicynable属性を1に設定することにより、ポリシーを有効にします。これが1に設定されていない場合、Oracle Internet Directoryはポリシーを無視します。

4. ポリシーによって管理されるサブツリーを決定します。ポリシーの識別名を指定したpwdpolicysubentry属性をサブツリーのルートに追加および移入します。

関連項目:
pwdPolicyオブジェクト・クラス、およびパスワード・ポリシーに関連するtopオブジェクト・クラスの属性のリストおよび説明は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のオブジェクト・クラスのリファレンスを参照してください。

29.1.3 細かなパスワード・ポリシー

10g (10.1.4.0.1)以降のOracle Internet Directoryでは、各レルムでの複数のパスワード・ポリシーをサポートします。これらのポリシーは、そのレルム内のどのサブツリーにも適用できます。つまり、エントリ固有のパスワード・ポリシーを使用できます。

パスワード・ポリシーは、レルム固有または有効範囲がディレクトリ全体のものとして指定できます。希望する有効範囲を実現するには、適切なコンテナにパスワード・ポリシー・エントリを作成する必要があります。パスワード・ポリシーは、各レルムのcn=commonエントリの下に作成されたcn=pwdPoliciesコンテナの下に移入されます。デフォルトでは、これらのコンテナに、相対識別名cn=defaultのパスワード・ポリシーが入っています。たとえば、ディレクトリ固有のデフォルトのパスワード・ポリシーの識別名は、cn=default,cn=pwdPolicies,cn=Common,cn=Products, cn=OracleContextになります。

その他のポリシーは、別の相対識別名を持つpwdPoliciesコンテナの下に作成できます。図29-1に、このシナリオを示します。

図29-1 パスワード・ポリシー・エントリの位置

図29-2 パスワード・ポリシーの識別名が移入されたpwdPolicyサブエントリ属性

実行時に、Oracle Internet Directoryは、エントリの移入されているpwdpolicysubentry属性を探し、その値で示されたポリシーを適用して、エントリで適用可能なパスワード・ポリシーを解決します。移入されたpwdPolicysubentry属性が存在しない場合、Oracle Internet Directoryは、pwdPolicysubentryが移入されている一番近い上位エントリが見つかるまで、ディレクトリ・ツリーを遡っていきます。Oracle Internet Directoryは、そのエントリの値で示されたパスワード・ポリシーを適用します。

注意:

- グループに適用したパスワード・ポリシーが、グループ・メンバーに自動的に適用されることはありません。ポリシーを個々のエントリまたは祖先エントリに適用する必要があります。

- パスワード・ポリシーは、orclpwdpolicyenableを0に設定することで無効にできます。無効にすると、ディレクトリのその部分は適用できるパスワード・ポリシーのない状態のままになります。Oracle Internet Directoryは、適用できる有効なポリシーを見つけるためにDITを遡らなくなります。この属性を0に設定すると、ディレクトリの一部を必要に応じてパスワード・ポリシーなしにしておくことができます。ただし、このような変更を行う意味について実行する前に考慮する必要があります。

- パスワード・ポリシー・エントリは、第30章「ディレクトリ・アクセス制御の管理」で説明しているOracle Internet DirectoryのACIインフラストラクチャを使用して、匿名アクセスから保護する必要があります。これは、パスワード・ポリシーが脆弱な場合、その情報が攻撃する者の助けとなって、ディレクトリを危険にさらす恐れがあるため、特に重要です。

29.1.4 デフォルトのパスワード・ポリシー

Oracle Internet Directoryのデフォルトのパスワード・ポリシーは次のとおりです。

- パスワードの有効期限は120日です。

- 10回ログインに失敗すると、アカウントがロックアウトされます。スーパーユーザー・アカウントを除き、すべてのアカウントは、ディレクトリ管理者がパスワードを再設定するまで、24時間ロックされたままになります。アカウント・ロックアウト継続時間が経過しても、正しいパスワードでバインドするまでユーザー・アカウントはロックされたままになります。
スーパーユーザー・アカウントであるcn=orcladminがロックされると、OIDデータベース・パスワード・ユーティリティを使用してロックを解除するまで、ロックされたままになります。このユーティリティでは、ODSユーザー・パスワードの入力が要求されます。ODSパスワードを入力すると、アカウントのロックが解除されます。

関連項目:

- スーパーユーザー・アカウントのロック解除の詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のoidpasswdコマンド行ツールのリファレンスを参照してください。

- 第R.1.6項「パスワード・ポリシーに関するトラブルシューティング」

- パスワードの最小文字数は5で、1つ以上の数字を含める必要があります。

- パスワードの期限切れの警告は、期限終了前7日に出ます。

- パスワードの期限切れ後、5回の猶予期間ログインが許されます

Oracle Internet Directoryリリース9.0.4からは、ルートOracleコンテキストのパスワード・ポリシー・エントリがスーパーユーザーに適用されますが、アカウントのロックアウトを管理するパスワード・ポリシーのみがそのアカウントに適用されます。

注意:
Oracle Identity Managementには、2つのタイプの特権ユーザーが存在します。どちらの特権ユーザー・アカウントも、特定のパスワード・ポリシーがアクティブになるとロックできます。
最初のタイプの特権ユーザーは、識別名cn=orcladminのスーパーユーザーで、デフォルトのアイデンティティ管理レルム内の特別なユーザー・エントリとして表されます。これによって、ディレクトリ管理者はDITを任意に変更し、Oracle Internet Directoryサーバーの構成を任意に変更できます。このスーパーユーザー(orcladmin)アカウントが、誤ったパスワードでのバインドを何度も試行したなどの理由でロックされた場合、Oracle Internet Directoryリポジトリに対するDBA権限を持つ管理者は、oidpasswdツールを使用してロックを解除できます。orcladminアカウントのロックを解除するには、次のコマンドを実行します。

oidpasswd connect="connt_String" unlock_su_acct=TRUE

もう一方の特権ユーザーは、レルム固有の特権ユーザーで、レルム内のユーザーやグループの作成と削除などの機能、およびOracle Delegated Administration Servicesに関連するすべての機能を制御します。このアカウントは、識別名cn=orcladmin,cn=users,realm DNのエントリにより表されます。単一のスーパーユーザー・アカウントの場合と比較すると、各レルムにレルム固有の独自の特権ユーザーが存在することになります。レルム固有の特権アカウントのロックを解除する場合は、もう一方のタイプの特権ユーザーであるcn=orcladminが、Oracle Directory Services Managerを使用して該当するアカウントのパスワードを変更します。

Oracle Internet Directoryのパスワード・ポリシーは、シンプルなバインド(userpassword属性に基づく)、userpassword属性に対する比較操作およびSASLバインドに適用されます。SSLバインドおよびプロキシ・バインドには適用されません。

29.1.5 パスワード・ポリシーの属性

次の属性は、パスワード・ポリシーに影響を与えます。

表29-1 パスワード・ポリシーの属性

名前

機能

pwdMinAge

ユーザーによるパスワードへの変更から変更までに必要な経過時間(秒)。デフォルトは0です。

pwdMaxAge

パスワードが有効である最大時間(秒)。この時間に達すると同時に、パスワードは期限切れになったとみなされます。デフォルトは10368000秒(120日)です。

pwdLockout

これに該当する場合、サーバーでは、無効なログインを何回か連続して試行したユーザーをロックアウトします。この回数はpwdMaxFailureで指定します。pwdLockoutのデフォルト値は1(TRUE)です。

orclpwdIPLockout

これがTRUEの場合、サーバーは、同じIPアドレスから無効なログインを何回か連続して試行したユーザーをロックアウトします。この回数はorclpwdIPMaxFailureで指定されます。デフォルトはFALSEです。

pwdLockoutDuration

無効なログイン試行回数がしきい値に達したユーザー・アカウントをロックアウトする期間(秒)。デフォルトは86400秒(24時間)です。

orclpwdIPLockoutDuration

同じIPアドレスからの無効なログイン試行回数がしきい値に達したユーザー・アカウントをロックアウトする期間(秒)。デフォルトは0です。

pwdMaxFailure

ユーザー・アカウントをロックアウトする前に、サーバーが許可する無効なログインの最大試行回数。デフォルト値は10です。

orclpwdIPMaxFailure

ユーザー・アカウントをロックアウトする前に、サーバーが許可する特定のIPアドレスからの無効なログインの最大試行回数。デフォルトは0です。

pwdFailureCountInterval

認証に成功しなくても、失敗カウンタからパスワードの失敗がパージされるまでの時間(秒)。この値が0である場合、失敗回数はパージされません。デフォルトは0です。

pwdExpireWarning

パスワードが期限切れになるまでの最大時間(秒)で、期限切れ警告メッセージが認証ユーザーに返されます。デフォルトは604800秒(7日)です。

pwdCheckSyntax

パスワードの構文チェックを有効または無効にします

0: すべての構文チェックを無効にします。

1: パスワード構文値チェックを暗号化されたパスワードを除き有効にします(デフォルト)。

pwdMinLength

このポリシーで管理されるパスワードの最小文字数。デフォルトは5文字です。

pwdGraceLoginLimit

パスワードの期限切れ後に許可する猶予期間ログインの最大数。デフォルトは5です。最大数は250です。

orclpwdGraceLoginTimeLimit

パスワードの期限切れ後に猶予期間ログインを許可する最大時間(秒)。orclpwdGraceLoginTimeLimitが0以外の場合、pwdGraceloginLimitは0にします。pwdGraceloginLimitが0以外の場合、orclpwdGraceLoginTimeLimitは0にします。

pwdMustChange

ユーザーは、アカウント作成後、または管理者によるパスワードの再設定後の最初のログイン時に、パスワードを再設定する必要があります。デフォルトは0(FALSE)です。

orclpwdIllegalValues

パスワードとして許可されない値のリストです。

orclpwdAlphaNumeric

パスワードに必要な数字の最小数。デフォルトは1です。

orclpwdMinAlphaChars

パスワードに必要なアルファベット文字の最小数。デフォルトは0です。

orclpwdMinSpecialChars

パスワードに必要な英数字以外の文字(特殊文字)の最小数。デフォルトは0です。

orclpwdMinUppercase

パスワードに必要な大文字の最小数。デフォルトは0です。

orclpwdMinLowercase

パスワードに必要な小文字の最小数。デフォルトは0です。

orclpwdMaxRptChars

パスワードで許可される繰返し文字の最大数。デフォルトは0です。

pwdInHistory

指定エントリのpwdHistory属性に格納される使用済パスワードの最大数。pwdHistoryに格納されたパスワードは、そこからパージされるまで、新規パスワードとして使用できません。デフォルトは0です。

pwdAllowUserChange

現在は使用されていません。

orclpwdPolicyEnable

これがTRUEの場合、サーバーはこのポリシーを評価します。そうでない場合、ポリシーは無視され、適用されません。デフォルトは1(TRUE)です。

orclpwdEncryptionEnable

TRUEに設定すると、パスワードの暗号化が有効になります。デフォルトは0(FALSE)です。

orclpwdAllowHashCompare

ハッシュ・パスワード値を使用するログインを有効または無効にします。0 = 無効(デフォルト)。1 = 有効。

orclPwdTrackLogin

ユーザーの最終ログイン時間の追跡を有効または無効にします。0=無効(デフォルト)。1=有効。

orclpwdmaxinactivitytime

アカウントが自動的に期限切れになるまでの非アクティブな時間(秒単位)。0=無効(デフォルト)。orclpwdmaxinactivitytimeがゼロ以外の場合は、属性orclPwdTrackLoginを有効にする必要があります。

第29.3.6項「コマンド行ツールを使用したOracle Internet Directoryの期限切れユーザーの判別」を参照してください。

29.1.6 パスワード・ポリシー関連の操作属性

Oracle Internet Directoryサーバーでは、ユーザー固有のパスワード・ポリシー関連情報がユーザー・エントリの操作属性に格納されます。このサーバーのみがこれらの属性を変更できます。表29-2を参照してください。

表29-2 パスワード・ポリシー関連の操作属性

属性

説明

orcllastlogintime

最後に成功したログインのタイムスタンプ。パスワード・ポリシー属性orclPwdTrackLoginが有効な場合にのみ、追跡されます。

pwdfailuretime

ログインの成功時にクリアされる、失敗したログイン試行の一連のスペース区切りのタイムスタンプ。

orclpwdipaccountlockedtime

このIPアドレスからのログインについて、アカウントがロックされた時間。これは、複数値の属性にすることができます。

orclpwdipfailuretime

ログインの成功時にクリアされる、特定のIPアドレスからの失敗したログイン試行の一連のスペース区切りのタイムスタンプ。これは、複数値の属性にすることができます。

pwdaccountlockedtime

アカウントがロックされた時間。

pwdchangedtime

最後にパスワードを変更した時間。

pwdexpirationwarned

ユーザーがパスワードの期限切れを警告された時間。

pwdgraceusetime

猶予期間中のログインのスペース区切りの一連のタイムスタンプ。

pwdreset

値が1の場合、ユーザーは次回ログイン時にパスワードをリセットする必要があります。

pwdhistory

以前に使用されたパスワードのリスト。

ユーザーが最後に成功したログイン・タイムスタンプを確認するには、ユーザーの最終ログイン時間の追跡を有効にする必要があります。つまり、関連するパスワード・ポリシーについて、PwdTrackLogin属性を1に設定する必要があります。この値は、デフォルトでは設定されません。その後、ユーザー・エントリのorcllastlogintime属性で最終ログインのタイムスタンプを確認します。

ユーザーの最後のログイン試行の時間を確認するには、ユーザーのorcllastlogintime属性とpwdfailuretimeの最後のタイムスタンプを比較します。これらの値の最新のものが、ユーザーの最後のログイン試行時間です。

29.1.7 パスワード・ポリシー情報のディレクトリ・サーバー検証

第29.1.3項「細かなパスワード・ポリシー」で説明しているように、Oracle Internet Directoryは、移入された適切なpwdPolicysubentryを見つけることで、エントリに適用可能なポリシーを判断します。ユーザー・パスワードが指定のポリシーの要件を満たしていることを確認する場合、ディレクトリ・サーバーは、次のことを検証します。

- パスワード・ポリシーが有効であること。これには、パスワード・ポリシー・エントリの属性orclpwdpolicyenableの値を確認します。値1は、パスワード・ポリシーが有効であることを示します。値0は、無効であることを示します。

- パスワード・ポリシー構文情報(英数字の数、パスワード長など)の正確さ。ディレクトリ・サーバーは、ldapaddおよびldapmodifyがuserpassword属性上で実行中に構文チェックを行います。

- パスワード・ポリシー状態情報。次に、その例を示します。

- ユーザー・パスワードが作成または変更されたときのタイムスタンプ。

- 最小パスワード有効期限は、現在の時刻からパスワード作成時刻を引いた値より大きくなります。

- ユーザーが連続してログインに失敗したときのタイムスタンプ。

- ユーザーのアカウントがロックされた日時。

- パスワードが再設定されたため、最初の認証でユーザーがパスワードを変更する必要があることを示すインジケータ。

- ユーザーが以前に使用したパスワードの履歴。

- 猶予期間ログインのタイムスタンプ。

猶予期間ログインが時間で設定されている場合、サーバーは現在の時刻と期限切れ時刻の差異をチェックします。

ディレクトリ・サーバーは、ldapbindおよびldapcompareの実行中に、状態情報をチェックしますが、このチェックは、orclpwdpolicyenable属性が1に設定されている場合にのみ実行されます。

パスワード値の構文チェックを使用可能にするには、パスワード・ポリシー・エントリのorclpwdpolicyenableおよびpwdchecksyntax属性をTRUEに設定します。

29.1.8 パスワード・ポリシーのエラー・メッセージ

パスワード・ポリシー違反が発生すると、ディレクトリ・サーバーはクライアントに様々なエラーおよび警告メッセージを送信します。Oracle Internet Directoryでは、10g(10.1.4.0.1)以降、クライアントがLDAPバインドまたは比較操作の一環としてパスワード・ポリシー・リクエスト制御を送信する場合にのみ、ディレクトリ・サーバーはこれらのメッセージをLDAP制御として送信できます。クライアントがリクエスト制御を送信しない場合、ディレクトリ・サーバーは、レスポンス制御を送信しません。かわりに、追加情報の一部としてエラーおよび警告を送信します。

関連項目:
エラー・メッセージのリストおよびそれらのエラーを解決する方法は、第R.1.6項「パスワード・ポリシーに関するトラブルシューティング」を参照してください。

29.1.9 10g(10.1.4.0.1)より前のリリース

10g(10.1.4.0.1)以前のリリースでは、パスワード・ポリシーは、レルム固有の共通エントリにあるorclcommonusersearchbase属性によって制御されていました。旧リリースからアップグレードした場合、アップグレード時に既存のパスワード・ポリシーが新規アーキテクチャに移行されています。新しいアーキテクチャでは、識別名を単純にorclcommonusersearchbaseに追加すると、レルムのデフォルトのパスワード・ポリシーが、その識別名をルートとするサブツリーに適用されることが保証されなくなります。

Oracle Internet Directory 10g(10.1.4.0.1)以降では、パスワード・ポリシーを定義すると、そのパスワード・ポリシーをそのディレクトリのサブツリーに適用するために、もう1つの手順を実行する必要があります。pwdPolicysubentry属性に希望するパスワード・ポリシーの識別名を指定して、そのポリシーの適用対象にしようと考えているサブツリーのルートであるエントリに移入します。図29-2では、これを説明しています。l=usにあるpwdPolicyには、デフォルト・ポリシーの識別名"cn=default,cn=pwdPolicies,cn=Common,cn=Products, cn=OracleContext"が含まれているため、デフォルト・ポリシーが米国内のユーザーに適用されます。l=ukにあるpwdPolicysubentryには、ポリシー"cn=policy2,cn=pwdPolicies,cn=Common,cn=Products, cn=OracleContext"の識別名が含まれているため、policy2が英国のユーザーに適用されます。

注意:
サブツリーのパスワード・ポリシー・エントリおよびユーザーはレプリケートされます。11g リリース1(11.1.1)または10g(10.1.4.0.1)のポリシーを10g(10.1.4.0.1)より前のノードにレプリケートしても、このノードの機能に悪影響を及ぼすことはありません。ただし、10g(10.1.4.0.1)より前のノードは、新しいパスワード・ポリシーを適切に解釈できません。レルムのOracleコンテキストでパスワード・ポリシーを適用し続けます。

29.2 Oracle Directory Services Managerを使用したパスワード・ポリシーの管理

Oracle Directory Services Managerを使用して、パスワード・ポリシーを作成、割当ておよび変更できます。

この項の項目は次のとおりです。

- 第29.2.1項「Oracle Directory Services Managerを使用したパスワード・ポリシーの表示」

- 第29.2.2項「Oracle Directory Services Managerを使用したパスワード・ポリシーの変更」

- 第29.2.3項「ODSMを使用したパスワード・ポリシーの作成およびサブツリーへの割当て」

29.2.1 Oracle Directory Services Managerを使用したパスワード・ポリシーの表示

1. 第7.4.5項「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動し、Oracle Internet Directoryサーバーに接続します。

2. タスク選択バーで、「セキュリティ」を選択します。

3. 左側のペインで「パスワード・ポリシー」を展開します。すべてのパスワード・ポリシーが左側のペインに相対識別名順に表示されます。完全識別名を表示するには、エントリ上にマウスを移動します。

4. パスワード・ポリシーを選択してその情報を右側のペインに表示します。

29.2.2 Oracle Directory Services Managerを使用したパスワード・ポリシーの変更

パスワード・ポリシーを変更する手順は、次のとおりです。

1. 第7.4.5項「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動し、Oracle Internet Directoryサーバーに接続します。

2. タスク選択バーで、「セキュリティ」を選択します。

3. 左側のペインで「パスワード・ポリシー」を展開します。すべてのパスワード・ポリシーが左側のペインに表示されます。

4. 変更するパスワード・ポリシーを選択します。5つのタブ・ページが、右側のペインに表示されます。

5. 必要に応じて、「一般」タブ・ページの編集可能な属性フィールドを変更します。

6. 「アカウントのロックアウト」タブ・ページを選択した後、フィールドを変更する場合は「グローバル・ロックアウト」を選択します。必要に応じて、編集可能な属性フィールドを変更します。

7. 「IPのロックアウト」タブ・ページを選択した後、フィールドを変更する場合は「IPのロックアウト」を選択します。必要に応じて、編集可能な属性フィールドを変更します。

8. 「パスワード構文」タブ・ページを選択した後、フィールドを変更する場合は「パスワード構文のチェック」を選択します。必要に応じて、編集可能な属性フィールドを変更します。

9. ポリシーを適用するサブツリーを変更するには、「有効サブツリー」タブ・ページを選択します。サブツリーを追加するには、「追加」を選択します。識別名を入力するか、「参照」を選択し、識別名(DN)パスの選択ウィンドウを使用して、ポリシーを適用するサブツリーにナビゲートします。

10. 変更終了後、「適用」を選択します。

29.2.3 ODSMを使用したパスワード・ポリシーの作成およびサブツリーへの割当て

新規のパスワード・ポリシーを作成する手順は、次のとおりです。

1. 第7.4.5項「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動し、Oracle Internet Directoryサーバーに接続します。

2. タスク選択バーで、「セキュリティ」を選択します。

3. 左側のペインで「パスワード・ポリシー」を展開します。すべてのパスワード・ポリシーが左側のペインに表示されます。

4. 新規ポリシーを作成するには、「作成」を選択します。また、左側のペインで既存のパスワード・ポリシーを選択し、「類似作成」を選択します。

5. 必要に応じて、「一般」タブ・ページの編集可能な属性フィールドを設定または変更します。

6. 「アカウントのロックアウト」タブ・ページを選択した後、フィールドを変更する場合は「グローバル・ロックアウト」を選択します。必要に応じて、編集可能な属性フィールドを変更します。

7. 「IPのロックアウト」タブ・ページを選択した後、フィールドを変更する場合は「IPのロックアウト」を選択します。必要に応じて、編集可能な属性フィールドを変更します。

8. 「パスワード構文」タブ・ページを選択した後、フィールドを変更する場合は「パスワード構文のチェック」を選択します。必要に応じて、編集可能な属性フィールドを変更します。

9. パスワード・ポリシーをサブツリーに割り当てるには、「有効サブツリー」タブ・ページを選択して、「追加」を選択します。識別名を入力するか、「参照」を選択し、識別名(DN)パスの選択ウィンドウを使用して、ポリシーを適用するサブツリーにナビゲートします。

10. 変更終了後、「適用」を選択します。

29.3 コマンド行ツールを使用したパスワード・ポリシーの管理

この項の項目は次のとおりです。

- 第29.3.1項「コマンド行ツールを使用したパスワード・ポリシーの表示」

- 第29.3.2項「コマンド行ツールを使用した新規パスワード・ポリシーの作成」

- 第29.3.3項「コマンド行ツールを使用したサブツリーへのパスワード・ポリシーの適用」

- 第29.3.4項「コマンド行ツールを使用したパスワード・ポリシーの設定」

- 第29.3.5項「コマンド行ツールを使用したパスワード・ポリシー・エントリの限定」

- 第29.3.6項「コマンド行ツールを使用したOracle Internet Directoryの期限切れユーザーの判別」

29.3.1 コマンド行ツールを使用したパスワード・ポリシーの表示

次の例では、特定のパスワード・ポリシー・コンテナの下にあるパスワード・ポリシーを取得します。

ldapsearch -p port -h host \
-b "cn=pwdPolicies,cn=common,cn=products,cn=OracleContext, \
o=my_company,dc=com" \
-s sub "(objectclass=pwdpolicy)"

次の例では、すべてのパスワード・ポリシー・エントリを取得します。

ldapsearch -p port -h host -b " " -s sub "(objectclass=pwdpolicy)"

29.3.2 コマンド行ツールを使用した新規パスワード・ポリシーの作成

新規パスワード・ポリシーを作成するには、ポリシー・エントリを適切なコンテナに追加します。これを実行するために最適な方法は、次のとおりです。

1. ldapmodifyを使用して、デフォルト・エントリcn=default,cn=pwdPolicies,cn=Common,cn=Products, cn=OracleContextの内容をLDIFファイルにダンプします。次に例を示します。

ldapsearch -p port -h host -D cn=orcladmin -q -L \
-b 'cn=default,cn=pwdPolicies,cn=Common,cn=Products, cn=OracleContext' \
-s base '(objectclass=pwdpolicy)' >> pwdpolicy.ldif

ldapsearchに代わる方法として、ldifwriteを使用できます。ORACLE_INSTANCEが設定されていることを確認してから、次を入力します。

ldifwrite connect="conn_str" \
baseDN="cn=default,cn=pwdPolicies,cn=Common,cn=Products, cn=OracleContext" \
ldiffile="pwpolicy.ldif"

2. 新規ポリシーに対して一般名および目的の値が使用されるようLDIFファイルを変更します。たとえば、cn=defaultをcn=policy1に変更し、pwdMaxFailureを10から5に変更します。

3. ldapaddを使用して新規エントリを追加します。次の形式のコマンド行を使用します。

ldapadd -p port_number -h host -D cn=orcladmin -q -f pwdpolicy.ldif

29.3.3 コマンド行ツールを使用したサブツリーへのパスワード・ポリシーの適用

新規パスワード・ポリシーをサブツリーdn: cn=accounting,c=usに適用するには、次のようなコマンド行とともに

ldapmodify -D "cn=orcladmin" -q -p port -h host -f my_file.ldif

次のようなLDIFファイルを使用します。

dn: cn=accounting,c=us
changetype: modify
replace: pwdPolicysubentry
pwdPolicysubentry:cn=policy1,cn=pwdPolicies,cn=common,cn=products,
cn=OracleContext,o=my_company,dc=com

29.3.4 コマンド行ツールを使用したパスワード・ポリシーの設定

次の例では、デフォルトのパスワード・ポリシーのpwdLockout属性を無効にします。これによって、属性はデフォルト設定の1から0に変更されます。

ファイルmy_file.ldifの内容は、次のとおりです。

dn: cn=default,cn=pwdPolicies,cn=common,cn=products,cn=OracleContext,
o=my_company,dc=com
changetype:modify
replace: pwdlockout
pwdlockout: 0

次のコマンドでこのファイルをディレクトリにロードします。

ldapmodify -D "cn=orcladmin" -q -p port -h host -f my_file.ldif

次の例では、デフォルトのパスワード・ポリシー・エントリのpwdMaxAgeを変更します。

ldapmodify -D "cn=orcladmin" -q -p port -h host -q -f file

fileには、次のものが含まれます。

dn: cn=default,cn=pwdPolicies,cn=common,cn=products,cn=OracleContext,
o=my_company,dc=com
changetype: modify
replace: pwdMaxAge
pwdMaxAge: 10000

29.3.5 コマンド行ツールを使用したパスワード・ポリシー・エントリの限定

多数のユーザーについてパスワード・ポリシーがリセットされる場合、Oracle Internet DirectoryサーバーではそのpasswordPolicySubentryキャッシュをリフレッシュする必要があり、これによってOracle Databaseに多数のSQL問合せのリクエストが発生し、パフォーマンスに影響する可能性があります。

Oracle Internet Directory 11g リリース1(11.1.1.7.0)以降では、entrylevelのサブタイプを指定することにより、パスワード・ポリシー・エントリを限定できます。たとえば、次のコマンドでは、A_userにパスワード・ポリシーが追加されます。

ldapmodify -D "cn=orcladmin" -q -p port -h host -q -f pwdpolicy.ldif

pwdpolicy.ldifの内容は次のとおりです。

dn: A_user,cn=users,dc=us,dc=mycompany,dc=com
changetype: modify
add: pwdpolicysubentry;entrylevel
pwdpolicysubentry;entrylevel: cn=pwdpolicies,dc=us,dc=mycompany,dc=com

パスワード・ポリシーはA_userにのみ適用されます。pwdpolicysubentry属性のエントリにentrylevelサブタイプがない場合、パスワード・ポリシーはサブツリー全体に適用されます。

29.3.6 コマンド行ツールを使用したOracle Internet Directoryの期限切れユーザーの判別

期限切れユーザーを判別し、そのユーザーをディレクトリから削除するなど特定のアクションを実行したい状況があります。

注意:
Oracle Internet Directoryの期限切れユーザーは、特定の属性で示されることはありません。期限切れユーザーは、システム時間、許可される最大非アクティブ時間、およびユーザーの最後の正常なログイン時間に応じて一時的な状態に置かれます。期限切れ状態は、ユーザーのバインドまたはパスワード比較操作中に判別されます。

期限切れユーザーを判別するには、Oracle Internet Directoryデプロイメントが次のように構成されている必要があります。

- 各ユーザーの最後の正常なログイン時間のトラッキングは、orclPwdTrackLogin属性を1に設定することによって有効にする必要があります。

- orclpwdmaxinactivitytime属性は0 (デフォルト)以外の値に設定する必要があります。この属性によって、ユーザーのアカウントが自動的に期限切れになるとみなされる非アクティブ時間が秒数で指定されます。

ユーザーのアカウントが期限切れであるとみなされるかどうかを判別するには、次の手順を実行します。

1. ユーザーの最後の正常なログインのタイムスタンプをorcllastlogintime属性から判別します。次に例を示します。

ldapsearch -h oid_host p oid_port -D "cn=orcladmin" -q -s base \
-b "cn=jdoe,cn=users,o=oracle" "(objectclass=*)" orcllastlogintime

2. ユーザーのorcllastlogintime値を現在のシステム時間から減算します。結果がorclpwdmaxinactivitytime値よりも大きい場合、ユーザーは期限切れ状態であるとみなされます。

3. 必要な場合は、期限切れユーザーをディレクトリから削除します。

30 ディレクトリ・アクセス制御の管理

この章では、Oracle Internet Directoryのアクセス制御ポリシーの概要について説明し、アクセス制御リスト(ACL)、アクセス制御項目(ACI)およびアクセス制御ポリシー・ポイント(ACP)の使用方法について説明します。具体的には、Oracle Directory Services Manager (ODSM)またはldapmodifyコマンド行ユーティリティを使用して、ディレクトリ・アクセス制御を管理する方法について説明します。

この章の内容は次のとおりです。

- 第30.1項「ディレクトリ・アクセス制御の管理の概要」

- 第30.2項「Oracle Directory Services Managerを使用したアクセス制御の管理」

- 第30.3項「コマンド行ツールを使用したアクセス制御の管理」

関連項目:

- アクセス制御ポリシーの実装と管理を開始する前に理解しておく必要がある概要については、第3.7項「セキュリティ」および第33章「認証の管理」を参照してください。

- アクセス制御情報項目(ACI)の書式または構文の詳細は、付録H「アクセス制御ディレクティブ書式」を参照してください。

30.1 ディレクトリ・アクセス制御の管理の概要

認可とは、オブジェクトまたはオブジェクトのセットへのアクセスのためにユーザー、プログラムまたはプロセスに与えられる権限です。ディレクトリ・セッション中にディレクトリ操作が試行されると、ディレクトリ・サーバーによって、ユーザーにこれらの操作を実行するための権限があるかどうかが確認されます。ユーザーに権限がない場合、ディレクトリ・サーバーはこれらの操作を許可しません。ディレクトリ・サーバーはアクセス制御情報を使用して、ディレクトリ・ユーザーによる不正操作からディレクトリ・データを保護します。

アクセス制御情報は、アクセス制御に関連する管理ポリシーを記録したディレクトリ・メタデータです。この情報は、ユーザーによる変更が可能な構成属性としてOracle Internet Directoryに格納され、アクセス制御項目(ACI)と呼ばれます。

通常、アクセス制御リスト(ACL)と呼ばれるこのACI属性値のリストは、ディレクトリ・オブジェクトと関連付けられています。このリストの属性値は、様々なディレクトリ・ユーザー・エンティティ(サブジェクト)が各オブジェクトに対して所有している権限を表しています。

ACIは次のコンポーネントで構成されています。

- アクセス権限を付与するオブジェクト

- アクセス権限を付与するエンティティ(サブジェクト)

- 付与するアクセス権限の種類

アクセス制御ポリシーは規定的です。つまり、そのセキュリティ・ディレクティブは、ディレクトリ情報ツリー(DIT)内のすべての下位エントリに適用されるように設定できます。アクセス制御ポリシーが適用される開始点は、アクセス制御ポリシー・ポイント(ACP)と呼ばれます。

ACIは、ディレクトリ内にテキスト文字列として記述され、格納されています。この文字列は、ACIディレクティブ書式と呼ばれる、明確に定義された書式に従う必要があります。ACI属性の各有効値は、個別のアクセス制御ポリシーを表します。

ホスティングされた環境で実行されているアプリケーションでは、ディレクトリ・アクセス制御の次の機能が使用できます。

- 規定のアクセス制御
サービス・プロバイダは、ディレクトリ・オブジェクトの集合に対してアクセス制御リスト(ACL)を指定できます。個々のオブジェクトごとにポリシーを設定する必要はありませんこの機能によって、アクセス制御の管理が簡素化されます。特に同じポリシーまたは同等のポリシーで管理されるオブジェクトが多数含まれる大きなディレクトリで有効です。

- 階層的なアクセス制御管理のモデル
サービス・プロバイダは、ホスティングされた企業にディレクトリ管理を委任できます。必要に応じて、レルムからさらに委任することもできます。

- 委任ドメインに対する管理無効制御
サービス・プロバイダは、アカウントの意図しないロックアウトやセキュリティの不慮の露見に対する診断とリカバリを実行できます。

- アクセス制御エンティティの動的評価
サブツリーの管理者は、サブジェクトとオブジェクトの双方を、そのネームスペースおよびディレクトリのその他のオブジェクトとの関連の点で識別できます。たとえば、あるレルムの管理者は、ユーザーの上司のみに、そのユーザーの給与属性の更新を認めることができます。他のレルムの管理者は、給与属性に関して、これと異なるポリシーを確立して適用できます。

アクセス制御ポリシーは、対応するエントリ内のACI属性の値を構成して管理します。そのためには、Oracle Directory Services Managerまたはldapmodifyのいずれかを使用します。

この項の項目は次のとおりです。

- 第30.1.1項「アクセス制御管理の構造体」

- 第30.1.2項「アクセス制御情報のコンポーネント」

- 第30.1.3項「LDAP操作のアクセス・レベル要件」

30.1.1 アクセス制御管理の構造体

この項では、Oracle Internet Directoryでアクセス制御に使用される構造について説明します。次のポリシーが含まれます。

- アクセス制御ポリシー・ポイント(ACP)

- 規定のアクセス制御のためのorclACI属性

- エントリ・レベルのアクセス制御のためのorclEntryLevelACI属性

- 権限グループ

30.1.1.1 アクセス制御ポリシー・ポイント(ACP)

ACPは、orclACI属性に値が指定されたエントリです。orclACI属性の値は、エントリのサブツリーによって継承されるアクセス・ポリシーを示します。エントリのサブツリーは、そのサブツリーのルートとなるACPから始まります。

ディレクトリ・サブツリー内に複数のACPの階層が存在する場合、そのサブツリー内の従属エントリは、すべての上位ACPからアクセス・ポリシーを継承します。継承結果のポリシーは、そのエントリより上位のACP階層内のポリシーを集約したものです。

たとえば、HR部門のエントリにACPが設定されており、HR部門内に、Benefits、PayrollおよびInsuranceグループのエントリがある場合、この3つのグループ内のエントリはいずれも、HR部門のエントリに指定されたアクセス権を継承します。

ACPの階層内に競合するポリシーがある場合、ディレクトリは、集約したポリシーの評価には明確に定義された優先順位規則を適用します。

関連項目:
第30.1.4項「ACL評価の動作」

30.1.1.2 規定のアクセス制御のためのorclACI属性

orclACI属性には、規定のアクセス制御リスト(ACL)ディレクティブが含まれています。つまり、このディレクティブは、この属性が定義されているACPより下位のサブツリー内にあるすべてのエントリに適用されます。ディレクトリ内のあらゆるエントリに、この属性の値を含めることができます。この属性自体へのアクセスは、他の属性に対するアクセスと同様に制御されます。

注意:
単一のエントリ固有のACLディレクティブをorclACI属性で示すことができます。ただし、このようなシナリオでは管理の利便性およびパフォーマンス上の利点から、orclEntryLevelACI (第30.1.1.3項「エントリ・レベルのアクセス制御のためのorclEntryLevelACI属性」を参照)を使用することをお薦めします。これは、orclACIを介して表されるディレクティブの数とともに、LDAP構成のオーバーヘッドが増加することが理由です。エントリ固有のディレクティブをorclACIからorclEntryLevelACIに移動すると、このオーバーヘッドを削減できます。

30.1.1.3 エントリ・レベルのアクセス制御のためのorclEntryLevelACI属性

あるポリシーが特定のエンティティ(例: 特別のユーザー)のみに関係するとき、そのエンティティのエントリ内でACLディレクティブをメンテナンスできます。これは、orclEntryLevelACIと呼ばれるユーザーが変更可能な構成属性を使用して実行できます。この属性には、関連付けられたエントリにのみ適用されるACLディレクティブが含まれます。

いずれのディレクトリ・エントリにも、この属性の値をオプションで設定できます。それは、Oracle Internet Directoryが抽象型オブジェクト・クラスtopを拡張し、オプション属性としてorclEntryLevelACIを組み込むためです。

orclEntryLevelACI属性は複数値の属性で、構造はorclACIと類似しています。

関連項目:
orclEntryLevelACI属性の構造については、「オブジェクト: アクセス権を付与するオブジェクト」を参照してください。

30.1.1.4 セキュリティ・グループ

Oracle Internet Directory内のグループ・エントリは、groupOfNamesオブジェクト・クラスまたはgroupOfUniqueNamesオブジェクト・クラスのいずれかと関連付けられます。グループ内のメンバーシップは、それぞれmember属性またはuniqueMember属性の値として指定されます。

個人またはエンティティのグループにアクセス権を指定するには、セキュリティ・グループでそのグループを識別します。セキュリティ・グループには、ACPグループと権限グループの2つのタイプがあります。

30.1.1.4.1 ACPグループ

個人がACPグループのメンバーである場合、ディレクトリ・サーバーは、そのACPグループに関連付けられている権限をその個人に単純に付与します。

ACPグループを使用して、ACPのレベルでアクセス権を解決します。たとえば、エントリを参照できるアクセス権を数百ものユーザーに付与すると仮定します。参照権限を各エントリに個別に付与することもできますが、この作業には相当な管理オーバーヘッドが必要となります。さらに、後日その権限の変更が決定した場合は、各エントリを個々に修正する必要があります。より効率的な解決策は、権限を集合的に割り当てることです。そのためには、グループ・エントリを作成してACPグループとして指定し、必要な権限をそのグループに割り当てた後、ユーザーをそのグループのメンバーに割り当てます。その後、アクセス権を変更する場合は、個々のユーザーに対してではなく、グループに対して1箇所で変更を行います。同様に、権限を削除する場合は、多数の各エントリにアクセスするのではなく、グループから権限を削除することによって、複数のユーザーから権限を削除できます。

ACPグループは、orclacpgroupオブジェクト・クラスに関連付けられています。

30.1.1.4.2 権限グループ

権限グループは、上位レベルのアクセス・グループです。同様の権限を持つユーザーをリストする点では、ACPグループと類似しています。ただし、単一のACPとは異なり追加チェックも提供しています。たとえば、あるACPによってアクセスが否認される場合、ディレクトリ・サーバーは、アクセスを否認されたユーザーがいずれかの権限グループに属しているかどうかをユーザー・エントリの属性によって判断します。その場合、このユーザーには上位管理レベルで別途の権限があるため、DITで上位管理レベルすべてがチェックされます。リクエストしたオブジェクトへのアクセス権を権限グループに付与する上位ACPが見つかった場合、ディレクトリ・サーバーは、従属ACPによる否認を無視してアクセス権をユーザーに付与します。ただし、従属ACPのorclACIまたはorclEntryLevelACI属性にキーワードDenyGroupOverrideが含まれている場合、上位レベルのACPは従属ACPを無視しません。DenyGroupOverrideを使用すると、権限グループを使用してスーパーユーザーのアクセスを制限できます。

通常は、ACPグループのみを実装します。権限グループが提供する追加チェックは、パフォーマンスを低下させる可能性があります。下位レベルの標準的な制御よりも上位レベルのアクセス制御を優先させる権限が必要な場合にのみ、権限グループを使用します。

権限グループを使用して、DITの下位ACPでは認識されない管理者に対して、アクセス権を付与します。たとえば、ホスティングされた環境のグローバル管理者が、レルムで操作を行う必要があると仮定します。グローバル管理者のアイデンティティはホスティングされた企業のレルムでは認識されないため、ディレクトリ・サーバーは、そのレルムのACPのみに依存している場合、必要なアクセスを拒否します。ただし、グローバル管理者が権限グループのメンバーである場合、ディレクトリ・サーバーは、DITの上位で、そのサブツリーへのアクセス権をこの権限グループに付与しているACPを検索します。アクセス権を付与しているACPが見つかった場合、ディレクトリ・サーバーは、ホスティングされた企業のレルムにあるACPによる制限を無視します。

DenyGroupOverrideキーワードをACIに追加すると、権限が付与されたグループのメンバーに対してアクセスを拒否できます。

権限グループは、orclPrivilegeGroupオブジェクト・クラスに関連付けられています。

30.1.1.4.3 両方のタイプのグループに属するユーザー

ユーザーがACPグループと権限グループの両方のメンバーである場合、ディレクトリ・サーバーは、各タイプのグループについて評価を行います。DITで上位のACPに注目して、権限グループのアクセス権を解決します。

30.1.1.4.4 セキュリティ・グループの制約

orclacpgroupオブジェクト・クラスとorclPrivilegeGroupオブジェクト・クラスの両方を含むセキュリティ・グループは作成しないでください。

ネストされているセキュリティ・グループの親グループと子グループは、常に同じオブジェクト・クラス(orclacpgroupまたはorclPrivilegeGroup)である必要があります。

これらの制約のいずれかに違反すると、ACIの評価が決定的ではなくなる可能性があります。

30.1.1.4.5 概要: グループへのアクセス権の付与

アクセス権をユーザーのグループに付与する手順は、次のとおりです。

1. 通常の方法でグループ・エントリを作成します。

2. グループ・エントリをorclPrivilegeGroupオブジェクト・クラスまたはorclACPgroupオブジェクト・クラスに関連付けます。

3. そのグループのアクセス・ポリシーを指定します。

4. メンバーをグループに割り当てます。

30.1.1.4.6 ディレクトリ・サーバーによるセキュリティ・グループ・メンバーシップの算出方法

エントリは、グループの直接のメンバーとなるか、またはグループをネストして権限グループの一群を形成し、他のACPまたは権限グループの間接のメンバーとなることができます。与えられたレベルで指定されているアクセス・ポリシーは、そのレベル以下のすべてのメンバーに直接的または間接的に適用されます。

Oracle Internet Directoryは、セキュリティ・グループのみをアクセス制御目的で評価するため、その他のタイプのグループに対してアクセス・ポリシーを設定できません。ユーザーが特定の識別名とバインドされると、Oracle Internet Directoryは、セキュリティ・グループ内でそのユーザーの直接のメンバーシップを算出します。指定した識別名の第1レベルのグループを認識すると、Oracle Internet Directoryは、この第1レベルのグループすべての、他のセキュリティ・グループへのネストを算出します。この処理は、評価対象のネストされたグループがなくなるまで行われます。

各セキュリティ・グループ(ネストされているかどうかに関係なく)は、セキュリティ・グループのオブジェクト・クラス(orclACPgroupまたはorclPrivilegeGroup)に関連付けられている必要があります。グループがセキュリティ・グループのメンバーの場合でも、セキュリティ・グループのオブジェクト・クラスに関連付けられていないかぎり、ディレクトリ・サーバーではアクセス制御目的のグループとはみなされません。セキュリティ・グループ内でユーザーのメンバーシップが判断された場合、ディレクトリ・サーバーでは、セッションの存続期間にわたってその情報を使用します。

30.1.1.4.7 例: セキュリティ・グループ・メンバーシップの算出

たとえば、表30-1のエントリのサンプル・グループについて考えてみます。group4以外は、それぞれ権限グループ(objectclass:orclprivilegegroup)として指定されています。group1、group2およびgroup3のメンバーに適用されるアクセス制御ポリシーを設定できます。

表30-1 サンプル・セキュリティ・グループ

グループ

エントリ

group 1

dn: cn=group1,c=us
cn: group1
objectclass: top
objectclass: groupofUniqueNames
objectclass: orclPrivilegeGroup
uniquemember: cn=mary smith,c=us
uniquemember: cn=bill smith,c=us
uniquemember: cn=john smith,c=us

group 2

dn: cn=group2,c=us
cn: group2
objectclass: top
objectclass: groupofUniqueNames
objectclass: orclPrivilegeGroup
uniquemember: cn=mary jones,c=us
uniquemember: cn=joe jones,c=us
uniquemember: cn=bill jones,c=us
uniquemember: cn=john smith,c=us

group 3

dn:cn=group3,c=us
cn: group3
objectclass: top
objectclass: groupofUniqueNames
objectclass: orclPrivilegeGroup
uniquemember: cn=group2,c=us
uniquemember: cn=group1,c=us
uniquemember: cn=group4,c=us

group 4

dn: cn=group4,c=us
cn: group4
objectclass: top
objectclass: groupofUniqueNames
uniquemember: cn=john doe,c=uk
uniquemember: cn=jane doe,c=uk
uniquemember: cn=anne smith,c=us

group 3には、次のネストされたグループが含まれています。

- cn=group2,c=us

- cn=group1,c=us

- cn=group4,c=us

group3のアクセス制御ポリシーは、group3、group1およびgroup2のメンバーに適用されます。これは、各グループが権限グループとしてマークされているためです。この同じアクセス制御ポリシーは、group4のメンバーには適用されません。これは、group4は権限グループとしてマークされていないためです。

たとえば、ユーザーが識別名cn=john doe,c=ukでgroup4のメンバーとしてOracle Internet Directoryにバインドされている場合を考えてみます。group3のメンバーに適用されるアクセス・ポリシーがこのユーザーに適用されることはありません。これは、このユーザーの唯一の直接メンバーシップが非権限グループに対するものであるためです。これに対して、ユーザーがcn=john smith,c=us、つまり、group1とgroup2のメンバーとしてバインドされている場合、そのアクセス権はgroup1、group2およびgroup3(group1とgroup2がネストされているため)のメンバーに対して設定されているアクセス・ポリシーで管理されます。これは、この3つのグループすべてがオブジェクト・クラスorclPrivilegeGroupと関連付けられているためです。

関連項目:
グループ・エントリを変更して、orclPrivilegeGroupまたはorclACPgroupオブジェクト・クラスと関連付ける方法または関連付けを解除する方法は、第14.2項「Oracle Directory Services Managerを使用したグループ・エントリの管理」または第14.3項「コマンド行を使用したグループ・エントリの管理」を参照してください。

30.1.2 アクセス制御情報のコンポーネント

アクセス制御情報とは、様々なエンティティまたはサブジェクトがディレクトリ内の指定されたオブジェクトに対して操作を行う必要がある権限を表します。したがって、ACIは次の3つのコンポーネントで構成されています。

- アクセス権限を付与するオブジェクト

- アクセス権限を付与するエンティティ(サブジェクト)

- 付与するアクセス権限の種類

30.1.2.1 オブジェクト: アクセス権を付与するオブジェクト

アクセス制御ディレクティブのオブジェクト部分により、そのアクセス制御が適用されるエントリおよび属性が決まります。エントリまたは属性のいずれかに適用できます。

ACIに関連付けられているエントリ・オブジェクトは、ACI自体が定義されているエントリまたはサブツリーによって暗黙的に識別されます。属性のレベルにおけるその他の条件は、ACL式で明示的に指定されます。

orclACI属性においては、ACIのオブジェクトのエントリ識別名コンポーネントは、暗黙的に、最上位のエントリのACPから始まるサブツリー内のエントリすべての識別名コンポーネントです。たとえば、dc=comがACPの場合、そのACIで管理されるディレクトリ領域は次のようになります。

.*, dc=com.

ただし、ディレクトリ領域は暗黙的であるため、この識別名コンポーネントは不要で、構文的にも許可されません。

orclEntryLevelACI属性においては、ACLのオブジェクトのエントリ識別名コンポーネントは、暗黙的にエントリ自体の識別名コンポーネントです。たとえば、dc=example,dc=comにエントリ・レベルのACIが関連付けられている場合、そのACIが管理しているエントリはdc=example,dc=com自体です。ただし、これは暗黙的であるため、この識別名コンポーネントは不要で、構文的にも許可されません。

ACLのオブジェクト部分は、次のようにエントリ内の属性と一致させるフィルタによって、エントリをオプションで限定できます。

filter=(ldapFilter)

ldapFilterは、LDAP検索フィルタの文字列を表しています。特別なエントリ・セレクタ*は、全エントリの指定に使用されます。

エントリ内の属性をポリシーに組み込むには、次のようにカンマで区切られた属性名のリストをオブジェクト・セレクタに組み込みます。

attr=(attribute_list)

エントリ内の属性をポリシーから除外するには、次のようにカンマで区切られた属性名のリストをオブジェクト・セレクタに組み込みます。

attr!=(attribute_list)

アクセス制御ディレクティブのオブジェクト部分には、特別なキーワードが含まれている場合もあります。これらのツールは、次のとおりです。

- DenyGroupOverride(上位レベルのACPによるアクセス権の無視を防止)

- AppendToAll(評価時にACIのサブジェクトをそのACP内の他のすべてのACIに追加)

注意:
エントリ自体に対するアクセス権は、特別なオブジェクト・キーワードENTRYを使用して、付与または否認する必要があります。属性に対してアクセス権を付与するのみでは不十分で、ENTRYキーワードを指定してエントリ自体にアクセス権を付与する必要があることに注意してください。

関連項目:
ACIの書式または構文の詳細は、付録H「アクセス制御ディレクティブ書式」を参照してください。

30.1.2.2 サブジェクト: アクセス権を付与する対象

この項では、次の項目について説明します。

- アクセス権が付与されるエンティティ

- バインド・モード(そのエンティティのアイデンティティの検証に使用される認証モード)

- バインドIPフィルタ(そのエンティティのアイデンティティの検証に使用されるIPアドレス・フィルタ)

- オブジェクト追加制約(アクセス権を付与されたユーザーが、親の下に追加できるオブジェクトの種類の制限)

30.1.2.2.1 エンティティ

アクセス権は、エントリではなくエンティティに対して付与されます。エンティティ・コンポーネントは、アクセス権が付与されているエンティティを指定します。

直接または間接的にエンティティを指定できます。

エンティティの直接指定: この方法は、実際のエンティティ値の入力(たとえば、group=managers)を必要とします。次の要素を使用して値を入力します。

- 任意のエントリと一致するワイルド・カード文字(*)

- アクセス権によって保護されているエントリと一致するキーワードSELF

- ディレクトリで指定されているSuperUser識別名と一致するキーワードSuperUser

- エントリの識別名と一致する正規表現(たとえば、dn=regex)

- 権限グループ・オブジェクトのメンバー(group=dn)

エンティティの間接指定: これはエンティティを動的に指定する方法です。アクセス権を付与しているエントリの一部である識別名値属性を指定する必要があります。識別名値属性には次の3つのタイプがあります。

- dnattr: この属性を使用して、このエントリに対してアクセス権を付与または制限しているエンティティの識別名を指定します。

- groupattr: この属性を使用して、このエントリに対してアクセス権を付与または制限している管理グループの識別名を指定します。

- guidattr: この属性を使用して、このエントリに対してアクセス権を付与または制限するエントリのグローバル・ユーザー識別子(orclGUID)を指定します。

たとえば、Anne Smithのマネージャが彼女のエントリで給与属性を変更できるように指定する場合を想定します。マネージャの識別名を直接指定するかわりに、識別名値属性を指定します(dnattr=manager)。次に、John DoeがAnneの給与属性を変更しようとすると、ディレクトリ・サーバーでは次の処理が実行されます。

1. 彼女のmanager属性の値を参照し、John Doeであることを確認します。

2. バインド識別名とmanager属性が一致することを確認します。

3. 適切なアクセス権をJohn Doeに付与します。

30.1.2.2.2 バインド・モード

バインド・モードは、サブジェクトが使用する認証と暗号化の方法を指定します。

認証には、次の4つのモードがあります。

- MD5ダイジェスト

- PKCS12

- プロキシ

- 簡易: パスワードベースの簡易認証

暗号化には、次の3つのオプションがあります。

- SASL

- SSL認証なし

- SSL一方向

暗号化モードの指定はオプションです。未指定の場合は、選択した認証モードがPKCS12でないかぎり暗号化は使用されません。PKCS12を使用して送信したデータは、すべて暗号化されます。

認証の選択肢には次のような優先順位規則があります。

匿名<プロキシ<簡易<MD5ダイジェスト<PKCS12

この規則は次のことを意味します。

- プロキシ認証は、匿名アクセスをブロックします。

- 簡易認証は、プロキシおよび匿名アクセスの両方をブロックします。

- MD5ダイジェスト認証は、簡易、プロキシおよび匿名アクセスをブロックします。

- PKCS12認証は、MD5ダイジェスト、簡易、プロキシおよび匿名アクセスをブロックします。

バインド・モードの構文は次のとおりです。

BINDMODE =(LDAP_AUTHENTICATION_CHOICE + [ LDAP_ENCRYPTION_CHOICE ] )
LDAP_AUTHENTICATION_CHOICE = Proxy | Simple | MD5Digest | PKCS12
LDAP_ENCRYPTION_CHOICE = SSLNoAuth | SSLOneway | SASL

LDAP_ENCRYPTION_CHOICEパラメータはオプションです。未指定の場合、ディレクトリ・サーバーでは、暗号化は使用されないとみなされます。

30.1.2.2.3 バインドIPフィルタ

標準LDAPフィルタを使用してorclipaddress属性で定義した、サブジェクトのIPアドレスまたはIPアドレス範囲です。サブジェクトのIPアドレスが定義したフィルタに一致すると、そのフィルタが定義されているACIが操作に適用できるようになります。

バインドIPフィルタの構文は次のとおりです。

BINDIPFILTER =(LDAPFILTER_FOR_ORCLIPADDRESS)

次に例を示します。

フィルタ(|(orclipaddress=1.2.3.*)(orclipaddress=1.2.4.*))は、サブジェクトのIPアドレスが1.2.3で始まるか、または1.2.4で始まる場合に適用されます。

フィルタ(&(orclipaddress!=1.2.*)(orclipaddress!=3.4.*))は、サブジェクトのIPアドレスが1.2で始まらない場合、および3.4で始まらない場合に適用されます。

30.1.2.2.4 オブジェクト追加制約

親エントリに追加アクセス権がある場合、階層内の下位エントリとしてオブジェクトを追加できます。オブジェクト追加制約は、ldapfilterを指定することによって、追加アクセス権を制限するために使用できます。

関連項目:
付録H「アクセス制御ディレクティブ書式」および付録G「LDAPフィルタ定義」

30.1.2.3 操作: 付与するアクセス権の種類

付与するアクセス権の種類は次のいずれかです。

- なし

- Compare/nocompare

- Search/nosearch

- Read/noread

- Selfwrite/noselfwrite

- Write/nowrite

- Add/noadd

- Proxy/noproxy

- Browse/nobrowse

- Delete/nodelete

各アクセス・レベルを個々に付与または否認できることに注意してください。noxxxという記述は、xxx権限が否認されていることを意味します。

エントリに関連付けられているアクセス権と、属性に関連付けられているアクセス権があることにも注意してください。

表30-2 アクセスのタイプ

アクセス・レベル

説明

オブジェクトのタイプ

比較

属性値で比較操作を実行する権限。

属性

読取り

属性値を読み取る権限。属性に対して読取り権限が与えられている場合でも、エントリ自体に参照権限がないかぎり値は返されません。

属性

検索

検索フィルタで属性を使用する権限。

属性

自己書込み

識別名のグループ・エントリ属性のリスト内で、ユーザー自身の追加/削除あるいは自身のエントリの変更を行う権限。メンバーがリスト上の自分自身をメンテナンスできます。たとえば、次のコマンドを実行すると、グループ内のユーザーがmember属性上で、自分自身の識別名のみを追加または削除できます。

access to attr=(member) by dnattr=(member) (selfwrite)

dnattrセレクタは、member属性にリストされているエンティティにアクセス権が適用されるように指定します。selfwriteアクセス権セレクタは、そのメンバーが、属性上で自分自身の識別名のみを追加または削除できるように指定します。

属性

書込み

エントリの属性を変更/追加/削除する権限。

属性

なし

アクセス権なし。サブジェクトとオブジェクトの組合せにアクセス権を付与しない場合、サブジェクトにとってオブジェクトがそのディレクトリに存在しないかのように見えるという効果があります。

エントリおよび属性

追加

ターゲットのディレクトリ・エントリの下にエントリを追加する権限。

エントリ

プロキシ

別のユーザーの代理となる許可。

エントリ

参照

検索結果で識別名を返すための権限。X.500のリスト権限と同等です。この権限は、クライアントがエントリの識別名をldapsearch操作でベース識別名として使用するときにも必要です。

エントリ

削除

ターゲットのエントリを削除する権限。

エントリ

エントリ・レベルのアクセス・ディレクティブは、オブジェクト・コンポーネント内のキーワードENTRYで識別されます。

注意:
デフォルトのアクセス制御ポリシーでは、エントリおよび属性の両方を対象に、すべての人に、エントリ内のすべての属性の読取り、検索、書込みおよび比較の各アクセス権が付与されており、自己書込み権限は未指定です。エントリが未指定の場合、アクセス権は、そのアクセス権が指定されている直近の上位レベルで判断されます。

30.1.3 LDAP操作のアクセス・レベル要件

表30-3に、LDAP操作と、各操作の実行に必要なアクセス権を示します。

表30-3 LDAP操作および各操作の実行に必要なアクセス権

操作

必要なアクセス権

オブジェクトの作成

親エントリに対する追加アクセス権

変更

変更対象の属性に対する書込みアクセス権

識別名の変更

現行の親に対する削除アクセス権と新しい親に対する追加アクセス権

相対識別名の変更

ネーミング属性すなわち相対識別名属性に対する書込みアクセス権

オブジェクトの削除

削除対象のオブジェクトに対する削除アクセス権

比較

属性に対する比較アクセス権とエントリに対する参照アクセス権

検索

- フィルタ属性での検索アクセス権およびエントリでの参照アクセス権(エントリ識別名が結果として返される必要がある場合)

- フィルタ属性での検索アクセス権、エントリでの参照アクセス権および属性での読取り権(その値が結果として返される必要があるすべての属性について)

30.1.4 ACL評価の動作

ユーザーが指定されたオブジェクトで操作を実行しようとすると、ディレクトリ・サーバーは、そのオブジェクト上で操作を実行するための適切なアクセス権がユーザーにあるかどうかを判断します。オブジェクトがエントリの場合、ディレクトリ・サーバーは、エントリおよびその各属性に対するアクセス権を系統的に評価します。

オブジェクト(エントリの属性も含む)へのアクセス権の評価は、そのオブジェクトのACIディレクティブすべての検証を必要とする場合があります。これは、ACPに階層的な特性があり、上位ACPから従属ACPにポリシーが継承されるためです。

ディレクトリ・サーバーは、最初にエントリ・レベルACI(orclEntryLevelACI)のACIディレクティブを検証します。最も近いACPに進み、評価が完了するまで各上位ACPを次々に検討します。

ACLの評価時には、属性は表30-4に示すいずれかの状態になります。

表30-4 ACL評価時の属性の状態

状態

説明

権限による解決

属性に対して要求されたアクセスは、ACIで付与されています。

否認による解決

属性に対して要求されたアクセスは、ACIで明示的に否認されています。

未解決

対象の属性に対して、適用可能なACIがまだ見つかりません。

検索を除き、次の場合にはすべての操作の評価が停止します。

- エントリ自体に対するアクセス権が否認される。

- 属性のいずれかが「否認による解決」の状態になる。

この場合、操作は失敗し、ディレクトリ・サーバーはエラーをクライアントに返します。

検索操作の場合は、すべての属性が「Resolved」の状態になるまで評価が続けられます。「否認による解決」の属性は返されません。

この項の項目は次のとおりです。

- 第30.1.4.1項「ACLの評価に使用される優先順位規則」

- 第30.1.4.2項「同一オブジェクトに対する複数ACIの使用」

- 第30.1.4.3項「ディレクトリ・オブジェクトに対する排他的アクセス権」

- 第30.1.4.4項「グループの場合のACL評価」

30.1.4.1 ACLの評価に使用される優先順位規則

LDAPの操作では、LDAPセッションのBindDN(つまりサブジェクト)に、そのオブジェクト(エントリ自体およびエントリの個々の属性を含む)で操作を実行するための特定の権限が必要です。

通常は、アクセス制御の管理認可の階層があり、ネーミング・コンテキストのルートから、継承する管理ポイント(またはアクセス制御ポリシー・ポイント)までが1つの階層になります。ACPは、orclACI属性の定義済の値を持つ任意のエントリです。また、単一のエントリ固有のアクセス情報をそのエントリ(orclEntryLevelACI)内で示すこともできます。

ACLの評価には、LDAP操作の実行に必要な権限がサブジェクトにあるかどうかを判別する処理が含まれています。通常、orclentryLevelACIまたはorclACIには、ACLの評価に必要な情報がすべて含まれているわけではありません。したがって、評価が完全に解決されるまで、使用可能なすべてのACL情報が、一定の順序で処理されます。

処理の順序は次の規則に従います。

- エントリ・レベルのACIが最初に検証されます。orclACIのACIは、そのターゲット・エントリに一番近いACPから順に上位方向に検証されます。

- 必要な権限が判別された時点で、評価は停止します。それ以外は評価が継続されます。

- 単一のACI内では、セッションの識別名と関連付けられているエンティティが、by句で識別される複数の項目と一致している場合、有効なアクセス権が次のように評価されます。

- 一致するby句の項目内で付与された全権限のUNION
次の場合のAND検索

- 一致するby句の項目内で否認された全権限のUNION

30.1.4.1.1 エントリ・レベルにおける優先順位

エントリ・レベルにおけるACIは、次の順序で評価されます。

1. フィルタを使用している場合。次に例を示します。

access to entry filter=(cn=p*)

by group1 (browse, add, delete)

2. フィルタを使用していない場合。次に例を示します。

access to entry

by group1 (browse, add, delete)

30.1.4.1.2 属性レベルにおける優先順位

属性レベルにおいては、属性が指定されているACIが未指定のACIよりも優先されます。

1. 属性が指定されているACIは、次の順序で評価されます。

1. フィルタを使用しているもの。次に例を示します。

access to attr=(salary) filter=(salary > 10000)
by group1 (read)

2. フィルタを使用していないもの。次に例を示します。

access to attr=(salary)
by group1 (search, read)

2. 属性が未指定のACIは、次の順序で評価されます。

1. フィルタを使用している場合。次に例を示します。

access to attr=(*) filter (cn=p*)
by group1 (read, write)

2. フィルタを使用していない場合。次に例を示します。

access to attr=(*)
by group1 (read, write)

30.1.4.2 同一オブジェクトに対する複数ACIの使用

Oracle Internet Directoryでは、オブジェクトのACP内に複数のACIを定義できます。オブジェクトに関連付けられているACIを処理して、内部ACPキャッシュ内に単一ACIとして格納します。その後、ACP内に指定された複数のACIのすべての関連ポリシーを適用します。

この動作については、次のACPの例を参照してください。

Access to entry by dn="cn=john" (browse,noadd,nodelete)
Access to entry by group="cn=admingroup" (browse,add,nodelete)
Access to entry by dn=".*,c=us" (browse,noadd,nodelete)

このACPには、オブジェクト・エントリに対する3つのACIがあります。このACPをロードする場合、Oracle Internet Directoryは、内部ACPキャッシュ内でこの3つのACIを1つのACIとしてマージします。

ACIの構文は次のとおりです。

Access to OBJECT> by SUBJECT ACCESSLIST
OBJECT = [ entry | attr [EQ-OR-NEQ] ( * | ATTRLIST ) ]
[ filter = ( LDAFILTER ) ]

この構文は、次のオブジェクトのタイプを可能にします。

- entry

- Entry + filter = (LDAPFILTER)

- Attr = (ATTRLIST)

- Attr = (ATTRLIST) + filter = (LDAPFILTER)

- Attr!= (ATTRLIST)

- Attr!= (ATTRLIST) + filter = (LDAPFILTER)

- Attr = (*)

- Attr = (*) + filter = (LDAPFILTER)

前述のすべてのオブジェクトのタイプに対して、複数のACIを定義できます。ACPの初期ロード時に、ディレクトリ・サーバーは、定義されたオブジェクト・タイプに基づいてACIをマージします。ACI内のオブジェクト文字列が完全一致の文字列かどうかを比較することが、一致基準となります。

1つのACIでATTR=(ATTRLIST)が指定され、別のATTR!=(ATTRLIST)が指定されている場合、ATTR=(*)はエントリ内でACIとしては指定できません。また、ACIでATTR=(ATTRLIST)が指定されている場合に、ATTRLISTにはない属性に対するアクセス権限を指定するには、ATTR!=(ATTRLIST)ではなく、ATTR=(*)を指定する必要があります。ATTR=(*)は、ATTRLISTで指定されている属性以外のすべての属性を示します。

注意:
同じ属性に対して同じフィルタを使用して複数のACIを定義する場合、Oracle Internet Directoryはそれらをマージし、実行時の構造として単一のACIを作成します。
同じ属性に対して異なるフィルタを使用して複数のACIを定義する場合、Oracle Internet Directoryではそれらを個別のACIとして処理します。このような場合、優先順位は決定的ではありません。

あいまいな動作を防ぐには、同じ属性に対して異なるフィルタを使用して複数のACIを定義する場合、フィルタにより重複する結果が生じないようにしてください。

30.1.4.3 ディレクトリ・オブジェクトに対する排他的アクセス権

指定したオブジェクトにACIが存在している場合は、そのオブジェクト以外のすべてのオブジェクトに対してアクセス権を指定できます。そのためには、アクセス権をすべてのオブジェクトに付与するか、または1つのオブジェクトに対するアクセス権を否認します。

次の例は、アクセス権をすべての属性に付与します。

access to attr=(*)
by group2 (read)

次の例は、userpassword属性に対するアクセス権を否認します。

access to attr!=(userpassword)
by group2 (read)

30.1.4.4 グループの場合のACL評価

属性またはエントリ自体の操作が、DIT内の下位のACPで明示的に否認されている場合、通常、ACLによるそのオブジェクトの評価は、否認による解決とみなされます。ただし、そのセッションのユーザー(bindDN)がグループ・オブジェクトのメンバーの場合、評価はまだ解決されていないかのように継続されます。グループのサブジェクト・セレクタを介して、ツリー内の上位のACPでセッションのユーザーに権限が付与されている場合、この権限付与はDIT内の下位での否認よりも優先されます。

この例は、上位レベルのACPのACLポリシーが、DIT内の下位のACPポリシーよりも優先される唯一のケースです。

30.2 Oracle Directory Services Managerを使用したアクセス制御の管理

ACP内のアクセス制御情報は、Oracle Directory Services Managerまたはコマンド行ツールを使用して表示および変更できます。この項では、Oracle Directory Services Managerでこれらのタスクを実行する方法について説明します。

注意:
Oracle Internet Directoryのインストール直後に、4-1ページの「タスク1: デフォルトのセキュリティ構成のリセット」の説明に従ってデフォルトのセキュリティ構成を必ずリセットしてください。

この項の項目は次のとおりです。

- 第30.2.1項「Oracle Directory Services Managerを使用したACPの表示」

- 第30.2.2項「Oracle Directory Services Managerを使用したACPの追加」

- 第30.2.3項「ODSMのアクセス制御管理を使用したACPの変更」

- 第30.2.4項「ODSMのデータ・ブラウザを使用したACPの追加または変更」

- 第30.2.5項「ODSMのデータ・ブラウザを使用したエントリ・レベルのアクセスの設定または変更」

関連項目:
コマンド行ツールの説明は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のOracle Identity Managementコマンド行ツールのリファレンスを参照してください。

30.2.1 Oracle Directory Services Managerを使用したACPの表示

ACPを特定し、表示する手順は次のとおりです。

1. 第7.4.5項「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動し、Oracle Internet Directoryサーバーに接続します。

2. タスク選択バーで、「セキュリティ」を選択します。

3. 左側のペインで「アクセス制御」をクリックします。定義されているすべてのアクセス制御ポイント(ACP)が、左側のペインに相対識別名順に表示されます。完全識別名を表示するには、エントリ上にマウスを移動します。

4. ACPを選択してその情報を右側のペインに表示します。

5. ページのサブツリー・アクセス項目セクションには、エントリ・レベルの操作(エントリ自体に対する操作)に関してこのACPに対するアクセス制御が表示されます。
ページの「コンテンツ・アクセス項目」セクションには、属性レベルの操作(エントリの属性に対する操作)に関してこのACPに対するアクセス制御が表示されます。

30.2.2 Oracle Directory Services Managerを使用したACPの追加

ACPは、規定の、すなわち継承可能なアクセス制御情報を含んだエントリです。この情報は、エントリ自体とその下位エントリすべてに影響を与えます。一般的に、サブツリー全体にわたる規模の大きいアクセス制御をブロードキャストするACPを作成します。

Oracle Directory Services Managerを使用してACPを追加するには、次の3つのタスクが必要です。

- タスク1: ACPにするエントリの指定

- タスク2: 構造型アクセス項目の構成(エントリに関するACI)

- タスク3: コンテンツ・アクセス項目の構成(属性に関するACI)

関連項目:
「構造型アクセス項目またはコンテンツ・アクセス項目の削除」

30.2.2.1 タスク1: ACPにするエントリの指定

1. 第7.4.5項「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動し、Oracle Internet Directoryサーバーに接続します。

2. タスク選択バーで、「セキュリティ」を選択します。

3. 左側のペインで「アクセス制御」をクリックします。定義されているすべてのACPが左側のペインに表示されます。

4. 左側のペインで「アクセス制御ポリシー・ポイントを作成します。」アイコンをクリックします。「新規アクセス制御ポイント」画面が表示されます。

5. 作成するエントリへのパスを入力するか、「参照」をクリックし、識別名を選択して、「OK」をクリックします。
エントリがすでにACPとして定義されている場合、エラー・ダイアログが表示されます。

6. また、既存のACPと同様のACPを作成するには、左側のペインの「アクセス制御管理」の下の既存のACPを選択し、類似作成アイコンをクリックします。「新規アクセス制御ポイント: 類似作成」画面が表示されます。

30.2.2.2 タスク2: 構造型アクセス項目の構成

1. 新規構造型アクセス項目(エントリに関係するACI)を定義するには、「新規アクセス制御ポイント」ペインまたは「新規アクセス制御ポイント: 類似作成」ペインの「構造型アクセス項目」セクションの新規アクセス項目の作成アイコンを選択します。「構造型アクセス項目」ダイアログ・ボックスが表示されます。
また、既存の項目と同様の構造型アクセス項目を作成することもできます。既存の構造型アクセス項目を選択し、「新規アクセス制御ポイント」ペインまたは「新規アクセス制御ポイント: 類似作成」ペインの「構造型アクセス項目」セクションの「選択したアクセス項目のコピーを作成します。」アイコンを選択します。「構造型アクセス項目」ダイアログ・ボックスが表示されます。一部のタブには構成情報が移入されていますが、これらは必要に応じて変更できます。

「構造型アクセス項目」ダイアログ・ボックスには、「エントリ・フィルタ」、「追加されたオブジェクト・フィルタ」、「責任者」および「アクセス権限」の4つのタブがあります。「エントリ・フィルタ」タブ・ページを使用して、ACIが関係するサブツリー・エントリを制限できます。「追加されたオブジェクト・フィルタ」、「責任者」および「アクセス権限」タブを使用して、アクセス制御を指定します。

2. ACPのすべての下位エントリをACPで管理する場合は、「エントリ・フィルタ」タブ・ページには何も入力せず、次の手順に進みます。それ以外の場合は、この手順を実行します。

エントリへのアクセスを、このエントリの1つ以上の属性に基づいて制限できます。たとえば、役職名がマネージャで組織単位がアメリカであるすべてのエントリへのアクセスを制限できます。

既存のフィルタを使用するには、「フィルタ・タイプ」メニューから「既存」を選択します。

新規フィルタを作成するには、「フィルタ・タイプ」メニューから「新規作成」を選択し、「LDAP問合せ」テキスト・フィールドに問合せ文字列を直接入力するか、検索基準バーのリストとテキスト・フィールドを使用して検索を絞り込みます。

1. 検索基準バーの一番左のリストから、検索するエントリの属性を選択します。各エントリですべての属性が使用されているわけではないため、指定した属性が、検索しているエントリの属性に実際に一致していることを確認する必要があります。そうでない場合は、検索に失敗します。

2. 検索基準バーの中央のリストから、フィルタを選択します。

3. 検索基準バーの一番右のテキスト・ボックスに、選択した属性の値を入力します。たとえば、選択した属性がcnの場合は、検索する個々の一般名を入力します。

4. 「+」をクリックし、この検索基準を「LDAP問合せ」フィールドに追加します。

5. 検索基準をさらに詳細に指定するには、論理積(AND、OR、NOT ANDおよびNOT OR)のリストと、検索基準バーのリストとテキスト・フィールドを使用して、別の検索基準を追加します。「+」をクリックし、検索基準を「LDAP問合せ」フィールドに追加します。「X」をクリックし、検索基準を「LDAP問合せ」フィールドから削除します。

3. 「追加されたオブジェクト・フィルタ」タブ・ページを選択します。
ACIを指定して、ユーザーが追加できるエントリの種類を制限できます。たとえば、ユーザーがobjectclass=countryを持つエントリのみを追加できるように、DSEルート・エントリでACIを指定できます。その後、ディレクトリ・サーバーによって、新規エントリがこのフィルタの制限に適合するかどうかが検証されます。

ユーザーが追加可能なエントリの種類を制限するには、「エントリ・フィルタ」タブ・ページと同じ手順に従い、「LDAP問合せ」テキスト・フィールドに問合せ文字列を直接入力するか、検索基準バーのリストとテキスト・フィールドを使用して検索を絞り込みます。

4. 「責任者」タブ・ページを選択します。

1. 「責任者」フィールドで、アクセス権を付与するエンティティを指定します。

2. 「バインド・モード」の下の「認証の選択」リストから、サブジェクト(アクセス権を要求しているエンティティ)が使用する認証のタイプを選択します。
認証方式を選択しない場合は、どの種類の認証も受け入れられます。あるノードで指定されている認証方式は、通信先のノードで指定されている認証方式と一致している必要があります。

「バインド・モード」の下の「暗号化の選択」リストで、使用される暗号化のタイプを選択します。

5. 「アクセス権限」タブ・ページを選択します。

付与する権限の種類を指定します。

- 参照: サブジェクトにエントリの表示を許可します。

- 追加: サブジェクトに、このエントリの下への他のエントリの追加を許可します。

- 削除: サブジェクトにエントリの削除を許可します。

- プロキシ: サブジェクトに、別のユーザーの代理となることを許可します。

6. 「OK」をクリックします。作成した構造型アクセス項目がリストに表示されます。

このACPの構造型アクセス項目を追加構成するには、「タスク2: 構造型アクセス項目の構成」を繰り返します。

30.2.2.3 タスク3: コンテンツ・アクセス項目の構成

1. コンテンツ・アクセス項目(属性に関係するACI)を定義するには、「新規アクセス制御ポイント」ペインまたは「新規アクセス制御ポイント: 類似作成」ペインの「コンテンツ・アクセス項目」セクションの新規アクセス項目の作成アイコンを選択します。「コンテンツ・アクセス項目」ダイアログ・ボックスが表示されます。
また、既存の項目と同様のコンテンツ・アクセス項目を作成することもできます。既存のコンテンツ・アクセス項目を選択し、「新規アクセス制御ポイント」ペインまたは「新規アクセス制御ポイント: 類似作成」ペインの「コンテンツ・アクセス項目」セクションの「選択したアクセス項目のコピーを作成します。」アイコンを選択します。「コンテンツ・アクセス項目」ダイアログ・ボックスが表示されます。一部のタブには構成情報が移入されていますが、これらは必要に応じて変更できます。

「コンテンツ・アクセス項目」ダイアログ・ボックスには、「エントリ・フィルタ」、「責任者」、「属性」および「アクセス権限」の4つのタブがあります。「エントリ・フィルタ」タブ・ページを使用して、ACIが関係するサブツリー・エントリを制限できます。「責任者」、「属性」および「アクセス権限」タブを使用して、アクセス制御を指定します。

2. ACPのすべての下位エントリをACPで管理する場合は、「エントリ・フィルタ」タブ・ページには何も入力せず、次の手順に進みます。それ以外の場合は、この手順を実行します。

ACPでは、アクセス権は、他のフィルタによりアクセスがそれ以上制限されないかぎり、このエントリおよびそのエントリのすべてのサブエントリに適用されます。適切な場合、「エントリ・フィルタ」タブ・ページを使用して、アクセスを指定するエントリを識別します。

エントリへのアクセスを、このエントリの1つ以上の属性に基づいて制限できます。たとえば、役職名がマネージャで組織単位がアメリカであるすべてのエントリへのアクセスを制限できます。

既存のフィルタを使用するには、「フィルタ・タイプ」メニューから「既存」を選択します。

新規フィルタを作成するには、「フィルタ・タイプ」メニューから「新規作成」を選択し、「LDAP問合せ」テキスト・フィールドに問合せ文字列を直接入力するか、検索基準バーのリストとテキスト・フィールドを使用して検索を絞り込みます。

1. 検索基準バーの一番左のリストから、検索するエントリの属性を選択します。各エントリですべての属性が使用されているわけではないため、指定した属性が、検索しているエントリの属性に実際に一致していることを確認する必要があります。そうでない場合は、検索に失敗します。

2. 検索基準バーの中央のリストから、フィルタを選択します。

3. 検索基準バーの一番右のテキスト・ボックスに、選択した属性の値を入力します。たとえば、選択した属性がcnの場合は、検索する個々の一般名を入力します。

4. 「+」をクリックし、この検索基準を「LDAP問合せ」フィールドに追加します。

5. 検索基準をさらに詳細に指定するには、論理積(AND、OR、NOT ANDおよびNOT OR)のリストと、検索基準バーのリストとテキスト・フィールドを使用して、別の検索基準を追加します。「+」をクリックし、検索基準を「LDAP問合せ」フィールドに追加します。「X」をクリックし、検索基準を「LDAP問合せ」フィールドから削除します。

3. 「責任者」タブ・ページを選択します。

1. 「責任者」フィールドで、アクセス権を付与するエンティティを指定します。

2. 「バインド・モード」の下の「認証の選択」リストから、サブジェクト(アクセス権を要求しているエンティティ)が使用する認証のタイプを選択します。
認証方式を選択しない場合は、どの種類の認証も受け入れられます。あるノードで指定されている認証方式は、通信先のノードで指定されている認証方式と一致している必要があります。

「バインド・モード」の下の「暗号化の選択」リストで、使用される暗号化のタイプを選択します。

3. アクセス権を付与するエンティティを指定します。

4. 「属性」タブ・ページを選択します。

1. 「属性」リストから、アクセス権を付与または否認する属性を選択します。

2. 「演算子」リストから、属性に対して実行する一致操作を選択します。選択肢は「EQ」(=)と「NEQ」(!=)です。
たとえば、「EQ」とcnを選択した場合は、付与したアクセス権がcn属性に適用されます。「NEQ」とcnを選択した場合は、付与したアクセス権がcn属性に適用されません。

5. 「アクセス権限」タブ・ページを選択します。
付与または否認する権限の種類を指定します。

- 読取り: サブジェクトに属性の読取りを許可します。

- 検索: サブジェクトに属性の検索を許可します。

- 書込み: サブジェクトに属性の変更を許可します。

- 自己書込み: エントリ自体に指定されたサブジェクトに属性の変更を許可します。

- 比較: サブジェクトに属性値と他の属性値の比較を許可します。

6. 「OK」をクリックします。作成したコンテンツ・アクセス項目がリストに表示されます。

このACPのコンテンツ・アクセス項目を追加構成するには、「タスク3: コンテンツ・アクセス項目の構成」を繰り返します。

30.2.2.4 構造型アクセス項目またはコンテンツ・アクセス項目の削除

構造型アクセス項目またはコンテンツ・アクセス項目を削除するには、項目を選択し、「削除」アイコンをクリックします。

30.2.3 ODSMのアクセス制御管理を使用したACPの変更

1. 第7.4.5項「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動し、Oracle Internet Directoryサーバーに接続します。

2. タスク選択バーで、「セキュリティ」を選択します。

3. 左側のペインで「アクセス制御」をクリックします。定義されているすべてのACPが左側のペインに表示されます。

4. 左側のペインで、リスト内のACPを選択します。そのACPに対応するタブ・ページが右側のペインに表示されます。

5. 新規構造型アクセス項目(エントリに関係するACI)を定義するには、「エントリ」タブ・ページの「構造型アクセス項目」セクションの「作成」アイコンを選択します。「構造型アクセス項目」ダイアログ・ボックスが表示されます。
また、既存の項目と同様の構造型アクセス項目を作成することもできます。既存の構造型アクセス項目を選択し、「新規アクセス制御ポイント」ペインまたは「新規アクセス制御ポイント: 類似作成」ペインの「構造型アクセス項目」セクションの類似作成アイコンを選択します。「構造型アクセス項目」ダイアログ・ボックスが表示されます。一部のタブには構成情報が移入されていますが、これらは必要に応じて変更できます。

「構造型アクセス項目」ダイアログ・ボックスには、「エントリ・フィルタ」、「追加されたオブジェクト・フィルタ」、「責任者」および「アクセス権限」の4つのタブがあります。「エントリ・フィルタ」タブ・ページを使用して、ACIが関係するサブツリー・エントリを制限できます。「追加されたオブジェクト・フィルタ」、「責任者」および「アクセス権限」タブを使用して、アクセス制御を指定します。第30.2.2.2,項「タスク2: 構造型アクセス項目の構成」の手順2から始まる手順に従ってください。

6. 既存の構造型アクセス項目を変更するには、項目を選択し、「編集」をクリックします。「構造型アクセス項目」ダイアログ・ボックスが表示されます。一部のタブには構成情報が移入されていますが、これらは必要に応じて変更できます。タブは、「エントリ・フィルタ」、「追加されたオブジェクト・フィルタ」、「付与先」および「アクセス権限」です。「エントリ・フィルタ」タブ・ページを使用して、ACIが関係するサブツリー・エントリを制限できます。「追加されたオブジェクト・フィルタ」、「責任者」および「アクセス権限」タブを使用して、アクセス制御を指定します。「タスク2: 構造型アクセス項目の構成」の手順2から始まる手順に従ってください。「OK」をクリックすると、構造型アクセス項目に加えた変更がリストに反映されます。

7. 新規コンテンツ・アクセス項目(属性に関係するACI)を定義するには、「エントリ」タブ・ページの「コンテンツ・アクセス項目」セクションの「作成」アイコンを選択します。「コンテンツ・アクセス項目」ダイアログ・ボックスが表示されます。
また、既存の項目と同様のコンテンツ・アクセス項目を作成することもできます。既存のコンテンツ・アクセス項目を選択し、「新規アクセス制御ポイント」ペインまたは「新規アクセス制御ポイント: 類似作成」ペインの「コンテンツ・アクセス項目」セクションの類似作成アイコンを選択します。「コンテンツ・アクセス項目」ダイアログ・ボックスが表示されます。一部のタブには構成情報が移入されていますが、これらは必要に応じて変更できます。

「コンテンツ・アクセス項目」ダイアログ・ボックスには、「エントリ・フィルタ」、「責任者」、「属性」および「アクセス権限」の4つのタブがあります。「エントリ・フィルタ」タブ・ページを使用して、ACIが関係するサブツリー・エントリを制限できます。「責任者」、「属性」および「アクセス権限」タブを使用して、アクセス制御を指定します。「タスク3: コンテンツ・アクセス項目の構成」の手順2から始まる手順に従ってください。

8. 既存のコンテンツ・アクセス項目を変更するには、項目を選択し、「編集」をクリックします。「コンテンツ・アクセス項目」ダイアログ・ボックスが表示されます。これには、「エントリ・フィルタ」、「付与先」、「属性」および「アクセス権限」の4つのタブがあります。「エントリ・フィルタ」タブ・ページを使用して、ACIが関係するサブツリー・エントリを制限できます。「付与先」、「属性」および「アクセス権限」タブを使用して、アクセス制御を指定します。これらは、「エントリ・フィルタ」、「追加されたオブジェクト・フィルタ」、「付与先」および「アクセス権限」です。「エントリ・フィルタ」タブ・ページを使用して、ACIが関係するサブツリー・エントリを制限できます。「追加されたオブジェクト・フィルタ」、「責任者」および「アクセス権限」タブを使用して、アクセス制御を指定します。「タスク3: コンテンツ・アクセス項目の構成」の手順に従ってください。「OK」をクリックすると、行った変更がリストに表示されます。

9. 構造型アクセス項目またはコンテンツ・アクセス項目を削除するには、項目を選択し、「削除」アイコンをクリックします。

10. 「適用」をクリックして、変更を有効にします。

30.2.4 ODSMのデータ・ブラウザを使用したACPの追加または変更

Oracle Directory Services Managerのデータ・ブラウザを使用してサブツリー・レベルのアクセスを設定する手順は、次のとおりです。

1. 第7.4.5項「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動します。

2. タスク選択バーで、「データ・ブラウザ」を選択します。

3. アクセスを設定するエントリにナビゲートします。

4. ナビゲータ・ペインで、エントリを選択して右側のペインにそのプロパティを表示します。

5. 「サブツリー・アクセス」タブ・ページを選択して、第30.2.3項「ODSMのアクセス制御管理を使用したACPの変更」での説明に従って、「構造型アクセス項目」タブと「コンテンツ・アクセス項目」タブでローカルACIを作成および編集します。

6. 変更後、「適用」をクリックします。

注意:
入力した情報をディレクトリ・サーバーに送信するには、「適用」をクリックする必要があります。そうしないと、情報はOracle Directory Services Managerのキャッシュに保持されるのみです。

30.2.5 ODSMのデータ・ブラウザを使用したエントリ・レベルのアクセスの設定または変更

Oracle Directory Services Managerを使用してエントリ・レベルのアクセス権を設定する手順は、次のとおりです。

1. 第7.4.5項「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動します。

2. タスク選択バーで、「データ・ブラウザ」を選択します。

3. アクセスを設定するエントリにナビゲートします。

4. ナビゲータ・ペインで、エントリを選択して右側のペインにそのプロパティを表示します。

5. 「ローカル・アクセス」タブ・ページを選択して、第30.2.3項「ODSMのアクセス制御管理を使用したACPの変更」での説明に従って、「構造型アクセス項目」タブと「コンテンツ・アクセス項目」タブでローカルACIを作成および編集します。

6. 変更後、「適用」をクリックします。

注意:
入力した情報をディレクトリ・サーバーに送信するには、「適用」をクリックする必要があります。

30.3 コマンド行ツールを使用したアクセス制御の管理

第30.1項「ディレクトリ・アクセス制御の管理の概要」で説明したように、ディレクトリのアクセス制御ポリシーの情報は、ユーザーが変更可能な構成属性で表されます。これらの属性の値の設定および変更にコマンド行ツール(ldapmodifyやldapmodifymtを含む)を使用することで、ディレクトリのアクセス制御を管理できます。

付録H「アクセス制御ディレクティブ書式」の説明に従ってACIを直接編集するには、ACIのディレクトリ表現の書式およびセマンティクスを理解する必要があります。

この項の項目は次のとおりです。

- 第30.3.1項「ユーザーが追加できるエントリの種類の制限」

- 第30.3.2項「ldapmodifyを使用した継承可能なACPの設定」

- 第30.3.3項「ldapmodifyを使用したエントリ・レベルのACIの設定」

- 第30.3.4項「ldapmodifyを使用したLDIFファイルでのワイルド・カードの使用方法」

- 第30.3.5項「識別名によるエントリの選択」

- 第30.3.6項「属性セレクタとサブジェクト・セレクタの使用方法」

- 第30.3.7項「読取り専用アクセス権の付与」

- 第30.3.8項「グループ・エントリへの自己書込みアクセス権の付与」

- 第30.3.9項「ポリシーの無視を禁止する完全な自律型ポリシーの定義」

関連項目:

- ライン・モード・コマンドに必須の入力形式であるLDIFを使用した入力の書式設定方法の詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のLDIFファイル形式の規則と例に関する説明を参照してください。

- ldapmodifyの実行方法の詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のldapmodifyコマンド行ツールのリファレンスを参照してください。

- ACIの書式または構文の詳細は、付録H「アクセス制御ディレクティブ書式」を参照してください。

30.3.1 ユーザーが追加できるエントリの種類の制限

ACIを指定して、ユーザーが追加できるエントリの種類を制限できます。たとえば、ユーザーがobjectclass=countryを持つエントリのみを追加できるように、DSEルート・エントリでACIを指定できます。これを行うには、added_object_constraintフィルタを使用します。その後、ディレクトリ・サーバーによって、新規エントリがこのフィルタの制限に適合するかどうかが検証されます。

次の制限を指定する例を示します。

- サブジェクトcn=admin,c=usは、organizationエントリの下を参照、追加および削除できます。

- サブジェクトcn=admin,c=usは、organizationエントリの下のorganizationalUnitオブジェクトを追加できます。

- その他はすべて、organizationエントリの下を参照できます。

access to entry filter=(objectclass=organization)
by group="cn=admin,c=us"
constraintonaddedobject=(objectclass=organisationalunit)
(browse,add,delete)
by * (browse)

30.3.2 ldapmodifyを使用した継承可能なACPの設定

この例では、my_ldif_fileという名前のLDIFファイルを使用して、ルートDSEでorclACIにサブツリーのアクセス権を設定します。この例はorclACI属性を参照しているため、このアクセス・ディレクティブはDITのエントリすべてを制御します。

ldapmodify -v -h myhost -D "cn=Directory Manager, o=IMC, c=US" -q -f my_ldif_file

LDIFファイルmy_ldif_fileは次のようになります。

dn:
changetype: modify
replace: orclaci
orclaci: access to entry

by dn="cn=directory manager, o=IMC, c=us" (browse, add, delete)
by * (browse, noadd, nodelete)

orclaci: access to attr=(*)

by dn="cn=directory manager, o=IMC, c=us" (search, read, write, compare)
by self (search, read, write, compare)
by * (search, read, nowrite, nocompare)

30.3.3 ldapmodifyを使用したエントリ・レベルのACIの設定

この例では、my_ldif_fileという名前のLDIFファイルを使用して、orclEntryLevelACI属性にエントリ・レベルのアクセス権を設定します。この例はorclentrylevelACI属性を参照しているため、このアクセス・ディレクティブは、それが存在しているエントリのみを制御します。

ldapmodify -v -h myhost -D "cn=Directory Manager, o=IMC, c=US" -q -f my_ldif_file

LDIFファイルmy_ldif_fileは次のようになります。

dn:
changetype: modify
replace: orclentrylevelaci
orclentrylevelaci: access to entry

by dn="cn=directory manager, o=IMC, c=us" (browse, add, delete)
by * (browse, noadd, nodelete)

orclentrylevelaci: access to attr=(*)

by dn="cn=directory manager, o=IMC, c=us" (search, read, write, compare)
by * (search, read, nowrite, nocompare)

注意:
この例では、識別名の値が指定されていません。このことは、このACIがルートDSEとその属性のみに関係していることを意味します。

30.3.4 ldapmodifyを使用したLDIFファイルでのワイルド・カードの使用方法

この例では、オブジェクトとサブジェクトの指定子にワイルド・カード(*)を使用しています。example.comドメイン内のすべてのエントリに対して、すべてのユーザーが、すべての属性の読取り権限と検索権限およびすべてのエントリの参照権限を持つことになります。

ldapmodify -v -h myhost -D "cn=Directory Manager, o=IMC, c=US" -q -f my_ldif_file

dc=comのACP内のorclACI属性は、次のように指定されています。

access to entry by * (browse)
access to attr=(*) by * (search, read)

属性の読取りを許可するには、エントリの参照権限を付与する必要があります。

30.3.5 識別名によるエントリの選択

この例では、2つのアクセス・ディレクティブで識別名を使用してエントリを選択する際の正規表現の使用方法を示します。この例では、dc=example,dc=comアクセス権より下位のアドレス帳属性に対するの読取り専用アクセス権をすべての人に付与します。

ldapmodify -v -h myhost -D "cn=Directory Manager, o=IMC, c=US" -q -f my_ldif_file

dc=example,dc=comのorclACI属性は、次のように指定されています。

access to entry by * (browse)
access to attr=(cn, telephone, email) by * (search, read)

dc=us,dc=example,dc=comのorclACI属性は、次のように指定されています。

access to entry by * (browse)
access to attr=(*) by dn=".*,dc=us,dc=example,dc=com" (search, read)

30.3.6 属性セレクタとサブジェクト・セレクタの使用方法

この例では、特定の属性に対するアクセス権を付与する属性セレクタ、および様々なサブジェクト・セレクタの使用方法を示します。この例は、dc=us,dc=example,dc=comサブツリー内のエントリに適用されます。このACIによって施行されるポリシーは次のとおりです。

- 管理者はサブツリー内のすべてのエントリに対する追加、削除および参照権限を所有しています。dc=usサブツリー内のその他のユーザーは、サブツリーの参照が可能ですが、サブツリー外部のユーザーはそのサブツリーにアクセスできません。

- salary属性は、そのマネージャによる変更が可能で、本人は参照できます。その他のユーザーはsalary属性にアクセスできません。

- userPassword属性は、パスワードの所有者と管理者による表示および変更が可能です。その他のユーザーは、この属性の比較のみ可能です。

- homePhone属性は、本人による読取りおよび書込みが可能で、すべてのユーザーが参照できます。

- その他のすべての属性は、管理者のみ値の変更が可能です。その他のすべてのユーザーは、比較、検索、読取りは可能ですが、属性値の更新はできません。

ldapmodify -v -h myhost -D "cn=Directory Manager, o=IMC, c=US" -q -f my_ldif_file

dc=us,dc=example,dc=comのorclACI属性は、次のように指定されています。

access to entry
by dn="cn=admin, dc=us,dc=example,dc=com" (browse, add, delete)
by dn=".*, dc=us,dc=example,dc=com" (browse)
by * (none)

access to attr=(salary)
by dnattr=(manager) (read, write)
by self (read)
by * (none)

access to attr=(userPassword)
by self (search, read, write)
by dn="cn=admin, dc=us,dc=example,dc=com" (search, read, write)
by * (compare)

access to attr=(homePhone)
by self (search, read, write)
by * (read)

access to attr != (salary, userPassword, homePhone)
by dn="cn=admin, dc=us,dc=example,dc=com" (compare, search, read, write)
by * (compare, search, read)

30.3.7 読取り専用アクセス権の付与

この例では、dc=example,dc=comより下位のアドレス帳属性に対する読取り専用アクセス権をすべての人に付与します。さらに、dc=us,dc=example,dc=comサブツリー内のみのすべての属性に対する読取りアクセス権をすべての人に付与します。

ldapmodify -v -h myhost -D "cn=Directory Manager, o=IMC, c=US" -q -f my_ldif_file

dc=example,dc=comのorclACI属性は、次のように指定されています。

access to entry by * (browse)
access to attr=(cn, telephone, email) by * (search, read)

dc=us,dc=example,dc=comのorclACI属性は、次のように指定されています。

access to entry by * (browse)
access to attr=(*) by dn=".*,dc=us,dc=example,dc=com" (search, read)

30.3.8 グループ・エントリへの自己書込みアクセス権の付与

この例では、USドメイン内のユーザーに、特定のグループ・エントリ(例: mailing list)のmember属性に対して自分自身の名前(識別名)の追加または削除のみを行うアクセス権を許可します。

ldapmodify -v -h myhost -D "cn=Directory Manager, o=IMC, c=US" -q -f my_ldif_file

グループ・エントリのorclEntryLevelACI属性は、次のように指定されています。

access to attr=(member)
by dn=".*, dc=us,dc=example,dc=com" (selfwrite)

30.3.9 ポリシーの無視を禁止する完全な自律型ポリシーの定義

この例では、グループの無視を否認します。

ldapmodify -v -h myhost -D "cn=Directory Manager, o=IMC, c=US" -q -f my_ldif_file

この例では、次の識別名を使用します。

表30-5 例で使用される識別名

コンテナ

DN

グループ無視ポリシーを適用できないネーミング・コンテキスト

c=us

ユーザー・コンテナ

cn=users,c=us

重要なデータ

cn=appdata

このネーミング・コンテキストのユーザー管理グループ

cn= user admin group, cn=users,c=us

セキュリティ管理グループまたはこのネーミング・コンテキスト

cn= security admin group, cn=users,c=us

パスワードをリセットするすべてのネーミング・コンテキストのグローバル・パスワード管理グループ

cn=password admin group

c=usのポリシー要件は次のとおりです。

- ユーザーはその情報を参照および読取りできる。

- ユーザー・セキュリティ管理は、パスワードとACPを除く、c=usの下の情報を変更できる。

- セキュリティ管理グループは、c=usの下のポリシーを変更できる。

- グローバル・パスワード管理とユーザーは、パスワードをリセットできる。

- 他のすべてのユーザーに権限は付与されない。

- このポリシーはオーバーライドできません。

必要なACPは次のとおりです。

Access to entry DenyGroupOverride
by dn=".*,c=us" (browse,noadd,nodelete)
by group="cn=User admin group,cn=users,c=us" (browse,add,delete)

Access to attr=(orclaci) DenyGroupOverride
by group="cn=security admin group,cn=users,c=us" (search,read,write,compare)
by * (none)

Access to attr=(userpassword) DenyGroupOverride
by self (search,read,write,compare)
by group="cn=password admin group" (search,read,write,compare)
by * (none)

Access to attr=(*) DenyGroupOverride
by self (search,read,nowrite,compare)
by group="cn= User admin group,cn=users,c=us" (search,read,write,compare)
by * (none)

31 パスワード・ベリファイアの管理

この章では、Oracle Internet Directoryおよび他のOracleコンポーネントに対してユーザーを認証するために使用されるセキュリティ資格証明であるパスワード・ベリファイアについて説明します。具体的には、Oracle Internet Directoryでこれらのパスワード・ベリファイアを集中的に格納する方法や、Oracle Directory Services Manager (ODSM)およびLDAPコマンド行ユーティリティを使用してパスワード・ベリファイアを管理する方法について説明します。

この章の内容は次のとおりです。

- 第31.1項「Directoryに対する認証用パスワード・ベリファイアの概要」

- 第31.2項「Directoryに対する認証用パスワード・ベリファイアのハッシング・スキームの管理」

- 第31.3項「コンポーネントに対する認証用パスワード・ベリファイアの概要」

- 第31.4項「ODSMを使用したOracleコンポーネント用パスワード・ベリファイア・プロファイルの管理」

- 第31.5項「コマンド行ツールを使用したコンポーネント用パスワード・ベリファイア・プロファイルの管理」

- 第31.6項「動的パラメータを使用したベリファイアの生成の概要」

- 第31.7項「動的パスワード・ベリファイアを生成するためのOracle Internet Directoryの構成」

31.1 Directoryに対する認証用パスワード・ベリファイアの概要

退職または役職が変わったユーザーの権限は、その当日に変更して、古くなった未使用のアカウントや権限が誤使用されないようにする必要があります。ユーザー・アカウントとパスワードが複数のデータベースに分散される大企業では、パスワードが集中管理されていないと、管理者が万全なセキュリティに必要な速度で変更を実行できない可能性があります。

Oracle Internet Directoryでは、セキュリティ資格証明を集中的に格納して、エンド・ユーザーと管理者が簡単に管理できるようにします。ここで格納される情報は、次のとおりです。

- ディレクトリ自体に対する認証ユーザーのパスワード

- その他のOracleコンポーネントに対する認証ユーザーのパスワード・ベリファイア

Oracle以外のアプリケーションがディレクトリ対応の場合、ユーザーは非Oracleの認証資格証明を格納できます。これらのアプリケーションは、製品エントリの下に独自のコンテナを作成する必要があります。

Oracle Internet Directoryでは、ユーザーのディレクトリ・パスワードをuserPassword属性に格納します。Oracle Internet Directoryでサポートされるハッシング・アルゴリズムの1つを使用して、パスワードを一方向ハッシュ値のBASE64エンコーディング文字列として格納することにより、このパスワードを保護できます。パスワードを暗号化された値ではなく一方向ハッシュ値として格納することにより、悪意のあるユーザーがパスワードを読み取ったり復号化できないため、パスワードがより完全に保護されます。

Oracle Internet DirectoryのデフォルトのuserPasswordハッシング・アルゴリズムは、MD4からSSHAに変更されました。このデフォルトのスキームは新規インストールでのみ有効です。新規インストール後に作成されたすべてのuserPassword属性は、SSHAを使用する一方向ハッシュであり、Oracle Internet Directoryに格納されます。

アップグレードを実行すると、アップグレード前に有効だったデフォルトのハッシング・スキームが保持されます。たとえば、アップグレード前のデフォルトのスキームがMD4の場合、アップグレード後もMD4がデフォルトのスキームとなります。userPasswordのセキュリティをより強化するには、アップグレード直後にデフォルトのスキームをSSHAに変更します。デフォルトのスキームをSSHAに変更しても、ユーザー・ログインには影響しません。セキュリティをより強化するために、ユーザーはSSHA値のハッシュ値がOracle Internet Directoryに格納されるように、パスワードをリセットする必要があります。

注意:
さらにセキュリティを強化する場合、11gリリース1 (11.1.1.4.0)では、よりセキュアなSHA-2アルゴリズムの3つのバリアント、およびこれらのバリアントのSaltバージョンを使用できます。

Oracle Internet Directoryでは、ユーザー・パスワードをorclrevpwd構成属性に可逆暗号化形式で格納します。このorclrevpwd属性は、パスワード・ポリシー・エントリの属性orclpwdencryptionenableが1に設定されている場合にのみ生成されます。

属性のアクセス制御ポリシー(ACI)を変更する場合でも、orclrevpwd属性はOracle Internet Directoryサーバーで安全に保持され、問合せは不可能です。ただし、Oracle Directory Integration Platformでは、orclrevpwd属性を問い合せることができ、これによりパスワード同期が機能します。

この項の項目は次のとおりです。

- 第31.1.1項「ユーザー・パスワード・ベリファイアおよびディレクトリに対する認証」

- 第31.1.2項「ユーザー・パスワード・ベリファイアを作成するためのハッシング・スキーム」

- 第31.2項「Directoryに対する認証用パスワード・ベリファイアのハッシング・スキームの管理」

31.1.1 ユーザー・パスワード・ベリファイアおよびディレクトリに対する認証

Oracle Internet Directoryでは、ユーザーのディレクトリ・パスワードを一方向ハッシュ値としてuserPassword属性に格納することによって、そのパスワードを保護します。使用するハッシング・アルゴリズムを選択します。パスワードを暗号化された値ではなく一方向ハッシュ値として格納することにより、悪意のあるユーザーがパスワードを読み取ったり復号化できないため、パスワードがより完全に保護されます。

ディレクトリ・サーバーの認証時に、クライアントはディレクトリ・サーバーにクリアテキストでパスワードを指定します。ディレクトリ・サーバーで、DSE属性orclcryptoschemeに指定されたハッシュ・アルゴリズムを使用してこのパスワードをハッシュします。その後、バインディング・エントリのuserPassword属性に格納されているハッシュ・パスワードと照らして検証します。ハッシュ・パスワード値が一致する場合、サーバーはそのユーザーを認証します。一致しない場合、サーバーはユーザーに対して「無効な資格証明」エラー・メッセージを送信します。

外部ユーザーは、バインディング・ユーザーのuserpassword属性に対するldapcompare操作を使用して認証できます。この場合でも、Oracle Internet Directoryは、最初に着信クリアテキスト値をハッシュしてそれを格納されている値と比較することによって、バインド操作のときと同じフローを使用します。

31.1.2 ユーザー・パスワード・ベリファイアを作成するためのハッシング・スキーム

インストール時、Oracle Identity Management 11gインストーラは、ユーザーのディレクトリ・パスワードを保護するために一方向ハッシング・スキームをSSHAに設定します。この値は、ルートDSEのorclCryptoScheme属性に格納されます。値は、次のハッシング・スキームに変更できます。

- MD4: 128ビットのハッシュまたはメッセージ・ダイジェスト値を生成する一方向ハッシュ関数

- MD5: MD4が改善された、より複合的なバージョン

- SHA-1: MD5よりさらに長い160ビットのハッシュを生成するセキュア・ハッシュ・アルゴリズム。このアルゴリズムはMD5よりも若干速度が遅くなりますが、大きなメッセージ・ダイジェストによって、総当たり攻撃や反転攻撃に対処できます。

- SSHA: Salted Secure Hash Algorithm。SHAと類似していますが、パスワードにランダムなsalt文字を使用して生成します。

- SHA256、SHA384、SHA512: よりセキュアなSHA-2アルゴリズムのバリアント。数値は、ハッシュ関数のダイジェスト・サイズを表しています。

- SSHA256、SSHA384、SSHA512: 3つのSHA-2アルゴリズムのSaltバージョン。

- SMD5: Salt MD5。MD5と類似していますが、パスワードにランダムなsalt文字を使用して生成します。

- UNIX Crypt: UNIXハッシング・アルゴリズム

- None: パスワードは、クリアテキストで格納されます。

第31.2項「Directoryに対する認証用パスワード・ベリファイアのハッシング・スキームの管理」および第9.5項「ODSMデータ・ブラウザを使用したシステム構成属性の管理」を参照してください。

注意:
過去において、Oracle Internet Directoryは、UNIX CryptのDESバリアントをサポートしていました。11g リリース1(11.1.1)Oracle Internet Directoryには、UNIX CryptのMD5およびBlowfishバリアントを解釈する機能があります。つまり、これらのバリアントを使用して事前にハッシュ処理されたパスワードをOracle Internet Directoryにそのままインポートし、作業を続行できます。ただし、orclcryptoschemeとしてUNIX Cryptを選択する場合は、引き続きUNIX CryptのDESバリアントのみが生成されます。

31.2 Directoryに対する認証用パスワード・ベリファイアのハッシング・スキームの管理

次の例は、my_ldif_fileという名前のLDIFファイルを使用してパスワード・ハッシング・アルゴリズムをSHA512に変更します。

ldapmodify -D cn=orcladmin -q -h myhost -p 3060 -v -f my_ldif_file

LDIFファイルmy_ldif_fileの内容は、次のとおりです。

dn:
changetype: modify
replace: orclcryptoscheme
orclcryptoscheme: SHA512

31.3 コンポーネントに対する認証用パスワード・ベリファイアの概要

Oracleコンポーネントは、パスワードとパスワード・ベリファイアの両方をOracle Internet Directoryに格納します。この項の項目は次のとおりです。

- 第31.3.1項「Oracleコンポーネントに対する認証用パスワード・ベリファイアについて」

- 第31.3.2項「Oracleコンポーネントに対する認証用パスワード・ベリファイアの格納用属性」

- 第31.3.3項「Oracleコンポーネントのデフォルトのベリファイア」

- 第31.3.4項「Oracleコンポーネントに対するパスワード検証の動作」

- 第31.4項「ODSMを使用したOracleコンポーネント用パスワード・ベリファイア・プロファイルの管理」

- 第31.5項「コマンド行ツールを使用したコンポーネント用パスワード・ベリファイア・プロファイルの管理」

31.3.1 Oracleコンポーネントに対する認証用パスワード・ベリファイアについて

Oracleコンポーネントは、それぞれのコンポーネントのパスワード値をパスワード・ベリファイアとしてOracle Internet Directoryに格納できます。パスワード・ベリファイアとは、クリアテキストのパスワードをハッシュしたバージョンで、このバージョンはBASE64エンコーディング文字列としてエンコードされます。

次のいずれかのハッシング・アルゴリズムを使用して、パスワード・ベリファイアを導出できます。

- MD5: MD4が改善された、より複合的なバージョン

- SHA-1: MD5よりさらに長い160ビットのハッシュを生成するセキュア・ハッシュ・アルゴリズム。このアルゴリズムはMD5よりも若干速度が遅くなりますが、大きなメッセージ・ダイジェストによって、総当たり攻撃や反転攻撃に対処できます。

- SSHAおよびSMD5

- SHA256、SHA384、SHA512: よりセキュアなSHA-2アルゴリズムのバリアント。数値は、ハッシュ関数のダイジェスト・サイズを表しています。

- SSHA256、SSHA384、SSHA512: 3つのSHA-2アルゴリズムのSaltバージョン。

- UNIX Crypt: UNIXハッシング・アルゴリズム

- SASL/MD5: Simple Authentication and Security Layer/MD5。接続ベースのプロトコルに認証サポートを追加し、チャレンジ/レスポンス・プロトコルを使用します。

- O3LOGON: ベリファイアを生成する独自のOracleアルゴリズム。チャレンジ/レスポンス・プロトコルを使用するという点で、SASL/MD5と類似しています。

- ORCLWEBDAV: SASL/MD5と同じ専用アルゴリズムで、username@realmの形式のユーザー名を使用します。

- ORCLLM: SMBLMアルゴリズムのOracle表現です。SMBLMアルゴリズムは、SMB/CIFSチャレンジ/レスポンス認証アルゴリズムのLMバリアントOracle表現です。

- ORCLNT: SMBNTアルゴリズムのOracle表現です。SMBNTアルゴリズムは、SMB/CIFSチャレンジ/レスポンス認証アルゴリズムのNTバリアントOracle表現です。

Oracleアプリケーションのインストール時に、Oracle Identity Management 11gインストーラは、必要なパスワード検証情報をすべて含むパスワード・ベリファイア・プロファイル・エントリをそのアプリケーション用に作成します。図31-1に示すように、このエントリは、レルム固有のOracleコンテキストの下にある製品エントリ下のアプリケーション・エントリの直下に配置されます。

このベリファイア・プロファイル・エントリは、指定されたレルム内のユーザーのみに適用されます。ベリファイアの生成を適切に行うには、レルム固有のOracleコンテキストの共通エントリのorclcommonusersearchbase属性に適切な値を設定する必要があります。

図31-1 パスワード・ベリファイア・プロファイル・エントリの位置

31.3.2 Oracleコンポーネントに対する認証用パスワード・ベリファイアの格納用属性

ディレクトリとOracleコンポーネントの両方とも、ユーザー・パスワードをユーザー・エントリに格納しますが、格納する属性は異なります。ディレクトリは、userPassword属性にユーザー・パスワードを格納しますが、Oracleコンポーネントは、ユーザー・パスワード・ベリファイアをauthPassword、orclPasswordVerifierまたはorclpassword属性に格納します。表31-1に、Oracleコンポーネントで使用する各属性を示します。

表31-1 ユーザー・エントリにパスワード・ベリファイアを格納するための属性

属性

説明

authPassword

パスワードが、ディレクトリに対してユーザー認証を行うために使用するパスワードuserpasswordと同じ場合に、パスワードをOracleコンポーネントに格納するための属性。この属性の値は、userpassword属性の値と同期します。

複数の異なるアプリケーションで、ディレクトリに使用されるのと同じクリアテキスト・パスワードを入力するようにユーザーに要求できますが、各アプリケーションでは、異なるアルゴリズムを使用してそのパスワードをハッシュすることがあります。この場合、同じクリアテキスト・パスワードが、複数の異なるパスワード・ベリファイア機能のソースになります。

この属性は複数値の属性であるため、異なるアプリケーションがこのユーザーのクリアテキスト・パスワードに対して使用する他のすべてのベリファイアを格納できます。userpassword属性を変更すると、すべてのアプリケーションのauthpasswordsが再生成されます。

orclPasswordVerifier

パスワードが、ディレクトリに対してユーザー認証を行うために使用するパスワードuserpasswordと異なる場合に、パスワードをOracleコンポーネントに格納するための属性。この属性の値は、userpassword属性の値とは同期しません。

authPasswordと同様に、この属性は複数値の属性であるため、異なるアプリケーションがこのユーザーのクリアテキスト・パスワードに対して使用する他のすべてのベリファイアを格納できます。

orclPassword

エンタープライズ・ユーザー用の03LOGONベリファイアのみを格納するための属性。03LOGONベリファイアは、userpassword属性と同期し、デフォルトでは、orcluserv2オブジェクト・クラスに関連付けられたすべてのユーザー・エントリに対して生成されます。

Oracle Internet Directoryをインストールすると、デフォルトではルートOracleコンテキストにデータベース・セキュリティ・プロファイルのエントリが作成されます。このエントリの存在によって、orcluserv2オブジェクト・クラスに関連付けられたユーザー・エントリを対象とする03LOGONベリファイアが生成されます。

これらの属性の型には、属性サブタイプとしてappIDがあります。この属性サブタイプで特定のアプリケーションを一意に識別します。たとえば、appIDはアプリケーション・エントリのORCLGUIDにできます。この属性サブタイプは、アプリケーションのインストール時に生成されます。

図31-2では、様々なOracleコンポーネントで、Oracle Internet Directoryにパスワード・ベリファイアが格納されています。Oracle Single Sign-Onはディレクトリ用と同じパスワードを使用し、このパスワードをauthPassword属性に格納します。その他のアプリケーションは別のパスワードを使用し、ベリファイアをorclPasswordVerifier属性に格納します。

次の記述は、アプリケーション固有のベリファイア・プロファイルの例です。共通のベリファイア・フレームワークを使用しないことを選択したアプリケーションでは、次の例のように、固有のベリファイア・プロファイル・エントリを作成する必要があります。orclappidはアプリケーション・コンテナのGUIDに設定され、ベリファイア属性authpasswordおよびorclpasswordverifierのサブタイプとしても使用されます。

dn: cn=IFSVerifierProfileEntry,cn=IFS,cn=Products,cn=OracleContext,o=Oracle,dc=com
objectclass:top
objectclass:orclpwdverifierprofile
cn:IFSVerifierProfileEntry
orclappid:8FF2DFD8203519C0E034080020C34C50
orclpwdverifierparams;authpassword: crypto:SASL/MDS $ realm:dc=com
orclpwdverifierparams;orclpasswordverifier: crypto:ORCLLM
orclpwdverifierparams;authpassword: crypto:ORCLWEBDAV $ realm:dc=com
$ usernameattribute: mail $ usernamecase: lower $ nodomain: TRUE

SASL/MD5およびORCLWEBDAVベリファイアは、ユーザー名、レルムおよびパスワードを使用して生成されます。使用するユーザー名属性は、ベリファイア・プロファイル・エントリで指定できます。ユーザー名は大文字でも小文字でも指定できます。ORLWEBDAVベリファイアは、ユーザー名にアイデンティティ管理レルムの名前を追加して生成されます。レルムの名前を追加して生成する必要がない場合、ベリファイア・プロファイル・エントリではnodomain: TRUEを指定する必要があります。

前述の例では、ORCLWEBDAVベリファイアは、レルムの名前を追加せずにmail属性の値を使用して生成されます。また、ユーザー名はベリファイアが生成される前に小文字に変換されます。

図31-2 認証モデル

31.3.3 Oracleコンポーネントのデフォルトのベリファイア

各Oracleコンポーネントのプロファイルを作成する必要をなくし、すべてのコンポーネントでパスワード・ベリファイアを共有できるようにするために、Oracle Internet Directoryにはパスワード・ベリファイアのデフォルト・セットが用意されています。デフォルトのベリファイアには、MD5、MD5-IFS(ユーザー名がニックネーム属性の値に設定され、レルムがAuthorized_Usersに設定されたSASL/MD5)、WEBDAV、ORCLLMおよびORCLNTのタイプがあります。

2つのプロファイル・エントリが必要です。1つは数値のみを使用する個人識別番号(PIN)を使用するアプリケーション用、もう1つは英数字のパスワードを使用するアプリケーション用です。

PINベースのアプリケーション用ベリファイア(たとえば、OracleAS Unified Messagingのボイス・メール)は、orclpasswordverifier;orclcommonpin属性に格納されます。サブタイプorclcommonpinは、数値のPINと英数字のパスワードを区別するために使用されます。数値のPINを使用するアプリケーションでは、orclpasswordverifier;orclcommonpin属性に対して直接に問合せや比較ができます。

英数字パスワード・ベースのアプリケーション用ベリファイアは、次のいずれかに格納されます。

- authpassword;orclcommonpwd属性: アプリケーションがそのベリファイアとuserpassword属性を同期する必要がある場合

- orclpasswordverifier;orclcommonpwd属性: userpassword属性との同期が必要ない場合

サブタイプorclcommonpwdは、数値のPINと英数字のパスワードを区別するために使用されます。サブタイプが付いたベリファイア属性は、問合せが可能です。

これらのプロファイル・エントリには、サブスクライブ・アプリケーションのリストも含まれ、これらのアプリケーションは、プロファイル・エントリ内でuniquemember属性の値として指定されます。デフォルトでは、Oracle Single Sign-OnのアイデンティティのDNがサブスクライブ・アプリケーションの1つになっています。これは、Oracle Single Sign-Onが、すべてのパートナ・アプリケーションのプロキシ・メンバーであることを示しています。Oracle Single Sign-Onに基づいていないすべてのアプリケーションで、適切なプロファイル・エントリ内のuniquemember属性にアイデンティティ(DN)を追加する必要があります。

次に、プロファイル・エントリの例を示します。

Cn=defaultSharedPwdProfileEntry, cn=common, cn=products, cn=oraclecontext
Objectclass: orclpwdverifierprofile
Objectclass: orclcommonpwdprofile
Cn: defaultSharedPwdProfileEntry
Orclappid: orclcommonpwd
Orclpwdverifierparams;authpassword: crypto:SASL/MD5 $ realm:Authorized_Users
Orclpwdverifierparams;authpassword: crypto:ORCLWEBDAV $ realm:Authorized_Users
Orclpwdverifierparams;authpassword: crypto:ORCLLM
Orclpwdverifierparams;authpassword: crypto:ORCLNT
Orclpwdverifierparams;orclpasswordverifier: crypto:SSHA
Uniquemember: cn=SSO,cn=Products,cn=OracleContext
Uniquemember: cn=IFS,cn=Products,cn=OracleContext

Cn=defaultSharedPINProfileEntry, cn=common, cn=products, cn=oraclecontext
Objectclass: orclpwdverifierprofile
Objectclass: orclcommonpwdprofile
Cn: defaultSharedPinProfileEntry
Orclappid: orclcommonpin
Orclpwdverifierparams;orclpasswordverifier: crypto:MD5
Orclpwdverifierparams;orclpasswordverifier: crypto:SSHA
Uniquemember: cn=SSO,cn=Products,cn=OracleContext
Uniquemember: cn=Unified Messaging,cn=Products,cn=OracleContext

PINベースのアプリケーションでは、authpasswordはオプションではありません。orclpasswordverifier属性が使用されます。

31.3.4 Oracleコンポーネントに対するパスワード検証の動作

図31-3に、Oracleコンポーネントに対するパスワード検証の例を示します。この例のOracleコンポーネントは、パスワード・ベリファイアをディレクトリに格納します。

図31-3 パスワード検証の動作

1. ユーザーは、ユーザー名とクリアテキスト・パスワードを入力して、アプリケーションへのログインを試みます。

2. アプリケーションは、クリアテキスト・パスワードをディレクトリ・サーバーに送信します。アプリケーションは、パスワード・ベリファイアをディレクトリに格納した後、ディレクトリ・サーバーに対して、このパスワード値をディレクトリ内の対応するベリファイアと比較するようにリクエストします。

3. ディレクトリ・サーバーは、次のように動作します。

1. 特定のアプリケーションに指定されているハッシング・アルゴリズムを使用して、パスワード・ベリファイアを生成します。

2. 次に、生成したパスワード・ベリファイアをディレクトリ内の対応するパスワード・ベリファイアと比較します。比較操作が成功した場合、アプリケーションは、ベリファイア属性のサブタイプとしてそのappIDを指定する必要があります。次に例を示します。

ldapcompare -p 3060 -D "DN_of_the_appplication_entity" -q \
-b "DN_of_the_user" -a orclpasswordverifier;appID \
-v password_of_the_user

3. 比較操作の結果をアプリケーションに通知します。

4. アプリケーションは、ディレクトリ・サーバーからのメッセージに従って、ユーザーを認証または否認します。

アプリケーションは、比較操作を使用しない場合、次のように動作します。

1. ユーザーが入力したクリアテキスト・パスワードをハッシュします。

2. ユーザーが入力したクリアテキスト・パスワードのハッシュ値をディレクトリから取り出します。

3. クライアントが応答するユーザーへのチャレンジを開始します。レスポンスが適切な場合、アプリケーションはユーザーを認証します。

31.4 ODSMを使用したOracleコンポーネント用パスワード・ベリファイア・プロファイルの管理

Oracle Directory Services Managerを使用して、パスワード・ハッシング・スキームを含むパスワード・ベリファイア・プロファイル・エントリを表示および変更できます。

アプリケーションのパスワード・ベリファイアを表示および変更する手順は、次のとおりです。

1. 第7.4.5項「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動し、Oracle Internet Directoryサーバーに接続します。

2. タスク選択バーで、「セキュリティ」を選択します。

3. 左側のペインで「パスワード検証」を展開します。すべてのパスワード・ベリファイアが左側のペインに表示されます。

4. 表示するパスワード・ベリファイアを選択します。右側のペインには、「パスワード検証プロファイル」タブ・ページが表示されます。

5. パスワード・ベリファイアの生成に使用するハッシング・アルゴリズムを変更できます。「パスワード検証プロファイル」ダイアログ・ボックスで、「Oracleパスワード・パラメータ」フィールドにハッシング・アルゴリズムを指定します。構文は次のとおりです。

crypto:hashing_algorithm

たとえば、ORCLLMハッシング・アルゴリズムを使用している場合、次のように入力します。

crypto:ORCLLM

たとえば、SASL/MD5を使用している場合、次のように入力できます。

crypto:SASL/MD5 $ realm:dc=com

31.5 コマンド行ツールを使用したコンポーネント用パスワード・ベリファイア・プロファイルの管理

コマンド行ツールを使用して、パスワード・ベリファイア・プロファイルを表示および変更できます。

31.5.1 コマンド行ツールを使用したパスワード・ベリファイア・プロファイルの表示

アプリケーションのパスワード・ベリファイアを表示するには、パスワード・ベリファイア・プロファイルの識別名を指定して検索を実行します。

31.5.2 例: コマンド行ツールを使用したパスワード・ベリファイア・プロファイルの変更

この例では、アプリケーションのパスワード・ベリファイア・プロファイル・エントリのハッシング・アルゴリズムを変更します。このパスワード・ベリファイアは、ユーザーのディレクトリ・パスワードと同期しています。次のように入力します。

ldapmodify -D "cn=orcladmin" -q -p 3060 -h my_host -v -f file.ldif

file.ldifの内容は、次のとおりです。

dn: cn=MyAppVerifierProfileEntry,cn=MyApp,cn=Products,cn=OracleContext,
o=my_company,dc=com
changetype: modify
replace: orclPwdVerifierParams
orclPwdVerifierParams;authPassword: crypto:SASL/MD5 $ realm:dc=com

31.6 動的パラメータを使用したベリファイアの生成の概要

前述のパスワード・ベリファイアは、静的パスワード・ベリファイアです。つまり、通常アプリケーションのインストール中に、事前構成されたパラメータから生成されたベリファイアです。一部のアプリケーション(Oracle Calendar、Oracle EmailおよびOracle Wireless and Voiceなど)では、Oracle Internet Directoryが動的パスワード・ベリファイアを生成する必要があります。

Oracle Internet Directoryは、アプリケーションが動的パスワード・ベリファイアをリクエストした場合に、これを生成します。動的ベリファイアは、アプリケーションの実行時に使用可能になるアプリケーション・パラメータに基づいています。

Oracle Internet Directoryが動的パスワード・ベリファイアを生成するには、以前に可逆暗号化形式で格納されたユーザー・パスワードが必要です。Oracle Internet Directoryでは、これらの値を構成属性orclrevpwdおよびorclunsyncrevpwdに格納します。userpasswordに基づいて暗号化された値は、orclrevpwdパラメータに格納されます。Oracle Calendarで使用される数値のPINなど、userpassword以外のパスワードに基づいて暗号化された値は、パラメータorclunsyncrevpwdに格納されます。

31.7 動的パスワード・ベリファイアを生成するためのOracle Internet Directoryの構成

userpasswordを使用し、動的パスワード・ベリファイアを必要とするアプリケーションをデプロイする場合、Oracle Internet Directoryがorclrevpwd属性を生成することを確認する必要があります。レルムのパスワード・ポリシー・エントリの属性orclpwdencryptionenableが1に設定されている場合、ユーザーをプロビジョニングすると、Oracle Internet Directoryは属性orclrevpwdを生成します。したがって、ユーザーをプロビジョニングする前に、orclpwdencryptionenableを1に設定する必要があります。

orclpwdencryptionenableの値を確認するには、ldapsearchを使用して、確認対象のエントリの有効なpwdpolicyエントリを問い合せます。たとえば、デフォルトのpwdpolicyを問い合せる場合、次のように入力します。

$ ldapsearch -p port -q -D "cn=orcladmin" \
-b "cn=default,cn=pwdPolicies,cn=Common,cn=Products,cn=OracleContext" \
-s base "objectclass=*"

orclpwdencryptionenableが表示されないか0の場合、ldapmodifyと次のようなLDIFファイルを使用して1に設定します。

dn: cn=DefaultSharedPinProfileEntry,cn=Common,cn=Products,cn=Oraclecontext
cn: DefaultSharedPinProfileEntry
orclappid: orclpwdencryptionenable
orclpwdencryptionenable: 1

orclpwdencryptionenableを設定する前にユーザーをプロビジョニングした場合には、かわりにすべてのユーザーのユーザー・パスワードをリセットし、暗号化された値を生成する必要があります。

数値のPINを使用し、動的パスワード・ベリファイアを必要とするアプリケーションをデプロイする場合、orclunsyncrevpwdに格納される値を生成するために、Oracle Internet Directoryが暗号タイプ3DESを使用可能であることを確認する必要があります。3DESを、ルートOracleコンテキスト下の共通ベリファイア・プロファイル・エントリの属性orclpwdverifierparams;orclpasswordverifierの値として指定する必要があります。このエントリのデフォルトの識別名はcn=DefaultSharedPINProfileEntry,cn=Common,cn=Products, cn=OracleContextです。値を設定するには、次のLDIFファイルを使用します。

dn: cn=DefaultSharedPinProfileEntry,cn=Common,cn=Products,cn=Oraclecontext
cn: DefaultSharedPinProfileEntry
orclappid: orclcommonpin
orclpwdverifierparams;orclpasswordverifier: crypto:MD5
orclpwdverifierparams;orclpasswordverifier: crypto:3DES

次のようなコマンド行を使用します。

ldapmodify -D cn=orcladmin -q -p portNum -h hostname -f ldifFile

32 Oracle Identity Managementの権限の委任

この章では、Oracle Identity Managementの委任モデルと、Oracle Internet Directoryのデフォルトのセキュリティ構成について説明します。具体的には、ユーザー、グループおよびサービスに関するすべてのデータを1つのリポジトリに格納する方法や、そのデータの管理を様々な管理者に委任する方法について説明します。

この章の内容は次のとおりです。

- 第32.1項「Oracle Identity Managementの権限の委任の概要」

- 第32.2項「ユーザーおよびグループの管理権限の委任」

- 第32.3項「Oracleコンポーネントのデプロイメント権限の委任」

- 第32.4項「コンポーネントの実行時権限の委任」

注意:
この章で言及するOracle Delegated Administration Servicesはすべて、Oracle Delegated Administration Services 10g(10.1.4.3.0)以上のことです。

32.1 Oracle Identity Managementの権限の委任の概要

Oracle Identity Managementを使用すると、ユーザー、グループおよびサービスのすべてのデータを1つのリポジトリに格納し、各データ・セットに特定の管理者を割り当てることができます。Oracle Identity Managementは、集中型のリポジトリとカスタマイズされた委任アクセスの両方を提供できる、安全でスケーラブルなものです。

この項の項目は次のとおりです。

- 第32.1.1項「委任の仕組み」

- 第32.1.2項「Oracle Fusion Middleware環境での委任」

- 第32.1.3項「デフォルトの構成について」

- 第32.1.4項「Oracleテクノロジ・スタックの管理権限」

32.1.1 委任の仕組み

委任モデルを使用すると、グローバル管理者は、ホスティングされた企業のアイデンティティ管理レルムを作成し、管理する権限をレルム管理者に委任できます。一方、レルム管理者は、アプリケーション用パスワード、個人データおよび作業環境を変更する権限をエンド・ユーザーおよびグループに委任できます。このようにして、各タイプのユーザーに、適切なレベルの権限を与えることができます。

必要な権限を委任するには、ユーザーを適切な管理グループに割り当てます。たとえば、エンタープライズ・ユーザーと電子メール・サービスに関するデータの両方をディレクトリに格納し、それぞれのデータ・セットに一意の管理者を割り当てる必要があるとします。ユーザーをエンタープライズ・ユーザーの管理者として指定するには、そのユーザーをエンタープライズ・ユーザー管理者グループなどに割り当てます。ユーザーを電子メール・サービスの管理者として指定するには、そのユーザーを電子メール・サービス管理者グループなどに割り当てます。

32.1.2 Oracle Fusion Middleware環境での委任

図32-1に、Oracle Fusion Middleware環境での委任の流れを示します。

図32-1 Oracle Fusion Middleware環境での委任の流れ

図32-1に示すように、Oracle Fusion Middleware環境では、ディレクトリのスーパーユーザー(cn=orcadmin)は次のものを作成します。

- Oracleコンテキスト

- レルム

- レルム固有のOracleコンテキスト

- レルム管理者用のエントリ(cn=orcladmin, cn=users, Enterprise DN)

一方、レルム管理者は、Oracleコンテキスト管理者グループにユーザーを割り当てることで、Oracleコンテキストの管理を特定のユーザーに委任します。その後、Oracleコンテキスト管理者は、Oracle Fusion Middleware管理者グループにユーザーを割り当てることで、Oracle Application Serverの管理を1人以上のユーザーに委任します。Oracle Fusion Middlewareの管理者は、Oracle Fusion Middlewareコンポーネントをインストールおよび管理し、ユーザーやグループのデータ管理をユーザーおよびグループの管理者グループに委任します。ユーザーおよびグループの管理者は、ユーザーおよびグループを作成します。他のユーザーにユーザーおよびグループの管理者権限を付与することもできます。

32.1.3 デフォルトの構成について

Oracle Internet Directoryを初めてインストールすると、デフォルトの構成により、ディレクトリ情報ツリー(DIT)内の様々なポイントでアクセス制御ポリシーが確立されます。デフォルトのアクセス制御は、この章の後半で説明するとおり、「ユーザー」および「グループ」のコンテナに配置されます。同様に、特定のディレクトリ・エンティティのデフォルトの権限についても、この章の後半で説明します。また、表32-2に示すように、特定のデフォルトの権限はすべての人および各ユーザーに付与されます。

表32-1 すべての人および各ユーザーに付与されるデフォルトの権限

対象

デフォルトの権限

すべての人

ルートDSEでの権限は次のとおりです。

- ユーザー・エントリを参照する権限

- userpkcs12、orcluserpkcs12hint、userpassword、orclpasswordおよびorclpasswordverifier以外のすべてのユーザー属性に対する検索、読取りおよび比較権限

各ユーザー

userpassword、orclpasswordおよびorclpasswordverifier属性を含む各ユーザー独自の属性に対する完全なアクセス権

企業のセキュリティ要件を満たすように、このデフォルト構成をカスタマイズできます。

32.1.4 Oracleテクノロジ・スタックの管理権限

表32-2に、Oracleテクノロジ・スタックの管理に必要な権限を示します。

表32-2 Oracleテクノロジ・スタックの管理権限

権限のタイプ

説明

詳細情報の参照先

ユーザーおよびグループの管理権限

これらの権限は、アイデンティティ管理インフラストラクチャを使用するOracleコンポーネントまたはエンド・ユーザー自身のいずれかに委任されます。

第32.2項「ユーザーおよびグループの管理権限の委任」

デプロイメント時権限

この権限は、Oracleコンポーネントをデプロイするために必要です。ディレクトリ内部で適切なエントリを作成する権限や、共通リポジトリにメタデータを格納する権限を含む場合もあります。そのような権限は、Oracle Portal管理者などに与える必要があります。

第32.3項「Oracleコンポーネントのデプロイメント権限の委任」

実行時権限

この権限は、アイデンティティ管理インフラストラクチャ内のOracleコンポーネントの実行時の対話を円滑にするために必要な権限です。ユーザー属性の表示、新規ユーザーの追加、グループ・メンバーシップの変更のための権限が含まれます。そのような権限は、各Oracleコンポーネントに固有な管理ツールがOracle Internet Directory内部でエントリにアクセス、またはエントリを作成できるように、その管理ツールに対し与える必要があります。

第32.4項「コンポーネントの実行時権限の委任」

注意:
OracleコンテキストでデフォルトACLを変更する場合は注意が必要です。変更により、ご使用の環境内でOracleコンポーネントのセキュリティが無効になることがあります。OracleコンテキストでデフォルトACLを安全に変更できるかどうかの詳細は、各コンポーネントのドキュメントを参照してください。

関連項目:
既存のディレクトリ構造からOracle Application Server環境への移行を検討している場合は、第37.1項「他のデータ・リポジトリからのデータの移行の概要」を参照してください。

32.2 ユーザーおよびグループの管理権限の委任

管理権限は、アイデンティティ管理インフラストラクチャを使用するOracleコンポーネントまたはエンド・ユーザー自身のいずれかに委任されます。権限は、アイデンティティ(ユーザーやアプリケーションなど)、またはロールやグループに対して委任できます。

この項の項目は次のとおりです。

- 第32.2.1項「ユーザーおよびグループのデータ管理権限の委任方法」

- 第32.2.2項「ユーザー・データを管理するためのデフォルトの権限」

- 第32.2.3項「グループ・データを管理するためのデフォルトの権限」

32.2.1 ユーザーおよびグループのデータ管理権限の委任方法

管理権限を委任するには、Oracle Internet Directoryスーパーユーザーが、次の作業を行います。

1. アイデンティティ管理レルムを作成します。

2. そのレルムでレルム管理者と呼ばれる特別なユーザーを識別します。

3. そのレルム管理者にすべての権限を委任します。

このレルム管理者は、Oracle定義済ロール(Oracle Fusion Middleware管理者など)に、Oracleコンポーネントが必要とする特定の権限を委任します。Oracleコンポーネントは、デプロイ時にこれらのロールを受け取ります。

レルム管理者は、Oracleコンポーネント固有のロールに権限を委任するほかに、デプロイメントに固有のロール(たとえば、ヘルプ・デスク管理者用のロール)を定義し、権限をこれらのロールに付与できます。委任された管理者は、これらのロールをさらにエンド・ユーザーに付与することができます。実際、ユーザー管理タスクの大部分はセルフサービス(電話番号の変更やアプリケーション固有の作業環境の指定など)に関係しているため、レルム管理者とOracleコンポーネント管理者は、これらの権限をエンド・ユーザーに委任できます。

グループの場合、1人以上の所有者(通常、エンド・ユーザー)を指定できます。これらの所有者に必要な管理権限が付与された場合、所有者は、Oracle Internet Directory Self-Service Console、Oracle Directory Services Managerまたはコマンド行ツールを使用してグループを管理できます。

32.2.2 ユーザー・データを管理するためのデフォルトの権限

ユーザーの管理には、次の権限が含まれます。

- ユーザー・エントリを作成および削除する権限

- ユーザー属性を変更する権限

- ユーザー管理を他のユーザーに委任する権限

ユーザーを作成するためのアクセス制御ポリシー・ポイント(ACP)は、アイデンティティ管理レルムの「ユーザー」コンテナにあります。

この項では、これらの権限について説明します。

32.2.2.1 レルムに対するユーザーの作成

レルムに対してユーザーを作成するには、管理者はサブスクライバDASユーザー作成グループのメンバーである必要があります。表32-3に、このグループの特性を示します。

表32-3 サブスクライバDASユーザー作成グループの特性

特性

説明

デフォルトACP

デフォルトのレルムの「ユーザー」コンテナにあるACLにより、レルムのOracleコンテキストのサブスクライバDASユーザー作成グループは、「ユーザー」コンテナの下でユーザーを作成できます。

管理者

Oracle Internet Directoryスーパーユーザー

Oracleコンテキスト管理者グループのメンバー。

ユーザー権限割当てグループのメンバー。

DAS管理者グループのメンバー。

このグループの所有者。

DN

cn=OracleDASCreateUser,cn=Groups,Oracle_Context_DN

32.2.2.2 ユーザー属性の変更

ユーザー属性を変更するには、管理者はサブスクライバDASユーザー編集グループのメンバーである必要があります。表32-4に、このグループの特性を示します。

表32-4 サブスクライバDASユーザー編集グループの特性

特性

説明

デフォルトACP

デフォルトのアイデンティティ管理レルムの「ユーザー」コンテナにあるACLにより、レルムのOracleコンテキストのサブスクライバDASユーザー編集グループは、ユーザーの各種属性を変更できます。

管理者

Oracle Internet Directoryスーパーユーザー

Oracleコンテキスト管理者グループのメンバー。

ユーザー権限割当てグループのメンバー。

DAS管理者グループのメンバー。

このグループの所有者。

DN

cn=OracleDASEditUser,cn=Groups,Oracle_Context_DN

32.2.2.3 ユーザーの削除

レルムでユーザーを削除するには、管理者はDASユーザー削除グループのメンバーである必要があります。表32-5に、このグループの特性を示します。

表32-5 DASユーザー削除グループの特性

特性

説明

デフォルトACP

デフォルトのアイデンティティ管理レルムの「ユーザー」コンテナにあるACLにより、レルムのOracleコンテキストのDASユーザー削除グループは、レルムからユーザーを削除できます。

管理者

Oracle Internet Directoryスーパーユーザー

Oracleコンテキスト管理者グループのメンバー。

ユーザー権限割当てグループのメンバー。

DAS管理者グループのメンバー。

このグループの所有者。

DN

cn=OracleDASDeleteUser,cn=Groups,Oracle_Context_DN

32.2.2.4 ユーザー管理の委任

委任管理者は、ディレクトリで指定された操作を実行できます。また、前述のユーザー作成、ユーザー編集、ユーザー削除の各グループにユーザーを追加する権限を必要とします。

委任管理者にユーザー管理権限を付与するには、付与する管理者がユーザー権限割当てグループのメンバーである必要があります。表32-6に、このグループの特性を示します。

表32-6 ユーザー権限割当てグループの特性

特性

説明

デフォルトACP

前述の各グループのACLポリシーにより、ユーザー権限割当てグループのメンバーは、これらのグループでユーザーを追加または削除することができます。

管理者

Oracle Internet Directoryスーパーユーザー

Oracleコンテキスト管理者グループ

このグループの所有者。これらの所有者の識別名は、グループのowner属性の値として表示されます。

DN

cn=OracleDASUserPriv,cn=Groups,Oracle_Context_DN

32.2.3 グループ・データを管理するためのデフォルトの権限

ユーザーとグループの管理には、次の権限が含まれます。

- グループ・エントリを作成および削除する権限

- グループ属性を変更する権限

- グループ管理を他のユーザーに委任する権限

グループを作成するためのACPは、アイデンティティ管理レルムの「グループ」コンテナにあります。

32.2.3.1 グループの作成

Oracle Internet Directoryでグループを作成するには、管理者はグループ作成グループのメンバーである必要があります。表32-7に、このグループの特性を示します。

表32-7 グループ作成グループの特性

特性

説明

デフォルトACP

レルムの「グループ」コンテナにあるACLにより、グループ作成グループは、レルムで新規グループを追加できます。

管理者

Oracle Internet Directoryスーパーユーザー

Oracleコンテキスト管理者グループのメンバー。

Oracle Fusion Middleware管理者グループのメンバー

グループ権限割当てグループのメンバー。

DAS管理者グループのメンバー。

このグループの所有者。

DN

cn=OracleDASCreateGroup,cn=Groups,Oracle_Context_DN

32.2.3.2 グループ属性の変更

レルムの「グループ」コンテナの下のグループ属性を変更するには、管理者はグループ編集グループのメンバーである必要があります。表32-8に、このグループの特性を示します。

表32-8 グループ編集グループの特性

特性

説明

デフォルトACP

レルムの「グループ」コンテナにあるACLにより、グループ編集グループは、レルムでグループの各種属性を変更できます。

管理者

Oracle Internet Directoryスーパーユーザー

Oracleコンテキスト管理者グループのメンバー。

Oracle Fusion Middleware管理者グループのメンバー

グループ権限割当てグループのメンバー。

DAS管理者グループのメンバー。

このグループの所有者。

DN

cn=OracleDASEditGroup,cn=Groups,Oracle_Context_DN

32.2.3.3 グループの削除

グループを削除するには、管理者はグループ削除グループのメンバーであることが必要です。表32-9に、このグループの特性を示します。

表32-9 グループ削除グループの特性

特性

説明

デフォルトACP

レルムの「グループ」コンテナにあるACLにより、グループ削除グループは、レルムでグループを削除できます。

管理者

Oracle Internet Directoryスーパーユーザー

Oracleコンテキスト管理者グループのメンバー。

グループ権限割当てグループのメンバー。

DAS管理者グループのメンバー。

このグループの所有者。

DN

cn=OracleDASDeleteGroup,cn=Groups,Oracle_Context_DN

32.2.3.4 グループ管理の委任

グループの管理を他のユーザーに委任する(つまり、前述のグループ作成、グループ編集またはグループ削除の各グループでユーザーを追加または削除する)には、管理者はグループ権限割当てグループのメンバーである必要があります。表32-10に、このグループの特性を示します。

表32-10 グループ権限割当てグループの特性

特性

説明

デフォルトACP

グループ作成、グループ編集、グループ削除の各グループのACLポリシーにより、グループ権限割当てグループのメンバーは、これらのグループでユーザーを追加または削除することができます。

管理者

Oracle Internet Directoryスーパーユーザー

Oracleコンテキスト管理者グループのメンバー。

グループの所有者。これらの所有者の識別名は、グループのowner属性の値として表示されます。

DN

cn=OracleDASUserPriv,cn=Groups,Oracle_Context_DN

32.3 Oracleコンポーネントのデプロイメント権限の委任

この項では、Oracleコンポーネントのデプロイを担当するグループについて説明します。管理者が実行するタスクおよび管理者が付与できる権限について説明します。内容は次のとおりです。

- 第32.3.1項「デプロイメント権限の付与方法」

- 第32.3.2項「Oracle Application Server管理者」

- 第32.3.3項「ユーザー管理アプリケーション管理者」

- 第32.3.4項「トラステッド・アプリケーション管理者」

注意:
Oracle Internet Directoryスーパーユーザーは、Oracle Fusion Middleware管理者およびトラステッド・アプリケーション管理者のすべての権限を持ちます。また、Oracle Fusion Middleware管理者グループのメンバーである必要があります。スーパーユーザーは、次を実行できます。

- ユーザーに対するOracle Fusion Middleware管理者ロールの割当て

- ユーザーに対するトラステッド・アプリケーション・ロールの割当て

- ユーザーに対するユーザー管理アプリケーション管理者ロールの割当て

32.3.1 デプロイメント権限の付与方法

管理者がOracleコンポーネントをデプロイできるようにするには、スーパーユーザーは次の手順を実行します。

1. 特定のデプロイメント権限をOracle Fusion Middleware管理者グループなどの様々なグループに付与します。

2. 管理者をこれらの権限グループに追加します。

一方、委任管理者は、権限を他の管理者に委任できます。

32.3.2 Oracle Application Server管理者

表32-11に、Oracle Application Server管理者グループの特性を示します。

表32-11Oracle Application Server管理者グループの特性

特性

説明

タスク

ディレクトリでリポジトリ・データベース登録エントリを作成する、リポジトリ・データベースのインストールの実行。

中間層インストールの実行。中間層をリポジトリと関連付けるには、ユーザーは特定のリポジトリ・データベースでの適切な権限が必要です。

Oracle Internet Directoryでアプリケーション・エンティティを作成する、Oracle Fusion Middlewareコンポーネントのインストールと構成。

この項で後述するリストに示す実行時権限のコンポーネント・エンティティへの付与。

コンポーネントが更新通知を受信できるようにするための、コンポーネントに対するプロビジョニング・プロファイルの構成。

このグループがコンポーネントに委任できる権限

パスワード、証明書および類似のセキュリティ資格証明以外の一般ユーザー属性を読み取る権限。

一般グループ属性を読み取る権限。

グループを作成、編集および削除する権限。

ユーザーを認証する権限。

アプリケーション・ベリファイアを読み取る権限。

管理者

Oracle Internet Directoryスーパーユーザー

Oracleコンテキスト管理者。

このグループの所有者。

DN

cn=iASAdmins,cn=Groups,Oracle_Context_DN

32.3.3 ユーザー管理アプリケーション管理者

ユーザー管理アプリケーション管理者は、Oracle Fusion Middleware管理者グループのメンバーである必要があります。

表32-12に、ユーザー管理アプリケーション管理者グループの特性を示します。

表32-12ユーザー管理アプリケーション管理者グループの特性

特性

説明

タスク

ユーザー管理アプリケーション管理者は、ユーザー管理操作を実行するためのインタフェースを持つ特定のアプリケーションをインストールします。たとえば、Oracle PortalやOracle Application Server Wirelessなどです。

このグループがコンポーネントに委任できる権限

ユーザー属性を作成、編集および削除する権限。

管理者

Oracle Internet Directoryスーパーユーザー

Oracleコンテキスト管理者。

このグループの所有者。

DN

cn=IAS&UserMgmtApplicationAdmins,cn=Groups,Oracle_Context_DN

32.3.4 トラステッド・アプリケーション管理者

トラステッド・アプリケーション管理者は、Oracle Fusion Middleware管理者グループのメンバーである必要があります。

表32-13に、トラステッド・アプリケーション管理者グループの特性を示します。

表32-13トラステッド・アプリケーション管理者グループの特性

特性

説明

タスク

Oracle Single Sign-On、Oracle Delegated Administration Services、Oracle Application Server Certificate Authorityなど、特定のアイデンティティ管理コンポーネントをインストールします。

このグループがコンポーネントに委任できる権限

ユーザー・パスワードの読取り、比較、再設定を行う権限。

エンド・ユーザーのプロキシとなる権限。

ユーザーの証明書とSMIME証明書の読取り、比較、変更を行う権限。

管理者

Oracle Internet Directoryスーパーユーザー

Oracleコンテキスト管理者。

このグループの所有者。

DN

cn=TrustedApplicationsAdmins,cn=Groups,Oracle_Context_DN

32.4 コンポーネントの実行時権限の委任

多くのOracleコンポーネントでは、Oracle Internet Directoryでユーザー・エントリが管理されているため、それに対応する権限が必要です。次に例を示します。

- Oracle Single Sign-On Serverがユーザーを認証する場合、そのサーバーには次の権限が必要です。

- 独自のアイデンティティを使用してOracle Internet Directoryに接続する権限

- ユーザーの入力したパスワードが、ディレクトリに格納されているそのユーザーのパスワードと一致するかどうかを検証する権限

このため、Oracle Single Sign-On Serverはユーザー・パスワードを比較する権限が必要です。Oracle Single Sign-OnのCookieを設定するには、ユーザー属性を読み取る権限が必要です。

- アクセス権をユーザーに付与するために、Oracle Portalはそのユーザーの属性を取得する必要があります。このために、プロキシ・ユーザーとしてOracle Internet Directoryにログインし、アクセスを要求しているユーザーの代理となります。したがって、プロキシ・ユーザーの権限を必要とします。

通常、Oracleコンポーネントでは、次の権限が必要となる場合があります。

- ユーザー・パスワードの読取りと変更を行う権限

- ユーザー・パスワードの比較を行う権限

- アプリケーションにアクセスするユーザーのプロキシとなる権限

- すべてのOracleコンポーネントのメタデータが格納されるOracleコンテキストを管理する権限

ほとんどのOracleコンポーネントは、権限が事前構成された状態で出荷されます。これらのデフォルトの権限は、特定のビジネス要件を満たすために変更できます。たとえば、ユーザー・エントリを作成および削除する権限を削除することにより変更できます。

関連項目:
コンポーネント委任モデルの詳細は、10g(10.1.4.0.1)ライブラリの『Oracle Application Serverセキュリティ・ガイド』を参照してください。

この項では、Oracleコンポーネントに必要なセキュリティ権限について説明します。この項の内容は、次のとおりです。

- 第32.4.1項「ユーザー・パスワードの読取りおよび変更を行うためのデフォルトの権限」

- 第32.4.2項「ユーザー・パスワードを比較するためのデフォルトの権限」

- 第32.4.3項「パスワード・ベリファイアを比較するためのデフォルトの権限」

- 第32.4.4項「エンド・ユーザーのプロキシとなるためのデフォルトの権限」

- 第32.4.5項「Oracleコンテキストを管理するためのデフォルトの権限」

- 第32.4.6項「共通ユーザー属性を読み取るためのデフォルトの権限」

- 第32.4.7項「共通グループ属性を読み取るためのデフォルトの権限」

- 第32.4.8項「サービス・レジストリを読み取るためのデフォルトの権限」

- 第32.4.9項「サービス・レジストリを管理するためのデフォルトの権限」

32.4.1 ユーザー・パスワードの読取りおよび変更を行うためのデフォルトの権限

ユーザー・パスワードの読取りおよび変更には、ディレクトリのセキュリティ関連の属性(userPassword属性など)に対する管理権限が必要です。ユーザー・セキュリティ管理者グループのメンバーシップが必要になります(表32-14を参照)。

表32-14 ユーザー・セキュリティ管理者グループの特性

特性

説明

デフォルトACP

ルート(DSEエントリ)でのデフォルトのACLポリシーにより、ユーザー・セキュリティ管理者グループのメンバーは、ルートOracleコンテキストでuserpkcs12、orclpkcs12hint、userpassword、orclpasswordおよびorclpasswordverifierの各属性の読取り、書込み、比較および検索を行えます。ただし、ディレクトリ管理者は、レルムのOracleコンテキストのユーザー・セキュリティ管理者グループに同様の管理権限を付与することができます。

管理者

Oracle Internet Directoryスーパーユーザー

Oracleコンテキスト管理者グループのメンバー。

トラステッド・アプリケーション管理者グループのメンバー。

DN

cn=OracleUserSecurityAdmins,cn=Groups,Oracle_Context_DN

32.4.2 ユーザー・パスワードを比較するためのデフォルトの権限

ユーザー・パスワードの比較には、ユーザーのuserPassword属性を比較する権限が必要です。この操作は、Oracle Internet Directoryに格納されたパスワードを使用してエンド・ユーザーを認証するOracle Unified Messagingのようなコンポーネントにより実行されます。

ユーザー・パスワードを比較するには、表32-15に示す認証サービス・グループのメンバーである必要があります。

表32-15認証サービス・グループの特性

特性

説明

デフォルトACP

デフォルトのアイデンティティ管理レルムの「ユーザー」コンテナにあるACLポリシーにより、認証サービス・グループは、ユーザーのuserPassword属性に対する比較操作を実行できます。

管理者

Oracle Internet Directoryスーパーユーザー

Oracleコンテキスト管理者グループのメンバー。

アプリケーション・サーバー管理者グループのメンバー。

このグループの所有者。

DN

cn=authenticationServices,cn=Groups,Oracle_Context_DN

32.4.3 パスワード・ベリファイアを比較するためのデフォルトの権限

パスワード・ベリファイアを比較するには、userpassword属性を比較する権限が必要です。パスワード・ベリファイアを比較するには、表32-16に示すベリファイア・サービス・グループのメンバーである必要があります。

表32-16ベリファイア・サービス・グループの特性

特性

説明

管理者

Oracle Internet Directoryスーパーユーザー

Oracleコンテキスト管理者グループのメンバー。

アプリケーション・サーバー管理者グループのメンバー。

このグループの所有者。

DN

cn=verifierServices,cn=Groups,Oracle_Context_DN

32.4.4 エンド・ユーザーのプロキシとなるためのデフォルトの権限

プロキシ・ユーザーは、エンド・ユーザーの代理となる権限を持ち、そのユーザーが権限を持つ操作をユーザーにかわって実行します。Oracle Fusion Middleware環境では、Oracle Delegated Administration Servicesがエンド・ユーザーのプロキシとなり、Oracle Internet Directory Self-Service Consoleを通じて、そのユーザーのかわりに操作を実行します。そのような場合、ディレクトリ・サーバーに対するアクセス制御がユーザーの実行できる操作を実質的に制御します。

エンド・ユーザーのプロキシとなるには、表32-17に示すユーザー・プロキシ権限グループのメンバーである必要があります。

表32-17ユーザー・プロキシ権限グループの特性

特性

説明

デフォルトACP

デフォルトのアイデンティティ管理レルムの「ユーザー」コンテナでのACLポリシーにより、ユーザー・プロキシ権限グループは、エンド・ユーザーのプロキシとなることができます。

管理者

Oracle Internet Directoryスーパーユーザー

Oracleコンテキスト管理者グループのメンバー。

グループの所有者。これらの所有者の識別名は、Oracle Fusion Middleware管理者グループのグループまたはメンバーのowner属性の値として表示されます。

トラステッド・アプリケーション管理者グループのメンバー。

DN

cn=UserProxyPrivilege,cn=Groups,Oracle_Context_DN

32.4.5 Oracleコンテキストを管理するためのデフォルトの権限

特定のOracleコンテキストを管理するには、そのコンテキストへの完全なアクセス権が必要です。Oracleコンテキストを管理するには、表32-18に示すOracleコンテキスト管理者グループのメンバーである必要があります。Oracleコンテキスト管理者グループは、Oracleコンテキストごとに存在し、特定のOracleコンテキストでの管理権限を持ちます。

表32-18Oracleコンテキスト管理者グループの特性

特性

説明

デフォルトACP

Oracleコンテキストのルート・ノードにあるACLポリシーにより、Oracleコンテキスト管理者グループは、Oracleコンテキスト内ですべての管理操作を実行できます。そのようなポリシーは、ディレクトリで新しいOracleコンテキストが作成されるときに設定されます。

管理者

Oracle Internet Directoryスーパーユーザー

Oracleコンテキスト管理者グループのメンバー。

DN

cn=OracleContextAdmins,cn=Groups,Oracle_Context_DN

32.4.6 共通ユーザー属性を読み取るためのデフォルトの権限

共通ユーザー属性には、mail、orclguid、displayname、preferredlanguage、orcltime、gender、dateofbirth、telephonenumberおよびwirelessaccountnumberがあります。これらの属性を読み取るには、表32-19に示す共通ユーザー属性グループのメンバーである必要があります。

表32-19共通ユーザー属性グループの特性

特性

説明

デフォルトACP

デフォルトACLは、レルム内の「ユーザー」コンテナ上にあり、共通ユーザー属性を読み取る権限を付与します。

管理者

Oracle Internet Directoryスーパーユーザー

アプリケーション・サーバー管理者グループのメンバー。

このグループの所有者。

DN

cn=CommonUserAttributes,cn=Groups,Oracle_Context_DN

32.4.7 共通グループ属性を読み取るためのデフォルトの権限

共通グループ属性には、cn、uniquemember、displaynameおよびdescriptionがあります。これらの属性を読み取るには、表32-20に示す共通グループ属性グループのメンバーである必要があります。

表32-20共通グループ属性グループの特性

特性

説明

デフォルトACP

デフォルトACLは、レルム内の「グループ」コンテナ上にあり、cn、uniquemember、displaynameおよびdescription属性を読み取る権限を付与します。

管理者

Oracle Internet Directoryスーパーユーザー

アプリケーション・サーバー管理者グループのメンバー。

このグループの所有者。

DN

cn=CommonGroupAttributes,cn=Groups,Oracle_Context_DN

32.4.8 サービス・レジストリを読み取るためのデフォルトの権限

サービス・レジストリのコンテンツを表示するには、表32-21に示すサービス・レジストリのビューア・グループのメンバーである必要があります。

表32-21サービス・レジストリのビューア・グループの特性

特性

説明

デフォルトACP

デフォルトのACLは、ルートOracleコンテキストの「サービス」コンテナにあります。

管理者

Oracle Internet Directoryスーパーユーザー

アプリケーション・サーバー管理者グループのメンバー。

このグループの所有者。

DN

cn=Service Registry Viewers,cn=Groups,cn=OracleContext

32.4.9 サービス・レジストリを管理するためのデフォルトの権限

サービス・レジストリを管理するには、表32-22に示すサービス・レジストリの管理グループのメンバーである必要があります。

表32-22共通グループ属性グループの特性

特性

説明

デフォルトACP

デフォルトのACLは、ルートOracleコンテキストの「サービス」コンテナにあります。

管理者

Oracle Internet Directoryスーパーユーザー

アプリケーション・サーバー管理者グループのメンバー。

このグループの所有者。

DN

cn=Service Registry Admins,cn=Groups,cn=OracleContext

33 認証の管理

この章では、直接認証、間接認証、外部認証、Simple Authentication and Security Layer (SASL)、匿名バインドなど、Oracle Internet Directoryの認証機能の概要について説明します。具体的には、Oracle Enterprise Manager Fusion Middleware ControlおよびLDAPコマンド行ツールを使用して認証を管理する方法について説明します。

この章の内容は次のとおりです。

- 第33.1項「認証の概要」

- 第33.2項「Fusion Middleware Controlを使用した証明書認証方式の構成」

- 第33.3項「Fusion Middleware Controlを使用したSASL認証の構成」

- 第33.4項「コマンド行ツールを使用した証明書認証方式の構成」

- 第33.5項「コマンド行を使用したSASL認証の構成」

- 第33.6項「匿名バインドの概要」

- 第33.7項「匿名バインドの管理」

- 第33.8項「Oracle Internet Directoryサーバーに対するユーザーのバインドの制限」

- 第33.9項「未認証バインドの管理」

33.1 認証の概要

認証は、ディレクトリ・サーバーが、そのディレクトリに接続しているユーザーの本当のアイデンティティを確定するプロセスです。LDAPセッションがバインド操作によって確立されたときに行われます。このようにして、すべてのセッションにユーザー・アイデンティティが関連付けられます。

ユーザー、ホストおよびクライアントのアイデンティティを検証するために、Oracle Internet Directoryでは、3種類の一般的な認証を使用できます。それらについて、次の項目で説明します。

- 第33.1.1項「直接認証」

- 第33.1.2項「間接認証」

- 第33.1.3項「外部認証」

- 第33.1.4項「Simple Authentication and Security Layer(SASL)を使用した認証」

33.1.1 直接認証

この項では、Oracle Internet Directory内で使用可能な3種類の直接認証と、SASL対応クライアントがディレクトリ・サーバーに対して認証を行う方法について説明します。直接認証オプションには、次の3種類があります。

- 匿名認証
匿名で認証する場合、ユーザーは、ユーザー名とパスワードのフィールドを空白のままにしてログインします。各匿名ユーザーは、匿名ユーザーに付与されている権限すべてを使用できます。

- 簡易認証

簡易認証を使用する場合、クライアントは、ネットワーク上を暗号化されずに送信される識別名とパスワードによって、サーバーに対して自己認証を行います。

- Simple Authentication and Security Layer (SASL)を使用した認証

これは接続ベースのプロトコルに認証サポートを追加する方法です。SASLを使用するために、プロトコルには、ユーザーを識別してサーバーに対して認証を行い、オプションで、以降のプロトコル対話の保護を規定するコマンドが含まれます。SASLを使用して、ネゴシエーションに成功すると、セキュリティ・レイヤーがプロトコルおよび接続の間に挿入されます。

Oracle Internet Directoryは、SASLを使用する2種類の認証メカニズムをサポートします。

- ダイジェストMD5: LDAPバージョン3内では必須の認証メカニズムです(RFC 2829)。MD5ハッシュ関数を使用して、任意の長さのメッセージを、クライアント/サーバー認証のベリファイアとして使用できる128ビットのメッセージ・ダイジェストに変換します。

- 外部認証: SSL相互認証を使用するメカニズム。この場合、クライアントは、ユーザー名とパスワードを使用するかわりに、証明書、トークンまたは他のデバイスによって、サーバーに対して認証します。証明書による認証には、次の形式があります。

- 完全一致: クライアント証明書内のサブジェクトDNが、ディレクトリ内のユーザーDNと比較されます。この2つの値が一致すると、バインドが行われます。

- 証明書ハッシュ: クライアント証明書がハッシュ処理され、ディレクトリ内に保管されている証明書のハッシュ値と比較されます。この2つの値が一致し、かつこのペアに関連付けられているDNが1つのみの場合は、バインドが行われます。複数のDNが関連付けられている場合は、証明書ハッシュとユーザーDNの関係はn対1の対応であり1対nの対応ではないので、エラーが返されます。つまり、1つのDNには複数の証明書を関連付けることができますが、1つの証明書には1つのDNしか関連付けられません。

- 完全一致/証明書ハッシュ: まず、完全一致検索が行われます。一致するものがない場合は、証明書ハッシュが実行されます。

これらの方法のいずれかを選択するには、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のOracle Identity ManagementのLDAP属性リファレンスに関する項で指示されているDSA構成属性orclpkimatchingruleを編集します。(認証の場合、orclpkimatchingruleの値3または4が値2に等しくなります)。

注意:

- 10g(10.1.4.0.1)に証明書のハッシュ値を導入する場合は、ユーザー証明書を旧リリースからアップグレードする必要があります。証明書をアップグレードする方法の詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のupgradecert.plコマンド行ツールのリファレンスを参照してください。

- バイナリ属性usercertificateを検索できます。検索方法については、付録K「ディレクトリでのユーザー証明書の検索」を参照してください。

- usercertificate属性は、DER書式の証明書の格納のみを目的としています。

関連項目:

- 第33.1.4項「Simple Authentication and Security Layer(SASL)を使用した認証」

- http://www.ietf.orgにあるInternet Engineering Task Force(IETF)のWebサイトで、RFC 2829(LDAPバージョン3サーバーで必要な認証メカニズムとしてのSASL MD5ダイジェストを指定)、RFC 2831(MD5ダイジェストメカニズムの説明)、RFC 2617(SASL MD5ダイジェストがベースとしているHTTP Digest認証メカニズムの説明)の各RFCを参照してください。

33.1.2 間接認証

間接認証は、ディレクトリに資格証明を保持するエンティティ(Oracle Internet Directoryセルフサービス・コンソールのようなアプリケーション、ファイアウォールやRADIUSサーバーのような中間層など)を介して行われます。アプリケーションや中間層は、プロキシ・ユーザーとなります。プロキシ・ユーザーは、エンド・ユーザーの代理となる権限を持ち、そのユーザーが権限を持つ操作をユーザーにかわって実行します。

図33-1および図に続く説明は、間接認証がどのように実行されるかを示しています。

図33-1 間接認証

間接認証は、次の手順で行われます。

1. エンド・ユーザーが、Oracle Internet Directoryへの問合せを含むリクエストをアプリケーションまたは中間層に送信します。アプリケーションまたは中間層がエンド・ユーザーを認証します。

2. アプリケーションまたは中間層がディレクトリにバインドします。

3. アプリケーションまたは中間層は、エンド・ユーザーの識別名を使用して、2回目のバインドを実行します。この場合、エンド・ユーザーのパスワードは入力しません。

4. ディレクトリ・サーバーは、アプリケーションまたは中間層がエンド・ユーザーのアイデンティティに切り替えようとしているものとして、この2回目のバインドを認識します。アプリケーションまたは中間層によってエンド・ユーザーに付与された認証を受け入れます。ただし、アプリケーションまたは中間層に、このユーザーのプロキシとなる権限があるかどうかを検証する必要があります。エンド・ユーザーのエントリを管理するACPによって、このエンド・ユーザーに対するプロキシ権限がこのアプリケーションまたは中間層に付与されているかどうかをチェックします。

- エンド・ユーザーのエントリにより、アプリケーションまたは中間層に必要なプロキシ権限が提供された場合、ディレクトリ・サーバーは、認可アイデンティティをエンド・ユーザーのものに変更します。後続するすべての操作は、そのエンド・ユーザーがサーバーに直接接続して直接認証された場合と同様に行われます。

- エンド・ユーザーのエントリが、アプリケーションまたは中間層に必要なプロキシ権限を提供しない場合、ディレクトリ・サーバーは、「アクセス権限が不十分です。」というエラー・メッセージを返します。

関連項目:
第30.1.2.3項「操作: 付与するアクセス権の種類」

ディレクトリ・サーバーは同一セッションで、その他のエンド・ユーザーを認証および許可できます。また、セッションをエンド・ユーザーから、そのセッションをオープンしたアプリケーションまたは中間層に切り替えることもできます。

セッションをクローズするには、アプリケーションまたは中間層がバインド解除リクエストをディレクトリ・サーバーに送信します。

たとえば、次の場合を想定します。

- cn=User1でディレクトリにバインドする中間層には、ディレクトリ全体に対するプロキシ・アクセス権限があります。

- cn=User2でディレクトリにバインドできるエンド・ユーザーがいます。

このエンド・ユーザーが、ディレクトリに対する問合せが含まれているリクエストをアプリケーションまたは中間層に送信すると、アプリケーションまたは中間層がエンド・ユーザーを認証します。その後、中間層サービスは、そのサービスのアイデンティティであるcn=User1を使用してディレクトリにバインドし、次に、エンド・ユーザーの識別名cn=User2のみを使用して2回目のバインドを実行します。この2回目のバインドは、Oracleディレクトリ・サーバーでは、プロキシ・ユーザーがエンド・ユーザーの代理になろうとしているものと認識されます。ディレクトリ・サーバーは、cn=user1にプロキシ・アクセス権限があることを確認した後、この2回目のバインドの実行を許可します。パスワードなど、エンド・ユーザー識別名の妥当性をさらに要求することはありません。このセッションでは、これ以降すべてのLDAP操作は、cn=User2が実行しているかのようにアクセス制御されます。

あるユーザーがアプリケーションからサービスを受け、続いて別のユーザーが同じアプリケーションのサービスをリクエストした場合、アプリケーションは、先行ユーザーのセッションを中断せずに、新規接続を確立して前述のとおりに処理を進めることができます。ただし、まだサービスを受けている先行ユーザーがいない場合は、新しい接続を確立することなく、既存の確立済接続を何度も使用できます。

33.1.3 外部認証

多くの企業では、ユーザー・セキュリティ資格証明をOracle Internet Directory以外のリポジトリ(データベースや他のLDAPディレクトリなど)に格納しています。Oracle Internet Directoryの外部認証プラグインとパスワード変更プラグインにより、ユーザー認証用のこれらの資格証明をOracleコンポーネントに対して使用できます。資格証明をOracle Internet Directoryに格納する必要はなく、常に同期化させる必要はありません。

関連項目:
第46章「カスタマイズされた外部認証プラグインの構成」

33.1.4 Simple Authentication and Security Layer(SASL)

「直接認証」の項では、Oracle Internet Directory環境でのSASLの使用について説明しました。この項では、SASLの動作について詳細に説明します。この項の内容は、次のとおりです。

- 第33.1.4.1項「SASL対応クライアントがMD5ダイジェストを使用してディレクトリ・サーバーに対して認証する方法」

- 第33.1.4.2項「SASL対応クライアントが外部認証を使用してディレクトリ・サーバーに対して認証する方法」

33.1.4.1 SASL対応クライアントがMD5ダイジェストを使用してディレクトリ・サーバーに対して認証する方法

注意:
SASL MD5ダイジェストをレルムとともに使用するには、SASLで動的ユーザー検証機能を作成する必要があります。可逆的なパスワード生成を有効にする必要があります。詳細は、Oracle Fusion Middleware Oracle Identity Managementアプリケーション開発者ガイドのMD5ダイジェストを使用したSASL認証に関する項を参照してください。

SASL対応クライアントがサーバーに対してMD5ダイジェスト認証を求める場合、その認証プロセスは次のとおりです。

1. ディレクトリ・サーバーは、サポートする各種MD5ダイジェスト認証オプションと特別なトークンを含むダイジェスト・チャレンジをLDAPクライアントに送信します。

2. クライアントは、認証オプションを選択し、選択したオプションを示すダイジェスト・レスポンスをサーバーに送信します。このレスポンスには、セキュアなトークンとクライアント資格証明が暗号化されて含まれます。このようして、サーバーに対するクライアントの認証を実行できます。

3. ディレクトリ・サーバーは、レスポンスのクライアント資格証明を復号化し、検証します。

33.1.4.2 SASL対応クライアントが外部認証を使用してディレクトリ・サーバーに対して認証する方法

Oracle Internet Directoryでは、クライアントおよびサーバーの両方が相互に証明書を提供して認証するSSL接続を介してSASL外部認証を提供します。識別名は、SSLネットワーク・ネゴシエーションで使用されたクライアント証明書から作成されます。

クライアントが、SSLのような外部認証メカニズムを使用してディレクトリ・サーバーに認証を求める場合、その認証プロセスは次のとおりです。

1. クライアントは、認可アイデンティティの入った初期メッセージを送信します。

2. ディレクトリ・サーバーは、SASLの外部にある情報を使用して、クライアントが認可アイデンティティとして正当に認証できるかどうかを判断します。クライアントを確実に認証できた場合、ディレクトリ・サーバーは認証情報の交換が無事完了したことを示します。そうでない場合、ディレクトリ・サーバーは失敗を示します。

外部情報は、IPsecやSSL/TLSなどのシステムにより提供されます。認可アイデンティティは、次のようにして得られます。

- 完全一致の場合は、外部認証を提供するシステムのクライアント認証資格証明(クライアントSSL証明書など)から認可アイデンティティが作成されます。

- クライアントが認可アイデンティティとして空の文字列を送信した場合、認可アイデンティティは外部認証を提供するシステムのクライアント認証資格証明(SSL証明書など)から作成されます。

33.2 Fusion Middleware Controlを使用した証明書認証方式の構成

証明書認証に使用される方式を決定するDSA構成属性orclPKIMatchingRuleの値を構成するには、Oracle Enterprise Manager Fusion Middleware ControlのOracle Internet Directoryの「共有プロパティ」ページを使用します。「Oracle Internet Directory」メニューから「管理」を選択し、「共有プロパティ」を選択します。「PKI一致ルール」のリストから目的の一致方式を選択します。

33.3 Fusion Middleware Controlを使用したSASL認証の構成

Oracle Enterprise Manager Fusion Middleware Controlを使用してSASL認証を構成する手順は、次のとおりです。

1. 「Oracle Internet Directory」メニューから「管理」を選択し、「サーバー・プロパティ」を選択してから、「SASL」を選択します。

2. 「MD5 SASL認証モード」について目的のタイプを選択します。

3. 「完全性とプライバシ保護での認証」を選択すると、「プライバシ保護のためのSASL暗号選択」の選択肢が表示されます。目的のタイプを選択します。
選択肢は、rc4-56、des、3des、rc4およびrc4-40です。デフォルトでは、5つがすべて有効になっています。少なくともdesおよび3desを構成する必要があります。これを行わないと、SASL認証が失敗します。

4. 必要に応じて、「SASL認証の有効化」を選択します。SASL認証を有効にする前に、相互認証を実行するようOracle Internet Directoryが構成されていることを確認します。第27.2項「Fusion Middleware Controlを使用したSSLの構成」を参照してください。

5. 「適用」を選択します。
表33-1に示すように、「SASL」タブで属性を変更した後、サーバーを再起動します。

表33-1 「サーバー・プロパティ」、「SASL」タブの構成属性

フィールドまたはヘッダー

構成属性

MD5 SASL認証モード

orclsaslauthenticationmode

プライバシ保護のためのSASL暗号選択

orclsaslcipherchoice

外部SASL認証モード

orclsaslmechanism

33.4 コマンド行ツールを使用した証明書認証方式の構成

証明書認証に使用される方式を決定するDSA構成属性orclPKIMatchingRuleの値を構成するには、ldapmodifyを使用しますが、この場合、次のようなコマンド行を使用します。

ldapmodify -D cn=orcladmin -q -p portNum -h hostname -f ldifFile

これとあわせて、次のようなLDIFファイルを使用します。

dn: cn=dsaconfig, cn=configsets, cn=oracle internet directory
changetype: modify
replace: orclPKIMatchingRule
orclPKIMatchingRule: 1

値は次のとおりです。

- 0 - 完全一致。PKI証明書の識別名が、ユーザーが入力した識別名と一致する必要があります。

- 1 - 証明書検索。ユーザーがOracle Internet DirectoryにプロビジョニングされているPKI証明書を持っているかどうかをチェックします。

- 2 - 完全一致と証明書検索の組合せ。完全一致しなかった場合、証明書検索が実行されます。

- 3 - マッピング・ルールのみ。マッピング・ルールを使用して、ユーザーのPKI証明書識別名をOracle Internet Directoryの証明書識別名にマップします。

- 4: 1(マッピング・ルール)、2(証明書検索)、3(完全一致)の順に試行します。

33.5 コマンド行を使用したSASL認証の構成

表33-2に、SASL認証属性を示します。これらは、インスタンス固有の構成エントリにあります。

表33-2 SASL認証属性

属性

説明

デフォルト

使用可能な値

orclsaslauthenticationmode

SASL認証モード

1

auth、auth-int、auth-conf。

orclsaslcipherchoice

SASL暗号選択

Rc4-56、rc4-40、rc4、des、3des

Rc4-56、des、3des、rc4、rc4-40の任意の組合せ

orclsaslmechanism

SASLメカニズム

DIGEST-MD5、EXTERNAL

DIGEST-MD5、EXTERNAL

「MD5 SASL認証モード」は、orclsaslauthenticationmode属性によって制御されます。表33-3に、使用できるモードを示します。3つの値すべて、あるいは値のサブセットをカンマ区切りの文字列で指定します。

表33-3 SASL認証モード

orclsaslauthenticationmodeの値

モード

説明

1

auth

認証のみ。

2

auth-int

完全性保護での認証。チャネルでチェックサムが実行されます。

3

auth-conf

完全性保護での認証と暗号化。チャネルは暗号化されます。

orclsaslauthenticationmodeを3(auth-conf)に設定した場合は、orclsaslcipherchoiceの値も選択する必要があります。選択肢は、rc4-56、des、3des、rc4およびrc4-40です。デフォルトでは、5つがすべて有効になっています。少なくともdesおよび3desを構成する必要があります。これを行わないと、SASL認証が失敗します。

変数orclsaslmechanismは、SASLでサポートされる認証メカニズムを制御します。値DIGEST-MD5およびEXTERNALは、デフォルトで設定されています。MD5ダイジェスト認証は、無効にしないでください。これは、LDAPバージョン3サーバーで必須の認証メカニズムです。外部認証は、ldapmodifyを使用して無効にできます。SSLクライアントおよびサーバー認証を実行するようにOracle Internet Directoryを構成しない場合は、外部認証を無効にしてください。

SASL属性を変更した後、サーバーを再起動します。

33.6 匿名ユーザーによるバインドの概要

匿名ユーザーによるバインドは、パスワードを使用せずに簡易認証を使用する方法です。デフォルトでは、ディレクトリ・サーバーは匿名バインドを許可しますが、匿名ユーザーのルートDSEエントリでの検索操作のみ許可します。すべての匿名バインドを許可するよう、あるいは匿名バインドを許可しないようサーバーを構成できます。この動作は、サーバー・インスタンス固有の構成エントリのorclanonymousbindsflag属性で制御します。表33-4に、orclanonymousbindsflagに指定可能な値と、ディレクトリ・サーバーの動作を示します。

表33-4 orclanonymousbindsflagの値とディレクトリ・サーバーの動作

orclAnonymousBindsFlagの値

ディレクトリ・サーバーの動作

0

匿名ユーザーによるバインドを禁止

1

匿名ユーザーによるバインドを許可。

2

匿名ユーザーによるバインドを許可。ただし、許可されるのは、匿名ユーザーのルートDSEエントリでの検索操作のみ(デフォルト)

33.7 匿名ユーザーによるバインドの管理

Oracle Internet Directory 11g リリース1(11.1.1)では匿名バインドがデフォルトで許可されますが、匿名ユーザーはルートDSEエントリでの検索操作のみ実行できます。Fusion Middleware Controlまたはコマンド行を使用して、匿名バインドに関するサーバーの動作を変更できます。

この項の内容は次のとおりです。

- 第33.7.1項「Fusion Middleware Controlを使用した匿名ユーザーによるバインドの管理」

- 第33.7.2項「コマンド行を使用した匿名ユーザーによるバインドの管理」

33.7.1 Fusion Middleware Controlを使用した匿名ユーザーによるバインドの管理

Oracle Enterprise Manager Fusion Middleware Controlを使用して匿名ユーザーによるバインドを管理するには、次の手順を実行します。

1. 「Oracle Internet Directory」メニューから「管理」を選択し、「サーバー・プロパティ」を選択してから、「一般」タブを選択します。

2. 「匿名バインド」リストから「許可」を選択して、匿名ユーザーによるバインドを有効にします。ルートDSEエントリに対する匿名ユーザーの検索操作のみを許可するには、「ルートDSEでの読取りアクセスを除いて使用できません」を選択します。

匿名ユーザーによるバインドを無効にするには、次の手順を実行します。

1. 「Oracle Internet Directory」メニューから「管理」を選択し、「サーバー・プロパティ」を選択してから、「一般」タブを選択します。

2. 「匿名バインド」リストから「拒否」を選択します。

33.7.2 コマンド行を使用した匿名ユーザーによるバインドの管理

ldapmodifyを使用して、コンポーネント名がoid1のOracle Internet Directoryインスタンスですべての匿名バインドを有効にするには、次のように入力します。

ldapmodify -D cn=orcladmin -q -p portNum -h hostname -f ldifFile

この場合、次のようなLDIFファイルを使用します。

dn: cn=oid1,cn=osdldapd,cn=subconfigsubentry
changetype: modify
replace: orclAnonymousBindsFlag
orclAnonymousBindsFlag: 1

すべての匿名バインドを無効にするには同様のLDIFファイルを使用しますが、最後の行を次のように変更します。

orclAnonymousBindsFlag: 0

関連項目:
第9.1.3項「インスタンス固有の構成エントリの属性」

33.8 Oracle Internet Directoryサーバーに対するユーザーのバインドの制限

Oracle Internet Directory 11gリリース1 (11.1.1.9.0)以降では、bindAuthPriv属性によって、Oracle Internet Directoryサーバーにバインド可能なユーザーを指定できます。サーバーにバインド可能なユーザーを指定する手順は、次のとおりです。

1. サーバーに対するバインドを許可するユーザーのみを含むディレクトリ・グループを作成します。

2. 手順1で作成したグループを指し示すようにbindAuthPriv属性を設定します。

3. サーバーに対するバインドを許可する各ユーザー(手順1のグループのメンバーであるユーザー)のユーザー・エントリにbindAuthPriv属性を追加します。

ユーザーがこのグループのメンバーではない場合、サーバーは、そのユーザーからの後続のバインド・リクエストを拒否します。

その他の考慮事項は、次のとおりです。

- bindAuthPriv属性には、特定のユーザーが属性を継承できる集合属性を指定できます。

- ディレクトリ・グループには、ネストされたグループを指定できます。

- 唯一の管理者のみがbindAuthPriv属性をユーザー・エントリに追加できるように、その適切なアクセス制御(ACL)を設定する必要があります。

関連項目:
Oracle Directory Services Manager (ODSM)またはLDAPコマンド行ツールを使用してユーザーとグループを作成および管理する方法の詳細は、次の項目を参照してください。

- 第13章「ディレクトリ・エントリの管理」

- 第14章「動的グループと静的グループの管理」

33.9 未認証バインドの管理

Oracle Internet Directoryでは、識別名の値(ユーザー識別名)を含み、パスワードを含まないバインド・リクエストを送信する未認証の認証メカニズムがサポートされます。

未認証バインドが許可される場合、バインド試行は、匿名バインドとして処理されます。

この項の内容は次のとおりです。

- 第33.9.1項「未認証バインドの構成」

- 第33.9.2項「コマンド行を使用した未認証バインドの管理」

33.9.1 未認証バインドの構成

orclunauthenticatedbindsflag属性によって、未認証バインドが成功するように設定できます。この属性を1に設定すると、未認証バインドが成功します。デフォルトでは、このパラメータは0に設定されています。

未認証バインドを構成するには、第33.9.2項「コマンド行を使用した未認証バインドの管理」を参照してください。

33.9.2 コマンド行を使用した未認証バインドの管理

ldapmodifyを使用して、コンポーネント名がoid1のOracle Internet Directoryインスタンスで未認証バインドを有効にするには、次のように入力します。

ldapmodify -D cn=orcladmin -q -p portNum -h hostname -f ldifFile

この場合、次のようなLDIFファイルを使用します。

dn: cn=oid1,cn=osdldapd,cn=subconfigsubentry
changetype: modify
replace: orclunauthenticatedbindsflag
orclunauthenticatedbindsflag: 1

未認証バインドを無効にするには同様のLDIFファイルを使用しますが、最後の行を次のように変更します。

orclunauthenticatedbindsflag: 0

第IV部

拡張管理: ディレクトリ・デプロイメントの管理

ここでは、デプロイメントに関する重要な考慮事項について説明します。次の各章で構成されています。

- 第34章「レルムの計画、デプロイおよび管理」

- 第35章「Oracle Internet Directoryのチューニングとサイズ設定」

- 第36章「ガベージ・コレクションの管理」

- 第37章「他のデータ・リポジトリからのデータの移行」

- 第38章「ディレクトリ・サーバー・チェーンの構成」

34 レルムの計画、デプロイおよび管理

この章では、Oracle Internet Directoryでのアイデンティティ管理レルムの実装について説明し、企業内デプロイメントとホスティングされたデプロイメント用のアイデンティティ管理レルムを計画、デプロイおよび管理する方法について説明します。

この章の内容は次のとおりです。

- 第34.1項「レルムの計画、デプロイおよび管理の概要」

- 第34.2項「デフォルトのアイデンティティ管理レルムのカスタマイズ」

- 第34.3項「ホスティングされたデプロイメントでのアイデンティティ管理レルムの追加作成」

- 第34.4項「DITビューの作成」

注意:
この章で言及するOracle Single Sign-Onはすべて、Oracle Single Sign-On 10g(10.1.4.3.0)以上のことです。

34.1 レルムの計画、デプロイおよび管理の概要

この概要の項目は次のとおりです。

- 第34.1.1項「アイデンティティ管理レルムの計画」

- 第34.1.2項「企業内デプロイメントにおけるアイデンティティ管理レルム」

- 第34.1.3項「ホスティングされたデプロイメントにおけるアイデンティティ管理レルム」

- 第34.1.4項「Oracle Internet Directoryでのアイデンティティ管理レルムの実装」

- 第34.1.5項「デフォルトのディレクトリ情報ツリーおよびアイデンティティ管理レルム」

34.1.1 アイデンティティ管理レルムの計画

第5章「Oracle Internet Directory編成の理解」では、DIT全体およびデプロイメント対象のユーザーとグループの配置を構成する場合のガイドラインを示しています。これらのガイドラインを実装すると、膨大な数のデプロイメント構成を行うことになるため、デプロイメントの目的をディレクトリ自体にメタデータとして取得する必要があります。Oracle Identity Managementインフラストラクチャに依存するOracleソフトウェアおよびサード・パーティのソフトウェアは、このメタデータによってデプロイメントの目的を認識し、カスタマイズされた環境で正常に機能できます。

Oracle Internet Directoryでは、デプロイメントの目的は、アイデンティティ管理レルムに取得されます。このレルムは、前述の項で配置について説明したユーザーおよびグループに対して、アイデンティティ管理ポリシーを設定する場合にも役立ちます。

アイデンティティ管理レルムは、ディレクトリ内の適用範囲が明確な領域で、次の要素で構成されています。

- 適用範囲が明確なエンタープライズ・アイデンティティの集合(米国内のすべての従業員など)

- これらのアイデンティティに関連付けられたアイデンティティ管理ポリシーの集合

- アイデンティティ管理ポリシーを設定しやすくするグループの集合(アイデンティティの集約)

DIT全体の構造およびユーザーとグループの配置を決定した後、アイデンティティ管理レルムのルートとして機能するディレクトリ・エントリを識別する必要があります。このエントリによって、レルムに定義されたアイデンティティ管理ポリシーの範囲が決まります。デフォルトでは、アイデンティティ管理レルムのルート下のディレクトリ・サブツリー全体が、範囲となります。このエントリの下に、OracleContextという特別なエントリが作成されます。次の項目が含まれます。

- ユーザーおよびグループのネーミングおよび配置などのデプロイメント固有のDIT設計(前述の項を参照)

- このレルムに関連付けられたアイデンティティ管理ポリシー

- Oracleアプリケーション特有のレルム固有の追加情報

アイデンティティ管理レルムを計画する場合は、次のことを考慮します。

- 企業のセキュリティ要件に基づいて、アイデンティティ管理レルムのルートを選択する必要があります。通常、ほとんどの企業で必要なレルムは1つのみです。ただし、個別のアイデンティティ管理ポリシーを使用して複数のユーザー集団を管理するときは、複数のレルムが必要になる場合があります。

- サード・パーティのディレクトリがすでに存在する場合、または将来それを統合する場合は、選択したアイデンティティ管理レルムのルートを、サード・パーティのディレクトリのDIT設計と一致させます。これによって、分散ディレクトリの同期化およびそれ以降の管理が簡単になります。

- アイデンティティ管理レルムを構成し管理するには、Oracle Internet Directoryで提供される管理ツールを使用します。これには、Oracle Delegated Administration Services 10g(10.1.4.3.0)以上のOracle Internet Directoryセルフサービス・コンソールやコマンド行ツールなどがあります。

関連項目:
『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のoidrealmコマンドのリファレンスを参照してください。

- Oracle Internet Directoryツールを使用してアイデンティティ管理レルムを構成した後、デプロイメントによって行われたカスタマイズを反映するために、ディレクトリのネーミングおよび格納ポリシーの更新を計画します。この更新は、Oracle Identity Managementインフラストラクチャを使用する他のOracleコンポーネントをインストールして使用する前に行う必要があります。

図34-1に、MyCompanyという会社のアイデンティティ管理レルムの例を示します。

図34-1 アイデンティティ管理レルムの例

図34-1の例は、ドメイン名ベースのDIT構造を使用するデプロイメントになっています。コンテナdc=us,dc=mycompany,dc=comは、アイデンティティ管理レルムのルートです。その結果、デフォルトで、適用範囲がdc=usエントリ下のディレクトリ・サブツリー全体に限定される新しいアイデンティティ管理レルムが作成されます。アイデンティティ管理レルムの名前はUSです。

34.1.2 企業内デプロイメントにおけるアイデンティティ管理レルム

この項では、単一および複数のアイデンティティ管理レルムを使用するデプロイメントについて説明します。この項の内容は、次のとおりです。

- 第34.1.2.1項「企業における単一アイデンティティ管理レルム」

- 第34.1.2.2項「企業における複数アイデンティティ管理レルム」

34.1.2.1 企業における単一アイデンティティ管理レルム

この例では、企業にはユーザーの集団が1つあり、そのすべてのユーザーが同一のアイデンティティ管理ポリシーによって管理されます。これは、すべてのOracle製品のデフォルトの構成です。Oracle Internet Directoryに存在するデフォルトのアイデンティティ管理レルムは1つのみであり、企業内のすべてのOracleコンポーネントが、このレルムのユーザーに対応します。図34-2に、この使用方法を示します。

図34-2 企業での使用例: 単一アイデンティティ管理レルム

図34-2の例には、従業員のみを含む単一のデフォルトのアイデンティティ管理レルムがあります。このレルムでは、すべてのユーザーおよびグループが管理され、同じアプリケーションであるアプリケーションAおよびアプリケーションBへのアクセスを共有しています。

34.1.2.2 企業における複数アイデンティティ管理レルム

同一のアイデンティティ管理インフラストラクチャを使用して、内部ユーザーと外部の自己登録ユーザーの両方に対応することも可能です。内部ユーザーと外部ユーザーではアイデンティティ管理ポリシーが異なるため、内部ユーザー用と外部ユーザー用にレルムを1つずつデプロイできます。図34-3に、この使用方法を示します。

図34-3 企業での使用例: 複数アイデンティティ管理レルム

図34-3の例では、デフォルトのアイデンティティ管理レルムは内部ユーザー(従業員)用であり、これらの内部ユーザーにはアプリケーションA、BおよびCへのアクセス権があります。外部アイデンティティ管理レルムは外部ユーザー用であり、外部ユーザーには、アプリケーションCおよびDへのアクセス権があります。

34.1.3 ホスティングされたデプロイメントにおけるアイデンティティ管理レルム

ホスティングされたデプロイメントでは、アプリケーション・サービス・プロバイダ(ASP)が、1社以上にアイデンティティ管理サービスを提供し、これらの企業にかわってアプリケーションのホスティングを行います。ホスティングされた各企業は、その企業のユーザーが管理される個別のアイデンティティ管理レルムに対応付けられます。アプリケーション・サービス・プロバイダに属するユーザーは、別のレルム(通常は、デフォルトのレルム)で管理されます。

図34-4に、ホスティングされたデプロイメント(2社をホスティング)を示します。

図34-4 ホスティングされたデプロイメントでの使用例

図34-4の例では、ASPユーザーはデフォルトのアイデンティティ管理レルムに存在します。ASPは、そのレルムのユーザー、グループおよび関連するポリシーを管理します。ASPユーザーは、ホスティングされた企業のためにアプリケーションA、B、Cを管理しています。ホスティングされた企業のMyCompanyユーザーは、MyCompanyというアイデンティティ管理レルムに存在します。これらのユーザーは、アプリケーションAおよびアプリケーションBを使用します。ホスティングされた企業のXY Corpユーザーは、XY Corpというアイデンティティ管理レルムに存在します。それらはアプリケーションBおよびアプリケーションCを使用します。

34.1.4 Oracle Internet Directoryでのアイデンティティ管理レルムの実装

表34-1に、アイデンティティ管理レルムのオブジェクトを示します。

表34-1Oracle Identity Managementオブジェクト

オブジェクト

説明

ルートOracleコンテキスト

このオブジェクトには、次のものが含まれます。

- インフラストラクチャ内のデフォルトのアイデンティティ管理レルムへのポインタ

- 単純な名前の指定によりレルムの位置を特定する方法に関する情報

アイデンティティ管理レルム

特別なオブジェクト・クラスが関連付けられた通常のディレクトリ・エントリ。

ID管理レルム固有のOracleコンテキスト

このオブジェクトには、レルムごとに次のものが含まれます。

- アイデンティティ管理レルムのユーザー・ネーミング・ポリシー(ユーザーに名前を付け、配置する方法)

- 必須認証属性

- アイデンティティ管理レルム内のグループの位置

- アイデンティティ管理レルムに対する権限の割当て(レルムにユーザーを追加する権限の割当てなど)

- レルムに関するアプリケーション固有のデータ(認可など)

34.1.5 デフォルトのディレクトリ情報ツリーおよびアイデンティティ管理レルム

構成を簡単にするために、Oracle Internet Directoryのインストール時に、デフォルトのDITが作成され、デフォルトのアイデンティティ管理レルムが設定されます。

図34-5 デフォルトのアイデンティティ管理レルム

図34-5に示されているとおり、デフォルトのアイデンティティ管理レルムはグローバルDITの一部です。ルートDSEのすぐ下のノードはdc=comで、その下にdc=MyCompany、次にdc=usが続きます。これらの4つのノードにより、DIT構造全体が表されます。ノードdc=usは、デフォルトのアイデンティティ管理レルムのルートです。これには、ユーザーおよびグループの情報を格納するためのcn=Usersおよびcn=Groupsという2つのサブツリーが含まれています。説明上の理由から、cn=Usersノードには、uid=user1およびuid=user2という2つのリーフが含まれています。同様に、cn=Groupsノードには、cn=group1およびcn=group2が含まれています

オプションで、Oracle Internet Directoryをインストールするコンピュータのドメインに基づいて、DITを設定することもできます。たとえば、oidhost.us.mycompany.comというコンピュータにインストールすると、デフォルトのアイデンティティ管理レルムのルートは、dc=us,dc=mycompany,dc=comとなります。

また、「Internet Directoryのネームスペースの指定」インストール画面で、デプロイメント要件を満たす別の識別名を、デフォルトのアイデンティティ管理レルムのルートとして指定することも可能です。たとえば、独自のアイデンティティ管理インストール環境をサード・パーティ・ディレクトリと統合する予定がある場合、サード・パーティ・ディレクトリのデフォルト・ネーミング・コンテキストの識別名と一致する識別名を指定することをお薦めします。サード・パーティ・ディレクトリからデフォルト・ネーミング・コンテキストを取得する方法の詳細は、『Oracle Fusion Middleware Oracle Directory Integration Platform管理者ガイド』のサード・パーティ・ディレクトリとの統合に関する章を参照してください。

構成中に、Oracle Internet Directoryによって次のものが作成されます。

- デフォルトのアイデンティティ管理レルムに関連付けられたOracleコンテキスト。Oracleコンテキストには、レルム固有のすべてのポリシーとメタデータが格納されます。前述の例の場合は、cn=OracleContext,dc=us,dc=mycompany,dc=comという識別名を持つOracleコンテキストが作成されます。このエントリとその下にあるノードによって、Oracleソフトウェアはレルム固有のポリシーと設定を検出できます。

- デフォルトのアイデンティティ管理レルムでのディレクトリ構造およびネーミング・ポリシー。これによって、Oracleコンポーネントが様々なアイデンティティを検索できるようになります。これらのデフォルト値は、次のとおりです。

- すべてのユーザーは、アイデンティティ管理レルムのベースの下にあるコンテナcn=usersに配置されます。この例では、cn=users,dc=us,dc=mycompany,dc=comがこのコンテナです。

- Oracle Identity Managementインフラストラクチャを使用してアイデンティティ管理レルム内に作成した新規ユーザーも、コンテナcn=usersの下に作成されます。

- Oracle Identity Managementインフラストラクチャを使用してアイデンティティ管理レルム内に作成したすべての新規ユーザーは、オブジェクト・クラスorclUserV2およびinetOrgPersonに属します。

- すべてのグループは、アイデンティティ管理レルムのベースの下にあるコンテナcn=groupsに配置されます。この例では、cn=groups,dc=us,dc=mycompany,dc=comがこのコンテナです。

- アイデンティティ管理レルム管理者。このユーザーは、ユーザー・コンテナの下に配置されます。この例では、レルム管理者の完全修飾された識別名はcn=orcladmin,cn=users,dc=us,dc=mycompany,dc=comです。

注意:
レルム管理者のアカウントがロックされた場合は、Oracle Internet DirectoryのスーパーユーザーがOracle Directory Managerを使用してレルム管理者のアカウントのパスワードを変更することにより、ロックを解除できます。

- 認証サービスで適切な処理を実行できるようにするデフォルトの認証ポリシー。次のポリシーが含まれます。

- デフォルトのディレクトリ・パスワード・ポリシー(パスワードの長さ、ロックアウト、有効期限など)

- ユーザーのプロビジョニングを行う際に自動生成される必要がある追加のパスワード・ベリファイア

- アイデンティティ管理の権限。Oracle Internet Directoryによって、Oracle Internet Directoryセルフサービス・コンソールを介してこれらの権限を委任できるレルム管理者に付与されます。これらの権限の例は、次のとおりです。

- 共通のアイデンティティ管理構成権限(ユーザーの作成、ユーザー・プロファイルの変更、グループの作成など)

- Oracle Identity Managementインフラストラクチャを使用して新しいOracleコンポーネントをインストールする権限

- Oracle Internet Directoryセルフサービス・コンソールを管理する権限

関連項目:

- オブジェクト・クラスorclUserV2の詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のOracle Identity Management LDAPオブジェクト・クラスに関する説明を参照してください。

- Oracle Identity Managementのデフォルトのアクセス制御ポリシーの詳細は、第32章「Oracle Identity Managementの権限の委任の概要」を参照してください。

34.2 デフォルトのアイデンティティ管理レルムのカスタマイズ

レルムを作成した後、その様々な要素をカスタマイズできます。表34-2に、カスタマイズできる要素、各種のカスタマイズで使用可能なツールおよび参照先を示します。

表34-2 デフォルトのアイデンティティ管理レルムのカスタマイズ

カスタマイズ可能な対象

ツール

参照箇所

ディレクトリ構造およびネーミング・ポリシー

Oracle Internet Directoryセルフサービス・コンソール

Oracle Directory Services Manager

コマンド行ツール

この項。

第34.1.5項「デフォルトのディレクトリ情報ツリーおよびアイデンティティ管理レルム」

10g (10.1.4.0.1)ライブラリの『Oracle Identity Management委任管理ガイド』の「Oracle Internet Directoryセルフ・サービス・コンソールの使用方法」

認証ポリシー

Oracle Directory Services Manager

コマンド行ツール

第29章「パスワード・ポリシーの管理」

アイデンティティ管理の権限

Oracle Internet Directoryセルフサービス・コンソール

Oracle Directory Services Manager

コマンド行ツール

第32章「Oracle Identity Managementの権限の委任」

10g (10.1.4.0.1)ライブラリの『Oracle Identity Management委任管理ガイド』の「Oracle Internet Directoryセルフ・サービス・コンソールの使用方法」

これが必要となる可能性がある典型的なシナリオは、Oracle Identity Managementインストールをサード・パーティ・ディレクトリと統合する場合です。

たとえば、デフォルトのアイデンティティ管理レルムがdc=mycompany,dc=comであり、cn=users,dc=mycompany,dc=comの下にユーザーが存在すると仮定します。

サード・パーティ・ディレクトリのネーミング・コンテキストが、デフォルト・レルム内のユーザーおよびグループの現在の検索ベースと一致しない場合は、既存のユーザーとサード・パーティのユーザーがどちらもOracle Single Sign-Onを使用してログインできるように、デフォルト・レルムのユーザーおよびグループの検索ベースを変更できます。既存のユーザーとサード・パーティのユーザーをともに含むことができて最も下位にあるユーザー検索ベースを選択します。この検索ベースを、最下位の共通ユーザー検索ベースと呼ぶことにします。

注意:
このアプローチでは、Oracle Single Sign-Onのログインで選択されるユーザーのnickname属性が、既存のユーザー検索ベースとサード・パーティ・ディレクトリのネーミング・コンテキスト全体で一意であると仮定しています。そうでない場合、nickname属性の値が競合しているすべてのユーザーは、Oracle Single Sign-Onの認証に失敗します。

デプロイメント環境が次の1から5の使用例のいずれかと一致する場合は、第34.2.1項「ユーザーおよびグループの既存の検索ベースを更新する手順」で説明されている手順に従ってください。

使用例1:

サード・パーティのネーミング・コンテキストは、デフォルト・レルムの下にありますが、レルムのユーザー検索ベース以外のコンテナ内に存在します。

たとえば、既存のユーザーがcn=users,dc=mycompany,dc=comの下に存在し、サード・パーティのネーミング・コンテキストがcn=users,o=employees,dc=mycompany,dc=comの下に存在する場合です。この場合、最下位の共通ユーザー検索ベースは、dc=mycompany,dc=comです。

使用例2:

サード・パーティのネーミング・コンテキストは、デフォルト・レルムの外部にありますが、最下位の共通ユーザー検索ベースが存在します。

たとえば、既存のユーザーがcn=users,dc=mycompany,dc=comの下に存在し、サード・パーティのネーミング・コンテキストがcn=users, dc=mycompanyecorp,dc=comの下に存在する場合です。この場合、最下位の共通ユーザー検索ベースは、dc=comです。

最下位の共通ユーザー検索ベースがルートDSEの場合は、「使用例6:」の次の項で説明されている手順に従います。

1. 第34.2.2項「追加の検索ベースの設定」

2. 第34.2.3項「Oracle Single Sign-Onのリフレッシュ」

3. 第34.2.4項「プロビジョニング・プロファイルの再構成」

使用例3:

サード・パーティのネーミング・コンテキストは、デフォルト・レルムの識別名と同じです。

たとえば、既存のユーザーがcn=users,dc=mycompany,dc=comの下に存在し、サード・パーティのネーミング・コンテキストがdc=mycompany,dc=comのすぐ下に存在する場合です。この場合、最下位の共通ユーザー検索ベースは、dc=mycompany,dc=comです。

使用例4:

サード・パーティのネーミング・コンテキストに、デフォルト・レルムの識別名の親が含まれます。

たとえば、識別名(DN)がdc=us,dc=mycompany,dc=comであるデフォルト・レルムがあり、既存のユーザーがcn=users,dc=us,dc=mycompany,dc=comの下に存在し、サード・パーティのネーミング・コンテキストがdc=comのすぐ下に存在する場合です。この場合、最下位の共通ユーザー検索ベースは、dc=comです。

使用例5:

サード・パーティのネーミング・コンテキストは、既存のユーザー検索ベースの下に存在します。

たとえば、既存のユーザーがcn=users,dc=mycompany,dc=comの下に存在し、サード・パーティのネーミング・コンテキストがl=emea,cn=users,dc=mycompany,dc=comのすぐ下に存在する場合です。この場合、最下位の共通ユーザー検索ベースは、cn=users,dc=mycompany,dc=comです。この使用例の場合、ユーザー検索ベースを変更する必要はありません。

34.2.1 ユーザーおよびグループの既存の検索ベースを更新する手順

サード・パーティ・ディレクトリとの同期化を設定する前に、次の手順を実行する必要があります。

1. Oracle Internet Directoryデータベースをバックアップします。

2. サード・パーティ・ディレクトリにまだエントリが存在しない場合、Oracle Directory Services Managerを使用してそのディレクトリにユーザー・コンテナおよびグループ・コンテナを作成します。

3. 次の手順に従って新規ユーザー・コンテナに適切なACLを適用します。

1. ACLテンプレート・ファイル$ORACLE_HOME/ldap/schema/oid/oidUserAdminACL.sbsの変数%USERBASE%と%REALMBASE%をインスタンス化し、usracl.ldifファイルを作成します。変数%USERBASE%は新規ユーザー・コンテナの識別名に、変数%REALMBASE%はデフォルト・レルムの識別名に設定します。

2. ldapmodifyコマンドを使用してインスタンス化したLDIFファイルのusracl.ldifをアップロードします。

4. 次の手順に従って新規グループ・コンテナに適切なACLを適用します。

1. ACLテンプレート・ファイル$ORACLE_HOME/ldap/schema/oid/oidGroupAdminACL.sbsの変数%GRPBASE%と%REALMBASE%をインスタンス化し、grpacl.ldifファイルを作成します。変数%USERBASE%は新規ユーザー・コンテナの識別名に、変数%REALMBASE%はデフォルト・レルムの識別名に設定します。

2. ldapmodifyコマンドを使用してインスタンス化したLDIFファイルのgrpacl.ldifをアップロードします。

5. 既存のユーザーとサード・パーティのユーザーをともに含むことができる最下位の共通ユーザー検索ベースを決定します。

たとえば、既存のユーザーがcn=users,dc=mycompany,dc=comの下に存在し、サード・パーティのユーザーがl=emea,dc=mycompany,dc=comの下に存在する場合、最下位の共通ユーザー検索ベースは、dc=mycompany,dc=comです。

最下位の共通ユーザー検索ベースが、ルート・エントリになることもあります。たとえば、既存のユーザーがcn=users,dc=mycompany,dc=comの下に存在し、サード・パーティのユーザーがdc=mycompanycorp,dc=netの下に存在する場合です。この場合は、第34.2.2項「追加の検索ベースの設定」で説明されているデプロイメント例までスキップしてください。

6. グループも同期化する必要がある場合は、既存のグループとサード・パーティのグループをともに含むことができて最も下位にあるグループ検索ベースを決定します。この検索ベースを、最下位の共通グループ検索ベースと呼ぶことにします。

たとえば、既存のグループがcn=groups,dc=mycompany,dc=comの下に存在し、サード・パーティのグループがl=emea,dc=mycompany,dc=comの下に存在する場合、最下位の共通グループ検索ベースは、dc=mycompany,dc=comです。

7. レルムの管理者(通常はorcladmin)としてセルフサービス・コンソールにログインします。

8. 「構成」タブに移動し、ユーザー検索ベースを手順5で決定した最下位の共通ユーザー検索ベースに設定します。グループも同期化する場合は、グループ検索ベースを手順6で決定した最下位の共通グループ検索ベースに設定します。

9. Oracle Single Sign-Onにこれらの変更を認識させるため、第34.2.3項「Oracle Single Sign-Onのリフレッシュ」に説明されている手順を実行します。

10. orcladminとしてログインし、元のユーザー検索ベースのユーザーによるOracle Single Sign-Onのログインを検証します。

11. 変更されたユーザーおよびグループ・ベースを反映するように、プロビジョニングされているアプリケーションも再構成する必要があります。第34.2.4項「プロビジョニング・プロファイルの再構成」に説明されている手順に従ってください。

注意:
ユーザーおよびグループの検索ベースの属性に加え、ログイン名(ニックネーム)の属性やRDNの属性など、アイデンティティ管理レルムの他の構成設定もセルフサービス・コンソールを使用して変更できます。詳細は、10g (10.1.4.0.1)ライブラリの『Oracle Identity Management委任管理ガイド』の「Oracle Internet Directoryセルフ・サービス・コンソールの使用方法」の章にある、アイデンティティ管理レルムの構成設定の変更に関する項を参照してください。

使用例6:

この場合、サード・パーティのネーミング・コンテキストはデフォルト・レルムの外部にあり、最下位の共通ユーザー検索ベースはルートDSEです。

たとえば、既存のユーザーがcn=users,dc=mycompany,dc=comの下に存在し、サード・パーティのネーミング・コンテキストがcn=users,dc=mycompanycorp,dc=netの下に存在する場合、最下位の共通ユーザー検索ベースは、ルートDSEです。

この場合、サード・パーティのネーミング・コンテキストを別の検索ベースとして追加する必要があります。この手順は次のとおりです。

1. 「追加の検索ベースの設定」

2. 「Oracle Single Sign-Onのリフレッシュ」

3. 「プロビジョニング・プロファイルの再構成」

34.2.2 追加の検索ベースの設定

サード・パーティ・ディレクトリとの同期化を設定する前に、次の手順を実行します。

1. Oracle Internet Directoryデータベースをバックアップします。

2. サード・パーティ・ディレクトリにまだエントリが存在しない場合、Oracle Directory Services Managerを使用してそのディレクトリにユーザー・コンテナおよびグループ・コンテナを作成します。

3. 次の手順に従って新規ユーザー・コンテナに適切なACLを適用します。

1. ACLテンプレート・ファイル$ORACLE_HOME/ldap/schema/oid/oidUserAdminACL.sbsの変数%USERBASE%と%REALMBASE%をインスタンス化し、usracl.ldifファイルを作成します。変数%USERBASE%は新規ユーザー・コンテナの識別名に、変数%REALMBASE%はデフォルト・レルムの識別名に設定します。

2. ldapmodifyコマンドを使用してインスタンス化したLDIFファイルのusracl.ldifをアップロードします。

4. 次の手順に従って新規グループ・コンテナに適切なACLを適用します。

1. ACLテンプレート・ファイル$ORACLE_HOME/ldap/schema/oid/oidGroupAdminACL.sbsの変数%GRPBASE%と%REALMBASE%をインスタンス化し、grpacl.ldifファイルを作成します。変数%USERBASE%は新規ユーザー・コンテナの識別名に、変数%REALMBASE%はデフォルト・レルムの識別名に設定します。

2. ldapmodifyコマンドを使用してインスタンス化したLDIFファイルのgrpacl.ldifをアップロードします。

5. レルムの管理者としてセルフサービス・コンソールにログインします。

6. 「構成」タブに移動します。

1. 現在のレルムのusersearchbaseにcn=users,dc=mycompanycorp,dc=netを追加します。

2. 現在のレルムのgroupsearchbaseにcn=groups,dc=mycompanycorp,dc=netを追加します。

7. Oracle Single Sign-Onにこれらの変更を認識させるため、第34.2.3項「Oracle Single Sign-Onのリフレッシュ」に説明されている手順を実行します。

8. orcladminとしてログインし、元のユーザー検索ベースのユーザーによるOracle Single Sign-Onのログインを検証します。

9. このアイデンティティ管理構成に基づいて中間層が構成されている場合、変更されたユーザーおよびグループ・ベースを反映するように、プロビジョニングされているアプリケーションも再構成する必要があります。第34.2.4項「プロビジョニング・プロファイルの再構成」に説明されている手順に従ってください。

注意:
ユーザーおよびグループの検索ベースの属性に加え、ログイン名(ニックネーム)の属性やRDNの属性など、アイデンティティ管理レルムの他の構成設定もセルフサービス・コンソールを使用して変更できます。詳細は、10g (10.1.4.0.1)ライブラリの『Oracle Identity Management委任管理ガイド』の「Oracle Internet Directoryセルフ・サービス・コンソールの使用方法」の章にある、アイデンティティ管理レルムの構成設定の変更に関する項を参照してください。

34.2.3 Oracle Single Sign-Onのリフレッシュ

Oracle Single Sign-Onに構成変更を認識させるため、$ORACLE_HOME/sso/admin/plsql/sso/ディレクトリに移動して次のように入力し、Oracle Single Sign-Onのリフレッシュ・スクリプトを実行します。

sqlplus orasso@ssoreoid.sql

パスワードが要求されます。orassoスキーマ・パスワードを取得するには、10g (10.1.4.0.1)ライブラリの『Oracle Application Server Single Sign-On管理者ガイド』の付録「Single Sign-Onスキーマのパスワードの取得」を参照してください。

34.2.4 プロビジョニング・プロファイルの再構成

ユーザーおよびグループの検索ベースを変更する前にデフォルトのアイデンティティ管理レルムに基づいて中間層アプリケーションをインストールしている場合、中間層のインストールによって作成されたプロビジョニング・プロファイルは、無効になります。この理由は、プロファイルのevent subscriptions属性に含まれるユーザーまたはグループの検索ベースの情報が古くなるためです。oidprovtoolを使用して、すべてのプロファイルを変更する必要があります。

すべてのプロビジョニング・プロファイルに対して次の手順を実行します。

1. ldapsearchを使用して、すべてのプロビジョニング・プロファイル情報をLDIFファイルに出力します。

ldapsearch -h oid_host -p oid_port \
-D "cn=orcladmin" -q -s sub \
-b "cn=provisioning profiles,cn=changelog subscriber,\
cn=oracle internet directory" \
"objectclass=*" >  provprofiles.ldif

イベント・サブスクリプションの例は、次のとおりです。

USER:cn=users,dc=mycompany,dc=com:MODIFY(list_of_attributes)USER:cn=users,dc=mycompany,dc=com:DELETEGROUP:cn=groups,dc=mycompany,dc=com:MODIFY(list_of_attributes)GROUP:cn=groups,dc=mycompany,dc=com:DELETE

ここで、cn=users,dc=mycompany,dc=comとcn=groups,dc=mycompany,dc=comは、それぞれアプリケーションのインストールおよび構成時に作成したユーザー検索ベースとグループ検索ベースです。

2. GUIDに基づいてOracle Internet Directoryサーバーを検索することで、アプリケーション・アイデンティティの実際の識別名を取得します。アプリケーションの識別名を取得するには、次のように入力します。

ldapsearch -h host -p port -D cn=orcladmin -q \
-s sub -b "" \
"orclguid=Value_of_orclODIPProvisioningAppGuid" dn

provprofiles.ldifの属性値から各プロファイルのGUID値を取得できます。

3. 返された各プロファイルを次のように変更します。

$ORACLE_HOME/bin/oidprovtool operation=MODIFY \
ldap_host=host ldap_port=port \
ldap_user_dn="cn=orcladmin" \
ldap_user_passwd=password \
interface_version=interfaceVersion \
application_dn=applicationDN \
organization_dn=identity_Realm_DN \
event_subscription=New_Event_Subscription_1
event_ subscription=New_Event_Subscription_2
.
.
.
event_subscription=New_Event_Subscription_n

New_Event_Subscription引数には、次の書式を使用する必要があります。

USER: new_user_search_base:MODIFY(list_of_attributes)
USER: new_user_search_base:DELETE
GROUP: new_group_search_base:MODIFY(list_of_attributes)
GROUP: new_group_search_base:DELETE

ここで、organization_dnの値には、元のアイデンティティ・レルムの識別名を指定する必要があります。

34.3 ホスティングされたデプロイメントでのアイデンティティ管理レルムの追加作成

追加のアイデンティティ管理レルムは、Oracle Delegated Administration Services 10g(10.1.4.3.0)以上のセルフサービス・コンソールまたはoidrealmを使用して作成できます。

ASPAdminsグループのメンバーのみが、新しいアイデンティティ管理レルムを作成できます。Oracle Directory Services Managerを使用して、デフォルトのアイデンティティ管理レルム固有のOracleコンテキストにおけるASPAdminsグループのuniquemember属性にユーザー識別名を追加し、このグループにユーザーを追加します。詳細は、「Oracle Directory Services Managerを使用した静的グループ・エントリの変更」を参照してください。

注意:
複数のアイデンティティ管理レルムでは、動作しないアプリケーションもあります。
レルムを追加する場合は、追加したレルムが既存アプリケーションで認識されるように手動で設定する必要があります。詳細は、アプリケーション固有のマニュアルを参照してください。

Oracle Identity Managementインフラストラクチャでは、特別な管理手順を使用してシングル・サインオン・サーバーに追加のレルムを認識させる必要があります。Oracle Single Sign-Onで複数のレルムを有効にする方法は、10g (10.1.4.0.1)ライブラリの『Oracle Application Server Single Sign-On管理者ガイド』の「複数レルムでのシングル・サインオン」の章を参照してください。

関連項目:

- 『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のoidrealmコマンドのリファレンスを参照してください。

- 第14.2.2項「Oracle Directory Services Managerを使用した静的グループ・エントリの変更」

- アイデンティティ管理レルムの追加作成の詳細は、10g (10.1.4.0.1)ライブラリの『Oracle Identity Management委任管理ガイド』の「Oracle Internet Directoryセルフ・サービス・コンソール」を参照してください。

34.4 DITビューの作成

11gリリース1 (11.1.1.9.0)以降では、異なるDITまたはソースDITのエントリを表示した仮想ビューまたはネームスペースであるDITビューを作成できます。次の項目がソースDITからDITビューのネームスペースに変換されます。

- エントリ内の識別名とすべての識別名属性

- DITビューで指定されている相対識別名マッピング

DITビューによって、テナント全体の共通エントリに対するクラウド環境の記憶域要件全体が削減されます。DITビューでは、LDAPMODDN以外のすべての操作が可能です。DITビューでは、エントリ内の任意の属性から相対識別名属性の値を導出できるため、ユーザー名がエントリ識別名に表示される場合に元のエントリを非表示にできます。

この項の内容は次のとおりです。

- 第34.4.1項「DITビューの構文」

- 第34.4.2項「DITビューの条件」

- 第34.4.3項「DITビューの例」

34.4.1 DITビューの構文

DITビューを指定するには、次の構文を使用します。

objectclass: orclditview
objectclass: extensibleobject
orclRDNAttrMapping:targetAttribute:sourceAttribute:valueFromAttribute[,optionalRelativeDN]
orclDITBaseDN: realDN
orclrdnmapping: targetRDN:sourceRDN
orclreturnattr: orclmemberof
orclreturnattr: attrName

表34-3に、DITビューを指定するために使用する項目を示します。

表34-3 DITビューの構文

項目

説明

objectclass: orclditview

Oracle Internet Directoryサーバーに、DITビュー・マッピングのエントリを処理するように指示します。

objectclass: extensibleobject

エントリでは、オプションで任意の属性を保持できます。

orclRDNAttrMapping: targetAttribute:sourceAttribute:valueFromAttribute[,optionalRelativeDN ]

ターゲット属性に対するソース属性のマッピングと、別の属性の値を使用するオプションを指定します。

- targetAttributeは、DITビューのエントリの相対識別名属性の名前です。

- sourceAttributeは、元のソース・エントリの相対識別名属性の名前です。

- valueFromAttributeは、相対識別名の値が導出される属性です。ほとんどの場合、この値は、sourceAttributeと同じにすることができます。

- optionalRelativeDNは、オプションで、この相対識別名の下にある場合にのみサーバーで変換を実行するかどうかを指定します。

orclDITBaseDN: realDN

元のソース・エントリの場所であるrealDNを指定します。次に例を示します。

ou=people,dc=us,dc=example,dc=com

orclrdnmapping: targetRDN: sourceRDN

sourceRDNから宛先のtargetRDNに対する相対識別名マッピングを指定します。

orclreturnattr: attrName

返却する複数値属性の名前を指定します。Oracle Internet Directoryサーバーは、これらの構成済属性のみを返します。

オプション。orclreturnattrが指定されていない場合、サーバーは、エントリのすべての属性を返します。

orclmaskfilter: LDAP Filter

このLDAPフィルタを使用してエントリをマスクします。

orclrdnfilter: LDAP Filter

このLDAPフィルタを使用して、orclrdnfilterが適用可能な場合にのみ、相対識別名マッピング変換を実行します。

orclattrmapping:targetAttr:SourceAttr:overwrite

SourceAttrからtarget Attrに値をコピーします。overwriteを1に設定すると、targetAttrの値にはsourceAttrからの値のみが含まれます。それ以外の場合、既存のtargetAttrの値に追加されます。

orclattrexclude: attrName: specificValue

属性または属性の特定の値を除外できます。specificValueパラメータはオプションです。

orclalternateDITDN: AlternateDN

orclDITBaseDNで検出されない場合に、別のコンテナのエントリを検索できます。これは単一値構成です。

注意: Oracle Internet DirectoryサーバーがorclDITBaseDNとorclalternateDITDNの使用時期を判別できるようにorclmaskfilterを構成する必要があります。

34.4.2 DITビューの条件

DITビューを使用する場合、次の条件に留意する必要があります。

- マップされるDITビューのエントリの相対識別名属性には、カンマ(,)、プラス記号(+)、等号(=)、セミコロン(;)、ハッシュ(#)、バックスラッシュ(\)、より小さい(<)、より大きい(>)などの特殊文字を含めることはできません。

- マップされるDITビューのエントリの相対識別名属性は、uniqueness属性が有効化された単一値属性である必要があります。

- DITビューからorclmemberof属性の別名(memberof/ismemberof)を取得する場合、DITビューの作成時に、次のように返却属性リストの別名を指定する必要があります。

orclreturnattr: orclmemberof

34.4.3 DITビューの例

次の例では、実際のエントリがDITビュー・エントリに変換されます。

実際のエントリ:

uid=user.1,ou=people,dc=us,dc=example,dc=com

DITビュー・エントリ:

displayname=user.1,ou=people,dc=uk,dc=example,dc=com

次に例を示します。

dn: ou=people,dc=uk,dc=example,dc=com
objectclass: top
objectclass: orclditview
objectclass: extensibleobject
orclrdnattrmapping: displayname:uid:mail
orclditbasedn: ou=people,dc=us,dc=example,dc=com

次の例では、実際のエントリがDITマップ・エントリに変換されます(user.1@example.comはmail属性の値です)。

実際のエントリ:

uid=user.1,ou=people,dc=us,dc=example,dc=com

DITビュー・エントリ:

displayname=user.1@example.com,ou=people,dc=ind,dc=example,dc=com

次に例を示します。

dn: ou=people,dc=ind,dc=example,dc=com
objectclass: top
objectclass: orclditview
objectclass: extensibleobject
orclrdnattrmapping: displayname:uid:mail
orclditbasedn: ou=People,dc=us,dc=example,dc=com
ou: people

次の例では、実際のエントリがDITマップ・エントリに変換されます(user.1@example.comはmail属性の値です)。

実際のエントリ:

uid=user.1,ou=people,dc=us,dc=example,dc=com

DITビュー・エントリ:

displayname=user.1@example.com,cn=users,cn=common,dc=example,dc=com

次に例を示します。

dn: cn=common,dc=example,dc=com
objectclass: top
objectclass: orclditview
objectclass: extensibleobject
orclrdnattrmapping: displayname:uid:mail
orclditbasedn: dc=us,dc=example,dc=com
orclrdnmapping: cn=users:ou=people
orclrdnmapping: cn=groupview:cn=groups
cn: common

次の例では、属性構成が返されます。この構成は、エントリがこのツリーで検索されると、uid、mail、cnおよびsn属性のみが返されることを示しています。他の属性を持つエントリを追加または更新する場合、この制限は適用されないため、他の属性を持つエントリを追加できることに注意してください。

dn: cn=common,dc=example,dc=com
objectclass: top
objectclass: orclditview
objectclass: extensibleobject
orclrdnattrmapping: displayname:uid:mail
orclditbasedn: dc=us,dc=example,dc=com
orclrdnmapping: cn=users:ou=people
orclrdnmapping: cn=groupview:cn=groups
orclreturnattr: cn
orclreturnattr: uid
orclreturnattr: mail
orclreturnattr: sn
cn: common

次の例で、属性マッピングについて説明します。構文は次のとおりです:

orclattrmapping=targetAttr:SourceAttr:overWrite

overWriteが1に設定されている場合、targetAttrの既存の値は削除されます。overWriteが0に設定されている場合、targetAttrの既存の値にsourceAttrの値が追加されます。

dn: cn=ditview,dc=oracle,dc=com
changetype: modify
replace: orclattrmapping
orclattrmapping: cn:mail:0
orclattrmapping: sn:givenname:1

次の例で、属性の値を除外する方法について説明します。構文は次のとおりです:

orclattrexclude: attribute: optionalValue

dn: cn=ditview,dc=oracle,dc=com
changetype: modify
orclattrexclude: objectclass:orgperson
orclattrexclude: authpassword
orclattrexclude: userpassword

次の例で、代替ベース識別名について説明します。

dn: cn=filteredusers,dc=oracle
objectclass: top
objectclass: orclditview
objectclass: extensibleobject
orclditbasedn: ou=people,dc=us,dc=oracle,dc=com
orclalternateditdn: ou=contractors, dc=us,dc=oracle,dc=com
orclmaskfilter: (employeetype=regular)
cn: filteredusers

35 Oracle Internet Directoryのチューニングとサイズ設定

Oracle Internet Directoryのサイズ設定とチューニングに関する推奨事項については、『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』の「Oracle Internet Directory」の章を参照してください。

注意:
Oracle Internet Directoryのデフォルト構成は、ほとんどの本番用デプロイメントおよびテスト用デプロイメントにとって最適なものではありません。最適なパフォーマンスと可用性を実現するには、少なくとも、『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』の「Oracle Internet Directory」の章に示されているチューニング手順に従う必要があります。

36 ガベージ・コレクションの管理

この章では、ガベージ・コレクション用のOracle Databaseタイムゾーンの設定、Oracle Internet Directoryガベージ・コレクタの管理、ガベージ・コレクタ用のロギングの管理など、Oracle Internet Directoryでガベージ・コレクションを管理する方法について説明します。

ガベージとは、ディレクトリで不要になっているが領域を使用しているデータを指します。結果として、このような不要なデータや古いデータでディスクが一杯になり、ディレクトリのパフォーマンスが低下します。ディレクトリからこの不要なデータを削除する処理を、ガベージ・コレクションと呼びます。

この章の内容は次のとおりです。

- 第36.1項「ガベージ・コレクションの管理の概要」

- 第36.2項「ガベージ・コレクション用のOracle Databaseタイムゾーンの設定」

- 第36.3項「Oracle Internet Directoryガベージ・コレクタの変更」

- 第36.4項「Oracle Internet Directoryガベージ・コレクタのロギングの管理」

- 第36.5項「時間ベースの変更ログのパージの構成」

36.1 ガベージ・コレクションの管理の概要

ガベージ・コレクタは、ディレクトリから不要なデータを削除する、バックグラウンドのデータベース・プロセスです。Oracle Internet Directoryガベージ・コレクション・フレームワークには、ガベージ・コレクタの標準セットがあり、このフレームワークにより、これらのコレクタを変更できます。Oracle Internet Directory統計情報コレクタでも、Oracle Internet Directoryガベージ・コレクション・フレームワークが使用されます。

この概要の項目は次のとおりです。

- 第36.1.1項「Oracle Internet Directoryガベージ・コレクション・フレームワークのコンポーネント」

- 第36.1.2項「Oracle Internet Directoryガベージ・コレクションの動作」

- 第36.1.3項「ガベージ・コレクタ・エントリとOracle Internet Directory統計情報コレクタ・エントリ」

- 第36.1.4項「変更ログのパージ」

36.1.1 Oracle Internet Directoryガベージ・コレクション・フレームワークのコンポーネント

この項では、Oracle Internet Directoryガベージ・コレクション・フレームワークを構成するコンポーネントであるガベージ・コレクション・プラグインとバックグラウンドのデータベース・プロセスについて説明します。

36.1.1.1 ガベージ・コレクション・プラグイン

Oracle Internet Directoryのガベージ・コレクションは、ガベージ・コレクタの管理リクエストを受け取るガベージ・コレクション・プラグインを使用します。このプラグインは、Oracle Internet Directoryとともにインストールされ、デフォルトで使用可能になります。このプラグインのエントリは、cn=plugin,cn=subconfigsubentryです。

このプラグインには、3つのトリガーがあります。

- ガベージ・コレクション・ジョブの作成に使用するプラグイン・トリガーの識別名:
cn=Add PurgeConfig,cn=plugin,cn=subconfigsubentry

- ガベージ・コレクション・ジョブの変更に使用するプラグイン・トリガーの識別名:
cn=Modify PurgeConfig,cn=plugin,cn=subconfigsubentry

- ガベージ・コレクション・ジョブの削除に使用するプラグイン・トリガーの識別名:
cn=Delete PurgeConfig,cn=plugin,cn=subconfigsubentry

関連項目:
ガベージ・コレクション・プラグインの属性とその説明は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のOracle Internet Directoryの構成スキーマ要素に関する説明を参照してください。

36.1.1.2 バックグラウンドのデータベース・プロセス

ガベージ・コレクション・プラグインによって起動されるバックグラウンドのデータベース・プロセスには、ガベージ・コレクタやOracle Internet Directory統計情報コレクタがあります。

36.1.1.2.1 ガベージ・コレクタ

次のガベージ・コレクタの動作を設定して管理できます。

- 起動時間

- パージするデータの経過時間

- 実行頻度

- パージするデータの種類

- 一度にパージするエントリの数

36.1.1.2.2 事前定義のガベージ・コレクタ

Oracle Internet Directoryのデフォルトのインストールに含まれている事前定義済ガベージ・コレクタは、次のとおりです。

- 変更ログのガベージ・コレクタ: ディレクトリ内のコンシューム済変更ログ・エントリをクリーンアップします。このガベージ・コレクタのコンテナは、
cn=changelog purgeconfig,
cn=purgeconfig,cn=subconfigsubentryです。

- 一般統計のガベージ・コレクタ: ディレクトリの一般統計情報をモニタリングするためにOracle Internet Directoryサーバー管理機能により作成され、使用されなくなったエントリをクリーンアップします。このガベージ・コレクタのコンテナは、
cn=general stats purgeconfig,
cn=purgeconfig,cn=subconfigsubentryです。

- 状況統計のガベージ・コレクタ: ディレクトリの状況統計情報をモニタリングするためにOracle Internet Directoryサーバー管理機能により作成され、使用されなくなったエントリをクリーンアップします。このガベージ・コレクタのコンテナは、cn=health stats purgeconfig,
cn=purgeconfig,cn=subconfigsubentryです。

- セキュリティおよびリフレッシュ・イベントのガベージ・コレクタ: ディレクトリのセキュリティおよびリフレッシュ・イベントをモニタリングするためにOracle Internet Directoryサーバー管理機能により作成され、使用されなくなったエントリをクリーンアップします。このガベージ・コレクタのコンテナは、cn=secrefresh events purgeconfig,
cn=purgeconfig,cn=subconfigsubentryです。

- システム・リソース・イベントのガベージ・コレクタ: ディレクトリのシステム・リソース・イベントをモニタリングするためにOracle Internet Directoryサーバー管理機能によって作成され、使用されなくなったエントリをクリーンアップします。このガベージ・コレクタのコンテナは、cn=sysresource events purgeconfig,
cn=purgeconfig,cn=subconfigsubentryです。

- ツームストンのガベージ・コレクタ: ディレクトリ内で削除済とマークされている、使用されなくなったエントリをクリーンアップします。このガベージ・コレクタのコンテナは、
cn=tombstone purgeconfig,
cn=purgeconfig,cn=subconfigsubentryです。

- LDAPパフォーマンス・モニタリング・ガベージ・コレクタ: LDAPサーバー・パフォーマンス統計データをクリーンアップします。このガベージ・コレクタのコンテナは、cn=perf stats purgeconfig,cn=purgeconfig,cn=subconfigsubentryです。

- LDAPバインド・パフォーマンス・モニタリング・ガベージ・コレクタ: セキュリティ・イベント追跡用に収集されたバインド・パフォーマンス・データをクリーンアップします。このガベージ・コレクタのコンテナは、cn=bindsec stats purgeconfig,cn=purgeconfig, cn=subconfigsubentryです。

- LDAP比較パフォーマンス・モニタリング・ガベージ・コレクタ: セキュリティ・イベント追跡用に収集された比較パフォーマンス・データをクリーンアップします。このガベージ・コレクタのコンテナは、cn=comparesec stats purgeconfig, cn=purgeconfig,cn=subconfigsubentryです。

- LDAP比較失敗パフォーマンス・モニタリング・ガベージ・コレクタ: セキュリティ・イベント追跡用に収集された比較失敗パフォーマンス・データをクリーンアップします。このガベージ・コレクタのコンテナは、cn=comparefailure stats purgeconfig,cn=purgeconfig,cn=subconfigsubentryです。

関連項目:

- 第25.1.1項「Oracle Internet Directoryサーバー管理機能」

- 『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のOracle Internet Directoryの構成スキーマ要素に関する説明

注意:
事前定義済ガベージ・コレクタは削除しないことをお薦めします。これらのガベージ・コレクタを1つ以上削除すると、不要なデータが増加し、最終的には使用可能なすべてのディスク領域を使い果すことになります。
ただし、動作をカスタマイズするために、事前定義済ガベージ・コレクタを変更してもかまいません。

36.1.1.2.3 Oracle Internet Directory統計情報コレクタ

次のOracle Internet Directory統計情報コレクタの動作を設定して管理できます。

- 起動時間

- 実行頻度

Oracle Internet Directory統計情報コレクタは、Oracle Internet Directoryに関する統計情報を収集します。このバックグラウンド・データベース・プロセスのコンテナは、
cn=oidstats_config,
cn=purgeconfig,cn=subconfigsubentryです。

36.1.2 Oracle Internet Directoryガベージ・コレクションの動作

図36-1に、変更ログ・エントリをパージするガベージ・コレクタの操作の例を示します。

図36-1 例: 変更ログ・エントリのガベージ・コレクション

図36-1の例に示すとおり、ガベージ・コレクション・プロセスは、次のように動作します。

1. LDAPクライアントが、特定のガベージ・コレクション操作リクエストをディレクトリ・サーバーに送信します。これらの操作には、ツームストンのエントリまたは変更ログのエントリのパージなどがあります。

2. ディレクトリ・サーバーが、リクエストをガベージ・コレクション・プラグインに渡します。

3. ガベージ・コレクション・プラグインが、Oracle Internet Directoryで指定されたデータベースのガベージ・コレクション・エンジンにリクエストを送信します。

4. ガベージ・コレクション・エンジンが、対応するバックグラウンド・データベース・プロセス(この場合は、変更ログのガベージ・コレクタ)をトリガーします。バックグラウンド・データベース・プロセスは、その構成で指定されているパラメータに従って動作します。

36.1.3 ガベージ・コレクタ・エントリとOracle Internet Directory統計情報コレクタ・エントリ

各ガベージ・コレクタ・エントリは、動作を指定する属性を持ち、エントリcn=subconfigsubentryの直下にあるエントリcn=purgeconfigに存在します。

関連項目:
ガベージ・コレクタの各属性の詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のOracle Internet Directoryの構成スキーマ要素に関する説明を参照してください。

Oracle Internet Directory統計情報コレクタ・エントリは、属性を持ち、エントリcn=subconfigsubentryの直下にあるエントリcn=purgeconfigにも存在します。

図36-2に、これらのエントリの場所を示します。

図36-2 DIT内のガベージ・コレクション・エントリ

36.1.4 変更ログのパージ

レプリケーションとOracle Directory Integration Platformはいずれも変更ログを使用して、サプライヤ・ディレクトリの情報をコンシューマ・ディレクトリに伝達します。変更ログはすべてods_chg_logという表に格納されます。また、レプリケーション変更ログはasr_chg_logに格納されます。変更ログのガベージ・コレクタが実行されると、どの変更ログ・コンシューマからも必要とされなくなった変更ログがパージされます。これで、Oracle Internet Directoryデータベースで変更ログ・ストアが大きくなりすぎるのを防ぐことができます。

変更ログのガベージ・コレクタでは、次の2つの方法でパージする変更ログを決定します。

- 変更番号ベースのパージ
変更番号ベースのパージでは、すべての変更ログ・コンシューマの変更ステータスが考慮されます。つまり、変更ログは、すべてのコンシューマによってコンシュームされてからパージされます。変更ログのガベージ・コレクタを実行すると、レプリケーション、Oracle Directory Integration Platformおよびその他のコンシューマによってコンシュームされたすべての変更ログがパージされます。

- 時間ベースのパージ
時間ベースのパージは、特定の時間が経過した変更ログのパージを目的としたフォールバック方法です。この方法では、すべての変更ログ・サブスクライバによってコンシュームされていないものであっても、古い変更ログが確実にパージされます。時間ベースのパージは、他のコンシューマの変更ステータスではなく、レプリケーションの変更ステータスに従います。変更ログのガベージ・コレクタは、レプリケーションで必要とされず、かつorclpurgetargetageの時間以上が経過したすべての変更ログをパージします。orclpurgetargetageがゼロの場合、変更ログのガベージ・コレクタはすぐにこの動作を実行します。orclpurgetargetageが無効な数値である場合や、定義されていない場合のデフォルト値は、240時間(10日)です。レプリケーションで必要とされる変更ログは、レプリケーションでコンシュームされた後でパージされます。

Oracle Directory Integration Platformがデプロイされているときに時間ベースのパージを有効にする場合は、変更ログがOracle Directory Integration Platformによって処理されてからパージされるように、orclpurgetargetageを十分に大きな値に設定してください。値を240にすると、10日が経過してから変更ログがパージされます。

第36.5項「時間ベースの変更ログのパージの構成」を参照してください。

36.2 ガベージ・コレクション用のOracle Databaseタイムゾーンの設定

Oracle Internet Directoryガベージ・コレクション・ロジックが正しく動作するようにするには、Oracle Databaseのdbtimezoneパラメータを協定世界時(UTC)からの適切な置換値に設定する必要があります。次のようにします。

1. 次のように、PL/SQLを起動します。

$ sqlplus /nolog
SQL> connect / as sysdba

2. 次のように、dbtimezoneの値を取得するための問合せを実行します。

SQL> select dbtimezone from dual;

3. 次のように、協定世界時(UTC)からの置換値を取得するための問合せを実行します。

SQL> select systimestamp from dual;

出力は次のようになります。

SYSTIMESTAMP
---------------------------------------
31-JAN-09 01.04.42.281000 PM -05:00

systimestamp出力の最終列を取得します。この例では、-05:00です。

4. dbtimezoneパラメータがsystimestamp出力の最終列の値と同じである場合、残りの手順を実行する必要はありません。それ以外の場合は、手順5に進みます。

5. 第8章「Oracle Internet Directoryインスタンスの管理」で説明しているように、Oracle Databaseを使用しているすべてのOracle Internet Directoryインスタンスを停止します。

6. 次にように、systimestamp問合せの最終列から取得した値を使用して、dbtimezoneパラメータを設定します。

SQL> ALTER DATABASE SET TIME_ZONE = '-05:00';

7. Oracle Databaseを停止します。

SQL> shutdown immediate

8. Oracle Databaseを再起動します。

SQL> startup

9. 第8章「Oracle Internet Directoryインスタンスの管理」の説明に従って、Oracle Internet Directoryを再起動します。

関連項目:
dbtimezoneパラメータの詳細は、『Oracle OLAP DMLリファレンス』を参照してください。

36.3 Oracle Internet Directoryガベージ・コレクタの変更

この項の項目は次のとおりです。

- 第36.3.1項「Oracle Directory Services Managerを使用したガベージ・コレクタの変更」

- 第36.3.2項「コマンド行ツールを使用したガベージ・コレクタの変更」

- 第36.3.3項「Oracle Internet Directory統計情報コレクタの変更」

36.3.1 Oracle Directory Services Managerを使用したガベージ・コレクタの変更

ガベージ・コレクタを変更する手順は、次のとおりです。

1. 第7.4.5項「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動し、Oracle Internet Directoryサーバーに接続します。

2. タスク選択バーで、「拡張」を選択します。

3. 左側のペインで「ガベージ・コレクション」を展開し、変更するガベージ・コレクタを選択します。右側のペインに「ガベージ・コレクタ」ウィンドウが表示されます。

4. ガベージ・コレクタ・ウィンドウで、このガベージ・コレクタに対する変更を入力します。

5. 「適用」を選択します。

36.3.2 コマンド行ツールを使用したガベージ・コレクタの変更

この項では、コマンド行ツールを使用してガベージ・コレクタを変更する方法の例を示します。変更できるガベージ・コレクション属性は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のOracle Internet Directoryの構成スキーマ要素に関する説明を参照してください。

36.3.2.1 例1: ガベージ・コレクタの変更

削除済とマークされたエントリのガベージ・コレクタをすぐに実行するとします。LDIFファイルは次のようになります。

dn: cn=tombstone purgeconfig, cn=purge config, cn=subconfigsubentry
changetype:modify
replace: orclpurgenow
orclpurgenow: 1

ldapmodifyを使用して、このエントリをロードします。

ldapmodify -D "cn=orcladmin" -q -h hostname -p port \
-D username -f file_name_of_defined_entry

36.3.2.2 例2: ガベージ・コレクタの変更ログの使用禁止

変更ログのガベージ・コレクタを使用禁止にするとします。

dn: cn=changelog purgeconfig, cn=purgeconfig, cn=subconfigsubentry
changetype: modify
replace: orclpurgeenable
orclpurgeenable: 0

ldapmodifyを使用して、このエントリをロードします。

ldapmodify -D "cn=orcladmin" -q -h hostname -p port \
-D username -f file_name_of_defined_entry

36.3.3 Oracle Internet Directory統計情報コレクタの変更

Oracle Internet Directory統計情報コレクタは、ガベージ・コレクタと同じ方法で変更しますが、変更可能なフィールドは3つのみです。

36.4 Oracle Internet Directoryガベージ・コレクタのロギングの管理

この項の項目は次のとおりです。

- 第36.4.1項「Oracle Internet Directoryガベージ・コレクタのロギングの有効化」

- 第36.4.2項「Oracle Internet Directoryガベージ・コレクタのロギングの無効化」

- 第36.4.3項「ガベージ・コレクションのロギングのモニタリング」

36.4.1 Oracle Internet Directoryガベージ・コレクタのロギングの有効化

ガベージ・コレクタのロギングを有効にすると、ディレクトリ・サーバーは、ファイル・システム内のファイルに、情報を書き込みます。これには次の情報が含まれます。

- ジョブ識別子

- ガベージ・コレクタのジョブ説明

- パージされたエントリ数

- 操作のステータス

- タイムスタンプ

- 捕捉されたエラー

ガベージ・コレクション情報のロギングを有効にする手順は、次のとおりです。

1. orclpurgedebug属性を必要に応じて1に設定します。orclpurgedebugが1に設定されている場合、特別なデバッグ詳細情報が記録されるため、ガベージ・コレクションの問題をトラブルシューティングする際に役立ちます。

2. ログ・ファイルの有効なファイル名(oidgc001.logなど)を、orclpurgefilename属性に設定します。

3. ログ・ファイルのあるディレクトリのパス名(/private/mydir/oracle/ldap/logなど)を、orclpurgefileloc属性に設定します。

4. 手順3で指定したディレクトリへのPL/SQL I/Oアクセスを有効にします。これには、次の内容をデータベースに指定します。

UTL_FILE_DIR=PATH_NAME

PATH_NAMEは、手順3で指定したパスです。

関連項目:
『Oracle Databaseリファレンス』のUTL_FILE_DIRパラメータ・タイプに関する項

5. レプリケーション・サーバーを停止し、次にOracle Internet Directoryサーバーを停止します。

6. データベースを再起動します。

7. Oracle Internet Directoryサーバーを起動し、次にレプリケーション・サーバーを起動します。

36.4.2 Oracle Internet Directoryガベージ・コレクタのロギングの無効化

ガベージ・コレクション情報のロギングを無効にするには、orclpurgedebug属性を0に設定します。

注意:
orclpurgedebugが0に設定されている場合も、ガベージ・コレクタの処理を示すために、ガベージ・コレクタの操作に関する最小限の情報が記録されます。

36.4.3 ガベージ・コレクションのロギングのモニタリング

ガベージ・コレクションのログの情報は、ガベージ・コレクションのモニタリングとトラブルシューティングに役立ちます。このログの場所は、ロギングを有効にする際に属性を設定して指定します。たとえば、次のように構成したとします。

orclpurgefilename = oidgc001.log
orclpurgefileloc     = /private/mydir/oracle/ldap/log

ロギングを有効にすると、/private/mydir/oracle/ldap/log/oidgc001.logファイルを読み取ることによって変更ログのガベージ・コレクションの処理をモニターできます。

次に、管理者が変更ログのガベージ・コレクション構成エントリのorclpurgenow属性を変更した場合に記録される情報の例を示します。

Running Garbage Collector: cn=changelog purgeconfig
Starting time: 2005/03/24 11:03:23
PurgeConfig object located, Eid= 936
purge_ODSChglog: Nothing to be purged(no_work_to_do)
purge_ODSChglog: 107 chglogs successfully purged
purge_ASRChglog: Nothing to be purged(no_work_to_do)
purge_ASRChglog: 0 chglogs successfully purged
purge_ASRChglog: 0 chglogs successfully purged

Modifying Garbage Collector for at "2005/03/24 11:03:23
Garbage Collector DN recognized, rdn=cn=changelog purgeconfig
orclPurgeNow successfully retrieved.
Garbage Collector job found: jobno=21
Garbage Collector has been run
Garbage collector is updated successfully!

orclpurgenowの変更により、変更ログのガベージ・コレクタがすぐに実行されます。最初のパラグラフで示されているように、ods_chg_log表から107個の変更ログがパージされ、asr_chg_log表からは0個の変更ログがパージされています。また、2番目のパラグラフの情報は、orclpurgenow属性が正常に変更されたことを示しています。

36.5 時間ベースの変更ログのパージの構成

変更ログのパージについては、第36.1.4項「変更ログのパージ」で説明しています。時間ベースのパージは、変更ログ・パージ構成エントリのorclpurgetargetage属性を変更して構成します。次の例では、120時間(5日)の時間ベースのパージを構成しています。次のようなLDIFファイルを使用します。

dn: cn=changelog purgeconfig,cn=purgeconfig,cn=subconfigsubentry
changetype:modify
replace: orclpurgetargetage
orclpurgetargetage: 120

LDIFファイルmod.ldifを適用するには、次のように入力します。

ldapmodify -D "cn=orcladmin" -q -p port -h host -f mod.ldif

注意:
変更ログのガベージ・コレクタのコンテナは、次のとおりです。cn=changelog purgeconfig, cn=purgeconfig,cn=subconfigsubentry

関連項目:
『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のOracle Internet Directoryの構成スキーマ要素に関する説明

37 他のデータ・リポジトリからのデータの移行

この章では、LDAPバージョン3準拠のディレクトリおよびアプリケーション固有のデータ・リポジトリからOracle Internet Directoryにデータを移行する方法について説明します。

この章の内容は次のとおりです。

- 第37.1項「他のデータ・リポジトリからのデータの移行の概要」

- 第37.2項「LDAP準拠のディレクトリからのデータの移行」

- 第37.3項「ユーザー・データのアプリケーション固有リポジトリからの移行」

37.1 他のデータ・リポジトリからのデータの移行の概要

Oracle Internet Directoryのインストール時に、Oracle Identity Management 11gインストーラによって、デフォルトのスキーマとディレクトリ情報ツリー(DIT)が作成されます。このデフォルトのDITフレームワークの詳細は、第3章「Oracle Internet Directoryの概念およびアーキテクチャの理解」および第34章「レルムの計画、デプロイおよび管理」を参照してください。このフレームワークには柔軟性があるため、デプロイメント要件に応じて適切に変更できます。

Oracle Internet Directoryでは、次のディレクトリ要素がデフォルトで作成されます。

- ルートOracleコンテキスト(cn=OracleContext): 企業全体の構成データがOracle製品によって格納されるコンテナです。

- デフォルトのアイデンティティ管理レルム(dc=dns_domain_of_host,dc=com): Oracle製品によるエンタープライズ・ユーザーおよび企業グループの検索対象となるコンテナです。これは、企業DIT構造に類似しています。たとえば、my_computer.us.my_company.comというホスト名のコンピュータにOracle Internet Directoryをインストールする場合、Oracle Internet Directoryのインストール時に作成されるデフォルトのアイデンティティ管理レルムは、dc=us,dc=my_company,dc=comとなります。Oracle製品による検索対象となるのは、コンテナcn=users,dc=us,dc=my_company,dc=comの下のすべてのユーザー、およびcn=groups,dc=us,dc=my_company,dc=comの下のすべてのグループです。デフォルトのアイデンティティ管理レルム・エントリの作成に加えて、他のOracle Internet Directory対応コンポーネントが自動的にブートストラップされるよう、Oracle Internet Directoryコンフィギュレーション・アシスタントによってルートOracleコンテキストにポインタが格納されます。

このデフォルトのアイデンティティ管理レルムは、デプロイメント要件に応じて変更してもかまいません。

37.2 LDAP準拠のディレクトリからのデータの移行

この項では、LDAP準拠のサード・パーティのディレクトリからOracle Internet Directoryにデータを移行する際に役立つ情報を提供します。すでに確立された構造を持つディレクトリが存在し、データをそのディレクトリからデフォルトのディレクトリ構造の環境に移行する場合は、この項の指示に従ってください。

データの移行に使用される一般的なツールには、bulkloadおよびsyncProfileBootstrapの2つがあります。表37-1「bulkloadとsyncProfileBootstrapの機能」では、bulkloadとsyncProfileBootstrapの機能の比較を示します。

表37-1 bulkloadとsyncProfileBootstrapの機能

機能

bulkload

syncProfileBootstrap

速度

高速

低速

データ転送方式

SQL

LDAP

受け入れ可能な入力のタイプ

LDIFファイルのみ

LDIFファイル、LDAPディレクトリ、タグ付きファイル、CSVファイル

データの変換

いいえ

はい

LDIF入力の検証

はい

いいえ

関連項目:

- bulkloadの構文情報と例は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のOracle Internet Directoryデータ管理ツールに関する説明を参照してください。

- syncProfileBootstrapの詳細は、『Oracle Fusion Middleware Oracle Directory Integration Platform管理者ガイド』を参照してください。

37.2.1 LDIFファイルとbulkloadを使用したLDAPデータの移行

バルク・ローダー(bulkload)は、大量のエントリをディレクトリ・サーバーにロードするためのコマンド行ツールです。このツールでは、Oracle SQL*Loaderを使用してディレクトリ・エントリをロードします。bulkloadツールの入力ファイルの形式は、LDAP Data Interchange Format(LDIF)である必要があります。bulkloadツールでは、LDIF入力の参照整合性を検証できますが、データに対してマッピングやその他の変換を実行することはできません。

変換が不要でデータが非常に大きい(50万件以上)場合、サード・パーティのディレクトリからOracle Internet Directoryにデータを移行するにはbulkloadが最も適しています。これは高速で、LDIF入力の検証が可能です。

この方法を使用する場合は、図37-1「LDIFファイルとbulkloadの使用」に示すように、まずサード・パーティのディレクトリからLDIFファイルにデータをエクスポートする必要があります。

図37-1 LDIFファイルとbulkloadの使用

LDIFは、LDAP準拠のディレクトリのデータをファイルとして表現するためのASCII交換フォーマットで、IETFによる承認を受けています。すべてのLDAP準拠のディレクトリには、エクスポート時にDITを表す1つ以上のLDIFファイルにその内容をエクスポートするツールがあります。

関連項目:
IETFのRFC 2849は、http://www.ietf.orgで入手可能です。

LDIFファイルとbulkloadを使用してデータをOracle Internet Directoryに移行するには、次のタスクを実行する必要があります。

タスク1: 非Oracle Internet DirectoryサーバーからLDIFファイル形式へのデータのエクスポート

エクスポートの方法については、ベンダーが提供するマニュアルを参照してください。外部のディレクトリからデータをエクスポートするためのフラグまたはオプションが存在する場合は、必ず次の方法を選択してください。

- 最小の独自情報が含まれるLDIF出力を生成する方法

- http://www.ietf.orgで入手可能なIETF RFC 2849に最も準拠している方法

タスク2: LDIFデータで参照される必須スキーマの追加のためのLDIFユーザー・データの分析

Oracle Internet Directoryベース・スキーマ内で検索できない属性については、LDIFファイルをインポートする前に、Oracle Internet Directoryベース・スキーマの拡張が必要です。一部のディレクトリでは、そのベース・スキーマへの拡張を定義するための構成ファイルの使用をサポートしている場合があります(Oracle Internet Directoryではサポートしていません)。構成ファイルがある場合は、「タスク3: Oracle Internet Directory内のスキーマの拡張」において、Oracle Internet Directory内のベース・スキーマを拡張するためのガイドラインとしてそのファイルを使用できます。

タスク3: Oracle Internet Directory内のスキーマの拡張

Oracle Internet Directoryにおけるディレクトリ・スキーマの拡張方法に関するヒントは、第21章「ディレクトリ・スキーマの管理」を参照してください。この作業は、Oracle Directory Services ManagerまたはSchemaSynchツール(『Oracle Fusion Middleware Oracle Identity Managementリファレンス』を参照)を使用して実行できます。

他のOracle製品を使用するユーザーがいる場合は、オブジェクト・クラスがorclUserV2で必須属性を持ったユーザーを作成する必要があります。Active Directoryとの統合には、オブジェクト・クラスがorclADUserで必須属性を持ったユーザーを作成する必要があります。これらのオブジェクト・クラスとその属性の詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』を参照してください。

タスク4: LDIFファイルからの独自のディレクトリ・データの削除

ACI属性など、LDAP v3標準の一部の要素は、まだ正式なものではありません。その結果、様々なディレクトリ・ベンダーがベンダー間で正常に変換できない方法で、ACIポリシー・オブジェクトを実装しています。

クリーンアップされたLDIFファイルからOracle Internet Directoryに基本エントリ・データをインポートした後、Oracle Internet Directory環境でセキュリティ・ポリシーを明示的に再適用する必要があります。この作業は、Oracle Directory Services Managerまたはコマンド行ツールと、必要なACP情報を含むLDIFファイルを使用して実行できます。

この他にもアクセス制御に関連しない独自のメタデータが含まれている場合があります。これも同様に削除する必要があります。様々なIETF RFCを理解することで、どのディレクトリ・メタデータが特定のベンダー独自のものであり、どれがLDAP規格に準拠していてLDIFファイルによって移植できるかを判断できます。

タスク5: LDIFファイルからの操作属性の削除

エントリが作成またはインポートされるたびに、標準のLDAPバージョン3の操作属性のうち、creatorsName、createTimestamp、modifiersNameおよびmodifyTimestampの4つの属性が、Oracle Internet Directoryによって自動的に生成されます。たとえば、LDIFファイルのインポートを使用して、既存のディレクトリ・データからこれらの値をインスタンス化することはできません。したがって、インポートを試行する前に、これらの属性をファイルから削除する必要があります。

タスク6: LDIFファイルからの非互換のuserPassword属性値の削除

Oracle Internet DirectoryでサポートされているuserPassword属性のハッシュ・アルゴリズムの詳細は、第9.1.5項「DSEの属性」のorclcryptoschemeエントリを参照してください。

一部のベンダー製品で使用されているuserPassword属性のハッシュ値は、Oracle Internet Directoryと互換性がありません。このため、プレーン・テキストで表されているか、または値が含まれていない場合を除き、userPassword属性と値に対応する行はすべてLDIFデータ・ファイルから削除する必要があります。LDIFデータをインポートした後、手動で再入力するか、またはハッシュされたuserPassword情報を別途ディレクトリにアップロードする必要があります。パスワードがOracle Internet Directoryパスワード・ポリシーに準拠し、クリアテキストになっていることを確認します。

タスク7: bulkload check =TRUE"モードの実行とスキーマ違反または重複エラーが残っているかどうかの判断

LDIFファイルを生成してロードする前に、必ずbulkloadユーティリティのチェック・モードを使用してLDIFファイルのチェックを実行してください。bulkloadの出力によって、データにおける不整合が報告されます。

関連項目:
bulkloadのチェック・モードの使用方法は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のbulkloadコマンド行ツールのリファレンスを参照

37.2.2 syncProfileBootstrapを直接使用したLDAPデータの移行

ディレクトリ統合アシスタントであるsyncProfileBootstrapは、Oracle Directory Integration Serverによってスケジュールされた同期プロファイルを管理するためのコマンド行ツールです。管理者は、Oracle Directory Integration Serverで継続的に同期を実行するように構成する際に、syncProfileBootstrap操作を使用して、接続ディレクトリとOracle Internet Directoryとの間で初期のデータ移行を実行できます。この操作は、継続した同期のない、1回かぎりのデータの移行にも使用できます。

syncProfileBootstrap操作では、データをサード・パーティのLDAP準拠ディレクトリから直接受け取るか、LDIFファイル、タグ付きファイルまたはCSVファイルから受け取ることができます。同期プロファイルまたは構成ファイルのいずれかで、マッピング・ルールを指定する必要があります。

syncProfileBootstrapの構文情報、構成ファイルのプロパティ、入力ファイルのタイプに関する情報および例の詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のOracle Directory Integration Platformツールに関する説明、および『Oracle Fusion Middleware Oracle Directory Integration Platform管理者ガイド』を参照してください。

サード・パーティのディレクトリからOracle Internet Directoryにデータを移行するときにマッピングを実行する必要があり、データのサイズが小さい場合は、syncProfileBootstrapを使用できます。図37-2「syncProfileBootstrapの直接の使用」に示すように、サード・パーティのディレクトリ自体をsyncProfileBootstrapへの入力として使用できます。

図37-2 syncProfileBootstrapの直接の使用

37.2.3 LDIFファイルとsyncProfileBootstrapを使用したLDAPデータの移行

使用例3は、使用例2のバリエーションです。サード・パーティのディレクトリに直接アクセスできない場合は、管理者に依頼してデータをLDIFファイルにエクスポートすることができます。図37-3「LDIFファイルとsyncProfileBootstrapの使用」に示すように、syncProfileBootstrapはLDIFファイルから入力を受け取ることができます。また、Oracle Directory Integration Serverを使用してデータを移行することもできます。

図37-3 LDIFファイルとsyncProfileBootstrapの使用

LDIFファイルとbulkloadを使用してデータをOracle Internet Directoryに移行する場合には、いくつかのタスクを実行する必要があります。この使用例では、syncProfileBootstrapまたはOracle Directory Integration Platformとともにマッピング・ファイルを使用するため、「LDIFファイルとbulkloadを使用したLDAPデータの移行」に示されているすべてのタスクを実行する必要はありません。実行する必要のあるタスクは、次のとおりです。

- タスク1: 非Oracle Internet DirectoryサーバーからLDIFファイル形式へのデータのエクスポート

- タスク2: LDIFデータで参照される必須スキーマの追加のためのLDIFユーザー・データの分析

- タスク3: Oracle Internet Directory内のスキーマの拡張

37.2.4 syncProfileBootstrap、bulkloadおよびLDIFファイルを使用したLDAPデータの移行

大量のデータがあり、データにマッピングを実行する必要がある場合は、ツールを組み合せて使用することができます。図37-4「syncProfileBootstrap、bulkloadおよびLDIFファイルの使用」に示すように、サード・パーティのディレクトリからLDIFファイルにデータをエクスポートし、syncProfileBootstrapを使用して別のLDIFファイルにデータをマッピングして、そのファイルをbulkloadでロードできます。

図37-4 syncProfileBootstrap、bulkloadおよびLDIFファイルの使用

第37.2.3項「LDIFファイルとsyncProfileBootstrapを使用したLDAPデータの移行」に示すように、実行する必要のあるタスクは、次のとおりです。

- タスク1: 非Oracle Internet DirectoryサーバーからLDIFファイル形式へのデータのエクスポート

- タスク2: LDIFデータで参照される必須スキーマの追加のためのLDIFユーザー・データの分析

- タスク3: Oracle Internet Directory内のスキーマの拡張

37.2.5 Oracle Directory Integration Platform Serverを使用したLDAPデータの移行

場合によっては、管理者はOracle Directory Integration Serverを構成するときに、syncProfileBootstrapを使用しないことがあります。Oracle Directory Integration Serverの構成後は、このサーバー自体で接続ディレクトリからOracle Internet Directoryにデータを移行できます。また、Oracle Directory Integration Serverを1回かぎりのデータの移行に使用することもできます。詳細は、『Oracle Fusion Middleware Oracle Directory Integration Platform管理者ガイド』を参照してください。

Oracle Directory Integration Serverを使用すると、図37-5「Oracle Directory Integration Serverの使用」に示すように、Oracle Internet Directoryとサード・パーティのディレクトリの間に双方向で継続的な統合を構成できます。詳細は、『Oracle Fusion Middleware Oracle Directory Integration Platform管理者ガイド』を参照してください。

図37-5 Oracle Directory Integration Serverの使用

37.3 ユーザー・データのアプリケーション固有リポジトリからの移行

ユーザー・データをアプリケーション固有のリポジトリから移行するには、次の処理が必要です。

- ユーザー・データをアプリケーション固有のリポジトリから収集し、ディレクトリが読み込める書式に設定します。

- ディレクトリ管理者がそのデータを使用できるようにします。ディレクトリ管理者は、次の作業を行う必要があります。

- ディレクトリ内でデータを格納する場所を指定します。

- データをディレクトリにインポートします。

37.3.1 中間テンプレート・ファイル

この移行を実行するには、Oracle Directory Provisioning Integration Serviceで、アプリケーション固有のリポジトリを使用してそのデータを中間テンプレート・ファイルにエクスポートする必要があります。このテンプレート・ファイル内のレコードは、完全なLDIFにはなっておらず、情報が最終的に格納されるディレクトリ内の場所などに関連する置換変数が含まれています。これらの変数はアプリケーションにより未定義のまま残されるため、ディレクトリ管理者は後で定義できます。

ユーザー・データをこの中間テンプレート・ファイルから適切なLDIFに変換するには、OID移行ツール(ldifmigrator)を使用します。LDIFに変換されたデータは、ディレクトリにロードできます。

要約すると、アプリケーション固有のリポジトリからデータを移行するには、通常、次の手順を実行します。

1. アプリケーション固有のデータを中間テンプレート・ファイルとしてエクスポートします。

2. ディレクトリ管理者は、OID移行ツール(ldifmigrator)を使用して、不完全なLDIFエントリをテンプレート・ファイルからロードし、デプロイメントの選択に基づいて完全なLDIFエントリに変換します。

3. ディレクトリ管理者は、この完全なLDIFのデータをOracle Internet Directoryにロードします。

4. アプリケーションは、独自の仕様に従って移行処理を完了します。

37.3.2 アプリケーション・リポジトリ内のデータとディレクトリの既存データとの調停

アプリケーション固有のリポジトリから移行しているデータが、Oracle Internet Directoryにすでに存在している場合があります。この場合、OID移行ツール(ldifmigrator)の調停機能を使用して、2つのディレクトリ間の差分を調整できます。

関連項目:
OID移行ツールの調停機能の詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のldifmigratorコマンド行ツールのリファレンスを参照

37.3.3 アプリケーション固有のリポジトリからデータを移行するためのタスク

アプリケーション固有のリポジトリからデータを移行するには、中間テンプレート・ファイルを作成してから、OID移行ツールを実行します。

37.3.3.1 タスク1: 中間テンプレート・ファイルの作成

各国語のデータを生成するアプリケーションでは、中間テンプレート・ファイルにデータをAL32UTF8で格納する必要があります。詳細は、http://www.ietf.orgで、IETFのRFC 2849「The LDAP Data Interchange Format(LDIF)- Technical Specification(LDAP Data Interchange Format(LDIF) - 技術仕様)」を参照してください。

中間テンプレート・ファイルの生成時に、移行を実行するアプリケーションでは、RFC 2849で定義されているレコード・セパレータを使用して、すべてのユーザー・レコードを順にリストする必要があります。OID移行ツール(ldifmigrator)は、デフォルトのアイデンティティ管理レルム(企業自体に対応しています)にすべてのユーザーを割り当てます。

図37-6に、ユーザー・エントリが格納される中間テンプレート・ファイルの全体構造を示します。

図37-6 中間ユーザー・ファイルの構造

中間テンプレート・ファイルでは、次の形式を使用して、有効なユーザー・エントリが生成されます。太字の文字列は、すべてアプリケーション固有のリポジトリから提供されます。

dn: cn=UserID, %s_UserContainerDN%
sn: Last_Name
orclGlobalID: GUID_for_User
%s_UserNicknameAttribute%: UserID
objectClass: inetOrgPerson
objectClass: orclUserV2

このテンプレートの文字列%s_UserContainerDN%と%s_UserNicknameAttribute%は置換変数で、OID移行ツールによって値が提供されます。OID移行ツールは、デプロイメントに固有な考慮事項に従ってこれらの値を判別します。引数は、アプリケーションがOID移行ツールに渡すか、ツールがディレクトリから取得します。

37.3.3.1.1 例: 中間テンプレート・ファイル内のユーザー・エントリ

次の中間テンプレート・ファイルには、アプリケーション固有の移行ロジックによって生成されたユーザー・エントリが格納されます。この例にある太字のデータは、すべてアプリケーション固有のユーザー・リポジトリから提供されます。

dn: cn=jdoe, %s_UserContainerDN%
sn: Doe
%s_UserNicknameAttribute%: jdoe
objectClass: inetOrgPerson
objectClass: orclUserV2
title: Member of Technical Staff
homePhone: 415-584-5670
homePostalAddress: 234 Lez Drive$ Redwood City$ CA$ 94402

dn: cn=jsmith, %s_UserContainerDN%
sn: Smith
%s_UserNicknameAttribute%: jsmith
objectClass: inetOrgPerson
objectClass: orclUserV2
title: Member of Technical Staff
homePhone: 650-584-5670
homePostalAddress: 232 Gonzalez Drive$ San Francisco$ CA$ 94404

dn: cn=lrider, %s_UserContainerDN%
sn: Rider
%s_UserNicknameAttribute%: lrider
objectClass: inetOrgPerson
objectClass: orclUserV2
title: Senior Member of Technical Staff
homePhone: 650-584-5670

中間ファイルの形式に変換されたすべてのユーザー・データは、さらに、OID移行ツールによって、Oracle Internet Directoryにロード可能な適切なLDIFファイルに変換されます。

中間テンプレート・ファイルの例は、$ORACLE_HOME/ldap/schema/oidにあります。

37.3.3.1.2 ユーザー・エントリの属性

各ユーザー・エントリには、必須とオプションの属性があります。

表37-2に、ユーザー・エントリの必須属性を示します。

表37-2 ユーザー・エントリの必須属性

属性

説明

dn

適切な置換変数を持つユーザー・エントリの識別名。エントリの相対識別名には、必ずcn属性を含める必要があります。

sn

ユーザーの姓。

objectclass

エントリが最小限、属する必要があるオブジェクト・クラス。inetOrgPersonおよびorclUserV2があります。

関連項目:

- inetOrgPersonオブジェクト・クラスの各属性については、http://www.ietf.orgで、IETFのRFC 2798「Definition of the inetOrgPerson LDAP Object Class(inetOrgPerson LDAPオブジェクト・クラスの定義)」を参照してください。

- orclUserV2オブジェクト・クラスのオプション属性の詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のOracle Identity Managementのオブジェクト・クラスのリファレンスを参照してください。

37.3.3.2 タスク2: OID移行ツールの実行

中間テンプレート・ファイルを設定すると、OID移行ツールによって、すべての関連データをアプリケーション固有のリポジトリからOracle Internet Directoryに移行できます。データの移行後は、そのアプリケーションとOracle Internet Directoryを同期化することによって、アプリケーションに関連するあらゆるデータを更新できます。同期化には、Oracle Directory Synchronization Serviceを使用します。

関連項目:
OID移行ツールの使用方法は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のldifmigratorコマンド行ツールのリファレンスを参照

38 ディレクトリ・サーバー・チェーンの構成

Oracle Internet Directoryのディレクトリ・サーバー・チェーンによって、外部またはサード・パーティのLDAPディレクトリに存在するエントリをディレクトリ・ツリーの一部にマップして、同期またはデータ移行なしでそれらのエントリにOracle Internet Directoryを通じてアクセスできます。サーバー・チェーンにより、実際のアイデンティティ・データがOracle Internet Directoryの外部にある場合も、Oracle Internet Directoryの認可フレームワークを使用できます。

この章の内容は次のとおりです。

- 第38.1項「サーバー・チェーンの構成の概要」

- 第38.2項「サーバー・チェーンの構成」

- 第38.3項「サーバー・チェーン構成エントリの作成」

- 第38.4項「サーバー・チェーンのデバッグ」

- 第38.5項「パスワード変更通知のActive Directoryプラグインの構成」

注意:
この章で言及するOracle Single Sign-Onは、Oracle Single Sign-On 10g (10.1.4.3.0)以上のことです。Oracle Enterprise User Securityに言及している場合、10gリリースのみを示しています。

38.1 サーバー・チェーンの構成の概要

ディレクトリ・サーバー・チェーンは、Oracle Internet Directory 10g (10.1.4.0.1)で最初に導入され、Javaプラグイン・フレームワークを使用して実装されました。11gリリース1 (11.1.1)では、SSLを使用するようにサーバー・チェーンを構成することもできます。サーバー・チェーンは、Oracle Directory Integration Platformを置き換えることはありませんが、かわりにその製品に補完的な機能を提供します。

サーバー・チェーンは、Oracle Virtual Directoryなどの仮想ディレクトリとは異なります。仮想ディレクトリは、複数のアイデンティティ・リポジトリとアプリケーション間の柔軟な仮想レイヤーです。仮想ディレクトリにより、アイデンティティ同期およびディレクトリ・サーバーに補完的なサービスが提供されます。組織では、複数のディレクトリおよびデータベースにわたる可能性があるデータの統合された論理ビューまたは仮想ビューを作成できます。

この項の内容は次のとおりです。

- 第38.1.1項「外部ディレクトリ・サーバーのサポート」

- 第38.1.2項「統合されたOracle製品」

- 第38.1.3項「サポートされる操作」

- 第38.1.4項「サーバー・チェーンとレプリケーション」

38.1.1 外部ディレクトリ・サーバーのサポート

Oracle Internet Directoryサーバー・チェーンは、次の外部ディレクトリ・サーバーをサポートします。

- Microsoft Active Directory

注意:
Oracle Internet Directoryサーバー・チェーンではMicrosoft Active Directory Lightweight Directory Service (AD LDS、以前のADAM)はサポートされません。

- Oracle Directory Server Enterprise Edition(ODSEE)

- Sun Java System Directory Server (以前のSun ONEまたはiPlanet Directory Server)

- Novell eDirectory

Oracle Internet Directoryでは、1つのActive Directoryサーバー、1つのSun Java System Directory Server、1つのNovell eDirectory、または3つのディレクトリ・サーバーすべてと接続できます。

38.1.2 統合されたOracle製品

次のOracle製品が、Oracle Internet Directoryサーバー・チェーンに統合されました。

- Oracle Single Sign-On 10g (10.1.4.3.0)以上

- Enterprise User Security 10gのみ

38.1.2.1 Oracle Single Sign-On 10g (10.1.4.3.0)以上

サーバー・チェーンが有効な場合、外部ディレクトリのユーザーは、Oracle Internet Directory内(外部リポジトリではなく)でローカルに認証された場合と同様にOracle Single Sign-Onを介してログインできます。

38.1.2.2 Enterprise User Security 10gのみ

Oracle Internet Directoryサーバー・チェーンにより、アイデンティティ・データをOracle Internet Directoryと同期させることなく、Oracle Directory Integration Platformを介してEnterprise User Security 10gを実装できます。アイデンティティ・データは外部リポジトリに置かれたままで、Oracle Internet Directoryのデータ・ストアにはエンタプライズ・ユーザー・セキュリティ関連のメタデータのみが格納されます。

Sun Java System Directory Serverが外部ディレクトリの場合、サーバー・チェーンは、エンタープライズ・ユーザー・セキュリティとのパスワードベースの認証をサポートします。

Active Directoryが外部ディレクトリの場合、サーバー・チェーンは、エンタープライズ・ユーザー・セキュリティとのKerberosベースの認証およびパスワードベースの認証をサポートします。外部ユーザーは、エンタープライズ・ユーザー・セキュリティの認証設定が完了すると、Oracle Databaseにログインできます。詳細は、http://metalink.oracle.comにあるMy Oracle Support(以前のMetaLink)のNote 452385.1に基づいた第38.5項「パスワード変更通知のActive Directoryプラグインの構成」を参照してください。

関連項目:
エンタープライズ・ユーザー・セキュリティのパスワード認証およびKerberos認証用の構成の詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

38.1.3 サポートされる操作

サーバー・チェーンでは、次の操作をサポートします。

- バインド

- 比較

- 変更

- 検索

比較、変更および検索操作は、構成パラメータの設定により有効または無効にできます。

Oracle Internet Directoryクライアント・アプリケーションからLDAP検索リクエストが発行されると、Oracle Internet Directoryは自身のデータと外部ディレクトリからの検索結果を統合します。

Oracle Internet Directoryクライアント・アプリケーションからLDAPバインド、比較または変更リクエストが発行されると、Oracle Internet Directoryはリクエストを外部ディレクトリにリダイレクトします。

10g(10.1.4.0.1)以上では、比較操作はuserpassword属性でのみサポートされています。

10g(10.1.4.0.1)以上では、次の2つの場合に属性変更がサポートされます。

- 外部属性は、Oracle Internet Directory属性と同じ名前を持っています。これは大部分のLDAP属性についても当てはまります。

- 外部属性はOracle Internet Directory属性にマップされ、外部属性とOracle Internet Directory属性のどちらも操作属性ではありません。

注意:
Active Directoryユーザー・パスワードは、Oracle Internet Directoryからサーバー・チェーンを介して変更できません。

38.1.4 サーバー・チェーンとレプリケーション

サーバー・チェーンをレプリケーション環境で使用する場合は、すべてのノード上でサーバー・チェーンを設定し、エントリがノード全体で一貫性を保てるようにします。サーバー・チェーンを構成して、マップされた外部ディレクトリがレプリケートされたすべてのノードにとって同じになるようにします。

38.2 サーバー・チェーンの構成

Oracle Internet Directoryには、サーバー・チェーンの無効のサンプル・エントリが付属しています。サーバー・チェーン・エントリの識別名は、次のとおりです。

- Active Directory: cn=oidscad,cn=OID Server Chaining,cn=subconfigsubentry

- Oracle Directory Server Enterprise EditionおよびSun Java System Directory Server (以前のSun ONEまたはiPlanet): cn=oidsciplanet,cn=OID Server Chaining,cn=subconfigsubentry

- Novell eDirectory: cn=oidscedir,cn=OID Server Chaining,cn=subconfigsubentry

前述のエントリを自分の環境に合うようにカスタマイズし、それらを有効にすることで、サーバー・チェーンを構成します。この構成を実行するには、コマンド行を使用するか、この項の後述の説明に従ってOracle Directory Services Managerを使用します。

11g (11.1.1.9)以降では、cn=OID Server Chaining, cn=subconfigsubentryの下に独自のエントリを追加してサーバー・チェーンを構成できます。この場合、新しいエントリにorcloidscdirtype属性を追加する必要があります。この属性は、サーバー・チェーンを構成する外部ディレクトリを指定し、次のいずれかの値を持つことができます。

- Active Directoryの場合: ad

- Novell eDirectoryの場合: edir

- Sun Java System Directory Serverの場合: iplanet

たとえば、エントリにorcloidscdirtype=edirが含まれる場合、このエントリはeDirectoryとの接続用に構成されていることがわかります。同様に、エントリの独自のセットを持つことができます。

注意:
外部ディレクトリ・サーバー・タイプ用にサポートされるアクティブなエントリは、1つのみです。

この項の内容は次のとおりです。

- 第38.2.1項「Oracle Directory Services Managerを使用したサーバー・チェーンの構成」

- 第38.2.2項「コマンド行からのサーバー・チェーンの構成」

38.2.1 Oracle Directory Services Managerを使用したサーバー・チェーンの構成

Oracle Directory Services Managerには、Oracle Internet Directoryサーバー・チェーン構成エントリの変更に便利なインタフェースが備わっています。

Oracle Directory Services Managerを使用してサーバー・チェーンを構成する手順は、次のとおりです。

1. 第7.4.5項「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動し、Oracle Internet Directoryサーバーに接続します。

2. タスク選択バーで、「拡張」を選択します。

3. 「サーバー・チェーン」を展開します。左側のパネルにサーバー・チェーンのエントリが表示されます。現在のエントリにiPlanet(Oracle Directory Server Enterprise EditionおよびSun Java System Directory Server)とActive Directoryが含まれています。

4. サーバー・チェーン構成エントリを変更するには、そのエントリを選択します。右側のペインに「サーバー・チェーン管理」タブが表示されます。

5. 必要に応じて「外部ホスト名」、「外部ポート番号」、「ログイン・ユーザーDN」および「ログイン・ユーザー・パスワード」を変更します。

6. サーバー・チェーンの認証、変更または検索を有効にするには、対応するチェック・ボックスを選択します。

7. 必要に応じて他のフィールドを変更します。

8. 外部ユーザー・コンテナ、グループ・コンテナまたはログイン資格証明の変更後、それぞれ「ユーザー・コンテナの検証」、「グループ・コンテナの検証」または「ログイン資格証明の検証」 をクリックして値を検証します。
検証に失敗した場合、入力した値に誤りがないか確認します。問題が解消されない場合、外部ディレクトリ管理者に連絡し、入力した値が正しいかどうかを確認します。

9. 属性マッピングを追加する場合は、「属性マッピング」の下の「属性マッピングをリストに追加」アイコンをクリックします。既存のマッピングを編集するには、マッピングを選択して「属性マッピング」の下の「属性マッピングの編集」アイコンをクリックします。新規属性マッピング・ウィンドウが表示されます。「外部ディレクトリ属性」および「OID属性」を入力します。参照によってOracle Internet Directory属性を特定するには、「選択」をクリックして属性の選択ウィンドウで属性を選択します。

10. 「OK」をクリックしてマッピングを作成するか、「取消」をクリックして破棄します。

11. マッピングを削除するには、マッピングを選択して「選択した属性マッピングの削除」アイコンをクリックします。削除の確認ダイアログが表示されたら、「削除」をクリックしてマッピングを削除するか、「取消」削除を取り止めます。

12. 「OK」をクリックして構成の変更を有効にするか、「取消」をクリックして変更を破棄します。

38.2.2 コマンド行からのサーバー・チェーンの構成

コマンド行からサーバー・チェーンを構成するには、次のようにします。

1. LDIFファイルを作成して、手動でユーザーおよびグループのコンテナを追加します。これらのコンテナの識別名を判断するには、第38.3.2項「ユーザー・コンテナとグループ・コンテナの要件」を参照してください。たとえば、ユーザー検索ベースがcn=users,dc=us,dc=oracle,dc=com、グループ検索ベースがcn=groups,dc=us,dc=oracle,dc=comの場合、LDIFファイルで次のエントリを使用します。

dn: cn=AD,cn=users,dc=us,dc=oracle,dc=com
cn: AD
objectclass: orclcontainer
objectclass: top

dn: cn=iPlanet,cn=users,dc=us,dc=oracle,dc=com
cn: iPlanet
objectclass: orclcontainer
objectclass: top

dn: cn=AD,cn=groups,dc=us,dc=oracle,dc=com
cn: AD
objectclass: orclcontainer
objectclass: top

dn: cn=iPlanet,cn=groups,dc=us,dc=oracle,dc=com
cn: iPlanet
objectclass: orclcontainer
objectclass: top

2. ldapaddと、エントリを追加するために作成したLDIFファイルを使用します。

ldapadd -p port -h host -D "binddn" -q -v -f container_ldif_file_name

3. もう1つのLDIFファイルを作成し、サーバー・チェーン構成エントリを変更し、有効にします。LDIFファイルの例は、第38.3.4項「Active Directoryの例」および第38.3.7,項「Oracle Directory Server Enterprise EditionおよびSun Java System Directory Server(iPlanet)の例」を参照してください。属性の表は、第38.3項「サーバー・チェーン構成エントリの作成」を参照してください。属性のマッピングは、第38.3.3項「属性マッピング」を参照してください。

4. ldapmodifyコマンドと作成したLDIFファイルを使用してサーバー・チェーン構成エントリを変更します。次の形式のコマンド行を使用します。

ldapmodify -D "cn=orcladmin" -q -p port -h host -D "binddn" \
-v -f entry_ldif_file_name

38.3 サーバー・チェーン構成エントリの作成

この項の内容は次のとおりです。

- 第38.3.1項「構成エントリ属性」

- 第38.3.2項「ユーザー・コンテナとグループ・コンテナの要件」

- 第38.3.3項「属性マッピング」

- 第38.3.4項「Active Directoryの例」

- 第38.3.5項「SSLを使用したActive Directoryの例」

- 第38.3.7項「Oracle Directory Server Enterprise EditionおよびSun Java System Directory Server(iPlanet)の例」

- 第38.3.8項「SSLを使用したOracle Directory Server Enterprise EditionおよびSun Java System Directory Server(iPlanet)の例」

- 第38.3.9項「eDirectoryの例」

- 第38.3.10項「SSLを使用したeDirectoryの例」

38.3.1 構成エントリ属性

表38-1は、サーバー・チェーンの構成エントリ属性を示しています。

表38-1 サーバー・チェーンの構成エントリ属性

属性

必須

説明

orclOIDSCExtHost

はい

外部ディレクトリ・ホストのホスト名。これは単一値属性です。

orclOIDSCExtPort

はい

外部ディレクトリ・ホストのポート番号。これは単一値属性です。デフォルト値は3060です。

orclOIDSCExtDN

はい

外部ディレクトリの識別名。サーバー・チェーンは、検索および変更操作を実行するために、このアイデンティティを使用して、外部ディレクトリに対してバインドされます。このアイデンティティには、操作を実行するために十分な権限が必要です。これは単一値属性です。

orclOIDSCExtPassword

はい

外部ディレクトリの識別名のパスワード。これは単一値属性です。ユーザーがこの属性をクリアテキストで取得できないようにするため、必ずプライバシ・モードを有効にします。第28.7項「受信した機密の属性のプライバシの構成」を参照してください。

orclOIDSCExtUserContainer

はい

ユーザー検索操作を実行する外部ディレクトリ内のユーザー・コンテナ。これは単一値属性です。

orclOIDSCExtGroupContainer

はい

グループ検索操作を実行する外部ディレクトリ内のグループ・コンテナ。これは単一値属性です。

外部ユーザー・コンテナおよび外部グループ・コンテナが同じ場合(つまり、外部ディレクトリ・サーバー内のグループをユーザーと同じコンテナに格納する場合)、この値とユーザー・コンテナ(orclOIDSCExtUserContainer属性)に使用する値を同じにする必要があります。

orclOIDSCTargetUserContainer

はい

外部ユーザーが存在するOracle Internet Directory内のユーザー・コンテナ。詳細は、第38.3.2項「ユーザー・コンテナとグループ・コンテナの要件」を参照してください。

orclOIDSCTargetGroupContainer

はい

外部グループが存在するOracle Internet Directory内のグループ・コンテナ。詳細は、第38.3.2項「ユーザー・コンテナとグループ・コンテナの要件」を参照してください。

orclOIDSCAttrMapping

いいえ

外部ディレクトリとOracle Internet Directory間の各属性マッピングを指定します。たとえば、eMail属性をActive DirectoryからOracle Internet Directoryのmail属性にマップするには、この属性を次のように設定します。

orclOIDSCAttrMapping;mail:eMail

詳細は、第38.3.3項「属性マッピング」を参照してください。

orclOIDSCExtSearchEnabled

はい

外部検索機能です。0 =無効化(デフォルト)、1 =有効化です。これは単一値属性です。

orclOIDSCExtModifyEnabled

はい

外部変更機能です。0 =無効化(デフォルト)、1 =有効化です。これは単一値属性です。

orclOIDSCExtAuthEnabled

はい

外部認証機能です。0 =無効化(デフォルト)、1 =有効化です。これは単一値属性です。

orclOIDSCSSLEnabled

いいえ

外部ディレクトリへのSSL接続です。0 =無効化(デフォルト)、1 =有効化です。これは単一値属性です。SSLが有効になっている場合は必須です。

orclOIDSCExtSSLPort

いいえ

外部ディレクトリ・ホストのSSLポート番号。これは単一値属性です。

OrclOIDSCWalletLocation

いいえ

外部ディレクトリのサーバー証明書が格納されているウォレットのファイル名とパス。これは単一値属性です。SSLが有効になっている場合は必須です。

orclOIDSCWalletPassword

いいえ

ウォレット・パスワード。これは単一値属性です。SSLが有効になっている場合は必須です。

mapUIDtoADAttribute

いいえ

OID属性uidのActive Directoryの属性へのマッピングを指定します。uidは、Active Directoryに定義されている任意の非バイナリ属性にマップできます。デフォルト値はnameです。これは単一値属性です。

showExternalGroupEntries

いいえ

グループ・コンテナに対する検索において、baseの場合、オブジェクト・クラス・グループとともにエントリを表示し(デフォルト)、subの場合、オブジェクト・クラスuserおよびcomputerなしでエントリを表示します。これは単一値属性です。Active Directoryでのみ適用可能です。

showExternalUserEntries

いいえ

ユーザー・コンテナの1レベル下にあるエントリをベースとして使用した1レベル検索において、baseの場合、いずれのエントリも表示せず(デフォルト)、subの場合、検索のベースの下位にあるサブツリーのエントリを表示します。これは単一値属性です。Active Directoryでのみ適用可能です。

addOrcluserv2ToADUsers

いいえ

オブジェクト・クラス・ユーザーを持つエントリにorcluserv2オブジェクト・クラスを追加します。0 =無効化(デフォルト)、1 =有効化です。これは単一値属性です。Active Directoryでのみ適用可能です。

38.3.2 ユーザー・コンテナとグループ・コンテナの要件

ターゲットのユーザー・コンテナおよびグループ・コンテナは、Oracle Single Sign-Onと連携させるために、Oracle Internet Directory検索ベースの下に置く必要があります。

ユーザー・コンテナとグループ・コンテナには、次の名前を使用します。

- Active Directory: cn=AD

- Oracle Directory Server Enterprise EditionまたはSun Java System Directory Server (iPlanetまたはSun ONE Directory Server): cn=iPlanet

- Novell eDirectory: cn=edir

たとえば、ユーザー検索ベースがcn=users,dc=us,dc=oracle,dc=comの場合

ターゲット・ユーザー・コンテナには次の名前を使用します。

- Active Directory: cn=AD,cn=users,dc=us,dc=oracle,dc=com

- Oracle Directory Server Enterprise EditionまたはSun Java System Directory Server: cn=iPlanet,cn=users,dc=us,dc=oracle,dc=com

- Novel eDirectory: cn=edir,cn=users,dc=us,dc=oracle,dc=com

同様に、グループ検索ベースがcn=groups,dc=us,dc=oracle,dc=comの場合

ターゲット・グループ・コンテナには次の名前を使用します。

- Active Directory: cn=AD,cn=groups,dc=us,dc=oracle,dc=com

- Oracle Directory Server Enterprise EditionまたはSun Java System Directory Server (iPlanetまたはSun ONE Directory Server): cn=iPlanet,cn=groups,dc=us,dc=oracle,dc=com

- Novel eDirectory: cn=edir,cn=groups,dc=us,dc=oracle,dc=com

注意:
ターゲットのユーザー・コンテナおよびグループ・コンテナは、外部ディレクトリ専用のものです。これらのノードの下に表示されるユーザーおよびグループはすべて、外部ディレクトリによりデータが移入されます。これらのコンテナの下に、Oracle Internet Directoryから直接エントリを追加しないでください。
外部ユーザー・コンテナと外部グループ・コンテナが同じである(つまり、外部ディレクトリ・サーバーのグループがユーザーと同じコンテナに格納されている)場合、グループ・コンテナ(orclOIDSCExtGroupContainer属性)の値は、ユーザー・コンテナ(orclOIDSCExtUserContainer属性)に使用されている値と同じである必要があります。

38.3.3 属性マッピング

外部ディレクトリの属性とOracle Internet Directory属性が同じ場合、マッピングは不要です。サーバー・チェーンは、デフォルトでいくつかの属性マッピングを実行します。デフォルト・マッピングのリストは次のとおりです。

表38-2 Active Directoryに対するデフォルトの属性マッピング

Oracle Internet Directory属性

Active Directory属性

orclguid

objectGUID

uid

name

orclsamaccountname

samaccountname

krbprincipalname

userprincipalname

Active Directoryサーバー・チェーンの場合、mapUIDtoADAttribute属性を使用して、Active Directoryに定義されている任意の非バイナリ属性にuidをマップできます。

表38-3 Sun Java System Directory Serverに対するデフォルトの属性マッピング

Oracle Internet Directory属性

Sun Java System Directory Server属性

orclguid

nsuniqueid

authpassword

userpassword

krbprincipalname

mail

表38-4 Novell eDirectoryに対するデフォルトの属性マッピング

Oracle Internet Directory属性

Novell eDirectory属性

orclguid

guid

orclsamaccountname

uid

krbprincipalname

mail

次のオブジェクトはマップできません。

- 操作属性

- オブジェクト・クラス

- Oracle Internet Directory固有の属性。これらの属性には通常、orclで始まる名前が付いています。

38.3.4 Active Directoryの例

次の例は、Active Directoryサーバーdlin-pc9.us.example.com、ポート3060を、外部ディレクトリ・ストアとして使用するよう構成されたサーバー・チェーンを示しています。SSL機能は有効になっています。属性はすべて、表38-1で説明しています。

cn=oidscad,cn=OID Server Chaining,cn= subconfigsubentry
orclOIDSCExtHost: dlin-pc9.us.example.com
orclOIDSCExtPort: 3060
orclOIDSCExtDN: cn=administrator,cn=users,dc=oidvd,dc=com
orclOIDSCExtPassword: *******
orclOIDSCExtUserContainer: cn=users,dc=oidvd,dc=com
orclOIDSCTargetUserContainer: cn=AD,cn=users,dc=us,dc=oracle,dc=com
orclOIDSCTargetGroupContainer: cn=AD,cn=groups,dc=us,dc=oracle,dc=com
orclOIDSCExtSearchEnabled: 1
orclOIDSCExtModifyEnabled: 1
orclOIDSCExtAuthEnabled: 1
orclOIDSCAttrMapping;description: title
orcloidscsslenabled: 0

次の例は、構成エントリを変更するために使用されるLDIFファイルです。

dn: cn=oidscad,cn=oid server chaining,cn=subconfigsubentry
changetype: modify
replace: orcloidscextdn
orcloidscextdn: cn=administrator,cn=users,dc=oidvd,dc=com
-
replace: orcloidscextpassword
orcloidscextpassword: password
-
replace: orcloidscexthost
orcloidscexthost: dlin-pc9.us.example.com
-
replace: orcloidscextport
orcloidscextport: 3060
-
replace: orcloidsctargetusercontainer
orcloidsctargetusercontainer: cn=AD,cn=users,dc=us,dc=oracle,dc=com
-
replace: orcloidsctargetgroupcontainer
orcloidsctargetgroupcontainer: cn=AD,cn=groups,dc=us,dc=oracle,dc=com
-
replace: orcloidscextusercontainer
orcloidscextusercontainer: cn=users,dc=dlin,dc=net
-
replace: orcloidscextgroupcontainer
orcloidscextgroupcontainer: cn=users,dc=dlin,dc=net
-
replace: orcloidscextsearchenabled
orcloidscextsearchenabled: 1
-
replace: orcloidscextmodifyenabled
orcloidscextmodifyenabled: 1
-
replace: orcloidscextauthenabled
orcloidscextauthenabled: 1
-
replace: orcloidscsslenabled
orcloidscsslenabled:1

38.3.5 SSLを使用したActive Directoryの例

次の例は、Active Directoryサーバーad.example.com、SSLポート3133、および/adwallet/ewallet.p12にあるウォレットを使用するよう構成されたサーバー・チェーンを示しています。

cn=oidscad,cn=OID Server Chaining,cn= subconfigsubentry
orclOIDSCExtHost: ad.example.com
orclOIDSCExtPort: 3060
orclOIDSCExtDN: cn=administrator,cn=users,dc=oidvd,dc=com
orclOIDSCExtPassword: *******
orclOIDSCExtUserContainer: cn=users,dc=oidvd,dc=com
orclOIDSCTargetUserContainer: cn=AD,cn=users,dc=oracle,dc=com
orclOIDSCTargetGroupContainer: cn=AD,cn=groups,dc=oracle,dc=com
orclOIDSCExtSearchEnabled: 1
orclOIDSCExtModifyEnabled: 1
orclOIDSCExtAuthEnabled: 1
orclOIDSCSSLEnabled: 1
orclOIDSCExtSSLPort: 3133
orclOIDSCWalletLocation: /adwallet/ewallet.p12
orclOIDSCWalletPassword: ********

コマンド行からSSLを使用してサーバー・チェーンを構成するには、次の手順を実行します。

1. 前の項に示すように、SSLなしでActive Directoryサーバー・チェーンを構成します。

2. 次のようなLDIFファイルを作成し、外部ディレクトリへのSSL接続を有効にします。orcloidscextsslport、orcloidscwalletlocationおよびorcloidscwalletpasswordの値を、実際のActive Directoryサーバーの値と一致する値に置き換えます。

dn: cn=oidscad,cn=oid server chaining,cn=subconfigsubentry
changetype: modify
replace: orcloidscsslenabled
orcloidscsslenabled:1
-
replace: orcloidscextsslport
orcloidscextsslport: 3133
-
replace: orcloidscwalletlocation
orcloidscwalletlocation: /adwallet/ewallet.p12
-
replace: orcloidscwalletpassword
orcloidscwalletpassword: passw0rd

3. 変更を適用するには、次のようなコマンド行を使用します。

ldapmodify -p OID_port -h OID_host -D "cn=orcladmin" -q -v -f ldif_file_name

38.3.6 新規属性を使用したActive Directoryの例

属性mapUIDtoADAttribute、showExternalGroupEntries、showExternalUserEntriesおよびaddOrcluserv2ToADUsersは、Oracle Internet Directory 10g(10.1.4.0.1)から追加されています。これらの属性を既存のActive Directoryサーバー・チェーン・エントリに追加するには、適切な値を使用して次のLDIFファイルを変更します。

dn: cn=oidscad,cn=oid server chaining,cn=subconfigsubentry
changetype: modify
replace: mapUIDtoADAttribute
mapUIDtoADAttribute: name
-
replace: showExternalGroupEntries
showExternalGroupEntries: base
-
replace: showExternalUserEntries
showExternalUserEntries: base
-
replace: addOrcluserv2ToADUsers
addOrcluserv2ToADUsers: 0

次の形式のコマンド行を使用します。

ldapmodify -p OID_port -h OID_host -D "cn=orcladmin" -q -v -f ldif_file_name

構成エントリが変更されます。

38.3.7 Oracle Directory Server Enterprise EditionおよびSun Java System Directory Server(iPlanet)の例

次の例は、Sun Java System Directory Server dlin-pc10.us.example.com、ポート103060を、外部ディレクトリ・ストアとして使用するよう構成されたサーバー・チェーンを示しています。属性はすべて、表38-1で説明しています。

cn=oidsciplanet,cn=OID Server Chaining,cn=subconfigsubentry
orclOIDSCExtHost: dlin-pc10.us.example.com
orclOIDSCExtPort: 10389
orclOIDSCExtDN: cn=directory manager
orclOIDSCExtPassword: ********
orclOIDSCExtUserContainer: ou=people,dc=example,dc=com
orclOIDSCExtGroupContainer: ou=groups,dc=example,dc=com
orclOIDSCTargetUserContainer: cn=iPlanet,cn=users,dc=us,dc=oracle,dc=com
orclOIDSCTargetGroupContainer: cn=iPlanet,cn=groups,dc=us,dc=oracle,dc=com
orclOIDSCExtSearchEnabled: 1
orclOIDSCExtModifyEnabled: 1
orclOIDSCExtAuthEnabled: 1
orclOIDSCSSLEnabled:0

次の例は、構成エントリを変更するために使用されるLDIFファイルです。

dn: cn=oidsciplanet,cn=oid server chaining,cn=subconfigsubentry
changetype: modify
replace: orcloidscextdn
orcloidscextdn: cn=directory manager
-
replace: orcloidscextpassword
orcloidscextpassword: password
-
replace: orcloidscexthost
orcloidscexthost: dlin-pc10.us.example.com
-
replace: orcloidscextport
orcloidscextport: 10389
-
replace: orcloidsctargetusercontainer
orcloidsctargetusercontainer: cn=iplanet,cn=users,dc=us,dc=oracle,dc=com
-
replace: orcloidsctargetgroupcontainer
orcloidsctargetgroupcontainer: cn=iplanet,cn=groups,dc=us,dc=oracle,dc=com
-
replace: orcloidscextusercontainer
orcloidscextusercontainer: ou=people,dc=example,dc=com
-
replace: orcloidscextgroupcontainer
orcloidscextgroupcontainer: ou=groups,dc=example,dc=com
-
replace: orcloidscextsearchenabled
orcloidscextsearchenabled: 1
-
replace: orcloidscextmodifyenabled
orcloidscextmodifyenabled: 1
-
replace: orcloidscextauthenabled
orcloidscextauthenabled: 1

38.3.8 SSLを使用したOracle Directory Server Enterprise EditionおよびSun Java System Directory Server(iPlanet)の例

次の例は、Sun Java System Directory Server sunone.example.com、SSLポート10636、および/ipwallet/ewallet.p12にあるウォレットを使用するよう構成したサーバー・チェーンを示しています。

cn=oidsciplanet,cn=OID Server Chaining,cn=subconfigsubentry
orclOIDSCExtHost: sunone.example.com
orclOIDSCExtPort: 10389
orclOIDSCExtDN: cn=directory manager
orclOIDSCExtPassword: ********
orclOIDSCExtUserContainer: ou=people,dc=example,dc=com
orclOIDSCExtGroupContainer: ou=groups,dc=example,dc=com
orclOIDSCTargetUserContainer: cn=iPlanet,cn=users,dc=oracle,dc=com
orclOIDSCTargetGroupContainer: cn=iPlanet,cn=groups,dc=oracle,dc=com
orclOIDSCExtSearchEnabled: 1
orclOIDSCExtModifyEnabled: 1
orclOIDSCExtAuthEnabled: 1
orclOIDSCSSLEnabled: 1
orclOIDSCExtSSLPort: 10636
orclOIDSCWalletLocation: /ipwallet/ewallet.p12
orclOIDSCWalletPassword: ********

コマンド行からSSLを使用してサーバー・チェーンを構成するには、次の手順を実行します。

1. 前の項に示すように、SSLなしでサーバー・チェーンを構成します。

2. 次のLDIFファイルを作成し、外部ディレクトリへのSSL接続を有効にします。orcloidscextsslport、orcloidscwalletlocationおよびorcloidscwalletpasswordの値を、実際のOracle Directory Server Enterprise Edition/Sun Java System Directory Serverの値と一致する値に置き換えます。

dn: cn=oidsciplanet,cn=oid server chaining,cn=subconfigsubentry
changetype: modify
replace: orcloidscsslenabled
orcloidscsslenabled:1
-
replace: orcloidscextsslport
orcloidscextsslport: 10636
-
replace: orcloidscwalletlocation
orcloidscwalletlocation: /ipwallet/ewallet.p12
-
replace: orcloidscwalletpassword
orcloidscwalletpassword: passw0rd

3. 次の形式のコマンド行を実行します。

ldapmodify -p OID_port -h OID_host -D "cn=orcladmin" -q -v -f ldif_file_name

構成エントリが変更されます。

38.3.9 eDirectoryの例

eDirectory構成の例は次のようになります。

cn=oidscedir,cn=OID Server Chaining,cn=subconfigsubentry
orclOIDSCExtHost: edirhost.domain.com
orclOIDSCExtPort: 3060
orclOIDSCExtDN: cn=admin,o=domain
orclOIDSCExtPassword: ********
orclOIDSCExtUserContainer: ou=users,o=domain
orclOIDSCExtGroupContainer: ou=groups,o=domain
orclOIDSCTargetUserContainer: cn=edir,cn=users,dc=us,dc=oracle,dc=com
orclOIDSCTargetGroupContainer: cn=edir,cn=groups,dc=us,dc=oracle,dc=com
orclOIDSCExtSearchEnabled: 1
orclOIDSCExtModifyEnabled: 1
orclOIDSCExtAuthEnabled: 1
orclOIDSCSSLEnabled:0

38.3.10 SSLを使用したeDirectoryの例

SSLを使用したeDirectory構成の例は次のようになります。

cn=oidscedir,cn=OID Server Chaining,cn=subconfigsubentry
orclOIDSCExtHost: edirhost.domain.com
orclOIDSCExtPort: 3060
orclOIDSCExtDN: cn=admin,o=domain
orclOIDSCExtPassword: ********
orclOIDSCExtUserContainer: ou=users,o=domain
orclOIDSCExtGroupContainer: ou=groups,o=domain
orclOIDSCTargetUserContainer: cn=edir,cn=users,dc=us,dc=oracle,dc=com
orclOIDSCTargetGroupContainer: cn=edir,cn=groups,dc=us,dc=oracle,dc=com
orclOIDSCExtSearchEnabled: 1
orclOIDSCExtModifyEnabled: 1
orclOIDSCExtAuthEnabled: 1
orclOIDSCSSLEnabled: 1
orclOIDSCExtSSLPort: 3133
orclOIDSCWalletLocation: /edir/ewallet.p12
orclOIDSCWalletPassword: ********

38.4 サーバー・チェーンのデバッグ

サーバー・チェーンのデバッグを行うには、次の手順を実行します。

1. 第24.2項「Fusion Middleware Controlを使用したロギングの管理」または第24.3項「コマンド行からのロギングの管理」の説明に従って、Oracle Internet Directoryサーバーのデバッグ・ロギング・レベルを設定します。ロギング・レベル値402653184を使用します。この値は、Javaプラグイン・フレームワーク関連の全メッセージのロギングを可能にします。

2. Oracle Internet Directoryサーバー・チェーンのデバッグ設定を変更します。cn=oidscad,cn=oid server chaining,cn=subconfigsubentryとcn=oidsciplanet,cn=oid server chaining, cn=subconfigsubentryの両方について、orcloidscDebugEnabled属性を1に設定します。
たとえば、cn=oidscad,cn=oid server chaining,cn=subconfigsubentryでorcloidscDebugEnabledを1に設定するには、次のように入力します。

$ORACLE_HOME/bin/ldapmodify -h host -p port -D cn=orcladmin -q -f file

fileには、次のものが含まれます。

dn: cn=oidscad,cn=oid server chaining,cn=subconfigsubentry
changetype: modify
replace: orcloidscDebugEnabled
orcloidscDebugEnabled: 1

関連項目:
Oracle Fusion Middleware Oracle Identity Managementアプリケーション開発者ガイドのJavaプラグインのデバッグおよびロギング情報。

38.5 パスワード変更通知のActive Directoryプラグインの構成

サーバー・チェーンでEnterprise User Security 10gを使用する場合は、ユーザーを認証するためにハッシュ・パスワードが必要になります。この項では、Oracle Internet Directoryを介してアクセスしたユーザーに対してハッシュ・パスワードを使用可能にするプラグインを、Microsoft Active Directory (AD)サーバーにインストールする方法について説明します。サーバー・チェーンを介してアクセスしたユーザーにエンタープライズ・ユーザー・セキュリティを使用する構成を計画している顧客は、この機能を構成する必要があります。

手順は次のとおりです。

1. Active Directoryで、orclCommonAttributeという属性を作成してハッシュ・パスワードを格納します。次の形式のコマンド行を使用します。

ldapadd –p AD_Port –h AD_host -D "AD_administrator_DN" –w AD_administrator_password -v –f orclca.ldif

次の例のようなorclca.ldifファイルを使用します。DC=bill,DC=comをActive Directoryの実際のドメイン名に置き換えて、適切なattributeIDを選択します。

dn: cn=orclcommonattribute,CN=Schema,CN=Configuration,DC=bill,DC=com
objectClass: top
objectClass: attributeSchema
cn: orclcommonattribute
distinguishedName: CN=orclcommonattribute,CN=Schema,CN=Configuration,DC=bill,DC=com
instanceType: 4
uSNCreated: 16632
attributeID: 1.9.9.9.9.9.9.9.9
attributeSyntax: 2.5.5.3
isSingleValued: TRUE
uSNChanged: 16632
showInAdvancedViewOnly: TRUE
adminDisplayName: orclCommonAttribute
oMSyntax: 27
lDAPDisplayName: orclCommonAttribute
name: orclcommonattribute
objectCategory: CN=Attribute-Schema,CN=Schema,CN=Configuration,DC=bill,DC=com

2. 属性をユーザーのオブジェクト・クラスに関連付けます。次の形式のコマンド行を使用します。

ldapadd –p AD_Port –h AD_host -D "AD_administrator_DN" –w AD_administrator_password -v –f user.ldif

次のファイルuser.ldifでは、DC=bill,DC=comをActive Directoryの実際のドメイン名に置き換えます。

dn: CN=User,CN=Schema,CN=Configuration,DC=bill,DC=com
changetype: modify
add: mayConatin
mayContain: orclCommonAttribute

Active Directoryでは、スキーマをリフレッシュするために数分かかることがあります。

3. パスワード変更通知のプラグインを次の手順でインストールします。

1. %ORACLE_HOME%\ldap\admin\oidpwdcn.dllをActive DirectoryのWINDOWS\system32フォルダにコピーします。

2. regedt32を使用して、レジストリを変更します。行HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Notification Packagesで、最後にoidpwdcnを追加します。次のようになります。

RASSFM
KDCSVC
WDIGEST
scecli
oidpwdcn

3. Active Directoryを再起動します。

4. ユーザーのパスワードを再設定することにより、プラグインが正しくインストールされていることを確認します。orclCommonAttributeにハッシュ・パスワードの値が格納されている必要があります。

4. Active Directoryの全ユーザーのパスワードを再設定し、すべてのユーザーにパスワード・ベリファイアが存在するようにします。

39 DITマスキングの管理

この章では、Oracle Internet DirectoryでのDITマスキングについて説明し、DITマスキングに必要な属性を構成する方法について説明します。DITマスキングは、Oracle Internet Directoryサーバー・インスタンスで公開されるDITコンテンツの制限です。

DITマスキングによって、スーパーユーザーcn=orcladmin以外のすべてのユーザーのアクセスが制限されます。マスキングは、通常、(ユーザーが接続しているOracle Internet Directoryサーバーのインタンスに基づいて)一部のユーザーにDITの特定の部分が表示されないようにするために使用します。異なるDITを表示する一般的な使用例として、テストと本番、内部ユーザーと外部ユーザーなどがあります。

Oracle Internet Directory 11g リリース1(11.1.1.7.0)以降では、特定のOracle Internet Directoryサーバー・インスタンスからコンテナを隠すのではなく、ディレクトリ全体から1つ以上のコンテナへのアクセスを禁止することもできます。

Oracle Virtual Directoryを使用してユーザーのDIT表示を制限することもできますが、パフォーマンスおよび管理のオーバーヘッドはDITマスキングの方が遥かに小さくなります。

この章の内容は次のとおりです。

- 第39章「マスキングの構成」

- 第39章「マスキングの例」

39.1 マスキングの構成

デフォルトでは、マスキングは構成されません。マスキングを構成するには、インスタンス固有の構成エントリの次の構成属性を使用します。

表39-1 構成属性のマスキング

属性

説明

orclMaskRealm

インスタンスで公開されるDITサブツリーが含まれます。構成された識別名およびその子は、インスタンス内で可視になります。DIT内の他のエントリは、すべてのLDAP操作に対してマスクされます(非表示になります)。

orclMaskRealm;disallowed

ディレクトリ全体に対して隠されたコンテナ内のDITサブツリーを含みます。

orclMaskFilter

インスタンスで公開されるエントリがフィルタされます。フィルタ基準に一致するエントリは公開されます。他のエントリは、すべてのLDAP操作に対して非表示になります。

これらの属性は、インスタンス固有の構成エントリの他の属性と同じ方法で変更します。第9.4.1項「ldapmodifyを使用したシステム構成属性の設定」を参照してください。

39.2 マスキングの例

マスキングは、ディレクトリに存在するエントリを管理者が選択して公開するかまたは隠す場合に有用です。次に、使用例を示します。

- 第39章「コンテナ名によるアクセス制限」

- 第39章「エントリ・データによるアクセス制限」

- 第39章「ディレクトリ全体からのコンテナに対するアクセスの禁止」

39.2.1 コンテナ名によるアクセス制限

次の階層を持つDIT設定について検討します。

cn=internal,o=oracle
cn=external,o=oracle
cn=public,o=oracle

internalコンテナには組織内部のエントリが含まれるため、アクセスを制限する必要があります。externalおよびpublicコンテナには、それぞれ外部ユーザーについてのデータ、およびすべてのユーザーがアクセスできる公開情報が含まれます。管理者は、組織のファイアウォールの外側ではexternalおよびpublicデータのみを利用できるようにする必要があります。これは、マスキングを使用して達成できます。ファイアウォールを介して公開されるポート上で実行するOracle Internet Directoryインスタンスを作成します(たとえば、oid2)。このポートに接続するアプリケーションおよびユーザーに、アクセス可能なコンテンツのみが表示されるようにするには、次のLDIFファイルを使用して、ldapmodifyでcn=oid2にマスキング・レルムを作成します。

dn: cn=oid2,cn=osdldapd,cn=subconfigsubentry
changetype: modify
add: orclmaskrealm
orclmaskrealm: cn=external,o=oracle
orclmaskrealm: cn=public,o=oracle

この例では、このインスタンスから構成済コンテナpublicおよびexternal内のエントリのみが表示されるようになります。このインスタンスに接続するアプリケーションおよびユーザーは、Internalコンテナおよびそのエントリを表示することはできません。

39.2.2 エントリ・データによるアクセス制限

別の使用例として、エントリに格納されているデータに基づいてエントリを制限する場合があります。ある組織に、従業員、契約社員および派遣社員に関するデータが存在しているとします。電子メール・クライアントなどのユーザー参照アプリケーションは、ディレクトリ・サーバー上のデータを参照して電子メール・アドレスを探します。管理者は、電子メール・クライアントからアクセスできるインスタンス(たとえば、cn=oid2)内で、派遣社員の情報を非表示にし、従業員および契約社員のみが公開されるようにすることができます。これは、次のLDIFファイルを使用し、ldapmodifyでマスキング・フィルタを構成することにより達成できます。

dn: cn=oid2,cn=osdldapd,cn=subconfigsubentry
changetype: modify
add: orclmaskfilter
orclmaskfilter: (usertype=employee)
orclmaskfilter: (usertype=contract)

この例では、usertype=employeeまたはusertype=contractのエントリが公開され、他のエントリは公開されなくなります。

39.2.3 ディレクトリ全体からのコンテナに対するアクセスの禁止

次のコンテナを持つDIT設定について検討します。

cn=internal,o=oracle

次のLDIFファイルを使用してldapmodifyにより、特定のインスタンスからコンテナを隠すのではなく、ディレクトリ全体からのこのコンテナに対するアクセスを禁止できます。

dn: cn=dsaconfig,cn=configsets,cn=oracle internet directory
changetype: modify
add: orclmaskrealm;disallowed
orclmaskrealm;disallowed: cn=internal,o=oracle

この例では、internalコンテナ内のすべてのエントリがLDAP操作についてスーパー・ユーザー(cn=orcladmin)以外のユーザーによりアクセスできないようにします。

第V部

拡張管理: ディレクトリ・レプリケーション

ここでは、レプリケーションおよび高可用性の詳細とその計画および管理方法について説明します。次の各章で構成されています。

- 第40章「レプリケーションの設定」

- 第41章「レプリケーション・フェイルオーバーの設定」

- 第42章「レプリケーション構成属性の管理」

- 第43章「レプリケーションの管理およびモニタリング」

40 レプリケーションの設定

この章では、Oracle Internet Directoryのレプリケーションについて説明し、アドバンスト・レプリケーション・ベースのレプリケーションおよびLDAPベースのレプリケーションの両方に共通する情報を示します。また、LDAPベースのレプリケーションと、ファンアウトを使用したマルチマスター・レプリケーションを設定する方法についても説明します。

レプリケーションは、複数のディレクトリ・サーバーに同じネーミング・コンテキストをコピーし、管理するプロセスです。これにより、問合せを処理するサーバーの数が増え、クライアントの近くにデータを持ってくるため、パフォーマンスが向上します。また、シングル・ポイント障害に関連するリスクを排除することで信頼性が向上します。

この章をお読みになる前に、レプリケーションの基本概念の概要について、第6章「Oracle Internet Directoryレプリケーションの理解」を参照してください。

Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーションに固有の情報および手順は、付録C「Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーションの設定」を参照してください。

関連項目:
第6.2.3項「転送メカニズム: LDAPまたはOracle Databaseアドバンスト・レプリケーション」
高可用性構成でのレプリケーション設定の詳細は、『Oracle Fusion Middleware高可用性ガイド』を参照してください。

この章の内容は次のとおりです。

- 第40.1項「レプリケーションの設定の概要」

- 第40.2項「アドバンスト・レプリケーション・ベースの承諾のLDAPベースの承諾への変換」

- 第40.3項「レプリケーション・ウィザードを使用したLDAPベースのレプリケーション承諾の設定」

- 第40.4項「Oracle Directory Services Managerを使用したレプリケーションのテスト」

- 第40.5項「コマンド行を使用したLDAPベースのレプリケーションの設定」

- 第40.6項「ファンアウトと組み合せたマルチマスター・レプリケーション・グループの設定」

注意:
この章で言及するOracle Single Sign-OnまたはOracle Delegated Administration ServicesはすべてOracle Single Sign-On 10g(10.1.4.3.0)以上またはOracle Delegated Administration Services 10g(10.1.4.3.0)以上のことです。

40.1 レプリケーションの設定の概要

レプリケーションの基本概念について不明な場合は、この概要の前に第6章「Oracle Internet Directoryレプリケーションの理解」を参照してください。

この概要の項目は次のとおりです。

- 第40.1.1項「レプリケーション転送メカニズム」

- 第40.1.2項「レプリケーション設定方法」

- 第40.1.3項「ブートストラップ規則」

- 第40.1.4項「レプリケーション承諾」

- 第40.1.5項「その他のレプリケーション構成属性」

- 第40.1.6項「レプリケーション・プロセスとアーキテクチャ」

- 第40.1.7項「LDAPベースのレプリケーションの構成に関する規則」

- 第40.1.8項「レプリケーションのセキュリティ」

- 第40.1.9項「部分レプリケーションのためのLDAPレプリケーションのフィルタリング」

40.1.1 レプリケーション転送メカニズム

Oracle Internet Directoryでは、2つのレプリケーション転送メカニズムがサポートされます。

- LDAPベースのレプリケーションでは、業界標準のLightweight Directory Access Protocolバージョン3を使用します。一方向、双方向およびマルチマスター構成でLDAPベースのレプリケーションを設定できます。これは、ほとんどの環境に推奨されるプロトコルです。

- Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーションでは、Oracle Databaseのレプリケーション機能を使用します。マルチマスター構成のみがサポートされます。(グループ内の1つを除き他のすべてのノードを読取り専用モードに切り替えることにより、単一のマスターDRGを作成できます。)
Oracle Single Sign-Onデータをレプリケートする必要がある場合、Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーションを使用する必要があります。アドバンスト・レプリケーション・ベースのレプリケーションに固有の情報および手順は、付録C「Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーションの設定」を参照してください。

remtool -asr2ldapを使用すると、既存のOracle Databaseアドバンスト・レプリケーション・ベースのマルチマスター承諾をLDAPベースのマルチマスター承諾に変換できます。第40.2項「アドバンスト・レプリケーション・ベースの承諾のLDAPベースの承諾への変換」を参照してください。

関連項目:
レプリケーション環境管理ツールの詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のremtoolコマンド行ツールのリファレンスを参照してください。

40.1.2 レプリケーション設定方法

Oracle Internet Directoryレプリケーションを設定するには、次のいずれかの方法を使用します。

- 第40.1.2.1項「レプリケーション・ウィザード」

- 第40.1.2.2項「コマンド行ツール」

注意:
次のシナリオではコマンド行ツール(ldifwriteおよびbulkload)を使用する必要があります。

- アドバンスト・レプリケーション・ベースのレプリケーション

- 100,000を超えるエントリを持つディレクトリのレプリケーション

他のシナリオでは、どちらのレプリケーション方法も使用できます。

40.1.2.1 レプリケーション・ウィザード

LDAPベース・レプリケーションの設定には、Oracle Enterprise Manager Fusion Middleware Controlのレプリケーション・ウィザードを使用する方法をお薦めします。この手順の詳細は、第40.3項「レプリケーション・ウィザードを使用したLDAPベースのレプリケーション承諾の設定」を参照してください。

第43.2.4項「レプリケーション・ウィザードを使用したレプリケーション設定の表示または変更」および第43.2.5項「レプリケーション・ウィザードを使用したLDAPベースのレプリケーション承諾の削除」で説明するように、このウィザードを使用して既存のレプリケーション承諾を変更することもできます。

40.1.2.2 コマンド行ツール

アドバンスト・レプリケーション・ベースのレプリケーションを設定する場合や、ディレクトリに100,000を超えるエントリが含まれる場合、コマンド行ツールを使用する必要があります。また、コマンド行ツールでLDAPベースのレプリケーションも設定できます。

コマンド行を使用したLDAPベースのレプリケーションの設定方法は、第40.5項「コマンド行を使用したLDAPベースのレプリケーションの設定」を参照してください。コマンド行を使用したアドバンスト・レプリケーション・ベースのレプリケーションの設定方法は、付録C「Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーションの設定」を参照してください。

コマンド行からレプリケーションを設定する場合、レプリケーション・サーバーの停止および開始には、oidctlコマンドを使用します。データをバックアップして他のノードにロードするにはバルク・ツールを使用します。いくつかの操作には、LDAPツールを使用します。

注意:
コマンド行を使用してレプリケーション・サーバーを起動する場合、停止にもコマンド行を使用する必要があります。Oracle Enterprise Manager Fusion Middleware Controlを使用してこれを停止しようとすると、失敗します。

また、初期データの移行には、レプリケーション・サーバーのブートストラップ機能を使用できます。

次のような各種レプリケーション関連タスクを実行するには、レプリケーション環境管理ツールのremtoolを使用します。

- レプリケーション・グループの設定

- 既存のOracle Databaseアドバンスト・レプリケーション・ベース承諾からLDAPマルチマスター承諾への変換

- レプリカの追加および削除

- ディレクトリ・レプリケーション・グループの管理

- レプリケーション・バインド識別名パスワードの変更または再設定

- データベース・レプリケーション・ユーザーREPADMINパスワードの変更

- 変更ログの伝播に関する様々なエラーおよびステータス情報の表示

- ディレクトリ・レプリケーション・グループでのレプリケーションの進行状況の追跡

関連項目:
レプリケーション環境管理ツールの詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のremtoolコマンド行ツールのリファレンスを参照してください。

40.1.2.3 データベース・コピー・プロシージャ

新規ホスト上では、既存ホストからOracle Databaseをコピーしてレプリケーションを設定できます。これは複雑な手順であり、ほとんどの環境では推奨されません。この手順は、付録L「データベース・コピー・プロシージャを使用したディレクトリ・ノードの追加」を参照してください。

40.1.3 ブートストラップ規則

Fusion Middleware Controlのレプリケーション・ウィザードを使用する場合もコマンド行を使用する場合も、初期データの移行にレプリケーション・サーバーのブートストラップ機能を使用できます。

replicadn下の属性orclreplicastateを0に設定してブートストラップ・フラグを設定します。

関連項目:

- 第40.5.2.1項「自動ブートストラップを使用したLDAPベースのレプリカの設定」

- 第D.4項「LDAPのレプリカ状態」

レプリカがブートストラップ・モードの場合、サプライヤ・ノードはオンライン・モード(orclreplicastate=1)である必要があります。サプライヤとコンシューマを同時にブートストラップに設定しないでください。

ブートストラップは、複数のサプライヤを持つノードでの初期データ移行には使用できません。つまり、ブートストラップは次のタイプのレプリカに制限されています。

- リーフ・レプリカ。つまり、コンシューマ・レプリカのないレプリカ。

- 双方向ファンアウト・レプリカがない場合の2ノードによるLDAPベースのマルチマスター・レプリケーション承諾での1次レプリカ。

- 双方向ファンアウト・レプリカがない場合の複数ノードによるLDAPベースのマルチマスター・レプリケーション承諾での非1次レプリカ。

- サプライヤが1つのみのファンアウト・レプリカ

他のレプリカのブートストラップ・フラグ(replicadn下のorclreplicastate=0)を設定すると、レプリケーション・サーバーは次のいずれかのメッセージをスローします。

bootstrapping against non-leaf replica is not allowed
bootstrap against master replica is not allowed

注意:

- ブートストラップは、Oracle Databaseアドバンスト・レプリケーション・レプリカには使用できません。

- レプリケーションのブートストラップ・プロセス中に、参照整合性を無効にします。参照整合性が有効になると、ブートストラップは失敗します。

40.1.4 レプリケーション承諾

レプリケーションを設定する場合は、各レプリケーション・ホスト上のDIT内にレプリケーション承諾と呼ばれるコンテナを作成します。レプリケーション承諾エントリの属性は、第42.1.3項「レプリケーション承諾エントリ」を参照してください。

Oracle Enterprise Manager Fusion Middleware Controlのレプリケーション・ウィザードを使用する場合は、ウィザードの「設定」ページでの選択に応じて、接続とスケジューリングを制御するレプリケーション承諾属性が指定されます。

このページの選択肢には次があります。

- レプリケーション・サーバーが、複数のLDAP操作の実行に同じ接続を使用する(キープ・アライブ)か、LDAP操作ごとに新しい接続を開く(常に新規の接続を使用)のどちらか。

- レプリケーションの発生頻度(レプリケーション頻度)。

- レプリケーション・サーバーが変更適用プロセスを繰り返す間隔(管理者操作キュー・スケジュール)。変更適用プロセスと管理者操作キューの詳細は、第D.5.1項「マルチマスター・レプリケーション・プロセスがコンシューマに新規エントリを追加する動作」を参照してください。

レプリケーション承諾にはレプリケーション・コンテキストも含まれます。詳細は、第40.1.9項「部分レプリケーションのためのLDAPレプリケーションのフィルタリング」を参照してください。その属性は、第42.1.3項「レプリケーション承諾エントリ」を参照してください。

40.1.5 その他のレプリケーション構成属性

レプリケーション承諾エントリに加え、DITには、レプリケーションを制御する属性を含む複数のエントリが他にも含まれています。エントリおよびその属性の詳細は、第42章「レプリケーション構成属性の管理」を参照してください。レプリケーションを設定した後で、これらの属性を管理できます。

Oracle Enterprise Manager Fusion Middleware Controlにはレプリケーション・ウィザードから独立した「レプリケーション」ページがあり、これを使用してレプリケーション属性を構成できます。LDAPツールを使用してレプリケーション属性を変更することもできます。その方法については、第43章「レプリケーションの管理およびモニタリング」で説明しています。

40.1.6 レプリケーション・プロセスとアーキテクチャ

レプリケーション・アーキテクチャとレプリケーション・プロセスの詳細は、付録D「レプリケーションの動作」を参照してください。

40.1.7 LDAPベースのレプリケーションの構成に関する規則

LDAPベースのレプリケーションには次の規則が適用されます。

1. 同じOracle Databaseを使用するOracle Internet Directoryのインスタンスが複数ある場合は、その1つのインスタンスのみをレプリケーション用に設定できます。

2. LDAPマルチマスター・レプリケーションには、下位互換性がありません。これは、11g リリース1(11.1.1)を実行するレプリカ間でのみサポートされています。

3. マルチマスター・レプリケーションまたは双方向ファンアウト・レプリケーションの場合は、すべてのノードで同じリリースのOracle Internet Directoryを実行する必要があります。したがって、ローリング・アップグレードの実行中にはレプリケーションをオフに切り替える必要があります。

4. そのサプライヤより新しいリリースを実行する一方向のファンアウト・レプリカを追加できます。たとえば、図6-5「ファンアウト・レプリケーションの例」では、ノードFで他のノードより新しいリリースを実行できます。
Oracle Internet Directory 10gノードと11gR1ノードの組合せによるデプロイメントを検討してください。次に例を示します。

- それぞれサプライヤ・ノードとコンシューマ・ノードとして使用される2つの10gノード

- LDAPマルチマスター・レプリケーションを指定した2つの新しい11gR1ノード(たとえば、ノード1および2)

レプリケーションを次のように設定する必要があります。

1. いずれかの10gノードから11gR1のノード1に一方向のLDAPレプリケーションを設定します。

2. 11gR1のノード1でレプリケーション・ブートストラップを設定し(エントリ数が100,000未満の場合)、レプリケーション・サーバーを起動します。

3. ブートストラップが完了したら、11gR1のノード1および2の間にLDAPマルチマスター・レプリケーションを設定します。

4. 11gR1のノード2でレプリケーション・ブートストラップを設定し、レプリケーション・サーバーを起動します。

11gR1のノード間のレプリケーションを設定する前に、最も重要な10gノードから11gR1ノードへのレプリケーションを設定する必要があります。

5. 一般に、より新しいバージョンのOracle Internet Directoryで生成された変更内容は、そのバージョンまでアップグレードされていないノードにはレプリケートしません。レプリケートすると、旧リリースでは正しく解析されない情報が変更内容に含まれてしまいます。

6. 具体的には、新しいOracle Internet Directory 11g リリース1(11.1.1.6)のノードを既存のDRGに一方向のファンアウト・レプリカとして追加する場合、DRGの他のノードをアップグレードする必要はありません。他のすべてのレプリケーション・タイプについては、DRGのノードをアップグレードしてから新規ノードを追加します。このことは、既存のノードで10g リリースまたは以前の11g リリースのいずれを実行していても、当てはまります。たとえば、図6-5「ファンアウト・レプリケーションの例」では、Oracle Internet Directory 11g リリース1(11.1.1.6)のノードをノードEとして追加する前に、まずノードA、B、CおよびGを11g リリース1(11.1.1.6)に更新する必要があります。

7. LDAPベースのレプリケーションでは、ルートDSEのnamingcontexts属性にリストされているネーミング・コンテキストのみ、コンシューマにレプリケートできます。

関連項目:
namingcontextsの詳細は、次の項を参照してください。

- 第40.1.9.1項「LDAPレプリケーションのフィルタリングに含まれるネーミング・コンテキストと除外されるネーミング・コンテキスト」

- 第43.1.1項「LDAPベースの部分レプリケーションでのレプリケート対象の変更」

8. LDAPベースのレプリカのサプライヤは、レプリケーション・グループのメンバーではないマスター・ノード、マルチマスター・レプリケーション・グループのメンバーまたは別のLDAPベースのレプリカです。

関連項目:
Oracle Internet Directoryのインストール方法は、『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』を参照してください。

9. LDAPベースのレプリカは、別のLDAPベースのレプリカのコンシューマの場合もあります。そのコンシューマはファンアウト・レプリカと呼ばれます。

注意:
スキーマが同期していることを確認してください。そうでないと、レプリケーション・サーバーがコンシューマ・レプリカに変更を適用できない場合があります。

10. 新規コンシューマ・ノードは空であることが必要です。つまり、Oracle Internet Directoryを新たにインストールする必要があります。

40.1.8 レプリケーションのセキュリティ

この項の項目は次のとおりです。

- 第40.1.8.1項「認証およびディレクトリ・レプリケーション・サーバー」

- 第40.1.8.2項「Secure Sockets Layer(SSL)とOracle Internet Directoryレプリケーション」

40.1.8.1 認証およびディレクトリ・レプリケーション・サーバー

認証とは、Oracleディレクトリ・レプリケーション・サーバーが、ディレクトリ・サーバーへの接続時に、サーバー自身の正確なアイデンティティを取得するプロセスです。これは、LDAPセッションがldapbind操作によって確立されたときに発生します。

ディレクトリ・レプリケーション・サーバーが、ディレクトリへのアクセスを許可される前に適切に認証されることが重要です。

ディレクトリ・レプリケーション・サーバーは、一意のアイデンティティとパスワードを使用して、ディレクトリ・サーバーに対する認証を行います。ディレクトリ・レプリケーション・サーバーのアイデンティティは、cn=replication dn,orclreplicaid=unique_identifier_of_node,cn=replication configurationの形式をとります。

ディレクトリ・レプリケーション・サーバーは、起動時、Oracle Internet Directoryのセキュアなウォレットからアイデンティティとパスワードを読み取り、これらの資格証明を使用して認証を行います。レプリケーション・バインド識別名のパスワードを変更する場合、レプリケーション環境管理ツールの-chgpwd、-presetpwdまたは-pchgwalpwdオプションを使用する必要があります。レプリケーションのアイデンティティのウォレットは、ORACLE_INSTANCE/OID/admin/oidpwdrOracle_SIDにあります。

関連項目:
『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のremtoolコマンド行ツールのリファレンスを参照してください。

注意:
以前のリリースでは、レプリケーション・サーバーを実行するには、ディレクトリ・サーバーで匿名バインドを許可する必要がありました。このリリースではその必要はありません。

40.1.8.2 Secure Sockets Layer(SSL)とOracle Internet Directoryレプリケーション

Oracle Internet Directoryレプリケーションは、SSLの使用に関係なくデプロイできます。レプリケーション・サーバーで、Oracle Internet DirectoryインスタンスのSSLポートにバインドしているかどうかを自動的に検出します。そうである場合、Secure Sockets Layer上で動作します。

SSL暗号化を使用するようにLDAPベースのレプリケーションを構成するには、サプライヤ連絡先情報が含まれているorclReplicaURI属性に、SSLポートのポート番号を指定します。

SSL暗号化を使用するようにOracle Databaseアドバンスト・レプリケーションを構成するには、Oracle Database Advanced Securityを使用します。『Oracle Database Advanced Security管理者ガイド』のSecure Sockets Layerに関する章を参照してください。

注意:
レプリケーション・サーバーは、一方向認証または双方向認証用に構成されているSSLポートで通信できません。レプリケーション・サーバーの起動に失敗し、ハングします。非SSLポートまたは認証なしで構成されているSSLポートを使用するようレプリケーション・サーバーを構成する必要があります。別のOracle Internet Directoryサーバー・インスタンスをレプリケーション用に使用できます。

関連項目:
第27章「Secure Sockets Layer(SSL)の構成」

40.1.9 部分レプリケーションのためのLDAPレプリケーションのフィルタリング

この項では、LDAP部分レプリケーションでネーミング・コンテキストを指定する場合の規則およびベスト・プラクティスについて説明します。この付録には、次の項があります。

- 第40.1.9.1項「LDAPレプリケーションのフィルタリングに含まれるネーミング・コンテキストと除外されるネーミング・コンテキスト」

- 第40.1.9.2項「ネーミング・コンテキストを制御する属性」

- 第40.1.9.3項「LDAP部分レプリケーションのフィルタリングの規則」

- 第40.1.9.4項「LDAPレプリケーションのフィルタリングの例」

- 第40.1.9.5項「ネーミング・コンテキストおよび属性の管理規則」

- 第40.1.9.6項「部分レプリケーションのネーミング・コンテキストの最適化によるパフォーマンスの向上」

関連項目:
第6.2.1項「レプリケートされるコンテンツ: 完全または一部」

40.1.9.1 LDAPレプリケーションのフィルタリングに含まれるネーミング・コンテキストと除外されるネーミング・コンテキスト

LDAPベースのレプリケーションでは、特定のネーミング・コンテキストをレプリケーションに追加し、そのネーミング・コンテキスト内の1つ以上のサブツリーをレプリケーションから除外できます。ネーミング・コンテキスト内の1つ以上の属性もレプリケーションから除外できます。

LDAPベースのレプリケーションでは、レプリケーションに含むことを明示的に指定したネーミング・コンテキストのみがレプリケートされます。しかし、Oracle Databaseアドバンスト・レプリケーションの場合は、デフォルトですべてのネーミング・コンテキストが含まれます。

40.1.9.2 ネーミング・コンテキストを制御する属性

ネーミング・コンテキストを制御する属性は、第42.1.5項「レプリケーションのネーミング・コンテキスト・オブジェクト・エントリ」を参照してください。Oracle Enterprise Manager Fusion Middleware Controlのレプリケーション・ウィザードを使用してレプリケーションを設定する場合は、各属性を「有効範囲」ページで設定します。

40.1.9.3 LDAPレプリケーションのフィルタリングの規則

レプリケーションに対して複数のネーミング・コンテキストを構成する場合、フィルタリングは次の規則に基づいて行われます。

1. 各ネーミング・コンテキスト・オブジェクトで定義されて含まれているすべてのネーミング・コンテキストの集合が、レプリケーションに含まれる全体的なネーミング・コンテキストになります。

2. 各ネーミング・コンテキスト・オブジェクトで定義された除外ネーミング・コンテキストの集合が、レプリケーションから除外される全体的なネーミング・コンテキストになります。

3. 1つのネーミング・コンテキスト・オブジェクトでの属性の除外は、そのネーミング・コンテキスト・オブジェクトのみに限定されます。

4. 包含されるネーミング・コンテキストと除外されるネーミング・コンテキストとの間で矛盾がある場合は、除外されるネーミング・コンテキストが優先されます。たとえば、ネーミング・コンテキスト・オブジェクトAの包含ネーミング・コンテキストが、別のネーミング・コンテキスト・オブジェクトBの除外ネーミング・コンテキストのサブツリーだった場合、ネーミング・コンテキスト・オブジェクトBのorclexcludednamingcontextsで指定されているサブツリーは、レプリケートされません。つまり、ネーミング・コンテキスト・オブジェクトAでのレプリケーションのフィルタリングは無視されます。

5. 2つの異なるバージョンのOracle Internet Directory(10g(10.1.4.0.1)と11g リリース1(11.1.1)など)間での部分レプリケーションを構成する場合、ネーミング・コンテキストを除外できません。そのかわり、レプリケート対象のネーミング・コンテキストを包含コンテキストとして明示的に指定する必要があります。

40.1.9.4 LDAPレプリケーションのフィルタリングの例

この項の説明は、図40-1に示すネーミング・コンテキストのサンプルに基づいて行われます。cn=user1、cn=user2およびcn=user1000の下には、ユーザー属性リストの一部が示されています。

図40-1 ネーミング・コンテキストのサンプル

関連項目:
レプリケーション・ネーミング・コンテキスト・エントリの属性の説明は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のレプリケーション・スキーマ要素に関する説明を参照してください。

前述の規則が実際にどのように働くかを次の例で説明します。

- 使用例A: あるネーミング・コンテキスト・オブジェクトで、レプリケーションに含まれるネーミング・コンテキストが、別のネーミング・コンテキスト・オブジェクトで、レプリケーションに含まれるネーミング・コンテキストのサブツリーになっている

- 使用例B: あるネーミング・コンテキスト・オブジェクトで、レプリケーションに含まれるネーミング・コンテキストが、別のネーミング・コンテキスト・オブジェクトで、レプリケーションから除外されるネーミング・コンテキストのサブツリーになっている

- ネーミング・コンテキストおよび属性の管理規則

- 部分レプリケーションのネーミング・コンテキストの最適化によるパフォーマンスの向上

使用例A: あるネーミング・コンテキスト・オブジェクトで、レプリケーションに含まれるネーミング・コンテキストが、別のネーミング・コンテキスト・オブジェクトで、レプリケーションに含まれるネーミング・コンテキストのサブツリーになっている

この例では、ネーミング・コンテキスト・オブジェクト2の包含ネーミング・コンテキストが、オブジェクト1の包含ネーミング・コンテキストのサブツリーになっているとします。

ネーミング・コンテキスト・オブジェクト1

dn:cn=namectx001,
cn=replication namecontext,
orclagreementid=unique_identifier_of_the_replication_agreement,
orclreplicaid=unique_identifier_of_the_supplier,
cn=replication configuration

orclincludednamingcontexts: cn=mycompany

図40-2に示すように、ネーミング・コンテキスト・オブジェクト1には、cn=myCompanyの下のDIT全体が含まれます。

図40-2 ネーミング・コンテキスト・オブジェクト1

ネーミング・コンテキスト・オブジェクト2

dn:cn=namectx002,
cn=replication namecontext,
orclagreementid=unique_identifier_of_the_replication_agreement,
orclreplicaid=unique_identifier_of_the_supplier,
cn=replication configuration

orclincludednamingcontexts: cn=hr,c=us,cn=mycompany
orclexcludednamingcontexts: cn=user1,cn=hr,c=us,cn=mycompany
orclexcludedattributes: userPassword

図40-3に示すように、ネーミング・コンテキスト・オブジェクト2には、cn=hr,c=us,cn=mycompanyの下のDITが含まれますが、cn=user1および属性userPasswordは除外されます。

図40-3 ネーミング・コンテキスト・オブジェクト2

ネーミング・コンテキスト・オブジェクトの1と2を組み合せた結果を図40-4に示します。

図40-4 ネーミング・コンテキスト・オブジェクトの1と2を組み合せた結果

このシナリオでは、レプリケートされるネーミング・コンテキストが、orclincludednamingcontexts属性で指定された最上位のコンテキストとなります。除外されたネーミング・コンテキストはレプリケートされません。cn=user1,cn=hr,c=us,cn=mycompany、および除外されているcn=hr,c=us,cn=mycompanyの下の属性userPasswordを除き、サブツリーcn=mycompanyの下の変更すべてがレプリケートされます。ただし、userPasswordの除外はネーミング・コンテキスト・オブジェクト2(cn=hrの下のDITにのみ含まれます)に対してのみ指定されたものであるため、残りのDITの下にある属性userPasswordは、レプリケーションから除外されません。

使用例B: あるネーミング・コンテキスト・オブジェクトで、レプリケーションに含まれるネーミング・コンテキストが、別のネーミング・コンテキスト・オブジェクトで、レプリケーションから除外されるネーミング・コンテキストのサブツリーになっている

この例では、ネーミング・コンテキスト・オブジェクト4の除外ネーミング・コンテキストが、オブジェクト3で定義されている除外ネーミング・コンテキストのサブツリーになっているとします。

ネーミング・コンテキスト・オブジェクト3

dn:cn=namectx001,cn=replication namecontext,
orclagreementid=identifier,orclreplicaid=supplier,cn=replication configuration

orclincludednamingcontexts: cn=mycompany
orclexcludednamingcontexts: c=us,cn=mycompany

図40-5に示すように、ネーミング・コンテキスト・オブジェクト3では、c=us,cn=mycompanyの下にあるすべてのものが除外されます。

図40-5 ネーミング・コンテキスト・オブジェクト3

ネーミング・コンテキスト・オブジェクト4

dn:cn=namectx002,cn=replication
namecontext,orclagreementid=identifier,orclreplicaid=supplier,
cn=replication configuration

orclincludednamingcontexts: cn=hr, c=us,cn=mycompany
orclexcludednamingcontexts: cn=user1,cn=hr,c=us,cn=mycompany
orclexcludedattributes: userPassword

図40-6に示すように、ネーミング・コンテキスト・オブジェクト4には、cn=hr,c=us,cn=mycompanyの下のDITが含まれますが、user1およびすべてのユーザーの属性userPasswordは除外されます。

図40-6 ネーミング・コンテキスト・オブジェクト4

ネーミング・コンテキスト・オブジェクトの3と4を組み合せた結果を図40-7に示します。

図40-7 ネーミング・コンテキスト・オブジェクトの3と4を組み合せた結果

この使用例では、ネーミング・コンテキスト・オブジェクト4に指定した、レプリケーションに含まれるネーミング・コンテキストはレプリケートされません。このネーミング・コンテキストは、ネーミング・コンテキスト・オブジェクト3で指定された除外ネーミング・コンテキストのサブツリーです。その場合、ネーミング・コンテキスト・オブジェクト4は無視され、cn=hr,c=us,cn=mycompanyの下の変更はレプリケートされません。

40.1.9.5 ネーミング・コンテキストおよび属性の管理規則

次のネーミング・コンテキストはレプリケートできません。

- DSEルート固有のエントリ

- orclagreementid=000001,cn=replication configuration

- cn=subconfigsubentry

- cn=Oracle Internet Directory

- cn=subregistrysubentry

次のネーミング・コンテキストはレプリケーションから除外できません。

- cn=catalogs

- cn=subschemasubentry

- cn=oracleschemaversion

- cn=replication configuration

次の属性は、必須またはオプションに関係なく、レプリケーションから除外できません。これらの属性をレプリケーションから除外するように指定しても、常にレプリケートされます。

- orclguid

- creatorsname

- createtimestamp

- cn

- dn

- attributetypes

- objectclasses

- objectclass

- orclindexedattribute

- orclproductversion

レプリケーションから必須属性を除外することはできません。たとえば、属性mandatory_attribute_1、optional_attribute_1およびoptional_attribute_2を含むmy_object_classという名前のオブジェクト・クラスがあるとします。この場合、レプリケーションからmandatory_attribute_1を除外することはできません。

エントリの必須属性である属性をレプリケーションから除外しようとしても、レプリケーション・サーバーはその属性をレプリケートします。

部分レプリケーションでは、moddn操作を使用してネーミング・コンテキストが包含から除外に変更されると、レプリケーション・サーバーによりコンシューマ側でネーミング・コンテキストが削除されます。同様に、サプライヤ側でmodnを使用してネーミング・コンテキストが除外から包含に変更されると、レプリケーション・サーバーにより、サプライヤからコンシューマまで、ネーミング・コンテキスト全体が同期化されます。

40.1.9.6 部分レプリケーションのネーミング・コンテキストの最適化によるパフォーマンスの向上

部分レプリケーションは慎重に計画して、レプリケーション・プロセスのパフォーマンスを低下させないようにする必要があります。最高のパフォーマンスを得るには、使用するネーミング・コンテキスト・オブジェクトの数をできるだけ少なくします。たとえば、ネーミング・コンテキスト・オブジェクトの5と6を組み合せる場合も、ネーミング・コンテキスト・オブジェクト7を使用する場合も、実行される条件は同じですが、パフォーマンスは、ネーミング・コンテキスト・オブジェクト7を使用する方がよくなります。

この項では、次の例について説明します。

- ネーミング・コンテキスト・オブジェクト5

- ネーミング・コンテキスト・オブジェクト6

- ネーミング・コンテキスト・オブジェクト7

ネーミング・コンテキスト・オブジェクト5

cn=namectx001,cn=replication namecontext,orclagreementid=identifier,orclreplicaid=supplier,cn=replication configuration
orclincludednamingcontexts: cn=mycompany
orclexcludednamingcontexts: c=europe,cn=mycompany
orclexcludedattributes: userPassword

ネーミング・コンテキスト・オブジェクト5を図40-8に示します。これにはcn=mycompanyの下のDITが含まれますが、c=europeの下にあるすべては除外されます。また、属性userPasswordも除外されます。

図40-8 ネーミング・コンテキスト・オブジェクト5

ネーミング・コンテキスト・オブジェクト6

cn=namectx002,cn=replication namecontext,orclagreementid=<id>,orclreplicaid=<supplier>,cn=replication configuration
orclincludednamingcontexts: cn=hr, c=us,cn=mycompany
orclexcludednamingcontexts: cn=user1,cn=hr, c=us,cn=mycompany
orclexcludedattributes: userPassword

ネーミング・コンテキスト・オブジェクト6を図40-9に示します。これにはcn=hr, c=us, cn=mycompanyの下のDITが含まれますが、user1および属性userPasswordは除外されます。

図40-9 ネーミング・コンテキスト・オブジェクト6

ネーミング・コンテキスト・オブジェクトの5と6を組み合せた場合は、cn=europe,c=mycompany、cn=user1,cn=hr,c=us,cn=mycompany、および属性userPasswordを除いて、cn=mycompanyの下の変更がすべてレプリケートされます。

ただし、同じ条件はネーミング・コンテキスト・オブジェクト7でも実現できます。使用するネーミング・コンテキスト・オブジェクトが1つのみの場合、部分レプリケーションのパフォーマンスが向上します。

ネーミング・コンテキスト・オブジェクト7

cn=namectx001,cn=replication namecontext,orclagreementid=identifier,orclreplicaid=supplier,cn=replication configuration
orclincludednamingcontexts: cn=mycompany
orclexcludednamingcontexts: c=europe,cn=mycompany
orclexcludednamingcontexts: cn=user1,cn=hr, c=us,cn=mycompany
orclexcludedattributes: userPassword

ネーミング・コンテキスト・オブジェクト7を図40-10に示します。

図40-10 ネーミング・コンテキスト・オブジェクト7

40.2 アドバンスト・レプリケーション・ベースの承諾のLDAPベースの承諾への変換

remtool -asr2ldapを使用して、複数のノード間の既存のOracle Databaseアドバンスト・レプリケーション・ベースの承諾をLDAPマルチマスター承諾に変換できます。情報を入力するようツールから要求されます。次に例を示します。

remtool -asr2ldap

Enter replication administrator's name       : repadmin

Enter replication administrator's password   :
Enter global name of MDS                     : inst1.regress.rdbms.dev.example.com
Directory Replication Group (DRG) details :

-------- ------------- ----------------------- ------------- ------------- ----
Instance Host Name     Global Name             Version       Replicaid     Site
Name                                                                       Type
-------- ------------- ----------------------- ------------- ------------- ----
tst1     stacu14       INST1.REGRESS.RDBMS.DEV OID 11.1.1.0. stacu14_tst1  MDS
tst12    stacu14       INST2.REGRESS.RDBMS.DEV OID 11.1.1.0. stacu14_tst12 RMS
-------- ------------- ----------------------- ------------- ------------- ----
Do you want to continue? [y/n] : y

------------------------------------------------------------------------------
Migrating ASR agreement to LDAP MM agreement...

Enter "SYSTEM" user password for "INST2.REGRESS.RDBMS.DEV.EXAMPLE.COM" database at "stacu14" host :
Enter "SYSTEM" user password for "INST1.REGRESS.RDBMS.DEV.example.com" database at "stacu14" host :
------------------------------------------------------------------------------
ASR setup has been cleaned up.------------------------------------------------------------------------------

40.3 レプリケーション・ウィザードを使用したLDAPベースのレプリケーション承諾の設定

Oracle Enterprise Manager Fusion Middleware Controlのレプリケーション・ウィザードを使用して、一方向、双方向またはマルチマスターのLDAPレプリカを構成します。

関連項目:
第6.2.2項「方向: 一方向、双方向またはpeer-to-peer」

注意:
Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーション承諾を構成する場合、または100,000を超えるエントリを持つディレクトリを使用したデプロイメントの場合、Oracle Enterprise Manager Fusion Middleware Controlのレプリケーション・ウィザードは使用できません。このようなレプリケーションは、コマンド行から実行する必要があります。

次のようにしてLDAPレプリケーション承諾を構成します。

1. ホームページの「Oracle Internet Directory」メニューから、「管理」、「レプリケーション管理」の順に選択します。

2. レプリケーション識別名アカウントへのログインを要求されます。ホスト、ポート、レプリケーション識別名およびレプリケーション識別名のパスワードを入力します。このOIDコンポーネントで匿名ユーザーによるバインドが有効な場合には、レプリケーション識別名、ホストおよびポートの各フィールドは自動的に入力され、グレー表示されます。パスワードの入力のみが必要です。

3. 「作成」アイコンをクリックします。

4. 「タイプ」画面でレプリケーション・タイプ(「一方向レプリケーション」、「双方向レプリケーション」または「マルチマスター・レプリケーション」)を選択します。

5. 「次へ」をクリックします。選択したレプリケーション・タイプが「レプリカ」画面に表示されます。

6. 承諾名を指定します。この名前はすべてのノードで一意である必要があります。

7. 一方向レプリケーションまたは双方向レプリケーションでは、コンシューマ・ノードのホスト、ポート、ユーザー名(レプリケーション識別名)およびレプリケーションのパスワードを入力します。サプライヤ・ノードのフィールドは移入されグレー表示されます。

マルチマスター・レプリケーションでは、セカンダリ・ノードのホスト、ポート、ユーザー名(レプリケーション識別名)およびレプリケーションのパスワードを入力します。プライマリ・ノードのフィールドは移入されグレー表示されます。

8. 「次へ」をクリックして、「設定」ページに移動します。

9. 複数のLDAP操作の実行に同じ接続をレプリケーション・サーバーで使用する場合は、「LDAP接続」フィールドで、「キープ・アライブ」を選択します。サーバーでそれぞれのLDAP操作について新規の接続を開始するには、「常に新規の接続を使用」を選択します。

10. 「レプリケーション頻度」を入力します。

11. 「管理者操作キュー・スケジュール」を入力します。これは、ディレクトリ・レプリケーション・サーバーが変更適用プロセスを繰り返す間隔(秒単位)です。

12. 承諾タイプとして「双方向レプリケーション」または「マルチマスター・レプリケーション」を指定した場合、「レプリケーション・サーバー起動詳細」というセクションが設定ページに含まれます。「サーバーの起動」を選択してサーバー・インスタンスを起動したり、「ブートストラップの有効化」を選択してブートストラップを有効にできます。まずホストを選択し、ホストの「インスタンス名」と「コンポーネント名」を選択します。次に「サーバーの起動」または「ブートストラップの有効化」、あるいはその両方を選択します。

13. 「次へ」をクリックして、「有効範囲」ページに移動します。デフォルトのプライマリ・ネーミング・コンテキストが入力されます。

14. デフォルト・プライマリ・ネーミング・コンテキスト内でセカンダリ・ネーミング・コンテキストを除外するには、プライマリ・ネーミング・コンテキストを選択して「作成」ボタンをクリックします。その後、手順16に進みます。

15. 別のプライマリ・ネーミング・コンテキストを作成するには、「プライマリ・ネーミング・コンテキストの作成」ボタンをクリックします。これにより、「プライマリ・ネーミング・コンテキスト」ダイアログが起動します。
プライマリ・ネーミング・コンテキストを指定するには、「プライマリ・ネーミング・コンテキスト」フィールドに識別名を手動で入力するか、または「選択」をクリックしてプライマリ・ネーミング・コンテキストとして使用する識別名を参照します。コンテナを選択し、「OK」をクリックします。

16. セカンダリ・ネーミング・コンテキストを除外するには、「除外されたセカンダリ・ネーミング・コンテキスト」フィールドの下にある「追加」アイコンをクリックします。これによって「除外するセカンダリ・ネーミング・コンテキストの選択」ダイアログが起動されます。ネーミング・コンテキストを選択し、「OK」をクリックします。「除外されたセカンダリ・ネーミング・コンテキスト」フィールドにネーミング・コンテキストが表示されます。

17. 属性を除外するには、「除外された属性」フィールドの下にある「追加」アイコンをクリックします。これによって除外する属性の選択画面が起動されます。除外する属性を選択して「OK」をクリックします。「除外された属性」フィールドにその属性が表示されます。

18. 「OK」をクリックします。プライマリ・ネーミング・コンテキストが「有効範囲」ページに表示されます。

19. 「次へ」をクリックします。作成するレプリケーション承諾の概要が「サマリー」ページに表示されます。

20. 「終了」をクリックして、レプリケーション承諾を作成します。

40.4 Oracle Directory Services Managerを使用したレプリケーションのテスト

次を実行することにより、Oracle Directory Services Managerを使用してディレクトリ・レプリケーションをテストします。

1. 第7.4.5項「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動し、Oracle Internet Directoryサーバーに接続します。

2. タスク選択バーで、「データ・ブラウザ」を選択します。

3. 第13.2.6項「Oracle Directory Services Managerを使用した新規エントリの追加」の説明に従って、MDSノード上で単一エントリを作成します。
同一のエントリが、RMSに約1から10分後に表示されます。このタイミングは、レプリケーション・サーバーの構成設定エントリで調整できます。エントリがDRGのいずれかのノードで変更されると、その変更はレプリケートされます。

40.5 コマンド行を使用したLDAPベースのレプリケーションの設定

この項の項目は次のとおりです。

- 第40.5.1項「ldifwriteとbulkloadを使用したLDAPデータのコピー」

- 第40.5.2項「カスタム設定を使用したLDAPベースのレプリカの設定」

- 第40.5.3項「パスワード・ポリシーとファンアウト・レプリケーション」

- 第40.5.4項「LDAPベースのレプリカの削除」

関連項目:
第6.2.2項「方向: 一方向、双方向またはpeer-to-peer」

40.5.1 ldifwriteとbulkloadを使用したLDAPデータのコピー

ldifwriteおよびbulkloadを使用すると、LDAPデータを1つのホストから別のホストへコピーできます。操作属性を保持してLDAPデータをバックアップするには、ldifwriteユーティリティを使用します。この操作を実行した後は、bulkloadユーティリティを使用して、グループ内のすべてのレプリカにデータをロードします。

まず引数check="TRUE"、generate="TRUE"およびrestore="TRUE"を指定し、次に引数load="TRUE"を指定してbulkloadを使用します。すべてのレプリカに同じ中間ファイル(generate="TRUE"引数を使用して生成)を使用することにより、操作属性を保存します。connect="connect_string"をレプリカごとに適切な接続文字列を指定して使用することにより、bulkloadコマンドの1回の起動で複数のレプリカをロードできます。

100万件のエントリがあるディレクトリの場合、この方法では長時間かかります。

関連項目:

- 第15章「バルク操作の実行」

- 第26章「Oracle Internet Directoryのバックアップとリストア」

- 『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のOracle Identity Managementコマンド行ツールのリファレンス

40.5.2 カスタム設定を使用したLDAPベースのレプリカの設定

カスタム設定を確立するには、まず新しいノードをインストールする必要があります。これを行うには、『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』の説明に従ってください。

remtoolを使用してLDAPベースのレプリケーションを構成した後、LDAPベースのノードに対してレプリケートされる項目を定義するnamingcontextをカスタマイズできます。

関連項目:
ネーミング・コンテキストの詳細は、第43.1.1項「LDAPベースの部分レプリケーションでのレプリケート対象の変更」を参照してください。

カスタム設定を使用してLDAPベースのレプリカを設定するには、ディレクトリのデータをどのように移行するかによって、2つの方法があります。

- コマンド行ツールを使用します。ldifwriteを使用してサプライヤ・レプリカのデータをバックアップした後、bulkloadを使用してコンシューマ・レプリカにデータをリストアします。

- 自動ブートストラップを使用します。これはレプリケーション・サーバーの機能で、レプリケーション構成に基づいてサプライヤ・レプリカからコンシューマ・レプリカにデータを自動的にブートストラップします。

表40-1に、2つの方法の比較を示します。

表40-1 ldifwrite/bulkloadを使用したデータ移行と自動ブートストラップを使用したデータ移行の比較

ldifwrite/bulkloadを使用した移行

自動ブートストラップを使用した移行

手動プロシージャ

高速パフォーマンス

大量のデータに最適

自動プロシージャ

部分レプリケーションのフィルタ機能を使用

エントリ数が少ない場合に最適

注意:
次のシナリオではコマンド行ツール(ldifwriteおよびbulkload)を使用する必要があります。

- アドバンスト・レプリケーション・ベースのレプリケーション

- 100,000を超えるエントリを持つディレクトリのレプリケーション

他のシナリオでは、どちらの移行方法も使用できます。

データ移行方法として自動ブートストラップを選択した場合は、第40.5.2.1項「自動ブートストラップを使用したLDAPベースのレプリカの設定」の指示に従って、LDAPベースのレプリカをカスタマイズします。

データ移行方法としてldifwrite/bulkloadを選択した場合は、第40.5.2.2項「ldifwriteツールを使用したLDAPベースのレプリカの設定」の指示に従って、LDAPベースのレプリカを構成します。

40.5.2.1 自動ブートストラップを使用したLDAPベースのレプリカの設定

次の8つのタスクを実行すると、自動ブートストラップを使用してLDAPベースのレプリカを構成できます。各タスクの詳細は、このリストの後で説明します。

- タスク1: サプライヤ・ノードでのディレクトリ・サーバーの特定と起動

- タスク2: Oracle Internet Directoryのインストールによる新規コンシューマ・ノードの作成

- タスク3: 新規コンシューマ・ノードのメタデータのバックアップ

- タスク4: レプリケーション環境管理ツールを使用したLDAPベースのレプリカの追加

- タスク5: コンシューマ側でコンシューマ・レプリカを自動ブートストラップ用に構成

- タスク6: オプション: デフォルトのレプリケーション・パラメータの変更

- タスク7: ディレクトリ・レプリケーション・サーバーの起動の確認

- タスク8: 新規ノードにOracle Delegated Administration ServicesまたはOracle Single Sign-Onがインストールされている場合、新規ノードのディレクトリ内のエントリをリストア

40.5.2.1.1 タスク1: サプライヤ・ノードでのディレクトリ・サーバーの特定と起動

LDAPベースのレプリカのサプライヤを特定します。次のいずれかがサプライヤとなります。

- レプリケーション・グループのメンバーではないディレクトリ

- マルチマスター・レプリケーション・グループのノード

- 別のLDAPベースのレプリカ

サプライヤ・ノードでOracle Internet Directoryサーバーが起動していることを確認します。ディレクトリ・サーバーを起動するには、次のコマンドを入力します。

opmnctl startproc ias_component=oid1

40.5.2.1.2 タスク2: Oracle Internet Directoryのインストールによる新規コンシューマ・ノードの作成

『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』の説明に従って、新しいOracle Internet Directoryをレプリカにインストールします。

40.5.2.1.3 タスク3: 新規コンシューマ・ノードのメタデータのバックアップ

カスタム設定を使用して新規ノードをLDAPベースのレプリカとして構成する前に、まず新規ノードのメタデータを次のようにサプライヤ・ノードに移行する必要があります。

- バックアップ・プロセス(remtool –backupmetadata)が正しく機能するように、Oracle Internet Directoryサーバーがサプライヤ・ノードとタスク2で作成した新規ノードの両方で稼働していることを確認します。

- 新たに作成したノードから、次のコマンドを実行します。

remtool –backupmetadata \
–replica "new_node_host:new_node_port" \
–master "master_host:master_port"

master_host:master_portは、対象となるレプリカのサプライヤのホスト名およびポート番号です。レプリケーション識別名のパスワードを要求されます。

注意:
Oracle Delegated Administration Servicesが構成されていない場合、remtoolを-backupmetadataオプションを指定して実行すると、次のようなエラー・メッセージが表示されます。

Failed to add "orclApplicationCommonName=ias.example.com,
cn=IAS Instances, cn=IAS, cn=Products, cn=OracleContext"
as "uniquemember" to entry "cn=Associated Mid-tiers,
orclapplicationcommonname=DASApp, cn=DAS,cn=products,
cn=OracleContext at replica ldap://myhost:3060

このエラー・メッセージは無視してください。

関連項目:
-backupmetadataを含めたremtoolオプションの詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のremtoolコマンド行ツールのリファレンスを参照してください。

- このコマンドは、メタデータをマスター・レプリカにロードする以外に、メタデータのバックアップを含むocbkup.new_replica_id.TO.master_replicaid.timestamp.ldifという名前のファイルを作成します。このファイルはORACLE_INSTANCE /diagnostics/logs/OID/toolsディレクトリに作成されます。このファイルには、LDIF形式でのマスター・レプリカの変更と、SSOのコンテナ・エントリ[orclApplicationCommonName=ORASSO_SSOSERVER, cn=SSO, cn=Products, cn=OracleContext]およびDASのURLコンテナ・エントリ[cn=OperationURLs, cn=DAS, cn=Products, cn=OracleContext]のコピーが格納されます。

- メタデータのバックアップに成功した場合、次のメッセージが端末に表示されます。

Backup of metadata will be stored in ORACLE_INSTANCE/diagnostics
/logs/OID/tools/ocbkup.replicaid_pilot.TO.replcicaid_master.timestamp.ldif.

Metadata copied successfully.

このメッセージには、ORACLE_INSTANCEのパスとファイル名が含まれます。

- メタデータのバックアップに失敗した場合、ORACLE_INSTANCE/diagnostics/logs/OID/tools/remtool.logファイルにエラー・メッセージが記録されます。remtoolを端末から起動した場合は、その端末にエラー・メッセージが表示されます。

40.5.2.1.4 タスク4: レプリケーション環境管理ツールを使用したLDAPベースのレプリカの追加

レプリカを追加するには、コンシューマ・レプリカで次のように入力します。

remtool -paddnode [-v] [-bind supplier_host_name:port]

replication_dn_passwordの入力を要求されます。

remtoolユーティリティから承諾のタイプの指定を求められます。追加するレプリカのタイプに応じて、一方向LDAP、双方向LDAPまたはマルチマスターLDAPのいずれかを選択します。

サプライヤのレプリカIDを要求されます。これは、ルートDSEエントリの属性orclreplicaidの値です。指定する値を検索するには、次のように入力します。

ldapsearch -D cn=orcladmin -q  -p port -b "" -s base "objectclass=*" orclreplicaid

サプライヤ・レプリカで使用できるネーミング・コンテキストのリストが要求されます。異なるバージョンのOracle Internet Directoryが稼働するサーバー・インスタンス間での部分レプリケーションを設定する場合、eと入力します。

remtoolが正常に完了したら、次のようにしてレプリケートされるサブツリーごとに異なるネーミング・コンテキストを追加します。

1. サプライヤ・レプリカ・ノードとコンシューマ・レプリカ・ノードの両方で次の検索コマンドを実行し、両ノードのレプリカIDを確認します。

ldapsearch -h host -p port -D cn=orcladmin -q -b "" \
-s base "objectclass=*" orclreplicaid

2. レプリケーション承諾エントリを確認します。形式は次のとおりです。

"orclagreementid=unique_identifier_of_the_replication_agreeement,orclreplicaid=supplier_replica_id,cn=replication configuration"

これを検索するには、次のように入力します。

ldapsearch -D cn=orcladmin -q -h supplier_host -p supplier_port \
-b "orclreplicaid=supplier_replica_id,cn=replication configuration" \
-s sub "(&(orclreplicadn=*consumer_replica_id*)(objectclass=orclreplagreemententry))" dn

3. コンシューマ・レプリカ・ノードとサプライヤ・レプリカ・ノードの両方で、レプリケーションに含めるネーミング・コンテキストごとに次のようなエントリを追加します。次のLDIFファイルでは、レプリケーションに含めるネーミング・コンテキスト(サブツリー)およびレプリケーションから除外する属性を指定します。

dn: cn=includednamingcontext000002,
cn=replication namecontext,orclagreementid=000003,
orclreplicaid=stajv18_oid10143,cn=replication configuration
objectclass: top
objectclass: orclreplnamectxconfig
orclincludednamingcontexts: cn=users,dc=small,dc=com
orclexcludedattributes: userpassword
orclexcludedattributes: telephonenumber
cn: includednamingcontext000002

次のLDAP追加コマンドを使用して、コンシューマ・レプリカとサプライヤ・レプリカのOracle Internet DirectoryにLDIFファイルを追加します。

ldapadd -D cn=orcladmin -q -h host -p port -v -f ldif_file

4. 部分レプリケーションに構成するネーミング・コンテキスト(サブツリー)ごとに、手順3を繰り返します。

関連項目:

- レプリケーション環境管理ツールの詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のremtoolコマンド行ツールのリファレンスを参照してください。

- 第40.1.9項「部分レプリケーションのためのLDAPレプリケーションのフィルタリング」

40.5.2.1.5 タスク5: コンシューマ側でコンシューマ・レプリカを自動ブートストラップ用に構成

自動ブートストラップ機能を使用するには、コンシューマ側で、次のようにコンシューマ・レプリカのサブエントリのorclReplicaState属性を0に設定します。

1. サンプル・ファイルmod.ldifを、次のように編集します。

Dn: orclreplicaid=unique_replicaID_of_consumer, cn=replication configuration
Changetype:modify
replace:orclReplicaState
OrclReplicaState: 0

注意:
WindowsシステムではorclReplicaStateの値を0に変更してブートストラップを有効にする前に、レプリケーション・サーバーが稼働していないことを確認します。

2. コンシューマ側でldapmodifyを使用して、コンシューマ・レプリカのサブエントリのorclreplicastate属性を更新します。

ldapmodify –D "cn=orcladmin" -q -h consumer_host -p port -f mod.ldif

関連項目:
LDAPベースのレプリケーションのブートストラップ機能の詳細は、第43章「レプリケーションの管理およびモニタリング」を参照してください。

40.5.2.1.6 タスク6: オプション: デフォルトのレプリケーション・パラメータの変更

レプリケーション承諾およびレプリカ・サブエントリのデフォルトのパラメータを変更できます。

関連項目:

- 第42章「レプリケーション構成属性の管理」

- 第43.1.1項「LDAPベースの部分レプリケーションでのレプリケート対象の変更」

40.5.2.1.7 タスク7: ディレクトリ・レプリケーション・サーバーの起動の確認

レプリケーション・サーバーを起動する正確な手順は、サーバーが一方向レプリカ、双方向レプリカまたはマルチマスター・レプリカのいずれにあるのかによって異なります。

- 一方向LDAPレプリケーションの場合は、コンシューマでレプリケーション・サーバーを起動する必要があります。たとえば、oid1にあるレプリケーション・サーバーを起動するには、次を入力します。

oidctl connect=connStr server=oidrepld instance=1 \
name=asinst_1 component name=oid1 \
flags="-h consumer_host -p consumer_port" start

注意:
読取り専用のレプリカ・コンシューマを持つ単一のマスターをデプロイする場合、競合解消をオフにすると、パフォーマンス・オーバーヘッドを低減できます。これを行うには、ldapmodifyで次のLDIFファイルを使用して、orclconflresolutionの値を0に変更します。

dn: cn=configset0,cn=osdrepld,cn=subconfigsubentry
changetype: modify
replace: orclconflresolution
orclconflresolution: 0

- 双方向またはマルチマスターLDAPレプリケーションの場合は、次のように各ノードでOracle Internet Directoryレプリケーション・サーバーを起動する必要があります。

oidctl connect=connStr server=oidrepld instance=1 \
name=instance_name componentname=component_name flags="-h \
LdapHost -p LdapPort" start

レプリケーション・サーバーが起動すると、サプライヤからコンシューマへのデータのブートストラップが開始されます。ブートストラップが正常に完了すると、レプリケーション・サーバーが自動的にオンライン・モード(orclreplicastate=1)に変わり、変更内容をサプライヤからコンシューマに適用します。次のコマンド行を使用してorclreplicastateの値をモニターできます。

ldapsearch -p port-h host -D cn=orcladmin -q \
-b "orclreplicaid=unique_replicaID_of_consumer, cn=replication configuration" \
-s base "objectclass=*" orclreplicastate

40.5.2.1.8 タスク8: 新規ノードにOracle Delegated Administration ServicesまたはOracle Single Sign-Onがインストールされている場合、新規ノードのディレクトリ内のエントリをリストア

Oracle Delegated Administration ServicesおよびOracle Single Sign-Onのエントリは、各サービスのローカル・インスタンスを参照する必要があります。しかし、レプリケーションをサプライヤからコンシューマに最初にダウンロードしたときには、サプライヤからレプリケートされた値を使用してこれらのエントリが作成されます。各サービスが実際にはコンシューマ・ノードに構成されている場合、これらの値をコンシューマ・ノードに適した正しい情報に置き換える必要があります。

- Delegated Administration Service(DAS)がコンシューマ・ノードに構成されている場合、次の手順に従ってDASをリストアする必要があります。

1. タスク3により作成したocbkup.new_replicaid.TO.master_replicaid.timestamp.ldifファイルで、DAS URLを見つけてコピーします。DAS URLコンテナ・エントリの識別名は、cn=OperationURLs, cn=DAS, cn=Products, cn=OracleContextです。通常、これがファイルの最後から2番目のエントリです。

2. LDIFファイルchange_das_url.ldifを作成します。このファイルの内容は次のとおりです。

dn: cn=OperationURLs,cn=DAS,cn=Products,cn=OracleContext
changetype: modify
replace: orcldasurlbase
orcldasurlbase: copy_paste_the_URL_from_backup_file

3. 次のコマンドを実行して、DASのURLを変更します。

ldapmodify –p consumer_port -h consumer_host -D super_user_DN \
-q -f change_das_URL.ldif

- 同様に、Single Sign-On(SSO)がコンシューマ・ノードに構成されている場合、次の手順に従ってSSOをリストアする必要があります。

1. タスク3により作成したocbkup.timestamp.datファイルで、SSOコンテナ・エントリを見つけてコピーします。手順2に示す属性のみをコピーします。SSOコンテナ・エントリの識別名は、orclApplicationCommonName=ORASSO_SSOSERVER, cn=SSO, cn=Products, cn=OracleContextです。通常、これがファイルの最後のエントリです。

関連項目:
10g (10.1.4.0.1)ライブラリの『Oracle Application Server Single Sign-On管理者ガイド』。

2. LDIFファイルadd_SSO_container.ldifを作成します。このファイルの内容は次のとおりです。

dn: orclApplicationCommonName=ORASSO_SSOSERVER,
cn=SSO,cn=Products,cn=OracleContext
orclapplicationcommonname: ORASSO_SSOSERVER
orclappfullname: ORASSO_SSOSERVER
orclversion: 10.1.2.0.0
objectclass: orclApplicationEntity
objectclass: top
userpassword: userpassword_copied_from_backup_file

注意:
authpassword;oid、createtimestamp、creatorsname、modifiersname、modifytimestamp、orclguidの各属性はコピーしないでください。

3. 次のコマンドを実行して、SSOのコンテナ・エントリを追加します。

ldapadd –p consumer_port -h consumer_host -D super_user_DN \
-q -f add_SSO_container.ldif

4. LDIFファイルmod.ldifを作成します。このファイルの内容は次のとおりです。

dn: cn=OracleUserSecurityAdmins,cn=Groups,cn=OracleContext
changetype:modify
add: uniquemember
uniquemember: orclApplicationCommonName=ORASSO_SSOSERVER,
cn=SSO,cn=Products,cn=OracleContext

dn: cn=verifierServices, cn=Groups,cn=OracleContext
changetype:modify
add: uniquemember
uniquemember: orclApplicationCommonName=ORASSO_SSOSERVER,
cn=SSO,cn=Products,cn=OracleContext

5. 次のコマンドを実行して、mod.ldifを適用します。

ldapmodify -p consumer_port -h consumer_host -D super_user_DN \
-q -f mod.ldif

6. ブラウザを使用して、Oracle Delegated Administration ServicesページとOracle Single Sign-Onページをテストします。
Oracle Delegated Administration Servicesをテストするには、adminユーザーorcladminとしてOracle Delegated Administration Servicesページ(http(s)://new_node_hostname:new_node_http_port/oiddas/)にログインします。ログインできない場合、10g (10.1.4.0.1)ライブラリの『Oracle Identity Management委任管理ガイド』のトラブルシューティングに関する付録を参照してください。

Oracle Single Sign-Onをテストするには、super adminユーザーorcladminとしてOracle Single Sign-Onページ(http(s)://new_node_hostname:new_node_http_port/pls/orasso/)にログインします。ログインできない場合、10g (10.1.4.0.1)ライブラリの『Oracle Application Server Single Sign-On管理者ガイド』のトラブルシューティングに関する付録を参照してください。

40.5.2.2 ldifwriteツールを使用したLDAPベースのレプリカの設定

この項では、ldifwriteツールを使用して、LDAPベースのレプリカを構成する場合に実行する一般的なタスクについて説明します。この項の内容は、次のとおりです。

- タスク1: サプライヤ・ノードとコンシューマ・ノードの両方でディレクトリ・サーバーを起動

- タスク2: 新規コンシューマ・ノードのメタデータのバックアップ

- タスク3: サプライヤ側のディレクトリ・サーバーの読取り専用モードへの切替え

- タスク4: レプリケーション環境管理ツールを使用したLDAPベースのレプリカの追加

- タスク5: レプリケートするネーミング・コンテキストのバックアップ

- タスク6: サプライヤ側のディレクトリ・サーバーの読取り/書込みモードへの切替え

- タスク7: 新規コンシューマへのデータのロード

- タスク8: 新規ノードにOracle Delegated Administration ServicesまたはOracle Single Sign-Onがインストールされている場合、新規ノードのディレクトリ内のエントリをリストア

- タスク9: オプション: デフォルトのレプリケーション・パラメータの変更

- タスク10: ディレクトリ・レプリケーション・サーバーの起動の確認

40.5.2.2.1 タスク1: サプライヤ・ノードとコンシューマ・ノードの両方でディレクトリ・サーバーを起動

1. LDAPベースのレプリカのサプライヤを特定します。次のいずれかがサプライヤとなります。

- レプリケーション・グループのメンバーではないディレクトリ

- マルチマスター・レプリケーション・グループのノード

- 別のLDAPベースのレプリカ

サプライヤ・ノードでOracle Internet Directoryサーバーが起動していることを確認します。ディレクトリ・サーバーを起動するには、次のコマンドを入力します。

opmnctl startproc ias_component=oid1

2. コンシューマ・ノードを識別し、このノードにOracle Internet Directoryを新しくインストールする必要があります。新しいOracle Internet Directoryをマスターとしてインストールするには、『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』の指示に従い、Oracle Internet Directoryサーバーが新規コンシューマ・ノードで起動されることを確認します。ディレクトリ・サーバーを起動するには、次のコマンドを入力します。

opmnctl startproc ias-component=oid1

40.5.2.2.2タスク2: 新規コンシューマ・ノードのメタデータのバックアップ

カスタム設定を使用してコンシューマをLDAPベースのレプリカとして構成する前に、まずコンシューマのメタデータを次のようにサプライヤ・ノードに移行する必要があります。

- バックアップ・プロセス(remtool –backupmetadata)が正しく機能するように、Oracle Internet Directoryサーバーがサプライヤ・ノードとタスク2で作成した新規ノードの両方で稼働していることを確認します。

- コンシューマ・ノードから、次のコマンドを実行します。

remtool –backupmetadata \
–replica "consumer_host:consumer_port" \
–master "supplier_host:supplier_port"

パスワードが要求されます。

- このツールは、メタデータをマスター・レプリカにロードする以外に、メタデータのバックアップを含むocbkup.consumer_replica_id.TO.supplier_replica_id.timestamp.datという名前のファイルを作成します。このファイルはORACLE_INSTANCE/diagnostics/logs/OID/toolsディレクトリに作成されます。このファイルには、LDIF形式でのマスター・レプリカの変更と、SSOのコンテナ・エントリ[orclApplicationCommonName=ORASSO_SSOSERVER, cn=SSO, cn=Products, cn=OracleContext]およびDASのURLコンテナ・エントリ[cn=OperationURLs, cn=DAS, cn=Products, cn=OracleContext]のコピーが格納されます。

- メタデータのバックアップに成功した場合、remtoolにより次のメッセージが端末に表示されます。

Backup of metadata will be stored in ORACLE_INSTANCE/diagnostics
/logs/OID/tools/ocbkup.replicaid_pilot.TO.replcicaid_master.timestamp.ldif.

Metadata copied successfully.

メッセージには、ORACLE_INSTANCEのパスが含まれます。

このメッセージには、ORACLE_INSTANCEの実際のパスとファイル名が含まれます。

メタデータのバックアップに失敗した場合、ORACLE_INSTANCE/diagnostics/logs/OID/tools/remtool.logファイルにエラー・メッセージが記録されます。remtoolを端末から起動した場合は、その端末にエラー・メッセージが表示されます。

40.5.2.2.3 タスク3: サプライヤ側のディレクトリ・サーバーの読取り専用モードへの切替え

データ整合性を保証するために、サプライヤ・ノードのディレクトリ・サーバーを読取り専用モードに切り替えます。サーバーを読取り/書込みモードから読取り専用モードに切り替えるには、第15.2項「サーバー・モードの変更」の手順のいずれかを使用します。

40.5.2.2.4 タスク4: レプリケーション環境管理ツールを使用したLDAPベースのレプリカの追加

レプリカを追加するには、コンシューマ・レプリカで次のように入力します。

remtool -paddnode [-v] [-bind supplier_host_name:port]

replication_dn_passwordの入力を要求されます。remtoolユーティリティから承諾のタイプの指定を求められます。追加するレプリカのタイプに応じて、一方向LDAPまたは双方向LDAPのいずれかを選択します。

関連項目:
レプリケーション環境管理ツールの詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のremtoolコマンド行ツールのリファレンスを参照してください。

40.5.2.2.5 タスク5: レプリケートするネーミング・コンテキストのバックアップ

LDAPベースのレプリカにレプリケートするエントリが、ネーミング・コンテキスト内に大量にある場合は、サプライヤ・ノードでこれらのネーミング・コンテキストをバックアップし、それをLDAPベースのレプリカにロードすることをお薦めします。

ネーミング・コンテキストをバックアップする手順は、次のとおりです。

1. 「タスク4: レプリケーション環境管理ツールを使用したLDAPベースのレプリカの追加」で作成したレプリケーション承諾識別名を特定します。

ldapsearch -h supplier_host -p port \
-b "orclreplicaid=supplier_replicaID,cn=replication configuration" \
-s sub "(orclreplicadn= orclreplicaid=consumer_replica_ID, \
cn=replication configuration)" dn

2. サプライヤ側で、ORACLE_INSTANCEが設定されていることを確認し、次のコマンドを使用してサプライヤからデータを取得します。ファイルにロードされたデータは、構成済の承諾に基づきます。

ldifwrite connect="connect_string_of_sponsor_node" \
baseDN="replication_agreement_dn_retrieved_in_step_1" \
file="name_of_output_LDIF_file"

関連項目:

- 第43.1.1項「LDAPベースの部分レプリケーションでのレプリケート対象の変更」

- ldifwriteを使用してネーミング・コンテキストの一部をバックアップする方法は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のldifwriteコマンド行ツールのリファレンスを参照してください。

40.5.2.2.6 タスク6: サプライヤ側のディレクトリ・サーバーの読取り/書込みモードへの切替え

「タスク3: サプライヤ側のディレクトリ・サーバーの読取り専用モードへの切替え」を実行した場合は、サプライヤ側のディレクトリ・サーバーを読取り/書込みモードに戻します。第15.2項「サーバー・モードの変更」の手順のいずれかを使用します。

40.5.2.2.7 タスク7: 新規コンシューマへのデータのロード

この手順は、次のとおりです。

1. 複数のファイルがある場合は、たとえば、backup_data.ldifなどの1つのファイルにまとめます。

2. LDAPベースのコンシューマ・レプリカにネーミング・コンテキストがある場合は、bulkdeleteを使用して削除します。ORACLE_INSTANCEが設定されていることを確認し、次のように入力します。

bulkdelete connect="connect_string_of_replica" baseDN="naming_context"

「タスク5: レプリケートするネーミング・コンテキストのバックアップ」でバックアップしたネーミング・コンテキストについて、この手順を実行します。

コンシューマ側で、bulkloadを追加モードで使用してデータをレプリカにロードします。ORACLE_INSTANCEが設定されていることを確認し、次のように入力します。

bulkload connect="connect_string_of_replica" append="TRUE" check="TRUE" \
generate="TRUE" restore="TRUE" file="backup_data.ldif"

bulkload connect="connect_string_of_replica" load="TRUE"

注意:
Oracle Internet Directoryの旧リリース(10g リリース2(10.1.2.0.2)など)のデータを、11g リリース1(11.1.1)が稼働しているノードにロードする場合、第40.5.3項「パスワード・ポリシーとファンアウト・レプリケーション」の説明に従って、パスワード・ポリシー・エントリを更新する必要があります。

関連項目:

- デフォルト・モードまたは追加モードでbulkloadを使用する方法は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のbulkloadコマンド行ツールのリファレンスを参照してください。

- 『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のbulkdeleteコマンド行ツールのリファレンス

40.5.2.2.8 タスク8: 新規ノードにOracle Delegated Administration ServicesまたはOracle Single Sign-Onがインストールされている場合、新規ノードのディレクトリ内のエントリをリストア

「タスク8: 新規ノードにOracle Delegated Administration ServicesまたはOracle Single Sign-Onがインストールされている場合、新規ノードのディレクトリ内のエントリをリストア」に記載されている手順に従います。

40.5.2.2.9 タスク9: オプション: デフォルトのレプリケーション・パラメータの変更

レプリケーション承諾、レプリカ・サブエントリ、およびレプリケーション・ネーミング・コンテキスト構成オブジェクトのデフォルトのパラメータを変更できます。

関連項目:

- 第42章「レプリケーション構成属性の管理」

- 第43.1.1項「LDAPベースの部分レプリケーションでのレプリケート対象の変更」

40.5.2.2.10 タスク10: ディレクトリ・レプリケーション・サーバーの起動の確認

レプリケーション・サーバーを起動する正確な手順は、サーバーが一方向レプリカまたは双方向レプリカのいずれにあるのかによって異なります。

- 一方向LDAPレプリケーションの場合は、コンシューマでレプリケーション・サーバーを起動する必要があります。次のように入力します。

oidctl connect=connStr server=oidrepld instance=1 \
name=instance_name componentname=oidComponentName \
flags="-h LdapHost -p LdapPort" start

注意:
読取り専用のレプリカ・コンシューマを持つ単一のマスターをデプロイする場合、競合解消をオフにすると、パフォーマンス・オーバーヘッドを低減できます。これを行うには、ldapmodifyで次のLDIFファイルを使用して、orclconflresolutionの値を0に変更します。

dn: cn=configset0,cn=osdrepld,cn=subconfigsubentry
changetype: modify
replace: orclconflresolution
orclconflresolution: 0

- 双方向LDAPレプリケーションの場合は、スポンサ・レプリカと新規レプリカの両方で、Oracle Internet Directoryレプリケーション・サーバーを次のように起動する必要があります。

1. スポンサ・レプリカでレプリケーションを起動または再起動します。次のように入力します。

oidctl connect=connStr server=oidrepld instance=1 \
name=instance_name componentname=component_name \
flags="-h LdapHost -p LdapPort" start

2. 新規レプリカでレプリケーション・サーバーを起動します。次のように入力します。

oidctl connect=connStr server=oidrepld instance=1 \
name=instance_name componentname=oidComponentName \
flags="-h LdapHost -p LdapPort" start

40.5.3 パスワード・ポリシーとファンアウト・レプリケーション

Oracle Internet Directory 11g リリース1(11.1.1)では、10g リリース2(10.1.2.0.2)より前のリリースより細かいパスワード・ポリシーをサポートしています。このため、マスター・ノードが旧リリース(10g リリース2(10.1.2.0.2)など)で、新規のファンアウト・ノードが11g リリース1(11.1.1)の場合、問題が発生する可能性があります。マスター・ノードのパスワード・ポリシー・エントリは、ブートストラップやファンアウト・ノードへの移行の際に、予想どおりに動作しない場合があります。この問題を解決するには、ファンアウト・ノードの設定の一部として、マスターのデータをブートストラップするか移行した後、Javaクラスoracle.ldap.oidinstall.backend.OIDUpgradePasswordPoliciesを起動することにより、パスワード・ポリシー・エントリを更新する必要があります。コマンド行構文は次のとおりです。

java –cp ORACLE_HOME/ldap/lib/oidca.jar:ORACLE_HOME/ldap/jlib/ldapjclnt10.jar \
oracle.ldap.oidinstall.backend.OIDUpgradePasswordPolicies host port bindDN \
bindPassword ORACLE_HOME[protocol]

表40-2に、コマンド行のパラメータを示します。

表40-2 OIDUpgradePasswordPoliciesに対するコマンド行パラメータ

パラメータ

説明

host

11g リリース1(11.1.1)ディレクトリ・サーバーが稼働しているホスト

port

11g リリース1(11.1.1)ディレクトリ・サーバーがリスニングしているポート。プロトコルがsslの場合、portはSSLポートである必要があります。

bindDN

権限を持つ管理ユーザーは通常cn=orcladmin

bindPwd

bindDNに関連付けられたユーザー・パスワード

ORACLE_HOME

Oracle Internet DirectoryのこのインスタンスのOracleホーム

protocol

オプション・パラメータ。これは、SSL環境ではsslである必要があります。

ツールにより実行されるアクションはすべて、ORACLE_HOME\ldap\logディレクトリにあるppUpgrade.logに記録されます。

注意:
ツールを実行する前に、該当する環境変数が正しく設定されていることを確認します。

- LinuxまたはSolarisでは、LD_LIBRARY_PATH変数にORACLE_HOME/libおよびORACLE_HOME/network/libが含まれている必要があります。

- 64ビットSolarisでは、LD_LIBRARY_PATH変数にORACLE_HOME/lib32およびORACLE_HOME/network/lib32が含まれている必要があります。

- Windowsでは、PATH変数にORACLE_HOME\binおよびORACLE_HOME\network\binが含まれている必要があります。

関連項目:
第29章「パスワード・ポリシーの管理」

40.5.4 LDAPベースのレプリカの削除

この項ではLDAPベースのレプリカを削除する方法について説明します。この項の内容は、次のとおりです。

- タスク1: 削除するノードでのディレクトリ・レプリケーション・サーバーの停止

- タスク2: レプリケーション・グループからのレプリカの削除

注意:
別のレプリカのサプライヤになっているレプリカは、削除できません。このようなレプリカを削除するには、先にそのすべてのコンシューマをレプリケーション・グループから削除する必要があります。

40.5.4.1 タスク1: 削除するノードでのディレクトリ・レプリケーション・サーバーの停止

次のように入力し、Oracleディレクトリ・レプリケーション・サーバーを停止します。

oidctl connect=connStr server=oidrepld instance=1 componentname=oidComponentName \
flags="-h LdapHost -p LdapPort" stop

40.5.4.2 タスク2: レプリケーション・グループからのレプリカの削除

このタスクは、レプリケーション環境管理ツールを使用して行います。次のように入力します。

remtool -pdelnode [-v] [-bind hostname:port_number]

関連項目:
『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のremtoolコマンド行ツールのリファレンスを参照してください

replication_dn_passwordの入力を要求されます。

40.6 ファンアウトと組み合せたマルチマスター・レプリケーション・グループの設定

この項では、ファンアウトと組み合せたマルチマスター・レプリケーション・グループの設定に役立つ例を表40-3に示す4つのシステムを使用して示します。

表40-3 部分レプリケーション・デプロイメント例におけるノード

ノード

ホスト名

ポート

ノード1

mycompany1.com

3000

ノード2

mycompany2.com

4000

ノード3

mycompany3.com

5000

ノード4

mycompany4.com

6000

ノード5

mycompany5.com

7000

この例では、ユーザーが次の要件に従って設定を済ませています。

- 要件1: いずれかのノードに加えられた変更が他のノードにレプリケートされるように、ノード1とノード2とを同期させる必要がありますが、ネーミング・コンテキストcn=private users, cn=mycompanyは、このレプリケーションから除外されます。

- 要件2: ノード2のou=Americas, cn=mycompanyの下で行われた変更のみがノード3にレプリケートされるように、ノード3のネーミング・コンテキストou=Americas,cn=mycompanyは、ノード2から部分的に同期させます。このレプリケーションから除外される対象は、次のとおりです。

- cn=customer profile, ou=Americas, cn=mycompanyの下で行われた変更

- userpassword属性に加えられた変更

- 要件3: ノード4は、ノード2の完全レプリカとして構成します。つまり、ノード2のすべてのネーミング・コンテキストに対する変更がノード4にレプリケート(一方向)されます。

- 要件4: ノード5は、ノード1の双方向(更新可能)の完全なレプリカとして構成します。

図40-11 ファンアウト・レプリケーションの例

この例の最初の要件を満たすには、ノード1およびノード2のマルチマスター・レプリケーション・グループを設定します。2番目を満たすには、ノード2およびノード3に対して部分レプリカを設定し、3番目を満たすには、ノード2からノード4に対して完全なLDAPレプリケーションを行います。

この項の項目は次のとおりです。

- タスク1: ノード1およびノード2を対象としたマルチマスター・レプリケーション・グループの設定

- タスク2: レプリケーション承諾の構成

- タスク3: ノード1およびノード2でのレプリケーション・サーバーの起動

- タスク4: ノード1とノード2間のディレクトリ・レプリケーションのテスト

- タスク5: ノード3をノード2の部分レプリカとしてインストールし、構成

- タスク6: 部分レプリケーション承諾のカスタマイズ

- タスク7: DRGの全ノードでのレプリケーション・サーバーの起動

- タスク8: ノード4をノード2の完全なレプリカとしてインストールし、構成

- タスク9: ノード2からノード4へのレプリケーションのテスト

- タスク10: ノード5をノード1の双方向レプリカとしてインストールし、構成

- タスク11: ノード1とノード5間の双方向レプリケーションのテスト

タスク1: ノード1およびノード2を対象としたマルチマスター・レプリケーション・グループの設定

ノード1とノード2のLDAPベースのマルチマスター・レプリケーション・グループを設定するには、第40.5.2項「カスタム設定を使用したLDAPベースのレプリカの設定」の手順に従います。

マルチマスター・レプリケーション・グループにアドバンスト・レプリケーション・ベースのレプリケーションを使用する場合は、第C.2.2項「アドバンスト・レプリケーション・ベースのマルチマスター・レプリケーション・グループの設定」のタスク1から5に従います。

タスク2: レプリケーション承諾の構成

ノード1とノード2間のレプリケーション承諾では、orclExcludedNamingcontexts属性の値を、cn=private users,cn=mycompanyとして指定します。この手順は、次のとおりです。

1. サンプル・ファイルmod.ldifを、次のように編集します。

dn: orclAgreementID=000001,cn=replication configuration
Changetype:modify
Replace: orclExcludedNamingcontexts
orclExcludedNamingcontexts: cn=private users,cn=mycompany

2. ldapmodifyを使用して、ノード1とノード2のレプリケーション承諾のorclExcludedNamingcontexts属性を更新します。これを行うには、次のように入力します。

ldapmodify -D "cn=orcladmin" -q -h mycompany1.com -p 3000 -f mod.ldif
ldapmodify -D "cn=orcladmin" -q -h mycompany2.com -p 4000 -f mod.ldif

タスク3: ノード1およびノード2でのレプリケーション・サーバーの起動

これを行うには、LDAPベースのレプリケーションを使用する場合、該当する指示に従います。

アドバンスト・レプリケーションを使用している場合は、付録C「Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーションの設定」の「タスク6: DRGの全ノードでのレプリケーション・サーバーの起動」の指示に従います。

タスク4: ノード1とノード2間のディレクトリ・レプリケーションのテスト

そのためには、第40.4項「Oracle Directory Services Managerを使用したレプリケーションのテスト」の指示に従います。

タスク5: ノード3をノード2の部分レプリカとしてインストールし、構成

部分レプリケーションのブートストラップ機能を使用する場合は、第40.5.2.1項「自動ブートストラップを使用したLDAPベースのレプリカの設定」のタスク1から5に従います。

ldifwriteツールを使用してレプリカを構成する場合は、第40.5.2.2項「ldifwriteツールを使用したLDAPベースのレプリカの設定」のタスク1から9に従います。

ノード2をサプライヤ、ノード3をコンシューマと指定します。

タスク6: 部分レプリケーション承諾のカスタマイズ

この手順は、次のとおりです。

- この例の要件2を満たすには、まずノード2とノード3の間にデフォルトのレプリケーションを構成する必要があります。
部分レプリケーションでは、デフォルトでネーミング・コンテキストcn=oraclecontextがレプリケートされます。このネーミング・コンテキストをサプライヤ(ノード2、mycompany2.com)とコンシューマ(ノード3、mycompany3.com)の両方で削除すれば、レプリケートされることはなくなります。

ldapdelete -D "cn=orcladmin" -q -h mycompany2.com \
-p 4000 "cn=includednamingcontext000001, \
cn=replication namecontext,orclagreementid=000002, \
orclreplicaid==node2_replica_id, \
cn=replication configuration"

ldapdelete -D "cn=orcladmin" -q -h mycompany3.com \
-p 5000 "cn=includednamingcontext000001, \
cn=replication namecontext,orclagreementid=000002, \
orclreplicaid==node2_replica_id, \
cn=replication configuration"

- ネーミング・コンテキストou=Americas,cn=mycompanyをレプリケートし、ネーミング・コンテキストcn=customer profile, ou=Americas, cn=mycompanyおよびuserpassword属性をレプリケーションから除外するには、ネーミング・コンテキスト・オブジェクトを次のように作成します。

1. サンプル・ファイルmod.ldifを、次のように編集します。

dn: cn=includednamingcontext000002,cn=replication namecontext,
orclagreementid=000002,orclreplicaid=node2_replica_id,
cn=replication configuration
orclincludednamingcontexts: ou=Americas,cn=mycompany
orclexcludednamingcontexts: cn=customer profile, ou=Americas, cn=mycompany
orclexcludedattributes: userpassword
objectclass: top
objectclass: orclreplnamectxconfig

2. ldapaddを使用して、部分レプリケーションのネーミング・コンテキスト・オブジェクトをノード2とノード3の両方に追加します。

ldapadd -D "cn=orcladmin" -q -h mycompany2.com -p 4000 -f mod.ldif
ldapadd -D "cn=orcladmin" -q -h mycompany3.com -p 5000 -f mod.ldif

- 部分レプリケーションの自動ブートストラップ機能を使用する場合は、サンプル・ファイルmod.ldifを編集し、次にldapmodifyを使用して、ノード2とノード3の両方で部分レプリカのorclreplicastate属性を変更します。詳細は、「タスク5: コンシューマ側でコンシューマ・レプリカを自動ブートストラップ用に構成」を参照してください。

タスク7: DRGの全ノードでのレプリケーション・サーバーの起動

このためには、各ノードでレプリケーション・サーバーを起動します。

次のように入力します。

oidctl connect=connStr server=oidrepld instance=1 \
componentname=oidComponentName flags="-h LdapHost -p LdapPort" start

タスク8: ノード4をノード2の完全なレプリカとしてインストールし、構成

完全レプリカ・レプリケーションがデフォルト構成であるため、新規ノードをLDAPレプリカとしてインストールする場合は、第40.5項「コマンド行を使用したLDAPベースのレプリケーションの設定」に記載されている指示に従います。インストーラからサプライヤ情報の入力を求められたときに、サプライヤ・ホスト名mycompany2.com、サプライヤ・ポート4000およびスーパーユーザー・パスワードを入力します。

タスク9: ノード2からノード4へのレプリケーションのテスト

示されている項の指示に従って、このレプリケーションをテストします。

アドバンスト・レプリケーションを使用している場合は、付録C「Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーションの設定」の「タスク7: ディレクトリ・レプリケーションのテスト」の指示に従います。

タスク10: ノード5をノード1の双方向レプリカとしてインストールし、構成

第40.3項「レプリケーション・ウィザードを使用したLDAPベースのレプリケーション承諾の設定」または第40.5項「コマンド行を使用したLDAPベースのレプリケーションの設定」に記載されている指示に従います。サプライヤ・ホスト名mycompany1.com、サプライヤ・ポート3000およびスーパーユーザー・パスワードを指定します。

タスク11: ノード1とノード5間の双方向レプリケーションのテスト

Oracle Enterprise Managerまたはldapaddコマンド行ツールを使用して、ノード1にエントリを作成します。エントリがノード5でレプリケートされるのを待機します。エントリがノード5にレプリケートされた後、ldapmodifyコマンド行ツールまたはOracle Enterprise Managerのいずれかを使用して、ノード5の該当するエントリに変更を適用します。この変更はノード1にレプリケートされます。

41 レプリケーション・フェイルオーバーの設定

この章では、Oracle Internet Directoryのフェイルオーバーについて説明し、ステートレス・レプリケーション・フェイルオーバーおよび時間ベース・レプリケーション・フェイルオーバーを実行する方法について説明します。

この章の内容は次のとおりです。

- 第41.1項「レプリケーション・フェイルオーバーの概要」

- 第41.2項「ステートレス・レプリケーション・フェイルオーバーの実行」

- 第41.3項「時間ベース・レプリケーション・フェイルオーバーの実行」

41.1 レプリケーション・フェイルオーバーの概要

10g(10.1.4.0.1)以降、Oracle Internet Directoryでは、1つのサプライヤからもう1つのサプライヤへのLDAPレプリケーションのフェイルオーバーをサポートしています。これには管理者操作が必要です。図41-1に、一般的なフェイルオーバーの使用例を示します。

図41-1 レプリケーション・フェイルオーバーの使用例

この使用例には、次の機能があります。

- Apple、BananaおよびCandyは、同じDRG内のマルチマスター・レプリカです。

- Damsonは、Bananaの読取り専用ファンアウト・レプリカです。つまり、一方向LDAPレプリケーションを使用した部分レプリカです。

- Eggplantは、Bananaの更新可能なファンアウト・レプリカです。つまり、双方向LDAPレプリケーションを使用した部分レプリカです。

- Bananaが停止すると、マルチマスターDRGとそのファンアウト・レプリカ間のレプリケーションは中断されます。
管理者は、EggplantとDamsonを新しいサプライヤのCandyに切り替えることができます。

フェイルオーバー・トポロジは2つのタイプのみがサポートされています。

- コンシューマと新規サプライヤは、どちらもLDAPベース・レプリケーションにより旧サプライヤに接続されます。これは、図41-2に示されています。ノード1とノード3はどちらも、ノード2とのLDAPレプリケーション承諾を持っています。ノード2は、ノード1の元のサプライヤです。ノード2が機能しなくなると、ノード1を新規のサプライヤ、ノード3にフェイルオーバーできます。

図41-2 LDAPにより旧サプライヤに接続されるコンシューマと新規サプライヤ

- コンシューマは、LDAPベース承諾により旧サプライヤに接続され、旧サプライヤは同じアドバンスト・レプリケーション・グループ内で新規のサプライヤとして機能します。これは、図41-3に示されています。ノード2とノード3は、同じアドバンスト・レプリケーションDRG内にあります。ノード2は、ノード4の元のサプライヤです。ノード4が機能しなくなると、ノード4を新規のサプライヤ、ノード3にフェイルオーバーできます。

図41-3 同じアドバンスト・レプリケーション・グループ内の新旧のサプライヤ

41.1.1 レプリケーション・フェイルオーバーに関する制限事項と警告

この項では、レプリケーション・フェイルオーバーの使用に関する制限事項と警告について説明します。

- Oracle Internet Directory 11g リリース1(11.1.1)では、レプリケーション・フェイルオーバーには、管理者の操作が必要です。

- フェイルオーバーの直後に、管理者はコンシューマと新規サプライヤを比較し、調整する必要があります。

- 新規の承諾は、旧承諾と同じタイプと方向のものであることが必要です。

- 2つのトポロジ・タイプのみがサポートされています。

- サプライヤが機能しなくなると、直接接続しているレプリカは、同様にそのサプライヤに接続している別のレプリカに対してのみフェイルオーバーができます。

- 新規サプライヤと旧サプライヤ間の承諾のレプリケーション・フィルタリング・ポリシーは、旧サプライヤとコンシューマ間の承諾と一致させる必要があります。

- ほとんどの場合、レプリカは元のレプリカ・タイプを維持する方法でフェイルオーバーする必要があります。図41-4に示した例では、ノード2は、ノード1とノート3の両方にとっての旧サプライヤであり、ノード1は読取り専用です。ノード2が機能しなくなった場合、理論上は、ノード1またはノード3のいずれかを新しいサプライヤ・ノードとして設定できます。しかし、ベスト・プラクティスは、ノード1をフェイルオーバーして、ノード3をサプライヤにすることです。この方法により、ノード1の元の読取り専用レプリカ・タイプが維持されます。

図41-4 レプリカ・タイプを維持するフェイルオーバー

- 新規の承諾が双方向承諾の場合、コンシューマをその新しいサプライヤと比較し、調整した後、新しいサプライヤと接続しているその他すべてのレプリカについても、新しいサプライヤと比較し、調整する必要があります。たとえば、図41-5では、ノード2にはノード3との双方向承諾があります。ノード3は、もう1つのレプリカ、ノード4に接続しています。ノード2が機能しなくなると、ノード3とノード1の双方向承諾を設定します。ノード3をノード1と比較、調整した後、ノード4もノード3と比較、調整し、レプリカを確実に同期化します。

図41-5 接続レプリカすべての比較および調整

41.1.2 使用するレプリケーション・フェイルオーバーのタイプの決定

レプリケーション・フェイルオーバーには2つのタイプがあります。次のタイプです。

- ステートレス

- 時間ベース

事前にフェイルオーバーを計画できない場合は、ステートレス・フェイルオーバーを使用します。ステートレス・レプリケーション・フェイルオーバーでは、レプリカの状態について想定は行いません。いつでも新しいサプライヤにフェイルオーバーできます。ステートレス・フェイルオーバーには、フェイルオーバー後、ノードを同期化するためにより多くの作業が必要です。

計画的なフェイルオーバーには、時間ベース・フェイルオーバーを使用します。時間ベース・フェイルオーバーは、フェイルオーバー後の作業が少なくなります。ただし、後続の想定がフェイルオーバー時に必ず当てはまるように、事前に時間を設定する必要があります。

- ノードは大部分は同期化されます。

- 新規のサプライヤは、完全な同期化がすぐに実行できるように、変更ログを保存しています。

41.2 ステートレス・レプリケーション・フェイルオーバーの実行

この項では、ステートレス・レプリケーション・フェイルオーバーの実行方法について説明します。次のタスクを説明します。

- タスク1: 関連ノードでのすべてのディレクトリ・レプリケーション・サーバーの停止

- タスク2: 旧レプリケーション承諾の破棄と新規承諾の設定

- タスク3: 最後に適用された変更番号の保存

- タスク4: 新規サプライヤとコンシューマの比較および調整

- タスク5: 新規承諾の最後に適用された変更番号の更新

- タスク6: 旧サプライヤでの旧承諾のクリーンアップ

- タスク7: 関連ノードでのすべてのディレクトリ・レプリケーション・サーバーの起動

41.2.1 タスク1: 関連ノードでのすべてのディレクトリ・レプリケーション・サーバーの停止

新規サプライヤ、旧サプライヤおよびコンシューマ上のOracleディレクトリ・レプリケーション・サーバーを、次のように入力することにより停止します。

oidctl connect=connStr server=oidrepld instance=1 componentname=oidComponentName \
flags="-h LdapHost -p LdapPort" stop

41.2.2 タスク2: 旧レプリケーション承諾の破棄と新規承諾の設定

旧サプライヤとコンシューマ間の古いレプリケーション承諾を破棄し、新規サプライヤとコンシューマ間の新規承諾を設定します。このタスクは、レプリケーション環境管理ツールを使用して行います。次のように入力します。

remtool -pchgmaster [-v] [-bind consumer_host::port_number]

replication_dn_passwordの入力を要求されます。

関連項目:
『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のremtoolコマンド行ツールのリファレンスを参照してください

41.2.3 タスク3: 最後に適用された変更番号の保存

新規サプライヤから最後に適用された変更番号を取得します。

一方向承諾の場合、次のコマンドを使用します。

ldapsearch -h new_supplier_host -p port_number -b "" \
-s base "objectclass=*" lastchangenumber

双方向承諾の場合、次のコマンドを使用します。

ldapsearch -h consumer_host -p port_number -b "" \
-s base "objectclass=*" lastchangenumber

この番号を保存します。

41.2.4 タスク4: 新規サプライヤとコンシューマの比較および調整

Oracle Internet Directory比較調整ツールを使用して、新規サプライヤとコンシューマを比較し、調整します。一方向承諾の場合は、次のように入力します。

oidcmprec operation=reconcile \
source=new_supplier_host:port \
destination=consumer_host:port \
base='""' scope=sub

双方向承諾の場合は、次のように入力します。

oidcmprec operation=merge \
source=new_supplier_host:port\
destination=consumer_host:port/ \
base='""' scope=sub

ソースと宛先のレプリケーション識別名のパスワードを要求されます。

この例では、ディレクトリ全体がレプリケートされることを想定しており、したがって、baseは" "に設定されています。部分レプリケーションを使用する場合は、base引数とdns2exclude引数をoidcmprecツールに使用して、希望するDITを含めます。

関連項目:
『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のoidcmprecコマンド行ツールのリファレンス

41.2.5 タスク5: 新規承諾の最後に適用された変更番号の更新

新規サプライヤ側で、検索の結果見つかった最後に適用された変更番号を使用して、新規の承諾を変更します。この手順は、次のとおりです。

1. 「タスク3: 最後に適用された変更番号の保存」で取得した最後の変更番号により、LDIFファイルを作成します。
一方向承諾の場合、次のようになります。

dn: agreement_dn
changetype: modify
replace: orclLastAppliedChangeNumber;apply$new_supplier_host$consumer_host
orclLastAppliedChangeNumber;apply$new_supplier_host$consumer_host:
last_change_number_retrieved.
-
replace: orclLastAppliedChangeNumber;transport$new_supplier_host$consumer_host
orclLastAppliedChangeNumber;transport$new_supplier_host$consumer_host:
last_change_number_retrieved_from_new_supplier

双方向承諾の場合、次のようになります。

dn: agreement_dn
changetype: modify
replace: orclLastAppliedChangeNumber;apply$new_supplier_host$consumer_host
orclLastAppliedChangeNumber;apply$new_supplier_host$consumer_host:
last_change_number_retrieved_from_new_supplier
-
replace: orclLastAppliedChangeNumber;transport$new_supplier$consumer
orclLastAppliedChangeNumber;transport$new_supplier$consumer:
last_change_number_retrieved_from_new_supplier
-
replace: orclLastAppliedChangeNumber;apply$consumer_host$new_supplier_host
orclLastAppliedChangeNumber;apply$consumer_host$new_supplier_host:
last_change_number_retrieved_from_consumer
-
replace: orclLastAppliedChangeNumber;transport$consumer_host$new_supplier_host
orclLastAppliedChangeNumber;transport$consumer_host$new_supplier_host:
last_change_number_retrieved_from_consumer

2. ldapmodifyを使用して承諾を変更する方法は次のとおりです。

ldapmodify -D "cn=orcladmin" -q -h host_name -p port_number -f LDIF_file

41.2.6 タスク6: 旧サプライヤでの旧承諾のクリーンアップ

「タスク2: 旧レプリケーション承諾の破棄と新規承諾の設定」の実行時に旧サプライヤが停止した場合、旧サプライヤ上の旧承諾はクリーンアップされません。ここで、レプリケーション環境管理ツールを使用して、これをクリーンアップします。次のように入力します。

remtool -pcleanup -agrmt [-v] [-bind consumer_host::port_number]

replication_dn_passwordの入力を要求されます。

関連項目:
『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のremtoolコマンド行ツールのリファレンスを参照してください

41.2.7 タスク7: 関連ノードでのすべてのディレクトリ・レプリケーション・サーバーの起動

新規サプライヤ、旧サプライヤおよびコンシューマ上のOracleディレクトリ・レプリケーション・サーバーを、次のように入力することにより起動します。

oidctl connect=connStr server=oidrepld instance=1 \
name=instance_name componentname=component_name \
flags="-h LdapHost -p LdapPort" start

関連項目:
第4章「Oracle Internet Directoryコンポーネントのプロセス制御の理解」

41.3 時間ベース・レプリケーション・フェイルオーバーの実行

この項では、時間ベース・レプリケーション・フェイルオーバーの実行方法について説明します。この項の内容は、次のとおりです。

- タスク1: 新規サプライヤでの変更ログ・ガベージ・コレクション・オブジェクトの構成

- タスク2: 新規サプライヤの最後に適用された変更番号の保存

- タスク3: 新規サプライヤでの変更ログ再生成の有効化

- タスク4: 希望する期間が経過するのを待機

- タスク5: 関連ノードでのすべてのディレクトリ・レプリケーション・サーバーの停止

- タスク6: 旧レプリケーション承諾の破棄と新規承諾の設定

- タスク7: 新規承諾の最後に適用された変更番号の更新

- タスク8: 旧サプライヤでの旧承諾のクリーンアップ

- タスク9: 関連ノードでのすべてのディレクトリ・レプリケーション・サーバーの起動

41.3.1 タスク1: 新規サプライヤでの変更ログ・ガベージ・コレクション・オブジェクトの構成

新規サプライヤ上で、希望する期間(たとえば、24時間)の変更ログを保存するように変更ログ・パージ構成エントリを構成する手順は、次のとおりです。

1. 次のようなLDIFファイルを作成します。

dn: cn=changelog purgeconfig,cn=purgeconfig,cn=subconfigsubentry
changetype:modify
replace: orclpurgetargetage
orclpurgetargetage: 24

2. LDIFファイルを適用するために、次のように入力します。

ldapmodify -D "cn=orcladmin" -q -p port -h host -f LDIF_file

関連項目:
第36章「ガベージ・コレクションの管理」

41.3.2 タスク2: 新規サプライヤの最後に適用された変更番号の保存

新規サプライヤから最後に適用された変更番号を、次のように取得します。

ldapsearch -h new_supplier_host -p port_number -D cn=orcladmin -q \
-b "" -s base "objectclass=*" lastchangenumber

この番号を保存します。

41.3.3 タスク3: 新規サプライヤでの変更ログ再生成の有効化

新規サプライヤで変更ログ再生成を、次のようにして有効化します。

1. 次のようなLDIFファイルを作成します。

dn:
changetype: modify
replace: orcldiprepository
orcldiprepository: TRUE

2. LDIFファイルを適用するために、次のように入力します。

ldapmodify -D "cn=orcladmin" -q -h host_name -p port_number -f LDIF_file

41.3.4 タスク4: 希望する期間が経過するのを待機

変更ログ・パージ構成エントリのorclpurgetargetageの値未満の期間を待機します。

41.3.5 タスク5: 関連ノードでのすべてのディレクトリ・レプリケーション・サーバーの停止

新規サプライヤ、旧サプライヤおよびコンシューマ上のOracleディレクトリ・レプリケーション・サーバーを、次のように入力することにより停止します。

oidctl connect=connStr server=oidrepld instance=1 \
componentname=oidComponentName \
flags="-h LdapHost -p LdapPort" stop

関連項目:
第4章「Oracle Internet Directoryコンポーネントのプロセス制御の理解」

41.3.6 タスク6: 旧レプリケーション承諾の破棄と新規承諾の設定

旧サプライヤとコンシューマ間の古いレプリケーション承諾を破棄し、新規サプライヤとコンシューマ間の新規承諾を設定します。このタスクは、レプリケーション環境管理ツールを次のように使用して行います。

remtool -pchgmaster [-v] [-bind hostname:port_number]

replication_dn_passwordの入力を要求されます。

関連項目:
『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のremtoolコマンド行ツールのリファレンスを参照してください

41.3.7 タスク7: 新規承諾の最後に適用された変更番号の更新

新規サプライヤで、最後に適用された変更番号が、「タスク2: 新規サプライヤの最後に適用された変更番号の保存」で取得した値になるように、次のように新規承諾を変更します。

1. 取得した最後に適用された変更番号を使用して、次のようなLDIFファイルを作成します。

dn: agreement_dn
changetype: modify
replace: orclLastAppliedChangeNumber
orclLastAppliedChangeNumber: last_change_number_retrieved

2. ldapmodifyを使用して、LDIFファイルを承諾に適用します。

ldapmodify -D "cn=orcladmin" -q -h host_name -p port_number -f LDIF_file

41.3.8 タスク8: 旧サプライヤでの旧承諾のクリーンアップ

「タスク6: 旧レプリケーション承諾の破棄と新規承諾の設定」の実行時に旧サプライヤが停止した場合、旧サプライヤ上の旧承諾はクリーンアップされません。ここで、レプリケーション環境管理ツールを使用して、これをクリーンアップします。次のように入力します。

remtool -pcleanup -agrmt [-v] [-bind hostname:port_number]

replication_dn_passwordの入力を要求されます。

関連項目:
『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のremtoolコマンド行ツールのリファレンスを参照してください

41.3.9 タスク9: 関連ノードでのすべてのディレクトリ・レプリケーション・サーバーの起動

新規サプライヤ、旧サプライヤおよびコンシューマ上のOracleディレクトリ・レプリケーション・サーバーを、次のように入力することにより起動します。

oidctl connect=connStr server=oidrepld instance=1  \
componentname=oidComponentName \
flags="-h LdapHost -p LdapPort" start

関連項目:

- 第4章「Oracle Internet Directoryコンポーネントのプロセス制御の理解」

- 『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のoidctlコマンド行ツールのリファレンス

42 レプリケーション構成属性の管理

この章では、Oracle Internet Directoryレプリケーション・サーバーを制御する構成属性について説明し、Oracle Enterprise Manager Fusion Middleware ControlおよびLDAPコマンド行ユーティリティを使用してそれらの属性を管理する方法について説明します。

この章の内容は次のとおりです。

- 第42.1項「レプリケーション構成属性の概要」

- 第42.2項「Fusion Middleware Controlを使用したレプリケーション構成属性の構成」

- 第42.3項「コマンド行からのレプリケーション構成属性の管理」

具体的なレプリケーション管理タスクは、第43章「レプリケーションの管理およびモニタリング」を参照してください。

42.1 レプリケーション構成属性の概要

構成属性は、DIT内の特定のコンテナに格納されます。この概要の項目は次のとおりです。

- 第42.1.1項「レプリケーション構成コンテナ」

- 第42.1.2項「レプリカ・サブエントリ」

- 第42.1.3項「レプリケーション承諾エントリ」

- 第42.1.4項「レプリケーションのネーミング・コンテキスト・コンテナ・エントリ」

- 第42.1.5項「レプリケーションのネーミング・コンテキスト・オブジェクト・エントリ」

- 第42.1.6項「レプリケーション構成セット」

- 第42.1.7項「ディレクトリ内のレプリケーション構成オブジェクトの例」

42.1.1 レプリケーション構成コンテナ

ノードに関するすべてのレプリケーション情報は、ルートDSEにあるコンテナcn=replication configuration内に存在します。このエントリは、DRG内の各ノードに存在します。次に、レプリケーション構成コンテナ・エントリの例を示します。

dn: cn=replication configuration
orclaci: access to entry by * (browse)
orclaci: access to attr=(*) by * (search,read)
orclnormdn: cn=replication configuration
cn: replication configuration
description: Replication agreement Container object
objectclass: top
objectclass: orclcontainerOC

42.1.2 レプリカ・サブエントリ

レプリカ・サブエントリには、次の識別名があります

orclreplicaid=Replica_ID,cn=replication configuration

このサブエントリは、インストール時にレプリケーション構成コンテナの下に作成されます。これには、表すノードの特性を識別し、定義する属性が含まれます。

表42-1に、レプリカ・サブエントリの属性を示します。更新メカニズムの列のEMは、Oracle Enterprise Manager Fusion Middleware Controlを使用してこの属性を管理できることを示します。LDAPは、LDAPツールを使用してこの属性を管理できることを示します。

表42-1 レプリカ・サブエントリの属性

属性

説明

更新メカニズム

デフォルト

使用可能な値

orclreplicaid

ディレクトリ・データベースの一意の識別子。インストール時に初期化されます。ルートDSEのorclreplicaidと一致します。

読取り専用

hostname_ORACLESID

整数

orclreplicauri

このレプリカに接続する際に使用されるアドレス。

EM、LDAP

有効なldapURI書式

orclreplicasecondaryuri

orclReplicaURIを使用できない場合に使用されるアドレス。

EM、LDAP

有効なldapURI書式

orclreplicatype

読取り専用、読取り/書込みなどのレプリカのタイプを定義します。

EM、LDAP

0(読取り/書込み)

0: 読取り/書込み

1: 読取り専用

2: パイロット

orclpilotmode

レプリカをパイロット(テスト)・モードにするかどうかを定義します。

remtool -pilotreplica

0

0: FALSE

1: TRUE

orclreplicastate

レプリカの状態を定義します。

EM、LDAP

0、1、2、6または8を設定できます。サーバーは他の値を設定します。表D-1を参照してください。

pilotstarttime

レプリカがパイロット(テスト)・モードに切り替わった時刻。

読取り専用

時間

注意:
WindowsシステムではorclReplicaStateの値を0に変更してブートストラップを有効にする前に、レプリケーション・サーバーが稼働していないことを確認します。

図42-3では、レプリカ・サブエントリはorclReplicaID=UID_of_node_D,cn=replication configurationで表されています。

次に、レプリカ・サブエントリの例を示します。

dn: orclreplicaid=myhost1_repl1,cn=replication configuration
objectclass: top
objectclass: orclreplicasubentry
orclreplicaid: myhost1_repl1
orclreplicauri: ldap://myhost1:3060/
orclreplicasecondaryuri: ldap://myhost1.mycompany.com:3060/
orclreplicastate: 1

関連項目:
レプリカ・サブエントリの属性の詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のレプリケーション・スキーマ要素に関する説明を参照してください。

42.1.3 レプリケーション承諾エントリ

レプリケーション承諾エントリの識別名は、次のとおりです。

orclagreementid=Agreement_ID,orclreplicaid=Replica_ID,cn=replication configuration

このエントリには、複数のノード間のレプリケーション承諾を定義する属性が含まれており、orclReplAgreementEntryオブジェクト・クラスに関連付けられます。承諾には次の2つの種類があります。

1. Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーション承諾。アドバンスト・レプリケーション・ノードのレプリケーション承諾は、レプリケーション構成セットの下に存在します。たとえば、図42-2では、Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーション承諾のエントリがorclagreementID=000001,cn=replication configurationで表されています。

2. LDAPベースのレプリケーション承諾。LDAPノードのレプリケーション承諾は、サプライヤのレプリカ・サブエントリの下に存在します。たとえば図42-3では、LDAPベースのレプリケーション承諾のエントリがorclagreementID=000003, orclReplicaID=UID_of_node_D,cn=replication configurationで表されています。

42.1.3.1 レプリケーション承諾エントリの属性

表42-2に、レプリケーション承諾の属性を示します。更新メカニズムの列のEMは、Oracle Enterprise Manager Fusion Middleware Controlを使用してこの属性を管理できることを示します。LDAPは、LDAPツールを使用してこの属性を管理できることを示します。

表42-2 レプリケーション承諾エントリの属性

属性

説明

更新メカニズム

デフォルト

使用可能な値

orclagreementid

レプリケーション承諾エントリの名前。

読取り専用

orclreplicadn

LDAPベースのレプリケーションのみ。レプリケーション承諾においてコンシューマを識別するためのレプリカの識別名。

読取り専用

DN

orclentryexclusionfilter

LDAPベースの一方向レプリケーションのみ。レプリケートしないエントリを指定するLDAPフィルタ文字列。

Oracle Internet Directory 11gリリース1 (11.1.1.9.0)以上に適用されます。

「orclEntryExclusionFilter属性を使用したレプリケーション・フィルタリングの構成」を参照してください。

LDAP

カッコで囲まれたLDAPフィルタ文字列。サポートされる最大長は、1500文字です。

例: (sn=smith)

orclreplicationprotocol

レプリカへの変更伝播用のレプリケーション・プロトコル。指定可能な値は次のとおりです。

読取り専用

ODS_ASR_1.0: Oracle Databaseアドバンスト・レプリケーション・ベース

ODS_LDAP_1.0: LDAPベース

orcldirreplgroupdsas

Oracle Databaseアドバンスト・レプリケーション・ベースのグループのみ。このレプリケーション・グループのすべてのノードのOrclreplicaid値。このリストは、グループのすべてのノードで同一であることが必要です。この属性は変更可能です。

LDAP

orclupdateschedule

新規の変更および再試行される変更の更新間隔。

EM、LDAP

60(秒)

0以上

orclhiqschedule

ディレクトリ・レプリケーション・サーバーが変更適用プロセスを繰り返す間隔。

EM、LDAP

600(秒)

60(秒)以上

orclldapconnkeepalive

レプリケーション・サーバーをディレクトリ・サーバーに常時接続するか、変更ログ処理が行われるたびに接続するかの指定。

EM、LDAP

1

0: FALSE

1: TRUE

orcllastappliedchangenumber

コンシューマ・レプリカで転送または適用された最後の変更番号。LDAPベースの承諾の場合、この属性にはサブタイプが含まれます。書式は次のとおりです。

orcllastappliedchangenumber; status_type$supplier_replicaID$consumer_replicaID: Number

ここでstatus_typeはtransportまたはapplyであり、supplier_replicaIDおよびconsumer_replicaIDはLDAPのデータ・フローの方向を示し、Numberは最後に適用された変更番号です。

これは、Numberより小さい変更番号を持つsupplier_replicaIDからconsumer_replicaIDへの変更ログは、consumer_replicaIDで転送または適用されたことを示します。

Oracle Databaseアドバンスト・レプリケーション・ベースの承諾の場合、ベース型のみ使用されます。

読取り専用

orclexcludednamingcontexts

レプリケーションから除外される変更。

Oracle Databaseアドバンスト・レプリケーション・ベースの承諾にのみ適用されます。LDAPレプリケーションは、レプリケーション・ネーミング・コンテキスト・エントリ(表42-3を参照)を使用します。

読取り専用

orclreplicationid

一方向、双方向またはpeer-to-peerレプリケーション・グループの一意の識別子

読取り専用

orclagreementtype

レプリケーション承諾のタイプ。

読取り専用

0: 一方向/読取り専用ファンアウト・レプリケーション承諾

1: 双方向/更新可能ファンアウト・レプリケーション承諾

2: LDAPベースのマルチマスター・レプリケーション承諾

3: Oracle Databaseアドバンスト・レプリケーション・ベースのマルチマスター・レプリケーション承諾

42.1.3.2 Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーション承諾

アドバンスト・レプリケーションの場合は、各ノードのレプリケーション承諾にグループ内のすべてのノードがリストされます。これは、ローカル・ディレクトリ・サーバーのパーティション化されたネーミング・コンテキストなどのローカル・オプションを除き、各ノードで同じです。

このタイプのレプリケーション承諾のエントリは、コンテナ・エントリcn=replication configurationの直下に存在します。たとえば、このような承諾のDNは、orclagreementID=000001,cn=replication configurationのようになります。

42.1.3.3 LDAPレプリケーション承諾

LDAPベースのレプリケーションの場合、サプライヤとコンシューマの関係ごとに、別々のレプリケーション承諾があります。一方向レプリケーションの場合、単一の一方向レプリケーション承諾があります。

LDAPベースのレプリケーション承諾のエントリは、サプライヤとして機能するノードのレプリカ・サブエントリの直下にあります。したがって、サプライヤ・ノードに対するレプリケーション承諾は、次のようになります。

orclagreementID=unique_identifier_of_the_replication_agreement, orclReplicaID=unique_identifier_of_supplier_node, cn=replication configuration

同様に、コンシューマ・ノードに対するレプリケーション承諾は、次のようになります。

orclagreementID=unique_identifier_of_the_replication_agreement, orclReplicaID=unique_identifier_of_supplier_node, cn=replication configuration

ファンアウト・レプリケーション承諾の場合、親ノードを調べることで、承諾エントリと関連付けられているノードを識別できます。次に、レプリケーション承諾エントリの例を示します。

orclagreementID=000002,orclReplicaID=node_A,cn=replication configuration

この例では、orclagreementID=000002で表されたレプリケーション承諾がノードAと関連付けられていることを確認できます。これは、orclagreementID=000002の親がorclReplicaID=node_Aであるためです。

注意:

- コンテナ・エントリcn=replication configurationは、すべてのノードでレプリケートされますが、すべてのノードで同一ではない場合があります。

- LDAPベースのレプリケーション承諾のorclreplicadn属性は、関連付けられるコンシューマ・ノードを指定します。

- agreementtypeは、レプリケーション承諾のタイプを表します。orclagreementtypeの値については、表42-2「レプリケーション承諾エントリの属性」を参照してください。

42.1.3.4 双方向LDAPレプリケーション承諾

双方向レプリケーションの場合、サプライヤとコンシューマの関係ごとに、単一の双方向レプリケーション承諾か2つの一方向承諾のいずれかになります。次に、双方向レプリケーション承諾エントリの例を示します。

dn: orclagreementid=000002, orclreplicaid=stadd58_repl, cn=replication configuration
orclagreementid: 000002
orclreplicationprotocol: ODS_LDAP_1.0
orclreplicadn: orclreplicaid=stadd57_repl,cn=replication configuration
orclldapconnkeepalive: 1
orclagreementtype: 1
orclreplicationid: 000002
orcllastappliedchangenumber;transport$stadd57$stadd58: 106
orcllastappliedchangenumber;transport$stadd58$stadd57: 2421
orcllastappliedchangenumber;apply$stadd57$stadd58: 106
orcllastappliedchangenumber;apply$stadd58$stadd57: 2421
orclupdateschedule: 0
orclhiqschedule: 60
objectclass: orclReplAgreementEntry
objectclass: top

注意:
これは双方向レプリケーション承諾であるため、orclagreementtypeの値は1となります。他のレプリケーション承諾タイプのorclagreementtypeの値は、表42-2「レプリケーション承諾エントリの属性」を参照してください。

関連項目:
レプリケーション承諾エントリの属性の詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のレプリケーション・スキーマ要素に関する説明を参照してください。

42.1.4 レプリケーションのネーミング・コンテキスト・コンテナ・エントリ

このエントリには、LDAPネーミング・コンテキストのすべてのオブジェクトが含まれています。

このエントリは相対識別名cn=replication namecontextを持ち、レプリケーション構成時にorclagreementIDエントリの下に作成されます。次に、レプリケーションのネーミング・コンテキスト・コンテナ・エントリの例を示します。

dn: cn=replication namecontext,orclagreementid=000002,
orclreplicaid=myhost1_repl1,cn=replication configuration
objectclass: top
objectclass: orclcontainerOC
cn: replication namecontext

42.1.5 レプリケーションのネーミング・コンテキスト・オブジェクト・エントリ

このエントリには、LDAPネーミング・コンテキストのすべてのオブジェクトが含まれています。これらのオブジェクトは、レプリケーション・フィルタ・ポリシー、つまりLDAPベースの部分レプリカに対するレプリケーションに何を含めるか、あるいはレプリケーションから何を除外するかを指定します。

注意:
Oracle Databaseアドバンスト・レプリケーション・ベースの承諾では、ネーミング・コンテキストを含めたり、属性を除外したりできません。アドバンスト・レプリケーション承諾では、表42-2で説明されているベース属性のorclexcludednamingcontextsを使用します。

このエントリは、レプリケーション構成時にネーミング・コンテキスト・コンテナ・エントリの下に作成されます。これは構成可能です。たとえば、図42-3では、レプリケーションのネーミング・コンテキスト・オブジェクトは、cn=includednamingcontext000001,cn=replication namecontext,orclagreementID=000003,orclReplicaID=UID_of_node_D,cn=replication configurationです。

表42-3に、レプリケーション・ネーミング・コンテキスト・エントリの属性を示します。Oracle Enterprise Manager Fusion Middleware Controlのレプリケーション・ウィザードを使用してレプリケーションを設定する場合は、各属性を「有効範囲」ページで設定します。

表42-3 レプリケーション・ネーミング・コンテキスト・エントリの属性

属性

説明

orclincludednamingcontexts

レプリケートされるネーミング・コンテキストのルート。orclincludednamingcontextsが"*"に設定されている場合、すべてのネーミング・コンテキストがレプリケートされます。この属性には、ネーミング・コンテキストを含めるレプリケーションの方向を指定するサブタイプがあります。書式は次のとおりです。

orclincludednamingcontexts ; supplier_replicaID$consumer_replicaiD: DN

この属性は単一の値です。ネーミング・コンテキスト・オブジェクトごとに、各方向に1つの一意のサブツリーのみを指定できます。

部分レプリケーションでは、orclexcluednamingcontexts属性に指定されたサブツリーを除き、ネーミング・コンテキストに含まれているサブツリーはすべてレプリケートされます。

この属性は変更可能です。

orclexcludednamingcontexts

含まれているネーミング・コンテキスト内に配置されている、レプリケーションから除外されるサブツリーのルート。この属性には、ネーミング・コンテキストを除外するレプリケーションの方向を指定するサブタイプがあります。書式は次のとおりです。

orclexcludednamingcontexts; supplier_replicaID$consumer_replicaiD : DN

この属性は複数値です。orclincludednamingcontexts属性で指定したネーミング・コンテキスト内から、各方向で部分レプリケーションから除外する1つ以上のサブツリーを指定できます。

この属性は変更可能です。

orclexcludedattributes

含まれているネーミング・コンテキスト内にある、レプリケーションから除外する属性。orclexcludedattributesには、指定した属性を除外するレプリケーションの方向を指定するサブタイプがあります。書式は次のとおりです。

orclexcludedattributes; supplier_replicaID$consumer_replicaiD: attribute_name

この属性は複数値です。

この属性は変更可能です。

次に、レプリケーションのネーミング・コンテキスト・オブジェクト・エントリの例を示します。

dn:cn=namectx001,
cn=replication namecontext,
orclagreementid=unique_identifier_of_the_replication_agreement,
orclreplicaid=replica_id_of_node_A,
cn=replication configuration
orclincludednamingcontexts: cn=mycompany
orclexcludednamingcontexts; replica_id_of_node_A$ replica_id_of_node_B : c=us,cn=mycompany
orclexcludedattributes; replica_id_of_node_B$ replica_id_of_node_A : userPassword

この例では、次のレプリケーション・フィルタを指定しています。

- ネーミング・コンテキストcn=mycompanyは、ノードAとノードBの双方向のレプリケーションに含まれます。

- ネーミング・コンテキストc=us,cn=mycompanyは、ノードAからノードBへのレプリケーションでのみ除外されます。

- userPassword属性は、ノードBからノードAへのレプリケーションで除外されます。

関連項目:

- 第40.1.9.4項「LDAPレプリケーションのフィルタリングの例」

- 『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のレプリケーション・スキーマ要素に関する説明

42.1.6 レプリケーション構成セット

レプリケーション構成セットには、次の識別名があります。

cn=configset0,cn=osdrepld,cn=subconfigsubentry

表42-4に、次の識別名を持つレプリケーション構成セットの属性とその説明を示します。

cn=configset0,cn=osdrepld,cn=subconfigsubentry

属性orcldebuglevelを除き、この識別名で加えた属性の変更内容を反映させるには、レプリケーション・サーバーを再起動する必要があります。更新メカニズムの列のEMは、Oracle Enterprise Manager Fusion Middleware Controlを使用してこの属性を管理できることを示します。LDAPは、LDAPツールを使用してこの属性を管理できることを示します。

表42-4 レプリケーション構成セットの属性

属性

説明

更新メカニズム

デフォルト

使用可能な値

modifyTimestamp

エントリの作成または変更の日時。

読取り専用

modifiersName

エントリの作成者または変更者の名前

読取り専用

orclChangeRetryCount

管理者操作キューに移動される前に、変更エントリに対して行われる処理再試行回数。

EM、LDAP

10

1以上。

orclThreadsPerSupplier;transport

変更ログを転送するために、各サプライヤで生成されたワーカー・スレッド数。

EM、LDAP

1

1-100

orclThreadsPerSupplier;apply

変更ログを適用するために、各サプライヤで生成されたワーカー・スレッド数。

EM、LDAP

5

1-100

orclreplautotune

transportタスクとapplyタスクに割り当てられたスレッドの数が、ロードに応じて動的に変化します。サーバーを自動調整するように設定した場合は、これらのタスク間で共有するスレッドの最大数を指定する必要があります。変更した後、サーバーを再起動します。

EM、LDAP

1

0: 無効

1: 有効

orclreplmaxworkers

ワーカー・スレッドの最大数。orclreplautotuneが設定されている場合は必須です。

EM、LDAP

20

1-100

orclsdumpflag

スタック・ダンプを生成します。

(変更後、再起動します。)

EM、LDAP

0

0: FALSE

1: TRUE

orclmaxlogfilesize

最大ログ・ファイル・サイズ(MB)

EM、LDAP

1MB

1以上

orclmaxlogfiles

ローテーション状態を保つログ・ファイルの最大数

EM、LDAP

100

1以上

orclsizelimit

レプリケーション・サイクル当たりで処理する最大項目数

EM、LDAP

1000

1-10000

orclconflresolution

レプリケーション競合の自動解消

EM、LDAP

1

0: FALSE

1: TRUE

orclreplusesasl;digest-md5

レプリケーション・バインド用SASLを使用します。

EM、LDAP

デフォルトでは属性が存在しません。

auth、auth-int、auth-conf

orclActivateReplication

orclOidInstanceNameおよびorclOidComponentNameにより指定されるレプリケーション・サーバーでレプリケーションをアクティブにすることを指定します。

EM、LDAP

0

0: FALSE

1: TRUE

orclReplicationState

レプリケーション・サーバーのアクティブ化の状態

EM、LDAPを使用し、読取り専用

0

0または存在しない: 非稼働(False)

1: 稼働中

orcldebuglevel

レプリケーション・サーバーのデバッグのレベル

EM、LDAP

0

値は加算方式です。

0: デバッグ・ログなし

2097152: レプリケーション・パフォーマンス・ログ

4194304: レプリケーション・デバッグ・ログ

8388608: ファンクション・コール・トレース

16777216: 大容量トレース・ログ

orclOidComponentName

レプリケーションがアクティブであるかアクティブ化されるOIDコンポーネントの名前

読取り専用

レプリケーションの設定中に設定

文字列

orclOidInstanceName

レプリケーションがアクティブであるかアクティブ化されるインスタンスのインスタンス番号

読取り専用

レプリケーションの設定中に設定

整数

orclReplAttrConflict

属性レベルの競合の解消時に最初にタイムスタンプまたは属性バージョンのいずれを適用する必要があるかを指定します。

EM、LDAP

0

0: 最初にタイムスタンプ。

1: 最初にバージョン番号

42.1.7 ディレクトリ内のレプリケーション構成オブジェクトの例

この項で説明するレプリケーション・オブジェクトの例は、図42-1に示すレプリケーション環境に依存します。

図42-1 例: マルチマスター・レプリケーションおよびファンアウト・レプリケーション

図42-1では、ノードA、B、Cがマルチマスター・レプリケーション・グループを形成しています。ノードCは、4番目のノードDに対してレプリケーションを行い、ノードDはノードEにファンアウトします。

この環境のレプリケーション承諾は、次のとおりです。

- ノードAには、ノードBおよびCとのマルチマスター関係を表す1つのレプリケーション承諾があります。

- ノードBには2つのレプリケーション承諾があり、最初の承諾はノードAおよびCとのマルチマスター関係を表し、2番目の承諾はノードFとの関係を表します。BとFの間のレプリケーション承諾は双方向です。

- ノードCには2つのレプリケーション承諾があり、最初の承諾はノードAおよびBとのマルチマスター関係を表し、2番目の承諾はノードDとの関係を表します。これは、Cがサプライヤとして機能し、ノードDがコンシューマとなる一方向レプリケーション承諾です。

- ノードDには、2つのレプリケーション承諾があります。どちらのレプリケーション承諾も一方向です。1つは、ノードDが変更情報を消費するサプライヤ・ノードCとの関係を表し、もう1つは、ノードDがサプライヤとなるコンシューマ・ノードEとの関係を表しています。

- ノードEには、ノードDとの一方向レプリケーション承諾が1つあります。ノードEはコンシューマです。

- ノードFには、2つのレプリケーション承諾があります。1つは、ノードBとの関係を表し、もう1つは、ノードBとの関係を表しています。どちらも両方向レプリケーション承諾です。

- ノードEには、ノードDとの一方向レプリケーション承諾が1つあります。ノードEはコンシューマです。

図42-2に、図42-1で説明したノードCに関連するDIT内のレプリケーション・オブジェクトを示します。

図42-2 例: ノードCについてのレプリケーション構成エントリ

ノードCの場合、ルートDSEにあるエントリcn=replication configurationには、次のRDNが含まれています。

- orclagreementID=000001: ノードCをノードAおよびノードBに関連付けるマルチマスター・レプリケーション承諾。

- orclReplicaID=UID_of_node_C: ノードCの一意識別子。ノードCに関する情報が含まれています。

- orclagreementID=000002: サプライヤ・ノードCとコンシューマ・ノードD間の関係を表す一意の識別子。この場合、ノードCが親になっているため、orclagreementID=000002がサプライヤ・ノードCのレプリケーション承諾です。
このエントリには、orclreplicaDN属性が含まれています。この属性の値は、レプリケーション承諾がノードCに含まれているコンシューマ・ノードDのレプリカ・エントリDNです。

- cn=replication DN: ノードC上のディレクトリ・レプリケーション・サーバーが、ディレクトリ・サーバーにバインドするときに使用するバインド識別名。

- cn=replication namecontext: レプリケーションに含まれるネーミング・コンテキストに関する情報のコンテナ。

- cn=includednamingcontext000001およびcn=namingcontext002: レプリケーションに含まれているか、またはレプリケーションから除外されている実際のオブジェクト。レプリケーションに含まれるネーミング・コンテキストには、レプリケーションから除外する1つ以上のサブツリーを指定できます。また、レプリケーションから除外する属性も指定できます。

図42-3に、図42-1で説明したノードDに関連するDIT内のレプリケーション承諾エントリを示します。

図42-3 例: ノードDについてのレプリケーション構成エントリ

ノードDの場合、ルートDSEにあるエントリcn=replication configurationには、次のRDNが入っています。

- orclReplicaID=UID_of_node_D: ノードDの一意識別子。ノードDに関する情報が含まれています。

- orclagreementID=000003: サプライヤ・ノードDとコンシューマ・ノードE間の関係を表す一意の識別子。この場合、ノードDが親になっているため、orclagreementID=000003がサプライヤ・ノードDのレプリケーション承諾です。
このエントリには、orclreplicaDN属性が含まれています。この属性の値は、レプリケーション承諾がノードDに含まれているコンシューマ・ノードEのDNです。

- cn=replication DN: ノードD上のディレクトリ・レプリケーション・サーバーが、ディレクトリ・サーバーにバインドするときに使用するバインド識別名。

- cn=replication namecontext: レプリケーションに含まれるネーミング・コンテキストに関する情報のコンテナ。

- cn=namingcontext001およびcn=namingcontext002レプリケーションに含まれるネーミング・コンテキストを指定するオブジェクト。レプリケーションに含まれるネーミング・コンテキストには、レプリケーションから除外する1つ以上のサブツリーまたは特定の属性を指定できます。

42.2 Fusion Middleware Controlを使用したレプリケーション構成属性の構成

この項では、Oracle Enterprise Manager Fusion Middleware Controlを使用して構成できるフィールドと対応するレプリケーション構成属性を要約して示します。具体的な手順は、第43章「レプリケーションの管理およびモニタリング」を参照してください。

42.2.1 「共有プロパティ」、「レプリケーション」タブの構成属性

Fusion Middleware ControlのOracle Internet Directoryの「共有プロパティ」ページを使用して、レプリケーション属性の一部を構成できます。「Oracle Internet Directory」メニューから、「管理」、「共有プロパティ」、「レプリケーション」の順に選択します。構成を変更した後、「適用」を選択します。対応関係は次のとおりです。

表42-5 「共有プロパティ」、「レプリケーション」タブの構成属性

フィールドまたはヘッダー

構成属性

変更再試行回数

orclchangeretrycount

最大ワーカー数

orclreplmaxworkers

自動チューニング・レプリケーション

orclreplautotune

サプライヤ当たりの適用スレッド数

orclthreadspersupplier;apply

サプライヤ当たりの移送スレッド数

orclthreadspersupplier;transport

レプリケーション・サイクル当たりの最大プロセス・エントリ数

orclsizelimit

レプリケーション競合の自動解決

orclconflresolution

スタック・ダンプの生成

orclsdumpflag

レプリケーション・バインド用SASL

orclreplusesasl;digest-md5

最大ログ・ファイル・サイズ(MB)

orclmaxlogfilesize

ローテーション状態を保つログ・ファイルの最大数

orclmaxlogfiles

変更操作の競合解決

orclreplattrconflict

デバッグ・レベル

orcldebuglevel

レプリケーション・ステータス

orclreplicationstate

アクティブ化/非アクティブ化

orclactivatereplication

レプリカID

orclreplicaid

レプリカ1次URI

orclreplicauri

レプリカ2次URI

orclreplicasecondaryuri

レプリカ状態

orclreplicastate

レプリカ・タイプ

orclreplicatype

42.2.2 レプリケーション・ウィザード・パラメータの構成

一部の構成属性は、Oracle Enterprise Manager Fusion Middleware Controlのレプリケーション・ウィザードで選択または入力するいくつかの値によって制御されます。たとえば、レプリケーション・ウィザードの「スケジュール」ページでの選択によって表42-6「レプリケーション・スケジュール属性」に示す属性が制御されます。

表42-6 レプリケーション・スケジュール属性

フィールドまたはヘッダー

構成属性

LDAP接続

orclldapconnkeepalive

レプリケーション頻度

orclupdateschedule

HIQスケジュール

orclhiqshecule

レプリケーションを構成すると、ウィザードで他の属性が適切に設定されます。たとえば、属性orclreplicauriは、ウィザードの「レプリカ」ページのフィールドを連結して形成されます。

42.3 コマンド行からのレプリケーション構成属性の管理

ほとんどの属性は、コマンド行からldapmodifyを使用して変更できます。コマンド行構文は次のとおりです。

ldapmodify -D cn=orcladmin -q -p portNum -h hostname -f ldifFile

LDIFファイルの内容は、識別名および実行されている操作によって異なります。

レプリケーション構成属性を変更するためのLDIFファイルの例は、第43.3項「コマンド行を使用したレプリケーションの管理およびモニタリング」を参照してください。

43 レプリケーションの管理およびモニタリング

この章では、Oracle Directory Services Manager (ODSM)、Oracle Enterprise Manager Fusion Middleware ControlおよびLDAPコマンド行ユーティリティを使用して、Oracle Internet Directoryでレプリケーションをモニターおよび管理する方法について説明します。また、Oracle Internet Directory比較調整ツール(oidcmpre)を使用して、一貫性のないデータを比較および調整する方法について説明します。

レプリケーションの構成属性の詳細は、第42章「レプリケーション構成属性の管理」を参照してください。

この章の内容は次のとおりです。

- 第43.1項「レプリケーションの管理およびモニタリングの概要」

- 第43.2項「ODSMおよびFusion Middleware Controlを使用したレプリケーションの管理およびモニタリング」

- 第43.3項「コマンド行を使用したレプリケーションの管理およびモニタリング」

- 第43.4項「一貫性のないデータのoidcmprecによる比較調整」

注意:
一部の変更は、レプリケーション・サーバーが再起動されるまで有効になりません。

43.1 レプリケーションの管理およびモニタリングの概要

レプリケーションのインストールおよび構成後は、レプリケーションに関連する属性のデフォルト値を表示または変更できます。属性およびそのコンテナの詳細は、第42章「レプリケーション構成属性の管理」を参照してください。

関連項目:

- 第6章「Oracle Internet Directoryレプリケーションの理解」

- 第40章「レプリケーションの設定」

- 付録C「Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーションの設定」

- 付録D「レプリケーションの動作」

この概要の項目は次のとおりです。

- 第43.1.2項「ワーカー・スレッドの管理」

- 第43.1.3項「ディレクトリ・レプリケーションの変更ログ」

- 第43.1.4項「ディレクトリ・レプリケーションの変更ログのパーティション化」

- 第43.1.5項「管理者操作キュー」

- 第43.1.6項「パイロット・モード」

- 第43.1.7項「Oracleレプリケーションにおける競合の解消」

43.1.1 LDAPベースの部分レプリケーションでのレプリケート対象の変更

LDAPベースの部分レプリケーションでは、レプリカのネーミング・コンテキスト・オブジェクトを定義することにより、レプリケートするものとしないものを変更できます。これらのオブジェクトのパラメータは、次の識別名を持つエントリに格納されます。

cn=namingcontext_ID,cn=replication namecontext,
orclAgreementID=numeric_identifier_of_replication_agreement,
orclReplicaId=unique_identifier_of_replica, cn=replication configuration

注意:
ディレクトリ・レプリケーション・サーバーは、レプリカのネーミング・コンテキスト・オブジェクトを、サプライヤ側にある承諾から読み込むため、すべての変更をサプライヤ側およびコンシューマ側(オプション)のネーミング・コンテキスト・オブジェクトに適用する必要があります。

第43.2.3項「レプリカのネーミング・コンテキスト・オブジェクトの表示と変更」および第43.3.6項「ldapmodifyを使用したレプリカのネーミング・コンテキスト・オブジェクト・パラメータの変更」を参照してください。

43.1.2 ワーカー・スレッドの管理

レプリケーション・サーバーはマルチスレッド・プロセスです。サプライヤ当たりの、次の専用ワーカー・スレッドの数を制御できます。

- サプライヤからコンシューマへの変更ログの転送

- 転送された変更ログのコンシューマでの適用

サプライヤ当たりの転送スレッド数および適用スレッド数を設定できます。あるいは、自動調整(負荷に基づいてこの2つのタスクに割り当てるスレッド数を動的に変更)するようにレプリケーション・サーバーを構成することもできます。サーバーを自動調整するように設定した場合は、これらのタスク間で共有するスレッドの最大数を指定する必要があります。

表43-1は、ワーカー・スレッドを制御するOracle Enterprise Manager Fusion Middleware Controlのパラメータおよび構成属性を示しています。これらは、レプリケーション構成セットの属性です。

表43-1 ワーカー・スレッドを制御する構成属性

Fusion Middleware Controlのパラメータ

構成属性

最大ワーカー数

orclreplmaxworkers

自動チューニング・レプリケーション

orclreplautotune

サプライヤ当たりの適用スレッド数

orclthreadspersupplier;apply

サプライヤ当たりの移送スレッド数

orclthreadspersupplier;transport

このような数はロードに基づいて調整する必要があります。Oracle Enterprise Manager Fusion Middleware Controlで「共有プロパティ」ページの「レプリケーション」タブを使用してスレッドを構成します。コマンド行からldapmodifyを使用します。

関連項目:

- 第43.2.6項「Fusion Middleware Controlを使用したレプリケーション属性の構成」

- 第43.3.7項「ldapmodifyを使用したレプリケーション構成セットの属性の構成」

- 第42.1.6項「レプリケーション構成セットの属性」

43.1.3 ディレクトリ・レプリケーションの変更ログ

Oracle Internet Directoryは、各変更をエントリとして変更ログ・ストアに記録します。各エントリには一意の変更番号があります。コンシューマは、適用した最後の変更の変更番号を記録しておき、その番号よりも大きい変更番号の変更のみをサプライヤから取得します。

- LDAPベース・レプリケーション承諾では、変更ログの処理は、変更ログの転送と変更ログの適用という2つのフェーズで構成されています。LDAPベース承諾ごとに、2つの変更ログ処理のステータス(各フェーズに1つ)があります。ディレクトリ・レプリケーション・サーバーは、最後に転送した変更番号を、レプリケーション承諾エントリのorlcllastappliedchangenumber属性のtransportサブタイプに格納します。ディレクトリ・レプリケーション・サーバーは、最後に適用した変更番号を、レプリケーション承諾エントリのorllclastappliedchangenumber属性のapplyサブタイプに格納します。orlcllastappliedchangenumber属性の書式は、第42.1.3.1項「レプリケーション承諾エントリの属性」を参照してください。

注意:
Oracle Internet Directory 11g リリース1(11.1.1.7.0)以降では、LDAPレプリケーションのデータフローは適用キューを含む適用フェーズから構成されます。トランスポート・キューを含むトランスポート・フェーズは使用されなくなりました。第D.3項「LDAPベースのレプリケーションのアーキテクチャ」を参照してください。

- Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーション承諾では、ディレクトリ・レプリケーション・サーバーによって、最後に転送された変更番号がchangestatusエントリのchangenumber属性に格納されます。changenumber属性は、次のようになります。

changenumber=last_applied_change_number, supplier=supplier_node, consumer=consumer_node

たとえば、コンシューマが最後に適用した変更の番号が250の場合、それ以降サプライヤから取得する変更の番号は、250より大きい番号である必要があります。

- 複数値属性を変更する場合、Oracle Internet Directoryでは通常、変更により1つの新しい値のみが追加されるときでも、その属性値をすべて含む変更ログが作成されます。ただし、数百万個の値を含む場合があるmemberおよびuniquememberでは、この動作によりパフォーマンスの問題が生じます。memberおよびuniquememberについては、Oracle Internet Directoryではそうせずに、追加または削除された値のみを含む変更ログを生成します。この動作は、DSE属性orclsimplemodchglogattributesによって制御されます。

変更ログは、レプリケーション・サーバーがコンシュームした後、ガベージ・コレクタによってパージされます。

43.1.4 ディレクトリ・レプリケーションの変更ログのパーティション化

Oracle Internet Directoryは、各変更をエントリとして変更ログ表に記録します。変更ログ表には、通常、数千から数百万のレコードが含まれます。しかし、このような大容量の表には、次のように重要な考慮事項があります。

- これらの表に対するデータの追加が発生する継続的な更新。

- 新しい変更レコードの継続的なレプリケーション検索。

- 不要なデータを削除するための定期的なパージ。

これらの要件に対処するため、Oracle Internet Directoryでは、変更ログ表のパーティション化の概念が導入されています。パーティション化によって、大規模な表を、より小規模で管理しやすいパーティションと呼ばれる複数の断片に分割できます。各パーティションには、その独自の名前、コンピューティング・リソースおよび記憶域特性があります。問合せが実行されると、処理が必要な行を保持するパーティションにリクエストが転送されます。これによって、問合せ実行のパフォーマンスが向上し、効率性が強化され、日々のメンテナンスの複雑性が簡略化されます。

注意:
変更ログのパーティション化は、Oracle Database 11g Enterprise Edition以上のバージョンでサポートされます。

この項で説明する内容は次のとおりです。

- 第43.1.4.1項「変更ログのパーティション化の方法」

- 第43.1.4.2項「変更ログのパーティション化の構成」

43.1.4.1 変更ログのパーティション化の方法

Oracle Internet Directoryでは、100Kのパーティション範囲を定義して、変更ログ表のODS_CHG_LOGをパーティション化できます。データベースでは100Kのレコードごとに新しいパーティションが作成されるため、各パーティションには100Kのレコードが含まれることになります。

パージが実行されると、個々のレコードではなくパーティションが削除されます。逆に言えば、すべての変更がパージされるわけではありません。パージは、変更ログの最大数が一定の間隔値に到達した場合にのみ発生します。

43.1.4.2 変更ログのパーティション化の構成

変更ログ表のパーティション化を構成するには、製品のアップグレード後またはインストール後に、明示的にoidchlogs.sqlスクリプトを実行する必要があります。このSQLスクリプトは、インストール・パッケージに附属しています。

注意:

- Oracle Internet Directoryのデフォルト・インストールでは、変更ログのパーティション化は有効になりません。

- 変更ログのパーティション化のためにoidchlogs.sqlスクリプトを実行する前に、すべてのOracle Internet Directoryインスタンスを停止する必要があります。

次のディレクトリに移動して、サービスの停止中にOracle Internet Directoryデータベース・ユーザーとしてSQLスクリプトを実行します。

ORACLE_HOME/ldap/admin/oidchlogs.sql

パーティション化に成功すると、バックアップ・パーティション表ods_chg_logとして、chglog_[timestamp]という名前の表が作成されます。

43.1.5 管理者操作キュー

レプリケーションの管理者操作キュー、パージ・キューおよびリトライ・キューのロールの詳細は、第D.5項「レプリケーション・プロセス」を参照してください。競合解消におけるこれらのキューのロールの詳細は、第43.1.7項「Oracleレプリケーションにおける競合の解消」を参照してください。

43.1.5.1 キューの管理

管理者操作キュー・ツールのManageHiq.retryおよびManageHiq.purgeにより、管理者操作キューからリトライ・キューまたはパージ・キューにそれぞれ変更を移動できます。第43.3.9項「管理者操作キューの管理」を参照してください。

43.1.5.2 キュー統計

Oracle Enterprise Manager Fusion Middleware Controlのレプリケーション・ウィザードまたはコマンド行を使用して、キュー統計を表示できます。第43.2.10項「Fusion Middleware Controlを使用したキュー統計の表示」および第43.3.2項「ldapsearchを使用した変更ログの表示」を参照してください。

43.1.5.3 管理者操作キュー・ツールで処理されるエントリ数

レプリケーション・サーバーが一度に処理できる変更ログの最大数を管理者操作キューのエントリ数が超える場合、一部のエントリが処理されません。

レプリケーション・サーバーが一度に処理できる変更ログの最大数は、次の2つの構成属性の最小数です。

- レプリケーション構成セット内のorclsizelimit

- レプリケーションがアクティブであるOIDコンポーネントのインスタンス固有の構成エントリ内のorclsizelimit

レプリケーション構成セット内のorclsizelimitのデフォルト値は1000です。これを0に設定すると、デフォルト値の1000が採用されます。

Oracle Internet Directoryインスタンス固有のエントリ内のorclsizelimit属性は、検索時に返されるエントリの最大数を指定します。デフォルト値は10000です。

一度に処理する変更ログの数を増やすには、両方の属性を同じ値(1000より大きい値)に設定する必要があります。

関連項目:

- 第43.3.12項「管理者操作キュー・ツールで処理できるエントリの数の管理」

- 表42-4「レプリケーション構成セットの属性」

Oracle Internet Directoryサーバー・インスタンスのorclsizelimit属性の設定値を大きくしすぎるとサーバーのパフォーマンスに影響を与えます。これはOracle Internet Directoryサーバー・インスタンスのorclsizelimitが、検索時に返されるエントリの最大数も制御するためです。

43.1.6 パイロット・モード

パイロット・モードを使用して、アプリケーションを本番環境にデプロイする前にテストします。通常、パイロット・モードは、本番ノードからの一方向レプリケーションを使用してローカル・ノードに設定します。レプリカはパイロット・モードですが、ローカル・ノードで発生するLDAPの変更はすべて追跡されます。パイロット・モードが終了すると、これらの変更はLDIFファイルに書き込まれます。アプリケーションが本番環境にデプロイされるときに、パイロット・レプリカで追加または変更されたすべてのエントリをldifファイルを使用して本番ノードに追加できます。

関連項目:
第43.3.4項「remtoolを使用したレプリカのパイロット・モードの指定」

43.1.7 Oracleレプリケーションにおける競合の解消

Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーションと双方向およびマルチマスターのLDAPベース・レプリケーションにより、複数のディレクトリ・サーバーに対する更新が可能になります。競合は、ディレクトリ・レプリケーション・サーバーがサプライヤからコンシューマにリモートの変更を適用しようとして失敗した場合、常に発生します。

通常、競合はWide Area Network上で発生する場合がある通信速度の低下や送信エラーが原因で発生する変更の時間的なずれが原因です。また、過去に発生した不整合がタイムリに解消されていない場合、引き続き競合が発生する可能性があります。

部分レプリケーションでは、ネーミング・コンテキストが含むから除外に変更されると、レプリケーション・サーバーによりコンシューマ側でネーミング・コンテキストが削除されます。同様に、ネーミング・コンテキストが除外から含むに変更されると、レプリケーション・サーバーで、サプライヤからコンシューマへのネーミング・コンテキスト全体が同期化されます。

競合を引き起こす可能性があるLDAP操作は次のとおりです。

- 追加

- 削除

- 変更

- 相対識別名または識別名の変更

43.1.7.1 レプリケーション競合が発生するレベル

競合には次の2つのタイプがあります。

- エントリ・レベルの競合

- 属性レベルの競合

表43-2 レプリケーション競合のタイプ

レプリケーション競合のレベル

説明

エントリ・レベルの競合

ディレクトリ・レプリケーション・サーバーが、コンシューマに変更を適用するときに発生します。次のいずれかのタイプの変更がコンシューマで発生する可能性があります。

- すでに存在しているエントリの追加

- 存在していないエントリの削除

- 存在していないエントリの変更

- 存在していない識別名に対する識別名の変更操作

これらの競合は、解消するのが難しい場合があります。たとえば、次のような原因の場合は競合を解消するのが不可能な可能性があります。

- エントリが別の位置に移動

- エントリがサプライヤから未到着

- エントリが削除済

- エントリがコンシューマに存在しない

存在する必要がないエントリが存在している場合は、以前に追加済であるか、最近識別名の操作変更があった可能性があります。

属性レベルの競合

2つのディレクトリが、同じ属性を異なる値で異なる時間に更新している場合に発生します。属性が単一値の場合、レプリケーション・プロセスは、競合および属性バージョン番号に含まれている変更のタイムスタンプを検証して、競合を解消します。レプリケーション構成設定エントリの属性orclReplAttrConflは、どちらを最初に適用するかを決定します。orclReplAttrConflが0(デフォルト)の場合はタイムスタンプが最初に適用されます。1の場合は属性バージョンが最初に適用されます。

43.1.7.2 競合の自動解消

11g リリース1(11.1.1)では、競合の自動解消を有効にできます。この機能を有効にすると、サプライヤのスキーマとコンシューマのスキーマが一致するときは、管理者操作キューの競合は自動的にパージ・キューに移動されます。

Oracle Enterprise Manager Fusion Middleware Controlまたはldapmodifyコマンドのどちらを使用しても、競合の自動解消を有効または無効にできます。Oracle Enterprise Manager Fusion Middleware Controlを使用するには、「共有プロパティ」ページの「レプリケーション」タブでレプリケーション構成パラメータ「レプリケーション競合の自動解決」を変更します。コマンド行を使用するには、レプリケーション構成セットのorclconflresolutionの値を変更します。

関連項目:

- 第42.1.6項「レプリケーション構成セットの属性」

- 第43.2.6項「Fusion Middleware Controlを使用したレプリケーション属性の構成」

- 第43.3.7項「ldapmodifyを使用したレプリケーション構成セットの属性の構成」

43.1.7.3 競合の自動解消の動作

ディレクトリ・レプリケーション・サーバーは、次の処理によって、発生した競合をすべて解消しようとします。

1. 変更が適用されたときに、競合が検出されます。

2. レプリケーション・プロセスは、特定の待機期間が過ぎると、特定回数分または反復による変更の再適用を、特定期間試行します。

3. レプリケーション・プロセスが変更の適用に成功しないまま再試行制限に達した場合、変更に競合のフラグを付けた後、解消を試みます。解消規則(次の項で説明)に従って競合を解消できない場合は、優先順位の低い管理者操作キューにその変更を移動します。変更は、レプリケーション承諾されたorclHIQScheduleパラメータに指定した時間単位に従って適用されます。ディレクトリ・レプリケーション・サーバーは、変更を移動する前にシステム管理者用のログ・ファイルに競合を書き込みます。

注意:
レプリケーション時に、スキーマ、カタログおよびグループ・エントリの競合の解消は行われません。これは、多数の複数値の属性の競合を解消しようとすると、パフォーマンスに重大な影響を及ぼす可能性があるためです。一度に複数のマスターからこのようなエントリの更新を行うことは、回避してください。

関連項目:

- マルチマスター・レプリケーション・プロセスによるエントリの追加、削除、変更、および識別名と相対識別名の変更方法については、付録D「レプリケーションの動作」を参照してください。

- スキーマについて不明な点がある場合は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のOracle Identity Management LDAPスキーマのリファレンスを参照してください。

- カタログについて不明な点がある場合は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のcatalogコマンド行ツールのリファレンスを参照してください。

- グループ・エントリについて不明な点がある場合は、10g (10.1.4.0.1)ライブラリの『Oracle Identity Management委任管理ガイド』のグループ・エントリの管理に関する項を参照してください

43.2 ODSMおよびFusion Middleware Controlを使用したレプリケーションの管理およびモニタリング

Oracle Enterprise Manager Fusion Middleware Controlを使用してレプリケーションを管理およびモニターできます。この項の内容は次のとおりです。

- 第43.2.1項「Fusion Middleware Controlを使用した変更ログ生成の有効化または無効化」

- 第43.2.2項「Oracle Directory Services Managerを使用したローカル変更ログの表示」

- 第43.2.3項「レプリカのネーミング・コンテキスト・オブジェクトの表示および変更」

- 第43.2.4項「レプリケーション・ウィザードを使用したレプリケーション設定の表示または変更」

- 第43.2.5項「レプリケーション・ウィザードを使用したLDAPベースのレプリケーション承諾の削除」

- 第43.2.6項「Fusion Middleware Controlを使用したレプリケーション属性の構成」

- 第43.2.7項「Fusion Middleware Controlを使用したレプリケーション・サーバーのアクティブ化または非アクティブ化」

- 第43.2.8項「Fusion Middleware Controlを使用したレプリケーションのデバッグ・レベルの構成」

- 第43.2.9項「Fusion Middleware Controlを使用したレプリカ詳細の構成」

- 第43.2.10項「Fusion Middleware Controlを使用したキュー統計の表示」

- 第43.2.11項「Fusion Middleware Controlを使用した変更ログ処理の管理」

- 第43.2.12項「Fusion Middleware Controlを使用した競合解消メッセージのモニタリング」

43.2.1 Fusion Middleware Controlを使用した変更ログ生成の有効化または無効化

次のように、Oracle Enterprise Manager Fusion Middleware Controlを使用して変更ログ生成を有効または無効にできます。

1. 「Oracle Internet Directory」メニューから「管理」を選択し、「サーバー・プロパティ」を選択します。

2. 「パフォーマンス」タブを選択します。

3. 「変更ログの生成の有効化」を選択または選択を解除します。

4. 構成を変更した後、「適用」を選択します。

43.2.2 Oracle Directory Services Managerを使用したローカル変更ログの表示

Oracle Directory Services Managerでは、最近実行された500件の変更を、変更ログ番号別、発生した操作の種類別(追加、変更、削除など)および各変更が加えられたエントリ別に表示できます。特定の変更を指定して、その詳細を表示することもできます。

次のようにOracle Directory Services Managerを使用して、変更ログを表示できます。

1. タスク選択バーで、「拡張」を選択します。

2. 「変更ログ」を拡張します(まだ拡張されていない場合)。左側のパネルに、直近の変更から順に最近の500件の変更が表示されます。

3. 変更を選択してそのプロパティを表示します。

表43-3に、「変更ログ」ページに表示されるプロパティと、対応する変更ログ・エントリの属性を示します。

表43-3 「変更ログ」ページのプロパティ

プロパティ

変更ログ属性

変更番号

changenumber

操作

changetype

ターゲットDN

targetdn

変更

changes

グローバル一意識別子(GUID)

orclguid

親GUID

orclparentguid

変更再試行回数

orclchangeretrycount

変更者名

modifiersname

操作時間

operationtime

サーバー名

servername

43.2.3 レプリカのネーミング・コンテキスト・オブジェクトの表示および変更

レプリカのネーミング・コンテキスト・オブジェクトのパラメータを追加、削除、表示および変更するには、Oracle Enterprise Manager Fusion Middleware Controlのレプリケーション・ウィザードで次のように実行します。

1. ホームページの「Oracle Internet Directory」メニューから、「管理」、「レプリケーション管理」の順に選択します。

2. レプリケーション識別名アカウントへのログインを要求されます。ホスト、ポート、レプリケーション識別名およびレプリケーション識別名のパスワードを入力します。

3. 「レプリケーション承諾」ページに各レプリケーション承諾に関する情報(名前、タイプ、サプライヤ、コンシューマ、ステータス)が表示されます。編集するレプリケーション承諾の名前を選択し、「編集」アイコンをクリックします。画面の下部に3つのタブが表示されます。

4. 「有効範囲」タブで、有効範囲の設定を変更できます。
プライマリ・ネーミング・コンテキストを追加するには、「プライマリ・ネーミング・コンテキスト」フィールドの上にある「作成」ボタンをクリックします。

プライマリ・ネーミング・コンテキストを変更するには、「プライマリ・ネーミング・コンテキスト」フィールドの上の「編集」ボタンをクリックし、別のコンテナを選択します。

5. セカンダリ・ネーミング・コンテキストを除外するには、除外するものを「セカンダリ・ネーミング・コンテキスト」フィールドで選択し、「除外」をクリックして「除外されたセカンダリ・ネーミング・コンテキスト」フィールドに移動します。
セカンダリ・ネーミング・コンテキストを含めるには、含めるものを「除外されたセカンダリ・ネーミング・コンテキスト」フィールドで選択し、「含む」をクリックして「セカンダリ・ネーミング・コンテキスト」フィールドに移動します。

6. 属性を除外するには、除外するものを「属性」フィールドで選択し、「除外」をクリックして「除外された属性」フィールドに移動します。
属性を包含するには、包含するものを「除外された属性」フィールドで選択し、「含む」をクリックして「属性」フィールドに移動します。

7. 変更内容を適用するには、「適用」をクリックします。

8. 加えた変更内容を反映させるには、レプリケーション・サーバーを起動または再起動する必要があります。一方向レプリケーションの場合は、コンシューマで再起動する必要があります。双方向またはマルチマスター・レプリケーション承諾の場合は、レプリケーション承諾の各ノードでレプリケーション・サーバーを再起動する必要があります。それには、ナビゲーション・ツリーのOracle Internet Directoryノードを選択し、次に「Oracle Internet Directory」のメニューから「制御」を選択します。

43.2.4 レプリケーション・ウィザードを使用したレプリケーション設定の表示または変更

レプリケーションを設定する際、レプリケーション承諾とレプリカ・サブエントリを作成します。次のように、Oracle Enterprise Manager Fusion Middleware Controlのレプリケーション・ウィザードを使用して設定を表示または変更できます。

1. ホームページの「Oracle Internet Directory」メニューから、「管理」、「レプリケーション管理」の順に選択します。

2. レプリケーション識別名アカウントへのログインを要求されます。ホスト、ポート、レプリケーション識別名およびレプリケーション識別名のパスワードを入力します。

3. レプリケーション承諾のキュー統計を表示するには、レプリケーション承諾を選択して「キュー統計」を選択し、第43.2.10項「Fusion Middleware Controlを使用したキュー統計の表示」に記載のとおり進めます。

4. レプリケーション承諾を表示または編集するには、編集するレプリケーション承諾の名前を選択し、「編集」アイコンをクリックします。画面の下部に3つのタブが表示されます。

5. レプリケーション構成を表示または編集するには、「レプリケーション構成」タブを選択します。

注意:
常に、レプリケーション承諾を削除または変更する前にレプリケーションを非アクティブ化します。第43.2.7項「Fusion Middleware Controlを使用したレプリケーション・サーバーのアクティブ化または非アクティブ化」を参照してください。

1. 複数のLDAP操作の実行に同じ接続をレプリケーション・サーバーで使用する場合は、「LDAP接続」フィールドで、「キープ・アライブ」を選択します。サーバーでそれぞれのLDAP操作について新規の接続を開始するには、「常に新規の接続を使用」を選択します。

2. 「レプリケーション頻度」を入力します。

3. 「管理者操作キュー・スケジュール」を入力します。これは、ディレクトリ・レプリケーション・サーバーが変更適用プロセスを繰り返す間隔(秒単位)です。

4. 「適用」をクリックして変更を適用するか、「取消」をクリックして変更を破棄します。

6. 有効範囲の設定を表示または変更するには、「有効範囲」タブをクリックします。第43.2.3項「レプリカのネーミング・コンテキスト・オブジェクトの表示と変更」に記載のとおり進めます。

7. 各ノードのタイプ、ホスト、ポートおよびユーザー名を表示するには、レプリケーション定義の編集ページの「レプリカ」タブをクリックします。

8. ノードのレプリカ1次URI、レプリカ2次URIまたはレプリカ状態を表示または編集するには、次のようにします。

1. 「レプリカ」タブを選択し、サプライヤまたはコンシューマの横の「+」をクリックします。

2. 「レプリカ1次URI」または「レプリカ2次URI」フィールドに必要な変更を行います。

3. リストから「レプリカ状態」を選択します。

4. 「適用」をクリックして変更を適用するか、「取消」をクリックして変更を破棄します。

9. ノードをマルチマスター・レプリケーション・グループのプライマリ・ノードにするには、次のようにします。

1. 「レプリカ」タブをクリックしてノードを選択します。

2. 「プライマリ・ノードの作成」アイコンをクリックします。

3. 「適用」をクリックして既存のディレクトリ・レプリケーション・グループにノードを追加するか、「取消」をクリックして変更を破棄します。

10. マルチマスター・レプリケーション・グループにノードを追加するには、次のようにします。

1. 「レプリカ」タブを選択します。

2. 「作成」アイコンをクリックします。

3. ポップアップ・ウィンドウで、新しいノードのホスト、ポートおよびレプリケーション識別名のパスワードの詳細を指定します。「追加」をクリックします。

4. 「適用」をクリックして既存のディレクトリ・レプリケーション・グループにノードを追加するか、「取消」をクリックして変更を破棄します。

11. 3つ以上のノードを含むマルチマスター・レプリケーション・グループからノードを削除するには、次のようにします。

1. 「レプリカ」タブを選択します。

2. マルチマスター・レプリケーション・デプロイメントから削除するレプリカをクリックします。「削除」アイコンが有効になります。

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

4. 「適用」をクリックして、ディレクトリ・レプリケーション・グループ(DRG)からノードを削除します。

43.2.5 レプリケーション・ウィザードを使用したLDAPベースのレプリケーション承諾の削除

一方向、双方向またはマルチマスターLDAPレプリカを削除するには、Oracle Enterprise Manager Fusion Middleware Controlのレプリケーション・ウィザードを使用します。

注意:
常に、レプリケーション承諾を削除または変更する前にレプリケーションを非アクティブ化します。第43.2.7項「Fusion Middleware Controlを使用したレプリケーション・サーバーのアクティブ化または非アクティブ化」を参照してください。

1. ホームページの「Oracle Internet Directory」メニューから、「管理」、「レプリケーション管理」の順に選択します。「レプリケーション承諾」ページに各レプリケーション承諾に関する情報(名前、タイプ、サプライヤ、コンシューマおよびステータス)が表示されます。

2. レプリケーション識別名アカウントへのログインを要求されます。ホスト、ポート、レプリケーション識別名およびレプリケーション識別名のパスワードを入力します。

3. レプリケーション承諾を削除するには、承諾の名前を選択してから、「削除」アイコンをクリックします。「削除」ポップアップが表示された後、「削除」をクリックします。

43.2.6 Fusion Middleware Controlを使用したレプリケーション属性の構成

ほとんどのレプリケーション構成セットの属性は、Fusion Middleware Controlの「共有プロパティ」ページの「レプリケーション」タブを使用して構成できます。「Oracle Internet Directory」メニューから「管理」を選択し、「共有プロパティ」を選択してから、「レプリケーション」を選択します。構成を変更した後、「適用」を選択します。表43-4に、「共有プロパティ」ページの「レプリケーション・コンフィグセット」セクションのフィールド間の対応関係を示します。これらの属性の詳細は、表42-5を参照してください。

表43-4 「共有プロパティ」、「レプリケーション」タブの「レプリケーション・コンフィグセット」の属性

フィールドまたはヘッダー

構成属性

変更再試行回数

orclchangeretrycount

最大ワーカー数

orclreplmaxworkers

自動チューニング・レプリケーション

orclreplautotune

サプライヤ当たりの適用スレッド数

orclthreadspersupplier;apply

サプライヤ当たりの移送スレッド数

orclthreadspersupplier;transport

レプリケーション・サイクル当たりに処理するエントリ数

orclsizelimit

レプリケーション競合の自動解決

orclconflresolution

スタック・ダンプの生成

orclsdumpflag

レプリケーション・バインド用SASL

orclreplusesasl;digest-md5

最大ログ・ファイル・サイズ(MB)

orclmaxlogfilesize

ローテーション状態を保つログ・ファイルの最大数

orclmaxlogfiles

デバッグ・レベル

orcldebuglevel

「自動チューニング・レプリケーション」または「スタック・ダンプの生成」を変更した後、サーバーを再起動します。

関連項目:

- 属性の詳細は、表42-4「レプリケーション構成セットの属性」を参照してください。

- 「デバッグ・レベル」の設定の詳細は、第43.2.8項「Fusion Middleware Controlを使用したレプリケーションのデバッグ・レベルの構成」を参照してください。

43.2.7 Fusion Middleware Controlを使用したレプリケーション・サーバーのアクティブ化または非アクティブ化

レプリケーション・ウィザードを使用してレプリケーションを設定する場合、レプリケーション・サーバーは、これを構成したOracle Internet Directoryインスタンス上で自動的にアクティブになります。必要な場合、構成を変更せずに、レプリケーションを非アクティブ化してから再度アクティブ化できます。また、あるインスタンスでレプリケーションを非アクティブ化してから、同じデータベースを共有する別のOracle Internet Directoryインスタンス上で再度アクティブ化することもできます。Oracle Enterprise Manager Fusion Middleware Controlを使用してレプリケーションをアクティブ化または非アクティブ化するには、Fusion Middleware Controlの「共有プロパティ」ページで、「レプリケーション」タブの「レプリケーション・サーバー・ステータス」セクションを使用します。

属性を次のように構成します。

1. 「Oracle Internet Directory」メニューから「管理」を選択し、「共有プロパティ」を選択してから、「レプリケーション」を選択します。

2. ページの「レプリケーション・サーバー・ステータス」セクションで、アクティブ化または非アクティブ化するOracle Internet Directoryコンポーネントを「レプリケーションをアクティブ化」リストから選択します。このリストには、同じデータベースを共有するWebLogic Serverドメイン内のすべてのOracle Internet Directoryコンポーネントが表示されます。

3. 選択したOracle Internet Directoryコンポーネントのレプリケーション・ステータスが非アクティブである場合、「アクティブ化」をクリックしてアクティブ化できます。レプリケーション・ステータスがアクティブである場合、「非アクティブ化」をクリックしてアクティブ化できます。これ以外をクリックする必要はありません。1つのインスタンスでレプリケーションをアクティブにすると、このレプリケーションは前にアクティブであったインスタンスでは自動的に非アクティブになります。

注意:
ページの上部にある「元に戻す」および「適用」ボタンは、レプリケーション・サーバー・ステータスには影響しません。

表43-5に、ページの「レプリケーション・サーバー・ステータス」セクションのフィールドと構成属性間の対応関係を示します。これらの属性の詳細は、第42.1.6項「レプリケーション構成セットの属性」を参照してください。

表43-5 「共有プロパティ」、「レプリケーション」タブの「レプリケーション・サーバー・ステータス」の属性

フィールドまたはヘッダー

構成属性

レプリケーション・ステータス

orclreplicationstate

レプリケーションをアクティブ化

orclactivatereplication

43.2.8 Fusion Middleware Controlを使用したレプリケーションのデバッグ・レベルの構成

レプリケーションのデバッグ・レベルは、Fusion Middleware Controlの「共有プロパティ」ページで、「レプリケーション」タブの「デバッグ・レベル」セクションを使用して構成できます。

orcldebuglevel属性の詳細は、表42-4「レプリケーション構成セットの属性」を参照してください。

デバッグ・レベルを次のように構成します。

1. 「Oracle Internet Directory」メニューから「管理」を選択し、「共有プロパティ」を選択してから、「レプリケーション」を選択します。

2. 「レプリケーション・プロセス」、「ファンクション・コールのトレース」、「レプリケーション・パフォーマンス・ログ」および「大容量トレースのデバッグ」の任意の組合せを選択します。

3. 「適用」を選択します。

43.2.9 Fusion Middleware Controlを使用したレプリカ詳細の構成

レプリカ詳細は、Fusion Middleware Controlの「共有プロパティ」ページで、「レプリケーション」タブの「レプリカ詳細」セクションを使用して変更できます。

表43-6に、「レプリカ詳細」セクションのフィールドとレプリカ・サブエントリの属性の対応関係を示します。これらの属性の詳細は、表42-1「レプリカ・サブエントリの属性」を参照してください。

orclreplicastateの値の詳細は、第D.4項「LDAPのレプリカ状態」を参照してください。

表43-6 「共有プロパティ」、「レプリケーション」タブの「レプリカ詳細」

フィールドまたはヘッダー

レプリカ・サブエントリの構成属性

レプリカID

orclreplicaid

レプリカ1次URI

orclreplicauri

レプリカ2次URI

orclreplicasecondaryuri

レプリカ状態

orclreplicastate

レプリカ・タイプ

orclreplicatype

レプリカ詳細を構成するには、「Oracle Internet Directory」メニューから「管理」を選択し、「共有プロパティ」を選択してから、「レプリケーション」を選択します。構成を変更した後、「適用」を選択します。

「レプリカ状態」の選択肢は、「ブートストラップ」、「オンライン」および「DBコピーAddNode」です。

「レプリカ・タイプ」の選択肢は、「読取り/書込み」、「読取り専用」および「パイロット」です。

43.2.10 Fusion Middleware Controlを使用したキュー統計の表示

LDAPレプリカの統計は、次のようにOracle Enterprise Manager Fusion Middleware Controlのレプリケーション・ウィザードを使用して表示します。

1. ホームページの「Oracle Internet Directory」メニューから、「管理」、「レプリケーション管理」の順に選択します。

2. レプリケーション識別名アカウントへのログインを要求されます。ホスト、ポート、レプリケーション識別名およびレプリケーション識別名のパスワードを入力します。

3. 「レプリケーション承諾」ページに各レプリケーション承諾に関する情報が表示されます。キュー統計を表示するレプリケーション承諾の名前をクリックし、「キュー統計」アイコンをクリックします。

4. ページの下部に次の統計が表示されます。

- 新規の変更

- 変更の再試行

- 変更のパージ

- HIQの変更

- 前回適用された変更

- 前回移送された変更

43.2.11 Fusion Middleware Controlを使用した変更ログ処理の管理

一度に処理する変更ログの数を増やすには、レプリケーション構成セット内のorclsizelimitと、レプリケーションが実行されているサーバー・インスタンス内のorclsizelimitを同じ値(1000より大きい値)に設定する必要があります。

レプリケーション構成セット内のorclsizelimitを変更するには、Fusion Middleware Controlを使用します。

1. 「Oracle Internet Directory」メニューから「管理」を選択し、「共有プロパティ」を選択します。

2. 「レプリケーション」を選択します。

3. 「レプリケーション・サイクル当たりに処理する最大項目数」パラメータを変更します。

4. 「適用」を選択します。

サーバー・インスタンス内のorclsizelimitを変更するには、Oracle Enterprise Manager Fusion Middleware Controlを使用します。

1. 「Oracle Internet Directory」メニューから「管理」を選択し、「サーバー・プロパティ」を選択します。

2. 「一般」を選択します。

3. 「検索で返される最大エントリ数」の値を変更します。

4. 「適用」を選択します。

Oracle Internet Directoryサーバー・インスタンスのorclsizelimitパラメータの設定値を大きくしすぎるとサーバーのパフォーマンスに影響を与えます。これはorclsizelimitが、検索時に返されるエントリの最大数も制御するためです。

関連項目:
表42-4「レプリケーション構成セットの属性」

43.2.12 Fusion Middleware Controlを使用した競合解消メッセージのモニタリング

次のように、Oracle Enterprise Manager Fusion Middleware Controlを使用して、レプリケーション・ログ内の競合解決メッセージを表示できます。

1. 「Oracle Internet Directory」メニューから、「モニタリング中」、「ログ」を選択します。「ログ・メッセージ」ページが表示されます。

2. 「ログ・ファイル」をクリックします。「ログ・ファイル」ページが表示されます。

3. レプリケーション・ログを選択します。

関連項目:

- Oracle Enterprise Manager Fusion Middleware Controlでのログ・ファイルの表示の詳細は、第24.2.1項「Fusion Middleware Controlを使用したログ・ファイルの表示」を参照してください。

- 競合解決メッセージの詳細は、第43.3.8項「コマンド行を使用した競合解消メッセージのモニタリング」を参照してください。

43.3 コマンド行を使用したレプリケーションの管理およびモニタリング

この項の項目は次のとおりです。

- 第43.3.1項「コマンド行を使用した変更ログ生成の有効化と無効化」

- 第43.3.2項「ldapsearchを使用した変更ログの表示」

- 第43.3.3項「ldapmodifyを使用したレプリカ・サブエントリの属性の構成」

- 第43.3.4項「remtoolを使用したレプリカのパイロット・モードの指定」

- 第43.3.5項「ldapmodifyを使用したレプリケーション承諾の属性の構成」

- 第43.3.6項「ldapmodifyを使用したレプリカのネーミング・コンテキスト・オブジェクト・パラメータの変更」

- 第43.3.7項「ldapmodifyを使用したレプリケーション構成セットの属性の構成」

- 第43.3.8項「コマンド行を使用した競合解消メッセージのモニタリング」

- 第43.3.9項「管理者操作キューの管理」

- 第43.3.10項「remtool -pthputを使用したディレクトリ・レプリケーション・グループでのレプリケーションの進行状況のモニタリング」

- 第43.3.11項「remtoolを使用したキュー統計の表示およびレプリケーションの検証」

- 第43.3.12項「管理者操作キュー・ツールで処理できるエントリの数の管理」

- 第43.3.13項「アドバンスト・レプリケーションのレプリケーション管理者パスワードの変更」

- 第43.3.14項「orclEntryExclusionFilter属性を使用したレプリケーション・フィルタリングの構成」

43.3.1 コマンド行を使用した変更ログ生成の有効化と無効化

変更ログ生成を有効化および無効化するには、ldapmodifyを使用して、インスタンス固有の属性であるorclgeneratechangelogの値を変更します。変更ログ生成を有効化するにはこの値を1に設定し、変更ログ生成を無効化するには0に設定します。コマンドは次のとおりです。

ldapmodify -D cn=orcladmin -q -p portNum -h hostname -f ldifFile

インスタンス固有のエントリ内のorclgeneratechangelog属性の値を1に変更するLDIFファイルは、次のようになります。

dn: cn=componentname,cn=osdldapd,cn=subconfigsubentry
changetype: modify
replace: orclgeneratechangelog
orclgeneratechangelog: 1

43.3.2 ldapsearchを使用した変更ログの表示

コマンド行から変更ログを表示するには、ldapsearchを使用します。表示する変更ログの変更番号または変更番号の範囲を検索フィルタに指定します。サプライヤからローカル・ホストに転送された変更ログを表示するには、サプライヤのレプリカIDも検索フィルタに指定します。

たとえば、サプライヤからローカル・ノードに転送された変更ログの範囲を表示するには、次のように入力します。

ldapsearch -D cn=orcladmin -p port -q -b "cn=changelog" -s one \
"(&(objectclass=changeLogEntry)(servername=SUPPLIER_REPLICAID)\
(changeNumber>=FROMCHGNO)(changeNumber<=TOCHGNO))"

サプライヤからローカル・ノードに転送された単一の変更ログを表示するには、次のように入力します。

ldapsearch -D cn=orcladmin -p port -q -b "cn=changelog" -s one \
"(&(objectclass=changeLogEntry)(servername=SUPPLIER_REPLICAID)\
(changeNumber=CHGNO))"

ローカル・ノードで生成された変更ログの範囲を表示するには、次のように入力します。

ldapsearch -D cn=orcladmin -p port -q -b "cn=changelog" -s one \
"(&(objectclass=changeLogEntry)(changeNumber>=FROMCHGNO)(changeNumber<=TOCHGNO))"

ローカル・ノードで生成された単一の変更ログを表示するには、次のように入力します。

ldapsearch -D cn=orcladmin -p port -q -b "cn=changelog" -s one \
"(&(objectclass=changeLogEntry)(changeNumber=CHGNO))"

出力の一部の行には、セパレータとして文字列<@! !@>が含まれる場合があります。

表43-7に、変更ログの重要な属性を示します。

表43-7 変更ログの重要な属性

属性

説明

changenumber

変更番号

changetype

操作

targetdn

ターゲットDN

changes

変更

orclguid

グローバル一意識別子(GUID)

orclparentguid

親GUID

orclchangeretrycount

変更再試行回数

modifiersname

変更者名

operationtime

操作時間

servername

サーバー名

changeloginfo

クライアントIPアドレスの値など、その他の変更ログ情報

例: changeloginfo=clientip=::ffff:10.229.116.104

43.3.3 ldapmodifyを使用したレプリカ・サブエントリの属性の構成

レプリカ・サブエントリには、次の識別名があります

orclreplicaid=Replica _ID,cn=replication configuration

表43-8に、ldapmodifyを使用して変更できるレプリカ・サブエントリの属性を示します。コマンド行構文は次のとおりです。

ldapmodify -D cn=orcladmin -q -p portNum -h hostname -f ldifFile

表43-8 レプリカ・サブエントリの属性

説明

構成属性

レプリカID

orclreplicaid

レプリカ1次URI

orclreplicauri

レプリカ2次URI

orclreplicasecondaryuri

レプリカ状態

orclreplicastate

レプリカ・タイプ

orclreplicatype

関連項目:

- 表42-1「レプリカ・サブエントリの属性」

- 第D.4項「LDAPのレプリカ状態」

表D-1「LDAPのレプリカ状態」に、orclreplicastateの値の詳細を示します。値として0、1、2、6または8を設定できます。表D-1にリストされている他のorclreplicastateの値は、ブートストラップ時にレプリケーション・サーバーによって設定される読取り専用値です。

orclreplicastateをゼロに設定するには、次のLDIFファイルを使用します。

dn: orcclreplicaid=Replica _ID,cn=replication configuration
changetype: modify
replace: orclreplicastate
orclreplicastate: 0

43.3.4 remtoolを使用したレプリカのパイロット・モードの指定

エンタープライズの一部としてレプリカをデプロイする前に、これをパイロット・モードでテストできます。パイロット・モードを開始および終了するには、remtoolコマンドを使用します。構文は次のとおりです。

remtool -pilotreplica begin -bind hostname:ldap_port

remtool -pilotreplica end -bind hostname:ldap_port [-bkup file_name]

remtool -pilotreplica beginを実行すると、次のようになります。

- orclreplicatypeは2(パイロット)に設定されます。

- orclpilotmodeは1に設定されます。

- pilotstarttimeは現在の時刻に設定されます。

remtool -pilotreplica endを実行すると、次のようになります。

- orclpilotmodeは0に設定されます。

ldapmodifyを使用してこれらの属性を直接変更しないようにしてください。

関連項目:
remtoolの-pilotreplicaオプションの詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のremtoolコマンドのリファレンスを参照してください。

43.3.5 ldapmodifyを使用したレプリケーション承諾の属性の構成

レプリケーション承諾には、次の識別名があります。

orclagreementid=Agreement_ID,orclreplicaid=Replica_ID,cn=replication configuration

表43-9に、ldapmodifyを使用して変更できるレプリケーション承諾の属性を示します。詳細は、表42-2「レプリケーション承諾エントリの属性」を参照してください。

注意:
常に、レプリケーション承諾を削除または変更する前にレプリケーションを非アクティブ化します。第43.2.7項「Fusion Middleware Controlを使用したレプリケーション・サーバーのアクティブ化または非アクティブ化」を参照してください。

表43-9 レプリケーション承諾のオプション

説明

構成属性

デフォルト値

レプリケーション頻度

orclupdateschedule

60(秒)

HIQスケジュール

orclhiqschedule

600(秒)

ディレクトリ・レプリケーション・サーバーをディレクトリ・サーバーに常時接続するか、変更ログ処理が行われるたびに接続するか

orclldapconnkeepalive

1

次のLDIFファイルは、レプリケーション承諾のorclHIQSchedule属性の値を900分に変更して管理者操作キュー・スケジュールを変更します。

dn: orclagreementid=Agreement_ID,orclreplicaid=Replica_ID,cn=replication configuration
changetype: modify
replace: orclhiqschedule
orclhiqschedule: 900

関連項目:
表42-2「レプリケーション承諾エントリの属性」

43.3.6 ldapmodifyを使用したレプリカのネーミング・コンテキスト・オブジェクト・パラメータの変更

レプリケーション範囲はコマンド行から変更できます。これを行うには、レプリケーションのネーミング・コンテキスト・コンテナ・エントリの下のネーミング・コンテキスト・オブジェクト・エントリを作成または変更します。次を参照してください。

関連項目:

- 表42-2「レプリケーション承諾エントリの属性」

- 第42.1.4項「レプリケーションのネーミング・コンテキスト・コンテナ・エントリ」

- 第42.1.5項「レプリケーションのネーミング・コンテキスト・オブジェクト・エントリ」

レプリケーション範囲を変更するには、次のようなコマンド行を使用します。

ldapadd -p port_number -h host -f file.ldif

この場合、LDIFファイルを使用して承諾の範囲を設定します。

たとえば、次のLDIFファイルを使用して、レプリケーション範囲をcn=oraclecontextに設定します。

dn: cn=includednamingcontext000001,cn=replication
namecontext,orclagreementid=agreementid,orclreplicaid=replicaid,cn=replication
configurationobjectclass: orclreplnamectxconfig
orclincludednamingcontexts: cn=oraclecontext
cn: includednamingcontext000001

次のファイルを使用して、レプリケーション範囲からEMEAおよびAPACグループと、userpasswordおよびauthpassword属性を除外します。

dn: cn=includednamingcontext000002,cn=replication
namecontext,orclagreementid=agreementid,orclreplicaid=replicaid,cn=replication
configuration
objectclass=orclreplnamectxconfig
orclincludednamingcontexts: dc=com
orclexcludednamingcontexts: cn=groups,l=emea,dc=xyz,dc=com
orclexcludednamingcontexts: cn=groups,l=apac,dc=xyz,dc=com
orclExcludedAttributes: userpassword
orclExcludedAttributes: authpassword
cn: includednamingcontext000002

レプリカのネーミング・コンテキスト・オブジェクトのパラメータとその説明は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のレプリケーション・スキーマ要素に関する説明を参照してください。

注意:
レプリケーション・サーバーは、サプライヤ・レプリカからネーミング・コンテキスト・オブジェクトを読み取ります。

例43-1 LDAPベースのレプリカのネーミング・コンテキスト・オブジェクトの追加

この例では、次の処理を行うネーミング・コンテキスト・オブジェクトを作成します。

- ou=Americas,cn=mycompanyネーミング・コンテキストをレプリケート

- レプリケーションからcn=customer profile, ou=Americas,cn=mycompanyネーミング・コンテキストを除外

- レプリケーションからuserpassword属性を除外

手順は、次のとおりです。

1. サンプル・ファイルmod.ldifを、次のように編集します。

dn: cn=naming_context_identifier, cn=replication  namecontext,
orclagreementid=replication_agreement_identifier,
orclreplicaid=supplier_replica_identifier,cn=replication configuration
orclincludednamingcontexts: ou=Americas,cn=mycompany
orclexcludednamingcontexts: cn=customer profile, ou=Americas, cn=mycompany
orclexcludedattributes: userpassword
objectclass: top
objectclass: orclreplnamectxconfig

2. ldapaddを使用して、部分レプリケーションのネーミング・コンテキスト・オブジェクトをサプライヤに追加します。

ldapadd -D "cn=orcladmin" -q -h supplier_host \
-p port_number -f mod.ldif

例43-2 ネーミング・コンテキスト・オブジェクトの削除

例43-1で作成したネーミング・コンテキスト・オブジェクトを削除するには、次のように入力します。

ldapdelete -D "cn=orcladmin" -q \
-h supplier_host -p supplier_host_port_number \
"cn=naming_context_identifier, cn=replication namecontext, \
orclagreementid=replication_agreement_identifier, \
orclreplicaid=supplier_replica_identifier, \
cn=replication configuration"

例43-3 レプリカのネーミング・コンテキスト・オブジェクトのorclIncludedNamingContexts属性の変更

ディレクトリ・レプリケーション・サーバーは、レプリカのネーミング・コンテキスト・オブジェクトのorclIncludedNamingcontexts属性の値を使用して、部分レプリケーションに含める最上位サブツリーを指定します。

この例では、含める対象ネーミング・コンテキストがc=usに設定されます。これは、c=usが部分レプリケーションに含められることを意味しています。

1. サンプル・ファイルmod.ldifを、次のように編集します。

DN:cn=naming_context_identifier,cn=replication namecontext,
orclagreementid=replication_agreement_identifier,
orclreplicaid=supplier_replica_identifier,cn=replication configuration
Changetype:modify
Replace: orclIncludedNamingcontexts
orclIncludedNamingcontexts: c=us

2. ldapmodifyを使用して、レプリケーション承諾のorclupdateschedule属性を更新します。

ldapmodify -D "cn=orcladmin" -q -h supplier_host -p port -f mod.ldif

3. ディレクトリ・レプリケーション・サーバーを再起動します。

例43-4 レプリカのネーミング・コンテキスト・オブジェクトのorclExcludedNamingContexts属性の変更

ディレクトリ・レプリケーション・サーバーは、レプリカのネーミング・コンテキスト・オブジェクトのorclExcludedNamingcontexts属性の値を使用して、部分レプリケーションから除外する最上位サブツリーを指定します。

この例では、除外対象ネーミング・コンテキストがou=Europe,c=usおよびou=Americas,c=usに設定されます。これは、この2つのネーミング・コンテキストが部分レプリケーションから除外されることを意味しています。

1. サンプル・ファイルmod.ldifを、次のように編集します。

DN:cn=naming_context_identifier,
cn=replication namecontext,
orclagreementid=replication_agreement_identifier,
orclreplicaid=supplier_replica_identifier,cn=replication configuration
Changetype:modify
Replace: orclExcludedNamingcontexts
orclExcludedNamingcontexts: ou=Europe, c=us
orclExcludedNamingcontexts: ou=Americas, c=us

2. ldapmodifyを使用して、レプリケーション承諾のorclupdateschedule属性を更新します。

ldapmodify -D "cn=orcladmin" -q -h supplier_host -p port -f mod.ldif

3. ディレクトリ・レプリケーション・サーバーを再起動します。

注意:
orclexcludednamingcontexts属性に指定されたサブツリーは、同一レプリカのネーミング・コンテキスト・オブジェクトで指定されるincludednamingcontextのサブツリーである必要があります。

例43-5 レプリカのネーミング・コンテキスト・オブジェクトのorclExcludedAttributes属性の変更

含めるネーミング・コンテキストに加えられた特定の変更を、属性レベルで部分レプリケーションから除外するように指定できます。ディレクトリ・レプリケーション・サーバーは、レプリカのネーミング・コンテキスト・オブジェクトのorclExcludedAttributes属性の値を使用して、除外する属性を判別します。

この例では、orclincludednamingcontexts属性に指定されたtelephonenumber属性およびtitle属性が、レプリケーションから除外されます。

1. サンプル・ファイルmod.ldifを、次のように編集します。

DN:cn=naming_context_identifier,
cn=replication namecontext,
orclagreementid=replication_agreement_identifier,
orclreplicaid=supplier_replica_identifier,cn=replication configuration
Changetype:modify
Replace: orclExcludedAttributes
orclExcludedAttributes: telephonenumber
orclExcludedAttributes: title

2. ldapmodifyを使用して、レプリケーション承諾のorclupdateschedule属性を更新します。

ldapmodify -D "cn=orcladmin" -q -h my_host -p port -f mod.ldif

3. ディレクトリ・レプリケーション・サーバーを再起動します。

43.3.7 ldapmodifyを使用したレプリケーション構成セットの属性の構成

レプリケーション構成セットには、次の識別名があります。

cn=configset0,cn=osdrepld,cn=subconfigsubentry

表43-10に、ldapmodifyを使用して変更できるレプリケーション構成セットの属性を示します。

表43-10 レプリケーション構成の属性

説明

構成属性

デフォルト値

変更再試行回数

orclchangeretrycount

10

最大ワーカー数

orclreplmaxworkers

20

自動チューニング・レプリケーション

(変更した後、サーバーを再起動します。)

orclreplautotune

1

サプライヤ当たりの適用スレッド数

orclthreadspersupplier;applly

5

サプライヤ当たりの移送スレッド数

orclthreadspersupplier;transport

1

レプリケーション・サイクル当たりの最大プロセス・エントリ数

orclsizelimit

1000

レプリケーション競合の自動解決

orclconflresolution

1

スタック・ダンプの生成

(変更した後、サーバーを再起動します。)

orclsdumpflag

レプリケーション・バインド用SASL

orclreplusesasl;digest-md5

なし

最大ログ・ファイル・サイズ(MB)

orclmaxlogfilesize

1

ローテーション状態を保つログ・ファイルの最大数

orclmaxlogfiles

100

デバッグ・レベル

orcldebuglevel

0

レプリケーション・ステータス

orclreplicationstate

アクティブ化/非アクティブ化

orclactivatereplication

0

たとえば、次のLDIFファイルでは、レプリケーション構成セットにorclreplusesasl;digest-md5属性を追加して設定し、レプリケーションのバインド用SASLを有効にします。

dn: cn=configset0,cn=osdrepld,cn=subconfigsubentry
changetype: modify
add: orclreplusesasl;digest-md5
orclreplusesasl;digest-md5: 1

orclsizelimitの変更の詳細は、第43.3.12項「管理者操作キュー・ツールで処理されるエントリの数の管理」を参照してください。

属性orcldebuglevelは、表43-11に示す値の任意の組合せに設定できます。値は加算方式です。再起動は不要です。

表43-11 レプリケーションのデバッグ・レベル

デバッグ・レベル

orcldebuglevelの値

レプリケーション・プロセスのトレース

4194304

レプリケーション・パフォーマンス・ログ

2097152

ファンクション・コールのトレース

8388608

大容量トレースのデバッグ

16777216

関連項目:
表42-4「レプリケーション構成セットの属性」

43.3.8 コマンド行を使用した競合解消メッセージのモニタリング

競合がログに書き込まれた場合、それは、システムに備わった解消手順では競合を解消できないということを意味します。以前に適用されなかった変更によって新しいレプリケーション変更の競合が発生することを防止するために、ログを定期的にモニターすることが重要です。

レプリケーション変更の競合をモニターするには、レプリケーション・ログの内容を検証します。それぞれに付加されているタイムスタンプによって、各メッセージを識別できます。

競合解消メッセージは、ファイルORACLE_INSTANCE/diagnostics/logs/OID/componentName/oidrepld00-XXXX.logに記録されます。この場合、XXXXは0000からorclmaxlogfiles configuredの範囲の数値です。

各メッセージには、競合の理由、変更番号、サプライヤ・ノード、変更タイプ、ターゲットDNおよび結果が含まれています。次に、いくつかの例を示します。

これは、競合がレプリケーション・サーバーによって自動的に解消された競合解消メッセージです。

[2008-10-09T09:57:31-07:00] [OID] [NOTIFICATION:16] [] [OIDREPLD] [host: stacu14]
[pid: 4280] [tid: 3] Worker(Transport)::[[************ Conflict Resolution
Message ************
Conflict reason: Attempted to add an existing entry.
Change number: 3696.
Supplier: stacu14_lm5.
Change type: Add.
Target DN: dc=org.
Result: Dropped a newer change entry.
]]

次は、管理者操作キューに移動された未解決の競合です。

[2008-10-09T10:03:28-07:00] [OID] [NOTIFICATION:16] [] [OIDREPLD] [host: stacu14]
[pid: 4653] [tid: 13] Worker(Transport)::[[************ Conflict Resolution
Message ************
Conflict reason: Attempted to delete a non-existent entry.
Change number: 3698.
Supplier: stacu14_lm5.
Change type: Delete.
Target DN: dc=imc,dc=org.
Result: Change moved to low priority queue after failing on 10th retry.
]]

競合の理由、変更タイプおよび結果には次のようなものがあります。

表43-12 競合解消メッセージ

競合の理由

変更タイプ

結果

既存のエントリの追加が試行されました

追加

新しい変更エントリが削除されました

N番目の再試行に失敗した後、変更は低優先度のキューに移動されました

変更エントリより後に作成された重複するターゲット・エントリが削除されました。変更エントリを再度適用してください

新しい変更エントリが削除されました

変更エントリは、guidがターゲット・エントリのguidより大きいため削除されました

変更エントリは、guidがターゲット・エントリと同じ(変更エントリとターゲット・エントリが同一)であるため削除されました

変更エントリより大きいguidを持つ重複するターゲット・エントリは削除されました

親エントリが存在しません

追加

N番目の再試行に失敗した後、変更は低優先度のキューに移動されました

内部エラーが発生しました

追加

削除

変更

moddn

N番目の再試行に失敗した後、変更は低優先度のキューに移動されました

存在しないエントリの変更が試行されました

変更

N番目の再試行に失敗した後、変更は低優先度のキューに移動されました

存在しないエントリの削除が試行されました

削除

N番目の再試行に失敗した後、変更は低優先度のキューに移動されました

リーフ以外のエントリの削除が試行されました

削除

N番目の再試行に失敗した後、変更は低優先度のキューに移動されました

存在しないエントリの移動が試行されました

moddn

N番目の再試行に失敗した後、変更は低優先度のキューに移動されました

既存のエントリへの移動が試行されました

moddn

N番目の再試行に失敗した後、変更は低優先度のキューに移動されました

存在しない別のエントリのmoddnの同期化が進行中です

moddn

移動しようとしているエントリより後に作成された既存のエントリが削除されました。エントリの移動が再試行されます

ソース・エントリより新しい既存のエントリへの移動が試行されました

moddn

エントリの移動が再試行されます

移動しようとしているエントリより古い既存のエントリへの移動が試行されました

moddn

ソース・エントリが削除され、変更が削除されました

同時に作成された同じguidを持つ既存のエントリへの移動が試行されました

moddn

ソース・エントリが削除され、変更が削除されました

移動しようとしているエントリより大きいguidを持つ既存のエントリへの移動が試行されました

moddn

重複するターゲット・エントリが削除され、変更が再適用されました

移動しようとしているエントリより小さいguidを持つ既存のエントリへの移動が試行されました

moddn

ソース・エントリが削除され、変更が削除されました

43.3.9 管理者操作キューの管理

レプリケーションの競合が発生すると、Oracle Internet Directoryレプリケーション・サーバーは変更をリトライ・キューに入れ、そこからの変更の適用を指定された回数試行します。指定された再試行回数の後に失敗した場合、レプリケーション・サーバーは変更を管理者操作キューに入れます。レプリケーション・サーバーは、管理者によるアクションを待ちながら、そこから長い間隔で変更適用プロセスを繰り返します。

管理者操作キュー・ツールのManageHiq.retryおよびManageHiq.purgeにより、管理者操作キューからリトライ・キューまたはパージ・キューにそれぞれ変更を移動できます。パージ・キューに変更を移動すると、以降ログ・エントリに対する変更の再適用は試行されません。管理者操作キューの変更を処理するには、次の一般的な手順を実行してください。

1. 管理者操作キューの変更を検証します。

2. 比較調整ツールを使用して競合している変更を調整します(第43.4項「一貫性のないデータのoidcmprecによる比較調整」を参照してください)。

3. ManageHiq.retryを使用してリトライ・キューに、またはManageHiq.purgeを使用してパージ・キューに変更を戻します。

関連項目:
管理者操作キュー・ツールの使用方法は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』の「レプリケーション・ツール」の章を参照してください。

43.3.10 remtool -pthputを使用したディレクトリ・レプリケーション・グループでのレプリケーションの進行状況のモニタリング

レプリケーション環境管理ツールremtoolを使用して、ディレクトリ・レプリケーション・グループでのレプリケーションの進行状況をモニターできます。-pthputオプションを指定してremtoolを起動すると、ツールは指定されたノードにバインドされ、ディレクトリ・レプリケーション・グループ内のすべてのノードに関する情報が収集されます。この情報は、指定された間隔で表示されます。

構文は次のとおりです。

remtool -pthput [-bind hostname:port] -interval time_in_seconds [-file filename]

bind引数はオプションです。これを指定しない場合、remtoolからhostname、portを入力するように求められます。レプリケーションdnのパスワードの入力を求められます。

intervalパラメータは、オプション・パラメータです。値は秒で指定します。デフォルト値は60秒です。各時間隔が経過するたびに、ディレクトリ・レプリケーション・グループ内のサプライヤおよびコンシューマ・ノードごとに次の情報がツールに表示されます。

- 最後の時間隔でキューに入れられた変更、q_chgs

- 最後に適用された変更番号、LA_Chg#

- 最後の時間隔で適用された変更、Appl_chgs

- 最後の3回の時間隔での平均スループット、Avg_thput

fileパラメータを指定すると、コマンド行に表示される出力がそのファイルに記録されます。指定しないと、タイムスタンプに基づいた名前のファイルに出力が記録されます。

出力例

------------------------------------------------------------------------------
Directory Replication Group (DRG) details :
--- ------------------ ----------------------- ----------------------- -----
Sl  Replicaid          Directory Information   Supplier Information    Repl. No.                                                                    Type
--- ------------------ ----------------------- ----------------------- -----
001 adc2101322_nldap32 adc2101322.us.example.com:3070 adc2101322_nldap3      RW
002 adc2101322_nldap3  adc2101322.us.example.com:3061 adc2101322_nldap32     RW
--- ------------------ ----------------------- ----------------------- -----
Queue Statistics :
------------ ------------- ----- ------- ------ ------ ------ --------- --------- --------------------------------
Supplier            Consumer           Queued      Last Applied     Applied      Average
Changes     Change Number    Changes      Throughput
Of 3 intervals
------------- ------------- ----- ------- ------ ------ ------ --------- --------- -----------------------------
adc2101322_nldap3    adc2101322_nldap32        0          134369             0            0
adc2101322_nldap32   adc2101322_nldap3         0           47342             0            0
------------- ------------- ----- ------- ------ ------ ------ --------- --------- --------------------------
adc2101322_nldap3    adc2101322_nldap32     2286          136214          1845           615
adc2101322_nldap32   adc2101322_nldap3         0           47342             0             0
------------- ------------- ----- ------- ------ ------ ------ --------- --------- -----------------------
adc2101322_nldap3    adc2101322_nldap32     1608          137886          1672          1172
adc2101322_nldap32   adc2101322_nldap3         0           47342             0             0
------------- ------------- ----- ------- ------ ------ ------ --------- --------- ------------------------
adc2101322_nldap3    adc2101322_nldap32      189          140302          2416          1977
adc2101322_nldap32   adc2101322_nldap3         0           47342             0             0
------------- ------------- ----- ------- ------ ------ ------ --------- --------- -----------------------

43.3.11 remtoolを使用したキュー統計の表示およびレプリケーションの検証

レプリケーション環境管理ツールremtoolを使用すれば、レプリケーション・プロセスの状態をモニターできます。remtoolを定期的に実行して、レプリケーション・プロセスが正常に実行されていることを確認できます。remtoolコマンドには、キュー統計を表示し、レプリケーションを検証するオプションがあります。

LDAPベースのレプリケーション承諾をモニタリングするためのremtoolオプションは、-pdipqstatと-pverifyです。構文は次のとおりです。

remtool -pdispqstat [-v] [-bind hostname:port_number]

remtool -pverify [-v] [-bind hostname:port_number] [-hiqmax hiqmax] [-tbtmax tbtmax]

Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーション承諾の場合、remtoolオプションは、-dipqstatと-asrverifyです。

構文は次のとおりです。

remtool -dispqstat [-connect repl_admin_name@net_service_name] [-v]

remtool -asrverify [-connect repl_admin_name@net_service_name] [-v]

これらすべてのコマンドで、replication_dn_passwordの入力を求められます。

レプリケーション・タイプに応じて、最初にremtoolを-pdispqstatオプションまたは-dispqstatオプションとともに実行します。DRGのキュー統計が表示されます。管理者操作キュー(HIQ)エントリの数および移送される変更ログ(ログTBP)の数が通常よりも多いかどうかを確認します。多い場合は、レプリケーションが本来よりもゆっくりと実行されています。レプリケーション・タイプに応じて、remtoolを-pverifyオプションまたは-asrverifyオプションとともに実行し、レプリケーション構成を検証します。

-pverifyまたは-asrverifyオプションを使用したremtoolによりテストの失敗が報告された場合は、生成されるレポートをチェックし、レポートの提案に従い、失敗を修正します。

関連項目:
『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のremtoolコマンド行ツールのリファレンス

43.3.12 管理者操作キュー・ツールで処理できるエントリの数の管理

一度に処理する変更ログの数を増やすには、レプリケーション構成セット内のorclsizelimitと、レプリケーションが実行されているサーバー・インスタンス内のorclsizelimitを同じ値(1000より大きい値)に設定する必要があります。ldapmodifyを使用して両方を変更します。どちらの場合も、次のように入力します。

ldapmodify -D cn=orcladmin -q -p portNum -h hostname -f ldifFile

レプリケーション構成セットのorclsizelimitを5000に設定するには、次のようなLDIFファイルを使用します。

dn: cn=configset0,cn=osdrepld,cn=subconfigsubentry
changetype: modify
replace: orclsizelimit
orclsizelimit: 5000

サーバー・インスタンスのorclsizelimitを5000に設定するには、次のようなLDIFファイルを使用します。

dn: cn=componentname,cn=osdldapd,cn=subconfigsubentry
changetype: modify
replace: orclsizelimit
orclsizelimit: 5000

Oracle Internet Directoryサーバー・インスタンスのorclsizelimitパラメータの設定値を大きくしすぎるとサーバーのパフォーマンスに影響を与えます。これはorclsizelimitが、検索時に返されるエントリの最大数も制御するためです。

関連項目:

- 第9.1.3項「インスタンス固有の構成エントリの属性」

- 第42.1.6項「レプリケーション構成セット」

- 第43.3.7項「ldapmodifyを使用したレプリケーション構成セットの属性の構成」

43.3.13 アドバンスト・レプリケーションのレプリケーション管理者パスワードの変更

Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーションを使用するDRGのすべてのノードに対するレプリケーション管理者のデータベース・アカウントのパスワードは、レプリケーション環境管理ツールのremtoolに-chgpwd引数を使用して変更できます。この引数を使用するには、次のように入力します。

remtool -chgpwd

remtoolユーティリティにより、MDSグローバル名(つまり、マスター定義サイトの名前)、現在のパスワードおよび新規パスワードを要求するプロンプトが表示されます。その後、新規パスワードの確認を要求されます。間違った現在のパスワードを入力した場合は、レプリケーション環境管理ツールを再度実行する必要があります。

remtoolに-pchgpwd引数を使用して、レプリカのレプリケーション識別名のパスワードを変更することもできます。

レプリケーション・ウォレットの$ORACLE_INSTANCE/OID/admin/oidpwdrORACLE_SID内でのみパスワードを変更するには、remtoolに-pchgwalpwd引数を使用します。この引数を使用するには、次のように入力します。

remtool -pchgwalpwd

関連項目:
このツールの使用方法の詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のremtoolコマンド行ツールのリファレンスを参照してください。

43.3.14 orclEntryExclusionFilter属性を使用したレプリケーション・フィルタリングの構成

11gリリース1 (11.1.1.9.0)以降のOracle Internet Directoryサーバーおよびディレクトリ・レプリケーション・サーバーでは、レプリケーション承諾のorclEntryExclusionFilter属性で構成されたLDAPフィルタに基づいて、特定のエントリを除外できます。

orclEntryExclusionFilter属性はオプションで、カッコで囲まれた有効なLDAPフィルタ文字列を指定する単一値属性です。詳細は、第42.1.3.1項「レプリケーション承諾エントリの属性」を参照してください。

注意:
orclEntryExclusionFilter属性のLDAPフィルタ文字列では、非カタログ化属性と集合属性はサポートされません。指定しない場合、フィルタは適用されません。

orclEntryExclusionFilter属性を使用したレプリケーション・フィルタリングは、一方向LDAPレプリケーションにのみ適用され、他のレプリケーション機能は変更されません。

orclEntryExclusionFilter属性を使用してレプリケーション・フィルタリングを構成する手順は、次のとおりです。

1. "cn=replication configuration"でldapsearchを使用して、レプリケーション承諾エントリのdnを検索します。

2. ldapmodifyを使用して、手順1のレプリケーション承諾エントリにorclEntryExclusionFilter属性を追加します。次の例で、orclEntryExclusionFilter属性は、LDAPフィルタを(sn=smith)と指定しています。

dn: orclagreementid=000001,orclreplicaid=supplier,cn=replication configuration
changetype: modify
add: orclentryexclusionfilter
orclentryexclusionfilter: (sn=smith)

3. レプリケーション・サーバーを再起動してLDAPフィルタを有効化します。

サプライヤでLDAPフィルタ(sn=smith)に一致するすべてのエントリに対する後続の変更は、コンシューマにレプリケートされません。

43.4 一貫性のないデータのoidcmprecによる比較調整

ディレクトリ・レプリケーション・サーバーが一貫性のないデータを検出した場合、Oracle Internet Directory比較調整ツールを使用して、コンシューマのエントリをサプライヤのエントリと同期化させることができます。その場合、次の一般的な手順を実行します。

1. サプライヤとコンシューマを、読取り専用モードに設定します。「サーバー・モードの変更」の手順のいずれかを使用します。

2. サプライヤとコンシューマが安定した状態、つまり変更の供給も適用も行っていない状態にあることを確認します。安定した状態にない場合は、更新が完了するまで待ちます。

3. コンシューマ上の一貫性のないエントリまたはサブツリーを識別します。

4. Oracle Internet Directory比較調整ツールを使用して、コンシューマ上の一貫性のないエントリまたはサブツリーを修正します。

5. サプライヤとコンシューマを、読取り/書込みモードに戻します。

関連項目:
Oracle Internet Directory比較調整ツールの構文と動作の詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のoidcmprecコマンド行ツールのリファレンスを参照してください。

注意:
比較調整ツールoidcmprecでは、一方向認証または双方向認証はサポートされず、認証なしモードでのみ動作します。

比較調整ツールoidcmprecを使用すると、2つのディレクトリを比較できます。これにより、競合が検出され、解消されます。2つのディレクトリのうち、1つのディレクトリはソース・ディレクトリ、つまり真のソースとみなされます。もう1つのディレクトリは、ソース・ディレクトリと同期する必要がある宛先ディレクトリです。比較対象となるディレクトリは、どのレプリケーション・グループのメンバーでもないディレクトリ、同じレプリケーション・グループのメンバーであるディレクトリ、または別のレプリケーション・グループのメンバーであるディレクトリです。

この項では、oidcmprecツールの概要と、oidcmprecの使用例のいくつかについて説明します。次のトピックが含まれています。

- 第43.4.1項「競合の例」

- 第43.4.2項「oidcmprecでサポートされる操作」

- 第43.4.3項「oidcmprecからの出力」

- 第43.4.4項「oidcmprecの動作」

- 第43.4.5項「ソース・ディレクトリと宛先ディレクトリの設定」

- 第43.4.6項「操作のDITの選択」

- 第43.4.7項「操作属性の選択」

- 第43.4.8項「変更ログ生成の制御」

- 第43.4.9項「テキストまたはXMLパラメータ・ファイルの使用」

- 第43.4.10項「ディレクトリ・スキーマの包含」

- 第43.4.11項「事前に定義された競合解消規則の無視」

- 第43.4.12項「ユーザー定義の比較調整操作の使用」

- 第43.4.13項「oidcmprecツールの既知の制限事項」

関連項目:
操作、競合の例、競合解消規則を含むoidcmprecの完全な構文は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のoidcmprecコマンド・リファレンスを参照してください。

43.4.1 競合の例

oidcmprecツールは、次の競合の例を検出し、解消できます。

- ソース・ディレクトリ内のみのエントリ(entos)

- 宛先ディレクトリ内のみのエントリ(entod)

- ソース・ディレクトリ内のみの属性(atros)

- 宛先ディレクトリ内のみの属性(atrod)

- 異なる単一値属性(svatrdif)

- 異なる複数値属性(mvatrdif)

- 異なるエントリ識別名(dndif)
dndifの例は、一方のノードで実行されたmodrdnまたはmoddn操作が、もう一方のノードにレプリケートされないときに、レプリケーション環境で発生する可能性があります。結果として、そのエントリは、orclguidは同じでも、識別名が2つのノードで異なります。ツールでは、orclguid属性を使用して、この競合を検出します。

oidcmprecツールは、次のスキーマ競合の例を検出し、解消できます。

- オブジェクト・クラス定義が、ソース・ディレクトリにのみ存在(odefos)

- オブジェクト・クラス定義が、宛先ディレクトリにのみ存在(odefod)

- ソースおよび宛先ディレクトリで異なるオブジェクト・クラス定義(odefdif)

- 属性定義が、ソース・ディレクトリにのみ存在(adefos)

- 属性定義が、宛先ディレクトリにのみ存在(adefod)

- ソースおよび宛先ディレクトリで異なる属性定義(adefdif)

43.4.2 oidcmprecでサポートされる操作

このツールは、5つの操作をサポートします。各操作は、エントリを比較し、競合を検出し、オプションで競合を解消します。操作は、競合の解消方法に違いがあります。操作は次のとおりです。

- 比較操作: 2つのディレクトリを比較し、変更をLDIFレコードとしてファイルに格納します。LDIFファイルは、宛先ディレクトリに適用でき、ソース・ディレクトリと同一にできます。ソース・ディレクトリ内のデータのみが有効とみなされます。

- 調整操作: 2つのディレクトリを比較し、宛先ディレクトリ側で、ソース・ディレクトリに一致させるために必要な変更を適用します。ディレクトリに対して加えられた変更はすべて、LDIF記録としてファイルに格納されます。ソース・ディレクトリ内のデータのみが有効とみなされます。

- マージまたは双方向調整操作: 2つのディレクトリを比較し、ソース・ディレクトリまたは宛先ディレクトリで、2つを一致させるために必要な変更を適用します。両ディレクトリのデータは有効とみなされます。たとえば、エントリが宛先ディレクトリにのみ存在することがツールにより検出された場合、ツールはこのエントリをソースに追加します。この操作ではまた、ディレクトリに加えられた変更をすべて、LDIFレコードとしてファイルに記録します。

- マージ・リハーサル操作: マージ操作と同様に2つのディレクトリを比較しますが、ディレクトリでの変更適用は行いません。かわりに、変更をLDIF記録としてファイルに格納します。ソース・ディレクトリと宛先ディレクトリに適用される変更は、2つの異なるファイルに格納されます。

- ユーザー定義の比較調整操作: 競合の例ごとに選択した競合解消規則を使用します。各競合の例に使用できる競合解消規則のリストは、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』を参照してください。

43.4.3 oidcmprecからの出力

oidcmprecツールは通常、複数の出力ファイルを生成します。oidcmprecのオプションを使用して、ファイルの生成を抑止できます。ファイルとこれに対応するオプションは次のとおりです。

- filename.rpt: 比較されたすべてのエントリの識別名と比較結果が含まれます。logrpt=falseを使用してこのファイルの生成を抑止します。

- filename.s2d.ldif: 宛先ディレクトリに適用された、または宛先ディレクトリに後から適用するために格納されたすべての変更が含まれます。名前は、宛先ディレクトリからソース・ディレクトリへの省略形です。logs2d=falseを使用してこのファイルの生成を抑止します。

- filename.d2s.ldif: ソース・ディレクトリに適用された、またはソース・ディレクトリに後から適用するために格納されたすべての変更が含まれます。名前は、宛先ディレクトリからソース・ディレクトリへの省略形です。logd2s=falseを使用してこのファイルの生成を抑止します。

- filename.eos.rpt: ソース・ディレクトリにのみ存在するエントリの識別名のリストが含まれます。スキーマが操作の対象に含まれている場合は、ソース・ディレクトリでのみ定義されている属性およびオブジェクト・クラスの名前のリストも含まれます。この名前は、ソース・ディレクトリでのみ使用可能なエントリの省略形です。logeos=falseを使用してこのファイルの生成を抑止します。

- filename.eod.rpt: 宛先ディレクトリにのみ存在するエントリの識別名のリストが含まれます。スキーマが操作の対象に含まれている場合は、宛先ディレクトリでのみ定義されている属性およびオブジェクト・クラスの名前のリストも含まれます。名前は、宛先ディレクトリでのみ使用可能なエントリの省略形です。logeod=falseを使用してこのファイルの生成を抑止します。

- filename.dif.rpt: 異なるすべてのエントリの識別名と、異なる属性の名前が含まれます。スキーマが操作の対象に含まれている場合は、定義が異なる属性およびオブジェクト・クラスの名前のリストも含まれます。このファイルはdifファイルと呼ばれます。logdif=falseを使用してこのファイルの生成を抑止します。

- filename.err: すべてのエラー・メッセージが含まれます。このファイルは、errファイルと呼ばれます。logerr=falseを使用してこのファイルの生成を抑止します。

ツールによってロードされたエントリの合計数およびoidcmprecの各キューのエントリの数をツールでダンプできます。エントリ数はファイルoidcmprec.logに記録されます。qlogfreq=frequency引数を使用してoidcmprecがこの情報を記録する頻度を指定します。使用できるfrequency値は1から5000です。値が小さいほど間隔が短くなります。頻度の高いエントリ数の場合5から10の値を使用します。

43.4.4 oidcmprecの動作

レプリケーション識別名とレプリケーション識別名パスワードを資格証明として使用して、ツールは3つのタスクを実行します。まず、スキーマ情報をメモリーにロードします。次に、比較対象のエントリを収集し、それらを属性ごとに比較します。ツールは、スキーマ情報を使用して、属性ごとに使用する比較規則を判断します。次に、比較結果に基づき、必要な処置を行います。これらの操作は、異なるスレッドによって実行されます。

- 識別名スレッドは、比較対象となるエントリを収集します。エントリの収集時に一度にツリー全体をフェッチすることはありません。最初にベース・エントリをフェッチして処理します。次に、ベース・エントリ直下の子をフェッチして処理し、さらにその下の子をフェッチして処理する、というように処理していきます。収集されたエントリはワーカー・スレッドに渡されます。識別名スレッドの数は、dnthreads引数を使用して制御できます。

- ワーカー・スレッドは、エントリを属性ごとに比較し、競合解消規則を適用する作業を担当します。ワーカー・スレッドは、その後、エントリをログ・ライター・スレッドに渡します。ワーカー・スレッドの数は、threads引数を使用して制御できます。ワーカー・スレッドと識別名スレッドの合計数は、6×(CPU数)- 2に相当する最大値以下です。これを超える値を指定すると、ツールは、ワーカー・スレッドと識別名スレッドの数を、最大値を超えないように調整します。

- ログ・ライター・スレッドは、第43.4.3項「oidcmprecからの出力」に示した7つの出力ファイルすべてへのコンテンツの書込みを担当します。ログ・ライター・スレッドは1つのみ存在します。この数は増やせません。

これらのスレッドは、メイン・スレッドによって生成、モニター、終了されます。メイン・スレッドは、コマンド行の引数とパラメータ・ファイルを処理し、別のスレッドを生成します。メイン・スレッドは、全操作の完了を検出すると、ただちにすべてのスレッドを終了し、接続をすべてクリーンアップします。

各スレッドは、ソース・ディレクトリと宛先ディレクトリへのLDAP接続を確立します。これらの接続は、すべての操作がスレッドによって完了されるまで、オープンのままです。なんらかの理由で接続がクローズされると、continueOnError引数がTRUEの場合、ツールは接続を再確立します。ツールが接続を再確立できると、操作を続行します。

注意:
continueOnError引数を使用して、ツールがエラーの処理を続行するかどうかを指定します。この引数は、TRUEにもFALSEにも設定できます。デフォルトでは、TRUEに設定されています。

43.4.5 ソース・ディレクトリと宛先ディレクトリの設定

sourceオプションとdestinationオプションを使用して、ソース・ディレクトリと宛先ディレクトリを設定します。

oidcmprec source=staqj13:3060 destination=staqj:3070 base="''" \
scope=subtree file=temp operation=compare

コマンド行でパスワードが指定されていないと、ツールがパスワードを要求します。

Enter replication DN password of the source directory     :
Enter replication DN password of the destination directory :

43.4.6 操作のDITの選択

base、dns2Excludeおよびscopeオプションを使用して、比較と調整の対象となる領域を選択します。

次の例では、c=us,dc=mycom,dc=comとc=uk,dc=mycom,dc=comを除く、ディレクトリ全体を比較します。

oidcmprec base="''" \
dns2exclude="'c=us,dc=mycom,dc=com' 'c=uk,dc=mycom,dc=com'" \
operation=compare scope=subtree \
source=myhost1.mycom.com:3060 \
destination=myhost2.mycom.com:3060 \
threads=5 dnthreads=2 file=cmpres

次の例では、c=us,dc=mycom,dc=comツリーとc=uk,dc=myorg,dc=orgツリーを除く、ネーミング・コンテキストdc=comおよびdc=orgを比較します。

oidcmprec base="'dc=com' 'dc=org'" \
dns2exclude="'c=us,dc=mycom,dc=com' 'c=uk,dc=myorg,dc=org'" \
operation=compare scope=subtree \
source=myhost1.mycom.com:3060 \
destination=myhost2.mycom.com:3060 \
threads=5 dnthreads=2 file=cmpres

43.4.7 操作属性の選択

デフォルトでは、oidcmprecは、操作属性のcreatorsname、createtimestamp、modifiersname、modifytimestamp、orclentrydnおよびorclnormdnを除くすべての属性を比較します。選択した操作に含める、または操作から除外する属性は、それぞれexcludedAttributesまたはincludedAttributesを使用して制御できます。excludedAttributes引数とincludedAttributes引数により、パターン一致を制限できます。 attributename*を使用すれば、attributenameで始まるすべての属性を一致させることができます。attributename;*を使用すれば、attributenameのすべてのサブタイプも一致させることができます。

次の例では、標準の除外属性に加えて、authpassword属性(サブタイプのあるものとないもの)、さらにuserpassword属性とcategory属性を除外します。

oidcmprec operation=compare scope=subtree base="'dc=com' 'dc=org'" \
source=myhost1.mycom.com:3060\
destination=myhost2.mycom.com:3060 \
exclattr="authpassword authpassword;* userpassword category" \
threads=5 dnthreads=2 file=compare

次の例では、比較操作に属性uid、cn、sn、givennameおよびmailのみを含めます。

oidcmprec operation=compare scope=subtree base="'dc=com'" \
source=myhost1.mycom.com:3060 \
destination=myhost2.mycom.com:3060 \
inclattr="uid cn sn givenname mail" \
file=compare

次の例では、orclguid、creatorsnameおよびmodifiersnameを除き、比較操作の対象となるすべての属性を含めます。この例ではまた、continueOnError=falseを設定することで、エラーが発生したら停止するように、ツールに指示しています。

oidcmprec operation=compare scope=subtree base="'dc=com'" \
source=myhost1.mycom.com:3060 \
destination=myhost2.mycom.com:3060 \
inclattr="*" exclattr="orclguid creatorsname modifiersname" \
file=compare contonerr=false

43.4.8 変更ログ生成の制御

oidcmprecによって加えられた変更に対する変更ログの生成は、ルートDSEのorcldiprepository属性によって決まります。ただし、変更ログ生成の動作は、generateChangeLog引数を使用することで制御できます。generateChangeLog引数には、次の値を指定できます。

- default: ディレクトリ・サーバーの設定により、変更ログが生成されるかどうかが決まります。ルート・エントリのorcldiprepository属性がtrueに設定されている場合は、変更ログが生成されます。orcldiprepositoryがfalseに設定されている場合は、生成されません。ソース・ディレクトリと宛先ディレクトリの両方に同じルールが適用されます。defaultが、gechglogのデフォルト値です。

- true: ソース・ディレクトリと宛先ディレクトリに対する設定に関係なく、変更ログは常に生成されます。

- false: ソース・ディレクトリと宛先ディレクトリに対する設定に関係なく、変更ログは常に生成されません。

次の例では、generateChangeLog falseで、変更ログの生成を停止します。

oidcmprec operation=merge scope=subtree base="'dc=com'" \
source=myhost1.mycom.com:3060 \
destination=myhost2.mycom.com:3060 \
inclattr="*" exclattr="orclguid creatorsname modifiersname" \
file=merge genchglog=false

43.4.9 テキストまたはXMLパラメータ・ファイルの使用

パラメータ・ファイルでoidcmprecコマンド行引数を指定することもできます。parameterFileオプションを使用してテキスト・パラメータ・ファイルを指定するか、xmlparameterFileオプションを使用してXMLパラメータ・ファイルを指定します。コマンド行とパラメータ・ファイルの両方で引数を指定した場合、コマンド行で指定した引数が、パラメータ・ファイルで指定した引数に優先します。次に例を示します。

oidcmprec paramfile=comp_param threads=4

この例では、次のサンプル・テキスト・パラメータ・ファイルを使用します。

#############################################
#Parameter file for compare and reconcile tool
#Creator   : Admin
#Date      : 21-Mar-2012
#File Name : comp_param
#############################################
operation=compare
source=staqj13:3060/ods
destination=staqj13:3070/ods
base='("cn=oraclecontext" "c=uk,dc=example,dc=com" "c=us,dc=example,dc=com")'
verbose=false
force=true
threads=6
dnthreads=2
exclattr=orclguid userpassword authpassword;*
filename=cmp2012Feb01

この例では、ツールにより4つのワーカー・スレッドが生成され、コマンド行引数が優先されます。

次のXMLパラメータ・ファイルは、サンプル・テキスト・パラメータ・ファイルと同等です。

<?xml version="1.0" standalone="yes" ?>
- <input>
<operation>compare</operation>
- <source>
<host>staqj13</host>
<port>3060</port>
<binddn>cn=orcladmin</binddn>
<password>source-password</password>
</source>
- <destination>
<host>staqj13</host>
<port>3070</port>
<binddn>cn=orcladmin</binddn>
<password>destination-password</password>
</destination>
<base>
<dn>cn=oraclecontext</dn>
<dn>c=uk,dc=example,dc=com</dn>
<dn>c=us,dc=example,dc=com</dn>
</base>
<threads>6</threads>
<dnthreads>2</dnthreads>
<exclattr>
<attribute>orclguid</attribute>
<attribute>userpassword</attribute>
<attribute>authpassword</attribute>
<exclattr/>
<force>true</force>
<verbose>false</verbose>
<filename>cmp2012Feb01</filename>
</input>

43.4.10 ディレクトリ・スキーマの包含

ベース引数にcn=subschemasubentryを含めると、oidcmprec操作の対象にスキーマを含めることができます。次に例を示します。

oidcmprec operation=merge scope=subtree \
base="'dc=com' 'cn=subschemasubentry'" \
source=myhost1.mycom.com:3060 \
destination=myhost2.mycom.com:3060 \
inclattr="*" exclattr="orclguid creatorsname modifiersname" \
file=merge genchglog=false

スキーマに加えてその他の識別名を含めた場合、oidcmprecは、最初にスキーマで操作を実行します。

43.4.11 事前に定義された競合解消規則の無視

各操作の競合の例と競合解消規則の詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のoidcmprecコマンド・リファレンスを参照してください。

競合名と、コマンド行またはパラメータ・ファイルで使用する規則を指定することにより、事前に定義された競合解消規則を無視できます。次の例では、競合dndifおよびmvatrdifに使用される競合解消規則を、compare操作に対してignoreに変更します。

oidcmprec operation=compare source=host1:3060 destination=host2:3070 \
base="''" scope=subtree file=temp operation=compare \
dndif=ignore mvatrdif=ignore

43.4.12 ユーザー定義の比較調整操作の使用

事前に定義されたcompare、reconcile、mergeおよびmerge dry run操作に加えて、oidcmprecにはユーザー定義の比較調整操作userdefinedcrがあり、競合解消規則引数を指定できます。-userdefinedcrで指定しない競合解消規則はすべて、デフォルトがignoreに設定されます。次のコマンド行では、userdefinedcr操作を使用しています。

oidcmprec operation=userdefinedcr scope=subtree \
base="'dc=com' 'dc=org'" \
source=myhost1.mycom.com:3060 \
destination=myhost2.mycom.com:3060 \
entos=add entod=ignore atros=add atrod=ignore \
svatrdif=usesrc mvatrdif=usesrc dndif=ignore \
threads=5 dnthreads=2 file=myreconcile

競合の例と競合解消規則の詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のoidcmprecコマンド・リファレンスを参照してください。

43.4.13 oidcmprecツールの既知の制限事項

oidcmprecツールには、次の制限事項があります。

- LDIFレコードに対する変更をツリーの削除のためにfilename.s2d.ldifまたはfilename.d2s.ldifファイルに記録する際、ツールはまず親レコードを記録し、次にその子のレコードを記録します。ldapmodifyコマンド行ツールを使用してこの変更を適用しようとすると、ディレクトリ・サーバーではリーフのないエントリの削除が許可されていないため、変更の適用は失敗します。ldapmodifyの失敗を防ぐには、ldapmodifyを実行する前に、ファイルを編集してレコードの順序を並べ替えます。

- エントリに対して削除操作を実行する際、ツールはそのエントリとその子を削除します。ツールにより、エントリが削除されたことは記録されますが、その子も削除されたことは記録されません。

- ツールには、複合相対識別名に関する制限があります。相対識別名には、次の例のように+で区切られた2つ以上のattribute=attrvalueペアがあります。

uid=jpaul + cn=john paul + mail=john.paul@example.com,dc=oracle,dc=com

比較対象のディレクトリの1つに複合相対識別名が含まれている場合、ツールが推奨するfilename.s2d.ldifまたはfilename.d2s.ldifファイルのmodrdn/moddnの変更でdeleteoldrdn値が正しくないことがあります。

- oidcmprecにフィルタを指定し、出力をldapmodifyの入力として使用する場合、まず出力を編集してエントリが正しい順序かどうかを確認します。特に、ツリー全体を移行する場合、ツリーのルートが最初のエントリであることを確認します。

第VI部

拡張管理: ディレクトリ・プラグイン

次の各章で構成されています。

- 第45章「Oracle Internet Directoryサーバーのプラグインの開発」

- 第44章「カスタマイズされたパスワード・ポリシー・プラグインの構成」

- 第46章「カスタマイズされた外部認証プラグインの構成」

44 カスタマイズされたパスワード・ポリシー・プラグインの構成

この章では、Oracle Internet Directoryでプラグインを使用して、パスワード値のチェックを他のパスワード・ポリシー管理機能に追加する方法について説明します。具体的には、カスタマイズされたパスワード・ポリシー・プラグインをインストール、構成および有効化する方法について説明します。

このプラグインを使用すると、追加または変更されたパスワードが、指定された最小文字数以上であるかどうかなどを確認できます。個別の要件に合せて、パスワード値チェックをカスタマイズできます。

この章の内容は次のとおりです。

- 第44.1項「カスタマイズされたパスワード・ポリシー・プラグインの構成の概要」

- 第44.2項「カスタマイズされたパスワード・ポリシー・プラグインのインストール、構成および有効化」

44.1 カスタマイズされたパスワード・ポリシー・プラグインの構成の概要

パスワードを追加または変更する場合、カスタマイズされたパスワード値チェックが次のように処理されます。

1. クライアントが、ldapaddリクエストまたはldapmodifyリクエストをディレクトリ・サーバーに送信します。

2. ディレクトリ・サーバーは、追加または変更を行う前にパスワード値をプラグインに渡します。

3. プラグインは次のように動作します。

1. エントリを解析

2. クリア・テキストのuserpassword属性値を取得

3. 指定したパスワード値チェックを実施

4. パスワードが指定と一致する場合は、そのことがプラグインによってディレクトリ・サーバーに通知され、ディレクトリ・サーバーによって追加または変更が行われます。
それ以外の場合は、次のいずれかのエラー・メッセージがプラグインによってディレクトリ・サーバーに送信され、その後、ディレクトリ・サーバーからクライアントに渡されます。

ldap_add: UnKnown Error Encountered
ldap_add: additional info: PASSWORD POLICY VIOLATION:0000X, less than 8 chars

ldap_add: UnKnown Error Encountered
ldap_add: additional info: PASSWORD POLICY VIOLATION:0000X, contains dictionary word

同じロジックがPRE ldapmodifyプラグインにも適用されます。

パスワード・ポリシー・プラグインが実行できる値チェックには、次のような種類があります。

- アルファベットの最大および最小文字数

- 数字の最大文字数

- 記号の最大および最小文字数

- 連続した文字の最大文字数

- 任意の文字の最大インスタンス数

- 辞書の語句かどうかの確認

44.2 カスタマイズされたパスワード・ポリシー・プラグインのインストール、構成および有効化

この例は、PL/SQLプログラムpluginpkg.sqlを使用しています。第44.2.4項「サンプルPL/SQLパッケージpluginpkg.sqlの内容」でこのプログラムについて説明します。通常、このパッケージには次のものが含まれます。

- プラグイン・モジュール: pre_addおよびpre_modify

- パスワードが最小文字数要件の8文字を満たしていること、および4文字よりも長い辞書の語句を含んでいないことを確認する値チェック・ファンクションisGoodPwd

この例では、ユーザーが8文字未満のuserpassword値を入力すると、リクエストは拒否されます。同様に、ユーザー・パスワードを変更する際に、新しいパスワード値が8文字未満の場合はリクエストが拒否されます。また、userpasswordの値supersundayを使用してユーザー・パスワードを登録または変更しようとすると、superおよびsundayが辞書にあるため、そのパスワードは拒否されます。

辞書は、4文字を超える語句のリストで、最初はファイルwords.txtに格納されます。プラグインを実装する前に、データベース表を設定して語句を格納します。表を設定するには、create.sqlを使用します。内容は次のとおりです。

drop table mydic;
create table mydic (word varchar2(1024));
commit;
exit;

続いて、次のsqlldrコマンドを使用して語句を表に格納します。

sqlldr control=words.txt userid=ods/ods_password

この項の項目は次のとおりです。

- 第44.2.1項「PL/SQLプログラムのロードおよび登録」

- 第44.2.2項「パスワード・ポリシー・プラグインのコード化」

- 第44.2.3項「パスワード・ポリシー・プラグインのデバッグ」

- 第44.2.4項「サンプルPL/SQLパッケージpluginpkg.sqlの内容」

44.2.1 PL/SQLプログラムのロードおよび登録

スタンドアロンの値チェックPL/SQLプログラムを実装したら、次の手順を実行します。

1. プラグイン・パッケージをデータベースにロードします。この例では、次のように入力します。

sqlplus ods @pluginpkg.sql

2. プラグインを登録します。この例では、次の内容のファイルpluginreg.datを使用します。

### add plugin ###
dn: cn=pre_add_plugin,cn=plugin,cn=subconfigsubentry
objectclass:orclPluginConfig
objectclass:top
orclpluginname:pwd_plugin
orclplugintype:operational
orclplugintiming:pre
orclpluginldapoperation:ldapadd
orclpluginenable:1
orclpluginversion:1.0.1
cn:pre_add_plugin
orclpluginsubscriberdnlist:dc=com;o=IMC ,c=US

### modify plugin ###
dn: cn=pre_mod_plugin,cn=plugin,cn=subconfigsubentry
objectclass:orclPluginConfig
objectclass:top
orclpluginname:pwd_plugin
orclplugintype:operational
orclplugintiming:pre
orclpluginldapoperation:ldapmodify
orclpluginenable:1
orclpluginversion:1.0.1
cn:pre_mod_plugin
orclpluginsubscriberdnlist:dc=com;o=IMC ,c=US
orclpluginattributelist:userpassword

このプラグインでは、ldapaddリクエストまたはldapmodifyリクエストを受け取った際に起動する2つのプラグイン・モジュールをディレクトリ・サーバーに認識させています。ターゲット・エントリがdc=comまたはo=IMC,c=US下の場合のみプラグインが起動するように、orclpluginsubscriberdnlist:dc=com;o=IMC,c=USを使用しています。

このファイルをディレクトリに追加するには、次のとおり入力します。

ldapadd -p portnum -h hostname -D cn=orcladmin -q -v -f pluginreg.dat

44.2.2 パスワード・ポリシー・プラグインのコード化

標準PL/SQL文字ファンクションを使用して、パスワード値を処理できます。正規表現を行うPL/SQLプログラムをダウンロードします。値チェック・ファンクションとプラグイン・モジュールを統合することが重要です。

44.2.3 パスワード・ポリシー・プラグインのデバッグ

ディレクトリ・サーバー・プラグインを設定すると、プラグインのプロセスと内容を調べることができます。

ディレクトリ・サーバー・プラグインのデバッグを設定するには、次のコマンドを実行します。

sqlplus ods @$ORACLE_HOME/ldap/admin/oidspdsu.pls

ディレクトリ・サーバー・プラグインのデバッグを有効にするには、次のコマンドを実行します。

sqlplus ods @$ORACLE_HOME/ldap/admin/oidspdon.pls

ディレクトリ・サーバー・プラグインのデバッグを無効にするには、次のコマンドを実行します。

sqlplus ods @$ORACLE_HOME/ldap/admin/oidspdof.pls

ディレクトリ・サーバー・プラグインのデバッグ・メッセージを表示するには、次のコマンドを実行します。

sqlplus ods @$ORACLE_HOME/ldap/admin/oidspdsh.pls

ディレクトリ・サーバー・プラグインのデバッグ・メッセージを削除するには、次のコマンドを実行します。

sqlplus ods @$ORACLE_HOME/ldap/admin/oidspdde.pls

44.2.4 サンプルPL/SQLパッケージpluginpkg.sqlの内容

この例で使用するスクリプトpluginpkg.sqlの内容は次のとおりです。

CREATE OR REPLACE PACKAGE pwd_plugin AS

PROCEDURE pre_add (ldapplugincontext IN  ODS.plugincontext,
dn       IN  VARCHAR2,
entry    IN  ODS.entryobj,
rc       OUT INTEGER,
errormsg OUT VARCHAR2
);

PROCEDURE pre_modify (ldapplugincontext IN  ODS.plugincontext,
dn       IN  VARCHAR2,
mods     IN  ODS.modlist,
rc       OUT INTEGER,
errormsg OUT VARCHAR2
);

-- Function: isGoodPwd
-- Parameter: inpwd
-- Purpose: 1. check if the password is at least
--          8 characters long
--          2. check if the password contains a
--          dictionary word (longer than 4 characters)

FUNCTION isGoodPwd(inpwd IN VARCHAR2)
RETURN INTEGER;

END pwd_plugin;
/

show error

CREATE OR REPLACE PACKAGE BODY pwd_plugin AS

FUNCTION isGoodPwd(inpwd IN VARCHAR2)
RETURN INTEGER
IS
i NUMBER;
ret NUMBER DEFAULT 1;
minpwdlen NUMBER DEFAULT 8;
len       NUMBER DEFAULT 0;
lcount    NUMBER DEFAULT 0;
matched   VARCHAR2(1024) DEFAULT NULL;

CURSOR c1 IS
SELECT word FROM mydic WHERE length(word) > 4
AND instr(lower(inpwd), lower(word), 1, 1) > 0;

BEGIN
plg_debug( '=== begin of ISGOODPWD ===');
plg_debug( 'password = ' || inpwd);
len := LENGTH(inpwd);
plg_debug( 'password length = ' || len);

IF len < minpwdlen THEN
RETURN 0;
ELSE
OPEN c1;
LOOP
FETCH c1 INTO matched;
EXIT WHEN c1%NOTFOUND;
lcount := lcount + 1;
END LOOP;
plg_debug( 'count = ' || lcount);
IF lcount > 0 THEN
RETURN 2;
ELSE
RETURN ret;
END IF;
END IF;

plg_debug( '=== end of ISGOODPWD ===');

EXCEPTION
WHEN OTHERS THEN
plg_debug( 'Exception in isGoodPwd(). Error code is ' || TO_CHAR(SQLCODE));
plg_debug( '   ' || Sqlerrm);
RETURN 0;
END;

PROCEDURE pre_add (ldapplugincontext IN  ODS.plugincontext,
dn       IN  VARCHAR2,
entry    IN  ODS.entryobj,
rc       OUT INTEGER,
errormsg OUT VARCHAR2
)
IS
inpwd VARCHAR2(256) DEFAULT NULL;
ret   NUMBER        DEFAULT 1;
BEGIN
plg_debug( '=== begin of PRE_ADD_PLUGIN ===');
plg_debug( 'dn = ' || dn);

plg_debug( 'entry obj ' || ':entryname = ' || entry.entryname);

FOR l_counter1 IN 1..entry.attr.COUNT LOOP
plg_debug( 'attrname[' || l_counter1 || '] = ' ||
entry.attr(l_counter1).attrname);
FOR l_counter2 IN 1..entry.attr(l_counter1).attrval.COUNT LOOP
plg_debug( entry.attr(l_counter1).attrname ||
'[' || l_counter1 || ']' ||
'.val[' || l_counter2 || '] = ' ||
entry.attr(l_counter1).attrval(l_counter2));
END LOOP;

IF entry.attr(l_counter1).attrname = 'userpassword' THEN
inpwd := entry.attr(l_counter1).attrval(1);
-- assuming only one attr val for userpassword
END IF;

END LOOP;

IF (inpwd IS NOT NULL) THEN
ret := isGoodPwd(inpwd);
END IF;

IF (inpwd IS NULL OR ret = 0) THEN
rc := 1;
errormsg := 'PASSWORD POLICY VIOLATION:0000X, less than 8 chars';
plg_debug( ' we got an invalid password, too short ');
ELSIF (ret = 2) THEN
rc := 1;
errormsg := 'PASSWORD POLICY VIOLATION:0000X, contains dictionary word';
plg_debug( ' we got an invalid password, dictionary word ');
ELSE
plg_debug( ' we got a good password ');
rc := 0;
errormsg := 'no pre_mod plguin error msg';
END IF;

plg_debug( '=== end of PRE_ADD_PLUGIN ===');

EXCEPTION
WHEN OTHERS THEN
plg_debug( 'Exception in PRE_ADD plugin. Error code is ' || TO_CHAR(SQLCODE));
plg_debug( '   ' || Sqlerrm);
rc := 1;
errormsg := 'exception: pre_add plguin';
END;

PROCEDURE pre_modify (ldapplugincontext IN  ODS.plugincontext,
dn       IN  VARCHAR2,
mods     IN  ODS.modlist,
rc       OUT INTEGER,
errormsg OUT VARCHAR2
)
IS
old_passwd VARCHAR2(256) DEFAULT NULL;
new_passwd VARCHAR2(256) DEFAULT NULL;
ret        NUMBER        DEFAULT 1;

BEGIN
plg_debug( '=== begin of PRE_MOD_PLUGIN ===');
plg_debug( dn);

FOR l_counter1 IN 1..mods.COUNT LOOP
IF (mods(l_counter1).operation = 2) AND
(mods(l_counter1).type = 'userpassword') THEN

FOR l_counter2 IN 1..mods(l_counter1).vals.COUNT LOOP
new_passwd := mods(l_counter1).vals(l_counter2).val;
END LOOP;
END IF;

IF (mods(l_counter1).operation = 0) AND
(mods(l_counter1).type = 'userpassword') THEN

FOR l_counter2 IN 1..mods(l_counter1).vals.COUNT LOOP
new_passwd := mods(l_counter1).vals(l_counter2).val;
END LOOP;
END IF;

IF (mods(l_counter1).operation = 1) AND
(mods(l_counter1).type = 'userpassword') THEN

FOR l_counter2 IN 1..mods(l_counter1).vals.COUNT LOOP
old_passwd := mods(l_counter1).vals(l_counter2).val;
END LOOP;
END IF;
END LOOP;

plg_debug(' new password: ' || new_passwd);
plg_debug(' old password: ' || old_passwd);

IF (new_passwd IS NOT NULL) THEN
ret := isGoodPwd(new_passwd);
END IF;

IF (new_passwd IS NULL OR ret = 0) THEN
rc := 1;
errormsg := 'PASSWORD POLICY VIOLATION:0000X, less than 8 chars';
plg_debug( ' we got an invalid password, too short ');
ELSIF (ret = 2) THEN
rc := 1;
errormsg := 'PASSWORD POLICY VIOLATION:0000X, contains dictionary word';
plg_debug( ' we got an invalid password, dictionary word ');
ELSE
plg_debug( ' we got a good password ');
rc := 0;
errormsg := 'no pre_mod plguin error msg';
END IF;

plg_debug( '=== end of PRE_MOD_PLUGIN ===');

EXCEPTION
WHEN OTHERS THEN
plg_debug( 'Exception in PRE_MODIFY plugin. Error code is ' || TO_CHAR(SQLCODE));
plg_debug( '   ' || Sqlerrm);
rc := 1;
errormsg := 'exception: pre_mod plguin';
END;

END pwd_plugin;
/
show error

EXIT;

45 Oracle Internet Directoryサーバー・プラグインの開発

この章では、Oracle Internet Directoryサーバー・プラグインと、Oracle Internet Directoryのプラグイン・フレームワークの概要について説明します。具体的には、プラグインを作成する方法、LDAPコマンド行ユーティリティを使用してプラグインを登録する方法、Oracle Directory Services Manager (ODSM)およびOracle Enterprise Manager Fusion Middleware Controlを使用してプラグインを管理する方法について説明します。

この章の内容は次のとおりです。

- 第45.1項「Oracle Internet Directoryサーバー・プラグインの開発の概要」

- 第45.2項「プラグインの作成」

- 第45.3項「コマンド行でのプラグインの登録」

- 第45.4項「Oracle Directory Services ManagerおよびOracle Enterprise Manager Fusion Middleware Controlを使用したプラグインの管理」

45.1 Oracle Internet Directoryサーバー・プラグインの開発の概要

サーバー・プラグインは、Oracle Internet Directoryサーバーの機能拡張に使用されるカスタマイズされたプログラムです。サーバー・プラグインは、PL/SQLパッケージ、Javaプログラムまたはパッケージ、共有オブジェクトまたはライブラリ、Windows上のダイナミック・リンク・ライブラリのいずれにもできます。各プラグインには構成エントリがOracle Internet Directoryサーバーにあります。構成エントリでは、プラグイン起動の条件が指定されます。プラグイン起動の条件には次のようなものがあります。

- LDAP操作(ldapbind、ldapmodifyなど)

- LDAP操作に関連したタイミング(pre_bind、post_modifyなど)

ディレクトリ・サーバーのプラグインは、次のような機能をディレクトリ・サーバーに追加します。

- ディレクトリ・サーバーによる操作実行前のデータの妥当性チェック

- サーバーによる操作実行後の指定処理の実行

- パスワード・ポリシーの定義

- 外部に格納された資格証明によるユーザーの認証

起動時に、ディレクトリ・サーバーはプラグイン構成およびライブラリをロードします。その後、リクエストを処理するときに、指定されたイベントが発生した場合は常に、プラグイン・ファンクションをコールします。

図45-1に、LDAPクライアントが個々のアプリケーションを使用して行う、Oracleディレクトリ・サーバーとの間の情報の送受信について示します。同様に、プラグイン構成ツールもディレクトリ・サーバーに情報を送信します。ディレクトリ・サーバーはデータをプラグイン・モジュール1、プラグイン・モジュール2およびプラグイン・モジュール3に送信します。各プラグイン・モジュールはプラグイン・モジュール・インタフェースとプラグイン・ロジックを備えています。各プラグイン・モジュールは、LDAP APIおよびプラグインLDAPとの間の情報の送受信を行います。

図45-1 Oracle Internet Directoryプラグイン・フレームワーク

通常のディレクトリ・サーバー操作の前後に実行するか、操作に追加して実行するかによって、プラグインが実行する作業は異なります。次の項では、様々な種類の操作ベースのプラグインについて説明します。

45.1.1 JVMへのオプション渡し

Javaサーバー・プラグインは、oidldapdサーバー自体の内部にあるJava仮想マシン(JVM)で実行されます。JVMは、Java Native Interface(JNI)を使用して実装されます。oidldapdサーバーは、JVMを起動するときにオプションをJVMに渡します。これらのJVMオプションは、DSA構成エントリのorcljvmoptions属性の中に含まれています。デフォルトでは、この属性の値は-Xmx64Mで、64MBのヒープ・サイズが指定されます。orcljvmoptionsの値を変更して、これらのオプションを変更できます。通常、これを行う必要があるのは、デフォルトの64Mを超えるヒープ・サイズを必要とするプラグインを追加する場合のみです。

DSA構成エントリのその他の属性と同じ方法で、またはOracle Enterprise Manager Fusion Middleware Controlを使用して、この属性を変更できます。詳細は、第9.4項「LDAPツールを使用したシステム構成属性の管理」および第45.4.5項「Oracle Enterprise Manager Fusion Middleware Controlを使用したJVMオプションの管理」を参照してください。

45.1.2 サーバー・プラグインの言語のサポート

10g (10.1.4.0.1)では、Oracle Internet Directoryは、JavaとPL/SQLのプラグインをサポートしています。この章では、JavaおよびPL/SQLプラグインに共通する情報について説明します。付録FではPL/SQLプラグインに固有の追加情報を示し、付録EではJavaプラグインに固有の追加情報を示します。

45.1.3 サーバー・プラグインの前提条件

Oracle Internet Directoryプラグインを開発するには、次の事項をよく理解している必要があります。

- 一般的なLDAPの概念

- Oracle Internet Directory

- Oracle Internet DirectoryとOracle Application Serverの統合

次のいずれかの分野のプログラミング・スキルを備えている必要があります。

- SQL、PL/SQLおよびデータベースRPC

- Java

45.1.4 サーバー・プラグインの利点

プラグインを使用してLDAP操作を拡張するには、次のような方法があります。

- サーバーによるデータに対するLDAP操作の実行前に、データの妥当性をチェックできます。

- サーバーがLDAP操作を正常に終了した後で、定義した処置を実行できます。

- 拡張操作を定義できます。

- 外部に格納された資格証明を介してユーザーを認証できます。

- 既存のサーバー・モジュールを独自のサーバー・モジュールに置換できます。

起動時に、ディレクトリ・サーバーはプラグイン構成およびライブラリをロードします。様々なLDAPリクエストの処理中にプラグイン・ファンクションをコールします。

関連項目:
『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のパスワード・ポリシー・プラグインに関する章。この章には、独自のパスワード値チェックを実装して、Oracle Internet Directoryサーバーに配置する方法の例が用意されています。

45.1.5 プラグイン設計のガイドライン

プラグイン設計時は、次のガイドラインを参考にします。

- プラグインを使用して、特定のLDAP操作が確実に実行され、関連アクションも確実に実行されるようにします。

- プラグインは、プログラム本体の文をどのユーザーやLDAPアプリケーションが発行したかに関係なく、その文に対して起動される、一元化されたグローバル操作にのみ使用します。

- 再帰プラグインは作成しないでください。たとえば、それ自体がldapbind文を発行するpre_ldap_bindプラグインを作成すると、リソースが不足するまでこのプラグインが再帰的に実行されるようになります。
プラグインは慎重に使用してください。プラグインは、関連するLDAP操作が発生するたびに実行されます。

45.1.6 サーバー・プラグイン・フレームワーク

プラグイン・フレームワークとは、プラグインを開発、構成および適用する環境です。個々のプラグイン・インスタンスは、プラグイン・モジュールと呼びます。

プラグイン・フレームワークには、次のものが含まれます。

- プラグイン構成ツール

- プラグイン・モジュール・インタフェース

- プラグインLDAP API

- PL/SQLパッケージODS.LDAP_PLUGIN

- Javaパッケージoracle.ldap.ospf

どちらの言語の場合も、次の一般的手順に従い、サーバー・プラグイン・フレームワークを使用します。

1. ユーザー定義プラグイン・プロシージャをPL/SQLまたはJavaで作成します。

2. プラグイン・モジュールをコンパイルします。

3. コマンド行またはOracle Directory Services Managerのいずれかを使用し、構成エントリ・インタフェースを介して、プラグイン・モジュールを登録します。

45.1.7 ディレクトリでサポートされているLDAP操作およびタイミング

Oracle Internet Directoryサーバーでは、次のLDAP操作のプラグインをサポートしています。

- ldapadd

- ldapbind

- ldapcompare

- ldapdelete

- ldapmoddn (Javaのみ)

- ldapmodify

- ldapsearch

Oracle Internet Directoryでは、プラグインに対して4つの操作タイミングをサポートしています。

- 前

- 後

- 操作時

- 操作時置換

これらについては、この後の4項で説明します。

45.1.7.1 操作前サーバー・プラグイン

サーバーは、LDAP操作の実行前に、操作前プラグイン・モジュールをコールします。このタイプのプラグインの主な目的は、データがLDAP操作で使用される前に、データを検証することです。

操作前プラグインで例外が発生すると、次のいずれかが発生します。

- 戻りエラー・コードが警告のステータスを示したとき、関連のLDAPリクエストは続行します。

- 戻りコードが失敗ステータスを示すと、リクエストは続行されません。

関連のLDAPリクエストが後で失敗すると、ディレクトリではプラグイン・モジュールでコミットされたコードをロールバックしません。

45.1.7.2 操作後サーバー・プラグイン

Oracle Internet Directoryサーバーは、LDAP操作の実行後に、操作後プラグイン・モジュールをコールします。このタイプのプラグインの主な目的は、特定のLDAP操作が実行された後に、ファンクションを起動することです。たとえば、ロギングや通知は、操作後プラグイン・ファンクションです。

操作後プラグインで例外が発生すると、関連のLDAP操作はロールバックされません。

関連のLDAPリクエストが失敗しても、操作後プラグインはそのまま実行されます。

45.1.7.3 操作時サーバー・プラグイン

ディレクトリは、標準のLDAP操作の実行中に、操作時プラグイン・モジュールをコールします。操作時プラグインは、操作に対するサーバー自身のコードの直前に実行されます。このタイプのプラグインの主な目的は、同じLDAPトランザクション内で既存の操作を強化することです。操作時プラグインが失敗すると、標準のLDAP操作は実行されません。操作時プラグインが正常に完了しても、標準のLDAP操作が失敗すると、プラグインで加えられた変更はロールバックされません。

たとえば、ldapcompare操作とともに操作時プラグインを使用できます。ディレクトリでは、ディレクトリ自身のサーバー比較コードを実行し、プラグイン開発者によって定義されたプラグイン・モジュールを実行します。

PL/SQL操作時プラグインは、ldapadd、ldapdeleteおよびldapmodifyでサポートされています。Java操作時プラグインは、ldapadd、ldapdelete、ldapmoddn、ldapmodifyおよびldapsearchでサポートされています。

45.1.7.4 操作時置換サーバー・プラグイン

操作時置換プラグインは、操作に対するサーバー自身のコードのかわりに実行されます。たとえば、ldapcompare操作とともに操作時置換プラグインを使用できます。ディレクトリでは、ディレクトリ自身の比較コードは実行されません。かわりに、比較の実行はプラグイン・モジュールに任せます。

PL/SQL操作時置換プラグインは、ldapadd、ldapcompare、ldapdelete、ldapmodifyおよびldapbindでのみサポートされています。

Java操作時置換プラグインは、ldapadd、ldapbind、ldapcompare、ldapdelete、ldapmoddn、ldapmodifyおよびldapsearchでサポートされています。

45.1.8 レプリケーション環境でのプラグインの使用

レプリケーション環境にプラグインをデプロイする際は注意してください。次のような誤った手法により一貫性のない状態になる場合があります。

- 他のノードへのプラグイン・メタデータのレプリケート

- 一部のメンバー・ノードへのプラグインのインストール

- ディレクトリ・データに依存する追加チェックのプラグインへの組込み

- プラグイン・プログラムまたはLDAP操作別のディレクトリ・エントリの変更

すべてのノードにプラグインをデプロイして、レプリケーションによる変更でプラグインが起動されないように構成した場合は、レプリケーション環境のディレクトリ・エントリを変更するプラグインを使用できます。この手順は次のとおりです。

- すべてのノードのレプリカIDをグループに追加します。

- プラグイン属性のorclpluginrequestneggroup値としてグループをインクルードします。次に例を示します。

orclpluginrequestneggroup: cn=pluginNegate,cn=groups,cn=oraclecontext.

変更リクエストがグループcn=pluginNegateのメンバーから発生していることがプラグインによって検出された場合、常にこのプラグインは起動されません。

45.2 プラグインの作成

次の一般的な手順に従い、サーバー・プラグイン・フレームワークを使用します。

1. ユーザー定義プラグイン・プロシージャをPL/SQLまたはJavaで作成します。

2. プラグイン・モジュールをコンパイルします。

3. コマンド行またはOracle Directory Services Managerのいずれかを使用し、構成エントリ・インタフェースを介して、プラグイン・モジュールを登録します。

45.3 コマンド行でのプラグインの登録

ディレクトリ・サーバーが適時にプラグインをコールできるように、プラグインをディレクトリ・サーバーに登録する必要があります。登録するには、cn=plugin,cn=subconfigsubentryの下のディレクトリ・スキーマにプラグインのエントリを作成します。

45.3.1 プラグイン構成エントリの作成

表45-1に、プラグイン構成で指定できるオブジェクト・クラスおよび属性とその説明を示します。

表45-1 プラグイン構成オブジェクトおよび属性

名前

値

必須

objectclass

orclPluginConfig

はい

objectclass

top

いいえ

dn

プラグイン・エントリ識別名

はい

cn

プラグイン・エントリ名

はい

orclPluginAttributeList

プラグインの実行を制御する、セミコロンで区切られた属性名のリスト。ターゲット属性がリストに含まれている場合は、プラグインが呼び出されます。ldapcompareプラグインおよびldapmodifyプラグインにのみ有効です。

いいえ

orclPluginEnable

0 = 無効(デフォルト)

1 = 有効

いいえ

orclPluginEntryProperties

ldapsearchフィルタ・タイプ値。たとえば、orclPluginEntryProperties: (&(objectclass=inetorgperson)(sn=Cezanne))と指定すると、ターゲット・エントリにinetorgpersonに等しいobjectclassと、Cezanneに等しいsnがある場合、プラグインは起動されません。

いいえ

orclPluginIsReplace

0 = 無効(デフォルト)

1 = 有効

when_replaceタイミングの場合、これを有効にして、orclPluginTimingをwhenに設定します。

いいえ

orclPluginKind

PL/SQLまたはJava(デフォルトはPL/SQL)

いいえ

orclPluginLDAPOperation

次のいずれかの値です。

ldapcompare

ldapmodify

ldapbind

ldapadd

ldapdelete

ldapsearch

ldapmoddn (Javaのみ)

はい

orclPluginName

プラグイン名

はい

orclPluginFlexfield

カスタム・テキスト情報(Javaのみ)。サブタイプを示すには、orclPluginFlexfield;subtypename(orclPluginFlexfield;minPwdLength: 8など)を指定します。

いいえ

orclPluginBinaryFlexfield

カスタム・バイナリ情報(Javaのみ)。

いいえ

orclPluginSecuredFlexfield

クリアテキストで表示されることのないカスタム・テキスト情報(Javaのみ)。サブタイプを示すには、orclPluginSecuredFlexfield;subtypename(orclPluginSecuredFlexfield;telephonenumber1: 650.123.456など)を指定します。値は暗号化形式で格納および表示されます。検索結果には、orclPluginSecuredFlexfield;telephonenumber1: 1291zjs8134のように表示されることがあります。

ユーザーがこの属性をクリアテキストで取得できないようにするため、Oracle Internet Directoryでは必ずプライバシ・モードを有効にします。『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』の受信した機密の属性のプライバシに関する項を参照してください。

いいえ

orclPluginRequestGroup

セミコロンで区切られたグループ・リストで、プラグインの実行を制御します。このグループを使用して、プラグインを実際に起動するユーザーを指定できます。

たとえば、プラグインの登録時にorclpluginrequestgroup:cn=security,cn=groups,dc=oracle,dc=comを指定すると、グループcn=security,cn=groups,dc=oracle,dc=comに属しているユーザーからldapリクエストがないかぎり、プラグインは起動されません。

いいえ

orclPluginRequestNegGroup

セミコロンで区切られたグループ・リストで、プラグインの実行を制御します。このグループを使用して、プラグインを起動できないユーザーを指定できます。たとえば、プラグインの登録時にorclpluginrequestgroup: cn=security,cn=groups,dc=oracle,dc=comを指定すると、グループcn=security,cn=groups,dc=oracle,dc=comに属しているユーザーからのLDAPリクエストである場合、プラグインは起動されません。

いいえ

orclPluginResultCode

LDAPの結果コードを指定する整数値。この値を指定すると、LDAP操作がこの結果コードの状態の場合にのみ、プラグインが起動します。

操作後プラグイン・タイプにのみ有効です。

いいえ

orclPluginShareLibLocation

ダイナミック・リンク・ライブラリのファイルの位置。この値が存在しない場合、Oracle Internet Directoryサーバーではプラグイン言語はPL/SQLであるとみなされます。

いいえ

orclPluginSubscriberDNList

セミコロンで区切られた識別名のリストで、プラグインの実行を制御します。LDAP操作のターゲット識別名がリストに含まれている場合、プラグインが起動されます。

いいえ

orclPluginTiming

次のいずれかの値です。

pre

when

post

操作時置換タイミングの場合、whenを指定して、orclPluginIsReplaceを有効にします。

いいえ

orclPluginType

次のいずれかの値です。

configuration

attribute

password_policy

syntax

matchingrule

関連項目: 「ディレクトリでサポートされているLDAP操作およびタイミング」

はい

orclPluginVersion

サポート対象のプラグイン・バージョン番号

いいえ

orclPluginClassReloadEnabled

この値が1の場合、サーバーではプラグインを起動するたびにプラグイン・クラスをリロードします。この値が0の場合、サーバーでは最初にプラグインを起動したときにのみクラスをロードします。

45.3.2 コマンド行ツールによるプラグイン構成エントリの追加

コマンド行からプラグイン構成エントリを追加するには、プラグイン構成を含むLDIFファイルを作成します。cn=plugin,cn=subconfigsubentryで識別名を指定します。

次の2つの部分から成るLDIFファイルmy_ldif_file.ldifは、my_plugin1という操作ベース・プラグイン用のエントリを作成します。

dn: cn=when_comp,cn=plugin,cn=subconfigsubentry
objectclass: orclPluginConfig
objectclass: top
orclPluginName: my_plugin1
orclPluginType: configuration
orclPluginTiming: when
orclPluginLDAPOperation: ldapcompare
orclPluginEnable: 1
orclPluginVersion: 1.0.1
orclPluginIsReplace: 1
cn: when_comp
orclPluginKind: PLSQL
orclPluginSubscriberDNList: dc=COM,c=us;dc=us,dc=oracle,dc=com;dc=org,dc=us;
o=IMC,c=US
orclPluginAttributeList: userpassword

dn: cn=post_mod_plugin, cn=plugin,cn=subconfigsubentry
objectclass: orclPluginConfig
objectclass: top
orclPluginName: my_plugin1
orclPluginType: configuration
orclPluginTiming: post
orclPluginLDAPOperation: ldapmodify
orclPluginEnable: 1
orclPluginVersion: 1.0.1
cn: post_mod_plugin
orclPluginKind: PLSQL

このファイルを、次のようなコマンドで、ディレクトリに追加します。

ldapadd -p 3060 -h myhost -D binddn -q -f my_ldif_file.ldif

注意:
プラグイン構成エントリはレプリケートされません。レプリケートすると、一貫性のない状態になります。

45.4 Oracle Directory Services ManagerおよびOracle Enterprise Manager Fusion Middleware Controlを使用したプラグインの管理

Oracle Directory Services Managerを使用して、プラグインを登録、編集および削除できます。

この項の内容は次のとおりです。

1. 第45.4.1項「Oracle Directory Services Managerを使用した新しいプラグインの作成」

2. 第45.4.2項「Oracle Directory Services Managerによるプラグインの登録」

3. 第45.4.3項「Oracle Directory Services Managerによるプラグインの編集」

4. 第45.4.4項「Oracle Directory Services Managerによるプラグインの削除」

5. 第45.4.5項「Oracle Enterprise Manager Fusion Middleware Controlを使用したJVMオプションの管理」

45.4.1 Oracle Directory Services Managerを使用した新しいプラグインの作成

新しいプラグインを作成する手順は、次のとおりです。

1. 第7.4.5項「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動し、Oracle Internet Directoryサーバーに接続します。

2. タスク選択バーで、「拡張」を選択します。

3. 「プラグイン」を展開します。左側のパネルにエントリが表示されます。

4. 対象のプラグイン管理構成エントリを選択し、有効にします。

5. 「作成」アイコンをクリックします。右側のペインに新規プラグイン・ウィンドウが表示されます。

6. この時点でプラグインを有効にするには、「プラグイン有効化」を選択します。

7. 「プラグイン名」を入力します。

8. 他の必須プロパティ用の値を選択します。

9. 値を入力した後、「OK」を選択します。作成したプラグインがこの時点でページの左側に表示されます。

45.4.2 Oracle Directory Services Managerによるプラグインの登録

プラグインを登録する手順は、次のとおりです。

1. 第7.4.5項「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動し、Oracle Internet Directoryサーバーに接続します。

2. タスク選択バーで、「拡張」を選択します。

3. 「プラグイン」を展開します。左側のパネルにエントリが表示されます。

4. 対象のプラグイン管理構成エントリを選択し、有効にします。右側のペインに「プラグイン管理」タブが表示されます。

5. 「プラグイン有効化」を選択します。

6. 「適用」をクリックします。

7. 値を入力した後、「OK」を選択します。作成したプラグインがこの時点でページの左側に表示されます。

45.4.3 Oracle Directory Services Managerによるプラグインの編集

プラグイン・エントリを編集する手順は、次のとおりです。

1. タスク選択バーで、「拡張」を選択します。

2. 「プラグイン」を展開します。左側のパネルにエントリが表示されます。

3. 対象のプラグイン管理構成エントリを選択し、変更します。

4. ページの右側の「必須プロパティ」および「オプション・プロパティ」に変更内容を入力します。

5. 「適用」をクリックします。

45.4.4 Oracle Directory Services Managerによるプラグインの削除

プラグインを削除する手順は、次のとおりです。

1. タスク選択バーで、「拡張」を選択します。

2. 「プラグイン」を展開します。左側のパネルにエントリが表示されます。

3. 削除するプラグイン・エントリを選択します。

4. 「削除」アイコンをクリックします。削除したプラグイン・エントリは、今後、リストに表示されません。

45.4.5 Oracle Enterprise Manager Fusion Middleware Controlを使用したJVMオプションの管理

JVMオプションは、DSA構成エントリのorcljvmoptions属性の中に含まれています。デフォルト値は-Xmx64Mで、ヒープ・サイズが64Mに設定されます。より大きなヒープを割り当てる必要がある場合は、この属性を更新します。

Oracle Enterprise Manager Fusion Middleware Controlを使用してこの属性を変更する方法は、第9.2.2項「共有プロパティの構成」を参照してください。コマンド行から変更する方法は、第13.3項「LDAPコマンド行ツールを使用したエントリの管理」を参照してください。

46 カスタマイズされた外部認証プラグインの構成

この章では、認証用としてOracle Internet Directory以外のリポジトリを使用するために、カスタマイズされた外部認証プラグインを使用する方法について説明します。具体的には、外部プラグインをインストール、構成、有効化およびデバッグする方法や、PL/SQLパッケージを作成する方法について説明します。

ユーザー・セキュリティ資格証明をOracle Internet Directory以外のリポジトリ(データベースや他のLDAPディレクトリなど)に格納し、Oracleコンポーネントに対するユーザー認証に使用できます。資格証明をOracle Internet Directoryに格納する必要はなく、常に同期化させる必要はありません。外部リポジトリに格納された資格証明によるユーザー認証を、外部認証と呼びます。

この章の内容は次のとおりです。

- 第46.1項「カスタマイズされた外部認証プラグインの構成の概要」

- 第46.2項「外部認証プラグインのインストール、構成および有効化」

- 第46.3項「外部認証プラグインのデバッグ」

- 第46.4項「PL/SQLパッケージoidexaup.sqlの作成」

注意:
この章で言及するOracle Single Sign-Onはすべて、Oracle Single Sign-On 10g(10.1.4.3.0)以上のことです。

46.1 カスタマイズされた外部認証プラグインの構成の概要

Oracle Internet Directoryに格納されたセキュリティ資格証明に基づく認証を、ネイティブ認証と呼びます。ユーザーがセキュリティ資格証明を入力すると、ディレクトリ・サーバーはOracle Internet Directoryに格納されている資格証明とそれを比較します。資格証明が一致すると、ディレクトリ・サーバーはユーザーを認証します。

一方、Oracle Internet Directory以外のディレクトリに格納されたセキュリティ資格証明に基づく認証を外部認証と呼びます。ユーザーがセキュリティ資格証明を入力すると、ディレクトリ・サーバーは他のディレクトリに格納されている資格証明とそれを比較します。この比較は次のものを使用して行われます。

- 外部認証作業を行うPL/SQLプログラム

- このPL/SQLプログラムを起動する外部認証プラグイン

46.2 外部認証プラグインのインストール、構成および有効化

この例は、PL/SQLプログラムoidexaup.sqlを使用しています。このプログラムについては、第46.4項「PL/SQLパッケージoidexaup.sqlの作成」で説明します。このパッケージを使用して、外部認証プラグインPL/SQLパッケージをインストールします。次の項目が含まれます。

- 2つのプラグイン(when_compare_replaceおよびwhen_modify_replace)

- ユーティリティ・ファンクション(get_nickname)

統合されたパッケージはプラグイン・パッケージOIDEXTAUTHです。これは、デプロイメントの要件に応じて変更できるテンプレートとしても機能します。

外部認証プラグインをインストールおよび構成し、有効にする手順は、次のとおりです。

1. スタンドアロンの外部認証PL/SQLプログラムを実装します。たとえば、ユーザー名とパスワードで認証する場合は、この2つのパラメータを取るPL/SQLプログラムを使用する必要があります。
サンプル・コードoidexaup.sqlで、auth_externalはプログラム・パッケージ名、authenticate_userは認証を行う関数です。次の手順に進む前に、このスタンドアロン・プログラムが適切に動作することを確認します。

2. スタンドアロンのプログラムをプラグイン・モジュールに登録します。

3. プラグイン・パッケージをデータベースにロードします。この例では、次のように入力します。

sqlplus ods/odspwd @oidexaup.sql

4. プラグインを登録します。プラグインの起動に必要な情報をディレクトリ・サーバーに提供するLDIFファイルを作成し、アップロードすることにより登録します。

5. この例では、次の内容のファイルoidexauth.ldifを使用します。

dn: cn=whencompare,cn=plugin,cn=subconfigsubentry
objectclass:orclPluginConfig
objectclass:top
orclpluginname:oidextauth
orclplugintype:configuration
orclplugintiming:when
orclpluginldapoperation:ldapcompare
orclpluginenable:1
orclpluginversion:1.0.1
orclPluginIsReplace:1
cn:whencompare
orclpluginsubscriberdnlist:dc=com;o=IMC,c=US
orclpluginattributelist:userpassword
orclpluginrequestgroup:$prgdn

dn: cn=whenmodify,cn=plugin,cn=subconfigsubentry
objectclass:orclPluginConfig
objectclass:top
orclpluginname:oidextauth
orclplugintype:configuration
orclplugintiming:when
orclpluginldapoperation:ldapmodify
orclpluginenable:1
orclpluginversion:1.0.1
orclPluginIsReplace:1
cn:whenmodify
orclpluginsubscriberdnlist:dc=com;o=IMC,c=US
orclpluginattributelist:userpassword
orclpluginrequestgroup:$prgdn

このファイルでは、ldapcompareリクエストまたはldapmodifyリクエストがあった際に2つのプラグインが起動することをディレクトリ・サーバーに通知します。

ターゲット・エントリがdc=comまたはo=IMC,c=US下の場合のみプラグインが起動するように、orclpluginsubscriberdnlist:dc=com;o=IMC,c=USを使用します。

$prgdnを、プラグイン・リクエスト・グループ識別名に置換します。これはオプションの推奨セキュリティ機能です。Oracle Single Sign-Onとの統合には、この値が必須フィールドです。入力されたグループのメンバーのみがプラグインを起動できます。複数のグループの入力が可能です。エントリを区切るには、セミコロンを使用します。

推奨デフォルトは、cn=OracleUserSecurityAdmins,cn=Groups,cn=OracleContextおよびcn=OracleDASAdminGroup,cn=Groups,cn=OracleContext,o=default_subscriber,dc=comです。Oracle Single Sign-On Serverは、最初のグループのメンバーです。また、デプロイメント環境に合せてo=default_subscriberを正しい値に置換してください。

このファイルをディレクトリに追加するには、次のとおり入力します。

ldapadd -p portnum -h hostname -D cn=orcladmin -q -v \
-f oidexauth.ldif

これで、すべての準備が完了しました。ldapcompareコマンド行ツールを使用すると、Oracle Single Sign-Onからユーザーを認証する前にプラグインおよび認証プログラムが適切に動作していることを確認できます。

この例では、ユーザー・パスワードを外部変更するためのプラグイン・コードも提供されています。

46.3 外部認証プラグインのデバッグ

ディレクトリ・サーバー・プラグインを設定すると、プラグインのプロセスと内容を調べることができます。

ディレクトリ・サーバー・プラグインのデバッグを設定するには、次のコマンドを実行します。

sqlplus ods  @$ORACLE_HOME/ldap/admin/oidspdsu.sql

ディレクトリ・サーバー・プラグインのデバッグを有効にするには、次のコマンドを実行します。

sqlplus ods  @$ORACLE_HOME/ldap/admin/oidspdon.sql

ディレクトリ・サーバー・プラグインのデバッグを無効にするには、次のコマンドを実行します。

sqlplus ods @$ORACLE_HOME/ldap/admin/oidspdof.sql

ディレクトリ・サーバー・プラグインのデバッグ・メッセージを表示するには、次のコマンドを実行します。

sqlplus ods @$ORACLE_HOME/ldap/admin/oidspdsh.sql

ディレクトリ・サーバー・プラグインのデバッグ・メッセージを削除するには、次のコマンドを実行します。

sqlplus ods @$ORACLE_HOME/ldap/admin/oidspdde.sql

46.4 PL/SQLパッケージoidexaup.sqlの作成

この例で使用するスクリプトoidexaup.sqlの内容は次のとおりです。

CREATE OR REPLACE PACKAGE OIDEXTAUTH AS

PROCEDURE when_compare_replace (ldapplugincontext IN  ODS.plugincontext,
result            OUT INTEGER,
dn                IN  VARCHAR2,
attrname          IN  VARCHAR2,
attrval           IN  VARCHAR2,
rc                OUT INTEGER,
errormsg          OUT VARCHAR2
);

PROCEDURE when_modify_replace (ldapplugincontext IN  ODS.plugincontext,
dn                IN  VARCHAR2,
mods              IN  ODS.modlist,
rc                OUT INTEGER,
errormsg          OUT VARCHAR2
);

FUNCTION get_nickname (dn         IN  VARCHAR2,
my_session IN  DBMS_LDAP.session)
RETURN VARCHAR2;

END OIDEXTAUTH;
/

SHOW ERROR

CREATE OR REPLACE PACKAGE BODY OIDEXTAUTH AS

-- We use this function to convert the dn to nickname.
-- When OID server receives the ldapcompare request, it
-- only has the dn information. We need to use DBMS_LDAP_UTL
-- package to find out the nickname attribute value of
-- the entry.

FUNCTION get_nickname (dn         IN VARCHAR2,
my_session IN DBMS_LDAP.session)
RETURN VARCHAR2
IS
my_pset_coll        DBMS_LDAP_UTL.PROPERTY_SET_COLLECTION;
my_property_names   DBMS_LDAP.STRING_COLLECTION;
my_property_values  DBMS_LDAP.STRING_COLLECTION;

user_handle         DBMS_LDAP_UTL.HANDLE;
user_id             VARCHAR2(2000);
user_type           PLS_INTEGER;
user_nickname       VARCHAR2(256) DEFAULT NULL;

my_attrs            DBMS_LDAP.STRING_COLLECTION;
retval              PLS_INTEGER;

BEGIN
plg_debug( '=== Beginning of get_nickname() === ');
user_type     := DBMS_LDAP_UTL.TYPE_DN;
user_id       := dn;

retval := DBMS_LDAP_UTL.create_user_handle(user_handle, user_type, user_id);

plg_debug('create_user_handle() Returns ' || To_char(retval));

retval := DBMS_LDAP_UTL.get_user_properties(my_session,
user_handle,
my_attrs,
DBMS_LDAP_UTL.NICKNAME_PROPERTY,
my_pset_coll);

plg_debug( 'get_user_properties() Returns ' || To_char(retval));

IF my_pset_coll.COUNT > 0 THEN
FOR i IN my_pset_coll.first .. my_pset_coll.last LOOP
retval := DBMS_LDAP_UTL.get_property_names(my_pset_coll(i),
my_property_names);
IF my_property_names.COUNT > 0 THEN
FOR j IN my_property_names.first .. my_property_names.last LOOP
retval := DBMS_LDAP_UTL.get_property_values(my_pset_coll(i),
my_property_names(j),
my_property_values);
IF my_property_values.COUNT > 0 THEN
FOR k IN my_property_values.FIRST..my_property_values.LAST LOOP
user_nickname := my_property_values(k);
plg_debug( 'user nickname = ' || user_nickname);
END LOOP;
END IF;
END LOOP;
END IF; -- IF my_property_names.count > 0
END LOOP;
END IF; -- If my_pset_coll.count > 0

plg_debug( 'got user_nickname: ' || user_nickname);

-- Free my_properties
IF my_pset_coll.count > 0 then
DBMS_LDAP_UTL.free_propertyset_collection(my_pset_coll);
END IF;

DBMS_LDAP_UTL.free_handle(user_handle);

RETURN user_nickname;

EXCEPTION
WHEN OTHERS THEN
plg_debug('Exception in get_nickname. Error code is ' || to_char(sqlcode));
plg_debug('   ' || Sqlerrm);
RETURN NULL;
END;

PROCEDURE when_compare_replace (ldapplugincontext IN  ODS.plugincontext,
result            OUT INTEGER,
dn                IN  VARCHAR2,
attrname          IN  VARCHAR2,
attrval           IN  VARCHAR2,
rc                OUT INTEGER,
errormsg          OUT VARCHAR2
)
IS
retval pls_integer;
lresult BOOLEAN;

my_session          DBMS_LDAP.session;
my_property_names   DBMS_LDAP.STRING_COLLECTION;
my_property_values  DBMS_LDAP.STRING_COLLECTION;
my_attrs            DBMS_LDAP.STRING_COLLECTION;
my_pset_coll        DBMS_LDAP_UTL.PROPERTY_SET_COLLECTION;
user_handle         DBMS_LDAP_UTL.HANDLE;

user_id             VARCHAR2(2000);
user_type           PLS_INTEGER;
user_nickname       VARCHAR2(60);
remote_dn           VARCHAR2(256);

i                   PLS_INTEGER;
j                   PLS_INTEGER;
k                   PLS_INTEGER;

BEGIN
plg_debug( '=== Begin of WHEN-COMPARE-REPLACE plug-in');
plg_debug( 'DN = ' || dn);
plg_debug( 'Attr = ' || attrname);
--plg_debug( 'Attrval = ' || attrval);

DBMS_LDAP.USE_EXCEPTION := FALSE;
errormsg := 'No error msg';
rc := 0;

-- converting dn to nickname
my_session := LDAP_PLUGIN.init(ldapplugincontext);
plg_debug( 'ldap_session =' || RAWTOHEX(SUBSTR(my_session,1,8)));

retval := LDAP_PLUGIN.simple_bind_s(ldapplugincontext, my_session);
plg_debug( 'simple_bind_res =' || TO_CHAR(retval));

user_nickname := get_nickname(dn, my_session);
plg_debug( 'user_nickname =' || user_nickname);

-- unbind from the directory
retval := DBMS_LDAP.unbind_s(my_session);
plg_debug( 'unbind_res Returns ' || To_char(retval));

IF (user_nickname IS NULL) THEN
result := 32;
errormsg := 'Can''t find the nickname';
plg_debug( 'Can''t find the nickname');
RETURN;
END IF;

plg_debug( '=== Now go to extauth ');

BEGIN
retval := auth_external.authenticate_user(user_nickname, attrval);
plg_debug( 'auth_external.authenticate_user() returns = ' || 'True');
result := 6; -- compare result is TRUE
EXCEPTION
WHEN OTHERS THEN
result := 5; -- compare result is FALSE
plg_debug( 'auth_external.authenticate_user() returns = ' || 'False');
RETURN;
END;

plg_debug( '=== End of WHEN-COMPARE-REPLACE plug-in');
EXCEPTION
WHEN OTHERS THEN
rc := 1;
errormsg := 'Exception: when_compare_replace plugin';
plg_debug( 'EXCEPTION: ' || retval);
plg_debug('Exception in when_compare. Error code is ' || to_char(sqlcode));
plg_debug('   ' || Sqlerrm);
END;

PROCEDURE when_modify_replace (ldapplugincontext IN  ODS.plugincontext,
dn                IN  VARCHAR2,
mods              IN  ODS.modlist,
rc                OUT INTEGER,
errormsg          OUT VARCHAR2
)
IS
retval pls_integer;
lresult BOOLEAN;

my_session          DBMS_LDAP.SESSION;
my_property_names   DBMS_LDAP.STRING_COLLECTION;
my_property_values  DBMS_LDAP.STRING_COLLECTION;
my_attrs            DBMS_LDAP.STRING_COLLECTION;
my_modval           DBMS_LDAP.BERVAL_COLLECTION;
my_pset_coll        DBMS_LDAP_UTL.PROPERTY_SET_COLLECTION;
user_handle         DBMS_LDAP_UTL.HANDLE;

l_mod_array         RAW(32);
user_id             VARCHAR2(2000);
user_type           PLS_INTEGER;
user_nickname       VARCHAR2(2000);
old_passwd          VARCHAR2(60) DEFAULT NULL;
new_passwd          VARCHAR2(60) DEFAULT NULL;
remote_dn           VARCHAR2(256);

i                   PLS_INTEGER;
j                   PLS_INTEGER;
k                   PLS_INTEGER;

BEGIN
plg_debug( '=== Begin of WHEN-MODIFY-REPLACE plug-in');
DBMS_LDAP.USE_EXCEPTION := FALSE;
user_type     := DBMS_LDAP_UTL.TYPE_DN;
user_id       := dn;

-- converting dn to nickname
my_session := LDAP_PLUGIN.init(ldapplugincontext);
plg_debug( 'ldap_session =' || RAWTOHEX(SUBSTR(my_session,1,8)));

retval := LDAP_PLUGIN.simple_bind_s(ldapplugincontext, my_session);
plg_debug( 'simple_bind_res =' || TO_CHAR(retval));

user_nickname := get_nickname(dn, my_session);
plg_debug( 'user_nickname =' || user_nickname);

-- unbind from the directory
retval := DBMS_LDAP.unbind_s(my_session);

FOR l_counter1 IN 1..mods.COUNT LOOP
IF (mods(l_counter1).operation = 2) AND
(mods(l_counter1).type = 'userpassword') THEN

FOR l_counter2 IN 1..mods(l_counter1).vals.COUNT LOOP
new_passwd := mods(l_counter1).vals(l_counter2).val;
END LOOP;
END IF;

IF (mods(l_counter1).operation = 0) AND
(mods(l_counter1).type = 'userpassword') THEN

FOR l_counter2 IN 1..mods(l_counter1).vals.COUNT LOOP
new_passwd := mods(l_counter1).vals(l_counter2).val;
END LOOP;
END IF;

IF (mods(l_counter1).operation = 1) AND
(mods(l_counter1).type = 'userpassword') THEN

FOR l_counter2 IN 1..mods(l_counter1).vals.COUNT LOOP
old_passwd := mods(l_counter1).vals(l_counter2).val;
END LOOP;
END IF;
END LOOP;

IF new_passwd IS NOT NULL AND old_passwd IS NOT NULL THEN
BEGIN
auth_external.change_passwd(user_nickname, old_passwd, new_passwd);
EXCEPTION
WHEN OTHERS THEN
rc := 1;
plg_debug( 'auth_external.change_passwd() raised exception.');
errormsg := 'auth_external.change_passwd() raised exception.';
RETURN;
END;
ELSIF new_passwd IS NOT NULL AND old_passwd IS NULL THEN
BEGIN
auth_external.reset_passwd(user_nickname, new_passwd);
EXCEPTION
WHEN OTHERS THEN
plg_debug( 'auth_external.reset_passwd() raised exception.');
rc := 1;
errormsg := 'auth_external.reset_passwd() raised exception.';
RETURN;
END;
ELSE
rc := 1;
errormsg := 'PLG_Exception. Not enough info to change passwd.';
END IF;

plg_debug( 'external change password succeed');
rc := 0;
errormsg := 'No when_mod_replace plguin error msg';

retval := DBMS_LDAP.unbind_s(my_session);

plg_debug( 'End of WHEN-MODIFY-REPLACE');
--COMMIT;
EXCEPTION
WHEN others THEN
rc := 1;
errormsg := 'PLG_Exception: when_modify_replace plguin';
plg_debug('Exception in when_modify. Error code is ' || to_char(sqlcode));
plg_debug('   ' || Sqlerrm);
END;

END OIDEXTAUTH;
/
SHOW ERRORS
--list

EXIT;

第VII部

付録

次の各付録で構成されています。

- 付録A「10gと11gの違い」

- 付録B「OIDCTLを使用したOracle Internet Directoryインスタンスの管理」

- 付録C「Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーションの設定」

- 付録D「レプリケーションの動作」

- 付録E「Javaサーバー・プラグイン開発者リファレンス」

- 付録F「PL/SQLサーバー・プラグイン開発者リファレンス」

- 付録G「LDAPフィルタ定義」

- 付録H「アクセス制御ディレクティブ書式」

- 付録I「ディレクトリにおけるグローバリゼーション・サポート」

- 付録J「ユーザーおよびグループの作成ベースおよび検索ベースに対するアクセス制御の設定」

- 付録K「ディレクトリでのユーザー証明書の検索」

- 付録L「データベース・コピー・プロシージャを使用したディレクトリ・ノードの追加」

- 付録M「Oracle Authentication Services for Operating Systems」

- 付録N「Oracle Internet DirectoryでサポートされているRFC」

- 付録O「Oracle Directory Services ManagerのJavaキーストアの管理」

- 付録P「Oracleスタックの起動と停止」

- 付録Q「ローリング・アップグレードの実行」

- 付録R「Oracle Internet Directoryに関するトラブルシューティング」

A 10gと11gの違い

この付録では、Oracle Internet Directoryリリース10g (10.1.4.0.1)と11gリリース1の主な違いについて説明します。

この付録の内容は次のとおりです。

- 第A.1項「インスタンスの作成とプロセスの管理」

- 第A.2項「構成属性の場所」

- 第A.4項「サーバー・デバッグの有効化」

- 第A.5項「コマンド行ツール」

- 第A.6項「パス名」

- 第A.7項「グラフィカル・ユーザー・インタフェース」

- 第A.8項「監査」

- 第A.9項「参照整合性」

- 第A.10項「サーバー・チェーン」

- 第A.11項「レプリケーション」

- 第A.12項「Oracle Directory Integration Platform」

- 第A.13項「Oracle Single Sign-OnとOracle Delegated Administration Services」

- 第A.14項「Javaコンテナ」

A.1 インスタンスの作成とプロセスの管理

10g Oracle Internet Directoryインスタンスの作成

10g (10.1.4.0.1)以前のリリースでは、Oracle Internet Directoryインスタンスの構成情報は、次の形式の識別名を持つ構成セットに格納されていました。

cn=configsetN,cn=osdldapd,cn=subconfigsubentry

Nは整数です。新規のconfigsetNエントリを作成して新規Oracle Internet Directoryインスタンスを作成し、

oidctl connect=connStr config=N inst=InstNum flags="...." start

を実行してインスタンスを起動していました。

11g Oracle Internet Directoryインスタンスの作成

11g リリース1では、インスタンスを作成する手順が変更されました。現在、Oracle Internet Directoryインスタンスの構成情報は、次の書式の識別名を持つインスタンス固有の構成エントリに格納されています。

cn=componentname,cn=osdldapd,cn=subconfigsubentry

componentnameは、Type=OIDのOracle Fusion Middlewareシステム・コンポーネントの名前(oid1など)です。インスタンス固有の構成エントリは手動で作成しません。かわりに、Type=OIDのOracle Fusion Middlewareコンポーネントを作成します。Oracle Internet Directoryコンポーネントを作成すると、インスタンス固有の構成エントリが自動的に生成されます。

注意:
configset0のエントリは11gにありますが、読取り専用であり、新規のインスタンス固有の構成エントリの生成時にデフォルトの属性値を格納するために使用されます。

最初のOracle Internet Directoryシステム・コンポーネントは、インストール時に作成されます。最初のOracle Internet Directoryシステム・コンポーネント(デフォルトではoid1)は、デフォルトではOracleインスタンス名asinst_1を使用してインストール時に作成されます。このコンポーネントに対応する構成エントリはcn=oid1,cn=osdldapd,cn=subconfigsubentryです。Oracle Internet Directoryインスタンスの追加作成には、次の2つの方法を使用します。

- opmnctl createcomponentを使用して、Type=OIDの別のコンポーネントを追加します。次に例を示します。

opmnctl createcomponent -componentType OID \
-componentName componentName -Db_info "DBHostName:Port:DBSvcName" \
-Namespace "dc=domain"

詳細は、第8.3.1項「opmnctlを使用したOracle Internet Directoryコンポーネントの作成」を参照してください。

- oidctl addを使用して、Type=OIDの既存のコンポーネント内にOracle Internet Directoryインスタンスを追加します。詳細は、第B.2項「OIDCTLを使用したOracle Internet Directoryサーバー・インスタンスの作成と起動」を参照してください。

推奨される方法は、opmnctlを使用してシステム・コンポーネントを追加することです。opmnctlを使用したコンポーネントの追加によってインスタンスを作成する場合、インスタンスの停止および起動にはopmnctlまたはOracle Enterprise Manager Fusion Middleware Controlを使用し、oidctlは使用しません。第8.3.7項「opmnctlを使用したOracle Internet Directoryサーバーの起動」および第8.2.2項「Fusion Middleware Controlを使用したOracle Internet Directoryサーバーの起動」を参照してください。

インスタンスの構成属性は、Fusion Middleware Control、LDAPツールまたはOracle Directory Services Managerを使用して更新できます。第9章「システム構成属性の管理」を参照してください。

opmnctlを使用してoid2というコンポーネント名のシステム・コンポーネントを追加すると、componentname=oid2の追加インスタンスが特定のOracleインスタンス(デフォルトではasinst_1)内に構成されます。このOracle Internet Directoryのインスタンスは、ias-component=oid2を指定したopmnctlコマンドまたはFusion Middleware Controlを使用して起動および停止できます。このインスタンスのインスタンス固有の構成エントリはcn=oid2,cn=osdldapd,cn=subconfigsubentryで、このエントリの構成属性を更新してインスタンスをカスタマイズできます。インスタンス固有の構成属性の詳細は、第9.1.3項「インスタンス固有の構成エントリの属性」を参照してください。

注意:
WebLogicドメインの一部としてではなく、スタンドアロン・サーバーとしてOracle Internet Directoryが稼働している場合、oidctlを使用してインスタンスを作成できます。oidctlを使用してインスタンスを作成した場合、oidmonおよびoidctlを使用してインスタンスを停止および起動する必要があります。oidctlを使用して作成したOracle Internet Directoryインスタンスは、WebLogicサーバーに登録できないため、Oracle Enterprise Manager Fusion Middleware Controlを使用してインスタンスを管理できません。付録B「OIDCTLを使用したOracle Internet Directoryインスタンスの管理」を参照してください。

11gのレプリケーション・サーバー

インスタンスでレプリケーションを初めて開始する場合、oidctlまたはOracle Enterprise Manager Fusion Middleware Controlを使用します。その後は、opmnctlでコンポーネントの停止および起動時にレプリケーションを停止および起動します。管理目的でOracle Internet Directoryレプリケーション・サーバーを停止および起動する必要がある場合、oidctlまたはOracle Enterprise Manager Fusion Middleware Controlを使用します。

11gのOIDMON

11g リリース1では、OIDMONがOracle Internet Directoryのすべてのプロセス(ディスパッチャ、ディレクトリ・サーバーおよびレプリケーション・サーバー)のステータスをモニターしてOPMNにレポートします。OIDMONのこのモニタリングにより、Fusion Middleware ControlはOracle Internet Directoryのステータスを正確にレポートできます。

関連項目:

- 第4章「Oracle Internet Directoryコンポーネントのプロセス制御の理解」

- 第8章「Oracle Internet Directoryインスタンスの管理」。

A.2 構成属性の場所

Oracle Internet Directoryの構成情報は、DIT内の構成属性に格納されます。構成属性とその場所、および管理手順の詳細は、第9章「システム構成属性の管理」を参照してください。

10g(10.1.4.0.1)では、構成可能な多くのOracle Internet Directory属性は、DSEルートとconfigsetエントリ(cn=configset0,cn=osdldapd,cn=subconfigsubentryなど)にありました。11g リリース1では、これらの大半がインスタンス固有の構成エントリまたはDSA構成エントリに移動しました。

10g(10.1.4.0.1)でインスタンス固有の構成セットにあった属性の大半は、11g リリース1ではインスタンス固有の構成エントリに格納されています。また、DSA構成エントリにあった一部の属性はインスタンス固有となり、インスタンス固有の構成エントリに移動されました。

注意:

- 11gへのアップグレード時、属性は新しい場所にデフォルト値で作成されます。アップグレード前の属性値は、属性が11gで同じ場所にないかぎり保持されません。

- 属性をコマンド行から管理する場合、コマンド行またはLDIFファイルで指定する識別名が、属性の11gでの場所を反映していることを確認します。

表A-1に、10gの属性とその属性の10gと11gでの場所、および11gでのデフォルト値を示します。次の表で、インスタンス固有とは、属性がインスタンス固有の構成エントリ(cn=oid1,cn=osdldapd,cn=subconfigsubentryなど)にあることを意味し、DSA構成はcn=dsaconfig,cn=configsets,cn=oracle internet directoryのことです。DSA構成エントリの属性は、Oracle Internet Directoryのすべてのインスタンスとコンポーネントで共有されます。

表A-1 10gの属性の新しい場所

属性

10gでの場所

11gでの場所

11gでのデフォルト値

orclanonymousbindsflag

ルートDSE

インスタンス固有

1

orcldataprivacymode

DSA構成

DSA構成

0

orcldebugflag

ルートDSE

インスタンス固有

0

orcldebugforceflush

DSA構成

インスタンス固有

0

orcldebugop

ルートDSE

インスタンス固有

511

orclecacheenabled

ルートDSE

DSA構成

1

orclecachemaxentries

ルートDSE

DSA構成

100000

orclecachemaxsize

ルートDSE

DSA構成

200000000

orclenablegroupcache

ルートDSE

インスタンス固有

1

orcleventlevel

ルートDSE

インスタンス固有

0

orclldapconntimeout

DSA構成

インスタンス固有

0

orclmatchdnenabled

ルートDSE

DSA構成

1

orclmaxcc

コンフィグセット

インスタンス固有

2

orclmaxconnincache

DSA構成

インスタンス固有

100000

orclnwrwtimeout

DSA構成

インスタンス固有

30

orcloptcontainsquery

ルートDSE

DSA構成

0

orcloptracklevel

DSA構成

インスタンス固有

0

orcloptrackmaxtotalsize

DSA構成

インスタンス固有

100000000

orclpkimatchingrule

DSA構成

DSA構成

2

orclrefreshdgrmems

DSA構成

DSA構成

0

orclsaslauthenticationmode

コンフィグセット

インスタンス固有

auth-conf

orclsaslcipherchoice

コンフィグセット

インスタンス固有

Rc4-56、des、3des、rc4、rc4-40

orclsaslmechanism

コンフィグセット

インスタンス固有

DIGEST MD5、EXTERNAL

orclsdumpflag

DSA構成

インスタンス固有

0

orclservermode

ルートDSE

インスタンス固有

rw

orclserverprocs

コンフィグセット

インスタンス固有

1

orclsizelimit

ルートDSE

インスタンス固有

10000

orclskewedattribute

DSA構成

DSA構成

objectclass

orclskiprefinsql

DSA構成

DSA構成

0

orclsslauthentication

コンフィグセット

インスタンス固有

1

orclsslenable

コンフィグセット

インスタンス固有

2

orclsslversion

コンフィグセット

インスタンス固有

3

orclsslwalleturl

コンフィグセット

インスタンス固有

File:

orclstatsdn

DSA構成

DSA構成

orclstatsflag

ルートDSE

インスタンス固有

1

orclstatslevel

ルートDSE

インスタンス固有

0

orclstatsperiodicity

DSA構成

インスタンス固有

30

orcltimelimit

ルートDSE

インスタンス固有

3600

orcltlimitmode

DSA構成

DSA構成

1

関連項目:
第9章「システム構成属性の管理」

A.3 デフォルト・ポート

Oracle Internet Directoryのインストール時、Oracle Identity Management 11gインストーラは特定の手順に従ってSSLおよび非SSLポートを割り当てます。まず、非SSLポートとして3060の使用を試みます。そのポートが使用できない場合、3061から3070の範囲のポートを試し、次に13060から13070の範囲のポートを試します。同様に、SSLポートとして3131を試し、次に3132から3141のポート、その後13131から13141のポートを試します。

Oracle Internet Directoryで特権ポートを使用する場合、staticports.iniを使用してインストール時にデフォルトをオーバーライドできます。(『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』を参照してください。)インストール後に、ポート番号を再設定することもできます。第7.2.8項「Enabling Oracle Internet Directoryの特権ポートでの実行の有効化」を参照してください。

注意:
Oracle Internet Directoryの旧バージョンから11g リリース1へアップグレードする場合、旧バージョンのポート番号が保持されます。

A.4 サーバー・デバッグの有効化

10gでは、サーバーを起動する際にデバッグ・オプションを使用するか、ルートDSEにあるorcldebugflagを設定してデバッグを有効にすることができました。

11gでは、サーバーの起動時にデバッグ・オプションを使用してデバッグを有効にすることはできません。ディレクトリ・サーバーのデバッグは、属性orcldebugflagを変更することにより有効にします。この属性は、次の形式の識別名を持つインスタンス固有の構成エントリにあります。

cn=componentname,cn=osdldapd,cn=subconfigsubentry

orcldebugflagは、Fusion Middleware Controlの「サーバー・プロパティ」ページの「ロギング」タブまたはldapmodifyを使用して変更できます。たとえば、次のLDIFファイルを使用して、システム・コンポーネントoid1のOracle Internet Directoryインスタンスを大容量トレースのデバッグ用に構成できます。

dn: cn=oid1,cn=osdldapd,cn=subconfigsubentry
changetype: modify
replace: orcldebugflag
orcldebugflag: 1

詳細は、第24章「ロギングの管理」を参照してください。

レプリケーション・サーバーのデバッグは、レプリケーション構成セットの属性orcldebuglevelを変更して有効にします。

表42-4「レプリケーション構成セットの属性」に、次の識別名を持つレプリケーション構成セットの属性とその説明を示します。

cn=configset0,cn=osdrepld,cn=subconfigsubentry

orcldebuglevelの変更には、ldapmodifyまたはFusion Middleware Controlの「共有プロパティ」、「レプリケーション」タブを使用できます。詳細は、第42章「レプリケーション構成属性の管理」を参照してください。

A.5 コマンド行ツール

ほとんどのコマンドで、環境変数ORACLE_INSTANCEの設定が必要になりました。

新しいオプションがopmnctlおよびoidctlに追加されました。

一部のOracle Internet Directory管理ツールおよびバルク・ツールは、接続先のOracle Databaseを指定するconnect引数をとります。10gでは、コマンド行にconnect引数を含めなかった場合、環境変数ORACLE_SIDの値がデフォルトで使用されました。11g リリース1では、connect引数を使用してデータベースを指定する必要があります。Oracle Internet DirectoryとOracle Databaseは同じORACLE_HOMEにインストールされないため、ORACLE_SIDは無関係です。したがって、connect=oiddbのようにconnect引数を使用してデータベースを指定する必要があります。

関連項目:

- 第8章「Oracle Internet Directoryインスタンスの管理」

- 第15章「バルク操作の実行」

A.6 パス名

Oracle Fusion Middleware 11g リリース1では、更新可能なファイルはORACLE_INSTANCE下にインストールされ、製品バイナリの大半はORACLE_HOME下に格納されます。その結果、大部分の構成ファイルとログ・ファイルのパス名が10g(10.1.4.0.1)と異なります。表A-2に例を示します。

表A-2 変更されたパス名の例

ファイル名

10g(10.1.4.0.1)での場所

11g リリース1での場所

Orclpwdlldap1

OidpwdrSID

ORACLE_HOME/ldap/admin

ORACLE_INSTANCE/OID/admin

Tnsnames.ora

ORACLE_HOME/network/admin

ORACLE_HOME/config

Oidldapd*.log

oidmon*.log

ORACLE_HOME/ldap/log

ORACLE_HOME/diagnostics/logs/OID/componentName

bulkload.log

bulkdelte.log

catalog.log

ORACLE_HOME/ldap/log

ORACLE_HOME/diagnostics/logs/OID/tools

bulkload中間ファイル

ORACLE_HOME/ldap/load

ORACLE_INSTANCE/OID/load

opmnctl

ORACLE_HOME/opmn/bin

ORACLE_INSTANCE/bin

opmn.xml

ORACLE_HOME/opmn/conf

ORACLE_INSTANCE/config/OPMN/opmn

関連項目:
第2章「Oracle Fusion Middleware内のOracle Internet Directoryの理解」

A.7 グラフィカル・ユーザー・インタフェース

11g リリース1には、Oracle Directory ManagerおよびOracle Internet Directory Grid Control Plug-inが存在しません。これらの機能は、Oracle Directory Services ManagerとOracle Enterprise Manager Fusion Middleware Controlに置き換えられました。

詳細は、次の項を参照してください。

- 第7.4項「Oracle Directory Services Managerの使用」

- 第7.3項「Fusion Middleware Controlを使用したOracle Internet Directoryの管理」

A.8 監査

11gリリース1のリリースでは、Oracle Internet DirectoryはOracle Fusion Middlewareと統合された監査フレームワークを使用します。

監査は、Oracle Enterprise Manager Fusion Middleware ControlまたはWebLogic Scripting Tool wlstを使用して構成できます。

属性orclAudFilterPresetによって、10g(10.1.4.0.1)で使用されている監査レベルが置き換えられます。None、Low、Medium、AllまたはCustomに設定できます。

Oracle Internet Directoryガベージ・コレクタはもう必要ありません。

関連項目:
第23章「監査の管理」

A.9 参照整合性

参照整合性が完全に実装しなおされました。コマンド行またはOracle Enterprise Manager Fusion Middleware Controlを使用して構成できます。

関連項目:
第22章「参照整合性の構成」

A.10 サーバー・チェーン

サーバー・チェーンで、Microsoft Active DirectoryおよびSun Java System Directory Server(以前のSunONE iPlanet)に加えてNovell eDirectoryがサポートされるようになりました。属性mapUIDtoADAttribute、showExternalGroupEntries、showExternalUserEntriesおよびaddOrcluserv2ToADUsersは、Oracle Internet Directory 10g(10.1.4.0.1)から追加されています。

A.11 レプリケーション

LDAPベースのレプリケーションは、Oracle Enterprise Manager Fusion Middleware Controlのレプリケーション・ウィザードを使用して設定および管理できます。個別の「レプリケーション」ページでレプリケーション・サーバーを制御する属性を調整できます。

LDAPベースのレプリケーションをマルチマスター・ディレクトリ・レプリケーション・グループに使用できるようになりました。この目的でOracle Databaseアドバンスト・レプリケーション・ベースのレプリケーションを使用する必要がなくなりました。ただし、Oracle Single Sign-Onをレプリケートする必要がある場合、Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーションを使用する必要があります。

関連項目:

- 第6章「Oracle Internet Directoryレプリケーションの理解」

- 第V部「拡張管理: ディレクトリ・レプリケーション」

- 付録C「Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーションの設定」

A.12 Oracle Directory Integration Platform

10g(10.1.4.0.1)では、Oracle Directory Integration Platformサーバーは、LDAPサーバーやレプリケーション・サーバーと同様にOIDMONで制御されていました。11g リリース1では、Oracle Directory Integration PlatformはJ2EEアプリケーションとして再実装され、Oracle Internet Directoryサーバーとは別に起動および停止されます。

関連項目:
Oracle Fusion Middleware Oracle Directory Integration Platform管理者ガイド

A.13 Oracle Single Sign-OnとOracle Delegated Administration Services

Oracle Fusion Middleware 11g リリース1には、Oracle Single Sign-OnもOracle Delegated Administration Servicesも含まれていません。ただし、Oracle Internet Directory 11g リリース1は、Oracle Single Sign-On 10g(10.1.4.3.0)以上およびOracle Delegated Administration Services 10g(10.1.4.3.0)以上と互換性があります。

A.14 Javaコンテナ

Oracle Application Server 10gでは、Oracle Containers for JavaのインスタンスでJavaアプリケーションが実行されていました。現行リリースでは、それらはWebLogicのインスタンスで実行されます。Oracle Directory Services ManagerとOracle Directory Integration Platformは、WebLogic管理対象サーバーで実行されるJavaコンポーネントです。

CプログラムのOracle Internet Directory LDAPサーバーおよびレプリケーション・サーバーはシステム・コンポーネントで、この変更による影響を受けません。Javaサーバー・プラグインはoidldapdサーバー自体の内部にあるJVMで実行されます。これは、Java Native Interface(JNI)を使用して実装されます。

関連項目:

- Oracle Fusion Middleware Oracle WebLogic Serverの紹介

- 第45章「Oracle Internet Directoryサーバーのプラグインの開発」

B OIDCTLを使用したOracle Internet Directoryインスタンスの管理

この付録では、OIDCTLを使用して、WebLogicドメインやOracle Enterprise Manager Fusion Middleware Controlなしでスタンドアロン・モードでOracle Internet Directoryを管理する方法について説明します。具体的には、この付録で、OIDCTLを使用して、Oracle Internet Directoryサーバー・インスタンスを作成、削除、起動および停止する方法や、そのステータス情報を表示する方法について説明します。

この付録の内容は次のとおりです。

- 第B.1項「OIDCTLを使用したOracle Internet Directoryの管理の概要」

- 第B.2項「OIDCTLを使用したOracle Internet Directoryサーバー・インスタンスの作成と起動」

- 第B.3項「OIDCTLを使用したOracle Internet Directoryサーバー・インスタンスの停止」

- 第B.4項「OIDCTLを使用したOracle Internet Directoryサーバー・インスタンスの起動」

- 第B.5項「OIDCTLを使用したステータス情報の表示」

- 第B.6項「OIDCTLを使用したOracle Internet Directoryサーバー・インスタンスの削除」

関連項目:
第8.4項「OIDCTLを使用したレプリケーション・サーバーのインスタンスの起動」

B.1 OIDCTLを使用したOracle Internet Directoryの管理の概要

一部の顧客は、WebLogicドメインやOracle Enterprise Manager Fusion Middleware Controlを使用せずに、スタンドアロン・モードでOracle Internet Directoryを実行する必要があります。Oracle Internet Directoryをスタンドアロン・モードで実行している場合は、oidctl addを使用して、既存のOracle Internet Directoryコンポーネント内にOracle Internet Directoryインスタンスを追加作成できます。oidctlを使用してOracle Internet Directoryインスタンスを作成すると、新規インスタンスはWebLogicサーバーから認識されず、Oracle Enterprise Manager Fusion Middleware Controlを使用して管理できません。

oidctlのinst引数は整数です。つまり、最初のサーバー・インスタンスは1(inst=1)、2番目は2となります。

図B-1に、2つのOracle Internet Directoryインスタンスで構成される1つのOracle Internet Directoryコンポーネントを示します。各インスタンスは、非SSLポートおよびSSLポートを使用する独自のディスパッチャを備えています。どちらのディスパッチャも同じOIDMONで制御されます。

図B-1 2つのインスタンスで構成されるコンポーネント

この方法で新規インスタンスを作成すると、コンポーネント名に新規インスタンス番号を追加したインスタンス固有の構成エントリも新規に作成されます。たとえば、最初のインスタンス固有の構成エントリを次のように仮定します。

cn=oid1,cn=osdldapd,cn=subconfigsubentry

2番目のインスタンス固有の構成エントリは、次のようになります。

cn=oid1_2,cn=osdldapd,cn=subconfigsubentry

これらの2つのインスタンスは、LDAPツールまたはOracle Directory Services Managerを使用して別々に管理できます。この新規インスタンスはWebLogicドメインに登録できないため、この管理にはOracle Enterprise Manager Fusion Middleware ControlやWLSTを使用できません。

この方法でOracle Internet Directoryインスタンスを作成した場合、ファイル・システムの新規パス名は生成されません。同じOracle Internet Directoryコンポーネントに属するインスタンスは、同じ構成ファイルから読み取られ、同じログ・ディレクトリのログ・ファイルに書き込まれます。

Oracle Internet Directory 11g リリース1では、下位互換性のために、oidctl addを使用してデフォルト属性値でインスタンスを作成することもできます。

B.2 OIDCTLを使用したOracle Internet Directoryサーバー・インスタンスの作成と起動

oidctl addを使用して既存のコンポーネント内に別のOracle Internet Directoryサーバー・インスタンスを作成し、サーバーを起動できます。このコマンドによってサーバーの起動も行われます。

注意:

- oidctlコマンドを実行する前に、環境変数ORACLE_INSTANCEおよびORACLE_HOMEを設定する必要があります。

- oidctlでOracle Internet Directoryのインスタンス名とコンポーネント名を指定しないと、それぞれデフォルト値のinst1およびoid1がコマンドで使用されます。別の値を指定する必要がある場合、環境変数INSTANCE_NAMEおよびCOMPONENT_NAMEを設定するか、コマンド行でname=instanceNameおよびcomponentname=componentNameとしてインスタンス名とコンポーネント名を渡します。

- ベスト・プラクティスは、第8章「Oracle Internet Directoryインスタンスの管理」の説明にあるように、Oracle Internet Directoryコンポーネントを新規作成して新しいOracle Internet Directoryインスタンスを作成することです。Oracle Internet Directoryをスタンドアロン・モードで実行し、Oracle Enterprise Manager Fusion Middleware Controlをまったく使用しない計画の場合は、oidctlのみを使用してインスタンスを作成する必要があります。

oidctl addを使用してサーバーを作成し、起動するには、次のように入力します。

oidctl connect=connect_string server=oidldapd inst=new_instance_number \
name=instanceName componentname=componentName  \
flags="port=non_ssl_port sport=ssl_port" add

oidctl addで次の構成エントリが新たに作成されます。

cn=componentName_new_instance_number,cn=osdldapd,cn=subconfigsubentry

通常、元のインスタンスのinst値は1、作成した2番目のインスタンスは2となります。次に例を示します。

oidctl connect=oiddb server=oidldapd inst=2 flags="port=3322 sport=3323" add

B.3 OIDCTLを使用したOracle Internet Directoryサーバー・インスタンスの停止

コンポーネント内にoidctlを使用して作成したOracle Internet Directoryサーバー・インスタンスがあり、インスタンスが起動している場合、次のように入力して停止できます。

oidctl connect=connect_string server=oidldapd inst=new_instance_number stop

次に例を示します。

oidctl connect=oiddb server=oidldapd inst=2 stop

B.4 OIDCTLを使用したOracle Internet Directoryサーバー・インスタンスの起動

コンポーネント内にoidctlを使用して作成したOracle Internet Directoryサーバー・インスタンスがあり、インスタンスが停止している場合、次のように入力して起動できます。

oidctl connect=connect_string server=oidldapd inst=new_instance_number start

次に例を示します。

oidctl connect=oiddb server=oidldapd inst=2 start

サーバーは、インスタンスの作成時に指定したportフラグとsportフラグを使用して起動されます。

B.5 OIDCTLを使用したステータス情報の表示

oidctlを使用してステータスを表示できます。次のように入力します。

oidctl connect=connect_string status

コマンドoidctl statusでは、ホストで稼働しているすべてのOracle Internet Directoryインスタンス(別のOracleインスタンスの場合も)のステータスが表示されます。

B.6 OIDCTLを使用したOracle Internet Directoryサーバー・インスタンスの削除

コンポーネント内の1つのOracle Internet Directoryサーバー・インスタンスを停止して削除するには、次のように入力します。

oidctl connect=connect_string server=oidldapd inst=new_instance_number \
name=instanceName componentname=componentName delete

connect、serverおよびinst引数のみが必須です。oidctl deleteで構成エントリが削除されます。

cn=componentName_new_instance_number,cn=osdldapd,cn=subconfigsubentry

通常、元のインスタンスのinst値は1、作成した2番目のインスタンスは2となります。次に例を示します。

oidctl connect=oiddb server=oidldapd inst=2 delete

C Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーションの設定

この付録では、Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーションを設定する方法について説明します。

11g リリース1(11.1.1)以降では、一方向および双方向レプリケーションに加えて、マルチマスター・レプリケーションにLDAPベース・レプリケーションを使用できます。このため、Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーションは、10g(10.1.4.0.1)の場合よりも重要性が低くなっています。11g リリース1でアドバンスト・レプリケーションを使用する必要があるのは、同じマシン上にOracle Single Sign-Onが構成されているときに、Oracle Internet DirectoryのデータとOracle Single Sign-Onのデータをレプリケートする場合に限られます。

この付録の内容は次のとおりです。

- 第C.1項「Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーションの設定の概要」

- 第C.2項「アドバンスト・レプリケーション・ベースのレプリケーションの設定」

注意:
この付録で言及するOracle Single Sign-OnおよびOracle Delegated Administration ServicesはすべてOracle Single Sign-On 10g(10.1.4.3.0)以上およびOracle Delegated Administration Services 10g(10.1.4.3.0)以上のことです。

C.1 Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーションの設定の概要

11g リリース1でアドバンスト・レプリケーションを設定するには、コマンド行を使用する必要があります。Oracle Enterprise Manager Fusion Middleware Controlのレプリケーション・ウィザードは、LDAPベースのレプリケーションの設定にのみ使用できます。

C.1.1 データベース・バージョンの互換性

Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーションを使用する場合、同じディレクトリ・レプリケーション・グループのすべてのノードで同じバージョンのOracle Databaseが稼働している必要があります。

C.1.2 部分レプリケーションのためのアドバンスト・レプリケーションのフィルタリング

この項では、部分レプリケーション用にアドバンスト・レプリケーションを設定する場合の規則およびベスト・プラクティスについて説明します。この付録には、次の項があります。

関連項目:
第6.2.1項「レプリケートされるコンテンツ: 完全または一部」

C.1.2.1 除外されるネーミング・コンテキスト

アドバンスト・レプリケーションで可能なのは、ネーミング・コンテキストの除外のみです。

Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーションでネーミング・コンテキストをレプリケーションから除外するには、Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーション承諾エントリorclagreementid=000001のorclexcludednamingcontext属性で除外ネーミング・コンテキストを指定します。

図C-1およびその後に続く説明では、ネーミング・コンテキスト・コンテナとそのオブジェクトの使用方法の詳細を示します。

図C-1 ネーミング・コンテキスト・コンテナおよびオブジェクトの例

図C-1で、レプリケーションに含まれるネーミング・コンテキストはc=usです。このネーミング・コンテキスト内では、1つのサブツリー(cn=users,cn=hr, c=us)がレプリケーションから除外されています。さらに、ネーミング・コンテキストc=usのuserPasswordおよびtelephonenumberという2つの属性がレプリケーションから除外されています。

関連項目:
第42.1.5項「レプリケーションのネーミング・コンテキスト・オブジェクト・エントリ」

C.1.2.2 アドバンスト・レプリケーションのフィルタリングの規則

この項では、アドバンスト・レプリケーションのフィルタリングの規則について説明します。

次のネーミング・コンテキストはレプリケートできません。

- DSEルート固有のエントリ

- orclagreementid=000001,cn=replication configuration

- cn=subconfigsubentry

- cn=Oracle Internet Directory

- cn=subregistrysubentry

次のネーミング・コンテキストはレプリケーションから除外できません。

- cn=catalogs

- cn=subschemasubentry

- cn=oracleschemaversion

- cn=replication configuration

C.2 アドバンスト・レプリケーション・ベースのレプリケーションの設定

この項では、マルチマスター・レプリケーション・グループの構成の方法、およびそのグループでの競合を手動で解決する方法について説明します。この項の内容は、次のとおりです。

- 第C.2.1項「アドバンスト・レプリケーションの設定の規則」

- 第C.2.2項「アドバンスト・レプリケーション・ベースのマルチマスター・レプリケーション・グループの設定」

- 第C.2.3項「アドバンスト・レプリケーション・ベースのマルチマスター・レプリケーションのノードの追加」

- 第C.2.4項「マルチマスター・レプリケーション・グループからのノードの削除」

関連項目:
『Oracle Fusion Middleware高可用性ガイド』のマルチマスター・レプリケーションに関する章

C.2.1 アドバンスト・レプリケーションの設定の規則

次の9つの規則は、アドバンスト・レプリケーション(ASRとも呼ばれます)・ベースのレプリケーションに適用されます。

1. このタイプのディレクトリ・レプリケーション・グループ(DRG)では、1つのノードをマスター定義サイト(MDS)として指定する必要があります。これは、グループ・マスターです。このレプリケーションに参加している他のすべてのノードはレプリカで、データベース・レプリケーションではリモート・マスター・サイト(RMS)と呼ばれます。

注意:
Oracle Databaseアドバンスト・レプリケーション・ベースのレプリカは、中央のマスターではありませんが、次の2つの理由によってリモート・マスター・サイト(RMS)と呼ばれることがあります。第1に、アドバンスト・レプリケーションでは、情報がサイト間で移動するときに、転送された情報の受信側はリモート・マスター・サイトと呼ばれるためです。第2に、Oracle Databaseアドバンスト・レプリケーション・ベースのレプリカに対して直接行われる個別の変更は、そのグループのすべてのメンバーにもレプリケートされるため、相互作用時にそのレプリカがマスターとなるためです。このようにメンバーに対する変更が他のすべてのメンバーにレプリケートされるグループは、マルチマスター・レプリケーション・グループと呼ばれます。

2. マルチマスター・レプリケーションの構成を行う場合、ディレクトリ・レプリケーション・グループ(DRG)のマスター・ノードとOracle Databaseアドバンスト・レプリケーション・ベースのレプリカになる各ノードが最初は空であることが必要です。つまり、Oracle Internet Directoryを新たにインストールする必要があります。

注意:
マスター・ノードが新規インストールでない場合は、第C.2.3項「アドバンスト・レプリケーション・ベースのマルチマスター・レプリケーションのノードの追加」で説明する手順に従って、レプリカを追加します。この手順では、レプリケーション・グループの初期化も行います。

3. Oracle Databaseアドバンスト・レプリケーション・ベースのレプリカを追加する場合、新規レプリカが空であることが必要です。つまり、Oracle Internet Directoryを新たにインストールする必要があります。

4. Oracle Databaseアドバンスト・レプリケーション・ベースの各レプリカのスポンサ・ノードは、次のいずれかです。

- マスター・ノード

- 既存のマルチマスターDRGのOracle Databaseアドバンスト・レプリケーション・ベースのレプリカ

- LDAPレプリカ(その他のLDAPレプリカのコンシューマLDAPレプリカではない)のサプライヤ

5. Oracle Databaseアドバンスト・レプリケーション・ベースのレプリカは、LDAPレプリカのコンシューマになることはできません。

6. Oracle Internet Directory 11g リリース1では、1つのノードを複数のマルチマスター・レプリケーション・グループの一部にすることはできません。

7. DSEルート固有のデータ、サーバー構成データおよびレプリケーション承諾データは、ディレクトリ・レプリケーション・グループのサーバー間でレプリケートされるデータには含まれません。

関連項目:
第C.1.2項「部分レプリケーションのためのアドバンスト・レプリケーションのフィルタリング」

8. マルチマスター・レプリケーション・グループを構成すると、Oracle Single Sign-Onデータベース・スキーマが自動的にレプリケーション内に構成されます。

9. DRGにノードを追加する場合、そのノードは、DRG内の他のノードと同じリリースのOracle Internet Directoryを実行している必要があります。新規の10g(10.1.4.0.1)ノードを旧リリースのノードを含むDRGに追加する場合は、まず既存のノードすべてを10g(10.1.4.0.1)にアップグレードします。

C.2.2 アドバンスト・レプリケーション・ベースのマルチマスター・レプリケーション・グループの設定

この項では、マルチマスター・レプリケーション・グループをインストールおよび設定する際に実行する一般的なタスクを説明します。この項の内容は、次のとおりです。

- タスク1: マスター定義サイト(MDS)へのOracle Internet Directoryのインストール

- タスク2: リモート・マスター・サイト(RMS)へのOracle Internet Directoryのインストール

- タスク3: ディレクトリ・レプリケーション・グループ用のアドバンスト・レプリケーションの設定

- タスク4(オプション): ディレクトリへのデータのロード

- タスク5: 全ノードでOracleディレクトリ・サーバー・インスタンスが起動していることの確認

- タスク6: DRGの全ノードでのレプリケーション・サーバーの起動

- タスク7: ディレクトリ・レプリケーションのテスト

注意:

- この項の説明は、空のノードのグループ内におけるレプリケーションの設定に適用されます。DRGのすべてのノードにディレクトリ・データが存在していないと仮定しています。既存のDRGにノードを追加する方法は、第C.2.3項「アドバンスト・レプリケーション・ベースのマルチマスター・レプリケーションのノードの追加」を参照してください。

- ディレクトリ・レプリケーション・サーバーでは、エントリのレプリケーション時に識別名の各相対識別名コンポーネント間の空白が必ずしも保持されるとはかぎりません。まれに、識別名の文字の大文字と小文字の区別が保持されない場合があります。

C.2.2.1 タスク1: マスター定義サイト(MDS)へのOracle Internet Directoryのインストール

『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』の説明に従って、マスター定義サイトにOracle Internet Directoryをインストールします。

Oracle Net Servicesを使用して、マスター定義サイトのデータベースおよびDRG内の他のすべてのノードに接続できる必要があります。

注意:
インストール時に、各Oracle Internet Directoryのデータベース・インスタンス名が各マシンで一意であることを確認してください。

C.2.2.2 タスク2: リモート・マスター・サイト(RMS)へのOracle Internet Directoryのインストール

Oracle Internet Directoryをマスター・サイトへのインストールと同じ方法でリモート・マスター・サイトへインストールします。Oracle Internet Directoryのインストールの詳細は、『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』を参照してください。

C.2.2.2.1 既存のマスターをリモート・マスター・サイトとして使用する場合

空のレプリカから開始することをお薦めしますが、レプリカではなく最初にマスターとして構成されたマシンを使用してレプリケーションを設定できます。最初にマスター(RMS)として構成されたマシンを使用する場合は、次のように、まずメタデータをMDSに移行する必要があります。

- プロセス(remtool –backupmetadata)が正しく機能するように、Oracle Internet DirectoryサーバーがMDSおよび対象となる各レプリカで稼働していることを確認します。

- 新たに作成したノードから、次のコマンドを実行します。

remtool –backupmetadata \
–replica "new_node_host:new_node_port" \
–master "master_host:master_port"

master_host:master_portは、対象となるレプリカのサプライヤのホスト名およびポート番号です。レプリケーション識別名のパスワードを要求されます。

注意:
Oracle Delegated Administration Servicesが構成されていない場合、remtoolを-backupmetadataオプションを指定して実行すると、次のようなエラー・メッセージが表示されます。

Failed to add "orclApplicationCommonName=ias.example.com,
cn=IAS Instances, cn=IAS, cn=Products, cn=OracleContext"
as "uniquemember" to entry "cn=Associated Mid-tiers,
orclapplicationcommonname=DASApp, cn=DAS,cn=products,
cn=OracleContext at replica ldap://myhost:3060

このエラー・メッセージは無視してください。

- このツールは、メタデータをマスター・レプリカにロードする以外に、メタデータのバックアップを含むocbkup.new_replica_id.TO.master_replicaid.timestamp.datという名前のファイルを作成します。このファイルはORACLE_INSTANCE /diagnostics/logs/OID/toolsディレクトリに作成されます。このファイルには、LDIF形式でのマスター・レプリカの変更と、SSOのコンテナ・エントリ[orclApplicationCommonName=ORASSO_SSOSERVER, cn=SSO, cn=Products, cn=OracleContext]およびDASのURLコンテナ・エントリ[cn=OperationURLs, cn=DAS, cn=Products, cn=OracleContext]のコピーが格納されます。

- メタデータのバックアップに成功すると、端末に次のメッセージが表示されます。

Backup of metadata will be stored in
ORACLE_INSTANCE/diagnostics/logs/OID/tools/ocbkup.replicaid_pilot.TO.replcicaid_master.timestamp.ldif.

Metadata copied successfully.

メッセージには、ORACLE_INSTANCEの実際のパスとファイル名が含まれます。

- この操作を行っている間にエラーが発生した場合、remtoolを起動した端末にエラーが表示されます。エラー・メッセージは、ORACLE_INSTANCE/diagnostics/logs/OID/tools/remtool.logファイルにも記録されます。

マスターのメタデータをMDSに正しく移行できたら、次は、「タスク3: ディレクトリ・レプリケーション・グループ用のアドバンスト・レプリケーションの設定」に進みます。

C.2.2.3 タスク3: ディレクトリ・レプリケーション・グループ用のアドバンスト・レプリケーションの設定

次の各項では、レプリケーション管理ツールを使用してアドバンスト・レプリケーションをインストールおよび設定する方法を説明します。

関連項目:
Oracle Databaseアドバンスト・レプリケーションの設定方法は、Oracle Databaseドキュメント・ライブラリの『Oracle Databaseアドバンスト・レプリケーション』、およびレプリケーション管理ツールのオンライン・ヘルプを参照してください。

ディレクトリ・レプリケーション・グループ(DRG)を設定するには、次のタスクを実行してアドバンスト・レプリケーション環境を構成する必要があります。

- 第C.2.2.3.1項「全ノードでのレプリケーション用のOracle Net Services環境の準備」

- 第C.2.2.3.2項「ディレクトリ・レプリケーション用のアドバンスト・レプリケーションのMDSからの構成」

C.2.2.3.1 全ノードでのレプリケーション用のOracle Net Services環境の準備

ディレクトリ・レプリケーション・グループの各ノードについて、次の手順を実行します。(各手順の詳細は、このリストに続く項を参照してください。)

1. sqlnet.oraを構成します。

2. 各Oracle Internet Directory ORACLE_INSTANCEおよびOracle Database ORACLE_INSTANCEでtnsnames.oraを構成します。

3. Oracle Internet Directory ORACLE_HOMEとOracle Database ORACLE_HOMEの両方でリスナーを停止し、再起動します。

4. DRGの各ノードで、全ノードに対してOracle Net接続をテストします。

Oracle Net Services環境をレプリケーション用に準備する手順は、次のとおりです。

1. sqlnet.oraを構成します。
sqlnet.oraファイルには、少なくとも次のパラメータが記述されている必要があります。

names.directory_path = (TNSNAMES)
names.default_domain = global_database_domain

UNIXでは、sqlnet.oraファイルはORACLE_INSTANCE/network/adminにあります。

Microsoft Windowsでは、sqlnet.oraファイルは%ORACLE_HOME%\network\adminにあります。

2. 各Oracle Internet Directory ORACLE_INSTANCEおよびOracle Database ORACLE_INSTANCEでtnsnames.oraを構成します。

DRGの各ノードで、DRGのすべてのOracle Internet Directoryデータベース・インスタンスを定義します。Oracle Internet Directory ORACLE_INSTANCEおよびOracle Database ORACLE_HOMEで、各tnsnames.oraファイルに、それぞれのOracle Internet Directoryデータベースに対する接続記述子情報が次の形式で記述されている必要があります。

net_service_name =
(DESCRIPTION =
(ADDRESS =
(PROTOCOL = TCP)
(HOST = HOST_NAME_OR_IP_ADDRESS)
(PORT = port_no_of_listener))
(CONNECT_DATA =(service_name = service_name_of_database)))

net_service_nameはデータベースのグローバル名です。たとえば、データベースのグローバル名がmds.sales.comの場合、net_service_nameはmds.sales.comであることが必要です。データベースのグローバル名およびnet_service_nameがドメイン修飾されていることを確認してください。この例の場合、グローバル名とnet_service_nameはsales.comでドメイン修飾されています。

注意:

- データベースのグローバル名は、データベースの初期化パラメータDB_NAMEとDB_DOMAINで構成されます。たとえば、データベースのDB_NAMEがmdsで、DB_DOMAINがsales.comである場合、そのデータベースのグローバル名はmds.sales.comになります。DB_DOMAIN初期化パラメータが定義されていない場合、グローバル名はドメイン修飾されません。

- sqlnet.oraファイルのNAMES.DEFAULT_DOMAINパラメータの値は、データベースのDB_DOMAIN初期化パラメータの値と一致している必要があります。

- ネット・サービス名(例: sales.com)はドメイン修飾する必要があります。ただし、そのドメイン・コンポーネントがsqlnet.oraファイル内のNAMES.DEFAULT_DOMAINパラメータで指定されているドメイン・コンポーネントと一致していることを確認してください。

関連項目:
tnsnames.ora構文の詳細は、『Oracle Database Net Servicesリファレンス』を参照してください。

UNIXでは、tnsnames.oraファイルは、ORACLE_INSTANCE/configにあります。

Microsoft Windowsでは、tnsnames.oraファイルは%ORACLE_INSTANCE%\configにあります。

3. Oracle Internet Directory ORACLE_HOMEとOracle Database ORACLE_HOMEの両方でリスナーを停止し、再起動します。

Oracle Internet Directoryデータベースのリスナーを停止するには、Oracle Database Oracleホームでリスナー制御ユーティリティ$ORACLE_HOME/bin/lsnrctlを使用します。lsnrctlコマンド・プロンプトで、次のコマンドを入力します。

SET PASSWORD
STOP [listener_name]

SET PASSWORDは、パスワードがlistener.oraファイルで設定されている場合にのみ必要です。設定するパスワードの入力を求められます。デフォルトのリスナー名はLISTENERです。

Oracle Internet Directoryデータベースのリスナーを再起動するには、lsnrctlコマンド・プロンプトで次のコマンドを入力します。

START [listener_name]

quit

4. DRGの各ノードで、全ノードに対してOracle Net接続をテストします。

重要: 次の2つのコマンドを使用して接続を試みます。

sqlplus ods@net_service_name_without_domain_name
sqlplus ods@net_service_name_with_domain_name

ods_passwordが要求されます。接続できない場合、レプリケーションは行われません。

C.2.2.3.2 ディレクトリ・レプリケーション用のアドバンスト・レプリケーションのMDSからの構成

この手順は、次のとおりです。

1. MDSコンソールから、システム・ユーザーとしてすべてのノード(MDSを含む)に接続します。すべてのノードで、次のことを確認してください。

- Oracle Internet Directoryデータベースが実行中であること

- Oracle Internet Directoryリスナーが実行中であること

- 接続文字列が正しいこと

- システム・パスワードが正しいこと

2. 次のウォレットがリモート・サイトに存在することを確認してください。

- Oracle Internet Directoryに指定されたデータベースにパスワードを保存するためのウォレット。このウォレットは、oidpwdlldap1という名前で、ディレクトリORACLE_INSTANCE/OID/adminにあります。

- レプリケーション管理者のパスワードを保存するためのウォレット。このウォレットは、oidpwdroracle_sidという名前で、ディレクトリORACLE_INSTANCE/OID/adminにあります。(oracle_sidは、接続データベースから取得されます。)

ウォレットが特定のサイトに存在しない場合は、リモート・ノードで次のコマンドを入力して作成します。

oidpasswd connect=connect_string create_wallet=true

3. MDSおよびRMSサイトのすべてのOracle Internet Directoryサーバー・プロセスを停止します。

MDSのコマンド・プロンプトでremtool(レプリケーション環境管理ツール)を使用し、次のコマンドを実行してアドバンスト・レプリケーションを構成します。

$ORACLE_HOME/ldap/bin/remtool -asrsetup

設定操作の完了後、すべてのOracle Internet Directoryプロセスとレプリケーション・サーバー・プロセスを再起動できます。

注意:
アドバンスト・レプリケーション・ノードがリモート・マスター・サイトにすでに存在する場合、remtool -asrsetupの実行時にそのノードのデータ・エントリが削除されます。

関連項目:

- レプリケーション環境管理ツール(remtool)の-asrsetupオプションの使用方法の詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のremtoolコマンド行ツールのリファレンスを参照してください。

- データベースとリスナーが稼働中であることを確認する方法は、Oracle Databaseドキュメント・ライブラリの『Oracle Database管理者ガイド』を参照してください

- 接続文字列が正しいことを確認する方法は、Oracle Databaseドキュメント・ライブラリの『Oracle Database Net Services管理者ガイド』を参照してください

注意:

- エラーが発生した場合は、レプリケーション環境管理ツールの-asrcleanupオプションを使用して、環境をクリーンアップします。その後、手順3を繰り返します。

- 「タスク3: ディレクトリ・レプリケーション・グループ用のアドバンスト・レプリケーションの設定」の一部として、レプリケーション環境管理ツール(remtool)はレプリケーション構成パラメータのデフォルト値を設定します。これにより、レプリケーション・サーバーを起動できます。レプリケーション構成パラメータを変更する場合は、次を参照してください。第43章「レプリケーションの管理およびモニタリング」。

C.2.2.4 タスク4(オプション): ディレクトリへのデータのロード

データをディレクトリにロードする方法は、次の2つから選択できます。

- DRGに追加するエントリが少数の場合は、DRGの構成が完了するまで待ちます。ldapaddを使用して、データをいずれかのノードにロードします。その後、エントリは指定した時間に他のノードにレプリケートされます。

- DRGにロードするデータが大量の場合は、bulkloadユーティリティを使用します。

1. 次のように入力して、DRGのすべてのノードでLDAPサーバーを停止します。

opmnctl stopproc process-type=OID

2. DRGの一部であり、ldifファイルをディレクトリにロードするノード上で、ORACLE_INSANCEが設定されていることを確認し、次のように入力します。

bulkload connect="connect_string" check="TRUE" \
generate="TRUE" file="file_with_absolute_path_name"

注意:
ldifwriteを使用してOracle Internet Directoryからデータを抽出した場合は、他のオプションに加え、restore="TRUE"オプションを使用して、操作属性をリストアします。

3. 同一ノードでORACLE_INSTANCEが設定されていることを確認し、次を入力します。

bulkload connect="connect_string_1" load="TRUE"

同じノードで手順cを繰り返し、DRGのすべてのノードにデータをロードするまで、毎回、connect_string_1をDRGの別のノードの接続文字列で置き換えます。たとえば、次のように入力します。

bulkload connect="connect_string_2" load="TRUE"

さらに、次のように入力します。

bulkload connect="connect_string_3" load="TRUE"

同様の手順で、DRG内のすべてのノードにデータをロードします。

注意:

- connect_stringは、ローカルOracle Internet Directoryデータベースの接続文字列です。

- レプリケーションを正常に行うには、レプリケートされるすべてのノードで、エントリに同じorclguid(グローバル識別子)が含まれている必要があります。そのためには、手順bを1度実行し、DRG内の各ノードについて手順cを繰り返します。

関連項目:
構文と使用方法の詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のbulkloadコマンド行ツールのリファレンスを参照してください。

C.2.2.5 タスク5: 全ノードでOracleディレクトリ・サーバー・インスタンスが起動していることの確認

デフォルトの構成では、Oracle Internet Directory LDAPサーバー・インスタンス#1の変更ロギングはTRUEに設定されています。Oracle Internet Directory LDAPサーバーのデフォルトのインスタンスは、次のように指定すると開始されます。

opmnctl startproc process-type=OID

C.2.2.6 タスク6: DRGの全ノードでのレプリケーション・サーバーの起動

すべてのノードでレプリケーション・サーバーを起動するには、各ノードで次のコマンドを入力します。

oidctl connect=connStr server=oidrepld instance=1 componentname=oidComponentName \
flags="-h LdapHost -p LdapPort" start

インスタンス番号は、DRG全体で一意である必要はありません。

注意:
読取り専用のレプリカ・コンシューマを持つ単一のマスターをデプロイする場合、競合解消をオフにすると、パフォーマンス・オーバーヘッドを低減できます。これを行うには、ldapmodifyで次のLDIFファイルを使用して、orclconflresolutionの値を0に変更します。

dn: cn=configset0,cn=osdrepld,cn=subconfigsubentry
changetype: modify
replace: orclconflresolution
orclconflresolution: 0

関連項目:

Oracle Internet Directoryのプロセス制御の詳細は、第4章「Oracle Internet Directoryコンポーネントのプロセス制御の理解」を参照してください。

C.2.2.7 タスク7: ディレクトリ・レプリケーションのテスト

第40.4項「Oracle Directory Services Managerを使用したレプリケーションのテスト」の説明に従って、レプリケーションをテストします。

注意:
Oracle Single Sign-Onのレプリケーションを構成するには、Oracle Single Sign-On用のインストール後の手順を実行します。詳細は、10g (10.1.4.0.1)のライブラリで『Oracle Application Server Single Sign-On管理者ガイド』のOracle Directory Services Managerを使用したレプリケーションのテストに関する項を参照してください。

C.2.3 アドバンスト・レプリケーション・ベースのマルチマスター・レプリケーションのノードの追加

注意:
既存のマルチマスター・レプリケーション・グループに追加する新規ノードには、Oracle Internet Directoryがインストールされている必要があります。詳細は、「タスク2: リモート・マスター・サイト(RMS)へのOracle Internet Directoryのインストール」を参照してください。

マスター・ノード、または他のLDAPベースのレプリカのコンシューマではないLDAPベースのサプライヤ・レプリカにノードを追加し、マルチマスターDRGを形成できます。その場合、この項の手順に従えば、アドバンスト・レプリケーションの初期インストールおよび構成が自動的に実行されます。

稼働中のレプリケーション・グループまたは大規模なマスター・ノードに新規レプリケーション・ノードを追加するには、次の手順を実行します。

- Oracle Net Services環境の準備

- タスク1: 全ノードでのディレクトリ・レプリケーション・サーバーの停止

- タスク2: スポンサ・ノードの特定とOracle Internet Directoryのインストール

- タスク3: スポンサ・ノードの読取り専用モードへの切替え

- タスク4: ldifwriteを使用したスポンサ・ノードのバックアップ

- タスク5: アドバンスト・レプリケーションのノード追加設定の実行

- タスク6: スポンサ・ノードの更新可能モードへの切替え

- タスク7: 新規ノード以外の全ノードでのディレクトリ・レプリケーション・サーバーの起動

- タスク8: bulkloadを使用した新規ノードへのデータのロード

- タスク9: 新規ノードでのディレクトリ・サーバーの起動

- タスク10: 新規ノードでのディレクトリ・レプリケーション・サーバーの起動

注意:
以降の各タスクの中で示されているコマンドを実行するには、次のタイプのファイルが、対応するディレクトリに格納されている必要があります。

- バイナリ: $ORACLE_HOME/bin

- SQLスクリプト: $ORACLE_HOME/ldap/admin

- UNIXスクリプト: $ORACLE_HOME/ldap/bin

「タスク2: スポンサ・ノードの特定とOracle Internet Directoryのインストール」を開始する前に、これら3つのタイプのファイルがそれぞれのパスに存在することを確認してください。

C.2.3.1 Oracle Net Services環境の準備

この環境を準備するプロセスは、第C.2.2.3.1項「全ノードでのレプリケーション用のOracle Net Services環境の準備」で説明されています。

C.2.3.2 タスク1: 全ノードでのディレクトリ・レプリケーション・サーバーの停止

ディレクトリ・レプリケーション・サーバーを停止するには、LDAPレプリケーション・グループ内の各ノードで次のコマンドを実行します。

oidctl connect=connStr server=oidrepld instance=1 componentname=oidComponentName\
flags="-h LdapHost -p LdapPort" stop

C.2.3.3 タスク2: スポンサ・ノードの特定とOracle Internet Directoryのインストール

このタスクのスポンサ・ノードを識別する必要があります。これは、新規ノードにデータを供給するノードです。

RMS用には、Oracle Internet Directoryの新規インスタンスをアドバンスト・レプリケーション・レプリカとしてインストールすることをお薦めします。(既存のマスター・ノードをRMSとして使用することも可能ですが、手動の手順を別途実行する必要があります。)

新しいOracle Internet Directoryをリモート・サイトにインストールします。

既存のマスターをRMSとして使用する場合は、第C.2.2.2.1項「既存のマスターをリモート・マスター・サイトとして使用する場合」の指示に従って、マスターのメタデータをスポンサ・ノードに移行する必要があります。マスターのメタデータをMDSに正しく移行できたら、次は、「タスク3: スポンサ・ノードの読取り専用モードへの切替え」に進みます。

C.2.3.4 タスク3: スポンサ・ノードの読取り専用モードへの切替え

スポンサ・ノードは、新規ノードにデータを供給するノードです。スポンサ・ノードを読取り/書込みモードから読取り専用モードに切り替えるには、第15.2項「サーバー・モードの変更」の手順のいずれかを使用します。

注意:
スポンサ・ノードが読取り専用モードの間は、そのノードを更新できません。他のノードは更新できますが、その更新内容はすぐにはレプリケートされません。
また、スポンサ・ノードとMDSが同じノードの可能性もあります。

C.2.3.5 タスク4: ldifwriteを使用したスポンサ・ノードのバックアップ

この処理は時間がかかる場合もあるため、バックアップ処理中に"タスク5: アドバンスト・レプリケーションのノード追加設定の実行"を開始してもかまいません。

スポンサ・ノードでORACLE_INSTANCEが設定されていることを確認し、次のコマンドを入力します。

ldifwrite connect="connect_string" \
baseDN="orclAgreementID=000001,cn=replication configuration" \
file="output_ldif_file"

これで、スポンサ・ノードのディレクトリがバックアップされます。

C.2.3.6 タスク5: アドバンスト・レプリケーションのノード追加設定の実行

注意:
レプリケーションを行うすべてのノードで、Oracle Net Serviceが正しく構成されている必要があります。「全ノードでのレプリケーション用のOracle Net Services環境の準備」を参照してください。

アドバンスト・レプリケーションのノード追加設定は、「タスク4: ldifwriteを使用したスポンサ・ノードのバックアップ」を実行するときに同時に実行できます。

スポンサ・ノードで、次のコマンドを入力します。

remtool -addnode

レプリケーション環境管理ツールによって、DRGにノードが追加されます。

注意:

remtool -addnodeを実行してレプリケーション・グループの最初のアドバンスト・レプリケーション・レプリカを追加すると、remtool -asrsetupを使用した場合と同様のレプリケーションの初期設定が自動的に行われます。remtool -addnodeを使用する際には、スポンサ・ノードの接続識別子を指定する必要があります。

remtool -addnodeを使用する場合、レプリケートされた表の行数とノード間のネットワーク待機時間によっては、操作に長時間かかることがあります。この操作の進捗状況を確認するには、-vオプションを使用します。

エラーが発生した場合は、まず-asrverifyオプションを使用します。このオプションでもエラーが発生した場合には、-asrrectifyオプションを使用して、そのエラーを修正します。-asrverifyおよび-asrrectifyは、DRG内のすべてのノードをリストします。新規ノードがリストにある場合は、-delnodeオプションを使用してレプリケーション環境管理ツールを再度実行し、新規ノードを削除します。その後、-addnodeオプションを使用して新規ノードを再度追加します。

関連項目:
レプリケーション環境管理ツールの-addnodeオプションの使用方法は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のremtoolコマンド行のリファレンスを参照してください。

C.2.3.7 タスク6: スポンサ・ノードの更新可能モードへの切替え

スポンサ・ノードを更新可能モードに切り替えるには、第15.7項「catalogを使用した既存の属性の索引の作成および削除」の手順のいずれかを使用します。

注意:
タスク6は、タスク3と類似しています。この手順ではorclservermodeパラメータが読取り/書込みに設定される点のみが異なります。

C.2.3.8 タスク7: 新規ノード以外の全ノードでのディレクトリ・レプリケーション・サーバーの起動

ディレクトリ・レプリケーション・サーバーを起動するには、新規ノード以外のすべてのノード上で次のコマンドを入力します。

oidctl connect=connStr server=oidrepld instance=1 componentname=oidComponentName \
flags="-h LdapHost -p LdapPort" start

新規ノードでディレクトリまたはレプリケーション処理が何も実行されていないことを確認するため、次のように入力します。

opmnctl stopproc process-type=OID

C.2.3.9 タスク8: bulkloadを使用した新規ノードへのデータのロード

データをロードするには、ORACLE_INSTANCEが設定されていることを確認し、新規ノードで次のコマンドを入力します。

bulkload connect="db_connect_string_of_new_node" check="TRUE" generate="TRUE" \
load="TRUE" restore="TRUE" \
file="absolute_path_to_the_ldif_file_generated_by_ldifwrite"

注意:
Oracle Internet Directoryの旧リリース(10g リリース2(10.1.2.0.2)など)のデータを、10g(10.1.4.0.1)が稼働しているノードにロードする場合、パスワード・ポリシー・エントリを、第40.5.3項「パスワード・ポリシーとファンアウト・レプリケーション」で説明しているように更新する必要があります。

C.2.3.10 タスク9: 新規ノードでのディレクトリ・サーバーの起動

ディレクトリ・サーバーを起動するには、新規ノードで次のコマンドを入力します。

opmnctl startproc process-type=OID

C.2.3.11 タスク10: 新規ノードでのディレクトリ・レプリケーション・サーバーの起動

注意:
構成パラメータまたは承諾パラメータの変更が必要な場合は、第43章「レプリケーションの管理およびモニタリング」を参照してください。

ディレクトリ・レプリケーション・サーバーを起動するには、新規ノードで次のコマンドを入力します。

oidctl connect=connStr server=oidrepld instance=1 componentname=oidComponentName \
flags="-h LdapHost -p LdapPort" start

注意:

- ディレクトリ・サーバー・インスタンスがレプリケーション承諾のメンバーの場合、ノードへのデータの追加にbulkloadツールを使用しないでください。かわりにldapaddを使用してください。

- レプリケーションでOracle Single Sign-Onが必要な場合、10g (10.1.4.0.1)ライブラリの『Oracle Application Server Single Sign-On管理者ガイド』のレプリケーションのインストールに関する項のインストール後の手順に従ってください。

C.2.4 マルチマスター・レプリケーション・グループからのノードの削除

システム・エラーが発生して新しいノードを追加できなかった場合などは、ノードをDRGから削除する必要があります。

レプリケーション・ノードを削除するには、次のタスクを実行します。

- タスク1: 全ノードでのディレクトリ・レプリケーション・サーバーの停止

- タスク2: 削除するノード内の全Oracle Internet Directoryプロセスの停止

- タスク3: マスター定義サイトからのノードの削除

- タスク4: 全ノードでのディレクトリ・レプリケーション・サーバーの起動

C.2.4.1 タスク1: 全ノードでのディレクトリ・レプリケーション・サーバーの停止

ディレクトリ・レプリケーション・サーバーを停止するには、DRG内の各ノードで次のコマンドを実行します。

oidctl connect=connStr server=oidrepld instance=1 componentname=oidComponentName \
flags="-h LdapHost -p LdapPort" stop

C.2.4.2 タスク2: 削除するノード内の全Oracle Internet Directoryプロセスの停止

削除するノードでOracle Internet Directoryを停止します。

opmnctl stopproc process-type=OID

関連項目:
Oracle Internet Directoryの停止方法の詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のopmnコマンド行ツールのリファレンスを参照してください。

C.2.4.3 タスク3: マスター定義サイトからのノードの削除

MDSから、次のスクリプトを実行します。

remtool -delnode

レプリケーション環境管理ツールによって、レプリケーション・グループからノードが削除されます。

関連項目:
レプリケーション環境管理ツールの-delnodeオプションの使用方法は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のremtoolコマンド行ツールのリファレンスを参照してください。

この処理は、システム・リソースとDRGのサイズによって、長時間かかる場合があります。-vオプションを使用すると、進捗状況を確認できます。

注意:
エラーが発生した場合は、まず-asrverifyオプションを使用します。このオプションでもエラーが発生した場合には、-asrrectifyオプションを使用して、そのエラーを修正します。-asrverifyおよび-asrrectifyは、DRG内のすべてのノードをリストします。削除するノードがリストにない場合は、-delnodeオプションを使用してレプリケーション環境管理ツールを再度実行し、ノードを削除します。

C.2.4.4 タスク4: 全ノードでのディレクトリ・レプリケーション・サーバーの起動

ディレクトリ・レプリケーション・サーバーを起動するには、DRGのその他の各ノードで次のコマンドを入力します。

oidctl connect=connStr server=oidrepld instance=1 componentname=oidComponentName \
flags="-h LdapHost -p LdapPort" start

関連項目:
『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のopmnコマンド行ツールのリファレンス

D レプリケーションの動作

この付録では、レプリケーションの動作について説明し、Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーションの機能とアーキテクチャ、LDAPベースのレプリケーションのアーキテクチャ、LDAPのレプリカ状態およびレプリケーション・プロセスについて説明します。

この付録の内容は次のとおりです。

- 第D.1項「Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーションの機能」

- 第D.2項「Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーションのアーキテクチャ」

- 第D.3項「LDAPベースのレプリケーションのアーキテクチャ」

- 第D.4項「LDAPのレプリカ状態」

- 第D.5項「レプリケーション・プロセス」

注意:
この付録で言及するOracle Single Sign-Onはすべて、Oracle Single Sign-On 10g(10.1.4.3.0)以上のことです。

D.1 Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーションの機能

Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーションでは、レプリケーション承諾がなされたOracle Internet Directoryノード間における更新情報の転送は、Oracle Databaseアドバンスト・レプリケーションのストア/フォワード転送機能によって管理されます。アドバンスト・レプリケーションを使用すると、2つのOracleデータベース間で、データベース表を同期化させることができます。

注意:
デプロイメントで適切な場合、パフォーマンス向上のためにOracle Databaseアドバンスト・レプリケーション・ベースのレプリケーションではなく、LDAPベースのレプリケーションを使用することをお薦めします。

Oracle Databaseアドバンスト・レプリケーション:

- ローカルの変更内容を格納し、コンシューマに定期的にまとめて伝播します。コンシューマ・レプリケーション・サーバーは、リモートの変更内容をサーバー固有のローカルのディレクトリ・サーバーに適用し、ローカル・ストアから適用済のリモートの変更内容をパージします。

- Oracleレプリケーション・グループ内のどこにあるディレクトリ表に対しても読取りおよび更新アクセスできるようにします。一般的なアドバンスト・レプリケーション構成では、行レベル・レプリケーションが使用されます。

- 実証済のネットワーク・トレランスを提供します。データ転送を制御およびモニターできます。このような管理機能によって、データ移送のスケジュール方法に高度な柔軟性を与えることができます。

注意:
Oracle Internet Directoryと同じデータベース内に常駐するOracle Single Sign-Onのデータベース・スキーマも、アドバンスト・レプリケーションを使用してレプリケートします。

関連項目:

- 10g (10.1.4.0.1)ライブラリの『Oracle Application Server Single Sign-On管理者ガイド』の高可用性に関する章で、レプリケーション用のOracle Single Sign-Onの構成に関する項を参照してください。

- アドバンスト・レプリケーションの詳細は、Oracle Databaseドキュメント・ライブラリの『Oracle Databaseアドバンスト・レプリケーション』を参照してください。

D.2 Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーションのアーキテクチャ

一般的なOracle Databaseアドバンスト・レプリケーション構成では、サプライヤが変更内容を変更ログに書き込み、バッチ処理された変更を他のコンシューマに定期的に送信する非同期データ伝播を使用します。コンシューマは変更ログ・データを受信し、変更内容をローカルに適用します。

レプリケーションを構成する場合は、レプリケーション・グループ内で変更を共有するノードを指定します。レプリケーション環境に導入するノードの数にかかわらず、レプリケーションの基本アーキテクチャは同一です。ローカル変更がリモート・マスター・サイトに配布されると、クライアントとして機能するレプリケーション・サーバーによってOracle Internet Directoryサーバーにコマンドが送信され、ここでコマンドが実装されます。

図D-1とその後に続く説明では、Oracle Databaseアドバンスト・レプリケーション・プロセスの概要を示します。

図D-1 アドバンスト・レプリケーション・プロセス

プロセスは次のとおりです。

1. レプリカAのOracle Internet Directoryサーバーで変更リクエストが作成されます。

2. 変更は、受け入れられ、Oracle Internet Directoryデータベースのストレージにコミットされます。
2' この操作に対して新規の変更ログが生成され、ods_chg_log表(server = レプリカA)に格納されます。

3. レプリカA上のレプリケーション・サーバーは、ローカルのods_chg_log表に新規のアウトバウンド変更ログを問い合せます。この問合せには次のフィルタが使用されます。

(& (objectclass=changeLogEntry) (servername=ReplicaID_of_A)
(changeNumber>= Last_Applied_ChgNum_From_A_TO_A) )

この検索操作とともに、処理承諾で指定されたorclreplicationidの値で制御も渡されます。値1は、アドバンスト・レプリケーション承諾のために予約されています。

Last_Applied_ChgNum_From_A_TO_Aは、アウトバウンド変更ログ処理ステータスです。

3' ディレクトリ・サーバーは、ods_chg_logに新規の変更ログを内部的に問い合せて、フェッチした変更ログを返します。

4. ods_chg_logから取得した新規の変更ログは、ローカルのasr_chg_logにコピーされます。
4' レプリケーション・サーバーは、取得した変更ログをローカルのasr_chg_logにコピーします。

5. レプリケーション・サーバーは、Oracle Internet Directoryサーバーに対して、変更ログretry_cntのステータスを正しく更新するようにリクエストします。
5' Oracle Internet Directoryサーバーは、ods_chg_log表にある変更ログのretry_cntを更新します。

6. 新規の変更ログは、Oracle Databaseアドバンスト・レプリケーションを介して、レプリカAからレプリカBに送信されます。

7. レプリカBにおいて、前回移送された数が前回適用された変更の数より大きい場合は、ローカル変更ログ・ストアasr_chg_logに新規の変更があることを示しています。この場合、レプリカB上のレプリケーション・サーバーは、ローカルのasr_chg_log表に新規のインバウンド変更ログを問い合せます。次のフィルタが使用されます。

(& (objectclass=changeLogEntry) (servername=ReplicaID_of_A)
(changeNumber>= Last_Applied_ChgNum_From_A_TO_B))

7' ディレクトリ・サーバーは、asr_chg_logに新規の変更ログを問い合せます。

8. レプリケーション・サーバーは、レプリカBで新規の変更を適用します。

9. レプリカBのOracle Internet Directoryサーバーは、変更を受け入れ、Oracle Databaseのストレージにコミットします。
9' ローカル・レプリカにLDAPベースのコンシューマ・レプリカがある場合、変更ログがレプリカBにあるods_chg_log表で、次の規則に従って再生成されます。

server = server of local replica,
ReplicaB orclreplicationid/chg_rid = 1
Modifiersname = Replbind_DN_of_A

orclreplicatid/chg_ridは、処理承諾のorclreplicationidの値に設定されます。この場合、変更がアドバンスト・レプリケーションを介してレプリケートと処理が行われるため、値はアドバンスト・レプリケーション用に予約されている1に設定されます。

10. レプリケーション・サーバーは、Oracle Internet Directoryサーバーに対して、シャドウ変更ログretry_cntのステータスを正しく更新するようにリクエストします。
10' Oracle Internet Directoryサーバーは、データベースにあるシャドウ変更ログのretry_cntを更新します。

適用済のエントリや候補の変更に従って削除されたエントリのパージが定期的に発生します。ローカルの変更ログ表にあるリモート変更の記録は、その変更がローカルで適用されると、ガベージ・コレクション・スレッドによってパージされます。ローカルの変更ログ表にあるローカル変更の記録は、その変更がすべてのコンシューマに配布されると、ガベージ・コレクション・スレッドによってパージされます。

関連項目:
レプリケーションの構成方法は、第43章「レプリケーションの管理およびモニタリング」を参照してください。

D.3 LDAPベースのレプリケーションのアーキテクチャ

この項では、LDAPレプリケーションの詳細を説明します。Oracle Internet Directory 11g リリース1(11.1.1.7.0)以降では、LDAPレプリケーションのデータフローは適用キューを含む適用フェーズから構成されます。トランスポート・キューを含むトランスポート・フェーズは使用されなくなりました。

図D-2およびその後に続く説明で、ファンアウト・レプリケーション・プロセスを示します。

図D-2 LDAPレプリケーション・プロセス

1. LDAP変更リクエストが、レプリカAのOracle Internet Directoryサーバーで作成されます。

2. 変更は、受け入れられ、Oracle Internet Directoryデータベースのストレージにコミットされます。

3. この操作に対して新規の変更ログが生成され、ods_chg_log表に格納されます。

- server = レプリカA

- orclreplicationid/chg_rid = 0 (値0はユーザー操作用です。)

- Modifiersname = 修飾子のユーザー識別名(デフォルト)

4. レプリカBのレプリケーション・サーバーは、レプリカAのods_chg_log表から変更ログをフェッチし、メモリー内で部分的なレプリケーション・フィルタリングをいくつか実行した後、適用キューに直接変更ログを格納します。orclupdateschedule構成属性は、レプリケーションの頻度を決定します。

5. レプリカBのレプリケーション・サーバーは、レプリカBのOracle Internet Directoryサーバーに変更をストレージにコミットするようにリクエストします。

6. レプリカBのOracle Internet Directoryサーバーは、Oracle Internet Directoryデータベース記憶域に変更をコミットし、asr_chg_log表に変更をコピーし、再試行回数を-2に更新します。これらはすべて、単一のLDAPコールで実行されます。
コミット時に失敗が生じた場合、Oracle Internet Directoryサーバーはレプリケーション・サーバーにエラーをレポートし、asr_chg_log表に変更をコピーし、再試行回数を1ずつ減少させます。この場合、Oracle Internet Directoryサーバーはコミットを再適用できます。

すべての変更ログは、成否にかかわらず、レプリカBのasr_chg_log表にコピーされます。

7. レプリカBがその他のレプリカのソースである場合、レプリカBのods_chg_log表に変更ログが、次のchangelog再生成規則に従って再生成されます。

- server = ローカル・レプリカ、レプリカBのサーバー

- orclreplicationid/chg_rid = N

- Modifiersname = Replbind_DN_of_A

orclreplicatid/chg_ridは、処理承諾のorclreplicationid値に設定されます。

D.4 LDAPのレプリカ状態

この項では、LDAPベースのレプリケーションのレプリカ状態について説明します。LDAPのレプリカ状態は、アドバンスト・レプリケーションには影響しません。

LDAPベースのレプリケーションを構成し、レプリケーション・サーバーを起動すると、サーバーはローカルのレプリカ(orclreplicaid=local_Replica_ID, cn=replication configuration)からレプリカ状態orclreplicastateを読み取ります。表D-1に示すとおり、レプリケーション・サーバーの動作はローカルのレプリカ状態によって異なります。レプリケーション・サーバーは、ローカル(コンシューマ)・ノードからローカルのレプリカ状態を読み取ります。

注意:
WindowsシステムではorclReplicaStateの値を0に変更してブートストラップを有効にする前に、レプリケーション・サーバーが稼働していないことを確認します。

表D-1 LDAPのレプリカ状態

値

意味

サーバーの動作

0

ブートストラップ

レプリケーションのネーミング・コンテキスト構成に基づき、サプライヤからコンシューマ・ディレクトリを同期化するためのレプリケーションのブートストラップ・プロセスを開始する。ブートストラップの進行に合せてレプリカ状態を更新する。

- ブートストラップの開始直後は、レプリカ状態を3(ブートストラップ進行中)にする。

- cn=oraclecontextのブートストラップが正常に完了すると、レプリカ状態を4(ブートストラップ進行中、cn=oraclecontextのブートストラップが完了)にする。

- ブートストラップが完了したが、ブートストラップ中に障害が検出された場合は、レプリカ状態を5(ブートストラップ・エラーの発生)にする。次に、レプリカ状態がリセットされるまで待機する。
注意: 管理者操作が必要です。詳細は第R.1.13項「Oracle Internet Directoryレプリケーションに関するトラブルシューティング」を参照してください。

- ブートストラップが正常に完了すると、レプリカ状態を1(オンライン)にする。次に、レプリケーションを自動的に開始し、通常のレプリケーション・プロセスを実行する。

1

オンライン

通常のレプリケーション・プロセスを開始し、サプライヤからコンシューマへ変更をレプリケートする。

2

オフライン

エラー・メッセージを、次のようにoidrepld.logに記録する。

2004/09/24:17:41:44 * Replica(dlsun1418_replica2) is in
OFFLINE mode, Please update the replica state and restart
OIDREPLD...

管理者は、レプリカ状態を適切に設定し、レプリケーション・サーバーを再起動する必要がある。

3

ブートストラップ進行中

レプリカ状態を0(ブートストラップ)に戻し、状態が0である場合と同様に、ブートストラップを再度開始する。

4

ブートストラップ進行中、cn=oraclecontextのブートストラップが完了。

レプリカ状態を0(ブートストラップ)に戻し、状態が0である場合と同様に、ブートストラップを再度開始する。

5

ブートストラップの完了。1つ以上のネーミング・コンテキストで障害を検出。

エラー・メッセージを、次のようにoidrepld.logに記録する。

2004/09/24:17:13:30 * Replication BOOTSTRAP_ERROR mode detected for replica(dlsun1418_replica2)

次に、レプリカ状態が適切にリセットされるまで待機する。

6

データベース・コピー・ベースのaddnode。

このモードは、レプリカがデータベース・コピー・ベースのaddnodeであることを示す。

7

スキーマの同期化

サプライヤからコンシューマへの、データではなくスキーマの同期化。

8

スキーマを同期化しないブートストラップ

以前にスキーマの同期化が実行されているものの、後続の手順でブートストラップが失敗している場合には、スキーマの同期化を再実行せずに再度ブートストラップが開始される。

Oracle Internet Directoryレプリケーション・サーバーでは、Oracle Internet Directoryレプリケーション・サーバー・ログ($ORACLE_INSTANCE/diagnostics/logs/OID/componentName/oidrepld00.log)にブートストラップ・プロセスが記録されます。

ブートストラップが正常に完了した場合、ログは次の例と同様になり、レプリケーション・サーバーが自動的に通常のレプリケーション・プロセスを開始します。

2004/10/06:17:13:25 * Starting OIDREPLD against isunnad03:5555...
2004/10/06:17:13:26 * Starting scheduler...
2004/10/06:17:13:27 * Start to BootStrap from supplier=isunnad03_purify to consumer=isunnad03_purify3
2004/10/06:17:13:28 * gslrbssSyncDIT:Replicating namingcontext=cn=oraclecontext ......
2004/10/06:17:14:21 * gslrbssSyncDIT:Sync done successfully for namingctx: cn=oraclecontext, 222 entries matched
2004/10/06:17:14:21 * gslrbssSyncDIT:Replicating namingcontext=c=india ......
2004/10/06:17:14:21 * gslrbssSyncDIT:Sync done successfully for namingctx: c=india, 0 entries matched
2004/10/06:17:14:21 * gslrbssSyncDIT:Replicating namingcontext=c=uk ......
2004/10/06:17:19:57 * gslrbssSyncDIT:Sync done successfully for namingctx: c=uk, 1087 entries matched
2004/10/06:17:19:57 * gslrbssSyncDIT:Replicating namingcontext=cn=oracleschemaversion ......
2004/10/06:17:19:59 * gslrbssSyncDIT:Sync done successfully for namingctx: cn=oracleschemaversion, 10 entries matched
2004/10/06:17:20:01 * gslrbsbBootStrap: BOOTSTRAP DONE SUCCESSFULL

障害が検出された場合、ログは次の例と同様になります。

2004/09/14:12:57:23 * Starting OIDREPLD against dlsun1418:4444...
2004/09/14:12:57:25 * Starting scheduler...
2004/09/14:12:57:26 * Start to BootStrap from supplier=dlsun1418_replica to consumer=dlsun1418_replica2
2004/09/14:12:57:27 * gslrbssSyncDIT:Replicating namingcontext=cn=oraclecontext ......
2004/09/14:12:58:21 * gslrbssSyncDIT:Sync done successfully for namingctx: cn=oraclecontext, 222 entries matched
2004/09/14:12:58:21 * gslrbssSyncDIT:Replicating namingcontext=cn=quan zhou ......
2004/09/14:12:58:23 * BootStrap failure when adding DN=cn=Quan Zhou,server=dlsun1418_replica2,err=Constraint violation.
2004/09/14:12:58:23 * gslrbssSyncDIT:Sync failed for namingctx: cn=quan zhou, only 1 entries retrieved
2004/09/14:12:58:23 * gslrbssSyncDIT:Replicating namingcontext=cn=oracleschemaversion ......
2004/09/14:12:58:25 * gslrbssSyncDIT:Sync done successfully for namingctx: cn=oracleschemaversion, 10 entries matched
2004/09/14:12:58:51 * gslrbsbBootStrap: Failure occurred when bootstrapping 1 out of 3 namingcontext(s) from the supplier

ヒント:
ブートストラップの障害のトラブルシューティングには2つのオプションがあります。

- オプション1: ブートストラップの障害の原因を特定し、修正します。次に、コンシューマ・レプリカのorclreplicastateをブートストラップ・モードにして、ブートストラップを再起動します。

- オプション2: ブートストラップに失敗したネーミング・コンテキストを特定し、oidcmprecを使用してこれらを調整します。次に、コンシューマ・レプリカのorclreplicastateをオンライン・モードにして、レプリケーションを再開します。

注意:
このとき、OidrepldはBootstrap_errorモードになっているので、コンシューマ・レプリカのレプリカ状態(orclreplicastate)をリセットする必要があります。

D.5 レプリケーション・プロセス

この項では、マルチマスター・レプリケーション・プロセスによるエントリの追加、削除、変更方法、および識別名と相対識別名の変更方法について紹介します。この項の内容は、次のとおりです。

- マルチマスター・レプリケーション・プロセスがコンシューマに新規エントリを追加する動作

- マルチマスター・レプリケーション・プロセスがエントリを削除する動作

- マルチマスター・レプリケーション・プロセスがエントリを変更する動作

- マルチマスター・レプリケーション・プロセスが相対識別名を変更する動作

- マルチマスター・レプリケーション・プロセスが識別名を変更する動作

D.5.1 マルチマスター・レプリケーション・プロセスがコンシューマに新規エントリを追加する動作

ディレクトリ・レプリケーション・サーバーは、コンシューマに新規エントリを追加すると、次の変更適用プロセスを実行します。

1. ディレクトリ・レプリケーション・サーバーは、コンシューマ内でターゲット・エントリの親の識別名を探します。具体的には、その親の識別名に割り当てられているGlobal Unique Identifier(GUID)を探します。

2. 親エントリが存在している場合、ディレクトリ・レプリケーション・サーバーは新規エントリの識別名を作成し、コンシューマ内にあるその親の下に新規エントリを配置します。次に、変更エントリをパージ・キューに入れます。

1回目の試行で変更エントリが正常に適用されなかった場合:

ディレクトリ・レプリケーション・サーバーは新しい変更エントリをリトライ・キューに入れ、再試行回数を指定の最大値に設定して変更適用プロセスを繰り返します。

最終試行を除いて、変更エントリが正常に適用されなかった場合:

ディレクトリ・レプリケーション・サーバーは変更エントリをリトライ・キューに保持したまま、再試行回数を減らして、変更適用プロセスを繰り返します。

最終試行で変更エントリが正常に適用されなかった場合:

ディレクトリ・レプリケーション・サーバーは、新規エントリが既存エントリと重複していないかどうかをチェックします。

変更エントリが重複エントリの場合:

ディレクトリ・レプリケーション・サーバーは、次の競合解消規則を適用します。

- 作成タイムスタンプが古い方のエントリを使用します。

- 両方のエントリの作成タイムスタンプが同じ場合は、GUIDの小さい方のエントリを使用します。

変更エントリを使用すると、ターゲット・エントリは削除されて変更が適用され、その変更エントリがパージ・キューに入ります。

ターゲット・エントリを使用すると、変更エントリがパージ・キューに入ります。

変更エントリが重複エントリではない場合:

ディレクトリ・レプリケーション・サーバーは、変更エントリを管理者操作キューに入れ、orclHIQScheduleパラメータで指定した間隔で変更適用プロセスを繰り返します。

変更エントリが管理者操作キューに入れられた後正常に適用されない場合:

ディレクトリ・レプリケーション・サーバーは、このキューに変更を保持したまま、管理者によるアクションを待ちながら、指定した間隔で変更適用プロセスを繰り返します。管理者は、Oracle Internet Directory比較調整ツールおよび管理者操作キュー操作ツールを使用して、競合を解消できます。

D.5.2 マルチマスター・レプリケーション・プロセスがエントリを削除する動作

ディレクトリ・レプリケーション・サーバーは、コンシューマからエントリを削除すると、次の変更適用プロセスを実行します。

1. ディレクトリ・レプリケーション・サーバーは、コンシューマ内で変更エントリのGUIDと一致するGUIDを持つエントリを探します。

2. 一致するエントリがコンシューマ内にある場合、ディレクトリ・レプリケーション・サーバーはそのエントリを削除します。次に、変更エントリをパージ・キューに入れます。

1回目の試行で変更エントリが正常に適用されなかった場合:

ディレクトリ・レプリケーション・サーバーは変更エントリをリトライ・キューに入れ、再試行回数を指定の最大値に設定して、変更適用プロセスを繰り返します。

最終試行を除いて、変更エントリが正常に適用されなかった場合:

ディレクトリ・レプリケーション・サーバーは変更エントリをリトライ・キューに保持したまま、再試行回数を減らして、変更適用プロセスを繰り返します。

最終試行で変更エントリが正常に適用されなかった場合:

ディレクトリ・レプリケーション・サーバーは、変更エントリを管理者操作キューに入れ、指定した間隔で変更適用プロセスを繰り返します。

変更エントリが管理者操作キューに入れられた後正常に適用されない場合:

ディレクトリ・レプリケーション・サーバーは、このキューに変更エントリを保持したまま、管理者によるアクションを待ちながら、指定した間隔で変更適用プロセスを繰り返します。管理者は、Oracle Internet Directory比較調整ツールおよび管理者操作キュー操作ツールを使用して、競合を解消できます。

D.5.3 マルチマスター・レプリケーション・プロセスがエントリを変更する動作

ディレクトリ・レプリケーション・サーバーは、コンシューマのエントリを変更すると、次の変更適用プロセスを実行します。

1. ディレクトリ・レプリケーション・サーバーは、コンシューマ内で変更エントリのGUIDと一致するGUIDを持つエントリを探します。

2. 一致するエントリがコンシューマ内にある場合、ディレクトリ・レプリケーション・サーバーは、変更エントリ内の各属性と、ターゲット・エントリ内の各属性を比較します。

3. その後、ディレクトリ・レプリケーション・サーバーは、次の競合解消規則を適用します。

1. 変更時間が最新の属性を使用します。

2. 最新バージョンの属性を使用します(バージョン1、2または3など)。

3. ホスト上の変更された属性のうち、アルファベットのAに最も近い名前のエントリを使用します。

4. ディレクトリ・レプリケーション・サーバーは、フィルタ処理済の変更を適用し、変更エントリをパージ・キューに入れます。

1回目の試行で変更エントリが正常に適用されなかった場合:

ディレクトリ・レプリケーション・サーバーは変更エントリをリトライ・キューに入れ、再試行回数を指定の最大値に設定して、変更適用プロセスを繰り返します。

最終試行を除いて、変更エントリが正常に適用されなかった場合:

ディレクトリ・レプリケーション・サーバーは変更エントリをリトライ・キューに保持したまま、再試行回数を減らして、変更適用プロセスを繰り返します。

最終試行で変更エントリが正常に適用されなかった場合:

ディレクトリ・レプリケーション・サーバーは、変更エントリを管理者操作キューに入れ、指定した間隔で変更適用プロセスを繰り返します。

変更エントリが管理者操作キューに入れられた後正常に適用されない場合:

ディレクトリ・レプリケーション・サーバーは、このキューに変更エントリを保持したまま、管理者によるアクションを待ちながら、指定した間隔で変更適用プロセスを繰り返します。管理者は、Oracle Internet Directory比較調整ツールおよび管理者操作キュー操作ツールを使用して、競合を解消できます。

D.5.4 マルチマスター・レプリケーション・プロセスが相対識別名を変更する動作

ディレクトリ・レプリケーション・サーバーは、コンシューマのエントリの相対識別名を変更すると、次の変更適用プロセスを実行します。

1. ディレクトリ・レプリケーション・サーバーは、コンシューマ内で変更エントリのGUIDと一致するGUIDを持つ識別名を探します。

2. 一致するエントリがコンシューマ内にある場合、ディレクトリ・レプリケーション・サーバーはそのエントリの相対識別名を変更し、変更エントリをパージ・キューに入れます。

1回目の試行で変更エントリが正常に適用されなかった場合:

ディレクトリ・レプリケーション・サーバーは変更エントリをリトライ・キューに入れ、再試行回数を指定の最大値に設定して、変更適用プロセスを繰り返します。

最終試行を除いて、変更エントリが正常に適用されなかった場合:

ディレクトリ・レプリケーション・サーバーは変更エントリをリトライ・キューに保持したまま、再試行回数を減らして、変更適用プロセスを繰り返します。

最終試行で変更エントリが正常に適用されなかった場合:

ディレクトリ・レプリケーション・サーバーは、変更エントリを管理者操作キューに入れ、変更がそのターゲット・エントリと重複していないかどうかをチェックします。

変更エントリが重複エントリの場合:

ディレクトリ・レプリケーション・サーバーは、次の競合解消規則を適用します。

- 作成タイムスタンプが古い方のエントリを使用します。

- 両方のエントリの作成タイムスタンプが同じ場合は、GUIDの小さい方のエントリを使用します。

変更エントリを使用すると、ターゲット・エントリは削除されて、変更エントリが適用されパージ・キューに入ります。

ターゲット・エントリを使用すると、変更エントリがパージ・キューに入ります。

変更エントリが重複エントリではない場合:

ディレクトリ・レプリケーション・サーバーは、変更エントリを管理者操作キューに入れ、指定した間隔で変更適用プロセスを繰り返します。

変更エントリが管理者操作キューに入れられた後正常に適用されない場合:

ディレクトリ・レプリケーション・サーバーは、このキューに変更エントリを保持したまま、管理者によるアクションを待ちながら、指定した間隔で変更適用プロセスを繰り返します。管理者は、Oracle Internet Directory比較調整ツールおよび管理者操作キュー操作ツールを使用して、競合を解消できます。

D.5.5 マルチマスター・レプリケーション・プロセスが識別名を変更する動作

ディレクトリ・レプリケーション・サーバーは、コンシューマのエントリの識別名を変更すると、次の変更適用プロセスを実行します。

1. ディレクトリ・レプリケーション・サーバーは、コンシューマ内で変更エントリのGUIDと一致するGUIDを持つ識別名を探します。
また、ディレクトリ・レプリケーション・サーバーは、コンシューマ内で変更エントリに指定されている新しい親のGUIDと一致するGUIDを持つ親の識別名も探します。

2. ターゲット・エントリの識別名と親の識別名の両方がコンシューマ内にある場合、ディレクトリ・レプリケーション・サーバーはそのエントリの識別名を変更し、変更エントリをパージ・キューに入れます。

1回目の試行で変更エントリが正常に適用されなかった場合:

ディレクトリ・レプリケーション・サーバーは変更エントリをリトライ・キューに入れ、再試行回数を指定の最大値に設定して、変更適用プロセスを繰り返します。

最終試行を除いて、変更エントリが正常に適用されなかった場合:

ディレクトリ・レプリケーション・サーバーは変更エントリをリトライ・キューに保持したまま、再試行回数を減らして、変更適用プロセスを繰り返します。

最終試行で変更エントリが正常に適用されなかった場合:

ディレクトリ・レプリケーション・サーバーは、変更エントリを管理者操作キューに入れ、変更がそのターゲット・エントリと重複していないかどうかをチェックします。

変更エントリが重複エントリの場合:

ディレクトリ・レプリケーション・サーバーは、次の競合解消規則を適用します。

- 作成タイムスタンプが古い方のエントリを使用します。

- 両方のエントリの作成タイムスタンプが同じ場合は、GUIDの小さい方のエントリを使用します。

変更エントリを使用すると、ターゲット・エントリは削除されて、変更エントリが適用されパージ・キューに入ります。

ターゲット・エントリを使用すると、変更エントリがパージ・キューに入ります。

変更エントリが重複エントリではない場合:

ディレクトリ・レプリケーション・サーバーは、変更エントリを管理者操作キューに入れ、指定した間隔で変更適用プロセスを繰り返します。

変更エントリが管理者操作キューに入れられた後正常に適用されない場合:

ディレクトリ・レプリケーション・サーバーは、このキューに変更エントリを保持したまま、管理者によるアクションを待ちながら、指定した間隔で変更適用プロセスを繰り返します。管理者は、Oracle Internet Directory比較調整ツールおよび管理者操作キュー操作ツールを使用して、競合を解消できます。

E Javaサーバー・プラグイン開発者リファレンス

この付録では、Oracle Internet Directoryのサーバー・プラグイン・フレームワークのJava APIについて説明します。

顧客と社内の両方からの要望に応え、オラクル社ではOracle Internet Directoryのサーバー・プラグイン・フレームワークにJava APIを追加しました。サーバー・チェーンなど、Oracle Internet Directoryの新機能のいくつかは、JavaプラグインAPIを使用して開発されました。

この付録の内容は次のとおりです。

- 第E.1項「Javaプラグインの利点」

- 第E.2項「Javaプラグインの設定」

- 第E.3項「JavaプラグインAPI」

- 第E.4項「Javaプラグイン・エラーおよび例外処理」

- 第E.5項「Javaプラグインのデバッグおよびロギング」

- 第E.6項「Javaプラグインの例」

E.1 Javaプラグインの利点

Java言語自体の利点に加え、Javaサーバー・プラグインには、PL/SQLプラグインに優る次のような利点があります。

- サーバーとプラグイン間の双方向通信

- プラグインで検索結果を戻す機能

- moddn操作のサポート

- より高いパフォーマンス

- データベースの知識が不要

- セキュリティの強化

- デバッグ機能の強化

E.2 Javaプラグインの設定

Javaプラグインは次のように設定します。

1. 事前定義済のクラス定義およびメソッドを使用して、スタンドアロンのJavaプログラムを作成します。プラグインは、jarファイルまたはパッケージとして実装できます。

2. プラグイン・ファイルまたはパッケージをコンパイルします。コンパイルする前に、CLASSPATHが$ORACLE_HOME/ldap/jlib/ospf.jarに設定されていることを確認します。コンパイルがエラーなしで完了していることを確認します。

3. クラス・ファイル、jarまたはパッケージを、事前に定義したクラスの場所$ORACLE_HOME/ldap/server/pluginに配置します。

4. プラグイン構成エントリを追加してJavaプラグインを登録します。
エントリは、コマンド行またはOracle Directory Services Managerを使用して追加できます。詳細は、第45.3項「コマンド行でのプラグインの登録」および第45.4項「Oracle Directory Services ManagerおよびOracle Enterprise Manager Fusion Middleware Controlを使用したプラグインの管理」を参照してください。

jarファイルには任意の名前を付けることができます。マニフェスト・ファイルには、後ろにJavaプラグインの名前が続く、属性Main-Classが含まれている必要があります。次に例を示します。

Main-Class: myjavaplugin

プラグイン構成エントリのorclPluginName属性の値は、次のいずれかと対応している必要があります。

- クラス・ファイル内のクラス名

- パッケージ内のクラスの完全修飾名

- jarファイル名

orclPluginName属性の値により、サーバーでクラスまたはjarファイルを検索する場所が決定されます。表E-1に、いくつかの例を示します。

表E-1 プラグイン名および対応するパス

orclPluginName

パス

myjavaplugin

ORACLE_HOME/ldap/server/plugin/myjavaplugin.class

myjavaplugin.jar

ORACLE_HOME/ldap/server/plugin/myjavaplugin.jar

my.package.myjavaplugin

ORACLE_HOME/ldap/server/plugin/my/package/myjavaplugin

前述の手順の実行後は、起動基準が満たされるたびに、サーバーによりプラグインが起動されます。

jarファイルに含まれるクラスが環境内に存在しないようにしてください。存在すると、予期しないエラーが発生する可能性があります。この問題を修正するには、環境からクラスを削除し、Oracle Internet Directoryサーバーを再起動します。JARファイルまたはクラス・ファイルが他のJARファイルやクラス・ファイルに依存している場合は、依存しているJARファイルまたはクラス・ファイルのパスをCLASSPATHに追加して、Oracle Internet Directoryサーバーを再起動します。

プラグインが実行されるたびにサーバーでJavaプラグイン・クラスをリロードするかどうかは、制御できます。属性orclPluginClassReloadEnabledの値が1の場合、サーバーはプラグイン・クラスを毎回リロードします。値が0の場合、サーバーは、プラグインの最初の実行時にのみクラスをロードします。

Oracle Internet Directoryサーバー・プラグイン・フレームワークのjarファイルのパスは、$ORACLE_HOME/ldap/jlib/ospf.jarです。

E.3 JavaプラグインAPI

この項では、APIの高度な概要、およびメイン・クラスやインタフェースの役割を説明します。すべてのJavaサーバー・プラグイン・クラスおよびインタフェースの詳細は、Javadocの『Oracle Fusion Middleware Java API Reference for Oracle Internet Directory』を参照してください。

この項の項目は次のとおりです。

- 第E.3.1項「サーバーとプラグイン間の通信」

- 第E.3.2項「Javaプラグインの構造」

- 第E.3.3項「PluginDetail」

- 第E.3.4項「PluginResult」

- 第E.3.5項「ServerPluginインタフェース」

注意:
JavaプラグインではSystem.exit()を使用しないでください。使用すると、Oracleディレクトリ・サーバーが予期しない動作をする可能性があります。

E.3.1 サーバーとプラグイン間の通信

すべてのJavaプラグインでは、プラグインとOracle Internet Directoryサーバーとの通信にServerPluginインタフェースが使用されます。サーバーによりJavaプラグインが起動される際に、PluginDetailオブジェクトが構成され、そのオブジェクトのプラグインに情報が渡されます。プラグインにより、PluginResultオブジェクトが構成されます。タスクが完了すると、プラグインによりPluginResultオブジェクトがサーバーに戻されます。プラグインにより、PluginDetailから受信した情報に変更または追加が加えられ、PluginResultオブジェクトに含めたその情報がサーバーに戻される場合もあります。図E-1は、Oracle Internet DirectoryサーバーとJavaプラグインの間の通信を示しています。

図E-1 サーバーとJavaプラグインの間の通信

Javaプラグインでは、ログ・ファイルにメッセージを記録するために、ServerLogクラスも使用できます。

E.3.2 Javaプラグインの構造

次に、Javaプラグインの一般的な構造を示します。

public class Java_Plug-in_Class_Name {extends ServerPluginAdapter} {
public PluginResult
Name_of_ServerPlugin_Method(PluginDetail plgObj)
throws Exception {
// Plug-in Code
}
}

または

public class Java_Plug-in_Class_Name {implements ServerPlugin}  {
public PluginResult
Name_of_ServerPlugin_Method(PluginDetail plgObj)
throws Exception {
// Plug-in Code
}
}

E.3.3 PluginDetail

PluginDetailには、次の項で説明する情報が含まれます。

- 第E.3.3.1項「Server」

- 第E.3.3.2項「LdapBaseEntry」

- 第E.3.3.3項「LdapOperation」

- 第E.3.3.4項「PluginFlexfield」

E.3.3.1 Server

このオブジェクトには、プラグインが実行されるOracle Internet Directoryサーバーに関するメタデータ情報が含まれます。次の情報が含まれます。

- Hostname

- ポート

- LdapContext

HostnameおよびPortは、サーバーが稼働しているホストとポートを示します。

LdapContextオブジェクトによって、プラグインはサーバーに接続し返し、接続がプラグインから取得されていることを通知できます。これは、ldapbind自体を実行するldapbindプラグインなどに必要です。LdapContextオブジェクトを使用してサーバーに接続すると、サーバーにより同じプラグインが起動され、それが原因で無限ループが発生するのを防ぐことができます。

次のコード・フラグメントは、プラグインがPluginDetailからServerオブジェクトを取得し、サーバーに接続する様子を示しています。

// An LDAP Bind Plug-in
public class MyBindPlugin extends ServerPluginAdapter
{
…..
// Retrieve the Server Object from the PluginDetail
Server srvObj = plgObj.getServer();
……
// This bind will not result in the LDAP Bind Plug-in being called
// in an infinite loop
InitialLdapContext myConn =

(InitialLdapContext)srvObj.getLdapContextFromServerPlugin();
myConn.bind(…);
….
}

この例で使用されているメソッドの詳細は、Javadocの『Oracle Fusion Middleware Java API Reference for Oracle Internet Directory』を参照してください。

E.3.3.2 LdapBaseEntry

LdapBaseEntryには、次の情報が含まれます。

- DN

- 属性

ldapaddを除き、すべての操作のDN情報をサーバーから送信する必要があります。表E-2は、各操作のDNの内容を示しています。

表E-2 各LDAP操作のDN情報の内容

操作

DNの内容

ldapadd

DNは送信されません。

ldapbind

ディレクトリ・サーバーがバインドを試行するエントリ。

ldapcompare

比較が実行されるベース・エントリ。

ldapdelete

タイミングが前および操作時の場合に削除されるエントリ。

タイミングが後の場合、DNは送信されません。

ldapmoddn

移動対象のベース・エントリ。

ldapmodify

タイミングが前および操作時の場合に変更が行われるエントリ。

タイミングが後の場合に変更されるエントリ。

ldapsearch

検索のベース・エントリ。

AttributesはJNDI属性です。

LdapBaseEntryには、DNおよびAttributesにアクセスするためのメソッドがあります。LdapBaseEntryがグループ・エントリで、エントリ・キャッシュ機能が無効な場合、パフォーマンス上の理由から、属性uniquememberおよびmemberにはアクセスできません。

関連項目:
パフォーマンス・チューニングの詳細は、『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』の「Oracle Internet Directory」の章を参照してください。

E.3.3.3 LdapOperation

すべてのプラグインは、add、bind、compare、delete、moddn、modifyまたはsearchの7つの基本的なLDAP操作のいずれかに関連付けられています。LdapOperationオブジェクトには、次の情報が含まれ、7つのすべての操作に渡されます。

- Bind DN

- Server Controls

- Operation Result Code

Bind DNは、LDAP操作をリクエストするアイデンティティの識別名です。Server Controlsは、制御情報を含むベクターです。操作中に任意のサーバー・コントロールがサーバーに渡された場合、制御情報はServer ControlsのJavaプラグインに渡されます。表E-2に示すように、Operation Result Codeの内容は操作のタイミングによって異なります。操作時置換の場合、プラグインによるOperation Result Codeの情報の変更が可能で、その情報はPluginResultに含められてサーバーに渡されます。

表E-3 Operation Result Codeの動作

プラグインのタイミング

Operation Result Codeの内容および動作

前

操作時

使用しない

操作時置換

プラグインによって行われたLDAP操作のエラー状態。プラグインからサーバーへの出力。

後

サーバーによって実行されたLDAP操作のエラー・ステータス。サーバーからプラグインへの入力です。

LdapOperationには、コンテンツを取得および変更するためのメソッドもあります。

7つのLDAP操作を表す異なる7つのクラスにより、LdapOperationクラスが拡張されます。各サブクラスには、LdapOperation情報の他に、クラス固有の情報も含まれます。表E-4は、クラスおよびクラス固有の情報を示しています。表E-4の各クラス名は、そのクラスの詳細が説明されている項にリンクされています。

表E-4 LdapOperationのサブクラスおよびクラス固有の情報

クラス

クラス固有の情報

AddLdapOperation

LdapEntry

BindLdapOperation

Bind Password

CompareLdapOperation

属性名

Attribute Value

DeleteLdapOperation

Delete DN

ModdnLdapOperation

New Parent DN

New Relative DN

Delete Old RDN

New DN

ModifyLdapOperation

LdapModification

SearchLdapOperation

Filter

Required Attributes

Scope

SearchResultSet(サーバーからは送信されず、データを戻すためにプラグインによって作成されます。)

各クラスには、情報を作成、変更および取得するためのメソッドもあります。クラス固有の情報は、プラグインへの入力またはプラグインからサーバーへの出力(あるいはその両方)を表します。

操作固有のクラスの詳細は、この項のこれ以降の部分で説明します。

E.3.3.3.1 AddLdapOperation

ldapaddプラグインの起動時に、サーバーにより、追加するエントリの情報を渡すためのLdapEntryオブジェクトを含むAddLdapOperationオブジェクトが構成されます。LdapEntryオブジェクトには、次の情報が含まれます。

- DN

- 属性

DNは、追加するエントリの識別名を表します。Attributesは、エントリのJNDI属性です。表E-5に示すように、操作後を除くすべての操作で、プラグインによるLdapEntryの情報の変更が可能で、その情報はサーバーに戻されます。

表E-5 各プラグインのタイミングに対するLdapEntry情報の動作

プラグインのタイミング

LdapEntry情報の動作

前

操作時

操作時置換

入力および出力の両方。プラグインによる情報の変更が可能で、その情報はサーバーに戻されます。

後

入力のみ。

E.3.3.3.2 BindLdapOperation

サーバーにより、ldapbindプラグインに次の情報が渡されます。

- Bind Password

- Proxy Requester DN

Bind Passwordは、バインド用のパスワードです。Proxy Requester DNは、プロキシ・スイッチをリクエストするアイデンティティの識別名です。

E.3.3.3.3 CompareLdapOperation

サーバーにより、ldapcompareプラグインに次の情報が渡されます。

- 属性名

- Attribute Value

Attribute Nameは、ldapcompare操作中に比較される名前です。表E-6に示すように、操作後を除くすべての操作で、プラグインによるAttribute Nameの情報の変更が可能で、その情報はサーバーに戻されます。

表E-6 各プラグインのタイミングに対するAttributeNameの動作

プラグインのタイミング

Attribute Name情報の動作

前

操作時

操作時置換

入力および出力の両方。プラグインによる情報の変更が可能で、その情報はサーバーに戻されます。

後

入力のみ。

Attribute Valueは、ldapcompare操作中に比較される値です。表E-7に示すように、操作後を除くすべての操作で、プラグインによるAttribute Valueの情報の変更が可能で、その情報はサーバーに戻されます。

表E-7 各プラグインのタイミングに対するAttribute Valueの動作

プラグインのタイミング

Attribute Value情報の動作

前

操作時

操作時置換

入力および出力の両方。プラグインによる情報の変更が可能で、その情報はサーバーに戻されます。

後

入力のみ。

E.3.3.3.4 DeleteLdapOperation

サーバーはDelete DNオブジェクトをldapdeleteプラグインに渡します。これは削除される識別名です。表E-8に示すように、操作後を除くすべての操作で、プラグインによるDelete DNの情報の変更が可能で、その情報はサーバーに戻されます。

表E-8 各プラグインのタイミングに対するDelete DNの動作

プラグインのタイミング

DeleteDN情報の動作

前

操作時

操作時置換

入力および出力の両方。プラグインによる情報の変更が可能で、その情報はサーバーに戻されます。

後

入力のみ。

E.3.3.3.5 ModdnLdapOperation

サーバーにより、ldapmoddnプラグインに次の情報が渡されます。

- New Parent DN

- New Relative DN

- Delete Old RDN

- New DN

New Parent DNには、PluginDetailのLdapBaseEntryに指定されたRDNの新規の親が含まれます。表E-9に示すように、操作後を除くすべての操作で、プラグインによるNew Parent DNの情報の変更が可能で、その情報はサーバーに戻されます。

表E-9 各プラグインのタイミングに対するNew Parent DN情報の動作

プラグインのタイミング

New Parent DN情報の動作

前

操作時

操作時置換

入力および出力の両方。プラグインによる情報の変更が可能で、その情報はサーバーに戻されます。

後

入力のみ。

New Relative DNは、PluginDetailのLdapBaseEntryに指定されたRDNを置き換える新規のRDNです。表E-10に示すように、操作後を除くすべての操作で、プラグインによるNew Relative DNの情報の変更が可能で、その情報はサーバーに戻されます。

表E-10 各プラグインのタイミングに対するNew Relative DN情報の動作

プラグインのタイミング

New Relative DN情報の動作

前

操作時

操作時置換

入力および出力の両方。プラグインによる情報の変更が可能で、その情報はサーバーに戻されます。

後

入力のみ。

Delete Old RDN値には、PluginDetailのLdapBaseEntryに指定されている古いRDNを、新規の相対識別名に置き換えた後も格納するかどうかを指定します。表E-11に示すように、操作後を除くすべての操作で、プラグインによるDelete Old RDNの値の変更が可能で、その情報はサーバーに戻されます。

表E-11 各プラグインのタイミングに対するDelete Old RDN情報の動作

プラグインのタイミング

Delete Old RDN情報の動作

前

操作時

操作時置換

入力および出力の両方。プラグインによる情報の変更が可能で、その情報はサーバーに戻されます。

後

入力のみ。

New DNは、ldapmoddn操作のターゲット識別名を指定します。この情報は、サーバーからプラグインへの入力のみです。プラグインがこの情報を変更してサーバーに戻すことはできません。

E.3.3.3.6 ModifyLdapOperation

サーバーにより、ldapmodifyプラグインにLdapModificationオブジェクトが渡されます。LdapModificationオブジェクトには、JNDI変更アイテムであるModification Itemが含まれます。表E-12に示すように、操作後を除くすべての操作で、プラグインによるLdapModificationの情報の変更が可能で、その情報はサーバーに戻されます。

表E-12 各プラグインのタイミングに対するLdapModification情報の動作

プラグインのタイミング

LdapModification情報の動作

前

操作時

操作時置換

入力および出力の両方。プラグインによる情報の変更が可能で、その情報はサーバーに戻されます。

後

入力のみ。

E.3.3.3.7 SearchLdapOperation

SearchLdapOperationオブジェクトには、次の情報が含まれます。

- Filter

- Required Attributes

- Scope

- SearchResultSet

Filter、Required AttributesおよびScopeはサーバーによって渡されます。

Filterには、ldapsearch操作に指定されたLDAP検索フィルタが含まれます。これは、プラグインへの入力のみです。プラグインがこの情報を変更してサーバーに戻すことはできません。

Required Attributesには、ldapsearch操作に指定された必須属性が含まれます。表E-13に示すように、操作後を除くすべての操作で、プラグインによるRequired Attributesの情報の変更が可能で、その情報はサーバーに戻されます。

表E-13 各プラグインのタイミングに対するRequired Attributesの動作

プラグインのタイミング

Required Attributes情報の動作

前

操作時

操作時置換

入力および出力の両方。プラグインによる情報の変更が可能で、その情報はサーバーに戻されます。

後

入力のみ。

Scopeには、ldapsearch操作により実行される検索の範囲が含まれます。表E-14に示すように、操作後を除くすべての操作で、プラグインによるScopeの情報の変更が可能で、その情報はサーバーに戻されます。

表E-14 各プラグインのタイミングに対するScopeの動作

プラグインのタイミング

Scope情報の動作

前

操作時

操作時置換

入力および出力の両方。プラグインによる情報の変更が可能で、その情報はサーバーに戻されます。

後

入力のみ。

SearchResultSetは、Javaプラグインからサーバーに戻される検索結果を定義します。ldapsearch操作を実行するプラグインは、このオブジェクトを構成できます。表E-15に示すように、SearchResultSetをサーバーに戻すことができるのは操作時プラグインと操作時置換プラグインのみです。

表E-15 各プラグインのタイミングに対するSearchResultSetの動作

プラグインのタイミング

SearchResultSet情報の動作

前

このプラグインはオブジェクトを戻せません。

操作時

操作時置換

このプラグインは、サーバーにオブジェクトを戻すことができます。

後

このプラグインはオブジェクトを戻せません。

E.3.3.4 PluginFlexfield

プラグインを登録すると、プラグイン構成エントリにカスタム情報を格納できます。サーバーによりプラグインが起動される際に、この情報がプラグイン・フィールドPluginFlexfieldに渡されます。

構成エントリにカスタム情報を格納するためのスキーマ属性は3つあります。orclPluginFlexfield属性にはテキスト情報を格納できます。格納するカスタム情報をさらに詳細に記録するには、サブタイプを使用できます。たとえば、サブタイプorclPluginFlexfield;ad-hostを使用して、プラグインが接続する必要のあるActive Directoryサーバーのホスト名を格納できます。

orclPluginBinaryFlexfield属性には、バイナリ値を格納できます。サーバーではバイナリ属性の属性サブタイプがサポートされていないため、プラグインごとにorclPluginBinaryFlexfieldに格納できるのは1つの値のみです。

クリアテキストには表示しないカスタム・テキスト情報を格納するには、orclPluginSecuredFlexfieldを使用できます。値は暗号化形式で格納および表示されます。ユーザーがこの属性をクリアテキストで取得できないようにするため、Oracle Internet Directoryでは必ずプライバシ・モードを有効にします。第28.7項「受信した機密の属性のプライバシの構成」を参照してください。サブタイプを使用して、格納するカスタム情報の種類をわかりやすくすることができます。orclPluginFlexfieldと同じサブタイプ形式を使用してください。

サーバーによりプラグインが起動されるときに、orclPluginFlexfield、orclPluginBinaryFlexfieldおよびorclPluginSecuredFlexfieldからPluginFlexfieldオブジェクトに情報が渡されます。プラグインにより情報が解析されて使用されます。これは、PluginFlexfieldをサーバーに返すことはできません。

次に示す構成エントリの例では、orclPluginFlexfieldのサブタイプにより、パスワードの長さは8文字以上で、数値が含まれている必要があり、同じ文字は繰返し使用できないことが指定されています。

dn: cn=pre_add replace,cn=plugin,cn=subconfigsubentry
orclPluginFlexfield;minPwdLength: 8
orclPluginFlexfield;isDigitPwd: 1
orclPluginFlexfield;isRepeatCharsPwd: 0
objectclass: orclPluginConfig
objectclass: top
orclpluginname: MyJavaPwdCheckPlugin
orclplugintype: configuration
orclplugintiming: pre
orclpluginldapoperation: ldapadd
orclpluginenable: 1
orclpluginsubscriberdnlist: cn=users,dc=us,dc=oracle,dc=com
orclpluginattributelist: userpassword
orclPluginKind: Java

E.3.4 PluginResult

実行結果をサーバーに戻すため、JavaプラグインによりPluginResultオブジェクトが構成され、そのオブジェクトがサーバーに渡されます。PluginResultには、LdapOperationまたはその操作固有のサブクラスの1つの、いずれかのオブジェクトが含まれます。これらのオブジェクトは、第E.3.3.3項「LdapOperation」で説明しました。その項で説明されているように、操作およびタイミングによっては、PluginDetailから受信したLdapOperationサブクラス・オブジェクトの情報をプラグインが変更することが可能で、そのオブジェクトはPluginResultに含まれてサーバーに戻されます。

E.3.5 ServerPluginインタフェース

すべてのJavaプラグインでは、ServerPluginインタフェースが使用されます。このインタフェースには、サーバーと通信するための事前定義済のメソッドがあります。各LDAP操作およびタイミングに対して1つのメソッドがあります。各メソッドでは、PluginDetailオブジェクトが入力として使用され、PluginResultオブジェクトがOracle Internet Directoryサーバーに返されます。

ServerPluginAdapterクラスは、ServerPluginインタフェースを実装します。ServerPluginAdapterクラスには、デフォルト(NULL)で、ServerPluginメソッドが実装されています。このクラスを使用すると、すべてのメソッドを実装しなくてもJavaプラグインをコーディングできます。

この項のこれ以降では、各LDAP操作のServerPluginメソッドを示します。次が含まれます。

- 第E.3.5.1項「LdapbindのServerPluginメソッド」

- 第E.3.5.2項「LdapcompareのServerPluginメソッド」

- 第E.3.5.3項「LdapaddのServerPluginメソッド」

- 第E.3.5.4項「LdapmodifyのServerPluginメソッド」

- 第E.3.5.5項「LdapmoddnのServerPluginメソッド」

- 第E.3.5.6項「LdapsearchのServerPluginメソッド」

- 第E.3.5.7項「LdapdeleteのServerPluginメソッド」

E.3.5.1 LdapbindのServerPluginメソッド

public PluginResult pre_bind(PluginDetail pc) throws Exception;
public PluginResult when_bind_replace(PluginDetail pc) throws Exception;
public PluginResult post_bind(PluginDetail pc) throws Exception;

E.3.5.2 LdapcompareのServerPluginメソッド

public PluginResult pre_compare(PluginDetail pc) throws Exception;
public PluginResult when_compare_replace(PluginDetail pc) throws Exception;
public PluginResult post_compare(PluginDetail pc) throws Exception;

E.3.5.3 LdapaddのServerPluginメソッド

public PluginResult pre_add(PluginDetail pc) throws Exception;
public PluginResult when_add(PluginDetail pc) throws Exception;
public PluginResult when_add_replace(PluginDetail pc) throws Exception;
public PluginResult post_add(PluginDetail pc) throws Exception;

E.3.5.4 LdapmodifyのServerPluginメソッド

public PluginResult pre_modify(PluginDetail pc) throws Exception;
public PluginResult when_modify(PluginDetail pc) throws Exception;
public PluginResult when_modify_replace(PluginDetail pc) throws Exception;
public PluginResult post_modify(PluginDetail pc) throws Exception;

E.3.5.5 LdapmoddnのServerPluginメソッド

public PluginResult pre_moddn(PluginDetail pc) throws Exception;
public PluginResult when_moddn(PluginDetail pc) throws Exception;
public PluginResult when_moddn_replace(PluginDetail pc) throws Exception;
public PluginResult post_moddn(PluginDetail pc) throws Exception;

E.3.5.6 LdapsearchのServerPluginメソッド

public PluginResult pre_search(PluginDetail pc) throws Exception;
public PluginResult when_search(PluginDetail pc) throws Exception;
public PluginResult when_search_replace(PluginDetail pc) throws Exception;
public PluginResult post_search(PluginDetail pc) throws Exception;

E.3.5.7 LdapdeleteのServerPluginメソッド

public PluginResult pre_delete(PluginDetail pc) throws Exception;
public PluginResult when_delete(PluginDetail pc) throws Exception;
public PluginResult when_delete_replace(PluginDetail pc) throws Exception;
public PluginResult post_delete(PluginDetail pc) throws Exception;Java plug-in API

E.4 Javaプラグイン・エラーおよび例外処理

すべての未処理例外は、プラグインの実行中にOracle Internet Directoryサーバーによって捕捉されます。各例外の例外スタック・トレースおよびメッセージは、サーバー・ログ・ファイルに記録されます。これらの例外は3つのカテゴリに分類されます。

- ランタイム・エラーおよび例外は、不適切なプラグイン・コードまたはロジックが原因で発生します。Javaプラグインの実行中に生成されたすべてのランタイム・エラーおよび例外(NullPointerExceptionなど)は、サーバーにより捕捉されます。これらのエラーおよび例外は、サーバー・ログ・ファイルに記録されます。

- プラグインによりスローされる予想される例外は、Oracle Internet Directoryサーバーのログ・ファイルに記録されます。また、例外はプラグインによって捕捉され、サーバー・ログ・ファイルに記録するためにサーバーにスローされます。

- プラグインでは、PluginExceptionクラスを使用してエラーを生成できます。PluginExceptionオブジェクトまたはそのサブクラスを使用してサーバーに渡されたエラー・メッセージは、LDAPクライアントに渡されます。このメッセージも、例外スタック・トレースおよびメッセージとともに、サーバーによりサーバー・ログ・ファイルに記録されます。

この項では、3つの例を説明します。次のタイプです。

- 第E.4.1項「ランタイム例外の例」

- 第E.4.2項「ランタイム・エラーの例」

- 第E.4.3項「PluginExceptionの例」

E.4.1 ランタイム例外の例

次に、プラグインの実行中に生成される典型的な例外のログ・エントリを示します。

….
06:17:03 *
ERROR * gslpg_exceptionHndlr * Exception Message : Error
ERROR * gslpg_exceptionHndlr * Exception Stack Trace :
MyCompareJavaPlugin.post_compare(Prog2.java:75)
END

BEGIN
2004/10/19:01:52:13 *
ServerWorker (REG):4 * ConnID:0 * OpID:1 * OpName:compare
ERROR * gslpg_exceptionHndlr * Exception Stack Trace :
java.lang.NullPointerException
java.util.Hashtable.put(Hashtable.java:393)
oracle.ldap.ospf.PluginDetail.put(PluginDetail.java:41)
END

E.4.2 ランタイム・エラーの例

このエラーは、プラグインMyJavaPluginが$ORACLE_HOME/ldap/server/pluginディレクトリに存在しなかったために発生しました。ログ・ファイル・エントリは次のようになります。

BEGIN
2004/10/19:01:52:13 *
ServerWorker (REG):4 * ConnID:0 * OpID:1 * OpName:compare
ERROR * gslpg_exceptionHndlr * Exception Stack Trace :
java.lang.NoClassDefFoundError: MyJavaPlugin
END

E.4.3 PluginExceptionの例

PluginExceptionオブジェクトがサーバーにスローされると、Oracle Internet Directoryサーバーにより、その他のエラー・メッセージとともに、標準のプラグイン・エラー・メッセージがLDAPクライアントに戻されます。次に、LDAPクライアントにより表示されるエラーを示します。

ldap_compare: UnKnown Error Encountered
ldap_compare: additional info: Error Message returned by the Java Plug-in

E.5 Javaプラグインのデバッグおよびロギング

プラグインでは、独自のログ・ファイルを保持し、そのファイルにリアルタイムで記録することが可能です。また、プラグインでは、ServerLogクラスを使用して、実行中にOracle Internet Directoryサーバーのログ・ファイルにデバッグ・メッセージを記録できます。ServerLogクラスにメッセージを記録するためのメソッドは、次のようになります。

public static void log(String message);

ServerLog.log()メソッドにより記録されたメッセージは、先頭に次の文字列が付きます。

* Server Java Plug-in *

次に例を示します。

2006/05/11:01:11:28 * ServerWorker (REG):7
ConnID:241 * mesgID:2 * OpID:1 * OpName:bind
01:11:28 * Server Java Plug-in * MESSAGE FROM PLUGIN
01:11:28 * Server Java Plug-in * Bind DN :
cn=ad_user,cn=oiddvusers,cn=oraclecontext,dc=us,dc=oracle,dc=com

プラグインのデバッグ・メッセージをサーバー・ログに記録するには、次に示すデバッグ・レベルのいずれかを使用してOracle Internet Directoryサーバーを起動する必要があります。

表E-16 Javaプラグインのロギングのデバッグ・レベル

Oracle Internet Directoryサーバーのデバッグ・レベル

デバッグ・レベルの内容

134217728

Javaプラグイン・フレームワーク関連のすべてのJavaプラグイン・デバッグ・メッセージと内部サーバー・メッセージ

268435456

ServerLogオブジェクトを使用してJavaプラグインによって渡されるすべてのメッセージ

402653184

上の両方

ServerLog.log()メソッドはスレッド・セーフです。このメソッドを実行すると、パフォーマンスが低下する場合があります。

E.6 Javaプラグインの例

この項では、2つの例を説明します。次のタイプです。

- 例1: パスワード検証プラグイン

- 例2: Active Directoryの外部認証プラグイン

注意:
JavaプラグインではSystem.exit()を使用しないでください。使用すると、Oracleディレクトリ・サーバーが予期しない動作をする可能性があります。

E.6.1 例1: パスワード検証プラグイン

この例では、ldapmodify操作の前にuserPasswordを検証するJavaプラグインを説明します。操作前Javaプラグインは、Oracle Internet Directoryサーバーに登録されています。プラグイン構成には、そのプラグインで検証される最低限のパスワードの長さが含まれます。この情報は、orclPluginFlexfield属性を使用して、プラグイン構成エントリに登録されます。サブタイプminPwdLengthには、最低限の長さが指定されます。この情報は、PluginFlexfieldを使用してプラグインに渡されます。orclPluginNameにより、Oracle Internet Directoryサーバーにより起動されるJavaプラグインの名前が指定されます。

プラグインへの入力はPluginDetailで、プラグインからの出力はPluginResultです。

E.6.1.1 パスワード検証プラグインの構成エントリ

dn: cn=checkuserpassword,cn=plugin,cn=subconfigsubentry
orclPluginFlexfield;minPwdLength: 8
objectclass: orclPluginConfig
objectclass: top
orclpluginname: CheckPassword
orclplugintype: configuration
orclplugintiming: pre
orclpluginldapoperation: ldapmodify
orclpluginenable: 1
orclpluginsubscriberdnlist: cn=users,dc=us,dc=oracle,dc=com
orclpluginattributelist: userPassword
orclPluginKind: Java

E.6.1.2 パスワード検証プラグインのコード例

import java.io.*;
import java.lang.*;
import java.util.*;
import javax.naming.*;
import javax.naming.directory.*;
import oracle.ldap.ospf.*;
/**
* This PRE modify plug-in will check whether the "userPassword"
* is greater than 8 characters in length
*/
public class CheckPassword extends ServerPluginAdapter {

// This PRE modify plug-in takes in a PluginDetail Object
// and returns a PluginResult Object
public PluginResult pre_modify(PluginDetail plgObj)
throws Exception
{
try {
// Retrieve the LdapOperation Object from the PluginDetail
ModifyLdapOperation opObj = (ModifyLdapOperation)
plgObj.getLdapOperation();

// Retrieve the LdapModification Object from the LdapOperation
LdapModification modObj = opObj.getLdapModification();

// Retrieve the PluginFlexfield Object from the PluginDetail
PluginFlexfield flxFldObj = plgObj.getPluginFlexfield();

// Retrieve the custom information from the PluginFlexfield
// Get the minimum password length
String passwdlength =
flxFldObj.getFlexfield("minPwdLength");

// Create a Result Object to return to the OID server
PluginResult plgResObj = new PluginResult();

// Check if the LdapModification Object is a NULL
// set the appropriate error and error message
if (modObj==null)
{
throw new PluginException("CheckPassword Plug-in Execution
Error");
}

// Retrieve the "userPassword" Attribute Value
ModificationItem modItem = modObj.getModificationItemAt(0);
BasicAttribute attr = (BasicAttribute)modItem.getAttribute();
String attrval = null;
if ((attr.getID()).equals("userpassword"))
attrval = attr.get(0);

// Check for the password length and set appropriate error
// and error message
if (attrval.length() < Integer.parseInt(passwdlength))
{
throw new PluginException("userPassword is less than 8
characters");
}

// Return the PluginResult Object to the OID Server
return plgResObj;
}
// Catch any unexpected exception which may occur and throw
// it back to the OID server to log it
catch (Exception e)
{
throw e;
}
}
}

E.6.2 例2: Active Directoryの外部認証プラグイン

この例では、Active Directoryの外部認証プラグインを説明します。クライアントがuserPasswordのldapcompare操作をリクエストすると、サーバーによりこのJavaプラグインが起動され、Active Directoryに対してユーザーが認証されます。

E.6.2.1 外部認証プラグインの構成エントリ

dn: cn=when_rep_comp,cn=plugin,cn=subconfigsubentry
orclpluginsubscriberdnlist: cn=users,dc=us,dc=oracle,dc=com;
orclpluginflexfield;ad-host: dlin-pc2.us.example.com
orclpluginflexfield;ad-port: 3060
orclpluginflexfield;ad-su-dn: administrator@dlin.net
orclpluginflexfield;ad-su-passwd: password1
objectclass: orclPluginConfig
objectclass: top
orclpluginname: ExtAuthAD
orclplugintype: configuration
orclplugintiming: when
orclpluginisreplace: 1
orclpluginldapoperation: ldapcompare
orclpluginversion: 1.0.1
cn: when_rep_comp
orclpluginkind: Java
orclpluginenable: 1

E.6.2.2 外部認証プラグインのコード

public class ExtAuthAD extends ServerPluginAdapter {

public PluginResult when_compare_replace(PluginDetail plgObj)
throws Exception {
try {

// Retrieve the LdapOperation from the PluginDetail
CompareLdapOperation opObj =
(CompareLdapOperation) plgObj.getLdapOperation();       String baseDn = plgObj.getLdapBaseEntry().getDN();

// Retrieve the Base DN, Attribute and Attribute Value
String bdn = baseDn.substring(0,
baseDn.lastIndexOf("cn=users,dc=us,dc=oracle,dc=com")-1)
+",cn=users,dc=dlin,dc=net";
String ban = opObj.getAttributeName();       String bav = opObj.getAttributeValue().toString();

// Retrieve the AD Information from the PluginFlexfield
PluginFlexfield flxObj = plgObj.getPluginFlexfield();
String adhost = flxObj.getFlexfield("ad-host");
String adport = flxObj.getFlexfield("ad-port");
String adsudn = flxObj.getFlexfield("ad-su-dn");
String adsupasswd = flxObj.getFlexfield("ad-su-passwd");

// Create a PluginResult Object to return to the OID server
PluginResult plgResObj = new PluginResult();

// Create a Hashtable with values required to connect to AD
Hashtable env = new Hashtable();

env.put(Context.INITIAL_CONTEXT_FACTORY,
"com.sun.jndi.ldap.LdapCtxFactory");
env.put(Context.PROVIDER_URL, "ldap://"+adhost+":"+adport);
env.put(Context.SECURITY_AUTHENTICATION, "simple");
env.put(Context.SECURITY_PRINCIPAL, bdn);
env.put(Context.SECURITY_CREDENTIALS, bav);

// Try to connect to AD
DirContext dirContext = null;
try {
dirContext = new InitialDirContext(env);
if (dirContext != null) {
// User has been successfully authenticated, add the appropriate
// result code to the LdapOperation
opObj.setOperationResultCode(6);
}
}
catch(NamingException ne) {
// Unable to connect to the AD directory server with the given
// credentials, add the appropriate result code to the LdapOperation
opObj.setOperationResultCode(5);
}

// Add the LdapOperation to the PluginResult
plgResObj.setLdapOperation(opObj);

// Return the PluginResult
return plgResObj;

} catch(Exception e) {
// In case of any unexpected errors in the plug-in, throw the Exception
// back to the OID server to log it     throw e;
}
}
}

F PL/SQLサーバー・プラグイン開発者リファレンス

この付録では、PL/SQLのプラグイン・フレームワークを使用する方法について説明し、Oracle Internet DirectoryでPL/SQLサーバー・プラグインを設計、作成および使用する方法について説明します。

この付録の内容は次のとおりです。

- 第F.1項「PL/SQLサーバー・プラグインの設計、作成および使用」

- 第F.2項「PL/SQLプラグインの例」

- 第F.3項「PL/SQLプラグイン・フレームワークでのバイナリ・サポート」

- 第F.4項「データベース・オブジェクト・タイプの定義」

- 第F.5項「PL/SQLプラグイン・プロシージャの仕様」

F.1 PL/SQLサーバー・プラグインの設計、作成および使用

この項の項目は次のとおりです。

- 第F.1.1項「PL/SQLプラグインの注意事項」

- 第F.1.2項「PL/SQLプラグインの作成」

- 第F.1.3項「PL/SQLプラグインのコンパイル」

- 第F.1.4項「PL/SQLプラグインの管理」

- 第F.1.5項「PL/SQLプラグインの有効化と無効化」

- 第F.1.6項「PL/SQLプラグインにおける例外処理」

- 第F.1.7項「PL/SQLプラグインLDAP API」

- 第F.1.8項「PL/SQLプラグインおよびデータベース・ツール」

- 第F.1.9項「PL/SQLプラグインのセキュリティ」

- 第F.1.10項「PL/SQLプラグインのデバッグ」

- 第F.1.11項「PL/SQLプラグインLDAP APIの仕様」

F.1.1 PL/SQLプラグインの注意事項

PL/SQLプラグインには、次の注意事項があります。

F.1.1.1 PL/SQLプラグイン操作のタイプ

PL/SQLプラグインは、ldapbind、ldapadd、ldapmodify、ldapcompare、ldapsearchおよびldapdeleteの各操作にのみ関連付けることができます。PL/SQLプラグインをmoddnに関連付けることはできません。プラグインをmoddnに関連付ける場合には、Javaプラグインを使用する必要があります。

F.1.1.2 PL/SQLプラグインの名前付け

プラグインが他のプラグインやストアド・プロシージャと同じデータベース・スキーマを共有する場合、そのプラグインの名前(PL/SQLパッケージ名)は一意であることが必要です。しかし、他のデータベース・スキーマ・オブジェクト(表やビューなど)とは同じ名前を共有できます。ただし、この種の共有はお薦めしません。

F.1.2 PL/SQLプラグインの作成

PL/SQLプラグイン・モジュールの作成は、PL/SQLパッケージの作成と似ています。いずれも、仕様部分と本文に分かれています。この仕様はOracle Internet Directoryとカスタム・プラグインを接続するインタフェースの役割を果すため、プラグインではなくディレクトリによってプラグインの仕様が決まります。

セキュリティ上およびLDAPサーバーの整合性の理由から、PL/SQLプラグインをコンパイルできるのはODSデータベース・スキーマにおいてのみです。これらを、Oracle Internet Directoryのバックエンド・データベースの役割を果すデータベースにコンパイルする必要があります。

F.1.2.1 プラグイン・モジュール・インタフェースのパッケージ仕様

パッケージ仕様はプラグインによって異なります。表F-1に示すように、プラグイン・パッケージには名前を指定できます。ただし、プラグイン・プロシージャの各タイプに定義されているシグネチャには従う必要があります。詳細は、第F.5項「PL/SQLプラグイン・プロシージャの仕様」を参照してください。

表F-1 プラグイン・モジュール・インタフェース

プラグイン項目

ユーザー定義

Oracle Internet Directoryで定義

プラグイン・パッケージ名

X

プラグイン・プロシージャ名

X

プラグイン・プロシージャのシグネチャ

X

表F-2に、様々なプラグイン・プロシージャを示します。また、各プロシージャで使用されるパラメータについても説明します。

表F-2 操作ベースと属性ベースのプラグイン・プロシージャのシグネチャ

起動コンテキスト

プロシージャ名

INパラメータ

OUTパラメータ

ldapbind前

PRE_BIND

ldapcontext、Bind DN、Password

return code、error message

ldapbind時(ただし、デフォルト・サーバーの動作を置換)

WHEN_BIND_REPLACE

ldapcontext、bind result、DN、userpassword

bind result、return code、error message

ldapbind後

POST_BIND

ldapcontext、Bind result、Bind DN、Password

return code、error message

ldapmodify前

PRE_MODIFY

ldapcontext、DN、Mod structure

return code、error message

ldapmodify時

WHEN_MODIFY

ldapcontext、DN、Mod structure

return code、error message

ldapmodify時(ただし、デフォルト・サーバーの動作を置換)

WHEN_MODIFY_REPLACE

ldapcontext、DN、Mod structure

return code、error message

ldapmodify後

POST_MODIFY

ldapcontext、Modify result、DN、Mod structure

return code、error message

ldapcompare前

PRE_COMPARE

ldapcontext、DN、attribute、value

return code、error message

ldapcompare時(ただし、デフォルト・サーバーの動作を置換)

WHEN_COMPARE_REPLACE

ldapcontext、Compare result、DN、attribute、value

compare result、return code、error message

ldapcompare後

POST_COMPARE

ldapcontext、Compare result、DN、attribute、value

return code、error message

ldapadd前

PRE_ADD

ldapcontext、DN、Entry

return code、error message

ldapadd時

WHEN_ADD

ldapcontext、DN、Entry

return code、error message

ldapadd時(ただし、デフォルト・サーバーの動作を置換)

WHEN_ADD_REPLACE

ldapcontext、DN、Entry

return code、error message

ldapadd後

POST_ADD

ldapcontext、Add result、DN、Entry

return code、error message

ldapdelete前

PRE_DELETE

ldapcontext、DN

return code、error message

ldapdelete時

WHEN_DELETE

ldapcontext、DN

return code、error message

ldapdelete時(ただし、デフォルト・サーバーの動作を置換)

WHEN_DELETE

ldapcontext、DN

return code、error message

ldapdelete後

POST_DELETE

ldapcontext、Delete result、DN

return code、error message

ldapsearch前

PRE_SEARCH

ldapcontext、Base DN、scope、filter

return code、error message

ldapsearch後

POST_SEARCH

Ldap context、Search result、Base DN、scope、filter

return code、error message

関連項目:

- リターン・コードとエラー・メッセージの有効な値は、第F.1.6.1項「エラー処理」を参照してください。

- サポート対象のプロシージャ・シグネチャの詳細は、第F.5項「PL/SQLプラグイン・プロシージャの仕様」を参照してください。

F.1.3 PL/SQLプラグインのコンパイル

Oracle Internet Directoryのバックエンド・データベースと同じ役割を果すデータベースに対して、プラグイン・モジュールをコンパイルする必要があります。プラグインのコンパイルは、PL/SQLストアド・プロシージャと同じです。無名PL/SQLブロックは、メモリーにロードされるたびにコンパイルされます。コンパイルは次の段階を踏んで実行されます。

1. 構文検査: PL/SQLの構文がチェックされ、解析ツリーが生成されます。

2. 意味検査: 型がチェックされ、解析ツリーでさらに処理されます。

3. コード生成: Pコードが生成されます。

プラグインのコンパイル中にエラーが発生した場合、そのプラグインは作成されません。プラグイン作成時のコンパイル・エラーを参照するには、SQL*PlusまたはEnterprise ManagerでSHOW ERRORS文を使用するか、あるいはSELECT文を使用してUSER_ERRORSビューからエラーを選択できます。

すべてのプラグイン・モジュールは、ODSデータベース・スキーマでコンパイルする必要があります。

F.1.3.1 依存性

コンパイル済プラグインには依存性があります。依存オブジェクト(プラグイン本体からコールされるストアド・プロシージャやファンクションなど)が変更された場合、プラグインは無効になります。依存性の理由から無効となったプラグインは、次回起動するまでに再コンパイルする必要があります。

F.1.3.2 プラグインの再コンパイル

ALTER PACKAGE文を使用してプラグインを手動で再コンパイルします。たとえば、次の文では、my_pluginプラグインを再コンパイルします。

ALTER PACKAGE my_plugin COMPILE PACKAGE;

F.1.4 PL/SQLプラグインの管理

この項では、プラグインの変更およびデバッグ方法について説明します。

F.1.4.1 プラグインの変更

ストアド・プロシージャと同様、プラグインは明示的に変更できません。これは、新しい定義で置換する必要があります。

プラグインを置換する場合は、CREATE PACKAGE文にOR REPLACEオプションを指定する必要があります。このOR REPLACEオプションによって、既存のプラグインの新規バージョンは、プラグインの元のバージョンに付与されている権限に影響を与えることなく古いバージョンを置換できます。

DROP PACKAGE文を使用してプラグインを削除してから、CREATE PACKAGE文を再実行することもできます。

プラグイン名(パッケージ名)が変更されている場合は、新規プラグインを再度登録する必要があります。

F.1.4.2 プラグインのデバッグ

プラグインは、PL/SQLストアド・プロシージャで使用可能な同じ機能を使用してデバッグできます。

F.1.5 PL/SQLプラグインの有効化と無効化

プラグインをオンまたはオフに切り替えるには、プラグイン構成オブジェクトのorclPluginEnableの値を変更します。たとえば、cn=post_mod_plugin,cn=plugins,cn=subconfigsubentryでorclPluginEnableの値を1または0(ゼロ)に変更します。

F.1.6 PL/SQLプラグインにおける例外処理

PL/SQLプラグインの各プロシージャには、エラーを処理し、可能な場合にはリカバリを行うための例外処理ブロックが必要です。

F.1.6.1 エラー処理

Oracle Internet Directoryでは、リターン・コード(rc)とエラー・メッセージ(errmsg)がプラグイン・プロシージャに正しく設定されている必要があります。

表F-3にリターン・コードの有効な値を示します。

表F-3 プラグインのリターン・コードの有効な値

エラー・コード

説明

0

成功

0(ゼロ)より大きい数値

障害

-1

警告

errmsgパラメータは、ユーザーのカスタム・エラー・メッセージをOracle Internet Directoryサーバーに戻すことができる文字列値です。errmsgのサイズ制限は、1024バイトです。Oracle Internet Directoryは、プラグイン・プログラムを実行するたびに、リターン・コードを検査し、エラー・メッセージの表示が必要かどうかを判断します。

たとえば、リターン・コードの値が0(ゼロ)の場合、エラー・メッセージの値は無視されます。リターン・コードの値が-1または0(ゼロ)よりも大きい場合は、次のメッセージがログ・ファイルに記録されるか、標準出力に表示(リクエスト元がLDAPコマンド行ツールの場合)されます。

ldap addition info: customized error

F.1.6.2 Oracle Internet Directoryとプラグインとの間のプログラム制御処理

表F-4に、プラグイン例外の発生場所とディレクトリによる処理方法を示します。

表F-4 プラグイン例外発生時のプログラム制御処理

プラグイン例外の発生場所

Oracle Internet Directoryサーバーによる処理

PRE_BIND、PRE_MODIFY、PRE_ADD、PRE_SEARCH、PRE_COMPARE、PRE_DELETE

リターン・コードに従います。処理は次のとおりです。

- 0(ゼロ)より大きい場合(エラー)は、LDAP操作を実行しません。

- -1の場合(警告)は、LDAP操作を続行します。

POST_BIND、POST_MODIFY、POST_ADD、POST_SEARCH、WHEN_DELETE

LDAP操作を完了します。ロールバックは実行されません。

WHEN_MODIFY、WHEN_ADD、WHEN_DELETE

LDAP操作をロールバックします。

表F-5に、LDAP操作障害時のディレクトリの対応を示します。

表F-5 LDAP操作障害時のプログラム制御処理

LDAP操作障害の発生場所

Oracle Internet Directoryサーバーによる処理

PRE_BIND、PRE_MODIFY、PRE_ADD、PRE_SEARCH、WHEN_DELETE

操作前プラグインを完了します。ロールバックは実行されません。

POST_BIND、POST_MODIFY、POST_ADD、POST_SEARCH、WHEN_DELETE

操作後プラグインが続行されます。LDAP操作結果はINパラメータの1つです。

WHEN_MODIFY、WHEN_ADD、WHEN_DELETE

操作時タイプのプラグインの変更はロールバックされます。

WHEN

プラグイン・プログラム本体への変更はロールバックされます。

F.1.7 PL/SQLプラグインLDAP API

APIアクセスを提供するには、次のように様々な方法があります。

- ユーザーは標準LDAP PL/SQL APIを利用できます。ただし、プログラム・ロジックを慎重に計画しないと、プラグインの実行で無限ループが発生する可能性があることに注意してください。

- Oracle Internet DirectoryはプラグインLDAP APIを提供します。LDAPリクエストに関連付けられている構成済のプラグインがある場合、このプラグインは、ディレクトリ・サーバー内の一連のプラグイン・アクションを実行しません。

プラグインLDAP APIでは、プラグイン・モジュールで指定されたディレクトリ・サーバーに接続するためのAPIがディレクトリにより提供されます。プラグインを実行するサーバーに接続する場合、このAPIを使用する必要があります。外部サーバーに接続する場合、DBMS_LDAP APIを使用できます。

各プラグイン・モジュールでは、ldapcontextがOracleディレクトリ・サーバーから渡されます。プラグインLDAP APIがコールされると、セキュリティおよびバインドの目的でldapcontextが渡されます。このldapcontextを使用してバインドすると、Oracle Internet Directoryで、LDAPリクエストがプラグイン・モジュールからのリクエストであることが認識されます。このタイプのプラグイン・バインドの場合、ディレクトリによって後続のプラグインがトリガーされることはありません。プラグイン・バインドは、スーパーユーザー・バインドとして処理されます。このプラグイン・バインドは慎重に使用してください。

関連項目:
第F.1.11項「PL/SQLプラグインLDAP APIの仕様」

F.1.8 PL/SQLプラグインおよびデータベース・ツール

バルク・ツールは、サーバー・プラグインをサポートしていません。

F.1.9 PL/SQLプラグインのセキュリティ

一部のOracle Internet Directoryサーバーのプラグインでは、厳重なセキュリティを保持するコードをユーザーが用意する必要があります。たとえば、ディレクトリのldapcompareまたはldapbind操作をユーザー独自のプラグイン・モジュールで置換する場合、ユーザーは、セキュリティを維持するための機能が、この操作の実装によって除外されないことを確認する必要があります。

厳重なセキュリティを確保するには、次の処理を実行する必要があります。

- プラグイン・パッケージを作成します。

- LDAP管理者のみがデータベース・ユーザーを制限できるように指定します。

- アクセス制御リスト(ACL)を使用して、LDAP管理者のみがプラグイン構成エントリにアクセスできるように設定します。

- 異なる複数のプラグイン間におけるプログラムの関連性に注意します。

F.1.10 PL/SQLプラグインのデバッグ

プラグインの処理および内容を検証するには、Oracle Internet Directoryのプラグイン・デバッグ・メカニズムを使用します。次のコマンドは、サーバーのデバッグ処理の操作を制御します。

- プラグインのデバッグを設定するには、次のコマンドを実行します。

% sqlplus ods @$ORACLE/ldap/admin/oidspdsu.pls

- プラグインのデバッグを有効にするには、次のコマンドを実行します。

% sqlplus ods @$ORACLE/ldap/admin/oidspdon.pls

- プラグインのデバッグを有効にした後は、プラグイン・モジュール・コードで次のコマンドを使用できます。

plg_debug('debuggingmessage');

生成されたデバッグ・メッセージは、プラグイン・デバッグ表に格納されます。

- デバッグを無効にするには、次のコマンドを実行します。

% sqlplus ods @$ORACLE/ldap/admin/oidspdof.pls

- プラグイン・モジュールに設定したデバッグ・メッセージを表示するには、次のコマンドを実行します。

% sqlplus ods @$ORACLE/ldap/admin/oidspdsh.pls

- デバッグ表からすべてのデバッグ・メッセージを削除するには、次のコマンドを実行します。

% sqlplus ods @$ORACLE/ldap/admin/oidspdde.pls

F.1.11 PL/SQLプラグインLDAP APIの仕様

Oracle Internet Directoryが提供するPL/SQLプラグインLDAP APIのパッケージ仕様は次のとおりです。

CREATE OR REPLACE  PACKAGE LDAP_PLUGIN AS
SUBTYPE SESSION IS RAW(32);

-- Initializes the LDAP library and return a session handler
-- for use in subsequent calls.
FUNCTION init (ldappluginctx IN ODS.plugincontext)
RETURN SESSION;

-- Synchronously authenticates to the directory server using
-- a Distinguished Name and password.
FUNCTION simple_bind_s (ldappluginctx IN ODS.plugincontext,
ld            IN SESSION)
RETURN PLS_INTEGER;

-- Get requester info from the plug-in context
FUNCTION get_requester (ldappluginctx IN ODS.plugincontext)
RETURN VARCHAR2;
END LDAP_PLUGIN;

F.2 PL/SQLプラグインの例

この項では、2つのサンプル・プラグインを示します。一方は、すべてのldapsearchコマンドを記録します。もう一方は、2つのディレクトリ情報ツリー(DIT)を同期化します。

F.2.1 例1: 検索問合せの記録

状況: すべてのldapsearchコマンドを記録できるかどうかについて、あるユーザーが疑問を持っています。

解答: 記録できます。これには、ldapsearch操作後構成プラグインを使用できます。リクエストをすべて記録することも、検索対象のDNで発生したリクエストのみを記録することも可能です。

すべてのldapsearchコマンドを記録するには、次の手順を実行します。

1. すべてのldapsearch結果をデータベース表に記録します。このログ表には次の列があります。

- タイムスタンプ

- ベースDN

- 検索範囲

- 検索フィルタ

- 必須属性

- 検索結果

表を作成するには、次のSQLスクリプトを使用します。

drop table search_log;
create table search_log
(timestamp varchar2(50),
basedn varchar2(256),
searchscope number(1);
searchfilter varchar2(256);
searchresult number(1));
drop table simple_tab;
create table simple_tab (id NUMBER(7), dump varchar2(256));
DROP sequence seq;
CREATE sequence seq START WITH 10000;
commit;

2. プラグイン・パッケージ仕様を作成します。

CREATE OR REPLACE PACKAGE LDAP_PLUGIN_EXAMPLE1 AS
PROCEDURE post_search
(ldapplugincontext IN  ODS.plugincontext,
result       IN  INTEGER,
baseDN       IN  VARCHAR2,
scope        IN  INTEGER,
filterStr    IN  VARCHAR2,
requiredAttr IN  ODS.strCollection,
rc           OUT INTEGER,
errormsg     OUT VARCHAR2
);
END LDAP_PLUGIN_EXAMPLE1;
/

3. プラグイン・パッケージ本体を作成します。

CREATE OR REPLACE PACKAGE BODY LDAP_PLUGIN_EXAMPLE1 AS
PROCEDURE post_search
(ldapplugincontext IN  ODS.plugincontext,
result       IN  INTEGER,
baseDN       IN  VARCHAR2,
scope        IN  INTEGER,
filterStr    IN  VARCHAR2,
requiredAttr IN  ODS.strCollection,
rc           OUT INTEGER,
errormsg     OUT VARCHAR2
)
IS
BEGIN
INSERT INTO simple_tab VALUES
(to_char(sysdate, 'Month DD, YYYY HH24:MI:SS'), baseDN, scope, filterStr, result);
-- The following code segment demonstrate how to iterate
-- the ODS.strCollection
FOR l_counter1 IN 1..requiredAttr.COUNT LOOP
INSERT INTO simple_tab
values (seq.NEXTVAL, 'req attr ' || l_counter1 || ' = ' ||
requiredAttr(l_counter1));
END LOOP;
rc := 0;
errormsg := 'no post_search plug-in error msg';
COMMIT;
EXCEPTION
WHEN others THEN
rc := 1;
errormsg := 'exception: post_search plug-in';
END;
END LDAP_PLUGIN_EXAMPLE1;
/

4. プラグイン・エントリをOracle Internet Directoryに登録します。

dn: cn=post_search,cn=plugin,cn=subconfigsubentry
objectclass: orclPluginConfig
objectclass: top
orclPluginName: ldap_plugin_example1
orclPluginType: configuration
orclPluginTiming: post
orclPluginLDAPOperation: ldapsearch
orclPluginEnable: 1
orclPluginVersion: 1.0.1
cn: post_search
orclPluginKind: PLSQL

ldapaddコマンド行ツールを使用して、このエントリを追加します。

% ldapadd –p port_number –h host_name –D bind_dn –q –v \
–f register_post_search.ldif

F.2.2 例2: 2つのDITの同期化

状況: 相互に依存する2つの製品がcn=Products、cn=oraclecontextにあります。この相互依存性は、これらの製品のコンテナ内のユーザーにも適用されます。最初のDIT(製品1)のユーザーが削除された場合、もう一方のDIT(製品2)の対応するユーザーを削除する必要があります。

トリガーを設定して、最初のDITのユーザーが削除された場合に2番目のDITのユーザーを削除するトリガーをコールする、または渡すことは可能でしょうか。

解答: 可能です。ldapdelete操作後プラグインを使用して、2番目のDITで発生する2番目の削除を処理できます。

最初のDITにcn=DIT1,cn=products,cn=oraclecontextというネーミング・コンテキストがあり、2番目のDITにcn=DIT2,cn=products,cn=oraclecontextというネーミング・コンテキストがある場合、2人のユーザーは同一のID属性を共有します。ldapdelete操作後プラグイン・モジュール内で、LDAP_PLUGINとDBMS_LDAPのAPIを使用して、2番目のDIT内のユーザーを削除できます。

orclPluginSubscriberDNListをcn=DIT1,cn=products,cn=oraclecontextに設定する必要があります。これによって、cn=DIT1,cn=products,cn=oraclecontextのエントリを削除すると、常にプラグイン・モジュールが起動されるようになります。

注意:
ldapmodify操作後プラグインを使用して2つのOracle Internet Directoryのノード間で変更を同期化する場合、一方のノードから他方のノードへすべての属性をプッシュすることはできません。これは、プラグイン・モジュールで取得された変更(変更構造体)に操作属性が含まれているためです。このような操作属性は各ノードで生成されるものであり、標準のLDAPメソッドを使用して変更できません。
プラグイン・プログラムを記述する際には、操作属性authPassword、creatorsname、createtimestamp、modifiersname、modifytimestamp、orcllastlogintime、pwdchangedtime、pwdfailuretime、pwdaccountlockedtime、pwdexpirationwarned、pwdreset、pwdhistory、pwdgraceusetimeを同期化の対象から除外します。

1. 両方のDITのエントリはディレクトリに追加されていると仮定します。たとえば、エントリid=12345,cn=DIT1,cn=products,cn=oraclecontextはDIT1に、エントリid=12345,cn=DIT2,cn=products,cn=oraclecontextはDIT2にあります。

2. プラグイン・パッケージ仕様を作成します。

CREATE OR REPLACE PACKAGE LDAP_PLUGIN_EXAMPLE2 AS
PROCEDURE post_delete
(ldapplugincontext IN  ODS.plugincontext,
result   IN  INTEGER,
dn       IN  VARCHAR2,
rc       OUT INTEGER,
errormsg OUT VARCHAR2
);
END LDAP_PLUGIN_EXAMPLE2;
/

3. プラグイン・パッケージ本体を作成します。

CREATE OR REPLACE PACKAGE BODY LDAP_PLUGIN_EXAMPLE2 AS
PROCEDURE post_delete
(ldapplugincontext IN  ODS.plugincontext,
result   IN  INTEGER,
dn       IN  VARCHAR2,
rc       OUT INTEGER,
errormsg OUT VARCHAR2
)
IS
retval       PLS_INTEGER;
my_session   DBMS_LDAP.session;
newDN        VARCHAR2(256);
BEGIN
retval         := -1;
my_session := LDAP_PLUGIN.init(ldapplugincontext);
-- bind to the directory
retval := LDAP_PLUGIN.simple_bind_s(ldapplugincontext, my_session);
-- if retval is not 0, then raise exception
newDN := REPLACE(dn,'DIT1','DIT2');
retval := DBMS_LDAP.delete_s(my_session, newDN);
-- if retval is not 0, then raise exception
rc := 0;
errormsg := 'no post_delete plug-in error msg';
EXCEPTION
WHEN others THEN
rc := 1;
errormsg := 'exception: post_delete plug-in';
END;
END LDAP_PLUGIN_EXAMPLE2;
/
(ldapplugincontext IN  ODS.plugincontext,
result   IN  INTEGER,
dn       IN  VARCHAR2,
rc       OUT INTEGER,
errormsg OUT VARCHAR2
)
IS
retval       PLS_INTEGER;
my_session   DBMS_LDAP.session;
newDN        VARCHAR2(256);
BEGIN
retval         := -1;
my_session := LDAP_PLUGIN.init(ldapplugincontext);
-- bind to the directory
retval := LDAP_PLUGIN.simple_bind_s(ldapplugincontext, my_session);
-- if retval is not 0, then raise exception
newDN := REPLACE(dn,'DIT1','DIT2');
retval := DBMS_LDAP.delete_s(my_session, newDN);
-- if retval is not 0, then raise exception
rc := 0;
errormsg := 'no post_delete plug-in error msg';
EXCEPTION
WHEN others THEN
rc := 1;
errormsg := 'exception: post_delete plug-in';
END;
END LDAP_PLUGIN_EXAMPLE2;
/

4. プラグイン・エントリをOracle Internet Directoryに登録します。
LDIFファイルregister_post_delete.ldifを構成します。

dn: cn=post_delete,cn=plugin,cn=subconfigsubentry
objectclass: orclPluginConfig
objectclass: top
orclPluginName: ldap_plugin_example2
orclPluginType: configuration
orclPluginTiming: post
orclPluginLDAPOperation: ldapdelete
orclPluginEnable: 1
orclPluginSubscriberDNList: cn=DIT1,cn=oraclecontext,cn=products
orclPluginVersion: 1.0.1
cn: post_delete
orclPluginKind: PLSQL

ldapaddコマンド行ツールを使用して、このエントリを追加します。

% ldapadd –p port_number –h host_name –D bind_dn –q –v –f register_
post_delete.ldif

F.3 PL/SQLプラグイン・フレームワークでのバイナリ・サポート

リリース10.1.2から、プラグインLDAP APIのオブジェクト定義によって、ldapmodify、ldapaddおよびldapcompareのプラグインがディレクトリ・データベース内のバイナリ属性にアクセスできるようになりました。これまでは、アクセスできるのはタイプVARCHAR2の属性のみでした。これらのオブジェクト定義では、リリース10.1.2より前のプラグイン・コードは無効化されません。このコードを変更する必要はありません。新しい定義は、第F.4項「データベース・オブジェクト・タイプの定義」に記載されています。

この項では、3種類のプラグインが関係するバイナリ操作について説明します。これらのプラグインの例も示します。新しいオブジェクト定義は、3つすべてについて操作前、操作後および操作時のバージョンに適用されます。

3つの例では、LOBのかわりにRAWファンクションおよび変数を使用していることに注意してください。

F.3.1 ldapmodifyでのバイナリ操作

プラグイン・フレームワークがldapmodifyのプラグインに渡すmodobjオブジェクトに、バイナリ属性の値がbinvalsとして格納されるようになりました。この変数は、binvalobjオブジェクトの表です。

このプラグインでは、modobjのoperationフィールドを調べて、バイナリ操作が実行されているかどうかを判断します。これにより、値DBMS_LDAP.MOD_ADD、DBMS_LDAP.MOD_DELETEおよびDBMS_LDAP.MOD_REPLACEのいずれかが、DBMS_LDAP.MOD_BVALUESと組み合されているかどうかがチェックされます。たとえば、DBMS_LDAP.MOD_ADD+DBMS_LDAP.MOD_BVALUESの組合せは、変更操作におけるバイナリの追加を示します。

次の例は、別のディレクトリのエントリを変更する、ldapmodify操作後プラグインを示しています。このプラグインは、ldapmodifyがプラグイン・ディレクトリの同じエントリに同じ変更を適用した後、起動されます。もう一方のディレクトリのエントリは、DIT cn=users,dc=us,dc=example,dc=comにあります。

create or replace package moduser as
procedure post_modify(ldapplugincontext IN ODS.plugincontext,
result IN integer,
dn IN varchar2,
mods IN ODS.modlist,
rc OUT integer,
errormsg OUT varchar2);
end moduser;
/
show error

CREATE OR REPLACE PACKAGE BODY moduser AS
procedure post_modify(ldapplugincontext IN ODS.plugincontext,
result IN integer,
dn IN varchar2,
mods IN ODS.modlist,
rc OUT integer,
errormsg OUT varchar2)
is
counter1 pls_integer;
counter2 pls_integer;
retval pls_integer := -1;
user_session DBMS_LDAP.session;
user_dn varchar(256);
user_array DBMS_LDAP.mod_array;
user_vals DBMS_LDAP.string_collection;
user_binvals DBMS_LDAP.blob_collection;
ldap_host varchar(256);
ldap_port varchar(256);
ldap_user varchar(256);
ldap_passwd varchar(256);
begin
ldap_host :='backup.us.example.com';
ldap_port :='4000';
ldap_user :='cn=orcladmin';
ldap_passwd :='password';

plg_debug('START MODIFYING THE ENTRY');

-- Get a session
user_session := dbms_ldap.init(ldap_host, ldap_port);

-- Bind to the directory
retval := dbms_ldap.simple_bind_s(user_session, ldap_user,
ldap_passwd);

-- Create a mod_array
user_array := dbms_ldap.create_mod_array(mods.count);

-- Create a user_dn
user_dn := substr(dn,1,instr(dn,',',1,1))||'cn=users,dc=us,dc=example,
dc=com';

plg_debug('THE CREATED DN IS'||user_dn);

-- Iterate through the modlist
for counter1 in 1..mods.count loop

-- Log the attribute name and operation
if (mods(counter1).operation > DBMS_LDAP.MOD_BVALUES) then
plg_debug('THE NAME OF THE BINARY ATTR. IS'||mods(counter1).type);
else
plg_debug('THE NAME OF THE NORMAL ATTR. IS'||mods(counter1).type);
end if;
plg_debug('THE OPERATION IS'||mods(counter1).operation);

-- Add the attribute values to the collection
for counter2 in 1..mods(counter1).vals.count loop
user_vals(counter2) := mods(counter1).vals(counter2).val;
end loop;

-- Add the attribute values to the collection
for counter2 in 1..mods(counter1).binvals.count loop
plg_debug('THE NO. OF BYTES OF THE BINARY ATTR. VALUE IS'
||mods(counter1).binvals(counter2).length);
user_binvals(counter2) := mods(counter1).binvals(counter2).binval;
end loop;

-- Populate the mod_array accordingly with binary/normal attributes
if (mods(counter1).operation >= DBMS_LDAP.MOD_BVALUES) then
dbms_ldap.populate_mod_array(user_array,mods(counter1).operation -
DBMS_LDAP.MOD_BVALUES,mods(counter1).type,user_binvals);
user_binvals.delete;
else
dbms_ldap.populate_mod_array(user_array,mods(counter1).operation,
mods(counter1).type,user_vals);
user_vals.delete;
end if;

end loop;

-- Modify the entry
retval := dbms_ldap.modify_s(user_session,user_dn,user_array);
if retval = 0 then
rc := 0;
errormsg:='No error occurred while modifying the entry';
else
rc := retval;
errormsg :='Error code'||rc||' while modifying the entry';
end if;

-- Free the mod_array
dbms_ldap.free_mod_array(user_array);

plg_debug('FINISHED MODIFYING THE ENTRY');

exception
WHEN others THEN
plg_debug (SQLERRM);
end;
end moduser;
/
show error

exit;

F.3.2 ldapaddでのバイナリ操作

プラグイン・フレームワークがldapaddのプラグインに渡すentryobjオブジェクトに、バイナリ属性がbinattrとして格納されるようになりました。この変数は、binattrobjオブジェクトの表です。次の例は、プラグイン・ディレクトリの変更(追加されたユーザー)を別のディレクトリに伝播する追加後プラグインを示しています。後者のディレクトリのエントリは、DIT cn=users,dc=us,dc=example,dc=comにあります。

create or replace package adduser as
procedure post_add(ldapplugincontext IN ODS.plugincontext,
result IN integer,
dn IN varchar2,
entry IN ODS.entryobj,
rc OUT integer,
errormsg OUT varchar2);
end adduser;
/
show error

CREATE OR REPLACE PACKAGE BODY adduser AS
procedure post_add(ldapplugincontext IN ODS.plugincontext,
result IN integer,
dn IN varchar2,
entry IN ODS.entryobj,
rc OUT integer,
errormsg OUT varchar2)
is
counter1 pls_integer;
counter2 pls_integer;
retval pls_integer := -1;
s integer;
user_session DBMS_LDAP.session;
user_dn varchar(256);
user_array DBMS_LDAP.mod_array;
user_vals DBMS_LDAP.string_collection;
user_binvals DBMS_LDAP.blob_collection;
ldap_host varchar(256);
ldap_port varchar(256);
ldap_user varchar(256);
ldap_passwd varchar(256);
begin
ldap_host :='backup.us.example.com';
ldap_port :='4000';
ldap_user :='cn=orcladmin';
ldap_passwd :='password';

plg_debug('START ADDING THE ENTRY');

-- Get a session
user_session := dbms_ldap.init(ldap_host, ldap_port);

-- Bind to the directory
retval := dbms_ldap.simple_bind_s(user_session, ldap_user, ldap_passwd);

-- Create a mod_array
user_array := dbms_ldap.create_mod_array(entry.binattr.count +
entry.attr.count);

-- Create a user_dn
user_dn := substr(dn,1,instr(dn,',',1,1))||'cn=users,dc=us,dc=example,
dc=com';
plg_debug('THE CREATED DN IS'||user_dn);

-- Populate the mod_array with binary attributes
for counter1 in 1..entry.binattr.count loop
for counter2 in 1..entry.binattr(counter1).binattrval.count loop
plg_debug('THE NAME OF THE BINARY ATTR. IS'||
entry.binattr(counter1).binattrname);
s := dbms_lob.getlength(entry.binattr(counter1).
binattrval(counter2));
plg_debug('THE NO. OF BYTES OF THE BINARY ATTR. VALUE IS'||s);
user_binvals(counter2) := entry.binattr(counter1).
binattrval(counter2);
end loop;
dbms_ldap.populate_mod_array(user_array,DBMS_LDAP.MOD_ADD,
entry.binattr(counter1).binattrname,user_binvals);
user_binvals.delete;
end loop;

-- Populate the mod_array with attributes
for counter1 in 1..entry.attr.count loop
for counter2 in 1..entry.attr(counter1).attrval.count loop
plg_debug('THE NORMAL ATTRIBUTE'||entry.attr(counter1).attrname||'
HAS THE VALUE'||entry.attr(counter1).attrval(counter2));
user_vals(counter2) := entry.attr(counter1).attrval(counter2);
end loop;
dbms_ldap.populate_mod_array(user_array,DBMS_LDAP.MOD_ADD,
entry.attr(counter1).attrname,user_vals);
user_vals.delete;
end loop;

-- Add the entry
retval := dbms_ldap.add_s(user_session,user_dn,user_array);
plg_debug('THE RETURN VALUE IS'||retval);
if retval = 0 then
rc := 0;
errormsg:='No error occurred while adding the entry';
else
rc := retval;
errormsg :='Error code'||rc||' while adding the entry';
end if;

-- Free the mod_array
dbms_ldap.free_mod_array(user_array);
retval := dbms_ldap.unbind_s(user_session);

plg_debug('FINISHED ADDING THE ENTRY');

exception
WHEN others THEN
plg_debug (SQLERRM);
end;
end adduser;
/
show error

exit;

F.3.3 ldapcompareでのバイナリ操作

ldapcompareのプラグインは、オーバーロードされた3つの新しいモジュール・インタフェースを使用してバイナリ属性を比較できます。これらのインタフェースを使用して、バイナリと非バイナリ両方の属性を処理するプラグイン・パッケージを開発する場合、パッケージに2つの別々のプロシージャを含める必要があります。orclPluginNameはプラグイン・エントリに1つしか登録できないため、2つのプロシージャのパッケージ名は同じです。

既存のプラグイン・パッケージを更新してバイナリ属性を比較するプロシージャを含めた後、パッケージを再インストールします。そのプラグイン・パッケージに依存するパッケージを再コンパイルします。

3つの新しいインタフェースは次のようになります。

PROCEDURE pre_compare (ldapplugincontext IN ODS.plugincontext,
dn          IN VARCHAR2,
attrname    IN VARCHAR2,
attrval     IN BLOB,
rc          OUT INTEGER,
errormsg    OUT VARCHAR2 );

PROCEDURE when_compare_replace (ldapplugincontext IN ODS.plugincontext,
result      OUT INTEGER,
dn          IN VARCHAR2,
attrname    IN VARCHAR2,
attrval     IN BLOB,
rc          OUT INTEGER,
errormsg    OUT VARCHAR2 );

PROCEDURE post_compare (ldapplugincontext IN ODS.plugincontext,
result      IN INTEGER,
dn          IN VARCHAR2,
attrname    IN VARCHAR2,
attrval     IN BLOB,
rc          OUT INTEGER,
errormsg    OUT VARCHAR2 );

次の例では、プラグイン・ディレクトリのエントリのバイナリ属性と別のディレクトリのエントリのバイナリ属性を比較します。このパッケージは、サーバーの比較コードをプラグインの比較コードに置き換えます。また、バイナリと非バイナリ両方の属性を処理します。そのため、2つの別々のプロシージャが含まれています。

create or replace package compareattr as
procedure when_compare_replace(ldapplugincontext IN ODS.plugincontext,
result OUT integer,
dn IN varchar2,
attrname IN VARCHAR2,
attrval IN BLOB,
rc OUT integer,
errormsg OUT varchar2);
procedure when_compare_replace(ldapplugincontext IN ODS.plugincontext,
result OUT integer,
dn IN varchar2,
attrname IN VARCHAR2,
attrval IN varchar2,
rc OUT integer,
errormsg OUT varchar2);
end compareattr;
/
show error

CREATE OR REPLACE PACKAGE BODY compareattr AS
procedure when_compare_replace(ldapplugincontext IN ODS.plugincontext,
result OUT integer,
dn IN varchar2,
attrname IN VARCHAR2,
attrval IN varchar2,
rc OUT integer,
errormsg OUT varchar2)
is
pos            INTEGER := 2147483647;
begin
plg_debug('START');
plg_debug('THE ATTRNAME IS'||attrname||' AND THE VALUE IS'||attrval);
plg_debug('END');
rc := 0;
errormsg :='No error!!!';
exception
WHEN others THEN
plg_debug ('Unknown UTL_FILE Error');
end;

procedure when_compare_replace(ldapplugincontext IN ODS.plugincontext,
result OUT integer,
dn IN varchar2,
attrname IN VARCHAR2,
attrval IN BLOB,
rc OUT integer,
errormsg OUT varchar2)
is
counter pls_integer;
retval pls_integer := -1;
cmp_result integer;
s integer;
user_session DBMS_LDAP.session;
user_entry DBMS_LDAP.message;
user_message DBMS_LDAP.message;
user_dn varchar(256);
user_attrs DBMS_LDAP.string_collection;
user_attr_name VARCHAR2(256);
user_ber_elmt DBMS_LDAP.ber_element;
user_vals DBMS_LDAP.blob_collection;
ldap_host varchar(256);
ldap_port varchar(256);
ldap_user varchar(256);
ldap_passwd varchar(256);
ldap_base varchar(256);
begin
ldap_host :='backup.us.example.com';
ldap_port :='4000';
ldap_user :='cn=orcladmin';
ldap_passwd :='password';
ldap_base := dn;

plg_debug('STARTING COMPARISON IN WHEN REPLACE PLUG-IN');

s := dbms_lob.getlength(attrval);
plg_debug('THE NUMBER OF BYTES OF ATTRVAL'||s);

-- Get a session
user_session := dbms_ldap.init(ldap_host, ldap_port);

-- Bind to the directory
retval := dbms_ldap.simple_bind_s(user_session, ldap_user, ldap_passwd);

-- issue the search
user_attrs(1) := attrname;
retval := DBMS_LDAP.search_s(user_session, ldap_base,
DBMS_LDAP.SCOPE_BASE,
'objectclass=*',
user_attrs,
0,
user_message);

-- Get the entry in the other OID server
user_entry := DBMS_LDAP.first_entry(user_session, user_message);

-- Log the DN and the Attribute name
user_dn := DBMS_LDAP.get_dn(user_session, user_entry);
plg_debug('THE DN IS'||user_dn);
user_attr_name := DBMS_LDAP.first_attribute(user_session,user_entry,
user_ber_elmt);

-- Get the values of the attribute
user_vals := DBMS_LDAP.get_values_blob(user_session, user_entry,
user_attr_name);

-- Start the binary comparison between the ATTRVAL and the attribute
-- values
if user_vals.count > 0 then
for counter in user_vals.first..user_vals.last loop
cmp_result := dbms_lob.compare(user_vals(counter),attrval,
dbms_lob.getlength(user_vals(counter)),1,1);
if  cmp_result = 0 then
rc := 0;
-- Return LDAP_COMPARE_TRUE
result := 6;
plg_debug('THE LENGTH OF THE ATTR.'||user_attr_name||' IN THE
ENTRY IS'||dbms_lob.getlength(user_vals(counter)));
errormsg :='NO ERROR. THE COMPARISON HAS SUCCEEDED.';
plg_debug(errormsg);
plg_debug('FINISHED COMPARISON');
return;
end if;
end loop;
end if;

rc := 1;
-- Return LDAP_COMPARE_FALSE
result := 5;
errormsg :='ERROR. THE COMPARISON HAS FAILED.';
plg_debug('THE LENGTH OF THE ATTR.'||user_attr_name||' IN THE ENTRY IS'
||dbms_lob.getlength(user_vals(user_vals.last)));
plg_debug(errormsg);
plg_debug('FINISHED COMPARISON');

-- Free user_vals
dbms_ldap.value_free_blob(user_vals);
exception
WHEN others THEN
plg_debug (SQLERRM);
end;
end compareattr;
/
show error

exit;

F.4 データベース・オブジェクト・タイプの定義

この項では、プラグインLDAP APIに導入されたオブジェクト型の定義を示します。これらの定義は、すべてOracle Directory Serverのデータベース・スキーマにあります。APIにはプラグインがデータベースからバイナリ・データを抽出するためのオブジェクト型が含まれていることに注意してください。

create or replace type strCollection as TABLE of VARCHAR2(512);
/
create or replace type pluginContext as TABLE of VARCHAR2(512);
/
create or replace type attrvalType as TABLE OF VARCHAR2(4000);
/
create or replace type attrobj as object (
attrname    varchar2(2000),
attrval     attrvalType
);
/
create or replace type attrlist as table of attrobj;
/
create or replace type binattrvalType as TABLE OF BLOB;
/
create or replace type binattrobj as object (
binattrname    varchar2(2000),
binattrval     binattrvalType
);
/
create or replace type binattrlist as table of binattrobj;
/
create or replace type entryobj as object (
entryname      varchar2(2000),
attr           attrlist,
binattr        binattrlist
);
/
create or replace type entrylist as table of entryobj;
/

create or replace type bvalobj as object (
length         integer,
val            varchar2(4000)
);
/
create or replace type bvallist as table of bvalobj;
/
create or replace type binvalobj as object (
length         integer,
binval         blob
);
/
create or replace type binvallist as table of binvalobj;
/
create or replace type modobj as object (
operation      integer,
type           varchar2(256),
vals           bvallist,
binvals        binvallist
);
/
create or replace type modlist as table of modobj;

F.5 PL/SQLプラグイン・プロシージャの仕様

プラグインを使用する場合、各プラグインに定義されたシグネチャに従う必要があります。次に各シグネチャを示します。

PROCEDURE pre_add (ldapplugincontext IN  ODS.plugincontext,

dn             IN  VARCHAR2,
entry          IN  ODS.entryobj,
rc             OUT INTEGER,
errormsg       OUT VARCHAR2);

PROCEDURE when_add (ldapplugincontext IN  ODS.plugincontext,

dn             IN  VARCHAR2,
entry          IN  ODS.entryobj,
rc             OUT INTEGER,
errormsg       OUT VARCHAR2);

PROCEDURE when_add_replace (ldapplugincontext IN  ODS.plugincontext,

dn             IN  VARCHAR2,
entry          IN  ODS.entryobj,
rc             OUT INTEGER,
errormsg       OUT VARCHAR2);

PROCEDURE post_add (ldapplugincontext IN  ODS.plugincontext,

result         IN  INTEGER,
dn             IN  VARCHAR2,
entry          IN  ODS.entryobj,
rc             OUT INTEGER,
errormsg       OUT VARCHAR2);

PROCEDURE pre_modify (ldapplugincontext IN  ODS.plugincontext,

dn             IN  VARCHAR2,
mods           IN  ODS.modlist,
rc             OUT INTEGER,
errormsg       OUT VARCHAR2);

PROCEDURE when_modify (ldapplugincontext IN  ODS.plugincontext,

dn             IN  VARCHAR2,
mods           IN  ODS.modlist,
rc             OUT INTEGER,
errormsg       OUT VARCHAR2);

PROCEDURE when_modify_replace (ldapplugincontext IN  ODS.plugincontext,

dn             IN  VARCHAR2,
mods           IN  ODS.modlist,
rc             OUT INTEGER,
errormsg       OUT VARCHAR2);

PROCEDURE post_modify (ldapplugincontext IN  ODS.plugincontext,

result         IN  INTEGER,
dn             IN  VARCHAR2,
mods           IN  ODS.modlist,
rc             OUT INTEGER,
errormsg       OUT VARCHAR2);

PROCEDURE pre_compare (ldapplugincontext IN  ODS.plugincontext,

dn             IN  VARCHAR2,
attrname       IN  VARCHAR2,
attrval        IN  VARCHAR2,
rc             OUT INTEGER,
errormsg       OUT VARCHAR2
);

PROCEDURE pre_compare (ldapplugincontext IN ODS.plugincontext,
dn             IN VARCHAR2,
attrname       IN VARCHAR2,
attrval        IN BLOB,
rc             OUT INTEGER,
errormsg       OUT VARCHAR2 );

PROCEDURE when_compare_replace (ldapplugincontext IN  ODS.plugincontext,

result         OUT INTEGER,
dn             IN  VARCHAR2,
attrname       IN  VARCHAR2,
attrval        IN  VARCHAR2,
rc             OUT INTEGER,
errormsg       OUT VARCHAR2
);

PROCEDURE when_compare_replace (ldapplugincontext IN ODS.plugincontext,
result         OUT INTEGER,
dn             IN VARCHAR2,
attrname       IN VARCHAR2,
attrval        IN BLOB,
rc             OUT INTEGER,
errormsg       OUT VARCHAR2 );

PROCEDURE post_compare (ldapplugincontext IN  ODS.plugincontext,

result         IN  INTEGER,
dn             IN  VARCHAR2,
attrname       IN  VARCHAR2,
attrval        IN  VARCHAR2,
rc             OUT INTEGER,
errormsg       OUT VARCHAR2
);

PROCEDURE post_compare (ldapplugincontext IN ODS.plugincontext,
result         IN INTEGER,
dn             IN VARCHAR2,
attrname       IN VARCHAR2,
attrval        IN BLOB,
rc             OUT INTEGER,
errormsg       OUT VARCHAR2 );

PROCEDURE pre_delete (ldapplugincontext IN  ODS.plugincontext,

dn             IN  VARCHAR2,
rc             OUT INTEGER,
errormsg       OUT VARCHAR2
);

PROCEDURE when_delete (ldapplugincontext IN  ODS.plugincontext,

dn             IN  VARCHAR2,
rc             OUT INTEGER,
errormsg       OUT VARCHAR2
);

PROCEDURE when_delete_replace (ldapplugincontext IN  ODS.plugincontext,

dn             IN  VARCHAR2,
rc             OUT INTEGER,
errormsg       OUT VARCHAR2
);

PROCEDURE post_delete (ldapplugincontext IN  ODS.plugincontext,

result         IN  INTEGER,
dn             IN  VARCHAR2,
rc             OUT INTEGER,
errormsg       OUT VARCHAR2
);

PROCEDURE pre_search (ldapplugincontext IN  ODS.plugincontext,

baseDN         IN  VARCHAR2,
scope          IN  INTEGER,
filterStr      IN  VARCHAR2,
requiredAttr   IN  ODS.strCollection,
rc             OUT INTEGER,
errormsg       OUT VARCHAR2
);

PROCEDURE post_search (ldapplugincontext IN  ODS.plugincontext,

result         IN  INTEGER,
baseDN         IN  VARCHAR2,
scope          IN  INTEGER,
filterStr      IN  VARCHAR2,
requiredAttr   IN  ODS.strCollection,
rc             OUT INTEGER,
errormsg       OUT VARCHAR2
);

PROCEDURE pre_bind (ldapplugincontext IN ODS.plugincontext,

dn             IN  VARCHAR2,
passwd         IN  VARCHAR2,
rc             OUT INTEGER,
errormsg       OUT VARCHAR2
);

PROCEDURE when_bind_replace (ldapplugincontext IN ODS.plugincontext,

result         OUT INTEGER,
dn             IN  VARCHAR2,
passwd         IN  VARCHAR2,
rc             OUT INTEGER,
errormsg       OUT VARCHAR2
);

PROCEDURE post_bind (ldapplugincontext IN ODS.plugincontext,

result         IN  INTEGER,
dn             IN  VARCHAR2,
passwd         IN  VARCHAR2,
rc             OUT INTEGER,
errormsg       OUT VARCHAR2
);

G LDAPフィルタ定義

この付録には、「The String Representation of LDAP Search Filters」という文書が含まれます。

この付録に記載されている文書は、Internet Engineering Task ForceのRFC 2254の許可を得て転載されています。この文書は、http://www.ietf.orgにあります。

この文書より後で発行された文書または他の情報が、ここに記載された内容より優先される場合があります。追加情報または補足情報は、前述のWebサイトおよび関連サイトをチェックしてください。

注意:
オラクル社は、すべての保証を明示的にも暗黙的にも行いません。ここでいう保証には、この情報の使用がいかなる権利も侵害しないという保証や、特定の目的に対する商業性と適合性への暗示的な保証が含まれますが、これに限定されるものではありません。

Network Working Group T. Howes
Request for Comments: 2254 Netscape Communications Corp.
Category: Standards Track December 1997

The String Representation of LDAP Search Filters

1. Status of this Memo

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (1997). All Rights Reserved.

IESG Note

This document describes a directory access protocol that provides both read and update access. Update access requires secure authentication, but this document does not mandate implementation of any satisfactory authentication mechanisms.

In accordance with RFC 2026, section 4.4.1, this specification is being approved by IESG as a Proposed Standard despite this limitation, for the following reasons:

a. to encourage implementation and interoperability testing of these protocols (with or without update access) before they are deployed, and

b. to encourage deployment and use of these protocols in read-only applications.(e.g. applications where LDAPv3 is used as a query language for directories which are updated by some secure mechanism other than LDAP), and

c. to avoid delaying the advancement and deployment of other Internet standards-track protocols which require the ability to query, but not update, LDAPv3 directory servers.

Readers are hereby warned that until mandatory authentication mechanisms are standardized, clients and servers written according to this specification which make use of update functionality are UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.

Implementors are hereby discouraged from deploying LDAPv3 clients or servers which implement the update functionality, until a Proposed Standard for mandatory authentication in LDAPv3 has been approved and published as an RFC.

2. Abstract

The Lightweight Directory Access Protocol (LDAP) [1] defines a network representation of a search filter transmitted to an LDAP server. Some applications may find it useful to have a common way of representing these search filters in a human-readable form. This document defines a human-readable string format for representing LDAP search filters.

This document replaces RFC 1960, extending the string LDAP filter definition to include support for LDAP version 3 extended match filters, and including support for representing the full range of possible LDAP search filters.

3. LDAP Search Filter Definition

An LDAPv3 search filter is defined in Section 4.5.1 of [1] as follows:

Filter::= CHOICE {

and [0] SET OF Filter,

or [1] SET OF Filter,

not [2] Filter,

equalityMatch [3] AttributeValueAssertion,

substrings [4] SubstringFilter,

greaterOrEqual [5] AttributeValueAssertion,

lessOrEqual [6] AttributeValueAssertion,

present [7] AttributeDescription,

approxMatch [8] AttributeValueAssertion,

extensibleMatch [9] MatchingRuleAssertion

}

SubstringFilter::= SEQUENCE {

type AttributeDescription,

SEQUENCE OF CHOICE {

initial [0] LDAPString,

any [1] LDAPString,

final [2] LDAPString

}

}

AttributeValueAssertion::= SEQUENCE {

attributeDesc AttributeDescription,

attributeValue AttributeValue

}

MatchingRuleAssertion::= SEQUENCE {

matchingRule [1] MatchingRuleID OPTIONAL,

type [2] AttributeDescription OPTIONAL,

matchValue [3] AssertionValue,

dnAttributes [4] BOOLEAN DEFAULT FALSE

}

AttributeDescription::= LDAPString

AttributeValue::= OCTET STRING

MatchingRuleID::= LDAPString

AssertionValue::= OCTET STRING

LDAPString::= OCTET STRING

where the LDAPString above is limited to the UTF-8 encoding of the ISO 10646 character set [4]. The AttributeDescription is a string representation of the attribute description and is defined in [1].

The AttributeValue and AssertionValue OCTET STRING have the form defined in [2]. The Filter is encoded for transmission over a network using the Basic Encoding Rules defined in [3], with simplifications described in [1].

4. String Search Filter Definition

The string representation of an LDAP search filter is defined by the following grammar, following the ABNF notation defined in [5]. The filter format uses a prefix notation.

filter = "(" filtercomp ")"

filtercomp = and / or / not / item

and = "&" filterlist

or = "|" filterlist

not = "!" filter

filterlist = 1*filter

item = simple / present / substring / extensible

simple = attr filtertype value

filtertype = equal / approx / greater / less

equal = "="

approx = "~="

greater = ">="

less = "<="

extensible = attr [":dn"] [":" matchingrule] ":=" value

/ [":dn"] ":" matchingrule ":=" value

present = attr "=*"

substring = attr "=" [initial] any [final]

initial = value

any = "*" *(value "*")

final = value

attr = AttributeDescription from Section 4.1.5 of [1]

matchingrule = MatchingRuleId from Section 4.1.9 of [1]

value = AttributeValue from Section 4.1.6 of [1]

The attr, matchingrule, and value constructs are as described in the corresponding section of [1] given above.

If a value should contain any of the following characters

Character ASCII value
---------------------------

* 0x2a

( 0x28

) 0x29

\ 0x5c

NUL 0x00

then the character must be encoded as the backslash '\' character (ASCII 0x5c) followed by the two hexadecimal digits representing the ASCII value of the encoded character. The case of the two hexadecimal digits is not significant.

This simple escaping mechanism eliminates filter-parsing ambiguities and allows any filter that can be represented in LDAP to be represented as a NUL-terminated string. Other characters besides the ones listed above may be escaped using this mechanism, for example, non-printing characters.

For example, the filter checking whether the "cn" attribute contained a value with the character "*" anywhere in it would be represented as

"(cn=*\2a*)".

Note that although both the substring and present productions in the grammar above can produce the "attr=*" construct, this construct is used only to denote a presence filter.

5. Examples

This section gives a few examples of search filters written using this notation.

(cn=Babs Jensen)

(!(cn=Tim Howes))

(&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*)))

(o=univ*of*mich*)

The following examples illustrate the use of extensible matching.

(cn:1.2.3.4.5:=Fred Flintstone)

(sn:dn:2.4.6.8.10:=Barney Rubble)

(o:dn:=Ace Industry)

(:dn:2.4.6.8.10:=Dino)

The second example illustrates the use of the ":dn" notation to indicate that matching rule "2.4.6.8.10" should be used when making comparisons, and that the attributes of an entry's distinguished name should be considered part of the entry when evaluating the match.

The third example denotes an equality match, except that DN components should be considered part of the entry when doing the match.

The fourth example is a filter that should be applied to any attribute supporting the matching rule given (since the attr has been left off). Attributes supporting the matching rule contained in the DN should also be considered.

The following examples illustrate the use of the escaping mechanism.

(o=Parens R Us \28for all your parenthetical needs\29)

(cn=*\2A*)

(filename=C:\5cMyFile)

(bin=\00\00\00\04)

(sn=Lu\c4\8di\c4\87)

The first example shows the use of the escaping mechanism to represent parenthesis characters. The second shows how to represent a "*" in a value, preventing it from being interpreted as a substring indicator. The third illustrates the escaping of the backslash character.

The fourth example shows a filter searching for the four-byte value 0x00000004, illustrating the use of the escaping mechanism to represent arbitrary data, including NUL characters.

The final example illustrates the use of the escaping mechanism to represent various non-ASCII UTF-8 characters.

6. Security Considerations

This memo describes a string representation of LDAP search filters. While the representation itself has no known security implications, LDAP search filters do. They are interpreted by LDAP servers to select entries from which data is retrieved. LDAP servers should take care to protect the data they maintain from unauthorized access.

7. References

[1] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access

Protocol (v3)", RFC 2251, December 1997.

[2] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight

Directory Access Protocol (v3): Attribute Syntax Definitions", RFC

2252, December 1997.

[3] Specification of ASN.1 encoding rules: Basic, Canonical, and

Distinguished Encoding Rules, ITU-T Recommendation X.690, 1994.

[4] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO

10646", RFC 2044, October 1996.

[5] Crocker, D., "Standard for the Format of ARPA Internet Text

Messages", STD 11, RFC 822, August 1982.

8. Author's Address

Tim Howes
Netscape Communications Corp.
501 E. Middlefield Road
Mountain View, CA 94043
USA
Phone: +1 415 937-3419
EMail: howes@netscape.com

9. Full Copyright Statement

Copyright (C) The Internet Society (1997). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other

Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

H アクセス制御ディレクティブ書式

この付録では、アクセス制御項目(ACI)の書式(構文)について説明します。

この付録の内容は次のとおりです。

- 第H.1項「orclACIのスキーマ」

- 第H.2項「orclEntryLevelACIのスキーマ」

H.1 orclACIのスキーマ

ユーザー属性orclACIで定義されているアクセス制御ディレクティブのスキーマは、次のとおりです。

OrclACI:{ object_identifier NAME 'orclACI' DESC 'Stores an inheritable ACI' EQUALITY
accessDirectiveMatch SYNTAX 'accessDirectiveDescription'  USAGE
'directoryOperation'}

accessDirectiveDescription has the following BNF:
<accessDirectiveDescription>
::= access to <object> [by <subject> ( <accessList> )]+

<object> ::= [attr <EQ-OR-NEQ> ( * | (<attrList>) ) | entry]
[filter=(<ldapFilter>)] [DenyGroupOverride] [AppendToAll]

<subject> ::= <entity> [<BindMode>] [<BindIPFilter>] [Added_object_constraint=(<ldapFilter>)]
<entity> ::= * | self | dn="<regex>" | dnAttr=(<dn_attribute>) | group="<dn>" |
guidattr=(<guid_attribute>) | groupattr=(<group_attribute>) | [SuperUser]

BindMode=(LDAP_authentication_choice)|LDAP_security_choice)
LDAP_authentication_choice::= proxy | simple | MD5Digest | PKCS12
LDAP_security_choice::= SSLNoAuth | SSLOneWay | SASL

BindIPFilter=(<ldapFilter for orclipaddress>)
ex: (|(orclipaddress=1.2.3.*)(orclipaddress=1.2.4.*)), (&(orclipaddress!=1.2.*)(orclipaddress!=3.4.*))

<accessList> ::= <access> | <access>, <accessList>

<access> ::= none | compare | search | browse | proxy | read | selfwrite | write |
add | delete | nocompare | nosearch | nobrowse | noproxy |noread | noselfwrite |
nowrite | noadd | nodelete

<attrList> ::=  <attribute name> | <attribute name>,<attrList>

<EQ-OR-NEQ> ::=  = | !=

<regex> ::= <dn> | *,<dn_of_any_subtree_root>

注意:
前述の正規表現は、任意の式のどれにでも対応するというものではありません。構文で許可されているのは、ワイルド・カードの後にカンマと有効な識別名が続く式のみです。<dn_of_any_subtree_root>で示されている識別名は、いくつかのサブツリーのルートを指定することを意味しています。

H.2 orclEntryLevelACIのスキーマ

orclEntryLevelACIのBER書式は、orclACIの書式と同じです。

ユーザー属性orclEntryLevelACIで定義されているエントリ・レベルのアクセス制御ディレクティブのスキーマは、次のとおりです。

"orclEntryLevelACI":
{ object_identifier NAME 'orclEntryLevelACI' DESC 'Stores entry level ACL Directive'
EQUALITY accessDirectiveMatch SYNTAX 'orclEntryLevelACIDescription'
USAGE 'directoryOperation' }

<orclEntryLevelACIDescription>
::= access to <object> [by <subject> ( <accessList> )]+

I ディレクトリにおけるグローバリゼーション・サポート

この付録では、Oracle Internet Directoryで使用されるグローバリゼーション・サポートについて説明し、Oracle Internet Directory環境における様々なコンポーネントとツールに必要な環境変数NLS_LANGについて説明します。

Oracle Internet Directoryでは、グローバリゼーション・サポートを使用して、ネイティブ言語でデータを格納、処理および取得できます。これにより、Oracle Internet Directoryのユーティリティおよびエラー・メッセージが、自動的にネイティブ言語とロケールに適応されます。

関連項目:
グローバリゼーション・サポートを構成する前に、第3.8項「グローバリゼーション・サポート」を参照してください。

この付録の内容は次のとおりです。

- 第I.1項「文字セットおよびディレクトリについて」

- 第I.2項「環境変数NLS_LANG」

- 第I.3項「非AL32UTF8データベースの使用方法」

- 第I.4項「LDIFファイルでのグローバリゼーション・サポートの使用方法」

- 第I.5項「コマンド行LDAPツールでのグローバリゼーション・サポートの使用方法」

- 第I.6項「クライアント環境におけるNLS_LANGの設定」

- 第I.7項「バルク・ツールでのグローバリゼーション・サポートの使用方法」

I.1 文字セットおよびディレクトリについて

コンピュータ・システムで文字を処理する場合、文字のグラフィカルな表現のかわりに数値コードを使用します。たとえば、データベースにAという文字を格納する場合、実際にはソフトウェアによって文字として解釈される数値コードが格納されます。

文字グループ(アルファベット文字、表意文字、記号、句読点および制御文字など)は、文字セットとしてエンコードできます。エンコードされた各文字セットでは、セット内の各文字に一意のコードを割り当てます。たとえば、ASCIIコード体系では、英語の大文字アルファベットの最初の文字の文字コードはOx4ですが、EBCDICコード体系ではOxc1です。

コンピュータ業界では多くのエンコードされた文字セットが使用されています。これらの文字セットは、利用可能な文字の数やタイプおよび様々な面で異なります。

データベースの作成時には、エンコードされた文字セットを指定します。文字セットを選択すると、特に、データベース内で表示される言語が決定されます。

ほとんどの各国語文字セット、国際文字セットおよびベンダー固有文字セットの標準がサポートされています。

この項の内容は次のとおりです。

- 第I.1.1項「Unicodeについて」

- 第I.1.2項「OracleとUTF-8について」

- 第I.1.3項「Oracle Internet Directoryのアップグレード時のUTF8からAL32UTF8への移行」

I.1.1 Unicodeについて

日々のE-Businessの要件を満たすために必要な文字が十分に含まれている単一の文字セットはありません。たとえば、欧州連合内のすべての言語を表すことのできる各国語文字セットはありません。さらに、異なる文字セットでは同じ文字が異なるコードで表されている場合もあるため、文字セット間で競合が起きる可能性もあります。

これらの問題に対処するために、Unicodeと呼ばれるグローバルな文字セットが開発されました。これは、句読点、発音区別符号、数学記号、技術記号、音楽記号などを含むあらゆる言語の情報を格納できる、汎用のエンコードされた文字セットです。Unicode標準のバージョン3.2以降では、世界中のアルファベット、表意文字セットおよび記号のコレクションから、95,000を超える文字がサポートされています。これには45,000の補助文字が含まれており、そのほとんどは、まれにしか使用されないものの電子ドキュメントで表示するために必要な中国語、日本語および韓国語の文字です。

Unicodeには複数の実装標準があります。これを表I-1に示します。

表I-1 Unicodeの実装

実装

説明

UTF-8

Unicodeの可変幅8ビット・エンコーディング。1つのUnicode文字は1、2、3または4バイトになります。ヨーロッパ言語の記述に含まれる文字は、1バイトまたは2バイトで表示されます。アジア言語の記述に含まれる文字は3バイトで表示され、補助文字は4バイトで表示されます。

UCS-2

Unicodeの固定幅16ビット・エンコーディング。記述に関係なく、各文字は2バイトです。

UTF-16

Unicodeの16ビット・エンコーディング。Unicode 3.1で追加された補助文字をサポートするためのUCS-2の拡張方式です。

1つの文字は2バイトまたは4バイトです。ヨーロッパ言語およびアジア言語の記述に含まれる文字は2バイトで表示され、補助文字は4バイトで表示されます。

I.1.2 OracleとUTF-8について

Oracleがデータベース文字セットとしてUnicodeのサポートを開始したのは、Oracleデータベース・バージョン7からです。Oracle9iでは、AL32UTF8と呼ばれる新しいUTF-8文字セットを追加しました。このデータベース文字セットは、最新の補助文字を含む最新バージョンのUnicode(3.2)をサポートしています。オラクル社では、Unicode標準の将来のバージョンをサポートするため、必要に応じてAL32UTF8を拡張する予定です。

I.1.3 Oracle Internet Directoryのアップグレード時のUTF8からAL32UTF8への移行

Oracle Internet Directoryでは、AL32UTF8をサポートするようになりました。Oracle Internet Directoryを10g(10.1.4.0.1)より前のバージョンからアップグレードする場合は、パフォーマンスの向上のため、ディレクトリ・データベースの文字セットをUTF8からAL32UTF8へ変更することをお薦めします。この手順は、次のとおりです。

1. Character Set Scanner(CSSCAN)を実行して、現在のデータベースに無効なUTF8文字が含まれていないことを確認します。

2. CSALTERスクリプトを実行して、データベースをAL32UTF8に更新します。

関連項目:
Oracle Databaseドキュメント・ライブラリの『Oracle Databaseグローバリゼーション・サポート・ガイド』の文字セットの移行に関する章

I.2 環境変数NLS_LANG

NLS_LANGパラメータには、language、territoryおよびcharsetの3つのコンポーネントがあります。形式は次のとおりです。

NLS_LANG = language_territory.charset

各コンポーネントは、グローバリゼーション・サポート機能のサブセットの作用を制御します。

NLS_LANGパラメータのコンポーネントは、表I-2に示すとおりです。

表I-2 NLS_LANGパラメータのコンポーネント

コンポーネント

説明

language

Oracleメッセージ、曜日および月の名前に使用する言語などの規則を指定します。サポートしているそれぞれの言語には、American English(米語)、French(フランス語)またはGerman(ドイツ語)などの固有の名前があります。

languageを指定しない場合、デフォルトではAmerican English(米語)になります。

関連項目: 言語の全一覧は、Oracle Databaseドキュメント・ライブラリの『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください

territory

デフォルトのカレンダ、照合、日付、通貨単位および数値書式などの規則を指定します。サポートしているそれぞれの地域には、America(アメリカ)、France(フランス)またはCanada(カナダ)などの固有の名前があります。

territoryを指定しない場合、デフォルト値ではAmericaになります。

関連項目: 地域の全一覧は、Oracle Databaseドキュメント・ライブラリの『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください

charset

クライアント・アプリケーションが使用する文字セット(通常はユーザー端末で使用する文字セット)を指定します。サポートしているそれぞれの文字セットには、WE8MSWIN1252、JA16SJISまたはAL32UTF8などの一意の頭字語があります。

関連項目: 文字セットの全一覧は、Oracle Databaseドキュメント・ライブラリの『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください

コマンド行で、NLS_LANGを環境変数として設定できます。次は、NLS_LANGの適切な値の例です。

- AMERICAN_AMERICA.AL32UTF8

- JAPANESE_JAPAN.AL32UTF8

I.3 非AL32UTF8データベースの使用方法

Oracleディレクトリ・サーバーとデータベース・ツールは、非AL32UTF8データベース上で実行できますが、クライアント文字セットにある文字がすべて、文字コードが同じかどうかにかかわらず、データベース文字セットに含まれているかどうかを確認してください。そうでない場合、ldapadd、ldapdelete、ldapmodifyまたはldapmodifydn操作中にデータが消失する可能性があります。たとえば、シングルバイト文字のみを使用する基礎となるデータベース上で、マルチバイト文字セットを使用してldapadd操作を実行すると仮定します。入力するバイトのすべてがデータベースで受け入れられるわけではないため、データが消失します。

I.4 LDIFファイルでのグローバリゼーション・サポートの使用方法

関連項目:
『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のLDIFファイル形式の規則と例に関する説明

属性タイプの名前は必ずASCII文字列で、マルチバイト文字は使用できません。Oracle Internet Directoryは、属性の型名にマルチバイト文字をサポートしていません。ただし、Oracle Internet Directoryでは、属性値におけるマルチバイト文字(簡体字中国語(ZHS16GBK)の文字セットなど)の使用をサポートしています。

属性値は、異なる方法でエンコードでき、この方法でエンコードされた値は、Oracle Internet Directoryのツールで正しく解釈できます。次の項で説明する2つのシナリオがあります。

- 第I.4.1項「ASCII文字列のみを含むLDIFファイル」

- 第I.4.2項「UTF-8エンコーディング文字列を含むLDIFファイル」

I.4.1 ASCII文字列のみを含むLDIFファイル

この例では、属性値の文字列もASCII文字列です。

すべてのツールがデフォルトでUTF-8文字セットを使用しており、ASCIIはUTF-8の正しいサブセットであるため、いずれのツールもこのファイルを解釈できます。キーボードでASCII文字列のみの値を入力する場合も同様です。

I.4.2 UTF-8エンコーディング文字列を含むLDIFファイル

この例では、属性値の文字列もUTF-8文字列です。

デフォルトでは、すべてのツールでUTF8文字セットが使用されるため、これらのファイルはどのツールでも解析できます。キーボードでUTF-8文字列の値を入力する場合も同様です。

このようなファイルでは、一部の文字がマルチバイトの可能性があります。マルチバイト・キャラクタ文字列は、属性値としてLDIFファイルで使用することも、キーボードで入力することもできます。それらの文字列は、ネイティブ文字セットまたはUTF-8でエンコードできます。さらに、ネイティブ文字列またはUTF-8文字列のBASE64エンコーディング形式も可能です。

次のケースを説明します。

- ケース1: ネイティブ文字列(非UTF-8)

- ケース2: UTF-8文字列

- ケース3: BASE64でエンコードされたUTF-8文字列

- ケース4: BASE64でエンコードされたネイティブ文字列

ディレクトリ・サーバーはUTF-8エンコーディング文字列のみを理解し、UTF-8エンコーディング文字列を受信することを想定しているため、ケース1、3および4は、LDAPサーバーに送信する前に、UTF-8文字列に変換しておく必要があります。

I.4.2.1 ケース1: ネイティブ文字列(非UTF-8)

NLS_LANGが設定されていない場合、コマンド行LDAPツールldapadd、ldapaddmt、ldapbind、ldapcompare、ldapmoddn、ldapmod、ldapdeleteおよびldapsearchで-E character_set引数を使用します。NLS_LANGが設定されている場合、-E character_set引数を使用する必要はありません。

この例では、簡体字中国語のネイティブ文字列をUTF-8に変換しています。ベース識別名は、簡体字中国語で記述できます。

ldapsearch -h my_host -D "cn=orcladmin" -q -p 3060 -E ".ZHS16GBK" -b base_DN \
-s base  "objectclass=*"

encode="character_set"引数をコマンド行バルク・ツールbulkload、bulkmodify、bulkdeleteおよびldifwriteで使用します(ここで、character_setはLDIFファイルで使用されている文字セットです)。NLS_LANGをディレクトリのデータベースで使用されている文字セットに設定します。

I.4.2.2 ケース2: UTF-8文字列

変換は不要です。

I.4.2.3 ケース3: BASE64でエンコードされたUTF-8文字列

NLS_LANGが設定されていない場合でも、LDAPツールで-E character_set引数を使用する必要はありません。

コマンド行ツールでencode=character_set引数を使用する必要はありません。Oracle Internet Directoryツールは、BASE64でエンコードされたUTF-8文字列をUTF-8文字列に自動的にデコードします。

I.4.2.4 ケース4: BASE64でエンコードされたネイティブ文字列

NLS_LANGが設定されていない場合、コマンド行LDAPツールldapadd、ldapaddmt、ldapbind、ldapcompare、ldapmoddn、ldapmod、ldapdeleteおよびldapsearchで-E character_set引数を使用します。NLS_LANGが設定されている場合、-E character_set引数を使用する必要はありません。

encode="character_set"引数をコマンド行バルク・ツールbulkload、bulkmodify、bulkdeleteおよびldifwriteで使用します(ここで、character_setはLDIFファイルで使用されている文字セットです)。NLS_LANGをディレクトリのデータベースで使用されている文字セットに設定します。

Oracle Internet Directoryのツールは、BASE64でエンコードされたネイティブ文字列を、単純なネイティブ文字列に自動的にデコードします。その後、ネイティブ文字列は対応するUTF-8文字列に変換されます。

注意:
1つの入力ファイルで使用できる文字セットは1つのみです。

I.5 コマンド行LDAPツールでのグローバリゼーション・サポートの使用方法

Oracle Internet Directoryのコマンド行ツールは、キーボード入力またはLDIFファイル入力を次の方法で読み取ります。

- ASCII文字のみ

- 非ASCII入力(ネイティブ言語文字セット)

- UTF-8またはネイティブ文字列のBASE64でエンコードされた値(LDIFファイル入力のみ)

LDIFファイルまたはキーボードからの入力として使用されている文字セットがUTF-8以外の場合、コマンド行ツールは、LDAPサーバーに送信する前に、その入力をUTF-8形式に変換する必要があります。

コマンド行ツールで入力をUTF-8に変換するには、-E character_set引数を、任意のコマンド行LDAPツールで指定します。encode="character_set"引数を、bulkload、bulkmodify、bulkdeleteおよびldifwriteで指定します。

この項の項目は次のとおりです。

- 第I.5.1項「各ツールを使用するときの-E引数の指定」

- 第I.5.2項「例: コマンド行LDAPツールでの-E引数の使用方法」

I.5.1 各ツールを使用するときの-E引数の指定

-E引数で指定しないかぎり、クライアント・ツールでは常に文字セットがUTF-8(Oracle文字セット名はAL32UTF8)であるとみなされます。-E引数が指定されていると、BASE64でエンコードされた値はデコードされ、次にデコードされたバッファがUTF-8に変換されます。たとえば、-E ".ZHS16GBK"と指定すると、デコードされたバッファは、ディレクトリ・サーバーに送信される前に、簡体字中国語(GBK)からUnicode UTF-8に変換されます。

-E引数を指定すると、-E引数で指定した文字セット(-E ".character_set")がAL32UTF8文字セットに正しく変換されます。

コマンド行ツールは、-E引数を使用して、-E引数に指定された文字セットで入力を処理します。出力は、環境変数NLS_LANGで指定された文字セットで表示します。

たとえば、簡体字中国語の文字セット(ZHS16GBK)でエンコードされたLDIFファイルのエントリを、ldapaddを使用して追加するには、次のように入力します。

ldapadd -h myhost -p 3060 -E ".ZHS16GBK" -D cn=orcladmin -q -f my_ldif_file

この例では、ディレクトリ・サーバーに送信される前に、文字がldapaddツールによって".ZHS16GBK"(簡体字中国語の文字セット)から".AL32UTF8"に変換されます。

I.5.2 例: コマンド行LDAPツールでの-E引数の使用方法

表I-3に、-E引数を各コマンド行ツールで正しく使用する方法の追加例を示します。各例のコマンドにより、値".ZHS16GBK"で指定されている簡体字中国語からAL32UTF8にデータが変換されます。たとえば、各コマンドで、-Dオプションの値、および-qが指定された場合にプロンプトで入力するパスワードはGBKです。-E引数を指定すると、これらがUTF-8に変換されます。

表I-3の例には、.ZHS16GBK文字セットに属している実際の文字は含まれていないことに注意してください。したがって、これらの例は-E引数の指定なしで動作します。ただし、引数の値に.ZHS16GBK文字セット内の実際の文字が含まれる場合は、-E引数を使用する必要があります。

関連項目:
各コマンド行ツールの構文と使用方法は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のOracle Internet Directory管理ツールに関する説明を参照

表I-3 例: コマンド行ツールでの-E引数の使用方法

ツール

例

ldapbind

ldapbind -h my_host -p 3060 -E ".ZHS16GBK" -D "o=example,c=us" -q

ldapsearch

ldapsearch -h my_host -p 3060 -E ".ZHS16GBK" -D "o=example,c=us" -q

ldapadd

ldapadd -h my_host -p 3060 -E ".ZHS16GBK" -D "o=example,c=us" -q

ldapaddmt

ldapaddmt -h my_host -p 3060 -E ".ZHS16GBK" -D "o=example,c=us" -q

ldapmodify

ldapmodify -h my_host -p 3060 -E ".ZHS16GBK" -D "o=example,c=us" -q

ldapmodifymt

ldapmodifymt -h my_host -p 3060 -E ".ZHS16GBK" -D "o=example,c=us" -q

ldapdelete

ldapdelete -h my_host -p 3060 -E ".ZHS16GBK" -D "o=example,c=us" -q

ldapcompare

ldapcompare -h my_host -p 3060 -E ".ZHS16GBK" -D "o=example,c=us" \
-b "ou=Construction,ou=Manufacturing,o=example,c=us" \
-a title -v manager -q

ldapmoddn

ldapmoddn -h my_host -p 3060 -E ".ZHS16GBK" -D "o=example,c=us" \
-b "cn=Frank Smith,ou=Construction,ou=Manufacturing,c=us, o=example"\
-N "ou=Contracting,ou=Manufacturing,o=example,c=us" -r -q

I.6 クライアント環境におけるNLS_LANGの設定

クライアントで必要な出力がUTF-8の場合は、環境変数NLS_LANGを設定する必要はありません。この場合、環境変数NLS_LANGの文字セット・コンポーネントはデフォルトでAL32UTF8に設定され、クライアントからサーバーへの入力の過程およびサーバーからクライアントへの出力の過程で、文字セット変換の必要はありません。

クライアントで必要な出力がUTF-8以外の場合は、環境変数NLS_LANGを設定する必要があります。この設定によって、AL32UTF8文字セットからクライアントが要求した文字セットに正しく変換されます。

たとえば、環境変数NLS_LANGが簡体字中国語の文字セットに設定されている場合、コマンド行ツールは、その文字セットで出力を表示します。そうでない場合、出力にはデフォルトでAL32UTF8文字セットが使用されます。

注意:
Microsoft Windowsを使用している場合、サーバーの起動後にコマンド行ツールを使用するには、MS-DOSウィンドウでNLS_LANGをリセットする必要があります。MS-DOSセッションのコード・ページに一致する文字セットを設定してください。AL32UTF8は使用できません。MS-DOSセッションでコマンド行ツールに使用する文字セットの詳細は、Oracle Databaseインストレーション・ガイドfor Microsoft Windowsを参照してください。
Oracle Internet Directoryとともに、事前にインストールされたOracle Databaseを使用している場合、データベース文字セットもAL32UTF8に設定する必要があります。

関連項目: Oracle Databaseドキュメント・ライブラリの『Oracle Databaseグローバリゼーション・サポート・ガイド』、および『Oracle Databaseインストレーション・ガイドfor Microsoft Windows』。

レジストリのNLS_LANGパラメータの値を変更しないように注意してください。

I.7 バルク・ツールでのグローバリゼーション・サポートの使用方法

Oracle Internet Directoryでは、LDIFファイルのテキスト・データの読取りや書込みが、LDAP標準で指定されているように、常にUTF-8エンコーディングで行われます。

この項では、各バルク・ツールで使用する引数の例を示します。内容は次のとおりです。

- 第I.7.1項「bulkloadでのグローバリゼーション・サポートの使用方法」

- 第I.7.2項「ldifwriteでのグローバリゼーション・サポートの使用方法」

- 第I.7.3項「bulkdeleteでのグローバリゼーション・サポートの使用方法」

- 第I.7.4項「bulkmodifyでのグローバリゼーション・サポートの使用方法」

関連項目:
各バルク・ツールの引数のリストは、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のOracle Internet Directory管理ツールに関する説明を参照

I.7.1 bulkloadでのグローバリゼーション・サポートの使用方法

コマンドに引数encode="character_set"を追加します。この入力のLDIFファイルは"character_set"でエンコードされています。

たとえば、ORACLE_INSTANCEが設定されているのを確認してから、次を入力します。

bulkload connect="connect_string" \
encode=".ZHS16GBK" check="TRUE" generate="TRUE" file="my_ldif_file"

I.7.2 ldifwriteでのグローバリゼーション・サポートの使用方法

ldifwriteユーティリティは常に、マルチバイト文字列に対してBASE64でエンコードされた値を書き出します。

BASE64エンコーディングは、ディレクトリ・サーバーに格納されているUTF-8文字列に対して行うか、ldifwriteの実行時に環境変数NLS_LANGの設定で指定されたネイティブ文字列に対して行うことができます。

次に例を示します。

ldifwrite connect="connect_string" baseDN="baseDN" ldiffile="output_file"

環境変数NLS_LANGが未設定の場合またはlanguage_territory.AL32UTF8に設定されている場合、この例では、出力のLDIFファイルにマルチバイト文字のBASE64でエンコードされたUTF-8文字列が含まれます。

このLDIFファイルのディレクトリへのロードの詳細は、「ケース3: BASE64でエンコードされたUTF-8文字列」を参照してください。

環境変数NLS_LANGがAL32UTF8以外の文字セット(たとえば、".ZHS16GBK")に設定されている場合は、出力のLDIFファイルには、簡体字中国語(GBK)文字列のBASE64でエンコードされた値が含まれます。

このLDIFファイルのディレクトリへのロードの詳細は、「ケース4: BASE64でエンコードされたネイティブ文字列」を参照してください。

I.7.3 bulkdeleteでのグローバリゼーション・サポートの使用方法

引数encode="character_set"をコマンドに追加します。

次に例を示します。

bulkdelete connect="connect_string"  encode=".ZHS16GBK" \
baseDN="ou=manufacturing,o=example,c=us"

この例では、-baseオプションの値に、ZHS16GBKネイティブ文字セット(簡体字中国語)を使用できます。

I.7.4 bulkmodifyでのグローバリゼーション・サポートの使用方法

引数encode="character_set"をコマンドに追加します。

次に例を示します。

bulkmodify connect="my_service_name" \
encode=".ZHS16GBK" baseDN="ou=manufacturing,o=example,c=us" \
replace=TRUE" value=Foreman filter="objectclass=*"

この例では、basedn、valueおよびfilterの各引数の値を簡体字中国語GBK文字セットを使用して指定できます。

J ユーザーおよびグループの作成ベースおよび検索ベースに対するアクセス制御の設定

この付録では、Oracle Internet Directoryで、ユーザー検索ベース、ユーザー作成ベース、グループ検索ベースおよびグループ作成ベースに対するアクセス制御を設定する方法について説明します。

ユーザー検索ベース、ユーザー作成ベース、グループ検索ベース、グループ作成ベースを変更すると、新しいコンテナに対するアクセス制御を適切に設定する必要があります。

この付録の内容は次のとおりです。

- 第J.1項「ユーザー検索ベースおよびユーザー作成ベースに対するアクセス制御の設定」

- 第J.2項「グループ検索ベースおよびグループ作成ベースに対するアクセス制御の設定」

J.1 ユーザー検索ベースおよびユーザー作成ベースに対するアクセス制御の設定

ユーザー検索ベースおよびユーザー作成ベースに対するアクセス制御を設定するには、次のようにします。

1. 次の内容で、LDIF(user_aci.ldif)ファイルを作成します。

--- BEGIN LDIF file contents---
dn: %usersearch_or_createbase_dn%
changetype: modify
add: orclaci
orclaci: access to entry by group="cn=oracledascreateuser,
cn=groups,cn=OracleContext,%subscriberdn%"
added_object_constraint=(objectclass=orcluser*) (browse,add) by
group="cn=Common User Attributes, cn=Groups,
cn=OracleContext,%subscriberdn%" (browse) by
group="cn=PKIAdmins, cn=groups, cn=OracleContext,%subscriberdn%" (browse)
orclaci: access to entry filter=(objectclass=inetorgperson) by
group="cn=oracledascreateuser, cn=groups,cn=OracleContext,%subscriberdn%"
added_object_constraint=(objectclass=orcluser*) (browse,add) by
group="cn=oracledasdeleteuser, cn=groups,cn=OracleContext,%subscriberdn%"
(browse,delete) by group="cn=oracledasedituser,
cn=groups,cn=OracleContext,%subscriberdn%" (browse) by
group="cn=UserProxyPrivilege, cn=Groups,cn=OracleContext,%subscriberdn%"
(browse,
proxy) by dn="orclApplicationCommonName=DASApp, cn=DAS,
cn=Products,cn=oraclecontext" (browse,proxy) by self (browse, nodelete, noadd)
by
group="cn=Common User Attributes, cn=Groups,cn=OracleContext,%subscriberdn%"
(browse) by * (browse, noadd, nodelete)
orclaci: access to attr=(*) filter=(objectclass=inetorgperson) by
group="cn=oracledasedituser, cn=groups,cn=OracleContext,
%subscriberdn%" (read,search,write,compare) by self (
read,search,write,selfwrite,compare) by *
(read, nowrite, nocompare)
orclaci: access to attr=(userPassword)
filter=(objectclass=inetorgperson) by
group="cn=OracleUserSecurityAdmins,cn=Groups,
cn=OracleContext, %subscriberdn%"
(read,search,write,compare) by group="cn=oracledasedituser,
cn=groups,cn=OracleContext,%subscriberdn%"
(read,search,write,compare) by self
(read,search,write,selfwrite,compare) by group="cn=authenticationServices,
cn=Groups,cn=OracleContext,%subscriberdn%" (compare) by * (none)
orclaci: access to attr=(authpassword, orclpasswordverifier, orclpassword) by
group="cn=oracledasedituser,cn=groups,cn=OracleContext,%subscriberdn%"
(read,search,write,compare) by
group="cn=verifierServices,cn=Groups,cn=OracleContext,%subscriberdn%"
(search, read, compare) by self (search,read,write,compare) by * (none)
orclaci: access to attr=(orclpwdaccountunlock) by
group="cn=oracledasedituser,cn=groups,cn=OracleContext,%subscriberdn%" (
write) by * (none)
orclaci: access to attr=(usercertificate, usersmimecertificate) by
group="cn=PKIAdmins,cn=Groups,cn=OracleContext,%subscriberdn%"
(read, search, write, compare) by self (read, search, compare) by *
(read, search, compare)
orclaci: access to attr=(mail) by
group="cn=EmailAdminsGroup,cn=EmailServerContainer,cn=Products,
cn=OracleContext" (write) by group="cn=oracledasedituser,
cn=groups,cn=OracleContext,%subscriberdn%" (read,search,write,compare)
orclaci: access to attr=(orclguid, orclisenabled, modifytimestamp,mail)
by group="cn=Common User Attributes,
cn=Groups,cn=OracleContext,%subscriberdn%"
(read, search, compare) by group="cn=oracledasedituser,
cn=groups,cn=OracleContext,%subscriberdn%" (read,search,write,compare)
by * (read, nowrite, nocompare)
orclaci: access to attr=(orclpasswordhintanswer) by
group="cn=Common User Attributes,
cn=Groups,cn=OracleContext,%subscriberdn%" (read, search, compare) by self
(read,search,write,selfwrite,compare) by * (noread, nowrite, nocompare)
orclaci: access to attr=(orclpasswordhint) by
group="cn=Common User Attributes,
cn=Groups,cn=OracleContext,%subscriberdn%" (read, search, compare) by self
(read,search,write,selfwrite,compare) by
group="cn=OracleUserSecurityAdmins,cn=Groups,cn=OracleContext,
%subscriberdn%" (read,search,write,compare) by *
(noread, nowrite, nocompare)
orclaci: access to attr=(displayName, preferredlanguage,
orcltimezone,orcldateofbirth,orclgender,orclwirelessaccountnumber,cn,
uid,homephone,telephonenumber) by group="cn=Common User Attributes,
cn=Groups,cn=OracleContext,%subscriberdn%"
(read, search, compare) by group="cn=oracledasedituser,
cn=groups,cn=OracleContext,%subscriberdn%" (read,search,write,compare)
by self (read,search,write,selfwrite,compare) by *
(read, nowrite, nocompare)
-
add: orclentrylevelaci
orclentrylevelaci: access to entry by group="cn=oracledascreateuser,
cn=groups,cn=OracleContext,%subscriberdn%" added_object_constraint=
(objectclass=orcluser*) (browse, add) by * (browse)
---END LDIF file contents------

2. %subscriberdn%をサブスクライバのDNに置き換え、%usersearch_or_createbase_dn%を、新しいユーザー検索/作成ベースが示すコンテナの新しいDN値に置き換えます。

3. 次のように、ldapmodifyコマンドを入力します。

ldapmodify -p oidport -h oidhost -D cn=orcladmin -q -v \
-f  user_aci.ldif

J.2 グループ検索ベースおよびグループ作成ベースに対するアクセス制御の設定

グループ検索ベースおよびグループ作成ベースに対するアクセス制御を設定するには、次のようにします。

1. 次の内容で、LDIF(group_aci.ldif)ファイルを作成します。

--- BEGIN LDIF file contents---
dn: %groupsearch_or_createbase_dn%
changetype: modify
add: orclaci
orclaci: access to entry by group="cn=IASAdmins,
cn=groups,cn=OracleContext,%subscriberdn%"
added_object_constraint=(objectclass=orclcontainer) (browse,add)
orclaci: access to entry by group="cn=oracledascreategroup,
cn=groups,cn=OracleContext,%subscriberdn%"
added_object_constraint=(objectclass=orclgroup*) (browse,add) by
group="cn=Common
Group Attributes, cn=Groups,cn=OracleContext,%subscriberdn%" (browse)
orclaci: access to entry filter=(&(objectclass=orclgroup)(orclisvisible=false))
by
groupattr=(owner) (browse, add, delete) by dnattr=(owner)
(browse, add, delete) by
group="cn=Common Group Attributes, cn=Groups,cn=OracleContext,%subscriberdn%"
(browse) by * (none)
orclaci: access to entry
filter=(&(objectclass=orclgroup)(!(orclisvisible=false))) by
group="cn=oracledascreategroup, cn=groups,cn=OracleContext,%subscriberdn%"
added_object_constraint=(objectclass=orclgroup) (browse,add) by
group="cn=oracledasdeletegroup, cn=groups,cn=OracleContext,%subscriberdn%"
(browse,delete) by group="cn=oracledaseditgroup,
cn=Groups,cn=OracleContext,%subscriberdn%" (browse) by groupattr=(owner) (
browse,
add, delete) by dnattr=(owner) (browse, add, delete) by group="cn=Common Group
Attributes, cn=Groups,cn=OracleContext,%subscriberdn%" (browse)
orclaci: access to attr=(*)
filter=(&(objectclass=orclgroup)(orclisvisible=false)) by
groupattr=(owner) (read,search,write,compare) by dnattr=(owner)
(read,search,write,compare) by * (none) by group="cn=Common Group Attributes,
cn=Groups,cn=OracleContext,%subscriberdn%" (read, search, compare)
orclaci: access to attr=(*)
filter=(&(objectclass=orclgroup)(!(orclisvisible=false))) by
groupattr=(owner) (read,search,write,compare) by dnattr=(owner)
(read,search,write,compare)  by group="cn=oracledaseditgroup,
cn=groups,cn=OracleContext,%subscriberdn%" (read,search,write,compare) by
group="cn=Common Group Attributes, cn=Groups,cn=OracleContext,%subscriberdn%"
(read, search, compare)
-
add: orclentrylevelaci
orclentrylevelaci: access to entry by group="cn=oracledascreategroup,
cn=groups,cn=OracleContext,%subscriberdn%"
added_object_constraint=(objectclass=orclgroup) (browse, add) by
group="cn=IASAdmins, cn=groups,cn=OracleContext,%subscriberdn%"
added_object_constraint=(objectclass=orclcontainer) (browse,add) by * (browse)
---END LDIF file contents------

2. %subscriberdn%をサブスクライバのDNに置き換え、%groupsearch_or_createbase_dn%を、新しいグループ検索/作成ベースが示すコンテナの新しいDN値に置き換えます。

3. 次のように、ldapmodifyコマンドを入力します。

ldapmodify -p oidport -h oidhost -D cn=orcladmin -q -v -f group_aci.ldif

K ディレクトリでのユーザー証明書の検索

この付録では、Oracle Internet Directoryでユーザー証明書を検索する方法について説明します。

10g (10.1.4.0.1)より、コマンド行からのバイナリ属性usercertificateの検索が可能になりました。

10g リリース2(10.1.2.0.2)より前のリリースでは、証明書からユーザーを特定するには、証明書で指定されている識別名を使用する必要がありました。これを証明書の一致といいます。Oracle Internet Directoryでは、10g リリース2(10.1.2.0.2)から、証明書の一致に加えて、証明書のマッピングも使用できるようになりました。証明書の一致では、ユーザー証明書がディレクトリにプロビジョニングされている必要があります。証明書のマッピングでは、ユーザー証明書のプロビジョニングは必要はありません。

この付録の内容は次のとおりです。

- 第K.1項「証明書のマッピング」

- 第K.2項「検索タイプ」

K.1 証明書のマッピング

証明書のマッピングを使用すれば、証明書とユーザーの識別名とのマッピング・ルールを定義できます。証明書のマッピング・ルールは、証明書を解析するためのルールと、ディレクトリにユーザー・アイデンティティを問い合せるためのルールの集まりです。マッピング・ルールでは、証明書のカスタム拡張のみを使用できます。

次の例は、証明書マッピング・ルールを追加、削除および変更する方法を示しています。

証明書マッピング・ルールの追加

ldapmodifyを使用してマッピング・ルールを追加する方法は次のとおりです。

ldapmodify -D "cn=orcladmin" -q -h hostName -p port_number -f certMapRuleAdd.ldif

certMapRuleAdd.ldifファイルは次のようになります。

dn: cn=maprule1,cn=SASL-EXTERNAL,cn=Identity Mapping Configurations,cn=Server Configurations
cn: maprule1
objectclass: orclidmapping
objectclass: orclcertidmapping
orclSearchScope: subtree
orclSearchFilter: (cn=$(2.16.750.5.14.2.81.2.5.1))
orclcertExtensionOID: 2.16.750.5.14.2.81.2.5
orclcertExtensionAttribute: 2.16.750.5.14.2.81.2.5.1

証明書マッピング・ルールの削除

ldapdeleteを使用してマッピング・ルールを削除する方法は次のとおりです。

ldapdelete hostName -D "cn=orcladmin" -q -p port_number \
"cn=maprule1,cn=SASL-EXTERNAL,cn=Identity Mapping Configurations,cn=Server \
Configurations"

証明書マッピング・ルールの変更

ldapmodifyを使用してマッピング・ルールを変更する方法は次のとおりです。

ldapmodify -D "cn=orcladmin" -q -h hostName -p port_number -f certMapRuleMod.ldif

certMapRuleMod.ldifファイルは次のようになります。

dn: cn=maprule1,cn=SASL-EXTERNAL,cn=Identity Mapping Configurations,cn=Server Configurations
changetype:modify
replace: attrName
attrName: attrValue

K.2 検索タイプ

次の2種類の証明書検索フィルタを使用できます。

- "usercertificate=certificate_serial_number$certificate_issuer_DN"形式のフィルタ。証明書の検索には、証明書のシリアル番号および証明書発行者のDNの組合せが使用されます。この組合せを、証明書の一致値と言います。

- "usercertificate;binary=base_64_encoded_value_of_certificate"形式のフィルタ。このフィルタを使用すると、次の2つの事柄に応じて、6つの検索タイプのいずれかを使用できます。

- DSA構成設定の属性(DN: "cn=dsaconfig,cn=configsets,cn=oracle internet directory")の値、orclpkimatchingrule

- LDAP制御GSL_CERTIFICATE_CONTROL、2.16.840.1.113894.1.8.23の有無

"usercertificate;binary=base_64_encoded_value_of_certificate"形式のフィルタで使用可能な6つの検索タイプは次のとおりです。

" width="100%">

LDAP制御の存在

orclpkimatchingruleの値

検索の動作

なし

使用しない

usercertificateの検索に、クライアント証明書のハッシュ値を使用する。

存在

0

完全一致検索を実行する。クライアント証明書のサブジェクトDNが検索ベースとなる。このDNとディレクトリ内のユーザーDNとが比較される。検索範囲はBase。フィルタはobjectclass=*。

存在

1

usercertificateの検索に、クライアント証明書のハッシュ値を使用する。

存在

2(デフォルト)

usercertificateの検索に、クライアント証明書のハッシュ値を使用する。この検索の結果がない場合は、完全一致検索を実行する。

存在

3

マッピング・ルールが使用される。

存在

4

最初にマッピング・ルールが使用される。何も検索されない場合は、値を2とみなして検索が続行される。

LDAP制御の使用方法の詳細は、『Oracle Fusion Middleware Oracle Identity Managementアプリケーション開発者ガイド』の「LDAPプロトコルに対する拡張機能」を参照してください。

注意:

- サブストリング・フィルタを使用してusercertificate属性を検索することはできません。

- 完全一致検索では、検索フィルタに使用できる属性値のアサーションは1つのみです。

- 1レベル検索およびサブツリー検索のみがサポートされています。

- catalogツールでは、ユーザー証明書のカタログ(ct_orclcertificatehashおよびct_orclcertificatematch)はサポートされていません。

- 10g(10.1.4.0.1)に証明書のハッシュ値を導入する場合は、証明書を以前のリリースからアップグレードする必要があります。『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のupgradecert.plコマンド行ツールのリファレンス。

関連項目:
「直接認証」

L データベース・コピー・プロシージャを使用したディレクトリ・ノードの追加

この付録では、データベース・コピー・プロシージャを使用して、Oracle Internet Directoryの既存のレプリケート・システムに新しいノードを追加する方法について説明します(コールド・バックアップとも呼ばれます)。

注意:
このプロシージャはOracle Internet Directoryでのみ機能します。Oracle Single Sign-Onなど、他のOracle Identity Managementコンポーネントがインストールされている場合は、このプロシージャを使用しないでください。Oracle Internet Directoryノードがスタンドアロンの場合は、データベース・コピー・プロシージャを使用して新しいディレクトリ・レプリケーション・グループ(DRG)を作成できます。このプロシージャは、Oracle Databaseアドバンスト・レプリケーション・ベースのレプリカと、完全LDAPベース・レプリカにのみ適用できます。

この付録の内容は次のとおりです。

- 第L.1項「定義」

- 第L.2項「前提条件」

- 第L.3項「スポンサ・ディレクトリ・サイトの環境」

- 第L.4項「新規ディレクトリ・サイトの環境」

- 第L.5項「ディレクトリ・ノードの追加」

L.1 定義

スポンサ・サイトは、Oracle Internet Directoryとそのリポジトリ(Oracleデータベース)がインストールされているサイト、ホストまたはノードです。スポンサ・サイトはスポンサ・ノードとも呼ばれます。

新規サイトは、Oracle Internet Directoryリポジトリのコピー先となるサイト、ホストまたはノードです。新規サイトは新規ノードとも呼ばれます。

L.2 前提条件

このプロシージャを開始するには、コンピューティング環境が次の前提条件を満たしている必要があります。

1. 新規ディレクトリ・サイトとスポンサ・ディレクトリ・サイトで、オペレーティング・システム、バージョンおよびパッチ・レベルが同じである必要があります。オペレーティング・システムのパッチ・レベルが異なると、このプロシージャが機能しない場合があります。

2. このプロシージャを実行する前に、スポンサ・ディレクトリのリポジトリのバックアップを強くお薦めします。

3. このプロシージャではOracleデータ・ファイルをコピーするので、使用しているネットワーク環境によってパフォーマンスが異なります。ネットワークの通信速度が遅い場合は、第40章「レプリケーションの設定」または付録C「Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーションの設定」で説明されている方法でレプリケーション・グループを設定することを検討してください。または、圧縮したOracleデータ・ファイルをリムーバブル・メディアに保存し、物理的に移動する方法もあります。ネットワークについては、ローカルのシステム管理者またはネットワーク管理者に確認してください。

4. Oracleデータベースをよく理解しているユーザーのみが、このプロシージャを実行してください。

5. スポンサ・サイトがすでにアドバンスト・レプリケーション・グループの一員である場合、スポンサ・ノードはマスター定義サイト(MDS)である必要があります。

L.3 スポンサ・ディレクトリ・サイトの環境

この付録の例は、スポンサ・ディレクトリ・サイトが次の環境であることを前提としています。

Hostname = rst-sun
Domain name = example.com
ORACLE_BASE = /private/oracle/app/oracle
ORACLE_HOME = /private/oracle/app/oracle/product/OraHome_1
ORACLE_SID  = LDAP
LD_LIBRARY_PATH = $ORACLE_HOME/lib
NLS_LANG = AMERICAN_AMERICA.AL32UTF8
datafile location = /private/oracle/oradata/LDAP
Dump destination =  /private/oracle/app/oracle/admin/LDAP/pfile,
/private/oracle/app/oracle/admin/LDAP/bdump,
/private/oracle/app/oracle/admin/LDAP/cdump,
/private/oracle/app/oracle/admin/LDAP/udump,
/private/oracle/app/oracle/admin/LDAP/create

L.4 新規ディレクトリ・サイトの環境

この付録の例は、新規ディレクトリ・サイトが次の環境であることを前提としています。

Hostname = dsm-sun
Domain name = example.com
ORACLE_BASE = /private1/oracle/app/oracle
ORACLE_HOME = /private1/oracle/app/oracle/product/OraHome_1
ORACLE_SID  = NLDAP
LD_LIBRARY_PATH = $ORACLE_HOME/lib
NLS_LANG = AMERICAN_AMERICA.AL32UTF8
datafile location = /private1/oracle/oradata/NLDAP
Dump destination =  /private1/oracle/app/oracle/admin/NLDAP/pfile,
/private1/oracle/app/oracle/admin/NLDAP/bdump,
/private1/oracle/app/oracle/admin/NLDAP/cdump,
/private1/oracle/app/oracle/admin/NLDAP/udump,
/private1/oracle/app/oracle/admin/NLDAP/create

ホスト名とドメイン名以外のすべてが、手順10のOracle Databaseのインストール時に作成されます。

L.5 ディレクトリ・ノードの追加

1. 次のようにしてノードを追加し、ステータスを確認します。

1. Identity ManagementとOracle Internet Directoryコンポーネントをスポンサ・ノードにインストールします。『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』を参照してください。

関連項目:

- 使用しているオペレーティング・システムのOracle Databaseのインストレーション・ガイド

- Oracle Fusion Middleware Getting Started With Installation for Oracle WebLogic Server

- Oracle Fusion Middlewareインストレーション・プランニング・ガイド

2. Oracle Internet Directoryのステータスを確認するには、次のように入力します。

$ cd ORACLE_INSTANCE/bin
$ ./opmnctl status

ステータスはAliveである必要があります。

2. スポンサ・ノード上のOracle Internet Directoryおよび他のすべてのopmnプロセスを次のように入力して停止します。

$ cd ORACLE_INSTANCE/bin
$ opmnctl stopall

3. スポンサ・ノードで次の手順を実行します。

1. コマンド行プロンプトで、次のSQL*Plusコマンドを実行します。

$ sqlplus /nolog
SQL> connect / as sysdba
SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE RESETLOGS;

このコマンド・シーケンスを実行すると、ダンプ先ディレクトリの下にトレース・ファイルが作成されます。

ユーザー・ダンプ先ディレクトリの位置を確認するには、次のコマンドを実行します。

SQL> show parameter user_dump_dest;

新たに作成したトレース・ファイルの名前は次の形式になります。

ORACLE_SID_ora_processid.trc

2. スポンサ・ノードのデータベースとOracle Net Servicesリスナーを停止します。デフォルトのリスナー名はLISTENERです。次のように入力します。

$ lsnrctl stop
$ sqlplus /nolog
SQL> connect / as sysdba
SQL> shutdown
SQL> exit

3. コピーされるノードがアドバンスト・レプリケーション・ベースのDRGの一員の場合、次の手順を実行します。

- DRGの他のノードで、LDAPレプリケーション・サーバーのみを停止します。

$ oidctl connect=connect_string server=oidrepld \
instance=instance_number stop

スポンサ・ノード以外のすべてのノードで、この手順を繰り返します。対応するノードに適したネット・サービス名を指定してください。

- ノードを既存のDRGに追加する場合、SQL*Plusを使用してOracle Databaseアドバンスト・レプリケーションを静止させます。次のコマンドは、マスター定義サイト(MDS)でのみ実行してください。

$ cd ORACLE_HOME/ldap/admin
$ sqlplus /nolog SQL> connect repadmin/repadmin_password;
SQL> @oidrsusp.sql

注意:
SQL*Plusのこの手順は、マスター定義サイトでのみ実行してください。

これで、レプリケーションが停止され、他のノードの変更が可能になります。

4. 手順3aで作成したトレース・ファイルの名前を、同じディレクトリ内でnewdb.sqlに変更します。

$ cp ORACLE_SID_ora_processid.trc newdb.sql

4. スポンサ・ノードで、newdb.sqlをテキスト・エディタで開き、STARTUP NOMOUNT文とCREATE CONTROLFILE文以外のすべての行を削除します。これらの行を削除した後のnewdb.sqlファイルは次のようになります。

STARTUP NOMOUNT
CREATE CONTROLFILE REUSE SET DATABASE "LDAP" RESETLOGS  NOARCHIVELOG
MAXLOGFILES 16
MAXLOGMEMBERS 3
MAXDATAFILES 100    MAXINSTANCES 8
MAXLOGHISTORY 454
LOGFILE
GROUP 1 '/private/oracle/oradata/LDAP/redo01.log'  SIZE 10M,
GROUP 2 '/private/oracle/oradata/LDAP/redo02.log'  SIZE 10M,
GROUP 3 '/private/oracle/oradata/LDAP/redo03.log'  SIZE 10M
-- STANDBY LOGFILE
DATAFILE
'/private/oracle/oradata/LDAP/system01.dbf',
'/private/oracle/oradata/LDAP/sysaux01.dbf',
'/private/oracle/oradata/LDAP/users01.dbf',
'/private/oracle/oradata/LDAP/dcm.dbf',
'/private/oracle/oradata/LDAP/portal.dbf',
'/private/oracle/oradata/LDAP/ptldoc.dbf',
'/private/oracle/oradata/LDAP/ptlidx.dbf',
'/private/oracle/oradata/LDAP/ptllog.dbf',
'/private/oracle/oradata/LDAP/oca.dbf',
'/private/oracle/oradata/LDAP/discopltc1.dbf',
'/private/oracle/oradata/LDAP/discopltm1.dbf',
'/private/oracle/oradata/LDAP/oss_sys01.dbf',
'/private/oracle/oradata/LDAP/wcrsys01.dbf',
'/private/oracle/oradata/LDAP/uddisys01.dbf',
'/private/oracle/oradata/LDAP/b2b_dt.dbf',
'/private/oracle/oradata/LDAP/b2b_rt.dbf',
'/private/oracle/oradata/LDAP/b2b_idx.dbf',
'/private/oracle/oradata/LDAP/b2b_lob.dbf',
'/private/oracle/oradata/LDAP/bam.dbf',
'/private/oracle/oradata/LDAP/orabpel.dbf',
'/private/oracle/oradata/LDAP/attrs1_oid.dbf',
'/private/oracle/oradata/LDAP/battrs1_oid.dbf',
'/private/oracle/oradata/LDAP/gcats1_oid.dbf',
'/private/oracle/oradata/LDAP/gdefault1_oid.dbf',
'/private/oracle/oradata/LDAP/svrmg1_oid.dbf',
'/private/oracle/oradata/LDAP/ias_meta01.dbf',
'/private/oracle/oradata/LDAP/undotbs.dbf'
CHARACTER SET AL32UTF8
;

5. スポンサ・ノードのファイルnewdb.sqlの編集を次のように続行します。

1. 次の行が変更対象の行です。

CREATE CONTROLFILE REUSE DATABASE "LDAP" RESETLOGS  NOARCHIVELOG

次のように変更します。

CREATE CONTROLFILE REUSE SET DATABASE "NLDAP" RESETLOGS  NOARCHIVELOG

2. データベースとログ・ファイルのUNIXディレクトリ位置を変更し、新規ノード・サイトのディレクトリを指し示すようにします。

この例では、newdb.sqlを次のように変更します。

STARTUP NOMOUNT
CREATE CONTROLFILE REUSE SET DATABASE "NLDAP" RESETLOGS  NOARCHIVELOG
MAXLOGFILES 16
MAXLOGMEMBERS 3
MAXDATAFILES 100
MAXINSTANCES 8
MAXLOGHISTORY 454
LOGFILE
GROUP 1 '/private1/oracle/oradata/NLDAP/redo01.log'  SIZE 10M,
GROUP 2 '/private1/oracle/oradata/NLDAP/redo02.log'  SIZE 10M,
GROUP 3 '/private1/oracle/oradata/NLDAP/redo03.log'  SIZE 10M
-- STANDBY LOGFILE
DATAFILE
'/private1/oracle/oradata/NLDAP/system01.dbf',
'/private1/oracle/oradata/NLDAP/sysaux01.dbf',
'/private1/oracle/oradata/NLDAP/users01.dbf',
'/private1/oracle/oradata/NLDAP/dcm.dbf',
'/private1/oracle/oradata/NLDAP/portal.dbf',
'/private1/oracle/oradata/NLDAP/ptldoc.dbf',
'/private1/oracle/oradata/NLDAP/ptlidx.dbf',
'/private1/oracle/oradata/NLDAP/ptllog.dbf',
'/private1/oracle/oradata/NLDAP/oca.dbf',
'/private1/oracle/oradata/NLDAP/discopltc1.dbf',
'/private1/oracle/oradata/NLDAP/discopltm1.dbf',
'/private1/oracle/oradata/NLDAP/oss_sys01.dbf',
'/private1/oracle/oradata/NLDAP/wcrsys01.dbf',
'/private1/oracle/oradata/NLDAP/uddisys01.dbf',
'/private1/oracle/oradata/NLDAP/b2b_dt.dbf',
'/private1/oracle/oradata/NLDAP/b2b_rt.dbf',
'/private1/oracle/oradata/NLDAP/b2b_idx.dbf',
'/private1/oracle/oradata/NLDAP/b2b_lob.dbf',
'/private1/oracle/oradata/NLDAP/bam.dbf',
'/private1/oracle/oradata/NLDAP/orabpel.dbf',
'/private1/oracle/oradata/NLDAP/attrs1_oid.dbf',
'/private1/oracle/oradata/NLDAP/battrs1_oid.dbf',
'/private1/oracle/oradata/NLDAP/gcats1_oid.dbf',
'/private1/oracle/oradata/NLDAP/gdefault1_oid.dbf',
'/private1/oracle/oradata/NLDAP/svrmg1_oid.dbf',
'/private1/oracle/oradata/NLDAP/ias_meta01.dbf',
'/private1/oracle/oradata/NLDAP/undotbs.dbf'
CHARACTER SET AL32UTF8
;

6. 初期化パラメータ・ファイルinit$ORACLE_SID.oraを、スポンサ・ディレクトリのデータベースからinit$ORACLE_SID_NEW_DIR_DB.oraにコピーします。初期化パラメータ・ファイルのデフォルトの場所は、UNIXまたはLinuxの場合は$ORACLE_HOME/dbs、Windowsの場合は%ORACLE_HOME%\databaseです。ここでは、次に示すように、/private/oracle/app/oracle/product/OraHome_1/dbs/initLDAP.oraを/private/oracle/app/oracle/product/OraHome_1/dbs/initNLDAP.oraにコピーします。

$ cd ORACLE_HOME/dbs
$ cp initLDAP.ora initNLDAP.ora

初期化パラメータ・ファイルのかわりにサーバー・パラメータ・ファイルspfile$ORACLE_SID.oraまたはspfile.oraを使用している場合は、サーバー・パラメータ・ファイルから初期化パラメータ・ファイルを作成します。たとえば、spfile$ORACLE_SID.oraがデフォルトの場所である$ORACLE_HOME/dbsにある場合、次のように入力します。

$ sqlplus /nolog
SQL> connect / as sysdba
SQL> create pfile from spfile
SQL> shutdown immediate

このコマンド・シーケンスを実行すると、spfileLDAP.oraからinitLDAP.oraファイルが作成され、/private/oracle/app/oracle/product/OraHome_1に配置されます。サーバー・パラメータ・ファイルがデフォルトの場所にない場合は、次の例のように、完全なパスを指定する必要があります。

SQL> connect / as sysdba
SQL> create pfile='/private/oracle/initLDAP.ora' from
spfile=/private/oracle/initLDAP.ora
SQL> shutdown immediate

初期化パラメータ・ファイルを作成したら、この手順の最初に説明した方法でそのファイルのコピーを作成します。

7. スポンサの新しい初期化パラメータ・ファイルで、次の変更を行います。

1. JOB_QUEUE_PROCESSESパラメータがあれば、コメント・アウトします。

2. dbnameパラメータをLDAPからNLDAPに変更します。

3. 新規サイトのドメイン名がスポンサ・ディレクトリのドメイン名と異なる場合は、db_domainパラメータも変更します。

4. 次のパラメータの場所を変更して、新規サイトの場所を指し示すようにします。

background_dump_dest
core_dump_dest
user_dump_dest
control_files
db_recovery_file_dest

5. 手順7dに記載されているパラメータに加え、DB_RECOVERY_FILE_DESTやDB_CREATE_FILE_DESTなど、ノード固有のパラメータが初期化パラメータ・ファイルに含まれている場合は、それらのパラメータも変更します。

この例の場合、変更後の初期化パラメータ・ファイルinitNLDAP.oraは次のようになります。

*.aq_tm_processes=1
*.background_dump_dest='/private1/oracle/app/oracle/admin/NLDAP/bdump'
*.compatible='10.1.0.2.0'
*.control_files='/private1/oracle/app/oracle/admin/NLDAP/control01.ctl',
'/private1/oracle/app/oracle/admin/NLDAP/control02.ctl',
'/private1/oracle/app/oracle/admin/NLDAP/control03.ctl'
*.core_dump_dest='/private1/oracle/app/oracle/admin/NLDAP/cdump'
*.db_block_size=8192*.db_cache_size=50331648
*.db_domain='example.com'
*.db_file_multiblock_read_count=16
*.db_name='NLDAP'*.db_recovery_file_dest='/private/oracle1/app/oracle/flash_recovery_area'
*.db_recovery_file_dest_size=2147483648
*.dispatchers='(PROTOCOL=TCP)(PRE=oracle.aurora.server.GiopServer)',
'(PROTOCOL=TCP)(PRE=oracle.aurora.server.SGiopServer)'
*.java_pool_size=67108864#*.job_queue_processes=5
*.large_pool_size=8388608
*.max_commit_propagation_delay=0
*.open_cursors=300
*.pga_aggregate_target=33554432*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
*.sessions=400
*.shared_pool_size=150994944
*.undo_management='AUTO'
*.undo_tablespace='UNDOTBS'
*.user_dump_dest='/private1/oracle/app/oracle/admin/NLDAP/udump'

8. 新規ノードの接続詳細が含まれるようtnsnames.oraファイルを編集します。次のサンプル・ファイルを参照してください。

LDAP.ACME.COM =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = rst-sun)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = ldap.acme.com)
)
)
NLDAP.ACME.COM =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = dsm-sun)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = nldap.acme.com)    )
)

9. すべてのデータ・ファイルのアーカイブを作成し、アーカイブしたファイルを圧縮します。newdb.sqlのDATAFILEの下に示されたファイルをすべて含めてください。

たとえば、次のコマンドを実行すると、データベース・ファイルの場所に移動し、OID_DB.tar.Zという圧縮アーカイブを生成できます。

$ cd $ORACLE_BASE/oradata/$ORACLE_SID
$ tar -cvf OID_db.tar *.dbf
$ compress OID_db.tar

10. ソフトウェアのみのオプションを使用して、Oracle Databaseを新規ノードにインストールします。使用しているプラットフォームのOracle Databaseのインストレーション・ガイドおよび『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』を参照してください。

11. 新規ノードでソフトウェアのみのインストールが完了すると、次のディレクトリが存在します。
/private1/oracle/app/oracle/product/OraHome_1/diag/rdbms

新規ノードで次のディレクトリを作成します。

- データファイルの場所: /private1/oracle/app/oracle/oradata/NLDAP

- ダンプ先:
/private1/oracle/app/oracle/admin/NLDAP/adump

/private1/oracle/app/oracle/admin/NLDAP/udump

/private1/oracle/app/oracle/flash_recovery_area

- トレース・ファイルの場所: /private1/oracle/app/oracle/product/OraHome_1/diag/rdbms/nldap/nldap/trace

12. FTPまたはその他の適切なツールを使用して、手順9でスポンサ・ノードに作成したアーカイブ・ファイルを新規ノードにコピーします。新規ノードのデータベース・ファイルの場所にディレクトリを移動し、FTPを使用してrst-sunからアーカイブ・ファイルをコピーします。

$ cd /private1/oracle/app/oracle/oradata/NLDAP
$ ftp
ftp> open rst-sun
Connected to rst-sun.us.example.com.
220 rst-sun FTP server (UNIX(r) System V Release 4.0) ready.
Name (rst-sun:oracle):
331 Password required for oracle.
Password:
230 User oracle logged in.
ftp> cd /private/oracle/oradata/LDAP
250 CWD command successful.
ftp> binary
200 Type set to I.
ftp> mget oradb.tar.Z

データ・ファイルのサイズが非常に大きく(数GBまたはTB)、ネットワーク帯域幅が狭いときは、テープやディスクなどのメディアを使用して、圧縮したファイルをスポンサ・ノードから新規ノードに移動することを検討してください。

新規ノードでアーカイブ・ファイルを展開します。次に例を示します。

$ uncompress oradb.tar.Z
$ tar xvf oradb.tar

データ・ファイルが正しいディレクトリに展開されたことを確認してください。この例では、/private1/oracle/oradata/NLDAPディレクトリに展開します。

13. スポンサ・ノードがアドバンスト・レプリケーション・グループの一員の場合、次の手順を実行します。

1. FTPなどのツールを使用して、初期化パラメータ・ファイルinitLDAP.oraを、スポンサ・ノード(rst-sun)から新規ノードのUNIXディレクトリ$ORACLE_HOME/dbsへコピーします。ファイル名をinitNLDAP.oraに変更します。
コピー後、コピーしたinitLDAP.oraファイルのデータが破損していないことを確認します。

ファイルinitLDAP.oraを編集します。次の変更を行います。

.db_name='NLDAP'

次のように変更します。

.db_name='LDAP'

2. FTPなどの適切なツールを使用して、手順5でスポンサ・ノードに作成したファイルnewdb.sqlを新規ノードにコピーします。newdb.sqlの名前をolddb.sqlに変更します。
olddb.sqlを編集します。次の変更を行います。

CREATE CONTROLFILE REUSE SET DATABASE "NLDAP" RESETLOGS  NOARCHIVELOG

次のように変更します。

CREATE CONTROLFILE REUSE SET DATABASE "LDAP" RESETLOGS  NOARCHIVELOG

3. tnsnames.oraをコピーし、tnsnames.ora.bkとします。
tnsnames.oraを編集します。次の変更を行います。

LDAP.ACME.COM =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = rst-sun)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = ldap.acme.com)
)
)
NLDAP.ACME.COM =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = dsm-sun)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = nldap.acme.com)    )
)

次のように変更します。

LDAP.ACME.COM =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = dsm-sun)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = ldap.acme.com)    )
)

4. 新規ノードのシェル・プロンプトで、ORACLE_BASE、ORACLE_HOMEおよびORACLE_SIDの各環境変数を設定します。次に例を示します(Cシェルを使用)。

$ setenv ORACLE_BASE /private1/oracle/app/oracle
$ setenv ORACLE_HOME /private1/oracle/app/oracle/product/OraHome_1
$ setenv ORACLE_SID LDAP

5. 同じシェルで、次の例に示すように、SQL*Plusを使用してolddb.sqlを実行します。

cd /private1/oracle/app/oracle/admin/NLDAP/udump
$ sqlplus /nolog
SQL> connect / as sysdba
SQL> @olddb.sql
SQL> shutdown normal
SQL>exit

6. 次のように、データベースとリスナーを起動します。

$ sqlplus /nolog
SQL> connect / as sysdba
SQL> startup mount
SQL> alter database open resetlogs
SQL> exit
$ lsnrctl start

7. 別のノードを使用して構成されたアドバンスト・レプリケーションを持つノードからデータベース・コピーを実行した場合、新規ノードでLDAP_REPレプリケーション・グループを削除する必要があります。これを行うには、次のコマンドを実行します。

sqlplus / as sydba
SQL> dbms_defer_sys.delete_tran(null,null);
SQL> dbms_defer_sys.delete_error(null,null);
SQL> dbms_repcat.purge_master_log(null,null,null);
SQL> exit

sqlplus rep_admin_db_account_name/password
SQL> exec dbms_repcat.drop_master_repgroup( gname => 'LDAP_REP' )
SQL> shutdown immediate

14. FTPまたは他の適切なツールを使用して、初期化パラメータ・ファイルinitLDAP.oraを、スポンサ・ノード(rst-sun)から新規ノードのUNIXディレクトリ$ORACLE_HOME/dbsへコピーします。コピー後、コピーしたinitLDAP.oraファイルのデータが破損していないことを確認します。
これに加えて、データベース・パスワード・ファイルorclpwORACLE_SIDもスポンサ・ノードから新規ノードへコピーします。

15. 新規ノードで、$ORACLE_HOME/dbsディレクトリ(UNIX)またはORACLE_HOME\databaseディレクトリ(Windows)に次のファイルが存在しないことを確認します。

- spfileNLDAP.ora

- spfile.ora

これらのファイルのいずれかが存在する場合、スポンサ・ノードからコピーしたinitNLDAP.oraファイルではなく、そのファイルがOracleデータベースで使用されます。

16. FTPまたはその他の適切なツールを使用して、手順5でスポンサ・ノードに作成したファイルnewdb.sqlを新規ノードにコピーします。次に例を示します。

$ cd /private1/oracle/app/oracle/admin/NLDAP/udump
$ ftp
ftp> open rst-sun
ftp> cd /private1/oracle/app/oracle/admin/LDAP/udump
ftp> mget newdb.sql

17. 新規ノードのUNIXシェル・プロンプトで、ORACLE_BASE、ORACLE_HOMEおよびORACLE_SIDの各環境変数を設定します。次に例を示します(Cシェルを使用)。

$ setenv ORACLE_BASE /private1/oracle/app/oracle
$ setenv ORACLE_HOME /private1/oracle/app/oracle/product/OraHome_1
$ setenv ORACLE_SID NLDAP

18. 同じUNIXシェルで、次の例に示すように、SQL*Plusを使用してnewdb.sqlを実行します。

$ sqlplus /nolog
SQL> connect / as sysdba
SQL> @newdb.sql
SQL> shutdown normal
SQL>exit

19. 新規ノードの変更を完了します。

1. 次のように、データベースとリスナーを起動します。

$ sqlplus /nolog
SQL> connect / as sysdba
SQL> startup mount
SQL> alter database open resetlogs
SQL> exit
$ lsnrctl start

2. 新規ノードのグローバル・データベース名を変更します。

SQL> connect / as sysdba
SQL> alter database rename global_name to NLDAP;
SQL> exit

新規ノードのORACLE_SIDはNLDAPであることに注意してください。

3. 次のコマンドを使用して、一時ファイルを表領域に追加します。

SQL> connect / as sysdba
SQL> ALTER TABLESPACE TEMP ADD TEMPFILE 'temp01.dbf' size 2000k;
SQL> exit

値2000Kは単なる例です。環境の要件に応じて値を決定します。

20. 新規ノードでOracle Internet Directoryを構成します。

1. WebLogic Serverをインストールします。『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』を参照してください。

2. Oracle Internet Directoryをインストールします。『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』を参照してください。

注意:
新規ノードでOracle Internet Directoryを構成するときは、新規ノードのデータベース(手順10で作成)に関する情報を指定する必要があります。

3. opmnctlを使用してOracle Internet Directoryを停止します。

21. 新規ノードで、ウォレット・ファイルoidpwdlldap1とoidpwdr*を削除し、ODSパスワードをリセットします。

$ cd $ORACLE_INSTANCE/OID/admin
$ rm oidpwdlldap1 oidpwdr*

22. 新規ノードで、パスワードをリセットし、Oracle Internet Directoryプロセスを起動します。

oidpasswd connect=oiddb create_wallet=true

現在のデータベースのパスワード入力を要求されます。新しいデータベース・パスワードを入力し、新規パスワードを確認します。

opmnctlコマンドを使用して、新規ノードでOracle Internet Directoryを起動します。

$opmnctl startproc ias-component=oid1

23. この時点では、新規ノードでOracle Internet Directoryが稼働しています。ただし、新規Oracle Internet Directoryノードのreplicaid値は、スポンサ・ノードのレプリカIDのままです。したがって、新規ノードのreplicaidをリセットする必要があります。replicaidの新しい値は、hostname_sidの形式である必要があります。

- hostnameは、新規ノードのホスト名(ドメイン名なし)です。

- sidは、新規ノードのデータベースのORACLE_SIDです。

replicaidのすべての文字が小文字であることを確認してください。

1. chgrid.ldifファイルを作成します。内容は次のとおりです。

dn:
changetype: modify
replace: orclreplicaid
orclreplicaid: new_replicaid

2. ldapmodifyツールを使用してreplicaidを変更します。

$ORACLE_HOME/bin/ldapmodify -h new_node_host -p port_ldap_server -D cn=orcladmin -q -f chgrid.ldif

24. 新規ノードのレプリカIDは手順23で変更されたため、新規ノードの相対レプリカ・エントリを次のように再作成する必要があります。

$ remtool -pcleanup -bind "new_node_host:new_node_port/new_node_repl_pswd"

新しいレプリカIDに対応するレプリカ・エントリがまだないため、remtoolコマンドによりエラーが報告され、入力を求められます。remtoolコマンドは、その入力を使用して、エラーを修正します。次の例では、ユーザー入力は太字で示されています。

remtool -pcleanup -bind "new_node_host:new_node_port/new_node_repl_pswd"
Error occurred while getting replication configuration information.
This tool will try to rectify the problem if super user DN and password are provided.
Do you want to continue? [y/n] : y
Enter superuser DN                           : cn=orcladmin
Enter superuser password                     :
Enter new password of replication DN     :
Reenter new password of replication DN  :
DRG identified by replica ldap://new_node_host:new_node_port (new_replicaid) will be cleaned up.
Do you want to continue? [y/n] : y
------------------------------------------------------------------------------
------------------------------------------------------------------------------
Replica replica ldap://new_node_host:new_node_port (new_replicaid) has been cleaned up.

25. レプリカ・サブエントリの名前を変更したら、レプリカ・サブエントリのorclreplicauri属性、orclreplicasecondaryuri属性およびorclreplicastate属性も変更します。orclreplicauri属性とorclreplicasecondaryuri属性には、新規ノードのLDAPサーバーのURIを追加する必要があります。orclreplicastate属性は6に設定します。remtoolはこの属性を使用して、データベース・コピー・ベースのaddnodeであることを識別します。この値を変更するには、次の手順を実行します。

1. LDIFファイルmodsubentry.ldifを作成します。このファイルの内容は次のとおりです。

dn: orclreplicaid=new_replicaid,cn=replication configuration
changetype: modify
replace: orclreplicauri
# Use your host name and port number
# where ldap server is listening
orclreplicauri: ldap://new_node_host:new_node_port/  ---
replace:orclreplicasecondaryuri
# Use your fully qualified host name and
# the port number where ldap server is listening  orclreplicasecondaryuri:
ldap://new_node_host_with_domain_name:new_node_port/  ----
replace:orclreplicastate
orclreplicastate: 6

2. ldapmodifyツールを使用して、ディレクトリを次のように変更します。

$ ldapmodify -h new_node_host -p port_of_ldap_server -f modsubentry.ldif

26. Oracle Internet Directoryプロセスを停止します。

$opmnctl stopproc ias-component=oid1

27. 新規ノードで、changelog表をクリーンアップします。

$ sqlplus /nolog
SQL> connect ods/ods_password;
SQL> truncate table ods.ods_chg_log;
SQL> truncate table ods.ods_chg_stat;
SQL> truncate table ods.asr_chg_log;

28. 新規ノードがアドバンスト・レプリケーション・ベースのDRGの一部になる場合、次の手順を実行します。

1. 新規ノードを既存のDRGに追加する場合、Oracle Databaseアドバンスト・レプリケーションを構成するには、シェル・プロンプトで次のコマンドを実行します。

$ remtool -addnode

スポンサ・ノードと新規ノードで構成された新しいDRGを作成する場合、Oracle Databaseアドバンスト・レプリケーションを構成するには、シェル・プロンプトで次のコマンドを実行します。

$ remtool -asrsetup

2. 新規ノードとスポンサ・ノードを含め、すべてのノードでOracle Internet Directoryとレプリケーション・サーバーを起動します。
次のコマンドを使用してレプリケーション・サーバーを起動します。

oidctl connect=oiddb server=OIDREPLD instance=1 \
flags="-p new_node_port -h new_node_host" start

次に、resumeasrまたはoidrrsme.sqlを実行します。

29. 新規ノードがLDAPベースのレプリケーションの完全なレプリカである場合、LDAPベースのレプリケーションを構成し、完全なレプリカをファンアウトとして次のように追加します。

1. データベースとOracle Internet Directoryサーバーがスポンサ・ノードで稼働していることを確認します。
スポンサ・ノードで、次のように入力します。

$ sqlplus /nolog
SQL> connect / as sysdba
SQL> startup
SQL> exit
$ lsnrctl start
Start OID
$opmnctl startproc ias-component=oid1

次のように入力して、Oracle Internet Directoryのステータスを確認します。

$opmnctl status

2. remtoolを使用して、LDAPベース・レプリケーションを次のように構成します。

remtool -paddnode

3. 新規レプリケーション承諾のレプリケーション変更ステータスを初期化します。

- スポンサ・ノードから、最大の使用済変更番号を取得します。

$ ldapsearch -h sponsor_node_host -p sponor_node_port -b " " \
-s base "objectclass=*" lastchangenumber

- LDIFファイルchgstatus.ldifを作成します。このファイルの内容は次のとおりです。

dn: orclagreementid=new_agreement_id,orclreplicaid=new_replicaid,cn=replication configuration
changetype: modify
replace: orcllastappliedchangenumber;transport$sponsor_replicaid$new_replicaid
orcllastappliedchangenumber;transport$sponsor_replicaid$new_replicaid: Number_from_ldapsearch
-
replace: orcllastappliedchangenumber;apply$sponsor_replicaid$new_replicaid
orcllastappliedchangenumber;apply$sponsor_replicaid$new_replicaid: Number_from_ldapsearch

Number_from_ldapsearchは、ldapsearchコマンドを使用して取得したスポンサ・ノードからの最大変更番号のことです。

- ldapmodifyを使用して、スポンサ・ノードと新規ノードの両方に変更を適用します。

ldapmodify -p sponsor_node_port -h sponsor_node_host -v \
-f chgstatus.ldif
ldapmodify -p new_node_port -h new_node_host -v -f chgstatus.ldif

4. すべてのノードでOracle Internet Directoryとレプリケーション・サーバーを起動します。一方向レプリケーションの場合は、コンシューマ・ノードでのみレプリケーション・サーバーを起動します。

M Oracle Authentication Services for Operating Systems

Oracle Authentication Services for Operating Systemsを使用すると、記憶域の集中化、認証およびユーザー・アイデンティティ管理をOracle Internet Directoryで行えるようになります。

Oracle Authentication Services for Operating Systemsは、Oracle Internet Directory 10g (10.1.4.0.1)で導入され、11gリリース1 (11.1.1)で更新されました。

詳細は、Oracle Fusion Middleware Oracle Authentication Services for Operating Systems管理者ガイドを参照してください。

N Oracle Internet DirectoryでサポートされているRFC

この付録では、Oracle Internet DirectoryでサポートされているRFCのリストを示します。

表N-1は、Oracle Internet Directoryで現在サポートされているRFCのリストです。この中には、古くなってしまったり、新しいRFCによって更新されたものもあります。Oracle Internet Directoryは、新しいドキュメントに準拠するよう絶えず更新されています。

表N-1 サポートされているRFC

数値

タイトル

RFC 1274

The COSINE and Internet X.500 Schema

RFC 1488

The X.500 String Representation of Standard Attribute Syntaxes

RFC 1777

Lightweight Directory Access Protocol

RFC 1778

The String Representation of Standard Attribute Syntaxes

RFC 1779

A String Representation of Distinguished Names

RFC 1960

A String Representation of LDAP Search Filters

RFC 2079

Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource Identifiers (URIs)

RFC 2247

Using Domains in LDAP/X.500 Distinguished Names

RFC 2251

Lightweight Directory Access Protocol (v3)

RFC 2252

Lightweight Directory Access Protocol (v3) Attribute Syntax Definitions

RFC 2253

Lightweight Directory Access Protocol (v3) UTF-8 String Representation of Distinguished Names

RFC 2254

The String Representation of LDAP Search Filters

RFC 2255

The LDAP URL Format

RFC 2256

A summary of the X500 (96) User Schema for use with LDAPv3

RFC 2307

An Approach for Using LDAP as a Network Information Service

RFC 2377

Naming Plan for Internet Directory-Enabled Applications

RFC 2396

Uniform Resource Identifiers(URI): 汎用構文

RFC 2596

Use of Language Codes in LDAP

RFC 2696

LDAP Control Extension for Simple Paged Results Manipulation

RFC 2713

Schema for Representing Java(tm) Objects in an LDAP Directory

RFC 2798

Definition of the inetOrgPerson LDAP Object Class

RFC 2829

Authentication Methods for LDAP

RFC 2830

Lightweight Directory Access Protocol(v3): Extension for Transport Layer Security

RFC 2849

The LDAP Data Interchange Format(LDIF)- Technical Specification

RFC 2891

LDAP Control Extension for Server Side Sorting of Search Results

RFC 3112

LDAP Authentication Password Schema

RFC 3296

Named Subordinate References in Lightweight Directory Access Protocol(LDAP)Directories

RFC 3377

Core LDAP Requirements

RFC 3671

Collective Attributes in the Lightweight Directory Access Protocol(LDAP)

RFC 3673

Search results returning all operational attributes

RFC 4122

Universally Unique IDentifier (UUID) URN Namespace

RFC 4514

String Representation of Distinguished Names

RFC 5805

Lightweight Directory Access Protocol (LDAP) Transactions

Oracle Internet Directoryのベース・スキーマは、新しいRFC改訂版に準拠するよう継続的に改訂されています。

関連項目:
Internet Engineering Task Forceのホームページ(http://www.ietf.org/)

O Oracle Directory Services ManagerのJavaキーストアの管理

この付録では、Oracle Directory Services Manager (ODSM)のJavaキーストア(JKS)を管理する方法について説明し、JKSパスワードの取得、odsm.cer JKSの内容のリスト、および期限が切れた証明書の削除について説明します。

Oracle Directory Services Manager(ODSM)は、Javaキー・ストア(JKS)にその秘密鍵、証明書および信頼できる証明書を格納します。管理者は、ODSMのJKSの管理を担当します。実行する必要がある重要なタスクの1つは、期限が切れたODSMの証明書をJKSから削除することです。この付録では、次のことについて説明します。

この付録の内容は次のとおりです。

- 第O.1項「ODSMのJavaキーストアの管理の概要」

- 第O.2項「ODSMのJavaキーストア・パスワードの取得」

- 第O.3項「odsm.cer Javaキーストアの内容のリスト」

- 第O.4項「期限が切れた証明書の削除」

O.1 ODSMのJavaキーストアの概要

ODSMは、初めて呼び出されると、ランダム・パスワードを生成し、そのパスワードをJKSに割り当てます。JKSファイルは、odsm.cerという名前を持ちます。このファイルは、次の書式の名前のディレクトリに置かれます。

DOMAIN_HOME/config/fmwconfig/servers/AdminServer/applications/odsm/conf

ODSMは、Oracleによるセキュアな格納フレームワークである資格証明ストア・フレームワーク(CSF)内のJDKにこのパスワードを格納します。WebLogicサーバー管理者は、CSFに格納されているJDKパスワードを取得できます。

ODSMは、自身の自己署名証明書の生成とJKSへの格納も行います。自己署名証明書は、生成日から15000日間有効です。自己署名証明書は、テスト目的のみに使用されます。本番環境では、自己署名証明書を、認証局(CA)によって署名された証明書に置き換えることをお薦めします。

JKSを管理するためのWebベースのツールはありません。ODSMのJKSを管理するには、OracleのJREまたはJDKに用意されているコマンド行ツールであるkeytoolを使用します。

関連項目:

- CSFの詳細は、Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイドの資格証明ストアの構成に関する項を参照してください。

- JavaTM暗号化アーキテクチャAPIの仕様、リファレンスとkeytool(キーおよび証明書の管理ツール)を含めて、Oracle Javaの詳細は、次を参照してください。
http://www.oracle.com/technetwork/java/index.html

O.2 ODSMのJavaキーストア・パスワードの取得

Oracle Directory Services ManagerのJavaキー・ストアを管理するには、まずOracle Directory Services ManagerのJavaキー・ストア・パスワードを取得する必要があります。このパスワードを取得するには次の2つの方法があります。

- Enterprise Manager Fusion Middleware Controlの使用

- Pythonスクリプトの使用

O.2.1 Enterprise Manager Fusion Middleware Controlの使用

Enterprise Managerを使用してOracle Directory Services ManagerのJavaキー・ストア・パスワードを取得するには、次の手順を実行します。

1. weblogic administratorとしてEnterprise Managerに接続します。

2. Enterprise Managerのナビゲーション・パネルの左側で、「WebLogicドメイン」を開き、Oracle Directory Services Managerをデプロイするドメインを選択します。

3. Enterprise Managerのナビゲーション・パネルの右側で、「WebLogicドメイン」メニューをクリックし、「システムMBeanブラウザ」を選択します。

4. システムMBeanブラウザで、「アプリケーション定義のMBean」→「com.oracle.jps」→「ドメイン」 : 「NameOfTheDomainWhereODSMisDeployed」→「JPSCredentialStore」→JPSCredentialストアを開きます。

5. 詳細ペインに表示される「操作」タブをクリックします。

6. 次の図に示すように、getPortableCredential操作をクリックします。

図O-1 getPortableCredential操作

7. 次のページが表示されたら、getPortableCredentialメソッドのパラメータを入力する必要があります。

- 「P1」で「ODSMMap」と入力します。

- 「P2」で、「ODSMKey.Wallet」と入力します。

8. 「起動」ボタンをクリックします。
次の図に示すように、「パラメータ」表の下に「戻り値」表が表示されます。「パスワード」フィールドに、Oracle Directory Services ManagerのJavaキー・ストアのパスワードが表示されます。

図O-2 getPortableCredential操作

O.2.2 Pythonスクリプトの使用

Enterprise Managerを使用できない場合は、Pythonスクリプトを使用することによりOracle Directory Services ManagerのJavaキー・ストアのパスワードを取得できます。

このパスワードを取得するには、次の手順を実行します。

1. 次の内容の.pyファイル(たとえばodsm.pyなど)を作成します。

import sys,getopt
from oracle.security.jps.mas.mgmt.jmx.credstore import PortableCredential
connect(sys.argv[1], sys.argv[2], sys.argv[3])
domainRuntime()
params= ["ODSMMap", "ODSMKey.Wallet"]
sign=["java.lang.String", "java.lang.String"]
on=ObjectName("com.oracle.jps:type=JpsCredentialStore")
cred = None
cred = mbs.invoke(on, "getPortableCredential", params, sign)
if cred != None:
credObject = PortableCredential.from(cred)
print credObject
print "ODSM Java Key Store Password: " + String.valueOf(credObject.getPassword())

2. 次のコマンドを実行します。

$MW_HOME/oracle_common/common/bin/wlst.sh odsm.py <wls_admin_user>
<wls_admin_password> t3://<adminserver_host>:<adminserver_port>

次に例を示します。

$MW_HOME/oracle_common/common/bin/wlst.sh odsm.py weblogic welcome1
t3://myadminserver:7001

このスクリプトを実行すると、DomainMBeanをルートとする読取り専用ツリーであるdomainRuntimeツリーに出力場所が変更されます。

注意:
ヘルプを表示するには、コマンド行で「help(domainRuntime)」と入力します。

[Name : ODSM, Description : ODSM Key store password, expiry Date : null]
ODSM Java Key Store Password: XXXXXXXXXX

関連項目:
詳細は、次の公開資料を参照してください。

- Oracle Fusion Middlewareセキュリティ・ガイド

- Oracle Fusion Middleware MBeans Java API Reference for Oracle Platform Security Services

O.3 odsm.cer Javaキーストアの内容のリスト

JKSパスワードを取得したら、keytoolを使用してJKSを管理できます。

odsm.cerの内容を表示するには、次のようにkeytoolコマンドを使用します。

cd directory_where_odsm.cer_resides
JAVA_HOME/bin/keytool -list -keystore odsm.cer \
-storepass password_obtained_from_CSF

次に例を示します。

$ cd DOMAIN_HOME/config/fmwconfig/servers/AdminServer/applications/odsm/conf
$ JAVA_HOME/bin/keytool -list -keystore odsm.cer -storepass "&M)S86)/RB" -v

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 2 entries

Alias name: serverselfsigned
Creation date: Dec 26, 2008
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=OVD, OU=Development, O=Oracle, L=Redwood Shores, ST=California, C=US
Issuer: CN=OVD, OU=Development, O=Oracle, L=Redwood Shores, ST=California, C=US
Serial number: 495586b6
Valid from: Fri Dec 26 17:36:54 PST 2008 until: Wed Jun 24 18:36:54 PDT 2009
Certificate fingerprints:
MD5:  6C:11:16:F3:88:8D:18:67:35:1E:16:5B:3E:03:8A:93
SHA1: F4:91:39:AE:8B:AC:46:B8:5D:CB:D9:A4:65:BE:D2:75:08:17:DF:D0
Signature algorithm name: SHA1withRSA         Version: 3

*******************************************
*******************************************

Alias name: cn=rootca, o=oracle, c=us (0)
Creation date: Dec 31, 2008
Entry type: trustedCertEntry

Owner: CN=RootCA, O=Oracle, C=US
Issuer: CN=RootCA, O=Oracle, C=US
Serial number: 0
Valid from: Tue Dec 30 02:33:11 PST 2008 until: Mon Jan 24 02:33:11 PST 2050
Certificate fingerprints:
MD5:  72:31:7B:24:C9:72:E3:90:37:38:68:40:79:D1:0B:4B
SHA1: D2:17:84:1E:19:23:02:05:61:42:A9:F4:16:C8:93:84:E8:20:02:FF
Signature algorithm name: MD5withRSA
Version: 1

*******************************************
*******************************************

O.4 期限が切れた証明書の削除

証明書の期限が切れたときに、その証明書をJDKから自動的に削除するメカニズムはありません。管理者は証明書の期限が切れるタイミングを判別し、それを削除する必要があります。

この項の内容は次のとおりです。

- 第O.4.1項「証明書の有効期限の確認」

- 第O.4.2項「証明書の削除」

O.4.1 証明書の有効期限の確認

第O.3項「odsm.cer Javaキーストアの内容のリスト」で説明するとおり、keytoolを使用してodsm.cerのすべての証明書をリストします。このリストには、各証明書の有効な日付が含まれています。たとえば、次の証明書はSat Oct 31 09:41:23 PDT 2008まで有効です。

Alias name: cn=ovd, ou=development, o=MyCompany, l=redwood shores,
st=california, c=us (1241455283)
Creation date: May 5, 2008
Entry type: trustedCertEntry

Owner: CN=OVD, OU=Development, O=MyCompany, L=Redwood Shores, ST=California, C=US
Issuer: CN=OVD, OU=Development, O=Oracle, L=Redwood Shores, ST=California, C=US
Serial number: 49ff1ab3
Valid from: Mon May 04 09:41:23 PDT 2008 until: Sat Oct 31 09:41:23 PDT 2008
Certificate fingerprints:
MD5: 93:0E:41:5E:95:88:71:BD:8A:49:ED:A9:29:3B:0A:1E
SHA1: 84:C6:75:60:D9:BE:7B:CA:D6:8B:B5:4B:97:E4:20:39:44:82:FE:93
Signature algorithm name: SHA1withRSA
Version: 3

証明書の有効期間が終了したら、次の項で説明しているように、keytoolを使用して削除します。

O.4.2 証明書の削除

odsm.cerの証明書を削除するには、次のようにkeytoolを使用します。

cd directory_where_odsm.cer_is_present
JAVA_HOME/bin/keytool -delete -keystore odsm.cer
-storepass password_obtained_from_CSF -alias "cn=rootca, o=oracle, c=us (0)"

次に例を示します。

$> JAVA_HOME/bin/keytool -delete -keystore odsm.cer \
-storepass  "&M)S86)/RB"  -alias "cn=rootca, o=oracle, c=us (0)"
[Storing odsm.cer]

P Oracleスタックの起動と停止

この付録では、Oracleスタックのコンポーネントを起動および停止する方法について説明します。

Oracleスタックのコンポーネントは、特定の順序で起動および停止する必要があります。その点についてこの付録で説明します。

この付録の内容は次のとおりです。

- 第P.1項「スタックの起動」

- 第P.2項「スタックの停止」

P.1 スタックの起動

次の順序でスタック・コンポーネントを起動します。

1. Oracle Databaseを起動します。

1. データベースのORACLE_HOMEで、ORACLE_SID、ORACLE_HOMEおよびPATHの各環境変数を適切な値に設定します。

2. リスナーを起動します。

ORACLE_HOME/bin/lsnrctl start

3. データベースを起動します。

ORACLE_HOME/bin/sqlplus "/as sysdba"
startup

2. Oracle WebLogic管理サーバーを起動します。

注意:
ここに示されたコマンド行からOracle WebLogic管理サーバーを起動すると、サーバーはフォアグラウンドで実行され、出力が画面に送られます。ただし、コマンド行の先頭にnohupを使用すると、バックグラウンドでサーバーを実行できます。この場合は、すべての出力がnohup.outファイルに送信され、スクリプトによるUSER_NAMEおよびPASSWORDの要求が回避されます。nohupの使用時にパラメータをStartWebLogic.shに渡すには、『Oracle Fusion Middleware Oracle WebLogic Serverサーバーの起動と停止の管理』の「サーバーの起動と停止」の説明に従って起動アイデンティティ・ファイルを使用できます。

MW_HOME/user_projects/domains/DOMAIN_NAME/bin/startWebLogic.sh
SERVER_NAME {ADMIN_URL}

これらのスクリプトを実行する場合は次のようになります。

- DOMAIN_NAMEのデフォルト値はIDMDomainです。

- SERVER_NAMEはOracle WebLogic管理対象サーバーの名前を表します。デフォルト値はwls_ods1です。

- USER_NAMEとPASSWORDの値をスクリプトの実行時にオプションとして指定しない場合、その入力を要求されます。

- ADMIN_URLの値をスクリプトの実行時にオプションとして指定しない場合、値は継承されます。

3. ノード・マネージャが実行中であることを確認します。通常、Oracle WebLogic Administration Serverがノード・マネージャを起動します。ノード・マネージャがなんらかの理由によって実行されていない場合は、ノード・マネージャを起動します。

MW_HOME/wlserver_10.3/server/startNodeManager.sh

4. Oracle Internet Directory、Oracle Virtual Directoryなどのシステム・コンポーネントを起動します。

ORACLE_INSTANCE/bin/opmnctl startall

システム・コンポーネントが起動したかどうかは次を実行して確認できます。

ORACLE_INSTANCE/bin/opmnctl status -l

5. Oracle Directory Integration Platform、Oracle Directory Services ManagerなどのWebLogic管理対象コンポーネントを起動します。

MW_HOME/user_projects/domains/DOMAIN_NAME/bin/startManagedWebLogic.sh \
SERVER_NAME {ADMIN_URL}

バックグラウンドで管理対象コンポーネントを起動するには、Oracle WebLogic管理コンソールを使用します。詳細は、「Oracle Fusion Middleware Oracle WebLogic Serverの紹介」を参照してください。

WebLogic管理対象コンポーネントのステータスは、Oracle Enterprise Manager Fusion Middleware Controlで表示できます。第7.3項「Fusion Middleware Controlを使用したOracle Internet Directoryの管理」を参照してください。

P.2 スタックの停止

Oracle WebLogic管理コンソールを使用して、管理サーバーおよびすべての管理対象サーバーを停止できます。詳細は、「Oracle Fusion Middleware Oracle WebLogic Serverの紹介」を参照してください。

コマンド行からスタック・コンポーネントを停止するには、次の順序でコマンドを発行します。

1. Oracle Directory Integration Platform、Oracle Directory Services ManagerなどのWebLogic管理対象コンポーネントを停止します。

MW_HOME/user_projects/domains/DOMAIN_NAME/bin/stopManagedWebLogic.sh \
{SERVER_NAME} {ADMIN_URL} {USER_NAME} {PASSWORD}

2. Oracle Internet Directory、Oracle Virtual Directoryなどのシステム・コンポーネントを停止します。

ORACLE_INSTANCE/bin/opmnctl stopall

3. WebLogic管理サーバーを停止します。

MW_HOME/user_projects/domains/DOMAIN_NAME/bin/stopWebLogic.sh

4. ノード・マネージャを停止するには、killコマンドを使用します。

kill -9 pid

5. Oracle Databaseを停止します。

1. DatabaseのORACLE_HOMEで、ORACLE_SID、ORACLE_HOMEおよびPATHの各環境変数を適切な値に設定します。

2. データベースを停止します。

ORACLE_HOME/bin/sqlplus "/as sysdba"
shutdown immediate

3. リスナーを停止します。

ORACLE_HOME/bin/lsnrctl stop

Q ローリング・アップグレードの実行

この付録では、現在の環境にディレクトリ・レプリケーション・グループ(DRG)が構成されている場合に、Oracle Internet Directoryのローリング・アップグレードを実行する方法について説明します。

DRGのOracleホーム・ディレクトリをアップグレードするには、DRGのすべてのレプリケーション・サーバーを停止し、各Oracleホームをそれぞれ最新バージョンにアップグレードする必要があります。レプリケーション・サーバーを停止しないと、Oracleホーム・ディレクトリをアップグレードするときに問題が発生する可能性があります。

このアップグレード・プロセスによる停止時間およびサービスの喪失を回避するには、ローリング・アップグレードの手順に従って、他のOracle Internet DirectoryノードおよびDRG内の対応するレプリケーション・サーバーが稼働したままの状態で、各Oracleホーム・ディレクトリを個別にアップグレードすることをお薦めします。

ローリング・アップグレードの実行後にDRG内のノードに一貫性のないデータが残されることを回避するため、Oracle Internet Directoryでは次の操作が実行されます。

1. 着信LDAP更新リクエストを処理するOracle Internet Directoryマスター・ノードで、更新リクエストごとに変更ログ・エントリが生成されます。マスター・ノードは、DRGのどのノードでもかまいません(第Q.3項「ローリング・アップグレードの例」のノードA、BまたはC)。

2. DRG内のノードがローリング・アップグレード操作の完了後に元どおり稼働するかぎり、LDAPリクエストの着信時にノードが停止しているか、アップグレード中であるかにかかわらず、後続の変更はDRG内の他のすべてのノードに適用されます。
変更がターゲット・ノードに適用されると、適切な競合解消ロジックによって収束が保証されます。再試行ロジック(デフォルトではサイクル遅延付きで10回)によって、ターゲット・ノードの停止時などに、一時的な競合状態が処理されます。

この付録の内容は次のとおりです。

- 第Q.1項「ローリング・アップグレードの前提条件」

- 第Q.2項「ローリング・アップグレードの実行」

- 第Q.3項「ローリング・アップグレードの例」

Q.1 ローリング・アップグレードの前提条件

ローリング・アップグレードの手順を開始する前に、Oracle Internet Directoryの現在のバージョンに応じて、DRGの各Oracleホームに次の個別パッチを適用します。これらのパッチによって、remtoolおよびoidrepldバイナリがアップグレードされます。

- Oracle Internet Directoryバージョン11.1.1.2.0の場合、各OracleホームにOracle Bug#10431688の修正を適用します。

- Oracle Internet Directoryバージョン11.1.1.3.0の場合、各OracleホームにOracle Bug#10431664の修正を適用します。

- Oracle Internet Directoryバージョン11.1.1.4.0以上のリリースの場合、ローリング・アップグレードに前提条件パッチは必要ありません。

パッチ適用の詳細は、『Oracle Fusion Middlewareパッチ適用ガイド』を参照してください。

Q.2 ローリング・アップグレードの実行

Oracle Internet Directory DRGをアップグレードする手順は、次のとおりです。

1. アップグレードする最初のノード上のレプリケーション・サーバーを停止します。

2. 最初のノードから他の各ノードへのレプリケーションを次のように一時停止します。

remtool -psuspendrepl -fromnode first_node_host:first_node_port

このコマンドは、すべてのOracle Internet DirectoryノードのレプリカIDおよびそれらの各ディレクトリ・バージョン番号をリストします。要求されたとおりに他の各ノードのレプリカIDを指定するか、または他のすべてのノードへのレプリケーションを一時停止するallを入力します。

remtoolの詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』を参照してください。

3. DRGの最初のノードから他のすべてのノードへのレプリケーションが一時停止されたことを検証するには、次のldapsearchコマンドを実行します。

ldapsearch -h first_node_host -p OID_port  -b "" -s base "(objectclass=orclReplAgreementEntry)" orcllastappliedchangenumber

最初のノードから他のノードへのorcllastappliedchangenumberをサブタイプ・ステータスで探します。この値は0で、次の形式となります。

orcllastappliedchangenumber;status$replica_id_of_first_node$replica_id_of_other_node;transport

および

orcllastappliedchangenumber;apply;status$replica_id_of_first_node$replica_id_of_other_node

矛盾がある場合は、手順2を繰り返します。

4. アップグレードしようとしているノード上でOracle Internet Directoryを停止します。

5. 『Oracle Fusion Middlewareパッチ適用ガイド』の説明に従って、ノードにパッチを適用して現在のリリースに移行します。

6. アップグレードしたばかりのノード上でOracle Internet Directoryを起動します。

7. 他のノードはまだアップグレードされていないため、最初のノードと他のノードとの間のレプリケーションは再開しないでください。

8. アップグレードする2番目のノードでレプリケーション・サーバーを停止します。

9. 2番目のノードから、まだアップグレードされていない各ノードへのレプリケーションは一時停止します。

remtool -psuspendrepl -fromnode second_node_host:second_node_port

このコマンドは、すべてのOracle Internet DirectoryノードのレプリカIDおよびそれらの各ディレクトリ・バージョン番号をリストします。まだアップグレードされていない他の各ノードのレプリカIDを指定する必要があります。

10. 手順3と同じコマンドを2番目のノードに使用して、アップグレードしようとしているノードから、まだアップグレードされていないその他の各ノードへのレプリケーションが一時停止されていることを検証します。

11. アップグレードしようとしているノード上でOracle Internet Directoryを停止します。

12. 『Oracle Fusion Middlewareパッチ適用ガイド』の説明に従って、ノードにパッチを適用して現在のリリースに移行します。

13. アップグレードしたばかりのノード上でOracle Internet Directoryを起動します。

14. これで、2つのノードがアップグレードされたため、最初のアップグレード済ノードから2番目のアップグレード済ノードへのレプリケーションを再開します。

remtool -presumerepl -fromnode  first_upgraded_replica_host:port -tonode second_upgraded_replica_host:port

15. 次のldapsearchコマンドを実行して、DRGの最初のアップグレード済ノードから2番目のアップグレード済ノードへのレプリケーションが再開されたことを検証します。

ldapsearch -p OID_port -h first_upgraded_OID_host -b "" -s sub"(objectclass=orclReplAgreementEntry)" orcllastappliedchangenumber

最初のアップグレード済Oracle Internet Directoryノードから2番目のアップグレード済ノードへのorcllastappliedchangenumberをサブタイプ・ステータスで探します。値は1となっているはずです。

このldapsearchコマンドを、以前アップグレードした他のすべてのノードに対して繰り返します。矛盾がある場合は、手順14を繰り返します。

16. 2番目のアップグレード済レプリカでレプリケーション・サーバーを起動します。

17. アップグレードする3番目のノードでレプリケーション・サーバーを停止します。

18. 3番目のノードから、まだアップグレードされていない各ノード'(ある場合)へのレプリケーションを一時停止します。

19. 3番目のノードから、まだアップグレードされていない各ノードへのレプリケーションが一時停止されたことを検証します。

20. アップグレードする3番目のノード上でOracle Internet Directoryおよびその他のプロセスを停止します。

21. 『Oracle Fusion Middlewareパッチ適用ガイド』の説明に従って、ノードにパッチを適用して現在のリリースに移行します。

22. 3番目のノードでOracle Internet Directoryを起動します。

23. すでにアップグレードした各ノードから3番目のノードへのレプリケーションを再開します。

24. 各アップグレード済ノードから3番目のノードへのレプリケーションが再開されたことを検証します。

25. 3番目のノードでレプリケーションを開始します。

DRGのすべてのノードに対してこの手順を繰り返します。

ノードをアップグレードする前に、そのノードから、まだアップグレードされていない各ノード'へのレプリケーションを一時停止し、一時停止されていることを検証します。アップグレードしようとしているノード上でOracle Internet Directoryを停止します。ノードをアップグレードします。アップグレードしたばかりノードでOracle Internet Directoryを起動します。すでにアップグレードしたノードから、アップグレードしたばかりのノードへのレプリケーションを再開します。アップグレードしたばかりノードでレプリケーションを開始します。

Q.3 ローリング・アップグレードの例

次の例には、マルチマスターDRGに3つのOracle Internet DirectoryノードA、B、Cが含まれます。ローリング・アップグレードの手順を使用して、すべてのノードを現在のリリースにアップグレードする必要があります。この例では、最初にノードAを、次にノードB、ノードCの順にアップグレードします。

注意:
ローリング・アップグレードの手順を開始する前に、第Q.1項「ローリング・アップグレードの前提条件」の説明に従って、必要なパッチを適用します。

ノードをアップグレードする手順は、次のとおりです。

1. ノードAでレプリケーション・サーバーを停止します。

2. ノードAからノードBとノードC両方へのレプリケーションを一時停止します。次に例を示します。

remtool -psuspendrepl  -fromnode  HostA:PortA

このコマンドは、3つすべてのOracle Internet DirectoryノードのレプリカIDを表示します。ノードBのレプリカIDをremtoolへの入力として指定します。または、allを入力して、remtoolでBおよびCのレプリカIDが自動的に選択されるようにすることもできます。

3. 次のldapsearchコマンドを実行して、ノードAからノードBへのレプリケーションが一時停止されていることを検証します。

ldapsearch -p  PortA  -h  hostA  -b  "" -s  base "(objectclass=orclReplAgreementEntry)" orcllastappliedchangenumber

サブタイプstatusでorcllastappliedchangenumber属性を探します。この属性の値は0で、次の形式となります。

orcllastappliedchangenumber;apply;status$replica_id_of_node A$replica_id_of_node_B
orcllastappliedchangenumber:status$replicaid_of_node_A$replicaid_of_nodeB;transport

このステータス値に矛盾がある場合は、手順2を繰り返します。

同様に、ノードAからノードCへのレプリケーションが一時停止されていることを検証します。

4. ノードAでOracle Internet Directoryおよびその他のプロセスを停止します。

5. ノードAでパッチセット・アシスタント(PSA)を実行してノードを現在のリリースにアップグレードします。

6. ノードAでOracle Internet Directoryとレプリケーション・サーバーを起動します。ノードAがレプリケーションを再開する必要があるノードはないことに注意してください。

7. ノードBでレプリケーション・サーバーを停止します。

8. 次のコマンドを実行して、ノードBからノードCへのレプリケーションを一時停止します。

remtool -psuspendrepl -fromnode HostB:PortB -tonode HostC:PortC

9. 次のldapsearchコマンドを実行して、ノードBからノードCへのレプリケーションが一時停止されていることを検証します。

ldapsearch -p  PortB  -h  hostB  -b  "" -s  base "(objectclass=orclReplAgreementEntry)" orcllastappliedchangenumber

サブタイプstatusでorcllastappliedchangenumberを探します。値が0で、次の形式となっているはずです。

orcllastappliedchangenumber;apply;status$replica_id_of_node_B$replica_id_of_node_C
orcllastappliedchangenumber:status$replicaid_of_node_B$replicaid_of_node_C;transport

このステータス値に矛盾がある場合は、手順8を繰り返します。

10. ノードBでOracle Internet Directoryおよびその他のプロセスを停止します。

11. ノードBでPSAを実行してノードを現在のリリースにアップグレードします。

12. ノードBのOracle Internet Directoryを起動して、次のようにノードAからノードBへのレプリケーションを再開します。

remtool -presumerepl -fromnode HostA:PortA -tonode HostB:PortB

13. 次のldapsearchコマンドを実行して、ノードAからノードBへのレプリケーションが再開されたことを検証します。

ldapsearch -p OID_port -h hostA -b "" -s base "(objectclass= orclReplAgreementEntry)" orcllastappliedchangenumber

アップグレード済ノードAからノードBへのorcllastappliedchangenumberをサブタイプstatusで探します。値は1となっているはずです。

このステータス値に矛盾がある場合は、手順12を繰り返します。

14. ノードBでレプリケーション・サーバーを起動します。

15. ノードCでレプリケーション・サーバーを停止します。

16. ノードCでOracle Internet Directoryおよびその他のプロセスを停止します。他にアップグレードするノードはないため、レプリケーションを一時停止する必要はありません。

17. ノードCでPSAを実行してノードを現在のリリースにアップグレードします。

18. ノードCのOracle Internet Directoryを起動して、次のようにノードAからノードCへのレプリケーションを再開します。

remtool -presumerepl -fromnode HostA:PortA -tonode HostC:PortC

ノードBからノードCへのレプリケーションを再開します。

remtool -presumerepl -fromnode HostB:PortB -tonode HostC:PortC

19. 手順13と同様に、ノードAとノードBでldapsearchを実行して、レプリケーションが正常に再開されたことを検証します。次のレプリケーションを検証します。

- ノードAからノードC

- ノードBからノードC

20. ノードCでレプリケーション・サーバーを起動します。

R Oracle Internet Directoryに関するトラブルシューティング

この付録では、Oracle Internet Directoryのインストール、構成または実行中に発生する可能性のある一般的な問題のトラブルシューティング・ソリューションおよびエラー・メッセージについて説明します。

この付録の内容は次のとおりです。

- 第R.1項「問題と解決方法」

- 第R.2項「その他の情報」

R.1 問題と解決方法

この項では、Oracle Internet Directoryの一般的なエラー・メッセージ、問題点および解決方法について説明します。この付録には、次の項があります。

- 第R.1.1項「インストール時のエラー」

- 第R.1.2項「Oracle Databaseサーバー・エラー」

- 第R.1.3項「ディレクトリ・サーバーのエラー・メッセージとその原因」

- 第R.1.4項「Oracle Internet Directoryのクラッシュ時のコア・ダンプとスタック・トレースの取得」

- 第R.1.5項「TCP/IPの問題」

- 第R.1.6項「パスワード・ポリシーに関するトラブルシューティング」

- 第R.1.7項「ディレクトリのパフォーマンスに関するトラブルシューティング」

- 第R.1.8項「ポート構成に関するトラブルシューティング」

- 第R.1.9項「opmnctlを使用したOracle Internet Directoryコンポーネントの作成に関するトラブルシューティング」

- 第R.1.10項「Oracle Internet Directoryの起動に関するトラブルシューティング」

- 第R.1.11項「クライアント接続の中断が原因のOracle Internet Directoryエラー」

- 第R.1.12項「ディレクトリ・サーバーの起動、停止および再起動に関するトラブルシューティング」

- 第R.1.13項「Oracle Internet Directoryレプリケーションに関するトラブルシューティング」

- 第R.1.14項「変更ログのガベージ・コレクションに関するトラブルシューティング」

- 第R.1.15項「動的パスワード・ベリファイアに関するトラブルシューティング」

- 第R.1.16項「Oracle Internet Directoryパスワード・ウォレットに関するトラブルシューティング」

- 第R.1.17項「bulkloadに関するトラブルシューティング」

- 第R.1.18項「bulkdelete、bulkmodifyおよびldifwriteに関するトラブルシューティング」

- 第R.1.19項「catalogに関するトラブルシューティング」

- 第R.1.20項「remtoolに関するトラブルシューティング」

- 第R.1.21項「サーバー・チェーンに関するトラブルシューティング」

- 第R.1.22項「バージョン情報の表示」

- 第R.1.23項「Fusion Middleware ControlとWLSTに関するトラブルシューティング」

- 第R.1.24項「Oracle Directory Services Managerに関するトラブルシューティング」

- 第R.1.25項「ロックされたユーザー・アカウントに関するトラブルシューティング」

- 第R.1.26項「ポリシー・ストアの移行に関するトラブルシューティング」

R.1.1 インストール時のエラー

Oracle Databaseのインストール時および構成時には、マルチバイト・キャラクタに伴う問題を回避するため、文字セットAL32UTF8を選択することをお薦めします。

R.1.2 Oracleデータベース・サーバー・エラー

Oracle Internet DirectoryはOracle Databaseに依存するため、データベース・エラーによりディレクトリ・サーバーの問題が発生することがあります。この項では、Oracle Internet Directoryのログに表示されるデータベース・エラーを示します。

関連項目:
第R.1.7.3項「Oracleデータベース・サーバーのパフォーマンスが不十分」

R.1.2.1 Oracleデータベース・サーバー接続が停止している

Oracle Internet Directoryが停止しています。ログ・ファイルにORA-3113またはORA-3114が記録されています。

問題

Oracle Internet DirectoryのOracle Databaseとの接続が失われています。

解決方法

データベースとリスナーのステータスを、これらが稼働しているホストで直接あるいは間接的に確認します。必要に応じて再起動します。OIDMONでデータベースの起動が自動的に検出され、OIDLDAPDサーバーが再起動されます。

R.1.2.2 クライアント接続の中断が原因のOracleデータベース・サーバー・エラー

エラーsgslunrReadまたは30SendPortが表示されます

問題

これらのエラーは、LDAPクライアントの接続が突然切断されたことを示しています。

考えられる原因は次のとおりです。

- クライアント・プログラムが、バインド解除や中止を実行せずに、接続を終了した。
クライアントのマシンが停止した。

- ネットワークのコンポーネント(ロード・バランサやファイアウォールなど)が、構成されたタイムアウト設定が原因で接続を切断した。

- ネットワークが停止中。

解決方法

これらのエラーは、サーバー外部の状況が原因です。必要な場合は、ネットワーク管理者に報告してください。

R.1.2.3 スキーマ変更が原因のOracleデータベース・サーバー・エラー

エラーORA-1562が表示されます。

問題

ロールバック・セグメント領域に収まらないスキーマ・コンポーネントを追加しようとすると、このエラーが発生し、変更はコミットされません。

解決方法

この問題を解決するには、データベース・サーバーのロールバック・セグメントのサイズを増やします。

R.1.2.4 Oracle Database TNSリスナー・エラー(ORA-12520)

問題

Oracleデータベースに接続できないか、データベース接続が停止と復帰を断続的に繰り返し、接続の停止時に次のエラーが返されます。

Error ORA-12520: TNS:listener could not find available handler for requested type of server

この問題の潜在的な原因とその解決方法は次のとおりです。

- 第R.1.2.4.1項「Oracle DatabaseのPROCESSESパラメータの値が小さすぎる」

- 第R.1.2.4.2項「リスナー制御ユーティリティ(lsnrctl)で状態がblockedと表示される」

R.1.2.4.1 Oracle DatabaseのPROCESSESパラメータの値が小さすぎる

Oracle Databaseに同時に接続できるオペレーティング・システム・プロセスの最大数は、PROCESSESパラメータによって決定します。

この問題が断続的に発生し(つまり、データベース接続が停止と復帰を断続的に繰り返し)、接続の停止時にORA-12520エラーが返される場合、次の手順を使用して問題をトラブルシューティングします。

1. sysdbaユーザーとしてOracle Databaseにログインします。

2. PROCESSESパラメータの値を確認します。次に例を示します。

SQL> SHOW PARAMETERS PROCESSES;

NAME                                TYPE        VALUE
------------------------------------ ----------- ------------------------------
processes                           integer     150

3. V$RESOURCE_LIMITビューを確認して、一部のシステム・リソース用のグローバル・リソースの使用に関する情報を表示します。次に例を示します。

SQL> SELECT * FROM V$RESOURCE_LIMIT WHERE RESOURCE_NAME IN ('PROCESSES','SESSIONS');

MAX_UTILIZATIONの値がINITIAL_ALLOCATIONの値と同じ場合、PROCESSESパラメータの値が小さすぎる可能性があります。

4. 同様に、listener.logファイルで追加のエラーを確認します。このファイルは、通常、$ORACLE_HOME/network/logまたは$ORACLE_HOME/binディレクトリに存在します。
ORA-12520エラーの後に次のエラーがあるかどうかを確認します。

TNS-12516: TNS:listener could not find available handler with matching protocol stack error message

TNS-12516が存在する場合、接続数(Windowsシステムではスレッド、UNIXおよびLinuxシステムではプロセス)がPROCESSESデータベース・パラメータの制限に到達している可能性があります。

5. この問題を解決するには、PROCESSESパラメータの値を増やします。たとえば、次のコマンドでは、値が500に設定されます。

SQL> ALTER SYSTEM SET PROCESSES=500 SCOPE=spfile;

PROCESSESパラメータの値は、個々の環境に依存します。

6. Oracle Databaseサーバーを再起動します。次に例を示します。

SQL> SHUTDOWN IMMEDIATE
SQL> STARUP

解決方法

この問題を解決するには、次のようにします。

1. PROCESSESパラメータの値を増やします。たとえば、次のコマンドでは、値が500に設定されます。

SQL> ALTER SYSTEM SET PROCESSES=500 SCOPE=spfile;

PROCESSESパラメータの新しい値は、個々の環境に依存します。

2. Oracle Databaseサーバーを再起動します。次に例を示します。

SQL> SHUTDOWN IMMEDIATE
SQL> STARUP

R.1.2.4.2 リスナー制御ユーティリティ(lsnrctl)で状態がblockedと表示される

リスナー制御ユーティリティ(lsnrctl)で状態がreadyではなくblockedと表示される場合、リスナー構成の問題を確認します。

1. Oracle DatabaseのLOCAL_LISTENERエントリの値を確認します。次に例を示します。

# sqlplus ods@oiddb
SQL> SHOW PARAMETER LOCAL_LISTENER
NAME                                 TYPE       VALUE
------------------------------------ ----------- ------------------------------
local_listener                       string     LISTENER_ORCL

2. 前の手順におけるLOCAL_LISTENERの値をtnsnames.oraファイルの値と比較します。たとえば、次のtnsnames.oraファイルの出力を検討します。

...
LISTENER_ORCL =
(ADDRESS = (PROTOCOL = TCP)(HOST = host.example.com)(PORT = 1521))

解決方法

tnsnames.oraファイルのリスナー・エントリがデータベースのLOCAL_LISTENERパラメータと一致していない場合、そのリスナーを指し示すようにLOCAL_LISTENERパラメータを構成します。

データベースのLOCAL_LISTENERパラメータを更新します。次に例を示します。

SQL> ALTER SYSTEM SET LOCAL_LISTENER ='(ADDRESS=(PROTOCOL=TCP)(HOST=host.example.com)(PORT=1521))' scope=spfile;

または、tnsnames.oraにリスナーを指し示すエントリがある場合、かわりにそのリスナー名を使用します。次に例を示します。

ALTER SYSTEM SET LOCAL_LISTENER ='listener_name' scope=spfile;

R.1.3 ディレクトリ・サーバーのエラー・メッセージとその原因

この項では、発生する可能性のあるOracleディレクトリ・サーバーのエラー・メッセージを示します。各メッセージに続いて、そのエラーに関して最も可能性の高い原因が記述されています。『Oracle Fusion Middleware Error Messages Reference』も参照してください。

R.1.3.1 不適切な認証エラー

サーバーに対して匿名ユーザーによるバインドを実行しようとすると、コマンド行に次のエラー・メッセージが表示されます。

ldap_bind: Inappropriate authentication
ldap_bind: additional info: Server is Configured to Deny Anonymous Binds

問題

匿名バインドが無効になっています。ほとんどの環境では、一部のクライアントのみが匿名アクセスを必要とします。

解決方法

匿名ユーザーによるバインドを有効にしてください。

関連項目:
詳細は、第33.7項「匿名バインドの管理」を参照してください。

R.1.3.2 ユーザーまたはグループを編集したか、レルムを作成したことが原因の制約違反エラー

oidldap*.logに次のエラーが表示されます。

ORA-01483: invalid length for DATE or NUMBER bind variable.

次のエラーも画面に表示される場合があります。

LDAP: error code 19 - Constraint Violation

これらのエラーは断続的に発生する場合があります。

問題

AL32UTF8文字セットを使用するOracle 10g DatabaseにOracleAS Metadata Repositoryをロードした場合、ユーザーやグループを編集しようとしたり、Oracle Internet Directoryにアイデンティティ管理レルムを作成しようとしたりすると、エラーが発生することがあります。ユーザーの編集には、既存ユーザーの属性を編集する作業も含まれます。

解決方法

しばらくしてから、ユーザーをもう一度編集してください。

R.1.3.3 Oracleディレクトリ・サーバーから戻される標準エラー・メッセージ

表R-1に、標準エラー・メッセージとその原因を示します。Oracle Internet Directoryは、第R.1.3.4項「ディレクトリ・サーバーのその他のエラー・メッセージ」でリストされ、説明されているメッセージ以外のメッセージも戻します。

表R-1 標準エラー・メッセージ

エラー

原因

00: LDAP_SUCCESS

操作が正常に完了しました。

01: LDAP_OPERATIONS_ERROR

リクエストの処理時に、サーバーで一般的なエラーが発生しました。

02: LDAP_PROTOCOL_ERROR

クライアントのリクエストが、書式、構文などのLDAPプロトコル要件を満たしていませんでした。これは、次のような状況で発生します。サーバーで受信リクエストの解析中にデコード・エラーが発生した場合。リクエストが、エントリへの属性タイプの追加を指定する追加または変更リクエストであるのに、値が指定されていない場合。SSL資格証明の読取りでエラーが発生した場合。不明なタイプの変更操作が指定されている場合(LDAP_MOD_ADD、LDAP_MOD_DELETEおよびLDAP_MOD_REPLACE以外)。検索範囲が不明な場合。

03: LDAP_TIMELIMIT_EXCEEDED

検索時間が指定した制限時間を超えました。検索の制限時間が未指定の場合、Oracle Internet Directoryでは、デフォルトの制限時間である1時間が使用されます。

04: LDAP_SIZELIMIT_EXCEEDED

検索の問合せに一致するエントリが、指定したサイズ制限を超えました。検索のサイズ制限が未指定の場合、Oracle Internet Directoryでは、デフォルトのサイズ制限1000が使用されます。

05: LDAP_COMPARE_FALSE

指定した値は、エントリ内の値と同一ではありません。

06: LDAP_COMPARE_TRUE

指定した値は、エントリ内の値と同一です。

07: LDAP_STRONG_AUTH_NOT_SUPPORTED

リクエストしたバインド方法がサーバーでサポートされていません。たとえば、SASLクライアントがOracle Internet DirectoryによるKerberos認証をリクエストすると、このエラーを受け取ります。

09: LDAP_PARTIAL_RESULTS

サーバーから参照が戻されました。

10: LDAP_REFERRAL

サーバーから参照が戻されました。

12: LDAP_UNAVAILABLE_CRITICALEXTENSION

指定したリクエストはサポートされていません。

16: LDAP_NO_SUCH_ATTRIBUTE

リクエストで指定したエントリ内に、該当する属性は存在していません。

17: LDAP_UNDEFINED_TYPE

指定した属性の型が、スキーマ内で定義されていません。

19: LDAP_CONSTRAINT_VIOLATION

リクエスト内の値が、特定の制約に違反しています。

20: LDAP_TYPE_OR_VALUE_EXISTS

属性に指定した値が重複しています。

21: LDAP_INVALID_SYNTAX

指定された属性構文が無効です。検索のフィルタ構文が無効です。

32: LDAP_NO_SUCH_OBJECT

操作用に指定したベースが存在していません。

34: LDAP_INVALID_DN_SYNTAX

識別名構文にエラーがあります。

49: LDAP_INVALID_CREDENTIALS

資格証明が正しくないため、バインドに失敗しました。

50: LDAP_INSUFFICIENT_ACCESS

クライアントに、この操作を実行するためのアクセス権限がありません。

53: LDAP_UNWILLING_TO_PERFORM

一般的なエラーか、またはサーバーが読取り専用モードです。

65: LDAP_OBJECT_CLASS_VIOLATION

エントリに対する変更が、オブジェクト・クラスの定義に違反しています。

66: LDAP_NOT_ALLOWED_ON_NONLEAF

削除対象のエントリに子エントリがあります。

67: LDAP_NOT_ALLOWED_ON_RDN

相対識別名属性でこの操作は実行できません。たとえば、エントリの相対識別名属性を削除することはできません。

68: LDAP_ALREADY_EXISTS

追加条件が重複しています。

81: LDAP_SERVER_DOWN

ディレクトリ・サーバーと通信できません。このメッセージはSDKから戻されます。

82: LDAP_LOCAL_ERROR

クライアントで内部エラーが発生しました。このメッセージはクライアントのSDKから戻されます。

83: LDAP_ENCODING_ERROR

クライアントで、リクエストをエンコーディングするときにエラーが発生しました。このメッセージはSDKから戻されます。

84: LDAP_DECODING_ERROR

クライアントで、リクエストをデコードするときにエラーが発生しました。このメッセージはSDKから戻されます。

85: LDAP_TIMEOUT

クライアントが、その操作に指定したタイムアウトに達しました。このメッセージはSDKから戻されます。

86: LDAP_AUTH_UNKNOWN

認証方式が、クライアントのSDKで理解されません。

87: LDAP_FILTER_ERROR

検索フィルタが正しくありません。

88: LDAP_USER_CANCELLED

ユーザーが操作を取り消しました。

89: LDAP_PARAM_ERROR

LDAPルーチンに対するパラメータが正しくありません。

90: LDAP_NO_MEMORY

メモリー不足です。

R.1.3.4 ディレクトリ・サーバーのその他のエラー・メッセージ

表R-2に、ディレクトリ・サーバーのその他のエラー・メッセージとその原因を示します。これらのメッセージには、エラー・コードは表示されません。

Oracle Internet Directoryアプリケーションは、次のメッセージの一部に表示されるparameterタグを適切な実行時の値で置き換えます。

表R-2 その他のエラー・メッセージ

エラー

原因

%s属性が見つかりません。

特定の属性の型が、スキーマに定義されていません。

parameterが属性parameterに見つかりません。

値がその属性に見つかりません。(ldapmodify)

オブジェクト・クラスparameterのスキーマ情報が管理ドメインに含まれていません。

リクエストで指定したオブジェクト・クラスが、スキーマに存在していません。

クラスの追加に使用したOID parameterは別のクラスで使用されています。

指定したオブジェクト識別子が重複しています。(スキーマ変更)

属性parameterはすでに使用されています。

属性名が重複しています。(スキーマ変更)

属性parameterに構文エラーがあります。

属性名の定義に構文エラーがあります。(スキーマ変更)

属性parameterはこのスキーマでサポートされていません。

属性が定義されていません。(すべての操作)

属性parameterは単一の値です。

属性は単一値です。(ldapaddおよびldapmodify)

属性parameterがエントリに存在していません。

エントリに、この属性は存在していません。(ldapmodify)

属性の定義が正しくありません。

属性の定義に構文エラーがあります。(スキーマ変更)

現在はサポートされていません

このバージョンのLDAPリクエストは、このサーバーではサポートされていません。

削除対象のエントリが見つかりません。

削除操作に指定した識別名が見つかりません。

変更対象のエントリが見つかりません。

リクエストで指定したエントリが見つかりません。

parameterをエントリに追加中にエラーが発生しました。

modifyのadd操作が呼び出されたときに戻されました。システム・リソースが使用できないことが原因と考えられます。

属性値の暗号化時にエラーが発生しました。

ユーザー・パスワードの暗号化時にエラーが発生しました。(すべての操作)

DNの正規化でエラーが発生しました。

指定されたDNが無効です。DNの解析で構文エラーが発生しました。(すべての操作)

parameter属性のハッシングでエラーが発生しました。

属性に対するハッシュ・エントリの作成時にエラーが発生しました。(スキーマ変更)

parameterオブジェクト・クラスのハッシングでエラーが発生しました。

オブジェクト・クラスに対するハッシュ・エントリの作成時にエラーが発生しました。(スキーマ変更)

スキーマ・ハッシュの作成でエラーが発生しました。

スキーマに対するハッシュ表作成時にエラーが発生しました。(スキーマ変更)

parameterの置換でエラーが発生しました。

この属性の置換でエラーが発生しました。(ldapmodify)

属性parameterに対する値の正規化時にエラーが発生しました。

属性に対する値の正規化時にエラーが発生しました。(すべての操作)

parameterが必須またはオプションの属性リストで見つかりません。

指定した属性が、オブジェクト・クラスの要件どおりに、必須属性またはオプション属性のリストに存在していません。

この機能は組み込まれていません

その機能またはリクエストが現在はサポートされていません。(検索で索引付けされていない属性を指定するとこのエラーが生成されることがあります。)

無効な非同期通信インタフェースはparameterです。

リクエストで指定した特定のアクセス制御情報アイテム(ACI)が無効です。

必須属性parameterが管理ドメインparameterに定義されていません。

未定義の属性を参照しています。(スキーマ変更)

必須属性が不足しています。

特定のエントリに対する必須属性が、特定のオブジェクト・クラスの要件どおりに存在していません。

一致規則parameterが定義されていません。

サーバーに一致規則が定義されていません。(スキーマ変更)

最大接続数に達しました

LDAPサーバーへの最大同時接続数に達しました。

DNを変更せずにエントリの命名属性を変更しようとしています。

ldapmodifyを使用して命名属性を変更することはできません。cnなどの命名属性は識別名の要素です。

新しい親が見つかりません。

識別名の変更操作で指定した新しい親が存在していません。(ldapmodifydn)

オブジェクトはすでに存在しています。

エントリが重複しています。(ldapaddおよびldapmodifydn)

オブジェクトID parameterはすでに使用されています。

指定したオブジェクト識別子が重複しています。(スキーマ変更)

オブジェクト・クラスparameterはすでに使用されています。

オブジェクト・クラス名が重複しています。(スキーマ変更)

オブジェクト・クラスの属性が不足しています。

この特定のエントリに対するオブジェクト・クラスの属性が不足しています。

OID parameterに構文エラーがあります。

オブジェクト識別子の定義に構文エラーがあります。(スキーマ変更)

エントリ内の属性の1つに重複した値があります。

作成中のエントリで、同じ属性に対して値を2つ入力しました。

parameterでの操作は許可されていません。

このエントリでの操作は許可されていません。(変更、追加および削除)

ディレクトリ・サーバー・エントリでの操作は許可されていません。

ディレクトリ・サーバー・エントリで、この操作を行うことはできません。(削除)

オプション属性parameterが管理ドメインparameterに定義されていません。

未定義の属性を参照している可能性があります。(スキーマ変更)

ディレクトリ内に親のエントリが見つかりません。

親エントリが存在していません。(ldapaddおよびldapmodifydn)

スーパー・オブジェクトparameterが管理ドメインparameterに定義されていません。

スーパー・タイプが、存在していないクラスを参照しています。(スキーマ変更)

スーパー・タイプが未定義です。

スーパー・タイプが存在していません。(スキーマ変更)

スーパー・ユーザーの追加は許可されていません。

スーパーユーザー・エントリを作成できません。(ldapadd)

構文 parameterが未定義です。

構文がサーバーに定義されていません。(スキーマ変更)

RDNで指定された属性または値がエントリ内に存在していません。

相対識別名(RDN)として指定した属性値がエントリ内に存在していません。(ldapadd)

検索範囲が不明です。

LDAPリクエストで指定した検索範囲が認識されません。

このバージョンはサポートされていません

このバージョンのLDAPリクエストは、このサーバーではサポートされていません。

別名に問題があります。

次のいずれかの問題が発生しました。

- 別名を間接参照しましたが、その別名がDIT内のエントリを指し示していません。

- 親が別名である別名エントリを追加しようとしました。

別名の参照解除に問題があります。

アクセス制御上の問題であるため、別名を間接参照できません。

該当するオブジェクトがありません。

検索リクエストに指定されたベース識別名をサーバーで検索できません。

DN構文に誤りがあります。

aliasedObjectNameに指定された値に無効な識別名の構文が含まれている場合に別名エントリを追加または変更すると、ディレクトリ・サーバーがクライアントにこのエラー・メッセージを返します。

不十分なアクセス権限

ユーザーが間接参照されたエントリへのアクセス権限を持っていません。

R.1.4 Oracle Internet Directoryのクラッシュ時のコア・ダンプとスタック・トレースの取得

Oracle Internet Directoryがクラッシュしたときに得られる情報の種類は、インスタンス固有の構成エントリのorclsdumpflag属性を変更して制御できます。

サーバーがクラッシュした場合、次のディレクトリにコア・ファイルが残されます。

ORACLE_INSTANCE/diagnostics/logs/OID

orclsdumpflagが0に設定されている場合、サーバーがクラッシュすると、コア・ダンプに加えてスタック・トレースも残されます。スタック・トレースの場所は次のとおりです。

ORACLE_INSTANCE/diagnostics/logs/OID/compName/oidldapd_stack00_pid.dmp

オペレーティング・システム固有の設定によっては、コア・ダンプまたはスタック・トレースの生成が影響を受ける場合があります。オペレーティング・システムのドキュメントで、次の設定が必要かどうかを確認します。

- コア・ダンプを有効にするためにcoredumpパラメータを設定する必要があります。

- ulimitコマンドで指定されている最大ファイル・サイズが、コア・ダンプに十分な大きさであることが必要です。

- ORACLE_HOME/bin/oidldapdのバイナリ・ファイルのファイル権限でグループによる読取りが許可されている必要があります。次のように入力してグループに読取り権限があることを確認できます。

chmod g+r $ORACLE_HOME/bin/oidldapd

これはルート・ユーザーで行います。

R.1.5 TCP/IPの問題

オペレーティング・システムのTCP/IPの不具合によって、Oracle Internet Directoryサービスに影響が及ぶ場合があります。

R.1.5.1 Windows 2003 Server上でサーバーの可用性をモニタリングするときはTCPベースのモニタリングを使用しない

F5ロード・バランサを使用してOracle Internet Directoryサーバーの可用性をモニタリングする場合は、『Oracle Fusion Middleware高可用性ガイド』のOracleASクラスタ(アイデンティティ管理)用のロード・バランサの構成に関する説明を参照して、LDAPベースまたはHTTPベースのモニタリングを使用するようにロード・バランサを構成します。TCPベースのモニタリングを使用すると、Microsoft Windows 2003 Serverのオペレーティング・システム・バグのため、サービスが使用できなくなることがあります。

R.1.5.2 DaimondCS Port Explorerをインストールしない

システムにDaimondCS Port Explorerがインストールされていると、Oracle Internet Directoryは動作しません。

R.1.6 パスワード・ポリシーに関するトラブルシューティング

この項では、パスワード・ポリシーに関連したエラー・メッセージと問題について説明します。

R.1.6.1 パスワード・ポリシーが適用されない

パスワード・ポリシーが、特定のユーザーまたは一連のユーザーに適用されていません。たとえば、ユーザーは、定義されているパスワード・ポリシーによって許可されていない構文を使用してパスワードをリセットできます。

問題

パスワード・ポリシーの作成のみでは十分でありません。ポリシーによって管理されるサブツリーも指定する必要があります。

解決方法

ポリシーの識別名を指定したpwdPolicysubentry属性を追加し、サブツリーのルートに移入します。

関連項目:
詳細は、第29.1.2項「パスワード・ポリシーの作成および適用に必要な手順」を参照してください。

R.1.6.2 パスワード・ポリシーのエラー・メッセージ

表R-3に、パスワード・ポリシー違反が発生した結果、クライアントに送信されるエラー・メッセージを示します。エラー・コードは、標準のLDAPエラー・コードではありません。このエラー・メッセージは、LDAP結果の追加情報の一部として送信されます。

表R-3 パスワード・ポリシー違反のエラー・メッセージ

エラー番号

例外

コメントまたは解消方法

9000

GSL_PWDEXPIRED_EXCP

ユーザー・パスワードが期限切れです。

9001

GSL_ACCOUNTLOCKED_EXCP

ユーザー・アカウントがロックされています。

9002

GSL_EXPIREWARNING_EXCP

ユーザー・パスワードがpwdexpirewarning秒後に期限切れになります。すぐにパスワードを変更してください。

9003

GSL_PWDMINLENGTH_EXCP

ユーザー・パスワードが必要な文字数に達していません。

9004

GSL_PWDNUMERIC_EXCP

ユーザー・パスワードに必要な数字が含まれていません。

9005

GSL_PWDNULL_EXCP

ユーザー・パスワードがNULLです。これは許可されていません。

9006

GSL_PWDINHISTORY_EXCP

ユーザーの新規パスワードが、履歴に保存されている旧パスワードと同じです。これは認められません(pwdinhistory属性が、履歴に保存されているパスワード数を制御します)。

9007

GSL_PWDILLEGALVALUE_EXCP

入力されたユーザー・パスワードは、orclpwdillegalvaluesで定義されている無効な値ですので、使用できません。

9008

GSL_GRACELOGIN_EXCP

ユーザー・パスワードが期限切れです。ユーザーには、pwdgraceloginlimit猶予ログインが残っているか、猶予ログインが許されるorclpwdgracelogintimelimitの時間(秒)があります。

9012

GSL_PWDALPHA_EXCP

パスワードには、少なくともorclpwdminalphachars英文字を含める必要があります。

9013

GSL_PWDSPECIAL_EXCP

パスワードには、少なくともorclpwdminspecialchars特殊文字を含める必要があります。

9014

GSL_PWDUPPER_EXCP

パスワードには、少なくともorclpwdminuppercase大文字を含める必要があります。

9015

GSL_PWDMAXCHAR_EXCP

パスワードには、orclpwdmaxrptchars繰り返し文字しか含められません。

9016

GSL_PWDLOWER_EXCP

パスワードには、少なくともorclpwdminlowercase小文字を含める必要があります。

9017

GSL_EC_PWDPOLSUBENTINV

指定されたpwdPolicysubentryは無効です。(識別名は、ディレクトリに存在する有効なパスワード・ポリシーのものではありません。)

9018

GSL_EC_PWDPOLINUSE

削除しようとしているpwdPolicyエントリは、現在使用中です。(パスワード・ポリシー自体を削除する前に、パスワード・ポリシーに対する参照を削除する必要があります。)

9019

GSL_EC_PWDPOLOBJ

pwdPolicyエントリの識別名は、変更できない可能性があります。

9020

GSL_PWDMINAGE_EXCP

パスワードは、少なくともpwdminageの秒数が経ってからでないと変更できません。

9032

GSL_EC_GRACE_CONST

orclgracelogintimelimitとpwdgraceloginlimitは、互いに排他的です。どちらもゼロ以外にはできません。

9033

GSL_EC_NOROOTDSEPWDPOL

ルートDSEのpwdpolicysubentry属性は、削除できません。(これは、適用可能なパスワード・ポリシーなしにディレクトリから出てしまうので、許可されません。)

9034

GSL_EC_NOTROCPWDPOL

ルートOracleコンテキストで定義されたパスワード・ポリシーのみが、ルートDSEで適用できます。(これにより、ディレクトリ全体の権限を持つ管理者が指定したポリシーのみが、ディレクトリ全体に適用できることが保証されます。)

9050

GSL_ACCTDISABLED_EXCP

ユーザー・アカウントが使用禁止になっています。

関連項目:
第12章「アカウントおよびパスワードの管理」

R.1.7 ディレクトリのパフォーマンスに関するトラブルシューティング

この項では、一般的なパフォーマンス関連の問題を解決するための簡単な説明を示します。

R.1.7.1 LDAP検索のパフォーマンスが不十分

LDAP検索のパフォーマンスが不十分です。

問題

様々な問題があります。

解決方法

次のことを確認してください。

- ODSユーザーに関連付けられているスキーマがANALYZEDであること

- 複数のフィルタ・オペランドを含む検索の場合は、フィルタの指定順序が、最も特殊な条件から最も一般的な条件の順であることを確認します。たとえば、&(objectclass=person)(uid=john.doe)よりも&(uid=john.doe)(objectclass=person)の方が適切です。

第R.1.7.3項「Oracleデータベース・サーバーのパフォーマンスが不十分」も参照してください。

R.1.7.2 LDAP追加または変更のパフォーマンスが不十分

LDAP追加または変更のパフォーマンスが不十分です。

問題

様々な問題があります。

解決方法

次のことを確認してください。

- データベースに十分な数のREDOログ・ファイルがあること

- データベースのUNDO表領域の大きさが十分であること

- ODSユーザーに関連付けられているスキーマがANALYZEDであること

統計を見積もる際には、OIDデータベース統計収集ツールを使用して、様々なデータベースODSスキーマ・オブジェクトを分析することができます。

第24章「ロギングの管理」で説明したトレース機能とデータベース・トレース・イベント10046は、パフォーマンスの問題を診断する際に役立ちます。

関連項目:
OIDデータベース統計収集ツールの使用方法は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のoidstats.sqlコマンド行ツールのリファレンスを参照してください。
検索を最適化する手順は、『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』の「Oracle Internet Directory」の章を参照してください。

グループ・エントリのパフォーマンスに関する問題の詳細は、http://metalink.oracle.comにあるMy Oracle Support(以前のMetaLink)のNote 243006.1を参照してください。

R.1.7.3 Oracleデータベース・サーバーのパフォーマンスが不十分

問題

Oracleデータベース・サーバーで、LDAP検索操作時に多くのプロセッサ・リソースが使用されています。

解決方法

次のようにします。

1. 次を実行して、プロセッサ使用率の高いLDAP操作を特定します。

oidctl connect=connstr status -diag

このコマンドでLDAP操作と、これに対応して実行されるSQLが表示されます。

2. この種の問合せに対してデータベースを適切にチューニングします。『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』の「Oracle Internet Directory」の章を参照してください。

3. 可能なら、アプリケーションの検索シグネチャを変更します。不可能な場合は、Oracle Internet Directory属性orclinmemfiltprocessをチューニングします。『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』の「Oracle Internet Directory」の章を参照してください。

R.1.7.4 AWRレポートを使用したデータベース・パフォーマンス問題に関するトラブルシューティング

自動ワークロード・リポジトリ(AWR)は、Oracle Databaseに存在する組込みリポジトリです。データベースは、定期的にその重要な統計とワークロード情報のスナップショットを作成し、そのスナップショットをワークロード・リポジトリに格納します。

デフォルトでは、1時間ごとにパフォーマンス・データのスナップショットが自動的に生成され、その統計はリポジトリに8日間保存されます。

データベース・パフォーマンス問題の原因となっているコンポーネントとしてOracle Internet Directoryが疑われる場合、次の項の説明に従って、AWRレポートを使用してさらに問題を調査できます。

- 第R.1.7.4.1項「AWRレポートの生成」

- 第R.1.7.4.2項「AWRレポートの分析」

関連項目:
『Oracle Databaseパフォーマンス・チューニング・ガイド』の「自動パフォーマンス統計」の章

R.1.7.4.1 AWRレポートの生成

特定のAWRレポートを生成するには、awrrpt.sql SQLスクリプトを実行します。

1. sysdbaユーザーとしてOracle Databaseに接続します。次に例を示します。

sqlplus /sys/sysdba-password@oiddb as sysdba

2. SQLプロンプトでawrrpt.slqスクリプトを実行してAWRレポートを生成します。次に例を示します。

SQL> $ORACLE_HOME/rdbms/admin/awrrpt.sql

3. プロンプトが表示されたら、レポート用に次の情報を指定します。

- HTMLまたはテキスト形式。デフォルトの形式はHTMLです。

- スナップショットIDをリストする日数。
この値は、パフォーマンス問題が発生したときの時間間隔(日単位)を示します。たとえば、問題が今日発生した場合、1を入力します。問題が昨日発生した場合、2を入力します。

awrrpt.sqlスクリプトは、選択された日数のスナップショットIDをリストします。各スナップショットには、一意のスナップショットIDが割り当てられます。

- ワークロード・リポジトリ・レポートの最初と最後のスナップショットID。
パフォーマンス問題が発生したときの時間を指定します。この時間間隔に基づいて、最初と最後のスナップショットIDを指定して、AWRデータを抽出する必要のあるスナップショットの範囲を定義します。次に例を示します。

Enter value for begin_snap: 110
Enter value for end_snap: 120

- レポート名。デフォルトのレポート名を受け入れるか、新しい名前を入力します。

データベースによって、sqlplusコマンドを実行したディレクトリ内にAWRレポートが生成されます。

4. 次の項の説明に従って、パフォーマンス問題の原因となっている問題の特定を試みるため、AWRレポートを分析します。

R.1.7.4.2 AWRレポートの分析

AWRレポートを分析する手順は、次のとおりです。

1. 「Top 5 Timed Foreground Events」表を確認します。この表には、パフォーマンス問題の原因となる可能性があるイベントの情報が示されます。「Waits」および「Avg wait (ms)」列を確認し、平均待機時間が最大のイベントに注意します。

2. 「SQL Statistics」セクションで、「SQL ordered by Elapsed Time」表を確認します。

1. 「Elapsed Time per Exec (s)」列の値を確認します。
通常の状況では、問合せは1秒未満で実行される必要があります(表ではミリ秒単位で示されます)。問合せの実行に1秒以上かかっている場合、次の手順で調査する必要があります。

2. 最大の「Elapsed Time per Exec (s)」が表示されているイベントについて、「SQL Id」列の下の値をクリックし、実行されたSQL問合せを表示します。
このSQL問合せに"attrvalue = 'referral'"などのフィールドが含まれる場合、1つのOracle Internet Directoryインスタンスのみが実行され、他のOracle Internet Directoryプロセスに対する参照が存在しない環境では、問合せの実行をスキップできます。

環境内に参照エントリが存在しない場合、次のように前の問合せの実行を回避することで、パフォーマンスを向上できます。

1. "cn=dsaconfig,cn=configsets,cn=oracle internet directory"で、orclskiprefinsql属性を1に設定し、検索で参照をスキップします。
詳細は、第9.1.4項「DSA構成エントリの属性」を参照してください。

2. Oracle Internet Directoryを再起動して、変更を有効にします。

R.1.8 ポート構成に関するトラブルシューティング

Oracle Internet DirectoryディスパッチャがSSLおよび非SSL接続に使用するポートは、次のようにして特定できます。

- Oracle Enterprise Manager Fusion Middleware ControlでOIDメニューから「ポートの使用状況」を選択します。

- コマンド行から次を実行します。

ORACLE_INSTANCE/bin/opmnctl status -l

- コマンド行から次を実行します。

oidctl connect=oiddb status

R.1.9 opmnctlを使用したOracle Internet Directoryコンポーネントの作成に関するトラブルシューティング

問題

コマンドopmnctl createcomponentが失敗し、ファイルORACLE_INSTANCE/diagnostics/logs/OPMN/opmn/provision.logに次のエラーが表示されます。

INFO: $ORACLE_INSTANCE/config/tnsnames_copy.ora file does not exist

解決方法

次の条件を満たしていることを確認します。

- ファイルORACLE_INSTANCE/config/tnsnames_copy.oraが存在しています。

- OIDDB connectStringがORACLE_INSTANCE/config/tnsnames.oraにあります。

- ORACLE_INSTANCE/config/OPMN/opmn/opmn.xmlのOIDスニペットのconnectStringが、ORACLE_INSTANCE/config/tnsnames.oraのものと同じです。デフォルトはOIDDBです。

次に、opmnctl createcomponentを再試行します。

R.1.10 Oracle Internet Directoryの起動に関するトラブルシューティング

この項では、Oracle Internet Directoryの起動時に起こる可能性のある問題について説明します。

R.1.10.1 Oracle Internet Directoryが停止している

問題

Oracle Enterprise Manager Fusion Middleware ControlでOracle Internet Directoryが停止していると表示されます。コマンド

opmnctl status

で、oidmonとすべてのoidldapdプロセスが停止していると示されます。

解決方法

OPMNログORACLE_HOME/opmn/logs/opmn.logで、oidmonが起動しない理由を確認します。

問題

Oracle Enterprise Manager Fusion Middleware ControlでOracle Internet Directoryが停止していると表示されます。コマンド

opmnctl status

で、oidmonは稼働しているがoidldapdプロセスは停止していると示されます。

解決方法

次のログを次に示す順に確認します。

1. oidmonログORACLE_INSTANCE/diagnostics/logs/OID/componentName/oidmon-0000.logには、oidmonがoidldapdプロセスを起動できない原因の詳細が含まれています。最も一般的な問題は次のとおりです。

- Oracle Databaseに接続できない: Oracleデータベースとリスナーが稼働していることを確認します。

- 2つのノードの時差が250秒より大きい: システム時間を調整します。

- oidmonはoidldapdプロセスの起動を再試行し続けますが、起動に失敗します。デバッグするには、手順2を参照してください。

2. Oracle Internet Directoryディスパッチャ・ログORACLE_INSTANCE/diagnostics/logs/OID/componentName/oidldapd01-0000.logには、oidldapdサーバー・プロセスの起動に失敗した原因に関する情報が含まれています。最も一般的な原因は次のとおりです。

- Oracle Internet Directory用に構成されたポートが空いていない: 次を実行します。

netstat -an | grep oidPort

ポートが空くかどうかを確認します。

- UNIXまたはLinuxシステムでは、Oracle Internet Directoryは1024未満のポート番号でリスニングするよう構成されています。また、実行可能バイナリ・ファイルORACLE_HOME/bin/oidldapdは、rootに所有されておらず、setuidビットがセットされていません。

- oidldapdディスパッチャはoidldapdサーバー・プロセスの生成を続けますが、稼働に失敗します。この場合、UNIXまたはLinuxのpsまたはWindowsのタスク・マネージャを使用すると、1つのoidldapdディスパッチャ・プロセスが稼働していることがわかる場合があります。デバッグするには、手順3を参照してください。

3. Oracle Internet Directoryサーバー・ログORACLE_INSTANCE/diagnostics/logs/OID/componentName/oidldapd01sPID-0000.logには、サーバー・プロセスの稼働に失敗した原因に関する情報が含まれています。一般的な問題は次のとおりです。

- Oracle Database接続プールが作成できない: Oracle DatabaseのPROCESSESパラメータを確認し、必要に応じて値を増やします。

- Oracle Internet DirectoryがSSLウォレット・ファイルを使用するよう構成されていますが、ファイルにアクセスできません。

R.1.10.2 Oracle Internet Directoryが読取り専用

問題

Oracle Internet Directoryサーバーが読取り専用モードで起動します。

解決方法

これは、通常Oracle Internet Directoryサーバーが、間違ったスキーマに対して起動されたことを表します。確認するには、次の2つのコマンドを入力します。

oidldapd -v

ldapsearch -p oidPort -D cn=orcladmin -q -b "" -s base "objectclass=*" Orcldirectoryversion

これらのコマンドで異なるバージョンが表示される場合、サーバーは読取り専用モードで起動します。

R.1.11 クライアント接続の中断が原因のOracle Internet Directoryエラー

次のエラーが戻されます。

ServerDispatcher:  sgslufread: Hard error on read, OS error = 110

問題

このエラーは、LDAPクライアントの接続が突然切断されたことを示しています。考えられる原因は次のとおりです。

- クライアント・マシンがクラッシュしたか、またはクライアント・プログラムがバインド解除や中止を実行せずに接続を終了した。

- ネットワークのコンポーネント(ロード・バランサやファイアウォールなど)が、アイドル接続タイムアウトなどの構成されたタイムアウト設定が原因で接続を切断した。

- ロード・バランサが、LDAP pingのかわりにTCP pingを発行した。

解決方法

このエラーは、サーバー外部の状況が原因です。必要な場合は、ネットワーク管理者に報告してください。

R.1.12 ディレクトリ・サーバーの起動、停止および再起動に関するトラブルシューティング

ディレクトリ・サーバーの起動および停止に関するトラブルシューティングを行うには、関係する各ツールの目的、すべてのツールがどのように連携するか、およびサーバーの起動および停止のプロセス全般について知っておく必要があります。

関連項目:
『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』の「Oracle Internet Directory」の章

R.1.12.1 ディレクトリ・サーバー・インスタンスを起動、停止および再起動するためのツールについて

次のように入力して、ディレクトリ・サーバー・インスタンスを起動します。

opmnctl startproc process-type=OID
opmnctl stopproc process-type=OID

OIDCTL OIDCTLを実行すると、OIDCTLはユーザーODSとしてデータベースに接続します。コマンドで使用するオプションに応じて、ODS.ODS_PROCESS_STATUS_STATUSという表に行を挿入するか、この表の行を更新します。STARTオプションを使用すると、行が挿入されます。STOPまたはRESTARTオプションを使用すると、行が更新されます。

ODS.ODS_PROCESS_STATUS表には次の情報が含まれています。

- instance: 一意のインスタンス番号。0から1000の任意の値です。

- pid: プロセス識別子。プロセスが起動されると、OIDMONによって更新されます。

- state: リクエストされた操作のタイプ。
stateの値は次のいずれかです。

- 0=停止

- 1=起動

- 2=実行中

- 3=再起動

- 4=シャットダウン

- 5=フェイルオーバー済

注意:
OPMNがディレクトリ・サーバーを停止した場合、stateの値は当初4(シャットダウン)です。ただし、OPMNが再度ディレクトリ・サーバーを起動すると、stateの値は2(実行中)になります。

OIDMON ディレクトリ・サーバー・インスタンスを起動、停止または再起動するには、OIDMONが実行中であることが必要です。このデーモンは、ODS.ODS_PROCESS_STATUS表のstate列の値を指定の間隔でチェックします。

state=0の行が見つかると、pidを読み取ってプロセスを停止します。

state=1またはstate=4の行が見つかると、新規プロセスを起動し、pid列を新しいプロセス識別子で更新します。

state=2の行が見つかると、pidを読み取り、そのpidを持つプロセスが実行中であることを検証します。実行中でない場合は、新規プロセスを起動し、pid列を新しいプロセス識別子で更新します。

state=3の行が見つかると、pidを読み取ってプロセスを停止し、新規プロセスを起動して、それに合せてpidを更新します。

これが失敗する場合、別のノードにリクエストをプッシュします。

つまり、OIDCTLは、ODS.ODS_PROCESS_STATUS表の行に対して状態情報の挿入および更新を行います。OIDMONは、その情報を読み取り、指定されたタスクを実行します。

ディレクトリ・サーバーの起動、停止および再起動に関与するプロセスについて

ディレクトリ・サーバーの起動、停止および再起動には、いくつかのプロセスが関与します。OIDMONはその1つです。UNIXでは、OIDMONをoidmonと呼びます。Microsoft Windows環境では、oidmon.exeと呼びます。

OIDMONは、インスタンスを開始するため、前出の項で説明されているinstance列の一意の番号を確認します。次に、Oracle Net Servicesのリスナー・プロセスとは異なる別のプロセス、リスナー/ディスパッチャを開始します。この新しいプロセスの識別子は、pid列に格納されます。

一方、リスナー/ディスパッチャは、構成設定エントリに定義されたいくつかのサーバー・プロセスを起動します。これらのサーバー・プロセスは、OIDMONではなくリスナー/ディスパッチャによって制御されます。いずれかのプロセスが失敗すると、リスナー/ディスパッチャによって自動的に再起動されます。

リスナー/ディスパッチャとサーバー・プロセスが組み合されて、ディレクトリ・サーバー・インスタンスとなります。UNIXでは、このディレクトリ・サーバー・インスタンスをoidldapdと呼びます。Microsoft Windowsでは、oidldapd.exeと呼びます。

つまり、少なくとも3つのプロセスがあり、1つはOIDMON用で、少なくとも2つはディレクトリ・サーバー用です。すべてのプロセスが実行中の場合は、UNIXコンピュータに次のように表示されます。

% ps -ef|grep oid
root 12387 12381 0 Mar 28 ? 0:05 oidldapd -i 1 -conf 0 key=811436710
root 12381 1 0 Mar 28 ? 0:10 oidmon start
root 13297 1 0 Mar 28 ? 0:14 oidldapd

サーバー情報を取得する別の方法は、次を実行することです。

oidctl connect=oiddb status.

R.1.12.2 ディレクトリ・サーバーの起動、停止および再起動に関する問題

この項では、ディレクトリ・サーバーを起動、停止または再起動するときに発生する場合がある問題について説明します。

R.1.12.2.1 OIDCTLまたはOIDMONの障害

OIDCTLまたはOIDMONが正常に動作しない場合は、いくつかの理由が考えられます。

問題

構文が正しくありません。

解決方法

『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のOracle Internet Directory管理ツールに関する章を参照して、正しい構文を使用していることを確認します。OIDCTLを使用する場合の接続オプションの適切な値は、TNS別名(接続文字列)であり、ホスト名などの他の値ではありません。http://metalink.oracle.comにあるMy Oracle Support(以前のMetaLink)のNote 155790.1を参照してください。

問題

Oracle Internet Directoryで指定されたデータベースが稼働していません。

Oracle Net Servicesの構成が正しくありません。

解決方法

Oracle Internet Directoryで指定されたデータベースとOracle Net Servicesのコンポーネントが正しく構成され、稼働していることを確認します。そのためには、OIDCTLと同じORACLE_HOMEにインストールされているSQL*Plusを使用して、データベースに接続できるかどうかを確認します。ODS/ods_password@tns_aliasとしてログインします(tns_aliasは、OIDCTLのconnectオプションで使用する場合と同じです)。http://metalink.oracle.comにあるMy Oracle Support(以前のMetaLink)のNote 155790.1を参照してください。

問題

oidldapdファイルがありません。

解決方法

$ORACLE_INSTANCE/diagnostics/logs/OID/componentName/oidmon-XXXX.logを参照してください。「No such file or directory」というメッセージを探してください。この問題を修正するには、実行可能ファイルを置き換えます。

問題

oidldapd/oiddispd実行可能ファイルの権限が不適切です。

解決方法

パート1

この解決方法は、Oracle Internet Directory 11g (11.1.1.7)より前のリリースに適用されます。

「Exec of OIDLDAPD failed with error 13」というメッセージを探します。UNIXの場合、$ORACLE_HOME/bin/oidldapdファイルには次の権限が必要です。

-rws--x---  1 root   dba       1691802 Jan 20 10:30 oidldapd

権限が正しくない場合は、ルートとして次のように入力します。

cd $ORACLE_HOME/bin
chown root:dba oidldapd
chmod 0710 oidldapd
chmod u+s oidldapd

パート2

この解決方法は、Oracle Internet Directory 11g (11.1.1.7)リリース以上に適用されます。

「Exec of OIDDISPD failed with error 13」というメッセージを探します。UNIXの場合、$ORACLE_HOME/bin/oiddispdファイルには次の権限が必要です。

-rws--x---  1 root   dba       1691802 Jan 20 10:30 oiddispd

権限が正しくない場合、次のいずれかのオプションを実行できます。

A) rootとして次のコマンドを実行します。

cd $ORACLE_HOME
oidRoot.sh

または

B) rootとして次のコマンドを入力します。

cd $ORACLE_HOME/bin
chown root:dba oiddispd
chmod 0710 oiddispd
chmod u+s oiddispd

前の解決方法を適用した後、次のコマンドを使用して、所有権と権限が正しく設定されているかどうかを確認することをお薦めします。

$ORACLE_HOME/bin/ls -al oiddispd

問題

権限が不十分なユーザーとして実行しています。

解決方法

これが問題になっていることを確認するには、ORACLE_INSTANCE/diagnostics/logs/ OID/componentName/oidmon-XXXXX.logを参照します。

「Permission denied」または「Open Wallet failed」というメッセージを探してください。これは、rootまたはdbaグループのユーザーとして実行していない場合に発生します。この問題を修正するには、正しいユーザーとして再試行します。

問題

ポートが使用中です。

解決方法

次を参照してください。

ORACLE_INSTANCE/diagnostics/logs/ OID/componentName/oidldapd00sPID-XXXX.log

メッセージ「バインド失敗...」を確認します。これは、oidldapdでリスニングするよう構成されているポートが他のプロセスによって使用中であることを示しています。ポートを使用しているプロセスを確認するには、次のように入力します。

netstat -a | grep portNum

必要に応じて、別のポートを使用するようにもう一方のプロセスを再構成するか、configsetを追加して別のポートをリスニングするようにoidladapdを構成します。デフォルトでは、oidladapdが2つのポート(SSLポートと非SSLポート)でリスニングすることに注意してください。

問題

クラスタ構成またはOracle Application Server Cluster(Identity Management)構成において、OIDMONは、ローカル・ノードでサーバーを起動できない場合に、クラスタ内の別のノードにそのサーバーをプッシュします。

解決方法

oidmon.logを参照してください。「gslsgfrPushServer: Could not start serveron NodeA, trying to start on nodeNodeB」というメッセージを探してください。この問題を修正するには、まずOIDMONがローカル・ノードでサーバーを起動できない理由を特定する必要があります。

問題

Oracle Net Servicesまたはデータベース自体で問題が発生している可能性があります。

解決方法

oidmon.log、oidldapdxx.log(xxはサーバー・インスタンス番号)を確認します。

ODS.ODS_PROCESS_STATUSの行が欠落しています。

問題

クラスタ構成またはOracle Application Server Cluster(Identity Management)構成において、OIDMONが両方のノードでoidldapdを正常に起動しましたが、タイムスタンプの相違によりフェイルオーバーを開始しました。

解決方法

トレース・ファイルoidldapdxx.log(xxはインスタンス番号)およびoidldapdxxsyy.log(xxはインスタンス番号で、yyはプロセス識別子)を確認します。トレース・ファイルに役立つ情報やMy Oracle Support(以前のMetaLink)ドキュメントへのポインタがない場合は、(1)ディレクトリ・サーバーのプロセスを停止し、(2)古いトレース・ファイルを削除または名前変更して、(3)OIDMONおよびディレクトリ・サーバーを最大デバッグ・レベルの11744051で起動します。トレース・ファイルを取得するには、サーバーを単に再起動するのではなく、最初に停止してから起動する必要があります。新しいトレース・ファイルを確認し、必要に応じて、Oracle Support ServicesによってiTARをロギングし、トレース・ファイルをiTARにアップロードします。http://metalink.oracle.comにあるMy Oracle Support(以前のMetaLink)のNote 155790.1を参照してください。

関連項目:
フェイルオーバーの詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のoidctlコマンド行ツールのリファレンスを参照してください。

R.1.13 Oracle Internet Directoryレプリケーションに関するトラブルシューティング

この項では、ディレクトリ・レプリケーションの問題について説明します。

レプリケーションの問題を調査するときは、必ずログ・ファイルの内容を確認してください。ログ・ファイルは、ORACLE_INSTANCE/diagnostics/logs/OID/componentName/oidrepld-XXXX.log、oidldapd00-XXXX.logおよびORACLE_INSTANCE/diagnostics/logs/OID/componentName/oidldapd00sPID-XXXX.log(PIDはサーバー・プロセス識別子で、XXXXは0000からorclmaxlogfiles configuredの番号)です。

レプリケーション・サーバーは複数のデバッグ・レベルをサポートしています。レプリケーションのデバッグを有効にするには、ldapmodifyまたはFusion Middleware Controlの「共有プロパティ」、「レプリケーション」タブを使用してレプリケーション構成セットのorcldebuglevelを変更します。

注意:
デバッグをオンにすると、レプリケーションのパフォーマンスに影響が出ます。

関連項目:
詳細は、第42章「レプリケーション構成属性の管理」を参照してください。

ブートストラップの失敗

レプリケーションのブートストラップ・プロセス中に、参照整合性を無効にします。参照整合性が有効になると、ブートストラップは失敗します。

R.1.13.1 レプリケーション・サーバーが起動しない

レプリケーション・サーバーを起動できない場合は、いくつかの問題があります。

問題

oidctlの構文に誤りがあります。

解決方法

次の構文を使用してレプリケーション・サーバーを起動します。

oidctl server=oidrepld connect=connect string instance=instance_number \
flags="-h host -p port"

問題

レプリケーション・サーバーを起動するときにコマンド行で指定したホストおよびポートでOracle Internet Directoryが稼働していません。そのため、ターゲットOracle Internet Directoryへの匿名ユーザーによるバインドに失敗しました。

解決方法

指定したホストおよびポートでターゲットOracle Internet Directoryが稼働していることを確認します。

問題

レプリケーション・サーバーが、レプリカ・エントリのorclreplicaprimaryurlまたはorclreplicasecondaryurl属性で指定したホストおよびポートへのバインドを試みていますが、Oracle Internet Directoryは別のホストまたはポートで稼働しています。

解決方法

Oracle Internet Directoryを別のホストまたはポートで実行する場合は、次の手順で、レプリカ・エントリのorclreplicasecondaryurl属性に新しい情報を追加します。

1. 変更ファイルmod.ldifを準備します。たとえば、ホストをmy.us.example.comに、ポートを4444に変更する場合は、次のように指定します。

dn: orclreplicaid=replica_ID, cn=replication configuration
changetype: modify
add: orclreplicasecondaryurl
orclreplicasecondaryurl: ldap://my.us.example.com:4444/

2. 次のコマンドを実行します。

ldapmodify -h host -p port -f mod.ldif

問題

レプリケーション・ウォレットORACLE_INSTANCE/OID/admin/oidpwdrORACLE_SIDのReplBind資格証明が破損しているか無効です。つまり、ウォレットに格納されているパスワードと、ディレクトリに格納されているパスワードが同じではないか、ウォレットが存在しません。そのため、レプリケーションのバインドに失敗し、レプリケーション・サーバーがエラーで終了しました。

oidrepldXX.logファイルに、次のようなメッセージが記録される場合があります。

2005/07/21:11:13:28 * gslrcfdReadReplDnPswd:Error reading repl passwd
2005/07/21:11:13:28 * gslrcfcReadReplConfig:Error found.
2005/07/21:11:13:28 * Failed to read replication configuration information.

解決方法

remtoolを使用して、レプリケーション・ウォレット内のレプリケーション・バインドの資格証明を修正するか、Oracle Internet Directoryとレプリケーション・ウォレットを同期させます。

- remtool -pchgpwdは、レプリカのレプリケーション識別名のパスワードを変更します。ディレクトリに格納されている現在のレプリケーション識別名パスワードを知っており、ディレクトリに格納されているパスワードとウォレット内の証明を両方変更する場合は、このオプションを使用します。

- remtool -presetpwdは、レプリカのレプリケーション識別名のパスワードをリセットします。ディレクトリに格納されている現在のレプリケーション識別名パスワードを知っており、ディレクトリに格納されているパスワードとウォレット内の証明を両方変更する場合は、このオプションを使用します。

- remtool -pchgwalpwdは、レプリカのレプリケーション識別名のパスワードをウォレット内でのみ変更します。ディレクトリに格納されているレプリケーション識別名のパスワードは知っているが、ウォレットのパスワードが正しいかどうか不明な場合、またはウォレット・ファイルを作成する必要がある場合に、このオプションを使用してください。

これらすべてのオプションは、ウォレットがまだ存在しない場合に新しいウォレットを作成します。

関連項目:

- remtoolの使用の詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のremtoolコマンド行ツールのリファレンスを参照してください。

- oidpasswdの使用の詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のoidpasswdコマンド行ツールのリファレンスを参照してください。

問題

レプリケーション・サーバーは、一方向認証または双方向認証用に構成されているSSLポートをバインドしようとしています。

解決方法

非SSLポートまたは認証なしで構成されているSSLポートを使用するようレプリケーション・サーバーを構成します。別のOracle Internet Directoryサーバー・インスタンスをレプリケーション用に使用できます。

関連項目:
第40.1.8.2項「Secure Sockets Layer(SSL)とOracle Internet Directoryレプリケーション」

R.1.13.2 レプリケーションのブートストラップに関するエラー

レプリケーションのブートストラップで、エラーが発生する場合があります。

問題

一部のネーミング・コンテキストのブートストラップに失敗しました。

解決方法

ブートストラップに失敗したネーミング・コンテキストを特定し、oidcmprecツールを使用して調整します。その後、コンシューマのレプリカ状態をオンライン・モードに設定して、レプリケーションを再開します。

問題

様々な原因。

解決方法

ブートストラップに失敗した原因を特定し、修正します。その後、コンシューマのレプリカ状態をブートストラップ・モードに設定して、ブートストラップを再開します。

解決方法

エラーの正確な原因を特定するには、ログ・ファイルoidldapdxx.logを調べます。次の例に示すようなエラー・メッセージを探します。

2004/09/14:12:57:23 * Starting OIDREPLD against dlsun1418:4444...
2004/09/14:12:57:25 * Starting scheduler...
2004/09/14:12:57:26 * Start to BootStrap from supplier=dlsun1418_replica to consumer=dlsun1418_replica2
2004/09/14:12:57:27 * gslrbssSyncDIT:Replicating namingcontext=cn=oraclecontext ......
2004/09/14:12:58:21 * gslrbssSyncDIT:Sync done successfully for namingctx: cn=oraclecontext, 222 entries matched
2004/09/14:12:58:21 * gslrbssSyncDIT:Replicating namingcontext=cn=joe smith ......
2004/09/14:12:58:23 * BootStrap failure when adding DN=cn=Joe Smith,
server=dlsun1418_replica2,err=Constraint violation.
2004/09/14:12:58:23 * gslrbssSyncDIT:Sync failed for namingctx: cn=joe smith, only 1 entries retrieved
2004/09/14:12:58:23 * gslrbssSyncDIT:Replicating namingcontext=cn=oracleschemaversion ......
2004/09/14:12:58:25 * gslrbssSyncDIT:Sync done successfully for namingctx: cn=oracleschemaversion, 10 entries matched
2004/09/14:12:58:51 * gslrbsbBootStrap: Failure occurred when bootstrapping 1 out of 3 namingcontext(s) from the supplier

ブートストラップに失敗した原因を特定し、修正します。問題の原因となったネーミング・コンテキストを特定し、oidcmprecを使用してネーミング・コンテキストの比較および調整を行うことができます。問題が解決したら、Oracle Internet Directoryレプリケーション・サーバーを起動して、再度ブートストラップを開始します。

問題

ブートストラップ中にOracle Internet Directoryサーバーが停止しました。

解決方法

サプライヤ側のOracle Internet Directoryサーバーとコンシューマ側のOracle Internet Directoryサーバーが、レプリケーションのブートストラップ中に稼働していることを確認します。

問題

制約違反のため、ブートストラップ対象のエントリの一部をコンシューマ側で適用できません。

解決方法

レプリケーションのブートストラップを開始する前に、コンシューマ側のOracle Internet Directoryスキーマがサプライヤ側のOracle Internet Directoryスキーマと同期していることを確認します。LDAPレプリカを追加する場合、remtoolによりコンシューマ・レプリカのOracle Internet Directoryスキーマはサプライヤ・レプリカのOracle Internet Directoryスキーマと必ず同期します。

問題

ブートストラップ中にレプリケーションの不適切なフィルタ処理が行われました。ブートストラップ中に1つ以上の属性をレプリケーションから除外できます。ただし、エントリの必須属性を除外する構成を行った場合、objectclass違反のため、そのエントリをコンシューマ側で適用できません。

解決方法

第40章「レプリケーションの設定」のレプリケーション・ネーミング・コンテキスト構成規則に従って、レプリケーションのフィルタ処理を正しく構成します。

LDAPレプリケーションをデバッグする場合、LDAPレプリカの状態をよく理解しておく必要があります。LDAPベースのレプリケーションが構成されている場合、レプリケーション・サーバーは、起動後、ローカル・レプリカからレプリカの状態を読み取ります。レプリケーション・サーバーの動作はローカル・レプリカの状態によって異なります。LDAPレプリケーション・エラーはoidldapdxx.logに記録されます。

関連項目:
第D.4項「LDAPのレプリカ状態」

問題

エントリ数が5000を超えるネーミング・コンテキストのブートストラップに失敗した後、そのレプリケーション・サーバーを再起動すると、次のようなエラー・メッセージがログ・ファイルoidrepld00.logに出力される場合があります。

2005/04/05:13:21:55 * gslrbssSyncDIT:Replicating namingcontext=dc=com ......
2005/04/05:15:36:09 * gslrbssSyncDIT:Subtree delete on dc=com failed.
Error=DSA is unwilling to perform
2005/04/05:15:36:09 * gslrbssSyncDIT:Sync failed for namingctx: dc=com, only
0 entries retrieved

レプリケーション・サーバーは、ブートストラップ操作時に2つの手順を実行します。まず、コンシューマ側で、ブートストラップが必要なネーミング・コンテキストを削除します。次に、それらのネーミング・コンテキストに属するエントリをサプライヤからコンシューマへコピーします。数千のエントリを含むネーミング・コンテキストをレプリケーション・サーバーが削除すると、非常に大規模なトランザクションが発生します。この大規模なトランザクションに対応するには、UNDO表領域として十分な領域を確保する必要があります。データベースのUNDO表領域の領域が不十分な場合は、ORA-30036エラーが発生します。

解決方法

UNDO表領域の領域を追加するようデータベース管理者に依頼します。または、bulkdeleteツールを使用して必要なネーミング・コンテキストを削除してから、レプリケーション・サーバーを起動します。

R.1.13.3 変更がレプリケートされない

変更内容が別のノードにレプリケートされません。

問題

レプリケーション・サーバーの表領域が不足しています。

解決方法

サーバー・ログで、次のメッセージを探してください。

OCI Error ORA-1653 : ORA-01653: unable to extend table ODS.ASR_CHG_LOG by 8192 in tablespace OLTS_DEFAULT

表領域を拡張し、表領域が増大し続けている原因を調べます。

問題

ターゲットのOracle Internet Directoryサーバーが停止しています。

解決方法

ターゲットのOracle Internet Directoryサーバーを再起動します。

問題

様々な原因

解決方法

レプリケーション・サーバーが、マルチマスター・レプリケーションのすべてのノード、および単一マスター・レプリケーションまたはファンアウト・レプリケーションのコンシューマ・ノードで起動していることを確認します。

Oracle Databaseアドバンスト・レプリケーション・ベースのマルチマスター・レプリケーションでは、remtoolを使用して問題を診断し、修正します。

- remtool -asrverifyは、DRGの設定が正しいかどうかを検証し、問題を報告します。

- remtool -asrrectifyは、DRGの設定が正しいかどうかを検証し、問題を報告して、問題の修正を試みます。

レプリケーション・ログおよびLDAPログにエラー・メッセージが記録されていないかどうかチェックし、調査が終わったら、エラーの原因を修正します。

関連項目:
remtoolの使用の詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のremtoolコマンド行ツールのリファレンスを参照してください。

R.1.13.4 レプリケーション操作の停止

問題

レプリカ間でデータがレプリケートされません。OID管理者操作キューのエントリがいずれかのノードに適用された後、実行中のレプリケーション設定作業が停止してしまうことがあります。新規レプリカの追加や削除を行うと問題や障害が発生することもあります。

問題

様々な原因

解決方法

http://metalink.oracle.comにあるMy Oracle Support(以前のMetaLink)で次のNoteを参照してください。

Note 171693.1「Resolving Conflicts」

Note 122039.1「Troubleshooting Basics for Advanced Replication」

Note 213910.1「Debugging OID Replication when ASR_CHG_LOG Never Gets Populated」

検索ボックスにreplicationなどの語を入力して、Notesを検索できます。

R.1.14 変更ログのガベージ・コレクションに関するトラブルシューティング

レプリケーションとOracle Directory Integration Platformはいずれも変更ログを使用して、サプライヤ・ディレクトリの情報をコンシューマ・ディレクトリに伝達します。変更ログはすべてods_chg_logという表に格納されます。また、レプリケーション変更ログはasr_chg_logに格納されます。

この項では、変更ログのガベージ・コレクションの際に発生する可能性のある問題について説明します。

問題

ガベージ・コレクションが機能しておらず、Oracle Internet DirectoryがOracle Database 11.2.0.1を使用しています。

解決方法

11.2.0.1.3 PSUをデータベースに適用します。

問題

レプリケーションの問題のため、変更ログはパージされません。たとえば、レプリケーション・サーバーが数日間停止した場合、レプリケーションのリカバリで必要になるので、レプリケーション変更ログはパージされません。

解決方法

レプリケーションの問題を解決します。「Oracle Internet Directoryレプリケーションに関するトラブルシューティング」を参照してください。

問題

属性orclpurgetargetageの設定が高過ぎ、サブスクライバ・プロファイルのorclLastAppliedChangeNumberを更新していない、有効化されているが、アクティブではない変更ログ・サブスクライバが1つ以上あります。変更番号ベースのパージはまだコンシュームされていない変更ログをパージせず、時間ベースのパージは変更ログが十分に古くないためパージしません。

解決方法

属性orclpurgetargetageの値を小さくして、変更ログがより早くパージされるようにしてください。

解決方法

非アクティブな変更ログ・サブスクライバを無効にして、変更ログ数ベースで変更ログがパージされるようにします。有効化されているが、アクティブではないサブスクライバ・プロファイルを探すには、次のように入力して、すべてのサブスクライバ・プロファイルのorclLastAppliedChangeNumberを調べます。

ldapsearch -v -p port -h host -D cn=orcladmin -q \
-b "cn=changelog subscriber,cn=oracle internet directory" \
-s sub "objectclass=orclchangesubscriber" \
orcllastappliedchangenumber orclsubscriberdisable

orclSubscriberDisabledがゼロで、orclLastAppliedChangeNumberの値がまったく変化していないエントリを探してください。そのようなエントリが存在し、変更ログのガベージ・コレクタのorclpurgetargetageがゼロ以上の場合は、orclpurgetargetageの値を削除します。orclpurgetargetageが定義されていない場合、またはゼロより小さい場合、別のサブスクライバがorclLastAppliedChangeNumberを更新していなくても、ガベージ・コレクタはレプリケーション・サーバーによって適用された変更をパージします。

関連項目:
「変更ログのパージ」。

R.1.15 動的パスワード・ベリファイアに関するトラブルシューティング

表R-4に、動的パスワード・ベリファイアのエラー・メッセージとその説明を示します。

表R-4 動的パスワード・ベリファイアのエラー・メッセージ

エラー・コード

説明

9022

ユーザー・エントリに可逆暗号化パスワードがありません。

9023

LDAPリクエスト制御で指定した暗号タイプはサポートされていません。

9024

LDAPリクエスト制御にusernameパラメータがありません。

ディレクトリがベリファイアを比較でき、比較の結果がFALSEの場合、ディレクトリは標準エラーLDAP_COMPARE_FALSEをクライアントに送信します。同様に、認証中のユーザーがディレクトリ・エントリを持たない場合、ディレクトリは標準エラーLDAP_NO_SUCH_OBJECTを送信します。

関連項目:
『Oracle Fusion Middleware Oracle Identity Managementリファレンス』の「パスワード・ベリファイアのスキーマ要素」の章

R.1.16 Oracle Internet Directoryパスワード・ウォレットに関するトラブルシューティング

Oracle Internet Directoryサーバーには、oidpwdlldap1とoidpwdrSIDの2つのパスワード・ウォレットがあります。

oidpwdlldap1ファイルには、ODSユーザーの識別名およびパスワードが暗号化形式で格納されます。Oracle Internet Directoryサーバーは、起動時に、資格証明を使用してバックエンド・データベースに接続します。

R.1.16.1 Oracle Internet Directoryサーバーが起動しない

oidctlまたはopmnがOracle Internet Directoryサーバー・インスタンスの起動に失敗します。

問題

oidpwdlldap1ウォレットに格納されているパスワードが、バックエンド・データベースのODSパスワードと同期していません。

解決方法

sqlplusコマンドを使用して、データベースへの接続を再試行します。

sqlplus ods /ods_password@connect_string

接続に成功した場合は、oidpasswdツールを使用して正しいパスワードを持つ新規ウォレットを作成することで、ウォレット内のパスワードをODSパスワードと同期させます。たとえば、ORACLE_INSTANCEが設定されているのを確認してから、次を入力します。

>> oidpasswd connect=connect_string create_wallet=true

接続に失敗した場合は、データベース管理者としてバックエンド・データベースにログインし、sqlコマンドを使用してODSパスワードを変更する必要があります。

>> alter user ods identified by some_new_password

その後、oidpwdlldap1を新たに作成して、新規パスワードを格納します。

解決方法

Oracle Internet Directoryサーバーの起動を再試行します。

oidpwdrSIDファイルには、レプリカ識別名の識別名およびパスワードが暗号化形式で格納されます。Oracle Internet Directoryレプリケーション・サーバーは、起動時に、資格証明を使用してOracle Internet Directoryサーバーに接続します。

レプリケーション・パスワード・ウォレットoidpwdrSIDの例を次に示します。

/------BEGIN REPL CREDENTIAL:cn=replication dn,orclreplicaid=qdinh-sun_
adeldap,cn=replication configuration-----
ezNkZXMtY2JjLXBrY3M1cGFkfQUnaz0TsfzcP0nM1HcHAXchf5mJw+sb4y0bLvvw3RvSg7H
S7/WsKJB02fdSGRlmfWAV+6llkRQ26g==
-----END REPL CREDENTIAL:cn=replication dn,orclreplicaid=qdinh-sun_
adeldap,cn=replication configuration-----/

R.1.16.2 パスワードが同期されない

oidctlまたはopmnがOracle Internet Directoryサーバー・インスタンスの起動に失敗し、バインドできないというメッセージがレプリケーション・サーバー・ログ・ファイルoidrepld00.logに記録されます。

問題

oidpwdrSIDに格納されたレプリカ識別名のパスワードが、Oracle Internet Directoryサーバーのレプリカ識別名のパスワードと同期していません。

解決方法

ldapbindコマンドを使用して、Oracle Internet Directoryサーバー・インスタンスへの接続を試みます。oidpwdrSIDに格納されているレプリカ識別名とレプリカ識別名のパスワードを指定します。次に例を示します。

>> ldapbind -h host -p port -D "cn=replication dn,orclreplicaid=qdinh-sun_adeldap, cn=replication configuration" -q

接続に成功した場合は、オプション-pchgwalpwdを指定してremtoolを使用し、oidpwdrSIDウォレットのパスワードを再設定でき、これにより、このウォレットのレプリカのみのレプリケーション識別名のパスワードが変更されます。レプリケーション識別名パスワードを覚えていない場合は、オプション-prestpwdを指定してremtoolを使用し、このパスワードを再設定でき、これにより、レプリカのレプリケーション識別名のパスワードが再設定されます。

レプリケーション・パスワード・ウォレットをリセットした後、opmnctlを使用して、レプリケーション・サーバー・インスタンスをもう一度再起動します。

R.1.17 bulkloadに関するトラブルシューティング

次の手順に進む前に、bulkloadがスローしたすべてのエラーを調べ、修正することを強くお薦めします。bulkloadエラーを無視すると、後から深刻な問題が発生する可能性があります。

エラーの原因に関する情報を得るには、デバッグを有効にして(debug=t)コマンドを実行します。デバッグ情報は、ORACLE_INSTANCE/diagnostics/logs/OID/tools/bulkload.logおよびデータベースのods.ds_ldap_log表にあります。

大部分のbulkloadエラーは、データ・ロード中または索引作成中に発生します。

問題

bulkloadコマンド行ツールが、データ・ロード中に失敗しました。

解決方法

次のいずれかの方法を使用して、ディレクトリをデータ・ロード前の状態にリストアします。

- bulkload recoverオプションの使用

- bulkloadを起動する前に取ったバックアップからのデータベースのリストア。

問題

bulkloadコマンド行ツールが、索引作成中に失敗しました。

解決方法

bulkload.logを調べます。索引作成失敗の原因となった問題を特定し、修正します。bulkloadにindexオプションを指定して、再び実行します。

索引エラーの修正に失敗すると、Oracle Internet Directoryの表に重複エントリや重複行が生じる可能性があります。

問題

bulkloadコマンド行ツールが、データベースへの接続切断のために失敗しました。これは、たとえばホストのクラッシュや、Real Application Clustersでのフェイルオーバーが原因で、発生する可能性があります。

解決方法

次の手順に従ってください。

1. データベースが正常に再起動したか確認します。

2. bulkloadの起動にcheck="TRUE"オプションまたはgenerate="TRUE"オプションのみを使用し、load="TRUE"オプションを使用しなかった場合は、手順3に進んでください。
失敗したオプションがbulkload load="TRUE"オプションだった場合、データベースを失敗前の状態にリストアする必要があります。どのように行うかは、bulkload load="TRUE"コマンドを発行する前に、データベースのバックアップを取ったかどうかによって決まります。

- バックアップがある場合は、それを使用して、データベースをbulkloadコマンドを発行する前の元の状態にリストアします。

- バックアップがない場合は、bulkload recoverコマンドを使用して、データベースをbulkload load="TRUE"コマンド発行前の状態に戻します。

3. 失敗したbulkloadコマンドを再発行します。

R.1.18 bulkdelete、bulkmodifyおよびldifwriteに関するトラブルシューティング

次の手順に進む前に、バルク・ツールがスローしたすべてのエラーを調べ、修正することをお薦めします。エラーの理由の詳細を取得するには、デバッグを有効にしてコマンドを実行します(debug=t)。デバッグ情報は、ORACLE_INSTANCE/diagnostics/logs/OID/tools/の対応するログ・ファイルbulkdelete.log、bulkmodify.logまたはldifwrite.logにあります。データベースでは、デバッグ情報はods.ds_ldap_log表にあります。

問題

bulkdeleteまたはbulkmodifyコマンド行ツールが、データベースへの接続切断のために失敗しました。これは、たとえばホストのクラッシュや、Real Application Clustersでのフェイルオーバーが原因で、発生する可能性があります。

解決方法

データベースが正常に再起動したか確認します。次に、失敗したbulkdeleteまたはbulkmodifyコマンドを再試行します。

R.1.19 catalogに関するトラブルシューティング

次の手順に進む前に、バルク・ツールがスローしたすべてのエラーを調べ、修正することをお薦めします。エラーの理由の詳細を取得するには、デバッグを有効にしてコマンドを実行します(debug=t)。デバッグ情報は、ORACLE_INSTANCE/diagnostics/logs/OID/tools/catalog.logおよびデータベースのods.ds_ldap_log表にあります。

問題

catalogコマンド行ツールが、データベースへの接続切断のために失敗しました。これは、たとえばホストのクラッシュや、Real Application Clustersでのフェイルオーバーが原因で、発生する可能性があります。

解決方法

データベースが正常に再起動したか確認します。失敗したcatalogコマンドを再試行します。最初の起動でadd="TRUE"オプションを使用した場合は、最初のコマンドが部分的に完了しているため、再試行が失敗する可能性があります。再試行が失敗した場合、catalog delete="TRUE"を使用して属性索引を削除し、コマンドをもう一度再試行します。

問題

ファイル内に1000を超える属性があるため、catalogコマンドがエラーをスローします。

解決方法

1000を超える属性の索引を作成する必要がある場合は、複数のファイルを使用します。

R.1.20 remtoolに関するトラブルシューティング

問題

remtool問合せ

remtool -pdispqstat -v -bind host:port

などがハングします。停止中に、その他のツールを使用してサーバーにバインドしようとしても、失敗する可能性があります。

解決方法

パージ待ち状態の変更ログのバックログが大きい場合、remtoolの検索問合せの実行に長時間かかります。変更ログのパージが環境に応じて適切に構成されていることを確認してください。「変更ログのパージ」を参照してください。

また、ワーカー・スレッド数を増やし、remtoolによる問合せの実行時にその他のツールでのバインドを可能にすることもできます。『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』のインスタンス固有の構成エントリの属性に関する説明および「Oracle Internet Directory」の章を参照してください。

R.1.21 サーバー・チェーンに関するトラブルシューティング

問題

ログに、エラー・メッセージServer Chaining errorとjavax.naming.AuthenticationExceptionが含まれています。

解決方法

ODSMで、拡張タブに移動し、「サーバー・チェーン」を展開します。有効になっている各エントリで、「ログイン資格証明の検証」、「ユーザー・コンテナの検証」および「グループ・コンテナの検証」をクリックします。

検証に失敗した場合、入力した値に誤りがないか確認します。問題が解消されない場合、外部ディレクトリ管理者に連絡し、入力した値が正しいかどうかを確認します。

R.1.22 バージョン情報の表示

Oracle Internet Directory用のOracle Directory Services Managerホームページで、Oracle Directory Services Manager、Oracle Internet Directoryおよび対応するOracle Databaseのバージョン情報を表示できます。Oracle Directory Services Managerの使用の詳細は、「Oracle Directory Services Managerの使用」を参照してください。

R.1.23 Fusion Middleware ControlとWLSTに関するトラブルシューティング

問題

システムに11g リリース1(11.1.1.4.0)のパッチを適用した後、Oracle Enterprise Manager Fusion Middleware ControlおよびWLSTが機能しません。

解決方法

この問題は、SSLサーバー認証を有効にし、パッチ適用前に暗号スイートを構成した場合に発生します。パッチ適用後にこの問題を修正するには、ldapmodifyを使用して、インスタンス固有の構成エントリからorclsslciphersuite属性を削除します。インスタンス固有のエントリ内のorclsslciphersuite属性を削除するためのLDIFファイルは、次のとおりです。

dn: cn=componentname,cn=osdldapd,cn=subconfigsubentry
changetype: modify
delete: orclsslciphersuite

コマンドは次のとおりです。

ldapmodify -D cn=orcladmin -q -p portNum -h hostname -f ldifFile

「opmnctlを使用したOracle Internet Directoryサーバーの再起動」の説明に従って、Oracle Internet Directoryを再起動します。

問題

Oracle Internet Directoryは稼働していますが、Oracle Enterprise Manager Fusion Middleware ControlまたはWLSTを使用してOracle Internet Directoryのパラメータを変更できません。バックエンドOIDに接続できないというエラー・メッセージが表示される場合があります。

解決方法

これは、Oracle Internet Directoryのポート番号が変更されて、サーバーが再起動されていないか、Oracle Internet Directoryのコンポーネント登録が更新されていない場合に起こります。サーバーを再起動し、「opmnctlを使用したOracleインスタンスのコンポーネント登録の更新」に記載のとおりopmnctl updatecomponentregistrationを実行します。

解決方法

これは、レプリケーション・ウィザードの使用時にサーバー認証または相互認証用に構成されたSSLポートを指定した場合に発生します。レプリケーション・ウィザードは、認証なし用に構成されているSSLポートにのみ接続できます。ログインを要求された場合またはノードを指定する場合は、常に、非SSLポートまたは認証なし用に構成されたSSLポートを指定します。

R.1.24 Oracle Directory Services Managerに関するトラブルシューティング

この項では、Oracle Directory Services Managerに関する問題を示します。

R.1.24.1 Fusion Middleware ControlからODSMを起動できない

問題

Oracle Internet Directoryターゲットの「Oracle Internet Directory」メニューから「Directory Services Manager」を選択し、「データ・ブラウザ」、「スキーマ」、「セキュリティ」または「拡張」を選択して、Oracle Enterprise Manager Fusion Middleware ControlからのOracle Directory Services Managerの起動を試みます。

ODSMは開きません。エラー・メッセージが表示される場合があります。

解決方法

これは、インストールに問題がある可能性があります。『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』を参照してください。

R.1.24.2 複数のNICおよびDHCPが有効な環境でFusion Middleware ControlからODSMを起動できない

問題

Oracle Directory Services ManagerがデプロイされているWebLogic管理対象サーバーで、複数のネットワーク・インタフェース・カード(NIC)があるか、またはDHCPが有効です。Oracle Enterprise Manager Fusion Middleware ControlからのOracle Directory Services Managerの起動が失敗し、404 errorsが返されます。

解決方法

Oracle Directory Services ManagerのURL内のIPアドレスまたはホスト名にアクセスできるように、WebLogic Server管理コンソールを使用してWebLogic管理対象サーバーのリスニング・アドレスを変更します。

次の手順を実行してください。

1. ブラウザを使用して、WebLogic Server管理コンソールにアクセスします。

2. WebLogic Server管理コンソールの左ペインで、「ロックして編集」をクリックしてサーバー構成を編集します。

3. WebLogic Server管理コンソールの左ペインで「環境」を開き、「サーバー」を選択します。

4. 「サーバーのサマリー」ページで、Oracle Directory Services ManagerがデプロイされているWebLogic管理対象サーバーのリンクをクリックします。

5. WebLogic管理対象サーバーの「設定」ページで、「リスニング・アドレス」を、Oracle Directory Services Managerがデプロイされているサーバーのホスト名に更新します。

6. 構成を保存するには、「保存」をクリックします。

7. 「変更のアクティブ化」をクリックして、サーバー構成を更新します。

R.1.24.3 様々なフェイルオーバーの問題

問題

Oracle HTTP Serverを使用してOracle Directory Services Managerフェイルオーバーを行うと、フェイルオーバーが透過的ではありません。次の手順を実行すると、この動作を確認できます。

1. Oracle Directory Services Managerは、Oracle HTTP Serverを使用する高可用性アクティブ/アクティブ構成でデプロイされています。

2. Oracle HTTP Serverの名前とポート番号を使用してOracle Directory Services Managerページを表示します。

3. Oracle Internet Directoryサーバーへ接続します。

4. 現在のOracle Directory Services Manager Oracle HTTP Serverホストとポートを介して、Oracle Internet Directoryサーバーを使用します。

5. WebLogic Server管理コンソールを使用して、一度に1つずつ管理対象サーバーを停止します。

6. Oracle Directory Services Managerページとポート、およびOracle Internet Directoryとの間でこれより前に確立した接続に戻ります。これを行うと、Oracle Directory Services Managerページとの接続を新たに確立することを推奨するメッセージが表示されます。

解決方法

この問題が起きたら、次の手順を実行します。

1. Webブラウザで現在のOracle Directory Services Managerページを終了します。

2. 新規Webブラウザ・ページを起動し、同じOracle Directory Services Manager Oracle HTTP Server名とポートを指定します。

3. これより前に使用していたOracle Internet Directoryとの接続を新たに確立します。

関連項目:

- 高可用性環境でのOracle Directory Services Managerの詳細は、『Oracle Fusion Middleware高可用性ガイド』を参照してください。

- 「Oracle WebLogic ServerクラスタでOracle Directory Services ManagerをサポートするためのOracle HTTP Serverの構成」

問題

ODSMが一時的にOracle Internet Directoryとの接続を失い、LDAPサーバーが停止しています。というメッセージが表示されます。

解決方法

ODSMがロード・バランサを介してOracle Internet Directoryに接続している高可用性構成では、あるOracle Internet Directoryのインスタンスから別のインスタンスへのフェイルオーバー時、ODSMはサーバーが停止していると報告します。他の構成では、このメッセージはOracle Internet Directoryが停止され、再起動されたことを示す場合があります。いずれの場合も、接続の再確立にかかる時間はわずかで、再度ログインすることなく続行できます。

問題

ODSMでは、Oracle RACデータベースを使用しているOracle Internet Directoryインスタンスとの接続が一時的に切断されます。ODSMに、メッセージ「Oracleデータベースへのアクセスに失敗しました(Oracleエラー・コード=errcode)」が表示されることがあります(ここで、errcodeは、3113、3114、1092、28、1041または1012のいずれか1つの値です)。

解決方法

このエラーは、Oracle Internet Directoryインスタンスが使用しているOracle Databaseのフェイルオーバー時に起こります。いずれの場合も、接続の再確立にかかる時間はわずかで、再度ログインすることなく続行できます。

R.1.24.4 ODSMがエラー・メッセージを表示する

問題

ODSMが、エラー: Posn: -1、サイズ: 0というエラー・メッセージを表示します。

解決方法

このエラーは無視しても問題ありません。これは、通常、Oracle Internet DirectoryがODSM操作のエラーを検出したことを示しています。ODSMがOracle Internet Directoryに接続するために使用するJNDIは、実際のエラー・コードではなく、このエラー・コードを戻すことがあります。Oracle Internet Directoryサーバーのログ・ファイルには、意味のわかりやすいエラー・メッセージがより多く表示されます。

R.1.24.5 カーソルがフォーカスを失う

問題

Internet Explorer 7でキーボードのみを使用してODSMにアクセシビリティ・モードでアクセスすると、カーソルがフォーカスを失います。この動作は、次の環境で起こります。

- ディレクトリにSSL有効モードでアクセスし、サーバー証明書が表示されます。

- 無効なパスワードを入力し、エラー・ダイアログが表示されます。

解決方法

[Tab]キーを9回押し、[Enter]キーを押します。

R.1.25 ロックされたユーザー・アカウントに関するトラブルシューティング

間違った資格証明(パスワード)を使用してユーザーが複数のldapbind、ldapcompareまたはldapsearch操作を実行したために、ユーザー・アカウントがロックされることがあります。そのため、このユーザー・アカウントに依存するアプリケーションは、アカウントがロック解除されるまで正常に動作しない可能性があります。

ユーザー・アカウントをロック解除するには、LDAP操作に対して間違った資格証明を提供している不明なソース(IPアドレス)を最初に特定する必要があります。

この問題の原因となっている不明なソースを検出する手順は、次のとおりです。

1. ロギングを有効にしてすべてのldapbind、ldapcompareおよびldapsearch着信操作を取得するようにデバッグ・レベルを設定します。
次の例では、コンポーネント名としてoid1を使用します。生成されるログ・ファイルは、次のディレクトリに格納されます。

$ORACLE_INSTANCE/diagnostics/logs/OID/oid1

1. 次の内容が含まれるdebug.ldifというファイルを作成します。

dn: cn=oid1,cn=osdldapd,cn=subconfigsubentry
changetype: modify
replace: orcldebugflag
orcldebugflag: 1

dn: cn=oid1,cn=osdldapd,cn=subconfigsubentry
changetype: modify
replace: orcldebugop
orcldebugop: 193

orcldebugflagを1に設定することで、debug.ldifファイルによるデバッグが有効になります。このファイルでは、orcldebugopフラグを193に設定して、ユーザー・アカウントのロックの原因となっている可能性のある基本操作のldapbind、ldapcompareおよびldapsearch操作も記録します。

orcldebugopフラグの設定の詳細は、表24-4「orcldebugop属性を設定するためのデバッグ操作」を参照してください。

2. ldapmodifyコマンドを使用してLDIFファイルをロードします。次に例を示します。

ldapmodify -h oid_host -p oid_port -D cn=orcladmin -p admin_password -f debug.ldif

ロギングの詳細は、第24章「ロギングの管理」を参照してください。

2. 問題が再発するのを待機してから、次のOracle Internet Directoryサーバー・ログで、ldapbind、ldapcompareおよびldapsearch操作に関する情報を確認します。

$ORACLE_INSTANCE/diagnostics/logs/OID/oid1/oidldap01s*.log

このログの場所で、oidldap01s*.logは、oid1コンポーネントのすべてのサーバー・ログを指定します。詳細は、表24-1「Oracle Internet Directoryログ・ファイルの位置」を参照してください。

これらのログには大量の情報が含まれるため、ファイル全体で"useraccount"を検索して関連情報を検出します。一部のシステムでは、grepコマンドを使用できます。次に例を示します。

cd $ORACLE_INSTANCE/diagnostics/logs/OID/oid1
grep -A 5 -B 3 "useraccount" oidldap01s*.log

この例では、"useraccount"がロックされているユーザー・アカウントです。一部のシステムでサポートされる-Aおよび-Bオプションは、ユーザー・アカウントの上5行と下3行を返します。

たとえば、ロックされているユーザー・アカウントがfaadminの場合、次のgrepコマンドによって関連する行が返されます。

grep -A 5 -B 3 "faadmin" oidldap01s*.log

3. grepコマンドの出力を分析します。例として、次のサンプル出力について検討します。

idldapd01s20149-0082.log-[2012-06-26T15:54:45-07:00] [OID] [TRACE:16] []
[OIDLDAPD] [host: adcdk04] [pid: 20149] [tid: 13] [ecid:
004kqVw6GZG2nJK_ITDCif0004up00Nd8Q,0] ServerWorker (REG):[[
oidldapd01s20149-0082.log-BEGIN
oidldapd01s20149-0082.log ConnID:40614 mesgID:306 OpID:25 OpName:bind
ConnIP:::ffff:10.240.109.21
ConnDN:cn=faadmin,cn=users,dc=us,dc=example,dc=com
oidldapd01s20149-0082.log:INFO : gslfbidbDoBind * Version=3 BIND dn="cn=FAAdmin,cn=Users,dc=us,dc=example,dc=com" method=128
oidldapd01s20149-0082.log- ConnId = 40614, op=25, IpAddr=::ffff:10.240.109.21
oidldapd01s20149-0082.log-2012-06-26T15:54:45 * Adding pwdfailuretime in gslsbmApplyModtoEntry()
oidldapd01s20149-0082.log-2012-06-26T15:54:45 * INFO:gsleswrASndResult
OPtime=4929 micro sec RESULT=49 tag=97 nentries=0
oidldapd01s20149-0082.log-END
oidldapd01s20149-0082.log-]]

この出力は、間違った資格証明を使用してLDAP操作を実行しているソースのIPアドレスを示しています。

- リクエストID (特定のリクエストについて一定): ecid: 004kqVw6GZG2nJK_ITDCif0004up00Nd8Q,0

- IPアドレス: IpAddr=::ffff:10.240.109.21

- 操作名: OpName:bind

- バインドDN: BIND dn="cn=FAAdmin,cn=Users,dc=us,dc=example,dc=com"

4. 前の手順の情報を使用して、問題の原因となっている操作を停止します。

注意:
複数のLDAP操作がユーザーのロックの原因となっている可能性があるため、引き続きログ・ファイルを検索して、停止する必要のある他の操作のソースを見つけてください。

5. 問題の原因となっている操作を停止した後、orcldebugflagおよびorcldebugopの値を0に設定してデバッグを無効にできます。

1. 次の内容が含まれるdebug_disable.ldifというファイルを作成します。

dn: cn=oid1,cn=osdldapd,cn=subconfigsubentry
changetype: modify
replace: orcldebugflag
orcldebugflag: 0

dn: cn=oid1,cn=osdldapd,cn=subconfigsubentry
changetype: modify
replace: orcldebugop
orcldebugop: 0

2. ldapmodifyコマンドを使用してLDIFファイルをロードします。次に例を示します。

ldapmodify -h oid_host -p oid_port -D cn=orcladmin -p admin_password -f debug_disable.ldif

R.1.26 ポリシー・ストアの移行に関するトラブルシューティング

ポリシー・ストアとしてOracle Internet Directoryを使用している場合、Fusion Applications専用環境から共有環境へのポリシーの移行中に、Oracle Internet Directoryに対するOPSS問合せが低速になることが原因で、セキュリティ・ストアの移行の実行が非常に遅くなることがあります。状況によっては、タイムアウトのために移行が失敗する可能性があります。

解決方法

OPSS問合せのパフォーマンスを向上させるには、Oracle Internet Directoryのポリシー・ストアに次のチューニング値を設定します。

- Oracle Databaseチューニング・パラメータ

- SGA_MAX_SIZE: 4G以上

- Oracle Databaseサーバー・プロセス: 500以上

- Oracle Internet Directory属性

- orclecacheenabled: 2 (エントリ・キャッシュおよび結果セット・キャッシュの両方が有効)

- orclrscacheattr - 次のように複数値属性を設定します。

orclrscacheattr: orcljaznprincipal
orclrscacheattr: orcljaznpermissiontarget
orclrscacheattr: orcljpsresourcename
orclrscacheattr: uniquemember
orclrscacheattr: orcljpsassignee

- orclecachemaxsize: 16G以上

- orclinmemfiltprocess - 次のように複数値属性を設定します。

orclinmemfiltprocess: (orcljpsresourcetypename=taskflowresourcetype)
orclinmemfiltprocess: (orcljpsresourcetypename=regionresourcetype

R.1.26.1 Oracle ZFSでのポリシー・ストアの移行に関するトラブルシューティング

Oracle ZFSを使用しており、ポリシー・ストアの移行中にパフォーマンス問題が発生した場合、その問題は、Dynamic Intimate Shared Memory (DISM)を使用するOracle Databaseに関連している可能性があります。ZFSファイル・システムとDISMは、メモリー・ページ・アクセスでロックされる可能性があります。

解決方法

データベースでDISMを効果的に無効にするため、SGA_MAX_SIZEとSGA_TARGETを同じサイズ(4G)に設定してください。

R.2 その他の情報

問題のその他の解決方法は、次のサイトを参照してください。

- My Oracle Support (以前のMetaLink): http://support.oracle.com

- Oracle Technology Network (OTN)で参照可能な『Oracle Fusion Middlewareリリース・ノート』のコレクション:
http://www.oracle.com/technology/documentation/

問題の解決方法が見つからない場合は、Oracleにサービス・リクエストを登録してください。

Oracleサポート・サービスが問題のトラブルシューティングを行う際に役立つ、次の情報を用意してください。

- 次の内容を含む問題の発生状況と発生時期の詳細な説明:

- 問題の原因となった可能性のあるコマンド、プロシージャまたは操作。

- 問題を再現可能かどうか。

- 問題の原因が、ldapsearch、ldapadd、ldapmodify、ldapdeleteなどのコマンドを使用して起動できるスタンドアロンの再現可能なLDAP操作であるかどうか。

- Oracle Internet Directoryデバッグ・ログ(次の項を参照)。

R.2.1 Oracle Internet Directoryデバッグ・ログの提供

Oracle Internet Directoryデバッグ・ログは、問題の解決方法を見つける際に役立ちます。これらのログは、次のディレクトリに生成されます。

$ORACLE_INSTANCE/diagnostics/logs/OID/componentName

ここで、componentNameは、Oracle Internet Directoryインスタンスのコンポーネント名です。この項の例では、componentNameとしてoid1を使用します。

特定の問題に対するOracle Internet Directoryデバッグ・ログを生成する手順は、次のとおりです。

1. 第24.3.2項「コマンド行を使用したデバッグ・ロギング・レベルの設定」の説明に従って、特定の問題に関する情報を取得するようにデバッグ・ロギング・レベルを設定します。
orcldebugflag属性によって、Oracle Internet Directoryのデバッグ・ロギング・レベルが決定されます。

たとえば、アクセス制御リスト(ACL)関連の問題をトラブルシューティングする場合、Oracle Internet Directoryにユーザー、ロールまたは属性が追加されると、アクセス拒否などのLDAPエラー(LDAPエラー・コード49)が表示されます。

この場合、DITの各レベルでACLのビューを取得するために、ACL処理および大容量トレースのデバッグに関するデバッグ情報が必要です。

大容量トレースのデバッグの値は1で、ACL処理の値は8192です。したがって、orcldebugflagを8193 (1 + 8192)に設定します。

指定可能なすべての値のリストは、表24-3「OrclDebugFlagの値」を参照してください。

2. デバッグ・レベルを設定したら、問題を発生させる可能性のある操作を再度実行するか、問題が再発生するまで待機します。

3. 問題の発生後に、次のディレクトリにあるデバッグ・ログを確認します。

$ORACLE_INSTANCE/diagnostics/logs/OID/oid1/oidldap01s*.log

このログの場所で、oidldap01s*.logは、oid1コンポーネントのサーバー・ログを指定します。詳細は、表24-1「Oracle Internet Directoryログ・ファイルの位置」を参照してください。

4. デバッグ・ログは、非常に大きい可能性があるため、ログ・ファイル全体をOracleに送信しないでください。ログを検索してエラーの記述がある行を見つけ、Oracleのトラブルシューティング・プロセスに役立つようにファイルの抜粋を提供してください。
通常は、問題の原因となった操作が実行された時間に基づいて、ログ・ファイルでこれらの行の場所を識別できます。

Oracleの法律上の注意点

コピーライト

Copyright © 1994-2018, Oracle and/or its affiliates. All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクルまでご連絡ください。

制限付権利について

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、Oracle Corporationおよびその関連会社は一切の責任を負いかねます。

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

Pre-General Availability (一般提供前)版のドキュメントについて

このドキュメントがPre-General Availability (一般提供前)版の場合:

このドキュメントはPre-General Availability (一般提供前)版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のPre-General Availability (一般提供前)版のドキュメントについて

このドキュメントが非公開のPre-General Availability (一般提供前)版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のPre-General Availability Trial Agreement (Pre-GAトライアル契約)のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle Partner Network Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

ドキュメントのアクセシビリティ

オラクルのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

サポートをご契約のお客様には、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info)か、聴覚に障害のあるお客様は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。