Oracle® Fusion Middleware Oracle Directory Server Enterprise Editionリファレンス

11gリリース1(11.1.1.7.0)

B72441-01(原本部品番号:E28969-01)

目次

例一覧

図一覧

表一覧

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

はじめに

- 対象読者

- このドキュメントをお読みになる前に

- このドキュメントの構成

- このドキュメントで使用する例

- Oracle Directory Server Enterprise Editionドキュメント・セット

- 関連ドキュメント

- 再配布可能ファイル

- デフォルト・パスとコマンドの場所

- 表記規則

- コマンド例でのシェル・プロンプト

- 記号の表記規則

- ドキュメント、サポートおよびトレーニング

- Oracleソフトウェア・リソース

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

1 Directory Server Enterprise Editionファイル・リファレンス

- 1.1 Directory Server Enterprise Editionのソフトウェアのレイアウト

- 1.2 Directory Serverインスタンスのデフォルト・レイアウト

- 1.3 Directory Proxy Serverインスタンスのデフォルト・レイアウト

第I部 Directory Serverのリファレンス

2 Directory Serverの概要

- 2.1 Directory Serverの概要

- 2.2 Directory Serverのアーキテクチャ

- 2.2.1 ソフトウェア・インストールとサーバー・インスタンスの比較

- 2.2.2 クライアント・アプリケーションとの通信

- 2.2.3 Directory Serverの構成

- 2.2.4 Directory Serverでのデータ・ストレージ

- 2.2.5 ディレクトリ情報ツリーでのデータ構造

- 2.2.5.1 DITの用語

- 2.2.6 サーバー・インスタンス間のデータ・レプリケーション

- 2.2.7 Directory Serverでのアクセス制御

3 Directory ServerのLDAP URL

- 3.1 LDAP URLのコンポーネント

- 3.2 安全でない文字のエスケープ

- 3.3 LDAP URLの例

4 Directory Server LDIFおよび検索フィルタ

- 4.1 LDIFファイル形式

- 4.1.1 LDIFにおける行の継続

- 4.1.2 LDIFにおけるバイナリ・データ

- 4.1.2.1 標準のLDIF表記を使用したバイナリ・データの表現

- 4.1.2.2 ldapmodify -bコマンドを使用したバイナリ・データの表現

- 4.1.2.3 Base 64エンコードを使用したバイナリ・データの表現

- 4.2 LDIFのディレクトリ・エントリ

- 4.2.1 LDIFにおける組織エントリ

- 4.2.2 LDIFにおける組織単位エントリ

- 4.2.3 LDIFにおける組織の個人エントリ

- 4.3 LDIFを使用してディレクトリの定義をするためのガイドライン

- 4.4 複数言語での情報の格納

- 4.5 LDIF入力を行うためのガイドライン

- 4.5.1 コマンドラインへのLDIF入力の終了

- 4.5.2 特殊文字の使用

- 4.5.3 属性OIDの使用

- 4.5.4 スキーマ・チェック

- 4.5.5 LDIFエントリの順序

- 4.5.6 大規模なエントリの管理

- 4.5.7 エラーの処理

- 4.6 ディレクトリの検索

- 4.6.1 ldapsearchによるディレクトリの検索

- 4.6.1.1 ldapsearchコマンドラインの形式

- 4.6.1.2 特殊文字の使用方法

- 4.6.2 ldapsearchの例

- 4.6.2.1 すべてのエントリを返す

- 4.6.2.2 コマンドラインでの検索フィルタの指定

- 4.6.2.3 ルートDSEエントリの検索

- 4.6.2.4 スキーマ・エントリの検索

- 4.6.2.5 LDAP_BASEDNの使用方法

- 4.6.2.6 属性のサブセットの表示

- 4.6.2.7 複数値属性の検索

- 4.6.2.8 検索時のクライアント認証の使用方法

- 4.6.3 LDAP検索フィルタ

- 4.6.3.1 検索フィルタの構文

- 4.6.3.2 検索フィルタでの属性の使用

- 4.6.3.3 検索フィルタでの演算子の使用方法

- 4.6.3.4 検索フィルタでのOIDの使用方法

- 4.6.3.5 複合検索フィルタの使用方法

- 4.6.3.6 ファイルを使用した検索フィルタの指定

- 4.6.3.7 検索フィルタの7ビット以外のASCII文字の指定

- 4.6.4 検索フィルタの例

- 4.6.4.1 操作属性の検索

5 Directory Serverのセキュリティ

- 5.1 Directory Serverのセキュリティの提供方法

- 5.2 Directory Serverのアクセス制御の提供方法

- 5.2.1 ACIの概要

- 5.2.1.1 ACIの有効範囲および階層

- 5.2.1.2 ACIの制限

- 5.2.1.3 デフォルトACI

- 5.2.1.4 ACIおよびレプリケーション

- 5.2.1.5 実効権限

- 5.2.2 アクセス制御命令のチューニング

- 5.3 Directory Serverの認証の提供方法

- 5.3.1 匿名アクセス

- 5.3.2 パスワードベースの認証

- 5.3.2.1 パスワードベースの認証の手順

- 5.3.2.2 パスワード・ポリシー

- 5.3.3 プロキシ認可

- 5.3.4 アカウントの非アクティブ化

- 5.3.5 グローバル・アカウント・ロックアウト

- 5.3.6 証明書ベースの認証

- 5.3.6.1 証明書ベースの認証の概要

- 5.3.6.2 証明書および認証局(CA)

- 5.3.6.3 証明書のタイプ

- 5.3.6.4 証明書の内容

- 5.3.6.5 証明書の管理

- 5.3.7 SASLベースの認証

- 5.4 Directory Serverの暗号化の提供方法

- 5.4.1 Secure Sockets Layer (SSL)

- 5.4.1.1 SSLの概要

- 5.4.1.2 SSLで使用される暗号化アルゴリズム

- 5.4.1.3 SSLハンドシェイク

- 5.4.2 デジタル署名

- 5.4.3 鍵の暗号化

- 5.4.3.1 対称鍵暗号化

- 5.4.3.2 公開鍵暗号化

- 5.4.3.3 鍵の長さおよび暗号化強度

- 5.4.4 属性の暗号化

6 Directory Serverの監視

- 6.1 Directory Serverの監視方法

- 6.2 Directory ServerとSNMP

- 6.3 Directory Server監視属性

- 6.3.1 cn=monitor

- 6.3.1.1 backendMonitorDN

- 6.3.1.2 bytesSent

- 6.3.1.3 cache-avail-bytes

- 6.3.1.4 connection

- 6.3.1.5 connectionPeak

- 6.3.1.6 currentConnections

- 6.3.1.7 currentTime

- 6.3.1.8 dTableSize

- 6.3.1.9 entriesSent

- 6.3.1.10 nbackEnds

- 6.3.1.11 opsCompleted

- 6.3.1.12 opsInitiated

- 6.3.1.13 request-que-backlog

- 6.3.1.14 readWaiters

- 6.3.1.15 currentpsearches

- 6.3.1.16 startTime

- 6.3.1.17 threads

- 6.3.1.18 totalConnections

- 6.3.1.19 version

- 6.3.2 cn=disk,cn=monitor

- 6.3.2.1 disk-dir

- 6.3.2.2 disk-free

- 6.3.2.3 disk-state

- 6.3.3 cn=counters,cn=monitor

- 6.3.3.1 backlogsum

- 6.3.3.2 *etimesum

- 6.3.4 cn=monitor,cn=Class of Service,cn=plugins, cn=config

- 6.3.4.1 classicHashAvgClashListLength

- 6.3.4.2 classicHashAvgClashPercentagePerHash

- 6.3.4.3 classicHashMemUsage

- 6.3.4.4 classicHashValuesMemUsage

- 6.3.4.5 numClassicDefinitions

- 6.3.4.6 numClassicHashTables

- 6.3.4.7 numClassicTemplates

- 6.3.4.8 numCoSAttributeTypes

- 6.3.4.9 numIndirectDefinitions

- 6.3.4.10 numPointerDefinitions

- 6.3.4.11 numPointerTemplates

7 Directory Serverのレプリケーション

- 7.1 レプリケーションの概要

- 7.1.1 サプライヤおよびコンシューマ

- 7.1.2 レプリケーションの単位

- 7.1.3 レプリカのアイデンティティ

- 7.1.4 レプリカのタイプ

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

- 7.1.6 レプリケーション認証

- 7.1.7 レプリケーション変更ログ

- 7.1.8 変更順序番号

- 7.1.9 レプリカ更新ベクトル

- 7.1.10 削除済エントリ: ツームストン

- 7.1.11 コンシューマの初期化および増分更新

- 7.1.12 リフェラルおよびレプリケーション

- 7.2 レプリケーションおよびレトロ変更ログ・プラグイン

- 7.2.1 レトロ変更ログおよびマルチマスター・レプリケーション

- 7.2.2 レトロ変更ログのフェイルオーバー

- 7.2.3 レプリケーションの競合およびレトロ変更ログ

- 7.2.4 レトロ変更ログ使用時の制限事項

8 Directory Serverのデータ・キャッシュ

- 8.1 キャッシュのタイプ

- 8.1.1 データベース・キャッシュ

- 8.1.2 エントリ・キャッシュ

- 8.1.2.1 エントリ・キャッシュの仕組み

- 8.1.2.2 エントリ・キャッシュのプレロード

- 8.1.2.3 エントリ・キャッシュ・サイズの変更

- 8.1.3 インポート・キャッシュ

- 8.1.4 ファイル・システム・キャッシュ

- 8.1.5 総計キャッシュ・サイズ

- 8.2 Directory Serverによるキャッシュを使用した検索の実行方法

- 8.2.1 Directory Serverによるベース検索の実行方法

- 8.2.2 Directory Serverによるサブツリー検索および1レベル検索の実行方法

- 8.3 Directory Serverによるキャッシュを使用した更新の実行方法

- 8.4 Directory Serverによるキャッシュを使用したサフィックスの初期化方法

9 Directory Serverの索引作成

- 9.1 索引の概要

- 9.2 システム索引およびデフォルトの索引

- 9.2.1 システム索引

- 9.2.2 デフォルトの索引

- 9.3 索引のタイプ

- 9.3.1 存在索引付け

- 9.3.2 同等索引付け

- 9.3.3 部分文字列索引付け

- 9.3.4 索引の参照

- 9.3.5 近似索引付け

- 9.3.6 国際索引

10 Directory Serverのロギング

- 10.1 ログの概要

- 10.2 トランザクション・ログ

- 10.3 アクセス、エラーおよび監査ログ

- 10.3.1 アクセス・ログ

- 10.3.2 エラー・ログ

- 10.3.3 監査ログ

- 10.3.4 アクセス・ログ、エラー・ログおよび監査ログの内容

- 10.3.4.1 タイプ・スタンプ

- 10.3.4.2 接続番号

- 10.3.4.3 ファイル記述子

- 10.3.4.4 スロット番号

- 10.3.4.5 操作番号

- 10.3.4.6 方法のタイプ

- 10.3.4.7 LDAPのバージョン

- 10.3.4.8 エラー番号

- 10.3.4.9 タグ番号

- 10.3.4.10 エントリ数

- 10.3.4.11 経過時間

- 10.3.4.12 LDAPリクエスト・タイプ

- 10.3.4.13 LDAPレスポンス・タイプ

- 10.3.4.14 索引付けされていない検索インジケータ

- 10.3.4.15 拡張操作OID

- 10.3.4.16 ログ・ファイルにおける変更シーケンス番号

- 10.3.4.17 中止メッセージ

- 10.3.4.18 メッセージID

- 10.3.4.19 SASLマルチステージ・バインド・ログ

- 10.3.4.20 オプションの説明

- 10.3.5 ログ・ファイルにおける接続コード

- 10.3.6 ログ・ファイルにおける結果コード

11 Directory Serverのグループおよびロール

- 11.1 Directory Serverのグループ

- 11.1.1 静的グループ

- 11.1.2 動的グループ

- 11.1.3 ネストされたグループ

- 11.2 Directory Serverのロール

- 11.2.1 管理対象ロール

- 11.2.2 フィルタ処理されたロール

- 11.2.3 ネストされたロール

- 11.2.4 ロールの使用に関する制限事項

- 11.3 グループかロールかの決定

- 11.3.1 グループ・メカニズムの長所

- 11.3.2 ロール・メカニズムの長所

- 11.3.3 ロールに関する権限の制限

12 Directory Serverのサービス・クラス

- 12.1 CoSの概要

- 12.2 CoS定義エントリおよびCoSテンプレート・エントリ

- 12.2.1 CoS定義エントリ

- 12.2.2 CoSテンプレート・エントリ

- 12.3 ポインタCoS、間接CoSおよびクラシックCoS

- 12.3.1 ポインタCoS

- 12.3.2 間接CoS

- 12.3.3 クラシックCoS

- 12.4 サービス・クラスによる属性の管理

- 12.4.1 多くのエントリが同じ値を共有している場合のCoSの使用

- 12.4.2 エントリが自然な関係を持っている場合のCoSの使用

- 12.4.3 過剰なCoS定義の回避

- 12.5 CoSの優先度

- 12.6 CoSの制限

13 Directory ServerのDSMLv2

- 13.1 DSMLの概要

- 13.2 DSMLv2標準の実装

- 13.3 DSMLのセキュリティ

- 13.4 DSMLアイデンティティ・マッピング

- 13.5 HTTPヘッダーの内容

- 13.6 DSMLv2使用によるディレクトリへのアクセス

- 13.6.1 空の匿名DSML Pingリクエスト

- 13.6.2 特定のユーザーとしてバインドするDSMLリクエストの発行

- 13.6.3 DSML検索リクエスト

14 Directory Serverの国際化のサポート

- 14.1 ロケールについて

- 14.2 サポートされるロケールの識別

- 14.3 サポートされる言語のサブタイプ

第II部 Directory Proxy Serverのリファレンス

15 Directory Proxy Serverの概要

- 15.1 Directory Proxy Serverの概要

- 15.2 Directory Proxy Serverのアーキテクチャ

- 15.3 Directory Proxy Serverの機能の概要

16 Directory Proxy Serverのロード・バランシングおよびクライアント・アフィニティ

- 16.1 LDAP データ・ソース・プール

- 16.2 ロード・バランシング

- 16.2.1 ロード・バランシングの概要

- 16.2.2 ロード・バランシングの比例アルゴリズム

- 16.2.3 ロード・バランシングの飽和アルゴリズム

- 16.2.4 ロード・バランシングの操作アフィニティ・アルゴリズム

- 16.2.4.1 ロード・バランシングの操作アフィニティ・アルゴリズムを使用するデメリット

- 16.2.4.2 グローバル・アカウントのロックアウトに対する操作アフィニティ・アルゴリズム

- 16.2.4.3 キャッシュ最適化の操作アフィニティ・アルゴリズム

- 16.2.5 ロード・バランシングのフェイルオーバー・アルゴリズム

- 16.2.6 ロード・バランシングの適応フェイルオーバー・アルゴリズム

- 16.2.7 ロード・バランシングの最速サーバー・アルゴリズム

- 16.3 クライアント・アフィニティ

17 Directory Proxy Serverの配布

- 17.1 LDAPデータ・ビュー

- 17.1.1 LDAPデータ・ビューの機能

- 17.1.1.1 データ・ビューからのサブツリーの除外

- 17.1.1.2 上位データ・ビューをターゲットとする検索の除外された下位データ・ビューでの検索

- 17.1.1.3 属性名とDN名の変更

- 17.2 異なるデータ・ビューへのサブツリーのエントリの配布

- 17.2.1 配布アルゴリズムの制限

- 17.3 データ・ビューのユースケース

- 17.3.1 リクエストのターゲットDNに関係なく、すべてのリクエストをルーティングするデータ・ビュー

- 17.3.2 データと等価な複数のデータソースにサブツリー・リストが格納されている場合にリクエストをルーティングするデータ・ビュー

- 17.3.3 異なるサブツリーが異なるデータソースに格納されている場合に単一のアクセス・ポイントを提供するデータ・ビュー

- 17.3.4 サブツリーの様々な部分が異なるデータソースに格納されている場合にリクエストをルーティングするデータ・ビュー

- 17.3.5 上位サブツリーと下位サブツリーが異なるデータソースに格納されている場合にリクエストをルーティングするデータ・ビュー

- 17.3.6 階層および配布アルゴリズムを持つデータ・ビュー

18 Directory Proxy Serverの仮想化

- 18.1 仮想データ・ビューの構造

- 18.2 仮想データの変換

- 18.2.1 変換モデル

- 18.2.1.1 マッピング変換

- 18.2.1.2 書込み変換

- 18.2.1.3 読取り変換

- 18.2.2 変換アクション

- 18.2.3 変換パラメータ

- 18.2.4 変換の例

- 18.3 仮想データ・ビューの追加プロパティ

- 18.4 結合データ・ビュー

- 18.4.1 プライマリ・データ・ビューとセカンダリ・データ・ビュー

- 18.4.2 セカンダリ・データ・ビューの追加プロパティ

- 18.4.2.1 結合ルール

- 18.4.2.2 共有エントリの処理

- 18.4.2.3 バインドの処理

- 18.4.3 Directory Proxy Serverが結合データ・ビューで読取りおよび書込み操作を処理する方法

- 18.4.4 結合データ・ビューの仮想データ変換

- 18.5 コーディネータ・データ・ビュー

- 18.5.1 コーディネータ・データ・ビューの機能

- 18.6 LDIFデータ・ビュー

- 18.7 JDBCデータ・ビュー

- 18.7.1 JDBCデータ・ソースおよびデータ・ソース・プール

- 18.7.2 JDBCオブジェクト・クラス

- 18.7.3 JDBC表

- 18.7.4 JDBC属性

- 18.7.5 JDBCデータ・ビューの大/小文字の区別

- 18.8 仮想データ・ビューのアクセス制御

- 18.8.1 仮想ACIの定義

- 18.8.2 グローバルACI

- 18.8.3 仮想ACI構文

- 18.8.4 仮想ACIのストレージおよびアクセス

- 18.8.5 仮想ACIのアプリケーション

- 18.9 仮想スキーマのチェック

- 18.9.1 スキーマのチェック

- 18.10 仮想データ・ビューおよびLDAPグループ

19 Directory Proxy ServerとバックエンドLDAPサーバー間の接続

- 19.1 LDAPデータソース

- 19.2 Directory Proxy ServerとバックエンドLDAPサーバーの接続

- 19.2.1 Directory Proxy ServerとバックエンドLDAPサーバー間の接続の開閉

- 19.2.2 Directory Proxy ServerとバックエンドLDAPサーバー間の接続プール

- 19.3 Directory Proxy ServerからバックエンドLDAPサーバーへのリクエストの転送

- 19.3.1 バインド・リプレイに構成されたDirectory Proxy Server

- 19.3.2 プロキシ認可に構成されたDirectory Proxy Server

- 19.3.2.1 Directory Proxy Serverがプロキシ認可に構成されているときの接続

- 19.3.2.2 プロキシ認可に構成されているDirectory Proxy Serverおよびクライアント・リクエストにプロキシ認可が含まれていない

- 19.3.2.3 プロキシ認可に構成されたDirectory Proxy Serverおよびクライアント・リクエストにプロキシ認可が含まれる

- 19.3.2.4 Directory Proxy Serverがプロキシ認可に構成されているときのセキュリティの問題

- 19.3.3 クライアント・アイデンティティなしでリクエストを転送するよう構成されたDirectory Proxy Server

- 19.3.4 代替ユーザーとしてリクエストを転送するよう構成されたDirectory Proxy Server

20 クライアントとDirectory Proxy Server間の接続

- 20.1 接続を接続ハンドラに割り当てる基準

- 20.2 接続ハンドラのデータ・ビュー

- 20.3 接続ハンドラのリソース制限ポリシー

- 20.3.1 カスタマイズされた検索制限

- 20.4 接続ハンドラのリクエスト・フィルタリング・ポリシー

- 20.4.1 リクエスト・フィルタリング・ポリシーのサブツリー

- 20.4.1.1 許可されたサブツリー

- 20.4.1.2 禁止されたサブツリー

- 20.4.2 リクエスト・フィルタリング・ポリシーの検索データ非表示ルール

21 Directory Proxy Serverのクライアント認証

- 21.1 クライアント認証の概要

- 21.2 単純バインド認証

- 21.2.1 パスワードの暗号化と検証

- 21.3 証明書ベースの認証

- 21.3.1 Directory Proxy Serverでの証明書の構成

- 21.3.2 SASL外部バインドの使用

- 21.4 匿名アクセス

- 21.5 Directory Proxy Serverのクライアント・リスナー

22 Directory Proxy Serverのセキュリティ

- 22.1 Directory Proxy Serverでのセキュリティ

- 22.2 Directory Proxy ServerのSecure Sockets Layer

- 22.3 Directory Proxy Serverの暗号およびプロトコル

23 Directory Proxy Serverのロギング

- 23.1 Directory Proxy Serverのログの概要

- 23.2 ログ・ファイルのローテーション

- 23.3 ログ・ファイルの削除

- 23.4 メッセージの重大度

- 23.5 Directory Proxy Serverのエラー・ログ

- 23.5.1 エラー・ログ・レベル

- 23.5.2 エラー・メッセージのフォーマット

- 23.6 Directory Proxy Serverのアクセス・ログ

- 23.6.1 アクセス・ログ・レベル

- 23.6.2 アクセス・ログ・メッセージのフォーマット

- 23.6.3 バインド・ログのメッセージの部分

- 23.6.4 アクセス・ログ・バッファ

- 23.7 Directory Proxy Serverのバインド・ログ

- 23.7.1 バインド・ログ・メッセージのフォーマット

- 23.7.2 バインド・ログのメッセージの部分

- 23.7.3 バインド・ログ・バッファ

- 23.8 Directory Proxy Serverの接続ログ

- 23.8.1 接続ログ・メッセージのフォーマット

- 23.8.2 接続ログのメッセージの部分

- 23.8.3 接続ログ・バッファ

- 23.9 Directory Proxy ServerおよびDirectory Serverのアクセス・ログによるクライアント・リクエストの追跡

- 23.9.1 接続のトラックの単純化

- 23.9.2 接続ごとのトラッキング操作

- 23.9.2.1 Directory Proxy Serverのトラッキング操作

- 23.9.2.2 Directory Proxy ServerおよびDirectory Server間の操作のトラッキング

- 23.9.3 クライアント識別

24 Directory Proxy Serverのアラートおよび監視

- 24.1 Directory Proxy Serverの管理アラート

- 24.2 データソースの監視

- 24.2.1 データソースの監視方法

- 24.2.1.1 エラーをリッスンしてデータソースを監視する

- 24.2.1.2 定期的に専用の接続を確立してデータソースを監視する

- 24.2.1.3 確立した接続をテストしてデータソースを監視する

- 24.2.2 データソースの失敗に対するレスポンス

- 24.3 Directory Proxy Serverの監視

- 24.3.1 cn=monitorエントリの簡略化されたレイアウト

- 24.3.2 監視された情報のステータス

- 24.3.3 cn=monitorエントリの下の各エントリの説明

- 24.3.3.1 cn=Product

- 24.3.3.2 cn=Operating System

- 24.3.3.3 cn=Instance

- 24.3.3.4 cn=Service

- 24.3.3.5 cn=SAP

- 24.3.3.6 cn=RSAP

- 24.3.3.7 cn=Component

- 24.3.3.8 cn=JVM

- 24.3.3.9 cn=Resource

- 24.3.4 cn=monitorエントリの詳細なレイアウト

索引

例一覧

- 3-1 エントリのベース検索

- 3-2 エントリのpostalAddress属性の取得

- 3-3 エントリのcnおよびmail属性の取得

- 3-4 dc=example,dc=com配下の姓Jensenの取得

- 3-5 dc=example,dc=comより1レベル下のすべてのエントリに関するオブジェクト・クラスの取得

- 4-1 LDIFのディレクトリ・エントリ

- 4-2 組織、組織単位、および組織の個人のエントリがあるLDIFファイルの例

- 5-1 証明書の人間が判読可能な形式でのデータ・セクションおよび署名セクション

- 5-2 ソフトウェアによって解読される64バイトでエンコードされた形式での証明書

- 13-1 空の匿名DSMLリクエスト

- 13-2 空の匿名DSMLレスポンス

- 13-3 DSML拡張操作: 特定ユーザーとしてのバインド

- 13-4 DSML拡張操作に対するレスポンス

- 13-5 DSML検索リクエスト

- 13-6 DSML検索レスポンス

- 18-1 マッピング変換を使用する場合

- 18-2 書込み変換を使用する場合

- 18-3 読取り変換を使用する場合

- 18-4 ADAMオブジェクト・クラスのLDAP準拠への適合

- 18-5 書込み変換による属性の構成

- 18-6 読取り変換による属性の構成

- 18-7 デフォルト属性値の追加

- 18-8 仮想変換を使用したDNの名前変更

- 23-1 エラー・ログの抜粋

- 23-2 アクセス・ログの抜粋

- 23-3 バインド・ログの抜粋

- 23-4 接続ログの抜粋

図一覧

- 2-1 1つのDirectory Server内の2つのルート・サフィックス

- 2-2 複数のサブサフィックスを持つ1つのルート・サフィックス

- 5-1 パスワードベースの認証

- 5-2 証明書ベースの認証

- 5-3 認証局の階層

- 5-4 証明書チェーン

- 5-5 証明書チェーンの検証

- 5-6 中間CAに対する証明書チェーンの検証

- 5-7 検証できない証明書チェーン

- 5-8 SSLが実行される場所

- 5-9 SSLハンドシェイクでのクライアントの証明書の認証

- 5-10 SSLハンドシェイクでの認証および検証

- 5-11 デジタル署名

- 5-12 対称鍵暗号化

- 5-13 公開鍵暗号化

- 5-14 属性の暗号化

- 6-1 情報フローの全体的な監視

- 6-2 SNMPの情報フロー

- 7-1 レトロ変更ログおよびマルチマスター・レプリケーション

- 7-2 レトロ変更ログのレプリケーションの簡略化したトポロジ

- 7-3 レトロ変更ログのフェイルオーバー

- 8-1 コンテキスト内のエントリおよびデータベース・キャッシュ

- 8-2 ディレクトリ・サーバーによる検索の実行方法

- 8-3 Directory Serverによる更新の実行方法

- 8-4 Directory Serverによるサフィックスの初期化方法

- 9-1 存在索引付け

- 9-2 同等索引付け

- 9-3 SN属性の部分文字列索引付け

- 9-4 索引の参照の図示

- 12-1 CoSの範囲

- 12-2 ポインタCoSの定義およびテンプレートの例

- 12-3 間接CoSの定義およびテンプレートの例

- 12-4 クラシックCoS定義とテンプレートの例

- 12-5 ポインタCoSによるCompanyNameの生成

- 12-6 間接CoSを使用した、DepartmentNumberの生成

- 12-7 間接CoSを使用したメール・ストップとFAX番号の生成

- 12-8 クラシックCoSを使用したサービス・レベル・データの生成

- 13-1 DSML有効化ディレクトリのデプロイメント例

- 15-1 単純化したDirectory Proxy Serverのアーキテクチャ

- 16-1 ロード・バランシングの比例アルゴリズムに従ったリクエストの分散

- 16-2 ロード・バランシングの飽和アルゴリズムに従ったリクエストの分散

- 16-3 ロード・バランシングの操作アフィニティ・アルゴリズムに従ったリクエストの分散

- 16-4 ロード・バランシングの適応フェイルオーバー・アルゴリズムに従ったリクエストの分散

- 17-1 属性名の変更

- 17-2 DN名の変更

- 17-3 ターゲットDNに関係なく、すべてのリクエストをデータソース・プールにルーティングするデプロイメントの例

- 17-4 データと等価な複数のデータソースにサブツリー・リストが格納されている場合にリクエストをルーティングするデプロイメント例

- 17-5 異なるサブツリーが異なるデータソースに格納されている場合に単一のアクセス・ポイントを提供するデプロイメント例

- 17-6 サブツリーの様々な部分が異なるデータソースに格納されている場合にリクエストをルーティングするデプロイメントの例

- 17-7 上位サブツリーと下位サブツリーが異なるデータソースに格納されている場合にリクエストをルーティングするデプロイメント例

- 17-8 階層および配布アルゴリズムを持つデータ・ビューの例

- 18-1 仮想データ・ビュー

- 18-2 マッピング変換

- 18-3 書込み変換

- 18-4 読取り変換

- 19-1 バインド・リプレイでの認証

- 19-2 プロキシ認可の接続

- 19-3 Directory Proxy Serverでプロキシ認可制御が追加されるときの情報フロー

- 19-4 プロキシ認可制御がクライアント・リクエストに含まれているときの情報フロー

- 19-5 代替アイデンティティへのクライアント・アイデンティティのローカル・マッピング

- 19-6 代替アイデンティティへのクライアント・アイデンティティのリモート・マッピング

- 20-1 接続ハンドラのデータ・ビューのリスト

表一覧

- 3-1 LDAP URLのコンポーネント

- 3-2 URLにおいて安全でない文字

- 4-1 LDIFのフィールド

- 4-2 LDIFにおける組織エントリ

- 4-3 LDIFにおける組織単位エントリ

- 4-4 LDIFにおける組織の個人エントリ

- 4-5 検索フィルタの演算子

- 4-6 検索フィルタのブール演算子

- 4-7 検索フィルタの特殊文字

- 8-1 インポート操作とキャッシュの使用

- 9-1 すべてのサフィックスに自動的に作成されるシステム索引

- 9-2 すべての新規サフィックスにおけるデフォルトの索引

- 10-1 Directory Serverによって使用されるログ

- 10-2 LDAPサーバーの結果コードのまとめ

- 10-3 LDAPクライアントの結果コードのまとめ

- 14-1 サポートされるロケール

- 14-2 サポートされる言語のサブタイプ

- 23-1 エラー・ログのメッセージ・カテゴリ

- 23-2 アクセス・ログのメッセージ・カテゴリ

- 23-3 クライアントとDirectory Proxy Server間の接続のメッセージの各部分

- 23-4 Directory Proxy Serverとデータ・ソース間の接続のメッセージの各部分

- 23-5 接続ログ・メッセージのカテゴリ

- 24-1 Directory Proxy Serverの管理アラート

- 24-2 監視された情報のステータス

Oracle® Fusion Middleware

Oracle Directory Server Enterprise Editionリファレンス

11gリリース1(11.1.1.7.0)

B72441-01(原本部品番号:E28969-01)

2013年1月

Directory ServerおよびDirectory Proxy Serverの製品アーキテクチャ、構成、ツール、APIおよびスキーマについて説明します。

Oracle Fusion Middleware Oracle Directory Server Enterprise Editionリファレンス, 11g リリース 1 (11.1.1.7.0)

B72441-01

Copyright © 2001, 2013, Oracle and/or its affiliates.All rights reserved.

原本主著者:  Gina Cariaga

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

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

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

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 Directory Server Enterprise Editionリファレンス』では、Directory ServerおよびDirectory Proxy Serverの製品アーキテクチャ、構成、ツール、APIおよびスキーマについて説明します。

対象読者

このリファレンスは、ディレクトリ・サービスの管理者、設計者および開発者を対象としています。

このドキュメントをお読みになる前に

関連情報については、『Oracle Directory Server Enterprise Editionリリース・ノート』を確認してください。

Directory Server Enterprise Editionソフトウェアを本番にデプロイする場合は、『Oracle Directory Server Enterprise Editionデプロイメント・プランニング・ガイド』で関連情報を確認してください。

このドキュメントの構成

第1章「Directory Server Enterprise Editionのファイル参照」では、インストールされた製品のレイアウトを説明します。

第I部「Directory Serverのリファレンス」では、Directory Serverの機能およびアーキテクチャを説明します。

第II部「Directory Proxy Serverのリファレンス」では、Directory Proxy Serverの機能およびアーキテクチャを説明します。

このドキュメントで使用する例

一貫性を保つため、このガイド全体で同じサンプル・データを使用します。これらの値をご使用のシステムに適した値に置き換えてください。

変数

例で使用する値

サフィックス(SUFFIX_DN)

dc=example,dc=com

インスタンスのパス(INSTANCE_PATH)

Directory Serverの場合: /local/dsInst/

Directory Proxy Serverの場合: /local/dps/

ホスト名(HOST)

host1、host2、host3

ポート(PORT)

LDAP:rootのデフォルト: 389。root以外のデフォルト: 1389

SSLのデフォルト: rootのデフォルト: 636。root以外のデフォルト: 1636

Oracle Directory Server Enterprise Editionドキュメント・セット

このドキュメント・セットでは、Oracle Directory Server Enterprise Editionを使用してディレクトリ・サービスを評価、設計、デプロイ、および管理する方法について説明します。また、Directory Server Enterprise Edition用クライアント・アプリケーションの開発方法についても説明します。Oracle Fusion Middleware Directory Server Enterprise Editionドキュメント・ライブラリは、http://docs.oracle.com/cd/E29127_01/index.htmで入手できます。

次の表に、Directory Server Enterprise Editionのドキュメント・セットを構成するドキュメントのリストを示します。

ドキュメント・タイトル

内容

Oracle Directory Server Enterprise Edition
リリース・ノート

既知の問題点を含め、Directory Server Enterprise Editionについての最新情報を提供しています。

Oracle Directory Server Enterprise Edition
評価ガイド

このリリースの重要な機能を紹介します。これらの機能の仕組みや提供される利点を、単独システムに実装可能なデプロイメントのコンテキストに沿って示しています。

Oracle Directory Server Enterprise Edition
デプロイメント・プランニング・ガイド

Directory Server Enterprise Editionをベースとする、可用性と拡張性に優れたディレクトリ・サービスを計画および設計する方法について説明しています。デプロイメントの計画および設計の基本的な概念および原則を提示します。ソリューションのライフ・サイクルについて検討し、Directory Server Enterprise Editionベースのソリューションを計画するために使用する概略レベルのサンプルおよび戦略を提供します。

Oracle Directory Server Enterprise Edition
インストレーション・ガイド

Directory Server Enterprise Editionソフトウェアのインストール方法について説明しています。インストール済ソフトウェアの構成方法および構成済ソフトウェアの検証方法を示します。

Oracle Directory Server Enterprise Edition
アップグレードおよび移行ガイド

バージョン11.1.1.3, 7.xおよび6のインストールをアップグレードする手順およびバージョン5.2インストールを移行する手順を示しています。

Oracle Directory Server Enterprise Edition
管理者ガイド

Directory Server Enterprise Editionをコマンドラインから管理する手順を示しています。

Directory Service Control Center(DSCC)を使用してDirectory Server Enterprise Editionを管理する際のヒントおよび手順については、DSCCのオンライン・ヘルプを参照してください。

Oracle Directory Server Enterprise Edition
リファレンス

Directory Server Enterprise Editionの技術および概念の基礎を紹介します。コンポーネント、アーキテクチャ、プロセス、および機能について説明しています。

Oracle Directory Server Enterprise Edition
マニュアル・ページ・リファレンス

Directory Server Enterprise Editionを通じて利用可能なコマンドライン・ツール、スキーマ・オブジェクトおよびその他の公開インタフェースについて説明しています。このドキュメントの個別の項を、オンライン・マニュアル・ページとしてインストールできます。

Oracle Directory Server Enterprise Edition
開発者ガイド

Directory Server Enterprise Editionの一部として提供されるツールおよびAPIを利用して、ディレクトリ・クライアント・アプリケーションを開発する方法を示しています。

Oracle Directory Server Enterprise Edition
トラブルシューティング・ガイド

様々なツールを使用して問題の範囲を特定し、データを収集し、問題部分のトラブルシューティングを行う手順について説明しています。

Identity Synchronization for Windows 6.0
リリース・ノート

Identity Synchronization for Windows 6.0 SP1のインストール、移行およびアップグレードに関する最新の情報を説明しています。

Identity Synchronization for Windows 6.0
デプロイメント・プランニング・ガイド

Identity Synchronization for Windowsの計画とデプロイメントに関する一般的なガイドラインやベスト・プラクティスを示しています。

Identity Synchronization for Windows 6.0
インストールおよび構成ガイド

Identity Synchronization for Windowsをインストールおよび構成する方法を説明しています。

Directory Server Enterprise Editionの概要については、次のドキュメントを、次の図の記載順に確認してください。

図docmap.pngの説明

関連ドキュメント

SLAMD分散負荷生成エンジンは、ネットワークベースのアプリケーションのパフォーマンスについて負荷テストを実行し、解析するために設計されたJavaアプリケーションです。このアプリケーションは、LDAPディレクトリ・サーバーのパフォーマンスについてベンチマークを実行し、分析するためにSun Microsystems, Inc.によって開発されました。SLAMDは、OSI認定オープン・ソース・ライセンスであるSun Public Licenseに基づいて、オープン・ソース・アプリケーションとして使用できます。SLAMDに関する情報を取得するには、http://www.slamd.com/を参照してください。SLAMDは、java.netプロジェクトでも提供されています。https://slamd.dev.java.net/を参照してください。

Java Naming and Directory Interface(JNDI)は、LDAPやDSML v2によるJavaアプリケーションからDirectory Serverへのアクセスに対応しています。JNDIの詳細は、http://www.oracle.com/technetwork/java/jndi/index.htmlを参照してください。JNDI Tutorialには、詳しい説明とJNDIの使用例が記載されています。このチュートリアルは、http://download.oracle.com/javase/jndi/tutorial/で参照できます。

Identity Synchronization for WindowsはMessage Queueを制限されたライセンスで使用します。Message Queueのドキュメントは、http://www.oracle.com/technetwork/indexes/documentation/index.htmlから入手できます。

Identity Synchronization for WindowsはMicrosoft Windowsのパスワード・ポリシーを扱います。

- Windows 2003のパスワード・ポリシーに関する情報は、オンラインのMicrosoftのドキュメント(http://technet.microsoft.com/en-us/windowsserver/default.aspx)で入手できます。

- Microsoft証明書サービスのエンタープライズ・ルート認証局に関する情報は、オンラインのMicrosoftサポート・ドキュメント(http://support.microsoft.com/default.aspx?scid=kb;en-us;247078)で入手できます。

- MicrosoftシステムでのLDAP over SSLの設定に関する情報は、オンラインのMicrosoftサポート・ドキュメント(http://support.microsoft.com/default.aspx?scid=kb;en-us;321051)で入手できます。

再配布可能ファイル

Directory Server Enterprise Editionのファイルは、再頒布できません。

デフォルト・パスとコマンドの場所

この項では、このドキュメントで使用するデフォルトのパスについて説明し、様々なオペレーティング・システムおよびデプロイメント・タイプでのコマンドの場所を示します。

デフォルト・パス

次の表では、このドキュメントで使用するデフォルトのパスについて説明します。インストールされるファイルの詳細は、『Oracle Directory Server Enterprise Editionリファレンス』の第1章「Directory Server Enterprise Editionのファイル参照」を参照してください。

プレースホルダ

説明

デフォルト値

install-path

Directory Server Enterprise Editionソフトウェアのベース・インストール・ディレクトリを表します。

unzipを使用してzipディストリビューションからインストールする場合、install-pathは、current-directory/dsee7になります。

instance-path

Directory ServerまたはDirectory Proxy Serverのインスタンスのフルパスを表します。

このドキュメントでは、Directory Serverには/local/dsInst/、Directory Proxy Serverには/local/dps/を使用します。

デフォルト・パスはありません。インスタンス・パスは、常にローカル・ファイル・システム上に存在するようにします。

Solarisシステムでは、/varディレクトリをお薦めします。

serverroot

Identity Synchronization for Windowsのインストール先の親ディレクトリを表します。

インストールごとに異なります。Directory ServerおよびDirectory Proxy Serverでは、serverrootの概念が存在しなくなったことに注意してください。

isw-hostname

Identity Synchronization for Windowsインスタンスのディレクトリを表します。

インストールごとに異なります。

/path/to/cert8.db

Identity Synchronization for Windowsにおけるクライアントの証明書データベースのデフォルト・パスおよびファイル名を表します。

current-working-dir/cert8.db

serverroot/isw-hostname/linebreaklogs/

システム・マネージャ、各コネクタ、およびセントラル・ロガーのログ・ファイルをIdentity Synchronization for Windowsがローカルに保存する場所のデフォルト・パスを表します。

インストールごとに異なります。

serverroot/isw-hostname/linebreaklogs/central/

Identity Synchronization for Windowsセントラル・ログ・ファイルのデフォルト・パスを表します。

インストールごとに異なります。

コマンドの場所

この項の次の表は、Directory Server Enterprise Editionのドキュメントで使用されるコマンドの場所を示しています。各コマンドの詳細は、関連するマニュアル・ページを参照してください。『Oracle Directory Server Enterprise Editionリファレンス』のDirectory Server Enterprise Editionのソフトウェア・レイアウトに関する説明も参照してください。

コマンド

Zipディストリビューション

certutil

install-path/bin/certutil

dpadm

install-path/bin/dpadm

dpconf

install-path/bin/dpconf

dsadm

install-path/bin/dsadm

dsccagent

install-path/bin/agent

dsccmon

install-path/bin/dsccmon

dsccreg

install-path/bin/dsccreg

dsccsetup

install-path/bin/dsccsetup

dsconf

install-path/bin/dsconf

dsmig

install-path/bin/dsmig

dsutil

install-path/bin/dsutil

entrycmp

install-path/bin/entrycmp

fildif

install-path/bin/fildif

idsktune

解凍したzipディストリビューションのroot

insync

install-path/bin/insync

ldapmodify

install-path/dsrk/bin/ldapmodify

ldapsearch

install-path/dsrk/bin/ldapsearch

repldisc

install-path/bin/repldisc

表記規則

次の表に、このドキュメントで使用する表記規則を示します。

書体

意味

例

AaBbCc123

コマンド名、ファイル名、ディレクトリ名、画面上のコンピュータ出力を示します。

.loginファイルを編集します。

ls aを使用してすべてのファイルをリストします。

machine_name% you have mail.

AaBbCc123

ユーザーが入力する文字を、画面上のコンピュータ出力と区別して示します。

machine_name% su

Password:

aabbcc123

プレースホルダ: 実際の名前または値で置き換えます。

ファイルを削除するコマンドはrm filenameです。

AaBbCc123

書名、新規用語および強調する用語を示します。

『ユーザーズ・ガイド』の第6章を参照してください。

キャッシュとは、ローカルに格納されるコピーです。

このファイルは保存しないでください。

注意: 強調する一部の項目は、オンラインで太字で表示されます。

コマンド例でのシェル・プロンプト

次の表に、Oracle Solaris OSに含まれるシェルのデフォルトのUNIXシステム・プロンプトとスーパーユーザー・プロンプトを示します。コマンド例に表示されるデフォルトのシステム・プロンプトは、Oracle Solarisのリリースによって異なることに注意してください。

シェル

プロンプト

Bashシェル、KornシェルおよびBourneシェル

$

Bashシェル、KornシェルおよびBourneシェル(スーパーユーザーの場合)

#

Cシェル

machine_name%

Cシェル(スーパーユーザーの場合)

machine_name#

記号の表記規則

次の表では、このドキュメントで使用される記号について説明します。

記号

説明

例

意味

[ ]

省略可能な引数やコマンドオプションが含まれます。

ls [-l]

-lオプションは省略可能です。

{ | }

必須のコマンドオプションの選択肢を囲みます。

-d {y|n}

-dオプションでは、yかnのどちらかの引数を使用する必要があります。

${ }

編集参照を示します。

${com.sun.javaRoot}

com.sun.javaRoot変数の値を参照します。

-

同時に押すキーを連結します。

Control-A

[Ctrl]キーと[A]キーを同時に押します。

+

連続して押すキーを連結します。

Ctrl+A+N

[Ctrl]キーを押し、放してから以後のキーを続けて押します。

>

グラフィカル・ユーザー・インタフェースで選択するメニュー項目を示します。

「ファイル」→「新規」→「テンプレート」

「ファイル」メニューから「新規」を選択します。「新規」サブメニューから「テンプレート」を選択します。

ドキュメント、サポートおよびトレーニング

次のWebサイトでは、追加の情報が提供されています。

- ドキュメント(http://www.oracle.com/technetwork/indexes/documentation/index.html)

- サポート(http://www.oracle.com/us/support/systems/index.html)

- トレーニング(http://education.oracle.com)

Oracleソフトウェア・リソース

Oracle Technology Network (http://www.oracle.com/technetwork/index.html)では、Oracleソフトウェアに関連する様々なリソースを提供しています。

- ODSEEディスカッション・フォーラム(http://forums.oracle.com/forums/forum.jspa?forumID=877)、およびDirectory Servicesブログ(http://blogs.oracle.com/directoryservices/)では、技術的な問題と解決策について情報交換できます。

- Directory Servicesブログ(http://blogs.oracle.com/directoryservices/)で、最新アナウンスメントを確認してください。

- ODSEE 11gサンプル・ファイル(http://www.oracle.com/technetwork/middleware/id-mgmt/learnmore/odsee11113-examples-350399.zip)をダウンロードできます。

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

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWeb サイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

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)を参照してください。

1 Directory Server Enterprise Editionファイル・リファレンス

この章では、Directory Server Enterprise Editionのインストール後、およびサーバー・インスタンスを作成した後に存在するファイルについて説明します。

この章で示されている例は、Solarisシステムのものです。ファイルの拡張子およびパスのセパレータは、ご使用のオペレーティング・システムで異なる場合があります。この章の内容は次のとおりです。

- Directory Server Enterprise Editionのソフトウェアのレイアウト

- Directory Serverインスタンスのデフォルト・レイアウト

- Directory Proxy Serverインスタンスのデフォルト・レイアウト

1.1 Directory Server Enterprise Editionのソフトウェアのレイアウト

この項ではzipで配布されたDirectory Server Enterprise Editionをインストールした時に作成されるファイルのレイアウトについて説明します。ファイルの場所はすべて、製品をインストールした場所の相対パスで示しています。

install-path/bin/

このディレクトリには次の重要なファイルが格納されています。

install-path/bin/certutil

他のツールで使用されるNSS証明書の操作コマンド(直接使用することは想定していません)。

install-path/bin/dpadm

ローカル管理用のDirectory Proxy Serverコマンド。「dpadm」を参照してください。

install-path/bin/dpconf

LDAPを介した構成のためのDirectory Proxy Serverコマンド。「dpconf」を参照してください。

install-path/bin/dsadm

ローカル管理用のDirectory Serverコマンド。「dsadm」を参照してください。

install-path/bin/dsccagent

Directory Service Control Centerのエージェントを作成、管理するためのコマンド。「dsccagent」を参照してください。

install-path/bin/dsccmon

Directory Service Control Centerにより管理されるサーバーを監視するためのコマンド。「dsccmon」を参照してください。

install-path/bin/dsccreg

Directory Service Control Centerのレジストリを管理するためのコマンド。「dsccreg」を参照してください。

install-path/bin/dsccsetup

Directory Service Control Centerをセットアップするためのコマンド。「dsccsetup」を参照してください。

install-path/bin/dsconf

LDAPを介した構成のためのDirectory Serverコマンド。「dsconf」を参照してください。

install-path/bin/dsmig

Directory Serverのバージョン5.2からこのバージョンにマイグレーションするためのDirectory Serverコマンド。「dsmig」を参照してください。

install-path/bin/dsutil

単一ユーザーまたはロールのユーザー・メンバーを有効化または無効化するためのDirectory Serverコマンド。「dsutil」を参照してください。

install-path/bin/entrycmp

レプリカ間のディレクトリ・エントリを比較するためのDirectory Serverコマンド。「entrycmp」を参照してください。

install-path/bin/fildif

LDIFコンテンツをフィルタリングするためのDirectory Serverコマンド。「fildif」を参照してください。

install-path/bin/insync

レプリカ同期を検証するためのDirectory Serverコマンド。「insync」を参照してください。

install-path/bin/ldif

base64エンコードを追加して入力をLDIFファイルに含められるような形式にするためのDirectory Serverコマンド。「ldif」を参照してください。

install-path/bin/mmldif

LDIFコンテンツを結合するためのDirectory Serverコマンド。「mmldif」を参照してください。

install-path/bin/pwdhash

パスワード値のハッシュ形式を表示するためのDirectory Serverコマンド。「pwdhash」を参照してください。

install-path/bin/repldisc

レプリケーション・トポロジを検出するためのDirectory Serverコマンド。「repldisc」を参照してください。

install-path/bin/support_tools

Directory Serverコマンドが含まれているディレクトリ。有資格のサポート担当者の支援が得られない場合は使用しないでください。

install-path/dsrk/bin/authrate

認証率を測定するためのDirectory Serverリソース・キットのコマンド。「authrate」を参照してください。

install-path/dsrk/bin/dsmlmodify

Directory Services Markup Language (DSML) v2により、ディレクトリ・エントリを追加、変更、名前変更、移動または削除するためのDirectory Serverリソース・キットのコマンド。「dsmlmodify」を参照してください。

install-path/dsrk/bin/dsmlsearch

Directory Services Markup Language (DSML) v2により、ディレクトリ・エントリを検索するためのDirectory Serverリソース・キットのコマンド。「dsmlsearch」を参照してください。

install-path/dsrk/bin/example_files

makeldifキーワードの入力データ。

install-path/dsrk/bin/ldapcmp

2つのディレクトリのLDAPエントリを比較するためのDirectory Serverリソース・キットのコマンド。「ldapcmp」を参照してください。

install-path/dsrk/bin/ldapcompare

LDAP比較操作を実行するためのDirectory Serverリソース・キットのコマンド。「ldapcompare」を参照してください。

install-path/dsrk/bin/ldapdelete

ディレクトリ・エントリを削除するためのDirectory Serverリソース・キットのコマンド。「ldapdelete」を参照してください。

install-path/dsrk/bin/ldapmodify

LDAPを介してエントリを更新するためのDirectory Serverリソース・キットのコマンド。「ldapmodify」を参照してください。

install-path/dsrk/bin/ldappasswd

ユーザー・パスワードを変更するためのDirectory Serverリソース・キットのコマンド。「ldappasswd」を参照してください。

install-path/dsrk/bin/ldapsearch

ディレクトリを検索するためのDirectory Serverリソース・キットのコマンド。「ldapsearch」を参照してください。

install-path/dsrk/bin/ldapsubtdel

ディレクトリのサブツリーを回帰的に削除するためのDirectory Serverリソース・キットのコマンド。「ldapsubtdel」を参照してください。

install-path/dsrk/bin/ldifxform

LDIFコンテンツを再フォーマットするためのDirectory Serverリソース・キットのコマンド。「ldifxform」を参照してください。

install-path/dsrk/bin/logconv

Directory Serverのアクセス・ログを分析するためのDirectory Serverリソース・キットのコマンド。「logconv」を参照してください。

install-path/dsrk/bin/makeldif

テストおよびベンチマークのためにLDIFコンテンツを生成するDirectory Serverリソース・キットのコマンド。「makeldif」を参照してください。

install-path/dsrk/bin/modrate

LDAPディレクトリの変更パフォーマンスを測定するためのDirectory Serverリソース・キットのコマンド。「modrate」を参照してください。

install-path/dsrk/bin/searchrate

LDAPディレクトリの検索パフォーマンスを測定するためのDirectory Serverリソース・キットのコマンド。「searchrate」を参照してください。

install-path/dsrk/lib/

Directory Serverリソース・キットのコマンドにより使用されるライブラリ(直接使用することは想定していません)。

install-path/include/

Directory Serverのプラグイン・ヘッダー・ファイル

install-path/jre/

Java Runtime Environment (直接使用することは想定していません)。

install-path/lib/

Directory Server Enterprise Editionコンポーネント製品により共有されるライブラリ(直接使用することは想定していません)。

install-path/resources/dpadm

dpadmで使用されるローカライズされたリソース・ファイル。

install-path/resources/dsadmin

dsadminで使用されるローカライズされたリソース・ファイル

install-path/resources/install/

Directory Serverインスタンスのインストール・テンプレート(直接使用することは想定していません)。

install-path/resources/ldif/Example.ldif

Directory ServerのLDIFコンテンツの例

install-path/resources/ldif/Example-roles.ldif

ロールに基づいてグループ化したDirectory ServerのLDIFコンテンツの例

install-path/resources/ldif/FusionAppsSchema.ldif

Oracle FusionアプリケーションでODSEEを使用できるようにするスキーマ定義。『Oracle Directory Server Enterprise Editionリリース・ノート』のインストール・ノートに関する説明を参照してください。

install-path/resources/man/

Directory Server Enterprise Editionオンライン・リファレンス・マニュアル・ページ。Oracle Directory Server Enterprise Editionマニュアル・ページ・リファレンスも参照してください。

install-path/resources/plugins/

Directory Serverのプラグイン構成ファイル(直接使用することは想定していません)。

install-path/resources/schema/

Directory ServerインスタンスのLDAPスキーマ・テンプレート(直接使用することは想定していません)。

install-path/var/

ランタイム・ファイルのコンテナ(直接使用することは想定していません)。

1.2 Directory Serverインスタンスのデフォルト・レイアウト

この項では、Directory Serverインスタンスを作成するときに作成されるファイル・レイアウトについて説明します。instance-pathはインスタンスを作成したファイル・システム・パスです。

instance-path/alias/

NSS証明書データベース・ディレクトリ。

instance-path/alias/certmap.conf

NSS証明書マッピング構成ファイル。

instance-path/bak/

デフォルトのデータ・バックアップ・ディレクトリ。

各ディレクトリ・データベース・バックアップは固有のファイル・システム・ディレクトリに格納されます。バックアップ・ディレクトリの名前は、バックアップの日時に相当します。

instance-path/config/

サーバー構成ディレクトリ。

instance-path/config/dse.ldif

サーバー構成ファイル(直接編集することは想定していません)。

instance-path/config/schema/

LDAPスキーマ構成ファイル。「dirserv」を参照してください。

instance-path/db/

サーバー・データベース・ファイルのデフォルト・ディレクトリ。サフィックスが作成されたときに、このファイル・システム・ディレクトリに次のデータベース・ファイルが格納されます。

__db.00x

データベースにより内部で使用されるファイル。これらのファイルは移動、削除または変更しないでください。

DBVERSION

データベースのバージョンを識別するファイル。

guardian

データベースの状態に関する情報を格納するためのファイル。データベースのリカバリが必要かどうかを判別するために使用されます。

log.xxxxxxxxxx

データベース・トランザクション・ログを格納するためのファイル。

suffix

ディレクトリ・サフィックス情報を格納するファイル。このディレクトリ名はサフィックス名に由来します(たとえば、DN dc=example,dc=comにより識別されるサフィックスのデータベースは、exampleという名前のファイル・システム・ディレクトリに格納されます)。

データベースに定義されるすべての索引で、サフィックス・ディレクトリにはsuffix_indexedAttr.db3という形式の名前を持つファイルが含まれます(たとえば、dc=example,dc=comのCNの索引にはexample_cn.db3というファイル名が付きます)。

サフィックス・ディレクトリにはsuffix_id2entry.db3という名前のファイルも含まれます。suffix_id2entry.db3ファイルにはディレクトリ・データベース・エントリが含まれています。

すべての索引ファイルは、必要に応じてsuffix_id2entry.db3ファイルから再作成できます。索引ファイルを再作成するには、サフィックスを再度索引付けします。

instance-path/locks/
ロック・ファイル・ディレクトリ。

ここのサブディレクトリexports/、imports/およびserver/に格納されたロック・ファイルは、同時操作が相互に競合するのを回避します。このロック・メカニズムにより、一度に1つのサーバー・インスタンスのみ実行できます。さらに、このロック・メカニズムにより、一度に1つのdsadm import (オフライン・インポート)操作のみが許可されます。そのため、インポート中はエクスポート操作やサーバー・インスタンス操作は実行できません。

ただし、このロック制限はdsconf import (オンライン・インポート)操作には適用されません。複数のオンライン・インポートを同時に実行できます。
instance-path/logs/
デフォルトのサーバー・ログ・ディレクトリ。ここには次のファイルが格納されています。

accessログ

このファイルはDirectory Serverへのクライアント・アクセスに関する情報を記録します。accessログの詳細は、「アクセス・ログ」を参照してください。

auditログ

このファイルはDirectory Serverデータへの変更に関する情報を記録します。auditログの詳細は、「監査ログ」を参照してください。

coreファイル

デフォルトで、サーバーのcoreファイルはクラッシュ時にここでダンプされます。

errorsログ

このファイルはDirectory Server操作時にログに書き込まれるエラー・メッセージ、警告メッセージおよび情報メッセージを記録します。errorsログの詳細は、「エラー・ログ」を参照してください。

pidファイル

このファイルは実行中のサーバーのプロセス識別子を保持します。

instance-path/plugins/DSMLv2.xsd
DSMLv2スキーマ・ファイル。
instance-path/plugins/soap-env.xsd
DSMLv2のSOAPスキーマの場所。
instance-path/plugins/words-english-big.txt
厳格なパスワード・チェックに使用されるデフォルト・ディクショナリ・ファイル。
instance-path/plugins/signatures/
プラグイン署名のディレクトリ(直接使用することは想定していません)。
instance-path/tmp/
サーバーのランタイム・ファイル・ディレクトリ(直接使用することは想定していません)。

1.3 Directory Proxy Serverインスタンスのデフォルト・レイアウト

この項では、Directory Proxy Serverインスタンスを作成するときに作成されるファイル・レイアウトについて説明します。instance-pathはインスタンスを作成したファイル・システム・パスです。

instance-path/alias/

証明書データベース・ファイル(直接使用することは想定していません)。

instance-path/config/

サーバー構成ファイル(直接使用することは想定していません)。

instance-path/etc/

追加のインスタンス構成(直接使用することは想定していません)。

instance-path/logs/

デフォルトのサーバー・ログ・ディレクトリ。ここには次のファイルが格納されています。

accessログ

このファイルは、Directory Proxy Serverにより処理されるリクエストに関する情報を記録します。accessログの詳細は、「Directory Proxy Serverのアクセス・ログ」を参照してください。

errorsログ

このファイルはDirectory Proxy Server操作時にログに書き込まれるエラー・メッセージ、警告メッセージおよび情報メッセージを記録します。errorsログの詳細は、「Directory Proxy Serverのエラー・ログ」を参照してください。

instance-path/tmp/
サーバーのランタイム・ファイル・ディレクトリ(直接使用することは想定していません)。

第I部

Directory Serverのリファレンス

この部では、Directory Serverの動作について説明します。ここでの情報は説明が主になります。手順については、『Oracle Directory Server Enterprise Edition管理者ガイド』の第I部「Directory Serverの管理」を参照してください。

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

- 第2章「Directory Serverの概要」

- 第3章「Directory Server LDAPのURL」

- 第4章「Directory ServerのLDIFおよび検索フィルタ」

- 第5章「Directory Serverのセキュリティ」

- 第6章「Directory Serverの監視」

- 第7章「Directory Serverのレプリケーション」

- 第8章「Directory Serverのデータ・キャッシュ」

- 第9章「Directory Serverの索引作成」

- 第10章「Directory Serverのロギング」

- 第11章「Directory Serverのグループおよびロール」

- 第12章「Directory Serverのサービス・クラス」

- 第13章「Directory ServerのDSMLv2」

- 第14章「Directory Serverの国際化サポート」

参照情報の詳細は、Oracle Directory Server Enterprise Editionマニュアル・ページ・リファレンスを参照してください。

2 Directory Serverの概要

この章では、Directory Serverのアーキテクチャの概要を説明します。この章の内容は、次のとおりです。

- Directory Serverの概要

- Directory Serverのアーキテクチャ

2.1 Directory Serverの概要

Directory Serverの役割は、規格に準拠したLDAPアプリケーションおよびDSMLアプリケーションに、ディレクトリのデータを渡すことです。Directory Serverは、データ・セットが大容量になっても検索時間が短くなるように、カスタマイズされた二分木のデータベースにデータを格納します。

ディレクトリは、オブジェクト指向データベースです。ディレクトリは、エントリと呼ばれるデータ・オブジェクトを、DITと呼ばれるディレクトリ情報ツリーに編成します。各エントリは、uid=bjensen,ou=people,dc=example,dc=comなどの識別名で識別されます。識別名によって、ディレクトリ情報ツリーでのエントリの場所が識別されます。たとえば、uid=bjensen,ou=people,dc=example,dc=comは、ツリーのdc=example,dc=com部分のou=peopleブランチ上にあるBarbara Jensenのユーザー・エントリです。

各ディレクトリには属性があります。人に関するエントリの場合、それらの属性は、名前、電話番号、電子メール・アドレスなどを反映している場合があります。属性には、少なくとも1つのタイプ名があり、これはその属性の名前です。たとえば、人エントリは、属性surname (短い名前snで呼ぶことも可能)を持つことができます。属性は、1つ以上の値を持つこともできます。たとえば、Barbara JensenがQuentin Cubbinsと結婚し、Quentinの苗字を使用する場合、彼女のエントリは、sn: Jensenおよびsn: Cubbinsを持つことができます。

ディレクトリは、その属性の値に基づいてエントリを検索する際に高速になるように設計されています。たとえば、「dc=example,dc=com以下にある苗字がJensenのすべてのエントリを検索する」と問い合わせることができます。この高速参照機能は、頻繁に読み取る必要のある情報を格納するアプリケーションに対して、ディレクトリをよく適した状態にします。したがって、ディレクトリは、電話や電子メールの情報に適したデータ・ストアです。さらに、ディレクトリは、認証の資格証明、アイデンティティ情報およびアプリケーションの構成データの処理にも適しています。

また、Directory Serverは、ディレクトリ内の情報が変更される際の高い更新率に対応するように設計されています。今日、多くのディレクトリ・デプロイメントのサイズは、更新を適切に処理することは参照を処理するのと同じぐらい重要であることを意味します。

Directory Serverでは、多数のディレクトリ関連の標準およびRFCがサポートされています。Directory Serverでは、高可用性のためのネットワークを介した高速データ・レプリケーションが可能です。Directory Serverでは、サーバーを再起動することなく包括的に構成できます。さらに、Directory Serverでは、ディレクトリ・データへのアクセスに対する広範囲にわたる制御が可能です。

Directory Serverの機能のリストは非常に長いため、簡単な紹介では説明できません。『Oracle Directory Server Enterprise Edition評価ガイド』に詳細なリストが含まれています。このリファレンスのこの部のその他の章は、多くの機能の詳細な理解に役立ちます。

2.2 Directory Serverのアーキテクチャ

この項では、Directory Serverの主要概念について、Directory Serverをインストールおよび管理する必要のある担当者の視点から簡潔に説明します。この項の内容は次のとおりです。

- ソフトウェア・インストールとサーバー・インスタンスの比較

- クライアント・アプリケーションとの通信

- Directory Serverの構成

- Directory Serverでのデータ・ストレージ

- ディレクトリ情報ツリーでのデータ構造

- サーバー・インスタンス間のデータ・レプリケーション

- Directory Serverでのアクセス制御

2.2.1 ソフトウェア・インストールとサーバー・インスタンスの比較

Directory Serverソフトウェアのインストールごとに、複数のサーバー・インスタンスを作成できます。ソフトウェアをインストールしたファイル・システム上にサーバー・インスタンスを作成できますが、ソフトウェアとインスタンスを併置するために必要なものはありません。

インストールするDirectory Serverソフトウェアには、実際のサーバーを作成、実行および管理するために必要な実行可能ファイル、テンプレート・データおよびサンプル・ファイルが含まれています。ソフトウェアは実際のサーバーとは分離されているため、サーバー・データを変更することなく、ソフトウェアにパッチまたはサービス・パックを適用できます。そのため、各サーバー・インスタンスにパッチを適用する必要はありませんが、そのかわり、ソフトウェア・インストールにのみ必要です。

Directory Serverインスタンスは、ディレクトリ・クライアント・アプリケーションにサービスを提供するために必要な構成データおよびディレクトリ・データを保持します。本番システムでは、サーバーのユーザー・アイデンティティを慎重に制御しますが、通常システム上では、Directory Serverインスタンスをユーザーとして作成および実行できます。その後、ディレクトリ・データは、インスタンスを作成したユーザーに属します。

第1章「Directory Server Enterprise Editionのファイル参照」では、「Directory Server Enterprise Editionのソフトウェア・レイアウト」が「Directory Serverインスタンスのデフォルト・レイアウト」から明確に分離されていることを確認します。特に、ドキュメントでは、ソフトウェア・インストールを参照するときはinstall-pathですが、サーバー・インスタンスを参照するときはinstance-pathと記載されていることに注意してください。

2.2.2 クライアント・アプリケーションとの通信

Directory Serverは、構成したポート番号上でLDAPおよびDSMLクライアント・アプリケーション・トラフィックをリスニングします。Directory Serverは、サーバーの起動直後にLDAP接続をリスニングします。DSMLサービスを構成した場合は、Directory ServerはHTTPを介したDSML接続のみをリスニングします。

デフォルトでDirectory Serverは、インスタンスがrootによって作成された場合はポート389上のLDAP接続をリスニングし、インスタンスがroot以外によって作成された場合は、1389をリスニングします。デフォルトでDirectory Serverは、インスタンスがrootによって作成された場合はポート636上のSSLを介したLDAP接続をリスニングし、インスタンスがroot以外によって作成された場合は、1636をリスニングします。DSML/HTTPポート番号はデフォルトでは定義されていません。かわりに、DSMLサービスを有効化するときに、ポート番号を指定します。

クライアント・アプリケーションがDirectory Serverを使用できるようにするには、静的IPアドレスを使用してホスト上にインスタンスを作成します。ホスト名も通常、DNSで参照されます。クライアント・アプリケーションがディレクトリにアクセスするには、少なくとも2つの情報が必要です。

1. Directory Serverが実行されるシステムのホスト名、または少なくともIPアドレス。

2. Directory Serverがクライアント接続をリスニングするポート番号。

LDAPクライアントおよびサーバーは、通常、リクエストごとに新しい接続を開きません。LDAPモデルでは、クライアントはその他の操作を実行する前に、認証のためにサーバーに接続します。この接続および認証プロセスは、バインディングと呼ばれます。クライアント・アプリケーションは資格証明を使用してバインドできますが、匿名でバインドすることもできます。Directory Serverでは、状況に応じて、既知および匿名のクライアントの両方にアクセスを構成できます。クライアント・アプリケーションは接続を開いたままにもできますが、再度バインドして、認証アイデンティティを変更します。この技術によって、新しい接続を作成するためのコストを削減できます。

バインドが実行され、クライアントが認証されると、クライアントは次の操作をリクエストできます。

add

新しいディレクトリ・エントリを追加します。

compare

属性値が指定された値と同じかどうかを確認します。

delete

ディレクトリ・エントリを削除します。

modify

ディレクトリ・エントリの1つ以上の属性を変更します。

modDN

ディレクトリ・エントリの識別名を変更します。

この操作は、ディレクトリ・エントリをディレクトリ情報ツリーの1つの部分から別の部分に移動するために行います。たとえば、uid=bjensen,ou=employees,dc=example,dc=comからuid=bjensen,ou=people,dc=example,dc=comに移動できます。

ou=people,dc=example,dc=comなどの親エントリを移動する場合は、Directory Serverはその親エントリのすべての子エントリも移動する必要があるため、操作に非常に時間がかかる場合があります。

modRDN

ディレクトリ・エントリの相対識別名を変更します。

相対識別名は、ディレクトリ情報ツリーと同じレベルで、他のエントリからディレクトリ・エントリを識別するために使用される属性値です。

この操作は、ディレクトリ・エントリの名前を変更するために行います。たとえば、uid=bjensen,ou=employees,dc=example,dc=comからuid=bcubbins,ou=people,dc=example,dc=comに名前を変更できます。

この操作は、modDNの特別なケースです。通常、modRDN操作は比較的高速です(ただし、リーフ・エントリのみの変更に関係する場合)。

search

フィルタと一致する属性値を持つディレクトリ情報ツリーの指定した点以下にあるすべてのディレクトリ・エントリを検索します。

検索フィルタには、1つ以上の属性の特性を指定できます。たとえば、苗字がJensenのエントリを検索するには、LDAPフィルタ(sn=Jensen)を使用します。苗字がJensenでユーザーIDが文字Bで始まるエントリを検索するには、LDAPフィルタ(&(sn=Jensen)(uid=b*))を使用します。

操作の実行が終了したら、クライアントをバインド解除できます。バインド解除後、クライアントとサーバーによって接続が切断されます。クライアント・アプリケーションは、時間がかかり過ぎている検索などの操作も中止できます。

Directory Serverは、多くのクライアント接続を同時に処理できます。接続を処理するために、Directory Serverは、空いているファイル記述子を消費し、多数のスレッドを管理します。サーバー構成を使用して、Directory Serverで使用可能なシステム・リソースを制限できます。詳細は、『Oracle Directory Server Enterprise Editionデプロイメント・プランニング・ガイド』の第6章「システム特性のチューニングとハードウェアのサイズ指定」を参照してください。

2.2.3 Directory Serverの構成

Directory Serverは、サーバー・インスタンスの構成データをファイルに格納しますが、構成データにはLDAPを介してアクセスすることもできます。

instance-path以下に格納されるファイルは次のとおりです。Directory Serverは、LDAPスキーマ(どのディレクトリ・エントリを含むことができるかを定義)をinstance-path/config/schema/に格納します。スキーマに関する参照情報は、Oracle Directory Server Enterprise Editionマニュアル・ページ・リファレンスを、スキーマの管理手順は、『Oracle Directory Server Enterprise Edition管理者ガイド』の第11章「Directory Serverのスキーマ」を参照してください。Directory Serverは、その他の構成情報をdse.ldifファイルであるinstance-path/config/dse.ldifに格納します。このファイルは手動で更新しないでください。

LDAPを介して、スキーマ情報はcn=schemaで利用できます。その他の構成情報はcn=configで利用できます。実際は、cn=configディレクトリ以下のデータは通常更新しません。かわりに、WebベースのDirectory Service Control Centerまたはdsconfコマンドを使用します。Directory Service Control Centerおよびdsconfコマンドはどちらも、LDAPを介してDirectory Serverを変更します。さらに、これらを使用することで、LDAP変更操作を使用した複雑な構成の調整の多くを行わずに済みます。

ほとんどすべてのDirectory Server製品のドキュメントは、Directory Serverの構成に焦点を当てています。『Oracle Directory Server Enterprise Edition管理者ガイド』では、コマンドライン構成ツールを使用した多様なタスクを完了するための詳細な方法が記載されています。Directory Service Control Centerのオンライン・ヘルプは、Directory Service Control Centerのインタフェースで直感的な理解が難しいような場合に、正しい手順に戻るのに役立ちます。

2.2.4 Directory Serverでのデータ・ストレージ

Directory Serverは、ディレクトリ・データを保存するために多数のバイナリツリー・データベースを管理します。デフォルトでは、データベース・ファイルはinstance-path/db/以下に格納されます。通常、これらのファイルは変更または移動しません。

instance-path/db/ディレクトリの内容を確認すると、データベース・ログ・ファイルが見つかります。また、サーバーが管理する各データベースにはサブディレクトリもあります。たとえば、instance-path/db/example/には、dc=example,dc=comにあるディレクトリ・エントリ用のデータが保存されています。このファイルを確認すると、苗字属性値のexample_sn.db3などの多数のデータベース索引があることがわかります。example_id2entry.db3ファイルには、ディレクトリ・エントリ情報が含まれていることもわかります。必要に応じて、これらのファイルの情報を暗号化するようにDirectory Serverを構成できます。

クライアント・アプリケーションの観点から、Directory Serverは、ディレクトリ情報ツリーに配置されたディレクトリ・エントリとして格納されたディレクトリ・データを表示します。Directory Serverは、エントリをすばやく取得するために、属性値索引を使用します。Directory Serverが保持する索引を構成できます。

ディレクトリ・データのバックアップ手順については、『Oracle Directory Server Enterprise Edition管理者ガイド』の第8章「Directory Serverのバックアップとリストア」を参照してください。索引の構成手順については、『Oracle Directory Server Enterprise Edition管理者ガイド』の第12章「Directory Serverの索引作成」を参照してください。ディレクトリ・データのバックアップおよび索引の構成は、Directory Service Control Centerを使用して行うこともできます。

2.2.5 ディレクトリ情報ツリーでのデータ構造

ディレクトリ情報ツリー(DIT)は、クライアント・アプリケーションがデータを参照できるようにディレクトリ・データを構成する方法を提供します。

2.2.5.1 DITの用語

適切に構成されたDITは、次を提供します。

- 簡略化されたディレクトリ・データの保持

- レプリケーション・ポリシーおよびアクセス制御の作成での柔軟性

- ディレクトリを使用するアプリケーションに対するサポート

- ユーザーに対する簡略化されたディレクトリ・ナビゲーション

DIT構成は、階層化LDAPモデルに従います。たとえばDITは、データをグループごと、人ごとまたは地理的な場所ごとに編成します。また、複数のサーバー全体でのデータのパーティション化の方法についても定義します。

DIT設計は、レプリケーション構成およびデータを分散するためのDirectory Proxy Serverの使用方法にも影響を与えます。DITの一部をレプリケートまたは分散する場合は、設計時に、Directory Proxy Serverのレプリケーションおよび要件を検討します。さらに、設計時に、ブランチ・ポイントでのアクセス制御が必要かどうかについても決定します。

DITは、サフィックス、サブサフィックスおよび結合されたサフィックスを単位として定義されます。サフィックスは、コンテンツ全体が管理タスクの単位として処理されるブランチまたはサブツリーです。索引作成はサフィックス全体に定義され、サフィックス全体は単一操作で初期化できます。また、サフィックスは通常、レプリケーションの単位です。同じ方法でアクセスおよび管理する必要のあるデータは、同じサフィックスにある必要があります。サフィックスはディレクトリ・ツリーのルートに配置でき、ここはルート・サフィックスと呼ばれます。

データはサフィックス・レベルでのみパーティション化できるため、複数のサーバー間にデータを分散するには、適切なディレクトリ・ツリー構造が必要です。

次の図に、2つのルート・サフィックスを持つディレクトリを示します。それぞれのサフィックスは、異なる企業のエンティティを表します。

図2-1 1つのDirectory Server内の2つのルート・サフィックス

「図2-1 単一Directory Server内の2つのルート・サフィックス」の説明

サフィックスは、別のサフィックスのブランチである場合があり、その場合、これはサブサフィックスと呼ばれます。親サフィックスには、管理操作用にサブサフィックスの内容は含まれません。サブサフィックスは、その親とは独立して管理されます。LDAP操作によって、サフィックスに関する情報が含まれないため、ディレクトリ・クライアントは、エントリがルート・サフィックスの一部なのかサブサフィックスの一部なのかを認識しません。

次の図に、大規模な企業エンティティの1つのサフィックスと複数のサブサフィックスを持つディレクトリを示します。

図2-2 複数のサブサフィックスを持つ1つのルート・サフィックス

「図2-2 複数のサブサフィックスを持つ1つのルート・サフィックス」の説明

サフィックスは、サーバー内の個々のデータベースに対応します。ただし、データベースおよびそのファイルは、サーバーによって内部的に管理され、データベース用語は使用されません。

カスケード・チェーンの特別な場合では、結合されたサフィックスはリモート・サーバー上などの別の結合されたサフィックスを参照する場合があります。各サーバーが操作を転送し、最終的にクライアントのリクエストを処理するサーバーに結果が戻されます。

2.2.6 サーバー・インスタンス間のデータ・レプリケーション

Directory Serverでは、必要な数のサーバー・インスタンス間でディレクトリ・データをレプリケートできます。Directory Serverのレプリケーションは、1つのサーバーから別のサーバーへ更新操作をリプレイするLDAP拡張操作として動作します。Directory Serverのレプリケーションのプロトコルは、ネットワーク間ですばやく動作するために最適化されています。また、このプロトコルは、2つの異なるサーバー・インスタンスで同じデータが同時に変更された場合の競合を解消するために最適化されています。

Directory Serverのレプリケーションの単位はサフィックスです。2つのサーバー間のレプリケーション承諾は、dc=example,dc=comなどのディレクトリ情報ツリーのベース・エントリの下にあるすべてのディレクトリ・エントリを処理します。レプリケーションのための各承諾は、ポイント間で設定されます。一方では、ポイント間の承諾は、ネットワークがパーティション化されているときにレプリケーションが単一点障害にならないようにします。他方で、ポイント間の承諾は、レプリカの数が増えると管理が複雑になります。幸いにも、Directory Service Control Centerでは、その複雑性の多くが処理されます。Directory Service Control Centerでは、共通ディレクトリ・サービスを提供するレプリカのグループを管理できます。

タイミング、優先度およびレプリケートするデータを構成できます。また、更新と参照の両方を受け入れるために、一部のサーバー(マスターと呼ばれる)も構成できます。参照のみを受け入れるためのその他のサーバー(コンシューマと呼ばれる)を構成できます。さらに、更新が発生したときに追従する必要のあるクライアント・アプリケーションに対して、LDAPを介して更新情報を公開できます。レプリケーションの詳細は、第7章「Directory Serverのレプリケーション」を参照してください。レプリケーションの構成手順については、『Oracle Directory Server Enterprise Edition管理者ガイド』の第10章「Directory Serverのレプリケーション」を参照してください。

2.2.7 Directory Serverでのアクセス制御

Directory Serverでは、ディレクトリ・エントリに配置されたaci属性を使用して機能するアクセス制御メカニズムが提供されます。ACIは、アクセス制御命令を表します。

ACIは、ユーザーのバインド・アイデンティティに基づいて評価されます。したがってACIは、ディレクトリにバインド可能なすべてのユーザーに対して評価できます。また、ACIは、バインド資格証明を提供していない匿名ユーザーに対しても適用できます。バインド・アイデンティティについてのルールでは、どのユーザーかだけでなく、ユーザーの接続元システム、1日のうちの接続時間帯または使用する認証方式も指定できます。

有効範囲内のエントリに適用するためにACIを構成します。有効範囲内に存在できるエントリには、ACIを保持するエントリで始まるディレクトリ情報ツリーのブランチ上にあるエントリが含まれます。Directory Serverでは、多数の異なる基準に従って適用されるACIを構成できます。また、Directory Serverでは、アクセスを許可するためだけでなく、アクセスを拒否するためにもACIを構成できます。

ACIは、許可および拒否する操作を指定できます。たとえば、通常は多数のユーザーによる情報の読取りを許可しますが、ごくわずかのユーザーに対してのみディレクトリ・データの更新および追加を許可します。

Directory Serverのアクセス制御の詳細は、「Directory Serverのアクセス制御の提供方法」を参照してください。アクセス制御の構成手順については、『Oracle Directory Server Enterprise Edition管理者ガイド』の第6章「Directory Serverのアクセス制御」を参照してください。

3 Directory ServerのLDAP URL

LDAP問合せを表現する1つの方法は、Directory Serverのホスト・マシン、および検索用にDNやフィルタを指定するためのURLを使用するというものです。Directory ServerはLDAP URLとして送信された問合せに応答し、結果を表示するHTMLページを戻します。匿名検索が許可された場合、このような方法で、Webブラウザはディレクトリの検索を実行します。また、Directory Serverのリフェラルを管理する場合、またはアクセス制御命令を管理する場合に、LDAP URLを使用してターゲット・エントリを指定できます。

LDAP URLの詳細は、次の項を参照してください。

- LDAP URLのコンポーネント

- 安全でない文字のエスケープ

- LDAP URLの例

3.1 LDAP URLのコンポーネント

LDAP URLの構文は、次のようになっています。

ldap[s]://hostname:port/base_dn?attributes?scope?filter

ldap://を指定すると、標準LDAPを使用して、LDAPサーバーに接続します。ldaps://を指定すると、LDAP over SSLを使用してLDAPサーバーに接続します。

表3-1 LDAP URLのコンポーネント

コンポーネント

説明

hostname

LDAPサーバー名(またはドット区切りのIPアドレス)。次に例を示します。

ldap.example.comまたは192.168.1.100

port

LDAPサーバーのポート番号。

ポートが指定されていない場合は、標準LDAPポート(389)またはLDAPSポート(636)が使用されます。

base_dn

ディレクトリにおけるエントリの識別名(DN)。このDNによって、検索の開始点であるエントリを識別します。

ベースDNが指定されていない場合、ディレクトリ・ツリーのルートから検索が開始されます。

attributes

戻される属性。複数の属性を指定するには、カンマを使用して属性を区切ります。たとえば、"cn,mail,telephoneNumber"などです。

URLで属性が指定されていない場合、すべての属性が戻されます。

scope

検索の有効範囲。次の値のいずれかを指定できます。

- baseによって、URLで指定されている識別名(base_dn)のみに関する情報を取得します。

- oneによって、URLで指定されている識別名(base_dn)の1レベル下のエントリに関する情報を取得します。ベース・エントリはこの範囲には含まれません。

- subによって、URLで指定されている識別名(base_dn)の配下のすべてのレベルのエントリに関する情報を取得します。ベース・エントリは、この範囲に含まれます。
範囲が指定されていない場合、サーバーはbase検索を実行します。

filter

指定された検索範囲内のエントリに適用するための、検索フィルタ。

フィルタが指定されていない場合、サーバーはフィルタobjectClass=*を使用します。

次のコンポーネント、すなわちattributes、scopeおよびfilterは、URLにおける位置によって識別されます。コンポーネントを指定しない場合は、フィールドを区切るために疑問符を含める必要があります。疑問符が2つ連続する場合、すなわち??は、属性が指定されていないことを示します。

たとえば、"(sn=Jensen)"に一致するエントリのすべての属性を戻す"dc=example,dc=com"からのサブツリー検索開始を指定するには、次のLDAP URLを使用します。

ldap://ldap.example.com/dc=example,dc=com??sub?(sn=Jensen)

URLで特定の属性が識別されていない場合、その検索におけるすべての属性が戻されます。

3.2 安全でない文字のエスケープ

URLにおける安全でない文字は、特定の文字列で表現される必要があります。次の表はURL内で安全でない文字をリスト表示しており、安全でない文字のかわりに使用するための、関連するエスケープ文字を示しています。

表3-2 URLにおいて安全でない文字

安全でない文字

エスケープ文字

スペース

%20

<

%3c

\>

%3e

"

%22

#

%23

%

%25

{

%7b

}

%7d

|

%7c

\\

%5c

^

%5e

~

%7e

[

%5b

]

%5d

"

%60

3.3 LDAP URLの例

LDAP URLの構文には、資格証明やパスワードを指定する方法は含まれていません。LDAP URLをサポートするLDAPクライアントによって認証メカニズムが提供されるにもかかわらず、LDAP URLを介して開始される検索リクエストは認証されません(匿名)。この項では、LDAP URLの例を示します。

例3-1 エントリのベース検索

次のLDAP URLで、識別名がdc=example,dc=comのエントリのベース検索を指定します。

ldap://ldap.example.com/dc=example,dc=com

- ポート番号が指定されていないため、標準LDAPポート番号389が使用されます。

- URLで属性が指定されていないため、この検索ではすべての属性が戻されます。

- 検索範囲が指定されていないため、この検索は、ベース・エントリのdc=example,dc=comに限定されます。

- フィルタが指定されていないため、このディレクトリはデフォルト・フィルタのobjectclass=*を使用します。

例3-2 エントリのpostalAddress属性の取得

次のLDAP URLで、DNがdc=example,dc=comであるエントリのpostalAddress属性を取得します。

ldap://ldap.example.com/dc=example,dc=com?postalAddress

- 検索範囲が指定されていないため、この検索は、ベース・エントリのdc=example,dc=comに限定されます。

- フィルタが指定されていないため、このディレクトリはデフォルト・フィルタのobjectclass=*を使用します。

例3-3 エントリのcnおよびmail属性の取得

次のLDAP URLでは、Barbara Jensenのcnおよびmail属性を取得します。

ldap://ldap.example.com/cn=Barbara%20Jensen,dc=example, dc=com?cn,mail

- 検索範囲が指定されていないため、この検索は、ベース・エントリのcn=Barbara Jensen,dc=example,dc=comに限定されます。

- フィルタが指定されていないため、このディレクトリはデフォルト・フィルタのobjectclass=*を使用します。

例3-4 dc=example,dc=com配下の姓Jensenの取得

次のLDAP URLは、姓がJensenでdc=example,dc=com配下のあらゆるレベルのエントリの検索を指定します。

ldap://ldap.example.com/dc=example,dc=com??sub?(sn=Jensen)

- URLで属性が指定されていないため、この検索ではすべての属性が戻されます。

- 検索範囲がsubであるため、この検索は、ベース・エントリのdc=example,dc comとベース・エントリ配下のすべてのレベルのエントリを網羅します。

例3-5 dc=example,dc=comより1レベル下のすべてのエントリに関するオブジェクト・クラスの取得

次のLDAP URLは、dc=example,dc=comより1レベル下のすべてのエントリについて、オブジェクト・クラス検索を指定します。

ldap://ldap.example.com/dc=example,dc=com?objectClass?one

- 検索範囲がoneであるため、この検索は、ベース・エントリのdc=example,dc=comより1レベル下のすべてのエントリを網羅します。この検索範囲には、ベース・エントリは含まれません。

- フィルタが指定されていないため、このディレクトリはデフォルト・フィルタのobjectclass=*を使用します。

4 Directory Server LDIFおよび検索フィルタ

Directory ServerはLDAP Data Interchange Format (LDIF)を使用して、ディレクトリおよびそのエントリをテキスト形式で記述します。LDIFを使用して、初期ディレクトリ・データベースを構築したり、ディレクトリに多数のエントリを追加することができます。またLDIFを使用して、ディレクトリ・エントリへの変更を記述することもできます。多くのコマンドライン・ユーティリティは、入力または出力についてはLDIFに基づいています。

すべてのディレクトリ・データはユニコードのUTF-8エンコーディングを使用することによって格納され、したがってLDIFファイルはUTF-8でエンコードされる必要があります。

この章では、ディレクトリの検索およびLDAP検索フィルタについても説明します。

LDIFおよびディレクトリの検索の詳細は、次の項を参照してください。

- LDIFファイル形式

- LDIFのディレクトリ・エントリ

- LDIFを使用してディレクトリの定義をするためのガイドライン

- 複数言語での情報の格納

- LDIF入力を行うためのガイドライン

- ディレクトリの検索

4.1 LDIFファイル形式

LDIFファイルは、空白行によって区切られた1つ以上のディレクトリ・エントリから構成されます。各LDIFエントリは、次の部分から構成されています。

- エントリID(オプション)

- 識別名(必須)

- 1つ以上のオブジェクト・クラス

- 複数の属性定義

LDIF形式は、RFC 2849で定義されています。

次の例は、LDIFの基本的なディレクトリ・エントリを示しています。

例4-1 LDIFのディレクトリ・エントリ

dn: distinguished_name
objectClass: object_class
objectClass: object_class
...
attribute_type[;subtype]: attribute_value
attribute_type[;subtype]: attribute_value
...

他のすべての属性およびオブジェクト・クラスは、オプションです。オブジェクト・クラスおよび属性は、任意の順序に指定できます。コロンの後ろのスペースは、任意です。

次の表では、LDIFファイルのフィールドについて説明します。

表4-1 LDIFのフィールド

フィールド

定義

[id]

オプション。エントリIDを示す、正の10進数。データベース作成ツールによって、このIDが生成されます。この値を、ユーザー自身で追加または編集しないでください。

dn: distinguished_name

エントリの識別名。

objectClass: object_class

このエントリで使用するオブジェクト・クラス。このオブジェクト・クラスは、エントリについて許可され、必要である属性またはスキーマのタイプを識別します。

attribute_type

エントリで使用される記述属性。この属性は、スキーマで定義されます。

[subtype]

オプション。次のタイプの1つのサブタイプ。

- 言語(属性;lang-サブタイプ)によって、対応する属性値が記述されている言語を識別

- バイナリ(属性;binary)によって、属性値がバイナリかどうかを識別

- 発音(属性;phonetic)によって、当該属性値がある属性値の発音であるかどうかを識別

attribute_value

属性タイプとともに使用される属性値。

ディレクトリ内のエントリに対する変更を示すLDIF構文は、前述の構文とは異なります。

4.1.1 LDIFにおける行の継続

LDIFを指定すると、改行および行の継続、または1スペースによって行の継続位置をインデントすることによって行を折り返すことができます。たとえば、次の2つの文は同一です。

dn: cn=Babs Jensen,dc=example,dc=com

dn: cn=Babs J
ensen,dc=exam
ple,dc=com

LDIF行の改行および継続は必須ではありません。ただし、LDIFファイルが読みやすくなります。

4.1.2 LDIFにおけるバイナリ・データ

次の方法のいずれかを使用して、LDIFにおけるバイナリ・データを表すことができます。

- 標準LDIF表記で、より小さいの意の、<記号

- コマンドライン・ユーティリティでldapmodify (-bオプションあり)

- Base 64エンコード

4.1.2.1 標準のLDIF表記を使用したバイナリ・データの表現

次の例では、バイナリ・データについての標準のLDIF表記が示されています。

jpegphoto:< file:/path/to/photo

この例ではパスは、サーバーではなくクライアントに関連しています。標準の表記を使用するには、ldapmodify -bパラメータを指定する必要はありません。ただし、次の行をLDIFファイルの最初またはLDIFのUPDATE文に追加する必要があります。

version:1

たとえば次のように、ldapmodifyコマンドを使用できます。

$ ldapmodify -D userDN -w passwd
version: 1
dn: cn=Barbara Jensen,ou=People,dc=example,dc=com
changetype: modify
add: userCertificate
userCertificate;binary:< file:BabsCert

4.1.2.2 ldapmodify -bコマンドを使用したバイナリ・データの表現

Directory Serverの以前のバージョンとの下位互換性については、ldapmodify -bコマンドを使用して、バイナリ・データを表現できます。ただし可能な場合は、標準のLDIF表記を使用してバイナリ・データを表現します。

Directory Serverは、-bパラメータのあるldapmodifyコマンドおよび次のLDIF表記を受け入れます。

jpegphoto: /path/to/photo

この表記は、属性値がスラッシュで始まる場合に、ldapmodifyコマンドがバイナリ値に関する参照ファイルを読み取る必要があることを示しています。

4.1.2.3 Base 64エンコードを使用したバイナリ・データの表現

Base 64でエンコードされたデータは、この例で示されているように::記号で表現されます。

jpegPhoto:: encoded_data

バイナリ・データに加えて、次の値もBase 64でエンコードされている必要があります。

- セミコロン;で始まるすべての値、またはスペース

- ASCII以外のデータを含むすべての値(新規行を含む)

次のように、-bパラメータのあるldifコマンドを使用して、バイナリ・データをLDIF形式に変換します。

$ ldif -b attributeName

ldifコマンドの使用方法の詳細は、ldifについての説明のマニュアル・ページを参照してください。

前述の例においてattributeNameは、ユーザーがバイナリ・データを提供する属性名です。バイナリ・データは標準入力から読み込まれ、この結果は標準出力に書き込まれます。リダイレクト演算子を使用して、入力および出力ファイルを選択します。

このコマンドによって、あらゆる入力が取得され、正しい行の継続および適切な属性情報が書式設定されます。このコマンドによって、入力にBase 64エンコードが必要がどうかも判断されます。次の例では、jpegPhotoと命名された属性について、JPEGイメージを含むバイナリ・ファイルを取得してLDIF形式に変換します。この出力はout.ldifに保存されます。

$ ldif -b jpegPhoto < aphoto.jpg> out.ldif

-bオプションによって、ユーティリティが入力全体を単一のバイナリ値として解釈することを指定します。-bオプションがない場合、各行は個別の入力値としてみなされています。

出力ファイルを編集して、バイナリ値を含むディレクトリ・エントリの作成または変更が必要なLDIF文を追加できます。たとえば、テキスト・エディタでファイルout.ldifを開いて、ファイルの最上部に次の行を追加できます。

dn: cn=Barbara Jensen,ou=People,dc=example,dc=com
changetype: modify
add: jpegPhoto
jpegPhoto:: encoded_data

この例ではencoded_dataは、コマンドによって作成されたout.ldifファイルの内容を示しています。

4.2 LDIFのディレクトリ・エントリ

この項の内容は次のとおりです。

- LDIFにおける組織エントリ

- LDIFにおける組織単位エントリ

- LDIFにおける組織の個人エントリ

4.2.1 LDIFにおける組織エントリ

ディレクトリには、1つ以上の組織エントリが含まれる場合が多くなっています。通常、組織エントリは、ディレクトリにおける最初または、最上位のエントリです。組織エントリは多くの場合、ディレクトリのサフィックスに対応します。たとえば多くの場合、サフィックスo=example.comを使用するために定義されたディレクトリには、o=example.comと命名された組織エントリがあります。

組織エントリを定義するLDIFは、次のように表示されます。

dn: distinguished_name
objectClass: top
objectClass: organization
o: organization_namelist_of_optional_attributes...

次は、LDIF形式における組織エントリの例です。

dn: o=example.com
objectclass: top
objectclass: organization
o: example.com Corporation
description: Fictional company for example purposes
telephonenumber: 555-5555

次の例における組織名には、カンマが使用されています。

dn: o=example.com Chile\, S.A.
objectclass: top
objectclass: organization
o: example.com Chile\, S.A.
description: Fictional company for example purposes
telephonenumber: 555-5556

次の表には、組織エントリの各要素が記載されています。

表4-2 LDIFにおける組織エントリ

LDIF要素

説明

dn: distinguished_name

必須。エントリの識別名を指定します。

objectClass: top

必須。最上位のオブジェクト・クラスを指定します。

objectClass: organization

組織のオブジェクト・クラスを指定します。この行は、組織としてエントリを定義します。

o: organization_name

組織の名前を指定します。組織名にカンマが含まれる場合、単一のバックスラッシュによってカンマをエスケープするか、または組織の引数全体を引用符で囲む必要があります。ただしUNIXシェルで作業している場合は、バックスラッシュもエスケープする必要があります。したがって、バックスラッシュを2つ使用する必要があります。たとえばサフィックスをexample.com Bolivia, S.A.に設定するには、o: example.com Bolivia\, S.A.を入力します。

list_of_attributes

このエントリに関して保持する属性(オプション)のリストを指定します。

4.2.2 LDIFにおける組織単位エントリ

ディレクトリ・ツリーにおいて、組織単位は主なサブディレクトリを示しています。ディレクトリ・ツリーには通常、複数の組織単位が含まれています。組織単位エントリを定義するLDIFファイルは、次のように表示されます。

dn: distinguished_name
objectClass: top
objectClass: organizationalUnit
ou: organizational_unit_namelist_of_optional_attributes...

次の例は、LDIF形式における組織単位エントリを示しています。

dn: ou=people, o=example.com
objectclass: top
objectclass: organizationalUnit
ou: people
description: Fictional organizational unit for example purposes

次の表では、組織単位エントリの各要素を定義しています。

表4-3 LDIFにおける組織単位エントリ

LDIF要素

説明

dn: distinguished_name

必須。エントリの識別名を指定します。

DNにカンマが含まれている場合は、バックスラッシュ(\)でカンマをエスケープする必要があります。次に例を示します。

dn: ou=people,o=example.com Bolivia\,S.A.

objectClass: top

必須。topオブジェクト・クラスを指定します。

objectClass: organizationalUnit

organizationalUnitオブジェクト・クラスを指定します。この行は、organizationalUnit.としてエントリを定義します。

ou: organizational_unit_name

組織単位の名前を含む属性を指定します。

list_of_attributes

このエントリに関して保持する属性(オプション)のリストを指定します。

4.2.3 LDIFにおける組織の個人エントリ

ディレクトリ内のエントリの多くは、組織の人々を示しています。LDIFでは、組織の個人の定義は次のようになっています。

dn: distinguished_name
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: common_name
sn: surname
list_of_optional_attributes

次の例は、LDIF形式における組織の個人エントリを示しています。

dn: uid=bjensen,ou=people,o=example.com
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
cn: Babs Jensen
sn: Jensen
givenname: Babs
uid: bjensen
ou: Marketing
ou: people
description: Fictional person for example purposes
telephonenumber: 555-5557
userpassword: {sha}dkfljlk34r2kljdsfk9

次の表では、LDIFの個人エントリの各要素を定義しています。

表4-4 LDIFにおける組織の個人エントリ

LDIF要素

説明

dn: distinguished_name

必須。エントリの識別名を指定します。

DNにカンマが含まれている場合は、バックスラッシュ(\)でカンマをエスケープする必要があります。たとえばdn:uid=bjensen,ou=people,o=example.com Bolivia\,S.A.となります。

objectClass: top

必須。topオブジェクト・クラスを指定します。

objectClass: person

personオブジェクト・クラスを指定します。LDAPクライアントの多くが、個人または組織の個人について検索操作を実行中に、このオブジェクト・クラスの指定を必要とするため、この指定は行う必要があります。

objectClass:organizationalPerson

organizationalPersonオブジェクト・クラスを指定します。LDAPクライアントの一部は、組織の個人について検索操作を実行中にこのオブジェクト・クラスの指定を必要とするため、この指定は行う必要があります。

objectClass: inetOrgPerson

inetOrgPersonオブジェクト・クラスを指定します。inetOrgPersonオブジェクト・クラスは最大範囲の属性を含んでいるため、組織の個人エントリの作成にお薦めです。uid属性はこのオブジェクト・クラスによって必要とされ、このオブジェクト・クラスを含むエントリはuid属性値に基づいて命名されます。

cn: common_name

必須。個人の共通名(通常、個人によって使用されているフルネーム)を指定します。たとえばcn: Bill Andersonです。

sn: surname

必須。個人の姓を指定します。たとえばsn: Andersonです。

list_of_attributes

このエントリに関して保持する属性(オプション)のリストを指定します。

4.3 LDIFを使用してディレクトリの定義をするためのガイドライン

次のガイドラインに従って、LDIFを使用してディレクトリを作成します。

- LDIF形式に追加するエントリを含む、ASCIIファイルを作成します。

- 単一の空白行のあるエントリを分離します。ファイルの最初の行を空白にしないでください(さもなければldapmodifyコマンドが終了します)。

- データベースにおいて、各ファイルを最上位またはルート・エントリから開始します。ルート・エントリは、データベースに含まれるサフィックスまたはサブサフィックスを示している必要があります。たとえば、ご使用のデータベースにサフィックスdc=example,dc=comがある場合、ディレクトリの最初のエントリは、次となります。

dn: dc=example,dc=com

- サブツリー内へ移動するエントリを作成する前に、サブツリーに対する分岐点を作成します。

- 次の方法のいずれかを使用して、LDIFファイルからディレクトリを作成します。

- Directory Service Control Centerの使用

- dsadmコマンドおよびdsconfコマンドの使用

- -aオプションまたは-Bオプションのあるldapmodifyコマンドの使用

現在、ディレクトリ・データベースがあってこのデータベースに新規サブツリーを追加している場合、ldapmodifyコマンドを使用してディレクトリを作成します。LDIFファイルからディレクトリを作成するその他の方法とは異なり、ldapmodifyコマンドを使用してサブツリーを追加できるようになる前にDirectory Serverを動作させておく必要があります。

次の例は、組織エントリが1つ、組織単位エントリが2つ、および組織の個人エントリが3つあるLDIFファイルを示しています。

例4-2 組織、組織単位、および組織の個人のエントリがあるLDIFファイルの例

dn: o=example.com Corp
objectclass: top
objectclass: organization
o: example.com Corp
description: Fictional organization for example purposes
dn: ou=People,o=example.com Corp
objectclass: top
objectclass: organizationalUnit
ou: People
description: Fictional organizational unit for example purposes
tel: 555-5559

dn: cn=June Rossi,ou=People,o=example.com Corp
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: June Rossi
sn: Rossi
givenName: June
mail: rossi@example.com
userPassword: {sha}KDIE3AL9DK
ou: Accounting
ou: people
telephoneNumber: 2616
roomNumber: 220

dn: cn=Marc Chambers,ou=People,o=example.com Corp
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: Marc Chambers
sn: Chambers
givenName: Marc
mail: chambers@example.com
userPassword: {sha}jdl2alem87dlacz1
telephoneNumber: 2652
ou: Manufacturing
ou: People
roomNumber: 167

dn: cn=Robert Wong,ou=People,o=example.com Corp
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: Robert Wong
cn: Bob Wong
sn: Wong
givenName: Robert
givenName: Bob
mail: bwong@example.com
userPassword: {sha}nn2msx761
telephoneNumber: 2881
roomNumber: 211
ou: Manufacturing
ou: people

dn: ou=Groups,o=example.com Corp
objectclass: top
objectclass: organizationalUnit
ou: groups
description: Fictional organizational unit for example purposes

4.4 複数言語での情報の格納

単一言語を含むディレクトリの場合、ディレクトリに新規エントリを追加するために特別なことをする必要はありません。ただし多国籍の組織の場合、様々なロケールのユーザーが自身の言語でディレクトリ情報を表示できるようにするために、複数言語で情報を格納する必要があります。

情報が複数言語で示される際に、サーバーは言語タグを属性値と関連付けます。新規エントリが追加される際に、RDN(相対識別名)で使用される属性値は言語コードなしで追加される必要があります。

単一の属性に複数言語を格納できます。属性タイプは同じですが、各属性値の言語コードが異なっています。言語タグは、ディレクトリ内に文字列が格納される方法については影響しません。すべてのオブジェクト・クラスおよび属性の文字列は、UTF-8を使用して格納されます。

Directory Serverおよびその関連する言語タグによってサポートされる言語のリストについては、「サポートされるロケールの識別」を参照してください。

たとえば、example.com社は米国およびフランスにオフィスがあります。この企業は、従業員が各自の母国語でディレクトリ情報を表示することを希望しています。ディレクトリ・エントリが新規従業員のBabs Jensen向けに追加される際に、管理者はLDIFでこのエントリを作成します。管理者は、英語およびフランス語で次のように、personalTitle属性に関する値を作成します。

dn: uid=bjensen,ou=people, o=example.com Corp
objectclass: top
objectclass: person
objectclass: organizationalPerson
name: Babs Jensen
cn: Babs Jensen
sn: Jensen
uid: bjensen
personalTitle: Miss
personalTitle;lang-en: Miss
personalTitle;lang-fr: Mlle
preferredLanguage: fr

優先言語を英語に設定しているLDAPクライアントでディレクトリ・エントリにアクセスしているユーザーには、個人の敬称がMissと表示されます。優先言語をフランス語に設定しているLDAPクライアントでディレクトリにアクセスしているユーザーには、個人の敬称がMlleと表示されます。

4.5 LDIF入力を行うためのガイドライン

すべてのディレクトリ・データは、ユニコードのUTF-8エンコーディングを使用することによって格納されます。したがってLDIFのすべての入力は、UTF-8でエンコードされる必要があります。LDIF形式の詳細は、LDAP Data Interchange Format (LDIF) - 技術仕様についての説明に記載されています。

LDIF入力を行うときは、次の点を考慮してください。

- オブジェクトは空白行で、dn:で開始する行が続きます。この行は、オブジェクトの識別名です。他のすべての行は、このオブジェクトの属性です。

- コメントは#で始まります(EOLで終了します)。

- シングル・スペースで始まる行は、前の行を継続しています。

- バイナリ値はBase 64でエンコードされており、属性名の後ろに二重コロン(::)で表されています。

- 改行および行送りによって、LDIFエントリに安全でない文字を追加します。

- ldapmodifyコマンドを使用して属性値を変更する場合、誤って属性値の最後にスペースを入れないでください。たとえば、末尾にスペースがあるjensenは、末尾にスペースがないjensenとは異なるものです。

4.5.1 コマンドラインへのLDIF入力の終了

ldapmodifyおよびldapdeleteユーティリティによって、ファイルからの読取りとまったく同じように、コマンドの後に入力するLDIF文が読み取られます。入力の完了後に、ファイルの終了(EOF)のエスケープ・シーケンスとしてシェルが認識する文字を入力します。

通常は、EOFエスケープ・シーケンスは[Ctrl]キーを押しながら[D]キーを押します(^D)。

次の例では、ldapmodifyコマンドへの入力を終了する方法を示します。

prompt\> ldapmodify -h host -p port -D cn=admin,cn=Administrators,cn=config -w -
dn: cn=Barry Nixon,ou=People,dc=example,dc=com
changetype: modify
delete: telephonenumber
^D
prompt\>

簡潔性および移植性の点から、このドキュメントの例では、プロンプトまたはEOFシーケンスを示していません。

4.5.2 特殊文字の使用

コマンドラインにコマンド・オプションを入力する際に、コマンドライン・インタプリタに対して特別な意味を持つ文字(スペース( )、アスタリスク(*)、バックスラッシュ(\\)など)をエスケープする必要となる場合があります。たとえばDNの多くはスペースを含み、多くのUNIXシェルの場合には二重引用符("")で値を囲む必要があります。

このため、ご使用のコマンドライン・インタプリタに応じて、一重引用符または二重引用符のいずれかを使用する必要があります。詳細は、オペレーティング・システムのドキュメントを参照してください。

ldapmodifyコマンドの後ろのLDIF文が、シェルではなくコマンドによって解釈されており、したがって特別な考慮事項は不要であることに留意してください。

4.5.3 属性OIDの使用

属性OIDは属性名において、デフォルトではサポートされていません。これは、Directory Serverの一部の旧バージョンには該当しません。属性OIDをDirectory Serverの旧バージョンで属性名として使用していた場合、受入れ対象の属性OIDについて、属性nsslapd-attribute-name-exceptionsをonに設定する必要があります。

4.5.4 スキーマ・チェック

エントリを追加または変更する場合、使用する属性はエントリのオブジェクト・クラスによって要求されるかまたは許可される必要があり、定義された構文と一致する値を含んでいる必要があります。

エントリを変更する際に、Directory Serverでは変更する属性のみでなく、エントリ全体でスキーマ・チェックを実行します。したがって、エントリのいずれかのオブジェクト・クラスまたは属性がスキーマに準拠しない場合、操作が失敗する場合もあります。

4.5.5 LDIFエントリの順序

エントリを追加する場合のLDIFテキストの順序では、コマンドラインまたはファイルのいずかにおいて、親エントは子エントリの前に記述される必要があります。サーバーがLDIFテキストを処理する際に、このように子エントリの前に親エントリを作成します。

たとえばご使用のディレクトリに存在しないPeopleのサブツリーにエントリを作成する場合、サブツリー内のエントリの前にPeopleコンテナを示すエントリを記述します。

dn: dc=example,dc=com
dn: ou=People,dc=example,dc=com
...
People subtree entries...
dn: ou=Group,dc=example,dc=com
...
Group subtree entries...

ldapmodifyコマンドライン・ユーティリティを使用して、ディレクトリに任意のエントリを作成できますが、サフィックスのルートまたはサブサフィックスは、必要な構成エントリと関連付ける必要のある特別なエントリです。

4.5.6 大規模なエントリの管理

極端に大きな属性値を持つエントリを追加または変更するときは、これを受け入れることができるように、事前にサーバーの構成が必要になることがあります。サーバーのオーバロードを防ぐために、デフォルトでは、クライアントは2MBを超えるデータを送信できないように制限されています。

これを超えるエントリを追加するか、属性をこれよりも大きい値に変更しようとすると、サーバーはその動作の実行を拒否し、ただちに接続を閉じます。たとえば、1つのエントリの1つ以上の属性にマルチメディア・コンテンツなどのバイナリ・データが含まれると、この制限を超える可能性があります。

また、大規模なスタティック・グループを定義するエントリに、表記がこの制限を超える多数のメンバーが含まれる可能性があります。ただしパフォーマンス上の理由からこのようなグループはお薦めできず、ディレクトリ構造の再設計を考慮する必要があります。

4.5.7 エラーの処理

コマンドライン・ツールは、LDIF入力に含まれるすべてのエントリまたは変更を、順番に処理します。最初のエラーが発生すると、デフォルトの動作では処理を停止することになっています。エラーに関係なくすべての入力の処理を継続するときは、-cオプションを使用します。エラーの状態は、ツールの出力に表示されます。

前述の考慮事項に加え、一般的なエラーには、次のようなものがあります。

- 実行する操作に対する適切なアクセス権限がない。

- ディレクトリにすでに存在するDNで、エントリを追加。

- 存在しない親の下にエントリを追加。

4.6 ディレクトリの検索

LDAPクライアントを使用して、ディレクトリ内のエントリを検索できます。ほとんどのクライアントには、ディレクトリを検索してエントリ情報を取得できるようにするために、なんらかの形式の検索インタフェースが用意されています。

ディレクトリに設定されたアクセス制御が、検索結果を決定します。通常、一般ユーザーにはディレクトリの多くは表示されず、ディレクトリ管理者が、全データへのすべてのアクセス権(構成を含む)を持っています。

4.6.1 ldapsearchによるディレクトリの検索

ldapsearchコマンドライン・ユーティリティを使用して、ディレクトリ・エントリを検索および取得できます。この項で説明するldapsearchユーティリティは、Solarisプラットフォームで提供されるユーティリティではなく、Directory Server Resource Kitの一部です。

このユーティリティは、指定されたユーザーID(通常は識別名)とパスワードによってサーバーへの接続を開き、検索フィルタに基づいてエントリを検索します。検索範囲には、単一のエントリ、エントリの直接のサブエントリ、またはエントリ・ツリーやサブツリーを含むことができます。

検索結果はLDIF形式で返されます。

4.6.1.1 ldapsearchコマンドラインの形式

ldapsearchを使用する場合は、次の形式を使用してコマンドを入力する必要があります。

ldapsearch [optional_options] [search_filter] [optional_list_of_attributes]

各項目の意味は次のとおりです。

- optional_optionsは、一連のコマンドラインのオプションを表しています。検索フィルタが存在する場合は、これよりも前に指定する必要があります。

- search_filterは、-fオプションを使用しているファイルにおいて、LDAP検索フィルタを表しています。

- optional_list_of_attributesは、スペースで区切られた属性のリストを表しています。属性のリストを指定すると、検索結果で返される属性の数が減少します。この属性のリストは、必ず検索フィルタの後に表示されます。属性のリストを指定しない場合は、ディレクトリ内に設定されたアクセス制御によって許可されたすべての属性(操作属性を除く)の値が検索によって返されます。

注意:

検索操作の結果として操作属性を返すようにする場合は、検索コマンドでこれらを明示的に指定する必要があります。明示的に指定された操作属性に加えて通常の属性も取得するには、ldapsearchコマンドの属性リスト内でアスタリスク(*)を使用します。

4.6.1.2 特殊文字の使用方法

ldapsearchコマンドライン・ユーティリティを使用する場合に、コマンドライン・インタープリタにとって特別な意味を持つ文字(空白[ ]、アスタリスク[*]、バックスラッシュ[\\]など)を含む値の指定が必要になることがあります。特殊文字を指定する場合は、その値を引用符("")で囲みます。次に例を示します。

-D "cn=Charlene Daniels,ou=People,dc=example,dc=com"

このために、ご使用のコマンドライン・インタプリタに応じて、一重引用符または二重引用符のいずれかを使用します。詳細は、ご使用のシェルのドキュメントを参照してください。

4.6.2 ldapsearchの例

ここで示す一連の例では、次の前提があるものとします。

- ディレクトリ内のすべてのエントリの検索を実行しようとしています。

- サーバーのホスト名はmyServerです。

- このサーバーが使用しているポート番号は、5201です。

- ディレクトリにname="DirAdminDN" content="cn=admin,cn=Administrators,cn=config"としてバインドされています。記号"-"の使用は、コマンドラインにパスワードの入力を求められることを示しています。

- SSLが、ポート636(デフォルトのSSLポート番号)のサーバーで有効です。

- すべてのデータの格納されているサフィックスは、dc=example,dc=comです。

4.6.2.1 すべてのエントリを返す

前述の情報が提供された場合は、次の呼出しによってディレクトリ内のすべてのエントリを返すことができます。

ldapsearch -h myServer -p 5201 -D cn=admin,cn=Administrators,cn=config
-b "dc=example,dc=com" -s sub "(objectclass=*)"

"(objectclass=*)"は、ディレクトリ内のすべてのエントリと一致する検索フィルタです。

4.6.2.2 コマンドラインでの検索フィルタの指定

検索フィルタはコマンドラインから直接指定できます。この場合、フィルタを引用符で囲むことを忘れないでください("filter")。また、-fオプションは指定しません。

次に例を示します。

ldapsearch -h myServer -p 5201 -D cn=admin,cn=Administrators,cn=config -w -
-b "dc=example,dc=com" "(cn=Charlene Daniels)"

4.6.2.3 ルートDSEエントリの検索

ルートDSEエントリは、サポートされているサフィックスのリストや使用可能な認証メカニズムなど、現在のサーバー・インスタンスに関連する情報を含む特別なエントリです。検索ベース""を指定することで、このエントリを検索できます。また、検索範囲base、およびフィルタ"(objectclass=*)"を指定する必要があります。

次に例を示します。

ldapsearch -h myServer -p 5201 -D cn=admin,cn=Administrators,cn=config -w -
-b "" -s base "(objectclass=*)"

4.6.2.4 スキーマ・エントリの検索

Directory Serverでは、特別なcn=schemaエントリ内にすべての Directory Serverスキーマが格納されています。このエントリには、ご使用のディレクトリ・サーバーに対して定義されたすべてのオブジェクト・クラスと属性に関する情報が含まれています。

このエントリの内容を調べるには、次のように指定します。

ldapsearch -h myServer -p 5201 -D cn=admin,cn=Administrators,cn=config
-b "cn=schema" -s base "(objectclass=*)"

注意:

厳密に準拠する場合は、指定されたエントリのスキーマ・サブエントリの場所は、subschemaSubentry操作属性によって指定されます。このバージョンのDirectory Serverでは、この属性の値は常にcn=schemaです。

4.6.2.5 LDAP_BASEDNの使用方法

検索を簡単に行うために、LDAP_BASEDN環境変数を使用して検索ベースを設定できます。これによって、-bオプションによる検索ベースの指定を省略できます(環境変数の設定方法については、オペレーティング・システムのドキュメントを参照)。

通常、ディレクトリのサフィックスの値にはLDAP_BASEDNを設定します。ディレクトリのサフィックスはルート、つまりディレクトリの最上位のエントリと等しいため、この設定によってすべての検索がディレクトリのルート・エントリから開始されます。

たとえばLDAP_BASEDNをdc=example,dc=comに設定した場合、次のコマンドラインの呼出しを使用すると、ディレクトリ内で(cn=Charlene Daniels)を検索することができます。

ldapsearch -h myServer -p 5201 -D cn=admin,cn=Administrators,cn=config -w -
"(cn=Charlene Daniels)"

この例では範囲の指定に-sオプションが使用されていないので、subのデフォルト範囲が使用されます。

4.6.2.6 属性のサブセットの表示

ldapsearchコマンドでは、すべての検索結果がLDIF形式で返されます。デフォルトではldapsearchは、エントリの識別名と読取りを許可されたすべての属性を返します。指定したディレクトリ・エントリの属性のサブセットの読取りのみが許可されるように、ディレクトリのアクセス制御を設定できます。操作属性のみが返されません。検索操作の結果として操作属性を返すようにする場合は、検索コマンドでこれらを明示的に指定する必要があります。操作属性の詳細は、TODO: AdminServerAdminGuideの不使用に関する説明を参照してください。

検索結果で返された属性のすべてを表示するわけではない場合を考えてみます。返された属性をいくつかの特定の属性に制限するには、検索フィルタのすぐ後のコマンドラインで、必要な属性を指定します。たとえば、ディレクトリのすべてのエントリについてcn属性とsn属性を表示するには、次のコマンドを使用します。

ldapsearch -h myServer -p 5201 -D cn=admin,cn=Administrators,cn=config -w -
"(objectclass=*)" sn cn

この例では、LDAP_BASEDNを使用して検索ベースを設定することを前提としています。

4.6.2.7 複数値属性の検索

Directory Serverは検索時に、複数値属性を必ずしもソート順で返すわけではありません。たとえば、変更を適用する前にサーバーを再起動することを要求するcn=configで、構成属性を検索する場合を考えてみます。

ldapsearch -h myServer -p 5201 -D cn=admin,cn=Administrators,cn=config -w -
-b cn=config "(objectclass=*)" nsslapd-requiresrestart

次のような結果が返されます。

dn: cn=config
nsslapd-requiresrestart: cn=config:nsslapd-port
nsslapd-requiresrestart: cn=config:nsslapd-secureport
nsslapd-requiresrestart: cn=config:nsslapd-plugin
nsslapd-requiresrestart: cn=config:nsslapd-changelogdir
nsslapd-requiresrestart: cn=config:nsslapd-changelogsuffix
nsslapd-requiresrestart: cn=config:nsslapd-changelogmaxentries
nsslapd-requiresrestart: cn=config:nsslapd-changelogmaxage
nsslapd-requiresrestart: cn=config:nsslapd-db-locks
nsslapd-requiresrestart: cn=config:nsslapd-return-exact-case
nsslapd-requiresrestart: cn=config,cn=ldbm database,cn=plugins,
cn=config:nsslapd-allidsthreshold
nsslapd-requiresrestart: cn=config,cn=ldbm database,cn=plugins,
cn=config:nsslapd-dbcachesize
nsslapd-requiresrestart: cn=config,cn=ldbm database,cn=plugins,
cn=config:nsslapd-dbncache
nsslapd-requiresrestart: cn=config,cn=ldbm database,cn=plugins,
cn=config:nsslapd-directory
nsslapd-requiresrestart: cn=encryption,cn=config:nssslsessiontimeout
nsslapd-requiresrestart: cn=encryption,cn=config:nssslclientauth
nsslapd-requiresrestart: cn=encryption,cn=config:nssslserverauth
nsslapd-requiresrestart: cn=encryption,cn=config:nsssl2
nsslapd-requiresrestart: cn=encryption,cn=config:nsssl3
...

このように、nsslapd-requiresrestart属性は複数の値を取得します。ただし、これらの値はソートされていません。複数値属性をソート順にする必要があるアプリケーションを開発する場合は、アプリケーションでソートを実行するようにします。

4.6.2.8 検索時のクライアント認証の使用方法

次の例は、クライアント認証を使用してディレクトリ検索を行うユーザーのcdanielsを示しています。

ldapsearch -h myServer -p 636 -b "dc=example,dc=com"
-N  "cdanielsscertname" -Z -W certdbpassword
-P /home/cdaniels/certdb/cert.db "(givenname=Richard)"

4.6.3 LDAP検索フィルタ

検索フィルタは、検索操作に対して返されるエントリを選択します。これらは一般的に、ldapsearchコマンドライン・ユーティリティによって使用されます。ldapsearchを使用する場合は、各フィルタをファイル内の個別の行にしてファイル内に複数の検索フィルタを配置するか、コマンドラインで直接検索フィルタを指定することができます。

たとえば、次のフィルタでは、共通名Lucie Du Boisの検索を指定しています。

(cn=Lucie Du Bois)

この検索フィルタでは、共通名Lucie Du Boisを含むすべてのエントリが返されます。共通名の値の検索では、大文字と小文字は区別されません。

共通名属性に言語タグに関連付けられた値が存在する場合は、すべての値が返されます。したがって、次の2つの属性値はどちらもこのフィルタに一致します。

cn: Lucie Du Bois
cn;lang-fr: Lucie Du Bois

4.6.3.1 検索フィルタの構文

検索フィルタの基本構文は次のとおりです。

(attribute operator value)

次に例を示します。

(buildingname\>=alpha)

この例では、buildingnameは属性、\>=は演算子、およびalphaは値です。ブール演算子によって異なる属性を組み合せて使用するように、フィルタを定義することもできます。

4.6.3.2 検索フィルタでの属性の使用

エントリを検索するときに、そのエントリのタイプに関連付けられた属性を指定することができます。たとえば人のエントリを検索する場合は、cn属性を使用して特定の共通名を持つ人を検索することができます。

人のエントリが含まれる属性の例には、次のようなものが挙げられます。

- cn(その人の共通名)

- sn(その人の姓)

- telephoneNumber(その人の電話番号)

- buildingName(その人が居住する建物名)

- l(その人が存在する場所)

4.6.3.3 検索フィルタでの演算子の使用方法

表4-5は、検索フィルタで使用できる演算子をリスト表示したものです。

表4-5 検索フィルタの演算子

検索タイプ

演算子

説明

等価

=

指定した値と正確に一致する属性値を含むエントリを返します。例: cn=Bob Johnson

部分文字列

=string*string

指定した部分文字列を含む属性を含む、エントリを返します。次に例を示します。

cn=Bob*cn=*Johnsoncn=*John*cn=B*John

(アスタリスク(*)はゼロ(0)個以上の文字を示します。)

以上

\>=

指定した値より大きいかそれと等しい属性を含むエントリを返します。次に例を示します。

buildingname \>= alpha

以下

<=

指定した値より小さいか、それと等しい属性を含むエントリを返します。次に例を示します。

buildingname <= alpha

プレゼンス

=*

指定した属性について1つ以上の値を含むエントリを返します。次に例を示します。

cn=*

telephonenumber=*

manager=*

近似

~=

検索フィルタで指定した値と近似した値を持つ、特定の属性を含むエントリを返します。次に例を示します。

cn~=suret

l~=san fransico

次が返される可能性があります

cn=sarette

l=san francisco

近似演算子は試験的なもので、英語の文字列でしか使用できません。ASCIIベース以外の文字列(Ja、Znなど)では動作しません。

dn属性に対する検索機能を拡張し(たとえばcn:dn:=John)、国際的な検索をサポートするために拡張された演算子も存在します。

4.6.3.4 検索フィルタでのOIDの使用方法

LDAPv3を使用すると、特定の属性に対してマッチ演算子とルールを構築することができます。一致ルールは、属性の値を特定の構文と比較する方法を定義しています。すなわち一致ルールとは、一致する可能性のある属性を比較する方法を定義したものです。たとえば一致ルールは、属性を比較するときにテキストの大文字小文字を考慮するかどうかを定義できます。

ルールが作成されると、検索フィルタで参照されます。

たとえば次の検索フィルタは、OID2.5.13.5で指定される一致ルールを使用して、姓Jensenを含むエントリを比較します。

(sn:2.5.13.5:=Jensen)

次の例では、:dn表記を使用して、比較時にOID2.5.13.5を使用することと、一致を評価する場合にエントリ\qsの識別名の属性をエントリの一部として考慮することを示しています。

(sn:dn:2.5.13.5:=Jensen)

4.6.3.5 複合検索フィルタの使用方法

プリフィクス表記内で次のように表現されるブール演算子を使用して、複数の検索フィルタ・コンポーネントを組み合せることができます。

(Boolean-operator(filter)(filter)(filter)...)

このBoolean-operatorは、表4-6に一覧表示されているブール演算子のいずれかになります。

ブール演算子を組み合せて相互にネストすることで、次のような複雑な式を作成できます。

(Boolean-operator(filter)(Boolean-operator(filter)(filter)))

検索フィルタで使用できるブール演算子には、次のようなものがあります。

表4-6 検索フィルタのブール演算子

演算子

記号

説明

AND

&

文がtrueになるためには、指定したすべてのフィルタがtrueである必要があります。次に例を示します。

(&(filter)(filter)(filter)...)

OR

|

文がtrueになるには、指定したフィルタの少なくとも1つがtrueである必要があります。次に例を示します。

(|(filter)(filter)(filter)...)

NOT

!

文がtrueになるためには、指定した文がtrueではない必要があります。NOT演算子によって影響を受けるのは、1つのフィルタだけです。次に例を示します。

(!(filter))

NOT演算子を使用すると、索引付けされていない検索となります。

ブール式は、次の順序で評価されます。

- 内側のカッコでくくられた式から外側のカッコでくくられた式へ

- すべての式を左から右へ

4.6.3.6 ファイルを使用した検索フィルタの指定

検索フィルタは、コマンドラインではなく、ファイルに入力できます。この場合、各検索フィルタをファイル内の個別の行に指定します。ldapsearchコマンドは、ファイル内に現れる順序で各検索を実行します。

たとえば、ファイルに次が含まれているとします。

(sn=Daniels)
(givenname=Charlene)

この場合、ldapsearchは最初にDanielsという姓を持つすべてのエントリを検索し、次にCharleneという名を持つすべてのエントリを検索します。両方の検索条件に一致するエントリが見つかると、そのエントリは2回返されます。

たとえば、前述の検索フィルタをsearchdbという名前のファイル内で指定して、LDAP_BASEDNを使用して検索ベースを設定したとします。次によって、どちらかの検索フィルタに一致するすべてのエントリが返されます。

ldapsearch -h myServer -p 5201 -D cn=admin,cn=Administrators,cn=config -w -
-f searchdb

ここで返される属性セットを制限するには、検索行の末尾で属性名を指定します。たとえば、次のldapsearchコマンドは両方の検索を実行しますが、各エントリのDNと、givenname、およびsn属性だけを返します。

ldapsearch -h myServer -p 5201 -D cn=admin,cn=Administrators,cn=config -w -
-f searchdb sn givenname

4.6.3.7 検索フィルタの7ビット以外のASCII文字の指定

検索フィルタの7ビット以外のASCII文字は、文字表現で置き換える必要があります(UTF-8エンコードの各バイトの前にバックスラッシュが入ります。)。UTF-8では、文字は各バイトに対して16進コードで表現されます。

たとえば、文字éをUTF-8で表現するとc3a9になります。この場合、検索フィルタではéを\\c3\\a9と表します。したがってcn=Véronique Martinを検索するには、次のように指定します。

ldapsearch -h myServer -b "dc=example,dc=com" "(cn=V\\c3\\a9ronique Martin)"

表4-7にリスト表示されている特殊文字は、検索フィルタで使用された場合、次の方法で表現される必要があります。

表4-7 検索フィルタの特殊文字

特殊文字

特殊文字を使用した値

フィルタの例

*

Five*Star

(cn=Five\\2aStar)

\\

c:\\File

(cn=\\5cFile)

()

John (2nd)

(cn=John \\282nd\\29)

null

0004

(bin=\\00\\00\\00\\04)

4.6.3.7.1 検索フィルタ内の識別名のエスケープ文字

Directory Serverの任意の箇所でDNを使用する場合、コンマとその他の特定の特殊文字はバックスラッシュ(\\)でエスケープする必要があります。検索フィルタでDNを使用する場合、DN内の特殊文字をエスケープするために使用されるバックスラッシュは\\5cと表します。次に例を示します。

DN: cn=Julie Fulmer,ou=Marketing\\,Bolivia,dc=example,dc=com

検索フィルタのDN: ldapsearch -h myServer -b "dc=example,dc=com" "(manager=cn=Julie Fulmer,ou=Marketing\\5c,Bolivia,dc=example,dc=com)"

4.6.4 検索フィルタの例

次のフィルタでは、manager属性について1つ以上の値を含むエントリを検索します。これは、プレゼンス検索とも呼ばれるものです。

(manager=*)

次のフィルタでは、共通名Ray Kultgenを含むエントリを検索します。これは、これは等価検索とも呼ばれるものです。

(cn=Ray Kultgen)

次のフィルタでは、部分文字列X.500を含むdescription属性を含むすべてのエントリが返されます。

(description=*X.500*)

次のフィルタでは、組織単位がMarketingで、説明フィールドに部分文字列X.500を含まないすべてのエントリが返されます。

(&(ou=Marketing)(!(description=*X.500*)))

次のフィルタでは、組織単位がMarketingで、Julie FulmerまたはCindy Zwaskaがマネージャーとして存在するすべてのエントリが返されます。

(&(ou=Marketing)(|(manager=cn=Julie Fulmer,ou=Marketing,
dc=example,dc=com)(manager=cn=Cindy Zwaska,ou=Marketing,
dc=example,dc=com)))

次のフィルタでは、人を表さないすべてのエントリが返されます。

(!(objectClass=person))

前述のフィルタは、パフォーマンスに悪影響を及ぼすので、複雑な検索の一部として使用します。次のフィルタでは、人を表さず、かつ共通名がprinter3bと近似しているすべてのエントリが返されます。

(&(cn~=printer3b)(!(objectClass=person)))

4.6.4.1 操作属性の検索

検索操作の結果として操作属性を返すようにする場合は、検索コマンドでこれらを明示的に指定する必要があります。

$ ldapsearch -h myServer -p 5201 -D cn=admin,cn=Administrators,cn=config -w -
"(objectclass=*)" aci

明示的に指定された操作属性に加えて通常の属性も取得するには、操作属性にアスタリスク(*)を追加して指定します。次に例を示します。

$ ldapsearch -h myServer -p 5201 -D cn=admin,cn=Administrators,cn=config -w -
"(objectclass=*)" aci *

5 Directory Serverのセキュリティ

Directory Serverのセキュリティの詳細は、次の各項を参照してください。

- Directory Serverのセキュリティの提供方法

- Directory Serverのアクセス制御の提供方法

- Directory Serverの認証の提供方法

- Directory Serverの暗号化の提供方法

5.1 Directory Serverのセキュリティの提供方法

Directory Serverは、次の方法を組み合せてセキュリティを提供します。

- 認証
認証は、1つのパーティが別のパーティのアイデンティティを検証するための手段です。たとえば、クライアントはLDAPのバインド操作中にDirectory Serverに対してパスワードを提供します。ポリシーは、パスワードが有効とみなされるために満たす必要がある基準(期間、長さ、構文など)を定義します。Directory Serverでは、匿名認証、パスワードベースの認証、証明書ベースの認証、SASLベースの認証およびプロキシ認証をサポートされています。認証が拒否された場合、Directory Serverは、アカウント非アクティブ化およびグローバル・ロックアウトというメカニズムを使用してデータを保護します。認証の詳細は、「Directory Serverの認証の提供方法」を参照してください。

- 暗号化
暗号化によって情報のプライバシが保護されます。データが暗号化されるとき、そのデータは正当な受信者のみがデコードできる方法でスクランブルされます。Directory Serverでは、SSL暗号化および属性の暗号化がサポートされています。暗号化の詳細は、「Directory Serverの暗号化の提供方法」を参照してください。

- アクセス制御
アクセス制御では、様々なディレクトリ・ユーザーに付与されたアクセス権を調整し、必須資格証明またはバインド属性を指定するための手段を提供します。アクセス制御の詳細は、「Directory Serverのアクセス制御の提供方法」を参照してください。

- 監査
監査では、ディレクトリのセキュリティが脅威にさらされているかどうかを判断します。たとえば、ディレクトリによって保持されているログ・ファイルを監査できます。ログ・ファイルの詳細は、第10章「Directory Serverのロギング」を参照してください。

5.2 Directory Serverのアクセス制御の提供方法

Directory Serverは、アクセス制御命令(ACI)を使用して、LDAPクライアントからのリクエストに対して付与または拒否する権限を定義します。Directory Serverがリクエストを受信すると、サーバー内に定義されたACI、およびユーザーによって提供された認証情報を使用して、ディレクトリ情報へのアクセスを許可または拒否します。サーバーは、読取り、書込み、検索、比較などの権限を許可または拒否できます。

Directory ServerでのACIの詳細は、次の各項を参照してください。

- ACIの概要

- アクセス制御命令のチューニング

5.2.1 ACIの概要

ACIは、aci操作属性に格納されます。aci属性は、エントリのオブジェクト・クラスに対してaci属性が定義されているかどうかにかかわらず、ディレクトリ内のすべてのエントリに使用できます。aci属性は複数値のため、複数のACIをディレクトリの同じ部分に対して定義できます。

ACIは、ディレクトリの次の部分に対するアクセス制御に使用できます。

- ディレクトリ全体

- ディレクトリのサブツリー

- 構成タスクを定義するエントリを含む、ディレクトリ内の特定のエントリ

- エントリ属性の特定のセット

- 特定のエントリ属性の値

ACIは、次のユーザーに対するアクセスを定義するために使用できます。

- 特定のユーザー

- 特定のグループまたはロールに属しているすべてのユーザー

- ディレクトリのすべてのユーザー

- IPアドレスまたはDNS名で識別される特定のクライアント

5.2.1.1 ACIの有効範囲および階層

ACIは、ルートDSEを含む、ディレクトリ・ツリー内のすべてのノードに作成できます。

ACIの有効範囲は、ターゲット・エントリ、ターゲット・エントリとその直下の子またはターゲット・エントリとそのすべての子にできます。有効範囲が指定されていない場合、ターゲット・エントリとそのすべての子にACIが適用されます。

サーバーがエントリに対するアクセス権を評価する場合、そのエントリに対するACIおよびエントリのルート・サフィックスのベースにバックアップされる親エントリのACIを検証します。

サーバー内のエントリへのアクセスは、ACIによって明示的に付与される必要があります。ACIはデフォルトで、匿名読取りアクセスを定義し、ユーザーによる自身のエントリ(セキュリティ上必要な属性を除く)の変更を許可します。エントリにACIが適用されない場合、ディレクトリ・マネージャを除くすべてのユーザーに対するアクセスが拒否されます。

ACIによって付与されたアクセスは、階層内の他のACIが拒否しないかぎり、許可されます。階層内で表示される場所にかかわらず、アクセスを拒否するACIは、同じリソースに対してアクセスを許可するACＩより優先されます。

ディレクトリ・マネージャは、アクセス制御が適用されない唯一の特権ユーザーです。クライアントがディレクトリ・マネージャとしてディレクトリにバインドされている場合、サーバーは操作を実行する前にACIを評価しません。

Directory Serverの以前のバージョンでは、ACIはルートDSEの下に直接追加または削除できませんでした。現在、この制限はDirectory Serverで削除されています。

5.2.1.2 ACIの制限

ACIには、次の制限が適用されます。

- アクセス制御ルールは、常にローカル・サーバーで評価されます。ACIキーワードに使用されているサーバーのホスト名またはポート番号は、LDAPのURLで指定できません。

- ディレクトリ・マネージャとしてユーザーにプロキシに対する権限を付与することはできず、ディレクトリ・マネージャに対してプロキシ権限を付与することもできません。

- 使用可能な物理メモリーにサーバーが確実に適合するために使用するキャッシュ設定は、ACIキャッシュには適用されませんが、これは、過剰な数のACIが使用可能なメモリーを飽和させる可能性があることを意味します。

5.2.1.3 デフォルトACI

次のデフォルトACIがルートDSEで定義されています。

- すべてのユーザーは、検索、比較および読取り操作用に、ディレクトリに対して匿名アクセスを持ちます(userpassword属性を除く)。

- バインド済ユーザーは、自身のパスワードを変更できます。

- グループcn=Administrators,cn=configのユーザーは、すべてのエントリに対して完全なアクセスを持ちます。これはディレクトリ・マネージャのアクセスと同等ですが、ディレクトリ・マネージャとは異なり、管理者グループのユーザーはACIの対象になります。

5.2.1.4 ACIおよびレプリケーション

ACIはエントリの属性として格納されます。したがって、ACIを含むエントリがレプリケートされたサフィックスの一部の場合、ACIは他の属性と同様にレプリケートされます。

ACIは、受信LDAPリクエストを処理するディレクトリ・サーバー上で、常にローカルで評価されます。

コンシューマ・サーバーが更新リクエストを受信すると、コンシューマ・サーバーは、このリクエストをマスターで処理できるかどうかを評価するために、マスター・サーバーに対してリフェラルを返します。

5.2.1.5 実効権限

実効権限機能は、次の情報を取得するために使用できます。

- エントリ・レベルの権限、属性レベルの権限およびロギングを含む、権限情報。

- 書込み、自己書込みの追加および自己書込みの削除に対する権限。

- アクセス制御の問題をデバッグするためのログ情報。

実効権限機能を使用するには、実効権限制御を使用するためのアクセス制御権限およびaclRights属性の読取りアクセス権が必要です。

プロキシ制御が実効権限制御ベースの検索操作に付随している場合は、実効権限操作はプロキシ・ユーザーとして認証されます。そのため、プロキシ・ユーザーは、実効権限制御を使用するための権利を持っている必要があります。プロキシ・ユーザーが検索および表示に対する権利を持つエントリが返されます。詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の第6章「Directory Serverのアクセス制御」を参照してください。

5.2.2 アクセス制御命令のチューニング

Directory Serverは、アクセス制御命令に対して、パフォーマンスおよびスケーラビリティの改善を提供します。改善には、メモリー管理の向上が含まれます。また、マクロACIに対するサポートも改善に含まれます。改善にもかかわらず、Directory Serverは複合ACIを評価するためにかなりのシステム・リソースを使用します。したがって、複合ACIを大量に使用すると、パフォーマンスに悪影響を与える場合があります。

マクロACIは、使用するACIの数を制限するのに役立ちます。ACIの数を制限することで、システム上の負荷を管理および削減するためのアクセス制御が容易になります。マクロは、ACIの中でDN、またはDNの一部を表現するプレースホルダです。マクロは、ACIターゲット内、ACIバインド・ルール内またはその両方で使用できます。Directory Serverがリクエストを受信すると、結果として生じる操作のターゲットとなるリソースに一致するACIマクロが確認されます。マクロが一致した場合、Directory Serverは、それを実際のDNの値で置き換えます。その後、Directory Serverは順当にACIを評価します。

テストでは、Directory Serverインスタンスは50,000を超えるACIをサポートできることが証明されました。とはいえ、ACIの数はできるだけ少なく維持します。ACIの数を少なく維持することで、パフォーマンスへの悪影響が制限されます。数を少なくすることで、アクセス制御の管理の複雑さも軽減されます。複合ACI環境が関係するデプロイでは、一部のアクセス制御機能を提供するために、Directory Proxy Serverの使用を検討してください。

5.3 Directory Serverの認証の提供方法

認証は、アイデンティティを確認するプロセスです。ネットワーク相互作用では、認証は、別のパーティによる1つのパーティのアイデンティティの確実性に関係します。一般にネットワーク相互作用は、パーソナル・コンピュータ上で動作しているブラウザ・ソフトウェアなどのクライアントと、Webサイトをホストするために使用されるソフトウェアおよびハードウェアなどのサーバー間で行われます。クライアント認証では、サーバーによるクライアントの確証アイデンティティを参照し、サーバー認証では、クライアントがサーバーの確証アイデンティティを参照します。

認証の詳細は、次の各項を参照してください。

- 匿名アクセス

- パスワードベースの認証

- 証明書ベースの認証

- プロキシ認可

- アカウントの非アクティブ化

- グローバル・アカウント・ロックアウト

- SASLベースの認証

5.3.1 匿名アクセス

匿名アクセスでは、認証資格証明を提供することなく、ユーザーをディレクトリにバインドできます。アクセス制御を使用することで、匿名ユーザーに選択した任意の権限を付与できます。たいていの場合、匿名ユーザーは、ディレクトリからの名前、電話番号、電子メールアドレスなどの機密ではないデータの読取りが許可されます。

匿名アクセスの権限を制限したり、アドレス帳情報が含まれる属性のサブセットに匿名アクセスを制限することもできます。機密データに対して匿名アクセスを許可しないようにします。

匿名ユーザーが何かに対するアクセス権を持っている場合、匿名としてアクセスが付与されているにもかかわらず、ユーザーが適切なバインドに失敗するのを防ぐ必要がある場合があります。詳細は、serverのrequire-bind-pwd-enabledを参照してください。

5.3.2 パスワードベースの認証

単純なパスワード認証は、ユーザーの認証の簡単な方法を提供します。パスワード認証では、ユーザーは、各サーバーに対してパスワードを提供する必要があり、管理者は、各ユーザーの名前およびパスワードを(通常はサーバーごとに)追跡する必要があります。

5.3.2.1 パスワードベースの認証の手順

図5-1に、名前およびパスワードを使用したクライアントの認証に関する手順を示します。この図では次の点を想定しています。

- ユーザーは、認証せずに、またはSSLを介したサーバー認証の基づいて、システムをすでに信頼しています。

- ユーザーは、サーバーによって制御されるリソースをリクエストしました。

- サーバーは、リクエストされたリソースへのアクセスを許可する前に、クライアント認証が必要です。

図5-1 パスワードベースの認証

「図5-1 パスワードベースの認証」の説明

図5-1では、パスワード認証は次の手順で実行されます。

1. ユーザーが名前とパスワードを入力します。
Directory ServerへのLDAPバインドでは、クライアント・アプリケーションは識別名を使用してバインドする必要があります。そのため、クライアント・アプリケーションは、ユーザーによって入力された名前を使用してDNを取得する場合があります。

2. クライアントは、DNおよびパスワードをネットワークを介して送信します。

3. サーバーは、クライアントが送信したパスワードが、エントリに対して格納されているパスワードと一致していることかどうかをクライアントが送信したDNを使用して確認します。
一致する場合、サーバーは、ユーザー・アイデンティティを認証した証拠として資格証明を受け入れます。

4. サーバーは、識別したユーザーによるリクエストされたリソースに対するアクセスが許可されているかどうかを確認します。
許可されている場合、サーバーはクライアントに対してリソースへのアクセスを許可します。

5.3.2.2 パスワード・ポリシー

パスワード・ポリシーは、システムでのパスワードの管理方法を制御する一連のルールです。Directory Serverでは、複数のパスワード・ポリシーがサポートされています。パスワード・ポリシーは、デプロイメントのセキュリティ要件を満たすように構成できます。

Directory Serverのインスタンスは、デフォルトのパスワード・ポリシーを使用して作成されます。

5.3.2.2.1 パスワード・ポリシーのタイプ

Directory Serverには、次のパスワード・ポリシーが用意されています。

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

デフォルトのパスワード・ポリシーは、構成エントリcn=PasswordPolicy,cn=configに定義されています。デフォルトのパスワード・ポリシーはディレクトリ・マネージャを除くディレクトリ内のすべてのアカウントに適用されます。

デフォルトのポリシーのパラメータは、デフォルト設定をオーバーライドするために変更できます。ただし、デフォルトのパスワード・ポリシーはインスタンスの構成の一部であるため、デフォルトのパスワード・ポリシーに対する変更はレプリケートできません。

特殊パスワード・ポリシー

パスワード・ポリシーは、個々のユーザー、またはCoSおよびロール機能を使用することでユーザーのセットに対して構成できます。ただし、特殊パスワード・ポリシーは静的グループには適用できません。

特殊パスワード・ポリシーはディレクトリ・ツリーのサブエントリに定義されます。デフォルトのパスワード・ポリシーと同様に、特殊パスワード・ポリシーはpwdPolicyオブジェクト・クラスを使用します。たとえば、次のエントリは特殊パスワード・ポリシーを定義します。

dn: cn=TempPolicy,dc=example,dc=com
objectClass: top
objectClass: pwdPolicy
objectClass: LDAPsubentry
cn: TempPolicy
pwdCheckQuality: 2
pwdLockout: on
pwdLockoutDuration: 300
pwdMaxFailure: 3
pwdMustChange: on

特殊パスワード・ポリシーは、単一のユーザー・アカウントまたはロールを使用することでユーザーのセットに割り当てることができます。たとえば、次のエントリでは、cn=TempPolicy,dc=example,dc=comに定義されたパスワード・ポリシーは、ユーザー・エントリのpwdPolicySubentry属性に割り当てられています。

dn: uid=dmiller,ou=people,dc=example,dc=com
objectClasaccess controls: person
objectClass: top
sn: miller
cn: david
userPassword: secret12
pwdPolicySubentry: cn=TempPolicy,dc=example,dc=com

ユーザー・エントリによって参照されると、特殊パスワード・ポリシーは、デフォルトのパスワード・ポリシーをオーバーライドします。

特殊パスワード・ポリシーはディレクトリ・データに定義されるため、レプリケートできます。

5.3.2.2.2 パスワード・ポリシーの構成

パスワード・ポリシーの構成方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の第7章「Directory Serverのパスワード・ポリシー」を参照してください。

パスワード・ポリシーの構成に使用される属性の詳細は、pwpolicyマニュアル・ページを参照してください。

5.3.3 プロキシ認可

プロキシ認可では、クライアントからのリクエストを、クライアントのアイデンティティではなくプロキシ・アイデンティティを使用して処理できます。自身のアイデンティティを使用してバインドされたクライアントには、プロキシ認可を介してプロキシ・ユーザーの権限が付与されます。クライアントのアクセス制御命令(ACI)ではなく、プロキシ・ユーザーのACIは、操作を許可または拒否するために評価されます。

プロキシ認可を使用して操作を実行する前に、プロキシ・ユーザーのアカウントが検証されます。プロキシ・ユーザーのアカウントがロック・アウト、非アクティブ化されている場合、パスワードがリセットされた場合または期限切れの場合は、クライアント操作は強制終了されます。

プロキシ認可を使用することで、LDAPアプリケーションは、単一のバインドを使用して、Directory Serverに対してリクエストを行う複数のユーザーに対処できます。各ユーザーに対してバインドおよび認証するのではなく、クライアント・アプリケーションはDirectory Serverにバインドしてプロキシ権限を使用します。

プロキシ認可を使用するには、次の条件を満たしている必要があります。

- Directory Serverは、プロキシ・アイデンティティに対して適切なACIを使用して構成されている必要があります。
たとえば、次のACIは、ALLアクセス権限を管理者に与えます。

aci: (targetattr="*") (version 3.0; acl "allowAll-Admin";
allow (all) userdn="ldap:///uid=Administrator,
ou=Administrators, dc=example,dc=com";)

- Directory Serverは、他のユーザーに対してプロキシとして動作するために、プロキシ・アイデンティティに対する許可を使用して構成されている必要があります。
たとえば、次のACIは、ユーザーuser ClientApplicationに対してプロキシとして動作する権限を管理者に与えます。

aci: (targetattr="*") (version 3.0; acl "allowproxy-
accountingsoftware"; allow (proxy) userdn=
"ldap:///dn:uid=ClientApplication,ou=Applications,
dc=example,dc=com";)

次の例に、Administratorプロキシ・アイデンティティを使用して検索操作を実行するユーザーClientApplicationを示します。

$ ldapsearch \
-D "uid=ClientApplication,ou=Applications,dc=example,dc=com" \
-w password \
-y "uid=Administrator,ou=Administrators,dc=example,dc=com" ...

クライアントは自身としてバインドしますが、プロキシ・エントリの権限が付与されます。クライアントには、プロキシ・エントリのパスワードは不要です。

プロキシ権限は、ディレクトリ・マネージャを除くすべてのユーザーに付与できます。

プロキシ認可の構成方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のプロキシ認可に関する説明を参照してください。

5.3.4 アカウントの非アクティブ化

ユーザー・アカウントまたはアカウントのセットは、dsutil account-inactivateコマンドを使用して、一時的または無限に非アクティブ化できます。「dsutil」を参照してください。

アカウントが非アクティブの場合、ユーザーはDirectory Serverにバインドできません。この機能は、アカウントの非アクティブ化と呼ばれます。

ユーザー・アカウントおよびロールは非アクティブ化できます。ロールが非アクティブの場合、ロール自体ではなく、ロールのメンバーが非アクティブ化されます。

アカウントの非アクティブ化の構成方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のアカウントの手動ロックに関する説明を参照してください。

5.3.5 グローバル・アカウント・ロックアウト

パスワード・ポリシーの設定に応じて、失敗したバインド試行の数が許可されているバインド試行の数を超えた場合に、クライアント・アカウントは、アカウントからロック・アウトされます。レプリケートされたトポロジでは、クライアントがバインドを試みたインスタンスのみでなく、Directory Serverのすべてのインスタンスからクライアントがロック・アウトされます。この機能は、グローバル・アカウント・ロックアウトと呼ばれます。

Directory Server 6より前のDirectory Serverのバージョンでは、アカウント・ロックアウトは整数カウンタに基づいていました。これらのカウンタは、デフォルトではレプリケートされませんでした。

製品のこのバージョンでは、バインド機能はタイムスタンプを使用して記録されます。タイムスタンプはデフォルトでレプリケートされ、失敗したバインド・リクエストが原因で発生したロック・アウト・データに対する更新をレプリケートするために優先順序付きレプリケーションが使用されます。

グローバル・アカウント・ロックアウトは、次のシナリオで使用できます。

- レプリケーションがバインド失敗を伝播するために使用される場合
バインド・リクエストは読取り専用のコンシューマを対象にできません。クライアントが読取り専用コンシューマへのバインドに失敗した場合、ロックアウト・データはレプリケートされません。そのため、バインド・リクエストが読取り専用コンシューマで失敗した場合、ロックアウト・データはそのインスタンス上でのみ更新され、トポロジ全体にはレプリケートされません。

すべてのバインド試行がマスター・レプリカを対象としている場合でも、クライアントは、ロックアウト・データがレプリケートされるより早く複数のサーバー上でバインド試行を実行できる可能性があります。このようにして、クライアントは、パスワード・ポリシーでの失敗したバインド試行の制限を超えることができます。優先順序付きレプリケーションを使用してバインドの失敗がレプリケートされる場合にも、この危険性が存在することに注意してください。

- Directory Proxy Serverがバインド操作のルーティングを管理する場合
Directory Proxy Serverでは、ロード・バランシング用にハッシュ・アルゴリズムを使用して指定されたアカウントに対するすべてのバインド・リクエストを同じDirectory Serverにルートすることで、グローバル・アカウント・ロックアウトを実現できます。グローバル・アカウント・ロックアウトのためのハッシュ・アルゴリズムの使用に関する詳細は、「グローバル・アカウント・ロックアウトの操作アフィニティ・アルゴリズム」を参照してください。

5.3.6 証明書ベースの認証

証明書を使用したクライアント認証の詳細は、次の各項を参照してください。

- 証明書ベースの認証の概要

- 証明書および認証局(CA)

- 証明書のタイプ

- 証明書の内容

- 証明書の管理

5.3.6.1 証明書ベースの認証の概要

図5-2に、認証での証明書およびSSLプロトコルの併用方法を示します。サーバーに対してユーザーを認証するには、クライアントは、ランダムに生成されたデータの1つにデジタル署名し、証明書および署名済データの両方をネットワークを介して送信します。この説明では、データに関連付けられているデジタル署名は、クライアントからサーバーに対して提供された証拠と考えることができます。サーバーは、ユーザーのアイデンティティをこの証拠の強度で認証します。

図5-1に示されているパスワードベースの認証と同様に、図5-2は、ユーザーは、すでにサーバーを信用済で、リソースをリクエスト済であると想定します。サーバーは、リクエストされたリソースへのアクセスを付与するかどうかの評価の過程で、クライアント認証をリクエスト済です。

図5-2 証明書ベースの認証

「図5-2 証明書ベースの認証」の説明

図5-1に示されているパスワードベースの認証とは異なり、図5-2ではSSLの使用が必要です。図5-2では、サーバーに対してクライアントを識別するために使用できる有効な証明書がクライアントにあることを想定しています。

証明書ベースの認証は、ユーザーが持っているもの(秘密鍵)およびユーザーが認識していること(秘密鍵を保護するパスワード)に基づいているため、一般に、パスワードベースの認証より望ましいと考えられています。ただし、これら2つの前提は、権限のない者がユーザーのマシンまたはパスワードにアクセスしない場合、クライアント・ソフトウェアの秘密鍵データベースにパスワードが設定されている場合およびソフトウェアが適度な頻度の間隔でパスワードを要求するように設定されている場合にのみ当てはまることに注意する必要があります。

注意:

パスワードベースの認証および証明書ベースの認証のどちらも、個々のマシンまたはパスワードへの物理的アクセスに関するセキュリティの問題には対処しません。公開鍵暗号化のみが、証明書内の公開鍵に対応する一部のデータの署名に使用された秘密鍵を検証できます。マシンの物理的セキュリティを保護することおよび秘密鍵のパスワードを隠しておくことはユーザーの責任です。

証明書は、クライアントとサーバー間の相互作用の認証部分を置換します。終日にわたってユーザーにネットワークを介してパスワードの送信を要求するかわりに、シングル・サインオンでは、ネットワークを介して送信するのではなく、ユーザーは、秘密鍵データベースのパスワードを一度のみ入力する必要があります。残りのセッションでは、クライアントは、新しく接続する各サーバーに対してユーザーを認証するためにユーザーの証明書を提示します。認証済のユーザー・アイデンティティに基づいた既存の認証メカニズムには影響しません。

5.3.6.2 証明書および認証局(CA)

証明書は、電子ドキュメントで、個人、サーバー、会社またはその他のエンティティを識別します。証明書は、そのアイデンティティと秘密鍵を関連付けます。運転免許証、パスポートまたは一般に使用されるその他の個人のIDと同様に、証明書は、誰かまたは何かのアイデンティティの一般に認識されている証拠を提供します。

認証局(CA)は、アイデンティティを検証し、証明書を発行します。CAは、独自の証明書発行サーバー・ソフトウェアを実行する独立したサード・パーティまたは組織です。アイデンティティの検証に使用される方法は、指定されたCAのポリシーによって異なります。一般には、証明書の発行前に、CAは、証明書の発行をリクエストしているエンティティが、実際に要求している本人であることを確認するために、証明書のその種類用に公開されている検証手順を使用する必要があります。

CAによって発行された証明書は、特定の秘密鍵をその証明書が識別するエンティティの名前(従業員またはサーバーの名前など)にバインドします。証明書は、なりすまし用の偽の秘密鍵の使用を防ぐのに役立ちます。証明書によって認証された公開鍵のみが、その証明書によって識別されたエンティティが保有する対応する秘密鍵と機能します。

公開鍵に加え、常に、証明書には、それが識別するエンティティの名前、有効期限、その証明書を発行したCAの名前、シリアル番号およびその他の情報が含まれます。最も重要なことは、証明書には発行したCAのデジタル署名が常に含まれています。CAのデジタル署名によって、証明書は、証明書によって識別されたエンティティは知らないが、そのCAを認識して信頼するユーザーにとっての「紹介状」として機能できます。

証明書をサポートするすべてのクライアント・ソフトウェアまたはサーバー・ソフトウェアは、信頼できるCAの証明書の集合を維持します。これらのCA証明書は、ソフトウェアが検証できる他の証明書を特定、つまり、ソフトウェアが信頼できる証明書の発行者を特定します。最も簡単な場合、ソフトウェアは、証明書を保持しているCAの1つによって発行された証明書のみを検証できます。また、信頼されたCA証明書は、証明書の階層でそれより上位にあるCAによってそれぞれが発行されたCA証明書のチェーンの一部になることができます。

CAの詳細は、次の各項を参照してください。

- CA階層

- 証明書チェーン

- 証明書チェーンの検証

5.3.6.2.1 CA階層

大規模な組織では、証明書の発行に対する責任を異なる複数の認証局に委任することが適切な場合があります。たとえば、単一のCAでは維持できないほど必要な証明書の数が多い場合、それぞれの組織単位で異なるポリシー要件が必要な場合、証明書を発行する人々と同じ地理的な場所に物理的に位置することがCAによって重要な場合です。

証明書発行の責任を下位のCAに委任することができます。X.509規格には、CAの階層を設定するためのモデルが含まれています。

図5-3 認証局の階層

「図5-3 認証局の階層」の説明

このモデルでは、ルートCAが階層の最上位にあります。ルートCAの証明書は、自己署名証明書です。つまり、証明書は、証明書が識別するのと同じエンティティ(ルートCA)によってデジタル署名されます。ルートCAの直下にあるCAには、ルートCAによって署名されたCA証明書があります。階層で、下位のCAの下にあるCAには、より上位レベルにある下位CAによって署名されたCA証明書があります。

組織は、独自のCA階層を設定する方法に関して、非常に高い柔軟性を持っています。図5-3には、1つの例のみを示しますが、多数の他の配置が可能です。

5.3.6.2.2 証明書チェーン

CA階層は証明書チェーンに反映されます。証明書チェーンは、連続するCAによって発行された一連の証明書です。図5-4に、(次の図に示すCA階層に基づいて) 2つの下位CA証明書を介していくつかのエンティティを識別する証明書からルートCAのCA証明書までの証明書チェーンを示します。

図5-4 証明書チェーン

「図5-4 証明書チェーン」の説明

証明書チェーンは、階層内のブランチから階層のルートまでの証明書の経路をたどります。証明書チェーンでは、次のことが発生します。

- 各証明書の後にその発行者の証明書が続きます。

- 図5-4では、Engineering CA証明書にはその証明書を発行したCA (つまり、USA CA)のDNが含まれています。USA CAのDNは、チェーン内の次の証明書のサブジェクト名でもあります。

- 各証明書は、発行者の秘密鍵を使用して署名されます。署名は、発行者の証明書(チェーンの次の証明書)内の公開鍵を使用して検証できます。

図5-4では、USA CAの証明書内の公開鍵は、Engineering CAの証明書上のUSA CAのデジタル署名を検証するために使用できます。

5.3.6.2.3 証明書チェーンの検証

証明書チェーンの検証は、指定された証明書チェーンが適格で、有効で、適切に署名され、信頼できることを確認する過程です。Directory Serverソフトウェアは、証明書チェーンの形成および検証を、認証のために提示された証明書から次の手順を使用して始めます。

1. 証明書の有効期間は、検証装置のシステム時計で提供される現在の時間と照合されます。

2. 発行者の証明書が特定されます。ソースは、検証者のローカル証明書データベース(クライアントまたはサーバー上)またはサブジェクトによって指定されている証明書チェーン(SSL接続経由など)のいずれかになります。

3. 証明書の署名は、発行者の証明書の公開鍵を使用して検証されます。

4. 発行者の証明書が、検証者の証明書データベース内の検証者によって信頼される場合は、検証は成功し、ここで終了します。それ以外の場合は、発行者の証明書にDirectory Server証明書タイプの拡張の適切な下位のCA表示が含まれていることを確認するために確認され、チェーンの検証は手順1に戻り、この新しい証明書を使用して再び開始されます。

図5-5 証明書チェーンの検証

「図5-5 証明書チェーンの検証」の説明

図5-5に、検証者のローカル・データベースにルートCAのみが含まれている場合の動作を示します。図5-6に示す中間CAの1つの証明書(Engineering CAなど)が検証者のローカル・データベースに見つかった場合、図に示すとおり、検証はその証明書で停止します。

図5-6 中間CAに対する証明書チェーンの検証

「図5-6 中間CAに対する証明書チェーンの検証」の説明

証明書チェーン内のどの時点でも、有効期限切れ、無効な署名または発行したCAの証明書がないことによって、認証は失敗します。たとえば、次の図に、検証者のローカル・データベースにルートCAの証明書または中間CAの証明書が含まれていない場合に、検証がどのように失敗するのかを示します。

図5-7 検証できない証明書チェーン

「図5-7 検証できない証明書チェーン」の説明

デジタル署名が機能する方法の概要は、「デジタル署名」を参照してください。

5.3.6.3 証明書のタイプ

Directory Serverは、次のタイプの証明書を使用します。

クライアントSSL証明書

クライアントSSL証明書は、サーバーに対してSSL (クライアント認証)を介してクライアントを識別するために使用されます。一般に、クライアントのアイデンティティは、企業の従業員などの人間のアイデンティティと同様であると考えられています。クライアントSSL証明書は、フォームの署名に使用され、シングル・サインオン・ソリューションの一部として使用できます。

たとえば、銀行は顧客に対してクライアントSSL証明書を提供し、銀行のサーバーがその顧客を識別して、顧客のアカウントへのアクセスを許可することが可能です。会社は新しい従業員に対してクライアントSSL証明書を提供し、会社のサーバーがその従業員を識別して、会社のサーバーへのアクセスを許可することが可能な場合があります。

サーバーSSL証明書

サーバーSSL証明書は、クライアントに対してSSL (サーバー認証)を介してサーバーを識別するために使用されます。サーバー認証は、クライアント認証を使用してまたは使用せずに、使用することができます。サーバー認証は、暗号化されたSSLセッションの要件です。

たとえば、電子商取引に携わるインターネット・サイトは通常、少なくとも証明書ベースのサーバー認証をサポートして、暗号化SSLセッションを確立し、顧客が特定の会社であることが確認されたWebサイトと取引することを保証します。暗号化SSLセッションでは、ネットワークを介して送信されるクレジット・カード番号などの個人情報が簡単に傍受されないことを保証します。

S/MIME証明書

S/MIME証明書は、署名および暗号化された電子メールで使用されます。クライアントSSL証明書と同様に、クライアントのアイデンティティは、一般に、企業の従業員などの人間のアイデンティティと同様であると考えられています。単一の証明書がS/MIME証明書およびSSL証明書の両方で使用されることがあります。S/MIME証明書は、フォームの署名に使用され、シングル・サインオン・ソリューションの一部として使用できます。

たとえば、会社は、従業員のアイデンティティを認証する目的で、S/MIME証明書とSSL証明書を組み合せて配置し、これによって署名された電子メールおよびクライアントSSL認証は許可しますが、暗号化された電子メールは許可しません。別の会社は、機密に属する財務または法的事項を扱う署名および暗号化された電子メールの両方を目的として、S/MIME証明書を発行します。

オブジェクト署名証明書

オブジェクト署名証明書は、Javaコード、JavaScriptのスクリプトまたはその他の署名されたファイルの署名者を識別するために使用されます。

たとえばソフトウェア会社は、そのソフトウェアがその会社の正規の製品であるという保証をユーザーに与えるために、インターネットを介して配布されるソフトウェアに署名します。証明書およびデジタル署名をこの方法で使用することによって、ダウンロードしたソフトウェアがコンピュータに対して行うアクセスの種類を、ユーザーが識別および制御することも可能になります。

CA証明書

CA証明書は、CAの識別に使用されます。クライアント・ソフトウェアおよびサーバー・ソフトウェアは、CA証明書を使用して、信用できる他の証明書を識別します。

たとえば、クライアント・ソフトウェアに格納されたCA証明書は、クライアントが認証できる他の証明書を判別します。管理者は、各ユーザーのクライアントに格納されたCA証明書を制御することによって、会社のセキュリティ・ポリシーの一部を実装できます。

5.3.6.4 証明書の内容

Directory Serverおよびその他多数のソフトウェア会社によってサポートされる証明書の内容は、国際的基準策定団体である国際電気通信連動(ITU)によって1988年から推奨されているX.509 v3の証明書仕様に従って編成されています。この項の例は、証明書のデータおよび署名セクションの例を示します。

すべてのX.509証明書は、次の各セクションで構成されています。

- データ・セクションには、次の情報が含まれます。

- 証明書でサポートされるX.509規格のバージョン番号。

- 証明書のシリアル番号。CAによって発行されるすべての証明書には、そのCAで発行される証明書間で一意のシリアル番号があります。

- 使用されたアルゴリズムおよび鍵自身の表現を含む、ユーザーの公開鍵に関する情報。

- その証明書を発行したCAのDN。

- 証明書が有効である期間(2003年11月15日の午後1時から2004年11月15日の午後1時までなど)。

- 証明書のサブジェクトのDN (たとえば、クライアントSSL証明書ではユーザーのDN)、サブジェクト名と呼ばれます。

- オプションの証明書拡張要素、クライアントまたはサーバーで使用される追加データを提供する場合があります。たとえば、証明書タイプの拡張は、証明書のタイプ、つまり、それがクライアントSSL証明書か、サーバーSSL証明書か、署名付き電子メールに対する証明書かどうかなどを示します。証明拡張要素は、他の様々な目的で使用することもできます。

- 署名セクションには、次の情報が含まれます。

- 発行CAによって自身のデジタル書名を作成するために使用される暗号アルゴリズム(暗号)。

- 証明書内のすべてのデータを一緒にハッシュし、CAの秘密鍵を使用して暗号化することで取得されるCAのデジタル署名。

例5-1 証明書の人間が判読可能な形式でのデータ・セクションおよび署名セクション

Certificate:
Data:
Version: v3 (0x2)
Serial Number: 3 (0x3)
Signature Algorithm: PKCS #1 MD5 With RSA Encryption
Issuer: OU=Certificate Authority, O=Example Industry, C=US
Validity:
Not Before: Fri Oct 17 18:36:25 2003
Not  After: Sun Oct 17 18:36:25 2004
Subject: CN=Jane Doe, OU=Finance, O=Example Industry, C=US
Subject Public Key Info:
Algorithm: PKCS #1 RSA Encryption
Public Key:
Modulus:
00:ca:fa:79:98:8f:19:f8:d7:de:e4:49:80:48:e6:2a:2a:86:
ed:27:40:4d:86:b3:05:c0:01:bb:50:15:c9:de:dc:85:19:22:
43:7d:45:6d:71:4e:17:3d:f0:36:4b:5b:7f:a8:51:a3:a1:00:
98:ce:7f:47:50:2c:93:36:7c:01:6e:cb:89:06:41:72:b5:e9:
73:49:38:76:ef:b6:8f:ac:49:bb:63:0f:9b:ff:16:2a:e3:0e:
9d:3b:af:ce:9a:3e:48:65:de:96:61:d5:0a:11:2a:a2:80:b0:
7d:d8:99:cb:0c:99:34:c9:ab:25:06:a8:31:ad:8c:4b:aa:54:
91:f4:15
Public Exponent: 65537 (0x10001)
Extensions:
Identifier: Certificate Type
Critical: no
Certified Usage:
SSL Client
Identifier: Authority Key Identifier
Critical: no
Key Identifier:
f2:f2:06:59:90:18:47:51:f5:89:33:5a:31:7a:e6:5c:fb:36:
26:c9
Signature:
Algorithm: PKCS #1 MD5 With RSA Encryption
Signature:
6d:23:af:f3:d3:b6:7a:df:90:df:cd:7e:18:6c:01:69:8e:54:65:fc:06:
30:43:34:d1:63:1f:06:7d:c3:40:a8:2a:82:c1:a4:83:2a:fb:2e:8f:fb:
f0:6d:ff:75:a3:78:f7:52:47:46:62:97:1d:d9:c6:11:0a:02:a2:e0:cc:
2a:75:6c:8b:b6:9b:87:00:7d:7c:84:76:79:ba:f8:b4:d2:62:58:c3:c5:
b6:c1:43:ac:63:44:42:fd:af:c8:0f:2f:38:85:6d:d6:59:e8:41:42:a5:
4a:e5:26:38:ff:32:78:a1:38:f1:ed:dc:0d:31:d1:b0:6d:67:e9:46:a8:
d:c4

例5-2 ソフトウェアによって解読される64バイトでエンコードされた形式での証明書

-----BEGIN CERTIFICATE-----
MIICKzCCAZSgAwIBAgIBAzANBgkqhkiG9w0BAQQFADA3MQswCQYDVQQGEwJVUzER
MA8GA1UEChMITmV0c2NhcGUxFTATBgNVBAsTDFN1cHJpeWEncyBDQTAeFw05NzEw
MTgwMTM2MjVaFw05OTEwMTgwMTM2MjVaMEgxCzAJBgNVBAYTAlVTMREwDwYDVQQK
EwhOZXRzY2FwZTENMAsGA1UECxMEUHViczEXMBUGA1UEAxMOU3Vwcml5YSBTaGV0
dHkwgZ8wDQYJKoZIhvcNAQEFBQADgY0AMIGJAoGBAMr6eZiPGfjX3uRJgEjmKiqG
7SdATYazBcABu1AVyd7chRkiQ31FbXFOGD3wNktbf6hRo6EAmM5/R1AskzZ8AW7L
iQZBcrXpc0k4du+2Q6xJu2MPm/8WKuMOnTuvzpo+SGXelmHVChEqooCwfdiZywyZ
NMmrJgaoMa2MS6pUkfQVAgMBAAGjNjA0MBEGCWCGSAGG+EIBAQQEAwIAgDAfBgNV
HSMEGDAWgBTy8gZZkBhHUfWJM1oxeuZc+zYmyTANBgkqhkiG9w0BAQQFAAOBgQBt
I6/z07Z635DfzX4XbAFpjlRl/AYwQzTSYx8GfcNAqCqCwaSDKvsuj/vwbf91o3j3
UkdGYpcd2cYRCgKi4MwqdWyLtpuHAH18hHZ5uvi00mJYw8W2wUOsY0RC/a/IDy84
hW3WWehBUqVK5SY4/zJ4oTjx7dwNMdGwbWfpRqjd1A==
-----END CERTIFICATE-----

5.3.6.5 証明書の管理

ネットワーク環境での公開鍵暗号化およびX.509 v3の証明書の使用を容易にする標準およびサービスのセットは、公開鍵インフラストラクチャ(PKI)と呼ばれます。Directory Serverで対処される証明書管理の問題の詳細は、次の各項を参照してください。

- 証明書の発行

- 証明書およびLDAPディレクトリ

- 鍵の管理

- 証明書の更新および失効

- 登録局

5.3.6.5.1 証明書の発行

証明書の発行プロセスは、発行する認証局および使用目的によって異なります。非デジタル形式の識別情報の発行プロセスも同様に異なります。たとえば、カリフォルニアの車両管理局から一般的なIDカード(運転免許証ではなく)を取得する場合、住所が記載された公共料金の請求書や学生証などのアイデンティティを証明するものを提示する必要があるという具合に、要件は単純です。通常の運転免許証を取得する場合は、試験(初めて免許を取得する場合は運転の試験を、更新の場合は筆記試験)も受ける必要があります。18輪トラックの第2種運転免許を取得する場合は、要件はより厳しくなります。他の州や国に住んでいる場合、様々な種類の免許に対する要件は異なります。

同様に、それぞれのCAには、様々な種類の証明書の発行に異なる手順があります。郵便の宛先が唯一の要件である場合もあります。UNIXのログインおよびパスワードで十分な場合もあります。基準の反対側の端では、大規模な出費する権限を与えたり、慎重に扱うべき決定をする人を識別するための証明書では、公正証書、身元調査および個人面接が発行プロセスで必要になる場合があります。

組織のポリシーに応じて、証明書の発行プロセスは、ユーザーに対して完全に透過的なものからかなりのユーザー参加と複雑な手順が必要なものまで多岐にわたります。一般に、証明書の発行プロセスは、組織が変化するニーズにプロセスを適応させることができるように、高度に柔軟である必要があります。

証明書の発行は、個々の登録局によって処理可能な複数の管理タスクの1つです。

5.3.6.5.2 証明書およびLDAPディレクトリ

ディレクトリ・サービスにアクセスするためのLightweight Directory Access Protocol (LDAP)は、組織内の証明書の管理における高柔軟性をサポートします。システム管理者は、証明書の管理に必要な情報の多くをLDAP準拠のディレクトリに格納できます。たとえば、CAは、ディレクトリ内の情報を使用して、新しい従業員の氏名およびその他の情報を使用して証明書を事前移入できます。CAは、指定された組織のセキュリティ・ポリシーに応じた様々な識別技術を使用して、証明書を1つずつまたはまとめて発行するための他の方法でディレクトリ情報を使用できます。鍵の管理および証明書の更新や失効などのその他の日常的な管理タスクは、このディレクトリを活用して一部または完全に自動化できます。

ディレクトリに格納された情報は、様々なユーザーまたはグループごとに各種のネットワークリソースに対するアクセスを制御するために、証明書で使用することもできます。そのため、証明書の発行およびその他の証明書の管理タスクは、ユーザーおよびグループの管理の不可欠な部分になります。

5.3.6.5.3 鍵の管理

証明書を発行する前に、証明書に含まれる公開鍵および対応する秘密鍵を生成する必要があります。1人に対して、署名操作には1つの証明書と鍵のペアを発行し、暗号化操作には別の証明書と鍵のペアを発行することが有効な場合もあります。署名と暗号化の証明書を分けることで、秘密の署名鍵をローカル・マシンのみに保持し(これにより最大の非拒否が提供され)、ユーザーが元の鍵を失くしたり会社を辞める場合に取得できるように、秘密の暗号化鍵を中央の場所のどこかにバックアップすることが可能になります。

鍵は、クライアント・ソフトウェアによって、またはCAによって集中的に生成でき、LDAPディレクトリを介してユーザーに配布できます。ローカルおよび集中型の鍵生成の選択の際には、トレードオフが関係します。たとえば、ローカル鍵生成では最大の非拒否が提供されますが、発行プロセスにはユーザーの参加がより多く伴う場合があります。柔軟なキー管理機能は、ほとんどの組織にとって不可欠です。

鍵のリカバリ、つまり注意深く定義された条件下での暗号化鍵のバックアップを取得する機能は、証明書管理の重要な要素となります(組織の証明書の使用方法に応じて)。鍵のリカバリ・スキームには通常、M of Nメカニズムを必要としますが、たとえば、特定の人の暗号化鍵をリカバリする前には、組織のM of N人のマネージャが同意する必要があり、それぞれが独自の特別なコードまたはキーを提供します。この種のメカニズムでは、暗号化鍵をリカバリする前に、複数の関係者の同意が必要になります。

5.3.6.5.4 証明書の更新および失効

運転免許証と同様に、証明書はそれが有効である期間を指定します。有効期間の前または後に、認証に証明書を使用しようとすると失敗します。そのため、証明書更新を管理するためのメカニズムは、すべての証明書管理計画で不可欠のものです。たとえば管理者は、証明書のサブジェクトで不都合が発生しないように、適切な更新プロセスが時間に余裕を持って完了するように、有効期限が近くなったら自動的に通知されるようにする場合もあります。更新プロセスでは、同じ公開鍵と秘密鍵のペアを再使用する場合や、新しい鍵を発行する場合があります。

運転免許証は、たとえば重大な運転違反の処罰として、期限切れでない場合でも一時停止できます。同様に、従業員が会社を辞める場合や会社内の他の仕事に移る場合などに、期限が切れる前に証明書を失効する必要がある場合があります。

証明書の失効は、複数の異なる方法で処理できます。提示された証明書がディレクトリに存在することの確認を認証プロセス含むようにサーバーを設定することで十分な組織もあります。管理者が証明書を失効させると、その証明書はディレクトリから自動的に削除され、その後のその証明書を使用した認証の試行は、その他すべての箇所で有効のままであっても失敗します。別の方法では、ディレクトリに対して定期的に証明書失効リスト(CRL) (失効した証明書のリスト)を発行し、認証プロセスの一部としてリストを確認することを含みます。ある組織では、認証のために証明書が提示されるたびに発行CAに直接問い合わせることが望ましい場合もあります。この方法は、リアルタイム・ステータス・チェックと呼ばれることもあります。

5.3.6.5.5 登録局

証明書によって識別されたエンティティ(エンド・エンティティとも呼ばれます)とCA間の相互作用は、証明書管理の不可欠な部分です。これらの相互作用には、証明書の登録、証明書の取得、証明書の更新、証明書の失効、鍵のバックアップおよびリカバリなどの操作が含まれます。通常CAは、リクエストに応答する前に、エンド・エンティティのアイデンティティを認証できる必要があります。さらに、提供される前に、認可された管理者またはマネージャによって承認される必要のあるリクエストもあります。

前述のとおり、証明書を発行する前にアイデンティティを検証するために使用される方法は、証明書が使用される組織および目的に応じて、CAごとに大きく異なります。運用上の最大の柔軟性を提供するために、エンド・エンティティとの相互作用をCAの他の機能と切り離し、登録局(RA)と呼ばれる別のサービスによって処理することが可能です。

RAは、エンド・エンティティのリクエストを受信し、それらを認証し、それらをCAに転送することで、CAのフロント・エンドとして機能します。CAから応答を受信した後、RAはエンド・エンティティに結果を通知します。RAは、PKIを別の部署、地理的なエリアまたは異なるポリシーおよび認証要件を使用する他の運営単位に拡大する際に役立ちます。

5.3.7 SASLベースの認証

SSLまたはTLS接続時のクライアント認証では、Simple Authentication and Security Layer (SASL)も使用できます。Directory Serverでは、SASLメカニズムをサポートしています。

DIGEST-MD5

DIGEST-MD5メカニズムは、クライアントによって送信されたハッシュされた値をユーザーのパスワードのハッシュと比較することによって、クライアントを認証します。ただし、このメカニズムはユーザー・パスワードを読み取る必要があるため、DIGEST-MD5による認証を希望するすべてのユーザーは、ディレクトリ内にクリアテキストのパスワードを持つ必要があります。

GSSAPI

GSSAPI は、Solarisオペレーティング・システムのみで使用できます。General Security Services API (GSSAPI)では、ユーザーを識別するためのDirectory ServerによるKerberos V5セキュリティ・システムとの対話が可能です。クライアント・アプリケーションは、Kerberosシステムに資格証明を提示する必要があり、これによって、Directory Serverに対してユーザーのアイデンティティが検証されます。

SASLベースの認証の構成方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の資格証明レベルおよび認証方法の構成に関する説明を参照してください。

5.4 Directory Serverの暗号化の提供方法

Directory Serverがデータを暗号化する方法の詳細は、次の各項を参照してください。

- Secure Sockets Layer(SSL)

- デジタル署名

- 鍵の暗号化

- 属性の暗号化

5.4.1 Secure Sockets Layer(SSL)

SSLは、暗号化された通信およびオプションとしてDirectory Serverとクライアントの間の認証を提供します。SSLは、LDAPを介して、またはHTTP経由のDSMLで使用できます。SSLは、LDAP上ではデフォルトで有効であり、HTTP経由のDSMLを有効にできます。

サーバー間のセキュアな通信にSSLを使用するように、レプリケーションを構成できます。レプリケーションがSSLを使用するように構成されている場合、サーバーに対して送受信されるデータは、SSLを使用して暗号化されます。

デフォルトでは、Directory Serverでは、異なるポート番号を要求する保護と非保護の同時通信が可能です。保護されていないLDAP通信は、1つのポート(慣例的にポート番号389)上で処理されます。セキュアなLDAP通信は、別のポート(慣例的にポート番号636)上で処理されます。

また、セキュリティ上の理由から、すべての通信をセキュアなポートに限定することもできます。クライアント認証も構成できます。クライアント認証を必要とする、または許可するように設定できます。この設定によって、実行するセキュリティのレベルが決定されます。

SSLによって、通常のLDAP接続をセキュリティ保護するStart TLS拡張処理のサポートも有効になります。クライアントはSSL以外のポートにバインドでき、トランスポート層セキュリティ・プロトコルを使用してSSL接続を開始できます。Start TLS処理では、クライアントに一層の柔軟性が与えられ、ポートの割当ても簡素化できます。

SSLの詳細は、次の各項を参照してください。

- SSLの概要

- SSLで使用される暗号化アルゴリズム

- SSLハンドシェイク

5.4.1.1 SSLの概要

TCP/IPは、インターネットを介したデータの転送およびルーティングを制御します。HTTP、LDAP、IMAPなどのその他のプロトコルは、TCP/IPを使用して、Webページの表示やメール・サーバーの運用などの標準のアプリケーション・タスクをサポートします。

図5-8 SSLが実行される場所

「図5-8 SSLが実行される場所」の説明

SSLプロトコルは、TCP/IPの上、HTTPまたはIMAPといった上位レベルのプロトコルの下で実行されます。上位レベルのプロトコルのかわりにTCP/IPを使用し、プロセスでは、SSL対応のサーバーによるSSL対応のクライアントに対する自身の認証を可能にし、クライアントによるサーバーに対する自身の認証を可能にし、両方のマシンが暗号化接続を確立するのを可能にします。

SSLは、インターネットおよびその他のTCP/IPネットワークを介した通信に関する問題に対処します。

SSLサーバー認証では、ユーザーがサーバーのアイデンティティを確認できます。

SSL対応のクライアント・ソフトウェアは、公開鍵暗号化の標準的な技術を使用して、サーバーの証明書および公開IDが有効で、クライアントの信頼できるCAのリストにリストされている認証局(CA)で発行されたことを確認できます。たとえば、ユーザーがネットワークを介してクレジット・カード番号を送信する際に受信するサーバーのアイデンティティを確認する場合に、この確認が重要になることがあります。

SSLクライアント認証では、サーバーがユーザーのアイデンティティを確認できます。

サーバー認証で使用する同じ技術を使用して、SSL対応のサーバー・ソフトウェアは、クライアントの証明書および公開IDが有効で、サーバーの信頼できるCAのリストにリストされている認証局(CA)で発行されたことを確認できます。たとえば、サーバーが親展の財務情報を顧客に送信する銀行で、受信者のアイデンティティを確認が必要な場合に、この確認が重要になることがあります。

暗号化されたSSL接続では、クライアントおよびサーバー間で送信されるすべての情報が、送信ソフトウェアを使用して暗号化され受信ソフトウェアで復号化される必要があり、これによって、高度の機密保護が提供されます。

機密保護は、両者にとってすべてのプライベート・トランザクションで重要です。さらに、暗号化SSL接続を使用して送信されるすべてのデータは、改ざんを検出する(送信中にデータが変更されたかどうかを自動的に判断する)ためのメカニズムを使用して保護されます。

SSLプロトコルには、SSLレコード・プロトコルおよびSSLハンドシェイク・プロトコルの2つのプロトコルが含まれます。

SSLレコード・プロトコルは、データの送信に使用される形式を定義します。SSLハンドシェイク・プロトコルでは、SSLレコード・プロトコルを使用して、SSL対応のサーバーとSSL対応のクライアント間で最初にSSL接続が確立されたときに、一連のメッセージを交換することが要求されます。このメッセージの交換は、次のアクションを容易にするために設計されています。

- クライアントに対してサーバーを認証します。

- クライアントおよびサーバーによる、両方がサポートする暗号化アルゴリズム(暗号)の選択を可能にします。

- オプションで、サーバーに対してクライアントを認証します。

- 公開鍵暗号化技術を使用して共有秘密を生成します。

- 暗号化されたSSL接続を確立します。

ハンドシェイク・プロセスの詳細は、「SSLハンドシェイク」を参照してください。

5.4.1.2 SSLで使用される暗号化アルゴリズム

暗号スイートは、SSL通信の次の側面を定義します。

- キー交換アルゴリズム

- 暗号化暗号

- 暗号化暗号の鍵の長さ

- メッセージ認証方式

SSLプロトコルでは多数の暗号がサポートされています。クライアントおよびサーバーは、サポートするSSLのバージョン、および許容される暗号化強度に関する会社のポリシーなどの要因によって、様々な暗号スイートをサポートできます。SSLハンドシェイク・プロトコルでは、相互に認証するため、証明書を転送するためおよびセッション・キーを確立するために使用する暗号スイートについて、サーバーとクライアント間での交渉方法を決定します。

SSL 2.0プロトコルおよびSSL 3.0プロトコルでは、暗号スイートの重複設定がサポートされています。管理者は、クライアントとサーバーの両方でサポートされている任意の暗号スイートを有効化または無効化できます。SSLハンドシェイク時にサーバーとクライントで情報を交換する際、共通して持っている有効化されていて最も強力な暗号スイートを特定し、SSLセッションで使用します。有効化する暗号スイートに関する決定は、関係するデータの機密性、暗号の速度およびエクスポート・ルールの適用性に依存します。

KEA、RSAなどのキー交換アルゴリズムは、サーバーおよびクライアントがSSLセッションで使用する対称鍵を決定する方法を制御します。最も一般的に使用されるSSL暗号スイートでは、RSAキー交換が使用されます。

Directory Serverで有効化できる暗号のリスト、およびDirectory Serverでサポートされる暗号のリストは、dsconfコマンドを使用して取得できます。dsconfコマンドを使用した使用可能な暗号のリストおよび暗号の管理の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の暗号化暗号の選択に関する説明を参照してください。

暗号に対するサポートは、ネットワーク・セキュリティ・サービス(NSS)のコンポーネントによって提供されます。NSSの詳細は、NSSのプロジェクト・サイト(http://www.mozilla.org/projects/security/pki/nss/)を参照してください。

5.4.1.3 SSLハンドシェイク

SSLプロトコルは、公開鍵および対称鍵暗号化の組合せを使用します。対称鍵暗号化は公開鍵暗号化よりはるかに高速ですが、公開鍵暗号化はより優れた認証技術を提供します。SSLセッションは、常にSSLハンドシェイクと呼ばれるメッセージの交換から開始されます。ハンドシェイクでは、サーバーは、公開鍵技術を使用してクライアントに対して自身を認証でき、その後、クライアントおよびサーバーは、高速暗号化、復号化および改ざん検出に使用される対称鍵を協働して作成できます。ハンドシェイクでは、オプションで、サーバーに対するクライアント自身の認証も可能です。

SSLハンドシェイクの詳細は、次の各項を参照してください。

- SSLハンドシェイクでのメッセージ交換

- SSLハンドシェイクでのサーバー認証

- 中間者攻撃

- SSLハンドシェイクでのクライアント認証

5.4.1.3.1 SSLハンドシェイクでのメッセージ交換

次の手順では、SSLハンドシェイクでのメッセージ交換の順序を説明します。これらの手順は、SSLハンドシェイクで交換されるメッセージのプログラム的な詳細を説明します。

1. クライアントは、サーバーに対して、クライアントのSSLバージョン番号、暗号設定、ランダムに生成されたデータおよびサーバーがSSLを使用してクライアントと通信するために必要なその他の情報を送信します。

2. サーバーは、クライアントに対して、サーバーのSSLバージョン番号、暗号設定、ランダムに生成されたデータおよびクライアントがSSLを使用してサーバーと通信するために必要なその他の情報を送信します。さらにサーバーは、自身の証明書を送信し、クライアント認証が必要なサーバー・リソースをクライアントがリクエストしている場合は、クライアントの証明書をリクエストします。

3. クライアントは、サーバーによって送信された情報の一部を使用して、サーバーを認証できます。詳細は、「SSLハンドシェイクでのサーバー認証」を参照してください。サーバーが認証できない場合、ユーザーは問題を警告され、暗号化された認証接続が確立できないことが通知されます。サーバーの認証に成功した場合、クライアントは手順4に進みます。

4. ハンドシェイクでここまでに生成されたすべてのデータを使用して、クライアントは、(サーバーの協力で)使用する暗号に応じて、セッションのプリマスタ・シークレットを作成し、(手順2で送信されたサーバーの証明書から取得した)サーバーの公開鍵を使用してそれを暗号化し、暗号化されたプリマスタ・シークレットをサーバーに送信します。

5. サーバーがクライアント認証をリクエストしている(ハンドシェイクのオプションの手順)場合、クライアントは、このハンドシェイクに一意で、クライアントとサーバーの両方で認識されている別のデータにも署名します。この場合、クライアントは署名済データおよびクライアント自身の証明書を、暗号化されたプリマスタ・シークレットとともにサーバーに送信します。

6. サーバーがクライアント認証をリクエストしている場合、サーバーはクライアントの認証を試みます。詳細は、「SSLハンドシェイクでのサーバー認証」を参照してください。クライアントが認証できない場合、セッションは終了します。クライアントの認証に成功すると、サーバーは自身の秘密鍵を使用してプリマスタ・シークレットを復号化し、一連の手順を実行(同じプリマスタ・シークレットから、クライアントも実行)してマスター・シークレットを生成します。

7. クライアントおよびサーバーの両方は、マスター・シークレットを使用してセッション・キーを生成しますが、これはSSLセッションで情報の暗号化および復号化およびその整合性の検証(SSL接続を介した送信時と受信時の間のデータの変更を検出する)に使用される対称鍵です。

8. クライントは、今後、クライアントからのメッセージはこのセッション・キーを使用して暗号化されることを通知するメッセージをサーバーに送信します。その後、ハンドシェイクのクライアント部分が終了したことを示す(暗号化された)別のメッセージを送信します。

9. サーバーは、今後、サーバーからのメッセージはこのセッション・キーを使用して暗号化されることを通知するメッセージをクライアントに送信します。その後、ハンドシェイクのサーバー部分が終了したことを示す(暗号化された)別のメッセージを送信します。

10. これでSSLハンドシェイクが完了し、SSLセッションが開始されます。クライアントおよびサーバーは、セッション・キーを使用して、相互に送信するデータを暗号化および復号化し、その整合性を検証します。

セッションを継続する前に、クライアントの証明書がLDAPディレクトリのユーザーのエントリに存在することを確認するようにDirectory Serverを構成できます。この確認オプションは、クライアントの証明書が失効していないことを確認するための1つの方法を提供します。

クライアントおよびサーバー認証のどちらも、秘密鍵と公開鍵のペアの片方の鍵を使用してデータの一部を暗号化し、もう片方の鍵を使用してそれを復号化する必要があります。

- サーバー認証の場合、クライアントは、サーバーの公開鍵を使用してプリマスタ・シークレットを暗号化します。対応する秘密鍵でのみシークレットを正しく復号化できるため、クライアントは、公開鍵に関連付けられているアイデンティティが、クライアントが実際に接続しているサーバーであることの保証が得られます。それ以外の場合、サーバーはプリマスタ・シークレットを復号化できず、セッションに必要な対称鍵を生成できないため、セッションは終了します。

- クライアント認証の場合、クライアントは、クライアントの秘密鍵を使用してランダム・データの一部を暗号化(つまり、デジタル署名を作成)します。クライアントの証明書の公開鍵は、対応する秘密鍵が使用された場合のみデジタル署名を正しく検証できます。それ以外の場合、サーバーはデジタル署名を検証できないため、セッションは終了します。

5.4.1.3.2 SSLハンドシェイクでのサーバー認証

SSL対応のクライアント・ソフトウェアは、常にサーバー認証、またはサーバーのアイデンティティのクライアントによる暗号化の検証が必要です。サーバーは、自身を認証するために、クライアントに対して証明書を送信します。クライアントは、その証明書を使用して、証明書が表すことを主張するアイデンティティを認証します。

公開鍵と公開鍵を含む証明書によって識別されるサーバー間のバインディングを認証するには、SSL対応のクライアントで、次の図に示す4つの質問に対してはいの回答を受信する必要があります。

図5-9 SSLハンドシェイクでのクライアントの証明書の認証

「図5-9 SSLハンドシェイクでのクライアントの証明書の認証」の説明

SSL対応のクライアントは、サーバーのアイデンティティを認証するために、次の手順を実行します。

1. 今日の日付は有効期限内ですか。
クライアントは、サーバーの証明書の有効期限を確認します。現在の日時がその範囲外の場合は、認証プロセスはこれ以降進みません。現在の日時が証明書の有効期限内の場合は、クライアントは次の手順に進みます。

2. 発行CAは信頼できるCAですか。
SSL対応の各クライアントは、図5-9の右側の網掛け部分で表される信頼できるCA証明書のリストを保持します。このリストで、クライアントが受け入れるサーバーの証明書を判断します。発行CAの識別名(DN)が、信頼できるCAのクライアントのリストにあるCAのDNと一致した場合、この質問に対する回答は「はい」となり、クライアントは次の手順に進みます。発行CAがリストにない場合、クライアントがリストにあるCAで終わる証明書チェーンを検証できないかぎり、サーバーは認証されません。

3. 発行CAの公開鍵は、発行者のデジタル署名を検証しますか。
クライアントは、CAの証明書(手順2の信頼できるCAのリストにある)からの公開鍵を使用して、提示されたサーバー証明書のCAのデジタル署名を検証します。CAによって署名された後にサーバーの証明書の情報が変更された場合またはCA証明書の公開鍵がサーバーの証明書を署名するためにCAによって使用された秘密鍵と一致しない場合は、クライアントはサーバーのアイデンティティを認証しません。CAのデジタル署名が検証できた場合、サーバーは、ユーザーの証明書をそのCAからの有効な「紹介状」として処理し、次に進みます。この時点でクライアントは、サーバーの証明書が有効であると判断します。

4. サーバーの証明書のドメイン名は、サーバー自身のドメイン名と一致しますか。
この手順は、サーバーの証明書にあるドメイン名によって指定されているものと同じネットワーク・アドレスに、このサーバーが実際に存在していることを確認します。手順4は、厳密にはSSLプロトコルの一部ではありませんが、これは、中間者攻撃と呼ばれるセキュリティ攻撃の一種に対する唯一の保護を提供します。クライアントはこの手順を実行して、ドメイン名が一致しない場合は、サーバーの認証または接続の確立を拒否する必要があります。サーバーの実際のドメイン名がサーバーの証明書のドメイン名と一致した場合、クライアントは次の手順に進みます。

5. サーバーは認証されました。
クライアントはSSLハンドシェイクを開始します。なんらかの理由でクライアントが手順5に到達しない場合は、証明書で識別されるサーバーは認証されないため、ユーザーは問題を警告され、暗号化された認証接続を確立できないことが通知されます。サーバーでクライアント認証が必要な場合は、サーバーは、「SSLハンドシェイクでのクライアントの認証」に記載されている手順を実行します。

ここに記載されている手順の後、サーバーは、自身の秘密鍵を使用してクライアントから送信されたプリマスタ・シークレットの復号化に成功する必要があります。

5.4.1.3.3 中間者攻撃

中間者攻撃とはローグ・プログラムで、クライアントとサーバー間でクライアントがSSLを介して通信を試行するすべての通信を傍受するプログラムです。ローグ・プログラムは、SSLハンドシェイクで往復して受け渡される正当な鍵を傍受し、自らの鍵で置き換え、自分をクライアントに対してはサーバーであるかのように、サーバーに対してはクライアントであるかのように見せます。

SSLハンドシェイクの最初に交換される暗号化された情報は、クライアントまたはサーバーの本物の鍵ではなく、ローグ・プログラムの公開鍵または秘密鍵を使用して実際に暗号化されます。最終的に、ローグ・プログラムは、本物のサーバーと使用するためのセッション・キーの1つのセットを、クライアントと使用するためのセッション・キーの別のセットを作成します。これによって、ローグ・プログラムは、クライアントと本物のサーバーの間に流れるすべてのデータを読み取れるだけでなく、削除することなくデータを変更できます。したがって、「SSLハンドシェイクでのサーバーの認証」に記載されているその他の手順を実行することで証明書の有効性を確認することに加えて、クライアントが通信を試みるサーバーのドメイン名とサーバーの証明書のドメイン名が一致するかどうかを確認することは、クライアントにとって非常に重要です。

5.4.1.3.4 SSLハンドシェイクでのクライアント認証

SSL対応のサーバーは、クライアント認証、またはクライアントのアイデンティティのサーバーによる暗号化の検証を必要とするように構成できます。サーバーがこのように構成されているとき、自身を認証するために、クライアント認証のデジタル署名された別のデータをリクエストします。サーバーは、デジタル署名されたデータを使用して証明書内の公開鍵を検証し、証明書が表すことを主張するアイデンティティを認証します。

SSLプロトコルでは、クライアントに対して、ハンドシェイク時にランダムに生成され、クライアントおよびサーバーのみが認識するデータから一方向ハッシュを作成することによってデジタル署名を作成することが要求されます。データのハッシュはその後、サーバーに提示された証明書の公開鍵と対応する秘密鍵を使用して暗号化されます。

公開鍵と公開鍵を含む証明書によって識別される人またはその他のエンティティ間のバインディングを認証するには、SSL対応のサーで、図5-10に示す最初の4つの質問に対してはいの回答を受信する必要があります。5番目の質問はSSLプロトコルの一部ではありませんが、認証プロセスの一部としてLDAPディレクトリのユーザー・エントリを活用するためにこの要件をサポートするように、Directory Serverを構成できます。

図5-10 SSLハンドシェイクでの認証および検証

「図5-10 SSLハンドシェイクでの認証および検証」の説明

SSL対応のサーバーは、ユーザーのアイデンティティを認証するために、次の手順を実行します。

1. ユーザーの公開鍵は、ユーザーのデジタル署名を検証しますか。
サーバーは、ユーザーのデジタル署名が証明書の公開鍵を使用して検証できることを確認します。できる場合、サーバーは、John Doeに属すと主張される公開鍵が署名を作成するために使用されたこと、およびデータは署名後に改ざんされていないことが証明されます。

ただし、この時点では、公開鍵と証明書で指定されたDN間のバインディングはまだ証明されていません。証明書は、ユーザーになりすますことを試みる誰かによって作成された可能性があります。公開鍵とDN間のバインディングを検証するには、サーバーは、このリストの手順3および4を完了する必要があります。

2. 今日の日付は有効期限内ですか。
サーバーは、クライアントの証明書の有効期限を確認します。現在の日時がその範囲外の場合は、認証プロセスはこれ以降進みません。現在の日時が証明書の有効期限内の場合は、サーバーは次の手順に進みます。

3. 発行CAは信頼できるCAですか。
SSL対応の各サーバーは、図5-10の右側の網掛け部分で表される信頼できるCA証明書のリストを保持します。このリストで、サーバーが受け入れる証明書を判断します。発行CAのDNが、信頼できるCAのサーバーのリストにあるCAのDNと一致した場合、この質問に対する回答は「はい」となり、サーバーは次の手順に進みます。発行CAがリストにない場合、サーバーが、クライアントおよびサーバーで保持されるCA証明書のリストを制御する組織内で信頼できるまたは信頼されないCAで終わる証明書チェーンを検証できないかぎり、クライアントは認証されません。

4. 発行CAの公開鍵は、発行者のデジタル署名を検証しますか。
サーバーは、CAの証明書(前述の手順の信頼できるCAのリストにある)からの公開鍵を使用して、提示された証明書のCAのデジタル署名を検証します。CAによって署名された後に証明書の情報が変更された場合またはCA証明書の公開鍵が証明書を署名するためにCAによって使用された秘密鍵と一致しない場合は、サーバーはユーザーのアイデンティティを認証しません。CAのデジタル署名が検証できた場合、サーバーは、ユーザーの証明書をそのCAからの有効な「紹介状」として処理し、次に進みます。この時点でSSLプロトコルでは、サーバーが、クライアントが認証されたとみなし、手順6の説明に従って接続に進むことを許可します。Directory Serverでは、手順6の前に手順5を実行するようにオプションで構成できます。

5. LDAPエントリにリストされているユーザーの証明書はそのユーザーのものですか。
このオプションの手順は、ユーザーの証明書が他のすべての手順のテストに合格したとしても、システム管理者がそれを失効させるための1つの方法を提供します。証明書管理システムは、失効した証明書をLDAPディレクトリのユーザーのエントリから自動的に削除できます。この手順を実行するように設定されているすべてのサーバーは、次にその証明書の認証または接続の確立を拒否します。ディレクトリ内のユーザーの証明書とSSLハンドシェイク時に提示されたユーザーの証明書が同じ場合は、サーバーは次の手順に進みます。

6. 認証されたクライアントは、リクエストされたリソースに対するアクセスが許可されていますか。
サーバーは、サーバーのアクセス制御リスト(ACL)に基づいて、クライアントがアクセスを許可されているリソースを確認し、適切なアクセスで接続を確立します。なんらかの理由でサーバーが手順6に到達しない場合は、証明書で識別されるユーザーを認証できないため、そのユーザーは、認証が必要なすべてのサーバー・リソースへのアクセスが許可されません。

5.4.2 デジタル署名

デジタル署名は、Directory Serverによって情報の整合性を保つために使用できます。送信される情報に暗号化およびメッセージ・ダイジェストが適用されている場合、受信者は、その情報が送信中に改ざんされていないと判断できます。

改ざん検出および関連する認証技術は、一方向ハッシュという数学関数に依存します。この関数は、メッセージ・ダイジェストとも呼ばれます。一方向ハッシュは、次の特性を持つ固定長の数字です。

- ハッシュの値はそのハッシュ・データに対して一意です。1文字の削除または変更でもデータを変更すると、異なる値になります。

- 事実上、ハッシュ・データの内容はハッシュからは予測できないため、一方向と呼ばれます。

暗号化に秘密鍵を使用し、復号化に公開鍵を使用することは可能です。これは機密情報を暗号化する際には望ましくありませんが、あらゆるデータをデジタル署名する場合の重要な部分です。データ自体を暗号化するかわりに、署名ソフトウェアでは、データの一方向ハッシュを作成し、秘密鍵を使用してそのハッシュを暗号化します。ハッシュ・アルゴリズムなどのその他の情報とともに暗号化されたハッシュは、デジタル署名と呼ばれます。図5-11に、署名されたあるデータの受信者に転送される2つのアイテムを示します。

図5-11 デジタル署名

「図5-11 デジタル署名」の説明

図5-11では、元のデータおよびデジタル署名は、基本的に署名者の秘密鍵を使用して暗号化された(元のデータの)一方向ハッシュです。そのデータの整合性を検証するには、受信ソフトウェアは、最初に署名者の公開鍵を使用してハッシュを復号化します。次に、元のハッシュを生成したものと同じハッシュ・アルゴリズムを使用して、同じデータの新しい一方向ハッシュを生成します。(この図には記されていませんが、使用されたハッシュ・アルゴリズムに関する情報は、デジタル署名とともに送信されています。)最後に、受信ソフトウェアは、新しいハッシュと元のハッシュを比較します。2つのハッシュが一致した場合、データは署名されてから変更されていません。それらが一致しない場合、データは署名後に改ざんされたか、署名者によって提示された公開鍵と一致しない秘密鍵を使用して署名が作成された可能性があります。

2つのハッシュが一致した場合、受信者は、デジタル署名の復号化に使用した公開鍵が、デジタル署名の作成に使用された秘密鍵と対応することを確信できます。ただし、署名者のアイデンティティを確認するには、その公開鍵が本当に特定の人または他のエンティティに属していることを確認するなんらかの方法が必要です。

デジタル署名の重要性は、手書きの署名の重要性に相当します。一度あるデータに署名したら、秘密鍵が危険にさらされることがなく、所有者が制御できている場合は、後でそのことを否定することは困難です。デジタル署名のこの性質によって高度の非拒否が提供されますが、つまり、デジタル署名は、署名者がデータに署名したことを否定するのを困難にします。場合によっては、デジタル署名は、手書きの署名と同程度の法的拘束力がある場合があります。

5.4.3 鍵の暗号化

最近の暗号化では、暗号化された情報の秘密を保つ機能は、暗号化アルゴリズムに基づいているのではなく、これは広く知られていることですが、鍵に基づいています。鍵は、暗号化された結果を作成する、または暗号化済の情報を復号化するためにアルゴリズムとともに使用する必要のある数字です。鍵を使用した暗号化および復号化の詳細は、次の各項を参照してください。

- 対称鍵暗号化

- 公開鍵暗号化

- 鍵の長さおよび暗号化強度

5.4.3.1 対称鍵暗号化

対称鍵暗号化では、暗号化鍵は復号化鍵から計算でき、その逆も同様です。最も対称なアルゴリズムでは、暗号化と復号化の両方に同じ鍵が使用されます。次の図に、対称鍵暗号化を示します。

図5-12 対称鍵暗号化

「図5-12 対称鍵暗号化」の説明

対称鍵暗号化の実装は非常に効率がよいため、ユーザーは、暗号化および複合化による大幅な遅延時間を経験しません。対称鍵暗号化では、1つの対称鍵で暗号化された情報は他の対称鍵では復号化できないため、認証度も提供されます。したがって、通信を暗号化するために対称鍵を使用した2つのパーティによって対称鍵の秘密が保持されるかぎり、復号化されたメッセージのつじつまが合っている間は、それぞれのパーティはもう一方と通信していることを確認できます。

対称鍵暗号化は、関係する2つのパーティによって対称鍵の秘密が保持される場合にかぎり、効果的です。他の誰かが鍵を見つけた場合は、機密保護と認証の両方に影響があります。認可されていない対称鍵を持った人は、その鍵を使用して送信されたメッセージを復号化できるだけでなく、新しいメッセージを暗号化し、本来その鍵を使用していた2つのパーティのうちのどちらかからのふりをしてメッセージを送信できます。

対称鍵暗号化は、認証、改ざん検出およびTCP/IPネットワークを経由した暗号化で広く使用されるSSLプロトコルで重要な役割を果たします。また、SSLは、次の項で説明する公開鍵暗号化の技術も使用します。

5.4.3.2 公開鍵暗号化

最も一般的に試用される公開鍵暗号化の実装は、RSA Data Security社が特許権を所有するアルゴリズムを基にしています。そのため、この項では公開鍵暗号化に対するRSAの方法について説明します。

公開鍵暗号化(非対称暗号化)には、電子的なアイデンティティの認証や、データの署名または暗号化が必要なエンティティに関連付けられている公開鍵および秘密鍵の鍵のペアを必要とします。各公開鍵は公開し、対応する秘密鍵は秘密にしておきます。次の図に、公開鍵が機能する仕組みを簡略化した図を示します。

図5-13 公開鍵暗号化

「図5-13 公開鍵暗号化」の説明

公開鍵暗号化では、公開鍵を配布し、あなただけがこの鍵で暗号化されたデータを読み取ることができます。一般に、暗号化されたデータを誰かに送信するには、その人の公開鍵を使用してデータを暗号化し、その暗号化されたデータを受け取る人が対応する秘密鍵でそれを復号化します。

対称鍵暗号化と比較して、公開鍵暗号化にはより多くの計算が必要なため、必ずしも大量のデータに適しているとはいえません。ただし、対称鍵を送信するために公開鍵暗号化を使用することは可能であり、つまり、その他のデータの暗号化に使用できます。これがSSLプロトコルで使用される方法です。

さらに、あなたの秘密鍵を使用して暗号化されたデータはあなたの公開鍵でのみ復号化できるという、図5-13に示されているスキームの逆も機能します。ただし、公開が示すとおり、あなたの公開鍵を持つ誰でもがそのデータを復号化できることを意味するため、これは機密データを暗号化するには望ましい方法ではありません。そうだとしても、秘密鍵を使用して、電子商取引およびその他の暗号化の商用アプリケーションの重要な要件であるデジタル署名でデータに署名できることを意味するため、秘密鍵は役立ちます。クライアント・ソフトウェアは、あなたの公開鍵を使用して、メッセージが秘密鍵で署名され、署名後に改ざんされていないことを確認できます。デジタル署名およびその後の各項では、この確認プロセスの機能する方法について説明します。

5.4.3.3 鍵の長さおよび暗号化強度

暗号化の強度は、鍵の発見の難しさに関係し、これは、使用する暗号と鍵の強度に依存します。たとえば、公開鍵に最も一般的に使用されるRSA暗号の鍵の発見の難しさは、大きい数の因数分解(周知の数学の問題)の難しさに依存します。

暗号化の強度は、多くの場合、暗号化の実行に使用される鍵のサイズの観点から説明されますが、一般に、鍵が長いほど強い暗号化が提供されます。鍵の長さはビットで測定されます。たとえば、SSLでサポートされるRC4対称鍵暗号で使用される128ビットの鍵では、同じ暗号を使用する40ビットの鍵よりかなり優れた暗号保護が提供されます。おおまかにいうと、128ビットのRC4暗号には、40ビットのRC4暗号よりも3×10^26倍の強度があります。

同じレベルの暗号化強度を得るためには、それぞれの暗号に異なる鍵の長さが必要になる場合があります。たとえば、公開鍵暗号化で使用されるRSA暗号は、それが基にしている数学の問題の性質により、指定された長さの鍵で可能なすべての値のサブセットのみが使用できます。対称鍵暗号化などに使用されるその他の暗号では、値のサブセットではなく、指定された長さの鍵で可能なすべての値を使用できます。このため、対称鍵暗号化暗号で使用される128ビットの鍵は、RSA公開鍵暗号化暗号で使用される128ビットの鍵よりも強度のある暗号が提供されます。この違いによって、RSA公開鍵暗号化暗号は、暗号の強度があると判断されるためには512ビット(またはそれ以上)の鍵を使用する必要があるのに対して、対称鍵暗号がほぼ同じレベルの強度を得るために64ビットの鍵を使用することの説明がつきます。このレベルの強度も、近い将来、攻撃に対して脆弱となる可能性があります。

5.4.4 属性の暗号化

属性の暗号化では、エントリの機密属性を暗号化形式で格納することが可能です。機密属性を暗号化することで、データベース・ファイル、バックアップ・ファイルまたはエクスポートされたLDIFファイルにデータが格納されている間や、データがエクスポートされている間に、属性が読み取られないようにできます。図5-14に、salary属性を暗号化するように属性の暗号化が構成されているデータベースに追加されるユーザー・エントリを示します。

図5-14 属性の暗号化

「図5-14 属性の暗号化」の説明

属性の暗号化機能では、広範な暗号化アルゴリズムおよび様々なプラットフォームがサポートされます。属性の暗号化では、サーバーのSSL証明書の秘密鍵を使用して独自の鍵を生成します。この鍵はその後、暗号化および復号化操作を実行するために使用されます。

属性の暗号化は、サフィックス・レベルで構成されます。これは、サフィックスに表示されるすべてのエントリに対して属性が暗号化されることを意味します。ディレクトリ全体で属性を暗号化するには、すべてのサフィックスでその属性の暗号化を有効にする必要があります。

一部のエントリがネーミング属性として使用する属性を暗号化する場合、DNに表示される値は暗号化されませんが、そのエントリに格納される値は暗号化されます。

userPassword属性を暗号化すると、DIGEST-MD5 SASL認証のように、パスワードがクリア・テキストで格納される必要がある場合を除いて、セキュリティの利点は提供されません。パスワード・ポリシーに定義されている暗号化メカニズムがすでにパスワードにある場合は、それをさらに暗号化してもセキュリティの強化にはなりません。

暗号化された属性が格納されている場合、使用された暗号化アルゴリズムを示す暗号タグが最初に付けられます。DES暗号化アルゴリズムを使用して暗号化された属性は、次のように表示されます。

{CKM_DES_CBC}3hakc&jla+=snda%

属性の暗号化によってデータ・セキュリティが強化される一方で、この機能はパフォーマンスに影響を与えます。暗号化が必要な属性について注意深く検討し、特に機密にする必要がある属性のみを暗号化します。機密データは索引ファイルから直接アクセスできるため、暗号化された属性に対応する索引キーは、属性が完全に保護されるように暗号化する必要があります。

属性を暗号化する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の属性値の暗号化に関する説明を参照してください。

6 Directory Serverの監視

Directory Serverの監視の詳細は、次の項を参照してください。

- Directory Serverの監視方法

- Directory ServerとSNMP

- Directory Server監視属性

6.1 Directory Serverの監視方法

次の方法で、Directory Serverを監視できます。

Directory Service Control Center

Directory Service Control Center (DSCC)を使用して、Directory Serverインスタンスの現在のアクティビティを監視できます。

DSCCは一般的なサーバー情報を提供し、これにはリソースのサマリー、現在のリソース使用状況、接続ステータスおよびグローバル・データベースのキャッシュ情報が含まれます。これは、一般的なデータベース情報(データベース・タイプ、ステータスおよびエントリ・キャッシュの統計など)も提供しますキャッシュ情報およびデータベース内の各索引ファイルに関連する情報も、提供されます。

コマンドライン

dsconfコマンドを使用して、ロギングを構成し、Directory Serverのレプリケーション・ステータスを監視できます。ロギングの構成方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のDirectory Serverのログの構成に関する説明を参照してください。dsconfコマンドを監視に使用する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のコマンドラインの使用によるレプリケーション・ステータスの取得に関する説明を参照してください。

ldapsearchコマンドを使用して、Directory Serverインスタンスの現在のアクティビティの情報に関するcn=monitorエントリを検索できます。cn=monitorの詳細は、「Directory Server監視属性」を参照してください。

ログ・アナライザ・ツール

Directory Server Resource Kitによって、logconvと呼ばれるログ・アナライザ・ツールが提供されます。

logconvツールは、使用状況統計を抽出し、アクセス・ログにおける重要なイベントの発生をカウントします。

Simple Network Management Protocol (SNMP)

Directory Serverは、SNMPを介して管理情報を公開します。

6.2 Directory ServerとSNMP

Directory Serverは、dsTableおよびRFC 2605 (http://www.ietf.org/rfc/rfc2605.txt)によって定義されたDirectory Server Monitoring MIBのdsApplIfOpsTableを実装しています。dsIntTableは実装していません。

またDirectory Serverは、RFC 2788 (http://www.ietf.org/rfc/rfc2788.txt)によって定義されたNetwork Services Monitoring MIBも実装しています。

Directory ServerのSNMPサポートには、次の制限事項があります。

- SNMPサポートの対象は監視のみで、SNMP管理はサポートされません。

- SNMPトラップは実装されていません。

この項の後半では、監視アプリケーションからDirectory Serverまで、およびその逆方向の情報フローに関して、特にSNMPを使用する場合について説明しています。

この監視フレームワークはDSCCエージェント内に含まれ、これはDirectory Serverとともにインストールされています。図6-1に、監視フレームワークを示します。

図6-1 情報フローの全体的な監視

「図6-1 情報フローの全体的な監視」の説明

Directory Serverの監視へのSNMPサポートは、DSCCエージェントによって管理されます。

図6-2は、DSCCエージェントを介した、Directory Serverに関するSNMP情報フローを示しています。

図6-2 SNMPの情報フロー

「図6-2 SNMPの情報フロー」の説明

Directory ServerのSNMP情報フローは、次のようになっています。

1. ネットワーク管理ステーションはGETメッセージをSNMPエージェントに送信し、これはデフォルトではポート3996を使用します。

2. SNMPエージェントは、Directory Server宛のあらゆるリクエストをDSCCエージェントに転送します。

3. Directory Serverは、DSCCエージェントにSNMP情報を定期的にプッシュします。

4. DSCCエージェントは、レスポンスをSNMPエージェント経由でリレーして、ネットワーク管理ステーションのSNMPクライアントに戻します。次にネットワーク管理ステーションは、ネットワーク管理アプリケーションを介してデータを表示します。

6.3 Directory Server監視属性

サーバー・ステータス、レプリケーション・ステータス、リソース使用状況およびその他の監視情報は、DSCCを介して利用可能です。

または、次のエントリに関して検索操作を実行することによって、任意のLDAPクライアントからDirectory Serverの現在のアクティビティを監視できます。

- cn=monitor

- cn=monitor, cn=ldbm database, cn=plugins, cn=config

- cn=monitor,cn=dbName,cn=ldbm database,cn=plugins,cn=config
dbNameは、監視するサフィックスのデータベース名です。cn=monitorエントリは、デフォルトで、匿名でバインドされているクライアントを含めて誰でも読取り可能であることに注意してください(各接続の情報を除く)。

6.3.1 cn=monitor

cn=monitorエントリは、extensibleObjectオブジェクト・クラスのインスタンスです。サーバーによって考慮されるcn=monitor構成属性に関して、topオブジェクト・クラスに加えてこのオブジェクト・クラスが、このエントリで表示されます。この項では、cn=monitor読取り専用属性を示します。

読取り専用の監視情報は、cn=monitorエントリの配下に格納されています。

6.3.1.1 backendMonitorDN

各Directory ServerバックエンドのDN。

データベース監視情報の詳細は、dse.ldifを参照してください。

6.3.1.2 bytesSent

Directory Serverによって送信されるバイト数。

6.3.1.3 cache-avail-bytes

キャッシュに利用可能なバイト数。

6.3.1.4 connection

ユーザーが管理ユーザーとして認証される場合にのみ、オープン接続のリストが返されます。リストは次の形式で示されます。

connection=31:20010201164808Z:45:45::name="DirAdminDN" content="cn=admin,cn=Administrators,cn=config":LDAP

- 31は、接続を処理するサーバーによって使用されるファイル記述子の数です。

- 20010201164808Zは、接続がオープンされた日付です。

- 45は、受信された操作数です。

- 45は、完了した操作数です。

- name="DirAdminDN" content="cn=admin,cn=Administrators,cn=config"は、バインドDNです。

6.3.1.5 connectionPeak

サーバーの起動からの最大同時接続数。

6.3.1.6 currentConnections

Directory Serverの現在の接続数。

6.3.1.7 currentTime

現在時刻はグリニッジ標準時で示され、GeneralizedTime構文のZ表記で示されます(例: 20010202131102Z)。

6.3.1.8 dTableSize

Directory Serverディスクリプタの表のサイズ。

6.3.1.9 entriesSent

Directory Serverによって送信されたエントリ数。

6.3.1.10 nbackEnds

Directory Serverバックエンド数。

6.3.1.11 opsCompleted

完了したDirectory Server操作数。

6.3.1.12 opsInitiated

開始されたDirectory Server操作数。

6.3.1.13 request-que-backlog

スレッドによる処理を待機しているリクエストの数。サーバーによって受信された各リクエストは、受け入れられた後、スレッドによって処理可能となるまでキューに置かれます。キューのバックログは、常に小さいサイズ(0または0に近いもの)である必要があります。キューのバックログが大きい場合、nsslapd-threadnumber属性を使用して、サーバーで利用可能なスレッド数を増加します。

6.3.1.14 readWaiters

一部のリクエストが保留中で、Directory Serverのスレッドによって現在は処理されていない接続数。

6.3.1.15 currentpsearches

サーバー上で現在実行されている、永続検索数。コマンドdsconf set-server-prop max-psearch-count:numberを使用して、サーバーに永続検索の最大数を設定できます。

6.3.1.16 startTime

Directory Serverの起動時間。

6.3.1.17 threads

Directory Serverが起動中に作成する操作スレッド数。この属性は、cn=config配下のnsslapd-threadnumber属性を使用して設定できます。nsslapd-threadnumber属性はデフォルトでは構成に存在しませんが、追加が可能です。

6.3.1.18 totalConnections

Directory Serverの接続合計数。

6.3.1.19 version

Directory Serverのバージョンおよびビルド番号。

6.3.2 cn=disk,cn=monitor

cn=diskエントリを使用して、LDAPを介してディスクの状態を監視できます。このエントリは、extensibleObjectオブジェクト・クラスのインスタンスです。各ディスクに対して、cn=disknumber,cn=disk,cn=monitorエントリが存在します。次のディスク監視属性は、このような個別のディスク・エントリの配下に表示されます。

6.3.2.1 disk-dir

ディスクにおいて、サーバーによって使用されるディレクトリのパス名を指定します。同じディスクに複数のデータベース・インスタンスが常駐する場合、またはインスタンスが同じディスク上の複数のディレクトリを参照する場合、短いパス名が表示されます。ディスクの番号付けは任意です。

6.3.2.2 disk-free

サーバーで利用可能なディスクの空き容量を、MBで示します。

注意:

サーバー・プロセスが利用可能なディスク領域は、空きディスク領域の合計よりも少ない可能性があります。たとえば一部のプラットフォームでは、rootとして動作しないプロセスは、利用可能なディスクの空き容量のすべてを利用できるとは限らない場合があります。

6.3.2.3 disk-state

利用可能な空き領域や、構成パラメータnsslapd-disk-low-thresholdやnsslapd-disk-full-thresholdでディスク・フルまたはディスク下限に設定されたしきい値に基づいて、ディスクの状態を示します。可能な値は、normal、lowおよびfullです。

6.3.3 cn=counters,cn=monitor

このエントリは、様々なサブツリー・エントリ・カウンタ・プラグインが有効化されている場合に、これらに関するカウンタ情報を保持します。

6.3.3.1 backlogsum

操作の受信時から処理の開始まで、ワーカー・スレッドによって消費される合計時間(秒単位)。このパラメータは、Windowsでは利用できません。

6.3.3.2 *etimesum

あるタイプの操作を完了するためにかかった、すべての*etimesum属性が示す合計経過時間(秒単位)。

たとえばbindetimesumは、バインド操作の処理にかかった合計秒数を示します。

6.3.4 cn=monitor,cn=Class of Service,cn=plugins, cn=config

このエントリでは、サービス・クラス・プラグインに関連するカウンタを保持します。このエントリは、extensibleObjectオブジェクト・クラスのインスタンスです。

6.3.4.1 classicHashAvgClashListLength

CoSプラグインが高速参照のためにハッシュ表を使用する際に、使用されているハッシュ・キーに複数のクラシックCoSテンプレートが対応する場合、このプラグインは次に、クラッシュ・リスト(同一ハッシュ・キーを共有しているテンプレートのリスト)での一致をチェックします。この属性値は、クラシックCoSテンプレートのクラッシュ・リストのすべてのハッシュ表における平均の長さを提供して、高速参照中にハッシュ表の使用後でプラグインが実行する必要があるリニア検索の量が示されます。

6.3.4.2 classicHashAvgClashPercentagePerHash

ハッシュ表ごとの平均クラッシュ数。すなわち、同一のハッシュ・キーを共有するクラシックCoSテンプレートのハッシュごとの、平均的な割合。

6.3.4.3 classicHashMemUsage

最初にクラシックCoSテンプレートを参照する際に、ハッシュ表を保持するためのメモリー・オーバーヘッド(バイト単位)。

6.3.4.4 classicHashValuesMemUsage

最初にクラシックCoSテンプレートを参照する際に、ハッシュ値を保持するために使用されるメモリー(バイト単位)。

6.3.4.5 numClassicDefinitions

使用されているクラシックCoS定義エントリ数。

6.3.4.6 numClassicHashTables

単一のCoS定義に対して11以上のクラシックCoSテンプレートが適用される、高速参照用に作成されているハッシュ表の数。ハッシュ表は、テンプレートのリストが少ない場合は作成されません。

6.3.4.7 numClassicTemplates

使用されているクラシックCoSテンプレートのエントリ数。

6.3.4.8 numCoSAttributeTypes

CoSを介して計算された値を持つ、個別属性の数。

6.3.4.9 numIndirectDefinitions

使用されている間接CoS定義エントリ数。

6.3.4.10 numPointerDefinitions

使用されているポインタCoS定義エントリ数。

6.3.4.11 numPointerTemplates

使用されているポインタCoSテンプレートのエントリ数。

7 Directory Serverのレプリケーション

この章では、次の項目について説明します。

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

- レプリケーションおよびレトロ変更ログ・プラグイン

7.1 レプリケーションの概要

レプリケーションは、2つ以上の参加者が必ず関係するトポロジ全体の機能です。

レプリケーションは次のように機能します。

1. マスターが変更を受信します。変更をデータベース内のエントリに適用後、サーバーはマスターのため、その変更を変更ログ・データベースに格納します。

2. マスターは、自身のレプリカ更新ベクトル(RUV)を更新します。

3. マスターは、新しい変更が変更ログに記録されたことをレプリケーション・スレッドに通知します。

4. これらのレプリケーション・スレッドはレプリケーション・パートナーに接続し、情報を伝播します。

たとえば、マスター1が変更を受信すると、それをエントリに適用して自身の変更ログを更新します。マスター1がコンシューマに接続する際、コンシューマは、そのマスター・レプリカに対して自身のRUVを示します。マスターはそのRUVを参照し、自身のRUVと比較して、コンシューマより新しい変更が含まれているかどうかを確認します。たとえば、コンシューマにより高いRUVが含まれていることを確認した場合、マスターは変更を送信しません。より最新の変更がマスターに含まれている場合は、レプリカID 1のロックを依頼する別のリクエストをコンシューマに送信し、更新を実行できるようにします。ロックが使用できない場合は、更新は後で実行されます。ロックが使用できる場合は、マスターは変更を続行します。

レプリケーションの概要の内容は、次のとおりです。

- サプライヤおよびコンシューマ

- レプリケーションの単位

- レプリカのアイデンティティ

- レプリケーション承諾

- レプリカのタイプ

- レプリケーション認証

- レプリケーション変更ログ

- 変更順序番号

- レプリカ更新ベクトル

- 削除済エントリ: ツームストン

- コンシューマの初期化および増分更新

- リフェラルおよびレプリケーション

7.1.1 サプライヤおよびコンシューマ

他のサーバーに対してレプリケートするDirectory Serverは、サプライヤと呼ばれます。他のサーバーによって更新されるDirectory Serverは、コンシューマと呼ばれます。サプライヤは、特別に設計されたLDAP v3拡張操作を使用して、コンシューマ上ですべての更新をリプレイします。そのため、パフォーマンスの面では、サプライヤはコンシューマにとっては必要性の高いクライアント・アプリケーションとなる可能性があります。

サーバーは、次のような場合に、サプライヤとコンシューマの両方になれます。

- マルチマスター・レプリケーションで、マスター・レプリカが2つの異なるDirectory Serverにマスターされている場合。各サーバーは、他のサーバーに対して、サプライヤおよびコンシューマとして動作します。

- サーバーにハブ・レプリカが含まれている場合、サーバーはサプライヤから更新を受け取り、変更をコンシューマにレプリケートします。

コンシューマの役割のみを実行するサーバーは、専用コンシューマと呼ばれます。

マスター・レプリカの場合、サーバーは次を行う必要があります。

- ディレクトリ・クライアントからの更新リクエストに応答します。

- 履歴情報および変更ログを保持します。

- コンシューマに対してレプリケーションを開始します。

マスター・レプリカを含むサーバーは、マスター・レプリカに対して行われたすべての変更を記録し、それらの変更をコンシューマにレプリケートする責任を負います。

ハブ・レプリカの場合、サーバーは次を行う必要があります。

- 読取りリクエストに応答します。

- マスター・レプリカを含むサーバーに更新リクエストを照会します。

- 履歴情報および変更ログを保持します。

- コンシューマに対してレプリケーションを開始します。

コンシューマ・レプリカの場合、サーバーは次を行う必要があります。

- 読取りリクエストに応答します。

- 履歴情報を保持します。

- マスター・レプリカを含むサーバーに更新リクエストを照会します。

7.1.2 レプリケーションの単位

レプリケーションの最小の論理単位は、ネーミング・コンテキストとも呼ばれるサフィックスです。サフィックスという用語は、ネーミング・コンテキストに対するベースDNが、そのコンテキスト内のすべてのDNに対するサフィックスであることに起因します。たとえば、サフィックスdc=example,dc=comには、Example.comネーミング・コンテキスト内のすべてのディレクトリ・エントリが含まれます。

レプリケーション・メカニズムでは、1つのデータベースに対応する1つのサフィックスが必要です。レプリケーションの単位は、サプライヤおよびコンシューマの両方に適用されます。したがって、マスター・レプリカ上の2つのサフィックスは、コンシューマ・レプリカ上の1つのサフィックスに対してレプリケートできません(逆の場合も同じです)。

7.1.3 レプリカのアイデンティティ

マスター・レプリカには、1から65534の間の16ビット整数である、一意のレプリカ識別子が必要です。コンシューマ・レプリカおよびハブ・レプリカのレプリカIDはすべて65535です。レプリカIDによって変更が行われたレプリカが識別されます。

複数のサフィックスが1つのマスターに構成されている場合、マスター上のそれぞれのサフィックスで同じレプリカIDを使用できます。この方法では、そのレプリカIDで変更が行われた場合、変更が行われたサーバーの特定が可能です。

7.1.4 レプリカのタイプ

レプリケーションに参加しているサフィックスをレプリカと呼びます。レプリカには次の3つの種類があります。

- マスター・レプリカは、ディレクトリ・データのマスター・コピーが含まれている読取り-書込みデータベースです。マスター・レプリカは次のタスクを実行できます。

- ディレクトリ・クライアントからの更新リクエストおよび読取りリクエストに応答します。

- そのレプリカの履歴情報および変更ログを保持します。

- コンシューマまたはハブに対してレプリケーションを開始します。

- コンシューマ・レプリカは、マスター・レプリカに格納されている情報のコピーを含む読取り専用データベースです。コンシューマ・レプリカは次のタスクを実行できます。

- 読取りリクエストに応答します。

- そのレプリカの履歴情報を保持します。

- マスター・レプリカを含むサーバーに更新リクエストを照会します。

- ハブ・レプリカは、コンシューマ・レプリカと同様に読取り専用のデータベースですが、1つ以上のコンシューマ・レプリカを提供するディレクトリ・サーバー上に格納されます。ハブ・レプリカは次のタスクを実行できます。

- 読取りリクエストに応答します。

- そのレプリカの履歴情報および変更ログを保持します。

- コンシューマに対してレプリケーションを開始します。

- マスター・レプリカを含むサーバーに更新リクエストを照会します。

Directory Serverの単一のインスタンスは、複数のレプリカを管理するために構成できます。

レプリカは、更新のサプライヤとして、または更新のコンシューマとして、あるいはその両方として動作できます。

- サプライヤは、別のレプリカに情報をコピーするレプリカです。
マスター・レプリカは、ハブ・レプリカおよびコンシューマ・レプリカのサプライヤになることができます。ハブ・レプリカは、コンシューマ・レプリカのサプライヤになることができます。マルチマスター・レプリケーションでは、1つのマスター・レプリカは、別のマスター・レプリカに対してサプライヤになることができます。

- コンシューマは、別のレプリカから更新を受信するレプリカです。
ハブ・レプリカおよびコンシューマ・レプリカは、マスター・レプリカのコンシューマになることができます。コンシューマ・レプリカは、ハブ・レプリカのコンシューマになることができます。マルチマスター・レプリケーションでは、1つのマスター・レプリカは、別のマスター・レプリカに対してコンシューマになることができます。

レプリカは、他のレプリカに対する動作を変更するために昇格または降格できます。専用コンシューマはハブに昇格でき、ハブはマスターに昇格できます。マスターはハブに降格でき、ハブは専用コンシューマに降格できます。

コンシューマ・レプリカのみを含むサーバーは、専用コンシューマと呼ばれます。

7.1.5 レプリケーション承諾

レプリケーション承諾によって、サプライヤとコンシューマ間の関係が定義されます。レプリケーション承諾は、サプライヤ上で構成されます。レプリケーション承諾には、次のレプリケーション・パラメータが含まれます。

- レプリケートするためのサフィックス。

- データのプッシュ先のコンシューマ・サーバー。

- レプリケーション・スケジュール。

- コンシューマをバインドするためにマスターが使用する必要のあるバインドDNおよび資格証明。

- 接続の保護方法。

- 部分レプリケーションが構成されている場合に、部分レプリケーションで除外するまたは含む属性。

- 1つのリクエストにグループ化可能な変更の数およびコンシューマ承認が必要になる前に送信可能なリクエストの数を構成するためのグループおよびウィンドウのサイズ。

- この承諾のレプリケーション・ステータスに関する情報。

- SolarisおよびLinuxシステムでレプリケーションに使用される圧縮レベル。

7.1.6 レプリケーション認証

マスターがコンシューマを更新可能になる前に、コンシューマは、Replication Managerエントリと呼ばれる特別なエントリを使用することで、そのマスターを認証します。マスターは、Replication Managerエントリを使用して、コンシューマにバインドします。

Replication Managerエントリには、コンシューマ・サーバー上に定義されているすべてのアクセス制御ルールを省略する特別なユーザー・プロファイルがあります。この特別なユーザー・プロファイルは、レプリケーション内でのみ有効です。

Replication Managerエントリには、次の特性があります。

- コンシューマ・サーバーでは、Replication Managerは更新の実行が許可されているユーザーです。Replication Managerに対するエントリは、すべてのレプリカに存在する必要があります。

- Replication ManagerエントリのバインドDNは、レプリケーション承諾で設定されています。バインドDNは、ハブまたはマスターで既存のReplication Managerエントリを指すように構成される必要があります。

- 初期化およびセキュリティ上の理由から、Replication Managerエントリは、レプリケートされたデータの一部になることはできません。

Replication Managerエントリは、ブラウザベースのインタフェースであるDirectory Service Control Centerを使用してレプリケーションを構成したときにデフォルトで作成されます。独自のReplication Managerエントリを作成することもできます。Replication Managerエントリの作成方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のデフォルト以外のReplication Managerの使用方法に関する説明を参照してください。

レプリケーションでのSSLに対して、認証は次の方法で実行できます。

- SSLサーバー認証では、認証するサーバーにReplication Managerエントリおよび関連付けられているパスワードが必要です。

- SSLクライアント認証では、認証するサーバーに証明書が含まれるエントリが必要です。このエントリは、Replication Managerエントリにマップされる場合とされない場合があります。

7.1.7 レプリケーション変更ログ

マスター・レプリカによって受信されたすべての変更は、変更ログに記録されます。変更ログは、すべてのマスター・レプリカおよびハブ・レプリカで保持されます。

アプリケーションで変更ログを読み取る必要がある場合は、下位互換性用にレトロ変更ログ・プラグインを使用します。レトロ変更ログ・プラグインの詳細は、「レプリケーションおよびレトロ変更ログ・プラグイン」を参照してください。

7.1.8 変更順序番号

マスター・レプリカに対する各変更は、変更順序番号(CSN)で特定されます。CSNはマスター・サーバーで生成され、クライアント・アプリケーションには表示されません。CSNには、タイムスタンプ、順序番号、レプリカIDおよびサブシーケンス番号が含まれます。変更ログはCSN順になっています。

レプリケーションは順次的であり、これはエントリが順序正しい方法でレプリケートされることを意味します。レプリケーションは順序立っているため、マスターによって生成されたすべての変更は、変更順序番号(CSN)によってラベル付けされ、マルチマスター・トポロジ内の各変更に対して一意です。CSNは16進文字列で、ログには次のように表示されます。

41e6ee93000e00640000

16進数の最初の8桁は、マスターで変更が生成された時間を表します。この時間は、1970年1月1日を基準とした秒単位で表されます。

次の4桁は順序番号、または変更が発生した現在の秒での順序です。たとえば、秒41e6ee93で複数の変更が発生します。順序番号は、変更の進行形の番号付けを示します。

次の4桁は、変更を最初に受信したマスターのレプリカIDを示します。

最後の4桁は予備です。ほとんどの場合、それらは0000です。

CSNは、ローカル・トラフィックによってレプリカに対して新しい変更が送信されたときにのみ生成されます。そのため、更新を受信するマスターのみがCSNを生成します。受信するすべての更新がレプリケーションを介して行われるため、コンシューマは、常にマスターを参照します。

7.1.9 レプリカ更新ベクトル

レプリカ更新ベクトル(RUV)は、トポロジ内の各レプリカの状態を識別します。サプライヤおよびコンシューマ上に格納されるRUVは、レプリケートする必要のある変更を確立するために使用されます。RUVは、サプライヤのURL、サプライヤのID、最小CSNおよび最大CSNを格納します。

レプリケーション・トポロジ内のすべてのレプリカは、レプリカ更新ベクトル(RUV)に現行のレプリケーション状態を格納します。RUVは実行中のプロセスによってメモリーに格納され、このレプリカ自身およびレプリケーション・トポロジ内のその他すべての参加者に関する正確な情報を提供します。指定されたサーバー上のRUVエントリには、レプリケーション・トポロジに参加している各マスターに対する行が含まれています。各行には、マスターのうちの1つの識別子、レプリカのURLおよびサーバーで最初および最後に行われた変更のCSNが含まれます。CSNは、必ずしもマスターによって行われた最新の変更ではなく、サーバーで認識される最初および最後の変更のみが記録されます。

RUVは、主にメモリーにあり、cn=replica,cn=suffix,cn=mapping tree,cn=configエントリ上のldapsearchを使用してアクセスできます。たとえば、ou=peopleサフィックスに対するldapsearchでは、次の結果が生成される可能性があります。

# ldapsearch -h host1 -p 1389 -D "cn=Directory Manager" -w secret \
-b "cn=replica,cn=ou=people,cn=mapping tree,cn=config" \
-s base objectclass=* nsds50ruv

nsds50ruv: {replicageneration} 45e8296c000000010000
nsds50ruv: {replica 1 ldap://server1:1389} 45ed8751000000010000 4600f252000000010000
nsds50ruv: {replica 2 ldap://server1:2389} 45eec0e1000000020000 45f03214000000020000

明確にするために、RUVの構文をCSNchangenumber-replicaidに簡略化します。change-numberは、マスター上で発生した連続した変更のうち、RUVが対応する変更を示します。たとえば、45ed8751000000010000はCSN05-1として書き込まれます。前述の図には、マスター1には次のRUVが含まれています。

replica 1: CSN05-1 CSN43-1
replica 2: CSN05-2 CSN40-2

最初の行は、レプリカID 1で示されている、このレプリカが自身(マスター1)について認識している最初および最後の変更に関する情報を提供しています。2番目の行は、このレプリカがマスター2から認識する最初および最後の変更に関する情報を提供しています。最も関心をひく情報は、最後の変更です。通常の操作では、マスター1は、受信する更新についてマスター2より認識しているはずです。このことを、マスター2のRUVを参照して確認します。

replica 2: CSN05-2 CSN50-2
replica 1: CSN01-1 CSN35-1

最後の変更を見ると、マスター2は受信した最後の変更(CSN50-2)について、マスター1 (最後の変更はCSN40-2で発生)よりも認識しています。一方、マスター1は自身の最後の変更(CSN43-1)については、マスター2 (CSN35-1)よりも認識しています。

レプリケーションに関する問題をトラブルシューティングする場合、CSNは問題を特定するのに役立ちます。変更は最初にマスター1に適用されその後レプリケートされるため、マスター1は、少なくともレプリケーション・トポロジ内の他の参加者と同様に自身のレプリカIDについて常に認識している必要があります。そのため、CSN43-1は、トポロジ内でレプリカID 1に属する最大値です。

たとえば、30分後にマスター1のRUVがまだCSN40-2で、マスター2ではRUVがCSN67-2まで大幅に増加した場合、問題が特定されます。これは、マスター2からマスター1へのレプリケーションが発生していないことを示します。

障害が発生し、できるかぎりデータを保存しながらトポロジを再初期化する必要がある場合は、RUVピクチャを使用して、最新の変更が含まれているマシンを判別できます。たとえば、前述のレプリケーション・トポロジには、次のRUVを含むハブがあります。

2: CSN05-2 CSN50-2
1: CSN05-1 CSN43-1

この場合、サーバー1が最新の変更を提供するために適した候補のようです。

RUVは、nsds50ruvからds6ruv属性を読み取ることができます。

7.1.10 削除済エントリ: ツームストン

レプリカ上で削除されたディレクトリ・エントリは、レプリケーションで必要がなくなるまでDirectory Serverによって保持されます。このような削除済エントリは、それらがobjectclass: nsTombstoneを持つため、ツームストンと呼ばれます。まれに、LDAPを介して手動でツームストンを削除する必要がある場合があります。

ツームストンはディレクトリ・マネージャに対してのみ表示されます。さらに、ツームストンは、フィルタ(objectclass=nsTombstone)を使用した検索でのみ表示されます。次のldapsearchコマンドでは、dc=example,dc=comの下にツームストン・エントリが返されます。

$ ldapsearch -D "cn=Directory Manager" -b dc=example,dc=com "(objectclass=nsTombstone)"

7.1.11 コンシューマの初期化および増分更新

コンシューマの初期化(合計更新)時に、すべてのデータがマスターからコンシューマに物理的にコピーされます。レプリケーション承諾を作成している場合、その承諾によって定義されているコンシューマを初期化する必要があります。コンシューマが初期化されると、マスターはコンシューマに対してリプレイ(レプリケート)または更新操作を開始できます。通常の状況では、コンシューマでその後の初期化が必要になることはありません。ただし、マスター上のデータがバックアップからリストアされた場合は、そのマスターに依存するコンシューマの再初期化が必要になる場合があります。

マルチマスター・レプリケーション・トポロジでは、バックアップまたはLDIFファイルから再初期化された読取り-書込みレプリカのデフォルトの動作では、クライアントの更新リクエストが拒否されます。デフォルトでは、更新を再び受け入れるように構成されるまで、レプリカは読取り専用モードのままになります。読取り専用レプリカ上に最も古い更新がある場合は、dsconf set-suffix-propコマンドを使用してサフィックスのプロパティrepl-accept-client-update-enabledをonに設定します。

コンシューマの初期化後に、サプライヤで変更が行われると、レプリケーション更新がコンシューマに送信されます。これらの更新は、増分更新と呼ばれます。更新が複数のレプリカIDから発生した場合は、コンシューマは複数のサプライヤから同時に増分更新できます。

バイナリ・コピー機能は、1つのサーバーのバイナリ・バックアップ・ファイルを使用して別のサーバーにリストアすることで、マスター・レプリカまたはコンシューマ・レプリカをクローニングするために使用できます。レプリケーション用のバイナリ・コピーの使用方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のバイナリ・コピーを使用したレプリケートされたサフィックスの初期化に関する説明を参照してください。

7.1.12 リフェラルおよびレプリケーション

コンシューマがデータを変更するためのリクエストを受信すると、マスター・レプリカを含むサーバーにはそのリクエストを転送しません。かわりに、そのリクエストを満たすことができるマスターのURLのリストをクライアントに返します。これらのURLは、リフェラルと呼ばれます。

レプリケーション・メカニズムでは、レプリケーション・トポロジに含まれるすべての既知のマスターのリフェラルを返すよう、コンシューマを自動的に構成します。ただし、独自のリフェラルを追加して、サーバーによって自動的に設定されたリフェラルを上書きすることもできます。リフェラルを制御する機能は、次のタスクを実行するのに役立ちます。

- ポートを保護する目的のみのポイント・リフェラル

- ロード・バランシングではなくDirectory Proxy Serverを指定

- WANによってサーバーが分離されている場合のみローカル・サーバーにリダイレクト

- 4方向マルチマスター・トポロジでリフェラルをマスターのサブセットに制限

Directory Proxy Serverはリフェラルに従うことができます。

7.2 レプリケーションおよびレトロ変更ログ・プラグイン

レトロ変更ログは、Directory Serverの以前のバージョンとのアプリケーション互換性を保持するためにLDAPクライアントによって使用されるプラグインです。レトロ変更ログは、サフィックスcn=changelogの下に、Directory Serverの変更ログとは別のデータベースに格納されます。

レトロ変更ログは、スタンドアロン・サーバーまたはレプリケーション・トポロジ内の各サーバーで有効にできます。サーバーでレトロ変更ログが有効になっている場合、デフォルトではそのサーバー上のすべてのサフィックスに対する更新が記録されます。

レトロ変更ログは、トポロジ内のすべてのマスター・レプリカから更新を受信します。各マスター・レプリカからの更新はレトロ変更ログに結合されます。レトロ変更ログは、アプリケーションによる同期を可能にするために、アプリケーションに対して変更を追跡するための方法を提供します。Directory Serverを使用することで、マルチマスター・トポロジ内の任意のマスターでレトロ変更ログの一貫性のあるバージョンにアクセスできます。また、変更番号に従ってその状態を管理するためにアプリケーションを更新できます。これにより、異なるサーバー上のレトロ変更ログ間でのフェイルオーバーが可能になります。

グローバル・レトロ変更ログには、すべての変更が含まれています。2つの異なる場所で同じエントリに対して2つの変更が発生した場合、レトロ変更ログは、順序付けられた変更の説明を提供します。任意のサーバーからレトロ変更ログに問い合わせた場合、同様の情報が含まれます。

レトロ変更ログの使用方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のレトロ変更ログの使用に関する説明を参照してください。

7.2.1 レトロ変更ログおよびマルチマスター・レプリケーション

次の図に、マルチマスター・トポロジ内の2つのサーバー上のレトロ変更ログを示します。

図7-1 レトロ変更ログおよびマルチマスター・レプリケーション

「図7-1 レトロ変更ログおよびマルチマスター・レプリケーション」の説明

レトロ変更ログは、レプリケーション時に次の属性を使用します。

changeNumber (cN)

レトロ変更ログに記録される更新の順序を特定

replicationCSN (CSN)

指定されたレプリカに対して更新を行う時間を特定

replicaIdentifier (RI)

レトロ変更ログを更新するレプリカを特定

図では、レトロ変更ログRCL1およびRCL2には同じ更新のリストが含まれていますが、更新は同じ順序で行われないことを示しています。ただし、指定されたreplicaIdentifierについては、更新は各レトロ変更ログで同じ順序に記録されます。更新がレトロ変更ログに記録される順序は、changeNumber属性で指定されます。

7.2.2 レトロ変更ログのフェイルオーバー

次の図に、簡略化したレプリケーション・トポロジを示しますが、ここではクライアントがコンシューマ・サーバー上のレトロ変更ログを読み取ります。

図7-2 レトロ変更ログのレプリケーションの簡略化したトポロジ

「図7-2 レトロ変更ログのレプリケーションの簡略化したトポロジ」の説明

トポロジ内の各マスター・レプリカに対して行われるすべての更新は、トポロジ内の各レトロ変更ログに記録されます。

クライアント・アプリケーションはDirectory Server 3のレトロ変更ログを読み取り、各レプリカ識別子に対する最後のCSNを格納します。各レプリカ識別子の最後のCSNは、replicationCSN属性によって指定されます。

次の図に、Directory Server 3の障害発生後のクライアントによるDirectory Server 2への読取りのリダイレクトを示します。

図7-3 レトロ変更ログのフェイルオーバー

「図7-3 レトロ変更ログのフェイルオーバー」の説明

フェイルオーバー後、クライアント・アプリケーションはDirectory Server 2のレトロ変更ログ(RCL2)を使用して、自身の更新を管理する必要があります。RCL2での更新の順序がRCL3での順序と同じではないため、クライアントは自身の更新をRCL2と同期する必要があります。

クライアントはRCL2を確認して、各レプリカ識別子に対する最後のCSNのレコードが対応するcNを特定します。レトロ変更ログのフェイルオーバーの例では、クライアントは、最後のCSNとcN間の次の対応関係を確認します。

- RI1からのCSN 1はRCL2上のcN4に対応

- RI2からのCSN 2はRCL2上のcN5に対応

- RI3からのCSN 3はRCL2上のcN7に対応

- RI4からのCSN 1はRCL2上のcN6に対応

クライアントは、このリストの最小のcNに対応する更新を特定します。レトロ変更ログのフェイルオーバーの例では、リスト内の最小のcNはcN4です。クライアントですべての更新が確実に処理されるようにするには、cN4以降にRCL2に記録されたすべての更新を処理する必要があります。クライアントは、cN4より前にRCL2に記録された更新は処理せず、cN4に対応する更新も処理しません。

7.2.3 レプリケーションの競合およびレトロ変更ログ

レプリケーションの競合が発生した場合、Directory Serverは、競合を解消するための操作を実行します。レトロ変更ログが実行中で、changeIsReplFixupOp属性がtrueに設定されている場合、操作に関する次の情報がchangeHasReplFixupOp属性に記録されます。

- 操作のターゲットDN

- 更新のタイプ

- 実行された変更

これらの属性の詳細は、Oracle Directory Server Enterprise Editionマニュアル・ページ・リファレンスを参照してください。

7.2.4 レトロ変更ログ使用時の制限事項

レプリケートされたトポロジでは、レプリケートされたサーバー上のレトロ変更ログは、互いに最新にする必要があります。これにより、レトロ変更ログのスイッチオーバーが可能になります。レトロ変更ログのフェイルオーバーの例を使用すると、RCL3上の各レプリカIDの最後のCSNは、RCL2上に存在する必要があります。

8 Directory Serverのデータ・キャッシュ

クライアント・リクエストに対するレスポンス時間を速くするために、Directory Serverはメモリー内のディレクトリ情報をキャッシュします。Directory Serverのパフォーマンスを最大限にする必要があるが、ディレクトリ・データのすべてを使用可能なメモリーに収めることができない場合は、キャッシュ設定を調整してパフォーマンスを最適化できます。

この章では、設定の調整が可能なキャッシュのタイプについて説明します。また、Directory Serverがそうしたタイプのキャッシュを使用する方法についても説明します。この章の内容は次のとおりです。

- キャッシュのタイプ

- Directory Serverによるキャッシュを使用した検索の実行方法

- Directory Serverによるキャッシュを使用した更新の実行方法

- Directory Serverによるキャッシュを使用したサフィックスの初期化方法

8.1 キャッシュのタイプ

この項では、Directory Serverにより使用されるキャッシュのタイプについて説明します。

図8-1は、それぞれに独自のエントリー・キャッシュがある3つのサフィックスを持つ、Directory Serverのインスタンスのキャッシュを示しています。

Directory Serverではファイル・システム・キャッシュも使用します。ファイル・システム・キャッシュは基本のオペレーティング・システム、およびディスク・サブシステムのI/Oバッファにより管理されます。

図8-1 コンテキスト内のエントリおよびデータベース・キャッシュ

「図8-1 コンテキスト内のエントリおよびデータベース・キャッシュ」の説明

8.1.1 データベース・キャッシュ

Directory Serverの各インスタンスにはデータベース・キャッシュが1つあります。データベース・キャッシュは、データベースの索引とエントリが含まれたページを保持します。各ページはエントリではありませんが、データベースの一部が含まれているメモリーの一片です。

Directory Serverはデータベース・ファイルとデータベース・キャッシュ間でページを移動し、ユーザーが指定する最大データベース・キャッシュ・サイズを維持します。Directory Serverがデータベース・キャッシュに使用するメモリーの容量は、指定されたサイズよりも大きくなることがあります。これは、データベース・キャッシュを管理するために、Directory Serverでさらにメモリーが必要なためです。

メモリーは経験的テストおよびSolarisシステムでのpmap(1)のようなツールを使用することにより監視できます。また、ps(1)ユーティリティを-p pidオプションおよび-o formatオプションとともに使用して、Directory Server ns-slapdなどの特定のプロセスで使用されている現在のメモリーを表示することもできます。詳細は、オペレーティング・システムのドキュメントを参照してください。

8.1.2 エントリ・キャッシュ

エントリ・キャッシュは、クライアント・アプリケーションへの配信のためにフォーマットされた、最近アクセスされたエントリを保持します。

8.1.2.1 エントリ・キャッシュの仕組み

デフォルトで、エントリ・キャッシュは負荷に応じて、サーバーにより完全に管理されます。エントリのキャッシュ・メモリーは、ユーザーが指定したエントリ・キャッシュの最大サイズに基づき、そのサイズを超えるまで必要に応じて割り当てられます。

エントリ・キャッシュに格納されたエントリはすでにフォーマット済なので、Directory Serverはエントリ・キャッシュからエントリを効率的に返すことができます。データベースのエントリは、クライアント・アプリケーションに配信される前にフォーマットされ、エントリ・キャッシュに格納される必要があります。

8.1.2.2 エントリ・キャッシュのプレロード

エントリー・キャッシュをプレロード、または準備するようにDirectory Serverを構成し、Directory Serverがシャットダウンする前に、有益なユーザー・データのみがディスクに書き込まれるようにできます。その後、Directory Serverが再起動したときに有益なデータのみが読み取られます。プレロード・オプションを選択した場合、起動時にデータベース・キャッシュとDNキャッシュが自動的に準備されるように、最後に使用されたentryIDのみがディスクに保存されます。詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』を参照してください。

8.1.2.3 エントリ・キャッシュ・サイズの変更

デフォルトで、エントリ・キャッシュは負荷に応じて、サーバーにより完全に管理されます。エントリのキャッシュ設定を変更する前に、デフォルト値でのサーバーのパフォーマンスの程度を評価する場合があります。

指定する最大サイズは、Directory Serverが要求する、基本のメモリー割当てライブラリからのメモリー量を示します。メモリーに対するリクエストをメモリー割当てライブラリが処理する方法によっては、Directory Serverがエントリ・キャッシュに使用できるメモリー容量よりも使用される実際のメモリーがはるかに大きい場合があります。

Directory Serverのプロセスにより使用されるメモリーは、使用されるメモリー割当てライブラリと、キャッシュされるエントリによって異なります。多くの小さな属性値を持つエントリは通常、少数の大きな属性値を持つエントリよりも多くのオーバーヘッドを必要とします。

設定できるキャッシュ・サイズのプロパティの詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』またはサーバーのmanページを参照してください。チューニングの推奨事項については、『Oracle Directory Server Enterprise Editionデプロイメント・プランニング・ガイド』を参照してください。

8.1.3 インポート・キャッシュ

インポート・キャッシュはサフィックスが初期化されるときに作成され、使用されます。導入時にオフラインでのサフィックスの初期化のみが行われる場合、インポート・キャッシュとデータベース・キャッシュが同時に使用されることはありません。この場合、インポート・キャッシュとデータベース・キャッシュは、キャッシュ・サイズの集計時に一緒に追加される必要はありません。「総計キャッシュ・サイズ」を参照してください。インポート・キャッシュ・サイズが変更された場合、サフィックスが次にリセットされ、初期化されたときにその変更が有効になります。インポート・キャッシュは初期化のために割り当てられ、初期化後に解放されます。

Directory Serverでは、インポート・キャッシュの処理をデータベース・キャッシュの処理と同じように行います。スワップを避けるには、十分な物理メモリーが使用可能であることが必要です。インポート・キャッシュのサイズが大きいという利点は、キャッシュ・サイズが2GBを超えると薄くなります。

8.1.4 ファイル・システム・キャッシュ

オペレーティング・システムは、Directory Serverのキャッシュや他のアプリケーションに使用されていない利用可能なメモリーを、ファイル・システム・キャッシュに割り当てます。ファイル・システム・キャッシュはディスクから最近読み取られたデータを保持するので、後続のリクエストがデータを取得するのにディスクから再度読み取るのではなく、キャッシュから取得できます。メモリー・アクセスはディスク・アクセスよりも何倍も高速なので、一部の物理メモリーをファイル・システム・キャッシュが利用できるようにしておくと、パフォーマンスが飛躍的に向上します。

ファイル・システム・キャッシュはデータベース・キャッシュの一部のかわりに使用できます。Directory Serverではデータベース・キャッシュを使用する方がファイル・システム・キャッシュを使用するよりも効率的ですが、ファイル・システム・キャッシュはDirectory Serverのns-slapdプロセスと直接関連付けられていません。データベース・キャッシュだけを使用した場合に利用可能なキャッシュ・サイズよりも大きな総計キャッシュ・サイズがDirectory Serverで利用できるようになる可能性があります。

ファイル・システム・キャッシュについては、オペレーティング・システムのドキュメントを参照してください。

8.1.5 総計キャッシュ・サイズ

同時に使用されるすべてのキャッシュの合計は、使用可能な物理メモリーの総計サイズから、ファイル・システム・キャッシュのためのメモリーと、Directory Server自身のような他のプロセスのためのメモリーを差し引いたサイズよりも小さくしておく必要があります。

32ビット・サーバーの場合、総計キャッシュ・サイズは、Directory Serverのns-slapdプロセスの合計サイズがオペレーティング・システムで可能な最大プロセス・サイズ未満になるように制限する必要があります。実際には、この制限は一般的に2GBから3GBの範囲です。

Directory Serverがオンラインの時にサフィックスが初期化される場合、データベース・キャッシュ、エントリ・キャッシュおよびインポート・キャッシュのサイズの合計が、利用可能な物理メモリーの合計サイズ未満になっている必要があります。

表8-1 インポート操作とキャッシュの使用

キャッシュ・タイプ

オフライン・インポート

オンライン・インポート

データベース

不可

可

エントリ

可

可

インポート

可

可

Directory Serverがオフラインのときにすべてのサフィックスが初期化される場合は、インポート・キャッシュとデータベース・キャッシュが共存しないため、オフラインのサフィックス初期化のためのインポート・キャッシュと、オンラインで使用するためのデータベース・キャッシュに同じメモリーを割り当てることができます。こうした特殊な場合の実装では、本番サーバーでオンライン一括ロードを実行しないようにしてください。同時に使用されるキャッシュの合計は、使用可能な物理メモリーの合計サイズ未満になっている必要があります。

キャッシュが非常に大きい場合は、Directory Serverにより使用されるメモリーが、利用可能な物理メモリーのサイズを超えないことが重要です。利用可能な物理メモリーのサイズを超えた場合は、システムのページングが繰返し発生し、パフォーマンスが低下します。

8.2 Directory Serverによるキャッシュを使用した検索の実行方法

図8-2で、個々の線は異なるレベルのメモリーにアクセスするそれぞれのスレッドを表しています。破線は、Directory Serverを効果的に調整することにより最小化される、可能性のあるボトルネックを表します。

図8-2 ディレクトリ・サーバーによる検索の実行方法

「図8-2 Directory Serverによる検索の実行方法」の説明

次の各項では、キャッシュを使用してDirectory Serverが検索を実行する方法について説明します。次の各項で説明するように、サブツリー検索を処理することにより、Directory Serverはすべての結果セットをメモリーにロードすることなく、結果を返します。

8.2.1 Directory Serverによるベース検索の実行方法

ベース検索はベースDNを指定するもので、Directory Serverによる管理が最も単純なタイプの検索です。Directory Serverは次の手順でベース検索を処理します。

1. Directory Serverがエントリ・キャッシュからエントリの取得を試行します。
エントリ・キャッシュでエントリが検出されると、Directory Serverは候補のエントリが検索に指定されたフィルタと一致するかどうかを検査します。

エントリが検索に指定されたフィルタと一致した場合、Directory Serverはフォーマット済のキャッシュされたエントリをクライアント・アプリケーションに返します。

2. Directory Serverがデータベース・キャッシュからエントリの取得を試行します。
データベース・キャッシュでエントリが検出されると、Directory Serverはそのエントリをサフィックスのエントリ・キャッシュにコピーします。Directory Serverは、エントリがエントリ・キャッシュで検出されたかのように処理を進めます。

3. Directory Serverはデータベース自身からエントリの取得を試行します。
データベースでエントリが検出されると、Directory Serverはそのエントリをデータベース・キャッシュにコピーします。Directory Serverは、エントリがデータベース・キャッシュで検出されたかのように、処理を進めます。

8.2.2 Directory Serverによるサブツリー検索および1レベル検索の実行方法

サブツリーまたはツリーのレベルに対する検索には、複数のエントリを処理するための追加プロセスが含まれます。Directory Serverは次の手順でサブツリー検索および1レベル検索を処理します。

1. Directory Serverがデータベース・キャッシュの索引からのフィルタに一致する一連の候補エントリの定義を試行します。
適切な索引が存在しない場合、候補エントリ・セットがデータベース自身で直接検出される必要があります。

2. 各候補エントリについて、Directory Serverは次のタスクを実行します。

1. エントリを取得するためにベース検索を実行します。

2. 検索に指定されたフィルタにエントリが一致するかどうかを検査します。

3. エントリがフィルタに一致する場合にクライアント・アプリケーションにエントリを返します。

8.3 Directory Serverによるキャッシュを使用した更新の実行方法

図8-3で、個々の線は異なるレベルのメモリーにアクセスするそれぞれのスレッドを表しています。破線は、Directory Serverを効果的に調整することにより最小化される、可能性のあるボトルネックを表します。

図8-3 Directory Serverによる更新の実行方法

「図8-3 Directory Serverによる更新の実行方法」の説明

この図には、更新のエントリを取得するために実行される内部ベース検索による影響は示されていません。

Directory Serverは次の手順で更新を処理します。

1. Directory Serverはエントリを取得するため、または追加操作の場合はエントリを更新するか、エントリがまだ存在していないことを検証するためにベースDN検索を実行します。

2. Directory Serverはデータベース・キャッシュおよび影響を受ける索引を更新します。
変更により影響を受けるデータがデータベース・キャッシュにロードされていない場合は、この段階は当該データがキャッシュにロードされる際のディスク・アクティビティになることがあります。

3. Directory Serverは変更に関する情報をトランザクション・ログに書き込み、情報がディスクにフラッシュされるのを待ちます(ディスクへのフラッシュは各チェックポイントで定期的に発生します)。つまり、Directory Serverのデータベース・ファイルは書込みごとではなく、チェックポイント操作時に更新されます。

4. Directory Serverは更新されたエントリをフォーマットし、サフィックスのエントリ・キャッシュにコピーします。

5. Directory Serverはクライアント・アプリケーションに、更新が正常に終了したという確認を返します。

8.4 Directory Serverによるキャッシュを使用したサフィックスの初期化方法

次の図は、Directory Serverがキャッシュを使用してサフィックスを初期化する方法を示しています。個々の線は異なるレベルのメモリーにアクセスするそれぞれのスレッドを表しています。破線は、Directory Serverを効果的に調整することにより最小化される、可能性のあるボトルネックを表します。

図8-4 Directory Serverによるサフィックスの初期化方法

「図8-4 Directory Serverによるサフィックスの初期化方法」の説明

Directory Serverは次の手順でサフィックスを初期化します。

1. LDIFからバッファをフィードするためのスレッドを開始します。

2. 影響を受ける各索引のスレッドおよび索引を更新するための他のワーキング・スレッドを開始します。これらのスレッドはインポート・キャッシュを使用します。

3. インポート・キャッシュが足りなくなると、データベース・ファイルで読み書きします。

また、Directory Serverはサフィックスの初期化時にログ・メッセージを書き込みますが、トランザクション・ログには書き込みません。

Directory Serverに付属するサフィックス初期化ツールには、キャッシュのヒット率およびインポートのスループットに関するフィードバックが用意されています。キャッシュ・ヒット率およびインポートのスループットが同時に低下した場合は、インポート・キャッシュが小さすぎることが考えられます。

9 Directory Serverの索引作成

書籍の索引と同様に、Directory Serverの索引を利用することで、検索文字列とディレクトリの内容を関連付け、検索が速くなります。Directory Serverによって使用される索引の詳細は、次の項を参照してください。

- 索引の概要

- システム索引およびデフォルトの索引

- 索引のタイプ

9.1 索引の概要

Directory Serverは索引を使用して、Directory Serverのエントリと参照情報を関連付けることによって検索操作の速度を向上させます。検索操作中に、Directory Serverは索引を使用して、検索キーと一致するエントリを検索します。索引なしでは、Directory Serverは検索キーへの一致を検索するために、サフィックスにおいてすべてのエントリをチェックする必要があります。

索引はデータベース・ファイルに格納され、ディレクトリにおける各サフィックスとは無関係に作成および管理されます。各索引ファイルには、特定の属性に対してサフィックスにおいて定義されている、索引のすべてが含まれています。たとえば、cn属性に関して保持されるすべての索引が、databaseName_cn.db3ファイルに格納されます。索引付けされたエントリが修正されると、Directory Serverは索引ファイルを更新します。

Directory Serverでは次のタイプの索引がサポートされています。

- 検索のパフォーマンスを向上するための、または他のアプリケーションによって実行される検索をサポートするためのデフォルトの索引。サフィックスが作成される際に、デフォルトの索引が追加されます。

- Directory Serverが適切におよび効率的に動作することを可能にする、システム索引。

- ユーザーが属性を作成する際に、または新規索引を定義する際に追加される、ユーザー索引。

9.2 システム索引およびデフォルトの索引

この項の内容は次のとおりです。

- システム索引

- デフォルトの索引

9.2.1 システム索引

システム索引は、Directory Serverが適切におよび効率的に動作することを可能にするために必要です。システム索引の削除や変更はできません。表9-1は、すべてのサフィックスに自動的に作成されるシステム索引を示しています。

表9-1 すべてのサフィックスに自動的に作成されるシステム索引

属性

同等索引付け

存在索引付け

説明

aciCaret

X

ディレクトリ・サーバーが、ディレクトリに保持されているアクセス制御情報を迅速に取得することを可能にする。

ancestorid

X

サブツリー検索中にディレクトリのパフォーマンスを向上させる。

entrydn

X

DN検索に基づき、エントリの取得速度を向上させる。

id2entry

X

ディレクトリ・エントリに関する実際のデータベースを含む。これから、他のすべてのデータベース・ファイルが再作成可能。

nsUniqueId

X

特定のエントリの検索に使用される。

nscpEntryDN

X

レプリケーション用のDirectory Serverで内部的に使用される。

nsds5ReplConflict

X

X

レプリケーションの競合の検出に役立つ。

numsubordinates

X

ディレクトリ・タブにおける表示パフォーマンスの向上のために、Directory Service Control Centerによって使用される。

objectClass

X

サブツリー検索の速度を速める。

parentID

X

1レベルの検索中にディレクトリのパフォーマンスを向上させる。

9.2.2 デフォルトの索引

ご使用のディレクトリに新しいサフィックスを作成すると、サーバーは、対応するデータベース・ディレクトリにデフォルトの索引のセットを構成します。ご使用の索引作成の必要性に応じて、デフォルトの索引を修正できます(ただし索引を削除する前に、御社においてサーバー・プラグインまたは他のサーバーが索引付けされた属性に依存していないことを確認する必要があります)。

表9-2は、Directory Serverに構成されるデフォルトの索引をリスト表示しています。

表9-2 すべての新規サフィックスにおけるデフォルトの索引

属性

同等索引付け

存在索引付け

部分文字列索引付け

説明

cn

X

X

X

ディレクトリ検索の最も一般的なタイプについてのパフォーマンスを改善。

givenName

X

X

X

ディレクトリ検索の最も一般的なタイプについてのパフォーマンスを改善。

mail

X

X

X

ディレクトリ検索の最も一般的なタイプについてのパフォーマンスを改善。

mailAlternateAddress

X

メッセージング・サーバーによる使用。

mailHost

X

メッセージング・サーバーによる使用。

member

X

サーバーのパフォーマンスの向上。この索引は、参照整合性プラグインによっても使用される。

nsCalXItemId

X

X

X

カレンダ・サーバーによる使用。

nsLIProfileName

X

メッセージング・サーバーのローミング機能による使用。

nsRoleDN

X

ロールベースの操作のパフォーマンスを改善。

nswcalCALID

X

カレンダ・サーバーによる使用。

owner

X

サーバーのパフォーマンスの向上。この索引は、参照整合性プラグインによっても使用される。

pipstatus

X

その他のサーバーによる使用。

pipuid

X

その他のサーバーによる使用。

seeAlso

X

サーバーのパフォーマンスの向上。この索引は、参照整合性プラグインによって使用される。

sn

X

X

X

ユーザー・ディレクトリ検索の最も一般的なタイプについてのパフォーマンスを改善。

telephoneNumber

X

X

X

ユーザー・ディレクトリ検索の最も一般的なタイプについてのパフォーマンスを改善。

uid

X

サーバーのパフォーマンスの向上。

uniquemember

X

サーバーのパフォーマンスの向上。この索引は、参照整合性プラグインによっても使用される。

9.3 索引のタイプ

近似索引付けの場合を除き、この項における索引は、基本的な一致ルールを高速化するためにDirectory Serverによって使用されます。この項では、次の索引タイプについて説明します。

- 存在索引付け

- 同等索引付け

- 部分文字列索引付け

- 索引の参照

- 近似索引付け

- 国際索引

9.3.1 存在索引付け

存在索引付けには、指定された属性の値を含むデータベースにおけるすべてのエントリが、値に関係なく含まれます。次の図は、nsRoleDN属性の存在索引付けを示します。この属性の詳細は、nsRoleDNについての説明を参照してください。

図9-1 存在索引付け

「図9-1 存在索引付け」の説明

Directory Serverは、entryid属性の値を使用して、エントリへの参照を格納します。Directory Serverは、instance-path/db/dbinstance/dbinstance_id2entry.db3索引ファイルの使用によって、エントリを取得します(dbinstanceは、データべース識別子に依存します)。

Directory Serverが存在索引付けされた属性値を削除するリクエストを受けた場合、クライアント・アプリケーションへの更新を確認する前に、この属性の存在索引付けからエントリを削除する必要があります。

存在索引付け向けに保持されるエントリのリストが長くなる可能性がありますが、存在索引付けによる負荷は一般的に低いものとなっています。索引リストの長さが短い場合、存在索引付けは、ディレクトリ・エントリの比較的小さい割合を占める属性の場合に役立ちます。

9.3.2 同等索引付け

同等索引付けには、任意の属性について指定された値を含む、データベースにおけるすべてのエントリが含まれます。この索引は、検索フィルタで値が指定される必要があります。次の図は、sn (すなわち姓)属性の同等索引付けを示します。この索引は、sn属性の値のリストを保持します。この属性の詳細は、snについての説明を参照してください。

図9-2 同等索引付け

「図9-2 同等索引付け」の説明

Directory Serverが同等索引付けされたエントリを更新するリクエストを受けた場合、更新を実行してクライアントへの更新を確認する前に、次の作業を行う必要があります。

- 索引からエントリを削除する必要があるかどうかの判断

- 索引に対してリストを追加または削除する必要があるかどうかの判断

同等索引付けの負荷は、部分文字列索引付けの場合よりも通常低いですが、同等索引付けは存在索引付けよりも容量を必要とします。メッセージング・サーバーなどの一部のクライアント・アプリケーションは、検索のパフォーマンスについては同等索引付けに依存する場合があります。写真やハッシュ・パスワードのような大きなバイナリ属性には、同等索引付けの使用を避けてください。

9.3.3 部分文字列索引付け

部分文字列索引付けは、3文字のグループの検索に使用されます(例: sn=*abc*)。3文字のグループが、この索引に格納されます。部分文字列索引付けは、写真などのバイナリ属性には適用できません。次の図は、SN属性の部分文字列索引付けを示します。

図9-3 SN属性の部分文字列索引付け

「図9-3 SN属性の部分文字列索引付け」の説明

Directory Serverの検索アルゴリズムは次の検索向けに最適化されていますが、これらの検索は、索引リストのしきい値に到達する可能性が高くなっています。

- sn=*ab*形式で2文字の部分文字列についての検索。

- sn=a*形式で1文字のグループについての検索。sn=*aおよびsn=*a*の形式で1文字のグループについては、検索を実行できません。

Directory Serverは、独自の組込みルールに基づき、部分文字列の索引を構築します。システム管理者は、部分文字列索引付けを構成できません。

Directory Serverが、部分文字列に索引付けされた属性のあるエントリを更新するリクエストを受けた場合、更新を実行してクライアントへ更新について応答する前に、次の作業を行う必要があります。

- 索引からエントリを削除する必要があるかどうかの判断

- エントリへの修正が索引に影響するかどうか、およびどのように影響するかを判断

- 索引に対して、エントリIDまたはエントリIDのリストを追加または削除する必要があるかどうかの判断

部分文字列索引付けの保持は負荷が比較的高く、索引付けされた部分文字列の長さの関数が負荷となります。負荷を最小にするために、不要な部分文字列索引付け(特に説明などの長い文字列となる可能性がある属性)を回避します。

9.3.4 索引の参照

索引の参照は、仮想リスト表示索引とも呼ばれます。索引の参照は、サーバー側のソートまたは仮想リスト表示(VLV)結果をリクエストする、検索操作に使用されます。索引の参照を使用して、大量の結果をサーバー側でソートすることが必要となる、検索のパフォーマンスを改善できます。ご使用のディレクトリ構成に応じて、索引の参照が定義されていない場合に、ソートを必要とする検索の実行をサーバーが拒否する可能性があります。これによって、大量のソート作業がサーバー・リソースに負荷をかけすぎることを防止します。

索引の参照は、vlvSearchオブジェクト・クラスの次のパラメータ、vlvBasevlvScope、vlvScopeおよびvlvFilterで構成されます。索引の参照は、vlvIndexオブジェクト・クラスの次のパラメータ、vlvSortによってソートされます。

索引の参照は、2つのステップで構成されます。

1. 検索ベース、検索の範囲および検索のフィルタは、vlvSearchオブジェクト・クラスのvlvBase、vlvScopeおよびvlvFilter属性によって構成されます。

2. 索引をソートする属性名は、vlvIndexオブジェクト・クラスのvlvSort属性によって構成されます。

次の図は、索引の参照を示しています。

図9-4 索引の参照の図示

「図9-4 索引の参照の図示」の説明

vlvFilter値のあるエントリを更新するリクエストをDirectory Serverが受けた場合、更新を実行してクライアントへの更新を確認する前に、次の作業を行う必要があります。

- 索引からエントリを削除する必要があるかどうかの判断

- リストにおけるエントリの正しい位置を特定

9.3.5 近似索引付け

近似索引付けは、効果的なあいまい検索を実現するために、英語のみで動作します。たとえば近似索引付けは、名前の一部やつづりの誤った名前の検索に役立ちます。Directory Serverは、Metaphone音声アルゴリズムの一種を使用して、近似索引付けで検索を実行します。このアルゴリズムは音節に緩やかに基づいているため、電話番号などの数字を含む属性には効果的ではありません。

9.3.6 国際索引

国際索引は、一致ルール索引とも呼ばれます。国際索引は、言語固有の一致ルールと属性を関連付けます。この索引タイプを使用すると、言語ルールに従って属性をソートおよび検索できます。国際索引は、索引を保持するために、特定のロケールに適した一致ルールを使用します。

国際および他のタイプの索引付けへの標準サポートは、カスタム一致ルールのサーバー・プラグインを使用することによって拡張可能です。

10 Directory Serverのロギング

Directory Serverで使用されるログ・タイプおよびサーバー・ログの説明の詳細は、次の項を参照してください。

- ログの概要

- トランザクション・ログ

- アクセス、エラーおよび監査ログ

10.1 ログの概要

次の表は、Directory Serverによって使用される様々なログをまとめたものです。

表10-1 Directory Serverによって使用されるログ

ログ

タイプ

説明

トランザクション・ログ

データベース

更新操作の結果のコードがクライアント・アプリケーションに返される前に、ディスクのトランザクション・ログに各更新操作をコミットすることによって、データの整合性を確保します。

Directory Serverは更新操作を受け入れる際に、操作についてのログ・メッセージをトランザクション・ログに書き込みます。システムがクラッシュした場合、Directory Serverはトランザクション・ログを使用してデータベースをリカバリします。

アクセス・ログ

フラット・ファイル

ディレクトリの使用パターンを評価し、構成設定を検証し、アクセス上の問題を診断します。アクセス・ログの詳細は、「アクセス・ログ」を参照してください。

エラー・ログ

フラット・ファイル

ディレクトリのデプロイメントをデバッグします。エラー・ログの詳細は、「エラー・ログ」を参照してください。

監査ログ

フラット・ファイル

セキュリティおよびデータの整合性に関する監査証跡を提供します。監査ログの詳細は、「監査ログ」を参照してください。

10.2 トランザクション・ログ

次のサーバー・プロパティによって、トランザクション・ログを構成します。

db-checkpoint-interval

Directory Serverがトランザクション・ログのチェックポイントを実行する回数で、データベース・システム全体がディスクに対して同期され、トランザクション・ログがクリーン・アップされることを確実にします。

db-durable-transaction-enabled

結果コードがクライアントに送信される前に、更新操作がディスクのトランザクション・ログに対してコミットされるかどうか。

db-log-buf-size

バッファが一杯になるか、あるいはトランザクションのコミットによってバッファがディスクに強制的に書き込まれるまでメモリーに格納される、ログ情報用のバッファ・サイズ。

db-log-path

トランザクション・ログのパス。

db-batched-transaction-count

ディレクトリ・データベースに対してコミットされる前に累積する、更新回数。

詳細は、サーバーに関する説明を参照してください。

10.3 アクセス、エラーおよび監査ログ

アクセス・ログ、エラー・ログおよび監査ログは、操作に関する情報を含むフラット・ファイルです。ログの表示および構成方法の詳細は、Oracle Directory Server Enterprise Editionの管理に関するガイドの第14章のDirectory Serverのロギングについてを参照してください。

デフォルトでは、ログはディレクトリinstance-path/logs/に格納されています。

ログ・ファイルは、必要に応じてローテーションが可能で、特定の曜日および時刻にローテーションするようにスケジュール可能であったり、またはログ・ファイルが指定の最小サイズを超えた場合にローテーションが可能であったりします。

古いログ・ファイルは、同じ名前で、このファイルが作成された日付を含む拡張子(filename.YYYYMMDD-hhmmssの形式)を持ち、同じパスに格納されます。サーバーは、すべてのログ・ファイルを作成日付を記録するために、同じ名前で.rotationinfo拡張子のファイルも保持します。

アクセス・ログ、エラー・ログおよび監査ログの詳細は、次の項を参照してください。

- アクセス・ログ

- エラー・ログ

- 監査ログ

- アクセス・ログ、エラー・ログおよび監査ログの内容

- ログ・ファイルにおける接続コード

- ログ・ファイルにおける結果コード

10.3.1 アクセス・ログ

アクセス・ログには、LDAPクライアントとディレクトリ・サーバー間の接続に関する情報が含まれています。接続は、同じクライアントからの一連のリクエストであり、次のコンポーネントを含みます。

- 接続索引およびクライアントのIPアドレス

- バインド・レコード

- バインド結果レコード

- 操作要求と操作結果が対になった一連のレコード(接続レコード、接続解除レコードおよび中断レコードの場合は単独のレコード)

- バインド解除レコード

- 接続解除レコード

10.3.2 エラー・ログ

エラー・ログには、エラーに関する一意の識別子、警告または情報のメッセージ、および人が理解できる形式のメッセージが含まれます。エラーは、次の重大度に従って定義します。

エラー

深刻なエラーです。ディレクトリ・データの損失または破損を回避するために、今すぐアクションが必要です。

警告

重要なエラーです。将来に深刻なエラーが発生することを防止するために、ある段階でアクションを行う必要があります。

情報

情報メッセージであり、通常は深刻なアクティビティについて説明しています。処置は必要ありません。

10.3.3 監査ログ

監査ログには、構成またはサフィックス・エントリに対するすべての変更のレコードが含まれます。変更は、LDIF形式で書き込まれます。

デフォルトでは、監査ロギングは有効になっていません。監査ロギングを有効化するには、『Oracle Directory Server Enterprise Edition管理者ガイド』の手順の監査ログの有効化に関する説明を使用します。

10.3.4 アクセス・ログ、エラー・ログおよび監査ログの内容

この章の以降の項では、ログ・ファイルの各部分について説明します。

10.3.4.1 タイプ・スタンプ

アクセス・ログ・ファイルの各行は、[20/Dec/2006:11:39:51 -0700]のような形式のタイム・スタンプで開始します。タイム・スタンプ-0700は、GMTとの関連で時差を示します。

タイム・スタンプの形式は、ご使用のプラットフォームによって異なる可能性があります。接続レコード、接続解除レコードおよび中断レコードが、個別に表示されます。その他のレコードがペアで表示され、すべてサービス要求レコードとそれに続く結果レコードのペアで示されます。このレコードのペアは、通常は隣接する行に示されますが、そうでない場合もあります。

10.3.4.2 接続番号

接続番号は、conn=値によって示されます。すべての外部リクエストは、増分方式の接続番号でリスト表示されます。

conn=Internalの場合、この操作は内部操作です。内部アクセス操作をログに記録するには、dsconf構成属性でacc-internalのアクセス・ロギング・レベルを指定します。

10.3.4.3 ファイル記述子

ファイル記述子は、fd=値によって示されます。

外部LDAPクライアントからディレクトリ・サーバーへの接続ごとに、オペレーティング・システムのファイル記述子が必要です。利用可能なファイル記述子のプールから、ファイル記述子が取得されます。

10.3.4.4 スロット番号

スロット番号は、ファイル記述子と同じ意味を持ちます。スロット番号はアクセス・ログのレガシー部分であるため、無視できます。

10.3.4.5 操作番号

操作番号は、op=値によって示されます。

接続に関して、すべての操作リクエストおよび結果のペアは、op=0で始まる増分方式の任意の操作番号です。操作番号は、実行されている操作を識別します。

op=-1の場合、接続へのLDAPリクエストは外部LDAPクライアントによっては発行されず、内部的に開始されます。

10.3.4.6 方法のタイプ

方法のタイプは、method=値によって示されます。

方法のタイプは、クライアントによって使用されるバインドの方法を示しています。方法のタイプは、次の値のいずれかが可能です。

0

認証なし

128

ユーザーのパスワードによる簡単なバインド

sasl

外部認証メカニズムを使用したSASLバインド

10.3.4.7 LDAPのバージョン

LDAPのバージョンは、LDAPv2またはLDAPv3です。LDAPバージョンは、LDAPクライアントがLDAPサーバーと通信するために使用したLDAPバージョン番号を示します。

10.3.4.8 エラー番号

エラー番号は、err=番号によって示されます。

エラー番号は、LDAP操作から返されたLDAP結果コードを示します。LDAPのエラー番号0は、その操作が正常に終了したことを表します。LDAP結果コードのリストについては、「ログ・ファイルにおける結果コード」を参照してください。

10.3.4.9 タグ番号

タグ番号は、tag=値によって示されます。

タグは、メッセージのデコードのために内部的に使用され、外部向けの使用は意図していません。頻繁に使用されるタグを次に示します。

tag=97

クライアントのバインド操作

tag=100

検索していたエントリ

tag=101

検索操作の結果

tag=103

変更操作の結果

tag=105

追加操作の結果

tag=107

削除操作の結果

tag=109

DN操作の変更の結果

tag=111

比較操作の結果

tag=115

検索を実行するエントリに、要求するエントリへのリフェラルが保持されている場合の検索参照。検索参照はリフェラルによって表されます。

tag=120

拡張操作の結果

10.3.4.10 エントリ数

エントリの数は、nentries=値によって示されます。

エントリ数は、LDAP検索リクエストと一致したエントリの数を示します。

10.3.4.11 経過時間

経過時間は、etime=値によって示されます。

経過時間は、LDAP操作の実行にかかった時間を示します。etimeの値が0の場合は、操作の実行にかかった時間がミリ秒単位であったことを示します。

ミリ秒単位の時間をログに記録するには、dsconf構成属性でacc-timingのアクセス・ロギング・レベルを指定します。

10.3.4.12 LDAPリクエスト・タイプ

LDAPリクエスト・タイプは、LDAPクライアントによって作成されたLDAPリクエストのタイプを示します。作成される可能性があるLDAPリクエストは、次のタイプです。

SRCH

検索

MOD

変更

DEL

削除

ADD

追加

MODDN

DNの変更

EXT

拡張操作

ABANDON

中止操作

COMPARE

比較操作

10.3.4.13 LDAPレスポンス・タイプ

LDAPレスポンス・タイプは、サーバーによって返されたLDAPレスポンスを示します。返される可能性があるLDAPレスポンスは、次となっています。

RESULT

結果

ENTRY

エントリ

REFERRAL

リフェラルまたは検索参照

10.3.4.14 索引付けされていない検索インジケータ

索引付けされていない検索インジケータは、notes=Uで示されます。

索引付けされていない検索では、索引ファイルのかわりにデータベースが検索されます。索引付けされていない検索は、次の理由によって発生します。

- 検索で使用された索引ファイルにおいて、すべてのIDのしきい値に到達

- 索引ファイルが存在しない

- 索引ファイルが、検索に必要な方法で構成されていない

索引付けされていない検索は、索引付けされている検索よりも一般に多くの時間を必要とするため、多くの場合、索引付けされていない検索インジケータのetime値は大きくなります。

10.3.4.15 拡張操作OID

拡張操作OIDは、EXT oid="OID番号"によって示されます。サポートされる拡張操作のリストは、extended-operationsを参照してください。

10.3.4.16 ログ・ファイルにおける変更シーケンス番号

レプリケーションの変更シーケンス番号は、csn=値によってログ・ファイルに示されます。

変更シーケンス番号の存在によって、このネーミング・コンテキストでレプリケーションが有効になっていることを示します。

10.3.4.17 中止メッセージ

中止メッセージは、ABANDONによって示されます。

中止メッセージの存在は、操作が中断されたことを示しています。メッセージIDが中止された操作の検索に成功した場合、ログ・メッセージは次のように読み取ります。

conn=12 op=2 ABANDON targetop=1 msgid=2 nentries=0 etime=0

ただしメッセージIDが操作の検索に成功しなかった場合、またはABANDONリクエストが送信される前に操作がすでに終了している場合、ログ・メッセージは次のように読み取ります。

conn=12 op=2 ABANDON targetop=NOTFOUND msgid=2

中止メッセージは、次のパラメータを使用します。

nentries

操作が中止されるまでに送信されたエントリ数を示します。

etime

操作が中止されるまでに経過した秒数を示します。

targetop

中止される操作を識別します。値がNOTFOUNDの場合、中止する操作が不明な操作であったか、またはすでに完了していたことを示します。

10.3.4.18 メッセージID

メッセージIDは、msgId=値によって示されます。

メッセージIDは、クライアントによって生成されたLDAP操作識別子です。メッセージIDは操作番号に対して異なる値である可能性がありますが、同じ操作を識別します。ABANDON操作におけるメッセージIDは、どのクライアント操作が中止されているかを明示します。

操作番号は、0から始まります。ただし多くのクライアントの実装では、メッセージID番号は1から始まります。したがって多くの場合、メッセージIDは操作番号に1を加えたものと同じになります。

10.3.4.19 SASLマルチステージ・バインド・ログ

Directory Serverは複数の段階があるバインド・プロセスにおける各段階をログに記録し、該当する場合は、進行状況の報告「SASL bind in progress」が含まれます。

アクセス制御の決定に使用されるDNはBIND結果行にログが記録され、バインド・リクエスト行には記録されません。

conn=14 op=1 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=myname,dc=example,dc=com"

SASLバインドの場合、バインド・リクエスト行に表示されるDN値はサーバーでは使用されないので、この値はSASLバインドとは関係ありません。ただしSASLバインドの場合、認証されたDNは監査目的に使用される必要があります。したがって、認証されたDNは明確にログに記録される必要があります。認証されたDNをバインド結果行にログ記録することによって、どちらのDNであるのかとの混乱を回避できます。

10.3.4.20 オプションの説明

オプションの説明でoptions=persistentについては、永続検索が実行されていることを示しています。永続検索は監視の一形態として利用でき、特定の構成に対する変更を返すように設定できます。アクセスログでは、永続検索と通常の検索が区別されます。

10.3.5 ログ・ファイルにおける接続コード

接続コードは、ログ・ファイルのclosingメッセージに含まれます。接続コードは、接続解除の理由に関する追加情報を提供します。次の表は、共通の接続コードを説明しています。

10.3.6 ログ・ファイルにおける結果コード

次の表は、LDAPサーバーおよびLDAPクライアントによって生成されたLDAP結果コードをまとめたものです。

表10-2 LDAPサーバーの結果コードのまとめ

結果コード

説明

0

正常終了

1

操作エラー

2

プロトコル・エラー

3

時間制限を超過しました

4

サイズ制限を超過しました

5

Falseを比較

6

Trueを比較

7

認証方法がサポートされていません

8

強い認証が必要です

9

受信した結果とリフェラルは一部分です

10

リフェラル受信済

11

管理上の制限を超過しました

12

クリティカルな拡張機能を使用できません

13

機密性が必要です

14

SASLバインドが進行中です

16

そのような属性はありません

17

未定義の属性タイプ

18

不正な照合

19

制約違反

20

タイプまたは値が存在しています

21

無効な構文

32

該当オブジェクトなし

33

エイリアスの問題

34

無効なDN構文

35

オブジェクトはリーフです

36

別名の参照解除の問題

48

不正な認証

49

無効な資格証明

50

アクセス権限が不十分です

51

サーバーがビジー状態です

52

サーバーが利用できません

53

サーバーで実行が受け付けられません

54

ループを検出

64

ネーミング違反

65

オブジェクト・クラス違反

66

非リーフ・エントリに対する操作は許可されていません

67

RDNに対する操作は許可されていません

68

エントリがすでに存在します

69

オブジェクト・クラスを変更できません

70

結果が大きすぎます

71

複数サーバーへ影響します

76

仮想一覧表示エラー

表10-3 LDAPクライアントの結果コードのまとめ

結果コード

説明

80

不明なエラー

81

LDAPサーバーに接続できません

82

ローカル・エラー

83

エンコーディング・エラー

84

デコード・エラー

85

タイムアウト

86

認証方式が不明です

87

検索フィルタが正しくありません

88

ユーザーが操作を取り消しました

89

LDAPルーチンに対するパラメータが正しくありません

90

メモリー不足

91

LDAPサーバーに接続できません

92

このバージョンのLDAPでサポートされていません

93

リクエストされたLDAP制御が見つかりません

94

結果は返されませんでした

95

戻される追加結果

96

クライアントのループ検出

97

リフェラル・ホップの制限を超過しました

11 Directory Serverのグループおよびロール

ディレクトリ情報ツリーによって、エントリが階層的に構成されます。この階層は、グループ化メカニズムの一種です。この階層は、分散したエントリ間の関連付けには適していません(頻繁に変更のある組織の場合、または多くのエントリに反復データが存在する場合)。Directory Serverグループおよびロールによって、エントリ間の関連付けがさらに柔軟になります。

この章では、エントリ同士を関連付けるためにDirectory Serverによってグループとロールを使用する方法を説明します。この章の内容は、次のとおりです。

- Directory Serverのグループ

- Directory Serverのロール

- グループかロールかの決定

11.1 Directory Serverのグループ

グループとは、グループ内の他のエントリを識別するためのエントリです。グループのメカニズムによって、特定のグループのメンバーとなるエントリのリストを取得することが容易になります。

グループによってディレクトリ内のどこででもメンバーが識別されるにもかかわらず、このグループ定義自体は、適切に命名されたノード(例: ou=Groups)に配置されます。これによってたとえば、アクセスを付与または制限するアクセス制御命令(ACI)を定義する際に、またはバインド資格証明がグループのメンバーである際に、検索が容易になります。

11.1.1 静的グループ

静的グループは、そのメンバーのエントリを明示的に指名します。たとえば次の図で示されているように、ディレクトリ管理者のグループは、このグループに所属する特定の人々を指名します。

図groups1.pngの説明

次のLDIF抽出は、この静的グループのメンバーがどのように定義されているかを示しています。

dn: cn=Directory Administrators, ou=Groups, dc=example,dc=com
...
member: uid=kvaughan, ou=People, dc=example,dc=com
member: uid=rdaugherty, ou=People, dc=example,dc=com
member: uid=hmiller, ou=People, dc=example,dc=com

静的グループは、グループの各メンバーのDNを指定します。静的グループによって、次のオブジェクト・クラスと属性のペアの1つが使用されます。

- groupOfNamesオブジェクト・クラスと複数値member属性

- groupOfUniqueNamesオブジェクト・クラスと複数値uniqueMember属性

member属性およびuniqueMember属性には、グループのメンバーであるすべてのエントリのDNが含まれています。一意性を保証するために、DNのuniqueMember属性値に、オプションでハッシュ、#および一意の識別子ラベルを続けることができます。

11.1.2 動的グループ

動的グループは、フィルタとこのフィルタに合致するすべてのエントリが、グループのメンバーであることを指定します。このようなグループは、フィルタが評価されるたびにメンバーシップが定義されるため、動的です。

たとえば、御社のビルの3階にすべての経営幹部とそのアシスタントが存在し、各従業員の部屋番号がフロアー番号で始まることを想定してください。3階の従業員のみを含むグループを作成しようとする場合、次の図に示されているように、これらの従業員のみを定義するために部屋番号を使用できます。

図groups2.pngの説明

次のLDIF抽出は、この動的グループがどのように定義されているかを示しています。

dn: cn=3rd Floor, ou=Groups, dc=example,dc=com
...
memberURL: ldap:///dc=example,dc=com??sub?(roomnumber=3*)

動的グループによって、次のオブジェクト・クラスと属性のペアの1つが使用されます。

- groupOfURLsオブジェクト・クラスと複数値memberURL属性

- groupOfUniqueNamesオブジェクト・クラスとuniqueMember属性

グループ・メンバーは、memberURL属性のLDAP URL値として表示される1つ以上のフィルタ、またはuniqueMember属性値としての1つ以上のDNのいずれかによって、リスト表示されます。

11.1.3 ネストされたグループ

静的および動的グループは、member属性またはuniqueMember属性の値として別のグループのDNを指定することによってネスト可能です。ネストされたグループがACIによってサポートされる深さは、nsslapd-groupevalnestlevel構成パラメータによって制御されます。またDirectory Serverは混成グループ、すなわち個別のエントリ、静的グループおよび動的グループを参照するグループもサポートします。

たとえば、すべてのディレクトリ管理者、およびすべての経営幹部とそのアシスタントを含むグループが必要であると想定してください。次の図に示されているように、以前に定義された2つのグループの組合せを使用して、ネストされた1つのグループを作成できます。

図groups3.pngの説明

次のLDIF抽出は、このネストされたグループがどのように定義されているかを示しています。

dn: cn=Admins and 3rd Floor, ou=Groups, dc=example,dc=com
...
member: cn=Directory Administrators, ou=Groups, dc=example,dc=com
member: cn=3rd Floor, ou=Groups, dc=example,dc=com

注意:

ネストされたグループは、最も効率のよいグループ化メカニズムではありません。動的なネストされたグループによって、パフォーマンスへの影響がさらに増加します。このようなパフォーマンスの問題を避けるために、かわりにロールの使用を検討します。

11.2 Directory Serverのロール

ロールはグループに類似していますが、逆の働きをします(すなわち、グループ・エントリがメンバー・エントリのDNをリスト表示する場合に、各メンバー・エントリに関してロール・エントリのDNがリスト表示されます)。ロール・メカニズムによって、エントリに割り当てられているロールのリストの取得が容易になります。

各ロールにはmembersまたはロールを所有するエントリが含まれます。ロール・メカニズムは、nsRoleDN属性およびnsRole属性によって管理されます。nsRoleDN属性は、ロールにエントリを追加するために使用されます。nsRole属性は読取り専用属性で、ディレクトリ・サーバーによって保持され、エントリが属するロールをリストします。nsRole属性は、エントリが属するすべてのロールを列挙するために、クライアントによる読取りまたは検索が可能です。ロール・メンバーシップを公開しないようにするには、nsRole属性を読取り保護するためのアクセス制御を定義します。

デフォルトでは、ロールの範囲は、これが定義されているサブツリーに制限されます。ロールの範囲は、同じサーバー・インスタンスにおける他のサブツリーに拡張できます。

11.2.1 管理対象ロール

管理対象ロールは、静的グループと機能的に非常に類似しています。管理対象ロールは、nsRoleDN属性を各メンバー・エントリに追加することで、明示的にロールをそれらのエントリに割り当てます。この属性の値は、ロール定義エントリのDNです。

ロール定義エントリによってのみ、ディレクトリにおけるロールの範囲が定義されます。ロールのメンバーは、ロール定義の範囲内に存在するエントリで、nsRoleDN属性でロール定義エントリを識別するエントリです。

11.2.2 フィルタ処理されたロール

フィルタ処理されたロールは、動的グループに相当します。エントリは、特定の検索フィルタに合致する場合に、ロールに割り当てられます。検索フィルタの値は、nsRoleFilter属性によって定義されます。サーバーがフィルタ処理されたロールの範囲のエントリを戻す際に、このエントリには、ロールを識別する生成済nsRole属性が含まれます。

11.2.3 ネストされたロール

ネストされたロールは、ネストされたグループに相当します。ネストされたロールによって、他のロールを含むロールを作成し、既存のロールの範囲を拡張することができます。ネストされたロール自体に、他のネストされたロールが含まれます。30レベルまでのネストがサポートされています。

ネストされたロールによって、他のロールの定義エントリがリスト表示され、これらのロールのすべてのメンバーが結合されます。エントリがネストされたロールにリスト表示されているロールのメンバーである場合、このエントリもネストされたロールのメンバーです。

11.2.4 ロールの使用に関する制限事項

ロールを使用してご使用のディレクトリ・サービスをサポートするには、次の制限事項に注意してください。

フィルタ処理されたロールは、CoS生成属性を使用できません。

フィルタされたロールのフィルタ文字列は、CoS仮想値の値に基づくことはできません。ただし、CoS定義の指定子属性が、ロール定義により生成されたnsRole属性を参照する場合があります。CoSの詳細は、第12章のDirectory Serverのサービス・クラスについての説明を参照してください。

ロールの範囲の拡張

ロールの範囲を別のサブツリーに拡張できますが、これらのロールは同じサーバー・インスタンス上に存在している必要があります。ロールの範囲を他のサーバーへ拡張することはできません。

nsRole属性についての検索

nsRole属性は、あらゆる比較演算子とともにあらゆる検索フィルタで使用できます。nsRole属性について検索する際に、次の点を考慮します。

- エントリがフィルタ処理可能となる前にすべてのロールが評価される必要があるため、nsRole属性についての検索には、長い時間がかかる場合があります。

- Directory Serverは、管理対象ロールにおけるメンバーシップについての等価検索向けに最適化されています。たとえば、この検索は実際の属性についての検索とほぼ同じ速さで行われます。

(&(nsRole=cn=managersRole,ou=People,dc=example,dc=com)
(objectclass=person)

- nsRoleDN属性は、デフォルトですべてのサフィックスにおいて索引付けされます。索引付けがnsRoleDN属性に対して無効化されている場合、管理対象ロールのメンバーシップ検索の最適化は失われます。

- フィルタ処理されたロールを含むエントリの検索には、ロール・フィルタによる内部検索が含まれます。ロール・フィルタに表示されるすべての属性が、このロールの範囲におけるすべてのサフィックスで索引付けされている場合、この内部操作は最速となります。

11.3 グループかロールかの決定

グループおよびロール・メカニズムの機能は、ある程度重複しています。両方のメカニズムに、長所と短所があります。一般的にロール・メカニズムは、頻繁に必要な機能を効率的に提供するために設計されています。グループ化メカニズムの選択は、サーバーの複雑さに影響し、クライアントがメンバーシップ情報を処理する方法を特定するため、グループ化メカニズムを慎重に計画する必要があります。どのメカニズムがより適切かを判断するには、代表的なメンバーシップ問合せと実行されている管理操作を理解する必要があります。

11.3.1 グループ・メカニズムの長所

グループには次の長所があります。

- 静的グループは唯一の、標準ベースのグループ化メカニズムです。したがって静的グループは、ほとんどのクライアント・アプリケーションおよびLDAPサーバーと相互運用可能です。

- メンバーを列挙する場合は、ロールよりも、静的グループをお薦めします。
特定のセットのメンバーを列挙することのみが必要な場合、静的グループでの負荷は高くありません。member属性を取得することによって静的グループのメンバーを列挙することは、ロールを共有するすべてのエントリをリカバリするよりも容易です。Directory Serverでは、大きな複数値属性に関して、パフォーマンスが著しく向上します。これらの属性に関する等価一致および変更操作(特に静的グループ関連)は大きく向上します。グループ・エントリのメンバーシップに関するテストも改善されました。以前は静的グループに対するいくつかの制限がありましたが(特にグループ・サイズの制限)、それらの機能強化によって取り除かれました。

Directory Serverはまた、ユーザー・エントリのグループ・メンバーシップに、isMemberOf操作属性を直接提供します。この機能は、静的グループのみに適用されますが、ネストされたグループを含みます。詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の管理グループに関する説明を参照してください。

- メンバーの割当ておよび削除のような管理操作の場合は、ロールよりも、静的グループをお薦めします。
静的グループは、ユーザーをセットに割り当てたり、ユーザーをセットから削除する場合に、最も平易なメカニズムです。ユーザーをグループに追加するために、特別なアクセス権は不要です。

グループ・エントリを自動的に作成する権限によって、グループにメンバーを割り当てる権限が付与されます。これは、管理対象ロールおよびフィルタ処理されたロールには該当しません。このようなロールでは管理者は、ユーザー・エントリにnsroledn属性を書き込む権限も必要です。ネストされたロールにも、同じアクセス権の制限が、間接的に適用されます。ネストされたロールを作成する機能には、すでに定義されている他のロールをまとめる機能が含まれています。

- フィルタベースのACIで使用する場合は、ロールよりも、動的グループをお薦めします。
ACIにおけるバインド・ルールの指定など、フィルタベースのすべてのメンバーの検索のみが必要な場合、動的グループを使用します。フィルタ処理されたロールは動的グループに類似していますが、フィルタ処理されたロールはロール・メカニズムをトリガーし、仮想nsRole属性を生成します。ご使用のクライアントでnsRole値が不要の場合、この計算のオーバーヘッドを回避するために動的グループを使用します。

- 既存のセットに対してセットを追加または削除する場合、ロールよりもグループをお薦めします。
既存のセットへのセットの追加、または既存のセットからのセットの削除を行う場合、グループ・メカニズムが最も平易です。グループ・メカニズムには、ネスト制限がありません。ロール・メカニズムでは、他のロールを受け入れられるのはネストされたロールに限られています。

- エントリのグループ化に関する範囲の柔軟性が重要な場合、ロールよりもグループをお薦めします。
グループ定義エントリの配置場所とは無関係に、可能なメンバーの範囲がディレクトリ全体であるため、範囲に関してはグループが柔軟となっています。ロールも特定のサブツリーを越えて範囲を拡張できますが、ネストされたロールに、範囲拡張属性nsRoleScopeDNを追加することによってのみ、これを実行できます。

11.3.2 ロール・メカニズムの長所

ロールには次の長所があります。

- セットのメンバーを列挙し、かつ特定のエントリがメンバーであるすべてのセットを検索する場合は、動的グループよりもロールをお薦めします。静的グループによっても、この機能にisMemberOf属性が提供されます。
ロールは、ユーザー・エントリにメンバーシップ情報をプッシュし、ここでこの情報は、後続のメンバーシップに関するテストをさらに効率的にするためにキャッシュされます。サーバーはすべての計算を実行し、クライアントはnsRole属性の値を読み込むことのみを必要とします。さらに、この属性のすべてのロール・タイプが表示され、クライアントはすべてのロールを均一に処理できます。ロールは動的グループよりも、両方の操作をさらに効率的に、そして一層平易なクライアントで実行できます。

- ご使用のグループ化メカニズムを既存のDirectory Server機能(CoS、パスワード・ポリシｰ、アカウントの非アクティブ化およびACIなど)と統合する場合、グループよりもロールをお薦めします。
サーバーにおいてセットのメンバーシップを違和感なく使用できるのは、ロールの方です。これは、サーバーが自動的に行うメンバーシップ計算を使用するということを意味します。ロールはリソース指向のACIにおいて、CoSのベースとして、さらに複雑な検索フィルタの一部として、パスワード・ポリシｰやアカウントの非アクティブ化などとともに使用できます。グループではこのような統合はできません。

11.3.3 ロールに関する権限の制限

ロールを使用する際には、次の問題に注意してください。

- nsRole属性は、ロール・メカニズムによってのみ割当て可能です。この属性はいかなるディレクトリ・ユーザーによっても割当てや修正ができませんが、潜在的にあらゆるディレクトリ・ユーザーによって読取り可能です。アクセス制御を定義して、権限のないユーザーによってこの属性が読み取られることを防止します。

- nsRoleDN属性は、管理対象ロール・メンバーシップを定義します。ユーザーが自身をロールに対して追加または削除できるかどうかを、決定する必要があります。ユーザーが各自のロールを修正できないようにするために、この趣旨でACIを定義する必要があります。

- ユーザー・エントリにおける属性の存在またはその値に基づくフィルタを介して、フィルタ処理されたロールがメンバーシップを指定します。フィルタ処理されたロールでメンバーシップを誰が定義できるかを制御するために、これらの属性のユーザー権限を慎重に割り当てます。

12 Directory Serverのサービス・クラス

サービス・クラス(CoS)メカニズムにより属性をエントリ間で共有できるようになります。CoSの値は、リクエストが出されたときに動的に計算されます。CoSの詳細は次の項を参照してください。

- CoSの概要

- CoS定義エントリおよびCoSテンプレート・エントリ

- ポインタCoS、間接CoSおよびクラシックCoS

- サービス・クラスによる属性の管理

- CoSの優先度

- CoSの制限

12.1 CoSの概要

facsimileTelephoneNumber属性に対してすべてが同じ値を持つ数千のエントリが含まれているディレクトリを想定してみます。従来は、FAX番号を変更するには各エントリを個別に更新するので、管理者にとっては時間のかかる作業でした。CoSを使用すると、FAX番号は1つの場所に保管され、各エントリが返されるときにfacsimileTelephoneNumber属性が自動的にそれぞれのエントリに生成されます。

クライアント・アプリケーションに対して、CoS属性は他の属性と全く同じ方法で生成されます。ただし、ディレクトリの管理者にとって、今度は管理するFAX番号が1つだけです。また、ディレクトリに格納される値の数も少なくなるので、データベースが使用するディスク容量も少なくなります。さらに、CoSメカニズムではエントリが生成済の値を上書きしたり、同じ属性について複数の値を生成できます。

注意:

CoS仮想属性は索引付けされていないため、LDAP検索フィルタで参照するとパフォーマンスに影響する場合があります。

生成されるCoS属性は複数値であることが可能です。指定子は複数のテンプレート・エントリを指定するか、または、同じ属性に対して複数のCoS定義が存在できます。または、すべてのテンプレートからただ1つの値が作成されるように、テンプレートの優先度を指定できます。

ロールおよびクラッシックCoSを一緒に使用してロール・ベースの属性を指定できます。これらの属性は、関連付けられたCoSテンプレートを持つ特定のロールをエントリが所有しているため、そのエントリに表示されます。たとえば、ロール・ベースの属性を使用して、ロールごとにサーバーの検索制限を設定できます。

CoS機能は再帰的に使用でき、ユーザーはCoSによって生成された他の属性に依存するCoSを使用して、属性を生成できます。複雑なCoSスキームは情報へのクライアントのアクセスを簡素化し、反復する属性の管理を容易にしますが、これらによって管理の複雑さが増し、サーバーのパフォーマンスが低下します。極端に複雑なCoSスキームは避けてください。たとえば、多くの間接的なCoSスキームはクラシックCoSまたはポインタCoSとして再定義できます。

また、必要以上頻繁にCoS定義を変更することも、避ける必要があります。サーバーはCoS情報をキャッシュするため、CoS定義への変更はただちに有効にはなりません。キャッシングにより、生成済属性への読取りアクセスは速くなりますが、CoS情報への変更が発生すると、サーバーはキャッシュを再構成する必要があります。このタスクは多少時間がかかる場合があり、通常はほぼ数秒程度です。キャッシュの再構成時に、書込み操作で新しく変更された情報ではなく、依然として古いキャッシュ済情報にアクセスする場合がありますが、これは、あまり頻繁にCoS定義を変更した場合、旧データへアクセスする可能性が高くなることを意味します。

12.2 CoS定義エントリおよびCoSテンプレート・エントリ

CoSメカニズムは、CoS定義エントリおよびCoSテンプレート・エントリの、2つのタイプのエントリに依存しています。この項ではCoS定義エントリおよびCoSテンプレート・エントリについて説明します。

12.2.1 CoS定義エントリ

CoS定義エントリは、CoSのタイプと、生成されるCoS属性の名前を識別します。ロール定義エントリと同様、CoS定義エントリはLDAPsubentryオブジェクト・クラスから継承されます。同じCoS属性に対して複数の定義が存在する場合があり、その結果、複数値になることがあります。

CoS定義エントリはcosSuperDefinitionオブジェクト・クラスのインスタンスです。CoS定義エントリはCoSのタイプを指定するために、次のいずれかのオブジェクト・クラスからも継承されます。

- cosPointerDefinition

- cosIndirectDefinition

- cosClassicDefinition

CoS定義エントリには、ターゲット・エントリの仮想CoS属性、テンプレートDNおよび指定子属性を命名するための、それぞれのCoSタイプに固有の属性が含まれています。デフォルトで、CoSメカニズムはCoS属性と同じ名前を持つ既存の属性の値を上書きしません。ただし、CoS定義エントリの構文でこの動作を制御できます。

スキーマ・チェックが有効になっている場合、CoS属性はその属性を許可するすべてのターゲット・エントリに生成されます。スキーマ・チェックが無効になっている場合、CoS属性はすべてのターゲット・エントリに生成されまます。

定義エントリの場所はCoSの範囲を決定しますが、これは、CoS定義エントリの親の下にあるサブツリー全体です。定義エントリの親のブランチのすべてのエントリは、CoS定義に対してターゲット・エントリと呼ばれます。

次の図は、ou=peopleサブツリーのルートにあるCoS定義エントリを示しています。CoSの範囲はルートの下の2つのサブツリーのみです。CoSはこのルートを超えて拡張されませんし、DITの他のサブツリーにも拡張されません。

図12-1 CoSの範囲

「図12-1 CoSの範囲」の説明

12.2.2 CoSテンプレート・エントリ

CoSテンプレート・エントリにはCoS属性のために生成された値が含まれています。CoSの範囲内のすべてのエントリはここで定義された値を使用します。それぞれが異なる値を持つ複数のテンプレートである場合もありますが、その場合は、生成される属性が複数値になることがあります。CoSメカニズムは、定義エントリおよびターゲット・エントリの両方の内容に基づき、これらの値の1つを選択します。

CoSテンプレート・エントリは、cosTemplateオブジェクト・クラスのインスタンスです。CoSテンプレート・エントリにはCoSメカニズムにより生成された属性の値が1つまたは複数含まれています。特定のCoSのテンプレート・エントリは、そのCoS定義と同じレベルのディレクトリ・ツリーに格納されます。

管理を容易にするために、可能な場合は定義エントリとテンプレート・エントリを同じ場所に配置する必要があります。また、それらには、提供する機能を連想させるような名前を付ける必要があります。たとえば、「cn=classicCosGenEmployeeType,ou=People,dc=example,dc=com」のような定義エントリのDNは、「cn=ClassicCos1,ou=People,dc=example,dc=com」よりも説明的です。オブジェクト・クラスおよび各CoSタイプに関連付けられる属性の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のサービス・クラスに関する説明を参照してください。

12.3 ポインタCoS、間接CoSおよびクラシックCoS

次のタイプのCoSではテンプレートを選択する方法、ひいては生成される値が異なります。

- ポインタCoS

- 間接CoS

- クラシックCoS

12.3.1 ポインタCoS

ポインタCoSは最も単純なタイプのCoSです。ポインタCoS定義エントリは、cosTemplateオブジェクト・クラスの特定のテンプレート・エントリのDNを提供します。すべてのターゲット・エントリには、このテンプレートにより定義された同じCoS属性値があります。

次の図は、dc=example,dc=comの下に格納されたすべてのエントリで共通の郵便番号を定義するポインタCoSを示しています。CoS定義エントリ、CoSテンプレート・エントリおよびターゲット・エントリが示されています。

図12-2 ポインタCoSの定義およびテンプレートの例

「図12-2 ポインタCoSの定義およびテンプレートの例」の説明

テンプレート・エントリは、CoS定義エントリ内のDN (cn=exampleUS,cn=data)で識別されます。dc=example,dc=comでpostalCode属性が問合せられるたびに、Directory Serverはテンプレート・エントリcn=exampleUS,cn=dataで使用できる値を返します。したがって、郵便番号はエントリuid=wholiday,ou=people,dc=example,dc=comにより表示されますが、そこには格納されません。

各エントリの既存の実在属性ではなく、数十万または数百万のエントリに対して複数の共有属性がCoSにより生成されるシナリオでは、CoSによりストレージ領域の大幅な節約とパフォーマンスの大幅な向上が提供されます。

12.3.2 間接CoS

間接CoSではディレクトリ内の任意のエントリをテンプレートにすることができ、CoSの値を指定できます。間接CoS定義エントリは、間接指定子と呼ばれる属性を識別し、ターゲット・エントリのその値は、そのエントリに使用されるテンプレートを決定します。ターゲット・エントリの間接指定子属性にはDNが含まれている必要があります。間接CoSでは各ターゲット・エントリで異なるテンプレートを使用でき、そのため、CoS属性に対して異なる値を持つ場合があります。

たとえば、departmentNumber属性を生成する間接CoSは指定子として従業員のマネージャを使用する場合があります。ターゲット・エントリを検索するときに、CoSメカニズムはテンプレートとしてmanager属性のDN値を使用します。次に、同じ値をマネージャの部門番号として使用することにより、従業員のdepartmentNumber属性を生成します。

注意:

テンプレートはディレクトリ・ツリー内の任意の場所にある任意のエントリが可能なので、間接CoSに対するアクセス制御の実装はきわめて複雑になる場合があります。パフォーマンスが重要となるデプロイメントにおいては、そのリソース集中的な性質上、間接CoSの使い過ぎも避ける必要があります。

多くの場合、間接CoSにより可能になるのと同様の結果は、クラシックCoSによりターゲット・エントリの場所を制限するか、またはより柔軟性の低いポインタCoSメカニズムを使用することにより、達成できます。

次の図は、そのターゲット・エントリのmanager属性を使用してテンプレート・エントリを識別する間接CoSを示しています。このようにして、CoSメカニズムはすべての従業員のdepartmentNumber属性を、その従業員たちのマネージャと同じになるように生成でき、それにより、属性が常に最新であることを確保します。

図12-3 間接CoSの定義およびテンプレートの例

「図12-3 間接CoSの定義およびテンプレートの例」の説明

間接CoS定義エントリは指定子属性に名前を付けますが、この例ではmanager属性となっています。William HolidayのエントリはこのCoSのターゲット・エントリの1つで、そのmanager属性にはuid=cfuentes,ou=people,dc=example,dc=comというDNが含まれています。したがって、Carla Fuentesのエントリがテンプレートで、これによって、318842というdepartmentNumber属性が指定されます。

12.3.3 クラシックCoS

クラシックCoSはポインタおよび間接CoSの動作を結合します。クラシックCoS定義エントリはテンプレートのベースDNおよび指定子属性を識別します。その後、ターゲット・エントリの指定子属性の値を使用して、次のようにテンプレート・エントリのDNが構成されます。

cn=specifierValue, baseDN

CoSの値が含まれたテンプレートは、ターゲット・エントリの指定子属性のRDN (相対識別名)値およびテンプレートのベースDNの組合せにより決定されます。

クラシックCoSテンプレートは、任意の間接CoSテンプレートに関連するパフォーマンス問題を回避するための、cosTemplateオブジェクト・クラスのエントリです。

クラシックCoSのメカニズムは定義エントリで指定されたベースDNおよびターゲット・エントリの指定子属性からテンプレートのDNを決定します。指定子属性の値はテンプレートDNのcn値としてとられます。このため、クラシックCoSのテンプレートDNは次の構造を持つ必要があります。

cn=specifierValue,baseDN

次の図は郵便番号属性の値を生成するクラシックCoS定義を示します。

図12-4 クラシックCoS定義とテンプレートの例

「図12-4 クラシックCoS定義とテンプレートの例」の説明

この例で、cosSpecifier属性はemployeeType属性の名前を付けます。cosSpecifier属性およびテンプレートDNの組合せにより、テンプレート・エントリがcn=sales,cn=exampleUS,cn=dataであると識別されます。次に、テンプレート・エントリはターゲット・エントリにpostalCode属性の値を指定します。

12.4 サービス・クラスによる属性の管理

サービス・クラス(CoS)により属性をエントリ間で共有できます。ロール・メカニズム同様、CoSはエントリが検索されるときにエントリに仮想属性を生成します。CoSはメンバーシップを定義しませんが、一貫性および空き領域に対する考慮から、関連エントリによるデータ共有を許可します。CoSの値は、値がリクエストされたときに動的に計算されます。

次の各項では、パフォーマンスの低下を避けつつ、意図するとおりにCoS機能を使用できる方法を検証します。

- 多くのエントリが同じ値を共有している場合のCoSの使用

- エントリが自然な関係を持っている場合のCoSの使用

- 過剰なCoS定義の回避

注意:

CoSの生成は常にパフォーマンスに影響します。実際に必要な以上に多くの属性を検索するクライアント・アプリケーションは、この問題をさらに複合的にすることがあります。

クライアント・アプリケーションの記述方法に影響力がある場合、クライアント・アプリケーションは実際に必要な属性値のみを検索するほうがパフォーマンスが非常によいということを、開発者に再認識してもらいます。

12.4.1 多くのエントリが同じ値を共有している場合のCoSの使用

CoSは、サブツリー内の多数のエントリに同じ属性値を表示する必要がある場合に、比較的低いコストで大きな利点を提供します。

たとえば、ou=Peopleの下のすべてのユーザー・エントリにcompanyName属性が含まれている、MyCompany, Inc.のディレクトリを考えてみます。各請負業者はcompanyName属性に対して実際の値を持ちますが、正規社員はすべて、CoSにより生成される1つの値MyCompany, Inc.をcompanyName属性に対して持ちます。次の図は、この例でポインタCoSを使用した場合を示しています。CoSは、請負業者の従業員用に格納されている、CoSにより生成されたのではないcompanyNameの実際の値を上書きすることなく、すべての正社員のcompanyName値を生成します。会社名は、companyNameが許可された属性になっているエントリに対してのみ生成されます。

図12-5 ポインタCoSによるCompanyNameの生成

「図12-5 ポインタCoSによるCompanyNameの生成」の説明

多数のエントリが同じ値を共有する場合には、ポインタCoSが特に活躍します。正社員のcompanyNameの保守が容易になることで、属性値を生成するための追加の処理コストが相殺されます。深いディレクトリ情報ツリー(DIT)は、一般的な特徴を共有するエントリをまとめる傾向があります。深いDITでポインタCoSを使用すると、ツリーの適当な分岐にCoS定義を配置することによって、一般的な属性値を生成できます。

12.4.2 エントリが自然な関係を持っている場合のCoSの使用

CoSはまた、ディレクトリ・データが自然な関係を持っている場合も、データ管理の大きな利点を提供します。

すべての従業員にマネージャがいる企業ディレクトリを考えてみます。すべての従業員はメール・ストップとFAX番号を、最も近い管理アシスタントと共有しています。図12-6は、間接CoSを使用して、マネージャのエントリから部門番号を取得する様子を示しています。図12-7では、管理アシスタントのエントリからメール・ストップとFAX番号が取得されます。

図12-6 間接CoSを使用した、DepartmentNumberの生成

「図12-6 間接CoSを使用した、DepartmentNumberの生成」の説明

この実装では、マネージャのエントリにdepartmentNumberの実際の値が含まれ、その値は生成されたすべての値に優先します。Directory Serverは、CoSで生成された属性値からは属性値を生成しません。そのため、図12-6の例では、部門番号の属性値をマネージャのエントリ上でのみ管理する必要があります。同様に、図12-7に示されている例では、メール・ストップとFAX番号の属性を管理アシスタントのエントリ上でのみ管理する必要があります。

図12-7 間接CoSを使用したメール・ストップとFAX番号の生成

「図12-7 間接CoSを使用したメール・ストップとFAX番号の生成」の説明

単一のCoS定義エントリを使用して、このような関係をディレクトリ内の様々なエントリに利用できます。

別の自然な関係に、サービス・レベルがあります。顧客にスタンダード、シルバー、ゴールドおよびプラチナのパッケージを提供しているインターネット・サービス・プロバイダを考えてみます。顧客のディスク割当て、メールボックスの数、前払いのサポート・レベルに対する権限などは、購入したサービス・レベルによって異なります。次の図は、クラシックCoSスキーマによってこの機能が可能になる様子を示しています。

図12-8 クラシックCoSを使用したサービス・レベル・データの生成

「図12-8 クラシックCoSを使用したサービス・レベル・データの生成」の説明

1つのCoS定義が複数のCoSテンプレート・エントリに関連付けられる場合があります。

12.4.3 過剰なCoS定義の回避

Directory Serverは、1つのクラシックCoS定義エントリが複数のCoS定義テンプレート・エントリに関連付けられている場合はCoSを最適化します。Directory Serverは、多数のCoS定義が適用される可能性がある場合はCoSを最適化しません。かわりに、Directory Serverは各CoS定義をチェックして、この定義が適用されるかどうかを判定します。この動作によって、数千のCoS定義が存在する場合はパフォーマンスの問題が発生します。

この状況は、図12-8で示した例に変更がある場合に発生する可能性があります。各顧客のサービスレベルの委任管理を顧客に提供している、インターネット・サービス・プロバイダを考えてみます。各顧客から、スタンダード、シルバー、ゴールドおよびプラチナのサービス・レベルの定義エントリが提供されます。顧客数が1000に増えると、1000個のクラシックCoS定義が作成されることになります。どの定義が適用されるを判定するために1000個のCoS定義のリストがチェックされるため、Directory Serverのパフォーマンスが影響を受ける可能性があります。この種の状況でCoSを使用する必要がある場合は、間接CoSを検討してください。間接CoSでは、顧客のエントリによって、その顧客のサービスクラス割当てを定義するエントリが特定されます。

1つまたは2つのターゲットエントリごとに別のCoSスキーマを選択することの限界に近づき始めたら、実際の値を更新することをお薦めします。CoSで生成されていない実際の値が読み取られるため、より高いパフォーマンスが実現します。

12.5 CoSの優先度

属性値を提供するために、それぞれが競合するCoSスキーマを作成することが可能です。たとえば、CoS定義エントリに複数値のcosSpecifierがあるとします。そのような場合、各テンプレート・エントリに対してテンプレートの優先度を指定し、属性値を提供するテンプレートを決定することができます。テンプレートの優先度はcosPriority属性を使用して設定します。この属性は、特定のテンプレートのグローバル優先度を数値で表します。優先度ゼロは、考えられる最高の優先度です。

cosPriority属性が含まれていないテンプレートは、考えられる最低の優先度であるとみなされます。属性値を供給するテンプレートとして2つ以上のテンプレートが検討され、それらが同じ優先度を持っているか、またはいずれも優先度を持たないテンプレートである場合、値は任意に選択されます。Directory Serverは、テンプレートを強制的に任意で選択する場合に、メッセージを記録するように構成できます。

12.6 CoSの制限

CoSの機能は複雑なメカニズムであり、パフォーマンスおよびセキュリティ上の理由から次の制限を受けます。

- サブツリーの制限
CoS定義はcn=configまたはcn=schemaサブツリーには作成できません。

- 索引付けされていない検索
属性がCoSにより生成された属性であると宣言されている場合にサフィックスで検索を実行すると、索引付けされていない検索になります。これはパフォーマンスに大きな影響を及ぼす場合があります。同じ属性がCoS属性では「ない」と宣言されているサフィックスでは、検索が索引付けされます。

- 属性タイプの制限
次の属性は、同じ名前の実際の属性とは異なる振舞いを持つため、CoSにより生成されることはありません。

- userPassword - CoSにより生成されるパスワード値は、Directory Serverへのバインドに使用できません。

- aci - Directory Serverは、CoSにより定義される仮想ACIの内容に基づいてアクセス制御を適用しません。

- objectclass - Directory Serverは、CoSにより定義された仮想オブジェクト・クラスの値に対してスキーマ・チェックを実行しません。

- nsRoleDN - CoSで生成されたnsRoleDN値は、ロールを生成するためにサーバーで使用されません。

- テンプレートはローカル
テンプレート・エントリのDNは、それがCoS定義のものでも、またはターゲット・エントリの指定子のものでも、ディレクトリのローカル・エントリを参照する必要があります。テンプレートおよびそれに含まれる値は、ディレクトリ・チェーニングまたはリフェラルによって取得することはできません。

- CoS仮想値は実際の値と結合できません。
CoS属性の値が、エントリの実際の値とテンプレートの仮想値を組み合せたものになることはありません。CoSが実際の属性値を上書きする場合は、すべての実際の値をテンプレートの値に置き換えます。ただし、CoSのメカニズムによって、複数のCoS定義エントリの仮想値を結合することができます。詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のCoSの制限に関する説明を参照してください。

- フィルタされたロールはCoSで生成した属性を使用できない
フィルタされたロールのフィルタ文字列は、CoS仮想値の値に基づくことはできません。ただし、CoS定義の指定子属性が、ロール定義により生成されたnsRole属性を参照する場合があります。詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のロールベースの属性の作成に関する説明を参照してください。

- アクセス制御命令(ACI)
サーバーは通常の、保管された属性へのアクセスを制御するのとまったく同じ方法で、CoSにより生成された属性へのアクセスを制御します。ただし、CoSにより生成された属性の値に応じたアクセス制御ルールは、「CoSの制限」で説明した条件に従います。

- CoSキャッシュの遅延
CoSキャッシュは、パフォーマンスを改善するために、すべてのCoSデータをメモリーに保持する内部構造です。このキャッシュは、CoS定義およびテンプレート・エントリを更新中の場合でも、仮想属性の計算に使用されるCoSデータを取得するために最適化されます。したがって、定義エントリおよびテンプレート・エントリが追加または変更された場合は、それらが考慮されるまでに若干の遅延が生じる場合があります。この遅延はCoS定義の数と複雑さ、および現在のサーバーの負荷によって異なりますが、通常は2、3秒です。極端に複雑なCoS構成を設計する前に、この遅延を検討してください。

13 Directory ServerのDSMLv2

Directory ServerでのDSMLv2の詳細は、次の各項を参照してください。

- DSMLの概要

- DSMLv2標準の実装

- DSMLのセキュリティ

- DSMLアイデンティティ・マッピング

- HTTPヘッダーの内容

- DSMLv2使用によるディレクトリへのアクセス

13.1 DSMLの概要

Directory Services Markup Languageバージョン2 (DSMLv2)は、eXtensible Markup Language (XML)ドキュメントでのディレクトリ操作を記述するマークアップ言語です。DSMLv2標準の詳細は、Directory Services Markup Language (DSML) v2.0 [OASIS 200201] (http://www.oasis-open.org/specs)を参照してください。

DSMLv2の完全な仕様およびサポート・ドキュメントは次の場所にあります。

- http://www.oasis-open.org/committees/dsml/docs/DSMLv2.xsd

- http://www.oasis-open.org/committees/dsml/docs/DSMLv2.doc

Directory ServerではDSMLv2 SOAP over HTTPバインディングがサポートされています。DSMLリクエストおよびレスポンスはSOAP v1.1の本文に埋め込まれ、HTTP/1.1ペイロードで転送されます。

Directory Serverリソース・キットにはDSMLv2を使用してディレクトリを検索および変更するツールが含まれています。「dsmlsearch」および「dsmlmodify」を参照してください。

DSMLを使用することにより、LDAPクライアント以外のクライアントがディレクトリ操作を実行できます。次の図は、DSMLを有効にしたディレクトリ・サーバーで非LDAPクライアントがデータを変更するリクエストを出すデプロイメント例を示しています。

図13-1 DSML有効化ディレクトリのデプロイメント例

「図13-1 DSML有効化ディレクトリのデプロイメント例」の説明

このデプロイメント例で、非LDAPクライアント・アプリケーションから到着したDSML形式の更新リクエストは、HTTPポート80を介してファイアウォールを通過します。Webプロキシ・サーバーはポート443経由のセキュアなHTTPの使用を強制し、リクエストは2番目のファイアウォールを通過してイントラネット・ドメインに入ります。リクエストはDSMLに対応していないコンシューマCおよびDにレプリケートされる前に、2つのマスター・レプリカによってMaster AおよびMaster Bで処理されます。

13.2 DSMLv2標準の実装

Directory ServerでのDSMLv2仕様の実装には次の制限があります。

バインディング

DSMLv2は2つの標準バインディング、SOAPリクエスト/レスポンス・バインディング、およびLDIFのDSMLv2版として機能するファイル・バインディングを定義します。Directory ServerではSOAPリクエスト/レスポンス・バインディングがサポートされています。

DNの変更

Directory ServerではDSML modDNRequest操作およびmodDNResponse操作がサポートされています。

廃棄リクエスト

abandonRequest操作は、HTTPでは役立たないため、Directory Serverではサポートされていません。

検索操作

一部のDSMLクライアントは、所在の一致が意図されている場合に、値*を使用した等価一致を誤って送信します。Directory Serverは、こうした誤った書式の問合せからゼロの結果を返します。アクセス・ログで文字=\2aを検索することにより、こうした誤ったクライアントを検出できます。

13.3 DSMLのセキュリティ

DSMLフロント・エンドは制限付きのHTTPサーバーを構築します。サーバーはDSMLポスト操作のみを受け入れ、DSMLv2 SOAPバインディング仕様に準拠しないリクエストを拒否します。

DSMLのセキュリティは、次のサーバー・プロパティ、dsml-client-auth-mode、dsml-port、dsml-secure-portおよびdsml-relative-root-urlにより構成されます。これらのプロパティの詳細は、「server」を参照してください。

追加セキュリティについては、次の事項を検討してください。

- ファイアウォールを実装することにより、DSML対応のディレクトリ・サーバーを保護します。

- クライアントでHTTP over SSLを設定しない場合は、非武装地帯を実装します。

13.4 DSMLアイデンティティ・マッピング

アイデンティティ・マッピングは次のメカニズムで必要です: DSML over HTTP、DIGEST-MD5およびGSSAPI SASLアイデンティティ・マッピングは、クライアントにより指定されるプロトコル固有の資格証明に基づき、バインドDNを判別するために使用されます。

アイデンティティ・マッピングではcn=identity mapping, cn=config構成ブランチのエントリを使用します。このブランチには、アイデンティティ・マッピングを実行するプロトコル用に次のコンテナが含まれています。

cn=HTTP-BASIC, cn=identity mapping, cn=config

DSML-over-HTTP接続のためのマッピングが含まれています。

cn=DIGEST-MD5, cn=identity mapping, cn=config

DIGEST-MD5 SASLメカニズムを使用したクライアント認証用のマッピングが含まれています。

cn=GSSAPI, cn=identity mapping, cn=config

GSSAPI SASLメカニズムを使用したクライアント認証用のマッピングが含まれるように作成する必要があります。

マッピング・エントリは、検索操作で使用するための、プロトコルに関する資格証明を抽出する方法を定義します。検索でユーザー・エントリが1つ返された場合、マッピングは成功しており、接続ではすべての操作のバインドDNとしてこのマッピング・エントリが使用されます。検索でゼロが返された場合、または複数のエントリが返された場合は、マッピングは失敗し、接続はマッピング・エントリをバインドDNとして使用しません。

アイデンティティ・マッピングを実行するプロトコルにはデフォルト・マッピングが含まれている必要があります。さらに、プロトコルには任意の数のカスタム・マッピングが含まれている場合があります。デフォルト・マッピングにはcn=defaultというRDNが含まれ、カスタム・マッピングにはネーミング属性としてcnを使用する、その他のRDNが含まれる場合があります。最初に、いずれかのカスタム・マッピングが成功するまで、すべてのカスタム・マッピングが順不同で評価されます。すべてのカスタム・マッピングが失敗した場合、デフォルト・マッピングが適用されます。デフォルト・マッピングが失敗すると、そのクライアントの認証は失敗します。

マッピング・エントリにはオブジェクト・クラスtop、containerおよびdsIdentityMappingが含まれている必要があります。

エントリには次の属性を含めることができます。

dsMappedDN: DN

ディレクトリ内のDNを定義するリテラル文字列。マッピングの実行時にこのDNが存在する場合、このDNはバインディングに使用されます。このDNが存在しない場合は、検索を実行するために次の属性を定義することもできます。

dsSearchBaseDN: DN

検索のベースDN。これを省略した場合、マッピングではディレクトリ・ツリー全体で、すべてのルートサフィックスが検索されます(cn=config、cn=monitorおよびcn=schema以外のすべてのネーミング・コンテキストを含む)。

dsSearchScope: base|one|sub

検索の適用範囲。検索ベース、ベースの1つ下の子レベル、またはベースの下にあるサブツリー全体を指定できます。この属性を省略した場合、マッピング検索のデフォルトの範囲はサブツリー全体です。

dsSearchFilter: filterString

マッピング検索を実行するためのフィルタ文字列。LDAP検索フィルタはRFC 4515 (http://www.ietf.org/rfc/rfc4515.txt)に定義されています。

さらに、マッピング・エントリには、次の属性を使用できるdsPatternMatchingオブジェクト・クラスを含めることもできます。

dsMatching-pattern: patternString

パターン一致が実行される文字列。

dsMatching-regexp: regularExpression

パターン文字列に適用する正規表現。

dsSearchScopeを除く、上記の属性値にはすべて、${keyword}という形式のプレースホルダを含めることができます(keywordはプロトコル固有の資格証明の要素名)。マッピング時に、プレースホルダはクライアントにより指定される、要素の実際の値で置き換えられます。

プレースホルダの置換がすべて終了すると、パターン一致が実行されます。一致するパターンは、次のように正規表現と比較されます。

- 正規表現がパターン文字列と一致しない場合、マッピングは失敗します。

- 正規表現がパターン文字列と一致した場合、正規表現の括弧内の一致した値は、番号付きのプレースホルダとして他の属性値に使用できます。

たとえば、次のマッピングをSASL用に定義できます。

dsMatching-pattern: ${Principal}
dsMatching-regexp: (.*)@(.*)\\.(.*)
dsMappedDN: uid=$1,ou=people,dc=$2,dc=$3

クライアントがbjensen@example.comというプリンシパルを使用して認証を行う場合、このマッピングはバインドDN uid=bjensen,ou=people,dc=example,dc=comを定義します。このDNがディレクトリに存在する場合、マッピングは成功し、クライアントが認証されます。そしてこの接続で実行されるすべての操作には、このバインドDNが使用されます。

dsMatching-patternは、POSIX regexec(3C)およびregcomp(3C)関数コールを使用して、dsMatching-regexpと比較されます。Directory Serverでは拡張正規表現が使用され、すべての比較では大文字小文字が区別されません。詳細は、これらの関数のmanページを参照してください。

プレースホルダが含まれる可能性がある属性値では、プレースホルダが使用されない場合でも、プレースホルダ部分以外に$、{および}の文字がある場合、それらの文字をエンコードする必要があります。これらの文字は次の値にエンコードする必要があります。$は\\24に、{は\\7Bに、そして}は\\7Dにエンコードします。

プレースホルダと置換を使用することにより、ユーザーはプロコル固有の資格証明からユーザー名やその他の値を抽出するマッピングを作成できます。資格証明を使用してマップ先DNを定義したり、ディレクトリ内の任意の場所にある対応するDNの検索を実行できます。

注意:

作成するマッピングの定義が不十分だとセキュリティ・ホールが生じます。たとえば、パターン一致を実行しないでハード・コーディングしたDNへのマッピングは常に成功しますが、その場合、ディレクトリ・ユーザーではない可能性があるクライアントを認証してしまいます。様々な形式のクライアント資格証明を処理するには、1つの非常に汎用的で許容性の高いマッピングを作成するよりも、複数のマッピングを定義する方が安全です。クライアント接続は必ず、クライアント資格証明に従って特定のユーザーにマップするようにしてください。

13.5 HTTPヘッダーの内容

Directory ServerではHTTPポスト操作のみがサポートされています。次の例は、HTTPを介してDSMLリクエストをサーバーに送信するために必要な最小フィールドを示しています。

POST /dsml HTTP/1.1
content-length: 450
HOST: hostname
SOAPAction: ""
Content-Type: text/xml
Connection: close

Connectionフィールドはオプションです。HTTP 1.0では、このフィールドのデフォルト値は「close」です。ただし、HTTP 1.1では、デフォルト値は「keep-alive」です。したがって、HTTP 1.1を使用している場合は、ダイアログを速く進めるために最後のリクエストでこのフィールドに「close」の値を入れることを推奨します。

追加のフィールドがHTTPヘッダーに含まれる場合があります。これらがDirectory Serverでサポートされている場合、その値はデフォルトに優先します。それらのフィールドがサポートされていない場合、リクエストがサーバーにより拒否されることはありませんが、フィールドは無視されます。

13.6 DSMLv2使用によるディレクトリへのアクセス

次の例は、DSMLリクエストを使用してディレクトリにアクセスし、検索する方法を示しています。

- 空の匿名DSML Pingリクエスト

- 特定のユーザーとしてバインドするDSMLリクエストの発行

- DSML検索リクエスト

これらの例のcontent-length:ヘッダーにはDSMLv2リクエストの正確な長さが含まれています。これらの例が正常に機能するためには、このコンテンツ長を守るエディタを使用するか、または必要に応じてコンテンツ長を変更する必要があります。

13.6.1 空の匿名DSML Pingリクエスト

DSMLフロント・エンドはデフォルトで無効になっています。これを有効化する方法については、『Oracle Directory Server Enterprise Edition管理者ガイド』のDSMLの構成に関する説明を参照してください。DSMLフロント・エンドが有効かどうかをチェックするには、例13-1に示すように、空のDSMLバッチ・リクエストを送信します。

例13-1 空の匿名DSMLリクエスト

POST /dsml HTTP/1.1
content-length: 451
HOST: hostname
SOAPAction: ""
Content-Type: text/xml
Connection: close
<?xml version='1.0' encoding='UTF-8'?\>
<soap-env:Envelope
xmlns:xsd='http://www.w3.org/2001/XMLSchema'
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
xmlns:soap-env='http://schemas.xmlsoap.org/soap/envelope/'\>
<soap-env:Body\>
<batchRequest
xmlns='urn:oasis:names:tc:DSML:2:0:core'           requestID='Ping!'\>
<!-- empty batch request --\>
</batchRequest\>
</soap-env:Body\>
</soap-env:Envelope\>

このDSMLリクエストの最初のセクションにはHTTPメソッド行POST /dsml HTTP/1.1が含まれ、これに複数のHTTPヘッダーが続きます。HTTPメソッド行は、HTTPメソッド・リクエストおよびDSMLフロント・エンドが使用するURLを指定します。POSTは、DSMLフロント・エンドが受け入れる唯一のHTTPメソッド・リクエストです。/dsml URLはDirectory ServerのデフォルトのURLですが、その他の任意の有効なURLを設定できます。これ以降のHTTPヘッダーで、DSMLリクエストの残りの詳細を指定します。

- content-length: 451は、SOAP/DSMLリクエストの正確な長さを指定します。

- HOST: hostnameは、接続するホストDirectory Serverの名前を指定します。

- SOAPAction:は、必須であり、HTTP/SOAPスタックでDSMLリクエストを実行することをディレクトリに通知します。ただし、これは空のままにすることができます。

- Content-Type: text/xmlは、コンテンツがXMLであることを定義する、text/xmlの値を持つ必要があります。

- Connection: closeは、リクエストが満たされた場合に接続が閉じることを指定します。HTTP/1.1のデフォルトの動作では、接続は開いたまま維持されます。
リクエストの残りの部分はSOAP/DSMLセクションです。DSMLリクエストはXMLプロローグ・ヘッダーで始まります。

<?xml version='1.0' encoding='UTF-8'?\>

これで、リクエストはUTF-8文字セットでエンコードされる必要があることを指定します。このヘッダーの後にSOAPエンベロープおよび、必須のXMLスキーマ、XMLスキーマ・インスタンス、そしてSOAPネームスペースが含まれる本文要素が続きます。

DSMLバッチ・リクエスト要素はDSMLバッチ・リクエストの開始を示し、その直後に必須のDSMLv2ネームスペースが続きます。

xmlns='urn:oasis:names:tc:DSML:2:0:core'.

オプションで、次のリクエストIDにより、このリクエストを識別します。

requestID='Ping!'

空のバッチ・リクエスト

<!-- empty batch request --\>

は、このようにXMLでコメントし、SOAP/DSMLバッチ・リクエストはバッチ・リクエスト終了、SOAP本文終了およびSOAPエンベロープ要素終了により閉じられます。

DSMLフロント・エンドが有効な場合は、例13-2に示すように空のDSMLレスポンスが返されます。

例13-2 空の匿名DSMLレスポンス

HTTP/1.1 200 OK
Cache-control: no-cache
Connection: close
Date: Mon, 11 Dec 2006 13:56:49 GMT
Accept-Ranges: none
Server: Directory Server Enterprise Edition/11g Release 1 (11.1.1.6.0)
Content-Type: text/xml; charset="utf-8"
Content-Length: 500
<?xml version='1.0' encoding='UTF-8' ?\>
<soap-env:Envelope
xmlns:xsd='http://www.w3.org/2001/XMLSchema'
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
xmlns:soap-env='http://schemas.xmlsoap.org/soap/envelope/'
\>
<soap-env:Body\>
<batchResponse
xmlns:xsd='http://www.w3.org/2001/XMLSchema'
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
xmlns='urn:oasis:names:tc:DSML:2:0:core'
requestID='Ping!'
\>
</batchResponse\>
</soap-env:Body\>
</soap-env:Envelope\>

何も返されない場合、フロント・エンドは無効であると結論付けることができます。

ディレクトリに同時に接続できるクライアント数とDSMLリクエストのサイズには上限があります。クライアント数の制限は、dsml-max-parser-countおよびdsml-min-parser-countサーバー・プロパティで指定し、リクエストのサイズの制限はdsml-request-max-sizeサーバー・プロパティで指定します。「server」を参照してください。

13.6.2 特定のユーザーとしてバインドするDSMLリクエストの発行

DSMLリクエストを発行するために、指定されたユーザーとして、または匿名でディレクトリにバインドできます。指定されたユーザーとしてバインドするには、例13-3に示すように、DNにマップされるUIDとパスワードを含むHTTP認証ヘッダーがリクエストに含まれている必要があります。

例13-3 DSML拡張操作: 特定ユーザーとしてのバインド

POST /dsml HTTP/1.1
content-length: 578
content-Type: text/xml; charset="utf-8"
HOST: hostname
Authorization: Basic ZWFzdGVyOmVnZw==
SOAPAction: ""
Connection: close
<?xml version='1.0' encoding='UTF-8'?\>
<soap-env:Envelope
xmlns:xsd='http://www.w3.org/2001/XMLSchema'
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
xmlns:soap-env='http://schemas.xmlsoap.org/soap/envelope/'\>
<soap-env:Body\>
<batchRequest
xmlns='urn:oasis:names:tc:DSML:2:0:core'\>
<extendedRequest\>
<requestName\>1.3.6.1.4.1.4203.1.11.3</requestName\>
</extendedRequest\>
</batchRequest\>
</soap-env:Body\>
</soap-env:Envelope\>

この例で、HTTP認証ヘッダーはユーザーID easterおよびパスワードegg (クリア・テキストではeaster:eggと表示されます)を送信していますが、これはbase64でエンコードされてAuthorization: Basic ZWFzdGVyOmVnZw==となっています。

LDAP拡張操作を指定するために、<extendedRequest\>タグが使用されています。拡張操作のOIDを指定するために、<requestName\>タグが使用されています。この例では、OID 1.3.6.1.4.1.4203.1.11.3によりwhoami拡張操作が識別されます。

DSML拡張操作に対するレスポンスは、バインド・リクエストを発行したユーザーのDNを示します。例13-4では、DNが含まれたwhoamiレスポンスがレスポンス行に表示されています。

<response\>dn:uid=easter,ou=people,dc=example,dc=com</response\>

例13-4 DSML拡張操作に対するレスポンス

HTTP/1.1 200 OK
Cache-control: no-cache
Connection: close
Date: Fri, 15 Dec 2006 09:15:09 GMT
Accept-Ranges: none
Server: Directory Server Enterprise Edition/11g Release 1 (11.1.1.6.0)
Content-Type: text/xml; charset="utf-8"
Content-Length: 697

<?xml version='1.0' encoding='UTF-8' ?\>
<soap-env:Envelope
xmlns:xsd='http://www.w3.org/2001/XMLSchema'
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
xmlns:soap-env='http://schemas.xmlsoap.org/soap/envelope/'
\>
<soap-env:Body\>
<batchResponse
xmlns:xsd='http://www.w3.org/2001/XMLSchema'
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
xmlns='urn:oasis:names:tc:DSML:2:0:core'
\>
<extendedResponse\>
<resultCode code='0' descr='success'/\>
<responseName\>1.3.6.1.4.1.4203.1.11.3</responseName\>
<response\>dn:uid=easter,ou=people,dc=example,dc=com</response\>
</extendedResponse\>
</batchResponse\>
</soap-env:Body\>
</soap-env:Envelope\>

匿名アクセスではHTTP認証ヘッダーは不要です。ただし、匿名アクセスにはたいてい厳しいアクセス制御があり、また、場合によりデータへのアクセスも制限されます。同様に、LDAPプロキシによるLDAP操作を実行するためにDSMLリクエストを発行することができます。

DSMLリクエストはバッチ・ベースで管理されるため、LDAPプロキシによるリクエストを発行する場合は、必要なDSMLプロキシ認可リクエストを、所定のリクエスト・バッチの最初に指定する必要があります。

13.6.3 DSML検索リクエスト

例13-5は、ルートDSEエントリに対するDSMLベース・オブジェクト検索リクエストを示しています。

例13-5 DSML検索リクエスト

POST /dsml HTTP/1.1
HOST: hostname
Content-Length: 1081
Content-Type: text/xml
SOAPAction: ""
Connection: close
<?xml version='1.0' encoding='UTF-8'?\>
<soap-env:Envelope
xmlns:xsd='http://www.w3.org/2001/XMLSchema'
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
xmlns:soap-env='http://schemas.xmlsoap.org/soap/envelope/'
\>
<soap-env:Body\>
<batchRequest
xmlns='urn:oasis:names:tc:DSML:2:0:core'
requestID='Batch of search requests'
\>
<searchRequest
dn=""
requestID="search on Root DSE"
scope="baseObject"
derefAliases="neverDerefAliases"
typesOnly="false"
\>
<filter\>
<present name="objectClass"/\>
</filter\>
<attributes\>
<attribute name="namingContexts"/\>
<attribute name="supportedLDAPversion"/\>
<attribute name="vendorName"/\>
<attribute name="vendorVersion"/\>
<attribute name="supportedSASLMechanisms"/\>
</attributes\>
</searchRequest\>
</batchRequest\>
</soap-env:Body\>
</soap-env:Envelope\>

- dn=""requestID="search on Root DSE"は、検索操作がルートDSEエントリ(空のDN)下のデータを要求し、オプションのリクエストID属性で識別されることを指定しています。

- scope="baseObject"は、検索がベース・オブジェクト検索であることを指定しています。

- derefAliases="neverDerefAliases"は、検索のベース・オブジェクトの検索中または探索中に、別名が間接参照されないことを指定しています。これはDirectory Serverでサポートされている唯一のderefAliases値です。

- typesOnly="false"は、属性名とその値の両方が返されることを指定します。typesOnly="true"は、属性名だけが返されることを指定します。この属性のデフォルト値はfalseです。
エントリがフィルタに一致するには、objectclassフィルタの存在を次のように使用する必要があります。

<filter\>
<present name="objectClass"/\>
</filter\>

これはLDAPのフィルタ文字列(objectclass=*)と同じ働きをします。フィルタの後に、使用する属性のリストが続きます。

<attributes\>
<attribute name="namingContexts"/\>
<attribute name="supportedLDAPversion"/\>
<attribute name="vendorName"/\>
<attribute name="vendorVersion"/\>
<attribute name="supportedSASLMechanisms"/\>
</attributes\>

例13-6 DSML検索レスポンス

HTTP/1.1 200 OK
Cache-control: no-cache
Connection: close
Date: Fri, 15 Dec 2006 09:21:43 GMT
Accept-Ranges: none
Server: Directory Server Enterprise Edition/11g Release 1 (11.1.1.6.0)
Content-Type: text/xml; charset="utf-8"
Content-Length: 1287

<?xml version='1.0' encoding='UTF-8' ?\>
<soap-env:Envelope
xmlns:xsd='http://www.w3.org/2001/XMLSchema'
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
xmlns:soap-env='http://schemas.xmlsoap.org/soap/envelope/'
\>
<soap-env:Body\>
<batchResponse
xmlns:xsd='http://www.w3.org/2001/XMLSchema'
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
xmlns='urn:oasis:names:tc:DSML:2:0:core'
requestID='Batch of search requests'
\>
<searchResponse requestID='search on Root DSE'\>
<searchResultEntry\>
<attr name='namingContexts'\>
<value\>dc=example,dc=com</value\>
</attr\>
<attr name='supportedLDAPVersion'\>
<value\>2</value\>
<value\>3</value\>
</attr\>
<attr name='vendorName'\>
<value\>Sun Microsystems, Inc.</value\>
</attr\>
<attr name='vendorVersion'\>
<value\>Directory Server Enterprise Edition/11g Release 1 (11.1.1.6.0)</value\>
</attr\>
<attr name='supportedSASLMechanisms'\>
<value\>EXTERNAL</value\>
<value\>GSSAPI</value\>
<value\>DIGEST-MD5</value\>
</attr\>
</searchResultEntry\>
<searchResultDone\>
<resultCode code='0' descr='success'/\>
</searchResultDone\>
</searchResponse\>
</batchResponse\>
</soap-env:Body\>
</soap-env:Envelope\>

14 Directory Serverの国際化のサポート

Directory Serverは、エントリおよびその関連する属性の格納、管理および検索のために、様々な言語でサポートを提供しています。

国際化されたディレクトリ内のデータは、UTF-8形式で格納されます。したがって、Directory Serverはデフォルトですべての国際文字をサポートしています。国際化されたディレクトリは、検索操作における言語プリファレンスに基づき、一致ルールおよび照合順序を指定するために使用可能です。国際化されたディレクトリの詳細は、次の項を参照してください。

- ロケールについて

- サポートされるロケールの識別

- サポートされる言語のサブタイプ

14.1 ロケールについて

ロケールによって、固有の地域、文化または慣習においてユーザーが希望するデータの表示方法について、言語固有の情報が識別されます。ロケールによって、異なる言語においてデータがどのように解釈、ソートおよび照合されるかが定義されます。Directory Serverは、ロケールの使用によって複数言語をサポートしています。

ロケールによって、次の情報が指定されます。

コード・ページ

コード・ページは、キーボードのキーを画面上に表示される文字フォントと関連させるためのオペレーティング・システムによって使用される、内部表です。ロケールは、エンド・ユーザーとのやり取りに関して、アプリケーションがどのコード・ページを選択するべきかを示すことができます。

照合順序

照合順序によって、指定された言語の文字がソートされる方法についての情報が提供されます。照合順序によって、次の情報が指定されます。

- アルファベットの文字の順序

- アクセントのある文字とアクセントのない文字の比較方法

- 文字列を比較する際に無視できる文字の有無

- 言語を読む方向(左から右、右から左、または上から下)

文字タイプ

文字タイプによって、アルファベットと、数値やその他の文字が識別されます。これによって、大文字から小文字へのマッピングが定義されます。たとえばパイプ文字(|)は、一部の言語では句読点とみなされますが、別の言語ではアルファベットとしてみなされます。

通貨書式

通貨書式によって、次の情報、すなわち、地域で使用される通貨記号、この記号が値の前後のどちらにくるか、および通貨単位の表示方法が指定されます。

時刻と日付の書式

時刻および日付書式によって、地域の時刻および日付の表示が指定されます。時刻書式によって、当該ロケールで12時間制または24時間制のどちらを使用するかを示します。日付書式には、短い日付順序と長い日付書式の両方が含まれ、各言語における月と曜日の名前が含まれます。

14.2 サポートされるロケールの識別

検索操作など、ロケールの指定が要求されるディレクトリ操作を実行する際に、言語タグまたは照合順序のオブジェクト識別子(OID)を使用できます。

言語タグはISO標準639で定義されているように、言語を識別する、小文字2文字の言語コードで始まる文字列です。言語における地域差を区別する必要がある場合、言語タグに国コードを含めることもでき、これはISO標準3166で定義されているように、2文字の文字列です。言語コードと国コードは、ハイフンで区切られます。たとえば、米国英語のロケールを識別するために使用される言語タグは、en-USです。

OIDは、属性またはオブジェクト・クラスなどのオブジェクトを一意に識別する10進数です。

ディレクトリで国際的な検索を実行する際に、使用する照合順序を識別するために、言語タグまたはOIDのいずれかを使用します。国際索引を設定する際には、OIDを使用します。

次の表では、Directory Serverによってサポートされているロケールがリスト表示されています。これは、関連する言語タグとOIDを識別します。

表14-1 サポートされるロケール

ロケール

タグ

照合順序OID

下位互換性OID

アフリカーンス語

af

1.3.6.1.4.1.42.2.27.9.4.1.1

アムハラ語(エチオピア)

am

1.3.6.1.4.1.42.2.27.9.4.2.1

アラビア語

ar

1.3.6.1.4.1.42.2.27.9.4.3.1

2.16.840.1.113730.3.3.2.1.1

アラビア語(アラブ首長国連邦)

ar-AE

1.3.6.1.4.1.42.2.27.9.4.4.1

アラビア語(バーレーン)

ar-BH

1.3.6.1.4.1.42.2.27.9.4.5.1

アラビア語(アルジェリア)

ar-DZ

1.3.6.1.4.1.42.2.27.9.4.6.1

アラビア語(エジプト)

ar-EG

1.3.6.1.4.1.42.2.27.9.4.7.1

アラビア語(インド)

ar-IN

1.3.6.1.4.1.42.2.27.9.4.8.1

アラビア語(イラク)

ar-IQ

1.3.6.1.4.1.42.2.27.9.4.9.1

アラビア語(ヨルダン)

ar-JO

1.3.6.1.4.1.42.2.27.9.4.10.1

アラビア語(クウェート)

ar-KW

1.3.6.1.4.1.42.2.27.9.4.11.1

アラビア語(レバノン)

ar-LB

1.3.6.1.4.1.42.2.27.9.4.12.1

アラビア語(リビア)

ar-LY

1.3.6.1.4.1.42.2.27.9.4.13.1

アラビア語(モロッコ)

ar-MA

1.3.6.1.4.1.42.2.27.9.4.14.1

アラビア語(オマーン)

ar-OM

1.3.6.1.4.1.42.2.27.9.4.15.1

アラビア語(カタール)

ar-QA

1.3.6.1.4.1.42.2.27.9.4.16.1

アラビア語(サウジアラビア)

ar-SA

1.3.6.1.4.1.42.2.27.9.4.17.1

アラビア語(スーダン)

ar-SD

1.3.6.1.4.1.42.2.27.9.4.18.1

アラビア語(シリア)

ar-SY

1.3.6.1.4.1.42.2.27.9.4.19.1

アラビア語(チュニジア)

ar-TN

1.3.6.1.4.1.42.2.27.9.4.20.1

アラビア語(イエメン)

ar-YE

1.3.6.1.4.1.42.2.27.9.4.21.1

ベラルーシ語

be

1.3.6.1.4.1.42.2.27.9.4.22.1

2.16.840.1.113730.3.3.2.2.1

ブルガリア語

bg

1.3.6.1.4.1.42.2.27.9.4.23.1

2.16.840.1.113730.3.3.2.3.1

ベンガル語(インド)

bn

1.3.6.1.4.1.42.2.27.9.4.24.1

カタロニア語

ca

1.3.6.1.4.1.42.2.27.9.4.25.1

2.16.840.1.113730.3.3.2.4.1

チェコ語

cs

1.3.6.1.4.1.42.2.27.9.4.26.1

2.16.840.1.113730.3.3.2.5.1

デンマーク語

da

1.3.6.1.4.1.42.2.27.9.4.27.1

2.16.840.1.113730.3.3.2.6.1

ドイツ語

deまたはde-DE

1.3.6.1.4.1.42.2.27.9.4.28.1

2.16.840.1.113730.3.3.2.7.1

ドイツ語(オーストリア)

de-AT

1.3.6.1.4.1.42.2.27.9.4.29.1

2.16.840.1.113730.3.3.2.8.1

ドイツ語(ベルギー)

de-BE

1.3.6.1.4.1.42.2.27.9.4.30.1

ドイツ語(スイス)

de-CH

1.3.6.1.4.1.42.2.27.9.4.31.1

2.16.840.1.113730.3.3.2.9.1

ドイツ語(ルクセンブルク)

de-LU

1.3.6.1.4.1.42.2.27.9.4.32.1

ギリシャ語

el

1.3.6.1.4.1.42.2.27.9.4.33.1

2.16.840.1.113730.3.3.2.10.1

英語(アメリカ合衆国)

en-US

1.3.6.1.4.1.42.2.27.9.4.34.1

2.16.840.1.113730.3.3.2.11.1

英語(オーストラリア)

en-AU

1.3.6.1.4.1.42.2.27.9.4.35.1

英語(カナダ)

en-CA

1.3.6.1.4.1.42.2.27.9.4.36.1

2.16.840.1.113730.3.3.2.12.1

英語(英国)

en-GB

1.3.6.1.4.1.42.2.27.9.4.37.1

2.16.840.1.113730.3.3.2.13.1

英語(香港)

en-HK

1.3.6.1.4.1.42.2.27.9.4.38.1

英語(アイルランド)

en-IE

1.3.6.1.4.1.42.2.27.9.4.39.1

2.16.840.1.113730.3.3.2.14.1

英語(インド)

en-IN

1.3.6.1.4.1.42.2.27.9.4.40.1

英語(マルタ)

en-MT

1.3.6.1.4.1.42.2.27.9.4.41.1

英語(ニュージーランド)

en-NZ

1.3.6.1.4.1.42.2.27.9.4.42.1

英語(フィリピン)

en-PH

1.3.6.1.4.1.42.2.27.9.4.43.1

英語(シンガポール)

en-SG

1.3.6.1.4.1.42.2.27.9.4.44.1

英語(ヴァージン諸島)

en-VI

1.3.6.1.4.1.42.2.27.9.4.45.1

英語(南アフリカ)

en-ZA

1.3.6.1.4.1.42.2.27.9.4.46.1

英語(ジンバブエ)

en-ZW

1.3.6.1.4.1.42.2.27.9.4.47.1

エスペラント語

eo

1.3.6.1.4.1.42.2.27.9.4.48.1

スペイン語

esまたはes-ES

1.3.6.1.4.1.42.2.27.9.4.49.1

2.16.840.1.113730.3.3.2.15.1

スペイン語(アルゼンチン)

es-AR

1.3.6.1.4.1.42.2.27.9.4.50.1

スペイン語(ボリビア)

es-BO

1.3.6.1.4.1.42.2.27.9.4.51.1

スペイン語(チリ)

es-CL

1.3.6.1.4.1.42.2.27.9.4.52.1

スペイン語(コロンビア)

es-CO

1.3.6.1.4.1.42.2.27.9.4.53.1

スペイン語(コスタリカ)

es-CR

1.3.6.1.4.1.42.2.27.9.4.54.1

スペイン語(ドミニカ共和国)

es-DO

1.3.6.1.4.1.42.2.27.9.4.55.1

スペイン語(エクアドル)

es-EC

1.3.6.1.4.1.42.2.27.9.4.56.1

スペイン語(グアテマラ)

es-GT

1.3.6.1.4.1.42.2.27.9.4.57.1

スペイン語(ホンジュラス)

es-HN

1.3.6.1.4.1.42.2.27.9.4.58.1

スペイン語(メキシコ)

es-MX

1.3.6.1.4.1.42.2.27.9.4.59.1

スペイン語(ニカラグア)

es-NI

1.3.6.1.4.1.42.2.27.9.4.60.1

スペイン語(パナマ)

es-PA

1.3.6.1.4.1.42.2.27.9.4.61.1

スペイン語(ペルー)

es-PE

1.3.6.1.4.1.42.2.27.9.4.62.1

スペイン語(プエルトリコ)

es-PR

1.3.6.1.4.1.42.2.27.9.4.63.1

スペイン語(パラグアイ)

es-PY

1.3.6.1.4.1.42.2.27.9.4.64.1

スペイン語(エルサルバドル)

es-SV

1.3.6.1.4.1.42.2.27.9.4.65.1

スペイン語(アメリカ合衆国)

es-US

1.3.6.1.4.1.42.2.27.9.4.66.1

スペイン語(ウルグアイ)

es-UY

1.3.6.1.4.1.42.2.27.9.4.67.1

スペイン語(ベネズエラ)

es-VE

1.3.6.1.4.1.42.2.27.9.4.68.1

エストニア語

et

1.3.6.1.4.1.42.2.27.9.4.69.1

2.16.840.1.113730.3.3.2.16.1

バスク語

eu

1.3.6.1.4.1.42.2.27.9.4.70.1

ペルシア語

fa

1.3.6.1.4.1.42.2.27.9.4.71.1

ペルシア語(インド)

fa-IN

1.3.6.1.4.1.42.2.27.9.4.72.1

ペルシア語(イラン)

fa-IR

1.3.6.1.4.1.42.2.27.9.4.73.1

フィンランド語

fi

1.3.6.1.4.1.42.2.27.9.4.74.1

2.16.840.1.113730.3.3.2.17.1

フェロー語

fo

1.3.6.1.4.1.42.2.27.9.4.75.1

フランス語

frまたはfr-FR

1.3.6.1.4.1.42.2.27.9.4.76.1

2.16.840.1.113730.3.3.2.18.1

フランス語(ベルギー)

fr-BE

1.3.6.1.4.1.42.2.27.9.4.77.1

2.16.840.1.113730.3.3.2.19.1

フランス語(カナダ)

fr-CA

1.3.6.1.4.1.42.2.27.9.4.78.1

2.16.840.1.113730.3.3.2.20.1

フランス語(スイス)

fr-CH

1.3.6.1.4.1.42.2.27.9.4.79.1

2.16.840.1.113730.3.3.2.21.1

フランス語(ルクセンブルグ)

fr-LU

1.3.6.1.4.1.42.2.27.9.4.80.1

アイルランド語

ga

1.3.6.1.4.1.42.2.27.9.4.81.1

ガリシア語

gl

1.3.6.1.4.1.42.2.27.9.4.82.1

グジャラト語

gu

1.3.6.1.4.1.42.2.27.9.4.83.1

マン島語(マン島)

gv

1.3.6.1.4.1.42.2.27.9.4.84.1

ヘブライ語

heまたはiw

1.3.6.1.4.1.42.2.27.9.4.85.1

2.16.840.1.113730.3.3.2.27.1

ヒンディー語

hi

1.3.6.1.4.1.42.2.27.9.4.86.1

クロアチア語

hr

1.3.6.1.4.1.42.2.27.9.4.87.1

2.16.840.1.113730.3.3.2.22.1

ハンガリー語

hu

1.3.6.1.4.1.42.2.27.9.4.88.1

2.16.840.1.113730.3.3.2.23.1

アルメニア語

hy

1.3.6.1.4.1.42.2.27.9.4.89.1

インドネシア語

id

1.3.6.1.4.1.42.2.27.9.4.90.1

アイスランド語

is

1.3.6.1.4.1.42.2.27.9.4.91.1

2.16.840.1.113730.3.3.2.24.1

イタリア語

it

1.3.6.1.4.1.42.2.27.9.4.92.1

2.16.840.1.113730.3.3.2.25.1

イタリア語(スイス)

it-CH

1.3.6.1.4.1.42.2.27.9.4.93.1

2.16.840.1.113730.3.3.2.26.1

日本語

ja

1.3.6.1.4.1.42.2.27.9.4.94.1

2.16.840.1.113730.3.3.2.28.1

グリーンランド語

kl

1.3.6.1.4.1.42.2.27.9.4.95.1

カンナダ語

kn

1.3.6.1.4.1.42.2.27.9.4.96.1

韓国語

ko

1.3.6.1.4.1.42.2.27.9.4.97.1

2.16.840.1.113730.3.3.2.29.1

コンカニ語

kok

1.3.6.1.4.1.42.2.27.9.4.98.1

コーンウォール語

kw

1.3.6.1.4.1.42.2.27.9.4.99.1

リトアニア語

lt

1.3.6.1.4.1.42.2.27.9.4.100.1

2.16.840.1.113730.3.3.2.30.1

ラトビア語またはレット語

lv

1.3.6.1.4.1.42.2.27.9.4.101.1

2.16.840.1.113730.3.3.2.31.1

マケドニア語

mk

1.3.6.1.4.1.42.2.27.9.4.102.1

2.16.840.1.113730.3.3.2.32.1

マラティー語

mr

1.3.6.1.4.1.42.2.27.9.4.103.1

マルタ語

mt

1.3.6.1.4.1.42.2.27.9.4.104.1

オランダ語

nlまたはnl-NL

1.3.6.1.4.1.42.2.27.9.4.105.1

2.16.840.1.113730.3.3.2.33.1

オランダ語(ベルギー)

nl-BE

1.3.6.1.4.1.42.2.27.9.4.106.1

2.16.840.1.113730.3.3.2.34.1

ノルウェー語

noまたはno-NO

1.3.6.1.4.1.42.2.27.9.4.107.1

2.16.840.1.113730.3.3.2.35.1

ノルウェー語(ニーノシュク)

no-NO-NY

1.3.6.1.4.1.42.2.27.9.4.108.1

2.16.840.1.113730.3.3.2.37.1

ノルウェー語(ニーノシュク)

nn

1.3.6.1.4.1.42.2.27.9.4.109.1

ノルウェー語(ブークモール)

nbまたはno-NO-B

1.3.6.1.4.1.42.2.27.9.4.110.1

2.16.840.1.113730.3.3.2.36.1

オロモ語(アファン)

om

1.3.6.1.4.1.42.2.27.9.4.111.1

オロモ語(エチオピア)

om-ET

1.3.6.1.4.1.42.2.27.9.4.112.1

オロモ語(ケニア)

om-KE

1.3.6.1.4.1.42.2.27.9.4.113.1

ポーランド語

pl

1.3.6.1.4.1.42.2.27.9.4.114.1

2.16.840.1.113730.3.3.2.38.1

ポルトガル語

ptまたはpt-PT

1.3.6.1.4.1.42.2.27.9.4.115.1

ポルトガル語(ブラジル)

pt-BR

1.3.6.1.4.1.42.2.27.9.4.116.1

ルーマニア語

ro

1.3.6.1.4.1.42.2.27.9.4.117.1

2.16.840.1.113730.3.3.2.39.1

ロシア語

ruまたはru-RU

1.3.6.1.4.1.42.2.27.9.4.118.1

2.16.840.1.113730.3.3.2.40.1

ロシア語(ウクライナ)

ru-UA

1.3.6.1.4.1.42.2.27.9.4.119.1

セルビア-クロアチア語

sh

1.3.6.1.4.1.42.2.27.9.4.120.1

2.16.840.1.113730.3.3.2.41.1

スロバキア語

sk

1.3.6.1.4.1.42.2.27.9.4.121.1

2.16.840.1.113730.3.3.2.42.1

スロベニア語

sl

1.3.6.1.4.1.42.2.27.9.4.122.1

2.16.840.1.113730.3.3.2.43.1

ソマリ語

soまたはso-SO

1.3.6.1.4.1.42.2.27.9.4.123.1

ソマリ語(ジブチ)

so-DJ

1.3.6.1.4.1.42.2.27.9.4.124.1

ソマリ語(エチオピア)

so-ET

1.3.6.1.4.1.42.2.27.9.4.125.1

ソマリ語(ケニア)

so-KE

1.3.6.1.4.1.42.2.27.9.4.126.1

アルバニア語

sq

1.3.6.1.4.1.42.2.27.9.4.127.1

2.16.840.1.113730.3.3.2.44.1

セルビア語

sr

1.3.6.1.4.1.42.2.27.9.4.128.1

2.16.840.1.113730.3.3.2.45.1

スウェーデン語

sv-SE

1.3.6.1.4.1.42.2.27.9.4.129.1

2.16.840.1.113730.3.3.2.46.1

スウェーデン語(フィンランド)

sv-FI

1.3.6.1.4.1.42.2.27.9.4.130.1

スワヒリ語

sw

1.3.6.1.4.1.42.2.27.9.4.131.1

スワヒリ語(ケニア)

sw-KE

1.3.6.1.4.1.42.2.27.9.4.132.1

スワヒリ語(タンザニア)

sw-TZ

1.3.6.1.4.1.42.2.27.9.4.133.1

タミル語

ta

1.3.6.1.4.1.42.2.27.9.4.134.1

テルグ語

te

1.3.6.1.4.1.42.2.27.9.4.135.1

タイ語

th

1.3.6.1.4.1.42.2.27.9.4.136.1

ティグリニャ語

ti

1.3.6.1.4.1.42.2.27.9.4.137.1

ティグリニャ語(エリトリア)

ti-ER

1.3.6.1.4.1.42.2.27.9.4.138.1

ティグリニャ語(エチオピア)

ti-ET

1.3.6.1.4.1.42.2.27.9.4.139.1

トルコ語

tr

1.3.6.1.4.1.42.2.27.9.4.140.1

2.16.840.1.113730.3.3.2.47.1

ウクライナ語

uk

1.3.6.1.4.1.42.2.27.9.4.141.1

2.16.840.1.113730.3.3.2.48.1

ベトナム語

vi

1.3.6.1.4.1.42.2.27.9.4.142.1

中国語

zh

1.3.6.1.4.1.42.2.27.9.4.143.1

2.16.840.1.113730.3.3.2.49.1

中国語(中国)

zh-CN

1.3.6.1.4.1.42.2.27.9.4.144.1

中国語(香港)

zh-HK

1.3.6.1.4.1.42.2.27.9.4.145.1

中国語(モンゴル)

zh-MO

1.3.6.1.4.1.42.2.27.9.4.146.1

中国語(シンガポール)

zh-SG

1.3.6.1.4.1.42.2.27.9.4.147.1

中国語(台湾)

zh-TW

1.3.6.1.4.1.42.2.27.9.4.148.1

2.16.840.1.113730.3.3.2.50.1

14.3 サポートされる言語のサブタイプ

言語のサブタイプは、デプロイメントのデフォルト言語以外で、言語の文字における固有の属性を示すために、クライアントによって使用可能です。たとえばドイツ語ユーザーは、可能であれば、住所のドイツ語表示を希望する場合があります。この場合、streetAddress属性については言語サブタイプとしてドイツ語を選択でき、この結果ユーザーは住所に関して英語またはドイツ語表示のいずれかを検索できます。属性の言語サブタイプを指定すると、そのサブタイプはattribute;lang-subtypeのように属性名に追加されます。

次のリスト表示は、streetAddress属性に対応する英語およびドイツ語の言語サブタイプを示しています。

streetAddress;lang-en: 10 Schlossplatz, 76113, Karlsruhe, Germany
streetAddress;lang-de: Schloßplatz 10, 76113, Karlsruhe, Deutschland

次の表には、サポートされている言語サブタイプのリストが含まれています。

表14-2 サポートされる言語のサブタイプ

言語

言語タグ

アフリカーンス語

af

アルバニア語

sq

アムハラ語(エチオピア)

am

アラビア語

ar

アルメニア語

hy

バスク語

eu

ベンガル語(インド)

bn

ブルガリア語

bg

ベラルーシ語

be

カタロニア語

ca

中国語

zh

コーンウォール語

kw

クロアチア語

hr

チェコ語

cs

デンマーク語

da

オランダ語

nl

英語

en

エスペラント語

eo

エストニア語

et

フェロー語

fo

フィンランド語

fi

フランス語

fr

ガリシア語

gl

ドイツ語

de

ギリシャ語

el

グリーンランド語

kl

グジャラト語

gu

ヘブライ語

heまたはiw

ヒンディー語

hi

ハンガリー語

hu

アイスランド語

is

インドネシア語

id

アイルランド語

ga

イタリア語

it

日本語

ja

カンナダ語

kn

コンカニ語

kok

韓国語

ko

ラトビア語またはレット語

lv

リトアニア語

lt

マケドニア語

mk

マルタ語

mt

マン島語(マン島)

gv

マラティー語

mr

ノルウェー語

不可

オロモ語

om

ペルシア語

fa

ポーランド語

pl

ポルトガル語

pt

ルーマニア語

ro

ロシア語

ru

セルビア語

sr

セルビア-クロアチア語

sh

スロバキア語

sk

スロベニア語

sl

ソマリ語

so

スペイン語

es

スワヒリ語

sw

スウェーデン語

sv

タミル語

ta

テルグ語

te

タイ語

th

ティグリニャ語

ti

トルコ語

tr

ウクライナ語

uk

ベトナム語

vi

第II部

Directory Proxy Serverのリファレンス

この部では、Directory Proxy Serverの動作について説明します。ここでの情報は説明が主になります。手順については、『Oracle Directory Server Enterprise Edition管理者ガイド』の第II部「Directory Proxy Serverの管理」を参照してください。

次の章で構成されています。

- 第15章「Directory Proxy Serverの概要」では、Directory Proxy Serverのアーキテクチャの概要を説明し、このリリースでの最も重要な機能を高レベルで説明します。

- 第16章「Directory Proxy Serverのロード・バランシングおよびクライアント・アフィニティ」では、Directory Proxy Serverをロード・バランシング用に構成する方法、ロード・バランシングのデプロイ時に伝播遅延のリスクを削減するためにクライアント・アフィニティを使用する方法を説明します。

- 第17章「Directory Proxy Serverの配布」では、LDAPサーバー内のデータをクライアント・リクエストに公開する方法について説明します。

- 第18章「Directory Proxy Serverの仮想化」では、仮想データ・ビューで物理データを異なる方法で表示する方法を説明し、Directory Proxy Serverで使用可能な仮想データ・ビューの種類を説明します。

- 第19章「Directory Proxy ServerとバックエンドLDAPサーバーの接続」では、Directory Proxy ServerとバックエンドLDAPサーバーとの接続について説明します。

- 第20章「クライアントとDirectory Proxy Serverの接続」では、接続に制限およびフィルタを適用するための接続ハンドラの使用方法、およびクライアントに公開されているデータを制限する方法について説明します。

- 第21章「Directory Proxy Serverのクライアント認証」では、Directory Proxy Serverで使用可能なクライアント認証メカニズムについて説明します。

- 第22章「Directory Proxy Serverのセキュリティ」では、Directory Proxy Serverを通過するデータを保護するために使用できるメカニズムについて説明します。

- 第23章「Directory Proxy Serverのロギング」では、Directory Proxy Serverのロギング・インタフェースの概要を説明します。

- 第24章「Directory Proxy Serverのアラートおよび監視」では、Directory Proxy ServerおよびバックエンドLDAPサーバーの可用性の両方を監視するために使用できるメカニズムについて説明します。

15 Directory Proxy Serverの概要

この章ではDirectory Proxy Serverのアーキテクチャの概要を説明し、今回のリリースで最も重要な各機能を概説します。

この章の内容は次のとおりです。

- Directory Proxy Serverの概要

- Directory Proxy Serverのアーキテクチャ

- Directory Proxy Serverの機能の概要

15.1 Directory Proxy Serverの概要

Directory Proxy ServerはLDAPアプリケーション層プロトコルのゲートウェイです。Directory Proxy Serverはディレクトリ・アクセス制御、スキーマ互換性、および高可用性の機能拡張を提供します。

Directory Proxy Serverのアーキテクチャにより、クライアント・リクエストがバックエンド・データ・ソースにルーティングされる方法を制御する、複数のオブジェクトをユーザーが構成できます。次のDirectory Proxy Serverアーキテクチャの単純な構成図では、これらの構成オブジェクトの概要が示されています。この図は、本書に後述されているアーキテクチャの概念を理解するうえで役立ちます。

図15-1 単純化したDirectory Proxy Serverのアーキテクチャ

「図15-1 単純化したDirectory Proxy Serverのアーキテクチャ」の説明

15.2 Directory Proxy Serverのアーキテクチャ

この項では新しいDirectory Proxy Serverのアーキテクチャおよび5.2と比較した新機能について簡単に説明します。この説明は、一部の5.2構成属性のリテラル変換ができない理由について、ユーザーが理解できるようにすることを目的としています。

Directory Proxy Serverインスタンスはデータ・ビューを使用して、クライアント・アプリケーションのリクエストをデータ・ソースへプロキシします。データ・ソースおよびデータ・ソースのプールは、ロード・バランシングされた5.2のグループに相当します。

しかし、データ・ビューは新規の機能です。これらは5.2に存在するいずれにも対応しません。基本的に、Directory Proxy Serverは、接続が開かれたときに接続ハンドラを割り当て、バインドIDが変更されたときの再バインド時に接続ハンドラを再度割り当てることにより、着信接続を個別に処理します。

接続ハンドラはDirectory Proxy Serverに対し、指定された接続を介してリクエストされた操作をどう処理するか決定するための一連のポリシー・ルールを提供します。接続ハンドラは5.2のネットワーク・グループにほぼ相当しますが、ネットワーク・グループはロード・バランシングされたグループを直接使用するように構成されています。

Directory Proxy Serverは接続ハンドラを使用して主に接続に関するポリシーを決定しますので、その接続に対して実行される操作について適切な決定を下すことができます。たとえば、接続ハンドラが特定の接続に対する書込み操作をしないように構成されている場合、Directory Proxy Serverはポリシーのそのプロパティを使用して、この接続での書込み操作リクエストに関する評価を省くことができます。その場合、Directory Proxy Serverが操作をデコードすると、ただちに該当するエラーが返されます。

接続に対するLDAP操作は、データ・ビューによってDirectory Proxy Serverで最初に処理されます。データ・ビューではDirectory Proxy ServerがDNベースのルーティングを実行することができます。言い換えれば、あるデータ・セットに関する操作を1つのデータ・ソース・セットに送信し、別のデータ・セットに関する操作を別のところに送信できます。この新しいアーキテクチャ形式は、5.2構成の再構成という観点からすると不要に見えます。それでも、異なるディレクトリのデータを様々なディレクトリに分散する場合や、分散したデータ・ソースからの異なるデータをリカバリして、クライアント・アプリケーションに対してそれらのソースの仮想ディレクトリ・ビューを表示する場合には、データ・ビューが必要不可欠になります。

したがって、データ・ビューではDirectory Proxy ServerがLDAP操作を処理するためにデータ・ソース・プールを介してデータ・ソースを選択できます。5.2のロード・バランシングされたグループに相当するデータ・ソース・プールは、それぞれが同等のデータを保有するデータ・ソースのセットを表します。プールでは、異なるデータ・ソースにわたって負荷を分散するためにDirectory Proxy Serverが実行するロード・バランシングとフェイルオーバー管理が定義されます。ロード・バランシングは操作ごとに実行されるので、バランシングそのものは本質的に操作ベースです。

データ・ソースは、読取り用のデータのソース、または書込み用のデータ・シンクと考えることができます。Directory Proxy Serverは次の種類のデータ・ソースを処理します。

- LDAPディレクトリ

- LDIFファイル

- JDBCを有効にしたデータ・リポジトリ

Directory Proxy Server 5.2は、基本的に接続ベースのルーターでした。Directory Proxy Server 5.2では、クライアント接続はディレクトリ・サーバーへルーティングされていました。そのクライアント接続からのすべてのリクエストは、その接続が切断されるまで、同じディレクトリ・サーバーに送信されていました。互換性のために、Directory Proxy ServerがDirectory Proxy Server 5.2と同じ動作をするように構成できます。この構成方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の接続ベースのルーターとしてのDirectory Proxy Serverの構成に関する説明を参照してください。このバージョンのDirectory Proxy Serverへのマイグレーション方法の詳細は、『Oracle Directory Server Enterprise Editionアップグレードおよび移行ガイド』を参照してください。

15.3 Directory Proxy Serverの機能の概要

Directory Proxy Serverには次の機能が用意されています。

- 管理のしやすさ

- 複数のディレクトリ・サーバーに格納されたディレクトリ・データへの単一アクセス・ポイント

- 自動リフェラル追従

- ディレクトリ・サーバーの事後監視および事前監視

- コマンドラインまたはGUIを使用した構成

- すべての接続が通常のリスナー・ポートとセキュア・リスナー・ポートを持つ

- 静止モードにより、接続が存在しない管理状態にサーバーが徐々に移行可能

- 認証と認可

- 証明書マッピングを使用した証明書ベースの認証

- セキュアなLDAPリバース・プロキシ

- LDAP制御フィルタリング

- プロキシ認可

- アイデンティティ・マッピング

- アクセス制御

- 分散

- 複数のディレクトリ・サーバーに広がるディレクトリ・サービスへの単一アクセスポイント

- 拡張可能およびカスタマイズ可能な分散アルゴリズム

- 伝播遅延問題に対処するためのサーバー・アフィニティ

- パフォーマンスおよびスケーラビリティのための接続プールおよび部分的なBERデコード

- ロード・バランシング/フェイルオーバー

- 操作または接続に基づくルーティング

- 複製されたLDAPディレクトリ・サーバー間の自動ロード・バランシングおよび自動フェイルオーバーとフェイルバック

- 3つのロード・バランシング・アルゴリズム

- 仮想化

- クライアント・アプリケーション用の複数の仮想ビュー

- 複数の異種データ・ソースの集計

- 属性名および属性値のマッピング

- JDBCに準拠したデータ・リポジトリへのアクセス

- LDIFフラット・ファイル・リソースへのアクセス

16 Directory Proxy Serverのロード・バランシングおよびクライアント・アフィニティ

クライアント・リクエストに応答するために複数のデータ・ソースを使用するデプロイメントでは、ワーク・ロードを分散するためにロード・バランシングが使用されます。クライアント・アフィニティを使用すると、ロード・バランシングされたデプロイメントでの伝播遅延のリスクを低減できます。

ロード・バランシングとクライアント・アフィニティの構成方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の第20章「Directory Proxy Serverのロード・バランシングおよびクライアント・アフィニティ」を参照してください。

Directory Proxy Serverがロード・バランシングとクライアント・アフィニティを実行する方法の詳細は、次の項を参照してください。

- LDAPデータ・ソース・プール

- ロード・バランシング

- クライアント・アフィニティ

16.1 LDAP データ・ソース・プール

クライアントからのリクエストはLDAPデータ・ソース・プールに分散されます。データ・ソース・プールには1つ以上のデータ・ソースがアタッチされます。データ・ソース・プールのプロパティは、プールにアタッチされる様々なLDAPデータ・ソースにクライアント・リクエストがルーティングされる方法を決定します。LDAPデータ・ソース・プールには次のプロパティを構成できます。

client-affinity-policy

クライアント・リクエストが単一のLDAPデータ・ソースにアフィニティを示すときを決定するために使用されるアルゴリズム

client-affinity-timeout

クライアント・アフィニティのタイムアウト時間

description

LDAPデータ・ソース・プールの説明

enable-client-affinity

同じクライアントからの連続したリクエストを同じLDAPデータ・ソースに送るかどうかを示すフラグ

load-balancing-algorithm

ロード・バランシングされたLDAPデータ・ソースに対して操作を分散するために使用されるアルゴリズム

LDAPデータ・ソース・プールの作成および構成方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のLDAPデータ・ソース・プールの作成と構成に関する説明を参照してください。

16.2 ロード・バランシング

複数のデータ・ソースがプールにアタッチされている場合、ロード・バランシングはプールのどのデータ・ソースがリクエストに応答するかを決定します。ロード・バランシングの詳細は次の項を参照してください。

- ロード・バランシングの概要

- ロード・バランシングの比例アルゴリズム

- ロード・バランシングの飽和アルゴリズム

- ロード・バランシングの操作アフィニティ・アルゴリズム

- ロード・バランシングのフェイルオーバー・アルゴリズム

- ロード・バランシングの適応フェイルオーバー・アルゴリズム

- ロード・バランシングの最速サーバー・アルゴリズム

16.2.1 ロード・バランシングの概要

Directory Proxy Serverはロード・バランシング・アルゴリズムに従ってリクエストを分散します。次のロード・バランシング・アルゴリズムを構成できます。

比例アルゴリズム

データ・ソースの重みおよびDirectory Proxy Serverが最後に起動されてからのデータ・ソースの累積負荷に従って、リクエストが分散されます。

飽和アルゴリズム

データ・ソースの重みおよびデータ・ソースで使用可能な接続の数に従って、リクエストが分散されます。

操作アフィニティ・アルゴリズム

ハッシュ値に従ってリクエストが分散されます。アタッチ済データ・ソースに割り当てられるハッシュ値の数は、そのデータ・ソースの重みに比例します。

フェイルオーバー・アルゴリズム

その操作に対して重みが最大のアタッチ済データ・ソースのみに、リクエストが分散されます。

適応フェイルオーバー・アルゴリズム

最小限必要な重みの合計になるよう、十分に重みが追加されたデータ・ソース・セットにリクエストが分散されます。

最速サーバー・アルゴリズム

操作のタイプに応じて、レスポンス時間が最も短いアタッチ済データ・ソースにのみ、リクエストが分散されます。

最速サーバー・アルゴリズムを除くすべてのロード・バランシング・アルゴリズムで、アタッチ済の各データ・ソースを、次の各操作タイプに応じた個別の重みを付けて構成できます。

- 追加

- バインド

- 比較

- 削除

- DNの変更

- 変更

- 検索

複数のアタッチ済データ・ソースが、あるタイプの操作について同じ重みを付けて構成されている場合、リクエストはDirectory Proxy Serverによって各データ・ソースに均等に分散されます。特定タイプの操作に対してあるデータ・ソースの重みがdisabledの場合、そのタイプのリクエストがDirectory Proxy Serverによってそのデータ・ソースに分散されることはありません。データ・ソースの重みが0(ゼロ)の場合、リクエストはそのデータ・ソースに分散されません。

次の場合は、アタッチ済データ・ソースをロード・バランシング・アルゴリズムによって選択することはできません。

- エラーが発生したためにデータ・ソースが使用不可である

- Directory Proxy Serverとデータ・ソース間のすべての接続が使用中である

データ・ソースが読取り専用で構成されている場合、そのデータ・ソースは追加リクエスト、削除リクエストまたは変更リクエストを受け取ることができません。ただし、検索リクエストは受け取ることができます。

ロード・バランシング・アルゴリズムはベスト・エフォートを基準に機能します。ロード・バランシング・アルゴリズムが重みを考慮してリクエストを分散するための十分なリソースがない場合、重みは無効になります。たとえば、データ・ソースに対する同時リクエストの数がそのデータ・ソースの最大接続数を超えた場合、リクエストは他のデータ・ソースに分散されます。

クライアント・アフィニティ機能が有効な場合は、ロード・バランシング・アルゴリズムを使用するかわりにクライアント・アフィニティ機能を使用して、リクエストがDirectory Proxy Serverにより分散されます。クライアント・アフィニティの詳細は、「クライアント・アフィニティ」を参照してください。

16.2.2 ロード・バランシングの比例アルゴリズム

比例アルゴリズムでは、次の基準に従ってアタッチ済データ・ソースにリクエストが分散されます。

- リクエストのタイプ

- プールの他のデータ・ソースの重みの合計の比率としてのデータ・ソースの重み

- Directory Proxy Serverを最後に起動してからの累積負荷

その操作に対して重みが最大のアタッチ済データ・ソースのみに、リクエストが分散されます。リクエストはDirectory Proxy Serverにより、そのタイプのリクエストに対する各データ・ソースの重みに比例して引き続き分散されます。

あるデータ・ソースが使用不可になると、リクエストはDirectory Proxy Serverにより、残りのデータ・ソースにその重みに比例して分散されます。

次の図では、最初の8つの検索リクエストがDirectory Proxy Serverにより、異なる重みを持つデータ・ソースのプールに分散される方法を示します。重み2のデータ・ソースは、重み1のデータ・ソースの2倍のリクエストを処理します。

図16-1 ロード・バランシングの比例アルゴリズムに従ったリクエストの分散

「図16-1 ロード・バランシングの比例アルゴリズムに従ったリクエストの分散」の説明

比例アルゴリズムの構成例については、『Oracle Directory Server Enterprise Edition管理者ガイド』のロード・バランシングの比例アルゴリズムの構成に関する説明を参照してください。

16.2.3 ロード・バランシングの飽和アルゴリズム

飽和アルゴリズムでは、データ・ソースの重みおよび使用可能な接続の数に従って、リクエストが分散されます。

特定タイプのすべてのリクエストは、重みが最大のデータ・ソースに、その飽和レベルに達するまで分散されます。このレベルに達すると、リクエストはこのデータ・ソースと重みが2番目のデータ・ソースに分散されます。飽和レベルは、データ・ソースの重みに接続数の合計を掛けて取得できます。

次の図では、Directory Proxy Serverにより、10の接続とそれぞれ異なる重みを持つデータ・ソースのプールにリクエストが分散される方法を示します。括弧内は使用可能な接続数に重みを掛けた結果です。

図16-2 ロード・バランシングの飽和アルゴリズムに従ったリクエストの分散

「図16-2 ロード・バランシングの飽和アルゴリズムに従ったリクエストの分散」の説明

デプロイメントに大きく異なる容量のデータ・ソースが含まれている場合、飽和アルゴリズムを使用してデータ・ソースの容量に応じてリクエストを分散できます。

飽和アルゴリズムの構成例については、『Oracle Directory Server Enterprise Edition管理者ガイド』のロード・バランシングの飽和アルゴリズムの構成に関する説明を参照してください。

16.2.4 ロード・バランシングの操作アフィニティ・アルゴリズム

ロード・バランシングの操作アフィニティ・アルゴリズムでは、リクエストのタイプとリクエストのプロパティに従って、すべてのリクエストがハッシュ値に割り当てられます。各ハッシュ値はアタッチ済データ・ソースに割り当てられます。データ・ソースに割り当てられるハッシュ値の数は、そのデータ・ソースの重みに比例します。

リクエストが受信されると、ハッシュ表がDirectory Proxy Serverにより検査され、そのハッシュ値を持つリクエストがすでに分散されているかどうかを判別します。ハッシュ値がすでに存在している場合、リクエストはDirectory Proxy Serverによりそのハッシュ値を持つデータ・ソースに送信されます。ハッシュ値がハッシュ表に存在していない場合、リクエストはロード・バランシングの比例アルゴリズムを使用して分散されます。

図16-3は、アタッチ済データ・ソースが3つある事例です。データ・ソースAは検索操作に対して重み3を持ち、他の2つのデータ・ソースは検索操作に対して重み1を持っています。ハッシュ表は、ハッシュ値の3/5をデータ・ソースAに割り当て、1/5をデータ・ソースBに、1/5をデータ・ソースCに割当てます。

リクエストが正常な多様性範囲である場合、データ・ソースAはデータ・ソースBまたはデータ・ソースCの3倍のリクエストを受信することになります。同じプロパティを持つ不均衡な数のリクエストがある場合、3つのデータ・ソース間のリクエストの比率は崩れます。たとえば、クライアントが同じDNに対してバインド・リクエストを繰り返した場合、バインドは常に同じデータ・ソースによって処理される必要があります。

図16-3 ロード・バランシングの操作アフィニティ・アルゴリズムに従ったリクエストの分散

「図16-3 ロード・バランシングの操作アフィニティ・アルゴリズムに従ったリクエストの分散」の説明

ロード・バランシングの操作アフィニティ・アルゴリズムの使用は、次の機能にとって有益です。

- グローバル・アカウントのロックアウト

- Directory Serverのキャッシュの最適化

16.2.4.1 ロード・バランシングの操作アフィニティ・アルゴリズムを使用するデメリット

ロード・バランシングの操作アフィニティ・アルゴリズムは、複数のデータ・ソース間でのワークロードの均等分散を保証するものではありません。

ハッシュ値はリクエストのタイプおよびリクエストのプロパティに従って、リクエストに割り当てられます。ハッシュ値の範囲は、関連のないリクエストの任意のグループを表します。あるハッシュ値の範囲が、別のハッシュ値の範囲よりもずっと多くの操作を表すこともあります。ある範囲のハッシュ値が頻繁に行われるリクエストを表し、別の範囲のハッシュ値がほとんど行われないリクエストを表す場合があります。

16.2.4.2 グローバル・アカウントのロックアウトに対する操作アフィニティ・アルゴリズム

ロード・バランシングの操作アフィニティ・アルゴリズムを使用することにより、特定クライアントからのバインド・リクエストに対して同じデータ・ソースが常に応答するようにできます。このようにして、最大回数のバインド試行が失敗すると、クライアントがロックアウトされるようにできます。同じデータ・ソースが特定クライアントからのバインド・リクエストに応答しない場合、クライアントは最大回数を超えてバインド試行を行うことができます。

クライアントがバインドすると、そのリクエストのハッシュ値がバインド資格証明に従って割り当てられます。Directory Proxy Serverはハッシュ表を参照し、そのハッシュ値のデータ・ソースにリクエストを分散します。クライアントのバインド回数にかかわらず、このハッシュ値は常に同じです。リクエストは常に同じデータ・ソースに分散されます。

クライアントが適切な資格証明のないバインド・リクエストを出した場合、データ・ソースはそのバインド・リクエストを拒否します。クライアントが2回目または3回目のバインド・リクエストを行った場合、同じデータ・ソースがバインド・リクエストを拒否します。クライアントが最大回数のバインド試行を超えると、そのクライアントはDirectory Serverによりロックアウトされます。

グローバル・アカウントのロックアウトに対する操作アフィニティ・アルゴリズムの構成例については、『Oracle Directory Server Enterprise Edition管理者ガイド』のグローバル・アカウントのロックアウトに対する操作アフィニティ・アルゴリズムの構成に関する説明を参照してください。

16.2.4.3 キャッシュ最適化の操作アフィニティ・アルゴリズム

ロード・バランシングの操作アフィニティ・アルゴリズムを使用することにより、同じクライアントから同じエントリへの検索を、常に同じデータ・ソースに分散できます。データ・ソースがリクエストに応答すると、ターゲット・エントリはキャッシュに格納されます。同じデータ・ソースが同じリクエストに繰り返し応答する場合、そのデータ・ソースはキャッシュ・データを使用できるという利点があります。

キャッシュの最適化に対する操作アフィニティ・アルゴリズムの構成例については、『Oracle Directory Server Enterprise Edition管理者ガイド』のキャッシュの最適化に対する操作アフィニティ・アルゴリズムの構成に関する説明を参照してください。

16.2.5 ロード・バランシングのフェイルオーバー・アルゴリズム

フェイルオーバー・アルゴリズムでは、特定タイプのリクエストはその操作に対して重みが最大のアタッチ済データ・ソースにのみ分散されます。そのアタッチ済データ・ソースが失敗した場合、その操作に対して2番目の重みのアタッチ済データ・ソースにのみ、リクエストが分散されます。重みが最大のデータ・ソースが再びオンラインになると、リクエストはそのデータ・ソースに分散されます。

フェイルオーバー・アルゴリズムの構成例については、『Oracle Directory Server Enterprise Edition管理者ガイド』のロード・バランシングのフェイルオーバー・アルゴリズムの構成に関する説明を参照してください。

16.2.6 ロード・バランシングの適応フェイルオーバー・アルゴリズム

このアルゴリズムは、フェイルオーバー・アルゴリズムが使用されているときに起こりうる状況を救済するために作成されました。フェイルオーバー・アルゴリズムでは、同じ重みのデータ・ソースはグループを表します。リクエストは常に、重みが最大のグループにのみ送信されます。一般的なデプロイメントではローカル・グループ(すべてのデータ・ソースが同じ高い重みを共有する)およびリモート・グループ(すべてのデータ・ソースが同じ低い重みを共有する)が使用されます。リモート・データ・ソースは、ローカル・データ・ソースがダウンするか使用不可になるまで使用されません。フェイルオーバー・アルゴリズムを使用すると、ほとんどの場合にグループが最大限ロードされます。データ・ソースが使用できない場合、グループ全体のスループットが低下します。

適応フェイルオーバー・アルゴリズムは、最小限必要な重み合計を定義することにより、この状況を救済します。データ・ソースは2つのグループに分けられます。アクティブ・グループは、希望する最小限の重み合計に追加の重みが達するデータ・ソース・セットです。残りのすべてのデータ・ソースは、スタンバイ・グループに分類されます。

アクティブ・グループは、最小限の重み合計(各データ・ソースの重みの合計)に達するまで、重みが最大のn個のデータ・ソースを選択することにより、作成されます。アクティブ・グループの各データ・ソースは、その重みに比例してリクエストを取得します。スタンバイ・グループのデータ・ソースには、リクエストは送信されません。

データ・ソースが使用可能になったり使用不可になった場合、または重みが変更された場合、グループのメンバーは動的に再評価されます。

デフォルトの最小限の重み合計は100で、次のコマンドを使用して変更できます。

$ dpconf set-ldap-data-source-pool-prop -host host  -p port  pool-name  \
minimum-total-weight:2

図16-4 ロード・バランシングの適応フェイルオーバー・アルゴリズムに従ったリクエストの分散

「図16-4 ロード・バランシングの適応フェイルオーバー・アルゴリズムに従ったリクエストの分散」の説明

詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のロード・バランシングの適応フェイルオーバー・アルゴリズムの構成に関する説明を参照してください。

16.2.7 ロード・バランシングの最速サーバー・アルゴリズム

最速サーバー・アルゴリズムでは、次の基準に従ってアタッチ済データ・ソースにリクエストが分散されます。

- リクエストのタイプ

- そのタイプのリクエストに対するレスポンス時間

リクエストを送信するためのサーバーを選択する必要があるときに、このアルゴリズムは最も短いレスポンス時間のサーバーをアタッチ済データ・ソースのリストから選択します。レスポンス時間は各データ・ソースおよび各操作タイプについて別々に測定されます。

サーバーのレスポンス時間は、実際は固定サイズのサンプルの値を意味します。最新のn回のレスポンス時間がこのサンプルに格納され、新しい測定が追加されるたびに(おそらく一番古い測定と置き換えられて)平均値が再計算されます。サンプル(最新のn回のレスポンス時間のセット)は、各サーバーの各操作タイプと関連付けられます。サンプルのサイズ(n)のデフォルト値は100ですが、次のコマンドを使用して構成できます。

$ dpconf set-ldap-data-source-pool-prop -host host  -p port  pool-name  \
sample-size:300

サンプル・サイズが小さいほど、データ・ソースのレスポンス時間の変化に対するアルゴリズムの反応性が高くなります。ただし、サンプル・サイズが小さすぎると悪影響を及ぼす場合があります。同じクライアントからの操作が異なるデータ・ソースに送信される場合があります。サイレント・バインド操作が必要となることがありますが、クライアント側から見るとこれにより、レスポンス時間が長くなります。

この方式の問題点は、最も短い平均レスポンス時間のサーバーが常に選択されることです。より長い平均レスポンス時間の他のサーバーは選択されないため、それらのサンプルおよび平均レスポンス時間は更新されません。そのため、平均レスポンス時間の長いサーバーが、実際には現在の最速サーバーよりも短いレスポンス時間を提供できるという状況が起こりえます。しかし、平均レスポンス時間が長いサーバーにはリクエストが送信されないため、その平均レスポンス時間は更新されず、そのサーバーがDirectory Proxy Serverの観点から最適の選択肢となることはありません。このため、システム全体のスループットが実際に可能であるよりも低くなる場合があるのです。

この状況を解決するために、2番目の属性が存在します。proportionプロパティは、いずれかのproportion操作が、最速サーバーに送信されるかわりにランダム選択されたサーバーに送信されることを示します。この値は次のコマンドを使用して構成できます。

$ dpconf set-ldap-data-source-pool-prop -host host  -p port  pool-name  \
proportion:100

proportionのデフォルト値は100です。これは、99の操作が最速サーバーに送信され、1つの操作がランダム選択されたサーバーに送信されることを意味します。ランダム選択は一様分布に従います。すべてのアタッチ済データ・ソースは、最も短いレスポンス時間のものでも、考慮されます。このため、ランダム選択のサーバーが最速サーバーになることもあります。

proportionを0に設定するということは、常にレスポンス時間に基づいて選択を行う必要があることを意味します。

選択したサーバーへの接続がなんらかの理由で取得できない場合、他のサーバーがランダムに試行されます。

詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のロード・バランシングの最速サーバー・アルゴリズムの構成に関する説明を参照してください。

16.3 クライアント・アフィニティ

クライアント・アフィニティは、クライアント接続とデータ・ソース間で定義されます。クライアント・アフィニティが定義されると、指定されたクライアント接続からのリクエストはデータ・ソース・プール内の指定されたデータ・ソースに分散されます。

クライアント・アフィニティ機能は、ロード・バランシングを使用するデプロイメントにおける伝播遅延のリスクを低減します。伝播遅延は、クライアントが同じエントリをターゲットとしたリクエストを連続して行ったとき、それらのリクエストが同じデータ・ソースにより処理されない場合に発生します。たとえば、クライアントがエントリを変更するあるリクエストを行い、変更されたエントリを使用する2番目のリクエストを行う場合があります。最初のリクエストにより更新されなかったデータ・ソースにより、2番目のリクエストが処理された場合、エラーが発生します。

クライアント・アフィニティは次の方法で構成できます。

- 有効化または無効化

- 最初の書込みリクエスト後のすべての書込みリクエストに対して構成

- 最初の書込みリクエスト後のすべてのリクエストに対して構成

- 最初の読取りリクエストまたは書込みリクエスト後のすべてのリクエストに対して構成

- 書込みリクエスト後の最初の読取りリクエストに対して構成

- 指定した時間後に期限切れになるように構成

クライアント・アフィニティはロード・バランシング・アルゴリズムよりも優先されます。Directory Proxy Serverは、ロード・バランシング・アルゴリズムにかかわらず、指定された接続からのリクエストを指定されたデータ・ソースへ分散します。

クライアント・アフィニティが定義され、有効化されている場合、次の状況下ではロード・バランシング・アルゴリズムの方が優先されます。

- クライアント・アフィニティを開始するリクエストが発生していない

- クライアント・アフィニティを終了するリクエストが発生した

- クライアント・アフィニティのタイムアウトが期限切れになった

- 指定されたデータ・ソースがリクエストに対して使用できない、または指定されたデータ・ソースでエラーが発生した

次の場合、データ・ソースはリクエストに対して使用できません。

- オフラインである。

- リクエストされている操作を実行するように構成されていない。たとえば、読取りリクエストに対して構成されているデータ・ソースは、書込みリクエストに応答できません。

クライアント・アフィニティの構成方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のクライアント・アフィニティの構成に関する説明を参照してください。

Directory Proxy Serverをシンプルな接続ベースのルーターとして構成するには、クライアント・アフィニティ機能を使用する必要があります。詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の接続ベースのルーターとしてのDirectory Proxy Serverの構成に関する説明を参照してください。

17 Directory Proxy Serverの配布

Directory Proxy Serverでは、データ・ビューの定義を使用した配布が可能です。データ・ビューは、そのデータ・ビューのエントリのベースDNを決定するビュー・ベースによって定義されます。Directory Proxy Serverが提供する配布アルゴリズムに基づいて、エントリを様々なデータ・ビュー間で分割する方法を指定できます。

この章の内容は、次のとおりです。

- LDAPデータ・ビュー

- 異なるデータ・ビューへのサブツリーのエントリの配布

- データ・ビューのユースケース

17.1 LDAPデータ・ビュー

LDAPデータ・ビューにより、クライアントのリクエストに対してLDAPサーバーのデータが公開され、そのレクエストに対応するソース・プールが指定されます。LDAPデータ・ビューを定義することで、次のタスクを実行できます。

- データベース全体を1つのビューで公開する

- データベース内の異なるサブツリーに対して異なるビューを提供する

- 異なるデータベースの統合ビューを提供する

その他のタイプのデータ・ビューがありますが、配布できるのは、LDAPデータ・ビューのみです。他のタイプのデータ・ビューの詳細は、第18章「Directory Proxy Serverの仮想化」を参照してください。

17.1.1 LDAPデータ・ビューの機能

単純なLDAPデータ・ビューは、主にデータ・ビューのベースDNによって定義されます。単純なデータ・ビューでは、サブツリーのすべてのエントリがデータ・ビューで囲まれます。データ・ビューは、上位データ・ビューおよび下位データ・ビューの階層構造で存在します。下位データ・ビューは、ベースDNが上位データ・ビューのベースDNに対して劣っているデータ・ビューです。下位データ・ビューのエントリは、上位データ・ビューから除外されます。

データ・ビューの機能の詳細は、次の項を参照してください。

- データ・ビューからのサブツリーの除外

- 上位データ・ビューをターゲットとする検索の除外された下位データ・ビューでの検索

- 異なるデータ・ビューへのサブツリーのエントリの配布

- 属性名とDN名の変更

17.1.1.1 データ・ビューからのサブツリーの除外

下位データ・ビューが作成されると、Directory Proxy Serverは上位データ・ビューから下位データ・ビューを自動的に除外します。リクエストが下位データ・ビューをターゲットにしている場合、リクエストは上位データ・ビューではなく、下位データ・ビューに送信されます。

デフォルトでは、Directory Proxy Serverは、上位データ・ビューのexcluded-subtreesパラメータを自動的に構成して、下位データ・ビューを除外します。自動構成を無効化する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のexcluded-subtreeおよびalternate-search-base-dnプロパティを手動で構成する方法に関する説明を参照してください。

サブツリーcn=config、cn=monitorおよびcn=proxy managerは、デフォルトですべてのデータ・ビューから除外されます。

17.1.1.2 上位データ・ビューをターゲットとする検索の除外された下位データ・ビューでの検索

代替検索ベースが下位データ・ビューで指定された場合、上位データ・ビューをターゲットとする検索操作も下位データ・ビューで実行されます。

デフォルトでは、Directory Proxy Serverは、下位データ・ビューのalternateSearchBaseパラメータを自動的に構成します。自動構成を無効化する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のexcluded-subtreeおよびalternate-search-base-dnプロパティを手動で構成する方法に関する説明を参照してください。

17.1.1.3 属性名とDN名の変更

ディレクトリの各エントリは、DNおよび、属性と属性値のセットにより識別されます。クライアント側で定義されたDNおよび属性は、多くの場合、サーバー側で定義されたDNおよび属性にはマップされません。

データ・ビューは、DNおよび属性の名前をサーバー側と一致する値に変更するよう定義できます。クライアントが要求を行うと、DNと属性の名前がサーバー側と一致するように変更されます。結果がクライアントに返されると、DNと属性はクライアント側と一致するよう元に戻されます。

17.1.1.3.1 属性名の変更

次の図は、Directory Proxy Serverによって属性名がどのように変更されるかを示しています。

図17-1 属性名の変更

「図17-1 属性名の変更」の説明

図17-1で、電子メール・クライアントでは、姓を属性surnameによって指定する必要がありますが、LDAPサーバーでは、姓は属性snによって定義されます。属性名を変更すると属性名のみが影響を受け、属性の値は変更されません。ただし、属性名を変更すると、その名前を持つすべてのエントリの名前が変更されます。

属性名の変更を構成する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の属性名の変更を構成する方法に関する説明を参照してください。

17.1.1.3.2 DN名の変更

次の図は、Directory Proxy ServerによってDN名がどのように変更されるかを示しています。

図17-2 DN名の変更

「図17-2 DN名の変更」の説明

図17-2で、クライアントにはdc=example, dc=comデータベースが含まれています。LDAPサーバーには、dc=example, dc=orgデータベースが含まれています。Directory Proxy Serverは、DNの名前を変更します。

DNが元々のDN名の変更によって変更されているDITの一部である場合、それらのDNを含む属性名も変更する必要があります。図17-2で、group属性には、グループ・メンバーのDNのリストが含まれています。dc=example, dc=comの名前をdc=example, dc=orgに変更すると、グループ属性のDNの名前も変更する必要があります。

DN名の変更を構成する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のDN名の変更を構成する方法に関する説明を参照してください。

17.2 異なるデータ・ビューへのサブツリーのエントリの配布

配布アルゴリズムは、同じベースDNを持つデータ・ビュー間に操作を配布します。配布アルゴリズムのタイプは、distribution-algorithmパラメータによって定義されます。

操作の配布方法を決定するために、配布アルゴリズムは、データ・ビューのベースDNの直下の属性の値を考慮します。たとえば、ou=people,dc=example,dc=comのベースDNを持つデータ・ビューを考慮します。検索操作にベースDN uid=23,ou=people,dc=example,dc=comが含まれている場合、uidがデータ・ビューのベースDNの直下にあるため、配布アルゴリズムはuidをルーティング属性とみなします。次に、アルゴリズムは、値23と一致するよう試みて、操作のルーティング方法を決定します。

ただし、検索操作にベースDN uid=23,ou=managers,ou=people,dc=example,dc=comが含まれている場合、ouがデータ・ビューのベースDNの直下にあるため、配布アルゴリズムはouをルーティング属性とみなします。ouは、検索問合せで指定されているuidと一致しないため、配布アルゴリズムは検索を正しく配布できません。この場合、配布を正しく動作させるには、データ・ビューのベースDNをou=managers,ou=people,dc=example,dc=comにする必要があります。

そのため、データ・ビューのベースDNが配布アルゴリズムに対して適切かどうかを確認する必要があります。

次の配布アルゴリズムは、Directory Proxy Serverによって提供されます。

パターン一致

リクエストは、リクエストのパラメータと1つ以上のパターンの間の一致に基づいてデータ・ビューに配布されます。パターンは次のパラメータによって定義されます。

- pattern-matching-base-dn-regular-expression

- pattern-matching-base-object-search-filter

- pattern-matching-dn-regular-expression

- pattern-matching-one-level-search-filter

- pattern-matching-subtree-search-filter

パターン一致アルゴリズムがサポートしている構文は、JavaのPatternクラス(http://java.sun.com/j2se/1.4.2/docs/api/java/util/regex/Pattern.html (http://download.oracle.com/javase/1.4.2/docs/api/java/util/regex/Pattern.html)の説明を参照)で指定されます。この構文は、通常のregex構文と同じではありません。

数値

リクエストは、リクエストのRDNの数値に応じて、データ・ビューに配布されます。数値は、データ・ビューのベースDNの下の最初のRDNの値から取得されます。数値のバウンドは、次のパラメータで定義されます。

- numeric-attrs

- numeric-default-data-view

- numeric-lower-bound

- numeric-upper-bound

辞書編集

リクエストは、リクエストのRDNの辞書編集上の値に応じて、データ・ビューに配布されます。辞書編集上のバウンドは、データ・ビューのベースDNの下の最初のRDNの値から取得されます。辞書編集上のバウンドは、次のパラメータで定義されます。

- lexicographic-attrs

- lexicographic-lower-bound

- lexicographic-upper-bound

レプリケーション

リクエストは、レプリケーションのデータ・ビューのロールに応じて、データ・ビューに配布されます。このアルゴリズムは、書込み操作をデータソース・プールのすべてのデータソースに配布し、読取り操作を1つのデータソースに配布します。レプリケーション・ロールは、replication-roleパラメータによって定義されます。データ・ビューは、マスター・ロールまたはコンシューマ・ロールを持つことができます。

また、カスタム配布アルゴリズムをサポートするようにDirectory Proxy Serverを構成することもできます。カスタム配布アルゴリズムの構成方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のカスタム配布アルゴリズムの構成方法に関する説明を参照してください。

配布アルゴリズムの構成方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の階層および配布アルゴリズムを持つデータ・ビューに関する説明を参照してください。配布アルゴリズムで使用されるパラメータの詳細は、distribution-algorithmを参照してください。

17.2.1 配布アルゴリズムの制限

Directory Proxy Serverで提供される配布アルゴリズムは、特定のリクエストのシナリオでは、一部制限があります。

次のリストは、リクエストで配布アルゴリズムが使用されない状況をまとめたものです。このリストの例は、ルーティング属性がuidで、データ・ビューのビュー・ベースがdc=example,dc=comであることを前提としています。

- 検索ベースがビュー・ベースで終わり、範囲がbaseである場合、リクエストは、常に最初のデータ・ビューに配布されます。次に例を示します。

$ ldapsearch -b "ou=people,dc=example,dc=com" -s base "uid=116352"

- 検索ベースがビュー・ベースで終わり、範囲が1つのレベルまたはサブツリーである場合、リクエストは、常に最初のデータ・ビューに配布されます。次に例を示します。

$ ldapsearch -b "ou=people,dc=example,dc=com" -s sub "uid=116352"

- 検索ベースがビュー・ベースで終わり、ルーティング属性で始まるが、検索フィルタにルーティング属性が含まれていない場合、リクエストはすべてのデータ・ビューに配布されます。次に例を示します。

$ ldapsearch -b "uid=116352",ou=people,dc=example,dc=com" -s base "objectclass=*"

この例では、RDN値がデータ・ビュー基準に一致する場合、リクエストは正しく配布されます。

- 検索ベースがビュー・ベースで終わり、ルーティング属性を含んでいるが、検索フィルタにルーティング属性が含まれていない場合、リクエストはすべてのデータ・ビューに配布されます。次に例を示します。

$ ldapsearch -b "cn=myAccount,uid=116352,ou=people,dc=example,dc=com" -s base "objectclass=*"

この例では、RDN値がデータ・ビュー基準に一致する場合、リクエストは正しく配布されます。

17.3 データ・ビューのユースケース

この項では、LDAPデータ・ビューのユースケースについて説明します。すべての例は、接続ハンドラのすべてのクライアント接続をDirectory Proxy Serverで処理できることを前提としています。

様々なデプロイメントでのデータ・ビューの例は、次の項を参照してください。

- リクエストのターゲットDNに関係なく、すべてのリクエストをルーティングするデータ・ビュー

- データと等価な複数のデータソースにサブツリー・リストが格納されている場合にリクエストをルーティングするデータ・ビュー

- 異なるサブツリーが異なるデータソースに格納されている場合に単一のアクセス・ポイントを提供するデータ・ビュー

- サブツリーの様々な部分が異なるデータソースに格納されている場合にリクエストをルーティングするデータ・ビュー

- 上位サブツリーと下位サブツリーが異なるデータソースに格納されている場合にリクエストをルーティングするデータ・ビュー

- 階層および配布アルゴリズムを持つデータ・ビュー

17.3.1 リクエストのターゲットDNに関係なく、すべてのリクエストをルーティングするデータ・ビュー

この項では、リクエストのターゲットDNに関係なく、すべてのリクエストをデータソース・プールにルーティングするデータ・ビューについて説明します。このデータ・ビューは、ルート・データ・ビューと呼ばれます。ルート・データ・ビューはDirectory Proxy Serverのインスタンスの作成時にデフォルトで作成されます。

この項の例には、同じサブツリーのセットを含む複数のデータソースが含まれています。データソースはデータと等価であり、ロード・バランシングのために1つのデータソース・プールにプールされます。データ・ビューは、" "で表されるrootDSEのベースDNを使用して構成されます。図17-3は、デプロイメントの例を示しています。

図17-3 ターゲットDNに関係なく、すべてのリクエストをデータソース・プールにルーティングするデプロイメントの例

「図17-3 ターゲットDNに関係なく、すべてのリクエストをデータソース・プールにルーティングするデプロイメントの例」の説明

データ・ビューのベースDNはrootDSEであるため、データ・ビューは、すべての使用可能なリクエストのベースDNを囲みます。すべてのリクエストは、ターゲットDNまたはデータソースにそのリクエストのエントリが含まれているかどうかに関係なく、データソース・プールに転送されます。

Directory Proxy Serverがデータソースに存在しないターゲットを持つリクエストを受け取った場合、リクエストはデータソース・プールに転送されます。リクエストに応答するデータソースはエラーを返します。

図17-3のデータ・ビューの構成方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のリクエストのターゲットDNに関係なくすべてのリクエストをルーティングするデータ・ビューに関する説明を参照してください。

17.3.2 データと等価な複数のデータソースにサブツリー・リストが格納されている場合にリクエストをルーティングするデータ・ビュー

この項では、サブツリー・リストをターゲットとするリクエストをデータと等価なデータソース・セットにルーティングするデータ・ビューについて説明します。

この項の例には、それぞれが同じサブツリーのセットを含む複数のデータソースが含まれています。データソースはデータと等価であり、ロード・バランシングのために1つのデータソース・プールにプールされます。データ・ビューは、サブツリーごとに、そのサブツリーをクライアント・リクエストに公開するように構成されます。図17-3は、デプロイメントの例を示しています。

図17-4 データと等価な複数のデータソースにサブツリー・リストが格納されている場合にリクエストをルーティングするデプロイメント例

「図17-4 データと等価な複数のデータソースにサブツリー・リストが格納されている場合にリクエストをルーティングするデプロイメント例」の説明

ターゲットDNがデータ・ビューのベースDNに対して下位である場合にのみ、リクエストはデータ・ビューに公開されます。リクエストがデータ・ビューに公開されると、リクエストは、データ・ビューによって指定されているデータソース・プールに転送されます。

リクエストのターゲットDNがいずれのデータ・ビューのベースDNに対しても下位でない場合、Directory Proxy Serverはエラーを返します。

図17-4で、dc=example1,dc=comまたはdc=example2,dc=comをターゲットとするリクエストは、データソース・プールに転送されます。Directory Proxy Serverは、dc=example1,dc=comもdc=example2,dc=comもターゲットとしないリクエストにエラーを返します。

この項のデータ・ビューの構成方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のデータと等価な複数のデータソースにサブツリー・リストが格納されている場合にリクエストをルーティングするデータ・ビューに関する説明を参照してください。

17.3.3 異なるサブツリーが異なるデータソースに格納されている場合に単一のアクセス・ポイントを提供するデータ・ビュー

この項では、Directory Proxy Serverが、複数のデータソースのデータの異なるサブツリーに単一のアクセス・ポイントを提供する方法について説明します。この項の例では、各サブツリーをクライアント・リクエストに公開するための、サブツリーのデータ・ビューが含まれます。データソース・プールは、データと等価なデータソースのセットごとに構成されます。図17-5は、デプロイメントの例を示しています。

図17-5 異なるサブツリーが異なるデータソースに格納されている場合に単一のアクセス・ポイントを提供するデプロイメント例

「図17-5 異なるサブツリーが異なるデータソースに格納されている場合に単一のアクセス・ポイントを提供するデプロイメント例」の説明

Directory Proxy Serverは、リクエストがターゲットとしているDNがデータ・ビューのベースDNに対して下位である場合、そのリクエストをデータ・ビューに公開します。リクエストがデータ・ビューに公開されると、リクエストは、データ・ビューによって指定されているデータソース・プールに転送されます。

リクエストに、データ・ビューのベースDNに対して下位でないターゲットDNがある場合、Directory Proxy Serverはエラーを返します。

図17-5で、dc=example1,dc=comをターゲットとするクライアント・リクエストは、データソース・プール1に転送され、データソース1またはデータソース1'によって処理されます。dc=example2,dc=comをターゲットとするクライアント・リクエストは、データソース・プール2に転送され、データソース2またはデータソース2'によって処理されます。Directory Proxy Serverは、dc=example1,dc=comもdc=example2,dc=comもターゲットとしないクライアント・リクエストにエラーを返します。

データ・ビューを構成して単一のアクセス・ポイントを複数のデータソースに格納されている異なるサブツリーに提供する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の異なるサブツリーが異なるデータソースに格納されている場合に単一のアクセス・ポイントを提供するデータ・ビューに関する説明を参照してください。

17.3.4 サブツリーの様々な部分が異なるデータソースに格納されている場合にリクエストをルーティングするデータ・ビュー

この項では、Directory Proxy Serverが、複数のデータソースに格納されているサブツリーの様々な部分に単一のアクセス・ポイントを提供する方法について説明します。サブツリーの様々な部分のリクエストをルーティングするために、Directory Proxy Serverは配布アルゴリズムを使用します。この項の例では、Directory Proxy Serverは、数値の配布アルゴリズムを使用します。配布アルゴリズムの詳細は、「異なるデータ・ビューへのサブツリーのエントリの配布」を参照してください。

この項の例には、同じベースDNを持つ2つのデータ・ビューが含まれています。数値配布アルゴリズムを使用して、エントリを異なるデータ・ビューに分割します。データソース・プールは、データと等価なデータソースのセットごとに構成されます。図17-6は、デプロイメントの例を示しています。

図17-6 サブツリーの様々な部分が異なるデータソースに格納されている場合にリクエストをルーティングするデプロイメントの例

「図17-6 サブツリーの様々な部分が異なるデータソースに格納されている場合にリクエストをルーティングするデプロイメントの例」の説明

Directory Proxy Serverは、次の条件を満たすデータ・ビューにリクエストを公開します。

- リクエストがターゲットとするDNがデータ・ビューのベースDNに対して下位である

- リクエストのパラメータが、データ・ビューの配布アルゴリズムで指定されているパターンに一致する

リクエストがデータ・ビューに公開されると、リクエストは、データ・ビューによって指定されているデータソース・プールに転送されます。

リクエストがいずれのデータ・ビューの条件にも一致しない場合、Directory Proxy Serverは、エラーを返します。

データ・ビューを構成して単一のアクセス・ポイントを複数のデータソースのサブツリーの様々な部分に提供する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のサブツリーの様々な部分が異なるデータソースに格納されている場合に単一のアクセス・ポイントを提供するデータ・ビューに関する説明を参照してください。

17.3.5 上位サブツリーと下位サブツリーが異なるデータソースに格納されている場合にリクエストをルーティングするデータ・ビュー

この項では、上位サブツリーと下位サブツリーが異なるデータソースに格納される場合に、Directory Proxy Serverが単一のアクセス・ポイントを提供する方法について説明します。

Directory Proxy Serverでは、デフォルトでexcluded-subtreesとalternate-search-base-dnプロパティが自動的に設定されます。ただし、excluded-subtreesとalternate-search-base-dnプロパティの自動管理は無効化できます。excluded-subtreesおよびalternate-search-base-dnプロパティを手動で構成する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のexcluded-subtreeおよびalternate-search-base-dnプロパティを手動で構成する方法に関する説明を参照してください。

図17-7の例には、3つのデータ・ビューが含まれています。dataview-1のベースDNは、dataview-2およびdataview-3のベースDNよりも上位です。

dataview-1のexcluded-subtreesプロパティは、dataview-1からdataview-2およびdataview-3を除外します。dataview-2およびdataview-3のalternate-search-base-dnプロパティには、dataview-1をターゲットとする検索操作にdataview-2およびdataview-3が含まれます。図17-7は、デプロイメントの例を示しています。

図17-7 上位サブツリーと下位サブツリーが異なるデータソースに格納されている場合にリクエストをルーティングするデプロイメント例

「図17-7 上位サブツリーと下位サブツリーが異なるデータソースに格納されている場合にリクエストをルーティングするデプロイメント例」の説明

Directory Proxy Serverは、次の条件を満たすデータ・ビューにリクエストを公開します。

- リクエストがターゲットとするDNがデータ・ビューのベースDNに対して下位である

- リクエストがターゲットとするDNは、excluded-subtreesパラメータによってデータ・ビューから除外されない

リクエストがデータ・ビューに公開されると、リクエストは、データ・ビューによって指定されているデータソース・プールに転送されます。

リクエストがいずれのデータ・ビューの条件にも一致しない場合、リクエストはデータ・ビューに公開できず、Directory Proxy Serverはエラーを返します。

図17-7で、dc=example,dc=comをターゲットとするが、ou=computer, dc=example, dc=comまたはou=people, dc=example, dc=comをターゲットとしないクライアント・リクエストは、データソース・プール1に転送されます。このようなリクエストは、データソース1またはデータソース1'によって処理されます。ou=computer, dc=example, dc=comまたはou=people, dc=example, dc=comをターゲットとするクライアント・リクエストは、それぞれデータソース・プール2およびデータソース3に転送されます。Directory Proxy Serverは、dc=example,dc=comをターゲットとしないクライアント・リクエストにエラーを返します。

サブツリー検索が上位データ・ビューをターゲットとすると、検索範囲は下位データ・ビューになります。この例で、3つのすべてのデータ・ビューが、dc=example,dc=comをターゲットとする検索操作の候補となります。一部の特定のケースでは、検索範囲がこのように拡大しないほうが便利な場合があります。この検索範囲の拡大を防ぐには、下位データ・ビューをその親データ・ビューから切断する必要があります。デフォルトでは、Directory Proxy Serverは、connect-to-parentパラメータをtrueに設定して、自動的に下位データ・ビューをそれらの各親に接続します。データ・ビューをその親から切断する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の階層および配布アルゴリズムを持つデータ・ビューに関する説明を参照してください。

データ・ビューを構成して単一のアクセス・ポイントを複数のデータソースのサブツリーの様々な部分に提供する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の上位サブツリーおよび下位サブツリーが異なるデータソースに格納されている場合に単一のアクセス・ポイントを提供するデータ・ビューに関する説明を参照してください。

17.3.6 階層および配布アルゴリズムを持つデータ・ビュー

同じトポロジに様々なデータ・ビューを使用して、サブツリーの部分を公開したり非表示にしたりできます。図17-8は、図17-7で示されている階層を図17-6で示されている配布アルゴリズムを組み合せたデータ・ビューの例です。

図17-8の例には、4つのデータ・ビューが含まれています。データ・ビュー1のベースDNは、他のデータ・ビューのベースDNより優先されます。データ・ビュー3とデータ・ビュー4は、同じベースDNを持っているが、数値の配布アルゴリズムは、エントリを異なるデータ・ビューに分割します。図17-8は、デプロイメントの例を示しています。

図17-8 階層および配布アルゴリズムを持つデータ・ビューの例

「図17-8 階層および配布アルゴリズムを持つデータ・ビューの例」の説明

dataview-1のexcluded-subtreesプロパティは、dataview-1から他のデータ・ビューを除外します。dataview-2、dataview-3およびdataview-4のalternate-search-base-dnプロパティには、dataview-1をターゲットとする検索操作にこれらのデータ・ビューが含まれます。

Directory Proxy Serverは、次の条件を満たすデータ・ビューにリクエストを公開します。

- リクエストがターゲットとするDNがデータ・ビューのベースDNに対して下位である

- リクエストがターゲットとするDNは、excluded-subtreesパラメータによってデータ・ビューから除外されない

- リクエストのパラメータが、配布アルゴリズムで指定されているパターンに一致する

リクエストがデータ・ビューに公開されると、リクエストは、データ・ビューによって指定されているデータソース・プールに転送されます。

リクエストがいずれのデータ・ビューの条件にも一致しない場合、Directory Proxy Serverは、エラーを返します。

複雑なデータ・ビューの構成方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の階層および配布アルゴリズムを持つデータ・ビューに関する説明を参照してください。

18 Directory Proxy Serverの仮想化

Directory Proxy Serverでは仮想データ・ビューの定義によって仮想化を実現しています。仮想データ・ビューではユーザーが物理データを違った方法で表示することができます。この章では仮想データ・ビューの作成方法と、Directory Proxy Serverで使用可能な仮想データ・ビューの種類について説明します。

この章の内容は次のとおりです。

- 仮想データ・ビューの構造

- 仮想データの変換

- 仮想データ・ビューの追加プロパティ

- 結合データ・ビュー

- コーディネータ・データ・ビュー

- LDIFデータ・ビュー

- JDBCデータ・ビュー

- 仮想データ・ビューのアクセス制御

- 仮想スキーマのチェック

- 仮想データ・ビューおよびLDAPグループ

18.1 仮想データ・ビューの構造

仮想データ・ビューは基本的には、特定の変換アクションが定義された物理データ・ビューです。変換アクションはリアルタイムで行われ、仮想データ・ビューが作成されます。次の図は、仮想データ・ビューを作成するために、物理データ・ビューで変換アクションが定義される方法を示しています。

図18-1 仮想データ・ビュー

「図18-1 仮想データ・ビュー」の説明

変換アクションに加えて、特定のプロパティをデータ・ビューで定義でき、これにより、そのデータ・ビューでデータが管理される方法を制限します。仮想データ・ビューの追加プロパティについては、「仮想データ・ビューの追加プロパティ」で説明します。

注意:

仮想データ・ビューはパフォーマンスへの影響を暗黙的に意味します。パフォーマンスへの影響の大きさは、物理データ・ソースのサイズ、変換アクションの複雑さおよび使用する仮想ACIの複雑さなど、複数の要因に応じて異なります。

18.2 仮想データの変換

仮想データ変換により、物理データ・ビューから仮想データ・ビューが作成されます。実質的には、ユーザーが仮想データ・ビューを定義することはありません。かわりに、必要な変換を指定し、これらを既存の物理データ・ビューで定義します。変換により、特定のアクションが特定の方向で実行されます。変換の方向により、変換モデルが決定されます。仮想データ変換を定義する場合、仮想データ・ビューのコンテキストでのみに存在する仮想属性を作成します。

次のようにdpconfコマンドを使用して、変換がデータ・ビューで定義されます。

$ dpconf add-virtual-transformation -h host -p port -D bindDN /
view-name model action attr-name [parameters...]

view-nameは、変換が定義されるデータ・ビューのことです。attr-nameは作成される仮想属性のことです。モデル、アクションおよび追加パラメータについては以降の各項で説明します。

仮想変換の名前は次のコマンドを使用して設定できます。

$ dpconf set-virtual-transformation-prop -h host -p port -D bindDN /
view-name transformation-name property:value [property:value]

18.2.1 変換モデル

変換モデルは変換の方向、つまり、変換がリクエスト時に適用されるか、レスポンス時に適用されるか、または両方で適用されるかにより決まります。

この意味で、変換は次のタイプに分類できます。

- マッピング変換(双方向変換)

- 書込み変換(インバウンド変換)

- 読取り変換(アウトバウンド変換)

18.2.1.1 マッピング変換

最も一般的な変換は双方向(マッピング)変換です。マッピング変換はリクエスト時に適用され、その逆はレスポンス時に適用されます。これらの変換は、実際には物理データ・ビューの属性やエントリが仮想データ・ビューの属性やエントリにマップされるため、マッピングと呼ばれます。マッピング変換では、既存の値をDNコンポーネント、属性タイプまたは値、あるいはオブジェクト・クラスに割り当てる前に、それらの値を処理することができます。

次の図は、マッピング変換のプリンシパルを表しています。

図18-2 マッピング変換

「図18-2 マッピング変換」の説明

マッピング変換は、次のようにdpconfコマンドを実行することにより、データ・ビューで定義されます。

$ dpconf add-virtual-transformation -h host -p port -D bindDN /
view-name mapping action attr-name [parameters]

次の検索フィルタ・コンポーネントがサポートされています。

- 単一の属性とともに仮想属性composeが含まれている、すべてのsubstringまたはpresence検索フィルタ。

- 1つ以上の属性とともに仮想属性composeが含まれている、すべてのequality検索フィルタ。

注意: マッピング変換を作成するときには、次の制限が適用されます。

- constantまたはmacro(split、substring、increment、decrement)パラメータ値を持つ仮想属性が含まれている検索フィルタは、サポートされていません。

- 複数の仮想属性が含まれているsubstringまたはpresence検索フィルタ・コンポーネントはサポートされていません。

例18-1 マッピング変換を使用する場合

たとえば、属性surnameおよびgivenameを持つエントリが含まれている物理データ・ソースをある組織が持っているとします。この組織には、形式givenname surnameのcn (共通名)属性を持つエントリを必要とするクライアント・アプリケーションがあります。

クライアント・アプリケーションは形式cn=Carlos Fuentesのエントリーを求める検索リクエストを送信します。このリクエスト時に氏名を抽出し、リクエストをsurname=Fuentes, givenname=Carlos形式の1つに変換する変換が定義されます。対応するエントリはデータ・ソースにあります。このエントリをクライアント・アプリケーションに戻す前に、逆の変換が実行されます。クライアント・アプリケーションは、理解できる形式であるcn=Carlos Fuentesでエントリを受信します。

このリクエストは形式surname=Fuentes, givenname=Carlosに変換されます。同様に、クライアント・アプリケーションはエントリのcn属性をLisa Davisに変更する変更リクエストを送信します。このリクエストは、物理エントリのgivenname属性がLisaに変更され、surname属性がDavisに変更されるように、変換されます。

18.2.1.2 書込み変換

書込み変換はリクエスト時に適用されますが、レスポンス時には適用されません。書込み変換はストレージ内の物理データを変更します。

次の図は書込み変換のプリンシパルを表しています。

図18-3 書込み変換

「図18-3 書込み変換」の説明

次のようにdpconfコマンドを使用して、書込み変換がデータ・ビューで定義されます。

$ dpconf add-virtual-transformation -h host -p port -D bindDN /
view-name write action attr-name [parameters]

例18-2 書込み変換を使用する場合

ある組織に、データ・ソースに個人エントリを追加する機能を持つレガシー・アプリケーションがあるとします。このアプリケーションはtelephoneNumber属性を持たないエントリを追加します。物理データ・ソースは更新されており、今ではtelephoneNumberが個人エントリの必須属性になっています。ここで必要な変換は、追加リクエスト時にtelephoneNumber属性を追加することです。この変換はデータベースに書き込まれるエントリを変更します。逆の変換は必要ありません。

18.2.1.3 読取り変換

読取り変換は、リクエストに対するレスポンス時にのみ適用されます。リクエスト時には変換は適用されず、物理データは変更されません。

次の図は、読取り変換のプリンシパルを表しています。

図18-4 読取り変換

「図18-4 読取り変換」の説明

次のようにdpconfコマンドを使用して、読取り変換がデータ・ビューで定義されます。

$ dpconf add-virtual-transformation -h host -p port -D bindDN /
view-name read action attr-name parameters

例18-3 読取り変換を使用する場合

ある組織に、個人エントリを表示する機能を持つレガシー・アプリケーションがあるとします。このアプリケーションは、mail属性を含んでいないエントリをサポートしていません。物理データ・ソースは更新されており、email属性はもう個人エントリに存在していません(電子メール・アドレスは、他の属性を使用して構成されます)。

ここで必要な変換は、検索レスポンス時にmail属性を追加することです。この変換はデータベースから読み取られたエントリを変更し、mail属性(値は、givenname.surname@example.com)を追加します。逆の変換は必要なく、物理データは変更されません。

上記の変換の場合、mail属性は検索リクエスト・フィルタで意味がないことに気を付けてください。検索リクエスト・フィルタには物理的な属性が含まれている必要があります。

18.2.2 変換アクション

変換アクションは、ターゲット・エントリに対して変換が何を行うかを記述します。次の変換アクションが考えられます。

- 属性の構成。このアクションにより、ユーザーは物理データ・ソースには実際に存在していないが、クライアント・アプリケーションに必要な仮想属性を構成できます。このアクションを使用して、物理データ・ソースに必要な属性を構成するための追加または修正リクエストを変更することもできます。
属性を構成するには、add-attr変換アクションを使用します。

- 属性の削除。このアクションにより、ある属性が物理データ・ソースでスキーマにより許可されていない場合に、ユーザーがその属性をクライアント・リクエストから削除できます。クライアント・アプリケーションがその属性を必要としない場合は、クライアント・アプリケーションに送信されたレスポンスから、このアクションを使用して属性を削除することもできます。
属性を削除するには、remove-attr変換アクションを使用します。

- 属性値の構成。このアクションにより、ユーザーは他の属性値からある属性値を作成できます。
属性値を作成するには、add-attr-value変換アクションを使用します。

- 属性値の削除。このアクションにより、ユーザーは属性から値を削除できます。これは通常、クライアント・アプリケーションまたはデータ・ソース・スキーマが複数値属性を許可していない場合に、複数値属性から1つ以上の値を削除するために使用されます。
属性値を削除するには、remove-attr-value変換アクションを使用します。

- 属性にデフォルト値を追加する。このアクションでは、属性に値が存在していない場合、デフォルト値を追加できます。
デフォルト値を属性に追加するには、def-value変換アクションを使用します。

- 1つの属性値を別の属性値にマップする。このアクションでは、属性がデータ・ソースに書き込まれるか、クライアント・アプリケーションに返されるかに応じて、ある属性に対して2つの異なる値を持つことができます。
属性値をマップするには、attr-value-mapping変換アクションをinternal-valueパラメータおよびview-valueパラメータとともに使用します。

注意:

Directory Proxy Serverでは、単純な属性マッピングと仮想変換によるマッピングという、属性値をマッピングする2つの方法がサポートされています。一般に、属性マッピングは構成がより簡単で、パフォーマンスの点でも若干の利得があります。詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の属性とDNの名前変更に関する説明を参照してください。

変換アクションの結果は変換モデルに応じて異なります。

18.2.3 変換パラメータ

変換パラメータは仮想属性の値を提供します。この値はデフォルト値か、または他の属性値から値を作成するルールであることが可能です。

次の変換パラメータが受け入れられます。

- value。このパラメータは、attr-value-mappingアクション以外の、属性値を追加するすべての変換アクションに適用されます。

- internal-value:value。このパラメータは、attr-value-mappingアクションとremove-attr-valueアクション(mappingモデルで使用される場合)にのみ適用されます。これは、物理データ・ソースに書き込まれる、または物理データ・ソースから読み取られる属性の値を説明します。

- view-value:value。このパラメータは、attr-value-mappingアクションとremove-attr-valueアクション(mappingモデルで使用される場合)にのみ適用されます。これは、クライアント・アプリケーションに返されるまたは、クライアント・アプリケーションにより送信される属性の値を説明します。

変換パラメータは次の構文をとります。

- 定数。静的なデフォルト値を持つ属性の生成に使用されます。
たとえば、デフォルトの電話番号を指定するにはパラメータ0800-5994654が使用される場合があります。

このパラメータはマッピング変換についてはサポートされていません。

- 属性値。処理されるエントリの既存の属性から新しい属性を作成するために使用されます。
たとえば、パラメータ\${cn}は、新しい属性の値をcn属性の値からとる必要があることを指定します。$の前にはエスケープ文字が必要です。

- 定数および属性値。既存の属性と静的な値を組み合せることにより、新しい属性を作成するために使用されます。
たとえば、パラメータ\${cn}@example.comは、新しい属性の値をcn属性の値および静的なドメイン名からとる必要があることを指定します。

- マクロ。既存の属性の値を操作することにより、属性を作成するために使用されます。
このパラメータはマッピング変換についてはサポートされていません。

マクロはJava正規表現です。Java正規表現の詳細は、http://download.oracle.com/docs/cd/E17476_01/javase/1.4.2/docs/api/java/util/regex/Pattern.htmlを参照してください。

次のマクロがサポートされています。

- 属性値の一定量の増加:

increment(source-attribute-value,increment)

たとえば、マクロincrement(\$(uid),10)は、エントリに存在するuid属性の値に10を加えることにより、新しい属性の値を取得することを指定します。

- 属性値の一定量の減少:

decrement(source-attribute-value,decrement)

たとえば、マクロdecrement($(uid),10)は、エントリに存在するuid属性の値から10を引くことにより、新しい属性の値を取得することを指定します。

- 既存の属性値の一部を使用:

substring(source-attribute-value,begin-index[,end-index])

begin-indexではその値も含まれ、end-indexではその値が除外されます。つまり、サブストリングはbegin-indexで指定された文字で始まり、end-indexの直前の文字で終了します。

たとえば、値がcn属性の値から始めの2つの文字を引いたものである新しい属性を作成するには、次のマクロを定義します。

substring(\${cn},2)

値が、cn属性の値の初めの2文字のみを含む新しい属性を作成するには、次のマクロを定義します。

substring(\${cn},0,2)

- 値を特定の場所で分割して、既存の属性値の一部を使用:

split(source-attribute-value,token-index,regular-expression)

たとえば、マクロsplit\(\${mail},1,"@"\)はドメインを返します。

注意:

変換パラメータの構文は、結合データ・ビューのコンテキストで使用する場合は少し異なります。詳細は、「結合データ・ビューの仮想データ変換」を参照してください。

18.2.4 変換の例

次の各項では、仮想データ・ビューが必要なユースケース、およびこのユースケースを実装するために必要な変換モデルとアクションの組合せについて説明します。

例18-4 ADAMオブジェクト・クラスのLDAP準拠への適合

会社Example Aは、ユーザーをLDAPディレクトリに格納しています。Example Aは別の会社、Example Bを買収しますが、この会社はユーザーをADAMディレクトリに格納しています。

Example AのLDAPディレクトリで、ユーザーはinetOrgPersonとして保管されます。Example Bのディレクトリでは、ユーザーはuserとして保管されます。このため、ADAMのuserオブジェクト・クラスをLDAPのinetOrgPersonオブジェクト・クラスにマップする変換が必要です。

次の変換がExample Aのディレクトリの物理データ・ビューで定義されます。

$ dpconf add-virtual-transformation -h myHost -p 2389 -D "cn=Proxy Manager" \
exampleB-view-name mapping attr-value-mapping objectclass internal-value:user \
view-value:inetOrgPerson

例18-5 書込み変換による属性の構成

Example Aはユーザー・エントリをそのディレクトリに保管します。すべてのユーザー・エントリにはmail属性が必要です。mail属性のないユーザー・エントリが追加されると、スキーマ違反エラーが返されます。Example Aには、ユーザー・エントリをディレクトリに追加するクライアント・アプリケーションがあります。一部のユーザー・エントリにはmail属性が含まれておらず、クライアント・アプリケーションはその属性を生成できません。ユーザー・エントリ追加時のスキーマ違反を回避するには、追加リクエストにmail属性を追加する変換を定義します。mail属性の値はクライアントの追加リクエストで指定されるuidから取得し、これに@example.comを付加します。

次の図は、追加リクエストで発生する変換を示しています。

図virtualtransform3.pngの説明

この変換は、次のdpconfコマンドを使用することにより、物理データ・ビューで定義されます。

$ dpconf add-virtual-transformation -h myHost -p 2389 -d "cn=Proxy Manager" \
exampleA-view-name write add-attr mail \${uid}@example.com

このコマンドで、\${uid}は、そのエントリのuid属性の値を意味します。

例18-6 読取り変換による属性の構成

Example Aは、ディレクトリにユーザーのメール・アドレスを保管していません。しかし、新しいクライアント・アプリケーションでは、ユーザー・エントリーとともにユーザーのメール・アドレスを返すことが必要です。

会社内のすべてのメール・アドレスは、firstname.lastname@example.comという書式をとります。この組織は、mail属性を各ユーザー・エントリに読取り専用で追加する、仮想ビューを定義します。mail属性の値は、ユーザー・エントリにすでに存在しているgivenName属性およびsn属性の値から生成されます。

次の図は、検索でユーザーのエントリが返されるときにユーザーのエントリで発生する変換を示しています。

図virtualtransform2.pngの説明

この変換は、次のdpconfコマンドを使用することにより、物理データ・ビューで定義されます。

$ dpconf add-virtual-transformation -h myHost -p 2389 -d "cn=Proxy Manager" \
exampleA-view-name read add-attr mail \${givenname}.\${sn}@example.com

例18-7 デフォルト属性値の追加

Example Aは、そのディレクトリに多くの製品を保管しています。過去には、それぞれの製品が1人のサポート・スタッフ(その製品についてのすべてのサポート・コールを処理する社員)と関連付けられていました。したがって、物理データ・ストアでは各製品がsupportPerson属性と関連付けられており、その値はその会社の社員のDNです。

同社ではサポート照会のビジネス・プロセスを変更し、すべての製品に関する問合せを中央のホットラインに送ることになりました。物理データを変更せずにこの変更を処理するために、会社ではすべての製品エントリがsupportPerson属性を持たないが、かわりにhotline属性を持つ仮想データ・ビューを定義します。hotline属性の値は、すべての製品について同じ数字である0800です。

次の図は、検索で返されるときに製品エントリで発生する変換を示しています。

図virtualtransform.pngの説明

この変換は、次のdpconfコマンドを使用して物理データ・ビューで定義されます。

$ dpconf add-virtual-transformation -h myHost -p 2389 -d "cn=Proxy Manager" \
exampleA-view-name read remove-attr supportPerson
$ dpconf add-virtual-transformation -h myHost -p 2389 -d "cn=Proxy Manager" \
exampleA-view-name read add-attr hotline "0800755 8625"

例18-8 仮想変換を使用したDNの名前変更

Example Aには、オブジェクト・クラスに従ってエントリをソートする必要があるクライアント・アプリケーションがあります。

これを実行するために、Example Aでは、エントリがその特定のクライアント・アプリケーションに返されるときには常にそのエントリのRDNを書き変え、cnとともにエントリのオブジェクト・クラスを含めるという仮想変換を定義します。

次の変換がExample Aのディレクトリの物理データ・ビューで定義されます。

$ dpconf add-virtual-transformation -h myHost -p 2389 -d "cn=Proxy Manager" \
exampleB-view-name mapping attr-value-mapping dn internal-value:cn=\${cn} \
view-value:cn=\${cn},objectclass=\${objectclass}

18.3 仮想データ・ビューの追加プロパティ

前述の変換アクションに加えて、特定のプロパティをデータ・ビューで定義でき、これにより、そのデータ・ビューでデータが管理される方法を制限します。これらのプロパティは基本的に、仮想データ・ビューを介して読取りまたは変更できる属性のリストを提供します。

制限された仮想データ・ビューを表示するために、次の追加プロパティをデータ・ビューで定義できます。

- 表示できない属性。このデータ・ビューを介して読み取ることができない属性のリストです。このリストは、複数値プロパティnon-viewable-attrをデータ・ビューに追加することにより、指定されます。このプロパティは、読み取ることができない属性の数が少ない場合に使用する必要があります。

- 書込みできない属性。このデータ・ビューを介して追加または変更することができない属性のリストです。このリストは、複数値プロパティnon-writable-attrをデータ・ビューに追加することにより、指定されます。このプロパティは、追加または変更できない属性の数が少ない場合に使用する必要があります。

- 表示可能な属性。このデータ・ビューを介して読み取ることができる属性のリストです。このリストは、複数値プロパティviewable-attrをデータ・ビューに追加することにより、指定されます。このプロパティは、読み取ることができる属性の数が少ない場合に使用する必要があります。

- 書込み可能な属性。このデータ・ビューを介して追加または変更できる属性のリストです。このリストは、複数値プロパティwritable-attrをデータ・ビューに追加することにより、指定されます。このプロパティは、追加または変更できる属性の数が少ない場合に使用する必要があります。

表示できない属性と表示できる属性は相互に排他的です。同様に、書込みできない属性と書込みできる属性も相互に排他的です。

18.4 結合データ・ビュー

結合データ・ビューは複数のデータ・ビューを集約したものです。Directory Proxy Serverの現在のリリースでは、2つのデータ・ビューの1つの結合データ・ビューへの集約がサポートされています。

結合データ・ビューは、結合データ・ビューの名前と、集約される2つの既存のデータ・ビューを指定することにより作成されます。これら既存のデータ・ビューの1つはプライマリ・データ・ビューとみなされ、もう一方のデータ・ビューはセカンダリ・データ・ビューとみなされます。結合データ・ビューを作成する前に、データが集約される方法を決定するルールをセカンダリ・データ・ビューに対して構成する必要があります。

次の図は、プライマリ・データ・ビューとセカンダリ・データ・ビューを集約して1つの結合データ・ビューを形成する様子を示しています。

図joindview.pngの説明

18.4.1 プライマリ・データ・ビューとセカンダリ・データ・ビュー

結合データ・ビューのソースを階層的に編成することにより、Directory Proxy Serverではプライマリ・データ・ビューおよびセカンダリ・データ・ビューのデータが一致しない場合のデフォルトの決定を行うことができます。

プライマリ・データ・ビューは結合データ・ビューの存在を制御します。セカンダリ・データ・ビューはこのエントリ・リストの補助データを提供します。言い換えれば、あるエントリがセカンダリ・データ・ビューには存在するがプライマリ・データ・ビューには存在しない場合、そのエントリは結合データ・ビューに表示されません。

デフォルトでは、プライマリ・データ・ビューが権限を持つソースです。ある属性が両方のソース・データ・ビューにあるが、それぞれが違う値の場合、複数値属性が返されます。ただし、この動作は構成可能です。たとえば、プライマリ・データ・ビューの値のみを受け入れる、またはセカンダリ・データ・ビューの値のみを受け入れるように選択できます。

18.4.2 セカンダリ・データ・ビューの追加プロパティ

「仮想データ・ビューの追加プロパティ」で説明した仮想データ・ビューのプロパティに加えて、セカンダリ・データ・ビューのみに特定のプロパティを定義できます。これらのプロパティは、2つのビューのデータが集約される方法およびデータ・ビューへのリクエストが処理される方法を決定します。次の各項ではこれらの追加プロパティについて説明します。

18.4.2.1 結合ルール

結合ルールは、セカンダリ・データ・ビューのエントリがプライマリ・データ・ビューのエントリに関連する方法を決定します。結合ルールはセカンダリ・データ・ビューでは必須ではありません。ただし、結合ルールが定義されていないと、LDAP操作時にセカンダリ・データ・ビューへの問合せは行われません。Directory Proxy Serverには、DN結合ルールおよびフィルタ結合ルールの、2つのタイプの結合ルールが用意されています。

18.4.2.1.1 DN結合ルール

DN結合ルールはセカンダリ・データ・ビューでのエントリのDNを決定します。DN結合ルールは、dn-join-ruleプロパティを使用してセカンダリ・データ・ビューで構成されます。セカンダリ・データ・ビューに構成できるDN結合ルールは1つだけです。DN結合ルールをデータ・ビューに構成した場合、そのデータ・ビューにはフィルタ結合ルールを構成できません。

DN結合ルールにはDN構文があり、次の形式のいずれかをとることができます。

- セカンダリ・エントリのDNは、プライマリ・エントリの属性から構成されます。
たとえば、次のDN結合ルールは、セカンダリ・データ・ビューのエントリのDNにプライマリ・データ・ビューのcnが含まれ、これにou=peopleのサフィックスが付いている必要があることを規定しています。

cn=\${primary-data-view.cn},ou=people

DNにはセカンダリ・データ・ビューのベースDNが含まれていてはいけません。その意味で、これは相対DNです。

- セカンダリ・エントリのDNはプライマリ・エントリのDNと同じです。
このような結合ルールの構文は次のとおりです。

\${primary-data-view.dn}

この場合、ベースDN下のプライマリおよびセカンダリDNの部分は、完全DNが異なっている場合でも同一です。たとえば、プライマリ・データ・ビューのベースDNがo=primaryで、セカンダリ・データ・ビューのベースDNがo=secondaryである場合を想定します。結合ルール\${primary-data-view.dn}は、ベースDN下のDITが同一であることを意味します。このため、エントリuid=1,o=secondaryはuid=1,o=primaryと関連付けられます。

18.4.2.1.2 フィルタ結合ルール

フィルタ結合ルールは、プライマリ・データ・ビューとセカンダリ・データ・ビュー間の関係を定義します。フィルタ結合ルールは、filter-join-ruleプロパティを使用してセカンダリ・データ・ビューで構成されます。このルールは、プライマリ・データ・ビューの何かに基づいてセカンダリ・データ・ビューからエントリが取得される方法を示します。

セカンダリ・データ・ビューに構成できるフィルタ結合ルールは1つだけです。フィルタ結合ルールをデータ・ビューに構成した場合、そのデータ・ビューにはDN結合ルールを構成できません。フィルタ結合ルールは、プライマリ・データ・ビューの1つ以上の属性からある属性を構成するために使用するフィルタの形をとります。

たとえば次のフィルタ結合ルールは、プライマリ・データ・ビューのエントリuidがセカンダリ・データ・ビューのエントリuidに一致した場合に、エントリが取得されることを規定しています。

uid=\${primary.uid}

18.4.2.2 共有エントリの処理

contains-shared-entriesプロパティは、セカンダリ・データ・ビューのエントリがプライマリ・データ・ビィーの複数のエントリにより使用されている場合に、何が実行されるかを決定します。

たとえば、プライマリ・データ・ビューにユーザー・エントリのリストが含まれており、セカンダリ・データ・ビューに部門番号のリストが含まれている場合を想定します。セカンダリ・データ・ビューの1つの部門番号は、プライマリ・データ・ビューの複数のユーザーに適用される可能性があります。プライマリ・データ・ビューからあるユーザーが削除された場合、セカンダリ・データ・ビューからそのユーザーの部門番号を必ずしも削除する必要がないことがあります。

contains-shared-entriesプロパティはセカンダリ・データ・ビューに設定されます。このプロパティはデフォルトでTRUEに設定されています。これは、プライマリ・データ・ビューのエントリを削除することで、セカンダリ・データ・ビューの共有エントリが削除されることはないことを意味します。プライマリ・データへエントリを追加すると、セカンダリ・データ・ビューにまだそのエントリが存在していない場合にのみセカンダリ・データ・ビューにそのエントリが追加されます。

18.4.2.3 バインドの処理

process-bindプロパティは、バインドをセカンダリ・データ・ビューに対して実行できるかどうかを指定します。

デフォルトで、プライマリ・データ・ビューではバインドが許可され、セカンダリ・データ・ビューでは許可されていません。process-bindプロパティはデフォルトでは設定されていません。このプロパティをセカンダリ・データ・ビューでtrueに設定した場合、バインドはそのデータ・ビューで許可されます。

18.4.3 Directory Proxy Serverが結合データ・ビューで読取りおよび書込み操作を処理する方法

属性がプライマリ・データ・ビューとセカンダリ・データ・ビューの両方に存在している場合、その属性の値は結合データ・ビューによってマージされます。読取り操作の場合、これは、両方のデータ・ビューからの値を持つ複数値属性が返されるっことを意味します。書込み操作の場合、プロキシが両方のデータ・ビューに問合せを行い、書込み操作の内容に基づいて値を書き込む場所を決定します。

追加操作時にあるバックエンド・データ・ソースに障害が発生した場合、Directory Proxy Serverは自動ロールバックを実行します。ロールバックは、障害が発生しなかったデータ・ソースでの削除操作の形式をとります。これにより、2つのデータ・ソース間のデータの一貫性が確保されます。ロールバックを実行できない場合はエラーが記録され、オプションで管理アラートが発行されます。自動ロールバックはデフォルトで有効になっています。自動ロールバックは、revertAddOnFailure属性をoff (直接cn=configで)に設定することにより構成できます。

削除操作時にあるバックエンド・データ・ソースに障害が発生した場合、ロールバックは実行されません。エラーが記録され、オプションで管理アラートが発行されます。

18.4.4 結合データ・ビューの仮想データ変換

各種の仮想データ変換は「仮想データの変換」で説明されています。変換パラメータの構文は、データ変換が結合データ・ビューで定義されている場合は少し異なります。属性が複数のデータ・ビューから取得されるため、属性の内容を定義する変数は完全修飾パスである必要があります。つまり、ソースの属性値には、その属性の取得元であるデータ・ビューの名前が含まれている必要があります。

たとえば、次のパラメータはプライマリ・データ・ビューとセカンダリ・データ・ビューの両方の既存の属性から属性を作成します。

\${primaryDataView.firstName}.\${secondaryDataView.lastName}@\${primaryDataView.domainName}

firstNameおよびdomainName属性はプライマリ・データ・ビューから取得され、lastName属性はセカンダリ・データ・ビューから取得されます。

18.5 コーディネータ・データ・ビュー

コーディネータ・データ・ビューは、一連のデータ・ビューを単一のデータ・ビューのように表示できるようにグループ化します。このグループ化によって、ユーザーはそれぞれのエントリがどこに格納されているかを知らなくても、1つの操作で別々のデータ・ビューに格納されているエントリにアクセスできます。このデータ・ビューは、各エントリがどこに格納されているかを自動的に検出し、それらに対する操作を実行します。

18.5.1 コーディネータ・データ・ビューの機能

- 2つの異なるソースのエンティティが1つのネームスペースに統合される場合、別々のデータ・ソースにまだ格納されているエントリの場所指定するために分散アルゴリズムが使用されることはありません。

- 名前付きサービスがディレクトリ・サーバーの階層によってデプロイされるとき、問合せではまずローカル・サーバーがヒットします。一致するエントリが見つからない場合、クエリはよりグローバルなサーバーにアクセスします。

- データが複数のデータ・ビューに分散されている場合、コーディネータ・データ・ビューは分散されたデータ・ビューをグループ化してそれが単一のデータ・ビューとして表示されるようにし、そのビューはさらに結合データ・ビューのプライマリ・データ・ビューまたはセカンダリ・データ・ビューとして使用できます。このように、コーディネータ・データ・ビューではエントリの集約と分散が可能です。

- 問合せで分散キーが使用できない場合、コーディネータ・データ・ビューはリクエストを分散データ・ビューにルーティングし、その分散データ・ビューはさらに分散データ・ビュー間のルーティングを繰り返してエントリを探します。

すべての構成の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のコーディネータ・データ・ビューの作成および構成に関する説明を参照してください。

18.6 LDIFデータ・ビュー

LDIFデータ・ビューは、LDIFファイルがLDAPデータ・ソースのように見える単純な仮想データ・ビューです。LDIFデータ・ビューは、次のようにdpconfコマンドを使用して定義されます。

dpconf create-ldif-data-view VIEW_NAME LDIF_FILE_NAME SUFFIX_DN

追加の変換は必要ありません。Directory Proxy Serverは、クライアント・アプリケーションに対してLDIFデータがLDAPデータのように見えるようにするために必要な変換を自動的に実行します。

LDIFデータ・ビューの作成および構の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のLDIFデータ・ビューの作成および構成に関する説明を参照してください。

18.7 JDBCデータ・ビュー

JDBCデータ・ビューを使用すると、リレーショナル・データベースからLDAPクライアント・アプリケーションにアクセスできます。JDBCデータ・ビューをセットアップするには、次の構成オブジェクトが必要です。

- JDBCデータ・ソース。各リレーショナル・データベースに対して定義されます。現在、1つのJDBCデータ・ビューについてサポートされているJDBCデータ・ソースは1つだけです。

- JDBCデータ・ソース・プール。各JDBCデータ・ソースに対して定義されます。

- JDBCデータ・ビュー。複数のJDBCオブジェクト・クラスを、LDAPクライアント・アプリケーションがアクセスできる単一のデータ・ビューに集約します。

- JDBCオブジェクト・クラス。1つ以上のJDBC表をLDAPオブジェクト・クラスにマップします。

- JDBC表。各リレーショナル・データベース表に対して定義されます。

- JDBC属性。JDBC表の指定された列からLDAP属性を定義します。

次の図は、前述のJDBCオブジェクトの構成により、LDAPクライアント・アプリケーションがLDAP DIT形式でOracleデータベースを表示する方法を示しています。各オブジェクトについては、この後の項で詳しく説明します。

図jdbcdview.pngの説明

LDAPクライアント・アプリケーションはJDBCデータ・ビューに、またはJDBCデータ・ビューが含まれている結合データ・ビューにバインドすることもできます。その場合、Directory Proxy ServerはJDBCデータベースからパスワードを取得してパスワード・チェックを実行します。パスワードはクリア・テキスト、SHAまたはSSHAで取得できます。

18.7.1 JDBCデータ・ソースおよびデータ・ソース・プール

JDBCデータ・ソースは各リレーショナル・データベースに対して定義されます。JDBCデータ・ソースのプロパティにはリレーショナル・データベースの名前と場所、およびデータベースへのアクセスに必要なユーザー名とパスワードが含まれています。JDBCデータ・ソースに設定できるプロパティの完全なリストについては、次のコマンドを実行します。

$ dpconf get-jdbc-data-source-prop -h myHost -p 2389 -d "cn=Proxy Manager"\
jdbc-data-source-name

現在、1つのJDBCデータ・ソースのみが各JDBCデータ・ビューに対してサポートされています。つまり、JDBCデータ・ソース間ではロード・バランシングできません。

LDAPデータ・ソース同様、JDBCデータ・ソースは複数のデータ・ソース・プールで編成されます。JDBCデータ・ソース・プールのプロパティは、LDAPデータ・ソース・プールのプロパティに似ています。LDAPデータ・ソース・プールの詳細は、「LDAPデータ・ソース・プール」を参照してください。

注意:

Directory Proxy Serverはリレーショナル・データベースから取得されるメタデータに依存します。このメタデータはDirectory Proxy Serverの起動時、または新しいJDBCデータ・ビューが追加されるときに読み取られます。メタデータはDirectory Proxy Serverがリクエストを処理するたびに再度読み取られます。リレーショナル・データベースでメタデータを変更した場合、変更を考慮に入れるためにはDirectory Proxy Serverを再起動する必要があります。

メタデータは次のいずれかの変更が行われた場合に変更されます。

- データベースの構造への変更(表、行または列の追加、または削除)

- 表内の任意の列の大文字小文字の区別に対する変更

18.7.2 JDBCオブジェクト・クラス

JDBCオブジェクト・クラスはLDAPオブジェクト・クラスを1つ以上のリレーショナル・データベース表にマップします。JDBCオブジェクト・クラスは結合データ・ビューと同じ方法で機能します(「結合データ・ビュー」を参照)。結合データ・ビューがプライマリおよびセカンダリ・ソースデータ・ビューを持つのとちょうど同じように、JDBCオブジェクト・クラスは情報を複数の表から取得できます。1つの表をプライマリ表として定義する必要があり、それ以外の表がある場合は、それらをセカンダリ表として定義します。プライマリ表はエントリのリストを制御し、これらのエントリに関する追加情報はセカンダリ表から抽出されます。

JDBCオブジェクト・クラスを定義するときには、次のオペランドを指定する必要があります。

- このオブジェクト・クラスがアタッチされるJDBCデータ・ビューの名前。

- JDBCオブジェクト・クラスの名前。

- オブジェクト・クラスがエントリのリストを取得するプライマリJDBC表。

- データ・ビューでDNが構成される方法を制御するDNパターン。

- 1つ以上のセカンダリJDBC表(オプション)。

18.7.3 JDBC表

JDBC表は、JDBCデータ・ビューで使用される各リレーショナル・データベースに対して作成する必要があります。JDBC表を作成するときには、リレーショナル・データベースで表の名前を指定し、次にJDBCデータ・ビューでこの表に割り当てる名前を指定します。

JDBC表には次のプロパティが適用されます。

- SQL表。 (sql-table) リレーショナル・データベース表の名前を指定します。
この値は、JDBC表を作成するときに指定する必要がありますが、SQL表の名前に変更があった場合は変更できます。

- 1行表。 (is-single-row-table) あるLDAPエントリがリレーショナル・データベース表で一致する行を1つだけ持つことを指定します。
このプロパティをtrueに設定した場合、SQLリクエストに順番がないため、一般にパフォーマンスが向上します。

- 共有エントリ。 (contains-shared-entries) このプロパティは、セカンダリ表のある行がプライマリ表の複数のエントリによって使用されている場合にどのように処理するかを決定します。
たとえば、プライマリ表にユーザー詳細のリストがあり、セカンダリ表に部門番号が含まれている場合を想定します。セカンダリ表の1つの部門番号は、プライマリ表の複数のユーザーに適用される可能性があります。あるユーザーが削除された場合、セカンダリ表からそのユーザーの部門番号を必ずしも削除する必要がないことがあります。

contains-shared-entriesプロパティはセカンダリ表にのみ設定されます。このプロパティがTRUEに設定された場合、LDAPエントリを削除するとプライマリ表のユーザーは削除されますが、セカンダリ表の対応する行は削除されません。

- フィルタ結合ルール。 (filter-join-rule) フィルタ結合ルールはプライマリ表とセカンダリ表の間の関係を定義します。
フィルタ結合ルールはセカンダリ表では必須で、プライマリ表のなんらかの値に基づいてエントリがセカンダリ表からどのように取得されるかを示します。

各セカンダリ表に構成できるフィルタ結合ルールは1つだけです。フィルタ結合ルールは、LDAP属性を構成するために使用されるフィルタの形をとります。

たとえば、次のコマンドはセカンダリphone表にフィルタ結合を作成します。このルールは、phone表のuser_idフィールドがemployee表のidフィールドに一致する場合に、エントリをphone表から取得することを規定しています。

$ dpconf set-jdbc-table-prop -h myHost -p 2389 -d "cn=Proxy Manager" \
phone filter-join-rule:user_id=\${employee.id}

18.7.4 JDBC属性

JDBC属性はリレーショナル・データベース表のエントリにLDAP属性をマップします。JDBC属性の定義にはLDAP属性の名前と、該当する情報がある表および列が含まれています。

たとえば、次のコマンドはemployeeNumber属性をEMPLOYEE表のIDフィールドにマップします。

$ dpconf add-jdbc-attr -h myHost -p 2389 -d "cn=Proxy Manager" \
EMPLOYEE employeeNumber ID

JDBC属性には次のプロパティがあります。

- LDAP構文。 (ldap-syntax) このプロパティは、リレーショナル・データベース表のエントリからLDAP表を構成するために使用される構文を定義します。
JDBC属性の構文に対する変更が考慮されるためにはサーバーの再起動が必要です。

- SQL列。 (sql-column) LDAP属性の取得元のリレーショナル・データベース表の列。

- SQL構文。 (sql-syntax) このプロパティはLDAPエントリからリレーショナル・データベース表のエントリを構成するために使用される構文を定義します。

18.7.5 JDBCデータ・ビューの大/小文字の区別

場合によっては、LDAP属性に大文字小文字の区別がなく、リレーショナル・データベースの対応する列に大文字小文字の区別があることがあります。Directory Proxy Serverは、UPPERキーワードを同等索引付けおよび部分文字列索引付けに追加することにより、この状態を処理します。これはパフォーマンスに重大な影響を与える場合があります。したがって、リレーショナル・データベースで大文字小文字の区別が必要な場合は、大文字の値に対して特定の索引を作成する必要があります。

18.8 仮想データ・ビューのアクセス制御

仮想データ・ビューではDirectory Proxy Serverは仮想データを表示します。したがって、Directory Proxy Serverはそのデータに誰がアクセスできるか、およびそのデータのどの部分をアクセス可能にするかの制御を担当します。仮想データへのアクセスを制御するために、仮想ACIを定義できます。Directory Proxy Serverが仮想データ・ビューに対するリクエストを受信すると、仮想ACIおよび、ユーザーにより提供された認証情報を使用して、リクエストされた情報へのアクセスを許可または拒否します。

この項では仮想ACIの構文およびアーキテクチャについて説明します。仮想ACIの構成の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の仮想データ・ビューのアクセス制御の定義に関する説明を参照してください。

18.8.1 仮想ACIの定義

仮想ACIはdpsaci操作属性を使用して定義されます。dpsaci属性は複数値です。これは、ディレクトリの同じ部分に対して複数のACIを定義できることを意味します。

Directory Proxy Serverはdpsaci属性の管理を担当します。この属性は物理データとともに構成できますが、データと一緒には保管されません。dpsaci属性がリクエストに含まれている場合、Directory Proxy Serverはリクエストからそれを抽出し、独自のACIデータ・ビューを介してそれを専用のACIリポジトリで管理します。

仮想データ・ビューを対象とし、dpsaci属性を含む変更リクエストは、Directory Proxy Serverにより2つのリクエストに効率的に分割されます。最初のリクエストは仮想データのみを処理し、2番目のリクエストは仮想ACIを処理します。

注意:

デフォルトで、書込み操作はLDAPデータ・ビュー以外のビューでは許可されていません。

18.8.2 グローバルACI

グローバルACIは、エントリcn=data-source-name,cn=virtual access controlsで定義されます。これらのACIはACIエンジンにより評価され、そのACIプールを使用する接続ハンドラからのリクエストを拒否するか、または許可します。グローバルACIは、アプリケーション管理者による特定データへのアクセスを許可または拒否するために必要です。その後、これらのアプリケーション管理者は、データに直接ACIを配置することにより、よりきめ細かなアクセス制御を提供できます。

プロキシ・マネージャのみがACIのプールを作成し、ACIデータ・ビューを介して直接ACIを管理できます。アプリケーション管理者は、たとえエントリを追加する権限を持っても、ACIデータ・ビューを介してACIを管理することはできません。アプリケーション・マネージャはデータを介してACIを管理できるだけです。

データそのものに定義されているACIは、Directory Proxy Serverにより評価されます。これらのACIは、プロキシ・マネージャにより定義されたACIのプールにあるエントリ、つまり、エントリcn=data-source-name,cn=virtual access controlsの子エントリです。

ACIはパフォーマンスに影響を及ぼします。したがって、データそのものでACIを使用する場合、サブツリーがアクセスされるたびにグローバルACIが評価されるため、グローバルACIのルール数を最小限にしてください。

18.8.3 仮想ACI構文

dpsaci属性は、構文と振舞いにおいてDirectory Serverのaci属性に似ています。Directory ServerのACI構文の説明は、「Directory Serverのアクセス制御の提供方法」を参照してください。

次のリストでは、仮想ACIとDirectory Server ACIの間の違いを説明します。

- ターゲット・キーワード。target、targetAttrおよびtargetscopeの各キーワードのみがサポートされています。

- 許可キーワード。All 書込み権限はselfwrite操作を許可しません。

- バインド・ルール・サブジェクト。パフォーマンス上の理由から、仮想ACIはldap:///suffix??sub?(filter)をuserdnキーワードの値としてサポートしていません。

- バインド・ルール・コンテキスト。仮想ACIはSASL認証をサポートしていません。さらに、ipキーワードはサブネット・マスクをサポートしていません。

18.8.4 仮想ACIのストレージおよびアクセス

仮想ACIはLDIFファイルまたはLDAPディレクトリに、一元的に格納されます。Directory Proxy Serverインスタンスを作成するときに、仮想ACIはデフォルトでLDIFファイルinstance-path /config/access_controls.ldifに格納されます。特に複数のプロキシ・サーバー間でACIを共有する場合など、仮想ACIの場所を変更できます。仮想ACIの場所を変更する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の新しいACIストレージ・リポジトリの定義に関する説明を参照してください。

ACIリポジトリは、リポジトリのタイプに応じてLDAPまたはLDIFデータ・ビューを介してアクセスされます。デフォルトで、アクセス制御データ・ビューはvirtual access controlsという名前のLDIFデータ・ビューです。アクセス制御データ・ビューにより表示されるビュー・ベースはACIリポジトリ内に存在する必要があります。

ACIリポジトリには1つ以上のACIのプールが含まれています。ACIプールは、データ・ビューのビュー・ベースの直下にある、タイプがaciSourceのLDAPエントリにより定義されます。ACIプールはエントリのサブツリーです。これはアクセス制御を含めることができ、ACIが含まれている他のエントリの親エントリとなることができます。

18.8.5 仮想ACIのアプリケーション

仮想ACIは接続ハンドラごとに適用されます。使用されるACIプールの名前は、接続ハンドラのaci-sourceプロパティとして定義されます。仮想アクセス制御は、プロキシ・マネージャとしてバインドする場合は評価されません。

18.9 仮想スキーマのチェック

Directory Proxy Serverでは、物理データ・ソースのスキーマとは異なる独自のスキーマがあります。Directory Proxy ServerのスキーマはローカルのLDIFファイルに保管されるか、またはリモートのDirectory Serverに保管されます。dpconfコマンドを使用して、スキーマを保管する場所を構成できます。接続ハンドラごとに1つのスキーマが定義されます。特定の接続ハンドラのスキーマは、ldapsearchまたはldapmodifyを使用して取得または更新できます。スキーマが更新された場合、変更が有効になるためにはDirectory Proxy Serverを再起動する必要があります。

18.9.1 スキーマのチェック

一般的に、スキーマ・チェックは、そのスキーマを表示するサーバーにより実行されます。Directory Proxy Serverが1つ以上のDirectory Serverのプロキシとして動作するシナリオでは、それらのDirectory Serverにより、追加リクエストおよび変更リクエストがそれらのLDAPスキーマに準拠しているかが確認されます。Directory Proxy Serverが独自のスキーマを表示する場合、Directory Proxy Serverは追加リクエストおよび変更リクエストがこれらのスキーマに準拠していることを確認する必要があります。

スキーマは特定の接続ハンドラに対して定義されるため、スキーマ・チェックは接続ハンドラごとに有効化されます。スキーマ・チェックは、接続ハンドラのschemaCheck属性をtrueに設定することにより、有効化されます。

18.10 仮想データ・ビューおよびLDAPグループ

仮想データ・ビューを使用して、ローカルの仮想グループを定義し、ACIを介してそれらを使用できます。バックエンド・サーバーに定義された既存のグループにも依存できます。DNマッピングを使用することにより、LDAPディレクトリのグループを仮想ネームスペースで表示されるように変換できます。属性値の名前変更を使用して、すべてのメンバーのDNを変換することもできます。

結合データ・ビューでは、メンバーの名前の競合がないかぎり、2つの異なるLDAPバックエンドからの2つの静的グループを結合できます。ACIを使用して、たとえばuniquemember属性に読取り専用の仮想グループを作成することもできます。

Directory Proxy ServerサーバーはACIの領域でのみグループを使用します。ACIエンジンはgroupdnキーワードを使用することにより、静的グループと動的グループの両方を参照できます。

仮想ACIは静的グループと動的グループの両方をサポートします。ただし、isMemberOf機能はサポートされていません。パフォーマンスに重大な影響を及ぼすため、ネストされたグループもサポートされません。

動的グループの場合、属性値の名前変更はその値がLDAP URLであり、したがってDN構文ではないため、動的グループの値には適用されません。言い換えれば、動的グループの値にDNが含まれている場合、そのDNの部分は名前変更されません。

19 Directory Proxy ServerとバックエンドLDAPサーバー間の接続

この章では、Directory Proxy ServerとバックエンドLDAPサーバー間の接続について説明します。この章の内容は次のとおりです。

- LDAPデータソース

- Directory Proxy ServerとバックエンドLDAPサーバー間の接続

- Directory Proxy ServerからバックエンドLDAPサーバーへのリクエストの転送

19.1 LDAPデータソース

Directory Proxy ServerとバックエンドLDAPサーバー間の接続は、LDAPデータソースを使用して構成されます。LDAPデータソースは、LDAPサーバーの名前とポート番号および操作をLDAPサーバーに転送するときにDirectory Proxy Serverが適用する認証ポリシーを特定します。LDAPデータソースは、LDAPサーバーの監視方法も構成します。

LDAPデータソースには、任意のLDAP v3サーバーを指定できます。Directory Proxy Serverの一部の詳細機能は、OracleのDirectory Serverのみで利用できる機能に依存している場合がありますが、この機能の構成はオプションです。たとえば、OracleのDirectory Serverの「実効権限取得」制御は、Directory Proxy Serverによってプロキシ認可で使用されます。

バックエンドLDAPサーバーのヘルスは、Directory Proxy ServerとバックエンドLDAPサーバー間の接続をテストして監視されます。Directory Proxy ServerによるLDAPデータソースの監視方法の詳細は、「データソースの監視方法」を参照してください。

LDAPデータソースの作成および構成方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のLDAPデータソースの作成および構成に関する説明を参照してください。

19.2 Directory Proxy ServerとバックエンドLDAPサーバー間の接続

この項では、Directory Proxy ServerとバックエンドLDAPサーバー間の接続の開閉方法について説明します。また、複数のクライアント・リクエストでの接続プールの使用についても説明します。

19.2.1 Directory Proxy ServerとバックエンドLDAPサーバー間の接続の開閉

起動時に、Directory Proxy Serverは、構成済の有効な各データソースに対して接続を開きます。

接続時にエラーが検出されると、Directory Proxy Serverは接続を閉じ、すぐに接続を再確立しようとします。Directory Proxy Serverがデータソースに接続できない場合、データソースは利用できないものとみなされます。失敗した接続に対するDirectory Proxy Serverの応答方法は、「データソースの失敗に対するレスポンス」を参照してください。

19.2.2 Directory Proxy ServerとバックエンドLDAPサーバー間の接続プール

Directory Proxy ServerとLDAPサーバー間の接続は、複数のクライアント・リクエストで使用できるようにプールされます。各データソースでは、1プールのSSL接続および1プールの非SSL接続を使用できます。データソースのssl-policyプロパティおよび接続ハンドラのis-ssl-mandatoryプロパティは、データソースに接続するときにSSLを使用するかどうかを決定します。

データソースに対して開くことができる接続の数は、BIND、READおよびWRITEの各操作で別々に構成できます。同様の制限は、SSL接続および非SSL接続に適用されます。

各データソースおよび各種操作に次のプロパティを構成できます。

- データソースへの初期接続数

- 初期接続数を超える接続がリクエストされた場合の新規接続数

- データソースへの最大接続可能数

バインド・リプレイを構成する際、Directory Proxy Serverは、すでに開いている接続を再利用してパフォーマンスを最適化しようとします。クライアントが認証された接続を開くと、接続はバインド・プールから取得されます。そのため、バインド・リプレイを使用すると、バインド操作の接続プールは、読込みまたは書込み操作の接続プールより多く使用されます。バインド・リプレイの詳細は、「バインド・リプレイに構成されたDirectory Proxy Server」を参照してください。

データソースへの接続が5分間使用されない場合、接続はプールから削除されます。

19.3 Directory Proxy ServerからバックエンドLDAPサーバーへのリクエストの転送

クライアント・リクエストは、Directory Proxy ServerからバックエンドLDAPサーバーへ異なるレベルの認可と認証を使用して、クライアントのアイデンティティとともにまたはクライアント・アイデンティティなしで転送できます。データソースの構成は、リクエストの転送方法を決定します。クライアント・リクエストでのプロキシ認可の詳細は、「プロキシ認可に構成されたDirectory Proxy Server」を参照してください。クライアント・リクエストでのプロキシ認可の構成方法は、『Oracle Directory Server Enterprise Edition管理者ガイド』のプロキシ認可に関する説明を参照してください。

クライアント・リクエストにプロキシ認可制御が含まれる場合、コントロールは、Directory Proxy Serverによるリクエストの転送方法に関係なく、常にリクエストとともに転送されます。Directory Proxy Serverがプロキシ認可に構成されているユースケースおよびクライアント・リクエスト自体にプロキシ認可制御が含まれているユースケースは、「プロキシ認可に構成されたDirectory Proxy Serverおよびクライアント・リクエストにプロキシ認可が含まれる」の項を参照してください。

Directory Proxy ServerからバックエンドLDAPサーバーへのクライアント・リクエストの転送方法の詳細は、次の項を参照してください。

- バインド・リプレイに構成されたDirectory Proxy Server

- プロキシ認可に構成されたDirectory Proxy Server

- 代替ユーザーとしてリクエストを転送するよう構成されたDirectory Proxy Server

- クライアント・アイデンティティなしでリクエストを転送するよう構成されたDirectory Proxy Server

19.3.1 バインド・リプレイに構成されたDirectory Proxy Server

Directory Proxy Serverは、クライアントおよびクライアントの資格証明からLDAPサーバーにバインド・リクエストを転送します。バインドが成功すると、クライアントからそのLDAPサーバーへのすべての後続リクエストは、クライアントの認可を使用して処理されます。

バインド・リプレイでは、クライアントが、別のLDAPサーバーに転送される後続のリクエストを作成すると、Directory Proxy Serverは、クライアントがすでに提供した資格証明を使用して他のLDAPサーバーにバインドしてからリクエストを転送します。

クライアント・リクエストにプロキシ認可制御が含まれている場合、Directory Proxy Serverは、その制御をバックエンド・サーバーに転送します。

次の図は、バインド・リプレイが認可に使用しているクライアント・アイデンティティおよび資格証明を示しています。

図19-1 バインド・リプレイでの認証

「図19-1 バインド・リプレイでの認証」の説明

Directory Proxy Serverは、開始されると各LDAPサーバーに接続を開きます。クライアントがDirectory Proxy Serverに接続すると、次の手順でリクエストが作成されます。

1. クライアントはバインドをリクエストし、DNおよびパスワードを提供します。

2. Directory Proxy Serverは、クライアントの資格証明を使用してLDAPサーバー1に対してクライアントを認可します。クライアントのエントリがLDAPサーバー1に存在し、バインド・リクエストが許可されます。

3. クライアントは、LDAPサーバー1をターゲットとする検索リクエストを発行します。

4. Directory Proxy Serverは、検索リクエストをLDAPサーバー1に転送し、接続2を再利用します。
検索リクエストは、クライアントの認可を使用して実行されます。クライアント・リクエストにプロキシ認可制御が含まれている場合、リクエストは、プロキシ認可制御で指定されているユーザーの認可を使用して処理されます。

クライアントがLDAPサーバー1をターゲットとする多数の検索リクエストを送信すると、Directory Proxy Serverは、追加のバインドを実行せずにリクエストを転送します。

5. クライアントは、LDAPサーバー2をターゲットとする検索リクエストを送信します。

6. Directory Proxy Serverは、手順1で取得したクライアントの資格証明を使用してLDAPサーバー2に対してクライアントを認可します。クライアントのエントリがLDAPサーバー2に存在し、バインド・リクエストが許可されます。

7. Directory Proxy Serverは、検索リクエストをLDAPサーバー2に転送し、接続3を再利用します。

クライアントがDirectory Proxy Serverに認可されない場合、バインド・リクエストは,匿名として転送されます。

クライアント・アイデンティティが別のアイデンティティにマップされている場合、Directory Proxy Serverは、マップされているアイデンティティを使用してLDAPサーバーにバインドします。その接続に対するすべてのリクエストは、マップされているアイデンティティの認可を使用して処理されます。マッピングの使用の詳細は、「代替ユーザーとしてリクエストを転送するよう構成されたDirectory Proxy Server」の項を参照してください。

Directory Proxy Serverがバインド・リプレイに構成されている場合、SASL外部バインドによる認証を使用できません。バインド・リプレイでは、クライアントDNおよびパスワードを使用して、Directory Proxy ServerがクライアントをバックエンドLDAPサーバーに認証します。SASL外部バインドでは、パスワードはクライアントから提供されません。また、ユーザー・エントリに格納されているパスワードはクリア・テキストで表示できません。

パフォーマンス上の理由から、プロキシ認可に必要な追加の構成を行うことができない場合、またはプロキシ認可がサポートされていない場合にのみバインド・リプレイを使用するようDirectory Proxy Serverを構成する必要があります。プロキシ認可の詳細は、「プロキシ認可に構成されたDirectory Proxy Server」を参照してください。

19.3.2 プロキシ認可に構成されたDirectory Proxy Server

Directory Proxy Serverがプロキシ認可に構成されていると、Directory Proxy Serverはプロキシ認可制御をクライアント・リクエストに追加できます。そうすると、クライアント・リクエストは、プロキシ認可制御で指定されている認可を使用して転送されます。

Directory Proxy Serverでは、ACIの構成を簡略化するために、匿名の読込みを許可して、書込み操作に対するプロキシ認可を適用するよう構成できます。

Directory Proxy Serverがプロキシ認可に構成されていて、クライアント・リクエストに独自のプロキシ認可制御が含まれている場合、Directory Proxy Serverはプロキシ認可制御を追加しません。この場合、Directory Proxy Serverは、クライアントがそのプロキシ認可制御を使用する権限を持つバックエンドLDAPサーバーでチェックします。クライアントがそのプロキシ認可制御を使用する権限を持っている場合、Directory Proxy Serverは、クライアントのプロキシ認可制御で指定されている認可を使用してリクエストを転送します。

Directory Proxy Serverでのプロキシ認可の構成方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のプロキシ認可を使用したリクエストの転送に関する説明を参照してください。

19.3.2.1 Directory Proxy Serverがプロキシ認可に構成されているときの接続

Directory Proxy Serverがプロキシ認可に構成されている場合、クライアントは通常、非匿名バインドまたはSASL外部バインドによってDirectory Proxy Serverに認証されますが、クライアントを匿名にすることもできます。Directory Proxy Serverは通常、管理アイデンティティを使用してデータソースにバインドされます。

図19-2は、Directory Proxy Serverがプロキシ認可に構成されているときの、クライアント、Directory Proxy ServerおよびバックエンドLDAPサーバーの間の接続を示しています。

図19-2 プロキシ認可の接続

「図19-2 プロキシ認可の接続」の説明

プロキシ認可の接続は次の手順で作成されます。

1. Directory Proxy Serverは、開始されると各LDAPサーバーに接続を開きます。Directory Proxy Serverは、そのDNとパスワード、DPSbindDNおよびDPSbindPWを提供して、LDAPサーバー1およびLDAPサーバー2にバインドします。
DPSbindDNのエントリが、LDAPサーバーおよび許可されているバインド・リクエストの両方に存在します。Directory Proxy Serverは、接続2および接続3でLDAPサーバーにバインドされます。

2. クライアントがDirectory Proxy Serverに接続すると、クライアントは、そのDNとパスワード、clientDNおよびclientPWを提供してバインドします。

3. Directory Proxy Serverは、クライアントの資格証明を使用し、接続2を再利用してLDAPサーバー1に対してクライアントを認可します。
クライアントのエントリがLDAPサーバー1に存在し、バインド・リクエストが許可されます。クライアントは、接続1のDirectory Proxy Serverにバインドされます。

19.3.2.2 プロキシ認可に構成されているDirectory Proxy Serverおよびクライアント・リクエストにプロキシ認可が含まれていない

図19-3は、Directory Proxy Serverがプロキシ認可に構成されているときの情報のフローを示しています。図19-2では、クライアントが接続を行い、Directory Proxy Serverはプロキシ認可制御を追加します。

図19-3 Directory Proxy Serverでプロキシ認可制御が追加されるときの情報フロー

「図19-3 Directory Proxy Serverでプロキシ認可制御が追加されるときの情報フロー」の説明

1. クライアントは、プロキシ認可制御を含まない検索リクエストSEARCH 1を送信します。リクエストはLDAPサーバー1をターゲットにしています。

2. Directory Proxy Serverは、プロキシ認可制御をリクエストに追加し、接続2を再利用して検索操作をLDAPサーバー1に転送します。
検索操作は、プロキシ認可制御で指定されているユーザーの認可を使用して実行されます。その認可は、プロキシ認可制御で指定されているユーザーのLDAPサーバーのRW ACIで定義されます。

3. クライアントは、プロキシ認可制御を含まない2番目の検索リクエストSEARCH 2を送信します。リクエストはLDAPサーバー2をターゲットにしています。

4. Directory Proxy Serverは、検索操作をLDAPサーバー2に転送し、接続3を再利用します。
クライアントは、リクエストを処理する前にLDAPサーバー2にバインドする必要はなく、またそのLDAPサーバーにクライアントのエントリを含める必要もありません。

19.3.2.3 プロキシ認可に構成されたDirectory Proxy Serverおよびクライアント・リクエストにプロキシ認可が含まれる

図19-3は、図19-2のクライアントがプロキシ認可制御を含むリクエストを作成するときの情報のフローを示しています。Directory Proxy Serverは、クライアントがそのプロキシ認可制御を使用する権限を持っているかを確認します。

図19-4 プロキシ認可制御がクライアント・リクエストに含まれているときの情報フロー

「図19-4 プロキシ認可制御がクライアント・リクエストに含まれているときの情報フロー」の説明

1. クライアントは、プロキシ認可制御を含む検索リクエストSEARCH 1を送信します。リクエストはLDAPサーバー1をターゲットにしています。

2. Directory Proxy Serverは、LDAPサーバー1に対するクライアントの有効な権限を取得して、clientDNがLDAPサーバー1に対してプロキシ認可制御を使用する権限を持っているかを確認します。有効な権限を取得する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の有効な権限の表示に関する説明を参照してください。

3. Directory Proxy Serverは、検索操作をLDAPサーバー1に転送し、接続2を再利用します。
検索操作は、プロキシ認可制御で指定されているユーザーの認可を使用して実行されます。認可は、LDAPサーバーのRW ACIで定義されます。

4. クライアントは、プロキシ認可制御を含む2番目の検索リクエストSEARCH 2を送信します。リクエストはLDAPサーバー2をターゲットにしています。

5. Directory Proxy Serverは、LDAPサーバー2に対するクライアントの有効な権限を取得して、clientDNがLDAPサーバー2に対してプロキシ認可制御を使用する権限を持っているかを確認します。

6. Directory Proxy Serverは、検索操作をLDAPサーバー2に転送し、接続3を再利用します。
クライアントは、リクエストを処理する前にLDAPサーバー2にバインドする必要はなく、またそのLDAPサーバーにクライアントのエントリを含める必要もありません。

19.3.2.4 Directory Proxy Serverがプロキシ認可に構成されているときのセキュリティの問題

プロキシ認可にDirectory Proxy Serverを構成する前に、次のセキュリティ・リスクを検討します。

- Directory Proxy Serverがプロキシ認可に構成されている場合、Directory Proxy Serverは、リクエストを転送する任意のクライアントの権限を前提としています。データに対する書込み操作の実行が認可されていないDirectory Proxy Serverは、プロキシ認可を使用して、それらの操作を実行できます。

- LDAPサーバーには、プロキシ認可制御で指定されているユーザーに適切なR/W ACIを持つエントリが含まれている必要があります。このエントリは、第三者によって不正にアクセスされると、その第三者が偽装できる可能性があります。

- プロキシ認可制御で構成されている認可アイデンティティを改ざんから保護する必要があります。

19.3.3 クライアント・アイデンティティなしでリクエストを転送するよう構成されたDirectory Proxy Server

一部のデプロイメント・シナリオでは、クライアントがリクエストを作成するときに、クライアントのアイデンティティを維持する必要はありません。Directory Proxy Serverは、クライアント・アイデンティティなしでリクエストをLDAPサーバーに転送するよう構成できます。LDAPサーバーは、リクエストをDirectory Proxy Serverのアイデンティティおよび認可を使用して処理します。

19.3.4 代替ユーザーとしてリクエストを転送するよう構成されたDirectory Proxy Server

クライアント・リクエストは、ユーザー・マッピングという機能を使用して、代替ユーザーのアイデンティティで実行できます。ユーザー・マッピングでは、クライアント・アイデンティティは、代替ユーザーのアイデンティティにマップされます。バインド操作の後、Directory Proxy Serverは、代替ユーザーとして後続の操作を送信します。

クライアント・アイデンティティが別のアイデンティティにマップされると、そのクライアントからのリクエストを、バインド・リプレイまたはプロキシ認可を使用して、バックエンドLDAPサーバーに転送できます。

クライアント・アイデンティティは、Directory Proxy Server上のローカル、またはLDAPサーバー上のリモートのいずれかで代替アイデンティティにマップできます。図19-5および図19-6は、ローカル・マッピングおよびリモート・マッピングを示しています。

図19-5 代替アイデンティティへのクライアント・アイデンティティのローカル・マッピング

「図19-5 代替アイデンティティへのクライアント・アイデンティティのローカル・マッピング」の説明

図19-6 代替アイデンティティへのクライアント・アイデンティティのリモート・マッピング

「図19-6 代替アイデンティティへのクライアント・アイデンティティのリモート・マッピング」の説明

ローカル・マッピングでは、アイデンティティ・マッピングは、Directory Proxy Serverで構成されます。Directory Proxy Serverを再構成しなくても構成を変更できます。ローカル・マッピングは、認証されていないクライアント、認証されているクライアントおよびプロキシによって認証されているクライアントに構成できます。

リモート・マッピングでは、アイデンティティ・マッピングは、リモートLDAPサーバーのエントリで構成されます。リモートLDAPサーバーのエントリを変更して、マッピングを構成できます。マッピングの変更にDirectory Proxy Serverの再構成は必要ありません。リモート・マッピングは、認証されていないクライアントおよびプロキシによって認証されているクライアントに構成できます。

リモート・マッピングは、バインド・リプレイに構成されているデータソースに使用できません。バインド・リプレイでは、Directory Proxy Serverは、バインド操作で提供される認証を使用して、クライアント・リクエストを転送します。ただし、リモート・マッピングでは、バインド操作で提供されるクライアントDNとパスワードは、代替DNとパスワードにマップされます。クライアントのパスワードは、バックエンドLDAPサーバーから取得できません。

ユーザー・マッピングが有効化されていてもマッピングに失敗する場合、クライアント・アイデンティティはデフォルトのアイデンティティにマップされます。クライアント・アイデンティティが、存在しない代替ユーザーにマップされている場合または構成エラーが発生している場合、ユーザー・マッピングは失敗する場合があります。

ユーザー・マッピングの構成方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の代替ユーザーとしてリクエストを転送する方法に関する説明を参照してください。

20 クライアントとDirectory Proxy Server間の接続

Directory Proxy Serverへのすべての着信接続は、基準セットに従って接続ハンドラに分類されます。接続ハンドラは、リソース制限を定義し、接続に適用するフィルタおよび接続に公開されるデータ・ビューを要求します。

この章の内容は、次のとおりです。

- 接続を接続ハンドラに割り当てる基準

- 接続ハンドラのデータ・ビュー

- 接続ハンドラのリソース制限ポリシー

- 接続ハンドラのリクエスト・フィルタリング・ポリシー

20.1 接続を接続ハンドラに割り当てる基準

Directory Proxy Serverのインスタンスでは、多数の接続ハンドラを使用できます。クライアントがDirectory Proxy Serverに接続すると、プロキシは、接続の属性が接続ハンドラのいずれかの基準に一致するかどうかを評価します。一致が見つかると、接続はその接続ハンドラに分類されます。その接続に定義されているすべてのポリシーがその接続に適用されます。この接続を使用して実行される操作は、すべてのデータ・ビューまたは接続ハンドラによって定義されているデータ・ビューのリストに公開されます。

接続は、接続ハンドラに分類された後、Directory Proxy Serverによって自動的に別の接続ハンドラに再分類できます。たとえば、クライアントが匿名で接続した場合、接続は、匿名の接続用に構成されている接続ハンドラに割り当てられます。クライアントが後で同じ接続上にバインドDNを提供した場合、その接続を別の接続ハンドラに再割当てすることができます。同様に、セキュアでないLDAP接続は、はじめにセキュアでない接続の接続ハンドラに分類されます。クライアントがStartTLSを使用して接続をセキュアなモードにプロモートする場合、その接続は自動的にセキュアな接続の接続ハンドラに再分類されます。

接続は、接続ハンドラの優先度の順番で接続ハンドラに対して評価されます。優先度1は、優先度が最高の接続ハンドラです。この接続は、一致する最初の接続ハンドラに分類されます。最も特殊な基準を持つ接続ハンドラは、あまり特殊でない条件またはより一般的な基準を持つ接続ハンドラよりも優先度が高くなります。たとえば、バインドDNを指定する接続ハンドラは、単純なバインドを指定する接続ハンドラよりも優先度が高くなります。

接続が、構成されているいずれの接続ハンドラの基準にも一致しない場合、その接続はデフォルトの接続ハンドラに割り当てられてます。デフォルトの接続ハンドラの基準は変更できません。また、デフォルトの接続ハンドラを無効化したり削除することもできません。ただし、デフォルトの接続ハンドラのポリシーおよびデータ・ビューは変更できます。

デフォルトの接続ハンドラは、最も優先度が低い接続ハンドラです。優先度のない新しい接続ハンドラが作成されると、新しい接続ハンドラには、デフォルトの接続ハンドラよりも高い優先度が設定されます。2つの接続ハンドラの優先度が同じである場合、接続が評価される順番は指定されません。

接続ハンドラの基準式は、異なる種類の基準の間の論理ANDおよび同じ種類の基準の間の論理ORです。たとえば、クライアントIPアドレスに基準が1つ指定されていると同時に、クライアント・ドメイン名に基準が1つ設定されている場合、どちらの基準も満たしている必要があります。ただし、クライアントIPアドレスに2つの基準が設定されている場合、両方ではなくいずれかの基準を満たしている必要があります。

次のリストは、接続を接続ハンドラに分類するときに使用される基準をまとめたものです。基準の構成方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の接続ハンドラの作成、構成および削除に関する説明を参照してください。

- クライアントIPアドレスおよびマスク。IPv4またはIPv6アドレス・マスクのセットです。接続が接続ハンドラによって受け入れられるには、クライアント接続のIPアドレスが、少なくとも1つのマスクと一致する必要があります。
IPアドレスは、次の形式のいずれかで指定できます。

- ドット区切りの10進数形式のIPアドレス。たとえば、129.153.129.14です。

- IPアドレスとビット数(ネットワーク番号/マスク・ビットの形式)。たとえば、129.153.129.0/24です。

- IPアドレスと4つの数値(ドット区切りの4つの10進数がペアになった形式)。たとえば、129.153.129.0/255.255.255.128です。

- ALL(すべてのアドレス)は、優先度の高いその他のグループとして設定されていないクライアントすべてをキャッチします。

- 0.0.0.0。このアドレスは、最初のメンバーシップを考慮しないグループのアドレスです。たとえば、最初のバインド後の、クライアントの切換え先となるグループです。

- ローカル・ホストのIPアドレス。IPアドレス127.0.0.1は、Directory Proxy Serverと同じコンピュータ上で実行されているクライアントのIPアドレスです。

- クライアント・ドメイン名。ドメイン名のセットです。接続が接続ハンドラによって受け入れられるには、クライアントのネットワーク・ドメインが、少なくとも1つのサフィックスと一致する必要があります。
クライアントのドメイン名をフィルタできるためには、Directory Proxy Serverで、受信IPアドレスを完全修飾ドメイン名に変換できる必要があります。ネーミング・サービスがドメイン名のないホスト名を返す場合、Directory Proxy Serverは、クライアントのドメイン名をフィルタできません。

Directory Proxy Serverは、ドメインのサフィックスを想定していないため、完全修飾ドメイン名を指定する必要があります。たとえば、.oracle.comのようにドメイン名のサフィックスがピリオドで始まっている場合、そのサフィックスで終わるドメイン名を持つすべてのホストが一致します。

ドメイン名は、次の形式で指定できます。

- 完全名(例: box.eng.oracle.com)。

- サフィックス名(例: .eng.oracle.com)。サフィックス名を使用してクライアントを特定する場合、DNSがDNS問合せに対して完全修飾名を返すように設定されているかを確認してください。

- ローカル・ホストの完全修飾名。これは、Directory Proxy Serverと同じコンピュータ上で実行されているクライアントのための基準です。

- バインドDN。クライアントのバインドDNで一致する必要のある正規表現です。
たとえば、正規表現: uid=(.*),dc=example,dc=comは、接続ハンドラのバインドDN基準として使用できます。uid=user1,dc=example,dc=comのようにuidを使用してバインドするクライアントがこの基準に一致し、接続ハンドラに割り当てることができます。ou=accounts,dc=example,dc=comのように別のDNでバインドするクライアントは、この基準に一致せず、接続ハンドラに割り当てられません。

- グループDN Directory Proxy Serverは、バインドDNによって表されるユーザー・エントリが、グループDNの基準属性で指定されている任意のグループのメンバーである場合にのみ、接続ハンドラを接続に割り当てます。Directory Proxy Serverは、接続ハンドラにアタッチされているデータ・ビューのみのグループおよびメンバーを検索します。グループDNの基準属性では、正規表現を使用できず、適切なグループDNのみを受け入れます。

- LDAP検索フィルタ。バインドされたクライアントのエントリが一致する必要のある検索フィルタ。
たとえば、フィルタ: uid>=1000は、接続ハンドラの基準として使用できます。フィルタに一致するuidを使用してバインドされたクライアントを接続ハンドラに割り当てることができます。

- 認証方式。接続が接続ハンドラによって受け入れられるためにクライアント・エントリに一致する必要がある認証方式。
認証方式は、次のいずれかを使用できます。

- 単純

- SASL/外部

- 匿名

- IPポート。IPポート番号のセットです。接続が接続ハンドラによって受け入れられるためには、クライアント接続が指定ポートのいずれかを使用して確立される必要があります。

- SSL接続。クライアント接続が、接続ハンドラによって受け入れられるためにSSLを使用する必要があるかを示すフラグ。

20.2 接続ハンドラのデータ・ビュー

接続が接続ハンドラに割り当てられると、接続に対するリクエストは、その接続ハンドラに構成されているデータ・ビューのリストに公開されます。接続ハンドラのデータ・ビューのリストには、ゼロ、1つまたは複数のデータ・ビューを含めることができます。

データ・ビューのリストが空の場合、接続に対するリクエストはいずれのデータ・ビューにも配布されません。接続を使用しているアプリケーションは、いずれのデータにもアクセスできず、No such Objectエラーが返されます。

データ・ビューのリストに複数のデータ・ビューが含まれている場合、接続に対するリクエストは、リクエストのターゲットDNに最も具体的に対応しているデータ・ビューに配布されます。たとえば、図20-1で、connection-handler-1での接続に対するリクエストは、data-view-2、data-view-3またはdata-view-4に配布することができます。ただし、検索リクエストにou=people,dc=example,dc=comというターゲットDNが含まれている場合、リクエストは、data-view-3またはdata-view-4のいずれかに配布されます。

図20-1 接続ハンドラのデータ・ビューのリスト

「図20-1 接続ハンドラのデータ・ビューのリスト」の説明

クライアント接続および選択したデータ・ビューの間にアフィニティを定義して、その接続に対するリクエストに応答できます。この機能をデータ・ビュー・アフィニティと呼びます。データ・ビュー・アフィニティを有効化すると、クライアント接続上の連続リクエストは、その接続に対する最初のリクエストに使用されたデータ・ビューに対して排他的に公開されます。

データ・ビュー・アフィニティは、有効化されると、他のタイプのルーティングよりも優先されます。たとえば、図20-1で、ou=computer,dc=example,dc=comというターゲットDNを使用した検索リクエストはdata-view-2に公開されます。そのクライアント接続に対するすべての後続のリクエストはdata-view-2に排他的に公開されます。そのクライアント接続に対する後続のリクエストにou=people,dc=example,dc=comというターゲットDNが含まれている場合、リクエストは、ou=people,dc=example,dc=comのデータ・ビューではなく、ou=computer,dc=example,dc=comのデータ・ビューに公開されます。

データ・ビュー・アフィニティを構成する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のデータ・ビューのアフィニティを構成する方法に関する説明を参照してください。

20.3 接続ハンドラのリソース制限ポリシー

リソース制限ポリシーは、Directory Proxy Serverが特定の接続ハンドラに対して処理できる最大のリソースを定義します。この種類の接続ハンドラのポリシーを使用すると、接続、リクエストおよびリフェラルに割り当てられるリソースを制限することができます。

接続ハンドラには、ゼロまたは1つのリソース制限ポリシーを設定することができます。リソース制限ポリシーが定義されていない場合、接続、リクエストおよびリフェラルにはリソース制限ポリシーが適用されません。リソース制限ポリシーの構成方法の詳細およびリソース制限ポリシーの例は、『Oracle Directory Server Enterprise Edition管理者ガイド』のリソース制限ポリシーの作成および構成に関する説明を参照してください。

次のリストは、構成できるリソース制限をまとめたものです。

- 接続

- 最大接続数。

- 単一のクライアントからの同時最大接続数。

- 1接続当たりの最大操作数。クライアントによる1接続当たりの操作が最大数を超過した場合、接続はDirectory Proxy Serverによって閉じられます。

- 1接続当たりの最大同時操作数。
1接続当たりの最大同時接続数が1である場合、クライアントは同期操作を実行する必要があります。操作中止のリクエストを除き、同時に操作された他のリクエストは失敗し、「サーバー・ビジー」というエラーが表示されます。

- 検索

- 検索操作結果の最大許容サイズ

- 検索操作の最大許容期間

- 検索フィルタで許可される部分文字列の最小長

- カスタマイズされた検索制限(カスタマイズされた検索制限に関する説明を参照)

- リフェラル

- リフェラルをたどるときの最大ホップ数

- リフェラルをたどる際に適用されるバインド・ポリシー
設定されている場合はパスワードを使用し、ない場合は匿名でリフェラルをたどります。

常に匿名としてリフェラルをたどります。

- サーバーからリフェラルが返される際に適用されるポリシー
* リフェラルに従う

* リフェラルをクライアントに転送する

* リフェラルを破棄する

リソース制限ポリシーの構成方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のリソース制限ポリシーの作成および構成に関する説明を参照してください。

20.3.1 カスタマイズされた検索制限

カスタマイズされた検索操作の制限は、検索ベースおよび検索範囲に基づいて定義できます。検索のターゲットDNがリストで指定されていて、検索の範囲が1レベルまたはサブツリーである場合は、検索結果の最大サイズを構成できます。

カスタム検索制限は、特定のリソース制限ポリシーに定義されます。リソース制限ポリシーを削除すると、そのポリシーに定義されているカスタム検索制限も削除されます。カスタム検索制限が指定されていない場合、標準の検索サイズ制限が適用されます。

20.4 接続ハンドラのリクエスト・フィルタリング・ポリシー

リクエスト・フィルタリング・ポリシーは、クライアントのデータへのアクセスを制御します。接続ハンドラは、ゼロまたは1つのリクエスト・フィルタリング・ポリシーを参照できます。

このタイプの接続ハンドラ・ポリシーを使用すると、クライアント・アクセスの次のような点を定義することができます。

- クライアントが実行を許可される操作または禁止される操作のタイプ。
追加、バインド、比較、削除、拡張操作、変更、DN変更、検索および不等フィルタに基づく検索の各操作を許可または禁止することができます。

- 検索フィルタおよび比較操作で使用を許可または禁止される属性。
すべての属性を検索フィルタおよび比較操作で許可できるか、または属性のリストを許可または禁止できます。

- 検索操作の範囲。
範囲は、ベースDN、ベースDNの1つ下のレベルまたはベースDNの下のサブツリー全体のいずれかを指定できます。

- クライアントによるアクセスが許可または禁止されるサブツリー。
詳細は、「リクエスト・フィルタリング・ポリシーのサブツリー」を参照してください。

- 検索操作でアクセスできるエントリおよび検索操作で返すことができるデータ。
詳細は、「リクエスト・フィルタリング・ポリシーの検索データ非表示ルール」を参照してください。

リクエスト・フィルタリング・ポリシーを構成する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のリクエスト・フィルタリング・ポリシーおよび検索データ非表示ルールの作成と構成に関する説明を参照してください。

20.4.1 リクエスト・フィルタリング・ポリシーのサブツリー

リクエスト・フィルタリング・ポリシーは、1つ以上の許可されたサブツリーおよびゼロ以上の禁止されたサブツリーで構成されます。サブツリーは、クライアントがアクセスできるデータ・ビューの部分を特定します。

20.4.1.1 許可されたサブツリー

許可されたサブツリーは、最小ベースDNで指定されます。クライアントは、最小ベースDNの下のエントリの操作の実行を許可されます。デフォルトでは、最小ベースDNは、ルートDNです。

クライアントが、最小ベースDNより優先されるDNをターゲットとしている検索操作をリクエストする場合、Directory Proxy ServerはDNをリライトして最小ベースDNをターゲットとします。クライアントが、最小ベースDNより優先されるDNをターゲットとするその他の操作を実行すると、操作は拒否されます。

20.4.1.2 禁止されたサブツリー

禁止されたサブツリーは、クライアントがアクセスできない許可されたサブツリーのブランチです。禁止されたサブツリーのベースDNは、許可されたサブツリーの最小ベースDNの下位にある必要があります。クライアントが、禁止されたサブツリーをターゲットとする操作を実行すると、操作は拒否されます。

20.4.2 リクエスト・フィルタリング・ポリシーの検索データ非表示ルール

検索操作の結果をクライアントに返す方法を決定するルールは、検索データ非表示ルールと呼ばれます。検索データ非表示ルールの作成方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の検索データ非表示ルールの作成方法に関する説明を参照してください。

検索操作の結果は、次のいずれかの方法で返すことができます。

- ターゲット・エントリは返さない

- ターゲット・エントリは返されるが、指定された属性はフィルタされて除去される

- ターゲット・エントリは返されるが、指定されていない属性はフィルタされて除去される

検索データ非表示ルールは、次のいずれかのエントリに適用できます。

- 指定されたDNを持つエントリ

- 指定されたDNパターンを持つエントリ

- 指定された属性名と属性値のペアを持つエントリ(attrName:attrValue)

検索データ非表示ルールは、特定のリクエスト・フィルタリング・ポリシーに定義され、それ以外のリクエスト・フィルタリング・ポリシーで使用することはできません。リクエスト・フィルタリング・ポリシーが削除されると、関連する検索データ非表示ルールも自動的に削除されます。ゼロ以上の検索データ非表示ルールを1つのリクエスト・フィルタリング・ポリシーに定義できます。

21 Directory Proxy Serverのクライアント認証

この章では、Directory Proxy Serverが受信クライアント接続を特定する方法について説明します。この章の内容は次のとおりです。

- クライアント認証の概要

- 単純バインド認証

- 証明書ベースの認証

- 匿名アクセス

- Directory Proxy Serverのクライアント・リスナー

21.1 クライアント認証の概要

クライアント認証は、クライアントが自身をDirectory Proxy Serverに特定させる方法を判断します。

プロトコルの観点では、クライアント認証は2つのレベルで行われます。

- LDAPレベル。認証は、LDAPバインド操作で行われます。

- 接続レベル。認証は、クライアントとDirectory Proxy Serverの間に確立されたネットワーク接続で行われます。

Directory Proxy Serverは、クライアント接続を認証なしで受け入れるように構成できます。

次のリストは、サポートされている認証オプションをまとめたものです。この章の後の項で、これらのオプションを詳しく説明します。

- 単純バインド認証。単純バインド認証は、バインド・レベルで行われます。クライアントがバインドすると、クライアントは、Directory Proxy Serverへの一意の名前(バインドDN)とパスワードを提供します。Directory Proxy Serverは、バインド・リクエストとともにこれらの資格証名をバックエンドLDAPサーバーに転送します。
単純バインド認証は、セキュアな接続上で行うこともできます。その場合でも、サーバーは、バインドDNからクライアントを特定します。

- 証明書ベースの認証。証明書ベースの認証は、接続がセキュアな場合に接続レベルで行われます。認証が接続レベルで行われると、クライアントは暗号化された接続(SSL)で接続し、証明書を提供します。Directory Proxy Serverは、クライアント証明書の有効性をチェックし、証明書をLDAP DNにマップします。

- 認証なし。クライアントが証明書またはバインドDNとパスワードを提供しない場合、認証は行われません。この場合、クライアントは匿名でDirectory Proxy Serverに接続します。これは、匿名アクセスと呼ばれます。

21.2 単純バインド認証

単純バインド認証は、LDAPクライアントを認証する最も一般的な方法です。単純バインドでは、クライアントは、匿名でバインドする、つまり空のバインドDNを使用するか、DNとパスワードを提供してバインドします。Directory Proxy Serverはデータソースにバインドして、資格証明を検証し、クライアントを認証します。クライアントのエントリは、データソースに存在する必要があり、それ以外の場合、クライアントは匿名とみなされます。クライアントが認証されると、Directory Proxy Serverはクライアントのアイデンティティを記録します。

Directory Proxy Serverは、デフォルトでは、単純バインド認証に構成されています。追加の構成は必要ありません。クライアントはDirectory Proxy Serverにパスワードを提供するため、単純バインド認証はパスワード・ベースの認証とも呼ばれます。

21.2.1 パスワードの暗号化と検証

パスワードの暗号化方法および確認方法は、クライアントがデータソースにアクセスする際に使用するデータ・ビューの種類によって異なります。データ・ビューの詳細は、第17章「Directory Proxy Serverの配布」および第18章「Directory Proxy Serverの仮想化」を参照してください。

LDAPデータ・ビューでは、Directory Proxy Serverのパスワード暗号化と検証は、バックエンドLDAPサーバーに依存します。クライアントがADDまたはMODIFY操作を使用してパスワードを変更する場合、バックエンドLDAPサーバーは、パスワードを格納するときにパスワード暗号化ポリシーを適用できます。クライアントがBINDリクエストを発行すると、LDAPサーバーはパスワードを検証します。

LDIFおよびJDBCデータ・ビューでは、Directory Proxy Serverのパスワード暗号化と検証を行います。クライアントがパスワードを変更すると、Directory Proxy Serverは、データ・ビューのdb-pwd-encryptionのプロパティによって定義されている暗号化ポリシーを適用します。暗号化ポリシーには、PLAIN、SHA、SSHAまたはSHA512を指定できます。SolarisおよびUNIXでは、追加オプションでCrypt暗号化ポリシーを使用できます。パスワードは引き続きデータソース、つまりLDIFファイルまたはJDBCデータベースに格納されます。デフォルトでは、パスワードはSSHAを使用して暗号化されます。

暗号化されたパスワードを格納すると、暗号化された値に暗号化ポリシーが付けられます。たとえば、格納された暗号化パスワードは、{SSHA}mcasopjebjakiueまたは{SHA}askjdlaijfbnjaのようになります。クライアントがBINDリクエストを発行すると、Directory Proxy Serverはパスワードを検証し、暗号化ポリシー・タグを要求します。

21.3 証明書ベースの認証

SSL接続上での証明書ベースの認証は、最もセキュアな認証タイプです。そのため、認証が接続層で行われる場合、クライアントは、LDAPバインド中に追加の名前(バインドDN)とパスワードをDirectory Proxy Serverに指定する必要がありません。

クライアントは、SSL接続を介してのみ証明書ベースの認証を実行できます。SSL接続の確立の基本的な手順は、次のとおりです。

1. クライアントは、セキュアな接続の確立をリクエストします。
このリクエストの一環として、Directory Proxy Serverは、クライアントにサーバー証明書を提供します。サーバー証明書は、Directory Proxy Serverの1インスタンスに関連付けられた単一の証明書です。セキュアな接続を使用すると、サーバー証明書は、クライアントへのDirectory Proxy Serverのインスタンスを特定します。

接続の確立には、ネゴシエーション・フェーズが含まれます。このフェーズの間、クライアントとDirectory Proxy Serverは、使用されている暗号化ポリシーの承認を試みます。サーバー証明書には、Directory Proxy Serverがサポートしている暗号化ポリシー(暗号)のリストが含まれています。

2. プロキシ・サーバーのセキュリティ構成によっては、サーバーは、クライアントによる証明書の提供を要求する場合があります。

3. クライアントは、クライアントが証明書をサーバーに提供するように構成されている、またはプロキシ・サーバーがそれをリクエストしているため、証明書をサーバーに提供します。

4. クライアントは次に、LDAPバインド・リクエストをDirectory Proxy Serverに送信して、その接続に対してクライアントのアイデンティティを確立します。

5. リクエストが単純バインドである場合、Directory Proxy Serverは、クライアントが提供するバインドDNとパスワードを使用します。

6. リクエストがSASL外部バインドである場合、Directory Proxy Serverは、次の2つのうちのいずれかを実行します。

- 証明書のサブジェクトをクライアントのバインドDNとしてみなす。

- 受け取った証明書に一致するエントリのバックエンド・サーバーを検索して証明書をマップする。verify-certsプロパティが設定されている場合、Directory Proxy Serverは、受け取った証明書が見つかったエントリに格納されいる証明書であるかどうかを検証します。
次の構成プロパティは、Directory Proxy Serverがその検索を実行する方法を決定します。

cert-data-view-routing-policy
cert-data-view-routing-custom-list
cert-search-bind-dn
cert-search-bind-pwd-file
cert-search-base-dn
cert-search-attr-mappings

7. プロキシ・サーバーにバインドDNがある場合、プロキシ・サーバーはクライアントの有効性を検証することができます。

Directory Proxy ServerのSSLの詳細は、「Directory Proxy ServerのSecure Sockets Layer」を参照してください。

証明書ベースの認証を行うには、Directory Proxy Serverがクライアント証明書を受け入れ、クライアントがSASL外部バインドを使用するように構成されている必要があります。

21.3.1 Directory Proxy Serverでの証明書の構成

Directory Proxy Serverインスタンスを作成すると、証明書データベースに、信頼できるCAのCA証明書が自動的に移入されます。必要に応じて、Directory Service Control Center (DSCC)またはdpadmコマンドを使用して、信頼できるCA証明書を証明書データベースに追加できます。詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のDirectory Proxy ServerにCA署名付きサーバー証明書をインストールする方法に関する説明を参照してください。

クライアントがDirectory Proxy Serverに証明書を提供すると、サーバーは、信頼できるCA証明書のリストに対するその証明書が、その証明書データベースにあるかどうか検証します。サーバーの証明書データベースにクライアント証明書自体またはクライアント証明書の生成に使用されたCA証明書が含まれている場合、検証は正常に実行されています。

サーバー証明書は、次のいずれかを使用できます。

- 自己署名付き証明書。公開鍵と秘密鍵のペアで、公開鍵はDirectory Proxy Serverによって署名されています。

- 信頼できるCA証明書。社内の証明書サーバーまたは既知の認証局(CA)によって自動的に生成された単一の証明書です。

また、Directory Proxy Serverは、サーバー証明書チェーンもサポートしています。サーバー証明書チェーンは、社内の証明書サーバーまたは既知のCAによって自動的に生成された証明書の集合です。チェーンの証明書は、元のCAにトレースバックして、アイデンティティの証明を提供します。この証明は、新しいサーバー証明書を取得またはインストールするたびに必要です。

Directory Proxy Serverのインスタンスが作成されると、デフォルトの自己署名付き証明書が作成されます。デフォルトでは、Directory Proxy ServerはSSL証明書データベースのパスワードを内部的に管理します。

任意の数の証明書をサーバーにインストールできます。Directory Proxy ServerのインスタンスのSSLを構成する場合、少なくとも1つ以上のサーバー証明書および1つの信頼できるCA証明書をインストールする必要があります。

証明書ベースの認証が動作する仕組みの説明は、「証明書ベースの認証」を参照してください。Directory Proxy Serverの証明書ベースの認証の構成方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の証明書ベースの認証の構成方法に関する説明を参照してください。

21.3.2 SASL外部バインドの使用

クライアントが単純バインド認証およびセキュリティ・レイヤー(SASL)外部バインドを使用してDirectory Proxy Serverにバインドすると、Directory Proxy Serverは、バインドDNからではなく、クライアントの証明書からクライアントの資格証明を取得します。

サーバーは、次の2つのうちのいずれかの方法で証明書を取得します。

- 証明書のサブジェクトをクライアントのバインドDNとしてみなす。

- 証明書サブジェクトをそれ自身のデータベース内のデータにマップし、バインドDNを推定する。

Directory Proxy Serverがバインド・リプレイに構成されている場合、SASL外部バインドは使用できません。バインド・リプレイでは、クライアントDNおよびパスワードを使用して、Directory Proxy ServerがクライアントをバックエンドLDAPサーバーに認証します。SASL外部バインドでは、パスワードはクライアントから提供されません。また、ユーザー・エントリに格納されているパスワードはクリア・テキストで表示できません。バインド・リプレイの詳細は、「バインド・リプレイに構成されたDirectory Proxy Server」を参照してください。

SSLを使用して、クライアントとDirectory Proxy Serverの間の以降の相互作用を保護することができます。

SASL外部バインドによる認証の構成方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のSASL外部バインドにDirectory Proxy Serverを構成する方法に関する説明を参照してください。

21.4 匿名アクセス

匿名アクセスを使用すると、ユーザーが認証されているかどうかに関係なく、任意のクライアントに対してデータが利用可能になります。

クライアントからの匿名接続にDirectory Proxy Serverを構成する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の匿名アクセスの構成方法に関する説明を参照してください。

21.5 Directory Proxy Serverのクライアント・リスナー

Directory Proxy Serverでは、クライアント・リスナーを使用して、クライアント接続の特定の側面を構成することができます。セキュアなリスナー(ldaps-listener)とセキュアでないリスナー(ldap-listener)の2つのクライアント・リスナーが提供されます。

セキュアなリスナーにより、接続がSSLを介してセキュアなポートに作成されるように指定されます。セキュアでないリスナーでは、接続がSSLを使用せずに、セキュアでないポートに作成されるように指定されます。クライアントは、必要な接続タイプに応じて、セキュアなリスナーまたはセキュアでないリスナーのいずれかを使用します。

注意:

クライアントがStart TLSをサポートしている場合、そのクライアントは、セキュアでないポートにセキュアな接続を確立することもできます。

セキュアなリスナーおよびセキュアでないリスナーのいずれも、クライアント接続の次の側面を指定します。

is-enabled

クライアントがそのリスナーを使用してDirectory Proxy Serverに接続できるかどうかを指定する

listen-port

Directory Proxy Serverがクライアント接続をリッスンするポート番号

listen-address

リスナーのIPアドレス

connection-idle-timeout

クライアント接続が、閉じられるまでアイドル状態でいることができる最長時間

connection-read-data-timeout

リスナーが新しいデータが利用可能になるのを待機できる最長時間

connection-write-data-timeout

結果をクライアントに戻すまでにリスナーが待機できる最長時間

max-connection-queue-size

リスナーの接続キューの最大サイズ

max-ldap-message-size

LDAPメッセージの最大サイズ

number-of-threads

同時クライアント接続およびリクエストのためにリスナーに割り当てられるスレッドの数

use-tcp-no-delay

クライアントとDirectory Proxy Serverの間の接続にTCP_NODELAYを有効化するかどうか

リスナーの構成方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のリスナーとDirectory Proxy Serverの間のリスナーの構成に関する説明を参照してください。

22 Directory Proxy Serverのセキュリティ

この章では、Directory Proxy Serverを通過するデータを保護するために使用できるメカニズムについて説明します。

この章の内容は次のとおりです。

- Directory Proxy Serverでのセキュリティ

- Directory Proxy ServerのSecure Sockets Layer

- Directory Proxy Serverの暗号およびプロトコル

22.1 Directory Proxy Serverでのセキュリティ

Directory Proxy Serverには、次の方法を組み合せたセキュリティが用意されています。

- 暗号化
暗号化は情報の秘密を保護します。データが暗号化されるとき、そのデータは正当な受信者のみがデコードできる方法でスクランブルされます。Directory Proxy ServerではSSL暗号化がサポートされています。SSLの詳細は、「Directory Proxy ServerのSecure Sockets Layer」を参照してください。

- 認証
認証は、一方が他方のIDを検証する方法です。たとえば、クライアントはLDAPバインド操作中にDirectory Proxy Serverにパスワードを渡します。ポリシーは、パスワードが有効とみなされるために満たす必要がある基準(期間、長さ、構文など)を定義します。Directory Proxy Serverでは非同期認証、パスワード・ベースの認証、および証明書ベースの認証がサポートされています。認証の詳細は、第21章「Directory Proxy Serverのクライアント認証」を参照してください。

- アクセス制御命令(ACI)
ACIは、クライアント・アプリケーションに付与されたアクセス権を管理し、必要な資格証明やバインド属性を指定する方法を提供します。Directory Proxy Serverは、リクエスト・フィルタリング・ポリシおよび仮想ACIを使用してアクセス制御を実装します。リクエスト・フィルタリング・ポリシーの詳細は、「接続ハンドラのリクエスト・フィルタリング・ポリシー」を参照してください。仮想ACIの詳細は、「仮想データ・ビューのアクセス制御」を参照してください。

- 監査およびログ
監査を使用して、セキュリティが損なわれていないかどうかを判別できます。Directory Proxy Serverに保持されているログ・ファイルを監査して、誰がサーバーにアクセスしたか、行われた操作は何かを追跡できます。ログ・ファイルの詳細は、第24章「Directory Proxy Serverのアラートおよび監視」および第23章「Directory Proxy Serverのロギング」を参照してください。

22.2 Directory Proxy ServerのSecure Sockets Layer

Secure Sockets Layer (SSL)はクライアントとDirectory Proxy Server間の暗号化した通信を提供します。認証とともにSSLを使用することにより、Directory Proxy Serverから送受信されるデータを暗号化できます。

Directory Proxy Serverのインスタンスが作成されるときに、SSLはデフォルトで有効化され、次のディレクトリおよびファイルが作成されます。

証明書データベースを保護するためのランダムで生成されたパスワード

このパスワードはinstance-path/etc/pass.txtに保管されます。

証明書のキーストア・データベース

このキーストア・データベースはinstance-path/alias/cert.jksにあります。

対称暗号化キーのキーストア・データベース

このキーストア・データベースはinstance-path/alias/key.jceksにあります。

キーストア・データベースは同じパスワードで保護されています。

SSLの詳細は、「Secure Sockets Layer (SSL)」を参照してください。ログ・ファイルの構成方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のクライアントとDirectory Proxy Serverの間のリスナーの構成に関する説明を参照してください。

Directory Proxy ServerではStart TLS拡張操作がサポートされています。StartTLSを使用して通常のLDAP接続に対するセキュリティを提供できます。StartTLSでは、クライアントは非セキュア・ポートをバインドしてからTLSプロトコルを使用してセキュア接続を開始できます。

22.3 Directory Proxy Serverの暗号およびプロトコル

Directory Proxy Serverで使用できる暗号およびプロトコルは、使用されているJVMに応じて異なります。デフォルトで、Directory Proxy ServerはJVM用のデフォルトの暗号およびプロトコルを使用します。

暗号およびプロトコルのリストはdpconfコマンドを使用して取得できます。

有効化されている暗号

LDAPリスナーおよびLDAPSリスナーの両方に対して現在有効にされている暗号のリストです。LDAPリスナーとLDAPSリスナーは同期されるため、プロパティはグローバル・サーバー構成の一部であり、リスナー構成の一部ではありません。

サポートされている暗号

Directory Proxy Serverに対してJVMによりサポートされている暗号のリストです。

ルートDSEには、supportedSSLCiphers属性でサポートされているすべての暗号がリストされています。

enabledSSLCiphers属性はsupportedSSLCiphers属性のサブセットです。

有効化されているプロトコル

LDAPリスナーおよびLDAPSリスナーの両方に対して現在有効にされているプロトコルのリストです。LDAPリスナーとLDAPSリスナーは同期されるため、プロパティはグローバル・サーバー構成の一部であり、リスナー構成の一部ではありません。

サポートされているプロトコル。

Directory Proxy Serverに対してJVMによりサポートされているプロトコルのリストです。

暗号スイートのリファレンス情報については、「SSLで使用される暗号化アルゴリズム」を参照してください。ログ・ファイルの構成方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のDirectory Proxy ServerのSSL暗号およびSSLプロトコルの選択に関する説明を参照してください。

23 Directory Proxy Serverのロギング

Directory Proxy Serverはアクセス・ログおよびエラー・ログに情報をロギングします。さらに、プラグインを構成してsyslogデーモンにメッセージをロギングすることができます。Directory Serverとは異なり、Directory Proxy Serverには監査ログが用意されていません。

Directory Proxy Serverのログ・ファイルは、Directory Service Control Centerまたはコマンドラインを使用して構成できます。ログ・ファイルの構成方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の第27章「Directory Proxy Serverのロギング」を参照してください。

アクセス・ログおよびエラー・ログの詳細は、次の項を参照してください。

- Directory Proxy Serverのログの概要

- ログ・ファイルのローテーション

- ログ・ファイルの削除

- メッセージの重大度

- Directory Proxy Serverのエラー・ログ

- Directory Proxy Serverのアクセス・ログ

- Directory Proxy Serverのバインド・ログ

- Directory Proxy Serverの接続ログ

- Directory Proxy ServerおよびDirectory Serverのアクセス・ログを介したクライアント・リクエストの追跡

このリリースのDirectory Proxy Serverではログ・メッセージのフォーマットをまだ改良中です。

23.1 Directory Proxy Serverのログの概要

Directory Proxy Serverのロギング・サービスはアクセス・ログおよびエラー・ログを提供します。ログは、クライアント操作およびDirectory Proxy Serverの健全性に関する情報が含まれているフラット・ファイルです。デフォルトで、ログ・ファイルは権限600を使用してinstance-path/logsに格納されます。Directory Proxy Serverが有効なログ・ファイルなしに起動された場合、ログ・ファイルがデフォルトの場所に作成され、警告がDSCCに送信されます。

ログの次の部分を構成できます。

- 各メッセージ・カテゴリのログ・レベルの設定

- すべてのログ・カテゴリのデフォルト・ログ・レベルのグローバル設定

- すべてのログのグローバルな有効化

- ログ・ファイルの名前、場所、および権限の名前

- ログ・ファイルの最大数の設定

- 各ログ・ファイルのローテーション・ポリシーの定義

- 検索操作のログ・メッセージの検索フィルタを含める、または除外する

ログ・メッセージはsyslogデーモンにも送信できます。syslogデーモンへのメッセージのログ方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のsyslogdデーモンに対するアラートのロギングに関する説明を参照してください。

23.2 ログ・ファイルのローテーション

ログ・ファイルは手動で随時ローテーションでき、または、次のイベントの発生時に自動的にローテーションできます。

- 指定されたサイズにログが達したとき

- 指定した間隔で

- 指定された開始時間、開始日、および間隔で

- 指定された開始時間、開始日、および間隔で(指定されたサイズよりもログ・ファイルが大きい場合)

- 指定された間隔で(指定されたサイズよりもログ・ファイルが大きい場合)

開始時間、開始日、および間隔は次の組合せが可能です。

- 時刻の後に、間隔(日数、時間数、または分数)

- 曜日および時刻の後に、間隔(週数)

- 日付および時刻の後に、間隔(月数)

時刻は間隔よりも優先されます。たとえば、午前3時に10時間ごとのローテーションを指定されているログは、03:00、13:00、23:00、そして再び03:00 (07:00ではありません)にローテーションされます。

31日にローテーションするようにログが構成されているが、31日がない月の場合、ログは次の月の最初の日にローテーションされます。

ログ・ファイルは、使用するディスク・スペースの一部をリカバリするために、ローテーション時に自動的に圧縮できます。

23.3 ログ・ファイルの削除

ログ・ファイルの削除ポリシーは、バックアップ・ログ・ファイルがいつ削除されるかを定義します。現在使用中のログ・ファイルが削除ポリシーによって削除されることはありません。

次の削除ポリシーを有効にできます。

- 時間に基づいた削除ログ・ファイルは、指定された時期に達したときに削除されます。

- サイズに基づいた削除ログ・ファイルは、すべてのログ・ファイルの合計サイズが、指定された限界に達したときに削除されます。現在のログ・ファイルのサイズは、このファイルが削除されない場合も計算に入ります。

- 空きディスク領域に基づく削除。空きディスク領域が指定された最小サイズに達したときに、最も古いバックアップ・ログ・ファイルが削除されます。それでもまだ空きディスク領域が最小サイズを下回っている場合は、次に古いバックアップ・ログ・ファイルが削除される、というように続きます。

デフォルトで、ログ・ファイルの削除は空きディスク領域に基づき、デフォルト値は1メガバイトです。3つの削除ポリシーが同時にアクティブになっている場合は、時間、サイズ、空きディスク領域の順で処理されます。ログ・ファイルの削除を構成する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のDirectory Proxy Serverのログの削除に関する説明を参照してください。

23.4 メッセージの重大度

メッセージの重大度、メッセージのカテゴリ、およびそのカテゴリに設定されたログ・レベルに従って、各メッセージはログ・ファイルに含まれるか、ログ・ファイルから除外されます。エラー・ログとアクセス・ログのカテゴリおよびログ・レベルは異なっており、後に続く各項で説明されます。

メッセージは重大度に従ってランク付けされます。メッセージは次の重大度のいずれかが可能ですが、error (エラー)の重大度が最高で、debug (デバッグ)の重大度が最低です。

1. error (エラー)

2. warning (警告)

3. info (情報)

4. debug (デバッグ)

このメッセージ・カテゴリに設定されたログ・レベルよりも低い重大度のメッセージは、ログ・ファイルに含まれません。関連付けられたメッセージ・カテゴリに設定されたログ・レベル以上の重大度のメッセージは、ログ・ファイルに含まれます。

23.5 Directory Proxy Serverのエラー・ログ

エラー・ログにはDirectory Proxy Serverの健全性に関する情報が含まれています。エラー・メッセージはメッセージの原因に従って分類されます。次の表は、エラー・ログに含むことができるメッセージ・カテゴリのリストです。

表23-1 エラー・ログのメッセージ・カテゴリ

カテゴリ名

カテゴリの説明

CONFIG

構成に関する情報

DECODE

操作のデコードに関する情報

PLUGIN

プラグイン処理に関する情報

PROCESSING

クライアント処理中に発生した重要なイベントに関する情報

BACKEND

データ・ソースの操作に関する情報

INTERNAL

コア・サーバーの内部エラーに関する情報

SHUTDOWN

サーバー・シャットダウン時のイベントに関する情報

STARTUP

サーバー起動時のイベントに関する情報

23.5.1 エラー・ログ・レベル

各メッセージ・カテゴリは、次のいずれかのログ・レベルで構成できます。

1. none ログ・ファイルにメッセージは含まれません。

2. error ログ・ファイルにエラー・メッセージのみが含まれます。

3. warning ログ・ファイルにエラー・メッセージと警告メッセージが含まれます。

4. info ログ・ファイルにエラー・メッセージ、警告メッセージおよび情報メッセージが含まれます。

5. all ログ・ファイルにすべてのメッセージが含まれます。ほとんどの場合、この設定はinfo設定と同じ結果となります。特定の状況において、この設定では追加のデバッグ・メッセージをロギングできます。

6. inherited ログ・レベルはdefault-log-levelプロパティの値から継承されます。

デフォルトで、各メッセージ・カテゴリのログ・レベルはinheritedです。default-log-levelプロパティがinfoに設定されていると、各カテゴリはinfoログ・レベルを継承します。

メッセージ・カテゴリのログ・レベルは、メッセージの重大度レベルと関連して機能し、ログ・ファイルに含まれるメッセージを判別します。詳細は「メッセージの重大度」を参照してください。

23.5.2 エラー・メッセージのフォーマット

エラー・ログ・メッセージのフォーマットは次のとおりです。

timestamp - message category - message severity - message text

例23-1は、エラー・ログの抜粋を示しています。

例23-1 エラー・ログの抜粋

[11/Feb/2010:14:52:28 +0100] - STARTUP    - INFO  - Logging Service configured
[11/Feb/2010:14:52:28 +0100] - STARTUP    - INFO  - Java Version: 1.6.0_16
(Java Home: /local/instances/dsee7/jre)
[11/Feb/2010:14:52:28 +0100] - STARTUP    - INFO  - Java(TM) SE Runtime Environment
(build 1.6.0_16-b01)
[11/Feb/2010:14:52:28 +0100] - STARTUP    - INFO  - Java HotSpot(TM) 64-Bit Server VM
(build 14.2-b01, mixed mode)
[11/Feb/2010:14:52:28 +0100] - STARTUP    - INFO  - Java Heap Space: Total Memory
(-Xms) = 241MB, Max Memory (-Xmx) = 241MB
[11/Feb/2010:14:52:28 +0100] - STARTUP    - INFO  - Operating System:
SunOS/sparcv9 5.10
[11/Feb/2010:14:52:29 +0100] - STARTUP    - INFO  - SSL initialization succeeded.
[11/Feb/2010:14:52:29 +0100] - CONFIG     - WARN  - Attribute
certMappingDataViewPolicy in entry cn=LDAPS Listener,cn=Client
Listeners,cn=config missing. Using ALL_DATA_VIEW
[11/Feb/2010:14:52:29 +0100] - STARTUP    - INFO  - Creating 50 worker threads.
[11/Feb/2010:14:52:30 +0100] - STARTUP    - INFO  - Sun-Directory-Proxy-Server/7.0
B2009.1104.2146 started on host lecap in directory /local/instances/dps-1
[11/Feb/2010:14:52:30 +0100] - STARTUP    - INFO  - Listening for client connections
on 0.0.0.0:1389
[11/Feb/2010:14:52:30 +0100] - STARTUP    - INFO  - Listening for secure client
connections on 0.0.0.0:1636
[11/Feb/2010:14:52:31 +0100] - BACKEND    - WARN  - LDAP server groupy:11998/ is
up and running.
[11/Feb/2010:17:43:10 +0100] - SHUTDOWN   - INFO  - Directory Proxy Server received a
shutdown request from external signal (caught by shutdown hook)
[11/Feb/2010:17:43:10 +0100] - BACKEND    - WARN  - LDAP server groupy:11998/ is up
and running.
[11/Feb/2010:17:43:11 +0100] - SHUTDOWN   - INFO  - Directory Proxy Server stopped.
[11/Feb/2010:17:43:19 +0100] - STARTUP    - INFO  - Logging Service configured
[11/Feb/2010:17:43:19 +0100] - STARTUP    - INFO  - Java Version: 1.6.0_16
(Java Home: /local/instances/dsee7/jre)
[11/Feb/2010:17:43:19 +0100] - STARTUP    - INFO  - Java(TM) SE Runtime Environment
(build 1.6.0_16-b01)
[11/Feb/2010:17:43:19 +0100] - STARTUP    - INFO  - Java HotSpot(TM) 64-Bit Server VM
(build 14.2-b01, mixed mode)
[11/Feb/2010:17:43:19 +0100] - STARTUP    - INFO  - Java Heap Space: Total Memory
(-Xms) = 241MB, Max Memory (-Xmx) = 241MB
[11/Feb/2010:17:43:19 +0100] - STARTUP    - INFO  - Operating System:
SunOS/sparcv9 5.10
[11/Feb/2010:17:43:19 +0100] - STARTUP    - INFO  - Initializing LDAP server
cn=dscc_ldap_groupy:11998,cn=data sources,cn=config
[11/Feb/2010:17:43:19 +0100] - STARTUP    - INFO  - SSL initialization succeeded.
[11/Feb/2010:17:43:20 +0100] - CONFIG     - WARN  - Attribute certMappingDataViewPolicy
in entry cn=LDAPS Listener,cn=Client Listeners,cn=config missing. Using ALL_DATA_VIEW

23.6 Directory Proxy Serverのアクセス・ログ

アクセス・ログにはDirectory Proxy Serverにより処理されているリクエストに関する情報が含まれています。アクセス・ログには2つのタイプの接続に関する情報が含まれます。

- クライアントとDirectory Proxy Server間の接続

- Directory Proxy Serverとデータ・ソース間の接続

アクセス・ログのメッセージはメッセージの原因に従って分類されます。次の表は、アクセス・ログに含むことができるメッセージ・カテゴリのリストです。

表23-2 アクセス・ログのメッセージ・カテゴリ

カテゴリ名

カテゴリの説明

CONNECT

クライアント接続に関する情報

DISCONNECT

クライアント切断に関する情報

OPERATION

クライアントにより要求された操作に関する情報

PROFILE

接続ハンドラのプロファイルに関する情報

SERVER_OP

データ・ソースへ転送される操作に関する情報

SERVER_OP_DETAIL

データ・ソースへ転送される操作に関する詳細情報

23.6.1 アクセス・ログ・レベル

各メッセージ・カテゴリは、次のいずれかのログ・レベルで構成できます。

1. none ログ・ファイルにアクセス・メッセージは含まれません。

2. info ログ・ファイルに情報メッセージが含まれます。

3. all ログ・ファイルにすべてのメッセージが含まれます。ほとんどの場合、この設定はinfo設定と同じ結果となります。特定の状況において、この設定では追加のデバッグ・メッセージをロギングできます。

4. inherited ログ・レベルはdefault-log-levelプロパティの値から継承されます。

デフォルトで、各メッセージ・カテゴリのログ・レベルはinheritedですが、SERVER_OP_DETAILの場合、ログ・レベルはnoneです。default-log-levelプロパティがinfoに設定されていると、SERVER_OP_DETAILを除くすべてのメッセージ・カテゴリはログ・レベルinfoを継承します。

メッセージ・カテゴリのログ・レベルは、メッセージの重大度レベルと関連して機能し、ログ・ファイルに含まれるメッセージを判別します。詳細は「メッセージの重大度」を参照してください。

23.6.2 アクセス・ログ・メッセージのフォーマット

アクセス・ログ・メッセージのフォーマットは次のとおりです。

timestamp - category - severity - connectionNumber operationNumber
messageID operationType messageText

例23-2はアクセス・ログの抜粋を示しています。このログは、CONNECTカテゴリのメッセージで開始され、DISCONNECTカテゴリのメッセージで終了するクライアント・リクエストを示しています。クライアントにより要求された操作はOPERATIONカテゴリのメッセージにより示され、SERVER_OPカテゴリの複数のメッセージの結果で終了します。ロギングされたメッセージの重大度はINFOおよびDEBUGです。

例23-2 アクセス・ログの抜粋

[07/Sep/2010:14:32:43 +0200] - PROFILE        - INFO -
conn=12 assigned to connection handler cn=default connection handler,
cn=connection handlers, cn=config
[07/Sep/2010:14:32:43 +0200] - CONNECT      - INFO -
conn=12 client=127.0.0.1:59723 server=localhost:14600 protocol=LDAP
[07/Sep/2010:14:32:43 +0200] - OPERATION   - INFO -
conn=12 op=0 msgid=1 BIND dn="uid=jvedder,ou=people,dc=example,dc=com"
method="SIMPLE" version=3 controls=""
[07/Sep/2010:14:32:43 +0200] - SERVER_OP   - INFO -
conn=12 op=0 BIND dn="uid=jvedder,ou=people,dc=example,dc=com"
method="SIMPLE" version=3 s_msgid=396 s_conn=dsource-1:2
[07/Sep/2010:14:32:43 +0200] - SERVER_OP   - INFO -
conn=12 op=0 BIND RESPONSE err=0 msg="" s_msgid=396 s_conn=dsource-1:2 etime=0
[07/Sep/2010:14:32:43 +0200] - OPERATION   - INFO -
conn=12 op=0 BIND RESPONSE err=0 msg="" etime=1
[07/Sep/2010:14:32:43 +0200] - OPERATION   - INFO -
conn=12 op=1 msgid=2 SEARCH base="uid=jvedder,ou=people,dc=example,dc=com"
scope=2 controls="" filter="(objectclass=*)" attrs="*"
[07/Sep/2010:14:32:43 +0200] - SERVER_OP   - INFO -
conn=12 op=1 SEARCH base="uid=jvedder,ou=people,dc=example,dc=com"
scope=2 filter="(objectclass=*)" attrs="*" s_msgid=397 s_conn=dsource-1:2
[07/Sep/2010:14:32:43 +0200] - SERVER_OP   - INFO -
conn=12 op=1 SEARCH RESPONSE err=0 msg="" nentries=1
s_msgid=397 s_conn=dsource-1:2 etime=1
[07/Sep/2010:14:32:43 +0200] - OPERATION   - INFO - conn=12 op=1 SEARCH RESPONSE
err=0 msg="" nentries=1 etime=1
[07/Sep/2010:14:32:43 +0200] - OPERATION   - INFO - conn=12 op=2 UNBIND
[07/Sep/2010:14:32:43 +0200] - DISCONNECT - INFO - conn=12 reason="unbind"

23.6.3 アクセス・ログのメッセージの各部分

クライアントとDirectory Proxy Server間の接続についてのメッセージは、Directory Serverと同じ方法でラベル付けされます。表23-4は、例23-2のクライアントとDirectory Proxy Server間のメッセージの各部分を説明しています。考えられるすべてのメッセージ部分の説明については、「アクセス・ログ、エラー・ログおよび監査ログの内容」を参照してください。

表23-3 クライアントとDirectory Proxy Server間の接続のメッセージの各部分

ログ・メッセージの部分

説明

conn

クライアントとDirectory Proxy Server間の接続の識別子

op

指定された接続に対する操作の数。接続に対する最初の操作の値はop=0です。この接続に対する以降のリクエストは、op=1、op=2というように数が増えます。

msgid

クライアント・アプリケーションに送信されたメッセージの数。LDAPプロトコルは主として非同期です。クライアント・リクエストがサーバーからのレスポンスを要求した場合、レスポンスは次の手順で行われます。

- ディレクトリ・サーバーがリクエストを確認し、msgidを割り当てます。

- ディレクトリ・サーバーはmsgid識別子を使用してリクエストに応答します。

レスポンスは複数のパケットで送信され、各パケットは同じmsgidによって識別されます。

nentries

検索リクエストにより返されるエントリの数。

err

LDAP操作から返される結果コード。エラー番号0は、操作が正常に終了したことを意味します。LDAP結果コードのリストについては、「ログ・ファイルにおける結果コード」を参照してください。

msg

判別可能なエラー診断。

etime

SERVER_OPメッセージの場合、これはDirectory Proxy Serverから見てデータ・ソースにより実行された当該操作にかかった時間です。

OPERATIONメッセージの場合、これはDirectory Proxy Serverにより実行された当該操作にかかった時間です。

いずれの場合も、サーバーのlog-etimes-in-secondsプロパティがtrueに設定されている場合、この時間は秒数で表され、log-etimes-in-secondsプロパティがfalseに設定されている場合は、サーバーのtime-resolutionプロパティの値に対応した単位で表されます。

Directory Proxy Serverとデータ・ソース間の接続のメッセージにはs_のサフィックスが付きます。表23-4は、例23-2のDirectory Proxy Serverとデータ・ソース間のメッセージの各部分を説明しています。

表23-4 Directory Proxy Serverとデータ・ソース間の接続のメッセージの各部分

ログ・メッセージの部分

説明

s_msgid

Directory Proxy Serverとデータ・ソース間のメッセージの識別子。

s_authzid

Directory Proxy Serverがプロキシ認可を使用してデータ・ソースへリクエストを転送するときに処理される操作の認可アイデンティティ。

s_conn

Directory Proxy Serverとデータ・ソース間の接続の識別子。

23.6.4 アクセス・ログ・バッファ

アクセス・ログ・メッセージはバッファに格納されます。バッファはアクセス・ログに対して次の時点でフラッシュされます。

- バッファが一杯になったとき

- アクセス・ログがローテーションされたとき

- Directory Proxy Serverが停止したとき

- 2.5秒ごと

デフォルトで、アクセス・ログ・バッファのサイズは1Mです。ただし、バッファのサイズを構成してフラッシュされる頻度を制御できます。バッファ・サイズを0に設定すると、バッファリングが無効に(Directory Proxy Serverが遅く)なります。

他の条件がいずれも満たされない場合も、バッファは2.5秒ごとに定期的にフラッシュされます。

log-buffer-sizeプロパティを設定することにより、アクセス・ログ・バッファのサイズを構成できます。アクセス・ログ・プロパティの構成方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のDirectory Proxy Serverのログの構成に関する説明を参照してください。

23.7 Directory Proxy Serverのバインド・ログ

バインド・ログにはクライアントから受信された正常なバインド操作に関する情報が含まれています。これはアクセス・ログに置かれる情報と同じですが、古いアクセス・ログが削除されるときに失われるのを防ぐために、この情報が複製されます。

23.7.1 バインド・ログ・メッセージのフォーマット

バインド・ログ・メッセージのフォーマットは次のとおりです。

timestamp - category - severity -
connectionNumber operationNumber messageID operationType messageText

カテゴリは常にBINDで、重大度は常にINFOです。

例23-3 バインド・ログの抜粋

[07/Sep/2010:14:32:38 +0200] - BIND - INFO - conn=11 op=1 msgid=2 BIND
dn="cn=proxy manager" method="NONE" version=3 controls=""

[07/Sep/2010:14:32:43 +0200] - BIND - INFO - conn=12 op=0 msgid=396 BIND
dn="uid=jvedder,ou=people,dc=example,dc=com" method="SIMPLE" version=3 controls=""

23.7.2 バインド・ログのメッセージの部分

バインド・メッセージはアクセス・ログのバインド・メッセージに似ています。「アクセス・ログ、エラー・ログおよび監査ログの内容」を参照してください。

23.7.3 バインド・ログ・バッファ

バインド・ログ・メッセージはバッファに格納されます。バッファはバインド・ログに対して次の時点でフラッシュされます。

- バッファが一杯になったとき

- バインド・ログがローテーションされたとき

- Directory Proxy Serverが停止したとき

- 2.5秒ごと

デフォルトで、バインド・ログ・バッファのサイズは1Mです。ただし、バッファのサイズを構成してフラッシュされる頻度を制御できます。バッファ・サイズを0に設定すると、バッファリングが無効に(Directory Proxy Serverが遅く)なります。

log-buffer-sizeプロパティを設定することにより、バインド・ログ・バッファのサイズを構成できます。バインド・ログ・プロパティの構成方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のDirectory Proxy Serverのログの構成に関する説明を参照してください。

23.8 Directory Proxy Serverの接続ログ

接続ログにはクライアントにより確立された接続と、その切断に関する情報が含まれています。これはアクセス・ログに置かれる情報と同じですが、古いアクセス・ログが削除されるときに失われるのを防ぐために複製されます。

接続ログのメッセージはメッセージの原因に従って分類されます。次の表は、接続ログに含むことができるメッセージ・カテゴリのリストです。

表23-5 接続ログ・メッセージのカテゴリ

カテゴリ名

説明

CONN_CONNECT

クライアント接続に関する情報

CONN_DISCONNECT

クライアント切断に関する情報

23.8.1 接続ログ・メッセージのフォーマット

接続ログ・メッセージのフォーマットは次のとおりです。

timestamp - category - severity -
connectionNumber operationNumber messageID operationType messageText

重大度は常にINFOです。

例23-4 接続ログの抜粋

[06/Sep/2010:15:10:29 +0200] - CONN_CONNECT  - INFO -
conn=110 client=127.0.0.1:44344 server=localhost:14600 protocol=LDAP
[06/Sep/2010:15:10:30 +0200] - CONN_DISCONNECT - INFO -
conn=110 reason="unbind"
[06/Sep/2010:15:15:09 +0200] - CONN_CONNECT  - INFO -
conn=111 client=127.0.0.1:44364 server=localhost:14600 protocol=LDAP
[06/Sep/2010:15:15:10 +0200] - CONN_DISCONNECT - INFO -
conn=111 reason="unbind"
[06/Sep/2010:15:47:37 +0200] - CONN_CONNECT  - INFO -
conn=112 client=127.0.0.1:55225 server=localhost:14600 protocol=LDAP
[06/Sep/2010:15:48:10 +0200] - CONN_CONNECT  - INFO -
conn=113 client=127.0.0.1:55244 server=localhost:14600 protocol=LDAP
[06/Sep/2010:15:49:08 +0200] - CONN_DISCONNECT - INFO -
conn=112 reason="unbind"
[06/Sep/2010:15:50:10 +0200] - CONN_DISCONNECT - INFO -
conn=113 reason="unbind"

23.8.2 接続ログのメッセージの部分

接続メッセージおよび切断メッセージは、アクセス・ログの接続メッセージと切断メッセージに似ています。「アクセス・ログ、エラー・ログおよび監査ログの内容」を参照してください。

23.8.3 接続ログ・バッファ

バインド・ログ・メッセージはバッファに格納されます。バッファはバインド・ログに対して次の時点でフラッシュされます。

- バッファが一杯になったとき

- バインド・ログがローテーションされたとき

- Directory Proxy Serverが停止したとき

- 2.5秒ごと

デフォルトで、接続ログ・バッファのサイズは1Mです。ただし、バッファのサイズを構成してフラッシュされる頻度を制御できます。バッファ・サイズを0に設定すると、バッファリングが無効に(Directory Proxy Serverが遅く)なります。

log-buffer-sizeプロパティを設定することにより、バインド・ログ・バッファのサイズを構成できます。バインド・ログ・プロパティの構成方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のDirectory Proxy Serverのログの構成に関する説明を参照してください。

23.9 Directory Proxy ServerおよびDirectory Serverのアクセス・ログによるクライアント・リクエストの追跡

アクセス・ログはサーバーへのクライアント・アクセスとそれに対するサーバーのレスポンスを示します。Directory Proxy Serverのアクセス・ログはさらに、データ・ソース(この場合はDirectory Serverのインスタンス)に対する接続のセットアップに関する情報も示します。

クライアント・リクエストの追跡は、次の手順に分けることができます。

- 単一のクライアント接続内で実行された操作の追跡

- 特定の操作を実行したクライアントの識別

23.9.1 接続のトラックの単純化

「接続のトラック」機能を有効化することを強く推奨します。この機能により、Directory Proxy Serverはアクセス・ログで、Directory Serverがそのアクセス・ログで使用する識別子と同じ識別子を使用できます。(Directory Proxy Serverにはさらに、データ・ソース名のサフィックスがつきます。)これにより、接続のトラックというタスクが単純化されます。

Directory Proxy Serverで接続のトラック機能を有効化するには、次のコマンドを使用します。

$ dpconf set-ldap-data-source-prop myDataSource conn-track-enabled:true

この機能は各データ・ソースについて個別に有効化でき、LDAPリクエストのレスポンスとしての接続識別子を提供できるすべてのバックエンドをサポートします。リクエストのパラメータはすべて(ベースDN、スコープ、フィルタ、属性、バインドDNおよびパスワード)ユーザが構成できます。デフォルト値は、ODSEEのDirectory Serverに必要な値に一致するように定義されています。

各接続の作成と関連して、バックエンド・サーバーの接続識別子を取得するために、Directory Proxy Serverにより発行されたリクエストに対応する行を見つけます。

[timestamp] - SERVER_OP  - INFO  - conn=-1 op=-1 SEARCH base="cn=monitor" scope=0 filter="(objectClass=*)" attrs="clientConnectionID " s_msgid=1
[timestamp] - SERVER_OP  - INFO  - conn=-1 op=-1 SEARCH RESPONSE err=0 msg="" nentries=1 s_msgid=1
[timestamp] - SERVER_OP  - INFO  - Created connection for BIND s_conn=server-1:244  client=192.168.192.132:59100

バインドDNおよびパスワードを構成してある場合は、これらの行の前にバインド操作が配置される場合もあります。

接続のトラッキングが有効になっているとき、Directory Proxy Serverの識別子の番号部分の前に、文字dを置くことができます。

[timestamp] - SERVER_OP  - INFO  - conn=-1 op=-1 SEARCH base="cn=wrong base" scope=0 filter="(objectClass=*)" attrs="wrongAttribute " s_msgid=1
[timestamp] - SERVER_OP  - INFO  - conn=-1 op=-1 SEARCH RESPONSE err=32 msg="" nentries=0 s_msgid=1
[timestamp] - SERVER_OP - INFO - Created connection for BIND s_conn=server-2:d104 client=192.168.192.115:35100

サフィックスのdは、おそらくは構成に誤りがあったために、バックエンド・サーバーにより使用される接続識別子の取得にDirectory Proxy Serverが失敗したため、接続のトラッキングが無効になっているかのように、独自の接続番号を使用するように切り替えたことを示します。

23.9.2 接続ごとのトラッキング操作

Directory Proxy Serverは一般的に、クライアント接続を処理する前にバックエンド・サーバーへの接続をセットアップします。これには、Directory Proxy Serverがプール内の接続を維持し、必要な場合にのみバインディングと再バインディングを行って接続セットアップのオーバーヘッドを避ける意味があります。Directory Proxy Serverは、s_conn=data-source:numberという形式のタグを使用してこれらのバックエンド接続をアクセス・ログで識別します(data-sourceは構成のデータ・ソース名、numberはプロキシにより割り当てられたサーバー接続番号)。接続のトラッキング機能が有効になっていた場合、Directory Proxy ServerとDirectory Serverは接続のnumberを共有します。それ以外の場合、こうしたs_connサーバー接続は、接続の確立時にプロキシがクライアントとしてディレクトリに接続したときのポート番号を使用して、Directory Serverのアクセス・ログの接続番号に対して突き合わせることができます。したがって、プロキシ・アクセス・ログ・メッセージのs_connは、ディレクトリ・アクセス・ログ・メッセージのconnに変換できます。

23.9.2.1 Directory Proxy Serverのトラッキング操作

Directory Proxy Serverのアクセス・ログでは、各クライアント操作が1つのCONNECTメッセージおよび1つのDISCONNECTメッセージに含まれています。これらの2つのメッセージ間に、複数のOPERATIONメッセージが表示される場合があります。各OPERATIONメッセージは複数のSERVER_OPメッセージを含むことができます。

OPERATIONメッセージとはクライアントにより実行された操作のことです。SERVER_OPメッセージとはDirectory Proxy Serverによって実行された操作のことです。

次のDirectory Proxy Serverのアクセス・ログの抜粋は、接続conn=0の開始(CONNECT)および終了(DISCONNECT)を示しています。ログは、クライアントによりこの接続に対して実行されたすべてのOPERATIONリクエストおよび、クライアントに代わってDirectory Proxy Serverによってバックエンド・サーバーに送信された関連のSERVER_OPリクエストを示しています。

[timestamp] - CONNECT    - INFO  - conn=0 client=192.168.192.132:59112 server=0.0.0.0:9389 protocol=LDAP[timestamp] - OPERATION  - INFO  - conn=0 op=0 BIND dn="uid=u1,ou=users,o=movie" method="SIMPLE"[timestamp] - SERVER_OP  - INFO  - conn=0 op=0 BIND dn="uid=u1,ou=users,o=movie" method="SIMPLE" s_msgid=2 s_conn=server-1:244[timestamp] - SERVER_OP  - INFO  - conn=0 op=0 BIND RESPONSE err=0 msg="" s_conn=server-1:244[timestamp] - OPERATION  - INFO  - conn=0 op=0 BIND RESPONSE err=0 msg="" etime=0[timestamp] - OPERATION  - INFO  - conn=0 op=1 msgid=2 SEARCH base="o=movie" scope=2 filter="(objectclass=*)"[timestamp] - SERVER_OP  - INFO  - conn=0 op=1 SEARCH base="o=movie" scope=2 filter="(objectclass=*)" s_msgid=3 s_conn=server-1:244[timestamp] - SERVER_OP  - INFO  - conn=0 op=1 SEARCH RESPONSE err=0 msg="" nentries=12 s_conn=server-1:244[timestamp] - OPERATION  - INFO  - conn=0 op=1 SEARCH RESPONSE err=0 msg="" nentries=12 etime=0[timestamp] - OPERATION  - INFO  - conn=0 op=2 UNBIND[timestamp] - DISCONNECT - INFO  - conn=0 reason="unbind"

このログを辿れば、特定のクライアントによって、または特定のクライアントのために実行されたすべての操作をトラッキングできます。

23.9.2.2 Directory Proxy ServerおよびDirectory Server間の操作のトラッキング

Directory Proxy Serverは起動時に、その構成内で識別されるすべてのリモート・サーバーとの接続を確立します。これらの接続はDirectory Proxy Serverのアクセス・ログに記録され、フィールドs_conn=server-name:numberにより識別されます。server-nameはDirectory Proxy Serverの構成で定義される、特定のバックエンド・サーバーのことです。この番号がバックエンド・サーバーへの接続を識別します。

たとえば、Directory Proxy Serverの次の抜粋で、s_conn=server-1:244はポート59100を介した、リモート・サーバーserver-1への接続です。

[timestamp] SSERVER_OP - INFO - Created connection for BIND s_conn=server-1:244  client=192.168.192.132:59100

この接続が確立されると、Directory Serverのアクセス・ログの該当する行に、ポート59100を介したDirectory Proxy Serverからの接続が接続ID conn=244により識別されることが表示されます。

[timestamp] conn=244 op=-1 msgId=-1 - fd=19 slot=19 LDAP connection from 192.168.192.132:59100 to 192.168.192.132

この接続IDは、conn-track-enabledプロパティがtrueに設定されている場合にのみ、Directory Proxy ServerおよびDirectory Serverとで同じです。それ以外の場合、IDは一致せず、ポート番号を使用して手動でマッピングする必要があります。

この接続の残りの存続時間について、Directory Proxy Serverのserver-1:244をDirectory Serverのconn=244にマップできます。

Directory Proxy ServerからバックエンドのDirectory Serverへの接続は数日間存続できることに注意してください。自動的にせよ手動でにせよ、ログをローテーションした場合は、接続中に実行された操作をトレースするためにアーカイブ済ログ・ファイルへのアクセスが必要になることがあります。この情報は、ログがアクティブにされたときにも接続ログに表示されます。

23.9.3 クライアント識別

クライアントはそのIPアドレスと、オプションでそのバインドDNにより、アクセス・ログで識別されます。クライアントがDirectory Proxy Serverへの接続を確立すると、Directory Proxy Serverのアクセス・ログには次のようなメッセージが記録されます。

[timestamp] - CONNECT  - INFO  - conn=45 client=IP1:port1 server=IP2:port2 protocol=LDAP

Directory Proxy Serverはこのクライアント接続をconn=45として識別します。

Directory Proxy ServerがリモートのDirectory Serverとの接続を確立したときには、Directory Proxy Serverのアクセス・ログに次のようなメッセージが記録されます。

[timestamp] - SERVER_OP  - INFO  - Created connection for READ s_conn=server-1:103 client=IP2:port3 server=IP4:port4 protocol=LDAP main

Directory Proxy Serverはリモート・サーバーへのこの接続をs_conn=server-1:103として識別します。

同時に、Directory Serverのアクセス・ログには次のようなメッセージが記録されます。

[timestamp] conn=103 op=-1 msgId=-1 - fd=23 slot=23 LDAP connection from IP2:port3 to IP4

Directory Serverはこの接続をconn=103として識別します。

識別子は、接続のトラッキング機能が有効になっている場合にのみ一致します。

このようにして接続のトラッキングにより、ユーザーはクライアントからDirectory Serverへの接続の絶対パスを識別できます。

Directory Proxy Serverはリモート・サーバーへの接続を確立する前には、クライアント接続への待機を行いません。Directory Proxy Serverの構成は、特定の接続をバインド操作専用とし、それ以外の接続を読取り操作、そして書込み操作用に指定します。Directory Proxy Serverは起動時に、この構成に従ってリモート・サーバーへのすべての接続を確立します。

接続(クライアントからDirectory Serverへの)が完全に確立されると、クライアントはそのDNにより識別できます。

Directory ServerはそのクライアントDNを次のいずれかとして認識します。

- 真のクライアント・バインドDN。Directory Proxy Serverがバインドを使用モードで構成されている場合、このバインドDNは、クライアント固有のバインドDNです。

- 変更されたクライアント・バインドDN。このバインドDNは、Directory Proxy Serverがユーザー・プロキシ認証制御モードで構成されている場合に変更されます。DNはDNリネーム変換またはユーザー・マッピングの結果、変更されます。

1つの接続は複数のクライアントにより使用できます(ただし、同時には使用できません)。アクセス・ログでクライアント接続を正確に識別するには、Directory Proxy ServerとDirectory Serverを同期させる、つまり、サーバー・クロックをできるだけ近づける必要があります。これにより、両者のアクセス・ログのタイムスタンプが対応することが保証されます。サーバーが同期されていない場合、ユーザーがタイム・サーバーを使用して同期するか、サーバー・クロック間の差を評価し、この差を考慮してアクセス・ログを検索する必要があります。

24 Directory Proxy Serverのアラートおよび監視

Directory Proxy Serverは、それ自体の状態に関する監視情報を提供します。また、Directory Proxy Serverは、データソースを監視して、それらが稼働しているかどうか、および失敗した接続を検出するかどうかを判断します。データソースが失敗すると、Directory Proxy Serverは、新しいリクエストをデータソース・プール内の動作中のデータソースに切り換え、失敗したリクエストをこの新しいデータソースにリプレイすることができます。

この章では、Directory Proxy Serverでの監視の実装方法について説明します。この章の内容は次のとおりです。

- Directory Proxy Serverの管理アラート

- データソースの監視

- Directory Proxy Serverの監視

24.1 Directory Proxy Serverの管理アラート

Directory Proxy Serverは、事前定義済の管理アラートのセットを生成します。1つ以上の事前定義済の管理アラートを選択して、アラート・イベントが発生したときに、特定の操作を実行するようDirectory Proxy Serverを構成することができます。

次のような操作を実行できます。

- syslogエントリを作成する。USERの機能を使用してアラートがsyslogに送信されます。

- 電子メール・メッセージを送信する。

- スクリプト・コマンドを実行する。

表24-1は、Directory Proxy Serverに事前定義済の管理アラートをリストしています。

表24-1 Directory Proxy Serverの管理アラート

アラート・イベント

アラート・コード

構成パラメータ

サーバーの起動

1000

info-server-startup

正常なサーバー停止

1001

info-server-shutdown-clean

突然のサーバー停止

1002

error-server-shutdown-abrupt

構成のリロード

1003

info-configuration-reload

不正な構成による構成のリロードの失敗。ランタイム構成に影響はありません。

1004

warning-configuration-reload-failure-no-impact

不正な構成による構成のリロードの失敗。ランタイム構成が影響を受けている可能性があります。

1005

error-configuration-reload-failure-with-impact

データソースは利用できません

2000

warning-data-source-unavailable

データソースは利用できます

2001

info-data-source-available

リスナーは利用できません

3000

warning-listener-unavailable

データソースのデータに一貫性がありません

4000

warning-data-sources-inconsistent

リソースが制限を超過しています

5000

error-resource-limit-exceeded

警告リソースが制限を超過しています

5100

warning-resource-limit-exceeded

Directory Proxy Serverの管理アラートの構成方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のDirectory Proxy Serverの管理アラートの構成に関する説明を参照してください。

24.2 データソースの監視

Directory Proxy Serverは、継続的にデータソースを監視して、それらが稼働しているかどうか、および失敗した接続を検出するかどうかを判断します。この項では、Directory Proxy Serverによるデータソースの監視方法およびデータソースが失敗したときに実行される操作について説明します。

24.2.1 データソースの監視方法

Directory Proxy Serverは、次のテストを実行してデータソースの状態を監視します。

- Directory Proxy Serverとデータソース間のトラフィックのエラーをリッスンする

- 指定された間隔にデータソースからトラフィックがない場合、データソースに専用の接続を定期的に確立する

- 接続が閉じられるのを防ぎ、閉じられた接続を検出できるように、既存の各接続を各データソースにピングする

これらのテストについては、後続の各項で説明します。

24.2.1.1 エラーをリッスンしてデータソースを監視する

このタイプの監視を構成すると、Directory Proxy Serverは、それ自身とデータソース間のトラフィックのエラーをリッスンします。Directory Proxy Serverでクライアント操作の失敗が検出されると、プロキシは、失敗に関連するデータソースをテストします。

このタイプの監視は、エラーが検出されるとDirectory Proxy Serverがエラーに反応するが、それ以外の場合では積極的にデータソースをテストしないため、事後監視と呼ばれます。

Directory Proxy Serverは、「定期的に専用の接続を確立してデータソースを監視する」および「確立した接続をテストしてデータソースを監視する」の項で説明されている監視を実行せずに、このタイプの事後監視のみを実行するように構成できます。事後監視のみを構成している場合、監視の完全性が低くなりますが、トラフィックは増加しません。

24.2.1.2 定期的に専用の接続を確立してデータソースを監視する

このタイプの監視を構成すると、Directory Proxy Serverは、指定された期間にデータソースに作成されたリクエストまたはデータソースからのレスポンスがない場合に、データソースに専用の接続を確立します。Directory Proxy Serverは、データソースに定期的に専用の接続を確立して、データソースが稼働しているかを監視します。

このタイプの監視は、Directory Proxy Serverが失敗の検出を待機してからデータソースをテストするわけではないため、エラーをリッスンしてデータソースを監視するよりも完全性が高くなります。ただし、このタイプの監視は、プロキシがデータソースへの既存の接続が稼働しているかをテストしないため、確立した接続をテストしてデータソースを監視するよりも完全性が低くなります。

このタイプの監視は、確立した接続をテストしてデータソースを監視する機能に追加して使用できます。

24.2.1.3 確立した接続をテストしてデータソースを監視する

このタイプの監視を構成すると、Directory Proxy Serverは、一定の間隔で各データソースに対する各接続をテストします。これにより、プロキシは、非アクティブのために接続が切断されることを防ぎ、閉じられた接続を検出します。

このタイプの監視は、定期的に専用の接続を確立してデータソースを監視する機能に追加して使用できます。

Directory Proxy Serverは、次のシナリオで接続をテストするように構成できます。

- プールされた接続が一定期間使用されていない

- 永続検索の接続が一定期間有効でない

- クライアントとDirectory Proxy Serverの間の接続がトンネリング・モードを利用している

確立した接続のテストは、システム・リソースを消費しますが、接続に対するセキュリティが強固になります。Active Directory製品は無効な接続を閉じるため、Active Directory製品を使用する場合は、この方法の監視を使用する必要があります。

Directory Proxy Serverは、確立した接続をテストするために、次のパラメータを使用して検索リクエストを発行します。

- 検索ベースのDN

- 接続タイムアウト

- 検索タイムアウト

- 検索フィルタ

接続が切断されていることが検出されると、Directory Proxy Serverは、指定された間隔で接続をポーリングし、そのリカバリを検出します。この間隔は、down-monitoring-intervalプロパティを設定して構成できます。詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の確立した接続をテストしてデータソースを監視する方法に関する説明を参照してください。

Directory Proxy Serverは、検索フィルタを使用してデータソースを監視します。データソースがフィルタの基準を満たしている結果を返す場合、データソースは稼働しているとみなされます。

24.2.2 データソースの失敗に対するレスポンス

Directory Proxy Serverが接続に対するエラーを検出すると、プロキシは接続を閉じて、すぐに接続を再確立しようとします。プロキシが接続を再確立できる場合、データソースは稼働しているとみなされます。プロキシが接続を再確立できない場合、データソースには、利用できないことを示すフラグが設定されます。Directory Proxy Serverは、データソースへのリクエストの配布を停止し、データソースへのその他すべての接続を閉じます。

失敗した接続または失敗したデータソースが原因でリクエストが失敗した場合、Directory Proxy Serverは、別の接続に対するリクエストを同じデータソースにリプレイするか、別のデータソースにリクエストをリプレイします。リクエストが別のデータソースにリプレイされた場合、ロード・バランシング・アルゴリズムは、使用するデータソースを決定します。

Directory Proxy Serverがリクエストをリプレイできるデータソースがない場合、プロキシはクライアントにエラーを返します。

リクエストをリプレイすると、その失敗をクライアントに対して透過的にすることができます。リクエストは、次の操作でリプレイされます。

- 検索

- バインド

- 比較

Directory Proxy Serverでは、接続の失敗が発生する前に操作が実行されたかどうかを確認することができないため、リクエストは書込み操作に対してリプレイされません。

データソースが、利用できなくなった後にリカバリされた場合、Directory Proxy Serverは、データソースを候補データソースのリストに返します。他の候補データソースが実行していた操作は、ロード・バランシング・アルゴリズムに従って、このデータソースを含めるように再配布されます。

失敗したデータソースがリカバリすると、Directory Proxy Serverは、データソースとそのクライアントの間のトラフィックを再度監視しはじめます。

24.3 Directory Proxy Serverの監視

Directory Proxy Serverは、Java仮想マシン(JVM)内部で実行され、JVMのメモリーに依存します。Directory Proxy Serverが正しく実行されていることを確認するには、そのメモリー消費量を監視する必要があります。Directory Proxy Serverのメモリー消費量の監視方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のJVMを使用してDirectory Proxy Serverについて監視されたデータを取得する方法に関する説明を参照してください。

Directory Proxy Serverの情報の監視は、cn=monitorエントリの下で提供されます。cn=monitorエントリは、メモリー内データベースで、ローカルのDirectory Proxy Serverによって管理されます。

Directory Proxy Serverの監視で最良の結果を得るには、ベース範囲を使用してcn=monitorエントリを検索します。検索のbaseDNを一緒に指定した場合、ベース範囲では、baseDNで指定されたレベルのみ(その子エントリを含まない)を調べます。ベース範囲は、-s baseオプションを使用して指定します。次に例を示します。

$ ldapsearch -h HOSTNAME -p LDAP_PORT -D"cn=proxy manager" -w PROXY_MANAGER_PASSWORD -s base -b "cn=monitor" "(objectclass=*)"
version: 1
dn: cn=monitor
objectClass: top
objectClass: extensibleObject
cn: monitor

Directory Proxy Serverの監視の詳細は、次の項を参照してください。

- cn=monitorエントリの簡略化されたレイアウト

- 監視された情報のステータス

- cn=monitorエントリの下の各エントリの説明

- cn=monitorエントリの詳細なレイアウト

『Oracle Directory Server Enterprise Edition管理者ガイド』のDirectory Proxy Serverの監視されたデータを取得する方法に関する説明も参照してください。

24.3.1 cn=monitorエントリの簡略化されたレイアウト

この項では、cn=monitorエントリの簡略化されたレイアウトについて説明します。cn=monitorエントリの詳細なレイアウトおよびcn=monitorの下のすべてのエントリおよび属性の説明は、「cn=monitorエントリの詳細なレイアウト」を参照してください。

cn=monitor
|
+-- cn=Product (Installed Product)
|
+-- cn=ProductName
|
+-- cn=Operating System
+-- cn=Instance (Application System)
|
+-- cn=InstanceId
|
+-- cn=Service
+-- cn=Add
+-- cn=Delete
+-- cn=Modify
+-- cn=ModifyDN
+-- cn=Search
+-- cn=Compare
+-- cn=Bind
+-- cn=Resource (System Resource)
+-- cn=Work Queue
+-- cn=Worker Thread
+-- cn=worker_thread_name
+-- cn=Search Thread
+-- cn=search_thread_name
+-- cn=Monitor Thread
+-- cn=monitor_thread_name
+-- cn=Connection Handler Thread
+-- cn=connection_handler_thread_name
+-- cn=SAP (Service Access Point)
+-- cn=LDAP
+-- cn=LDAPS
+-- cn=RSAP (Remote SAP)
+-- cn=LDAP  Server servername
+-- cn=LDAPS Server servername
+-- cn=RDBM  Server servername
+-- cn=Component (Logical Component)
+-- cn=DataSource Pool
+-- cn=poolname
+-- cn=Proportional Load Balancing
+-- cn=Add
+-- cn=Search
+-- cn=Delete
+-- cn=Compare
+-- cn=Modify
+-- cn=ModifyDN
+-- cn=Bind
+-- cn=Saturation Load Balancing
+-- cn=Affinity Load Balancing
+-- cn=Failover Load Balancing
+-- cn=Fastest-Server Load Balancing
+-- cn=Adaptive-Failover Load Balancing
+-- cn=JVM
+-- cn=DB System
+-- cn=DB Service

24.3.2 監視された情報のステータス

監視されている各要素には、操作のステータスが含まれています。表24-2は、監視された情報のステータスを示しています。

表24-2 監視された情報のステータス

値

名前

説明

2

OK

要素は完全に動作しています

3

DEGRADED

要素は動作していますが最適ではありません

4

STRESSED

要素は、オーバーロードのような負荷の高い環境で動作しています

10

STOPPED

要素は停止しています

12

NO_CONTACT

要素にアクセスできません

13

LOST_COMMUNICATION

一度要素にアクセスしましたが、現在はアクセスできません

24.3.3 cn=monitorエントリの下の各エントリの説明

cn=monitorサブツリーの各エントリの詳細は、次の項を参照してください。

- cn=Product

- cn=Operating System

- cn=Instance

- cn=Service

- cn=SAP

- cn=RSAP

- cn=Component

- cn=JVM

- cn=Resource

24.3.3.1 cn=Product

cn=Productエントリは、インストールされているファイルのセットを特定します。インストールされている製品は、エントリcn=ProductNameによって特定されます。

cn=Productには、次のグループの属性が含まれています。

設定

- versionは、メジャー・リリース、マイナー・リリースおよび必要に応じてマイクロ・リリース(たとえば、6.1)を含むフル・リリース番号を特定します。

- buildNumberは、ビルド番号の構文を特定します。

- patchIdは、製品のパッチを特定します。この属性は空にしても構いません。

状態

操作のステータスおよび利用可能なステータスを提供します。

統計

パフォーマンスと使用状況などの統計メトリックのセットを提供します。

24.3.3.2 cn=Operating System

cn=Operating Systemエントリは、製品パッケージがインストールされているオペレーティング・システムを特定します。このエントリには、次の監視DNが含まれています。

cn=Operating System, cn=ProductName, cn=Product, cn=monitor

cn=Operating Systemには、次のグループの属性が含まれています。

設定

- operatingSystemNameは、SunOSなどのオペレーティング・システムの名前を特定します。

- operatingSystemVersionは、5.10などのオペレーティング・システムのリリースを特定します。

状態

操作のステータスおよび利用可能なステータスを提供します。

統計

パフォーマンスと使用状況などの統計メトリックのセットを提供します。

24.3.3.3 cn=Instance

cn=Instanceエントリは、インストールされている製品のインスタンスを特定します。製品の2つの以上のインスタンスが1つのデータソースに存在します。各インスタンスは、インスタンスID(instanceId=host:instance-path)で特定されます。

cn=Instanceエントリには、次の監視DNが含まれています。

cn=InstanceId, cn=Instance, cn=Operating System, cn=ProductName,
cn=Product, cn=monitor

cn=Operating Systemには、次のグループの属性が含まれています。

設定

構成属性値を提供します。

状態

operationalStatusは、値0、2、8、9および10を使用して要素の状態を特定します。値の詳細は、表24-2を参照してください。

統計

パフォーマンスと使用状況などの統計メトリックのセットを提供します。

24.3.3.4 cn=Service

cn=Serviceエントリは、Directory Proxy ServerのインスタンスのLDAP操作またはサービスに関する情報を特定します。

LDAP操作は、add、delete、modify、modifyDN、search、compareおよびbindです。各LDAP操作は、cn=Serviceの下に特定の監視エントリがあります。たとえば、追加操作には次のDNがあります。

cn=add, cn=Service, cn=InstanceId, cn=Instance, cn=Operating System,
cn=ProductName, cn=Product, cn=monitor

cn=Serviceの下のエントリには、次のグループの属性が含まれる場合があります。

設定

構成属性値を提供します。

状態

操作のステータスおよび利用可能なステータスを提供します。

統計

- totalは、Directory Proxy Serverのこのインスタンスが受け取った操作の番号を特定します。

- succeededは、Directory Proxy Serverのこのインスタンスで成功した操作の番号を特定します。

- failedは、Directory Proxy Serverのこのインスタンスで失敗した操作の番号を特定します。

- abandonnedは、Directory Proxy Serverのこのインスタンスが中断した操作の番号を特定します。

24.3.3.5 cn=SAP

サービス・アクセス・ポイント(SAP)は、サービスへのアクセス方法に関する情報を提供します。cn=SAPエントリには、次の監視DNが含まれています。

cn=listenerThread, cn=SAP, cn=instanceId, cn=Instance,
cn=OperatingSystem, cn=Product, cn=monitor

cn=SAPの下のエントリには、次のグループの属性が含まれる場合があります。

設定

- nameは、LDAPまたはLDAPSのいずれかのSAP名を特定します。

- isSecureは、LDAPSが使用されているかどうかを特定します。値がTRUEの場合、LDAPSが使用されています。

- hostは、現在のデータソースのホスト名を特定します。

- portは、Directory Proxy Serverのこのインスタンスにアクセスするポート番号を特定します。

状態

- enabledは、SAPが有効化されているかどうかを特定します。

- operationalStatusは、SAPのステータスを特定します。値が2またはOKの場合、SAPは完全に動作しています。

- statusDescriptionは、詳細なステータスを説明します。

- startTimeは、SAPが起動した日付と時間を特定します。

- stopTimeは、SAPが停止した日付と時間を特定します。

- stopExceptionは、停止操作が失敗した場合に、エラーの詳細を説明します。この属性が空の場合、エラーは発生していません。

統計

- acceptedConnectionsは、受け入れたTCP接続の数を特定します。すべてのLDAP操作にカウンタが1つ存在します。このカウンタは、サービスを認識しません。

- refusedConnectionsは、拒否されたTCP接続の数を特定します。

- currentConnectionsは、エントリが取得された時点で確立されているクライアント接続の数を特定します。

24.3.3.6 cn=RSAP

cn=RSAPエントリは、リモート・サービスのタイプを特定します。リモートSAPは、次のいずれかのタイプを指定できます。

- Oracle Directory ServerまたはMicrosoft ADAMのようなディレクトリ・サービスにアクセスするLDAP

- Oracle DatabaseのようなRDBMシステムにアクセスするODBC

24.3.3.6.1 LDAPリモートSAP

LDAPリモートSAPのcn=RSAPエントリには、次のいずれかの監視DNを使用できます。

cn=LDAP  servername, cn=RSAP, cn=instanceId, cn=Instance,
cn=OperatingSystem, cn=Product, cn=monitor

cn=LDAPS  servername, cn=RSAP, cn=instanceId, cn=Instance,
cn=OperatingSystem, cn=Product, cn=monitor

cn=RSAPの下のエントリには、次のグループの属性が含まれる場合があります。

設定

- nameは、LDAPまたはLDAPSのいずれかのSAP名を特定します。

- isSecureは、LDAPSが使用されているかどうかを特定します。値がTRUEの場合、LDAPSが使用されています。

- hostは、ホスト・サーバーのホスト名を特定します。

- portは、Directory Proxy Serverのこのインスタンスにアクセスするポート番号を特定します。

状態

- operationalStatusは、値2、4、12および13を使用して要素の状態を特定します。これらの値の詳細は、表24-2を参照してください。

- statusDescriptionは、状態の詳細を説明します。

- startedは、RSAPが起動しているかどうかを特定します。

- readOnlyは、これが読込み専用モードかどうかを特定します。

統計

- totalConnectionsは、確立されている接続を含む接続の合計数を特定します。

- totalAvailableConnectionsは、バインド、読込みおよび書込み操作に利用できる接続の合計数を特定します。値0は、データソースへのアクセスが混雑していることを意味します。

- 次の属性は、バインド接続で指定されますが、読込み接続および書込み接続でも指定される場合があります。

- totalBindConnectionsは、バインド操作で確立されている接続の数を特定します。すべての接続は、バインド接続のプール内に格納されます。

- availableBindConnectionsは、プール内の空いているバインド接続の数を特定します。

- bindConnectionsRequestedは、プールから空いているバインド接続を取得するリクエストの数を特定します。

- bindConnectionsProvidedは、リクエストに応じて提供されるバインド接続の数を特定します。

- bindConnectionsRefusedは、(待機の後であっても)プールが空であるか、またはリモート・データソースが停止しているために拒否されているリクエストの数を特定します。

- bindConnectionsWaitsRequiredは、バインド接続が解放されるのを待機している間、待機状態でブロックされているリクエストの数を特定します。

- bindConnectionsReturnedValidは、解放されている接続の数を特定します。

- bindConnectionsReturnedInvalidは、無効として解放されている接続の数を特定します。エラーが発生すると、接続は無効とされます。

- 次の属性はバインド接続に指定されますが、追加、変更、DN変更、削除、比較および検索接続で指定される場合もあります。
bindResponseTimeInMicroSecは、最速のサーバー・ロード・バランシング・アルゴリズムによって使用されるバインド操作の現在のサーバー平均レスポンス時間を特定します。

24.3.3.7 cn=Component

cn=Componentエントリは、サービスを使用してアクセスしているソフトウェアの部分を特定します。次の部分のソフトウェアは、cn=Componentエントリによって特定されます。

- ロード・バランシング・アルゴリズム

- 接続クラス

- データ・ビュー

24.3.3.7.1 すべてのデータソースの比例ロード・バランシング・アルゴリズム

すべてのデータソースの比例ロード・バランシング・アルゴリズムのcn=Componentエントリには、次の監視DNが含まれています。

cn=ProportionalLB, cn=DataSourcePool poolname, cn=Component,
cn=instanceId, cn=Instance, cn=OperatingSystem, cn=Product, cn=monitor

比例ロード・バランシング・アルゴリズムのcn=Componentエントリには、すべてのデータソースに対して次のグループの属性が含まれています。

設定

- classNameは、クラスの名前を提供します。

状態

- enabledは、リモートSAPの状態を特定します。値がTRUEの場合、ロード・バランシング・アルゴリズムは有効です。

統計

- totalBindConnectionsProvidedは、バインド操作に提供される接続の合計数を特定します。

- totalBindConnectionsRefusedは、バインド操作で拒否された接続の数を特定します。
接続は、次いずれかの理由で拒否される場合があります。

- データソースのプールが空である。

- プールのすべてのデータソースが停止している。

- ロード・バランシング・アルゴリズムが選択したデータソースに、リモート・サービスに達することができる接続がない。

- totalAddConnectionsProvidedは、totalBindConnectionsProvidedを参照します。

- totalAddConnectionsRefusedは、totalBindConnectionsRefusedを参照します。

- totalCompareConnectionsProvidedは、totalBindConnectionsProvidedを参照します。

- totalCompareConnectionsRefusedは、totalBindConnectionsRefusedを参照します。

- totalDeleteConnectionsProvidedは、totalBindConnectionsProvidedを参照します。

- totalDeleteConnectionsRefusedは、totalBindConnectionsRefusedを参照します。

- totalModifyConnectionsProvidedは、totalBindConnectionsProvidedを参照します

- totalModifyConnectionsRefusedは、totalBindConnectionsRefusedを参照します。

- totalModifyDNConnectionsProvidedは、totalBindConnectionsProvidedを参照します。

- totalModifyDNConnectionsRefusedは、totalBindConnectionsRefusedを参照します。

- totalCompareConnectionsProvidedは、totalBindConnectionsProvidedを参照します。

- totalCompareConnectionsRefusedは、totalBindConnectionsRefusedを参照します。

24.3.3.7.2 各データソースの比例ロード・バランシング・アルゴリズム

各データソースの比例ロード・バランシング・アルゴリズムのcn=Componentエントリには、次の監視DNが含まれています。

cn=Add, cn=servername, cn=Proportional LB, cn=DataSource Pool poolname,
cn=Component, cn=instanceId, cn=Instance, cn=OperatingSystem,
cn=Product, cn=monitor

削除、変更、変更DN、検索、比較およびバインド操作には、同様の監視DNがあります。

比例ロード・バランシング・アルゴリズムのcn=Componentエントリには、各データソースに対して次のグループの属性が含まれています。

設定

- 構成属性値を提供します。

状態

- operationalStatusは、値2および5を使用して要素の状態を特定します。これらの値の詳細は、表24-2を参照してください。

- statusDescriptionは、詳細なステータスを説明します。

統計

- providedConnectionsは、操作のデータソースにアクセスするために提供される接続の数を特定します。

- providedPercentageは、操作のデータソースにアクセスするために提供される接続の割合を特定します。

- refusedConnectionsは、データソースに対する接続の取得が拒否されたリクエストの数を特定します。

- refusedPercentageは、拒否されたリクエストの割合を特定します。

24.3.3.8 cn=JVM

cn=JVMエントリは、Directory Proxy Serverのインスタンスを実行するために使用されているJVMを特定します。cn=JVMエントリには、次の監視DNが含まれています。

cn=JVM, cn=instanceId, cn=Instance, cn=DPS60, cn=Product, cn=monitor

cn=JVMの下のエントリには、次のグループの属性が含めることができます。

設定

- versionは、Directory Proxy Serverのインスタンスを実行するために使用されているJVMのバージョンを特定します。

- JVMInstallationは、JVMインストールの場所を特定します。

状態

- operationalStatusは、値2および5を使用して要素の状態を特定します。これらの値の詳細は、表24-2を参照してください。

- statusDescriptionは、詳細なステータスを説明します。

統計

- totalJVMMemoryは、実行するJVMに割り当てられたメモリの合計量を特定します。

- maxJVMMemoryは、JVMメモリの最大容量を特定します。

- freeJVMMemoryは、メモリの空き容量を特定します。

- realFreeJVMMemoryは、使用できるJVMの空き容量を特定します。

- JVMMemoryLowLevelCountは、JVMのメモリの状態が緑からオレンジに変わる回数を提供します。

- JVMMemoryVeryLowLevelCountは、JVMのメモリの状態がオレンジから赤に変わる回数を提供します。

- availableCPUは、利用できるCPU容量を特定します。

24.3.3.9 cn=Resource

cn=Resourceエントリは、ソフトウェアが使用しているリソースのセットを特定します。リソースには、バッファ、ファイル説明およびハード・ディスクなどが含まれます。

次の要素は、cn=Resourceエントリによって特定されます。

- 接続ハンドラ・スレッド

- 作業キュー

- ワーカー・スレッド

- 検索スレッド

- 監視スレッド

24.3.3.9.1 接続ハンドラ・スレッド

接続ハンドラ・スレッドは、受信リクエストをデコードします。接続ハンドラは、LDAPまたはLDAPSプロトコル指向です。リクエストが完全にデコードされると、リクエストは作業キューに配置されます。

接続ハンドラ・スレッドのcn=Resourceエントリには、次の監視DNがあります。

cn=connection_handler_thread_name, cn=Connection Handler Thread,
cn=Resource, cn=instanceId, cn=Instance, cn=DPS60, cn=Product,
cn=monitor

接続ハンドラ・スレッドのcn=Resourceエントリの下のエントリには、次のグループの属性が含まれます。

設定

- threadIDは、一意のスレッドID番号を提供します。

- threadStackは、スレッド・スタックの情報を提供します。

状態

- operationalStatusは、要素のステータスを特定します。値2は、要素が完全に動作していることを示します。

- startTimeは、スレッドが起動した日付と時間を特定します。

- startedは、スレッドが起動しているかどうかを特定します。

- runningは、スレッドが起動状態であるかどうかを特定します。

- statusDescriptionは、詳細なステータスを説明します。

統計

次の統計を収集できます。

- cn=ByteBufferPoolの下のバイト・バッファ・プール統計

- numTries

- numHits

- numMissesEmpty

- numMissesSize

- numReleases

- availableStandardBuffers

- availableOversizedBuffers

- cn=StringBufferPoolの下の文字列バッファ・プール統計

- numTries

- numHits

- numMisses

- numReleases

- availableBuffers

- cn=VectorPoolのベクトル・プール統計

- numTries

- numHits

- numMisses

- numReleases

- availableBuffers

24.3.3.9.2 作業キュー

クライアントからの受信リクエストは、接続ハンドラ・スレッドによって作業キューに格納されます。次にリクエストは、ワーカー・スレッドによって処理されます。作業キューのcn=Resourceエントリには、次の監視DNがあります。

cn=Work Queue, cn=Resource, cn=instanceId, cn=Instance, cn=DPS60,
cn=Product, cn=monitor

作業キューのcn=Resourceエントリの下のエントリには、次のグループの属性が含まれます。

設定

- maxNormalPriorityPeakは、キューに配置できる標準優先度のリクエストの最大数を特定します。このしきい値に達すると、接続ハンドラは一時停止します。

- maxHighPriorityPeakは、キューに配置できる高優先度のリクエストの最大数を特定します。このしきい値に達すると、接続ハンドラは一時停止します。

状態

- curNormalPriorityInQueueは、キューに現在の標準優先度のリクエストを提供します。

- curHighPriorityInQueueは、キューに現在の高優先度のリクエストを提供します。

- operationalStatusは、値2および4を使用して要素の状態を特定します。これらの値の詳細は、表24-2を参照してください。

- statusDescriptionは、詳細なステータスを説明します。

統計

- numNormalPriorityPutsは、接続ハンドラ・スレッドによってキューに配置される標準優先度のリクエストの数を特定します。

- numNormalPriorityGetsは、ワーカー・スレッドによってキューから取得される標準優先度のリクエストの数を特定します。

- numHighPriorityPutsは、接続ハンドラ・スレッドによってキューに配置される高優先度のリクエストの数を特定します。

- numHighPriorityGetsは、ワーカー・スレッドによってキューから取得される高優先度のリクエストの数を特定します。

- numAbandonRequestsは、破棄されるリクエストの数を特定します。

- numAbandonSuccessesは、キューに存在しているときに破棄されるリクエストの数を特定します。

24.3.3.9.3 ワーカー・スレッド

ワーカー・スレッドは、作業キューからのリクエストを処理します。

ワーカー・スレッドのcn=Resourceエントリには、次の監視DNがあります。

cn=Worker Thread, cn=Resource, cn=<instanceId>,
cn=Instance, cn=DPS, cn=Product, cn=monitor

このエントリには、すべてのワーカー・スレッドに関する一般的な情報が含まれています。属性のリストは次のとおりです。

統計

- busyThreadsは、エントリが取得されるときのビジー・ワーカー・スレッドの数を特定します。

- idleThreadsは、エントリが取得されるときのアイドル・ワーカー・スレッドの数を特定します。

ワーカー・スレッドのcn=Worker Threadエントリの下のエントリには、「接続ハンドラ・スレッド」で説明されている属性のグループと同じグループが含まれており、これらの属性は次のとおりです。

統計

- operationsProcessedは、ワーカー・スレッドによって処理される操作の数を特定します。

- exceptionsCaughtは、操作の処理中に発生する例外の数を特定します。

24.3.3.9.4 検索スレッド

複数のデータ・ビューで検索を実行する場合、パラレル検索スレッドを使用できます。検索スレッドのcn=Resourceエントリには、次の監視DNがあります。

cn=search_thread_name, cn=Search Thread, cn=Resource, cn=instanceId,
cn=Instance, cn=DPS60, cn=Product, cn=monitor

検索スレッドのcn=Resourceエントリの下のエントリには、「接続ハンドラ・スレッド」で説明されている属性のグループと同じグループが含まれています。

24.3.3.9.5 監視スレッド

監視スレッドは、リモート・データソースの可用性をチェックします。リモート・データソースは、監視スレッドがリモート・データソースに1つの接続を作成できる場合、利用可能であるとみなされます。監視スレッドのcn=Resourceエントリには、次の監視DNがあります。

cn=monitor_thread_name, cn=Monitor Thread, cn=Resource, cn=instanceId,
cn=Instance, cn=DPS60, cn=Product, cn=monitor

検索スレッドのcn=Resourceエントリの下のエントリには、「接続ハンドラ・スレッド」で説明されている属性のグループと同じグループが含まれており、この属性のグループは次のとおりです。

設定

- backendServerは、監視されているリモート・データソースの名前を特定します。

- checkIntervalは、2回のチェックの間の間隔(単位: 秒)を特定します。

- additionalCheckTypeは、追加のチェックを指定します。次の値を使用できます。

- 1 (追加のチェックなし)

- 2 (データソースへのバインド接続を作成する)

- 3 (データソースへの読込み接続を作成する)

状態

- serverAvailableは、リモート・データソースの状態を特定します。リモート・データソースが稼働している場合、値はtrueです。

統計

- totalChecksは、チェックの合計数を特定します。

- availabilityChecksFailedは、失敗した可用性チェックの数を指定します。リモート・データソースが稼働中の場合、可用性チェックは成功します。

- additionalChecksFailedは、失敗した追加のチェックの数を指定します。

24.3.4 cn=monitorエントリの詳細なレイアウト

この項では、cn=monitorサブツリーの詳細なレイアウトについて説明します。

cn=monitor
|
+-- cn=Product (Installed Product)
|
+-- cn=ProductName
|| setting:
|| - version
|| - buildNumber
|| - patchId
+-- cn=Operating System
|| setting:
|| - operatingSystemName
|| - operatingSystemVersion
|| state:
|| - (empty)
|| statisitics:
|| - (empty)
+-- cn=Instance  (Application System)
|
+-- cn=InstanceId (= host:port:instanceDir)
|
+-- cn=Service
+-- cn=Add
|| statistics:
|| - total
|| - succeeded
|| - failed
|| - abandonned (?)
+-- cn=Search
|| (same as Add operation above)
+-- cn=Delete
+-- cn=Compare
+-- cn=Modify
+-- cn=ModifyDN
+-- cn=Bind
+-- cn=SAP  (Service Access Point)
+-- cn=listenerThread
|| settings:
|| - name
|| - isSecure
|| - host (?)
|| - port (?)
|| state:
|| - enabled
|| - operationalStatus
|| - statusDescription
|| - startTime
|| - stopTime
|| - stopException
|| statistics:
|| - acceptedConnections
|| - refusedConnections
|| - currentConnections
+-- cn=listenerThread
|| (same as above)
+-- cn=RSAP  (Remote SAP)
+-- cn=LDAP Server servername
|| settings:
|| - name
|| - isSecure
|| - host (?)
|| - port (?)
|| state:
|| - operationalStatus
|| - statusDescription
|| - started
|| - readOnly
|| statistics:
|| - totalConnections
|| - totalAvailableConnections
|| - totalBindConnections
|| - availableBindConnections
|| - bindConnectionsRequested
|| - bindConnectionsProvided
|| - bindConnectionsRefused
|| - bindConnectionsWaitsRequired
|| - bindConnectionsReturnedValid
|| - bindConnectionsReturnedInvalid
|| - (idem for readConnections)
|| - (idem for writeConnections)
+-- cn=LDAPS Server servername
|| (same as LDAP Server above)
+-- cn=RDBM Server servername
|| settings:
|| - TBC
|| state:
|| - TBC
|| statistics:
|| - TBC
+-- cn=Component  (Logical Component)
+-- cn=DataSource Pool poolname
+-- cn=Proportional LB
|| settings:
|| - classname
|| state:
|| - enabled
|| statistics:
|| - totalBindConnectionsProvided
|| - totalBindConnectionsRefused
|| - totalAddConnectionsProvided
|| - totalAddConnectionsRefused
|| - totalCompareConnectionsProvided
|| - totalCompareConnectionsRefused
|| - totalDeleteConnectionsProvided
|| - totalDeleteConnectionsRefused
|| - totalModifyConnectionsProvided
|| - totalModifyConnectionsRefused
|| - totalModifyDNConnectionsProvided
|| - totalModifyDNConnectionsRefused
|| - totalCompareConnectionsProvided
|| - totalCompareConnectionsRefused
+-- cn=Add
|| settings:
|| - (empty)
|| status:
|| - operationalStatus
|| - statusDescription
|| statistics:
|| - providedConnections
|| - providedPercentage
|| - refusedConnections
|| - refusedPercentage
+-- cn=Search
|| (same as Add operation above)
+-- cn=Delete
+-- cn=Compare
+-- cn=Modify
+-- cn=ModifyDN
+-- cn=Bind
+-- cn=Saturation LB
|| (same as Proportional LB)
+-- cn=Affinity LB
|| (same as Proportional LB)
+-- cn=Failover LB
|| (same as Proportional LB)
+-- cn=Fastest-Server LB
|| (same as Proportional LB)
+-- cn=Adaptive-Failover LB
|| (same as Proportional LB)
+-- cn=JVM
|| settings:
|| - version
|| - jvmInstallation
|| state:
|| - operationalStatus
|| - statusDescription
|| statistics:
|| - totalJVMMemory
|| - maxJVMMemory
|| - freeJVMMemory
|| - realFreeJVMMemory
|| - JVMMemoryLowLevelCount
|| - JVMMemoryVeryLowLevelCount
|| - availableCPU
+-- cn=Resource  (System Resource)
+-- cn=Worker Thread
||statistics
||- busyThreads
||- idleThreads
+-- cn=worker_thread_name
|| settings:
|| - threadID
|| - threadStack
|| state:
|| - operationalStatus
|| - statusDescription
|| - startTime
|| - started
|| - running
|| statistics:
|| - operationsProcessed
|| - exceptionsCaught
+-- cn=Byte Buffer Pool
|| statistics:
|| - numTries
|| - numHits
|| - numMissesEmptyPool
|| - numMissesBufferSize
|| - numReleases
|| - availableStandardBuffers
|| - availableOversizedBuffers
+-- cn=String Buffer Pool
|| statistics:
|| - numTries
|| - numHits
|| - numMisses
|| - numReleases
|| - availableBuffers
+-- cn=Vector Pool
|| statistics:
|| - numTries
|| - numHits
|| - numMisses
|| - numReleases
|| - availableVectors
+-- cn=Search Thread
+-- cn=search_thread_name
|| settings:
||
|| state:
|| - operationalStatus
|| - startTime
|| - stopTime
|| statistics:
||
+-- cn=Byte Buffer Pool
|| (see Worker Thread)
+-- cn=String Buffer Pool
|| (see Worker Thread)
+-- cn=vector Pool
|| (see Worker Thread)
+-- cn=Monitor Thread
+-- cn=monitor_thread_name
|| settings:
|| - started
|| - running
|| - startTime
|| - threadID
|| - threadStack
|| - backendServer
|| - checkInterval
|| - additionalCheckType
|| state:
|| - operationalStatus
|| - statusDescription
|| - serverAvailable
|| statistics:
|| - totalChecks
|| - availabilityChecksFailed
|| - additionalChecksFailed
+-- cn=Byte Buffer Pool
|| (see Worker Thread)
+-- cn=String Buffer Pool
|| (see Worker Thread)
+-- cn=vector Pool
|| (see Worker Thread)
+-- cn=Connection Handler Thread
+-- cn=connection_handler_thread_name
|| settings:
|| - threadID
|| - threadStack
|| state:
|| - operationalStatus
|| - startTime
|| - started
|| - running
|| - statusDescription
|| statistics:
|| - (empty)
+-- cn=Byte Buffer Pool
|| (see Worker Thread)
+-- cn=String Buffer Pool
|| (see Worker Thread)
+-- cn=Vector Pool
|| (see Worker Thread)
+-- cn=Work Queue
|| settings:
|| - maxNormalPriorityPeak
|| - maxHighPriorityPeak
|| - operationalStatus
|| - statusDescription
|| state:
|| - curNormalPriorityInQueue
|| - curHighPriorityInQueue
|| statistics:
|| - numNormalPriorityPuts
|| - numNormalPriorityGets
|| - numHighPriorityPuts
|| - numHighPriorityGets
|| - numAbandonRequests
|| - numAbandonSuccesses
+-- cn=DB System
+-- cn=DB Service

索引

A B C D E F G H I J K L M N O P R S T U V W

A

アクセス

匿名, 5.3.1

アクセス制御, 22.1

レプリケーション, 5.2.1.4

ACIの配置, 5.2.1, 18.8.1

仮想, 18.8

ACI, 22.1

属性, 5.2.1, 18.8.1

レプリケーション, 5.2.1.4

ACIの配置, 5.2.1, 18.8.1 ACI

グローバル, 18.8.2

管理アラート, 24.1 近似索引, 「索引付け」を参照, 9.3.5 近似検索, 4.6.3.3 属性

ACI, 5.2.1, 18.8.1

属性名称変更プロパティ, 17.1.1.3 属性タイプ・フィールド(LDIF), 4.1 属性値フィールド(LDIF), 4.1 属性

検索, 4.6.3.2

認証, 21.1, 22.1

無名, 21.1

証明書ベース, 5.3.6.1, 21.1

クライアントおよびサーバー, 5.3

防止, 5.3.4

SASL, 5.3.7

簡易バインド, 21.1

認証。「クライアント認証」も参照, 5.3.6.1 認証。「サーバー認証」も参照, 5.3.6.1

B

backendMonitorDN属性, 6.3.1.1, 6.3.3.1

バックアップ・ファイル

Directory Server, 1.2

ベースDN, ldapsearch, 4.6.2.5 バインド・リプレイ, 19.3.1 検索フィルタでのブール演算子, 4.6.3.5 参照索引, 9.3.4 bytesSent属性, 6.3.1.2

C

CA

階層およびルート, 5.3.6.2.1

キャッシュ

データベース, 8.1.1

エントリ, 8.1.2

ファイル・システム, 8.1.4

インポート, 8.1.3

合計サイズ, 8.1.5

検索で使用, 8.2

サフィックスのインストールで使用, 8.4

更新で使用, 8.3

キャッシュの最適化, 16.2.4.3 キャッシュ・タイプ, 8.1 cache-avail-bytes属性, 6.3.1.3 中央ログ・ディレクトリ, はじめに 証明書データベース

デフォルト・パス, はじめに

証明書データベース・ファイル

Directory Proxy Server, 1.3

Directory Server, 1.2

証明書

LDAPディレクトリ, 5.3.6.5.2

認証, 5.3.6.1

チェーン, 5.3.6.2.2

内容, 5.3.6.4

発行, 5.3.6.5.1

更新の概要, 5.3.6.5.4

取消し, 5.3.6.5.4

自己署名, 5.3.6.2.1

証明書チェーンの検証, 5.3.6.2.3

変更順序番号, 7.1.8 暗号, 22.3 サービス・クラス, 12.4 サービス・クラス(CoS)

アクセス制御, 12.6

キャッシュ, 12.6

フィルタ処理されたロールの制限, 12.6

制限, 12.6

テンプレート・エントリ, 12.2.2

クラシックCoS, 12.3.3 classichashavgclashlistlength属性, 6.3.4.1 classichashavgclashpercentageperhash属性, 6.3.4.2 classichashmemusage属性, 6.3.4.3 classichashvaluesmemusage属性, 6.3.4.4 クライアント・アフィニティ, 16.1, 16.3 クライアント・リクエスト

トラッキング, 23.9

cn=monitor

オブジェクト・クラス, 6.3.1

読取り専用監査構成のエントリ, 6.3.1

照合順序, 「一致ルールを使用した索引付け」を参照, 9.3.6 コマンドライン・ユーティリティ

ldapsearch, 4.6.3

DNのカンマ, 4.6.3.7 カンマ, DN, 4.5.2 複合検索フィルタ, 4.6.3.5, 4.6.3.5 構成属性

監査構成の属性, 6.3.1

構成ファイル

Directory Proxy Server, 1.3

Directory Server, 1.2

構成

属性名称変更プロパティ, 17.1.1.3

connection属性, 6.3.1.4 接続ハンドラ

リクエスト・フィルタリング・ポリシー, 20.4

リソース制限ポリシー, 20.3

接続ハンドラ, 20 connectionPeak属性, 6.3.1.5 コンシューマ, 7.1.1 contains-shared-entriesプロパティ, 18.4.2.2 コーディネータ・データ・ビュー, 18.5 コア・サーバー構成の属性

backendMonitorDN, 6.3.1.1, 6.3.3.1

bytesSent, 6.3.1.2

cache-avail-bytes, 6.3.1.3

classichashavgclashlistlength, 6.3.4.1

classichashavgclashpercentageperhash, 6.3.4.2

classichashmemusage, 6.3.4.3

classichashvaluesmemusage, 6.3.4.4

connection, 6.3.1.4

connectionPeak, 6.3.1.5

currentconnections, 6.3.1.6

currenttime, 6.3.1.7

disk-dir, 6.3.2.1

disk-free, 6.3.2.2

disk-state, 6.3.2.3

dtablesize, 6.3.1.8

entriessent, 6.3.1.9

nbackends, 6.3.1.10

numclassicdefinitions, 6.3.4.5

numclassichashtables, 6.3.4.6

numclassictemplates, 6.3.4.7

numcosattributetypes, 6.3.4.8

numindirectdefinitions, 6.3.4.9

numpointerdefinitions, 6.3.4.10

numpointertemplates, 6.3.4.11

opscompleted, 6.3.1.11

opsinitiated, 6.3.1.12

readWaiters, 6.3.1.14

startTime, 6.3.1.16

threads, 6.3.1.17

totalConnections, 6.3.1.18

version, 6.3.1.19

CoS。「サービス・クラス」を参照 CoSテンプレート・エントリ, 12.2.2 ディレクトリの作成, 4.3 CSN。「変更順序番号」を参照, 7.1.8 currentconnections属性, 6.3.1.6 currenttime属性, 6.3.1.7

D

データソース

LDAP, 19.1

データソース・プール, 16.1 データ・ビュー, 20.2

コーディネータ, 18.5

JDBC, 18.7

結合, 18.4

LDAP, 17.1

LDIF, 18.6

プライマリ, 18.4.1

セカンダリ, 18.4.1

仮想, 18

データベース

LDIFを使用して作成, 4.3

データベース・ファイル

Directory Server, 1.2

デフォルトの場所, はじめに 定義

属性名称変更プロパティ, 17.1.1.3

ディレクトリ作成, 4.3 ディレクトリ情報ツリー, 2.2.5 Directory Proxy Server

アーキテクチャ, 15.2

機能, 15.3

ディレクトリ・サーバー

検索, 4.6

disk-dir属性, 6.3.2.1 disk-free属性, 6.3.2.2 disk-state属性, 6.3.2.3 分散アルゴリズム, 17.2 DIT, 2.2.5 DNフィールド(LDIF), 4.1 DN結合ルール, 18.4.2.1.1 DSMLv2

実装, 13.2

dtablesize属性, 6.3.1.8 動的グループ, 11.1.2

E

暗号化, 22.1

public-key, 5.4.3.2

LDIF入力でのファイルの終端マーカー, 4.5.1 エントリ

LDIFを使用して作成, 4.2

検索, 4.6, 4.6.1

LDIFファイルでの順序, 4.5.5

entriessent属性, 6.3.1.9 LDIF入力でのファイルのEOFマーカー, 4.5.1 同等索引, 「索引付け」を参照, 9.3.2 等価検索, 4.6.3.3 等価検索

例, 4.6.4

エスケープ文字, 4.6.3.7, 4.6.3.7 サブツリーの除外, 17.1.1.1

F

フェイルオーバー・アルゴリズム, 16.2.5

フィルタ結合ルール, 18.4.2.1.2

フィルタリング, 4.6.3

形式, LDIF, 4.1

G

グローバル・アカウント・ロックアウト, 16.2.4.2

グローバルACI, 18.8.2

以上検索, 4.6.3.3

グループ, 11

メリット, 11.3.1

動的, 11.1.2

静的, 11.1.1

H

HTTPヘッダー, 13.5

I

索引

概要, 9.1

タイプ, 9.3

索引付け

近似索引, 9.3.5

参照, 9.3.4

同等索引, 9.3.2

国際, 9.3.6

一致ルール索引, 9.3.6

存在索引, 9.3.1

部分文字列索引, 9.3.3

デフォルト索引の表示, 9.2.2

VLV, 9.3.4

install-path, はじめに instance-path, はじめに 国際索引, 「索引付け」を参照, 9.3.6 国際化

オブジェクト識別子, 14.2

LDIFファイル, 4.4

サポートされているロケール, 14.2

isw- hostnameディレクトリ, はじめに

J

Java Naming and Directory Interface, はじめに

JDBC属性, 18.7.4

JDBCデータ・ソース, 18.7.1

JDBCデータソース・プール, 18.7.1

JDBCデータ・ビュー, 18.7

JDBCオブジェクト・クラス, 18.7.2

JDBC表, 18.7.3

結合データ・ビュー, 18.4

結合ルール, 18.4.2.1

K

鍵

定義済, 5.4.3

管理およびリカバリ, 5.3.6.5.3

L

言語サブタイプ, 14.3

言語サポート

ロケールを使用して指定, 14.2

レイアウト

Directory Proxy Serverのインスタンス, 1.3

Directory Server Enterprise Editionソフトウェア, 1.1

Directory Serverのインスタンス, 1.2

LDAPデータソース, 19.1 LDAP検索フィルタ

カンマ付きのDN, 4.6.3.7

LDAPのURL

コンポーネント, 3.1

例, 3.3

LDAP_BASEDN, 4.6.2.5 ldapdeleteユーティリティ

カンマ付きのDN, 4.5.2

ldapmodifyユーティリティ

カンマ付きのDN, 4.5.2

ldapsearchユーティリティ, 4.6.1

ベースDN, 4.6.2.5

コマンドライン構文, 4.6.1.1

カンマ付きのDN, 4.6.3.7

例, 4.6.2

フィルタ, 4.6.3

返される属性の制限, 4.6.2.6

検索フィルタ, 4.6.3

特殊文字, 4.6.1.2

ファイルの指定, 4.6.2.6

LDIF

エントリ形式, 4.1

組織, 4.2.1

組織の人, 4.2.3

組織単位, 4.2.2

国際化, 4.4 エントリの順序, 4.5.5 ディレクトリを作成するために使用, 4.3 LDIFデータ・ビュー, 18.6 LDIFエントリ

作成, 4.2

組織の人, 4.2.3

組織単位, 4.2.2

組織, 4.2.1

国際化, 4.4 LDIFファイル

ディレクトリの作成, 4.3

国際化, 4.4

LDIF形式, 4.1 以下検索

構文, 4.6.3.3

リスナー, 21.5 ロード・バランシング, 16.2

フェイルオーバー, 16.2.5

操作アフィニティ, 16.2.4

比例, 16.2.2

飽和, 16.2.3

ローカル・ログ・ディレクトリ, はじめに ロケール

サポート対象, 14.2

ロック・ファイル

Directory Server, 1.2

ログ・ファイル

Directory Proxy Server, 1.3

Directory Server, 1.2

ログ

アクセス, 23.6

削除, 23.3

Directory Proxy Server, 23.1

エラー, 23.5

メッセージの重大度, 23.4

ローテーション, 23.2

M

変換のマッピング, 18.2.1.1

一致ルール索引, 「索引付け」を参照, 9.3.6

Message Queue, Preface

近似索引でのmetaphone音声アルゴリズム, 9.3.5

モニタリング

データ・ソース, 24.2

Directory Proxy Server, 24.3

コマンドラインから, 6.3

複数の検索フィルタ, 4.6.3.5

N

nbackends属性, 6.3.1.10

non-viewable属性, 18.3

non-writable属性, 18.3

numclassicdefinitions属性, 6.3.4.5

numclassichashtables属性, 6.3.4.6

numclassictemplates属性, 6.3.4.7

numcosattributetypes属性, 6.3.4.8

numindirectdefinitions属性, 6.3.4.9

numpointerdefinitions属性, 6.3.4.10

numpointertemplates属性, 6.3.4.11

O

オブジェクト識別子(OID), 14.2

objectClassフィールド(LDIF), 4.1

操作アフィニティ・アルゴリズム, 16.2.4

演算子

ブール, 4.6.3.5

検索フィルタ, 4.6.3.3

opscompleted属性, 6.3.1.11 opsinitiated属性, 6.3.1.12 組織, エントリの指定, 4.2.1 組織の人, エントリの指定, 4.2.3 組織単位, エントリの指定, 4.2.2 ou=monitor, 24.3.1

P

パスワード・ポリシー

設計, 5.3.2.2

存在索引, 「索引付け」を参照, 9.3.1 存在検索

例, 4.6.4

構文, 4.6.3.3

秘密鍵, 定義済, 5.4.3.2 process-bindプロパティ, 18.4.2.3 プロパティ

属性名称変更, 17.1.1.3

比例アルゴリズム, 16.2.2 プロキシ認可, 19.3.2 公開鍵

定義済, 5.4.3.2

インフラストラクチャ, 5.3.6.5

管理, 5.3.6.5.3

R

RA, 「登録局」を参照

読取り変換, 18.2.1.3

読取り専用監査構成の属性

backendMonitorDN, 6.3.1.1, 6.3.3.1

bytesSent, 6.3.1.2

cache-avail-bytes, 6.3.1.3

connection, 6.3.1.4

connectionPeak, 6.3.1.5

currentconnections, 6.3.1.6

currenttime, 6.3.1.7

disk-dir, 6.3.2.1

disk-free, 6.3.2.2

disk-state, 6.3.2.3

dtablesize, 6.3.1.8

entriessent, 6.3.1.9

nbackends, 6.3.1.10

opscompleted, 6.3.1.11

opsinitiated, 6.3.1.12

readWaiters, 6.3.1.14

startTime, 6.3.1.16

threads, 6.3.1.17

totalConnections, 6.3.1.18

version, 6.3.1.19

読取り専用監査構成のエントリ

cn=monitor, 6.3.1

readWaiters属性, 6.3.1.14 登録局, 定義済, 5.3.6.5.5 レプリカ更新ベクトル, 7.1.9 レプリケーション

アクセス制御, 5.2.1.4

ACI, 5.2.1.4

概要, 7.1

リクエスト・フィルタリング・ポリシー, 20.4 request-que-backlog, 6.3.1.13 リソース制限ポリシー, 20.3 ロール

メリット, 11.3.2

制限, 11.2.4

権限, 11.3.3

ルートDSE, 4.6.2.3 RUV。「レプリカ更新ベクトル」を参照, 7.1.9

S

SASL, 21.3.2

飽和アルゴリズム, 16.2.3

スキーマ

検索, 4.6.2.4

スキーマ・チェック

仮想, 18.9.1

検索データ非表示ルール, 20.4.2 検索フィルタ, 4.6.2.2, 4.6.3, 4.6.3

ブール演算子, 4.6.3.5

複合, 4.6.3.5

ファイルに含まれている, 4.6.2.6

例, 4.6.3, 4.6.4, 4.6.4

演算子, 4.6.3.3

属性の指定, 4.6.3.2

ファイルを使用して指定, 4.6.3.6

構文, 4.6.3.1, 4.6.3.1

属性を使用, 4.6.3.2

複合を使用, 4.6.3.5

複数を使用, 4.6.3.5

演算子を使用, 4.6.3.3

検索タイプ, リスト, 4.6.3.3 検索

近似, 4.6.3.3

同等, 4.6.3.3, 4.6.4

以上, 4.6.3.3

以下, 4.6.3.3

存在, 4.6.3.3, 4.6.4

部分文字列, 4.6.3.3

検索, 4.6.1 セカンダリ・データ・ビュー, 18.4.2 自己署名証明書, 5.3.6.2.1 serverrootディレクトリ, はじめに サイズ設定

合計キャッシュ, 8.1.5

SLAMD分散負荷生成エンジン, はじめに 特殊文字, 4.6.1.2, 4.6.3.7, 4.6.3.7 SSL, 22.2 startTime属性, 6.3.1.16 静的グループ, 11.1.1 サブセット, 4.6.2.6 部分文字列索引, 「索引付け」を参照, 9.3.3 部分文字列検索, 4.6.3.3 サプライヤ, 7.1.1 構文

検索フィルタ, 4.6.3.1

T

テンプレート・エントリ。「CoSテンプレート・エントリ」を参照, 12.2.2

threads属性, 6.3.1.17

totalConnections属性, 6.3.1.18

クライアント・リクエストのトラッキング, 23.9

チューニング

アクセス制御, 5.2.2

キャッシュ, 8.1

U

ユーザー・マッピング, 19.3.4

V

version属性, 6.3.1.19

表示可能な属性, 18.3

仮想アクセス制御, 18.8

仮想データ・ビュー, 18

構成, 18.1

仮想リスト・ビュー索引, 9.3.4 仮想スキーマ, 18.9.1 仮想変換, 18.2

アクション, 18.2.2

例, 18.2.4

モデル, 18.2.1

パラメータ, 18.2.3

VLV, 9.3.4

W

書込み可能な属性, 18.3

書込み変換, 18.2.1.2

Copyright © 2001, 2013, Oracle and/or its affiliates. All rights reserved.