Oracle® Fusion Middleware

Oracle Unified Directory管理者ガイド

11g リリース2 (11.1.2)

B72794-02(原本部品番号:E22648-05)

2013年6月

Oracle Fusion Middleware Oracle Unified Directory管理者ガイド 11g リリース2 (11.1.2)

B72794-02

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

原本主著者:  Devanshi Mohan、Showvik Chowdhuri

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

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

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

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 Unified Directoryの新機能

- Oracle Unified Directory 11gリリース2 (11.1.2)の新機能

第I部 Oracle Unified Directoryの概要

1 Oracle Unified Directoryの概要

- 1.1 Oracle Unified Directoryとは

- 1.1.1 Oracle Unified Directoryのコンポーネント

- 1.1.2 Oracle Unified Directoryのインストール・タイプ

- 1.1.2.1 ディレクトリ・サーバーの設定

- 1.1.2.2 プロキシ・サーバーの設定

- 1.1.2.3 レプリケーション・ゲートウェイ・サーバーの設定

- 1.1.3 Oracle Unified Directoryと他のディレクトリの同期

- 1.1.3.1 Oracle Unified DirectoryとOracle Internet Directoryの間の同期

- 1.1.3.2 Oracle Unified Directoryとサード・パーティ・ディレクトリの間の同期

- 1.2 ディレクトリ・サーバーの概要

- 1.3 プロキシ・サーバーの概要

- 1.3.1 プロキシ・サーバーとは

- 1.3.2 プロキシ・サーバーを使用する理由

- 1.4 レプリケーション・ゲートウェイの概要

- 1.4.1 レプリケーション・ゲートウェイとは

- 1.4.2 レプリケーション・ゲートウェイの役割

- 1.4.3 レプリケーション・ゲートウェイの制限事項

2 ディレクトリ・サーバーを使用するデプロイメントの例

- 2.1 小規模なレプリケートされるトポロジ

- 2.1.1 トポロジにおけるディレクトリ・サーバーの役割

- 2.1.2 トポロジにおけるレプリケーション・サーバーの役割

- 2.2 複数のデータ・センターのトポロジ

- 2.2.1 複数のデータ・センターとレプリケーション・グループ

- 2.2.2 複数のデータ・センターとウィンドウ・メカニズム

3 プロキシ・サーバーを使用するデプロイメントの例

- 3.1 プロキシ・デプロイメント・タイプの決定

- 3.2 構成1: 単純なロード・バランシング

- 3.3 構成2: 単純な分散

- 3.4 構成3: データ・センター間のフェイルオーバー

- 3.5 構成4: 分散とロード・バランシングの併用

- 3.6 構成5: 分散とデータ・センター間のフェイルオーバーの併用

- 3.7 構成6: エンタープライズ・ユーザー・セキュリティ

- 3.8 レプリケートされる複数のプロキシ

第II部 Oracle Unified Directoryの概念およびアーキテクチャ

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

- 4.1 Oracle Unified Directoryのコンポーネント

- 4.1.1 ネットワーク・グループ

- 4.1.2 ワークフロー

- 4.1.3 ワークフロー要素

- 4.2 Oracle Unified Directoryのアーキテクチャ

5 Oracle Unified Directory高可用性デプロイメントの理解

- 5.1 高可用性とは

- 5.2 可用性とシングル・ポイント障害

- 5.2.1 SPOFのタイプ

- 5.2.1.1 ハードウェア障害

- 5.2.1.2 ソフトウェア障害

- 5.2.2 SPOFを抑制する一般的な手法 - 冗長性

- 5.3 冗長性を使用した高可用性の実現

- 5.3.1 ハードウェア・レベルでの冗長性

- 5.3.2 レプリケーションを使用するディレクトリ・サーバー・レベルでの冗長性

- 5.3.3 冗長ソリューションの一部としてのプロキシ・サーバーの使用方法

- 5.3.4 アプリケーションの分離を使用した高可用性の実現

- 5.3.5 レプリケーション・ゲートウェイを使用した高可用性の実現

- 5.4 冗長性を使用して高可用性を実現するサンプル・トポロジ

6 Oracle Unified Directoryレプリケーション・モデルの理解

- 6.1 レプリケーション・アーキテクチャの概要

- 6.1.1 基本的なレプリケーション・アーキテクチャ

- 6.1.2 レプリケーション・サーバー

- 6.1.3 レプリケーション変更番号

- 6.1.4 レプリケーション・サーバーの状態

- 6.1.5 操作の依存性

- 6.2 レプリケーションの動作

- 6.2.1 レプリケーションの初期化

- 6.2.1.1 構成データの手動レプリケート

- 6.2.2 ディレクトリ・サーバーの変更処理

- 6.2.3 レプリケーション・サーバーの選択

- 6.2.3.1 レプリケーション・サーバーの選択アルゴリズム

- 6.2.3.2 レプリケーション・サーバーのロード・バランシング

- 6.2.4 変更のリプレイ

- 6.2.5 自動修復

- 6.2.6 ディレクトリ・サーバーのクラッシュ

- 6.2.7 レプリケーション・サーバーのクラッシュ

- 6.3 履歴情報と競合解消

- 6.3.1 レプリケーション競合とは

- 6.3.2 変更の競合の解消

- 6.3.3 名前の競合の解消

- 6.3.4 履歴情報のパージ

- 6.4 スキーマ・レプリケーション

- 6.4.1 スキーマ・レプリケーション・アーキテクチャ

- 6.5 レプリケーション・ステータス

- 6.5.1 レプリケーション・ステータスの定義

- 6.5.2 低下ステータス

- 6.5.3 完全更新ステータスと不正生成IDステータス

- 6.6 レプリケーション・グループ

- 6.7 保証レプリケーション

- 6.7.1 保証レプリケーション・モード

- 6.7.1.1 セーフ・データ・モード

- 6.7.1.2 セーフ読取りモード

- 6.7.1.3 セーフ読取りモードとレプリケーション・グループ

- 6.7.2 保証レプリケーションの接続アルゴリズム

- 6.7.3 保証レプリケーションとレプリケーション・ステータス

- 6.7.4 保証レプリケーションの監視

- 6.8 部分レプリケーション

- 6.8.1 部分データ・セットの識別

- 6.8.2 部分レプリケーションのフィルタリング

- 6.8.3 部分レプリケーションとローカル操作

7 Oracle Unified Directory索引モデルの理解

- 7.1 索引の概要

- 7.1.1 索引とは

- 7.1.2 索引の重要性の理解

- 7.2 索引タイプ

- 7.2.1 近似索引

- 7.2.2 等価索引

- 7.2.3 順序付き索引

- 7.2.4 プレゼンス索引

- 7.2.5 部分文字列索引

- 7.3 索引エントリ制限

- 7.4 検索の評価

- 7.5 索引の管理

8 Oracle Unified Directoryのアクセス制御モデルの理解

- 8.1 アクセス制御の原則

- 8.1.1 アクセス制御の概要

- 8.1.2 ACIの構造

- 8.1.3 ディレクトリ・サーバーのグローバルACI

- 8.1.4 ACI評価

- 8.1.5 ACI制限事項

- 8.1.6 アクセス制御とレプリケーション

- 8.2 ACI構文

- 8.2.1 ACI構文の概要

- 8.2.2 ターゲットの定義

- 8.2.2.1 ディレクトリ・エントリのターゲット

- 8.2.2.2 属性のターゲット指定

- 8.2.2.3 エントリと属性のターゲット指定

- 8.2.2.4 LDAPフィルタを使用したエントリまたは属性のターゲット指定

- 8.2.2.5 LDAPフィルタを使用した属性値のターゲット指定

- 8.2.2.6 単一のディレクトリ・エントリのターゲット指定

- 8.2.2.7 ACIの有効範囲の指定

- 8.2.2.8 LDAP制御のターゲット指定

- 8.2.2.9 LDAP拡張操作のターゲット指定

- 8.2.3 権限の定義

- 8.2.3.1 アクセスの許可または拒否

- 8.2.3.2 権限の割当て

- 8.2.3.3 LDAP操作に必要な権限

- 8.2.3.4 権限の構文

- 8.3 バインド・ルール

- 8.3.1 バインド・ルールの概要

- 8.3.2 ブール・バインド・ルールの使用

- 8.4 バインド・ルールの構文

- 8.4.1 バインド・ルールの構文の概要

- 8.4.2 ユーザー・アクセスの定義(userdnキーワード)

- 8.4.2.1 汎用アクセスの定義(allキーワード)

- 8.4.2.2 匿名アクセスの定義(anyoneキーワード)

- 8.4.2.3 自己アクセスの定義(selfキーワード)

- 8.4.2.4 親アクセスの定義(parentキーワード)

- 8.4.2.5 LDAP URLを使用したユーザーの指定

- 8.4.2.6 ワイルドカードを使用したユーザーの指定

- 8.4.2.7 LDAP URLの論理ORを使用したユーザーの指定

- 8.4.2.8 特定のLDAP URLの除外

- 8.4.3 グループ・アクセスの定義(groupdnキーワード)

- 8.4.3.1 単一のLDAP URLを使用したグループの指定

- 8.4.3.2 LDAP URLの論理ORを使用したグループの指定

- 8.4.4 値マッチングに基づくアクセスの定義(userattrキーワード)

- 8.4.4.1 バインド・タイプ・フォーマット

- 8.4.4.2 属性値フォーマット

- 8.4.4.3 USERDNバインド・タイプの例

- 8.4.4.4 GROUPDNバインド・タイプの例

- 8.4.4.5 LDAPURLバインド・タイプの例

- 8.4.4.6 属性値の例

- 8.4.4.7 継承

- 8.4.4.8 継承の例

- 8.4.4.9 追加権限

- 8.4.5 特定のIPアドレスからのアクセスの定義(ipキーワード)

- 8.4.6 特定のドメインからのアクセスの定義(dnsキーワード)

- 8.4.7 特定の時刻または曜日におけるアクセスの定義(timeofdayおよびdayofweekキーワード)

- 8.4.8 認証メソッドに基づくアクセスの定義(authmethodキーワード)

- 8.4.8.1 認証メソッドの例

- 8.4.9 接続のセキュリティ強度係数に基づくアクセスの定義(ssfキーワード)

- 8.4.9.1 DIGEST-MD5 QOPのキー・サイズ・マッピング

- 8.4.9.2 TLS暗号のキー・サイズ・マッピング

- 8.4.9.3 例

- 8.5 Oracle Directory Server Enterprise Editionのアクセス制御モデルとの互換性

- 8.5.1 グローバルACI

- 8.5.2 識別名(DN)のワイルドカード・マッチング

- 8.5.3 特権サブシステムの影響

- 8.5.4 targetscopeキーワード

- 8.5.5 LDAPの変更の増分

- 8.5.6 マクロのサポート

- 8.5.7 rolednキーワード

- 8.6 高度なアクセス制御のためのマクロACIの使用

- 8.6.1 マクロとは

- 8.6.2 マクロACIの例

- 8.6.3 マクロACIの構文

- 8.6.3.1 ターゲット内での($dn)マッチング

- 8.6.3.2 ($attr.attrName)のマクロ・マッチング

9 Oracle Unified Directoryスキーマ・モデルの理解

- 9.1 一致ルールの理解

- 9.1.1 一致ルールの説明形式

- 9.1.2 一般に使用される一致ルール

- 9.1.3 相対時間の一致ルール

- 9.1.4 部分的な日付や時間の一致ルール

- 9.1.5 値の正規化

- 9.2 属性構文の理解

- 9.2.1 属性構文の説明形式

- 9.2.2 一般的に使用される属性構文

- 9.2.3 パターン一致構文の拡張

- 9.2.4 列挙構文の拡張

- 9.2.5 置換構文の拡張

- 9.3 属性タイプの理解

- 9.3.1 属性タイプの説明形式

- 9.3.2 属性タイプの継承

- 9.3.3 属性タイプの実装

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

- 9.4.1 オブジェクト・クラスの説明形式

- 9.4.2 オブジェクト・クラスの種類

- 9.4.3 オブジェクト・クラスの継承

- 9.4.4 ディレクトリ・サーバーのオブジェクト・クラスの実装

- 9.5 名前書式の理解

- 9.5.1 名前書式の説明形式

- 9.6 DITコンテンツ・ルールの理解

- 9.6.1 DITコンテンツ・ルールの説明形式

- 9.6.2 DITコンテンツ・ルールの実装

- 9.7 DIT構造ルールの理解

- 9.7.1 DIT構造ルールの説明形式

- 9.7.2 DIT構造ルールと複数のスキーマ

- 9.8 一致ルールの使用の理解

10 rootユーザーと特権サブシステムの理解

- 10.1 Rootユーザー・アカウント

- 10.2 特権サブシステム

- 10.3 通常ユーザーへの権限の割当て

- 10.4 Rootユーザーへの権限の割当て

11 プロキシ機能の理解

- 11.1 プロキシを使用したロード・バランシング

- 11.1.1 フェイルオーバー・ロード・バランシング

- 11.1.2 最適ロード・バランシング

- 11.1.2.1 飽和レベルの決定

- 11.1.3 比例ロード・バランシング

- 11.1.4 飽和ロード・バランシング

- 11.1.5 検索フィルタ・ロード・バランシング

- 11.2 プロキシを使用したデータ分散

- 11.2.1 数値分散

- 11.2.2 辞書編集分散

- 11.2.3 容量分散

- 11.2.4 DNパターン分散

- 11.3 グローバル索引カタログ

- 11.4 プロキシを使用したDNリネーム

- 11.4.1 DNリネーム・ワークフロー要素の動作

- 11.5 RDNの変更

- 11.6 変換フレームワークの理解

- 11.6.1 変換の概要

- 11.6.1.1 変換モデル

- 11.6.1.2 Oracle Unified Directoryでの変換の実装

- 11.6.2 変換のコンポーネント

- 11.6.2.1 変換のタイプ

- 11.6.2.2 変換条件

- 11.6.2.3 変換のための属性値の定義

- 11.6.3 変換の構成

- 11.6.3.1 構成モデルの概要

- 11.6.3.2 CLIを使用した変換の構成例

12 Oracle Unified Directoryのマッピングの理解

- 12.1 アイデンティティ・マッパーの概要

- 12.2 サポートされているアイデンティティ・マッパー

- 12.2.1 完全一致アイデンティティ・マッパー

- 12.2.2 一致と置換アイデンティティ・マッパー

- 12.3 アイデンティティ・マッパーのコンポーネント

- 12.3.1 グローバル構成

- 12.3.2 ネットワーク・グループ

- 12.4 アイデンティティ・マッパーの構成

- 12.4.1 グローバル・アイデンティティ・マッパーの構成

- 12.4.2 ネットワーク・グループ・アイデンティティ・マッパーの構成

- 12.5 アイデンティティ・マッパーの選択

- 12.6 アイデンティティ・マッパーの順序付け

第III部 基本的な管理

13 サーバーの起動と停止

- 13.1 サーバーの起動

- 13.1.1 start-dsを使用したサーバーの起動

- 13.1.2 フォアグラウンド・プロセスとしてのサーバーの起動

- 13.1.3 サーバーの再起動

- 13.1.4 スクリプトを使用したサーバーの起動(UNIX/Linux)

- 13.2 サーバーの停止

- 13.2.1 stop-dsを使用したサーバーの停止

- 13.2.2 フォアグラウンドで実行しているサーバーの停止

- 13.2.3 スクリプトを使用したサーバーの停止(UNIX/Linux)

- 13.3 サーバーが起動しているか停止しているかの確認

- 13.3.1 サーバー・ステータスの確認

- 13.4 非ルート・ユーザーとしてのサーバーの実行

- 13.4.1 非ルート・ユーザーとしてサーバーを実行する理由

- 13.4.2 標準LDAPポートで非ルート・ユーザーとして実行する方法

14 サーバー・インスタンスの構成

- 14.1 dsconfigを使用したサーバー構成の管理

- 14.1.1 dsconfigコマンドの概要

- 14.1.1.1 dsconfigおよび証明書のチェック

- 14.1.1.2 dsconfigのサブコマンド

- 14.1.1.3 dsconfigの拡張プロパティ

- 14.1.2 対話型モードでのdsconfigの使用

- 14.1.3 dsconfigのヘルプ

- 14.1.3.1 グローバル使用

- 14.1.3.2 正しいサブコマンドの確認

- 14.1.3.3 個々のサブコマンドのヘルプ

- 14.1.3.4 コンポーネントのプロパティの概要表示

- 14.1.3.5 プロパティの詳細ヘルプ表示

- 14.1.4 dsconfigを使用したサーバー・インスタンスの構成

- 14.1.4.1 コンポーネントのプロパティを表示するには

- 14.1.4.2 コンポーネントを一覧表示するには

- 14.1.4.3 コンポーネントを作成するには

- 14.1.4.4 コンポーネントのプロパティを変更するには

- 14.1.4.5 複数値プロパティの値を変更するには

- 14.1.4.6 コンポーネントを削除するには

- 14.1.4.7 バッチ・モードでdsconfigを使用するには

- 14.1.5 dsconfigを使用した接続ハンドラの構成

- 14.1.5.1 すべての接続ハンドラの表示

- 14.1.5.2 LDAP接続ハンドラの構成

- 14.1.5.3 LDIF接続ハンドラの構成

- 14.1.5.4 JMX接続ハンドラの構成

- 14.1.6 dsconfigを使用したネットワーク・グループの構成

- 14.1.6.1 ネットワーク・グループの作成

- 14.1.6.2 ネットワーク・グループのプロパティの変更

- 14.1.6.3 ネットワーク・グループのサービス品質ポリシーの作成

- 14.1.6.4 ネットワーク・グループのサービス品質ポリシーの変更

- 14.1.6.5 ネットワーク・グループのルートDSEエントリの再配置

- 14.1.7 dsconfigを使用したワークフローの構成

- 14.1.7.1 既存ワークフローのリスト

- 14.1.7.2 ワークフロー・プロパティの表示

- 14.1.7.3 ワークフローの作成

- 14.1.8 dsconfigを使用したワークフロー要素の構成

- 14.1.8.1 ワークフロー要素のリスト

- 14.1.8.2 ワークフロー要素の作成

- 14.1.8.3 ワークフロー要素の変更

- 14.1.9 dsconfigを使用したプラグインの構成

- 14.1.9.1 プラグイン・タイプの概要

- 14.1.9.2 プラグイン構成の変更

- 14.1.10 dsconfigを使用した接尾辞の構成

- 14.1.10.1 セットアップ時でのdsconfigを使用した接尾辞の構成

- 14.1.10.2 実行中のサーバー上でのdsconfigを使用した接尾辞の構成

- 14.2 Oracle Directory Services Managerを使用したサーバー構成の管理

- 14.2.1 構成ビューの選択

- 14.2.2 ODSMを使用してオブジェクトを構成するためのショートカット

- 14.2.3 ODSMを使用した接尾辞の構成

- 14.2.3.1 接尾辞の作成

- 14.2.3.2 接尾辞プロパティの表示と編集

- 14.2.3.3 接尾辞の削除

- 14.2.4 ODSMを使用したワークフロー要素の構成

- 14.2.4.1 ワークフロー要素の作成

- 14.2.4.2 ワークフロー要素のプロパティの表示と編集

- 14.2.4.3 ワークフロー要素の削除

- 14.2.5 ODSMを使用したワークフローの構成

- 14.2.5.1 ワークフローの作成

- 14.2.5.2 ワークフロー・プロパティの表示と編集

- 14.2.5.3 ワークフローの削除

- 14.2.6 ODSMを使用した接続ハンドラの構成

- 14.2.6.1 接続ハンドラの作成

- 14.2.6.2 接続ハンドラの変更

- 14.2.6.3 接続ハンドラの削除

- 14.2.7 ODSMを使用したネットワーク・グループの構成

- 14.2.7.1 ネットワーク・グループの作成

- 14.2.7.2 ネットワーク・グループの変更

- 14.2.7.3 ネットワーク・グループの削除

- 14.2.8 一般的なサーバー構成の変更

- 14.3 サーバーへの管理トラフィックの管理

- 14.3.1 管理コネクタの概要

- 14.3.2 管理接尾辞へのアクセス

- 14.3.3 管理コネクタの構成

- 14.3.4 管理コネクタのキー・マネージャと信頼マネージャ

- 14.4 タスクとしてのコマンドの構成

- 14.4.1 タスクをスケジュールできるコマンド

- 14.4.2 実行可能タスクの制御

- 14.4.3 タスクのスケジュールと構成

- 14.4.3.1 タスクのスケジュール

- 14.4.3.2 再帰タスクのスケジュール

- 14.4.3.3 タスク通知の構成

- 14.4.3.4 タスク依存性の構成

- 14.4.4 スケジュール済タスクの管理と監視

- 14.4.4.1 スケジュール済タスクについての情報の取得

- 14.4.4.2 スケジュール済タスクのキャンセル

- 14.4.4.3 再帰タスクのキャンセル

- 14.5 DSMLゲートウェイのデプロイおよび構成

- 14.5.1 DSMLゲートウェイのデプロイ

- 14.5.1.1 Oracle WebLogic ServerへのDSMLゲートウェイのデプロイ

- 14.5.1.2 IBM WebSphereへのDSMLゲートウェイのデプロイ

- 14.5.2 DSMLゲートウェイ・デプロイメントの確認

- 14.5.2.1 JXplorerによるDSMLゲートウェイ・デプロイメントの確認

- 14.5.2.2 Directory Server Resource KitによるDSMLゲートウェイ・デプロイメントの確認

15 プロキシ・コンポーネントの構成

- 15.1 dsconfigを使用したプロキシ構成の管理

- 15.1.1 リモートLDAPサーバーとの通信の構成

- 15.1.1.1 リモート・サーバーとの通信のコンポーネント

- 15.1.1.2 LDAPサーバー拡張の構成

- 15.1.1.3 プロキシLDAPワークフロー要素の構成

- 15.1.2 バインド・モードの構成

- 15.1.2.1 サーバーを最適化するためのバインド・モード・パラメータの構成

- 15.1.3dsconfigを使用したロード・バランシングの構成

- 15.1.3.1 ロード・バランシングを構成するには

- 15.1.3.2 ロード・バランシング・ワークフロー要素の作成

- 15.1.3.3 ロード・バランシング・アルゴリズムの作成

- 15.1.3.4 ロード・バランシング・ルートの作成

- 15.1.3.5 ロード・バランシングのプロパティの変更

- 15.1.4 dsconfigを使用した分散の構成

- 15.1.4.1 分散を構成するには

- 15.1.4.2 分散ワークフロー要素の作成

- 15.1.4.3 分散アルゴリズムの作成

- 15.1.4.4 分散パーティションの作成

- 15.1.4.5 DNの変更リクエストの管理

- 15.1.4.6 ワークフローのクリティカル度の構成

- 15.1.4.7 ワークフロー要素のクリティカル度の構成

- 15.1.4.8 分散構成の削除

- 15.1.5 dsconfigを使用したDNリネームの構成

- 15.1.5.1 DNリネーム構成の変更

- 15.1.6 dsconfigを使用したRDN変更の構成

- 15.1.6.1 RDNリネーム構成の変更

- 15.1.7 コマンドラインを使用したグローバル索引の構成

- 15.1.7.1 gicadmを使用したグローバル索引カタログの構成

- 15.1.7.2 グローバル索引カタログのレプリケーション

- 15.1.7.3 グローバル索引カタログに必要な制御のOracle Unified Directoryを使用した構成

- 15.1.8 Microsoft Active Directoryページングの構成

- 15.1.8.1 Active Directoryページング・ワークフロー要素の構成

- 15.1.8.2 Active Directoryから返される特定の属性のスキャン

- 15.2 ODSMを使用したプロキシ構成の管理

- 15.2.1 ODSMを使用したロード・バランシングの構成

- 15.2.2 ODSMを使用した分散の構成

- 15.2.3 ODSMを使用したワークフローのクリティカル度の構成

- 15.2.4 ODSMを使用した変換の構成

- 15.2.4.1 変換の作成

- 15.2.4.2 変換の変更

- 15.2.4.3 変換の削除

- 15.2.4.4 値定義画面からの値の選択

16 プロキシ構成の例

- 16.1 ロード・バランシングの構成

- 16.1.1 単純なロード・バランシングを構成するには

- 16.2 分散の構成

- 16.2.1 単純な分散を構成するには

- 16.3 分散およびロード・バランシングの構成

- 16.3.1 分散をロード・バランシングとともに構成するには

- 16.4 データ・センター間のフェイルオーバーの構成

- 16.5 データ・センター間のフェイルオーバーを使用した分散の構成

17 ディレクトリ・データの管理

- 17.1 データのインポートとエクスポート

- 17.1.1 スタンドアロン・ディレクトリ・サーバーへのデータの移入

- 17.1.2 import-ldifを使用したデータのインポート

- 17.1.2.1 import-ldifの操作モード

- 17.1.2.2 オフライン・モードでデータをインポートする方法

- 17.1.2.3 オフライン・インポート中に既存のデータを置換する方法

- 17.1.2.4 既存のデータにインポートしたデータを追加する方法

- 17.1.2.5 部分的にファイルをインポートする方法

- 17.1.2.6 フィルタを使用して部分的にファイルをインポートする方法

- 17.1.2.7 インポート中に属性を含めるまたは除外する方法

- 17.1.2.8 圧縮済LDIFファイルをインポートする方法

- 17.1.2.9 インポート中に拒否またはスキップされたエントリを記録する方法

- 17.1.2.10 MakeLDIFテンプレートからデータをインポートする方法

- 17.1.2.11 オンライン・モードでインポートを実行する方法

- 17.1.2.12 インポートをスケジュールする方法

- 17.1.3 export-ldifを使用したデータのエクスポート

- 17.1.3.1 export-ldifの操作モード

- 17.1.3.2 LDIFにデータをエクスポートする方法

- 17.1.3.3 部分的にデータをエクスポートする方法

- 17.1.3.4 フィルタを使用してバックエンドの一部をエクスポートする方法

- 17.1.3.5 エクスポート中に属性を含めるまたは除外する方法

- 17.1.3.6 LDIFをエクスポートしてそのファイルを圧縮する方法

- 17.1.3.7 オンライン・モードでエクスポートを実行する方法

- 17.1.3.8 エクスポートをスケジュールする方法

- 17.1.4 MakeLDIFテンプレート・ファイルの作成

- 17.1.4.1 テンプレート・ファイルの書式

- 17.1.4.2 make-ldifテンプレート・ファイル・タグ

- 17.1.4.3 カスタム・タグの定義

- 17.2 大規模データ・セットのインポート

- 17.2.1 インポート・オプションの設定

- 17.2.2 JVMおよびJava引数のチューニング

- 17.3 データのバックアップおよびリストア

- 17.3.1 バックアップおよびリストアのプロセスの概要

- 17.3.2 データのバックアップ

- 17.3.2.1 すべてのバックエンドをバックアップする方法

- 17.3.2.2 暗号化および署名付きハッシュを使用してすべてのバックエンドをバックアップする方法

- 17.3.2.3 すべてのバックエンドで増分バックアップを実行する方法

- 17.3.2.4 特定のバックエンドをバックアップする方法

- 17.3.2.5 特定のバックエンドに対して増分バックアップを実行する方法

- 17.3.2.6 バックアップをタスクとしてスケジュールする方法

- 17.3.3 サーバー構成のバックアップ

- 17.3.4 障害時リカバリのためのバックアップ

- 17.3.4.1 障害時リカバリのためにディレクトリ・サーバーをバックアップする方法

- 17.3.5 ファイル・システム・スナップショットを使用したデータのバックアップおよびリストア

- 17.3.5.1 専用バックアップ・サーバーでZFSスナップショットを取る方法

- 17.3.5.2 ZFSスナップショットからディレクトリ・サーバーをリストアする方法

- 17.3.6 データのリストア

- 17.3.6.1 バックエンドをリストアする方法

- 17.3.6.2 増分バックアップからバックエンドをリストアする方法

- 17.3.6.3 リストアをタスクとしてスケジュールする方法

- 17.3.6.4 構成ファイルをリストアする方法

- 17.3.6.5 障害時リカバリ中にディレクトリ・サーバーをリストアする方法

- 17.3.7 レプリケートされたディレクトリ・サーバーのリストア

- 17.3.8 バックアップ・データの削除

- 17.3.8.1 バックアップ・ファイルを削除する方法

- 17.4 ディレクトリ・データの検索

- 17.4.1 ldapsearchコマンドの概要

- 17.4.2 ldapsearchの場所と形式

- 17.4.2.1 一般的なldapsearchオプション

- 17.4.3 検索基準の理解

- 17.4.3.1 フィルタのタイプと演算子の指定

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

- 17.4.3.3 検索フィルタでのUTF-8エンコードの使用方法

- 17.4.3.4 検索フィルタでの特殊文字の使用方法

- 17.4.4 ldapsearchの例

- 17.4.4.1 すべてのエントリを返す方法

- 17.4.4.2 特定のユーザーを検索する方法

- 17.4.4.3 特定のユーザー属性を検索する方法

- 17.4.4.4 ベース範囲を指定して検索を実行する方法

- 17.4.4.5 1レベル範囲を指定して検索を実行する方法

- 17.4.4.6 サブツリー範囲を指定して検索を実行する方法

- 17.4.4.7 属性名のみを返す方法

- 17.4.4.8 ユーザー属性のみを返す方法

- 17.4.4.9 ベースDNのみを返す方法

- 17.4.4.10 特定のオブジェクト・クラスを検索する方法

- 17.4.4.11 ディレクトリ内のすべてのエントリのカウントを返す方法

- 17.4.4.12 複合フィルタを使用して検索を実行する方法

- 17.4.4.13 フィルタ・ファイルを使用して検索を実行する方法

- 17.4.4.14 検索で返されるエントリ数を制限する方法

- 17.4.5 Oracle Directory Services Managerを使用したデータの検索

- 17.4.5.1 複雑なLDAP検索の実行

- 17.5 拡張検索機能の使用方法

- 17.5.1 特別なエントリおよび属性の検索

- 17.5.1.1 操作属性を検索する方法

- 17.5.1.2 ルートDSEエントリを検索する方法

- 17.5.1.3 ACI属性を検索する方法

- 17.5.1.4 スキーマ・エントリを検索する方法

- 17.5.1.5 構成エントリを検索する方法

- 17.5.1.6 監視エントリを検索する方法

- 17.5.2 SSL経由の検索

- 17.5.2.1 ブラインド信頼を使用してSSL経由で検索する方法

- 17.5.2.2 トラスト・ストアを使用してSSL経由で検索する方法

- 17.5.2.3 トラスト・ストアを指定しないでSSL経由で検索する方法

- 17.5.2.4 キーストアを使用してSSL経由で検索する方法

- 17.5.2.5 StartTLSを使用して検索する方法

- 17.5.2.6 DIGEST-MD5クライアント認証を利用してSASLを使用して検索する方法

- 17.5.2.7 GSSAPIメカニズムを利用してSASLを使用して検索する方法

- 17.5.2.8 PLAINメカニズムを利用してSASLを使用して検索する方法

- 17.5.3 制御を使用した検索

- 17.5.3.1 使用可能な制御の表示

- 17.5.3.2 結合検索制御を使用した検索

- 17.5.3.3 近接検索制御を使用した検索

- 17.5.3.4 アカウント・ユーザビリティ・リクエスト制御を使用した検索

- 17.5.3.5 認可アイデンティティ・リクエスト制御を使用した検索

- 17.5.3.6 実効権限取得制御を使用した検索

- 17.5.3.7 LDAPアサーション制御を使用した検索

- 17.5.3.8 LDAPサブエントリ制御を使用した検索

- 17.5.3.9 DSA ITの管理制御を使用した検索

- 17.5.3.10 一致値フィルタ制御を使用した検索

- 17.5.3.11 パスワード・ポリシー制御を使用した検索

- 17.5.3.12 永続検索制御を使用した検索

- 17.5.3.13 プロキシ設定された認可制御を使用した検索

- 17.5.3.14 サーバー側ソート制御を使用した検索

- 17.5.3.15 単純なページングの結果制御を使用した検索

- 17.5.3.16 仮想リスト表示制御を使用した検索

- 17.5.4 詳細モードでの検索とプロパティ・ファイルを使用した検索

- 17.5.4.1 詳細モードで検索する方法

- 17.5.4.2 プロパティ・ファイルを使用して検索する方法

- 17.5.5 国際化されたエントリの検索

- 17.5.5.1 例

- 17.5.5.2 サポートされている照合ルール

- 17.6 ディレクトリ・データの追加、変更および削除

- 17.6.1 ディレクトリ・エントリの追加

- 17.6.1.1 ルート・エントリを作成する方法

- 17.6.1.2 ldapmodifyで--defaultAddオプションを使用してエントリを追加する方法

- 17.6.1.3 ldapmodifyでLDIF更新文を使用してエントリを追加する方法

- 17.6.2 属性の追加

- 17.6.2.1 エントリに属性を追加する方法

- 17.6.2.2 ACI属性を追加する方法

- 17.6.2.3 国際化属性を追加する方法

- 17.6.3 ディレクトリ・エントリの変更

- 17.6.3.1 属性値を変更する方法

- 17.6.3.2 前後のスナップショットで属性を変更する方法

- 17.6.3.3 属性を削除する方法

- 17.6.3.4 RDNを変更する方法

- 17.6.3.5 エントリを移動する方法

- 17.6.4 ディレクトリ・エントリの削除

- 17.6.4.1 ldapmodifyでエントリを削除する方法

- 17.6.4.2 ldapdeleteでエントリを削除する方法

- 17.6.4.3 DNファイルを使用して複数のエントリを削除する方法

- 17.7 ディレクトリ・データへの索引付け

- 17.7.1 ローカルDBバックエンドでの索引の構成

- 17.7.1.1 新規ローカルDB索引を作成する方法

- 17.7.2 VLV索引の構成

- 17.7.2.1 新規VLV索引を作成する方法

- 17.8 格納されるデータ・サイズの削減

- 17.8.1 圧縮エンコーディングを有効化または無効化する方法

- 17.8.2 エントリの圧縮を有効化または無効化する方法

- 17.9 属性値の一意性の確認

- 17.9.1 一意な属性プラグインの概要

- 17.9.2 dsconfigを使用した一意な属性プラグインの構成

- 17.9.2.1 uid属性の値の一意性を確保する方法

- 17.9.2.2 他の属性の値の一意性を確保する方法

- 17.9.3 レプリケーションと一意な属性プラグイン

- 17.10 仮想属性の構成

- 17.10.1 既存の仮想属性をリストする方法

- 17.10.2 新規仮想属性を作成する方法

- 17.10.3 仮想属性を有効化または無効化する方法

- 17.10.4 仮想属性の構成を表示する方法

- 17.10.5 仮想属性の構成を変更する方法

- 17.11 LDAPサブエントリの使用方法

- 17.11.1 相対サブツリー

- 17.12 集合属性の使用方法

- 17.12.1 集合属性の標準に対する拡張

- 17.12.1.1 集合属性の指定

- 17.12.1.2 集合属性と競合解消

- 17.12.1.3 特定のエントリからの集合属性の除外

- 17.12.2 集合属性の構成

- 17.12.2.1 新規集合属性を作成する方法

- 17.12.2.2 集合属性を削除する方法

- 17.12.2.3 エントリに適用される集合属性をリストする方法

- 17.12.3 継承集合属性

- 17.12.3.1 継承集合属性の指定

- 17.13 リフェラルの構成

- 17.13.1 レプリケートされたトポロジでのリフェラル

- 17.13.2 リフェラル・リストの手動による構成

- 17.13.3 スマート・リフェラル

- 17.13.3.1 スマート・リフェラルを構成する方法

- 17.13.3.2 スマート・リフェラルを変更する方法

- 17.13.3.3 スマート・リフェラルを削除する方法

- 17.13.4 LDAP URL

- 17.13.4.1 LDAP URLの例

- 17.14 Oracle Directory Services Managerを使用した仮想属性の管理

- 17.14.1 既存の仮想属性の表示

- 17.14.2 仮想属性の作成

- 17.15 Oracle Directory Services Managerを使用したデータの管理

- 17.15.1 エントリの表示

- 17.15.2 エントリの属性の表示

- 17.15.3 エントリの検索

- 17.15.4 エントリの追加

- 17.15.5 既存のエントリに基づくエントリの追加

- 17.15.6 エントリの削除

- 17.15.7 エントリおよびサブツリーの削除

- 17.15.8 エントリのRDNの変更

- 17.15.9 LDIFファイルからのデータのインポート

- 17.15.10 LDIFファイルへのデータのエクスポート

18 Oracle Directory Services Managerを使用したOracle Unified Directoryへのアクセス

- 18.1 Oracle Directory Services Managerの起動

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

- 18.3 Oracle Directory Services Managerを使用したサーバー情報の表示

- 18.3.1 バージョン情報の表示

- 18.3.2 サーバー・ロールの表示

- 18.3.3 サーバー統計情報の表示

- 18.3.4 構成済接続ハンドラの表示

- 18.3.5 構成済ネーミング・コンテキストの表示

- 18.3.6 構成済データ・ソースの表示

19 ユーザーおよびグループの管理

- 19.1 ユーザー・アカウントの管理

- 19.1.1 パスワードの変更

- 19.1.1.1 ディレクトリ・マネージャのパスワードを変更するには

- 19.1.1.2 リセットして、ユーザーの新規パスワードを生成するには

- 19.1.1.3 ユーザーのパスワードを変更するには

- 19.1.2 ユーザーのアカウント情報の管理

- 19.1.2.1 ユーザーのアカウント情報を表示するには

- 19.1.2.2 アカウント・ステータス情報を表示するには

- 19.1.2.3 アカウントを無効にするには

- 19.1.2.4 アカウントを有効にするには

- 19.1.2.5 orclIsEnabledを使用してアカウントを有効にするには

- 19.1.3 ユーザー・アカウントへのリソース制限の設定

- 19.1.3.1 アカウントにリソース制限を設定するには

- 19.2 ルート・ユーザーの構成

- 19.2.1 コマンドライン・ユーティリティを使用したルート・ユーザーの構成

- 19.2.1.1 グローバル・ルート・ユーザーの権限を変更するには

- 19.2.1.2 新規ルート・ユーザーを作成するには

- 19.2.1.3 既存のルート・ユーザーを編集するには

- 19.2.2 ODSMを使用したルート・ユーザーの構成

- 19.2.2.1 グローバル・ルート・ユーザーの権限の構成

- 19.2.2.2 新規ルート・ユーザーの作成

- 19.2.2.3 既存のルート・ユーザーの編集

- 19.3 グループの定義

- 19.3.1 静的グループの定義

- 19.3.1.1 groupOfNamesを使用して静的グループを作成するには

- 19.3.1.2 groupOfUniqueNamesを使用して静的グループを作成するには

- 19.3.1.3 groupOfEntriesを使用して静的グループを作成するには

- 19.3.1.4 仮想静的グループのすべてのメンバーをリストするには

- 19.3.1.5 ユーザーがメンバーになっているすべての静的グループをリストするには

- 19.3.1.6 ユーザーが仮想静的グループのメンバーかどうかを確認するには

- 19.3.2 動的グループの定義

- 19.3.2.1 動的グループを作成するには

- 19.3.2.2 動的グループのすべてのメンバーをリストするには

- 19.3.2.3 ユーザーがメンバーになっているすべての動的グループをリストするには

- 19.3.2.4 ユーザーが動的グループのメンバーかどうかを確認するには

- 19.3.3 仮想静的グループの定義

- 19.3.3.1 仮想静的グループを作成するには

- 19.3.3.2 仮想静的グループのすべてのメンバーをリストするには

- 19.3.3.3 ユーザーがメンバーになっているすべての仮想静的グループをリストするには

- 19.3.3.4 ユーザーが仮想静的グループのメンバーかどうかを確認するには

- 19.3.4 ネストされたグループの定義

- 19.3.4.1 ネストされたグループを作成するには

- 19.4 参照整合性の保持

- 19.4.1 参照整合性プラグインの概要

- 19.4.2 参照整合性プラグインを有効にするには

- 19.5 Oracle Unified DirectoryサーバーでのODSEEロールのシミュレート

- 19.5.1ユーザーがロールのメンバーかどうかを確認するには

- 19.5.2 nsRoleDN属性を使用してメンバーシップを変更するには

第IV部 高度な管理: セキュリティ、アクセス制御およびパスワード・ポリシー

20 クライアント/サーバー間のセキュリティ構成

- 20.1 SSLの迅速な起動と実行

- 20.1.1自己署名証明書を使用したSSLベースの接続を受け入れる方法

- 20.2 キー・マネージャ・プロバイダの構成

- 20.2.1 キー・マネージャ・プロバイダの概要

- 20.2.2 JKSキー・マネージャ・プロバイダの使用

- 20.2.2.1 秘密鍵を生成する方法

- 20.2.2.2 証明書に自己署名する方法

- 20.2.2.3 外部認証局を使用して証明書に署名する方法

- 20.2.2.4 JKSキー・マネージャ・プロバイダを構成する方法

- 20.2.3 PKCS #12キー・マネージャ・プロバイダの使用

- 20.2.4 PKCS #11キー・マネージャ・プロバイダの使用

- 20.2.5 本番サーバーでの証明書の置換え

- 20.2.6 ODSMによるキー・マネージャの構成

- 20.3 信頼マネージャ・プロバイダの構成

- 20.3.1 証明書信頼メカニズムの概要

- 20.3.2 ブラインド信頼マネージャ・プロバイダの使用

- 20.3.3 JKS信頼マネージャ・プロバイダの使用

- 20.3.4 PKCS #12信頼マネージャ・プロバイダの使用

- 20.3.5 ODSMによる信頼マネージャの構成

- 20.4 証明書マッパーの構成

- 20.4.1 Subject Equals DN証明書マッパーの使用

- 20.4.2 サブジェクト属性からユーザー属性証明書マッパーの使用

- 20.4.3 サブジェクトDNからユーザー属性への証明書マッパーの使用

- 20.4.4 フィンガープリント証明書マッパーの使用

- 20.5 LDAPおよびJMX用のSSLおよびStartTLSの構成

- 20.5.1 LDAPおよびLDAPS接続ハンドラの構成

- 20.5.1.1 接続ハンドラを有効化する方法

- 20.5.1.2 接続ハンドラのリスニング・ポートを指定する方法

- 20.5.1.3 接続ハンドラの認可ポリシーを指定する方法

- 20.5.1.4 接続ハンドラの証明書にニックネームを指定する方法

- 20.5.1.5 接続ハンドラのキー・マネージャ・プロバイダを指定する方法

- 20.5.1.6 接続ハンドラの信頼マネージャ・プロバイダを指定する方法

- 20.5.1.7 StartTLSサポートを有効化する方法

- 20.5.1.8 SSLベースの通信を有効化する方法

- 20.5.2 JMX接続ハンドラでのSSLの有効化

- 20.6 SASL認証の使用

- 20.6.1 サポートされているSASLメカニズム

- 20.6.2 認可ID

- 20.6.3 ANONYMOUSメカニズムのSASLオプション

- 20.6.4 CRAM-MD5メカニズムのSASLオプション

- 20.6.5 DIGEST-MD5メカニズムのSASLオプション

- 20.6.6 EXTERNALメカニズムのSASLオプション

- 20.6.7 GSSAPIメカニズムのSASLオプション

- 20.6.8 PLAINメカニズムのSASLオプション

- 20.7 SASL認証の構成

- 20.7.1 SASL EXTERNAL認証の構成

- 20.7.1.1 SASL EXTERNAL認証を可能にするためのLDAP接続ハンドラの構成

- 20.7.1.2 EXTERNAL SASLメカニズム・ハンドラの構成

- 20.7.2 SASL DIGEST-MD5認証の構成

- 20.7.3 SASL GSSAPI認証の構成

- 20.8 GSSAPI SASL認証のためのKerberosおよびOracle Unified Directoryサーバーの構成

- 20.8.1 ホスト上でKerberos V5を構成する方法

- 20.8.2 Kerberos認証用にSASLオプションを指定する方法

- 20.8.3 GSSAPIとSASLを使用したKerberos認証の構成例

- 20.8.3.1 この例での前提

- 20.8.3.2 すべてのマシン: Kerberosクライアント構成ファイルの編集

- 20.8.3.3 すべてのマシン: 管理サーバーACL構成ファイルの編集

- 20.8.3.4 KDCマシン: KDCサーバー構成ファイルの編集

- 20.8.3.5 KDCマシン: KDCデータベースの作成

- 20.8.3.6 KDCマシン: 管理プリンシパルとキータブの作成

- 20.8.3.7 KDCマシン: Kerberosデーモンの開始

- 20.8.3.8 KDCマシン: KDCマシンとOracle Unified Directoryマシンに対するホスト・プリンシパルの追加

- 20.8.3.9 KDCマシン: ディレクトリ・サーバーに対するLDAPプリンシパルの追加

- 20.8.3.10 KDCマシン: KDCへのテスト・ユーザーの追加

- 20.8.3.11 ディレクトリ・サーバー・マシン: Oracle Unified Directoryのインストール

- 20.8.3.12 ディレクトリ・サーバー・マシン: ディレクトリ・サーバーLDAPの作成と構成

- 20.8.3.13 ディレクトリ・サーバー・マシン: GSSAPIを有効にするためのディレクトリ・サーバーの構成

- 20.8.3.14 ディレクトリ・サーバー・マシン: ディレクトリ・サーバーへのテスト・ユーザーの追加

- 20.8.3.15 ディレクトリ・サーバー・マシン: テスト・ユーザーとしてのKerberosチケットの取得

- 20.8.3.16 クライアント・マシン: GSSAPIによるディレクトリ・サーバーに対する認証

- 20.8.4 dsconfigを使用したKerberosワークフロー要素の作成

- 20.8.5 Kerberos構成のトラブルシューティング

- 20.9 ldapsearchによるSSL、StartTLS、およびSASL認証のテスト

- 20.9.1 セキュリティに適用できるldapsearchコマンド・ライン引数

- 20.9.2 SSLのテスト

- 20.9.3 StartTLSのテスト

- 20.9.4 SASL EXTERNAL認証のテスト

- 20.10 s_clientテスト・ユーティリティを使用したSSLのデバッグ

- 20.10.1 シナリオ1- 接続が拒否された

- 20.10.2 シナリオ2- リターン・コード: 18 (自己署名証明書)を確認する

- 20.10.3 シナリオ3 リターン・コード: 0 (ok)を確認する

- 20.10.4 シナリオ4 - SSLHandshakeException

- 20.10.5 シナリオ5 - SASL EXTERNALバインド・リクエストを処理できない

- 20.11 Javaデバッグ情報を使用したSSLまたはTLSのデバッグ

- 20.11.1 SSLデバッグ記録の有効化

- 20.11.2 SSLデバッグ記録の無効化

- 20.12 許可および拒否ルールを使用した接続アクセスの制御

- 20.12.1 許可および拒否クライアント・ルールのプロパティ構文

- 20.12.2 許可および拒否クライアント・ルールの構成

- 20.13 強度無制限の暗号の構成

21 プロキシ/データ・ソース間のセキュリティ構成

- 21.1 プロキシによるセキュアな接続の管理

- 21.2 セキュアな接続のモード

- 21.2.1 alwaysセキュア・モード

- 21.2.2 neverセキュア・モード

- 21.2.3 userセキュア・モード

- 21.3 プロキシとデータ・ソースの間でのdsconfigを使用したセキュリティ構成

- 21.3.1 dsconfigを使用してプロキシとディレクトリ・サーバーの間のセキュリティを構成する手順

- 21.3.2 LDAP拡張の構成可能なセキュリティ関連プロパティ

22 データへのアクセス制御

- 22.1 dsconfigによるグローバルACIの管理

- 22.1.1 デフォルト・グローバルACI

- 22.1.2 グローバルACIの表示

- 22.1.3 グローバルACIの削除

- 22.1.4 グローバルACIの追加

- 22.2 ldapmodifyによるACIの管理

- 22.2.1 aci属性の値の表示

- 22.2.2 ACIの追加

- 22.2.3 ACIの削除

- 22.3 Oracle Directory Services Managerによるアクセス制御の管理

- 22.3.1 構成済ACIの表示

- 22.3.2 アクセス制御ポイントの作成

- 22.3.3 既存のアクセス制御ポイントに基づくアクセス制御ポイントの作成

- 22.3.4 アクセス制御ポイントの削除

- 22.3.5 ACIの追加

- 22.3.6 既存のACIに基づくACIの追加

- 22.3.7 ACIの変更

- 22.4 Oracle Directory Services ManagerによるマクロACIの管理

- 22.4.1 ターゲットの編集

- 22.4.2 ターゲット・フィルタの編集

- 22.4.3 ユーザーDNまたはグループDNのバインド・ルールの編集

- 22.4.4 ユーザー属性のバインド・ルールの編集

- 22.5 アクセス制御の使用例

- 22.5.1 匿名アクセスの無効化

- 22.5.2 個人エントリへの書込みアクセスの許可

- 22.5.2.1 DNSに基づく書込みアクセスの許可

- 22.5.2.2 認証方式に基づく書込みアクセスの許可

- 22.5.3 グループによる接尾辞への完全アクセスの許可

- 22.5.4 グループ・エントリを追加および削除する権限の付与

- 22.5.4.1 "Create Group" ACIの作成

- 22.5.4.2 "Delete Group" ACIの作成

- 22.5.5 グループへのユーザー自身の追加または削除の許可

- 22.5.6 グループへの条件付きアクセスの許可

- 22.5.7 アクセスの拒否

- 22.5.8 カンマを含むDNの権限の定義

- 22.6 プロキシ認可ACI

- 22.7 実効権限の表示

- 22.7.1 実効権限取得制御

- 22.7.2 実効権限取得制御の使用方法

- 22.7.3 実効権限の結果の理解

- 22.7.3.1 権限情報

- 22.7.3.2 write、selfwrite_addおよびselfwrite_delete権限

- 22.7.3.3 ログ情報

- 22.7.4 実効権限取得制御へのアクセス制限

23 管理ユーザーの管理

- 23.1 複数のルート・ユーザーの使用

- 23.2 ルート・ユーザーと特権サブシステム

- 23.3 dsconfigによるルート・ユーザーの管理

- 23.3.1 デフォルトのルート・ユーザー特権を表示するには

- 23.3.2 デフォルトのルート・ユーザー特権を編集するには

- 23.3.3 ルート・ユーザーを作成するには

- 23.3.4 ルート・ユーザーのパスワードを変更するには

- 23.3.5 ルート・ユーザーの特権を変更するには

- 23.4 ルート・ユーザーのリソース制限の設定

- 23.5 管理者の管理

- 23.5.1 新しい管理者を作成するには

- 23.5.2 ルート・ユーザーの特権を持つ管理者を作成するには

- 23.6 グローバル管理者の管理

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

- 24.1 パスワード・ポリシーのコンポーネント

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

- 24.2.1 デフォルト・パスワード・ポリシーのプロパティを表示するには

- 24.2.2 デフォルト・パスワード・ポリシーを変更するには

- 24.3 レプリケート環境でのパスワード・ポリシー

- 24.4 コマンドラインを使用したパスワード・ポリシーの構成

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

- 24.4.2 新しいパスワード・ポリシーを作成するには

- 24.4.3 初回ログイン・パスワード・ポリシーを作成するには

- 24.4.4 パスワード・ポリシーを個別アカウントに割り当てるには

- 24.4.5 パスワード・ポリシーの変更を防止するには

- 24.4.6 パスワード・ポリシーをユーザーのグループに割り当てるには

- 24.4.7 LDAPサブエントリとしてパスワード・ポリシーを定義するには

- 24.4.8 パスワード・ポリシーを削除するには

- 24.5 Oracle Directory Services Managerを使用したパスワード・ポリシーの構成

- 24.5.1 構成済パスワード・ポリシー・サブエントリのリスト

- 24.5.2 パスワード・ポリシー・サブエントリの作成

- 24.5.3 既存のパスワード・ポリシー・サブエントリに基づくパスワード・ポリシー・サブエントリの作成

- 24.5.4 パスワード・ポリシー・サブエントリの削除

- 24.5.5 構成済パスワード・ポリシーの表示

- 24.5.6 パスワード・ポリシーの変更

- 24.5.7 パスワード・ポリシーの作成

- 24.5.8 既存のパスワード・ポリシーに基づくパスワード・ポリシーの作成

- 24.5.9 パスワード・ポリシーの削除

- 24.5.10 サポートされているパスワード記憶スキームの表示

- 24.5.11 パスワード記憶スキームの有効化または無効化

- 24.6 パスワード・バリデータ

- 24.6.1 パスワード・バリデータの管理

- 24.6.1.1 使用可能なパスワード・バリデータを表示するには

- 24.6.1.2 パスワード・バリデータのプロパティを表示するには

- 24.6.1.3 パスワード・バリデータを有効化または無効化するには

- 24.6.1.4 パスワード・バリデータの値を構成するには

- 24.6.1.5 パスワード・バリデータをパスワード・ポリシーに関連付けるには

- 24.7 パスワード・ジェネレータ

- 24.7.1 構成済パスワード・ジェネレータを表示するには

- 24.7.2 パスワード・ジェネレータのプロパティを表示するには

- 24.7.3 パスワード・ジェネレータを有効化または無効化するには

- 24.7.4 パスワード・ジェネレータの値を構成するには

- 24.7.5 パスワード・ジェネレータをパスワード・ポリシーに関連付けるには

25 Oracleのエンタープライズ・ユーザー・セキュリティとの統合

- 25.1 統合シナリオ

- 25.2 このリリースでの新機能

- 25.3 エンタープライズ・ユーザー・セキュリティへのOracle Unified Directoryの統合

- 25.3.1 Oracle Unified Directoryサーバーでのエンタープライズ・ユーザー・セキュリティの構成

- 25.3.1.1 インストール時のエンタープライズ・ユーザー・セキュリティの有効化

- 25.3.1.2 既存のインスタンスでの、ODSMを使用したエンタープライズ・ユーザー・セキュリティの有効化

- 25.3.2 エンタープライズ・ユーザー・セキュリティに対応した、Oracle Unified Directoryの構成変更

- 25.3.3 Oracle Unified Directoryに対応した、Oracle Databaseの構成

- 25.3.3.1 データベースの構成

- 25.3.3.2 データベースの登録

- 25.4 エンタープライズ・ユーザー・セキュリティおよび外部LDAPディレクトリとの統合

- 25.4.1 外部ディレクトリでの統合の構成

- 25.4.1.1 Microsoft Active DirectoryのユーザーID

- 25.4.1.2 Oracle Directory Server Enterprise EditionのユーザーID

- 25.4.1.3 Novell eDirectoryのユーザーID

- 25.4.1.4 Oracle Unified DirectoryのユーザーID

- 25.4.2 Oracle Unified Directoryでの統合の構成

- 25.4.2.1 Oracle Unified Directoryプロキシ・サーバーでのエンタープライズ・ユーザー・セキュリティの構成

- 25.4.2.2 インストール後の構成手順の実行

- 25.4.2.3 エンタープライズ・ユーザー・セキュリティに対応した、Oracle Unified Directoryプロキシ・サーバーの構成変更

- 25.4.2.4 Oracle Unified Directoryプロキシ・サーバーに対応した、Oracle Databaseの構成

第V部 高度な管理: データ・レプリケーション、スキーマ管理および環境間の移行

26 ディレクトリ・データのレプリケーション

- 26.1 dsreplicationによるデータ・レプリケーションの構成

- 26.1.1 2つのサーバー間のレプリケーションを有効にするには

- 26.1.1.1 レプリケーション・サーバーの作成場所の制御

- 26.1.2 レプリケート対象サーバーを初期化するには

- 26.1.3 トポロジ全体を初期化するには

- 26.1.4 レプリケーションをテストするには

- 26.1.5 レプリケート対象トポロジのステータスを取得するには

- 26.1.6 既存の2つのレプリケート対象トポロジをマージするには

- 26.1.7 特定のレプリケーション・ドメインに対してレプリケーションを無効にするには

- 26.1.7.1 レプリケーション・サーバーの無効化に関する注意

- 26.2 大規模なレプリケーション・トポロジの構成

- 26.2.1 専用レプリケーション・サーバーを構成するには

- 26.3 dsconfigによるレプリケーション構成の変更

- 26.3.1 レプリケーション・ドメイン名の取得

- 26.3.2 レプリケーション・パージ遅延の変更

- 26.3.2.1 レプリケーション変更記録のパージ動作

- 26.3.2.2 レプリケーション・パージ遅延を変更するには

- 26.3.3 ウィンドウ・サイズの変更

- 26.3.3.1 ウィンドウ・サイズを変更するには

- 26.3.4 初期化ウィンドウ・サイズの変更

- 26.3.4.1 初期化ウィンドウ・サイズを変更するには

- 26.3.5 ハートビート間隔の変更

- 26.3.5.1 ハートビート間隔を変更するには

- 26.3.6 分離ポリシーの変更

- 26.3.6.1 分離ポリシーを変更するには

- 26.3.7 暗号化レプリケーションの構成

- 26.3.8 レプリケーション・グループの構成

- 26.3.8.1 レプリケーション・グループを構成するには

- 26.3.9 保証レプリケーションの構成

- 26.3.9.1 安全データ・モードの保証レプリケーションを構成するには

- 26.3.9.2 安全読取りモードの保証レプリケーションを構成するには

- 26.3.10 部分レプリケーションの構成

- 26.3.10.1 排他部分レプリケーションを構成するには

- 26.3.10.2 包含部分レプリケーションを構成するには

- 26.3.10.3 部分ドメインを構成および初期化するには

- 26.3.11 レプリケーション・ステータスの構成

- 26.3.11.1 機能低下ステータスしきい値を構成するには

- 26.3.12 レプリケーション・サーバーの重みの構成

- 26.4 データによるレプリケート対象サーバーの初期化

- 26.4.1 単一のレプリケート対象サーバーの初期化

- 26.4.2 新しいレプリケート対象トポロジの初期化

- 26.4.3 既存のレプリケート対象トポロジへのディレクトリ・サーバーの追加

- 26.4.4 既存のレプリケート対象トポロジにあるデータ・セットの変更

- 26.4.4.1 import-ldifまたはバイナリ・コピーを使用してデータ・セットを変更するには

- 26.4.5 既存のレプリケート対象トポロジへのデータの追加

- 26.5 外部変更ログの使用

- 26.5.1 外部変更ログの有効化

- 26.5.2 外部変更ログのAPI

- 26.5.3 クライアント・アプリケーションがCookieモードで外部変更ログを使用する際の動作

- 26.5.4 外部変更ログ・エントリの形式

- 26.5.5 外部変更ログに含める属性の指定

- 26.5.6 外部変更ログから除外する属性の指定

- 26.5.7 外部変更ログを使用するクライアント・アプリケーションの初期化

- 26.5.7.1 外部変更ログを使用するクライアント・アプリケーションを初期化するには

- 26.5.7.2 ドメイン追加時のクライアント・アプリケーションの再初期化

- 26.5.7.3 ドメインの削除時または無効化時のクライアント・アプリケーションの再初期化

- 26.5.8 外部変更ログへのアクセスの制御

- 26.5.9 外部変更ログのパージ

- 26.5.10 サーバーでの外部変更ログの無効化

- 26.5.11 特定のドメインに対する外部変更ログの無効化

- 26.5.12 他の変更ログに依存するアプリケーションの移植

- 26.5.12.1 外部変更ログとLDAP変更ログ・ドラフトの相違点

- 26.5.12.2 外部変更ログとOracle Directory Server Enterprise Editionレトロ変更ログとのその他の相違点

- 26.5.12.3 LDAP変更ログ・ドラフトおよびOracle Directory Server Enterprise Editionレトロ変更ログとの互換性のためのAPI

- 26.6 スキーマのレプリケーションの構成

- 26.6.1 スキーマ・ソースの指定

- 26.6.2 スキーマのレプリケーションの無効化

- 26.6.2.1 スキーマをレプリケートしないように指定するには

- 26.6.2.2 スキーマのレプリケーションを無効にするには

- 26.7 読取り専用サーバーへのレプリケーション

- 26.7.1 レプリカの読取り専用としての構成

- 26.8 レプリケーションの非一貫性の検出および解決

- 26.8.1 レプリケーションの非一貫性の種類

- 26.8.2 非一貫性の検出

- 26.8.3 非一貫性の解決

- 26.8.4 名前の競合の解決

- 26.9 履歴レプリケーション・データのパージ

- 26.10 分離レプリカの使用

- 26.10.1 分離レプリカのデプロイメント・シナリオ

- 26.10.1.1 DMZでの分離レプリカの使用

- 26.10.1.2 分離レプリカを使用したテスト

- 26.11 Oracle Directory Server Enterprise EditionとOracle Unified Directory間のレプリケーション

- 26.11.1 Oracle Directory Server Enterprise Editionのスキーマおよび構成の移行

- 26.11.2 Oracle Directory Server Enterprise EditionとOracle Unified Directory間のレプリケーションを構成するには

- 26.11.3 Oracle Unified DirectoryをOracle Directory Server Enterprise Editionのデータで初期化するには

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

- 27.1 Oracle Unified Directoryスキーマの概要

- 27.1.1 スキーマの設計および拡張

- 27.1.2 デフォルト・スキーマ・ファイル

- 27.2 スキーマ・チェックの構成

- 27.3 オブジェクト識別子(OID)の使用

- 27.3.1 ベースOIDの取得

- 27.4 スキーマの拡張

- 27.4.1 属性タイプの管理

- 27.4.1.1 属性タイプを表示するには

- 27.4.1.2 属性タイプを作成するには

- 27.4.1.3 属性タイプを削除するには

- 27.4.2 オブジェクト・クラスの管理

- 27.4.2.1 オブジェクト・クラスを表示するには

- 27.4.2.2 オブジェクト・クラスを作成するには

- 27.4.2.3 オブジェクト・クラスを削除するには

- 27.5 スキーマのレプリケート

- 27.6 Oracle Directory Services Managerを使用したスキーマの管理

- 27.6.1 新規属性タイプの追加

- 27.6.2 既存の属性に基づく属性の追加

- 27.6.3 属性の変更

- 27.6.4 属性の削除

- 27.6.5 すべてのディレクトリ属性の表示

- 27.6.6 属性の検索

- 27.6.7 属性の索引付け詳細の表示

- 27.6.8 新規オブジェクト・クラスの追加

- 27.6.9 既存のオブジェクト・クラスに基づくオブジェクト・クラスの追加

- 27.6.10 オブジェクト・クラスのプロパティの表示

- 27.6.11 オブジェクト・クラスの変更

- 27.6.12 オブジェクト・クラスの削除

- 27.6.13 オブジェクト・クラスの検索

- 27.6.14 LDAP構文のリストの表示

- 27.6.15 構文の検索

- 27.6.16 LDAP一致ルールのリストの表示

- 27.6.17 一致ルールの検索

- 27.6.18 コンテンツ・ルールのリストの表示

- 27.6.19 コンテンツ・ルールの検索

- 27.6.20 新規コンテンツ・ルールの作成

- 27.6.21 既存のコンテンツ・ルールに基づくコンテンツ・ルールの作成

- 27.6.22 コンテンツ・ルールの変更

- 27.6.23 コンテンツ・ルールの削除

28 テスト環境から本番環境への移行

- 28.1 環境間の移動の概要

- 28.2 テストから本番への移行における制限

- 28.3 テストから本番へのプロセスの概要

- 28.3.1 バイナリの移動

- 28.3.2 構成の移動

- 28.3.2.1 構成のコピー

- 28.3.2.2 構成の編集

- 28.3.2.3 構成の貼付け

- 28.3.3 データの移動

第VI部 高度な管理: パフォーマンスの監視とチューニング

29 Oracle Unified Directoryの監視

- 29.1 監視の概要

- 29.2 監視プロバイダの構成

- 29.2.1 監視プロバイダを表示するには

- 29.2.2 監視プロバイダを無効にするには

- 29.3 ログの構成

- 29.3.1 dsconfigを使用したログの構成

- 29.3.1.1 ログ・パブリッシャの構成

- 29.3.1.2 ログ保存ポリシーの構成

- 29.3.1.3 ログ・ローテーション・ポリシーの構成

- 29.3.2 ODSMを使用したログの構成

- 29.3.2.1 ロガー・プロパティの変更

- 29.3.2.2 ログ・ローテーション・ポリシーの変更

- 29.3.2.3 ログ保存ポリシーの変更

- 29.3.3 アクセス・ログ・パブリッシャへの操作のロギング

- 29.3.3.1 管理ロガーの概要

- 29.3.3.2 ODSMを使用してアクセス・ログ・パブリッシャにログされた操作の構成

- 29.4 アラートおよびアカウント・ステータス通知ハンドラの構成

- 29.4.1 アラート・ハンドラの管理

- 29.4.1.1 dsconfigを使用したアラート・ハンドラの管理

- 29.4.1.2 ODSMを使用したアラート・ハンドラの管理

- 29.4.1.3 サポートされているアラート・タイプ

- 29.4.2 アカウント・ステータス通知ハンドラの管理

- 29.4.2.1 構成済のアカウント・ステータス通知ハンドラを表示するには

- 29.4.2.2 アカウント・ステータス通知ハンドラを有効にするには

- 29.4.2.3 新規アカウント・ステータス通知ハンドラを作成するには

- 29.4.2.4 アカウント・ステータス通知ハンドラを削除するには

- 29.5 LDAPを使用したサーバーの監視

- 29.5.1 cn=monitorエントリを使用した監視情報の表示

- 29.5.1.1 プロキシの監視される属性

- 29.5.1.2 使用可能な監視情報を表示するには

- 29.5.1.3 汎用サーバー情報を監視するには

- 29.5.1.4 システム情報を監視するには

- 29.5.1.5 バージョン情報を監視するには

- 29.5.1.6 ユーザー・ルート・バックエンドを監視するには

- 29.5.1.7 バックアップ・バックエンドを監視するには

- 29.5.1.8 タスク・バックエンドを監視するには

- 29.5.1.9 monitorバックエンドを監視するには

- 29.5.1.10 スキーマ・バックエンドを監視するには

- 29.5.1.11 adminRootバックエンドを監視するには

- 29.5.1.12 ads-truststoreバックエンドを監視するには

- 29.5.1.13 クライアント接続を監視するには

- 29.5.1.14 LDAP接続ハンドラを監視するには

- 29.5.1.15 LDAP接続ハンドラの統計を監視するには

- 29.5.1.16 LDAP接続ハンドラの接続を監視するには

- 29.5.1.17 管理コネクタを監視するには

- 29.5.1.18 管理コネクタ統計を監視するには

- 29.5.1.19 管理コネクタの接続を監視するには

- 29.5.1.20 LDIF接続ハンドラを監視するには

- 29.5.1.21 ワーク・キューを監視するには

- 29.5.1.22 JVMスタック・トレース情報を監視するには

- 29.5.1.23 JVMメモリー使用量を監視するには

- 29.5.1.24 userRootデータベース環境を監視するには

- 29.5.1.25 データベース・キャッシュを監視するには

- 29.5.1.26 エントリ・キャッシュを監視するには

- 29.5.1.27 ネットワーク・グループを監視するには

- 29.5.1.28 分散を監視するには

- 29.5.1.29 ロード・バランシングを監視するには

- 29.5.1.30 リモートLDAPサーバーを監視するには

- 29.5.1.31 グローバル索引を監視するには

- 29.5.1.32 グローバル索引カタログを監視するには

- 29.5.2 manage-tasksコマンドを使用した監視

- 29.5.3 JConsoleを使用したサーバーの監視

- 29.5.3.1 サーバー・インスタンス上でJMXを構成するには

- 29.5.3.2 JConsoleの起動

- 29.5.3.3 JConsoleからのサーバー・インスタンスへのアクセス

- 29.5.3.4 JConsoleを使用した監視情報の表示

- 29.5.4 ログへのアクセス

- 29.5.4.1 アクセス・ログを表示するには

- 29.5.4.2 監査ログを表示するには

- 29.5.4.3 デバッグ・ログを表示するには

- 29.5.4.4 エラー・ログを表示するには

- 29.5.4.5 レプリケーション修復ログを表示するには

- 29.5.4.6 server.outログを表示するには

- 29.5.4.7 設定ログを表示するには

- 29.6 SNMPを使用したサーバーの監視

- 29.6.1 SNMP接続ハンドラおよびその依存性の構成

- 29.6.1.1 サーバーのSNMPを構成するには

- 29.6.1.2 SNMP接続ハンドラのプロパティを表示するには

- 29.6.1.3 サーバー・インスタンス上でSNMPにアクセスするには

- 29.6.1.4 SNMPセキュリティ構成

- 29.7 レプリケートされたトポロジの監視

- 29.7.1 dsreplicationを使用したレプリケーション・ステータスの監視

- 29.7.2 詳細レプリケーション監視

- 29.7.2.1 トポロジおよびその接続を監視するには

- 29.7.2.2 レプリケーション待機時間を監視するには

- 29.7.2.3 データの一貫性を監視するには

- 29.7.2.4 レプリケーションのセキュリティを監視するには

- 29.7.2.5 レプリケートされた更新を監視するには

- 29.7.2.6 レプリケーションの競合を監視するには

- 29.8 汎用のエンタープライズの監視のソリューション

- 29.8.1 汎用のUNIX監視ツール

- 29.8.2 Solarisの監視ツール

- 29.8.3 HP-UXの監視ツール

30 パフォーマンスのチューニング

- 30.1 パフォーマンスの問題の評価

- 30.2 一般的なパフォーマンス・チューニング

- 30.3 Java仮想マシン設定のチューニング

- 30.4 データベース・キャッシュ・サイズの決定

- 30.5 サーバー構成のチューニング

- 30.5.1 バックエンドのチューニング・パラメータ

- 30.5.2 コア・サーバーのチューニング・パラメータ

- 30.5.3 追加のチューニング推奨事項

A Oracle Unified Directoryコマンドライン・インタフェース

- A.1 一般的なコマンドラインの使用方法に関する情報

- A.1.1 サーバー・コマンドとその使用のサマリー

- A.1.2 サーバー・コマンドによるプロパティ・ファイルの使用方法

- A.1.2.1 プロパティ・ファイルの検索

- A.1.2.2 オプションおよびプロパティの優先順位

- A.2 サーバー管理コマンド

- A.2.1 create-rc-script

- A.2.1.1 シノプシス

- A.2.1.2 説明

- A.2.1.3 オプション

- A.2.1.4 一般オプション

- A.2.1.5 例

- A.2.1.6 create-rc-scriptコマンドにより生成されるコード

- A.2.1.7 終了コード

- A.2.1.8 場所

- A.2.1.9 関連コマンド

- A.2.2 dps2oud

- A.2.2.1 シノプシス

- A.2.2.2 説明

- A.2.2.3 オプション

- A.2.2.4 LDAP接続オプション

- A.2.2.5 一般オプション

- A.2.2.6 例

- A.2.2.7 終了コード

- A.2.2.8 場所

- A.2.2.9 関連コマンド

- A.2.3 ds2oud

- A.2.3.1 シノプシス

- A.2.3.2 説明

- A.2.3.3 オプション

- A.2.3.4 Oracle Directory Server Enterprise EditionのLDAP接続オプション

- A.2.3.5 Oracle Unified DirectoryのLDAP接続オプション

- A.2.3.6 コマンド入力/出力オプション

- A.2.3.7 一般オプション

- A.2.3.8 例

- A.2.3.9 終了コード

- A.2.3.10 場所

- A.2.3.11 関連コマンド

- A.2.4 dsconfig

- A.2.4.1 シノプシス

- A.2.4.2 説明

- A.2.4.3 ヘルプ・サブコマンド

- A.2.4.4 一般サブコマンド

- A.2.4.5 分散サブコマンド

- A.2.4.6 一般構成サブコマンド

- A.2.4.7 ロード・バランシング・サブコマンド

- A.2.4.8 ローカル記憶域サブコマンド

- A.2.4.9 その他のワークフロー要素サブコマンド

- A.2.4.10 リモート記憶域サブコマンド

- A.2.4.11 レプリケーション・サブコマンド

- A.2.4.12 スキーマ・サブコマンド

- A.2.4.13 セキュリティ・サブコマンド

- A.2.4.14 仮想化サブコマンド

- A.2.4.15 オプション

- A.2.4.16 LDAP接続オプション

- A.2.4.17 コマンド入力/出力オプション

- A.2.4.18 一般オプション

- A.2.4.19 例

- A.2.4.20 終了コード

- A.2.4.21 プロパティ・ファイルの使用方法

- A.2.4.22 場所

- A.2.4.23 関連コマンド

- A.2.5 dsjavaproperties

- A.2.5.1 シノプシス

- A.2.5.2 説明

- A.2.5.3 オプション

- A.2.5.4 例

- A.2.5.5 終了コード

- A.2.5.6 場所

- A.2.6 dsreplication

- A.2.6.1 シノプシス

- A.2.6.2 説明

- A.2.6.3 サーバー・サブコマンド

- A.2.6.4 オプション

- A.2.6.5 構成オプション

- A.2.6.6 LDAP接続オプション

- A.2.6.7 コマンド入力/出力オプション

- A.2.6.8 一般オプション

- A.2.6.9 例

- A.2.6.10 終了コード

- A.2.6.11 プロパティ・ファイルの使用方法

- A.2.6.12 場所

- A.2.6.13 関連コマンド

- A.2.7 gicadm

- A.2.7.1 シノプシス

- A.2.7.2 説明

- A.2.7.3 オプション

- A.2.7.4 LDAP接続オプション

- A.2.7.5 コマンド入力/出力オプション

- A.2.7.6 一般オプション

- A.2.7.7 例

- A.2.7.8 終了コード

- A.2.7.9 場所

- A.2.7.10 関連コマンド

- A.2.8 manage-tasks

- A.2.8.1 シノプシス

- A.2.8.2 説明

- A.2.8.3 オプション

- A.2.8.4 LDAP接続オプション

- A.2.8.5 コマンド入力/出力オプション

- A.2.8.6 一般オプション

- A.2.8.7 例

- A.2.8.8 終了コード

- A.2.8.9 プロパティ・ファイルの使用方法

- A.2.8.10 場所

- A.2.8.11 関連コマンド

- A.2.9 oudCopyConfig

- A.2.9.1 シノプシス

- A.2.9.2 説明

- A.2.9.3 オプション

- A.2.9.4 例

- A.2.9.5 場所

- A.2.9.6 関連コマンド

- A.2.10 oudExtractMovePlan

- A.2.10.1 シノプシス

- A.2.10.2 説明

- A.2.10.3 オプション

- A.2.10.4 例

- A.2.10.5 場所

- A.2.10.6 関連コマンド

- A.2.11 oudPasteConfig

- A.2.11.1 シノプシス

- A.2.11.2 説明

- A.2.11.3 オプション

- A.2.11.4 例

- A.2.11.5 場所

- A.2.11.6 関連コマンド

- A.2.12 oud-replication-gateway-setup

- A.2.12.1 シノプシス

- A.2.12.2 説明

- A.2.12.3 オプション

- A.2.12.4 レプリケーション・ゲートウェイの構成オプション

- A.2.12.5 Oracle Directory Server Enterprise Editionサーバー・オプション

- A.2.12.6 レプリケーション・ゲートウェイのセキュリティ・オプション

- A.2.12.7 Oracle Unified Directoryサーバー・オプション

- A.2.12.8 セキュアな接続のオプション

- A.2.12.9 コマンド入力/出力オプション

- A.2.12.10 一般オプション

- A.2.12.11 例

- A.2.12.12 終了コード

- A.2.12.13 プロパティ・ファイルの使用方法

- A.2.12.14 ログ・ファイル

- A.2.12.15 場所

- A.2.12.16 関連コマンド

- A.2.13 oud-setup

- A.2.13.1 シノプシス

- A.2.13.2 説明

- A.2.13.3 オプション

- A.2.13.4 コマンド入力/出力オプション

- A.2.13.5 一般オプション

- A.2.13.6 例

- A.2.13.7 終了コード

- A.2.13.8 プロパティ・ファイルの使用方法

- A.2.13.9 ログ・ファイル

- A.2.13.10 場所

- A.2.13.11 関連コマンド

- A.2.14 oud-proxy-setup

- A.2.14.1 シノプシス

- A.2.14.2 説明

- A.2.14.3 オプション

- A.2.14.4 コマンド入力/出力オプション

- A.2.14.5 一般オプション

- A.2.14.6 例

- A.2.14.7 終了コード

- A.2.14.8 ログ・ファイル

- A.2.14.9 場所

- A.2.14.10 関連コマンド

- A.2.15 start-ds

- A.2.15.1 シノプシス

- A.2.15.2 説明

- A.2.15.3 オプション

- A.2.15.4 コマンド入力/出力オプション

- A.2.15.5 一般オプション

- A.2.15.6 例

- A.2.15.7 終了コード

- A.2.15.8 場所

- A.2.15.9 関連コマンド

- A.2.16 status

- A.2.16.1 シノプシス

- A.2.16.2 説明

- A.2.16.3 LDAP接続オプション

- A.2.16.4 コマンド入力/出力オプション

- A.2.16.5 一般オプション

- A.2.16.6 例

- A.2.16.7 終了コード

- A.2.16.8 プロパティ・ファイルの使用方法

- A.2.16.9 場所

- A.2.17 stop-ds

- A.2.17.1 シノプシス

- A.2.17.2 説明

- A.2.17.3 オプション

- A.2.17.4 LDAP接続オプション

- A.2.17.5 コマンド入力/出力オプション

- A.2.17.6 一般オプション

- A.2.17.7 例

- A.2.17.8 終了コード

- A.2.17.9 プロパティ・ファイルの使用方法

- A.2.17.10 場所

- A.2.17.11 関連コマンド

- A.2.18 uninstall

- A.2.18.1 シノプシス

- A.2.18.2 説明

- A.2.18.3 ディレクトリ・サーバーの削除

- A.2.18.4 プロキシ・サーバーの削除

- A.2.18.5 レプリケーション・ゲートウェイ・サーバーの削除

- A.2.18.6 コマンド入力/出力オプション

- A.2.18.7 一般オプション

- A.2.18.8 例

- A.2.18.9 終了コード

- A.2.18.10 プロパティ・ファイルの使用方法

- A.2.18.11 ログ・ファイル

- A.2.18.12 場所

- A.2.18.13 関連コマンド

- A.2.19 windows-service

- A.2.19.1 シノプシス

- A.2.19.2 説明

- A.2.19.3 コマンドのオプション

- A.2.19.4 一般オプション

- A.2.19.5 例

- A.2.19.6 終了コード

- A.2.19.7 場所

- A.2.19.8 関連コマンド

- A.3 データ管理コマンド

- A.3.1 backup

- A.3.1.1 シノプシス

- A.3.1.2 説明

- A.3.1.3 オプション

- A.3.1.4 タスク・バックエンド接続オプション

- A.3.1.5 タスク・スケジュール・オプション

- A.3.1.6 コマンド入力/出力オプション

- A.3.1.7 一般オプション

- A.3.1.8 例

- A.3.1.9 終了コード

- A.3.1.10 プロパティ・ファイルの使用方法

- A.3.1.11 場所

- A.3.1.12 関連コマンド

- A.3.2 base64

- A.3.2.1 シノプシス

- A.3.2.2 説明

- A.3.2.3 サブコマンド

- A.3.2.4 グローバル・オプション

- A.3.2.5 例

- A.3.2.6 終了コード

- A.3.2.7 場所

- A.3.3 dbtest

- A.3.3.1 シノプシス

- A.3.3.2 説明

- A.3.3.3 サブコマンド

- A.3.3.4 グローバル・オプション

- A.3.3.5 例

- A.3.3.6 終了コード

- A.3.3.7 場所

- A.3.3.8 関連コマンド

- A.3.4 encode-password

- A.3.4.1 シノプシス

- A.3.4.2 説明

- A.3.4.3 オプション

- A.3.4.4 例

- A.3.4.5 終了コード

- A.3.4.6 場所

- A.3.5 export-ldif

- A.3.5.1 シノプシス

- A.3.5.2 説明

- A.3.5.3 オプション

- A.3.5.4 タスク・バックエンド接続オプション

- A.3.5.5 タスク・スケジュール・オプション

- A.3.5.6 コマンド入力/出力オプション

- A.3.5.7 一般オプション

- A.3.5.8 例

- A.3.5.9 終了コード

- A.3.5.10 プロパティ・ファイルの使用方法

- A.3.5.11 場所

- A.3.5.12 関連コマンド

- A.3.6 import-ldif

- A.3.6.1 シノプシス

- A.3.6.2 説明

- A.3.6.3 オプション

- A.3.6.4 タスク・バックエンド接続オプション

- A.3.6.5 タスク・スケジュール・オプション

- A.3.6.6 コマンド入力/出力オプション

- A.3.6.7 一般オプション

- A.3.6.8 例

- A.3.6.9 終了コード

- A.3.6.10 プロパティ・ファイルの使用方法

- A.3.6.11 場所

- A.3.6.12 関連コマンド

- A.3.7 ldif-diff

- A.3.7.1 シノプシス

- A.3.7.2 説明

- A.3.7.3 オプション

- A.3.7.4 例

- A.3.7.5 終了コード

- A.3.7.6 場所

- A.3.7.7 関連コマンド

- A.3.8 ldifmodify

- A.3.8.1 シノプシス

- A.3.8.2 説明

- A.3.8.3 オプション

- A.3.8.4 例

- A.3.8.5 終了コード

- A.3.8.6 場所

- A.3.8.7 関連コマンド

- A.3.9 ldifsearch

- A.3.9.1 シノプシス

- A.3.9.2 説明

- A.3.9.3 オプション

- A.3.9.4 例

- A.3.9.5 終了コード

- A.3.9.6 場所

- A.3.9.7 関連コマンド

- A.3.10 list-backends

- A.3.10.1 シノプシス

- A.3.10.2 説明

- A.3.10.3 オプション

- A.3.10.4 コマンドのオプション

- A.3.10.5 一般オプション

- A.3.10.6 例

- A.3.10.7 終了コード

- A.3.10.8 場所

- A.3.11 make-ldif

- A.3.11.1 シノプシス

- A.3.11.2 説明

- A.3.11.3 オプション

- A.3.11.4 例

- A.3.11.5 終了コード

- A.3.11.6 場所

- A.3.11.7 関連コマンド

- A.3.12 manage-account

- A.3.12.1 シノプシス

- A.3.12.2 説明

- A.3.12.3 サブコマンド

- A.3.12.4 オプション

- A.3.12.5 LDAP接続オプション

- A.3.12.6 一般オプション

- A.3.12.7 例

- A.3.12.8 終了コード

- A.3.12.9 場所

- A.3.12.10 関連コマンド

- A.3.13 rebuild-index

- A.3.13.1 シノプシス

- A.3.13.2 説明

- A.3.13.3 オプション

- A.3.13.4 コマンドのオプション

- A.3.13.5 タスク・バックエンド接続オプション

- A.3.13.6 タスク・スケジュール・オプション

- A.3.13.7 ユーティリティ入力/出力オプション

- A.3.13.8 一般オプション

- A.3.13.9 例

- A.3.13.10 終了コード

- A.3.13.11 場所

- A.3.13.12 関連コマンド

- A.3.14 restore

- A.3.14.1 シノプシス

- A.3.14.2 説明

- A.3.14.3 オプション

- A.3.14.4 タスク・バックエンド接続オプション

- A.3.14.5 タスク・スケジュール・オプション

- A.3.14.6 コマンド入力/出力オプション

- A.3.14.7 一般オプション

- A.3.14.8 例

- A.3.14.9 終了コード

- A.3.14.10 プロパティ・ファイルの使用方法

- A.3.14.11 場所

- A.3.14.12 関連コマンド

- A.3.15 split-ldif

- A.3.15.1 シノプシス

- A.3.15.2 説明

- A.3.15.3 オプション

- A.3.15.4 グローバル索引オプション

- A.3.15.5 分割オプション

- A.3.15.6 一般オプション

- A.3.15.7 例

- A.3.15.8 場所

- A.3.15.9 関連コマンド

- A.3.16 verify-index

- A.3.16.1 シノプシス

- A.3.16.2 説明

- A.3.16.3 オプション

- A.3.16.4 コマンドのオプション

- A.3.16.5 一般オプション

- A.3.16.6 例

- A.3.16.7 終了コード

- A.3.16.8 場所

- A.3.16.9 関連コマンド

- A.4 LDAPクライアントのコマンド

- A.4.1 ldapcompare

- A.4.1.1 シノプシス

- A.4.1.2 説明

- A.4.1.3 オプション

- A.4.1.4 コマンドのオプション

- A.4.1.5 LDAP接続オプション

- A.4.1.6 コマンド入力/出力オプション

- A.4.1.7 一般オプション

- A.4.1.8 例

- A.4.1.9 終了コード

- A.4.1.10 CLIプロパティ・ファイルの使用方法

- A.4.1.11 場所

- A.4.1.12 関連コマンド

- A.4.2 ldapdelete

- A.4.2.1 シノプシス

- A.4.2.2 説明

- A.4.2.3 始める前に

- A.4.2.4 オプション

- A.4.2.5 コマンドのオプション

- A.4.2.6 LDAP接続オプション

- A.4.2.7 コマンド入力/出力オプション

- A.4.2.8 一般オプション

- A.4.2.9 例

- A.4.2.10 終了コード

- A.4.2.11 CLIプロパティ・ファイルの使用方法

- A.4.2.12 場所

- A.4.2.13 関連コマンド

- A.4.3 ldapmodify

- A.4.3.1 シノプシス

- A.4.3.2 説明

- A.4.3.3 始める前に

- A.4.3.4 オプション

- A.4.3.5 コマンドのオプション

- A.4.3.6 LDAP接続オプション

- A.4.3.7 コマンド入力/出力オプション

- A.4.3.8 一般オプション

- A.4.3.9 例

- A.4.3.10 終了コード

- A.4.3.11 CLIプロパティ・ファイルの使用方法

- A.4.3.12 場所

- A.4.3.13 関連コマンド

- A.4.4 ldappasswordmodify

- A.4.4.1 シノプシス

- A.4.4.2 説明

- A.4.4.3 オプション

- A.4.4.4 コマンドのオプション

- A.4.4.5 LDAP接続オプション

- A.4.4.6 コマンド入力/出力オプション

- A.4.4.7 一般オプション

- A.4.4.8 例

- A.4.4.9 終了コード

- A.4.4.10 CLIプロパティ・ファイルの使用方法

- A.4.4.11 場所

- A.4.4.12 関連コマンド

- A.4.5 ldapsearch

- A.4.5.1 シノプシス

- A.4.5.2 説明

- A.4.5.3 始める前に

- A.4.5.4 オプション

- A.4.5.5 コマンドのオプション

- A.4.5.6 LDAP接続オプション

- A.4.5.7 コマンド入力/出力オプション

- A.4.5.8 一般オプション

- A.4.5.9 例

- A.4.5.10 プロパティ・ファイルを使用して検索するには

- A.4.5.11 検索属性

- A.4.5.12 終了コード

- A.4.5.13 場所

- A.4.5.14 関連コマンド

B サポートされている制御および操作

- B.1 サポートされているLDAP制御

- B.2 サポートされている拡張操作

C Oracle Unified Directoryがサポートしている規格および仕様

- C.1 Oracle Unified DirectoryがサポートしているRFC

- C.2 Oracle Unified Directoryがサポートしているインターネット・ドラフト

- C.3 Oracle Unified Directoryがサポートしているその他の仕様

D Oracle Unified Directory用語集

- D.1 A

- D.1.1 中止操作

- D.1.2 抽象オブジェクト・クラス

- D.1.3 抽象構文表記法1

- D.1.4 アクセス制御

- D.1.5 アクセス制御命令(ACI)

- D.1.6 アクセス制御ルール

- D.1.7 アクセス・ログ

- D.1.8 アカウント有効期限

- D.1.9 アカウント・ロックアウト

- D.1.10 アカウント・ステータス通知

- D.1.11 アカウント・ユーザビリティ制御

- D.1.12 ACID

- D.1.13 追加操作

- D.1.14 別名

- D.1.15 AND検索フィルタ

- D.1.16 匿名バインド

- D.1.17 ANONYMOUS SASLメカニズム

- D.1.18 近似索引

- D.1.19 近似検索フィルタ

- D.1.20 ASN.1

- D.1.21 アサーション値

- D.1.22 属性

- D.1.23 属性説明

- D.1.24 属性オプション

- D.1.25 属性構文

- D.1.26 属性タイプ

- D.1.27 属性使用方法

- D.1.28 属性値

- D.1.29 属性値アサーション

- D.1.30 監査ログ

- D.1.31 認証

- D.1.32 認証ID

- D.1.33 認証パスワード構文

- D.1.34 認可

- D.1.35 認可ID

- D.1.36 認可アイデンティティ制御

- D.1.37 補助オブジェクト・クラス

- D.1.38 AVA

- D.2 B

- D.2.1 バックエンド

- D.2.2 バックアップ

- D.2.3 base64エンコーディング

- D.2.4 基本エンコーディング・ルール

- D.2.4.1 基本エンコーディング・ルールの概要

- D.2.4.2 BERタイプ

- D.2.4.3 BERの長さ

- D.2.4.4 BERの値

- D.2.4.5 BERエンコーディングの例

- D.2.5 BER

- D.2.6 Berkeley DB Java Edition

- D.2.7 バイナリ・コピー

- D.2.8 バインド操作

- D.3 C

- D.3.1 取消し拡張操作

- D.3.2 CDDL

- D.3.3 証明書

- D.3.4 証明書マッパー

- D.3.5 チェーン

- D.3.6 変更ログ

- D.3.7 cn=Directory Manager

- D.3.8 集合属性

- D.3.9 Common Development and Distribution License

- D.3.10 比較操作

- D.3.11 接続ハンドラ

- D.3.12 接続ID

- D.3.13 制御

- D.3.14 CRAM-MD5 SASLメカニズム

- D.3.15 暗号化アルゴリズム

- D.4 D

- D.4.1 データベース

- D.4.2 データベース・キャッシュ

- D.4.3 デバッグ・ログ

- D.4.4 削除操作

- D.4.5 非推奨パスワード記憶スキーム

- D.4.6 間接参照ポリシー

- D.4.7 DIGEST-MD5 SASLメカニズム

- D.4.8 ディレクトリ情報ツリー

- D.4.9 directory manager

- D.4.10 ディレクトリ・サーバー

- D.4.11 ディレクトリ・サーバー・エージェント

- D.4.12 Directory Services Markup Language

- D.4.13 識別名

- D.4.14 分散

- D.4.15 DIT

- D.4.16 DITコンテンツ・ルール

- D.4.17 DIT構造ルール

- D.4.18 DN

- D.4.19 DSA

- D.4.20 DSA固有のエントリ

- D.4.21 DSE

- D.4.22 DSML

- D.4.23 DSMLゲートウェイ

- D.4.24 期間

- D.4.25 動的グループ

- D.5 E

- D.5.1 エントリ

- D.5.2 エントリ・キャッシュ

- D.5.3 エントリ変更通知制御

- D.5.4 エントリDN

- D.5.5 エントリID

- D.5.6 エントリUUID

- D.5.7 等価索引

- D.5.8 等価検索フィルタ

- D.5.9 エラー・ログ

- D.5.10 エクスポート

- D.5.11 拡張操作

- D.5.12 拡張可能な一致索引

- D.5.13 拡張可能な一致検索フィルタ

- D.5.14 EXTERNAL SASLメカニズム

- D.6 F

- D.6.1 フェイルオーバー・アルゴリズム

- D.6.2 falseフィルタ

- D.7 G

- D.7.1 一般的な時刻

- D.7.2 実効権限取得制御

- D.7.3 グローバル索引

- D.7.4 グローバル索引カタログ

- D.7.5 大きいか等しい検索フィルタ

- D.7.6 グループ

- D.7.7 GSSAPI SASLメカニズム

- D.8 I

- D.8.1 IDリスト

- D.8.2 id2entryデータベース

- D.8.3 アイデンティティ・マッパー

- D.8.4 アイドル・アカウント・ロックアウト

- D.8.5 インコア再起動

- D.8.6 索引

- D.8.7 索引エントリ制限

- D.8.8 中間レスポンス

- D.8.9 Internet Draft

- D.9 J

- D.9.1 Java Management Extensions

- D.9.2 JMX

- D.10 K

- D.10.1 キー・マネージャ・プロバイダ

- D.11 L

- D.11.1 最終ログイン時刻

- D.11.2 最終変更プラグイン

- D.11.3 LDAPアサーション制御

- D.11.4 ldapcompareコマンド

- D.11.5 LDAPデータ変換形式

- D.11.6 ldapdeleteコマンド

- D.11.7 LDAP falseフィルタ

- D.11.8 LDAP中間レスポンス

- D.11.9 LDAPメッセージ

- D.11.10 LDAP DN変更操作

- D.11.11 LDAP変更操作

- D.11.12 ldapmodifyコマンド

- D.11.13 LDAP no-op制御

- D.11.14 LDAP読込み後制御

- D.11.15 LDAP読込み前制御

- D.11.16 LDAP結果

- D.11.17 LDAPS

- D.11.18 LDAP検索フィルタ

- D.11.19 ldapsearchコマンド

- D.11.20 LDAP trueフィルタ

- D.11.21 LDAPサブエントリ

- D.11.22 LDAP URL

- D.11.23 LDIFエクスポート

- D.11.24 LDIFインポート

- D.11.25 リーフ・エントリ

- D.11.26 小さいか等しい検索フィルタ

- D.11.27 辞書編集アルゴリズム

- D.11.28 Lightweight Directory Access Protocol

- D.11.29 ロード・バランシング

- D.11.30 検索制限

- D.12 M

- D.12.1 MakeLDIFコマンド

- D.12.2 ManageDSAIT制御

- D.12.3 一致したDN

- D.12.4 一致値制御

- D.12.5 一致ルール

- D.12.6 一致ルールの使用

- D.12.7 MD5

- D.12.8 メッセージ

- D.12.9 メッセージID

- D.12.10 変更

- D.12.11 変更タイプ

- D.12.12 DN変更操作

- D.12.13 変更操作

- D.12.14 監視エントリ

- D.13 N

- D.13.1 名前書式

- D.13.2 ネーミング・コンテキスト

- D.13.3 ネットワーク・グループ

- D.13.4 リーフ以外のエントリ

- D.13.5 正規化された値

- D.13.6 切断の通知未承諾通知

- D.13.7 NOT検索フィルタ

- D.13.8 数値アルゴリズム

- D.13.9 nsuniqueid

- D.14 O

- D.14.1 オブジェクト・クラス

- D.14.2 オブジェクト・クラス・タイプ

- D.14.3 オブジェクト識別子

- D.14.4 操作ID

- D.14.5 操作属性

- D.14.6 順序付け索引

- D.14.7 OR検索フィルタ

- D.15 P

- D.15.1 パーティション

- D.15.2 パスワード

- D.15.3 パスワード有効期限

- D.15.4 パスワード・ジェネレータ

- D.15.5 パスワード変更拡張操作

- D.15.6 パスワード・ポリシー

- D.15.7 パスワード・ポリシー制御

- D.15.8 パスワードのリセット

- D.15.9 パスワード記憶スキーム

- D.15.10 パスワード・バリデータ

- D.15.11 永続検索制御

- D.15.12 PLAIN SASLメカニズム

- D.15.13 プラグイン

- D.15.14 プレゼンス索引

- D.15.15 プレゼンス検索フィルタ

- D.15.16 特権

- D.15.17 比例アルゴリズム

- D.15.18 プロトコル・データ・ユニット

- D.15.19 プロトコルop

- D.15.20 プロキシ認可制御

- D.16 Q

- D.16.1 保護品質

- D.17 R

- D.17.1 実在属性専用制御

- D.17.2 参照整合性

- D.17.3 リフェラル

- D.17.4 相対識別名

- D.17.5 レプリカ

- D.17.6 レプリケーション

- D.17.7 レプリケーション修復制御

- D.17.8 request for comments

- D.17.9 復元

- D.17.10 結果

- D.17.11 結果コード

- D.17.12 ルートDN

- D.17.13 ルートDSE

- D.17.14 ルート

- D.18 S

- D.18.1 salt

- D.18.2 飽和アルゴリズム

- D.18.3 飽和アラート

- D.18.4 飽和しきい値

- D.18.5 スキーマ

- D.18.6 スキーマ検査

- D.18.7 検索属性

- D.18.8 検索ベースDN

- D.18.9 検索フィルタ

- D.18.10 検索操作

- D.18.11 検索結果終了

- D.18.12 検索結果エントリ

- D.18.13 検索結果参照

- D.18.14 検索範囲

- D.18.15 セキュア・ハッシュ・アルゴリズム

- D.18.16 Secure Sockets Layer

- D.18.17 サーバー側ソート制御

- D.18.18 簡易認証

- D.18.19 Simple Authentication and Security Layer

- D.18.20 単純なページングの結果制御

- D.18.21 サイズ制限

- D.18.22 スマート・リフェラル

- D.18.23 TLS起動拡張操作

- D.18.24 静的グループ

- D.18.25 構造オブジェクト・クラス

- D.18.26 サブエントリ

- D.18.27 サブスキーマ・サブエントリ

- D.18.28 部分文字列アサーション

- D.18.29 部分文字列索引

- D.18.30 部分文字列検索フィルタ

- D.18.31 サブツリー

- D.18.32 サブツリー削除制御

- D.18.33 サポートされている制御

- D.18.34 サポートされている拡張

- D.18.35 サポートされている機能

- D.18.36 同期

- D.19 T

- D.19.1 タスク

- D.19.2 時間制限

- D.19.3 トランザクション

- D.19.4 Transport Security Layer

- D.19.5 trueフィルタ

- D.19.6 信頼マネージャ・プロバイダ

- D.19.7 typesOnlyフラグ

- D.20 U

- D.20.1 アンバインド操作

- D.20.2 索引なし検索

- D.20.3 UNIX暗号化アルゴリズム

- D.20.4 未承諾通知

- D.20.5 URL

- D.20.6 user attribute

- D.21 V

- D.21.1 仮想属性

- D.21.2 仮想属性専用制御

- D.21.3 仮想ディレクトリ

- D.21.4 仮想一覧表示

- D.21.5 仮想静的グループ

- D.21.6 VLV索引

- D.22 W

- D.22.1 Who Am I拡張操作

- D.22.2 ワーク・キュー

- D.22.3 ワーカー・スレッド

- D.22.4 ワークフロー

- D.22.5 ワークフロー要素

- D.22.6 書込み可能モード

例一覧

- 4-1 ネットワーク・グループの条件を使用した異なるワークフローへのルーティング

- 4-2 ネットワーク・グループのQoSポリシーを使用したリクエストのフィルタリング

- 4-3 1つのネットワーク・グループから複数のワークフローへのルーティング

- 6-1 セーフ・データ・レベルが1の場合

- 6-2 セーフ・データ・レベルが2の場合(RSとDSが異なるホスト上に存在)

- 6-3 セーフ・データ・レベルが2の場合(RSとDSが同じホスト上に存在)

- 6-4 1つのグループが存在する単一データ・センター内のセーフ読取りモード

- 6-5 複数のグループが存在する単一データ・センター内のセーフ読取りモード

- 6-6 マルチデータ・センター・デプロイメント内のセーフ読取りモード

- 11-1 数値分散アルゴリズムを使用した検索例

- 11-2 辞書編集分散アルゴリズムを使用した検索例

- 11-3 地域別分割DNパターン・アルゴリズムの例

- 11-4 電話番号のグローバル索引カタログの使用

- 15-1 クライアント接続アフィニティが拒否される場合の例

- 15-2 レプリケート・トポロジでグローバル索引カタログを再起動するには

- 15-3 レプリケートされたグローバル索引カタログ・トポロジへのグローバル索引の追加

- 15-4 レプリケートされたグローバル索引カタログのコンテンツの上書き

- 15-5 レプリケート・トポロジへのプロキシの追加

- 17-1 等価検索

- 17-2 より小さい検索

- 17-3 以下検索

- 17-4 以上検索

- 17-5 より大きい検索

- 17-6 部分文字列検索

- 17-7 新しい等価索引の作成

- 17-8 部分文字列索引の追加

- 17-9 新しいVLV索引の作成

- 20-1 編集後のKerberosクライアント構成ファイル/etc/krb5/krb5.conf

- 20-2 編集後の管理サーバーACL構成ファイル

- 20-3 編集後のKDCサーバー構成ファイル/etc/krb5/kdc.conf

- 20-4 新しいtestuser.ldifファイル

- 24-1 アカウント・ロックアウトの構成

- 24-2 最終ログインの構成

- 24-3 パスワード履歴数および履歴期間の構成

- A-1 スクリプトの作成

- A-2 新規スクリプトを使用したディレクトリ・サーバーの起動

- A-3 新規スクリプトを使用したディレクトリ・サーバーの停止

- A-4 新規スクリプトを使用したディレクトリ・サーバーの再起動

- A-5 スクリプトでのJAVA_HOMEおよびJAVA_ARGSの指定

- A-6 グローバル・ヘルプ・サブコマンドの表示

- A-7 ディレクトリ・プロキシ・サーバー構成のOracle Unified Directory構成への移行

- A-8 グローバル・ヘルプ・サブコマンドの表示

- A-9 コマンドラインからのインタラクティブ・モードでのds2oudの実行

- A-10 データ診断用のds2oudの実行

- A-11 既存のOracle Directory Server Enterprise Edition構成のOracle Unified Directory構成への移行

- A-12 グローバル・ヘルプ・サブコマンドとグローバル・オプションの表示

- A-13 コンポーネントのサブコマンドとヘルプ情報の表示

- A-14 個別サブコマンドのヘルプの表示

- A-15 コンポーネントのプロパティの表示

- A-16 -F, --batchFilePathサブコマンドでサポートされるパラメータ

- A-17 sortMenuItemオプションを使用したロケール別の情報表示

- A-18 スクリプトの変更

- A-19 ディレクトリ・サーバー・レプリケーションの有効化

- A-20 ディレクトリ・サーバー・レプリケーションの初期化

- A-21 ディレクトリ・サーバーのレプリケーション・ステータスの取得

- A-22 ディレクトリ・サーバー・レプリケーションの無効化

- A-23 レプリケートされないサーバーでの外部変更ログの構成

- A-24 グローバル・ヘルプ・サブコマンドとグローバル・オプションの表示

- A-25 個別サブコマンドのヘルプの表示

- A-26 gicadmを使用したグローバル索引カタログの作成

- A-27 gicadmを使用したグローバル索引カタログへのグローバル索引の追加

- A-28 gicadmを使用したグローバル索引カタログの分散への関連付け

- A-29 スケジュール済タスクのサマリーの表示

- A-30 タスク情報の取得

- A-31 スケジュール済タスクの取消し

- A-32 既存の構成のコピーの取得

- A-33 ヘルプ・コマンド・オプションの実行

- A-34 構成の編集

- A-35 ヘルプ・コマンド・オプションの実行

- A-36 構成の貼付け

- A-37 ヘルプ・コマンド・オプションの実行

- A-38 GUIモードでのoud-replication-gateway-setupの実行

- A-39 コマンドラインからのインタラクティブ・モードでのoud-replication-gateway-setupの実行

- A-40 GUIモードでのoud-setupの実行

- A-41 コマンドラインからのインタラクティブ・モードでのoud-setupの実行

- A-42 非インタラクティブCLIモードでのoud-setupの実行

- A-43 LDIFインポートを指定した非インタラクティブCLIモードでのoud-setupの実行

- A-44 サンプル・エントリの生成を指定した非インタラクティブ・モードでのoud-setupの実行

- A-45 Windowsでのoud-setupの実行

- A-46 GUIモードでのoud-proxy-setupの実行

- A-47 非インタラクティブCLIモードでのoud-proxy-setupの実行

- A-48 サーバーの起動

- A-49 フォアグラウンド・プロセスとしてのサーバーの起動

- A-50 サーバー・ステータスの表示

- A-51 サーバーのローカルでの停止

- A-52 サーバーのリモートでの停止

- A-53 サーバーのリモートでの再起動

- A-54 グラフィカル・アンインストーラを使用したアンインストール

- A-55 コマンドラインを使用したアンインストール

- A-56 非インタラクティブCLIモードでのアンインストール

- A-57 サーバーのWindowsサービスとしての有効化

- A-58 サーバーのWindowsサービスとしての無効化

- A-59 ステータスの表示

- A-60 すべての構成済バックエンドのバックアップ

- A-61 特定のバックエンドのバックアップ

- A-62 増分バックアップの実行

- A-63 特定のバックエンドでの増分バックアップの実行

- A-64 既存のバックアップに対する増分バックアップの実行

- A-65 暗号化および署名付きハッシュによるすべての構成済バックエンドのバックアップ

- A-66 バックアップのスケジュール

- A-67 base64による文字列のエンコード

- A-68 base64によるファイルのコンテンツのエンコード

- A-69 base64でエンコードされた文字列のデコード

- A-70 base64でエンコードされたファイルのコンテンツのデコード

- A-71 Linuxシステムでのbase64によるエンコードおよびデコード

- A-72 ルート・コンテナのリストの表示

- A-73 エントリ・コンテナのリストの表示

- A-74 データベース・コンテナのリストの表示

- A-75 データベースのコンテンツのダンプとデコードのスキップ

- A-76 サーバーでの記憶スキームのリスト

- A-77 サーバーでの認証済パスコード構文記憶スキームのリスト

- A-78 クリアテキスト・パスワードの別のスキームへのエンコード

- A-79 認証パスワード構文を使用したクリアテキスト・パスワードの別のスキームへのエンコード

- A-80 クリアテキスト・パスワードとエンコード済パスワードの比較

- A-81 クリアテキスト・パスワードとエンコード済パスワードの比較および終了コードの返し

- A-82 SSHAを使用したファイル内のパスワードのエンコード

- A-83 オフライン・エクスポートの実行

- A-84 オンライン・エクスポートの実行

- A-85 エクスポートのスケジュール

- A-86 オフライン・インポートの実行

- A-87 LDIFファイルの一部のオフライン・インポート

- A-88 MakeLDIFテンプレートからのデータのインポート

- A-89 ユーザー属性のみのインポート

- A-90 ユーザー属性のみのインポートと属性の除外

- A-91 操作属性のみのインポート

- A-92 選択されたユーザーと操作属性のインポート

- A-93 オンライン・インポートの実行

- A-94 インポートのスケジュール

- A-95 2つのLDIFファイルの比較と標準出力への差異の送信

- A-96 2つのLDIFファイルの比較とファイルへの差異の送信

- A-97 LDIFファイルの変更

- A-98 LDIFファイルの検索

- A-99 フィルタ・ファイルを使用したLDIFファイルの検索

- A-100 現在のバックエンドのリスト

- A-101 バックエンドIDのリスト

- A-102 ベースDNのリスト

- A-103 サンプルLDIFファイルの作成

- A-104 大きいサンプルLDIFファイルの作成

- A-105 ユーザーのすべてのパスワード・ポリシー状態情報の表示

- A-106 ユーザー・アカウントの無効化

- A-107 ユーザー・アカウントの有効化

- A-108 索引の再作成

- A-109 すべての索引の再作成

- A-110 拡張索引の再作成

- A-111 バックアップ情報の表示

- A-112 バックアップの復元

- A-113 暗号化されたバックアップの復元

- A-114 復元のスケジュール

- A-115 split-ldifを使用したグローバル索引への1つの索引付け属性の移入

- A-116 split-ldifを使用したグローバル索引への複数の索引付け属性の移入

- A-117 索引の検証

- A-118 索引の検証とエラー件数のカウント

- A-119 グループ・メンバーシップに関するエンティティの比較

- A-120 属性値とエントリの比較

- A-121 サーバー認証でのldapcompareの使用

- A-122 クライアント認証でのldapcompareの使用

- A-123 コマンドラインからのエントリの削除

- A-124 DNファイルを使用した複数エントリの削除

- A-125 サーバー認証を使用したエントリの削除

- A-126 クライアント認証を使用したエントリの削除

- A-127 エントリの追加

- A-128 属性のエントリへの追加

- A-129 属性値の変更

- A-130 複数の属性の変更

- A-131 コマンドラインからの属性の削除

- A-132 コマンドラインからのエントリの削除

- A-133 サーバー認証でのldapmodifyの使用

- A-134 クライアント認証でのldapmodifyの使用

- A-135 ユーザー・パスワードの変更

- A-136 別のユーザーのパスワードの変更および生成

- A-137 別のユーザーのパスワードの変更

- A-138 すべてのエントリを返す

- A-139 値を除く属性名を返す

- A-140 特定の属性値を返す

- A-141 ルートDSEを返す

- A-142 サーバー認証を使用した検索

- A-143 クライアント認証を使用した検索

- A-144 ユーザーの有効権限を返す

- A-145 スキーマを返す

- A-146 永続検索の実行

- A-147 ACI属性の表示

- A-148 監視情報の表示

- A-149 プロパティ・ファイルを使用した検索

図一覧

- 2-1 基本的なレプリケーション・トポロジ

- 2-2 複数のデータ・センターのトポロジ

- 2-3 WAN上のレプリケーション・グループ

- 3-1 単純なロード・バランシング

- 3-2 単純な分散

- 3-3 データ・センター間のフェイルオーバー

- 3-4 分散とロード・バランシングの併用

- 3-5 分散とデータ・センター間のフェイルオーバーの併用

- 3-6 プロキシ・エンタープライズ・ユーザー・セキュリティ

- 3-7 複数のプロキシ・インスタンス

- 4-1 ネットワーク・グループの選択

- 4-2 ディレクトリ・サーバーに対するクライアント・リクエスト

- 4-3 Oracle Unified Directoryコンポーネントの高レベルな表現

- 8-1 マクロACIのディレクトリ・ツリーの例

- 11-1 フェイルオーバー・ロード・バランシングの例

- 11-2 最適ロード・バランシングの例

- 11-3 比例ロード・バランシングの例

- 11-4 リクエスト固有管理を行う比例ロード・バランシング

- 11-5 飽和ロード・バランシングの例

- 11-6 検索フィルタ・ロード・バランシング

- 11-7 数値分散の例

- 11-8 辞書編集分散の例

- 11-9 容量分散の例

- 11-10 DNパターン分散の列

- 11-11 ディレクトリ情報ツリーの例

- 11-12 DNリネーム

- 11-13 RDNの変更

- 11-14 読取り変換

- 11-15 書込み変換

- 11-16 マッピング変換

- 11-17 構成モデル

- 15-1 レプリケートされたグローバル索引カタログ

- 15-2 グローバル索引カタログの再起動

- 15-3 レプリケートされたグローバル索引カタログ・トポロジへのグローバル索引の追加

- 15-4 レプリケートされたグローバル索引カタログのコンテンツの上書き

- 15-5 レプリケート・トポロジへのプロキシの追加

- 15-6 クリティカル度フラグ

- 15-7 変換タイプ

- 15-8 「値定義」画面

- 16-1 ロード・バランシング

- 16-2 分散の構成

- 16-3 分散およびロード・バランシングの構成

- 17-1 仮想属性

- 18-1 ODSMの画面

- 19-1 動的グループの構造

- 19-2 仮想静的グループ

- 19-3 ネストされた静的グループ

- 21-1 userセキュア・モードでの接続

- 21-2 複数の接続プール

- 26-1 大規模なレプリケーション・トポロジ

- 26-2 非武装地帯内の分離レプリカ

- 26-3 ステージング領域内の分離レプリカ

- 29-1 Java監視と管理コンソール

- 29-2 単純なレプリケーション・トポロジ

- 29-3 単純なレプリケーション・トポロジ

表一覧

- 6-1 ディレクトリ・サーバーの監視属性

- 6-2 レプリケーション・サーバーの監視属性

- 8-1 LDIFターゲット・キーワード

- 8-2 マクロACIキーワード

- 11-1 addOutboundAttribute変換タイプのパラメータ

- 11-2 filterOutboundAttribute変換タイプのパラメータ

- 11-3 addInboundAttribute変換タイプのパラメータ

- 11-4 filterInboundAttribute変換タイプのパラメータ

- 11-5 mapAttribute変換タイプのパラメータ

- 11-6 transformations-workflow-elementの構成パラメータ

- 15-1 Oracle Unified Directoryでサポートされているバインド・モード

- 17-1 一致ルール接尾辞

- 17-2 サポートされている照合ルール

- 22-1 実効権限の相互依存性

- 22-2 実効権限ログ情報の理由とその説明

- 27-1 デフォルト・スキーマ・ファイル

- 27-2 各スキーマ・コンポーネントに使用されるベースOID

- 27-3 各属性タイプに割り当てられたOID値

- A-1 サーバー管理コマンド

- A-2 データ管理コマンド

- A-3 終了コード

- B-1 ディレクトリ・サーバーでサポートされているLDAP制御

- B-2 プロキシでサポートされているLDAP制御

- C-1 サポートされているRFC

- C-2 Oracle Unified Directoryがサポートしているインターネット・ドラフト

- C-3 Oracle Unified Directoryがサポートしているその他の仕様

はじめに

Oracle Unified Directory 11gリリース2 (11.1.2)管理者ガイドは、デプロイされたOracle Unified Directoryサーバーで必要とされる一般的な構成および管理タスクについて説明することを目的としています。

対象読者

このドキュメントは、デプロイされたOracle Unified Directoryサーバーの管理者を対象としています。

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

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

関連ドキュメント

次のドキュメントには、Oracle Unified Directoryの日常的な管理に関する情報が記載されています:

- Oracle Fusion Middleware Oracle Unified Directoryインストレーション・ガイド

- Oracle Fusion Middleware Oracle Unified Directoryリリース・ノート

表記規則

このマニュアルでは次の表記規則を使用します:

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

このガイドの最新情報

ここでは、Oracle Unified DirectoryとOracle Directory Services Manager (ODSM)の前のリリースから追加および変更された機能を紹介し、詳細情報へのリンクを記載します。次の各項で構成されます:

- Oracle Unified Directory 11gリリース2 PS1 (11.1.2.1.0)の新機能

- Oracle Unified Directory 11gリリース2 (11.1.2)の新機能

Oracle Unified Directoryの新機能

この項では、このリリースの新機能の簡単なサマリーを示します。次の各項で構成されます:

- Oracle Unified Directory 11gリリース2 PS1 (11.1.2.1.0)の新機能

- Oracle Directory Services Manager 11gリリース2 PS1 (11.1.2.1.0)の新機能

Oracle Unified Directory 11gリリース2 PS1 (11.1.2.1.0)の新機能

この項では、Oracle Unified Directoryのこのリリースの新機能の簡単なサマリーを示します。内容は次のとおりです:

- ACIにおけるマクロのサポート

- nsuniqueid仮想属性のサポート

- ワークフローでのクリティカル度のサポート

- 管理操作のロギングのサポート

- 変換フレームワークの紹介

- 外部変更ログ・プロパティの拡張

- Oracle Unified Directoryとエンタープライズ・ユーザー・セキュリティの外部LDAPリポジトリとの統合のサポート

- ルートDSEエントリの再配置のサポート

- RDN変更のサポート

- Directoryプラグインのサポート

ACIにおけるマクロのサポート

Oracle Unified Directoryでは、ACIのターゲット・セクションまたはバインド・ルール・セクション、あるいはその両方で、DNを表すマクロ式をサポートしています。

詳細は、第8.6項「高度なアクセス制御のためのマクロACIの使用」を参照してください。

nsuniqueid仮想属性のサポート

Oracle Unified Directoryでは、nsuniqueid仮想操作属性が導入されています。この属性は、LDAPデータベースとしてOracle Directory Server Enterprise Editionを使用するレガシー・アプリケーションをOracle Unified Directoryに移行する際の名前の競合を解決するために、ディレクトリ・サーバーの各エントリに割り当てられます。

詳細は、第17.10項「仮想属性の構成」を参照してください。

ワークフローでのクリティカル度のサポート

クリティカル度フラグを設定することによって、ワークフロー・レベルでクリティカル度を構成できます。

詳細は、第15.1.4.6項「ワークフローのクリティカル度の構成」を参照してください。

管理操作のロギングのサポート

Oracle Unified Directoryでは、管理トラフィック関連のロギング情報を格納する独立したログ・ファイルに管理操作を記録できます。

詳細は、第29.3.3項「アクセス・ログ・パブリッシャへの操作のロギング」を参照してください。

変換フレームワークの紹介

Oracle Unified Directoryでは、ワークフロー要素のインスタンス作成による変換をサポートしています。

詳細は、第11.6項「変換フレームワークの理解」を参照してください。

外部変更ログ・プロパティの拡張

Oracle Unified Directoryに、外部変更ログ(ECL)の属性を構成するためのプロパティとしてecl-include-del-onlyとecl-blacklistが追加されています。

詳細は、第26.5.5項「外部変更ログに含める属性の指定」と第26.5.6項「外部変更ログから除外する属性の指定」を参照してください。

Oracle Unified Directoryとエンタープライズ・ユーザー・セキュリティの外部LDAPリポジトリとの統合のサポート

Oracle Unified Directoryでは、次の外部ディレクトリがサポートされています:

- Microsoft Active Directory

- Novell eDirectory

- Oracle Directory Server Enterprise Edition

詳細は、第25.4項「エンタープライズ・ユーザー・セキュリティおよび外部LDAPディレクトリとの統合」を参照してください。

ルートDSEエントリの再配置のサポート

Oracle Unified Directoryでは、ルートDSEを再配置できます。ルートDSEは、サーバーの名前、バージョン、ネーミング・コンテキストおよびサポートする機能に関する情報を提供する特殊エントリです。

詳細は、第14.1.6.5項「ネットワーク・グループのルートDSEエントリの再配置」を参照してください。

RDN変更のサポート

Oracle Unified Directoryでは、RDNChanging構成を使用して、ソース・ディレクトリからOracle Unified DirectoryにRDN値の名前変更または置換を実行できます。

詳細は、第11.5項「RDNの変更」を参照してください。

Directoryプラグインのサポート

Oracle Unified Directoryでは、既存のディレクトリ・サーバー機能を拡張する手段として、DirectoryプラグインAPIをサポートしています。

詳細は、Oracle® Fusion Middleware Oracle Unified Directory開発者ガイドを参照してください。

Oracle Directory Services Manager 11gリリース2 PS1 (11.1.2.1.0)の新機能

この項では、Oracle Directory Services Manager (ODSM)のこのリリースの新機能のサマリーを示します。内容は次のとおりです:

- IBM WebSphere Application Serverのサポート

- ログ・パブリッシャ構成の拡張

- マクロACIとの統合

- ワークフロー構成におけるクリティカル度フラグのサポート

- 仮想属性のサポート

- 変換のサポート

- 新しいワークフロー要素のサポート

- ルートDSEエントリの構成のサポート

- RDN変更ワークフロー要素の構成のサポート

IBM WebSphere Application Serverのサポート

IBM WebSphere Application Server Network Deployment (ND)をインストールして、Oracle Unified Directoryと連携して動作するように構成できます。これが可能なのは、Oracle Directory Service Managerのグラフィカル・インタフェースを使用して、すでにOracle Unified Directoryを管理している場合のみです。詳細は、Oracle Fusion Middleware Oracle Unified Directoryインストレーション・ガイドのOracle Directory Services ManagerのためのIBM WebSphereの構成に関する項を参照してください。

ログ・パブリッシャ構成の拡張

ODSMでは、管理操作をアクセス・ログに記録するための新しいパラメータをサポートしています。

詳細は、第29.3.3.2項「ODSMを使用してアクセス・ログ・パブリッシャにログされた操作の構成」を参照してください。

マクロACIとの統合

ODSMでは、ACIのターゲット・セクションまたはバインド・ルール・セクション、あるいはその両方で、DNを表すマクロ式をサポートしています。

詳細は、第22.4項「Oracle Directory Services ManagerによるマクロACIの管理」を参照してください。

ワークフロー構成におけるクリティカル度フラグのサポート

ODSMでは、ワークフローを構成するためのクリティカル度フラグを新しいパラメータとしてサポートしています。

詳細は、第15.2.3項「ODSMを使用したワークフローのクリティカル度の構成」を参照してください。

仮想属性のサポート

ODSMでは、仮想属性を構成できます。

詳細は、第17.14項「Oracle Directory Services Managerを使用した仮想属性の管理」を参照してください。

変換のサポート

ODSMでは、変換ワークフロー要素の作成を通じて変換を定義できます。

詳細は、第15.2.4項「ODSMを使用した変換の構成」を参照してください。

新しいワークフロー要素のサポート

ODSMでは、次のワークフロー要素を作成できます:

- Kerberos認証プロバイダ・ワークフロー要素

- RDN変更ワークフロー要素

- 変換ワークフロー要素

詳細は、第14.2.4項「ODSMを使用したワークフロー要素の構成」を参照してください。

ルートDSEエントリの構成のサポート

ODSMでは、エンタープライズ・ユーザー・セキュリティの構成機能をサポートしています。

詳細は、第14.2.7項「ODSMを使用したネットワーク・グループの構成」を参照してください。

RDN変更ワークフロー要素の構成のサポート

ODSMでは、RDN変更ワークフロー要素を構成できます。

詳細は、第14.2.4項「ODSMを使用したワークフロー要素の構成」を参照してください。

Oracle Unified Directory 11gリリース2 (11.1.2)の新機能

この項では、このリリースの新機能の簡単なサマリーを示します。次の各項で構成されます:

- Oracle Unified Directory 11gリリース2 (11.1.2)の新機能

- Oracle Directory Services Manager 11gリリース2 (11.1.2)の新機能

Oracle Unified Directory 11gリリース2 (11.1.2)の新機能

この項では、Oracle Unified Directoryのこのリリースの新機能の簡単なサマリーを示します。内容は次のとおりです:

- 決定論的アイデンティティ・マッパーの評価順序のサポート

- LDAP参照のサポート

- バインド・モードの新しいパラメータ

- Microsoft Active Directoryページングのサポート

- クリティカル度フラグのサポート

- Oracleのエンタープライズ・ユーザー・セキュリティ(EUS)のサポート

- ソーシャル・ネットワーキング・アプリケーションのサポートの拡張

- 外部変更ログを構成するCLIの強化

- テスト環境から本番環境への移行のサポート

- CLIでのパスワード表示の非表示

決定論的アイデンティティ・マッパーの評価順序のサポート

競合を避けるには、ネットワーク・グループ内のアイデンティティ・マッパーの評価順序を定義する必要があります。現在は、競合するアイデンティティ・マッパーの優先度を定義できます。

詳細は、第12.6項「アイデンティティ・マッパーの順序付け」を参照してください。

LDAP参照のサポート

サーバーは、クライアントのリクエストを処理できない場合、トポロジ内の他のサーバーをクライアントに示すリフェラルのリストをクライアントに送信します。その後、クライアントは、リフェラル・リスト内のリモート・サーバーの1つに対して操作を再度実行します。

詳細は、第17.13項「リフェラルの構成」を参照してください。

バインド・モードの新しいパラメータ

現在は、never-bindパラメータとuse-proxy-authパラメータなどの2つの追加パラメータおよび包含リストと除外リストを使用してプロキシLDAPワークフロー要素を構成し、サーバーの動作を調整できます。

詳細は、第15.1.2項「バインド・モードの構成」を参照してください。

Microsoft Active Directoryページングのサポート

Oracle Unified Directoryでは、Microsoft Active Directoryページングをサポートすることによって、Active Directory範囲の取得をサポートしています。

詳細は、第15.1.8項「Microsoft Active Directoryページングの構成」を参照してください。

クリティカル度フラグのサポート

Oracle Unified Directoryにクリティカル度構成が実装されています。クリティカル度構成は、検索操作がホスト・エラーによって失敗した場合に、Oracle Unified Directoryプロキシ・サーバーが途中までのデータをクライアントに返すことを許可します。

詳細は、第15.1.4.7項「ワークフロー要素のクリティカル度の構成」を参照してください。

Oracleのエンタープライズ・ユーザー・セキュリティ(EUS)のサポート

Oracle Unified DirectoryをEUSと統合することによって、Oracle Database認証に使用するユーザーIDをOracle Unified Directoryに保存できます。

このリリースでは、EUSのサポートはパスワード認証に制限されています(証明書認証およびKerberosとの統合は現在のところサポートされていません)。

詳細は、第25章「Oracleのエンタープライズ・ユーザー・セキュリティとの統合」を参照してください。

ソーシャル・ネットワーキング・アプリケーションのサポートの拡張

ソーシャル・ネットワーキング・アプリケーションに、結合コントロールと近接コントロールの2つの新しいコントロールによるサポートが追加されています。

詳細は、第17.5.3.2項「結合検索制御を使用した検索」と第17.5.3.3項「近接検索制御を使用した検索」を参照してください。

外部変更ログを構成するCLIの強化

外部変更ログ(ECL)機能を使用すると、ディレクトリ・サーバー・データベースで発生したすべての変更をパブリッシュでき、LDAPディレクトリと他のサブシステムを同期する場合に特に便利です。

dsreplicationコマンドを使用して外部変更ログを構成するCLIがわかりやすくなっています。

詳細は、第26.5項「外部変更ログの使用」を参照してください。

テスト環境から本番環境への移行のサポート

テスト環境では、Oracle Unified Directoryのインストール、構成、カスタマイズおよび検証を実行できます。システムが想定どおりに機能するようになったら、テスト環境に組み込んだすべての変更内容を再実行するかわりに、サーバーとその構成のコピーをテスト環境から移行することで本番環境を作成できます。

詳細は、第28章「テスト環境から本番環境への移行」を参照してください。

CLIでのパスワード表示の非表示

一部のコマンドには、CLIでパスワードをクリア・テキスト形式で渡すオプションがありました。この場合、UNIXマシンでpsコマンドを使用してパスワードを取得できるので、セキュリティ上の脅威になります。

クリア・テキスト形式は非推奨になり、次のオプションを導入することによって、ファイルベースのオプションを使用してパスワードを格納するようにコマンドが変更されています:

-j, --bindPasswordFile

詳細は、付録A「Oracle Unified Directoryコマンドライン・インタフェース」を参照してください。

ADSトラスト・ストアPINの暗号化機能

Oracle Unified Directoryでは、ADSトラスト・ストアPINを構成して、提示されている証明書を信頼するかどうかを決定できます。

詳細は、第20.3項「信頼マネージャ・プロバイダの構成」を参照してください。

Oracle Directory Services Manager 11gリリース2 (11.1.2)の新機能

この項では、Oracle Directory Services Manager (ODSM)のこのリリースの新機能の簡単なサマリーを示します。内容は次のとおりです:

- EUSの接尾辞構成

- ルート・ユーザーを構成する新しいユーザー・インタフェース

- キー・マネージャと信頼マネージャの構成

- オートサジェスト機能

- 動的グループのサポート

- 仮想静的グループのサポート

- 「構成」タブのツリー構造の簡素化

EUSの接尾辞構成

ODSMでは、Oracle Enterprise User Security (EUS)と連携して動作するための接尾辞を作成および構成できます。

詳細は、第14.2.3項「ODSMを使用した接尾辞の構成」を参照してください。

ルート・ユーザーを構成する新しいユーザー・インタフェース

ODSMでは、ルート・ユーザーを構成するための新しいユーザー・インタフェース(UI)を提供しています。

詳細は、第19.2.2項「ODSMを使用したルート・ユーザーの構成」を参照してください。

キー・マネージャと信頼マネージャの構成

ODSMを使用して、キー・マネージャ・プロバイダと信頼マネージャを構成できます。

詳細は、第20.2.6項「ODSMによるキー・マネージャの構成」と第20.3.5項「ODSMによる信頼マネージャの構成」を参照してください。

オートサジェスト機能

ODSMでは、構成および操作の効率向上に役立つオートサジェスト機能が各タブに実装されています。

詳細は、第17.15項「Oracle Directory Services Managerを使用したデータの管理」を参照してください。

動的グループのサポート

OSDMでは、LDAP URLを使用する検索条件によってメンバーシップが決定される動的グループを作成できます。

詳細は、第19.3.2項「動的グループの定義」を参照してください。

仮想静的グループのサポート

ODSMでは、仮想静的グループを作成できます。このグループの各エントリは、仮想属性を使用して、静的グループのエントリのように動作します。

詳細は、第19.3.4項「ネストされたグループの定義」を参照してください。

「構成」タブのツリー構造の簡素化

「構成」タブの構成ツリーのデフォルト・ビューが簡素化されて、ネーミング・コンテキスト(または接尾辞)構成がわかりやすく表示されるようになりました。さらに、選択したノードのすべての関連操作を起動できるコンテキスト・メニューにより、ユーザーの操作が簡素化されています。

詳細は、第14.2項「Oracle Directory Services Managerを使用したサーバー構成の管理」を参照してください。

第I部

Oracle Unified Directoryの概要

この部では、Oracle Unified Directoryの概要およびそのインストール・モードについて説明します。また、サーバー・モードごとのサンプル・デプロイメント・シナリオについて説明します。

この部の内容は次のとおりです:

- 第1章「Oracle Unified Directoryの概要」

- 第2章「ディレクトリ・サーバーを使用するデプロイメントの例」

- 第3章「プロキシ・サーバーを使用するデプロイメントの例」

1 Oracle Unified Directoryの概要

この章では、Oracle Unified Directoryの概要およびOracle Unified Directoryの固有の機能の一部について説明します。

この章には次のトピックが含まれます:

- 第1.1項「Oracle Unified Directoryとは」

- 第1.2項「ディレクトリ・サーバーの概要」

- 第1.3項「プロキシ・サーバーの概要」

- 第1.4項「レプリケーション・ゲートウェイの概要」

1.1 Oracle Unified Directoryとは

Oracle Unified Directoryは、次世代の包括的なディレクトリ・サービスです。大規模なデプロイメントに対応し、高パフォーマンスを提供できるように設計され、拡張性に優れています。Oracle Unified Directoryは、簡単にデプロイ、管理および監視できます。

この項には次のトピックが含まれます:

- 第1.1.1項「Oracle Unified Directoryのコンポーネント」

- 第1.1.2項「Oracle Unified Directoryのインストール・タイプ」

- 第1.1.3項「Oracle Unified Directoryと他のディレクトリの同期」

1.1.1 Oracle Unified Directoryのコンポーネント

Oracle Unified Directoryには次が含まれます:

- LDAPディレクトリ・サーバー。データの格納に使用します。
ディレクトリ・サーバーの詳細は、第1.2項「ディレクトリ・サーバーの概要」を参照してください。

- プロキシ・サーバー。データが格納されているディレクトリ・サーバーとクライアントの間のインタフェースとして動作します。
プロキシ・サーバーの詳細は、第1.3項「プロキシ・サーバーの概要」を参照してください。

- レプリケーション・ゲートウェイ。Oracle Unified DirectoryとOracle Directory Server Enterprise Editionの間に位置します。
レプリケーション・ゲートウェイの詳細は、第1.4項「レプリケーション・ゲートウェイの概要」を参照してください。

使用する必要があるOracle Unified Directoryサーバー・モードの詳細は、第1.1.2項「Oracle Unified Directoryのインストール・タイプ」を参照してください。

1.1.2 Oracle Unified Directoryのインストール・タイプ

Oracle Unified Directoryサーバーの動作モードは、要件に応じてこのソフトウェアをインストールする方法によって決まります。

Oracle Unified Directoryをインストールする際、次のいずれかのインストール・タイプを選択できます:

- 第1.1.2.1項「ディレクトリ・サーバーの設定」

- 第1.1.2.2項「プロキシ・サーバーの設定」

- 第1.1.2.3項「レプリケーション・ゲートウェイ・サーバーの設定」

1.1.2.1 ディレクトリ・サーバーの設定

ディレクトリ・データを格納するLDAPディレクトリを作成する場合、ディレクトリ・サーバーとしてOracle Unified Directoryをインストールします。詳細は、Oracle Fusion Middleware Oracle Unified Directoryインストレーション・ガイドの「ディレクトリ・サーバーの設定」を参照してください。

1.1.2.2 プロキシ・サーバーの設定

データを格納するディレクトリ・サーバーとクライアントの間のインタフェースとしてサーバーを使用する場合、プロキシ・サーバーとしてOracle Unified Directoryをインストールします。プロキシ・サーバーにはデータは格納されません。ロード・バランシングまたはデータ分散を通じて、クライアント・リクエストを処理します。プロキシ・サーバーの設定の詳細は、Oracle Fusion Middleware Oracle Unified Directoryインストレーション・ガイドの「プロキシ・サーバーの設定」を参照してください。

1.1.2.3 レプリケーション・ゲートウェイ・サーバーの設定

Oracle Unified Directoryサーバーを使用してOracle Unified DirectoryとOracle Directory Server Enterprise Editionの間で情報をレプリケートする場合、レプリケーション・ゲートウェイとしてOracle Unified Directoryをインストールします。詳細は、Oracle Fusion Middleware Oracle Unified Directoryインストレーション・ガイドの「レプリケーション・ゲートウェイの設定」を参照してください。

1.1.3 Oracle Unified Directoryと他のディレクトリの同期

Oracle Directory Integration Platformを使用して、Oracle Unified Directoryと他のディレクトリを同期できます。

注意:

Oracle Directory Integration Platformは、Oracle Identity Managementリリース11.1.1.6.0以上をインストールすることで入手できます。

Oracle Directory Integration Platformは、ディレクトリと他のリポジトリの間の同期とプロビジョニングのソリューションを支援する一連のサービスとインタフェースで構成されます。

ディレクトリ統合プラットフォームを使用してOracle Unified Directoryの同期を有効にする場合、Oracle Unified Directory変更ログを有効にする必要があります。Oracle Unified Directoryの変更ログを有効にする方法の詳細は、第26.5項「外部変更ログの使用」を参照してください。

ディレクトリ統合プラットフォームの同期には、次の方法があります:

- 第1.1.3.1項「Oracle Unified DirectoryとOracle Internet Directoryの間の同期」

- 第1.1.3.2項「Oracle Unified Directoryとサード・パーティ・ディレクトリの間の同期」

1.1.3.1 Oracle Unified DirectoryとOracle Internet Directoryの間の同期

Oracle Directory Integration Platform 11.1.1.5以上で、Oracle Internet DirectoryとOracle Unified Directoryの間の同期がサポートされています。同期手順の詳細は、ディレクトリ統合プラットフォーム管理者ガイドの「Oracle Directory Server Enterprise Editionとの統合」を参照してください。Oracle Directory Server Enterprise Editionは、旧名Sun Java System Directory Serverです。同期が正常に動作するには、ガイドでSJSDSと参照されている箇所をすべてOUDに置き換える必要があります。Oracle Directory Integration Platformは、Oracle Identity Managementリリース11.1.1.6.0以上をインストールすることで入手できます。

1.1.3.2 Oracle Unified Directoryとサード・パーティ・ディレクトリの間の同期

Oracle Unified Directoryとサード・パーティ・ディレクトリの間のデータ同期を有効にするには、Oracle Directory Integration PlatformをOracle Unified Directoryと統合する必要があります。Oracle Directory Integration Platformは、Oracle Identity Managementリリース11.1.1.6.0以上をインストールすることで入手できます。

1.2 ディレクトリ・サーバーの概要

この項では、Oracle Unified Directoryサーバーのディレクトリ・サーバー・コンポーネントの概要について説明します。

Oracle Unified Directoryサーバーは、すべてJavaで記述されているLDAPv3準拠ディレクトリです。ディレクトリ・サーバーには、次の高レベルの機能が組み込まれています:

- LDAPv3 (RFC 4510-4519)に完全準拠し、多数の標準および実験的拡張をサポート

- 高パフォーマンス、高スペース効率のデータ・ストレージ

- 構成と管理が容易

- 非常に拡張性の高い管理フレームワーク。この後にリストされている機能のほとんどをカスタマイズできます。

- 管理コネクタ。サーバーへのすべての管理トラフィックを管理します。管理コネクタを使用すると、ユーザー・トラフィックと管理トラフィックを分離して、ロギングと監視を簡素化し、ユーザー・データを操作するコマンドよりも管理コマンドが優先されることを保証できます。

- グラフィカルなコントロール・パネル。サーバー・ステータス情報を表示し、サーバーとデータの基本的な管理操作を実行できます。

- 各種コマンドライン・ユーティリティ。構成、管理タスク、基本監視およびデータ管理を支援します。メイン構成ユーティリティ(dsconfig)には、大部分の構成タスクを段階的に実行できる対話モードがあります。

- 高度なレプリケーション・メカニズム。

- 強化されたディレクトリ・サーバー・インスタンス間のマルチマスターのレプリケーション。

- 保証レプリケーション機能。データの高可用性および特定のデプロイメント要件におけるデータの即時可用性を保証します。

- 部分レプリケーション機能。

- ディレクトリ・サーバー・データベースで発生したすべての変更を公開する外部変更ログのサポート。

- 拡張可能セキュリティ・モデル

- 様々なレベルの認証と機密性のサポート

- 権限に基づくリソースへのアクセス

- 高度なアクセス制御メカニズム

多面的な監視機能

- 豊富なユーザー管理機能

- パスワード・ポリシー

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

- アカウント・ステータス通知

1.3 プロキシ・サーバーの概要

この項では、Oracle Unified Directoryのプロキシ・コンポーネントの概要について説明します。この項の内容は次のとおりです:

- 第1.3.1項「プロキシ・サーバーとは」

- 第1.3.2項「プロキシ・サーバーを使用する理由」

1.3.1 プロキシ・サーバーとは

Oracle Unified Directoryプロキシは、データを格納しないで、クライアントからのLDAPリクエストを企業全体に分散しているディレクトリ・サーバーにルーティングするLDAPv3準拠サーバーです。

このプロキシは、複数のディレクトリ・サーバーまたは複数のデータ・センター、あるいはその両方の全体に分散しているディレクトリ・サービス・デプロイメントへのエントリ・ポイントです。クライアント・リクエストはすべて、プロキシによって適切なリモートLDAPサーバーにルーティングされます。Oracle Unified Directoryプロキシ・コンポーネントは、Oracle Unified DirectoryサーバーやOracle Directory Server Enterprise Editionなど、任意のLDAP v3準拠ディレクトリ・サーバーと連携して動作できます。

データ・リクエストをリモートLDAPサーバーにルーティングするために、ロード・バランシングまたはデータ分散のどちらか、あるいはその両方を使用するようにプロキシ・コンポーネントを構成できます。

Oracle Unified Directoryプロキシは、oud-proxy-setupを使用して、非常に単純な構成またはレプリケーションを使用するより複雑なシナリオのどちらでもデプロイできます。単純なデプロイメントの詳細は、第3章「プロキシ・サーバーを使用したデプロイメント例」を参照してください。

注意:

プロキシ・コンポーネントをデータストアとして直接使用することはできません。

プロキシは、クライアントとリモートLDAPサーバーの間のインタフェースとして、必要に応じてセキュアな接続を保証するために、様々なセキュリティ機能を提供します。セキュリティの詳細は、第21章「プロキシ/データ・ソース間のセキュリティ構成」を参照してください。

Oracle Unified Directoryプロキシを構成する要素の詳細は、第11章「プロキシ機能の理解」を参照してください。

1.3.2 プロキシ・サーバーを使用する理由

プロキシは、クライアントとデータ・ソース(単一サーバー、レプリケートされたサーバーまたはデータ・センターの場合)の間のすべての接続を管理します。したがって、データ・ソースのロード・バランシング、データ分散およびセキュリティの処理など、クライアント接続に関するすべてのルールを集中管理します。

ロード・バランシング用にプロキシをデプロイする場合、プロキシが受信するリクエストはすべて、デプロイメント時に設定されたロード・バランシング・アルゴリズムに基づいて、いずれかのリモートLDAPサーバーにルーティングされます。これにより、プロキシが通信する必要があるバックエンド・ディレクトリ・サーバーを特定し、各ディレクトリ・サーバーが受信する必要があるクライアントの総ロードに対する割合を指定できます。構成後は、プロキシは自動的に、構成で定義されているロード条件に従って、クライアント問合せを複数のディレクトリ・サーバーに分配します。

高可用性ディレクトリ・サービスをデプロイするには、レプリケートされたディレクトリ・サーバーを少なくとも2つ用意する必要があります。最初のサーバーで処理できなかったリクエストがバックアップ・サーバーによって処理されることを保証するには、すべてのクライアントが両方のデータ・ソースのアドレスを認識し、プライマリ・サーバーでの失敗はバックアップ・サーバーにそのリクエストを再送信することで処理するようにコーディングされていることを保証する必要があります。プロキシでリクエストのフェイルオーバーとロード・バランシングが処理されるので、高可用性とスケーラビリティが単純化されます。

一般に、1つのサーバーのみを使用してデプロイメントのすべてのデータを格納する場合、データ・ストアが大きすぎると、パフォーマンスの問題が発生します。この問題は、1つのサーバーを複数のサーバーに置き換えて、それらのサーバーにデータを分散させることで解決できます。この場合、各クライアント・アプリケーションが、そのデータを検索するサーバーを認識する必要があります。プロキシを使用すると、各アプリケーションの分散情報をレプリケートする必要はなくなります。これは、リクエストを適切なデータ・ソースに分散する処理を、プロキシが管理するからです。この場合、クライアント・アプリケーションはリクエストをプロキシに送信します。プロキシはリクエストされたデータが保持されているパーティションを認識しているので、分散機能を使用してリクエストを処理します。

デプロイメントでプロキシを使用することによって、クライアント・アプリケーションの構成と管理の手間が軽減されます。プロキシは、すべてのリクエストを集めて処理することで、リクエストのロード・バランシングまたは分散、あるいはその両方を保証します。

プロキシは、ディレクトリ・サービスのセキュリティを管理する単一アクセス・ポイントにもなります。プロキシを使用して、リモート・ディレクトリ・サーバーへのアクセスを認可または制限できます。また、メンテナンスまたはLDAPサーバーのバックアップを実行する場合、プロキシ・デプロイメントを変更するだけでサービスの中断を回避できます。

サンプル・デプロイメントの詳細は、第3章「プロキシ・サーバーを使用したデプロイメント例」を参照してください。

1.4 レプリケーション・ゲートウェイの概要

この項では、Oracle Unified Directoryのレプリケーション・ゲートウェイ・コンポーネントの概要について説明します。内容は次のとおりです:

- 第1.4.1項「レプリケーション・ゲートウェイとは」

- 第1.4.2項「レプリケーション・ゲートウェイの役割」

- 第1.4.3項「レプリケーション・ゲートウェイの制限事項」

移行シナリオでのレプリケーション・ゲートウェイのデプロイの詳細は、第26.11項「Oracle Directory Server Enterprise EditionとOracle Unified Directory間のレプリケーション」を参照してください。

1.4.1 レプリケーション・ゲートウェイとは

レプリケーションは、1つのディレクトリ・サーバー上で行われた変更を、レプリケーション・トポロジ内の他の複数のディレクトリに伝播するメカニズムです。レプリケーション・ゲートウェイは、Oracle Directory Server Enterprise Editionのディレクトリ・サーバーとOracle Unified Directoryのディレクトリ・サーバーの間でレプリケーション情報を効率的に変換し、伝播します。変換には中間ファイルを使用しないので、データがディスクに格納されることはありません。

レプリケーション・ゲートウェイの主な目的は、既存のOracle Directory Server Enterprise Editionデプロイメントを容易にOracle Unified Directoryトポロジに移行できるようにすることです。この移行を成功させるには、Oracle Directory Server Enterprise Edition 11gリリース1 (11.1.1)以上が必要です。

レプリケーション・ゲートウェイは、ディレクトリの各バージョンに固有の同期メカニズムを変換して、異種トポロジの間の双方向レプリケーションを実現します。レプリケーション・ゲートウェイは、レプリケートする異種トポロジの間で更新を伝播するパイプと見なすことができます。

1.4.2 レプリケーション・ゲートウェイの役割

次の例は、2つのトポロジの間でレプリケーション・ゲートウェイを使用することによって、既存のOracle Directory Server Enterprise Edition 11gリリース1 (11.1.1)デプロイメントをOracle Unified Directoryトポロジに移行する方法を示します。

レプリケーション・ゲートウェイの役割は、異種サーバー上で行われる変更をレプリケーション・トポロジ全体に伝播することです。

全体的なレプリケーション・トポロジの中では、レプリケーション・ゲートウェイは双方向転送サーバーとして動作します。Oracle Directory Server Enterprise Editionサーバーで行われた変更をOracle Unified Directoryレプリケーション・トポロジに伝播し、Oracle Unified Directoryサーバーで行われた変更をOracle Directory Server Enterprise Editionレプリケーション・トポロジに伝播します。各インスタンスでは、レプリケーション・ゲートウェイは双方向に伝播します。移行シナリオに従って、Oracle Unified DirectoryサーバーからOracle Directory Server Enterprise Editionレプリケーション・トポロジへの変更の伝播を無効にできます。

高可用性を実現するために、すべての移行シナリオで2つのレプリケーション・ゲートウェイ・サーバーがデプロイされます。

1.4.3 レプリケーション・ゲートウェイの制限事項

レプリケーション・ゲートウェイは、次のものを管理しません:

- データ初期化。レプリケーション・ゲートウェイ経由の全面的更新はサポートされていません。Oracle Unified DirectoryサーバーのデータでOracle Directory Server Enterprise Editionトポロジを初期化するには、Oracle Unified Directoryサーバーからデータをエクスポートして、Oracle Directory Server Enterprise Editionマスター・サーバーにインポートする必要があります。

- スキーマの一貫性。レプリケーション・ゲートウェイは、異種サーバー間のスキーマの一貫性を保証しません。管理者が、一貫性のあるスキーマを定義する必要があります。

- 機能の変換。レプリケーション・ゲートウェイは、異種サーバー間の機能変換は行わず、機能に関してトポロジが異種混合であることを前提としています。互換性のない機能(たとえば、マクロACI、CoS、パスワード・ポリシー)を処理する最善の方法は、レプリケーションの実行前に、影響を受けるオブジェクト・クラスと属性タイプをフィルタで除外することです。
レプリケーション・ゲートウェイには、Oracle Directory Server Enterprise EditionからOracle Unified Directoryへのレプリケーションに対するフィルタリング・オプションが用意されています。このオプションを使用して、Oracle Unified Directoryサーバーに適用しないオブジェクト・クラスと属性タイプを除外できます。フィルタリングに構成されているデフォルト値は、CoS、ロール、パスワード・ポリシーおよび競合解消の違いを考慮しています。

- レプリケーション競合の解消。単一値属性の場合、異なる値が同時に1つの単一値属性に追加されたときのOracle Directory Server Enterprise EditionサーバーとOracle Unified Directoryサーバーの処理は異なります。Oracle Directory Server Enterprise Editionサーバーでは最後の変更/追加操作の値が保持されますが、Oracle Unified Directoryサーバーでは最も古い値が保持されます。両方の値が常に同じであるとはかぎりません。

2 ディレクトリ・サーバーを使用するデプロイメントの例

この章では、Oracle Unified Directoryディレクトリ・サーバーの複数のインスタンスが含まれる、レプリケートされるトポロジのサンプル構成について説明します。

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

- 第2.1項「小規模なレプリケートされるトポロジ」

- 第2.2項「複数のデータ・センターのトポロジ」

Oracle Unified Directoryでのレプリケーションの動作の詳細は、第6章「Oracle Unified Directoryレプリケーション・モデルの理解」を参照してください。

2.1 小規模なレプリケートされるトポロジ

サーバー間でディレクトリ・データをレプリケートすることによって、1つのマシンのアクセス負荷を減らすことができるので、サーバー・レスポンス時間が向上し、読取り操作が水平方向にスケーリングされます。また、レプリケーションを使用して、マシンに障害が発生した場合のデータの可用性を保証できます。

レプリケーションを使用して書込み操作をスケーリングすることはできません。これは、1つのディレクトリ・サーバーへの書込み操作は、結果的にトポロジ内の他のすべてのサーバーへの書込み操作になるからです。書込み操作を水平方向にスケーリングする唯一の方法は、ディレクトリ・データを分割して複数のデータベースに格納し、これらのデータベースを複数のサーバーに配置することです。

Oracle Unified Directoryの集中レプリケーション・モデルでは、ユーザー・データはレプリケーション・メタデータから分離されます。このモデルでは、ユーザー・データが格納されるサーバーは、ディレクトリ・サーバーと呼ばれます。レプリケーション・メタデータが格納されるサーバーは、レプリケーション・サーバーと呼ばれます。この方法は、レプリケーション・トポロジの管理を簡素化し、パフォーマンスを向上できます。

小規模デプロイメントの場合、レプリケーション・サーバーとディレクトリ・サーバーを同一システム上に配置する方法でレプリケーションを設定できます。1つのプロセスで各システム上のレプリケーション・サーバーとディレクトリ・サーバーを実行することによって、管理をさらに簡素化できます。

次の図は、小規模トポロジで、可用性を保証し、読取りをスケーリングするために、レプリケーションを使用する方法を示します。

図2-1 基本的なレプリケーション・トポロジ

2.1.1 トポロジにおけるディレクトリ・サーバーの役割

ディレクトリ・サーバーには、次のタスクを実行する役割があります:

- データの永続化およびクライアント・リクエストの処理

- 特定のレプリケーション・サーバーへの変更の転送

ディレクトリ・サーバー上で変更が行われると、このサーバーは、選択されているレプリケーション・サーバーに変更を転送します。レプリケーション・サーバーは受信した変更をトポロジ内の他のレプリケーション・サーバーにリプレイし、今度はそれらのサーバーが変更をトポロジ内の他のすべてのディレクトリ・サーバーにリプレイします。

各ディレクトリ・サーバーには、次の項目が格納されます:

- 同期する接尾辞DNのリスト

- 接尾辞DNごとの接続先レプリケーション・サーバーのリスト

通常、アプリケーションは、同一ディレクトリ・サーバー・インスタンスに対して読取りと書込みを実行する必要があります。これにより、それらのアプリケーションで緩い一貫性が原因で一貫性の問題が発生することを防ぎます。

2.1.2 トポロジにおけるレプリケーション・サーバーの役割

レプリケーション・サーバーには、次のタスクを実行する役割があります:

- ディレクトリ・サーバーからの接続の管理

- 他のレプリケーション・サーバーへの接続

- 他のレプリケーション・サーバーからの接続のリスニング

- ディレクトリ・サーバーからの変更の受信

- ディレクトリ・サーバーおよび他のレプリケーション・サーバーへの変更の転送

- 安定したストレージへの変更の保存(古い操作の切捨てが含まれます)

各レプリケーション・サーバーには、レプリケーション・トポロジ内の他のすべてのレプリケーション・サーバーのリストが存在します。レプリケーション・サーバーには、レプリケーション・トポロジに関する情報を他のサーバーに提供する役割もあります。最小規模のデプロイメントであっても、2つのレプリケーション・サーバー・インスタンスを実行する必要があります。これは、どちらかのレプリケーション・サーバー・インスタンスに障害が発生した場合の可用性を保証するためです。通常、同時に複数の障害が発生してもディレクトリ・サービスを提供できるようにする必要がある場合またはディレクトリ・サーバー・インスタンスの数を非常に多くする必要がある場合を除いて、レプリケーション・サーバー・インスタンスを増やす必要はありません。

レプリケーション・サーバーは、ディレクトリ・データは格納されませんが、常にLDAPサーバーまたはJMXサーバーのいずれかです。ディレクトリ・サーバーと同じように、レプリケーション・サーバーを構成、監視、バックアップおよびリストアできます。

2.2 複数のデータ・センターのトポロジ

レプリケーションを使用して、複数のデータ・センターの複数のサーバー上にディレクトリ・データの同一のコピーを提供することにより、ディレクトリ・サービスを地理的に分散させることができます。小規模トポロジに関する項で説明したレプリケーション・デプロイメントの基本原則は、複数のデータ・センターのデプロイメントにも当てはまります。

Oracle Unified Directoryディレクトリ・サーバーは、広域ネットワーク(WAN)上で効果的なカスタム・レプリケーション・プロトコルを使用します。次のシナリオでは、企業がロンドンとニューヨークの2箇所に大規模データ・センターを配置し、それらがWANで接続されています。

このデプロイメントには、どちらかのレプリケーション・サーバー・インスタンスに障害が発生した場合の各データ・センターの可用性を保証するために、2つのレプリケーション・サーバー・インスタンスが存在します。ディレクトリ・サーバーはまず、ローカル・レプリケーション・サーバーに接続します。ディレクトリ・サーバーがもう一方のデータ・センターにあるレプリケーション・サーバーにアクセスするのは、すべてのローカル・レプリケーション・サーバーに障害が発生した場合のみです。クライアント・アプリケーションは常にローカル・ディレクトリ・サーバー・インスタンスに接続し、同一のディレクトリ・サーバー・インスタンスに対して読取りと書込みを実行します。

Oracle Unified Directoryディレクトリ・サーバーがサポートする、レプリケーション・トポロジ内の読取り/書込みディレクトリ・サーバーの数には制限がありません。ディレクトリ・サーバーの数は、組織の読取り要件に従ってスケーリングできます。ディレクトリ・サーバーの数を増やしても、処理できる書込みの数はスケーリングされません。これは、最終的にはトポロジ内のすべてのサーバーがすべての書込みを処理する必要があるからです。収束しないトポロジを持つことが許容される場合を除き、トポロジの書込みスループットは、最も遅いマシンの書込みスループットで制限されます。

図2-2 複数のデータ・センターのトポロジ

2.2.1 複数のデータ・センターとレプリケーション・グループ

レプリケーション・グループを使用すると、データ・センターの場所など、特定の条件に従って、レプリケートされるトポロジを編成できます。レプリケーション・グループは、グループ内のレプリケーション・サーバーとディレクトリ・サーバーに割り当てられる一意のIDによって識別されます。グループIDによって、ディレクトリ・サーバー・ドメインが利用可能なレプリケーション・サーバーに接続する方法が決まります。ディレクトリ・サーバーは、構成済のレプリケーション・サーバーのリストを参照して、自身のグループIDと同じグループIDを持つレプリケーション・サーバーに接続を試みます。

次のサンプル・デプロイメントでは、複数のデータ・センターでのレプリケーション・グループの使用方法を示します。このデプロイメントでは、2つのデータ・センターが、広域ネットワーク(WAN)で接続され、次のように構成されていると想定しています:

- 1つのデータ・センター内のレプリケーション・サーバーとディレクトリ・サーバーにはそれぞれ同じグループIDが割り当てられています。

- データ・センター全体に一意なグループIDが1つ存在する(データ・センターごとに1つのグループID)

図2-3は、異なるグループIDを持つ2つのデータ・センターで構成されるディザスタ・リカバリ・デプロイメントを示します。

図2-3 WAN上のレプリケーション・グループ

このデプロイメントでは、各ディレクトリ・サーバーは同じデータ・センターにあるレプリケーション・サーバーに接続を試みることによって、WAN経由で接続する場合の待機時間を回避します。データ・センター内のすべてのレプリケーション・サーバーに障害が発生している場合は、ディレクトリ・サーバーはリモート・レプリケーション・サーバーに接続します。これにより、パフォーマンスは低下しますが(データ・センター間が低速接続の場合)、レプリケーション・サービスが引き続き提供されることが保証されます。1つ以上のローカル・レプリケーション・サーバーがオンラインに復帰すると、ディレクトリ・サーバーは自動的にローカル・レプリケーション・サーバーに再接続します。

2.2.2 複数のデータ・センターとウィンドウ・メカニズム

Oracle Unified Directoryディレクトリ・サーバーは、特定のサーバーが受信側サーバーからの確認を待たずに連続して一定数の更新リクエストを送信することを指定する、ウィンドウ・メカニズムを提供します。

ウィンドウ・サイズは、受信側サーバーからの即時確認がなくても送信可能な更新メッセージの最大数を表します。待機時間の長いネットワークで接続されている複数のデータ・センターにまたがるトポロジの場合、ウィンドウ・サイズをデフォルト値の100から増やす価値がある可能性があります。ウィンドウ・サイズがレプリケーション・スループットを制限する要因になっているかどうかを評価するには、cn=monitorの下のcurrent-send-window属性とcurrent-rcv-window属性を監視します。

あるサーバーが定常的に 0 または 0 に近い値のcurrent-send-windowを対応するサーバーにパブリッシュし、そのサーバーがそれより大きい値のcurrent-rcv-windowをパブリッシュしている場合、すべてのデータが現在ネットワーク上に送信されていることを意味します。この場合、受信側サーバーのウィンドウ・サイズを増やすと、レプリケーション速度が向上し、レプリケーション遅延が減るはずです。これらの状況が改善されることで、受信側サーバーのリソース消費量は増加します。

3 プロキシ・サーバーを使用するデプロイメントの例

様々なタイプのデプロイメントでOracle Unified Directoryプロキシを正常に使用できます。次に、プロキシの動作の理解に役立つデプロイメントを示します。

この章では、次のトピックを取り扱います:

- 第3.1項「プロキシ・デプロイメント・タイプの決定」

- 第3.2項「構成1: 単純なロード・バランシング」

- 第3.3項「構成2: 単純な分散」

- 第3.4項「構成3: データ・センター間のフェイルオーバー」

- 第3.5項「構成4: 分散とロード・バランシングの併用」

- 第3.6項「構成5: 分散とデータ・センター間のフェイルオーバーの併用」

- 第3.7項「構成6: エンタープライズ・ユーザー・セキュリティ」

- 第3.8項「レプリケートされる複数のプロキシ」

3.1 プロキシ・デプロイメント・タイプの決定

プロキシを使用する主なデプロイメント・タイプとして、ロード・バランシングと分散の2つがあります。

使用するデプロイメント・タイプを決定するには、データを格納する場所と方法および処理するデータ量について検討します。

- レプリケートされるデータ・ストアにすべてのデータが格納される場合、ロード・バランシングを使用するデプロイメントを使用します。「構成1: 単純なロード・バランシング」を参照してください。

- データがパーティション化されている場合、またはデータベースのサイズが大きいので複数のデータ・ソースにパーティション化されるようにデータを分割する必要がある場合、分散を使用するデプロイメントを使用します。第3.3項「構成2: 単純な分散」を参照してください。

ロード・バランシングと分散を組み合せる、さらに複雑なデプロイメント・シナリオも定義できます。ロード・バランシングまたは分散のどちらが必要なのか、あるいは両方が必要なのかを検討する必要があります。

この後は、単純なロード・バランシングおよび単純な分散に加えて、次のデプロイメント例について説明します:

- たとえば、地理的に異なる場所にデータ・センターを配置する場合、ロード・バランシングされた2つのデータ・センターの間にフェイルオーバーをデプロイできます。第3.4項「構成3: データ・センター間のフェイルオーバー」を参照してください。

- 分散を使用し、さらにデータ・パーティションをレプリケートする場合、ロード・バランサにルーティングされる分散を使用するプロキシ・サーバーをデプロイできます。第3.5項「構成4: 分散とロード・バランシングの併用」を参照してください。

- 分散を使用し、データ・パーティションをレプリケートすると同時に、可用性とディザスタ・リカバリのためにパーティションを1つのデータ・センター内でレプリケートするだけでなく、地理的に異なる2つの場所にあるデータ・センター間でレプリケートする場合、第3.6項「構成5: 分散とデータ・センター間のフェイルオーバーの併用」と同様のアーキテクチャをデプロイできます。

分散を使用してグローバル索引カタログをデプロイメントに追加することによって、エントリを特定のパーティションにマップできます。これにより、ブロードキャストの使用を最小限に抑えることができます。グローバル索引カタログの構成の詳細は、第15.1.7項「コマンドラインを使用したグローバル索引の構成」を参照してください。

3.2 構成1: 単純なロード・バランシング

プロキシをデプロイしてロード・バランシングを実現する場合、プロキシが受信したリクエストはすべて、いずれかのリモートLDAPサーバーにルーティングされます。図3-1に示すように、リモートLDAPサーバーはレプリケートされるので、格納されるデータは同じです。サポートするリモートLDAPサーバーの数に制限はありません。

図3-1 単純なロード・バランシング

デプロイメントの際に設定されたロード・バランシング・アルゴリズムに基づいて、リクエストはどちらかのリモートLDAPサーバーにルーティングされます。

ロード・バランシング・アルゴリズムには、次の種類があります:

- failover

- generic

- optimal

- proportional

- saturation

- searchfilter

各種ロード・バランシング・アルゴリズムの詳細は、第11.1項「プロキシを使用したロード・バランシング」を参照してください。

このアルゴリズムは、クライアント接続アフィニティによりバイパスできます。クライアント接続アフィニティを設定した場合、プロキシは、最初のリクエストの処理ではロード・バランシング・アルゴリズムを使用しますが、それ以降のリクエストの処理では設定されているロード・バランシング・アルゴリズムを無視し、たとえば設定されているクライアント・アフィニティのタイプに応じて、同じクライアント接続上の新しい操作に同じルートを再利用しようとします。詳細は、第15.1.3.5.7項「クライアント接続アフィニティの設定」を参照してください。

ロード・バランシング・デプロイメントを使用する場合、データの高可用性およびリモートLDAPサーバーに適応した処理負荷が実現されるという利点があります。たとえば、構成されているリモートLDAPサーバーの1つに障害が発生した場合、ロード・バランシングによってリクエストは別のリモートLDAPサーバーにルーティングされます。この場合、障害が発生したことをクライアントが認識することはなく、サービスの中断も発生しません。

単純なロード・バランシング・デプロイメントは、プロキシをインストールする際に簡単に構成できます。

3.3 構成2: 単純な分散

プロキシをデプロイして単純な分散を実現する場合、データはパーティションに分割されます。図3-2に示すように、データの各パーティションは個別のリモートLDAPサーバーに保持されます。この図の「LDAP Server A...L」は、名前の先頭がAからLまでのユーザーのエントリが格納されるサーバーです。同様に、「LDAP Server M...Z」には、名前の先頭がMからZまでのユーザーのエントリが格納されます。プロキシが受信したリクエストはすべて、該当するデータが格納されるリモートLDAPサーバーにルーティングされます。

データがパーティション化されるリモートLDAPサーバーの数は、分割するデータベースのサイズによって決まります。図3-2は、2つのパーティションを使用する単純な分散アルゴリズムを示しますが、パーティションの数を増やした構成も可能です。

図3-2 単純な分散

デプロイメントの際に設定された分散アルゴリズムに基づいて、リクエストはどちらかのリモートLDAPサーバーにルーティングされます。

分散アルゴリズムには、次の種類があります:

- capacity

- numeric

- lexico

- dnpattern

各種分散アルゴリズムの詳細は、第11.2項「プロキシを使用したデータ分散」を参照してください。

分散を使用するデプロイメントの場合、1秒当たりの更新数をスケーリングできるという利点があります。分散を使用する場合、グローバル索引カタログを追加してブロードキャストの数を減らすことができます。グローバル索引カタログの詳細は、第15.1.7項「コマンドラインを使用したグローバル索引の構成」を参照してください。

単純な分散デプロイメントは、プロキシをインストールする際に簡単に構成できます。

3.4 構成3: データ・センター間のフェイルオーバー

データ・センター間にフェイルオーバーを構成することは、実質的にはプロキシ内に2レベルのロード・バランサをデプロイすることです。このデプロイメントでは、データ・センターがレプリケートされ、データ・センター内のリモートLDAPサーバーもレプリケートされます。このデプロイメントでは、フェイルオーバーまたは飽和のどちらかが、最初のロード・バランシング要素になります。次の例では、最初のロード・バランシング要素としてフェイルオーバー・アルゴリズムが選択されていることを前提としています。

図3-3に示すように、リクエストはすべて、フェイルオーバー・ロード・バランサによってメイン・ルート経由で2番目のロード・バランシング要素にルーティングされ、そこでData Center 1の内部にあるサーバーにリクエストが送信されます。この図の「LDAP Server A...L」は、名前の先頭がAからLまでのユーザーのエントリが格納されるサーバーです。Data Center 1が停止するか、またはパフォーマンスが低下した場合、トラフィックは、フェイルオーバー・ロード・バランサによってバックアップ・ルート経由でData Center 2の内部にあるサーバーにルーティングされます。

図3-3 データ・センター間のフェイルオーバー

設定されたロード・バランシング・アルゴリズムに基づいて、リクエストはデータ・センター内のリモートLDAPサーバーにルーティングされます。データ・センターごとに異なるロード・バランシング・アルゴリズムを使用できます。たとえば、ロード・バランシング・アルゴリズムとして、Data Center 1ではproportionalを設定し、Data Center 2ではsaturationを設定できます。

通常、このタイプのデプロイメントは、2つの地理的地域にデプロイする場合に使用します。このデプロイメントでは、リモートLDAPサーバーだけでなく、データ・センターもレプリケートされるので、単純なロード・バランシング・デプロイメントに高可用性が加わります。

通常、2つのデータ・センターは地理的に異なる2つの場所に配置します。この場合、一方の場所で問題が発生すると、もう一方の場所のデータ・センターがバックアップとして動作します。別の例として、最初のロード・バランサをsaturationと設定する場合を考えます。この場合、一方の地理的な場所(たとえば特定のタイムゾーン)にあるData Center 1が飽和状態になった場合、もう一方のデータ・センターが超過分のトラフィックを引き受けることができます。

各種ロード・バランシング・アルゴリズムの詳細は、「プロキシを使用したロード・バランシング」を参照してください。

この構成のデプロイの詳細は、「フェイルオーバー・ロード・バランシング」を参照してください。

3.5 構成4: 分散とロード・バランシングの併用

分散とロード・バランシングを併用するデプロイメントでは、データがパーティションに分割され、リモートLDAPサーバー上でデータがレプリケートされます。プロキシに送信されたリクエストは、まずデータが格納されているパーティションに分散され、次に設定されているロード・バランシング・アルゴリズムに応じていずれかのリモートLDAPサーバーにルーティングされます。パーティション化されたデータを保持するリモートLDAPサーバーは、レプリケートされます。

図3-4に示すように、プロキシはリクエストを受信すると、分散によって正しいパーティションに振り分けます。この図の「LDAP Server A...L」は、名前の先頭がAからLまでのユーザーのエントリが格納されるサーバーです。同様に、「LDAP Server M...Z」には、名前の先頭がMからZまでのユーザーのエントリが格納されます。たとえば、cnがたとえばGarryであるエントリに対するリクエストは、パーティション1のA..Lのデータを保持するサーバーに転送されます。さらに、ロード・バランサによって、レプリケートされているいずれかのリモートLDAPサーバーに転送されます。

図3-4 分散とロード・バランシングの併用

設定されたロード・バランシング・アルゴリズムに基づいて、リクエストはデータ・センター内のリモートLDAPサーバーにルーティングされます。各種ロード・バランシング・アルゴリズムの詳細は、第11.1項「プロキシを使用したロード・バランシング」を参照してください。

このデプロイメントには、データが分散されることにより更新が速いこと、およびデータの高可用性という利点があります。

各種分散アルゴリズムの詳細は、第11.2項「プロキシを使用したデータ分散」を参照してください。

各種ロード・バランシング・アルゴリズムの詳細は、第11.1項「プロキシを使用したロード・バランシング」を参照してください。

この構成のデプロイの詳細は、第11章「プロキシ機能の理解」を参照してください。

3.6 構成5: 分散とデータ・センター間のフェイルオーバーの併用

分散と2つのデータ・センターの間のフェイルオーバー・ロード・バランシングを併用するデプロイメントでは、データがパーティションに分割され、各パーティションはフェイルオーバー・ロード・バランシング・ルートによって管理されます。図3-5に示すように、パーティション化されたデータを保持するリモートLDAPサーバーが1つのデータ・センター内でレプリケートされるだけでなく、さらにデータ・センターがレプリケートされ、一方のデータ・センターがバックアップとして動作します。この図の「LDAP Server A...L」は、名前の先頭がAからLまでのユーザーのエントリが格納されるサーバーです。同様に、「LDAP Server M...Z」には、名前の先頭がMからZまでのユーザーのエントリが格納されます。

図3-5 分散とデータ・センター間のフェイルオーバーの併用

言い換えると、プロキシに送信されたリクエストは、まずデータが格納されているパーティションに分散されます。たとえば、cnがたとえばGarryであるエントリに対するリクエストは、パーティション1に転送されます。さらに、設定されているロード・バランシング・アルゴリズムに基づいて、フェイルオーバー・ロード・バランサによってメイン・ルート経由でA..Lのデータが格納されているいずれかのリモートLDAPサーバーに転送されます。

図3-5に示すデプロイメントでは、Data Center 2はバックアップとして動作し、Data Center 1で障害が発生した場合にのみ使用されます。ただし、これと同じデプロイメントを、フェイルオーバー・ロード・バランサではなく、saturationを使用するように構成できます。この場合、一方の地理的な場所(たとえば特定のタイムゾーン)にあるData Center 1が飽和状態になった場合、もう一方のデータ・センターが超過分のトラフィックを引き受けることができます。

このデプロイメントには、分散アルゴリズムを使用することにより読取りが速いことに加えて、リモートLDAPサーバーがレプリケートされ、1つのデータ・センターがバックアップとして動作するために高可用性が実現するという利点があります。

各種分散アルゴリズムの詳細は、第11.2項「プロキシを使用したデータ分散」を参照してください。

各種ロード・バランシング・アルゴリズムの詳細は、第11.1項「プロキシを使用したロード・バランシング」を参照してください。

この構成のデプロイの詳細は、第16.5項「データ・センター間のフェイルオーバーを使用した分散の構成」を参照してください。

3.7 構成6: エンタープライズ・ユーザー・セキュリティ

エンタープライズ・ユーザー・セキュリティ(EUS)のためにプロキシをデプロイする場合、構成の詳細はローカルのOracle Unified Directoryに格納され、リモートの外部LDAPディレクトリにはエンタープライズ・ユーザーとエンタープライズ・グループの詳細のみが格納されます。

図3-6に示すように、リモートの外部LDAPディレクトリには、エンタープライズ・ユーザーとエンタープライズ・グループの詳細のみが格納されます。

図3-6 プロキシ・エンタープライズ・ユーザー・セキュリティ

デプロイメントの際に設定されたロード・バランシング・アルゴリズムに基づいて、リクエストはどちらかのリモートLDAPサーバーにルーティングされます。

ロード・バランシング・アルゴリズムには、次の種類があります:

- failover

- optimal

- proportional

- saturation

各種ロード・バランシング・アルゴリズムの詳細は、第11.1項「プロキシを使用したロード・バランシング」を参照してください。

このプロキシ・デプロイメントを構成するには、次の手順に従います:

1. Oracle Fusion Middleware Oracle Unified Directoryインストレーション・ガイドのエンタープライズ・ユーザー・セキュリティの構成に関する項の説明に従って、プロキシ・サーバーを構成します。

2. 第25章「Oracleのエンタープライズ・ユーザー・セキュリティとの統合」の説明に従って、Oracle Unified Directoryとエンタープライズ・ユーザー・セキュリティを統合します。

3.8 レプリケートされる複数のプロキシ

シングル・ポイント障害を回避するには、デプロイメントに冗長性を持たせることを保証する必要があります。通常は、図3-7に示すように、サード・パーティ・ハードウェア・ロード・バランサをインストールすることによってそれを実現できます。

ハードウェア・ロード・バランサを使用すると、物理的に異なるマシンまたは地理的に異なる場所にある複数のプロキシ・インスタンスを管理できます。

図3-7 複数のプロキシ・インスタンス

グローバル索引カタログを使用する分散デプロイメントで複数のプロキシ・インスタンスを実行する場合、グローバル索引カタログをレプリケートする必要があります。グローバル索引カタログのレプリケートの詳細は、第15.1.7.2項「グローバル索引カタログのレプリケーション」を参照してください。

このプロキシ・デプロイメントを構成するには、Oracle Fusion Middleware Oracle Unified Directoryインストレーション・ガイドのプロキシ・サーバーの設定に関する項を参照してください。

第II部

Oracle Unified Directoryの概念およびアーキテクチャ

この部では、Oracle Unified Directoryの動作の詳細について説明します。この後の章では、Oracle Unified Directoryのアーキテクチャおよびそのアーキテクチャを構成する様々なコンポーネントについて説明します。

通常は、Oracle Unified Directoryを管理するためにそれらの概念をすべて詳細に理解する必要はありませんが、この後の章で説明する概要を理解することで、管理が容易になる可能性があります。

この部には次の章が含まれます:

- 第4章「Oracle Unified Directoryの概念およびアーキテクチャの理解」

- 第5章「Oracle Unified Directory高可用性デプロイメントの理解」

- 第6章「Oracle Unified Directoryレプリケーション・モデルの理解」

- 第7章「Oracle Unified Directory索引モデルの理解」

- 第8章「Oracle Unified Directoryのアクセス制御モデルの理解」

- 第9章「Oracle Unified Directoryスキーマ・モデルの理解」

- 第10章「rootユーザーと特権サブシステムの理解」

- 第11章「プロキシ機能の理解」

- 第12章「Oracle Unified Directoryのマッピングの理解」

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

Oracle Unified Directoryは、ストレージ、同期およびプロキシ機能を統合して、ビジネス・アプリケーションが動作するための重要な識別情報の管理を支援する、次世代の統合ディレクトリ・ソリューションです。これらの機能により、エンタープライズ・アーキテクチャの進化するニーズを満たすことができます。

この章では、Oracle Unified Directoryの基本コンポーネントの概念およびOracle Unified Directoryのアーキテクチャについて説明します。この章では、次のトピックを取り扱います:

- 第4.1項「Oracle Unified Directoryのコンポーネント」

- 第4.2項「Oracle Unified Directoryのアーキテクチャ」

4.1 Oracle Unified Directoryのコンポーネント

Oracle Unified Directoryには、ネットワーク・グループ、ワークフローおよびワークフロー要素の3つの主要コンポーネントが統合されています。この項では、各コンポーネントの概要について説明します。内容は次のとおりです:

- 第4.1.1項「ネットワーク・グループ」

- 第4.1.2項「ワークフロー」

- 第4.1.3項「ワークフロー要素」

4.1.1 ネットワーク・グループ

ネットワーク・グループは、Oracle Unified Directoryで処理するすべてのクライアント・リクエストのエントリ・ポイントです。

ネットワーク・グループは、クライアントの相互作用をすべて処理し、次の項目に基づいてローカル・バックエンド・ワークフローまたはプロキシ・ワークフローにディスパッチします:

- 条件
条件として、セキュリティ認証レベル、ポート番号、クライアントIPマスク、クライアント・バインドDN、バインドID、ドメイン名および他の条件を使用できます。

- サービス品質(QoS)ポリシー
QoSポリシーとして、LDAP参照ポリシー、リクエスト・フィルタリング、クライアント接続アフィニティおよびリソース制限を使用できます。

プロパティや優先度の異なる複数のネットワーク・グループを定義できます。ただし、着信クライアント接続をアタッチできるのは、一度に1つのネットワーク・グループのみです。着信クライアント接続は、ネットワーク・グループに定義されている条件にこの接続が準拠していると最初に判断されたネットワーク・グループにアタッチされます。

クライアント接続は、ネットワーク・グループのすべての条件に準拠していることが確認されるまで、優先度順に各ネットワーク・グループによって評価されます。図4-1に示すように、リクエストはまず優先度が最も高いネットワーク・グループNetwork Group 1に送信されます。Network Group 1は、そのリクエストが必要なすべての条件に一致するかどうかを評価します。すべての条件には一致しない場合、リクエストはリストの次のネットワーク・グループNetwork Group 2に転送されます。

リクエストがネットワーク・グループのすべてのプロパティに一致する場合、このネットワーク・グループは、そのQoSポリシーにクライアント接続が一致するかどうかを評価します。QoSポリシーに一致する場合、クライアント接続は関連付けられているワークフローにルーティングされます。

図4-1 ネットワーク・グループの選択

ネットワーク・グループには、それぞれが異なるネーミング・コンテキストに対応している1つ以上のワークフローを関連付けることができます。ワークフローの詳細は、第4.1.2項「ワークフロー」を参照してください。クライアント接続が、ネットワーク・グループの条件には一致しても、そのQoSポリシーには一致しない場合、接続はワークフローに転送されることも、次のネットワーク・グループに送信されることもありません。かわりに、エラーの原因になったQoSポリシーを示すエラーが返されます。

ネットワーク・グループにワークフローが関連付けられていない場合、リクエストは処理されません。かわりに、サーバーからNo such entryのようなエラー・メッセージが返されます。

ネットワーク・グループの管理の詳細は、第14.1.6項「dsconfigを使用したネットワーク・グループの構成」を参照してください。

例4-1 ネットワーク・グループの条件を使用した異なるワークフローへのルーティング

次のネットワーク・グループを使用するOracle Unified Directory構成を想定します:

- Network Group 1: 条件にはバインドDNとして**,dc=example,dc=comが設定されています。
このネットワーク・グループは、ネーミング・コンテキストdc=example,dc=comでWorkflow 1に関連付けられます。

- Network Group 2: 条件にはバインドDNとして**,dc=test,dc=comが設定されています。
このネットワーク・グループは、ネーミング・コンテキストdc=test,dc=comでWorkflow 2に関連付けられます。

バインドDNに応じて、検索はNetwork Group 1またはNetwork Group 2を経由してルーティングされます。たとえば、バインドDNがuid=user.1,dc=test,dc=comであるリクエストは、Network Group 1には受け入れられませんが、Network Group 2に転送されて、そこで受け入れられ、Workflow 2に転送されます。

例4-2 ネットワーク・グループのQoSポリシーを使用したリクエストのフィルタリング

次のネットワーク・グループを使用するOracle Unified Directory構成を想定します:

- Network Group 1: 条件にはバインドDNとして**,ou=admin,dc=example,dc=comが設定されています。
QoSポリシーには、リソース制限としてsize limit=0とtime limit=0が設定されています。したがって、adminグループには制限がありません。

このネットワーク・グループは、ネーミング・コンテキストdc=example,dc=comでWorkflow 1に関連付けられます。

- Network Group 2: 条件にはバインドDNとして**,dc=example,dc=comが設定されています。
QoSポリシーには、リソース制限としてsize limit=100とtime limit=30 sが設定されています。したがって、adminグループ以外のすべての接続には、使用リソースに制限が設定されます。

また、このネットワーク・グループは、ネーミング・コンテキストdc=example,dc=comでWorkflow 1に関連付けられます。

したがって、バインドDNがdc=example,dc=comであるかぎり、リクエストはWorkflow 1に転送されます。Network Group 2に設定されているQoSポリシーにより、admin以外の任意のユーザーには、Workflow 1に対する制限付きアクセスが付与されます。adminとしてバインドされている任意のユーザーは、Network Group 1経由でWorkflow 1にアクセスし、使用リソースに制限はありません。

4.1.2 ワークフロー

ワークフローは、ネーミング・コンテキスト(ベースDN)およびOracle Unified Directoryによる着信リクエストの処理方法を定義するワークフロー要素によって定義されます。ワークフローは、少なくとも1つのネットワーク・グループに登録される必要がありますが、複数のネットワーク・グループにアタッチできます。

1つのネットワーク・グループは、ワークフローのネーミング・コンテキストが異なる場合は複数のワークフローを指すことができます。一方、ネットワーク・グループのQoSポリシーが異なり、ワークフローのネーミング・コンテキストと同じである場合は、複数のネットワーク・グループが同一のワークフローを指すことができます。

例4-3 1つのネットワーク・グループから複数のワークフローへのルーティング

(Figure 4-1に示すように)次のネットワーク・グループを使用するOracle Unified Directory構成を想定します:

- Network Group 1: 条件にはバインドDNとして**,l=fr,dc=example,dc=comが設定されています。
このネットワーク・グループは、ネーミング・コンテキストl=fr,dc=oracle,dc=comでWorkflow 1に関連付けられます。

- Network Group 2: 条件にはバインドDNとして**,l=uk,dc=example,dc=comが設定されています。
このネットワーク・グループは、ネーミング・コンテキストl=uk,dc=example,dc=comでWorkflow 2に関連付けられます。

- Network Group 3: 条件にはバインドDNとして**,dc=example,dc=comが設定されています。
このネットワーク・グループは、ネーミング・コンテキストdc=example,dc=comでWorkflow 1とWorkflow 2に関連付けられます。

バインドDNが**,l=uk,dc=oracle,dc=comである検索はNetwork Group 2によって処理され、Workflow 2に送信されます。

バインドDNが**,dc=oracle,dc=comである検索はNetwork Group 3によって処理され、Workflow 1とWorkflow 2に送信されます。

4.1.3 ワークフロー要素

各ワークフローには、少なくとも1つのワークフロー要素が含まれます。ワークフロー要素は、ルーティング構造の一部です。

Oracle Unified Directoryは、次のような様々なタイプのワークフロー要素をサポートします:

- リーフ・ワークフロー要素: ローカル・バックエンド・ワークフロー要素とプロキシ・ワークフロー要素を構成します。

- ルーティング・ワークフロー要素: ロード・バランシング・ワークフロー要素と分散ワークフロー要素を構成します。

- 仮想ワークフロー要素: DN名前変更ワークフロー要素、RDN変更ワークフロー要素および変換ワークフロー要素を構成します。

- EUSワークフロー要素: エンタープライズ・ユーザー・セキュリティ(EUS)ワークフロー要素を構成します。

- EUSコンテキスト・ワークフロー要素: EUSコンテキスト・ワークフロー要素を構成します。

- LDIFワークフロー要素: LDIFローカル・バックエンド・ワークフロー要素を構成します。

- メモリー・バックエンド・ワークフロー要素: メモリー・ローカル・バックエンド・ワークフロー要素を構成します。

ディレクトリ・サーバーの場合、図4-2に示すように、ワークフロー要素はDBローカル・バックエンドです。

プロキシ・サーバーの場合、ワークフロー要素は、リクエストを特定のパスに沿ってルーティングするポインタとして動作するロード・バランシング・ワークフロー要素または分散ワークフロー要素にチェーンできます。プロキシ・ワークフロー要素により、リモート・データ・ソースに直接アクセスできます。

図4-2 ディレクトリ・サーバーに対するクライアント・リクエスト

Oracle Unified Directoryには、変更または削除が禁止されている事前構成済ワークフロー要素が多数存在します。

4.2 Oracle Unified Directoryのアーキテクチャ

このセクションでは、Oracle Unified Directoryの高レベルのアーキテクチャについて説明します。

図4-3に示すように、クライアント・リクエストは、データ・ソースに転送される前は、Oracle Unified Directoryによって管理されます。このシナリオには、たとえば、ng1、ng2およびng3の3つのネットワーク・グループが存在します。最初のネットワーク・グループであるng1には2つのワークフローが関連付けられ、ng3には1つのワークフローが関連付けられています。ワークフローは、接尾辞で定義されます。w1の接尾辞はou=Xであり、ワークフローは3つのワークフロー要素からなるツリーを指しています。ワークフロー要素のツリーにより、操作に適用される処理が決定します。

クライアント・リクエストは、次のパスをたどります:

1. リクエスト・ハンドラは着信LDAPリクエストをワーク・キューに追加し、ワーカー・スレッドがそこからリクエストを受信します。

2. この操作は、割り当てられているネットワーク・グループの条件に基づいて、特定のネットワーク・グループにルーティングされます。操作は、サーバー・プロファイル、ディレクトリ・サーバーまたはプロキシ・サーバーに関係なく、ネットワーク・グループのQoSポリシーに準拠している必要があります。

3. ネットワーク・グループは操作をワークフローに転送します。ワークフローには、ネーミング・コンテキストが定義されています。ワークフローのネーミング・コンテキストとリクエストのベースDNの一致に基づいてワークフローが決定されます。

4. ワークフローはそのワークフロー要素のツリーに操作を転送します。ツリーには、リクエストの処理方法が定義されています。ワークフロー要素のツリーの内容は、サーバー・プロファイルに応じて、次のようになります:

- ディレクトリ・サーバーの場合、ワークフロー要素を、ローカル・バックエンド・ワークフロー要素(ストレージ)としてのみ構成できます。

- プロキシ・サーバーの場合、ワークフロー要素を、分散ワークフロー要素、ロード・バランシング・ワークフロー要素、DN名前変更ワークフロー要素またはLDAPプロキシ・ワークフロー要素として構成できます。

5. リクエストに割り当てられている処理が完了すると、リクエストがデータ・ソースに送信されます。

図4-3 Oracle Unified Directoryコンポーネントの高レベルな表現

5 Oracle Unified Directory高可用性デプロイメントの理解

集中管理されているアイデンティティを使用して接続する企業および基幹アプリケーションが増えるにつれて、常時LDAPサービスを使用できるようにすることが欠かせなくなっています。高可用性とパフォーマンスは、すべてのエクストラネットとエンタープライズのデプロイメントの際立った特長になっています。

この章には次のトピックが含まれます:

- 第5.1項「高可用性とは」

- 第5.2項「可用性とシングル・ポイント障害」

- 第5.3項「冗長性を使用した高可用性の実現」

- 第5.4項「冗長性を使用して高可用性を実現するサンプル・トポロジ」

5.1 高可用性とは

高可用性は、ディレクトリ・サービスに関して、特定の測定期間中の合意した動作パフォーマンス・レベルを保証するためのシステム設計方法と関連する実装です。

合意するサービス・レベルは、組織ごとに異なります。サービス・レベルは、システムがアクセスされる時刻、メンテナンスのためにシステムを停止する可能性があるかどうか、および組織が負担するダウンタイムのコストなど、様々な要因にも依存します。この場合、障害またはダウンタイムは、システムが使用不可状態であり、合意したサービス・レベルを提供できない期間として定義されます。

Oracle Unified Directoryには、精巧で使いやすく、コスト効率に優れた高可用性機能が用意されており、ダウンタイムを解消し、システムの使用可能時間を最大化します。

5.2 可用性とシングル・ポイント障害

Oracle Unified Directoryの高可用性サービスを提供するデプロイメントでは、障害からリカバリしたり、合意したサービス・レベルを維持したりできます。高可用性デプロイメントでは、コンポーネントの障害は、個々のディレクトリ問合せには影響する可能性がありますが、その結果としてシステム全体に障害が発生することはありません。

シングル・ポイント障害(SPOF)とは、そこに障害が発生したときにシステム全体が使用不可または信頼できない状態になるシステム・コンポーネントを指します。高可用性デプロイメントを設計する際、潜在的なSPOFを特定し、それらを抑制する方法を調べます。

この項には次のトピックが含まれます:

- 第5.2.1項「SPOFのタイプ」

- 第5.2.2項「SPOFを抑制する一般的な手法 - 冗長性」

5.2.1 SPOFのタイプ

SPOFは、次の3つのカテゴリに分けることができます:

- 第5.2.1.1項「ハードウェア障害」

- 第5.2.1.2項「ソフトウェア障害」

5.2.1.1 ハードウェア障害

ハードウェアSPOFは、大きく次のカテゴリに分けることができます:

- ネットワークの障害

- ディレクトリ・サーバーまたはディレクトリ・プロキシ・サーバーが動作している物理サーバーの障害

- ハードウェア・ロード・バランサの障害

- ストレージ・サブシステムの障害

- 電源の障害

5.2.1.2 ソフトウェア障害

ディレクトリ・サーバーまたはプロキシ・サーバーの障害は、次のカテゴリに分けることができます:

- レスポンス時間の低下

- 書込みのオーバーロード

- ファイル・ディスクリプタが最大数に達した

- ファイル・システムが満杯になった

- 構成されているストレージが不足している

- 索引が多すぎる

- 読取りのオーバーロード

- キャッシュの問題

- CPUの制約

- レプリケーションの問題

- 同期外れ

- レプリケーションの伝播の遅延

- レプリケーション・フロー

- レプリケーションのオーバーロード

- 大量のデータに対するワイルドカード検索

5.2.2 SPOFを抑制する一般的な手法 - 冗長性

冗長性を実装することで、単一コンポーネントの障害がディレクトリ・サービス全体の障害を引き起こさないことを保証できます。冗長性には、冗長なソフトウェア・コンポーネントまたはハードウェア・コンポーネント、あるいはその両方を提供することが含まれます。この戦略の例では、レプリケートされる複数のディレクトリ・サーバー・インスタンスを別々のホストにデプロイするか、またはディレクトリ・サーバー・データのストレージとしてRedundant Array of Independent Disks (RAID)を使用するか、あるいはその両方を実行します。レプリケートされるディレクトリ・サーバーを使用する冗長性は、高可用性を実現する最も効率的な方法です。

5.3 冗長性を使用した高可用性の実現

ディレクトリ・サービスの信頼性と継続サービスを保証するには、システム障害発生時にシームレスに冗長なシステムに移行できる、高レベルのシステム可用性を維持する必要があります。

冗長性はディレクトリ・サーバーとプロキシ・サーバーの両方に適用され、次の影響を抑制します:

- ハードウェア障害。トラフィックを別のハードウェア・コンポーネントにリダイレクトできるため。

- ソフトウェア障害。体系的に障害が再発する可能性はありません。

冗長性によって、障害は次のように処理されます:

- 第5.3.1項「ハードウェア・レベルでの冗長性」

- 第5.3.2項「レプリケーションを使用するディレクトリ・サーバー・レベルでの冗長性」

- 第5.3.3項「冗長ソリューションの一部としてのプロキシ・サーバーの使用方法」

- 第5.3.4項「アプリケーションの分離を使用した高可用性の実現」

- 第5.3.5項「レプリケーション・ゲートウェイを使用した高可用性の実現」

5.3.1 ハードウェア・レベルでの冗長性

この項では、ハードウェア冗長性の概要について説明します。ハードウェア冗長性を使用した高可用性の実現については、多くの出版物で包括的に説明されています。特に、John Wiley & Sons, Incから出版されている『Blueprints for High Availability』を参照する必要があります。

ネットワーク・レベルの障害は、冗長なネットワーク・コンポーネントを用意することで抑制できます。デプロイメントを設計する際、次のものに対して冗長なコンポーネントを用意することを検討します:

- インターネット接続

- ネットワーク・インタフェース・カード

- ネットワーク・ケーブル

- ネットワーク・スイッチ

- ゲートウェイとルーター

SPOFとしてのハードウェア・ロード・バランサの影響は、アーキテクチャ内に冗長なハードウェア・ロード・バランサを追加することで抑制できます。

冗長なサーバー・コントローラを使用することによって、ストレージ・サブシステムのSPOFの影響を抑制できます。また、コントローラとストレージ・サブシステムの間の冗長なケーブル、冗長なストレージ・サブシステム・コントローラまたはRedundant Array of Independent Disksを使用することもできます。

電源が1つしかない場合、この電源を失うことでサービス全体が使用不可になる可能性があります。この状況を回避するには、可能であればハードウェアに冗長な電源を用意して、電源を分散することを検討します。電源のSPOFの影響を抑制する他の方法として、サージ・プロテクタ、複数の電力事業者、ローカル・バッテリ・バックアップおよび緊急ローカル発電機を使用することなどがあります。

たとえば、自然災害が特定の地理的地域を襲った場合、データ・センター全体で障害が発生する可能性があります。この場合、綿密に設計された複数のデータ・センターを使用するレプリケーション・トポロジを使用して、分散ディレクトリ・サービスが使用不可になることを防ぐことができます。詳細は、第5.4項「冗長性を使用して高可用性を実現するサンプル・トポロジ」を参照してください。

5.3.2 レプリケーションを使用するディレクトリ・サーバー・レベルでの冗長性

Oracle Unified Directoryサーバーに冗長性を実装する一般的な方法は、レプリケーションを使用することです。冗長ソリューションは通常、クラスタリング・ソリューションより低コストで実装しやすく、管理が容易です。これは、クラスタリング・モデルでは同じアプリケーション処理負荷を処理するために少なくとも2つのサーバーを構成し、一方のノードをアクティブで、もう一方のノードをパッシブでスタンバイさせて使用する必要があるからです。冗長ソリューションの一部としてのレプリケーションには、可用性以外に多数の機能があります。レプリケーションの主な利点は、複数サーバー間で読取りを分割できることですが、この利点は追加したサーバーを管理するタスクとのバランスを取る必要があります。レプリケーションは、読取り操作のスケーラビリティ、および正しく設計された場合には、一定の制限はありますが、書込み操作のスケーラビリティも提供します。レプリケーションの概念の概要は、第6章「Oracle Unified Directoryレプリケーション・モデルの理解」を参照してください。

第5.2.1.2項「ソフトウェア障害」で説明されているSPOFは、ディレクトリ・サーバーの冗長なインスタンスを用意することで抑制できます。この場合もレプリケーションが使用されます。レプリケーションは、冗長なサーバーが同期されること、およびダウンタイムなしでリクエストをルーティングできることを保証します。

レプリケーションは、1つのサーバーを失うことでディレクトリ・サービスが使用不可になることを防ぐために使用します。信頼できるレプリケーション・トポロジは、たとえサーバーに障害が発生した場合でも、データ・センター全体でクライアントが最新データを使用できることを保証します。最低でも、ローカル・ディレクトリ・ツリーを少なくとも1つのバックアップ・サーバーにレプリケートする必要があります。ディレクトリ・アーキテクトは、データの信頼性を最大化するために、物理的な場所ごとに3回レプリケートすることをお薦めします。データが少なくとも3回レプリケートされている場合、ディレクトリ・サーバーに障害が発生しても、構成は可用性が高く、障害から保護されている状態で維持されます。フォルト・トレランスのためにレプリケーションの回数を決定する際、ディレクトリで使用するハードウェアとネットワークの品質を検討します。ハードウェアの信頼性が低い場合、必要なバックアップ・サーバーの数は増えます。

Oracle Unified Directoryレプリケーション・モデルは、ゆるやかな一貫性を持つマルチマスター・モデルです。言い換えると、レプリケートされるトポロジのすべてのディレクトリ・サーバーが、読取り操作と書込み操作の両方を処理できます。レプリケーションの詳細は、第6章「Oracle Unified Directoryレプリケーション・モデルの理解」を参照してください。

レプリケーションを通常のデータ・バックアップ・ポリシーのかわりとして使用しないでください。レプリケーションは、所定のサービス・レベル合意の範囲内にサービスを維持する目的で設計されています。アプリケーションまたはユーザーによってディレクトリに格納された不正なデータから保護することが目的ではありません。ディレクトリ・データのバックアップの詳細は、第17.3項「データのバックアップおよびリストア」を参照してください。

想定されているサービス・レベル合意の範囲でディレクトリのデータを読み取る能力を維持するには、適切なロード・バランシング戦略を導入する必要があります。複数のレプリカ間で読取り負荷を分散するために、ソフトウェアとハードウェアの両方のロード・バランシング・ソリューションが存在します。これらのソリューションはそれぞれ、レプリカごとの状態を決定し、ロード・バランシング・トポロジに参加するかどうかを管理できます。これらのソリューションは、完全性と精度という点に違いが存在する可能性があります。

地理的に分散したサイト全体の書込みフェイルオーバーを維持するために、WAN経由の複数データ・センターのレプリケーションを使用できます。それには、各データ・センターに少なくとも2つのマスター・サーバーを設定し、それらのサーバーがWAN経由でフルメッシュされるように構成します。この戦略により、トポロジ内のどのマスターで障害が発生しても、サービスが失われることはありません。書込み可能サーバーが使用不可になった場合、書込み操作は代替サーバーにルーティングされる必要があります。

5.3.3 冗長ソリューションの一部としてのプロキシ・サーバーの使用方法

ディレクトリ・プロキシ・サーバーは、高可用性ディレクトリ・デプロイメントをサポートする目的で設計されています。プロキシは、レプリケートされる一連のディレクトリ・サーバー間で、自動ロード・バランシングおよび自動のフェイルオーバーとフェイルバックを提供します。トポロジ内で1つ以上のディレクトリ・サーバーが使用不可になった場合、負荷は残りのサーバー間で均等に分散されます。

プロキシ・サーバーは、複数のプロキシ・インスタンスを使用して冗長化することもできます。高可用性ディレクトリ・サービスを実現するもう1つの手法です。

ディレクトリ・プロキシ・サーバーはディレクトリ・サーバーを積極的に監視して、サーバーが引き続きオンラインであることを確認します。また、実行される各操作のステータスも調査します。すべてのサーバーのスループットとパフォーマンスが同等であるとはかぎりません。プライマリ・サーバーが使用不可になった場合、一時的にセカンダリ・サーバーにリダイレクトされたトラフィックは、プライマリ・サーバーが使用可能になるとすぐに、プライマリ・サーバーに戻されます。

データが分散されている場合、接続されていない複数のレプリケーション・トポロジを管理する必要があるので、管理が非常に複雑になります。さらに、ディレクトリ・プロキシ・サーバーは、ユーザー認可の管理をプロキシ認可制御に大きく依存しています。分散に関連するディレクトリ・サーバーごとに、固有の管理ユーザーを作成する必要があります。これらの管理ユーザーには、プロキシ・アクセス制御権限を付与する必要があります。

5.3.4 アプリケーションの分離を使用した高可用性の実現

ディレクトリ・プロキシ・サーバーを使用して、欠陥のあるクライアント・アプリケーションによる障害から、レプリケートされるディレクトリ・サービスを保護することもできます。可用性を高めるために、限られた数のマスターまたはレプリカが各アプリケーションに割り当てられます。

欠陥のあるアプリケーションが特定のアクションを実行すると、サーバーがシャットダウンされるとします。アプリケーションがその後に続く各レプリカにフェイルオーバーした場合、1つのアプリケーションの1つの問題が、レプリケートされるトポロジ全体に障害を引き起こす可能性があります。このようなシナリオを回避するために、各アプリケーションのフェイルオーバーとロード・バランシングの対象を限られた数のレプリカに制限できます。これにより、障害が発生する可能性があるのは限られた数のレプリカのみとなり、障害が他のアプリケーションに及ぼす影響も少なくなります。

5.3.5 レプリケーション・ゲートウェイを使用した高可用性の実現

レプリケーション・ゲートウェイは、Oracle Directory Server Enterprise EditionトポロジとOracle Unified Directoryトポロジの間で変更を伝播します。レプリケーション・ゲートウェイは、冗長なレプリケーション・ゲートウェイ・サーバーを使用して異種サーバーで行われた変更をレプリケーション・トポロジ全体に伝播できるようにすることで、高可用性デプロイメント・ソリューションを提供できるように設計されています。レプリケーション・ゲートウェイの詳細は、第1.4.2項「レプリケーション・ゲートウェイの役割」を参照してください。

5.4 冗長性を使用して高可用性を実現するサンプル・トポロジ

次のサンプル・トポロジは、冗長性とレプリケーションを使用して、障害発生時に継続サービスを提供する方法を示します:

- 第2章「ディレクトリ・サーバーを使用するデプロイメントの例」

- 第3章「プロキシ・サーバーを使用するデプロイメントの例」

- 第15.2.1項「ODSMを使用したロード・バランシングの構成」

- 第15.1.7.2項「グローバル索引カタログのレプリケーション」

6 Oracle Unified Directoryレプリケーション・モデルの理解

Oracle Unified Directoryレプリケーションは、ゆるやかな一貫性を持つマルチマスター・モデルを使用しています。レプリケーション・トポロジ内のディレクトリ・サーバーはすべて、読取り操作と書込み操作が可能です。

この後のアーキテクチャに関する各項は、開発者およびレプリケーション・メカニズムの仕組みに興味があるユーザーを対象として書かれています。レプリケーションを使用できるようになるためだけに、それらの各項を読む必要はありません。レプリケーションの構成と使用の詳細は、第26章「ディレクトリ・データのレプリケーション」を参照してください。

次の各項では、Oracle Unified Directoryレプリケーション機能のアーキテクチャについて説明します。

- 第6.1項「レプリケーション・アーキテクチャの概要」

- 第6.2項「レプリケーションの動作」

- 第6.3項「履歴情報と競合解消」

- 第6.4項「スキーマ・レプリケーション」

- 第6.5項「レプリケーション・ステータス」

- 第6.6項「レプリケーション・グループ」

- 第6.7項「保証レプリケーション」

- 第6.8項「部分レプリケーション」

6.1 レプリケーション・アーキテクチャの概要

Oracle Unified Directoryレプリケーション・モデルは、ゆるやかな一貫性を持つマルチマスター・モデルです。言い換えると、レプリケートされるトポロジのすべてのディレクトリ・サーバーが、読取り操作と書込み操作の両方を処理できます。

レプリケーションは、パブリッシュ・サブスクライブ・アーキテクチャを中心に構築されています。各ディレクトリ・サーバーは、中央サービスと通信し、自身の変更のパブリッシュおよび他のディレクトリ・サーバーの変更通知の受信を行うために中央サービスを使用します。この中央サービスは、レプリケーション・サービスと呼ばれます。

レプリケーション・サービスは、複数のホストで動作する複数のサーバー・インスタンスを使用することで、高可用性を持たせることができます。レプリケーション・アーキテクチャ内でレプリケーション・サービスを提供するサーバー・インスタンスは、レプリケーション・サーバーと呼ばれます。ディレクトリ・サービスを提供するサーバー・インスタンスは、ディレクトリ・サーバーと呼ばれます。

レプリケーション・セッションの参加者は、SSL証明書を使用してお互いを認証します。提示された証明書がADSトラスト・ストアに存在する場合、接続は許可されます。アクセス制御や権限は強制されません。

次の各項では、レプリケーション・アーキテクチャおよびそれを構成する様々な要素について説明します。

- 第6.1.1項「基本的なレプリケーション・アーキテクチャ」

- 第6.1.2項「レプリケーション・サーバー」

- 第6.1.3項「レプリケーション変更番号」

- 第6.1.4項「レプリケーション・サーバーの状態」

- 第6.1.5項「操作の依存性」

6.1.1 基本的なレプリケーション・アーキテクチャ

次の図は、基本的なレプリケーション・アーキテクチャを示します。

各ディレクトリ・サーバーは、起動時にレプリケーション・サーバーを1つ選択して接続します。ディレクトリ・サーバーは、処理したすべての変更をレプリケーション・サーバーに送信し、トポロジ内の他のサーバー上のすべての変更をレプリケーション・サーバー経由で受信します。各レプリケーション・サーバーは、トポロジ内の他のすべてのレプリケーション・サーバーに接続します。

レプリケーション・サーバーは、ディレクトリ・サーバーから変更を受信すると、その変更をトポロジ内の他のすべてのレプリケーション・サーバーに転送します。それらのレプリケーション・サーバーは、その変更を接続しているすべてのディレクトリ・サーバーに転送します。レプリケーション・サーバーは、別のレプリケーション・サーバーから変更を受信したとき、その変更を接続しているディレクトリ・サーバーには転送しますが、他のレプリケーション・サーバーには転送しません。ディレクトリ・サーバーが別のディレクトリ・サーバーに直接変更を送信することはありません。このアーキテクチャにより、複雑なネゴシエーションを行わなくても、すべての変更がすべてのサーバーに転送されることが保証されます。

すべての変更には、それを最初に処理したディレクトリ・サーバーにより、変更番号が割り当てられます。変更番号は、変更を処理するすべての過程を通じてその変更を識別するために使用されます。レプリケーション・サーバーは、変更発生時に接続されていなかったディレクトリ・サーバーまたは動作が遅れたために処理された変更をすべて受信することが一時的にできなくなったディレクトリ・サーバーに過去の変更を再送信できるように、永続記憶域に変更を保持します。詳細は、第6.1.3項「レプリケーション変更番号」を参照してください。

各ディレクトリ・サーバーの現在の更新状態は、ディレクトリ・サーバーが最後に処理した変更を記録することで管理されます。ディレクトリ・サーバーがレプリケーション・サーバーに接続すると、レプリケーション・サーバーはこの記録を使用して、更新リストからディレクトリ・サーバーに送信する最初の変更を特定します。

複数のディレクトリ・サーバーが同時に更新を処理できるので、あるディレクトリ・サーバー上の更新操作が、同じエントリに作用する別のディレクトリ・サーバー上の別の更新操作と競合する可能性があります。各ディレクトリ・サーバーが他のディレクトリ・サーバーから受信した操作をリプレイする際に競合を解消することにより、最終的にはすべてのディレクトリ・サーバーのデータが収束します。

競合は、変更の競合と呼ばれる競合する変更操作によって発生する可能性があります。また、名前の競合と呼ばれる、競合する追加、削除またはmodRDNの各操作によって発生する可能性もあります。ディレクトリ・サーバーは、一貫性のある方法で競合を解消するために、エントリごとに一連の変更履歴を保持します。この履歴は、履歴情報と呼ばれます。履歴情報は、変更が発生したエントリ内に操作属性として格納されます。詳細は、第6.3項「履歴情報と競合解消」を参照してください。

6.1.2 レプリケーション・サーバー

レプリケーション・サーバーは、次のタスクを実行します:

- ディレクトリ・サーバーからの接続の管理

- 他のレプリケーション・サーバーへの接続

- 他のレプリケーション・サーバーからの接続のリスニング

- ディレクトリ・サーバーからの変更の受信

- ディレクトリ・サーバーおよび他のレプリケーション・サーバーへの変更の転送

- 安定したストレージへの変更の保存(古い操作の切捨てが含まれます)

レプリケーション・サーバーは、ディレクトリ・サーバーと同じではありません。ただし、ディレクトリ・サーバーと同様、レプリケーション・サーバーは構成ファイルを使用し、オンラインで構成および監視でき、バックアップおよびリストアが可能です。そのため、レプリケーション・サーバーは、ディレクトリ・データを格納していなくても、常にLDAPサーバーまたはJMXサーバーです。

レプリケーションのためにディレクトリ・サーバー・インスタンスを構成すると、レプリケーション・サーバーは、自動作成なしを指定した場合を除いて、自動作成されます。レプリケーション・サーバーとディレクトリ・サーバーは、同一JVM内でも、別々のJVM内でも、動作できます。

小規模トポロジ(ディレクトリ・サーバーの数が最大4つ)では、各サーバーをディレクトリ・サーバー兼レプリケーション・サーバーとして構成することが合理的です。大規模トポロジ(ディレクトリ・サーバーの数が20を超えている)では、ディレクトリ・サーバー・インスタンスとレプリケーション・サーバー・インスタンスを別々のJVMに分けて、レプリケーション・サーバーの数を制限することをお薦めします。

この2つの極端なトポロジの中間の規模の場合は、要件に合せて最適な構成を決定できます。すべてのサーバーをディレクトリ・サーバー兼レプリケーション・サーバーとして動作させるほうが、一般にはトポロジが単純になり、管理しやすくなります。ディレクトリ・サーバーとレプリケーション・サーバーを分ける場合、ディレクトリ・サーバー・インスタンスはレプリケーション変更ログを保存する必要がないので必要なディスク容量が少なくなります。

6.1.3 レプリケーション変更番号

変更番号は、LDAPディレクトリ・サーバー上で行われた変更を一意に識別します。また、変更番号により、一貫した変更の順序が提供されます。変更番号順序は、競合の解消および転送された変更のリプレイ順の決定に使用されます。

変更番号は、次の要素で構成されています:

- タイムスタンプ(ミリ秒単位)。タイムスタンプは、システム時刻を使用して生成されます。変更番号は、サーバーによってすでに処理されているすべての変更番号よりも、生成される各変更番号のほうが必ず大きくなるように生成されます。変更番号が常に増加し続けることにより、それ以前に行われた操作に依存する操作が一貫して正しい順序でリプレイされることが保証されます。エントリの追加操作の直後に実行される変更操作は、それ以前の操作に依存する操作の例です。

- 順序番号。同じミリ秒内に発生した変更ごとに値が増える連番です。

- レプリカ識別子。トポロジ内の各レプリカに割り当てられる一意の整数識別子です。(レプリケーション・トポロジは、特定のデータ・セットのすべてのレプリカの集合です。たとえば、example.comのレプリケーション・トポロジは、ディレクトリ・サービス全体のdc=example,dc=com接尾辞のすべてのコピーである可能性があります。)
レプリカ識別子は、同じ識別子が異なる2つのサーバーによって異なる2つの変更に割り当てられることがないことを保証します。ディレクトリ・サーバーの将来のリリースでは、レプリカ識別子が自動的に割り当てられるアルゴリズムが使用される可能性があります。

6.1.4 レプリケーション・サーバーの状態

ディレクトリ・サーバーがレプリケーション・サーバーに接続すると、レプリケーション・サーバーは、ディレクトリ・サーバーがまだ参照していない変更を送信するために、ディレクトリ・サーバー・データがどの程度最新なのかを決定する必要があります。このディレクトリ・サーバーの「最新」状態は、レプリケーション・サーバー状態と呼ばれます。

あるサーバーが、別のリモート・サーバーからの比較的古い変更をまだ受信していないかもしれないのに、近くのサーバーからのそれより新しい変更をすでに参照して処理している可能性があります。そのため、レプリカ識別子を使用して、各レプリカで最後に処理された変更番号を記録することでサーバー状態を管理します。

管理者がサーバーを停止して再起動する可能性があるので、サーバー状態は安定したストレージに保存する必要があります。理想的なのは、ローカルな変更またはレプリケートによる変更が行われるたびにサーバー状態を保存することです。ただし、変更のたびにデータベースに情報を保存すると、かなりの量のオーバーヘッドが発生します。そのため、サーバー状態はメモリー内で維持し、定期的に、またはサーバーを正しくシャットダウンする際に、データベースに保存します。

強制終了またはクラッシュなど、突然の中断が発生した場合、処理済の変更の記録をサーバーが失う可能性があります。この場合、サーバーの再起動時に非一貫性を修正する必要がある可能性があります。クラッシュ・リカバリの管理方法の詳細は、第6.2.6項「ディレクトリ・サーバーのクラッシュ」を参照してください。

6.1.5 操作の依存性

ある操作を、別の操作が完了するまで、リプレイできない可能性があります。たとえば、同じエントリに対して追加操作の後に変更操作が行われた場合、サーバーは変更操作を開始する前に追加操作の完了を待機する必要があります。

このような依存性は非常にまれであり、一般には依存性が必要な操作は限られています。通常、操作は変更操作なので、依存性はありません。したがって、そのような場合、マルチCPUサーバーを使用して最適なパフォーマンスを得るには、操作を並行してリプレイする必要があります。

レプリケーション・モデルは、操作の依存性はまれであるという前提に基づいて構築されています。したがって、レプリケーション・メカニズムは、並行して操作をリプレイすることを試みて、操作のリプレイに失敗した場合のみ操作の依存性の処理に切り替えます。

6.2 レプリケーションの動作

次の各項では、レプリケーション・プロセスに関するメカニズムおよび特定の機能の実現方法について説明します。

- 第6.2.1項「レプリケーションの初期化」

- 第6.2.2項「ディレクトリ・サーバーの変更処理」

- 第6.2.3項「レプリケーション・サーバーの選択」

- 第6.2.4項「変更のリプレイ」

- 第6.2.5項「自動修復」

- 第6.2.6項「ディレクトリ・サーバーのクラッシュ」

- 第6.2.7項「レプリケーション・サーバーのクラッシュ」

6.2.1 レプリケーションの初期化

サーバーがレプリケートされたトポロジに参加するには、そのサーバーをデータで初期化する必要があります。すなわち、完全なデータ・セットをなんらかの方法でサーバーにコピーする必要があります。サーバーをデータで初期化する方法の詳細は、第26.4項「データによるレプリケート対象サーバーの初期化」を参照してください。

6.2.1.1 構成データの手動レプリケート

データのレプリケーションは自動実行されますが、構成のレプリケーションは手動でトリガーする必要があります。

Oracle Unified Directory構成は、ファイルinstance-path/config/oud.ldifで指定されています。この項では、レプリケーション元のインスタンスからレプリケーション先のインスタンスに手動でレプリケートする必要がある特定の構成属性をリストして説明します。

次の構成属性の値を移行できます:

- グローバル構成属性。書込み可能性モード、サイズ制限および時間制限など。

- セキュリティ構成属性。暗号化マネージャ、キー・マネージャ、信頼マネージャ、アイデンティティ・マッピングおよびSASLなど。

- 接続ハンドラ。

- パフォーマンス・チューニング属性。キャッシュ、スレッドおよび他のデータベース構成パラメータなど。

- レプリケーション構成属性。

- パスワード・ポリシー構成属性。

- プラグイン構成属性。

- 機能構成属性。アイデンティティ・マッピング、索引など。

6.2.2 ディレクトリ・サーバーの変更処理

ディレクトリ・サーバーで変更が発生すると、ディレクトリ・サーバー上のレプリケーション・コードが次のタスクを実行します:

- 変更番号の割当て

- 履歴情報の生成

- 変更のレプリケーション・サーバーへの転送

- サーバー状態の更新

履歴情報はエントリに格納されるので、サーバーがバックエンドに書き込む前に、操作に含まれている必要があります。サーバーは、履歴情報を生成する際に変更番号を使用します。したがって、変更番号は履歴情報の前に生成されます。変更番号と履歴情報の両方は、操作前フェーズの一部として実行されます。

操作は、操作をリクエストしたクライアント・アプリケーションに更新の確認が送信される前に、レプリケーション・サーバーに送信されます。これにより、同期した保証アプリケーション・モードを実装できます。詳細は、第6.7項「保証レプリケーション」を参照してください。したがって、確認は操作後フェーズの一部として送信されます。

変更は、変更番号で定義される順序で送信されます。正しい順序で送信することにより、レプリケーション・サーバーがすべての変更を他のディレクトリ・サーバーに送信することを保証できます。

ディレクトリ・サーバーはマルチスレッドで動作するので、同じ操作に対して、操作後プラグインが操作前プラグインと異なる順序で呼び出される可能性があります。レプリケーション・コードは、保留中の変更のリストを管理します。このリストには、開始されて変更番号は生成済ですが、まだレプリケーション・サーバーに送信されていない変更が含まれます。変更は、操作前フェーズで保留中の変更のリストに追加されます。また、レプリケーション・サーバーに送信されると、リストから削除されます。特定の操作が、その変更番号で定義される位置よりも早く操作後フェーズに到達した場合、その操作は、それより前の操作が送信されるまで待機した後で、レプリケーション・サーバーに送信されます。

操作がレプリケーション・サーバーに送信されると、サーバー状態が更新されます。詳細は、第6.1.4項「レプリケーション・サーバーの状態」を参照してください。

6.2.3 レプリケーション・サーバーの選択

ディレクトリ・サーバーが起動されたとき(または接続しているレプリケーション・サーバーが停止したとき)、ディレクトリ・サーバーは、変更をパブリッシュおよび受信するための適切なレプリケーション・サーバーを選択します。この項では、レプリケーション・サーバーの選択方法について説明します。

6.2.3.1 レプリケーション・サーバーの選択アルゴリズム

ディレクトリ・サーバーは、次の原則に従って、適切なレプリケーション・サーバーを選択します:

- フィルタリング。ディレクトリ・サーバーはまず、トポロジ内で構成されているすべてのレプリケーション・サーバーから、選択可能なレプリケーション・サーバーのリストを作成します。このリストは、次の条件に基づいて作成されます:

1. ディレクトリ・サーバーと同じグループID (または地理的識別子)を持つレプリケーション・サーバー

2. ディレクトリ・サーバーと同じ生成ID (初期データ・セット)を持つレプリケーション・サーバー

3. そのディレクトリ・サーバーで生成された最新の更新がすべて存在するレプリケーション・サーバー

4. ディレクトリ・サーバーと同じ仮想マシンで動作しているレプリケーション・サーバー

注意:

このリストの条件は、望ましい順序で並んでいます。したがって、たとえば、あるレプリケーション・サーバーがディレクトリ・サーバーと同じ生成ID (2番目の条件)を持っていても、同じグループID (1番目の条件)を持っていない場合、トポロジ内にディレクトリ・サーバーと同じグループIDを持つレプリケーション・サーバーが1つも存在しない場合を除いて、このレプリケーション・サーバーはリストに追加されません。

- ロード・バランシング。ディレクトリ・サーバーが選択可能なレプリケーション・サーバーのリストを編集する際、トポロジ内のすべてのレプリケーション・サーバーに負荷が分散されるようにレプリケーション・サーバーを選択します。この選択は、トポロジ内のレプリケーション・サーバーの重みに従って行われます。詳細は、第6.2.3.2項「レプリケーション・サーバーのロード・バランシング」を参照してください。

6.2.3.2 レプリケーション・サーバーのロード・バランシング

複数のディレクトリ・サーバーと複数のレプリケーション・サーバーからなる大規模なトポロジでは、あらかじめ定義された方法でディレクトリ・サーバーをレプリケーション・サーバーに分散させた方が効率的です。これは、レプリケーション・サーバーを異なるタイプの異なる能力を持つマシンで実行している場合に、特に重要です。予想されるマシンの全体的能力がレプリケーション・サーバー間で大幅に異なる場合は、その能力に従ってレプリケーション・サーバーに負荷を分散させることが有効です。

レプリケーション・サーバーごとに接続されるディレクトリ・サーバーの数が効率的に分散されるように、レプリケーション・サーバーに比例した重みを構成できます。レプリケーション・サーバーの重みは、整数(1..n)として定義されます。トポロジ内の各レプリケーション・サーバーのデフォルトの重みは1です。この重みは、トポロジ内の他のレプリケーション・サーバーの重みと比較する際にのみ意味を持ちます。

レプリケーション・サーバーの重みによって、トポロジ内に現在存在し、この特定のレプリケーション・サーバーに接続する必要があるディレクトリ・サーバーの比率が決まります。レプリケーション・サーバーの重みは、トポロジ内のすべてのレプリケーション・サーバーの予想される全体的能力の比率として構成します。たとえば、レプリケーション・サーバーAにレプリケーション・サーバーBの2倍の能力があると予想される場合、レプリケーション・サーバーAの重みはレプリケーション・サーバーBの重みの2倍である必要があります。

特定のレプリケーション・サーバーの重みは、nをそのレプリケーション・サーバーの重み、dをトポロジ内のすべてのレプリケーション・サーバーの重みの合計として、(n/d)で表すことができます。

レプリケーション・サーバーの重みの構成の詳細は、第26.3.12項「レプリケーション・サーバーの重みの構成」を参照してください。

6.2.4 変更のリプレイ

レプリケートされたディレクトリ・サーバーで変更をリプレイすることは、マルチコアおよびマルチCPUのシステムで効率的に実行されます。ディレクトリ・サーバーでは、レプリケーション・サーバーから送信された変更を、複数のスレッドが読み取ります。

操作をすぐにリプレイできるかどうかを判断するために、依存性情報を使用します。サーバーは、サーバー状態および現在の操作が依存する操作のリストをチェックして、それらの操作がリプレイ済かどうかを判断します。それらの操作がリプレイされていない場合、サーバーは、依存性操作を保持するキューに現在の操作を追加します。現在の操作をリプレイできる場合、サーバーは、レプリケーション・サーバーから送信された情報に基づいて内部操作を構築します。その後、サーバーは内部リプレイ操作を実行します。

レプリケーション・サーバーから送信された操作から構築された内部リプレイ操作は、それ以前の操作と競合する可能性があります。したがって、そのような内部操作は、常に発生元のディレクトリ・サーバーで実行したときと同じようにリプレイできるとはかぎりません。サーバーは、handleConflictResolutionフェーズを処理する際に競合をチェックします。

ほとんどの場合、内部リプレイ操作がそれ以前の操作と競合することはありません。その場合は、handleConflictResolutionフェーズでは何も実行しません。したがって、レプリケーション・コードはすぐに戻るように最適化されます。

競合が発生した場合、handleConflictResolutionコードは競合を解消するための適切なアクションを実行します。変更操作が競合する場合、handleConflictResolutionコードは、最新の変更が残るように変更操作を変更します。

競合解消の処理では、ローカル操作に関する履歴情報を更新します。それによって、この操作をコア・サーバーで処理できるようになります。最後に、操作が終了したら、サーバー状態を更新します。

操作が完了すると、その操作を処理しているサーバー・スレッドは、現在の操作の完了を待機している操作が依存性キューに存在するかどうかをチェックします。存在する場合、その操作はリプレイ可能なので、そのリプレイ・プロセスを開始します。存在しない場合、レプリケーション・サーバーをリスニングして、さらに操作が送信されるまで待機します。

6.2.5 自動修復

サーバーの同期を維持する処理が実行されていても、ディレクトリ・サーバーが一貫しないデータを示しはじめる可能性があります。これは、通常、次の状況で発生します:

- 格納されているデータがディスク・エラーによって損なわれた場合

- データ処理中にメモリー・エラーによりエラーが発生した場合

- ソフトウェアの不具合により不正なデータが発生したり変更が失われたりした場合

このような状況では、変更を記録してリプレイするだけでは、一貫しないデータを同期するには不十分です。

提供されている自動修復メカニズムは、エントリ内の履歴情報を使用して、一貫性のあるデータがどうあるべきかを判断します。その後、レプリケーション・メカニズムは、不正なデータが存在するか、またはデータが欠落しているディレクトリ・サーバー上でデータを修復します。自動修復メカニズムは、LDAPアプリケーションとして実装され、レプリケーション・サーバーが動作するホスト上で動作します。

自動修復アプリケーションは、様々なモードで実行できます。実行モードに応じて、次のタスクを実行します:

- サーバーが変更をリプレイしたときにエラーとして示された非一貫性を修復します。

- 管理者が検出した非一貫性を修復します。

- ディレクトリ・エントリを定期的にスキャンして非一貫性を検出して修復します。

注意:

ディレクトリ・サーバーの現在のリリースでは、自動修復メカニズムを手動で実行する必要があります。詳細は、第26.8項「レプリケーションの非一貫性の検出および解決」を参照してください。

6.2.6 ディレクトリ・サーバーのクラッシュ

ディレクトリ・サーバーがクラッシュした場合、レプリケーション・サーバーへの接続は切断されます。このとき、ディレクトリ・サーバーが処理して、自身のデータベースにコミットした最新の変更が、まだどのレプリケーション・サーバーにも送信されていない可能性があります。

そのため、ディレクトリ・サーバーが再起動したときに、その状態を、ディレクトリ・サーバーが接続するレプリケーション・サーバーで保持されているサーバー状態と比較する必要があります。ディレクトリ・サーバーは、変更が失われていて、まだレプリケーション・サーバーに送信されていないことを検出すると、履歴情報から仮の操作を構築します。そして、これらの仮の操作をレプリケーション・サーバーに送信します。

ローカルのサーバー状態は操作のたびに保存されるわけではないので、クラッシュ後にディレクトリ・サーバーに保持されているサーバー状態は信頼できません。かわりに、自身のサーバー更新状態を、履歴情報から再計算します。

6.2.7 レプリケーション・サーバーのクラッシュ

レプリケーション・サーバーがクラッシュした場合、ディレクトリ・サーバーはトポロジ内の別のレプリケーション・サーバーに接続します。そこで欠落している変更の有無をチェックして、必要に応じて再送信します。

6.3 履歴情報と競合解消

この項では、履歴情報を保持する方法およびレプリケーション競合を解消するために履歴情報を使用する方法について説明します。

- 第6.3.1項「レプリケーション競合とは」

- 第6.3.2項「変更の競合の解消」

- 第6.3.3項「名前の競合の解消」

- 第6.3.4項「履歴情報のパージ」

6.3.1 レプリケーション競合とは

競合は、1つ以上のエントリが複数のサーバー上で同時に更新され、それらの変更に互換性がないか、またはそれらの変更が更新の間に相互作用を引き起こす場合に発生します。競合が発生するのは、更新操作がレプリケーション・トポロジ内のすべてのレプリカで同時に実行されるわけではないためです。実際には、更新はまずあるサーバーで処理され、その後で他のサーバーにレプリケートされます。

次の例では、異なる2つのディレクトリ・サーバー上で同時に1つの属性が変更された場合に発生する競合について説明します。

読取りと書込みを行う2つのレプリカが存在するトポロジについて考えます。変更操作により、一方のサーバー上でエントリの姓を示すsn属性をSmithに変更します。その変更を処理するサーバーがもう一方のサーバーと同期する前に、もう一方のサーバー上でそのエントリのsn属性の値がJonesに置換されたとします。競合管理が行われていない場合、レプリケーションによって、現在値Jonesが保持されているサーバー上で、Smithへの変更がリプレイされます。同時に、レプリケーションによって、値Smithが保持されているサーバー上で、Jonesへの変更がリプレイされます。そのため、これらのサーバーは、変更されたエントリのsn属性の値として一貫しない値を保持することになります。

次のリストに、発生する可能性がある他の競合を示します。

- あるサーバー上でエントリが削除され、その属性値の1つが別のサーバー上で変更された場合

- あるサーバー上でエントリの名前が変更され、その属性値の1つが別のサーバー上で再変更された場合

- あるサーバー上でエントリの削除およびそれと同じ識別名(DN)を持つ別のエントリの追加が行われ、その属性値の1つが別のサーバー上で変更された場合

- 親エントリが削除され、別のサーバー上で追加操作または名前変更操作のどちらかによってそのエントリの子が作成された場合

- 同じDNを持つ異なる2つのエントリが異なる2つのサーバー上で同時に追加された場合

- 異なるサーバー上の単一値属性の値が異なる2つの値で同時に置換される場合

同じエントリの変更のみが含まれる競合は、変更の競合と呼ばれます。変更以外の操作が少なくとも1つ含まれる競合は、名前の競合と呼ばれます。

すべての変更の競合と大部分の名前の競合は、発生順に操作をリプレイすることで自動的に解消できます。ただし、次に示す名前の競合は、発生することはまれですが、自動的に解消することができません。

- 新しいエントリの追加または既存エントリの名前の変更によって、同じDNの2つのエントリが異なるサーバー上で同時に作成された場合。

- 親エントリの削除とその子の作成が同時に行われた場合。子エントリは、新しいエントリが追加されたときか、既存のエントリの名前が変更されたときに、作成される可能性があります。

6.3.2 変更の競合の解消

変更の競合は、変更操作でのみ発生します。

特定の一連の操作の結果を決定するために、操作はグローバルかつ論理的に順序付けされます。この順序を定義するために、変更番号を使用します。

レプリケーション競合の解消機能により、すべての操作が変更番号で定義された順序ですべての場所でリプレイされたかのように、すべてのサーバーが最終的に同じ状態に到達することが保証されます。このことは、変更が複数のサーバー上で異なる順序でリプレイされる可能性があっても、同じように成立します。snの値としてSmithとJonesが存在した前述の変更の競合の例では、1番目のサーバー上で値がSmithに設定された後に、2番目のサーバー上で値がJonesに設定されたと想定しています。結果的には、2番目のサーバー上でSmithに置換する変更がリプレイされた後であっても、両方のサーバー上の属性値がJonesになります。

各エントリの履歴情報は、現在の競合する操作の変更番号よりも新しい変更番号で、競合する操作がすでにリプレイされたかどうかをチェックするために保持されます。変更操作のたびに、履歴情報を使用して、まず競合が存在するかどうかをチェックし、存在する場合は操作の正しい結果を決定します。

変更の競合が発生した場合、サーバーは、現在の属性値を保持する必要があるかどうか、または変更を適用する必要があるかどうかを判断します。これを評価するには、現在の属性値のみでは不十分です。サーバーは、いつ(どの変更番号で)それ以前の変更が実行されたのかも確認します。したがって、履歴情報には、次の要素が含まれます:

- 属性が最後に削除された日付

- 特定の値が最後に追加された日付

- 特定の値が最後に削除された日付

属性が削除されるか、完全に置換された場合、それ以前の情報は必要なくなります。その時点で、それ以前の履歴情報は削除されます。

履歴情報に対して次の処理が行われます:

- ds-sync-hist属性に保存されます(この属性は管理者のみ参照可能です。)

- 通常の操作の場合に更新されます(ただし使用されません)

- レプリケートされた操作の場合に更新および使用されます。

競合解消は、操作のリプレイの際、handleConflictResolutionフェーズの操作前処理の後に実行されます。

競合解消は、modifyOperationのList<Modification>フィールドを変更して、エントリのユーザー属性に対して実際に行う必要がある変更と一致させ、履歴情報の格納に使用されるds-sync-hist属性を変更することによって実行します。

6.3.3 名前の競合の解消

名前の競合は、リプレイされた操作でのみ発生します。サーバーは、次の方法で名前の競合を解消します:

- 一意のIDを使用して、名前が変更されたエントリも含めて、エントリを識別します。

- まず各操作のリプレイを試みて、競合が発生した場合のみアクションを実行します。

- 操作前処理で、操作のリプレイ時に検出できなかった競合をチェックします。

- ツームストン・エントリ(削除マークが付けられていて、まだ削除されていないエントリ)は保持しません。

ディレクトリ・エントリは名前が変更される可能性があるので、DNはそのエントリの不変な値ではありません。したがって、DNを使用して、レプリケーションのためにエントリを識別することはできません。そのため、エントリの作成時に一意の不変な識別子が生成され、エントリの操作属性として追加されます。この一意のIDをDNのかわりに使用して、ディレクトリ・サーバーとレプリケーション・サーバーの間で送信される変更のエントリを識別します。

操作には、レプリケーション・コンテキストがアタッチされます。レプリケーション・コンテキストには、変更番号、エントリIDおよび親エントリIDなど、競合を解消するために必要なプライベート・レプリケーション情報が格納されています。

6.3.4 履歴情報のパージ

履歴情報は、サーバー・データベースに格納されます。したがって、履歴情報は、領域およびI/O帯域幅を消費し、キャッシュ効率を低下させます。履歴情報は、それより新しい変更がトポロジ内の他のすべてのサーバーによって確認されたらすぐに削除できます。

履歴情報が削除されるのは、次の場合です:

- エントリに対して新しい変更が実行されたとき。

- 定期的にトリガー可能なパージ・プロセスを使用する場合。パージ・プロセスにより空き領域は増えますが、パージ処理のために余分にCPUを消費します。そのため、パージ・プロセスは構成可能です。詳細は、第26.3.2項「レプリケーション・パージ遅延の変更」を参照してください。

6.4 スキーマ・レプリケーション

この項では、スキーマ・レプリケーション・アーキテクチャの詳細を理解する必要があるユーザー向けに、スキーマ・レプリケーションの実装方法について説明します。

スキーマには、ディレクトリ・サーバーに格納可能なエントリを記述します。スキーマ管理は、ディレクトリ・サービスの中核機能です。レプリケーションも、ディレクトリ・サービスの中心的機能であり、スケーラブルな高可用性サービスに必要不可欠です。

したがって、個々のディレクトリ・サーバーのスキーマに対してなんらかの変更が行われた場合、同一のサービスを提供するすべてのディレクトリ・サーバーに、その変更をレプリケートする必要があります。

スキーマ・レプリケーションは、次のいずれかの方法でスキーマが変更された場合に実行されます:

- サーバーがオンラインのときにcn=schema接尾辞が変更された場合

- サーバーがオンラインのときにファイルを使用して動的なスキーマ更新を実行する専用タスクが使用された場合

- サーバーがオフラインのときに基礎となるバックエンド・ファイルが直接変更された場合

一般に、スキーマ変更は、新しいアプリケーションまたは新しいタイプのデータをデプロイした場合にのみ発生します。したがって、スキーマの変更頻度は多くありません。そのため、スキーマ・レプリケーションの実装では、スケーラビリティよりも単純さが優先されます。

スキーマのレプリケーションはデフォルトで有効になっています。特定の場合に、複数のディレクトリ・サーバー上で、それらがデータをすべてまたは一部共有している場合でも、複数のスキーマを使用する必要がある場合があります。そのような場合は、スキーマ・レプリケーションを無効にするか、またはスキーマ・レプリケーションに参加する限られた数のサーバーのリストを指定することができます。詳細は、第26.6項「スキーマのレプリケーションの構成」を参照してください。

6.4.1 スキーマ・レプリケーション・アーキテクチャ

スキーマ・レプリケーション・アーキテクチャは、一般的なレプリケーション・アーキテクチャに基づいています。したがって、この項を読む前に、一般的なレプリケーション・アーキテクチャについて理解する必要があります。詳細は、第6.1項「レプリケーション・アーキテクチャの概要」を参照してください。

ディレクトリ・サーバーは、ローカル・スキーマに対する変更について、レプリケーション・サーバーに通知します。データ・レプリケーションの場合と同様に、レプリケーション・サーバーはスキーマ変更を他のレプリケーション・サーバーに伝播し、それらのサーバーは受信した変更をトポロジ内の他のディレクトリ・サーバー上でリプレイします。

スキーマ・レプリケーションは、任意のサブツリーに使用されるレプリケーション構成と同じ構成を共有します:

dn: cn=example,cn=domains,cn=Multimaster Synchronization,\
cn=Synchronization Providers,cn=config
objectClass: top
objectClass: ds-cfg-replication-domain
cn: example
ds-cfg-base-dn: cn=schema
ds-cfg-replication-server: <server1>:<port1>
ds-cfg-replication-server: <server2>:<port2>
ds-cfg-server-id: <unique-server-id>

スキーマ・レプリケーションは、次の点でデータ・レプリケーションと異なります:

- エントリの一意のID。エントリは名前が変更されたり削除されたりする可能性があるので、データ・レプリケーションには一意のIDが必要です。
スキーマの場合、エントリは1つのみであり、そのエントリを削除したり名前を変更したりすることはできません。したがって、スキーマ・エントリには、一意のIDとしてスキーマ・エントリのDNを使用します。

- 履歴情報。履歴情報は、エントリに対する変更の履歴を保存するために使用されます。この情報により、変更の競合を解消できます。
スキーマ・レプリケーションの場合、唯一可能な操作は値の追加と値の削除です。したがって、スキーマに対する変更の場合、履歴情報は保持されません。

- 永続サーバー状態。ディレクトリ・サーバーが起動すると、レプリケーション・プラグインがレプリケーション・サーバーとの接続を確立します。レプリケーション・サーバーは、変更ログで変更をチェックして、ディレクトリ・サーバーに適用されていない変更があれば、それを送信します。
レプリケーション・プラグインは、変更ログのチェックを開始する位置を知るために、サーバーを停止して起動しても残る情報を格納します。この永続情報は、レプリケーションのbase-dnエントリに格納されます。

スキーマ・バックエンドを使用すると、永続状態を格納するために使用される特定の操作属性ds-sync-stateを変更できます。

6.5 レプリケーション・ステータス

レプリケート対象トポロジ内の各レプリケート対象ドメインには、トポロジ内での接続状態や、トポロジ内で発生した変更の反映状況に応じて特定のレプリケーション・ステータスが設定されます。

ドメインのレプリケーション・ステータスを知ることで、レプリケートされるトポロジで次のことを実行できます:

- 保証レプリケーションの特定の側面の管理

- 特定の管理タスクの有効化

- レプリケーションの効果的な管理と監視

詳細は、第29.7項「レプリケートされたトポロジの監視」を参照してください。

次の各項では、レプリケートされるドメインの取りうる複数のステータスについて説明します。

- 第6.5.1項「レプリケーション・ステータスの定義」

- 第6.5.2項「低下ステータス」

- 第6.5.3項「完全更新ステータスと不正生成IDステータス」

6.5.1 レプリケーション・ステータスの定義

次のリストでは、レプリケーション・ドメインの取りうる各レプリケーション・ステータスについて説明します。

NOT_CONNECTED_STATUS

ローカルのレプリケートされるドメインは、どのレプリケーション・サーバーにも接続されていません。レプリケーション・サーバーへの接続が確立するまで、レプリケーションを実行できません。レプリケーション・サーバーに接続していない場合は、これが取りうる唯一のステータスです。

NORMAL_STATUS

ローカルのレプリケートされるドメインが、そのピアとほぼ同期しています(すなわち、レプリケーション・サーバーで更新を受信済です)。クライアントLDAPリクエストは正常に処理されています。

DEGRADED_STATUS

レプリケーション・サーバーがキューに追加した更新に対するローカルのレプリケートされるドメインの処理が遅すぎます。遅すぎるかどうかの判断基準は、低下ステータスのしきい値、すなわちレプリケーション・サーバーでそのディレクトリ・サーバーに対するキューに追加されている変更の数によって定義されます。このステータスの場合、ローカル・ディレクトリ・サーバーによる変更のリプレイの速度が低下している可能性があります。これは、保証アプリケーションに影響を及ぼす可能性があります。

FULL_UPDATE_STATUS

ローカルのレプリケートされるドメインが、現在オンライン完全更新を実行中です(言い換えると、ドメインがリモート・ディレクトリ・サーバーからエントリを受信中です)。ステータスが変更されて、ドメインが再びレプリケーションに参加できるようになるには、完全更新が完了する必要があります。

BAD_GEN_ID_STATUS

ローカルのレプリケートされるドメインに、接続しているレプリケーション・サーバーと同じ生成IDが存在しません。ローカル・ドメインがレプリケーション・サーバーと同じ生成IDを含むデータ・セットで初期化されるまで、レプリケーションを実行できません。ローカル・ドメインを初期化するには、オンライン完全更新、LDIFインポートまたはデータベースのバイナリ・コピーを実行して、ドメイン・エントリを保持します。

6.5.2 低下ステータス

変更のリプレイの速度が低下しているディレクトリ・サーバーには、DEGRADED_STATUSが割り当てられます。サーバーが遅すぎると見なされる段階は、低下ステータスのしきい値によって定義され、レプリケーション・サーバーでそのディレクトリ・サーバーに対するキューに追加されている更新の数に基づいて構成可能です。

低下ステータスのしきい値に達すると、ディレクトリ・サーバーに低下ステータスが割り当てられ、時間内に確認を送信できないと見なされます。このステータスのサーバーは、保証レプリケーションに影響を及ぼします。なぜなら、これ以降のレプリケーション・サーバーは、自身が確認を返す前に、このサーバーからの確認を待機しなくなるからです。

6.5.3 完全更新ステータスと不正生成IDステータス

低下ステータスが割り当てられたことは別にして、ディレクトリ・サーバーは、管理者がトポロジで次のいずれかのタスクを実行した場合、ステータスを変更できます:

- 完全更新。レプリケートされたドメインがトポロジ内の別のサーバーからオンラインで初期化された場合、そのドメインでのディレクトリ・サーバーのステータスはFULL_UPDATE_STATUSに変更されます。完全更新が完了すると、ディレクトリ・サーバーはトポロジへの接続を再初期化して、ステータスはNORMAL_STATUSにリセットされます。

- ローカルのインポートまたはリストア。レプリケートされたドメインがローカルのインポートまたはリストアの手順を使用して再初期化された場合、そのドメインでのディレクトリ・サーバーのステータスはNOT_CONNECTED_STATUSに変更されます。

- 生成IDのリセット。レプリケートされたドメインの生成IDが、接続したレプリケーション・サーバーの生成IDと異なる場合、ドメインにBAD_GEN_IDステータスが割り当てられます。オンラインの完全更新、ローカル・インポート、またはレプリケーション・サーバーと異なる生成IDを持つ一連のデータによるリストアの後に再接続が行われた場合も、このステータスがドメインに割り当てられる可能性があります。
それ以外に、ディレクトリ・サーバー上で生成IDリセット・タスクを実行することによって、トポロジ内のすべてのレプリケーション・サーバーの生成IDをリセットする必要がある場合もあります。これにより、トポロジ内のすべてのレプリケーション・サーバーのIDは、接続しているディレクトリ・サーバーのIDと異なる値になります。この場合は、ディレクトリ・サーバーにBAD_GEN_IDステータスが割り当てられます。

6.6 レプリケーション・グループ

レプリケーション・グループは、マルチデータ・センター・デプロイメントおよび障害回復シナリオをサポートする場合に設計します。レプリケーション・グループは、グループIDによって定義されます。グループIDは、ディレクトリ・サーバー上のレプリケートされるドメインに割り当てられる一意の数です(レプリケートされるドメインごとに1つのグループID)。グループIDは、レプリケーション・サーバーにも割り当てられます(レプリケーション・サーバー全体に対して1つのグループID)。

グループIDによって、ディレクトリ・サーバー・ドメインが利用可能なレプリケーション・サーバーに接続する方法が決まります。ディレクトリ・サーバーは、構成済のレプリケーション・サーバーのリストを参照して、自身のグループIDと同じグループIDを持つレプリケーション・サーバーに接続を試みます。ディレクトリ・サーバーは、互換性のあるグループIDを持つレプリケーション・サーバーが見つからない場合は、異なるグループIDを持つレプリケーション・サーバーに接続します。この選択プロセスの詳細は、次の項を参照してください。

レプリケーション・グループの構成方法は、第26.3.8項「レプリケーション・グループの構成」を参照してください。

注意:

保証レプリケーションは、グループ境界内で行われます。詳細は、第6.7項「保証レプリケーション」を参照してください。

6.7 保証レプリケーション

この後の項を読む前に、基本的なレプリケーションの概念について理解している必要があります。ディレクトリ・サーバーと対比してレプリケーション・サーバーがどのような存在であるかを認識し、レプリケートされるトポロジ内でのレプリケーション・サーバーの動作を理解する必要があります。該当しない場合は、少なくとも第6.1項「レプリケーション・アーキテクチャの概要」を読んで、ディレクトリ・サーバーでの通常のレプリケーションの動作について理解してください。

標準のレプリケートされるトポロジでは、変更は、他のレプリケートされるサーバーに対してベストエフォート・モードでリプレイされます。LDAPサーバー上で行われた変更は、トポロジ内の他のサーバー上で、できるかぎり速やかに、ただし非同期で、リプレイされます。これは、パフォーマンス面では好都合ですが、当初のLDAPクライアント・コールが完了するまでに他のサーバーに変更が伝播済になることは保証しません。

これは、一部のデプロイメントでは許容されます。すなわち、最初のサーバー上での変更からピア・サーバー上でのリプレイまでの時間が十分に短く、デプロイメントの用件を満たしている場合です。たとえば、国際組織が、様々な地理的な場所にまたがるレプリケートされるトポロジで従業員のユーザー・アカウントを格納するとします。新しい従業員が雇用され、そのアカウントが特定の場所の特定のLDAPサーバーで作成された場合、LDAPクライアント・コールが終了してから数ミリ秒後に他のLDAPサーバー上で作成がリプレイされることは許容される可能性があります。このユーザーが、ユーザー・アカウントが作成されて1秒以内に、他のいずれかのLDAPサーバーにアクセスするホスト・ログインを実行する可能性はほとんどありません。

一方で、レプリケーション・プロセスで同期の必要性が高い場合があります。特定のホストに障害が発生した場合、そのホストで行われたあらゆる変更がトポロジ内の他の場所に伝播済であることが不可欠な場合があります。また、デプロイメントによっては、変更のLDAPクライアント・コールがサーバーから戻った時点で、トポロジ内のすべてのピア・サーバーがその変更を受信済であることを保証する必要がある場合があります。トポロジ内の任意の場所からそのエントリを読み取る他のクライアントは、確実にその変更を取得します。

保証レプリケーションは、通常のレプリケーションの動作の同期性を高める方法です。この項では、保証レプリケーションの動作について、アーキテクチャの観点から説明します。保証レプリケーションの構成の詳細は、第26.3.9項「保証レプリケーションの構成」を参照してください。

次の項では、保証レプリケーションの実装について説明します:

- 第6.7.1項「保証レプリケーション・モード」

- 第6.7.2項「保証レプリケーションの接続アルゴリズム」

- 第6.7.3項「保証レプリケーションとレプリケーション・ステータス」

- 第6.7.4項「保証レプリケーションの監視」

6.7.1 保証レプリケーション・モード

ディレクトリ・サーバーは現在、必要な同期レベル、レプリケートされるトポロジの目的および許容されるパフォーマンスへの影響に応じて、2つの保証レプリケーション・モードをサポートしています。

- 第6.7.1.1項「セーフ・データ・モード」

- 第6.7.1.2項「セーフ読取りモード」

- 第6.7.1.3項「セーフ読取りモードとレプリケーション・グループ」

6.7.1.1 セーフ・データ・モード

セーフ・データ・モードでは、あらゆる変更は、LDAPクライアント・コールが戻る前に、トポロジ内の指定された数のサーバーに伝播されます。変更が行われたLDAPサーバーに障害が発生した場合、その変更が少なくとも指定された数のサーバーに伝播済であることは保証されます。

この指定されたサーバーの数(N)は、セーフ・データ・レベルを定義します。セーフ・データ・レベルに関して使用されるのは、レプリケーション・サーバーからの確認のみです。言い換えると、LDAPサーバーから送信された更新メッセージは、更新を開始したLDAPクライアント・コールから戻る前に、少なくともN (N>1)個のレプリケーション・サーバーによって確認される必要があります。

セーフ・データ・レベルが大きいほど、更新を受信済であることが保証されるマシンの数が増えて、その結果、データの信頼性が高くなります。ただし、セーフ・データ・レベルが増えるにつれて、LDAPクライアント・コールが戻る前に必要な確認の数が増えるので、全体的なパフォーマンスは低下します。

セーフ・データ・レベルは、ベスト・エフォート・モードで動作します。すなわち、セーフ・データ・レベルが3に設定され、トポロジ内で使用可能なレプリケーション・サーバーが一時的に2つになった場合、3番目(使用不可)のレプリケーション・サーバーから確認を受信することは、このサーバーが再度使用可能になるまで期待できません。

レプリケーション・グループを使用する場合、セーフ・データ・モードが影響を受けます。保証レプリケーションはグループ境界内で行われるので、グループIDが1のレプリケーション・サーバーは、同じグループIDを持つ他のレプリケーション・サーバーからの確認を待機して、異なるグループIDを持つレプリケーション・サーバーからの確認は待機しません。詳細は、第6.6項「レプリケーション・グループ」を参照してください。

注意:

現在のレプリケーションの実装では、setupコマンドとdsreplicationコマンドは、メイン・レプリケーション・サーバーがLDAPサーバーと同じVM (すなわち同じマシン)に物理的に存在するシナリオのみサポートします。ただし、レプリケーションの基礎設計では、信頼性を高めるためにレプリケーション・サーバーが異なるマシンで動作するデプロイメントをサポートしています。

このようなデプロイメントを構成できるのは、現在はdsconfigコマンドのみであり、setupコマンドとdsreplicationコマンドはサポートしていません。ただし、そのようなデプロイメントはフェイルオーバーと可用性に優れており、将来サポートされることが予定されています。そのようなデプロイメントでセーフ・データ・レベルを1に設定した場合(1つのレプリケーション・サーバーの確認のみを待機)、このレプリケーション・サーバーはLDAPサーバーとは別のマシン上で動作する必要があります。

例6-1 セーフ・データ・レベルが1の場合

セーフ・データ・レベルを1に設定すると、最初のレプリケーション・サーバーが、更新を受信してすぐにディレクトリ・サーバーに確認を返すことが保証されます。このレプリケーション・サーバーは、トポロジ内の他のレプリケーション・サーバーからの確認を待機しません。変更が別の(変更が行われたディレクトリ・サーバー以外の) 1つのサーバー上に存在することが保証されます。

この例を構成できるのは、dsconfigのみであり、setupコマンドまたはdsreplicationコマンドはサポートしていません。

例6-2 セーフ・データ・レベルが2の場合(RSとDSが異なるホスト上に存在)

セーフ・データ・レベルを2に設定すると、最初のレプリケーション・サーバーは、ディレクトリ・サーバーに確認を返す前に、1つのピア・レプリケーション・サーバーからの確認を待機することが保証されます。変更が別の(変更が行われたディレクトリ・サーバー以外の) 2つのサーバー上に存在することが保証されます。

この例を構成できるのは、dsconfigのみであり、setupコマンドまたはdsreplicationコマンドはサポートしていません。

例6-3 セーフ・データ・レベルが2の場合(RSとDSが同じホスト上に存在)

現在のレプリケーションの実装では、setupコマンドとdsreplicationコマンドは、レプリケーションがディレクトリ・サーバーと同じマシンに存在する構成のみサポートします。この実装では、変更が別の少なくとも1つのホストに送信されることを保証する必要がある場合、セーフ・データ・レベルを2に設定する必要があります。

6.7.1.2 セーフ読取りモード

セーフ読取りモードは、特定のディレクトリ・サーバー上で行われたあらゆる変更が、LDAPコールが戻る前に、トポロジ内の他のすべてのディレクトリ・サーバーに対してリプレイ済であることを保証します。このモードでは、別のLDAPクライアントがトポロジ内の別のディレクトリ・サーバー上で読取り操作を実行する場合、そのクライアントは直前に実行された変更を読み取ることが保証されます。セーフ読取りモードは、レプリケーションを構成できる最も同期性の高い方法です。ただし、このモードは、書込み時間という点で、パフォーマンスに及ぼす影響も最大です。

セーフ読取りモードに関して使用されるのは、トポロジ内のレプリケーション・サーバーではなく、LDAPサーバーからの確認です。ディレクトリ・サーバー上で変更が行われると、対応するレプリケーション・サーバーに更新が送信されます。このレプリケーション・サーバーは、トポロジ内の他のレプリケーション・サーバーに更新を転送します。これらのレプリケーション・サーバーは、変更が転送されたすべてのディレクトリ・サーバー上で変更がリプレイされたことの確認を待機します。トポロジ内のすべてのディレクトリ・サーバーで変更がリプレイされると、レプリケーション・サーバーは最初のレプリケーション・サーバーに確認を送信し、このサーバーは当初のディレクトリ・サーバーに確認を送信します。

最初のレプリケーション・サーバーは、他に直接接続しているディレクトリ・サーバーが存在する場合は、当初のディレクトリ・サーバーに確認を送信する前に、それらからの確認も待機します。当初のディレクトリ・サーバーがレプリケーション・サーバーから確認を受信した場合のみ、最後にLDAPクライアントに操作のコールの終了を返します。

この時点で、トポロジ内のすべてのディレクトリ・サーバーに変更が存在しています。したがって、LDAPクライアントが任意のディレクトリ・サーバーからデータを読み取った場合、確実に変更を取得しています。

6.7.1.3 セーフ読取りモードとレプリケーション・グループ

レプリケーション・グループは、マルチデータ・センターのレプリケーションと高可用性をサポートします。レプリケーション・グループの詳細は、第6.6項「レプリケーション・グループ」を参照してください。保証レプリケーションを使用する場合、レプリケーション・グループを使用すると、一連のディレクトリ・サーバーがセーフ読取りモードで連携して動作できます。同期を取って連携して動作するディレクトリ・サーバーはすべて、同じグループIDを持つ必要があります。このグループIDは、同期したトポロジ内で動作するすべてのレプリケーション・サーバーにも割り当てられる必要があります。保証レプリケーションは、グループ境界内で行われます。

特定のグループID (N)を持つディレクトリ・サーバーで変更が行われた場合、グループIDがNである他のすべてのディレクトリ・サーバーが変更の確認を返す前に、LDAPコールが戻ることはありません。

レプリケーション・グループを使用すると、セーフ読取りモードを使用するレプリケートされるトポロジの柔軟性が高まります。

- 単一データ・センター・デプロイメントでは、完全に同期する必要があるディレクトリ・サーバーのサブセットを定義できます。同じグループIDを持つディレクトリ・サーバーのみが、同じグループIDを持つピアからの確認を待機します。レプリケーション・サーバーはすべて、同じグループIDを持っています。

- マルチデータ・センター・デプロイメントでは、1つのデータ・センター内のすべてのディレクトリ・サーバーが完全に同期するように指定できます。ディレクトリ・サーバーは、LDAPコールが戻る前に、同一データ・センター内に存在するピアからの確認のみ待機します。確認を待機するのは、ディレクトリ・サーバーが同じグループIDを持つレプリケーション・サーバーに接続している場合のみです。

例6-4 1つのグループが存在する単一データ・センター内のセーフ読取りモード

次の図は、すべてのノードが同一データ・センター内に存在し、同一レプリケーション・グループの一部であるデプロイメントを示します。各ディレクトリ・サーバーと各レプリケーション・サーバーは、同一グループIDを持っています。変更は、LDAPクライアント・コールが戻る前に、トポロジ内のすべてのディレクトリ・サーバーでリプレイされる必要があります。その後は、トポロジ内のどのディレクトリ・サーバーのLDAP読取り操作でも、前の変更が読み取られることが保証されます。

このようなシナリオは、たとえば、レプリケートされるディレクトリ・サーバー・プールの前にLDAPロード・バランサが存在する場合に便利です。ロード・バランサがLDAP変更をリダイレクトするディレクトリ・サーバーを判断することは不可能なので、その後の読取り操作は、必ずしも変更が行われたディレクトリ・サーバーにはルーティングされません。この場合、LDAPクライアント・コールが戻る前に、トポロジ内のすべてのサーバー上で変更を行うことが不可欠です。

例6-5 複数のグループが存在する単一データ・センター内のセーフ読取りモード

次の図は、すべてのノードが同一データ・センター内に存在しますが、ディレクトリ・サーバーのサブセットでのみ保証レプリケーションが構成されているデプロイメントを示します。サーバーのこのサブセットはレプリケーション・グループを構成し、各サーバーに同一グループID (1)が割り当てられます。レプリケーション・グループ内のいずれかのディレクトリ・サーバーで変更が行われた場合、当初のLDAPコールがクライアントに戻る前に、グループ内のすべてのディレクトリ・サーバーからの確認を受信する必要があります。トポロジ内のそれ以外のディレクトリ・サーバーは変更のリプレイを続行しますが、それらからの確認を、LDAPコールが戻る前に受信する必要はありません。グループ外のいずれかのサーバーで変更が行われた場合は、LDAPコールがクライアントに戻る前に、他のディレクトリ・サーバーからの確認を受信する必要はありません。

この例では、レプリケーション・グループに属さないディレクトリ・サーバーに接続しているレプリケーション・サーバーにも、グループIDとして1が割り当てられています。この構成では、別のレプリケーション・サーバーがオフラインになった場合のフェイルオーバーが保証されます。この場合、レプリケーション・グループ内のディレクトリ・サーバーがこの特定のレプリケーション・サーバーに接続している場合は、保証レプリケーションは依然として動作します。フェイルオーバーが動作するには、グループ内のディレクトリ・サーバーがいずれ接続する可能性があるレプリケーション・サーバーが存在する場合は、それにも同じグループIDを割り当てる必要があります。

例6-6 マルチデータ・センター・デプロイメント内のセーフ読取りモード

次の図は、2つの(異なる地理的な場所にある)データ・センターで構成されるデプロイメントを示します。各データ・センター内には、ローカルにセーフ読取りモードが構成されています。同一データ・センター内のすべてのディレクトリ・サーバーとレプリケーション・サーバーには、同じグループID (1番目のデータ・センターでは1、2番目のデータ・センターでは2)が割り当てられています。同一データ・センター内のディレクトリ・サーバーは、非常に厳しく一貫して同期を取って動作しています。ディレクトリ・サーバー上で変更が行われた場合、LDAPクライアント・コールが戻る前に、同じデータ・センター内のすべてのディレクトリ・サーバー上で変更がリプレイされ、確認を受信する必要があります。

この例では、データは2つのデータ・センター間で同期されますが、特定のディレクトリ・サーバー上で行われた変更は、すぐに同じデータ・センター内の他のすべてのディレクトリ・サーバーで参照できるようになります。このシナリオは、データ・センターのディレクトリ・サーバーの前にLDAPロード・バランサが存在する場合に便利です。リモート・データ・センターのサーバーからの確認は必要ないので、書込みに関してパフォーマンスにそれほど大きな影響はありません。

このシナリオでは、レプリケーション・サーバーのグループIDが重要です。グループIDがNのディレクトリ・サーバーから変更を受信した場合、レプリケーション・サーバーはそのグループIDとNを比較して、次のアクションを実行します:

- レプリケーション・サーバーが同じグループID (N)を持っている場合、直接接続しているすべてのレプリケーション・サーバーとディレクトリ・サーバーに変更を転送します。ただし、最初のディレクトリ・サーバーに自身の確認を送信する前に待機するのは、同じグループID (N)を持つサーバーからの確認のみです。

- レプリケーション・サーバーが異なるグループIDを持っている場合、すべてのレプリケーション・サーバーとディレクトリ・サーバーに変更を転送しますが、確認は一切待機しません。

6.7.2 保証レプリケーションの接続アルゴリズム

これまでの項で説明したシナリオを実装する際、トポロジ内のディレクトリ・サーバーは、次のアルゴリズムを使用して、接続する必要があるレプリケーション・サーバーを選択します:

1. 構成されているレプリケーション・サーバーのリストの各レプリケーション・サーバーに接続して、そのサーバー状態とグループIDを取得します。

2. ディレクトリ・サーバー上の最新の変更を保持し、ディレクトリ・サーバーと同じグループIDを持つレプリケーション・サーバーのリストから、トポロジ内の他のディレクトリ・サーバーからの更新を最も多く保持しているレプリケーション・サーバーを選択します。ディレクトリ・サーバーと同じグループIDを持つレプリケーション・サーバーが1つも存在しない場合は、最新の内容を持つレプリケーション・サーバーを選択します。

このアルゴリズムにより、ディレクトリ・サーバーと同じグループIDを持つレプリケーション・サーバーに高い優先度が割り当てられることが保証されます。したがって、ディレクトリ・サーバーは、同じデータ・センター内に存在するレプリケーション・サーバーを優先します。

(同じデータ・センター内で)同じグループIDを持つレプリケーション・サーバーに接続することにより、セーフ読取りモード機能が提供されます。異なるグループIDを持つレプリケーション・サーバーに接続することにより、(ローカル・データ・センター内のすべてのレプリケーション・サーバーで障害が発生した場合の)もう1つのデータ・センターへのフェイルオーバーが提供されます。この場合、更新メッセージを異なるグループIDを持つレプリケーション・サーバーに送信しても、確認は要求されないので、セーフ読取りモードは無効になります。レプリケーションは続行されますが、低下モードになります。(すなわち、構成の際に要求されたセーフ読取りモードは適用されません。)

正常なレプリケーションに戻すために、ディレクトリ・サーバーは定期的に構成リストをポーリングして、同じグループIDを持つレプリケーション・サーバーの出現をチェックします。ディレクトリ・サーバーは、同じグループIDを持つレプリケーション・サーバーが使用可能になったことを検出すると、現在のレプリケーション・サーバー(グループIDが異なる)を切断して、検出した同じグループIDを持つレプリケーション・サーバーに再接続します。これにより、セーフ読取りモードが再び有効になり、レプリケーションは構成されたモードに戻ります。

6.7.3 保証レプリケーションとレプリケーション・ステータス

レプリケーション・サーバーが、トポロジ内で行われた全体的な更新に関して同期外れになっているディレクトリ・サーバーを検出した場合、そのディレクトリ・サーバーは低下ステータスであると見なされます。同期外れのディレクトリ・サーバーは、タイムアウトにならないよう時間内にレプリケーション・サーバーに期待されている確認を送信することはほぼ不可能です。したがって、このサーバーは、保持する更新が許容できるレベルに達するまで、低下ステータスになります。低下ステータスのディレクトリ・サーバーは、正常ステータスに戻るまでの間、レプリケーション・サーバーに確認を送信することは期待されません。

低下ステータスのディレクトリ・サーバーは確認を送信できないので、セーフ読取りモードでのLDAP操作の同期は保証できません。言い換えると、このディレクトリ・サーバーから読み取ったデータには、トポロジ内の別のディレクトリ・サーバーで行われた変更が含まれていない可能性があります。

詳細は、第6.5.1項「レプリケーション・ステータスの定義」を参照してください。

6.7.4 保証レプリケーションの監視

保証レプリケーション・メカニズムには、メカニズムの正常動作を監視するための様々な属性が定義されています。次の表は、トポロジ内のディレクトリ・サーバーとレプリケーション・サーバーで定義されている監視属性を示します。

これらの属性は、ディレクトリ・サーバーの場合は、レプリケートされているDNのmonitorエントリの下にあります。たとえば、レプリケートされるドメインdc=example,dc=comに関する監視情報は、監視エントリcn=Replication Domain,dc=example,dc=com,server-id,cn=monitorの下にあります。

レプリケーション・サーバーの場合は、保証レプリケーションに関する監視情報が接続ごとに存在します。監視属性は、現在のレプリケーション・サーバーに接続しているディレクトリ・サーバーまたはレプリケーション・サーバーの監視エントリに存在します。たとえば、特定のレプリケーション・サーバーでは、接続しているディレクトリ・サーバーに関する監視情報は、監視エントリcn=Directory Server dc=example,dc=com ds-host,server-id,cn=monitorの下にあります。接続しているレプリケーション・サーバーに関する監視情報は、監視エントリcn=Remote Replication Server dc=example,dc=com repl-server-host:repl-port,server-id,cn=monitorの下にあります。

表6-1 ディレクトリ・サーバーの監視属性

属性名

属性のタイプ

説明

assured-sr-sent-updates

整数(0..N)

保証レプリケーションのセーフ読取りモードで送信した更新の数。

assured-sr-acknowledged-updates

整数(0..N)

保証レプリケーションのセーフ読取りモードで送信し、正常に確認した更新の数。

assured-sr-not-acknowledged-updates

整数(0..N)

保証レプリケーションのセーフ読取りモードで送信し、(タイムアウト、不正なステータスまたはリプレイ時のエラーのいずれかの理由で)正常に確認していない更新の数。

assured-sr-timeout-updates

整数(0..N)

保証レプリケーションのセーフ読取りモードで送信し、タイムアウトが理由で正常に確認していない更新の数。

assured-sr-wrong-status-updates

整数(0..N)

保証レプリケーションのセーフ読取りモードで送信し、不正なステータスが理由で正常に確認していない更新の数。

assured-sr-replay-error-updates

整数(0..N)

保証レプリケーションのセーフ読取りモードで送信し、リプレイ時のエラーが理由で正常に確認していない更新の数。

assured-sr-server-not-acknowledged-updates

文字列

複数の値を設定可能: 保証レプリケーションのセーフ読取りモードで送信し、特定のサーバー(ディレクトリ・サーバーまたはレプリケーション・サーバー)について(タイムアウト、不正なステータスまたはリプレイ時のエラーのいずれかの理由で)正常に確認していない更新の数。文字列形式: サーバーid:失敗した更新の数。

assured-sr-received-updates

整数(0..N)

保証レプリケーションのセーフ読取りモードで受信した更新の数。

assured-sr-received-updates-acked

整数(0..N)

保証レプリケーションのセーフ読取りモードで受信し、エラーなしで確認した更新の数。

assured-sr-received-updates-not-acked

整数(0..N)

保証レプリケーションのセーフ読取りモードで受信し、エラーありで確認した更新の数。

assured-sd-sent-updates

整数(0..N)

保証レプリケーションのセーフ・データ・モードで送信した更新の数。

assured-sd-acknowledged-updates

整数(0..N)

保証レプリケーションのセーフ・データ・モードで送信し、正常に確認した更新の数。

assured-sd-timeout-updates

整数(0..N)

保証レプリケーションのセーフ・データ・モードで送信し、タイムアウトが理由で正常に確認していない更新の数。

assured-sd-server-timeout-updates

文字列

複数の値を設定可能: 保証レプリケーションのセーフ・データ・モードで送信し、特定のRSについて(タイムアウトが理由で)正常に確認していない更新の数。文字列形式: サーバーid:失敗した更新の数。

表6-2 レプリケーション・サーバーの監視属性

属性名

属性のタイプ

説明

assured-sr-received-updates

整数(0..N)

保証レプリケーションのセーフ読取りモードでリモート・サーバーから受信した更新の数。

assured-sr-received-updates-timeout

整数(0..N)

保証レプリケーションのセーフ読取りモードでリモート・サーバーから受信し、転送する際にタイムアウトした更新の数。

assured-sr-sent-updates

整数(0..N)

保証レプリケーションのセーフ読取りモードでリモート・サーバーに送信した更新の数。

assured-sr-sent-updates-timeout

整数(0..N)

保証レプリケーションのセーフ読取りモードでリモート・サーバーに送信し、タイムアウトした更新の数。

assured-sd-received-updates

整数(0..N)

保証レプリケーションのセーフ・データでリモート・サーバーから受信した更新の数。

assured-sd-received-updates-timeout

整数(0..N)

保証レプリケーションのセーフ日付モードでリモート・サーバーから受信し、転送する際にタイムアウトした更新の数。リモート・サーバーがレプリケーション・サーバーの場合、この属性に意味はありません。

assured-sd-sent-updates

整数(0..N)

保証レプリケーションのセーフ・データ・モードでリモート・サーバーに送信した更新の数。リモート・サーバーがディレクトリ・サーバーの場合、この属性に意味はありません。

assured-sd-sent-updates-timeout

整数(0..N)

保証レプリケーションのセーフ・データ・モードでリモート・サーバーに送信し、タイムアウトした更新の数。リモート・サーバーがディレクトリ・サーバーの場合、この属性に意味はありません。

6.8 部分レプリケーション

部分レプリケーション機能を使用して、トポロジ内の特定のサーバーで変更操作がリプレイされるときに、特定の属性を除外できます。部分レプリケーションの構成の詳細は、第26.3.10項「部分レプリケーションの構成」を参照してください。

この項では、部分レプリケーション・メカニズムのアーキテクチャについて説明します。内容は次のとおりです:

- 第6.8.1項「部分データ・セットの識別」

- 第6.8.2項「部分レプリケーションのフィルタリング」

- 第6.8.3項「部分レプリケーションとローカル操作」

6.8.1 部分データ・セットの識別

部分データ・セットは、レプリケートされるドメインのルート・エントリに格納される次の操作属性によって特定されます:

- ds-sync-fractional-exclude

- ds-sync-fractional-include

これらの属性の構文と意味は対応する構成属性と同じです。詳細は、第26.3.10項「Configuring Fractional Replication」を参照してください。これらの操作属性の役割は、データ・セットが部分であることを示すタグを付けることです。それらの属性がドメインに存在することは、このデータ・セットが部分ドメインであり、特定の属性が除外されていることを示します。

ドメインのルート・エントリに格納される部分構成と、生成ID (ds-sync-generation-id)およびレプリケーション状態(ds-sync-state)を合せて、部分シグネチャと見なすことができます。

ドメインを有効にすると(たとえば、その部分構成を変更した後で)、サーバーは、ドメインの部分構成(cn=configの下)とドメインのルート・エントリの部分構成属性を比較します。両方の構成が一致した場合、ドメインは正常ステータスであると見なし、LDAP操作を受け付けることができます。構成が一致しない場合、ドメインは不正な生成IDステータスであると見なし、LDAP操作を受け付けるには、(データ・セットをインポートして)データ・セットを同期する必要があります。

インポートするデータ・セットは、次のどちらかである必要があります:

- そのルート・エントリにある部分構成が、ローカル・ドメインのcn=configの下にある部分構成と同じであること。この場合、データ・セットはそのままインポートされます。

- そのルート・エントリに部分構成が存在しないこと。この場合、データ・セットはインポートされてから、ローカル・ドメインの部分構成(cn=configの下)で定義されている属性フィルタリング・ルールに従ってフィルタされます。その後、ローカル・ドメインの部分構成をコピーすることによって、インポートされたデータのルート・エントリにds-sync-fractional-exclude属性またはds-sync-fractional-include属性が作成されます。

6.8.2 部分レプリケーションのフィルタリング

ドメインが部分として構成されている場合、リプレイを目的としてネットワークから着信するADD、MODIFYおよびMODIFYDNのすべての操作はフィルタ処理されます。これらの操作は、部分構成に従って操作の属性がすべてフィルタ処理された場合、最終的に中止される可能性があります。

6.8.3 部分レプリケーションとローカル操作

LDAPクライアントが部分レプリカに対して直接実行した操作が部分構成に一致しない場合、その操作は禁止され、サーバーは「実行要求を拒否」エラーを返します。

たとえば、部分レプリカがfractional-exclude: *:jpegPhotoで構成されている場合、LDAPクライアントがjpegPhoto属性を含む新しいエントリを追加しようとすると、「実行要求を拒否」エラーで拒否されます。この動作により、このドメインにはjpegPhoto属性が存在できないことを意味する部分構成定義に関して、ドメインの一貫性が維持されることが保証されます。

7 Oracle Unified Directory索引モデルの理解

書籍の索引と同様に、Oracle Unified Directoryの索引は、検索文字列をディレクトリの内容に関連付けることによって検索時間を短縮します。

この章では、様々な索引タイプおよび検索を評価する方法について説明します。次の各項で構成されます:

- 第7.1項「索引の概要」

- 第7.2項「索引タイプ」

- 第7.3項「索引エントリ制限」

- 第7.4項「検索の評価」

- 第7.5項「索引の管理」

索引の構成の詳細は、第17.7項「ディレクトリ・データへの索引付け」を参照してください。

7.1 索引の概要

Oracle Unified Directoryは、索引を使用して、参照情報をOracle Unified Directoryエントリに関連付けることによって、検索操作を高速化します。各検索操作には、返すエントリを指定する検索キーが含まれます。検索操作中に、サーバーは索引を使用して、検索キーに一致するエントリを見つけます。索引が構成されていない場合、サーバーはすべてのエントリの接尾辞をチェックして、検索キーに一致する可能性があるエントリを特定する必要があります。

ディレクトリ内のすべてのエントリをチェックすることは、特に大規模ディレクトリの場合に、リソースを大量に消費します。さらに、権限を持たないユーザーは、索引付けされていない検索の実行を許可されない可能性があります。索引付けされていない検索を実行する権限の割当ての詳細は、第10章「rootユーザーと特権サブシステムの理解」を参照してください。検索効率を高めるために、クライアントが実行する必要がある検索に対応する索引を構成できます。

この項には次のトピックが含まれます:

- 第7.1.1項「索引とは」

- 第7.1.2項「索引の重要性の理解」

7.1.1 索引とは

索引は、検索条件に一致するエントリを効率的に見つけるためにディレクトリ・サーバー・データベースで使用するメカニズムです。索引は、検索キーをIDリストにマップします。IDリストは、その索引キーに一致するエントリのエントリIDの集合です。

7.1.2 索引の重要性の理解

- ディレクトリ・サーバーに対する検索操作を向上させる最も効率的な方法は、索引を構成し、検索結果に対する索引エントリ制限を定義することです。

- 索引にはエントリの指定した属性の値のみが格納され、エントリに関する他の詳細は格納されません。これにより領域が節約され、その属性を中心に索引を編成することによって検索が速くなります。索引が付けられている属性で検索を実行する場合、Oracle Unified Directoryはすぐに索引を特定して、検索条件に一致するエントリを探します。

7.2 索引タイプ

Oracle Unified Directoryでは次の索引タイプをサポートしています:

- 第7.2.1項「近似索引」

- 第7.2.2項「等価索引」

- 第7.2.3項「順序付き索引」

- 第7.2.4項「プレゼンス索引」

- 第7.2.5項「部分文字列索引」

7.2.1 近似索引

近似索引は、検索フィルタで指定されている値と似ている値を比較するために使用します。近似索引の目的は、検索フィルタに似た値に一致するエントリを特定することです。たとえば、cn属性の近似索引を使用した場合、クライアント・アプリケーションは、名前のつづりが間違っていてもエントリを見つけることができます。

7.2.2 等価索引

等価索引は、検索フィルタで指定されている値と正確に一致するエントリを特定します。等価索引は、対応する等価一致ルールが存在する属性にのみ付けることができます。

7.2.3 順序付き索引

順序付き索引は、属性値の相対順序を記録します。等価索引に似ていますが、等価一致ルールではなく、順序付け一致ルールを使用して値を正規化する点が異なります。順序付き索引は、対応する順序付け一致ルールが存在しない属性には付けることができません。

7.2.4 プレゼンス索引

プレゼンス索引は、指定されている属性の少なくとも1つの値を持つエントリを記録します。属性ごとにプレゼンス索引キーは1つのみ存在し、そのIDリストには、指定されている属性を含むすべてのエントリのエントリIDが含まれます。ACIを使用してエントリを高速検索できるように、aci属性にはデフォルトでプレゼンス索引が付けられています。

7.2.5 部分文字列索引

部分文字列索引は、特定の部分文字列が含まれるエントリを記録します。部分文字列索引の索引キーは、属性値から取得した6文字の部分文字列で構成され、対応する値であるIDリストには、それらの部分文字列を含むエントリのエントリIDが含まれます。属性の部分文字列一致ルールを使用して、索引キーの値を正規化します。部分文字列一致ルールを持たない属性には、部分文字列索引を定義できません。

7.3 索引エントリ制限

索引エントリ制限は、指定された索引キーと一致可能なエントリの最大数(つまり、IDリストの最大サイズ)の制御に使用できる構成制限です。サーバー内のエントリと高い割合で一致する索引キーを維持するために、パフォーマンスの影響を制限するメカニズムを提供します。大きなIDリストを必要とする可能性がある場合は、索引なし検索を実行すると、索引を使用するよりも速度を向上できる場合がよくあります。

7.4 検索の評価

LDAP検索操作を処理するために、サーバーは検索フィルタの各アサーションを適用して候補エントリのリストを生成し、このリストを結合して候補エントリIDの初期セットを構成します。

候補セットが作成されている場合、検索は索引付きであると見なされます。各候補エントリがエントリ・データベースからフェッチされ、検索範囲とフィルタに一致した場合はクライアントに返されます。

候補セットが作成されていない場合(索引が存在しないか、または一部の索引値が索引エントリ制限を超えているため)、検索は索引付けされていないと見なされます。この場合、範囲内のすべてのレコードを反復処理するためにベース・エントリでDNデータベースに対するカーソルがオープンされ、検索ベースの下のエントリをすべて処理するまで対応するエントリをフェッチおよびフィルタします。

索引から取得した候補エントリIDの数が10以下であることが判明した時点で、候補数を減らす処理は終了します。かわりに、索引データベースの読取りを続けるよりも速いという前提で、それらのエントリがすぐにエントリ・データベースからフェッチおよびフィルタ処理されます。この場合、最初のコンポーネントが最も厳しい条件であるようなAND検索で、期待する結果が得られる可能性があります。

また、検索のANDフィルタは、評価に時間がかかるコンポーネント(以上、以下)が、通常はそれより高速なコンポーネント(たとえば、等価)よりも後に評価されるように再配置されます。

7.5 索引の管理

索引を管理する場合、次の重要なポイントがあります:

- verify-indexコマンドを実行して、索引とディレクトリ・サーバー・データベース内のエントリ・データの間の一貫性をチェックします。
このコマンドの詳細は、第A.3.16項「verify-index」を参照してください。

- 新しい索引を作成したか、または索引のindex-entry-limitプロパティが変更された場合、rebuild-indexコマンドを実行して、ディレクトリ・サーバーの索引を再構築します。
このコマンドの詳細は、第A.3.13項「rebuild-index」を参照してください。

- 仮想リスト表示(VLV)索引を構成します。これは、VLVコントロールを使用して効率的に検索を処理するためにディレクトリ・サーバー・データベースで使用するメカニズムです。VLV索引は特定のクエリおよびソート・パラメータを使用して、仮想一覧表示が実行されることを効率的にサーバーに通知します。また、この索引は、仮想一覧表示をより迅速に使用するために必要な情報の収集および維持をサーバーができるようにします。VLV索引には、ソートされたIDリストのブロックが格納されます。このリストは、エントリIDとエントリのソート対象の属性値のセットです。
VLV索引の構成の詳細は、第17.7.2項「VLV索引の構成」を参照してください。

- 拡張一致検索フィルタを使用して検索操作を高速化するために、拡張一致索引を構成します。索引キーは指定した一致ルールを使用して正規化された値であり、対応するIDリストにはその一致ルールに従って値に一致するすべてのエントリのエントリIDが含まれます。
拡張一致検索フィルタの詳細は、D.5.13項「extensible match search filter」を参照してください。

8 Oracle Unified Directoryのアクセス制御モデルの理解

この章は、ディレクトリ・サーバーのアクセス制御モデルに関する参照情報を含みます。ディレクトリ・サーバーでのアクセス制御の構成の詳細は、第22章「データへのアクセス制御」を参照してください。

この章では、次のトピックを取り扱います:

- 第8.1項「アクセス制御の原則」

- 第8.2項「ACI構文」

- 第8.3項「バインド・ルール」

- 第8.4項「バインド・ルールの構文」

- 第8.5項「Oracle Directory Server Enterprise Editionのアクセス制御モデルとの互換性」

- 第8.6項「高度なアクセス制御のためのマクロACIの使用」

8.1 アクセス制御の原則

この項では、ディレクトリ・サーバーで提供されているアクセス制御メカニズムの原則について説明します。

- 第8.1.1項「アクセス制御の概要」

- 第8.1.2項「ACIの構造」

- 第8.1.3項「ディレクトリ・サーバーのグローバルACI」

- 第8.1.4項「ACI評価」

- 第8.1.5項「ACI制限事項」

- 第8.1.6項「アクセス制御とレプリケーション」

第22.1項「dsconfigを使用したグローバルACIの管理」も参照してください。

8.1.1 アクセス制御の概要

ディレクトリ·サーバーがリクエストを受信すると、バインド操作でユーザーが提供する認証情報、およびサーバーで定義されたアクセス制御命令(ACI)を使用して、ディレクトリ情報へのアクセスが許可または拒否されます。サーバーは、読取り、書込み、検索、比較などの権限を許可または拒否できます。ユーザーに付与される権限のレベルは、ユーザーが入力する認証情報によって異なります。

アクセス制御を利用すると、ディレクトリ全体、ディレクトリのサブツリー、ディレクトリ内の特定のエントリ(構成タスクを定義するエントリを含む)、エントリ属性の特定のセット、あるいは特定のエントリ属性値へのアクセスを制御できます。特定のユーザー、特定のグループまたはロールに属するすべてのユーザー、またはそのディレクトリのすべてのユーザーに対して権限を設定できます。さらに、(そのIPアドレスまたはDNS名で識別される)特定のクライアントのアクセス権を定義できます。

8.1.2 ACIの構造

アクセス制御の方法はエントリの属性としてディレクトリに保存されます。aci属性は操作属性で、エントリのオブジェクト・クラス用に定義されているかどうかにかかわらず、ディレクトリ内のすべてのエントリに使用できます。この属性は、ディレクトリ・サーバーがクライアントからLDAPリクエストを受け取るときに、どの権限が付与、または拒否されるかを評価するためにディレクトリ・サーバーに使用されます。明確にリクエストされている場合のみ、aci属性はldapsearch操作で戻されます。

ACI文は3つの主要部分を含みます:

ターゲット

権限が適用されるエントリまたは属性を決定します。

権限

どの操作が許可または拒否されるかを定義します。

バインド・ルール

バインドDNに基づいて、ACIの対象を決定します。

ACIの権限とバインド・ルールの部分は、ペアで設定されます。これは、アクセス制御ルール(ACR)とも呼ばれています。ターゲットにアクセスするために指定される権限は、付随するルールがtrueと評価されるかどうかによって付与されるか拒否されるかが決定されます。詳細は、第8.2項「ACI構文」を参照してください。

ACIを含むエントリが子エントリを持たない場合は、ACIはそのエントリにのみ適用されます。エントリが子エントリを持つ場合は、ACIはそのエントリ自身およびその下位のすべてのエントリに適用されます。したがって、ディレクトリ・サーバーがエントリへのアクセス権を評価するときは、リクエストされたエントリとそのルート接尾辞のベースとの間のすべてのエントリのACIを検証します。

aci属性は複数値です。つまり、同じエントリまたはサブツリーに対して、複数のACIを定義できます。

直接そのエントリではなく、その下のサブツリー内の一部またはすべてのエントリに適用されるACIを作成することができます。この利点は、ツリーで下位に位置する可能性の高いエントリに効果的に適用する一般的なACIを、ディレクトリ・ツリーの高いレベルに設定できることです。たとえば、organizationalUnitエントリまたはlocalityエントリのレベルでは、inetorgpersonオブジェクト・クラスを含むエントリをターゲットとするACIを作成できます。

この機能を使用すると、高いレベルの分岐点で一般的なルールを設定することでディレクトリ・ツリー内のACIの数を最小にできます。より具体的なルールの範囲を制限するには、できるだけリーフ・エントリに近い位置にそのルールを設定します。

注意:

ルートのDSEエントリ(DN ""を使用)に設定されたACIは、そのエントリにのみ適用されます。

8.1.3 ディレクトリ・サーバーのグローバルACI

アクセス制御ハンドラのプロパティを変更するdsconfigを使用することによって、一元的にアクセス制御を構成することができます。

ルールではtarget式が指定されないので、次のデフォルトのグローバルACIは、ディレクトリ・サーバーに定義されているすべての接尾辞に適用されます:

Property   : Value(s)
-----------:-------------------------------------------------------------------
global-aci : "(targetattr!="userPassword||authPassword")(version 3.0; acl
: "Anonymous read access"; allow (read,search,compare)
: userdn="ldap:///anyone";)", (targetattr="*")(version 3.0; acl
: "Self entry modification"; allow (write) userdn="ldap:///self";),
: "(targetattr="createTimestamp||creatorsName||modifiersName||modify
: Timestamp||entryDN||entryUUID||subschemaSubentry")(version 3.0;
: acl "User-Visible Operational Attributes"; allow
: (read,search,compare) userdn="ldap:///anyone";)",

詳細は、第22.1項「dsconfigを使用したグローバルACIの管理」を参照してください。

8.1.4 ACI評価

特定のエントリへのアクセス権を評価するためには、サーバーはエントリ自身およびエントリのルート接尾辞のベースに戻る親エントリに存在するACIのリストをコンパイルします。評価中、サーバーはこの順番でACIを処理します。ACIは、エントリとそのルート接尾辞のベースの間のすべての接尾辞およびサブ接尾辞内で評価されます(他のサーバー上の連鎖接尾辞間では評価されません)。

注意:

アクセス制御はbypass-acl権限を持つユーザーには適用されません。ディレクトリ・マネージャにはこの権限があります。クライアントがディレクトリ・マネージャとしてディレクトリにバインドされている場合、ディレクトリ・サーバーは、操作を実行する前にACIを評価しません。結果として、ディレクトリ・マネージャとしてのLDAP操作のパフォーマンスは、他のユーザーで予期されるパフォーマンスと同等にはなりません。一般的なユーザーIDを使用して、常にディレクトリのパフォーマンスをテストする必要があります。

デフォルトでは、ACIがエントリに適用されない場合、アクセスはbypass-acl権限を持つユーザー以外のすべてのユーザーに拒否されます。ユーザーがディレクトリ内のエントリにアクセスするためには、ACIによってアクセス権が明示的に付与される必要があります。デフォルトACIは匿名の読取りアクセスを定義し、セキュリティのために必要な属性を除いて、ユーザーが自分のエントリを変更することができます。詳細は、第22.1.1項「デフォルトのグローバルACI」を参照してください。

ディレクトリ·サーバーは、最初にターゲット・エントリに最も近いACIを処理しますが、エントリに適用されるすべてのACIの影響は累積されます。他のACIが拒否しないかぎり、任意のACIによって付与されたアクセス権が許可されます。アクセスを拒否するACIは、リストのどこにそれが現れても、同じリソースにアクセスを許可するACIよりも優先されます。

たとえば、ディレクトリのルート・レベルで書込み権限を拒否すると、ユーザーに特定の権限を与えても、どのユーザーもディレクトリに書き込めなくなります。特定のユーザーにディレクトリへの書込み権限を付与するには、そのユーザーを除外するように書込み権限の元の拒否の有効範囲を制限する必要があります。

8.1.5 ACI制限事項

ディレクトリ・サービスにアクセス制御ポリシーを作成するときは、次の制限事項に注意してください:

- ディレクトリ・ツリーが複数のディレクトリ・サーバー上に分散している場合、いくつかの制限はアクセス制御文で使用できるキーワードに適用されます。グループ・エントリ(groupdnキーワード)に依存するACIは、グループ・エントリと同じディレクトリ・サーバー上に配置する必要があります。そのグループが動的である場合は、そのグループのすべてのメンバーはディレクトリ・サーバー上にエントリを持つ必要があります。グループが静的である場合は、メンバーのエントリはリモート・ディレクトリ・サーバー上に配置することができます。ただし、ターゲット·エントリに格納される値とバインド・ユーザーのエントリに格納される値のマッチングを行うことができます(たとえば、userattrキーワードを使用)。ACIを保持するディレクトリ・サーバーにバインド・ユーザーがエントリを持っていなくても、アクセスは通常どおりに評価されます。

- アクセス制御ルールは、常にローカル・ディレクトリ・サーバー上で評価されます。ACIキーワードで使用されるLDAP URLでは、ディレクトリ・サーバーのホスト名またはポート番号を指定することはできまん。指定する場合は、LDAP URLはまったく考慮されません。

8.1.6 アクセス制御とレプリケーション

ACIはエントリの属性として格納されます。したがって、ACIを含んでいるエントリがレプリケートされた接尾辞の一部である場合、ACIは他の属性のようにレプリケートされます。

8.2 ACI構文

ACIは多数の可能性のバリエーションを持つ複雑な構造です。次の項では、ACIの構文の詳細を説明します。

- 第8.2.1項「ACI構文の概要」

- 第8.2.2項「ターゲットの定義」

- 第8.2.3項「権限の定義」

第8.4項「バインド・ルールの構文」も参照してください。

8.2.1 ACI構文の概要

aci属性には、次の構文があります:

aci: (target)(version 3.0;acl "name";permissionBindRules;)

ここで:

- targetは、アクセス制御するエントリ、属性、またはエントリと属性のセットを指定します。targetには、識別名、1つ以上の属性、または単一のLDAPフィルタを指定できます。targetはオプションです。targetが指定されていない場合は、ACIは定義されているエントリとそのすべての子のエントリ全体に適用されます。

- version 3.0はACIバージョンを識別する必須の文字列です。

- nameはACIの名前です。nameはACIを識別する任意の文字列です。ACI名は必須であり、ACIの影響を示す必要があります。名前に制約はありませんが、ACIには一意の名前を使用することをお薦めします。一意の名前を使用すると、実効権限取得制御によって、有効になっているACIを判別することができます。

- permissionは、許可または拒否する権限(たとえば読取り権限や検索権限)を明示します。

- bindRulesは、ユーザーがアクセス権を付与されるために提供する必要がある資格証明およびバインド・パラメータを指定します。バインド・ルールは、ユーザー・メンバーシップ、グループ・メンバーシップ、またはクライアントの接続プロパティに基づいて指定することもできます。

複数のターゲットおよび権限とバインド・ルールのペアを指定することができます。これにより、ターゲットとなるエントリおよび属性の両方を詳細に指定し、ここに示すように、特定のターゲットに対して複数のアクセス制御を効率的に設定できます:

aci: (target)...(target)(version 3.0;acl "name"; permissionBindRule; permissionBindRule; ...; permissionBindRule;)

次の例は、完全なLDIF ACIを示しています:

aci: (target="ldap:///uid=bjensen,dc=example,dc=com")
(targetattr="*")(version 3.0; acl "example"; allow (write)
userdn="ldap:///self";)

この例では、ACIは、ユーザーbjensenは、自身のディレクトリ・エントリ内のすべての属性を変更する権限を持つことを指定しています。

8.2.2 ターゲットの定義

ターゲットは、ACIの適用対象を識別します。クライアントがエントリ内の属性の操作をリクエストする場合は、ディレクトリ・サーバーはACIが操作を許可または拒否するために評価される必要があるかを確認するためにターゲットを評価します。ターゲットが指定されていない場合は、ACIはaci属性を含むエントリのすべての属性、およびその下位のエントリに適用されます。

次の項では、ターゲットの定義方法を説明します:

- 第8.2.2.1項「ディレクトリ・エントリのターゲット」

- 第8.2.2.2項「属性のターゲット指定」

- 第8.2.2.3項「エントリと属性のターゲット指定」

- 第8.2.2.4項「LDAPフィルタを使用したエントリまたは属性のターゲット指定」

- 第8.2.2.5項「LDAPフィルタを使用した属性値のターゲット指定」

- 第8.2.2.6項「単一のディレクトリ・エントリのターゲット指定」

- 第8.2.2.7項「ACIの有効範囲の指定」

- 第8.2.2.8項「LDAP制御のターゲット指定」

- 第8.2.2.9項「LDAP拡張操作のターゲット指定」

ターゲットの一般的な構文は、次のいずれかです:

(keyword = "expression")
(keyword != "expression")

ここで:

- keywordはターゲットのタイプを示します。ターゲットの次のタイプは表8-1のキーワードで定義されます:

- ディレクトリ・エントリまたはそのサブツリー

- エントリの属性

- LDAPフィルタとマッチングするエントリまたは属性のセット

- LDAPフィルタとマッチングする属性値または値の組合せ

- ACIの有効範囲

- LDAP制御

- 拡張操作

- 等号(=)は、ターゲットが式で指定されたオブジェクトであることを示し、非等号(!=)は、ターゲットが式で指定されていない任意のオブジェクトであることを示します。

注意:

非等号演算子はtargattrfiltersおよびtargetscopeキーワードではサポートされません。

- expressionは、キーワードに依存し、ターゲットを識別します。構文上、expressionの前後には引用符("")が必要です。ただし、現在の実装では、targetattr=*のような表現も受け入れています。将来のバージョンでは、構文チェックがより厳密になる可能性があるので、常に引用符を使用する必要があります。

次の表は、各キーワードとそれに関連する式を示します。

表8-1 LDIFターゲット・キーワード

キーワード

有効な式

ワイルドカード使用の可否

target

ldap:///distinguishedName

使用可能

targetattr

属性

使用可能

targetfilter

LDAPfilter

使用可能

targattrfilters

LDAPoperation:LDAPfilter

使用可能

targetscope

base, onelevel, subtree, subordinate

使用不可

targetcontrol

oid

使用不可

extop

oid

使用不可

8.2.2.1 ディレクトリ・エントリのターゲット

ターゲット・キーワードおよびLDAP URL内部のDNを使用すると、特定のディレクトリ・エントリおよびその下位の任意のエントリをターゲット指定することができます。ターゲットDNは、ACIが定義されているエントリ、またはエントリの下のサブツリーに配置される必要があります。ターゲット式の構文は次のとおりです:

(target = "ldap:///distinguishedName")
(target != "ldap:///distinguishedName")

識別名は、ACIが定義されているエントリ、またはエントリの下のサブツリーに配置される必要があります。たとえば、ou=People,dc=example,dc=com上のACIでは、次のようなターゲットを使用できます:

(target = "ldap:///uid=bjensen,ou=People,dc=example,dc=com")

キーワードtargetはオプションです。それが存在しない場合は、ACIのデフォルト・ターゲットはACIが格納されているエントリです。

注意:

エントリのDNは、文字列表現の識別名とする必要があります(RFC 4514 (http://www.ietf.org/rfc/rfc4514.txt)で定義されています)。そのため、カンマなど、DNの構文上意味を持つ文字は、単一の円記号(\)でエスケープする必要があります。例:

(target="ldap:///uid=cfuentes,o=Example Bolivia\, S.A.")

LDAP URLに一致する任意の数のエントリをターゲットにするために、DNでワイルドカードを使用することもできます。ワイルドカードの正しい使用例を次に示します:

- (target="ldap:///uid=*,dc=example,dc=com")は、エントリのRDNにuid属性を持つexample.com分岐エントリのすべての直近の子と一致します。次に例を示します。

uid=tmorris,dc=example,dc=com
uid=yyorgens,dc=example,dc=com
uid=bjensen,dc=example,dc=com

- (target="ldap:///uid=*,**,dc=example,dc=com")は、エントリのRDNにuid属性を持つexample.com分岐エントリよりも複数レベル下のすべてのエントリと一致します。次に例を示します。

uid=tmorris,ou=sales,dc=example,dc=com
uid=yyorgens,ou=marketing,dc=example,dc=com
uid=bjensen,ou=eng,ou=east,dc=example,dc=com

- (target="ldap:///uid=*Anderson,ou=People,dc=example,dc=com")は、uidがAndersonで終了するou=People分岐エントリのすぐ下のすべてのエントリと一致します。

- (target="ldap:///*=*Anderson,ou=People,dc=example,dc=com")は、ネーミング属性に関係なく、AndersonでRDNが終了するou=People分岐のすぐ下のすべてのエントリと一致します。

uid=*,ou=*,dc=example,dc=comのように複数のワイルドカードを使用できます。この例は、指定された位置で識別名がuidおよびou属性を含むexample.comツリーのすべてのエントリと一致します。

8.2.2.2 属性のターゲット指定

ディレクトリ・エントリをターゲットにすることに加えて、ターゲットのエントリに発生する1つ以上の属性(またはすべて(1つ以上)の属性)をターゲットにすることができます。この機能は、エントリに関する部分的な情報へのアクセスを拒否または許可したい場合に便利です。たとえば、特定のエントリの共通名、名字および電話番号の属性にのみアクセスを許可できます。同様に、個人情報などの機密情報へのアクセスを拒否できます。

targetattrルールがない場合は、デフォルトではどの属性にもアクセスすることはできません。すべての属性にアクセスするには、ルールはtargetattr="*"である必要があります。

ターゲット属性は、ターゲット・エントリまたはそのサブツリーに存在する必要はありませんが、存在すればACIが適用されます。ターゲットにする属性は、このスキーマで定義する必要はありません。スキーマ・チェックを行わないことにより、データとそのスキーマをインポートする前にアクセス制御ポリシーを実装できます。

属性をターゲット指定するには、targetattrキーワードを使用し、属性名を入力します。targetattrキーワードでは、次の構文を使用します:

(targetattr = "attribute")
(targetattr != "attribute")

次の構文でtargetattrキーワードを使用することで、複数の属性をターゲットにすることができます:

(targetattr = "attribute1 || attribute2 ... || attributeN")
(targetattr != "attribute1 || attribute2 ... || attributeN")

たとえば、エントリの共通名、名字およびUID属性をターゲットにする場合は、次のように指定します:

(targetattr = "cn || sn || uid")

carlicenseを除く、エントリのユーザー属性のすべてをターゲットにするには、次のターゲットを使用します:

(targetattr != "carlicense")

前述の例では、操作属性を返しません。

ターゲット属性には、指定された属性のすべてのサブタイプが含まれます。たとえば、(targetattr = "locality")はlocality;lang-frもターゲットになります。たとえば、(targetattr = "locality;lang-fr-ca")のように、具体的にサブタイプをターゲットにすることもできます。

targetattrルール(たとえばtargetattr="*")でスタンドアロン文字としてワイルドカードを使用できますが、特定の目的を果たさず、パフォーマンスに悪影響を与える可能性があるため、この使用はお薦めしません。

8.2.2.3 エントリと属性のターゲット指定

デフォルトでは、targetattrキーワードを含むACIにターゲット指定されたエントリは、ACIが配置されたエントリです。つまり、ACI aci: (targetattr = "uid")(accessControlRules;)をou=Marketing, dc=example,dc=comエントリに適用する場合は、ACIはMarketingサブツリー全体に適用されます。ただし、次の例のように、ターゲット・キーワードを使用して明示的にターゲットを指定することもできます:

aci: (target="ldap:///uid=*,ou=Marketing,dc=example,dc=com")
(targetattr="uid") (accessControlRules;)

ターゲットおよびtargetattrキーワードを指定する順番は重要ではありません。

8.2.2.4 LDAPフィルタを使用したエントリまたは属性のターゲット指定

一定基準に一致するエントリのセットをターゲットにするために、LDAPフィルタを使用することができます。このためには、LDAPフィルタとともにtargetfilterキーワードを使用します。ACIは、ターゲットDNのレベルおよびその下位のサブツリーでフィルタに一致するすべてのエントリに適用されます。

targetfilterキーワードは次の構文を使用します:

(targetfilter = "LDAPfilter")

ここで、LDAPfilterは標準のLDAP検索フィルタです。フィルタの構文の詳細は、付録D「検索フィルタ」を参照してください。

たとえば、従業員を示すすべてのエントリには、正社員または契約社員のステータスと、労働時間数を(フルタイムに対する割合として)示す属性があると仮定します。契約社員またはパート社員を示すすべてのエントリをターゲットにするには、次のフィルタを使用できます:

(targetfilter = "(|(status=contractor)(fulltime<=79))")

ACIでは、Netscapeが拡張したフィルタ構文はサポートされません。たとえば、次のターゲット・フィルタは有効ではありません:

(targetfilter = "(locality:fr:=<= Qu?bec)")

ターゲット・フィルタはACIのターゲットとしてエントリ全体を選択します。ターゲット・エントリの属性のサブセットに適用されるACIを作成するために、targetfilterおよびtargetattrキーワードを組み合せることができます。

次に示すLDIFの例では、Engineering Adminグループのメンバーは、Engineeringのビジネス・カテゴリ内のすべてのエントリのdepartmentNumberおよびmanager属性を変更できます。この例では、LDAPフィルタを使用して、businessCategory属性がEngineeringに設定されたすべてのエントリを選択します:

dn: dc=example,dc=com
objectClass: top
objectClass: organization
aci: (targetattr="departmentNumber || manager")
(targetfilter="(businessCategory=Engineering)")
(version 3.0; acl "eng-admins-write"; allow (write)
groupdn ="ldap:///cn=Engineering Admins, dc=example,dc=com";)

ディレクトリ内に分散したエントリおよび属性をターゲットにする場合、LDAPフィルタの使用は便利ですが、フィルタでは、アクセス管理対象のオブジェクトが直接指定されないので、思わぬ結果を招くことがあります。フィルタ処理済のACIでターゲット指定されたエントリのセットは、属性の追加や削除によって変化することがあります。したがって、ACIでLDAPフィルタを使用する場合は、ldapsearch操作で同じフィルタを使用して適切なエントリと属性がターゲット指定されていることを確認する必要があります。

8.2.2.5 LDAPフィルタを使用した属性値のターゲット指定

アクセス制御を使用すると、特定の属性値をターゲットに指定できます。つまり、属性値がACIで定義された条件を満たす場合、属性に対する権限を付与または拒否できます。属性の値に基づいてアセスを許可または拒否するACIは、値ベースACIと呼ばれています。

たとえば、組織内のすべてのユーザーに、ユーザー自身のエントリ内のroomNumber属性を変更する権限を付与することができます。ただし、ユーザーが予約済の部屋番号(12から始まるすべての番号)を指定できないようにすることも必要です。LDAPフィルタは、属性値の条件が満たされていることを確認するために使用されます。

値ベースACIを作成するには、次の構文でtargattrfiltersキーワードを使用する必要があります:

(targattrfilters="Op=attr1:F1[(&& attr2:F2)*][;Op=attr:F[(&& attr:F)*]")

ここで:

- Opは、addまたはdelete操作のいずれかです:

- addは属性を作成する操作を示します。

- deleteは属性を削除する操作を示します。

- attrはターゲット属性を示します。

- Fは、関連付けられた属性のみに適用する「検索フィルタ」(付録D)を示します。

エントリを作成するとき、フィルタが新しいエントリの属性に適用される場合は、その属性のすべての値はフィルタを満たす必要があります。エントリを削除するとき、フィルタがエントリの属性に適用される場合は、その属性のすべての値もフィルタを満たす必要があります。

エントリを変更するとき、操作で属性を追加する場合は、その属性に適用される追加フィルタを満たす必要があります。操作で属性を削除する場合は、その属性に適用される削除フィルタを満たす必要があります。エントリ内にすでに存在する属性の各値が置き換えられる場合は、追加および削除フィルタの両方を満たす必要があります。

次の例の属性フィルタは、12の接頭辞を持つ予約済の部屋番号を除いて、ユーザー自身のエントリに任意のroomNumber属性を追加することをユーザーに許可します。またこれにより、ユーザーは123という接頭辞を持つ電話番号を追加できます。

(targattrfilters="add=roomNumber:(!(roomNumber=12*)) && telephoneNumber:(telephoneNumber=123*)")

8.2.2.6 単一のディレクトリ・エントリのターゲット指定

単一のエントリをターゲットとする明示的な方法はありません。ただし、次の2つのうちのいずれかの方法で可能です:

- バインド・リクエストでのユーザー入力が、ターゲット・エントリ内に格納された属性値に一致するバインド・ルールを作成する

- targetfilterキーワードを使用する

targetfilterキーワードを使用すると、目的のエントリにのみ表示される属性値を指定することができます。たとえば、ディレクトリ・サーバーをインストールする間に次のACIが作成されます:

aci: (targetattr="*")(targetfilter=(o=example))
(version 3.0; acl "Default anonymous access";
allow (read, search) userdn="ldap:///anyone";)

属性oが値exampleを持つ唯一のエントリのため、このACIはo=exampleエントリにのみ適用されます。

これらのメソッドに関連付するリスクは、ディレクトリ・ツリーは、将来変更される可能性があるということと、このACIを変更することを忘れないようにしなければならないことです。

8.2.2.7 ACIの有効範囲の指定

通常、ACIの範囲はサブツリーです。次の構文でtargetscopeキーワードを使用することでACIの有効範囲を制限できます:

(targetscope="expression")

ここで、expressionは次のいずれかです:

base

ACIは、ターゲット・リソースにのみ適用されます。

onelevel

ACIは、ターゲット・リソースの第1世代の子に適用されます。

subtree

ACIは、ターゲット・リソースとその下にあるサブツリーに適用されます。

subordinate

ACIは、ターゲット・リソースの下にあるサブツリーにのみ適用されます。

targetscopeが指定されていない場合、デフォルト値はsubtreeです。次の例では、ACIターゲット一致は、識別名uid=bjensen,ou=People,dc=example,dc=comのエントリ、およびその1レベル下の任意の子のエントリのみに制限されます:

(target = "ldap:///uid=bjensen,ou=People,dc=example,dc=com")(targetscope="onelevel")

注意:

非等号演算子はtargetscopeキーワードではサポートされていません。

8.2.2.8 LDAP制御のターゲット指定

LDAP制御をターゲットに指定するには、targetcontrolキーワードを使用し、制御(付録D「オブジェクト識別子」)を入力します。targetcontrolキーワードは次の構文を使用します:

(targetcontrol="oid")

(targetcontrol!="oid")

次の構文でtargetcontrolキーワードを使用することで、複数のLDAP制御をターゲットにすることができます:

(targetcontrol="oid1 || oid2... || oidN")

(targetcontrol!="oid1 || oid2... || oidN")

たとえば、「実効権限取得制御」(付録D)および「プロキシ設定された認可制御」(付録D)の両方をターゲットに指定するには、次のtargetcontrol式を使用します:

(targetcontrol = "1.3.6.1.4.1.42.2.27.9.5.2 || 2.16.840.1.113730.3.4.18")

注意:

実効権限取得制御は1.3.6.1.4.1.42.2.27.9.5.2のOID値を持ちます。プロキシ認可V2制御は2.16.840.1.113730.3.4.18のOID値を持ちます。

8.2.2.9 LDAP拡張操作のターゲット指定

拡張操作をターゲットに指定するには、extopキーワードを使用し、操作(付録D「オブジェクト識別子」)を指定します。extopキーワードは次の構文を使用します:

(extop= "oid")

(extop!= "oid")

次の構文でextopキーワードを使用することにより、複数の拡張操作をターゲットにすることができます:

(extop = "oid1 || oid2... || oidN")

(extop!= "oid1 || oid2... || oidN")

たとえば、「StartTLS拡張操作」(付録D)および「パスワード変更拡張操作」(付録D)の両方をターゲットにするには、次のextop式を使用します:

(extop = "1.3.6.1.4.1.1466.20037 || 1.3.6.1.4.1.4203.1.11.1.")

注意:

StartTLS拡張操作ターゲットでextopキーワードを使用するアクセス制御は、常にグローバルACIを使用して行われる必要があります。StartTLS拡張操作で認可エントリはnullになります。

8.2.3 権限の定義

権限では、許可または拒否するアクセスのタイプを指定します。ディレクトリ内で特定の操作を実行する権限を許可または拒否することができます。割り当てられる様々な操作は、権限として知られています。

権限の設定には2つの手順があります:

- アクセスの許可または拒否

- 権限の割当て

次の項では、権限の定義方法を説明します:

- 第8.2.3.1項「アクセスの許可または拒否」

- 第8.2.3.2項「権限の割当て」

- 第8.2.3.3項「LDAP操作に必要な権限」

- 第8.2.3.4項「権限の構文」

8.2.3.1 アクセスの許可または拒否

allowまたはdenyキーワードを使用して、アクセス権を明示的に許可または拒否できます。

8.2.3.2 権限の割当て

権限は、ユーザーがディレクトリ・データで実行できる特定の操作の詳細を説明します。すべての権限を許可または拒否するか、または次に示す権限の1つ以上を割り当てることができます:

読取り(Read)

ユーザーがディレクトリ・エントリおよびACIに指定されたエントリの属性を読み取ることができるかを示します。この権限は、検索操作のみに適用されます。(読取り権限を次の検索権限の説明と比較してください。)

書込み(Write)

ユーザーが属性を追加、変更または削除することでエントリを変更できるかを示します。この権限は、変更およびmodRDN操作に適用されます。

追加(Add)

ユーザーがエントリを作成できるかを示します。この権限は、追加操作のみに適用されます。

削除(Delete)

ユーザーがエントリを削除できるかを示します。この権限は、削除操作のみに適用されます。

検索(Search)

ACIに指定されたターゲット上でユーザーが検索できるかを示します。この権限は、検索操作のみに適用されます。検索権限は、一度確認され、検索が許可または拒否された後は再び確認されません。検索が許可された場合、読取り権限は検索の結果として返される各エントリおよび各エントリの各属性に適用されます。

比較(Compare)

ユーザーは、ユーザーが指定するデータとディレクトリに格納されたデータを比較できるかを示します。比較権限を使用すると、ディレクトリが問合せの応答として成功または失敗のメッセージを返しますが、ユーザーはエントリまたは属性の値を参照できません。この権限は、比較操作のみに適用されます。

自己書込み(Selfwrite)

ユーザーがターゲット・エントリの属性に自分自身のDNを追加または削除できるかを示します。この属性の構文は、識別名である必要があります。この権限は、グループ管理でのみ使用されます。自己書込みは、プロキシ認可で機能します。これは、(バインドされたユーザーのDNではなく)グループ・エントリからプロキシDNを追加または削除する権限を付与します。

プロキシ(Proxy)

指定されたDNが別のエントリの権限でターゲットにアクセスできるかを示します。ディレクトリ・マネージャDNを除くディレクトリ内の任意のユーザーのDNを使用して、プロキシ・アクセス権を付与できます。なお、ディレクトリ・マネージャにはプロキシ権限を付与できません。第22.6項「プロキシ認可のACI」に例があります。

インポート(Import)

変更DN操作で使用されます。このアクセス権限は、エントリを特定のDNにインポートできるかどうかを示します。

エクスポート(Export)

変更DN操作で使用されます。このアクセス権限は、エントリを特定のDNからエクスポートできるかどうかを示します。

すべて(All)

指定されたDNが、ターゲット・エントリに対して次の権限を持つことを示します: 読取り、書込み、検索、削除、比較、自己書込み。すべてのアクセス権限は、ターゲット・エントリに次の権限を与えません: プロキシ、インポートおよびエクスポート。

rightは、互いに独立して付与されます。つまり、たとえば、削除権限が明確に付与されていない場合は、追加権限を付与されるユーザーはエントリを作成することができますが、それを削除することはできません。したがって、ディレクトリに対するアクセス制御ポリシーを計画している場合、ユーザーに対して合理的に権利を付与することを確認することが必要です。たとえば、読取りおよび検索権限を付与せずに書込み権限を付与しても、合理的ではありません。

8.2.3.3 LDAP操作に必要な権限

この項では、実行を許可するLDAP操作のタイプに応じて、ユーザーに付与する必要のある権限について説明します。

- エントリの追加

- 追加されるエントリに対する追加権限を付与します。

- エントリの各属性値に対する書込み権限を付与します。この権限はデフォルトで付与されますが、targattrfiltersキーワードを使用して制限することもできます。

- エントリの削除

- 削除されるエントリに対する削除権限を付与します。

- エントリの各属性値に対する書込み権限を付与します。この権限はデフォルトで付与されますが、targattrfiltersキーワードを使用して制限することもできます。

- エントリ内の属性の変更

- 属性タイプに対する書込み権限を付与します。

- 各属性タイプの値に対する書込み権限を付与します。この権限はデフォルトで付与されますが、targattrfiltersキーワードを使用して制限することもできます。

- エントリのRDNの変更

- エントリに対する書込み権限を付与します。

- 新しいRDNで使用される属性タイプに対する書込み権限を付与します。

- 古いRDNを削除する権限を付与する場合、古いRDNで使用される属性タイプに対する書込み権限を付与します。

- 新しいRDNで使用される属性タイプの値に対する書込み権限を付与します。この権限はデフォルトで付与されますが、targattrfiltersキーワードを使用して制限することもできます。

- 別のサブツリーへのエントリの移動

- 移動するエントリに対するエクスポート権限を付与します。

- 移動するエントリの新しい上位エントリに対するインポート権限を付与します。

- 属性の値の比較

- 属性タイプに対する比較権限を付与します。

- エントリの検索

- 検索フィルタで使用される各属性タイプに対する検索権限を付与します。

- エントリが確実に返されるようにエントリで使用される最低1つの属性タイプに対する読取り権限を付与します。

- エントリで返される各属性タイプに対する読取り権限を付与します。

ユーザーがディレクトリを検索するために設定する必要のある権限を簡単に理解できるように、次に例を示します。次の検索について考えてみます:

$ ldapsearch -h host -p port -D "uid=bjensen,dc=example,dc=com" \
-j pwd-file -b "dc=example,dc=com" \
"(objectclass=*)" mail

次のACIは、ユーザーbjensenに、自身のエントリを検索するためのアクセス権を付与できるかどうかを決定します:

aci: (targetattr = "mail")(version 3.0; acl "self access to \
mail"; allow (read, search) userdn = "ldap:///self";)

このACIではbjensenにobjectclass属性で検索する権限を許可していないため、検索結果リストは空になります。正常な検索操作のためには、次の例のようにACIを変更する必要があります:

aci: (targetattr = "mail || objectclass")(version 3.0; acl \
"self access to mail"; allow (read, search) userdn = \
"ldap:///self";)

8.2.3.4 権限の構文

ACI文において、権限は次の構文を使用します:

allow|deny (rights)

ここで、rightsはカッコで囲まれたコンマ区切りのキーワードのリストです。有効なキーワードは、read、write、add、delete、search、compare、selfwrite、proxy、import、exportまたはallです。

allのアクセス権限は、ターゲット・エントリに次の権限を与えません: proxy、importおよびexport。

次の例では、バインド・ルールがtrueと評価される場合、read、searchおよびcompareのアクセスが許可されます:

aci: (target="ldap:///dc=example,dc=com") (version 3.0;acl \
"example"; allow (read, search, compare) bindRule;)

8.3 バインド・ルール

ディレクトリに対して定義されたACIに応じて、いくつかの操作では、ディレクトリにバインドが必要です。次の項では、バインド・ルールがアクセスを制御するために使用される方法を説明します:

- 第8.3.1項「バインド・ルールの概要」

- 第8.3.2項「ブール・バインド・ルールの使用」

8.3.1 バインド・ルールの概要

バインドとは、バインドDNおよびパスワードを入力して(SSLを使用する場合は、証明書を提示して)ディレクトリにログインするか、自身の認証を行うことです。バインド操作で提示される資格証明およびバインドの状況によって、ディレクトリへのアクセスが許可されるか拒否されるかが決定されます

ACI内のすべての権限セットには、必要な資格証明およびバインド・パラメータの詳細を示す、対応するバインド・ルールがあります。

単純なバインド・ルールでは、ディレクトリにアクセスするユーザーが特定のグループに属している必要があります。複雑なバインド・ルールでは、ユーザーが特定のグループに属し、特定のIPアドレスのマシンから午前8時から午後5時の間にログインする必要があることを設定できます。

バインド・ルールは、誰が、いつ、どこからディレクトリにアクセスできるかを定義します。具体的には、バインド・ルールは次の内容を指定できます:

- アクセス権が付与されるユーザー、グループおよびロール

- エンティティがバインドする必要のある場所(ユーザーが認証を受ける場所はなりすましの可能性があるので、信頼できません。この情報のみでACIを判断しないでください。)

- バインドを実行する必要がある時間または日付

- バインド時に使用する必要がある認証のタイプ

- セキュリティ強度係数(つまり、現在使用中の暗号化鍵の長さ)

また、第8.4項「バインドルールの構文」で説明されているように、バインド・ルールは、ブール演算子を使用して、これらの条件を組み合せた複雑な構造にできます。

ディレクトリ・サーバーは、3値ロジックに従って、ACIで使用される論理式を評価します。これは、RFC 4511 (http://www.ietf.org/rfc/rfc4511.txt)「Lightweight Directory Access Protocol (LDAP): The Protocol」で説明されているLDAPフィルタの評価に使用されるものと類似しています。つまり、式の中の任意のコンポーネントが未定義と評価される(たとえば、リソースの制限により、式の評価が中断された場合など)と、ディレクトリ・サーバーはこの状況を正しく処理します。複雑なブール式で未定義値が発生しても、間違ってアクセス権を付与することはありません。

8.3.2 ブール・バインド・ルールの使用

バインド・ルールは、ブール式AND、ORおよびNOTを使用する複合式で、細かいアクセス・ルールを設定できます。ブール・バインド・ルールを作成するときは、評価されるルールの順番を定義するために常にカッコを使用します。末尾のセミコロンは、最終ルールの後に出現する必要のある必須のデリミタです。

たとえば、bindRuleAをbindRuleB、またはbindRuleCおよびbindRuleDとバインドするには、次の構文を使用します:

(bindRuleA and (bindRuleB or (bindRuleC and bindRuleD));)

別の例を使用すると、バインドDNクライアントがexample.comドメイン内からアクセスされ、管理者グループのメンバーまたはメール管理者グループとカレンダ管理者グループの両方のメンバーである場合は、次のバインド・ルールはtrueと評価されます。

(dns = "*.example.com" and (groupdn = "ldap:///cn=administrators,dc=example,dc=com" or
(groupdn = "ldap:///cn=mail administrators,dc=example,dc=com" and
groupdn = "ldap:///cn=calendar administrators,dc=example,dc=com"));)

||演算子は、groupdnバインド・ルール・キーワード式でのみ、許可されています。その他すべてのバインド・ルール式については、or演算子を使用する必要があります。

8.4 バインド・ルールの構文

アクセスが許可されるか拒否されるかは、ACIのバインド・ルールがtrueであると評価されるかどうかによります。次の項では、バインド・ルールの構文、およびアクセスを許可または拒否するために使用される様々なキーワードについて説明します。

- 第8.4.1項「バインド・ルールの構文の概要」

- 第8.4.2項「ユーザー・アクセスの定義(userdnキーワード)」

- 第8.4.3項「グループ・アクセスの定義(groupdnキーワード)」

- 第8.4.4項「値マッチングに基づくアクセスの定義(userattrキーワード)」

- 第8.4.5項「特定のIPアドレスからのアクセスの定義(ipキーワード)」

- 第8.4.6項「特定のドメインからのアクセスの定義(dnsキーワード)」

- 第8.4.7項「特定の時刻または曜日におけるアクセスの定義(timeofdayおよびdayofweekキーワード)」

- 第8.4.8項「認証メソッドに基づくアクセスの定義(authmethodキーワード)」

- 第8.4.9項「接続のセキュリティ強度係数に基づくアクセスの定義(ssfキーワード)」

8.4.1 バインド・ルールの構文の概要

バインド・ルールは、次のパターンのうちのどちらかを使用します:

- keyword =" expression";

- keyword!=" expression";

ここで、等号(=)は、バインド・ルールをtrueとするにはキーワードと式が一致する必要があることを示し、不等号(!=)は、バインド・ルールをtrueとするにはキーワードと式が一致してはならないことを示します。

式の前後の引用符("")および区切りを示すセミコロン(;)は必須です。使用できる式は、関連付けられたキーワードによります。

timeofdayキーワードは不等式(<、<=、>、>=)もサポートします。timeofdayキーワードはこれらの式をサポートする唯一のキーワードです。

次の表に、各キーワードと関連する式をリストし、式でワイルドカード文字を使用できるかどうかについても示します。

キーワード

有効な式

ワイルドカード使用の可否

ユーザー・アクセスの定義(userdnキーワード)

ldap:///distinguishedName

ldap:///all

ldap:///anyone

ldap:///self

ldap:///parent

ldap:///suffix??sub?(filter)

可(DNのみ)

グループ・アクセスの定義(groupdnキーワード)

ldap:///DN

使用不可

値マッチングに基づくアクセスの定義(userattrキーワード)

attribute#bindTypeまたはattribute#value

使用不可

特定のIPアドレスからのアクセスの定義(ipキーワード)

IPaddress

使用可能

特定のドメインからのアクセスの定義(dnsキーワード)

DNShostName

使用可能

特定の時刻または曜日におけるアクセスの定義(timeofdayおよびdayofweekキーワード)

sun

mon

tue

wed

thu

fri

sat

使用不可

特定の時刻または曜日におけるアクセスの定義(timeofdayおよびdayofweekキーワード)

hhmm、ここでhhは00-24の範囲、mmは00-60の範囲です。

使用不可

認証メソッドに基づくアクセスの定義(authmethodキーワード)

none

simple

ssl

sasl

authenticationMethod

使用不可

接続のセキュリティ強度係数に基づくアクセスの定義(ssfキーワード)

0-256

使用不可

次の項では、各キーワードのバインド・ルール構文の詳細を説明します。

8.4.2 ユーザー・アクセスの定義(userdnキーワード)

ユーザー・アクセスは、userdnキーワードを使用して定義されます。userdnキーワードでは、次の書式で1つ以上の有効な識別名が必要です:

userdn = "ldap:///dn [|| ldap:///dn]..."

userdn!= "ldap:///dn [|| ldap:///dn]..."

ここで、dnはDNまたは式(anyone、all、selfまたはparent)の1つです。これらの式は次のユーザーを参照します:

userdn = "ldap:///anyone"

匿名ユーザーと認証ユーザーの両方

userdn = "ldap:///all"

認証ユーザーのみ

userdn = "ldap:///self"

ACIのターゲット・エントリと同じユーザーのみ

userdn = "ldap:///parent"

ACIターゲットの親エントリのみ

userdnキーワードは、次の書式でLDAPフィルタとして表すこともできます:

userdn = ldap:///suffix??sub?(filter)

カンマなどのDNの文法的な意味を持つ文字は、単一の円記号(\)でエスケープする必要があります。

次の項では、userdnキーワードを使用してユーザー・アクセスを定義する方法を説明します:

- 第8.4.2.1項「汎用アクセスの定義(allキーワード)」

- 第8.4.2.2項「匿名アクセスの定義(anyoneキーワード)」

- 第8.4.2.3項「自己アクセスの定義(selfキーワード)」

- 第8.4.2.4項「親アクセスの定義(parentキーワード)」

- 第8.4.2.5項「LDAP URLを使用したユーザーの指定」

- 第8.4.2.6項「ワイルドカードを使用したユーザーの指定」

- 第8.4.2.7項「LDAP URLの論理ORを使用したユーザーの指定」

- 第8.4.2.8項「特定のLDAP URLの除外」

8.4.2.1 汎用アクセスの定義(allキーワード)

ディレクトリに正常にバインドしたすべてのユーザーに権限が適用されることを示すために、バインド・ルールを使用することができます。したがって、allキーワードはすべての認証ユーザーによるアクセスを許可します。これは、匿名アクセスを防ぐ一方で、汎用アクセスを許可します。

たとえば、すべての認証ユーザーに、ツリー全体に対する読取りアクセスを許可するには、dc=example,dc=comノードに次のACIを作成します:

aci: (version 3.0; acl "all-read"; allow (read)
userdn="ldap:///all";)

8.4.2.2 匿名アクセスの定義(anyoneキーワード)

ディレクトリへの匿名アクセスを許可すると、バインドの状況にかかわりなく、バインドDNやパスワードを入力することなく誰でもそのディレクトリにアクセスすることができます。匿名アクセスを特定のアクセスのタイプ(たとえば、読取り用のアクセスや検索用のアクセスなど)に制限したり、ディレクトリ内の特定のサブツリーや個々のエントリに制限できます。anyoneキーワードを使用した匿名アクセスは、認証ユーザーによるアクセスも許可します。

たとえば、example.comツリー全体に対する匿名の読取りおよび検索アクセスを許可するには、dc=example,dc=comノードに次のACIを作成します:

aci: (version 3.0; acl "anonymous-read-search";
allow (read, search) userdn = "ldap:///anyone";)

8.4.2.3 自己アクセスの定義(selfキーワード)

ユーザー自身のエントリに対して、ユーザーがアクセス権を付与または拒否されていることを指定します。この場合、バインドDNがターゲット・エントリのDNと一致しているかどうかで、アクセスが許可または拒否されます。たとえば、example.comツリーのすべてのユーザーにuserPassword属性への書込み権限を付与するには、dc=example,dc=comノードに次のACIを作成します。

aci: (targetattr = "userPassword") (version 3.0; acl
"modify own password"; allow (write) userdn = "ldap:///self";)

8.4.2.4 親アクセスの定義(parentキーワード)

ユーザーのバインドDNがターゲット・エントリの親である場合にかぎり、ユーザーがエントリへのアクセスを許可または拒否されることを指定します。たとえば、バインドDNの任意の子エントリをユーザーが変更できるようにするには、dc=example,dc=comノードに次のACIを作成します:

aci: (version 3.0; acl "parent access";
allow (write) userdn="ldap:///parent";)

8.4.2.5 LDAP URLを使用したユーザーの指定

次の例に示されているようなフィルタ付きのURLを使用して、ACI内で動的にユーザーをターゲットにできます:

userdn = "ldap:///suffix??sub?(filter)"

たとえば、example.comツリーのaccounting分岐とengineering分岐のすべてのユーザーは、次のURLに基づいて動的にターゲット・リソースへのアクセスを許可または拒否されます:

userdn = "ldap:///dc=example,dc=com??sub?(|(ou=eng)(ou=acct))"

LDAP URL内でホスト名またはポート番号を指定しないでください。LDAP URLは常にローカル・ディレクトリ・サーバーに適用されます。

8.4.2.6 ワイルドカードを使用したユーザーの指定

ワイルドカード文字(*)を使用して、ユーザーのセットを指定することもできます。たとえば、uid=b*,dc=example,dc=comのユーザーDNを指定すると、文字bで始まるバインドDNを持つユーザーのみが、設定された権限に基づいてアクセスを許可または拒否されることを示します。

8.4.2.7 LDAP URLの論理ORを使用したユーザーの指定

ユーザー・アクセスに複雑なルールを作成するために、いくつかのLDAP URLまたはキーワード式を指定します。例:

userdn = "ldap:///uid=b*,c=example.com ||
ldap:///cn=b*,dc=example,dc=com";

バインド・ルールは、DNパターンのいずれかでバインドされたユーザーに対して、trueと評価されます。

8.4.2.8 特定のLDAP URLの除外

特定のURLまたはDNを除外するユーザー・アクセスを定義するのに非等号(!=)演算子を使用します。例:

userdn != "ldap:///uid=*,ou=Accounting,dc=example,dc=com";

クライアントがaccountingサブツリー内でUIDベースの識別名としてバインドしていない場合、バインド・ルールはtrueと評価されます。このバインド・ルールは、ターゲット・エントリがディレクトリ・ツリーのaccounting分岐の下にない場合にのみ、意味を持ちます。

8.4.3 グループ・アクセスの定義(groupdnキーワード)

特定のグループのメンバーは、ターゲット・リソースにアクセスできます。これはグループ・アクセスと呼ばれています。グループ・アクセスは、ユーザーが特定のグループに属するDNを使用してバインドする場合、ターゲット・エントリへのアクセスが許可または拒否されるのを指定するために、groupdnキーワードを使用して定義されます。

groupdnキーワードは、次の形式で1つ以上の識別名が必要です:

groupdn="ldap:///groupDN [|| ldap:///groupDN]..."

バインドDNが任意のグループDNで指定されたグループに属する場合、バインド・ルールはtrueと評価されます。次の項では、groupdnキーワードを使用した例を示します。

カンマなどのDNの文法的な意味を持つ文字は、単一の円記号(\)でエスケープする必要があります。

8.4.3.1 単一のLDAP URLを使用したグループの指定

groupdn = "ldap:///cn=Administrators,dc=example,dc=com";

バインドDNが管理者グループに属する場合、バインド・ルールはtrueと評価されます。たとえば、管理者グループにディレクトリ・ツリー全体への書込みの権限を付与する場合は、次のACIをdc=example,dc=comノードに作成します:

aci: (version 3.0; acl "Administrators-write"; allow (write)
groupdn="ldap:///cn=Administrators,dc=example,dc=com";)

8.4.3.2 LDAP URLの論理ORを使用したグループの指定

groupdn = "ldap:///cn=Administrators,dc=example,dc=com ||
ldap:///cn=Mail Administrators,dc=example,dc=com";

バインドDNが管理者グループまたはメール管理者グループに属する場合、バインド・ルールはtrueと評価されます。

8.4.4 値マッチングに基づくアクセスの定義(userattrキーワード)

userattrキーワードは、バインドに使用するエントリ(バインド・エントリ)とターゲット・エントリの間で、一致する必要がある属性値を指定するのに使用できます。userattr式は、バインド・タイプ・フォーマットと属性値フォーマットの2つの形式があります。

次の項では、値マッチングに基づいたアクセスを定義する方法を説明します:

- 第8.4.4.1項「バインド・タイプ・フォーマット」

- 第8.4.4.2項「属性値フォーマット」

- 第8.4.4.3項「USERDNバインド・タイプの例」

- 第8.4.4.4項「GROUPDNバインド・タイプの例」

- 第8.4.4.5項「LDAPURLバインド・タイプの例」

- 第8.4.4.6項「属性値の例」

- 第8.4.4.7項「継承」

- 第8.4.4.8項「継承の例」

- 第8.4.4.9項「追加権限」

8.4.4.1 バインド・タイプ・フォーマット

この形式は、一致を評価するときにバインドDN、およびおそらくバインド・エントリを使用するため、バインド・タイプ・フォーマットと名付けられます。これは、2つの形式の中でより複雑な形式です。バインド・タイプ・フォーマットは、次の3つの方法で使用できます:

- ターゲット・エントリの属性値をバインドDNに一致するDNとして扱います。

- ターゲット・エントリの属性値を、バインドDNがメンバーである必要があるグループDNとして扱います。

- バインドDNとバインド·エントリの両方が、ターゲット・エントリの属性値に指定されているLDAP URLと一致している必要があります。

バインド・タイプuserattr形式は、次の構文を使用します:

userattr = "attrName#bindType"

ここで:

attrName

ターゲット・エントリの属性の名前です。

bindType

次のいずれかを指定する必要があります:

- USERDN — attrNameの値はバインドDNと一致する必要があります。

- GROUPDN — attrNameの値は、バインドDNを含む必要のあるグループです。

- LDAPURL — attrNameの値は、バインドDNとエントリが一致する必要がある検索として扱われる「URL」(付録D)です。検索を実行するためには、URLのdn値がベースDNとして使用されます。ベースDNは、バインドDNと一致するか、またはバインドDNが親DNとしてそれを持つ必要があります。URLのscope値は、ベースDNのどの程度下位までバインドDNが一致できるかを制限します。最終的に、バインド・エントリはURLのfilter値と一致する必要があります。

バインド・タイプuserattr形式は、現在のターゲット・エントリの下のエントリ・レベルのターゲット指定を許可する特別な親キーワードを持っています。このキーワードに関する詳細は、第8.4.4.7項「継承」を参照してください。

8.4.4.2 属性値フォーマット

属性値フォーマットは、次の2つの条件に一致する必要があります:

- userattr式で指定された属性は、ターゲット・エントリおよびバインド・エントリの両方で存在する必要があります。

- これらの属性の両方の値は、userattr式で指定された文字列の値に一致する必要があります。この文字列の値には、バインド・タイプのキーワード(USERDN、GROUPDN、LDAPURL)のいずれも指定することはできません。

属性値userattr形式は、次の構文を使用します:

userattr = "attrName#attrValue"

ここで:

attrName

ターゲット・エントリとバインド・エントリの両方の属性の名前です。

attrValue

属性値(USERDN、GROUPDNまたはLDAPURLではない)を示す文字列です。

8.4.4.3 USERDNバインド・タイプの例

バインド・ルールuserattrキーワード式の次の例は、バインドDNとターゲット・エントリの属性managerの値の一致を指定します。

userattr = "manager#USERDN"

バインドDNがターゲット・エントリのmanager属性の値と一致する場合、このバインド・ルールはtrueと評価されます。ターゲット・エントリのmanager属性は、バインドDNと一致する必要があります。ワイルドカードは使用できません。

次の例では、ACIは、DNdc=example, dc=commの下のサブツリーに位置するエントリのすべてのユーザー属性への完全なアクセス権をマネージャに付与します:

aci: (target="ldap:///dc=example,dc=com")(targetattr="*")
(version 3.0;acl "manager all access";
allow (all) userattr = "manager#USERDN";)

8.4.4.4 GROUPDNバインド・タイプの例

次は、バインドDNがメンバーである必要があるグループDNを含む属性を指定するバインド・ルールuserattrキーワード式の例です。

userattr = "owner#GROUPDN"

バインドDNがターゲット・エントリのowner属性で指定されたグループのメンバーである場合、バインド・ルールはtrueと評価されます。

8.4.4.5 LDAPURLバインド・タイプの例

これは、バインドDNとエントリが一致している必要がある検索として扱われるLDAP URLを含む属性を指定するバインド・ルールuserattrキーワード式の例です。

userattr = "aciurl#LDAPURL"

属性aciurlは一例です。

バインドDNとバインド・エントリがLDAP URLで指定される検索要件のすべてを満たす場合、バインド・ルールはtrueと評価されます。たとえば、aciurlの値がldap:///dc=example,dc=com??one?(cn=joe*)である場合、バインドDNはdc=example,dc=comのベースDNの下で1レベル検索を満たし、バインド・エントリはフィルタ(cn=joe*)を満たす必要があります。

8.4.4.6 属性値の例

次は、バインド・エントリとターゲット・エントリの両方が一致する必要がある属性値を指定するバインド・ルールuserattrキーワード式の例です。

userattr = "favoriteBeverage#Water"

バインド・エントリとターゲット・エントリにWaterの値のfavoriteBeverage属性が含まれる場合、バインド・ルールはtrueと評価されます。

8.4.4.7 継承

userattrキーワードを使用してバインドに使用されるエントリをターゲット・エントリに関連付けると、ACIは指定されたターゲットにのみ適用され、下位のエントリには適用されません。状況によっては、ターゲット・エントリの数レベル下位のACIのアプリケーションを拡張することもできます。これは、parentキーワードを使用し、ACIを継承するターゲットの下のレベルの数を指定することで可能です。

parentキーワードと関連してuserattrキーワードを使用する場合は、構文は次の例のようになります:

userattr = "parent[[inheritanceLevel].attribute#bindType"

ここで:

- inheritanceLevelは、カンマ区切りのリストで、ターゲットのいくつ下のレベルまでACIを継承するかを示します。ターゲット・エントリの10レベル[0,1,2,3,4,..,9]下まで含めることができます。0は、ターゲット・エントリを示します。

- attributeは、userattrのターゲットとなる属性です。

- bindTypeは、USERDNまたはGROUPDNのどちらかです。LDAPURLバインド・タイプは、継承ではサポートされていません。

たとえば、バインドDNがターゲット・エントリのmanager属性と一致する場合、userattr = "parent[[0,1].manager#USERDN"バインドルールはtrueと評価されます。また、バインド・ルールは、バインドDNと一致するmanager属性を持つターゲット・エントリのすぐ下(ターゲットの1レベル下)のすべてのエントリに対して、trueと評価されます。

8.4.4.8 継承の例

次の例は、ユーザーbjensenが、cn=Profilesエントリおよびcn=mailとcn=newsを含む子エントリの最初のレベルに対して、読取りと検索を許可されることを示しています。

cn=Profiles
aci:(targetattr="*")(version 3.0, acl "profiles access" allow(read, search)
userattr="parent[[0,1].owner#USERDN;)
owner=cn=bjensen, ou=people, dc=example, dc=com
cn=mail, cn=Profiles
mailuser: bjensen
cn=news, cn=Profiles
newuser: bjensen

継承がこの例で使用されない場合は、次のいずれかを実行する必要があります:

- ディレクトリ内のcn=Profiles、cn=mailおよびcn=newsエントリに、ユーザーbjensenの読取りおよび検索アクセスを明示的に設定します。

- cn=mail、cn=Profilesおよびcn=news,cn=Profilesエントリに所有者属性および次のACIを追加します:

aci: (targetattr="*") (version 3.0; acl "profiles access"; allow
(read,search) userattr="owner#USERDN";)

8.4.4.9 追加権限

userattrキーワードをallまたはadd権限と組み合せて使用すると、サーバーの動作が想定どおりにならない場合があります。通常、新しいエントリがディレクトリに作成されると、ディレクトリ・サーバーは作成されたエントリのアクセス権を評価し、親エントリのアクセス権は評価しません。ただし、userattrキーワードを使用するACIの場合は、この動作によってセキュリティ・ホールが生じる可能性があるので、これを避けるためにディレクトリ・サーバーの通常動作は変更されます。

次の例ACIを考えてみます:

aci: (target="ldap:///dc=example,dc=com")(targetattr="*")
(version 3.0; acl "manager-write"; allow (all)
userattr = "manager#USERDN";)

このACIは、部下のエントリに対するすべての権限をマネージャに与えます。ただし、新しく作成されるエントリについてアクセス権が評価されるので、このタイプのACIでは、すべての社員に対して、manager属性が自身のDNに設定されるエントリの作成を許可します。たとえば、会社に不満を抱くJoeという社員(cn=Joe,ou=eng,dc=example,dc=com)は、ツリーのHuman Resources分岐にエントリを作成して、Human Resourcesの社員に付与された権限を使用(悪用)できます。

これは、次のエントリを作成することで可能です:

dn: cn= Trojan Horse,ou=Human Resources,dc=example,dc=com
objectclass: top
...
cn: Trojan Horse
manager: cn=Joe,ou=eng,dc=example,dc=com

このようなセキュリティ上の危険を回避するために、ACIの評価プロセスでは、レベル0の追加権限、つまりエントリ自身に対する追加権限を付与しません。ただし、既存エントリの下位にあるエントリには、parentキーワードを使用して追加アクセス権を付与できます。親のいくつ下のレベルまで追加アクセス権を許可するかを指定する必要があります。たとえば、次のACIでは、バインドDNと一致するmanager属性を持つdc=example,dc=com内の任意のエントリに子エントリを追加できます:

aci: (target="ldap:///dc=example,dc=com")(targetattr="*")
(version 3.0; acl "parent-access"; allow (add)
userattr = "parent[1].manager#USERDN";)

このACIでは、バインドDNが親エントリのmanager属性と一致しているユーザーのみに追加権限が付与されます。

8.4.5 特定のIPアドレスからのアクセスの定義(ipキーワード)

バインド・ルールを使用して、バインド操作を特定のIPアドレスから行う必要があることを示すことができます。これは多くの場合、特定のマシンまたはネットワーク・ドメインからすべてのディレクトリの更新が強制的に実行されるようにするために使用されます。

IPアドレスに基づくバインド・ルールを設定するためのLDIF構文は、次のとおりです:

ip = "IPaddressList"
ip != "IPaddressList"

IPaddressListは、次のうちの1つ以上のカンマ区切り要素のリストです:

- 特定のIPv4アドレス(123.45.6.7など)

- IPv4/CIDRに準拠したアドレス(192.168.0.0/16など)

- サブネットワークを指定するためのワイルドカードを含むIPv4アドレス(12.3.45.*など)

- サブネットワーク・マスクを含むIPv4アドレスまたはサブネットワーク(123.45.6.*+255.255.255.192など)

- 有効な形式で大カッコ([と])を含むIPv6アドレス(RFC 2373 (http://www.ietf.org/rfc/rfc2373.txt)およびRFC 2732 (http://www.ietf.org/rfc/rfc2732.txt)で定義されています)次のアドレスは同等です:

- ldap://[12AB:0000:0000:CD30:0000:0000:0000:0000]

- ldap://[12AB::CD30:0:0:0:0]

- ldap://[12AB:0:0:CD30::]

- サブネット接頭辞長を含むIPv6アドレス(ldap://[12AB::CD30:0:0:0:0]/60など)

ディレクトリにアクセスするクライアントが指定されたIPアドレスに位置している場合、バインド・ルールはtrueと評価されます。これは、特定のサブネットまたはマシンのみから特定の種類のディレクトリ・アクセスを可能にするために役立ちます。ユーザーが認証を受けるIPアドレスはなりすまされる可能性があるため、信頼できないことに注意してください。ACIでは、これらの情報のみに依存にしないでください。

8.4.6 特定のドメインからのアクセスの定義(dnsキーワード)

バインド・ルールによって、バインド操作を特定のドメインまたはホスト・マシンから行う必要があることを指定できます。これは多くの場合、特定のマシンまたはネットワーク・ドメインからすべてのディレクトリの更新が強制的に実行されるようにするために使用されます。

DNSホスト名に基づくバインド・ルールを設定するためのLDIF構文を次に示します:

dns = "DNShostname"
dns != "DNShostname"

注意:

dnsキーワードを使用する場合、マシンで使用されるネーミング・サービスはDNSである必要があります。ネーミング・サービスがDNSでない場合、かわりにipキーワードを使用する必要があります。

dnsキーワードには、完全修飾DNSドメイン名が必要です。ドメインを指定せずにホストへのアクセスを許可すると、セキュリティの脅威がもたらされる可能性があります。たとえば、次の式は使用できますが、お薦めできません:

dns = "legend.eng";

次のような完全修飾名を使用する必要があります:

dns = "legend.eng.example.com";

dnsキーワードでは、ワイルドカードを使用できます。例:

dns = "*.example.com";

ディレクトリにアクセスするクライアントが指定されたドメインに位置している場合、バインド・ルールはtrueと評価されます。これは、特定のドメインからのアクセスのみを許可する場合に役立ちます。システムでDNS以外のネーミング・サービスを使用している場合、ワイルドカードは機能しません。特定のドメインへのアクセスを制限したい場合は、第8.4.5項「特定のIPアドレスからのアクセスの定義(ipキーワード)」に説明されているように、ipキーワードを使用します。

8.4.7 特定の時刻または曜日におけるアクセスの定義(timeofdayおよびdayofweekキーワード)

バインド・ルールを使用して、特定の時刻または曜日だけにバインドするように指定できます。たとえば、月曜日から金曜日の午前8時から午後5時までの間のみ、アクセスを許可するようにルールを設定できます。アクセス権の評価に使用される時刻は、ディレクトリ・サーバー上の時刻で、クライアント上の時刻ではありません。

時刻に基づくバインド・ルールを設定するためのLDIF構文は、次のとおりです:

timeofday operator "time"

ここで、operatorは次の記号のいずれかになります:

- =(等しい)

- !={等しくない}

- >(より大きい)

- >=(以上)

- <(より小さい)

- <=(以下)

時刻は、24時間制で時と分を表す4桁で表現されます(hhmm、ここでhhは00-24の範囲、mmは00-60の範囲です)。例:

- timeofday = "1200";は、システム時刻が正午を示す1分間にクライアントがディレクトリにアクセスする場合、trueになります。

- timeofday!= "0100";は、午前1時以外の任意の時刻のアクセスに対して、trueになります。

- timeofday> "0800";は、午前8:01から午後11:59のアクセスに対して、trueになります。

- timeofday>= "0800";は、午前8:00から午後11:59のアクセスに対して、trueになります。

- timeofday< "1800";は、夜12:00から午後5:59のアクセスに対して、trueになります。

timeofdayおよびdayofweekバインド・ルールの評価には、ディレクトリ・サーバー上の日付と時刻が使用されます(クライアント上の日時ではありません)。

曜日に基づくバインド・ルールを設定するためのLDIF構文は、次のとおりです:

dayofweek = "day1, day2 ..."

dayofweekキーワードに指定できる値は、英語の曜日の3文字の略語で、sun、mon、tue、wed、thu、fri、satです。アクセスを許可するすべての曜日を指定します。例:

dayofweek = "mon, tue, wed, thu, fri";

リストされているいずれかの曜日にディレクトリにアクセスする場合、バインド・ルールはtrueになります。

8.4.8 認証メソッドに基づくアクセスの定義(authmethodキーワード)

クライアントが特定の認証メソッドを使用してディレクトリにバインドする必要があることを示すバインド・ルールを設定できます。次に示す認証メソッドを使用できます:

None

認証は不要です。これはデフォルトです。匿名アクセスを示します。

Simple

クライアントは、ディレクトリにバインドするためにユーザー名とパスワードを入力する必要があります。

SSL

クライアントは、Secure Sockets Layer (SSL)またはTransport Layer Security (TLS)接続でディレクトリにバインドする必要があります。

SSLの場合、接続はLDAPSの2番目のポートに確立されます。TLSの場合は、接続はStart TLS操作を介して確立されます。どちらの場合も、証明書が提供される必要があります。SSLの設定については、第20.6項「SASL認証の使用」を参照してください。

SASL

クライアントは、Simple Authentication and Security Layer (SASL)メカニズム(たとえば、DIGEST-MD5やGSSAPI)を使用してディレクトリにバインドする必要があります。

認証メソッドに基づくバインド・ルールを設定するためのLDIF構文を次に示します:

authmethod = "authentication_method"

ここで、authentication_methodはnone、simple、sslまたはsasl sasl_mechanismです。

8.4.8.1 認証メソッドの例

次の例は、authmethodキーワードの典型的な仕様を示します:

authmethod = "none"

バインド・ルールの評価時に、認証はチェックされません。

authmethod = "simple"

クライアントがユーザー名とパスワードを使用してディレクトリにアクセスする場合、バインド・ルールはtrueと評価されます。

authmethod = "ssl"

クライアントがLDAPSで証明書を使用してディレクトリに対して認証される場合、バインド・ルールはtrueと評価されます。クライアントがLDAPSで簡易認証(バインドDNとパスワード)を使用して認証される場合、trueにはなりません。

authmethod = "sasl DIGEST-MD5"

クライアントがSASL DIGEST-MD5メカニズムを使用してディレクトリにアクセスする場合、バインド・ルールはtrueと評価されます。この他にSASLメカニズムをサポートしているのは、EXTERNALおよびGSSAPIです。

8.4.9 接続のセキュリティ強度係数に基づくアクセスの定義(ssfキーワード)

バインド・ルールを使用すると、確立された接続で適用されている特定のレベルのセキュリティ強度係数(SSF)のみに基づいてバインドするように指定できます。接続のSSFは、接続で適用されている暗号の鍵の強度に基づいており、TLS/SSLまたはDIGEST-MD5/GSSAPIの機密保護接続または整合性接続のみに関連します。

セキュリティ強度係数に基づくバインド・ルールを設定するためのLDIF構文は、次のとおりです:

ssf operator "strength"

ここで、operatorは次の記号のいずれかになります:

- =(等しい)

- !=(等しくない)

- >(より大きい)

- >=(以上)

- <(より小さい)

- <=(以下)

強度は、接続で必要とされている暗号の鍵の強度を示す値で、0から256の値です。整合性が適用されているDIGEST-MD5/GSSAPI接続は、1のSSFを持ちます。TLS/SSLとDIGEST-MD5/GSSAPIの機密保護接続は、ディレクトリ·サーバーとクライアントとの間で行われる暗号ネゴシエーションに基づいて、SSFの変数の値を持つことができます。接続のネゴシエートされたSSFが大きいほど、接続における暗号化は強力になります。次に例を示します:

- ssf = "1";は、整合性ssf = 1のみが接続で適用されている場合のアクセスに対して、trueになります。

- ssf!= "40";は、ssf not equal 40が接続で適用されている場合のアクセスに対して、trueになります。

- ssf> "128";は、ssf greater than 128が接続で適用されている場合のアクセスに対して、trueになります。

- ssf>= "128";は、ssf greater than or equal 128が接続で適用されている場合のアクセスに対して、trueになります。

- ssf< "56";は、ssf less than 56が接続で適用されている場合のアクセスに対して、trueになります。

クリアな接続は、SSF0になります。

次の項では、接続のセキュリティ強化係数キーワードに基づいた定義の方法について説明します。

8.4.9.1 DIGEST-MD5 QOPのキー・サイズ・マッピング

次の表は、キー・サイズ・マッピングを暗号化する保護の品質(QOP)を説明します。

暗号

QOP

説明

RC4 (40)

低

40ビット・キーを使用したRC4暗号(廃止)

RC4 (56)

中

56ビット・キーを使用したRC4暗号

DES

中

56ビット・キーを使用した暗号ブロック連鎖(CBC)モードのデータ暗号化規格(DES)の暗号

RC4 (128)

高

128ビット・キーを使用したRC4暗号

トリプルDES

高

各Eステージで同じ鍵を持つEDEのCBCモード(2キー・モードとも呼ばれます)のトリプルDES暗号(鍵の長さの合計は112ビット)

8.4.9.2 TLS暗号のキー・サイズ・マッピング

暗号

TLS RFC

キー・サイズ

説明

RC2_CBC_40

4346

40

暗号ブロック連鎖(CBC)モードのRC2暗号(廃止)

RC4_40

4346

40

RC4暗号(廃止)

DES40_CBC

4346

40

暗号ブロック連鎖(CBC)モードのDES 40ビット暗号(廃止)

DES_CBC

4346

56

暗号ブロック連鎖(CBC)モードのDES 56ビット暗号

3DES_EDE_CBC

4346

112

TDES

RC4_128

4346

128

RC4暗号

IDEA_CBC

4346

128

暗号ブロック連鎖(CBC)モードの国際データ暗号化アルゴリズム(IDEA)の暗号

SEED_CBC

4162

128

暗号ブロック連鎖(CBC)モードのSEED暗号

CAMELLIA_128_CBC

4132

128

暗号ブロック連鎖(CBC)モードのCamellia暗号

AES_128_CBC

3268

128

暗号ブロック連鎖(CBC)モードの拡張暗号化規格(AES)

AES_256_CBC

3268

256

暗号ブロック連鎖(CBC)モードの拡張暗号化規格(AES)

CAMELLIA_256_CBC

4132

256

暗号ブロック連鎖(CBC)モードのCamellia暗号

AES_256_GCM

5288

256

Galois Counter Mode (GCM)のAES

8.4.9.3 例

次のACIは、SSF強度が128以上の接続を介してのみ、ユーザーに自身のパスワードを変更することを許可します:

(targetattr="userPassword||authPassword")(version 3.0; acl "User change pwd";
(allow (write) userdn="ldap:///self" and ssf >= "128");)

8.5 Oracle Directory Server Enterprise Editionのアクセス制御モデルとの互換性

次の項では、Oracle Unified Directoryのアクセス制御モデルがOracle Directory Server Enterprise Editionで提供されるアクセス制御モデルとどのように異なるのかを説明します。

- 第8.5.1項「グローバルACI」

- 第8.5.2項「識別名(DN)のワイルドカード・マッチング」

- 第8.5.3項「特権サブシステムの影響」

- 第8.5.4項「targetscopeキーワード」

- 第8.5.5項「LDAPの変更の増分」

- 第8.5.6項「マクロのサポート」

- 第8.5.7項「rolednキーワード」

8.5.1 グローバルACI

グローバルACIの構成は、2つの点で、Oracle Directory Server Enterprise EditionのグローバルACIの実装と異なります:

- ds-config-global-aci属性は、ACIをルートのDSEエントリに配置するのではなく、cn=Access Control Handler,cn=configエントリ(第8.1項「アクセス制御の原則」を参照)のグローバルACIを指定します。

- ACIでターゲット・キーワードを指定することで、グローバルACIの有効範囲を絞り込むことができます。たとえば、次のグローバルACIは、接尾辞dc=example,dc=comの下のエントリへの匿名の読取りアクセスを制限します:

ds-cfg-global-aci: (target="dc=example,dc=com")
(targetattr!="userPassword||authPassword")
(version 3.0; acl "Anonymous read access only under dc=example,dc=com suffix";
allow (read,search,compare) userdn="ldap:///anyone";)

(target="dc=example,dc=com")式の削除は、Oracle Unified Directoryのすべてのエントリに対してACIをグローバルにします。

8.5.2 識別名(DN)のワイルドカード・マッチング

ACIのDNワイルドカード・マッチングの実装は、次の使用法をサポートしています:

- ワイルドカードはいくつでも相対識別名(RDN)の属性値に使用することができ、それらはゼロ個以上の文字と一致します(文字列のフィルタと同様)。たとえば、バインド・ルールは次のDNに一致します。uid=bob jensen,dc=example,dc=comおよびuid=bjensen,dc=example,dc=com:

userdn="ldap:///uid=b*jensen*,dc=example,dc=com"

最初のRDNの属性のタイプが一致しないため、DNcn=bill jensen,dc=example,dc=comと一致しません。

- 単一のワイルドカードも、任意のRDNの属性タイプと一致させるために使用することができます。(この場合のワイルドカードは、簡略化して省略することができます)。たとえば、これら2つのバインド・ルールは、まったく同じ動作をします:

userdn="ldap:///*=bjensen, dc=example, dc=com"
userdn="ldap:///bjensen, dc=example, dc=com"

それらは両方とも、次のDNに一致します: uid=bjensen,dc=example,dc=comおよびcn=bjensen,dc=example,dc=com

- 単一のワイルドカードは、単一または複数の値を持つことのできる1つのRDNコンポーネントと正確に一致させるのに使用することができます。たとえば、次のバインド・ルールはDNuid=jensen,dc=example,dc=comおよびcn=smith,dc=example,dc=comに一致します:

userdn="ldap:///*,dc=example,dc=com"

- ダブル・ワイルドカードは1つ以上のRDNコンポーネントを一致させるのに使用できます。たとえば、次のバインド・ルールはDNuid=jensen,ou=people,dc=example,dc=comおよびuid=jensen,ou=sales,ou=people,dc=example,dc=comに一致します:

userdn="ldap:///uid=bjensen,**,dc=example,dc=com"

8.5.3 特権サブシステムの影響

Oracle Directory Server Enterprise Editionは権限をサポートしていません。特権サブシステム(第23.2項「rootユーザーと特権サブシステム」を参照してください)は、2つの点でACIに影響を与えます:

- ds-privilege-name: bypass-acl権限を持つユーザーは、アクセス制御の評価をバイパスすることができます。

- アクセス制御ルールを変更する必要のあるユーザーは、ds-privilege-name: modify-acl権限が必要です。

注意:

Lightweight Directory Access Protocol (LDAP)のプロキシ設定された認可制御(https://opends.dev.java.net/public/standards/rfc4370.txt)の使用は、バインド・ユーザーがds-privilege-name: proxied-auth権限を持っていることを必要とします。プロキシ設定された認可制御が使用されている場合、ds-privilege-name: bypass-acl権限の評価は、プロキシ・ユーザーではなく、バインド・ユーザーを使用して実行されます。

プロキシ・ユーザーがACIアクセス評価をバイパスするのを許可するため、一般に、ユーザーはds-privilege-name: proxied-auth権限とds-privilege-name: bypass-acl権限を両方同時に持つべきではありません。

8.5.4 targetscopeキーワード

targetscopeキーワードは新しいスコープが組み込まれていることにより、Oracle Directory Server Enterprise Editionとは異なります:

subordinate

ターゲット・リソースの下のサブツリーにのみACIを制限します。

8.5.5 LDAPの変更の増分

Oracle Unified Directoryは、LDAPの変更増分の拡張(https://opends.dev.java.net/public/standards/rfc4525.txt)をサポートします。この拡張は、Oracle Directory Server Enterprise Editionではサポートされていません。増分される属性は、書込み権限を持っている必要があります。

8.5.6 マクロのサポート

Oracle Unified DirectoryはACIでマクロをサポートします。

8.5.7 rolednキーワード

ロールはOracle Unified Directoryでサポートされていないので、rolednキーワードは使用できません。同等の機能は、グループを使用することで得ることができます。

8.6 高度なアクセス制御のためのマクロACIの使用

ディレクトリ・ツリー構造を繰り返し使用する組織では、ディレクトリ・ツリー内のACIの数を最適化するためにマクロを使用することにより、パフォーマンスとACIのメモリー使用量を向上させることができます。ディレクトリ・ツリー内のACIの数を減らすことによって、アクセス制御ポリシーの管理が簡単になります。

この項では、マクロACIとその使用法について説明します。この項の内容は、次のとおりです:

- 第8.6.1項「マクロとは」

- 第8.6.2項「マクロACIの例」

- 第8.6.3項「マクロACIの構文」

8.6.1 マクロとは

マクロは、ACIの中でDN、またはDNの一部を表現するために使用されるプレースホルダです。マクロを使用すると、ACIのターゲット部分またはバインド・ルール部分、あるいはその両方のDNを表せます。実際の処理では、Directory ServerがLDAP操作を受け取ると、LDAP操作のターゲットとなるリソースに対してACIマクロのマッチングが行われます。このマッチングは、一致する部分文字列(存在する場合)を確認するために行われます。一致が検出された場合は、一致した部分文字列を使用してバインド・ルール側のマクロが展開され、その展開バインド・ルールを評価してリソースへのアクセス権が決定されます。

8.6.2 マクロACIの例

マクロACIを使用する利点と最も効果的に機能させる方法を、例を通して説明します。図8-1は、ACIの合計数を効果的に減らすために、マクロACIを使用しているディレクトリ・ツリーを示しています。

図8-1 マクロACIのディレクトリ・ツリーの例

この例では、同じツリー構造のサブドメインが同じパターンで繰り返されています(ou=groups, ou=people)。example.comディレクトリ・ツリーには、dc=hostedCompany2, dc=example,dc=comおよびdc=hostedCompany3,dc=example,dc=comという接尾辞が格納されているので、このパターンはツリー内でも繰り返されています。ただし、前述の図には示されていません。

ディレクトリ・ツリーに適用されるACIでも、同じパターンが繰り返されています。たとえば、次のACIはdc=hostedCompany1,dc=example,dc=com node:上に置かれています。

aci: (targetattr="*")(targetfilter=(objectClass=nsManagedDomain))
(version 3.0; acl "Domain access"; allow (read,search)
groupdn="ldap:///cn=DomainAdmins,ou=Groups,dc=hostedCompany1,dc=example,dc=com";)

このACIは、dc=hostedCompany1,dc=example,dc=comツリー内のすべてのエントリに対する読取りおよび検索権限をDomainAdminsグループに与えます。

次のACIは、dc=hostedCompany1,dc=example,dc=comノード上に置かれています:

aci: (targetattr="*")
(targetfilter=(objectClass=nsManagedDomain))
(version 3.0; acl "Domain access"; allow (read,search)
groupdn="ldap:///cn=DomainAdmins,ou=Groups,dc=hostedCompany1,dc=example,dc=com";)

次のACIは、dc=subdomain1, dc=hostedCompany1, dc=example, dc=comノード上に置かれています:

aci: (targetattr="*")
(targetfilter=(objectClass=nsManagedDomain))
(version 3.0; acl "Domain access"; allow (read,search)
groupdn="ldap:///cn=DomainAdmins,ou=Groups,dc=subdomain1,dc=hostedCompany1,
dc=example,dc=com";)

次のACIは、dc=hostedCompany2, dc=example, dc=comノード上に置かれています:

aci: (targetattr="*")
(targetfilter=(objectClass=nsManagedDomain))
(version 3.0; acl "Domain access"; allow (read,search)
groupdn="ldap:///cn=DomainAdmins,ou=Groups,dc=hostedCompany2, dc=example,dc=com";)

次のACIは、dc=subdomain1, dc=hostedCompany2, dc=example, dc=com node上に置かれています:

aci: (targetattr="*")
(targetfilter=(objectClass=nsManagedDomain))
(version 3.0; acl "Domain access"; allow (read,search)
groupdn="ldap:///cn=DomainAdmins,ou=Groups,dc=subdomain1,dc=hostedCompany2,
dc=example,dc=com";)

前述の4つのACIの違いは、groupdnキーワード内で指定されているDNのみです。DN用のマクロを使用することによって、これらのACIを、1つのACIにまとめてルート・ツリーのdc=example,dc=comノードに置くことができます。このマクロACIは次のようになります:

aci: (target="ldap:///ou=Groups,($dn),dc=example,dc=com")
(targetattr="*")(targetfilter=(objectClass=nsManagedDomain))
(version 3.0; acl "Domain access"; allow (read,search)
groupdn="ldap:///cn=DomainAdmins,ou=Groups,[$dn],dc=example,dc=com";)

以前は使用されなかったtargetキーワードは、新しいACIで使用されます。

この例では、ACIの数が4から1に減っています。本当の決定要因は、ディレクトリ・ツリー全体で繰り返されているパターンの数です。

8.6.3 マクロACIの構文

マクロACIには、DNまたはDNの一部を置き換える次のタイプの式があります:

- ($dn)

- [$dn]

- ($attr.attrName)。ここで、attrNameはターゲット・エントリに含まれる属性を表します。

この項では、userdn、roledn、groupdnおよびuserattrのようなバインド資格証明を提供するために使用されるACIキーワードをまとめてACIのサブジェクトと呼びます。サブジェクトは、ACIの適用対象を決定します。

表8-2は、特定のACIキーワードの置換に使用できるマクロを示しています。

表8-2 マクロACIキーワード

マクロ

説明

ACIキーワード

($dn)

targetでマッチングに使用され、サブジェクト内で直接置き換えられます。たとえば、targetまたはtargetfilterと一致し、一致した値はuserdn、groupdnまたはuserattrに置き換えます。

(target、targetfilter)および(userdn、groupdn、userattr)

[$dn]

サブジェクトのサブツリー内で機能する複数のRDNに置き換えられます。

(targetfilter)および(userdn、groupdn、userattr)

($attr.attrName)

ターゲット・エントリのattributeName属性の値に置き換えられて、サブジェクトに設定されます。

userdn、groupdn、userattr

マクロACIキーワードには、次のような制限が適用されます:

- ($dn)マクロをサブジェクトで使用する場合は、($dn)を含むターゲットを定義する必要があります。

- [$dn]マクロをサブジェクトで使用する場合は、($dn)を含むターゲットを定義する必要があります。

- ($dn)マクロと[$dn]マクロの両方を、サブジェクトで($attr.attrName)マクロと組み合せることができます。

次の項では、マクロACIの評価メカニズムを説明します。この項の内容は、次のとおりです:

- 第8.6.3.1項「ターゲット内での($dn)とのマッチング」

- 第8.6.3.2項「($attr.attrName)のマクロ・マッチング」

8.6.3.1 ターゲット内での($dn)マッチング

ACIのtargetに含まれる($dn)マクロを、LDAPリクエストのターゲットとなるエントリと比較することによって、実際に置き換えられる値が決定します。たとえば、このエントリをターゲットとするLDAPリクエストがあるとします:

cn=all, ou=groups, dc=subdomain1, dc=hostedCompany1, dc=example, dc=com

また、次のようなtargetを定義しているACIもあるとします:

(target="ldap:///ou=Groups,($dn),dc=example,dc=com")

($dn)マクロは"dc=subdomain1, dc=hostedCompany1"と一致します。この部分文字列は、その後、ACIのサブジェクトの置換に使用されます。

サブジェクト内での($dn)の置換

ACIのサブジェクト内では、($dn)マクロはターゲット内で一致する部分文字列全体に置き換えられます。例:

groupdn="ldap:///cn=DomainAdmins,ou=Groups,($dn),dc=example,dc=com"

このシナリオでは、ターゲット内の($dn)に一致する文字列がdc=subdomain1, dc=hostedCompany1である場合、同じ文字列がサブジェクト内で使用されます。サブジェクトは次のように展開されます:

groupdn="ldap:///cn=DomainAdmins,ou=Groups,dc=subdomain1,dc=hostedCompany1,dc=example,dc=com"

ACIのtargetfilter内では、($dn)マクロはターゲット内で一致する部分文字列全体に置き換えられます。例:

(targetattr="*")(targetfilter=(&(objectClass=nsManagedPerson)(!(memberOf=cn=ServiceAdministrators,ou=Groups,($dn),o=ace industry,c=us))(!(memberOf=cn=Service Help Desk Administrators,ou=Groups,($dn),o=ace industry,c=us))))

targetfilterは次のようになります:

(targetattr="*")(targetfilter=(&(objectClass=nsManagedPerson)
(!(memberOf=cn=ServiceAdministrators,ou=Groups,dc=subdomain1,
dc=hostedCompany1,o=ace industry,c=us))
(!(memberOf=cn=Service Help Desk
Administrators,ou=Groups,dc=subdomain1,dc=hostedCompany1,o=ace industry,c=us))))

マクロが展開されると、通常のプロセスに続いてDirectory ServerがACIを評価し、アクセス権が与えられるかどうかを決定します。

注意:

標準のACIとは異なり、マクロ置換を使用したACIはターゲット・エントリの子へのアクセスを許可する必要はありません。これは、子のDNがターゲットとなった場合に、置換によってサブジェクト文字列内に有効なDNが作成されない可能性があるためです。

サブジェクト内での[$dn]の置換

[$dn]の置換メカニズムは、($dn)と若干異なっています。一致する対象が見つかるまで、一番左にあるRDNコンポーネントを外しながら、ターゲット・リソースのDNが数回検証されます。

cn=all,ou=groups, dc=subdomain1,dc=hostedCompany1,dc=example,dc=comサブツリーをターゲットとするLDAPリクエストで、次のようなACIのシナリオがあるとします:

aci: (targetattr="*") (target="ldap:///ou=Groups,($dn),dc=example,dc=com")
(version 3.0; acl "Domain access"; allow (read,search)
groupdn="ldap:/cn=DomainAdmins,ou=Groups,[$dn], dc=example,dc=com";)

サーバーは次のように処理を続け、このACIを展開します:

1. targetの($dn)とdc=subdomain1, dc=hostedCompany1が一致することをサーバーが確認します。

2. サブジェクトの[$dn]をdc=subdomain1, dc=hostedCompany1で置き換えます。
この結果、サブジェクトはgroupdn="ldap:///cn=DomainAdmins,ou=Groups, dc=subdomain1,dc=hostedCompany1,dc=example,dc=com"になります。バインドDNがそのグループのメンバーであるため、アクセスが許可される場合は、マクロの展開は停止し、ACIが評価されます。バインドDNがメンバーでない場合は、処理を継続します。

3. サブジェクトの[$dn]をdc=hostedCompany1で置き換えます。
この結果、サブジェクトはgroupdn="ldap:///cn=DomainAdmins,ou=Groups, dc=hostedCompany1,dc=example,dc=com"になります。バインドDNはこのグループのメンバーであることを再びテストされ、メンバーである場合は、ACIは完全に評価されます。ただし、バインドDNがメンバーでない場合は、マクロの展開は最後に一致したRDNで置き換えたところで終了し、このACIに対する評価は終了します。

[$dn]マクロの利点は、ドメインレベルの管理者に対して、ディレクトリ・ツリー内のすべてのサブドメインへのアクセス権を柔軟な方法で与えられることです。したがって、[$dn]マクロは、ドメイン間の階層的な関係を表す場合に便利です。

たとえば、次のようなACIがあるとします:

aci: (target="ldap:///ou=*,($dn),dc=example,dc=com") (targetattr="*") (targetfilter=(objectClass=nsManagedDomain)) (version 3.0; acl "Domain access"; allow (read,search) groupdn= "ldap:/cn=DomainAdmins,ou=Groups,[$dn],dc=example,dc=com";)

このACIは、cn=DomainAdmins,ou=Groups, dc=hostedCompany1,dc=example,dc=comのメンバーに対して、dc=hostedCompany1の下にあるすべてのサブドメインへのアクセス権を与えます。したがって、そのグループに属する管理者は、たとえばサブツリーou=people,dc=subdomain1.1,dc=subdomain1にアクセスできます。

ただし、同時に、cn=DomainAdmins,ou=Groups, dc=subdomain1.1のメンバーのou=people,dc=subdomain1, dc=hostedCompany1およびou=people,dc=hostedCompany1ノードに対するアクセスは拒否されます。

8.6.3.2 ($attr.attrName)のマクロ・マッチング

($attr.attrname)マクロは、常にACIのサブジェクト部分で使用されます。たとえば、次のgroupdnを定義できます。

groupdn = "ldap:/cn=DomainAdmins,ou=($attr.ou),dc=HostedCompany1,dc=example,dc=com"

ここで、サーバーが次のエントリをターゲットとするLDAP操作を受け取ったとします:

dn: cn=Babs Jensen,ou=People,dc=HostedCompany1,dc=example,dc=com
cn: Babs Jensen
sn: Jensen
ou: Sales ...

ACIのgroupdn部分を評価するために、サーバーはターゲット・エントリに格納されているou属性の値を読み取ります。その後、サブジェクト内でこの値を置換してマクロを展開します。この例では、groupdnは次のように展開されます:

groupdn= "ldap:///cn=DomainAdmins,ou=Sales,dc=HostedCompany1,dc=example,dc=com"

続いて、通常のACI評価アルゴリズムに従って、Directory ServerがACIを評価します。

マクロ内で指定された属性が複数の値を持つ場合は、それぞれの値を使用して順にマクロが展開されます。最初にマッチングに成功した値が使用されます。

9 Oracle Unified Directoryスキーマ・モデルの理解

この章では、一般的なスキーマ要素を説明し、これらのスキーマ要素がOracle Unified Directoryで使用される方法を示します。

この章の内容は次のとおりです:

- 第9.1項「一致ルールの理解」

- 第9.2項「属性構文の理解」

- 第9.3項「属性タイプの理解」

- 第9.4項「オブジェクト・クラスの理解」

- 第9.5項「名前書式の理解」

- 第9.6項「DITコンテンツ・ルールの理解」

- 第9.7項「DIT構造ルールの理解」

- 第9.8項「一致ルールの使用の理解」

ldapsearchコマンドを使用してスキーマを表示する説明については、第27.4.1項「属性タイプの管理」および第27.4.2項「オブジェクト・クラスの管理」を参照してください。

9.1 一致ルールの理解

一致ルールは、同じ属性の2つの値を比較するため、すなわち、それらで一致操作を実行するためにOracle Unified Directoryで使用されます。一致ルールには、次に示すようないくつかの異なるタイプがあります

等価一致ルール

この種の一致ルールは、2つの値が論理的に等価かどうかを決定するために使用されます。等価一致ルールの実装ごとに、この決定に使用される基準は異なることがあります(たとえば、大文字/小文字の相違を無視するかどうか、どのスペースが重要かの決定など)。

順序付け一致ルール

この種の一致ルールは、2つの値の相対順序を決定するために(たとえば、次以上または次以下の検索の評価時や、結果をソートする必要があるときなど)使用されます。

部分文字列一致ルール

この種の一致ルールは、所定の部分文字列アサーションが特定の値に一致するかどうかを決定するために使用されます。部分文字列アサーションは、最大で1つのsubInitial要素、ゼロ個以上のsubAny要素、および最大で1つのsubFinal要素というセットの少なくとも1つの要素で構成されています。

近似一致ルール

この種の一致ルールは、2つの値がおおよそ等価かどうかを決定するために使用されます。これは、多くの場合、「類似しているものを検索する」などの種類のファジー・アルゴリズムに基づきます。近似一致ルールは正式なLDAP仕様の一部とはなっていませんが、Oracle Unified Directoryでは柔軟性を高めるために採用しています。

次の項では、一致ルールを説明します:

- 第9.1.1項「一致ルールの説明形式」

- 第9.1.2項「一般的に使用される一致ルール」

- 第9.1.3項「相対時間の一致ルール」

- 第9.1.4項「部分的な日付や時間の一致ルール」

- 第9.1.5項「値の正規化」

9.1.1 一致ルールの説明形式

一致ルールの説明形式は、Augmented Backus-Naur Form (ABNF)で、RFC 4512 (http://www.ietf.org/rfc/rfc4512.txt)の第4.1.3項で説明されています。ABNFに関する詳細は、RFC 4234 (http://www.ietf.org/rfc/rfc4234.txt)およびRFC 5234 (http://www.ietf.org/rfc/rfc5234.txt)を参照してください。これは、スキーマ・サブエントリのmatchingRules属性で一致ルールを表示するのに使用される形式で、一致ルールと関連付けることのできるプロパティを示します。次の例は、一致ルールの説明形式の定義を示します:

MatchingRuleDescription = LPAREN WSP
numericoid                 ; object identifier
[ SP "NAME" SP qdescrs ]   ; short names (descriptors)
[ SP "DESC" SP qdstring ]  ; description
[ SP "OBSOLETE" ]          ; not active
SP "SYNTAX" SP numericoid  ; assertion syntax
extensions WSP RPAREN      ; extensions

一致ルールの説明は、次の要素を含みます:

numericoid

数値OIDは、Oracle Unified Directoryで一致ルールを一意に識別するのに使用されます。すべての一致ルールは、一意のOIDを持っている必要があります。

NAME

名前要素は、OIDのかわりに、それを参照するために使用することができる一致ルールに割り当てられた判読可能な名前です。一致ルールは、判読可能な名前を持つ必要はありません。単一の名前を持つ場合は、それを一重引用符で囲みます。一致ルールに複数の名前がある場合は、それぞれを一重引用符で囲み、名前の間には空白を入れ、名前のセット全体をカッコで囲みます。

DESC

説明要素は、一致ルールの判読可能な説明です。最大で1つの説明があり、それが存在する場合は、一重引用符で囲む必要があります。

OBSOLETE

OBSOLETEフラグは、この一致ルールが使用可能であると見なすかどうかを示します。一致ルールがOBSOLETEにマークされた場合、この一致ルールを参照する、新しい属性タイプまたは一致ルールの使用方法を作成することはできません。

SYNTAX

構文要素は、一致ルールが関連付けられている属性構文を識別します。これは、一致ルールが操作する値に対して許容可能な形式を示すために使用されます。属性構文に関する詳細は、第9.2項「属性構文の理解」を参照してください。構文OIDは、すべての一致ルールの説明に含まれている必要があります。

拡張

一致ルールの拡張は、標準の定義に含まれない可能性があるその一致ルールの他のプロパティを識別するために使用することができます。Oracle Unified Directoryは現在、一致ルールで使用するためのいずれの拡張もサポートしていません。

たとえば、次の例は標準のcaseIgnoreMatch一致ルールの説明です:

( 2.5.13.2 NAME 'caseIgnoreMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

この場合、OIDは2.5.13.2です。caseIgnoreMatchという名前が1つあります。説明はありません。関連する構文のOIDは、1.3.6.1.4.1.1466.115.121.1.15(ディレクトリ文字列構文)です。拡張はありません。

9.1.2 一般に使用される一致ルール

LDAPで定義されている一致ルールは多数あります。それらは、コア・プロトコル仕様と同様に他の関連するRFCおよびインターネット・ドラフトの両方で定義されています。この一致ルールの多くは、RFC 4517 (http://www.ietf.org/rfc/rfc4517.txt)「LDAP構文と一致ルール」の第4.2項で定義されています。もっとも一般的に使用される一致ルールのいくつかを次に示します:

caseIgnoreMatch、caseIgnoreOrderingMatch、caseIgnoreSubstringsMatch

これらはそれぞれ、等価、順序付け、部分文字列一致ルールで、大/小文字の違いを無視し、複数の連続した空白を単一の空白として扱います。

caseExactMatch、caseExactOrderingMatch、caseExactSubstringsMatch

これらはそれぞれ、等価、順序付け、部分文字列の一致ルールで、大/小文字を区別をする方法で値を扱いますが、複数の連続した空白は、単一の空白として扱います。

octetStringMatch、octetStringOrderingMatch、octetStringSubstringsMatch

これらはそれぞれ、等価、順序付け、部分文字列の一致ルールで、バイト単位で値の比較を実行します(それらを文字列ではなくバイナリ・データとして扱います)。

numericStringMatch、numericStringOrderingMatch、numericStringSubstringsMatch

これらはそれぞれ、等価、順序付けおよび部分文字列の一致ルールで、数値の桁で始まり、数値の桁および空白のみを含む値に対して操作が行われます。これらの一致ルールでマッチングを実行するときは、空白は無視されます。

distinguishedNameMatch

これは、等価一致ルールで、識別名(DN)値に対して操作が行われます。DNコンポーネントを区切るカンマやセミコロンの前後の空白、RDNコンポーネントを区切る正符号の前後の空白、およびRDN属性タイプ名をそれらの対応する値から区切る等号の前後の空白を無視します。大/小文字の違いは、属性タイプ名では無視されます。属性値の等価一致は、対応する属性タイプ用の等価一致ルールを使用して実行されます。

doubleMetaphoneApproximateMatch

これは近似一致ルールで、比較「のような」ことを実行するためにdouble metaphoneアルゴリズムを使用します。この一致ルールは公式のLDAP仕様の一部ではなく、柔軟性の向上のためにOracle Unified Directoryに含まれていることに注意してください。

9.1.3 相対時間の一致ルール

Oracle Unified Directoryは、ここで定義されているように、「一般化時間」(付録D)属性(relativeTimeLTOrderingMatchおよびrelativeTimeGTOrderingMatch)の相対日付で一致を実行するための2つの一致ルールを提供します:

( 1.3.6.1.4.1.26027.1.4.6
NAME ( 'relativeTimeLTOrderingMatch''relativeTimeOrderingMatch.lt' )
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )

( 1.3.6.1.4.1.26027.1.4.5
NAME ( 'relativeTimeGTOrderingMatch' 'relativeTimeOrderingMatch.gt' )
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )

構文は、GeneralizedTime構文を持つ属性に適用されますが、一般化時間の文字列を取ることはありません。かわりに、[+|-]数値[単位]の形式でオフセットをとります:

+|-

過去または将来の時間を指定します。正のオフセット(+)は、現在の時間と比較して将来の時間を計算し、負のオフセット(-)は現在の時間と比較して過去の時間を計算します。デフォルトの値は正(+)です。

数値

正の整数として、時間単位の数値を指定します。

単位

単一の文字で時間の単位を指定します(秒、分、時間、日または週はそれぞれ、s、m、h、dまたはwとなります)。

フィルタを処理するときに、サーバーは、現在のGMT時間を算出し、オフセットを追加し、属性値を新しく算出された値と比較します。

次の例は、pwdExpirationTime >= (Now + 5 days)を表しています。

(pwdExpirationTime:1.3.6.1.4.1.26027.1.4.5:=5d)

同様に、次の例はpwdExpirationTime <= (Now + 5 days)を表しています。

(pwdExpirationTime:1.3.6.1.4.1.26027.1.4.6:=5d)

9.1.4 部分的な日付や時間の一致ルール

Oracle Unified Directoryは、「一般化時間」(付録D)属性の日付で部分文字列一致を実行するためにpartialDateAndTimeMatchingRule一致ルールを提供します:

( 1.3.6.1.4.1.26027.1.4.7
NAME 'partialDateAndTimeMatchingRule'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )

この一致ルールは、GeneralizedTime構文を持つ属性に適用されますが、値は一般化時間ではありません。かわりに、タグの前の1つ以上の整数のシーケンスで構成される日付のパターンを指定します。現在サポートされているタグは、Y、M、D、h、mおよびsです。

次の例では、次の定義を使用して属性birthDate (http://tools.ietf.org/html/draft-gryphon-ldap-schema-vcard4-00を参照してください)を使用しています:

attributeTypes: ( 1.3.6.1.4.1.33592.1.3.2 NAME 'birthDate'
DESC 'birthday'
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX .3.6.1.4.1.1466.115.121.1.24
USAGE userApplications SINGLE-VALUE )

たとえば、次のフィルタは9月21日に生まれたすべてのユーザーに一致します。

(birthDate:1.3.6.1.4.1.26027.1.4.7:=09M21D)

別の例では、次のフィルタは1965年に生まれたすべてのユーザーに一致します:

(birthDate:1.3.6.1.4.1.26027.1.4.7:=1965Y)

次の検索操作は、任意の月の14日が誕生日であるすべてのエントリを返します:

$ ./ldapsearch -p 1389 -h localhost -D "cn=Directory Manager" -j pwd-file \
-b "dc=example,dc=com" \
"(birthDate:1.3.6.1.4.1.26027.1.4.7:=14D)" birthDate

9.1.5 値の正規化

ほとんどの一致ルールが実行する必要のあるタスクの1つが値の正規化です。これは、指定された値を、効率的に値と比較するために使用できる形式に変換するプロセスです。ほとんどの場合、正規化プロセスでは、すべての論理的に同等の値を同じ文字列に短縮する必要があります。それによって、非常に単純な文字列の比較を実行して、文字列が等しいかどうかを決定することができます。たとえば、caseIgnoreMatch一致ルールは、通常、すべての文字を小文字に変換し、複数の連続した空白を単一の空白に置換することで値を正規化します。より複雑な例は、distinguishedNameMatch一致ルールで、すべての不要な空白(たとえば、カンマ、等号および正符号の前後)を削除して、すべての属性タイプを小文字に変換し、適切な一致ルールを使用して各RDNコンポーネントの属性値を正規化します。

場合によっては、正規化単独では、2つの値が論理的に同等であるかを判断するには不十分であることに注意してください。これは、値が変換され、同じ値に対して複数の異なる変換が存在する可能性がある場合に、特に当てはまります。

9.2 属性構文の理解

属性構文は、基本的にデータ型の定義です。属性タイプの構文は、対応する値によって保持されるデータ型を示します。これは、指定された属性で特定の値が受け入れられるかどうかを決定するのに使用されるだけではなく、Oracle Unified Directoryが既存の値とどのように相互作用するかに関する情報を提供するのにも使用されます。

Oracle Unified Directoryでは、関連付けられた属性構文に違反する値を拒否する機能をサポートしています。これは標準への準拠を目的とするデフォルトの動作です。必要であれば、この属性構文の検査を完全に無効にすることができますが、関連付けられた構文に違反する値を受け入れることも可能です。ただし、毎回これが発生するたびにOracle Unified Directoryのエラー・ログに警告メッセージが記録されます。ただし、属性がそれらの関連付けられた構文に違反する値を持つことを許可されている場合は、一致操作はそのような値では期待どおりに動作しない可能性があります。スキーマ・チェックの無効化の詳細は、第27.2項「スキーマ・チェックの構成」を参照してください。

次の項では、属性構文について説明します:

- 第9.2.1項「属性構文の説明形式」

- 第9.2.2項「一般的に使用される属性構文」

- 第9.2.3項「パターン一致の構文拡張」

- 第9.2.4項「列挙の構文拡張」

- 第9.2.5項「置換の構文拡張」

9.2.1 属性構文の説明形式

属性構文の説明形式は、RFC 4512 (http://www.ietf.org/rfc/rfc4512.txt)の第4.1.5項で説明されています。次に例を示します:

SyntaxDescription = LPAREN WSP
numericoid                 ; object identifier
[ SP "DESC" SP qdstring ]  ; description
extensions WSP RPAREN      ; extensions

属性構文の説明は、次の要素を含みます:

numericoid

数値OIDは、Oracle Unified Directoryで属性構文を一意に識別するのに使用されます。

DESC

構文のオプションの説明です。指定する場合は、一重引用符で囲む必要があります。

拡張

属性構文の拡張のオプションのセットです。Oracle Unified Directoryでは、次の拡張がサポートされています:

- X_PATTERN: 属性が正規表現構文を使用することを指定します。詳細は、第9.2.3項「パターン一致構文の拡張」を参照してください。

- X-ENUM: 属性が列挙構文を使用することを指定します。詳細は、第9.2.4項「列挙構文の拡張」を参照してください。

- X-SUBST: 属性が置換構文を使用することを指定します。詳細は、第9.2.5項「置換構文の拡張」を参照してください。

次の例では、標準のディレクトリ文字列構文の属性構文の説明を示します:

( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' )

この場合、OIDは1.3.6.1.4.1.1466.115.121.1.15で、説明はDirectory Stringです。この例では、拡張を指定していません。

9.2.2 一般的に使用される属性構文

LDAPで定義されている属性構文は多数あります。それらは、コア・プロトコル仕様と他の関連するRFCおよびインターネット・ドラフトの両方で定義されています。この属性構文の多くは、RFC 4517 (http://www.ietf.org/rfc/rfc4517.txt)「LDAP構文と一致ルール」の第3.3項で定義されています。もっとも一般的に使用される属性構文のいくつかを次に示します:

ディレクトリ文字列

Directory String構文は、1つ以上のUTF-8文字を含む汎用の文字列値を保持するために使用されます。技術的には、空の値(つまり、文字なし)は許可されていません。Oracle Directory Server Enterprise Editionは従来、空の値を許可しているため、標準コンプライアンスに対してデフォルトでは無効になっていますが、Oracle Unified Directoryは、それを許可するために使用できる構成オプションを提供しています。

IA5文字列

IA5 String構文は、ASCII文字セットとしても知られているIA5文字セットに基づいた文字列値を保持するために使用されます。

印刷可能文字列

Printable String構文は、大文字と小文字、数値の桁、一重引用符、左右のカッコ、正符号、カンマ、ハイフン、ピリオドおよび等号のセットから1つ以上の文字を含む文字列値を保持するために使用されます。

Boolean

Boolean構文は、TRUEまたはFALSEの値を保持するのに使用されます。この構文を持つ属性には、その他の値は許可されていません。

Integer

Integer構文は、少なくとも1つの数字を含む必要がある整数値を保持するために使用されます。負の値を示すためにハイフンで始めることができます。値がゼロの場合にのみ、最初の桁にゼロを使用することができます。

オクテット文字列

Octet String構文は、ゼロ以上のバイトのセットを保持するために使用されます。以前のBinary構文のかわりに使用されています。

DN

DN構文は、ゼロ以上のRDNコンポーネントで構成される識別名の値を保持するのに使用されます。値は、RFC 4514 (http://www.ietf.org/rfc/rfc4514.txt)「識別名のLDAP文字列表現」で指定されている形式である必要があります。

9.2.3 パターン一致構文の拡張

X-PATTERN属性構文の拡張は、1つ以上の正規表現によって制限された値を使用して新しい文字列構文を定義するのに使用されます。次の例では、X-PATTERN属性構文をスキーマに追加します。

$ ldapmodify -p 1389 -h localhost -D "cn=Directory Manager" -j pwd-file
dn: cn=schema
changetype: modify
add: ldapsyntaxes
ldapSyntaxes: ( 1.3.6.1.4.1.32473.1 DESC 'Host and Port in the format of HOST:PORT'
X-PATTERN '^[a-zA-Z][a-zA-Z0-9-]+:[0-9]+$' )

この新しい構文は、属性およびオブジェクト・クラスを定義するのに使用されます。次に例を示します。

$ ldapmodify -p 1389 -h localhost -D "cn=Directory Manager" -j pwd-file
dn: cn=schema
changetype: modify
add: attributetypes
attributetypes: ( 1.3.6.1.4.1.32473.2 NAME 'example-attr-regex' SYNTAX
1.3.6.1.4.1.32473.1 )
-
add: objectclasses
objectclasses: ( 1.3.6.1.4.1.32473.3 NAME 'exampleOCregex' SUP top AUXILIARY MUST
example-attr-regex)
-

example-attr-regex属性の値は、定義されたパターンに一致する必要があります。そうでなければ、サーバーがそれらを拒否します。次の属性は、例の構文で定義されたパターンに一致するので、サーバーはそれを受け入れます:

example-attr-regex: localhost:389

次の属性は、必要なコロンおよび数値文字列を含んでいないため、拒否されます:

localhost

次の属性は、HOSTコンポーネントの一部として指定されないピリオド(.)を含むため、拒否されます:

host.domain.com:389

9.2.4 列挙構文の拡張

X-ENUM属性構文の拡張は、順序付けられた定義済の値のセットに制限された値を用いて新しい文字列構文を定義するために使用されます。次の例では、X-ENUM属性をスキーマに定義します。

$ ldapmodify -p 1389 -h localhost -D "cn=Directory Manager" -j pwd-file
dn: cn=schema
changetype: modify
add: ldapsyntaxes
ldapSyntaxes: ( 1.3.6.1.4.1.32473.4 DESC 'Day Of The Week'
X-ENUM ( 'monday' 'tuesday' 'wednesday' 'thursday'
'friday' 'saturday' 'sunday' ) )

この新しい構文は、属性およびオブジェクト・クラスを定義するのに使用されます。次に例を示します。

$ ldapmodify -p 1389 -h localhost -D "cn=Directory Manager" -j pwd-file
dn: cn=schema
changetype: modify
add: attributetypes
attributetypes: ( 1.3.6.1.4.1.32473.5 NAME 'example-attr-enum' SYNTAX
1.3.6.1.4.1.32473.4 )
-
add: objectclasses
objectclasses: ( 1.3.6.1.4.1.32473.6 NAME 'exampleOCenum' SUP top AUXILIARY
MUST example-attr-enum)

example-attr-enum属性の値は、定義されたパターンに一致する必要があります。そうでなければ、サーバーがそれらを拒否します。

列挙された値は、大/小文字が区別されないので、次の例の両方が受け入れられます:

example-attr-enum: thursday
example-attr-enum: Thursday

列挙された属性値はリテラルである(国際化されていない)ので、次の例では、任意のセマンティック等価にかかわらず、パターンと一致せずに拒否されます:

example-attr-enum: jeudi

定義された値は順序を指定するので、列挙された属性は、相対的な比較フィルタで使用することができます。次に例を示します:

(example-attr-enum>=wednesday)

前述の比較フィルタは、たとえば、thursdayの値に一致します。比較は、列挙された値の順序に基づき、この場合は、ASCII値は適用されません。

9.2.5 置換構文の拡張

X-SUBST属性構文の拡張を使用して、既存の構文を用いた値で新しい文字列構文を定義できます。Oracle Unified Directoryでサポートされていない構文を使用する非標準スキーマ(または外部スキーマ)で、ネイティブ・ディレクトリ・サーバーのスキーマを拡張するときに使用するために提供されています。インポートされたスキーマを変更するかわりに、X-SUBST拡張を使用してそれを拡張し、サポートされている構文を用いて値を処理するようにOracle Unified Directoryに指示します。

次の例では、新しい構文(AttCertPath)を既存の構文(1.3.6.1.4.1.1466.115.121.1.15ディレクトリ文字列)を用いて定義します。この変更は、cn=schemaの下で行う必要があります。

$ ldapmodify -p 1389 -h localhost -D "cn=Directory Manager" -j pwd-file
dn: cn=schema
objectClass: top
objectClass: ldapSubentry
objectClass: subschema
ldapSyntaxes: ( 1.3.6.1.4.1.4203.666.11.10.2.4
DESC 'AttCertPath'
X-SUBST '1.3.6.1.4.1.1466.115.121.1.15' )

この機能は、移行時に便利であり、スキーマへの影響を軽減することができます。たとえば、Oracle Unified Directoryへの移行時には、受信スキーマは、定義されていない構文を使用する属性定義を含むことができます。X-SUBST属性構文の拡張は、他の、より一般的な構文を用いてそれらの不足している構文を定義する方法を提供します。スキーマおよびデータは、この機能により、スキーマまたはデータを変更したり、新たな構文を実装したりする必要なしに移行することができます。

9.3 属性タイプの理解

属性タイプは、Oracle Unified Directoryで使用できる属性のセット、およびこれらの属性に関する操作の実行方法を定義します。特に、属性構文および一致ルールのセットを一意のOIDおよび判読可能な名前を結び付けます。

次の項で、属性タイプについて説明します:

- 第9.3.1項「属性タイプの説明形式」

- 第9.3.2項「属性タイプの継承」

- 第9.3.3項「属性タイプの実装」

9.3.1 属性タイプの説明形式

属性タイプの説明形式は、RFC 4512 (http://www.ietf.org/rfc/rfc4512.txt)の第4.1.2項で説明されています。次に例を示します:

AttributeTypeDescription = LPAREN WSP
numericoid                    ; object identifier
[ SP "NAME" SP qdescrs ]      ; short names (descriptors)
[ SP "DESC" SP qdstring ]     ; description
[ SP "OBSOLETE" ]             ; not active
[ SP "SUP" SP oid ]           ; supertype
[ SP "EQUALITY" SP oid ]      ; equality matching rule
[ SP "ORDERING" SP oid ]      ; ordering matching rule
[ SP "SUBSTR" SP oid ]        ; substrings matching rule
[ SP "SYNTAX" SP noidlen ]    ; value syntax
[ SP "SINGLE-VALUE" ]         ; single-value
[ SP "COLLECTIVE" ]           ; collective
[ SP "NO-USER-MODIFICATION" ] ; not user modifiable
[ SP "USAGE" SP usage ]       ; usage
extensions WSP RPAREN         ; extensions

usage = "userApplications"     /  ; user
"directoryOperation"   /  ; directory operational
"distributedOperation" /  ; DSA-shared operational
"dSAOperation"            ; DSA-specific operational

属性タイプの説明は、次の要素を含みます:

numericoid

数値OIDは、Oracle Unified Directoryで属性タイプを一意に識別するのに使用されます。仕様では数値OIDが必要ですが、Oracle Unified Directoryはまた、利便性とOracle Directory Server Enterprise Editionとの互換性を高めることを目的として、非数値OIDを許可しています。この場合、非数値OIDは、文字列-oidが続く属性タイプの名前と同じである必要があります。

NAME

判読可能な名前のオプションのセットは、属性タイプを参照するのに使用されます。単一の名前がある場合は、それを一重引用符で囲む必要があります。複数の名前がある場合は、それぞれを空白で区切られた一重引用符で囲み、名前のセット全体をカッコで囲む必要があります。

DESC

オプションの判読可能な説明です。説明がある場合は、一重引用符でそれを囲みます。

OBSOLETE

オプションのOBSOLETEフラグは、属性タイプがアクティブかどうかを示すのに使用されます。属性タイプがOBSOLETEとしてマークされている場合、それは、Oracle Unified Directoryで作成された任意の新しい要素によって参照されるべきではないことを意味します。

SUP

上位の属性タイプへのオプション参照です。上位のタイプがある場合、そのOIDまたは任意の判読可能な名前によって参照することができます。

EQUALITY

オプションの等価一致ルールの定義です。特定の等価一致ルールが指定された場合は、そのOIDまたは任意の判読可能な名前によって参照することができます。等価一致ルールが指定されない場合は、属性タイプは、関連付けられた属性構文にデフォルトの等価一致ルールを使用します。属性構文がデフォルトの等価一致ルールを持たない場合は、等価一致操作はそのタイプの属性では許可されません。

ORDERING

オプションの順序付け一致ルールの定義です。特定の順序付け一致ルールが指定された場合は、そのOIDまたは任意の判読可能な名前によって参照することができます。順序付け一致ルールが指定されない場合は、属性タイプは、関連付けられた属性構文にデフォルトの順序付け一致ルールを使用します。属性構文がデフォルトの順序付け一致ルールを持たない場合は、順序付け一致操作はそのタイプの属性では許可されません。

SUBSTR

オプションの部分文字列一致ルールの定義です。特定の部分文字列一致ルールが指定された場合は、そのOIDまたは任意の判読可能な名前によって参照することができます。部分文字列一致ルールが指定されない場合は、属性タイプは、関連付けられた属性構文にデフォルトの部分文字列一致ルールを使用します。属性構文がデフォルトの部分文字列一致ルールを持たない場合は、部分文字列一致操作はそのタイプの属性では許可されません。

SYNTAX

属性タイプで使用するためのオプションの属性構文です。指定する場合は、数値のOIDにする必要があります。構文識別子はまた、オプションで、OIDの直後に中カッコで囲まれた整数値(OIDの最後の桁と左中カッコの間に空白なし)を含むことができます。これは、そのタイプの属性の値の長さの推奨上限値を示すために使用されます。Oracle Unified Directoryでは、属性値に対して最大長の制限が適用されないため、長さが指定された場合、それは無視されます。

SINGLE-VALUE

オプションのSINGLE-VALUEフラグは、そのタイプの属性が、それらが使用されているいずれのエントリでも、単一の値のみを持つことを許可されていることを示します。属性タイプの説明にこのフラグが存在しない場合は、そのタイプの属性は同じエントリで複数の異なる値を持つことを許可されています。

COLLECTIVE

オプションのCOLLECTIVEフラグは、そのタイプの属性に、コレクションにおけるメンバーシップに基づいて値が割り当てられることを示します。集合属性は、RFC 3671 (http://www.ietf.org/rfc/rfc3671.txt)「LDAPの集合属性」で説明されていて、Oracle Unified Directoryでサポートされている仮想属性のタイプの1つです。

NO-USER-MODIFICATION

オプションのNO-USER-MODIFICATIONフラグは、そのタイプの属性の値が外部クライアントによって変更されない(つまり、値はOracle Unified Directory内の内部処理によってのみ変更することができる)ことを示します。

USAGE

属性タイプが使用される方法を示すオプションの使用方法の仕様です。次の属性使用方法が許可されています:

- userApplications — ユーザー・データを格納するために使用されます。

- directoryOperation — Oracle Unified Directory内の内部処理に必要なデータを格納するために使用されます。

- distributedOperation — トポロジ内のサーバー間で同期させる必要がある操作データを格納するために使用されます。

- dSAOperation — 特定のディレクトリ·サーバーに固有のものであり、トポロジ間で同期されるべきではない操作データを格納するために使用されます。

拡張

属性タイプの拡張のオプションのセットです。Oracle Unified Directoryは現在、属性タイプに次の拡張を使用しています:

- X-ORIGIN — 属性タイプが定義されている場所の情報を提供します(たとえば、特定のRFCまたはインターネット・ドラフトで定義されているか、またはプロジェクト内で定義されているか)。

- X-SCHEMA-FILE — 属性タイプの定義が含まれるスキーマ・ファイルを示します。

- X-APPROX — その属性タイプでどの近似一致ルールを使用するかを示します。これが指定されている場合は、その値は登録されている一致ルールの名前またはOIDになります。

たとえば、次の例では、標準のuid属性タイプの説明を示します:

( 0.9.2342.19200300.100.1.1 NAME 'uid' EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256}
X-ORIGIN 'RFC 4519' )

この場合、OIDは0.9.2342.19200300.100.1.1です。uidの単一の判読可能な名前があります。等価一致ではcaseIgnoreMatchルールを、部分文字列一致ではcaseIgnoreSubstringsMatchルールを使用する必要があります。属性タイプは、256文字の推奨上限値でディレクトリ文字列構文を使用しており、属性タイプの定義は、RFC 4519 (http://www.ietf.org/rfc/rfc4519.txt)から取得されています。説明または上位タイプは指定されていません。属性タイプは、OBSOLETE、SINGLE-VALUE、COLLECTIVEまたはNO-USER-MODIFICATIONにマークされていません。指定された順序付け一致ルールはありません。つまり、Oracle Unified Directoryは、ディレクトリ文字列構文で使用されているデフォルトの順序付けルールを使用します。近似一致ルールを指定するためのX-APPROX拡張はないので、ディレクトリ文字列構文のデフォルトの近似ルールがここでも使用されます。

9.3.2 属性タイプの継承

属性タイプはその上位タイプとしての属性タイプを参照できます。これには、2つの主な効果があります:

- 下位の属性タイプが上位の属性タイプの定義をオーバーライドしない場合、上位の属性タイプの一致ルールと属性構文の仕様は、下位タイプで継承できます。たとえば、上位の属性タイプがIA5 String構文を使用する場合、その定義が代替構文を指定することによってそれをオーバーライドしないかぎり、下位の属性タイプもまたIA5 String構文を使用します。RFC 4512 (http://www.ietf.org/rfc/rfc4512.txt)の第2.5.1項によると、下位タイプの構文が上位の属性タイプの改良版である場合(つまり、上位の属性タイプの構文の値のサブセットを許可する)にのみ、属性タイプはその上位のタイプとは異なる構文を持つことができます。

- OID、上位の属性タイプに関連した任意の判読可能な名前、あるいは両方を、下位のタイプのすべてを一元的に参照するために使用することができます。たとえば、名前属性タイプは、cn、sn、c、l、st、o、ou、title、givenName、initials、generationQualifierおよびdmdName属性タイプの上位タイプとして参照されます。したがって、これらのタイプのいずれかを持つ任意の属性がtestの値を持つ場合、(name=test)のフィルタは、エントリに一致する必要があります。

下位の属性タイプは、その上位のタイプと異なる用法を持つことはできません。つまり、上位タイプがuserApplicationsの場合、下位タイプもまた、userApplicationsである必要があります。同様に、上位タイプがCOLLECTIVEを宣言している場合、サブタイプもCOLLECTIVEである必要がありますが、上位タイプがCOLLECTIVEでない場合は、下位タイプもCOLLECTIVEである必要はありません。

9.3.3 属性タイプの実装

現時点では、属性タイプを処理するために使用されるメカニズムは、次の点でLDAPv3の仕様とは異なります:

- LDAPv3仕様では、下位の属性タイプは上位タイプと同じ構文またはその構文の改良版を持つ必要があると規定されています。属性構文がスーパータイプの構文の改良版であるかどうかを判断する方法がないため、Oracle Unified Directoryは、この制約を実行しません。

- 同期サブシステムは、(たとえば、dSAOperationの使用方法を持つ属性タイプが同期されないように)属性使用方法を考慮に入れません。

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

オブジェクト・クラスは、エントリに格納できるデータ型を制御するために使用できる属性タイプの基本的な名前付きセットです。「オブジェクト・クラス」と「オブジェクトクラス」(単語の間の中黒の有無)は、一般的に区別しないで使用されることに注意してください。

次の項では、オブジェクト・クラスについて説明します:

- 第9.4.1項「オブジェクト・クラスの説明形式」

- 第9.4.2項「オブジェクト・クラスの種類」

- 第9.4.3項「オブジェクト・クラスの継承」

- 第9.4.4項「Directory Serverのオブジェクト・クラスの実装」

9.4.1 オブジェクト・クラスの説明形式

オブジェクト・クラスの説明形式は、RFC 4512 (http://www.ietf.org/rfc/rfc4512.txt)の第4.1.1項で説明されています。

ObjectClassDescription = LPAREN WSP
numericoid                 ; object identifier
[ SP "NAME" SP qdescrs ]   ; short names (descriptors)
[ SP "DESC" SP qdstring ]  ; description
[ SP "OBSOLETE" ]          ; not active
[ SP "SUP" SP oids ]       ; superior object classes
[ SP kind ]                ; kind of class
[ SP "MUST" SP oids ]      ; attribute types
[ SP "MAY" SP oids ]       ; attribute types
extensions WSP RPAREN
kind = "ABSTRACT" / "STRUCTURAL" / "AUXILIARY"

オブジェクト・クラスの説明は、次の要素を含みます:

numericoid

数値OIDは、Oracle Unified Directoryでオブジェクト・クラスを一意に識別するのに使用されます。仕様では数値OIDが必要ですが、Oracle Unified Directoryはまた、利便性とOracle Directory Server Enterprise Editionとの互換性を高めることを目的として、非数値OIDを許可します。この場合、非数値OIDは、文字列-oidが続くオブジェクト・クラスの名前と同じである必要があります。

NAME

オブジェクト・クラスを参照するのに使用される判読可能な名前のオプションのセットです。単一の名前がある場合は、それを一重引用符で囲む必要があります。複数の名前がある場合は、それぞれを空白で区切られた一重引用符で囲み、名前のセット全体をカッコで囲む必要があります。

DESC

オプションの判読可能な説明です。説明がある場合は、一重引用符でそれを囲みます。

OBSOLETE

オプションのOBSOLETEフラグは、オブジェクト・クラスがアクティブかどうかを示すのに使用されます。オブジェクト・クラスがOBSOLETEとしてマークされている場合、それは、Oracle Unified Directoryで作成されたいずれの新しい要素によっても参照されるべきではないことを意味します。

SUP

オブジェクト・クラスに対して1つ以上の上位クラスのオプションのセットです。技術的な仕様では、オブジェクト·クラスは、複数の上位クラスを持つことができますが、Oracle Unified Directoryは現在のところ、単一の上位クラスのみをサポートしていることに注意してください。この場合、SUPキーワードの後には、空白および上位クラスの名前またはOIDが続きます。複数の上位クラスがある場合は、それらをドル記号で区切り、上位クラスのセット全体をカッコで囲む必要があります。

kind

定義されているオブジェクト・クラスの種類を指定するオプションのキーワードです。これが指定されている場合は、ABSTRACT、STRUCTURALまたはAUXILIARYのいずれかである必要があります。値が指定されていない場合は、オブジェクト・クラスはSTRUCTURALと見なされます。

MUST

そのオブジェクト・クラスを持つエントリで存在することが要求されている(すなわち、少なくとも1つの値を持つ)属性の属性タイプのオプションのセットです。単一の必須の属性のみの場合、MUSTキーワードの後に属性タイプの名前またはOIDが続く必要があります。複数の必須属性タイプがある場合は、それらをドル記号で区切り、必須属性タイプのセット全体をカッコで囲む必要があります。

MAY

そのオブジェクト・クラスを持つエントリに存在することが許可されている(必須ではない)属性のオプションの属性タイプのオプションのセットです。単一のオプションの属性のみの場合、MAYキーワードの後に属性タイプの名前またはOIDが続く必要があります。複数のオプションの属性タイプがある場合は、それらをドル記号で区切り、オプションの属性タイプのセット全体をカッコで囲む必要があります。

拡張

オブジェクト・クラスの拡張のオプションのセットです。Oracle Unified Directoryは現在、オブジェクト・クラスに次の拡張を使用しています:

- X-ORIGIN — オブジェクト・クラスが定義されている場所の情報を提供します(たとえば、特定のRFCまたはインターネット・ドラフト由来かどうか、またはプロジェクト内で定義されているかどうか)。

- X-SCHEMA-FILE — オブジェクト・クラスの定義が含まれるスキーマ・ファイルを示します(この拡張は、一般に内部目的でのみ使用され、クライアントに公開されています)。

たとえば、次の例では、標準のpersonオブジェクト・クラスのオブジェクト・クラスの説明を示します:

( 2.5.6.6 NAME 'person' SUP top STRUCTURAL MUST ( sn $ cn )
MAY ( userPassword $ telephoneNumber $ seeAlso $ description )
X-ORIGIN 'RFC 4519' )

この場合、OIDは2.5.6.6です。personの単一の判読可能な名前があります。上位クラスはtopです。種類はSTRUCTURALです。personオブジェクト・クラスを含むすべてのエントリは、snおよびcn属性を含むことが必須で、userPassword、telephoneNumber、seeAlsoおよびdescription属性を含むことが可能です。オブジェクト・クラスの定義は、RFC 4519 (http://www.ietf.org/rfc/rfc4519.txt)から取得されています。説明はなく、オブジェクト・クラスはOBSOLETEと見なされません。

9.4.2 オブジェクト・クラスの種類

第9.4.1項「オブジェクト・クラスの説明形式」で説明されているように、すべてのオブジェクト・クラスは、ABSTRACT、STRUCTURALまたはAUXILIARYのいずれかの種類である必要があります:

- ABSTRACTオブジェクト・クラスは、他のオブジェクト・クラスによって拡張されることのみが意図されています。エントリに、その抽象クラスから導出される構造または補助クラスが含まれていないかぎり、エントリはいずれの抽象クラスも含むことができません(つまり、その継承連鎖で抽象クラスを持つ非抽象オブジェクト・クラスを含みます)。すべてのエントリは、構造化クラスの継承連鎖に少なくともtop抽象オブジェクト・クラスを含む必要があります。それらは、それらの構造化クラスまたはいずれかの補助クラスの継承連鎖に、別の抽象クラスを含む可能性もあるし、含まない可能性もあります。

- STRUCTURALオブジェクト・クラスは、エントリで表されるものの中核を定義することが意図されています。すべてのエントリには、ただ1つの構造化オブジェクト・クラス連鎖が含まれている必要があり、その連鎖のルートは、最終的にはtop抽象オブジェクト・クラスである必要があります。エントリの構造化オブジェクト・クラスを変更することはできません。

- AUXILIARYオブジェクト・クラスは、エントリの追加クオリティを定義することを意図しています。エントリには、ゼロ個以上の補助クラスを含めることができ、エントリに関連付けられた補助クラスのセットは時間の経過とともに変化します。

オブジェクト・クラスの種類によって表されるモデルは、Javaプログラミング言語で使用されるモデルに整然と変換されます。抽象LDAPオブジェクト·クラスはJavaの抽象クラスに直接マッピングし、補助LDAPオブジェクト·クラスは、Javaのインタフェースに直接マッピングし、構造化LDAPオブジェクト·クラスは、Javaの具象(非抽象)クラスに直接マッピングします。Javaクラスでは、ただ1つのスーパークラスを拡張する必要がありますが、任意の数のインタフェースを実装することができます。同様に、LDAPエントリでは、ただ1つの構造化クラス連鎖が含まれている必要がありますが、任意の数の補助クラス連鎖を含めることができます。また、Java抽象クラスを直接インスタンス化することは不可能であるように、抽象オブジェクト・クラスのみを含むLDAPエントリを作成することもできません。

Oracle Directory Server Enterprise Editionは、オブジェクト・クラスの種類に対してここで示されている制限の多くを適用しません。特に、任意の構造化オブジェクト·クラスのチェーンを含んでいないエントリの作成を許可し、また、複数の構造化オブジェクト・クラスのチェーンを含むエントリの作成も許可します。これは、Oracle Directory ServerのEnterprise Editionを使用したデプロイメントがこの制約に違反するエントリを含んでいる可能性があることを意味します。Oracle Unified Directoryでは、デフォルトではこの動作を許可していませんが、既存のOracle Directory Server Enterprise Editionのデプロイメントとの互換性のため、この制約に違反するエントリが許可されるようにOracle Unified Directoryを構成し、オプションでこの状況が検出されるたびにOracle Unified Directoryのエラー・ログにメッセージを書き込むようにすることができます。しかし、正確に1つの構造化オブジェクト·クラスが含まれていないエントリがある場合、この制約に依存するDITコンテンツ・ルールのようないくつかのスキーマ要素は、すべてのケースで期待どおりに動作するとはかぎりません。このようなスキーマ違反を受け入れるようにOracle Unified Directoryを構成するには、グローバル構成のsingle-structural-objectclass-behaviorプロパティを設定します。詳細については、Oracle Unified Directory構成リファレンスのグローバル構成に関する項を参照してください。

9.4.3 オブジェクト・クラスの継承

第9.4.1項「オブジェクト・クラスの説明形式」で説明されているように、オブジェクト・クラスは、ゼロ個以上の上位クラス(現時点では、Oracle Unified Directoryは最大で1つの上位クラスをサポートしています)を持つことができます。オブジェクト・クラスが上位クラスを参照する場合、その上位クラスに関連付けられた必須およびオプションの属性のすべては、下位クラスにも関連付けられます。

オブジェクト・クラスの継承には次の制約があります:

- ABSTRACTオブジェクト・クラスは、別の属性クラスからのみ継承することができます。それらは、構造化または補助クラスの下位であることはできません。

- STRUCTURALオブジェクト・クラスは、抽象クラスまたは別の構造化クラスからのみ継承することができます。それらは、補助オブジェクト・クラスの下位であることはできません。

- AUXILIARYオブジェクト・クラスは、抽象または別の補助クラスからのみ継承することができます。それらは、構造化オブジェクト・クラスの下位であることはできません。

- すべてのSTRUCTURALオブジェクト・クラスは、最終的にトップの抽象オブジェクト・クラスから継承する必要があります。これによる実際の影響は、Oracle Unified Directoryのすべてのエントリがtopオブジェクト・クラスを含む必要があり、また、topオブジェクト・クラスに要求されるobjectClass属性タイプを含む必要があるということです。

9.4.4 ディレクトリ・サーバーのオブジェクト・クラスの実装

オブジェクト・クラスを処理するために使用されるメカニズムは、オブジェクト・クラスで最大1つの上位クラスを持つことが許可されている点で、LDAPv3仕様と異なります。LDAPv3仕様では、場合によっては複数の上位クラスが許可されます。

9.5 名前書式の理解

名前書式は、Oracle Unified Directoryでエントリに名前をつけるためのメカニズムを定義するために使用することができます。特に、名前書式は、特定の構造化オブジェクト・クラスを持つエントリのRDNに存在している必要のある1つ以上の属性タイプを指定します。名前書式では、RDNにオプションで存在可能なゼロ個以上の属性タイプを指定することもできます。

Oracle Unified Directoryのスキーマで定義された各構造化オブジェクト·クラスは、1つ以上の名前書式に関連付けることができます。名前書式が、特定の構造化オブジェクト・クラスに定義されている場合、関連付けられている名前書式は、そのオブジェクト・クラスを含むエントリに対するDNの追加または変更操作で適用されます。構造化オブジェクト·クラスが、名前書式に関連付けられていない場合は、ターゲット・エントリに存在することが許可されている任意の属性タイプはネーミング属性タイプとして使用することができます。

9.5.1 名前書式の説明形式

名前書式の説明形式は、RFC 4512 (http://www.ietf.org/rfc/rfc4512.txt)の第4.1.7.2項で説明されています。次に例を示します:

NameFormDescription = LPAREN WSP
numericoid                 ; object identifier
[ SP "NAME" SP qdescrs ]   ; short names (descriptors)
[ SP "DESC" SP qdstring ]  ; description
[ SP "OBSOLETE" ]          ; not active
SP "OC" SP oids             ; structural object classes
SP "MUST" SP oids          ; attribute types
[ SP "MAY" SP oids ]       ; attribute types
extensions WSP RPAREN      ; extensions

名前書式の説明は、次の要素を含みます:

numericoid

数値OIDは、Oracle Unified Directoryで名前書式を一意に識別するのに使用されます。仕様では数値OIDが必要ですが、Oracle Unified Directoryはまた、利便性を高めること目的として、非数値OIDを許可します。この場合、非数値OIDは、文字列-oidが続く名前書式の名前と同じである必要があります。

NAME

名前書式を参照するのに使用される判読可能な名前のオプションのセットです。単一の名前がある場合は、それを一重引用符で囲む必要があります。複数の名前がある場合は、それぞれを空白で区切られた一重引用符で囲み、名前のセット全体をカッコで囲む必要があります。

DESC

オプションの判読可能な説明です。説明がある場合は、一重引用符でそれを囲みます。

OBSOLETE

オプションのOBSOLETEフラグは、名前書式がアクティブかどうかを示すのに使用されます。名前書式がOBSOLETEとしてマークされている場合、Oracle Unified Directory内で有効にしてはならず、またそれに依存する他の要素を作成することが可能であってはいけません。

OC

名前書式が関連付けられている構造化オブジェクト・クラスの名前またはOIDです。

MUST

指定された構造化クラスを持つエントリのRDNに存在する必要がある1つ以上の属性タイプの名前またはOIDです。単一の必須属性タイプのみの場合は、その名前またはOIDのみを指定する必要があります。複数の必須属性タイプがある場合は、それらを空白とドル記号で区切り、必須属性タイプのセット全体をカッコで囲む必要があります。

MAY

指定された構造化クラスを持つエントリのRDNにオプションで存在可能なゼロ個以上の属性タイプの名前またはOIDです。単一のオプションの属性タイプのみがある場合は、その名前またはOIDのみを指定する必要があります。複数のオプションの属性タイプがある場合は、それらを空白およびドル記号で区切り、オプションの属性タイプのセット全体をカッコで囲む必要があります。

拡張

名前書式の拡張のオプションのセットです。Oracle Unified Directoryは現在、名前書式に次の拡張を使用しています:

- X-ORIGIN — 名前書式が定義されている場所の情報を提供します(たとえば、特定のRFCまたはインターネット・ドラフト由来かどうか、またはプロジェクト内で定義されているかどうか)。

- X-SCHEMA-FILE — 名前書式の定義が含まれるスキーマ・ファイルを示します(この拡張は、一般に内部目的でのみ使用され、クライアントに公開されています)。

たとえば、次に、RFC 4403 (http://www.ietf.org/rfc/rfc4403.txt)で定義されているuddiBusinessEntityNameForm名前書式の名前書式の説明を示します:

( 1.3.6.1.1.10.15.1 NAME 'uddiBusinessEntityNameForm'
OC uddiBusinessEntity MUST ( uddiBusinessKey ) X-ORIGIN 'RFC 4403' )

この場合、数値OIDは1.3.6.1.1.10.15.1で、判読可能な名前はuddiBusinessEntityNameFormです。uddiBusinessEntity構造化オブジェクト・クラスを持つエントリは、唯一のRDN属性タイプとしてuddiBusinessKeyを使用することが必要です。説明はなく、関連付けられたエントリにオプションで含まれるその他の属性タイプもありません。名前書式はOBSOLETEにマークされません。

9.6 DITコンテンツ・ルールの理解

DITコンテンツ・ルールは、エントリに表示できるコンテンツを定義するメカニズムを提供します。その構造化オブジェクト・クラスに基づいて、最大で1つのDITコンテンツ・ルールをエントリに関連付けることができます。エントリにそのようなルールが存在する場合、エントリに存在する必要がある(存在する可能性がある、または存在していはいけない)属性タイプと同様に、含む可能性のある補助クラスを定義するために、そのエントリに含まれるオブジェクト・クラスとともに動作します。

次の項では、DITコンテンツ・ルールを説明します:

- 第9.6.1項「DITコンテンツ・ルールの説明形式」

- 第9.6.2項「DITコンテンツ・ルールの実装」

9.6.1 DITコンテンツ・ルールの説明形式

DITコンテンツ・ルールの説明形式は、RFC 4512 (http://www.ietf.org/rfc/rfc4512.txt)の第4.1.6項で説明されています。次に例を示します:

DITContentRuleDescription = LPAREN WSP
numericoid                 ; object identifier
[ SP "NAME" SP qdescrs ]   ; short names (descriptors)
[ SP "DESC" SP qdstring ]  ; description
[ SP "OBSOLETE" ]          ; not active
[ SP "AUX" SP oids ]       ; auxiliary object classes
[ SP "MUST" SP oids ]      ; attribute types
[ SP "MAY" SP oids ]       ; attribute types
[ SP "NOT" SP oids ]       ; attribute types
extensions WSP RPAREN      ; extensions

DITコンテンツ・ルールの説明は、次の要素を含みます:

numericoid

DITコンテンツ・ルールに関連付けられている構造化オブジェクト・クラスの数値OIDです。仕様では、数値OIDを必要としますが、このnumericoidは関連付けられているオブジェクト・クラスに指定されているOIDと一致する必要があるので、オブジェクト・クラスのOIDが非数値の場合は、OIDも同様である必要があります。

NAME

DITコンテンツ・ルールを参照するために使用される判読可能な名前のオプションのセットです。単一の名前がある場合は、それを一重引用符で囲む必要があります。複数の名前がある場合は、それぞれを空白で区切られた一重引用符で囲み、名前のセット全体をカッコで囲む必要があります。

DESC

オプションの判読可能な説明です。説明を指定する場合は、一重引用符で囲んでください。

OBSOLETE

オプションのOBSOLETEフラグは、DITコンテンツ・ルールがアクティブかどうかを示すのに使用されます。DITコンテンツ・ルールがOBSOLETEとしてマークされている場合は、Oracle Unified Directory内で有効してはいけません。

AUX

関連付けられた構造化クラスを持つエントリに存在することができる補助オブジェクト・クラスのオプションのリストです。値が指定されていない場合、そのようなエントリは、いずれの補助オブジェクト・クラスも持つことを許可されていません。値は、1つ以上の許可されている補助クラスの名前またはOIDとして指定される必要があります。複数の補助クラスが許可されている場合は、それらを空白およびドル記号で区切り、名前のセット全体をカッコで囲みます。

MUST

関連付けられた構造化クラスを持つエントリに存在することが必要な属性タイプのオプションのリストです。これは、オブジェクト・クラスによって要求される属性タイプに加えてエントリに追加されます、これらの追加属性タイプは、それらのオブジェクト・クラスによって許可される必要はありません。値は、必須属性タイプの1つ以上の名前またはOIDとして指定される必要があります。複数の補助クラスが要求されている場合は、それらを空白およびドル記号で区切り、必須属性タイプのセット全体をカッコで囲みます。

MAY

関連付けられた構造化クラスを持つエントリにオプションで存在することができる属性タイプのオプションのリストです。これは、オブジェクト・クラスによって許可された属性タイプに加えてエントリに追加されます。値は、オプションの属性タイプの1つ以上の名前またはOIDとして指定される必要があります。複数のオプションの補助クラスがある場合は、それらを空白およびドル記号で区切り、オプションの属性タイプのセット全体をカッコで囲みます。

NOT

関連付けられた構造化クラスを持つエントリに存在することが禁止されている属性タイプのオプションのリストです。このリストは、構造化クラスまたは許可されている補助クラスで要求されているいずれの属性タイプも含むことはできませんが、それらのいずれかのオブジェクト・クラスによって許可される属性タイプの混入を防ぐために使用することができます。値は、禁止属性タイプの1つ以上の名前またはOIDとして指定される必要があります。複数のタイプが禁止されている場合は、それらを空白およびドル記号で区切り、禁止属性タイプのセット全体をカッコで囲みます。

拡張

DITコンテンツ・ルールの拡張のオプションのセットです。Oracle Unified Directoryは現在、DITコンテンツ・ルールに次の拡張を使用しています:

- X-ORIGIN — DITコンテンツ・ルールが定義されている場所の情報を提供します(たとえば、特定のRFCまたはインターネット・ドラフト由来かどうか、またはプロジェクト内で定義されているかどうか)。

- X-SCHEMA-FILE — DITコンテンツ・ルールの定義が含まれるスキーマ・ファイルを示します(この拡張は、一般に内部目的でのみ使用され、クライアントに公開されています)。

次の例では、DITコンテンツ・ルールの説明を示しています:

( 2.16.840.1.113730.3.2.2 NAME 'inetOrgPersonContentRule'
AUX ( posixAccount $ shadowAccount $ authPasswordObject )
MUST uid )

この場合、数値OIDは2.16.840.1.113730.3.2.2で、inetOrgPerson構造化オブジェクト・クラスのOIDです。inetOrgPersonContentRuleの判読可能な名前を持ち、説明はありません。inetOrgPersonオブジェクト・クラスを含むエントリは、posixAccount、shadowAccountおよびauthPasswordObject補助クラスを含むことができ、それらのエントリはuid属性タイプを含む必要があります。この例では、OBSOLETEにマークされず、追加のオプションの属性タイプまたは禁止属性タイプは定義されず、拡張も含まれません。

9.6.2 DITコンテンツ・ルールの実装

現時点では、DITコンテンツ・ルールを処理するために使用されるメカニズムは、LDAPv3の仕様とは異なります。LDAPv3の仕様では、エントリで使用されている構造化オブジェクト・クラスが、対応するDITコンテンツ・ルールを持たない場合、そのエントリはいずれの補助オブジェクト・クラスも含むことはできないと規定されています。Oracle Directory Server Enterprise EditionはDITコンテンツ・ルールをサポートしないため、Oracle Unified Directoryは対応するDITコンテンツ・ルールがないエントリで補助オブジェクト・クラスの使用を妨げません。特定のエントリのタイプに補助クラスが含まれないようにすることが望ましい場合、DITコンテンツ・ルールは、補助クラスを許可しないDITコンテンツ・ルールを作成して、適切な構造化オブジェクト·クラスを持つエントリを処理する必要があります。

9.7 DIT構造ルールの理解

DIT構造ルールは、ディレクトリ・データの許可された階層構造を定義するために使用されます。特に、それらは指定された構造化オブジェクト・クラスを持つエントリの直接の子として存在することができるエントリのタイプを指定することを可能にします。たとえば、inetOrgPerson構造化クラスを持つエントリのみがorganizationalUnit構造化オブジェクト・クラスを持つエントリの直接の子になることができます。

DIT構造ルールは、それら自身で階層になっています。各DIT構造ルールは、整数値であるルールIDが割り当てられ、また、名前書式(1つ以上の構造化オブジェクト・クラスにリンクします)に関連付けられています。DIT構造ルールは、1つ以上上位のDIT構造ルールを参照することができ、これは、データの階層を制御するためのメカニズムを提供します。DIT構造ルールがいずれの上位ルールも指定しない場合は、その関連付けられた構造化オブジェクト・クラスを含むエントリは、関連付けられたスキーマのルートに存在することが許可されています。DIT構造が1つ以上の上位ルールを指定する場合は、関連付けられた構造化オブジェクト・クラスを持つエントリは、それらの上位ルールのいずれかの構造化オブジェクト・クラスを含むエントリの下にのみに存在することが許可されています。

次の項では、DIT構造ルールを説明します:

- 第9.7.1項「DIT構造ルールの説明形式」

- 第9.7.2項「DIT構造ルールと複数のスキーマ」

9.7.1 DIT構造ルールの説明形式

DIT構造ルールの説明形式は、RFC 4512 (http://www.ietf.org/rfc/rfc4512.txt)の第4.1.7.1項で説明されています。次に例を示します:

DITStructureRuleDescription = LPAREN WSP
ruleid                     ; rule identifier
[ SP "NAME" SP qdescrs ]   ; short names (descriptors)
[ SP "DESC" SP qdstring ]  ; description
[ SP "OBSOLETE" ]          ; not active
SP "FORM" SP oid           ; NameForm
[ SP "SUP" ruleids ]       ; superior rules
extensions WSP RPAREN      ; extensions
ruleids = ruleid / ( LPAREN WSP ruleidlist WSP RPAREN )
ruleidlist = ruleid *( SP ruleid )
ruleid = number

DIT構造ルールの説明は、次の要素を含みます:

ruleid

DIT構造ルールに割り当てられた整数のルールIDです。これは、スキーマ内のすべての他のDIT構造ルールの中で一意である必要があります。

NAME

DIT構造ルールを参照するのに使用される判読可能な名前のオプションのセットです。単一の名前がある場合は、それを一重引用符で囲む必要があります。複数の名前がある場合は、それぞれを空白で区切られた一重引用符で囲み、名前のセット全体をカッコで囲む必要があります。

DESC

オプションの判読可能な説明です。説明を指定する場合は、一重引用符で囲んでください。

OBSOLETE

オプションのOBSOLETEフラグは、DIT構造ルールがアクティブかどうかを示すのに使用されます。OBSOLETEにマークされている場合、エントリの作成時または移動時に、このルールは考慮されません。

FORM

DIT構造ルールが関連付けられている名前書式の名前またはOIDです。第9.7項「DIT構造ルールの理解」で述べられているように、名前書式はDIT構造ルールと構造化オブジェクト・クラスを関連付けます。

SUP

DIT構造ルールの上位のルールIDのオプションのセットです。複数の上位のルールIDがある場合は、空白でそれらを区切り、上位のルールIDのセット全体をカッコで囲みます。複数のDIT構造ルールは、上位のルールIDの重複セットを使用することが許容されます。

拡張

DIT構造ルールの拡張のオプションのセットです。Oracle Unified Directoryは現在、DIT構造ルールに次の拡張を使用しています:

- X-ORIGIN — DIT構造ルールが定義されている場所の情報を提供します(たとえば、特定のRFCまたはインターネット・ドラフト由来かどうか、またはプロジェクト内で定義されているかどうか)。

- X-SCHEMA-FILE — DIT構造ルールの定義が含まれるスキーマ・ファイルを示します(この拡張は、一般に内部目的でのみ使用され、クライアントに公開されています)。

次の例は、uddiContactStructureRule DIT構造ルールのDIT構造ルールの定義を示します:

dITStructureRule:
( 2 NAME 'uddiContactStructureRule' FORM uddiContactNameForm SUP ( 1 )
X-ORIGIN 'RFC 4403' )

この場合、ルールIDは2で、判読可能な名前はuddiContactStructureRuleです。uddiContactNameForm名前書式に関連付けられ(uddiContactオブジェクト・クラスにリンクします)、1の上位のルールIDを持ちます。RFC 4403 (http://www.ietf.org/rfc/rfc4403.txt)で定義されました。説明はありませんし、OBSOLETEにマークされてもいません。

9.7.2 DIT構造ルールと複数のスキーマ

DIT構造ルールは、Oracle Unified Directory階層に制約を配置するためのメカニズムを提供することができますが、それらの効用を最大化するためには、複数のスキーマのサポートとともにそれらを使用する必要があります。たとえば、2つの分岐(ou=People,dc=example,dc=comおよびou=Groups,dc=example,dc=com)が下にあるdc=example,dc=comのネーミング・コンテキストを持つディレクトリについて考えてみます。ou=People分岐の下のinetOrgPersonエントリのみ、およびou=Groups分岐の下のgroupOfNamesエントリのみを許可したい場合は、ou=People分岐およびou=Groups分岐を管理する異なるスキーマがある場合にかぎり、完全にそれを達成することができます。

ディレクトリ・サーバー全体を管理する単一のスキーマがあった場合は、4つのDIT構造ルールがあるだろうことが想像できます:

- dITStructureRule: (11 NAME 'domainStructureRule' FORM domainNameForm)

- dITStructureRule: (12 NAME 'organizationalUnitStructureRule' FORM organizationalUnitNameForm SUP 11)

- dITStructureRule: (13 NAME 'inetOrgPersonStructureRule' FORM inetOrgPersonNameForm SUP 12)

- dITStructureRule: (14 NAME 'groupOfNamesStructureRule' FORM groupOfNamesNameForm SUP 12)

DIT構造ルールのこのセットは、前述の構造を許可しますが、ou=People分岐の下のグループ・エントリの作成、およびou=Groups分岐の下のユーザー・エントリの作成も許可します。DIT構造ルールを使用してそれを防ぐ唯一の方法は、ou=People分岐およびou=Groups分岐に別々のスキーマを定義し、ou=People分岐のスキーマにはinetOrgPersonStructureRuleルールのみを定義し、ou=Groups分岐のスキーマにはgroupOfNamesStructureRuleのみを定義します。

9.8 一致ルールの使用の理解

一致ルールの使用は、拡張一致フィルタ・コンポーネントで検索リクエストを処理する際に、特定の一致ルールとともに使用できる属性タイプを指定するために使用することができます。その拡張一致コンポーネントが、属性タイプおよび一致ルールIDの両方を含む場合は、Oracle Unified Directoryは関連付けられている一致ルールに対する一致ルールの使用があるかを確認し、ある場合は、指定された属性タイプがその一致ルールで使用することができることを確認します。

一致ルールの使用の説明形式は、RFC 4512 (http://www.ietf.org/rfc/rfc4512.txt)の第4.1.4項で説明されています。次に例を示します:

MatchingRuleUseDescription = LPAREN WSP
numericoid                 ; object identifier
[ SP "NAME" SP qdescrs ]   ; short names (descriptors)
[ SP "DESC" SP qdstring ]  ; description
[ SP "OBSOLETE" ]          ; not active
SP "APPLIES" SP oids       ; attribute types
extensions WSP RPAREN      ; extensions

一致ルールの使用の説明は、次の要素を含みます:

numericoid

一致ルールの使用が関連付けられている一致ルールの数値OIDです。特定の一致ルールに関連付けられた一致ルールの使用は1つのみです。

NAME

一致ルールの使用を参照するのに使用できる判読可能な名前のオプションのセットです。単一の名前がある場合は、それを一重引用符で囲む必要があります。複数の名前がある場合は、それぞれを一重引用符で囲み、空白で区切り、名前のセット全体をカッコで囲む必要があります。

DESC

オプションの判読可能な説明です。説明がある場合は、それを一重引用符で囲む必要があります。

OBSOLETE

オプションのOBSOLETEフラグは、一致ルールの使用がアクティブかどうかを示すのに使用されます。OBSOLETEにマークされている場合、拡張一致フィルタを許可するかどうかを判断する際に、このルールは考慮されません。

APPLIES

関連付けられた一致ルールとともに使用される1つ以上の属性タイプのセットです。関連付けられた属性タイプがある場合は、その名前またはOIDが使用されます。複数の属性タイプがある場合は、それらを空白およびドル記号で区切り、関連付けられた属性タイプのセット全体をカッコで囲みます。

拡張

一致ルールの使用の拡張のオプションのセットです。Oracle Unified Directoryは現在、一致ルールの使用に次の拡張を使用しています:

- X-ORIGIN — 一致ルールが定義されている場所の情報を提供します(たとえば、特定のRFCまたはインターネット・ドラフト由来かどうか、またはプロジェクト内で定義されているかどうか)。

- X-SCHEMA-FILE — 一致ルールの定義が含まれるスキーマ・ファイルを示します(この拡張は、一般に内部目的でのみ使用され、クライアントに公開されています)。

次の例は、一致ルールの使用の説明を示しています:

( 1.3.6.1.4.1.26027.1.999.10 NAME 'testAddMRUSuccessful' APPLIES cn )

この場合、数値OIDは1.3.6.1.4.1.26027.1.999.10、単一の判読可能な名前はtestAddMRUSuccessfulであり、cn属性とともに使用できます。説明はなく、OBSOLETEにマークされておらず、そしていずれの拡張もありません。

10 rootユーザーと特権サブシステムの理解

ほとんどのLDAPディレクトリ・サーバーでは、一般的に単一のスーパーユーザーを持っています。これは、従来のUNIXシステムのrootアカウントに似ています。このアカウントでは、通常のユーザーには適用されるアクセス制御や他の制限をバイパスすることができます。Oracle Unified Directoryでは、複数のrootユーザーおよびよりきめ細かいレベルで機能の制御を可能にする特権サブシステムを定義できます。

次の項では、rootユーザー・アカウントおよび特権サブシステムを説明します:

- 第10.1項「rootユーザー・アカウント」

- 第10.2項「特権サブシステム」

- 第10.3項「通常ユーザーへの権限の割当て」

- 第10.4項「rootユーザーへの権限の割当て」

10.1 Rootユーザー・アカウント

rootユーザー・アカウントは、サーバー構成のcn=Root DNs,cn=config分岐の下に定義されます。各rootアカウントは、ds-cfg-root-dn-user補助オブジェクト・クラスが含まれることを除いて、通常のユーザー・エントリとして定義されます。rootユーザー・エントリは、ds-cfg-alternate-bind-dn属性に1つ以上の値を持つことができます。この属性では、代替DN(これを使用して、そのユーザーとして認証することが可能です)を指定します(たとえば、実際のエントリDNであるcn=Directory Manager,cn=Root DNs,cn=configを使用するかわりに、cn=Directory Managerとしてバインドできます)。

複数のrootユーザーを定義する機能(それぞれ、自身のエントリ内に)は、いくつかの利点があります:

- ディレクトリ・サーバーへのルート・アクセスが必要な各管理者は、自身の資格証明が設定されている各自のアカウントを持つことができます。これは、すべての管理者が単一のrootアカウントを共有する場合よりも、ディレクトリ・サーバー内でだれが何をするかの監査証跡を保持することを容易にします。

- 各rootユーザー・アカウントは、自身の資格証明のセットを持っているため、1人のrootユーザーの資格証明は、他のrootユーザーへ影響を与えることなく変更することができます。各管理者は自身のアカウントを持っているため、すべての管理者の間でrootパスワードの変更を調整する必要はありません。管理者が異動または退職した場合、そのアカウントを非アクティブ化または削除するだけで済みます。

- 各rootユーザーは自身のエントリを持っていて、そのエントリ(ds-cfg-root-dn-user補助オブジェクト・クラスを持っているかぎり)に好きな属性およびオブジェクト・クラスを配置することができるため、rootユーザーは、EXTERNALやGSSAPI SASLメカニズムのような強力な認証を使用することができます。

- rootユーザーは、パスワード・ポリシー適用の対象となります。これは、rootユーザーに定期的に自分のパスワードを変更させ、セキュアなメカニズムを使用してのみ認証やパスワードの変更を行えるようにし、強力なパスワードが選択されるようにすることを意味します。ディレクトリの他のユーザーとは異なるパスワード・ポリシー要件のセットの対象となるように、rootユーザーにカスタム・パスワード・ポリシーを使用することもできます。

- 通常のユーザーよりもrootユーザーのために異なるリソース制限を定義することができます。各rootアカウントは自身のエントリを持つため、ds-rlim-size-limit、ds-rlim-time-limitおよびds-rlim-lookthrough-limitなどの操作属性は、通常のユーザー・アカウントと同じようにrootユーザーに作用します。

10.2 特権サブシステム

前述したように、従来のディレクトリ内のrootユーザー・アカウントは、アクセス制御および他の制限をバイパスできるため特別であり、rootユーザーのみが実行できるいくつかの操作があります。これは、従来のUNIXオペレーティング・システムにおけるrootユーザーの概念に似ています。ただし、rootユーザーのみができることを通常のユーザーが実行する必要がある場合があります。rootアクセスを与えられているユーザーには、実際にジョブを実行するのに必要なパワーよりもはるかに大きなパワーが与えられます。システム管理者には、ユーザーがこのパワーを責任を持って使用し、故意であってもなくてもシステムの他の部分に影響を与えないようにすることが求められます。それに対して、ユーザーにrootアクセスが与えられないと、重要な機能を実行できないか、タスクを実行するためにシステム管理者に頼る必要がある場合もあります。

Solaris 10以降では、特権サブシステム(「プロセス権限管理」とも呼ばれます)を作成することで、UNIXシステムのこの問題に取り組んでいます。Solarisの開発エンジニアは、一つの特定のタスクを実行するだけのために誰かにrootアクセス権を与えざるを得ないことは、危険で望ましくないと気が付きました。たとえば、1024未満のポートでリスニングするプロセスを開始する必要があるといって、ユーザーはファイルシステム権限をバイパスできたり、ネットワーク・インタフェースの設定を変更できたり、また、ファイル・システムをマウントおよびアンマウントできる必要があるというわけではありません。Solaris 10の特権サブシステムを使用すると、ユーザーに必要な特定の機能のみを与えることが可能です(たとえば、完全なrootアクセス権を与えることなく権限ポートにバインドできるようにすることなど)。同様に、利用可能な権限を無効にすることも可能です。たとえば、特定のデーモンを実行するためにのみ使用されるアカウントは、システムの他のユーザーが所有するプロセスを参照することができるようにする必要はありません。

注意:

管理者は、最高のセキュリティ・レベルを達成するために、Oracle Privileged Account Managementシステムを検討する必要があります。

Oracle Unified Directoryは、ユーザーが必要とする可能性のある個別の機能を定義し、ユーザーが必要とするアクセスのレベルだけを与えることができる特権サブシステムも持っています。通常のユーザーは持たない権限を通常のユーザーに付与したり、rootユーザーの特定の権限を無効にしたりすることができます。ディレクトリ・サーバーに現在定義されている権限のセットは次のとおりです:

bypass-acl

アクセス制御の評価のバイパスをユーザーに許可

modify-acl

ユーザーが、サーバーで定義されたアクセス制御に変更を加えることを許可します。

config-read

サーバー構成の読取りアクセス権の保有をユーザーに許可

config-write

サーバー構成の書込みアクセス権の保有をユーザーに許可

jmx-read

ユーザーがJMX属性値を読み取ることを許可します。

jmx-write

ユーザーがJMX属性値を更新することを許可します。

jmx-notify

*ユーザーがJMX通知にサブスクライブすることを許可します。

ldif-import

ユーザーがLDIFインポート・タスクを要求することを許可します。

ldif-export

ユーザーがLDIFエクスポート・タスクを要求することを許可します。

backend-backup

ユーザーがバックエンドのバックアップ・タスクを要求することを許可します。

backend-restore

ユーザーがバックエンドのリストア・タスクを要求することを許可します。

server-shutdown

ユーザーがサーバーのシャットダウン・タスクを要求することを許可します。

server-restart

ユーザーがサーバーの再起動タスクを要求することを許可します。

proxied-auth

ユーザーが、プロキシ設定された認可制御を使用すること、または代替SASL認可IDを要求することを許可します。

disconnect-client

ユーザーが任意のクライアント接続を終了することを許可します。

cancel-request

*ユーザーが任意のクライアント・リクエストを取り消すことを許可します。

unindexed-search

ユーザーがインデックスを使用しない検索操作を要求することを許可します。

password-reset

ユーザーが他のユーザーのパスワードをリセットすることを許可します。

update-schema

ユーザーがサーバー・スキーマを更新することを許可します。

privilege-change

ユーザーが、ユーザーに割り当てられた権限のセットを変更するか、デフォルトのroot権限のセットを変更することを許可します。

現時点では、アスタリスク(*)でマークされた権限は、まだサーバーに実装されていないので、有効ではありません。

特権サブシステムは、アクセス制御サブシステムにはほとんど依存しません。ユーザーがbypass-acl権限も持たないかぎり、操作はアクセス制御のチェックの影響下にある可能性があります。たとえば、ユーザーがconfig-read権限を持つ場合、そのユーザーは、アクセス制御で許可されている構成の部分のみを参照することができます。原則として、ある操作が特権サブシステムとアクセス制御の両方の対象となっているときはいつでも、両方のメカニズムでその操作を許可する必要があります。

10.3 通常ユーザーへの権限の割当て

デフォルトでは、前述の権限のいずれも通常のユーザーには付与されません。したがって、ユーザーが、関連付けられた任意の操作を実行できるようにする場合は、適切な権限が付与されている必要があります。これは、ユーザーのエントリにds-privilege-name操作属性を追加することで行うことができます。

注意:

modify-aclなどの値を持つ特権の追加は、ユーザーにACIの追加、置換または削除の権限を付与するには十分ではありません。ユーザーが別のエントリのACIを変更するための適切なアクセス制御も必要です。詳細は、付録の第8節の「ACI構文」を参照してください。

ds-privilege-nameは複数値の属性であり、ユーザーが複数の権限を与えられる場合、単独の値がそれぞれに使用される必要があります。仮想属性サブシステムが所定の場所にあるとき、それらのユーザー・エントリでds-privilege-nameを仮想属性にすることで、自動的にユーザーのグループに権限を付与することが可能です。

ユーザーcn=Proxy User,dc=example,dc=comにproxied-auth権限を追加するのに使用される変更の例を次に示します:

dn: cn=Proxy User,dc=example,dc=com
changetype: modify
add: ds-privilege-name
ds-privilege-name: proxied-auth

10.4 Rootユーザーへの権限の割当て

権限サブシステムを導入した場合、サーバー内の他のアカウントとrootユーザーを区別する主な特徴は、rootユーザーがユーザー・データ内ではなく構成内に存在すること、およびrootユーザーであるため権限の特定のセットを自動的に継承することです。rootユーザーに自動的に付与される権限のセットは、cn=Root DNs,cn=configエントリのds-cfg-default-root-privilege-name属性で定義されます。デフォルトでは、rootユーザーには次の権限が自動的に付与されます:

- bypass-acl

- modify-acl

- config-read

- config-write

- ldif-import

- ldif-export

- backend-backup

- backend-restore

- server-shutdown

- server-restart

- disconnect-client

- cancel-request

- unindexed-search

- password-reset

- update-schema

- privilege-change

rootユーザーに自動的に割り当てられる権限のセットを変更したい場合は、ds-cfg-default-root-privilege-name属性を編集することで行うことができます。さらに、特定のrootユーザーに異なる権限のセットを付与する場合は、通常のユーザーと同様に、rootユーザーのエントリ内のds-privilege-name属性を使用することでそれを行うことができます。たとえば、次の変更を使用して、特定のrootユーザー(この場合は、cn=Test Root User,cn=Root DNs,cn=config)がプロキシ認可を使用できるようにする一方で、ユーザー権限を変更したり構成にアクセスしたりすることはできないようにします。(権限の前のマイナス記号は、付与ではなく、削除されることを示します。)

dn: cn=Test Root User,cn=Root DNs,cn=config
changetype: modify
add: ds-privilege-name
ds-privilege-name: proxied-auth
ds-privilege-name: -config-read
ds-privilege-name: -config-write

この場合、cn=Test Root User,cn=Root DNs,cn=configユーザーは、rootユーザーに自動的に付与されるすべての権限(ただしconfig-readおよびconfig-write権限は除きます)を継承します。さらに、proxied-auth権限も付与されます。

11 プロキシ機能の理解

この章では、プロキシ・サーバー・インスタンス固有の機能について説明します。内容は次のとおりです:

- 第11.1項「プロキシを使用したロード・バランシング」

- 第11.2項「プロキシを使用したデータ分散」

- 第11.3項「グローバル索引カタログ」

- 第11.4項「プロキシを使用したDNリネーム」

- 第11.5項「RDNの変更」

- 第11.6項「変換フレームワークの理解」

注意:

この章をお読みになる前に、第1章「Oracle Unified Directoryの概要」に目を通して、ここで説明する概念について理解しておくようにしてください。

11.1 プロキシを使用したロード・バランシング

プロキシを使用して、複数のデータ・ソースまたはレプリケートされたLDAPサーバー間でリクエストをロード・バランシングすることができます。

ロード・バランシング・デプロイメントでは、リクエストは、設定されているロード・バランシング・アルゴリズムに基づいて、データ・ソースの1つにルーティングされます。

次のいずれかのロード・バランシング・アルゴリズムを選択できます:

- フェイルオーバー。複数のリモートLDAPサーバーが、特定の操作タイプに対して、サーバー上で構成されている優先度に基づいてリクエストを処理します。エラーが発生すると、その操作タイプに対して次に優先度が高いサーバーに、リクエストが送信されます。
詳細は、第11.1.1項「フェイルオーバー・ロード・バランシング」を参照してください。

- 最適。複数のリモートLDAPサーバー間に優先度が設けられません。飽和レベルが最も低いLDAPサーバーが、リクエストを処理するサーバーになります。最適なルートが選択されるように、リモートLDAPサーバーの飽和レベルは定期的に再評価されます。
詳細は、第11.1.2項「最適ロード・バランシング」を参照してください。

- 比例。すべてのリモートLDAPサーバーが、設定された比率(重み)に基づいてリクエストを処理します。
詳細は、第11.1.3項「比例ロード・バランシング」を参照してください。

- 飽和。飽和制限に達するまで、1つのメインLDAPサーバーがすべてのリクエストを処理します。
詳細は、第11.1.4項「飽和ロード・バランシング」を参照してください。

- 検索フィルタ。複数のLDAPサーバーがデプロイされ、リクエスト検索フィルタの特定の属性に基づいてリクエストを処理します。詳細は、第11.1.5項「検索フィルタ・ロード・バランシング」を参照してください。

11.1.1 フェイルオーバー・ロード・バランシング

フェイルオーバー・アルゴリズムを使用したロード・バランシングでは、プロキシが、特定の操作タイプ(追加操作など)に対して優先度が一番高いリモートLDAPサーバーまたはデータ・センターにリクエストをルーティングします。リモートLDAPサーバーが停止するまで、プロキシは優先度ルートにリクエストを送信し続けます。これは、ネットワークの切断、ハードウェアの障害、ソフトウェアの障害などの問題が原因になります。フェイルオーバーにより、プロキシは、特定の操作タイプに対する2番目の優先度のサーバーに着信リクエストをルーティングします。

図11-1は、フェイルオーバー・ロード・バランシングの構成を示しています。この例では、3つのルートがあり、それぞれ、操作タイプごとに一意の優先度が設定されています。追加操作はすべて、最高優先度(priority=1)が設定されているサーバー1によって処理され、バインド操作はサーバー2によって処理されます。サーバー1が停止すると、追加リクエストは、2番目の優先度が設定されているサーバー2に送信されます。

図11-1 フェイルオーバー・ロード・バランシングの例

デフォルトでは、停止したサーバーが再度実行しても、プロキシはそのサーバーへのリクエストの再ルーティングをすぐには行いません。たとえば、サーバー1が停止すると、追加リクエストはサーバー2に送信されます。サーバー1が再起動しても、着信した追加リクエストは、サーバー2が処理し続けます。ただし、サーバー2が停止して、サーバー1が再起動している場合、サーバー1が着信リクエストを再び受信するようになります。このデフォルト動作は、switch-backフラグで変更できます。switch-backフラグの構成については、第15.1.3.5.2項「switch-backフラグの設定」を参照してください。

フェイルオーバーを効果的に実行するには、ビジネス・ニーズに合った間隔内でフェイルオーバーが発生するように監視チェック間隔を低く設定する必要があります。監視チェック間隔の詳細は、第29章「Oracle Unified Directoryの監視」を参照してください。

11.1.2 最適ロード・バランシング

最適ロード・バランシング・アルゴリズムでは、プロキシは、最低飽和レベルのルートにリクエストを送信します。ルート上のリモートLDAPサーバーの飽和レベルが、そのデプロイメントでの他のリモートLDAPサーバーの飽和レベルを超えるまで、プロキシはリクエストをこのルートに送信し続けます。飽和レベルは割合で表されます。

ルートの飽和レベルが変わると、ロード・バランシング・アルゴリズムが最適なルートを再評価し、必要に応じて別のルートを選択します。最低飽和レベルのルートが、常に最適ルートとして選択されます。図11-5の構成では、最低飽和レベルのサーバーはサーバー1であり、この飽和レベルが他のサーバーの飽和レベルを超えるまで、サーバー1がすべてのリクエストを処理します。サーバーの1つが停止すると、その飽和レベルは100%になります。

図11-2 最適ロード・バランシングの例

飽和精度を構成して、ルートが最低飽和レベルのサーバーに切り替わる前の2つのサーバー間の飽和レベルの差を設定できます。デフォルトでは、飽和精度は5に設定されています。ただし、アルゴリズムがサーバー間で頻繁に切り替わっている場合は、飽和精度を10に設定できます。飽和精度はLDAPサーバーの拡張で設定します。詳細は、第15.1.3.5.3項「最適アルゴリズムまたは飽和アルゴリズムでの飽和精度の設定」を参照してください。

11.1.2.1 飽和レベルの決定

飽和レベルは、接続プール内の使用中の接続数と、その構成済の最大サイズとの割合を示します。接続プールの最大サイズは、LDAPサーバー拡張オブジェクトの拡張パラメータの1つです。

使用中の接続数が、最大プール・サイズの2で割った数より小さい場合、飽和は0になります。これは、プールが飽和していないことを意味します。

接続の半分以上が使用中である場合、次のように飽和レベルが計算されます:

100 * (1 - 使用可能な接続数/(最大プール・サイズ/2))

この計算により、すべての接続が使用中であるとき、飽和レベルが100になります。

11.1.3 比例ロード・バランシング

比例ロード・バランシング・アルゴリズムでは、プロキシは、複数のルート間において、設定されている比率に基づいて、リモートLDAPサーバーまたはデータ・ソースにリクエストを転送します。ルートによって処理されるリクエストの比率は、構成内の各ルートに対して設定した重みによって識別されます。重みは整数値で表されます。

ロード・バランシングを構成する際に、各LDAPサーバーが処理するリクエスト比率を示す必要があります。図11-3の例では、2:1という重みが設定されているため、サーバー1は、サーバー2の2倍の数の接続を処理します。サーバー2とサーバー3は、同じリクエスト量を処理します(1:1)。

図11-3 比例ロード・バランシングの例

図11-4に示されているように、クライアント操作の各タイプに対して重みを構成できます。たとえば、サーバー1で全バインド操作を処理するように設定できます。そのためには、バインドの重みをサーバー1は1 (以上)に設定し、サーバー2とサーバー3は0に設定します。

図11-4の例では、サーバー1は、サーバー2とサーバー3の3倍の追加リクエストを処理します。ただし、サーバー1が処理する検索リクエストは、サーバー2とサーバー3が処理する半分になります。サーバー2とサーバー3は、追加リクエストと検索リクエストについて同じ量を処理しますが、バインド・リクエストは処理しません。

図11-4 リクエスト固有管理を行う比例ロード・バランシング

図11-4のように、バインド、追加および検索以外の操作の重みを変更しなければ、サーバーは他のすべての操作(削除など)については、同じロードを共有します。

比例ロード・バランシングにおけるルートの重みの構成の詳細は、第15.1.3.5項「ロード・バランシングのプロパティの変更」を参照してください。

11.1.4 飽和ロード・バランシング

飽和ロード・バランシング・アルゴリズムでは、プロキシは、選択された優先度のルートにリクエストを送信します。そのルートのリモートLDAPサーバーが、設定されている飽和しきい値を超えるまで、プロキシは、その優先度のルートにリクエストを送信し続けます。飽和しきい値は割合で表されます。

たとえば、1つのリモートLDAPサーバーですべての着信リクエストを管理する必要がある場合、このサーバーに優先度1を設定します。飽和索引が70%に達するとリクエストの処理を停止するように同じリモートLDAPサーバーを設定するには、図11-5のように、飽和しきい値を70%に設定します。このようにすると、サーバーは飽和レベルが70%に達するまで、全着信リクエストを処理します。そして、プロキシは、次に優先度の高いサーバー2に、リモートLDAPサーバーへの新しいリクエストをすべて送信します。サーバー2は、サーバー2の飽和しきい値に達するまで、またはサーバー1の飽和レベルが再び低くなるまで、リクエストを処理し続けます。

つまり、サーバー1の飽和レベルが70%に達すると、プロキシはサーバー2にリクエストを送信し始めます。サーバー1が70%のままで、サーバー2が60%に達すると、プロキシは、新しいリクエストをサーバー3に送信します。

ただし、サーバー2がリクエストを処理しているときに、サーバー1の飽和レベルが55%まで落ちると、サーバー2が飽和しきい値に達していない場合でも、プロキシはサーバー1に新しい全リクエストを送信し始めます。

図11-5 飽和ロード・バランシングの例

すべてのルートが飽和しきい値に達する場合、プロキシは、飽和レベルが最低のルートを選択します。

サーバーが飽和レベルに達したときに警告を発するように、飽和しきい値アラートを設定することができます。たとえば、飽和しきい値アラートを60%に設定した場合、サーバーがこの値に達すると通知が届き、サーバーのパフォーマンスが低下しすぎないうちに対応策をとることができます。

飽和レベルの決定方法の詳細は、第11.1.2.1項「飽和レベルの決定」を参照してください。

11.1.5 検索フィルタ・ロード・バランシング

検索フィルタ・ロード・バランシング・アルゴリズムでは、プロキシは、リクエスト検索フィルタで定義されている特定属性に基づいてLDAPサーバーに検索リクエストをルーティングします。

トポロジは、プロキシ経由でアクセス可能な複数のLDAPサーバーで構成されます。すべてのLDAPサーバーには似たデータが含まれますが、各サーバーが、より高いパフォーマンスを提供するように検索フィルタで定義された属性に基づいて最適化されます。各ルートを、許可属性リストと禁止属性リストで構成できます。リクエストの検索フィルタに少なくとも1つの許可属性が含まれ、禁止属性が含まれていない場合に、検索リクエストはルートと一致します。

図11-6は、検索フィルタ・ロード・バランシング・アルゴリズムを示しています。この例では、3つのLDAPサーバーがあり、3つの個別ルートが設定されています。LDAPサーバー1は索引としてuid属性を持ち、LDAPサーバー2は索引としてcn属性を持ち、3つ目のLDAPサーバーはパススルー・ルートです。

図11-6 検索フィルタ・ロード・バランシング

プロキシが、検索フィルタにuid属性を含む検索リクエストを受信すると、検索リクエストは、より高いパフォーマンスのためLDAPサーバー1にルーティングされます。同様に、検索フィルタにcn属性が含まれている場合、検索リクエストはLDAPサーバー2にルーティングされます。他のすべての検索リクエストは、パススルーLDAPサーバー3にルーティングされます。

追加、削除、変更などのその他すべてのリクエストは、優先度ベースでLDAPサーバーにルーティングできます。各検索フィルタ・ルートに優先度が設定されます。この優先度によってルートの評価順序が決まります。検索フィルタに一致し、優先度が一番高いルート・フィルタが、リクエスト処理用に選択されます。すべての検索フィルタ・ルートの優先度が同じ場合、どのルートでもリクエストを処理できます。

11.2 プロキシを使用したデータ分散

Oracle Unified Directoryの分散機能は、水平スケーラビリティなど、全エントリを単一のデータ・ソースまたはLDAPサーバーに格納できない大規模デプロイメントに対応できる機能です。また、分散を使用して、1秒当たりの更新回数を調整することができます。

分散デプロイメントでは、まずデータを小さなチャンクに分割する必要があります。データを分割するには、split-ldifコマンドを使用します。このようなデータ・チャンクをパーティションと呼びます。通常、各パーティションは別々のサーバー上に格納されます。

データの分割は、次の分散アルゴリズムのいずれかに基づきます:

- 数値。エントリを、命名属性(たとえばuid)の数値に基づいて、パーティションに分割し、分散します。詳細は、第11.2.1項「数値分散」を参照してください。

- 辞書編集。エントリを、命名属性(たとえばcn)のアルファベット値に基づいて、パーティションに分割し、分散します。詳細は、第11.2.2項「辞書編集分散」を参照してください。

- 容量。エントリは、各パーティションの容量に基づいてパーティションに追加されます。このアルゴリズムは、追加リクエストにのみ使用されます。他のすべてのリクエストは、グローバル索引カタログまたはブロードキャストによって分散されます。詳細は、第11.2.3項「容量分散」を参照してください。

- DNパターン。エントリを、エントリDNのパターン(値)に基づいて、パーティションに分割し、分散します。詳細は、第11.2.4項「DNパターン分散」を参照してください。

選択するデータ分散タイプは、ディレクトリ・サービス内のデータの編成方法によります。数値分散と辞書編集分散は、特別な分散形式を持ちます。DNパターンは、既存のデータ分散モデルと一致させるのに使用できます。

クライアント・リクエスト(追加以外)が、分散パーティションの1つとリンクできない場合、グローバル索引カタログが構成されていないかぎり、プロキシは、着信リクエストをすべてのパーティションにブロードキャストします。

ただし、リクエストが分散範囲外であることが明確な場合は、このリクエストは、エントリが存在しないことを示すエラーとともに返されます。たとえば、分散パーティションにuidが1-100 (partition1)と100-200 (partition2)が含まれている状態で、ベースDNがuid=222,ou=people,dc=example,dc=comの検索を実行すると、プロキシは、このエントリが存在しないことを示します。

さらに、数値アルゴリズムと辞書編集アルゴリズムの場合、分散ベースDNの直下の最初のRDNが、リクエストの処理用に使用されます。たとえば、次の検索はエラーを返します。uidが分散ベースDN (たとえばou=people,dc=example,dc=com)の直下の最初のRDNでないためです。

$ ldapsearch -b "uid=1010,o=admin,ou=people,dc=example,dc=com" "objectclass=*"

パーティション数は慎重に決めてください。デプロイメント内のパーティション数を定義する際、後でデータを分割し、新しいパーティションに再分散する場合、ダウンタイムが必要になることを念頭に置いておく必要があります。ただし、初期パーティション外のエントリを持つデータで、新しいパーティションを追加することはできます。

たとえば、初期パーティションが、uidが1-100のデータ(partition1)と100-200のデータ(partition2)で構成されている場合に、後で、200-300のuidを含むpartition3を追加することはできます。ただし、partition1とpartition2を分割して、たとえばpartition1に1-150のuidを含め、partition2に150-300のuidを含めることは簡単ではありません。パーティションの分割は、新しい分散デプロイメントを再構成するのと実質同じです。

11.2.1 数値分散

数値アルゴリズムを使用する分散では、プロキシは、リクエスト内の分散ベースDNの直下の最初のRDNの数値に基づいて、リクエストをパーティションの1つに転送します。数値アルゴリズムの分散を設定する場合、選択した属性の数値に基づいてデータベース上のデータをパーティションに分割します。このとき、選択する属性が数値文字列を表すものである必要があります。プロキシは、同じ数値アルゴリズムを使用して、適切なパーティションにすべてのクライアント・リクエストを転送します。

たとえば、図11-7に示されているように、エントリのuidに基づいて、2つのパーティションにデータを分割できます。

図11-7 数値分散の例

この例では、uidが1111のエントリの検索はパーティション1に送信され、uidが2345のエントリの検索はパーティション2に送信されます。定義されているパーティション範囲外のuidのエントリに対するリクエストについては、そのエントリが存在していないことが示されます。

注意:

分散アルゴリズムの上限は含まれません。つまり、この例においては、uidが3000の検索では、このエントリが存在していないことを示すエラーが返されます。

例11-1 数値分散アルゴリズムを使用した検索例

次の検索は成功します:

$ ldapsearch -b "uid=1010,ou=people,cn=example,cn=com" "cn=Ben"

ただし、次の検索では、エントリが存在しないことが示されます(結果コード32):

$ ldapsearch -b "uid=1010,o=admin,ou=people,cn=example,cn=com" "objectclass=*"

$ ldapsearch -b "uid=99,ou=people,cn=example,cn=com" "objectclass=*"

プロキシが、上記定義されている分散アルゴリズムでエントリの所属するパーティションを判断できないため、次の検索はブロードキャストされます:

$ ldapsearch -b "ou=people,cn=example,cn=com" "uid=*"

11.2.2 辞書編集分散

辞書編集アルゴリズムを使用する分散では、プロキシは、リクエスト内の分散ベースDN直下の最初のRDNのアルファベット値に基づいて、リクエストをパーティションの1つに転送します。辞書編集アルゴリズムの分散を設定する場合、選択した属性のアルファベット値に基づいてデータベース上のデータをパーティションに分割します。プロキシは、同じアルゴリズムを使用して、適切なパーティションにすべてのクライアント・リクエストを転送します。

たとえば、図11-8に示されているように、エントリのcnに基づいて、2つのパーティションにデータを分割できます。

図11-8 辞書編集分散の例

この例では、cnがBenなど、Bで始まるエントリに対するリクエストはパーティション1に送信され、cnがM-Yのエントリに対するリクエストはパーティション2に送信されます。

注意:

分散アルゴリズムの上限は含まれません。つまり、この例において、cn= Zacharyの検索については、このエントリが存在していないことが示されます。検索範囲にZで始まるエントリを含めるには、unlimitedキーワードを使用する必要があります。たとえば、cn=[M..unlimited[には、M以降のすべてのエントリが含まれます。

例11-2 辞書編集分散アルゴリズムを使用した検索例

次の検索は成功します:

$ ldapsearch -b "cn=Ben,ou=people,cn=example,cn=com" "objectclass=*"

次の検索も、cn=Benが最初のRDNになるので、成功します。

$ ldapsearch -b "uid=1010,cn=Ben,ou=people,cn=example,cn=com" "objectclass=*"

ただし、次の検索では、エントリが存在しないことが示されます(結果コード32):

$ ldapsearch -b "cn=Ben,o=admin,ou=people,cn=example,cn=com" "objectclass=*"

$ ldapsearch -b "cn=Zach,ou=people,cn=example,cn=com" "objectclass=*"

次の検索は、所属するパーティションを判断できないので、ブロードキャストされます:

$ ldapsearch -b "ou=people,cn=example,cn=com" "cn=*"

11.2.3 容量分散

容量ベースの分散では、プロキシは、各パーティションの容量に基づいて追加リクエストを送信します。これは、パーティションに含めることができるエントリの最大数により判断されます。他のすべてのリクエストは、グローバル索引カタログまたはブロードキャストによって分散されます。

データは完全無作為にパーティションに分散されるため、特定のデータ・エントリが所属するパーティションを識別する最も簡単な方法はグローバル索引を使用する方法です。容量分散を使用する場合は、グローバル索引は必須です。グローバル索引がセットアップされていない場合、追加以外のすべてのリクエストはブロードキャストされます。グローバル索引の詳細は、第11.3項「グローバル索引カタログ」および第15.1.7項「コマンドラインを使用したグローバル索引の構成」を参照してください。

図11-9 容量分散の例

図11-9の例では、パーティション1は、パーティション2の2倍の容量があるので、パーティション1は、パーティション2より2倍の追加リクエストを受信します。この場合、両方のパーティションが同時に一杯になります。すべてのパーティションが一杯になったら、各サイクルで各パーティションに1つのリクエストが送信されます。

11.2.4 DNパターン分散

DNパターン・アルゴリズムを使用する分散では、プロキシは、リクエスト・ベースDNと文字列パターンとの照合に基づいて、リクエストをパーティションの1つに転送します。照合は、リクエスト・ベースDNの相対部分、つまり、分散ベースDN以下の部分についてのみ行われます。たとえば、図11-10に示されているように、エントリのuid内のDNパターンに基づいて、2つのパーティションにデータを分割できます。

DNパターンを使用する分散は、数値アルゴリズムまたは辞書編集アルゴリズムを使用する分散より面倒です。できるかぎり、別の分散アルゴリズムを使用するようにしてください。

図11-10 DNパターン分散の列

この例では、0、1、2、3または4で終わるuidのすべてのデータ・エントリがパーティション1に送信されます。5、6、7、8または9で終わるuidのデータ・エントリはパーティション2に送信されます。

この分散は、数値を使用していますが、数値分散とはまったく異なります。数値分散では、データは数値の範囲に基づいて分割されますが、DNパターン分散は、データ文字列のパターンに基づきます。

DNパターン・アルゴリズムを使用する分散は、通常、分散パーティションが分散ベースDNに正確に対応していない場合に使用します。たとえば、データが図11-11で示されているように分散されている場合、パーティション1とパーティション2のデータは、ベースDN ou=people,ou=region1とou=people,ou=region2の両方に該当します。データを簡単に分散するには、DNパターンを使用する以外方法がありません。

図11-11 ディレクトリ情報ツリーの例

例11-3 地域別分割DNパターン・アルゴリズムの例

情報のデプロイメントが2つの地域で行われている場合、データの分散にはDNパターン分散を使用するのが簡単です。たとえば、従業員番号が4桁コードで、最初の桁が地域を示している場合、次のようになります:

地域1

地域2

1000

2000

1001

2001

1002

2002

1003

2003

1004

2004

1005

2005

1006

2006

1007

2007

1008

2008

1009

2009

1010

2010

...

...

データのロードを分散するのに各地域内のエントリを2つのサーバーに分割します。このとき、サーバー1には、0、1、2、3および4で終わるすべてのエントリが含まれ、サーバー2には、5、6、7、8および9で終わるすべてのエントリが含まれます(図11-10参照)。

したがって、DNパターン1222の検索はパーティション1に送信され、2222も同様です。

11.3 グローバル索引カタログ

分散デプロイメントでグローバル索引カタログを使用できます。容量ベース分散を構成する場合、DNを索引とするグローバル索引カタログをセットアップする必要があります。グローバル索引カタログは、エントリと、そのデータを格納する分散パーティションとをマップします。プロキシはクライアントからリクエストを受信すると、分散が、グローバル索引カタログで属性エントリを検索して、クライアント・リクエストを正しいパーティションに転送します。これにより、ブロードキャストの手間を省くことができます。さらに、DN変更リクエストが行われる場合、グローバル索引カタログにより、そのエントリが確実に存在することを確認することができます。

グローバル索引カタログは、従業員番号や電話番号など、特定の属性に基づいてエントリをマップします。索引とする属性値は、全エントリにおいて一意である必要があります。たとえば、一意でない国などに基づいて、グローバル索引を使用してエントリをマップすることはできません。

値が一意でない属性を索引とした場合、プロキシが、リクエストされるすべてのエントリを返せないことがあります。たとえば、必ずしも一意とはかぎらないmail属性を索引にしたとします。そして、次の2つのエントリを連続で追加します:

- uid=user.1およびmail=joe.smith@example.comの属性を持つエントリ1はパーティション1に送信されます。

- uid=user.2およびmail=joe.smith@example.comの属性を持つエントリ2はパーティション2に送信されます。

この状況では、グローバル索引mailは、2つ目のエントリへの参照のみを保持します。この場合、フィルタ(mail=joe.smith@example.com)の検索を実行すると、2つ目のエントリuid=user.2のみが返されることになります。

グローバル索引カタログには、複数のグローバル索引を含めることができます。各グローバル索引でそれぞれ異なる属性のマッピングを行います。たとえば、電話番号をベースにしたエントリのマッピングを行うグローバル索引と、従業員番号をベースにしたエントリのマッピングを行うグローバル索引を含むGI-catalogというグローバル索引カタログをセットアップできます。この場合、電話番号または従業員番号のいずれかを使用して、正しいパーティションにクライアント・リクエストを転送できます。

グローバル索引カタログとグローバル索引は、gicadmコマンドを使用して作成および構成されます。詳細は、第15.1.7項「コマンドラインを使用したグローバル索引の構成」および付録A「gicadm」を参照してください。

グローバル索引には、LDIFファイルからデータを移入できます。1つのLDIFファイルのデータは、split-ldifコマンドを使用してパーティションに分割できます。詳細は、付録A「split-ldif」を参照してください。

シングル・ポイント障害を回避するために、グローバル索引カタログはレプリケートする必要があります。グローバル索引カタログのレプリケートについては、第15.1.7.2項「グローバル索引カタログのレプリケーション」を参照してください。

例11-4 電話番号のグローバル索引カタログの使用

グローバル索引の作成に使用できる一意の属性の一般的な例は、電話番号です。この属性値は一意になるので、その電話番号を持っている人物(従業員など)は1人のみです。

次の例では、データベース内のエントリは電話番号に基づいて分割されています。グローバル索引には、次の情報が含まれています:

値

パーティションID

4011233

1

4011234

1

7054477

2

グローバル索引には、従業員名、場所または電話番号に関連付けることのできるその他の属性値は格納されません。属性の索引とパーティションとのマッピングのみが行われます。索引値(ここでは電話番号)に関連付けられているデータは、リモートLDAPサーバー上に置かれています。

1人の従業員が複数の電話番号を持っている場合、複数値エントリとしての扱いになります。この場合、グローバル索引が電話番号に基づいて作成される際、たとえばBen Brownという1人の従業員を検出するグローバル索引エントリが2つできるということになります。

前述の例では、従業員Ben Brownには、4011233と7054477の両方の電話番号が割り当てられています。この場合、Ben Brownの1つの電話番号を検索すれば、Ben Brownに2つの電話番号が割り当てられていることとは関係なく、正しいパーティションと、その電話番号に関連付けられている、Ben Brownという名前を含むすべての情報が返されます。

11.4 プロキシを使用したDNリネーム

ディレクトリの各エントリは、DNおよび属性と属性値のセットにより識別されます。クライアント側で定義されたDNおよび属性は、サーバー側で定義されたDNおよび属性にマップされない場合があります。たとえば、サンプルAという組織ではdc=parentcompany, dc=comというエントリを使用しているとします。ここに、サンプルBという別の組織が加わりました。このサンプルBは、dc=newcompany, dc=comというエントリを使用しています。つまり、既存のクライアント・アプリケーションを正しく動かすには、dc=newcompany, dc=comをdc=parentcompany, dc=comにリネームする必要があります。

DNリネーム・ワークフロー要素を定義して、DNをサーバー側と一致する値にリネームできます。クライアントがリクエストを行うと、DNと属性の名前がサーバー側と一致するように変更されます。結果がクライアントに返されるときには、DNと属性はクライアント側と一致するよう元に戻されます。

11.4.1 DNリネーム・ワークフロー要素の動作

Oracle Unified Directoryでは、ディレクトリ情報ツリー(DIT)のコンテンツを、異なるベースDNの別のDITに変換できるDNリネーム・ワークフロー要素が用意されています。ある操作(追加、バインド、削除、変更など)がDNリネーム・ワークフロー要素を通ることにより、DNリネーム構成に従ってパラメータが変換され、仮想エントリから実際のエントリへの変換が行われます。

図11-12は、プロキシを使用したDNリネームの動作を示しています。

図11-12 DNリネーム

クライアントはou=myorg, dc=server, dc=comエントリを待機します。しかし、LDAPサーバー上のエントリはou=people, dc=server, dc=comです。プロキシは、DNリネーム・ワークフロー要素を使用してしてDNのリネームを行います。

この例では、実際のエントリou=people, dc=server, dc=comを、クライアントからはou=myorg, dc=server, dc=comエントリに見えるようにします。

DNリネーム変換は、次のオブジェクトに対して適用可能です:

- エントリのDN。たとえば、LDAPサーバー上の実際のエントリであるdn:uid=user, ou=people, dc=server, dc=comが、クライアントの仮想エントリdn:uid=user, ou=myorg, dc=server, dc=comに変換されます。

- DNを含むエントリの属性。たとえば、オブジェクトクラスinetorgpersonmanagerのエントリのmanager属性のサーバー側の値がmanager:uid=mgr, ou=people, dc=server, dc=comである場合に、クライアント側の値であるmanager:uid=mgr, ou=myorg, dc=server, dc=comに変換します。

注意:

変換は、エントリのすべてのユーザー属性に適用できます。このとき、該当する属性リストを定義したり、該当しない属性リストを定義することもできます。

11.5 RDNの変更

Oracle Unified Directoryでは、RDNChanging構成を使用して、ソース・ディレクトリからOracle Unified Directoryに対して、RDN値をリネームまたは置換することが可能です。

図11-13は、プロキシを使用したDNリネームの動作を示しています。

図11-13 RDNの変更

注意:

相対識別名(RDN)は、エントリDNの左端の要素です。たとえば、uid=Marcia Garza,ou=People,dc=example,dc=comのRDNは、uid=Marcia Garzaです。変更できるのは、エントリDNの一番左の要素のみです。

RDNChanging構成には、次のパラメータがあります:

オブジェクト・クラス

RDNの名前変更を実行するオブジェクト・クラスのタイプを指定します。デフォルト設定はpersonです。

置換値

TrueまたはFalse: クライアント・ビュー内の元のRDN値(source-rdnパラメータで指定)を新しいRDN値(client-rdnパラメータで指定)に置き換えるかどうかを指定します。デフォルトの設定はtrueです。

注意:

この値がtrueに設定されており、エントリの新しいRDN属性に複数の値がある場合、Oracle Unified DirectoryではRDNの最初の値が使用されます。

source-rdn

Oracle Unified Directoryで置換または変更される、ソース・ディレクトリの元のRDN属性名を指定します。

client-rdn

Oracle Unified Directoryで使用される新しいRDN属性名を指定し、source-rdn構成パラメータで指定されている属性名と置き換えます。

dn-attributes

RDNの名前変更を実行するDNを持つ属性のリスト。属性のデフォルト・リストはmember、managerおよびownerです。

11.6 変換フレームワークの理解

Oracle Unified Directoryは、ワークフロー要素の定義を介したデータ変換をサポートしています。ワークフロー要素のインスタンスを作成することにより、物理データを異なる方法で表示できます。この章では、Oracle Unified Directoryで変換がどのように発生するのかについて説明します。この章の内容は次のとおりです:

- 第11.6.1項「変換の概要」

- 第11.6.2項「変換のコンポーネント」

- 第11.6.3項「変換の構成」

11.6.1 変換の概要

LDAPクライアント・アプリケーションのデータ構造が、LDAPリポジトリのデータ構造と異なる場合があります。スキーマが異なる場合もあれば(エントリ内の属性タイプが異なる)、値が異なる場合もあります(属性名は同じでも値のセマンティクスが異なる)。これが、変換が必要な対象となります。

1つの変換は、特定の方向における特定のアクションを実行します。必要な変換を指定し、既存のワークフロー要素に対する変換を定義します。

この項には次のトピックが含まれます:

- 第11.6.1.1項「変換モデル」

- 第11.6.1.2項「Oracle Unified Directoryでの変換の実装」

11.6.1.1 変換モデル

変換の方向は、変換がリクエスト中に適用されるのか、応答中に適用されるのか、または両方に適用されるのかを示し、これにより変換モデルが決まります。

変換は次のタイプに分類できます:

- 読取り変換(アウトバウンド変換): 詳細は、第11.6.1.1.1項「読取り変換」を参照してください。

- 書込み変換(インバウンド変換): 詳細は、第11.6.1.1.2項「書込み変換」を参照してください。

- マッピング変換(双方向変換): 詳細は、第11.6.1.1.3項「マッピング変換」を参照してください。

11.6.1.1.1 読取り変換

読取り変換は、一般的に使用される変換です。読取り変換は、リクエストへの応答中にのみ発生します。リクエスト中には変換は行われず、物理データの変更はありません。

図11-14は、読取り変換の概念を示しています。

図11-14 読取り変換

組織に、personエントリを表示するレガシー・アプリケーションがあるとします。このアプリケーションは、email属性を含まないエントリをサポートしません。物理データ・ソースはアップグレードされており、email属性はpersonエントリから削除されています。

そこで、検索応答中にemail属性を追加するという変換が必要になります。この変換は、データ・ソースから読み取られるエントリを変更し、email属性を追加します。このとき、この属性値はfirstname.surname@mycompany.comになります。元に戻す変換は必要ないので、物理データは変更されません。

11.6.1.1.2 書込み変換

書込み変換は、応答中ではなく、リクエスト中に適用される変換です。書込み変換は、バックエンドに格納する前に、クライアントによって提供されたデータを変更します。

図11-15は、書込み変換の概念を示しています。

図11-15 書込み変換

組織に、personエントリをデータ・ソースに追加するレガシー・アプリケーションがあるとします。このアプリケーションは、email属性なしでエントリを追加します。物理データ・ソースはアップグレードされており、email属性はpersonエントリの必須属性となっています。そこで、追加リクエスト中にemail属性を追加するという変換が必要になります。この変換は、データベースに書き込むエントリを変更します。逆の変換は必要ありません。

11.6.1.1.3 マッピング変換

マッピング変換は、一般的に使用される変換です。これは、まず変換がリクエスト中に適用され、逆の変換が応答中に適用されるという双方向の変換です。このような変換は、物理データ・ビュー内の属性またはエントリが、仮想データ・ビュー内の属性またはエントリにマップされるため、マッピング変換と呼ばれます。マッピング変換では、既存値を、DNコンポーネント、属性タイプまたは値、またはオブジェクト・クラスに割り当てる前に、処理することができます。

図11-16は、マッピング変換の概念を示しています。

図11-16 マッピング変換

組織に、surnameおよびfirstnameの属性を持つエントリが格納される物理データ・ソースがあるとします。この組織には、firstname surnameという形式のcn (共通名)属性を持つエントリを要求するクライアント・アプリケーションがあります。

このクライアント・アプリケーションは、cn=Joe Smithという形式のエントリの検索リクエストを送信します。変換は、このリクエスト中に名(firstname)と姓(surname)を抽出し、このリクエストをsurname=Smith, firstname=Joeという形式に変換するように定義されています。対応するエントリは、データ・ソース内にあります。このエントリをクライアント・アプリケーションに戻す前に、逆の変換が実行されます。クライアント・アプリケーションは、認識できるcn=Joe Smithというエントリを受信します。

このリクエストは、surname=Smith, firstname=Joeという形式に変換されます。

11.6.1.2 Oracle Unified Directoryでの変換の実装

Oracle Unified Directoryは、プロキシ・サーバーでの変換をサポートするLDAPサーバーです。

変換を実装するには、次のことが必要です:

- 変換タイプのワークフロー要素のインスタンスを作成します。

- 目的のワークフロー要素リストに変換ワークフロー要素を挿入します。

Oracle Unified Directoryのアーキテクチャの詳細は、第4.2項「Oracle Unified Directoryのアーキテクチャ」を参照してください。

変換ワークフロー要素インスタンスは、特定の変換アクションが定義されているデータ・ビューのことです。

11.6.2 変換のコンポーネント

この項では、変換のワークフロー要素を構成するためのコンポーネントについて説明します。次のトピックが含まれます:

- 第11.6.2.1項「変換のタイプ」

- 第11.6.2.2項「変換条件」

- 第11.6.2.3項「変換のための属性値の定義」

11.6.2.1 変換のタイプ

変換タイプのワークフロー要素は、次の変換セットで構成できます:

注意:

説明:

- クライアント側: Oracle Unified Directoryサーバーがクライアント・アプリケーションと対話する側を指します。

- ソース側: Oracle Unified Directoryサーバーがローカル・データ・ソースを持つデータ・ソースとして、またはリモート・サーバーを持つプロキシ・サーバーとして対話する側を指します。

- インバウンド方向: 変換がクライアントからソースに適用される方向を指します。

- アウトバウンド方向: 変換がソースからクライアントに適用される方向を指します。

この項には次のトピックが含まれます:

- 第11.6.2.1.1項「addOutboundAttribute変換タイプ」

- 第11.6.2.1.2項「filterOutboundAttribute変換タイプ」

- 第11.6.2.1.3項「addInboundAttribute変換タイプ」

- 第11.6.2.1.4項「filterInboundAttribute変換タイプ」

- 第11.6.2.1.5項「mapAttribute変換タイプ」

11.6.2.1.1 addOutboundAttribute変換タイプ

この変換は、検索操作中、リクエスト内の属性リストが未定義(つまり、すべて該当)な場合、またはその属性が含まれている場合に、クライアントに返されるエントリに、仮想属性または値を追加します。

エントリに仮想属性がすでに含まれているかどうか判断できない場合、conflict-behaviorパラメータが、次のポリシーのどれを適用するかを決定します:

- 仮想値を追加しない

- 仮想値を追加して、既存値とマージする

- 既存値を仮想値に置き換える

仮想属性をソース・リポジトリで検索できる場合(ソース・リポジトリ内のエントリの一部に仮想属性が含まれており、この属性について検索が最適化されている)、およびフラグvirtual-in-sourceが設定されている場合、変換プロセスは、SEARCH REQUESTフィルタで仮想属性をソース・リポジトリに転送します。通常、仮想属性はソース・リポジトリに転送されません。このパラメータがFALSEに設定されている場合、検索リクエストは一般用に最適化されているということです。つまり、仮想属性はソース・リポジトリには存在していないことを意味します。

注意:

追加リクエストまたは変更リクエストに仮想属性を含めることが必要とされる場合は、ソース・スキーマ・チェックが適用されます。したがって、仮想属性を受け入れるようにソースのスキーマを構成することをお薦めします。それ以外の場合は、スキーマ・チェックを無効にしてください。

表11-1は、addOutboundAttribute変換タイプのパラメータを説明しています。

表11-1 addOutboundAttribute変換タイプのパラメータ

パラメータ

dsconfig CLI

複数(M)/単一(S)値

オプション(O)/必須(M)

値

クライアント仮想属性の名前とクライアント仮想属性の値定義

client-attribute

S

M

文字列

詳細は、第11.6.2.3項「変換のための属性値の定義」を参照してください。

たとえば、displayName=%cn%は、属性displayNameを値cnで発行します。

競合動作ポリシー

conflict-behavior

S

O [デフォルト=merge-real-and-virtual]

merge-real-and-virtual

real-overrides-virtual

virtual-overrides-real

ソース内の仮想ポリシー

virtual-in-source

S

O [デフォルト = FALSE]

TRUE、FALSE

エントリが一致する必要があるフィルタベースの条件

entry-match-filter

S

O [デフォルト = ワークフロー要素によって処理されるすべてのエントリに適用]

LDAPフィルタ

祖先である必要があるDNベースの条件

entry-parent-suffix

M

O [デフォルト = ワークフロー要素によって処理されるすべてのリクエストに適用]

DN

処理する操作から操作を除外する条件

excluded-operation

M

O [デフォルト = すべてのLDAP操作に適用]

列挙(ADD、MODIFY...)

11.6.2.1.2 filterOutboundAttribute変換タイプ

この変換では、ソースから受信したエントリをクライアントに送信する前に、ここから属性または値を削除します。

表11-2は、filterOutboundAttribute変換タイプのパラメータを説明しています。

表11-2 filterOutboundAttribute変換タイプのパラメータ

パラメータ

dsconfig CLI

複数(M)/単一(S)値

オプション(O)/必須(M)

値

ソース仮想属性の名前とクライアント仮想属性の値定義

source-attribute

S

M

文字列

詳細は、第11.6.2.3項「変換のための属性値の定義」を参照してください。

たとえば、certificate=verisignは、certificate属性のverisign値をフィルタリングします。

エントリが一致する必要があるフィルタベースの条件

entry-match-filter

S

O [デフォルト = ワークフロー要素によって処理されるすべてのエントリに適用]

LDAPフィルタ

祖先である必要があるDNベースの条件

entry-parent-suffix

M

O [デフォルト = ワークフロー要素によって処理されるすべてのリクエストに適用]

DN

処理する操作から操作を除外する条件

excluded-operation

M

O [デフォルト = すべてのLDAP操作に適用]

列挙(ADD、MODIFY...)

11.6.2.1.3 addInboundAttribute変換タイプ

この変換は、追加操作の実行中、データをソースに転送する前に、クライアントから受信したエントリに仮想属性または値を追加します。

エントリに仮想属性がすでに含まれているかどうか判断できない場合、conflict-behaviorパラメータが、次のポリシーのどれを適用するかを決定します:

- 仮想値を追加しない

- 仮想値を追加して、既存値とマージする

- 既存値を仮想値に置き換える

表11-3は、addInboundAttribute変換タイプのパラメータを説明しています。

表11-3 addInboundAttribute変換タイプのパラメータ

パラメータ

dsconfig CLI

複数(M)/単一(S)値

オプション(O)/必須(M)

値

ソース仮想属性の名前とソース仮想属性の値定義

source-attribute

S

M

文字列

詳細は、第11.6.2.3項「変換のための属性値の定義」を参照してください。

たとえば、email={%cn%.%sn%@mycompany.com}は、email属性を、cn属性とsn属性から導出した値で書き込みます。

競合動作ポリシー

conflict-behavior

S

O [デフォルト=merge-real-and-virtual]

merge-real-and-virtual

real-overrides-virtual

virtual-overrides-real

エントリが一致する必要があるフィルタベースの条件

entry-match-filter

S

O [デフォルト = ワークフロー要素によって処理されるすべてのエントリに適用]

LDAPフィルタ

祖先である必要があるDNベースの条件

entry-parent-suffix

M

O [デフォルト = ワークフロー要素によって処理されるすべてのリクエストに適用]

DN

処理する操作から操作を除外する条件

excluded-operation

M

O [デフォルト = すべてのLDAP操作に適用]

列挙(ADD、MODIFY)

11.6.2.1.4 filterInboundAttribute変換タイプ

この変換では、追加(および変更)時に、クライアントから受信したエントリ(および変更)をソースに送信する前に、ここから属性または値を削除します。

表11-4は、filterInboundAttribute変換タイプのパラメータを説明しています。

表11-4 filterInboundAttribute変換タイプのパラメータ

パラメータ

dsconfig CLI

複数(M)/単一(S)値

オプション(O)/必須(M)

値

クライアント仮想属性の名前とクライアント仮想属性の値定義

client-attribute

S

M

文字列

詳細は、第11.6.2.3項「変換のための属性値の定義」を参照してください。

たとえば、certificate=verisignは、certificate属性のverisign値をフィルタリングします。

同様に、secondarylocation=%primarylocation%は、primarylocationの値と一致した場合に、secondarylocation値をフィルタリングします。

エントリが一致する必要があるフィルタベースの条件

entry-match-filter

S

O [デフォルト = ワークフロー要素によって処理されるすべてのエントリに適用]

LDAPフィルタ

祖先である必要があるDNベースの条件

entry-parent-suffix

M

O [デフォルト = ワークフロー要素によって処理されるすべてのリクエストに適用]

DN

処理する操作から操作を除外する条件

excluded-operation

M

O [デフォルト = すべてのLDAP操作に適用]

列挙(ADD、MODIFY...)

11.6.2.1.5 mapAttribute変換タイプ

この変換では、両方向において、クライアント属性を1つのソース属性にリネームしたり、値の変換を行うことができます。

表11-5は、mapAttribute変換タイプのパラメータを説明しています。

表11-5 mapAttribute変換タイプのパラメータ

パラメータ

dsconfig CLI

複数(M)/単一(S)値

オプション(O)/必須(M)

値

クライアント属性の名前とクライアント仮想属性からソース仮想属性へのマッピングの値定義

client-attribute

S

M

文字列

詳細は、第11.6.2.3項「変換のための属性値の定義」を参照してください。

たとえば、displayName=%cn%は、displayName属性をcn属性値に置き換えて発行し、cn属性をdisplayName属性値に置き換えて書き込みます。

ソース内の仮想ポリシー

virtual-in-source

S

O [デフォルト = FALSE]

TRUE、FALSE

競合動作ポリシー

conflict-behavior

S

O [デフォルト=merge-real-and-virtual]

merge-real-and-virtual

real-overrides-virtual

virtual-overrides-real

エントリが一致する必要があるフィルタベースの条件

entry-match-filter

S

O [デフォルト = ワークフロー要素によって処理されるすべてのエントリに適用]

LDAPフィルタ

祖先である必要があるDNベースの条件

entry-parent-suffix

M

O [デフォルト = ワークフロー要素によって処理されるすべてのリクエストに適用]

DN

処理する操作から操作を除外する条件

excluded-operation

M

O [デフォルト = すべてのLDAP操作に適用]

列挙(ADD、MODIFY...)

11.6.2.2 変換条件

条件付きで変換ワークフロー要素を構成できます。条件は、transformations-workflow-elementまたは個々のtransformationに対して設定できるプロパティ(属性)です。変換は、LDAPリクエストがすべての条件およびワークフロー要素レベルで設定されているすべての条件を満たしている場合のみ、実行されます。

変換の実装には、次の条件を使用できます:

- 変換を実施するかどうかを決定するルールに対して条件を構成できます。

- transformations-workflow-elementに対して条件を設定できます。この場合、そのworkflow-elementに設定されているすべての変換に対して条件が照合され、各変換が実際に処理される前に評価されます。

- 個々の各変換に対しても条件を設定でき、この変換の実際の処理前に評価されます。

条件は、広い意味で次のカテゴリに分類されます:

- 第11.6.2.2.1項「親接頭辞」

- 第11.6.2.2.2項「エントリ一致フィルタ」

- 第11.6.2.2.3項「除外LDAP操作」

11.6.2.2.1 親接頭辞

この条件は、指定されている1つの親接頭辞の下にある名前のエントリをターゲットとするLDAP操作のみに適用される変換に対して使用されます。

このタイプの条件が構成されていない場合、処理されるすべてのエントリに対して変換が適用されます。

11.6.2.2.2 エントリ一致フィルタ

この条件は、指定フィルタと一致するエントリに対するLDAP操作にのみ適用される変換に対して使用されます。

このタイプの条件が構成されていない場合、処理されるすべてのエントリに対して変換が適用されます。

11.6.2.2.3 除外LDAP操作

この条件は、複数値属性のリストを指定し、各属性が、変換によって影響を受けてはならないLDAP操作を示します。各LDAPプロトコル・メッセージに対する変換(ある場合)のアクションを無効にできます。

このタイプの条件が構成されていない場合、このタイプの変換が通常影響するすべてのLDAP操作に対して変換が実行されます。

11.6.2.3 変換のための属性値の定義

属性値により、変換中における仮想属性の値を定義できます。この値は、デフォルト値のままにすることもできますし、他の属性値から値を作成するルールにすることもできます。

addInboundAttribute、addOutboundAttributeおよびmapAttributeでは、追加する仮想属性の値を構成する必要があります。filterInboundAttributeおよびfilterOutboundAttributeでは、フィルタリングする値を構成することもできます。

属性は、次から値を導出できます:

- 第11.6.2.3.1項「定数」

- 第11.6.2.3.2項「別の属性の値」

- 第11.6.2.3.3項「正規表現」

- 第11.6.2.3.4項「値のマッピング」

- 第11.6.2.3.5項「複数値仮想属性」

11.6.2.3.1 定数

静的なデフォルト値の属性を生成したり、属性の静的な値でフィルタリングする場合に使用します。

たとえば、プロパティsource-attribute:mycompany=Acmeは、デフォルトの会社名を指定する際に使用します。

dsconfig --create-transformation \
--type add-inbound-attribute \
--set source-attribute:mycompany=Acme \
--transformation-name virtDeptName \

11.6.2.3.2 別の属性の値

%inputAttrName%構文を使用して、処理対象のエントリ内の既存の属性から新しい属性を作成したり、別の属性から取得する値をフィルタリングできます。

たとえば、プロパティsource-attribute:displayName=%cn%は、cn属性の値から新しい属性値を取得する必要があることを示します。

dsconfig --create-transformation \
--type add-inbound-attribute \
--set source-attribute:displayName=%cn% \
--transformation-name virtDeptName \

注意:

同じtransformations-workflow-elementで生成される別の仮想属性は参照しないでください。評価順序が保証されません。

11.6.2.3.3 正規表現

{expression}構文を使用して、既存の属性値を操作することにより、属性値を作成したり、属性値をフィルタリングできます。

たとえば、プロパティclient-attribute:mail={%cn%.%sn%@mycompany.com}は、既存の属性の値を組み合せて属性を導出するための正規表現です。

dsconfig create-transformation \
--type add-outbound-attribute \
--set client-attribute:mail={%cn%.%sn%@mycompany.com} \
--transformation-name virtDeptName \

11.6.2.3.4 値マッピング

virtAttrName=%refAttrName%(virtValue1,refValue1)(virtValue2,refValue2)構文を使用して、別の属性の値のマッピングとして仮想値を定義します。

virtAttrNameパラメータに対して、変換が、refAttrNameから抽出された値を追加またはフィルタリングします。refAttrNameがrefValue1と一致すれば、変換は、virtValue1に対する追加またはフィルタリングを行います。指定する値内の文字(、)、,および\は\文字でエスケープ処理する必要があります。

たとえば、複数の部署を持つ組織があり、取得される部署IDにより、部署名が、Department:1–Marketing、2–Sales、3–Financeなどのように返されます。ただし、deptIdが1の場合、deptNameに対して返される値はMarketingです。deptIdが2の場合は、deptName値はSalesです。同様に、deptIdが3の場合は、deptNameに対して返される値はFinanceです。

dsconfig --create-transformation \
--type add-outbound-attribute \
--set client-attribute:deptName=%deptId%(Marketing,1)(Sales,2)(Finance,3) \
--transformation-name virtDeptName

11.6.2.3.5 複数値仮想属性

virtAttrName=virtAttrValue1=virtAttrValue2=構文を使用して、複数値仮想属性を指定します。

dsconfig --create-transformation \
--type add-outbound-attribute \
--set client-attribute:countriesResp=France=Germany=Italy \
--transformation-name virtCountriesRep

11.6.3 変換の構成

この項では、変換ワークフロー要素の構成方法について説明します。この項の内容は次のとおりです:

- 第11.6.3.1項「構成モデルの概要」

- 第11.6.3.2項「CLIを使用した変換の構成例」

11.6.3.1 構成モデルの概要

transformations-workflow-elementおよびtransformationは、変換構成の中心的なエントリです。

変換ワークフロー要素は、変換への参照リストを含むコンテナです。1つの変換は複数のtransformation-workflow-elementによって再利用できます。条件は、transformations-workflow-elementまたはtransformationのいずれかに対して設定できるプロパティ(属性)です。

表11-6では、transformations-workflow-elementに対して構成できるパラメータについて説明します。

表11-6 transformations-workflow-elementの構成パラメータ

パラメータ

dsconfig CLI

複数(M)/単一(S)値

オプション(O)/必須(M)

値

変換タイプのリスト

詳細は、第11.6.2.1項「変換のタイプ」を参照してください。

変換オブジェクト(関連付け)

M

M

変換の参照

エントリが一致する必要があるフィルタベースの条件

詳細は、第11.6.2.2.2項「エントリ一致フィルタ」を参照してください。

entry-match-filterプロパティ

S

O [デフォルト = ワークフロー要素によって処理されるすべてのエントリに適用]

LDAPフィルタ

祖先である必要があるDNベースの条件

詳細は、第11.6.2.2.1項「親接頭辞」を参照してください。

entry-parent-suffixプロパティ

M

O [デフォルト = ワークフロー要素によって処理されるすべてのリクエストに適用]

DN

処理する操作から操作を除外する条件

詳細は、第11.6.2.2.3項「除外LDAP操作」を参照してください。

excluded-operationプロパティ

M

O [デフォルト = すべてのLDAP操作に適用]

列挙(ADD、MODIFY...)

変換の実行順序は構成できません。たとえば、変換Aと変換Bを使用するtransformation-workflow-elementを使用するとします。このとき、エントリに対して変換Aを先に実行してから変換Bを実行するように指定することはできません。Bの後にAである可能性もあります。

変換の実行順序を定義する必要がある場合、たとえば、変換Aを変換Bの前に実行する必要がある場合は、変換Aを使用するtransformation-workflow-elementを最初に作成することをお薦めします。次に、変換Bを使用する別のtransformation-workflow-elementを作成します。そして、2つ目のtransformation-workflow-elementを最初のtransformation-workflow-elementの後に配置します。

図11-17は、高レベルな構成モデルを示しています。

図11-17 構成モデル

11.6.3.2 CLIを使用した変換の構成例

この項の例は、CLIで変換を作成し、変換ワークフロー要素を作成し、変換を追加し、条件を関連付ける方法について説明します。

次の手順で変換を構成します:

1. まず、filter-outbound-attributeタイプの変換を作成します。

$ dsconfig --create-transformation -X -n -Q -p -D cn="directory manager" -j pwd-file \
--set source-attribute:description \
--type filter-outbound-attribute\
--transformation-name fodescription

2. add-outbound-attributeタイプの別の変換を作成します。

$ dsconfig --create-transformation -X -n -Q -p -D cn="directory manager" -j pwd-file  \
--set client-attribute:legacyemail=%cn%.%sn%@mycompany.com \
--type add-outbound-attribute \
--transformation-name legacyemail

3. 最初の変換でtransformations-workflow-elementを作成し、これを処理フローに追加します。

$ dsconfig --create-workflow-element -X -n -Q -p -D cn="directory manager" -j pwd-file \
--set transformation:legacyemail \
--set set next-workflow-element:pxywfe \
--type transformations \
--element-name trsfwfe

$ dsconfig --set-workflow-prop -X -n -Q -p -D cn="directory manager" -j pwd-file \
--workflow-name pxywf \
--set workflow-element:trsfwfe

4. 2つ目の変換をワークフロー要素に追加します。

$ dsconfig --set-workflow-element-prop -X -n -Q -p -D cn="directory manager" -j pwd-file \
--element-name trsfwfe \
--add transformation:fodescription

5. cn=usersの下の変換のみ実行するという変換条件を定義します。

$ dsconfig --set-workflow-element-prop -X -n -Q -p -D cn="directory manager" -j pwd-file \
--element-name trsfwfe \
--set entry-parent-suffix:cn=users,dc=oracle

6. パリにいるユーザーにのみ変換を適用するように設定します。

$ dsconfig --set-workflow-element-prop -X -n -Q -p -D cn="directory manager" -j pwd-file \
--element-name trsfwfe \
--set entry-match-filter:l=Paris

7. 新しいマッピング変換を作成し、これをワークフロー要素に追加します。

$ dsconfig --create-transformation -X -n -Q -p -D cn="directory manager" -j pwd-file  \
--set client-attribute:faxnum=%facsimileTelephoneNumber% \
--type map-attribute \
--transformation-name mapfax

$ dsconfig --set-workflow-element-prop -X -n -Q -p -D cn="directory manager" -j pwd-file \
--element-name trsfwfe \
--add transformation:mapfax

8. この変換が人物に対してのみ適用されるように設定します。

$ dsconfig --set-transformation-prop -X -n -Q -p -D cn="directory manager" -j pwd-file \
--transformation-name mapfax \
--set entry-match-filter:\(objectclass=person\)

12 Oracle Unified Directoryのマッピングの理解

この章では、Oracle Unified Directoryのマッピングについて説明します。この章の内容は次のとおりです:

- 第12.1項「アイデンティティ・マッパーの概要」

- 第12.2項「サポートされているアイデンティティ・マッパー」

- 第12.3項「アイデンティティ・マッパーのコンポーネント」

- 第12.4項「アイデンティティ・マッパーの構成」

- 第12.5項「アイデンティティ・マッパーの選択」

- 第12.6項「アイデンティティ・マッパーの順序付け」

12.1 アイデンティティ・マッパーの概要

アイデンティティ・マッパーは、クライアントから提供されるID文字列と、そのIDに対応するユーザーのエントリ間にマッピングを構築します。アイデンティティ・マッパーは、複数のSASLメカニズムを処理して、認証ID(たとえば、GSSAPIを使用している場合はKerberosプリンシパル)をディレクトリ・ユーザーにマップします。アイデンティティ・マッパーは、プロキシ設定された認可制御によりリクエストを処理する際にも使用されます。

Oracle Unified Directoryは、複数のSASLアイデンティティ・マッパーをサポートします。たとえば、ユーザーxyz用にはアイデンティティ・マッパー1を使用し、残りのユーザーにはアイデンティティ・マッパー2を使用したりできます。これは、GSSAPIの利用時、@example.comと@oracle.comなど、ドメインの異なるユーザーに対して別々のアイデンティティ・マッパーが必要となる場合に便利です。

また、Oracle Unified Directoryは、DNではなくバインドIDであるID文字列に対するサポートも提供しています。ただし、これは、単純なバインドの場合にかぎられます。重要なことは、クライアントが、対応するアイデンティティ・マッパーによって許可されている単純バインドで属性を指定できる必要があるということです。次に例を示します:

ldapsearch -D "user@example.com" -w password -b "" objectclass=*

この例では、バインドIDはユーザーの電子メールIDです。

12.2 サポートされているアイデンティティ・マッパー

次のアイデンティティ・マッパーをサーバーで使用できます:

- 第12.2.1項「完全一致アイデンティティ・マッパー」

- 第12.2.2項「一致と置換アイデンティティ・マッパー」

12.2.1 完全一致アイデンティティ・マッパー

完全一致アイデンティティ・マッパーは、指定IDを値として持つ指定属性を含むエントリを検索することにより、ID文字列をユーザー・エントリにマップします。たとえば、DIGEST-MD5認証用にクライアントによって提供されるユーザー名は、uid属性値と一致する必要があります。この属性は、アイデンティティ・マッパー構成で指定されている必要があります。

これは、単純バインドと、GSSAPI以外のすべてのSASLバインドで主に使用されます。

12.2.2 一致と置換アイデンティティ・マッパー

一致と置換アイデンティティ・マッパーでは、適切なユーザー・エンティティを検索する際に、正規表現を使用して、指定IDを変換します。

たとえば、指定IDが電子アドレスまたはKerberosプリンシパルであるが、マッピング・プロセスで使用できるのがユーザー名(@記号の前の部分)のみである場合などに、このマッパーが使用されます。指定ID文字列のすべてまたは一部が指定マッチ・パターンと一致する場合のみ、置換が行われます。ID文字列の一部が指定パターンと一致しなかった場合、指定ID文字列が変更なしで使用されます。

これは、主にGSSAPIバインドで使用されます。

12.3 アイデンティティ・マッパーのコンポーネント

アイデンティティ・マッパーと直接関係するのは次のコンポーネントです:

- 第12.3.1項「グローバル構成」

- 第12.3.2項「ネットワーク・グループ」

12.3.1 グローバル構成

グローバル構成には、Oracle Unified Directoryの操作全体に影響するプロパティが含まれます。

12.3.2 ネットワーク・グループ

ネットワーク・グループは、着信クライアント接続を分類して、リクエストをワークフローにルーティングするのに使用されます。

12.4 アイデンティティ・マッパーの構成

アイデンティティ・マッパーは、次のインスタンスで構成されます:

- ネットワーク・グループ

- グローバル構成

簡単に言えば、ネットワーク・グループは、そのネットワーク・グループ固有のIDのマッピングに使用される1つ以上のアイデンティティおよび証明書のマッパーを含みます。アイデンティティまたは証明書のマッパーがネットワーク・グループ・レベルで定義されていない場合は、デフォルト設定としてグローバル・アイデンティティ・マッパーが使用されます。

この項には次のトピックが含まれます:

- 第12.4.1項「グローバル・アイデンティティ・マッパーの構成」

- 第12.4.2項「ネットワーク・グループ・アイデンティティ・マッパーの構成」

12.4.1 グローバル・アイデンティティ・マッパーの構成

アイデンティティ・マッパーは、デフォルトで、グローバル・レベルで構成されています。あるアイデンティティ・マッパーをグローバルに構成する必要がある場合、次のコマンドを実行してください:

dsconfig set-global-configuration-prop --add "generic-identity-mapper:Exact Match"

このコマンドは、Exact Matchアイデンティティ・マッパーがすでに存在していることが前提になっています。このアイデンティティ・マッパーは、デフォルトで構成されています。

12.4.2 ネットワーク・グループ・アイデンティティ・マッパーの構成

network-groupという名前のデフォルトの既存ネットワーク・グループに対して、次のように、generic-identity-mapperを構成します:

dsconfig set-network-group-prop --group-name network-group --set "generic-identity-mapper:Exact Match"

このコマンドは、Exact Matchアイデンティティ・マッパーがすでに存在していることが前提になっています。このアイデンティティ・マッパーは、デフォルトで構成されています。

12.5 アイデンティティ・マッパーの選択

通常、ネットワーク・グループごとに1つのアイデンティティ・マッパーが定義されます。generic-identity-mapperは、GSSAPIバインド以外のすべてのバインドに適用されるアイデンティティ・マッパーを定義します。gssapi-identity-mapperは、GSSAPIバインドにのみ適用されるアイデンティティ・マッパーを定義します。

前述したように、完全一致アイデンティティ・マッパーと一致と置換アイデンティティ・マッパーは、通常、それぞれgeneric-identity-mapperとgssapi-identity-mapperとして使用されます。ただし、必要に応じて、別の組合せを選択することもできます。

12.6 アイデンティティ・マッパーの順序付け

アイデンティティ・マッパーはregexパターンに基づいて選択されます。したがって、複数のアイデンティティ・マッパーが定義されている場合には、競合が発生することがあります。このような場合、アイデンティティ・マッパーをネットワーク・グループ内で評価する順序を定義することが必須になります。

.競合を解決するために、アイデンティティ・マッパーに対して優先度を定義できます。競合が発生すると、一番優先度が低いアイデンティティ・マッパーが選択され、マッピングに使用されます。優先度が同じ場合の動作は未定義です。

優先度を定義するには、次のコマンドを実行します:

dsconfig -h hostname -p admin_port -D USER set-identity-mapper-prop --mapper-name "Exact Match" --set "priority:2"

優先度値が低い方が実際の優先度が高くなります。ネットワーク・グループの優先度についても、同様の設定方法です。

第III部

基本的な管理

この部では、必要なデプロイメント・シナリオに応じたサーバーの起動と停止の方法、および様々なサーバー要素の構成方法について説明します。

この部には次の章が含まれます:

- 第13章「サーバーの起動と停止」

- 第14章「サーバー・インスタンスの構成」

- 第15章「プロキシ・コンポーネントの構成」

- 第16章「プロキシ構成の例」

- 第17章「ディレクトリ・データの管理」

- 第18章「Oracle Directory Services Managerを使用したOracle Unified Directoryへのアクセス」

- 第19章「ユーザーおよびグループの管理」

13 サーバーの起動と停止

この章では、サーバー・インスタンスの起動と停止の基本的な手順について説明します。この章で説明する手順は、Oracle Unified Directoryディレクトリ・サーバー、プロキシ・サーバーおよびレプリケーション・ゲートウェイ・インスタンスに適用されます。

この章には次のトピックが含まれます:

- 第13.1項「サーバーの起動」

- 第13.2項「サーバーの停止」

- 第13.3項 サーバーが起動しているか停止しているかの確認

- 第13.4項「非ルート・ユーザーとしてのサーバーの実行」

13.1 サーバーの起動

サーバーを起動するには、UNIXシステムまたはLinuxシステムではstart-dsコマンド、Windowsシステムではstart-ds.batコマンドを実行します。デフォルトでは、指定オプションがない場合、start-dsコマンドにより、サーバーはバックグラウンド・プロセスとして起動します。--nodetachオプション付きでstart-dsコマンドを実行すると、サーバーをフォアグラウンド・プロセスとして起動できます。詳細は、付録A「start-ds」を参照してください。

start-dsコマンドは、サーバーの起動時に使用する正しいJava環境を自動的に検出しようとします。Javaインストールのパスを指定して、ディレクトリ・サーバーの起動時にJVMに直接、追加オプションを転送することができます。詳細は、Oracle Fusion Middleware Oracle Unified Directoryインストレーション・ガイドのデフォルトJVMとJava引数の構成に関する項を参照してください。

13.1.1 start-dsを使用したサーバーの起動

1. 適切なディレクトリに移動します。

(UNIX, Linux)  $ cd INSTANCE_DIR/OUD/bin
(Windows)      C:\> cd INSTANCE_DIR\OUD\bat

2. 「start-ds」と入力します。

(UNIX, Linux)  $ start-ds
(Windows)      C:\> start-ds

13.1.2 フォアグラウンド・プロセスとしてのサーバーの起動

1. 適切なディレクトリに移動します。

(UNIX, Linux)  $ cd INSTANCE_DIR/OUD/bin
(Windows)      C:\> cd INSTANCE_DIR\OUD\bat

2. -Nまたは--nodetach付きで「start-ds」と入力します。

(UNIX, Linux)  $ start-ds --nodetach
(Windows)      C:\> start-ds --nodetach

サーバーが実行しているターミナル・ウィンドウで[Ctrl]を押しながら[C]を押すか、別のウィンドウからstop-dsユーティリティを実行して、ディレクトリ・サーバーを停止できます。

13.1.3 サーバーの再起動

1. インストール・ディレクトリに移動します。

(UNIX, Linux)  $ cd INSTANCE_DIR/OUD/bin
(Windows)      C:\> cd INSTANCE_DIR\OUD\bat

2. -Rまたは--restart付きで「stop-ds」と入力します。

(UNIX, Linux)  $ stop-ds --restart
(Windows)      C:\> stop-ds --restart

13.1.4 スクリプトを使用したサーバーの起動(UNIX/Linux)

start-dsコマンドには、重大なエラーが発生しないかぎり起動プロセス中の出力を抑制するquietオプション(-Qまたは--quiet)があります。起動スクリプトでこのオプションを使用できます。

1. シェル・スクリプトを作成して、次のstart-dsコマンドを追加します。

INSTANCE_DIR/OUD/bin/start-ds --quiet

2. スクリプトを実行します。

13.2 サーバーの停止

どのシステム上でも(サーバーがフォアグラウンドで実行している場合でもバックグラウンドで実行している場合でも)、またリモート・システムからでも、次のいずれかの方法でサーバーを停止できます。stop-dsコマンドの詳細は、付録A「stop-ds」を参照してください。

13.2.1 stop-dsを使用したサーバーの停止

1. 適切なディレクトリに移動します。

(UNIX, Linux)  $ cd INSTANCE_DIR/OUD/bin
(Windows)         C:\> cd INSTANCE_DIR\OUD\bat

2. 「stop-ds」と入力します。

(UNIX, Linux)  $ stop-ds
(Windows)      C:\> stop-ds

13.2.2 フォアグラウンドで実行しているサーバーの停止

この手順は、ディレクトリ・サーバーが(-Nまたは--nodetachオプションを使用して)フォアグラウンド・プロセスとして実行していることが前提です。

1. ターミナル・ウィンドウ(UNIX)または「コマンド プロンプト」ウィンドウ(Windows)で[Ctrl]を押しながら[C]を押して、サーバーを停止します。
または、別のウィンドウからstop-dsコマンドを実行します。

13.2.3 スクリプトを使用したサーバーの停止(UNIX/Linux)

stop-dsコマンドには、重大なエラーが発生しないかぎり停止プロセス中の出力を抑制するquietオプション(-Qまたは--quiet)があります。シャットダウン・スクリプトでこのオプションを使用できます。

1. シェル・スクリプトを作成して、次のstop-dsコマンドを追加します。

INSTANCE_DIR/OUD/bin/stop-ds --quiet

2. スクリプトを実行します。

13.3 サーバーが起動しているか停止しているかの確認

いつでも、statusコマンドを使用して、サーバーが起動しているか停止しているか確認することができます。

13.3.1 サーバー・ステータスの確認

1. 適切なディレクトリに移動します。

(UNIX, Linux)  $ cd INSTANCE_DIR/OUD/bin
(Windows)      C:\> cd INSTANCE_DIR\OUD\bat

2. 「status」と入力します。

(UNIX, Linux)  $ status
(Windows)      C:\> status

13.4 非ルート・ユーザーとしてのサーバーの実行

多くのネットワーク・デーモンのように、Oracle Directory Server Enterprise Editionにも、ルート・ユーザーとして起動し、権限を削って、実行機能の少ないユーザーとして実行できるsetuid機能があります。Oracle Unified Directoryには、現在この機能はありません。ただし、非ルート・ユーザーとしてサーバーをインストール、起動および実行できます。この項は、主にUNIXベースのプラットフォームを対象としています。Windowsシステムでは、今までも、管理者以外のユーザーにそれほど多くの制限はかけられていません。

13.4.1 非ルート・ユーザーとしてサーバーを実行する理由

多くの場合、初めから非ルート・ユーザーとしてサーバーを実行できることは、対応するsetuidより機能性に富んでいるため、便利なオプションになります。非ルート・ユーザーとしてサーバーを実行できれば、管理者にとって、操作上よく必要となるシステムへのルート・アクセスが必要なくなるということを意味します。さらに、ルート権限を削った場合には実行できなくなる可能性があることをサーバーが実行できるため、サーバーに対してより多くの管理アクションをオンラインで実行できます。

サーバーが通常はルート・ユーザーで起動または実行される主な理由は、ルート・ユーザーであれば特権ポート(1から1024までのポート)をリスニングできるためです。標準的なLDAP通信用ポートは389、標準的なLDAPS通信用ポートは636です。大部分のUNIXベース・システムでは、ルート・ユーザーのみがこれらのポートをリスニングするプロセスを作成できます。ルート・ユーザーとして起動する理由はほかにもありますが(大量のファイル記述子を使用できるなど)、一般的に、これら他の制限については回避するように構成する方が簡単です。

標準のLDAPポートとLDAPSポートは389と636ですが、サーバーは、これらのポートで実行する必要はありません。環境によっては、ルートとして起動する必要がないという理由により、1024より大きい(1389や1636などの)ポートでサーバーを実行する方が一般的です。実質すべてのLDAP対応クライアントで、サーバーがリスニングするポートを指定できます。クライアント側でサーバーが使用するポートがわかっていれば、どの値でも問題ありません。リスニング・ポートの構成については、第14.1.5.2項「LDAP接続ハンドラの構成」を参照してください。

13.4.2 標準LDAPポートで非ルート・ユーザーとして実行する方法

クライアント側で、サーバーがポート389または636をリスニングすることを必要としている場合でも、他のオプションがあります。最適なオプションは、Solaris 10以降のSolarisシステムで有効な方法で、プロセス権限管理サブシステム(最小権限とも呼ばれます)を使用します。Solarisの特権サブシステムは、非ルート・ユーザーとロールに、通常はルート・ユーザーにのみ実行可能な機能を提供できます(特権サブシステムがサーバー内で許可しているようなものです)。特に、net_privaddr権限は、特権ポートにバインドできるユーザーを制御します。この権限が非ルート・ユーザーに付与されれば、そのユーザーが特権ポートにバインドできるようになります。この権限をユーザーに構成するには、ルート・ユーザーとして次のコマンドを実行します:

# usermod -K defaultpriv=basic,net_privaddr,sys_resource,-proc_info,-file_link_any oud

このコマンドは、oudユーザーが、basic権限セット(非ルート・ユーザーがデフォルトで持っている権限)で起動できるように構成します。次に、net_privaddr権限とsys_resource権限を追加します。この権限により、使用可能なファイル記述子の数が増えるなどします。proc_info権限(他のユーザーが所有するプロセスを表示できる権限)とfile_link_any権限(自分が所有していないファイルへのハード・リンクを作成する権限)を削除します。このコマンドを実行した後、oudユーザーは、特権ポートをリスニングするサポートを起動できるようになります。

最小権限のような機能を持っていないシステムでも、起動するためにルート権限を要求することなく、389または636などの特権ポートでサーバーを公開することができます。非特権ポートでサーバーを実行し、特権ポートをリスニングするディレクトリ・プロキシ・サーバーを使用して、通信を非特権ポートのサーバーに転送するという方法もあります。同じ目的のためにネットワーク・ハードウェアを使用したり、同じシステム上でファイアウォール・ルールを設定する方法もあります。たとえば、Linuxシステムで次のコマンドを使用して、ポート389をターゲットとするトラフィックをポート1389にリダイレクトできます:

# iptables --append PREROUTING --table nat --protocol tcp --dport 389 \
--jump REDIRECT --to-port 1389
# iptables -t nat -A OUTPUT -p tcp --dport 389 -j DNAT --to :1389

14 サーバー・インスタンスの構成

サーバー構成にアクセスする最も簡単な方法は、dsconfigコマンドを使用する方法です。また、特定の構成については、Oracle Directory Services Managerを使用する場合もあります。

この章では、次のトピックを取り扱います:

- 第14.1項「dsconfigを使用したサーバー構成の管理」

- 第14.2項「Oracle Directory Services Managerを使用したサーバー構成の管理」

- 第14.3項「サーバーへの管理トラフィックの管理」

- 第14.4項「タスクとしてのコマンドの構成」

- 第14.5項「DSMLゲートウェイのデプロイおよび構成」

14.1 dsconfigを使用したサーバー構成の管理

この項は、デプロイされたOracle Unified Directoryインスタンスの構成と管理を行う必要がある管理者またはユーザーを対象としています。ここでは、dsconfigコマンドライン・ユーティリティの概要と、このコマンド・ユーティリティを使用したサーバー構成方法について説明します。

dsconfigコマンドを使用して、Oracle Unified Directoryのディレクトリ・サーバーとプロキシ・サーバーの両方を構成できます。ディレクトリ・サーバーまたはプロキシ・インスタンス用にサポートされているサブコマンドのリスト、およびこのコマンド固有の情報については、付録A「dsconfig」を参照してください。

dsconfigを使用して、プロキシ固有の多くのコンポーネントを構成できます。この項には次のトピックが含まれます:

- 第14.1.1項「dsconfigコマンドの概要」

- 第14.1.2項「対話型モードでのdsconfigの使用」

- 第14.1.3項「dsconfigのヘルプ」

- 第14.1.4項「dsconfigを使用したサーバー・インスタンスの構成」

- 第14.1.5項「dsconfigを使用した接続ハンドラの構成」

- 第14.1.6項「dsconfigを使用したネットワーク・グループの構成」

- 第14.1.7項「dsconfigを使用したワークフローの構成」

- 第14.1.8項「dsconfigを使用したワークフロー要素の構成」

- 第14.1.9項「dsconfigを使用したプラグインの構成」

- 第14.1.10項「dsconfigを使用した接尾辞の構成」

14.1.1 dsconfigコマンドの概要

dsconfigコマンドは、サーバー構成にアクセスするための簡単なメカニズムを提供します。dsconfigは、コンポーネント・セットとして構成を提供します。各コンポーネントが、1つ以上のサブコマンドにより管理できます。

dsconfigは対話型として使用することもできます。対話型モードでは、dsconfigは、ウィザードのようにサーバー構成を進めます。詳細は、第14.1.2項「インタラクティブ・モードでのdsconfigの使用」を参照してください。

dsconfigは、実行中のサーバー・インスタンスを構成する場合のみ有効です。オフライン構成はdsconfigではサポートされていません。

他の管理コマンドと同じように、dsconfigは、管理コネクタを使用してサーバーにアクセスします。詳細は、第14.3項「サーバーへの管理トラフィックの管理」を参照してください。この項で紹介する例はすべて、管理コネクタがデフォルト・ポート(4444)をリスニングし、コマンドは、ローカル・ホスト上で実行中のサーバーにアクセスすることを前提としています。そうでない場合は、--portオプションと--hostnameオプションを指定する必要があります。

この項には次のトピックが含まれます:

- 第14.1.1.1項「dsconfigおよび証明書のチェック」

- 第14.1.1.2項「dsconfigのサブコマンド」

- 第14.1.1.3項「dsconfigの拡張プロパティ」

14.1.1.1 dsconfigおよび証明書のチェック

dsconfigは、証明書認証を行う保護された接続で、サーバーにアクセスします。dsconfigを対話型モードで実行する場合、証明書の信頼方法について尋ねるメッセージが表示されます。

dsconfigを非対話型モード(つまり-nオプション付き)で実行する場合、トラスト・ストア・パラメータの指定は、コマンドをローカルで実行しているか、リモートで実行しているかによって異なります。

- dsconfigをローカルで実行。(コマンドは、ユーザーが管理しているサーバー上で起動。)トラスト・ストア・パラメータを指定しない場合、サーバーは、デフォルトでローカル・インスタンスのトラスト・ストアを使用します。明示的に指定しないかぎり、ローカル・インスタンス・トラストはINSTANCE_DIR/OUD/config/admin-truststoreです。

- dsconfigをリモートで実行。(コマンドは、ユーザーが管理していないサーバー上で起動。)トラスト・ストア・パラメータまたは-X (--trustAll)オプションを指定する必要があります。トラスト・ストア・パラメータを指定する最も簡単な方法は、対話型モードで1回コマンドを実行し、サーバーによって提示される証明書をトラスト・ストアに保存することです。

$ dsconfig

>>>> >>>> Specify Oracle Unified Directory LDAP connection parameters

Directory server hostname or IP address [host1.example.com]:
Directory server administration port number [4444]:
Administrator user bind DN [cn=Directory Manager]:
Password for user 'cn=Directory Manager':

How do you want to trust the server certificate?

1)  Automatically trust
2)  Use a truststore
3)  Manually validate

Enter choice [3]: 3

Administrator user bind DN [cn=Directory Manager]:

Password for user 'cn=Directory Manager':

Server Certificate:

User DN  : CN=host1.example.com, O=Administration Connector Self-Signed Certificate
Validity : From 'Wed Apr 29 11:13:21 MEST 2009'
To 'Fri Apr 29 11:13:21 MEST 2011'
Issuer   : CN=host1.example.com, O=Administration Connector Self-Signed Certificate

Do you trust this server certificate?

1)  No
2)  Yes, for this session only
3)  Yes, also add it to a truststore
4)  View certificate details

Enter choice [2]: 3

Truststore path: /local/instances/certificates/jctruststore

Password for keystore '/local/instances/certificates/jctruststore':

...

トラスト・ストアに証明書を保存しておけば、非対話型モードでそのトラスト・ストア・パラメータを指定できるようになります。

$ dsconfig -h localhost -p 4444 list-connection-handlers -n \
--trustStorePath /local/instances/certificates/jctruststore \
--trustStorePasswordFile /local/instances/certificates/jctruststore.pin -j pwd-file
Connection Handler       : Type : enabled : listen-port : use-ssl
-------------------------:------:---------:-------------:--------
JMX Connection Handler   : jmx  : false   : 1689        : false
LDAP Connection Handler  : ldap : true    : 1389        : false
LDAPS Connection Handler : ldap : false   : 636         : true
LDIF Connection Handler  : ldif : false   : -

14.1.1.2 dsconfigサブコマンド

dsconfigは、様々な構成要素を直感的に管理できるサブコマンド・リストを提供します。

これらのサブコマンドを使用して、様々なコンポーネントを追加、削除、リストアップ、表示および変更することができます:

サブコマンド

機能

dsconfig create-componentオプション

新規のコンポーネントを作成する

dsconfig delete-componentオプション

既存のコンポーネントを削除する

dsconfig get-component-propオプション

コンポーネントのプロパティを表示する

dsconfig list-componentsオプション

既存の定義済コンポーネントをリストする

dsconfig set-component-propオプション

コンポーネントのプロパティを変更する

たとえば、次の5つのサブコマンドが接続ハンドラの管理に使用されます:

サブコマンド

機能

dsconfig create-connection-handlerオプション

接続ハンドラを作成する

dsconfig delete-connection-handlerオプション

接続ハンドラを削除する

dsconfig get-connection-handler-propオプション

接続ハンドラのプロパティを表示する

dsconfig list-connection-handlersオプション

既存の定義済接続ハンドラをリストする

dsconfig set-connection-handler-propオプション

接続ハンドラのプロパティを変更する

すべてのタイプのコンポーネントを作成したり削除できるわけではありません。たとえば、ディレクトリ・サーバーのグローバル構成は1つのみです。このため、グローバル構成は、次の2つのサブコマンドでのみ管理されます:

サブコマンド

機能

dsconfig get-global-configuration-propオプション

グローバル構成プロパティを表示する

dsconfig set-global-configuration-propオプション

グローバル構成プロパティを変更する

すべてのコンポーネントの構成可能プロパティは、問合せして変更し、これによりコンポーネントの動作を変えることができます。たとえば、LDAP接続には、IPリスナー・アドレス、ポートおよびSSL構成を決定するプロパティがあります。

14.1.1.3 dsconfigの拡張プロパティ

多くのコンポーネント・プロパティが、拡張プロパティと見なされます。拡張プロパティは、デフォルトでは表示されませんが、通常適用されるデフォルト値を持っています。拡張プロパティの値を変更する場合は、サブコマンドの前に--advancedを付けます。例:

$ dsconfig --advanced get-extension-prop

14.1.2 対話型モードでのdsconfigの使用

すべての構成パラメータと-n (--no-prompt)オプションを指定した場合を除き、dsconfigはインタラクティブ・モードで実行します。対話型モードは、ウィザードのようにサーバー構成を進めます。対話型モードは、dsconfigの使用し始めに適しています。

dsconfigを対話型モードで実行する際、対応するコマンド(すべての設定内容を含む)を表示またはファイルに書き込むように指定できます。次の例は、--displayCommandオプションを使用して、トラスト・マネージャ構成時に、対応する非対話型コマンドを表示する方法を示しています。対応するコマンドは、そのコマンドがディレクトリ・サーバーによって適用および検証されたときに表示されます。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --displayCommand
...
The TrustStore Manager Provider was modified successfully

The equivalent non-interactive command-line is:
dsconfig --hostname "localhost" --port "4444" --bindDN "cn=directory
manager" --bindPasswordFile pwd-file --trustAll
set-trust-manager-provider-prop --provider-name "PKCS12" --set
"enabled:true"

対応するコマンドをファイルにコピーするには、次の例に示すように、--commandFilePathオプションを使用します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --commandFilePath /tmp/filename

14.1.3 dsconfigのヘルプ

dsconfigコマンドには、--helpオプションを使用してアクセスできる拡張オンラインヘルプがあります。この項ではその概要を示します。内容は次のとおりです:

- 第14.1.3.1項「グローバル使用」

- 第14.1.3.2項「正しいサブコマンドの確認」

- 第14.1.3.3項「個々のサブコマンドのヘルプ」

- 第14.1.3.4項「コンポーネントのプロパティの概要表示」

- 第14.1.3.5項「プロパティの詳細ヘルプ表示」

14.1.3.1 グローバル使用

次のコマンドを使用して、dsconfigのグローバル使用方法を表示できます:

$ dsconfig --help

14.1.3.2 正しいサブコマンドの確認

グローバル使用情報には、使用可能なサブコマンドのリストは含まれていません。サブコマンドのリストを取得するには、--help-xxxオプションを使用します。xxxは、表示されるサブコマンドのグループを示します。

注意:

--help-allオプションを使用すると、使用可能なすべてのサブコマンドが表示されます。

たとえば、分散に関連するすべてのサブコマンドを確認するには、次のコマンドを使用します:

$ dsconfig --help-distribution

14.1.3.3 個々のサブコマンドのヘルプ

必要なサブコマンドがわかっているときに、そのサブコマンドに関する詳細なヘルプ情報を参照するには、次のようにサブコマンドの--helpオプションを使用します:

$ dsconfig create-monitor-provider --help

14.1.3.4 コンポーネントのプロパティの概要表示

dsconfigコマンドには、すべてのコンポーネントとそのプロパティについてのドキュメントが組み込まれています。このドキュメントには、list-propertiesサブコマンドでアクセスできます。たとえば、次のコマンドを使用して、ワーク・キューに関連付けられているプロパティの概要を表示できます:

$ dsconfig list-properties -c work-queue

-cオプションが指定されていなければ、全コンポーネントのプロパティの概要が表示されます。

14.1.3.5 プロパティの詳細ヘルプ表示

概要表には、各プロパティの簡単な使用情報のみが表示されます。より詳細な情報を表示するには、list-propertiesサブコマンドの冗長モードを使用します:

$ dsconfig list-properties -c work-queue --property num-worker-threads -v

--propertyオプションを指定しない場合、すべてのワーク・キュー・プロパティの冗長ヘルプが提供されます。

14.1.4 dsconfigを使用したサーバー・インスタンスの構成

dsconfigコマンドは、サーバー構成にアクセスするための推奨ユーティリティです。ldap*ユーティリティを使用したLDAP経由で直接構成にアクセスする方法はお薦めできません。この項では、サーバー・コンポーネントにアクセスするためのユーティリティの操作について説明します。内容は次のとおりです:

- 第14.1.4.1項「コンポーネントのプロパティを表示するには」

- 第14.1.4.2項「コンポーネントを一覧表示するには」

- 第14.1.4.3項「コンポーネントを作成するには」

- 第14.1.4.4項「コンポーネントのプロパティを変更するには」

- 第14.1.4.5項「複数値プロパティの値を変更するには」

- 第14.1.4.6項「コンポーネントを削除するには」

- 第14.1.4.7項「バッチ・モードでdsconfigを使用するには」

14.1.4.1 コンポーネントのプロパティを表示するには

各コンポーネントには、そのコンポーネントのget-xxx-propサブコマンドを使用して表示できる1つ以上のプロパティがあります。各コンポーネントは、サーバー構成内の単一のLDAPエントリに関連付けられ、各プロパティは単一のLDAP属性に関連付けられています。

デフォルトのLDAP接続ハンドラのプロパティを表示するには、次のコマンドを実行します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
get-connection-handler-prop --handler-name "LDAP Connection Handler"

Property : Value(s)
------------------------:-------------------------------------------------------
allow-ldap-v2 : true
allow-start-tls : false
allowed-client : -
denied-client : -
enabled : true
keep-stats : true
key-manager-provider : -
listen-address : 0.0.0.0
listen-port : 1389
ssl-cert-nickname : server-cert
ssl-cipher-suite : -
ssl-client-auth-policy : optional
ssl-protocol : -
trust-manager-provider : -
use-ssl : false

dsconfigコマンドは、カスタマイズされていないプロパティのデフォルト値または動作を表示します。

14.1.4.2 コンポーネントを一覧表示するには

コンポーネントのlist-xxxsサブコマンドを使用して、そのコンポーネントのインスタンス・リストとその概要を表示できます。これは、同じコンポーネントに複数のインスタンスがある場合に特に便利です。

たとえば、構成済の接続ハンドラを一覧表示するには、次のコマンドを実行します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
list-connection-handlers

インストールに応じて、出力は次のものに類似したものになります。

Connection Handler       : Type : enabled : listen-port : use-ssl-------------------------:------:---------:-------------:--------JMX Connection Handler   : jmx  : false   : 1689        : falseLDAP Connection Handler  : ldap : true    : 1389        : falseLDAPS Connection Handler : ldap : false   : 636         : trueLDIF Connection Handler  : ldif : false   : -           : -SNMP Connection Handler  : snmp : false   : 161         : -

14.1.4.3 コンポーネントを作成するには

コンポーネントの新しいインスタンスは、コンポーネントのcreate-xxxサブコマンドを使用して作成できます。複数のサブタイプを持つコンポーネントもあります。たとえば、接続ハンドラには、LDAP、LDIF、JMXおよびSNMPの4つのタイプがあります。これらすべてが同じサブコマンドを使用して作成されるので、作成する必要があるコンポーネントのタイプを指定する必要があります。サブコマンドの-tまたは--typeを使用して指定します。

新しいコンポーネントを作成する際には、そのコンポーネントの必須プロパティを指定する必要があります。必須プロパティは、作成するコンポーネントのタイプによって異なります。たとえば、LDAP接続ハンドラとJMX接続ハンドラとでは必須プロパティが異なる可能性があります。必須プロパティが未定義のままの場合、dsconfigは、対話型モードに入り、未定義プロパティの入力が求められます。-n (非対話型)オプションを含めている場合、dsconfigは、コンポーネントの作成に失敗し、定義の必要があるプロパティを示すエラー・メッセージが表示されます。

1. 接続ハンドラ・コンポーネントのヘルプにアクセスすることにより、作成できる接続ハンドラのタイプを表示します。

$ dsconfig create-connection-handler --help

Usage: dsconfig create-connection-handler {options}
Creates Connection Handlers

Global Options:
See "dsconfig --help"

SubCommand Options:
--handler-name {NAME}
The name of the new Connection Handler
--set {PROP:VALUE}
Assigns a value to a property where PROP is the name of the property and
VAL is the single value to be assigned. Specify the same property multiple
times in order to assign more than one value to it
-t, --type {TYPE}
The type of Connection Handler which should be created. The value for TYPE
can be one of: custom | jmx | ldap | ldif | snmp

2. 必須のenabledプロパティとlisten-portプロパティに値を指定する必要がある新しいLDAP接続ハンドラを作成します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
create-connection-handler -t ldap --handler-name "My LDAP Connection Handler"

次のようなエラー・メッセージが表示されます。

The LDAP Connection Handler could not be created because the following
mandatory properties were not defined:

Property     Syntax
----------------------------------
enabled      false | true
listen-port  1 <= INTEGER <= 65535

14.1.4.4 コンポーネントのプロパティを変更するには

コンポーネントのプロパティは、そのコンポーネントのset-xxx-propサブコマンドを使用して変更できます。複数のプロパティは、--setオプションを複数回使用することにより、同時に変更できます。次の例では、set-connection-handler-propサブコマンドを使用して、接続ハンドラのプロパティを変更しています。

注意:

多くのコンポーネントには、そのコンポーネントの実装として使用されるJavaクラスの名前を指定するJavaクラス・プロパティがあります。このプロパティは変更しないでください。変更した場合、サーバーの操作が正しく実行されなくなる可能性があります。これらのプロパティは拡張プロパティとして扱われ、dsconfigを--advancedオプション付きで実行しないかぎり、表示されません。

たとえば、LDAPv2接続を受け入れるようにLDAP接続ハンドラを構成する場合は、次のコマンドを実行します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
set-connection-handler-prop --handler-name="LDAP Connection Handler" \
--set allow-ldap-v2:true

14.1.4.5 複数値プロパティの値を変更するには

1つのdsconfigコマンドで--addオプションを複数回使用することにより、プロパティに対して複数の値を設定できます。

この例では、allowed-clientプロパティに対して複数の値を設定します。

LDAP接続ハンドラで接続を特定のクライアントに制限するには、次のコマンドを実行します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
set-connection-handler-prop --handler-name "LDAP Connection Handler" \
--add allowed-client:myhost --add allowed-client:myhost.example \
--add allowed-client:myhost.example.com

14.1.4.6 コンポーネントを削除するには

コンポーネントの既存インスタンスは、dsconfig delete-xxxサブコマンドを使用して削除できます。

次の例では、前の例で作成したLDAP接続ハンドラを削除します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
delete-connection-handler --handler-name "My LDAP Connection Handler"

14.1.4.7 バッチ・モードでdsconfigを使用するには

dsconfigコマンドの-Fオプションまたは--batchFilePathオプションを使用して、1つのファイルにまとめることにより1回のコマンドで完了できる複数の操作を指定できます。この機能は、複数のdsconfigコマンドが必要な場合に、パフォーマンスを大幅に向上させることができます。

dsconfigをバッチ・モードで使用するには、次の手順に従います:

1. 新しい接尾辞が格納される新しいバックエンドを作成するための必要なコマンドが含まれるスクリプトを作成します。
たとえば、次のファイル(new-backend.txt)には3つのタスクがアーカイブされています:

- db-local-backendワークフロー要素を作成する

- uniquemember属性に対して索引入力制限を追加する(たとえばプロパティの設定方法。ただし、これは必須ではありません)

- 新しい接尾辞のワークフローを作成する

- デフォルトのネットワーク・グループに新しい接尾辞を登録する

create-workflow-element --element-name myBackend --type db-local-backend \
--set enabled:true --set base-dn:cn=myexample,cn=com
set-local-db-index-prop --element-name myBackend --index-name uniqueMember \
--set index-entry-limit:5000
create-workflow --workflow-name myWorkflow --set base-dn:cn=myexample,cn=com \
--set enabled:true --set workflow-element:myBackend
set-network-group-prop --group-name network-group --add workflow:myWorkflow

2. このファイルをパラメータとしてdsconfigコマンドを実行します。

$ dsconfig -h localhost -p 4444 -D cn="directory manager" -j pwd-file \
-F new-backend.txt -X -n

14.1.5 dsconfigを使用した接続ハンドラの構成

接続ハンドラは、接続の許可、リクエストの読取りおよび応答の送信を含む、クライアント・アプリケーションとのすべてのやり取りを処理します。

セキュアな接続の構成については、第20.5項「LDAPおよびJMX用のSSLおよびStartTLSの構成」を参照してください。

この項では、dsconfigコマンドを使用した接続ハンドラの構成方法について説明します。この項の内容は次のとおりです:

- 第14.1.5.1項「すべての接続ハンドラの表示」

- 第14.1.5.2項「LDAP接続ハンドラの構成」

- 第14.1.5.3項「LDIF接続ハンドラの構成」

- 第14.1.5.4項「JMX接続ハンドラの構成」

これらの項では、部分的な構成例のみを紹介しています。全構成プロパティの詳細を表示するには、次のコマンドを使用してください:

$ dsconfig list-properties -c connection-handler

14.1.5.1 すべての接続ハンドラの表示

Oracle Unified Directoryは、次のタイプの接続ハンドラをサポートします:

- LDAP接続ハンドラ。この接続ハンドラは、LDAPを使用するクライアントとのやり取りに使用されます。LDAPv3は完全サポート、LDAPv2は部分的にサポートされます。

- LDAPS接続ハンドラ。この接続ハンドラは、SSL経由でLDAPを使用するクライアントとのやり取りに使用されます。

- LDIF接続ハンドラ。この接続ハンドラは、内部操作によりサーバー内の変更を処理するために使用されます。

- JMX接続ハンドラ。この接続ハンドラは、Java Management Extensions (JMX)フレームワークとRemote Method Invocation (RMI)プロトコルを使用するクライアントとのやり取りを許可します。

- SNMP。この接続ハンドラは、SNMPリクエストを処理して、MIB 2605により示される監視情報を取得するために使用されます。サポートされているSNMPプロトコルは、SNMP V1、V2cおよびV3です。

構成済接続ハンドラのすべてを、その基本プロパティとともに表示するには、dsconfig list-connection-handlersコマンドを使用します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
list-connection-handlers

Connection Handler       : Type : enabled : listen-port : use-ssl
-------------------------:------:---------:-------------:--------
JMX Connection Handler   : jmx  : false   : 1689        : falseLDAP Connection Handler  : ldap : true    : 1389        : falseLDAPS Connection Handler : ldap : false   : 636         : trueLDIF Connection Handler  : ldif : false   : -           : -SNMP Connection Handler  : snmp : false   : 161         : -

14.1.5.2 LDAP接続ハンドラの構成

次のコマンドにより、LDAP接続ハンドラのプロパティが表示されます:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
get-connection-handler-prop --handler-name "LDAP Connection Handler"

次のように出力されます。出力内容は、構成によって異なります。

Property               : Value(s)
-----------------------:------------
allow-ldap-v2          : true
allow-start-tls        : false
allowed-client         : -
denied-client          : -
enabled                : true
keep-stats             : true
key-manager-provider   : -
listen-address         : 0.0.0.0
listen-port            : 1389
ssl-cert-nickname      : server-cert
ssl-cipher-suite       : -
ssl-client-auth-policy : optional
ssl-protocol           : -
trust-manager-provider : -
use-ssl                : false

14.1.5.2.1 ディレクトリ・サーバーにLDAP経由でアクセスするクライアントを制御するには

LDAP経由でディレクトリ・サーバーにアクセスできる、またはアクセスできないクライアントのリストを指定できます。LDAP接続ハンドラのallowed-clientプロパティまたはdenied-clientプロパティを設定します。これらのプロパティの値は、サブネットワーク・マスク付きIPアドレスまたはサブネットです。

デフォルトでは、これらのプロパティは設定されないので、すべてのクライアントがアクセスを許可されます。これらのプロパティの変更は、即時有効になりますが、すでに構築されている接続への干渉は発生しません。

この例では、サブネット・マスク255.255.255.10のクライアントにのみアクセスが許可されます。

dsconfigコマンドを次のように実行します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
set-connection-handler-prop --handler-name "LDAP Connection Handler" \
--set allowed-client:255.255.255.10

14.1.5.3 LDIF接続ハンドラの構成

LDIF接続ハンドラはデフォルトで無効になっています。この接続ハンドラを使用して、内部操作によりサーバー内の変更を処理できます。処理する変更はLDIFファイルから読み取られます。

次のコマンドにより、LDIF接続ハンドラのデフォルト・プロパティが表示されます:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
get-connection-handler-prop --handler-name "LDIF Connection Handler"

インストールに応じて、出力は次のものに類似したものになります。

Property       : Value(s)
---------------:-------------------------
allowed-client : -
denied-client  : -
enabled        : false
ldif-directory : config/auto-process-ldif
poll-interval  : 5 s

ldif-directoryプロパティは、LDIFファイルのディレクトリを指定します。接続ハンドラは、poll-intervalプロパティで指定されている間隔で、このディレクトリにファイルがあるかどうかを確認します。それから、接続ハンドラは内部操作としてこれらのファイルに含まれる変更を処理し、結果を出力ファイルに書き込みます。このとき、処理結果を示すコメントも書き込まれます。

14.1.5.3.1 LDIF接続ハンドラでJMXアラート・ハンドラを有効にするには

この例では、LDIF接続ハンドラからJMXアラート・ハンドラを有効にする方法を示します。

1. JMXアラート・ハンドラのステータスを確認します(デフォルトでは無効です)。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
get-alert-handler-prop --handler-name "JMX Alert Handler"

インストールに応じて、出力は次のものに類似したものになります。

Property            : Value(s)
--------------------:---------
disabled-alert-type : -
enabled             : false
enabled-alert-type  : -

2. デフォルトのLDIFディレクトリに、JMXアラート・ハンドラを有効にするLDIFファイルを作成します。

$ cd ../config/
$ mkdir auto-process-ldif
$ cd auto-process-ldif/
$ cat > disable-jmx.ldif << EOM
> dn: cn=JMX Alert Handler,cn=Alert Handlers,cn=config
> changetype: modify
> replace: ds-cfg-enabled
> ds-cfg-enabled: true
> EOM
$

3. poll-intervalの間隔後に、JMXアラート・ハンドラのステータスを再度確認します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
get-alert-handler-prop --handler-name "JMX Alert Handler"

Property            : Value(s)
--------------------:---------
disabled-alert-type : -
enabled             : true
enabled-alert-type  : -

14.1.5.4 JMX接続ハンドラの構成

次のコマンドにより、JMX接続ハンドラのデフォルト・プロパティが表示されます:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
get-connection-handler-prop --handler-name "JMX Connection Handler"

インストールに応じて、出力は次のものに類似したものになります。

Property             : Value(s)
---------------------:------------
allowed-client       : -
denied-client        : -
enabled              : false
key-manager-provider : -
listen-port          : 1689
ssl-cert-nickname    : server-cert
use-ssl              : false

14.1.5.4.1 JMX接続をリスニングするサーバーのポートを変更するには

この例では、JMX接続をリスニングするサーバーのポートを1789に変更します。

dsconfigコマンドを次のように使用します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
set-connection-handler-prop \
--handler-name "JMX Connection Handler" --set listen-port:1789

14.1.6 dsconfigを使用したネットワーク・グループの構成

ネットワーク・グループは、Oracle Unified Directoryに対する全クライアント・リクエストの単一のエントリ・ポイントです。ネットワーク・グループは、クライアントとのすべてのやり取りを処理し、これをディスパッチし、リクエスト処理をワークフローに委任します。クライアント接続は、一番優先度が高く、すべての条件を満たしているネットワーク・グループに関連付けられます。インストール時、優先度1のデフォルト・ネットワーク・グループが作成されます。リクエスト・フィルタリング・ポリシーまたはリソース制限を設定するには、ネットワーク・グループのサービス品質ポリシーを作成する必要があります。

各ネットワーク・グループは、1つ以上のワークフローに関連付けられます。ワークフローは、ネーミング・コンテキスト(または接尾辞)へのアクセスを提供します。ワークフローをネットワーク・グループに関連付けることにより、ネットワーク・グループに対して、使用可能なネーミング・コンテキストが示されます。通常、ワークフローが作成されている状態で、ネットワーク・グループを作成します。ワークフローの詳細は、第14.1.7項「dsconfigを使用したワークフローの構成」を参照してください。

この項では、dsconfigコマンドを使用したネットワーク・グループの構成方法について説明します。この項の内容は次のとおりです:

- 第14.1.6.1項「ネットワーク・グループの作成」

- 第14.1.6.2項「ネットワーク・グループのプロパティの変更」

- 第14.1.6.3項「ネットワーク・グループのサービス品質ポリシーの作成」

- 第14.1.6.4項「ネットワーク・グループのサービス品質ポリシーの変更」

- 第14.1.6.5項「ネットワーク・グループのルートDSEエントリの再配置」

次の手順内のコマンドではすべて、ホスト名(-h)、管理ポート(-p)、バインドDN (-D)およびバインド・パスワード・ファイル(-j)を指定します。各例では、すべての証明書を信頼するために-Xオプションが使用されます。

14.1.6.1 ネットワーク・グループの作成

多くのネットワーク・グループを作成できます。クライアント・リクエストは、条件を満たす一番高い優先度のネットワーク・グループによって処理されます。したがって、ネットワーク・グループを作成する際には、作成予定のすべてのネットワーク・グループと、各優先度を考慮する必要があります。優先度は0以上で、0が最も高い優先度になります。

同じ優先度の2つのネットワーク・グループを作成できます。ただし、2つ以上のネットワーク・グループが同じ優先度で、クライアント・リクエストと一致する場合、リクエストを処理するネットワーク・グループは、クライアント・リクエストと一致する他のネットワーク・グループ間においてランダムになります。したがって、各ネットワーク・グループに異なる優先度を指定する必要があります。

新しいネットワーク・グループのデフォルト・プロパティは次のとおりです。

Property                 Value(s)
----------------------------------------------------------------------
allowed-auth-method      All authorization methods are allowed.
allowed-bind-dn          All bind DNs are allowed.
allowed-bind-id          All bind IDs are allowed.
allowed-client           All clients with addresses that do not match
an address on the deny list are allowed. If
there is no deny list, then all clients are
allowed.
allowed-protocol         All supported protocols are allowed.
certificate-mapper       The global certificate mapper will be used.
denied-client            If an allow list is specified, then only
clients with addresses on the allow list are
allowed. Otherwise, all clients are allowed.
enabled                  true
generic-identity-mapper  The global generic identity mapper will be
used.
gssapi-identity-mapper   The global GSSAPI identity mapper will be
used.
is-security-mandatory    false
priority                 1
workflow                 userroot0

ネットワーク・グループを作成するには、次のようにdsconfig create-network-groupコマンドを使用します:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
create-network-group --group-name network-group1 --set enabled:true\
--set workflow:workflow1 --set priority:1

ネットワーク・グループを作成した後、ネットワーク・グループにネットワーク・グループのサービス品質ポリシーを関連付けることができます。サービス品質ポリシーの作成については、第14.1.6.3項「ネットワーク・グループのサービス品質ポリシーの作成」を参照してください。

14.1.6.2 ネットワーク・グループのプロパティの変更

ネットワーク・グループのプロパティは、トラフィックをフィルタリングし、リクエストの転送方法を示します。

dsconfig set-network-group-propコマンドを使用して、ネットワーク・グループのプロパティを変更できます。たとえば、ネットワーク・グループのpriorityを変更するには、次のように指定します:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
set-network-group-prop --group-name network-group1 --set priority:3

次の条件を設定するように、ネットワーク・グループのプロパティを構成できます:

- クライアントとネットワーク・グループ間で許可される認証方法(allowed-auth-method)。

- ネットワーク・グループへの接続が許可されるバインドDN (allowed-bind-dn)。

- Oracle Unified Directoryへのアクセスが承認されるクライアントのリスト(allowed-client)。リストは、クライアントのIPアドレスまたは名前で示されます。許可クライアント・リストが設定されていない場合、拒否クライアント・リストに含まれていなければ、すべてのクライアントが許可されます。

- Oracle Unified Directoryへの接続に使用できるプロトコル(allowed-protocol)。指定がなければ、すべてのプロトコルが許可されます。

- クライアント証明書をユーザー・エントリと照合させるために使用する証明書マッパーの名前(certificate-mapper)。指定がなければ、グローバル証明書マッパーが使用されます。

- Oracle Unified Directoryへのアクセスが承認されないクライアントのリスト(denied-client)。拒否クライアント・リストが設定されていない場合、許可クライアント・リストによる制限がなければ、すべてのクライアントが承認されます。

- 簡易非GSSAPI SASLバインド・リクエストとプロキシ認可制御の実行中にアイデンティティをマップするためにネットワーク・グループが使用するアイデンティティ・マッパーのセット(generic-identity-mapper)。

- GSSAPI/SASLバインド・リクエストの実行中にアイデンティティをマップするためにネットワーク・グループが使用するアイデンティティ・マッパーのセット(gssapi-identity-mapper)。

- クライアントとOracle Unified Directory間のセキュリティを常に必要とするかどうか(is-security-mandatory)。

- ネットワーク・グループの優先度(priority)。クライアント接続は、まず、一番優先度が高いネットワーク・グループと比較されます。クライアント接続が、その接続条件と一致しない場合、比較するネットワーク・グループの優先度を1つずつ下げていきます。ネットワーク・グループが選択されない場合、クライアント接続は拒否されます。

たとえば、次のように指定すると、IPアドレス208.77.188.166からの接続は、network-group1により拒否されます:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
set-network-group-prop --group-name network-group1 \
--set denied-client:208.77.188.166

14.1.6.2.1 許可/拒否クライアント・リストの設定

allowed-clientリストとdenied-clientリストに対しては、サーバーの名前サービス構成を知っている必要があります。たとえば、名前サービスがホストをmyclienthost.example.comとして認識する場合、値は、myclienthostではなく、myclienthost.example.comと指定する必要があります。同様に、名前サービスがホストをmyclienthostと認識する場合は、値はmyclienthostと指定する必要があります。名前サービスがどのように構成されているか知らない場合は、マシンの完全修飾ドメイン名(たとえばmyclienthost.sun.com)と短縮名(myclienthost)の両方を指定する必要があります。複数の値を指定することにより、名前が確実に正しく解決されます。例:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
set-network-group-prop \
--group-name network-group1 \
--add denied-client:myhost \
--add denied-client:myhost.example \
--add denied-client:myhost.example.com

これらの問題を回避するには、ホスト名より明確なIPアドレスを使用してください。

Oracle Unified Directoryに接続する際、localhostまたはローカル・マシンの名前を使用すると、クライアントのIPアドレスが変わってしまいます。localhostからの接続を拒否するには、拒否クライアント・リストにlocalhostとローカル・マシンの名前の両方を指定します。

14.1.6.3 ネットワーク・グループのサービス品質ポリシーの作成

オプションで、ネットワーク・グループとサービス品質(QoS)ポリシーを関連付けることができます。QoSポリシーは、ネットワーク・グループによるリクエストの処理方法を決定する追加フィルタリング条件をクライアント接続に適用します。

Oracle Unified Directoryは、次の4つのタイプのQoSポリシーをサポートします:

- リクエスト・フィルタリング・ポリシー

- リソース制限

- アフィニティ

- リフェラル

注意:

ODSMは、管理コネクタ経由でOracle Unified Directoryインスタンスにアクセスします。管理コネクタは、ネットワーク・グループに対して定義されているQoSポリシーの影響は受けません。したがって、ODSMは、ネットワーク・グループに対して定義されているQoSポリシーをバイパスします。詳細は、第14.3項「サーバーへの管理トラフィックの管理」を参照してください。

ネットワーク・グループのサービス品質ポリシーを作成するには、dsconfig create-network-group-qos-policyコマンドを使用します。サービス品質ポリシーが適用されるネットワーク・グループの名前と、サービス品質ポリシーのタイプを指定する必要があります。

14.1.6.3.1 リクエスト・フィルタリング・サービス品質ポリシーの作成

リクエスト・フィルタリング・ポリシーは、着信クライアント・リクエストに次の条件を適用します:

- allowed-attributes: 検索リクエストのフィルタに指定できる属性のリスト。

- allowed-operations: ネットワーク・グループによって許可される操作のタイプ。たとえば、ネットワーク・グループが読取りリクエストのみを許可するように指定できます。

- allowed-search-scopes: 許可される検索範囲。たとえば、1レベルのみ。

- allowed-subtrees: 検索リクエストにベースDNとして指定できる特定のサブツリーのリスト。

- prohibited-attributes: 検索リクエストのフィルタに指定すると拒否される属性のリスト。

- prohibited-subtrees: 検索リクエストでベースDNとして指定されていても、指定不可となるサブツリーのリスト。

次の例では、ユーザー操作として検索のみが許可され、データ変更は許可されないリクエスト・フィルタリング・ポリシーを定義します:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
create-network-group-qos-policy --group-name network-group1 \
--type request-filtering --set allowed-operations:search

14.1.6.3.2 リソース制限サービス品質ポリシーの作成

リソース制限ポリシーは、そのネットワーク・グループ経由でサーバーにアクセスできるクライアント接続に対して特定の制限を設定します。次の制限を定義できます:

- max-concurrent-ops-per-connection: 構築済接続に対して同時に実行できる操作の最大数。サーバーを同期モードで実行する場合には、この最大値は1に設定します。

- max-ops-per-connection: 接続単位での最大操作数。

- max-connections: サーバーに対する同時クライアント接続最大数。接続の最大数を設定しない場合、サーバー側の制限が適用されます。

- max-connections-from-same-ip: 同じIPアドレスからの最大接続数。サービス拒否攻撃を防ぎたい場合、このパラメータを使用します。ほとんどのリクエストが同じクライアントから送信されることが多いとわかっている場合には、このパラメータは設定しないでください。

- max-ops-per-interval: 指定間隔単位での最大操作数。たとえば、1,000と設定すると、max-ops-intervalによる間隔の間に実行できる操作は最大1,000に制限されます。

- max-ops-interval: max-ops-per-intervalパラメータで操作数をカウントする間隔。たとえば、この間隔を1秒と設定すると、秒単位で操作数がカウントされます。各間隔で制限(max-ops-per-interval)がチェックされ、適用されます。

- min-substring-length: 最小検索文字列長。検索文字列が短いほど、検出対象となり表示される結果が多くなります。したがって、この機能は、部分文字列検索フィルタで最小検索文字列長を設定して、使用されるリソースを制限するのに便利です。

- size-limit: 1回の検索でクライアントに返すことのできる最大エントリ数。このプロパティは、デフォルト設定にしておくことをお薦めします。

- time-limit: 検索処理にかけることのできる最大時間。このプロパティは、デフォルト設定にしておくことをお薦めします。

次の例では、戻り値数を制限するためにユーザーに5文字以上の検索文字列を入力させるリソース制限ポリシーを定義します:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
create-network-group-qos-policy --group-name network-group1 \
--type resource-limits --set min-substring-length:5

14.1.6.3.3 アフィニティ・サービス品質ポリシーの作成

ロード・バランシング・デプロイメントでは、アフィニティを使用して、通常のルーティング・プロセスをオーバーライドできます。アフィニティ・ポリシーのプロパティは、ルーティング・プロセスを決定します。

次のプロパティを構成できます:

- affinity-policy: 使用する必要があるルーティング・ポリシーを指定します。
アフィニティ・ポリシーは次のいずれかの値を使用できます:

- all-requests-after-first-request

- all-requests-after-first-write-request

- all-write-requests-after-first-write-request

- first-read-request-after-write-request

アフィニティ・ポリシーに従って、特定の操作がアフィニティを設定します。前述のリストの最初のポリシー(all-requests-after-first-request)では、すべての操作がアフィニティを設定します。残りのポリシー(all-requests-after-first-write-request、all-write-requests-after-first-write-requestおよびfirst-read-request-after-write-request)では、ADD、DELETE、MODまたはMODDNの操作がアフィニティを設定します。

- affinity-timeoutは、アフィニティが適用される期間を定義します。

前の操作でアフィニティがすでに設定されている場合でも、アフィニティ・ポリシーと現在の操作タイプに応じて、ロード・バランシング・アルゴリズムは特定の状況でのみバイパスされます。アフィニティ・ポリシーがall-requests-after-first-requestまたはall-requests-after-first-write-requestである場合、アフィニティ・タイムアウトが切れるまで、すべての操作タイプに対してそのアフィニティ・ルートが使用されます。アフィニティ・ポリシーがall-write-requests-after-first-writeである場合、アフィニティ・タイムアウトが切れるまで、ADD、DELETE、MODまたはMODDNの操作に対してそのアフィニティ・ルートが使用されます。他の操作に対してはアフィニティ・ルートは使用されません。アフィニティ・ポリシーがfirst-read-request-after-write-requestである場合、アフィニティ・タイムアウトが切れるまで、ADD、DELETE、MODまたはMODDNの操作以外のすべての操作に対してそのアフィニティ・ルートが使用されます。

次の例では、任意の操作に対して設定できるアフィニティ・ポリシーを設定し、最大60秒間、すべての操作に対して使用するよう定義します。

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
create-network-group-qos-policy --group-name network-group1 \
--type affinity --set affinity-timeout:60s \
--set affinity-policy:all-requests-after-first-request

注意:

アフィニティ機能は、フェイルオーバー・アルゴリズム以外のすべてのロード・バランシング・アルゴリズムで使用できます。フェイルオーバー・アルゴリズムでは、一度に1つのルートのみが有効になります。有効なルートは、リモート・サーバーに障害が発生したところで(リモート・サーバーへのすべての接続が切断されるため)、変更されます。したがって、アフィニティは、フェイルオーバー・シナリオには適用できません。

14.1.6.3.4 参照サービス品質ポリシーの作成

参照サービス品質ポリシーを定義することによって、リモートLDAPサーバーから参照を受信したときのプロキシ・サーバーの動作を構成できます。参照そのものは、リモートLDAPサーバーで定義する必要があります。

ネットワーク・グループのサービス品質を作成する際、次の参照プロパティを設定できます:

- 参照ポリシーをfollowに設定した場合にサポートされるホップ最大数(referral-hop-limit)。デフォルトは5です。

- discard、forward、followなど参照ポリシーのタイプを定義します(referral-policy)。これは、ネットワーク・グループによって参照が処理される方法を定義します。

たとえば、参照ポリシーはデフォルトでforwardに設定されます。これを次のようにdiscardまたはfollowに変更できます:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
create-network-group-qos-policy --group-name network-group1 \
--type referral --set referral-policy:follow

14.1.6.4 ネットワーク・グループのサービス品質ポリシーの変更

QoSポリシーを変更するには、dsconfig set-network-group-qos-policy-propコマンドを使用して、ネットワーク・グループとポリシー・タイプを指定します。

次の例では、リソース制限サービス品質ポリシーの最小検索文字列制限を設定します。

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
set-network-group-qos-policy-prop --group-name network-group1 \
--policy-type resource-limits --set min-substring-length:5

14.1.6.5 ネットワーク・グループのルートDSEエントリの再配置

ルートDSEは、サーバーの名前、ネーミング・コンテキスト、およびサポートされている機能に関する情報を提供する特別なエントリです。ネットワーク・グループのルートDSEエントリは、ローカル・サーバー内でもリモート・サーバー内でも設定できます。

ルートDSEを再配置するには、次の例に示すように、dsconfig set-network-group-propコマンドを使用します:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
set-network-group-prop --group-name network-group1 \
--set relocated-rootdse-workflow-element:<new rootDSE workflow element>  \

relocated-rootdse-workflow-elementプロパティの値は、ルートDSEを検出できるワークフロー要素です(これは、null DNで検索して返されるエントリです)。

14.1.7 dsconfigを使用したワークフローの構成

ワークフローは、ネットワーク・グループとネーミング・コンテキスト(接尾辞)間のリンクです。ワークフローは、ロード・バランシングまたは分散構成へのリクエストを処理する際に、特定のネットワーク・グループに対してアクセス可能なネーミング・コンテキストを定義します。ワークフローを作成する際には、ロード・バランシングまたは分散ワークフロー要素がすでに作成されている必要があります。ワークフロー要素の詳細は、第14.1.8項「dsconfigを使用したワークフロー要素の構成」を参照してください。

プロキシは、多くのプライベート・ワークフローを自動的に作成します。これらのワークフローは、変更または削除してはいけません。ワークフローの構成時には、リモートLDAPサーバーのプライバシ設定を考慮する必要があります。プライバシ設定は次のとおりです:

LDIFBackend

プロパティds-cfg-is-private-backendで定義されているプライバシ。このフラグは、デフォルトでプライベートに設定されていますが、変更できます。

JEBバックエンド

常にパブリックです。ユーザー・データを含みます。

構成ファイル・ハンドラ・バックエンド

常にプライベートです。

バックアップ・バックエンド

常にプライベートです。

スキーマ・バックエンド

常にプライベートです。

タスク・バックエンド

常にプライベートです。

監視バックエンド

常にプライベートです。

Truststoreバックエンド

常にプライベートです。

この項では、dsconfigコマンドを使用したワークフローの構成例について説明します。内容は次のとおりです:

- 第14.1.7.1項「既存ワークフローのリスト」

- 第14.1.7.2項「ワークフロー・プロパティの表示」

- 第14.1.7.3項「ワークフローの作成」

次の各プロシージャで使用するすべてのコマンドで、プロキシ・ホスト名(-h)、プロキシ管理ポート(-p)、バインドDN(-D)およびバインド・パスワード・ファイル(-j)が指定されます。各例では、すべての証明書を信頼するために-Xオプションが使用されます。

14.1.7.1 既存ワークフローのリスト

サーバー・インスタンス上で構成されているすべてのワークフローを表示するには、dsconfig list-workflowsコマンドを使用します。次の例は、プロキシ・サーバー・インスタンス上で構成されているデフォルト・ワークフローを示しています:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
list-workflows

Workflow       : Type    : enabled
---------------:---------:--------
workflow1      : generic : true

14.1.7.2 ワークフロー・プロパティの表示

特定のワークフローのプロパティを表示するには、dsconfig get-workflow-propコマンドを使用します。例:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
get-workflow-prop --workflow-name workflow1

Property         : Value(s)
-----------------:-------------------
base-dn          : "ou=people,o=test"
enabled          : true
workflow-element : load-bal-we1

base-dnは、ワークフローに対して使用されるベースDNを示します。このベースDNは、そのワークフローを使用したデプロイメント用です。workflow-elementプロパティは、リクエストを処理するワークフロー要素を示します。

注意:

base-dnプロパティは読取り専用で、変更できません。

14.1.7.3 ワークフローの作成

各ワークフローは、ワークフロー要素に関連付けられます。ワークフローを作成する際、関連付けるワークフロー要素名(--set workflow-element)を指定する必要があります。つまり、ワークフロー要素が先に作成されている必要があります。第14.1.8項「dsconfigを使用したワークフロー要素の構成」を参照してください。

ワークフローを作成するには、dsconfig create-workflowコマンドを使用します。例:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
create-workflow \
--workflow-name workflow1 \
--set base-dn:ou=people,o=test \
--set enabled:true \
--set workflow-element:load-bal-we1

14.1.8 dsconfigを使用したワークフロー要素の構成

ワークフロー要素は、ルーティング構造の一部で、ワークフローにリンクされます。ディレクトリ・サーバー・インスタンスの場合、DBローカル・ワークフロー要素は物理データベースに関連付けられます。

構成可能なワークフロー要素のすべてのタイプおよびその用途については、第4.1.3項「ワークフロー要素」を参照してください。

プロキシ・デプロイメントには、LDAPプロキシ・ワークフロー要素およびロード・バランシング・ワークフロー要素または分散ワークフロー要素が含まれている必要があります。

この項では、dsconfigコマンドを使用したワークフロー要素の構成方法について説明します。内容は次のとおりです:

- 第14.1.8.1項「ワークフロー要素のリスト」

- 14.1.8.2項「ワークフロー要素の作成」

- 14.1.8.3項「ワークフロー要素の変更」

次の手順内のコマンドではすべて、ホスト名(-h)、管理ポート(-p)、バインドDN (-D)およびバインド・パスワード・ファイル(-j)が指定されます。各例では、すべての証明書を信頼するために-Xオプションが使用されます。

14.1.8.1 ワークフロー要素のリスト

構成されているすべてのワークフロー要素を表示するには、dsconfig list-workflow-elementsコマンドを使用します。

次の例は、ディレクトリ・サーバー・インスタンスに対するデフォルト・ワークフロー要素を示しています。

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
list-workflow-elements

Workflow Element : Type               : enabled
-----------------:--------------------:--------
adminRoot        : ldif-local-backend : true
userRoot         : db-local-backend   : true
virtualAcis      : db-local-backend   : true

次の例では、ロード・バランシング用にデプロイされるプロキシ・サーバー・インスタンスのデフォルト・ワークフロー要素を示します:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
list-workflow-elements

Workflow Element : Type               : enabled
-----------------:--------------------:--------
adminRoot        : ldif-local-backend : true
load-bal-we1     : load-balancing     : true
proxy-we1        : proxy-ldap         : true
proxy-we2        : proxy-ldap         : true

14.1.8.2 ワークフロー要素の作成

対話型モードでワークフロー要素を作成するには、dsconfig create-workflow-elementコマンドを使用します。セットアップ時にプロキシ・インスタンスを構成している場合には、必要なワークフロー要素はすでに作成されています。

次のタイプのワークフロー要素を作成できます:

- DBローカル・バックエンド。詳細は、第14.1.8.2.1項「DBローカル・バックエンド・ワークフロー要素の作成」を参照してください。

- プロキシLDAP。詳細は、第15.1.1.3.3項「プロキシLDAPワークフロー要素を作成するには」を参照してください。

- ロード・バランシング。詳細は、第15.1.3.2項「ロード・バランシング・ワークフロー要素の作成」を参照してください。

- 分散。詳細は、第15.1.4.2項「分散ワークフロー要素の作成」を参照してください。

- DNリネーム。詳細は、第15.1.5項「dsconfigを使用したDNリネームの構成」を参照してください。

- Kerberos認証。詳細は、第20.8.4項「dsconfigを使用したKerberosワークフロー要素の作成」を参照してください。

14.1.8.2.1 DBローカル・バックエンド・ワークフロー要素の作成

ローカル・バックエンド・ワークフロー要素は、ディレクトリ・サーバー・インスタンス内のバックエンドへのアクセスを提供します。新しいローカル・バックエンド・ワークフロー要素を作成するには、dsconfig create-workflow-elementコマンドを使用して、ワークフロー要素を介してアクセスする1つ以上のベースDNを指定します。

単一のバックエンドは、1つ以上のベースDNを処理できます。複数のバックエンドが同じベースDNを持つことはできませんが、1つのバックエンドが別のバックエンドによって提供されるベースDN以下のベースDNを持つことは可能です。ベースDNが別のバックエンドのベースDNに従属する場合、そのバックエンドのすべてのベースDNがその同じDNに従属する必要があります。

次の例では、ou=admins,dc=example,dc=comのベースDNにアクセスするローカル・バックエンド・ワークフロー要素を作成および有効化しています。

$ dsconfig create-workflow-element -h localhost -p 4444 -D "cn=directory manager"\
-j pwd-file -X -n --element-name admins --type db-local-backend \
--set base-dn:ou=admins,dc=example,dc=com --set enabled:true

14.1.8.3 ワークフロー要素の変更

ワークフロー要素を作成した後、dsconfig set-workflow-element-propコマンドを使用してそのプロパティを変更できます。

14.1.9 dsconfigを使用したプラグインの構成

プラグインは、操作の実行中、またはディレクトリ・サーバー内部のその他の定義済ポイントに、カスタム・ロジックを提供します。dsconfigコマンドは、ディレクトリ・サーバー構成の管理に使用します。dsconfigの使用法の詳細は、第14.1項「dsconfigを使用したサーバー構成の管理」を参照してください。この項の内容は次のとおりです:

- 第14.1.9.1項「プラグイン・タイプの概要」

- 第14.1.9.2項「プラグイン構成の変更」

14.1.9.1 プラグイン・タイプの概要

dsconfig plugin-typeプロパティを使用して、サーバーによってサポートされる数多くのプラグイン・タイプを1つ以上使用するようにプラグインを構成できます。既存のプラグインの構成に新しいデフォルト・プラグイン・タイプを追加することはできません。プラグインの構成から1つ以上のデフォルト・プラグイン・タイプを削除することはできますが、その場合には注意が必要です。通常、プラグインは、なんらかの理由があってデフォルト・プラグイン・タイプをサポートするように設計されています。1つ以上のプラグイン・タイプの削除により、ディレクトリ・サーバーの操作が不安定になる可能性があります。

大部分のプラグインが複数のタイプをサポートし、複数のプラグインが同じプラグイン・タイプで定義されることもあります。処理中におけるこれらのプラグインの起動順序は未定義です。特定の順序で起動する必要がある場合(たとえば、別のプラグインの結果に依存するプラグインがある場合)、プラグインが起動する順序を指定できます。詳細は、第14.1.9.2.5項「プラグインの起動順序を構成するには」を参照してください。

14.1.9.2 プラグイン構成の変更

次の項では、dsconfigを使用したプラグイン構成の管理例を紹介します。dsconfigは、管理コネクタを使用して、サーバーにアクセスします。この項の例ではすべて、管理コネクタはデフォルト・ポート(4444)をリスニングし、ローカル・ホストを実行するサーバーにアクセスすることが前提になっています。そうでない場合は、--portオプションと--hostnameオプションを指定する必要があります。

dsconfigコマンドは、常に、証明書認証を行う保護された接続で、サーバーにアクセスします。dsconfigを対話型モードで実行する場合、証明書の信頼方法について尋ねるメッセージが表示されます。dsconfigを非対話型モード(-nオプション)で実行する場合、-Xオプションまたは--trustAllオプションを指定する必要があります。そうでない場合、コマンドは失敗します。

この項では、プラグイン構成の管理例を紹介します。内容は次のとおりです:

- 第14.1.9.2.1項「プラグインのリストを表示するには」

- 第14.1.9.2.2項「新しいプラグインを作成するには」

- 第14.1.9.2.3項「プラグインを有効または無効にするには」

- 第14.1.9.2.4項「プラグイン・プロパティを表示および構成するには」

- 第14.1.9.2.5項「プラグインの起動順序を構成するには」

14.1.9.2.1 プラグインのリストを表示するには

この例では、現在サポートされているプラグインで構成されたディレクトリ・サーバーを示しています。これらのプラグインおよびその目的については、Oracle Unified Directory構成リファレンスのプラグイン構成に関する項を参照してください。

dsconfigを使用して、現在構成されているプラグインのリストを表示できます。

$ dsconfig -h localhost -p 4444 -D cn="Directory Manager" -j pwd-file -X -n \
list-plugins

インストールに応じて、出力は次のものに類似したものになります。

Plugin                          : Type                            : enabled
--------------------------------:---------------------------------:--------
7-Bit Clean                     : seven-bit-clean                 : false
Change Number Control           : change-number-control           : true
Entry UUID                      : entry-uuid                      : true
LastMod                         : last-mod                        : true
LDAP Attribute Description List : ldap-attribute-description-list : true
Password Policy Import          : password-policy-import          : true
Profiler                        : profiler                        : true
Referential Integrity           : referential-integrity           : false
Replication LDIF Import         : replication-ldif-import         : true
UID Unique Attribute            : unique-attribute                : false

コマンドの出力により次の情報が示されます(左から右へ):

- プラグイン。プラグインの名前。通常、プラグインの実行内容がわかる名前になっています。

- タイプ: プラグインのタイプ。同じタイプのプラグインが複数ある場合もあります。

- 有効。プラグインは有効/無効を設定できます。サーバー構成で無効になっているプラグインは、何も行いません。

14.1.9.2.2 新しいプラグインを作成するには

プラグインを構成する最も簡単な方法は、対話型モードでdsconfigを使用する方法です。対話型モードでは、順を追ってプラグインを構成できるので、ここでの説明は省きます。

この例では、非対話型モードでdsconfigを使用して新しいパスワード・ポリシー・インポート・プラグインを作成し、有効にする方法を示します。

次のように、dsconfigコマンドを実行して、新しいパスワード・ポリシー・インポート・プラグインを作成して有効にします:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
create-plugin --type password-policy-import \
--plugin-name "My Password Policy Import Plugin" --set enabled:true

14.1.9.2.3 プラグインを有効または無効にするには

enabledプロパティをtrueまたはfalseに設定することにより、プラグインを有効または無効にできます。この例では、前の例で作成したパスワード・ポリシー・インポート・プラグインを無効にします。

次のように、dsconfigコマンドを実行して、新しいパスワード・ポリシー・インポート・プラグインを無効にします。

$ dsconfig -h localhost -p 4444 -D cn="Directory Manager" -j pwd-file -X -n \
set-plugin-prop --plugin-name "My Password Policy Import Plugin" \
--set enabled:false

14.1.9.2.4 プラグイン・プロパティを表示および構成するには

プラグインのプロパティを表示するには、get-plugin-propサブコマンドを使用します。プラグインのプロパティを変更するには、set-plugin-propサブコマンドを使用します。この例では、前の例で作成したプラグインのプロパティを表示し、プラグインを有効にして、デフォルトの認証パスワード格納スキームをSalted SHA-512に設定します。

1. プラグイン・プロパティを表示します。

$ dsconfig -h localhost -p 4444 -D cn="Directory Manager" -j pwd-file -X -n \
get-plugin-prop --plugin-name "My Password Policy Import Plugin"

インストールに応じて、出力は次のものに類似したものになります。

Property                             : Value(s)
-------------------------------------:---------
default-auth-password-storage-scheme : -
default-user-password-storage-scheme : -
enabled                              : false

2. プラグインを有効にして、デフォルトの認証パスワード格納スキームをSalted SHA-512に設定します。

$ dsconfig -h localhost -p 4444 -D cn="Directory Manager" -j pwd-file -X -n \
set-plugin-prop --plugin-name "My Password Policy Import Plugin" \
--set enabled:true\
--set default-auth-password-storage-scheme:"Salted SHA-512"

3. プラグイン・プロパティをもう一度表示して、変更を確認します。

$ dsconfig -h localhost -p 4444 -D cn="Directory Manager" -j pwd-file -X -n \
get-plugin-prop --plugin-name "My Password Policy Import Plugin"

Property                             : Value(s)
-------------------------------------:---------------
default-auth-password-storage-scheme : Salted SHA-512
default-user-password-storage-scheme : -
enabled                              : true

14.1.9.2.5 プラグインの起動順序を構成するには

デフォルトでは、プラグインの起動順序は未定義です。set-plugin-root-prop --set plugin-type:valueサブコマンドを使用して、プラグインが特定の順序で起動するように指定できます。ここでのvalueは、コンマで区切ったプラグイン名のリストで表されたプラグインの順序になります。プラグイン順序文字列には、単一のアスタリスク要素を含めることができます。これは、明示的に名前が付けられていないプラグインを示すワイルドカードになります。

この例では、事前操作追加プラグインの前にEntry UUIDプラグインを起動することを指定しています。

1. 現在のプラグイン起動順序を表示します。

$ dsconfig -h localhost -p 4444 -D cn="Directory Manager" -j pwd-file -X -n \
get-plugin-root-prop

Property                                    : Value(s)
--------------------------------------------:---------
plugin-order-intermediate-response          : -
plugin-order-ldif-export                    : -
plugin-order-ldif-import                    : -
plugin-order-post-connect                   : -
...

2. プラグインの順序を設定します。

$ dsconfig -h localhost -p 4444 -D cn="Directory Manager" -j pwd-file -X -n \
set-plugin-root-prop --set plugin-order-pre-operation-add:"Entry UUID,*"

注意:

プラグイン順序値は検証されません。定義済プラグインと一致しない値は無視されます。

14.1.10 dsconfigを使用した接尾辞の構成

Oracle Unified Directoryでは、セットアップ時またはその後に、複数の接尾辞を構成できます。

この項には次のトピックが含まれます:

- 第14.1.10.1項「セットアップ時でのdsconfigを使用した接尾辞の構成」

- 第14.1.10.2項「実行中のサーバー上でのdsconfigを使用した接尾辞の構成」

dsconfigの非対話型モードで、次の項で説明する構成を行うこともできます。

14.1.10.1 セットアップ時でのdsconfigを使用した接尾辞の構成

ベース・エントリを作成することにより、セットアップ時にdsconfigコマンドを使用して接尾辞を構成できます。

次のいずれかの手順でベース・エントリdc=example,dc=com;dc=other,dc=com;dc=test,dc=comを作成します。

- 次のコマンドを使用してベース・エントリを作成します:

oud-setup --cli --baseDN dc=example,dc=com --baseDN dc=test,dc=com --baseDN \
dc=other,dc=com --addBaseEntry --ldapPort 2389 --adminConnectorPort 24444 \
--rootUserDN cn=Directory Manager --rootUserPassword password --no-prompt \
--noPropertiesFile

- 次のコマンドを使用してサンプル・データでベース・エントリを作成します:

oud-setup --cli --baseDN dc=example,dc=com --baseDN dc=test,dc=com --baseDN \
dc=other,dc=com --sampleData 15 --ldapPort 2389 --adminConnectorPort 24444 \
--rootUserDN cn=Directory Manager --rootUserPassword password --no-prompt \
--noPropertiesFile

追加構成なしで、すべての接尾辞の下にあるデータにアクセスできるようになりました。

14.1.10.2 実行中のサーバー上でのdsconfigを使用した接尾辞の構成

dsconfigコマンドまたはODSMのいずれかを使用して、実行中のサーバー・インスタンス上で接尾辞を構成できます。ODSMを使用した接尾辞の構成の詳細は、第14.2.3.1項「接尾辞の作成」を参照してください。

次の手順でdsconfigコマンドを使用して接尾辞を構成します:

1. ローカル・バックエンド・ワークフロー要素にベースDNを追加します。

dsconfig set-workflow-element-prop \
--element-name userRoot \
--add base-dn:dc=example2,dc=com \
--hostname localhost \
--port 24444 \
--trustAll \
--bindDN cn=directory manager \
--bindPassword ****** \
--no-prompt

2. 新しいベースDNのワークフローを作成します。

dsconfig create-workflow \
--set base-dn:dc=example2,dc=com \
--set enabled:true \
--set workflow-element:userRoot \
--type generic \
--workflow-name dc=example2,dc=com \
--hostname localhost \
--port 24444 \
--trustAll \
--bindDN cn=directory manager \
--bindPassword ****** \
--no-prompt

3. 新しいワークフローをネットワーク・グループに追加します。

dsconfig set-network-group-prop \
--group-name network-group \
--add workflow:dc=example2,dc=com \
--hostname localhost \
--port 24444 \
--trustAll \
--bindDN cn=directory manager \
--bindPassword ****** \
--no-prompt

4. ベース・エントリdc=example2,dc=comを作成します。

5. 必要なエントリで新しい接尾辞を移入します。

14.2 Oracle Directory Services Managerを使用したサーバー構成の管理

ODSM上の各サーバー・インスタンスの「構成」タブから、サーバー構成要素を変更できます。プロキシ・サーバー・インスタンス固有の構成管理の詳細は、第15.2項「ODSMを使用したプロキシ構成の管理」を参照してください。

この項では、ODSMの「構成」タブで実行できるタスクの概要について説明します。内容は次のとおりです:

- 第14.2.1項「構成ビューの選択」

- 第14.2.2項「ODSMを使用してオブジェクトを構成するためのショートカット」

- 第14.2.3項「ODSMを使用した接尾辞の構成」

- 第14.2.5項「ODSMを使用したワークフローの構成」

- 第14.2.4項「ODSMを使用したワークフロー要素の構成」

- 第14.2.6項「ODSMを使用した接続ハンドラの構成」

- 第14.2.7項「ODSMを使用したネットワーク・グループの構成」

- 第14.2.8項「一般的なサーバー構成の変更」

14.2.1 構成ビューの選択

「構成」タブにサーバー構成に関する2つの別個のビューが表示されます:

- ネーミング・コンテキスト。これはデフォルトのビューです。そのサーバー・インスタンスに構成された命名コンテキストまたは接尾辞に関するサーバー構成が表示されます。

- コア構成。このビューには、そのサーバー・インスタンスに構成されたワークフロー、ワークフロー要素およびサーバー拡張に関するサーバー構成が表示されます。

選択する構成ビューにより、「作成」メニューで使用可能な項目が決まります。

14.2.2 ODSMを使用してオブジェクトを構成するためのショートカット

ODSMを使用してサーバー・コンポーネントを作成する際、「類似作成」を使用して既存のコンポーネントを複製できます。「構成」タブでコンポーネントを選択して、「類似作成」をクリックすると、同じ構成の新しいコンポーネントが作成されます。その後、必要に応じて、新しいコンポーネントのプロパティを編集できます。

「作成」を使用して、選択したコンポーネントと同じタイプのコンポーネントを作成することもできます。たとえば、左側のメニューからLDAP接続ハンドラを選択し、「作成」をクリックすると、新しい未構成のLDAP接続ハンドラが作成されます。

左側のメニュー内のコンポーネントを右クリックすると、そのコンポーネントに関連するアクション・リストが表示されます。たとえば、LDAP接続ハンドラを右クリックして表示されるドロップダウン・メニューから、新しいLDAP接続ハンドラを作成したり、そのLDAP接続ハンドラを複製したり、接続ハンドラを削除することができます。

14.2.3 ODSMを使用した接尾辞の構成

次の項では、ODSMを使用した接尾辞またはネーミング・コンテキストの構成方法について説明します。dsconfigを使用した接尾辞の構成については、第14.1.10項「dsconfigを使用した接尾辞の構成」を参照してください。

14.2.3.1 接尾辞の作成

Oracle Unified Directoryでは、次のようにODSMインタフェースを使用して1つ以上の接尾辞を構成できます:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「構成」タブを選択します。

3. 「ネーミング・コンテキスト」ビューを選択します。

4. 「作成」メニューから「ローカル・ネーミング・コンテキスト」を選択します。

5. 「ネーミング・コンテキスト」領域で、次の手順に従います:

1. 「ベースDN」フィールドに、作成する接尾辞の名前を入力します。

2. 「ディレクトリ・データ・オプション」グループから、接尾辞へのデータの移入オプションとして次のいずれかを選択します:

「ベース・エントリの作成のみ」では、接尾辞のベース・エントリとともにデータベースが作成されます。その他のエントリは、接尾辞の作成後に追加する必要があります。

「データベースを空のままにする」では、空のデータベースが作成されます。ベース・エントリおよびその他のエントリは、接尾辞の作成後に追加する必要があります。

「生成されたサンプル・データのインポート」を選択すると、接尾辞にサンプル・エントリが移入されます。

「ユーザー・エントリ数」フィールドに、生成するエントリ数を指定します。ODSMを使用してインポートできるサンプル・エントリ数は、最大30,000です。30,000を超える数のエントリを追加する場合は、import-ldifコマンドを使用する必要があります。

6. 「Oracleコンポーネント統合」領域で、次のいずれかのオプションを選択して、新しい接尾辞を有効にします:

- 特定の統合なし: ネーミング・コンテキストとOracleコンポーネントを統合する必要がない場合に、このオプションを選択します。

- エンタープライズ・ユーザー・セキュリティ(EUS)に使用可能:
EUSに対して接尾辞を有効にするには、管理リスナーに加えて、少なくとも1つのLDAPリスナーがSSL対応になっている必要があります。接尾辞として、少なくとも1つのエントリが含まれている必要があります(つまり、前の手順で「データベースを空のままにする」を選択することはできません)。

EUSを選択すると、この接尾辞が作成されるほかに、2つの接尾辞"cn=oracleschemaversion"と"cn=oraclecontext"が自動的に作成されます。また、EUSワークフロー要素がローカルのバックエンド・ワークフロー要素の前に追加されます。さらに、"cn=schema"のDNリネーム・ワークフロー要素が追加され、"cn=subschemasubentry" DNを使用してこの要素にアクセスできるようになります。

- Oracle Database Net Servicesに使用可能: ネーミング・コンテキストにデータベース接続識別子を格納する場合、このオプションを選択します。

7. 「ネットワーク・グループ」リージョンで、次の手順に従って1つ以上のネットワーク・グループに接尾辞をアタッチします:

- 接尾辞を既存のネットワーク・グループにアタッチする場合は、「既存のものを使用」を選択し、必要なネットワーク・グループをリストから選択します。

- 新しいネットワーク・グループに接尾辞をアタッチするには、「新規作成」を選択して、「名前」フィールドに、作成するネットワーク・グループの名前を入力します。

同じ接尾辞を複数のネットワーク・グループにアタッチできます。

8. 「ワークフロー要素」リージョンで、次のいずれかの手順に従ってワークフロー要素に接尾辞をアタッチします:

- 接尾辞を既存のワークフロー要素にアタッチする場合は、「既存のものを使用」を選択し、必要なワークフロー要素をリストから選択します。

- 接尾辞を新しいワークフロー要素にアタッチする場合は、「新規作成」を選択し、作成するワークフロー要素名を「名前」フィールドに入力します。ローカルDBワークフロー要素またはローカルLDIFワークフロー要素を作成できます。

9. 「作成」をクリックします。
次の確認メッセージが表示されます:

構成が正常に作成されました。

ローカル・バックエンド・ワークフロー要素構成で、接尾辞を作成した後、ツームストン・エントリのパージ間隔とツームストン・エントリ期間を構成できます。

14.2.3.2 接尾辞プロパティの表示と編集

「構成」タブの「ネーミング・コンテキスト」ビューには、サーバー上に構成されているすべての接尾辞が表示されます。

構成済接尾辞のプロパティを表示するには、次の手順に従います:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「構成」タブを選択します。

3. 「ネーミング・コンテキスト」ビューを選択します。

4. 「ネーミング・コンテキスト」要素を開きます。

5. 表示するプロパティの接尾辞をクリックします。
接尾辞プロパティが右側のペインに表示されます。

6. 必要に応じて、接尾辞構成に変更を加えます。
この接尾辞をアタッチするネットワーク・グループを変更したり、エンタープライズ・ユーザー・セキュリティ(EUS)またはOracle Database Net Servicesに対して接尾辞を有効にできます。

注意:

「エンタープライズ・ユーザー・セキュリティ(EUS)に使用可能」オプションまたは「Oracle Database Net Servicesに使用可能」オプションに対して「Oracleコンポーネント統合」オプションを構成し、「Oracleコンポーネント統合」領域で変更を行っている場合、「構成必須」ダイアログ・ボックスが表示されます。選択するオプションに応じて、次のいずれかを選択します:

- Oracleコンテキストの保持: EUSおよびOracle Database Net Serviceのネーミング・コンテキストを保持する必要がある場合は、このオプションを選択します。

- Oracleコンテキストの削除: EUSおよびOracle Database Net Serviceのネーミング・コンテキストを削除する必要がある場合は、このオプションを選択します。

「適用」をクリックして、変更を保存します。

14.2.3.3 接尾辞の削除

「構成」タブの「ネーミング・コンテキスト」ビューには、サーバー上に構成されているすべての接尾辞が表示されます。

接尾辞を削除するには、次の手順に従います:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「構成」タブを選択します。

3. 「ネーミング・コンテキスト」ビューを選択します。

4. 「ネーミング・コンテキスト」要素を開きます。

5. 削除する必要がある接尾辞を選択します。

6. 「構成の削除」をクリックします。

14.2.4 ODSMを使用したワークフロー要素の構成

ワークフロー要素は、ワークフロー・プロセスの重要なビルディング・ブロックです。ワークフロー要素は、サーバーに送信されるクライアント・リクエストの処理方法を定義します。プロキシ・サーバーを含むデプロイメントでは、ワークフロー要素はロード・バランシングまたは分散用として構成されます。プロキシ・サーバーが含まれないデプロイメントでは、ワークフロー要素は各バックエンドに対して直接構成されます。

次の項では、ODSMを使用してワークフロー要素を構成する方法について説明します。dsconfigを使用したワークフロー要素の構成については、第14.1.8項「dsconfigを使用したワークフロー要素の構成」を参照してください。

14.2.4.1 ワークフロー要素の作成

ODSMを使用してワークフロー要素を作成するには、次の手順に従います:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「構成」タブを選択します。

3. 「コア構成」ビューを選択します。
詳細は、第14.2.1項「構成ビューの選択」を参照してください。

4. 「作成」メニューで「ワークフロー要素」を選択し、作成するワークフロー要素のタイプを選択します。
様々なワークフロー要素タイプの詳細は、第4.1.3項「ワークフロー要素」を参照してください。

5. 構成する必要があるワークフロー要素のプロパティは、作成するワークフロー要素のタイプによって異なります。
すべてのワークフロー要素で、次の基本プロパティを構成する必要があります:

名前: ワークフロー要素の名前を入力します。

有効。ワークフロー要素を作成すると、デフォルトではそのワークフロー要素は有効になります。ワークフロー要素を無効にするには、この項目をクリアします。

加えて、対応する各ワークフロー要素タイプに対して次のプロパティを構成する必要があります:

- DNリネーム・ワークフロー要素

- クライアント・ベースDN: クライアント・アプリケーションによって使用されるベースDNを指定します。

- ソース・ベースDN: LDAPサーバーに格納されるベースDNを指定します。

- 次のワークフロー要素: ワークフロー内で次に位置するワークフロー要素を選択します。

- 属性ホワイト・リスト: 「追加」をクリックして、DNが含まれている、リネーム操作によって転送する必要がある属性リストを選択します。

- 属性ブラック・リスト: 「追加」をクリックして、DNが含まれているが、リネーム操作によって転送しない属性リストを選択します。

- EUSワークフロー要素

- EUSレルム: EUSワークフロー要素が適用されるDITの部分を入力します。

- 次のワークフロー要素: ワークフロー内で次に位置するワークフロー要素を選択します。

- サーバー・タイプ: EUSユーザー・エントリを格納するサーバーを選択します。

- パスワード属性: EUSユーザー・パスワードを格納する属性タイプを入力します。

- EUSコンテキスト・ワークフロー要素

- EUSコンテキスト: Oracleコンテキストを含むDNを入力します。Oracleコンテキストは、最上位ディレクトリ・エントリで、ディレクトリを使用するインストール済のOracle製品によって使用されるデータが含まれます。

- EUS管理者: 管理ユーザーのDNを入力します。このユーザーは、Oracleコンテキストで作成されたグループのuniquememberになります。

- 次のワークフロー要素: ワークフロー内で次に位置するワークフロー要素を選択します。

- Kerberos認証プロバイダ・ワークフロー要素

- レルム: Kerberos認証で使用するレルムを指定します。レルムを指定しない場合、サーバーが基のシステム構成からレルムを決定しようとします。

- プリンシパル名属性: 「選択」をクリックして、プリンシパル名属性を指定します。

- KDCアドレス: キー配布センター(KDC)サーバー・アドレスを指定します。

- ローカルDBワークフロー要素

- 書込み可能性モード: このワークフロー要素に関連付けられているバックエンドが書込み操作を処理するかどうかを指定します。

- ベースDN: バックエンドによって処理されるデータに対して1つ以上のベースDNを指定します。

- データベース・プロパティ: データベースのプロパティを指定します。これらのプロパティのリストと、その値の詳細は、Oracle Unified Directory構成リファレンスのDBローカル・バックエンド・ワークフロー要素に関する項を参照してください。

- ツームストン構成: データベースに対してツームストン・エントリを処理する方法を指定します。これらのプロパティのリストと、その値の詳細は、Oracle Unified Directory構成リファレンスのDBローカル・バックエンド・ワークフロー要素に関する項を参照してください。

- 索引プロパティ: 次のパラメータを指定します:
サブツリーの索引付け: このチェック・ボックスを選択または選択解除して、各親エントリの直接または間接子エントリについての情報を含むサブツリー固有データを保持するように、バックエンドがサブツリーの索引付けを行うかどうかを指定します。

ローカル・データベース索引: データベースに対してローカル・データベース索引構成を指定します。これらのプロパティのリストと、その値の詳細は、Oracle Unified Directory構成リファレンスのDBローカル・バックエンド・ワークフロー要素に関する項を参照してください。

ローカル・データベースVLV索引: データベースに対してローカル・データベースVLV索引構成を指定します。これらのプロパティのリストと、その値の詳細は、Oracle Unified Directory構成リファレンスのDBローカル・バックエンド・ワークフロー要素に関する項を参照してください。

- ローカルLDIFワークフロー要素

- 書込み可能性モード: このワークフロー要素に関連付けられているバックエンドが書込み操作を処理するかどうかを指定します。

- ベースDN: バックエンドによって処理されるデータに対して1つ以上のベースDNを指定します。

- プライベート・バックエンド: バックエンドをプライベート・バックエンドと見なすかどうかを指定します。これにより、ユーザー定義情報ではなく操作データの格納に使用するかどうかが示されます。

- LDIFファイル: このバックエンドのデータを含むLDIFファイルのパスを入力します。

- パス・スルー認証ワークフロー要素

- ユーザー・プロバイダ・ワークフロー要素: リクエストされたユーザー・エントリを提供するワークフロー要素を選択します。

- 認証プロバイダ・ワークフロー要素: ユーザー・エントリの認証サービスを提供するワークフロー要素を選択します。たとえば、Kerberos認証プロバイダ・ワークフロー要素またはローカル・データベース・ワークフロー要素を認証プロバイダとして使用できます。

- ローカル・メモリー・ワークフロー要素

- ベースDN: バックエンドによって処理されるデータに対して1つ以上のベースDNを指定します。

- RDN変更ワークフロー要素

- 次のワークフロー要素: ワークフロー内で次に位置するワークフロー要素を選択します。

- オブジェクト・クラス: RDN変更操作のオブジェクト・クラス・タイプを選択します。

- ソースRDN属性: Oracle Unified Directoryで置換またはリネームを行うソース・ディレクトリの元のRDN属性名を選択します。

- クライアントRDN属性: Oracle Unified Directoryで使用する新しいRDN属性名を選択します。

- RDN値の置換: 元のRDN値を新しいRDN値で置換するかどうかを指定します。これはデフォルトで有効になっています。

- DN属性: 「追加」をクリックして、RDNリネームを実行するDNの属性リストを選択します。

- 変換ワークフロー要素

- 次のワークフロー要素: ワークフロー内で次に位置するワークフロー要素を選択します。

- エントリ一致フィルタ: これはLDAPフィルタです。このオプションを選択すると、エントリはこのLDAPフィルタと一致する場合のみ変換されるようになります。

- エントリ親接尾辞: これは省略可能です。接尾辞のリストを指定することにより、変換の適用を特定のサブツリー下のエントリに制限できます。このオプション指定すると、エントリは、これらの接尾辞のルートであるサブツリー内にある場合のみ指定されます。

- 除外操作: このオプションを指定すると、指定操作中にはエントリの変換が行われません。

- 変換: 変換ワークフロー要素が処理する変換のリスト。この変換リストの順序は、実行時リクエスト処理中に変換が実際に適用される順番を保証するものではありません。

6. 「作成」をクリックします。
次の確認メッセージが表示されます:

Workflow Element created successfully.

14.2.4.2 ワークフロー要素のプロパティの表示と編集

既存のワークフロー要素のプロパティを表示または変更するには、次の手順に従います:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「構成」タブを選択します。

3. 「コア構成」ビューを選択します。
詳細は、第14.2.1項「構成ビューの選択」を参照してください。

4. 「コア構成」要素を開きます。

5. 「ワークフロー要素」要素を開きます。

6. 表示または変更する必要のあるワークフロー要素をクリックします。
ワークフロー要素のプロパティが右側のペインに表示されます。

7. 編集できるプロパティは、構成されているワークフロー要素のタイプによって異なります。

8. 「適用」をクリックして、変更を保存します。

14.2.4.3 ワークフロー要素の削除

既存のワークフロー要素を削除するには、次の手順に従います:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「構成」タブを選択します。

3. 「コア構成」ビューを選択します。
詳細は、第14.2.1項「構成ビューの選択」を参照してください。

4. 「コア構成」要素を開きます。

5. 「ワークフロー要素」要素を開きます。

6. 削除する必要のあるワークフロー要素をクリックし、「構成の削除」をクリックします。

7. 「OK」をクリックして、削除を確定します。

14.2.5 ODSMを使用したワークフローの構成

ワークフローは、ネーミング・コンテキストまたは接尾辞、およびOracle Unified Directoryが着信リクエストを処理する方法を定義するワークフロー要素によって定義されます。ワークフローは、少なくとも1つのネットワーク・グループに登録される必要がありますが、複数のネットワーク・グループにアタッチできます。

ワークフロー、ワークフロー要素およびOracle Unified Directoryのその他のコンポーネントの詳細は、第4.1項「Oracle Unified Directoryのコンポーネント」を参照してください。

次の項では、ODSMを使用してワークフローを構成する方法について説明します。dsconfigを使用したワークフローの構成については、第14.1.7項「dsconfigを使用したワークフローの構成」を参照してください。

14.2.5.1 ワークフローの作成

ODSMを使用してワークフローを作成するには、次の手順に従います:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「構成」タブを選択します。

3. 「コア構成」ビューを選択します。
詳細は、第14.2.1項「構成ビューの選択」を参照してください。

4. 「作成」メニューから「ワークフロー」を選択します。

5. 「ワークフロー・プロパティ」領域で、次の手順に従います:

1. 「名前」フィールドに、作成するワークフローの名前を入力します。

2. このワークフローを有効にする場合は、「有効」チェック・ボックスを選択します。
この段階でワークフローを有効にしない場合は、このチェック・ボックスを選択解除します。

6. 「ベースDN」フィールドに、このワークフローからアクセスできるネーミング・コンテキストを入力します。

7. このワークフローに関連付けるワークフロー要素を選択します。
ワークフロー要素は、ワークフローを作成する前にすでに存在している必要があります。

8. このワークフローが、複数のワークフローを含む検索操作の失敗の原因となるクリティカルなワークフローであるのかどうか、およびこのワークフロー上で操作を失敗させるかどうかに応じて、「True」、「False」または「部分的」を選択します。

9. 「作成」をクリックします。
次の確認メッセージが表示されます:

Workflow created successfully.

14.2.5.2 ワークフロー・プロパティの表示と編集

「構成」タブの「コア構成」ビューに、サーバー上に構成されているすべてのワークフローとワークフロー要素が表示されます。

構成済ワークフローのプロパティを表示するには、次の手順に従います:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「構成」タブを選択します。

3. 「コア構成」ビューを選択します。
詳細は、第14.2.1項「構成ビューの選択」を参照してください。

4. 「ワークフロー」要素を開きます。

5. プロパティを表示するワークフローをクリックします。
ワークフロー・プロパティが右側のペインに表示されます。

6. 必要に応じて、接尾辞構成に変更を加えます。
ワークフローを無効にしたり、このワークフローに関連付けられているワークフロー要素を変更したりできます。

「適用」をクリックして、変更を保存します。

14.2.5.3 ワークフローの削除

ワークフローは、どのネットワーク・グループからも参照を受けていない場合のみ、ODSMを使用して削除できます。

ワークフローを削除するには、次の手順に従います:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. ネットワーク・グループから参照されているワークフローの場合、ネットワーク・グループのプロパティを変更して、そのワークフローを削除します。
詳細は、第14.2.7.2項「ネットワーク・グループの変更」を参照してください。

3. 「構成」タブを選択します。

4. 「コア構成」ビューを選択します。
詳細は、第14.2.1項「構成ビューの選択」を参照してください。

5. 「ワークフロー」要素を開きます。

6. 削除する必要のあるワークフローを選択し、「構成の削除」をクリックします。

7. 「OK」をクリックして、削除を確定します。

14.2.6 ODSMを使用した接続ハンドラの構成

接続ハンドラは、リクエストがサーバーにより確実に処理され、対応する応答がクライアントに適切に送信されるように、クライアントからの接続の許可、クライアントからのリクエストの読取りと解析を行います。接続ハンドラは、クライアントとのすべての通信を管理するため、関連付けられているプロトコルのサポートを実装する必要があります。

次の項では、ODSMを使用して接続ハンドラを構成する方法について説明します。dsconfigを使用した接続ハンドラの構成については、第14.1.5項「dsconfigを使用した接続ハンドラの構成」を参照してください。

14.2.6.1 接続ハンドラの作成

ODSMを使用して接続ハンドラを作成するには、次の手順に従います:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「構成」タブを選択します。

3. 「作成」メニューから「接続ハンドラ」を選択します。

4. 作成する接続ハンドラのタイプを選択します:

- LDAP。この接続ハンドラは、LDAPを使用するクライアントとのやり取りに使用されます。LDAPv3は完全サポート、LDAPv2は部分的にサポートされます。

- LDAPS。この接続ハンドラは、SSL経由でLDAPを使用するクライアントとのやり取りに使用されます。

- LDIF。この接続ハンドラは、内部操作によりサーバー内の変更を処理するために使用されます。

- JMX。この接続ハンドラは、Java Management Extensions (JMX)フレームワークとRemote Method Invocation (RMI)プロトコルを使用するクライアントとのやり取りを許可します。

- SNMP。この接続ハンドラは、SNMPリクエストを処理して、MIB 2605により示される監視情報を取得するために使用されます。サポートされているSNMPプロトコルは、SNMP V1、V2cおよびV3です。

5. 右側のペインにプロパティを入力して接続ハンドラを構成します。
構成可能なプロパティは、選択した接続ハンドラのタイプによって異なります。すべての構成可能なプロパティの包括的なリストと使用可能な値については、Oracle Unified Directory構成リファレンスの接続ハンドラの構成に関する項を参照してください。

6. 特定の接続ハンドラ・タイプの必須プロパティを構成している場合は、「作成」をクリックします。
次の確認メッセージが表示されます:

Connection Handler created successfully.

14.2.6.2 接続ハンドラの変更

ODSMを使用して接続ハンドラのプロパティを表示または変更するには、次の手順に従います:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「構成」タブを選択します。

3. 「一般構成」要素を展開します。

4. 「接続ハンドラ」要素を開きます。

5. プロパティを変更する接続ハンドラをクリックします。
プロパティが右側のペインに表示されます。

すべての構成可能なプロパティの包括的なリストと使用可能な値については、Oracle Unified Directory構成リファレンスの接続ハンドラの構成に関する項を参照してください。

6. 必須プロパティを変更して、「適用」をクリックします。

14.2.6.3 接続ハンドラの削除

ODSMを使用して既存の接続ハンドラを削除するには、次の手順に従います:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「構成」タブを選択します。

3. 「一般構成」要素を展開します。

4. 「接続ハンドラ」要素を開きます。

5. 削除する必要のある接続ハンドラをクリックし、「構成の削除」をクリックします。

6. 削除の確認を求められます。「OK」をクリックします。

14.2.7 ODSMを使用したネットワーク・グループの構成

ネットワーク・グループは、Oracle Unified Directoryサーバーにより処理される全クライアント・リクエストのエントリ・ポイントです。ネットワーク・グループのプロパティは、クライアント・リクエストの転送方法を示します。

次の項では、ODSMを使用してネットワーク・グループを構成する方法について説明します。dsconfigを使用したネットワーク・グループの構成については、第14.1.6項「dsconfigを使用したネットワーク・グループの構成」を参照してください。

14.2.7.1 ネットワーク・グループの作成

ODSMを使用してネットワーク・グループを作成するには、次の手順に従います:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「構成」タブを選択します。

3. 「作成」メニューから「ネットワーク・グループ」を選択します。

4. 右側のペインでネットワーク・グループを構成するプロパティを入力します。

- 名前: ネットワーク・グループの名前を入力します。

- 有効。このチェック・ボックスを選択するか、選択解除して、ネットワーク・グループを有効または無効にします。ネットワーク・グループを無効にすると、そのネットワーク・グループによって処理できるクライアント・リクエストはなくなります。構成済ネットワーク・グループのみ無効にすると、クライアント・アプリケーションがバックエンドにアクセスするのを効果的に停止できます。

- 優先度。複数のネットワーク・グループがある場合、このネットワーク・グループの優先度を設定します。クライアント・リクエストは、一番優先度が高く、条件を満たしているネットワーク・グループにより処理されます。ネットワーク・グループの一番高い優先度は0です。

- ワークフロー。「追加」()をクリックし、このネットワーク・グループを介してアクセスできる1つ以上のワークフローを追加します。

- 公開するルートDSE。このネットワーク・グループを公開するルートDSEを選択します。ローカル・サーバーのルートDSE、リモート・サーバーに格納されているルートDSEまたはローカル・ファイルに定義されているルートDSEを公開できます。
「その他」をクリックして、次のいずれかのオプションを選択します:

- LDIFファイルで定義されているルートDSE: ルートDSEを含むLDIFファイルのパスを入力します。サーバーはこのファイルにアクセスできる必要があります。

- リモート・サーバーのルートDSE: 次のパラメータを入力します:
ホスト名: リモート・サーバーのホスト名を入力します。

使用可能なポート: リモート・サーバーのLDAPポート、LDAPSポートまたはLDAPポートとLDAPSポートを入力します。

すべて信頼: リモート・サーバーが提示するすべての証明書を信頼する場合は、このチェック・ボックスを選択します。

信頼マネージャ: サーバーがリクエストを転送するためにリモート・サーバーのLDAPSポートに接続するときに使用する信頼マネージャを選択します。

- セキュリティ必須。クライアントが、このネットワーク・グループにアクセスするためにセキュアな接続を使用することを必要とする場合、このオプションを選択します。デフォルトでは、セキュアな接続は必要とされません。

- 許可された認証方法。クライアントとネットワーク・グループ間で許可される認証方法を指定します。

- 許可されたプロトコル。クライアント接続に対して許可されるプロトコルを指定します。プロトコルを指定しない場合、すべてのプロトコルが許可されます。

- 許可されたバインドDN。「追加」をクリックし、このネットワーク・グループに接続するために許可される1つ以上のバインドDNを追加します。このネットワーク・グループで許可されるバインドDNを削除するには、「削除」()をクリックします。

- 許可されたクライアント。「追加」をクリックし、このネットワーク・グループにアクセスするために許可される1つ以上のクライアントを追加します。クライアントは、IPアドレス、名前またはサブネット・マスクにより表すことができます。許可クライアント・リストが設定されていない場合、拒否クライアント・リストに含まれていなければ、すべてのクライアントが許可されます。

- 拒否されたクライアント。「追加」をクリックし、このネットワーク・グループへのアクセスを禁止する1つ以上のクライアントを追加します。クライアントは、IPアドレス、名前またはサブネット・マスクにより表すことができます。拒否クライアント・リストが設定されていない場合、許可クライアント・リストによる制限がなければ、すべてのクライアントが許可されます。

- QOSポリシー。このネットワーク・グループのサービス品質ポリシーを選択します。詳細は、第14.1.6.3項「ネットワーク・グループのサービス品質ポリシーの作成」を参照してください。

5. ネットワーク・グループの必須プロパティを構成している場合は、「作成」をクリックします。
次の確認メッセージが表示されます:

Network Group created successfully.

14.2.7.2 ネットワーク・グループの変更

ネットワーク・グループのプロパティは次のように無効にしたり変更したりできます:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「構成」タブを選択します。

3. 「一般構成」要素を展開します。

4. 「ネットワーク・グループ」要素を開きます。

5. 変更するプロパティのネットワーク・グループをクリックします。
ネットワーク・グループのプロパティが右側のペインに表示されます。

6. 必須プロパティを変更して、「適用」をクリックします。
構成済の各プロパティの説明は、第14.2.7.1項「ネットワーク・グループの作成」を参照してください。

14.2.7.3 ネットワーク・グループの削除

ODSMを使用してネットワーク・グループを削除するには、次の手順に従います:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「構成」タブを選択します。

3. 「一般構成」要素を展開します。

4. 「ネットワーク・グループ」要素を開きます。

5. 削除する必要のあるネットワーク・グループをクリックし、「構成の削除」をクリックします。

6. 削除の確認を求められます。「OK」をクリックします。

14.2.8 一般的なサーバー構成の変更

一般的なサーバー構成の特定の要素については、ODSMを使用して次のように変更できます:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「構成」タブを選択します。

3. 「コア構成」要素を選択します。
プロパティが右側のペインに表示されます。

4. 次のプロパティを変更できます:

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

- Etime解決

- アイドル時間制限

- 最大許容クライアント接続数

- 認証されたユーザーを保持

- 未認証リクエストの却下

- サイズ制限

- 書込み可能性モード

- ルートDSEプロパティ

- ワーク・キュー・プロパティ

- ワーカー・スレッド数

「適用」をクリックして、変更を保存します。

構成可能なプロパティの包括的なリストと使用可能な値については、Oracle Unified Directory構成リファレンスのグローバル構成に関する項を参照してください。

14.3 サーバーへの管理トラフィックの管理

接続ハンドラは、接続の許可、リクエストの読取りおよび応答の送信を含む、クライアント・アプリケーションとのすべてのやり取りを処理します。Oracle Unified Directoryには、サーバーへの管理トラフィックを管理する特別な接続ハンドラである管理コネクタが含まれています。管理コネクタは、監視を簡素化し、ユーザー・データを操作するコマンドより管理コマンドを優先するように、ユーザー・トラフィックと管理トラフィックを分離します。

この項では、管理トラフィックがどのように処理されるかについて説明します。内容は次のとおりです:

- 第14.3.1項「管理コネクタの概要」

- 第14.3.2項「管理接尾辞へのアクセス」

- 第14.3.3項「管理コネクタの構成」

- 第14.3.4項「管理コネクタのキー・マネージャと信頼マネージャ」

14.3.1 管理コネクタの概要

管理コネクタは、デフォルトでLDAPプロトコルに基づき、SSL経由でLDAPを使用します。管理接尾辞にアクセスするすべてのコマンドライン・ユーティリティは管理コネクタを使用します。次のコマンドが含まれています:

- backup

- dsconfig

- dsreplication

- export-ldif

- import-ldif

- manage-account

- manage-tasks

- restore

- status

- stop-ds

- uninstall

管理コネクタは常駐し、常に有効になっています。管理コネクタは無効にしたり、削除できませんが、dsconfigを使用して、次のプロパティを操作できます:

- listen-address。サーバーが管理トラフィックをリスニングするアドレス。

- listen-port。管理コネクタのデフォルト・ポートは4444です。このポートは、必要に応じて、セットアップ時に変更できます。デフォルト・ポートを使用する場合、管理コマンドの実行時にポートを指定する必要はありません(デフォルト・ポートが前提になります)。ポートを変更する場合には、管理コマンドの実行時、新しいポートを指定する必要があります。
同じホストで複数のディレクトリ・サーバー・インスタンスが実行している場合、セットアップ時、複数の管理リスニング・ポートが指定されます。この場合、管理コネクタがデフォルト・リスニング・ポート(4444)を使用しないサーバー・インスタンスでは、管理コマンドの実行時にポートを指定する必要があります。

- セキュリティ関連のプロパティ。管理コネクタを使用するトラフィックは常にセキュリティ保護されます。LDAPS接続ハンドラと同じように、管理コネクタは、セットアップ時、自己署名済の証明書(admin-cert)で構成されます。この自己署名済証明書は、サーバーが最初に起動されるときに生成されます。keytoolなどの外部ツールを使用して、管理コネクタ証明書を管理できます。
管理のセキュリティ関連プロパティには次のようなプロパティがあります:

- ssl-cert-nickname

- ssl-cipher-suite

- key-manager-provider

- trust-manager-provider

管理コマンドの実行時、証明書を信頼する方法が尋ねられます。管理コマンドを非対話型モードで実行する場合、-Xオプションまたは--trustAllオプションを指定して証明書を信頼する必要があります。そうでない場合、コマンドは失敗します。

14.3.2 管理接尾辞へのアクセス

管理接尾辞は次のとおりです:

- cn=config

- cn=monitor

- cn=tasks

- cn=backups

- cn=ads-truststore

- cn=schema

- cn=admin data

一般的には、管理接尾辞に直接LDAPアクセスする(ldap*ユーティリティを使用する)ことはお薦めしません。ただし、cn=monitor接尾辞は例外になります。通常、これらの接尾辞には専用管理コマンドライン・ユーティリティを使用してアクセスすることをお薦めします。

ldap*コマンドを使用して、管理接尾辞にアクセスする場合、管理コネクタ・ポートを使用する必要があります(--useSSLオプションまたは-Zオプションを使用)。管理コネクタを使用すると、データの監視が損なわれず、ユーザー・トラフィックよりもサーバー管理が優先されるようになります。LDAPブラウザを使用して管理接尾辞にアクセスする場合も同様の制限が適用されます。

14.3.3 管理コネクタの構成

この例では、管理コネクタのデフォルト・プロパティを表示し、コネクタのリスニング・ポートを5555に変更します。

1. dsconfigコマンドを使用して、管理コネクタのデフォルト・プロパティを表示します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
get-administration-connector-prop

出力は次のようになります。

Property               : Value(s)
-----------------------:---------------
key-manager-provider   : Administration
listen-address         : 0.0.0.0
listen-port            : 4444
ssl-cert-nickname      : admin-cert
ssl-cipher-suite       : -
trust-manager-provider : Administration

2. dsconfigコマンドを使用して、リスニング・ポートを変更します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
set-administration-connector-prop --set listen-port:5555

注意:

このプロパティの変更を有効にするには、サーバーを再起動する必要があります。

14.3.4 管理コネクタのキー・マネージャと信頼マネージャ

管理コネクタはLDAPSコネクタです。すべてのSSLベース・コネクタと同様、管理コネクタにはキー・マネージャと信頼マネージャが必要です。

Oracle Unified Directoryには、デフォルトで有効になる管理コネクタ専用のキー・マネージャと信頼マネージャが用意されています。デフォルトの管理キー・マネージャと信頼マネージャのプロパティは変更できます。詳細は、第20.2項「キー・マネージャ・プロバイダの構成」および第20.3項「信頼マネージャ・プロバイダの構成」を参照してください。

14.4 タスクとしてのコマンドの構成

特定のコマンドライン・ユーティリティを使用して、ディレクトリ・サーバー上で実行するタスク、およびローカルで実行するタスクをスケジュールできます。スケジュールできるタスクは、タスク・バックエンドと対話するディレクトリ・サーバーへの接続に使用されるオプションをサポートします。

この項には次のトピックが含まれます:

- 第14.4.1項「タスクをスケジュールできるコマンド」

- 第14.4.2項「実行可能タスクの制御」

- 第14.4.3項「タスクのスケジュールと構成」

- 第14.4.4項「スケジュール済タスクの管理と監視」

14.4.1 タスクをスケジュールできるコマンド

次のユーティリティがタスクをスケジュールできます:

- import-ldif

- export-ldif

- backup

- restore

- stop-ds

- stop-ds --restart

- rebuild-index

- dsreplication purge-historical

プロキシ・サーバーに対しては、stop-dsコマンドのみタスクとして実行するようにスケジュールできます。

14.4.2 実行可能タスクの制御

allowed-tasks拡張グローバル構成プロパティを設定することにより、実行できるタスクを制御できます。デフォルトでは、タスク・バックエンドによりサポートされるタスクはすべて許可されます。タスクの実行を禁止するには、この値をallowed-tasksプロパティから削除します。たとえば、サーバーがタスクの使用を停止しないようにするには、次のコマンドを実行します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
set-global-configuration-prop --remove \
allowed-task:org.opends.server.tasks.ShutdownTask

14.4.3 タスクのスケジュールと構成

この項では、タスクのスケジュール方法、タスク通知の構成方法およびタスク依存性の構成方法について説明します。この項のすべての例では、コマンドは、デフォルト管理ポート(4444)とローカル証明書構成を使用してローカル・ホスト上で実行されることが前提になっています。コマンドをリモート実行する場合、証明書パラメータを指定することが必要になることがあります。詳細は、第14.3項「サーバーへの管理トラフィックの管理」を参照してください。

この項では、タスクのスケジュールと構成の手順について説明します。内容は次のとおりです:

- 第14.4.3.1項「タスクのスケジュール」

- 第14.4.3.2項「再帰タスクのスケジュール」

- 第14.4.3.3項「タスク通知の構成」

- 第14.4.3.4項「タスク依存性の構成」

14.4.3.1 タスクのスケジュール

タスクをスケジュールするには、ディレクトリ・サーバーに接続するためのオプション、オプションの開始時刻、およびタスク実行の引数として使用される任意のオプションで必要なユーティリティを起動します。

-tオプションまたは--startオプションが提供されると、タスクのスケジュール直後、ユーティリティは終了します。ただちに実行するようにタスクをスケジュールし、タスクのスケジュール後ただちにユーティリティを終了するには、開始時間の値として0を指定します。

-tまたは--startオプションを省略すると、ユーティリティは、タスクをただちに実行するようにスケジュールし、タスクの進行状況を追跡し、ログ・メッセージを使用できるように出力し、タスクが完了したときに終了します。

export-ldifタスクを、2009年9月24日の12:15に開始するようにスケジュールします。

$ export-ldif -D "cn=directory manager" -j pwd-file \
-l /ldif-files/example.ldif --start 20090924121500 -n userRoot

14.4.3.2 再帰タスクのスケジュール

再帰タスクをスケジュールするには、ディレクトリ・サーバーに接続するためのオプションで、必要なユーティリティを起動します。再帰タスク・スケジュール、およびタスク実行の引数として使用される任意のオプションを指定します。再帰タスクとして次のコマンドをスケジュールできます:

- import-ldif

- export-ldif

- backup

- restore

- rebuild-index

- dsreplication purge-historical

--recurringTaskオプションは、タスク・スケジューラにより使用される再帰タスク・スケジュールを指定して、再帰タスクの実行タイミングと実行頻度を決定します。スケジュールの指定に使用されるパターンはUNIX crontab(5)スケジューリング・パターンとルールに基づき、空白スペースで区切られる次の5つの整数パターン・フィールドを含みます:

- 分 [0,59]

- 時 [0,23]

- 該当月の日 [1,31]

- 該当年の月 [1,12]

- 曜日 [0,6] (0=日曜日)

これらの各パターンは、アスタリスク(全有効値)、要素、またはコンマ区切り要素リストのいずれかになります。要素は、ダッシュで区切る1つまたは2つの数値になります(指定値も含まれます)。

タスク・スケジューラは、指定のスケジュールに従って正規タスク反復を生成します。

--recurringTaskオプションを使用してタスクをスケジュールします。

次のコマンドは、バックアップ・タスクを毎時開始時に実行するようにスケジュールします。

$ backup -D "cn=directory manager" -j pwd-file --recurringTask \
"00 * * * *" --backupDirectory /example/backup --backUpAll --backupID "Hourly Backup"

次の例では、毎週日曜日15分ごとに実行するようにエクスポート・タスクをスケジュールしています。

$ export-ldif -D "cn=directory manager" -j pwd-file --recurringTask \
"0,15,30,45 * * * 0" -l PATH/export-recurring.ldif -n userRoot
Recurring Export task  ExportTask-a614e45d-6ba5-4c29-a8e1-d518c20e46ab scheduled
successfully

14.4.3.3 タスク通知の構成

ユーティリティのタスク・スケジューリング・オプションにより、タスクが完了したとき、またはタスク実行時にエラーが発生したとき、管理者に通知が送信されます。通知機能を使用するには、ディレクトリ・サーバーに対してSMTPサーバーを構成する必要があります。

1. smtp-serverグローバル構成プロパティを設定することにより、SMTPサーバーを指定します。
次のコマンドでは、mailserver.example.comという名前のSMTPサーバーが構成されます:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
set-global-configuration-prop --set smtp-server:mailserver.example.com

2. completionNotifyオプションとerrorNotifyオプションを使用して、タスク通知を送信する電子メール・アドレスを指定します。
次のコマンドでは、backupタスクをスケジュールし、タスク完了時、またはエラー発生時にadmin@example.comに通知を行うように指定しています:

$ backup -D "cn=directory manager" -j pwd-file -a -d /tmp/backups \
--start 20080924121500 --completionNotify admin@example.com \
--errorNotify admin@example.com
Backup task 20080924121500 scheduled to start Sep 24, 2008 12:15:00 PM SAST

14.4.3.4 タスク依存性の構成

タスクを開始する前に別のタスクの完了が必要となる場合があります。ユーティリティのタスク依存性オプションは、タスクが別のタスクに依存すること、および他のタスクが失敗した場合にどうするかを指定します。

タスクをスケジュールして、dependencyとfailedDependencyActionを指定します。

次の例では、別のタスクに依存するバックアップ・タスクをスケジュールし、他のタスクが失敗した場合はバックアップをキャンセルすることを指定します:

$ backup -D "cn=directory manager" -j pwd-file -a -d /tmp/backups \
--start 2008102914530410 --dependency 20080924121500 \
--failedDependencyAction cancel
Backup task 2008102914530410 scheduled to start Oct 29, 2008 14:53:04 PM SAST

14.4.4 スケジュール済タスクの管理と監視

manage-tasksユーティリティは、スケジュール済タスクのリストを取得したり、タスク・ステータスを表示したり、スケジュール済タスクをキャンセルするのに使用できます。次の手順では、スケジュール済タスクの管理例を紹介します:

- 第14.4.4.1項「スケジュール済タスクについての情報の取得」

- 第14.4.4.2項「スケジュール済タスクのキャンセル」

- 第14.4.4.3項「再帰タスクのキャンセル」

14.4.4.1 スケジュール済タスクについての情報の取得

1. 全スケジュール済タスクの概要を表示します。

$ manage-tasks -D "cn=directory manager" -j pwd-file -n -s
ID                Type    Status
------------------------------------------------
2008100912550010  Backup  Completed successfully
2008100912554710  Backup  Completed successfully
2008100912560510  Backup  Waiting on start time
2008100912561410  Backup  Waiting on start time

2. タスクIDで指定される特定タスクの追加情報を表示します。

$ manage-tasks -D "cn=directory manager" -j pwd-file -n -i 2008100912550010

Task Details
------------------------------------------------------
ID                        2008100912550010
Type                      Backup
Status                    Completed successfully
Scheduled Start Time      Immediate execution
Actual Start Time         Oct 9, 2008 12:55:00 PM SAST
Completion Time           Oct 9, 2008 12:55:01 PM SAST
Dependencies              None
Failed Dependency Action  None
Email Upon Completion     None Specified
Email Upon Error          None Specified

Backup Options
----------------------------
Backup All        true
Backup Directory  ../backups

Last Log Message
------------------------------------------------------------------------------
[09/Oct/2008:12:55:01 +0200] severity="NOTICE" msgCount=4 msgID=10944795
message="The backup process completed successfully"

14.4.4.2 スケジュール済タスクのキャンセル

manage-tasksユーティリティを-cオプションまたは--cancelオプション付きで実行します。

次のコマンドは、タスクIDで指定される特定タスクをキャンセルします:

$ manage-tasks -D "cn=directory manager" -j pwd-file -n -c 2008100912561410

14.4.4.3 再帰タスクのキャンセル

再帰タスク全体をキャンセルできます。この場合、再帰タスクと次のスケジュール済反復の両方がキャンセルされます。また、次のスケジュール済タスクのみキャンセルすることもできます。この場合、将来の再帰タスクはタスク・スケジューラによって生成されます。

1. manage-tasksコマンドを使用して、スケジュール済タスクの概要を表示します。

$ manage-tasks -D "cn=directory manager" -j pwd-file -n -s

ID                                             Type    Status
----------------------------------------------------------------------------
Hourly Backup                                  Backup  Recurring
Hourly Backup - Wed Jan 14 13:00:00 SAST 2009  Backup  Waiting on start time

2. manage-tasksユーティリティを-cオプションまたは--cancelオプション付きで実行します。

1. タスクIDで指定して、再帰タスク全体をキャンセルします。

$ manage-tasks -D "cn=directory manager" -j pwd-file -n -c "Hourly Backup"
Task Hourly Backup canceled

2. タスクIDで指定して、次のスケジュール済タスクをキャンセルします。

$ manage-tasks -D "cn=directory manager" -j pwd-file -n \
-c "Hourly Backup - Wed Jan 14 13:00:00 SAST 2009 "
Task Hourly Backup - Wed Jan 14 13:00:00 SAST 2009  canceled

14.5 DSMLゲートウェイのデプロイおよび構成

Directory Services Markup Language (DSML)は、LDAPプロトコルのかわりにXMLベースの表現を使用してディレクトリ・サーバーと通信できるSOAPベースのメカニズムです。Oracle Unified Directory 11gリリース2 PS1 (11.1.2.1.0)は、DSMLとLDAP間のゲートウェイとして動作するWebアプリケーション経由でのDSMLの使用をサポートします。クライアントはDSMLを使用してゲートウェイと通信し、ゲートウェイはLDAP経由でディレクトリ・サーバーと通信します。

この項では、DSMLゲートウェイの構成とデプロイの方法について説明します。内容は次のとおりです:

- 第14.5.1項「DSMLゲートウェイのデプロイ」

- 第14.5.2項「DSMLゲートウェイ・デプロイメントの確認」

14.5.1 DSMLゲートウェイのデプロイ

DSMLゲートウェイは、他のWebアプリケーションと同じように一般的なアプリケーション・コンテナにデプロイできます。次の項では、UNIXシステム上のOracle WebLogic Server 10.3.5にDSMLゲートウェイをデプロイする方法について説明します。

- 第14.5.1.1項「Oracle WebLogic ServerへのDSMLゲートウェイのデプロイ」

- 第14.5.1.2項「IBM WebSphereへのDSMLゲートウェイのデプロイ」

14.5.1.1 Oracle WebLogic ServerへのDSMLゲートウェイのデプロイ

この項では、Oracle WebLogic Serverがインストールされていることが前提になっています。インストールされていない場合は、Oracle Fusion Middleware Oracle Unified Directoryインストレーション・ガイドのOracle WebLogic Serverのインストールに関する項の手順に従って、Oracle WebLogic Serverをインストールしてください。

DSMLゲートウェイ用のWebLogic Serverの構成

1. 次の場所から構成ウィザードを実行します:
OUD_BASE_LOCATION_HOME/wlserver_10.3/common/bin/config.sh

2. 「ようこそ」画面で「新しいWebLogicドメインの作成」を選択し、「次へ」をクリックします。

3. 「ドメイン・ソースの選択」画面で、デフォルトの選択内容(Basic WebLogic Server Domain)を使用して、「次へ」をクリックします。

4. 「ドメイン名と場所の指定」画面で、ドメイン名を入力し、場所を指定します。

この場所に新しいWebLogicドメインが作成されます。DSMLゲートウェイはこのドメインにデプロイされます。

5. 「管理者ユーザー名およびパスワードの構成」画面で、このドメインの管理者になるユーザーの名前とパスワードを入力します。

パスワードは8文字以上の長さで、数字または特殊文字を1つ以上含む必要があります。パスワードを確認して、「次へ」をクリックします。

これらの情報はWebLogicドメインの起動または再起動時に必要になるので、控えておいてください。

6. サーバー起動モードの構成画面で、「本番モード」を選択します。
有効なJDK (Java 1.6以上)を選択し、「次へ」をクリックします。

7. 「オプションの構成」画面で「次へ」をクリックします。

8. 「構成のサマリー」画面で、ドメイン詳細を確認して「作成」をクリックします。

9. 「ドメインの作成中」画面で、「完了」をクリックします。

10. WebLogic Serverに対してJavaオプションを設定します。

$ export JAVA_OPTIONS=-Djavax.xml.soap.MessageFactory=weblogic.xml.saaj.MessageFactoryImpl

Javaオプションを設定しない場合、エラーが返されます。

11. WebLogicドメイン(DOMAIN_HOME/config/config.xml。DOMAIN_HOMEは手順4で作成したドメイン)の構成ファイル内のenforce-valid-basic-auth-credentialsフラグを設定します。
たとえば、次の行をsecurity-configuration要素に追加することにより、ファイルOUD_BASE_LOCATION_HOME/user_projects/domains/base_domain/config/config.xmlを編集します:

<enforce-valid-basic-auth-credentials>false</enforce-valid-basic-auth-credentials>

詳細は、http://download.oracle.com/docs/cd/E12840_01/wls/docs103/security/thin_client.html#understanding_basic_atnを参照してください。

12. DOMAIN_HOME/bin/startWebLogic.sh (DOMAIN_HOMEは手順4で作成したドメイン)を実行することによって、WebLogic Serverを開始します。
例:

OUD_BASE_LOCATION_HOME/user_projects/domains/base_domain/bin/startWebLogic.sh

13. 次の項で説明するようにDSMLゲートウェイWARファイルをデプロイします。

DSMLゲートウェイWARファイルのデプロイ

1. アドオン・ディレクトリにDSMLディレクトリを作成し、そのディレクトリに移動します。

$ cd OUD_BASE_LOCATION_HOME/ORACLE_HOME/addons
$ mkdir DSML
$ cd DSML

2. DSMLゲートウェイWARファイルを展開します。

$ jar xvf ../OUD-DSML.zip

3. 必要に応じて、DSML構成を編集します。
WEB-INF/web.xmlファイルには、DSMLリクエストの転送先となるディレクトリ・サーバーのアドレス(ldap.hostパラメータ)とポート番号(ldap.portパラメータ)を指定するために使用できる初期化パラメータが含まれています。

デフォルトでは、DSMLゲートウェイは、同じシステム(localhost)上のディレクトリ・サーバーとポート389で通信するように構成されています。ホスト・アドレスとポート番号を変更する必要がある場合は、web.xmlファイルを編集して、Webコンテナを再起動します。

4. ブラウザ・ウィンドウで、WebLogic管理コンソール(たとえばhttp://hostname:7001/console)に接続します。hostnameは、WebLogic Serverが実行しているホストです。
前述の手順5で設定した管理者のユーザー名とパスワードを使用します。

5. Webアプリケーションのインストールについては、WebLogic Serverドキュメント(http://download.oracle.com/docs/cd/E12840_01/wls/docs103/ConsoleHelp/taskhelp/web_applications/InstallWebApplications.html)に従ってください。

- 手順4で、展開したアプリケーションのパス(OUD_BASE_LOCATION_HOME/ORACLE_HOME/addons/DSML)を指定します。

- 手順6で、このデプロイメントをアプリケーションとしてインストールするを選択します。

- 他の手順ではデフォルト値を使用します。

6. 管理コンソールの左パネルで、「デプロイメント」をクリックします。

7. DSMLアプリケーションの隣のチェック・ボックスを選択し、「開始」、「すべてのリクエストを処理」の順にクリックします。

8. 「デプロイメントの起動」パネルで、「はい」をクリックします。

9. DSMLアプリケーションがデプロイされ、使用できる状態になります。

14.5.1.2 IBM WebSphereへのDSMLゲートウェイのデプロイ

DSMLゲートウェイWARファイルをIBM Websphereにデプロイするには、次の操作を完了します:

注意:

Oracle Fusion Middleware Oracle Unified Directoryインストレーション・ガイドのOracle Directory Services Manager用のIBM WebSphereの構成に関する項の手順に従って、IBM WebSphereをインストールおよび構成していることを確認します。

1. アドオン・ディレクトリにDSMLディレクトリを作成し、そのディレクトリに移動します。

$ cd OUD_BASE_LOCATION_HOME/ORACLE_HOME/addons
$ mkdir DSML
$ cd DSML

2. DSMLゲートウェイWARファイルを展開します。

$ jar xvf ../OUD-DSML.war

3. 必要に応じて、DSML構成を編集します。
WEB-INF/web.xmlファイルには、DSMLリクエストの転送先となるディレクトリ・サーバーのアドレス(ldap.hostパラメータ)とポート番号(ldap.portパラメータ)を指定するために使用できる初期化パラメータが含まれています。

デフォルトでは、DSMLゲートウェイは、同じシステム(localhost)上のディレクトリ・サーバーとポート389で通信するように構成されています。ホスト・アドレスとポート番号を変更する必要がある場合は、web.xmlファイルを編集して、Webコンテナを再起動します。

4. ブラウザで、IBM WebSphere管理コンソールにログインします。

http://Hostname:Port-Number/ibm/console/

5. 左のパネルで、「アプリケーション」、「新規アプリケーション」の順に選択します。

6. 新規エンタープライズ・アプリケーションをクリックします。
アプリケーション・インストールの準備ページが表示されます。

1. OUD-DSML.warファイルのパスを指定して、「次へ」をクリックします。

- OUD-DSML.warファイルがローカル・システム上にある場合、ローカル・ファイル・システムの完全パスを入力します。

- ファイルがリモートIBM WebSphereマシンに存在する場合は、リモート・ファイル・ロケーションのパスを指定します。

2. 詳細 - すべてのインストール・オプションとパラメータを表示するを選択します。

3. デフォルトのバインディングとマッピングを生成するページで、デフォルト構成のまま「次へ」をクリックします。

7. 「アプリケーション・セキュリティ警告」ページで「続行」をクリックします。
インストール・オプションの選択ページが表示されます。

8. 次の詳細を入力します:

1. デフォルト以外の場所にアプリケーションをインストールするには、「アプリケーションをインストールするディレクトリ」フィールドに、パスを入力します。たとえば、UNIXシステムの場合は次のスクリプトを使用します:
/opt/IBM/Websphere/AppServer/installed Apps/Hostname

2. 次のオプションが選択されていることを確認します:

- JavaServer Pagesファイルのプリコンパイル

- 分散アプリケーション

- ユーザー・バイナリ構成

3. 「アプリケーション名」フィールドにアプリケーション名を入力し、「次へ」をクリックします。デフォルト・アプリケーション名はOUD-DSML.warです。

9. 「モジュールをサーバーにマップ」ページで、Oracle Unified Directoryアプリケーション・マッピングが適切なクラスタ/サーバーに設定されていることを確認し、「次へ」をクリックします。
JSPのコンパイル・オプションの指定ページが表示されます。

10. 次の変更を行い、「次へ」をクリックします:

1. WebモジュールOracle Unified Directoryを選択します。

2. JDKソース・レベルを15に変更します。

11. Webモジュールに対するJSPリロード・オプションの指定ページで、デフォルト構成を使用します。

12. 「共有ライブラリのマップ」ページで、設定を確認し、「次へ」をクリックします。
「共有ライブラリ関係のマップ」ページで、設定を確認し、「次へ」をクリックします。

「Webモジュールの仮想ホストのマップ」ページで、Oracle Unified Directoryアプリケーション・マッピングが適切なホストに設定されていることを確認し、「次へ」をクリックします。

13. 「Webモジュールのコンテキスト・ルートのマッピング」ページで、コンテキスト・ルート/DSMLを指定し、「次へ」をクリックします。

14. 「アプリケーション」、「アプリケーション・タイプ」、WebSphere Enterprise Applications、OUD-DSML_war、「モジュールの管理」の順に選択して、次の操作を行います:

1. クラスタ/サーバーのマッピングが正しいことを確認します。

2. 「OUD-DSML.war」>「クラス・ローダーの順序」の順に選択します。

3. クラス・ローダーの順序でローカル・クラス・ローダーで最初にクラスをロード(親が最後)を選択し、変更を保存します。

注意:

同じセルで複数のアプリケーションを実行している場合、アプリケーション・クラス・ローダーが親をオーバーライドし、クラスの独自のバージョンを提供できるように、アプリケーション・サーバーを構成することが重要です。WebSphereに対して、前述に説明しているように、ローカル・クラス・ローダーで最初にクラスをロード(親が最後)を選択します。

15. IBM WebSphereを再起動します。

14.5.2 DSMLゲートウェイ・デプロイメントの確認

DSMLゲートウェイをデプロイして構成した後、DSMLv2クライアントを使用してDSMLゲートウェイに通信できます。次の項では、このことを行うための2つの方法について説明します:

- 第14.5.2.1項「JXplorerによるDSMLゲートウェイ・デプロイメントの確認」

- 第14.5.2.2項「Directory Server Resource KitによるDSMLゲートウェイ・デプロイメントの確認」

14.5.2.1 JXplorerによるDSMLゲートウェイ・デプロイメントの確認

JXplorerツールは、Oracle Unified Directoryインスタンスのコンテンツの参照、検索および編集に使用できるJavaベースのLDAPブラウザです。このツールはLDAPとDSMLの両方を使用して通信できます。JXplorerのDSMLサポートには認証は含まれませんが(したがって、匿名ユーザーに許可される操作セットにのみ制限されます)、DSMLゲートウェイが期待どおり機能しているかどうか確認することはできます。

JXplorerと付属ドキュメントはjxplorer.orgからダウンロードできます。

JXplorerを使用してDSMLゲートウェイを確認するには、次の手順に従います:

1. JXplorerを開始し、「ファイル」メニューから「接続」オプションを選択します。
「LDAP/DSML接続を開く」ウィンドウが開き、各フィールドに接続情報が表示されます。次の図に、エントリ例を示します。

2. DSMLゲートウェイが実行されるWebアプリケーションのアドレスとポート番号を入力します。

3. プロトコル・リストからDSMLv2を選択します。

4. DSMLサービス・フィールドにDSMLサーブレットのパスを指定します。

5. ディレクトリの適切なベースDN値を指定します。

6. 「OK」をクリックして、ディレクトリ・サーバーに接続し、ツリーを検索および参照できるJXplorerウィンドウ(匿名ユーザー用制限付き)が表示されます。

14.5.2.2 Directory Server Resource KitによるDSMLゲートウェイ・デプロイメントの確認

Directory Server Resource Kit (DSRK)は、ディレクトリ・サーバーとともに使用できるユーティリティのコレクションです。DSRKは、もともとはOracle Directory Server Enterprise Edition対応でしたが、ほとんどの場合において、Oracle Unified Directoryで使用されています。DSRKの最新バージョンは、Oracle Directory Server Enterprise Edition 11gリリース1 PS1 (11.1.1.7.0)に含まれており、LDAPではなくDSMLを使用してディレクトリ・サーバーとやり取りできるdsmlsearchツールとdsmlmodifyツールが含まれています。

これらDSMLツールの旧バージョンがDirectory Server Resource Kitの以前のバージョンから提供されていますが、Oracle Directory Server Enterprise Edition 11gリリース1 PS1 (11.1.1.7.0)から提供されているバージョンの方が操作性に優れているので、こちらの使用を強くお薦めします。Oracle Directory Server Enterprise Edition 11gリリース1 PS1 (11.1.1.7.0)は次のOracle Technology Network (OTN)からダウンロードできます:

http://www.oracle.com/technetwork/middleware/downloads/oid-11g-161194.html

14.5.2.2.1 dsmlsearchコマンドの使用

dsmlsearchコマンドは、ldapsearchコマンドのDSMLベース・バージョンです。dsmlsearchはldapsearchと似ていますが、重要な違いがいくつかあります。使用方法を確認するには、次の例のように、引数なしでコマンドを実行します:

$ ./dsmlsearch
usage: dsmlsearch -h http://host:port -b basedn [options] filter [attributes...]
where:
-h hostURL URL of the directory server
-b basedn  base dn for search
-D binddn  bind dn
-w passwd  bind password (for simple HTTP authentication)
use "-w - " to prompt for a password
-j pwfile  file where password is stored
-s scope   specify the scope of the search
baseObject - For searching only the base entry
singleLevel - For searching only the children
wholeSubtree - For searching the base entry and all childrens
-a deref   specify how aliases are deferenced
neverDerefAliases - Aliases are never dereferenced
derefFindingBaseObj - Dereferenced when finding the base DN
derefAlways - Dereferenced when finding below the base DN
-l seconds specify the maximum number of seconds to wait for the search
-z number  specify the maximum number of entries to return for the search
-f file    specify the name of the file containing the search filter

dsmlsearchコマンドはldapsearchと使用方法が異なります:

- -h引数が、サーバーへのアクセスに使用するURLを指定します。ホスト番号とポート番号、およびゲートウェイ・サーブレットのURIが含まれている必要があります(たとえばhttp://127.0.0.1:8080/dsml/DSMLServlet)。

- -b引数は、検索範囲を指定します。ただし、指定値が異なります(baseではなくbaseObject、oneではなくsingleLevel、subではなくwholeSubtree)。

- 結果はDSML形式で出力されます。これは、ldapsearchで提供されるLDIF形式のようなわかりやすい読取り可能な形式ではありません。

このツールの使用例を次に示します。DSML出力には改行はありませんが、ここでは読みやすさのために改行を入れています。

$ ./dsmlsearch -h http://127.0.0.1:8080/dsml/DSMLServlet \-b "dc=example,dc=com" -s baseObject \"(objectClass=*)"
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body><dsml:batchResponse xmlns:dsml="urn:oasis:names:tc:DSML:2:0:core">
<dsml:searchResponse><dsml:searchResultEntry dn="dc=example,dc=com"><dsml:attr
name="objectClass"><dsml:value>domain</dsml:value><dsml:value>top</dsml:value>
</dsml:attr><dsml:attr name="dc"><dsml:value>example</dsml:value></dsml:attr>
</dsml:searchResultEntry><dsml:searchResultDone><dsml:resultCode code="0"/>
</dsml:searchResultDone></dsml:searchResponse></dsml:batchResponse>
</SOAP-ENV:Body></SOAP-ENV:Envelope>

14.5.2.2.2 dsmlmodifyユーティリティの使用

dsmlmodifyユーティリティは、ldapmodifyコマンドのDSMLベース・バージョンで、DSML経由でDNの追加、削除および変更を実行できます。使用方法を確認するには、次の例のように、引数なしでツールを実行します:

$ ./dsmlmodify
usage: dsmlmodify -h http://host:port [options] -f file
where:
-h hostURL URL of the directory server
-D binddn  bind dn
-w passwd  bind password (for simple HTTP authentication)
use "-w - " to prompt for a password
-j pwfile  file where password is stored
-f file    specify the name of the file containing
the modifications

dsmlsearchユーティリティと同様、-h引数はURLを指定し、出力はDSML形式で返されます。ldapmodifyとは異なり、dsmlmodifyツールは、標準入力からの変更を許可しません。変更はファイルで指定する必要があり、ファイルはLDIFではなくDSML形式である必要があります。また、変更に外部batchRequestラッパーを含めることはできません。次の例に、標準的な入力ファイルを示します。

<addRequest dn="uid=test.user,dc=example,dc=com">
<attr name="objectClass">
<value>top</value>
<value>person</value>
<value>organizationalPerson</value>
<value>inetOrgPerson</value>
</attr>
<attr name="uid">
<value>test.user</value>
</attr>
<attr name="givenName">
<value>Test</value>
</attr>
<attr name="sn">
<value>User</value>
</attr>
<attr name="cn">
<value>Test User</value>
</attr>
<attr name="userPassword">
<value>password</value>
</attr>
</addRequest>
<modifyRequest dn="uid=test.user,dc=example,dc=com">
<modification name="description" operation="replace">
<value>This is the new description</value>
</modification>
</modifyRequest>
<modDNRequest dn="uid=test.user,dc=example,dc=com" newrdn="cn=Test User"
deleteoldrdn="false" newSuperior="ou=People,dc=example,dc=com" />
<delRequest dn="cn=Test User,ou=People,dc=example,dc=com" />

次の例は、これらの変更を適用した後の出力を示しています。読みやすさのために出力に改行を追加しています:

$ dsmlmodify -h http://127.0.0.1:8080/dsml/DSMLServlet \  -D "cn=Directory Manager" -j pwd-file -f /tmp/test.dsml
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body><dsml:batchResponse xmlns:dsml="urn:oasis:names:tc:DSML:2:0:core">
<dsml:addResponse><dsml:resultCode code="0"/></dsml:addResponse>
<dsml:modifyResponse><dsml:resultCode code="0"/></dsml:modifyResponse>
<dsml:modDNResponse><dsml:resultCode code="0"/></dsml:modDNResponse>
<dsml:delResponse><dsml:resultCode code="0"/><dsml:errorMessage>The number of
entries deleted was 1</dsml:errorMessage></dsml:delResponse></dsml:batchResponse>
</SOAP-ENV:Body></SOAP-ENV:Envelope>

$ dsmlmodify -h http://localhost:8080/dsml/DSMLServlet \  -D "cn=directory manager" -j pwd-file -f /tmp/dsml.ldif
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body><batchResponse xmlns="urn:oasis:names:tc:DSML:2:0:core">
<addResponse><resultCode code="0"/></addResponse>
<modifyResponse><resultCode code="0"/></modifyResponse>
<modDNResponse><resultCode code="0"/></modDNResponse>
<delResponse><resultCode code="0"/></delResponse></batchResponse>
</SOAP-ENV:Body></SOAP-ENV:Envelope>

15 プロキシ・コンポーネントの構成

この章では、プロキシ・インスタンスに固有のサーバー要素を構成する方法を説明します。これらの要素の多くは、プロキシ・インスタンスの設定時にロード・バランシングまたは分散トポロジを構成すると自動的に構成されることに注意してください。

この章では、次のトピックを取り扱います:

- 第15.1項「dsconfigを使用したプロキシ構成の管理」

- 第15.2項「ODSMを使用したプロキシ構成の管理」

dsconfigコマンドの詳細は、第14.1項「dsconfigを使用したサーバー構成の管理」を参照してください。

ODSMの詳細は、第18章「Oracle Directory Services Managerを使用したOracle Unified Directoryへのアクセス」を参照してください。

15.1 dsconfigを使用したプロキシ構成の管理

この項では、dsconfigコマンドを使用した、プロキシ構成を管理するための各プロシージャについて説明します。この項の内容は次のとおりです:

- 第15.1.1項「リモートLDAPサーバーとの通信の構成」

- 第15.1.2項「バインド・モードの構成」

- 第15.1.3項「dsconfigを使用したロード・バランシングの構成」

- 第15.1.4項「dsconfigを使用した分散の構成」

- 第15.1.5項「dsconfigを使用したDNリネームの構成」

- 第15.1.6項「dsconfigを使用したRDN変更の構成」

- 第15.1.7項「コマンドラインを使用したグローバル索引の構成」

15.1.1 リモートLDAPサーバーとの通信の構成

この項では、プロキシ・インスタンスと1つ以上のリモートLDAPサーバーとの通信を構成する方法を説明します。この項の内容は次のとおりです:

- 第15.1.1.1項「リモート・サーバーとの通信のコンポーネント」

- 第15.1.1.2項「LDAPサーバー拡張の構成」

- 第15.1.1.3項「プロキシLDAPワークフロー要素の構成」

15.1.1.1 リモート・サーバーとの通信のコンポーネント

プロキシ・インスタンスとリモートLDAPサーバーとの通信には、次の2つの要素が関わっています:

- LDAPサーバー拡張: この要素では、リモート・ピアからのレスポンスを定期的に確認し、接続プールで保持されている有効な接続を提供することによって、リモート・サーバーとの接続性が管理されます。

- プロキシLDAPワークフロー要素: この要素では、LDAPサーバー拡張要素から接続が取得され、構成されているモードで定義されているとおりにユーザーから受け取った操作が実行されます。

15.1.1.2 LDAPサーバー拡張の構成

この項では、リモートLDAPサーバーとの通信に必要なLDAPサーバー拡張を構成する方法を説明します。この項の内容は次のとおりです:

- 第15.1.1.2.1項「既存のLDAPサーバー拡張を表示するには」

- 第15.1.1.2.2項「LDAPサーバー拡張のプロパティを表示するには」

- 第15.1.1.2.3項「LDAPサーバー拡張の拡張プロパティを表示するには」

- 第15.1.1.2.4項「LDAPサーバー拡張を作成するには」

- 第15.1.1.2.5項「LDAPサーバー拡張のプロパティを変更するには」

- 第15.1.1.2.6項「LDAPサーバー拡張の拡張プロパティを変更するには」

- 第15.1.1.2.7項「LDAPデータ・ソースの接続監視プロパティ」

15.1.1.2.1 既存のLDAPサーバー拡張を表示するには

特定のプロキシ・インスタンスに構成されているLDAPサーバー拡張すべてを表示するには、次に示すように、dsconfig list-extensionsコマンドを使用します:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
list-extensions

Extension  : Type
-----------:---------------------
gi-catalog : global-index-catalog
proxy1     : ldap-server
proxy2     : ldap-server

タイプがldap-serverの拡張が、LDAPサーバー拡張です。リモートLDAPサーバーごとに1つのLDAPサーバー拡張が指定されているはずです。

15.1.1.2.2 LDAPサーバー拡張のプロパティを表示するには

特定のLDAPサーバー拡張のプロパティを表示するには、次に示すように、dsconfig get-extension-propコマンドを使用します:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
get-extension-prop --extension-name proxy1

Property                   : Value(s)
---------------------------:---------
enabled                    : true
remote-ldap-server-address : server1.example.com
remote-ldap-server-port    : 1389

次のプロパティが表示されます:

enabled

LDAPサーバー拡張が有効になっている(true)か、それとも有効になっていない(false)かを示します。

remote-ldap-server-addressおよびremote-ldap-server-port

リクエストの転送先のリモートLDAPサーバーのアドレスおよびポートを示します。

monitoring-bind-dnおよびmonitoring-bind-password

これらのプロパティは、--advancedオプションが指定されている場合にのみ表示されます。データ・ソースの監視の実行に拡張で使用される、ユーザーの資格証明が示されます。これらのプロパティがデフォルトから変更されていない場合、これらのプロパティは表示されません。つまり監視は匿名で実行されます。これらのプロパティを構成するには、第29.5項「LDAPを使用したサーバーの監視」を参照してください。

15.1.1.2.3 LDAPサーバー拡張の拡張プロパティを表示するには

LDAPサーバー拡張のすべてのプロパティを表示するには、dsconfig --advanced get-extension-propコマンドを使用します。例:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
--advanced get-extension-prop --extension-name proxy1

次のようなプロパティが表示されます。

Property                            Value(s)
----------------------------------------------------------------------
1)   enabled                             true
2)   java-class                          com.sun.dps.server.workflowelement
.proxyldap.LDAPServerExtension
3)   monitoring-check-interval           30000
4)   monitoring-connect-timeout          5000
5)   monitoring-inactivity-timeout       120000
6)   monitoring-ping-timeout             5000
7)   pool-increment                      5
8)   pool-initial-size                   10
9)   pool-max-size                       1000
10)  pool-max-write                      0
11)  pool-release-connection-interval    300000
12)  pool-use-max-write                  false
13)  proxied-auth-use-v1                 false
14)  remote-ldap-server-address          localhost
15)  remote-ldap-server-connect-timeout  10000
16)  remote-ldap-server-port             1389
17)  remote-ldap-server-read-only        false
18)  remote-ldap-server-read-timeout     10000
19)  remote-ldap-server-ssl-policy       never
20)  remote-ldap-server-ssl-port         636
21)  saturation-precision                5
22)  ssl-client-alias                    -
23)  ssl-key-manager-provider            -
24)  ssl-trust-all                       false
25)  ssl-trust-manager-provider          -

注意:

ほとんどの拡張プロパティ(SSLプロパティを除く)が、LDAPサーバー拡張の作成時にデフォルトで設定されます。

これらの値を変更するには、第15.1.1.2.5項「LDAPサーバー拡張のプロパティを変更するには」を参照してください。

監視プロパティの詳細は、第15.1.1.2.7項「LDAPデータ・ソースの接続監視プロパティ」を参照してください。SSL(セキュリティ)プロパティの詳細は、第21章「プロキシ/データ・ソース間のセキュリティ構成」を参照してください。

15.1.1.2.4 LDAPサーバー拡張を作成するには

新規LDAPサーバー拡張を作成するには、次に示すように、dsconfig create-extensionコマンドを使用します:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
create-extension \
--extension-name DS-proxy5 \
--type ldap-server \
--set enabled:true \
--set remote-ldap-server-address:DS5-hostname
--set remote-ldap-server-port:1389

拡張のtypeはldap-serverである必要があります。新規拡張の名前は、extension-nameで定義します。この例では、DS-proxy5です。

作成している拡張を関連付けるリモートLDAPサーバーの名前も指定する必要があります(remote-ldap-server-address)。リモートLDAPサーバーのホスト名またはIPアドレスを指定できます。

remote-ldap-server-portを指定しないと、デフォルトのLDAPポート1389であると見なされます。

15.1.1.2.5 LDAPサーバー拡張のプロパティを変更するには

LDAPサーバー拡張のプロパティを変更するには、set-extension-propサブコマンドを使用します。このサブコマンドを使用すると、次の操作を実行できます:

- LDAPサーバー拡張を有効にする(true)か、それとも有効にしない(false)かを設定できます。

- リモートLDAPディレクトリ・サーバーのアドレスおよびポート(remote-ldap-server-addressおよびremote-ldap-server-port)を変更できます。

- データ・ソースの監視の実行に拡張で使用される、ユーザーの資格証明を設定できます(monitoring-bind-dnおよびmonitoring-bind-password)。これを空白のままにすると、監視はデフォルトである匿名で実行されます。

たとえば、一般的な操作として、使用するリモートLDAPサーバーの変更があります。これを行うには、次に示すように、新規リモートLDAPサーバーのアドレスとポートを設定する必要があります:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
set-extension-prop \
--extension-name DS-proxy5 \
--set remote-ldap-server-address:DS5-hostname \
--set remote-ldap-server-port:3388

LDAPサーバー拡張の拡張プロパティを変更するには、第15.1.1.2.6項「LDAPサーバー拡張の拡張プロパティを変更するには」を参照してください。

15.1.1.2.6 LDAPサーバー拡張の拡張プロパティを変更するには

次の拡張プロパティを構成できます:

pool-increment

接続プールのサイズを大きくするまたは小さくする際の増分。remote-ldap-server-ssl-policyプロパティがuserに設定されると、2つの接続プールが作成され、各プールのサイズの増分がpool-incrementに設定されます。

デフォルト値は接続数5です。

pool-initial-size

接続プールの初期サイズ。これは、プールの初期化時に作成される初期接続数です。pool-initial-sizeは、プールの最小サイズでもあることに注意してください。

デフォルト値は接続数10です。

remote-ldap-server-ssl-policyプロパティがuserに設定されると、2つの接続プールが作成され、各プールの初期サイズ、つまり最小サイズがpool-initial-sizeに設定されます。このため、最初は合計接続数が、pool-initial-sizeで示される接続数の2倍になる可能性があります。詳細は、第21.2項「セキュアな接続のモード」を参照してください。

pool-max-size

接続プールの最大サイズ。これは、1つのプールに割り当てることができる最大接続数です。remote-ldap-server-ssl-policyプロパティがuserに設定されると、2つの接続プールが作成され、各プールの最大サイズがpool-max-sizeに設定されます。

デフォルト値は接続数1000です。

pool-max-write

1つの接続プールに同時に割り当てることができる書込み接続の最大数。整数を指定します。このパラメータは、pool-use-max-writeパラメータがtrueに設定されている場合にのみ、考慮されます。

デフォルト値は接続数0です。

pool-release-connection-interval

プロキシに送信されているトラフィックがない場合に、プロキシで接続が未使用と見なされるまでの時間。接続数が前に増加されている接続プールの場合、そのサイズが縮小されます。未使用の接続の数がpool-incrementより大きい場合、プールのサイズはpool-incrementの分だけ縮小されます。これは、未使用の接続がクローズされ、プールから削除されることを意味します。

デフォルト値は、300000ミリ秒(30秒)です。

pool-use-max-write

このブール値がtrueに設定されるとpool-max-writeパラメータが考慮されますが、そうでない場合は考慮されません。デフォルトで、pool-use-max-writeはfalseに設定されます。

proxied-auth-use-v1

プロキシ認可制御モードを使用している場合、制御のデフォルトのバージョンはv2です。互換性の理由により前のバージョンを使用する場合は、proxied-auth-use-v1をtrueに設定します。デフォルトで、proxied-auth-use-v1はfalseに設定されます。制御の詳細は、付録B「サポートされている制御および操作」を参照してください。

remote-ldap-server-read-timeout

読取りのタイムアウト。リモートLDAPサーバーがレスポンスを返す前にタイムアウトに達すると、プロキシからクライアントにエラーが返されます。デフォルトで、この値は10000ミリ秒(10秒)です。

saturation-precision

飽和精度は、飽和しきい値の計算に使用されます。飽和限度はリクエストの送受信によって変化するため、飽和精度は、どれくらい飽和が変化したときに、飽和が考慮されることになるかを示します。デフォルトで、考慮に入れられるまで飽和は5%まで変化できます。

監視プロパティについては、第15.1.1.2.7項「LDAPデータ・ソースの接続監視プロパティ」で説明しています。

SSLプロパティは、セキュリティ機能です。これらのプロパティの詳細は、第21章「プロキシ/データ・ソース間のセキュリティ構成」を参照してください。

LDAPサーバー拡張の拡張プロパティを変更するには、set-extension-prop --advancedコマンドを使用します。

注意:

これらの拡張プロパティは、デフォルトで設定されており、通常は変更されません。

変更する可能性がある拡張プロパティの例として、pool-max-sizeがあります。強力なリモートLDAPサーバーを使用しており、最大数のリクエストを受信するようプロキシを構成している場合は、次のようにpool-max-sizeを増加できます:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
set-extension-prop --advanced \
--extension-name DS-proxy5 \
--set pool-max-size:2000

15.1.1.2.7 LDAPデータ・ソースの接続監視プロパティ

LDAPサーバー拡張のdsconfig --advancedコマンドを使用すると、次の監視プロパティを表示または変更できます。明記されていないかぎり、すべてのプロパティはプロアクティブ監視に関連しています。

monitoring-check-interval

監視チェックの間隔。これは、プロキシ・プロアクティブ監視でデータ・ソースのチェックが実行されるミリ秒単位の間隔です。デフォルト値は、30000ミリ秒(30秒)です。

monitoring-connect-timeout

プロアクティブ監視ファシリティがリモートLDAPサーバーへの接続の試行を停止するまでのミリ秒単位の最大時間。デフォルト値は、5000ミリ秒(5秒)です。0は無制限を意味します。

monitoring-inactivity-timeout

リモート・サーバーによる接続のクローズを回避するために定期的にアイドル接続がチェックされるまでのミリ秒単位の時間間隔。このパラメータの値は、monitoring-check-intervalより長く設定する必要があります。デフォルト値は、120000ミリ秒(120秒)です。

monitoring-ping-timeout

プロアクティブ監視でリモート・サーバーへのpingが試行されるミリ秒単位の最大時間。デフォルト値は、5000ミリ秒(5秒)です。

remote-ldap-server-read-timeout

接続が失敗したと見なされるまで、LDAPサーバー拡張がリモート・サーバーからのレスポンスを待機するミリ秒単位の最大時間。0は無制限を意味します。

remote-ldap-server-connect-timeout

接続が失敗したと見なされるまで、監視でリモート・サーバーへの接続が試行されるミリ秒単位の最大時間。0は無制限を意味します。デフォルトは10000ミリ秒(10秒)です。

15.1.1.3 プロキシLDAPワークフロー要素の構成

この項では、リモートLDAPサーバーとの通信に必要なLDAPプロキシ・ワークフロー要素を構成する方法を説明します。この項の内容は次のとおりです:

- 第15.1.1.3.1項「既存のプロキシLDAPワークフロー要素を表示するには」

- 第15.1.1.3.2項「プロキシLDAPワークフロー要素のプロパティを表示するには」

- 第15.1.1.3.3項「プロキシLDAPワークフロー要素を作成するには」

- 第15.1.1.3.4項「プロキシLDAPワークフロー要素のプロパティを変更するには」

15.1.1.3.1 既存のプロキシLDAPワークフロー要素を表示するには

特定のプロキシ・サーバー・インスタンスに構成されているワークフロー要素すべてを表示するには、次に示すように、dsconfig list-workflow-elementsコマンドを使用します:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
list-workflow-elements

Workflow Element : Type               : enabled
-----------------:--------------------:--------
adminRoot        : ldif-local-backend : true
load-bal-we1     : load-balancing     : true
proxy-we1        : proxy-ldap         : true
proxy-we2        : proxy-ldap         : true

プロキシ・ワークフロー要素は、タイプがproxy-ldapになっているものです。

15.1.1.3.2 プロキシLDAPワークフロー要素のプロパティを表示するには

プロキシ・ワークフロー要素のプロパティを表示するには、次に示すように、dsconfig get-workflow-element-propコマンドを使用します:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
get-workflow-element-prop --element-name proxy-we1

Property                              : Value(s)
--------------------------------------:--------------------
client-cred-mode                      : use-client-identity
enabled                               : true
ldap-server-extension                 : proxy1
remote-ldap-server-bind-dn            : -
remote-ldap-server-bind-password      : -
use-proxy-auth                        : false

次のプロパティが表示されます:

client-cred-mode

プロキシからリモートLDAPサーバーに接続する方法を示します。この例では、ステータスはuse-client-identityになっています。これは、クライアントでプロキシへの接続に使用されたものと同じ資格証明を使用してプロキシからリモートLDAPサーバーに接続されることを意味しています。これはデフォルトのモードです。

詳細は、第21章「プロキシ/データ・ソース間のセキュリティ構成」を参照してください。

enabled

ワークフローが有効になっている(true)か、それとも有効になっていない(false)かを示します。

ldap-server-extension

ワークフロー要素が関連付けられているLDAPサーバー拡張の名前です。

remote-ldap-server-bind-dnおよびremote-ldap-server-bind-password

client-cred-modeがuse-specific-identityまたはuse-proxy-authの場合に、リモートLDAPサーバーへの接続にプロキシで使用される、ユーザーの資格証明です。

15.1.1.3.3 プロキシLDAPワークフロー要素を作成するには

プロキシLDAPワークフロー要素を作成するには、LDAPサーバー拡張を構成しておく必要があります。

プロキシLDAPワークフロー要素を作成するには、次に示すように、dsconfig create-workflow-elementコマンドを使用します:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
create-workflow-element \
--element-name proxy-we5 \
--type proxy-ldap \
--set enabled:true \
--set client-cred-mode:use-client-identity \
--set ldap-server-extension:DS-proxy5

ワークフロー要素のタイプは、proxy-ldapである必要があります。新規プロキシLDAPワークフロー要素の名前は、element-nameで定義します。この例では、proxy-we5です。

クライアント資格証明モード(client-cred-mode)は、プロキシがリモートLDAPサーバーに接続する方法を示します。この例では、資格証明モードはuse-client-identityになっています。これは、クライアントでプロキシへの接続に使用されたものと同じ資格証明を使用してプロキシからリモートLDAPサーバーに接続されることを意味しています。これはデフォルトのモードです。

注意:

- Oracle Unified DirectoryリモートLDAPサーバーを使用しており、クライアント資格証明モードがuse-proxy-authに設定されている場合、接続しているユーザーが、リモートLDAPサーバー上に存在する必要があります。ユーザーが存在しないと、リクエストは拒否されます。ユーザーがリモートLDAPサーバー上に存在することを保証できない場合は、クライアント資格証明モードをuse-specific-identityに設定してください。

- ユーザー・デプロイメントで、内部操作が実行される場合は、ルート資格証明を定義する必要があります。たとえば、第15.1.6項「dsconfigを使用したRDN変更の構成」で説明しているようにRDN変更を使用する場合は、ルート資格証明は次のプロパティで定義されます:
remote-root-dn

remote-root-password

これらは、サーバーで内部操作が実行される場合の、リモートLDAPサーバーのルート・ユーザーの資格証明です。

- プロキシLDAPワークフロー要素でパスワードを管理する場合(remote-ldap-server-bind-passwordまたはremote-root-passord)、次の構文が有効です:
<password-value>またはfile://<password-file>

詳細は、第21章「プロキシ/データ・ソース間のセキュリティ構成」を参照してください。

15.1.1.3.4 プロキシLDAPワークフロー要素のプロパティを変更するには

プロキシLDAPワークフロー要素のプロパティを変更するには、set-workflow-element-propコマンドを使用します。

次のプロパティを変更できます:

- プロキシLDAPワークフロー要素を有効にする(true)か、それとも有効にしない(false)かを設定できます。

- 使用するクライアント資格証明モードを設定できます(client-cred-mode)。

- LDAPサーバー拡張を関連付けて、使用するリモートLDAPサーバーを指定できます(ldap-server-extension)。

- リモートLDAPサーバーへの接続にプロキシで使用する、ユーザーの資格証明を設定できます(remote-ldap-server-bind-dnおよびremote-ldap-server-bind-password)。次の構文がサポートされています:

- <password-value>

- file://<password-file>

コマンドラインで、クリア・テキストでパスワードを渡すことはサポートされていますが、お薦めしません。パスワード・ファイルを使用することをお薦めします。パスワード・ファイルは、コマンドが実行されたら削除できます。

たとえば、別のリモートLDAPサーバーを使用するために、ワークフロー要素で使用するLDAPサーバー拡張を変更する場合、次のように実行します:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
set-workflow-element-prop --advanced \
--element-name proxy-we5 \
--set remote-ldap-server-bind-dn:uid=Specific\ User,dc=example,dc=com \
--remote-ldap-server-bind-password:file://pwd-file \
--set ldap-server-extension:DS-proxy3 \
--set client-cred-mode:use-specific-identity

15.1.2 バインド・モードの構成

エンド・ユーザーが1つの認証済操作を実行すると、プロキシLDAPワークフロー要素は、次の2つの個別操作を受け取ります:

1. リモート・サーバーに対してユーザーを認証するバインド操作。

2. 実行する操作。

バインド操作が実行される際には、プロキシLDAPワークフロー要素は、LDAPサーバー拡張から接続を取得し、バインド操作を実行してから、接続を解放します。

実際の操作が着信すると、プロキシLDAPワークフロー要素は、LDAPサーバー拡張から接続を再度取得します。該当する資格証明にバインドされている接続が検出された場合、その接続が再利用されます。検出されなかった場合、新規接続を認証する必要があります。この追加認証操作をサイレント・バインドと呼びます。

サイレント・バインドの実行に使用する一連の資格証明は、バインド・モードで指定されます。これは、LDAPワークフロー要素のプロパティの1つです。これらの資格証明は、クライアント資格証明またはプロキシ資格証明です。表15-1は、Oracle Unified Directoryでサポートされているバインド・モードを示しています。

表15-1 Oracle Unified Directoryでサポートされているバインド・モード

モード

説明

use-client-identity

サイレント・バインドの実行にクライアント資格証明を使用します。

use-specific-identity

サイレント・バインドの実行にプロキシ資格証明を使用します。

15.1.2.1 サーバーを最適化するためのバインド・モード・パラメータの構成

表15-1に示されているバインド・モードごとに、追加のパラメータを構成して、サーバーの動作を微調整することができます。これらのパラメータについては、次の各項で説明しています:

- 第15.1.2.1.1項「use-client-identityバインド・モードの構成」

- 第15.1.2.1.2項「use-specific-identityバインド・モードの構成」

15.1.2.1.1 use-client-identityバインド・モードの構成

バインド・モードがuse-client-identityに設定された場合、サーバーでは特定のパラメータによって阻止されないかぎり、サイレント・バインドの実行にクライアント資格証明が使用されます。サーバーでクライアント資格証明が使用されないようにするパラメータは、次のとおりです:

- 包含リストおよび除外リストの使用

- never-bindパラメータの使用

包含リストおよび除外リストの使用

次のリストを構成できます:

- 包含リスト: リモート・サーバーで処理される接尾辞をリストします。

- 除外リスト: リモート・サーバーで処理されない接尾辞をリストします。

クライアント・バインドDNが包含リスト上のいずれかのDNの子であるが、除外リスト上のいずれのDNの子でもない場合、プロキシ・サーバーではサイレント・バインドの実行にクライアント資格証明が使用されます。それ以外の場合、プロキシ・サーバーでは、サイレント・バインドの実行にプロキシ資格証明が使用されます。両方のリストがともに空の場合、プロキシ・サーバーでは常にクライアント資格証明が使用されます。

包含リストと除外リストは相互に排他的ではなく、同時に使用できます。ただし、1つのリストのみを定義することをお薦めします。また、両方のリストに同一の接尾辞を定義することはできません。

never-bindパラメータの使用

never-bindパラメータは、プロキシでクライアント資格証明を使用したバインドを実行する必要がある場合は常に適用できます。このフラグがtrueに設定されると、プロキシ・サーバーではリモート・データ・ソースからユーザー・エントリが読み取られ、バインドをリモート・サーバーに転送するのではなく、ユーザー・パスワード自体が検証されます。ユーザー・エントリの読取りに使用される資格証明は、プロキシLDAPワークフロー要素の次のプロパティで定義されているプロキシ資格証明であることに注意してください。remote-ldap-server-bind-dnおよびremote-ldap-server-bind-password。

受信バインド操作に重要な制御が含まれている場合、バインド操作専用の制御はnever-bind機能と互換性がないため、エラー結果が返されます。

注意:

プロキシでユーザー・エントリの読取りに独自の資格証明が使用される場合、プロキシ認可制御を操作に追加して、リクエストの送信元のクライアントのIDを示すことができます。use-proxy-authプロパティの値によって、制御を追加する必要があるかどうかが指定されます。

15.1.2.1.2 use-specific-identityバインド・モードの構成

バインド・モードがuse-specific-identityに設定されると、プロキシ・サーバーでは、すべてのサイレント・バインドの実行にプロキシ資格証明が使用されます。プロキシ資格証明は、プロキシLDAPワークフロー要素の次のプロパティで定義されます。remote-ldap-server-bind-dnおよびremote-ldap-server-bind-password。

use-specific-identityバインド・モードでは、次のパラメータを設定できます:

- use-proxy-authパラメータの使用

- never-bindパラメータの使用

use-proxy-authパラメータの使用

use-proxy-authフラグがtrueに設定されると、プロキシ・サーバーでは、バインド・リクエスト以外のすべてのリクエストにプロキシ認可制御が追加されます。プロキシ認可IDの値は、クライアント・バインドDNです。

never-bindパラメータの使用

never-bindパラメータは、プロキシでクライアント資格証明を使用したバインドを実行する必要がある場合は常に適用できます。このフラグがtrueに設定されると、プロキシ・サーバーではリモート・データ・ソースからユーザー・エントリが読み取られ、バインドをリモート・サーバーに転送するのではなく、ユーザー・パスワード自体が検証されます。ユーザー・エントリの読取りに使用される資格証明は、プロキシLDAPワークフロー要素の次のプロパティで定義されているプロキシ資格証明であることに注意してください。remote-ldap-server-bind-dnおよびremote-ldap-server-bind-password。

15.1.3 dsconfigを使用したロード・バランシングの構成

ロード・バランシングを使用してクライアント・リクエストをリモートLDAPサーバーに転送するには、次の要素が必要です:

- ロード・バランシング・ワークフロー要素

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

- ロード・バランシング・ルート(リモートLDAPサーバーごと)

1つのロード・バランシング・ワークフロー要素で、ロード・バランシング・アルゴリズムを1つのみ使用できます。ただし、デプロイメント内のすべてのロード・バランシング・ルートで同一のロード・バランシング・アルゴリズムが使用されます。

この項では、ロード・バランシングに関連するすべての管理タスクについて説明します。インストール時のロード・バランシング・デプロイメントの設定の詳細は、Oracle Fusion Middleware Oracle Unified Directoryインストレーション・ガイドの単純なロード・バランシングの構成に関する項を参照してください。次のトピックが含まれます:

- 第15.1.3.1項「ロード・バランシングを構成するには」

- 第15.1.3.2項「ロード・バランシング・ワークフロー要素の作成」

- 第15.1.3.3項「ロード・バランシング・アルゴリズムの作成」

- 第15.1.3.4項「ロード・バランシング・ルートの作成」

- 第15.1.3.5項「ロード・バランシングのプロパティの変更」

次の各例は、dsconfigコマンドを使用して、ロード・バランシングを構成する方法を示しています。すべての例で、プロキシ・ホスト名(-h)、プロキシ管理ポート(-p)、バインドDN(-D)およびバインド・パスワード・ファイル(-j)が指定され、すべての証明書を信頼するために-Xオプションが使用されています。

15.1.3.1 ロード・バランシングを構成するには

1. ロード・バランシング・ワークフロー要素を作成します。
第15.1.3.2項「ロード・バランシング・ワークフロー要素の作成」を参照してください。

2. ロード・バランシング・アルゴリズムを作成します。
第15.1.3.3項「ロード・バランシング・アルゴリズムの作成」を参照してください。

3. ロード・バランシング・ワークフロー要素ごとに1つのロード・バランシング・ルートを作成します。
第15.1.3.4項「ロード・バランシング・ルートの作成」を参照してください。

15.1.3.2 ロード・バランシング・ワークフロー要素の作成

ロード・バランシングを構成するには、dsconfig create-workflow-elementコマンドを使用して、ロード・バランシング・ワークフロー要素を作成する必要があります。例:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
create-workflow-element \
--element-name load-bal-we1 \
--type load-balancing \
--set enabled:true

ロード・バランシング・ワークフロー要素を作成する場合、タイプをload-balancingにする必要があります。ワークフロー要素の名前は、element-nameで定義され、この例ではload-bal-we1です。

15.1.3.3 ロード・バランシング・アルゴリズムの作成

ロード・バランシング・デプロイメントで、リクエストが転送される方法を指定するには、ロード・バランシング・アルゴリズムを構成する必要があります。ロード・バランシング・アルゴリズム・セットによって、クライアント・リクエストが各リモートLDAPサーバーのプールにディスパッチされる方法が指定されます。使用可能なロード・バランシング・タイプは、failover、optimal、proportionalまたはsaturationです。

ロード・バランシング・アルゴリズムを作成するには、ロード・バランシング・ワークフロー要素が必要です。第15.1.3.2項「ロード・バランシング・ワークフロー要素の作成」を参照してください。

dsconfig create-load-balancing-algorithmコマンドを使用して、ロード・バランシング・アルゴリズムを作成します。例:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
create-load-balancing-algorithm \
--element-name load-bal-we1 \
--type failover

ロード・バランシング・アルゴリズムを作成するために、タイプをproportional、optimal、failoverまたはsaturationとして指定する必要があります。ワークフロー要素の名前は、element-nameで定義され、この例ではload-bal-we1です。

15.1.3.4 ロード・バランシング・ルートの作成

データ・ソースごとに1つのロード・バランシング・ルートが必要です。ロード・バランシング・ルートを作成する前に、ロード・バランシング・ワークフロー要素およびロード・バランシング・アルゴリズムを作成しておく必要があります。

ロード・バランシング・ルートを作成するには、dsconfig create-load-balancing-routeコマンドを使用します。例:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
create-load-balancing-route \
--element-name load-bal-we1 \
--route-name load-bal-route1 \
--type failover \
--set workflow-element:proxy-we1 \
--set add-priority:1 \
--set bind-priority:2 \
--set compare-priority:2 \
--set delete-priority:1 \
--set extended-priority:2 \
--set modify-priority:1 \
--set modifydn-priority:1 \
--set search-priority:2

この例では、load-bal-route1が新規ロード・バランシング・ルートの名前、load-bal-we1が既存のロード・バランシング・ワークフロー要素の名前およびproxy-we1がLDAPプロキシ・ワークフロー要素の名前です。タイプは、関連付けられているロード・バランシング・アルゴリズムで定義されているものと同じにする必要があり、ここではfailoverです。

設定するプロパティ(ここでは優先度)は、作成したロード・バランシングのタイプに関連します。アルゴリズム・タイプに関連した、ルートのプロパティの詳細は、第15.1.3.5項「ロード・バランシングのプロパティの変更」を参照してください。

15.1.3.5 ロード・バランシングのプロパティの変更

ロード・バランシング・デプロイメントを設定したら、優先度、重み、飽和しきい値など特定のプロパティを変更できます。これらのプロパティのほとんどが、ロード・バランシング・ルート・レベルで変更されます。

ロード・バランシング・アルゴリズムに応じて、ロード・バランシングの次のプロパティを変更できます:

フェイルオーバー

最適

比例

飽和

検索フィルタ

add-priority

alert-threshold

add-weight

alert-threshold

priority

bind-priority

saturation-precision*

bind-weight

priority

allowed-attributes

compare-priority

workflow-element

compare-weight

threshold

prohibited-attributes

delete-priority

delete-weight

saturation-precision*

workflow-element

extended-priority

extended-weight

workflow-element

modify-priority

modify-weight

modifydn-priority

modifydn-weight

search-priority

search-weight

workflow-element

workflow-element

switch-back flag

* 飽和精度は、LDAPサーバー拡張のプロパティの1つです。

ロード・バランシング・ルートのプロパティを変更するには、dsconfig set-load-balancing-route-propコマンドを使用します。

サーバーを再起動する必要なく、実行中のアルゴリズムに新規ルートを追加したり、ルートを削除したり、ルートの優先順位を変更したりできます。

注意:

ロード・バランシング・アルゴリズムのタイプを変更することはできません。

たとえば、フェイルオーバー・ロード・バランシング・デプロイメントを比例ロード・バランシング・デプロイメントに変更するには、新規ロード・バランシング・デプロイメントを作成する必要があります。第15.1.3項「dsconfigを使用したロード・バランシングの構成」を参照してください。

次の各項では、1つのロード・バランシング・デプロイメントで使用可能な様々な設定について説明します:

- 第15.1.3.5.1項「フェイルオーバー・アルゴリズムでの優先度の設定」

- 第15.1.3.5.2項「switch-backフラグの設定」

- 第15.1.3.5.3項「最適アルゴリズムまたは飽和アルゴリズムでの飽和精度の設定」

- 第15.1.3.5.4項「比例アルゴリズムの重みの設定」

- 第15.1.3.5.5項「飽和アルゴリズムでのしきい値の設定」

- 第15.1.3.5.6項「飽和しきい値アラートの設定」

- 第15.1.3.5.7項「クライアント接続アフィニティの設定」

- 第15.1.3.5.8項「ロード・バランシング要素の削除」

15.1.3.5.1 フェイルオーバー・アルゴリズムでの優先度の設定

フェイルオーバー・アルゴリズムを使用するロード・バランシング・デプロイメントでは、プロキシ・ワークフロー要素を変更して、使用されるルートを変更したり、指定された操作タイプのルートの優先度を変更したりできます。

フェイルオーバー・アルゴリズムでは、優先度1が最高の優先度で、特定の操作タイプに使用されるメイン・ルートであることを示します。優先度2(またはこれ以降)のルートは、プライマリ・ルートで障害が発生した場合に使用されるセカンダリ・ルートです。優先度は、操作タイプごとに設定されます。つまり、追加操作用としては優先度1のルートに、バインドおよび検索操作用として優先度2を指定できます。

たとえば、ルートload-bal-route1を最初は追加操作用の優先度1のメイン・ルートとして設定したが、このルートをバックアップ・ルートにする必要が生じた場合、次のコマンドを使用して優先度を2に設定できます。

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
set-load-balancing-route-prop \
--element-name load-bal-we1 \
--route-name load-bal-route1
--set add-priority: 2

注意:

指定された操作タイプについて、2つのルートの優先度が同じ場合、リクエストを処理するアクティブ・ルートの選択はランダムです。

15.1.3.5.2 switch-backフラグの設定

ロード・バランシング・デプロイメントでのフェイルオーバーの後、バックアップ・ルートでは、障害が発生した優先サーバーが使用可能になった後でも、すべての受信リクエストの処理が続けられます。プライマリ・ルートへのスイッチバックまたはフェイルバックは、switch-backフラグがtrueに設定されていないかぎり、自動的には発生しません。デフォルトで、switch-backフラグはfalseに設定されます。

switch-backフラグは、拡張プロパティです。switch-backフラグをtrueに設定するには、次のように実行します:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
--advanced set-load-balancing-algorithm-prop \
--element-name load-bal-we1 \
--set switch-back:true

15.1.3.5.3 最適アルゴリズムまたは飽和アルゴリズムでの飽和精度の設定

最適アルゴリズムまたは飽和アルゴリズムを使用するロード・バランシング・デプロイメントでは、飽和精度レベルを設定できます。飽和精度は、2つの飽和レベルの差分であり、飽和レベルが最低のルートの判別に使用されます。デフォルトで、飽和精度レベルは5に設定されます。

飽和精度レベルが低すぎて、ルートが頻繁に変わりすぎると思われる場合は、次のように飽和精度レベルを変更できます:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
--advanced set-extension-prop \
--extension-name proxy1 \
--set saturation-precision:10

15.1.3.5.4 比例アルゴリズムの重みの設定

比例アルゴリズムを使用してロード・バランシング・デプロイメントを作成したら、プロキシ・ワークフロー要素を変更して、使用するルートおよびルートの重みを変更できます。操作タイプごとに異なる重みを指定できます。重みの値は、0以上である必要があります。0は、指定された操作には対象のルートが使用されないことを示します。

対話モードのdsconfigを使用すると、次のプロパティが変更可能なことがわかります:

>>>> Configure the properties of the Proportional Load Balancing Route

Property          Value(s)
---------------------------
1)  add-weight        1
2)  bind-weight       1
3)  compare-weight    1
4)  delete-weight     1
5)  extended-weight   1
6)  modify-weight     1
7)  modifydn-weight   1
8)  search-weight     1
9)  workflow-element  proxy-we1

たとえば、最初にすべての操作に対してすべてのルートを重み1に設定した場合、すべてのサーバーで同等の比率で操作が処理されます。ただし、リモートLDAPサーバーを、デプロイメント内の他のユーザーより多くの検索リクエストを処理するよう設定する場合は、リモートLDAPサーバーのsearch-weightを5などのより大きな値に設定できます。これには、次のようなコマンドを使用します:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
set-load-balancing-route-prop \
--element-name load-bal-we1 \
--route-name load-bal-route1 \
--set search-weight:5

注意:

すべての操作について重みを変更するには、各操作の重みを個別に変更する必要があります。

他方のルートの2倍の操作を処理するようload-bal-route1を変更するには、すべての操作の重みを2に設定します(他方のルートの重みが1に設定されていることを前提としています)。つまり、次のようなコマンドを実行します:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
set-load-balancing-route-prop \
--element-name load-bal-we1 \
--route-name load-bal-route1 \
--set add-weight:2 \
--set bind-weight:2 \
--set compare-weight:2 \
--set delete-weight:2 \
--set extended-weight:2 \
--set modify-weight:2 \
--set modifydn-weight:2 \
--set search-weight:2

いずれかの操作について重みが0に設定されている場合、ルートではその指定された操作は実行されません。たとえば、add-weightを0に設定すると、load-bal-route1では、関連付けられているリモートLDAPサーバーに追加リクエストが転送されることはありません。特定の操作について、構成されているすべてのルートが重み0を示している場合、その操作はサポートされません。

15.1.3.5.5 飽和アルゴリズムでのしきい値の設定

飽和アルゴリズムを使用してロード・バランシング・デプロイメントを作成したら、使用されるプロキシ・ワークフロー要素、ルートの優先度、飽和しきい値および飽和しきい値アラートを変更できます。

飽和アルゴリズムでは、リクエストは次の2つの条件に基づいて分散されます。サーバーの優先度とサーバーの飽和しきい値です。飽和しきい値は、サーバーが最大化されていると見なされ、サービスの機能が低下する可能性がある限界値です。飽和アルゴリズムを使用したロード・バランシング・デプロイメントでは、リクエストは、優先度が最高(1)のサーバーに、そのサーバーに指定されている飽和しきい値に達するまで送信されます。

たとえば、load-bal-route1を最高優先度のサーバーとして指定し、しきい値を80%に指定すると、すべてのリクエストは、飽和しきい値の80%を超えるまでload-bal-route1に送信されます。80%を超えると、リクエストは、優先度リストの次のサーバーにルーティングされます。

>>>> Configure the properties of the Saturation Load Balancing Route

Property          Value(s)
---------------------------
1)  alert-threshold   85
2)  priority          1
3)  threshold         80
4)  workflow-element  proxy-we1

飽和しきい値を変更するには、次のコマンドを使用します:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
set-load-balancing-route-prop \
--element-name load-bal-we1 \
--route-name load-bal-route1 \
--set threshold:90

この例では、飽和しきい値は90%に設定されています。

15.1.3.5.6 飽和しきい値アラートの設定

飽和しきい値アラートは、システム管理者にサーバーが飽和限度を超えたことを知らせる通知を送信する時点の設定に使用されます。通常、飽和しきい値アラートは、飽和が飽和しきい値を超えた後も増え続けている(これは問題を示唆している可能性がある)かどうかを示すために、飽和限度より高く設定されます。リクエストが別のルートに転送されるまでに短い遅延があって、その間に飽和の増加が続くことになる可能性があるため、アラートには受け入れ可能なバッファを設定しておく必要があります。

飽和しきい値を変更するには、次のコマンドを使用します:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
set-load-balancing-route-prop \
--element-name load-bal-we1 \
--route-name load-bal-route1 \
--set alert-threshold:85

予防的措置を講じるために飽和しきい値アラートを飽和しきい値より低い値に設定できます(たとえば、メイン・ルートが、ロード・バランシングが設定された一連のサーバーの場合、その一連のサーバーに予防措置として1つ以上のサーバーを追加できます)。これは、飽和しきい値に達していない場合でも通知を受信することを意味しています。つまり、飽和しきい値アラートが送信されたが、飽和限度が低くなっていて、飽和しきい値には達していないということです。ただし、飽和しきい値に達したときにのみ、リクエストは優先度が次のルートに送信されます。

通知メッセージの設定の詳細は、第29.4項「アラートおよびアカウント・ステータス通知ハンドラの構成」を参照してください。

15.1.3.5.7 クライアント接続アフィニティの設定

クライアント接続アフィニティを定義すると、指定されたクライアント接続からのリクエストは、設定されているロード・バランシング・アルゴリズムをバイパスして、同一サーバーにルーティングされます。クライアント接続アフィニティは、ネットワーク・グループ・レベルで設定されます。

クライアント接続アフィニティを設定するには、dsconfig create-network-group-qos-policyコマンドを使用します。詳細は、第14.1.6.3項「ネットワーク・グループのサービス品質ポリシーの作成」を参照してください。

例15-1 クライアント接続アフィニティが拒否される場合の例

クライアント接続アフィニティを設定すると、定義されている重みの制約が順守されているかぎり、ロード・バランシング・アルゴリズムはバイパスされます。

たとえば、次のルートが次の重みで設定されているとします:

- LB-route1: add=10, search=0

- LB-route2: add=0, search=10

LB-route1がすべての追加リクエストを受信し、LB-route2がすべての検索リクエストを受信することが明らかです。

この例でロード・バランシング・デプロイメントをクライアント接続アフィニティall-requests-after-first-write-requestで設定するとします。ロード・バランシング・デプロイメントで追加、検索、追加という一連のリクエストを受信した場合、通常、クライアント接続アフィニティでは、最初の追加リクエストと同じルート(LB-route1)に検索リクエストが送信されます。ところが、この場合、検索リクエストはLB-route1では許可されていないため、ロード・バランシング・アルゴリズムはクライアント・アフィニティによってバイパスされません。

15.1.3.5.8 ロード・バランシング要素の削除

ロード・バランシング・ワークフロー全体(ワークフロー要素、アルゴリズムおよびルート)を削除するために必要な処理は、ロード・バランシング・ワークフロー要素の削除のみです。ロード・バランシング・ワークフロー要素を削除すると、関連付けられているロード・バランシング・アルゴリズムおよびルートは通知なしに削除されます。

15.1.4 dsconfigを使用した分散の構成

クライアント・リクエストをリモートLDAPサーバーに分散を使用して転送するには、プロキシ・サーバーに次のコンポーネントを構成する必要があります:

- 分散ワークフロー要素

- 分散アルゴリズム

- 1つ以上の分散パーティション(通常はリモートLDAPサーバーごとに1つ)

1つの分散ワークフロー要素には、データの分散方法が定義される分散アルゴリズムを1つのみ設定できます。1つの分散アルゴリズムで、複数のパーティションを使用できます。

次の各例は、dsconfigコマンドを使用して、分散を構成する方法を示しています。セットアップ時の分散デプロイメントの設定の詳細は、Oracle Fusion Middleware Oracle Unified Directoryインストレーション・ガイドの単純な分散の構成に関する項を参照してください。

次の各プロシージャで使用するすべてのコマンドで、プロキシ・ホスト名(-h)、プロキシ管理ポート(-p)、バインドDN(-D)およびバインド・パスワード・ファイル(-j)が指定されます。各例では、すべての証明書を信頼するために-Xオプションが使用されます。

この項には次のトピックが含まれます:

- 第15.1.4.1項「分散を構成するには」

- 第15.1.4.2項「分散ワークフロー要素の作成」

- 第15.1.4.3項「分散アルゴリズムの作成」

- 第15.1.4.4項「分散パーティションの作成」

- 第15.1.4.5項「DNの変更リクエストの管理」

- 第15.1.4.6項「ワークフローのクリティカル度の構成」

- 第15.1.4.7項「ワークフロー要素のクリティカル度の構成」

- 第15.1.4.8項「分散構成の削除」

15.1.4.1 分散を構成するには

1. 分散ワークフロー要素を作成します。
第15.1.4.2項「分散ワークフロー要素の作成」を参照してください。

2. 分散アルゴリズムを作成します。
第15.1.4.3項「分散アルゴリズムの作成」を参照してください。

3. パーティション化されたデータのチャンクごとに1つのパーティションを作成します。1つのパーティションを1つのリモートLDAPサーバーに、またはレプリケートされた複数のリモートLDAPサーバーの1つのセットに関連付ける必要があります。

- 容量ベースの分散の場合は、第15.1.4.4.1項「capacity分散パーティションの作成」を参照してください。

- 辞書編集分散または数値分散の場合は、第15.1.4.4.2項「lexicoまたはnumeric分散パーティションの作成」を参照してください。

- DNパターン・アルゴリズムを使用している場合は、第15.1.4.4.3項「dnpattern分散パーティションの作成」を参照してください。

15.1.4.2 分散ワークフロー要素の作成

分散を構成するには、dsconfig create-workflow-elementコマンドを使用して、分散ワークフロー要素を作成する必要があります。例:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
create-workflow-element \
--element-name distrib-we \
--type distribution \
--set enabled:true \
--set base-dn:ou=people,dc=example,dc=com

分散ワークフロー要素を作成するには、タイプをdistributionにする必要があります。ワークフロー要素の名前は、element-nameで定義され、この例ではdistrib-weです。

注意:

前述のように、create-workflow-elementサブコマンドを使用してbase-dnを宣言する場合、必ず完全なツリー構造を指定してください。

構成の分散要素を完成するには、分散アルゴリズムおよび適切なパーティションを作成します。

15.1.4.3 分散アルゴリズムの作成

分散デプロイメントで、リクエストが転送される方法を指定するには、分散アルゴリズムを構成する必要があります。アルゴリズム・セットによって、データをパーティション化する方法およびリクエストの送信先のパーティションが指定されます。使用可能な分散タイプは、numeric、lexicoまたはdnpatternです。

分散アルゴリズムを作成するには、分散ワークフロー要素が必要です。第15.1.4.2項「分散ワークフロー要素の作成」を参照してください。

dsconfig create-distribution-algorithmコマンドを使用して、分散アルゴリズムを作成します。例:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
create-distribution-algorithm \
--element-name distrib-we \
--type numeric \
--set distribution-attribute:uid

ワークフロー要素の名前は、element-nameで定義され、この例ではdistrib-weです。分散アルゴリズムのタイプをcapacity、numeric、lexicoまたはdnpatternに設定する必要があります。設定するプロパティは、アルゴリズム・タイプによって異なります。この例では、アルゴリズム・タイプがnumericであるため、distribution-attributeを設定する必要があります。

15.1.4.4 分散パーティションの作成

次のタイプの分散パーティションを作成できます:

- 第15.1.4.4.1項「capacity分散パーティションの作成」

- 第15.1.4.4.2項「lexicoまたはnumeric分散パーティションの作成」

- 第15.1.4.4.3項「dnpattern分散パーティションの作成」

15.1.4.4.1 capacity分散パーティションの作成

capacity分散パーティションを作成するには、分散ワークフロー要素および分散アルゴリズムを作成しておく必要があります。データ・セットごとに1つの分散パーティションを作成する必要があります。

分散パーティションを作成するには、dsconfig create-distribution-partitionコマンドを使用します。例:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
create-distribution-partition \
--element-name distrib-we \
--partition-name distrib-partition1 \
--type capacity \
--set partition-id:1 \
--set workflow-element: proxy-we1 \
--set max-entries:1000

注意:

容量ベースのアルゴリズムを使用する場合は、グローバル索引カタログを作成して、DNに索引を付ける必要があります。グローバル索引カタログを作成するには、第15.1.7.1.1項「グローバル索引が含まれるグローバル索引カタログを作成するには」を参照してください。

分散パーティションは、パーティション名(この例ではdistrib-partition1)とパーティションIDの両方で識別されます。パーティションIDは、グローバル索引カタログ参照で使用されることになるため、簡単な整数にする必要があります。タイプは、関連付けられている分散アルゴリズムで定義されているものと同じにする必要があり、ここではcapacityです。

分散パーティションを作成する場合、パーティションを管理する既存の分散ワークフロー要素の名前(element-name、ここではdistrib-we)、およびLDAPワークフロー要素などワークフロー内の次の要素の名前(workflow-element、この例ではproxy-we1)も指定する必要があります。プロキシ・ワークフロー要素によって、リモートLDAPサーバー上のデータへのアクセスに使用されるパスが指定されます。プロキシの詳細は、第15.1.1項「リモートLDAPサーバーとの通信の構成」を参照してください。

capacity分散パーティションを作成する場合、パーティションで保持可能なエントリの最大数を指定する必要があります(たとえば、1000)。

15.1.4.4.2 lexicoまたはnumeric分散パーティションの作成

辞書編集分散と数値分散はよく似ており、辞書編集分散または数値分散の分散パーティションを作成する場合は同じプロパティを設定します。データ・セットごとに1つの分散パーティションを作成する必要があります。

lexicoまたはnumeric分散パーティションを作成するには、分散ワークフロー要素および分散アルゴリズムを作成しておく必要があります。

分散パーティションを作成するには、dsconfig create-distribution-partitionコマンドを使用します。数値分散の例として、次のようなパーティションを作成する場合があります:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
create-distribution-partition \
--element-name distrib-we \
--partition-name distrib-partition1 \
--type numeric \
--set partition-id:1 \
--set workflow-element: proxy-we1 \
--set lower-bound:1000 \
--set upper-bound:2000

分散パーティションは、パーティション名(この例ではdistrib-partition1)とパーティションIDの両方で識別されます。パーティションIDは、グローバル索引カタログ参照で使用されることになるため、簡単な整数にする必要があります。タイプは、関連付けられている分散アルゴリズムで定義されているものと同じにする必要があり、ここではnumericです。

分散パーティションを作成するために、既存の分散ワークフローの名前(ここではdistrib-we)、およびLDAPワークフロー要素など関連付けられているワークフロー要素の名前(この例ではproxy-we1)も指定する必要があります。プロキシ・ワークフロー要素によって、リモートLDAPサーバー上のデータへのアクセスに使用されるパスが指定されます。プロキシの詳細は、第15.1.1項「リモートLDAPサーバーとの通信の構成」を参照してください。

lexicoまたはnumeric分散パーティションを作成する場合、パーティションの下限と上限を指定する必要があります。プロキシによって、どの2つのパーティションの範囲にも、重なりがないことが確認されます。つまり、パーティション1の下限と上限を1000-3000に設定して、パーティション2の下限と上限を2000-4000に設定することはできません。

上限値自体は含まれません。つまり、前述の例では、パーティション化されるデータは1000から1999までの値のみになります。上限または下限を無制限にする場合は、キーワードunlimitedを使用します。

設定するプロパティ(この例では下限と上限)は、作成した分散のタイプに関連します。アルゴリズム・タイプに関連した、パーティションのプロパティの詳細は、第15.1.4項「dsconfigを使用した分散の構成」を参照してください。

なお、辞書編集分散アルゴリズムの場合、使用されるソート・シーケンスはASCIIです。

15.1.4.4.3 dnpattern分散パーティションの作成

dnpattern分散パーティションを作成する前に、分散ワークフロー要素および分散アルゴリズムを作成しておく必要があります。

dnpattern分散パーティションを作成するには、dsconfig create-distribution-partitionコマンドを使用します。例:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
create-distribution-partition \
--element-name distrib-we \
--partition-name distrib-partition5 \
--type dnpattern \
--set partition-id:5 \
--set workflow-element: proxy-we1 \
--set dn-pattern:uid=[0-9]*[01].*

分散パーティションは、パーティション名(この例ではdistrib-partition5)とパーティションIDの両方で識別されます。パーティションIDは、グローバル索引カタログ参照に使用されるため、簡単な整数にします。分散パーティションを作成するために、既存の分散ワークフローの名前(ここではdistrib-we)、およびLDAPプロキシなど関連付けられているワークフロー要素の名前(この例ではproxy-we1)も指定する必要があります。タイプは、関連付けられている分散アルゴリズムで定義されているものと同じにする必要があり、ここではdnpatternです。

dnpatternアルゴリズムを使用する分散シナリオでは、リクエストは、分散ベースDNより下位のリクエストRDNがDN文字列パターンに一致した場合にパーティションに送信されます。たとえば、分散ベースDNがou=people,dc=example,dc=comで、リクエスト・ベースDNがuid=1,ou=people,dc=example,dc=comの場合、文字列パターンに対するチェックはRDN uid=1で実行されます。

同様に、分散ベースDNがou=people,dc=example,dc=comで、リクエスト・ベースDNがuid=1,ou=region1,ou=people,dc=example,dc=comの場合、文字列パターンに対するチェックは、RDN uid=1,ou=region1で実行されます。

15.1.4.4.4 DNパターン文字列構文

DN文字列パターンは、DN構文およびJava Patternクラスのサブセットに準拠する必要があります。

DNパターン文字列

説明

.

任意の文字

\\

バックスラッシュ

\t

タブ文字

[abc]

a、bまたはc

[^abc]

a、bまたはcを除く任意の文字

[a-zA-Z]

aからzまたはAからZ、範囲指定に使用する文字も含む(範囲)

[a-d[m-p]]

aからd、またはmからp(和集合)

[a-z&&[def]]

d、eまたはf(積集合)

[a-z&&[^bc]]

aからzのうち、bおよびcを除く(減算)

[A-Z&&[^M-P]]

aからzのうち、mからpを除く(減算)

次の数量詞を使用できます:

X?

X、1回または0回

X*

X、0回以上

X+

X、1回以上

X{n}

X、n回

X{n,}

X、n回以上

X{n,m}

X、n回以上m回以下

15.1.4.4.5 DNパターンnegative-matchの使用

negative-matchという分散プロパティを使用して、一致する必要のあるDNパターンに反するものを指定できます。つまり、無視するDNパターンを指定します。指定したDNパターンに一致しない値が分散されます。デフォルトで、negative-matchプロパティは、falseに設定されます。

次のように、negative-matchを使用して、dnpattern分散パーティションを作成します:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
create-distribution-partition \
--element-name distrib-we \
--partition-name distrib-partition5 \
--type dnpattern \
--set partition-id:5 \
--set workflow-element: proxy-we1 \
--set dn-pattern:uid=[123]*[0-9].* \
--set negative-match:true

この例では、negative-matchがtrueに設定されているため、1、2または3で開始して、n個の文字が続くもの以外のuidについてのリクエストはすべて、対象のパーティションに転送されます。

15.1.4.5 DNの変更リクエストの管理

新規エントリが元のエントリと同じパーティションに留まるようDNを変更できます。デフォルトで、プロキシでは現行パーティションの範囲外の値にDNを変更することは許可されません。

modifyDNリクエストで、エントリが配置されているパーティションの境界外の値にDNを変更できるようにするには、force-modify-dnフラグをtrueに設定します。

たとえば、uidの境界が0-999のパーティション1と、uidの境界が1000-1999のパーティション2があるとします。force-modify-dnフラグをtrueに設定して、特定のエントリのuidを1から1001に変更すると、変更は許可されますが、uidが1001のそのエントリはパーティション1に留まります。このエントリがパーティション2に移動されることはありません。

uid=1001を検索すると、サーバーは、そのようなエントリは見つからないというエラーを返します。エントリの位置を特定するには、グローバル索引カタログを使用する必要があります。これによって、変更されているエントリが常に見つかります。グローバル索引カタログを構成するには、第15.1.7項「コマンドラインを使用したグローバル索引の構成」を参照してください。

DN変更操作を強制実行するには、次のように、force-modify-dnフラグをtrueに設定します:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
--advanced set-workflow-element-prop --element-name distrib-we \
--set force-modify-dn:true

15.1.4.6 ワークフローのクリティカル度の構成

クリティカル度の構成によって、検索操作が失敗したときのサーバーの動作が指定されます。クリティカル度は検索リクエストにのみ適用されます。その他のリクエストはすべてサーバーによって通常どおりに処理されます。

クリティカル度は、ワークフロー・レベルでクリティカル度フラグを設定することによって構成できます。ワークフローで検索リクエストを実行するときに、下位ワークフローがある場合は、いくつかのワークフローでそのリクエストが実行されます。ワークフローのクリティカル度の設定は、次のいずれかになります:

- true
これはデフォルト設定で、対象のワークフローをクリティカルであると見なすことを示します。特定のワークフローで結果を返すことに失敗した場合、その他のワークフローでの操作の実行が成功したかどうかにかかわらず、処理は停止します。

- false
この設定は、対象のワークフローが非クリティカルであることを示します。クリティカル度の設定がfalseの場合、特定のワークフローでの操作実行の失敗は全体的な結果にとってクリティカルではないことがサーバーに伝えられます。非クリティカルのワークフローが結果を返すことに失敗した場合、サーバーでは単にその結果が省略され(ワークフローが何もデータを返さなかったかのように)、クライアントに成功の結果コードを返し、エラーが示されることはありません。

- Partial
この設定は、対象のワークフローが部分的にクリティカルであることを示します。これは、結果の一部が取得されたことをアプリケーションからアプリケーションのユーザーに通知できることを意味します。たとえば、完全に飽和したことや無効になっていることによって、部分的にクリティカルなパーティションが結果を返すことに失敗した場合、サーバーはAdmin Limit Exceededエラーを返します。これは、実際の内容とは異なるエラーですが、この設定の目的は、クライアント・アプリケーションのロジックによって、表示されている結果が全体の一部にすぎないことが示されることです。

ワークフローのクリティカル度を設定するには、dsconfig set-workflow-propコマンドを使用します。たとえば、次のコマンドでは、workflow-1という名前のワークフローのクリティカル度がtrueに設定されます。

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
set-workflow-prop --workflow-name workflow-1 \
--set criticality:true

15.1.4.7 ワークフロー要素のクリティカル度の構成

分散デプロイメントでは、クリティカル度構成によって、ホスト・エラーによって検索操作が失敗したときのサーバーの動作を指定します。クリティカル度は検索リクエストにのみ適用されます。その他のリクエストはすべてサーバーによって通常どおりに処理されます。

クリティカル度は、分散ワークフロー要素の分散パーティションごとに構成されます。分散パーティションのクリティカル度の設定は、次のいずれかになります:

- true
これはデフォルト設定で、対象のパーティションをクリティカルであると見なすことを示します。たとえば、完全に飽和したことや無効になっていることによって、特定のパーティションが結果を返すことに失敗した場合、データが他のパーティションで見つかったかどうかにかかわらず、サーバーは使用不可のエラーをクライアントに返します。

- false
この設定は、対象のパーティションが非クリティカルであることを示します。クリティカル度の設定がfalseの場合、特定のパーティションでの操作実行の失敗は全体的な結果にとってクリティカルではないことがサーバーに伝えられます。たとえば、完全に飽和したことや無効になっていることによって、非クリティカルのパーティションが結果を返すことに失敗した場合、サーバーでは単にその結果が省略され(パーティションが何もデータを返さなかったかのように)、クライアントに成功の結果コードを返し、エラーが示されることはありません。

- Partial
この設定は、対象のパーティションが部分的にクリティカルであることを示します。これは、結果の一部が取得されたことをアプリケーションからアプリケーションのユーザーに通知できることを意味します。たとえば、完全に飽和したことや無効になっていることによって、部分的にクリティカルなパーティションが結果を返すことに失敗した場合、サーバーはAdmin Limit Exceededエラーを返します。これは、実際の内容とは異なるエラーですが、この設定の目的は、クライアント・アプリケーションのロジックによって、表示されている結果が全体の一部にすぎないことが示されることです。

分散ワークフロー要素を除くすべてのタイプのワークフロー要素について、クリティカル度は暗黙的であり、次のように処理されます:

- ロード・バランシング: すべてのルートが非クリティカルと見なされます。1つのルートが機能しない場合、それがロード・バランサで選択ルートの決定に考慮されることはないためです。

- LDAPプロキシ・ワークフロー要素: LDAPサーバーは常にクリティカルと見なされます。

- ローカル・バックエンド・ワークフロー要素: ローカル・バックエンド・サーバーは常にクリティカルと見なされます。

分散パーティションのクリティカル度を設定するには、dsconfig set-distribution-partition-propコマンドを使用します。たとえば、次のコマンドでは、distrib-partition-1という名前のパーティションのクリティカル度がtrueに設定されます。

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
set-distribution-partition-prop --element-name distrib-we \
--partition-name distrib-partition-1 --set criticality:true

15.1.4.8 分散構成の削除

分散ワークフロー全体(ワークフロー要素、アルゴリズムおよびパーティション)を削除するために必要な処理は、分散ワークフロー要素の削除のみです。分散ワークフロー要素を削除すると、関連付けられている分散アルゴリズムおよびパーティションは通知なしに削除されます。

15.1.5 dsconfigを使用したDNリネームの構成

DNリネームを構成するには、dsconfig create-workflow-elementコマンドを使用して、DNリネーム・ワークフロー要素を作成する必要があります。

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
create-workflow-element \
--type dn-renaming \
--element-name RenameorgDN \
--set client-base-dn:ou=myorg,dc=example,dc=com \
--set next-workflow-element:load-bal-we1 \
--set source-base-dn:ou=people,dc=example,dc=com \
--set enabled:true

- --set client-base-dnは、クライアント・ベースDNを示します。これは、ワークフロー・エントリ・ポイントです。

- --set source-base-dnは、エントリで変換後に使用する必要のあるベースDNを示します。これは、ワークフロー終了ポイントです。

- --set next-workflow-elementは、プロキシ・アーキテクチャでDNリネーム・ワークフロー要素に続くワークフロー要素を示します。これは、どのようなタイプのワークフロー要素でもかまいません。

15.1.5.1 DNリネーム構成の変更

DNリネームを構成したら、DNリネームの次のプロパティを変更できます:

- クライアント・ベースDN

- ソース・ベースDN

- 次のワークフロー要素

- ブラック・リストの属性

- ホワイト・リストの属性

1. DNリネームの現行プロパティを表示するには、dsconfig get-workflow-element-propコマンドを使用します。

2. DNリネームのプロパティを変更するには、dsconfig set-workflow-element-propコマンドを使用します。

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
set-workflow-element-prop \
--element-name RenameorgDN \
--set source-base-dn:ou=admin,dc=example,dc=com

この例では、source-base-dnのみが変更されています。元のソース・ベースDNを指定する必要はありません。新しいもののみが必要です。

リネームしてはいけないDN属性のブラック・リストを作成するには、dsconfig set-workflow-element-propコマンドを使用します。

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
set-workflow-element-prop --element-name RenameorgDN \
--set black-list-attributes:manager

属性にはDNタイプを指定する必要があります。

15.1.6 dsconfigを使用したRDN変更の構成

RDNをリネームするには、dsconfig create-workflow-elementコマンドを使用して、RDN変更ワークフロー要素を作成します。

dsconfig create-workflow-element \
--set client-rdn:cn \
--set enabled:true \
--set next-workflow-element:localproxy \
--set source-rdn:uid \
--type rdn-changing \
--element-name myrdnchangingwfe \
--hostname localhost \
--port "4444" \
--trustAll \
--bindDN cn=directory\ manager \
--bindPasswordFile pwd-file \
--no-prompt

- --set client-rdnは、クライアント・ベースRDNを示します。これは、ワークフロー・エントリ・ポイントです。

- --set source-rdnは、エントリで変換後に使用する必要のあるベースRDNを示します。これは、ワークフロー終了ポイントです。

- --set next-workflow-element:localproxyは、プロキシ・アーキテクチャでRDN変更ワークフロー要素に続くワークフロー要素を示します。これは、どのようなタイプのワークフロー要素でもかまいません。

注意:

次のパラメータを使用して、プロキシLDAPワークフロー要素を作成する必要があります。

- remote-root-dn

- remote-root-password

RDN変更ワークフロー要素では、これらの資格証明を使用して、リモート・サーバーでの内部検索が実行されます。

- --element-name myrdnchangingwfeは、作成しているRDN変更ワークフロー要素の名前を示します。
この構成によって、uid=user.1,ou=people,dc=example,dc=comがcn=User CN,ou=people,dc=example,dc=comに置換されます。

15.1.6.1 RDNリネーム構成の変更

RDNリネームを構成したら、RDNリネームの次のプロパティを変更できます:

- クライアントRDN

- ソースRDN

- 次のワークフロー要素

- オブジェクト・クラス

- DN属性

- 置換値

1. RDNリネームの現行プロパティを表示するには、dsconfig get-workflow-element-propコマンドを使用します。

2. RDNリネームのプロパティを変更するには、dsconfig set-workflow-element-propコマンドを使用します。

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
set-workflow-element-prop \
--element-name myrdnchangingwfe \
--set source-rdn:uid

この例では、source-rdnのみが変更されています。元のsource-rdnを指定する必要はありません。新しいもののみが必要です。

15.1.7 コマンドラインを使用したグローバル索引の構成

グローバル索引では、エントリが特定の分散パーティションにマップされるため、分散トポロジでの検索操作および変更操作が速くなります。グローバル索引では、電話番号など一意の属性に基づいてエントリがマップされます。グローバル索引のリストは、グローバル索引カタログに含まれます。1つのプロキシ・インスタンスに1つ以上のグローバル索引カタログを含めることができます。

注意:

グローバル索引およびグローバル索引カタログを構成および管理するには、リモート・サーバーで特定の制御、特にLDAP読込み前制御およびCSN制御を有効にする必要があります。詳細は、付録B「サポートされている制御および操作」を参照してください。

この項には次のトピックが含まれます:

- 第15.1.7.1項「gicadmを使用したグローバル索引カタログの構成」

- 第15.1.7.2項「グローバル索引カタログのレプリケーション」

- 第15.1.7.3項「グローバル索引カタログに必要な制御のOracle Unified Directoryを使用した構成」

15.1.7.1 gicadmを使用したグローバル索引カタログの構成

グローバル索引カタログは、INSTANCE_DIR/OUD/catalogsにあるBerkeleyデータベースに格納されます。分散トポロジの高可用性を確保するために、グローバル索引カタログのレプリケーションをお薦めします。詳細は、「グローバル索引カタログのレプリケーション」を参照してください。

gicadmコマンドは、次のサーバー・インスタンス・ディレクトリにあります:

- Unixの場合: INSTANCE_DIR/OUD/bin/gicadm

- Windowsの場合: INSTANCE_DIR\OUD\bat\gicadm.bat

詳細は、付録A「gicadm」を参照してください。

この項で示している各プロシージャでは、分散アーキテクチャにプロキシがデプロイされており、デフォルトのプロキシ管理ポート(4444)を使用していることが前提となっています。この項には次のトピックが含まれます:

- 第15.1.7.1.1項「グローバル索引が含まれるグローバル索引カタログを作成するには」

- 第15.1.7.1.2項「グローバル索引カタログのプロパティを表示するには」

- 第15.1.7.1.3項「グローバル索引カタログのプロパティの変更」

- 第15.1.7.1.4項「グローバル索引カタログのプロパティを変更するには」

- 第15.1.7.1.5項「グローバル索引カタログの複数値プロパティを変更するには」

- 第15.1.7.1.6項「グローバル索引カタログのプロパティをデフォルト値にリセットするには」

- 第15.1.7.1.7項「グローバル索引のプロパティを表示するには」

- 第15.1.7.1.8項「グローバル索引カタログにコンテンツをインポートするには」

- 第15.1.7.1.9項「グローバル索引カタログのコンテンツをディレクトリにエクスポートするには」

- 第15.1.7.1.10項「グローバル索引カタログを分散要素に関連付けるには」

- 第15.1.7.1.11項「グローバル索引カタログの分散要素への関連付けを解除するには」

- 第15.1.7.1.12項「グローバル索引カタログにグローバル索引を追加するには」

- 第15.1.7.1.13項「グローバル索引カタログからグローバル索引を削除するには」

15.1.7.1.1 グローバル索引が含まれるグローバル索引カタログを作成するには

グローバル索引を作成するには、次のプロシージャで示しているとおりに、まずグローバル索引カタログを作成する必要があります。このプロシージャでは、グローバル索引カタログの作成、グローバル索引の作成と追加およびグローバル索引へのデータの追加を実行する方法を示しています。必要に応じて、データは後でグローバル索引に追加できます。

開始する前に、プロキシを分散にデプロイしておく必要があります。

1. gicadmコマンドを使用して、グローバル索引カタログを作成します:

$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \
create-catalog --catalogName sampleCatalog

カタログ名は一意である必要があります。

2. 作成したグローバル索引カタログに、少なくとも1つのグローバル索引を作成して追加します。
次のコマンドによって、telephoneNumber属性値で構成されたグローバル索引が作成され、そのグローバル索引が、前の手順で作成したグローバル索引カタログに追加されます。

$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \
add-index --catalogName sampleCatalog --attributeName telephoneNumber

後でadd-indexサブコマンドを使用して、追加のグローバル索引をこのグローバル索引カタログに追加できます。

3. グローバル索引カタログを分散に関連付けます。

$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \
associate --catalogName sampleCatalog \
--distributionWorkflowElement myDistributionName

ワークフロー要素の詳細は、第14.1.8項「dsconfigを使用したワークフロー要素の構成」を参照してください。分散の詳細は、第15.1.4項「dsconfigを使用した分散の構成」を参照してください。

4. split-ldifコマンドを使用して、1つのLDIFファイルから複数のファイルを生成します。
split-ldifコマンドでは、プロキシで構成されている分散アルゴリズムに基づいて、1つのLDIFファイルのコンテンツが、複数のLDIFファイルに分割されます。このコマンドを使用して、グローバル索引にロードするデータを含めるファイルを生成することもできます。ディレクトリ・サービスを開始したときに索引付けする必要があるデータをリモートLDAPサーバーに含める場合は、グローバル索引の初期化時にsplit-ldifを使用する必要があります。ディレクトリにデータを含めない状態で開始する場合は、この手順を省略できます。

split-ldifコマンドの詳細は、このコマンドを使用してグローバル索引に1つまたは複数の索引付き属性を移入する方法の例も含めて、付録A「split-ldif」を参照してください。

5. gicadm importコマンドを使用して、グローバル索引にデータをインポートします。
詳細は、第15.1.7.1.8項「グローバル索引カタログにコンテンツをインポートするには」を参照してください。

15.1.7.1.2 グローバル索引カタログのプロパティを表示するには

グローバル索引カタログのプロパティは、グローバル索引カタログのレプリケーションに関連しています。グローバル索引カタログのプロパティのリストおよびそれらの使用についての説明は、第15.1.7.1.3項「グローバル索引カタログのプロパティの変更」を参照してください。

グローバル索引カタログのすべてのプロパティを表示するには、gicadmコマンドをget-catalog-propサブコマンドとともに使用します。

$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \
get-catalog-prop --catalogName sampleCatalog --property all

出力は、次のようになります。

Property   : Value(s)
-------------------:-------------------------------
replication-server : localhost:3390, localhost:4390
server-id          : 4247
window-size        : 100
heartbeat-interval : 1000
group-id           : 1

グローバル索引カタログの特定のプロパティの値を表示するには、そのプロパティを指定します。

$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \
get-catalog-prop --catalogName sampleCatalog --property heartbeat-interval

15.1.7.1.3 グローバル索引カタログのプロパティの変更

グローバル索引のプロパティは、グローバル索引カタログのレプリケーションに関連しています。使用可能なグローバル索引カタログのプロパティは、次のとおりです:

- replication-server: host:portの形式で、レプリケーション・トポロジ内のサーバーをリストします。このプロパティは、set-catalog-propコマンドで変更してはいけませんが、enable-replicationコマンドでは変更できます。

- server-id: グローバル索引カタログ・レプリケーション・ドメイン内のグローバル索引に一意の識別子を指定します。同一のグローバル索引カタログ・レプリケーション・ドメイン内の各インスタンスに、異なるサーバーIDを指定する必要があります。1つのインスタンスが複数のグローバル索引カタログ・レプリケーション・ドメインのメンバーとなっている場合は、それぞれのグローバル索引カタログ・レプリケーション・ドメイン構成で同じサーバーIDを使用できます。
構文: 1 <= INTEGER <= 65535またはテキスト。このプロパティは変更しないでください。

- window-size: インスタンスがレプリケーション・サーバーとの通信で使用するウィンドウ・サイズを指定します。デフォルト値は100です。
構文: 0 <= INTEGERまたはテキスト。

- heartbeat-interval: インスタンスがレプリケーション・サーバーとの通信で使用するハートビート間隔を指定します。インスタンスは、レプリケーション・サーバーからの、指定した間隔内での定期的なハートビートを予期します。ハートビートをこの間隔内に受信しなかった場合、インスタンスはその接続をクローズして、別のレプリケーション・サーバーに接続します。
構文: 100 ms <= DURATION (ms)

- group-id: 特定のレプリケートされたドメインに関連付けられたID。この値は、レプリケートされたドメインのグループIDを定義します。レプリケーション・システムは、自身のものと同じグループIDのレプリケーション・サーバーに接続して更新を送信し、レプリケートしようとします。
構文: 1 <= INTEGER <= 127

注意:

このプロパティは変更しないでください。

15.1.7.1.4 グローバル索引カタログのプロパティを変更するには

グローバル索引カタログのプロパティのリストは、第15.1.7.1.3項「グローバル索引カタログのプロパティの変更」を参照してください。

gicadmコマンドをset-catalog-propサブコマンドとともに使用します。

$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \
set-catalog-prop --catalogName sampleCatalog --set property:value

たとえば、変更可能なプロパティの1つとして、ハートビート間隔があります。この場合、次のように実行します:

--set heartbeat-interval:500

15.1.7.1.5 グローバル索引カタログの複数値プロパティを変更するには

グローバル索引またはグローバル索引カタログの複数値プロパティの場合、--addオプションまたは--removeオプションを使用して、値を追加または削除できます。

グローバル索引カタログの場合、複数値を含めることができるのは、replication-serverプロパティのみです。グローバル索引の複数値プロパティの場合は、かわりにset-index-propサブコマンドを使用します。

1. 値を追加するには、gicadmコマンドをset-catalog-propサブコマンドとともに使用します。

$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \
set-catalog-prop --catalogName sampleCatalog --add replication-server:hostname

2. 複数値プロパティから値を削除するには、gicadmコマンドをset-catalog-propサブコマンドとともに使用します。

$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \
set-catalog-prop --catalogName sampleCatalog \
--remove replication-server:hostname

15.1.7.1.6 グローバル索引カタログのプロパティをデフォルト値にリセットするには

グローバル索引カタログのいずれかのプロパティを変更して、その後それらの値をデフォルト値にリセットする必要が生じた場合は、次のプロシージャを実行します。

gicadmコマンドをset-catalog-propサブコマンドとともに使用します。

たとえば、ハートビート間隔をリセットする場合は、次のように実行します:

$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \
set-catalog-prop --catalogName sampleCatalog --reset heartbeat-interval

15.1.7.1.7 グローバル索引のプロパティを表示するには

グローバル索引のプロパティを表示するには、gicadmコマンドをget-index-propサブコマンドとともに使用します。

$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \
get-index-prop --catalogName sampleCatalog --attributeName telephoneNumber \
--property all

プロパティは、次のようになります:

Property Names                               : Property Values
---------------------------------------------:---------------------------------
global-index-deleted-entry-retention-timeout : 500
db-cleaner-min-utilization                   : 50
db-log-file-max                              : 10000000
db-checkpointer-bytes-interval               : 20000000
db-checkpointer-wakeup-interval              : 30
db-num-lock-tables                           : -
db-num-cleaner-threads                       : -
db-txn-no-sync                               : false
db-txn-write-no-sync                         : true
je-property                                  : -
db-directory                                 : catalogs
db-directory-permissions                     : 700
global-index-catalogs-shared-cache           : global-index-catalogs-shared-cac
global-index-attribute                       : telephoneNumber

注意:

通常、これらの値は変更できません。

15.1.7.1.8 グローバル索引カタログにコンテンツをインポートするには

特定のファイルのコンテンツを、グローバル索引カタログ内の1つまたは複数のグローバル索引にインポートできます。ファイルのコンテンツのインポート先のカタログの名前を指定する必要があります。オプションでattributeNameパラメータを指定することによって、ファイルのコンテンツを特定の索引に関連するデータにフィルタで抽出できます。

インポート対象のデータ・ファイルは、たとえば、split-ldifコマンドまたはgicadm exportコマンドを実行することによって作成できます。

ファイルのコンテンツをグローバル索引カタログにインポートするには、gicadmコマンドをimportサブコマンドとともに使用します。例:

$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \
import --file /usr/local/import-file --catalogName sampleCatalog

gicadm importタスクの実行中にプロキシ・サーバーが停止すると、グローバル索引カタログ・ワークフロー要素は無効になります。この場合、次のようにdsconfigを使用して、グローバル索引カタログ・ワークフロー要素を再度有効にします。ここで、sampleCatalogはグローバル索引カタログの名前です:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
set-workflow-element-prop --element-name sampleCatalog set enabled:true

15.1.7.1.9 グローバル索引カタログのコンテンツをディレクトリにエクスポートするには

グローバル索引カタログのコンテンツをディレクトリにエクスポートするには、gicadmコマンドをexportサブコマンドとともに使用します。

$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \
export --exportDirectory directory-path --catalogName sampleCatalog

15.1.7.1.10 グローバル索引カタログを分散要素に関連付けるには

グローバル索引カタログを分散要素に関連付けるには、gicadmコマンドをassociateサブコマンドとともに使用します。

$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \
associate --catalogName sampleCatalog --distributionWorkflowElement element-name

グローバル索引カタログを分散ワークフロー要素に関連付けると、グローバル索引カタログが分散のプロパティにリストされるようになります。分散に関連付けるグローバル索引カタログを確認するには、dsconfig get-workflow-element-propコマンドを使用します。ワークフロー要素の詳細は、第14.1.8項「dsconfigを使用したワークフロー要素の構成」を参照してください。

15.1.7.1.11 グローバル索引カタログの分散要素への関連付けを解除するには

グローバル索引カタログの分散トポロジへの関連付けを解除するには、グローバル索引カタログが関連付けられている分散ワークフロー要素を確認する必要があります。対象のグローバル索引カタログを使用している分散ワークフロー要素の名前を確認するには、dsconfig --get-workflow-element-propコマンドを使用して、分散トポロジのプロパティを表示します。

グローバル索引カタログの分散ワークフロー要素への関連付けを解除するには、gicadmコマンドをdisassociateサブコマンドとともに使用します。

$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \
disassociate --distributionWorkflowElement element-Name

15.1.7.1.12 グローバル索引カタログにグローバル索引を追加するには

たとえば新規属性をマップするために、新規グローバル索引を既存のグローバル索引カタログに追加するには、次のプロシージャを使用します。このプロシージャによって、グローバル索引が作成され、グローバル索引カタログに追加されます。グローバル索引カタログには追加することなく、グローバル索引を作成することはできません。

開始する前に、グローバル索引カタログを構成しておく必要があります。

gicadmコマンドをadd-indexサブコマンドとともに使用します。

$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \
add-index --catalogName sampleCatalog --attributeName telephoneNumber

15.1.7.1.13 グローバル索引カタログからグローバル索引を削除するには

gicadmコマンドをremove-indexサブコマンドとともに使用します。

$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \
remove-index --catalogName sampleCatalog --attributeName telephoneNumber

15.1.7.2 グローバル索引カタログのレプリケーション

高可用性を確保するために、グローバル索引カタログをレプリケートする必要があります。標準のハードウェア・ロード・バランサを使用できます。グローバル索引カタログのレプリケーションは、第3.8項「レプリケートされる複数のプロキシ」で示しているように、デプロイメント内で構成できます。

この項には次のトピックが含まれます:

- 第15.1.7.2.1項「レプリケート・トポロジを作成して、グローバル索引カタログのレプリケーションを有効にするには」

- 第15.1.7.2.2項「グローバル索引カタログのレプリケーションを有効にするには」

- 第15.1.7.2.3項「グローバル索引カタログのレプリケーションを初期化するには」

- 第15.1.7.2.4項「グローバル索引カタログのレプリケーションを無効にするには」

- 第15.1.7.2.5項「レプリケートされたグローバル索引カタログ構成のステータスを表示するには」

- 第15.1.7.2.6項「レプリケーション・アクティビティのロギング」

- 第15.1.7.2.7項「レプリケートされたグローバル索引カタログのライフサイクルの例」

15.1.7.2.1 レプリケート・トポロジを作成してグローバル索引カタログのレプリケーションを有効にするには

次の手順に従って、図15-1に示しているように、3つのプロキシ・インスタンスが設定されたレプリケート・トポロジを作成し、グローバル索引カタログのレプリケーションを有効にします。

図15-1 レプリケートされたグローバル索引カタログ

1. サーバー・トポロジに、少なくとも2つのプロキシ・インスタンスをインストールします。
これらのインスタンスは、冗長性のために、個別の物理マシンに配置する必要があります。

2. トポロジ内のプロキシのインスタンスごとに1つのグローバル索引カタログを構成して、1つ以上のグローバル索引を追加します。
gicadmコマンドを使用したグローバル索引カタログの構成の詳細は、第15.1.7.1.1項「グローバル索引が含まれるグローバル索引カタログを作成するには」を参照してください。

3. グローバル索引カタログのレプリケーションを有効にします。
トポロジ全体で、グローバル索引カタログがレプリケートされるプロキシ・インスタンスは、CLI構文においては、localインスタンスと見なされますが、コマンドで宣言されたその他のプロキシ・インスタンスはremoteインスタンスと見なされます。gicadm enable-replicationコマンド実行の詳細は、第15.1.7.2.2項「グローバル索引カタログのレプリケーションを有効にするには」を参照してください。

レプリケート・トポロジに含まれるプロキシごとにこの手順を繰り返します。

4. レプリケーションを初期化するプロキシ・インスタンスを選択します。グローバル索引カタログのコンテンツが最新となっているプロキシ・インスタンスを確認します。
あるいは、トポロジに含まれる各プロキシにLDIFファイルをインポートできます。第15.1.7.1.8項「グローバル索引カタログにコンテンツをインポートするには」を参照してください。

5. 前の手順で選択したプロキシ・インスタンスで、gicadm initialize-replication --allコマンドを実行します。詳細は、第15.1.7.2.3項「グローバル索引カタログのレプリケーションを初期化するには」を参照してください。

注意:

レプリケートされた複数のリモートLDAPサーバーで1つのグローバル索引カタログを使用する際に、書込み操作で同一の値を同時に変更できる上に、その値が索引付けされている場合は、1つのリモートLDAPサーバーのみでそれらの書込み操作を処理する必要があります。このためには、ロード・バランシング・ワークフロー要素の重みを、すべての書込みトラフィックが同一サーバーに送られるように設定できます。詳細は、第15.1.3.5項「ロード・バランシングのプロパティの変更」を参照してください。

15.1.7.2.2 グローバル索引カタログのレプリケーションを有効にするには

このコマンドでは、レプリケーションが構成されますが、レプリケーションの初期化は行われません。このコマンドは、-hオプションによって宣言されたローカル・ホストで、そのローカル・ホストの管理ポートを使用して実行されます。リモート・ホストは、--remoteHostオプションによって宣言されますが、完全修飾ホスト名またはIPアドレスである必要があります。このコマンドによって、バインドIDがadminUIDであるグローバル索引カタログ・レプリケーション管理者が作成されます。

インストール時にグローバル索引カタログを作成した場合は、グローバル索引管理者はすでに作成されており、このパスワードはディレクトリ・マネージャのものと同じです。グローバル索引を使用した分散デプロイメントのインストールの詳細は、Oracle Fusion Middleware Oracle Unified Directoryインストレーション・ガイドの単純な分散の構成に関する項を参照してください。

グローバル索引カタログのレプリケーションを有効にするには、gicadm enable-replicationコマンドを使用します。

$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \
enable-replication --catalogName sampleCatalog --adminUID adminUID
--localReplicationPort 8989 --remoteReplicationPort 8989 \
--remoteAdminPort 4444 --remoteHost host

このコマンドによって、ローカル・ホスト上のsampleCatalogというグローバル索引カタログのコンテンツをレプリケートするようプロキシ構成が更新されます。トポロジ内のいずれかのプロキシ・インスタンスですでにグローバル索引カタログがレプリケートされている場合、このコマンドによってトポロジ内のその他すべてのプロキシ・インスタンスの構成が更新されます。このため、トポロジ内の最初の2つのプロキシ・インスタンスに対してgicadm enable-replicationを実行した後は、トポロジを拡張するために追加される新規プロキシ・インスタンスごとにこのコマンドを1回実行すれば十分です。

このコマンドを実行するプロキシ・インスタンスのレプリケーション・ポートを--localReplicationPortオプションで宣言しておく必要があります。このローカル・インスタンスのグローバル索引カタログが、後でgicadm initialize-replicationコマンドによってトポロジ全体にレプリケートされることになります。--remoteReplicationPortオプションによって、sampleCatalogというグローバル索引カタログのコンテンツが、このローカル・インスタンスからリモート・インスタンスにレプリケートされます。--remoteAdminPortは、リモート・プロキシ・インスタンスの管理ポートです。

ファイルに格納されている、ローカル・プロキシ・インスタンスのパスワードを--adminPasswordFileサブオプションを使用して宣言できます。

オプションで、--remoteBindDNサブオプションを使用してリモート・サーバーへのバインドのためのDNを、および--remoteBindPasswordFileサブオプションを使用してファイル内の、リモート・プロキシ・インスタンスのパスワードを宣言できます。これらを宣言しないと、--adminUIDによって宣言されたグローバル管理者がバインドに使用されます。

またオプションで、--localSecureReplicationサブオプションを使用してローカル・サーバーのレプリケーションポートを通した通信、および--remoteSecureReplicationサブオプションを使用してリモート・サーバーのレプリケーション・ポートを通した通信のセキュリティの確保を必須とすることもできます。

15.1.7.2.3 グローバル索引カタログのレプリケーションを初期化するには

このコマンドによって、-hオプションによって宣言されたサーバー上のプロキシ・インスタンスから、トポロジに含まれるすべてのインスタンスへのsampleCatalogというグローバル索引カタログのコンテンツが初期化されます。指定するポートは管理ポートであり、レプリケーション・ポートではありません。

1. レプリケーション・トポロジに含まれるすべてのプロキシ・インスタンスへのグローバル索引カタログのレプリケーションを初期化するには、次のように、gicadm initialize-replication --allを使用します:

$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \
initialize-replication --catalogName sampleCatalog \
--adminUID adminUID --all

2. gicadm status-replicationコマンドを使用して、レプリケーションが完了したことを確認します。
レプリケーションが完了していない場合は、トポロジ内のすべてのプロキシ・インスタンスのステータスがrunning replicatedとなっています。

たとえばパッチを適用した後に、トポロジ内のプロキシ・インスタンスを再起動する前に、レプリケーションが完了している必要があります。

gicadm status-replicationコマンド使用の詳細は、第15.1.7.2.5項「レプリケートされたグローバル索引カタログ構成のステータスを表示するには」を参照してください。

15.1.7.2.4 グローバル索引カタログのレプリケーションを無効にするには

グローバル索引カタログのレプリケーションを無効にするには、gicadm disable-replicationコマンドを使用します。

$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \
disable-replication --catalogName sampleCatalog --adminUID adminUID

gicadm disable-replicationコマンドは、トポロジ内の、レプリケーションを無効にするプロキシ・インスタンスごとに実行する必要があります。

15.1.7.2.5 レプリケートされたグローバル索引カタログ構成のステータスを表示するには

レプリケートされたグローバル索引カタログの基本構成情報を表示するには、gicadm status-replicationコマンドを使用します。

$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \
status-replication --catalogName sampleCatalog --adminUID adminUID

カタログ名を宣言しないと、レプリケートされたすべてのグローバル索引カタログのステータス情報が表示されます。

15.1.7.2.6 レプリケーション・アクティビティのロギング

レプリケーション・ログは、レプリケーション修復ログに格納されます。変更は変更ログに記録されます。これらのログへのアクセスの詳細は、第29.5.4項「ログへのアクセス」を参照してください。

グローバル索引カタログをレプリケートする場合は、変更ログ用のディスク領域をプロビジョニングしてください。デフォルトで、これらのログには変更が24時間格納されます。300,000回の書込み操作に、訳100MBが必要です。デフォルト値の24時間では、その期間に予期されるサービスのサイズに基づいてログを構成する必要があります。ヒントとして、24時間で1秒当たり5000回の変更につき約150GBのプロビジョニングが考えられます。ログを構成する方法の詳細は、第29.3項「ログの構成」を参照してください。

15.1.7.2.7 レプリケートされたグローバル索引カタログのライフサイクルの例

この項では、レプリケーション・トポロジでイベントが発生した場合の典型的なライフサイクルの例をいくつか示します。これらすべての例で使用している基本のレプリケーション・トポロジは、第15.1.7.2.1項「レプリケート・トポロジを作成して、グローバル索引カタログのレプリケーションを有効にするには」で作成したものです。

例15-2 レプリケート・トポロジでグローバル索引カタログを再起動するには

図15-2で示している例では、3つのプロキシ・インスタンスが、レプリケートされたグローバル索引カタログを指定して実行されています。プロキシ・インスタンス3がなんらかの理由でダウンするか停止した場合、次の手順に従って、3つのプロキシ・インスタンスがレプリケートされていることを確認します。

1. プロキシ・インスタンス3で、start-dsコマンドを発行します。

2. 第15.1.7.2.5項「レプリケートされたグローバル索引カタログ構成のステータスを表示するには」に示されているように、gicadm status-replicationコマンドを実行することによって、レプリケーションが完了しているかどうかを確認できます。

図15-2 グローバル索引カタログの再起動

例15-3 レプリケートされたグローバル索引カタログ・トポロジへのグローバル索引の追加

図15-3で示している例では、3つのプロキシ・インスタンスが、レプリケートされたグローバル索引カタログを指定して実行されています。レプリケートされたグローバル索引カタログに、追加の属性(たとえば、mail)を追加するには、次の手順に従います。

1. まず、3つのプロキシ・インスタンスそれぞれで、gicadm add-index mailコマンドを実行します。

2. 分散ルートの下のディレクトリ・データをいずれかのリモートLDAPサーバーからfile1という名前のLDIFファイルに、export-ldifを使用してエクスポートします。

3. split-ldifを実行して、指定したディレクトリにGICコンテンツを生成します。

4. プロキシ・インスタンス1で、コマンドgicadm import --importDirectory directory-nameを実行します。

5. プロキシ・インスタンス1で、gicadm initialize-replication --allコマンドを実行します。このコマンドによって、変更が、プロキシ1からトポロジ内のその他すべてのプロキシにプッシュされ、新規グローバル索引が追加されます。

図15-3 レプリケートされたグローバル索引カタログ・トポロジへのグローバル索引の追加

例15-4 レプリケートされたグローバル索引カタログのコンテンツの上書き

図15-4で示している例では、3つのプロキシ・インスタンスが、レプリケートされたグローバル索引カタログを指定して実行されています。プロキシ・インスタンス2および3のグローバル索引カタログのコンテンツをインスタンス1のグローバル索引カタログのコンテンツで上書きするには、次の手順に従います。

1. プロキシ・インスタンス1で、gicadm initialize-replication --allコマンドを実行します。これによってプロキシ・インスタンス2および3のグローバル索引カタログのコンテンツが、プロキシ・インスタンス1のグローバル索引カタログのコンテンツに置き換わります。

図15-4 レプリケートされたグローバル索引カタログのコンテンツの上書き

例15-5 レプリケート・トポロジへのプロキシの追加

図15-5で示している例では、3つのプロキシ・インスタンスが、レプリケートされたグローバル索引カタログを指定して実行されています。レプリケートされたグローバル索引カタログが指定された4つ目のプロキシ・インスタンスを追加するには、その新規プロキシ・インスタンスについて次の手順を実行します。

1. 新規のプロキシ・インスタンス4で、gicadm create-catalogコマンドを実行します。

2. コマンドgicadm add-index cn、gicadm add-index snおよびgicadm add-index mailを実行します。

3. gicadm associateコマンドを実行します。

4. 次のコマンドを実行します:

gicadm enable-replication --localReplicationPort replication port of instance 4 --remoteHost name or IP address of host running instance 1

このコマンドによって、インスタンス1からインスタンス4までのレプリケーションが構成されます。

5. initialize replication --from proxy 1コマンドを実行します。

図15-5 レプリケート・トポロジへのプロキシの追加

15.1.7.3 グローバル索引カタログに必要な制御のOracle Unified Directoryを使用した構成

Oracle Unified Directoryディレクトリ・サーバーをLDAPデータ・ソースとして指定してプロキシ・サーバーを使用する場合、プロキシ・サーバーとディレクトリ・サーバーとの間の接続をディレクトリ・サーバーの管理IDを使用してバインドする必要があります。そうしない場合は、グローバル索引カタログが正常に機能できるようにディレクトリ・サーバーに一定の構成が必要です。

制御のグローバルACIが変更されていない場合は、ldapmodifyコマンドを使用して、次の変更をディレクトリ・サーバーに適用します:

dn: cn=Access Control Handler,cn=config
changetype: modify
add: ds-cfg-global-aci
ds-cfg-global-aci:
(targetcontrol="2.16.840.1.113730.3.4.2 || 2.16.840.1.113730.3.4.17 |
| 2.16.840.1.113730.3.4.19 || 1.3.6.1.4.1.4203.1.10.2 || 1.3.6.1.4.1.42.2.27.8.5.1 |
| 2.16.840.1.113730.3.4.16 || 1.3.6.1.1.13.1 || 1.3.6.1.4.1.42.2.27.9.5.9")
(version 3.0; acl "Anonymous control access"; allow(read) userdn="ldap:///anyone";)
ds-cfg-global-aci: (targetattr="createTimestamp||creatorsName||modifiersName|
|modifyTimestamp||entryDN||entryUUID||subschemaSubentry||aclRights||aclRightsInfo")
(version 3.0; acl "User-Visible Operational Attributes"; allow (read,search,compare)
userdn="ldap:///anyone";)

Oracle Unified Directory 11g R1ディレクトリ・インスタンスからACIを削除するには、次のACIを削除する必要があります:

dn: cn=Access Control Handler,cn=config
changetype: modify
delete: ds-cfg-global-aci
ds-cfg-global-aci: (targetcontrol="2.16.840.1.113730.3.4.2 || 2.16.840.1.113730.3.4.17 || 2.16.840.1.113730.3.4.19 || 1.3.6.1.4.1.4203.1.10.2 || 1.3.6.1.4.1.42.2.27.8.5.1 || 2.16.840.1.113730.3.4.16") (version 3.0; acl "Anonymous control access"; allow(read) userdn="ldap:///anyone";)
ds-cfg-global-aci: (targetattr="createTimestamp||creatorsName||modifiersName||modifyTimestamp||entryDN||entryUUID||subschemaSubentry")(version 3.0; acl "User-Visible Operational Attributes"; allow (read,search,compare) userdn="ldap:///anyone";)

Oracle Unified Directory 11g R2ディレクトリ・インスタンスからACIを削除するには、次のACIを削除する必要があります:

dn: cn=Access Control Handler,cn=config
changetype: modify
delete: ds-cfg-global-aci
ds-cfg-global-aci: (targetcontrol="2.16.840.1.113730.3.4.2 || 2.16.840.1.113730.3.4.17 || 2.16.840.1.113730.3.4.19 || 1.3.6.1.4.1.4203.1.10.2 || 1.3.6.1.4.1.42.2.27.8.5.1 || 2.16.840.1.113730.3.4.16 || 2.16.840.1.113894.1.8.31") (version 3.0; acl "Anonymous control access"; allow(read) userdn="ldap:///anyone";)

前述のコマンドで指定されているOIDは、Oracle Unified Directoryの未変更の構成に適しています。デフォルトのOIDが変更されている場合は、適切なOIDを含めるようコマンドを変更します。

グローバル索引カタログには次の制御が必要です:

- 読込み前制御、OID = 1.3.6.1.1.13.1

- CSN制御、OID = 1.3.6.1.4.1.42.2.27.9.5.9

15.1.8 Microsoft Active Directoryページングの構成

複数値属性のコンテンツの取得で、多数の値が返されることになる場合があります。Microsoft Active Directoryサーバーでは、1回の問合せで取得できる属性値の最大数が制限されます。

Microsoft Active Directoryでは、複数値属性のすべての値を取得できる範囲取得メカニズムを使用できます。このメカニズムでは、検索リクエストで、値のクライアント指定のサブセットを取得できます。複数の検索リクエストを実行し、各リクエストで個別のサブセットを取得することによって、属性の完全な値セットを取得できます。

Oracle Unified Directoryは、Microsoft Active Directoryページングのサポートを提供することによって、Active Directoryの範囲取得に対応します。Microsoft Active Directoryページングの主な目的は、返された属性のオプションの中に範囲オプションがあるかどうかを検出すること、およびMicrosoft Active Directoryサーバーから完全な範囲の属性値を取得することです。この完全な属性値セットが返されると、クライアント・アプリケーションでは範囲オプションを処理する必要がなくなります。

Microsoft Active Directoryページングは、ワークフロー要素チェーンのリーフがActive Directoryサーバーに接続されている場合にのみ関連するワークフロー要素として実装されます。Active Directoryページング・ワークフロー要素の次のプロパティを構成できます:

- チェーン内の次のワークフロー要素(このワークフロー要素はリーフ・ワークフロー要素ではないため)

- 範囲オプションを検出するための属性のスキャン処理を軽減できるオプションの属性リスト

15.1.8.1 Active Directoryページング・ワークフロー要素の構成

Microsoft Active Directoryページングのサポートを構成するには、LDAPプロキシ・ワークフロー要素を指すActive Directoryページング・ワークフロー要素を作成して有効にします。

次の例では、LDAPプロキシ・ワークフローproxy-we1を指すad-paging-we1という名前のActive Directoryページング・ワークフロー要素が作成されます。

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
create-workflow-element --element-name ad-paging-we1 --type ad-paging \
--set next-workflow-element:proxy-we1 --set enabled:true

15.1.8.2 Active Directoryから返される特定の属性のスキャン

効率性を高めるために、ワークフロー要素のhandled-attributes複数値プロパティを設定することによって特定の属性のみがスキャンされるようActive Directoryページング・ワークフロー要素を構成できます。このプロパティの値は必要な数だけ追加できます。

デフォルトで、すべての属性がスキャンされます。これは、パフォーマンスに直接影響を与える可能性があります。パフォーマンスの影響を軽減するために、handled-attributesプロパティの値としてスキャンする必要のある属性のみをリストします。

次の例では、memberOf属性のみがスキャンされるように、前の例で作成したワークフロー要素が変更されています:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
set-workflow-element-prop --element-name ad-paging-we1 \
--set handled-attributes:memberOf

15.2 ODSMを使用したプロキシ構成の管理

この項では、Oracle Directory Services Managerを使用して管理できるプロキシ・サーバー構成の要素について説明します。この項の内容は次のとおりです:

- 第15.2.1項「ODSMを使用したロード・バランシングの構成」

- 第15.2.2項「ODSMを使用した分散の構成」

- 第15.2.3項「ODSMを使用したワークフローのクリティカル度の構成」

- 第15.2.4項「ODSMを使用した変換の構成」

15.2.1 ODSMを使用したロード・バランシングの構成

ロード・バランシングまたは分散を構成せずにプロキシ・サーバー・インスタンスを設定した場合は、ODSMを使用してロード・バランシングを構成できます。開始する前に、ロード・バランシング・デプロイメントを構成しているコンポーネントについて理解しておくと便利です。詳細は、第3.2項「構成1: 単純なロード・バランシング」を参照してください。

ODSMを使用してロード・バランシングを構成するには、次の手順を実行します:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」で示しているように、ODSMからプロキシ・サーバーに接続します。

2. 「ホーム」タブを選択します。

3. 「構成」項目の「ロード・バランサの設定」を選択します。

4. 「ロード・バランシング: バックエンド・サーバー」画面で、次の情報を入力します:

- 「ロード・バランシング名」フィールドに、このロード・バランシング・ワークフロー要素の名前を入力します。

- 「追加」をクリックして、クライアント・リクエストのロード・バランシング対象とする少なくとも2つのレプリケート済バックエンドLDAPサーバーの接続詳細を入力します。
ODSMでは、アクセス可能かどうかを確認するために、これらのバックエンドLDAPサーバーへの接続が試行されます。接続試行が失敗した場合、それでもそのサーバー詳細を使用するか、それとも接続詳細を確認するかを尋ねるプロンプトが表示されます。

5. すべてのバックエンドLDAPサーバーを追加したら、「次へ」をクリックして続行します。

6. 「ロード・バランシング: オプション」画面で、次の情報を入力します:

- 「ロード・バランシング・アルゴリズム」を選択します。

- 選択したロード・バランシング・アルゴリズムに応じて、各バックエンドLDAPサーバーの関連する重みまたは優先度を指定します。

ロード・バランシング・アルゴリズムの詳細は、第11.1項「プロキシを使用したロード・バランシング」を参照してください。

7. ロード・バランシングのオプションを指定したら、「次」をクリックして続行します。

8. 「ロード・バランシング: ネーミング・コンテキスト」画面で、「追加」をクリックして、対象のプロキシ・インスタンスで対応する少なくとも1つのネーミング・コンテキスト、つまり接尾辞を指定します。

9. 必要なネーミング・コンテキストをすべて追加したら、「次」をクリックして続行します。

10. 「ロード・バランシング設定: サマリー」画面で、ロード・バランシング構成を確認し、「終了」をクリックして構成を完了します。

ロード・バランシングを構成した後は、ODSMの「構成」タブで構成の任意の側面を変更できます。

15.2.2 ODSMを使用した分散の構成

ロード・バランシングまたは分散を構成せずにプロキシ・サーバー・インスタンスを設定した場合は、ODSMを使用して分散を構成できます。開始する前に、分散デプロイメントを構成しているコンポーネントについて理解しておくと便利です。詳細は、第3.3項「構成2: 単純な分散」を参照してください。

ODSMを使用して分散を構成するには、次の手順を実行します:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」で示しているように、ODSMからプロキシ・サーバーに接続します。

2. 「ホーム」タブを選択します。

3. 「構成」項目の「ディストリビュータの設定」を選択します。

4. 「分散: データのパーティション化」画面で、次の情報を入力します:

- 「パーティション数」を選択します。

- 「分散アルゴリズム」を選択します。使用可能な分散アルゴリズムの詳細は、第11.2項「プロキシを使用したデータ分散」を参照してください。

- この分散デプロイメントで対応する「ネーミング・コンテキスト」、つまり接尾辞を入力します。

- 分散を構成する「ネットワーク・グループ」を選択します。

- 選択した分散アルゴリズムに応じて、各パーティションの容量、DNパターンまたは境界を入力します。

5. すべてのパーティション詳細を入力したら、「次」をクリックして続行します。

6. 「分散: サーバー・パーティション」で、パーティションごとに「追加」をクリックして、パーティション化されたデータを保持する各バックエンドLDAPサーバーの接続詳細を入力します。
ODSMでは、アクセス可能かどうかを確認するために、これらのバックエンドLDAPサーバーへの接続が試行されます。接続試行が失敗した場合、それでもそのサーバー詳細を使用するか、それとも接続詳細を確認するかを尋ねるプロンプトが表示されます。

7. 必要なサーバーについてすべて追加したら、「次」をクリックして続行します。

8. 「分散: グローバル索引」画面で、グローバル索引の詳細を指定します。グローバル索引の詳細は、第11.3項「グローバル索引カタログ」を参照してください。

9. グローバル索引を構成したら、「次」をクリックして続行します。

10. 「分散: サマリー」画面で、分散構成を確認し、「終了」をクリックして構成を完了します。

分散を構成した後は、ODSMの「構成」タブで構成の任意の側面を変更できます。

15.2.3 ODSMを使用したワークフローのクリティカル度の構成

クリティカル度フラグという新規のパラメータを追加して、ワークフローを構成します。デフォルトで、クリティカル度フラグはTrueに設定されます。

次の項では、ODSMを使用してワークフローのクリティカル度を構成する方法を説明します。dsconfigを使用したクリティカル度の構成の詳細は、第15.1.4.6項「ワークフローのクリティカル度の構成」を参照してください。

ODSMを使用してワークフローのクリティカル度を構成するには、次の手順を実行します:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」で示しているように、ODSMからプロキシ・サーバーに接続します。

2. 「構成」タブを選択します。

3. 「コア構成」ビューを選択します。

4. 「ワークフロー」要素で、クリティカル度フラグを設定する、目的のワークフローを選択します。

5. ワークフローに設定するクリティカル度の値(True、FalseまたはPartial)を選択します。たとえば、選択したワークフロー要素にクリティカル度を設定するには、「True」をクリックします。

図15-6 クリティカル度フラグ

15.2.4 ODSMを使用した変換の構成

ODSMを使用して、Oracle Unified Directoryプロキシ・サーバーの変換ワークフロー要素の作成、変更および削除を実行できます。変換ワークフロー要素の詳細は、第14.2.4項「ODSMを使用したワークフロー要素の構成」を参照してください。

次の各項で、ODSMを使用して変換を構成する方法を説明します。dsconfigを使用した変換の構成の詳細は、第11.6.3.2項「CLIを使用した変換の構成例」を参照してください。

この項には次のトピックが含まれます:

- 第15.2.4.1項「変換の作成」

- 第15.2.4.2項「変換の変更」

- 第15.2.4.3項「変換の削除」

- 第15.2.4.4項「値定義画面からの値の選択」

15.2.4.1 変換の作成

Oracle Unified Directoryプロキシ・サーバーに接続している場合、ODSMを使用して5つの異なるタイプの変換を作成できます。サポートされている変換タイプの詳細は、第11.6.2.1項「変換のタイプ」を参照してください。

注意:

Oracle Unified Directoryサーバー・インスタンスに接続している場合、変換機能はプロキシ・サーバーでしかサポートされていないため、新規変換を作成するオプションは用意されません。

ODSMを使用して変換を作成するには、次の手順に従います:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「構成」タブを選択します。

3. 「コア構成」ビューを選択します。

4. 「作成」メニューから、「変換」を選択します。

5. 「変換」サブメニューから、必要な変換タイプを選択します。

図15-7 変換タイプ

この例では、「アウトバウンド属性追加」変換タイプの次のプロパティを取り上げます。

注意:

変換の作成時に表示されるプロパティは、作成している変換のタイプによって異なります。各変換タイプおよび関連プロパティの詳細は、第11.6.2.1項「変換のタイプ」を参照してください。

6. 「名前」フィールドに、変換の名前を入力します。

7. 「条件」リージョンで、次の情報を入力します:

注意:

条件はオプションです。ただし、ここで変換レベルで指定するランタイム条件は、変換が使用される変換ワークフロー要素に変換ワークフロー要素レベルで指定される条件と組み合せて使用されます。変換ワークフロー要素の詳細は、第14.2.4項「ODSMを使用したワークフロー要素の構成」を参照してください。

1. 「フィルタに一致するエントリ」フィールドに、有効なLDAPフィルタを入力します。

2. 「エントリ親接尾辞」ボックスで、「追加」をクリックして、祖先にする必要のあるDNを指定します。
エントリを選択するには、「選択」をクリックします。

「エントリ・ピッカー」ウィンドウで、「ツリー・ビュー」を選択してディレクトリ・ツリーに移動し、対象のエントリを見つけるか、「検索ビュー」を選択して対象のエントリを検索します。

3. 「除外された操作」リストから、除外する操作を選択します。

8. 「変換定義」リージョンで、次の情報を入力します:

1. 「クライアント属性」フィールドに、クライアント仮想属性の名前を入力します。
クライアント属性エントリを選択するには、「選択」をクリックします。

「属性ピッカー」ウィンドウで、目的のエントリを見つけて選択するか、または「検索」をクリックして目的のエントリを検索します。

2. 「値定義」ボックスで、「追加」をクリックして、クライアント仮想属性の値定義を指定します。
「定義」をクリックして、適切な値定義を入力します。値定義の指定の詳細は、第15.2.4.4項「値定義画面からの値の選択」を参照してください。

9. 「競合動作」リストから、必要な競合動作ポリシーを選択します。

10. 「ソース内の仮想」をクリックして、「はい」に設定します。

11. 「作成」をクリックします。

15.2.4.2 変換の変更

この項では、変換のプロパティを変更する方法を説明します。この例では、第15.2.4.1項「変換の作成」で作成した「アウトバウンド属性追加」変換タイプのプロパティを変更します。

変換を変更するには、次の手順を実行します:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「構成」タブを選択します。

3. 「コア構成」ビューを選択します。

4. 「変換」要素を開きます。

5. 目的の変換をクリックします。
変更処理を実行できるように、右側のペインに変換構成の詳細が表示されます。

6. 必要な情報を変更します。

7. 「適用」をクリックします。

15.2.4.3 変換の削除

変換を削除するには、次の手順を実行します:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「構成」タブを選択します。

3. 「コア構成」ビューを選択します。

4. 「変換」要素を開きます。

5. 削除する変換を選択します。
削除する前に確認を求める「構成の削除」ウィンドウが表示されます。

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

15.2.4.4 値定義画面からの値の選択

値定義ビルダー・サブ画面を使用すると、変換によって追加、マップまたは削除される属性の値を定義できます。

次の値を指定できます:

- 定数値: 定数値の入力に使用します。

- 別の属性の値: 処理対象のエントリの既存の属性から新規属性を作成する場合、または別の属性から値をフィルタ処理して取得する場合に使用します。

- 式の値: 1つ以上の既存の属性の特定の値を操作ることによって、属性値を作成するまたは属性値をフィルタ処理する場合に使用します。

図15-8は、「値定義」画面を示しています。

図15-8 「値定義」画面

16 プロキシ構成の例

この章では、dsconfigコマンドを使用して、特定のプロキシ・デプロイメントを構成する方法を示します。対話モードで構成を実行することもできます。詳細は、第14.1.2項「対話型モードでのdsconfigの使用」を参照してください。

この章には、次の例が含まれます:

- 第16.1項「ロード・バランシングの構成」

- 第16.2項「分散の構成」

- 第16.3項「分散およびロード・バランシングの構成」

- 第16.4項「データ・センター間のフェイルオーバーの構成」

- 第16.5項「データ・センター間のフェイルオーバーを使用した分散の構成」

16.1 ロード・バランシングの構成

単純なロード・バランシングを使用したデプロイメントの設定に必要な様々な要素すべてを定義するための、手順を追ったプロシージャを次に示しています。次の例は、2つのLDAPサーバーのフェイルオーバーを使用したロード・バランシングを示しています。使用可能な様々なタイプのロード・バランシングの詳細は、第11.1項「プロキシを使用したロード・バランシング」を参照してください。

次の図は、単純なロード・バランシングにプロキシ・サーバーを構成する場合に作成する必要のあるオブジェクトを示しています。これらのオブジェクトを、示された順序で作成する必要があります。

図16-1 ロード・バランシング

このプロシージャで使用するすべてのコマンドで、プロキシ・ホスト名(-h)、プロキシ管理ポート(-p)、初期ルート・ユーザーのバインドDN(-D)およびプロキシ・パスワードが含まれるファイル(-j)が指定されます。また、認証も指定する必要があります。クライアントとサーバーが同一インスタンスで実行されている場合に認証を指定しないと、ローカル認証構成が使用されます。

16.1.1 単純なロード・バランシングを構成するには

1. プロキシLDAPサーバー拡張を作成します。

$ dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file \
create-extension \
--extension-name proxy_extension1 \
--type ldap-server \
--set enabled:true \
--set remote-ldap-server-address:DS1_hostname \
--set remote-ldap-server-port:2389

LDAPサーバー拡張は、リモートLDAPサーバーへのリンクです。このユースケースでは、少なくとも2つのリモートLDAPサーバー・インスタンスが必要です。異なるLDAPホスト名およびポートを使用して、この手順を再度実行してください。

2. 各LDAPサーバー拡張にプロキシ・ワークフロー要素を作成します。

$ dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file \
create-workflow-element \
--element-name proxy-we1 \
--type proxy-ldap\
--set enabled:true \
--set client-cred-mode:use-client-identity \
--set ldap-server-extension:proxy_extension1

プロパティclient-cred-modeは、プロキシとリモートLDAPサーバーとの間で使用される認証のタイプを示します。クライアント資格証明モードは、use-client-identityまたはuse-specific-identityです。

3. ロード・バランシング・ワークフロー要素を作成します。

$ dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file \
create-workflow-element \
--element-name LB-we1 \
--type load-balancing \
--set enabled:true

2つのリモートLDAPサーバーのいずれかにリクエストをルーティングするために、ロード・バランシング・ワークフロー要素が1つのみ必要です。

4. ロード・バランシング・アルゴリズムを定義します。

$ dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file \
create-load-balancing-algorithm \
--element-name LB-we1 \
--type failover

ロード・バランシング・アルゴリズムのタイプは、proportional、saturation、optimal、searchfilterまたはfailoverです。ロード・バランシング・アルゴリズムのプロパティ(重み、しきい値または優先度)は、次の手順で、ロード・バランシング・ルートを使用して定義されます。

5. 各プロキシにロード・バランシング・ルートを定義します。

$ dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file \
create-load-balancing-route \
--element-name LB-we1 \
--route-name LB-route1 \
--type failover \
--set workflow-element:proxy-we1 \
--set add-priority:1 \
--set bind-priority:2 \
--set compare-priority:2 \
--set delete-priority:1 \
--set extended-priority:2 \
--set modify-priority:1 \
--set modifydn-priority:1 \
--set search-priority:2

ルートを定義する際は、必ずロード・バランシング・アルゴリズムを定義したときと同じタイプを指定してください。

このユースケースでは、2つのロード・バランシング・ルートが必要です。ルートごとに異なる優先度を指定して、この手順を再度実行してください。

前述の例のプロパティでは、フェイルオーバー・ロード・バランシングの優先度が設定されています。比例または飽和のロード・バランシングを使用する場合、プロパティは異なります。様々なロード・バランシング・タイプの設定の詳細は、第15.1.3.5項「ロード・バランシングのプロパティの変更」を参照してください。

6. ワークフローを作成します。
このワークフローによって、ロード・バランシング・ワークフロー要素が、指定したベースDNに関連付けられます。

$ dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file \
create-workflow \
--workflow-name LB-workflow1 \
--set enabled:true \
--set base-dn:dc=example,dc=com \
--set workflow-element:LB-we1

7. ネットワーク・グループを作成します。
このネットワーク・グループでは、クライアントとプロキシの間のすべてのリクエストが処理されます。

$ dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file \
create-network-group \
--group-name network-group1 \
--set enabled:true \
--set workflow:LB-workflow1 \
--set priority:1

16.2 分散の構成

次のプロシージャは、単純な分散デプロイメントの設定に必要な要素を示しています。例では、2つのパーティションに分割された分散が示されています。サポートされている分散タイプの詳細は、第11.2項「プロキシを使用したデータ分散」を参照してください。

次の図は、単純な分散にプロキシ・サーバーを構成する場合に作成する必要のあるオブジェクトを示しています。これらのオブジェクトを、示された順序で作成する必要があります。

図16-2 分散の構成

このプロシージャで使用するすべてのコマンドで、プロキシ・ホスト名(-h)、プロキシ管理ポート(-p)、初期ルート・ユーザーのバインドDN(-D)および構成対象のプロキシ・パスワード(-w)が指定されます。また、認証も指定する必要があります。クライアントとサーバーが同一インスタンスで実行されている場合に認証を指定しないと、ローカル認証構成が使用されます。

16.2.1 単純な分散を構成するには

1. プロキシLDAPサーバー拡張を作成します。

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \
create-extension \
--extension-name proxy_extension1 \
--type ldap-server \
--set enabled:true \
--set remote-ldap-server-address:DS1_hostname \
--set remote-ldap-server-port:2389

LDAPサーバー拡張は、リモートLDAPサーバーへのリンクです。このユースケースでは、2つのリモートLDAPサーバー・インスタンスが必要になります。異なるLDAPホスト名およびポートを使用して、この手順を再度実行してください。

2. 各LDAPサーバー拡張にプロキシ・ワークフロー要素を作成します。

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \
create-workflow-element \
--element-name proxy-we1 \
--type proxy-ldap\
--set enabled:true \
--set client-cred-mode:use-client-identity \
--set ldap-server-extension:proxy_extension1

1つの分散アーキテクチャに少なくとも2つのリモートLDAPサーバーが必要です。この手順を再度実行します。LDAPサーバー拡張名は、手順1で作成したものと同じにする必要があります。

プロパティclient-cred-modeは、プロキシとリモートLDAPサーバーとの間で使用される認証のタイプを示します。クライアント資格証明モードは、use-client-identityまたはuse-specific-identityです。

3. 分散ワークフロー要素を作成して、分散を設定します。

$ dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file \
create-workflow-element \
--element-name distrib-we \
--type distribution \
--set base-dn:dc=example,dc=com \
--set enabled:true

4. 分散アルゴリズムを設定します。

$ dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file \
create-distribution-algorithm \
--element-name distrib-we \
--type numeric \
--set distribution-attribute:uid

分散アルゴリズムのタイプは、capacity、numeric、lexicoまたはdnpatternです。アルゴリズムのプロパティは、次の手順で分散パーティションを作成するときに定義されます。

5. 分散パーティションを定義します。

$ dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file \
create-distribution-partition \
--element-name distrib-we \
--partition-name distrib-part1\
--type numeric \
--set lower-bound:0 \
--set upper-bound:1000 \
--set partition-id:1 \
--set workflow-element:proxy-we1

このユースケースでは、2つのパーティションを作成する必要があります。ワークフロー要素ごとに、パーティションIDおよびパーティション名を一意にする必要があります。分散アルゴリズムを定義したときと同じタイプをパーティションを定義するときにも指定する必要があります。

注意:

指定される上限値自体は含まれません。つまり、上限として1000を指定すると、パーティションには0から999までの値のみが含まれることになります。

グローバル索引を作成するには

定義した分散アルゴリズムのタイプに応じて、グローバル索引を作成する必要があります。容量アルゴリズムを作成した場合は、グローバル索引を作成する必要があります。

辞書編集、数値およびDNパターンの場合は、グローバル索引はオプションです。

次の手順を実行して、グローバル索引を作成します:

1. グローバル索引カタログを作成します。

$ gicadm -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file \
create-catalog \
--catalogName gi-catalog

2. DN属性を索引付けするグローバル索引をカタログに追加します。

$ gicadm -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file \
add-index \
--catalogName gi-catalog \
--attributeName dn

3. グローバル索引カタログを分散に関連付けます。

$ gicadm -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file \
associate \
--catalogName gi-catalog \
--distributionWorkflowElement distrib-we

6. ワークフローを作成します。
このワークフローによって、分散ワークフロー要素が分散パーティションに関連付けられます。

$ dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file \
create-workflow \
--workflow-name distrib-workflow \
--set enabled:true \
--set base-dn:dc=example,dc=com \
--set workflow-element:distrib-we

7. ネットワーク・グループを作成します。
このネットワーク・グループでは、クライアントとプロキシの間のすべてのリクエストが処理されます。

$ dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file \
create-network-group \
--group-name network-group1 \
--set enabled:true \
--set workflow:distrib-workflow \
--set priority:1

16.3 分散およびロード・バランシングの構成

このユースケースでは、分散とロード・バランシングが組み合されます。すべての分散デプロイメントについて、グローバル索引を追加できますが、これはここでは含まれていません。グローバル索引の作成の詳細は、第15.1.7項「コマンドラインを使用したグローバル索引の構成」を参照してください。

次の図は、分散とロード・バランシングにプロキシ・サーバーを構成する場合に作成する必要のあるオブジェクトを示しています。これらのオブジェクトを、示された順序で作成する必要があります。

図16-3 分散およびロード・バランシングの構成

次の例は、2つのパーティションにわたる分散が指定されたデプロイメントを示しています。それぞれのパーティションに、レプリケートされた2つのLDAPサーバーへのロード・バランシングが設定されています。データのパーティション化に使用されている分散アルゴリズムは数値です。

このプロシージャで使用するすべてのコマンドで、プロキシ・ホスト名(-h)、プロキシ管理ポート(-p)、初期ルート・ユーザーのバインドDN(-D)およびプロキシ・パスワードが含まれるファイル(-j)が指定されます。また、認証も指定する必要があります。クライアントとサーバーが同一インスタンスで実行されている場合に認証を指定しないと、ローカル認証構成が使用されます。

16.3.1 分散をロード・バランシングとともに構成するには

1. プロキシLDAPサーバー拡張を作成します。

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \
create-extension \
--extension-name proxy_extension1 \
--type ldap-server \
--set enabled:true \
--set remote-ldap-server-address:DS1_hostname \
--set remote-ldap-server-port:2389

LDAPサーバー拡張は、リモートLDAPサーバーへのリンクです。このユースケースでは、4つのリモートLDAPサーバー・インスタンスが必要になります。必ず異なるLDAPホスト名およびポートを使用して、リモートLDAPサーバーごとにこの手順を1回実行してください。

2. 各LDAPサーバー拡張にプロキシ・ワークフロー要素を作成します。

$ dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file \
create-workflow-element \
--element-name proxy-we1 \
--type proxy-ldap\
--set enabled:true \
--set client-cred-mode:use-client-identity \
--set ldap-server-extension:proxy_extension1

このユースケースでは、4つのリモートLDAPサーバー・インスタンスが必要になります。リモートごとにこの手順を1回実行します。LDAPサーバー拡張名は、手順1で作成したものと同じにする必要があります。

プロパティclient-cred-modeは、プロキシとリモートLDAPサーバーとの間で使用される認証のタイプを示します。クライアント資格証明モードは、use-client-identityまたはuse-specific-identityです。

3. ロード・バランシング・ワークフロー要素を作成します。

$ dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file \
create-workflow-element \
--element-name LB-we1 \
--type load-balancing \
--set enabled:true

2つのリモートLDAPサーバーのいずれかにリクエストをルーティングするために、ロード・バランシング・ワークフロー要素が1つのみ必要です。このユースケースでは、2つのロード・バランサを使用するため、2つのロード・バランシング・ワークフロー要素を作成する必要があります。

4. ロード・バランシング・アルゴリズムを定義します。

$ dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file \
create-load-balancing-algorithm \
--element-name LB-we1 \
--type failover

ロード・バランシング・アルゴリズムのタイプは、proportional、optimal、saturation、searchfilterまたはfailoverです。ロード・バランシング・アルゴリズムのプロパティ(重み、しきい値または優先度)は、次の手順で、ロード・バランシング・ルートを使用して定義されます。このユースケースでは、2つのロード・バランシング・アルゴリズムが必要です。

5. 各プロキシにロード・バランシング・ルートを定義します。

$ dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file \
create-load-balancing-route \
--element-name LB-we1 \
--route-name LB-route1 \
--type failover \
--set workflow-element:proxy-we1 \
--set add-priority:1 \
--set bind-priority:1 \
--set compare-priority:1 \
--set delete-priority:1 \
--set extended-priority:1 \
--set modify-priority:1 \
--set modifydn-priority:1 \
--set search-priority:1

このユースケースでは、4つのロード・バランシング・ルートが必要です。ロード・バランシング・ワークフロー要素(前の手順で作成した)ごとに2つのルートを設定します。たとえば、すべての操作について一方のルートを優先度1に指定し、すべての操作について他方のルートを優先度2に指定します。

注意:

前述の例のプロパティでは、フェイルオーバー・ロード・バランシングの優先度が設定されています。比例または飽和のロード・バランシングを使用する場合、プロパティは異なります。様々なロード・バランシング・タイプの設定の詳細は、第15.1.3.5項「ロード・バランシングのプロパティの変更」を参照してください。

6. 分散ワークフロー要素を作成して、分散を設定します。

$ dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file \
create-workflow-element \
--element-name distrib-we \
--type distribution \
--set base-dn:dc=example,dc=com \
--set enabled:true

このユースケースでは、分散アルゴリズムを指す1つの分散ワークフロー要素のみが必要です。

7. 分散アルゴリズムを設定します。

$ dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file \
create-distribution-algorithm \
--element-name distrib-we \
--type numeric \
--set distribution-attribute:uid

分散アルゴリズムのタイプは、capacity、numeric、lexicoまたはdnpatternです。境界は、次の手順で分散パーティションを作成するときに定義されます。

8. 分散パーティションを定義します。

$ dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file \
create-distribution-partition \
--element-name distrib-we \
--partition-name distrib-part1\
--type numeric \
--set lower-bound:0 \
--set upper-bound:1000 \
--set partition-id:1 \
--set workflow-element:LB-we1

このユースケースでは、2つのパーティションを作成する必要があります。ワークフロー要素ごとに、パーティションIDおよびパーティション名を一意にする必要があり、各パーティションで、異なるロード・バランシング・ワークフロー要素を使用する必要があります。ロード・バランシング・アルゴリズムを定義したときと同じタイプをルートを定義するときにも指定する必要があります。

注意:

指定される上限値自体は含まれません。つまり、上限として1000を指定すると、パーティションには0から999までの値のみが含まれることになります。

グローバル索引を作成するには

定義した分散アルゴリズムのタイプに応じて、グローバル索引を作成する必要があります。容量アルゴリズムを作成した場合は、グローバル索引を作成する必要があります。

辞書編集、数値およびDNパターンの場合は、グローバル索引はオプションです。

次の手順を実行して、グローバル索引を作成します。

1. グローバル索引カタログを作成します:

$ gicadm -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file \
create-catalog \
--catalogName gi-catalog

2. DN属性を索引付けするグローバル索引をカタログに追加します。

$ gicadm -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file \
add-index \
--catalogName gi-catalog \
--attributeName dn

3. グローバル索引カタログを分散に関連付けます。

$ gicadm -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file \
associate \
--catalogName gi-catalog \
--distributionWorkflowElement distrib-we

9. ワークフローを作成します。
このワークフローによって、分散ワークフロー要素がベースDNに関連付けられます。

$ dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file \
create-workflow \
--workflow-name workflow \
--set enabled:true \
--set base-dn:dc=example,dc=com \
--set workflow-element:distrib-we

10. ネットワーク・グループを作成します。
このネットワーク・グループでは、クライアントとプロキシの間のすべてのリクエストが処理されます。

$ dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file \
create-network-group \
--group-name network-group1 \
--set enabled:true \
--set workflow:workflow \
--set priority:1

16.4 データ・センター間のフェイルオーバーの構成

第3.4項「構成3: データ・センター間のフェイルオーバー」で示しているように、次のコマンドを使用して、2つのデータ・センター間にフェイルオーバー・デプロイメントを設定します。

#Create a proxy LDAP extension for each remote LDAP server
dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-extension \
--type ldap-server \
--extension-name proxy-extension1 \
--set enabled:true \
--set remote-ldap-server-address:DS1_hostname \
--set remote-ldap-server-port:3189

dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-extension \
--type ldap-server \
--extension-name proxy-extension2 \
--set enabled:true \
--set remote-ldap-server-address:DS2_hostname \
--set remote-ldap-server-port:3289

dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-extension \
--type ldap-server \
--extension-name proxy-extension3 \
--set enabled:true \
--set remote-ldap-server-address:DS3_hostname \
--set remote-ldap-server-port:3389

dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-extension \
--type ldap-server \
--extension-name proxy-extension4 \
--set enabled:true \
--set remote-ldap-server-address:DS4_hostname \
--set remote-ldap-server-port:3489

#Create a proxy workflow element for each LDAP server extension
dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-workflow-element \
--element-name proxy-we1 \
--type proxy-ldap \
--set enabled:true \
--set client-cred-mode:use-client-identity \
--set ldap-server-extension:proxy-extension1

dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-workflow-element \
--element-name proxy-we2 \
--type proxy-ldap \
--set enabled:true \
--set client-cred-mode:use-client-identity \
--set ldap-server-extension:proxy-extension2

dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-workflow-element \
--element-name proxy-we3 \
--type proxy-ldap \
--set enabled:true \
--set client-cred-mode:use-client-identity \
--set ldap-server-extension:proxy-extension3

dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-workflow-element \
--element-name proxy-we4 \
--type proxy-ldap \
--set enabled:true \
--set client-cred-mode:use-client-identity \
--set ldap-server-extension:proxy-extension4

# Create a load balancing workflow element for each data center
dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-workflow-element \
--element-name LB-we1 \
--type load-balancing \
--set enabled:true

dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-workflow-element \
--element-name LB-we2 \
--type load-balancing \
--set enabled:true

# Define the load balancing algorithm for each data center
dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-load-balancing-algorithm \
--element-name LB-we1 \
--type proportional

dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-load-balancing-algorithm \
--element-name LB-we2 \
--type proportional

# Define the load balancing routes for each proxy
dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-load-balancing-route \
--element-name LB-we1 \
--route-name LB-route1 \
--type proportional \
--set workflow-element:proxy-we1

dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-load-balancing-route \
--element-name LB-we1 \
--route-name LB-route2 \
--type proportional \
--set workflow-element:proxy-we2

dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-load-balancing-route \
--element-name LB-we2 \
--route-name LB-route3 \
--type proportional \
--set workflow-element:proxy-we3

dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-load-balancing-route \
--element-name LB-we2 \
--route-name LB-route4 \
--type proportional \
--set workflow-element:proxy-we4

# Set failover between the two data centers
dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-workflow-element \
--element-name FO-we \
--type load-balancing \
--set enabled:true

dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-load-balancing-algorithm \
--element-name FO-we \
--type failover

dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-load-balancing-route \
--element-name FO-we \
--route-name FO-route1 \
--type failover \
--set workflow-element:LB-we1 \
--set add-priority:1 \
--set bind-priority:1 \
--set compare-priority:1 \
--set delete-priority:1 \
--set extended-priority:1 \
--set modify-priority:1 \
--set modifydn-priority:1 \
--set search-priority:1 \

dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-load-balancing-route \
--element-name FO-we \
--route-name FO-route2 \
--type failover \
--set workflow-element:LB-we2 \
--set add-priority:2 \
--set bind-priority:2 \
--set compare-priority:2 \
--set delete-priority:2 \
--set extended-priority:2 \
--set modify-priority:2 \
--set modifydn-priority:2 \
--set search-priority:2 \

# Create workflow
dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-workflow \
--workflow-name FO-workflow \
--set enabled:true \
--set base-dn:dc=example,dc=com \
--set workflow-element:FO-we

# Create network group
dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-network-group \
--group-name network-group1 \
--set enabled:true \
--set workflow:FO-workflow \
--set priority:1

16.5 データ・センター間のフェイルオーバーを使用した分散の構成

第3.6項「構成5: 分散とデータ・センター間のフェイルオーバーの併用」で示しているように、次のコマンドを使用して、2つのデータ・センター間にフェイルオーバー・デプロイメントを設定します。

#Create the first failover route
#Create a proxy LDAP extension for each remote LDAP server
dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-extension \
--type ldap-server \
--extension-name proxy-extension-1a \
--set enabled:true \
--set remote-ldap-server-address:DS1a_hostname \
--set remote-ldap-server-port:3189

dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-extension \
--type ldap-server \
--extension-name proxy-extension-2a \
--set enabled:true \
--set remote-ldap-server-address:DS2a_hostname \
--set remote-ldap-server-port:3289

dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-extension \
--type ldap-server \
--extension-name proxy-extension-1b \
--set enabled:true \
--set remote-ldap-server-address:DS1b_hostname \
--set remote-ldap-server-port:3389

dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-extension \
--type ldap-server \
--extension-name proxy-extension-2b \
--set enabled:true \
--set remote-ldap-server-address:DS2b_hostname \
--set remote-ldap-server-port:3489

#Create a proxy workflow element for each LDAP server extension
dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-workflow-element \
--element-name proxy-we-1a \
--type proxy-ldap \
--set enabled:true \
--set client-cred-mode:use-client-identity \
--set ldap-server-extension:proxy-extension-1a

dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-workflow-element \
--element-name proxy-we-2a \
--type proxy-ldap \
--set enabled:true \
--set client-cred-mode:use-client-identity \
--set ldap-server-extension:proxy-extension-2a

dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-workflow-element \
--element-name proxy-we-1b \
--type proxy-ldap \
--set enabled:true \
--set client-cred-mode:use-client-identity \
--set ldap-server-extension:proxy-extension-1b

dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-workflow-element \
--element-name proxy-we-2b \
--type proxy-ldap \
--set enabled:true \
--set client-cred-mode:use-client-identity \
--set ldap-server-extension:proxy-extension-2b

# Create a load balancing workflow element for each data center
dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-workflow-element \
--element-name LB-we-1a \
--type load-balancing \
--set enabled:true

dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-workflow-element \
--element-name LB-we-1b \
--type load-balancing \
--set enabled:true

# Define the load balancing algorithm for each data center
dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-load-balancing-algorithm \
--element-name LB-we-1a \
--type proportional

dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-load-balancing-algorithm \
--element-name LB-we-1b \
--type proportional

# Define the load balancing routes for each proxy
dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-load-balancing-route \
--element-name LB-we-1a \
--route-name LB-route-1a \
--type proportional \
--set workflow-element:proxy-we-1a

dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-load-balancing-route \
--element-name LB-we-1a \
--route-name LB-route-2a \
--type proportional \
--set workflow-element:proxy-we-2a

dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-load-balancing-route \
--element-name LB-we-1b \
--route-name LB-route-1b \
--type proportional \
--set workflow-element:proxy-we-1b

dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-load-balancing-route \
--element-name LB-we-1b \
--route-name LB-route-2b \
--type proportional \
--set workflow-element:proxy-we-2b

# Set failover between the two data centers
dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-workflow-element \
--element-name FO-we1 \
--type load-balancing \
--set enabled:true

dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-load-balancing-algorithm \
--element-name FO-we1 \
--type failover

dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-load-balancing-route \
--element-name FO-we1 \
--route-name FO-route-1a \
--type failover \
--set workflow-element:LB-we-1a \
--set add-priority:1 \
--set bind-priority:1 \
--set compare-priority:1 \
--set delete-priority:1 \
--set extended-priority:1 \
--set modify-priority:1 \
--set modifydn-priority:1 \
--set search-priority:1

dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-load-balancing-route \
--element-name FO-we1 \
--route-name FO-route-1b \
--type failover \
--set workflow-element:LB-we-1b \
--set add-priority:2 \
--set bind-priority:2 \
--set compare-priority:2 \
--set delete-priority:2 \
--set extended-priority:2 \
--set modify-priority:2 \
--set modifydn-priority:2 \
--set search-priority:2

#Create the second failover route
#Create a proxy LDAP extension for each remote LDAP server
dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-extension \
--type ldap-server \
--extension-name proxy-extension-3a \
--set enabled:true \
--set remote-ldap-server-address:DS3a_hostname \
--set remote-ldap-server-port:3189

dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-extension \
--type ldap-server \
--extension-name proxy-extension-4a \
--set enabled:true \
--set remote-ldap-server-address:DS4a_hostname \
--set remote-ldap-server-port:3289

dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-extension \
--type ldap-server \
--extension-name proxy-extension-3b \
--set enabled:true \
--set remote-ldap-server-address:DS3b_hostname \
--set remote-ldap-server-port:3389

dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-extension \
--type ldap-server \
--extension-name proxy-extension-4b \
--set enabled:true \
--set remote-ldap-server-address:DS4b_hostname \
--set remote-ldap-server-port:3489

#Create a proxy workflow element for each LDAP server extension
dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-workflow-element \
--element-name proxy-we-3a \
--type proxy-ldap \
--set enabled:true \
--set client-cred-mode:use-client-identity \
--set ldap-server-extension:proxy-extension-3a

dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-workflow-element \
--element-name proxy-we-4a \
--type proxy-ldap \
--set enabled:true \
--set client-cred-mode:use-client-identity \
--set ldap-server-extension:proxy-extension-4a

dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-workflow-element \
--element-name proxy-we-3b \
--type proxy-ldap \
--set enabled:true \
--set client-cred-mode:use-client-identity \
--set ldap-server-extension:proxy-extension-3b

dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-workflow-element \
--element-name proxy-we-4b \
--type proxy-ldap \
--set enabled:true \
--set client-cred-mode:use-client-identity \
--set ldap-server-extension:proxy-extension-4b

# Create a load balancing workflow element for each data center
dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-workflow-element \
--element-name LB-we-2a \
--type load-balancing \
--set enabled:true

dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-workflow-element \
--element-name LB-we-2b \
--type load-balancing \
--set enabled:true

# Define the load balancing algorithm for each data center
dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-load-balancing-algorithm \
--element-name LB-we-2a \
--type proportional

dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-load-balancing-algorithm \
--element-name LB-we-2b \
--type proportional

# Define the load balancing routes for each proxy
dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-load-balancing-route \
--element-name LB-we-2a \
--route-name LB-route-3a \
--type proportional \
--set workflow-element:proxy-we-3a

dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-load-balancing-route \
--element-name LB-we-2a \
--route-name LB-route-4a \
--type proportional \
--set workflow-element:proxy-we-4a

dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-load-balancing-route \
--element-name LB-we-2b \
--route-name LB-route-3b \
--type proportional \
--set workflow-element:proxy-we-3b

dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-load-balancing-route \
--element-name LB-we-2b \
--route-name LB-route-4b \
--type proportional \
--set workflow-element:proxy-we-4b

# Set failover between the two data centers
dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-workflow-element \
--element-name FO-we2 \
--type load-balancing \
--set enabled:true

dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-load-balancing-algorithm \
--element-name FO-we2 \
--type failover

dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-load-balancing-route \
--element-name FO-we2 \
--route-name FO-route-2a \
--type failover \
--set workflow-element:LB-we-2a \
--set add-priority:1 \
--set bind-priority:1 \
--set compare-priority:1 \
--set delete-priority:1 \
--set extended-priority:1 \
--set modify-priority:1 \
--set modifydn-priority:1 \
--set search-priority:1

dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-load-balancing-route \
--element-name FO-we2 \
--route-name FO-route-2b \
--type failover \
--set workflow-element:LB-we-2b \
--set add-priority:2 \
--set bind-priority:2 \
--set compare-priority:2 \
--set delete-priority:2 \
--set extended-priority:2 \
--set modify-priority:2 \
--set modifydn-priority:2 \
--set search-priority:2

# Create distribution to the two failover routes
dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-workflow-element \
--element-name distrib-we \
--type distribution \
--set base-dn:dc=example,dc=com \
--set enabled:true

dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-distribution-algorithm \
--element-name distrib-we \
--type numeric \
--set distribution-attribute:uid

dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-distribution-partition \
--element-name distrib-we \
--partition-name distrib-part1\
--type numeric \
--set lower-bound:0 \
--set upper-bound:1000 \
--set partition-id:1 \
--set workflow-element:FO-we1

dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-distribution-partition \
--element-name distrib-we \
--partition-name distrib-part2\
--type numeric \
--set lower-bound:1000 \
--set upper-bound:2000 \
--set partition-id:2 \
--set workflow-element:FO-we2

# Create workflow
dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-workflow \
--workflow-name Distrib-workflow \
--set enabled:true \
--set base-dn:dc=example,dc=com \
--set workflow-element:distrib-we

# Create network group
dsconfig -p 4444 -h localhost -D"cn=Directory Manager" -j pwd-file -X -n \
create-network-group \
--group-name network-group1 \
--set enabled:true \
--set workflow:Distrib-workflow \
--set priority:1

17 ディレクトリ・データの管理

この章では、ディレクトリ・サーバーにおけるデータの追加、変更、削除および検索の方法について説明します。この章では、データに索引付けすることによって、より効率的に検索を実行する方法、エントリが一意であることを確認する方法、仮想属性など拡張データ機能を使用する方法についても説明します。

この章では、次のトピックを取り扱います:

- 第17.1項「データのインポートとエクスポート」

- 第17.2項「大規模データ・セットのインポート」

- 第17.3項「データのバックアップおよびリストア」

- 第17.4項「ディレクトリ・データの検索」

- 第17.5項「拡張検索機能の使用方法」

- 第17.6項「ディレクトリ・データの追加、変更および削除」

- 第17.7項「ディレクトリ・データへの索引付け」

- 第17.8項「格納されるデータ・サイズの削減」

- 第17.9項「属性値の一意性の確認」

- 第17.10項「仮想属性の構成」

- 第17.11項「LDAPサブエントリの使用方法」

- 第17.12項「集合属性の使用方法」

- 第17.13項「リフェラルの構成」

- 第17.14項「Oracle Directory Services Managerを使用した仮想属性の管理」

- 第17.15項「Oracle Directory Services Managerを使用したデータの管理」

17.1 データのインポートとエクスポート

ディレクトリ・サーバーは、特定のバックエンドとの間でデータをやり取りするいくつかのメカニズムを備えています。この章では、各種オプションの概要を示し、インポートおよびエクスポートのメカニズムについて詳しく説明します。

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

- 第17.1.1項「スタンドアロン・ディレクトリ・サーバーへのデータの移入」

- 第17.1.2項「import-ldifを使用したデータのインポート」

- 第17.1.3項「export-ldifを使用したデータのエクスポート」

- 第17.1.4項「MakeLDIFテンプレート・ファイルの作成」

注意:

ユーザー・エントリをインポートする場合、Oracle Unified Directoryでは、事前に暗号化されたパスワードがパスワード・ポリシーに一致していることを検証できません。したがって、事前に暗号化されたパスワードは、次のエラーで拒否されます:

LDAP: error code 53 - Pre-encoded passwords are not allowed for the password attribute userPassword.

ldapmodifyまたはimport-ldifを使用してユーザー・エントリをインポートする場合に事前に暗号化されたパスワードを許可するには、拡張プロパティallow-pre-encoded-passwordsをtrueに設定することで、デフォルト・パスワード・ポリシーを変更します。詳細は、第24.2.2項「デフォルト・パスワード・ポリシーを変更するには」を参照してください。

17.1.1 スタンドアロン・ディレクトリ・サーバーへのデータの移入

スタンドアロン・ディレクトリ・サーバーにデータを移入するには、次の方法の1つを使用します:

- サーバーをセットアップする際に、GUIモードでsetupユーティリティを使用するか、対話方式コマンドライン・モードでsetupユーティリティを使用することによって、LDAPデータ交換形式(LDIF)ファイルからデータをインポートします。これは、スタンドアロン・サーバーまたはレプリケートされたトポロジにおける最初のサーバーを初期化するための最も便利な方法です。

- 空の接尾辞から開始し、ldapmodifyコマンドを使用することでエントリを追加します。例:

$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
-a -f /usr/local/add_entry.ldif

- import-ldifコマンドを使用して、LDIFファイルからデータをインポートします。例:

$ import-ldif -b dc=example,dc=com -n userRoot -l /var/tmp/Example.ldif

これは、エントリを一括して追加する場合の大変効率的な方法です。import-ldifコマンドは、接尾辞の既存のデータを置き換えるか、ベースDNにデータを追加することによって、LDIFファイルからデータをインポートします。同様に、export-ldifコマンドは、データベースからLDIFファイルにエントリをエクスポートし、その後、それは別のサーバーにインポートできます。どちらのツールでも、ファイルの圧縮およびSASL拡張と、SSLおよびstartTLSを使用したクライアント/サーバー認証がサポートされています。

- 別のサーバーからバイナリ・データベースをコピーします。この方法は、バイナリ・コピーとも呼ばれます。

$ cp instance-path/db/example.db destination-path/db

- restoreコマンドを使用して、バックアップからデータベースをリストアします。例:

$ restore -d /home/backup/userRoot

注意:

バイナリ・データベース・コピーまたはバックアップからのデータベースのリストアを実行するには、ソース・サーバーとターゲット・サーバーでデータベース・リモートLDAP構造および索引が同一であることが必要です。

17.1.2 import-ldifを使用したデータのインポート

import-ldifコマンドは、LDIFファイルから読み取ったデータまたは第17.1.4項「MakeLDIFテンプレート・ファイルの作成」に基づいて生成されたデータを、ディレクトリ・サーバー・バックエンドに移入します。多くの場合、import-ldifのほうが、ldapmodifyを使用してエントリを追加するよりも大幅に高速です。

import-ldifコマンドでは、LDIFファイルと圧縮済ファイル(.zip)の両方がサポートされています。

インポート操作における次の局面に注意してください:

- Oracle Berkeley DB Java Edition (JE)バックエンド全体への完全なインポートのほうが、JEバックエンドの分岐への部分インポートよりもパフォーマンスがよくなります。インポートするすべてのLDIFファイルで、UTF-8キャラクタ・セット・エンコードを使用している必要があります。

- 接尾辞のインポートは、リソースに負荷のかかる操作です。多数の接尾辞を含むLDIFファイルをインポートする場合、そのインポート操作を完了するにはヒープ領域不足になることがあります。そのようなLDIFファイルをインポートする前に、ヒープを可能なかぎり増やしておく必要があります。詳細は、第30章「パフォーマンス・チューニング」および第17.2項「大規模データ・セットのインポート」を参照してください。

- LDIFファイルをインポートするためにroot権限は必要ありませんが、cn=Directory Managerなどのroot権限を持つユーザーとして認証される必要があります。

次の項では、import-ldifコマンドを使用してデータをインポートする方法について説明します:

- 第17.1.2.1項「import-ldifの操作モード」

- 第17.1.2.2項「オフライン・モードでデータをインポートする方法」

- 第17.1.2.3項「オフライン・インポート中に既存のデータを置換する方法」

- 第17.1.2.4項「既存のデータにインポートしたデータを追加する方法」

- 第17.1.2.5項「部分的にファイルをインポートする方法」

- 第17.1.2.6項「フィルタを使用して部分的にファイルをインポートする方法」

- 第17.1.2.7項「インポート中に属性を含めるまたは除外する方法」

- 第17.1.2.8項「圧縮済LDIFファイルをインポートする方法」

- 第17.1.2.9項「インポート中に拒否またはスキップされたエントリを記録する方法」

- 第17.1.2.10項「MakeLDIFテンプレートからデータをインポートする方法」

- 第17.1.2.11項「オンライン・モードでインポートを実行する方法」

- 第17.1.2.12項「インポートをスケジュールする方法」

17.1.2.1 import-ldifの操作モード

import-ldifコマンドには、操作にオンラインとオフラインの2つのモードがあります。

- オンライン・モード。オンライン・モードでは、import-ldifは、実行中のディレクトリ・サーバー・インスタンスにアクセスし、インポート・タスクを登録します。このコマンドは、管理コネクタを通してSSL経由でタスク・バックエンドにアクセスします。詳細は、第14.3項「サーバーへの管理トラフィックの管理」を参照してください。オンライン・モードは、いずれかの接続オプション(--hostname、--port、--bindDN、--bindPasswordFileなど)が指定されている場合は自動的に実行されます。
オンライン・インポートの場合でも、インポート中はバックエンドが使用できないことに注意してください。レプリケートされたトポロジでは、全体的なサービスは、依然としてreferral on update機能を通して使用可能です。詳細は、第17.13.1項「レプリケートされたトポロジでのリフェラル」を参照してください。

一般的に、オンライン・インポートを実行する予定である場合は、サーバーを起動するときにヒープを増やす必要があります。詳細は、第30章「パフォーマンス・チューニング」を参照してください。

- オフライン・モード 。接続オプションが指定されていない場合、このコマンドはオフライン・モードで実行されます。オフライン・モードでは、import-ldifはディレクトリ・サーバー・インスタンスを介さずに、データベースに直接アクセスします。この場合、ディレクトリ・サーバーを停止する必要があります。

17.1.2.2 オフライン・モードでデータをインポートする方法

この手順では、インポートLDIFファイルで指定されている新しいエントリを持つリモートLDAPデータベースをインポートします。コマンドはオフライン・モードで実行され、それには、インポートする前にサーバーを停止する必要があります。

1. サーバーが実行中である場合は、それを停止します。

$ stop-ds

2. 次の例のように、LDIFファイルをインポートします:

$ import-ldif -b dc=example,dc=com -n userRoot -l Example.ldif

このコマンドは、インポートに含めるデータの分岐のベースDN(-b)、データのインポート先のバックエンドID (-n)およびインポートに使用するLDIFファイル(-l)を指定します。

17.1.2.3 オフライン・インポート中に既存のデータを置換する方法

次の手順では、既存のバックエンドを、インポート・ファイルで指定されている新しいエントリに置き換えます。

1. サーバーが実行中である場合は、それを停止します。

$ stop-ds

2. LDIFファイルをインポートし、既存のデータを置き換えます。例:

$ import-ldif --includeBranch dc=example,dc=com --backendID userRoot \
--replaceExisting --ldifFile Example.ldif

17.1.2.4 既存のデータにインポートしたデータを追加する方法

次の手順では、インポート・ファイル内のエントリを、バックエンドの既存のエントリに追加します。

1. サーバーが実行中である場合は、それを停止します。

$ stop-ds

2. LDIFファイルをインポートし、既存のデータに新規データを追加します。例:

$ import-ldif --backendID userRoot --append --ldifFile new.ldif

17.1.2.5 部分的にファイルをインポートする方法

import-ldifコマンドには、プロセス中に含めるまたは除外するベースDNを指定することによって、インポート・ファイルの一部をインポートするオプションがあります。

この例では、ベースDN (dc=example,dc=com)の下のすべてのエントリがインポートされ、ou=People,dc=example,dc=comの下のすべてのエントリが除外されます。

1. サーバーが実行中である場合は、それを停止します。

$ stop-ds

2. LDIFファイルの一部をインポートします。例:

$ import-ldif --includeBranch dc=example,dc=com \
--excludeBranch ou=People,dc=example,dc=com --backendID userRoot \
--replaceExisting --ldifFile Example.ldif

17.1.2.6 フィルタを使用して部分的にファイルをインポートする方法

import-ldifコマンドには、データを含めるか除外するためのフィルタを使用することによって、インポート・ファイルの一部をインポートするオプションがあります。このメカニズムを使用する前に、それがどのように機能するのかを完全に把握してください。

この例では、検索フィルタl=Auckland (つまり、location=Auckland)に一致するエントリを除く、LDIFファイルの内容がインポートされます。

--includeFilterオプションは、インポート中に検索フィルタに一致するすべてのエントリが含められることを除いて、--excludeFilterと同様の方法で機能します。

1. サーバーが実行中である場合は、それを停止します。

$ stop-ds

2. 除外フィルタを使用することによって、ファイルの一部をインポートします。例:

$ import-ldif --excludeFilter "(l=Auckland)" --backendID userRoot \
--replaceExisting --ldifFile Example.ldif

17.1.2.7 インポート中に属性を含めるまたは除外する方法

import-ldifコマンドには、--includeAttributeおよび--excludeAttributeのオプションを使用することで、インポート中に、それぞれ属性を含めるまたは除外するオプションがあります。このメカニズムを使用する前に、それがどのように機能するのかを完全に把握してください。

1. サーバーが実行中である場合は、それを停止します。

$ stop-ds

2. インポートを開始する前に、インポート・ファイルのエントリを表示します。
ディレクトリ・サーバーは、サーバーに接続することなく、インポート・ファイルを検索、変更、比較または削除するために役立つユーティリティを備えています。ldifsearchコマンドを使用して、インポート・ファイル内のエントリを表示できます。たとえば、Sam Carterのエントリを表示するには、次のコマンドを使用します:

$ ldifsearch -b dc=example,dc=com --ldifFile Example.ldif "(cn=Sam Carter)"
dn: uid=scarter,ou=People,dc=example,dc=com
objectClass: person
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: top
givenname: Sam
uid: scarter
cn: Sam Carter
telephonenumber: +1 408 555 4798
sn: Carter
userpassword: sprain
roomnumber: 4612
mail: scarter@example.com
l: Sunnyvale
ou: Accounting
ou: People
facsimiletelephonenumber: +1 408 555 9751

このエントリでは、telephonenumber属性の下にroomnumber属性があることに注意します。

3. すべてのエントリについてroomnumber属性を除外して、ファイルをインポートします。

$ import-ldif --excludeAttribute "roomnumber" --backendID userRoot \
--replaceExisting --ldifFile Example.ldif

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

$ start-ds

5. ldapsearchを実行し、インポートを確認します。
次の例は、Sam Carterのエントリからroomnumber属性が削除されていることを示しています。

$ ldapsearch --port 1389 --baseDN dc=example,dc=com --bindDN "cn=Directory Manager" \
--bindPassword password "(cn=Sam Carter)"
dn: uid=scarter,ou=People,dc=example,dc=com \
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: top
givenName: Sam
uid: scarter
cn: Sam Carter
sn: Carter
telephoneNumber: +1 408 555 4798
ou: Accounting
ou: People
l: Sunnyvale
mail: scarter@example.com
facsimileTelephoneNumber: +1 408 555 9751

17.1.2.8 圧縮済LDIFファイルをインポートする方法

import-ldifユーティリティは圧縮LDIFファイルをサポートしています。

1. サーバーが実行中である場合は、それを停止します。

$ stop-ds

2. 圧縮LDIFファイルをインポートします。

$ import-ldif --includeBranch dc=example,dc=com
--excludeBranch "ou=People,dc=example,dc=com" --ldifFile Example.ldif \
--backendID userRoot --replaceExisting --isCompressed

17.1.2.9 インポート中に拒否またはスキップされたエントリを記録する方法

import-ldifコマンドは、インポート・プロセス中に拒否またはスキップされたエントリについて出力ファイルに書き込む方法を提供します。これにより、LDIFファイルの簡単なデバッグが可能です。拒否されたエントリは、ディレクトリ・サーバーによって、追加されるエントリがスキーマ違反が原因で拒否された場合に発生します。スキップされたエントリは、指定されているベースDNの下にエントリを配置できない場合に発生します。

1. サーバーが実行中である場合は、それを停止します。

$ stop-ds

2. --rejectFileおよび--skipFileのオプションを使用して、ファイルをインポートします。
--overWriteオプションを使用して、2つのファイル内の前のアイテムを置換することもできます。このオプションを指定しない場合、ディレクトリ・サーバーでは、新しい拒否されたエントリおよびスキップされたエントリを既存のファイルに追加します。

$ import-ldif --backendID userRoot --append --ldifFile new.ldif
--overwrite --rejectFile rejected.ldif --skipFile skipped.ldif

3. rejectFileおよびskipFileの内容を表示し、インポート中にどのエントリが拒否またはスキップされたのかを判別します。例:

$ more rejected.ldif
# Entry ou=Contractors,dc=example,dc=com read from LDIF starting at line 1
is not valid because it violates the server's schema configuration:
Entry ou=Contractors,dc=example,dc=com violates the Directory Server schema
configuration because it includes attribute changeType which is not allowed.
changetype: add objectclasses defined in that entry objectclass: top
objectclass: organizationalUnit ou: Contractors ou: Product Testing
ou: Product Dev ou: Accounting ...

$ more skipped.ldif
# Skipping entry ou=People,dc=example,dc=com because the DN is not one that should be
included based on the include and exclude branches objectclass: top
objectclass: organizationalunit ou: People
aci: (target ="ldap:///ou=People,dc=example,dc=com")(targetattr ="userpassword ||
telephonenumber || facsimiletelephonenumber")(version 3.0;acl "Allow self entry
modification"; allow (write)(userdn = "ldap:///self");)
aci: (target ="ldap:///ou=People,dc=example,dc=com")(targetattr h3.="cn || sn ||
uid") (targetfilter ="(ou=Accounting)")(version 3.0;acl "Accounting Managers Group
Permissions"; allow (write)
(groupdn = "ldap:///cn=Accounting Managers,ou=groups,dc=example,dc=com");)
aci: (target ="ldap:///ou=People,dc=example,dc=com")(targetattr h3.="cn || sn ||
uid") (targetfilter ="(ou=Human Resources)")(version 3.0;acl "HR Group Permissions";
allow write)(groupdn = "ldap:///cn=HR Managers,ou=groups,dc=example,dc=com");) aci:
(target ="ldap:///ou=People,dc=example,dc=com")(targetattr h3.="cn ||sn || uid")
(targetfilter ="(ou=Product Testing)")(version 3.0;acl "QA Group Permissions"; allow
(write)(groupdn = "ldap:///cn=QA Managers,ou=groups,dc=example,dc=com");)
aci: (target ="ldap:///ou=People,dc=example,dc=com")(targetattr h3.="cn || sn ||
uid") (targetfilter ="(ou=Product Development)")(version 3.0;acl "Engineering Group
Permissions"; allow (write)(groupdn =
"ldap:///cn=PD Managers,ou=groups,dc=example,dc=com");) ...

17.1.2.10 MakeLDIFテンプレートからデータをインポートする方法

ディレクトリ・サーバーにはJavaユーティリティmakeLDIFが組み込まれており、それを使用してインポート向けのサンプル・データを生成できます。makeLDIFユーティリティには、テンプレート・ファイルが必要です。独自のテンプレート・ファイルを作成するか、INSTANCE_DIR/OUD/config/MakeLDIF/example.templateにあるテンプレート・ファイルを必要に応じて編集して使用できます。詳細は、第17.1.4項「MakeLDIFテンプレート・ファイルの作成」および付録A「make-ldif」を参照してください。

1. サーバーが実行中である場合は、それを停止します。

$ stop-ds

2. テンプレート・ファイルを使用して、データをインポートします。
このサンプル・テンプレートによって、指定したバックエンドに10,003個のサンプル・エントリが生成されます。

$ import-ldif --backendID userRoot --templateFile example.template \
--randomSeed 0

17.1.2.11 オンライン・モードでインポートを実行する方法

import-ldifユーティリティは、サーバーをオンラインにした状態で実行することもできます。オンライン・モードでは、このコマンドは、管理コネクタを通してSSL経由でタスク・バックエンドにアクセスします。オンライン・モードでこのコマンドを実行するには、SSL証明書の信頼方法など関連する接続オプションを指定する必要があります。この例では、-Xオプションを使用して、すべての証明書を信頼します。詳細は、第14.3項「サーバーへの管理トラフィックの管理」を参照してください。

適切な接続オプションを指定して、import-ldifコマンドを実行します。

$ import-ldif -h localhost -port 4444 -D "cn=Directory Manager" -j pwd-file -X \
-l /ldif-files/example.ldif

17.1.2.12 インポートをスケジュールする方法

import-ldifユーティリティは、将来の日付でインポートをスケジュールするための--startオプションを備えています。manage-tasksユーティリティを使用することで、このスケジュール済タスクを表示できます。このコマンドは、管理コネクタを通してSSL経由でタスク・バックエンドにアクセスします。インポート・タスクをスケジュールするには、SSL証明書の信頼方法など関連する接続オプションを指定する必要があります。この例では、-Xオプションを使用して、すべての証明書を信頼します。

--startオプションを指定して、import-ldifコマンドを実行します。

$ import-ldif -h localhost -port 4444 -D "cn=Directory Manager" -j pwd-file -X \
-l /ldif-files/example.ldif --start 20080124121500

詳細は、第14.4項「タスクとしてのコマンドの構成」を参照してください。

17.1.3 export-ldifを使用したデータのエクスポート

export-ldifコマンドを使用して、ディレクトリ・サーバー・バックエンドからデータをエクスポートします。このコマンドは、次のタスクに有効です:

- ディレクトリ・データのバックアップ

- 他のアプリケーションへのデータのエクスポート

- ディレクトリ・トポロジへの変更後のデータベースへの移入

- レプリケートされたトポロジでのマスター・サーバーの再初期化

注意:

export-ldifコマンドを使用して、monitor、ads-truststore、backupおよびconfig-file-handlerのバックエンドからデータをエクスポートすることはできません。

次の項では、export-ldifコマンドを使用してデータをエクスポートする方法について説明します:

- 第17.1.3.1項「export-ldifの操作モード」

- 第17.1.3.2項「LDIFにデータをエクスポートする方法」

- 第17.1.3.3項「部分的にデータをエクスポートする方法」

- 第17.1.3.4項「フィルタを使用してバックエンドの一部をエクスポートする方法」

- 第17.1.3.5項「エクスポート中に属性を含めるまたは除外する方法」

- 第17.1.3.6項「LDIFをエクスポートしてそのファイルを圧縮する方法」

- 第17.1.3.7項「オンライン・モードでエクスポートを実行する方法」

- 第17.1.3.8項「エクスポートをスケジュールする方法」

17.1.3.1 export-ldifの操作モード

export-ldifコマンドには、操作にオンラインとオフラインの2つのモードがあります。

- オンライン・モード。オンライン・モードでは、export-ldifは、実行中のディレクトリ・サーバー・インスタンスにアクセスし、エクスポート・タスクを登録します。このモードは、LDAP接続オプション(--hostname、--port、--bindDN、--bindPasswordFileなど)が使用されている場合は自動的に実行されます。このコマンドは、管理コネクタを通してSSL経由でタスク・バックエンドにアクセスします。詳細は、第14.3項「サーバーへの管理トラフィックの管理」を参照してください。

- オフライン・モード 。接続オプションが指定されていない場合、このコマンドはオフライン・モードで実行されます。オフライン・モードでは、export-ldifはディレクトリ・サーバー・インスタンスを介さずに、データベースに直接アクセスします。この場合、ディレクトリ・サーバーを停止する必要があります。

詳細は、付録A「export-ldif」を参照してください。

17.1.3.2 LDIFにデータをエクスポートする方法

1. サーバーが実行中である場合は、それを停止します。

$ stop-ds

2. 指定したLDIFファイルにバックエンドをエクスポートします。

$ export-ldif --includeBranch "dc=example,dc=com" --backendID userRoot \
--ldifFile example.ldif

17.1.3.3 部分的にデータをエクスポートする方法

export-ldifコマンドには、処理中に含めるまたは除外するベースDNおよびその子を指定することでバックエンドの一部をエクスポートするオプションがあります。

1. サーバーが実行中である場合は、それを停止します。

$ stop-ds

2. バックエンドの一部をエクスポートします。
この例では、ou=People,dc=example,dc=comの下のエントリのみがエクスポートされます。

$ export-ldif --includeBranch ou=People,dc=example,dc=com --backendID userRoot \
--ldifFile example-people.ldif

3. ldifsearchコマンドを使用して、エクスポートされたファイルを検証します。
ldifsearchコマンドは、ディレクトリ・サーバーに接続することなく、LDIFファイル内のエントリを検証します。これは、ldapsearchコマンドと類似した方法で使用できます。例:

$ ldifsearch -b dc=example,dc=com --ldifFile export.ldif "(objectclass=*)"
dn: ou=People,dc=example,dc=com
objectClass: organizationalunit
objectClass: top
ou: People
dn: uid=scarter,ou=People,dc=example,dc=com
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: top
givenName: Sam
uid: scarter
cn: Sam Carter
sn: Carter
telephoneNumber: +1 408 555 4798
userPassword: {SSHA}Ocpp2P4sImz2MziL69AUG9+khdIhFpmU4B5mvA==
roomNumber: 4612
ou: Accounting
ou: People
l: Sunnyvale
mail: scarter@example.com
facsimileTelephoneNumber: +1 408 555 9751 ...

17.1.3.4 フィルタを使用してバックエンドの一部をエクスポートする方法

export-ldifコマンドには、検索フィルタを使用することで、バックエンドの一部をエクスポートするオプションがあります。ディレクトリ・サーバーでは、フィルタに一致するすべてのエントリが含められるか除外されます。このメカニズムを使用する前に、それがどのように機能するのかを完全に把握してください。

この例では、検索フィルタl=Cupertino (つまり、location=Cupertino)に一致するエントリのみがエクスポートされます。--excludeFilterオプションは、エクスポート中にフィルタに一致するすべてのエントリが除外されることを除いて、--includeFilterと同様の方法で機能します。

1. サーバーが実行中である場合は、それを停止します。

$ stop-ds

2. --includeFilterオプションを使用することによって、バックエンドの一部をエクスポートします。

$ export-ldif --includeFilter "(l=Cupertino)" --backendID userRoot \
--ldifFile export.ldif

17.1.3.5 エクスポート中に属性を含めるまたは除外する方法

export-ldifユーティリティには、--includeAttributeおよび--excludeAttributeのオプションを使用することで、エクスポート中に、それぞれ属性を含めるまたは除外するオプションがあります。このメカニズムを使用する前に、それがどのように機能するのかを完全に把握してください。

1. サーバーの実行中に、ldapsearchコマンドを使用することによって、サンプル・エントリを表示します。例:

$ ldapsearch --baseDN dc=example,dc=com "(cn=Sam Carter)"
dn: uid=scarter,ou=People,dc=example,dc=com
objectClass: person
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: top
givenname: Sam
uid: scarter
cn: Sam Carter
telephonenumber: +1 408 555 4798
sn: Carter
userpassword: sprain
roomnumber: 4612
mail: scarter@example.com
l: Sunnyvale
ou: Accounting
ou: People
facsimiletelephonenumber: +1 408 555 9751

2. サーバーを停止します。

$ stop-ds

3. --includeAttributeオプションを使用して、エクスポートに含める属性を使用して、バックエンドをエクスポートします。
--includeAttributeオプションは、含める属性ごとに複数回使用できます。この例では、最上位レベルの属性のみがエクスポートされます。

$ export-ldif --backendID userRoot --includeAttribute dn --includeAttribute dc \
--includeAttibute cn --includeAttribute sn --includeAttribute givenname \
--includeAttribute objectclass --includeAttribute ou --includeAttribute uid \
--ldifFile export.ldif

4. ldifsearchコマンドを使用して、エクスポート・ファイルを検証します。
エラーが発生した場合、サーバーではそのコマンドの処理が続行されます。

$ ldifsearch --baseDN dc=example,dc=com --ldifFile export.ldif "(objectclass=*)"
dn: dc=example,dc=com
objectClass: domain
objectClass: top
dc: example
dn: ou=Groups,dc=example,dc=com
objectClass: organizationalunit
objectClass: top
ou: Groups
dn: cn=Directory Administrators,ou=Groups,dc=example,dc=com
objectClass: groupofuniquenames
objectClass: top
cn: Directory Administrators
ou: Groups
dn: ou=People,dc=example,dc=com
objectClass: organizationalunit
objectClass: top
ou: People ...

17.1.3.6 LDIFをエクスポートしてそのファイルを圧縮する方法

export-ldifコマンドで、出力LDIFファイルを圧縮できます。

1. サーバーが実行中である場合は、それを停止します。

$ stop-ds

2. LDIFにエクスポートしてから、そのファイルを圧縮します。

$ export-ldif --backendID userRoot --ldifFile export.ldif --compress

17.1.3.7 オンライン・モードでエクスポートを実行する方法

export-ldifコマンドは、サーバーをオンラインにした状態で実行することもできます。オンライン・モードでは、このコマンドは、管理コネクタを通してSSL経由でタスク・バックエンドにアクセスします。詳細は、第14.3項「サーバーへの管理トラフィックの管理」を参照してください。オンライン・モードでこのコマンドを実行するには、SSL証明書の信頼方法など関連する接続オプションを指定する必要があります。この例では、-Xオプションを使用して、すべての証明書を信頼します。

LDAP接続オプションを指定して、export-ldifコマンドを実行します。例:

$ export-ldif -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \
--includeBranch "dc=example,dc=com" --backendID userRoot --ldifFile export.ldif

17.1.3.8 エクスポートをスケジュールする方法

export-ldifユーティリティは、将来の日付でエクスポートをスケジュールするための--startオプションを備えています。manage-tasksユーティリティを使用することで、このスケジュール済タスクを表示できます。このコマンドは、管理コネクタを通してSSL経由でタスク・バックエンドにアクセスします。詳細は、第14.3項「サーバーへの管理トラフィックの管理」を参照してください。エクスポート・タスクをスケジュールするには、SSL証明書の信頼方法など関連する接続オプションを指定する必要があります。この例では、-Xオプションを使用して、すべての証明書を信頼します。

エクスポートをスケジュールするには、サーバーが実行中である必要があります。

--startオプションおよびLDAP接続パラメータを指定して、export-ldifコマンドを実行します。

--startオプションは、その値として、yyyymmddhhmmss形式の日付と時刻を取ります。例:

$ export-ldif -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \
--includeBranch "dc=example,dc=com" --backendID userRoot \
--ldifFile export.ldif --start 20080124121500

17.1.4 MakeLDIFテンプレート・ファイルの作成

make-ldifコマンドは、テンプレート・ファイルを使用して、LDIFファイルを生成する方法を定義します。この手法では、目的の結果を生成するためにコードを変更することを必要とせずに柔軟性が得られます。この項では、make-ldifコマンドを使用して、カスタマイズされたLDIFファイルを作成する方法を説明します。

17.1.4.1 テンプレート・ファイルの書式

テンプレート・ファイルには、最大4つのセクションを含めることができ、それらは次の順序で指定する必要があります:

1. 第17.1.4.1.1項「カスタム・タグのインクルード」

2. 第17.1.4.1.2項「グローバル置換変数」

3. 第17.1.4.1.3項「分岐定義」

4. 第17.1.4.1.4項「テンプレート定義」

17.1.4.1.1 カスタム・タグのインクルード

カスタム・タグのインクルードは、カスタム・タグをロードし、make-ldifテンプレートを処理するときにそれらを使用できるうにするメカニズムを提供します。これは、次のようにincludeディレクティブを使用して実行します:

include com.example.opends.makeldif.MyCustomTag

指定したクラスは、クラス・パスに含まれている必要があり、org.opends.server.tools.makeldif.Tagクラスのサブクラスである必要があります。カスタム・タグの開発の詳細は、第17.1.4.3項「カスタム・タグの定義」を参照してください。

make-ldifで提供されている標準置換タグはすべて、自動的に使用可能であるため、明示的なincludeディレクティブは必要ありません。

17.1.4.1.2 グローバル置換変数

最初のセクションは、テンプレート・ファイルに必ず含める必要があり、そこでグローバル置換変数を定義します。グローバル置換変数は、テンプレート・ファイルで後で参照できるテキストの文字列を定義するために使用され、各行がメモリーに読み込まれるときに自動的に置換されます(Cプリプロセッサによって、コード内のマクロ゛かそれらの定義済の値と置換されるのに似ています)。たとえば、次の置換変数定義によって、dc=example,dc=comという値を持つsuffixという名前のグローバル置換変数が作成されます:

define suffix=dc=example,dc=com

グローバル置換変数が定義されているときは、その縁数名が大カッコで囲まれている場合(たとえば、[suffix])、トークンがその置換変数に対して定義された値と置換されます。

最初の空白行とその後に続く1つ以上の置換変数定義によって示されるようにすべての置換変数定義が読み取られると、テンプレート・ファイルから読み取られるすべて残りの行が、1行ずつ処理されます。大カッコ内の置換変数名のすべてのオカレンスは、その変数の値で置換されます。置換は、テンプレート・ファイルがメモリーに読み取られるときに実行されるため、置換変数は、分岐、テンプレート定義、さらにタグ内などどの場所にも配置できます。

テンプレート・ファイルに定義されているグローバル置換変数がある場合、それらは、ファイルの先頭に配置する必要があり、それらの間に空白文字を入れないようにします。ただし、置換変数は必要ありません。置換変数がない場合、テンプレート・ファイルは分岐定義から開始する必要があります。

17.1.4.1.3 分岐定義

分岐定義は、生成されたLDIFに使用する基本構造を定義するためにmake-ldifテンプレート・ファイル内で使用されます。それらによって、階層の最上部に配置される1つ以上のエントリと、それらの下に配置されるエントリのタイプが指定されます。

分岐定義の最も基本的な形式は、次のとおりです:

branch: dc=example,dc=com

この例では、次のエントリがdc=example,dc=comのDNで作成されます:

dn: dc=example,dc=com
objectClass: top
objectClass: domain
dc: example

エントリの基本構造は、分岐定義のDNで指定されているdcのRDN属性によって定義されます。make-ldifコマンドは、dc RDN属性をdomainオブジェクト・クラスと自動的に関連付けます。make-ldifコマンドには、次のように分岐エントリ内の他の共通RDN属性に対して同様の定義があります:

o

organizationオブジェクト・クラスのエントリを作成します。

ou

organizationalUnitオブジェクト・クラスのエントリを作成します。

c

countryオブジェクト・クラスのエントリを作成します。

分岐エントリに対して、他のどのような種類のRDN属性も使用できます。前述の指定したもの以外のRDN属性を持つ分岐エントリについては、エントリはuntypedObjectおよびextensibleObjectオブジェクト・クラスで作成されます。

前述の分岐定義によって、その分岐エントリの下に追加のエントリが作成されることはありません。これを行うには、1つ以上のsubordinateTemplate行を指定する必要があります。例:

branch: ou=People,dc=example,dc=com
subordinateTemplate: person:100

これにより、ou=People,dc=example,dc=comエントリが作成され、personテンプレートでモデル化された1000個の他のエントリがその下に作成されます。personテンプレートは、テンプレート・ファイルで後で定義する必要があります。詳細は、第17.1.4.1.4項「テンプレート定義」を参照してください。

分岐エントリは、1つのsubordinateTemplate定義のみに限定されません。その分岐定義の別の行にsubordinateTemplate定義を含めることによって、それらを複数指定できます。次の例では、personテンプレートに基づいて1000個のエントリを作成し、certificatePersonテンプレートに基づいて別の100個のエントリを作成します:

branch: ou=People,dc=example,dc=com
subordinateTemplate: person:10000
subordinateTemplate: certificatePerson:100

前述のすべてのエントリにおいて、分岐エントリ自体には、DN、RDN属性、およびRDN属性と関連付けられたオブジェクト・クラスのみが含まれています。分岐エントリにその他の属性を含めるには、テンプレート・ファイルの分岐定義にそれらを含めます。たとえば、次のような分岐定義では:

branch: dc=example,dc=com
description: This is the description for dc=example,dc=com

次のエントリが作成されます:

dn: dc=example,dc=com
objectClass: top
objectClass: domain
dc: example
description: This is the description for dc=example,dc=com

この追加のテキストは、静的にするか、任意の定義済グローバル置換変数を含めるか、またはテンプレート定義で使用できる置換タグのサブセットを含めることができます。使用可能なタグの概要、および分岐定義でどのタグが使用できるかに関する情報は、第17.1.4.2.1項「標準置換タグ」を参照してください。

17.1.4.1.4 テンプレート定義

make-ldifテンプレート・ファイルの中心となるのは、一連のテンプレート定義です。テンプレートによって、生成されるエントリの構造が定義されます。エントリに含める一連の属性と、その属性に含める値のタイプを指定します。値の指定は、make-ldifによって解析されるタグによって処理され、それらのタグに適した値で置換されます。

テンプレート定義の例は、次のようになります:

template: person
rdnAttr: uid
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
givenName: <first>
sn: <last>
cn: {givenName} {sn}
initials: {givenName:1}<random:chars:ABCDEFGHIJKLMNOPQRSTUVWXYZ:1>{sn:1}
employeeNumber: <sequential:0>
uid: user.{employeeNumber}
mail: {uid}@[maildomain]
userPassword: password
telephoneNumber: <random:telephone>
homePhone: <random:telephone>
pager: <random:telephone>
mobile: <random:telephone>
street: <random:numeric:5> <file:streets> Street
l: <file:cities>
st: <file:states>
postalCode: <random:numeric:5>
postalAddress: {cn}${street}${l}, {st}  {postalCode}
description: This is the description for {cn}.

この例は、LDIFデータを作成するときにmake-ldifが提供する柔軟性を示しています。テンプレート定義に含めることができるタグは、後続の項で説明します(第17.1.4.2.1項「標準置換タグ」および第17.1.4.2.2項「属性値参照タグ」を参照してください)。

テンプレート定義の最上部には、テンプレート自体に関する情報を示す2つの行があり、このテンプレートから作成されるエントリには含まれません。最初の行は、テンプレートの名前を指定します。これは、分岐定義のsubordinateTemplate行で参照される名前です。2番目の行では、エントリのRDN属性として使用する属性の名前を指定します。そのRDN属性には、テンプレート定義の本文で値を割り当てる必要があり、値の割当て方法では、同じ親の下の同じテンプレートで作成されるすべての他のエントリの間でその値が必ず一意となるようにする必要があります。

注意:

次の例に示すように、プラス記号で属性名を区切ることで、複数の値を持つRDNを指定できます:

rdnAttr: uid+employeeNumber

複数の値を持つRDNを使用する場合、すべてのRDN属性について値をテンプレート本文で定義し、各エントリのRDN値の組合せが一意になっていることが必要です。ただし、組合せが重複しない場合は、そのRDN内で1つ以上の属性が一意でなくてもかまいません。

templateおよびrdnAttrの行に加えて、1つ以上のsubordinateTemplate行を含めることができます。これにより、動的に生成された他のエントリの下に動的に生成されたエントリを含めることができ(たとえば、各ユーザー・エントリの下に1つ以上のエントリがある場合)、複雑な階層にすることができます。ネストのこのレベルに対する制限はありませんが、同じテンプレートを使用して追加のエントリを直接または間接的に作成するsubordinateTemplateを設定することで再帰的ループが作成されないようにする必要があります。

テンプレート定義では、extendsキーワードの使用による継承の概念もサポートされています。たとえば、次のテンプレート定義から生成されるエントリには、指定されている形式でuserCertificate;binaryとともにpersonテンプレートで定義されているすべての属性が含まれます:

template: certificatePerson
rdnAttr: uid
extends: person
userCertificate;binary:: <random:base64:1000>

extendsキーワードを使用して複数の行を含めることで複数の継承が可能ですが、subordinateTemplateキーワードの場合と同様に、テンプレート・ファイルが、直接または間接的にそれ自体から継承される再帰的ループが作成されないようにすることが重要です。

17.1.4.2 make-ldifテンプレート・ファイル・タグ

make-ldifによって、多様なデプロイメントをシミュレートするために使用できるLDIFファイルを生成できるようにするために、テンプレートで使用するための多数のタグが定義されています。この項では、make-ldifテンプレート・ファイルで使用できる標準セットのタグについて説明します。第17.1.4.3項「カスタム・タグの定義」の説明に従って、カスタム・タグを作成することもできます。

この項には次のトピックが含まれます:

- 第17.1.4.2.1項「標準置換タグ」

- 第17.1.4.2.2項「属性値参照タグ」

- 第17.1.4.2.3項「タグの評価順序」

17.1.4.2.1 標準置換タグ

make-ldif標準置換タグは、山カッコで囲まれた特殊な要素(小なり記号(<)で始まり、大なり記号(>)で終わる)であり、生成された値に動的に置換されます。標準置換タグには、引数を必要としないもの(たとえば、<first>)があります。他のものは引数を取り、その場合、最初にタグ名、次にコロン、そして、各引数の間をコロンで区切った引数のリストが続きます(たとえば、<random:numeric:5>)。引数では、通常、大文字小文字が区別されますが、タグ名では大文字小文字が区別されまません。

次のタイプの標準置換タグは、現在、make-ldifの一部として組み込まれています:

DNタグ

DN標準置換タグは、現在のエントリのDNで置換されます。そのDNがまだ使用できない場合(生成されるエントリではRDN属性に値が割り当てられていないためなど)、それは空の文字列で置換されます。通常、このタグが使用される前に、先にテンプレート内ですべてのRDN属性に必ず値が割り当てられるようにします。

DNタグは、引数を指定せずに使用でき(たとえば、<DN>)、その場合、それが、そのエントリの完全なDNで置換されます。このタグは、1つの整数の引数を取ることもでき、それによって、出力に含めるコンポーネントの最大数を指定します。たとえば、タグ<DN:1>では、そのエントリの左端のDNコンポーネント(多くの場合、RDNと呼ばれる)のみが含められます。したがって、生成されるエントリのDNがuid=john.doe,ou=People,dc=example,dc=comである場合、タグ<DN:1>はuid=john.doeで置換されます。引数値が正ではなく負である場合、指定されている引数値の絶対値が使用され、DNの終わりからその数のコンポーネントを取ります。したがって、uid=john.doe,ou=People,dc=example,dc=comのDNを使用すると、タグ<DN:-1>はdc=comで置換されます。

このタグは、分岐とテンプレートの両方の定義で使用できます。

Fileタグ

File標準置換タグは、指定されているファイルの行で置換されます。1つまたは2つの引数が必要です。最初の引数は、データ・ファイルのバスである、絶対パスでもconfig/MakeLDIFディレクトリに含まれているファイルの名前(パス情報なし)のいずれでもかまいません。2番目の引数がある場合、それはsequentialとrandomのいずれかの値であることが必要で、それはファイル内の行を連続した順序で取得するか、ランダムに選択するかを示しています。2番目の引数を指定しない場合、値はランダムに選択されます。たとえば、タグ<file:cities>と<file:cities:random>のどちらでも、タグは、citiesファイルからランダムに選択した行で置換されますが、タグ<file:cities:sequential>では、市区町村名が連続した順序で取得されます。連続した順序が使用されていて、すべての値が使用し尽された場合、そのファイルの最初の行に戻ります。

make-ldifコマンドは、生成されたデータで使用できるいくつかの標準データ・ファイルをインクルードします。これらのファイルは、config/MakeLDIFディレクトリにインクルードされているため、ファイル名のみが必要です。このファイルには、次のものが含まれています:

cities: 一般的な市区町村名のリストが含まれています

first.names: 一般的な名のリストが含まれています

last.names: 一般的な姓のリストが含まれています

states: 米国の州を表す2文字の略語すべてのリストが含まれています

streets: 一般的な番地名のリストが含まれています

このタグは、分岐とテンプレートの両方の定義で使用できます。

Firstタグ

First標準置換タグは、config/MakeLDIF/first.namesファイルから取得された名前で置換されます。名前と姓の組合せが常に一意になるなど、<first>タグと<last>タグの間には特別な関係があります。名前ファイルと姓ファイルからの考えられる組合せをすべて使用し尽した場合、make-ldifによって、整数値が姓に追加され、値は確実に常に一意になります。

<first>タグは、引数を取りません。これは、テンプレート定義内でのみ使用できます。分岐定義で使用することはできません。

GUIDタグ

GUID標準置換タグは、ランダムに生成されたGUID (globally-unique identifier)値で置換されます。生成されたすべてのGUID値は、一意になります。生成される値は、それぞれ8、4、4、4および12桁からなるダッシュで区切られたグループに分かれている32桁の16進数です(たとえば、12345678-90ab-cdef-1234-567890abcdef)。

<guid>タグは、引数を取りません。これは、分岐とテンプレートの両方の定義で使用できます。

IfAbsentタグ

IfAbsent標準置換タグは、それ自体の値は生成せず、したがって、常に空の文字列で置換されます。ただし、その値によって、指定した属性または属性値が存在するかどうかに基づいて、エントリないに属性がまとめて表示されないようにすることができます。

たとえば、次のテンプレートについて考えてみます:

template: example
rdnAttr: cn
objectClass: top
objectClass: untypedObject
objectClass: extensibleObject
cn: <guid>
displayName: <presence:50>{cn}
description: <ifabsent:displayName>{cn}

この場合、description属性は、displayName属性が含まれていない場合のみ、生成されるエントリに含まれます(つまり、結果のエントリには、displayNameとdescriptionのいずれかのみが含まれ、両方が含まれることはありません)。

IfAbsentタグには、1つまたは2つの引数が必要です。最初の引数は、ターゲット属性の名前です。2番目の引数がある場合、それはターゲット属性に対して特定の値を指定します。値が指定されている場合、生成されるエントリにその値が含まれていると、IfAbsentタグがアクションを実行します。

このタグは、分岐とテンプレートの両方の定義で使用できます。

IfPresentタグ

IfPresent標準置換タグは、それ自体の値は生成せず、したがって、常に空の文字列で置換されます。ただし、その値によって、指定した属性または属性値が存在するかどうかに基づいて、エントリないに属性がまとめて表示されないようにすることができます。

たとえば、次のテンプレートについて考えてみます:

template: example
rdnAttr: cn
objectClass: top
objectClass: untypedObject
objectClass: extensibleObject
cn: <guid>
displayName: <presence:50>{cn}
description: <ifpresent:displayName>{cn}

この場合、description属性は、displayName属性も含まれている場合のみ、生成されるエントリに含まれます(つまり、結果のエントリには、どちらの属性も含まれないか、両方の属性が含まれるかのいずれかになります)。

IfPresentタグには、1つまたは2つの引数が必要です。最初の引数は、ターゲット属性の名前です。2番目の引数がある場合、それはターゲット属性に対して特定の値を指定します。値が指定されている場合、生成されるエントリにその値が含まれているときにのみ、IfPresentタグがアクションを実行します。

このタグは、分岐とテンプレートの両方の定義で使用できます。

Lastタグ

Last標準置換タグは、config/MakeLDIF/last.namesファイルから取得された姓で置換されます。名前と姓の組合せが常に一意になるなど、<first>タグと<last>タグの間には特別な関係があります。名前ファイルと姓ファイルからの考えられる組合せをすべて使用し尽した場合、make-ldifによって、整数値が姓に追加され、値は確実に常に一意になります。

<last>タグは、引数を取りません。これは、テンプレート定義内でのみ使用できます。分岐定義で使用することはできません。

Listタグ

List標準置換タグは、指定されている値のリストから選択された文字列で置換されます。使用される値は、Listタグの引数として指定する必要があります(少なくとも1つの引数を指定する必要があります)。オプションで、各値の後にセミコロンと、その値の相対的な重みを指定する整数値を続けることができます。値に重みが含まれていない場合、そのアイテムの重みは1と想定されます。重みは、それに関連する値がリスト内の他のすべての値と比較して選択される頻度を制御するために使用します。

たとえば、リストされているすべての色が同じ重みを持つ赤、緑、青の色のリストを選択するには、次のものを使用できます:

<list:red:green:blue>

赤い色を、他のいずれの色に対しても2倍の頻度で表示する場合は、次のものを使用できます:

<list:red;2:green;1:blue;1>

この場合、greenとblueの要素の後の1は、技術的には不要です。それは、重みを明示的に含まないアイテムの重みは1であるためですが、この例では明確にするために指定されています。

このタグは、分岐とテンプレートの両方の定義で使用できます。

ParentDNタグ

ParentDN標準置換タグは、生成されるエントリの親エントリのDNで置換されます。これは常に使用可能です。

このタグは、引数を取りません。これは、テンプレート定義内でのみ使用できます。これは分岐定義では使用できません。

Presenceタグ

Presence標準置換タグは、それ自体の値は生成せず、したがって、常に空の文字列で置換されます。ただし、その値は、関連付けられた属性を、指定した割合でエントリに表示するために使用できます。

たとえば、次のテンプレートについて考えてみます:

template: example
rdnAttr: cn
objectClass: top
objectClass: untypedObject
objectClass: extensibleObject
cn: <guid>
displayName: <presence:50>{cn}

この場合、displayName属性が存在するのは、生成されるエントリの約50%のみになります。

Presenceタグには、1つの引数が必要であり、それは0と100の間の整数値で、関連する属性を持つエントリの割合を示します。

このタグは、分岐とテンプレートの両方の定義で使用できます。

Randomタグ

Random標準置換タグは、ランダムに生成された値で置換されます。いくつかの異なるタイプの値を生成できます。このタグが取る引数の個数は可変ですが、最初の引数は、常に、生成する値のタイプを指定します。そのタイプは、次の値の1つにすることができます:

- alpha。これにより、タグは、指定された数の小文字のASCII英文字で置換されます(つまり、abcdefghijklmnopqrstuvwxyz)。これには、もう1つの引数が必要であり、それは生成される値に含まれる文字の数を指定する整数です。たとえば、<random:alpha:5>では、ランダムに選択された5つの英文字からなる文字列が生成されます。

- numeric。これにより、タグは、1つ以上の桁の数字で置換されます。1つまたは2つの追加の引数を指定できます。追加の引数が1つである場合、それは、その値に含まれる数字の桁数を指定します(たとえば、<random:numeric:5>では、5桁の数字の文字列が生成されます)。追加の引数が2つある場合、それらはランダムに生成される数の上限と下限を指定します(たとえば、<random:numeric:5:10>では、5から10までの間でランダムな整数が生成されます)。

- alphanumeric。これにより、タグは、指定された数の小文字のASCII英文字(つまり、abcdefghijklmnopqrstuvwxyz)または数値(つまり、キャラクタ・セット0123456789)、あるいはその両方で置換されます。これには、もう1つの引数が必要であり、それは生成される値に含まれる文字の数を指定する整数です。たとえば、<random:alphanumeric:5>では、ランダムに選択された英数字からなる文字列が生成されます。

- chars。これにより、タグは、ユーザー定義のキャラクタ・セットの文字で置換されます。これは、2つまたは3つの追加の引数を取ることができます。最初の追加の引数は、ユーザー定義のキャラクタ・セットの文字です。キャラクタ・セットの後に1つの引数がある場合、それは、そのセットから取得する文字の数を指定します(たとえば、<random:chars:abcd:3>では、3つの文字が選択され、それらの文字はa、b、cまたはdのいずれかです)。キャラクタ・セットの後に2つの引数がある場合、生成される文字の数はこの範囲内の整数になります(たとえば、<random:chars:abcd:3:5>では、その値に3から5個の文字が含められ、各文字はa、b、cまたはdのいずれかです)。

- hex。これにより、タグは、指定された数の16進文字で置換されます(つまり、0123456789abcdef)。これには、もう1つの引数が必要であり、それは生成される値に含まれる文字の数を指定する整数です。たとえば、<random:hex:5>では、ランダムに選択された5つの16進文字からなる文字列が生成されます。

- base64。これにより、タグは、指定された数のbase64キャラクタ・セットで許可される文字で置換されます(ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz01234567890+/)。これには、もう1つの引数が必要であり、それは生成される値に含まれる文字の数を指定する整数です。たとえば、<random:base64:5>では、ランダムに選択された5つの16進文字からなる文字列が生成されます。

- month。これにより、タグは、1年間のうちのいずれかの月の名前で置換されます。追加の引数がない場合、月の完全な名前が含められます(たとえば、<random:month>では、Octoberの値が返されます)。追加の引数が1つある場合、それは月の名前から含める文字の最大数を指定する整数値である必要があります(たとえば、<random:month:3>では、Octの値が生成されます)。

- telephone。これにより、タグは、123-456-7890の形式のランダムに生成された電話番号で置換されます。これは、追加の引数を取りません(つまり、常に<random:telephone>のように使用されます)。

このタグは、分岐とテンプレートの両方の定義で使用できます。

RDNタグ

RDN標準置換タグは、現在のエントリであるRDN(つまり、左端のDNコンポーネント)で置換されます。そのRDNがまだ使用できない場合(生成されるエントリではRDN属性に値が割り当てられていないためなど)、それが空の文字列で置換されます。通常、このタグが使用される前に、先にテンプレート内ですべてのRDN属性に必ず値が割り当てられるようにします。このタグの動作は、値が1である1つの引数を使用して使用されている場合(つまり、<dn:1>)のDNタグの動作と同一です。

RDNタグは、引数を取りません。これは、分岐とテンプレートの両方の定義で使用できます。

Sequentialタグ

Sequential標準置換タグは、1つの整数値で置換されます。各エントリには、連続して増加する値が指定されます(たとえば、最初のエントリにはゼロの値、次のエントリには1の値などのように指定されます)。

このタグは、ゼロ、1または2個の引数を取ることができます:

- 引数がない(つまり、タグが<sequential>である)場合、最初の値はゼロになり、その値は新しい分岐ごとにゼロにリセットされます。

- 追加の引数が1つある場合、それは、使用する初期値を指定する整数値である必要があります(たとえば、<sequential:1000>では、0のかわりに1000から値の生成を開始します)。値は、新しい分岐ごとに、指定した初期値にリセットされます。

- 引数が2つある場合は、最初のものは初期値を指定する整数であり、2番目のものは新しい分岐が始まるたびにカウンタをリセットするかどうかを示すtrueまたはfalseのブール値である必要があります。

このタグは、分岐とテンプレートの両方の定義で使用できます。

_DNタグ

_DN (先頭のアンダースコア文字に注意)標準置換タグは、生成されるエントリのDNで置換されますが、DNコンポーネント間ではカンマのかわりにアンダースコアが使用されます。カンマのかわりにアンダースコアを使用することを除けば、これは、DNタグとまったく同じように動作します。したがって、左から(値が負の場合は右から)、含めるコンポーネントの数を指定するオプションの整数引数も取ることができます。

このタグは、分岐とテンプレートの両方の定義で使用できます。

_ParentDNタグ

_ParentDN (先頭のアンダースコア文字に注意)標準置換タグは、生成されるエントリの親エントリのDNで置換されますが、DNコンポーネント間ではカンマのかわりにアンダースコアが使用されます。これは常に使用可能です。

このタグは、引数を取りません。これは、テンプレート定義内でのみ使用できます。これは分岐定義では使用できません。

17.1.4.2.2 属性値参照タグ

属性値参照タグは、同じエントリの指定した属性の値で、そのタグを置換するために使用できます。それは、目的の属性の名前を中カッコで囲むことによって使用されます。たとえば、{cn}は、ターゲット・エントリですでにcn属性に値が指定されている場合は、その値で置換されます。エントリでターゲット属性にまだ値が割り当てられていない場合、それは空の文字列で置換されます。

たとえば、テンプレートからの次の抜粋について考えてみます:

givenName: <first>
sn: <last>
uid: {givenName}.{sn}
cn: {givenName} {sn}
mail: {uid}@example.com

最初の名前に対して選択された値がJohnであり、最後の名前がDoeである場合、結果のLDIF出力は次のようになります:

givenName: John
sn: Doe
uid: John.Doe
cn: John Doe
mail: John.Doe@example.com

属性名の後にコロンを配置し、その後に、ターゲット属性から含める文字の最大数を指定する正の整数値を続けることもできます。たとえば、次のテンプレートの抜粋の場合:

givenName: <first>
sn: <last>
initials: {givenName:1}{sn:1}

次のLDIFが生成されます:

givenName: John
sn: Doe
initials: JD

指定した長さが、指定した属性の値よりも長い場合、埋込みが追加されることなく、その値全体が使用されます。それ以外の場合、指定した個数の文字がその値から取得されます。

17.1.4.2.3 タグの評価順序

make-ldif構文のすべてのタグには、現在、同一の優先度が指定されています。したがって、それらは、テンプレート定義内で配置されている順序で、上から下に、指定された行内では左から右に評価されます。別のタグ内に1つのタグを埋め込むことはできません。

17.1.4.3 カスタム・タグの定義

make-ldifユーティリティは、拡張可能に設計されているため、新しいタグをテンプレート・ファイル内で定義および使用できます。

すべてのタグは、org.opends.server.tools.makeldif.Tag抽象クラスのサブクラスであることが必要です。カスタム・タグ定義には、次のメソッドを含める必要があります:

public String getName()

これにより、タグを参照するために使用する名前が取得されます。それが返す値は、サーバーによって使用される他のすべてのタグの間で一意である必要があります。

public boolean allowedInBranch()

これは、そのタグが分岐定義で許可されるかどうかを示します。それがtrueの値を返す場合、そのタグは、分岐とテンプレートの両方の定義で使用できます。それがfalseの値を返す場合、そのタグは、テンプレート定義で使用できますが、分岐定義では使用できません。

public void initializeForBranch(TemplateFile templateFile, Branch branch, String[] arguments, int lineNumber, List<String> warnings)

これは、タグが分岐定義で使用される場合に必要な初期化を実行します。allowedInBranch()がfalseを返す場合は、これを実装する必要はありません。

public void initializeForTemplate(TemplateFile templateFile, Template template, String[] arguments, int lineNumber, List<String> warnings)

これは、タグがテンプレート定義で使用される場合に必要な初期化を実行します。

public void initializeForParent(TemplateEntry parentEntry)

これは、新しい親の下でのエントリの生成を開始する前に必要な初期化を実行します。特別な初期化が不要な場合、これを実装する必要はありません。

public TagResult generateValue(TemplateEntry templateEntry, TemplateValue templateValue)

これは、エントリを生成するときに、関連付けられたタグを置換するために使用される値を生成します。

make-ldifで使用可能なタグはすべて、org.opends.server.tools.makeldifパッケージに含められています。それらは、カスタム・タグの実相に何が関与しているのかを把握するための参照に使用できます。

注意:

カスタム・タグを定義する場合、それを必要とする可能性があるテンプレート・ファイルで使用できるようになっているいことを確認してください。これは、include文を使用して実行され、それはテンプレート・ファイルの先頭に配置する必要があります。詳細は、第17.1.4.1.1項「カスタム・タグのインクルード」を参照してください。

17.2 大規模データ・セットのインポート

この項では、ディレクトリ・サーバーに大きなデータ・セットをインポートする際のパフォーマンスの向上に関するヒントを示します。デフォルトでは、サーバーは、固定したセットのパラメータでデータをインポートします。デフォルトの動作を変更するには、次の2通りがあります:

- import-ldifコマンドを実行する際は、特定のオプションを指定します。
詳細は、第17.2.1項「インポート・オプションの設定」を参照してください。

- import-ldifコマンドを実行する前に、dsjavapropertiesコマンドを使用して、適切なJava引数を設定します。
詳細は、第17.2.2項「JVMおよびJava引数のチューニング」を参照してください。

17.2.1 インポート・オプションの設定

import-ldifコマンドの次のオプションは、特に大きなデータベースをインポートする場合に便利です:

- --skipDNValidation
このオプションでは、インポートの最初のフェーズでDNの検証もデータベースのロードも実行されないため、大量のインポートが大幅に高速化されます。LDIFファイルのDNは、通常の索引として処理され、インポートのフェーズ2でロードされるスクラッチ索引ファイルに書き込まれます。

インポートの2番目のフェーズ中に、限られたDN親チェックが実行されます。この評価中に、LDIFファイル内のDNが調べられ、各DNが適切な親DNを持っていることが確認されます。親のないDNが検出された場合、ダミーのエントリが拒否ファイルに書き込まれます。

--skipDNValidationオプションが指定されている場合、重複したDNのチェックは実行されません。

インポートのフェーズ2中に索引データベースから不適切なエントリIDがサーバーによって削除されることはありません。したがって、--skipDNValidationオプションが指定されている場合は、そのLDIFインポート・ファイルが適切であることが不可欠です。適切なLDIFファイルとは、通常、make-ldifコマンドを使用して生成されたもの、LDAPサーバーからエクスポートされたLDIFファイル、または適切なLDIFを生成することが履歴からわかっているスクリプトによって作成されたLDIFファイルです。

- --threadCount
このオプションでは、より多くのスレッドをインポート・プロセス専用に指定可能にすることで、大量のインポートが高速化されます。デフォルトでは、CPUごとに2つのスレッドがインポート操作に使用されます。

--thread-countを増やすと、LDIFインポートのフェーズ1に必要なバッファ領域も増えます。

- --tmpDirectory
インポートの最初のフェーズでは、サーバーによってLDIFファイルが解析され、索引レコードがソートされ、レコードが一時ファイルに書き込まれます。デフォルトでは、一時索引ファイルがintall-dir/import-tmpに書き込まれます。特に大きな索引ファイルをインポートする場合、より大きいディスク領域がある別の場所を指定することもできます。

一時索引ファイルに必要な領域の容量は、次の要因に応じて異なります:

- LDIFファイル内のエントリの数。

- LDIFファイル内のエントリのサイズ。
索引付けを必要とする属性の数が多いエントリでは、一時ディレクトリの場所およびデータベース・ディレクトリで必要とされる領域が、より多くなります。

- 構成される索引の数。
構成される索引数が多くなるほど、一時ディレクトリの場所およびデータベース・ディレクトリで必要とされるディスク領域が多くなります。部分文字列索引では、処理するために他のタイプの作成よりも多くの一時ディスク領域が必要になります。

- すべての作成または個々の索引に対してindex-entry-limitを増やすと、より多くのディスク領域が必要になります。
これは、特に部分文字列索引の場合に該当します。多数のエントリを含むLDIFファイルをインポートする場合、複数の索引レコードがindex-entry-limitをヒットしないように、すべての部分文字列索引をオフにする必要があります。

17.2.2 JVMおよびJava引数のチューニング

JVMヒープのチューニングは、import-ldifコマンドのパフォーマンスに不可欠です。import-ldifコマンドでは、それが必要とするJVMヒープの容量を制限することが試みられますが、多数のエントリをインポートする場合、可能なかぎり多くのJVMヒープをimport-ldifに割り当てる必要があります。

次のJVMチューニングの考慮事項は、import-ldif操作に特定の影響があります:

- オンライン・インポートの実行では、サーバーが起動されたときに指定されたJVM設定が使用されます。オンライン・インポートを使用することで大きなLDIFファイルをインポートする予定である場合、サーバーを起動するときに追加のJVMヒープを指定する必要があります。一般的に、大きなLDIFファイルをインポートする必要がある場合、最良の選択肢は、オフライン・インポートを実行することです。

- 32ビットのJVMは通常、小規模なLDIFファイル、および大規模なLDIFファイルのほとんどでパフォーマンスが高くなります。
常に、最初にこのJVMを、可能なかぎり大きいヒープを設定して試す必要があります。最小ヒープは2 GBをお薦めします。

- 極端に大きいLDIFファイルでは、エントリのサイズと構成されている索引に応じて、大きなJVMヒープ(4 GBを超える)を設定した64ビットのJVMが必要な場合もあります。
64ビットのJVMは、通常、32ビットのJVMほどパフォーマンスは高くありません。

- デフォルトのJVMエルゴノミクスでは、いくつかのJVMに対して小さすぎて、パフォーマンスに重大な影響を与えることができます。
ご使用のJVMのデフォルト・エルゴノミクス値を書き留めてください(これらの値はベンダーごとおよびオペレーティング・システムごとに異なります)。

- レプリケーションを使用している場合、特にオンライン・インポート後に、トポロジの他のレプリカの完全な初期化を実行する予定である場合は、追加のJVMヒープを計画する必要があります。

- 大量のインポートに対しては、パラレル・ガベージ・コレクションを有効化します。

- 並行Mark Sweep (CMS)ガベージ・コレクタを使用します。このオプションを使用すると、JVMにおけるLDAP操作のレスポンス時間を最小化できますが、サーバーの全体的なパフォーマンス(スループット)に若干の影響を与える可能性があります。

メモリー要件を計算する場合は、次の手順を実行します:

1. instance-dir/OUD/config/java.propertiesファイルを編集し、次の値を設定します:

overwrite-env-java-args=true
import-ldif.offline.java-args=-Xms2560M -Xmx2560M -XX:+UseParallelGC -XX:+UseConcMarkSweepGC

2. dsjavapropertiesコマンドを実行します:

$ bin/dsjavaproperties

注意:

dsjavapropertiesコマンドの実行またはOPENDS_JAVA_ARGS環境変数の設定がパフォーマンスに影響を及ぼすのは、インポートがオフラインである場合のみです。サーバーがすでに実行中であり、オンライン・インポートを実行する場合、Java引数を変更しても、インポートのパフォーマンスに影響を与えることはありません。それは、インポートはサーバーJVMによって実行されるためです。

17.3 データのバックアップおよびリストア

Oracle Unified Directoryは、様々なリポジトリ・タイプをサポートする拡張可能なフレームワークを提供します。ディレクトリ・サーバーは、そのプライマリ・バックエンドとしてBerkeley DB Java Edition (JE)を使用します。JEバックエンドには、他のデータベースと比較していくつかの利点があります。それは、それが、データ・セット(小さなものから非常に大きなものまで)に対して、ACIDセマンティクスに対する完全なサポートとともに、高性能かつスケーラブルなトランザクショナルBツリー・データベースを提供するためです。また、そのエントリを、エンコードされた形式で格納し、高速かつ効率的なデータ取得のための索引を提供することも可能です。

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

- 第17.3.1項「バックアップおよびリストアのプロセスの概要」

- 第17.3.2項「データのバックアップ」

- 第17.3.3項「サーバー構成のバックアップ」

- 第17.3.4項「障害時リカバリのためのバックアップ」

- 第17.3.5項「ファイル・システム・スナップショットを使用したデータのバックアップおよびリストア」

- 第17.3.6項「データのリストア」

- 第17.3.7項「レプリケートされたディレクトリ・サーバーのリストア」

17.3.1 バックアップおよびリストアのプロセスの概要

JEバックエンドにディレクトリ・データを保持するために、Oracle Unified Directoryは、全体バックアップおよび増分バックアップをサポートする効率的なバックアップおよびリストア・ユーティリティを備えています。全体バックアップでは、ディレクトリ・データ・ファイルが、圧縮済アーカイブ・ファイルとして環境に保存されます。増分バックアップでは、前回のバックアップ以降に書き込まれたファイルのみが、前回のバックアップ以降に変更されていないファイルの名前のリストとともに保存され圧縮されます。Oracle Unified Directoryでは、リストアを簡単にするためにバックアップ・バックエンドにそのバックアップ情報が格納されます。

ディレクトリ・サーバー・バックアップは、ローカル・ディスク上またはリモート・ディスク上で、たとえば、ネットワーク接続ストレージ(NAS)で実行できます。ローカルでバックアップを実行する場合、セキュリティ上の理由から、別のマシンまたはファイル・システムにバックアップをコピーして保存します。

データのバックアップとリストアを開始する前に、次の事項を考慮します:

- ご使用のディレクトリ・サービス・システムに対して実行可能なバックアップおよびリストア計画を設計する必要があります。たとえば、増分バックアップを毎日実行し、全体バックアップを少なくとも週に1回実行することができます。バックアップ・プロセスおよびリストア可能かどうかを定期的にテストしてください。データをリストアするために、多くの会社では、レプリケートされたサーバーからディレクトリ・サーバーをリストアし、それによって、ディレクトリ・データの最も更新されているコピーが使用されるようにしています。ディレクトリ・データが損傷し(たとえば、エントリが欠落し)、損傷したデータが他のサーバーにレプリケートされた場合には、バックアップ・テープが必要になります。

- 障害時リカバリ計画が策定済であることを確認します。障害時リカバリは、破局的なイベント、データ破損、またはデータの不正操作が発生した場合に必要です。企業は、独自の計画を策定するか、サード・パーティの専門家にその作業をアウトソーシングします。詳細は、第17.3.4項「障害時リカバリのためのバックアップ」を参照してください。

- バックアップを格納する場所が確保されていることを確認します。アーカイブ済データ、構成ディレクトリ、スキーマ・サブディレクトリ、およびご使用のサーバーのインストール・ディレクトリを、1つの場所にまとめて保存します。これらのアイテムはすべて、サーバーをリストアするときに必要です。

17.3.2 データのバックアップ

ディレクトリ・サーバーは、データベースをバックアップするための効率的なコマンドライン・ユーティリティ(backup)を備えています。backupコマンドは、ただちに実行することも、タスクとしてスケジュールすることもできます。バックアップがスケジュール済の場合、このコマンドは管理コネクタを使用してSSL経由でサーバーにアクセスし、バックアップ・タスクを登録します。接続オプションが指定されていない場合、このコマンドはただちに実行されます。

次の手順は、様々なバックアップ・シナリオにおけるbackupコマンドの使用を示しています。

17.3.2.1 すべてのバックエンドをバックアップする方法

--backUpAllオプションを使用することで、すべてのバックエンドをバックアップできます。

次のコマンドは、スタンドアロン・ディレクトリ・サーバーで実行され、すべてのデータベースをバックアップすることを指定し、バックアップ・ファイルを圧縮し、ファイルを指定した場所に保存します。

$ backup --backUpAll --compress --backupDirectory /tmp/backup

このバックアップ・ディレクトリには、各バックエンドのサブディレクトリが含まれています:

$ ls /tmp/backup
./ ../ config/ schema/ tasks/ userRoot/

backupユーティリティによって、指定したディレクトリにバックアップが書き込まれ、バックアップに関する詳細を示すbackup.infoファイルが作成されます。ディレクトリ・サーバーによって、現在の日付と時刻に基づいたバックアップIDが割り当てられます。独自のIDを作成するには、--backupIDオプションを指定します:

$ ls /tmp/backup/config
./ backup.info
../ config-backup-20070827153501Z

backup.infoファイルには、現行のバックアップに関する詳細情報が含まれます。

$ more /tmp/backup/config/backup.info
backend_dn=ds-cfg-backend-id=config,cn=Backends,cn=config

backup_id=20070827153501Z
backup_date=20070827153511Z
incremental=false
compressed=true
encrypted=false
property.archive_file=config-backup-20070827153501Z

17.3.2.2 暗号化および署名付きハッシュを使用してすべてのバックエンドをバックアップする方法

backupユーティリティは、セキュアなバックアップのために暗号化および署名付きハッシュのサポートを提供しています。暗号化および署名付きハッシュ・オプションを使用するには、オンライン・サーバー・インスタンスへの接続が必要であるため、適切な接続オプションを指定する必要があります。

backupコマンドを実行します。

次のコマンドは、すべてのバックエンドをバックアップし、それらを圧縮し、ハッシュを生成し、ハッシュに署名し、そのデータを暗号化します。

$ backup -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --backUpAll \
-X --compress --hash --signHash --encrypt --backupID 123 \
--backupDirectory /tmp/backup

17.3.2.3 すべてのバックエンドで増分バックアップを実行する方法

増分バックアップでは、最後のバックアップ(増分または全体)以降に発生した変更のみが保存されます。増分バックアップの主な利点は、全体バックアップと比べてシステムのバックアップが高速であることです。増分バックアップの短所は、各増分バックアップをリストアする必要があり、全体リストアよりも時間と注意が必要なことです。

増分バックアップを実行するには、次のように--incrementalオプションを指定してbackupコマンドを実行します:

$ backup --backUpAll --incremental --compress --backupDirectory /tmp/backup

17.3.2.4 特定のバックエンドをバックアップする方法

保存するバックエンドを指定する--backendIDオプションを使用することによって、1つのバックエンドバックアップできます。

1. list-backendsコマンド実行することによって、サーバー上に構成されているバックエンドをリストします。例:

$ list-backends

Backend ID     Base DN
-------------- -----------------
adminRoot      cn=admin data
ads-truststore cn=trust-store
backup         cn=backups
config         cn=config
monitor        cn=monitor
schema         cn=schema
tasks          cn=tasks
userRoot       dc=example,dc=com

2. --backendIDオプションを指定してbackupコマンドを実行します。
たとえば、userRootバックエンドをバックアップするには、次のコマンドを実行します:

$ backup --backendID userRoot --backupDirectory /tmp/backup

1つはバックエンドバックアップし、レプリケーションが構成されている場合、そのバックエンドに行うすべての変更は、レプリケーション・サーバーの変更ログに格納されます。そのバックエンドをリストアするときに、レプリケーション・サーバーによってそのバックエンドが最新のものではないことが検出され、そのバックアップ以後に行われた変更がリプレイされます。この動作は、レプリケートされたトポロジ内のディレクトリ・サーバーが1つのみである場合でも実行されます。それは、変更がレプリケーション・サーバーに保存されているためです。

この動作を実行しないようにするには、レプリケートされた環境にすべてのバックエンドをバックアップします。これによって、データおよびレプリケーション・サーバーがバックアップされます。この場合、リストアが行われる際、ディレクトリ・サーバーおよびレプリケーション・サーバーはバックアップ前の状態にリストアされ、後続の変更はメモリー内に残りません。

17.3.2.5 特定のバックエンドに対して増分バックアップを実行する方法

1. list-backendsコマンド実行することによって、サーバー上に構成されているバックエンドをリストします。例:

$ list-backends

Backend ID     Base DN
-------------- -----------------
adminRoot      cn=admin data
ads-truststore cn=trust-store
backup         cn=backups
config         cn=config
monitor        cn=monitor
schema         cn=schema
tasks          cn=tasks
userRoot       dc=example,dc=com

2. --incrementalオプションを指定してbackupコマンドを実行します。

$ backup --incremental --backendID userRoot --backupDirectory /tmp/backup

17.3.2.6 バックアップをタスクとしてスケジュールする方法

ディレクトリ・サーバーは、バックアップやリストアなどの管理タスクを実行するためにタスク・バックエンドを提供しています。-tまたは--startオプションを使用することで、バックアップまたはリストアの開始時間を指定できます。これらのオプションを指定しない場合、タスクのスケジュール後ただちにユーティリティは終了します。ただちに実行するようにタスクをスケジュールし、タスクのスケジュール後ただちにユーティリティを終了するには、開始時間の値として0を指定します。-tまたは--startオプションを省略すると、ユーティリティは、タスクをただちに実行するようにスケジュールし、タスクの進行状況を追跡し、ログ・メッセージを使用できるように出力し、タスクが完了したときに終了します。

タスク・バックエンドへのアクセスは、管理コネクタを介してSSL経由で提供されます。したがって、バックアップをタスクとしてスケジュールする場合、SSL証明書の信頼方法を指定する必要があります。この例では、バックアップを将来の時刻に実行するようにスケジュールします。-Xオプションは、サーバーによって定義されるすべての証明書を信頼することを指定します。詳細は、第14.3項「サーバーへの管理トラフィックの管理」を参照してください。

1. 次のオプションを指定してbackupコマンドを実行します:

$ backup --port 4444 --bindDN "cn=Directory Manager" \
--bindPasswordFile pwd-file -X \
--backUpAll --backupDirectory /tmp/backups --start 20080601121500 \
--completionNotify admin@example.com --errorNotify admin@example.com

2. manage-tasksコマンドを使用することで、このスケジュール済タスクに関する情報を表示します。例:

$ manage-tasks --port 4444 --bindDN "cn=Directory Manager" \
--bindPasswordFile pwd-file -X --info 2008040210324704 --no-prompt

17.3.3 サーバー構成のバックアップ

ディレクトリ・サーバー・インスタンスのすべての構成設定は、configディレクトリにあるconfig.ldifファイルに保存されます。構成内で変更が適切に認識されるように、config.ldifファイルはディレクトリ・サーバーによって自動的に保存されます。ファイルは、次の2つの特定の時間に保存されます:

- 起動時。現在の構成がアーカイブされた構成に一致しない場合は、サーバーによってconfig.ldifファイルが保存されます。

- 変更時。サーバーがオンラインになっている状態でディレクトリ管理者がdsconfigユーティリティを使用して構成を変更するたびに、ディレクトリ・サーバーによって、変更前にconfig.ldifファイルが保存されます。

アーカイブされた構成ファイルにはINSTANCE_DIR/OUD/config/archived-configsディレクトリからアクセスできます。このディレクトリによって、各保存済構成ファイルがリストされ、それが.gzファイルとして圧縮され、構成がconfig-timestamp.gzとして保存されます。たとえば、アーカイブ済config.ldifファイルを次のように表示できます:

$ ls config/archived-configs
09/02/2010 03:43 PM 9,045 config-20100819055359Z.gz

17.3.4 障害時リカバリのためのバックアップ

ディレクトリ管理者およびシステム管理者は、自然障害、人為的障害、または破局的な障害が発生した場合の障害時リカバリ計画を策定しておく必要があります。ディレクトリ・サービスが複数の個別のサーバーに分散されている場合、すべてのサーバーを個別にバックアップするか、すべてのディレクトリ・データを中央からバックアップします。

かわりに、バックアップおよびリストア計画としてレプリケーションを検討してください。レプリケーションは、別のレプリケートされたサーバーからのより高速なリストアおよびより更新されたデータを提供します。詳細は、第17.3.7項「レプリケートされたディレクトリ・サーバーのリストア」を参照してください。

17.3.4.1 障害時リカバリのためにディレクトリ・サーバーをバックアップする方法

1. --backUpAllオプションを使用することですべてのバックエンドのバックアップを実行します。例:

$ backup --backUpAll --backupDirectory /tmp/backup

2. 構成ディレクトリINSTANCE_DIR /OUD/configをコピーします。
schemaサブディレクトリがINSTANCE_DIR /OUD/configディレクトリ内に存在していることを確認します。

3. INSTANCE_DIR/OUD/logs内のファイルをコピーします。

4. インストール・ディレクトリのコピーを作成します。

5. アーカイブ済データ、構成ディレクトリ、スキーマ・サブディレクトリ、ログ・ファイルおよびインストール・ディレクトリを、1つの場所にまとめて保存します。
サーバーをリストアするときにはすべてのアイテムが必要です。

17.3.5 ファイル・システム・スナップショットを使用したデータのバックアップおよびリストア

特定のデプロイメントに対して、ファイル・システム・スナップショット・テクノロジは、従来のバックアップに対する実行可能な代替手段を提供します。Solarisシステムでは、ZFSによって、領域効率がよく、迅速に作成でき、システム間で移植可能なファイル・システム・スナップショットが可能です。データ・センターごとに1つ、または2つ(1つのデータ・センターでサービス全体を実行している場合)の専用ディレクトリ・サーバーを使用している場合は、障害時リカバリ計画の一部としてデータをリストアするために有効かつ冗長なソリューションをデプロイします。

この項には次のトピックが含まれます:

- 第17.3.5.1項「専用バックアップ・サーバーでZFSスナップショットを取る方法」

- 第17.3.5.2項「ZFSスナップショットからディレクトリ・サーバーをリストアする方法」

17.3.5.1 専用バックアップ・サーバーでZFSスナップショットを取る方法

1. ディレクトリ・サーバーは、バックアップ専用であるため、まだサーバーを読取り専用のレプリカとして構成していない場合は、そのように構成します。

$ dsconfig -h host -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
set-global-configuration-prop --set writability-mode:internal-only

読取り専用のレプリカのスナップショットからサーバーをリストアする場合、リストアされるサーバーは、トポロジ内の他のレプリカと情報交換した後、書込み可能に設定されるまではレプリケーション・トラフィックのみを受け入れます。

2. ZFSスナップショットを取ります。
たとえば、ディレクトリ・サーバー・ファイルが、zpool/DS_FSに対応するファイル・システムに格納されている場合、このコマンドは次のとおりです:

$ zfs snapshot zpool/DS_FS@{todays_date}

3. スナップショットを他のストレージにバックアップします。

$ zfs send zpool/DS_FS@{today_date} > /backups/DS_FS.{today_date}.zfs

スナップショットをレプリケーションのパージ遅延より長く保持しないでください。それは、スナップショットからリストアするときに、レプリケーション・メカニズムによって、レプリカ上のすべての欠落している変更内容がリプレイ可能であることが必要なためです。

17.3.5.2 ZFSスナップショットからディレクトリ・サーバーをリストアする方法

1. バックアップzpoolをインポートします。
マウント・ポイントとして/backupsを使用して、バックアップ・プールにアクセスするためのZFSファイル・システムを作成します。

2. リストア対象のディレクトリ・サーバーを停止します。

3. /backupsからZFSファイル・システムを初期化します。

$ dd if=/backups/DS_FS.{date_to_restore}.zfs bs=32k | zfs receive -F zpool/DS_FS

4. リストアするディレクトリ・サーバーのホスト名とポート番号を使用するように、必要に応じて構成を変更します。

5. ディレクトリ・サーバーを起動します。

6. ディレクトリが、トポロジ内の他のレプリカと同期していることが確認されるまで、レプリケーションを監視します。

7. writability-modeをenabledに設定し、ディレクトリ・サーバーが、クライアントからの書込み操作を処理できるようにします。

$ dsconfig -h restored-host -p 4444 -D "cn=Directory Manager" -j pwd-file -X \
-n set-global-configuration-prop --set writability-mode:enabled

17.3.6.4 データのリストア

restoreユーティリティを使用してデータをリストアできます。restoreユーティリティでは、一度に1つのバックエンドのみリストアできます。リストア・タスクをスケジュールしている場合、または署名またはハッシュされたデータをリストアする場合以外は、リストアする前にディレクトリ・サーバーを停止しておく必要があります。

この項には次のトピックが含まれます:

- 第17.3.6.1項「バックエンドをリストアする方法」

- 第17.3.6.2項「増分バックアップからバックエンドをリストアする方法」

- 第17.3.6.3項「リストアをタスクとしてスケジュールする方法」

- 第17.3.6.4項「構成ファイルをリストアする方法」

- 第17.3.6.5項「障害時リカバリ中にディレクトリ・サーバーをリストアする方法」

17.3.6.1 バックエンドをリストアする方法

1. サーバーが実行中である場合は、それを停止します。

2. --listBackupsオプションを指定してrestoreコマンドを実行することでバックアップ情報を表示します。例:

$ restore --listBackups --backupDirectory backup/userRoot
Backup ID: 20080827153501Z
Backup Date: 27/Aug/2008:10:35:11 -0500
Is Incremental: false
Is Compressed: true
Is Encrypted: false
Has Unsigned Hash: false
Has Signed Hash: false
Dependent Upon: none

3. バックエンドをリストアします。

$ restore --backupDirectory backup/userRoot

4. 他のバックエンドに対してリストアを繰り返します。

17.3.6.2 増分バックアップからバックエンドをリストアする方法

通常、システム管理者は、増分バックアップを毎日、全体バックアップを毎週実行します。増分バックアップからのシステムのリストアのほうが時間が長くかかることに注意してください。

1. restoreコマンドを使用することで、システム上に最新の全体バックアップをリストアします。
各バックエンドは、個別にリストアする必要があります。

2. restoreコマンドを使用することで、各増分バックアップをリストアします。
最新の全体バックアップから開始して、各増分バックアップをリストアします。

17.3.6.3 リストアをタスクとしてスケジュールする方法

ディレクトリ・サーバーは、バックアップやリストアなどの管理タスクを実行するためにタスク・バックエンドを提供しています。-tまたは--startオプションを使用することで、リストアの開始時間を指定できます。これらのオプションを指定しない場合、タスクのスケジュール後ただちにユーティリティは終了します。ただちに実行するようにタスクをスケジュールし、タスクのスケジュール後ただちにユーティリティを終了するには、開始時間の値として0を指定します。-tまたは--startオプションを省略すると、ユーティリティは、タスクをただちに実行するようにスケジュールし、タスクの進行状況を追跡し、ログ・メッセージを使用できるように出力し、タスクが完了したときに終了します。

タスク・バックエンドへのアクセスは、管理コネクタを使用してSSL経由で提供されます。したがって、リストアをタスクとしてスケジュールする場合、SSL証明書の信頼方法を指定する必要があります。

1. スケジュール済のリストア時間の前にサーバーが停止されていることを確認します。

2. restoreコマンドの-tまたは--startオプションを使用することによって、リストアをスケジュールします。
次のコマンドは、--startオプションを使用することでスケジュールされた開始時間にuserRootバックエンドをリストアします。リストアによって、admin@example.comに完了およびエラーの通知が送信されます。-Xオプションは、サーバーによって定義されるすべての証明書を信頼することを指定します。

$ restore -p 4444 -D "cn=Directory Manager" -j pwd-file -X \
-d /backup/userRoot --start 20080125121500 --completionNotify admin@example.com \
--errorNotify admin@example.com

3. manage-tasksユーティリティを使用することで、このスケジュール済タスクを表示できます。
詳細は、第14.4項「タスクとしてのコマンドの構成」を参照してください。

17.3.6.4 構成ファイルをリストアする方法

場合によっては、障害時リカバリ目的で、または他のイベントのために、別のサーバーに構成を転送するための構成ファイルをリストアする必要があります。一般に、サーバーがオンラインである場合、現在の構成ファイルは、最後にアーカイブした構成ファイルと同一です。ただし、前の日付のものからconfig.ldifファイルをリストアすることを選択できます。

1. サーバーが実行中である場合は、それを停止します。

2. システム上で必要な構成ファイルを特定します。例:

$ ls INSTANCE_DIR/OUD/config/archived-configs
./
../
config-20110817192057Z.gz
config-20110827153200Z.gz
config-20110817192052Z.gz
config-20110827153214Z-2.gz

3. gunzipなでの解凍ユーティリティを使用して、アーカイブ済構成ファイルを手動で解凍します。

4. そのファイルをconfigディレクトリにコピーし、現在のconfig.ldifファイルを置き換えます。

$ cp config-20110817192057Z INSTANCE_DIR/OUD/config/config.ldif

17.3.6.5 障害時リカバリ中にディレクトリ・サーバーをリストアする方法

1. ホストに前にインストールされていたディレクトリ・サーバーと同じバージョンをインストールします。

2. setupコマンドを使用して、サーバー・インスタンスを作成します。

3. 保存済のconfigディレクトリをINSTANCE_DIR /OUD/configにコピーします。
config.ldifファイルは、このディレクトリに配置されています。保存済のスキーマ・サブディレクトリは、INSTANCE_DIR/OUD/config/schemaに配置されています。

4. リストアしたサーバーの構成が正しいことを確認します。

5. restoreコマンドを使用することで個々のバックエンドをリストアします。

17.3.7 レプリケートされたディレクトリ・サーバーのリストア

レプリケートされた環境でバイナリ・リストアを実行するには、レプリケートされたトポロジに応じた特別な注意が必要です。可能な場合は、バックアップからのリストアではなく、ご使用のシステムのレプリケーション・メカニズムを使用することでバックエンドを更新してください。従来のテープによるバックアップと比較して、レプリケーションには明確な利点があります。データのリストアは、テープによるリストアよりも大幅に高速であり、データは、より最新の状態に保たれます。ただし、テープは、依然として、レプリケートされたデータが破損していて、他のサーバーに伝播された場合に必要になります。

レプリケートされたサーバーをリストアする場合は、構成ファイルINSTANCE_DIR/OUD/config/config.ldifが、バックアップが実行されときと同一であることを確認します。サーバー・バックエンドをリストアする前に、config.ldifファイルをリストアします。

古いバックアップをマスター・サーバーにリストアすることはできません。最新でない可能性があるためです。かわりに、レプリケーション・メカニズムが、マスターを読取り専用に設定することで、他のマスター・サーバーを使用してそのマスターを最新の状態にできるようにします。マスターが同期されたら、それを読取り/書込みにリセットできます。

レプリケートされたサーバーをリストアする必要がある場合は、LDIFファイルをインポートすることで、他のレプリケートされたサーバーの1つからサーバーを再初期化します。

大規模データベース(数百万のエントリ)の場合は、1つのサーバーのバイナリ・コピーを作成し、それを他のレプリケートされたサーバー上でリストアします。

比較的最近のバックアップ(他のレプリケートされたサーバーの変更ログの内容の最大保持時間よりも古くないもの)がある場合、そのバージョンを使用してデータをリストアできます。古いバックアップをリストアすると、他のサーバーによって、そのバックアップを保存した後に行われた最近の更新でそのサーバーが更新されます。

17.3.8 バックアップ・データの削除

通常のバックアップを実行する場合、そのバックアップ・ファイルが、多すぎるディスク領域を消費し始めることがあります。古いバックアップ・ファイルを手動で削除し、新しいもの向けの領域を作る必要があります。

17.3.8.1 バックアップ・ファイルを削除する方法

手動でバックアップ・ファイルを削除するときは、バックアップのセット間の依存関係を壊さないようにします。

1. バックアップ・ディレクトリ内の既存のバックアップをリストします。
たとえば、デフォルト・バックアップ・ディレクトリ内のバックアップをリストするには、次のコマンドを実行します:

UNIX: $ ls INSTANCE_DIR/OUD/bak
backup-userRoot-20110929184101Z backup-userRoot-20111029184509Z
backup.info backup.info.save

WINDOWS: C:\> dir INSTANCE_DIR\OUD\bak
backup-userRoot-20110929184101Z backup-userRoot-20111029184509Z
backup.info backup.info.save

2. バックアップ・ディレクトリからバックアップ・ファイルを削除します。
たとえば、前の手順でuserRootデータベースの最も古いバックアップを削除するには、次のコマンドを実行します:

UNIX: $ rm INSTANCE_DIR/OUD/bak/backup-userRoot-20110929184101Z

WINDOWS C:\> del INSTANCE_DIR\OUD\bak\backup-userRoot-20110929184101Z

3. backup.infoファイルから関連するバックアップ情報を削除します。
次のようにして、backup.infoの内容を表示できます(UNIXシステムの場合):

$ more INSTANCE_DIR/OUD/bak/backup.info
backend_dn=ds-cfg-backend-id=userRoot,cn=Backends,cn=config

backup_id=20110929184101Z
backup_date=20110929184104Z
incremental=false
compressed=false
encrypted=false
property.last_logfile_name=00000000.jdb
property.last_logfile_size=160773
property.archive_file=backup-userRoot-20110929184101Z

backup_id=20111029184509Z
backup_date=20111029184512Z
incremental=false
compressed=false
encrypted=false
property.last_logfile_name=00000000.jdb
property.last_logfile_size=160773
property.archive_file=backup-userRoot-20111029184509Z

Windowsシステムの場合、適切なテキスト・エディタを使用します。

17.4 ディレクトリ・データの検索

ディレクトリ・サーバーは、検索機能およびフィルタの形式の高性能なルックアップ操作など、LDAPv3対応のコマンドライン・ツールのスイートを備えています。Oracle Directory Services Managerを使用してディレクトリ・データを検索することもできます。この項では、ldapsearchコマンドライン・ユーティリティおよびOracle Directory Services Managerを使用してディレクトリ内のエントリを見つける方法について説明します。

この項には次のトピックが含まれます:

- 第17.4.1項「ldapsearchコマンドの概要」

- 第17.4.2項「ldapsearchの場所と形式」

- 第17.4.3項「検索基準の理解」

- 第17.4.4項「ldapsearchの例」

- 第17.4.5項「Oracle Directory Services Managerを使用したデータの検索」

17.4.1 ldapsearchコマンドの概要

ldapsearchコマンドでは、検索リクエストを入力し、そこでディレクトリ内のエントリを見つけるためのホスト名、ポート、バインドDNおよびパスワード、さらに検索基準を指定できます。LDAPクライアントが、ディレクトリ・サーバーに対して検索リクエストを実行すると、そのディレクトリ・サーバーへの接続がTCP/IP経由で開きます。その後、クライアントは、指定されたエントリの照合を試みることで、ディレクトリ・サーバーへのbind操作を実行し、それによって実際にクライアントが認証されます。大部分のユーザーは、ディレクトリ管理者や彼ら自身など特定のユーザーとしてバインドすることも、どのユーザーとしてもバインドしないこと(この場合、ディレクトリ・サーバーはそのユーザーが匿名ユーザーとしてバインドしていると想定する)もできます。

ディレクトリ・データへのすべてのアクセスは、接続のバインド方法に基づいているため、ディレクトリ・サーバーによって、クライアントの権限が調べられ、クライアントが特定の検索操作を実行できるかどうかが確認されます。ディレクトリ・サーバーによって、ユーザーのアクセス権が調べられた後、クライアントからディレクトリ・サーバーに一連の検索基準およびオプションで構成された検索リクエストが渡されます。

ディレクトリ・サーバーによって、その検索基準およびオプションに一致するすべてのエントリが検索されます。その後、それによって、標準出力のLDIFテキストの形式でエントリ、DN、および各エントリのすべての属性が返されます。エラーが発生した場合、ディレクトリ・サーバーによって、そのエラーを示すエラー・メッセージが表示されます。最後に、検索操作が完了すると、クライアントによって接続が閉じられます。

17.4.2 ldapsearchの場所と形式

ldapsearchユーティリティは次の場所にあります:

(UNIX, Linux) INSTANCE_DIR/OUD/bin
(Windows) INSTANCE_DIR\OUD\bat

このユーティリティは次の形式です:

ldapsearch optional-options search-filter optional-list-of-attributes

ここで:

- optional-optionsは、コマンドライン・オプションであり、検索フィルタの前に配置される必要があります。

- search-filterは、コマンドラインまたはファイル内で指定されるLDAP検索フィルタです。

- optional-list-of-attributesは、空白で区切られた属性のリストです。属性のリストは、検索フィルタの後に配置する必要があります。

17.4.2.1 一般的なldapsearchオプション

ldapsearchコマンドには、ディレクトリ内のエントリを検索するための多くのオプションがあります。オプションは、短い形式(たとえば、-b baseDN)でも長い形式(たとえば、--baseDN)でも可能です。ldapsearchとともに使用する最も一般的なコマンド・オプションは、次のとおりです:

-h, --hostname address

検索を実行する必要があるディレクトリ・サーバーのホスト名またはIPアドレスを指定します。これは、IPアドレスまたは解決可能なホスト名です。これを指定しない場合、localhostのデフォルト値が使用されます。

-p, --port port

ディレクトリ・サーバー・ポートを指定します。これは、1から65535までの整数値(両端を含む)にする必要があります。これを指定しない場合、389のデフォルト・ポートが使用されます。

-b, --baseDN baseDN

検索操作に使用するベースDNを指定します。--filenameオプションを使用して複数のフィルタを含むファイルが指定された場合、このベースDNが、すべての検索に対して使用されます。これは必須オプションです。

-s, --searchScope scope

検索操作の範囲を設定します。次のいずれかの値を指定する必要があります:

- base。--baseDNまたは-bオプションで指定されたエントリのみを検索します。

- one。--baseDNまたは-bオプションで指定されたエントリおよびその直下の子のみを検索します。

- subまたはsubordinate。ベースが--baseDNまたは-bオプションで指定されたエントリであるサブツリー全体を検索します。これは、--searchScopeオプションが指定されていない場合のデフォルトです。

-D, --bindDN bindDN

簡易認証を使用してディレクトリ・サーバーにバインドするときに使用するDNを指定します。このオプションは、SASL認証または匿名バインドを使用する場合は不要です。

-w, --bindPassword bindPassword

ディレクトリ・サーバーにバインドするときに使用するパスワードを指定します。このオプションは、簡易認証の場合、およびCRAM-MD5、DIGEST-MD5、PLAINなどのパスワードベースのSASLメカニズムの場合に使用します。匿名バインドを使用する場合は、不要です。このオプションは、--bindPasswordFileオプションとともに使用しないでください。パスワードの入力を要求するには、-w -を入力します。

-l, --timeLimit numSeconds

ディレクトリ・サーバーが検索リクエストの処理に費やす時間の最大の長さを秒単位で設定します。これを指定しない場合、クライアントによって適用される時間制限はありません。ディレクトリ・サーバーによって適用される時間制限が、クライアントによって要求されるものよりも短い場合があることを注意してください。

-z, --sizeLimit numEntries

ディレクトリ・サーバーがクライアントに返す一致エントリの最大数を設定します。これを指定しない場合、クライアントによって適用される最大サイズはありません。ディレクトリ・サーバーによって適用されるサイズ制限が、クライアントによって要求されるものよりも小さい場合があることを注意してください。

-S, --sortOrder sortOrder

結果をクライアントに返す前に、それらをソートします。ソート順はソート・キーのカンマ区切りリストであり、各ソート・キーは次の要素で構成されます:

- +/- (プラスまたはマイナス記号)。ソートを昇順にするのか(+)降順にするのか(-)を指定します。この値を省略すると、デフォルトではソートで昇順が使用されます。

- Attribute name。データをソートする属性の名前。この要素は必須です。

- NameまたはOID Matching Rule。オプションのコロンの後に、ソートの実行に使用する一致ルールの名前またはOIDが続きます。これを指定しない場合、指定した属性タイプのデフォルトの順序付け一致ルールが使用されます。
たとえば、ソート順序文字列sn,givenNameでは、最初にsnによって、次にgivenNameによって昇順でエントリがソートされます。かわりに、-modifyTimestampを使用すると、ディレクトリ・サーバーによって、最新の値を持つものが最初になるようにmodifyTimestamp属性がソートされます。

17.4.3 検索基準の理解

ldapsearchコマンドには、ディレクトリ情報ツリー内のどこで何を検索するのかを指定する次の3つのセットの情報が必要です:

- ベースDN。ベースDNを指定することで、検索を実行するディレクトリの最上位識別名(DN)または開始店を定義します。すべての検索は、範囲に応じてベースDNから、またその下からツリーの下に向かって開始され、上に向かって進むことはありません。ベースDNの例としては、dc=example,dc=comおよびou=People,dc=example,dc=comがあります。

- 範囲。範囲によって、検索フィルタによってベースDNのエントリとその下のエントリのどちらのセットを評価するのかが決まります。検索範囲およびベースDNは、ともに、ディレクトリのないのエントリを検索する場所を示します。

- 検索フィルタ。検索フィルタは、クライアントに返されるエントリが満たす必要がある条件を指定します。

この項では、様々なフィルタ・オプションについて説明し、内容は次のとおりです:

- 第17.4.3.1項「フィルタのタイプと演算子の指定」

- 第17.4.3.2項「複合検索フィルタの使用方法」

- 第17.4.3.3項「検索フィルタでのUTF-8エンコードの使用方法」

- 第17.4.3.4項「検索フィルタでの特殊文字の使用方法」

17.4.3.1 フィルタのタイプと演算子の指定

ディレクトリ・サーバーは、LDAPプロトコルで定義されている7つのタイプの検索フィルタを備えています。検索フィルタ・タイプごとに、attributeとvalueの2つのエンティティ間の関係をテストする演算子を使用します。

次の表は、検索問合せにおいて特定のエントリを返すための検索フィルタの使用方法を示しています。

検索フィルタ

演算子

説明

プレゼンス

attr=*

指定された属性と関連する値を持つすべてのエントリを返します。このフィルタでは、ワイルドカード文字を使用して、文字列内のゼロ個以上の文字を示します。たとえば、フィルタ(objectclass=\*)は、よく使用されるフィルタであり、すべてのエントリにある値を持つオブジェクト・クラスを含むすべてのエントリが返されます。

注意: LDAPプロトコルでは、フィルタは、引用符に囲まれたカッコも含めて"(filter)"の形式を持つと指定されています。大部分のディレクトリ・サーバーでは、カッコと引用符がないフィルタを受け入れますが、それらを含めることをお薦めします。

等価

attr=value

指定された値に等しい属性を含むエントリを返します。たとえば、(sn=Bergin)では、姓(sn)属性の値がBerginであるすべてのエントリが返されます。

注意: sn値は大文字小文字を区別しないため、sn=berginまたはsn=Berginに関連するエントリが返されます。

部分文字列

attr=<initial-string><any substring><final-string>

指定した部分文字列または部分的な部分文字列を含む属性を持つエントリが返されます。このフィルタでは、ワイルドカード文字を使用して、文字列内のゼロ個以上の文字を示します。

- 文字列の最初に文字Berを持つすべての属性値を検索する先頭文字列検索を実行します: (sn=Ber\*)

- 属性値の中間部分文字列を指定します。例: (sn=\*erg\*)

- 属性値の末尾にある部分文字列を指定します。例: (sn=\*gin)。または、部分文字列の組合せを指定できます。

- 先頭および中間の部分文字列を指定します: (sn=ber\*gi\*)

- 先頭および末尾の部分文字列を指定します: (sn=be\*in)

- 中間および末尾の部分文字列を指定します: (sn=\*er\*in)
注意: 部分文字列フィルタでは、システムのリストや正規表現などにおいて真のワイルドカードは使用されません。したがって、次のフィルタは、基準が多すぎるため無効です: (sn=\*B\*rg\*n)。

以上

attr>=value

指定された値以上の属性を含むエントリを返します。たとえば、(sn>=Bergin)は、属性の一致ルール(「一致ルールの理解」を参照)に基づいて、値Bergin以上の属性を持つすべてのエントリが返されます。

以下

attr<=value

指定された値以下の属性を含むエントリを返します。たとえば、(sn&lt;=Bergin)は、属性の一致ルールに基づいて、値Bergin以下の属性を持つすべてのエントリが返されます。

近似

attr~=value

検索フィルタに指定されている値にほぼ等しい値を持つ指定された属性を含むエントリを返します。たとえば、(sn~=Bergan)では、(sn=Bergin)または(sn=Bergan)に関連するエントリが返されます。近似検索フィルタは、英語の文字列でのみ機能します。JaやZnなど非ASCIIベース文字列では機能しません。

拡張可能一致

attr= attr [":dn"] [":" matchingrule] ":=" value Or:[:dn] ":" matchingrule ":=" value

指定した一致ルールで属性がその値に等しい場合、結果のエントリを返します。LDAPバージョン3では、特定の属性に対する一致演算子およびルールを作成できます。一致ルールによって、特定の構文と属性値を比較する方法が定義されます。つまり、拡張可能検索フィルタでは、一致ルールを検索フィルタに追加できます。たとえば、(sn:2.5.13.5:=Jensen)の検索フィルタでは、OID 2.5.13.5によって指定された一致ルールを使用することで、Jensenに等しい値を持つ姓属性を含むエントリが比較されます。もう1つの例の(sn:dn:2.5.13.5:=Jensen)は、比較を行うときにOID 2.5.13.5を使用すること、および一致を評価するときにエントリの属性をエントリの一部と見なすことを示すための":dn"表記の使用例を示します。

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

次のように演算子を使用することで、複数の検索フィルタ・コンポーネントを結合し、評価できます:

(Boolean-Operator(filter)(filter)(filter))

ブール演算子を結合し、ネストして、複合式を形成できます:

(Boolean-Operator(filter)(Boolean-operator(filter)(filter)))

次の表で、ブール演算子について説明します。

検索フィルタ

演算子

説明

AND

(&(filter)(filter))

文がtrueになるためには、指定されているすべてのフィルタがtrueである必要があります。たとえば、(&(sn=Carter)(l=Cupertino))では、姓属性がCarterで、かつ位置属性がCupertinoのエントリがあれば、それらがすべて返されます。

OR

(|(filter)(filter))

文がtrueになるためには、指定されているフィルタの少なくとも1つがtrueである必要があります。たとえば、(|(sn=Carter)(l=Cupertino))では、姓属性がCarterであるか、位置属性がCupertinoのエントリがあれば、それらがすべて返されます。

NOT

(!(filter)(filter))

文がtrueになるためには、指定されているフィルタがtrueでない必要があります。たとえば、(!(sn=Bergin))では、姓属性が文字列Smithでないすべてのエントリが返されます。このフィルタでは、sn属性を持たないすべてのエントリも返されます。

17.4.3.3 検索フィルタでのUTF-8エンコードの使用方法

UTF8は、Unicodeのバイト順の可変長文字コードであり、ASCIIのサブセットです。7ビットのASCII文字を、1バイトのUTF-8エンコーディングで置き換えることで複数言語サポートにUTF-8を使用します。通常、UTF-8エンコーディングは1つの円記号でエスケープする必要があります。

たとえば、文字éのUTF-8表記はc3a9であり、èのUTF-8表記はc3a8です。UTF-8エンコーディングは、エスケープ円記号で表されます。したがって、éは\\c3\\a9として、èは\\c3\\a8として表されます。cn=Hélène Laurentを表すには、次のエンコーディングを使用します:

(cn=H\\c3\\a9l\\c3\\a8ne Laurent)

17.4.3.4 検索フィルタでの特殊文字の使用方法

特殊文字(たとえば、空白、円記号、アスタリスク、カンマ、ピリオドなど)は、エスケープ円記号を使用することで指定する必要があります。

- アスタリスク。アスタリスク(*)は、\\2aとして表します。たとえば、Five*Starは"(cn=Five\\2aStar)"として表されます。

- 円記号。円記号(\)は、\\5cとして表します。たとえば、c:\\fileは"(cn=c:\\5c\\5cfile)"として表されます。

- カッコ。カッコ()は、それぞれ\\28および\\29として表されます。たとえば、John Doe (II)は"(cn=John Doe \\28II\\29)"として表されます。

- NULL。NULLは、\\00として表されます。たとえば、0001は"(bin=\\00\\00\\00\\01)"として表されます。

- カンマ。カンマ(,)は、それを\\,のようにエスケープすることで表します。たとえば、"(cn=Mkt\\,Peru,dc=example,dc=com)"のようになります。

- 空白。通常、空白を含む文字列は引用符を使用して囲みます。たとえば、(cn="HR Managers,ou=Groups,dc=example,dc=com")のようになります。

17.4.4 ldapsearchの例

次の例は、各種検索オプションを指定したldapsearchコマンドの使用を示しています。これらの例はすべて、現行作業ディレクトリがINSTANCE_DIR/OUD/bin (WindowsシステムではINSTANCE_DIR\OUD\bat)であることを想定しています。

次の点は、この項のすべての例に関係しています:

- 例で(--searchScopeまたは-sオプションで)範囲が指定されていない場合、ldapsearchでは、範囲がsubordinateまたはsubであると想定され、ベースDNのすべてのサブツリーが返されます。

- 属性が指定されていない場合、このコマンドはすべての属性とそれらの値を返します。

- --bindDNおよび--bindPasswordが指定されていない場合、検索で匿名バインドが使用されます。

- --hostnameが指定されていない場合、デフォルト(localhost)が使用されます。

注意:

多くのUNIXおよびLinuxオペレーティング・システムで、/usr/binディレクトリにldapsearch、ldapmodify、ldapdeleteなど一般的なLDAPクライアント・ツールのインストール済バージョンが提供されています。ディレクトリ・サーバーを検索するには、そのディレクトリ・サーバーで提供されているldapsearchを使用する必要があります。次のコマンドを入力することで、ldapsearchのどのバージョンを使用しているのかを調べることができます:

$ which ldapsearch

/usr/bin内のldapsearchを使用する場合は、$PATHの先頭にINSTANCE_DIR/OUD/binを付けます。

この項には次のトピックが含まれます:

- 第17.4.4.1項「すべてのエントリを返す方法」

- 第17.4.4.2項「特定のユーザーを検索する方法」

- 第17.4.4.3項「特定のユーザー属性を検索する方法」

- 第17.4.4.4項「ベース範囲を指定して検索を実行する方法」

- 第17.4.4.5項「1レベル範囲を指定して検索を実行する方法」

- 第17.4.4.6項「サブツリー範囲を指定して検索を実行する方法」

- 第17.4.4.7項「属性名のみを返す方法」

- 第17.4.4.8項「ユーザー属性のみを返す方法」

- 第17.4.4.9項「ベースDNのみを返す方法」

- 第17.4.4.10項「特定のオブジェクト・クラスを検索する方法」

- 第17.4.4.11項「ディレクトリ内のすべてのエントリのカウントを返す方法」

- 第17.4.4.12項「複合フィルタを使用して検索を実行する方法」

- 第17.4.4.13項「フィルタ・ファイルを使用して検索を実行する方法」

- 第17.4.4.14項「検索で返されるエントリ数を制限する方法」

17.4.4.1 すべてのエントリを返す方法

プレゼンス検索フィルタ(objectclass=*)を使用すると指定した分岐DNの下のすべてのエントリを返すことができます。この検索フィルタでは、値を持つ1つ以上のオブジェクト・クラスを持つすべてのエントリが検索されます。すべてのエントリは、いくつかのオブジェクト・クラス定義を持っているため、このフィルタはすべてのエントリが返されることを保証します。

フィルタ(objectclass=*)を指定してldapsearchコマンドを実行します。

$ ldapsearch --hostname localhost --port 1389 --baseDN "dc=example,dc=com" \
"(objectclass=*)"
dn: dc=example,dc=com
objectClass: domain
objectClass: top
dc: example

dn: ou=Groups,dc=example,dc=com
objectClass: organizationalunit
objectClass: top
ou: Groups

dn: cn=Directory Administrators,ou=Groups,dc=example,dc=com
objectClass: groupofuniquenames
objectClass: top
ou: Groups
cn: Directory Administrators
uniquemember: uid=kvaughan, ou=People, dc=example,dc=com
uniquemember: uid=rdaugherty, ou=People, dc=example,dc=com
uniquemember: uid=hmiller, ou=People, dc=example,dc=com
...

17.4.4.2 特定のユーザーを検索する方法

等価フィルタを使用して、ディレクトリ内の特定のユーザーを見つけることができます。この例では、Frank Albersという共通名を持つ従業員を見つけます。

フィルタ"(cn=Frank Albers)"を指定してldapsearchコマンドを実行します。

$ ldapsearch --port 1389 --baseDN dc=example,dc=com  "(cn=Frank Albers)"

dn: uid=falbers,ou=People,dc=example,dc=com
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: top
givenName: Frank
uid: falbers
cn: Frank Albers
sn: Albers
telephoneNumber: +1 408 555 3094
userPassword: {SSHA}nDTQJ9DDiMUrBwR0WNKq0tgS4iB2A9QJFgpZiA==
roomNumber: 1439
ou: Accounting
ou: People
l: Sunnyvale
mail: falbers@example.com
facsimileTelephoneNumber: +1 408 555 9751

17.4.4.3 特定のユーザー属性を検索する方法

等価フィルタを使用して、ディレクトリ内のエントリの1つ以上の属性を見つけることができます。検索フィルタの後に1つ以上の属性を配置することによって、それらを指定します。この例では、Frank Albersのユーザー・エントリからtelephoneNumberおよびmail属性を見つけます。

フィルタ"(cn=Frank Albers)"および対応する属性を指定してldapsearchコマンドを実行します。

$ ldapsearch --port 1389 --baseDN dc=example,dc=com \
"(cn=Frank Albers)" telephoneNumber mail
dn: uid=falbers,ou=People,dc=example,dc=com
telephoneNumber: +1 408 555 3094
mail: falbers@example.com

17.4.4.4 ベース範囲を指定して検索を実行する方法

検索ベースDNとともに指定することで、範囲によって、ディレクトリ情報ツリー(DIT)のどの部分を調べるのかが決まります。ベース範囲では、そのベースDNで指定されたレベルのみ(その子のエントリは除く)が調査されます。ベース範囲は、--searchScope baseオプションまたはその短い形式の同等物である-s baseを使用して指定します。

--searchScope baseオプションを指定して、ldapsearchコマンドを実行します。

$ ldapsearch --hostname localhost --port 1389 --baseDN "dc=example,dc=com" \
--searchScope base "(objectclass=*)"
dn: dc=example,dc=com
objectClass: domain
objectClass: top
dc: example

17.4.4.5 1レベル範囲を指定して検索を実行する方法

1レベル範囲では、ベースDNの直下のレベルのみが調査されます。1レベル範囲は、--searchScope oneオプションまたはその短い形式の同等物である-s oneを使用して指定します。これ例では、ベースDNの直下のエントリを表示します。

--searchScope oneオプションを指定して、ldapsearchコマンドを実行します。

$ ldapsearch --hostname localhost --port 1389 --baseDN "dc=example,dc=com" \
--searchScope one "(objectclass=*)"
dn: ou=Groups,dc=example,dc=com
objectClass: top
objectClass: organizationalunit
ou: Groups
dn: ou=People,dc=example,dc=com
objectClass: top
objectClass: organizationalunit
ou: People
dn: ou=Special Users,dc=example,dc=com
objectClass: top
objectClass: organizationalUnit
ou: Special Users
description: Special Administrative Accounts
dn: ou=Company Servers,dc=example,dc=com
objectClass: top
objectClass: organizationalUnit
ou: Company Servers
description: Standard branch for Company Server registration

17.4.4.6 サブツリー範囲を指定して検索を実行する方法

サブツリー範囲では、ベースDNの下のサブツリーとそのベースDNレベルが調査されます。サブツリー範囲は、--searchScope subオプションまたはその短い形式の同等物である-s subを使用して指定します。--searchScopeを指定しない場合、ldapsearchではサブツリー範囲が想定されます。

--searchScope subオプションを指定して、ldapsearchコマンドを実行します。

$ ldapsearch --hostname localhost --port 1389 \
--baseDN "cn=Directory Administrators,ou=Groups,dc=example,dc=com" \
--searchScope sub "(objectclass=*)"
dn: cn=HR Managers,ou=groups,dc=example,dc=com
objectClass: groupOfUniqueNames
objectClass: top
ou: groups
description: People who can manage HR entries
cn: HR Managers
uniqueMember: uid=kvaughan, ou=People, dc=example,dc=com
uniqueMember: uid=cschmith, ou=People, dc=example,dc=com

17.4.4.7 属性名のみを返す方法

ldapsearchコマンドは、ディレクトリ内に属性が存在しているかどうかを調べるための便利なオプションを備えています。--typesOnlyオプションまたはその短い形式の同等物である-Aを使用して、ディレクトリ・サーバーに、属性の値を表示しないで属性名を表示することを指示します。

--typesOnlyオプションを指定して、ldapsearchコマンドを実行します。

$ ldapsearch --hostname localhost --port 1389 \
--baseDN "dc=example,dc=com" --typesOnly "(objectclass=*)"
dn: dc=example,dc=com
objectClass
dc
dn: ou=Groups,dc=example,dc=com
objectClass
ou ...

17.4.4.8 ユーザー属性のみを返す方法

アスタリスク*を含めることで、ldapsearchを使用して、検索フィルタに一致するエントリのユーザー属性のみを返すことができます。ユーザー属性は(操作属性とは異なり)、ディレクトリ内にユーザー情報を格納します。アスタリスクを指定しない場合、デフォルトでユーザー属性が返されます。シェルに対してはアスタリスクを適切にエスケープする必要があります。

検索フィルタの後に'*'を指定してldapsearchコマンドを実行します。

$ ldapsearch --hostname localhost --port 1389 --baseDN "dc=example,dc=com" \
"(objectclass=*)" '*'
dn: cn=Aggie Aguirre,ou=People,dc=example,dc=com
objectClass: person
objectClass: inetorgperson
objectClass: organizationalperson
objectClass: top
postalAddress: Aggie Aguirre$15172 Jackson Street$Salt Lake City, MI  49843
postalCode: 49843
uid: user.99
description: This is the description for Aggie Aguirre.
employeeNumber: 99
initials: AGA
givenName: Aggie
pager: +1 514 297 1830
mobile: +1 030 300 0720
cn: Aggie Aguirre
telephoneNumber: +1 730 027 2062
sn: Aguirre
street: 15172 Jackson Street
homePhone: +1 229 128 3072
mail: user.99@maildomain.net
l: Salt Lake City
st: MI

17.4.4.9 ベースDNのみを返す方法

検索フィルタの後に1.1文字列を含めることで、ldapsearchを使用して、検索フィルタに一致するエントリのベースDNのみを返すことができます。

検索フィルタの後に1.1を指定してldapsearchコマンドを実行します。

$ ldapsearch --hostname localhost --port 1389 --baseDN "dc=example,dc=com" \
"(objectclass=*)" 1.1
version: 1
dn: cn=Richard Arnold,ou=people,dc=example,dc=com

dn: cn=Kevin Booysen,ou=people,dc=example,dc=com

dn: cn=Steven Morris,ou=people,dc=example,dc=com

dn: cn=Leila Shakir,ou=people,dc=example,dc=com

dn: cn=Emily Smith,ou=people,dc=example,dc=com
...

17.4.4.10 特定のオブジェクト・クラスを検索する方法

特定のオブジェクト・クラスの名前の前に@文字を付けることで、そのオブジェクト・クラスによって属性が参照されるすべてのエントリを検索できます。groupOfUniqueNamesのオブジェクト・クラスを持つすべてのエントリを表示するには、検索フィルタの後に@groupOfUniqueNamesを含めます。

検索フィルタの後に@およびオブジェクト・クラスを指定してldapsearchコマンドを実行します。

$ ldapsearch --hostname localhost --port 1389 \
--baseDN "ou=Groups,dc=example,dc=com" "(objectclass=*)" @groupOfUniqueNames
dn: ou=Groups,dc=example,dc=com
ou: Groups
objectClass: organizationalunit
objectClass: top
dn: cn=Directory Administrators,ou=Groups,dc=example,dc=com
ou: Groups
objectClass: groupofuniquenames
objectClass: top
cn: Directory Administrators
uniqueMember: uid=kvaughan, ou=People, dc=example,dc=com
uniqueMember: uid=rdaugherty, ou=People, dc=example,dc=com
uniqueMember: uid=hmiller, ou=People, dc=example,dc=com ...

17.4.4.11 ディレクトリ内のすべてのエントリのカウントを返す方法

ldapsearchコマンドは、ディレクトリ内のエントリの合計数を返すための--countEntriesを備えています。ディレクトリ・サーバーによって、検索フィルタに一致するすべてのエントリが返され、最後の行に合計数が表示されます。この例では、位置がCincinnatiの従業員のエントリの数を判別します。

--countEntriesオプションを指定して、ldapsearchコマンドを実行します。

$ ldapsearch --hostname localhost --port 1389 --bindDN "cn=Directory Manager" \
--bindPassword password --baseDN dc=example,dc=com --countEntries "l=Cincinnati"
dn: cn=Adi Adamski,ou=People,dc=example,dc=com
...
l: Cincinnati
st: OH

dn: Aggi Aguinsky,ou=People,dc=example,dc=com
objectClass: person
...
l: Cincinnati
st: OH

# Total number of matching entries: 2

17.4.4.12 複合フィルタを使用して検索を実行する方法

複合検索フィルタには、ブール演算子AND (&)、OR (|)またはNOT (!)を使用する複数のテストが含まれています。ブール演算子とフィルタを組み合せ、ネストして、複合式を作成できます。次の例では、Jensenという名前で、Cupertinoで働いている従業員のすべてのエントリを検索します。このコマンドは2つの結果を返します。

複合検索フィルタを指定してldapsearchコマンドを実行します。

$ ldapsearch --hostname localhost --port 1389 --bindDN "cn=Directory Manager" \
--bindPassword password --baseDN dc=example,dc=com "(&(sn=jensen)(l=Cupertino))"
dn: uid=bjensen,ou=People,dc=example,dc=com
objectClass: person
objectClass: inetOrgPerson
objectClass: top
objectClass: organizationalPerson
ou: Product Development
ou: People
sn: Jensen
...
l: Cupertino
st: CA

dn: uid=rjensen,ou=People,dc=example,dc=com
objectClass: person
objectClass: inetOrgPerson
objectClass: top
objectClass: organizationalPerson
ou: Accounting
ou: People
sn: Jensen
...
l: Cupertino
st: CA

17.4.4.13 フィルタ・ファイルを使用して検索を実行する方法

--filenameオプションを使用することで、ファイル内に複合または複数のフィルタを配置できます。ファイルに複数のフィルタが含まれている場合は、1行に1つのフィルタが表示されるようにファイルを構成する必要があります。検索は、フィルタ・ファイルに記載されている順序でディレクトリ・サーバーへの同じ接続を使用して実行されます。--filenameオプションを使用する場合、その後のオプションはすべて独立した属性として処理されます。そうでない場合は、最初の後続オプションを検索フィルタにする必要があります。

この例では、Jensenという名前で、Cupertinoで働いていて、かつ会計部門では働いていない従業員のすべてのエントリを検索します。

1. フィルタ・ファイルを作成します。
この例では、(&(sn=jensen)(l=Cupertino)(!(ou=Accounting)))の内容を持つmyfilter.txtという名前のファイルを作成します。

2. フィルタとしてファイル名を指定してldapsearchコマンドを実行します。

$ ldapsearch --hostname localhost --port 1389 --bindDN "cn=Directory Manager" \
--bindPassword password --baseDN dc=example,dc=com --filename myfilter.txt
dn: uid=bjensen,ou=People,dc=example,dc=com
objectClass: person
objectClass: inetOrgPerson
objectClass: top
objectClass: organizationalPerson
ou: Product Development
ou: People
sn: Jensen
l: Cupertino
cn: Barbara Jensen
cn: Babs Jensen
telephoneNumber: +1 408 555 1862
givenName: Barbara
uid: bjensen
mail: bjensen@example.com

17.4.4.14 検索で返されるエントリ数を制限する方法

-zまたは--sizeLimitオプションを使用することで、返されるエントリの数を制限できます。エントリの数が、指定されている数を超える場合、検索によって指定された数のエントリが返され、サイズ制限を超えたことを示すエラーが返されます。次の例では、最大5つのエントリが要求されます。

--sizeLimitオプションを指定して、ldapsearchコマンドを実行します。

$ ldapsearch --hostname localhost --port 1389 -b "dc=example,dc=com" \
--sizeLimit 5 "objectclass=*" 1.1
dn: dc=example,dc=com

dn: ou=People,dc=example,dc=com

dn: uid=user.0,ou=People,dc=example,dc=com

dn: uid=user.1,ou=People,dc=example,dc=com

dn: uid=user.2,ou=People,dc=example,dc=com

SEARCH operation failed
Result Code:  4 (Size Limit Exceeded)
Additional Information:  This search operation has sent the maximum of 5 entries to the client

17.4.5 Oracle Directory Services Managerを使用したデータの検索

次の項に示すように、ODSMの各サーバー・インスタンスの「拡張検索」タブで、ディレクトリ・データに対して複合検索を実行できます。

17.4.5.1 複雑なLDAP検索の実行

ODSM拡張検索機能を使用することで複合LDAP検索を実行するには、次の手順を完了します:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「拡張検索」タブを選択します。

3. 「ネットワーク・グループ」リストから適切なネットワーク・グループを選択します。

4. 「ベース検索DN」フィールドで、検索の開始点となるDNを入力します。
「ベース検索DN」としてエントリを選択するには、「選択」をクリックします。

「エントリ・ピッカー」ウィンドウで、「ツリー・ビュー」を選択してディレクトリ・ツリーに移動し、対象のエントリを見つけるか、「検索ビュー」を選択して対象のエントリを検索します。

5. 「範囲」リストから検索の範囲を選択します。LDAP検索範囲は、検索操作の一致候補と見なされる、ベースDNまたはその下にある一連のエントリを示します。範囲は、次のいずれかです:

- ベース。検索操作は、検索ベースDNとして指定されたエントリに対してのみ実行されることを示します。その下には検討されるエントリはありません。

- 「1レベル」。検索操作は、検索ベースDNとして指定されたエントリの直下のエントリに対してのみ実行されることを示します。ベース・エントリ自体または検索ベース・エントリの直下より下位のエントリは含まれません。

- サブツリー。検索操作は、検索ベースとして指定されたエントリ、および深さにかかわらず検索ベースの下位すべての指定されたエントリに対して実行されることを示します。

6. 「フィルタ」フィールドで、有効なLDAP検索フィルタを入力します。
かわりに、「フィルタ・ビルダー」をクリックし、ODSMに必要な情報を入力し、LDAP検索フィルタを構築します。

LDAP検索フィルタの詳細は、第17.4.3.1項「フィルタのタイプと演算子の指定」を参照してください。

7. 「検索結果サイズ」リストから、検索によって返されるエントリの数をODSMで制限する方法を選択します。

- 「制限設定」で、返されるエントリの正確な数を指定できます。

- 「仮想リスト・ビューの使用」によって、検索に仮想リスト表示索引を使用できます。詳細は、第17.5.3.16項「仮想リスト表示制御を使用した検索」を参照してください。

- 「ページングの使用」によって、一度に結果のサブセットのみを返すことを指定でき、各ページの結果の数を指定できます。詳細は、第17.5.3.15項「単純なページングの結果制御を使用した検索」を参照してください。

17.5 拡張検索機能の使用方法

ディレクトリ・サーバーは、ldapsearchコマンドを使用することでLDAPv3対応の検索機能をサポートしています。ご使用のシステム構成に基づいて、検索プロセスで特殊属性、セキュリティ、オプション、およびLDAP制御を使用できます。詳細は、第17.4項「ディレクトリ・データの検索」、付録A「サーバー・コマンドによるプロパティ・ファイルの使用方法」および付録A「ldapsearch」を参照してください。

この項には次のトピックが含まれます:

- 第17.5.1項「特別なエントリおよび属性の検索」

- 第17.5.2項「SSL経由の検索」

- 第17.5.3項「制御を使用した検索」

- 第17.5.3.16項「仮想リスト表示制御を使用した検索」

- 第17.5.4項「詳細モードでの検索とプロパティ・ファイルを使用した検索」

- 第17.5.5項「国際化されたエントリの検索」

17.5.1 特別なエントリおよび属性の検索

この項では、操作属性を検索する方法と、ルートDSEエントリを検索する方法について説明し、内容は次のとおりです:

- 第17.5.1.1項「操作属性を検索する方法」

- 第17.5.1.2項「ルートDSEエントリを検索する方法」

- 第17.5.1.3項「ACI属性を検索する方法」

- 第17.5.1.4項「スキーマ・エントリを検索する方法」

- 第17.5.1.5項「構成エントリを検索する方法」

- 第17.5.1.6項「監視エントリを検索する方法」

17.5.1.1 操作属性を検索する方法

操作属性は、サーバー自体で処理を行ったり、ディレクトリ・サーバーで管理されている(クライアントから明示的に提供されることのない)その他のデータを保持するために必要な情報を格納する場合に使用されます。操作属性は、検索属性のリストに明示的に含められていない場合は、検索操作から返されるエントリに含まれません。+ (プラス記号)をldapsearchコマンドに追加することで、操作属性を返すようにディレクトリ・サーバーに要求できます。

+文字を指定して、ldapsearchコマンドを実行します。

ご使用のシェルに適した方法で文字をエスケープする必要があります。

$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" \
-j pwd-file -b "dc=example,dc=com" "(objectclass=*)" "+"
...
dn: cn=PD Managers,ou=groups,dc=example,dc=com
numSubordinates: 0
hasSubordinates: false
subschemaSubentry: cn=schema
entryDN: cn=pd managers,ou=groups,dc=example,dc=com
entryUUID: 38666d52-7a53-332e-902f-e34dd4aaa7a0
...

17.5.1.2 ルートDSEエントリを検索する方法

ルートDSEは、サーバーの名前、ネーミング・コンテキスト、およびサポートされている機能に関する情報を提供する特別なエントリです。属性の多くは操作属性であるため、+ (プラス記号)を指定してルートDSEエントリの属性を表示する必要があります。

""のbaseDNを指定してldapsearchコマンドを実行します。

baseとして範囲を指定し、+文字を含めて、操作属性を表示します。

$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" \
-j pwd-file -b "" --searchScope base "(objectclass=*)" "+"
dn:
supportedExtension: 1.3.6.1.4.1.4203.1.11.3
supportedExtension: 1.3.6.1.4.1.4203.1.11.1
supportedExtension: 1.3.6.1.4.1.26027.1.6.2
supportedExtension: 1.3.6.1.4.1.26027.1.6.1
supportedExtension: 1.3.6.1.1.8
supportedExtension: 1.3.6.1.4.1.1466.20037
...

17.5.1.3 ACI属性を検索する方法

ディレクトリ・サーバーでは、アクセス制御命令(ACI)を、エントリのaci属性の1つ以上の値として保存し、そのディレクトリ・データベースへのアクセスを許可または拒否します。aci属性は、ディレクトリ・ユーザーが読取りおよび変更できる複数値操作属性であり、それ自体がACIによって保護される必要があります。管理ユーザーは、通常、aci属性への完全アクセス権を付与され、ldapsearchコマンドを実行することでその値を表示できます。

ldapsearchコマンドを次のように実行します:

$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" \
-j pwd-file -b dc=example,dc=com --searchScope base "(aci=*)" aci
dn: dc=example,dc=com
aci: (target ="ldap:///dc=example,dc=com")(targetattr h3.="userPassword")
(version 3.0;acl "Anonymous read-search access";allow (read, search, compare)
(userdn = "ldap:///anyone");)
aci: (target="ldap:///dc=example,dc=com") (targetattr = "*")
(version 3.0; acl "allow all Admin group"; allow(all)
groupdn = "ldap:///cn=Directory Administrators,ou=Groups,dc=example,dc=com";)

17.5.1.4 スキーマ・エントリを検索する方法

ディレクトリ・サーバーは、ご使用のインスタンスに対して定義されているオブジェクト・クラスおよび属性のスキーマ情報をスキーマ・エントリ(cn=schema)に保持しています。

cn=schemaベースDNに対してldapsearchコマンドを実行します。

スキーマ内の属性は、操作属性であるため、検索の最後に"+"を含める必要があります。

$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" \
-j pwd-file -b cn=schema --searchScope base "(objectclass=*)" "+"
dn: cn=schema
nameForms: ( 1.3.6.1.1.10.15.1 NAME 'uddiBusinessEntityNameForm' OC uddiBusiness
Entity MUST ( uddiBusinessKey ) X-ORIGIN 'RFC 4403' )
nameForms: ( 1.3.6.1.1.10.15.2 NAME 'uddiContactNameForm' OC uddiContact MUST
(uddiUUID ) X-ORIGIN 'RFC 4403' )
nameForms: ( 1.3.6.1.1.10.15.3 NAME 'uddiAddressNameForm' OC uddiAddress MUST
(uddiUUID ) X-ORIGIN 'RFC 4403' )
...
attributeTypes: ( 1.3.6.1.1.1.1.12 NAME 'memberUid' EQUALITY caseExactIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'draft-howard-rfc2307bis' )
attributeTypes: ( 1.3.6.1.1.1.1.13 NAME 'memberNisNetgroup' EQUALITY caseExactIA
5Match SUBSTR caseExactIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
X-ORIGIN 'draft-howard-rfc2307bis' )
attributeTypes: ( 1.3.6.1.1.1.1.14 NAME 'nisNetgroupTriple' DESC 'Netgroup
triple' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN
'draft-howard-rfc2307bis' )
...

17.5.1.5 構成エントリを検索する方法

ディレクトリ・サーバーは、その構成をcn=configエントリの下に格納します。LDAPを使用したこのエントリへの直接アクセスはお薦めしません。この構成は、dsconfigコマンドを使用してアクセスおよび変更できます。dsconfigコマンドは、管理コネクタを使用してSSL経由でディレクトリ・サーバーに接続します。詳細は、第14.3項「サーバーへの管理トラフィックの管理」を参照してください。

対話モードでdsconfigを使用して構成エントリを検索するには、次のようにコマンドを実行します:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file

dsconfigを使用したサーバー構成へのアクセスの詳細は、第14.1項「dsconfigを使用したサーバー構成の管理」を参照してください。

17.5.1.6 監視エントリを検索する方法

ディレクトリ・サーバーの監視エントリcn=monitorは、サーバー・パフォーマンス、状態およびバージョンに関する統計情報を提供します。この情報には、ldapsearchコマンドを使用することでアクセスできます。

任意の構成済LDAP接続ハンドラを使用してcn=monitorにアクセスできますが、管理接尾辞へのすべてのアクセスに管理コネクタを使用することをお薦めします。管理コネクタを使用すると、データの監視が損なわれず、ユーザー・トラフィックよりもサーバー管理が優先されるようになります。管理コネクタを使用するには、管理ポートを指定し、--useSSLオプションを含めます。詳細は、第14.3項「サーバーへの管理トラフィックの管理」を参照してください。

ベースDNcn=monitorに対してldapsearchコマンドを実行します。

$ ldapsearch -h localhost -p 4444 --useSSL -D "cn=Directory Manager" \
-j pwd-file -b cn=monitor "(objectclass=*)"
dn: cn=monitor
startTime: 20120119135658Z
objectClass: extensibleObject
objectClass: top
objectClass: ds-monitor-entry
cn: monitor
vendorName: Oracle Corporation
currentTime: 20120125145650Z
vendorVersion: Oracle Unified Directory 11.1.2.0.0
maxConnections: 3
productName: Oracle Unified Directory
currentConnections: 1
totalConnections: 22
upTime: 6 days 0 hours 59 minutes 52 seconds
...

17.5.2 SSL経由の検索

自己署名証明書または証明書を使用することでSSL接続を受け入れるようにディレクトリ・サーバーを構成した場合、クライアント認証を使用して検索できます。次の手順は、各種認証メカニズムを使用してSSL経由でディレクトリを検索する方法を示しています。

この項には次のトピックが含まれます:

- 第17.5.2.1項「ブラインド信頼を使用してSSL経由で検索する方法」

- 第17.5.2.2項「トラスト・ストアを使用してSSL経由で検索する方法」

- 第17.5.2.3項「トラスト・ストアを指定しないでSSL経由で検索する方法」

- 第17.5.2.4項「キーストアを使用してSSL経由で検索する方法」

- 第17.5.2.5項「StartTLSを使用して検索する方法」

- 第17.5.2.6項「DIGEST-MD5クライアント認証を利用してSASLを使用して検索する方法」

- 第17.5.2.7項「GSSAPIメカニズムを利用してSASLを使用して検索する方法」

- 第17.5.2.8項「PLAINメカニズムを利用してSASLを使用して検索する方法」

17.5.2.1 ブラインド信頼を使用してSSL経由で検索する方法

サーバーから提示されたどのような証明書も、自動的に信頼するようにクライアントを構成できます。ただし、この方法は安全ではなく、介在者による攻撃を受けやすくなります。一般的に、このタイプの認証は、テスト目的でのみ使用してください。

--trustAllオプションを指定して、ldapsearchコマンドを実行します。

次のコマンドは、ルートDSEを検索します。

$ ldapsearch -h localhost -p 1636 --useSSL --trustAll -b "" \
--searchScope base "(objectClass=*)"

17.5.2.2 トラスト・ストアを使用してSSL経由で検索する方法

証明書トラスト・ストアを使用するようにクライアントを構成できます。これには、信頼できる証明書に関する情報が含まれています。クライアントは、サーバー証明書を、トラスト・ストアにリストされているものと比べてチェックできます。クライアントによって一致が確認されると、サーバーとの間でセキュアな通信を行えます。一致がない場合、サーバーを信頼できません。提示された証明書が有効であることを確認し、それをトラスト・ストアに追加する必要があります。それによってセキュアな通信が許可されます。

--trustStorePathオプションを指定して、ldapsearchコマンドを実行します。

次のコマンドは、トラスト・ストアを使用してルートDSEを検索します。

$ ldapsearch -h localhost -p 1636 --useSSL \
--trustStorePath /home/scarter/security/cert.db -b "" \
--searchScope base "(objectClass=*)"

17.5.2.3 トラスト・ストアを指定しないでSSL経由で検索する方法

トラスト・ストアが指定されていない場合、クライアントに提示された証明書を信頼するかどうかに関するプロンプトが表示されます。

--trustStorePathオプションを指定せずに、ldapsearchコマンドを実行します。

次のコマンドは、トラスト・ストアを使用せずにルートDSEを検索します。

$ ldapsearch -h localhost -p 1636 --useSSL -b "" \
--searchScope base "(objectclass=*)"
The server is using the following certificate:
Subject DN: CN=example.com, O=Example Corp, C=US
Issuer DN: CN=example.com, O=Example Corp, C=US
Validity: Fri Mar 02 16:48:17 CST 2007 through Thu May 31 17:48:17 CDT 2007
Do you wish to trust this certificate and continue connecting to the server?
Please enter "yes" or "no": yes

dn: objectClass: ds-rootDSE
objectClass: top

17.5.2.4 キーストアを使用してSSL経由で検索する方法

クライアントがディレクトリ・サーバーに独自の証明書ょ提示する必要がある場合、そのクライアントは、どの証明書キーストアを使用するのか認識している必要があります。クライアントは、--keyStorePasswordまたは--keyStorePasswordFileオプションのいずれかを使用して、--keyStorePathオプションを指定することで証明書キーストアを判別できます。このシナリオは、通常、クライアントがSASL EXTERNAL認証を実行する場合、またはサーバーが常にクライアントに独自の証明書を提示することを要求する場合に発生します。

--keyStore...オプションを指定して、ldapsearchコマンドを実行します。

次のコマンドは、トラスト・ストアおよびキーストアを使用してルートDSEを検索します。

$ ldapsearch -h localhost -p 1636 --useSSL \
--keyStorePath /home/scarter/security/key.db \
--keyStorePasswordFile /home/keystore.pin \
--trustStorePath /home/scarter/security/cert.db --useSASLExternal -b "" \
--searchScope base "(objectClass=*)"

17.5.2.5 StartTLSを使用して検索する方法

ldapsearchユーティリティでStartTLSを使用するプロセスは、SSLを使用するプロセスととてもよく似ています。ただし、次のことを実行する必要があります:

- サーバーがunencrypted LDAPリクエストをリスニングするポートを使用します。

- SSLのかわりにStartTLSを使用する必要があることを示します(つまり、--useSSLオプションのかわりに--startTLSオプションを使用します)。

--startTLSオプションを指定して、ldapsearchコマンドを実行します。

次のコマンドは、startTLSを使用してルートDSEを検索します。

$ ldapsearch -h localhost -p 1389 --startTLS \
-b "" --searchScope base "(objectClass=*)"

17.5.2.6 DIGEST-MD5クライアント認証を利用してSASLを使用して検索する方法

ディレクトリ・サーバーは、いくつかのSimple Authentication and Security Layer (SASL)メカニズムをサポートしています。DIGEST-MD5は、クリアテキスト・パスワードを公開しないサーバーに対するSASL認証の1つの形式です。

適切な--saslOptionオプションを指定して、ldapsearchコマンドを実行します。

authidオプションは、サーバーに認証を受けるユーザーのアイデンティティを指定します。このオプションは、dn (たとえば、dn:uid=scarter,dc=example,dc-com)またはユーザー名(たとえば、authid=u:sam.carter)の形式にすることができます。この属性は、認証後に別のユーザーの認可の下に検索操作を実行する必要があることを示すために使用できます。realmは、サーバー・ホスト・マシンの完全修飾名を指定しますが、省略可能です。

この例では、ルートDSEを検索します。

$ ldapsearch -h localhost -p 1636 --useSSL \
--trustStorePath /home/cert.db --certNickName "my-cert" -w - \
--saslOption mech=DIGEST-MD5 --saslOption realm="example.com" \
--saslOption authid="dn:uid=scarter,dc=example,dc=com" -b "" "(objectclass=*)"

17.5.2.7 GSSAPIメカニズムを利用してSASLを使用して検索する方法

GSSAPIメカニズムはKerberos環境で認証を実行し、クライアント・システムがそのような環境に参加するように構成されていることを必要とします。

有効なKerberosセッションをすでに保持しているユーザーとしてldapsearchコマンドを実行し、検索します。

authid属性は、ユーザーの識別に使用する認証IDを指定します。

この例では、ルートDSEを検索します。

$ ldapsearch -h localhost -p 1389 --saslOption mech=GSSAPI \
--saslOption authid="dn:uid=scarter,dc=example,dc=com" \
--searchScope "" -b "" "(objectclass=*)"

17.5.2.8 PLAINメカニズムを利用してSASLを使用して検索する方法

PLAINメカニズムは、ユーザーが完全なDNではなく認可IDの形式で識別されること以外はLDAP簡易認証に類似した方法で認証を実行します。

有効なKerberosセッションをすでに保持しているユーザーとしてldapsearchコマンドを実行し、検索します。

authid属性は、ユーザーの識別に使用する認証IDを指定します。

この例では、ルートDSEを検索します。

$ ldapsearch -h localhost -p 1389 \
--saslOption mech=PLAIN --saslOption authid="dn:uid=scarter,dc=example,dc=com" \
--searchScope "" -b "" "(objectclass=*)"

17.5.3 制御を使用した検索

LDAP制御は、ldapsearchなどのLDAPコマンドの機能を拡張し、検索結果に対して追加の操作を実行します。各制御は、制御、クリティカル度フラグ、および関連付けられている値を一意に識別するオブジェクト識別子(OID)として定義されます。ディレクトリ・サーバーに制御が送信されるときに、クライアントによってクリティカル度フラグが設定されている場合、そのディレクトリ・サーバーではその制御を使用して操作を実行するか、それを処理しないかのいずれかにする必要があります。フラグがクライアントによって設定されていない場合、ディレクトリ・サーバーでは、その制御を処理できない場合はそれを無視できます。

1つの操作内で、仮想リスト表示とサーバー側ソートなど複数の制御を使用できます。仮想リスト表示制御には、追加の説明が必要なため、それ自体の項で説明します。

この項には次のトピックが含まれます:

- 第17.5.3.1項「使用可能な制御の表示」

- 第17.5.3.2項「結合検索制御を使用した検索」

- 第17.5.3.3項「近接検索制御を使用した検索」

- 第17.5.3.4項「アカウント・ユーザビリティ・リクエスト制御を使用した検索」

- 第17.5.3.5項「認可アイデンティティ・リクエスト制御を使用した検索」

- 第17.5.3.6項「実効権限取得制御を使用した検索」

- 第17.5.3.7項「LDAPアサーション制御を使用した検索」

- 第17.5.3.8項「LDAPサブエントリ制御を使用した検索」

- 第17.5.3.9項「DSA ITの管理制御を使用した検索」

- 第17.5.3.10項「一致値フィルタ制御を使用した検索」

- 第17.5.3.11項「パスワード・ポリシー制御を使用した検索」

- 第17.5.3.12項「永続検索制御を使用した検索」

- 第17.5.3.13項「プロキシ設定された認可制御を使用した検索」

- 第17.5.3.14項「サーバー側ソート制御を使用した検索」

- 第17.5.3.15項「単純なページングの結果制御を使用した検索」

- 第17.5.3.16項「仮想リスト表示制御を使用した検索」

17.5.3.1 使用可能な制御の表示

supportedControl属性のルートDSEエントリを検索することで、ディレクトリ・サーバーの制御の現在のリストを表示できます。

ルートDSEエントリに対してldapsearchコマンドを実行します。

$ ldapsearch -h localhost -p 1389 -b "" --searchScope base "(objectclass=*)" \
supportedControl
dn:
supportedControl: 1.2.826.0.1.3344810.2.3
supportedControl: 1.2.840.113556.1.4.1413
supportedControl: 1.2.840.113556.1.4.319
supportedControl: 1.2.840.113556.1.4.473
supportedControl: 1.2.840.113556.1.4.805
supportedControl: 1.3.6.1.1.12
supportedControl: 1.3.6.1.1.13.1
supportedControl: 1.3.6.1.1.13.2
supportedControl: 1.3.6.1.4.1.26027.1.5.2
supportedControl: 1.3.6.1.4.1.26027.1.5.5
supportedControl: 1.3.6.1.4.1.26027.1.5.6
supportedControl: 1.3.6.1.4.1.26027.2.3.1
supportedControl: 1.3.6.1.4.1.26027.2.3.2
supportedControl: 1.3.6.1.4.1.42.2.27.8.5.1
supportedControl: 1.3.6.1.4.1.42.2.27.9.5.2
supportedControl: 1.3.6.1.4.1.42.2.27.9.5.8
supportedControl: 1.3.6.1.4.1.4203.1.10.1
supportedControl: 1.3.6.1.4.1.4203.1.10.2
supportedControl: 2.16.840.1.113730.3.4.12
supportedControl: 2.16.840.1.113730.3.4.16
supportedControl: 2.16.840.1.113730.3.4.17
supportedControl: 2.16.840.1.113730.3.4.18
supportedControl: 2.16.840.1.113730.3.4.19
supportedControl: 2.16.840.1.113730.3.4.2
supportedControl: 2.16.840.1.113730.3.4.3
supportedControl: 2.16.840.1.113730.3.4.4
supportedControl: 2.16.840.1.113730.3.4.5
supportedControl: 2.16.840.1.113730.3.4.9
supportedControl: 2.16.840.1.113894.1.8.21
supportedControl: 2.16.840.1.113894.1.8.31

制御は、OIDのリストとして返されます。各OIDに対応する制御の説明は、次の表を参照してください。これらの制御の一部はldapsearchコマンドで使用できないことに注意してください。

OID

制御

1.2.826.0.1.3344810.2.3

一致する値の制御

1.2.840.113556.1.4.1413

LDAP変更制限緩和制御

1.2.840.113556.1.4.319

単純なページングの結果制御

1.2.840.113556.1.4.473

サーバー側ソート制御

1.2.840.113556.1.4.805

サブツリー削除制御

1.3.6.1.1.12

LDAPアサーション制御

1.3.6.1.1.13.1

LDAP読込み前制御

1.3.6.1.1.13.2

LDAP読込み後制御

1.3.6.1.4.1.26027.1.5.2

レプリケーション修復制御

1.3.6.1.4.1.26027.1.5.5

ネットワーク・グループ選択制御

1.3.6.1.4.1.26027.1.5.6

ネットワーク・グループ問合せ制御

1.3.6.1.4.1.26027.2.3.1

Join Search Control

1.3.6.1.4.1.26027.2.3.2

近接検索制御

1.3.6.1.4.1.42.2.27.8.5.1

パスワード・ポリシー制御

1.3.6.1.4.1.42.2.27.9.5.2

実効権限取得制御

1.3.6.1.4.1.42.2.27.9.5.8

アカウント・ユーザビリティ・リクエスト制御

1.3.6.1.4.1.4203.1.10.2

LDAP操作なし制御

1.3.6.1.4.1.4203.1.10.1

LDAPサブエントリ・リクエスト制御

2.16.840.1.113730.3.4.12

プロキシ認可v1制御

2.16.840.1.113730.3.4.16

認可アイデンティティ制御

2.16.840.1.113730.3.4.17

実在属性専用制御

2.16.840.1.113730.3.4.18

プロキシ認可v2制御

2.16.840.1.113730.3.4.19

仮想属性専用制御

2.16.840.1.113730.3.4.2

DSA ITの管理制御

2.16.840.1.113730.3.4.3

永続検索制御

2.16.840.1.113730.3.4.4

Netscapeパスワード有効期限切れLDAPv3制御

2.16.840.1.113730.3.4.5

Netscapeパスワード有効期限切れ間近LDAPv3制御

2.16.840.1.113730.3.4.9

仮想リスト表示制御

2.16.840.1.113894.1.8.21

検索件数リクエスト制御

2.16.840.1.113894.1.8.31

ECID実行情報制御

17.5.3.2 結合検索制御を使用した検索

結合検索制御では、1回の検索操作で、友人、マネージャなど関連するエントリ・ツリー・チェーンを取得します。結合制御がターゲットとすることができるのは、相互参照できる(ただし、しなくてもよい)確立された関係を持つエントリ・チェーンのみです。

たとえば、次のエントリは、参加しているエントリそれぞれが他の参加しているエントリにリンクを持つ確立されたfriends関係階層の一部です。この場合、これらのリンクはfriend属性によって形成されます。

dn: uid=user.3,ou=People,dc=example,dc=com
objectClass: person
objectClass: organizationalperson
objectClass: inetorgperson
objectClass: top
uid: user.3
cn: Kenny McCormick
sn: McCormick
friend: uid=user.0,ou=People,dc=example,dc=com
friend: uid=user.1,ou=People,dc=example,dc=com
friend: uid=user.2,ou=People,dc=example,dc=com
...

結合制御を使用する検索操作では、範囲およびフィルタなどの検索パラメータは、その結合検索、つまり結合中に評価されたエントリに適用されます。つまり、一致する結果のみが返されます。この機能によって、1回の検索操作で、特定の検索基準または範囲に基づいて、リンクされた関係階層全体を取得したり、そのサブセットを取得できます。

次のように、近似検索制御OID (1.3.6.1.4.1.26027.2.3.1)とともに--controlまたは-Jオプションを使用することで、ldapsearchコマンドで近似検索制御を指定できます:

OID:criticality:attribute

ここで、attributeは、エントリ間の関係の基になっている属性です。

次の例では、friend属性を介してリンクしているユーザー・エントリのサブセットをリクエストします。

$ ldapsearch -h localhost -p 1389 -D "cn=directory manager" -j pwd-file \
--baseDN "uid=user.3,ou=People,dc=example,dc=com" \
--searchScope sub \
-J "1.3.6.1.4.1.26027.2.3.1:true:friend" \
"(objectClass=person)"

結合検索では、検索パラメータには次のような意味があります:

- baseDN
検索ベースは、結合検索を開始するエントリを指定するために使用します。

- searchScope
検索範囲は、結合の深さの個別のレベルを指定するために使用します。

- baseの検索範囲は、直接の関係(たとえば、サンプル・エントリではfriend属性によって指定される直接の友人)のみを取得します。

- oneの検索範囲は、1レベル深くなり、サンプル・エントリの直接の友人の直接の友人を取得します。

- subの検索範囲は、レベルの数に関係なく階層チェーン全体を横断します。

- subordinateの検索範囲は、subと同じ効力を持ちますが、検索結果にベース・エントリは含まれません。

- filter
検索フィルタは、検索結果に含めるための結合中に、候補のエントリを評価するために使用されます。フィルタは、特定のエントリのみを含めるように検索を絞り込むためにも使用できます。これは、標準検索操作のフィルタと同じですが、結合検索結果にのみ適用できます。

17.5.3.3 近接検索制御を使用した検索

近似検索制御は、検索リクエストにおいてサーバーにベースの位置データを提供します。これによって、サーバーは、位置データを含む近似仮想属性値を候補のエントリすべてに対して生成できます。エントリ内のlocation属性の値は、WGS84標準形式の緯度経度GPS座標です。ユーザー・アプリケーションは、ユーザーの最後の既知の位置で、この属性の値を定期的に更新できます。たとえば、次の抽出されたエントリは、位置がゴールデン・ゲート・ブリッジの座標に更新されたエントリを示しています:

dn: uid=user.1,ou=People,dc=example,dc=com
objectClass: geoObject
objectClass: person
objectClass: organizationalperson
objectClass: inetorgperson
objectClass: top
objectClass: geoObject
uid: user.1
cn: Bob Smith
sn: Smith
location: 37.81997, -122.47859
...

サーバーは、近似検索制御で提供されるベースの位置に対する、各エントリの場所の近接度を計算できます。

したがって、クライアント・アプリケーションは、一致する検索結果エントリごとに近似値を計算して返すようにリクエストできます。クライアント・アプリケーションは、検索操作自体の検索フィルタで近似属性を使用でき、したがって、指定されたベースの位置に対するそれらの近接度に基づいて一致する検索結果エントリをリクエストできます。

次のように、近似検索制御OID (1.3.6.1.4.1.26027.2.3.2)とともに--controlまたは-Jオプションを使用することで、ldapsearchコマンドで近似検索制御を指定できます:

OID:criticality:location

ここで、位置は、WGS84標準形式の緯度経度GPS座標を表します。

次の例では、ベース位置をエッフェル塔(48.858844, 2.294351)の座標に設定し、位置がベース位置から500m以内のすべてのユーザー・エントリをリクエストします。

$ ldapsearch -h localhost -p 1389 -D "cn=directory manager" -j pwd-file \
-b "dc=example,dc=com" --searchScope sub \
-J "1.3.6.1.4.1.26027.2.3.2:true:48.858844,2.294351" \
"(&(objectClass=person)(proximity<=500))"

17.5.3.4 アカウント・ユーザビリティ・リクエスト制御を使用した検索

アカウント・ユーザビリティ・リクエスト制御は、ユーザー・アカウントをサーバーから認証を受けるために使用できるかどうかを判別します。ユーザー・アカウントを使用できる場合、その制御によって、アカウントが使用可能であるかどうかに基づいてエントリの前にメッセージが追加されます。

次のようにしてldapsearchとともにアカウント・ユーザビリティ・リクエスト制御を指定できます:

- OID。アカウント・ユーザビリティ・リクエスト制御OIDの1.3.6.1.4.1.42.2.27.9.5.8とともに、値を指定しないで--controlまたは-Jオプションを使用します。

- 名前付き定数。アカウント・ユーザビリティ・リクエスト制御OIDのかわりに、名前付き定数accountusableまたはaccountusabilityを--controlまたは-Jオプションとともに使用します。たとえば、ldapsearchコマンドとともに-J accountusableまたは-J accountusabilityを使用します。

--controlオプションまたはその短い形式である-Jを指定して、ldapsearchコマンドを実行します。

$ ldapsearch -h localhost -p 1389 -b "dc=example,dc=com" \
--searchScope sub -J "accountusability:true" "(objectclass=*)"
# Account Usability Response Control
# The account is usable
dn: dc=example,dc=com
objectClass: domain
objectClass: top
dc: example
...

17.5.3.5 認可アイデンティティ・リクエスト制御を使用した検索

認可アイデンティティ・リクエスト制御によって、クライアントは、LDAPバインド・リクエスト中にクライアント接続のための認可アイデンティティを取得できます。サーバーによって返される認可IDは、認証が完了するとただちにクライアントに表示されます。認可IDを含む行は、前に#文字が付けられ、出力がLDIFとして解釈される場合にコメントになります。

次のいくつかの方法で、ldapsearchとともに認可アイデンティティ・リクエスト制御を指定できます:

- OID。認可アイデンティティ・リクエスト制御OIDの2.16.840.1.113730.3.4.16とともに、値を指定しないで--controlまたは-Jオプションを使用します。

- 名前付き定数。認可アイデンティティ・リクエスト制御OIDのかわりに、名前付き定数authzidまたはauthorizationidentityを--controlまたは-Jオプションとともに使用します。たとえば、ldapsearchコマンドとともに-J authzidまたは-J authorizationidentityを使用します。

--reportAuthzIDオプションを指定して、ldapsearchコマンドを使用します。

$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" \
-j pwd-file -b dc=example,dc=com --searchScope base \
--reportAuthzID "(objectclass=*)"
# Bound with authorization ID dn:cn=Directory Manager,cn=Root DNs,cn=config
dn: dc=example,dc=com
objectClass: domain
objectClass: top
dc: example

17.5.3.6 実効権限取得制御を使用した検索

実効権限取得制御によって、既存または新しいACIを評価でき、指定されたエントリ上のユーザーに付与された実効権限を確認できます。

この制御に対するレスポンスは、検索結果のエントリおよび属性に関する実効権限情報を返すことです。この追加情報としては、各エントリとその中の各属性に対する読取り権限および書込み権限などがあります。権限は、検索に使用するバインドDNまたは任意のDNに対してリクエストできるため、管理者はディレクトリ・ユーザーの権限をテストできます。

ldapsearchコマンドには、次の2つの実効権限取得制御の使用方法があります:

- -J effectiverightsまたはOID -J "1.3.6.1.4.1.42.2.27.9.5.2"を使用します。リクエストは認可ID (authzid)のみを取ります。認可ID (authzid)にNULL値を指定すると、バインド・ユーザーはauthzidとして使用されます。

- -g dn:"dn"を使用します。このコマンド・オプションは、指定されたDNとバインドされているユーザーの実効権限を示します。このオプションを-eオプションとともに使用して、指定した属性に対する実効権限を含めることができます。このオプションを使用すると、エントリ内に現在存在しない属性を追加する権限をユーザーが持っているかどうかを判別できます。

注意:

-Jオプションとともに-gオプションを使用することはできません。

実効権限を表示するには、仮想属性aclRightsおよびaclRightsInfoを指定する必要があります。これらは、実効権限リクエストに応答してサーバーによって生成されます。したがって、どのような種類の検索コマンドでもこれらの属性を使用しないでください。

1. ldapsearchコマンドを使用して、すべてのユーザーの実効権限を表示します。

$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
-b dc=example,dc=com -J effectiverights "(objectclass=*)" aclRights

dn: dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0

dn: ou=Groups, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0

dn: ou=People, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0

dn: cn=Accounting Managers,ou=groups,dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0

dn: cn=HR Managers,ou=groups,dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0

...

2. ldapsearchコマンドを使用して、特定のユーザーの実効権限を表示します。
この例では、--getEffectiveRightsAuthzidオプションを使用します。-J geteffectiverightsなど--controlまたは-Jオプションも使用できます。

$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
-b dc=example,dc=com \
--getEffectiveRightsAuthzid "dn:uid=scarter,ou=People,dc=example,dc=com" \
"(uid=scarter)" aclRights
dn: uid=scarter,ou=People,dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:1,proxy:0

3. ldapsearchコマンドを使用して、特定のユーザーの実効権限情報を表示します。
aclRightsInfo属性は、実効権限がどのように付与または拒否されているかを説明する詳細なロギング情報を提供します。

ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
-b dc=example,dc=com \
--getEffectiveRightsAuthzid "dn:uid=scarter,ou=People,dc=example,dc=com"\
"(uid=scarter)" aclRightsInfo

dn: uid=scarter,ou=People,dc=example,dc=com
aclRightsInfo;logs;entryLevel;add: acl_summary(main): access not allowed(add) on
entry/attr(uid=scarter,ou=People,dc=example,dc=com, NULL) to
(uid=scarter,ou=People,dc=example,dc=com)
(not proxied) ( reason: no acis matched the subject )
aclRightsInfo;logs;entryLevel;proxy: acl_summary(main): access not allowed(proxy ) on
entry/attr(uid=scarter,ou=People,dc=example,dc=com, NULL) to
(uid=scarter, ou=People,dc=example,dc=com)
(not proxied) ( reason: no acis matched the subject )
aclRightsInfo;logs;entryLevel;write: acl_summary(main): access allowed(write) on
entry/attr(uid=scarter,ou=People,dc=example,dc=com, NULL) to
(uid=scarter,ou=People,dc=example,dc=com)
(not proxied) ( reason: evaluated allow , deciding_aci : Allow self entry modification)
aclRightsInfo;logs;entryLevel;read: acl_summary(main): access allowed(read) on
entry/attr(uid=scarter,ou=People,dc=example,dc=com, NULL) to
(uid=scarter,ou=People,dc=example,dc=com)
(not proxied) ( reason: evaluated allow , deciding_aci: Anonymous extended
operation access)
aclRightsInfo;logs;entryLevel;delete: acl_summary(main): access not allowed(delete) on
entry/attr(uid=scarter,ou=People,dc=example,dc=com, NULL) to
(uid=scarter,ou=People,dc=example,dc=com)
(not proxied) ( reason: no acis matched the subject )

17.5.3.7 LDAPアサーション制御を使用した検索

LDAPアサーション制御によって、検索操作を処理するためにtrueに評価される必要がある条件を指定できます。この制御の値は、LDAP検索フィルタの形式にする必要があります。サーバーによって、検索範囲とフィルタに一致するエントリを検索する前に、ベース・オブジェクトがテストされます。アサーションが失敗すると、エントリは何も返されません。

この例では、最初にアサーションを満たすかどうかを判別し、エントリが検索フィルタに一致する場合はそれを返します。

アサーション(objectclass=top)を使用し、--assertionFilterオプションを指定して、ldapsearchコマンドを実行します。

$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
-b "cn=HR Managers,ou=Groups,dc=example,dc=com" \ -s sub \
--assertionFilter "(objectclass=top)" "(objectclass=*)"
dn: cn=HR Managers,ou=groups,dc=example,dc=com
objectClass: groupOfUniqueNames
objectClass: top
ou: groups
description: People who can manage HR entries
uniqueMember: uid=kvaughan, ou=People, dc=example,dc=com
uniqueMember: uid=cschmith, ou=People, dc=example,dc=com
cn: HR Managers

17.5.3.8 LDAPサブエントリ制御を使用した検索

LDAPサブエントリ制御によって、クライアントは、検索操作中にldapSubEntryオブジェクト・クラスを持つエントリのみがサーバーによって返されることをリクエストできます。LDAPサブエントリは、操作属性に類似した操作オブジェクトであり、それらが明示的にリクエストされた場合にのみ返されます。通常、スキーマを検索する場合はこの制御を使用できます。

次のようにしてldapsearchで、サブエントリを返すようにサーバーにリクエストします:

- --subEntriesオプションを使用して、LDAPサブエントリ制御を指定します。

- ベースDNが既知である場合は、ベース検索範囲を指定して特定のサブエントリを取得します。

- 等価フィルタ(objectclass=ldapSubentry)を使用します。

注意:

等価フィルタの使用は、標準の一部ではなく、後方互換性のためにのみサポートされています。

次のように、--subEntriesオプションを指定して、ldapsearchコマンドを実行します:

$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
-b "cn=schema" --subEntries "(objectclass=*)"

17.5.3.9 DSA ITの管理制御を使用した検索

DSA ITの管理制御によって、クライアントは、検索中にサーバーがスマート・リフェラルを通常のエントリとして処理することをリクエストできます。スマート・リフェラルは、別のサーバーまたはディレクトリ情報ツリーDIT内の場所を参照し、そのリフェラルを指定するLDAP URLを含む1つ以上の属性を持つreferralオブジェクト・クラスが含まれているエントリです。

次のいくつかの方法で、ldapsearchとともにDSA ITの管理制御を指定できます:

- OID。DSA ITの管理制御OIDの2.16.840.1.113730.3.4.2とともに、値を指定しないで--controlまたは-Jオプションを使用します。

- 名前付き定数。DSA ITの管理制御OIDのかわりに、名前付き定数managedsaitを--controlまたは-Jオプションとともに使用します。たとえば、ldapsearchコマンドとともに-J managedsaitを使用します。

検索でDSA ITの管理制御を使用するには、次のように-Jオプションを指定してldapsearchコマンドを実行します:

$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
-b dc=example,dc=com -J managedsait "(uid=president)" ref
dn: uid=president,ou=People,dc=example,dc=com
ref: ldap://example.com:389/dc=example,dc=com??sub?(uid=bjensen)

注意:

-J managedsait引数を指定しないと、このコマンドは、参照先のエントリを返します。

17.5.3.10 一致値フィルタ制御を使用した検索

一致値フィルタ制御によって、クライアントは、Trueに評価される属性値のサブセットをエントリにリクエストできます。この制御によって、ユーザーは、すべての値を取得することなく属性値のサブセットを選択して読み取り、目的のセットをローカルにスキャンできます。

--matchedValuesFilterオプションを指定して、ldapsearchコマンドを実行します。

$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
-b ou=groups,dc=example,dc=com --matchedValuesFilter "(uniquemember=uid=kvaughan*)"
"(objectclass=*)"
dn: ou=Groups,dc=example,dc=com
dn: cn=Directory Administrators,ou=Groups,dc=example,dc=com
uniqueMember: uid=kvaughan, ou=People, dc=example,dc=com
dn: cn=Accounting Managers,ou=groups,dc=example,dc=com
dn: cn=HR Managers,ou=groups,dc=example,dc=com
uniqueMember: uid=kvaughan, ou=People, dc=example,dc=com
dn: cn=QA Managers,ou=groups,dc=example,dc=com
dn: cn=PD Managers,ou=groups,dc=example,dc=com

17.5.3.11 パスワード・ポリシー制御を使用した検索

パスワード・ポリシー制御によって、クライアントは、ユーザー・エントリの現在のパスワード・ポリシー情報に関する情報をリクエストできます。

次のいくつかの方法で、ldapsearchとともにパスワード・ポリシー制御を指定できます:

- OID。パスワード・ポリシー制御OIDの1.3.6.1.4.1.42.2.27.8.5.1とともに、値を指定しないで--controlまたは-Jオプションを使用します。

- 名前付き定数。パスワード・ポリシー制御OIDのかわりに、名前付き定数pwpolicyまたはpasswordpolicyを--controlまたは-Jオプションとともに使用します。たとえば、ldapsearchとともに-J pwpolicyまたは-J passwordpolicyを使用します。

- オプション。--usePasswordPolicyControlオプションを使用します。

注意:

-Jまたは--controlオプションは、検索リクエストでどの制御を使用するのかを指定するために使用します。--usePasswordPolicyControlオプションは、バインド・リクエストに使用されます。

--usePasswordPolicyControlオプションを指定して、ldapsearchコマンドを実行します。

$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
-b dc=example,dc=com -s base --usePasswordPolicyControl "(objectclass=*)"

17.5.3.12 永続検索制御を使用した検索

永続検索制御によって、クライアントは、追加、削除または変更操作によってディレクトリのエントリが変更されたときに、通知を受け取れます。変更が行われたときに、そのエントリが、エントリ変更通知制御によって使用された検索基準に一致する場合、サーバーによって更新済エントリがクライアントに送信されます。

ldapsearchコマンドには、接続を開いたままにして、変更(追加、削除、変更、またはすべて)が発生するたびにその範囲およびフィルタに一致するエントリを表示する永続検索(-C)を実行するオプションがあります。この検索は、[Ctrl] + [C]を押すことで終了できます。

この引数の値は、ps[[:''changetype''[[:''changesonly''[[:''entrychangecontrols'']]]の形式にする必要があります。

この値の要素には、次のものがあります:

- ps: 必須演算子。

- changetype: クライアントが通知の受信を必要とする変更のタイプを指定します。この要素は、add、del、mod、moddnのいずれか、またはすべての変更タイプに登録する場合はallです。また、複数の特定の変更タイプに登録するには、カンマ区切りリストにすることもできます。この要素が指定されない場合、デフォルトとしてall変更タイプが含まれます。

- changesonly: Trueの場合、クライアントは、その検索が登録された後に一致するエントリに行われた変更のみを通知されます。Falseの場合、サーバーによって、サーバー内の指定された検索基準に一致するすべての既存のエントリも送信されます。この要素が指定されていない場合、デフォルトでは、その検索が登録された後に発生した更新についてのみエントリが返されます。

- entrychangecontrols: Trueの場合、サーバーは、変更の結果としてクライアントに送信されるエントリ内にエントリ変更通知制御を含めます。Falseの場合、エントリ変更通知制御は含められません。この要素が指定されない場合、デフォルトとしてエントリ変更通知制御が含まれます。

1. ldapsearchコマンドを次のように実行します:

$ ldapsearch -h localhost -p 1389 -D "cn=admin,cn=Administrators,cn=config" \
-j pwd-file -b dc=example,dc=com --persistentSearch ps:add:true:true \
"(objectclass=*)"

注意:

このコマンドを使用する場合、サーバーはadd、delete、modifyまたはallを使用して行われた変更を待って、値を返します。

2. 別の端末ウィンドウを開き、ldapmodifyを使用して新しいエントリを追加します。

$ ldapmodify -h localhost -p 1389 -b dc=example,dc=com \
--defaultAdd --filename new_add.ldif
Processing ADD request for uid=Marcia Garza,ou=People,dc=example,dc=com
ADD operation successful for DN uid=Marcia Garza,ou=People,dc=example,dc=com

3. 元の端末ウィンドウに変更内容が表示されます。
このセッションを終了するには、[Ctrl] + [Z] (Unix/Linux)または[Ctrl] + [C] (Windows)を押します。

# Persistent search change type:  add
dn: uid=Marcia Garza,ou=People,dc=example,dc=com
objectClass: person
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: top
givenName: Marcia
uid: mgarza
uid: Marcia Garza
cn: Marcia Garza
sn: Garza
userpassword: {SSHA}SNfL1RUm5uvTnLK+G0K3oz+Peb1i5/+YsylfBg==
roomnumber: 5484
l: Santa Clara
ou: Accounting
ou: People
mail: mgarza@example.com

4. このセッションを途中で終了させるには、[Ctrl] + [D] (Unix/Linux)または[Ctrl] + [C] (Windows)を押し、Yと入力して終了します。

Terminate batch job (Y/N)?

17.5.3.13 プロキシ設定された認可制御を使用した検索

プロキシ設定された認可制御によって、クライアントは、特定の操作に対して別のエントリを偽装できます。この制御は、多数の異なるユーザーのかわりに実行する必要がある信頼できるアプリケーションにおいて役立ち、そのアプリケーションが操作ごとに再度認証を受ける必要がなくなります。

次のように、--proxyAsオプションを指定して、ldapsearchコマンドを実行します:

ここで、プロキシ設定された認可制御を使用するには、サブツリー内でclientAppが適切なACI権限を持っている必要があります。付与されていない場合は、LDAPエラー50「不十分なアクセス権限」がクライアントに返されます。

$ ldapsearch -h localhost -p 1389 \
-D "uid=clientApp,ou=Applications,dc=example,dc=com" -j pwd-file \
-s sub -b dc=example,dc=com \
--proxyAs "dn:uid=acctgAdmin,ou=Administrators,ou=People,dc=example,dc=com" \
"(uid=kvaughan)" mail

17.5.3.14 サーバー側ソート制御を使用した検索

サーバー側ソート制御によって、クライアントは、サーバーが検索結果をクライアントに送信する前にそれらをソートするようにリクエストできます。これは、サーバーに、クライアントによってリクエストされたソート順序をクライアントより速く満たすことができる索引がある場合に便利です。

--sortOrderオプションを使用することで、返されるエントリをソートできます。昇順の+ (プラス記号)または降順の- (マイナス記号)を指定しない場合、デフォルトのオプションは、昇順でのソートです。

1. ldapsearchコマンドを使用して、すべてのエントリを検索し、昇順で結果を表示します。
--sortOrderオプションを指定して、snおよびgivenName属性を基準にソートします。

$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
--s sub -b dc=example,dc=com --sortorder sn,givenName "(objectclass)"
dn: uid=dakers,ou=People,dc=example,dc=com
objectClass: person
objectClass: organizationalPerson
...<search results>...

2. ldapsearchコマンドを使用して、すべてのエントリを検索し、降順で結果を表示します。
--sortorderオプションを指定して、属性snを基準にソートします。

$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
-s sub -b dc=example,dc=com --sortOrder -sn "(objectclass)"
dn: uid=pworrell,ou=People,dc=example,dc=com
objectClass: person
objectClass: organizationalPerson
...<search results>...

17.5.3.15 単純なページングの結果制御を使用した検索

単純なページングの結果制御によって、検索操作で、一度に結果のサブセットのみを返すことができます。検索結果全体を一度に1ページずつ取り出すために使用できます。これは、仮想リスト表示制御に似ていますが、結果のソートを必要とせず、検索結果全体に順番に繰り返し処理を実行するためにのみ使用できます。

--simplePageSizeオプションを指定して、ldapsearchコマンドを使用します。

次のコマンドは、--countEntriesオプションを使用して、各ページをマークします。

$ ldapsearch --hostname localhost --port 1389 \
--bindDN "cn=Directory Manager" --bindPassword password \
--searchScope sub --baseDN dc=example,dc=com \
--simplePageSize 2 --countEntries "(objectclass=*)"

dn: ou=Groups,dc=example,dc=com
objectClass: organizationalunit
objectClass: top
ou: Groups

dn: ou=People,dc=example,dc=com
objectClass: organizationalunit
objectClass: top
ou: People

# Total number of matching entries: 2

dn: ou=Special Users,dc=example,dc=com
objectClass: organizationalUnit
objectClass: top
description: Special Administrative Accounts
ou: Special Users

dn: ou=Company Servers,dc=example,dc=com
objectClass: organizationalUnit
objectClass: top
description: Standard branch for Company Server registration
ou: Company Servers

# Total number of matching entries: 2

dn: ou=Contractors,dc=example,dc=com
objectClass: organizationalUnit
objectClass: top
ou: Contractors
ou: Product Testing
ou: Product Development
ou: Accounting

# Total number of matching entries: 1

17.5.3.16 仮想リスト表示制御を使用した検索

仮想リスト表示制御によって、クライアントは、サーバーにエントリの特定の範囲内で小さい、管理可能なチャンクで検索結果を送信するようにリクエストできます。GUIブラウザまたはアプリケーションで特定のエントリに直接移動するように構成されている場合は、これにより、クライアントは、検索操作の結果内を前後に移動することもできるようになります。

注意:

仮想リスト表示制御は、返されるエントリのソートが必要です。

--virtualListViewオプションまたはその短い形式である-Gとともに、次の引数を指定します:

- before。結果に含めるターゲットの前のエントリ数を指定します。
before値がターゲット・オフセット以上である場合は、返される最初のエントリが、リストの先頭になるようにbefore値が調整されます。

- after。結果に含めるターゲットの後のエントリ数を指定します。

- index。結果セット内のターゲット・エントリのオフセットを指定します。索引の1は、常に最初のエントリを意味します。indexとcontent_countが等しい場合、最後のエントリが選択されます。
index値が負である場合、サーバーによってリクエストが拒否されます。

index値が0である場合、返される値が表示されるようにそれが1に調整されます。

index値が、一致する値の合計数よりも大きい場合、その内容の数より1大きいものに調整されます。

indexの値は、アサーション値にすることもでき、そのようにすると返されるエントリにその値が含まれます。返されるエントリが、リストの終わりに近すぎて、afterの値が最後のエントリを超える場合は、afterの値が適切なエントリを表示するように調整されます。

- count。結果セットの予期されるサイズを指定します。

- count=0。ターゲット・エントリは、指定されたindexの位置にあるエントリで、1から始まり、ソート結果の全体リストに相対しています。この引数は、クライアントが結果セットのサイズを把握していない場合に使用します。

- count=1。ターゲット・エントリは、ソート結果のリストにある最初のエントリです。

- count>1。ターゲット・エントリは、index/countの分数で表されるリストの一部の最初のエントリです。リストの最後の結果をターゲットにするには、count引数よりも大きいindex引数を使用します。クライアント・アプリケーションは、ユーザーがスクロール・バーを使用して長いリスト内を移動できるインタフェースを使用できます。たとえば、indexが33で、countが100の場合、アプリケーションは、リストの33パーセント進んだ位置に移動できます。

たとえば、引数(0:4:1:0)は、索引1にあるターゲット・エントリの前の0個のエントリと、後の4個のエントリを表示することを示します。クライアントがセットのサイズを把握していない場合、countは0です。

17.5.3.16.1 仮想リスト表示制御を使用した検索

ソート順序オプション(-S)は、仮想リスト表示制御とともに使用する必要があります。この例では、仮想リスト表示制御オプションを使用して、次のように指定します:

- Before=0。ターゲットの前の0個のエントリを表示することを指定します。

- After=2。ターゲットの後の2個のエントリを表示することを指定します。

- Index=1。結果セット内のターゲット・エントリのオフセットを返すことを指定します。

- Count=0。索引位置にあるターゲット・エントリ(最初のエントリ)を返すことを指定します。

したがって、サーバーによって、最初のエントリと、そのターゲットの後の2個のエントリが、givenName属性で昇順にソートされて返されます。

--virtualListViewオプションを指定して、ldapsearchコマンドを使用します。

$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -w bindPassword \
-b dc=example,dc=com --searchScope sub --sortOrder givenName \
--virtualListView "0:2:1:0" "(objectclass=*)"

dn: uid=awhite,ou=People,dc=example,dc=com
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: top
givenName: Alan
uid: awhite
cn: Alan White
sn: White
...

dn: uid=aworrell,ou=People,dc=example,dc=com
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: top
givenName: Alan
uid: aworrell
cn: Alan Worrell
sn: Worrell
...

dn: uid=alutz,ou=People,dc=example,dc=com
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: top
givenName: Alexander
uid: alutz
cn: Alexander Lutz
sn: Lutz
...

# VLV Target Offset: 1
# VLV Content Count: 172

17.5.3.16.2 特定のターゲットを指定して仮想リスト表示を使用して検索する方法

ソート順序(-S)オプションは、仮想リスト表示とともに使用する必要があります。この例のコマンドでは、仮想リスト表示制御オプションを使用して、次のように指定します:

- Before=0。ターゲットの前の0個のエントリを表示することを指定します。

- After=4。ターゲットの後の4個のエントリを表示することを指定します。

- Index=jensen。結果セット内の文字列jensenを返すことを指定します。

- Count=指定しない。デフォルトのcount=0を使用します。これは最初のエントリです。

したがって、サーバーによって、jensenに一致する最初のsn属性と、そのターゲットの後の4個のsn属性が、sn属性で昇順にソートされて返されます。

--virtualListViewオプションを指定して、ldapsearchコマンドを使用します。

$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
-b dc=example,dc=com --searchScope sub --sortOrder sn \
--virtualListView "0:4:jensen" "(objectclass=*)" sn

dn: uid=kjensen,ou=People,dc=example,dc=com
sn: Jensen

dn: uid=bjensen,ou=People,dc=example,dc=com
sn: Jensen

dn: uid=gjensen,ou=People,dc=example,dc=com
sn: Jensen

dn: uid=jjensen,ou=People,dc=example,dc=com
sn: Jensen

dn: uid=ajensen,ou=People,dc=example,dc=com
sn: Jensen

# VLV Target Offset: 56
# VLV Content Count: 172

17.5.3.16.3 既知の合計を指定して仮想リスト表示を使用して検索する方法

ソート順序(-S)オプションは、仮想リスト表示とともに使用する必要があります。この例のコマンドでは、仮想リスト表示制御オプションを使用して、次のように指定します:

- Before=0。ターゲットの前の0個のエントリを表示することを指定します。

- After=2。ターゲットの後の2個のエントリを表示することを指定します。

- Index=57。結果セット内の57の索引を返すことを指定します。これは、リストの約1/3です。

- Count=172。合計カウントを使用します。

したがって、サーバーによって、リスト内の1/3である最初のsn属性と、2個のsn属性が、sn属性で昇順にソートされて返されます。

--virtualListViewオプションを指定して、ldapsearchコマンドを使用します。

$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
-b dc=example,dc=com -s sub --sortOrder sn \
--virtualListView "0:2:57:172" "(objectclass=*)" sn

dn: uid=bjensen,ou=People,dc=example,dc=com
sn: Jensen

dn: uid=gjensen,ou=People,dc=example,dc=com
sn: Jensen

dn: uid=jjensen,ou=People,dc=example,dc=com
sn: Jensen

# VLV Target Offset: 57
# VLV Content Count: 172

17.5.3.16.4 仮想リスト表示制御への匿名アクセスの許可

デフォルトてば、仮想リスト表示制御へのアクセスは、認証済のユーザーにのみ許可されます。認証されていないユーザーに仮想リスト表示制御へのアクセスを許可するには、仮想リスト表示制御(2.16.840.1.113730.3.4.9)のOIDを、「匿名制御アクセス」グローバルACIに追加し、「認証済ユーザー制御アクセス」グローバルACIから削除する必要があります。

ds-cfg-global-aci: (targetcontrol="2.16.840.1.113730.3.4.2 ||
2.16.840.1.113730.3.4.17 || 2.16.840.1.113730.3.4.19 ||
1.3.6.1.4.1.4203.1.10.2 || 1.3.6.1.4.1.42.2.27.8.5.1 ||
2.16.840.1.113730.3.4.16 || 2.16.840.1.113894.1.8.31") (version 3.0; acl
"Anonymous control access"; allow(read) userdn="ldap:///anyone";)
ds-cfg-global-aci: (targetcontrol="1.3.6.1.1.12 || 1.3.6.1.1.13.1 ||
1.3.6.1.1.13.2 || 1.2.840.113556.1.4.319 || 1.2.826.0.1.3344810.2.3 ||
2.16.840.1.113730.3.4.18 || 2.16.840.1.113730.3.4.9 || 1.2.840.113556.1.4.473
|| 1.3.6.1.4.1.42.2.27.9.5.9 || 1.2.840.113556.1.4.473") (version 3.0; acl
"Authenticated users control access"; allow(read) userdn="ldap:///all";)

これらのグローバルACIを変更する最も簡単な方法は、次のようにODSMを使用することです:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「セキュリティ」タブを選択します。

3. 「ルート」メニューから、匿名制御アクセスを選択します。

4. 左側のペインの「ターゲット」表で、「ターゲット制御」フィールドを選択し、「編集」をクリックします。

5. 「使用可能なコントロール」リストから、仮想リスト表示制御(2.16.840.1.113730.3.4.9)を選択します。

6. 右矢印をクリックして、VLV制御を「選択したコントロール」リストに移動します。

7. 「OK」をクリックします。

8. 「適用」をクリックして、変更を保存します。

9. 「ルート」メニューから、認証済ユーザー制御アクセスを選択します。

10. 左側のペインの「ターゲット」表で、「ターゲット制御」フィールドを選択し、「編集」をクリックします。

11. 「選択したコントロール」リストから、仮想リスト表示制御(2.16.840.1.113730.3.4.9)を選択します。

12. 左矢印をクリックして、VLV制御を「使用可能なコントロール」リストに移動します。

13. 「OK」をクリックします。

14. 「適用」をクリックして、変更を保存します。

dsconfigを使用してグローバルACIを変更することもできますが、dsconfigでACI値を変更することはできません。かわりに、ACIを削除して再作成する必要があります。詳細は、第22.1.1項「デフォルト・グローバルACI」を参照してください。

17.5.4 詳細モードでの検索とプロパティ・ファイルを使用した検索

この項では、詳細モードで検索する方法と、プロパティ・ファイルを使用して検索する方法について説明し、内容は次のとおりです:

- 第17.5.4.1項「詳細モードで検索する方法」

- 第17.5.4.2項「プロパティ・ファイルを使用して検索する方法」

17.5.4.1 詳細モードで検索する方法

詳細モードでは、クライアントとサーバー間で送信されている処理情報が表示されます。このモードはデバッグに便利です。

ldapsearchコマンドを次のように使用します:

$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
-b dc=example,dc=com -s base --verbose "(objectclass=*)"
LDAP: C>S 01:43:46.140 (0ms) LDAPMessage(msgID=1, protocolOp=BindRequest
(version =3, dn=cn=Directory Manager, password=password))
ASN1: C>S 01:43:46.140 (0ms) ASN.1 Sequence
BER Type: 30
Decoded Values:
ASN1Integer(type=02, value=1)
ASN1Sequence(type=60, values={ ASN1Integer(type=02, value=3),
cn=Directory Manager, opends })
Value:
02 01 01 60 23 02 01 03   04 14 63 6E 3D 64 69 72     `#  cn=directory
65 63 74 6F 72 79 20 6D   61 6E 61 67 65 72 80 08          manager
70 61 73 73 77 6F 72 64                                    password
...

17.5.4.2 プロパティ・ファイルを使用して検索する方法

ディレクトリ・サーバーは、ldapsearchコマンドで使用するデフォルト引数値を保持しているプロパティ・ファイルの使用をサポートしています。プロパティ・ファイルは、様々な構成環境、特にスクリプト済アプリケーションまたは埋込みアプリケーションで作業する場合に便利です。詳細は、付録A「サーバー・コマンドによるプロパティ・ファイルの使用方法」を参照してください。

1. 任意のテキスト・エディタで、次の内容のプロパティ・ファイルを作成します:

hostname=localhost
port=1389
bindDN=cn=Directory Manager
bindPasswordFile=pwd-file
baseDN=dc=example,dc=com
searchScope=sub
sortOrder=givenName
virtualListView=0:2:1:0

2. ファイルをtools.propertiesという名前で保存します。

3. --propertiesFilePathオプションを指定して、ldapsearchを使用します。

$ ldapsearch --propertiesFilePath tools.properties "(objectclass=*)"

17.5.5 国際化されたエントリの検索

Oracle Unified Directoryでは、エントリと突き合せて、第17.5.3.14項「サーバー側ソート制御を使用した検索」のように使用して検索結果をソートする照合ルールがサポートされています。この照合ルールは、次に示すように、コロンで区切って、検索フィルタで一致ルールとして指定します:

locale.matchingRule

ここで:

- localeは、次のいずれかの方法で指定します。

- ロケールOID

- ロケール文字接尾辞(ar、en、fr-CAなど)。
サポートされているロケール、それらのOIDおよびタグのリストは、この項の終わりにある第17.5.5.2項「サポートされている照合ルール」を参照してください。

- matchingRuleは、表17-1に示すように、ロケールに追加された数字接尾辞または文字接尾辞のいずれかとして指定できます。

注意:

ロケールをそのOIDで指定する場合、一致ルールはその数字接尾辞で指定する必要があります。この場合、一致ルールを文字接尾辞で指定することはできません。

表17-1 一致ルール接尾辞

一致ルール

数字接尾辞

文字接尾辞

未満

.1

.lt

以下

.2

.lte

等価

.3

.eq (デフォルト)

以上

.4

.gte

Greater than

.5

.gt

部分文字列

.6

.sub

等価が、デフォルトの一致ルールです。つまり、一致ルール接尾辞が指定されていない場合、照合ルールでは等価一致ルールが使用されます。次の2つの例は同等であり、英語の照合ルールと等価一致ルールを指定しますが、2番目の例では.eq接尾辞で等価一致ルールを明示的に指定しています:

"cn:en:=sanchez"
"cn:en.eq:=sanchez"

次の例では、同じ検索フィルタを示していますが、ロケールの文字接尾辞と一致ルールの数字コードを使用して指定しています:

"cn:en.3:=sanchez"

次の例では、ロケールOIDと一致ルールの数字接尾辞を使用して指定した同じ検索フィルタを示しています:

"cn:1.3.6.1.4.1.42.2.27.9.4.34.1.3:=sanchez"

次の例では、同じ検索フィルタを、スペイン語の照合ルールで指定しています。

"cn:es.eq:=sanchez"
"cn:1.3.6.1.4.1.42.2.27.9.4.49.1.3:=sanchez"
"cn:es.3:=sanchez"

次の例では、スペイン語の照合ルールでgreater-than一致ルールを使用する同じ検索フィルタを指定しています。

"cn:es.gt:=sanchez"
"cn:1.3.6.1.4.1.42.2.27.9.4.49.1.5:=sanchez"
"cn:es.5:=sanchez"

この項には次のトピックが含まれます:

- 第17.5.5.1項「例」

- 第17.5.5.2項「サポートされている照合ルール」

17.5.5.1 例

例17-1 等価検索

次の検索では、en (en-US)ロケールOIDを指定したフィルタを使用し、等価検索を実行して、cn値がsanchezのエントリを返します:

$ ldapsearch -D "cn=directory manager" -j pwd-file -b "o=test" \
"cn:1.3.6.1.4.1.42.2.27.9.4.34.1:=sanchez"

次のフィルタでは、同じ結果が返されます:

- "cn:en:=sanchez"

- "cn:en.3:=sanchez"

- "cn:en.eq:=sanchez"

- "cn:1.3.6.1.4.1.42.2.27.9.4.34.1.3:=sanchez"

例17-2 より小さい検索

次の検索では、es (es-ES)ロケールを指定したフィルタを使用し、より小さい検索を実行して、departmentnumber値がabc119のエントリを返します:

$ ldapsearch -D "cn=directory manager" -j pwd-file -b "o=test" \
"departmentnumber:1.3.6.1.4.1.42.2.27.9.4.49.1.1:=abc120"

次のフィルタでは、同じ結果が返されます:

- "departmentnumber:es.1:=abc120"

- "departmentnumber:es.lt:=abc120"

例17-3 以下検索

次の検索では、es (es-ES)ロケールを指定したフィルタを使用し、departmentnumber値がabc119のエントリを返す、以下検索を実行します:

$ ldapsearch -D "cn=directory manager" -j pwd-file -b "o=test" \
"departmentnumber:1.3.6.1.4.1.42.2.27.9.4.49.1.2:=abc119"

次のフィルタでは、同じ結果が返されます:

- "departmentnumber:es.2:=abc119"

- "departmentnumber:es.lte:=abc119"

例17-4 以上検索

次の検索では、fr (fr-FR)ロケールを指定したフィルタを使用し、departmentnumber値がabc119のエントリを返す、以上検索を実行します。

$ ldapsearch -D "cn=directory manager" -j pwd-file -b "o=test" \
"departmentnumber:fr.4:=abc119"

次のフィルタでは、同じ結果が返されます:

- "departmentnumber:1.3.6.1.4.1.42.2.27.9.4.76.1.4:=abc119"

- "departmentnumber:fr.gte:=abc119"

例17-5 より大きい検索

次の検索では、fr (fr-FR)ロケールを指定したフィルタを使用し、より大きい検索を実行します:

$ ldapsearch -D "cn=directory manager" -j pwd-file -b "o=test" \
"departmentnumber:fr.5:=abc119"

前述の検索では、departmentnumber値がabc119のエントリは返されません。

次のフィルタでは、同じ結果が返されます:

- "departmentnumber:1.3.6.1.4.1.42.2.27.9.4.76.1.5:=abc119"

- "departmentnumber:fr.gt:=abc119"

例17-6 部分文字列検索

次の検索では、en (en-US)ロケールを指定したフィルタを使用し、sn値がQuebecのエントリを返す、部分文字列検索を実行します:

$ ldapsearch -D "cn=directory manager" -j pwd-file -b "o=test" \
"sn:en.6:=*u*bec"

次のフィルタでは、同じ結果が返されます:

- "sn:1.3.6.1.4.1.42.2.27.9.4.34.1.6:=*u*bec"

- "sn:en.sub:=*u*bec"

17.5.5.2 サポートされている照合ルール

次の表は、Oracle Unified Directoryによってサポートされている国際化ロケールを、文字接尾辞のアルファベット順に示しています。

表17-2 サポートされている照合ルール

ロケール

文字接尾辞

OID

アラビア語

ar

1.3.6.1.4.1.42.2.27.9.4.3.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-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

ブルガリア語

bg

1.3.6.1.4.1.42.2.27.9.4.23.1

カタロニア語

ca

1.3.6.1.4.1.42.2.27.9.4.25.1

チェコ語

cs

1.3.6.1.4.1.42.2.27.9.4.26.1

デンマーク語

da

1.3.6.1.4.1.42.2.27.9.4.27.1

ドイツ語

de

1.3.6.1.4.1.142.2.27.9.4.28.1

ドイツ語ドイツ

de-DE

1.3.6.1.4.1.142.2.27.9.4.28.1

ドイツ語オーストリー

de-AT

1.3.6.1.4.1.42.2.27.9.4.29.1

ドイツ語スイス

de-CH

1.3.6.1.4.1.42.2.27.9.4.31.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

英語

en

1.3.6.1.4.1.42.2.27.9.4.34.1

英語アメリカ合衆国

en-US

1.3.6.1.4.1.42.2.27.9.4.34.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

英語イギリス

en-GB

1.3.6.1.4.1.42.2.27.9.4.37.1

英語アイルランド

en-IE

1.3.6.1.4.1.42.2.27.9.4.39.1

英語インド

en-IN

1.3.6.1.4.1.42.2.27.9.4.40.1

英語ニュージーランド

en-NZ

1.3.6.1.4.1.42.2.27.9.4.42.1

英語南アフリカ

en-ZA

1.3.6.1.4.1.42.2.27.9.4.46.1

スペイン語

es

1.3.6.1.4.1.42.2.27.9.4.49.1

スペイン語スペイン

es-ES

1.3.6.1.4.1.42.2.27.9.4.49.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-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

フィンランド語

fi

1.3.6.1.4.1.42.2.27.9.4.74.1

フランス語

fr

1.3.6.1.4.1.42.2.27.9.4.76.1

フランス語

fr-FR

1.3.6.1.4.1.42.2.27.9.4.76.1

フランス語

fr-BE

1.3.6.1.4.1.42.2.27.9.4.77.1

フランス語

fr-CA

1.3.6.1.4.1.42.2.27.9.4.78.1

フランス語

fr-CH

1.3.6.1.4.1.42.2.27.9.4.79.1

フランス語

fr-LU

1.3.6.1.4.1.42.2.27.9.4.80.1

ヘブライ語

he

1.3.6.1.4.1.42.2.27.9.4.85.1

クロアチア語

hr

1.3.6.1.4.1.42.2.27.9.4.87.1

ハンガリー語

hu

1.3.6.1.4.1.42.2.27.9.4.88.1

アイスランド語

is

1.3.6.1.4.1.42.2.27.9.4.91.1

イタリア語

it

1.3.6.1.4.1.42.2.27.9.4.92.1

イタリア語スイス

it-CH

1.3.6.1.4.1.42.2.27.9.4.93.1

日本語

ja

1.3.6.1.4.1.42.2.27.9.4.94.1

韓国語

ko

1.3.6.1.4.1.42.2.27.9.4.97.1

リトアニア語

lt

1.3.6.1.4.1.42.2.27.9.4.100.1

ラトビア語

lv

1.3.6.1.4.1.42.2.27.9.4.101.1

マケドニア語

mk

1.3.6.1.4.1.42.2.27.9.4.102.1

オランダ語

nl

1.3.6.1.4.1.42.2.27.9.4.105.1

オランダ語オランダ

nl-NL

1.3.6.1.4.1.42.2.27.9.4.105.1

オランダ語ベルギー

nl-BE

1.3.6.1.4.1.42.2.27.9.4.106.1

ノルウェー語

no

1.3.6.1.4.1.42.2.27.9.4.107.1

ノルウェー語ノルウェー

no-NO

1.3.6.1.4.1.42.2.27.9.4.107.1

ノルウェー語ニーノシュク

no-NO-NY

1.3.6.1.4.1.42.2.27.9.4.108.1

ポーランド語

pl

1.3.6.1.4.1.42.2.27.9.4.114.1

ポルトガル語

pt

1.3.6.1.4.1.42.2.27.9.4.115.1

ポルトガル語ポルトガル

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

ロシア語

ru

1.3.6.1.4.1.42.2.27.9.4.118.1

ロシア語ロシア

ru-RU

1.3.6.1.4.1.42.2.27.9.4.118.1

スロバキア語

sk

1.3.6.1.4.1.42.2.27.9.4.121.1

スロベニア語

sl

1.3.6.1.4.1.42.2.27.9.4.122.1

アルバニア語

sq

1.3.6.1.4.1.42.2.27.9.4.127.1

セルビア語

sr

1.3.6.1.4.1.42.2.27.9.4.128.1

スウェーデン語

sv

1.3.6.1.4.1.42.2.27.9.4.129.1

スウェーデン語スウェーデン

sv-SE

1.3.6.1.4.1.42.2.27.9.4.129.1

タイ語

th

1.3.6.1.4.1.42.2.27.9.4.136.1

トルコ語

tr

1.3.6.1.4.1.42.2.27.9.4.140.1

ウクライナ語

uk

1.3.6.1.4.1.42.2.27.9.4.141.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

中国語中国

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-TW

1.3.6.1.4.1.42.2.27.9.4.148.1

17.6 ディレクトリ・データの追加、変更および削除

ディレクトリ・サーバーは、ディレクトリ・エントリを管理するためのLDAPv2およびLDAPv3準拠クライアント・ツールの完全なセットを備えています。ldapmodifyおよびldapdeleteユーティリティを使用することで、エントリを追加、更新または削除できます。LDAPコマンドライン・ユーティリティは、コマンドラインから入力またはファイルから読み取られたLDAP Data Interchange Format (LDIF)形式の入力を必要とします。

ディレクトリ・データに変更を行う前に、次の概念を理解していることを確認します:

- 権限およびアクセス制御メカニズム。
権限の設定の詳細は、第22章「データへのアクセス制御」を参照してください。

- ご使用のディレクトリ・サーバーの構造。

- ご使用のディレクトリ・サーバーのスキーマ。

この項には次のトピックが含まれます:

- 第17.6.1項「ディレクトリ・エントリの追加」

- 第17.6.2項「属性の追加」

- 第17.6.3項「ディレクトリ・エントリの変更」

- 第17.6.4項「ディレクトリ・エントリの削除」

17.6.1 ディレクトリ・エントリの追加

ldapmodifyコマンドを使用して1つ以上のエントリをディレクトリ・サーバーに追加できます。ldapmodifyは、ディレクトリ・サーバーへの接続を開き、それにバインドし、コマンドライン・オプションによって指定されたとおりにデータベースに対する変更(この場合は「追加」)を実行します。

ldapmodifyでは、次の2つの方法のいずれかでエントリを追加できます:

- --defaultAddオプションの使用。コマンドラインでデータを入力する場合は、--defaultAddオプションを使用して新しいエントリをディレクトリに追加します。終了したら、[Ctrl] + [D] (UNIX、Linux)または[Ctrl] + [Z] (Windows)を押すか、変更内容が含まれている入力ファイルを使用します。

- LDIF更新文の使用。LDIF更新文は、ldapmodifyによってディレクトリ・エントリをどのように変更するのかを定義します。LDIF更新文には、変更するエントリのDN、特定のエントリをどのように変更するのか(add、delete、modify、modrdn)を定義するchangetype、および一連の属性とそれらの変更された値が含まれています。

注意:

新たに追加されたエントリはすべて、そのディレクトリのスキーマに準拠している必要があります。スキーマに準拠しないエントリを追加すると、サーバーはオブジェクト・クラス違反エラーで応答します。エラーの詳細は、errorsログで表示できます。

この項には次のトピックが含まれます:

- 第17.6.1.1項「ルート・エントリを作成する方法」

- 第17.6.1.2項「ldapmodifyで--defaultAddオプションを使用してエントリを追加する方法」

- 第17.6.1.3項「ldapmodifyでLDIF更新文を使用してエントリを追加する方法」

17.6.1.1 ルート・エントリを作成する方法

ルート・エントリは、ディレクトリの最上位のエントリであり、ネーミング・コンテキストまたはルート接尾辞を含んでいる必要があります。ルート・エントリは、ディレクトリ・サーバーを最初にインストールするときに、グラフィカル・ユーザー・インタフェース(GUI)またはコマンドラインを使用して設定できます。データを含めずにディレクトリをインストールする場合は、--defaultAddオプションを指定してldapmodifyコマンドを使用してルート・エントリを作成します。

1. ldapmodifyを使用してルート・エントリを作成します。

$ ldapmodify --hostname localhost --port 1389 --defaultAdd \
--bindDN "cn=Directory Manager" --bindPassword password
dn: dc=example,dc=com
objectclass: domain
objectclass: top
dc: example
(Press Ctrl-D on Unix, Linux)
(Press Ctrl-Z on Windows), then press ENTER.

Processing ADD request for dc=example,dc=com
ADD operation successful for DN dc=example,dc=com

注意:

--bindDNおよび--bindPasswordオプションにより、新しいエントリを追加する権限を持つユーザーのバインドDNとパスワードをそれぞれ指定します。クリアテキスト・バージョンのパスワードを指定できます。サーバーではこの値を暗号化し、暗号化されたもののみを保存します。LDIFファイルに表示されるクリアテキストのパスワードを保護するため、読取り権限を制限してください。このセキュリティの問題を回避するには、SSLまたはstartTLSを使用してください。

2. ldapsearchコマンドを使用して変更内容を検証します。

$ ldapsearch --hostname localhost --port 1389 --baseDN "dc=example,dc=com" \
--searchScope base --bindDN "cn=Directory Manager" --bindPassword password \
"(objectclass=*)"
dn: dc=example,dc=com
objectClass: domain
objectClass: top
dc: example

17.6.1.2 ldapmodifyで--defaultAddオプションを使用してエントリを追加する方法

1. LDIF形式でディレクトリ・エントリを作成します。
エントリを追加する前に、エントリの追加先の接尾辞がデータベース内に存在していることを確認します(たとえば、ou=People,dc=example,dc=com)。

この例では、次の内容を持つnew.ldifという入力ファイルを作成します:

dn: uid=Marcia Garza,ou=People,dc=example,dc=com
cn: Marcia Garza
sn: Garza
givenName: Marcia
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
ou: Accounting
ou: People
l: Santa Clara
uid: mgarza
mail: mgarza@example.com
roomnumber: 5484
userpassword: donuts

2. --defaultAddオプションを指定してldapmodifyを使用してエントリを追加します。

$ ldapmodify --hostname localhost --port 1389 --bindDN "cn=Directory Manager" \
--bindPassword password --defaultAdd --filename /tmp/new.ldif

17.6.1.3 ldapmodifyでLDIF更新文を使用してエントリを追加する方法

1. changetype:add要素を指定してLDIF形式でエントリを作成します。
addの後に空白がないことを確認してください。addの後に空白があると、BASE64エンコーディングではその値は空白を表し、それによって問題が発生することがあります。

この例では、new.ldifという名前の入力LDIFファイルを作成します。

dn: uid=Marcia Garza,ou=People,dc=example,dc=com
changetype: add
cn: Marcia Garza
sn: Garza
givenName: Marcia
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
ou: Accounting
ou: People
l: Santa Clara
uid: mgarza
mail: mgarza@example.com
roomnumber: 5484
userpassword: donuts

2. ldapmodifyを使用してエントリを追加します。
changetype属性によってアクションが指定されるため、-aオプションを含めないでください。

$ ldapmodify --hostname localhost --port 1389 --bindDN "cn=Directory Manager" \
--bindPassword password --filename /tmp/new.ldif

Processing ADD request for uid=Marcia Garza,ou=People,dc=example,dc=com
ADD operation successful for DN uid=Marcia Garza,ou=People,dc=example,dc=com

17.6.2 属性の追加

LDIF changetype:add文は、エントリをディレクトリに追加します。エントリに属性を追加するには、次の例に示すようにchangetype:modify文を使用します。各コマンドをダッシュ(-)で区切ることで、1つのファイル内の複数のコマンドを結合できます。

この項では、エントリの管理方法を説明しており、内容は次のとおりです:

- 第17.6.2.1項「エントリに属性を追加する方法」

- 第17.6.2.2項「ACI属性を追加する方法」

- 第17.6.2.3項「国際化属性を追加する方法」

17.6.2.1 エントリに属性を追加する方法

1. changetype:modify要素を指定してLDIF形式でエントリを作成します。
既存のエントリを新しい属性を追加して変更しようとしているので、modify変更タイプを使用します。modifyの後に空白がないことを確認してください。changetypeの後に、add: newAttributeNameを指定し、次の行に新しい属性の値を指定します。

この例では、次のようにadd_attribute.ldifという入力LDIFファイルを作成します:

dn: uid=Marcia Garza,ou=People,dc=example,dc=com
changetype: modify
add: telephonenumber
telephonenumber: +1 408 555 8283

注意:

複数の属性を追加するには、属性をダッシュ(-)で区切ります。例:

dn: uid=Marcia Garza,ou=People,dc=example,dc=com
changetype: modify
add: telephonenumber
telephonenumber: +1 408 555 8283
-
add: building
building: sc09

2. ldapmodifyを使用して属性を追加します。

$ ldapmodify --hostname localhost --port 1389 --bindDN "cn=Directory Manager" \
--bindPassword password --filename /tmp/add_attribute.ldif

Processing MODIFY request for uid=Marcia Garza,ou=People,dc=example,dc=com
MODIFY operation successful for DN uid=Marcia Garza,ou=People,dc=example,dc=com

17.6.2.2 ACI属性を追加する方法

ldapmodifyを使用して、アクセス制御命令(ACI)を追加し、ユーザーのアカウントのアクセス権を管理できます。詳細は、第22章「データへのアクセス制御」およびACI構文を参照してください。

次の例では、ユーザーに自身のディレクトリ属性の変更を許可します。

1. ACIが含まれているLDIFファイルを作成します。

dn: uid=Marcia Garza,ou=People,dc=example,dc=com
changetype: modify
add: aci
aci: (target="ldap:///uid=Marcia Garza,ou=People,dc=example,dc=com")
(targetattr="*")(version 3.0; acl "mgarza rights"; allow (write)
userdn="ldap:///self";)

2. ldapmodifyを使用して属性を追加します。

$ ldapmodify --hostname localhost --port 1389 --bindDN "cn=Directory Manager" \
--bindPassword password --filename /tmp/add_aci.ldif

Processing MODIFY request for uid=Marcia Garza,ou=People,dc=example,dc=com
MODIFY operation successful for DN uid=Marcia Garza,ou=People,dc=example,dc=com

17.6.2.3 国際化属性を追加する方法

ディレクトリ・サーバーでは、attribute;language-subtype形式の言語タグを使用して国際化ロケールを表します。たとえば、homePostalAddress;lang-jp:addressは、日本のロケール(subtype=jp)では住所を指定します。

ldapmodifyを使用して属性を追加します。

言語サブタイプlang-ccを追加します。ccは国コードです。

$ ldapmodify --hostname localhost --port 1389 --bindDN "cn=Directory Manager" \
--bindPassword password
dn: uid=jarrow,ou=People,dc=example,dc=com
changetype: modify
add: homePostalAddress;lang-jp
homePostalAddress;lang-jp: 1-8-15 Azuchimachi, Chuo-ku
(Press Ctrl-D on Unix, Linux)
(Press Ctrl-Z on Windows), then press ENTER.

注意:

属性値にASCII以外の文字がある場合、UTF-8エンコードする必要があります。

17.6.3 ディレクトリ・エントリの変更

LDIF更新文changetype:modifyを使用して、既存のディレクトリ・データに変更を行います。次の手順は、ディレクトリ・エントリを変更する例を示し、内容は次のとおりです:

- 第17.6.3.1項「属性値を変更する方法」

- 第17.6.3.2項「前後のスナップショットで属性を変更する方法」

- 第17.6.3.3項「属性を削除する方法」

- 第17.6.3.4項「RDNを変更する方法」

- 第17.6.3.5項「エントリを移動する方法」

詳細は、付録A「ldapmodify」を参照してください。

17.6.3.1 属性値を変更する方法

ldapmodifyを使用し、changetype:modifyおよびreplace要素を使用してエントリを変更します。

modifyの後に空白がないことを確認してください。

この例では、ユーザーの既存の電話番号を変更します。

$ ldapmodify -h localhost -p 1389 D "cn=Directory Manager" -j pwd-file \
dn: uid=Marcia Garza,ou=People,dc=example,dc=com
changetype: modify
replace: telephonenumber
telephonenumber: +1 408 555 8288

Processing MODIFY request for uid=Marcia Garza,ou=People,dc=example,dc=com
MODIFY operation successful for DN uid=Marcia Garza,ou=People,dc=example,dc=com

複数の属性を変更するには、属性をダッシュ(-)で区切ります。例:

dn: uid=Marcia Garza,ou=People,dc=example,dc=com
changetype: modify
replace: telephonenumber
telephonenumber: +1 408 555 6465
-
add: facsimiletelephonenumber
facsimiletelephonenumber: +1 408 222 4444
-
replace: l
l: Sunnyvale

17.6.3.2 前後のスナップショットで属性を変更する方法

ldapmodifyコマンドには、--preReadAttributeと--postReadAttributeのオプションがあり、それらはそれぞれ、前および後のスナップショットで変更された属性を返します。

--preReadAttributeおよび--postReadAttributeオプションを指定してldapmodifyを使用します。

この例では、ユーザーの既存の電話番号を変更します。

$ ldapmodify -h localhost -p 1389 D "cn=Directory Manager" -j pwd-file \
--preReadAttributes telephoneNumber --postReadAttributes telephoneNumber
dn: uid=Marcia Garza,ou=People,dc=example,dc=com
changetype: modify
replace: telephonenumber
telephonenumber: +1 408 555 8288

Processing MODIFY request for uid=Marcia Garza,ou=People,dc=example,dc=com
MODIFY operation successful for DN uid=Marcia Garza,ou=People,dc=example,dc=com

Target entry before the operation:
dn: uid=Marcia Garza,ou=People,dc=example,dc=com
telephonenumber: +1 408 555 4283

Target entry after the operation:
dn: uid=Marcia Garza,ou=People,dc=example,dc=com
telephonenumber: +1 408 555 8288

17.6.3.3 属性を削除する方法

この例では、エントリから位置(l)属性を削除します。

ldapmodifyを使用して属性を削除します。

$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file
dn: uid=Marcia Garza,ou=People,dc=example,dc=com
changetype: modify
delete: l
(Press CTRL-D for Unix, Linux) (Press CTRL-Z for Windows), then press ENTER.

Processing MODIFY request for uid=Marcia Garza,ou=People,dc=example,dc=com
MODIFY operation successful for DN uid=Marcia Garza,ou=People,dc=example,dc=com

[Ctrl] + [D] (UNIX、Linux)または[Ctrl] + [Z] (Windows)を押して入力を完了します。

17.6.3.4 RDNを変更する方法

エントリの識別名(DN)によって、エントリが一意に識別され、そのエントリが記述されます。識別名は、そのエントリ自体の名前と、ディレクトリ内でそれの上にあるオブジェクトの名前(下から上の順序)で構成されています。

相対識別名(RDN)は、エントリDNの左端の要素です。たとえば、uid=Marcia Garza,ou=People,dc=example,dc=comのRDNは、uid=Marcia Garzaです。RDNを変更するには、changetype:moddn LDIF更新文を使用します。

deleteoldrdn属性を使用することでディレクトリ内に古いRDNを保持するかどうかを指定できます。0のdeleteoldrdn値は、既存のRDNをディレクトリ内に保持することを示します。1の値は、既存のRDNを新しいRDNで置き換えることを示します。

1. ldapmodifyコマンドを使用して、エントリの名前を変更します。
この例では、従業員Marcia Garzaは、彼女の結婚後の名前であるMarcia Petersに変更したいと考えています。

$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file
dn: uid=Marcia Garza,ou=Marketing,dc=example,dc=com
changetype: moddn
newrdn: uid=Marcia Peters
deleteoldrdn: 1
Processing MODIFY DN request for uid=Marcia Garza,ou=People,dc=example,dc=com
MODIFY DN operation successful for DN uid=Marcia Garza,ou=People,dc=example,dc=com

2. 必要に応じて、他の属性を変更します。
この例では、特定の属性に、ユーザーの前の名前が依然としてリストされている可能性があります。

$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file
dn: uid=Marcia Peters,ou=People,dc=example,dc=com
changetype: modify
replace: sn
sn: Peters
-
replace: cn
cn: Marcia Peters
-
replace: uid
uid: mpeters
uid: Marcia Peters
-
replace: mail
mail: mpeters@example.com
(Press Ctrl-D on Unix, Linux)
(Press Ctrl-Z on Windows), then press ENTER.

Processing MODIFY request for uid=Marcia Peters,ou=People,dc=example,dc=com
MODIFY operation successful for DN uid=Marcia Peters,ou=People,dc=example,dc=com

17.6.3.5 エントリを移動する方法

1つの親から別の親にエントリを移動する場合、その親エントリのアクセス制御命令(ACI) 権限を拡張します。エントリの移動元の親エントリ上で、構文allow(export...)を使用することで、ACIでエクスポート操作が許可されるようにします。エントリの移動先の親エントリ上で、構文allow(import...)を使用することで、ACIでインポート操作が許可されるようにします。

この例では、uid=sgarzaをou=Contractors,dc=example,dc=com接尾辞からou=People,dc=example,dc=comサブツリーに移動します。

1. moddn変更タイプを指定してldapmodifyを使用し、エントリを移動します。

$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file
dn: uid=sgarza,ou=Contractors,dc=example,dc=com
changetype: moddn
newrdn: uid=sgarza
deleteoldrdn: 0
newsuperior: ou=People,dc=example,dc=com
--filename move_entry.ldif
Processing MODIFY DN request for uid=sgarza,ou=Contractors,dc=example,dc=com
MODIFY DN operation successful for DN uid=sgarza,ou=Contractors,dc=example,dc=com

2. 必要に応じて、他の属性値を変更します。
次の例では、ou属性の前後のスナップショットの変更を示します。

$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
--preReadAttributes ou --postReadAttributes ou
dn: uid=sgarza,ou=People,dc=example,dc=com
changetype: modify
replace: ou
ou: People
ou: Product Testing
(Press Ctrl-D on Unix, Linux)
(Press Ctrl-Z on Windows), then press ENTER.

Processing MODIFY request for uid=sgarza,ou=People,dc=example,dc=com
MODIFY operation successful for DN uid=sgarza,ou=People,dc=example,dc=com

Target entry before the operation:
dn: uid=sgarza,ou=People,dc=example,dc=com
ou: Contractors
ou: Product Testing

Target entry after the operation:
dn: uid=sgarza,ou=People,dc=example,dc=com
ou: People
ou: Product Testing

17.6.4 ディレクトリ・エントリの削除

ldapmodifyおよびldapdeleteを使用して、ディレクトリからエントリを削除できます。ldapmodifyコマンドは、delete属性とともに、LDIF更新文changetype:deleteを使用してエントリを、changetype:modifyを使用して属性を削除します。ldapdeleteツールでは、エントリのみが削除されます。

注意:

子エントリを持つエントリは削除できません。子を持つエントリを削除する場合、最初にターゲット・エントリの下にあるすべての子エントリを削除してから、そのエントリを削除します。

詳細は、付録A「ldapdelete」を参照してください。

この項では、ディレクトリ・エントリの削除方法を説明しており、内容は次のとおりです:

- 第17.6.4.1項「ldapmodifyでエントリを削除する方法」

- 第17.6.4.2項「ldapdeleteでエントリを削除する方法」

- 第17.6.4.3項「DNファイルを使用して複数のエントリを削除する方法」

17.6.4.1 ldapmodifyでエントリを削除する方法

changetype:delete文を指定して、ldapmodifyコマンドを使用します。

$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file
dn: uid=Marcia Garza,ou=People,dc=example,dc=com
changetype: delete
(Press CTRL-D for Unix)
(Press CTRL-Z for Windows), then press ENTER.

Processing DELETE request for uid=Marcia Garza,ou=People,dc=example,dc=com
DELETE operation successful for DN uid=Marcia Garza,ou=People,dc=example,dc=com
The number of entries deleted was 1

17.6.4.2 ldapdeleteでエントリを削除する方法

ldapdeleteコマンドを使用して、削除するエントリを変更します。

$ ldapdelete -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file
"uid=mgarza,ou=People,dc=example,dc=com"

Processing DELETE request for uid=Marcia Garza,ou=People,dc=example,dc=com
DELETE operation successful for DN uid=Marcia Garza,ou=People,dc=example,dc=com

17.6.4.3 DNファイルを使用して複数のエントリを削除する方法

1. 削除するDNのリストが含まれているファイルを作成します。
この例では、ファイルはdelete.ldifという名前です。ファイルには、各DNが個別の行にリストされます。次の例:

uid=mgarza,ou=People,dc=example,dc=com
uid=wsmith,ou=People,dc=example,dc=com
uid=jarrow,ou=People,dc=example,dc=com
uid=mbean,ou=People,dc=example,dc=com

2. ldapdeleteコマンドに引数としてファイルを渡すことで、エントリを削除します。

$ ldapdelete -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
--continueOnError --filename delete.ldif

Processing DELETE request for uid=mgarza,ou=People,dc=example,dc=com
DELETE operation successful for DN uid=mgarza,ou=People,dc=example,dc=com
Processing DELETE request for uid=wsmith,ou=People,dc=example,dc=com
DELETE operation successful for DN uid=wsmith,ou=People,dc=example,dc=com
Processing DELETE request for uid=jarrow,ou=People,dc=example,dc=com
DELETE operation successful for DN uid=jarrow,ou=People,dc=example,dc=com
Processing DELETE request for uid=mbean,ou=People,dc=example,dc=com
DELETE operation successful for DN uid=mbean,ou=People,dc=example,dc=com

注意:

--continueOnErrorオプションは、エラーが発生した場合にコマンドが次の検索アイテムで続行されることを指定します。

17.7 ディレクトリ・データへの索引付け

この項では、dsconfigコマンドライン・ツールを使用して属性に索引付けする方法を説明します。索引は、サーバーごとに構成され、索引構成はレプリケートされません。

dsconfigを使用して、ローカル・データベース索引および仮想リスト表示(VLV)索引を作成します。ローカル・データベース索引は、検索基準に一致するエントリを見つけるために使用されます。VLV索引は、VLV制御で効率的に検索を処理するために使用されます。

ユーザーにunindexed-search権限がある場合以外は、索引付けされていない検索はデフォルトで拒否されます。詳細は、第23.3.5項「ルート・ユーザーの特権を変更するには」を参照してください。

次の2つの方法で、検索が索引付けされているかどうかを判別できます:

- 匿名で検索の実行を試みます。(サーバーは、デフォルトで、索引付けされていない匿名検索を拒否します。)

- debugsearchindex操作属性を使用します。この属性は、検索で使用される索引、各索引からの候補エントリの数、最終的な索引付けされたステータスを提供します。次のように、ldapsearchコマンドにdebugsearchindex属性を含めます:

$ ldapsearch -h localhost -p 1389 -b "dc=example,dc=com" "(objectClass=*)" debugsearchindex

この項では、データの索引付け方法を説明しており、内容は次のとおりです:

- 第17.7.1項「ローカルDBバックエンドでの索引の構成」

- 第17.7.2項「VLV索引の構成」

17.7.1 ローカルDBバックエンドでの索引の構成

ローカルDBバックエンドでは、次の索引タイプがサポートされています:

- approximate: 近似検索フィルタを使用する検索の効率を高めます。

- equality: 等価検索フィルタを使用する検索の効率を高めます。

- ordering: 以上または以下の検索フィルタを使用する検索の効率を高めます。今後、この索引タイプは、サーバー側ソートにも使用される可能性があります。

- presence: プレゼンス検索フィルタを使用する検索の効率を高めます。

- substring: 部分文字列検索フィルタを使用する検索の効率を高めます。

ディレクトリ・サーバーでは、照合一致ルール、相対時間の一致ルール、部分的な日付や時刻の一致ルールなど拡張可能一致操作のサブセットに対してのみ索引付けがサポートされています。詳細は、第17.5.5項「国際化されたエントリの検索」、第9.1.3項「相対時間の一致ルール」および第9.1.4項「部分的な日付や時間の一致ルール」を参照してください。

dsconfigで新しいローカルDBバックエンドを作成すると、次のデフォルト索引が自動的に作成されます:

- aci (プレゼンス索引)

- ds-sync-hist (順序付け索引)

- entryuuid (等価索引)

- objectclass (等価索引)

この項には次のトピックが含まれます:

- 第17.7.1.1項「新規ローカルDB索引を作成する方法」

- 第17.7.2.1項「新規VLV索引を作成する方法」

17.7.1.1 新規ローカルDB索引を作成する方法

これは、新規ローカルDB索引を作成する手順を示しています。

注意:

新しい索引を作成した後、rebuild-indexユーティリティを使用して索引を再構築する必要があります。ディレクトリ・サーバーは、索引が再構築されるまで新しい索引を使用できません。詳細は、付録A「rebuild-index」を参照してください。

1. 新しい索引を作成します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
create-local-db-index \
--element-name backend --index-name attribute \
--set index-type:index-type

2. ローカルDB索引をそのバックエンドに対してリストすることで索引が作成されたことを確認します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
list-local-db-indexes \
--element-name backend

3. 具体的な索引プロパティを構成します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
set-local-db-index-prop \
--element-name backend --index-name attribute \
--set property:value

4. 索引プロパティをリストして変更を検証します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
get-local-db-index-prop \
--element-name backend --index-name attribute

5. 索引を再構築します。

1. サーバーを停止し、索引を再構築して、サーバーを再起動します。

$ stop-ds
$ rebuild-index --baseDN baseDN --index attribute
$ start-ds

2. または、タスクとしてrebuild-indexコマンドを実行することで、オンラインで索引を再構築します。

$ rebuild-index -h localhost -p 4444 -D "cn=Directory manager" -j pwd-file \
-X -n --baseDN dc=example,dc=com --index aci
Rebuild Index task 20110201162742312 scheduled to start immediately
...
Rebuild Index task 20110201162742312 has been successfully completed

オンラインの再索引付け操作の場合でも、再索引付け中はバックエンドが使用できないことに注意してください。レプリケートされたトポロジでは、全体的なサービスは、依然としてreferral on update機能を通して使用可能です。詳細は、第17.13.1項「レプリケートされたトポロジでのリフェラル」を参照してください。

例17-7 新しい等価索引の作成

この例では、employeeNumber属性の新しい等価索引を作成し、索引プロパティを検証し、索引エントリの制限を5000に制限します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
create-local-db-index \
--element-name userRoot --index-name employeeNumber \
--set index-type:equality

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
list-local-db-indexes \
--element-name userRoot
Local DB Index : Type    : index-type
---------------:---------:-----------
...
employeeNumber : generic : equality
...
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
get-local-db-index-prop \
--element-name userRoot --index-name employeeNumber
Property                       : Value(s)
-------------------------------:---------------
attribute                      : employeenumber
index-entry-limit              : 4000
index-extensible-matching-rule : -
index-type                     : equality
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
set-local-db-index-prop \
--element-name userRoot --index-name employeeNumber --set index-entry-limit:5000
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
get-local-db-index-prop \
--element-name userRoot --index-name employeeNumber
Property                       : Value(s)
-------------------------------:---------------
attribute                      : employeenumber
index-entry-limit              : 5000
index-extensible-matching-rule : -
index-type                     : equality
$ rebuild-index -h localhost -p 4444 -D "cn=Directory manager" -j pwd-file -X \
--baseDN dc=example,dc=com --index employeeNumber

例17-8 部分文字列索引の追加

この例では、前の例で作成した索引に部分文字列索引を追加します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
set-local-db-index-prop \
--'
p userRoot --index-name employeeNumber \
--add index-type:substring
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
get-local-db-index-prop \
--element-name userRoot --index-name employeeNumber
Property                       : Value(s)
-------------------------------:---------------
attribute                      : employeenumber
index-entry-limit              : 5000
index-extensible-matching-rule : -
index-type                     : equality, substring
$ rebuild-index -h localhost -p 4444 -D "cn=Directory manager" -j pwd-file -X \
--baseDN dc=example,dc=com --index employeeNumbe

17.7.2 VLV索引の構成

VLV索引は、指定されたベース・エントリおよびそのサブツリーに対する特定の検索に適用されます。索引を作成するときは、ソート順序、索引の範囲、ベースDNおよびフィルタを定義する必要があります。

新しいVLV索引を作成した後、rebuild-indexコマンドを使用して索引を再構築し、索引名の前にvlv.を追加する必要があります。ディレクトリ・サーバーは、索引が再構築されるまで新しい索引を使用できません。詳細は、付録A「rebuild-index」を参照してください。

VLVリクエスト制御へのアクセスは、デフォルトで、認証されたユーザーにのみ許可されることに注意してください。認証されていないユーザーが検索リクエストでVLV制御を使用できるようにする場合は、対応するグローバルACIを変更する必要があります。詳細は、第17.5.3.16.4項「仮想リスト表示制御への匿名アクセスの許可」を参照してください。

17.7.2.1 新規VLV索引を作成する方法

1. 次のように、dsconfigを使用して新しいVLV索引を作成します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
create-local-db-vlv-index \
--element-name backend --index-name name --set sort-order:attributes \
--set scope:scope --set base-dn:baseDN --set filter:filter

ここで:

- index-nameは一意の索引名を指定し、VLV索引を作成した後に変更できません。

- sort-orderは、エントリをソートする基準となる属性の名前およびそれらの優先順位を高いほうから順に指定します。

- scopeは、索引付けされる問合せのLDAP範囲を指定し、base-object、single-level、subordinate-subtreeまたはwhole-subtreeの1つにすることができます。

- base-dnは、索引付けされる検索問合せで使用されるベースDNを指定します。

- filterは、索引付けされる問合せに使用されるLDAPフィルタを指定し、任意の有効なLDAPフィルタにすることができます。

2. 既存のVLV索引をリストすることで索引が作成されたことを確認します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
list-local-db-vlv-indexes \
--element-name backend

3. 索引プロパティを表示して変更を検証します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
get-local-db-vlv-index-prop \
--element-name backend --index-name name

4. 索引を再構築します。

1. サーバーを停止し、索引を再構築して、サーバーを再起動します。

$ stop-ds
$ rebuild-index --baseDN baseDN --index vlv.name
$ start-ds

2. または、タスクとしてrebuild-indexコマンドを実行することで、オンラインで索引を再構築します。

$ rebuild-index -h localhost -p 4444 -D "cn=Directory manager" -j pwd-file -X \
--baseDN baseDN --index vlv.name

例17-9 新しいVLV索引の作成

次の例では、新しいVLV索引を作成し、問合せsn=*に対して、最初に姓で、次に共通名でエントリをソートします。この例では、その後、索引をオンラインで再構築します。

$ dsconfig -D "cn=directory manager" -j pwd-file -n create-local-db-vlv-index \
--element-name userRoot --index-name myVLVIndex --set sort-order:"sn cn" \
--set scope:base-object --set base-dn:dc=example,dc=com --set filter:sn=*
$ rebuild-index -h localhost -p 4444 -D "cn=Directory manager" -j pwd-file -X \
-b "dc=example,dc=com" --index vlv.myVLVIndex

17.8 格納されるデータ・サイズの削減

ディレクトリ・サーバーは、格納されるデータのサイズを減らすための2つのメカニズムを備えています:

- 圧縮エンコーディング。圧縮エンコーディングが有効化されている場合、バックエンドではエントリをエンコードするときに属性の説明とオブジェクト・クラス・セットを圧縮することで、圧縮形式が使用されます。このプロパティは、エントリ自体にのみ適用され、索引データには影響を与えません。圧縮エンコーディングは、デフォルトで有効化されていますが、必要に応じて無効化できます。ご使用のデプロイメントで、オブジェクト・クラスおよび属性タイプ名でユーザーによる先頭文字の大文字化が必要とされている場合、ユーザーによる先頭文字の大文字化は圧縮されたエントリでは保持されないため、圧縮エンコーディングを無効化できます。ただし、圧縮は、パフォーマンスを向上させるため、パフォーマンスのためにはユーザーによる先頭文字の大文字化を無視できるか、それが不要なデプロイメントでは利点があります。

- エントリの圧縮。エントリの圧縮では、デフレータを使用して、データを格納する前に圧縮します。エントリの圧縮を有効化すると、エントリをデータベースに格納する前にバックエンドによってそれらの圧縮が試みられます。このプロパティも、エントリ自体にのみ適用され、索引データには影響を与えません。エントリの圧縮の有効性は、エントリに含まれているデータ型に基づきます。

これらのメカニズムの1つまたは両方を有効化して、格納されるデータのサイズを減らすことができます。これらのメカニズムを有効化すると、今後の書込みにのみ作用するため、データベースには、圧縮されたデータと圧縮されていないレコードが混在することがあります。圧縮の設定に関係なく、どちらのタイプのレコードも読取り可能です。

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

- 第17.8.1項「圧縮エンコーディングを有効化または無効化する方法」

- 第17.8.2項「エントリの圧縮を有効化または無効化する方法」

17.8.1 圧縮エンコーディングを有効化または無効化する方法

圧縮エンコーディングは、ローカル・バックエンド・ワークフロー要素のcompact-encodingプロパティを設定することで構成されます。この設定に対する変更は、変更がお粉綿後に発生する書込みにのみ有効になります。既存のデータがさかのぼって変更されることはありません。

userRootワークフロー要素に対しては圧縮エンコーディングを無効化します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
set-workflow-element-prop --element-name="userRoot" --set compact-encoding:false

17.8.2 エントリの圧縮を有効化または無効化する方法

エントリの圧縮は、ローカル・バックエンド・ワークフロー要素のentries-compressedプロパティを設定することで構成されます。この設定に対する変更は、変更がお粉綿後に発生する書込みにのみ有効になります。既存のデータがさかのぼって変更されることはありません。

userRootワークフローに対してはエントリの圧縮を有効化します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
set-workflow-element-prop --element-name="userRoot" \
--set entries-compressed:true

17.9 属性値の一意性の確認

ディレクトリの構造では、識別名によって、ディレクトリ情報ツリー内のオブジェクトおよびその場所が一意に識別される必要があります。ディレクトリ・サーバーは、一意属性プラグインを備えており、それによって、属性がディレクトリ内で追加、変更または移動された場合に、属性値の一意性が確保されます。

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

- 第17.9.1項「一意な属性プラグインの概要」

- 第17.9.2項「dsconfigを使用した一意な属性プラグインの構成」

- 第17.9.3項「レプリケーションと一意な属性プラグイン」

17.9.1 一意な属性プラグインの概要

一意属性プラグインは、デフォルトで無効化されています。このプラグインは、dsconfigコマンドを使用することで有効化でき、それによってチェックされる接尾辞および属性を定義できます。このプラグインは、有効化されている場合、操作によってデータベースが更新される前に、LDAP追加、変更またはDN変更操作によって、2つのエントリが同じ属性を持つようになるかどうかを識別します。サーバーによって競合が認識された場合、操作は終了され、LDAP_CONSTRAINT_VIOLATIONエラーがクライアントに返されます。

既存のディレクトリで属性値の一意性を有効にしても、サーバーは既存のエントリ間での一意性をチェックしません。プラグインが有効化された後は、エントリが追加、変更または移動されるときに一意性が強制されます。

一意属性プラグインを構成すると、ディレクトリ内の1つ以上のサブツリー内または特定のオブジェクト・クラスのエントリ間に一意性を強制できます。他の属性の一意性を確保する場合、一意属性プラグインのインスタンスをいくつか定義できます。通常、値を一意にする属性ごとに、1つのプラグイン・インスタンスを定義します。同じ属性に複数のプラグイン・インスタンスを用意することで、複数のエントリ・セットでその属性の一意性を個別に確保できます。

一意属性プラグインはデフォルトでは無効化されており、マルチマスターのレプリケーション構成が影響を受けることはありません。プラグインが有効化されていると、スタンドアロン・システムの場合は追加、変更またはDN変更操作の前にuid属性が一意であることが確認され、レプリケートされた環境では同期の後に一意性がチェックされます。

一意属性プラグインは、他のプラグインと同様に、dsconfigコマンドを使用して構成されます。詳細は、第14.1.9項「dsconfigを使用したプラグインの構成」を参照してください。プラグインを構成する最も簡単な方法は、対話モードでdsconfigを使用することです。対話モードは、ウィザードのように機能し、プラグイン構成を手順を追ってガイドします。対話モードは説明不要であるため、この項の例では、対話モードを例示せず、同等の完全なdsconfigコマンドについて説明します。

17.9.2 dsconfigを使用した一意な属性プラグインの構成

次の手順では、属性値の一意性を構成する方法について説明します。

17.9.2.1 uid属性の値の一意性を確保する方法

デフォルトでは、一意属性プラグインはuid属性をチェックします。次のタスクによって、一意属性プラグインが有効化され、ベースDN(その下のuid属性の属性値の一意性がチェックされる)が設定されます。

1. サーバーで現在定義されているプラグインを表示します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
list-plugins

インストールに応じて、出力は次のものに類似したものになります。

Plugin                          : Type                            : enabled
--------------------------------:---------------------------------:--------
7-Bit Clean                     : seven-bit-clean                 : false
Change Number Control           : change-number-control           : true
Entry UUID                      : entry-uuid                      : true
LastMod                         : last-mod                        : true
LDAP Attribute Description List : ldap-attribute-description-list : true
Password Policy Import          : password-policy-import          : true
Profiler                        : profiler                        : true
Referential Integrity           : referential-integrity           : false
UID Unique Attribute            : unique-attribute                : false

2. 一意属性プラグインに対して構成されているプロパティを表示します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
get-plugin-prop \
--plugin-name "UID Unique Attribute" \
Property : Value(s)
---------:---------
base-dn  : -
enabled  : false
type     : uid

3. 一意属性プラグインを有効化します。

$ dsconfig --advanced -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
set-plugin-prop \
--plugin-name "UID Unique Attribute" --set enabled:true

注意:

--advancedサブコマンドを指定して、dsconfigコマンドを必ず実行してください。このサブコマンドにより、postaddoperation、postmodifyoperationおよびpostmodifydnoperationなどの選択可能な拡張プラグインを表示するように表示出力が変更されます。デフォルト値は、preaddoperation、premodifyoperationおよびpostmodifyoperationなどの操作前プラグインです。操作後プラグインと一致する操作前プラグインを選択する必要があります。

4. ベースDN(それより下で一意性がチェックされる)を設定します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
set-plugin-prop \
--plugin-name "UID Unique Attribute" --set base-dn:ou=People,dc=example,dc=com

17.9.2.2 他の属性の値の一意性を確保する方法

デフォルトでは、一意属性プラグインはuid属性をチェックします。別の属性の一意性を確認する場合は、一意属性プラグインの新しいインスタンスを作成し、そのtypeプロパティを設定します。

この例では、一意属性プラグインの新しいインスタンスを作成し、mail属性の一意性を確認します。

1. 一意属性プラグインの新しいインスタンスを作成し、有効化します。
typeプロパティを、一意である必要がある属性の名前(この場合はmail)に設定します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
create-plugin \
--type unique-attribute --plugin-name "MAIL unique attribute"
--set enabled:true --set type:mail

2. 新しい一意属性プラグインを有効化します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
set-plugin-prop \
--plugin-name "MAIL Unique Attribute" --set enabled:true

3. ベースDN(それより下で一意性がチェックされる)を設定します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
set-plugin-prop \
--plugin-name "MAIL Unique Attribute" --set base-dn:ou=People,dc=example,dc=com

4. 値を一意にする必要がある属性を指定します。
この例では、mail属性を指定します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
set-plugin-prop \
--plugin-name "MAIL Unique Attribute" --set type:mail

1つ以上の属性の値が一意であることを確認するには、一意属性プラグインの複数のインスタンスを作成し、有効化します。

17.9.3 レプリケーションと一意な属性プラグイン

レプリケーション操作の一環として更新が実行される際は、一意属性プラグインによる属性の一意性チェックは行われません。レプリケーション環境で属性値の一意性を確認するには、トポロジ内のすべてのサーバーの同じサブツリーの同じ属性に対して一意属性プラグインを有効化します。

17.10 仮想属性の構成

仮想属性とは、永続ストレージに存在しないがいずれかの方法で動的に生成される値を持つ属性です。

Oracle Unified Directoryでは次の仮想属性タイプをサポートしています:

- collective attribute subentries

- entryDN

- entryUUID

- governingStructureRule

- hasSubordinates

- isMemberOf

- member

- nsuniqueid

- numSubordinates

- orclguid

- Password Policy Subentry

- Proximity

- structuralObjectClass

- subschemaSubentry

- ユーザー定義仮想属性

仮想属性は、dsconfigコマンドを使用して構成されます。dsconfigコマンドは、第14.3項「サーバーへの管理トラフィックの管理」を使用してSSL経由でプラグイン構成にアクセスします。仮想属性を構成する最も簡単な方法は、対話モードでdsconfigを使用することです。対話モードは、ウィザードのように機能し、仮想属性構成を手順を追ってガイドします。対話モードは説明不要であるため、この項の例では、対話モードを例示せず、同等の完全なdsconfigコマンドについて説明します。

dsconfigの使用の詳細は、第14.1項「dsconfigを使用したサーバー構成の管理」を参照してください。

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

- 第17.10.1項「既存の仮想属性をリストする方法」

- 第17.10.2項「新規仮想属性を作成する方法」

- 第17.10.3項「仮想属性を有効化または無効化する方法」

- 第17.10.4項「仮想属性の構成を表示する方法」

- 第17.10.5項「仮想属性の構成を変更する方法」

17.10.1 既存の仮想属性をリストする方法

ディレクトリ・サーバーは、デフォルトでいくつかの仮想属性ルールを提供します。この例では、構成されている仮想属性ルールをすべてリストします。

dsconfigコマンドを次のように実行します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n list-virtual-attributes

Virtual Attribute               : Type                            : enabled : attribute-type
--------------------------------:---------------------------------:---------:------------------
Collective Attribute Subentries : collective-attribute-subentries : true    : collectiveattributesubentries
entryDN                         : entry-dn                        : true    : entrydn
entryUUID                       : entry-uuid                      : true    : entryuuid
governingStructureRule          : governing-structure-rule        : true    : governingstructurerule
hasSubordinates                 : has-subordinates                : true    : hassubordinates
isMemberOf                      : is-member-of                    : true    : ismemberof
nsuniqueid                      : nsuniqueid                      : true    : nsuniqueid
numSubordinates                 : num-subordinates                : true    : numsubordinates
orclguid                        : orclguid                        : true    : orclguid
Password Policy Subentry        : password-policy-subentry        : true    : pwdpolicysubentry
Proximity                       : proximity                       : true    : proximity
structuralObjectClass           : structural-object-class         : true    : structuralobjectclass
subschemaSubentry               : subschema-subentry              : true    : subschemasubentry
Virtual Static member           : member                          : true    : member
Virtual Static uniqueMember     : member                          : true    : uniquemember

このコマンドの出力は、次のものを表示します(左から右):

- Virtual Attribute。仮想属性の名前。通常、それが何を行うかを説明するものです。

- Type。仮想属性のタイプ。特定のタイプの仮想属性を複数定義することができます。

- enabled。仮想属性を、有効化または無効化できます。無効化された仮想属性はサーバー構成内に保持されますが、それらの値は生成されません。

- attribute-type。仮想属性が生成される属性のタイプを指定します。

17.10.2 新規仮想属性を作成する方法

この例では、位置がシドニーのユーザー・エントリに仮装FAX番号の+61 2 45607890を追加する仮想属性ルールを作成し、有効化します(彼らが自身のエントリにすでにFAX番号を持っていない場合):

dsconfigコマンドを次のように実行します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
create-virtual-attribute \
--type user-defined --name "Sydney Fax Number" \
--set attribute-type:facsimiletelephonenumber --set enabled:true \
--set value:+61245607890 --set filter:"(&(objectClass=person)(l=Sydney))"

17.10.3 仮想属性を有効化または無効化する方法

仮想属性を有効化するには、enabledプロパティをtrueに設定します。仮想属性を無効化するには、enabledプロパティをfalseに設定します。この例では、前の例で作成された仮想属性を無効化します:

dsconfigコマンドを次のように実行します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
set-virtual-attribute-prop --name="Sydney Fax Number" --set enabled:false

17.10.4 仮想属性の構成を表示する方法

dsconfigのget-*-propサブコマンドを使用して、仮想属性構成を表示します。この例では、前の例で作成された仮想属性のプロパティを表示します:

dsconfigコマンドを次のように実行します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
get-virtual-attribute-prop --name="Sydney Fax Number"
Property          : Value(s)
------------------:----------------------------------
attribute-type    : facsimiletelephonenumber
base-dn           : -
conflict-behavior : real-overrides-virtual
enabled           : false
filter            : (&(objectClass=person)(l=Sydney))
group-dn          : -
value             : +61245607890

17.10.5 仮想属性の構成を変更する方法

dsconfigのset-*-propサブコマンドを使用して、仮想属性構成を変更します。この例では、競合が発生した場合に仮想属性の動作を変更します。デフォルトでは、実際の属性の値によって仮想属性の値が上書きされます。この変更によって、実際の属性の値と仮想属性の値がマージされます。

dsconfigコマンドを次のように実行します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
set-virtual-attribute-prop --name="Sydney Fax Number" \
--set conflict-behavior:merge-real-and-virtual

17.11 LDAPサブエントリの使用方法

LDAPサブエントリは、サーバーの操作データを保持し、ldapSubEntryオブジェクト・クラスを持つ特別なエントリです。それらは、サブエントリ制御リクエスト制御を含めることで明示的にリクエストされない場合は、クライアントに返されない点で、操作属性に似ています。

LDAPサブエントリは、エントリの範囲を指定するために使用できます。この機能は、集合属性の定義で使用され、アクセス制御などの他の分野でも便利です。詳細は、第17.12項「集合属性の使用方法」および第24.4.7項「LDAPサブエントリとしてパスワード・ポリシーを定義するには」を参照してください。

サブツリーの指定では、次のパラメータを使用して一連のエントリを定義します:

- ベース
これは、管理ポイントを基準としたサブツリーのルートの相対名です。管理ポイントがou=systemで、ベースがou=usersである場合、サブツリーは、ou=users,ou=systemで始まります。ベースは、""を含む任意の長さの名前コンポーネントにすることができます。この場合、サブツリーは、前の例のou=system管理ポイントで始まります。

- 切捨て
chopBeforeおよびchopAfterパラメータは、サブツリーのベースを基準とした名前であり、エントリとその子をコレクションから除外するかどうかを指定します。minimumパラメータは、選択にエントリを含めるために必要なベースとターゲットの間の名前コンポーネントの最小数を示します。maximumパラメータは、コレクションからエントリから除外されるまでに許可されるベースとターゲットの間の最大長を示します。

- 仕様フィルタ
仕様フィルタは、前のパラメータによって定義されたサブツリーを絞り込み、それがエントリの連続したセットではなく、エントリのobjectClass特性に基づいて収集されたセットになるようにします。

たとえば、管理領域のリージョンを対象にするが、そのリージョンのinetOrgPersonsのみを含むサブツリーを定義できます。

LDAPサブエントリのOracle Unified Directoryの実装は、RFC 3672 (http://www.ietf.org/rfc/rfc3672.txt)に基づいていますが、相対サブツリーという拡張が1つあり、それは次の項で説明します。

17.11.1 相対サブツリー

相対サブツリーは標準サブツリーのように機能します。ただし、仕様フィルタは、一連の絞込みではなくLDAP検索フィルタです

相対サブツリーの場合は、仕様によって、relativeBaseキーワードを使用してサブツリーのルートを指定することが定められています。baseキーワードを使用してサブツリーのルートを指定しないでください。

たとえば、次のサブツリー定義は、ベースDN ou=Peopleの下の、位置がパリのすべてのユーザーをターゲットにします:

subtreeSpecification: {relativeBase "ou=people", specificationFilter "(l=Paris)" }

17.12 集合属性の使用方法

集合属性は、エントリのコレクション全体で共有される値を持つ属性です。集合属性は、Oracle Directory Server Enterprise Editionサービス・クラス機能に類似した機能を提供します。

Oracle Unified Directoryの集合属性は、仮想属性に似ていますが、LDAPサブエントリとしてユーザー・データとともに定義され、格納されます。ユーザー・データの一部として、集合属性は、トポロジ内の他のサーバーにレプリケートできます。

この項では、Oracle Unified Directory内の集合属性の実装と、集合属性の構成方法について説明します。この項の内容は次のとおりです:

- 第17.12.1項「集合属性の標準に対する拡張」

- 第17.12.2項「集合属性の構成」

- 第17.12.3項「継承集合属性」

17.12.1 集合属性の標準に対する拡張

集合属性のOracle Unified Directoryでの実装は、RFC 3671 (http://www.ietf.org/rfc/rfc3671.txt)およびRFC 3672 (http://www.ietf.org/rfc/rfc3672.txt)に基づいており、いくつかの特定の拡張があります。これの拡張により、Oracle Unified Directoryの集合属性は、LDAPクライアント・アプリケーションに対して、より透過的になっており、これについては次の項で説明します:

- 第17.12.1.1項「集合属性の指定」

- 第17.12.1.2項「集合属性と競合解消」

- 第17.12.1.3項「特定のエントリからの集合属性の除外」

17.12.1.1 集合属性の指定

RFC 3671 (http://www.ietf.org/rfc/rfc3671.txt)によれば、集合属性はCOLLECTIVE属性タイプを持ち、スキーマで定義されている通常のユーザー属性から導出し、c-接頭辞を持っている必要があります。たとえば、c-lは、標準l属性に対する集合属性であり、影響を受けるユーザー・エントリには実行中にc-lが追加されます。

この仕様により、多くのクライアント・アプリケーションで問題が発生することがあります。それらは、一般的に、集合属性を認識せず、集合属性を処理するように変更または拡張する必要がありすま。したがって、Oracle Unified Directoryでは、この制約を取り除き、任意の通常の属性を、スキーマ内で集合属性として定義することがサポートされています。この拡張は、関連する集合属性サブエントリに、必要な属性を追加し、その属性に集合オプションでマークすることで容易になります。

17.12.1.2 集合属性と競合解消

集合属性には、様々な方法で名前が付けられます。このため、すでに関連する実際の属性を含んでいる影響を受けるユーザー・エントリに対して、競合解消メカニズムが提供されています。Oracle Unified Directoryでは、仮想属性の場合と同じ競合解消オプション(real-overrides-virtual、virtual-overrides-realおよびmerge-real-and-virtual)を集合属性に提供しています。

デフォルトの競合解消ルールは、real-overrides-virtualです。エントリにすでに同じ属性タイプが定義されている場合は、明示的に定義された属性が集合属性より優先されます。この動作は、collectiveConflictBehavior 属性を使用することで集合属性サブエントリごとに(virtual-overrides-realまたはmerge-real-and-virtualに)変更できます。

次の例では、Parisの値を持つl集合属性を、ou=peopleの下にある該当するユーザー・エントリそれぞれに動的に追加します。集合属性の値によって、エントリに固有のlの値がすべてオーバーライドされます:

dn: cn=People Locale,dc=example,dc=com
objectClass: top
objectClass: subentry
objectClass: collectiveAttributeSubentry
objectClass: extensibleObject
cn: People Locale
l;collective: Savoie
subtreeSpecification: {base "ou=people", minimum 1}
collectiveConflictBehavior: virtual-overrides-real

17.12.1.3 特定のエントリからの集合属性の除外

場合によっては、特定のユーザー・エントリに集合属性を含めることを避ける必要があります。この動作を得るために、そのようなエントリにcollectiveExclusions操作属性を追加できます。特定の集合属性を除外するには、collectiveExclusions属性の値として属性名をリストします。すべての集合属性を除外するには、collectiveExclusionsの値をexcludeAllCollectiveAttributesに設定します。

次の例では、preferredLanguage属性を、user.0のエントリへの適用から除外します:

dn: uid=user.0,ou=People,dc=example,dc=com
objectclasses and other user attributes
collectiveExclusions: preferredLanguage

次の例では、c-l属性を、user.1のエントリへの適用から除外します:

dn: uid=user.1,ou=People,dc=example,dc=com
objectclasses and other user attributes
collectiveExclusions: c-l

次の例では、preferredLanguageとc-lの両方の属性を、user.2のエントリへの適用から除外します:

dn: uid=user.2,ou=People,dc=example,dc=com
objectclasses and other user attributes
collectiveExclusions: preferredLanguage
collectiveExclusions: c-l

次の例では、すべての集合属性を、user.0のエントリへの適用から除外します:

dn: uid=user.0,ou=People,dc=example,dc=com
objectclasses and other user attributes
collectiveExclusions: excludeAllCollectiveAttributes

17.12.2 集合属性の構成

集合属性は、ディレクトリ・ツリー内のLDAPサブエントリを使用して定義されます(適用可能な場合)。次の例では、複数のユーザー・エントリを持つ単純なツリーを使用します。

dn: dc=example,dc=com
dn: ou=People,dc=example,dc=com
dn: uid=user.0,ou=People,dc=example,dc=com
dn: uid=user.1,ou=People,dc=example,dc=com
dn: uid=user.2,ou=People,dc=example,dc=com
...

すべてのユーザーに共通のpreferredLanguage属性を追加するには、次のものに類似した集合属性サブエントリを作成して追加します:

dn: cn=People Preferred Language,dc=example,dc=com
objectClass: top
objectClass: subentry
objectClass: collectiveAttributeSubentry
objectClass: extensibleObject
cn: People Preferred Language
preferredLanguage;collective: fr
subtreeSpecification: {base "ou=people", minimum 1}

次の例に示すように、preferredLanguage属性と値のペアは、ou=peopleの下のすべてのユーザー・エントリに動的に追加されます:

dn: uid=user.0,ou=People,dc=example,dc=com
objectclasses and other user attributes
preferredLanguage: fr

dn: uid=user.1,ou=People,dc=example,dc=com
objectclasses and other user attributes
preferredLanguage: fr

...

同じ手順が、collective属性タイプにも適用されます。たとえば、c-l集合属性タイプは、エントリのコレクションに対して地域名を指定します。次の例では、共通c-l集合属性を追加します:

dn: cn=People Locale,dc=example,dc=com
objectClass: top
objectClass: subentry
objectClass: collectiveAttributeSubentry
objectClass: extensibleObject
cn: People Locale
c-l: Paris
subtreeSpecification: {base "ou=people", minimum 1}

この例に示すように、c-l: Paris属性が、該当するエントリに追加されます:

dn: uid=user.0,ou=People,dc=example,dc=com
objectclasses and other user attributes
c-l: Paris

dn: uid=user.1,ou=People,dc=example,dc=com
objectclasses and other user attributes
c-l: Paris

...

次のようにして、任意の集合属性のサブエントリに複数の集合属性を定義できます:

- 集合属性タイプをサブエントリに追加する

- 集合オプションを指定した通常の属性タイプを追加する

- それらの2つの組合せを追加する

集合属性サブエントリでは、柔軟かつ複雑な定義が可能です。集合属性の範囲指定およびsubtreeSpecification構文の詳細は、RFC 3671 (http://www.ietf.org/rfc/rfc3671.txt)およびRFC 3672 (http://www.ietf.org/rfc/rfc3672.txt)を参照してください。

この項では、集合属性に関する次の内容について説明します:

- 第17.12.2.1項「新規集合属性を作成する方法」

- 第17.12.2.2項「集合属性を削除する方法」

- 第17.12.2.3項「エントリに適用される集合属性をリストする方法」

17.12.2.1 新規集合属性を作成する方法

1. 集合属性サブエントリを指定するchangetype: add要素を含むLDIFファイルを作成します。
addの後に空白がないことを確認してください。addの後に空白があると、BASE64エンコーディングではその値は空白を表し、それによって問題が発生することがあります。

この例では、add_collective_attr.ldifという名前の入力LDIFファイルを使用します。

dn: cn=People Preferred Language,dc=example,dc=com
changetype: add
objectClass: top
objectClass: subentry
objectClass: collectiveAttributeSubentry
objectClass: extensibleObject
cn: People Preferred Language
preferredLanguage;collective: fr
subtreeSpecification: {base "ou=people", minimum 1}

2. 次の例に示すように、ldapmodifyコマンドを使用して、集合属性を追加します。

$ ldapmodify -p 1389 -h localhost -D "cn=Directory Manager" -j pwd-file \
-f /usr/local/add_collective_attr.ldif
Processing ADD request for cn=People Preferred Language,dc=example,dc=com
ADD operation successful for DN cn=People Preferred Language,dc=example,dc=com

17.12.2.2 集合属性を削除する方法

集合属性は、ldapdeleteコマンドまたはldapmodifyコマンドを使用することで削除できます。この例では、ldapmodifyコマンドを使用します。

次の例に示すように、changetype: delete要素を指定してldapmodifyコマンドを使用します。

$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file
dn: cn=People Preferred Language,dc=example,dc=com
changetype: delete
deleting entry cn=People Preferred Language,dc=example,dc=com

17.12.2.3 エントリに適用される集合属性をリストする方法

特定のユーザー・エントリに適用される集合属性サブエントリをリストするには、そのエントリに対するcollectiveAttributeSubentries操作属性をリクエストします。

ldapsearchコマンドを使用して、user.0エントリに適用される集合属性サブエントリをリストします:

$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
-b "uid=user.0,ou=People,dc=example,dc=com" \
"objectclass=*" "collectiveAttributeSubentries"

version: 1
dn: uid=user.0,ou=People,dc=example,dc=com
collectiveAttributeSubentries: cn=People Preferred Language,dc=example,dc=com

17.12.3 継承集合属性

継承属性では、継承の特性から、属性の共通セットの共有が可能になります。継承集合属性は、標準サブエントリ・サブツリー仕様を使用する柔軟な範囲指定メカニズムを提供し、RDNの定義および構築のためのすべての属性タイプをサポートします。

集合属性と継承集合属性の主な相違は、属性値のソースです:

- 集合属性は、常に、その値をその定義エントリから導出します。

- 継承集合属性は、直接的または間接的に他のエンティティから集合属性値を継承できます。

継承集合属性の機能は、就航属性の上に構築および拡張されます。継承属性は、集合属性サブエントリの特別なタイプとして定義されます(inheritedCollectiveAttributeSubentry)。このタイプは、さらに次の2つの個別サブタイプに分かれています:

- inheritedFromDNCollectiveAttributeSubentry

- inheritedFromRDNCollectiveAttributeSubentry

各サブタイプには、構成属性の独自のセットがあります。これらのサブタイプは1つの定義内に混在できず、継承属性定義は1つのサブタイプのもののみになります。

継承集合属性の範囲下にあるエントリは、複数のテンプレート・エントリを指す可能性があり、したがって、複数のエントリから値を継承できます。この場合、最初に処理された値が優先されます。

他の仮想属性と同様に、継承属性ではスキーマ・チェックは実行されません。したがって、継承によって、エントリがスキーマ違反になることがあります。ただし、これらの属性はすべて仮想であるため、この種のスキーマ違反は、サーバー機能に影響がないため無視できます。

継承集合属性は、Oracle Directory Server Enterprise Editionサービス・クラス(クラシックCoS)に類似した機能を提供します。たとえば、次のものがあるとします。ユーザー・エントリ:

uid=psmith,ou=people,dc=example,dc=com
departmentNumber: 123
...

部門エントリ:

cn=123,ou=departments,dc=example,dc=com
telephoneNumber: 4486152643
...

および継承属性定義:

dn: cn=classicCOS,dc=example,dc=com
objectClass: top
objectClass: subentry
objectClass: inheritedCollectiveAttributeSubentry
objectClass: inheritedFromRDNCollectiveAttributeSubentry
cn: classicCOS
subtreeSpecification: {base "ou=people"}
inheritFromBaseRDN: ou=departments
inheritFromRDNAttribute: departmentNumber
inheritFromRDNType: cn
inheritAttribute: telephoneNumber

継承集合属性サブエントリは、ou=people,dc=example,dc=comの下のユーザー・エントリに適用されます。telephoneNumber属性は、それらのエントリそれぞれに追加されます。telephoneNumber属性の値は、次のロジックで構築したDNを持つエントリから継承されます:

inheritFromRDNType=inheritFromRDNAttribute,inheritFromBaseRDN,"inherited collective attribute sub-entry rootDN"

またはcn=123,ou=departments,dc=example,dc=com

したがって、影響を受けるユーザー・エントリは次の形式になります:

uid=psmith,ou=people,dc=example,dc=com
departmentNumber: 123
...
telephoneNumber: 4486152643

17.12.3.1 継承集合属性の指定

通常の集合属性と同様に、継承集合属性は、ディレクトリ・ツリー内のLDAPサブエントリを使用して定義されます(適用可能な場合)。

次の例では、複数のユーザー・エントリを持つ単純なツリーを使用します。

dn: dc=example,dc=com
dn: ou=People,dc=example,dc=com
dn: uid=hpollock,ou=People,dc=example,dc=com
dn: uid=cventer,ou=People,dc=example,dc=com
dn: uid=sdonnelly,ou=People,dc=example,dc=com
...

すべてのユーザーに継承postalAddress属性を追加するには、次のものに類似した継承集合属性サブエントリを作成して追加します:

dn: cn=indirectCOS,dc=example,dc=com
objectClass: top
objectClass: subentry
objectClass: inheritedCollectiveAttributeSubentry
objectClass: inheritedFromDNCollectiveAttributeSubentry
cn: indirectCOS
subtreeSpecification: {base "ou=people"}
inheritFromDNAttribute: manager
inheritAttribute: postalAddress

このサブエントリは、そのユーザー・エントリが、そのユーザー・エントリ内のmanager属性によって参照されるエントリからそのpostalAddress値を継承することを指定します。

マネージャのエントリには、postalAddress属性の実際の値が含まれています:

dn: uid=dsmith,ou=People,dc=example,dc=com
... objectclasses and other user attributes
postalAddress: 650 Granger Parkway, Redwood Shores, CA 94065

各ユーザー・エントリは、マネージャ・エントリを参照し、そのエントリからそのpostalAddressを継承します:

dn: uid=hpollock,ou=People,dc=example,dc=com
... objectclasses and other user attributes
manager: uid=dsmith,ou=People,dc=example,dc=com
postalAddress: 650 Granger Parkway, Redwood Shores, CA 94065

dn: uid=cventer,ou=People,dc=example,dc=com
... objectclasses and other user attributes
manager: uid=dsmith,ou=People,dc=example,dc=com
postalAddress: 650 Granger Parkway, Redwood Shores, CA 94065

dn: uid=sdonnelly,ou=People,dc=example,dc=com
... objectclasses and other user attributes
manager: uid=dsmith,ou=People,dc=example,dc=com
postalAddress: 650 Granger Parkway, Redwood Shores, CA 94065

17.13 リフェラルの構成

リフェラルは、結果のかわりにクライアントに返されるリモート接尾辞またはエントリへのポインタです。サーバーは、クライアントのリクエストを処理できない場合、トポロジ内の他のサーバーをクライアントに示すリフェラルのリストをクライアントに送信します。その後、クライアントは、リフェラル・リスト内のリモート・サーバーの1つに対して操作を再度実行します。

サーバーは、次の場合にリフェラルのリストを返します:

- サーバーまたはローカル・バックエンド・ワークフロー要素で、書込み可能性が無効化されているかinternal-onlyに設定されています。詳細は、第D.22.6項「書込み可能モード」を参照してください。
この種のリフェラルは、referral on updateと呼ばれます。

- ローカル・バックエンド・ワークフロー要素が、メンテナンス・モードになっていました。
一時的に、サーバーがクライアント・リクエストに応答しないようにする場合は、ローカル・バックエンド・ワークフロー要素をメンテナンス・モードにすることができます。

バックエンドをメンテナンス・モードにするには、ローカル・バックエンド・ワークフロー要素のmaintenanceプロパティをtrueに設定します。

- データ・インポートまたは再索引付けの処理中などなんらかの理由で、バックエンドが使用できません。

- クライアント・リクエストが明示的にスマート・リフェラルをターゲットにしています。詳細は、第17.13.3項「スマート・リフェラル」を参照してください。

リフェラルURLは、ホスト名、ポート番号、および必要に応じてローカル・ホストまたは別のサーバーのDNを含むLDAP URLです。詳細は、第17.13.4項「LDAP URL」を参照してください。

使用可能な場合は、サーバーから結果コードREFERRAL (10)がリフェラルURLのリストとともに返されます。使用可能なリフェラルURLがない場合は、サーバーから結果コードUNAVAILABLE (52)が返されます。

リフェラルURLは次の2つの方法で作成できます:

- レプリケートされたサーバーの場合は、レプリケーション・サービスを使用してリストを伝播します。詳細は、第17.13.1項「レプリケートされたトポロジでのリフェラル」を参照してください。

- DBローカル・バックエンド・ワークフロー要素のds-cfg-referrals-urlプロパティを設定することで、リストを手動で作成します。詳細は、第17.13.2項「リフェラル・リストの手動による構成」を参照してください。

17.13.1 レプリケートされたトポロジでのリフェラル

レプリケーション・サービスによって、リクエストをリダイレクトできるリフェラルURLのリストが生成されます。このリストは、各ローカル・サーバーで構成されているLDAP/LDAPS接続ハンドラに対応しています。LDAP/LDAPS接続ハンドラ以外の値を公開するには、独自のリフェラルURLを、ローカル・サーバー上のレプリケーション・ドメインのreferrals-urlプロパティの値として定義します。

クライアント・リクエストが、使用できないレプリケートされたサーバーをターゲットとしている場合は、サーバーから、リクエストをリダイレクトできるリフェラルURLのリストが送信されます。

リフェラルURLのリストは、リクエストに使用されたプロトコルに従って編成されます。たとえば、その操作がLDAPS経由で実行された場合、提供される最初のURLは、同じセキュアなプロトコル(LDAPS)を使用するものになります。

さらに、リストはグループIDによって編成されます。同じレプリケーション・グループ内のサーバーを表すURLは、最初に提示されます。URLのリストは、プロトコル・タイプ(LDAP/LDAPS)ごとに16個までのURLに制限されており、信頼されないサーバーは除外されます。

セキュリティ上の理由から、レプリケーション・サービスによって伝播されるリテラルは、信頼されないサーバーに対しては返されません。信頼されないサーバーが、トポロジの残りのものに関する情報を漏えいしないようにします。クライアント・リクエストが、信頼されないサーバーをターゲットとしている場合は、リフェラルURLのリストには、ローカル・バックエンド上の管理者によって管理されているサーバーのみが含まれるようになります。さらに、レプリケーション・サービスによって提供されるリフェラルURLでは、トポロジ内の信頼されないサーバーは除外されます。

レプリケーション・ドメインのpublish-referrals構成プロパティがfalseに設定されている場合は、レプリケーション・サービスによって生成されるリフェラルのリストにそのサーバーは含まれなくなります。

17.13.2 リフェラル・リストの手動による構成

レプリケーション・サービスによって提示されるリフェラルURLのリストをオーバーライドするか、またはレプリケートされたトポロジの外部でリフェラルを設定するには、DBローカル・バックエンド・ワークフロー要素のreferrals-urlプロパティを設定します。

referrals-urlプロパティは、値として1つ以上のLDAP URLを取ります。

次の例では、dc=example,dc=com接尾辞をターゲットとしているクライアント・リクエストは、ホストhost1.example.com上で実行されているサーバーを参照し、ポート2389でリスニングする必要があります。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
set-workflow-element-prop --element-name userRoot \
--set referrals-url:ldap://host1.example.com:2389/dc=example,dc=com

複数のLDAP URLを指定するには、--addサブオプションを複数回使用します。例:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
set-workflow-element-prop --element-name userRoot \
--add referrals-url:ldap://host1.example.com:2389/dc=example,dc=com
--add referrals-url:ldap://host2.example.com:1389/dc=example,dc=com

17.13.3 スマート・リフェラル

スマート・リフェラルは、別のサーバーまたは別の接尾辞のコンテンツを参照する特別なタイプのエントリです。スマート・リフェラル・エントリには、ref属性の1つ以上のインスタンスを含むreferralオブジェクト・クラスが含まれています。各ref属性には、リフェラルで使用されるLDAP URLが含まれています。

17.13.3.1 スマート・リフェラルを構成する方法

スマート・リフェラルを構成するには、referralオブジェクト・クラスおよびref属性を含む新しいエントリを追加します。ref属性には、LDAP URLが含まれている必要があります。

この例では、サーバーAに存在しているユーザー・エントリのリフェラルをサーバーBに作成します。

1. 次の検索コマンドを実行することでサーバーA上のユーザー・エントリを見つけます:

$ ldapsearch -h serverA -p 1389 -b dc=example,dc=com "uid=user.199" cn
dn: uid=user.199,ou=People,dc=example,dc=com
cn: Alfred Altay

2. サーバーB上のディレクトリにリフェラル・エントリを追加します。

$ ldapmodify -h serverB -p 2389 -D "cn=directory manager" -j pwd-file
dn: uid=aaltay,ou=People,dc=example,dc=com
changetype: add
objectclass: top
objectclass: extensibleObject
objectclass: referral
uid: aaltay
ref: ldap://serverA:1389/dc=example,dc=com??sub?(uid=user.199)

Processing ADD request for uid=aaltay,ou=People,dc=example,dc=com
ADD operation successful for DN uid=aaltay,ou=People,dc=example,dc=com

3. 十分なアクセス権を持つユーザーとして、サーバーB上のユーザー・エントリを検索します。

$ ldapsearch -h serverB -p 2389 -D "cn=directory manager" -j pwd-file \
-b dc=example,dc=com "uid=aaltay"
SearchReference(referralURLs={ldap://localhost:1389/dc=example,dc=com??sub?})

17.13.3.2 スマート・リフェラルを変更する方法

スマート・リフェラルを表示または変更するには、manageDsaIT制御を指定して、ldapsearchまたはldapmodifyコマンドを使用します。この制御は、サーバーに、通常のエントリとしてリフェラル・オブジェクトを管理する予定であることを通知し、リフェラル・オブジェクトを読み取りまたは更新するリクエストに対してサーバーからリフェラル結果が送信されないようにします。

1. ldapsearchコマンドを使用して、リフェラルを表示します。

$ ldapsearch -h serverB -p 2389 -D "cn=Directory Manager" -j pwd-file \
-b dc=example,dc=com --control managedsait "(uid=aaltay)" ref
dn: uid=aamar,ou=People,dc=example,dc=com
ref: ldap://serverA:1389/dc=example,dc=com??sub?(uid=user.199)

2. ldapmodifyコマンドを使用して、リフェラルを変更します。
この例では、リフェラルが指すサーバーと、下にエントリが配置されているベースDNを変更します。

$ ldapmodify -h serverB -p 2389 -D "cn=Directory Manager" -j pwd-file \
--control managedsait
dn: uid=aaltay,ou=People,dc=example,dc=com
changetype: modify
replace: ref
ref: ldap://serverC:1389/ou=People,dc=example,dc=com??sub?(uid=user.199)
Processing MODIFY request for uid=aaltay,ou=People,dc=example,dc=com
MODIFY operation successful for DN uid=aaltay,ou=People,dc=example,dc=com

17.13.3.3 スマート・リフェラルを削除する方法

スマート・リフェラルを削除するには、manageDsaIT制御を指定して、ldapdeleteコマンドを使用します。この制御は、サーバーに、通常のエントリとしてリフェラル・オブジェクトを管理する予定であることを通知し、リフェラル・オブジェクトを読み取りまたは更新するリクエストに対してサーバーからリフェラル結果が送信されないようにします。

1. ldapsearchコマンドを使用して、リフェラルを表示します。

$ ldapsearch -h serverB -p 2389 -D "cn=Directory Manager" -j pwd-file \
-b dc=example,dc=com --control managedsait "(uid=aaltay)" ref
dn: uid=aamar,ou=People,dc=example,dc=com
ref: ldap://serverA:1389/dc=example,dc=com??sub?(uid=user.199)

2. ldapdeleteコマンドを使用して、リフェラルを削除します。

$ ldapdelete -h serverB -p 2389 -D "cn=Directory Manager" -j pwd-file \
--control managedsait "uid=aaltay,ou=People,dc=example,dc=com"
Processing DELETE request for uid=aaltay,ou=People,dc=example,dc=com
DELETE operation successful for DN uid=aaltay,ou=People,dc=example,dc=com

17.13.4 LDAP URL

LDAP URLの形式は、RFC 4516で説明されており、次のように要約されます:

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

LDAP URLのコンポーネントは、次のとおりです:

ldap[s]

サーバーに接続するのか(ldap:)、SSL経由でサーバーに接続するのか(ldaps:)を示します。

hostname

LDAPサーバーのホスト名またはIPアドレスを指定します。

port

LDAPサーバーのポート番号を指定します。ポートが指定されていない場合、デフォルトLDAPポート(389)またはLDAPSポート(636)が使用されます。

base_dn

ディレクトリ内のエントリの識別名(DN)を指定します。このDNは、検索の開始点であるエントリを識別します。ベースDNが指定されていない場合、検索は、そのディレクトリ・ツリーのルートから開始されます。

attributes

指定された属性を返します。複数の属性を区切るには、カンマを使用します。属性が指定されていない場合、検索によってすべての属性が返されます。

scope

検索の範囲を指定します:

- base。base_dnで指定されたベース・エントリのみを検索します。

- one。base_dnで指定されたベース・エントリの1レベル下を検索します。

- sub。base_dnで指定されたベース・エントリおよびその下のすべてのエントリを検索します。

範囲が指定されていない場合、ベース検索が実行されます。

filter

検索の指定された範囲内のエントリに適用される検索フィルタを指定します。フィルタが指定されていない場合、デフォルト(objectclass=*)が使用されます。

空白はすべて、ご使用のシェルに適した文字を使用してエスケープする必要があります。

注意:

LDAPクライアントが認証を提供しない場合、LDAP URLを使用して開始された検索リクエストはすべて匿名(未認証)になります。

17.13.4.1 LDAP URLの例

- 次のLDAP URLは、dc=example,dc=comの下のいずれかのレベルで姓Jensenを持つすべてのエントリの検索を指定します。ポートが指定されていない場合は、デフォルト(389)が使用されます。属性が指定されていない場合、すべての属性が返されます。

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

- 次のLDAP URLは、dc=example,dc=comの下のすべてのレベルにおけるcnおよびtelephoneNumber属性の検索を指定します。サーバーは、ポート2389でリモート・サーバーにアクセスします。検索フィルタが指定されていないため、デフォルト・フィルタ(objectclass=*)が使用されます。

ldap://example.com:2389/dc=example,dc=com?cn,telephoneNumber?sub

17.14 Oracle Directory Services Managerを使用した仮想属性の管理

ODSMの各サーバー・インスタンスの「構成」タブで、仮想属性を作成、削除、および変更できます。

次の項では、ODSMで仮想属性を管理する方法を説明し、内容は次のとおりです:

- 第17.14.1項「既存の仮想属性の表示」

- 第17.14.2項「仮想属性の作成」

17.14.1 既存の仮想属性の表示

ODSMで既存の仮想属性を表示するには、次の手順を実行します:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「構成」タブを選択します。

3. 「一般構成」ノードを開きます。

4. 「仮想属性」ノード内の属性を開き、既存の仮想属性をすべて表示します。

図17-1 仮想属性

5. 左ペインで、表示する仮想属性をクリックします。
右ペインに、仮想属性の詳細が表示されます。

17.14.2 仮想属性の作成

ODSMを使用して仮想属性を作成するには、次の手順を実行します:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「構成」タブを選択します。

3. 「作成」メニューから、「仮想属性」を選択します。

4. 「名前」フィールドに、仮想属性の名前を入力します。

5. 「仮想属性タイプ」リストから、仮想属性のタイプを選択します。

6. 「追加」アイコンをクリックし、この仮想属性の使用に適したエントリが含まれている分岐のベースDNを入力します。
次のいずれかを実行してベースDNを入力します:

- 「ベースDN」フィールドで、目的のベースDNを入力します。

- 「選択」をクリックし、ツリー・ビューまたは検索ビューを使用してエントリを選択します。

7. 「追加」アイコンをクリックし、この仮想属性の使用に適したメンバーを持つグループのDNを入力します。
次のいずれかを実行して、グループのDNを指定します:

- 「グループDN」フィールドで、目的のグループDNを入力します。

- 「選択」をクリックし、ツリー・ビューまたは検索ビューを使用してエントリを選択します。

8. 「追加」アイコンをクリックし、それらのエントリに対して仮想属性を生成する必要があるかどうかを判別するためにそれらのエントリに対して適用される検索フィルタを指定します。

9. 「作成」をクリックします。

注意:

前述の手順で説明したプロパティは、追加のプロパティが含まれているユーザー定義およびメンバー仮想属性を除いて、すべての仮想属性に対して同じです。

ユーザー定義仮想属性

これには、次の追加プロパティがあります:

競合動作: 関連する属性に対してすでに1つ以上の実際の値が含まれているエントリに対してサーバーが提示する必要がある動作を指定します。次の値があります:

- 実際の値と仮想値をマージ: 仮想属性プロバイダが、エントリに含まれている実際の値をすべて保持し、それらを、生成された仮想値のセットとマージして、実際の値と仮想値の両方が使用されるようにすることを示します。

- 実際の値が仮想値をオーバーライド: エントリに含まれている実際の値をすべて保持して使用し、仮想値を生成しないことを示します。

- 仮想値が実際の値をオーバーライド: 仮想属性プロバイダが、エントリに含まれている実際の値をすべて抑止し、仮想値を生成して使用することを示します。

値: 仮想属性に含める値を指定します。

メンバー仮想属性

これには、次の追加プロパティがあります:

競合動作: これは、ユーザー定義仮想属性に似ています。

メンバーシップの取得を許可: 仮想属性のすべての値を要求するリクエストを処理するかどうかを示します。デフォルト値はfalseです。

17.15 Oracle Directory Services Managerを使用したデータの管理

ODSMの各サーバー・インスタンスの「データ・ブラウザ」タブで、ディレクトリ・データに対する基本検索を実行でき、エントリを追加、削除、および変更できます。

ODSMには、どのデータ・フィールドにも文字のサブセットを入力できる自動提案機能があります。その後、ODSMによって、その文字のサブセットに一致するすべてのエントリが返されます。自動提案機能では、ODSMによってすでにキャッシュされているエントリのみが返されます。

次の項では、ODSMでのデータの管理方法を説明し、内容は次のとおりです:

- 第17.15.1項「エントリの表示」

- 第17.15.2項「エントリの属性の表示」

- 第17.15.3項「エントリの検索」

- 第17.15.4項「エントリの追加」

- 第17.15.5項「既存のエントリに基づいたエントリの追加」

- 第17.15.6項「エントリの削除」

- 第17.15.7項「エントリとそのサブツリーの削除」

- 第17.15.8項「エントリのRDNの変更」

- 第17.15.9項「LDIFファイルからのデータのインポート」

- 第17.15.10項「LDIFファイルへのデータのエクスポート」

17.15.1 エントリの表示

ODSMデータ・ブラウザを使用してディレクトリ・エントリを表示するには、次の手順を完了します:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「データ・ブラウザ」タブを選択します。

3. 「ネットワーク・グループ」リストから適切なネットワーク・グループを選択します。

4. 「エントリ」ペインでエントリを開き、必要なサブツリー内のエントリをすべて表示します。
一度に最大200個のエントリが表示されます。

5. 特定のエントリ・セットにエントリを制限するには、サブツリー(たとえば、ou=People)を選択し、「フィルタ」アイコンをクリックします。
「フィルタ」フィールドで、必要なフィルタ(たとえば、surname=a*)を入力し、「OK」をクリックします。

6. 左ペインで表示するエントリを選択します。
右側のタブにエントリの詳細が表示されます。

第17.15.2項「エントリの属性の表示」も参照してください。

17.15.2 エントリの属性の表示

エントリの属性を表示するには:

1. 第17.15.1項「エントリの表示」の説明に従って、エントリを表示します。

2. 左ペインで表示するエントリを選択します。
右側のタブにエントリの詳細が表示されます。

すべてのエントリに、対応する「プロパティ」タブがあり、それにはそのエントリの使用可能な属性(必須とオプション)がすべて表示されます。さらに、次のタイプのエントリには、カスタマイズされたタブがあり、それにはそのエントリ・タイプに対して論理的なレイアウトでエントリの必須属性が表示されます:

- inetorgpersonエントリには、対応する「ユーザー・ページ」タブがあります。

- groupエントリには、対応する「グループ・ページ」タブがあります。

- countryエントリには、対応する「国ページ」タブがあります。

- domainエントリには、対応する「ドメイン・ページ」タブがあります。

- organizationエントリには、対応する「組織ページ」タブがあります。

- organization unitエントリには、対応する「組織単位ページ」タブがあります。

17.15.3 エントリの検索

「データ・ブラウザ」タブの基本検索機能では、ユーザーまたはグループのエントリを検索できます。ディレクトリ・データに対して基本検索を実行するには、次の手順を完了します:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「データ・ブラウザ」タブを選択します。

3. 「ネットワーク・グループ」リストから適切なネットワーク・グループを選択します。

4. 左ペインで「検索」タブを選択します。

5. 「対象」リストから、ユーザー・エントリとグループ・エントリのどちらを検索するのかを選択します。

6. エントリ名の任意の部分を入力し、右矢印ボタンをクリックします。たとえば、John Smithというユーザーを検索するには、Smith、Smi、Johnなどを入力できます。

7. 左ペインにエントリが表示されたら、そのエントリをダブルクリックし、右ペインにその詳細を表示します。

17.15.4 エントリの追加

Oracle Directory Services Managerでエントリを追加または削除するには、親エントリに対する書込みアクセス権限があり、新規エントリの識別名を認識している必要があります。ODSMデータ・ブラウザを使用してエントリを追加するには、次の手順を完了します:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「データ・ブラウザ」タブを選択します。

3. 「ネットワーク・グループ」リストから適切なネットワーク・グループを選択します。

4. 「エントリの追加」アイコンをクリックし、追加するエントリの種類(たとえば、「ユーザー・エントリ」)を選択します。

5. 親エントリのDNを入力します。これはディレクトリ・ツリーでその下に新しいエントリが表示されるエントリです。たとえば、ou=people,dc=example,dc=comです。
親エントリとして既存のエントリを選択するには、「選択」をクリックします。

「エントリ・ピッカー」ウィンドウで、「ツリー・ビュー」を選択してディレクトリ・ツリーに移動し、対象のエントリを見つけるか、「検索ビュー」を選択して対象のエントリを検索します。

6. 新しいエントリの追加情報を入力します。

7. 必要な詳細を入力したら、「作成」をクリックします。

17.15.5 既存のエントリに基づくエントリの追加

ODSMデータ・ブラウザを使用して既存のエントリに基づいたエントリを追加するには、次の手順を完了します:

1. 第17.15.1項「エントリの表示」の説明に従って、既存のエントリを表示します。

2. 新しいエントリの基にするエントリを選択し、類似エントリの作成アイコンをクリックします。
既存のエントリの詳細が右ペインに表示されます。

3. そのエントリの新しい共通名 およびユーザー名を指定します。

4. エントリの他の詳細を変更します。

5. 「作成」をクリックします。

17.15.6 エントリの削除

ODSMデータ・ブラウザを使用してエントリを削除するには、次の手順を完了します:

1. 第17.15.1項「エントリの表示」の説明に従って、既存のエントリを表示します。

2. 削除するエントリを選択し、「削除」アイコンをクリックします。

3. 「エントリの削除」ダイアログで、適切なエントリを削除しようとしていることを確認し、「OK」をクリックします。

17.15.7 エントリとそのサブツリーの削除

エントリと、ディレクトリ・ツリー内でその下にあるすべてのエントリを削除するには、次の手順を完了します:

1. 第17.15.1項「エントリの表示」の説明に従って、既存のエントリを表示します。

2. 削除するエントリを選択し、エントリとそのサブツリーの削除アイコンをクリックします。

3. 「サブツリーの削除」ダイアログで、適切なエントリを削除しようとしていることを確認し、「OK」をクリックします。

17.15.8 エントリのRDNの変更

ODSMデータ・ブラウザを使用してエントリのRDNを変更するには、次の手順を完了します:

1. 第17.15.1項「エントリの表示」の説明に従って、既存のエントリを表示します。

2. 新しいエントリの基にする、変更するRDNを持つエントリを選択し、「RDNの編集」アイコンをクリックします。

3. 「新規RDN値」フィールドに新しいRDNを指定します。

4. 古いRDNを形成していた値をエントリから削除する場合は、「古いRDNの削除」を選択します。このチェック・ボックスを選択しない場合、古いRDNを形成していた値は、そのエントリの非識別属性値として保持されます。

5. オプションで、「サブツリー・エントリのリフレッシュ」アイコンをクリックし、RDNの変更を確認します。

17.15.9 LDIFファイルからのデータのインポート

次のようにして、LDIFファイルからエントリをインポートできます:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「データ・ブラウザ」タブを選択します。

3. 「ネットワーク・グループ」リストから適切なネットワーク・グループを選択します。

4. 「LDIFのインポート」アイコンをクリックします。

5. 「エントリのインポート」ダイアログで、「ファイルの選択」をクリックします。

6. システム上のLDIFファイルを見つけ、「OK」をクリックします。

7. 「LDIFのインポート進行状況」ダイアログで、インポートの進行状況を監視し、インポートが完了したら、「OK」をクリックします。

8. データ・ブラウザ・ツリーがリフレッシュされ、新規エントリが表示されます。

17.15.10 LDIFファイルへのデータのエクスポート

次のようにして、ODSMを使用して、LDIFファイルにエントリをエクスポートできます:

ODSMデータ・ブラウザを使用してLDIFファイルにエントリをエクスポートするには、次の手順を完了します:

1. 第17.15.1項「エントリの表示」の説明に従って、エントリを表示します。

2. エクスポートするサブツリーの最上位レベルの識別名にナビゲートし、「LDIFのエクスポート」アイコンをクリックします。

3. 操作属性をエクスポートする場合は、「エントリのエクスポート」ダイアログで、「操作属性のエクスポート」を選択します。

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

5. ここをクリックしてLDIFファイルを開きます。
ODSMが実行されているブラウザ・ウィンドウの個別タブに完全なLDIFファイルが表示されます。

6. 書込み可能な場所にLDIFファイルを保存します。

7. 「エントリのエクスポート」ダイアログで「OK」をクリックし、エクスポートを終了します。

18 Oracle Directory Services Managerを使用したOracle Unified Directoryへのアクセス

Oracle Directory Services Manager (ODSM)は、Oracle Unified Directoryのインスタンスを管理するためのインタフェースです。ODSMでは、ディレクトリ構造の構成、ディレクトリ内のオブジェクトの定義、ユーザー、グループおよびその他のエントリの追加と構成ができます。ODSMは、エントリ、スキーマ、セキュリティおよび他のディレクトリ機能を管理するために使用するインタフェースでもあります。

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

- 第18.1項「Oracle Directory Services Managerの起動」

- 第18.2項「Oracle Directory Services Managerからサーバーへの接続」

- 第18.3項「Oracle Directory Services Managerを使用したサーバー情報の表示」

ODSMを使用したOracle Unified Directoryの管理に関するその他の情報は、次の各項で示しています:

- 第14.2項「Oracle Directory Services Managerを使用したサーバー構成の管理」

- 第15.2項「ODSMを使用したプロキシ構成の管理」

- 第17.4.5項「Oracle Directory Services Managerを使用したデータの検索」

- 第17.15項「Oracle Directory Services Managerを使用したデータの管理」

- 第27.6項「Oracle Directory Services Managerを使用したスキーマの管理」

- 第22.3項「Oracle Directory Services Managerによるアクセス制御の管理」

- 第24.5項「Oracle Directory Services Managerを使用したパスワード・ポリシーの構成」

18.1 Oracle Directory Services Managerの起動

ODSMでサポートされているブラウザの詳細は、Oracle Fusion Middleware 11gR2のシステム要件およびサポートされているプラットフォームを参照してください。これにアクセスできるリンクが、http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.htmlに含まれています。

ODSMを起動するには、ブラウザのアドレス・フィールドにURL http://host:port/odsmを入力します。hostは、ODSMが実行されている管理対象サーバーの名前で、portは、管理サーバーの管理対象サーバー・ポート番号です。デフォルトの管理ポートは、7001です。

次の項の説明に従って、サーバーに接続します。

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

次の図は、ODSMのメイン画面の一部を示しています。ここから特定のOracle Unified Directoryインスタンスに接続できます。

図18-1 ODSMの画面

Oracle Unified Directoryインスタンスに接続するには、次の情報を入力します:

- サーバー。接続先のディレクトリ・サーバーの名前を入力します。

- ポート。接続先のディレクトリ・サーバーの管理ポート番号を入力します。

- ユーザー名。ディレクトリへの接続に使用するバインドDNを入力します。

- パスワード。ディレクトリへの接続に使用するバインド・パスワードを入力します。

SSLが有効になっている場合、サーバー証明書を信頼するよう求められます。

注意:

ブラウザの言語設定を変更する場合、新しい設定を使用するにはセッションを更新する必要があります。セッションを更新するには、「URL」フィールドにODSM URLを再入力して[Enter]を押すか、ブラウザを終了して再起動します。

18.3 Oracle Directory Services Managerを使用したサーバー情報の表示

ODSMの各サーバー・インスタンスの「ホーム」タブを使用すると、サーバーに関する特定の情報を表示できます。

この項では、サーバー情報を表示する方法について説明します。この項の内容は次のとおりです:

- 第18.3.1項「バージョン情報の表示」

- 第18.3.2項「サーバー・ロールの表示」

- 第18.3.3項「サーバー統計情報の表示」

- 第18.3.4項「構成済接続ハンドラの表示」

- 第18.3.5項「構成済ネーミング・コンテキストの表示」

- 第18.3.6項「構成済データ・ソースの表示」

18.3.1 バージョン情報の表示

「バージョン情報」パネルには、ODSMインスタンスおよびOracle Unified Directoryインスタンスのバージョン番号、およびJava Runtime Edition (JRE)のバージョンが示されます。

18.3.2 サーバー・ロールの表示

サーバー・ロールは、Oracle Unified Directoryインスタンスが設定された方法に従って、次の1つまたは複数のロールとして指定されます。

- ディレクトリ

- プロキシ

- ロード・バランサ

- ディストリビュータ

- レプリケーション・ゲートウェイ

- レプリケーション・サーバー

詳細は、Oracle Fusion Middleware Oracle Unified Directoryインストレーション・ガイドのサーバー・ロールの選択に関する項を参照してください。

18.3.3 サーバー統計情報の表示

「OUD統計」パネルには、対象のサーバー・インスタンスのインストール詳細および基本的な監視情報が表示されます。次の情報が表示されます:

- サーバー開始時間: サーバーが正常に起動した最新の日時。

- インストール・パス: 対象のサーバー・インスタンスのインストール・ファイルへのネットワーク・パス。

- インスタンス・パス: 対象のサーバー・インスタンスのインスタンス・ファイルへのネットワーク・パス。

- 管理ユーザー: サーバーのセットアップ時に構成されたルート・ユーザー。詳細は、第23章「管理ユーザーの管理」を参照してください。

- 完了したLDAP操作の合計数(/秒) (起動以降): サーバーで実行されたLDAP操作の合計数をサーバーの起動以降に経過した秒数で割った数値。

- 1操作当たりの平均経過時間(起動以降) (ミリ秒): LDAP操作の実行に要した平均時間。

- 接続レート(接続/秒): サーバーで現在処理されている1秒当たりの接続数。

18.3.4 構成済接続ハンドラの表示

「接続ハンドラ」パネルには、対象のサーバー・インスタンスに構成されているすべての接続ハンドラの詳細が、接続ハンドラのタイプ、接続ハンドラがリスニングしているポートおよび接続ハンドラが有効かどうかなどの情報とともに表示されます。

接続ハンドラの詳細は、第14.1.5項「dsconfigを使用した接続ハンドラの構成」および第14.3項「サーバーへの管理トラフィックの管理」を参照してください。

18.3.5 構成済ネーミング・コンテキストの表示

「ネーミング・コンテキスト」パネルには、対象のサーバー・インスタンスに構成されているすべてのネーミング・コンテキスト、つまり接尾辞が表示されます。これには、ネーミング・コンテキストが属しているネットワーク・グループ、ネーミング・コンテキストに含まれるエントリの数およびネーミング・コンテキストがレプリケートされているかどうかの情報が含まれます。

18.3.6 構成済データ・ソースの表示

プロキシ・サーバーの場合、「データ・ソース」パネルには、すべてのデータ・ソース、またはプロキシ・インスタンスを通して管理されているバックエンドLDAPサーバーが表示されます。

19 ユーザーおよびグループの管理

Oracle Unified Directoryは、アイデンティティ・マップおよびアカウント・ステータス通知を含め、包括的なユーザー管理モデルを提供します。この項では、コマンドライン・ユーティリティおよびOracle Directory Services Managerインタフェースを使用して、これらの要素を構成する方法を説明します。

この章の内容は次のとおりです:

- 第19.1項「ユーザー・アカウントの管理」

- 第19.2項「ルート・ユーザーの構成」

- 第19.3項「グループの定義」

- 第19.4項「参照整合性の保持」

- 第19.5項「Oracle Unified DirectoryサーバーでのODSEEロールのシミュレート」

ユーザー・パスワードの詳細は、第24章「パスワード・ポリシーの管理」を参照してください。

19.1 ユーザー・アカウントの管理

ユーザー・アカウントは基本的に、ディレクトリで作成、変更または削除するユーザー・エントリです。

ユーザー・アカウントの管理を開始する前に、ディレクトリ・サーバーに適切なパスワード・ポリシーが設定されていることを確認してください。詳細は、第24章「パスワード・ポリシーの管理」を参照してください。

この項では、manage-accountおよびldappasswordmodifyコマンドライン・ユーティリティを使用して、ユーザー・アカウントおよびパスワードを管理する方法を説明します。この項の内容は次のとおりです:

- 第19.1.1項「パスワードの変更」

- 第19.1.2項「ユーザーのアカウント情報の管理」

- 第19.1.3項「ユーザー・アカウントへのリソース制限の設定」

19.1.1 パスワードの変更

ディレクトリ管理者は、他のユーザーのパスワードの作成、リセットまたは削除を求められることがよくあります。ldappasswordmodifyユーティリティを使用すると、LDAPパスワード変更拡張操作でユーザーのパスワードを変更またはリセットできます。--authzidオプションを使用して、dn:またはu:を接頭辞として付けるか、または完全なDNを指定することによって、認可IDを指定できます。

この項では、パスワードを管理する方法を説明します。この項の内容は次のとおりです:

- 第19.1.1.1項「ディレクトリ・マネージャのパスワードを変更するには」

- 第19.1.1.2項「リセットして、ユーザーの新規パスワードを生成するには」

- 第19.1.1.3項「ユーザーのパスワードを変更するには」

19.1.1.1 ディレクトリ・マネージャのパスワードを変更するには

次の例で示しているように、ldappasswordmodifyコマンドを使用します:

$ ldappasswordmodify -h localhost -p 1389 \
--authzID "dn:cn=Directory Manager" \
--currentPassword mypassword --newPassword mynewpassword

The LDAP password modify operation was successful

19.1.1.2 リセットして、ユーザーの新規パスワードを生成するには

この例では、ユーザーは既存のパスワードを覚えていないことが前提となっています。

次の例で示しているように、ldappasswordmodifyコマンドを使用します:

$ ldappasswordmodify -h localhost -p 1389 -D "cn=Directory Manager" \
-j pwd-file --authzID u:jvedder

The LDAP password modify operation was successful
Generated Password:  evx07npv

19.1.1.3 ユーザーのパスワードを変更するには

この例では、ユーザーは既存のパスワードを覚えていることが前提となっています。新規パスワードは、指定したファイルでサーバーに渡されます。

次の例で示しているように、ldappasswordmodifyコマンドを使用します:

$ ldappasswordmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
--authzID uid=jvedder,ou=People,dc=example,dc=com \
--currentPassword password --newPasswordFile pwdFile

The LDAP password modify operation was successful

19.1.2 ユーザーのアカウント情報の管理

ユーザーのアカウントおよびそのユーザーに適用されているパスワード・ポリシーに関する情報を表示するには、manage-accountコマンドを使用できます。このコマンドを使用して、ユーザーのアカウントを有効または無効にすることもできます。manage-accountコマンドは、管理ポート経由でSSLを使用してサーバーにアクセスします。詳細は、第14.3項「サーバーへの管理トラフィックの管理」を参照してください。

この項では、ユーザーのアカウント情報を管理する方法を説明します。この項の内容は次のとおりです:

- 第19.1.2.1項「ユーザーのアカウント情報を表示するには」

- 第19.1.2.2項「アカウント・スタータス情報を表示するには」

- 第19.1.2.3項「アカウントを無効にするには」

- 第19.1.2.4項「アカウントを有効にするには」

- 第19.1.2.5項「orclIsEnabledを使用してアカウントを有効にするには」

19.1.2.1 ユーザーのアカウント情報を表示するには

manage-accountコマンドは、ユーザー・アカウントに適用されているパスワード・ポリシーのDN、アカウント・ステータス、およびパスワードとログイン関連情報を返します。

1. 特定のユーザー・アカウントに関して入手可能な情報をすべて表示するには、次の例に示しているように、manage-accountコマンドをget-allサブコマンドとともに使用します:

$ manage-account -D "cn=directory manager" -j pwd-file get-all \
--targetDN uid=kvaughan,ou=People,dc=example,dc=com
Password Policy DN:  cn=Default Password Policy,cn=Password Policies,cn=config
Account Is Disabled:  false
Account Expiration Time:
Seconds Until Account Expiration:
Password Changed Time:  19700101000000.000Z
Password Expiration Warned Time:
Seconds Until Password Expiration:  432000
Seconds Until Password Expiration Warning:  0
Authentication Failure Times:
Seconds Until Authentication Failure Unlock:
Remaining Authentication Failure Count:
Last Login Time:
Seconds Until Idle Account Lockout:
Password Is Reset:  false
Seconds Until Password Reset Lockout:
Grace Login Use Times:
Remaining Grace Login Count:  4
Password Changed by Required Time:
Seconds Until Required Change Time:
Password History:

2. 特定のアカウントの1つのプロパティのみを表示するには、get-allサブコマンドのかわりに、表示するプロパティに対応するサブコマンドを使用します。
たとえば、パスワード履歴のみを表示するには、次のコマンドを実行します:

$ manage-account -D "cn=directory manager" -j pwd-file get-password-history \
--targetDN "uid=kvaughan,ou=People,dc=example,dc=com"

サブコマンドの全リストを表示するには、次のコマンドを実行します:

$ manage-account --help

19.1.2.2 アカウント・ステータス情報を表示するには

manage-accountコマンドを使用して、特定のアカウントが有効か無効かを評価できます

次の例で示しているように、manage-accountコマンドをget-account-is-disabledサブコマンドとともに使用します:

$ manage-account -D "cn=directory manager" -j pwd-file get-account-is-disabled \
--targetDN "uid=kvaughan,ou=People,dc=example,dc=com"
Account Is Disabled:  false

19.1.2.3 アカウントを無効にするには

次の例で示しているように、manage-accountコマンドをset-account-is-disabledサブコマンドとともに使用します:

$ manage-account -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X \
set-account-is-disabled --operationValue true \
--targetDN "uid=kvaughan,ou=People,dc=example,dc=com"
Account Is Disabled:  true

19.1.2.4 アカウントを有効にするには

次の例で示しているように、manage-accountコマンドをclear-account-is-disabledサブコマンドとともに使用します:

$ manage-account -D "cn=directory manager" -j pwd-file clear-account-is-disabled \
--targetDN "uid=kvaughan,ou=People,dc=example,dc=com"
Account Is Disabled:  false

19.1.2.5 orclIsEnabledを使用してアカウントを有効にするには

orclIsEnabledを使用してOracle Unified Directoryを有効にするには、次の手順を実行します:

1. 次のように新規ワークフロー要素を作成して有効にします:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n /
create-workflow-element --element-name fawe --type fa \
--set enabled:true --set next-workflow-element:userRoot

2. 次のように、新規ワークフロー要素をデフォルトのワークフローに割り当てます:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n /
set-workflow-prop --workflow-name userRoot0 --set workflow-element:fawe

19.1.3 ユーザー・アカウントへのリソース制限の設定

リソース制限をエントリに割り当てることによって、クライアント・アカウントごとにサーバー上での検索操作を制御できます。リソース制限は、特定の操作属性をユーザー・エントリに追加することによって割り当てられます。その上で、ディレクトリ・サーバーで、クライアントがディレクトリへのバインドに使用するアカウントに基づいて制限が施行されます。

特定のユーザー・アカウントに対して設定したリソース制限は、サーバー規模の構成で設定したリソース制限より優先されます。リソース制限の構成可能なプロパティすべての詳細は、Oracle Unified Directory構成リファレンスのグローバル構成に関する項を参照してください。

設定できる制限は次のとおりです:

- 検索制限。検索操作で調べるエントリの最大数が指定されます。ds-rlim-lookthrough-limit操作属性を使用します。

- サイズ制限。検索操作のレスポンスとして返されるエントリの最大数が指定されます。ds-rlim-size-limit操作属性を使用します。

- 時間制限。検索操作の処理に費やせる最大時間が指定されます。ds-rlim-time-limit操作属性を使用します。

注意:

デフォルトで、ディレクトリ・マネージャでは無制限にリソースを使用できます。

19.1.3.1 アカウントにリソース制限を設定するには

1. 次に示しているように、操作属性を追加することによって、LDIFファイル内のエントリを変更します:

dn: uid=kvaughan,ou=people,dc=example,dc=com
changetype: modify
add: ds-rlim-lookthrough-limit
ds-rlim-lookthrough-limit: 1000
-
add: ds-rlim-size-limit
ds-rlim-size-limit: 500
-
add: ds-rlim-time-limit
ds-rlim-time-limit: 300

2. 次に示しているように、ldapmodifyコマンドを使用して、変更を適用します:

$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
--filename add_resource.ldif
Processing MODIFY request for uid=kvaughan,ou=people,dc=example,dc=com
MODIFY operation successful for DN uid=kvaughan,ou=people,dc=example,dc=com

19.2 ルート・ユーザーの構成

ルート・ユーザーは、アクセス制御および通常のユーザーに施行されている可能性のあるその他の制限をバイパスできるアカウントを持つ特別なユーザーです。複数のルート・ユーザーを定義して、各ルート・ユーザーに個別の資格証明セットを指定し、ファイングレイン・レベルでアクセスを制御できます。たとえば、特定のタスクに対するルート・アクセス権が必要だが、完全なルート・ユーザー権限セットは必要ではないユーザーに権限を割り当てることができます。各ルート・ユーザーが独自の強固な認証メカニズム(GSSAPI SASLなど)、固有のパスワード・ポリシーおよび独自のリソース制限を持つように各ルート・ユーザーを構成できます。

デフォルトで、一連のグローバル・ルート・ユーザー権限が定義されます。これらの権限は、ルート・ユーザー・エントリの権限を変更しないかぎり、デフォルトのルート・ユーザーを含めて、すべての構成済ルート・ユーザーに適用されます。すべてのルート・ユーザーに継承されるグローバル・ルート・ユーザー権限を変更できます。

セットアップ・プロセス中に、完全な管理権限を持つデフォルトのルート・ユーザーが作成されます。このルート・ユーザーに対してセットアップで提示されるDNは"cn=directory manager"であるため、セットアップで提示されるデフォルト値を変更しないと、DNが"cn=directory manager,cn=Root DNs,cn=config"のルート・ユーザーが構成されます。

次の各項で説明している各プロシージャを使用して、ルート・ユーザーおよびその権限を管理できます。

19.2.1 コマンドライン・ユーティリティを使用したルート・ユーザーの構成

dsconfigコマンドを使用して、グローバル・ルート・ユーザーのプロパティを表示および編集できます。追加のルート・ユーザーを作成および管理するには、ldapmodifyコマンドを使用して、ユーザー・エントリをサーバー構成に追加する必要があります。次の各項では、コマンドラインを使用してルート・ユーザーを管理する方法を説明します。

- 第19.2.1.1項「グローバル・ルート・ユーザーの権限を変更するには」

- 第19.2.1.2項「新規ルート・ユーザーを作成するには」

- 第19.2.1.3項「既存のルート・ユーザーを編集するには」

19.2.1.1 グローバル・ルート・ユーザーの権限を変更するには

グローバル・ルート・ユーザーの権限を表示するには、次のdsconfigコマンドを実行します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
get-root-dn-prop
Property                    : Value(s)
----------------------------:--------------------------------------------------
default-root-privilege-name : backend-backup, backend-restore, bypass-acl,
: bypass-lockdown, cancel-request, config-read,
: config-write, disconnect-client, ldif-export,
: ldif-import, modify-acl, password-reset,
: privilege-change, server-restart,
: server-shutdown, subentry-write,
: unindexed-search, update-schema

グローバル・ルート・ユーザーの権限を変更するには、dsconfig set-root-dn-propコマンドを--addオプションまたは--removeオプションを指定して実行します。

次の例では、サーバーでのバックアップまたはリストア操作を実行するための、ルート・ユーザーのデフォルトの権限が削除されます。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
set-root-dn-prop --remove default-root-privilege-name:backend-backup \
--remove default-root-privilege-name:backend-restore

権限の全リストおよび各権限の説明は、第10.2項「特権サブシステム」を参照してください。

19.2.1.2 新規ルート・ユーザーを作成するには

新規ルート・ユーザーを作成するには、LDIFファイルにユーザー・エントリを作成してから、ldapmodifyコマンドを使用して、そのエントリをサーバー構成のcn=Root DNs,cn=configブランチに追加します。

cn=config接尾辞は、管理接尾辞であるため、管理コネクタを使用して評価する必要があります。詳細は、第14.3項「サーバーへの管理トラフィックの管理」を参照してください。

たとえば、特定のユーザーにデータベースのバックアップおよびリストアを行う権限を付与するが、その他の管理権限は付与しない場合、次のように実行します。

1. 適切な権限が指定されたルート・ユーザー・エントリを定義するLDIFファイルを作成します。
次のサンプルのLDIFファイル(add-backup-admin.ldif)では、サーバー構成でこれらの権限を持つがその他の権限は持たない、DNが"cn=backup-admin"のルート・ユーザーが定義されます。

dn: cn=backup-admin,cn=Root DNs,cn=config
changetype: add
objectClass: person
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: ds-cfg-root-dn-user
objectClass: top
cn: backup-admin
sn: backup-admin
ds-cfg-alternate-bind-dn: cn=backup-admin
userPassword: secret
ds-privilege-name: backend-backup
ds-privilege-name: backend-restore
ds-privilege-name: -bypass-acl
ds-privilege-name: -bypass-lockdown
ds-privilege-name: -cancel-request
ds-privilege-name: -config-read
ds-privilege-name: -config-write
ds-privilege-name: -disconnect-client
ds-privilege-name: -ldif-export
ds-privilege-name: -ldif-import
ds-privilege-name: -modify-acl
ds-privilege-name: -password-reset
ds-privilege-name: -privilege-change
ds-privilege-name: -server-restart
ds-privilege-name: -server-shutdown
ds-privilege-name: -subentry-write
ds-privilege-name: -unindexed-search
ds-privilege-name: -update-schema

2. ldapmodifyコマンドを--useSSLオプションを指定して使用し、このLDIFファイルをサーバー構成に追加します。

$ ldapmodify -h localhost -p 4444 -D "cn=directory manager" -j pwd-file \
--useSSL -X -f add-backup-admin.ldif

権限の全リストおよび各権限の説明は、第10.2項「特権サブシステム」を参照してください。

19.2.1.3 既存のルート・ユーザーを編集するには

既存のルート・ユーザーを編集するには、ldapmodifyコマンドを使用して、サーバー構成のcn=Root DNs,cn=configブランチにあるユーザー・エントリの属性を変更します。

cn=config接尾辞は、管理接尾辞であるため、管理コネクタを使用して評価する必要があります。詳細は、第14.3項「サーバーへの管理トラフィックの管理」を参照してください。

次の例では、前述の例で作成したルート・ユーザーのリストア操作を実行する機能が削除されます。

$ ldapmodify -h localhost -p 4444 -D "cn=directory manager" -j pwd-file \
--useSSL -X
dn: cn=backup-admin,cn=root DNs,cn=config
changetype: modify
delete: ds-privilege-name
ds-privilege-name: backend-restore

19.2.2 ODSMを使用したルート・ユーザーの構成

ODSMインタフェースを使用して、デフォルトのルート・ユーザーを表示および編集したり、追加のルート・ユーザーを作成および管理したりできます。この項の内容は次のとおりです:

- 第19.2.2.1項「グローバル・ルート・ユーザーの権限の構成」

- 第19.2.2.2項「新規ルート・ユーザーの作成」

- 第19.2.2.3項「既存のルート・ユーザーの編集」

19.2.2.1 グローバル・ルート・ユーザーの権限の構成

デフォルトで、一連のグローバル・ルート・ユーザー権限が定義されます。これらの権限は、ルート・ユーザー・エントリの権限を変更しないかぎり、すべての構成済ルート・ユーザーに適用されます。

ODSMを使用してグローバル・ルート・ユーザーの権限を変更するには、次の手順に従います:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「構成」タブを選択します。

3. 「一般構成」項目の「ルート・ユーザー」を選択します。
右側のペインに、グローバル・ルート・ユーザーの権限が表示されます。

権限の横のチェック・マークは、ルート・ユーザーにその権限がデフォルトで付与されていることを示します。

4. グローバル・ルート・ユーザーの権限のリストに権限を追加するには、追加する権限の横のチェック・ボックスを選択します。
権限を削除するには、その権限の横のチェック・ボックスを選択解除します。

権限の全リストおよび各権限の説明は、第10.2項「特権サブシステム」を参照してください。

5. 必要な変更を加えたら、「適用」をクリックします。

19.2.2.2 新規ルート・ユーザーの作成

次のように、ODSMを使用して新規ルート・ユーザーを作成できます:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「構成」タブを選択します。

3. 「作成」メニューから、「ルート・ユーザー」を選択します。

4. 「一般プロパティ」リージョンで、次の詳細を入力します:

1. 「名前」フィールドに、作成するルート・ユーザーの名前を入力します。

2. 「代替バインドDN」リージョンで、「追加」をクリックして、対象のルート・ユーザーがサーバーにバインドする際に使用可能な1つ以上の代替DNを指定します。
たとえば、デフォルトのルート・ユーザーの代替バインドDNは、"cn=Directory Manager"です。これを使用すると、実際のエントリDNである"cn=Directory Manager,cn=Root DNs,cn=config"を使用する必要なく、"cn=Directory Manager"としてバインドできます。

代替バインドDNは、すべてのルート・ユーザーにおいて一意である必要があります。

新規ルート・ユーザーに代替バインドDNを指定しない場合は、表を空のままにしておきます。

3. 「パスワード」フィールドに、このルート・ユーザーのパスワードを入力します。

4. 「パスワードの確認」フィールドに、このルート・ユーザーのパスワードを再入力します。

5. 「特権」リージョンで、この新規ルート・ユーザーに適用する必要のある様々な権限の設定を選択します。
権限ごとに、次のいずれかを選択できます:

- Enable: このルート・ユーザーに対して、この権限を有効にします。

- Disable: このルート・ユーザーに対して、この権限を無効にします。

- Default Privilege (enable)またはDefault Privilege (disable): グローバル権限構成で定義されているとおりに、ユーザーは、この権限のデフォルトの設定を継承します。

6. 「作成」をクリックします。
次の確認メッセージが表示されます:

ルート・ユーザーは正常に作成されました。

19.2.2.3 既存のルート・ユーザーの編集

次のように、ODSMを使用して、既存のルート・ユーザーを編集できます:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「構成」タブを選択します。

3. 「一般構成」項目の「ルート・ユーザー」項目を開きます。

4. 構成を変更するルート・ユーザーを選択します。
右側のペインに、対象のルート・ユーザーのプロパティが表示されます。

5. 必要なプロパティを編集して、「適用」をクリックします。

6. 新しい構成の保存を求められます。「はい」をクリックします。

19.3 グループの定義

Oracle Unified Directoryでは、単一オブジェクトとして管理可能な、エントリのコレクションであるグループがサポートされます。通常、ディレクトリ管理者は、プリンタのグループ、ソフトウェア・アプリケーションのグループ、従業員のグループなどを構成します。グループは、一連のユーザーに特別なアクセス権を割り当てる場合に特に有用です。たとえば、アクセス・マネージャに、従業員データに対する権限を割り当てる一方で、これらの同じ権限を社内の他のユーザーに対しては制限することができます。

次のグループ・タイプがサポートされています:

- 静的グループ: 静的グループでは、groupOfNames、groupOfUniqueNamesまたはgroupOfEntriesオブジェクト・クラスを使用して、識別名(DN)の明示的セットを指定することによって、メンバーシップが定義されます。静的グループは、外部クライアントで適切にサポートされ、良好なパフォーマンスを実現します。
静的グループの短所は、グループのメンバーシップが増加するにつれ、簡単だったデータの管理がだんだん難しくなっていくことです。変更されるエントリごとに、その変更されたエントリが含まれるすべてのグループも変更する必要があります。このタスクは、グループのメンバーの数が多くなるにつれ、難しくなっていきます。このため、静的グループは、あまり頻繁には変更されない比較的小規模のグループに使用することが最適です。

詳細は、第19.3.1項「静的グループの定義」を参照してください。

- 動的グループ: 動的グループでは、groupOfUrlsオブジェクト・クラスを使用して、LDAP URLの形式で一連の検索基準を使用し、グループのメンバーシップが定義されます。静的グループと比較して、動的グループでは、多数のメンバー(数百万のエントリ)が適切に処理されます。エントリが更新されると、すべての親グループが自動的に更新されます。
動的グループの短所は、一部のクライアントでサポートされないことです。また、エントリの全リストに問合せを実行する必要がある場合、パフォーマンスに悪影響を与えます。このため、動的グループは、エントリ数が多大なグループの場合、または1つのエントリに対して特定のグループ・メンバーシップを指定する必要があるクライアントの場合に最適です。

詳細は、第19.3.2項「動的グループの定義」を参照してください。

- 仮想静的グループ: 仮想静的グループは、各メンバーが、別の動的グループからその場でメンバーシップを定義する仮想属性によって表されることを除いて、外部クライアントに対して静的グループと外観および動作が同様です。仮想静的グループは、多数のエントリを管理しつつ、静的グループのみをサポートするクライアントのスケーラビリティの問題を回避する効率的な方法を提供します。

- 詳細は、第19.3.3項「仮想静的グループの定義」を参照してください。

19.3.1 静的グループの定義

静的グループは、エントリに明示的なDNのメンバーシップ・リストが含まれるグループです。多くのクライアントで静的グループがサポートされますが、グループ内のメンバー数が多くなってくると、静的グループの管理は難しくなってきます。たとえば、DN変更が必要なメンバー・エントリがある場合、そのエントリの所属先の各グループのユーザーDNを変更する必要があります。

静的グループには明示的なメンバーDNのリストが含まれるため、メンバーシップ・リストが大きくなると、データベースのフットプリントも大きくなります。このため、静的グループは、エントリが頻繁には変更されない小規模のグループ(10,000未満)に最適です。大規模な静的グループを使用すると、パフォーマンスに有害な影響を与える可能性があります。グループ・メンバーシップ数が10,000を超えることがわかっている場合は、かわりに動的グループの使用を検討してください。

ディレクトリ・サーバーでは、使用するオブジェクト・クラスに応じて分類された、次の3つのタイプの静的グループがサポートされます:

- groupOfNames: groupOfNamesオブジェクト・クラスを使用し、member属性を使用してメンバーDNを明示的に指定することによって、静的グループを定義できます。

注意:

RFC 4519(https://opends.dev.java.net/public/standards/rfc4519.txt)では、groupOfNamesオブジェクト・クラス内でmember属性を必須とすることが求められます。従来、このメンバーシップ要件によって、管理者がグループ内の最後のメンバーを削除しようとしたときにデータ管理上の問題が発生します。ディレクトリ・サーバーでは、member属性をオプションにできるため、この問題が解決されます。このオプションのメンバーシップ要件では、グループの最後のメンバーを削除するときに、オブジェクト・クラスを空にできます。

dn: cn=Example Static Group 1,ou=Groups,dc=example,dc=com
objectClass: top
objectClass: groupOfNames
member: uid=user1,ou=People,dc=example,dc=com
member: uid=user2,ou=People,dc=example,dc=com
cn: Example Static Group 1

- groupOfUniqueNames: groupOfUniqueNamesオブジェクト・クラスを使用し、uniqueMember属性を使用してメンバーDNを明示的に指定することによって、静的グループを定義できます。groupOfUniqueNamesオブジェクト・クラスでは、groupOfNamesオブジェクト・クラスとは異なり、一意のDNに加えてオプションの識別子を指定することによって、グループのメンバーを列挙できます。この識別子によって、いずれかのオブジェクトを追加、削除または名前変更したときに一意のオブジェクトを必ず識別できるようになります。
たとえば、従業員(cn=Tom Smith)を削除して、名前(cn=Tom Smith)が同じ新規従業員をディレクトリに追加するとします。2人を区別するには、ビット文字列を使用して個別の識別子を追加する必要があります。次の例では、2人のユーザーの名前は同じですが、2番目のuniqueMemberにはオプションの識別子が指定されています。

uniqueMember: uid=tsmith,ou=People,dc=example,dc=com
uniqueMember: uid=tsmith,ou=People,dc=example,dc=com#'0111101'B

注意:

実際にオプションのUID識別子を使用するLDAPアプリケーションはほとんどありません。

RFC 4519(https://opends.dev.java.net/public/standards/rfc4519.txt)では、groupOfUniqueNamesオブジェクト・クラス内にuniqueMember属性を必須とすることが求められます。以前より、このメンバーシップ要件は、管理者がグループ内の最後のメンバーを削除しようとした際にデータ管理上の問題を引き起こす要因となっています。Oracle Unified Directoryでは、uniqueMember属性をオプションにすることによって、この問題が解決されます。このオプションのメンバーシップ要件では、グループの最後のメンバーを削除するときに、オブジェクト・クラスを空にできます。

dn: cn=Example Static Group 2,ou=Groups,dc=example,dc=com
objectClass: top
objectClass: groupOfUniqueNames
uniqueMember: uid=user1,ou=People,dc=example,dc=com
uniqueMember: uid=user2,ou=People,dc=example,dc=com
cn: Example Static Group 2

- groupOfEntries: groupOfEntriesオブジェクト・クラスを使用して、静的グループを定義できます。元の仕様(RFC 4519 (http://www.rfc-editor.org/rfc/rfc4519.txt)およびdraft-findlay-ldap-groupofentries-00.txt(http://ietfreport.isoc.org/idref/draft-findlay-ldap-groupofentries/) (2008年3月に失効))に基づいて、groupOfEntriesオブジェクト・クラスは、groupOfNamesおよびgroupOfUniqueNamesオブジェクト・クラスとは、属性がオプションである点において異なっています。これによって、メンバーが含まれない空のオブジェクト・クラスを指定できます。

注意:

Oracle Unified Directoryでは、groupOfEntriesドラフトがサポートされますが、空のgroupOfNamesおよびgroupOfUniqueNamesオブジェクト・クラスも使用できます。このため、任意のタイプ(groupOfEntries、groupOfNamesおよびgroupOfUniqueNames)の空のグループを作成できます。

dn: cn=Example Static Group 3,ou=Groups,dc=example,dc=com
objectClass: top
objectClass: groupOfEntries
cn: Example Static Group 3

この項には次のトピックが含まれます:

- 第19.3.1.1項「groupOfNamesを使用して静的グループを作成するには」

- 第19.3.1.2項「groupOfUniqueNamesを使用して静的グループを作成するには」

- 第19.3.1.3項「groupOfEntriesを使用して静的グループを作成するには」

- 第19.3.1.4項「静的グループのすべてのメンバーをリストするには」

- 第19.3.1.5項「ユーザーがメンバーになっているすべての静的グループをリストするには」

- 第19.3.1.6項「ユーザーがグループのメンバーかどうかを確認するには」

19.3.1.1 groupOfNamesを使用して静的グループを作成するには

1. LDIFに、グループ名(cn)およびgroupOfNamesオブジェクト・クラスを含めたグループ・エントリを作成します。
次の例は、新規グループを定義するstatic-group1.ldifという名前のLDIFファイルを示しています。

dn: cn=Directory Administrators,ou=Groups,dc=example,dc=com
cn: Directory Administrators
objectclass: top
objectclass: groupOfNames
ou: Groups
member: uid=ttully,ou=People,dc=example,dc=com
member: uid=charvey,ou=People,dc=example,dc=com
member: uid=rfisher,ou=People,dc=example,dc=com

2. ldapmodifyを使用してグループを追加し、このLDIFファイルを適用します。

$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
--defaultAdd --filename static-group1.ldif
Processing ADD request for cn=Directory Administrators,ou=Groups,dc=example,dc=com
ADD operation successful for DN cn=Directory
Administrators,ou=Groups,dc=example,dc=com

19.3.1.2 groupOfUniqueNamesを使用して静的グループを作成するには

1. LDIFに、グループ名(cn)およびgroupOfUniqueNamesオブジェクト・クラスを含めたグループ・エントリを作成します。
次の例は、新規グループを定義するstatic-group2.ldifという名前のLDIFファイルを示しています。

dn: cn=Directory Administrators2,ou=Groups,dc=example,dc=com
cn: Directory Administrators2
objectclass: top
objectclass: groupOfUniqueNames
ou: Groups
uniquemember: uid=alangdon,ou=People,dc=example,dc=com
uniquemember: uid=drose,ou=People,dc=example,dc=com
uniquemember: uid=polfield,ou=People,dc=example,dc=com

2. ldapmodifyを使用してグループを追加し、このLDIFファイルを適用します。

$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
--defaultAdd --filename static-group2.ldif

3. ldapsearchおよびisMemberOf属性を使用して変更を確認します。

$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
--baseDN dc=example,dc=com "(uid=rdaugherty)" isMemberOf
dn: uid=alangdon,ou=People,dc=example,dc=com
isMemberOf: cn=Directory Administrators2,ou=Groups,dc=example,dc=com

19.3.1.3 groupOfEntriesを使用して静的グループを作成するには

1. LDIFに、グループ名(cn)およびgroupOfEntriesオブジェクト・クラスを含めたグループ・エントリを作成します。
次の例は、新規グループを定義するstatic-group3.ldifという名前のLDIFファイルを示しています。

dn: cn=Directory Administrators3,ou=Groups,dc=example,dc=com
cn: Directory Administrators3
objectclass: top
objectclass: groupOfEntries
ou: Groups
member: uid=bfrancis,ou=People,dc=example,dc=com
member: uid=tjames,ou=People,dc=example,dc=com
member: uid=bparker,ou=People,dc=example,dc=com

2. ldapmodifyを使用してグループを追加し、このLDIFファイルを適用します。

$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
--defaultAdd --filename static-group3.ldif

3. ldapsearchおよびisMemberOf属性を使用して変更を確認します。

$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
--baseDN dc=example,dc=com "(uid=bparker)" isMemberOf
dn: uid=bparker,ou=People,dc=example,dc=com
isMemberOf: cn=Directory Administrators3,ou=Groups,dc=example,dc=com

19.3.1.4 静的グループのすべてのメンバーをリストするには

グループの検索に、isMemberOf仮想属性を使用できます。この属性は、検索の開始時にユーザー・エントリに追加され、検索の終了後に削除されます。この機能によって、読取りアクセスが高速になり、グループの管理が容易になります。

仮想属性isMemberOfとともに、ldapsearchコマンドを使用します。

次の例では、Accounting Managersというグループのメンバーとなっているすべてのユーザーが検索されます。

$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
-b dc=example,dc=com \
"(isMemberOf=cn=Accounting Managers,ou=Groups,dc=example,dc=com)"
dn: uid=scarter,ou=People,dc=example,dc=com
objectClass: person
objectClass: inetOrgPerson
objectClass: top
objectClass: organizationalPerson
ou: Accounting
ou: People
sn: Carter
facsimiletelephonenumber: +1 408 555 9751
roomnumber: 4612
userpassword: {SSHA}3KiJ51sx2Ug7DxZoq0vA9ZY6uaomevbJUBm7OA==
l: Sunnyvale
cn: Sam Carter
telephonenumber: +1 408 555 4798
givenname: Sam
uid: scarter
mail: scarter@example.com
dn: uid=tmorris,ou=People,dc=example,dc=com
objectClass: person
objectClass: inetOrgPerson
objectClass: top
objectClass: organizationalPerson
ou: Accounting
ou: People
sn: Morris
facsimiletelephonenumber: +1 408 555 8473
roomnumber: 4117
userpassword: {SSHA}bjFFHv6k1kbI6fZoCEfqmTj9XOZxWR06gxpKpQ==
l: Santa Clara
cn: Ted Morris
telephonenumber: +1 408 555 9187
givenname: Ted
uid: tmorris
mail: tmorris@example.com

19.3.1.5 ユーザーがメンバーになっているすべての静的グループをリストするには

次の例で示しているように、ldapsearchおよび仮想属性isMemberOfを使用して検索します:

$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
-b dc=example,dc=com "(uid=scarter)" isMemberOf
dn: uid=scarter,ou=People,dc=example,dc=com
isMemberOf: cn=Accounting Managers,ou=groups,dc=example,dc=com

19.3.1.6 ユーザーがグループのメンバーかどうかを確認するには

次の例で示しているように、ldapsearchを使用して検索します:

$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
-b "cn=Account Managers,ou=Groups,dc=example,dc=com" \
"(&(objectclass=groupOfUniqueNames) \
(uniquemember=uid=scarter,ou=People,dc=example,dc=com))"
dn: cn=Accounting Managers,ou=groups,dc=example,dc=com
objectClass: groupOfUniqueNames
objectClass: top
ou: groups
description: People who can manage accounting entries
cn: Accounting Managers
uniquemember: uid=scarter, ou=People, dc=example,dc=com
uniquemember: uid=tmorris, ou=People, dc=example,dc=com

19.3.2 動的グループの定義

動的グループは、メンバーシップがリストで明示的に保持されるのではなく、LDAP URLを使用して検索基準によって決定されるグループです。たとえば、dc=example,dc=comネーミング・コンテキスト内のすべてのマネージャに電子メールを送信するとします。これを行うには、cn=Managers,ou=Groups,dc=example,dc=comと指定した動的グループを作成します。また、電子メール・アドレスのみが返されるように指定します。電子メール・アプリケーションから特定グループのディレクトリの問合せがあると、ディレクトリ・サーバーでは、メンバーシップが動的に計算され、対応する電子メール・アドレスのリストが返されます。

動的グループでは、groupOfURLsオブジェクト・クラスおよびmemberURL属性を使用して、LDAP URLおよびグループのメンバーの特定に使用する基準(検索ベース、スコープおよびフィルタ)が定義されます。ユーザーが動的グループのメンバーかどうかを判別するメカニズムは、定数時間の操作であるため、メンバーが数百万のグループを複数対象とする場合でも、メンバーが数個のグループを1つのみ対象とする場合と同じく効率的に実行されます。ただし、大量のデータに対して検索を行う場合はパフォーマンスに悪影響を及ぼす可能性があるため、検索基準を指定する際には注意が必要です。

図19-1 動的グループの構造

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

- 第19.3.2.1項「動的グループを作成するには」

- 第19.3.2.2項「動的グループのすべてのメンバーをリストするには」

- 第19.3.2.3項「ユーザーがメンバーになっているすべての動的グループをリストするには」

- 第19.3.2.4項「ユーザーが動的グループのメンバーかどうかを確認するには」

19.3.2.1 動的グループを作成するには

1. グループを指定するLDIFファイルを作成します。
次の例では、Cupertinoに配置されている従業員の動的グループが指定されます。

dn: cn=cupertinoEmployees,ou=Groups,dc=example,dc=com
cn: CupertinoEmployees
objectclass: top
objectclass: groupOfURLs
ou: Groups
memberURL: ldap:///ou=People,dc=example,dc=com??sub?(l=Cupertino)

2. ldapmodifyを使用してグループを追加し、LDIFファイルを処理します。

$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
--defaultAdd --filename dynamic_group.ldif
Processing ADD request for cn=cupertionEmployees,ou=Groups,dc=example,dc=com
ADD operation successful for DN cn=cupertionEmployees,ou=Groups,dc=example,dc=com

19.3.2.2 動的グループのすべてのメンバーをリストするには

次のプロシージャでは、仮想属性isMemberOfが使用されています。ディレクトリ・サーバーのパフォーマンスに悪影響を与えるため、このプロシージャは非常に大規模なグループには使用しないでください。

ldapsearchおよび仮想属性isMemberOfを使用して検索します。

$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
-b "dc=example,dc=com" \
"(isMemberOf=cn=cupertinoEmployees,ou=Groups,dc=example,dc=com)"
dn: uid=abergin,ou=People,dc=example,dc=com
objectClass: person
objectClass: inetOrgPerson
objectClass: top
objectClass: organizationalPerson
ou: Product Testing
ou: People
sn: Bergin
facsimiletelephonenumber: +1 408 555 7472
roomnumber: 3472
userpassword: {SSHA}YcDl0pHLxkd/ouW2jslAk1XaT5SiY4ium5qh8w==
l: Cupertino
cn: Andy Bergin
telephonenumber: +1 408 555 8585
givenname: Andy
uid: abergin
mail: abergin@example.com
...(more entries)...

19.3.2.3 ユーザーがメンバーになっているすべての動的グループをリストするには

ldapsearchおよび仮想属性isMemberOfを使用して検索します。

$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
-b dc=example,dc=com "(uid=abergin)" isMemberOf
dn: uid=abergin,ou=People,dc=example,dc=com
isMemberOf: cn=QA Managers,ou=groups,dc=example,dc=com
isMemberOf: cn=cupertinoEmployees,ou=Groups,dc=example,dc=com

19.3.2.4 ユーザーが動的グループのメンバーかどうかを確認するには

ldapsearchおよび仮想属性isMemberOfを使用して検索します。

$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
-b dc=example,dc=com \
"(&(uid=abergin)(isMemberOf=cn=cupertinoEmployees,ou=Groups,dc=example,dc=com))"
dn: uid=abergin,ou=People,dc=example,dc=com
objectClass: person
objectClass: inetOrgPerson
objectClass: top
objectClass: organizationalPerson
ou: Product Testing
ou: People
sn: Bergin
facsimiletelephonenumber: +1 408 555 7472
roomnumber: 3472
userpassword: {SSHA}YcDl0pHLxkd/ouW2jslAk1XaT5SiY4ium5qh8w==
l: Cupertino
cn: Andy Bergin
telephonenumber: +1 408 555 8585
givenname: Andy
uid: abergin
mail: abergin@example.com

19.3.3 仮想静的グループの定義

仮想静的グループでは、静的グループのみをサポートするクライアントのスケーラビリティが効率的に管理されます。仮想静的グループでは、各エントリが仮想属性を使用することによって静的グループのように動作します。次の図で示しているように、仮想属性は、起動時に動的に指定され、グループ・メンバーシップを指定する操作が動的グループなどの別のグループに渡されます。

図19-2 仮想静的グループ

仮想静的グループには、groupOfNamesまたはgroupOfUniqueNamesオブジェクト・クラスを含める必要がありますが、memberまたはuniqueMember属性を含めてはいけません。仮想静的グループには、ds-virtual-static-group補助オブジェクト・クラスおよびds-target-group-dn属性も含める必要があります。ds-target-group-dn属性は、実際のグループを参照して、仮想静的グループとしてミラー化するために使用され、memberまたはuniquemember属性のかわりに使用されます。例:

dn: cn=Example Virtual Static Group,ou=Groups,dc=example,dc=com
objectClass: top
objectClass: groupOfUniqueNames
objectClass: ds-virtual-static-group
cn: Example Virtual Static Group
ds-target-group-dn: cn=Example Real Group,ou=Groups,dc=example,dc=com

仮想静的グループは、アプリケーションでメンバーシップ属性をターゲットとした検索が実行されるが、実際にはメンバー・セット全体は取得されない場合に最も効率的です。一般的に、アプリケーションでは次のようなフィルタを使用して、ユーザーが、指定のグループのメンバーかどうかの判別が試行されます:

(&(objectClass=groupOfUniqueNames)(uniqueMember=uid=john.doe,\
ou=People,dc=example,dc=com))

メンバー・セットを取得するアプリケーションでは、完全なメンバー・リストを構築するプロセスで負荷がかかる可能性があるため、仮想静的グループは理想的ではない場合があります。

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

- 第19.3.3.1項「仮想静的グループを作成するには」

- 第19.3.3.2項「仮想静的グループのすべてのメンバーをリストするには」

- 第19.3.3.3項「ユーザーがメンバーになっているすべての仮想静的グループをリストするには」

- 第19.3.3.4項「ユーザーが仮想静的グループのメンバーかどうかを確認するには」

19.3.3.1 仮想静的グループを作成するには

1. グループを指定するLDIFファイルを作成します。
次のサンプル・ファイルvirtual-static.ldifでは、cupertinoEmployeesという名前の仮想静的グループが指定されます。

dn: cn=virtualStatic,ou=Groups,dc=example,dc=com
cn: Virtual Static
objectclass: top
objectclass: groupOfUniqueNames
objectclass: ds-virtual-static-group
ou: Groups
ds-target-group-dn: cn=cupertinoEmployees,ou=Groups,dc=example,dc=com

2. ldapmodifyを使用してグループを追加し、LDIFファイルを処理します。

$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
--defaultAdd --filename virtual-static.ldif
Processing ADD request for cn=virtualStatic,ou=Groups,dc=example,dc=com
ADD operation successful for DN cn=virtualStatic,ou=Groups,dc=example,dc=com

19.3.3.2 仮想静的グループのすべてのメンバーをリストするには

仮想静的グループの使用は、検索のターゲットがメンバーシップ属性の場合に最適です。このため、次のプロシージャはお薦めできませんが、リストにアクセスする方法を示すために記載しています。

この例では、前の例で作成した動的グループcupertinoEmployeesが使用されています。

ldapsearchおよび仮想属性isMemberOfを使用して検索します。

$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
-b dc=example,dc=com "(isMemberOf=cn=virtualStatic,ou=Groups,dc=example,dc=com)"
dn: uid=abergin,ou=People,dc=example,dc=com
objectClass: person
objectClass: inetOrgPerson
objectClass: top
objectClass: organizationalPerson
ou: Product Testing
ou: People
sn: Bergin
facsimiletelephonenumber: +1 408 555 7472
roomnumber: 3472
userpassword: {SSHA}YcDl0pHLxkd/ouW2jslAk1XaT5SiY4ium5qh8w==
l: Cupertino
cn: Andy Bergin
telephonenumber: +1 408 555 8585
givenname: Andy
uid: abergin
mail: abergin@example.com
...(more entries)...

19.3.3.3 ユーザーがメンバーになっているすべての仮想静的グループをリストするには

ldapsearchおよび仮想属性isMemberOfを使用して検索します。

$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
-b dc=example,dc=com "(uid=abergin)" isMemberOf
dn: uid=abergin,ou=People,dc=example,dc=com
isMemberOf: cn=QA Managers,ou=groups,dc=example,dc=com
isMemberOf: cn=cupertinoEmployees,ou=Groups,dc=example,dc=com
isMemberOf: cn=virtualStatic,ou=Groups,dc=example,dc=com

19.3.3.4 ユーザーが仮想静的グループのメンバーかどうかを確認するには

ldapsearchおよびuniqueMember属性を使用して検索します。

$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
-b "cn=virtualStatic,ou=Groups,dc=example,dc=com" \
"(&(objectclass=groupOfUniqueNames) \
(uniquemember=uid=abergin,ou=People,dc=example,dc=com))"
dn: cn=virtualStatic,ou=Groups,dc=example,dc=com
objectClass: groupOfUniqueNames
objectClass: top
objectClass: ds-virtual-static-group
ou: Groups
ds-target-group-dn: cn=cupertinoEmployees,ou=Groups,dc=example,dc=com
cn: Virtual Static
cn: virtualStatic

19.3.4 ネストされたグループの定義

グループをネストすることができます。その場合、DNが別のグループ(親)内にリストされる子グループ・エントリとして、1つのグループが定義されます。グループをネストすると、パフォーマンスが優先されない場合に、継承グループ・メンバーシップを設定できます。0個以上のメンバー属性を、静的グループおよび動的グループを含め、ネストされた子グループのDNにそのメンバー属性の値を設定して追加できます。

図19-3 ネストされた静的グループ

19.3.4.1 ネストされたグループを作成するには

このプロシージャ例では、1つの静的グループと1つの動的グループを使用してネストされたグループが作成されます。

1. 静的グループを指定するLDIFファイルを作成します。
次の例のファイルstatic-group.ldifでは、Dev Contractorsという名前の仮想静的グループが指定されます。

dn: cn=Contractors,ou=Groups,dc=example,dc=com
cn: Dev Contractors
objectclass: top
objectclass: groupOfUniqueNames
ou: Dev Contractors Static Group
uniquemember: uid=wsmith,ou=Contractors,dc=example,dc=com
uniquemember: uid=jstearn,ou=Contractors,dc=example,dc=com
uniquemember: uid=pbrook,ou=Contractors,dc=example,dc=com
uniquemember: uid=njohnson,ou=Contractors,dc=example,dc=com
uniquemember: uid=sjones,ou=Contractors,dc=example,dc=com

2. ldapmodifyを使用してグループを追加し、LDIFファイルを処理します。

$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
--defaultAdd --filename static-group.ldif

3. 動的グループを指定するLDIFファイルを作成します。
次の例のファイルdynamic-group.ldifでは、Developersという名前の動的グループが指定されます。

dn: cn=Developers,ou=Groups,dc=example,dc=com
cn: Developers
objectclass: top
objectclass: groupOfURLs
ou: Groups
memberURL: ldap:///ou=People,dc=example,dc=com??sub?(ou=Product Development)

4. ldapmodifyを使用してグループを追加し、LDIFファイルを処理します。

$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
--defaultAdd --filename dynamic-group.ldif

5. ネストされた静的グループを指定するLDIFファイルを作成します。
次の例のファイルnested-group.ldifでは、Developers Groupという名前のネストされたグループが指定されます。

dn: cn=DevelopersGroup,ou=Groups,dc=example,dc=com
cn: Developers Group
objectclass: top
objectclass: groupOfUniqueNames
ou: Nested Static Group
uniquemember: cn=Contractors,ou=Groups,dc=example,dc=com
uniquemember: cn=Developers,ou=Groups,dc=example,dc=com

6. ldapmodifyを使用してグループを追加し、LDIFファイルを処理します。

$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
--defaultAdd --filename nested-group.ldif

19.4 参照整合性の保持

参照整合性とは、削除操作、名前変更操作または移動操作の後にすべての参照が適切に保持されるようにするためのデータベース・メカニズムです。たとえば、1つのエントリをディレクトリから削除した場合、ディレクトリ・サーバーではそのエントリがメンバーとしてリストされていたすべてのグループからもそのエントリが削除されます。

参照整合性メカニズムは、ディレクトリ・サーバーのプラグインとして構成され、dsconfigコマンドを使用して有効化できます。詳細は、第14.1項「dsconfigを使用したサーバー構成の管理」を参照してください。

この項では、参照整合性について説明します。この項の内容は次のとおりです:

- 第19.4.1項「参照整合性プラグインの概要」

- 第19.4.2項「参照整合性プラグインを有効にするには」

19.4.1 参照整合性プラグインの概要

デフォルトでは、参照整合性プラグインは無効となります。dsconfigを使用してこのプラグインを有効にすると、削除操作、名前変更操作または移動操作の直後に、member属性およびuniquemember属性で整合性の更新が実行されます。ディレクトリ内のユーザー・エントリまたはグループ・エントリを削除、名前変更または移動すると常に、その操作は、参照整合性ログ・ファイルINSTANCE_DIR/OUD/logs/referintに記録されます。

指定された時間(更新間隔)の経過後に、サーバーでは指定された属性に対して検索が実行され、ログに記録されている削除済エントリまたは変更済エントリのDNに検索結果が照合されます。ログ・ファイルで、エントリが削除されていることが確認されたら、対応する属性が削除されます。ログ・ファイルで、エントリが変更されていることが確認されたら、それに従って対応する属性値も変更されます。

要件に合うように参照整合性プラグインのプロパティを構成できます。次のプロパティを構成できます:

- 有効: 参照整合性プラグインをオンにします。

- プラグイン・タイプ: デフォルトで、削除操作、名前変更操作および移動操作が設定されます。たとえば、削除のみにするなど、プラグイン・タイプを変更できます。

- 属性のタイプ: デフォルトで、属性のタイプはmember,uniquememberに設定されますが、他の属性に変更できます。DN値が含まれる属性を使用または定義すると、参照整合性プラグインを使用してこれらの属性を監視できます。

- ベースDN: デフォルトで、すべてのパブリック・ネーミング・コンテキストをスコープで使用するよう設定されますが、これは特定のコンテキストに変更できます。

- ログ・ファイル: デフォルトで、ログ・ファイルはlogs/referintです。別のファイルに参照整合性の更新を記録できます。たとえば、レプリケートした環境での変更を記録する場合は、レプリケーション・サーバー上のchangelogファイルに書き込むことができ、コンシューマ・サーバーにその変更をレプリケートできるようになります。

- 更新間隔: デフォルトで、更新間隔は0秒に設定されます。これは、削除操作、名前変更操作または移動操作の直後に参照整合性が実行されることを意味します。更新がシステム・パフォーマンスに与える影響を最小限に抑えるには、更新間隔を長くします。一般的な更新間隔は次のとおりです:

- 0秒(すぐに更新)

- 90秒(90秒ごとに更新)

- 3600秒(1時間ごとに更新)

- 10,800秒(3時間ごとに更新)

- 28,800秒(8時間ごとに更新)

- 86,400秒(1日に1回更新)

- 604,800秒(1週間に1回更新)

19.4.2 参照整合性プラグインを有効にするには

dsconfigを使用して参照整合性を有効にするには、プラグインのenabledプロパティをtrueに設定します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
set-plugin-prop --plugin-name "Referential Integrity" --set enabled:true

19.5 Oracle Unified DirectoryサーバーでのODSEEロールのシミュレート

Oracle Directory Server Enterprise Edition (ODSEE)には、特化されたタイプのグループ・メカニズムの提供に使用されるロール・サブシステムが含まれます。この機能はOracle Unified Directoryには含まれていません。これは、非標準の機能に基づいており、Netscape固有のスキーマ要素が使用され、LDAP対応アプリケーションでは一般的に使用されていないためです。

ただし、Oracle Unified Directoryでは、ODSEEロールによって提供されるすべての機能を使用でき、この機能を標準のグループ化メカニズムに使用することができます。ODSEEで使用可能なロール機能に依存することを目的として作成されており、標準のグループ化メカニズムを使用できないアプリケーションを使用している場合は、そのようなアプリケーションの要件を満たすためにODSEEロールをシミュレートするようOracle Unified Directoryを構成できます。

注意:

使用しているアプリケーションでロール・エントリを作成して破棄することが必要な場合(たとえば、nsRoleDefinitionオブジェクト・クラスのいずれかの下位クラスが含まれるエントリ)、この機能は現在Oracle Unified Directoryでは使用できません。

この項には次のトピックが含まれます:

- 第19.5.1項「ユーザーがロールのメンバーかどうかを確認するには」

- 第19.5.2項「nsRoleDN属性を使用してメンバーシップを変更するには」

19.5.1 ユーザーがロールのメンバーかどうかを確認するには

アプリケーションで、ユーザーが所定のロールのメンバーかどうかの判別のみが必要な場合は、ターゲット・ユーザーのエントリのnsRole属性を確認して、該当するロールのDNが含まれているかどうかを判別するだけです。この場合、次の手順に従って、ロール機能をシミュレートできます。

これらの手順を完了したら、nsRole仮想属性がユーザー・エントリの操作属性として表示され、ユーザーがメンバーになっているすべてのグループのDNが含まれているはずです。nsRoleは操作属性であり、検索結果で返されるよう明示的にリクエストされる必要があることに注意してください。また、認証ユーザーに必ずその属性を表示する権限が付与されるように設定しておく必要もあります。

1. ODSEEロールの実装に必要なスキーマが含まれるようにディレクトリ・サーバーを更新します。
このスキーマは、03-dsee-roles.ldifと言う名前のLDIFファイルで提供されます。

1. このファイルをディレクトリ・サーバー実装のconfig/schemaディレクトリにコピーしてサーバーを再起動するか、または

2. add schema fileタスクを使用して、サーバーでスキーマ・ファイルが、実行中のサーバー・インスタンスにロードされるようにします。

2. 静的グループまたは動的グループを作成して、ロール・メンバーシップを定義します。
グループに必ず適切なメンバー・セットが含まれるようにします。

3. isMemberOf仮想属性の新規インスタンスを作成して、nsRole仮想属性を指定します。
nsRole属性には、ターゲット・ユーザーがメンバーになっているすべてのグループのDNのリストが含まれることになります。次のように、dsconfigコマンドを使用して、仮想属性を作成します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
create-virtual-attribute \
--type is-member-of --name nsRole --set attribute-type:nsRole --set enabled:true

19.5.2 nsRoleDN属性を使用してメンバーシップを変更するには

使用しているアプリケーションで、ユーザーのエントリのnsRoleDN仮想属性に、対応するロールの名前を配置することによってメンバーシップを変更できるようにする必要がある場合は、次の手順に従います。

この手順が完了したら、"cn=Test Role,ou=Roles,dc=example,dc=com"というnsRoleDN値が含まれるユーザー・エントリすべてのnsRole操作属性にそのDNが含まれるようになります。

1. 目的のロールのDNを指定して動的グループ・エントリを作成します。

2. 値がターゲット・ロールのDNに等しいnsRoleDN属性が含まれるメンバーを含めるようこのグループを構成します。
たとえば、アプリケーションで"cn=Test Role,ou=Roles,dc=example,dc=com"というnsRoleDN値を追加する場合、次のエントリを追加します:

dn: cn=Test Role,ou=Roles,dc=example,dc=com
objectClass: top
objectClass: groupOfURLs
cn: Test Role
memberURL: ldap:///dc=example,dc=com??sub?(nsRoleDN=\
cn=Test Role,ou=Roles,dc=example,dc=com)

第IV部

高度な管理: セキュリティ、アクセス制御およびパスワード・ポリシー

この部では、サーバー自体のセキュリティとディレクトリに保存されるデータのセキュリティに関連するデプロイメントのすべての局面を構成する方法について説明します。

この部には次の章が含まれます:

- 第20章「クライアント/サーバー間のセキュリティ構成」

- 第21章「プロキシ/データ・ソース間のセキュリティ構成」

- 第22章「データへのアクセス制御」

- 第23章「管理ユーザーの管理」

- 第24章「パスワード・ポリシーの管理」

- 第25章「Oracleのエンタープライズ・ユーザー・セキュリティとの統合」

20 クライアント/サーバー間のセキュリティ構成

Oracle Unified Directoryには、クライアント/サーバー間の通信を保護するためのメカニズムが複数用意されています。この項のトピックでは、これらのメカニズムの概要と構成方法について説明します。

ディレクトリ・データへのアクセスを保護する方法は、第22章「データへのアクセス制御」を参照してください。

プロキシ/ディレクトリ・サーバーまたはデータ・ソース間のセキュリティ構成は、第21章「プロキシ/データ・ソース間のセキュリティ構成」を参照してください。

この章では、次のトピックを取り扱います:

- 第20.1項「SSLの迅速な起動と実行」

- 第20.2項「キー・マネージャ・プロバイダの構成」

- 第20.3項「信頼マネージャ・プロバイダの構成」

- 第20.4項「証明書マッパーの構成」

- 第20.5項「LDAPおよびJMX用のSSLおよびStartTLSの構成」

- 第20.6項「SASL認証の使用」

- 第20.7項「SASL認証の構成」

- 第20.8項「GSSAPI SASL認証用のKerberosおよびOracle Unified Directory Serverの構成」

- 第20.9項「ldapsearchによるSSL、StartTLSおよびSASL認証のテスト」

- 第20.10項「OpenSSL s_clientテスト・ユーティリティを使用したSSLのデバッグ」

- 第20.11項「Javaデバッグ情報を使用したSSLまたはTLSのデバッグ」

- 第20.12項「許可および拒否ルールを使用した接続アクセスの制御」

- 第20.13項「強度無制限の暗号の構成」

20.1 SSLの迅速な起動と実行

Oracle Unified Directoryには、SSLおよびStartTLSを構成し、使用するための多数のオプションが用意されています。構成オプションが豊富だと、テクノロジに不慣れな人やテスト目的で迅速に起動と実行を試したい人は厄介に感じるかもしれません。

この項では、Oracle Unified Directoryが自己署名証明書を使用するSSLベースの接続を受け入れるために実行する必要がある手順をリストします。

この項の手順では、信頼されるキーストアの知識が前提となります。キーストアの詳細は、第20.2項「キー・マネージャ・プロバイダの構成」を参照してください。トラスト・ストアの詳細は、第20.3項「信頼マネージャ・プロバイダの構成」を参照してください。

注意:

通常の運用で自己署名証明書を使用することはお薦めできません。通常の運用で証明書をインストールする場合は、第20.2項「キー・マネージャ・プロバイダの構成」を参照してください。

20.1.1自己署名証明書を使用したSSLベースの接続を受け入れる方法

この手順の前提条件は次のとおりです:

- Oracle Unified Directoryが作業中のシステムにインストールされています。

- Java keytoolユーティリティがパス内にあります。それがない場合は、パスに追加するか、コマンド呼出し時に完全パスを指定してください。keytoolユーティリティは、Java Runtime Environment (JRE)に提供されています。

- 管理コネクタがデフォルト・ポート(4444)でリッスンし、dsconfigコマンドがローカル・ホスト上で実行されているサーバーにアクセスしています。そうでない場合は、--portオプションと--hostnameオプションを指定する必要があります。

1. keytoolコマンドに-genkeypairオプションを指定して、証明書用の秘密鍵を生成します。
例:

$ keytool -genkeypair -alias server-cert -keyalg rsa \
-dname "CN=myhost.example.com,O=Example Company,C=US" \
-keystore config/keystore -storetype JKS

- -alias別名。キーストア内の証明書を参照するために使用する名前を指定します。サーバーが使用するデフォルト名はserver-certです。

- -keyalgアルゴリズム。秘密鍵を生成するために使用するアルゴリズムを指定します。これは通常、rsaです。

- -dname サブジェクト。証明書に使用するサブジェクトを指定します。
環境に合せて、-dname引数の値を変更します:

CN属性の値は、証明書がインストールされているシステムの完全修飾名です。

O属性の値は、社名または組織名です。

C属性の値は、2文字の国名の省略形です。

- -keystoreパス。キーストア・ファイルへのパスを指定します。ファイルがない場合は作成されます。サーバーによって使用されるデフォルトのキーストア・パスは、config/keystoreです。

- -keypassパスワード。キーストア内の秘密鍵を保護するためのパスワードを指定します。パスワードを指定しないと、指定するように要求されます。

- -storepassパスワード。キーストアの内容を保護するためのパスワードを指定します。パスワードを指定しないと、指定するように要求されます。-keypassオプションと-storepassオプションには同じパスワードを使用します。

- -storetype タイプ。使用されるキーストア・タイプを指定します。たとえば、JKSキーストアの場合、値は常にJKSです。

キーストアの内容を保護するパスワードと秘密鍵を保護するパスワードの入力が要求されます。

2. 鍵のための自己署名証明書を生成します。
例:

$ keytool -selfcert -alias server-cert -validity 1825 \
-keystore config/keystore -storetype JKS

- -alias別名。キーストア内の証明書を参照するために使用する名前を指定します。-genkeypairオプションを使用して秘密鍵を生成したときに指定した値と同一である必要があります。

- -validity 日間。証明書の有効期間を日数で指定します。デフォルトの有効期間は90日間です。

- -keystoreパス。キーストア・ファイルへのパスを指定します。ファイルがない場合は作成されます。

- -keypassパスワード。キーストア内の秘密鍵を保護するためのパスワードを指定します。これを省略すると、入力するように要求されます。

- -storepassパスワード。キーストアの内容を保護するためのパスワードを指定します。これを省略すると、入力するように要求されます。

- -storetype タイプ。使用されるキーストア・タイプを指定します。JKSキーストアでは、値は常にJKSです。

キーストア・パスワードの入力を要求されたら、前の手順で入力したパスワードを入力します。

3. config/keystore.pinという名のテキスト・ファイルを作成します。
このファイルには、キーストアの内容を保護するためのパスワードを指定する必要があります。このファイルを変更する場合は、キーストア・マネージャ構成と一致する必要があることに注意してください。別のファイル名を使用する場合は、該当するキーストア・マネージャのkey-store-fileプロパティをそのパスおよびファイル名と一致させる必要があります。

4. 作成した証明書の公開鍵をエクスポートします。
例:

$ keytool -exportcert -alias server-cert -file config/server-cert.txt -rfc \
-keystore config/keystore -storetype JKS

5. 新規にトラスト・ストアを作成して、それにサーバー証明書をインポートします。
例:

$ keytool -importcert -alias server-cert -file config/server-cert.txt \
-keystore config/truststore -storetype JKS

6. その証明書を信頼するか尋ねられたら、yesと入力します。
この手順は、インストール時にSSLおよびStartTLS設定が指定されなかったか、これらの設定を変更する場合にのみ必要です。

7. dsconfigコマンドを使用して、キー・マネージャ・プロバイダ、信頼マネージャ・プロバイダおよび接続ハンドラを有効にします。
例:

$ dsconfig -D "cn=directory manager" -j pwd-file -X -n \
set-key-manager-provider-prop --provider-name JKS --set enabled:true
$ dsconfig -D "cn=directory manager" -j pwd-file -X -n \
set-trust-manager-provider-prop --provider-name "Blind Trust" \
--set enabled:true
$ dsconfig -D "cn=directory manager" -j pwd-file -X -n \
set-connection-handler-prop --handler-name "LDAPS Connection Handler" \
--set "trust-manager-provider:Blind Trust" --set key-manager-provider:JKS \
--set listen-port:1636 --set enabled:true

ポート1636は標準のLDAPSポートですが、そのポートがすでに占有されている場合や、レギュラー・ユーザーの場合は使用できないことがあります。I1636以外のポート上でSSLベースの接続を受け入れる必要がある場合は、最後のコマンドのlisten-portプロパティを使用するポート番号に変更します。

ステップ3でconfig/keystore.pinと異なる場所および名前のテキスト・ファイルを作成した場合、たとえば、ファイル名がconfig/mykeystore.pinだとしたら、以下のように情報を指定します:

$ dsconfig -D "cn=directory manager" -j pwd-file -X -n \
set-key-manager-provider-prop --provider-name JKS --set enabled:true \
--set keystore-pin-file:/config/mykeystore.pin

キーストアの詳細は、第20.2項「キー・マネージャ・プロバイダの構成」を参照してください。トラスト・ストアの詳細は、第20.3項「信頼マネージャ・プロバイダの構成」を参照してください。

8. これでサーバーはSSLベースのクライアント接続を受け入れる第2のリスナーを持つことになります。ldapsearchコマンドで、以下のように構成をテストします:

$ ldapsearch --port 1636 --useSSL --baseDN "" --searchScope base "(objectClass=*)"

サーバーの証明書を信頼するかどうか尋ねられます。yesと入力すると、ルートDSEエントリが戻されます。

20.2 キー・マネージャ・プロバイダの構成

キー・マネージャ・プロバイダは、SSLまたはStartTLSネゴシエーションを実行するときにディレクトリ・サーバーによって使用される証明書へのアクセスを提供します。

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

- 第20.2.1項「キー・マネージャ・プロバイダの概要」

- 第20.2.2項「JKSキー・マネージャ・プロバイダの使用」

- 第20.2.3項「PKCS #12 キー・マネージャ・プロバイダの使用」

- 第20.2.4項「PKCS #11キー・マネージャ・プロバイダの使用」

- 第20.2.5項「本番サーバーでの証明書の置換え」

- 第20.2.6項「ODSMによるキー・マネージャの構成」

詳細は、Oracle Unified Directoryの構成リファレンスのキー・マネージャ・プロバイダの構成に関する項を参照してください。

20.2.1 キー・マネージャ・プロバイダの概要

Oracle Unified Directoryは、次のキー・マネージャ・プロバイダのキーストア・フォーマットをサポートします:

- JKSキーストア、Java Secure Socket Extension (JSSE)によって使用されるデフォルトのキーストア・フォーマット

- PKCS #12ファイル

- PKCS #11デバイス、ハードウェア・セキュリティ・モジュールまたは暗号アクセラレータなど

注意:

PKCS #11は、プロキシ・サーバー・インスタンスとの使用がサポートされていません。

これらのキー・マネージャ・プロバイダを使用するためのOracle Unified Directoryの構成プロセスは、以下の項で詳細に説明します。

管理コネクタはLDAPSコネクタです。すべてのSSLベース・コネクタと同様に、管理コネクタにはキー・マネージャが必要です。Oracle Unified Directoryは、管理コネクタ専用のキー・マネージャを提供します。これはデフォルトで有効になっています。詳細は、第14.3項「サーバーへの管理トラフィックの管理」を参照してください。

20.2.2 JKSキー・マネージャ・プロバイダの使用

JKSキーストアは、大半のJSSEの実装で使用されるデフォルトのキーストアであり、多くの環境で優先されるキーストア・タイプです。このキーストア・タイプを使用するようにサーバーを構成するには、まず有効な証明書を含むJKSキーストアを取得する必要があります。これを行うには、自己署名証明書を生成するか、既存の認証局(CA)に証明書署名リクエストを発行して署名された証明書をインポートします。

ここで述べたすべてのステップでkeytoolユーティリティを使用する必要があります。このユーティリティはJavaランタイム環境に用意されています。このユーティリティは通常、Javaインストール・ディレクトリのルート下のbinディレクトリにあります。keytoolユーティリティの使用法は、Java公式ドキュメント(http://download.oracle.com/javase/6/docs/technotes/tools/windows/keytool.html)を参照してください。

JKSキー・マネージャ・プロバイダを使用する手順は次のとおりです:

1. 秘密鍵を生成します。

2. 証明書に自己署名するか、外部認証局を使用して証明書に署名します。

3. JKSキー・マネージャ・プロバイダを構成します。

20.2.2.1 秘密鍵を生成する方法

自己署名証明書を使用する場合でも、また証明書署名リクエストを生成する場合でも、まず秘密鍵を生成する必要があります。これは、-genkeypairオプションを指定してkeytoolユーティリティによって実行できます。このオプションには次の引数を指定できます:

- -alias別名。キーストア内の証明書を参照するために使用する名前を指定します。サーバーによって使用されるデフォルト名はserver-certです。

- -keyalgアルゴリズム。秘密鍵を生成するために使用するアルゴリズムを指定します。これは通常、rsaです。

- -dname サブジェクト。証明書に使用するサブジェクトを指定します。サブジェクトには通常、最低でもCN属性、O属性およびC属性が含まれます。CN属性は証明書がインストールされるシステムの完全修飾名です。O属性は社名または組織名を指定します。Cは証明書が使用される国を指定します。

- -keystoreパス。キーストア・ファイルへのパスを指定します。ファイルがない場合は作成されます。ディレクトリ・サーバーによって使用されるデフォルトのキーストア・パスは、config/keystoreです。

- -keypassパスワード。キーストア内の秘密鍵を保護するためのパスワードを指定します。パスワードを指定しないと、指定するように要求されます。

- -storepassパスワード。キーストアの内容を保護するためのパスワードを指定します。パスワードを指定しないと、指定するように要求されます。-keypassおよび-storepassオプションのパスワードは同じものを使用します。

- -storetype タイプ。使用されるキーストア・タイプを指定します。JKSキーストアでは、値は常にJKSです。

以下のように、keytool -genkeypairコマンドを使用して秘密鍵を生成します:

$ keytool -genkeypair -alias server-cert -keyalg rsa \
-dname "CN=server.example.com,O=example.com,C=US" \
-keystore config/keystore -keypass password \
-storetype JKS -storepass password

20.2.2.2 証明書に自己署名する方法

自己署名証明書の場合は、-selfcertオプションを使用します。このオプションに使用される最も重要な引数は、次のとおりです:

- -alias別名。キーストア内の証明書を参照するために使用する名前を指定します。-genkeypairオプションを使用して秘密鍵を生成したときに指定した値と同一である必要があります。

- -validity 日間。証明書の有効期間を日数で指定します。デフォルトの有効期間は90日間です。

- -keystoreパス。キーストア・ファイルへのパスを指定します。ファイルがない場合は作成されます。

- -keypassパスワード。キーストア内の秘密鍵を保護するためのパスワードを指定します。これを省略すると、入力するように要求されます。

- -storepassパスワード。キーストアの内容を保護するためのパスワードを指定します。これを省略すると、入力するように要求されます。

- -storetype タイプ。使用されるキーストア・タイプを指定します。JKSキーストアでは、値は常にJKSです。

次のように、keytool -selfcertコマンドを使用して自己署名証明書を生成します:

$ keytool -selfcert -alias server-cert -validity 1825 \
-keystore config/keystore -keypass password -storetype JKS \
-storepass password

20.2.2.3 外部認証局を使用して証明書に署名する方法

外部認証局を使用して証明書に署名する場合は、-certreqオプションを使用して証明書署名リクエスト(CSR)を生成します。認証局にCSRを提出して署名してもらいます。この方法と、署名済証明書を取得する方法は、認証局によって異なる場合があります。

認証局から署名済の証明書を受け取ったら、-importcertオプションを使用して、それをキーストアにインポートします。

1. -certreqオプションを使用して、証明書署名リクエストを取得します。

$ keytool -certreq -alias server-cert -file /tmp/server-cert.csr \
-keystore config/keystore -keypass password -storetype JKS \
-storepass password

このコマンドで使用できる引数は次のとおりです:

- -alias別名。キーストア内の証明書を参照するために使用する名前を指定します。-genkeypairオプションを使用して秘密鍵を生成したときに指定した値と同一である必要があります。

- -fileパス。CSRを書き込むファイルへのパスを指定します。これを省略すると、リクエストは標準出力に書き込まれます。

- -keystoreパス。キーストア・ファイルへのパスを指定します。ファイルがない場合は作成されます。

- -keypassパスワード。キーストア内の秘密鍵を保護するためのパスワードを指定します。これを省略すると、入力が求められます。

- -storepassパスワード。キーストアの内容を保護するためのパスワードを指定します。これを省略すると、入力が求められます。

- -storetype タイプ。使用されるキーストア・タイプを指定します。JKSキーストアでは、値は常にJKSです。

2. 証明書リクエストを外部認証局に送信します。認証局は署名済証明書ファイルを返送します。/tmp/server-cert.txtにファイルを保存します。

3. -importcertを使用して、署名済の証明書をインポートします。

$ keytool -importcert -alias server-cert -file /tmp/server-cert.cert \
-keystore config/keystore -storetype JKS -storepass password

このコマンドで使用できる引数は次のとおりです:

- -alias別名。キーストア内の証明書を参照するために使用する名前を指定します。-genkeypairオプションを使用して秘密鍵を生成したときに指定した値と同一である必要があります。

- -fileパス。署名済証明書を含むファイルへのパスを指定します。ファイルは、DERでエンコードされたバイナリ形式かBase64でエンコードされたASCII形式(RFC 1421 (http://www.ietf.org/rfc/rfc1421.txt)の記述どおり)である必要があります。

- -keystoreパス。キーストア・ファイルへのパスを指定します。ファイルがない場合は、新規に作成されます。

- -storepassパスワード。キーストアの内容を保護するためのパスワードを指定します。これを省略すると、入力するように要求されます。

- -storetype タイプ。使用されるキーストア・タイプを指定します。JKSキーストアでは、値は常にJKSです。

20.2.2.4 JKSキー・マネージャ・プロバイダを構成する方法

署名済の証明書(自己署名か外部CAによる署名かを問わず)を含むJKSキーストアを作成したときに、そのキーストアのキー・マネージャ・プロバイダ・エントリの構成により、そのキーストアを使用するようにサーバーを構成できます。

この例ではdsconfigを使用してデフォルトのJKSキー・マネージャ・プロバイダのプロパティを構成します。キー・マネージャ・プロバイダのすべてのプロパティの詳細は、Oracle Unified Directory構成リファレンスのファイル・ベースのキー・マネージャ・プロバイダの構成に関する項を参照してください。

dsconfigコマンドを使用してキー・マネージャ・プロバイダ・エントリを構成します。

$ dsconfig -D "cn=Directory Manager" -j pwd-file -X -n \
set-key-manager-provider-prop --provider-name "JKS" \
--set enabled:true --set "key-store-type:JKS" \
--set "key-store-file:config/keystore" \
--set "key-store-pin:password"
--reset key-store-pin-file

20.2.3 PKCS #12キー・マネージャ・プロバイダの使用

PKCS #12は、秘密鍵を含めて、証明書情報を格納するための標準フォーマットです。Oracle Unified Directoryは証明書の秘密鍵を含む証明書キーストアとしてPKCS #12ファイルを使用できます。

PKCS #12は証明書情報を格納するための共通のフォーマットであるため、このフォーマットの証明書をすでに持っているか、使用する認証局(CA)がこのフォーマットで証明書を作成することがあります。場合によっては、既存の証明書をPKCS #12フォーマットに変換できます。たとえば、Network Security Services (NSS)証明書データベースにすでに証明書がある場合は、NSS pk12utilツールでそれをインポートできます。次の例では、pk12utilツールを使用して、データベース../../alias/slapd-config-key3.dbに含まれるserver-certという名の証明書をPKCS #12ファイル/tmp/server-cert.p12にエクスポートします:

$ ./pk12util -n server-cert -o /tmp/server-cert.p12 \
-d ../../alias -P "slapd-config-"

PKCS #12フォーマットの証明書を新規作成するには、第20.2.2項「JKSキー・マネージャ・プロバイダの使用」の手順を使用してJKSキーストア内の証明書を取得します。手順の中で唯一異なる点は、keytoolコマンドを呼び出すときに、-storetype JKSでなく-storetype PKCS12を使用する点です。PKCS #12ファイルの中の自己署名証明書を使用するには、次のコマンドを使用します:

$ keytool -genkeypair -alias server-cert -keyalg rsa \
-dname "CN=server.example.com,O=example.com,C=US" \
-keystore config/keystore.p12 -keypass password \
-storetype PKCS12 -storepass password

$ keytool -selfcert -alias server-cert -validity 1825 \
-keystore config/keystore.p12 -keypass password \
-storetype PKCS12 -storepass password

サーバーはJKSと同様に、PKCS #12証明書ファイルで使用するためにJKSキー・マネージャ・プロバイダの構成エントリと同一構成属性を使用するテンプレートのキー・マネージャ・プロバイダを提供します。相違点は、key-store-type属性の値がPKCS12であり、key-store-file属性がJKSキーストアでなく、PKCS #12ファイルの場所を参照する必要がある点です。次の例では、dsconfigを使用してPKCS #12キーストア・マネージャ・プロバイダを構成します:

$ dsconfig -D "cn=directory manager" -j pwd-file -X -n\
set-key-manager-provider-prop --provider-name "PKCS12" --set enabled:true \
--set java-class:org.opends.server.extensions.FileBasedKeyManagerProvider \
--set enabled:true --set "key-store-type:PKCS12" \
--set "key-store-file:/config/keystore" \
--set "key-store-pin:secret"

構成可能なプロパティの完全なリストは、Oracle Unified Directory構成ガイドのファイル・ベースのキー・マネージャ・プロバイダの構成に関する項を参照してください。

20.2.4 PKCS #11キー・マネージャ・プロバイダの使用

PKCS #11は、暗号情報を保持し、暗号機能を実行できるデバイスと対話するために使用される標準インタフェースです。PKCS #11インタフェースには、ディレクトリ・サーバーについて2つの共通する使用法があります:

- 暗号アクセラレータは、このインタフェースを使用して製品による暗号処理を外部ボード(または場合によっては、システムのCPU内部の特殊モジュールや、OSカーネル内部のフレームワーク)に任せることができるため、暗号処理を高速化できます。

- ハードウェア・セキュリティ・モジュール(HSM)は、このインタフェースを使用して、鍵情報を格納するための安全なリポジトリを提供します。これは重要な鍵情報が漏えいする危険性を顕著に減らし、安全な通信メカニズムの全体的整合性の保護に役立ちます。

注意:

PKCS #11フォーマットは、プロキシ・サーバー・インスタンスでの使用がサポートされていません。

現在、Oracle Unified Directoryが提供するPKCS #11サポートは、Solaris OS暗号フレームワークの使用によりSolaris 10以上(SPARCおよびx86/x64システム上)を実行するシステム上でのみテストおよび検証されます。このSolaris暗号フレームワークに接続されるデバイスはすべて、この方法でサポートされます。これにはsofttokenデバイスが含まれます。このデバイスはソフトウェアでシミュレートされるため、PKCS #11サポートを提供するハードウェア・デバイスの有無にかかわらずSolaris暗号フレームワークをサポートするすべてのシステムで使用できます。

サードパーティのPKCS #11デバイスがSolarisシステムにインストールされている場合、通常はすでにSolaris OS暗号フレームワークでそのデバイスへのアクセスが構成されています。ただし、単にソフトウェア・トークンを使用する場合や、Sun Fire T1000またはT2000システムでの実行中にUltraSPARC—T1 CPUに搭載された暗号プロセッサの利点を活用する場合は通常、PKCS #11インタフェースを初期化する必要があります。それには、まず証明書ストア用に使用するPINを選択します。そのためのコマンドは次のとおりです:

$ pktool setpin

このコマンドにより現在のパスフレーズの入力が求められます。Solaris OS暗号フレームワークをまだ使用していない場合、デフォルトのパスフレーズはchangemeです。次に新しいパスワードの入力が2回求められます。

注意:

ユーザーごとに証明書セットが異なるため、ユーザーとしてログインするか、ディレクトリ・サーバーを実行するために使用されるロールとしてログインするときにこのステップを実行します。

この時点で、Java keytoolユーティリティを使用してPKCS #11を通してSolaris暗号フレームワークと対話することができます。これはJKSまたはPKCS#12キーストアでの操作とほとんど同じですが、次のような例外があります:

- -keystore引数の値には、NONEを指定します。

- -storetype引数の値には、PKCS11を指定します。

- -keypass引数は使用できません。パスワードを省略しても、パスワードの入力は求められません。

- -storepass引数の値には、pktool setpinコマンドを使用するときに選択したパスフレーズを指定します。もう1つの方法として、この引数をコマンド・ラインに指定しない場合、これは要求されたときに入力すべきパスワードです。

たとえば、次のコマンドはPKCS #11インタフェースを使用して、Solaris暗号フレームワークを通して自己署名証明書を生成します:

$ keytool -genkeypair -alias server-cert -keyalg rsa \
-dname "CN=server.example.com,O=example.com,C=US" \
-keystore NONE -storetype PKCS11 -storepass password

$ keytool -selfcert -alias server-cert -validity 1825 \
-keystore NONE -storetype PKCS11 -storepass password

証明書がPKCS #11キーストアにインストールされたら、ディレクトリ・サーバーを構成してそのキーストアを使用する必要があります。JKSおよびPKCS#12キーストア・マネージャ・プロバイダのエントリと同じ方法でPKCS #11キーストア・プロバイダを構成します。このとき、key-store-file属性は指定しないでください。ただし、PINは必須なので、直接PINファイルに指定するか、Javaプロパティか環境変数を通して指定します。

次の例では、dsconfigを使用してPKCS #11キー・マネージャ・プロバイダを構成します:

$ dsconfig -D "cn=directory manager" -j pwd-file -X -n \
set-key-manager-provider-prop --provider-name "PKCS11" --set enabled:true \
--set enabled:true --set "key-store-type:PKCS11" \
--set "key-store-file:/config/keystore" \
--set "key-store-pin:secret"

構成可能なプロパティの完全なリストは、Oracle Unified Directory構成ガイドのPKCS11キー・マネージャ・プロバイダの構成に関する項を参照してください。

20.2.5 本番サーバーでの証明書の置換え

本番サーバーで証明書を置き換えるには、新しい証明書をリクエストして適切なキー・マネージャ・プロバイダを構成します。詳細は、第20.2.2項「JKSキー・マネージャ・プロバイダの使用」、第20.2.3項「PKCS #12キー・マネージャ・プロバイダの使用」または第20.2.4項「PKCS #11キー・マネージャ・プロバイダの使用」を参照してください。

SSLベースの接続ハンドラ(デフォルト名はLDAPS)のkey-manager-providerプロパティは、セキュリティに使用すべきキーストア・マネージャを指定します。key-manager-providerプロパティのデフォルト値は"JKS"で、SSL接続ハンドラがデフォルトでJKSキー・マネージャ・プロバイダを使用することを意味します。別のキー・マネージャ・プロバイダを使用する場合は、SSL接続ハンドラのこのプロパティを適宜変更します。

新しい証明書をインストールした後にサーバーを再起動する必要はありません。関連するクライアント接続では、それ以降のサーバー・アクセスに対して新しい証明書がただちに使用されます。既存の接続は再確立されません。

20.2.6 ODSMによるキー・マネージャの構成

ODSMの使用により、次のようにキー・マネージャ構成を管理できます:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「構成」タブを選択します。

3. 「一般構成」の下の「キー・マネージャ」項目を開きます。

4. 構成するキー・マネージャを選択します。
キー・マネージャの構成可能なプロパティは右側のペインに表示されます。

5. 必要に応じてキー・マネージャの構成を編集し、「適用」をクリックして変更を保存します。

20.3 信頼マネージャ・プロバイダの構成

Oracle Unified Directoryは、信頼マネージャ・プロバイダを使用して提出された証明書を信頼するかどうかを決定します。信頼マネージャは、システム全体のセキュリティ上重要な役割を担っています。これはクライアントからのインバウンド接続や別のサーバーへのアウトバウンド接続の相手側システムが申告どおりの本人であることを保障します。

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

- 第20.3.1項「証明書信頼メカニズムの概要」

- 第20.3.2項「ブラインド信頼マネージャ・プロバイダの使用」

- 第20.3.3項「JKS信頼マネージャ・プロバイダの使用」

- 第20.3.4項「PKCS #12信頼マネージャ・プロバイダの使用」

- 第20.3.5項「ODSMによる信頼マネージャの構成」

20.3.1 証明書信頼メカニズムの概要

信頼マネージャ・プロバイダは、偽造証明書を使用した攻撃や介入者攻撃を防ぐためにSSLやStartTLSを使用するときにセキュリティを向上させることができます。

信頼マネージャ・プロバイダの2つの主要な使用例を以下に示します:

- インバウンド接続: SSLまたはStartTLSネゴシエーション・プロセス中にクライアントが自身の証明書をサーバーに提出します。これはSASL EXTERNAL認証で使用される可能性があります。

- アウトバウンド接続: サーバーが外部のシステムとのSSLベースの接続を確立しようとします。たとえば、同期、プロキシ、または連鎖操作が目的です。

信頼マネージャは暗号強度に影響を与えません。このため、サーバーとそのピアだけが通信を理解できます。サードパーティのオブザーバーは通信を解読できません。信頼マネージャはピアが申告どおりに本人であることを保証し、機密情報が他人になりすましたピアに不注意に開示されないようにします。

信頼マネージャは、ピアの証明書が信頼できるものかどうか判断するために、多数の要因を検討します。この項では、このプロセスで検討される最も一般的ないくつかの基準について説明します。

最も単純な信頼メカニズムの1つは証明書の有効期限です。すべての証明書には、"notBefore"および"notAfter"タイムスタンプによって境界される有効期間を示す特定のウィンドウがあります。現在の時間が"notAfter"タイムスタンプを超えると、証明書が期限切れとなり、信頼マネージャによって拒否されます。同様に、現在の時間が"notBefore"タイムスタンプより前の場合にも証明書は拒否されます。通常、"notBefore"タイムスタンプは証明書が署名された時間に設定されますが、ただちに有効にならない証明書が発行されることがあります。そのような場合は、ピアからのアクセスが期限前に許可されないようにすることが重要です。

ピアの証明書を信頼するかどうか判断する際に非常に重要なもう1つの要因は、ピアの証明書チェーンです。あるシステムが別のシステムに証明書を提出する場合、提出するものは自身の証明書だけではなく、プロセスに関連するすべてのエンティティを記述する証明書チェーンを提出します。信頼マネージャがピアを信頼するかどうか判断する場合に、信頼マネージャはまず、トラスト・ストアを見てそこに通信相手の証明書が含まれているか確認します。証明書が見つかると、有効期限を過ぎているなど、他の理由がなければ、ピアは信頼されます。ピアの証明書が見つからない場合、信頼マネージャはピアの証明書に署名するために使用された、チェーン内の次の証明書(発行者証明書)を探します。トラスト・ストアに発行者の証明書が含まれる場合、サーバーはその発行者の証明書を信頼し、暗黙にそれが署名したすべての証明書を信頼します。このプロセスは、トラスト・ストア内で証明書の1つが見つかるか、チェーンのルートに達するまで(この場合、ルート証明書は自己署名であるためそれ自体の発行者です)証明書チェーンで継続されます(発行者の証明書に署名した証明書、等々)。ピアのチェーン内のどの証明書もトラスト・ストアに含まれない場合、ピアの証明書は拒否されます。

このプロセスにより、膨大な数の証明書が使用される環境(たとえば、膨大な数のサーバーを持つ環境や多数のクライアントがSASL EXTERNAL認証を使用する環境)の管理が大幅に簡素化されます。トラスト・ストアは個々のピアの証明書を持っている必要はありません。トラスト・ストアは、ピアの証明書チェーン内の証明書を1つだけ持つことができます。たとえば、サーバーに提出された正当なすべての証明書が同一発行者によって署名されている場合、トラスト・ストアにその発行者の証明書があれば、すべてのピアが暗黙に信頼されます。

環境によっては、ピアの証明書チェーンを信頼するかどうか判断するときに考慮すべきその他の要素があります。たとえば、無効になった証明書や有効期限内であり信頼された発行者によって署名されていても有効と見なすべきでないすべての証明書のリストを含む証明書失効リスト(CRL)があります。たとえば、これは証明書の持主である社員が退職したときや証明書の秘密鍵が信用できなくなったときに利用できます。オンライン証明書ステータス・プロトコル(OCSP、RFC 2560 (http://www.ietf.org/rfc/rfc2560.txt)で定義されている)も類似したメカニズムを持ち、信頼性マネージャは証明書が有効かどうかにかかわらずOCSPサーバーに問合せることがあります。Oracle Unified Directoryは現在、ピアの証明書チェーンが信頼できるものかどうか判断するときにCRLやOCSPの使用をサポートしていません。

管理コネクタはLDAPSコネクタです。すべてのSSLベース・コネクタと同様に、管理コネクタには信頼マネージャが必要です。Oracle Unified Directoryは、管理コネクタ専用の信頼マネージャを提供します。これはデフォルトで有効になっています。詳細は、第14.3項「サーバーへの管理トラフィックの管理」を参照してください。

20.3.2 ブラインド信頼マネージャ・プロバイダの使用

ブラインド信頼マネージャ・プロバイダは、提示されたすべての証明書を信頼する単純なプロバイダです。これは有効期限、証明書の署名者、件名、別名などの条件を確認しません。

Oracle Unified Directoryは、ブラインド信頼マネージャ・プロバイダを提供しますが、これはデフォルトで無効になっています。enabled属性の値をtrueに変更することにより、このプロバイダを有効にできます。ブラインド信頼マネージャ・プロバイダには、その他の構成属性は必要ありません。

注意:

ブラインド信頼マネージャ・プロバイダは、プロキシ・サーバー・インスタンスではサポートされません。

次の例ではdsconfigを使用してブラインド信頼マネージャ・プロバイダを構成します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X \
set-trust-manager-provider-prop --provider-name "Blind Trust"

構成可能なプロパティのリストは、Oracle Unified Directory構成リファレンスのブラインド信頼マネージャ・プロバイダの構成に関する項を参照してください。

注意:

ブラインド信頼マネージャ・プロバイダは、テスト用にのみ提供されており、本番サーバー用ではありません。特にSASL EXTERNAL認証を許可するように構成されたサーバーでは使用しないでください。クライアントがSASL EXTERNALを使用して証明書を認証し、サーバーがクライアントによって提出されるすべての証明書を盲目的に受け入れてしまうと、ユーザーは自己署名証明書を作成して、ディレクトリ内のあらゆるユーザーになりすますことができます。

20.3.3 JKS信頼マネージャ・プロバイダの使用

JKSキーストアを使用してキー・マネージャ・プロバイダ用に鍵情報を提供できるのと同様に、信頼マネージャ・プロバイダによって使用される情報を提供するために使用することもできます。通常、JKSファイルをトラスト・ストアとして使用するのは、それをキーストアとして使用するのと似ています。ただし、ファイルをトラスト・ストアとして使用するときには秘密鍵情報にアクセスしないため、コンテンツにアクセスするときに通常はPINは必要ありません。

JKS信頼マネージャ・プロバイダが、ピアの証明書チェーンを信頼するかどうか判断するときに、2つの要因を検討します:

- ピアの証明書が有効期限内かどうか。

- チェーン内の証明書が1つ以上トラスト・ストアに含まれているかどうか。

ピアの証明書の有効期限が切れていたり、証明書チェーン内の証明書が1つもトラスト・ストアに含まれていない場合、JKS信頼マネージャによってピアの証明書が拒否されます。

keytool -importcertユーティリティを使用して、証明書をJKSトラスト・ストアにインポートします。-importcertオプションは以下の引数を使用します:

- -alias alias トラスト・ストア内の証明書に名前を指定します。証明書ごとに一意の名前を指定します。ニックネームは主にトラスト・ストア内の証明書の管理用であり、証明書が信頼されているかどうかに影響を与えません。

- -file path インポートする証明書を含むファイルへのパスを指定します。ファイルは、DER形式かBase64でエンコードされたASCII形式(RFC 1421 (http://www.ietf.org/rfc/rfc1421.txt)の記述どおり)である必要があります。

- -keystore path JKSトラスト・ストアとして使用されるファイルへのパスを指定します。このパスは通常、config/truststoreです。

- -storetype type トラスト・ストア・ファイルの形式を指定します。JKS信頼マネージャの場合、これはJKSとする必要があります。

- -storepass password トラスト・ストアのコンテンツを保護するために使用するパスワードを指定します。トラスト・ストア・ファイルがない場合、この値はトラスト・ストアに割り当てられるパスワードです。これ以降は、このパスワードを使用して、トラスト・ストアと対話する必要があります。このオプションを省略すると、パスワードはユーザーからインタラクティブに要求されます。

証明書をJKSトラスト・ストアにインポートするためのコマンドの例を以下に示します。トラスト・ストアがない場合、このコマンドは証明書をインポートする前にトラスト・ストアを作成します。

$ keytool -importcert -alias server-cert -file /tmp/cert.txt \
-keystore config/truststore -storetype JKS -storepass password

Oracle Unified Directoryには、JKS信頼マネージャ・プロバイダのテンプレートが用意されています。dsconfigを使用してJKS信頼マネージャ・プロバイダの次のプロパティを構成します:

- enabled。JKS信頼マネージャ・プロバイダが有効かどうかを示します。JKS信頼マネージャ・プロバイダは、このプロパティの値がtrueの場合を除き、他のサーバー・コンポーネントによって使用されることはありません。

- trust-store-file トラスト・ストア・ファイルへのパスは通常、config/truststoreですが、必要に応じて別のファイルを使用することもできます。このプロパティの値は絶対パスかINSTANCE_DIRに対する相対パスです。

- trust-store-type トラスト・ストアの形式。JKSトラスト・ストア・プロバイダの場合、このプロパティの値はJKSです。

次の例ではインタラクティブ・モードでdsconfigを使用して、JKS信頼マネージャ・プロバイダを構成します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X \
set-trust-manager-provider-prop --provider-name "JKS"

構成可能なプロパティのリストは、Oracle Unified Directory構成リファレンスのファイル・ベースの信頼マネージャ・プロバイダの構成に関する項を参照してください。

20.3.4 PKCS #12信頼マネージャ・プロバイダの使用

PKCS #12信頼マネージャ・プロバイダは主に、PKCS #12ファイルで使用されるピアまたは発行者の証明書をすでに持っている場合に便利です。この形式の証明書を持っていない場合は、かわりにJKS信頼マネージャ・プロバイダを使用します。Java keytoolユーティリティは現在、信頼された(公開鍵のみで秘密鍵を持たない)証明書のPKCS #12ファイルへのインポートをサポートしていません。

Oracle Unified Directoryには、PKCS #12信頼マネージャ・プロバイダのテンプレートが用意されています。dsconfigを使用してPKCS #12信頼マネージャ・プロバイダの次のプロパティを構成します:

- enabled。PKCS #12信頼マネージャ・プロバイダが有効かどうかを示します。信頼マネージャ・プロバイダは、このプロパティの値がtrueの場合を除き、他のサーバー・コンポーネントによって使用されることはありません。

- trust-store-type トラスト・ストアの形式を指定します。PKCS #12信頼マネージャ・プロバイダの場合、値はPKCS12です。

- trust-store-file トラスト・ストア・ファイルへのパスを指定します。これは通常、config/truststore.p12ですが、必要に応じて別のファイルを使用することもできます。このプロパティの値は絶対パスかINSTANCE_DIRに対する相対パスです。

PKCS #12ファイルのコンテンツにアクセスするにはPINが必要です。この場合、次の構成属性の1つを使用してパスワードを指定する必要があります。(現在、パスワードはクリア・テキストで指定する必要があります。)

- trust-store-pinトラスト・ストアに直接アクセスするために必要なPINを指定します。

- trust-store-pin-fileトラスト・ストアにアクセスするために必要なPINを含むファイルへのパスを指定します。このプロパティの値は絶対パスかサーバー・ルートに対する相対パスです。

- trust-store-pin-propertyトラスト・ストアへのアクセスに必要なPINが格納されたJavaプロパティの名前を指定します。

- trust-store-pin-environment-variableトラスト・ストアへのアクセスに必要なPINが格納された環境変数の名前を指定します。
次の例では、インタラクティブ・モードでdsconfigを使用して、PKCS #12信頼マネージャ・プロバイダを構成します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X \
set-trust-manager-provider-prop --provider-name "PKCS12"

構成可能なプロパティのリストは、Oracle Unified Directory構成リファレンスのファイル・ベースの信頼マネージャ・プロバイダの構成に関する項を参照してください。

20.3.5 ODSMによる信頼マネージャの構成

次のようにODSMを使用して、信頼マネージャの構成を管理できます:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「構成」タブを選択します。

3. 「一般構成」の下の「信頼マネージャ」項目を開きます。

4. 構成する信頼マネージャを選択します。
信頼マネージャの構成可能なプロパティが右側のペインに表示されます。

5. 必要に応じて、信頼マネージャの構成を編集し、変更を保存するために「適用」をクリックします。

20.4 証明書マッパーの構成

証明書マッパーは、クライアントによって提出された証明書を検査し、その証明書と関連づけられるディレクトリ内のユーザーにそれをマップします。

証明書マッパーは、ディレクトリ・サーバー・インスタンスのみに構成されます。プロキシ・インスタンスやゲートウェイ・インスタンスには構成されません。

証明書マッパーは、主にSASL EXTERNAL認証を処理するために使用されます。クライアントはSASL EXTERNAL認証で、パスワードやその他の形式の資格証明より、SSL証明書を使用してサーバーの認証を受けようとします。

Oracle Unified Directoryはデフォルトで次の証明書マッパーを提供します:

- Subject Equals DN

- サブジェクト属性からユーザー属性への証明書マッパー

- サブジェクトDNからユーザー属性への証明書マッパー

- フィンガープリント・マッパー

ユーザーのデプロイ要件に合せて、カスタムの証明書マッパーを作成することもできます。

証明書マッパーは、グローバル・サーバー構成レベルかネットワーク・グループ・レベルかのいずれかで定義されます。証明書マッパーがネットワーク・グループで定義されると、それによってグローバル・サーバー構成で定義された証明書マッパーが置き換えられます。ネットワーク・グループで定義された証明書マッパーがない場合は、グローバル証明書マッパーが使用されます。使用すべき証明書マッパーを定義するには、グローバル構成またはネットワーク・グループのcertificate-mapperプロパティを設定します。

この項の例では、dsconfigコマンドを使用して証明書マッパーを変更します。dsconfigコマンドは、管理コネクタを使用してSSL上でサーバー構成にアクセスします。詳細は、第14.1項「dsconfigを使用したサーバー構成の管理」を参照してください。

20.4.1 Subject Equals DN証明書マッパーの使用

Subject Equals DN証明書マッパーは、クライアント証明書のサブジェクトが対応するユーザー・エントリの識別名(DN)と同一であることを期待する単純な証明書マッパーです。この証明書マッパーの使用は、関連付けられた構成属性がないため簡単です。ただし、証明書のサブジェクトとユーザーDNは異なることが多いため、このマッパーはほとんどの環境に適していません。

サーバーはデフォルトでSubject Equals DN証明書マッパーを使用します。サーバーが使用する証明書マッパーを変更するには、dsconfigを使用して適切なグローバル構成プロパティを設定します。次のコマンドにより、サーバーが使用する証明書マッパーが、Subject Equals DNからサブジェクト属性からユーザーに置き換えられます。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
set-global-configuration-prop \  --set certificate-mapper:"Subject Attribute to User Attribute"

グローバル・サーバー構成によって参照される場合、Subject Equals DN証明書マッパーは無効にできません。マッパーを無効にするには、前述のとおりデフォルトの証明書マッパーを変更する必要があります。

20.4.2 サブジェクト属性からユーザー属性証明書マッパーの使用

サブジェクト属性からユーザー属性証明書マッパーは、それらが共通に持つ属性セットに基づいてクライアント証明書をユーザー・エントリにマップします。具体的には、証明書サブジェクトから指定の属性セットの値を取得し、対応する属性セットに同一値を持つユーザー・エントリを検索します。

dsconfigを使用して、この証明書マッパーのプロパティを設定します:

- subject-attribute-mapping 証明書サブジェクトからの属性をユーザー・エントリの属性にマップする複数値プロパティです。この属性の値は、証明書サブジェクトの中の属性名、コロン、ユーザーのエントリの中の対応する属性名で構成されます。たとえば、値e:mailは、証明書サブジェクトからのe 属性をユーザー・エントリのmail属性にマップします。1つ以上の属性マッピングを定義する必要があります。デフォルトのマッピングは、e:mailとcn:cnです。

- user-base-dn ベースDNのセットを指定する複数値プロパティです。サーバーは、このDN下で一致するエントリを探します。この属性に値がないと、サーバーはすべてのパブリック・ネーミング・コンテキストを検索します。

次の例では、dsconfigを使用してサブジェクト属性からユーザー属性証明書マッパーを構成します。このとき、サーバーの検索範囲をou=people,dc=example,dc=comの下に限定します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
set-certificate-mapper-prop \
--mapper-name "Subject Attribute to User Attribute" \
--set user-base-dn:ou=people,dc=example,dc=com

複数の属性マッピングが定義されていると、それらを組み合せてAND検索を実行します。たとえば、2つのマッピングcn:cnとe:mailが定義されていると、サブジェクトE=john.doe@example.com,CN=John Doe,O=Example Corp,C=USを持つ証明書がサーバーに提出されると、検索フィルタ(&(cn=John Doe)(mail=john.doe@example.com))が生成されます。マッピングが定義されていても証明書サブジェクトに含まれていない属性は、生成された検索フィルタには含まれません。生成された検索フィルタに使用できる属性はすべて、この証明書マッパーによって検索可能なすべてのリモートLDAPデータベース内の索引と対応している必要があります。

マッピングを成功させるには、生成された検索フィルタをディレクトリ(マッパーのベースDNの範囲内)の中の1人のユーザーと正確に一致させる必要があります。生成された条件と一致するユーザーがいないか、複数のユーザーが一致すると、マッピングは失敗します。

20.4.3 サブジェクトDNからユーザー属性への証明書マッパーの使用

サブジェクトDNからユーザー属性への証明書マッパーは、提出された証明書のサブジェクトをユーザー・エントリ内の指定された属性内で検索することによってマッピングを確立しようとします。この場合、ユーザー・エントリに、それらのユーザーと関連付けられた証明書のサブジェクトが移入されるようにする必要があります。ただし、このプロセスは、ユーザー・エントリに含まれるすべての証明書を自動的に識別し、それらの証明書のサブジェクトを別の属性に追加するプラグインによって将来自動化される可能性があります。

dsconfigを使用して、この証明書マッパーのプロパティを設定します:

- subject-attribute これは単一値属性で、値はユーザー・エントリ内に証明書サブジェクトを含む属性タイプの名前です。この属性はサーバー・スキーマ内で定義されます。これには、検索対象のすべてのバックエンド内で等価索引を設定する必要があります。
サーバーによって受信された証明書のサブジェクトDNには、証明書がRDNコンポーネントによって作成された場合でも、それらのコンポーネントの間にスペースは含まれません。ユーザー・エントリ内のsubject-attributeの値でも、RDNコンポーネント間にスペースを含めないようにして、受信した証明書のサブジェクトDNと正確に一致させます。元の証明書の例を以下に示します:

keytool -printcert -file cert.002
Owner: CN=test,  O=Test Certificate
Issuer: CN=test,  O=Test Certificate
Serial number: 49b55976
Valid from: Mon Mar 09 19:01:26 MET 2009 until: Sat Mar 08 19:01:26 MET 2014
Certificate fingerprints:
MD5:  5E:08:78:36:DF:25:F4:6C:43:9E:7B:CF:1F:1E:B9:6B
SHA1: B7:B9:1C:A0:B0:52:C3:87:3C:C2:70:27:11:6F:5E:58:C5:33:9D:6B
Signature algorithm name: SHA1withRSA
Version: 3

ユーザー・エントリのサブジェクト属性に定義されたサブジェクトDNは次のとおりです:

CN=test,O=Test Certificate

subject-attributeのRDNコンポーネント間のスペースを削除します。

- user-base-dn これはベースDNのセットを指定する複数値属性です。サーバーは、このDN下で一致するエントリを探します。この属性に値がないと、サーバーはすべてのパブリック・ネーミング・コンテキストを検索します。

次の例では、dsconfigを使用してサブジェクトDNからユーザー属性への証明書マッパーを構成します。このとき、サーバーの検索範囲をou=people,dc=example,dc=comの下に限定します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
set-certificate-mapper-prop \
--mapper-name "Subject DN to User Attribute" \
--set user-base-dn:ou=people,dc=example,dc=com

ユーザーが持っている証明書のサブジェクトを保持する標準の属性はありませんが、この目的に使用できるカスタム属性タイプds-certificate-subject-dnを定義します。この属性は、ds-certificate-user補助オブジェクト・クラスとともにユーザー・エントリに追加できます。これは複数値属性です。ユーザーが複数の証明書を持つ場合、各証明書のサブジェクトが別個の値として属性に含まれる必要があります。

この属性には、デフォルトで索引が設定されません。このため、使用する場合は、対応するバックエンドを更新して、この属性の等価索引が含まれるようにします。

マッピングを成功させるには、証明書マッパーを(マッパーのベースDNの範囲内の)1人のユーザーと正確に一致させる必要があります。一致するエントリがないか、複数のエントリが一致すると、マッピングは失敗します。

20.4.4 フィンガープリント証明書マッパーの使用

フィンガープリント証明書マッパーは、ユーザー・エントリ内の指定された属性で、提出された証明書のMD5またはSHA1フィンガープリントを検索することによってマッピングを確立しようとします。この場合、ユーザー・エントリに、証明書フィンガープリントが移入されるようにする必要があります。フィンガープリントは標準の16進表記で、各バイトはコロンで区切られます(例: 07:5A:AB:4B:E1:DD:E3:05:83:C0:FE:5F:A3:E8:1E:EB)。将来、このプロセスは、ユーザー・エントリに含まれるすべての証明書を自動的に識別し、それらの証明書のフィンガープリントを適切な属性に追加するプラグインによって自動化される可能性があります。

dsconfigを使用して、この証明書マッパーのプロパティを設定します:

- fingerprint-attribute単一値属性を指定します。その値は、ユーザー・エントリ内の証明書フィンガープリントを含む属性タイプの名前です。この属性はサーバー・スキーマ内で定義する必要があります。また、検索対象のすべてのバックエンド内で等価索引を設定する必要があります。

- fingerprint-algorithm証明書フィンガープリントを計算するために、そのダイジェスト・アルゴリズムを使用するのか指定します。値はMD5かSHA1のいずれかです。

- user-base-dn ベースDNのセットを指定する複数値属性を指定します。サーバーは、このDN下で一致するエントリを探します。このプロパティがないと、サーバーはすべてのパブリック・ネーミング・コンテキストを検索します。

次の例では、dsconfigを使用してフィンガープリント証明書マッパーを構成します。このとき、サーバーの検索範囲をou=people,dc=example,dc=comの下に限定します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
set-certificate-mapper-prop \
--mapper-name "Fingerprint Mapper" \
--set user-base-dn:ou=people,dc=example,dc=com

証明書フィンガープリントを保持する標準の属性はありませんが、この目的に使用できるカスタム属性タイプds-certificate-fingerprintを定義します。この属性は、ds-certificate-user補助オブジェクト・クラスとともにユーザー・エントリに追加できます。これは複数値属性です。ユーザーが複数の証明書を持つ場合、各証明書のフィンガープリントが別個の値として属性に含まれる必要があります。ただし、どのサーバー・バックエンドでも、この属性タイプにはデフォルトで索引が設定されません。このため、使用する場合は、すべての対応するバックエンドに、この属性の等価索引を追加します。

マッピングを成功させるには、証明書マッパーを(マッパーのベースDNの範囲内の)1人のユーザーと正確に一致させる必要があります。一致するエントリがないか、複数のエントリが一致すると、マッピングは失敗します。

20.5 LDAPおよびJMX用のSSLおよびStartTLSの構成

1つ以上の有効なキー・マネージャ・プロバイダとともにOracle Unified Directoryを構成したときに、接続ハンドラにSSLおよびStartTLSを有効にできます。

この項の例では、dsconfigコマンドを使用してサーバー構成を変更します。dsconfigコマンドは、管理コネクタを使用してSSL上でサーバー構成にアクセスします。SSL証明書を信頼する方法を含めて、適切な接続オプションを指定する必要があります。これらの例では、-Xオプションを使用してすべての証明書を信頼します。

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

- 第20.5.1項「LDAPおよびLDAPS接続ハンドラの構成」

- 第20.5.2項「JMX接続ハンドラでのSSLの有効化」

20.5.1 LDAPおよびLDAPS接続ハンドラの構成

LDAP接続ハンドラは、LDAPを使用したクライアントとのすべての通信の管理に責任を持ちます。デフォルトでは、LDAPプロトコルは通信を保護するためのどのような形のセキュリティも指定しませんが、SSLを使用するか、StartTLS拡張操作の使用を許可するように構成できます。

サーバーは、このために使用できる2つの接続ハンドラを構成します。LDAP接続ハンドラ・エントリがデフォルトで有効にされており、暗号化されていないLDAP通信に使用される場合、StartTLSをサポートするように構成することもできます。詳細は、「StartTLSサポートを有効化する方法」を参照してください。LDAPS接続ハンドラ・エントリは無効にされますが、デフォルト構成はSSLベース接続を有効化するためにセットアップされます。

この項では、dsconfigを使用してLDAPおよびLDAPS接続ハンドラ・パラメータを構成する方法について説明します:

- 第20.5.1.1項「接続ハンドラを有効化する方法」

- 第20.5.1.2項「接続ハンドラのリスニング・ポートを指定する方法」

- 第20.5.1.3項「接続ハンドラの認可ポリシーを指定する方法」

- 第20.5.1.4項「接続ハンドラの証明書にニックネームを指定する方法」

- 第20.5.1.5項「接続ハンドラのキー・マネージャ・プロバイダを指定する方法」

- 第20.5.1.6項「接続ハンドラの信頼マネージャ・プロバイダを指定する方法」

- 第20.5.1.7項「StartTLSサポートを有効化する方法」

- 第20.5.1.8項「SSLベースの通信を有効化する方法」

20.5.1.1 接続ハンドラを有効化する方法

接続ハンドラのenabledプロパティをtrueに設定します。

この例ではLDAP接続ハンドラを有効化します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
set-connection-handler-prop --handler-name "LDAP Connection Handler" \
--set enabled:true

20.5.1.2 接続ハンドラのリスニング・ポートを指定する方法

接続ハンドラのlisten-portプロパティを設定します。

listen-portプロパティは、この接続ハンドラを通してサーバーと通信するときに使用するポート番号を指定します。暗号化されていないLDAP通信(またはStartTLSを使用するLDAP)に使用する標準ポートは389です。SSL暗号化LDAP用の標準ポートは636です。ただし、環境によっては、これを変更したほうがいい場合や変更する必要がある場合もあります(たとえば、標準ポートがすでに使用されていたり、1024以下のポートをブラインドできる十分な権限のないユーザーとしてUNIXシステムで実行中の場合など)。

この例ではLDAPS接続ハンドラのリスニング・ポートを1636に設定します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
set-connection-handler-prop --handler-name "LDAPS Connection Handler" \
--set listen-port:1636

20.5.1.3 接続ハンドラの認可ポリシーを指定する方法

接続ハンドラのssl-client-auth-policyプロパティを設定します。

ssl-client-auth-policyプロパティは、SSLまたはStartTLSネゴシエーション・プロセス中にクライアント証明書をリクエストするときの接続ハンドラの行動を指定します。値がoptionalの場合、サーバーはクライアントに自身の証明書の提出をリクエストしますが、クライアントが証明書を提出しない場合でも接続を許可します。値がrequiredの場合、サーバーはクライアントに自身の証明書の提出をリクエストし、クライアントがそれに応じないと接続をすべて拒否します。値がdisabledの場合、サーバーはクライアントに自身の証明書の提出をリクエストしません。

この例では、LDAPS接続ハンドラの認可ポリシーをrequiredに設定します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
set-connection-handler-prop --handler-name "LDAPS Connection Handler" \
--set ssl-client-auth-policy:required

20.5.1.4 接続ハンドラの証明書にニックネームを指定する方法

接続ハンドラのssl-cert-nicknameプロパティを設定します。

ssl-cert-nicknameプロパティは、SSLまたはStartTLSネゴシエーション中にサーバーがクライアントに提出する証明書のニックネームを指定します。このプロパティは主に、複数の証明書がキーストアに存在し、リスナー・インスタンスにどの証明書を使用すべきか指定するときに便利です。

この例ではLDAP接続ハンドラの証明書のニックネームをserver-certに設定します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
set-connection-handler-prop --handler-name "LDAP Connection Handler" \
--set ssl-cert-nickname:server-cert

20.5.1.5 接続ハンドラのキー・マネージャ・プロバイダを指定する方法

接続ハンドラのkey-manager-providerプロパティを設定します。

key-manager-providerプロパティは、構成されたキー・マネージャ・プロバイダの中から、接続ハンドラがSSLまたはStartTLSネゴシエーションのための鍵情報を取得するために使用するキー・マネージャ・プロバイダを指定します。

この例ではこの例ではLDAP接続ハンドラのキー・マネージャ・プロバイダをJKSに設定します。コマンドを実行するには、指定されたキー・マネージャが構成済である必要があります。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
set-connection-handler-prop --handler-name "LDAP Connection Handler" \
--set key-manager-provider:JKS

20.5.1.6 接続ハンドラの信頼マネージャ・プロバイダを指定する方法

接続ハンドラのtrust-manager-providerプロパティを設定します。

trust-manager-providerプロパティは、構成された信頼マネージャ・プロバイダの中から、接続ハンドラが提出されたクライアント証明書を信頼すべきかどうか判断するために使用する信頼マネージャ・プロバイダを指定します。

この例ではLDAP接続ハンドラの信頼マネージャをJKSに設定します。コマンドを実行するには、指定されたキー・マネージャが構成済である必要があります。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
set-connection-handler-prop --handler-name "LDAP Connection Handler" \
--set trust-manager-provider:JKS

20.5.1.7 StartTLSサポートを有効化する方法

1. key-manager-providerおよびtrust-manager-providerプロパティに適切な値を設定します。

2. allow-start-tlsプロパティを次のようにtrueに設定します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
set-connection-handler-prop --handler-name "LDAP Connection Handler" \
--set allow-start-tls:true

注意:

SSLが有効だと、allow-start-tlsプロパティを設定できません。

StartTLSは、プロキシ・サーバーとリモートLDAPサーバー間の接続ではサポートされません。リモートLDAPサーバーのSSLポリシーの設定によっては、StartTLSクライアント接続がプロキシからリモートLDAPサーバーへのSSL接続または安全でない接続として渡されることがあります。詳細は、グローバル索引を含むグローバル索引カタログの作成方法を参照してください。

20.5.1.8 SSLベースの通信を有効化する方法

1. 接続ハンドラのプロパティを表示して、構成されたキー・マネージャ・プロバイダおよび信頼マネージャ・プロバイダの値が正しいことを確認できます。
次の例では、LDAPS接続ハンドラのプロパティを表示します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
get-connection-handler-prop --handler-name "LDAPS Connection Handler"

2. enabledプロパティを次のようにtrueに設定します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
set-connection-handler-prop --handler-name "LDAPS Connection Handler" \
--set enabled:true

注意:

SSLが有効だと、接続ハンドラ・インスタンスはSSL以外の通信を使用できません。

20.5.2 JMX接続ハンドラでのSSLの有効化

JMX接続ハンドラは、JMX (Java Management Extensions)プロトコルを使用してクライアントと通信できます。このプロトコルでは、StartTLSを使用して同一ポート上で暗号化通信と非暗号化通信の両方を許可できませんが、暗号化されないJMX通信、またはSSL暗号化JMX通信のいずれか一方を許可するように構成できます。

JMX接続ハンドラは、JMX上の通信のためのサーバーのデフォルト構成を提供します。この接続ハンドラでSSLを有効化するには、dsconfigを使用して次の構成属性を設定します:

- key-manager-provider接続ハンドラがSSLネゴシエーションのための鍵情報を取得するために使用するキー・マネージャ・プロバイダの構成エントリのDNを指定します。

- ssl-cert-nicknameクライアントに提出される証明書のニックネーム(または別名)を指定します。

- use-ssl接続ハンドラがSSLを使用してクライアントと通信するかどうかを示します。

次の例ではインタラクティブ・モードでdsconfigを使用してJMX接続ハンドラを構成します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X \
set-connection-handler-prop --handler-name "JMX Connection Handler"

構成可能なプロパティのリストは、Oracle Unified Directory構成リファレンスのJMX接続ハンドラの構成に関する項を参照してください。

20.6 SASL認証の使用

LDAPプロトコル定義には、クライアントがサーバーの認証を受けるための2つの方法、つまりLDAP簡易認証とSASL認証が提供されています。

注意:

SASLは、プロキシ・サーバー・インスタンスでの使用がサポートされていません。

LDAP簡易認証では、クライアントはユーザーのDNおよびパスワードを指定します。これは最も一般的な認証メカニズムであり、通常は最も使用法が簡単です。ただし、次のような多数の制約があります:

- ユーザーは常に完全なDNを指定する必要があります。ユーザー名のようなユーザー・フレンドリなものに置き換えられません。

- パスワード・ベースの認証のみ許可されます。

- クライアントは完全なクリアテキスト・パスワードをサーバーに提供する必要があります。

これらの問題を解決するために、SASL (Simple Authentication and Security Layer)を使用してクライアントと通信することもできます(SASLの定義はRFC 4422 http://www.ietf.org/rfc/rfc4422.txtを参照)。これは非常に広範なフレームワークであり、サーバーに多数の認証方法のサポートを可能にします。

20.6.1 サポートされているSASLメカニズム

現在、次のSASLメカニズムがサポートされています:

注意:

プロキシ・サーバーで現在サポートされている唯一のSASLメカニズムはANONYMOUSです。

ANONYMOUS

このメカニズムは実際にはクライアントを認証しませんが、デバッグ用のサーバー・ログにトレース情報を含めるメカニズムを提供します。

CRAM-MD5

このメカニズムは後方互換背のために提供されています。本番環境では、CRAM-MD5を構成しないでください。かわりに、より安全なDIGEST-MD5メカニズムを使用します。

DIGEST-MD5

このメカニズムにより、クライアントはサーバーにパスワードを送信せずにパスワードベースの認証を使用できます。そのかわりに、クライアントは単にパスワードを知っているという情報を提供するだけです。このメカニズムはCRAM-MD5より多くのオプションとセキュリティを提供します。

EXTERNAL

このメカニズムにより、クライアントはLDAP通信の直接のフローの外部で提供される情報に基づき自身を識別できます。Oracle Unified Directoryでは、これはSSLクライアント証明書の使用を通して可能です。

GSSAPI

このメカニズムにより、クライアントはKerberos V5環境への参加を通してサーバーから認証を受けることができます。

PLAIN

このメカニズムはパスワードベースの認証を使用しますが、DNでなくユーザー名を使用できます。

追加のSASLメカニズムのサポートは、サーバーにカスタムのSASLメカニズム・ハンドラを実装することにより追加できます。

SASLメカニズムは非常に拡張性が高いため、認証を実行するためにクライアントがサーバーに提供する必要がある情報はメカニズムごとに異なります。そのため、Oracle Unified Directoryクライアントはユーザー用の汎用インタフェースを使用してこの情報を提供します。これは、-oまたは--saslOption引数を通して公開されます。この引数の値は、名前と値のペアである必要があります。mechオプションを使用して、使用するSASLメカニズムを選択します。例:

--saslOption mech=DIGEST-MD5

使用可能なその他のオプションは、選択されたSASLメカニズムによって異なります。これについては以下の項で説明します。

20.6.2 認可ID

以下の多数のSASLメカニズムは、ユーザーDNでなく、認可IDに基づいてユーザーを識別できる機能を提供します。認可IDは次のいずれかの形式で指定します:

dn:dn

これには、認証のためにユーザーの完全なDNを指定します(例: dn:uid=john.doe,ou=People,dc=example,dc=com)。dn:の値にDNが指定されないと、匿名ユーザーとして取り扱われます。この形式は以下に示す多数のSASLメカニズムによって拒否されます。

u:username

これには完全なDNでなく、ユーザーのユーザー名を指定します(例: u:john.doe)。

u:username形式を使用した場合、そのユーザー名を対応するユーザー・エントリに変換するためにサーバーによって使用されるメカニズムは、サーバー内のIDマッピング構成に基づきます。

20.6.3 ANONYMOUSメカニズムのSASLオプション

ANONYMOUSメカニズムは、実際には認証の実行には使用されません。これに追加の必須オプションはありません。ただし、次のオプションを指定できます:

trace

サーバーのアクセス・ログに書き込まれるトレース文字列を指定するために使用します。これはデバッグやクライアントの識別に便利です。ただし、認証せずにこの値の妥当性を信頼することはできません。

次のコマンドはSASL匿名認証の使用例を示します:

$ ldapsearch --hostname server.example.com --port 1389 --saslOption mech=ANONYMOUS \
--saslOption "trace=Example Trace String" --baseDN "" \
--searchScope base "(objectClass=*)"

20.6.4 CRAM-MD5メカニズムのSASLオプション

CRAM-MD5メカニズムにより、サーバーにクリアテキスト・パスワードを送信せずにパスワードベースの認証を実行できます。クリアテキスト・パスワードとサーバーによって提供されるランダム生成されたデータを組み合せたMD5ダイジェストを提供することによって認証が実行されます。これはリプレーアタックの防止に役立ちます。

SASL CRAM-MD5メカニズムには、指定する必要がある1つのSASLオプションがあります:

authid

これはサーバーの認証を受けるユーザーのIDを指定します。これは前述の認可IDの値です。

パスワードは、簡易認証を使用するときと同様に--bindPasswordオプションか--bindPasswordFileオプションのいずれかを使用して指定します。次のコマンドは、SASL CRAM-MD5認証の使用例を示します:

ldapsearch --hostname server.example.com --port 1389 --saslOption mech=CRAM-MD5 \
--saslOption authid=u:john.doe --baseDN "" --searchScope base "(objectClass=*)"

20.6.5 DIGEST-MD5メカニズムのSASLオプション

DIGEST-MD5メカニズムはCRAM-MD5メカニズムと類似していますが、クライアントとサーバーの両方からのランダムなデータを組み合せるため、安全性が増し、リプレーアタックや介入者攻撃の両方に有効です。DIGEST-MD5認証はまた、以下を含む多数のSASLオプションを提供します:

authid

サーバーの認証を受けるユーザーのIDを指定します。このオプションは必須です。

realm

このオプションはDNとして指定しないでください。

注意:

realmオプションは使用しないでください。これはサーバーがIDをマッピングするときに使用されません。

digest-uri

クライアントがサーバーとの通信に使用するダイジェストURIを指定します。これはオプションのパラメータです。指定する場合は、ldap/serveraddress形式を使用します。serveraddressは完全修飾のサーバー・アドレスです。

注意:

本番環境ではdigest-uriオプションを使用しないでください。

authzid

認証プロセス中に使用される認可IDを指定します。このオプションは、認証後の接続でリクエストされた操作が別のユーザーの認可の元で実行されることを示すために使用できます。

パスワードは、簡易認証を使用するときと同様に--bindPasswordオプションか--bindPasswordFileオプションのいずれかを使用して指定します。次のコマンドは、SASL DIGEST-MD5認証の使用例を示します:

$ ldapsearch --hostname server.example.com --port 1389 --saslOption mech=DIGEST-MD5 \
--saslOption authid=u:john.doe --saslOption realm=dc=example,dc=com --baseDN "" \
--searchScope base "(objectClass=*)"

20.6.6 EXTERNALメカニズムのSASLオプション

EXTERNALメカニズムを使用して、LDAPセッションの外部にあるサーバーが使用できる情報に基づいて認証を実行します。現在、これはSSLクライアント認証によってのみ使用可能です。この場合、クライアントのSSL証明書がクライアントの認証に使用されます。そのため、サーバーと通信するときにはSSLまたはStartTLSを使用し、クライアント証明書キーストアが使用できる必要があります。

EXTERNALメカニズムは追加のSASLオプションをサポートしません。通常は、--saslOption mech=EXTERNALまたは--useSASLExternalのいずれかを使用してリクエストできます。次のコマンドは、SASL EXTERNAL認証の使用例を示します:

$ ldapsearch --hostname server.example.com --port 1636 --useSSL \
--keyStorePath /path/to/key.store --keyStorePasswordFile /path/to/key.store.pin \
--trustStorePath /path/to/trust.store --saslOption mech=EXTERNAL --baseDN "" \
--searchScope base "(objectClass=*)"

詳細は、SASL External認証の構成を参照してください。

20.6.7 GSSAPIメカニズムのSASLオプション

GSSAPIメカニズムは、Kerberos V5環境で認証を実行するために使用され、クライアント・システムを構成して、このような環境に参加させます。GSSAPIメカニズムで使用できるオプションは次のとおりです:

authid

ユーザーを識別するために使用される認証IDを指定します。IDは、前述の認可IDの形式でなく、Kerberosプリンシパルの形式で指定する必要があります。バインドを試みる前に、ユーザーがKerberos認証を使用しない場合は、このオプションを指定する必要があります。

authzid

認可処理の実行対象となるユーザーを識別するための認可IDを指定します。この機能はまだサポートされていません。

quality-of-protection

通信に使用する保護の質を指定します。現在クライアントによってサポートされるquality-of-protectionの値はauthのみです。サーバーによってサポートされる値は、auth-intとauth-confです。

ユーザーがGSSAPIの使用を試みるときに、システム上にすでに有効なKerberosチケットを持っている場合、クライアントがそれを使用するとパスワードが不要になります。ただし、ユーザーが有効なKerberosチケットを持っていないか、チケットが受け入れられない場合は、--bindPasswordオプションか--bindPasswordFileオプションのいずれかを使用してパスワードを指定する必要があります。

次のコマンドは、すでに有効なKerberosセッションを持つユーザーに対するSASL GSSAPI認証の使用例を示します:

$ ldapsearch --hostname server.example.com --port 1389 --saslOption mech=GSSAPI \
--saslOption authid=jdoe@EXAMPLE.COM --baseDN "" --searchScope base "(objectClass=*)"

20.6.8 PLAINメカニズムのSASLオプション

PLAINメカニズムは、LDAP簡易認証と同一の機能を多数提供しますが、ユーザーは通常、完全DNでなく認可IDの形式で識別されます。SASL PLAIN認証を使用するときに、次のオプションを使用できます:

authid

サーバーの認証を受けるユーザーのIDを指定します。これは前述の認可IDの値です。このオプションは必須です。

authzid

認可処理の実行対象となるユーザーのIDを指定します。認可IDの形式で指定する必要があります。この機能はまだサポートされていません。

パスワードは、簡易認証を使用するときと同様に--bindPasswordオプションか--bindPasswordFileオプションのいずれかを使用して指定します。次のコマンドは、SASL PLAIN認証の使用例を示します:

$ ldapsearch --hostname server.example.com --port 1389 --saslOption mech=PLAIN \
--saslOption authid=u:john.doe --baseDN "" --searchScope base "(objectClass=*)"

20.7 SASL認証の構成

この項では、多様なSASL認証メカニズムを使用するためにディレクトリ・サーバーを構成するための要件について説明します。

注意:

SASLは、プロキシ・サーバー・インスタンスでの使用がサポートされていません。

20.7.1 SASL EXTERNAL認証の構成

SASL EXTERNALメカニズムは、厳密なLDAP通信の外部で提供される情報を使用して、クライアントがサーバーに認証してもらうために使用できます。現在、LDAP通信にかぎり、SSLまたはStartTLSネゴシエーション中にサーバーに提示されたクライアント証明書を使用する認証がサポートされます。

20.7.1.1 SASL EXTERNAL認証を可能にするためのLDAP接続ハンドラの構成

ディレクト・サーバーがクライアント証明書をユーザー・エントリにマッピングするには、クライアント証明書を処理できるように接続ハンドラを構成する必要があります。dsconfigを使用して次のLDAP接続ハンドラのプロパティを構成します:

- ssl-client-auth-policySSLまたはStartTLSネゴシエーション・プロセス中にクライアント証明書の提出をクライアントに要求するかどうかを指定します。SASL EXTERNAL認証をサポートするには、optionalかrequiredか、どちらかの値を指定します。値がdisabledの場合、クライアントは証明書の提出を求められず、認証に使用できる証明書はありません。

- trust-manager-providerディレクトリ・サーバーがクライアント証明書の妥当性を信頼するかどうか判断するために使用される信頼マネージャ・プロバイダのDNを指定します。サーバーがクライアント証明書を信頼しない場合、SSLまたはStartTLSネゴシエーションは失敗し、クライアントはSASL EXTERNAL認証をリクエストできません。サーバーが正当でないクライアント証明書を信頼した場合、悪意のあるユーザーは証明書を偽造してディレクトリ内の任意のユーザーになりすますことができます。通常は、JKSまたはPKCS12信頼マネージャ・プロバイダを使用し、対応するトラスト・ストアはクライアント証明書の署名に使用される発行者証明書のみを使用してロードされる必要があります。

注意:

dsconfigコマンドは、管理コネクタを使用してSSL上でサーバー構成にアクセスします。SSL証明書を信頼する方法を含めて、適切な接続オプションを指定する必要があります。これらの例では、-Xオプションを使用してすべての証明書を信頼します。

次の例では、インタラクティブ・モードでdsconfigを使用してLDAP接続ハンドラのプロパティを設定します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager"-j pwd-file -X \
set-connection-handler-prop --handler-name "LDAP Connection Handler"

構成可能なプロパティのリストは、Oracle Unified Directory構成リファレンスのLDAP接続ハンドラの構成に関する項を参照してください。

20.7.1.2 EXTERNAL SASLメカニズム・ハンドラの構成

SASL EXTERNALバインド・リクエストは、SASLメカニズム・ハンドラによって処理されます。dsconfigコマンドを使用して、次のSASLメカニズム・ハンドラのプロパティを設定します:

- java-classSASLメカニズム・ハンドラのロジックを提供するJavaクラスの完全修飾名を指定します。EXTERNALメカニズムの場合、この値は常にorg.opends.server.extensions.ExternalSASLMechanismHandlerです。拡張プロパティ。

- enabled。EXTERNAL SASLメカニズムが有効で、使用できるかどうかを示します。クライアントにSASL EXTERNAL認証の使用を許可しない場合は、値をfalseに変更します。

- certificate-mapper。クライアント証明書とユーザー・エントリのマッピングに使用される証明書マッパーの構成エントリのDNを指定します。

- certificate-validation-policy。マッピングの確立後に、ディレクトリ・サーバーがユーザーのエントリ内でクライアント証明書を探すかどうかを指定します。値がalwaysの場合、マッピングされたユーザーのエントリにクライアントが提出した証明書が含まれているときにのみ認証が成功します。値がifpresent (デフォルト値)で、ユーザーのエントリに1つ以上の証明書が含まれている場合、それらの証明書の1つがクライアントによって提出された証明書と一致するときにのみ認証が成功します。値がifpresentで、ユーザーのエントリに証明書が含まれていない場合でも、信頼マネージャによって受け入れられ、証明書マッパーによってマッピングされる場合は認証が成功します。値がneverの場合、ユーザーのエントリに1つ以上の証明書が含まれる場合でも、サーバーはユーザーのエントリ内で一致する証明書を探しません。

- certificate-attribute。certificate-validation-policyプロパティにalwaysまたはifpresentの値が含まれる場合に、調べられるユーザー証明書を持つ属性の名前を指定します。

次の例では、インタラクティブ・モードでdsconfigを使用してEXTERNAL SASLメカニズム・ハンドラのプロパティを設定します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager"-j pwd-file -X \
set-sasl-mechanism-handler-prop --handler-name "EXTERNAL"

構成可能なプロパティのリストは、Oracle Unified Directory構成リファレンスのSASLメカニズム・ハンドラの構成に関する項を参照してください。

20.7.2 SASL DIGEST-MD5認証の構成

この項では、認可IDキーワード(authzid)を使用するユーザーに対するアクセス制御および権限の制約について説明します。ユーザーがauthzidキーワードを使用しない場合は、これらの制約は適用されません。DIGEST-MD5およびauthzidキーワードを使用してバインドするユーザーは、次の要件を満たす必要があります:

- 認証ID (authid) は、それに認可IDへのプロキシ権限を許可するACIによってアクセスが許可される必要があります。

- 認証ID (authid)エントリには、proxied-auth権限を含める必要があります。次の例ではテスト環境を作成し、DIGEST-MD5 SASLメカニズムを使用したユーザー認証の要件を示します。

次の例ではテスト環境を作成し、DIGEST-MD5 SASLメカニズムを使用したユーザー認証の要件を示します。

1. 次のエントリをディレクトリにインポートします。これらのエントリはACIと3人のユーザーを定義します:

- エントリuid=user.0,ou=People,dc=example,dc=comは、proxied-auth権限を持ちませんが、ACIによってプロキシ・アクセスが許可されます。

- エントリuid=user.1,ou=People,dc=example,dc=comは、proxied-auth権限を持ちますが、ACIによってプロキシ・アクセスが許可されません。

- エントリuid=user.2,ou=People,dc=example,dc=comは、proxied-auth権限を持ち、ACIによってプロキシ・アクセスが許可されます。

dn: ou=People,dc=example,dc=com
objectClass: top
objectClass: organizationalunit
objectClass: posixGroup
ou: People
aci: (target="ldap:///uid=proxy user,ou=People,dc=example,dc=com") \
(targetattr="*") (version 3.0; acl "allow SASL Example"; \
allow (proxy) userdn="ldap:///uid=user.0,ou=People,dc=example,dc=com ||
ldap:///uid=user.2,ou=People,dc=example,dc=com";)

dn: uid=user.0,ou=People,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalperson
objectClass: inetorgperson
...
description: This is the description for user.0

dn: uid=user.1,ou=People,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalperson
objectClass: inetorgperson
...
description: This is the description for user.1
ds-privilege-name: proxied-auth

dn: uid=proxy user,ou=People,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalperson
objectClass: inetorgperson
...
description: This is the description for proxy user

dn: uid=user.2,ou=People,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalperson
objectClass: inetorgperson
...
description: This is the description for user.2
ds-privilege-name: proxied-auth

2. DIGEST-MD5を使用してuid=user.1,ou=People,dc=example,dc=comとしてバインドします:

$ ldapsearch --port 1389 -j pwd-file --saslOption mech=DIGEST-MD5 \
--saslOption authid=dn:uid=user.1,ou=People,dc=example,dc=com --saslOption \
authzid=dn:uid=proxy user,ou=People,dc=example,dc=com --baseDN "" \
--searchScope base "(objectClass=*)"
The SASL DIGEST-MD5 bind attempt failed Result Code: 49 (Invalid Credentials)

uid=user.1,ou=People,dc=example,dc=comはACIによってプロキシ権限が許可されないため、検索は失敗します。

3. uid=user.0,ou=People,dc=example,dc=comとしてDIGEST-MD5を使用してバインドします:

$ ldapsearch --port 1389 -j pwd-file --saslOption mech=DIGEST-MD5 \
--saslOption authid=dn:uid=user.0,ou=People,dc=example,dc=com --saslOption \
authzid=dn:uid=proxy user,ou=People,dc=example,dc=com --baseDN "" \
--searchScope base "(objectClass=*)"
The SASL DIGEST-MD5 bind attempt failed Result Code: 49 (Invalid Credentials)

uid=user.0,ou=People,dc=example,dc=comがproxied-authプロパティを持たないため、検索は失敗します。

4. アクセス制御アクセスとproxied-auth権限の両方を持つuid=user.2,ou=People,dc=example,dc=com authidとしてDIGEST-MD5を使用してバインドします:

$ ldapsearch --port 1389 -j pwd-file --saslOption mech=DIGEST-MD5 \
--saslOption authid=dn:uid=user.2,ou=People,dc=example,dc=com --saslOption \
authzid=dn:uid=proxy user,ou=People,dc=example,dc=com --baseDN "" \
--searchScope base "(objectClass=*)"
dn:
objectClass: ds-root-dse
objectClass: top

uid=user.2,ou=People,dc=example,dc=comはproxied-auth権限を持ち、ACIによってアクセスが許可されるため、検索は成功します。

20.7.3 SASL GSSAPI認証の構成

この項では、認可IDキーワード(authzid)を使用するユーザーに対するアクセス制御および権限の制約について説明します。ユーザーがauthzidキーワードを使用しない場合は、制約は適用されません。

GSSAPIを使用してバインドを実行するユーザーは、次の要件を満たす必要があります:

- 認証ID (authid) は、それに認可IDへのプロキシ権限を許可するACIによってアクセスが許可される必要があります。

- 認証ID (authid)エントリには、proxied-auth権限を含める必要があります。

次の例では3つのサンプル・エントリを含むテスト環境を作成し、GSSAPI SASLメカニズムを使用したユーザー認証の要件を示します。これらの例では、有効なキータブ・ファイルを含めて完全に構成されたKerberos環境が必要です。

1. レルムTESTLOCAL.NET内に3つのKerberosプリンシパルを作成します:

- user.0@TESTLOCAL.NET

- user.1@TESTLOCAL.NET

- user.2@TESTLOCAL.NET

2. GSSAPI SASLハンドラを構成して有効にし、正規表現アイデンティティ・マッパーを使用し、有効なTESTLOCAL.NETキータブ・ファイルを使用できるようにします。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
set-sasl-mechanism-handler-prop --handler-name "GSSAPI" \
--set enabled:true --set identity-mapper:"Regular Expression" \
--set keytab:keytabPath

GSSAPIのenabledプロパティのデフォルト値はfalseです。これをtrueに設定する必要があります。identity-mapperのデフォルト値はRegular Expressionです。keytabプロパティのデフォルト値は/etc/krb5/krb5.keytabです。

3. 次のエントリをディレクトリにインポートします。これらのエントリはACIと3人のユーザーを定義します:

- エントリuid=user.0,ou=People,dc=example,dc=comは、proxied-auth権限を持ちませんが、ACIによってプロキシ・アクセスが許可されます。

- エントリuid=user.1,ou=People,dc=example,dc=comは、proxied-auth権限を持ちますが、ACIによってプロキシ・アクセスが許可されません。

- エントリuid=user.2,ou=People,dc=example,dc=comは、proxied-auth権限を持ち、ACIによってプロキシ・アクセスが許可されます。

dn: ou=People,dc=example,dc=com
objectClass: top
objectClass: organizationalunit
objectClass: posixGroup
ou: People
aci: (target="ldap:///uid=proxy user,ou=People,dc=example,dc=com") \
(targetattr="*") (version 3.0; acl "allow SASL Example"; \
allow (proxy) userdn="ldap:///uid=user.0,ou=People,dc=example,dc=com"
|| "ldap:///uid=user.2,ou=People,dc=example,dc=com";)

dn: uid=user.0,ou=People,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalperson
objectClass: inetorgperson
uid=user.0
...
description: This is the description for user.0

dn: uid=user.1,ou=People,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalperson
objectClass: inetorgperson
uid=user.1
...
description: This is the description for user.1
ds-privilege-name: proxied-auth

dn: uid=user.2,ou=People,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalperson
objectClass: inetorgperson
uid=user.2
...
description: This is the description for user.2
ds-privilege-name: proxied-auth

dn: uid=proxy user,ou=People,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalperson
objectClass: inetorgperson
uid=proxy user
...
description: This is the description for proxy user

4. このコマンドを実行すると、Kerberosプリンシパルuser.0@TESTLOCAL.NETを使用するGSSAPI SASLバインドが失敗します:

$ ldapsearch --port 1389 \
--saslOption mech=GSSAPI \
--saslOption authid=user.0@TESTLOCAL.NET \
--saslOption authzid=dn:uid=proxy user,ou=People,dc=example,dc=com \
--baseDN "" --searchScope base "(objectClass=*)"
The SASL DIGEST-MD5 bind attempt failed
Result Code:  49 (Invalid Credentials)

user.0@TESTLOCAL.NETがuid=user.0,ou=People,dc=example,dc=comにマッピングされますが、これにはuid=proxy user,ou=People,dc=example,dc=comへのアクセス制御権限はあっても、proxied-auth権限がないため、この検索は失敗します。

5. このコマンドを実行すると、Kerberosプリンシパルuser.1@TESTLOCAL.NETを使用するGSSAPI SASLバインドが失敗します。

$ ldapsearch --port 1389 \
--saslOption mech=GSSAPI \
--saslOption authid=user.1@TESTLOCAL.NET \
--saslOption authzid=dn:uid=proxy user,ou=People,dc=example,dc=com \
--baseDN "" --searchScope base "(objectClass=*)"
The SASL DIGEST-MD5 bind attempt failed
Result Code:  49 (Invalid Credentials)

user.1@TESTLOCAL.NETがuid=user.1,ou=People,dc=example,dc=comにマッピングされますが、これにはproxied-auth権限はあってもuid=proxy user,ou=People,dc=example,dc=comへのアクセス制御権限がないため検索は失敗します。

6. このコマンドを実行すると、Kerberosプリンシパルuser.2@TESTLOCAL.NETを使用するGSSAPI SASLバインドが成功します:

$ ldapsearch --port 1389 \
--saslOption mech=GSSAPI \
--saslOption authid=user.2@TESTLOCAL.NET \
--saslOption authzid=dn:uid=proxy user,ou=People,dc=example,dc=com \
--baseDN "" --searchScope base "(objectClass=*)"
dn:
objectClass: ds-root-dse
objectClass: top }}} \\ \\

user.2@TESTLOCAL.NETがuid=user.2,ou=People,dc=example,dc=comにマッピングされますが、これにはproxied-auth権限とid=proxy user,ou=People,dc=example,dc=comへのアクセス制御権限の両方があるため検索は成功します。

20.8 GSSAPI SASL認証のためのKerberosおよびOracle Unified Directoryサーバーの構成

次の項ではGSSAPI SASL認証のためのKerberos Version 5の構成について説明します。

- ホスト上でKerberos V5を構成するには

- Kerberos認証のSASLオプションを設定するには:

- GSSAPIとSASLを使用したKerberos認証の構成例

- Kerberos構成のトラブルシューティング

20.8.1 ホスト上でKerberos V5を構成する方法

LDAPクライアントを実行するホスト・マシンでKerberos V5を構成する必要があります。

1. インストール手順に従ってKerberos V5をインストールします。
Sun Enterprise Authentication Mechanism 1.0.1クライアント・ソフトウェアをインストールすることをお薦めします。

2. Kerberosソフトウェアを構成します。
Sun Enterprise Authentication Mechanismソフトウェアを使用して、/etc/krb5の下のファイルを構成します。この構成は、kdcサーバーを設定し、デフォルト・レルムとKerberosシステムが必要とするその他の構成を定義します。

3. リストされた最初の値がkerberos_v5となるように/etc/gss/mechファイルを変更します。

20.8.2 Kerberos認証用にSASLオプションを指定する方法

Kerberosのインストール時には適切なSASLオプションを指定する必要があります。

1. GSSAPIメカニズムで有効にするクライアント・アプリケーションを使用する前に、ユーザーのプリンシパルでKerberosセキュリティ・システムを初期化します。

$ kinit user-principal

ここで、user-principalは、ご使用のSASLアイデンティティです。たとえば、bjensen@example.comとなります。

2. Kerberosの使用を設定するSASLオプションを指定します。
UNIX環境では、SASL_PATH環境変数をSASLライブラリの正しいパスに設定する必要があります。Kornシェルでの設定例は次のようになります:

$ export SASL_PATH=SASL-library

このパスは、LDAPツールが起動されたホストと同じホストにOracle Unified Directoryソフトウェアがインストールされていることを前提としています。

次に示すldapsearchツールの例は、-o(小文字のo)オプションを使用してKerberosの使用を設定するSASLオプションを指定する方法を示しています:

$ ldapsearch -h www.host1.com -p 1389 -o mech=GSSAPI -o authid="bjensen@EXAMPLE.COM" \
-o authzid="bjensen@EXAMPLE.COM" -b "dc=example,dc=com" "(givenname=Richard)"

authidは、kinitコマンドによって初期化されたKerberosキャッシュに含まれるので、省略できます。authidを指定する場合、プロキシ操作を対象とするauthzidは使用されませんが、authidとauthzidにはどちらにも同じ値を指定する必要があります。authidの値は、アイデンティティ・マッピングで使用されるプリンシパルです。レルムを含み、プリンシパルはすべて完全なプリンシパルである必要があります。

20.8.3 GSSAPIとSASLを使用したKerberos認証の構成例

Oracle Unified Directoryディレクトリ・サーバー用のKerberosの構成は複雑な場合があります。最初にKerberosのマニュアルを参照してください。

さらに詳細について知りたい場合は、次に示す手順例を参考にしてください。ただし、この手順は例であることを忘れないでください。自分の設定と環境に合せて手順を変更してください。

Solaris OSでのKerberosの構成と使用の詳細は、システム管理ガイド: セキュリティ・サービスを参照してください。このマニュアルはSolarisマニュアル・セットの一部です。マニュアル・ページを参照することもできます。

この例についての情報と使用する手順は、次のとおりです:

1. この例の前提

2. すべてのマシン: Kerberosクライアント構成ファイルの編集

3. すべてのマシン: 管理サーバーACL構成ファイルの編集

4. KDCマシン: KDCサーバー構成ファイルの編集

5. KDCマシン: KDCデータベースの作成

6. KDCマシン: 管理プリンシパルとキータブの作成

7. KDCマシン: Kerberosデーモンの開始

8. KDCマシン: KDCマシンとOracle Unified Directoryマシンに対するホスト・プリンシパルの追加

9. KDCマシン: ディレクトリ・サーバーに対するLDAPプリンシパルの追加

10. KDCマシン: KDCへのテスト・ユーザーの追加

11. ディレクトリ・サーバー・マシン: Oracle Unified Directoryのインストール

12. Directory Serverマシン: GSSAPIを有効にするためのDirectory Serverの構成

13. ディレクトリ・サーバー・マシン: ディレクトリ・サーバーLDAPの作成と構成

14. Directory Serverマシン: Directory Serverへのテスト・ユーザーの追加

15. ディレクトリ・サーバー・マシン: テスト・ユーザーとしてのKerberosチケットの取得

16. クライアント・マシン: GSSAPIによるDirectory Serverに対する認証

20.8.3.1 この例での前提

この手順例では、1台目のマシンをKDC (Key Distribution Center)として操作し、2台目のマシンではディレクトリ・サーバーを実行できるように構成する処理について説明します。この手順の結果として、ユーザーはGSSAPIによってKerberos認証を実行できるようになります。

同じマシン上でKDCとディレクトリ・サーバーの両方を実行することもできます。両方を同じマシン上で実行することを選択した場合にも同じ手順を使用できます。この場合、KDCマシンとディレクトリ・サーバー・マシンで重複する手順は、一度行うのみですみます。

この手順では、使用される環境に関する多くの前提条件が発生します。手順例を使用する場合は、環境に合せて値を変更してください。前提条件は次のとおりです:

- このシステムには、推奨される最新のパッチ・クラスタのインストールされた最新のSolaris 10ソフトウェアがインストールされています。適切なSolarisパッチがインストールされていない場合、ディレクトリ・サーバーに対するKerberos認証は失敗する可能性があります。

- Kerberosデーモンを実行するマシンは、kdc.example.comという完全修飾ドメイン名を持ちます。このマシンは、ネーミング・サービスにDNSを使用するように構成する必要があります。この構成は、Kerberosの必要条件です。fileなど、他のネーミング・サービスをかわりに使用すると、特定の操作が失敗することもあります。

- ディレクトリ・サーバーを実行するマシンは、directory.example.comという完全修飾ドメイン名を持ちます。このマシンも、ネーミング・サービスにDNSを使用するように構成する必要があります。

- Directory Serverマシンは、Kerberosによってディレクトリ・サーバーに対する認証を行うためのクライアント・システムとして機能します。この認証は、ディレクトリ・サーバーとKerberosデーモンの両方と通信できる任意のシステムから実行できます。しかし、この例で必要なコンポーネントはすべて、Oracle Unified Directoryディレクトリ・サーバーによって提供され、認証はこのシステムから実行されます。

- ディレクトリ・サーバー内のユーザーは、uid=username,ou=People,dc=example,dc=comの形式のDNを持ちます。対応するKerberosプリンシパルは、username@EXAMPLE.COMです。別のネーミング・スキームを使用する場合は、別のGSSAPIアイデンティティ・マッピングを使用する必要があります。

20.8.3.2 すべてのマシン: Kerberosクライアント構成ファイルの編集

/etc/krb5/krb5.conf構成ファイルは、KDCと通信するためにKerberosクライアントが必要とする情報を提供しています。

Kerberosを使用してディレクトリ・サーバーに対する認証を行うKDCマシン、ディレクトリ・サーバー・マシンおよび任意のクライアント・マシン上の/etc/krb5/krb5.conf構成ファイルを編集します。

- "___default_realm___"をすべて"EXAMPLE.COM"に置き換えます。

- "___master_kdc___"をすべて"kdc.example.com"に置き換えます。

- "___slave_kdcs___"の含まれる行を削除して、Kerberosサーバーが1つしか存在しないようにします。

- "___domain_mapping___"を".example.com = EXAMPLE.COM"に置き換えます(example.comの最初のピリオドに注意)。

更新された/etc/krb5/krb5.conf構成ファイルは次の例のコンテンツと類似しています。

例20-1 編集後のKerberosクライアント構成ファイル/etc/krb5/krb5.conf

#pragma ident   "@(#)krb5.conf  1.2     99/07/20 SMI"
# Copyright (c) 1999, by Sun Microsystems, Inc.
# All rights reserved.
#
# krb5.conf template
# In order to complete this configuration file
# you will need to replace the __<name\>__ placeholders
# with appropriate values for your network.
#

[libdefaults]
default_realm = EXAMPLE.COM
[realms]
EXAMPLE.COM = {
kdc = kdc.example.com
admin_server = kdc.example.com
}
[domain_realm]
.example.com = EXAMPLE.COM
[logging]
default = FILE:/var/krb5/kdc.log
kdc = FILE:/var/krb5/kdc.log
kdc_rotate = {

# How often to rotate kdc.log. Logs will get rotated no more
# often than the period, and less often if the KDC is not used
# frequently.
period = 1d

# how many versions of kdc.log to keep around (kdc.log.0, kdc.log.1, ...)
versions = 10
}

[appdefaults]
kinit = {
renewable = true
forwardable= true
}
gkadmin = {
help_url =
http://docs.sun.com:80/ab2/coll.384.1/SEAM/@AB2PageView/1195
}

20.8.3.3 すべてのマシン: 管理サーバーACL構成ファイルの編集

/etc/krb5/kadm5.acl構成ファイル内の"___default_realm___"を"EXAMPLE.COM"に置き換えます。更新されたファイルは、次の例のようになります。

例20-2 編集後の管理サーバーACL構成ファイル

#
# Copyright (c) 1998-2000 by Sun Microsystems, Inc.
# All rights reserved.
#
# pragma ident   "@(#)kadm5.acl  1.1     01/03/19 SMI"
*/admin@EXAMPLE.COM *

20.8.3.4 KDCマシン: KDCサーバー構成ファイルの編集

/etc/krb5/kdc.confファイルを編集して、"___default_realm___"を"EXAMPLE.COM"に置き換えます。更新されたファイルは、次の例のようになります。

例20-3 編集後のKDCサーバー構成ファイル/etc/krb5/kdc.conf

# Copyright 1998-2002 Sun Microsystems, Inc.  All rights reserved.
# Use is subject to license terms.
#
#ident  "@(#)kdc.conf   1.2     02/02/14 SMI"

[kdcdefaults]
kdc_ports = 88,750

[realms]
EXAMPLE.COM = {
profile = /etc/krb5/krb5.conf
database_name = /var/krb5/principal
admin_keytab = /etc/krb5/kadm5.keytab
acl_file = /etc/krb5/kadm5.acl
kadmind_port = 749
max_life = 8h 0m 0s
max_renewable_life = 7d 0h 0m 0s
default_principal_flags = +preauth
}

20.8.3.5 KDCマシン: KDCデータベースの作成

$ /usr/sbin/kdb5_util create -r EXAMPLE.COM -s
Initializing database '/var/krb5/principal' for realm 'EXAMPLE.COM',
master key name 'K/M@EXAMPLE.COM'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key: password
Re-enter KDC database master key to verify: password
$

20.8.3.6 KDCマシン: 管理プリンシパルとキータブの作成

次のコマンドを使用して、kws/admin@EXAMPLE.COMというプリンシパルの管理ユーザーと、管理デーモンによって使用されるサービス鍵を作成します。

$ /usr/sbin/kadmin.local
kadmin.local:  add_principal kws/admin
Enter password for principal "kws/admin@EXAMPLE.COM": secret
Re-enter password for principal "kws/admin@EXAMPLE.COM": secret
Principal "kws/admin@EXAMPLE.COM" created.
kadmin.local:  ktadd -k /etc/krb5/kadm5.keytab kadmin/kdc.example.com
Entry for principal kadmin/kdc.example.com with kvno 3, encryption type
DES-CBC-CRC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
kadmin.local:  ktadd -k /etc/krb5/kadm5.keytab changepw/kdc.example.com

Entry for principal changepw/kdc.example.com with kvno 3, encryption type
DES-CBC-CRC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
kadmin.local:  ktadd -k /etc/krb5/kadm5.keytab kadmin/changepw
Entry for principal kadmin/changepw with kvno 3, encryption type
DES-CBC-CRC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
kadmin.local:  quit$

20.8.3.7 KDCマシン: Kerberosデーモンの開始

KerberosデーモンはSMF (Service Management Facility)フレームワークによって管理されます。次のコマンドを実行して、KDCおよび管理デーモンを開始します:

$ /etc/init.d/kdc start
$ /etc/init.d/kdc.master start
$

$ svcadm disable network/security/krb5kdc
$ svcadm enable network/security/krb5kdc
$ svcadm disable network/security/kadmin
$ svcadm enable network/security/kadmin
$

KDCプロセスは、/usr/lib/krb5/krb5kdcとプロセス・リストに表示されます。管理デーモンは、/usr/lib/krb5/kadmindと表示されます。

20.8.3.8 KDCマシン: KDCマシンとOracle Unified Directoryマシンに対するホスト・プリンシパルの追加

KDCのKerberosデータベースとディレクトリ・サーバー・マシンにホスト・プリンシパルを追加するには、次の一連のコマンドを使用します。ホスト・プリンシパルは、klistなどの特定のKerberosユーティリティによって使用されます。

$ /usr/sbin/kadmin -p kws/admin
Enter Password: secret
kadmin:  add_principal -randkey host/kdc.example.com
Principal "host/kdc.example.com@EXAMPLE.COM" created.
kadmin:  ktadd host/kdc.example.com
Entry for principal host/kdc.example.com with kvno 3, encryption type
DES-CBC-CRC added to keytab WRFILE:/etc/krb5/krb5.keytab.
kadmin:  add_principal -randkey host/directory.example.com
Principal "host/directory.example.com@EXAMPLE.COM" created.
kadmin:  ktadd host/directory.example.com
Entry for principal host/directory.example.com with kvno 3, encryption type
DES-CBC-CRC added to keytab WRFILE:/etc/krb5/krb5.keytab.
kadmin:  quit
$

20.8.3.9 KDCマシン: ディレクトリ・サーバーに対するLDAPプリンシパルの追加

ディレクトリ・サーバーで認証中のユーザーが保持するKerberosチケットを検証できるようにするには、ディレクトリ・サーバーディレクトリ・サーバーが独自のプリンシパルを保持する必要があります。現在Oracle Unified Directoryは、ldap/fqdn@realmのプリンシパルを要求するためにハードコーディングされています。ここで、fqdnはディレクトリ・サーバーの完全修飾ドメイン名で、realmはKerberosレルムです。fqdnは、Oracle Unified Directoryのインストール時に指定された完全修飾名と一致する必要があります。この場合、ディレクトリ・サーバーのプリンシパルは、ldap/directory.example.com@EXAMPLE.COMとなります。

次のコマンド・シーケンスを使用して、ディレクトリ・サーバーのLDAPプリンシパルを作成します:

$ /usr/sbin/kadmin -p kws/admin
Enter Password: secret
kadmin: add_principal -randkey ldap/directory.example.com
Principal "ldap/directory.example.com@EXAMPLE.COM" created.
kadmin: quit
$

20.8.3.10 KDCマシン: KDCへのテスト・ユーザーの追加

Kerberos認証を実行するには、Kerberosデータベース内にユーザー認証が存在している必要があります。この例では、ユーザーのユーザー名をkerberos-testにします。つまりKerberosプリンシパルがkerberos-test@EXAMPLE.COMになります。

この例の一連のコマンドを使用してユーザーを作成します:

$ /usr/sbin/kadmin -p kws/admin
Enter Password: secret
kadmin:  add_principal kerberos-test
Enter password for principal "kerberos-test@EXAMPLE.COM": secret

Re-enter password for principal "kerberos-test@EXAMPLE.COM": secret

Principal "kerberos-test@EXAMPLE.COM" created.
kadmin:  quit
$

20.8.3.11 ディレクトリ・サーバー・マシン: Oracle Unified Directoryのインストール

Oracle Unified Directoryをインストールします。次の表に、この項の例で使用するインストール設定を示します。

変数タイプ

サンプル値

ディレクトリ・サーバーの完全修飾DNS名

directory.example.com

サーバー・ポート

389

接尾辞

dc=example,dc=com

インストール・ディレクトリ

/asinst_1/oud

Oracle Unified Directoryサーバー・ユーザー

oud

Oracle Unified Directoryサーバー・グループ

oud

Kerberosテスト・プリンシパル

kerberos-test

Oracle Unified Directoryキータブ・パス

/asinst_1/oud/config/oud.keytab

注意:

ディレクトリ・サーバーの完全修飾DNS名は、すべてのサーバー(Oracle Unified Directoryサーバー、Kerberos Key Distribution Center (KDC)、およびGSSAPI SASLを使用してサーバーにバインドする予定のクライアント・マシン)上で同一IPアドレスに変換される必要があります。

20.8.3.12 ディレクトリ・サーバー・マシン: ディレクトリ・サーバーLDAPの作成と構成

これまでに説明したように、GSSAPIによってKerberosユーザーを認証するには、Oracle Unified DirectoryはKDC内に独自のプリンシパルを持つ必要があります。プリンシパル情報は、ディレクトリ・サーバー・マシン上のKerberosキータブ内に格納されている必要があります。この情報は、ディレクトリ・サーバーが動作するユーザー・アカウントが参照できるファイル内にある必要があります。

注意:

この手順は、GSSAPI SASL mechanism handlerを構成する前に実行する必要があります。ハンドラは初期化する前にキータブ・ファイルが存在することを確認します。

正しいプロパティを持つキータブ・ファイルを作成するには、次の一連のコマンドを使用します:

$ kadmin -p kws/admin@EXAMPLE.COM
kadmin:  addprinc -randkey ldap/directory.example.com
WARNING: no policy specified for ldap/directory.example.com@EXAMPLE.COM;
defaulting to no policy
Principal "ldap/directory.example.com@EXAMPLE.COM" created.
kadmin:  ktadd -k asinst_1/oud/config/oud.keytab ldap/directory.example.com
Entry for principal ldap/directory.example.com with kvno 3,
encryption type AES-128 CTS mode
with 96-bit SHA-1 HMAC added to keytab WRFILE:asinst_1/oud/config/oud.keytab.
Entry for principal ldap/directory.example.com with kvno 3,
encryption type Triple DES cbc mode
with HMAC/sha1 added to keytab WRFILE:asinst_1/oud/config/oud.keytab.
Entry for principal ldap/directory.example.com with kvno 3,
encryption type ArcFour with HMAC/md5
added to keytab WRFILE:asinst_1/oud/config/oud.keytab.
Entry for principal ldap/directory.example.com with kvno 3,
encryption type DES cbc mode with RSA-MD5
added to keytab WRFILE:asinst_1/oud/config/oud.keytab.
kadmin:  quit

このカスタムのキータブのアクセス権と所有権を変更します。キータブを、ディレクトリ・サーバーを実行するために使用されるユーザー・アカウントの所有にし、そのユーザーしか参照できないようにします:

$ chown oud:oud asinst_1/oud/config/oud.keytab
$ chmod 600 asinst_1/oud/config/oud.keytab

これらの変更を有効にするには、ディレクトリ・サーバーを停止し、再起動する必要があります。

20.8.3.13 ディレクトリ・サーバー・マシン: GSSAPIを有効にするためのディレクトリ・サーバーの構成

この手順では、directory.example.comディレクトリ・サーバー・ホスト上のGSSAPI SASL mechanism handlerを管理する例を示します。

次の例に従ってdsconfigコマンドを使用してディレクトリ・サーバー・ホストdirectory.example.com上のGSSAPI SASLメカニズム・ハンドラを有効にし、asinst_1/oud/config/oud.keytabを使用するようにそのハンドラを構成します。

$ dsconfig -X -n -p 4444 -h directory.example.com \
-D "cn=directory manager" -j pwd-file
set-sasl-mechanism-handler-prop \
--handler-name GSSAPI \
--set enabled:true \
--set keytab:asinst_1/oud/config/oud.keytab \
--set server-fqdn:directory.example.com

このコマンドの最後の行はGSSAPI SASLメカニズムのプロパティserver-fqdnをdirectory.example.comに設定します。これはオプションのパラメータです。ディレクトリ・サーバー・ホスト上でのホスト名の検索によりLDAPプリンシパルの作成に使用された正確なホスト名が間違えなく返される場合は、省略しても構いません。このプロパティを設定すると、2つの名前を確実に一致させられます(この例では、directory.example.com)。

ディレクトリ・サーバー・ホストdirectory.example.com上のGSSAPI SASLメカニズム・ハンドラのプロパティを調べて構成が正しいことを確認します。

$ dsconfig -X -n -p 4444 -h directory.example.com \
-D "cn=directory manager" -j pwd-file \
get-sasl-mechanism-handler-prop \
--handler-name GSSAPI
Property              : Value(s)
----------------------:----------------------
enabled               : true
identity-mapper       : Regular Expression
kdc-address           : -
keytab                : asinst_1/oud/config/oud.keytab
principal-name        : -
quality-of-protection : none
realm                 : -
server-fqdn           : directory.example.com

トラブルシューティングの必要がある場合は、dsconfigを使用してディレクトリ・サーバー・ホストdirectory.example.com上のすべてのSASLメカニズム・ハンドラのステータスをリストすることができます。

$ dsconfig -X -n -p 4444 -h directory.example.com \
-D "cn=directory manager" -j pwd-file \
list-sasl-mechanism-handlers
SASL Mechanism Handler : Type       : enabled
-----------------------:------------:--------
ANONYMOUS              : anonymous  : false
CRAM-MD5               : cram-md5   : true
DIGEST-MD5             : digest-md5 : true
EXTERNAL               : external   : true
GSSAPI                 : gssapi     : true
PLAIN                  : plain      : true

必要があれば、dsconfigを使用してディレクトリ・サーバー・ホストdirectory.example.com上のGSSAPI SASLメカニズム・ハンドラを無効にできます。

$ dsconfig -X -n -p 4444 -h directory.example.com \
-D "cn=directory manager" -j pwd-file \
set-sasl-mechanism-handler-prop \
--handler-name GSSAPI \
--set enabled:false

20.8.3.14 ディレクトリ・サーバー・マシン: ディレクトリ・サーバーへのテスト・ユーザーの追加

Kerberosユーザーをディレクトリ・サーバーに対して認証するには、そのユーザーのKerberosプリンシパルに対応する、ユーザーのディレクトリ・エントリが必要です。

これまでの手順で、kerberos-test@EXAMPLE.COMというプリンシパルを持つテスト・ユーザーがKerberosデータベースに追加されました。ディレクトリに追加されたアイデンティティ・マッピング構成のために、そのユーザーに対応するディレクトリ・エントリには、uid=kerberos-test,ou=People,dc=example,dc=comというDNが必要です。

ユーザーをディレクトリに追加する前に、次の内容でファイルtestuser.ldifを作成する必要があります。

例20-4 新しいtestuser.ldifファイル

dn: uid=kerberos-test,ou=People,dc=example,dc=com
changetype: add
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: kerberos-test
givenName: Kerberos
sn: Test
cn: Kerberos Test
description: An account for testing Kerberos authentication through GSSAPI

次に、ldapmodifyを使用して、このエントリをサーバーに追加します:

$ ldapmodify -D "cn=Directory Manager" -w - -f testuser.ldif
adding new entry uid=kerberos-test,ou=People,dc=example,dc=com
$

20.8.3.15 ディレクトリ・サーバー・マシン: テスト・ユーザーとしてのKerberosチケットの取得

テスト・ユーザーは、Kerberosデータベース、ディレクトリ・サーバーおよびKDC内に存在します。このため、ディレクトリ・サーバーのテストユーザーとしてGSSAPIを経由したKerberosによって認証できます。

まず、kinitコマンドを使用してユーザーのKerberosチケットを取得します。次の例を参照してください:

$ kinit kerberos-test
Password for kerberos-test@EXAMPLE.COM: secret
$

次に、klistコマンドを使用して、このチケットに関する情報を表示します:

$ klist
Kerberos 5 ticket cache: 'API:6'
Default principal: kerberos-test@EXAMPLE.COM
Valid Starting     Expires            Service Principal
03/23/09 12:35:05  03/23/09 20:35:05  krbtgt/EXAMPLE.COM@EXAMPLE.COM
renew until 03/30/09 12:34:15
$

20.8.3.16 クライアント・マシン: GSSAPIによるディレクトリ・サーバーに対する認証

最後の手順はGSSAPIを使用したディレクトリ・サーバーに対する認証です。ディレクトリ・サーバーの提供するldapsearchユーティリティは、GSSAPI、DIGEST-MD5およびEXTERNALメカニズムを含むSASL認証をサポートしています。しかし、GSSAPIを使用してバインドするために、SASLライブラリへのパスをクライアントに設定する必要があります。SASL_PATH環境変数をlib/saslディレクトリに設定してパスを提供します:

$ SASL_PATH=SASL-library
$ export SASL_PATH
$

ldapsearchを使用してディレクトリ・サーバーに対して実際にKerberosベースの認証を実行するには、-o mech=GSSAPI引数と-o authzid=principal引数を含める必要があります。

また、ここで-h directory.example.comと表示している完全修飾ホスト名も指定する必要があります。これは、サーバーに対するcn=config上のnsslapd-localhost属性の値と一致する必要があります。GSSAPI認証プロセスでは、クライアントから提供されたホスト名がサーバーから提供されたホスト名と一致する必要があるため、ここでは-hオプションを使用する必要があります。

次の例では、これまでに作成したKerberosテスト・ユーザー・アカウントとして認証を行って、dc=example,dc=comエントリを取得しています:

$ ldapsearch -h directory.example.com -p 389 -o mech=GSSAPI \ -o authzid="kerberos-test@EXAMPLE.COM" -b "dc=example,dc=com" -s base "(objectClass=*)"
version: 1
dn: dc=example,dc=com
dc: example
objectClass: top
objectClass: domain
$

正常に認証されたかどうかディレクトリ・サーバーのアクセス・ログを確認します:

$ tail -12 /local/ds/logs/access

[24/Jul/2004:00:30:47 -0500] conn=0 op=-1 msgId=-1 - fd=23 slot=23 LDAP
connection from 1.1.1.8 to 1.1.1.8
[24/Jul/2004:00:30:47 -0500] conn=0 op=0 msgId=1 - BIND dn="" method=sasl
version=3 mech=GSSAPI
[24/Jul/2004:00:30:47 -0500] conn=0 op=0 msgId=1 - RESULT err=14 tag=97
nentries=0 etime=0, SASL bind in progress
[24/Jul/2004:00:30:47 -0500] conn=0 op=1 msgId=2 - BIND dn="" method=sasl
version=3 mech=GSSAPI
[24/Jul/2004:00:30:47 -0500] conn=0 op=1 msgId=2 - RESULT err=14 tag=97
nentries=0 etime=0, SASL bind in progress
[24/Jul/2004:00:30:47 -0500] conn=0 op=2 msgId=3 - BIND dn="" method=sasl
version=3 mech=GSSAPI
[24/Jul/2004:00:30:47 -0500] conn=0 op=2 msgId=3 - RESULT err=0 tag=97
nentries=0 etime=0 dn="uid=kerberos-test,ou=people,dc=example,dc=com"
[24/Jul/2004:00:30:47 -0500] conn=0 op=3 msgId=4 - SRCH base="dc=example,dc=com"
scope=0 filter="(objectClass=*)" attrs=ALL
[24/Jul/2004:00:30:47 -0500] conn=0 op=3 msgId=4 - RESULT err=0 tag=101 nentries=1
etime=0
[24/Jul/2004:00:30:47 -0500] conn=0 op=4 msgId=5 - UNBIND
[24/Jul/2004:00:30:47 -0500] conn=0 op=4 msgId=-1 - closing - U1
[24/Jul/2004:00:30:48 -0500] conn=0 op=-1 msgId=-1 - closed.
$

この例は、バインドが3つの手順によるプロセスであることを示しています。最初の2つの手順でLDAP結果14 (SASLバインド実行中)を返し、3番目の手順はバインドが成功したことを示します。method=saslタグとmech=GSSAPIタグは、このバインドにGSSAPI SASLメカニズムが使用されたことを示しています。成功したバインド・レスポンスの最後のdn="uid=kerberos-test,ou=people,dc=example,dc=com"は、このバインドが適切なユーザーとして実行されたことを示しています。

20.8.4 dsconfigを使用したKerberosワークフロー要素の作成

dsconfig create-workflow-elementコマンドの実行によりKerberosワークフロー要素を作成できます:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
create-workflow-element \
--type KerberosAuthProviderWorkflowElement  \
--element-name Kerberos_Test_WE  \

20.8.5 Kerberos構成のトラブルシューティング

Kerberosのインストールを期待どおりに実行できない場合は、次の条件を確認してください:

- ディレクトリ・サーバー・マシンからのテスト・プリンシパルを使用してkinitを実行し、ディレクトリ・サーバーがKerberos KDCで認証されることを確認します。

- クライアント・マシンからのテスト・プリンシパルを使用してkinitを実行し、クライアント・マシンがKerberos KDCで認証されることを確認します。

- ディレクトリ・サーバーのキータブ・ファイルが存在し、ディレクトリ・サーバーによって読み取り可能なことを確認します。つまり、キータブ・ファイルの所有権と権限設定が正しいことを確認します。

- キータブ・ファイル内のLDAPプリンシパル名が、構成時にディレクトリ・サーバーによって使用されたホスト名と一致することを確認します。次の例は失敗する構成を示します:

1. 次のようにGSSAPIを構成します。server-fqdn属性に指定された値bad.example.comが、キータブdirectory.example.comの作成時に使用された値と一致しません。

$ dsconfig -X -n -p 4444 -h directory.example.com \
-D "cn=directory manager" -j pwd-file \
set-sasl-mechanism-handler-prop \
--handler-name GSSAPI \
--set enabled:true \
--set keytab:asinst_1/oud/config/oud.keytab \
--set server-fqdn:bad.example.com

2. クライアントからGSSAPIを使用してldapsearch認証を試みます。

$ ldapsearch -h directory.example.com \
-o mech=GSSAPI -o authid=kerberos-test@EXAMPLE.COM \
--searchScope base \
-b "uid=kerberos-test,ou=people,dc=example,dc=com" "(objectclass=*)"
An error occurred while attempting to perform GSSAPI authentication to
the Directory Server: \
PrivilegedActionException(AccessController.java:-2)
Result Code:  82 (Local Error)

予想どおり、検索は失敗します。

3. 検索が失敗した原因を確認するには、ディレクトリ・サーバーのアクセス・ログを調べます:

$ tail asinst_1/oud/logs/access
[23/Mar/2009:13:12:59 -0500] CONNECT conn=14 from=129.150.33.77:65076
to=192.168.0.199:1389 protocol=LDAP
[23/Mar/2009:13:13:00 -0500] BIND REQ conn=14 op=0 msgID=1
type=SASL mechanism=GSSAPI dn=""
[23/Mar/2009:13:13:00 -0500] BIND RES conn=14 op=0 msgID=1
result=49 authFailureID=1310915   authFailureReason="An unexpected error
occurred while trying to create an GSSAPI context:
major code (13) No valid credentials provided,
minor code (-1)   Failed to find any Kerberos Key" etime=253
[23/Mar/2009:13:13:00 -0500] DISCONNECT conn=14 reason="Client Disconnect"

アクセス・ログの最後のレコードのマイナー・コードにあるメッセージに、ディレクトリ・サーバーがキータブ・ファイル内に一致するエントリを見つけられなかったことが示されています。

4. 問題を解決するには、ハンドラを無効にしてから、次の例が示すように正しい情報を使用して再度有効にします。

$ dsconfig -X -n -p 4444 -h directory.example.com \
-D "cn=directory manager" -j pwd-file \
set-sasl-mechanism-handler-prop \
--handler-name GSSAPI \
--set enabled:false
$ dsconfig -X -n -p 4444 -h directory.example.com
-D "cn=directory manager" -j pwd-file \
set-sasl-mechanism-handler-prop \
--handler-name GSSAPI \
--set enabled:true \
--set keytab:asinst_1/oud/config/oud.keytab \
--set server-fqdn:directory.example.com
$ ldapsearch -h directory.example.com \
-o mech=GSSAPI \
-o authid=kerberos-test@EXAMPLE.COM \
--searchScope base \
-b "uid=kerberos-test,ou=people,dc=example,dc=com" "(objectclass=*)"
dn: uid=kerberos-test,ou=People,dc=example,dc=com
changetype: add
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: kerberos-test
givenName: Kerberos
sn: Test
cn: Kerberos Test
description: An account for testing Kerberos authentication through GSSAPI

20.9 ldapsearchによるSSL、StartTLS、およびSASL認証のテスト

ディレクトリ・サーバーに用意されているldapsearchユーティリティは、サーバーがSSLおよびStartTLSをサポートするために正しく構成されていることをテストするときに便利です。このユーティリティには、多数の異なる状況下でのテストに適した多数のオプションが含まれています。この項では、ldapsearchを使用してSSLおよびStartTLS通信、SASL EXTERNAL認証をテストする方法を説明します。ldapmodify、ldapcompareおよびldapdeleteなど、ディレクトリ・サーバーで提供されているその他の多数のクライアント・ツールで同一プロセスを使用できます。

20.9.1 セキュリティに適用できるldapsearchコマンド・ライン引数

次のコマンド・ライン引数は、特にldapsearchツールを使用してSSLまたはStartTLSを介して通信するときに重要です:

- -h addressまたは--hostname addressは、接続先のディレクトリ・サーバーのアドレスを指定します。値を省略すると、IPv4ループバック・アドレス(127.0.0.1)が使用されます。

- -p portまたは--port portは、ディレクトリ・サーバーが接続のためにリッスンするポート番号を指定します。値を省略すると、標準の暗号化されていないLDAPポート(389)が使用されます。

- -Zまたは--useSSLは、ディレクトリ・サーバーとの安全な通信のためにクライアントはSSLを使用する必要があることを示します。このオプションを使用する場合は、ポート引数に指定した値がSSLベースの接続をサーバーがリッスンするポートである必要があります。デフォルトのLDAPSポートは、636です。

- -qまたは--startTLSは、ディレクトリ・サーバーとの通信を保護するためにクライアントはStartTLS拡張操作を使用する必要があることを示します。このオプションを使用する場合は、ポート引数に指定した値がクリアテキストLDAP接続をサーバーがリッスンするポートである必要があります。サーバーがデフォルトのLDAPポート(389)をリッスンする場合、ポート引数は必要ありません。

- -rまたは--useSASLExternalは、ディレクトリ・サーバーとの安全な通信のためにクライアントはSASL EXTERNAL認証を使用する必要があることを示します。このオプションを使用する場合は、キーストア・パスも指定する必要があります。

- -Xまたは--trustAllは、クライアントがディレクトリ・サーバーによって提出されるすべての証明書を盲目的に信頼する必要があることを示します。このオプションは、トラスト・ストア・パスの指定に使用される引数と一緒には使用できません。

- -K pathまたは--keyStorePath pathは、クライアントがディレクトリ・サーバーに証明書を提出する場合に使用する必要があるキーストアへのパスを指定します(たとえば、SASL EXTERNAL認証を使用するときなど)。これはJKSキーストアへのパスです。

- -W passwordまたは--keyStorePassword passwordは、キーストアのコンテンツへのアクセスに必要なPINを指定します。これはキーストア・パスワード・ファイル引数と一緒には使用できません。

- --keyStorePasswordFile pathは、キーストアのコンテンツへのアクセスに必要なPINを含むファイルへのパスを指定します。これはキーストア・パスワード引数と一緒には使用できません。

- -N nicknameまたは--certNickname nicknameは、クライアントがディレクトリ・サーバーに提出する必要がある証明書のニックネームまたは別名を指定します。キーストア・パス引数も指定する必要があります。ニックネームを省略すると、クライアントはキーストア内で見つけた最初の受け入れ可能なクライアント証明書を使用します。

- -P pathまたは--trustStorePath pathは、クライアントがディレクトリ・サーバーによって提出された証明書を信頼するかどうか判断するときに使用するJKSトラスト・ストア・ファイルへのパスを指定します。この引数とtrustAllオプションが省略されると、クライアントに提出されるすべての証明書が表示され、それを信頼するかどうかユーザーが尋ねられます。

- --trustStorePassword passwordは、トラスト・ストアのコンテンツにアクセスするためのパスワードを指定します。通常、トラスト・ストア・パスワードは必要ありません。これはトラスト・ストア・パスワード・ファイルのオプションと一緒には使用できません。

- --trustStorePasswordFile pathは、トラスト・ストア・コンテンツへのアクセスに必要なパスワードを含むファイルへのパスを指定します。通常、トラスト・ストア・パスワードは必要ありません。これはトラスト・ストア・パスワードのオプションと一緒には使用できません・

- -Eまたは--reportAuthzIDは、ディレクトリ・サーバーがバインド・レスポンスの中の認証済ユーザーの認可IDを含む必要があることを示します。これはSASL認証を実行して、クライアント証明書(またはEXTERNAL以外のメカニズムが使用された場合は、その他の形式のSASL資格証明)がマッピングされるユーザーを判断するのに役立ちます。

20.9.2 SSLのテスト

ldapsearchを使用してLDAP over SSLを通してディレクトリ・サーバーと通信する例を以下に示します:

$ ldapsearch --hostname directory.example.com --port 1636 \
--useSSL --baseDN "" --searchScope base "(objectClass=*)"

この場合、トラスト・ストアは指定されず、--trustAll引数も指定されません。このため、サーバーが証明書をクライアントに提出すると、その証明書を信頼すべきかどうかユーザーが尋ねられます。全シーケンスの例を以下に示します:

$ ldapsearch --hostname directory.example.com --port 1636 \
--useSSL --baseDN "" --searchScope base "(objectClass=*)"

The server is using the following certificate:
Subject DN: CN=directory.example.com, O=Example Corp, C=US
Issuer DN: CN=directory.example.com, O=Example Corp, C=US
Validity: Fri Mar 02 16:48:17 CST 2007 through Thu might 31 17:48:17 CDT 2007
Do you want to trust this certificate and continue connecting to the server?
Please enter "yes" or "no":
dn:
objectClass: ds-rootDSE
objectClass: top

ユーザーに確認せずに、サーバーによって提出されたすべての証明書をクライアントに信頼させるには、--trustAll引数を指定します。例:

$ ldapsearch --hostname directory.example.com --port 1636 \
--useSSL --trustAll --baseDN "" --searchScope base \
"(objectClass=*)"

クライアントがトラスト・ストアを所有し、それを使用してサーバー証明書を信頼するかどうか判断する場合は、--trustStorePath引数も指定する必要があります。例:

$ ldapsearch --hostname directory.example.com --port 1636 \
--useSSL --trustStorePath client.truststore --baseDN "" \
--searchScope base "(objectClass=*)"

20.9.3 StartTLSのテスト

ldapsearchユーティリティでStartTLSを使用するプロセスは、SSLを使用するプロセスとほとんど同じです。サーバーが暗号化されていないLDAPリクエストをリッスンするポートを使用し、SSLのかわりにStartTLSを使用する(つまり、--useSSLのかわりに--useStartTLSを使用する)ことを示す必要がある点のみ異なります。次の例は通信を保護するためにStartTLSを使用することを除き、SSLとldapsearchを使用する最初の例と同じです:

$ ldapsearch -h directory.example.com --port 1389 \
--useStartTLS --baseDN "" --searchScope base "(objectClass=*)"

これはその他のすべての例に適用されます。単にLDAPSポートからLDAPポートにポート番号を変更し、--useSSLオプションを--useStartTLSで置き換えます。

20.9.4 SASL EXTERNAL認証のテスト

注意:

SASLは、プロキシ・サーバー・インスタンスでの使用がサポートされていません。

SASL EXTERNAL認証は、SSLまたはStartTLSのいずれかと一緒に使用できます。主な相違点は、クライアント証明書を含むキーストア、そのキーストアのコンテンツにアクセスする必要があるPIN、およびクライアントがSASL EXTERNAL認証を使用する必要があることを示すフラグを指定する必要があることです。次の例では、このようなコマンドの使用例を示します:

$ ldapsearch --hostname directory.example.com --port 1636 \
--useSSL --keyStorePath /path/to/client.keystore \
--keyStorePasswordFile /path/to/client.keystore.pin \
--useSASLExternal --certNickName nickname \
--baseDN "" --searchScope base \
"(objectClass=*)"

SASL EXTERNAL認証を使用するときに、認証が正しいユーザーとして実行されていることを保証するためにサーバーに認可IDを返してもらうときにも便利です。以下に、このプロセスの例を示します。("#"で始まる行に報告された値に注意します。)

$ ldapsearch --hostname directory.example.com --port 1636 \
--useSSL --keyStorePath /path/to/client.keystore \
--keyStorePasswordFile /path/to/client.keystore.pin \
--useSASLExternal --reportAuthzID --certNickName nickname \
--baseDN "" --searchScope base "(objectClass=*)"

# Bound with authorization ID dn:uid=test.user,dc=example,dc=com
dn:
objectClass: ds-rootDSE
objectClass: top

20.10 s_clientテスト・ユーティリティを使用したSSLのデバッグ

OpenSSLは、SSLサーバーをデバッグするための有益で便利な診断ツールs_clientを提供します。このコマンドは、SSL/TLSを使用してリモート・ホストに接続する汎用SSL/TLSクライアントを実装します。

この強力なコマンド・ライン・ユーティリティにより、SSL/TLSを使用するサーバーをテストまたはデバッグできます。Oracle Unified Directoryサーバーへのセキュアな接続をテストするには、コマンド・プロンプトに次のコマンドを入力します:

openssl s_client -connect <host>:<port> [options]

説明:

s_client:は、セキュア・サーバーをテストするためのSSL/TLSテスト・クライアントです。テスト・クライアントは、セキュア・ポートに接続し、SSL/TLSハンドシェーク中に実行されたステップの詳細なログを提供します。

hostname:port:は、接続先のホストとオプションのポートを指定します。省略すると、ポート443上のローカル・ホストへの接続が試みられます。これは、httpsによりポート443が使用されるからです。

接続された場合、セキュア・サーバーに対して"GET /"や"HEAD / HTTP/1.0"など、いくつかのコマンドを手動で入力できます。ただし、ハンドシェークが失敗する場合には、いくつかの原因が考えられます。直面している問題がアプリケーション、ファイアウォール、証明書トラストなどに関連しているかどうか確認したい場合、この項では考えられる原因のリストからSSLを除外する方法を説明します。

この項には次のトピックが含まれます:

- 第20.10.1項「シナリオ1- 接続が拒否された」

- 第20.10.2項「シナリオ2- リターン・コード: 18 (自己署名証明書)を確認する」

- 第20.10.3項「シナリオ3 - リターン・コード: 0 (ok)を確認する」

- 第20.10.4項「シナリオ4 - SSLHandshakeException」

- 第20.10.5項「シナリオ5 - SASL EXTERNALバインド・リクエストを処理できない」

20.10.1 シナリオ1- 接続が拒否された

割り当てられたSSLポートでSSLクライアントに接続しようとしても接続できません。次に、このシナリオの例を示します:

openssl s_client -connect localhost:<ldaps_portnumber>
connect: Connection refused
connect:errno=146

解決策

解決策として、config.ldifファイルのLDAPS番号が正しい値かどうか確認してください。

20.10.2 シナリオ2- リターン・コード: 18 (自己署名証明書)を確認する

エラー・コード18は、証明書チェーンの検証が失敗したためSSLクライアント・プログラムがサーバーとのセキュアな接続(https)を確立できなかったことを意味します。ユーザーが使用しているサーバーは自己署名証明書を使用しており、証明書チェーンを使用する必要があります。

次に、このシナリオの例を示します:

openssl s_client -connect localhost:<ldaps-port-number>
CONNECTED(00000004)
depth=0 /C=ca/ST=California/L=SF/O=Oracle/OU=ldap/CN=server admin
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=ca/ST=California/L=SF/O=Oracle/OU=ldap/CN=server admin
verify return:1
---
Certificate chain
0 s:/C=ca/ST=California/L=SF/O=Oracle/OU=ldap/CN=server admin
i:/C=ca/ST=California/L=SF/O=Oracle/OU=ldap/CN=server admin
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDBjCCAsSgAwIBAgIETxRMvTALBgcqhkjOOAQDBQAwZjELMAkGA1UEBhMCY2Ex
EzARBgNVBAgTCkNhbGlmb3JuaWExCzAJBgNVBAcTAlNGMQ8wDQYDVQQKEwZPcmFj
bGUxDTALBgNVBAsTBGxkYXAxFTATBgNVBAMTDHNlcnZlciBhZG1pbjAeFw0xMjAx
MTYxNjEzNDlaFw0xMjA0MTUxNjEzNDlaMGYxCzAJBgNVBAYTAmNhMRMwEQYDVQQI
EwpDYWxpZm9ybmlhMQswCQYDVQQHEwJTRjEPMA0GA1UEChMGT3JhY2xlMQ0wCwYD
VQQLEwRsZGFwMRUwEwYDVQQDEwxzZXJ2ZXIgYWRtaW4wggG4MIIBLAYHKoZIzjgE
ATCCAR8CgYEA/X9TgR11EilS30qcLuzk5/YRt1I870QAwx4/gLZRJmlFXUAiUftZ
PY1Y+r/F9bow9subVWzXgTuAHTRv8mZgt2uZUKWkn5/oBHsQIsJPu6nX/rfGG/g7
V+fGqKYVDwT7g/bTxR7DAjVUE1oWkTL2dfOuK2HXKu/yIgMZndFIAccCFQCXYFCP
FSMLzLKSuYKi64QL8Fgc9QKBgQD34aCF1ps93su8q1w2uFe5eZSvu/o66oL5V0wL
PQeCZ1FZV4661FlP5nEHEIGAtEkWcSPoTCgWE7fPCTKMyKbhPBZ6i1R8jSjgo64e
K7OmdZFuo38L+iE1YvH7YnoBJDvMpPG+qFGQiaiD3+Fa5Z8GkotmXoB7VSVkAUw7
/s9JKgOBhQACgYEAw+2EIpmwy0rqtHbNb6gxbEtW0hplXXQdHEQp24brde1jt1qv
LDz/c8KR+fVxqvTxAmurGt1qbrhjXcUxi1KdaLnLnLXTCoD+ZLQU+F6B/TNmfrxb
AJmHtmoZsFtNCBTC++FClXtconKyXjEWnKMw7fEb+gNY3eTUrcyIpa/YEbYwCwYH
KoZIzjgEAwUAAy8AMCwCFEtf5+J77Q/5fI6bZ7k3D1rdbw6UAhQkWGmp8VOiMdUg
5K4wK7Y7cC0wSQ==
-----END CERTIFICATE-----
subject=/C=ca/ST=California/L=SF/O=Oracle/OU=ldap/CN=server admin
issuer=/C=ca/ST=California/L=SF/O=Oracle/OU=ldap/CN=server admin
---
Acceptable client certificate CA names
/C=FR/ST=France/L=Grenoble/O=Oracle/OU=OUD/CN=CA Certificate
/C=ca/ST=California/L=SF/O=Oracle/OU=ldap/CN=user.41
/C=ca/ST=California/L=SF/O=Oracle/OU=ldap/CN=server admin
---
SSL handshake has read 1594 bytes and written 312 bytes
---
New, TLSv1/SSLv3, Cipher is EDH-DSS-DES-CBC3-SHA
Server public key is 1024 bit
SSL-Session:
Protocol  : TLSv1
Cipher    : EDH-DSS-DES-CBC3-SHA
Session-ID: 4F16C3F27655013F71AE2120134A8D1AFE966A1D9233618507DEFE9C607417AA
Session-ID-ctx:
Master-Key: 57BDB7FCA9A293E65274AA7CDD0E7CC48AA227806FC2B54C9F9E36BB26D32943FC115CE4FF9A605B6B6BD237026F3D0E
Key-Arg   : None
Start Time: 1326892018
Timeout   : 300 (sec)
Verify return code: 18 (self signed certificate)

解決策

署名済証明応答とCA証明書をサーバーのキーストアにインポートする必要があります。

20.10.3 シナリオ3 リターン・コード: 0 (ok)を確認する

SSLサーバーとの接続が確立されると、リターン・コード0.を受け取ります。これは、サーバーから受信したデータがすべて表示され、押されたキーがすべてサーバーに送信されることを意味します。また、使用される証明書チェーンも表示されます。

次に、稼働中のセッションの例を示します:

openssl s_client -connect localhost:8636 -verify 250 \
-key $SERVER_SSL/config/keystore   -CApath $CA_SSL -CAfile ca-cert.pem

-key is specifying the path to teh server keystore
-CAPath/-CAfile allows to locate CA certificate (pem format)

verify depth is 250
CONNECTED(00000004)
depth=1 /C=FR/ST=France/L=Grenoble/O=Oracle/OU=OUD/CN=CA Certificate
verify return:1
depth=0 /C=ca/ST=California/L=SF/O=Oracle/OU=ldap/CN=server admin
verify return:1
---
Certificate chain
0 s:/C=ca/ST=California/L=SF/O=Oracle/OU=ldap/CN=server admin
i:/C=FR/ST=France/L=Grenoble/O=Oracle/OU=OUD/CN=CA Certificate
1 s:/C=FR/ST=France/L=Grenoble/O=Oracle/OU=OUD/CN=CA Certificate
i:/C=FR/ST=France/L=Grenoble/O=Oracle/OU=OUD/CN=CA Certificate
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDYDCCAsmgAwIBAgIFAJbW4rkwDQYJKoZIhvcNAQEFBQAwaTELMAkGA1UEBhMC
RlIxDzANBgNVBAgTBkZyYW5jZTERMA8GA1UEBxMIR3Jlbm9ibGUxDzANBgNVBAoT
Bk9yYWNsZTEMMAoGA1UECxMDT1VEMRcwFQYDVQQDEw5DQSBDZXJ0aWZpY2F0ZTAe
Fw0xMjAxMTcxMDQ5MjdaFw0xMjA0MTcxMDQ5MjdaMGYxCzAJBgNVBAYTAmNhMRMw
EQYDVQQIEwpDYWxpZm9ybmlhMQswCQYDVQQHEwJTRjEPMA0GA1UEChMGT3JhY2xl
MQ0wCwYDVQQLEwRsZGFwMRUwEwYDVQQDEwxzZXJ2ZXIgYWRtaW4wggG3MIIBLAYH
KoZIzjgEATCCAR8CgYEA/X9TgR11EilS30qcLuzk5/YRt1I870QAwx4/gLZRJmlF
XUAiUftZPY1Y+r/F9bow9subVWzXgTuAHTRv8mZgt2uZUKWkn5/oBHsQIsJPu6nX
/rfGG/g7V+fGqKYVDwT7g/bTxR7DAjVUE1oWkTL2dfOuK2HXKu/yIgMZndFIAccC
FQCXYFCPFSMLzLKSuYKi64QL8Fgc9QKBgQD34aCF1ps93su8q1w2uFe5eZSvu/o6
6oL5V0wLPQeCZ1FZV4661FlP5nEHEIGAtEkWcSPoTCgWE7fPCTKMyKbhPBZ6i1R8
jSjgo64eK7OmdZFuo38L+iE1YvH7YnoBJDvMpPG+qFGQiaiD3+Fa5Z8GkotmXoB7
VSVkAUw7/s9JKgOBhAACgYA8N/yzB5rrvNOPhOrea1RNCRePn0bMvXkDpfUs8dpH
z1qQog4soloAhojIYJYA3OGqKr3ryNnfB0B8lePQ1ZaJgkURqOjiVKF6xv5FmnuM
C1uwiTfr/9IKijiy8oCKKKSLTB5lY3Rk0o03D+LrqgLp27A41WvvhGo4djBqXse1
OTANBgkqhkiG9w0BAQUFAAOBgQBzTpgFc1YCpo8QKeoDBRag4tn2y8BzkeLeLMgy
gQAYCGNjJjrV0ChYKMJnqLPCrP9+/Otyj9ZByn9+T1Jx9/khuh9oNXCwF5FUE5VE
gkn3kPo1LdLBqKpfUSeFcYNJDQDhtThVwEq05Ifm+JuCCM4J3BbFuZpJM5xnbcIZ
mjcn5w==
-----END CERTIFICATE-----
subject=/C=ca/ST=California/L=SF/O=Oracle/OU=ldap/CN=server admin
issuer=/C=FR/ST=France/L=Grenoble/O=Oracle/OU=OUD/CN=CA Certificate
---Verify return code: 0 (ok)
Acceptable client certificate CA names
/C=FR/ST=France/L=Grenoble/O=Oracle/OU=OUD/CN=CA Certificate
/C=fr/ST=Isere/L=Montbonnot/O=Oracle/OU=ldap/CN=server_8839
---
SSL handshake has read 2179 bytes and written 312 bytes
---
New, TLSv1/SSLv3, Cipher is EDH-DSS-DES-CBC3-SHA
Server public key is 1024 bit
SSL-Session:
Protocol  : TLSv1
Cipher    : EDH-DSS-DES-CBC3-SHA
Session-ID: 4F16C59B172D329E44AF199B4E49B14E54163AAF783A68FBD48556FCB06A9238
Session-ID-ctx:
Master-Key: 21CC1BBF638FFDAF16E5DBAB337728D029F0125D483636EF7590BE3005DDA96AEAF60DE88172DE925806F633EB09ACBE
Key-Arg   : None
Start Time: 1326892443
Timeout   : 300 (sec)
Verify return code: 0 (ok)

20.10.4 シナリオ4 - SSLHandshakeException

セキュアなサーバー接続を確立しようとすると、ldapsearchにより次のメッセージが発行されます:

ldapsearch  -p 7636 -D "cn=Directory Manager" -w secret12  -P config/truststore -Z -b dc=example,dc=com uid=user.0 Cannot send the simple bind request:  SSLHandshakeException(sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target)

サーバーの証明書が自己署名証明書であり、証明書チェーンでないため、このエラーが表示されます。エラー・コード18を受け取ります。

以下に、このプロセスの例を示します。

openssl s_client -connect localhost:7636
CONNECTED(00000004)
depth=0 /C=ca/ST=California/L=SF/O=Oracle/OU=ldap/CN=server admin
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=ca/ST=California/L=SF/O=Oracle/OU=ldap/CN=server admin
verify return:1
---
Certificate chain
0 s:/C=ca/ST=California/L=SF/O=Oracle/OU=ldap/CN=server admin
i:/C=ca/ST=California/L=SF/O=Oracle/OU=ldap/CN=server admin
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDBjCCAsSgAwIBAgIETxRMvTALBgcqhkjOOAQDBQAwZjELMAkGA1UEBhMCY2Ex
EzARBgNVBAgTCkNhbGlmb3JuaWExCzAJBgNVBAcTAlNGMQ8wDQYDVQQKEwZPcmFj
bGUxDTALBgNVBAsTBGxkYXAxFTATBgNVBAMTDHNlcnZlciBhZG1pbjAeFw0xMjAx
MTYxNjEzNDlaFw0xMjA0MTUxNjEzNDlaMGYxCzAJBgNVBAYTAmNhMRMwEQYDVQQI
EwpDYWxpZm9ybmlhMQswCQYDVQQHEwJTRjEPMA0GA1UEChMGT3JhY2xlMQ0wCwYD
VQQLEwRsZGFwMRUwEwYDVQQDEwxzZXJ2ZXIgYWRtaW4wggG4MIIBLAYHKoZIzjgE
ATCCAR8CgYEA/X9TgR11EilS30qcLuzk5/YRt1I870QAwx4/gLZRJmlFXUAiUftZ
PY1Y+r/F9bow9subVWzXgTuAHTRv8mZgt2uZUKWkn5/oBHsQIsJPu6nX/rfGG/g7
V+fGqKYVDwT7g/bTxR7DAjVUE1oWkTL2dfOuK2HXKu/yIgMZndFIAccCFQCXYFCP
FSMLzLKSuYKi64QL8Fgc9QKBgQD34aCF1ps93su8q1w2uFe5eZSvu/o66oL5V0wL
PQeCZ1FZV4661FlP5nEHEIGAtEkWcSPoTCgWE7fPCTKMyKbhPBZ6i1R8jSjgo64e
K7OmdZFuo38L+iE1YvH7YnoBJDvMpPG+qFGQiaiD3+Fa5Z8GkotmXoB7VSVkAUw7
/s9JKgOBhQACgYEAw+2EIpmwy0rqtHbNb6gxbEtW0hplXXQdHEQp24brde1jt1qv
LDz/c8KR+fVxqvTxAmurGt1qbrhjXcUxi1KdaLnLnLXTCoD+ZLQU+F6B/TNmfrxb
AJmHtmoZsFtNCBTC++FClXtconKyXjEWnKMw7fEb+gNY3eTUrcyIpa/YEbYwCwYH
KoZIzjgEAwUAAy8AMCwCFEtf5+J77Q/5fI6bZ7k3D1rdbw6UAhQkWGmp8VOiMdUg
5K4wK7Y7cC0wSQ==
-----END CERTIFICATE-----
subject=/C=ca/ST=California/L=SF/O=Oracle/OU=ldap/CN=server admin
issuer=/C=ca/ST=California/L=SF/O=Oracle/OU=ldap/CN=server admin
---
Acceptable client certificate CA names
/C=FR/ST=France/L=Grenoble/O=Oracle/OU=OUD/CN=CA Certificate
/C=ca/ST=California/L=SF/O=Oracle/OU=ldap/CN=user.41
/C=ca/ST=California/L=SF/O=Oracle/OU=ldap/CN=server admin
---
SSL handshake has read 1594 bytes and written 312 bytes
---
New, TLSv1/SSLv3, Cipher is EDH-DSS-DES-CBC3-SHA
Server public key is 1024 bit
SSL-Session:
Protocol  : TLSv1
Cipher    : EDH-DSS-DES-CBC3-SHA
Session-ID: 4F16C3F27655013F71AE2120134A8D1AFE966A1D9233618507DEFE9C607417AA
Session-ID-ctx:
Master-Key: 57BDB7FCA9A293E65274AA7CDD0E7CC48AA227806FC2B54C9F9E36BB26D32943FC115CE4FF9A605B6B6BD237026F3D0E
Key-Arg   : None
Start Time: 1326892018
Timeout   : 300 (sec)
Verify return code: 18 (self signed certificate)

解決策

問題解決のために次の手順を実行します:

1. CA証明書をサーバーのキーストアにインポートします。

keytool -importcert -alias ca-cert -keystore config/keystore -storetype JKS -file $CA_SSL/ca-cert.pem
Enter keystore password:
Owner: CN=CA Certificate, OU=OUD, O=Oracle, L=Grenoble, ST=France, C=FR
Issuer: CN=CA Certificate, OU=OUD, O=Oracle, L=Grenoble, ST=France, C=FR
Serial number: 96b69e65
Valid from: Wed Jan 04 15:51:37 MET 2012 until: Mon Sep 04 16:51:37 MEST 2428
Certificate fingerprints:
MD5:  D0:5B:C8:2A:3D:3B:09:07:5A:29:62:E3:27:99:4E:D4
SHA1: E4:C9:BB:B7:5B:49:C7:7E:BF:8B:C3:C3:DC:DF:29:E7:74:A0:66:03
Signature algorithm name: SHA1withRSA
Version: 3
Trust this certificate? [no]:  yes
Certificate was added to keystore

2. 署名済のサーバー証明書応答をサーバーのキーストアにインポートします。

keytool -importcert -trustcacerts -alias server-cert -keystore config/keystore -storetype JKS -file server-cert.pem Enter keystore password:
Certificate reply was installed in keystore

3. LDAPサーバー・キーストア内の証明書をリストします。

keytool -list -keystore config/keystore -storepass secret12 -v

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 2 entries

Alias name: ca-cert
Creation date: Jan 18, 2012
Entry type: trustedCertEntry

Owner: CN=CA Certificate, OU=OUD, O=Oracle, L=Grenoble, ST=France, C=FR
Issuer: CN=CA Certificate, OU=OUD, O=Oracle, L=Grenoble, ST=France, C=FR
Serial number: 96b69e65
Valid from: Wed Jan 04 15:51:37 MET 2012 until: Mon Sep 04 16:51:37 MEST 2428
Certificate fingerprints:
MD5:  D0:5B:C8:2A:3D:3B:09:07:5A:29:62:E3:27:99:4E:D4
SHA1: E4:C9:BB:B7:5B:49:C7:7E:BF:8B:C3:C3:DC:DF:29:E7:74:A0:66:03
Signature algorithm name: SHA1withRSA
Version: 3

4. SSL上でldapsearchリクエストを使用して接続を検証します。

ldapsearch  -p 7636 -D "cn=Directory Manager" -w secret12  -P config/truststore -Z -b dc=example,dc=com uid=user.0
dn: uid=user.0,ou=People,dc=example,dc=com
postalAddress: Aaccf Amar$01251 Chestnut Street$Panama City, DE  50369
postalCode: 50369
uid: user.0
description: This is the description for Aaccf Amar.
userPassword: {SSHA}vVIy4fjEUyt0L8GSVzX+VrJKEgGASLkeCvL1ng==
employeeNumber: 0
initials: ASA
givenName: Aaccf
objectClass: person
objectClass: inetorgperson
objectClass: organizationalperson
objectClass: top
pager: +1 779 041 6341
mobile: +1 010 154 3228
cn: Aaccf Amar
telephoneNumber: +1 685 622 6202
sn: Amar
street: 01251 Chestnut Street
homePhone: +1 225 216 5900
mail: user.0@maildomain.net
l: Panama City
st: DE

5. ログにアクセスします。

[18/Jan/2012:16:39:24 +0100] CONNECT conn=1 from=127.0.0.1:46726 to=127.0.0.1:7636 protocol=LDAPS
[18/Jan/2012:16:39:24 +0100] BIND REQ conn=1 op=0 msgID=1 type=SIMPLE dn="cn=Directory Manager"
[18/Jan/2012:16:39:24 +0100] BIND RES conn=1 op=0 msgID=1 result=0 authDN="cn=Directory Manager,cn=Root DNs,cn=config" etime=31
[18/Jan/2012:16:39:24 +0100] SEARCH REQ conn=1 op=1 msgID=2 base="dc=example,dc=com" scope=wholeSubtree filter="(uid=user.0)" attrs="ALL"
[18/Jan/2012:16:39:24 +0100] SEARCH RES conn=1 op=1 msgID=2 result=0 nentries=1 etime=18
[18/Jan/2012:16:39:24 +0100] UNBIND REQ conn=1 op=2 msgID=3
[18/Jan/2012:16:39:24 +0100] DISCONNECT conn=1 reason="Client Disconnect"

20.10.5 シナリオ5 - SASL EXTERNALバインド・リクエストを処理できない

SSL上でOUD SASLクライアントの外部認証を実行しようとすると、次のエラー・メッセージが表示されます:

ldapsearch -p 7636 -Z -K /export/home/oud/security/client/config/keystore -W secret12 -P /export/home/oud/security/client/config/truststore --trustStorePassword secret12 -N user.41-cert --useSASLExternal -b dc=example,dc=com uid=user.0
The SASL EXTERNAL bind attempt failed
Result Code:  49 (Invalid Credentials)

アクセス・ログを表示すると、次のメッセージが示されます:

CONNECT conn=2 from=127.0.0.1:46763 to=127.0.0.1:7636 protocol=LDAPS
[18/Jan/2012:17:48:44 +0100] BIND REQ conn=2 op=0 msgID=1 type=SASL mechanism=EXTERNAL dn=""
[18/Jan/2012:17:48:44 +0100] BIND RES conn=2 op=0 msgID=1 result=49 authFailureID=1245310 authFailureReason="The SASL EXTERNAL bind request could not be processed because the client did not present a certificate chain during SSL/TLS negotiation" etime=6
[18/Jan/2012:17:48:44 +0100] DISCONNECT conn=2 reason="Client Disconnect"

クライアント証明書が有効な証明書チェーンでない場合に、このエラーが表示されます。

解決策

この問題を解決するには、次の手順を実行します:

1. CA証明書をクライアントのキーストアにインポートします。

keytool -importcert -alias ca-cert -keystore config/keystore \
-storetype JKS -file $CA_SSL/ca-cert.pem
Enter keystore password:
Owner: CN=CA Certificate, OU=OUD, O=Oracle, L=Grenoble, ST=France, C=FR
Issuer: CN=CA Certificate, OU=OUD, O=Oracle, L=Grenoble, ST=France, C=FR
Serial number: 96b69e65
Valid from: Wed Jan 04 15:51:37 MET 2012 until: Mon Sep 04 16:51:37 MEST 2428
Certificate fingerprints:
MD5:  D0:5B:C8:2A:3D:3B:09:07:5A:29:62:E3:27:99:4E:D4
SHA1: E4:C9:BB:B7:5B:49:C7:7E:BF:8B:C3:C3:DC:DF:29:E7:74:A0:66:03
Signature algorithm name: SHA1withRSA
Version: 3
Trust this certificate? [no]:  yes
Certificate was added to keystore

2. ユーザー署名済の応答証明書をクライアントのキーストアにインポートします。

keytool -importcert -trustcacerts -alias user.41-cert -keystore config/keystore -storetype JKS -file user.41-cert.pem -storepass secret12
Certificate reply was installed in keystore

3. ldapコマンドを実行します。

ldapsearch -p 7636 -Z -K /export/home/oud/security/client/config/keystore -W secret12 -P /export/home/oud/security/client/config/truststore --trustStorePassword secret12 -N user.41-cert --useSASLExternal -b dc=example,dc=com uid=user.0
dn: uid=user.0,ou=People,dc=example,dc=com
postalAddress: Aaccf Amar$01251 Chestnut Street$Panama City, DE  50369
postalCode: 50369
uid: user.0
description: This is the description for Aaccf Amar.
employeeNumber: 0
initials: ASA
givenName: Aaccf
objectClass: person
objectClass: inetorgperson
objectClass: organizationalperson
objectClass: top
pager: +1 779 041 6341
mobile: +1 010 154 3228
cn: Aaccf Amar
telephoneNumber: +1 685 622 6202
sn: Amar
street: 01251 Chestnut Street
homePhone: +1 225 216 5900
mail: user.0@maildomain.net
l: Panama City
st: DE

4. ログを検証します。

[18/Jan/2012:18:04:49 +0100] CONNECT conn=3 from=127.0.0.1:46777 to=127.0.0.1:7636 protocol=LDAPS
[18/Jan/2012:18:04:49 +0100] BIND REQ conn=3 op=0 msgID=1 type=SASL mechanism=EXTERNAL dn=""
[18/Jan/2012:18:04:49 +0100] BIND RES conn=3 op=0 msgID=1 result=0 authDN="uid=user.41,ou=People,dc=example,dc=com" etime=37
[18/Jan/2012:18:04:49 +0100] SEARCH REQ conn=3 op=1 msgID=2 base="dc=example,dc=com" scope=wholeSubtree filter="(uid=user.0)" attrs="ALL"
[18/Jan/2012:18:04:49 +0100] SEARCH RES conn=3 op=1 msgID=2 result=0 nentries=1 etime=15
[18/Jan/2012:18:04:49 +0100] UNBIND REQ conn=3 op=2 msgID=3
[18/Jan/2012:18:04:49 +0100] DISCONNECT conn=3 reason="Client Disconnect"

20.11 Javaデバッグ情報を使用したSSLまたはTLSのデバッグ

Javaデバッグ情報を使用してSSLまたはTLS接続のネットワーク・トラフィックをトラブルシューティングできます。

SSLを解析する方法がネットワーク・アクセスの追跡しかないことがあります。Oracle Unified Directoryでは、config/java.propertiesファイルで-Djavax.net.debug=allオプションをサーバーに追加することによりSSLをデバッグできます。

サンプルのデバッグ出力は次のとおりです:

server.core.DirectoryServer (alert type org.opends.server.DirectoryServerStarted, alert ID 458887):  The Directory Server has started successfully
***
found key for : server-cert
chain [0] = [
[
Version: V3
Subject: CN=server admin, OU=ldap, O=mycompany, L=City1, ST=Country1, C=ca
Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5

Key:  SunPKCS11-Solaris DSA public key, 1024 bits (id 22714576, session object)
y: 137585178298829672773992262717400783035252676067753730258902133887472765737596162865068864757751081632128325087288240737049199605991868092341784810001823893557764102282007356730105011462039459191437293297725512863853468183519862577505401958362086546885405080570540575677103845462467633475547155894544465662390
p: 178011905478542266528237562450159990145232156369120674273274450314442865788737020770612695252123463079567156784778466449970650770920727857050009668388144034129745221171818506047231150039301079959358067395348717066319802262019714966524135060945913707594956514672855690606794135837542707371727429551343320695239
q: 864205495604807476120572616017955259175325408501
g: 174068207532402095185811980123523436538604490794561350978495831040599953488455823147851597408940950725307797094915759492368300574252438761037084473467180148876118103083043754985190983472601550494691329488083395492313850000361646482644608492304078721818959999056496097769368017749273708962006689187956744210730
Validity: [From: Mon Jan 16 17:15:45 MET 2012,
To: Mon Apr 16 18:15:45 MEST 2012]
Issuer: CN=CA Certificate, OU=OUD, O=mycompany, L=City2, ST=Country2, C=FR
SerialNumber: [96d4f0dc]

]
Algorithm: [SHA1withRSA]
Signature:
0000: 72 F6 7E 93 2B 87 B9 C7   39 51 4C D2 A7 B0 AA 36  r...+...9QL....6
0010: B8 0F BA C4 6E 43 70 72   81 50 09 7A 88 05 16 A2  ....nCpr.P.z....
0020: 1C 96 C2 49 B3 0A F9 AB   2B 4B 8D 59 4C BA 58 C9  ...I....+K.YL.X.
0030: EF B9 48 58 A7 C5 BB B5   0E 64 51 CF BC 58 DA 71  ..HX.....dQ..X.q
0040: E1 F7 2E A4 1D 1B FC D5   4F B2 70 B0 78 F4 FB E6  ........O.p.x...
0050: C4 6A 6A E0 DE B0 F5 98   7B 09 A9 A4 9D 17 4C F5  .jj...........L.
0060: 9F 06 07 E1 09 81 77 9E   41 3C 02 4C FB D8 94 ED  ......w.A<.L....
0070: 36 6A 65 5A 96 2C AE A4   86 83 66 63 BC 3C 8C 47  6jeZ.,....fc.<.G

]

Oracle Unified Directoryデバッグ・ログ・テキストに加えて、前記の情報が提供されます。

この項では、SSLデバッグ記録の使用法について説明します。この項の内容は次のとおりです:

- 第20.11.1項「SSLデバッグ記録の有効化」

- 第20.11.2項「SSLデバッグ記録の無効化」

20.11.1 SSLデバッグ記録の有効化

次の手順を実行して、SSLデバッグ記録を有効化します:

1. config/java.propertiesファイルのstart-ds.java-argsプロパティを次の情報で更新します:

start-ds.java-args=-server -Djavax.net.debug=all

2. 第A.2.5項「dsjavaproperties」の手順に従ってdsjavapropertiesコマンドを実行します。

3. stop-dsコマンドを使用してサーバー・インスタンスを停止します。

4. start-dsコマンドを使用してサーバー・インスタンスを再起動します。

注意:

SSLデバッグ情報は、logs/server.outファイルにログされます。

20.11.2 SSLデバッグ記録の無効化

次の手順を実行して、SSLデバッグ記録を無効化します:

1. java.propertiesファイルから-Djavax.net.debug=allプロパティを削除します。

start-ds.java-args=-server

2. 第A.2.5項「dsjavaproperties」の手順に従ってdsjavapropertiesコマンドを実行します。

3. stop-dsコマンドを使用してサーバー・インスタンスを停止します。

4. start-dsコマンドを使用してサーバー・インスタンスを再起動します。

20.12 許可および拒否ルールを使用した接続アクセスの制御

接続ハンドラの許可または拒否されたクライアント・ルールを使用して、どのホストがサーバーへのTCP接続を確立できるか管理します。接続ハンドラは、サーバーへの接続の受け入れに責任を持ちます。

この項に示された異なる種類の接続ハンドラとその構成プロパティは次のとおりです:

- allowed-clientこの接続ハンドラへの接続の確立を許可されているクライアントを判断するためのホスト名またはアドレス・マスクのセットを指定します。有効な値には、ホスト名、完全修飾ドメイン名、ドメイン名、IPアドレス、またはサブネットワーク・マスクを持つサブネットワークが含まれます。

- denied-clientこの接続ハンドラへの接続の確立を許可されていないクライアントを判断するためのホスト名またはアドレス・マスクのセットを指定します。有効な値には、ホスト名、完全修飾ドメイン名、ドメイン名、IPアドレス、またはサブネットワーク・マスクを持つサブネットワークが含まれます。許可と拒否の両方のクライアント・マスクが定義され、クライアント接続が両方のリストの中の1つ以上のマスクと一致すると、接続は拒否されます。拒否リストのみ指定された場合、そのリストの中のマスクと一致しないクライアントはすべて許可されます。

注意:

IPv4とIPv6の両方のアドレスがサポートされています。

20.12.1 許可および拒否クライアント・ルールのプロパティ構文

allowed-clientプロパティとdenied-clientプロパティは、同一構文を使用して、IP (IPv4またはIPv6)アドレスおよびホスト名に対してパターン・マッチングを実行します。

次の構文がサポートされています:

- IPアドレス - 許可または拒否されるクライアントのIPアドレスはルールの中に指定できます。例:

ds-cfg-denied-client:   192.168.5.6
ds-cfg-allowed-client:  2001:fecd:ba23:cd1f:dcb1:1010:9234:4088

- CIDR表記のIPアドレス - CIDR表記を使用するIPアドレスを指定することにより特定範囲のIPアドレスを許可または拒否できます。例:

ds-cfg-denied-client:   192.168.5.6/28
ds-cfg-allowed-client:  2001:0db8:1234::/48

まず、192.168.5.0 - 192.168.5.15の範囲のクライアントが拒否され、第2に2001:0db8:1234:0000:0000:0000:0000:0000 - 2001:0db8:1234:ffff:ffff:ffff:ffff:ffffの範囲のクライアントが許可されます。

- '*'表記を持つIPアドレス - IPアドレスに'*'を指定してIPアドレスの部分と一致させることにより、特定範囲のIPアドレス(IPv4のみ)を許可または拒否できます。例:

ds-cfg-denied-client:   192.168.5.*
ds-cfg-allowed-client:   129.45.*.*

最初の例は192.168.5で始まるIPアドレスを持つクライアントを拒否し、2番目の例は129.45で始まるIPアドレスを持つクライアントを許可します。2番目の例では複数の一致文字が使用されていることに注意してください。すべてのIPアドレスを一致させるには、次のようなルールを使用します:

ds-cfg-denied-client:   *.*.*.*

- DNS名 - クライアントはDNS名によって制限できます。たとえば、ホスト名foo.example.comでクライアントを制限するには、次のように入力します:

ds-cfg-denied-client:   foo.example.com

- パターン一致を使用するDNS名 - これはIPアドレスのパターン一致と類似しています。プロパティに'*'を指定してDN名の部分と一致させます:

ds-cfg-allowed-client: foo.*.test.com

このプロパティにより、foo.bar.test.comまたはfoo.foobar.test.comなどのDN名を持つクライアントが許可されます。接尾辞で終了するDNS名のみと一致させる場合、プロパティは次のとおりです:

ds-cfg-allowed-client: .example.com

このプロパティにより、test.example.comまたはtest.me.example.comなどのDNS名を持つクライアントが許可されます。

注意:

ホスト名の変換はサーバー名サービスの構成により異なるため、DNSプロパティを使用するときには注意してください。

20.12.2 許可および拒否クライアント・ルールの構成

接続ハンドラは、それぞれに独自のルール・セットを持つ必要があります。例:

dn: cn=LDAP Connection Handler,cn=Connection Handlers,cn=config
objectClass: top
objectClass: ds-cfg-connection-handler
objectClass: ds-cfg-ldap-connection-handler
cn: LDAP Connection Handler
ds-cfg-java-class: org.opends.server.protocols.ldap.LDAPConnectionHandler
ds-cfg-enabled: true
ds-cfg-listen-address: 0.0.0.0
ds-cfg-listen-port: 389
ds-cfg-accept-backlog: 128
ds-cfg-allow-ldap-v2: true
ds-cfg-keep-stats: true
ds-cfg-use-tcp-keep-alive: true
ds-cfg-use-tcp-no-delay: true
ds-cfg-allow-tcp-reuse-address: true
ds-cfg-send-rejection-notice: true
ds-cfg-max-request-size: 5 megabytes
ds-cfg-max-blocked-write-time-limit: 2 minutes
ds-cfg-num-request-handlers: 2
ds-cfg-allow-start-tls: false
ds-cfg-use-ssl: false
ds-cfg-ssl-client-auth-policy: optional
ds-cfg-ssl-cert-nickname: server-cert
ds-cfg-denied-client: *.example.com
ds-cfg-denied-client:  129.45.*.*
ds-cfg-denied-client:   192.168.5.6

dn: cn=LDAPS Connection Handler,cn=Connection Handlers,cn=config
objectClass: top
objectClass: ds-cfg-connection-handler
objectClass: ds-cfg-ldap-connection-handler
cn: LDAPS Connection Handler
ds-cfg-java-class: org.opends.server.protocols.ldap.LDAPConnectionHandler
ds-cfg-enabled: true
ds-cfg-listen-address: 0.0.0.0
ds-cfg-listen-port: 636
ds-cfg-accept-backlog: 128
ds-cfg-allow-ldap-v2: true
ds-cfg-keep-stats: true
ds-cfg-use-tcp-keep-alive: true
ds-cfg-use-tcp-no-delay: true
ds-cfg-allow-tcp-reuse-address: true
ds-cfg-send-rejection-notice: true
ds-cfg-max-request-size: 5 megabytes
ds-cfg-max-blocked-write-time-limit: 2 minutes
ds-cfg-num-request-handlers: 2
ds-cfg-allow-start-tls: false
ds-cfg-use-ssl: true
ds-cfg-ssl-client-auth-policy: optional
ds-cfg-ssl-cert-nickname: server-cert
ds-cfg-key-manager-provider: cn=JKS,cn=Key Manager Providers,cn=config
ds-cfg-trust-manager-provider: cn=JKS,cn=Trust Manager Providers,cn=config
ds-cfg-allowed-client: .example.com
ds-cfg-allowed-client: foo.*.test.com
ds-cfg-allowed-client: 192.168.6.7/22

dsconfigコマンドを使用して、各接続ハンドラの許可および拒否プロパティを管理します。例:

$ dsconfig -n -X -p 4444 -D "cn=directory manager" -j pwd-file \
set-connection-handler-prop   --handler-name "LDAPS Connection Handler" \
--set denied-client:.example.com \
--set allowed-client:192.168.1.6/17

注意:

拒否ルールは許可ルールの前に適用されます。

20.13 強度無制限の暗号の構成

強度無制限の暗号を構成するには、Java Cryptography Extension Unlimited Strength Jurisdictionポリシー・ファイルをダウンロードして、暗号化サポートを追加する必要があります。次の手順に従って、ポリシー・ファイルのダウンロードとインストールを実行し、強度無制限の暗号を構成します:

1. 次のWebページからJava Cryptography Extension Unlimited Strength Jurisdictionポリシー・ファイルをダウンロードします。
http://www.oracle.com/technetwork/java/javase/downloads/index.html

2. ダウンロードされたzipファイルに含まれるREADME.txtファイルの説明に従ってインストールを実行します。
Java Cryptography Extension Unlimited Strength Jurisdictionポリシー・ファイルがインストールされます。

3. Oracle Unified Directoryサーバーを停止した後、再起動します。

21 プロキシ/データ・ソース間のセキュリティ構成

プロキシとリモートLDAPサーバーの間のセキュリティ構成は、次の方法で構成できます:

- プロキシのインストール時にoud-proxy-setup GUIを使用して。詳細は、Oracle Fusion Middleware Oracle Unified Directoryインストレーション・ガイドのGUIを使用したプロキシ・サーバーの設定に関する項を参照してください。

- プロキシのインストール後にインタラクティブ・モードでdsconfigコマンドを使用して。dsconfigコマンドの使用法に関する一般的な情報は、第14.1項「dsconfigを使用したサーバー構成の管理」を参照してください。

セキュリティ管理のために、ネットワーク・グループを有効にして着信クライアント接続を分類することができます。ネットワーク・グループを使用すると、接続の分類に基づいて実行可能な操作を制限できます。この機能を使用して、たとえば指定したIPアドレスから接続するクライアントに対してのみアクセスを制限することができます。詳細は、第14.1.6項「dsconfigを使用したネットワーク・グループの構成」を参照してください。

プロキシとリモートLDAPサーバーの間でのセキュアなクライアント認証のために、各リモートLDAPサーバーのトラスト・ストアにプロキシの証明書をインポートする必要があります。この場合は、キーストアを手動で構成する必要があります。詳細は、第20.2項「キー・マネージャ・プロバイダの構成」を参照してください。

プロキシのセキュリティは、バックエンドACIをバイパスしません。

この章では、次のトピックを取り扱います:

- 第21.1項「プロキシによるセキュアな接続の管理」

- 第21.2項「セキュアな接続のモード」

- 第21.3項「プロキシとデータ・ソースの間でのdsconfigを使用したセキュリティ構成」

21.1 プロキシによるセキュアな接続の管理

プロキシは、クライアントとのセキュリティとディレクトリ・サーバーとのセキュリティを管理し、SSLとStartTLSの両方をサポートします。

セキュリティを構成する際には、プロキシがリモートLDAPサーバーにどのように接続するかを指定する必要があります。それには、プロキシによるSSLの使用について、always、neverまたはuserを指定します。alwaysを指定すると、クライアントがどのような方法でプロキシに接続するかに関係なく、リモートLDAPサーバーとの接続は常にSSLを使用して保護されます。neverを指定すると、クライアントがセキュアな方法でプロキシに接続するかどうかに関係なく、プロキシとリモートLDAPディレクトリ・サーバーとの接続は保護されなくなります。userを指定すると、プロキシとリモートLDAPディレクトリ・サーバーの間のセキュリティが、クライアントとプロキシの間のセキュリティと同じになります。たとえば、クライアントがSSLを使用して接続している場合は、リモートLDAPサーバーへの接続でもSSLが使用されます。例外として、クライアントがStartTLSを使用して接続している場合は、プロキシからリモートLDAPサーバーへの接続にSSLが使用されます。

詳細は、「セキュアな接続のモード」を参照してください。

21.2 セキュアな接続のモード

プロキシは、リモートLDAPサーバーへの接続を次の3つのSSLセキュリティ・モードで処理します:

- always

- never

- user

これらの設定は、dsconfig --advancedコマンドを使用して表示および編集できます。メイン・メニューから「拡張」を選択します。

remote-ldap-server-ssl-policyプロパティは、3つのSSLセキュリティ・モードを管理します。

remote-ldap-server-ssl-policyプロパティをalwaysまたはuserに設定した場合は、プロキシがリモートLDAPサーバーを信頼する必要があります。そのためには、各リモートLDAPサーバーの証明書を手動でプロキシのトラスト・ストアにインポートする必要があります。

21.2.1 alwaysセキュア・モード

remote-ldap-server-ssl-policyプロパティをalwaysに設定すると、クライアントがどのような方法でプロキシに接続するかに関係なく、プロキシからリモートLDAPサーバーへの接続はすべて完全にセキュアなSSL接続となります。

このモードでは、プール・サイズは1つのタイプの接続プール、すなわちセキュアなLDAPS接続を参照します。

alwaysセキュア・モードでは、各リモートLDAPサーバーの証明書をプロキシのトラスト・ストアにインポートする必要があります。Oracle Unified DirectoryサーバーではないバックエンドLDAPサーバーが多数存在していて、インストール時に証明書が管理されていなかった場合、プロキシのトラスト・ストアへ証明書をインポートすることが制約になる可能性があります。テスト環境の場合は、ssl-trust-allパラメータを使用してこのプロセスを迅速化できます。このパラメータは、すべてのリモートLDAPサーバーを信頼することをプロキシにリクエストします。

21.2.2 neverセキュア・モード

remote-ldap-server-ssl-policyプロパティをneverに設定すると、プロキシからリモートLDAPサーバーへの接続はいっさいセキュアなSSL接続にならなくなります。

このモードでは、リモートLDAPサーバーのプロキシによる監視接続は決してセキュアになりません。

このモードでは、プール・サイズは1つのタイプの接続プール、すなわち非保護LDAP接続を参照します。

21.2.3 userセキュア・モード

remote-ldap-server-ssl-policyプロパティをuserに設定すると、プロキシからリモートLDAPサーバーへの接続がセキュアになるかどうかは、クライアントがどのような方法でプロキシに接続するかに関係なく、クライアントからプロキシへの着信リクエストによって決まります。

着信クライアント・リクエストがセキュアな場合、それがSSLであってもStartTLSであっても、プロキシからリモートLDAPサーバーへの接続はセキュアなSSL接続になります。

着信クライアント・リクエストがセキュアでない場合、プロキシからリモートLDAPサーバーへの接続はセキュアなSSL接続になりません。

このモードでは、プロキシとリモートLDAPサーバーの間の監視接続は決してセキュアになりません。

2つの接続プールが作成されます。1つはセキュアで、もう1つは非保護です。図21-1を参照してください。左のシナリオでは、クライアントが非保護接続を使用してプロキシに接続し、プロキシからリモートLDAPサーバーまでは非保護の接続プールが使用されます。右のシナリオでは、クライアントがセキュアな接続(SSLとStartTLSのどちらでも)を使用してプロキシに接続し、プロキシからリモートLDAPサーバーまではセキュアなSSL接続プールが使用されます。

図21-1 userセキュア・モードでの接続

「図21-1 userセキュア・モードでの接続」の説明

userモードでは、各リモートLDAPサーバーの証明書をプロキシのトラスト・ストアにインポートする必要があります。Oracle Unified DirectoryサーバーではないリモートLDAPサーバーが多数存在していて、インストール時に証明書が管理されていなかった場合、プロキシのトラスト・ストアへ証明書をインポートすることが制約になる可能性があります。テスト環境では、ssl-trust-allパラメータを使用してこのプロセスを迅速化できます。このパラメータは、すべてのリモートLDAPサーバーを信頼することをプロキシにリクエストします。

remote-ldap-server-ssl-policyプロパティがuserに設定されている場合、プール・サイズは2つのタイプの接続プール、すなわち非保護のLDAP接続とセキュアなLDAPS接続を参照します。たとえば、図21-2のようにpool-initial-sizeで接続数が5に設定された場合、LDAP拡張が初期化されるときに、5個のLDAP接続からなるプールが1つと5個のLDAPS接続からなるプールが1つ(つまり合計10個の接続)が存在することになります。この初期化の後、各プールは各自について設定されたパラメータに基づいて、それぞれ個別に進化していきます。

注意:

デフォルトでは、pool-initial-sizeは10(接続数)に設定されています。

図21-2 複数の接続プール

21.3 プロキシとデータ・ソースの間でのdsconfigを使用したセキュリティ構成

dsconfigツールは、証明書認証によって保護された接続を通じてサーバーにアクセスします。dsconfigを非インタラクティブ・モードで実行する場合(dsconfig -nを使用して)、トラスト・ストア・パラメータの指定は、そのコマンドをローカルとリモートのどちらで実行するかによって決まります。コマンドをローカルまたはリモートで実行する方法の詳細は、「dsconfigコマンドの概要」を参照してください。

21.3.1 dsconfigを使用してプロキシとディレクトリ・サーバーの間のセキュリティを構成する手順

このタスクでは、リモートLDAPサーバーへの接続のセキュリティを構成するために必要な主要な手順について説明します。プロセスが、プロキシとクライアントの間のセキュリティを構成する場合のプロセスに似ている箇所では、関連する手順への参照が示されています。

1. プロキシからリモートLDAPサーバーへクライアント認証を渡す必要がない場合は、ステップ2に進んでください。
プロキシからリモートLDAPサーバーへクライアント認証を渡す必要がある場合は、次のサブステップを実行してください:

1. リモートLDAPサーバー接続のキーストアを構成します。
これを行うには、Javaコマンドkeytoolを使用してプロキシ・サーバー上に証明書を生成します。キーストアは手動で構成する必要があります。詳細は、「キー・マネージャ・プロバイダの構成」を参照してください。

証明書に自己署名するか、外部の認証局による署名を取得します。詳細は、「キー・マネージャ・プロバイダの構成」を参照してください。

2. リモートLDAPサーバー接続のキーストアについて、プロキシ上のキー・マネージャ・プロバイダを構成します。
詳細は、「キー・マネージャ・プロバイダの構成」を参照してください。このキー・マネージャ・プロバイダは、クライアントへのセキュアな接続を処理するために使用するキー・マネージャ・プロバイダとは別にすることができます。

3. リモートLDAPサーバーがクライアント認証を必要とする場合は、プロキシの証明書を各リモートLDAPサーバーのキーストアにインポートする必要があります。
Oracle Unified Directory上での証明書のインポートとエクスポートの方法は、「キー・マネージャ・プロバイダの構成」を参照してください。

2. プロキシがリモートLDAPサーバーとの間にセキュアな接続を確立できるようにするために、トラスト・ストアを構成します。

セキュアな接続を必要とするすべてのリモートLDAPサーバーについて、各サーバーの証明書をプロキシのトラスト・ストアにインポートする必要があります。これらのリモートLDAPサーバーの証明書はすべて、単一のプロキシ・トラスト・ストアにインポートすることも、複数のプロキシ・トラスト・ストアに分散させることもできます。プロキシのトラスト・ストアは、インポートするリモートLDAPサーバーの証明書の数だけ使用できます。

リモートLDAPデータ・ソースへのセキュアな接続をターゲットとするLDAPプロキシ拡張は、その構成の中で適切なトラスト・ストア・マネージャを参照する必要があります。LDAPプロキシ拡張はこれにより、インポートされたリモートLDAPサーバーの証明書にアクセスして、セキュアな接続を承認できるようになります。

3. 各トラスト・ストアは、プロキシ信頼マネージャ・プロバイダを必要とします。
プロキシ信頼マネージャ・プロバイダのリストを表示するには、dsconfig list-trust-manager-providersコマンドを使用します。例:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
list-trust-manager-providers

プロキシ信頼マネージャ・プロバイダを作成するには、dsconfig create-trust-manager-providerコマンドを使用します。例:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager"  -j pwd-file -X -n \
create-trust-manager-provider \
--provider-name Backend\ Servers \
--type file-based --set enabled:true \
--set trust-store-file:/localhost/config/backend-servers-truststore \
--set trust-store-type:JKS \
--set trust-store-pin-file:/installPath/config/backend-servers-truststore.pin

4. リモートLDAPサーバーの証明書をプロキシのトラスト・ストアにインポートします。

21.3.2 LDAP拡張の構成可能なセキュリティ関連プロパティ

dsconfigを使用してリモートLDAPサーバーへの接続を管理するときに、LDAP拡張のセキュリティ接続プロパティのいくつかを構成できます。LDAP拡張の管理の詳細は、「リモートLDAPサーバーとの通信の構成」を参照してください。直接的または間接的にセキュリティに関連する構成可能なプロパティには、次のものが含まれます:

remote-ldap-server-ssl-policy

この重要な値は、プロキシとリモートLDAPサーバーの間の接続の全体的なセキュリティ・モードを制御します。その使用法については、「セキュアな接続のモード」で説明しています。

pool-increment

remote-ldap-server-ssl-policyプロパティをuserに設定すると、2つの接続プールが作成され、各プールのサイズの増分変更がpool-incrementに設定されます。このプロパティの詳細は、「LDAPサーバー拡張の拡張プロパティを変更するには」を参照してください。

pool-initial-size

remote-ldap-server-ssl-policyプロパティがuserに設定されると、2つの接続プールが作成され、各プールの初期サイズ、つまり最小サイズがpool-initial-sizeに設定されます。したがってこの場合は、pool-initial-sizeで指定された合計接続数の2倍の数の接続が最初に存在することになります。詳細は、「LDAPサーバー拡張の拡張プロパティを変更するには」を参照してください。

pool-max-size

remote-ldap-server-ssl-policyプロパティがuserに設定されると、2つの接続プールが作成され、各プールの最大サイズがpool-max-sizeに設定されます。

デフォルト値は接続数1000です。このプロパティの詳細は、「LDAPサーバー拡張の拡張プロパティを変更するには」を参照してください。

remote-ldap-server-ssl-port

プロキシからリモートLDAPサーバーへのSSL接続のポート番号です。

ssl-client-alias

クライアントの認証のためにキーストアが作成されるときに、複数の鍵がそのキーストアに保存されることがあります。このプロパティは、どの鍵を使用するかを指定するために使用します。キーストアの詳細は、「SSLの迅速な起動と実行」を参照してください。また、「キー・マネージャ・プロバイダの構成」も参照してください。

ssl-key-manager-provider

LDAP拡張のために使用するキー・マネージャ・プロバイダを指定します。キー・マネージャ・プロバイダは必須ではなく、リモートLDAPサーバーがクライアント認証用に構成されている場合に使用できます。参照先のキー・マネージャ・プロバイダは、有効になっている必要があります。キー・マネージャ・プロバイダの詳細は、「キー・マネージャ・プロバイダの構成」を参照してください。

ssl-trust-all

このパラメータをtrueに設定すると、すべてのリモートLDAPサーバーが信頼されます。デフォルト値はfalseです。この値をtrueに設定すると、リモートLDAPサーバーから証明書をインポートする必要はなくなりますが、接続がセキュアでなくなります。

インタラクティブなdsconfig --advancedコマンドは、使用できる信頼マネージャ・プロバイダとしてブラインド信頼を提供しますが、ブラインド信頼マネージャ・プロバイダはプロキシ・サーバーについてはサポートされていません。証明書をインポートする必要をなくすには、かわりにssl-trust-allパラメータをtrueに設定します。その結果、デプロイメントがセキュアでなくなるため、この設定は本番環境ではお薦めできません。テスト用にのみ使用してください。

remote-ldap-server-ssl-policyをneverに設定すると、ssl-trust-allパラメータの値は無意味になります。この場合、プロキシとの間のすべての接続がセキュアでなくなります(暗号化されません)。remote-ldap-server-ssl-policyの詳細は、「セキュアな接続のモード」を参照してください。

ssl-trust-manager-provider

LDAP拡張のためにどの信頼マネージャ・プロバイダを使用するかを指定します。信頼マネージャ・プロバイダは、ssl-trust-allパラメータがtrueに設定されていないかぎり必須です。参照先の信頼マネージャ・プロバイダは、有効になっている必要があります。

22 データへのアクセス制御

セキュアなディレクトリ・サービスを作成するためには、ディレクトリの内容へのアクセスを制御することが最も重要です。データへのアクセスはアクセス制御命令(ACI)によって管理されます。ACIでは、個々のエントリ、各エントリに属するすべてのサブエントリ、またはグローバル・ベースで全エントリに対するアクセス権を指定します。

多数のACIや複雑なACIを使用すると、少数の単純なACIを使用する場合より多くの処理リソースが必要になります。多数のACIや極端に複雑なACIを指定すると、パフォーマンスが大幅に低下する可能性があります。

Oracle Unified Directoryには、特定のエントリに対する特定のユーザーの実効権限を表示する機能があります。この機能により、複雑で強力なアクセス制御メカニズムの管理が簡素化されます。

ACIモデルの概要は、第8章「Oracle Unified Directoryのアクセス制御モデルの理解」を参照してください。

次の各項では、データへのアクセスを制御するACIを作成する方法について説明します:

- 第22.1項「dsconfigによるグローバルACIの管理」

- 第22.2項「ldapmodifyによるACIの管理」

- 第22.3項「Oracle Directory Services Managerによるアクセス制御の管理」

- 第22.4項「Oracle Directory Services ManagerによるマクロACIの管理」

- 第22.5項「アクセス制御の使用例」

- 第22.6項「プロキシ認可ACI」

- 第22.7項「実効権限の表示」

22.1 dsconfigによるグローバルACIの管理

グローバルACIは、部分的なサブツリーではなく、DITのルートへのアクセスを制御します。グローバルACIは、ディレクトリ内のすべてのエントリに適用されます。グローバルACIは、dsconfigコマンドとldapmodifyコマンドを使用して、設定、リセットおよび削除できます。dsconfigは、管理コネクタを使用してSSLを介してサーバーの構成にアクセスします。dsconfigの詳細は、第14.1項「dsconfigを使用したサーバー構成の管理」を参照してください。

サブツリー内のエントリに適用されるACIを、dsconfigを使用して管理することはできません。グローバルではないACIの管理方法は、第22.2項「ldapmodifyによるACIの管理」を参照してください。

22.1.1 デフォルト・グローバルACI

Oracle Unified Directoryをインストールするときに、9個のデフォルト・グローバルACIが定義されます。デフォルト・グローバルACIの効果は、次を可能にすることです:

- 特定のコントロールと拡張操作に対して誰もが読取りアクセス権を持ちます。

- 属性に対して誰もがルートDSEレベルでの検索、比較、および読取りアクセス権を持ちます。特定の属性にアクセスするには明示的なアクセス権が必要となります。

- 認証されたユーザーはディレクトリ内にある自分自身のエントリ内の属性のサブセットを変更できます。ユーザーは自分自身のエントリを削除できません。

- ルートDSE内の多くの操作属性とcn=schemaを含む主要な操作属性と、サーバー全体の各エントリ内に現れるその他の属性に対するアクセス権を、すべてのユーザーが持ちます。

プロキシはグローバルACIを評価しません。プロキシはLDAPリクエストをリモートLDAPサーバーへ転送し、リモートLDAPサーバーがACIを評価します。

22.1.2 グローバルACIの表示

グローバルACIはすべて、アクセス制御ハンドラのglobal-aciプロパティの値です。サーバー上で現在構成されているグローバルACIを表示するには、dsconfigを使用してglobal-aciプロパティを表示します。

dsconfigコマンドは次のように実行します(出力の書式は読みやすいように変更してあります)。

$ dsconfig -h localhost -p 4444 -D cn="Directory Manager" -j pwd-file -X -n \
get-access-control-handler-prop --property global-aci
Property   : Value(s)
-----------:-----------------------------------------------------------------------------------
global-aci : (extop="1.3.6.1.4.1.26027.1.6.1 || 1.3.6.1.4.1.26027.1.6.3 ||
:   1.3.6.1.4.1.4203.1.11.1 || 1.3.6.1.4.1.1466.20037 ||
:   1.3.6.1.4.1.4203.1.11.3") (version 3.0; acl "Anonymous extended operation access";
:   allow(read) userdn="ldap:///anyone";),
: "(target="ldap:///")(targetscope="base")(targetattr="objectClass||namingContexts||
:   supportedAuthPasswordSchemes||supportedControl||supportedExtension||
:   supportedFeatures||supportedLDAPVersion||supportedSASLMechanisms||vendorName||
:   vendorVersion")(version 3.0; acl "User-Visible Root DSE Operational Attributes";
:   allow (read,search,compare) userdn="ldap:///anyone";)",
: (target="ldap:///cn=changelog")(targetattr="*")(version 3.0; acl "External changelog
:   access"; deny (all) userdn="ldap:///anyone";),
: "(target="ldap:///cn=schema")(targetscope="base")(targetattr="objectClass||
:   attributeTypes||dITContentRules||dITStructureRules||ldapSyntaxes||matchingRules||
:   matchingRuleUse||nameForms||objectClasses")(version 3.0; acl "User-Visible Schema
:   Operational Attributes"; allow (read,search,compare) userdn="ldap:///anyone";)",
: (target="ldap:///dc=replicationchanges")(targetattr="*")(version3.0; acl
:   "Replication backend access"; deny (all) userdn="ldap:///anyone";),
: (targetattr="audio||authPassword||description||displayName||givenName||homePhone||
:   homePostalAddress||initials||jpegPhoto||labeledURI||mobile||pager||postalAddress||
:   postalCode||preferredLanguage||telephoneNumber||userPassword")(version 3.0; acl
:   "Self entry modification"; allow (write) userdn="ldap:///self";),
: "(targetattr="createTimestamp||creatorsName||modifiersName||modifyTimestamp||entryDN||
:   entryUUID||subschemaSubentry||orclguid")(version 3.0; acl "User-Visible Operational
:   Attributes"; allow (read,search,compare) userdn="ldap:///anyone";)",
: "(targetattr="userPassword||authPassword")(version 3.0; acl "Self entry read";
:   allow (read,search,compare) userdn="ldap:///self";)",
: (targetcontrol="1.3.6.1.1.12 || 1.3.6.1.1.13.1 || 1.3.6.1.1.13.2||
:   1.2.840.113556.1.4.319 || 1.2.826.0.1.3344810.2.3 || 2.16.840.1.113730.3.4.18 ||
:   2.16.840.1.113730.3.4.9 ||1.2.840.113556.1.4.473 || 1.3.6.1.4.1.42.2.27.9.5.9")
:  (version 3.0; acl "Authenticated users control access"; allow(read)
:   userdn="ldap:///all";), (targetcontrol="2.16.840.1.113730.3.4.2 ||
:   2.16.840.1.113730.3.4.17 || 2.16.840.1.113730.3.4.19 ||1.3.6.1.4.1.4203.1.10.2 ||
:   1.3.6.1.4.1.42.2.27.8.5.1 ||2.16.840.1.113730.3.4.16 || 2.16.840.1.113894.1.8.31")
:  (version 3.0; acl "Anonymous control access"; allow(read) userdn="ldap:///anyone";)

22.1.3 グローバルACIの削除

グローバルACIを削除する最も簡単な方法は、dsconfigをインタラクティブ・モードで使用することです。インタラクティブ・モードでは、ガイドに従ってACI構成に対する操作を実行できるため、ここでは操作法を説明しません。非インタラクティブ・モードでグローバルACIを削除する場合は、コマンドライン・シェルの規則に従ってACI指定内の特殊文字をすべてエスケープしてください。

次の例では、dsconfigを非インタラクティブ・モードで使用して、匿名アクセスを許可するグローバルACIを削除しています。

dsconfigコマンドは次のように実行します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
set-access-control-handler-prop \
--remove global-aci:\(targetattr!=\"userPassword\|\|authPassword\"\) \
\(version\ 3.0\;\ acl\ \"Anonymous\ read\ access\"\;\ allow\(read,search,compare\) \
\ userdn=\"ldap:///anyone\"\;\)

22.1.4 グローバルACIの追加

グローバルACIを追加するときには、コマンドライン・シェルの規則に従ってACI指定内の特殊文字をすべてエスケープしてください。

次の例では、dsconfigを非インタラクティブ・モードで使用して、前の手順で削除したグローバルACIを追加しています:

dsconfigコマンドは次のように実行します。

$ dsconfig -h localhost -p 4444 -D cn="Directory Manager" -j pwd-file -n \
set-access-control-handler-prop \
--add global-aci:\(targetattr!=\"userPassword\|\|authPassword\"\) \
\(version\ 3.0\;\ acl\ \"Anonymous\ read\ access\"\;\ allow\ \(read,search,compare\)
\ userdn=\"ldap:///anyone\"\;\)

22.2 ldapmodifyによるACIの管理

LDIF文を使用してアクセス制御命令(ACI)を手動で作成し、ldapmodifyコマンドを使用してそのACIをディレクトリに追加することができます。ACIの値は非常に複雑な場合があるため、既存の値を表示してそれをコピーすれば、新しいACIを作成する助けになります。

ここに示されている以外のACIのサンプルについては、第22.5項「アクセス制御の使用例」を参照してください。

22.2.1 aci属性の値の表示

ACIは、エントリのaci属性の1つ以上の値として保存されます。aci属性は、ディレクトリ・ユーザーによる読取りと変更が可能な複数値操作属性であり、それ自体をACIによって保護する必要があります。

通常、管理ユーザーにはaci属性への完全アクセス権が付与されます。

aci属性の値を表示するには、次のldapsearchコマンドを実行します:

$ ldapsearch -h host -p port -D "cn=Directory Manager" -j pwd-file \
-b entryDN -s base "(objectclass=*)" aci

その結果、新しいLDIF ACI定義にコピーして編集できるLDIFテキストが出力されます。ACIの値は長い文字列になるため、ldapsearch操作による出力は、多くの場合数行にわたって表示されます(先頭の空白が継続マーカーになります)。LDIF出力をコピーして貼り付ける場合は、これを考慮してください。

設定されているACIの値によってどのような権限が付与または拒否されているかを表示する方法は、第22.7項「実効権限の表示」を参照してください。

22.2.2 ACIの追加

ACIを追加するには、LDIFファイル内でACIを指定し、ldapmodifyコマンドを使用してそのLDIFファイルを適用します。LDIFファイルは1つ以上のaci属性を含んでいる必要があり、各aci属性は接頭辞aci:とその後に続くACI指定で構成されます。詳細は、第8.2項「ACI構文」を参照してください。

1. LDIFファイルにACIを作成します。
次のサンプルLDIFファイル(aci.ldif)は、特定のユーザー(csmith)にディレクトリへの完全なアクセス権を付与するACIを追加します:

dn: ou=people,dc=example,dc=com
changetype: modify
add: aci
aci: (targetattr="*")(version 3.0; acl "give csmith full rights"; allow(all)
userdn =  "ldap:///uid=csmith,ou=People,dc=example,dc=com";)

2. ldapmodifyコマンドを使用して、ACIをディレクトリに適用します。
次のコマンドは、aci.ldifファイルに含まれているACIをディレクトリに適用します:

$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
--filename aci.ldif
Processing MODIFY request for ou=people,dc=example,dc=com
MODIFY operation successful for DN ou=people,dc=example,dc=com

22.2.3 ACIの削除

ACIを削除するには、LDIFファイル内のACIの値を指定し、ldapmodifyコマンドを使用してその値を削除します。

1. LDIFファイル内のACIを削除します。
次のサンプルLDIFファイル(remove-aci.ldif)は、前の手順で追加したACIを削除します:

dn: ou=people,dc=example,dc=com
changetype: modify
delete: aci
aci: (targetattr="*")(version 3.0; acl "give csmith full rights"; allow(all)
userdn =  "ldap:///uid=csmith,ou=People,dc=example,dc=com";)

2. ldapmodifyコマンドを使用して、変更をディレクトリに適用します。
次のコマンドは、remove-aci.ldifファイルに含まれている変更をディレクトリに適用します:

$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
--filename remove-aci.ldif
Processing MODIFY request for ou=people,dc=example,dc=com
MODIFY operation successful for DN ou=people,dc=example,dc=com

22.3 Oracle Directory Services Managerによるアクセス制御の管理

ODSMを使用すると、使いやすいインタフェースで、サーバー内で構成されている既存のACIを表示したり、新規のアクセス制御ポイントを作成したり、新規のACIを作成することができます。次の各トピックでは、ODSMを使用してアクセス制御を管理する方法について説明します。

22.3.1 構成済ACIの表示

Oracle Unified Directoryは、デフォルトで複数の事前構成済ACIをサポートしています。サーバー内で構成されているすべてのACIを、ODSMを使用して次の手順で表示できます:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「セキュリティ」タブを選択します。

3. 「ディレクトリACL」要素を開きます。

4. 構成済ACIはすべて、そのACIが定義されているアクセス制御ポイントの下に表示されます。ACIを表示するには、そのACIが定義されているアクセス制御ポイントを開きます。たとえば、ルート・エントリに適用されるACIのリストを表示するには、ルート・エントリを開きます。

5. ACIを選択すると、そのプロパティが右側のペインに表示されます。

22.3.2 アクセス制御ポイントの作成

アクセス制御ポイントは、その中にACIが定義されているエントリです(つまり、対応するaci属性を含んでいるエントリです)。

ODSMを使用して、新規のアクセス制御ポイントを次の手順で定義できます:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「セキュリティ」タブを選択します。

3. 「ディレクトリACL」要素を開きます。

4. 「作成」アイコンをクリックします。

5. 新しいアクセス制御ポイントとなるエントリのDNを「場所」フィールドに入力するか、「選択」をクリックしてディレクトリからエントリを選択します。

6. 1つまたは複数のACIをアクセス制御ポイントに追加するには、「ACIの作成」をクリックします。

7. ACIの詳細を入力します。これらのフィールドの詳細は、「ACIの追加」の項を参照してください。

8. アクセス制御ポイントに必要なACIを追加し終わったら、「作成」をクリックします。

22.3.3 既存のアクセス制御ポイントに基づくアクセス制御ポイントの作成

ODSMを使用して、既存のアクセス制御ポイントに基づく新規のアクセス制御ポイントを次の手順で定義できます:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「セキュリティ」タブを選択します。

3. 「ディレクトリACL」要素を開きます。

4. 新しいアクセス制御ポイントのベースにするアクセス制御ポイントを選択します。

5. 「類似作成」アイコンをクリックします。

6. 新しいアクセス制御ポイントとなるエントリのDNを「場所」フィールドに入力するか、「選択」をクリックしてディレクトリからエントリを選択します。

7. ベースにしたアクセス制御ポイントと同じACLを持つ新しいアクセス制御ポイントが自動的に作成されます。

8. 新しいアクセス制御ポイントに対して既存のACIの追加、編集または削除を行うには、それぞれ「作成」、「編集」または「削除」をクリックします。

9. ACIを追加または編集する場合は、必要な詳細を入力します。これらのフィールドの詳細は、第22.3.5項「ACIの追加」を参照してください。

10. 新しいアクセス制御ポイントのACIの変更が終わったら、「作成」をクリックします。

22.3.4 アクセス制御ポイントの削除

ODSMを使用して、アクセス制御ポイントを次の手順で削除できます:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「セキュリティ」タブを選択します。

3. 「ディレクトリACL」要素を開きます。

4. 削除するアクセス制御ポイントを選択し、「削除」アイコンをクリックします。

5. 「OK」をクリックして、削除を確定します。

22.3.5 ACIの追加

ODSMを使用して、次の手順でACIを既存のアクセス制御ポイントに追加できます:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「セキュリティ」タブを選択します。

3. 「ディレクトリACL」要素を開きます。

4. 新しいACIを追加するアクセス制御ポイントを開きます。

5. アクセス制御リストからACIを1つ選択します。

6. 「追加」アイコンをクリックします。

7. 使いやすいインタフェースを使用してACIを作成する場合は、「詳細の表示」タブを選択します。

8. 「範囲」で、ACIの範囲を選択します。
通常、ACIの範囲はサブツリーです。ACIの範囲は、次のいずれかの値を選択して制限できます:

- ベース。ACIは、ターゲット・リソースにのみ適用されます。

- 1。ACIは、ターゲット・リソースの第1世代の子に適用されます。

- サブツリー。ACIは、ターゲット・リソースとその下にあるサブツリーに適用されます。

- 下位。ACIは、ターゲット・リソースの下にあるサブツリーにのみ適用されます。

9. 「ターゲット」フィールドで、ACIの各要素を選択して「編集」をクリックし、そのプロパティを定義します。
ACIターゲットの定義方法の詳細は、第8.2.2項「ターゲットの定義」を参照してください。

10. 「権限」フィールドで、「追加」アイコンをクリックして権限とバインド・ルールを定義します。
ACI権限の定義方法の詳細は、第8.2.3項「権限の定義」を参照してください。

バインド・ルールの定義方法の詳細は、第8.3項「バインド・ルール」を参照してください。

バインド・ルールを定義するには、次の手順を実行します:

1. 「バインド・ルール・タイプ」リストから、目的のバインド・ルールを選択します。

2. 「ユーザー属性」タブをクリックし、ユーザー属性バインド・ルールを作成します。
次のステップを実行します:

- 「ユーザー属性演算子」プロパティの値を選択します。

- 「エントリ選択」プロパティの値として、「ターゲット・エントリとそのサブツリー」を選択します。

- 「継承レベル」リストから、継承レベルの値を選択します。

- 「ユーザー属性」フィールドで、属性を入力するか、「選択」をクリックしてエントリを検索します。

- 「ユーザー属性タイプ」プロパティとして、「バインド・タイプ・フォーマット」をクリックします。

- 「バインド・タイプ値」リストから、バインド・タイプ値を選択します。

- 「OK」をクリックします。

11. ACIを手動で定義する場合は、「テキスト・エディタ・ビュー」タブをクリックしてACIの詳細を入力します。
「検証」をクリックして、作成中のACIがACI構文に従っているかどうかチェックします。

このビューを使用して、既存のACIをコピーして貼り付けることもできます。

12. ACI定義が完成したら、「作成」をクリックします。

22.3.6 既存のACIに基づくACIの追加

ODSMを使用して、既存のACIに基づく新規のACIを次の手順で追加できます:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「セキュリティ」タブを選択します。

3. 「ディレクトリACL」要素を開きます。

4. コピーするACIが含まれているアクセス制御ポイントを開きます。

5. コピーするACIを選択します。

6. 「類似追加」アイコンをクリックします。

7. 変更が必要なACIの要素を、「テキスト・エディタ・ビュー」または「詳細の表示」で編集します。

8. ACI定義が完成したら、「作成」をクリックします。

22.3.7 ACIの変更

ODSMを使用して、既存のACIを次の手順で変更できます:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「セキュリティ」タブを選択します。

3. 「ディレクトリACL」要素を開きます。

4. 変更するACIが含まれているアクセス制御ポイントを開きます。

5. 変更するACIを選択します。

6. 「テキスト・エディタ・ビュー」または「詳細の表示」で、ACIの要素を編集します。

7. 変更が完了したら、「適用」をクリックします。

22.4 Oracle Directory Services ManagerによるマクロACIの管理

ODSMを使用して、target、targetFilter、userDn、groupDNおよびuserAttr属性にマクロ式を入力できます。マクロACIの詳細は、第8.6項「高度なアクセス制御のためのマクロACIの使用」を参照してください。

この項には次のトピックが含まれます:

- 第22.4.1項「ターゲットの編集」

- 第22.4.2項「ターゲット・フィルタの編集」

- 第22.4.3項「ユーザーDNまたはグループDNのバインド・ルールの編集」

- 第22.4.4項「ユーザー属性のバインド・ルールの編集」

22.4.1 ターゲットの編集

この項では、ターゲットにマクロACIを入力する方法について説明します。

ターゲットを編集してマクロACIを入力するには:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「セキュリティ」タブを選択します。

3. 「ディレクトリACL」リストから、編集するACIを選択します。

4. 「ターゲット」表から「ターゲット」行を選択します。

5. 「編集」をクリックします。

6. 「ターゲット」フィールドにマクロ式を入力します。

7. 「OK」をクリックします。

22.4.2 ターゲット・フィルタの編集

この項では、ターゲット・フィルタにマクロACIを入力する方法について説明します。

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「セキュリティ」タブを選択します。

3. 「ディレクトリACL」リストから、編集するACIを選択します。

4. 「ターゲット」表から「ターゲット・フィルタ」行を選択します。

5. 「編集」をクリックします。

6. 「ターゲット」フィールドに、マクロ式を使用してフィルタを入力します。

7. 「OK」をクリックします。

22.4.3 ユーザーDNまたはグループDNのバインド・ルールの編集

この項では、ターゲット・リソースに対する特定のユーザーまたは特定のグループのアクセス権を定義する方法について説明します。

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「セキュリティ」タブを選択します。

3. 「ディレクトリACL」リストから、編集するACIを選択します。

4. 「権限」表から「バインド・ルール」行を選択します。

5. 「編集」をクリックします。

6. 「バインド・ルール・タイプ」リストから、目的のバインド・ルールを選択します。

7. 「アクセス先」タブで、「ユーザーDN」リストから「ユーザーの指定」を選択します。

8. 「ユーザー」表で次の手順を実行します:

1. 「追加」をクリックします。

2. ユーザー・アクセスを定義するマクロ式を入力するか、「選択」をクリックしてエントリを検索し、選択したエントリにマクロ式を追加します。

9. ターゲット・リソースに対する特定のグループのアクセス権を指定するには、「グループDN演算子」表で次の手順を実行します:

1. 「追加」をクリックします。

2. グループ・アクセスを定義するマクロ式を入力するか、「選択」をクリックしてエントリを検索し、選択したエントリにマクロ式を追加します。

10. 「OK」をクリックします。

注意:

個々のバインド・ルールを編集することもできます。バインド・ルールを変更するには、「権限」表で必要なバインド・ルールを選択してから「編集」をクリックする必要があります。

22.4.4 ユーザー属性のバインド・ルールの編集

この項では、ユーザー属性のバインド・ルールを編集する方法について説明します。

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「セキュリティ」タブを選択します。

3. 「ディレクトリACL」リストから、編集するACIを選択します。

4. 「権限」表から「バインド・ルール」行を選択します。

5. 「編集」をクリックします。

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

7. 「バインド・ルール・タイプ」リストから、目的のバインド・ルールを選択します。

8. 「エントリ選択」プロパティの値として、「特定のエントリ」を選択します。

9. 「エントリ・ベースDN」フィールドで、ベースDNを入力するか、「選択」をクリックしてエントリを検索し、選択したエントリにマクロ式を追加します。

10. 「ユーザー属性」フィールドで、属性名を入力するか、「選択」をクリックして属性名のリストから属性名を選択します。

11. 「バインド・タイプ・フォーマット」をクリックします。

12. 「バインド・タイプ値」リストから、目的の値を選択します。

13. 「OK」をクリックします。

注意:

個々のバインド・ルールを編集することもできます。バインド・ルールを変更するには、「権限」表で必要なバインド・ルールを選択してから「編集」をクリックする必要があります。

22.5 アクセス制御の使用例

この項では、アクセス制御ポリシーの実装に使用できるサンプルACIをいくつか示します。

22.5.1 匿名アクセスの無効化

ディレクトリ・サーバーは、デフォルトでは匿名アクセスを許可します。匿名アクセス(特にディレクトリ内の機密データへの)を無効にする必要が生じる場合があります。

次のデフォルトACIは、userpassword属性およびauthPassword属性以外のすべてのユーザー属性に対する匿名読取りアクセスを許可します:

aci: (targetattr!="userPassword||authPassword")(version 3.0; acl "
Anonymous read access"; allow (read,search,compare) userdn="ldap:///anyone";)

匿名アクセスを無効にするには、次の例のように、デフォルト・アクセス制御ハンドラからこのACIを削除します:

$ dsconfig -h localhost -p 4444 -D cn="Directory Manager" -j pwd-file -n \
set-access-control-handler-prop \
--remove global-aci:'(targetattr!="userPassword||authPassword") \
(version 3.0; acl "Anonymous read access"; \
allow (read,search,compare) userdn="ldap:///anyone";)'

使用されているシェルによっては、ACI自体の中の引用符をエスケープする必要があります。

22.5.2 個人エントリへの書込みアクセスの許可

デフォルトのグローバルACIは、ユーザー自身のエントリの属性の限られたサブセットに対する書込みアクセスを許可します。これには次の属性が含まれます:

- audio

- authPassword

- description

- displayName

- givenName

- homePhone

- homePostalAddress

- initials

- jpegPhoto

- labeledURI

- mobile

- pager

- postalAddress

- postalCode

- preferredLanguage

- telephoneNumber

- userPassword

ユーザー自身のエントリについて上記以外の属性に対する書込みアクセスをユーザーに許可するには、この項で説明する手順を実行します。

22.5.2.1 DNSに基づく書込みアクセスの許可

次のサンプルACIは、example.com内でユーザーが自分自身のビジネス・カテゴリと部屋番号を変更できるようにします。

前述のように、書込みアクセスを許可すると、属性値を削除する権限もユーザーに付与することになります。

aci: (targetattr="businessCategory || roomNumber")
(version 3.0; acl "Write example.com"; allow (write)
userdn="ldap:///self" and dns="*.example.com";)

この例では、ACIがou=People,dc=example,dc=comエントリに追加されることを前提としています。

22.5.2.2 認証方式に基づく書込みアクセスの許可

次の例は、ディレクトリへのSSL接続が確立されている場合に、すべてのユーザーがexample.comツリー内の自分自身の全個人情報を更新できるようにします。

この権限を設定すると、ユーザーに属性値を削除する権限も付与することになります。

aci: (targetattr="*")
(version 3.0; acl "Write SSL"; allow (write)
userdn= "ldap:///self" and authmethod="ssl";)

この例では、aciがou=subscribers,dc=example,dc=comエントリに追加されることを前提としています。

22.5.3 グループによる接尾辞への完全アクセスの許可

ほとんどのディレクトリには、特定の業務機能を識別するためのグループがあります。これらのグループにディレクトリの全体または一部へのアクセス権を付与できます。グループにアクセス権を適用することで、メンバーに個別にアクセス権を設定せずにすみます。かわりにグループにユーザーを追加することで、そのユーザーにアクセス権を付与します。

次のサンプルACIは、HRgroupという名前のグループに、ディレクトリのou=Peopleブランチに対する完全アクセスを許可し、そのグループのメンバーが従業員情報を更新できるようにします:

aci: (targetattr="*") (version 3.0; acl "HR"; allow (all)
groupdn= "ldap:///cn=HRgroup,ou=People,dc=example,dc=com";)

この例では、ACIがou=People,dc=example,dc=comエントリに追加されることを前提としています。

22.5.4 グループ・エントリを追加および削除する権限の付与

一部の組織では、それによる従業員の効率の向上やコーポレート・ダイナミクスへの貢献が見込まれる場合に、従業員にツリー内のエントリの作成を許可します。次のそれぞれの例では、example.comの社会委員会が様々なクラブ(テニス、水泳、スキーなど)に編成されていることを前提としています。

22.5.4.1 "Create Group" ACIの作成

このサンプルACIは、example.comのあらゆる従業員が新しいクラブを表すグループ・エントリをou=social committeeブランチの下に作成することを許可します。

aci: (target = "ldap:///dc=ou=social committee,dc=example,dc=com")
(targetfilter="(|(objectClass=groupOfNames)(objectClass=top))")
(version 3.0; acl"Create Group"; allow (search,read,add) (userdn = @ "ldap:///uid=*,ou=People,dc=example,dc=com" and dns = "*.example.com");)

この例では、ACIがou=social committee,dc=example,dc=comエントリに追加されることを前提としています。

注意:

このACIでは書込み権限を付与しません。つまり、エントリ作成者はエントリを変更できません。サーバーは暗黙的にtopという値を追加するため、targattrfiltersにobjectClass=topを指定する必要があります。

22.5.4.2 "Delete Group" ACIの作成

このサンプルACIは、グループの所有者のみがou=Social Committeeブランチの下にあるグループ・エントリを変更または削除できるようにします。

aci: (target="ou=social committee,dc=example,dc=com")
(targetattr = "*")
(targattrfilters="del=objectClass:(objectClass=groupOfNames)")
(version 3.0; acl "Delete Group"; allow (write,delete)
userattr="owner#GROUPDN";)

この例では、ACIがou=social committee,dc=example,dc=comエントリに追加されることを前提としています。

22.5.5 グループへのユーザー自身の追加または削除の許可

多くのディレクトリで、グループに対するユーザー自身の追加または削除をユーザーに許可するACIが設定されています。これは、たとえばユーザーが自分自身をメーリング・リストに追加したりそこから削除できるようにする場合などに役立ちます。次のサンプルACIは、すべての従業員がou=social committeeサブツリーの下にある任意のグループ・エントリに自分自身を追加できるようにします:

aci: (targettattr="member")(version 3.0; acl "Group Members";
allow (selfwrite)
(userdn= "ldap:///uid=*,ou=People,dc=example,dc=com") ;)

この例では、ACIがou=social committee,dc=example,dc=comエントリに追加されることを前提としています。

22.5.6 グループへの条件付きアクセスの許可

多くの場合、グループにディレクトリへのアクセス権を付与する際には、正しい権限を持つユーザーを偽装しようとする侵入者からこれらの権限を確実に保護する必要があります。そのため、グループまたはロールに重要なアクセスを許可するアクセス制御ルールには、たいてい多くの条件が関連付けられます。

次のサンプルACIは、次の条件が満たされた場合に、ディレクトリ・ツリーのcorporate-clientsブランチへの完全アクセスをDirectory Administratorsグループに許可します:

- 証明書を使用して、SSL経由の接続が認証される

- 月曜日から木曜日の08:00から18:00の間にアクセスがリクエストされる

- 指定されたIPアドレスからアクセスがリクエストされる

aci: (target="ou=corporate-clients,dc=example,dc=com")
(targetattr = "*") (version 3.0; acl "corporate-clients"; allow (all)
(groupdn="ldap:///cn=DirectoryAdmin,ou=corporate-clients,dc=example,dc=com")
and (authmethod="ssl") and (dayofweek="Mon,Tue,Wed,Thu") and
(timeofday >= "0800" and timeofday <= "1800") and (ip="255.255.123.234"); )

この例では、ACIがou=corporate-clients,dc=example,dc=comエントリに追加されることを前提としています。

22.5.7 アクセスの拒否

ディレクトリ内にビジネスにとって重要な情報がある場合は、そのディレクトリへのアクセスを特に拒否する必要が生じることがあります。次のサンプルACIは、ユーザーが自分自身のエントリの下にある特定の請求情報(接続時間や勘定残高など)を読み取れるようにしますが、その情報の変更は禁止します。

このACIは、ユーザーが情報を読み取れるようにします。この例は、該当する属性がすでにスキーマ内に作成されていることを前提としています。

aci: (targetattr="connectionTime || accountBalance")
(version 3.0; acl "Billing Info Read"; allow (search,read)
userdn="ldap:///self";)

このACIは、ユーザーが情報を変更できないようにします。この例は、該当する属性がすでにスキーマ内に作成されていることを前提としています。

aci: (targetattr="connectionTime || accountBalance")
(version 3.0; acl "Billing Info Deny";
deny (write) userdn="ldap:///self";)

22.5.8 カンマを含むDNの権限の定義

LDIF ACI文の中にあるカンマを含むDNには、特別な処理が必要です。ACI文のターゲットとバインド・ルールの部分で、1つの円記号(\)を使用して、カンマをエスケープする必要があります。次の例でこの構文を示します:

dn: o=example.com Bolivia\, S.A.
objectClass: top
objectClass: organization
aci: (target="ldap:///o=example.com Bolivia\,S.A.")
(targetattr="*") (version 3.0; acl "aci 2"; allow (all)
groupdn = "ldap:///cn=Directory Administrators,
o=example.com Bolivia\, S.A.";)

22.6 プロキシ認可ACI

プロキシ認可方式は特殊な形の認証で、自分自身のIDを使用してディレクトリにバインドするユーザーに、プロキシ認可を通じて別のユーザーの権限が付与されます。

この例では、次のことを想定しています:

- クライアント・アプリケーションのバインドDNは、uid=MoneyWizAcctSoftware, ou=Applications,dc=example,dc=comです。

- クライアント・アプリケーションがアクセスをリクエストするターゲット・サブツリーは、ou=Accounting,dc=example,dc=comです。

- ou=Accounting,dc=example,dc=comサブツリーに対するアクセス権を持つAccounting Administratorが、ディレクトリ内に存在します。

クライアント・アプリケーションがAccountingサブツリーにアクセスできるようにするには(Accounting Administratorと同じアクセス権を使用して)、そのアプリケーションが次の権限と制御を持っている必要があります:

- Accounting Administratorは、ou=Accounting,dc=example,dc=comサブツリーに対するアクセス権限を持つ必要があります。次のACIは、Accounting Administratorエントリにすべての権限を付与します:

aci: (target="ldap:///ou=Accounting,dc=example,dc=com")
(targetattr="*") (version 3.0; acl "allow All-AcctAdmin"; allow
(all) userdn="ldap:///uid=AcctAdministrator,ou=Administrators,
dc=example,dc=com";)

- クライアント・アプリケーションはプロキシ権限を持っている必要があります。次のACIは、クライアント・アプリケーションにプロキシ権限を付与します:

aci: (target="ldap:///ou=Accounting,dc=example,dc=com")
(targetattr="*") (version 3.0; acl "allow proxy-
accounting software"; allow (proxy) userdn=
"ldap:///uid=MoneyWizAcctSoftware,ou=Applications,
dc=example,dc=com";)

- クライアント・アプリケーションはプロキシ認可制御を使用する許可を得る必要があります。次のACIは、クライアント・アプリケーションがプロキシ認可制御を使用することを許可します:

aci: (targetcontrol = "2.16.840.1.113730.3.4.18")
(version 3.0; acl "allow proxy auth - accounting software";
allow (all) userdn="ldap:///uid=MoneyWizAcctSoftware,ou=Applications,
dc=example,dc=com";)

これらのACIが定義されていれば、MoneyWizAcctSoftwareクライアント・アプリケーションは、ディレクトリにバインドし、プロキシDNのアクセス権を必要とするldapsearchやldapmodifyなどのLDAPコマンドを送信できます。

この例では、クライアントがldapsearchコマンドを実行する場合、そのコマンドには次のような制御が含まれます:

$ ldapsearch -D "uid=MoneyWizAcctSoftware,ou=Applications,dc=example,dc=com" \
-j pwd-file -Y "dn:uid=AcctAdministrator,ou=Administrators,dc=example,dc=com" \
-b "ou=Accounting,dc=example,dc=com"  "objectclass=*"\
...

検索のベースはACIのターゲットと一致する必要があります。クライアントは自身としてバインドしますが、プロキシ・エントリの権限を付与されます。クライアントには、プロキシ・エントリのパスワードは不要です。

詳細は、第17.5.3.13項「プロキシ設定された認可制御を使用した検索」を参照してください。

22.7 実効権限の表示

ディレクトリのエントリのアクセス制御ポリシーを管理するときには、定義したACIのセキュリティへの影響を把握しておくと役に立ちます。ディレクトリ・サーバーで、既存のACIを評価して、それらのACIによって特定のエントリ上の特定のユーザーに付与された実効権限に関するレポートを生成できます。

22.7.1 実効権限取得制御

ディレクトリ・サーバーは、検索操作に含めることができる実効権限取得制御に応答します。この制御に対するレスポンスは、検索結果のエントリおよび属性に関する実効権限情報を返すことです。この追加情報としては、各エントリとその中の各属性に対する読取り権限および書込み権限などがあります。検索や任意のDNに使用されるバインドDNについて権限をリクエストすることで、管理者がディレクトリ・ユーザーの権限をテストできます。

実効権限の機能は、LDAP制御に依存します。プロキシ・サーバーを通過するときに実効権限を表示するには、プロキシ・チェーン・ポリシー内でこの制御を有効にする必要があります。また、リモート・サーバーとのバインドに使用されるプロキシ・アイデンティティにも、実効権限属性へのアクセスを許可する必要があります。

22.7.2 実効権限取得制御の使用方法

実効権限取得制御の動作は、次の点でインターネット・ドラフトの実効権限取得制御(http://tools.ietf.org/html/draft-ietf-ldapext-acl-model-08)とは異なります:

- 検索結果とともに返されるレスポンス制御はありません。かわりに、権限情報が結果エントリに追加されます。また、権限情報の書式はドラフトと完全に異なっています(この書式については後述します)。

- リクエスト制御はauthzidのみを取ります。

ldapsearchコマンドで実効権限取得制御を指定するには、2つの方法があります:

1. -J "1.3.6.1.4.1.42.2.27.9.5.2"オプションまたはより簡単な-J effectiverightsを使用します。実効権限取得制御のauthzidの値としてNULL値を指定すると、authzidとしてバインド・ユーザーが使用され、現在のldapsearch操作で返される属性およびエントリに対する権限が取得されます。

2. より単純で優先される方法は、-eオプションありまたはなしで-gオプションを使用することです:

- -g "dn: DN"-- 指定されたDNにバインドしているユーザーの実効権限が検索結果に示されます。管理者は、このオプションを使用して他のユーザーの実効権限をチェックできます。オプション-g "dn:"を指定すると、匿名認証に対する実効権限が表示されます。

- -e attributeName1 -e attributeName2 -- 指定された属性に対する実効権限も検索結果に含められます。このオプションは、エントリに関する検索結果に通常は含まれない属性を指定するために使用できます。たとえば、このオプションを使用すると、エントリ内に現在存在しない属性を追加する権限をユーザーが持っているかどうかを調べられます。

注意:

-eオプションは-gオプションとともに使用する必要があります。また、-Jオプションとともには使用できません。

-gオプションを使用する場合は、実効権限取得制御のOIDとともに-Jオプションを使用しないでください。

この2つの方法のいずれかを使用して実効権限取得制御を指定する以外に、表示する情報のタイプも指定する必要があります。すなわち、単純な権限を表示するか、それともそれらの権限がどのように付与または拒否されるかを説明する詳細なログ情報を表示するかを指定します。情報のタイプは、検索結果で返す属性として、aclRightsまたはaclRightsInfoをそれぞれ追加することで特定します。両方の属性をリクエストすると、実効権限の情報をすべて取得できます。ただし、単純な権限情報は詳細なログ情報と重複します。

注意:

aclRights属性とaclRightsInfo属性は、仮想の操作属性として動作します。これらの属性はディレクトリには保存されず、明示的にリクエストしないかぎり返されません。これらの属性は、実効権限取得制御に対するレスポンスとしてディレクトリ・サーバーによって生成されます。そのため、これらの属性はフィルタにもいかなる検索操作にも使用できません。

実効権限機能は、アクセス制御に影響する他のパラメータ(時刻、認証方式、マシン・アドレス、マシン名など)を、検索操作を開始したユーザーから継承します。

次の例は、Carla Fuenteというユーザーがディレクトリ内の自分自身の権限をどのようにして表示するかを示しています。結果表示の中で、1は権限が付与されていることを意味し、0は権限が拒否されたことを意味します。

$ ldapsearch -J effectiverights -h rousseau.example.com -p 1389 \
-D "uid=cfuente,ou=People,dc=example,dc=com" -j pwd-file \
-b "dc=example,dc=com" "(objectclass=*)" aclRights
dn: dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: ou=Groups, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: ou=People, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: cn=Accounting Managers,ou=groups,dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: cn=HR Managers,ou=groups,dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: uid=bjensen,ou=People, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: uid=cfuente, ou=People, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:1,proxy:0

この結果には、Carla Fuenteが少なくとも読取り権限を持つディレクトリ内のエントリが表示されており、彼女が自分自身のエントリを変更できることが示されています。実効権限制御は通常のアクセス権限をバイパスしないため、ユーザー自身が読取り権限を持たないエントリは表示されません。次の例で、ディレクトリ・マネージャは、Carla Fuenteが読取り権限を持たないエントリを確認できます:

$ ldapsearch -h rousseau.example.com -p 1389 -D "cn=Directory Manager" \
-j pwd-file -g "dn: uid=cfuente,ou=People,dc=example,dc=com" \
-b "dc=example,dc=com" "(objectclass=*)" aclRights
dn: dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: ou=Groups, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: cn=Directory Administrators, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:0,write:0,proxy:0
dn: ou=Special Users,dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:0,write:0,proxy:0
dn: ou=People, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: cn=Accounting Managers,ou=groups,dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: cn=HR Managers,ou=groups,dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: uid=bjensen,ou=People, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: uid=cfuente, ou=People, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:1,proxy:0

この出力で、ディレクトリ・マネージャは、Carla Fuenteがディレクトリ・ツリーのSpecial UsersブランチもDirectory Administratorsブランチも表示できないことを確認できます。次の例で、ディレクトリ・マネージャは、Carla Fuenteが自分自身のエントリ内のmail属性とmanager属性を変更できないことを確認できます:

$ ldapsearch -h rousseau.example.com -p 1389 -D "cn=Directory Manager" \
-j pwd-file -g "dn: uid=cfuente,ou=People,dc=example,dc=com" \
-b "dc=example,dc=com" "(uid=cfuente)" aclRights "*"
version: 1
dn: uid=cfuente, ou=People, dc=example,dc=com
aclRights;attributeLevel;mail: search:1,read:1,compare:1,
write:0,selfwrite_add:0,selfwrite_delete:0,proxy:0
mail: cfuente@example.com
aclRights;attributeLevel;uid: search:1,read:1,compare:1,
write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
uid: cfuente
aclRights;attributeLevel;givenName: search:1,read:1,compare:1,
write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
givenName: Carla
aclRights;attributeLevel;sn: search:1,read:1,compare:1,
write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
sn: Fuente
aclRights;attributeLevel;cn: search:1,read:1,compare:1,
write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
cn: Carla Fuente
aclRights;attributeLevel;userPassword: search:0,read:0,
compare:0,write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
userPassword: {SSHA}wnbWHIq2HPiY/5ECwe6MWBGx2KMiZ8JmjF80Ow==
aclRights;attributeLevel;manager: search:1,read:1,compare:1,
write:0,selfwrite_add:0,selfwrite_delete:0,proxy:0
manager: uid=bjensen,ou=People,dc=example,dc=com
aclRights;attributeLevel;telephoneNumber: search:1,read:1,compare:1,
write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
telephoneNumber: (234) 555-7898
aclRights;attributeLevel;objectClass: search:1,read:1,compare:1,
write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0

22.7.3 実効権限の結果の理解

実効権限リクエストに指定したオプションに応じて、次の情報が返されます:

- 権限情報

- write、selfwrite_addおよびselfwrite_delete権限

- ログ情報

22.7.3.1 権限情報

実効権限情報は、次のサブタイプに従って示されます:

aclRights;entrylevel - エントリ・レベルの権限情報を示します

aclRights;attributelevel - 属性レベルの権限情報を示します

aclRightsInfo;entrylevel - エントリ・レベルのログ情報を示します

aclRightsInfo;attributelevel - 属性レベルのログ情報を示します

aclRights文字列の書式は次のとおりです:

aclRights;entryLevel: 権限:値(権限:値)*

および

aclRights;attributeLevel: 権限:値(権限:値)*

エントリ・レベルの権限としては、add、delete、read、writeおよびproxyがあります。それぞれの権限が取り得る値は、0(権限は付与されない)と1(権限が付与される)です。

エントリ・レベルの権限

説明

addおよびdelete

ユーザーがエントリ全体を追加および削除する権限。

read

ユーザーがエントリ内の属性の読取りおよび検索を行う権限。

write

ユーザーがエントリ内の属性値の追加、削除および置換を行う権限。

proxy

ユーザーがエントリの権限でディレクトリにアクセスする権限。

注意:

ACIでこれらの権限を割り当てる方法の詳細は、第8.2項「ACI構文」を参照してください。

属性レベルの権限としては、read、search、compare、write、selfwrite_add、selfwrite_deleteおよびproxyがあります。それぞれの権限が取り得る値は、0(権限は付与されない)と1(権限が付与される)です。write権限の場合は、値?も使用できます。

属性レベルの権限

説明

read

ユーザーがエントリ内の属性値を読み取る権限。

search

ユーザーがエントリ内の属性値を検索する権限。

compare

ユーザーがエントリ内の属性値を自身が指定した値と比較する権限。

write

ユーザーがエントリ内の属性値の追加、削除および置換を行う権限。これは、authorization dn以外のすべての属性に適用されます。

selfwrite_add

ユーザーが属性authorization dnを追加する権限。

selfwrite_delete

ユーザーが属性authorization dnを削除する権限。

proxy

ユーザーがエントリ内の属性の権限でディレクトリにアクセスする権限。

注意:

write、selfwrite_addおよびselfwrite_delete権限は特に複雑です。権限の値が?になっている場合は、ログ情報を確認して、なぜその権限が付与される(またはされない)かを明確にしてください。詳細は、表22-1を参照してください。

aclRightsInfo文字列の書式は次のとおりです:

aclRightsInfo;logs;entryLevel;permission: acl_summary(main):permission-string

および

aclRightsInfo;logs;attributeLevel;permission;attribute: acl_summary(main):permission-string

エントリ・レベルと属性レベルの権限については、前の項で説明しています。

permission-stringには、エントリ・レベルと属性レベルの実効権限に関する詳細情報が含まれています。

22.7.3.2 write、selfwrite_addおよびselfwrite_delete権限

属性レベルのwrite権限の値は、0、1または?です。属性レベルのwrite権限のみが値として?を取ることができますが、この値は通常はACIコンポーネントtargattrfiltersに由来します。add権限とdelete権限の場合、変更できるエントリは、そのエントリ内の属性の値によって決まります。エントリに対する権限の値としては、0または1のみが返されますが、これは値がldapsearch操作で返されるためです。

authorization dn以外のすべての属性値については、write権限の値が1の場合、追加と削除の両方の権限が付与されます。同様に、authorization dn以外のすべての属性値については、write権限の値が0の場合、ldapmodify操作の追加と削除のどちらについても権限を付与されないことを意味します。authorization dnの値に対して有効になっている権限は、selfwrite権限の1つ(つまりselfwrite_addまたはselfwrite_delete)として明示的に返されます。

属性レベルの権限selfwrite_addおよびselfwrite_deleteはACIのコンテキスト内には存在しませんが、ACIのセットは、変更操作の追加の部分または削除の部分についてのみselfwrite権限を付与できます。selfwrite権限の場合、変更の対象となる属性の値はauthorization dnです。write権限については同じ区別は行われません。write権限では変更の対象となる属性の値が未定義だからです。

実効権限がtargattrfilters ACIに依存する場合、値?は権限の詳細を知るためにログ情報を参照する必要があることを意味します。write、selfwrite_addおよびselfwrite_delete権限の間の相互依存性は非常に複雑です。その概要を次の表で説明します。

表22-1 実効権限の相互依存性

write

selfwrite_add

selfwrite_delete

実効権限の説明

0

0

0

この属性のどの値も、追加も削除もできません。

0

0

1

authorization dnの値のみ削除できます。

0

1

0

authorization dnの値のみ追加できます。

0

1

1

authorization dnの値のみ追加または削除できます。

1

0

0

authorization dn以外のすべての値を追加または削除できます。

1

0

1

authorization dnを含めたすべての値を削除でき、authorization dn以外のすべての値を追加できます。

1

1

0

authorization dnを含めたすべての値を追加でき、authorization dn以外のすべての値を削除できます。

1

1

1

この属性のすべての値を追加または削除できます。

?

0

0

authorization dn値の追加または削除はできませんが、その他の値の追加または削除はできる場合があります。write権限に関する詳細は、ログ情報を参照してください。

?

0

1

authorization dnの値を削除できますが、追加はできません。さらに、それ以外の値を追加または削除できる場合があります。write権限に関する詳細は、ログ情報を参照してください。

?

1

0

authorization dnの値を追加できますが、削除はできません。さらに、それ以外の値を追加または削除できる場合があります。write権限に関する詳細は、ログ情報を参照してください。

1

?

1

authorization dnの値を追加および削除できます。さらに、それ以外の値を変更、追加または削除できる場合があります。write権限に関する詳細は、ログ情報を参照してください。

22.7.3.3 ログ情報

実効権限のログ情報は、アクセス制御の問題の理解とデバッグに役立ちます。ログ情報には、acl_summaryと呼ばれるアクセス制御サマリー文が含まれています。このサマリーには、アクセス制御がなぜ許可または拒否されたかが示されます。アクセス制御サマリー文には、次の情報が含まれています:

- アクセスが許可されたか、それとも拒否されたか

- 付与された権限

- 権限のターゲット・エントリ

- ターゲット属性の名前

- リクエストされている権限のサブジェクト

- リクエストの発行元がプロキシかどうか(プロキシの場合はプロキシ認証DNも報告されます)

- アクセスを許可または拒否する理由(次の表で説明しているように、デバッグが目的の場合に重要です)

次の表に、実効権限のログ情報の理由とその説明を示します。

表22-2 実効権限ログ情報の理由とその説明

ログ情報の理由

説明

no reason available

アクセスがなぜ許可または拒否されたかを説明するための理由がありません。

no allow acis

allow ACIが存在しないため、アクセスが拒否されます。

result cached deny

キャッシュされた情報を使用して、アクセス拒否が決定されました。

result cached allow

キャッシュされた情報を使用して、アクセス許可が決定されました。

evaluated allow

ACIが評価されて、アクセス許可が決定されました。ACIの名前がログ情報に含められます。

evaluated deny

ACIが評価されて、アクセス拒否が決定されました。ACIの名前がログ情報に含められます。

no acis matched the resource

リソースまたはターゲットに一致するACIがないため、アクセスが拒否されます。

no acis matched the subject

アクセス制御をリクエストしているサブジェクトに一致するACIがないため、アクセスが拒否されます。

allow anyone aci matched anon user

userdn = "ldap:///anyone"サブジェクトを持つACIが、匿名ユーザーに対してアクセスを許可しました。

no matching anyone aci for anon user

userdn= "ldap:///anyone"サブジェクトを持つACIが見つからなかったため、匿名ユーザーのアクセスが拒否されました。

user root

ユーザーがルートDNであるため、アクセスを許可されます。

注意:

仮想属性については書込み権限は付与されず、関連するログ評価情報も提供されません。仮想属性は更新できないためです。

22.7.4 実効権限取得制御へのアクセス制限

実効権限を表示する操作はそれ自体が、保護と適切な制限を必要とするディレクトリ操作です。

デフォルトのACIでは、実効権限を返すために使用されるaclRightsおよびaclRightsInfo操作属性に対する読取りアクセスは許可されません。ディレクトリ・ユーザーがこの情報にアクセスできるように、これらの属性のために新しいACIを作成してください。

たとえば次のACIは、Directory Administratorsグループのメンバーに実効権限の取得を許可します:

aci: (targetattr = "aclRights||aclRightsInfo")(version 3.0; acl "getEffectiveRights";
allow(all) groupdn = "ldap:///cn=Directory
Administrators,ou=Groups,dc=example,dc=com";)

さらに、実効権限取得制御を使用するためのアクセス権も必要です。

実効権限取得制御にディレクトリ・ユーザーがアクセスできるようにするには、この制御のOID (1.3.6.1.4.1.42.2.27.9.5.2)を使用して新しいACIターゲットを作成します。ACI構文の詳細は、第8.2.2項「ターゲットの定義」を参照してください。

たとえば次のACIは、Directory Administratorsグループのメンバーが実効権限取得制御を使用することを許可します:

aci: (targetcontrol = "1.3.6.1.4.1.42.2.27.9.5.2")(version 3.0;
acl "getEffectiveRights control access";
allow(all) groupdn = "ldap:///cn=Directory
Administrators,ou=Groups,dc=example,dc=com";)

23 管理ユーザーの管理

Oracle Unified Directoryは、ルート・ユーザー、グローバル管理者およびサーバーの管理者を構成できる柔軟な特権サブシステムを備えています。複数のルート・ユーザーを構成して、管理者ごとに異なるroot特権を割り当てることができます。管理ドメインについては、ネットワーク内またはレプリケート環境内の管理ドメインを管理する複数のドメイン管理者を構成することもできます。

この項のトピックでは、複数のルート・ユーザーおよび特権サブシステムの管理について説明します。また、サーバーを安全に管理するために必要な様々なユーザー・アカウントの構成およびメンテナンス手順についても説明します。

ここで概説する手順を開始する前に、サーバーに関する次のガイドラインについて決定しておきます:

- ルート・ユーザー数、各ルート・ユーザーの特権およびリソース制限(制限が必要な場合)。

- 管理者数、各管理者の特権およびリソース制限(制限が必要な場合)。

- システムのユーザー・アカウントに関するガイドライン。

- サーバーおよび特定のユーザー・グループのパスワード・ポリシー。

この章では、次のトピックを取り扱います:

- 第23.1項「複数のルート・ユーザーの使用」

- 第23.2項「ルート・ユーザーと特権サブシステム」

- 第23.3項「dsconfigによるルート・ユーザーの管理」

- 第23.4項「ルート・ユーザーのリソース制限の設定」

- 第23.5項「管理者の管理」

- 第23.6項「グローバル管理者の管理」

23.1 複数のルート・ユーザーの使用

Oracle Unified Directoryは、"cn=Directory Manager"というデフォルトのルートDN(ルート・ユーザー)を1つ備えています。このデフォルトのルートDNは、サーバー内のすべてのデータに対する完全な読取りおよび書込みアクセスが可能な特殊特権を割り当てられたユーザー・エントリです。ルートDNは、Unixのルート・ユーザーまたはスーパーユーザーに相当し、アクセス制御を回避してサーバー上でタスクを実行できます。ルート・ユーザーは、サーバーの"cn=Root DNs,cn=config"ブランチの下にあるcn=Directory Manager,cn=Root DNs,cn=configで定義されます。

サーバーでは、複数のルート・ユーザー(それぞれがそのサーバー上に固有のエントリと固有の資格証明セットを保有)をサポートしています。そのため、特定のタスクについてのみルート・アクセス権を必要とし、ルート・ユーザーの完全な特権セットは必要としない可能性があるユーザーに対しても特権を割り当てることが可能です。各エントリでは、GSSAPI SASLメカニズムなどの厳密な認証やパスワード・ポリシーの割当またはリソース制限の追加(スキーマでこの制限が可能な場合)を行うことができ、ルート・ユーザーごとにまったく異なる構成を設定できます。

ルート・ユーザーは、次の面で通常のユーザー・エントリとは異なります:

- 構成。サーバー構成(cn=config)内に存在することが可能なユーザー・アカウントはルート・ユーザーのみです。

- 特権の継承。ルート・ユーザーは、デフォルトのルート・ユーザー特権セットを自動的に継承します。通常のユーザーは、明示的に付与されないかぎり、どのような特権も自動的には受け取りません。特権は、実際、仮想またはこの両方のroot-privilege-name属性を使用して、エントリ内で付与できます。

- ロックダウン・モード。サーバーにロックダウン・モードを開始または終了させることができるユーザーは、ルート・ユーザーのみです。これらの操作はループ・インタフェースを介してのみ可能です。

特権サブシステムでは、複数のルート・ユーザーの構成をサポートしています。

23.2 ルート・ユーザーと特権サブシステム

特権サブシステムは、ルート・ユーザーの特定のアクセス特権セットのみを必要とする可能性があるユーザーに対して、特権を絞り込んで割り当てることを可能にします。ルート・ユーザーには、"cn=Root DNs,cn=config"サブツリー内のdefault-root-privilege-name属性で定義されている特権セットが自動的に付与されます。

特権サブシステムはアクセス制御サブシステムからは独立していますが、一部の操作にはアクセス制御が適用されることがあります。

ルート・ユーザーには、次の特権セットが自動的に割り当てられます。

特権

説明

bypass-acl

アクセス制御評価の回避をユーザーに許可します。

modify-acl

サーバーに定義されているアクセス制御命令の変更をユーザーに許可します。

config-read

サーバー構成への読取りアクセスをユーザーに許可します。

config-write

サーバー構成への書込みアクセスをユーザーに許可します。

ldif-import

LDIFインポート・タスクのリクエストをユーザーに許可します。

ldif-export

LDIFエクスポート・タスクのリクエストをユーザーに許可します。

backend-backup

バックエンドのバックアップ・タスクのリクエストをユーザーに許可します。

backend-restore

バックエンドのリストア・タスクのリクエストをユーザーに許可します。

server-shutdown

サーバー停止タスクのリクエストをユーザーに許可します。

server-restart

サーバー再起動タスクのリクエストをユーザーに許可します。

disconnect-client

任意のクライアント接続の終了をユーザーに許可します。

cancel-request

任意のクライアント・リクエストの取消をユーザーに許可します。

unindexed-search

索引なし検索操作のリクエストをユーザーに許可します。

password-reset

ユーザー・パスワードのリセットをユーザーに許可します。

update-schema

サーバー・スキーマの更新をユーザーに許可します。

privilege-change

ユーザーに割り当てられた特権セットの変更またはデフォルトのroot特権セットの変更をユーザーに許可します。

ルート・ユーザーには、次の特権を割り当てることができます。

特権

説明

jmx-read

JMX属性値の読取りをユーザーに許可します。

jmx-write

JMX属性値の更新をユーザーに許可します。

jmx-notify

JMX通知のサブスクライブをユーザーに許可します。

proxied-auth

プロキシ設定された認可制御の使用または代替SASL認証IDのリクエストをユーザーに許可します。

23.3 dsconfigによるルート・ユーザーの管理

ルート・ユーザーの管理にはdsconfigコマンドを使用します。詳細は、第14.1項「dsconfigを使用したサーバー構成の管理」を参照してください。

23.3.1 デフォルトのルート・ユーザー特権を表示するには

デフォルトのルート・ユーザーはいくつかの特権を保有しています。これらの特権はdefault-root-privilege-nameプロパティの値として格納されています。

1. デフォルトのルート・ユーザー特権を表示するには、次のdsconfigコマンドを実行します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
get-root-dn-prop

Property                    : Value(s)
----------------------------:--------------------------------------------------
default-root-privilege-name : backend-backup, backend-restore, bypass-acl,
: cancel-request, config-read, config-write,
: disconnect-client, ldif-export, ldif-import,
: modify-acl, password-reset, privilege-change,
: server-restart, server-shutdown,
: unindexed-search, update-schema

23.3.2 デフォルトのルート・ユーザー特権を編集するには

ルート・ユーザー特権の最も容易な管理方法は、対話モードでdsconfigを使用することです。対話モードでは画面の指示に従ってルート・ユーザー構成を変更できるため、この手順はここでは取り上げません。

デフォルトのルート・ユーザーの特権を追加または削除するには、default-root-privilege-nameプロパティの値を追加または削除します。このプロパティには次の値を保持できます:

- backend-backup

- backend-restore

- bypass-acl

- cancel-request

- config-read

- config-write

- disconnect-client

- jmx-notify

- jmx-read

- jmx-write

- ldif-export

- ldif-import

- modify-acl

- password-reset

- privilege-change

- proxied-auth

- server-restart

- server-shutdown

- unindexed-search

- update-schema

次の例では、dsconfigを非対話モードで使用して、デフォルトのルート・ユーザーにjmx-notify特権を追加します。

1. dsconfigコマンドを次のように実行します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
set-root-dn-prop --add default-root-privilege-name:jmx-notify

23.3.3 ルート・ユーザーを作成するには

ルート・ユーザーはcn=Root DNs,cn=configエントリの下に格納されます。新しいルート・ユーザーを作成するには、LDIFでエントリを作成し、ldapmodifyコマンドを使用してそのエントリを追加します。cn=config接尾辞は管理コネクタからのみ使用可能なため、SSLを使用して管理ポートからアクセスする必要がある点に注意してください。

ルート・ユーザーは、サーバーのデフォルトのルート・ユーザー特権セットを自動的に継承します。特定のルート・ユーザーの特権の追加または削除の詳細は、「ルート・ユーザーの特権を変更するには」を参照してください。

1. cn=Root DNs,cn=configエントリの下にルート・ユーザー・エントリを作成します。
次のLDIFファイルは、Administration Managerという新しいルート・ユーザー名を示しています。このエントリはadd-root-user.ldifという名前のファイルに保存されています。

dn: cn=MyRootUser,cn=Root DNs,cn=config
objectClass: inetOrgPerson
objectClass: person
objectClass: top
objectClass: ds-cfg-root-dn-user
objectClass: organizationalPerson
userPassword: password
cn: MyRootUser
sn: MyRootUser
ds-cfg-alternate-bind-dn: cn=MyRootUser
givenName: Directory

2. ldapmodifyコマンドを使用して、エントリを追加します。

$ ldapmodify -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file \
--useSSL --defaultAdd --filename "add-root-user.ldif"
Processing ADD request for cn=MyRootUser,cn=Root DNs,cn=config
ADD operation successful for DN cn=MyRootUser,cn=Root DNs,cn=config

3. サーバーに定義されているすべてのルート・ユーザーを表示するには、ldapsearchコマンドを使用します。

$ ldapsearch -p 4444 -b "cn=root DNs,cn=config" -D "cn=directory manager" -j pwd-file \
--useSSL "objectclass=*" dn
dn: cn=Root DNs,cn=config

dn: cn=MyRootUser,cn=Root DNs,cn=config

dn: cn=Directory Manager,cn=Root DNs,cn=config

23.3.4 ルート・ユーザーのパスワードを変更するには

1. セキュア・ファイルにパスワードを作成します。

2. ldappasswordmodifyを使用して、パスワードを変更します。

$ ldappasswordmodify -h localhost -p 4444 -D "cn=MyRootUser" -j pwd-file \
--useSSL --newPasswordFile rootuser_pwd.txt
The LDAP password modify operation was successful

23.3.5 ルート・ユーザーの特権を変更するには

特定のルート・ユーザーに対して異なる特権セットを割り当てるには、そのルート・ユーザーのエントリにds-privilege-name属性を追加します。

次の例では、ルート・ユーザー"cn=MyRootUser,cn=Root DNs,cn=config"に、プロキシ認可を使用する権限を割り当てます。この例では、ユーザー特権の変更権限と構成へのアクセス権限を削除します。特権の前のマイナス記号は、その特権が追加されるのではなく、削除されることを表します。

1. ルート・ユーザーのエントリに次のLDIF文を適用します:

dn: cn=MyRootUser,cn=Root DNs,cn=config
changetype: modify
add: ds-privilege-name
ds-privilege-name: proxied-auth
ds-privilege-name: -config-read
ds-privilege-name: -config-write

この例のルート・ユーザー"cn=MyRootUser,cn=Root DNs,cn=config"は、ルート・ユーザーに自動的に付与される特権のうち、config-read特権とconfig-write特権を除くすべての特権を継承します。また、このユーザーにはproxied-auth特権も付与されます。

23.4 ルート・ユーザーのリソース制限の設定

サーバーにバインドされているクライアント・アプリケーションで操作属性を使用することによって、検索操作に対するサーバーのリソース制限を設定できます。使用可能なリソース制限は次のとおりです:

- 検索制限。単一の検索操作中に調べることができる最大エントリ数を指定します。ds-rlim-lookthrough-limit操作属性を使用します。

- サイズ制限。単一の検索操作で返すことができる最大エントリ数を指定します。ds-rlim-size-limit操作属性を使用します。

- 時間制限。検索操作の処理に使用できる最大時間を秒単位で指定します。ds-rlim-time-limit操作属性を使用します。

次のLDIF update文では、前の項で作成した新しいルート・ユーザーに対してリソース制限を設定します。この文をルート・ユーザーのエントリに適用します。

dn: cn=MyRootUser,cn=Root DNs,cn=config
changetype: modify
add: ds-rlim-lookthrough-limit
ds-rlim-lookthrough-limit: 1000
-
add: ds-rlim-size-limit
ds-rlim-size-limit: 500
-
add: ds-rlim-time-limit
ds-rlim-time-limit: 300

特定のリソース制限を無制限に設定するには、対応する属性の値を0(ゼロ)に設定します。

23.5 管理者の管理

一般に、管理者はほとんどのユーザーよりも広範な権限を保有します。多数の管理者を作成し、それぞれの管理者に異なるアクセス制御やリソース制限を割り当てることができます。

23.5.1 新しい管理者を作成するには

1. import-ldifを使用して、管理者データをインポートします。
この例で追加する管理者はuid=Admin.Labを持っています。

1. または、既存のユーザーを使用することもできます。

2. cn=Administratorsを使用して、管理者のグループを作成します。
管理者のグループには少数のユーザーしか含めないため、静的グループを作成できます。詳細は、「静的グループの定義」を参照してください。

dn: cn=Administrators,ou=People,dc=example,dc=com
objectClass: top
objectClass: groupOfNames
member: uid=Admin.Lab,ou=People,dc=example,dc=com
cn: Administrator

3. ldapmodifyコマンドを使用して、管理者の特権を設定します。
たとえば、次のコマンドでは、バックエンドでバックアップとリストアを実行する権限が管理者に付与されます。

ldapmodify -h localhost -p 1389 -j pwd-file -D "cn=directory manager"
dn: uid=Admin.Lab,ou=People,dc=example,dc=com
changetype: modify
add: ds-privilege-name
ds-privilege-name: backend-backup
ds-privilege-name: backend-restore

4. 必要に応じて、リソース制限を設定します。
手順は、ルート・ユーザーに対してリソース制限を設定する場合と同様です。「ルート・ユーザーのリソース制限の設定」を参照してください。

23.5.2 ルート・ユーザーの特権を持つ管理者を作成するには

管理者またはユーザーにルート・ユーザーの特権を割り当てることができます。

1. 管理者を作成するか、既存のユーザーを使用します。
「新しい管理者を作成するには」を参照してください。

2. ldapmodifyコマンドを使用して、特権を変更します。
たとえば次のコマンドでは、Admin.Labという名前の管理者の特権を変更して、ルート・ユーザーと同じデフォルトの特権を割り当てます。

ldapmodify -h localhost -p 1389 -j pwd-file -D "cn=directory manager"
dn: uid=Admin.Lab,cn=Administrators,ou=People,dc=example,dc=com
changetype: modify
add: ds-privilege-name
ds-privilege-name: bypass-acl
ds-privilege-name: modify-acl
ds-privilege-name: config-read
ds-privilege-name: config-write
ds-privilege-name: ldif-import
ds-privilege-name: ldif-export
ds-privilege-name: backend-backup
ds-privilege-name: backend-restore
ds-privilege-name: server-shutdown
ds-privilege-name: server-restart
ds-privilege-name: disconnect-client
ds-privilege-name: cancel-request
ds-privilege-name: password-reset
ds-privilege-name: update-schema
ds-privilege-name: privilege-change
ds-privilege-name: unindexed-search

注意:

アクセス制御に関する特権bypass-aclとmodify-aclは、限られた数のユーザーにのみ割り当てるようにします。アクセス制御を回避または変更する権限を経験の浅いユーザーに割り当てると、危険な場合があります。

23.6 グローバル管理者の管理

グラフィカル・インストーラまたはdsreplicationコマンドを使用したレプリケーション・サーバーの設定時には、グローバル管理者のユーザー名とパスワードを設定するように求められます。グローバル管理者は、レプリケート環境内の管理サーバーの管理とメンテナンスの責任者です。

グローバル管理者はcn=Administrators,cn=admin dataサブツリー内に存在します。グローバル管理者のエントリを表示するには、次のldapsearchコマンドを実行します:

$ ldapsearch -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file \
--useSSL -b "cn=Administrators,cn=admin data" -s sub "(objectclass=*)"
dn: cn=Administrators,cn=admin data
objectClass: top
objectClass: groupofurls
description: Group of identities which have full access.
cn: Administrators
memberURL: ldap:///cn=Administrators,cn=admin data??one?(objectclass=*)
dn: cn=admin,cn=Administrators,cn=admin data
objectClass: person
objectClass: top
userPassword: {SSHA}+ed1wbhcWjxtv2zJ6OHEA2TuE9n1qIJGnuR94w==
description: The Administrator that can manage all the OUD instances.
cn: admin
sn: admin

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

パスワード・ポリシーは、システムでのパスワードの使用を制御するルール・セットであり、ディレクトリに対して採用するあらゆるセキュリティ戦略に不可欠のコンポーネントです。

Oracle Unified Directoryには、一般ユーザーのパスワード・ポリシーとデフォルトのルート・ユーザーのパスワード・ポリシーに対応したデフォルトのパスワード・ポリシーが含まれています。これらのデフォルトのパスワード・ポリシーは、ディレクトリ・サーバーの構成内にあり、変更可能です。

Oracle Unified Directoryでは複数のパスワード・ポリシーをサポートしているため、デフォルトのパスワード・ポリシーを使用するほかに、特定のユーザー・セットに対象を特化したパスワード・ポリシーを作成および構成できます。カスタマイズしたパスワード・ポリシーをLDAPサブエントリとして定義し、ユーザー・データとともに格納できます。それにより、カスタマイズしたポリシーをサーバー間でレプリケートできるようになります。

この章では、パスワード・ポリシーのコンポーネントについて概説し、パスワード・ポリシーの構成および管理方法を説明します。この章の内容は次のとおりです:

- 第24.1項「パスワード・ポリシーのコンポーネント」

- 第24.2項「デフォルト・パスワード・ポリシー」

- 第24.3項「レプリケート環境でのパスワード・ポリシー」

- 第24.4項「コマンドラインを使用したパスワード・ポリシーの構成」

- 第24.5項「Oracle Directory Services Managerを使用したパスワード・ポリシーの構成」

- 第24.6項「パスワード・バリデータ」

- 第24.7項「パスワード・ジェネレータ」

24.1 パスワード・ポリシーのコンポーネント

すべてのパスワード・ポリシーには、次の構成可能なコンポーネントが含まれます:

- パスワードの複雑性要件。パスワードの構成と必要な文字数を指定します。通常、パスワードで使用する最小文字数、使用可能な文字のタイプおよび必要な数字の数を指定します。たとえば、多くの機関が、最小文字数を7文字または8文字とし、数字と特殊文字が1文字ずつ含まれていることと、大文字と小文字の両方が含まれていることを要件としています。

- パスワード履歴。以前のパスワードを再利用できるようになるまでに、ユーザーが使用する必要がある一意のパスワード数を決定します。

- 最大パスワード経過時間。パスワードの変更をユーザーに許可または要求するまでに、パスワードをどのくらいの期間使用できるかを決定します。

- 最小パスワード経過期間。新しいパスワードをユーザーが変更できるようになるまでに、そのパスワードをユーザーがどのくらいの期間維持する必要があるかを決定します。

- 初回ログイン。システムへのユーザーの初回ログイン時に、ユーザーにパスワードの変更を要求するかどうかを決定します。

- パスワード変更の認可。ユーザーがパスワードを変更するための条件を示します。たとえば、ユーザーがパスワードを変更しようとしたときに、新しいパスワードの入力前に現在のパスワードを入力してアイデンティティを認証することをユーザーに要求するようにサーバーを構成できます。

- アカウント・ロックアウト。アカウントを無効にしてユーザーがアクセスできないようにするときの条件を決定します。たとえば、ユーザーが3回の試行後に適切な認証に失敗した場合、4回目の試行でアカウントをロックするようにサーバーを構成できます。ユーザーのアカウントのロックは、管理者が手動で解除する必要があります。

- パスワード記憶スキーム。パスワードの暗号化方法とサーバーでの記憶方法を決定します。サーバー上の特定のアカウントの記憶スキームを構成できます。たとえば、ルート・ユーザーのパスワードは、このアカウントおよびその特権が持つ重要性から、強力な暗号化を必要とします。そのため、ルート・ユーザーのパスワードの記憶には、SSHA-512記憶スキームを使用するように構成できます。

パスワードの検証は、パスワード・ポリシーで直接的には処理されず、DNがパスワード・ポリシー内に存在する特定のパスワード・バリデータ・エントリによって処理されます。詳細は、第24.6項「パスワード・バリデータ」を参照してください。

24.2 デフォルト・パスワード・ポリシー

デフォルト・パスワード・ポリシーには、構成可能な多数のプロパティが含まれています。これらを次の表に示します。

プロパティ

説明

account-status-notification-handler

パスワード・ポリシー処理の過程でイベントが発生すると、アカウント・ステータス通知ハンドラを使用してメッセージが送信されます。このプロパティでは、このパスワード・ポリシーに使用するアカウント・ステータス通知ハンドラのDNを指定します。

allow-expired-password-changes

使用はお薦めしません。ユーザーのパスワードの有効期限が切れた後に、そのユーザーにパスワードの変更を許可するかどうかを示します。ユーザーはリクエストを匿名で発行し、現在のパスワードをリクエストに含める必要があります。このプロパティを有効化すると、この機能によってパスワード変更拡張操作が使用されます。この操作はデフォルトで初期構成時に有効化されます。

allow-user-password-changes

ユーザーが自分のパスワードを変更するためのアクセス制御権を保有している場合に、そのユーザーにこの変更を許可するかどうかを示します。

default-password-storage-scheme

このパスワード・ポリシーでクリア・テキスト・パスワードのエンコードに使用するパスワード記憶スキームのDNを指定します。

deprecated-password-storage-scheme

このパスワード・ポリシーで非推奨と見なすパスワード記憶スキームのDNを指定します。このパスワード・ポリシーを持つユーザーがサーバーに対する認証を行ったときに、そのユーザーのパスワードが非推奨のスキームでエンコードされている場合、その値は削除され、デフォルトのパスワード記憶スキームを使用してエンコードされた値に置き換えられます。

expire-password-without-warning

パスワード有効期限切れ警告がユーザーにまだ表示されていない場合でも、そのユーザーのパスワードを有効期限切れにすることが可能かどうかを示します。これをfalseに設定すると、パスワードの有効期限時間が過ぎた後でも、常に、警告メッセージが少なくとも1回、確実にユーザーに表示されます。有効期限時間は、現在の時間に警告間隔(ds-cfg-password-expiration-warning-interval)を加えた時間にリセットされます。

force-change-on-add

アカウントの初回使用時にパスワードの変更をユーザーに要求し、その他の操作はいずれもパスワードを変更しないと実行できないようにするかどうかを示します。

force-change-on-reset

管理パスワードのリセット後にパスワードを変更するようにユーザーに要求し、他の操作はいずれもパスワードを変更しないと実行できないようにするかどうかを示します。

grace-login-count

ユーザーに許可する最大猶予ログイン数を指定します。猶予ログインによって、ユーザーは、パスワードの有効期限が切れた後でもサーバーに対して認証を行うことができますが、パスワードを変更するまでは他の操作はいずれも実行できません。

idle-lockout-interval

ユーザー・アカウントがアイドル状態を維持できる(つまり、ディレクトリに対する認証を行わないでいられる)最大時間を指定します。この時間が経過すると、アカウントはサーバーによってロックされます。このアクションは、last login timeのトラッキングが有効化されており、idle lockout intervalがゼロ以外の値に設定されている場合に適用されます。

last-login-time-attribute

ユーザーの最終ログイン時刻の保持に使用する、ユーザーのエントリ内の属性名を指定します。これを指定する場合、指定する属性は、サーバー・スキーマに操作属性として定義されているか、ユーザーのエントリの少なくとも1つのオブジェクト・クラスで許可されている必要があります。この目的で、ds-pwp-last-login操作属性が定義されています。最終ログイン時刻のトラッキングは、パスワード・ポリシーに対してds-cfg-last-login-time-attribute属性とds-cfg-last-login-time-format属性が構成されている場合にのみ有効化されます。

last-login-time-format

最終ログイン時刻値の生成に使用する書式文字列を指定します。これには、java.text.SimpleDateFormatクラスとともに使用できる任意の有効な書式文字列を使用できます。パフォーマンス上の理由から、最終ログインの日付(書式: yyyyMMdd)のみを格納し、時間は格納しないようにこの属性を構成するほうが望ましい場合もあります。この場合、更新は1日に1回行えばよく、ユーザーの認証時に毎回行う必要はなくなります。最終ログイン時刻のトラッキングは、パスワード・ポリシーに対してds-cfg-last-login-time-attribute属性とds-cfg-last-login-time-format属性が構成されている場合にのみ有効化されます。

lockout-duration

認証に失敗したユーザー・アカウントをロック状態にする時間を指定します。この時間が経過すると、アカウントのロックは自動的に解除されます。値0 secondsは、ロックされたアカウントのロック解除は自動的には行われず、管理者がリセットする必要があることを表します。

lockout-failure-count

認証に何回失敗したら、ユーザー・アカウントを一時的または永久的にロックするかを指定します。値ゼロは、自動ロックアウトを有効化しないことを表します。

lockout-failure-expiration-interval

ロックアウト対象の失敗として前回の認証試行の失敗を加算する場合の最大時間を指定します。認証に成功すると、以前に失敗したすべての試行のレコードが常にクリアされます。値0 secondsは、失敗した試行が自動的には有効期限切れにならないことを表します。

max-password-age

ユーザーが同じパスワードを維持できる最大時間を指定します。この時間が経過すると、ユーザーは新しいパスワードを選択する必要があります。これは、多くの場合パスワードが有効期限切れになるまでの間隔と呼ばれます。値0 secondsは、パスワードが有効期限切れにならないことを表します。ds-cfg-expire-passwords-without-warning属性をfalseに設定すると、有効なパスワード有効期限切れ時間が再計算され、最初の警告を受け取った時間に警告間隔(ds-cfg-password-expiration-warning-interval)を加えた時間に設定されます。この動作によって、常に、完全に構成されたパスワード変更警告間隔がユーザーに確実に適用されるようになります。

max-password-reset-age

ユーザーのパスワードが管理者によってリセットされた後に、そのユーザーによるパスワードの変更が可能な最大時間を指定します。この時間が経過すると、そのユーザーはロックアウトされます。これは、ds-cfg-force-change-on-reset属性がtrueに設定されている場合にのみ適用されます。値0 secondsは、管理者によるリセット後にユーザーがパスワードを変更する必要がある時間に制限がないことを表します。

min-password-age

ユーザーがパスワード値を維持する必要がある最小時間を指定します。この時間が経過すると、ユーザーはパスワード値を再び変更できるようになります。ゼロ以外の値を指定することによって、ユーザーが、前のパスワードを履歴からフラッシュして再利用可能にするために、パスワードの変更を繰り返すことを確実に防止できます。

password-attribute

ユーザーのエンコードされたパスワードを保持する、ユーザーのエントリ内の属性を指定します。指定する属性は、サーバーのスキーマで定義されている必要があり、またユーザー・パスワード構文または認証パスワード構文のどちらかを持っている必要があります。通常、ユーザー・パスワード構文(OID: 1.3.6.1.4.1.26027.1.3.1)の場合は「userPassword」と入力します。また、認証パスワード構文(OID: 1.3.6.1.4.1.4203.1.1.2)用に値authPasswordを指定することもできます(サーバーでこの構文がサポートされている場合)。

password-change-requires-current-password

ユーザーが新しいパスワードを設定するときに、現在のパスワードを入力する必要があるかどうかを示します。これをtrueに設定した場合、ユーザーは既存のパスワードの変更時に現在のパスワードを入力する必要があります。この変更は、パスワード変更拡張操作を使用するか、標準のLDAP変更操作を使用する(既存のパスワード値を削除し、同じ変更操作で新しいパスワード値を追加する)ことによって実行できます。

password-expiration-warning-interval

パスワードの有効期限が間もなく切れることを示すユーザーへの通知を開始する、パスワード有効期限前の時間を指定します。ds-cfg-expire-passwords-without-warning属性がfalseに設定されている場合は、ゼロ以外の値をここで指定する必要があります。

password-generator

このパスワード・ポリシーとともに使用するパスワード・ジェネレータのDNを指定します。パスワード・ジェネレータはパスワード変更拡張操作とともに使用され、このジェネレータによって、クライアントからのリクエストに新しいパスワードが含まれていない場合に新しいパスワードが生成されます。パスワード・ジェネレータのDNを指定しないと、パスワード変更拡張操作でユーザーのパスワードの自動生成は行われません。

password-history-count

パスワード履歴に保持するパスワード値の最大数を指定します。ユーザーのパスワードが変更されるたびに、サーバーは、提示された新しいパスワードを、現在のパスワードおよび履歴に格納されているすべてのパスワードと突き合せてチェックします。一致が検出された場合、ユーザーは新しいパスワードを使用できません。値ゼロは、パスワード履歴を保持しないことを表すか(パスワード履歴期間の値が0 secondsに設定されている場合)、パスワード履歴リストを完全に期間ベースとし、最大数を適用しないことを表します(パスワード履歴期間の値が0 seconds以外の値に設定されている場合)。構成されている履歴数を管理者が減らした場合(ただし、ゼロ以外の値)、パスワード履歴状態情報を含んでいる各ユーザー・エントリは、そのユーザーのパスワード変更が処理されたときに初めてこの操作の影響を受けます。履歴状態の超過値がある場合は、この時点でパージされます。履歴数がゼロに減らされ、かつパスワード履歴期間が0 secondsに設定されている場合、この機能を再び有効化すると、ユーザーのエントリのあらゆる状態情報が保持されます。

password-history-duration

以前に使用されたパスワードをユーザーのパスワード履歴内に有効として保持する最大時間を指定します。ユーザーのパスワードが変更されるたびに、サーバーは、提示された新しいパスワードを、現在のパスワードおよび履歴に格納されているすべてのパスワードと突き合せてチェックします。一致が検出された場合、ユーザーは新しいパスワードを使用できません。値0 secondsは、パスワード履歴を保持しないことを表すか(パスワード履歴の期間の値が0に設定されている場合)、パスワード履歴リストを完全に期間ベースとし、最大数を適用しないことを表します(パスワード履歴の期間の値が0以外の値に設定されている場合)。

password-validator

このパスワード・ポリシーとともに使用するパスワード・バリデータのDNを指定します。パスワード・バリデータはユーザーが新しいパスワードを指定しようとするたびに起動され、新しいパスワードが許容範囲内かどうかがこのバリデータによって判定されます。

previous-last-login-time-format

古い最終ログイン時刻値に対して過去に使用された書式文字列を指定します。この値は、最終ログイン時刻機能が有効化されており、その値の格納書式が変更された場合以外は不要です。

require-change-by-time

このパスワード・ポリシーを持つすべてのユーザーがパスワードを変更する必要がある時点を指定します。このオプションは、パスワード有効期限とは別に作用します(つまり、パスワード有効期限が無効化されている場合でも、いずれかの時点ですべてのユーザーにパスワードの変更を強制します)。

require-secure-authentication

このパスワード・ポリシーを持つユーザーが、SSLのようなセキュア通信メカニズム、またはパスワードをプクリア・テキストで公開しないDIGEST-MD5、EXTERNAL、GSSAPIなどのセキュアSASLメカニズムを使用して、安全に認証を行う必要があるかどうかを示します。

require-secure-password-changes

このパスワード・ポリシーを持つユーザーが、安全な方法で(SSLのようなセキュア通信チャネルを使用するなど)パスワード変更を行う必要があるかどうか示します。

24.2.1 デフォルト・パスワード・ポリシーのプロパティを表示するには

デフォルト・パスワード・ポリシーのプロパティは、dsconfigコマンドまたはODSMを使用して表示できます。

dsconfigを使用してプロパティを表示するには、次のコマンドを実行します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
get-password-policy-prop --policy-name "Default Password Policy"

Property                                  : Value(s)
------------------------------------------:--------------------------
account-status-notification-handler       : -
allow-expired-password-changes            : false
allow-user-password-changes               : true
default-password-storage-scheme           : Salted SHA-1
deprecated-password-storage-scheme        : -
expire-passwords-without-warning          : false
force-change-on-add                       : false
force-change-on-reset                     : false
grace-login-count                         : 0
idle-lockout-interval                     : 0 s
last-login-time-attribute                 : -
last-login-time-format                    : -
lockout-duration                          : 0 s
lockout-failure-count                     : 0
lockout-failure-expiration-interval       : 0 s
max-password-age                          : 0 s
max-password-reset-age                    : 0 s
min-password-age                          : 0 s
password-attribute                        : userpassword
password-change-requires-current-password : false
password-expiration-warning-interval      : 5 d
password-generator                        : Random Password Generator
password-history-count                    : 0
password-history-duration                 : 0 s
password-validator                        : -
previous-last-login-time-format           : -
require-change-by-time                    : -
require-secure-authentication             : false
require-secure-password-changes           : false

拡張プロパティを表示するには、--advancedオプションを次のように含めます:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
get-password-policy-prop --policy-name "Default Password Policy" --advanced

ODSMを使用してデフォルト・パスワード・ポリシーのプロパティを表示する手順は次のとおりです:

- 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

- 「セキュリティ」タブを選択します。

- 「パスワード・ポリシー」要素を開きます。

- 「デフォルト・パスワード・ポリシー」を選択します。

パスワード・ポリシーのプロパティとその値が右側のペインに表示されます。

24.2.2 デフォルト・パスワード・ポリシーを変更するには

デフォルト・パスワード・ポリシーのプロパティは、dsconfigコマンドまたはODSMを使用して変更できます。

dsconfigを使用してプロパティを変更するには、次のコマンドを実行します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
set-password-policy-prop --policy-name "Default Password Policy" \
--set allow-expired-password-changes:true

ODSMを使用してデフォルト・パスワード・ポリシーのプロパティを変更する手順は次のとおりです:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「セキュリティ」タブを選択します。

3. 「パスワード・ポリシー」要素を開きます。

4. 「デフォルト・パスワード・ポリシー」を選択します。
パスワード・ポリシーのプロパティとその値が右側のペインに表示されます。

5. 必要なプロパティを変更して「適用」をクリックします。

拡張プロパティの表示と変更は、ODSMでは行えません。

24.3 レプリケート環境でのパスワード・ポリシー

ディレクトリ・サーバー構成内(cn=configの下)に存在するパスワード・ポリシーは、レプリケートされません。構成情報全般はレプリケートされず、各ディレクトリ・サーバー・インスタンス固有のものです。デフォルト・パスワード・ポリシーを変更する場合は、レプリケート・トポロジ内の各ディレクトリ・サーバー・インスタンスで同じ変更を行う必要があります。同様に、cn=configの下にある特殊パスワード・ポリシーも、他のディレクトリ・サーバーにはコピーされません。

サブエントリとして(つまり、データの一部として)作成されたパスワード・ポリシーは、レプリケートされます。サブエントリとしてのパスワード・ポリシーの作成の詳細は、第24.4.7項「LDAPサブエントリとしてパスワード・ポリシーを定義するには」を参照してください。

レプリケート環境でのパスワード・ポリシーの使用に関するその他の考慮事項を次に示します:

- ディレクトリ・サーバーは、ユーザー・エントリに格納されているすべてのパスワード情報(現在のパスワード、パスワード履歴、パスワード有効期限)をレプリケートします。

- ユーザーが自分のパスワードを変更した場合、すべてのレプリカでパスワードが新しいパスワードに更新されるまでにしばらく時間がかかる場合があります。

- 1人のユーザーに対してパスワード有効期限の警告が複数(レプリケートされた各サーバーから1つずつ)表示されることがあります。

24.4 コマンドラインを使用したパスワード・ポリシーの構成

パスワード・ポリシーを最も容易に構成する方法は、dsconfigコマンドを使用して、既存のパスワード・ポリシーの管理とパスワード・ポリシー・プロパティの変更を行うことです。

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

- 第24.4.1項「デフォルト・パスワード・ポリシーの構成」

- 第24.4.2項「新しいパスワード・ポリシーを作成するには」

- 第24.4.3項「初回ログイン・パスワード・ポリシーを作成するには」

- 第24.4.4項「パスワード・ポリシーを個別アカウントに割り当てるには」

- 第24.4.5項「パスワード・ポリシーの変更を防止するには」

- 第24.4.6項「パスワード・ポリシーをユーザーのグループに割り当てるには」

- 第24.4.7項「LDAPサブエントリとしてパスワード・ポリシーを定義するには」

- 第24.4.8項「パスワード・ポリシーを削除するには」

24.4.1 デフォルト・パスワード・ポリシーの構成

次の例では、dsconfigを使用して、デフォルト・パスワード・ポリシーの様々なプロパティを変更します。

例24-1 アカウント・ロックアウトの構成

次のアカウント・ロックアウト機能を構成できます:

- ロックアウト対象の失敗数。認証に何回失敗したら、ユーザー・アカウントをロックするかを指定します。

- ロックアウト期間。認証試行に失敗したアカウントをロック状態にする時間を決定します。この継続時間が経過すると、アカウントのロックは自動的に解除されます。値ゼロは、アカウントのロック解除が自動的には行われないことを表します。

- ロックアウト対象の失敗が有効期限切れになるまでの間隔。ロックアウト対象の失敗として前回の認証試行の失敗を加算する場合の最大時間を決定します。値ゼロは、失敗した試行が自動的には有効期限切れにならないことを表します。

- アイドル・ロックアウト間隔。ユーザー・アカウントがディレクトリに対する認証を行わないでいられる最大時間を指定します。この時間が経過すると、アカウントはサーバーによってロックされます。このプロパティは、last-login-timeが有効化され、idle-lockout-intervalがゼロ以外の値に設定されている場合に適用されます。

次のコマンドでは、デフォルト・パスワード・ポリシーのアカウント・ロックアウト・プロパティが設定されます。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
set-password-policy-prop \
--policy-name "Default Password Policy" --set "lockout-failure-count:3" \
--set "lockout-duration:15 minutes" --set "idle-lockout-interval:90 days" \
--set "lockout-failure-expiration-interval:10 minutes"

例24-2 最終ログインの構成

最終ログインは、ユーザーがログイン履歴を追跡するために役立つ基本的なセキュリティ機能です。ディレクトリ・サーバーは、ユーザーの最終ログイン時刻を保持する操作属性ds-pwp-last-loginを備えています。別の属性を指定する場合は、その操作属性がサーバー・スキーマに定義されているか、ユーザーのエントリの少なくとも1つのオブジェクト・クラスで許可されている必要があります。

last-login-time-formatプロパティでは、時間書式が決定されます。最終ログインが有効化されているときに、時間書式が変更された場合は、previous-last-login-time-formatプロパティが使用されます。

次のコマンドでは、デフォルト・パスワード・ポリシーの最終ログイン・プロパティが設定されます。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
set-password-policy-prop \
--policy-name "Default Password Policy" \
--set "last-login-time-attribute:ds-pwp-last-login-time" \
--set "last-login-time-format:yyyyMMdd" \
--set "previous-last-login-time-format:yyyyMMdd"

例24-3 パスワード履歴数および履歴期間の構成

password-history-countプロパティでは、履歴に保持する過去のパスワード数が指定されます。値ゼロは、サーバーがパスワード履歴を保持しないことを表します。

password-history-durationプロパティでは、以前に使用されたパスワードをユーザー・パスワード履歴に保持する最大時間が指定されます。値0 secondsは、サーバーにパスワード履歴を保持しないことを表します。

次のコマンドでは、デフォルト・パスワード・ポリシーのパスワード履歴数と履歴期間が構成されます。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
set-password-policy-prop \
--policy-name "Default Password Policy" --set "password-history-count:3" \
--set "password-history-duration:5 seconds"

24.4.2 新しいパスワード・ポリシーを作成するには

異なる構成オプションを使用して複数のパスワード・ポリシーを構成し、格納できます。ディレクトリ・サーバー・インスタンスを設定すると、そのインスタンスでデフォルト・パスワード・ポリシーが使用され、ルート・ユーザー(cn=Directory Managerアカウントなど)を除くすべてのユーザー・エントリにそのポリシーが適用されます。

ディレクトリ内の特定のグループ用に、デフォルト・パスワード・ポリシーを変更したり、新しいパスワード・ポリシーを作成したりすることが可能です。特定のプロパティがパスワード・ポリシーに存在しない場合、サーバーはそのプロパティをデフォルト・パスワード・ポリシーから読み取ります。つまり、すべてのパスワード・ポリシーは、そのデフォルト値をデフォルト・パスワード・ポリシーから継承します。

次のコマンドでは、新しいパスワード・ポリシーが作成され、default-password-storage-scheme、lockout-duration、lockout-failure-countおよびpassword-change-requires-current-passwordプロパティが設定されます。残りのプロパティはデフォルト・パスワード・ポリシーから継承されます。

新しいパスワード・ポリシーを作成するには、dsconfigコマンドを次のように使用します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
create-password-policy \
--policy-name "Temp Password Policy" --set password-attribute:userPassword \
--set default-password-storage-scheme:"Salted SHA-1" \
--set lockout-duration:300s --set lockout-failure-count:3 \
--set password-change-requires-current-password:true

24.4.3 初回ログイン・パスワード・ポリシーを作成するには

初回ログイン・パスワード・ポリシーは、システムへの最初のログイン時にパスワードを変更するようにユーザーに要求する特殊パスワード・ポリシーです。通常、管理者が新規作成したアカウント用に新しい一時パスワードを設定し、この一時パスワードがユーザーの初回ログインに使用されます。初回ログイン後、ユーザーは自分のパスワードを作成するように要求されます。

初回ログイン・パスワード・ポリシーを作成するには、dsconfigコマンドを使用します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
create-password-policy --policy-name "First Login Password Policy" \
--set password-attribute:userpassword \
--set default-password-storage-scheme:"Salted SHA-1" \
--set allow-user-password-changes:true --set force-change-on-add:true \
--set force-change-on-reset:true \
--set expire-password-without-expiration:false \
--set password-expiration-warning-interval:86400 \
--set min-password-age:0 --set max-password-age:259200 \
--set lockout-duration:3600 --set lockout-failure-count:3 \
--set password-change-requires-current-password:true

24.4.4 パスワード・ポリシーを個別アカウントに割り当てるには

パスワード・ポリシーを個別ユーザーに割り当てるには、対象のユーザーのエントリにds-pwp-password-policy-dn属性を追加します。それにより、構成したパスワード・ポリシーが、そのユーザーに対してサーバーで使用されるようになります。

1. ldapmodifyを使用して、ds-pwp-password-policy-dn属性を追加します。

$ ldapmodify --h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
dn: uid=mgarcia,ou=Contractors,dc=example,dc=com
changetype: modify
add: ds-pwp-password-policy-dn
ds-pwp-password-policy-dn: cn=Temp Password Policy,cn=Password Policies,cn=config

2. ldapsearchを使用して、エントリを検証します。

$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
-b "dc=example,dc=com" -s sub "(uid=mgarcia)" ds-pwp-password-policy-dn

24.4.5 パスワード・ポリシーの変更を防止するには

ユーザーが自分のパスワード・ポリシーを変更できないようにするには、ルート・エントリにACIを追加する必要があります。

特定のACIとともにldapmodifyコマンドを使用します。

$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
dn: dc=example,dc=com
changetype: modify
add: aci
aci: (targetattr != "passwordPolicySubentry")(version 3.0; acl "Allow self
modification except for passwordPolicySubentry";
allow (write) (userdn = "ldap:///self");)

24.4.6 パスワード・ポリシーをユーザーのグループに割り当てるには

パスワード・ポリシーをユーザーのグループに割り当てるには、特定の基準に一致するすべてのエントリにds-pwp-password-policy-dn属性を自動的に割り当てる仮想属性を使用し、この仮想属性に基準を関連付けて追加します。基準では、ユーザーがグループのメンバーであることを条件全体とすることも、条件の一部とすることもできます。

パスワード・ポリシーをユーザーのグループに追加する仮想属性を作成するには、dsconfigを使用します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
create-virtual-attribute \
--name "Add PWPolicy to Admins" --type user-defined --set enabled:true \
--set attribute-type:ds-pwp-password-policy-dn \
--set group-dn:cn=Admins,ou=Groups,dc=example,dc=com \
--set conflict-behavior:real-overrides-virtual \
--set value:"cn=Admins PWPolicy,cn=Password Policies,cn=config"

24.4.7 LDAPサブエントリとしてパスワード・ポリシーを定義するには

LDAPサブエントリは、サーバーの操作データを保持する特殊エントリです。それらは、サブエントリ制御リクエスト制御を含めることで明示的にリクエストされない場合は、クライアントに返されない点で、操作属性に似ています。

パスワード・ポリシーをLDAPサブエントリとして定義すると、パスワード・ポリシーがユーザー・データとともに格納されるようになるため、レプリケート可能になります。

サブエントリ・パスワード・ポリシーは、構成で定義されているデフォルト・パスワード・ポリシーよりも優先されます。サブエントリ・パスワード・ポリシーに含まれていない設定は、デフォルト・パスワード・ポリシーから継承されます。

有効範囲が重なっている複数のパスワード・ポリシーが同じ親ノードに定義されている場合、その有効範囲内のエントリに適用するパスワード・ポリシー・サブエントリの選択は決定できません。そのため、パスワード・ポリシーの定義時には、他のポリシーとの間で競合が発生しないようにする必要があります。

サブエントリ・パスワード・ポリシーでは、パスワード・ポリシーの標準のプロパティのみを使用する必要があります。サブエントリ・パスワード・ポリシーに、Oracle Unified Directory固有のパスワード・ポリシー拡張を含めることはできません。

サブエントリ・パスワード・ポリシーの場合、パスワード・バリデータとパスワード・ジェネレータは常にデフォルトのサーバー・パスワード・ポリシーから継承します。個々のパスワード・ポリシー・サブエントリに対するパスワード・バリデータまたはパスワード・ジェネレータの定義は行えません。

サブエントリ・パスワード・ポリシーを定義するには、LDIFファイルにパスワード・ポリシーを作成し、ldapmodifyを使用してそのファイルをデータに追加します。パスワード・ポリシーの適用先エントリを指定するには、サブエントリ・サブツリーの指定でLDAPフィルタを追加します。

次の例では、管理者のグループにのみ適用するパスワード・ポリシーを作成します。このパスワード・ポリシーの指定内容は次のとおりです:

- ユーザーがパスワード試行に3回連続して失敗したら、そのユーザーのアカウントをロックします。

- 失敗間隔は300秒とし、この経過後は、以前の失敗した認証試行についてはロックアウト対象の失敗として加算しません。

- ロックアウト期間は300秒とし、この経過後は、ロックを自動的に解除します。

- このパスワード・ポリシーの適用先ユーザーは、自分のパスワードを変更できます。

- このパスワード・ポリシーを持つユーザーは、資格証明の公開を回避できる安全な方法を使用して自分のパスワードを変更する必要があります。

1. パスワード・ポリシーを指定するエントリを含むLDIFファイル(admin-pwp.ldif)を作成します。

dn: cn=Admins Password Policy,dc=example,dc=com
objectClass: top
objectClass: subentry
objectClass: pwdPolicy
cn: Admins Password Policy
pwdAttribute: userPassword
pwdLockout: TRUE
pwdMaxFailure: 3
pwdFailureCountInterval: 300
pwdLockoutDuration: 300
pwdAllowUserChange: TRUE
pwdSafeModify: TRUE
subtreeSpecification: {relativeBase "ou=people", specificationFilter
"(isMemberOf=cn=Admins,ou=Groups,dc=example,dc=com)" }

2. ldapmodifyコマンドを使用して、エントリをディレクトリに追加します。

$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -w password \
--defaultAdd --filename admin-pwp.ldif
Processing ADD request for cn=Admins Password Policy,dc=example,dc=com
ADD operation successful for DN cn=Admins Password Policy,dc=example,dc=com

24.4.8 パスワード・ポリシーを削除するには

不要になった任意のパスワード・ポリシーを配置場所のディレクトリから削除できます。ただし、デフォルト・パスワード・ポリシーとデフォルト・ルート・ユーザー・ポリシーは削除できません。

実際の操作では、まず、削除を計画しているパスワード・ポリシーを持つユーザーをチェックし、ユーザーを新しいパスワード・ディレクトリに移動します。その後、以前のパスワード・ポリシーを削除します。パスワード・ポリシーを削除したときに、削除したパスワード・ポリシーをまだ持っているユーザーがいる場合、そのユーザーは引き続き以前のパスワード・ポリシーを指すds-pwd-password-policy-dnを保有します。このエントリへのアクセス・リクエストが発生すると、サーバーはエラーを返します。

パスワード・ポリシーを削除するには、dsconfigを使用します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
delete-password-policy --policy-name "Temp Password Policy"

24.5 Oracle Directory Services Managerを使用したパスワード・ポリシーの構成

ODSMを使用してパスワード・ポリシーを管理できます。この方法について次の各項で説明します。

24.5.1 構成済パスワード・ポリシー・サブエントリのリスト

ODSMを使用して、サーバーに構成されているすべてのパスワード・ポリシー・サブエントリを表示する手順は次のとおりです:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「セキュリティ」タブを選択します。

3. 「パスワード・ポリシー・サブエントリ」要素を開きます。
すべてのパスワード・ポリシー・サブエントリのDNがリストされます。

4. パスワード・ポリシー・サブエントリの詳細を表示するには、そのDNを選択します。
右側のペインに、そのパスワード・ポリシー・サブエントリのプロパティが表示されます。

5. パスワード・ポリシー・サブエントリのいずれかの面を変更するには、必要な値を変更して「適用」をクリックします。

使用可能なすべてのプロパティとその値の詳細は、Oracle Unified Directory構成リファレンスのパスワード・ポリシーに関する項を参照してください。

24.5.2 パスワード・ポリシー・サブエントリの作成

ODSMを使用して新しいパスワード・ポリシー・サブエントリを作成する手順は次のとおりです:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「セキュリティ」タブを選択します。

3. 「パスワード・ポリシー・サブエントリ」要素を開きます。

4. 「追加」アイコンをクリックします。
右側のペインに、そのパスワード・ポリシー・サブエントリのプロパティが表示されます。

5. 「新規パスワード・ポリシー・サブエントリの作成」画面で、必須フィールドを設定します。
使用可能なすべてのプロパティとその値の詳細は、Oracle Unified Directory構成リファレンスのパスワード・ポリシーに関する項を参照してください。

6. パスワード・ポリシー・サブエントリの構成が完了したら、「作成」をクリックします。

24.5.3 既存のパスワード・ポリシー・サブエントリに基づくパスワード・ポリシー・サブエントリの作成

ODSMを使用して既存のパスワード・ポリシー・サブエントリに基づく新しいパスワード・ポリシー・サブエントリを作成する手順は次のとおりです:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「セキュリティ」タブを選択します。

3. 「パスワード・ポリシー・サブエントリ」要素を開きます。

4. 新しいサブエントリのベースとするパスワード・ポリシー・サブエントリを選択します。

5. 「類似追加」アイコンをクリックします。
右側のペインに、元のパスワード・ポリシー・サブエントリのプロパティが表示されます。

6. 必要な値を変更します。
使用可能なすべてのプロパティとその値の詳細は、Oracle Unified Directory構成リファレンスのパスワード・ポリシーに関する項を参照してください。

7. 新しいパスワード・ポリシー・サブエントリの構成が完了したら、「作成」をクリックします。

24.5.4 パスワード・ポリシー・サブエントリの削除

ODSMを使用してパスワード・ポリシー・サブエントリを削除する手順は次のとおりです:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「セキュリティ」タブを選択します。

3. 「パスワード・ポリシー・サブエントリ」要素を開きます。

4. 削除するパスワード・ポリシー・サブエントリを選択します。

5. 「削除」アイコンをクリックします。
削除の確認を求められます。「OK」をクリックします。

24.5.5 構成済パスワード・ポリシーの表示

ODSMを使用してパスワード・ポリシーのリストを表示する手順は次のとおりです:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「セキュリティ」タブを選択します。

3. 「パスワード・ポリシー」要素を開きます。
構成済パスワード・ポリシーのリストが表示されます。

4. パスワード・ポリシーを選択すると、そのプロパティが右側のペインに表示されます。

使用可能なすべてのプロパティとその値の詳細は、Oracle Unified Directory構成リファレンスのパスワード・ポリシーに関する項を参照してください。

24.5.6 パスワード・ポリシーの変更

ODSMを使用して構成済パスワード・ポリシーを変更する手順は次のとおりです:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「セキュリティ」タブを選択します。

3. 「パスワード・ポリシー」要素を開きます。
構成済パスワード・ポリシーのリストが表示されます。

4. プロパティを変更するパスワード・ポリシーを選択します。

使用可能なすべてのプロパティとその値の詳細は、Oracle Unified Directory構成リファレンスのパスワード・ポリシーに関する項を参照してください。

24.5.7 パスワード・ポリシーの作成

ODSMを使用して新しいパスワード・ポリシーを作成する手順は次のとおりです:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「セキュリティ」タブを選択します。

3. 「パスワード・ポリシー」要素を開きます。

4. 「追加」アイコンをクリックします。

5. 「パスワード・ポリシーの新規作成」画面で、必須プロパティを構成します。
使用可能なすべてのプロパティとその値の詳細は、Oracle Unified Directory構成リファレンスのパスワード・ポリシーに関する項を参照してください。

6. 新しいパスワード・ポリシーの構成が完了したら、「作成」をクリックします。

24.5.8 既存のパスワード・ポリシーに基づくパスワード・ポリシーの作成

ODSMを使用して既存のパスワード・ポリシーに基づく新しいパスワード・ポリシーを作成する手順は次のとおりです:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「セキュリティ」タブを選択します。

3. 「パスワード・ポリシー」要素を開きます。

4. 新しいポリシーのベースとするパスワード・ポリシーを選択します。

5. 「類似追加」アイコンをクリックします。

6. 「パスワード・ポリシーの新規作成」画面で、作成する新しいポリシー用にプロパティを編集します。
使用可能なすべてのプロパティとその値の詳細は、Oracle Unified Directory構成リファレンスのパスワード・ポリシーに関する項を参照してください。

7. 新しいパスワード・ポリシーの構成が完了したら、「作成」をクリックします。

24.5.9 パスワード・ポリシーの削除

ODSMを使用してパスワード・ポリシーを削除する手順は次のとおりです:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「セキュリティ」タブを選択します。

3. 「パスワード・ポリシー」要素を開きます。

4. 削除するパスワード・ポリシーを選択します。

5. 「削除」アイコンをクリックします。

6. 「OK」をクリックして、削除を確定します。

24.5.10 サポートされているパスワード記憶スキームの表示

パスワード記憶スキームは、サーバーで保管されるユーザー・パスワードをエンコードするためのメカニズムを提供します。ユーザーが入力したパスワードが正しいかどうかをサーバーは判断できますが、多くの場合、パスワードは、クリアテキスト・パスワードの内容をユーザーに決定させない方法でエンコードされます。Oracle Unified Directoryは多数のパスワード記憶スキームをサポートしています。詳細は、D.15.9項「パスワード記憶スキーム」を参照してください。

ODSMを使用してパスワード記憶スキームのリストを表示する手順は次のとおりです:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「セキュリティ」タブを選択します。

3. 「パスワード記憶」要素を開きます。

4. パスワード記憶スキームのリストが表示されます。

24.5.11 パスワード記憶スキームの有効化または無効化

ODSMを使用してパスワード記憶スキームを有効化または無効化する手順は次のとおりです:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「セキュリティ」タブを選択します。

3. 「パスワード記憶」要素を開きます。

4. 有効化または無効化するパスワード記憶スキームを選択します。

5. 右側のペインで、必要に応じて、「有効」ボックスを選択するか、このボックスの選択を解除します。

6. 「適用」をクリックして、変更を保存します。

24.6 パスワード・バリデータ

パスワード・バリデータは、入力されたプレーン・テキスト・パスワードの使用が許容されるかどうかを判定するメカニズムを提供します。この検証によって、脆弱で容易に推測される可能性がある単純なパスワードをユーザーが選択するのを防止できます。実行可能な検証のタイプには次のものがあります:

- 指定されている最小文字数以上の文字がパスワードに含まれていることの確認

- 指定されている最大文字数を超える文字数がパスワードに含まれていないことの確認

- 各種文字セット(小文字、大文字、数字、記号など)の指定された文字数以上の文字がパスワードに含まれていることの確認

- ユーザーが以前に使用したパスワードを再利用することの確実な防止(つまり、そのパスワードが以前のパスワードの履歴に含まれていないことの確認)

- ユーザーがそのユーザーのエントリの別の属性値に一致するパスワードを選択することの確実な防止

- パスワードが指定されたディレクトリに含まれていないことの確認

ユーザーのパスワード・ポリシーでは、そのユーザーが新しいパスワードを入力するたびに使用されるパスワード・バリデータ・セットが指定されます。パスワード・バリデータをアクティブ化するには、対応する構成エントリを有効化し、そのバリデータをアクティブ化するパスワード・ポリシーのpassword-validator属性にそのエントリのDNを含める必要があります。

サーバーで次のパスワード・バリデータをデフォルトで使用できます:

- 属性値パスワード・バリデータ
このバリデータは、提示されたパスワードの使用が許容されるかどうかを判定するために、そのパスワードがユーザーのエントリ内のいずれかの属性に含まれているかどうかを判定します。このバリデータは、すべての属性または指定した属性サブセット内を検索するように構成できます。

- 文字セット・パスワード・バリデータ
このバリデータは、提示されたパスワードが許容されるかどうかを判定するために、1つ以上のユーザー定義文字セット内の文字が必要な数だけそのパスワードに含まれているかどうかをチェックします。たとえば、このバリデータでは、小文字、大文字、数字および記号がそれぞれ1つ以上パスワードに含まれているかどうかを確認できます。

- 辞書パスワード・バリデータ
このバリデータは、提示されたパスワードが許容されるかどうかを、指定された辞書ファイルにそのパスワード値が含まれているかどうかに基づいて判定します。サーバーに大きな辞書ファイルが装備されていますが、代替辞書も指定できます。この場合、辞書は、1行に1つのワードが含まれるプレーン・テキスト・ファイルである必要があります。

- 長さに基づくパスワード・バリデータ
このバリデータは、提示されたパスワードが許容されるかどうかを、そのパスワードに含まれる文字数が値の許容範囲内に収まっているかどうかに基づいて判定します。上限と下限の両方を定義できます。

- 繰返し文字パスワード・バリデータ
このバリデータは、提示されたパスワードが許容されるかどうかを、パスワード値内での任意の文字の連続使用回数に基づいて判定します。「aaaaaa」や「aaabbb」のような、同じ文字の繰返しで構成されている文字列がユーザー・パスワードに含まれていないことを確認します。

- 類似に基づくパスワード・バリデータ
このバリデータは、提示されたパスワードが許容されるかどうかを判定するために、ユーザーの現在のパスワードへの類似度を測定します。特に、レーベンシュタイン距離アルゴリズムを使用して、文字列間の変換における変更(文字の挿入、削除または置換)の最小数を判定します。この使用により、ユーザーが新しいパスワードの設定時に現在のパスワードにわずかな変更しか行わないことを防止できます。このバリデータを有効にするには、ユーザーの現在のパスワードにアクセスできるようにする必要があります。そのため、このパスワード・バリデータを有効化する場合は、この他に、パスワード・ポリシー構成内のpassword-change-requires-current-passwordプロパティをtrueに設定する必要があります。

- 一意文字パスワード・バリデータ
このバリデータは、提示されたパスワードが許容されるかどうかを、パスワード内に含まれる一意の文字数に基づいて判定します。この使用により、「aabbcc」や「abcabc」のような、少数の文字しか含まれない単純なパスワードを防止できます。

24.6.1 パスワード・バリデータの管理

パスワード・バリデータは、dsconfigコマンドまたはODSMインタフェースを使用して管理できます。この方法について次の各項で説明します:

- 第24.6.1.1項「使用可能なパスワード・バリデータを表示するには」

- 第24.6.1.2項「パスワード・バリデータのプロパティを表示するには」

- 第24.6.1.3項「パスワード・バリデータを有効化または無効化するには」

- 第24.6.1.4項「パスワード・バリデータの値を構成するには」

- 第24.6.1.5項「パスワード・バリデータをパスワード・ポリシーに関連付けるには」

24.6.1.1 使用可能なパスワード・バリデータを表示するには

使用可能なパスワード・バリデータをリストするには、dsconfigコマンドを次のように使用します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
list-password-validators
Password Validator                  : Type                : enabled
------------------------------------:---------------------:--------
Attribute Value                     : attribute-value     : true
Character Set                       : character-set       : true
Dictionary                          : dictionary          : false
Length-Based Password Validator     : length-based        : true
Repeated Characters                 : repeated-characters : true
Similarity-Based Password Validator : similarity-based    : true
Unique Characters                   : unique-characters   : true

ODSMを使用して使用可能なパスワード・バリデータを表示する手順は次のとおりです:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「セキュリティ」タブを選択します。

3. 「パスワード・バリデータ」要素を開きます。
使用可能なパスワード・バリデータが表示されます。

24.6.1.2 パスワード・バリデータのプロパティを表示するには

特定のパスワード・バリデータのプロパティを表示するには、dsconfigコマンドを次のように使用します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
get-password-validator-prop --validator-name "Length-Based Password Validator"
Property            : Value(s)
--------------------:---------
enabled             : true
max-password-length : 0
min-password-length : 6

ODSMを使用してパスワード・バリデータのプロパティを表示する手順は次のとおりです:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「セキュリティ」タブを選択します。

3. 「パスワード・バリデータ」要素を開きます。
使用可能なパスワード・バリデータが表示されます。

4. パスワード・バリデータをクリックすると、右側のペインにそのプロパティが表示されます。

24.6.1.3 パスワード・バリデータを有効化または無効化するには

デフォルトでは、辞書バリデータ以外のすべてのパスワード・バリデータが有効化されます。バリデータを特定のパスワード・ポリシーに関連付けるには、事前にそのバリデータを有効化する必要があります。

dsconfigコマンドを使用して、enabledプロパティをtrueまたはfalseに設定します。たとえば、長さに基づくパスワード・バリデータを無効化するには、enabledプロパティを次のように設定します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
set-password-validator-prop --validator-name "Length-Based Password Validator" \
--set enabled:false

ODSMを使用してパスワード・バリデータを有効化または無効化する手順は次のとおりです:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「セキュリティ」タブを選択します。

3. 「パスワード・バリデータ」要素を開きます。
使用可能なパスワード・バリデータが表示されます。

4. パスワード・バリデータをクリックすると、右側のペインにそのプロパティが表示されます。

5. バリデータを有効化する場合は「有効」チェック・ボックスを選択し、バリデータを無効化する場合はこのチェック・ボックスの選択を解除します。

6. 「適用」をクリックして、構成変更を保存します。

24.6.1.4 パスワード・バリデータの値を構成するには

パスワード・バリデータのプロパティを構成するには、dsconfigコマンドを使用します。たとえば、パスワードは8文字以上の長さにする必要があることを指定するには、min-password-lengthプロパティを次のように設定します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
set-password-validator-prop --validator-name "Length-Based Password Validator" \
--set min-password-length:6

ODSMを使用してパスワード・バリデータのプロパティを表示する手順は次のとおりです:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「セキュリティ」タブを選択します。

3. 「パスワード・バリデータ」要素を開きます。
使用可能なパスワード・バリデータが表示されます。

4. パスワード・バリデータをクリックすると、右側のペインにそのプロパティが表示されます。

5. 必要なプロパティを構成し、「適用」をクリックして構成変更を保存します。

24.6.1.5 パスワード・バリデータをパスワード・ポリシーに関連付けるには

パスワード・バリデータは、特定のパスワード・ポリシーに関連付けられているときにのみ考慮されます。

dsconfigを使用してパスワード・バリデータをパスワード・ポリシーに関連付けるには、そのパスワード・ポリシーのpassword-validatorプロパティを設定します。

たとえば、パスワードが特定の文字数を順守しているかどうかをデフォルト・パスワード・ポリシーでチェックすることを指定するには、デフォルト・パスワード・ポリシーのpassword-validatorプロパティを次のように設定します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
set-password-policy-prop --policy-name "Default Password Policy" \
--set password-validator:"Length-Based Password Validator"

ODSMを使用してパスワード・バリデータをパスワード・ポリシーに関連付ける手順は次のとおりです:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「セキュリティ」タブを選択します。

3. 「パスワード・ポリシー」要素を開きます。
使用可能なパスワード・ポリシーが表示されます。

4. パスワード・ポリシーをクリックすると、右側のペインにそのプロパティが表示されます。

5. 右側のペインで「構文」要素を開きます。

6. 「パスワード・バリデータ」リストから、このパスワード・ポリシーに関連付けるパスワード・バリデータを選択します。

7. 「適用」をクリックして、構成変更を保存します。

24.7 パスワード・ジェネレータ

パスワード・ジェネレータは、ユーザー・アカウントのパスワードを生成するために使用されます。パスワード・ジェネレータはパスワード変更拡張操作とともに使用され、このジェネレータによって、クライアントからのリクエストにパスワードが含まれていない場合に新しいパスワードが生成されます。有効なパスワード・ポリシーにパスワード・ジェネレータが関連付けられていない場合、パスワード変更拡張操作によるユーザーのパスワードの自動生成は行われません。

パスワード・ジェネレータによって作成されたパスワードには、検証は適用されません。関連付けられたパスワード・バリデータの要件と一致するパスワードを作成するように、パスワード・ジェネレータを構成してください。

ディレクトリ・サーバー・インスタンスには、デフォルトで1つのパスワード・ジェネレータが構成されます。これはランダム・パスワード・ジェネレータです。次の各項では、dsconfigを使用したパスワード・ジェネレータの管理方法について説明します。

24.7.1 構成済パスワード・ジェネレータを表示するには

構成済パスワード・ジェネレータをリストするには、dsconfigコマンドを次のように使用します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
list-password-generators
Password Generator        : Type   : enabled
--------------------------:--------:--------
Random Password Generator : random : true

24.7.2 パスワード・ジェネレータのプロパティを表示するには

パスワード・バリデータのプロパティを表示するには、dsconfigコマンドを次のように使用します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
get-password-generator-prop --generator-name "Random Password Generator"
Property               : Value(s)
-----------------------:-----------------------------------------------------
enabled                : true
password-character-set : alpha:abcdefghijklmnopqrstuvwxyz, numeric:0123456789
password-format        : "alpha:3,numeric:2,alpha:3"

パスワード文字セットは複数値プロパティであり、各値で異なる文字セットが定義されます。文字セットの書式は、セット名の後にコロンを1つ付け、次にセット内の文字を指定します。たとえば、alpha:abcdefghijklmnopqrstuvwxyzという値では、ASCIIのすべての英小文字を含む、alphaという文字セットが定義されます。

パスワード書式はカンマ区切りの要素リストであり、各要素はpassword-character-setプロパティで定義されている文字セット名および1つのコロンと、使用するそのセット内の文字数で構成されます。たとえば、デフォルト値alpha:3,numeric:2,alpha:3では、最初の3文字にalphaセット内の文字、次の2文字にnumericセット内の文字、最後の3文字にalphaセット内の文字をそれぞれ使用した、8文字のパスワードが生成されます。

24.7.3 パスワード・ジェネレータを有効化または無効化するには

デフォルトで、ランダム・パスワード・ジェネレータが有効化されます。バリデータを特定のパスワード・ポリシーに関連付けるには、事前にそのバリデータを有効化する必要があります。

dsconfigコマンドを使用して、enabledプロパティをtrueまたはfalseに設定します。たとえば、ランダム・パスワード・ジェネレータを無効化するには、enabledプロパティを次のように設定します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
set-password-generator-prop --generator-name "Random Password Generator" \
--set enabled:false

24.7.4 パスワード・ジェネレータの値を構成するには

パスワード・ジェネレータのプロパティを構成するには、dsconfigコマンドを使用します。たとえば、ランダム・パスワード・ジェネレータによって生成するパスワードを、3つの文字、3つの数字および定義した2つの特殊文字の書式にする必要があることを指定するには、対応するプロパティを次のように設定します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
set-password-generator-prop --generator-name "Random Password Generator" \
--add password-character-set:special:\!@#\$%^&*\(\)
--set password-format:alpha:3,numeric:3,special:2

24.7.5 パスワード・ジェネレータをパスワード・ポリシーに関連付けるには

パスワード・ジェネレータは、特定のパスワード・ポリシーに関連付けられているときにのみ考慮されます。

dsconfigを使用してパスワード・ジェネレータをパスワード・ポリシーに関連付けるには、そのパスワード・ポリシーのpassword-generatorプロパティを設定します。

たとえば、Special Generatorという名前の新しいパスワード・ジェネレータをデフォルト・パスワード・ポリシーで使用することを指定するには、デフォルト・パスワード・ポリシーのpassword-generatorプロパティを次のように設定します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
set-password-policy-prop --policy-name "Default Password Policy" \
--set password-generator:"Special Generator"

25 Oracleのエンタープライズ・ユーザー・セキュリティとの統合

Oracleのエンタープライズ・ユーザー・セキュリティ(EUS)を使用することによって、Oracle Database認証用に、LDAPに準拠したディレクトリ・サービスにユーザーIDを格納できます。

エンタープライズ・ユーザー・セキュリティを使用すると、エンタープライズ全体でデータベース・ユーザーを一元的に管理できます。エンタープライズ・ユーザーは、LDAPに準拠にしたディレクトリ・サービス内に作成されます。ディレクトリに登録された様々なエンタープライズ・データベースのロールや特権をこのエンタープライズ・ユーザーに割り当てることができます。

ユーザーは、Oracle Unified Directoryに格納されている資格証明を提供することによって、Oracle Databaseに接続します。データベースはLDAP検索操作を実行して、ユーザー固有の認証および認可情報について問い合せます。

Oracle Unified Directoryとエンタープライズ・ユーザー・セキュリティとを統合すると、追加の同期を行うことなく、LDAP準拠ディレクトリ・サービスに格納されているユーザーIDを活用できるため、認証機能と認可機能が強化され、かつ簡素化されます。

この章では、次のトピックを取り扱います:

- 第25.1項「統合シナリオ」

- 第25.2項「このリリースの新機能」

- 第25.3項「エンタープライズ・ユーザー・セキュリティへのOracle Unified Directoryの統合」

- 第25.4項「エンタープライズ・ユーザー・セキュリティおよび外部LDAPディレクトリとの統合」

25.1 統合シナリオ

Oracle Unified Directoryとエンタープライズ・ユーザー・セキュリティとを統合するには、次のいずれかのシナリオを選択できます:

- Oracle Unified DirectoryにユーザーIDを格納。詳細は、第25.3項「エンタープライズ・ユーザー・セキュリティへのOracle Unified Directoryの統合」で説明しています。

- LDAPに準拠した外部ディレクトリ・サービスにユーザーIDを格納し、プロキシ・サーバーとしてOracle Unified Directoryを使用。詳細は、第25.4項「エンタープライズ・ユーザー・ディレクトリおよび外部LDAPディレクトリとの統合」で説明しています。

25.2 このリリースでの新機能

このリリースにおけるOracle Unified DirectoryでのEUSのサポート内容は次のとおりです:

- 証明書認証、Kerberos認証との統合。

注意:

証明書認証では、証明書内のDNに一致するDNエントリのみをサポートしています。

- パスワード・ポリシー: パスワード・ポリシーは、アイデンティティ管理レルムのすべてのユーザー・パスワードに適用されるルール・セットです。パスワード・ポリシーには、パスワードの難易度、パスワードの最低限の文字数などが含まれます。アカウントのロックアウトとパスワード有効期限の設定も含まれます。
ユーザー・エントリを格納するLDAP準拠ディレクトリで定義されているパスワード・ポリシー・エントリを、エンタープライズ・ユーザー・セキュリティ用にOracle Databaseで使用できます。

データベースはOracle Unified Directoryと通信し、パスワード・ポリシー違反についてレポートするようにOracle Unified Directoryにリクエストします。データベースは、Oracle Unified Directoryからポリシー違反に関するレスポンスを取得すると、適切な警告またはエラー・メッセージをユーザーに表示します。

データベースは次のイベントをレポートします:

- ユーザー・パスワードがまもなく期限切れになる場合に警告を表示し、ユーザーが自分のパスワードを何日以内に変更する必要があるかを表示します。

- パスワードが期限切れになった場合に警告を表示し、残っている猶予期間ログイン数についてユーザーに通知します。

- ユーザー・パスワードが期限切れになり、ユーザーに猶予期間ログインが残っていない場合に、エラーを表示します。

- ログイン試行に繰り返し失敗したためにユーザー・アカウントがロックされた場合に、エラーを表示します。

- ユーザー・アカウントが管理者によって無効にされている場合に、エラーを表示します。

- ユーザー・アカウントが非アクティブである場合に、エラーを表示します。

エンタープライズ・ユーザーによってデータベースへのログイン試行が行われると、Oracle Unified Directoryまたはサポートされている外部LDAP準拠ディレクトリでそのユーザー・アカウントのステータスが更新されます。たとえば、データベースへのログイン試行が連続して失敗すると、ディレクトリのパスワード・ポリシーに従って、そのアカウントはディレクトリでロックされます。

- 次の外部LDAP準拠ディレクトリをサポートしています:

- Microsoft Active Directory

- Novell eDirectory

- Oracle Directory Server Enterprise Edition

- Oracle Unified Directory

注意:

別のOracle Unified Directoryをプロキシ・サーバーとして持つ外部ディレクトリ・サーバーとして、Oracle Unified Directoryインスタンスを構成できます。

エンタープライズ・ユーザー・セキュリティの構成の詳細は、『Oracle Databaseエンタープライズ・ユーザー管理者ガイド』を参照してください。

25.3 エンタープライズ・ユーザー・セキュリティへのOracle Unified Directoryの統合

ユーザーIDを格納するOracle Unified Directoryを、追加の同期不要でエンタープライズ・ユーザー・セキュリティに統合できます。これを行うには、次を実行します:

- Oracle Unified Directoryサーバーでのエンタープライズ・ユーザー・セキュリティの構成

- エンタープライズ・ユーザー・セキュリティに対応した、Oracle Unified Directoryの構成変更

- Oracle Unified Directoryに対応した、Oracle Databaseの構成

25.3.1 Oracle Unified Directoryサーバーでのエンタープライズ・ユーザー・セキュリティの構成

Oracle Unified DirectoryサーバーでEUSの構成を行うには、次のいずれかのオプションを使用します:

- インストール時のエンタープライズ・ユーザー・セキュリティの有効化

- 既存のインスタンスでの、ODSMを使用したエンタープライズ・ユーザー・セキュリティの有効化

注意:

- インストール時にEUSを有効化するには、「インストール時のエンタープライズ・ユーザー・セキュリティの有効化」で説明している手順を実行します。

- 既存のOracle Unified DirectoryインスタンスでEUSを構成するには、「既存のインスタンスでの、ODSMを使用したエンタープライズ・ユーザー・セキュリティの有効化」で説明している手順を実行します。

25.3.1.1 インストール時のエンタープライズ・ユーザー・セキュリティの有効化

このオプションは、Oracle Unified Directoryのインストール時に使用できます。Oracle Unified Directoryディレクトリ・サーバー・インスタンスの設定時に、そのサーバー・インスタンスとEUSとの統合を有効化します。この手順は、Oracle Fusion Middleware Oracle Unified Directoryインストレーション・ガイドのディレクトリ・サーバーの設定に関する項の説明に従ってください。

注意:

oud-setupのグラフィカル・インタフェース・オプションの実行時に「Oracleコンポーネントの統合」画面で「EUSで有効にする」を選択します。または、--cliオプションを指定してoud-setupを実行する場合は、インストーラの起動時に次のオプションを指定します:

oud-setup --eus

25.3.1.2 既存のインスタンスでの、ODSMを使用したエンタープライズ・ユーザー・セキュリティの有効化

既存のディレクトリ・サーバー・インスタンスで、ODSMを使用してEUS用の新しい接尾辞を作成できます。この機能と同等のコマンドラインはありません。

ODSMを使用してEUS用の接尾辞を作成する手順は次のとおりです:

1. SSLが有効化されたLDAP接続ハンドラがサーバー・インスタンスに存在することを確認します。
SSLが有効になっていない場合は、第14.2項「Oracle Directory Services Managerを使用したサーバー構成の管理」で説明している手順に従ってLDAPS接続を追加します。

2. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

3. 「ホーム」タブを選択します。

4. 「構成」メニューで、「ローカル・ネーミング・コンテキストの作成」を選択します。
「新規ローカル・ネーミング・コンテキスト」ウィンドウが表示されます。

5. 次の詳細を入力します:

1. 「ベースDN」フィールドに、作成する接尾辞の名前を入力します。

注意:

ユーザー・データがすでに移入されている既存の接尾辞では、EUSの有効化はできません。

2. 「ディレクトリ・データ・オプション」グループから、接尾辞へのデータの移入オプションとして次のいずれかを選択します:
「ベース・エントリの作成のみ」では、接尾辞のベース・エントリとともにデータベースが作成されます。その他のエントリは、接尾辞の作成後に追加する必要があります。

「データベースを空のままにする」では、空のデータベースが作成されます。ベース・エントリおよびその他のエントリは、接尾辞の作成後に追加する必要があります。

注意:

接尾辞は少なくとも1つのエントリを含んでいる必要があるため、「データベースを空のままにする」オプションは選択しないでください。

「生成されたサンプル・データのインポート」を選択すると、接尾辞にサンプル・エントリが移入されます。

「ユーザー・エントリ数」フィールドに、生成するエントリ数を指定します。ODSMを使用してインポートできるサンプル・エントリ数は、最大30,000です。30,000を超える数のエントリを追加する場合は、import-ldifコマンドを使用する必要があります。

3. 「Oracleコンポーネントの統合」リージョンで、「エンタープライズ・ユーザー・セキュリティ(EUS)に使用可能」を選択して、新しい接尾辞を有効にします。
EUSを選択すると、この接尾辞が作成されるほかに、2つの接尾辞"cn=oracleschemaversion"と"cn=oraclecontext"が自動的に作成されます。また、EUSワークフロー要素がローカルのバックエンド・ワークフロー要素の前に追加されます。さらに、"cn=schema"のDNリネーム・ワークフロー要素が追加され、"cn=subschemasubentry" DNを使用してこの要素にアクセスできるようになります。

4. 「ネットワーク・グループ」リージョンで、次の手順に従って1つ以上のネットワーク・グループに接尾辞をアタッチします:

- 接尾辞を既存のネットワーク・グループにアタッチする場合は、「既存のものを使用」を選択し、必要なネットワーク・グループをリストから選択します。

- 接尾辞を新しいネットワーク・グループにアタッチする場合は、「新規作成」を選択し、作成するネットワーク・グループ名を「名前」フィールドに入力します。

同じ接尾辞を複数のネットワーク・グループにアタッチできます。

5. 「ワークフロー要素」リージョンで、次のいずれかの手順に従ってワークフロー要素に接尾辞をアタッチします:

- 接尾辞を既存のワークフロー要素にアタッチする場合は、「既存のものを使用」を選択し、必要なワークフロー要素をリストから選択します。

- 接尾辞を新しいワークフロー要素にアタッチする場合は、「新規作成」を選択し、作成するワークフロー要素名を「名前」フィールドに入力します。

6. 「作成」をクリックします。
次の確認メッセージが表示されます:

構成が正常に作成されました。

25.3.2 エンタープライズ・ユーザー・セキュリティに対応した、Oracle Unified Directoryの構成変更

OUDをEUS対応に設定した後は、次の手順に従ってOUD構成のレルム情報を更新する必要があります:

1. LDIFテンプレート・ファイル(install_dir/config/EUS/modifyRealm.ldif)を見つけます。

2. modifyRealm.ldifファイルを次のように編集します:

- dc=example,dc=comをサーバー・インスタンスの現在のネーミング・コンテキストに置き換えます。

- ou=peopleとou=groupsをDIT内のユーザー・エントリとグループ・エントリの現在の場所にそれぞれ置き換えます。

3. ldapmodifyコマンドを使用して、編集済のLDIFテンプレート・ファイルで構成を更新します。例:

$ ldapmodify -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -v -f modifyRealm.ldif

25.3.3 Oracle Unified Directoryに対応した、Oracle Databaseの構成

次の手順に従って、エンタープライズ・ユーザー・セキュリティに対応するようにOracle Databaseを構成する必要があります:

- データベースの構成

- データベースの登録

25.3.3.1 データベースの構成

Net Configuration Assistant (NetCA)ツールを実行して、Oracle Unified Directoryのホスト名とポート番号をデータベースに対して構成します。

ディレクトリを使用するようにデータベースを構成するには:

1. Oracle Net Configuration Assistantを起動します:
Unix

コマンドラインでnetcaを実行します(これは$ORACLE_HOME/binにあります)。

Windows

「スタート」→「プログラム」→「Oracle - HOME_NAME」→「構成および移行ツール」→「Net Configuration Assistant」の順に選択します。

「Oracle Net Configuration Assistant: ようこそ」画面が表示されます。

2. ディレクトリ・サービス使用構成を選択して「次へ」をクリックします。
「Oracle Net Configuration Assistant: ディレクトリ使用構成-ディレクトリ・タイプ」画面が表示されます。

3. ディレクトリ・タイプとして「Oracle Unified Directory」を選択して、「次へ」をクリックします。
「Oracle Net Configuration Assistant: ディレクトリ使用構成-ディレクトリの場所」画面が表示されます。

4. 次の詳細を入力します:

- ホスト名: Oracle Unified Directoryサーバーを実行するホストの名前を入力します。

- ポート: Oracle Unified Directoryのポート番号を入力します。

- SSLポート: Oracle Unified DirectoryのSSLポート番号を入力します。

「次へ」をクリックします。

「Oracle Net Configuration Assistant: ディレクトリ使用構成-Oracleコンテキストの選択」画面が表示されます。

5. 使用するデフォルトのOracleコンテキストを選択します。ディレクトリ・サーバー上にOracle Unified Directoryレルムが複数存在する場合は、これを選択する必要があります。「次へ」をクリックします。
ディレクトリ使用構成の完了画面が表示されます。

6. ディレクトリ使用構成が正常に完了したことを確認します。「次へ」をクリックします。

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

NetCAによって、$ORACLE_HOME/network/adminディレクトリ(Unixの場合)またはORACLE_HOME\network\adminディレクトリ(Windowsの場合)にldap.oraファイルが作成されます。このファイルには、ディレクトリに関する接続情報の詳細が格納されます。

25.3.3.2 データベースの登録

データベースをディレクトリ・サービスに登録します。Database Configuration Assistant (DBCA)ツールを使用して、データベースをOracle Unified Directoryに登録できます。

データベースをディレクトリに登録するには:

1. dbcaコマンドを使用してDBCAを起動します。

- UNIXシステムでは、次のコマンドを使用してDBCAを起動できます:
$ORACLE_HOME/bin/dbca

- Windowsでは、「スタート」メニューからDBCAを起動することもできます:
「スタート」→「すべてのプログラム」、「Oracle - OracleHomeName」→「構成および移行ツール」の順にクリックし、「Database Configuration Assistant」を選択します。

「ようこそ」画面が表示されます。

2. 「次へ」をクリックします。
「操作」画面が表示されます。

3. 「データベース・オプションの構成」を選択します。
「次へ」をクリックします。

「データベース」画面が表示されます。

4. 構成するデータベース名を選択します。オペレーティング・システムの認証を使用していない場合は、SYSユーザー資格証明の入力を求められることもあります。
「次へ」をクリックします。

「管理オプション」画面が表示されます。

5. Database Controlを使用してデータベースの管理を続行する場合は、「Database Controlで構成済のデータベースを維持」を選択します。また、Grid Controlを使用したデータベースの管理を選択することもできます。
「次へ」をクリックします。

「セキュリティ設定」画面が表示されます。

6. 11gのセキュリティ設定を維持する場合は、「11gのデフォルトの高度セキュリティ設定を維持」を選択します。
「次へ」をクリックします。

「ネットワーク構成」画面が表示されます。

7. データベースをディレクトリに登録するには、「データベースを登録する」を選択します。Oracle Unified Directoryへのデータベースの登録を許可されたユーザーの識別名(DN)を入力します。また、ディレクトリ・ユーザーのパスワードも入力します。ウォレット・パスワードを入力します。「パスワードの確認」フィールドにパスワードを再度入力します。
「次へ」をクリックします。

注意:

データベースでは、ランダムに生成されたパスワードを使用してディレクトリにログインします。このデータベース・パスワードは、Oracleウォレットに格納されます。また、このウォレットを使用して、SSL接続に必要な証明書を格納することもできます。

指定するウォレット・パスワードは、データベース・パスワードとは異なります。ウォレット・パスワードは、ウォレットの保護に使用します。

「データベース・コンポーネント」画面が表示されます。

8. 「次へ」をクリックします。
「接続モード」ページが表示されます。

9. 「専用サーバー・モード」または「共有サーバー・モード」を選択します。
「終了」をクリックします。

「確認」ダイアログ・ボックスが表示されます。

10. 「OK」をクリックします。

注意:

データベースをディレクトリに登録した後に、データベース・ウォレットの自動ログインが有効になっていることを確認します。デフォルトのウォレットは、$ORACLE_BASE/admin/database_sid/walletディレクトリ(Unixの場合)またはORACLE_BASE\admin\database_sid\walletディレクトリ(Windowsの場合)に作成されます。

ウォレット・ディレクトリにcwallet.ssoファイルが存在することをチェックすることで、ウォレットに対する自動ログインが有効であることを確認できます。このファイルが存在しない場合は、Oracle Wallet Managerを使用してウォレットを開き、ウォレットに対する自動ログインを有効にするオプションを使用して、自動ログインを有効にできます。

25.4 エンタープライズ・ユーザー・セキュリティおよび外部LDAPディレクトリとの統合

Oracle Unified Directoryとエンタープライズ・ユーザー・セキュリティ(EUS)とを統合すると、追加の同期を行うことなく、外部LDAPリポジトリに格納されているユーザーIDを一元化できるため、認証機能と認可機能が強化され、かつ簡素化されます。

Oracle Unified Directoryが外部LDAPリポジトリのフロントエンド処理を実行するプロキシとして構成されている場合は、EUSを外部LDAPディレクトリに統合できます。EUSの構成の詳細はOracle Unified Directoryにローカルで格納され、エンタープライズ・ユーザーとエンタープライズ・グループの詳細のみがリモートの外部LDAPディレクトリに格納されます。

この項では、Oracle Unified DirectoryをOracleのエンタープライズ・ユーザー・セキュリティに統合する方法について説明します。この項の内容は次のとおりです:

- 外部ディレクトリでの統合の構成

- Oracle Unified Directoryでの統合の構成

注意:

ORACLE_HOME/config/eus/ディレクトリ(Unixの場合)またはORACLE_HOME\config\eus\ディレクトリ(Windowsの場合)のバックアップ・コピーを作成します。エンタープライズ・ユーザー・セキュリティ統合で必要な構成ファイルはすべてeusディレクトリにあります。eusディレクトリのバックアップ・コピーを作成すると、使用する環境に基づいているオリジナルのeusディレクトリにあるファイルをテンプレートとして編集しつつ、オリジナル・ファイルのコピーを保持しておくことができます。

25.4.1 外部ディレクトリでの統合の構成

この項では、Oracle Unified Directoryをエンタープライズ・ユーザー・セキュリティと統合し、特定の外部ディレクトリを使用できるようにするための手順を説明します。

この手順は、外部ディレクトリのタイプごとに次の項に分かれています:

- Microsoft Active DirectoryのユーザーID

- Oracle Directory Server Enterprise EditionのユーザーID

- Novell eDirectoryのユーザーID

- Oracle Unified DirectoryのユーザーID

注意:

Microsoft Active Directoryを除いて、これらの外部ディレクトリではバックエンドのLDAPスキーマ拡張は不要になりました。これらの変更はOracle Unified Directoryローカル・ストアで実行されるようになりました。

Active Directoryの場合は、orclCommonAttribute属性を追加するための、スキーマに対する単一の最小限の変更のみが必要です。

25.4.1.1 Microsoft Active DirectoryのユーザーID

ユーザーIDがActive Directoryに格納されている場合に、Oracle Unified Directoryをエンタープライズ・ユーザー・セキュリティに統合する手順は次のとおりです:

1. Active Directoryイメージのバックアップ・コピーを作成します。Active Directory内部のスキーマ拡張は永続的で、キャンセルできません。バックアップ・イメージがあると、必要になったときに変更をすべてリストアできます。

2. Oracle Unified Directoryに組み込まれているJavaクラスを使用してエンタープライズ・ユーザー・セキュリティの必須スキーマであるExtendADをActive Directoryにロードするために、次のコマンドを実行します。
ExtendADファイルは、$ORACLE_HOME/config/EUS/ActiveDirectory/ディレクトリ(Unixの場合)またはORACLE_HOME\config\EUS\ActiveDirectory\ディレクトリ(Windowsの場合)にあります。ORACLE_HOME/jdk/binディレクトリのjava実行可能ファイルを使用できます。

java ExtendAD -h Active_Directory_Host_Name -p Active_Directory_Port
-D Active_Directory_Admin_DN -w Active_Directory_Admin_Password
–AD Active_Directory_Domain_DN -commonattr

例:

java ExtendAD -h myhost -p 389 -D cn=administrator,cn=users,dc=example,dc=com -w <pwd> -AD dc=example,dc=com -commonattr

3. 次の手順に従って、Oracle Unified Directoryパスワード変更通知プラグインoidpwdcn.dllをインストールします:

1. Windowsのタイプに応じて、次の操作を行います:
Windows 32ビット

OUD_HOME\config\EUS\ActiveDirectory\win\oidpwdcn.dllファイルをActive DirectoryのWINDOWS\system32ディレクトリにコピーします。

Windows 64ビット

OUD_HOME\config\EUS\ActiveDirectory\win64\oidpwdcn.dllファイルをActive DirectoryのWINDOWS\system64ディレクトリにコピーします。

2. regedt32またはregedt64を使用してレジストリを編集し、oidpwdcn.dllを有効にします。コマンド・プロンプトでregedt32と入力して、regedt32を起動します。

3. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\レジストリにあるNotification Packagesエントリの末尾にoidpwdcnを追加します。例:

RASSFM
KDCSVC
WDIGEST
scecli
oidpwdcn

それによって、パスワードDLLが有効化され、EUSで必要なパスワード検証がorclCommonAttribute属性に移入されます。

4. 変更したら、Active Directoryシステムを再起動します。

4. ldapmodifyを実行して、Active Directoryでの匿名ログインを許可します:

ldapmodify -h <ADhost> -p <AD port> -D <AD dirmgr> -w <pwd>
dn: cn=directory service,cn=windows nt,cn=services,cn=configuration,dc=example,dc=com
changetype: modify
replace: dsHeuristics
dsHeuristics: 0000002

注意:

dc=example,dc=comをActive DirectoryサーバーのDNに必ず置き換えてください。

5. すべてのActive Directoryユーザーのパスワードをリセットすることで、プラグインがパスワード変更を取得して、パスワード検証を生成および格納できるようにします。

6. 次の手順に従って、Active Directoryの設定を検証します:

1. Active Directoryユーザーのパスワードを変更します。

2. パスワードを変更したユーザーをActive Directoryで検索します。orclCommonAttribute属性に、生成されたハッシュ・パスワード値が含まれることを確認します。
この値は、Active DirectoryにorclCommonAttribute属性定義を追加します。

7. 「Oracle Unified Directoryでの統合の構成」で説明しているタスクを実行することによって、統合を完了します。

25.4.1.2 Oracle Directory Server Enterprise EditionのユーザーID

ユーザーIDがOracle Directory Server Enterprise Editionに格納されている場合に、Oracle Unified Directoryをエンタープライズ・ユーザー・セキュリティに統合する手順は次のとおりです:

1. Oracle Directory Server Enterprise Editionからldapmodifyコマンドを次のように実行して、アカウント・ロックの拡張操作を有効化します:

ldapmodify -h <ODSEE Server> -p <ODSEE port> -D <ODSEE Admin ID> -w <ODSEE Admin password>
dn: oid=1.3.6.1.4.1.42.2.27.9.6.25,cn=features,cn=config
changetype: add
objectclass: directoryServerFeature
oid: 1.3.6.1.4.1.42.2.27.9.6.25
cn: Password Policy Account Management

2. 「Oracle Unified Directoryでの統合の構成」で説明しているタスクを実行することによって、統合を完了します。

25.4.1.3 Novell eDirectoryのユーザーID

ユーザーIDがNovell eDirectoryに格納されている場合に、Oracle Unified Directoryをエンタープライズ・ユーザー・セキュリティに統合する手順は次のとおりです:

1. 統合用にNovell eDirectoryを構成するには、eDirectoryのユニバーサル・パスワードを有効化し、管理者がユーザー・パスワードを取得できるようにします。詳細は、Novell eDirectoryのパスワード管理に関するドキュメントを参照してください。

2. 「Oracle Unified Directoryでの統合の構成」で説明しているタスクを実行することによって、統合を完了します。

25.4.1.4 Oracle Unified DirectoryのユーザーID

別のOracle Unified Directoryをプロキシ・サーバーとして持つ外部ディレクトリ・サーバーとして、Oracle Unified Directoryインスタンスを構成できます。このシナリオでは、EUSの構成の詳細はOracle Unified Directoryプロキシ・サーバーにローカルで格納され、エンタープライズ・ユーザーとエンタープライズ・グループの詳細のみが外部Oracle Unified Directoryに格納されます。

このためには、dsconfigコマンドを次のように実行することによって、パスワード記憶スキームとしてSalted SHA-1を使用するようにデフォルトのパスワード・ポリシーを変更する必要があります:

dsconfig -h <OUD host> -p <OUD admin port> -D <OUD dirmgr> -j <pwdfile> -X -n set-password-policy-prop --policy-name "Default Password Policy" --set default-password-storage-scheme:"Salted SHA-1"

注意:

エンタープライズ・ユーザーとエンタープライズ・グループの詳細を格納するOracle Unified Directoryのデフォルトのパスワード・ポリシーを変更します。プロキシ・サーバーとして機能するOracle Unified Directoryインスタンスのデフォルトのパスワード・ポリシーは変更しないでください。

25.4.2 Oracle Unified Directoryでの統合の構成

次の手順に従って、Oracle Unified Directoryで外部LDAPディレクトリに関する構成を行います:

- Oracle Unified Directoryプロキシ・サーバーでのエンタープライズ・ユーザー・セキュリティの構成

- インストール後の構成手順の実行

- エンタープライズ・ユーザー・セキュリティに対応した、Oracle Unified Directoryプロキシ・サーバーの構成変更

25.4.2.1 Oracle Unified Directoryプロキシ・サーバーでのエンタープライズ・ユーザー・セキュリティの構成

Oracle Unified Directoryプロキシ・サーバーでEUSの構成を行うには、次のいずれかのオプションを使用します:

- プロキシ・サーバーのインストール時のエンタープライズ・ユーザー・セキュリティの有効化

- 既存のプロキシ・サーバー・インスタンスでのエンタープライズ・ユーザー・セキュリティの有効化

注意:

- インストール時にEUSを有効にするには、「プロキシ・サーバーのインストール時のエンタープライズ・ユーザー・セキュリティの有効化」で説明している手順を実行します。

- 既存のOracle Unified DirectoryインスタンスでEUSを構成するには、「既存のプロキシ・サーバー・インスタンスでのエンタープライズ・ユーザー・セキュリティの有効化」で説明している手順を実行します。

25.4.2.1.1 プロキシ・サーバーのインストール時のエンタープライズ・ユーザー・セキュリティの有効化

Oracle Unified Directoryディレクトリ・サーバー・インスタンスの設定時に、そのサーバー・インスタンスとEUSとの統合を有効化できます。この手順は、Oracle Fusion Middleware Oracle Unified Directoryインストレーション・ガイドのプロキシ・サーバーの設定に関する項の説明に従ってください。

注意:

- oud-proxy-setupのグラフィカル・インタフェース・オプションの実行時に「デプロイメント・オプション」画面で「EUSを構成します」を選択します。または、--cliオプションを指定してoud-proxy-setupを実行する場合は、インストーラの起動時に次のオプションを指定します:

oud-proxy-setup --eusContext {namingContext}

- --cliオプションを指定してoud-proxy-setupを実行する場合は、dsconfigを使用して、LDAPサーバー拡張、プロキシ・ワークフロー要素およびEUSワークフロー要素を手動で構成する必要があります。グラフィカル・インタフェースでは、これらは自動構成されます。

- Novell eDirectoryの場合は、Oracle Unified Directoryプロキシ・サーバーのLDAPSポートを入力します。

25.4.2.1.2 既存のプロキシ・サーバー・インスタンスでのエンタープライズ・ユーザー・セキュリティの有効化

既存のOracle Unified Directoryプロキシ・サーバー・インスタンスでエンタープライズ・ユーザー・セキュリティの構成を行う手順は次のとおりです:

1. SSLが有効化されたLDAP接続ハンドラがサーバー・インスタンスに存在することを確認します。
SSLが有効になっていない場合は、第14.2項「Oracle Directory Services Managerを使用したサーバー構成の管理」で説明している手順に従ってLDAPS接続を追加します。

2. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからプロキシ・サーバーに接続します。

3. 「ホーム」タブを選択します。

4. 「構成」メニューで、「リモートEUSネーミング・コンテキストの作成」を選択します。
「リモートEUSネーミング・コンテキストの作成」ウィンドウが表示されます。

5. 次の詳細を入力します:

- ベースDN: 接尾辞の名前を入力します。

- ネットワーク・グループ: 接尾辞にアタッチするネットワーク・グループを選択します。

- サーバー・タイプ: EUSユーザー・エントリを格納するサーバーを選択します。

- ホスト名: リモート・サーバーのホスト名を入力します。

- 使用可能なポート: リモート・サーバーのLDAPポート、LDAPSポートまたはLDAPポートとLDAPSポートを入力します。

注意:

Novell eDirectoryの場合は、Oracle Unified Directoryプロキシ・サーバーのLDAPSポートを入力します。

- すべて信頼: リモート・サーバーが提示するすべての証明書を信頼する場合は、このチェック・ボックスを選択します。

- 信頼マネージャ: サーバーがリクエストを転送するためにリモート・サーバーのLDAPSポートに接続するときに使用する信頼マネージャを選択します。

6. 「作成」をクリックします。
次の確認メッセージが表示されます:

構成が正常に作成されました。

25.4.2.2 インストール後の構成手順の実行

第25.4.2.1項「Oracle Unified Directoryプロキシ・サーバーでのエンタープライズ・ユーザー・セキュリティの構成」の説明に従って必要な構成を完了した後は、次の操作を実行する必要があります:

1. dsconfigコマンドを次のように実行して、外部LDAP準拠ディレクトリのプロキシ・ワークフロー要素、リモート・ルートDNおよびリモート・ユーザー・アカウントを構成します:

dsconfig set-workflow-element-prop \
--element-name proxy-we1 \
--set remote-root-dn:cn=administrator,cn=users,dc=example,dc=com \
--set remote-root-password:******** \
--hostname localhost \
--port 4444 \
--trustAll \
--bindDN cn=directory\ manager \
--bindPasswordFile pwd.txt \
--no-prompt

2. 外部LDAP準拠ディレクトリのプロキシ・ワークフロー要素の構成では、除外リスト、リモートldapサーバー・バインドdnおよびリモートldapサーバー・バインド・パスワードを定義することによって、use-client-identityを指定できます。EUSが有効化されている場合、データベースは自身の資格証明を使用して接続を行い、外部LDAPサーバー上で検索を実行します。DBエントリはOUDプロキシにローカルで格納され、外部LDAPサーバー上にはデータベース・エントリは存在しないため、代替IDを使用して外部LDAPサーバーへのバインドが行われます。

dsconfig set-workflow-element-prop \
--element-name proxy-we1 \
--add exclude-list:cn=directory\ manager \
--add exclude-list:cn=oraclecontext,dc=example,dc=com \
--set remote-ldap-server-bind-dn:cn=administrator,cn=users,dc=example,dc=com \
--set remote-ldap-server-bind-password:******** \
--hostname localhost \
--port 4444 \
--trustAll \
--bindDN cn=directory\ manager \
--bindPasswordFile pwd.txt \
--no-prompt

25.4.2.3 エンタープライズ・ユーザー・セキュリティに対応した、Oracle Unified Directoryプロキシ・サーバーの構成変更

OUDをEUS対応に設定した後は、次の手順に従ってOUD構成のレルム情報を更新する必要があります:

1. LDIFテンプレート・ファイル(install_dir/config/EUS/modifyRealm.ldif)を見つけます。

2. modifyRealm.ldifファイルを次のように編集します:

- dc=example,dc=comをサーバー・インスタンスの現在のネーミング・コンテキストに置き換えます。

- ou=peopleとou=groupsをDIT内のユーザー・エントリとグループ・エントリの現在の場所にそれぞれ置き換えます。

3. ldapmodifyコマンドを使用して、編集済のLDIFテンプレート・ファイルで構成を更新します。例:

$ ldapmodify -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -v -f modifyRealm.ldif

25.4.2.4 Oracle Unified Directoryプロキシ・サーバーに対応した、Oracle Databaseの構成

「Oracle Unified Directoryに対応した、Oracle Databaseの構成」の説明に従って、Oracle Databaseを構成する必要があります。

第V部

高度な管理: データ・レプリケーション、スキーマ管理および環境間の移行

この部では、データ・レプリケーションの構成、監視およびトラブルシューティングの方法、スキーマの管理方法、およびサーバー・インスタンスをテスト環境から本番環境に移行する方法について説明します。

次の章で構成されています:

- 第26章「ディレクトリ・データのレプリケーション」

- 第27章「ディレクトリ・スキーマの管理」

- 第28章「テスト環境から本番環境への移行」

26 ディレクトリ・データのレプリケーション

レプリケーションにより、同一データのコピーを複数のサーバーで使用できるようになります。Oracle Unified Directoryでは、マルチマスター・レプリケーション・モデルを採用しており、レプリケーション・トポロジ内の全サーバーが読取りおよび書込み操作を受け入れることができます。

マルチマスター・レプリケーション・モデルは、デフォルトではゆるやかな一貫性を持つモデルです。つまり、1つのサーバー上で加えられた変更がトポロジ内の他のサーバーに非同期的にレプリケートされます。このため、同一エントリが別々のサーバーで同時に変更される可能性があります。2つのサーバー間で更新が送信された場合、変更の競合を解決する必要があります。WANの各種属性(待機時間など)によってレプリケーションの競合が発生する可能性が高くなる場合があります。競合の解決は一般に自動的に行われます。一連の競合ルールによって、どの変更が優先されるかが決まります。場合によっては、手動で競合を解決する必要があります。

注意:

一部のデプロイメント・シナリオでは、デフォルトのゆるやかな一貫性モデルが不適なことがあります。このような場合は、レプリケーションを保証モードで動作するように構成できます。詳細は、第26.3.9項「保証レプリケーションの構成」を参照してください。

レプリケーションは必ず、保護された接続を介して行われます。レプリケーション・セッションの双方のサーバーは、SSL証明書を使用して相手側サーバーに対して認証される必要があります。アクセス制御や権限は強制されません。次の各項では、ディレクトリ・サーバーでレプリケーションを構成する方法について説明します。

レプリケーション・プロセスのメカニズムの詳細は、第6章「Oracle Unified Directoryレプリケーション・モデルの理解」を参照してください。

この章では、次のトピックを取り扱います:

- 第26.1項「dsreplicationによるデータ・レプリケーションの構成」

- 第26.2項「大規模なレプリケーション・トポロジの構成」

- 第26.3項「dsconfigによるレプリケーション構成の変更」

- 第26.4項「データによるレプリケート対象サーバーの初期化」

- 第26.5項「外部変更ログの使用」

- 第26.6項「スキーマ・レプリケーションの構成」

- 第26.7項「読取り専用サーバーへのレプリケーション」

- 第26.8項「レプリケーションの非一貫性の検出および解決」

- 第26.9項「履歴レプリケーション・データのパージ」

- 第26.10項「分離レプリカの使用」

- 第26.11項「Oracle Directory Server Enterprise EditionとOracle Unified Directory間のレプリケーション」

26.1 dsreplicationによるデータ・レプリケーションの構成

すべてのディレクトリ・サーバーを同じように構成する場合は、Oracle Unified Directoryの初回インストール時にグラフィカルな設定ユーティリティを使用してレプリケーションを設定できます。setupコマンドを使用してコマンドライン・モードでレプリケーションを構成することはできません。setupコマンドでディレクトリ・サーバーを設定する場合は、dsreplicationコマンドを使用してサーバー間のレプリケーションを構成する必要があります。

dsreplicationは、SSLを介して管理コネクタ経由でサーバー構成にアクセスします。詳細は、第14.3項「サーバーへの管理トラフィックの管理」を参照してください。

どのトポロジでも、レプリケーション・サーバーに障害が発生した場合の可用性を確保するために、2つのレプリケーション・サーバーが必要とされます。レプリケーション・サーバーは、環境内で発生したあらゆる変更を追跡する役割を担います。各レプリケーション・サーバーには、トポロジ内の他のレプリケーション・サーバーをすべて列挙したリストが格納されます。

この項の各例では、すでに2つのディレクトリ・サーバーがインストールされており、その一方にデータが移入されていることを前提としています。2つのディレクトリ・サーバーは同じホスト・マシン上にインストールできますが、その場合は別々のポート番号を割り当てる必要があります。

26.1.1 2つのサーバー間のレプリケーションを有効にするには

dsreplication enableコマンドのインスタンスを複数実行して、複数のサーバー間のレプリケーションを並列に設定することはできません。かわりに、トポロジ内のレプリケート対象サーバーの組ごとに逐次にdsreplication enableコマンドを実行してください。

レプリケーションを有効にするには、dsreplication enableコマンドを使用します。

次のコマンドは、host1とhost2という2つのディレクトリ・サーバー間で、"dc=example,dc=com"にあるデータのレプリケーションを有効にします。どちらのサーバーもデフォルトの管理ポート(4444)を使用します。このコマンドは、host1のポート8989にレプリケーション・サーバー・インスタンスを1つ作成し、host2のポート8989にもう1つレプリケーション・サーバー・インスタンスを作成します。

$ dsreplication enable
--host1 host1 --port1 4444 --bindDN1 "cn=Directory Manager" \
--bindPasswordFile1 pwd.txt --replicationPort1 8989 \
--host2 host2 --port2 4444 --bindDN2 "cn=Directory Manager" \
--bindPasswordFile2 pwd.txt --replicationPort2 8989 \
--adminUID admin --adminPasswordFile pwd.txt --baseDN "dc=example,dc=com" -X -n

--adminUIDオプションと--adminPasswordFileオプションは、 レプリケーション・ドメインのグローバル管理者を指します。詳細は、第23.6項「グローバル管理者の管理」を参照してください。-Xオプションは、すべてのサーバー証明書を信頼する必要があることを指定します。-n (--no-prompt)オプションは、このコマンドを非対話型モードで実行するように指定します。dsreplicationコマンドの全グローバル・オプションの詳細は、コマンドラインでdsreplication -helpと入力してください。

26.1.1.1 レプリケーション・サーバーの作成場所の制御

dsreplication enableを2つのサーバー間で使用すると、それぞれのホスト上でレプリケーション・サーバーが自動的に構成されます。レプリケーション・サーバーを各ホストに作成することなく、2つのディレクトリ・サーバー間のレプリケーションを構成する必要がある場合があります。--noReplicationServer1オプションまたは--noReplicationServer2オプションを使用すれば、追加のレプリケーション・サーバーを作成せずに、ディレクトリ・サーバーをトポロジに追加できます。シングル・ポイント障害を回避するために、レプリケートするトポロジ内にはレプリケーション・サーバーが少なくとも2つ必要であることに注意してください。

また、2つのサーバー間のレプリケーションを有効にし、一方のサーバーにのみレプリケーション・サーバー(ディレクトリ・サーバーではありません)を作成するようにも指定できます。これを実現するには、--onlyReplicationServer1オプションまたは--onlyReplicationServer2オプションを使用します。このオプションを指定すると、そのサーバーで変更ログとレプリケーション・ポートが構成されます。そのサーバーには、レプリケートされたデータは格納されません。

26.1.2 レプリケート対象サーバーを初期化するには

レプリケート対象サーバーを別のレプリケート対象サーバーのデータで初期化するには、dsreplication initializeコマンドを使用します。

次のコマンドは、host2のベースDN "dc=example,dc=com"を、host1に格納されているデータによって初期化します:

$ dsreplication initialize --baseDN "dc=example,dc=com" \
--adminUID admin --adminPasswordFile pwd.txt \
--hostSource host1 --portSource 4444 \
--hostDestination host2 --portDestination 4444 -X -n

26.1.3 トポロジ全体を初期化するには

トポロジに3つ以上のディレクトリ・サーバーがある場合は、dsreplication intialize-allコマンドを使用すると、すべてのレプリカを同時に初期化できます。

このコマンドはソース・ホストの詳細を引数としてとり、レプリケーションが有効になっている他のすべてのサーバーを初期化します。

次のコマンドは、レプリケーションが有効になっているすべてのサーバーを、host1のベースDN "dc=example,dc=com"のコンテンツで初期化します:

$ dsreplication initialize-all --hostname host1 --port 4444 \
--baseDN "dc=example,dc=com" --adminUID admin --adminPasswordFile pwd.txt

26.1.4 レプリケーションをテストするには

レプリケーションの動作をテストする最も簡単な方法は、1つのディレクトリ・サーバー上で変更を適用し、その変更が別のディレクトリ・サーバーにレプリケートされたことを確認するという方法です。前述の手順で設定したレプリケーション・トポロジをテストする手順は、次のとおりです:

1. ldapmodifyを使用して、host1上のエントリを変更します。

2. ldapsearchを使用して、その変更がhost2に伝播されていることを確認します。

26.1.5 レプリケート対象トポロジのステータスを取得するには

トポロジ内の任意のディレクトリ・サーバーの接続詳細を使用して、トポロジ全体のステータスを取得できます。

dsreplication statusコマンドを使用すると、トポロジ内のディレクトリ・サーバーのリストが表示され、サーバー間で未伝播の変更があれば一緒に表示されます。

次のコマンドは、前述の手順で設定したトポロジのステータスを表示します:

$ dsreplication status --adminUID admin --adminPasswordFile pwd.txt -X \
--hostname host1 --port 4444

26.1.6 既存の2つのレプリケート対象トポロジをマージするには

2つのレプリケート対象トポロジをマージするには、各トポロジの1つのサーバー同士のレプリケーションを有効にします。

次の制限に注意してください:

- このマージの実行時には、両方のトポロジ内のサーバーがすべて起動され実行されている必要があります。
いずれかのサーバーがオフラインである場合、dsreplicationではその構成を更新できません。マージの実行時にオフラインであったサーバーが再びオンラインになっても、このサーバーにもう一方のトポロジ内のレプリケーション・サーバーへの参照が追加されることはありません。

- ドメインIDまたはレプリケーション・サーバーIDが2つのトポロジ間で競合している場合は、マージを実行できません。
つまり、トポロジAのサーバーがトポロジBのサーバーと同じレプリケーション・サーバーIDやドメインIDを持つことはできません。

IDが競合している場合は、最初のサーバー(--host1)のIDを使用して競合が解消されます。その後、--host1と同じトポロジに属すサーバーをソースとして使用して、最新の状態でないサーバーをすべて再初期化する必要があります。

- 両方のレプリケーション・トポロジで同一のグローバル管理者が定義されている必要があります。

1. 2つのレプリケート対象トポロジをマージするには、dsreplication enableコマンドを使用します。
たとえば、レプリケート対象トポロジ(トポロジA)にはhost1、host2およびhost3が属しており、レプリケート対象トポロジ(トポロジB)にはhost4、host5およびhost6が属している場合、次のコマンドはこの2つのトポロジを効果的にマージします:

$ dsreplication enable \
--host1 host1 --port1 4444 --bindDN1 "cn=Directory Manager" \
--bindPasswordFile1 pwd.txt --replicationPort1 8989 \
--host2 host4 --port2 4444 --bindDN2 "cn=Directory Manager" \
--bindPasswordFile2 pwd.txt --replicationPort2 8989 \
--adminUID admin --adminPasswordFile pwd.txt --baseDN "dc=example,dc=com" \
-X -n

この例では、host1とhost4の両ホストにディレクトリ・サーバーとレプリケーション・サーバーが1つずつ含まれていると仮定しています。含まれていない場合は、ディレクトリ・サーバーまたはレプリケーション・サーバーが自動的に構成されます。

2. 高可用性を確保するには、マージ時にオフラインまたは使用不可であったすべてのサーバーに対して、次の手順を実行する必要があります:

1. dsreplication enableを使用して、接尾辞cn=admin dataのコンテンツを初期化します。
マージ時に使用可能であったサーバーの1つを使用して個別にサーバーを初期化することも、dsreplication initialize-allを使用することもできます。

2. dsconfigコマンドを使用してレプリケーション・サーバーのリストを更新します。

26.1.7 特定のレプリケーション・ドメインに対してレプリケーションを無効にするには

1. 特定のドメインでのレプリケーションを無効にするには、dsreplication disableコマンドを使用します。
次のコマンドは、"dc=example,dc=com"にあるデータのレプリケーションを無効にします。

$ dsreplication disable --hostname host1 --port 4444 --adminUID admin \
--adminPasswordFile pwd.txt --baseDN "dc=example,dc=com" -X -n

このコマンドは、そのドメインのディレクトリ・サーバーからレプリケーション構成を削除します。無効にするドメインがこのディレクトリ・サーバー・インスタンス上でレプリケートされている唯一のドメインである場合は、このインスタンス上のレプリケーション・サーバーも無効になります。レプリケーション・サーバーが無効になると、そのレプリケーション・サーバーに接続していた他のディレクトリ・サーバーは切断され、トポロジ内の別のレプリケーション・サーバーに自動的に再接続します。

2. レプリケーション・サーバー自体を(変更ログとレプリケーション・ポートを含めて)無効にするには、次のコマンドを使用します:

$ dsreplication disable --hostname host1 --port 4444 -X -n \
--adminUID admin --adminPasswordFile pwd.txt --baseDN "dc=example,dc=com" \
--disableReplicationServer

レプリケーション・サーバーが無効になると、そのレプリケーション・サーバーに接続していた他のディレクトリ・サーバーは切断され、トポロジ内の別のレプリケーション・サーバーに自動的に再接続します。

26.1.7.1 レプリケーション・サーバーの無効化に関する注意

レプリケーション・サーバーを無効にすると、レプリケーション構成が削除されますが、レプリケーション・サーバーのデータベースは削除されません。したがって、レプリケーション・サーバーを誤って無効にしてしまった場合には、レプリケーションの変更記録を取得できます。この接尾辞でのレプリケーションを再度有効にする必要がなければ、レプリケーション・サーバーのデータベースを手動で削除してください(例: $rm changelogDB/*)。

レプリケーションを無効にして再度有効にした場合、その間にそのサーバーで行われた変更はレプリケートされません。このため、レプリケーションを無効にした期間中はそのサーバーでの変更を禁止するか、変更が発生した場合には、そのサーバーからトポロジ内の残りの各サーバーを再同期する必要があります。

26.2 大規模なレプリケーション・トポロジの構成

特に大規模なトポロジでは、専用のレプリケーション・サーバー(ディレクトリ・サーバーを含まないサーバー)と専用のディレクトリ・サーバー(レプリケーション・サーバーを含まないサーバー)を構成する方が簡単な場合が多くあります。

専用ディレクトリ・サーバーにはレプリケート対象データが格納されますが、レプリケート対象データへの変更を記録した変更ログは格納されません。また、専用ディレクトリ・サーバーはレプリケーション・ポートも構成されません。専用レプリケーション・サーバーは、レプリケーション・ポートが構成されます。専用レプリケーション・サーバーにはレプリケート対象データは格納されませんが、トポロジ内の他のサーバーでレプリケート対象データに加えられた変更を記録した変更ログが格納されます。

注意:

シングル・ポイント障害を回避するために、どのトポロジにも少なくとも2つのレプリケーション・サーバーが必要です。

詳細およびトポロジの例は、第2章「ディレクトリ・サーバーを使用するデプロイメントの例」を参照してください。

次の図に、1台の専用レプリケーション・サーバー(レプリケーション・サーバー2)、4台の専用ディレクトリ・サーバー、およびレプリケーション・サーバーとディレクトリ・サーバーを兼ねた1台のサーバー(ホスト1)からなる大規模なレプリケーション・トポロジを示します。

図26-1 大規模なレプリケーション・トポロジ

26.2.1 専用レプリケーション・サーバーを構成するには

専用レプリケーション・サーバーを構成するには、2つのサーバー間のレプリケーションを有効にするときに--onlyReplicationServer1オプションまたは--onlyReplicationServer2オプションを指定します。

次の例では、前掲の図に示したディレクトリ・サーバーCとレプリケーション・サーバー2の間のレプリケーションを構成します。

$ dsreplication enable \
--host1 host3 --port1 4444 --bindDN1 "cn=Directory Manager" \
--bindPasswordFile1 pwd.txt --noReplicationServer1 \
--host2 host4 --port2 4444 --bindDN2 "cn=Directory Manager" \
--bindPasswordFile2 pwd.txt --onlyReplicationServer2 \
--replicationPort2 8989 --adminUID admin --adminPasswordFile pwd.txt \
--baseDN "dc=example,dc=com" -X -n

26.3 dsconfigによるレプリケーション構成の変更

この項では、dsconfigコマンドを使用してレプリケーション構成のいくつかの拡張プロパティを変更する方法について説明します。通常、拡張プロパティはオプションです。または、ほとんどの場合に適したデフォルト値が割り当てられています。dsconfigの使用方法の詳細は、第14.1項「dsconfigを使用したサーバー構成の管理」を参照してください。

dsconfigは、ディレクトリ・サーバー間のレプリケーションの設定には使用できません。レプリケーションの設定は、GUIインストール・ユーティリティを使用して自動的に行うか、dsreplicationコマンドを使用して手動で行います。詳細は、第26.1項「dsreplicationによるデータ・レプリケーションの構成」を参照してください。

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

- 第26.3.1項「レプリケーション・ドメイン名の取得」

- 第26.3.2項「レプリケーション・パージ遅延の変更」

- 第26.3.3項「ウィンドウ・サイズの変更」

- 第26.3.4項「初期化ウィンドウ・サイズの変更」

- 第26.3.5項「ハートビート間隔の変更」

- 第26.3.6項「分離ポリシーの変更」

- 第26.3.7項「暗号化レプリケーションの構成」

- 第26.3.8項「レプリケーション・グループの構成」

- 第26.3.9項「保証レプリケーションの構成」

- 第26.3.10項「部分レプリケーションの構成」

- 第26.3.11項「レプリケーション・ステータスの構成」

- 第26.3.12項「レプリケーション・サーバーの重みの構成」

26.3.1 レプリケーション・ドメイン名の取得

レプリケーション・ドメイン名はディレクトリ・サーバーによって生成されます。この名前にはベースDNと一意の数値識別子が含まれています。

構成されているレプリケーション・ドメインのリストを取得するには、list-replication-domainsサブコマンドを使用します。例:

$ dsconfig -h host1 -p 4444 -D "cn=directory manager" -j pwd-file -n list-replication-domains \
--provider-name "Multimaster Synchronization"

Replication Domain : Type    : server-id : replication-server     : base-dn
-------------------:---------:-----------:------------------------:--------------------
cn=admin data      : generic : 13981     : host1:8989, host2:8989 : cn=admin data
cn=schema          : generic : 20284     : host1:8989, host2:8989 : cn=schema
dc=example,dc=com  : generic : 26560     : host1:8989, host2:8989 : "dc=example,dc=com"

26.3.2 レプリケーション・パージ遅延の変更

レプリケーション変更データベースは、レプリケートが完了した更新またはレプリケートが完了していない更新の記録を保持しています。レプリケーション・パージ遅延はレプリケーション・サーバーのプロパティで、レプリケーション変更データベースに対して内部パージ操作を実行するまでの期間を指定します。

26.3.2.1 レプリケーション変更記録のパージ動作

パージ遅延の期間を過ぎた変更記録は、すでに適用されたかどうかに関係なく、レプリケーション変更データベースから削除されます。デフォルトのパージ遅延は1日です。レプリケーション変更データベースのバックアップ間隔がこのパージ遅延の期間より短いと、変更データベースがバックアップされる前に変更記録がクリアされてしまいます。したがって、バックアップからデータをリストアしても、変更記録が失われる可能性があります。

26.3.2.2 レプリケーション・パージ遅延を変更するには

1. レプリケーション・パージ遅延の現在値を表示します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
get-replication-server-prop \
--provider-name "Multimaster Synchronization" --advanced \
--property replication-purge-delay

Property                : Value(s)
------------------------:---------
replication-purge-delay : 1 d

2. パージ遅延を変更します。
次のコマンドは、パージ遅延を1週間に変更します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
set-replication-server-prop \
--provider-name "Multimaster Synchronization" \
--set replication-purge-delay:1w

26.3.3 ウィンドウ・サイズの変更

ウィンドウ・サイズはレプリケーション・サーバーのプロパティで、レプリケーション・サーバーがディレクトリ・サーバーからの確認応答を待たずにディレクトリ・サーバーに送信できる変更リクエストの数を指定します。

ウィンドウ・サイズは、ディレクトリ・サーバーからの即時の確認応答なしに送信できる更新メッセージの最大数を表します。各メッセージ後の確認応答を待たずに、素早く連続して多くのメッセージを送信する方が効率的です。適切なウィンドウ・サイズを使用することで、レプリケーション・サーバーが確認応答の到着を待つために費やす時間を排除できます。デフォルトのウィンドウ・サイズは100です。一部のディレクトリ・サーバーで変更のレプリケーションが遅れていることに気付いた場合は、他の調整を行う前に、ウィンドウ・サイズの値を大きくしてレプリケーション・パフォーマンスをもう一度確認してください。

26.3.3.1 ウィンドウ・サイズを変更するには

1. ウィンドウ・サイズの現在値を表示します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
get-replication-server-prop --provider-name "Multimaster Synchronization" \
--advanced --property window-size

Property    : Value(s)
------------:---------
window-size : 100

2. ウィンドウ・サイズを変更します。
次のコマンドは、ウィンドウ・サイズを200に変更します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
set-replication-server-prop \
--provider-name "Multimaster Synchronization" --set window-size:200

26.3.4 初期化ウィンドウ・サイズの変更

レプリケート対象トポロジ内でのデータ・インポート時に、インポート側のサーバーが遅すぎてエクスポート側のサーバーから送信されるデータについていけないことがあります。このような場合、インポート側サーバーはインポートを妨げるだけでなく、エクスポート側サーバーによる他のレプリケーション変更記録の伝播まで妨げるおそれがあります。

初期化ウィンドウ・サイズを使用することで、エクスポート側サーバーは最も遅いインポート側サーバーからの確認応答を検出し、その遅いインポート側サーバーが受信可能な状態のときのみデータをレプリケーション・ネットワーク上に送信することが可能になります。

デフォルトでは、初期化ウィンドウ・サイズは100です。トポロジ内に遅いサーバーがない場合は、初期化ウィンドウ・サイズを大きくできます。これにより、エクスポート側サーバーがより多くの更新を、確認応答を待たずに送信できるようになります。トポロジ内に非常に遅いサーバーがある場合は、初期化ウィンドウ・サイズを小さくすることで、そのサーバーがレプリケーションを妨げないようにできます。

26.3.4.1 初期化ウィンドウ・サイズを変更するには

1. 初期化ウィンドウ・サイズの現在値を表示します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
get-replication-domain-prop --provider-name "Multimaster Synchronization" \
--domain-name dc=example,dc=com --advanced --property initialization-window-size
Property                   : Value(s)
---------------------------:---------
initialization-window-size : 100

2. 初期化ウィンドウ・サイズを変更します。
次のコマンドは、初期化ウィンドウ・サイズを50に変更します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
set-replication-domain-prop --provider-name "Multimaster Synchronization" \
--domain-name dc=example,dc=com --set initialization-window-size:50

26.3.5 ハートビート間隔の変更

ハートビート間隔はレプリケーション・ドメインのプロパティで、レプリケーション・ドメインがレプリケーション・サーバーと通信する間隔を指定します。レプリケーション・ドメインは、レプリケーション・サーバーからこの間隔で定期的にハートビートが届くのを待ちます。ハートビートが受信されない場合、ドメインはその接続を閉じ、トポロジ内の別のレプリケーション・サーバーに接続します。

デフォルトのハートビート間隔は10秒です。応答が遅いWANまたはネットワーク上でレプリケーションを実行している場合は、ハートビート間隔を長くできます。また、次のようなエラーがログに記録されている場合は、おそらくハートビート間隔を長くする必要があります。

[26/May/2011:16:32:50 +0200] category=SYNC severity=NOTICE msgID=15138913
msg=Replication Heartbeat Monitor on RS rserver/192.157.197.62:8989 30382 for
dc=example,dc=com in DS 10879 is closing the session because it could not
detect a heartbeat

ハートビート間隔はJVMの設定に影響されます。ハートビート間隔をデフォルトより短くする必要がある場合は、必ずJVMの-XX:+UseConcMarkSweepGCオプションを設定して、ガベージ・コレクション中の一時停止時間を短くしてください。詳細は、Oracle Fusion Middleware Oracle Unified Directoryインストレーション・ガイドのJVM、Javaオプションおよびデータベース・キャッシュの構成に関する項を参照してください。

26.3.5.1 ハートビート間隔を変更するには

1. ハートビート間隔の現在値を表示します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
get-replication-domain-prop \
--provider-name "Multimaster Synchronization" \
--domain-name "dc=example,dc=com (domain 15853)" --advanced \
--property heartbeat-interval
Property           : Value(s)
-------------------:---------
heartbeat-interval : 10 s

2. ハートビート間隔を変更します。
次のコマンドは、ハートビート間隔を5秒に変更します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
set-replication-domain-prop \
--provider-name "Multimaster Synchronization" \
--domain-name "dc=example,dc=com (domain 15853)" --set heartbeat-interval:5s

26.3.6 分離ポリシーの変更

分離ポリシーはレプリケーション・ドメインのプロパティです。このプロパティは、レプリケーションが構成されているのに、更新の受信時にレプリケーション・サーバーが1つも起動および実行されていない場合のディレクトリ・サーバーの動作を指定します。この場合のディレクトリ・サーバーのデフォルト動作は、すべての更新を拒否するというものです。

26.3.6.1 分離ポリシーを変更するには

1. 現在の分離ポリシーを表示します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file \
get-replication-domain-prop \
--provider-name "Multimaster Synchronization" \
--domain-name "dc=example,dc=com (domain 15853)" \
--advanced --property isolation-policy -n

Property         : Value(s)
-----------------:-------------------
isolation-policy : reject-all-updates

2. 分離ポリシーを変更します。
次のコマンドは、このような場合にディレクトリ・サーバーがすべての更新を受け入れるように指定します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file \
set-replication-domain-prop \
--provider-name "Multimaster Synchronization" \
--domain-name "dc=example,dc=com (domain 15853)" \
--set isolation-policy:accept-all-updates -n

26.3.7 暗号化レプリケーションの構成

デフォルトでは、レプリケーションの通信は暗号化されません。暗号化を有効にするには、dsconfigコマンドを使用して暗号化マネージャのプロパティを設定します。

次のコマンドは、レプリケーションの通信を暗号化するように指定します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
set-crypto-manager-prop --set ssl-encryption:true

26.3.8 レプリケーション・グループの構成

レプリケーション・グループは、マルチデータ・センター・デプロイメントおよび障害回復シナリオをサポートする場合に設計します。ディレクトリ・サーバーにおけるレプリケーション・グループの設計と実装の詳細は、第6.6項「レプリケーション・グループ」を参照してください。

注意:

レプリケーション・グループの構成を変更すると、保証レプリケーションに影響します。詳細は、第6.7項「保証レプリケーション」を参照してください。

26.3.8.1 レプリケーション・グループを構成するには

レプリケーション・グループの構成は、同じグループに所属させる個々のディレクトリ・サーバーおよびレプリケーション・サーバーで行います。ディレクトリ・サーバーでは、レプリケート対象ドメインごとにレプリケーション・グループを構成します。レプリケーション・サーバーでは、レプリケーション・サーバー全体に対してグループを構成します。

レプリケーション・グループを構成するには、それぞれのレプリケート対象ドメインとレプリケーション・サーバーに同じグループIDを割り当てます。次の例では、レプリケート対象ドメインdc=example,dc=comに対してレプリケーション・グループ(1)を構成します。

1. このグループに所属させる各ディレクトリ・サーバーで、ドメインdc=example,dc=comに対してグループIDを設定します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
set-replication-domain-prop \
--provider-name "Multimaster Synchronization" \
--domain-name "dc=example,dc=com (domain 10233)" --advanced \
--set group-id:1

2. このグループに所属させる各レプリケーション・サーバーで、グループIDを設定します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
set-replication-server-prop \
--provider-name "Multimaster Synchronization" --advanced \
--set group-id:1

26.3.9 保証レプリケーションの構成

ほとんどのデプロイメント・シナリオでは、ゆるやかな一貫性を持つマルチマスター・レプリケーション・モデルで十分です。しかし、シナリオによっては、レプリカ間のより厳格な一貫性が必要とされる場合もあります。このような場合は、保証レプリケーションを構成できます。保証レプリケーションには、次の利点があります:

- データの高可用性。サーバーが変更を受信した直後にクラッシュした場合、変更がトポロジ内の他のサーバーにレプリケートされる前に失われるおそれがあります。保証レプリケーションでは、確認応答がクライアント・アプリケーションへ送信される前に、すべての変更がトポロジ内の他のサーバーにレプリケートされます。したがって、サーバーがクラッシュした場合にデータが失われる危険性が最小限に抑えられます。

- 即時のデータ可用性。アプリケーションによっては、変更が行われた直後にその変更がトポロジ内の他のサーバーで使用できるようになることが必要な場合があります。

保証レプリケーションはレプリケーション・プロトコルの拡張であり、レプリケート対象ドメイン単位で構成されます。詳細は、第26.3.1項「レプリケーション・ドメイン名の取得」を参照してください。

保証レプリケーションは、同期レプリケーションとは異なります。つまり、トポロジ内のすべてのサーバーで同時に変更が行われるわけではありません。ただし、LDAPクライアントに関するかぎり、保証レプリケーションは同期レプリケーションの機能をある程度まで模倣します。変更がトポロジ内の他のサーバーに伝播されるまで、クライアント・アプリケーションへの確認応答を遅らせることによって、これを実現しています。

注意:

保証レプリケーションは、レプリケーション・グループに依存しています。1つの保証レプリケーション構成で連動するすべてのレプリケーション・サーバーおよびディレクトリ・サーバーが同じレプリケーション・グループに属している必要があります。

保証レプリケーションには次の2つの動作モードがあります:

- 安全データ・モード。更新が正常に完了したという確認応答をクライアントが受信する前に、定義した数のレプリケーション・サーバーへ更新を伝播させる必要があります。
伝播が必須であるレプリケーション・サーバーの数によって安全データ・レベルが既定されます。安全データ・レベルが高ければ高いほど、全体のデータ可用性が高まります。

- 安全読取りモード。更新が正常に完了したという確認応答をクライアントが受信する前に、トポロジ内のすべてのディレクトリ・サーバーへ更新を伝播させる必要があります。

安全データ・モードでも安全読取りモードでも、トポロジ内のいくつかのサーバーが使用不可である場合にLDAPクライアント・コールがハングしないように、タイムアウト間隔を設定できます。

- 各ディレクトリ・サーバーでは、ディレクトリ・サーバーがレプリケーション・サーバーに安全データ・モードまたは安全読取りモードで更新を送信すると有効になるグローバル・タイムアウトを構成できます。このタイムアウトに達すると、LDAPクライアント・コールは即座に復帰し、このイベントを追跡するためのメッセージがレプリケーション・ログに書き込まれます。

- 各レプリケーション・サーバーでは、レプリケーション・サーバーがピアのレプリケーション・サーバーまたは別のディレクトリ・サーバーに安全データ・モードまたは安全読取りモードで更新を送信すると有効になるグローバル・タイムアウトを構成できます。このタイムアウトに達すると、開始サーバー(ディレクトリ・サーバーまたはレプリケーション・サーバー)に返される確認応答メッセージに、タイムアウトを示すメッセージが挿入されます。すると、開始ディレクトリ・サーバーは、その更新に対してタイムアウトが発生したというメッセージをログに書き込みます。

注意:

ほとんどのデプロイメントでは、デフォルトのタイムアウトで問題ありません。ディレクトリ・サーバーは2秒、レプリケーション・サーバーは1秒です。タイムアウトを変更するのは、ログにタイムアウトが記録されており、かつタイムアウトの変更が及ぼす影響を完全に理解している場合のみです。更新がフル・パスを経由して目的のサーバーに届くまでにかかる時間を見越して、タイムアウト値に反映させる必要があります。

ディレクトリ・サーバーのタイムアウト値は、レプリケーション・サーバーの値より必ず大きくしてください。例: DS1(タイムアウト2秒)→RS1(タイムアウト1秒)→RS2(タイムアウト1秒)→DS2

保証レプリケーションのメカニズムと様々な構成オプションの詳細は、第6.7項「保証レプリケーション」を参照してください。

26.3.9.1 安全データ・モードの保証レプリケーションを構成するには

この手順では、トポロジに対して安全データ・モードの保証レプリケーションを構成します。ここでは、レプリケーションがすでに構成されていることを前提としています。

1. トポロジ内の各ディレクトリ・サーバーで次の操作を行います:

1. 保証レプリケーションのモードを設定します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
set-replication-domain-prop \
--provider-name "Multimaster Synchronization" \
--domain-name "dc=example,dc=com (domain 10233)" --advanced \
--set assured-type:safe-data

2. 安全データ・レベルを設定します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
set-replication-domain-prop \
--provider-name "Multimaster Synchronization" \
--domain-name "dc=example,dc=com (domain 10233)" --advanced \
--set assured-sd-level:2

setupまたはdsreplicationを使用してレプリケーションを構成した場合は、レプリケーション・サーバーおよびディレクトリ・サーバーが同一の仮想マシン上に存在します。この場合は、安全データ・レベルを2以上に設定してください。

3. 保証レプリケーションのタイムアウトを設定します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
set-replication-domain-prop \
--provider-name "Multimaster Synchronization" \
--domain-name "dc=example,dc=com (domain 10233)" --advanced\
--set assured-timeout:5s

タイムアウトを変更するのは、ログにタイムアウトが記録されており、かつタイムアウトの変更が及ぼす影響を完全に理解している場合のみです。

4. ディレクトリ・サーバーのグループIDを確認します。
これは、このレプリケーション・グループを構成するすべてのレプリケーション・サーバーおよびディレクトリ・サーバーで同一である必要があります。グループIDを構成する手順は、第26.3.8項「レプリケーション・グループの構成」を参照してください。

5. 保証レプリケーションの現在の構成を表示します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
get-replication-domain-prop \
--provider-name "Multimaster Synchronization" \
--domain-name "dc=example,dc=com (domain 10233)" --advanced \
--property assured-type --property assured-sd-level --property assured-timeout

Property         : Value(s)
-----------------:------------
assured-sd-level : 2
assured-timeout  : 5 s
assured-type     : safe-data

2. トポロジ内の各レプリケーション・サーバーで次の操作を行います:

1. 保証レプリケーションの現在の構成を表示します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
get-replication-server-prop \
--provider-name "Multimaster Synchronization" --advanced \
--property assured-timeout --property group-id

Property                  : Value(s)
--------------------------:---------
assured-timeout           : 1 s
group-id                  : 1

2. 保証レプリケーションのタイムアウトを設定します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
set-replication-server-prop \
--provider-name "Multimaster Synchronization" --advanced \
--set assured-timeout:5s

タイムアウトを変更するのは、ログにタイムアウトが記録されており、かつタイムアウトの変更が及ぼす影響を完全に理解している場合のみです。

3. レプリケーション・サーバーのグループIDを確認します。
これは、このレプリケーション・グループを構成するすべてのレプリケーション・サーバーおよびディレクトリ・サーバーで同一である必要があります。グループIDを構成する手順は、第26.3.8項「レプリケーション・グループの構成」を参照してください。

26.3.9.2 安全読取りモードの保証レプリケーションを構成するには

保証レプリケーションは、レプリケート対象ドメインごとに構成します。この手順では、トポロジに対して安全読取りモードの保証レプリケーションを構成します。ここでは、レプリケーションがすでに構成されていることを前提としています。

1. トポロジ内の各ディレクトリ・サーバーで次の操作を行います:

1. 保証レプリケーションのモードを設定します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
set-replication-domain-prop \
--provider-name "Multimaster Synchronization" \
--domain-name "dc=example,dc=com (domain 10233)" --advanced \
--set assured-type:safe-read

2. 保証レプリケーションのタイムアウトを設定します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
set-replication-domain-prop \
--provider-name "Multimaster Synchronization" \
--domain-name "dc=example,dc=com (domain 10233)" --advanced \
--set assured-timeout:5s

タイムアウトを変更するのは、ログにタイムアウトが記録されており、かつタイムアウトの変更が及ぼす影響を完全に理解している場合のみです。

3. ディレクトリ・サーバーのグループIDを確認します。
これは、このレプリケーション・グループを構成するすべてのレプリケーション・サーバーおよびディレクトリ・サーバーで同一である必要があります。グループIDを構成する手順は、第26.3.8項「レプリケーション・グループの構成」を参照してください。グループと保証レプリケーションの詳細は、第6.7項「保証レプリケーション」を参照してください。

4. 保証レプリケーションの現在の構成を表示します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
get-replication-domain-prop \
--provider-name "Multimaster Synchronization" \
--domain-name "dc=example,dc=com (domain 10233)" --advanced \
--property assured-type --property assured-timeout --property group-id

Property         : Value(s)
-----------------:------------
assured-timeout  : 5 s
assured-type     : safe-read
group-id         : 1

2. トポロジ内の各レプリケーション・サーバーで次の操作を行います:

1. 保証レプリケーションの現在の構成を表示します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
get-replication-server-prop \
--provider-name "Multimaster Synchronization" --advanced \
--property assured-timeout --property degraded-status-threshold \
--property group-id

Property                  : Value(s)
--------------------------:---------
assured-timeout           : 1 s
degraded-status-threshold : 5000
group-id                  : 1

2. 保証レプリケーションのタイムアウトを設定します。
タイムアウトを変更するのは、ログにタイムアウトが記録されており、かつタイムアウトの変更が及ぼす影響を完全に理解している場合のみです。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
set-replication-server-prop \
--provider-name "Multimaster Synchronization" --advanced \
--set assured-timeout:5s

3. 機能低下ステータスのしきい値を設定します。
機能低下ステータスのしきい値では、そのディレクトリ・サーバーに対するレプリケーション・サーバーのキューに入っている更新の数に基づいて、サーバーを「遅すぎる」と判断する段階を定義します。詳細は、第6.5.2項「低下ステータス」を参照してください。

ログにタイムアウトが記録されていないかぎり、この値は調整しないでください。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
set-replication-server-prop \
--provider-name "Multimaster Synchronization" --advanced \
--set degraded-status-threshold:2000

4. レプリケーション・サーバーのグループIDを確認します。
これは、このレプリケーション・グループを構成するすべてのレプリケーション・サーバーおよびディレクトリ・サーバーで同一である必要があります。グループIDを構成する手順は、第26.3.8項「レプリケーション・グループの構成」を参照してください。グループと保証レプリケーションの詳細は、第6.7項「保証レプリケーション」を参照してください。

26.3.10 部分レプリケーションの構成

部分レプリケーションでは、ディレクトリ・データの特定部分をトポロジ内の他のレプリカにレプリケートできます。この機能は、次のシナリオで特に有効です:

- ディスク領域が限られている場合。レプリケートするデータを限定することで、特定のレプリカで必要とされるディスク領域の量を大幅に低減できます。特に、データ量が大きいjpeg写真などの属性のレプリケーションを制限すると効果的です。

- セキュリティ上の問題。ユーザー・パスワードなどのデータは機密性が高く、一部のレプリカでは不要なことがあります。特に、それらのレプリカで不正アクセスの危険性があるような場合です。

この項では、トポロジ内の1つ以上のサーバーで部分レプリケーションを構成する手順について説明します。部分レプリケーション・メカニズムのアーキテクチャの詳細は、第6.8項「部分レプリケーション」を参照してください。

部分レプリケーションの構成は、部分データを受け取るディレクトリ・サーバー上で、属性ベースで行います。次の図を参照してください:

ディレクトリ・サーバーBで部分レプリケーションが構成されています。ldapmodify操作がディレクトリ・サーバーAに送信されます。この操作全体がレプリケーション・サーバー1、レプリケーション・サーバー2、ディレクトリ・サーバーBの順に転送されていきます。この操作がディレクトリ・サーバーBでレプリケートされるとき、このサーバーの部分レプリケーション構成に基づいて、操作の一部の属性が排除されます。

部分レプリカは、クライアント・アプリケーションから直接書込み可能です。ただし、禁止された属性を含む追加操作や変更操作が部分レプリカに対して試行された場合、その操作は拒否され、サーバーが「実行要求を拒否」エラーを返します。

部分レプリケーションは、次の2つのうちいずれかのモードで構成できます:

- 排他モード。このモードでは、fractional-excludeという複数値属性を使用して指定した属性を、受信したLDAP追加操作または変更操作から排除します。
除外する属性は、オブジェクト・クラスのオプション属性であることが必要です。

- 包含モード。このモードでは、fractional-includeという複数値属性を使用して指定した属性のみを、受信したLDAP追加操作または変更操作から受け入れます。
その他の属性はすべて(オブジェクト・クラスの必須属性を除き)、サーバー上でレプリケートされる変更から削除されます。

この2つのモードは同時には使用できません。つまり、どちらか一方のモードの属性のみをドメイン構成に追加できます。

部分レプリケーションはレプリケート対象ドメイン単位で構成します(第26.3.1項「レプリケーション・ドメイン名の取得」を参照)。部分ドメインは、特定の属性がそのドメインにまったく存在しないことを意味します。これらの属性は操作のリプレイ時に排除されるだけでなく、ドメインの既存データ自体にも存在しません。

レプリケート対象トポロジ全体でデータの一貫性を確保するためには、特定のデータ・セットが部分的であるかどうかを判断する必要があります。したがって、新しい部分ドメインを構成する作業には、そのドメインに禁止の属性が存在しないことと、そのドメインが部分ドメインとして認識可能であることを確認する手順が伴います。詳細は、第26.3.10.3項「部分ドメインを構成および初期化するには」を参照してください。

ドメインの部分レプリケーションを構成するには、次のようにdsconfigコマンドを使用します。

26.3.10.1 排他部分レプリケーションを構成するには

次の例では、オブジェクト・クラスがinetOrgPersonのエントリの作成または変更からphoto属性とjpegPhoto属性を除外するようにレプリカを構成します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X \
set-replication-domain-prop --provider-name "Multimaster Synchronization" \
--domain-name "dc=example,dc=com (domain 10233)" \
--set fractional-exclude:inetOrgPerson:photo,jpegPhoto

オブジェクト・クラスと属性の指定は名前でもOIDでも行えます。したがって、次の例は前の例と同じ結果になります:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X \
set-replication-domain-prop --provider-name "Multimaster Synchronization" \
--domain-name "dc=example,dc=com (domain 10233)" \
--set fractional-exclude:2.16.840.1.113730.3.2.2:0.9.2342.19200300.100.1.7, \
0.9.2342.19200300.100.1.60

オブジェクト・クラスまたは属性の名前とOIDを併用した場合、両方の値が追加されます。たとえば、次のコマンドは属性名とそのOIDの両方を、除外する属性のリストに追加します:

$ dsconfig set-replication-domain-prop ...
--set fractional-exclude:*:jpegPhoto,*:0.9.2342.19200300.100.1.60

この属性をリストから削除するには、属性名とOIDの両方を削除する必要があります。

オブジェクト・クラスを問わず、すべてのエントリの作成または変更からphoto属性とjpegPhoto属性を削除するように指定するには、オブジェクト・クラスのかわりにアスタリスクを使用します。例:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X \
set-replication-domain-prop --provider-name "Multimaster Synchronization" \
--domain-name "dc=example,dc=com (domain 10233)" \
--set fractional-exclude:*:photo,jpegPhoto

26.3.10.2 包含部分レプリケーションを構成するには

次の例では、オブジェクト・クラスがinetOrgPersonのエントリの作成または変更にuid属性とemployeeNumber属性のみを含めるようにレプリケーションを構成します。その他の属性は変更において、オブジェクト・クラスの必須属性を除きすべて無視されます。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X \
set-replication-domain-prop --provider-name "Multimaster Synchronization" \
--domain-name "dc=example,dc=com (domain 10233)" \
--set fractional-include:inetOrgPerson:uid,employeeNumber

オブジェクト・クラスと属性の指定は名前でもOIDでも行えます。したがって、次の例は前の例と同じ結果になります:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X \
set-replication-domain-prop --provider-name "Multimaster Synchronization" \
--domain-name "dc=example,dc=com (domain 10233)" \
--set fractional-include:2.16.840.1.113730.3.2.2:0.9.2342.19200300.100.1.1, \
2.16.840.1.113730.3.1.3

オブジェクト・クラスまたは属性の名前とOIDを併用した場合、両方の値が追加されます。たとえば、次のコマンドは属性名とそのOIDの両方を、含める属性のリストに追加します:

$ dsconfig set-replication-domain-prop ...
--set fractional-include:*:jpegPhoto,*:0.9.2342.19200300.100.1.60

この属性をリストから削除するには、属性名とOIDの両方を削除する必要があります。

オブジェクト・クラスを問わず、すべてのエントリの作成または変更に特定の属性を含めるように指定するには、オブジェクト・クラスのかわりにアスタリスクを使用します。次の例では、すべてのエントリに対する作成操作または変更操作にdescription属性のみを含めます。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X \
set-replication-domain-prop --provider-name "Multimaster Synchronization" \
--domain-name "dc=example,dc=com (domain 10233)" \
--set fractional-include:*:description

26.3.10.3 部分ドメインを構成および初期化するには

新しい部分ドメインを初期化する手順は次のとおりです:

1. 前述の2つの項の説明に従って、排他または包含モードの部分レプリケーションを構成します。
この時点で、ドメインのステータスがbad generation IDになります。詳細は、第6.5項「レプリケーション・ステータスの定義」を参照してください。

このステータスは、データがトポロジ内の他のサーバーと同期されるまで、このドメインでの変更がすべてブロックされることを意味します。

2. トポロジ内の他のサーバーの1つから新しいデータ・セットをインポートします。
新しいデータ・セットをオンラインでインポートするには、dsreplication initializeを使用するか、import-ldifをオンライン・モードまたはオフライン・モードで使用します。データのインポート元にするサーバーは、完全なレプリカである(つまり、部分レプリカではない)か、またはデータのインポート先のサーバーと同じ部分構成が設定されている必要があります。インポート時には、前述の手順で設定した部分構成に従って、すべてのエントリがフィルタリングされます。

データ・セットをインポートする方法の詳細は、第26.4.1項「単一のレプリケート対象サーバーの初期化」と第17.1項「データのインポートとエクスポート」を参照してください。

3. データ・インポート後、ドメインのステータスがnormalに戻ります。
詳細は、第6.5項「レプリケーション・ステータスの定義」を参照してください。

これで、ドメインはローカルLDAP操作やトポロジ内の他のサーバーとの同期操作から新規エントリの受入れが可能になりました。ドメイン内のデータに禁止の属性は存在しません。

26.3.11 レプリケーション・ステータスの構成

レプリケート対象トポロジ内の各レプリケート対象ドメインには、トポロジ内での接続状態や、トポロジ内で発生した変更の反映状況に応じて特定のレプリケーション・ステータスが設定されます。詳細は、第6.5項「レプリケーション・ステータスの定義」を参照してください。

レプリケーション・ステータスは、サーバーがレプリケート対象トポロジ内でどの程度最新の状態に保たれているかに応じて自動的に生成されます。設定可能な唯一のパラメータは機能低下ステータスのしきい値です。このパラメータは、レプリケーション・サーバーに接続されているディレクトリ・サーバーのすべてのドメインについて、レプリケーション・サーバーのキューに格納できる最大の変更数を定義するものです。特定のディレクトリ・サーバーに対してこの数に達すると、そのサーバーに機能低下ステータスが割り当てられます。機能低下ステータスは、変更数がこのしきい値を下回るまで維持されます。

注意:

機能低下ステータスしきい値のデフォルト値は、ほとんどのデプロイメントに適しています。保証レプリケーションが構成されている場合で、ログに複数のタイムアウト・メッセージが記録されているときのみ、この値を変更します。

26.3.11.1 機能低下ステータスしきい値を構成するには

このしきい値で定義されているデフォルトの変更数は5000です。次の例では、待機時間が長いネットワークを考慮して、しきい値を6000に設定します。

レプリケーション・サーバーでdsconfigを使用して機能低下ステータスしきい値を設定します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
set-replication-server-prop --provider-name "Multimaster Synchronization" \
--set degraded-status-threshold:6000

26.3.12 レプリケーション・サーバーの重みの構成

複数のディレクトリ・サーバーと複数のレプリケーション・サーバーからなる大規模なトポロジでは、あらかじめ定義された方法でディレクトリ・サーバーをレプリケーション・サーバーに分散させた方が効率的です。トポロジ内の各レプリケーション・サーバーに接続するディレクトリ・サーバーの数を、レプリケーション・サーバーが稼働しているマシンの相対的な能力に応じて指定できます。詳細は、第6.2.3.2項「レプリケーション・サーバーのロード・バランシング」を参照してください。

レプリケーション・サーバーの重みを構成するには、次のようにdsconfigコマンドを実行します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
set-replication-server-prop \
--provider-name "Multimaster Synchronization" --set weight:2

デフォルトでは、トポロジ内の各レプリケーション・サーバーの重みは1です。

26.4 データによるレプリケート対象サーバーの初期化

この項では、dsreplicationコマンドを使用してレプリケート対象サーバーをデータで初期化する方法について説明します。dsreplicationは、SSL経由で管理コネクタを介してサーバー構成にアクセスします。詳細は、第14.3項「サーバーへの管理トラフィックの管理」を参照してください。

この項では、第17.1.1項「スタンドアロン・ディレクトリ・サーバーへのデータの移入」に記載されている情報の一部を参照します。同項を先に一読することをお薦めします。

26.4.1 単一のレプリケート対象サーバーの初期化

トポロジ内の単一のディレクトリ・サーバーを初期化する最も簡単な方法は、dsreplicationコマンドを使用して、トポロジ内の別のディレクトリ・サーバーからデータをコピーする方法です。このコマンドを使用するには、コピー元のサーバーとコピー先のサーバー同士のレプリケーションが有効になっている必要があります。このコマンドは、コピー先サーバーの指定したベースDNの下にあるすべてのデータをコピー元サーバーからのデータに置き換えます。

たとえば、次のコマンドはhost2のベースDN "dc=example,dc=com"をhost1のデータで初期化します。

$ dsreplication initialize --baseDN "dc=example,dc=com" \
--adminUID admin --adminPasswordFile pwd.txt \
--hostSource host1 --portSource 4444 \
--hostDestination host2 --portDestination 4444 --trustAll

26.4.2 新しいレプリケート対象トポロジの初期化

新しいレプリケート対象トポロジ内のすべてのディレクトリ・サーバーを初期化するには、次のいずれかの方法を使用します:

- 第17.1.1項「スタンドアロン・ディレクトリ・サーバーへのデータの移入」で説明されているいずれかの方法を使用して、すべてのディレクトリ・サーバーを同じデータで個別に初期化します。すべてのディレクトリ・サーバーをデータで初期化したら、サーバー間のレプリケーションを有効にします。

- 第17.1.1項「スタンドアロン・ディレクトリ・サーバーへのデータの移入」で説明されているいずれかの方法を使用して、単一のディレクトリ・サーバーを初期化します。すべてのディレクトリ・サーバーに対してレプリケーションを有効にし、dsreplication intialize-allコマンドを使用して残りのすべてのサーバーを同時に初期化します。このコマンドはソース・サーバーの詳細を引数としてとり、レプリケーションが有効になっている他のすべてのサーバーを初期化します。
たとえば、次のコマンドはすべてのディレクトリ・サーバーをhost1上のコンテンツで初期化します。

$ dsreplication initialize-all --hostname localhost --port 4444 --trustAll \
--baseDN "dc=example,dc=com" --adminUID admin --adminPasswordFile pwd.txt

26.4.3 既存のレプリケート対象トポロジへのディレクトリ・サーバーの追加

既存のレプリケート対象トポロジにディレクトリ・サーバーを追加する場合、トポロジ内の既存のディレクトリ・サーバーと同じデータ生成を新しいサーバーに移入する必要があります。データ生成とは、レプリケーション・ドメインのルート・エントリに格納されているIDです。データ生成が存在しない場合、レプリケーション・メカニズムによってデータ生成が計算され格納されます。新しいディレクトリ・サーバーがトポロジ内の他のサーバーと同じデータ生成を保持するようにするには、次のいずれかの方法でディレクトリ・サーバーにデータを移入します:

- 他のディレクトリ・サーバーの移入に使用した同じオリジナルLDIFファイル、バックアップ・ファイルまたはバイナリ・コピーを使用します。

- トポロジ内の別のディレクトリ・サーバーからのエクスポート、バックアップまたはバイナリ・コピーを使用します。

GUIインストールを使用して新しいディレクトリ・サーバーをインストールする場合は、そのサーバーをレプリケート対象トポロジのメンバーにすることを指定すれば、自動的に適切なデータ生成を使用してサーバーが初期化されます。

GUIインストールを使用せずにディレクトリ・サーバーをインストールし、dsreplicationコマンドを使用してレプリケーションを有効にする場合は、前述の項で説明したいずれかの方法により手動でサーバーを初期化する必要があります。

トポロジ内のディレクトリ・サーバーにトポロジ内の他のサーバーと同じデータ生成が格納されていない場合、そのディレクトリ・サーバーとのデータ・レプリケーションはできません。ただし、そのディレクトリ・サーバーもトポロジとの接続は維持されており、レプリケーション・プロトコルによる初期化が可能です。このディレクトリ・サーバー上のレプリケーションは、ダウングレードした状態にあるといいます。

適切なデータ生成を持つディレクトリ・サーバーが既存のトポロジに追加されると、トポロジ内の最初のディレクトリ・サーバーがデータで初期化された時点以降に発生したすべての変更がレプリケーション・メカニズムによって自動的にリプレイされます。この動作より、新しいディレクトリ・サーバーがトポロジ内の他のサーバーと確実に同期されます。

26.4.4 既存のレプリケート対象トポロジにあるデータ・セットの変更

データ・セットを変更するには、完全に新規のデータ・セットをトポロジ内のすべてのディレクトリ・サーバーにインポートします。データ・セットが変更される際、2つのタスクが実行されます:

- 新しいデータがトポロジ内の各ディレクトリ・サーバーに適用されます。

- レプリケーション・サーバーに格納されている変更がすべてクリアされます。このタスクには、各ディレクトリ・サーバー上のデータ生成をリセットして新しいデータ生成が使用されるようにする操作も含まれます。

dsreplication initializeコマンドを使用してデータ・セットを変更すると、これらのタスクの両方が自動的に実行されます。ただし、import-ldifコマンドまたはバイナリ・コピー方式でデータ・セットを変更する場合は、次の項の説明に従って、これらのタスクを手動で行う必要があります。

26.4.4.1 import-ldifまたはバイナリ・コピーを使用してデータ・セットを変更するには

1. dsreplication pre-external-initializationコマンドを実行して、ディレクトリ・サーバーから生成IDをクリアします。
このコマンドは、トポロジ内の1つのディレクトリ・サーバーで実行するだけで十分です。1つのディレクトリ・サーバーのみを更新対象として指定しないかぎり、トポロジ内のすべてのディレクトリ・サーバーが更新されます。たとえば、次のコマンドは、import-ldifまたはバイナリ・コピーを使用してトポロジ内の全サーバーの初期化を準備します:

$ dsreplication pre-external-initialization -h host1 -p 4444 -X \
-b dc=example,dc=com -I admin -j pwd-file

Are you going to initialize only the contents of server host1:4444 (type
'no' if you will initialize contents of all replicated servers for the given
Base DNs)? (yes / no) [no]:
Preparing base DN dc=example,dc=com to be initialized externally ..... Done.
Now you can proceed to the initialization of the contents of the base DNs on
all the replicated servers. You can use the command import-ldif or the binary
copy to do so. When the initialization is completed you must use the subcommand
{post-external-initialization} for replication to work with the new base DNs contents.

2. import-ldifまたはバイナリ・コピーを使用して、トポロジ内のすべてのディレクトリ・サーバーをデータで初期化します。

3. dsreplication post-external-initializationコマンドを実行して生成IDをリセットします。
このコマンドは、トポロジ内の1つのディレクトリ・サーバーで実行するだけで十分です。他のすべてのディレクトリ・サーバーが更新されます。たとえば、次のコマンドは、import-ldifまたはバイナリ・コピーを使用してトポロジ内のすべてのディレクトリ・サーバーの生成IDをリセットします:

$ dsreplication post-external-initialization -h localhost \
-p 4444 -b dc=example,dc=com -I admin -j pwd-file -X
Updating replication information on base DN dc=example,dc=com ..... Done.
Post initialization procedure completed successfully.

26.4.5 既存のレプリケート対象トポロジへのデータの追加

すでに大量のエントリが含まれている既存のレプリケート対象トポロジに大量のエントリをインポートする最も簡単な方法は、import-ldifコマンドに-aオプションまたは--appendオプションを指定して使用する方法です。

import-ldifコマンドを使用してデータをインポートする場合、レプリケート対象データが自動的にはレプリケートされません。このため、import-ldif --appendをトポロジ内のすべてのディレクトリ・サーバーで実行する必要があります。この戦略では、ディレクトリ・サービスを停止せずにデータをインポートできます。

また、トポロジ内の単一のディレクトリ・サーバーにデータをインポートしてから、dsreplication initialize-allコマンドを使用することもできます。ただし、この戦略ではディレクトリ・サービスが一定期間、使用不可になります。

26.5 外部変更ログの使用

外部変更ログ(ECL)は、ディレクトリ・サーバー・データベース内で発生したすべての変更を公開します。特に、LDAPディレクトリを他のサブシステムと同期させる場合に便利です。

外部変更ログはレプリケーション変更ログからオンラインで構築され、その保管に追加のデータベースは使用されません。通常のJEBバックエンドではないため、索引の構成は不要です。

この項では、ディレクトリ・サービスで外部変更ログを有効にする方法と、外部変更ログにアクセスできるようにクライアント・アプリケーションを構成する方法について説明します。この項の内容は次のとおりです:

- 第26.5.1項「外部変更ログの有効化」

- 第26.5.2「外部変更ログのAPI」

- 第26.5.3項「クライアント・アプリケーションがCookieモードで外部変更ログを使用する際の動作」

- 第26.5.4項「外部変更ログの形式」

- 第26.5.5項「外部変更ログに含める属性の指定」

- 第26.5.6項「外部変更ログから除外する属性の指定」

- 第26.5.7項「外部変更ログを使用するクライアント・アプリケーションの初期化」

- 第26.5.8項「外部変更ログへのアクセスの制御」

- 第26.5.9項「外部変更ログのパージ」

- 第26.5.10項「サーバーでの外部変更ログの無効化」

- 第26.5.11項「特定のドメインに対する外部変更ログの無効化」

- 第26.5.12項「他の変更ログに依存するアプリケーションの移植」

26.5.1 外部変更ログの有効化

ディレクトリ・サーバーおよびレプリケーションの両方を含むサーバー・インスタンスでは、外部変更ログがデフォルトで使用できます。dedicated directory serverまたはdedicated replication serverのいずれかを使用して構成されたサーバー・インスタンスでは、外部変更ログがデフォルトでは使用できません(第26.2項「大規模なレプリケーション・トポロジの構成」を参照)。

次のいずれかの方法でレプリケーションを構成すると、外部変更ログが有効になります:

- インストール時にレプリケート対象トポロジのメンバーとしてディレクトリ・サーバーを構成する方法。詳細は、Oracle Fusion Middleware Oracle Unified Directoryインストレーション・ガイドのインストール時のレプリケーションの設定に関する項を参照してください。

- インストール後にdsreplicationコマンドを使用してレプリケーションを構成する方法。詳細は、第26.1項「dsreplicationによるデータ・レプリケーションの構成」を参照してください。

注意:

--onlyReplicationServerオプションまたは--noReplicationServerオプションを指定してレプリケーションを構成した場合は、外部変更ログが使用できません。

外部変更ログの機能はレプリケーション・メカニズムに基づいていますが、クライアント・アプリケーションによっては、レプリケート対象トポロジの外側のローカル・サーバー上にある外部変更ログ・コンテンツを必要とするものもあります。ローカル・サーバーで特定のベースDNに対する外部変更ログを有効にするには、次のコマンドを実行します:

$ dsreplication enable-changelog -h localhost -p 4444 -D "cn=directory manager" \
-j pwd-file -r 8989 -b dc=example,dc=com -X -n

外部変更ログを構成するには、スタンドアロン・サーバーでもレプリケーション・ポート(-r)が必要ですが、これは外部変更ログがレプリケーション・メカニズムに依存しているためです。レプリケーション・ポートを指定する必要があるのは、そのサーバーで変更ログ(またはレプリケーション)があらかじめ構成されていない場合のみです。レプリケーション・ポートのデフォルト値は8989です。

ディレクトリ・サーバー・インスタンス上で外部変更ログが構成されていることを確認するには、次の検索コマンドを実行します:

$ ldapsearch -h localhost -p 1389 -D "cn=directory manager" -j pwd-file \
-s base -b "" "objectclass=*" namingContexts
dn:
namingContexts: cn=changelog
namingContexts: dc=Europe,dc=com
namingContexts: dc=us,dc=com

26.5.2 外部変更ログのAPI

外部変更ログは、次の2種類の操作モードを有効にする2つのAPIをサポートしています:

- Cookieモード。外部変更ログへのアクセスには、このAPIを使用することをお薦めします。
Cookieモードでは、クライアント・アプリケーションがサーバーへのリクエストで外部変更ログの交換制御を提供します。このモードでは、サーバーから返されるエントリ内のDITとスキーマは、LDAP変更ログ・ドラフト(http://tools.ietf.org/html/draft-good-ldap-changelog-04)と互換性がありません。

- ドラフト互換モード。このモードは、LDAP変更ログ・ドラフトに依存する既存のアプリケーションでのみ使用してください。
このモードでは、サーバーから返されるエントリ内のDITとスキーマは、LDAP変更ログ・ドラフトと互換性があります。

パフォーマンスの向上および簡素化のために、クライアント・アプリケーションを移植してCookieモードを使用してください。詳細は、第26.5.12項「他の変更ログに依存するアプリケーションの移植」を参照してください。

26.5.3 クライアント・アプリケーションがCookieモードで外部変更ログを使用する際の動作

外部変更ログのエントリには、それぞれCookieが関連付けられています。クライアント・アプリケーションは、検索リクエストを送信するとき、(前回の検索の)外部変更ログから読み取った最後のメッセージのCookieまたは空の値のどちらかを提供します。サーバーは、そのCookieに関連付けられた外部変更ログ・エントリを返します。

各エントリがそれぞれに関連付けられたCookieとともに返されます。アプリケーションは接続を切断すると、受信した最後のCookieを格納し、このCookieを次の検索リクエストとともにサーバーへ送信します。

この外部変更ログCookieの送信を次の図に示します。

Cookieのコンテンツは、クライアント・アプリケーションのための公開インタフェースではありません。クライアント・アプリケーションはCookieをリクエスト制御として送信し、サーバーはCookieをレスポンス制御として送信します。

Cookie交換制御のOIDは1.3.6.1.4.1.26027.1.5.4です。アプリケーションから提供されたCookieが破損しているとサーバーが判断した場合、リクエストが却下されます。また、このCookieをアプリケーションに送信した後に外部変更ログの構成が変更されたとサーバーが判断した場合や、外部変更ログがパージされており、格納されている最も古い変更がCookieの値より新しいとサーバーが判断した場合も、リクエストは却下されます。この場合、外部アプリケーションの完全な再同期を推奨する追加情報が返されます。

注意:

サーバーがレプリケーション・トポロジから切断され、接続中のクライアントからの変更を処理した場合は、収束を保証できません。

次のリクエストとレスポンスの例で、クライアント・アプリケーションがどのように外部変更ログを使用して検索し、どのように外部変更ログが応答するかを示します。

リクエスト1

外部変更ログの読取りを開始するために、クライアントがcn=changelogに対する最初の検索リクエストを送信します。Cookie交換制御には空の文字列を指定します。

$ ldapsearch -h localhost -p 1389 -D "cn=directory manager" -j pwd-file \
--control "1.3.6.1.4.1.26027.1.5.4:false:;" -b "cn=changelog" \
"(objectclass=*)" "*" +

レスポンス1

サーバーが各変更をSearchResultEntryに格納してクライアントへ送信します。cookie属性では新しいCookieの値を指定します。この値はまた、Cookie交換制御に格納されてエントリとともに送信されます。

# Public changelog exchange control(1.3.6.1.4.1.26027.1.5.4):
dc=europe,dc=com:0000012187eae081456200000001;o=example:;
dn: replicationcsn=0000012187eae081456200000001,dc=europe,dc=com,cn=changelog
objectClass: top
objectClass: changeLogEntry
replicationCSN: 0000012187eae081456200000001
replicaIdentifier: 17762
targetDN: cn=chek-piao chea,ou=unit1,o=people,dc=europe,dc=com
changeTime: 20090528155105Z
changes:: cmVwbGFjZTogc2VlQWxzbwpzZWVBbHNvOiBjbj1tY29uZmlnCi0KcmVwbGFjZTogbW9kaW
ZpZXJzTmFtZQptb2RpZmllcnNOYW1lOiBjbj1EaXJlY3RvcnkgTWFuYWdlcixjbj1Sb290IEROcyxjb
j1jb25maWcKLQpyZXBsYWNlOiBtb2RpZnlUaW1lc3RhbXAKbW9kaWZ5VGltZXN0YW1wOiAyMDA5MDUy
ODE1NTEwNVoKLQo=
changeType: modify
changeLogCookie: dc=europe,dc=com:0000012187eae081456200000001;
targetEntryUUID: 08d1830c-02f1-34a6-9cf4-8d1270ec1db0
changeNumber: 0

リクエスト2

最後に返されたエントリから外部変更ログを読み取るために、クライアントがcn=changelogに対する検索リクエストを送信します。今度は、Cookie交換制御で受信した最後のCookieの値を指定します。

$ ldapsearch -h localhost -p 1389 -D "cn=directory manager" -j pwd-file
--control "1.3.6.1.4.1.26027.1.5.4:false:dc=europe,dc=com:0000012187eae081456200000001;"
-b "cn=changelog" "(objectclass=*)"

注意:

外部変更ログのコンテンツはBase64でエンコードされています。コンテンツのデコードの詳細は、第A.3.2項「base64」を参照してください。

26.5.4 外部変更ログ・エントリの形式

外部変更ログ内の返される各エントリのDNは、次のような形式になっています:

replicationcsn=replicationCSN,replication-domain-DN,cn=changelog

例:

dn: replicationcsn=0000012187eae081456200000001,dc=europe,dc=com,cn=changelog

外部変更ログ・エントリについて次の属性が返されます:

targetDN / MUST
changeType / MUST
changeTime / MUST
changeNumber / MUST // used only for compatibility mode

changes / MAY, MUST for add, mod
newRDN / MAY, MUST for modrdn
deleteOldRDN / MAY, MUST for modrdn
newSuperior / MAY, MUST for modrdn

replicaIdentifier / MAY, OPERATIONAL / specific OUD value
replicationCSN / MAY, OPERATIONAL / specific OUD value
targetEntryuuid / MAY, OPERATIONAL / specific OUD value
changelogcookie / MAY, OPERATIONAL

26.5.5 外部変更ログに含める属性の指定

デフォルトでは、外部変更ログに含まれる属性は、変更操作の影響を受ける属性のみです。したがって、たとえば、エントリのsn属性が変更される場合、その属性のみが外部変更ログに記述されます。ただし、変更操作の影響を受けるかどうかに関係なく、外部変更ログに含める属性のリストを指定できます。また、この属性リストをすべての種類の操作に対して含めるか、削除操作に対してのみ含めるかも指定できます。

属性の構成には次のプロパティを使用します:

- ecl-include

- ecl-include-del-only

ecl-includeプロパティの使用方法

ecl-includeプロパティを使用すると、エントリが変更された場合に外部変更ログに含める属性を構成できます。

ecl-includeプロパティの値を設定するには、dsconfigコマンドを使用します。たとえば、エントリが変更された場合に常にcn属性とsn属性を外部変更ログに含めるように指定するには、次のコマンドを実行します:

dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -Q -n -X \
set-external-changelog-domain-prop --provider-name "Multimaster Synchronization" \
--domain-name dc=example,dc=com \
--add ecl-include:cn --add ecl-include:sn

サーバーが返す外部変更ログ・エントリでは、属性名にtargetという接頭辞が付いています。たとえば、前述の例でいえば、dc=example,dc=comでの変更に対する外部変更ログ・エントリには、targetcn属性とtargetsn属性が必ず含まれています。これらの属性の値は、エントリの変更または移動前のcn属性とsn属性の値です。

ecl-include-del-onlyプロパティの使用方法

ecl-includeプロパティと一緒にecl-include-del-onlyプロパティを使用すると、 削除操作についてのみ追加の属性を取得できます。

ecl-include-del-onlyプロパティの値を設定するには、dsconfigコマンドを使用します。

dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -Q -n -X \
set-external-changelog-domain-prop --provider-name "Multimaster Synchronization" \
--domain-name dc=example,dc=com \
--add ecl-include:cn --add ecl-include:sn --set ecl-include-del-only:true

26.5.6 外部変更ログから除外する属性の指定

外部変更ログを使用するクライアント・アプリケーションは必ずしも、サーバーで実行されたすべてのLDAP操作に関心があるわけではありません。このため、無関連の情報の処理を避けるために、属性のリストをフィルタリングできます。

ecl-blacklistプロパティを使用すると、外部変更ログから除外する属性を構成できます。すべての変更がブラックリスト対象属性に該当する場合のみ、クライアント・アプリケーションへ送信される変更操作がスキップされます。

注意:

ブラックリスト・メカニズムを使用するには、Cookieモードを使用する必要があります。

ecl-blacklistプロパティの値を設定するには、dsconfigコマンドを使用します。たとえば、email属性とtelephonenumber属性に関連する変更操作を外部変更ログから除外するように指定するには、次のコマンドを実行します:

dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -Q -n -X \
set-external-changelog-domain-prop --provider-name "Multimaster Synchronization" \
--domain-name dc=example,dc=com --add ecl-blacklist:email \
--add ecl-blacklist:telephonenumber

26.5.7 外部変更ログを使用するクライアント・アプリケーションの初期化

クライアントで外部変更ログを使用するために必要なサーバー構成は特にありません。ただし、外部変更ログを使用するクライアント・アプリケーションを、次の各項の説明に従って初期化する必要があります。

- 第26.5.7.1項「外部変更ログを使用するクライアント・アプリケーションを初期化するには」

- 第26.5.7.2項「ドメインの追加時のクライアント・アプリケーションの再初期化」

- 第26.5.7.3項「ドメインの削除時または無効化時のクライアント・アプリケーションの再初期化」

26.5.7.1 外部変更ログを使用するクライアント・アプリケーションを初期化するには

次の例で、ホスト2をホスト1から初期化するシナリオを示します。ホスト1は初期化操作中も固定されず、変更を受信し続けます。次の手順により、ホスト1で受信された変更がホスト2に漏れなく反映されることが保証されます。

1. ホスト1にある最後の外部変更ログCookieの値を読み取って、ホスト1の最新の状態を保存します。
これは、ルートDSEのlastExternalChangelogCookie属性の値です。例:

$ ldapsearch -h localhost -p 1389 -D "cn=directory manager" -j pwd-file \
-s base -b "" "objectclass=*" lastExternalChangelogCookie
dn:
objectClass: top
objectClass: ds-root-dse
lastExternalChangelogCookie: dc=europe:00000121cea5221c04b100000005 \
00000121cea5319e04b400000009;

ホスト1は固定されず、変更を受信し続けることに注意してください。

2. ホスト2を初期化するために、Oracle Unified Directoryデータベースをホスト1からエクスポートしてホスト2にインポートします。

3. エクスポートしたデータベースを使用してアプリケーションを初期化します。
手順1で保存した最新の状態を使用して、ホスト2でのレプリケーションを再開します。これで、アプリケーションは最後のCookie値を検索制御の値として提供して、外部変更ログの読取りを開始できます。例:

$ ldapsearch -h localhost -p 1389 -D "cn=directory manager" -j pwd-file
--control "1.3.6.1.4.1.26027.1.5.4:false:dc=europe:00000121cea5221c04b100000005 \
00000121cea5319e04b400000009" -b "cn=changelog" "(objectclass=*)"

26.5.7.2 ドメイン追加時のクライアント・アプリケーションの再初期化

新しいレプリケーション・ドメインをトポロジに追加すると、そのドメインで外部変更ログがデフォルトで有効になります。外部変更ログを使用するクライアント・アプリケーションを、その新規ドメインに対して再初期化する必要があります。

サーバーでは、提供されたCookieが新規ドメインを参照していなければ検索操作を拒否することによって、この要件を強制します。その操作結果コードは「実行要求を拒否」です。サーバーは、欠けているドメインのリストと部分的初期化用のCookie値を含む詳細メッセージを提供します。

次のいずれかの方法でクライアント・アプリケーションを再初期化する必要があります:

- 完全な再初期化。アプリケーションをすべてのドメインに対して再初期化します。

1. lastExternalChangelogCookie属性の値を読み取ります。この値は、新規ドメインを含む、トポロジ内の全ドメインを参照しています。

2. 新規ドメインを含む全ドメインを対象にデータベースをエクスポートします。

3. エクスポートの出力を使用してアプリケーションを全ドメインに対して初期化します。詳細は、第26.5.7.1項「外部変更ログを使用するクライアント・アプリケーションを初期化するには」を参照してください。

4. これで、アプリケーションはlast_cookie_from_dse_rootを使用して外部変更ログを検索できるようになりました。

- 部分的再初期化。アプリケーションを新規ドメインに対してのみ再初期化します。

1. 新規ドメインのみを対象にデータベースをエクスポートします。

2. エクスポートの出力を使用してアプリケーションを初期化します。エクスポートの出力には、新規ドメイン内のエントリのみが格納されています。詳細は、第26.5.7.1項「外部変更ログを使用するクライアント・アプリケーションを初期化するには」を参照してください。

3. これで、アプリケーションは、「実行要求を拒否」エラーでサーバーから返された部分的初期化用のCookie値を使用して、外部変更ログを検索できるようになりました。その結果として、すでに処理が完了している一部の更新がリプレイされることがありますが、これはCookie値がデータベースの初期状態を示しているためです。

注意:

ドラフト互換モードのドラフトAPIでは、アプリケーションが適切に初期化されるようにサーバーが強制することはできません。したがって、ドラフト互換モードでは、新規ドメインが追加されると同時に、そのサーバーにおける変更が外部変更ログに公開されます。

サーバーが新規ドメインに関する変更を公開しないようにするには、第26.5.11項「特定のドメインに対する外部変更ログの無効化」を参照してください。特定のドメインに対する変更のみがアプリケーションに通知されるようにするには、そのドメインをベースDNで指定するか(Cookieモードの場合のみ)、targetDN属性の検索フィルタとして指定します。

26.5.7.3 ドメインの削除時または無効化時のクライアント・アプリケーションの再初期化

レプリケーション・ドメインをトポロジから削除したら(または、外部変更ログを特定のドメインに対して無効にしたら)、以後そのドメインでは変更が発生しないことをクライアント・アプリケーションに通知する必要があります。

サーバーでは、提供されたCookieが、削除されたドメインを参照していれば検索操作を拒否することによって、この要件を強制します。その操作結果コードは「実行要求を拒否」です。サーバーは、Cookieにあるドメインで削除されたもの(または外部変更ログが無効化されたもの)のリストと継続用のCookie値を含む詳細メッセージを提供します。

クライアント・アプリケーションでは、削除されたドメインを次のいずれかの方法で処理できます:

- 円滑な継続。この場合、アプリケーションはドメインの削除時の処理に関する独自のポリシーを適用できます。このポリシーの作成を支援するために、アプリケーションでは、サーバーからエラー・メッセージで返された継続用のCookie値を提供して外部変更ログを検索できます。

- 完全な再初期化。アプリケーションをすべてのドメインに対して再初期化します。

1. lastExternalChangelogCookie属性の値を読み取ります。この値は、削除されたドメインを除く、トポロジ内の全ドメインを参照しています。

2. 全ドメインを対象にデータベースをエクスポートします。

3. エクスポートの出力を使用してアプリケーションを全ドメインに対して初期化します。詳細は、第26.5.7.1項「外部変更ログを使用するクライアント・アプリケーションを初期化するには」を参照してください。

4. これで、アプリケーションはlastExternalChangelogCookieを使用して外部変更ログを検索できるようになりました。

26.5.8 外部変更ログへのアクセスの制御

外部変更ログへのアクセスは、サーバーで構成可能なグローバルACIによって制御されています。デフォルトでは、rootユーザーのみが外部変更ログにアクセスできます。

グローバルACIの構成の詳細は、第22.1項「dsconfigによるグローバルACIの管理」を参照してください。

26.5.9 外部変更ログのパージ

外部変更ログは、レプリケーション変更ログとともにパージされます。レプリケーション変更ログのパージ間隔の変更の詳細は、第26.3.2項「レプリケーション・パージ遅延の変更」を参照してください。

アプリケーションがサーバーに保存されている最も古い変更よりも古いCookie値を指定して、外部変更ログに対する検索リクエストを送信する場合があります。これは、そのアプリケーションからの前回のリクエスト以降にパージが実行されたためです。この場合、サーバーはリクエストを却下し、Cookieが古いことと完全な再同期が必要であることを示します。

26.5.10 サーバーでの外部変更ログの無効化

サーバーで特定のベースDNに対する外部変更ログを無効にするには、次のようにdsreplication disable-changelogコマンドを使用します:

$ dsreplication disable-changelog -h localhost -p 4444 -D "cn=directory manager" \
-j pwd-file -b dc=example,dc=com -X -n

26.5.11 特定のドメインに対する外部変更ログの無効化

特定のドメインにおける変更を外部変更ログから除外する必要がある場合があります。特定のレプリケーション・ドメインについて外部変更ログを無効にできます。無効にすると、そのドメインに対する変更が外部変更ログに公開されなくなります。

1. ドメイン名を取得します。詳細は、第26.3.1項「レプリケーション・ドメイン名の取得」を参照してください。

2. そのドメインの外部変更ログ・ドメイン・プロパティを設定します。
たとえば、スキーマの変更を外部変更ログに公開しないようにするには、次のようにdsconfigコマンドを実行します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
set-external-changelog-domain-prop \
--provider-name "Multimaster Synchronization" --domain-name cn=schema \
--set enabled:false

26.5.12 他の変更ログに依存するアプリケーションの移植

外部変更ログは、LDAP変更ログ・ドラフト(http://tools.ietf.org/html/draft-good-ldap-changelog-04)に基づいていますが、この変更ログを厳密にはサポートしていません。LDAP変更ログ・ドラフトでは、変更ログを閲覧するためのキーとして整数を使用するのに対し、外部変更ログではCookieを使用します。

クライアント側では、Cookieメカニズムには次の利点があります:

- 外部変更ログ・インスタンス間のフェイルオーバーが可能。

- 複数の外部変更ログ・インスタンス間での負荷分散リクエストが可能。

サーバー側では、Cookieメカニズムには次の利点があります:

- マルチマスター環境における実装が容易になる

- サーバーで必要とされるリソースが少なくなる

- 変更を生成する他のアプリケーションに対するパフォーマンスの影響が小さくなる

注意:

Oracle Directory Server Enterprise Edition (ODSEE)のレトロ変更ログ(RCL)はLDAP変更ログ・ドラフトをサポートしており、固有の追加がいくつかあります。

26.5.12.1 外部変更ログとLDAP変更ログ・ドラフトの相違点

次の各項では、2つの変更ログの相違点について説明します。これは、クライアント・アプリケーションを移植するときに役立ちます。

26.5.12.1.1 索引の相違点

LDAP変更ログ・ドラフトでは、変更ログ索引を整数として指定します(changenumber属性)。この形式は、変更ログ・サービスが単一のサーバーによって提供される場合には効果的です(LDAP変更ログ・ドラフトの仕様が策定された時点ではそうでした)。しかし、変更ログ・サービスが複数のサーバーをサポートする場合や、サーバー間のフェイルオーバーをサポートする場合、この整数の形式は不適切です。

Oracle Directory Server Enterprise Editionとの互換性を確保するには、cn=changelogでreplicationCSN属性に索引を作成する必要があります。cn=changelog以外のパラメータでreplicationCSN属性に索引を作成すると、パフォーマンスに影響するおそれがあります。

26.5.12.1.2 DITおよびスキーマの相違点

LDAP変更ログ・ドラフトでは、変更ログ内のエントリに対するDNをchangenumber=changenumer,cn=changelogとして指定します。外部変更ログでは、変更ログ内のエントリに次のDNを使用します:

replicationcsn=replicationCSN,replication-domain-DN,cn=changelog

外部変更ログのスキーマはLDAP変更ログ・ドラフトのスキーマに基づいていますが、Oracle Unified Directoryでは外部変更ログ内の索引をchangenumber属性ではなく、アプリケーションには理解不能なCookieによって管理します。スキーマの違いは次のとおりです:

オリジン

必須

任意

LDAP変更ログ・ドラフト

changenumber

targetDn

changetype

changes

newRDN

deleteOldRDN

newSuperior

ODSEEレトロ変更ログ

changenumber

targetDn

changetype

changetime

changes

newRDN

deleteOldRDN

newSuperior

changeHasReplFixupOp

changeIsReplFixupOp

deletedEntryAttrs

replicaIdentifier (操作属性)

replicationCSN (操作属性)

targetUniqueId (操作属性)

Oracle Unified Directory外部変更ログ

changenumber:0

targetDn

changetype

changetime

changes

newRDN

deleteOldRDN

newSuperior

replicaIdentifier (操作属性)

replicationCSN (操作属性)

targetentryuuid (操作属性)

changelogcookie (操作属性)

26.5.12.2 外部変更ログとOracle Directory Server Enterprise Editionレトロ変更ログとのその他の相違点

スキーマおよび実装ベースの値

Oracle Directory Server Enterprise Editionのレトロ変更ログは、 ターゲット・エントリの一意IDをtargetuniqueid属性に格納する仕様になっています。この属性値フォーマットは、Oracle Directory Server Enterprise Editionに固有のものです。replicationcsn属性もOracle Directory Server Enterprise Editionに固有の値を保持します。

最初と最後の外部変更ログ索引

Oracle Directory Server Enterprise Editionのレトロ変更ログは、ルートDSEエントリの次の属性をサポートしています:

- firstchangenumber属性: 最初の(最も古い)変更ログ索引を整数の変更番号として保持します。
この値は、変更ログがパージされると更新されます。アプリケーションは変更ログ・サーバーに接続する前に、最初の変更ログ索引を読み取り、それをアプリケーションが格納した変更ログ索引と比較します。アプリケーションが格納した最後の変更ログ索引よりも最初の変更ログ索引の方が新しければ、アプリケーションの索引から最初の変更ログ索引までの変更がサーバーから返されないことをアプリケーションは認識します。この変更は、すべてのエントリを読み取ることによってのみ取得できます(完全再同期)。

Oracle Unified Directoryの外部変更ログでは、この手続きをアプリケーションが行う必要がありません。かわりに、Oracle Unified Directoryサーバーが確認を行い、Cookieが古すぎる場合はリクエストを却下します。詳細は、第26.5項「外部変更ログの使用」を参照してください。

- lastchangenumber属性: 最後の(最も新しい)変更ログ索引を整数の変更番号として保持します。
Oracle Unified Directoryの外部変更ログは、lastExternalChangelogCookie属性に相当する機能をサポートしています。詳細は、第26.5項「外部変更ログの使用」を参照してください。

パージの遅延

Oracle Directory Server Enterprise Editionのレトロ変更ログでは、外部変更ログと通常のレプリケーション変更ログが別々のデータベースになっています。Oracle Unified Directoryでは、この2つの変更ログが同じデータベースに格納されています。この設計上の決定には、それぞれの利点があります。この設計上の決定の付加的な結果として、Oracle Directory Server Enterprise Editionでは2つの別々のトリミング・ポリシー(パージの遅延)を設定できるのに対し、Oracle Unified Directoryのトリミング・ポリシーは同一です。

26.5.12.3 LDAP変更ログ・ドラフトおよびOracle Directory Server Enterprise Editionレトロ変更ログとの互換性のためのAPI

Oracle Unified Directoryは、LDAP変更ログ・ドラフトと互換性のある追加APIを備えているほか、Oracle Directory Server Enterprise Editionのレトロ変更ログの追加機能の大部分をサポートしています。このAPIの使用は、サーバー側のCPUとデータベース(ディスク)領域の面、および外部変更ログ・サーバー間でフェイルオーバーするアプリケーションの計算処理面のパフォーマンスに影響します。

サーバーが外部変更ログに対するリクエストを変更ログCookieなしで受信すると、この互換性API (互換性モード)の使用が構成されます。サーバーは、エントリとともにchangenumber属性を返します。その値は1ずつ増加していく整数です。

クライアントは、changenumberに対するフィルタを指定することで外部変更ログを検索できます。ターゲット・エントリの一意IDは、Oracle Directory Server Enterprise Editionのレトロ変更ログと互換性のある形式でtargetuniqueidという属性に格納されます。最初と最後のchangenumberは、ルートDSEエントリの属性として存在します。

26.5.12.3.1 互換性APIの制限事項

Oracle Unified Directoryでは、外部変更ログを専用のデータベースに格納しないため、特定の索引など、JEBバックエンドでサポートされている機能の一部をサポートしていません。

また、LDAP変更ログ・ドラフトで指定されたchangenumberベースの順序をサポートするために、Oracle Unified Directoryではchangenumberからレプリケーション・ステータスへのマッピングを格納する必要があります。サーバーはリクエストの処理時に、リクエスト・フィルタで提供されたchangenumberからレプリケーション・ステータスの取得を試みます。取得できない場合は、リクエストが却下されます。

26.6 スキーマのレプリケーションの構成

スキーマのレプリケーションはデフォルトで有効になっています。サーバー設定の一部としてレプリケーションを構成すると、トポロジ内の既存のサーバーのスキーマを使用して、新しいサーバーのスキーマが自動的に初期化されます。

26.6.1 スキーマ・ソースの指定

dsreplication enableコマンドでレプリケーションを構成するとき、2番目のディレクトリ・サーバーを使用して1番目のサーバーのスキーマを初期化するように指定できます。オプションを指定しないと、1番目のディレクトリ・サーバーのスキーマがデフォルトで使用されます。

次の例では、host1のデータを使用してhost2を初期化し、host2のスキーマを使用してhost1のスキーマを初期化します:

$ dsreplication enable --host1 host1 --port1 4444 \
--bindDN1 "cn=Directory Manager" --bindPasswordFile1 pwd.txt \
--replicationPort1 8989 --host2 host2 --port2 4444 \
--bindDN2 "cn=Directory Manager" --bindPasswordFile2 pwd.txt \
--replicationPort2 8989 --adminUID admin --adminPasswordFile pwd.txt \
--baseDN "dc=example,dc=com" --useSecondServerAsSchemaSource -X

26.6.2 スキーマのレプリケーションの無効化

環境によっては、スキーマをレプリケートしたくない場合もあります。スキーマは、"cn=schema"という別個のベースDNの下にレプリケートされます。

26.6.2.1 スキーマをレプリケートしないように指定するには

dsreplication enableコマンドでレプリケーションを構成するとき、スキーマをレプリケートしないように指定するには、--noSchemaReplicationオプションを使用します。

注意:

QuickSetupを使用してレプリケーションを有効にする場合は、スキーマをレプリケートしないようには指定できません。

26.6.2.2 スキーマのレプリケーションを無効にするには

現在スキーマがレプリケートされている既存のトポロジでこの機能を無効にするには、スキーマ・ベースDNのレプリケーションを無効にします。次の例では、ローカル・ホストのポート1389で稼働しているディレクトリ・サーバーのスキーマのレプリケーションを無効にします:

$ dsreplication disable -h localhost -p 1389 -D "cn=directory manager" \
-j pwd-file -b "cn=schema" -X

注意:

この例は、トポロジ全体のスキーマのレプリケーションを無効にするものではありません。トポロジ全体のスキーマのレプリケーションを無効にするには、トポロジ内の各ディレクトリ・サーバーで同等のコマンドを実行する必要があります。

26.7 読取り専用サーバーへのレプリケーション

Oracle Unified Directoryのレプリケーション・モデルはマルチマスター・モデルです。つまり、トポロジ内のすべてのレプリケーション・サーバーが読取り操作と書込み操作の両方を処理できます。ただし、特定のディレクトリ・サーバーを読取り専用に設定できます。そのサーバーでは、LDAPクライアントからの追加操作、変更操作および削除操作が却下されます。

注意:

読取り専用ディレクトリ・サーバーは、Oracle Directory Server Enterprise Editionのレプリケーション・モデルにおけるコンシューマ・レプリカと同様に機能します。

26.7.1 レプリカの読取り専用としての構成

この例では、host1とhost2の2つのホストにレプリケーション・サーバーが存在するレプリケーション構成を想定しています。この例では、host2のディレクトリ・サーバーを読取り専用レプリカとして構成します。ここでは、dsconfigコマンドを使用します。このコマンドは、管理コネクタを介してサーバー構成にアクセスします。詳細は、第14.3項「サーバーへの管理トラフィックの管理」を参照してください。

dsconfigコマンドを使用してhost2のwritability-modeを設定します。

$ dsconfig -h host2 -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
set-global-configuration-prop --set writability-mode:internal-only

internal-onlyという書込み可能性モードは、サーバーでレプリケーション操作は処理されるが、LDAPクライアント・アプリケーションによるサーバーへの直接の書込みはできないことを意味します。

26.8 レプリケーションの非一貫性の検出および解決

ディレクトリ・サーバーのレプリケーションは、ハードウェアの故障やディレクトリ・サーバーの再起動、ネットワーク障害が発生しても、レプリケート対象データベース間の一貫性が維持されるように設計されています。しかし、それでも、ハードウェアの故障(ディスク・エラー、メモリー・エラー)やソフトウェアの不具合(これに起因するメモリーの破損)によってデータベース間に不整合が発生する可能性があります。

ここでは、レプリケーションの非一貫性を検出する方法と、非一貫性が確認された場合にそれを解決する方法について説明します。

26.8.1 レプリケーションの非一貫性の種類

非一貫性が発生しても、しばらくそれが顕在化しない場合もあれば、レプリケーション・エラーやアプリケーション・エラーが引き起こされる場合もあります。非一貫性の例を次に示します:

- あるエントリがレプリケーション・トポロジ内の1つのディレクトリ・サーバーを除くすべてのディレクトリ・サーバーに存在します。

- あるエントリのDNが1つのディレクトリ・サーバーでのみ、他のディレクトリ・サーバーと異なります。

- あるエントリの属性が1つのディレクトリ・サーバーでのみ、レプリケーション・トポロジ内の他のディレクトリ・サーバーと異なります。

26.8.2 非一貫性の検出

レプリケーションの非一貫性を確認するには、次の方法があります:

- レプリケーション・ログ・ファイル内の情報を確認する。レプリケーション・ログ・ファイルはデフォルトで構成されており、レプリケーション・メカニズムによって検出された非一貫性が記録されます。たとえば、トポロジ内の1つのディレクトリ・サーバーに存在しないエントリに対して変更操作が実行されたとします。レプリケーションがこの操作をこのサーバーに対してリプレイしようとすると、問題が検出され、logs/replicationエラー・ログにエラーが書き込まれます。この種のエラーによってレプリケーションが停止することはありませんが、操作がリプレイされないため、管理者は非一貫性を修正する必要があります。

- クライアント・アプリケーションまたはユーザーから報告されるエラーに注意する。クライアント・アプリケーションやユーザーがディレクトリ・サーバーへのアクセス時に、レプリケーションの非一貫性に起因する可能性のあるエラーに遭遇する場合があります。

- データベースの一貫性を定期的に確認する。現行のリリースのディレクトリ・サーバーでは、これらの確認は検索またはデータベース・エクスポートによって手動で行う必要があります。

26.8.3 非一貫性の解決

トポロジ内の単一のディレクトリ・サーバーでレプリケーションの非一貫性が検出された場合、通常のLDAP操作でこの非一貫性を修正することはできません。LDAP操作自体がトポロジ内の他のディレクトリ・サーバーにレプリケートされ、それらのサーバーを損傷するおそれがあるためです。また、修正には、ディレクトリ・サーバーによって生成された属性(entryuid属性、modifyTimestamp属性など)の変更が伴う場合もあります。こうした属性は通常のLDAP操作では変更できません。

したがって、レプリケーションの修復操作は、レプリケーション修復制御(OID: 1.3.6.1.4.1.26027.1.5.2)を指定するLDAP操作を使用して行う必要があります。

注意:

レプリケーション修復制御を使用すると、ディレクトリ・サーバーが通常行ういくつかの制御をスキップできます。このため、レプリケーション修復制御は、一貫性の問題が検出されアサートされた場合にのみ、細心の注意を払って使用してください。

修復制御により、操作の通常の処理が次のように変更されます:

- entryuuid、ds-sync-histなど通常は変更や追加ができない(NO-USER-MODIFICATION)属性を操作で変更できるようになります。

- 操作にレプリケーション変更番号が関連付けられません。

- 操作がレプリケーション・サーバーに公開されず、ローカルのみの操作になります。

- レプリケーションが競合の解決を試みないか、この操作の履歴情報を生成しません。

- この操作に対しては、ほとんどのスキーマ・チェックが実行されません。

たとえば、次のldapmodify操作は、changes.ldifファイルに格納されている変更を使用して、host1上のエントリのみを修復します:

$ ldapmodify -J 1.3.6.1.4.1.26027.1.5.2 -h localhost -p 1389 \
-D "cn=Directory Manager" -j pwd-file -f changes.ldif

エントリを修復するときには、その通常属性だけでなく、ディレクトリ・サーバーによって生成されたmodifyTimestamp、modifiersName、createTimestamp、creatorsName、ds-sync-histなどの属性もすべて修復する必要があります。これらの属性の値を、正しい値が格納されているディレクトリ・サーバーから読み取り、不適切な値があるサーバーで再作成してください。

ds-sync-hist属性には、レプリケーションによる変更の競合の解決に使用される履歴情報が保持されています。この属性を参照できるのは管理者のみです。

26.8.4 名前の競合の解決

サーバー同士が互いの変更をレプリケートする前にエントリが作成された場合、同じDNを持つエントリが別々のディレクトリ・サーバーで作成される場合があります。リモート操作がローカル・サーバーにレプリケートされると、名前の競合が発生します。名前の競合の結果として、競合エントリがローカル・サーバーに作成されます。

競合エントリは、entryuuid=entryUid+oldRDNという形式の固有のDNを持ちます。どの競合エントリにもds-sync-conflict属性があり、その値は競合する通常エントリのDNです。

たとえば、cn=bjensen,ou=People,dc=example,dc=comというエントリが2つのディレクトリ・サーバー上で同時に作成されたとします。サーバー1のエントリにはuid1という一意IDが割り当てられ、サーバー2のエントリにはuid2という一意IDが割り当てられます。レプリケーション後、どちらのディレクトリ・サーバーにも次の2つのエントリが存在することになります:

cn=bjensen,dc=example,dc=com
...
entryuuid=uid2+cn=bjensen,dc=example,dc=com
ds-sync-conflict:cn=bjensen,dc=example,dc=com

競合エントリを特定したら、そのエントリの名前を変更して一意のDNを与えることができます。

競合エントリのネーミング属性が複数値の場合、次のようにして競合エントリの名前を変更できます:

1. 古いRDN値を維持しながら、エントリ名を変更します。例:

$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file
dn: entryuuid=uid2+cn=bjensen,dc=example,dc=com
changetype: modrdn
newrdn: cn=bljensen
deleteoldrdn: 0
^D

この手順で古いRDN値は削除できません。これには、削除できないentryuuid操作属性も含まれているためです。

2. ネーミング属性の古いRDN値と競合マーカー属性を削除します。例:

$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file
dn: cn=bljensen,dc=example,dc=com
changetype: modify
delete: cn
cn: bjensen
delete: ds-sync-conflict
^D

dc(ドメイン・コンポーネント)など、競合エントリのネーミング属性が単一値の場合、エントリ名を単純に同じ属性の他の値に変更することはできません。かわりに、次のように仮の名前をエントリに付与する必要があります:

1. 異なるネーミング属性を使用してエントリ名を変更し、古いRDN値は維持します。たとえば、次のようになります:

$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file
dn: entryuuid=uid2+dc=HR,dc=example,dc=com
changetype: modrdn
newrdn: o=TempHR
deleteoldrdn: 0
^D

この手順で古いRDN値は削除できません。これには、削除できないentryuuid操作属性も含まれているためです。

2. 目的のネーミング属性を一意の値に変更して、競合マーカー属性を削除します。例:

$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file
dn: o=TempHR,dc=example,dc=com
changetype: modify
replace: dc
dc: NewHR
delete: ds-sync-conflict
^D

3. エントリ名を変更して目的のネーミング属性に戻し、仮のRDNを削除します。例:

$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file
dn: dc=NewHR,dc=example,dc=com
changetype: modrdn
newrdn: dc=NewHR
deleteoldrdn: 1
^D

26.9 履歴レプリケーション・データのパージ

Oracle Unified Directoryは、レプリケーション操作の結果としてサーバーで行われたすべての変更の履歴を維持します。この履歴レプリケーション・データは各ユーザー・エントリの属性に格納され、いずれ大量のディスク領域を占有する可能性があります。そのため、エントリが変更された時点で履歴情報はパージされます。または、管理者が明示的にコマンドを実行してデータをパージすることもできます。

デフォルトでは、1日以上経過した情報がパージされます。パージ対象とするデータの経過時間を指定するには、レプリケーション・ドメインのconflicts-historical-purge-delayプロパティの値を設定します。次の例では、5日以上経過したデータをパージするように指定します。このプロパティの値は分単位で指定します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
set-replication-domain-prop --provider-name "Multimaster Synchronization" \
--domain-name dc=example,dc=com --set conflicts-historical-purge-delay:7200m

また、履歴データを即時にパージしたり、タスクをスケジュールして指定時刻にデータをパージすることもできます。たとえば、あるサーバーを大量のエントリで初期化した後、それらのエントリに相当数の変更を加えたとします。その結果生成されたレプリケーション履歴データにより、データベースのサイズが大幅に増加します。その後、そのサーバーが主に読取り操作に使用された場合、履歴データのパージをトリガーする変更が行われないため、データベースのサイズは大きいままになってしまいます。この場合、1回かぎりのパージ・タスクを実行することで、初期変更によって生成された履歴データを削除し、データベースをより適切なサイズに戻すことができます。

パージ処理にはしばらく時間がかかる場合があるため、パージの最大継続時間を秒単位で指定する必要があります。履歴データを即時にパージするには、次のコマンドを実行します:

$ dsreplication -h localhost -p 4444 --adminUID admin --adminPasswordFile pwd.txt \
purge-historical --maximumDuration 3600 --baseDN dc=example,dc=com -X -n

スケジューリング・コマンドの詳細は、第14.4項「タスクとしてのコマンドの構成」を参照してください。

26.10 分離レプリカの使用

分離レプリカとは、他のレプリカから変更を受け入れてリプレイできるが、接続先のレプリケーション・サーバーに変更を送信できないディレクトリ・サーバーのことをいいます。分離レプリカは、トポロジに対するデータ更新のソースにはなれません。分離レプリカを使用すると、特定のディレクトリ・サーバーをレプリケーション・トポロジ内の他のサーバーから分離できます。

トポロジ内のすべてのディレクトリ・サーバーにtrusted構成プロパティがあります。このプロパティは、デフォルトではtrueに設定されています。トポロジ内の信頼できないサーバーとして構成すると、つまり、trusted構成プロパティをfalseに設定すると、分離レプリカとして認識されます。信頼できないディレクトリ・サーバーに由来するデータは、レプリケーション・サーバーによって破棄されます。これにより、分離レプリカがレプリケーション・トポロジ内でデータ更新のソースにならないことが保証されます。

信頼できるサーバーか信頼できないサーバーかを構成できるのは、ディレクトリ・サーバーのみです。レプリケーション・サーバーにはtrusted構成フラグがありません。

特定のディレクトリ・サーバーを信頼できないサーバーとして構成するには、次のようにdsreplication set-trustコマンドを使用します:

$ dsreplication --adminUID admin --adminPasswordFile pwd.txt -X \
set-trust --trustedHost host1 --trustedPort 4444 \
--modifiedHost host2 --modifiedPort 5444 --trustValue untrusted

dsreplication set-trustコマンドは、対話型モードと非対話型モードの両方でサポートされています。

信頼できるサーバーと信頼できないサーバーの構成には、次の制限があります:

- ディレクトリ・サーバーのtrustフラグは、トポロジ内の別の信頼できるサーバーからのみ構成できます。trustフラグは、構成対象のサーバー自体からは構成できません。したがって、-trustedHostオプションと--modifiedHostオプションが同じディレクトリ・サーバーを参照することはできません。

- ディレクトリ・サーバーをuntrustedからtrustedに変更する場合、変更対象のホストが稼働中であることが必要です。稼働していないと、コマンドが失敗します。

- ディレクトリ・サーバーをuntrustedからtrustedに変更する場合、信頼できない変更が変更対象のホストに存在しないことが必要です。信頼できない変更とは、信頼できないサーバーで行われた変更のことで、そのため、トポロジ内の他のサーバーには伝播されていない変更のことをいいます。変更対象のホストに信頼できない変更がある場合は、トポロジ内のいずれかの信頼できるサーバーの適切なデータ・セットを使用して、影響を受ける接尾辞を再初期化してから、ホストをtrustedに変更してください。

- 信頼できないサーバーのスキーマを変更すると、そのサーバーを信頼できるサーバーとして再構成できなくなります。この場合、そのサーバー・インスタンスを削除して作成しなおす必要があります。

ディレクトリ・サーバーが信頼できるサーバーか信頼できないサーバーかを調べるには、dsreplication statusコマンドを使用します。例:

$ dsreplication status --adminUID admin --adminPasswordFile pwd.txt -X \
--hostname host1 --port 4444

26.10.1 分離レプリカのデプロイメント・シナリオ

分離レプリカをレプリケーション・トポロジ内で使用するための主なシナリオには、次の2つがあります:

- 非武装地帯(DMZ)にセキュリティを追加するシナリオ

- クライアント・アプリケーションをステージング領域でテストするシナリオ

26.10.1.1 DMZでの分離レプリカの使用

非武装地帯(DMZ)とは、社内ネットワークの中で、インターネットなどの信頼できないネットワークに公開されている領域のことです。DMZは信頼できるネットワークと信頼できないネットワークの間に位置するため、保護層を備えています。外部からの直接アクセスは、DMZの内側に設置されている機器に限定されます。次の図は、DMZでの分離レプリカの使用方法を示しています。

図26-2 非武装地帯内の分離レプリカ

DMZ内に読取り専用ディレクトリ・サーバーを配置することで、危険にさらされているデータが社内ネットワークのプライベート領域内にあるレプリケーション・サーバーに伝播されないようにできます。レプリカをDMZ内にデプロイすると、そのレプリカは社内のファイアウォールで保護されないため、セキュリティが破られる危険性があります。このような場合、不正なユーザーがレプリカの構成にアクセスして、書込み可能なレプリカに変更してしまうおそれがあります。そのため、このようなレプリカに対し、ファイアウォールで保護されているレプリケーション・サーバーは信頼できないというレッテルを貼ります。

DMZ内のサーバーを信頼できないサーバーとして構成することで、悪意のあるデータをそれらのサーバーが受け入れないように保護できます。プライベート領域内のサーバーは、読取りおよび書込みアクセス権を持つように構成されています。この構成により、データ変更がプライベート領域内のディレクトリ・サーバーによってのみレプリケーション・トポロジ全体に伝播されることが保証されます。DMZ内の読取り専用ディレクトリ・サーバーは、プライベート・ネットワークの内側にあるレプリケーション・サーバーからデータ変更を取得します。外部の攻撃者がデータのセキュリティを破ろうとしても、直接アクセス・ポイントはDMZ内の読取り専用サーバーです。DMZ内のディレクトリ・サーバーは信頼できないサーバーなので、悪意のあるデータは伝播できません。したがって、プライベート社内LAN内のサーバー・データの整合性が守られます。

このシナリオには次の構成要件があります:

- DMZ内の各ディレクトリ・サーバーが信頼できないサーバーかつ読取り専用として構成されていること。

- トポロジ内の各レプリケーション・サーバーがプライベート社内LANの内側に位置していること。

- プライベート社内LAN内の各ディレクトリ・サーバーが読取り/書込みアクセス権を持つ信頼できるサーバーとして構成されていること。

トポロジ内の信頼できる各ディレクトリ・サーバーには次のアクセス権が付与されています:

- 接続先のレプリケーション・サーバーに変更を送信できます。この変更は、トポロジ内の他のすべてのディレクトリ・サーバーに伝播されます。

- 接続先のレプリケーション・サーバーから送信された変更をリプレイできます。

- 他のサーバーを初期化するためのオンライン完全更新操作のデータ・ソースになることができます。

トポロジ内の信頼できない各ディレクトリ・サーバーには次のアクセス制限があります:

- 接続先のレプリケーション・サーバーに変更を送信する権限がありません。信頼できないディレクトリ・サーバーが変更を送信すると、その変更は危険にさらされたデータと判定され、レプリケーション・サーバーはその変更を破棄します。

- 接続先のレプリケーション・サーバーから送信された変更をリプレイできます。

- 他のサーバーを初期化するためのオンライン完全更新操作のデータ・ソースになることができません。

26.10.1.2 分離レプリカを使用したテスト

ステージング領域でアプリケーションをライブ・データに対してテストするとき、分離レプリカを使用すると便利な場合があります。それには、分離レプリカを信頼できないサーバーとして構成し、読取り/書込みアクセス権を付与します。アプリケーションのアクセス・ポイントは分離レプリカであり、ステージング領域内の分離レプリカにのみデータが書き込まれます。

次の図は、ステージング領域での分離レプリカの使用方法を示しています。

図26-3 ステージング領域内の分離レプリカ

26.11 Oracle Directory Server Enterprise EditionとOracle Unified Directory間のレプリケーション

Oracle Unified Directoryは、Oracle Directory Server Enterprise EditionとOracle Unified Directoryの間でデータをレプリケートする仕組みを備えています。このレプリケーション・ゲートウェイの主な目的は、Oracle Directory Server Enterprise EditionからOracle Unified Directoryへの移行を可能にすることです。

この2つの異なるトポロジ間のレプリケーションを設定するには、次の3つのステップが必要になります:

- Oracle Directory Server Enterprise Editionのスキーマおよび構成からOracle Unified Directoryサーバーへの移行

- Oracle Directory Server Enterprise EditionサーバーとOracle Unified Directoryサーバー間のレプリケーションの構成

- Oracle Directory Server Enterprise EditionサーバーのデータによるOracle Unified Directoryサーバーの初期化

各ステップについては、次の手順説明を参照してください。これらの手順は、次の作業が完了していることを前提としています:

- Oracle Directory Server Enterprise Editionサーバーがインストールされており、稼働中であること。
Oracle Unified Directoryのレプリケーション・ゲートウェイは、DS6モードのパスワード・ポリシーのみをサポートしています。Oracle Directory Server Enterprise EditionのインスタンスでDS5モードのパスワード・ポリシーを使用している場合は、アップグレードする必要があります。

- Oracle Unified Directoryディレクトリ・サーバーがインストールされており、稼働中であること。
Oracle Unified Directoryサーバーは、Oracle Directory Server Enterprise Editionサーバーのデータで初期化されるため、接尾辞なしで構成されている必要があります。

レプリケート対象Oracle Unified Directoryトポロジがすでに存在する場合は、Oracle Unified Directoryサーバー・インスタンスをもう1つ接尾辞なしで作成し、そのサーバーをレプリケーション・ゲートウェイにアタッチします。すべてのds2oudコマンドをその空のOracle Unified Directoryサーバーに対して実行する必要があります。Oracle Directory Server Enterprise EditionサーバーとOracle Unified Directoryサーバーの間のレプリケーションが稼働しているとき、Oracle Unified Directoryサーバーを既存のレプリケート対象Oracle Unified Directoryトポロジに追加できます。

たとえば、既存のOracle Unified Directoryトポロジがあると仮定した場合、移行前のサーバー・レイアウトは次のようになります:

移行後のサーバー・レイアウトは次のようになります:

26.11.1 Oracle Directory Server Enterprise Editionのスキーマおよび構成の移行

Oracle Unified Directoryでは、すべてのパッチセットが適用されたSun ONE Directory Server 5.2、Sun Java System Directory Server Enterprise Edition 6.3.1、Sun Directory Server Enterprise Edition 7.0およびOracle Directory Server Enterprise Edition 11gリリース1 (11.1.1)の構成とスキーマを移行できます。このタイプのインスタンスの移行は、ds2oudコマンドを使用して実行できます。これらのバージョンのディレクトリはds2oudツールでのみサポートされていますが、レプリケーション・ゲートウェイ(Oracle Directory Server Enterprise Edition 11gリリース1 (11.1.1)以上が必須です)の使用についてこのかぎりではありません。

つまり、移行するインスタンスのバージョンによっては、生成されるOracle Unified Directoryインスタンスが完全に機能するためには、手動での補足の手順が必要になります。たとえば、オブジェクト・クラスおよびパスワード・ポリシーに関するデータの変更やメタデータの変換などです。ただし、Oracle Directory Server Enterprise Edition 11gリリース1 (11.1.1)以上を実行している場合は、この項の手順2 aで説明するユーザー・データのエクスポート時に自動的にデータ変換が行われます。

この項の手順では、ds2oudコマンドの様々なオプションについて説明します。コマンドラインでds2oudを入力すると、ds2oudコマンドを完全に対話型で実行できます。対話型モードでは、応答を要求するプロンプトが表示されます。詳細は、第A.2.3項「ds2oud」を参照してください。

1. Oracle Unified Directoryディレクトリ・サーバーで、ds2oud --diagnoseコマンドにOracle Directory Server Enterprise Editionサーバーの接続詳細を指定して実行します。ds2oudコマンドは、instance_dir/OUD/bin (Linuxの場合)またはinstance_dir\OUD\bat (Windowsの場合)にあります。
このコマンドは、Oracle Directory Server Enterprise Editionサーバー・インスタンスを評価して、いずれかのサーバー構成をOracle Unified Directoryサーバーに移行する必要があるかどうかを報告します。

$ ds2oud --diagnose -h host1.example.com -p 1389 \
-D "cn=directory manager" -j pwdfile

--diagnoseサブコマンドは、Oracle Directory Server Enterprise Editionの次の構成要素を調べます:

- 有効なユーザー・プラグイン

- 有効なサブツリー・エントリ・カウンタ・プラグイン(サブツリー・エントリ・カウンタ・プラグインはOracle Unified Directoryではサポートされていません)

- デフォルトのスキーマに対する拡張

- CoSまたはロール定義

- マクロACI

- ACI構文の妥当性

- パスワード・ポリシーの種類(DS6モードのみがサポートされています)

- データ内の競合するエントリ

- 暗号化された属性(属性の暗号化はOracle Unified Directoryではサポートされていません)

2. Oracle Unified Directoryスキーマに関するデータのコンプライアンスを検証するために、次の操作を行います:

1. Oracle Directory Server Enterprise EditionデータをLDIFにエクスポートします。

Oracle Directory Server Enterprise Editionサーバーで、次の例のようにdsconf exportコマンドを実行します:

$ dsconf export -f opends-export -h host1.example.com -p 1389 \
dc=example,dc=com odsee-data.ldif

注意:

前述のコマンドの-f opends-exportオプションは、Oracle Directory Server Enterprise Edition 11gリリース1 (11.1.1)にのみ適用可能です。

移行時にopends-exportオプションを使用すると、DSEE固有の属性が一部のエントリに存在する場合があり、これらのエントリがインポートされないようにできます。たとえば、nds5replconflictがOracle Directory Server Enterprise Editionのデータに存在する場合があります。そのため、Oracle Unified Directoryへのインポート時に、次のインポート・オプションを使用してこの属性をフィルタする必要があります。

--excludeAttribute "nsds5replconflict"

2. データをLDIFにエクスポートしたら、Oracle Unified Directoryでds2oudコマンドを実行します。例:

$ ds2oud --ldifDBFile odsee-data.ldif --userSchemaFile 99user.ldif

odsee-data.ldifは、LDIFにエクスポートされたOracle Directory Server Enterprise Editionのデータです。99user.ldifは、Oracle Directory Server Enterprise Editionのカスタマイズされたスキーマ・ファイルです(Oracle Directory Server Enterprise Editionのスキーマをカスタマイズした場合)。

このコマンドは、Oracle Directory Server Enterprise EditionのデータとOracle Unified Directoryのスキーマの間にスキーマの不整合がないかを調べます。データを移行する前に、Oracle Directory Server Enterprise Editionのデータが必要とするスキーマ拡張をOracle Unified Directoryのスキーマに追加する必要があります。

3. ds2oudコマンドに1つまたは複数の移行オプションを指定して実行し、スキーマ、サーバー構成またはその両方を移行します。
Oracle Unified Directoryがデータを検証できるように、スキーマを移行してから構成を移行する必要があります。

1. ds2oud --migrateUserSchemaを実行すると、Oracle Directory Server Enterprise Editionのユーザー・スキーマ(通常は99user.ldifファイルに格納されています)がOracle Unified Directoryのスキーマに追加されます。
Oracle Unified Directoryで集合属性またはパスワード・ポリシーの機能をレプリケートする場合は、これらの機能用にOracle Directory Server Enterprise Editionのスキーマを準備する必要があります。Oracle Unified Directoryでは、次の場所にカスタム・スキーマ・ファイル(99OudSchemaExtract.ldif)が用意されています。
install-dir/OracleUnifiedDirectory/config/ds2oud
このファイルを使用して、Oracle Unified Directory固有のスキーマ要素をOracle Directory Server Enterprise Editionインスタンスに追加できます。

このスキーマ・ファイルをOracle Directory Server Enterprise Editionスキーマに追加する方法の詳細は、Oracle Directory Server Enterprise Edition管理ガイドのカスタム・スキーマ・ファイルによるスキーマの拡張に関する項を参照してください。

2. ds2oud --migrateConfigurationを実行すると、次の操作が行われます:

- Oracle Directory Server Enterprise Editionの既存の接尾辞に基づいてネーミング・コンテキストが作成されます。ネーミング・コンテキストを単一の共有ワークフロー要素(userRoot)に作成するか、接尾辞ごとのワークフロー要素に作成するかを指定できます。構成にサブ接尾辞が含まれている場合は、強制的に接尾辞ごとのワークフロー要素に作成されます。

- Oracle Unified Directoryに適用されるいくつかのグローバル構成パラメータ(size-limit、lookthrough-limit、idle-time-limit、max-psearches、bind-with-dn-requires-passwordなど)が移行されます。

- グローバルおよびバックエンドallidsthresholdパラメータがOracle Unified Directoryのindex-entry-limitバックエンド・プロパティに移行されます。

- 構成されている索引があれば追加され、索引または索引タイプ上の固有のallidsthresholdパラメータが新しい索引に移行されます。

- DSE ACIがds-cfg-global-aciに翻訳され、Oracle Unified Directoryの構文検証を使用してACIの妥当性が確認されます。

- 可能な場合は、7ビット・チェック、UID一意性、参照整合性、強力なパスワード・ポリシー・チェックの各プラグインの構成が移行されます。

- パスワード・ポリシーが設定され、デフォルトのパスワード・ポリシーがOracle Directory Server Enterprise Editionのデフォルトのパスワード・ポリシーに対応するように構成されます。移行が可能なのは、DS6モードのパスワード・ポリシーを使用しているOracle Directory Server Enterprise Editionサーバーの場合のみです。

3. スキーマおよび構成パラメータを移行するには、次のコマンドを実行します:

$ ds2oud --migrateAll -D "cn=directory manager" -j pwdfile \
-h host1.example.com -p 1389 \
--oudBindDN "cn=directory manager" --oudBindPasswordFile pwdfile \
--oudHostname localhost --oudAdminPort 4444 --oudPort 1389

-D、-j、-hおよび-pには、Oracle Directory Server Enterprise Editionインスタンスの接続パラメータを指定します。

ほんどのACIはエントリ自体に格納されています。したがって、Oracle Directory Server Enterprise EditionインスタンスからデータをエクスポートしてOracle Unified Directoryインスタンスにインポートするときに移行されます。--migrateAllサブコマンドは、構成に格納されているグローバルACIのみを移行します。

Oracle Unified Directoryの構成に関連する追加情報の入力を求められます。このコマンドにより、互換性のある構成がOracle Unified Directoryディレクトリ・サーバー上に作成されます。

26.11.2 Oracle Directory Server Enterprise EditionとOracle Unified Directory間のレプリケーションを構成するには

Oracle Fusion Middleware Oracle Unified Directoryインストレーション・ガイドのレプリケーション・ゲートウェイの設定に関する項の説明に従って、レプリケーション・ゲートウェイをインストールして構成します。

この時点で、Oracle Unified Directoryサーバーでレプリケーション用のグローバル管理者を構成する必要があります。このサーバーを後で既存のレプリケート対象Oracle Unified Directoryトポロジに接続する予定の場合は、他のOracle Unified Directoryサーバーで定義されている同じグローバル管理者の資格証明を使用します。

26.11.3 Oracle Unified DirectoryをOracle Directory Server Enterprise Editionのデータで初期化するには

1. 初期化するOracle Unified Directoryサーバーを準備します。例:

$ dsreplication pre-external-initialization -h localhost -p 4444 \
--adminUID admin --adminPasswordFile pwd.txt --baseDN dc=example,dc=com \
-X -n --noPropertiesFile

2. Oracle Directory Server Enterprise Editionサーバーで、次のコマンドを実行してデータ・セットをエクスポートします:

$ dsadm export -f opends-export dsee-instance-path baseDN exportedLDIFPath

exportedLDIFPathは生成されるLDIFファイルのパスです。このファイルにレプリケート対象データが格納されます。

Oracle Directory Server Enterprise Editionデータに暗号化された属性が含まれている場合は、--decrypt-attrオプションを指定して復号化します。

注意:

dsadm exportは、LDIF形式のファイルを作成します。

dsadm backupは、Oracle Directory Server Enterprise Editionサーバーのデータベース・ファイルのバイナリ・コピーを作成します。Oracle Directory Server Enterprise EditionとOracle Unified Directoryではデータベースの実装が大きく異なるため、一方のサーバー・タイプからもう一方のサーバー・タイプへデータをエクスポートするときにバイナリ・コピーは使用できません。

3. 手順1で生成されたLDIFファイルを、Oracle Unified Directoryサーバーがアクセスできるディレクトリにコピーします。LDIFファイルのファイル権限でサーバーによる読取りアクセスが許可されていることを確認します。

4. Oracle Unified Directoryサーバーで、次のようにLDIFデータをインポートします:

$ import-ldif -h localhost -p 4444 -D "cn=directory manager" -j pwd-file \
--includeBranch dc=example,dc=com --ldifFile path/to/exportedLDIFFile \
--clearBackend --trustAll --noPropertiesFile

LDIFファイルの相対パスを指定する場合、相対パスのルートは現在の作業ディレクトリではなく、インスタンスのルートであることに注意してください。したがって、たとえば、imports/odsee-data.ldifというパスはinstance-root/imports/odsee-data.ldifを指します。

5. Oracle Unified Directoryサーバーで初期化後のスクリプトを実行します。例:

$ dsreplication post-external-initialization -h localhost -p 4444 \
--adminUID admin --adminPasswordFile pwd.txt --baseDN dc=example,dc=com \
-X -n --noPropertiesFile

6. レプリケーションが正常に動作することをテストするために、各Oracle Directory Server Enterprise Editionサーバーで少なくとも1つのエントリを変更し、Oracle Unified Directoryサーバーで変更を確認します。

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

スキーマでは、ディレクトリへの格納が可能な情報オブジェクトのタイプが定義および制御されます。スキーマによって、ディレクトリ情報ツリー内のエントリのタイプが定義され、要素の一意性が維持されます。また、新しい要素がディレクトリに追加されるときに発生することがある未チェックのスキーマの増大が防止されます。

この章では、ディレクトリ・サーバーに付属しているスキーマの表示手順と拡張手順について説明します。この章の内容は次のとおりです:

- 第27.1項「Oracle Unified Directoryスキーマの概要」

- 第27.2項「スキーマ・チェックの構成」

- 第27.3項「オブジェクト識別子(OID)の使用」

- 第27.4項「スキーマの拡張」

- 第27.5項「スキーマのレプリケート」

- 第27.6項「Oracle Directory Services Managerを使用したスキーマの管理」

個々のスキーマ要素の詳細は、第9章「Oracle Unified Directoryスキーマ・モデルの理解」を参照してください。

27.1 Oracle Unified Directoryスキーマの概要

ディレクトリ・サーバー・インスタンスは、起動時に一度スキーマを読み取ります。その後、スキーマ情報を使用して、検索フィルタ・リクエストまたはアサーションをエントリの属性と照合し、追加または変更操作がクライアントによって許可されているかどうかを判定します。

通常、ほとんどのアプリケーションにはデフォルトのスキーマで間に合います。しかし、ディレクトリ・サーバーの柔軟性を活用して、アプリケーションに合せてスキーマを拡張することもできます。一般的な手順では、新しいカスタムのスキーマの採用時に標準のスキーマを放棄するのではなく、標準の属性またはオブジェクト・クラスを可能なかぎり使用します。標準のスキーマで処理されないカスタム属性またはオブジェクト・クラスが必要な場合は、アプリケーションで必要な補助属性およびオブジェクト・クラスを使用して標準のスキーマを拡張することによって、スキーマを作成できます。

スキーマはディレクトリ内の接尾辞(cn=schema)の下に格納されます。またディレクトリ・サーバーには、スキーマ要素を定義するサブスキーマ・サブエントリと、ディレクトリでの操作属性セットも格納されます。

スキーマは次の2つの方法のいずれかで拡張できます:

- LDAPを介してスキーマを拡張します。

- カスタムのスキーマ定義ファイルを作成します。

27.1.1 スキーマの設計および拡張

デフォルト・スキーマの拡張または独自のスキーマの設計について検討する場合は、事前にスキーマの構文と設計を確実に理解する必要があります。

スキーマの設計または拡張の基本手順は次のとおりです:

1. データをデフォルト・スキーマにマップします。ディレクトリ・サーバーに定義されている既存のスキーマ要素をできるかぎり使用します。標準のスキーマ要素は、ディレクトリ対応アプリケーションとの互換性を確保するうえで役立ちます。スキーマはLDAP標準に基づいているため、多数のディレクトリ・ユーザーからレビューされ、これらのユーザーの合意を得ています。

2. 一致しないデータを特定します。デフォルト・スキーマは様々な情報オブジェクトに対応するように設計されています。しかし、特定のデータ型がこのスキーマで処理されない場合は、そのデータをメモするとともに、ディレクトリに必要な他のデータ型をメモします。

3. デフォルト・スキーマを拡張して、新しい要素を定義します。最適なパフォーマンスを達成するには、できるかぎり既存のスキーマ要素を再利用します。また、各オブジェクト・クラスに対して定義する必須属性を最小限に抑えます。スキーマはできるかぎり簡潔にします。同じ目的に対して複数のオブジェクト・クラスまたは属性を定義しないでください。

4. スキーマ・チェックを使用します。スキーマ・チェックによって、属性とオブジェクト・クラスをスキーマ・ルールに準拠させることができます。

5. 一貫性のあるデータ書式を選択し、適用します。LDAPスキーマでは、属性値に任意のデータを設定できます。しかし、LDAPクライアント・アプリケーションおよびディレクトリ・ユーザーに適した書式を選択して、一貫性のある方法でデータを格納するようにしてください。

27.1.2 デフォルト・スキーマ・ファイル

ディレクトリ・サーバー付属のデフォルト・スキーマは、OUD_ORACLE_HOME/config/schemaに格納されたLDIFファイルの集合です。これらのスキーマ・ファイルは、そのOUD_ORACLE_HOMEに関連付けれたすべてのサーバー・インスタンスに適用されます。

ディレクトリ・サーバー・インスタンスは、サーバーの起動時にスキーマ・ファイルを英数字順に(数字が先)ロードします。

注意:

これらのファイル内の標準のスキーマ定義と内部操作属性は決して変更しないでください。

次の表で、各デフォルト・スキーマ・ファイルとそれぞれのファイルの内容を説明します。

表27-1 デフォルト・スキーマ・ファイル

スキーマ・ファイル

説明

00-core.ldif

LDAPv3標準ユーザーおよび組織に関するスキーマ定義を格納します。

01-pwpolicy.ldif

draftldappolicyドラフトに基づくパスワード・ポリシーに関するスキーマ定義を格納します。

02-config.ldif

ディレクトリ構成ファイル内の属性とオブジェクト・クラスの定義に関するスキーマ定義を格納します。

03-changelog.ldif

draftldap-changelogに基づくディレクトリ・データの変更の格納に関するスキーマ定義を格納します。

03-rfc2713.ldif

RFC 2713に基づくLDAPディレクトリでのJavaオブジェクトの表現に関するスキーマ定義を格納します。

03-rfc2714.ldif

RFC 2714に基づくLDAPディレクトリでのCORBAオブジェクト参照の表現に関するスキーマ定義を格納します。Common Object Request Broker Architecture (CORBA)は、マルチベンダー、マルチプラットフォーム環境でCORBAオブジェクトを使用してマシンを統合します。ディレクトリ・サーバーをCORBAオブジェクト参照のリポジトリにすることで、CORBAに準拠したアプリケーションでのサービスの集中管理が可能になります。

03-rfc2739.ldif

RFC 2739に基づくvCardディレクトリのカレンダ属性の表現に関するスキーマ定義を格納します。カレンダ・アプリケーションは、ディレクトリ内に配置されている、個人のカレンダのURIを特定するようにカレンダ・ユーザー・エージェントに要求します。RFC 2739の定義にはエラーが多数含まれています。これらのいくつかの問題を修正するために、このスキーマ・ファイルは標準の定義を変更したものとなっています。

03-rfc2926.ldif

RFC 2926に基づくサービス・ロケーション・プロトコル(SLP)通知のマッピングに関するスキーマ定義を格納します。この仕様は、SLPテンプレートとLDAPディレクトリ・スキーマ間のマッピングを作成するSLPディレクトリ・エージェント・バックエンドをディレクトリ・サーバーで処理することを可能にします。

03-rfc3112.ldif

RFC 3112に基づく認証パスワード構文に関するスキーマ定義を格納します。

03-rfc3712.ldif

RFC 3712に基づくディレクトリでのプリンタ情報の格納に関するスキーマ定義を格納します。

03-uddiv3.ldif

RFC 4403に基づくディレクトリでのUDDI v3情報の格納に関するスキーマ定義を格納します。Universal Description, Discovery and Integration (UDDI)は、企業向けの、プラットフォームに依存しないXMLベースのインターネット上のレジストリです。UDDIによって、企業はインターネットを介してサービス・リストを公開できます。UDDIでは、どのソフトウェア・アプリケーションがインターネット上で相互作用を行うかが定義されます。

04-rfc2307bis.ldif

draftrfc2307bisに基づくディレクトリでのネーミング・サービス情報の格納に関するスキーマ定義を格納します。

05-rfc4876.ldif

ディレクトリ・ユーザー・エージェント(DUA)のプロファイルおよびプリファレンスのスキーマを定義するRFC 4876に基づくスキーマ定義を格納します。

05-solaris.ldif

SolarisおよびOpenSolaris LDAPネーミング・サービスに必要なスキーマ定義を格納します。

06-compat.ldif

ディレクトリ・サーバー構成で使用する属性タイプとオブジェクト・クラスの定義を格納します。

10-ad-paging.ldif

Active Directoryページング関数に必要なスキーマ定義を格納します。

10-distribution.ldif

プロキシ・サーバー・インスタンスの配信機能に必要なスキーマ定義を格納します。

10-global-index-catalog.ldif

プロキシ・サーバー・インスタンスのグローバル索引付け機能に必要なスキーマ定義を格納します。

10-loadbalancing.ldif

プロキシ・サーバー・インスタンスのロード・バランシング機能に必要なスキーマ定義を格納します。

10-proxy.ldif

プロキシ・サーバー・インスタンス固有のスキーマ定義を格納します。

10-replication-gateway.ldif

レプリケーション・ゲートウェイ・サーバー・インスタンス固有のスキーマ定義を格納します。

10-virtualization.ldif

プロキシ・サーバー・インスタンスの仮想化機能に必要なスキーマ定義を格納します。

27.2 スキーマ・チェックの構成

Oracle Unified Directoryは、新規書込みまたは追加エントリがディレクトリ・サーバーのスキーマに準拠しているかどうかを検証するスキーマ・チェック・メカニズムを備えています。このメカニズムによって、import-ldifを使用してインポートされるデータや、ldapmodifyを使用して追加されるデータをスキーマの構文ルールに確実に準拠させることができます。

スキーマ・チェック構成は拡張グローバル構成の一部であり、次のコマンドを使用して表示できます:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
--advanced get-global-configuration-prop
Property                               : Value(s)
---------------------------------------:---------------------------------------
...
check-schema                           : true
...
invalid-attribute-syntax-behavior      : reject
...
single-structural-objectclass-behavior : reject
...

スキーマ・チェックは次の構成プロパティによって制御されます:

- check-schema: 使用可能な値は、true(デフォルト)、falseです。このプロパティでは、新たにインポートまたは追加されるエントリに対してディレクトリ・サーバーでスキーマ・チェックを実行するかどうかが制御されます。デフォルトでは、このプロパティはtrueに設定されます。最大のパフォーマンスが得られるようにサーバーを構成する必要があり、スキーマ違反を発生させる変更をクライアントが行わないことが確実であれば、このプロパティをfalseに設定できます。ディレクトリにもたらす可能性があるリスクと比較すると、パフォーマンス上の利点はわずかしかありません。

- invalid-attribute-syntax-behavior: 使用可能な値は、reject(デフォルト)、acceptおよびwarnです。このプロパティでは、関連付けられた構文に違反する属性値の使用が試みられた場合のサーバーの動作が制御されます。デフォルトでは、サーバーはスキーマに違反する属性を使用するあらゆるリクエストを拒否します。このプロパティがacceptに設定されている場合、サーバーは属性違反を警告なしで受け入れます。このプロパティがwarnに設定されている場合、サーバーは違反を受け入れますが、エラー・ログにメッセージを書き込みます。check-schemaプロパティがfalseに設定されている場合、無効な属性構文のチェックは適用されません。

- single-structural-objectclass-behavior: 使用可能な値は、reject(デフォルト)、acceptおよびwarnです。このプロパティでは、構造化オブジェクト・クラスを正確に1つ持っているという条件に一致しないエントリの作成または変更が試みられた場合のサーバーの動作が制御されます。つまりデフォルトでは、構造化オブジェクト・クラスをまったく持たないかまたは複数持つオブジェクト・クラスは拒否されます。このプロパティがacceptに設定されている場合、構造化オブジェクト・クラスを持たないエントリが許可されます。このプロパティがwarnに設定されている場合、構造化オブジェクト・クラスをまったく持たない(または複数持つ)エントリが許可されますが、エラー・ログにメッセージが書き込まれます。check-schemaプロパティがfalseに設定されている場合、単一構造化オブジェクト・クラス・チェックは適用されません。

注意:

これらのプロパティの値をデフォルトから変更すると、スキーマの整合性が危険にさらされるため、通常は、これらの値を変更しないでください。

27.3 オブジェクト識別子(OID)の使用

オブジェクト識別子(OID)は、ディレクトリ内のオブジェクトを一意に識別するために使用される数値文字列です。OIDは、ディレクトリ・スキーマ、制御および拡張操作で要素の一意の識別を必要とする場合に使用されます。

LDAPオブジェクト・クラスおよび属性にはベース・オブジェクト識別子(OID)が必要です。ディレクトリでの名前の競合を避けるために、このOIDは、組織内で一意にする必要があります。ディレクトリを組織の内部で使用することを計画している場合は、ディレクトリ・サーバーで提供されるOIDを使用してください。スキーマをエクスポートすることや、なんらかの方法でスキーマを公開することを計画している場合は、自組織用の一意のOIDのリクエストを入力することを検討してください。詳細は、第27.3.1項「ベースOIDの取得」を参照してください。

ベースOIDの取得後、組織のオブジェクト・クラスと属性用にそのOIDにブランチを追加できます。たとえば、ディレクトリ・サーバーは、割当て済ベースOIDとして1.3.6.1.4.1.26027を使用します。コンポーネント・タイプごとに、ディレクトリ・サーバーは各スキーマ・コンポーネントのベースOIDに一意のブランチ番号を提供します。

Oracle Unified Directoryは包括的なOIDセットを備えおり、ほとんどのアプリケーションにはこのセットで間に合います。

次の表に、各スキーマ・コンポーネントに使用されるベースOIDを示します:

表27-2 各スキーマ・コンポーネントに使用されるベースOID

OID値

タイプ

1.3.6.1.4.1.26027.1.1

属性

1.3.6.1.4.1.26027.1.2

オブジェクト・クラス

1.3.6.1.4.1.26027.1.3

属性構文

1.3.6.1.4.1.26027.1.4

一致ルール

1.3.6.1.4.1.26027.1.5

制御

1.3.6.1.4.1.26027.1.6

拡張操作

1.3.6.1.4.1.26027.1.9

一般的な使用

1.3.6.1.4.1.26027.1.999

試験的な使用

スキーマ・タイプごとに、一意のブランチ番号がベースOIDに追加されます。たとえば、属性タイプでは、ブランチ番号1が使用され、1.3.5.1.4.1.26027.1.*1*というOIDが形成されます。ディレクトリ・サーバーによって、個々の属性タイプごとに別のブランチ番号セットが1つずつ割り当てられます。

次の表に、各属性タイプに割り当てられたOID値のリスト(一部)を示します。

表27-3 各属性タイプに割り当てられたOID値

OID値

属性のタイプ

1.3.6.1.4.1.26027.1.1.1

ds-cfg-java-class

1.3.6.1.4.1.26027.1.1.2

ds-cfg-enabled

1.3.6.1.4.1.26027.1.1.3

ds-cfg-allow-attribute-name-exceptions

1.3.6.1.4.1.26027.1.1.4

ds-cfg-allowed-client

1.3.6.1.4.1.26027.1.1.5

ds-cfg-allow-ldap-v2

Oracle Unified Directoryでは非数値OIDを使用できます。ただし、対応する数値OIDがスキーマ内で定義されていることが前提となります。たとえば、名前付き属性myTestAttributeに対して、非数値OID、mytestattribute-oidを使用できます。非数値OIDは、すべて小文字で構成され、名前付き属性に-oidが付加されたものである必要があります。非数値OIDの使用はLDAP仕様違反ですが、使いやすさを考慮して許容されています。

27.3.1 ベースOIDの取得

ディレクトリ・サーバーを公開することを計画している場合や、スキーマ定義をカスタム・アプリケーション用に再配布することを計画している場合は、自組織用のベースOIDを取得できます。ディレクトリ・サーバーのカスタム拡張を作成することを計画している場合は、カスタム・スキーマ・ファイルで独自のOIDを使用できます。または、ベースOIDをそのブランチ番号とともに追加することによって、スキーマ構成ファイルを変更できます。

注意:

デフォルトOIDの変更は、この操作の影響を十分に理解している場合を除いて、行わないでください。OIDを変更すると、ディレクトリ・サーバーが破損する可能性があります。

組織用のベースOIDを取得および作成する手順は次のとおりです:

1. ブラウザから、Internet Assigned Numbers Authority (IANA)のWebサイト(http://www.iana.org)またはこの種のタスクを行っている国内組織のサイトにアクセスします。国によっては、企業にすでにOIDが割り当てられています。自組織用のOIDがまだ割り当てられていない場合は、IANAのWebサイトでリクエストを入力できます。

2. 一意のオブジェクト・クラス、属性、名前およびその他のスキーマ要素について決定します。スキーマの管理を容易化するために、わかりやすい名前を使用してください。カスタムのオブジェクト・クラスと属性にカスタムの接頭辞を追加するのも1つの方法です。たとえば、Example.comという組織の場合、各カスタム・スキーマ要素の前にExampleという接頭辞を追加します。例として、Personというオブジェクト・クラスがある場合、このクラスにExampleを付けて、ExamplePersonとします。

3. OIDの割当てを追跡するためのOIDレジストリを作成します。このレジストリは単なるリストであり、このリストを管理することによって、各OIDとその説明をディレクトリ内で確実に一意のものにします。このレジストリには十分な保護を適用し、特権のある管理者以外、このレジストリを変更できないようにします。

4. スキーマ要素を格納するブランチをOIDツリー内に作成します。

5. トポロジ内のディレクトリ・サーバーを停止します。

6. トポロジ内の各ディレクトリ・サーバーでスキーマ構成ファイルを手動で編集します。各OIDを自社のOIDに置き換えます。それによって、スキーマ・レプリケーションでのスキーマ内の相違の認識と情報の同期試行に関連する問題が回避されます。

7. カスタムのスキーマ拡張を手動で編集します。理想的には、カスタム拡張はいずれも別のファイルで定義します。

27.4 スキーマの拡張

Oracle Unified Directoryでは、複数のスキーマ拡張方法をサポートしています。標準のスキーマ・ファイルは、OUD_ORACLE_HOME/config/schemaにあるLDIFファイル・セットです。これらのファイルの直接的な変更は行わないでください。このような変更によって、サーバーが予測不可能な動作を起こす可能性があります。

標準のスキーマ定義は、そのOUD_ORACLE_HOMEに関連付けられた各サーバー・インスタンスに適用されます。instance-dir/OUD/config/schema/99user.ldifにあるカスタム・スキーマ定義は、その定義の作成場所のサーバー・インスタンスにのみ適用されます。

スキーマは次の方法で拡張できます:

- LDAPを介してスキーマを拡張します。スキーマ拡張を定義してLDIFファイルに定義を書き込み、ldapmodifyコマンドを使用してカスタム・スキーマ拡張を追加します。
この方法を使用した場合、ディレクトリ・サーバーによって、新しいスキーマ定義が次のファイルに自動的に書き込まれます:

instance-dir/OUD/config/schema/99user.ldif

別のスキーマ・ファイルを指定するには、X-SCHEMA-FILE要素をスキーマ・ファイルの名前とともに含めます。たとえば、属性タイプ定義の一部として、要素X-SCHEMA-FILE '98myschema.ldif'を含めます。

LDAPを介してスキーマを拡張した場合は、サーバーを再起動しなくてもスキーマの変更が考慮されます。

- カスタム・スキーマ・ファイルを作成します。定義を格納したカスタム・スキーマ・ファイルを作成し、そのファイルを次のディレクトリに移動します:

instance-dir/OUD/config/schema/

ディレクトリ・サーバーはスキーマ・ファイルを英数字順に(数字が先)ロードします。そのため、カスタム・スキーマ・ファイルには[00-99]filename.ldifという名前を付けてください。この数字は、定義済の標準のスキーマ・ファイルのどれよりも大きい数字にします。カスタム・スキーマ・ファイル名で標準のスキーマ・ファイルよりも小さい数字を使用した場合、サーバーでスキーマのロード時にエラーが発生することがあります。

カスタム・スキーマ・ファイルでスキーマを拡張した場合は、サーバーを再起動しないと、スキーマの変更は考慮されません。

- 既存のスキーマ・ファイルを変更します。instance-dir/OUD/config/schema/99user.ldifなどの既存のスキーマ・ファイルにカスタムのスキーマ拡張を追加します。
既存のスキーマ・ファイルを変更してスキーマを拡張した場合は、サーバーを再起動しないと、スキーマの変更は考慮されません。

新しいスキーマ要素を追加するときには、すべての属性を定義する必要があります。未定義の属性はオブジェクト・クラスで使用できません。他のオブジェクト・クラスから継承されるオブジェクト・クラスをいくつか作成する場合は、先に親のオブジェクト・クラスを作成する必要があります。

作成するカスタムの各属性またはオブジェクト・クラスは、1つのスキーマ・ファイルのみで定義する必要があります。

新しいスキーマ定義を手動で定義するときのベスト・プラクティスは、99user.ldifファイルまたは任意のスキーマ・ファイルにこの定義を追加することです。

27.4.1 属性タイプの管理

スキーマに新しい属性タイプを追加するには、ldapmodifyコマンドを使用します。属性タイプの構文では、新しい要素の定義時には、少なくとも有効なOIDを指定する必要があります。標準的なアプリケーションでは、オプションで、属性タイプに関する次の識別子を含めることができます。属性タイプ要素の完全セットの詳細は、第9.3項「属性タイプの理解」を参照してください。

OID

必須。ディレクトリ・サーバー内でその属性タイプを一意に識別するOIDを指定します。LDAP v3仕様では、OIDにはUTF-8エンコードのドット区切り10進数を使用することが要件となっています。しかし、Oracle Unified Directoryでは、識別を容易化するため、スキーマが組織の内部で使用される場合にかぎり、非数値OIDの使用をサポートしています。書式はattributename-oidです(例: telephoneNumber-oid)。非数値OIDを使用する場合は、非数値OIDごとに、対応するドット区切り10進数のOIDがスキーマで定義されていることが必要です。

NAME

オプション。その属性タイプについて言及するときに使用する、判読可能な名前セットを指定します。名前が1つのときは、一重引用符で囲みます(例: 'blogURL')。名前が複数あるときは、一重引用符で囲んだ各名前をスペースで区切り、名前セット全体をカッコで囲みます(例: ('blog' 'blogURL'))。左カッコと名前の間および右カッコの前に1つずつ、必ずスペースを挿入してください。

SUP

オプション。属性タイプに別の属性タイプの要素を継承させる場合に、上位属性タイプを指定します。一致ルールと属性構文の仕様を上位属性タイプから下位タイプに継承できます。ただし、これは、上位属性タイプの定義よりも優先される下位タイプの定義が存在しない場合です。上位属性タイプのOID、上位属性タイプに関連付けられた判読可能ないずれかの名前またはこの両方を、すべての下位属性タイプを一括参照する目的で使用できます。

DESC

オプション。その属性タイプに関する判読可能な説明を指定します。

SYNTAX

オプション。その属性タイプで使用する属性構文を指定します。指定する場合は、数値OIDとして指定します。RFC 4517(http://www.ietf.org/rfc/rfc4517.txt)の第3.3項および同じドキュメントの付録Aで、コア構文が定義されています。

SINGLE-VALUE

オプション。そのタイプの属性を含むエントリでそのタイプの属性に対して単一値のみを指定可能とするかどうかを指定します。SINGLE-VALUEが指定されていない場合、同じエントリ内で複数の固有の値をその属性に対して指定できます。

NO-USER-MODIFICATION

オプション。そのタイプの属性の値を外部クライアントが変更不能かどうか(つまり、ディレクトリ・サーバー内部の処理によってのみ値の変更が可能かどうか)を示します。

USAGE

オプション。その属性の用途を示します。使用可能な値は次のとおりです。userApplications: ユーザー・データの格納に使用。directoryOperation: ディレクトリ・サーバー内部の処理に必要なデータの格納に使用。distributeOperation: トポロジ内のディレクトリ・サーバー間で同期する必要がある操作データの格納に使用。dSAOperation: トポロジ全体での同期を行わない、特定のディレクトリ・サーバー固有の操作データの格納に使用。

extensions

オプション。その属性タイプで使用できる拡張を指定します。Oracle Unified Directoryは次の拡張を備えています:

- X-ORIGIN: その属性タイプが定義されている場所に関する情報を提供します。この要素は非標準のツールであり、RFC番号(RFC4517)などのスキーマ要素を見つけるときに使用できます。

- X-SCHEMA-FILE: その属性タイプ定義を格納するスキーマ・ファイルを示します。内部目的でのみ使用され、クライアントには公開されません。この拡張を使用して、ディレクトリ・サーバーがカスタム・スキーマ定義をどこに格納するかを指定できます。

- X-APPROX: その属性タイプでどの近似一致ルールを使用するかを示します。指定する場合は、登録されている一致ルールのOIDの名前を値として指定します。

たとえば、新しい属性タイプblogURLの追加をLDIFファイルで指定し、このファイルをスキーマに追加できます。

$ cat blogURL.ldif
dn: cn=schema
changetype: modify
add: attributeTypes
attributeTypes: ( 1.3.6.1.4.1.32473.1.1.590
NAME ( 'blog' 'blogURL' )
DESC 'URL to a personal weblog'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
X-ORIGIN 'Oracle Unified Directory Server'
USAGE userApplications )

注意:

属性タイプの宣言では、スペースに特に注意してください。LDAPの仕様で、左カッコとOIDの間およびUSAGE要素値と右カッコの間にスペースが存在することが要件となっています。また、LDIFの仕様で、LDIFパーサーは各行の先頭で厳密にスペース1つのみを無視すると規定されています。そのため、要素キーワードで始まる行の先頭にスペースを2つ追加することをお薦めします。たとえば、前の例のNAME、DESC、SYNTAX、SINGLE-VALUE、X-ORIGINおよびUSAGEの前にスペースを2つ追加します。

この例で使用しているOIDは説明用であり、実際のディレクトリには実装しないでください。

27.4.1.1 属性タイプを表示するには

cn=schemaエントリは複数値属性attributeTypesを持ち、この属性にはディレクトリ・スキーマ内の各属性タイプの定義が含まれています。スキーマ定義を表示するには、ldapsearchコマンドを使用します。スキーマ要素はLDAPサブエントリとして表現されるため、cn=schemaでの検索にはLDAPサブエントリ検索制御を含める必要があります。

1. LDAPサブエントリ検索制御とともにldapsearchコマンドを使用する方法は次のとおりです:

$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
-b "cn=schema" -s base "(objectclass=*)" attributeTypes
dn: cn=schema
attributeTypes: ( 2.5.4.41 NAME 'name' EQUALITY caseIgnoreMatch SUBSTR
caseIgnoreeSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768}
X-ORIGIN 'RFC 4519' )
attributeTypes: ( 2.5.4.49 NAME 'distinguishedName' EQUALITY
distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN
'RFC 4519' )
attributeTypes: ( 2.5.4.0 NAME 'objectClass' EQUALITY objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 X-ORIGIN 'RFC 4512' )
...(more output)...

2. 特定の属性タイプを表示するには、--dontWrapオプションを使用し、その後grepコマンド(UNIXシステム上)を使用して必要な属性を検索します。
次の例では、telexNumberという文字列を含む属性タイプを検索します。

$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
-b cn=schema -s base --dontWrap "(objectclass=*)" \
attributeTypes | grep "telexNumber"
attributeTypes: ( 2.5.4.21 NAME 'telexNumber' SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 X-ORIGIN 'RFC 4519' )
attributeTypes: ( 2.5.4.21.1 NAME 'c-TelexNumber' SUP telexNumber COLLECTIVE X-ORIGIN 'RFC 3671' )

27.4.1.2 属性タイプを作成するには

cn=schemaエントリは複数値属性attributeTypesを持ち、この属性にはディレクトリ・スキーマ内の各属性タイプの定義が含まれています。カスタムのスキーマ定義を追加するには、ldapmodifyコマンドを使用します。次の例では、blogという名前の属性を追加します。

1. テキスト・エディタを使用して、スキーマ拡張を含むLDIFファイルを作成します。

dn: cn=schema
changetype: modify
add: attributeTypes
attributeTypes: ( 1.3.6.1.4.1.32473.1.1.590
NAME ( 'blog' 'blogURL' )
DESC 'URL to a personal weblog'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
X-ORIGIN 'Oracle Unified Directory Server'
USAGE userApplications )

2. ldapmodifyを使用してファイルを追加します。

$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
-a -f blogURL.ldif
Processing MODIFY request for cn=schema
MODIFY operation successful for DN cn=schema

3. ldapsearchを使用して追加内容を表示することによって、これを検証します。

$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
-b "cn=schema" -s base --dontWrap "(objectclass=*)" \
attributeTypes | grep 'blog'
attributeTypes: ( 1.3.6.1.4.1.32473.1.1.590 NAME ( 'blog' 'blogURL' )
DESC 'URL to a personal weblog' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE X-ORIGIN 'Oracle Unified Directory Server' USAGE userApplications )

注意:

新しい属性定義は、Oracle Unified Directoryによって、instance-dir/OUD/config/schema/99user.ldifファイルに自動的に追加されます。

27.4.1.3 属性タイプを削除するには

cn=schemaエントリは複数値属性attributeTypesを持ち、この属性にはディレクトリ・スキーマ内の各属性タイプの定義が含まれています。カスタムのスキーマ定義は、ldapmodifyコマンドを使用して削除できます。Oracle Unified Directoryでの標準のスキーマ定義の削除は行えません。

注意:

属性タイプを削除する際には注意してください。この削除によってディレクトリが損なわれることがあります。属性タイプの削除は、どうしても削除する必要がある場合以外は行わないでください。

1. LDIFファイルに削除リクエストを作成します。

dn: cn=schema
changetype: modify
delete: attributeTypes
attributeTypes: ( 1.3.6.1.4.1.32473.1.1.590
NAME ( 'blog' 'blogURL' )
DESC 'URL to a personal weblog'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
X-ORIGIN 'Oracle Unified Directory Server'
USAGE userApplications )

2. ldapmodifyコマンドを使用して、削除リクエストを処理します。

$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
--defaultAdd --fileName "remove_blogURL.ldif"
Processing MODIFY request for cn=schema
MODIFY operation successful for DN cn=schema

27.4.2 オブジェクト・クラスの管理

オブジェクト・クラスは、エントリに格納するデータ型を制御するために使用される属性定義の名前付きセットです。新しいオブジェクト・クラスをスキーマに追加するには、ldapmodifyコマンドを使用します。オブジェクト・クラスの構文では、新しい要素の定義時には、少なくとも有効なOIDを指定する必要があります。標準的なアプリケーションでは、オブジェクト・クラス・タイプに関する次のオプションの識別子も含めることができます。オブジェクト・クラス定義の詳細は、第27.1項「Oracle Unified Directoryスキーマの概要」を参照してください。

OID

必須。ディレクトリ・サーバー内でそのオブジェクト・クラスを一意に識別するOIDを指定します。LDAP v3仕様では、OIDにはUTF-8エンコードのドット区切り10進数を使用することが要件となっています。しかし、Oracle Unified Directoryでは、組織の内部で使用されるスキーマの識別を容易化するため、非数値OIDの使用をサポートしています。たとえば、objectClassName-oidのような書式になります(person-oidなど)。

NAME

オプション。そのオブジェクト・クラスについて言及するときに使用する、判読可能な名前セットを指定します。名前が1つのときは、一重引用符で囲みます(例: 'blogURL')。名前が複数あるときは、一重引用符で囲んだ各名前をスペースで区切り、名前セット全体をカッコで囲みます(例: ('blog' 'blogURL'))。左カッコと名前の間および右カッコの前に1つずつ、必ずスペースを挿入してください。

DESC

オプション。そのオブジェクト・クラスに関する判読可能な説明を指定します。指定する場合は、説明を一重引用符で囲みます。

SUP

オプション。そのオブジェクト・クラスに別のオブジェクト・クラスの要素を継承させる場合に、上位オブジェクト・クラスを指定します。ディレクトリ・サーバーで使用できる上位オブジェクト・クラスは1つのみです。ただし、LDAP v3の仕様では複数の上位オブジェクト・クラスが許容されています。

OBSOLETE

オプション。そのオブジェクト・クラスがアクティブかどうかを示します。OBSOLETEとしてマークされているオブジェクト・クラスは、ディレクトリ・サーバーで作成される新しい要素からは参照されません。

SUP oids

オプション。SUPキーワードに続けて上位クラスのOIDを指定します。

KIND

オプション。定義対象のオブジェクト・クラスのタイプを示します。使用可能な値はABSTRACT、AUXILIARYおよびSTRUCTURALです。

MUST oids

オプション。そのオブジェクト・クラスを含むエントリに存在する(つまり、1つ以上の値を持つ)必要がある属性タイプ・セットを指定します。必須属性が1つのみの場合は、MUSTキーワードに続けてその属性タイプの名前またはOIDを指定します。必須属性タイプが複数ある場合は、属性タイプ間をドル記号($)で区切り、属性タイプ・セット全体をカッコで囲みます。例: MUST (sn $cn)。

MAY oids

オプション。そのオブジェクト・クラスを含むエントリで使用可能な(必須ではない)属性タイプ・セットを指定します。指定する属性が1つのみの場合は、MAYキーワードに続けてその属性タイプの名前またはOIDを指定します。属性タイプを複数指定する場合は、各属性タイプ間をドル記号($)で区切り、属性タイプ・セット全体をカッコで囲みます。例: MAY (userPassword $telephoneNumber $seeAlso $description)。

extensions

オプション。そのオブジェクト・クラスで使用できる拡張を指定します。ディレクトリ・サーバーは次の拡張を備えています。X-ORIGIN: そのオブジェクト・クラスが定義されている場所に関する情報を提供します。この要素は、ユーザーがスキーマ要素を見つけやすいようにする非標準のツールです。X-SCHEMA-FILE: そのオブジェクト・クラス定義を格納するスキーマ・ファイルを示します。内部目的でのみ使用され、クライアントには公開されません。この拡張を使用して、ディレクトリ・サーバーがカスタム・スキーマ定義をどこに格納するかを指定できます。

たとえば、新しいオブジェクト・クラスbloggerの追加をLDIFファイルで指定し、このファイルをスキーマに追加できます。

$ cat blogger.ldif
dn: cn=schema
changetype: modify
add: objectClasses
objectClasses: ( 1.3.6.1.4.1.32473.1.1.10
NAME ( 'blogger' )
DESC 'Someone who has a blog'
SUP inetOrgPerson
STRUCTURAL
MAY blog
X-ORIGIN 'Oracle Unified Directory Server' )

オブジェクト・クラスの宣言では、スペースに特に注意してください。LDAPの仕様で、左カッコとOIDの間およびX-ORIGIN要素値と右カッコの間にスペースが存在することが要件となっています。また、LDIFの仕様で、LDIFパーサーは各行の先頭で厳密にスペース1つのみを無視すると規定されています。そのため、前の例のNAME、DESC、SUP、STRUCTURAL、MAY、X-ORIGINなどの要素キーワードで始まる行の前にスペースを2つ追加することをお薦めします。

この例で使用しているOIDは説明用であり、実際のディレクトリには実装しないでください。

27.4.2.1 オブジェクト・クラスを表示するには

cn=schemaエントリは複数値属性objectClassesを持ち、この属性にはディレクトリ・スキーマ内の各オブジェクト・クラスの定義が含まれています。スキーマ定義を表示するには、ldapsearchコマンドを使用します。

1. オブジェクト・クラス定義を表示するには、ldapsearchコマンドを使用します。

$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
-b cn=schema -s base "(objectclass=*)" objectClasses
dn: cn=schema
objectClasses: ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass X-ORIGIN
'RFC 4512' )
objectClasses: ( 2.5.6.1 NAME 'alias' SUP top STRUCTURAL MUST aliasedObjectName
X-ORIGIN 'RFC 4512' )
objectClasses: ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c MAY
( searchGuide $ description ) X-ORIGIN 'RFC 4519' )
objectClasses: ( 2.5.6.3 NAME 'locality' SUP top STRUCTURAL MAY ( street $
seeAlso $ searchGuide $ st $ l $ description ) X-ORIGIN 'RFC 4519' )
objectClasses: ( 2.5.6.4 NAME 'organization' SUP top STRUCTURAL MUST o MAY
( userPassword $ searchGuide $ seeAlso $ businessCategory $ x121Address $
registered Address $ destinationIndicator $ preferredDeliveryMethod $
telexNumber $ teletexTerminalIdentifier $ telephoneNumber $
internationaliSDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $
postalCode $ postalAddress $ physicalDeliveryOfficeName $ st $ l $ description
) X-ORIGIN 'RFC 4519' )
...(more output)...

2. 特定のオブジェクト・クラスを検索する場合は、--dontWrapオプションとgrepコマンドを使用します。

$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
-b cn=schema -s base --dontWrap "(objectclass=*)" \
objectClasses | grep "inetOrgPerson"
objectClasses: ( 2.16.840.1.113730.3.2.2 NAME 'inetOrgPerson' SUP organizationalPerson
STRUCTURAL MAY ( audio $ businessCategory $ carLicense $ departmentNumber $ displayName
$ employeeNumber $ employeeType $ givenName $ homePhone $ homePostalAddress $ initials
$ jpegPhoto $ labeledURI $ mail $ manager $ mobile $ o $ pager $ photo $ roomNumber
$ secretary $ uid $ userCertificate $ x500UniqueIdentifier $ preferredLanguage
$ userSMIMECertificate $ userPKCS12 ) X-ORIGIN 'RFC 2798' )

27.4.2.2 オブジェクト・クラスを作成するには

cn=schemaエントリは複数値属性objectClassesを持ち、この属性にはディレクトリ・スキーマ内の各オブジェクト・クラスの定義が含まれています。カスタム・スキーマを追加するには、ldapmodifyコマンドを使用します。次の例では、前の例で作成した属性タイプに基づいて、オブジェクト・クラスbloggerを追加します。

1. テキスト・エディタを使用して、スキーマ拡張を含むLDIFファイルを作成します。

dn: cn=schema
changetype: modify
add: objectClasses
objectClasses: ( 1.3.6.1.4.1.32473.1.1.10
NAME ( 'blogger' )
DESC 'Someone who has a blog'
SUP inetOrgPerson
STRUCTURAL
MAY blog
X-ORIGIN 'Oracle Unified Directory Server' )

2. ldapmodifyコマンドを使用してファイルを追加します。

$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
-a -f blogger.ldif
Processing MODIFY request for cn=schema
MODIFY operation successful for DN cn=schema

3. ldapsearchを使用して追加内容を表示することによって、これを検証します。

$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
-b cn=schema -s base --dontWrap "(objectclass=*)" \
objectClasses | grep 'blogger'

注意:

新しいオブジェクト・クラス定義は、Oracle Unified Directoryによって、instance-dir/OUD/config/schema/99user.ldifファイルに自動的に追加されます。

27.4.2.3 オブジェクト・クラスを削除するには

cn=schemaエントリは複数値属性objectClassesを持ち、この属性にはディレクトリ・スキーマ内の各オブジェクト・クラスの定義が含まれています。カスタムのオブジェクト・クラス定義を削除するには、ldapmodifyコマンドを使用します。

注意:

オブジェクト・クラスを削除する際には注意してください。この削除によってディレクトリが損なわれることがあります。オブジェクト・クラスの削除は、どうしても削除する必要がある場合以外は行わないでください。

1. LDIF形式の削除リクエストを作成します。

dn: cn=schema
changetype: modify
delete: objectClasses
objectClasses: ( 1.3.6.1.4.1.32473.1.1.10
NAME ( 'blogger' )
DESC 'Someone who has a blog'
SUP inetOrgPerson
STRUCTURAL
MAY blog
X-ORIGIN 'Oracle Unified Directory Server' )

2. ldapmodifyを使用してLDIFファイルを適用することによって、オブジェクト・クラスを削除します。

$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
--fileName "remove_objectclass_schema.ldif"

27.5 スキーマのレプリケート

レプリケート・トポロジでは、スキーマ定義が自動的にレプリケートされ、1つのスキーマがすべてのサーバーで確実に使用されます。どのサーバーで行われたスキーマの変更も、トポロジ内の他のすべてのサーバーにレプリケートされます。

レプリケーションを構成すると、デフォルトで、最初のサーバーのスキーマを使用して2番目のサーバーのスキーマが初期化されます。しかし、2番目のサーバーのスキーマを使用して最初のサーバーのスキーマを初期化するように指定できます。また、そのスキーマ・レプリケーションを完全に無効化するように指定することも可能です。詳細は、第26.6項「スキーマ・レプリケーションの構成」を参照してください。

27.6 Oracle Directory Services Managerを使用したスキーマの管理

ディレクトリ・スキーマのほとんどの要素は、ODSMを使用して管理できます。次の各項では、スキーマの表示および拡張の一般的な面を管理する手順を示します。

27.6.1 新規属性タイプの追加

ODSMを使用して新しい属性タイプをスキーマに追加する手順は次のとおりです:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「スキーマ」タブを選択します。

3. デフォルトで、「属性」パネルが開かれます。開かれない場合は、矢印をクリックして開きます。

4. 「追加」アイコンをクリックします。

5. 「新規属性の作成」ウィンドウで次の情報を設定します:

- 名前: 新しい属性タイプの一意の名前を入力します。

- オブジェクトID: ディレクトリ・サーバー内でその属性タイプを一意に識別するOIDを指定します。Oracle Unified Directoryでは、識別を容易化するため、スキーマが組織の内部で使用される場合にかぎり、非数値OIDの使用をサポートしています。ただし、このリリースでODSMがサポートしているOIDは数値OIDのみです。

- 説明: その属性タイプに関する判読可能な説明を入力します。

- 構文: その属性タイプで使用する属性構文を入力します。構文を指定する場合は、数値OIDとして指定します。RFC 4517の第3.3項および同じドキュメントの付録Aで、コア構文が定義されています。

- サイズ: その属性の値の最大サイズをバイト単位で入力します。複数値属性の場合は、これは各値の結合ではなく、単一値の最大サイズのことです。

- 使用方法: その属性の用途を指定します。次の値があります:

- userApplications: その属性を、ユーザー・データの格納に使用します。

- directoryOperation: その属性を、ディレクトリ・サーバー内部の処理に必要なデータの格納に使用します。

- distributedOperation: その属性を、トポロジ内のディレクトリ・サーバー間で同期する必要がある操作データの格納に使用します。

- dSAOperation: その属性を、トポロジ全体での同期を行わない、特定のディレクトリ・サーバー固有の操作データの格納に使用します。

- 順序付け: この属性タイプの順序付け索引の詳細を選択します。詳細は、第17.7項「ディレクトリ・データへの索引付け」を参照してください。

- 等価: この属性タイプの等価索引の詳細を選択します。詳細は、第17.7項「ディレクトリ・データへの索引付け」を参照してください。

- 部分文字列: この属性タイプの部分文字列索引の詳細を選択します。詳細は、第17.7項「ディレクトリ・データへの索引付け」を参照してください。

- 廃止: この属性タイプは使用廃止となっているが、互換性用に維持する場合は、このボックスを選択します。

- 単一値: このタイプの属性を含むエントリでそのタイプの属性に対して単一値のみを指定可能とするどうかを示します。このチェック・ボックスの選択を解除すると、同じエントリ内で複数の固有の値を属性に対して指定できるようになります。

- 集合: この属性が集合属性かどうかを示します。詳細は、第17.12項「集合属性の使用方法」を参照してください。

- スーパー: この新しい属性が既存の属性の拡張である場合は、既存のスーパー・タイプの名前を入力または選択します。

- オリジン: この新しい属性タイプのソース(RFC 4512など)を入力します。
ディレクトリ内のすべてのスキーマ要素のソースを表示するには、「表示」メニューから「すべて表示」を選択します。

- スキーマ・ファイル拡張: この属性タイプの定義がファイルに格納されている場合は、そのファイルのパスを入力します。

6. 「作成」をクリックすると、新しい属性が作成されます。

27.6.2 既存の属性に基づく属性の追加

ODSMを使用して既存の属性タイプに基づく属性タイプを追加する手順は次のとおりです:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「スキーマ」タブを選択します。

3. デフォルトで、「属性」パネルが開かれます。開かれない場合は、矢印をクリックして開きます。

4. 新しい属性タイプのベースとする属性を選択します。

5. 「類似作成」アイコンをクリックします。

6. 一部のフィールドは、選択した属性に基づいてデフォルトで設定されます。
新しい属性タイプの残りのフィールドを設定します。

各フィールドとその値の詳細は、第27.6.1項「新規属性タイプの追加」を参照してください。

7. 「作成」をクリックすると、新しい属性が作成されます。

27.6.3 属性の変更

ODSMを使用して既存の属性タイプを変更する手順は次のとおりです:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「スキーマ」タブを選択します。

3. デフォルトで、「属性」パネルが開かれます。開かれない場合は、矢印をクリックして開きます。

4. 変更する属性タイプを選択します。

5. 右側のペインで、必要なフィールドを変更します。
各フィールドの詳細は、第27.6.1項「新規属性タイプの追加」を参照してください。

6. 「適用」をクリックして、変更を保存します。

27.6.4 属性の削除

ODSMを使用して既存の属性タイプを削除する手順は次のとおりです:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「スキーマ」タブを選択します。

3. デフォルトで、「属性」パネルが開かれます。開かれない場合は、矢印をクリックして開きます。

4. 削除する属性タイプを選択します。

5. 「削除」アイコンをクリックし、「OK」をクリックして削除を確認します。

6. 「適用」をクリックして、変更を保存します。

7. 「リフレッシュ」アイコンをクリックして左側のペインの属性リストをリフレッシュし、その属性がスキーマから削除されたことを確認します。

注意:

サーバー内の1つ以上のエントリによってすでに参照されている属性タイプを削除しようとすると、サーバーからエラーが返されます。

27.6.5 すべてのディレクトリ属性の表示

ODSMを使用して既存のすべての属性タイプを表示する手順は次のとおりです:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「スキーマ」タブを選択します。

3. デフォルトで、「属性」パネルが開かれます。開かれない場合は、矢印をクリックして開きます。

4. スキーマで定義されているすべての属性が左側のペインにリストされます。

5. 属性を選択すると、右側のペインにそのプロパティが表示されます。

27.6.6 属性の検索

ODSMを使用して特定の属性タイプを検索する手順は次のとおりです:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「スキーマ」タブを選択します。

3. デフォルトで、「属性」パネルが開かれます。開かれない場合は、矢印をクリックして開きます。

4. スキーマで定義されているすべての属性が左側のペインにリストされます。

5. 属性名全体またはその一部を「検索」フィールドに入力して、「実行」アイコンをクリックします。
検索フィールドでは、パターン一致をサポートしています。たとえば、uidという文字列で終わるすべての属性を検索するには、*uidと入力します。

6. 属性を選択すると、右側のペインにそのプロパティが表示されます。

27.6.7 属性の索引付け詳細の表示

索引は、サーバーごとに構成され、索引構成はレプリケートされません。ローカル・データベース索引は、検索基準に一致するエントリを見つけるために使用されます。VLV索引は、VLV制御で効率的に検索を処理するために使用されます。索引なし検索は、ユーザーが索引なし検索特権を持っていない場合はデフォルトで拒否されます。

ローカル・データベース索引は次のいずれかのタイプです:

- 近似: 近似検索フィルタを使用して検索の効率を高めます。

- 等価: 等価検索フィルタを使用して検索の効率を高めます。

- 順序付け: 以上または以下検索フィルタを使用して検索の効率を高めます。

- プレゼンス: プレゼンス検索フィルタを使用して検索の効率を高めます。

- 部分文字列: 部分文字列検索フィルタを使用して検索の効率を高めます。

ODSMを使用して、属性に対して定義されている索引を表示する手順は次のとおりです:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「スキーマ」タブを選択します。

3. デフォルトで、「属性」パネルが開かれます。開かれない場合は、矢印をクリックして開きます。

4. 属性を選択すると、右側のペインにそのプロパティが表示されます。

5. 「索引付き」プロパティまで下にスクロールして、その属性の索引付け詳細を表示します。

27.6.8 新規オブジェクト・クラスの追加

ODSMを使用して新しい属性タイプをスキーマに追加する手順は次のとおりです:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「スキーマ」タブを選択します。

3. 「オブジェクト・クラス」パネルをクリックして開きます。
既存のすべてのオブジェクト・クラスが左側のペインに表示されます。

4. 「追加」アイコンをクリックします。

5. 「新規オブジェクト・クラスの作成」ウィンドウで次の情報を設定します:

- 名前: 新しいオブジェクト・クラスの一意の名前を入力します。

- オブジェクトID: ディレクトリ・サーバー内でそのオブジェクト・クラスを一意に識別するOIDを指定します。Oracle Unified Directoryでは、識別を容易化するため、スキーマが組織の内部で使用される場合にかぎり、非数値OIDの使用をサポートしています。ただし、このリリースでODSMがサポートしているOIDは数値OIDのみです。

- 説明: そのオブジェクト・クラスに関する判読可能な説明を入力します。

- タイプ: そのオブジェクト・クラスのタイプを指定します。次の値があります:

- 構造型: 構造化オブジェクト・クラスでは、そのオブジェクト・クラスを含むあらゆるエントリのコア・タイプが定義されます。個々のエントリは厳密に1つの構造化クラスを持っている必要があります(ただし、構造化クラスは他の構造化クラスまたは抽象クラスから継承可能です)。

- 補助型: 補助オブジェクト・クラスでは、エントリのコア・タイプは定義されず、そのエントリの追加属性が定義されます。個々のエントリは1つ以上の補助オブジェクト・クラスを含むことができます。個々のエントリで使用可能な補助オブジェクト・クラス・セットは、そのエントリの構造化オブジェクト・クラスに関連付けられたDITコンテンツ・ルールによって制御できます。

- 抽象型: 抽象オブジェクト・クラスは、エントリで直接使用できず、構造化オブジェクト・クラスまたは補助オブジェクト・クラスのどちらかでサブクラス化する必要があります。サブクラスは、抽象クラスで定義されている必須、オプションまたはこの両方の属性タイプを継承します。

- スーパークラス: 「追加」アイコンをクリックして、1つ以上の上位オブジェクト・クラスを指定します。新しいオブジェクト・クラスはその上位オブジェクト・クラスから要素を継承します。

- 必須属性: 「追加」アイコンをクリックして、そのオブジェクト・クラスを含むエントリに存在する(つまり、1つ以上の値を持つ)必要がある属性タイプ・セットを指定します。

- オプション属性: 「追加」アイコンをクリックして、そのオブジェクト・クラスを含むエントリで使用可能な(必須ではない)属性タイプ・セットを指定します。

- 継承属性: オブジェクト・クラスの作成後、このオブジェクト・クラスの上位オブジェクト・クラスから継承された属性がこのフィールドに表示されます。

- オリジン: この新しいオブジェクト・クラスのソース(RFC 4512など)を入力します。
ディレクトリ内のすべてのスキーマ要素のソースを表示するには、「表示」メニューから「すべて表示」を選択します。

- スキーマ・ファイル拡張: この新しいオブジェクト・クラスの定義がファイルに格納されている場合は、そのファイルのパスを入力します。

6. 「作成」をクリックすると、新しいオブジェクト・クラスが作成されます。

27.6.9 既存のオブジェクト・クラスに基づくオブジェクト・クラスの追加

ODSMを使用して既存のオブジェクト・クラスに基づくオブジェクト・クラスを追加する手順は次のとおりです:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「スキーマ」タブを選択します。

3. 「オブジェクト・クラス」パネルを開きます。

4. 新しいオブジェクト・クラスのベースとするオブジェクト・クラスを選択します。

5. 「類似作成」アイコンをクリックします。

6. 一部のフィールドは、選択したオブジェクト・クラスに基づいてデフォルトで設定されます。既存のオブジェクト・クラスが、この新しいオブジェクト・クラスの上位オブジェクト・クラスとして使用されます。
新しいオブジェクト・クラスの残りのフィールドを設定します。

各フィールドとその値の詳細は、第27.6.8項「新規オブジェクト・クラスの追加」を参照してください。

7. 「作成」をクリックすると、新しいオブジェクト・クラスが作成されます。

27.6.10 オブジェクト・クラスのプロパティの表示

ODSMを使用して既存のオブジェクト・クラスのプロパティを表示する手順は次のとおりです:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「スキーマ」タブを選択します。

3. 「オブジェクト・クラス」パネルを開きます。

4. スキーマで定義されているすべてのオブジェクト・クラスが左側のペインにリストされます。

5. オブジェクト・クラスを選択すると、右側のペインにそのプロパティが表示されます。

27.6.11 オブジェクト・クラスの変更

ODSMを使用して既存のオブジェクト・クラスを変更する手順は次のとおりです:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「スキーマ」タブを選択します。

3. 「オブジェクト・クラス」パネルを開きます。

4. 変更するオブジェクト・クラスを選択します。

5. 右側のペインで、必要なフィールドを変更します。
各フィールドの詳細は、第27.6.8項「新規オブジェクト・クラスの追加」を参照してください。

6. 「適用」をクリックして、変更を保存します。

27.6.12 オブジェクト・クラスの削除

ODSMを使用して既存のオブジェクト・クラスを削除する手順は次のとおりです:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「スキーマ」タブを選択します。

3. 「オブジェクト・クラス」パネルを開きます。

4. 削除するオブジェクト・クラスを選択します。

5. 「削除」アイコンをクリックし、「OK」をクリックして削除を確認します。

6. 「適用」をクリックして、変更を保存します。

7. 「リフレッシュ」アイコンをクリックして左側のペインの属性リストをリフレッシュし、そのオブジェクト・クラスがスキーマから削除されたことを確認します。

注意:

サーバー内の1つ以上のエントリによってすでに参照されているオブジェクト・クラスを削除しようとすると、サーバーからエラーが返されます。

27.6.13 オブジェクト・クラスの検索

ODSMを使用して特定のオブジェクト・クラスを検索する手順は次のとおりです:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「スキーマ」タブを選択します。

3. 「オブジェクト・クラス」パネルを開きます。

4. スキーマで定義されているすべてのオブジェクト・クラスが左側のペインにリストされます。

5. オブジェクト・クラス名全体またはその一部を「検索」フィールドに入力して、「実行」アイコンをクリックします。
検索フィールドでは、パターン一致をサポートしています。たとえば、personという文字列で終わるすべてのオブジェクト・クラスを検索するには、*personと入力します。

6. オブジェクト・クラスを選択すると、右側のペインにそのプロパティが表示されます。

27.6.14 LDAP構文のリストの表示

LDAP構文は基本的にデータ型の定義です。属性タイプの構文は、対応する値が保持するデータ型を示します。構文の使用により、所定の属性に対して特定の値が許容されるかどうかと、ディレクトリ・サーバーが既存の値に対してどのように相互作用するかを決定できます。

Oracle Unified Directoryでは、関連付けられた属性構文に違反する値を拒否する機能をサポートしています。これは標準への準拠を目的とするデフォルトの動作です。必要に応じて、構文チェックを完全に無効化できます。また、関連付けられた構文に違反する値が検出されたときに、その値を受け入れる一方、ディレクトリ・サーバーのエラー・ログに警告メッセージを記録することも可能です。スキーマ・チェックの無効化の詳細は、第27.2項「スキーマ・チェックの構成」を参照してください。

LDAP構文は変更できませんが、ODSMを使用して既存のすべてのLDAP構文を表示できます。この手順は次のとおりです:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「スキーマ」タブを選択します。

3. 「構文」パネルを開きます。

4. サポートされているすべてのLDAP構文が左側のペインにリストされます。

5. 構文を選択すると、そのプロパティが右側のペインに表示されます。
すべての属性や、その構文を現在参照している一致ルールなどの情報が表示されます。

27.6.15 構文の検索

ODSMを使用して特定のLDAP構文を検索する手順は次のとおりです:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「スキーマ」タブを選択します。

3. 「構文」パネルを開きます。

4. サポートされているすべてのLDAP構文が左側のペインにリストされます。

5. 構文名全体またはその一部を「検索」フィールドに入力して、「実行」アイコンをクリックします。
検索フィールドでは、パターン一致をサポートしています。たとえば、timeという文字列で終わるすべての構文を検索するには、*timeと入力します。

6. 構文を選択すると、そのプロパティが右側のペインに表示されます。

27.6.16 LDAP一致ルールのリストの表示

一致ルールは、同じ属性の2つの値を比較する、つまりそれらの値に対して一致操作を実行するために、ディレクトリ・サーバーで使用されます。次のような様々なタイプの一致ルールをサポートしています:

- 等価一致ルール: この種の一致ルールは、2つの値が論理的に等価かどうかを決定するために使用されます。等価一致ルールの実装ごとに、この決定に使用される基準は異なることがあります(たとえば、大文字/小文字の相違を無視するかどうか、どのスペースが重要かの決定など)。

- 順序付け一致ルール: この種の一致ルールは、2つの値の相対順序を決定するために(たとえば、次以上または次以下の検索の評価時や、結果をソートする必要があるときなど)使用されます。

- 部分文字列一致ルール: この種の一致ルールは、所定の部分文字列アサーションが特定の値に一致するかどうかを決定するために使用されます。

- 近似一致ルール: この種の一致ルールは、2つの値がおおよそ等価かどうかを決定するために使用されます。これは、多くの場合、「類似しているものを検索する」などの種類のファジー・アルゴリズムに基づきます。近似一致ルールは正式なLDAP仕様の一部とはなっていませんが、Oracle Unified Directoryでは柔軟性を高めるために採用しています。

一致ルールは変更できませんが、ODSMを使用して既存のすべての一致ルールを表示できます。この手順は次のとおりです:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「スキーマ」タブを選択します。

3. 「一致ルール」パネルを開きます。

4. 構成済のすべての一致ルールが左側のペインにリストされます。

5. 一致ルールを選択すると、そのプロパティが右側のペインに表示されます。
すべての属性や、その一致ルールを現在参照している一致ルールなどの情報が表示されます。

27.6.17 一致ルールの検索

ODSMを使用して特定の一致ルールを検索する手順は次のとおりです:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「スキーマ」タブを選択します。

3. 「一致ルール」パネルを開きます。

4. 構成済のすべての一致ルールが左側のペインにリストされます。

5. 一致ルール名全体またはその一部を「検索」フィールドに入力して、「実行」アイコンをクリックします。
検索フィールドでは、パターン一致をサポートしています。たとえば、matchという文字列で終わるすべての一致ルールを検索するには、*matchと入力します。

6. 一致ルールを選択すると、そのプロパティが右側のペインに表示されます。

27.6.18 コンテンツ・ルールのリストの表示

コンテンツ・ルールは、エントリが含むことができるコンテンツを定義するメカニズムを提供します。個々のエントリには、最大1つのコンテンツ・ルールをその構造化オブジェクト・クラスに基づいて関連付けることができます。エントリにそのようなルールが存在する場合、エントリに存在する必要がある(存在する可能性がある、または存在していはいけない)属性タイプと同様に、含む可能性のある補助クラスを定義するために、そのエントリに含まれるオブジェクト・クラスとともに動作します。

ODSMを使用して、サーバーに構成されているすべてのコンテンツ・ルールを表示する手順は次のとおりです:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「スキーマ」タブを選択します。

3. 「コンテンツ・ルール」パネルを開きます。

4. 構成済のすべてのコンテンツ・ルールが左側のペインにリストされます。

5. コンテンツ・ルールを選択すると、そのプロパティが右側のペインに表示されます。

27.6.19 コンテンツ・ルールの検索

ODSMを使用して特定のコンテンツ・ルールを検索する手順は次のとおりです:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「スキーマ」タブを選択します。

3. 「コンテンツ・ルール」パネルを開きます。

4. 構成済のすべてのコンテンツ・ルールが左側のペインにリストされます。

5. コンテンツ・ルール名全体またはその一部を「検索」フィールドに入力して、「実行」アイコンをクリックします。

6. コンテンツ・ルールを選択すると、そのプロパティが右側のペインに表示されます。

27.6.20 新規コンテンツ・ルールの作成

ODSMを使用して新しいコンテンツ・ルールをスキーマに追加する手順は次のとおりです:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「スキーマ」タブを選択します。

3. 「コンテンツ・ルール」パネルを開きます。

4. 「追加」アイコンをクリックします。

5. 「新規コンテンツ・ルールの作成」ウィンドウで次の情報を設定します:

- 名前: 新しいコンテンツ・ルールの一意の名前を入力します。

- 構造化オブジェクト・クラス: このコンテンツ・ルールに関連付ける構造化オブジェクト・クラスの名前を指定します。

- 説明: そのコンテンツ・ルールに関する判読可能な説明を入力します。

- 補助オブジェクト・クラス: 「追加」アイコンをクリックして、関連付けられた構造化クラスを含むエントリに存在することが可能な補助オブジェクト・クラスのリストを指定します。値を何も指定しない場合、このようなエントリは補助オブジェクト・クラスを持つことができません。使用可能な補助オブジェクト・クラスは、その名前またはOIDによって指定できます。

- 必須属性: 「追加」アイコンをクリックして、関連付けられた構造化クラスを含むエントリに存在する必要がある属性タイプのリストを指定します。このリストは、エントリに含まれるオブジェクト・クラスで必要とされる属性タイプ以外のものです。これらの追加属性タイプは、このようなオブジェクト・クラスのいずれでも使用可能とされていないものでもかまいません。必須属性は、その名前またはOIDによって指定できます。

- オプション属性: 「追加」アイコンをクリックして、関連付けられたオブジェクト・クラスを含むエントリで使用可能な(必須ではない)属性タイプのリストを指定します。このリストは、エントリに含まれるオブジェクト・クラスで使用可能な属性タイプ以外のものです。オプション属性は、その名前またはOIDによって指定できます。

- 拒否属性: 「追加」アイコンをクリックして、関連付けられた構造化クラスを含むエントリに存在することを禁止する属性タイプのリストを指定します。構造化クラスまたは使用可能な補助クラスのいずれかで必要とされる属性タイプは、このリストに含めることはできません。このリストを使用することで、それらのオブジェクト・クラスのいずれかで使用可能となっている属性タイプの含有を防止できます。拒否属性は、その名前またはOIDによって指定できます。

- オリジン: この新しいコンテンツ・ルールのソース(RFC 4517など)を入力します。
ディレクトリ内のすべてのスキーマ要素のソースを表示するには、「表示」メニューから「すべて表示」を選択します。

- スキーマ・ファイル拡張: このコンテンツ・ルールの定義がファイルに格納されている場合は、そのファイルのパスを入力します。

6. 「作成」をクリックすると、新しいコンテンツ・ルールが作成されます。

27.6.21 既存のコンテンツ・ルールに基づくコンテンツ・ルールの作成

ODSMを使用して既存のコンテンツ・ルールに基づくコンテンツ・ルールを追加する手順は次のとおりです:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「スキーマ」タブを選択します。

3. 「コンテンツ・ルール」パネルを開きます。

4. 新しいコンテンツ・ルールのベースとするコンテンツ・ルールを選択します。

5. 「類似作成」アイコンをクリックします。

6. 一部のフィールドは、選択したコンテンツ・ルールに基づいてデフォルトで設定されます。
新しいコンテンツ・ルールの残りのフィールドを設定します。

各フィールドとその値の詳細は、第27.6.20項「新規コンテンツ・ルールの作成」を参照してください。

7. 「作成」をクリックすると、新しいコンテンツ・ルールが作成されます。

27.6.22 コンテンツ・ルールの変更

ODSMを使用して既存のコンテンツ・ルールを変更する手順は次のとおりです:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「スキーマ」タブを選択します。

3. 「コンテンツ・ルール」パネルを開きます。

4. 変更するコンテンツ・ルールを選択します。

5. 右側のペインで、必要なフィールドを変更します。
各フィールドの詳細は、第27.6.20項「新規コンテンツ・ルールの作成」を参照してください。

6. 「適用」をクリックして、変更を保存します。

27.6.23 コンテンツ・ルールの削除

ODSMを使用して既存のコンテンツ・ルールを削除する手順は次のとおりです:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「スキーマ」タブを選択します。

3. 「コンテンツ・ルール」パネルを開きます。

4. 削除するコンテンツ・ルールを選択します。

5. 「削除」アイコンをクリックし、「OK」をクリックして削除を確認します。

6. 「適用」をクリックして、変更を保存します。

7. 「リフレッシュ」アイコンをクリックして左側のペインのコンテンツ・ルール・リストをリフレッシュし、そのコンテンツ・ルールがスキーマから削除されたことを確認します。

28 テスト環境から本番環境への移行

この章では、環境間、特にテスト環境と本番環境間でOracle Unified Directoryインストールを移動またはクローニングする方法について説明します。環境間での移動により、テスト環境で開発とテストを行い、その後テスト・アプリケーションと、必要に応じてテスト・データを本番環境にロール・アウトできます。この章の残りの部分では、テスト環境をソース環境と呼び、本番環境をターゲット環境と呼びます。

この章には次のトピックが含まれます:

- 第28.1項「環境間の移動の概要」

- 28.2項「テストから本番への移行における制限」

- 第28.3項「テストから本番へのプロセスの概要」

Oracle Unified Directoryの「テストから本番へ」プラグインは、Oracle Fusion Middlewareの「テストから本番へ」フレームワークが提供する機能のサブセットを提供します。この章のドキュメントはOracle Unified Directory固有のものです。環境間での他のFusion Middlewareコンポーネントの移動の包括的な説明は、『Oracle Fusion Middleware管理者ガイド』のテスト環境から本番環境への移行に関する項を参照してください。

28.1 環境間の移動の概要

Oracle Unified Directoryインストールを移動することによって、元の環境で行ったすべてのカスタマイズおよび構成変更を別の環境に再適用するために必要な作業量が最小化されます。テスト環境で、Oracle Unified Directoryのインストール、構成、カスタマイズおよび検証を実行できます。システムが安定し、必要なパフォーマンスを達成できるようになったら、本番環境を作成しますが、この場合、テスト環境に組み込んだすべての変更を再適用しなくても、サーバーとその構成のコピーをテスト環境から移動することによって本番環境を作成できます。既存の本番環境が存在する場合は、テスト環境で行ったカスタマイズなどのあらゆる変更を本番環境に移動できます。

テスト環境から本番環境へのOracle Unified Directoryインストールの移動では、本番環境がテスト環境と同じオペレーティング・システム上で動作することを前提としています。また、オペレーティング・システムのアーキテクチャが両方の環境で同じである必要があります。たとえば、両方の環境で32ビットのオペレーティング・システムまたは64ビットのオペレーティング・システムを実行している必要があります。

28.2 テストから本番への移行における制限

環境間でのOracle Unified Directoryインストールの移動のサポートには次の制限があります:

- テスト環境から本番環境への移動のサポートは、ディレクトリ・サーバー・インスタンスのみを対象としています。環境間でのプロキシ・サーバー・インスタンスまたはレプリケーション・ゲートウェイ・サーバー・インスタンスの移動は行えません。

- レプリケート・トポロジは移動できません。レプリケート・トポロジ全体を移動するには、まずトポロジ内の各サーバー・インスタンスを移動した後に、サーバー・インスタンス間のレプリケーションを手動で構成する必要があります。レプリケート・トポロジの一部であるサーバーを移動すると、移動先環境内の構成からレプリケーション構成が削除されます。

- セキュリティ・データはテストから本番へのプロセスでは移動されません。これには次の要素が含まれます:

- SSL構成(デフォルトでconfigディレクトリに配置されるキーストア、トラストストアおよびその他のセキュリティ構成)

- SNMP V3セキュリティ・ファイル(デフォルトでconfig/snmpディレクトリに配置)

28.3 テストから本番へのプロセスの概要

テスト環境から本番環境への移動は、大きく分けて次の3つの手順で構成されます:

1. 本番システムへのOracle Unified Directoryバイナリの移動

2. 本番システムへのOracle Unified Directory構成の移動

3. 本番システムへのデータの移動

これらの手順では、Oracle Unified Directoryテスト・システムを新しい本番デプロイメントに移動する(既存の本番システムは存在しない)ことを前提としています。

28.3.1 バイナリの移動

新しい本番システム上にOracle Unified Directoryバイナリのコピーを取得するには、Oracle Unified Directoryインストレーション・ガイドのOracle Unified Directoryのインストールに関する項の説明に従ってバイナリをインストールします。

28.3.2 構成の移動

環境間での構成の移動は、次の3つの手順で構成されます:

1. ソース環境からの構成のコピー

2. 構成の編集(必要に応じて)

3. ターゲット環境への構成の貼付け

28.3.2.1 構成のコピー

既存の構成のコピーを取得するには、ソース環境でoudCopyConfigコマンドを実行します。

UNIXシステムでは、次のようにコマンドを実行します:

$ OUD_ORACLE_HOME/bin/oudCopyConfig -javaHome java_home \
-sourceInstanceHomeLoc instance_dir -archiveLoc archive_location \
-logDirLoc log_directory

例:

$ OUD_ORACLE_HOME/bin/oudCopyConfig -javaHome /usr/jdk \
-sourceInstanceHomeLoc /local/asinst_1 -archiveLoc /tmp/oud.jar \
-logDirLoc /tmp/logs

Windowsシステムでは、次のようにコマンドを実行します:

$ OUD_ORACLE_HOME\bat\oudCopyConfig.bat -javaHome java_home \
-sourceInstanceHomeLoc instance_dir -archiveLoc archive_location \
-logDirLoc log_directory

oudCopyConfigコマンドの完全なシノプシスは、A.2.9項「oudCopyConfig」を参照してください。

oudCopyConfigコマンドは、次のアクションを実行します:

- テスト・インスタンス(instance_dir)を本番環境に移動するために必要な構成データを格納するアーカイブ(archive_location)を作成します。この場合、-archiveLocにアーカイブのフルパスを指定します。

- アーカイブで移動計画を作成します。

- メッセージをlog_directoryに記録します。指定されない場合、記録されたメッセージのデフォルト場所はシステムの一時ディレクトリになります。

28.3.2.2 構成の編集

移動計画を編集することによって、特定の構成パラメータを変更できます。移動計画とは、環境にまたがっての移動中にカスタマイズ可能なパラメータを公開するXMLファイルです。

移動計画は、oudCopyConfigコマンドを実行するときに生成され、構成を複製するためにoudPasteConfigコマンドによって使用されます。

構成のコピー後、次の手順でその構成を編集します:

1. oudExtractMovePlanコマンドを実行して、構成のコピーを取得します。UNIXシステムでは、次のようにコマンドを実行します:

$ OUD_ORACLE_HOME/bin/oudExtractMovePlan -javaHome java_home \
-archiveLoc archive_location -planDirLoc moveplan_dir \
-logDirLoc log_directory

例:

$ OUD_ORACLE_HOME/bin/ExtractMovePlan -javaHome /usr/jdk \
-archiveLoc /tmp/oud.jar -planDirLoc /tmp \
-logDirLoc /tmp/logs

Windowsシステムでは、次のようにコマンドを実行します:

$ OUD_ORACLE_HOME\bat\oudExtractMovePlan.bat -javaHome java_home \
-archiveLoc archive_location -planDirLoc moveplan_dir \
-logDirLoc log_directory

oudextractMovePlanコマンドの完全なシノプシスは、A.2.10項「oudExtractMovePlan」を参照してください。

oudExtractMovePlanコマンドは、-planDirLoc引数で指定された場所のmoveplan.xmlという名前のファイルに、編集可能な構成バージョンを作成します。このディレクトリが存在していて、書込み可能である必要があります。

2. テキスト・エディタで、必要に応じてmoveplan.xmlファイルを編集します。
移動計画で構成可能なパラメータは次のとおりです:

- OUD非SSLポート

- OUD SSLポート

- OUD管理コネクタ・ポート

- SNMPリスニング・ポート

- SNMPトラップ・ポート

- JMXポート

- OUDルート・ユーザー・パスワード・ファイル

- SMTPサーバーおよびポート

- 次のようなファイルまたはディレクトリの絶対パス

- バックアップ・ディレクトリ

- データベース・ディレクトリ

- プロファイル・ディレクトリ

- 辞書ファイル

- 参照整合性プラグイン・ログ・ファイル

- SMTPアカウント・ステータス通知ハンドラ・メッセージ・テンプレート・ファイル

3. moveplan.xmlファイルを保存します。

28.3.2.3 構成の貼付け

移動計画の編集が完了したら、次の手順で構成をターゲット環境に貼り付けます:

1. アーカイブと移動計画をターゲット・ホストに移動します。
ほとんどのシナリオでは、テスト環境と本番環境は別々のマシンに存在します。そのため、アーカイブと移動計画をターゲット・マシンに移動またはコピーする必要があります。

テスト環境と本番環境が同じマシンに存在する場合は、この手順は不要です。

2. ターゲット環境でoudPasteConfigコマンドを実行することによって、ターゲット環境に構成を貼り付けます。
UNIXシステムでは、次のようにコマンドを実行します:

$ OUD_ORACLE_HOME/bin/oudPasteConfig -javaHome java_home \
-targetInstanceHomeLoc instance_dir -archiveLoc archive_location \
-targetOracleHomeLoc ORACLE_HOME -movePlanLoc move_plan_location \
-logDirLoc log_directory -targetInstanceName instance_name

例:

$ OUD_ORACLE_HOME/bin/oudPasteConfig -javaHome /usr/jdk \
-targetInstanceHomeLoc /local/asinst_2 -archiveLoc /tmp/oud.jar \
-targetOracleHomeLoc /local/ORACLE_HOME -movePlanLoc /tmp/moveplan.xml \
-logDirLoc /tmp/logs -targetInstanceName asinst_2

Windowsシステムでは、次のようにコマンドを実行します:

$ OUD_ORACLE_HOME\bat\oudPasteConfig.bat -javaHome java_home \
-targetInstanceHomeLoc instance_dir -archiveLoc archive_location \
-targetOracleHomeLoc ORACLE_HOME -movePlanLoc move_plan_location \
-logDirLoc log_directory -targetInstanceName instance_name

oudPasteConfigコマンドの完全なシノプシスは、A.2.11項「oudPasteConfig」を参照してください。

oudPasteConfigコマンドは、アーカイブおよび修正済移動計画(存在する場合)から取得した構成とともに新しいサーバー・インスタンスを作成します。

28.3.3 データの移動

テスト・システムから本番システムにデータを移動する最も簡単な方法は、テスト・システムからデータをエクスポートし、本番システムにインポートすることです。

この手順の詳細は、第17.1項「データのインポートとエクスポート」を参照してください。

第VI部

高度な管理: パフォーマンスの監視とチューニング

この部では、Oracle Unified Directoryサーバー・インスタンスの監視方法とサーバーのパフォーマンスのチューニング方法について説明します。

この部には次の章が含まれます:

- 第29章「Oracle Unified Directoryの監視」

- 第30章「パフォーマンス・チューニング」

29 Oracle Unified Directoryの監視

Oracle Unified Directoryでは拡張可能な監視フレームワークが提供されます。この章では、監視機能の概要と、監視の構成方法を説明します。監視フレームワークが構成されると、サーバー・インスタンスの統計またはレプリケートされたトポロジを表示できます。

この章では、次のトピックを取り扱います:

- 第29.1項「監視の概要」

- 第29.2項「監視プロバイダの構成」

- 第29.3項「ログの構成」

- 第29.4項「アラートおよびアカウント・ステータス通知ハンドラの構成」

- 第29.5項「LDAPを使用したサーバーの監視」

- 第29.6項「SNMPを使用したサーバーの監視」

- 第29.7項「レプリケートされたトポロジの監視」

- 第29.8項「汎用のエンタープライズの監視のソリューション」

29.1 監視の概要

監視情報およびパフォーマンス・データは、次の場所にあります:

- ログ
ログの構成の詳細は、第29.3項「ログの構成」を参照してください。

- アラート
アラートの構成の詳細は、第29.4項「アラートおよびアカウント・ステータス通知ハンドラの構成」を参照してください。

- cn=monitor
cn=monitorの詳細は、第29.5項「LDAPを使用したサーバーの監視」を参照してください。

- RFC 2605で定義されているDIRECTORY_SERVER_MIB
SNMPを使用したサーバーの監視の詳細は、第29.6項「SNMPを使用したサーバーの監視」を参照してください。

監視情報にアクセスするには、必要なプロトコルを持っていることを確認します:

- ログの場合、ファイル・システムが必要です。

- アラートの場合、JMX:RMIまたはSMTPが必要です。

- cn=monitorの場合、LDAPまたはJMX:RMI (たとえばjconsole)が必要です。

- DIRECTORY_SERVER_MIBの場合、SNMPが必要です。

29.2 監視プロバイダの構成

監視プロバイダは、デフォルトで有効になっており、監視目的またはトラブルシューティング目的で役に立つサーバーの情報を提供します。cn=monitorエントリには、監視プロバイダによって公開される監視情報が含まれています。監視プロバイダが無効になっていると、提供される情報をcn=monitorの下で使用できなくなります。

監視プロバイダは、dsconfigコマンドを使用して構成できます。詳細は、第14.1項「dsconfigを使用したサーバー構成の管理」を参照してください。

29.2.1 監視プロバイダを表示するには

次に示すように、dsconfigコマンドをlist-monitor-providersサブコマンドとともに実行します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
list-monitor-providers

Monitor Provider   : Type              : enabled
-------------------:-------------------:--------
Client Connections : client-connection : true
Entry Caches       : entry-cache       : true
JVM Memory Usage   : memory-usage      : true
JVM Stack Trace    : stack-trace       : true
System Info        : system-info       : true
Version            : version           : true

29.2.2 監視プロバイダを無効にするには

次に示すように、dsconfigコマンドをset-monitor-provider-propとともに実行します:

たとえば、JVM Stack Trace監視プロバイダをfalseに設定するには、次のコマンドを使用します:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
set-monitor-provider-prop --provider-name "JVM Stack Trace" \
--set enabled:false

ここでdsconfigコマンドをlist-monitor-providersサブコマンドとともに実行すると、JVM Stack Trace監視プロバイダがfalseとして表示されます:

Monitor Provider   : Type             : enabled
-------------------:-------------------:--------
Client Connections : client-connection : true
Entry Caches       : entry-cache       : true
JVM Memory Usage   : memory-usage      : true
JVM Stack Trace    : stack-trace       : false
System Info        : system-info       : true
Version            : version           : true

29.3 ログの構成

Oracle Unified Directoryでは、アクセス・ログ、監査ログ、エラー・ログ、デバッグ・ログ、レプリケーション修復ログなど、様々なタイプのログが提供されます。レプリケーション修復ログは読取り専用であり、レプリケーションの競合解決を有効にする場合のみ使用できます。次の各項では、dsconfigコマンドライン・インタフェースまたはOracle Directory Services Managerを使用して、アクセス・ログ、監査ログ、エラー・ログおよびデバッグ・ログを構成する方法を説明します。また、この項では、管理操作のログ方法も説明します。

ログの結果コードの詳細は、第D.17.11項「結果コード」を参照してください。

この項には次のトピックが含まれます:

- 第29.3.1項「dsconfigを使用したログの構成」

- 第29.3.2項「ODSMを使用したログの構成」

- 第29.3.3項「アクセス・ログ・パブリッシャへの操作のロギング」

29.3.1 dsconfigを使用したログの構成

dsconfigを使用してロギングを構成する最も簡単な方法は、このコマンドを対話モードで使用して、構成に導いてもらうことです。この項では、非対話モードで必要なコマンドを示し、設定される特定のパラメータがわかるようにします。dsconfigの詳細は、第14.1項「dsconfigを使用したサーバー構成の管理」を参照してください。

ログ構成には、次の3つの構成オブジェクトの定義が含まれています:

- ログ・パブリッシャ。ログ・パブリッシャは、各ロガーに対して定義されます。ログ・パブリッシャのタイプは、ログのタイプに対応します。ログ・パブリッシャの詳細は、第29.3.1.1項「ログ・パブリッシャの構成」を参照してください。

- ログ保存ポリシー。保存ポリシーによって、アーカイブされたログ・ファイルの格納期間が決まります。ログ保存ポリシーの詳細は、第29.3.1.2項「ログ保存ポリシーの構成」を参照してください。

- ログ・ローテーション・ポリシー。ローテーション・ポリシーによって、ログ・ファイルのローテーション頻度が決まります。ログ・ローテーション・ポリシーの詳細は、第29.3.1.3項「ログ・ローテーション・ポリシーの構成」を参照してください。

29.3.1.1 ログ・パブリッシャの構成

Oracle Unified Directoryは、デフォルトでいくつかのログ・パブリッシャを提供します。

任意のタイプのログ・パブリッシャを任意の数定義して、いつでもアクティブにできます。つまり、様々な場所または様々なタイプのリポジトリにログでき、ログに含めるものに関して様々な条件セットを指定できます。

ログ・パブリッシャに関連付けられた構成プロパティの詳細は、Oracle Unified Directory構成リファレンスを参照してください。

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

- 第29.3.1.1.1項「既存のログ・パブリッシャをリストするには」

- 第29.3.1.1.2項「ログ・パブリッシャを有効にするには」

- 第29.3.1.1.3項「ODL形式でのロギング」

- 第29.3.1.1.4項「内部操作のロギング」

- 第29.3.1.1.5項「ローカル・タイムスタンプを使用したログ・ファイルのローテーション名の構成」

29.3.1.1.1 既存のログ・パブリッシャをリストするには

1. 既存のログ・パブリッシャを表示するには、次のdsconfigコマンドを実行します:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
list-log-publishers

デフォルトの出力は、次のようなものです:

Log Publisher                  : Type              : enabled
-------------------------------:-------------------:--------
File-Based Access Logger       : file-based-access : true
File-Based Admin Access Logger : file-based-access : true
File-Based Audit Logger        : file-based-access : false
File-Based Debug Logger        : file-based-debug  : false
File-Based Error Logger        : file-based-error  : true
Oracle Access Logger           : file-based-access : false
Oracle Error Logger            : file-based-error  : false
Replication Repair Logger      : file-based-error  : true

2. ログ・パブリッシャのプロパティを表示するには、次のdsconfigコマンドを実行します:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
get-log-publisher-prop --publisher-name "File-Based Error Logger"

29.3.1.1.2 ログ・パブリッシャを有効にするには

すべてのログ・パブリッシャがデフォルトで有効になっているわけではありません。ログ・パブリッシャが無効になっている場合、そのタイプのメッセージはログされません。

ログ・パブリッシャを有効にするには、そのenabledプロパティをtrueに設定します。たとえば、監査ロガーを有効にするには、次のコマンドを実行します:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
set-log-publisher-prop --publisher-name "File-Based Audit Logger" \
--set enabled:true

ログ・パブリッシャが有効になると、サーバーは、適切なパブリッシャへのメッセージのロギングをすぐに開始します。この変更を有効にするためにサーバーを再起動する必要はありません。

29.3.1.1.3 ODL形式でのロギング

Oracle Unified Directoryは、診断ログ・ファイルのOracle Diagnostic Logging形式(ODL)での書込みも実行します。

デフォルトではODLは無効になっています。ODLを有効にするには、ODL Access LogパブリッシャまたはODL Error Logパブリッシャのenabledプロパティをtrueに設定します。次の例では、アクセス・ロガーが有効になります:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
set-log-publisher-prop --publisher-name "Oracle Access Logger" \
--set enabled:true

エラー・ロガーを有効にするには、--publisher-name "Oracle Error Logger"を使用します。

ODLアクセス・ログは、次のファイルに格納されます:

instance_dir/OUD/logs/access.log

ODLエラー・ログは、次のディレクトリに格納されます:

instance_dir/OUD/logs/errors.log

標準アクセス・ロガーおよびエラー・ロガーは、ODLロガーを有効にしても無効になりません。したがって、ODLロガーを有効にした後に標準アクセス・ログおよびエラー・ログを無効にする必要があります(特別に両方の形式のログを保持する場合を除く)。

ODLの詳細(ログ・ファイルの形式の説明を含む)は、『Oracle Fusion Middleware管理者ガイド』のログ・ファイルと診断データの管理に関する項を参照してください。

29.3.1.1.4 内部操作のロギング

デフォルトでは、パブリッシャのsuppress-internal-loggingプロパティはtrueに設定されています。内部操作(LDIF接続ハンドラおよび特定のプラグインによって実行される操作など)をログに記録する必要がある場合、suppress-internal-loggingをfalseに設定します。次の例では、ファイルベースのアクセス・ロガーに関してsuppress-internal-loggingがfalseに設定されます:

dsconfig set-log-publisher-prop \
--publisher-name File-Based\ Access\ Logger \
--add operations-to-log:internal \
--hostname localhost \
--port 4444 \
-X \
--bindDN cn=directory\ manager \
--bindPasswordFile /tmp/password \
--no-prompt

29.3.1.1.5 ローカル・タイムスタンプを使用したログ・ファイルのローテーション名の構成

デフォルトでは、Oracle Unified Directoryは自動的にGMT形式の日付スタンプを使用して、ローカル・サーバーのログ・ファイルの名前を変更(ローテーション)します。

ログ・ファイルのローテーションに関するこれらのデフォルト設定は変更することができます。ローテーションされたログ・ファイルのファイル名にローカル・タイムスタンプを含めるように、サーバー・インスタンスを構成することもできます。

ローカル・タイムスタンプを使用してログ・ファイル名を構成するには、適切なログ・パブリッシャのlog-file-use-local-timeプロパティをtrueに設定する必要があります。次に、ローテーションされたアクセス・ログ・ファイルのファイル名にローカル・タイムスタンプを設定する方法の例を示します。

dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
set-log-publisher-prop --publisher-name "Oracle Access Logger" \
--set log-file-use-local-time:true

注意:

ローカル・タイムスタンプを使用したローテーション・ログ・ファイル名は、互換性を確保するためにOracle Directory Server Enterprise Editionで使用する形式に従います。

29.3.1.2 ログ保存ポリシーの構成

ログ・ファイルのサイズおよび領域制限は、ログ保存ポリシーによって決まります。Oracle Unified Directoryには、次の3つのログ保存ポリシーがあります:

- ファイル数保存(file-count)。デフォルトでは、このポリシーは、指定したタイプのログ・ファイルの最大ログ・ファイル数を10に設定します。

- 空きディスク領域保存(free-disk-space)。デフォルトでは、このポリシーは、指定したタイプのログ・ファイルの残りの最小空きディスク領域の制限を500MBに設定します。

- サイズ制限保存(size-limit)。デフォルトでは、このポリシーは、指定したタイプのログ・ファイルの使用されるディスク領域を最大500MBに設定します。

デフォルトでは、有効になっているログ保存ポリシーは、ファイル数保存です。

独自のカスタム・ログ保存ポリシーを作成することも可能です。

29.3.1.2.1 ログ保存ポリシーを表示するには

既存のログ保存ポリシーのリストを表示するには、次のdsconfigコマンドを実行します:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
list-log-retention-policies

デフォルトの出力は、次のようなものです:

Log Retention Policy             : Type            : disk-space-used : free-disk-space : number-of-files
---------------------------------:-----------------:-----------------:-----------------:----------------
File Count Retention Policy      : file-count      : -               : -               : 10
Free Disk Space Retention Policy : free-disk-space : -               : 500 mb          : -
Size Limit Retention Policy      : size-limit      : 500 mb          : -               : -

ログ保存ポリシーのプロパティをリストするには、次のdsconfigコマンドを実行します。

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \
get-log-retention-policy-prop --policy-name "Free Disk Space Retention Policy"

29.3.1.2.2 ログ保存ポリシーを作成するには

ログ保存ポリシーを作成し、これをenabledに設定するには、次のように入力します:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -w pwd-file -X -n
create-log-retention-policy --policy-name MyMaxDiskSpace \
--type size-limit --set disk-space-used:100mb

29.3.1.2.3 ログ保存ポリシーを変更するには

既存のログ保存ポリシーのプロパティを変更するには、次のdsconfigコマンドを実行します:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -w pwd-file -X -n \
set-log-retention-policy-prop --policy-name "File Count Retention Policy" \
--set number-of-files:20

プロパティ値を設定するかわりに、--add、--resetまたは--removeサブコマンドを--setサブコマンドのかわりに使用して、プロパティ値を追加、リセットまたは削除できます。詳細は、第A.2.4項「dsconfig」を参照してください。

29.3.1.3 ログ・ローテーション・ポリシーの構成

ファイルをローテーションする頻度(つまり、ログ・ファイルが様々な条件に基づいて保持される期間)は、ログ・ローテーション・ポリシーによって決まります。Oracle Unified Directoryには、次の4つのログ・ローテーション・ポリシーがあります:

- 24時間制限のローテーション・ポリシー。デフォルトでは、このポリシーは、ローテーション間隔を1日に設定します。時刻は構成できます。

- 7日間制限のローテーション・ポリシー。デフォルトでは、このポリシーは、ローテーション間隔を1週間に設定します。時刻は構成できます。

- 固定時間制限のローテーション・ポリシー。デフォルトでは、このポリシーは、ログ・ファイルをローテーションする時刻を深夜の1分前に設定します。

- サイズ時間制限のローテーション・ポリシー。デフォルトでは、このポリシーは、ログ・ファイルが到達できる最大サイズを100MBに設定し、これに到達するとログ・ファイルはローテーションされます。

デフォルトで有効になっているログ・ローテーション・ポリシーのタイプは、ログ・タイプによって異なります。

- アクセス・ログと監査ログでは、次のポリシーが有効になっています:

- 24時間制限のローテーション・ポリシー

- サイズ時間制限のローテーション・ポリシー

- エラー・ログとレプリケーション修復ログでは、次のポリシーが有効になっています:

- 7日間制限のローテーション・ポリシー

- サイズ時間制限のローテーション・ポリシー

独自のカスタム・ログ・ローテーション・ポリシーを作成することも可能です。

注意:

複数のローテーション・ポリシーが同じログに対して指定された場合、到達した最初のしきい値によってローテーションがトリガーされます。

29.3.1.3.1 ログ・ローテーション・ポリシーを表示するには

既存のログ・ローテーション・ポリシーのリストを表示するには、次のdsconfigコマンドを実行します:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -w pwd-file -X -n \
list-log-rotation-policies

デフォルトの出力は、次のようなものです:

Log Rotation Policy                 : Type       : file-size-limit : rotation-interval : time-of-day
------------------------------------:------------:-----------------:-------------------:------------
24 Hours Time Limit Rotation Policy : time-limit : -               : 1 d               : -
7 Days Time Limit Rotation Policy   : time-limit : -               : 1 w               : -
Fixed Time Rotation Policy          : fixed-time : -               : -                 : 2359
Size Limit Rotation Policy          : size-limit : 100 mb          : -                 : -

ログ・ローテーション・ポリシーのプロパティを表示するには、次のコマンドを実行します:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -w pwd-file -X -n \
get-log-rotation-policy-prop "Fixed Time Rotation Policy"

29.3.1.3.2 ログ・ローテーション・ポリシーを作成するには

ログ・ローテーション・ポリシーを作成するには、次のdsconfigコマンドを実行します:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -w pwd-file -X -n \
create-log-rotation-policy --policy-name my2DayPolicy \
--type time-limit --set rotation-interval:2d

ポリシー・タイプは次のいずれかにできます:

- size-limit

- fixed-time

- time-limit

29.3.1.3.3 特定のログ・ファイルにログ・ローテーションまたはログ保存を設定するには

特定のログ・ファイルにローテーション・ポリシーまたは保存ポリシーを設定するには、ログ・パブリッシャを作成し、ログ・ローテーション・ポリシーまたはログ保存ポリシーを設定する必要があります。

特定のログ・ファイルにログ・ローテーションまたはログ保存を設定するには、次のdsconfigコマンドを実行します:

$ dsconfig -h localhost -p 1444 -D "cn=Directoy manager" -j pwd-file -n -X \
create-log-publisher --publisher-name myPublisher \
--type file-based-access --set log-file:logs/myLogs --set enabled:true \
--set retention-policy:MyMaxDiskSpace --set rotation-policy:my2DayPolicy

29.3.2 ODSMを使用したログの構成

この項では、ODSMを使用してログを構成する方法を説明します。次のトピックが含まれます:

- 第29.3.2.1項「ロガー・プロパティの変更」

- 第29.3.2.2項「ログ・ローテーション・ポリシーの変更」

- 第29.3.2.3項「ログ保存ポリシーの変更」

29.3.2.1 ロガー・プロパティの変更

Oracle Unified Directoryは、デフォルトでいくつかのログ・パブリッシャ(またはロガー)を提供します。任意のタイプのロガーを任意の数定義して、いつでもアクティブにできます。つまり、様々な場所または様々なタイプのリポジトリにログでき、ログに含めるものに関して様々な条件セットを指定できます。

ODSMを使用して新規ログ・パブリッシャを作成できませんが、既存のログ・パブリッシャのプロパティを変更できます。

ODSMを使用してロガー・プロパティを構成するには、次の手順に従います:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「構成」タブを選択します。

3. 「一般構成」要素を展開します。

4. 「ロギング」要素を展開します。

5. 「ロガー」要素を展開し、変更するプロパティを持つロガーをクリックします。

ロガーのプロパティが右側のペインに表示されます。構成可能なプロパティは、選択したロガーのタイプによって異なります。構成可能なすべてのプロパティおよび設定可能なプロパティ値の包括的なリストは、Oracle Unified Directory構成リファレンスを参照してください。

Oracle Unified Directoryは、選択したロガーのタイプに応じて、次の一般構成ポリシーを提供します:

- 有効。これは、ログ・パブリッシャの使用が有効になっているかどうかを示します。

- ログ・パブリッシャ・ファイルの場所。これは、ファイルベースのアクセス・ログ・パブリッシャによって生成されたログ・ファイルに使用するファイル名を指定します。ファイルへのパスは、サーバー・ルートに対して相対的です。

- ログ・パブリッシャの権限。これは、このファイルベースのアクセス・ログ・パブリッシャによって作成されたログ・ファイルのUNIX権限を示します。

- ログに記録する操作。これは、ログに記録する必要がある操作を示します。
このプロパティは、アクセス・ログ・パブリッシャおよび監査ログ・パブリッシャに対してのみ使用可能です。

- リクエスト・コントロールおよびレスポンス・コントロールのロギング。これは、クライアント・アプリケーションによってリクエストされた操作とともにリクエスト・コントロールおよびレスポンス・コントロールをログに記録する必要があるかどうかを示します。
このプロパティは、アクセス・ログ・パブリッシャおよび監査ログ・パブリッシャに対してのみ使用可能です。

- デフォルト重大度。これは、ロガーのデフォルトの重大度レベルを指定します。
このプロパティは、エラー・ログ・パブリッシャに対してのみ使用可能です。

- デフォルト・デバッグ・レベル。これは、定義済のターゲットのいずれもメッセージと一致しない場合にログに記録するデバッグ・メッセージの最低の重大度レベルを指定します。
このプロパティは、デバッグ・ログ・パブリッシャに対してのみ使用可能です。

構成可能なすべてのプロパティおよび各ロガーに設定可能なプロパティ値の包括的なリストは、Oracle Unified Directory構成リファレンスを参照してください。

注意:

手順5で選択したロガーにログ・ローテーション・ポリシーおよびログ保存ポリシーを構成できます。ログ・ローテーション・ポリシーおよびログ保存ポリシーの構成の詳細は、第29.3.2.2項「ログ・ローテーション・ポリシーの変更」および第29.3.2.3項「ログ保存ポリシーの変更」を参照してください。

29.3.2.2 ログ・ローテーション・ポリシーの変更

ログ・ファイルをローテーションする頻度(つまり、ログ・ファイルが様々な条件に基づいて保持される期間)は、ログ・ローテーション・ポリシーによって決まります。

Oracle Unified Directoryには、次の4つのログ・ローテーション・ポリシーがあります:

- 24時間制限のローテーション・ポリシー。デフォルトでは、このポリシーは、ローテーション間隔を1日に設定します。時刻は構成できます。

- 7日間制限のローテーション・ポリシー。デフォルトでは、このポリシーは、ローテーション間隔を1週間に設定します。時刻は構成できます。

- 固定時間制限のローテーション・ポリシー。デフォルトでは、このポリシーは、ログ・ファイルをローテーションする時刻を深夜の1分前に設定します。

- サイズ時間制限のローテーション・ポリシー。デフォルトでは、このポリシーは、ログ・ファイルが到達できる最大サイズを100MBに設定し、これに到達するとログ・ファイルはローテーションされます。

デフォルトで有効になっているログ・ローテーション・ポリシーのタイプは、ロガー・タイプによって異なります。

次のようにODSMを使用して、ログ・ローテーション・ポリシーを構成できます:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「構成」タブを選択します。

3. 「一般構成」要素を展開します。

4. 「ロギング」要素を展開します。

5. 「ローテーション・ポリシー」要素を選択し、必要なプロパティを変更します。

このページで「追加」アイコンや「削除」アイコンをクリックし、必要な情報を入力することによって、新規ローテーション・ポリシーの追加や既存のローテーション・ポリシーの削除も行えます。

29.3.2.3 ログ保存ポリシーの変更

ログ・ファイルのサイズおよび領域制限は、ログ保存ポリシーによって決まります。Oracle Unified Directoryには、デフォルトで次の3つのログ保存ポリシーがあります:

- ファイル数保存(file-count)。デフォルトでは、このポリシーは、指定したタイプのログ・ファイルの最大ログ・ファイル数を10に設定します。

- 空きディスク領域保存(free-disk-space)。デフォルトでは、このポリシーは、指定したタイプのログ・ファイルの残りの最小空きディスク領域の制限を500MBに設定します。

- サイズ制限保存(size-limit)。デフォルトでは、このポリシーは、指定したタイプのログ・ファイルの使用されるディスク領域を最大500MBに設定します。デフォルトでは、有効になっているログ保存ポリシーは、ファイル数保存です。

次のようにODSMを使用して、ログ保存ポリシーを構成できます:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「構成」タブを選択します。

3. 「一般構成」要素を展開します。

4. 「ロギング」要素を展開します。

5. 「保存ポリシー」要素を選択し、必要なプロパティを変更します。

このページで「追加」アイコンや「削除」アイコンをクリックし、必要な情報を入力することによって、新規保存ポリシーの追加や既存の保存ポリシーの削除も行えます。

29.3.3 アクセス・ログ・パブリッシャへの操作のロギング

Oracle Unified Directoryには、ログに記録する操作を指定する新規パラメータがあります。この項では、この新規構成パラメータについて説明し、次のトピックを説明します:

- 第29.3.3.1項「管理ロガーの概要」

- 第29.3.3.2項「ODSMを使用してアクセス・ログ・パブリッシャにログされた操作の構成」

29.3.3.1 管理ロガーの概要

Oracle Unified Directoryには、管理コネクタを使用して管理ログをユーザー・ログから分離するメカニズムがあります。管理操作は、管理トラフィックと関連付けられたロギング情報を提供する異なるファイルにログされるようになります。

注意:

Oracle Unified Directoryは、元の状態で、管理コネクタの操作のみを含むファイルベースの管理アクセス・ロガーという専用アクセス・ロガーをサポートしています。したがって、異なるファイルに管理操作をログに記録するために特別なアクションを実行する必要はありません。

operations-to-logプロパティを使用して、アクセス・ログを構成してログに記録する操作のタイプを指定できます。このプロパティはオプションで、次構成可能な値を持っています:

- SYNCHRONIZATION

- INTERNAL

- ADMINISTRATION

- USER

- ADMIN_BROWSING

- ALL

この意味では、Oracle Unified Directoryは、次の操作タイプをサポートしています:

- 同期操作
ロック、プロセス同期、属性マッピング、変換などの同期操作。

- 内部操作
内部操作は、クライアントからの外部リクエストによってではなく、プラグインによって内部的に開始されるため、内部的です。クライアントのリクエストが存在しない操作を実行するためにプラグインがディレクトリ・サーバーを必要とする場合、内部操作コールを使用する必要があります。

- 管理操作
管理操作は、ネットワーク・グループ選択コントロールに関連付けられた操作を除いて、管理ネットワーク・グループに対して実行されます。

- ユーザー操作
ユーザー操作は、ネットワーク・グループ選択コントロールに関連付けられた操作を除いて、任意のユーザー・ネットワーク・グループに対して実行されます。

- 管理参照操作
管理参照操作は、ネットワーク・グループ選択コントロールと関連付けられています。これは、ネットワーク・グループ依存に関連付けられた操作を除外します。

注意:

ネットワーク・グループによって処理された操作はユーザーによって作成され、管理接尾辞にアクセスすることはユーザー操作と見なされます。

29.3.3.2 ODSMを使用してアクセス・ログ・パブリッシャにログされた操作の構成

ODSMは、ログ・パブリッシャのプロパティの特性および動作に応じて、ログ・パブリッシャのプロパティを3つの異なるヘッダー(「ロガーの一般プロパティ」、「ローテーションおよび保持ポリシー」および「拡張プロパティ」)にグループ化します。「ロガーの一般プロパティ」リージョンは、デフォルトですべてのロガーに表示可能で、ファイルベースのアクセス・ロガーにログに記録する操作を構成できます。

次のようにODSMを使用して、アクセス・ログ・パブリッシャにログに記録する操作を構成できます:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーまたはディレクトリ・プロキシ・サーバーに接続します。

2. 「構成」タブを選択します。

3. 「一般構成」要素を展開します。

4. 「ロギング」要素を展開します。

5. 「ロガー」要素を展開します。

6. 変更するファイルベースのアクセス・ロガー(たとえば、ファイルベースの管理アクセス・ロガー)をクリックします。

7. 「ロガーの一般プロパティ」リージョンで、次の手順を実行します:
「ログに記録する操作」リストから、ログに記録する操作を選択します。

8. 「適用」をクリックします。

29.4 アラートおよびアカウント・ステータス通知ハンドラの構成

Oracle Unified Directoryには、JMX拡張子またはSMTP拡張子によってアラートおよびアカウント・ステータス通知を転送するメカニズムがあります。ディレクトリ・サーバーを構成して、処理中にイベントが発生したときにアラート通知を送信できます。一般的なサーバー・イベントには、サーバーの起動とシャットダウン、サーバーによって検出される問題(構成ファイルに書き込もうとするなど)が含まれます。

パスワード・ポリシーの処理中にイベント(アカウントのロック・アウト、アカウントの期限切れ、パスワードの期限切れなど)が発生したときにアカウント・ステータス通知を受信することも可能です。

アラートとアカウント・ステータス通知ハンドラは、dsconfigコマンドを使用して構成されます。詳細は、第14.1項「dsconfigを使用したサーバー構成の管理」を参照してください。

この項のトピックの詳細は、第24章「パスワード・ポリシーの管理」およびOracle Unified Directory構成リファレンスのアラート・ハンドラ構成に関する項を参照してください。

29.4.1 アラート・ハンドラの管理

Oracle Unified Directoryには、JMX拡張子またはSMTP拡張子によってアラートおよびアカウント・ステータス通知を転送するメカニズムがあります。

Oracle Unified Directoryを構成して、処理中にイベントが発生したときにアラート通知を送信できます。一般的なサーバー・イベントには、サーバーの起動とシャットダウン、サーバーによって検出される問題(構成ファイルに書き込もうとするなど)が含まれます。パスワード・ポリシーの処理中にイベント(アカウントのロック・アウト、アカウントの期限切れ、パスワードの期限切れなど)が発生したときにアカウント・ステータス通知を受信することも可能です。

Oracle Unified Directoryでは、次のアラート・ハンドラがサポートされます:

- JMX通知用のJMXアラート・ハンドラ

- 電子メール通知用のSMTPアラート・ハンドラ

次のトピックでは、アラート・ハンドラ構成の管理方法を説明します:

- 第29.4.1.1項「dsconfigを使用したアラート・ハンドラの管理」

- 第29.4.1.2項「ODSMを使用したアラート・ハンドラの管理」

- 第29.4.1.3項「サポートされているアラート・タイプ」

29.4.1.1 dsconfigを使用したアラート・ハンドラの管理

次の項では、dsconfigを使用したアラート・ハンドラ構成の管理方法を説明します。ODSMインタフェースを使用したアラートの構成の詳細は、第29.4.1.2項「ODSMを使用したアラート・ハンドラの管理」を参照してください。

この項には次のトピックが含まれます:

- 第29.4.1.1.1項「構成済のアラート・ハンドラを表示するには」

- 第29.4.1.1.2項「アラート・ハンドラを有効にするには」

- 第29.4.1.1.3項「新規アラート・ハンドラを作成するには」

- 第29.4.1.1.4項「アラート・ハンドラを削除するには」

- 第29.4.1.1.5項「許可されているアラート・タイプをコントロールするには」

29.4.1.1.1 構成済のアラート・ハンドラを表示するには

Oracle Unified Directoryは、アラート・ハンドラの情報をcn=Alert Handlers,cn=configサブツリーの下の構成ファイルに格納します。この情報には、dsconfigコマンドを使用してアクセスできます。

アラート・ハンドラのリストを表示するには、次のdsconfigコマンドを実行します:

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
list-alert-handlers

Alert Handler     : Type : enabled
------------------:------:--------
JMX Alert Handler : jmx  : false

29.4.1.1.2 アラート・ハンドラを有効にするには

JMXアラート・ハンドラはデフォルトでは無効になっています。開始する前に、サーバー上でJMXを構成する必要があります。詳細は、第29.5.3項「JConsoleを使用したサーバーの監視」を参照してください。

1. アラート・ハンドラのプロパティをリストするには、次のようにdsconfigコマンドを使用します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
get-alert-handler-prop --handler-name "JMX Alert Handler"

Property            : Value(s)
--------------------:---------------------------------------------
disabled-alert-type : -
enabled             : false
enabled-alert-type  : -

2. アラート・ハンドラを有効にするには、次のようにdsconfigを使用します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
set-alert-handler-prop --handler-name "JMX Alert Handler" --set enabled:true

3. dsconfigを使用して変更内容を確認します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
get-alert-handler-prop --handler-name "JMX Alert Handler"

Property            : Value(s)
--------------------:---------------------------------------------
disabled-alert-type : -
enabled             : true
enabled-alert-type  : -

29.4.1.1.3 新規アラート・ハンドラを作成するには

次の例では、新規SMTPハンドラを構成します。この手順を開始する前に、Oracle Unified DirectoryのSMTPサーバーが構成済である必要があります。

1. アラート・ハンドラを作成するには、dsconfigをcreate-alert-handlerサブコマンドとともに実行します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
create-alert-handler --handler-name "my SMTP Handler" --type smtp \
--set enabled:true --set message-body:"Alert Type: %%alert-type%%
\n\nAlert ID: %%alert-id%%\n\nAlert Message: %%alert-message%%" \
--set message-subject:"Alert Message" \
--set recipient-address:directorymanager@example.com \
--set sender-address:OUD-Alerts@directory.example.com

2. 次のようにアラート・ハンドラのリストを表示します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
list-alert-handlers

29.4.1.1.4 アラート・ハンドラを削除するには

アラート・ハンドラを削除するには、dsconfig delete-alert-handlerコマンドを使用します。次の例では、JMXアラート・ハンドラを削除します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
delete-alert-handler --handler-name "JMX Alert Handler"

アラート・ハンドラを削除するかわりに、これを単に無効にできます。この場合、将来このアラート・ハンドラを再有効化する必要がある場合、これを使用できます。詳細は、第29.4.1.1.5項「許可されているアラート・タイプをコントロールするには」を参照してください。

29.4.1.1.5 許可されているアラート・タイプをコントロールするには

サポートされているすべてのアラート・タイプのリストは、第29.4.1.3項「サポートされているアラート・タイプ」を参照してください。

デフォルトでは、サポートされているすべてのアラート・タイプが許可されます。enabled-alert-typeプロパティに値を指定すると、これらのタイプのいずれかであるアラートのみが許可されます。disabled-alert-typeプロパティに値を指定すると、このプロパティの値のタイプを除くすべてのアラート・タイプが許可されます。アラート・タイプは、この例に示すようにJavaクラスによって指定されます。

アラート・タイプを無効にするには、そのJavaクラスをdisabled-alert-typeプロパティの値として指定します。

このコマンドは、JMXアラート・ハンドラから起動アラートを無効にします。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
set-alert-handler-prop --handler-name "JMX Alert Handler" \
--set disabled-alert-type:org.opends.server.DirectoryServerStarted

29.4.1.2 ODSMを使用したアラート・ハンドラの管理

次の項では、ODSMを使用したアラート・ハンドラ構成の管理方法を説明します。dsconfigを使用したアラート・ハンドラの構成の詳細は、第29.4.1.1項「dsconfigを使用したアラート・ハンドラの管理」を参照してください。

29.4.1.2.1 アラート・ハンドラの作成

ODSMを使用してアラート・ハンドラを作成するには、次の手順を実行します:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「構成」タブを選択します。

3. 「作成」メニューから、「アラート・ハンドラ」を選択します。

4. 作成するアラート・ハンドラのタイプを選択します:

- JMX。このアラート・ハンドラは、JMX通知を生成して、サーバー内で発生する重大なイベントを管理者にアラートするために使用されます。

- SMTP。このアラート・ハンドラは、電子メール・メッセージを送信して、サーバー内で発生する重大なイベントを管理者に通知するために使用されます。

5. 右側のペインにプロパティを入力して接続ハンドラを構成します。
構成可能なプロパティは、選択したアラート・ハンドラのタイプによって異なります。構成可能なすべてのプロパティおよび設定可能なプロパティ値の包括的なリストは、Oracle Unified Directory構成リファレンスのアラート・ハンドラ構成に関する項を参照してください。

6. 注意:

デフォルトでは、すべてのアラート・タイプが許可されます。「有効なアラート・タイプ」フィールドで1つ以上の値を指定すると、これらのタイプのいずれかであるアラートのみが許可されます。「無効なアラート・タイプ」フィールドに1つ以上の値を指定すると、このフィールドの値のタイプを除くすべてのアラート・タイプが許可されます。
サポートされているすべてのアラート・タイプのリストは、第29.4.1.3項「サポートされているアラート・タイプ」を参照してください。

7. 特定のアラート・ハンドラ・タイプに必要なプロパティを構成済の場合、「作成」をクリックします。

29.4.1.2.2 アラート・ハンドラの変更

次のようにODSMを使用して、既存のアラート・ハンドラを変更できます:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「構成」タブを選択します。

3. 「一般構成」要素を展開します。

4. 「アラート・ハンドラ」要素を展開します。

5. 変更するプロパティを持つアラート・ハンドラを選択します。

6. 右側のペインにプロパティが表示されます。

7. 必要なプロパティを変更したら、「適用」をクリックします。

29.4.1.2.3 アラート・ハンドラの削除

次のようにODSMを使用して、既存のアラート・ハンドラを変更できます:

1. 第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。

2. 「構成」タブを選択します。

3. 「一般構成」要素を展開します。

4. 「アラート・ハンドラ」要素を展開します。

5. 削除するアラート・ハンドラを選択し、「構成の削除」アイコンをクリックします。

6. 削除の確認を求められます。「はい」をクリックします。

29.4.1.3 サポートされているアラート・タイプ

サーバーは、システムでアラート・タイプ・イベントが発生すると、メッセージ・アラートを送信します。サポートされているアラート・タイプは、次の表で定義されています。

アラート・タイプ

説明

アクセス制御無効

Javaクラス: org.opends.server.AccessControlDisabled

アクセス・コントロール・ハンドラが無効になったことを管理者に通知します。

アクセス制御有効

Javaクラス: org.opends.server.Enabled

アクセス・コントロール・ハンドラが有効になったことを管理者に通知します。

アクセス制御の解析に失敗しました

Javaクラス: org.opends.server.authentication.dseecompat.ACIParseFailed

サーバーを初めて起動したときに、Oracle Directory Server Enterprise Edition互換のアクセス・コントロール・サブシステムが1つ以上のACIルールを正しく解析できなかったことを管理者に通知します。

バックエンド環境使用不可

Javaクラス: org.opends.server.BackendRunRecovery

JEバックエンドがRunRecoveryExceptionをスローし、ディレクトリ・サーバーを再起動する必要があることを管理者に通知します。

スキーマ・ファイルをコピーできません

Javaクラス: org.opends.server.CannotCopySchemaFiles

スキーマの更新の前に既存のスキーマ構成のコピーを作成しようとしている間に問題が発生し、スキーマ構成が一貫性のない状態のままになっている可能性がある場合に管理者に通知します。

繰返しタスクが見つかりません

Javaクラス: org.opends.server.CannotFindRecurringTask

前の繰返しが完了した後、次の繰返しをスケジュールするための反復タスク定義をディレクトリ・サーバーが見つけられなかった場合に管理者に通知します。

現在のタスク・ファイルの名前を変更できません

Javaクラス: org.opends.server.CannotRenameCurrentTaskFile

更新したバージョンを書き込もうとするプロセスで、ディレクトリ・サーバーが現在のタスクのバッキング・ファイルの名前を変更できない場合に管理者に通知します。

新規タスク・ファイルの名前を変更できません

Javaクラス: org.opends.server.CannotRenameNewTaskFile

ディレクトリ・サーバーが新規タスクのバッキング・ファイルの名前を適切に変更できない場合に管理者に通知します。

反復の繰返しをスケジュールできません

Javaクラス: org.opends.server.CannotScheduleRecurringIteration

ディレクトリ・サーバーが繰返しタスクの反復をスケジュールできない場合に管理者に通知します。

構成を書き込めません

Javaクラス: org.opends.server.CannotWriteConfig

ディレクトリ・サーバーがなんらかの理由で更新した構成を書き込めず、サーバーを再起動してもサーバーが新規構成を表示できない場合に管理者に通知します。

新規スキーマ・ファイルを書き込めません

Javaクラス: org.opends.server.CannotWriteNewSchemaFiles

新しいバージョンのサーバー・スキーマ構成ファイルを書き込もうとしている間に問題が発生し、スキーマ構成が一貫性のない状態のままになっている可能性がある場合に管理者に通知します。

タスク・ファイルを書き込めません

Javaクラス: org.opends.server.CannotWriteTaskFile

ディレクトリ・サーバーが更新したタスクのバッキング・ファイルをなんらかの理由で書き込めない場合に管理者に通知します。

分散バックエンドはPreRead制御をサポートしていません

Javaクラス: com.sun.dps.server.distribution.globalindex.UnsupportedDirectoryBackend

分散によってグローバル索引カタログの内容を維持できない場合に管理者に通知します。これは、1つ以上のサーバーが読込み前エントリ制御(RFC 4527)をサポートしていない場合に発生します。

ロックダウン・モードの開始中

Javaクラス: org.opends.server.EnteringLockdownMode

ルート・ユーザーのみがループバック・アドレスを介してのみ操作の実行を許可されているロックダウン・モードをディレクトリ・サーバーが開始中の場合に管理者に通知します。

LDAP接続ハンドラ連続失敗

Javaクラス: org.opends.server.LDAPHandlerDisabledByConsecutiveFailures

LDAP接続ハンドラで連続して失敗が発生し、このハンドラが無効になったことを管理者に通知します。

LDAP接続ハンドラ・キャッチなしエラー

Javaクラス: org.opends.server.LDAPHandlerUncaughtError

LDAP接続ハンドラでキャッチなしエラーが発生し、このハンドラが無効になったことを管理者に通知します。

LDAPサーバー拡張失敗

Javaクラス: com.sun.dps.server.workflowelement.proxyldap.LDAPServerExtension.LDAPServerExtensionDown

LDAPサーバー拡張が停止中として検出されたことを管理者に通知します。

LDAPサーバー拡張稼働

Javaクラス: com.sun.dps.server.workflowelement.proxyldap.LDAPServerExtension.LDAPServerExtensionUp

LDAPサーバー拡張が稼働中として検出されたことを管理者に通知します。

LDIFバックエンドは更新を書き込めません

Javaクラス: org.opends.server.LDIFBackendCannotWriteUpdate

書込み操作の処理後、更新したLDIFファイルのコピーをLDIFバックエンドが格納できなかったことを管理者に通知します。

LDIF ConnHandler解析エラー

Javaクラス: org.opends.server.LDIFConnectionHandlerParseError

LDIFファイルを解析しようとしてLDIF接続ハンドラでリカバリ不能なエラーが発生したことを管理者に通知します。

LDIF ConnHandler IOエラー

Javaクラス: org.opends.server.LDIFConnectionHandlerIOError

LDIF接続ハンドラでI/Oエラーが発生し、処理を完了できなかったことを管理者に通知します。

ロックダウン・モードの終了中

Javaクラス: org.opends.server.LeavingLockdownMode

ディレクトリ・サーバーがロックダウン・モードを終了中であることを管理者に通知します。

手動構成編集が処理されました

Javaクラス: org.opends.server.ManualConfigEditHandled

サーバーがオンラインの状態でディレクトリ・サーバーの構成が手動で編集され、その変更がサーバーを介して行われた別の変更によってオーバーライドされたことをディレクトリ・サーバーが検出した場合に管理者に通知します。手動で編集した構成は別の場所にコピーされます。

手動構成編集が失われました

Javaクラス: org.opends.server.ManualConfigEditLost

サーバーがオンラインの状態でディレクトリ・サーバーの構成が手動で編集され、その変更がサーバーを介して行われた別の変更によってオーバーライドされたことをディレクトリ・サーバーが検出した場合に管理者に通知します。手動で編集した構成は、予期しないエラーのために保存できませんでした。

SaturationLoadBalancingAlgorithmによって選択された新規ルート

Javaクラス: com.sun.dps.server.SaturationLoadBalancer

飽和ロード・バランシング・アルゴリズムによって新規ルートがアクティブ・ルートとして選択されたことを管理者に通知します。

FailoverLoadBalancingAlgorithmによって選択された新規ルート

Javaクラス: com.sun.dps.server.FailoverLoadBalancer

フェイルオーバー・ロード・バランシング・アルゴリズムによって新規ルートがアクティブ・ルートとして選択されたことを管理者に通知します。

レプリケーション未解決競合

Javaクラス: org.opends.server.replication.UnresolvedConflict

マルチマスター・レプリケーションが競合を自動的に解決できない場合に管理者に通知します。

サーバーが起動しました

Javaクラス: org.opends.server.DirectoryServerStarted

ディレクトリ・サーバーが起動プロセスを完了したことを管理者に通知します。

サーバーのシャットダウン

Javaクラス: org.opends.server.DirectoryServerShutdown

ディレクトリ・サーバーがシャットダウンのプロセスを開始したことを管理者に通知します。

飽和ロード・バランシング・ルートの状態変更

Javaクラス: com.sun.dps.server.SaturationLoadBalancer

飽和ロード・バランシング・ルートの状態が変化した(飽和から未飽和または未飽和から飽和のいずれか)ことを管理者に通知します。

キャッチなし例外

Javaクラス: org.opends.server.UncaughtException

ディレクトリ・サーバーのスレッドでキャッチなし例外が発生し、スレッドが異常終了した場合に管理者に通知します。この問題がディレクトリ・サーバーに与える影響は、影響を受けたスレッドおよび例外の特性によって異なります。

一意属性同期競合

Javaクラス: org.opends.server.UniqueAttributeSynchronizationConflict

一意属性競合が同期処理中に検出されたことを管理者に通知します。

一意属性同期エラー

Javaクラス: org.opends.server.UniqueAttributeSynchronizationError

同期処理中に一意属性競合検出を実行しようとしてエラーが発生したことを管理者に通知します。

サポートされていないディレクトリ・バックエンド

Javaクラス: com.sun.dps.server.distribution.globalindex.UnsupportedDirectoryBackend

分散によってグローバル索引カタログの内容を維持できないことを管理者に通知します。これは、1つ以上のサーバーが読込み前エントリ制御(RFC 4527)をサポートしていない場合に発生します。

29.4.2 アカウント・ステータス通知ハンドラの管理

アカウント・ステータス通知ハンドラは、パスワード・ポリシーの処理中にイベントのアラートを提供します。デフォルトでは、エラー・ログ・アカウント・ステータス通知ハンドラは、初期構成時に有効に設定されます。サーバーは、次のいずれかのイベントがパスワード・ポリシーで構成済で、パスワード・ポリシーの処理中にこれが発生した場合にメッセージをサーバーのエラー・ログに書き込みます:

- account-temporarily-locked

- account-permanently-locked

- account-unlocked

- account-idle-locked

- account-reset-locked

- account-disabled

- account-expired

- password-expired

- password expiring

- password-reset

- password-changed

エラー・ログは、instance-dir/OUD/logs/errorsにあります。

29.4.2.1 構成済のアカウント・ステータス通知ハンドラを表示するには

dsconfigをlist-account-status-notification-handlersサブコマンドとともに使用します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
list-account-status-notification-handlers

Account Status Notification Handler : Type      : enabled
------------------------------------:-----------:--------
Error Log Handler                   : error-log : true
SMTP Handler                        : smtp      : false

29.4.2.2 アカウント・ステータス通知ハンドラを有効にするには

dsconfigコマンドを使用して、既存のアカウント・ステータス通知ハンドラを有効にできます。デフォルトでは、ディレクトリ・サーバーは、サーバーが最初に構成されるときにエラー・ログ・ハンドラを有効にします。この例では、SMTP通知ハンドラを有効にします。

1. enabledプロパティを表示するには、dsconfigをget-account-status-notification-handler-propサブコマンドとともに使用します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
get-account-status-notification-handler-prop --handler-name "SMTP Handler" \
--property enabled

Property : Value(s)
---------:---------
enabled  : false

2. 通知ハンドラを有効にするには、dsconfigをset-account-status-notification-handler-propサブコマンドとともに使用します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
set-account-status-notification-handler-prop --handler-name "SMTP Handler" \
--set property:enabled

29.4.2.3 新規アカウント・ステータス通知ハンドラを作成するには

1. dsconfigをcreate-account-status-notification-handlerサブコマンドとともに使用してハンドラを作成します。
タイプを指定するとき、error-logまたはgeneric(デフォルト)を使用できます。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
create-account-status-notification-handler \
--handler-name "My Password Reset Logger" --type error-log \
--set enabled:true --set account-status-notification-type:password-reset

2. dsconfigを使用して、アカウント・ステータス通知ハンドラのリストを表示します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
list-account-status-notification-handlers

Account Status Notification Handler : Type      : enabled
------------------------------------:-----------:--------
Error Log Handler                   : error-log : true
my Password Reset Logger            : error-log : true
SMTP Handler                        : smtp      : false

29.4.2.4 アカウント・ステータス通知ハンドラを削除するには

アカウント・ステータス通知ハンドラを削除するかわりにこれを無効にできます。この場合、将来このアラート・ハンドラを再有効化する必要がある場合、これを使用できます。

dsconfigを使用して、アカウント・ステータス通知ハンドラを完全に削除できます。

dsconfigをdelete-account-status-notification-handlerサブコマンドとともに使用します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
delete-account-status-notification-handler \
--handler-name "My Password Reset Logger"

29.5 LDAPを使用したサーバーの監視

Oracle Unified Directoryには、デバッグまたはトラブルシューティングの目的でサーバーの現在の状態を監視する様々な方法があります。

この項のトピックでは、サーバーでのプロバイダの監視を構成済であることを前提としています。詳細は、第29.2項「監視プロバイダの構成」を参照してください。

いくつかの方法でLDAPを介してサーバーを監視できます。これらの機能については、次の各項で説明します:

- 第29.5.1項「cn=monitorエントリを使用した監視情報の表示」

- 第29.5.2項「manage-tasksコマンドを使用した監視」

- 第29.5.3項「JConsoleを使用したサーバーの監視」

- 第29.5.4項「ログへのアクセス」

29.5.1 cn=monitorエントリを使用した監視情報の表示

ディレクトリ・サーバーは、cn=monitorのベースDNを使用して、システム、パフォーマンスおよびバージョンの情報をエントリとして記録します。このエントリは、便利なパフォーマンス・メトリックおよびサーバーの状態の情報を提供し、これを使用してディレクトリ・サーバー・インスタンスを管理およびデバッグできます。

管理ポートからのみcn=monitor接尾辞にアクセスできます。管理ポートを使用すると、監視情報にアクセスできる利点があります。管理コネクタの主な利点は、ユーザー・トラフィックと管理トラフィックを分離できることです。

たとえば、通常のLDAPポートを介してLDAP接続ハンドラの接続数を監視する場合、("cn=Client Connections,cn=LDAP Connection Handler 0.0.0.0 port port-number,cn=monitor")、管理データは監視リクエスト自身によって「汚されます」。この項の例はすべて、SSLを介した管理ポートを使用します。詳細は、第14.3項「サーバーへの管理トラフィックの管理」を参照してください。

29.5.1.1 プロキシの監視される属性

プロキシに関する監視情報は、数十の属性(次のものに関係のある属性など)に関してcn=Monitorの下のレベルで収集できます:

- ワークフロー: cn=workflow,cn=monitor

- ネットワーク・グループ: cn=Network Groups,cn=monitor

- ロード・バランサ: cn=load balancing,cn=monitor

- 分散: cn=distribution,cn=monitor

- グローバル索引カタログ: cn=Global Index Catalogs,cn=monitor

- クライアント接続: cn=Client Connections,cn=monitor、またはcn=Client Connections,cn=LDAP Connection Handler 0.0.0.0 port ポート番号,cn=monitorの下

- LDAP接続ハンドラ: cn=LDAP Connection Handler 0.0.0.0 port ポート番号,cn=monitor

- LDAP接続ハンドラ統計: cn=LDAP Connection Handler 0.0.0.0 portポート番号 statistics,cn=monitor

- SNMP接続ハンドラ: cn=SNMP Connection Handler,cn=Monitor

- JMX接続ハンドラ: cn=JMX Connection Handler ポート番号,cn=monitor

- 管理コネクタ: cn=Administration Connector 0.0.0.0 port ポート番号,cn=monitor

- システム情報: cn=System Information,cn=monitor

- バージョン: cn=Version,cn=monitor

- バックエンドLDAPサーバー: cn=LDAP Servers,cn=monitor

- JVMスタック・トレース: cn=JVM Stack Trace,cn=monitor

- JVMメモリー使用量: cn=JVM Memory Usage,cn=Monitor

- SNMP: cn=SNMP,cn=Monitor

- バックエンド・バックアップ: cn=backup Backend,cn=monitor

- バックエンド・データの監視: cn=monitor Backend,cn=monitor

- バックエンド・バックアップのタスク: cn=backup Backend,cn=monitor

- エントリ・キャッシュ: cn=Entry Caches,cn=monitor

- ワーク・キュー: cn=Work Queue,cn=monitor

その他の属性は、dnツリーの前述のそれぞれの下で監視されます。たとえば、クライアント接続は、cn=Client Connections, 0.0.0.0 port ポート番号,cn=monitorとcn=Client Connections,cn=Administration Connector 0.0.0.0 port ポート番号, cn=monitorの下の両方で監視されます。

ワークフロー要素は、そのワークフロー要素が関係するツリーの一部の下で監視されます。たとえば、ロード・バランシング・ワークフロー要素は、cn=load-bal-route1,cn=load balancing,cn=monitorとして監視できます。

数百の統計が監視のためにプロキシによって収集されます。たとえば永続検索機能では、psearchCountは永続検索操作数をリストし、psearchTotalCountは最後のサーバー再起動以降の永続検索操作数をリストします。

ldapsearchコマンドをcn=monitorエントリで使用してこれらの統計をすべてリストできます(第29.5.1.2項「使用可能な監視情報を表示するには」を参照)。cn=monitorエントリへのアクセスは、ACIのバイパス権限を持つユーザーに制限されています。

次の手順は、コマンドライン・インタフェースでldapsearchコマンドを使用します。

グローバル索引のレプリケーションに関するステータス情報を表示するには、gicadm status-replicationコマンドを使用します。詳細は、第15.1.7.2.5項「レプリケートされたグローバル索引カタログ構成のステータスを表示するには」を参照してください。

29.5.1.2 使用可能な監視情報を表示するには

ldapsearchコマンドを使用して、cn=monitorの属性を検査します。この例では、各監視エントリのベースDNをリストします。

検索範囲をsub、検索属性を1.1に設定して、ldapsearchコマンドを実行します。

この検索属性は、一致するエントリに属性が含まれていてはいけないことを示します。

$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \
--trustAll -s sub -b "cn=monitor" "(objectclass=*)" "1.1"
dn: cn=monitor
dn: cn=Client Connections,cn=monitor
dn: cn=ads-truststore Backend,cn=monitor
dn: cn=Network Groups,cn=monitor
dn: cn=internal,cn=Network Groups,cn=monitor
dn: cn=default,cn=Network Groups,cn=monitor
dn: cn=LDAP Connection Handler 0.0.0.0 port 1389 Statistics,cn=monitor
dn: cn=Administration Connector 0.0.0.0 port 4444,cn=monitor
dn: cn=Client Connections,cn=Administration Connector 0.0.0.0 port 4444,cn=monitor
dn: cn=backup Backend,cn=monitor
dn: cn=Version,cn=monitor
dn: cn=Work Queue,cn=monitor
dn: cn=System Information,cn=monitor
dn: cn=userRoot Database Environment,cn=monitor
dn: cn=tasks Backend,cn=monitor
dn: cn=adminRoot Backend,cn=monitor
dn: cn=userRoot Backend,cn=monitor
dn: cn=schema Backend,cn=monitor
dn: cn=LDAP Connection Handler 0.0.0.0 port 1389,cn=monitor
dn: cn=admin,cn=Network Groups,cn=monitor
dn: cn=Client Connections,cn=LDAP Connection Handler 0.0.0.0 port 1389,cn=monitor
dn: cn=JVM Memory Usage,cn=monitor
dn: cn=Administration Connector 0.0.0.0 port 4444 Statistics,cn=monitor
dn: cn=JVM Stack Trace,cn=monitor
dn: cn=Entry Caches,cn=monitor
dn: cn=monitor Backend,cn=monitor

29.5.1.3 汎用サーバー情報を監視するには

ldapsearchコマンドを"cn=monitor"のベースDNとともに使用します。

$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \
--trustAll -s base -b "cn=monitor" "(objectclass=*)"

出力は、次のようになります:

dn: cn=monitorstartTime: 20120110110156ZobjectClass: extensibleObjectobjectClass: topobjectClass: ds-monitor-entrycn: monitorvendorName: Oracle CorporationcurrentTime: 20120111082026ZvendorVersion: Oracle Unified Directory 11.1.2.0maxConnections: 1productName: Oracle Unified DirectorycurrentConnections: 1totalConnections: 8upTime: 57 days 21 hours 18 minutes 30 seconds

29.5.1.4 システム情報を監視するには

ldapsearchコマンドを"cn=System Information,cn=monitor"のベースDNとともに使用します。

$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \
--trustAll -s base -b "cn=System Information,cn=monitor" "(objectclass=*)"

構成に応じて、出力は次のようになります:

dn: cn=System Information,cn=monitor
instancePath: /local/asinst_2/OUD
javaVersion: 1.6.0_10
jvmArchitecture: 32-bit
jvmArguments: "-Dorg.opends.server.scriptName=start-ds"
jvmVersion: 11.0-b15
classPath: /local/instances/OUD/classes:
/local/asinst_2/OUD/resources/resources.jar:
/local/asinst_2/OUD/lib/activation.jar:
/local/asinst_2/OUD/lib/aspectjrt.jar:
/local/asinst_2/OUD/lib/je.jar:
/local/asinst_2/OUD/lib/mail.jar:
/local/asinst_2/OUD/lib/OUD_de.jar:
/local/asinst_2/OUD/lib/OUD_es.jar:
/local/asinst_2/OUD/lib/OUD_fr.jar:
/local/asinst_2/OUD/lib/OUD_ja.jar:
/local/asinst_2/OUD/lib/OUD.jar:
/local/asinst_2/OUD/lib/OUD_zh_CN.jar:
/local/asinst_2/OUD/lib/quicksetup.jar
usedMemory: 83361792
freeUsedMemory: 21020432
objectClass: extensibleObject
objectClass: top
objectClass: ds-monitor-entry
javaVendor: Oracle Corporation
operatingSystem: SunOS 5.11 x86
cn: System Information
systemName: llandudno
workingDirectory: /local/asinst_2/OUD/bin
maxMemory: 518717440
availableCPUs: 2
javaHome: /usr/jdk/instances/jdk1.6.0/jre
jvmVendor: Oracle Corporation

29.5.1.5 バージョン情報を監視するには

ldapsearchコマンドを"cn=Version,cn=monitor"のベースDNとともに使用します。

$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \
--trustAll -b "cn=Version,cn=Monitor" "(objectclass=*)"

出力は、次のようなものです:

dn: cn=Version,cn=monitor
shortName: OUD
labelNumber: 1112231410
objectClass: extensibleObject
objectClass: top
objectClass: ds-monitor-entry
cn: Version
pointVersion: 2
compactVersion: OUD-11.1
buildID: 20111224012512Z
majorVersion: 11
productName: Oracle Unified Directory
minorVersion: 1
versionQualifier: 0
fullVersion: Oracle Unified Directory 11.1.2.0

29.5.1.6 ユーザー・ルート・バックエンドを監視するには

userRootバックエンドは、データのバックエンド・データベース(JE環境)です。このモニターには、バックエンドの一般プロパティ(書込み可能性モード、ベースDN、バックエンドID、エントリ数などのプロパティ)が表示されます。

ldapsearchコマンドを"cn=userRoot Backend,cn=monitor"のベースDNとともに使用します。

$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \
--trustAll -s base -b "cn=userRoot Backend,cn=monitor" "(objectclass=*)"

構成に応じて、出力は次のようになります:

dn: cn=userRoot Backend,cn=monitor
objectClass: top
objectClass: ds-monitor-entry
objectClass: ds-backend-monitor-entry
ds-backend-is-private: FALSE
cn: userRoot Backend
ds-backend-writability-mode: enabled
ds-backend-entry-count: 2002
ds-backend-id: userRoot
ds-base-dn-entry-count: 2002 dc=example,dc=com
ds-backend-base-dn: dc=example,dc=com

29.5.1.7 バックアップ・バックエンドを監視するには

ldapsearchコマンドを"cn=backup Backend,cn=monitor"のベースDNとともに使用します。

$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \
--trustAll -s base -b "cn=backup Backend,cn=monitor" "(objectclass=*)"

構成に応じて、出力は次のようになります:

dn: cn=backup Backend,cn=monitor
objectClass: top
objectClass: ds-monitor-entry
objectClass: ds-backend-monitor-entry
ds-backend-is-private: TRUE
cn: backup Backend
ds-backend-writability-mode: disabled
ds-backend-entry-count: 1
ds-backend-id: backup
ds-base-dn-entry-count: 1 cn=backups
ds-backend-base-dn: cn=backups

29.5.1.8 タスク・バックエンドを監視するには

タスクは、ある将来の日付に処理または反復して処理を行うためにスケジュールできる管理機能(import-ldif、export-ldif、backup、restoreなど)です。このモニターには、タスクのバックエンドの一般プロパティ(書込み可能性モード、ベースDN、バックエンドID、エントリ数などのプロパティ)が表示されます。

ldapsearchコマンドを"cn=Tasks Backend,cn=monitor"のベースDNとともに使用します。

$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \
--trustAll -s base -b "cn=Tasks Backend,cn=monitor" "(objectclass=*)"

構成に応じて、出力は次のようになります:

dn: cn=tasks Backend,cn=monitor
objectClass: top
objectClass: ds-monitor-entry
objectClass: ds-backend-monitor-entry
ds-backend-is-private: TRUE
cn: tasks Backend
ds-backend-writability-mode: enabled
ds-backend-entry-count: 3
ds-backend-id: tasks
ds-base-dn-entry-count: 3 cn=tasks
ds-backend-base-dn: cn=tasks

29.5.1.9 monitorバックエンドを監視するには

このモニターには、バックエンドの一般プロパティ(書込み可能性モード、ベースDN、バックエンドID、エントリ数などのプロパティ)が表示されます。

ldapsearchコマンドを"cn=monitor Backend,cn=monitor"のベースDNとともに使用します。

$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \
--trustAll -s base -b "cn=monitor Backend,cn=monitor" "(objectclass=*)"

構成に応じて、出力は次のようになります:

dn: cn=monitor Backend,cn=monitor
objectClass: top
objectClass: ds-monitor-entry
objectClass: ds-backend-monitor-entry
ds-backend-is-private: TRUE
cn: monitor Backend
ds-backend-writability-mode: disabled
ds-backend-entry-count: 25
ds-backend-id: monitor
ds-base-dn-entry-count: 25 cn=monitor
ds-backend-base-dn: cn=monitor

29.5.1.10 スキーマ・バックエンドを監視するには

このモニターには、スキーマのバックエンドの一般プロパティ(書込み可能性モード、ベースDN、バックエンドID、エントリ数などのプロパティ)が表示されます。

ldapsearchコマンドを"cn=schema Backend,cn=monitor"のベースDNとともに使用します。

$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \
--trustAll -s base -b "cn=schema Backend,cn=monitor" "(objectclass=*)"

構成に応じて、出力は次のようになります:

dn: cn=schema Backend,cn=monitor
objectClass: top
objectClass: ds-monitor-entry
objectClass: ds-backend-monitor-entry
ds-backend-is-private: TRUE
cn: schema Backend
ds-backend-writability-mode: enabled
ds-backend-entry-count: 1
ds-backend-id: schema
ds-base-dn-entry-count: 1 cn=schema
ds-backend-base-dn: cn=schema

29.5.1.11 adminRootバックエンドを監視するには

このモニターには、adminRootバックエンドの一般プロパティ(書込み可能性モード、ベースDN、バックエンドID、エントリ数などのプロパティ)が表示されます。

ldapsearchコマンドを"cn=adminRoot Backend,cn=monitor"のベースDNとともに使用します。

$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \
--trustAll -s base -b "cn=adminRoot Backend,cn=monitor" "(objectclass=*)"

構成に応じて、出力は次のようになります:

dn: cn=adminRoot Backend,cn=monitor
objectClass: top
objectClass: ds-monitor-entry
objectClass: ds-backend-monitor-entry
ds-backend-is-private: TRUE
cn: adminRoot Backend
ds-backend-writability-mode: enabled
ds-backend-entry-count: 7
ds-backend-id: adminRoot
ds-base-dn-entry-count: 7 cn=admin data
ds-backend-base-dn: cn=admin data

29.5.1.12 ads-truststoreバックエンドを監視するには

ads-truststoreは、新規インスタンスがADSドメインの既存のサーバーに対して信頼を確立できるように、リモート管理ディレクトリ・サービス(ADS)のホストのADSキー・エントリのミラー(またはコピー)を保持します。このモニターには、バックエンドの一般プロパティ(書込み可能性モード、ベースDN、バックエンドID、エントリ数などのプロパティ)が表示されます。

ldapsearchコマンドを"cn=ads-truststore Backend,cn=monitor"のベースDNとともに使用します。

$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \
--trustAll -s base -b "cn=ads-truststore Backend,cn=monitor" "(objectclass=*)"

構成に応じて、出力は次のようになります:

dn: cn=ads-truststore Backend,cn=monitor
objectClass: top
objectClass: ds-monitor-entry
objectClass: ds-backend-monitor-entry
ds-backend-is-private: TRUE
cn: ads-truststore Backend
ds-backend-writability-mode: enabled
ds-backend-entry-count: 3
ds-backend-id: ads-truststore
ds-base-dn-entry-count: 3 cn=ads-truststore
ds-backend-base-dn: cn=ads-truststore

29.5.1.13 クライアント接続を監視するには

このモニターは、オープン状態のすべてのクライアント接続を表します。この内容は、LDAP接続ハンドラのオープン状態のクライアント接続のみを記述する"cn=Client Connections,cn=LDAP Connection Handler 0.0.0.0 port 1389,cn=monitor"のDNの内容とは異なります。

ldapsearchコマンドを"cn=Client Connections,cn=monitor"のベースDNとともに使用します。

$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \
--trustAll -s base -b "cn=Client Connections,cn=monitor" "(objectclass=*)"

構成に応じて、出力は次のようになります:

dn: cn=Client Connections,cn=monitor
connection: connID="11" connectTime="20090702125632Z" source="198.51.100.0:54044"
destination="198.51.100.23:1389" ldapVersion="3" authDN="cn=Directory Manager,cn=Root DNs,
cn=config" security="none" opsInProgress="1"
cn: Client Connections
objectClass: extensibleObject
objectClass: top
objectClass: ds-monitor-entry

29.5.1.14 LDAP接続ハンドラを監視するには

LDAP接続ハンドラは、LDAPを介してクライアントと対話するために使用されます。

ldapsearchコマンドを"cn=LDAP Connection Handler 0.0.0.0 port port-number,cn=monitor"のベースDNとともに使用します。

$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \
--trustAll -s base \
-b "cn=LDAP Connection Handler 0.0.0.0 port 1389,cn=monitor" \
"(objectclass=*)"

構成に応じて、出力は次のようになります:

dn: cn=LDAP Connection Handler 0.0.0.0 port 1389,cn=monitor
ds-connectionhandler-listener: 0.0.0.0:1389
ds-connectionhandler-num-connections: 1
ds-connectionhandler-protocol: LDAP
objectClass: top
objectClass: ds-monitor-entry
objectClass: ds-connectionhandler-monitor-entry
ds-mon-config-dn: cn=ldap connection handler,cn=connection handlers,cn=config
cn: LDAP Connection Handler 0.0.0.0 port 1389
ds-connectionhandler-connection: connID="22" connectTime="20120302133936Z"
source="198.51.100.0:39574" destination="198.51.100.23:1389" ldapVersion="3"
authDN="cn=Directory Manager,cn=Root DNs,cn=config" security="none" opsInProgress="1"

29.5.1.15 LDAP接続ハンドラの統計を監視するには

ldapsearchコマンドを"cn=LDAP Connection Handler 0.0.0.0 port port-number Statistics,cn=monitor"のベースDNとともに使用します。

$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \
--trustAll -s base \
-b "cn=LDAP Connection Handler 0.0.0.0 port 1389 Statistics,cn=monitor" \
"(objectclass=*)"

構成に応じて、出力は次のようになります:

dn: cn=LDAP Connection Handler 0.0.0.0 port 1389 Statistics,cn=monitor
objectClass: ds-monitor-entry
objectClass: top
objectClass: extensibleObject
operationsCompleted: 37
compareRequests: 0
bytesWritten: 99488
extendedRequests: 0
addRequests: 0
bindRequests: 19
...(more output)

29.5.1.16 LDAP接続ハンドラの接続を監視するには

このモニターは、LDAP接続ハンドラのオープン状態のクライアント接続を表します。

ldapsearchコマンドを"cn=Client Connections,cn=LDAP Connection Handler 0.0.0.0 port port-number,cn=monitor"のベースDNとともに使用します。

$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file \
--useSSL --trustAll \
-b "cn=Client Connections,cn=LDAP Connection Handler 0.0.0.0 port 1389 \
cn=monitor" \
"(objectclass=*)"

構成に応じて、出力は次のようになります:

dn: cn=Client Connections,cn=LDAP Connection Handler 0.0.0.0 port 1389,cn=monitor
connection: connID="0" connectTime="20090706084747Z" source="198.51.100.0:57523" destination="198.51.100.0:1389" ldapVersion="3" authDN="" security="none" opsInProgress="0"
connection: connID="1" connectTime="20090706084747Z" source="198.51.100.0:57524" destination="198.51.100.0:1389" ldapVersion="3" authDN="" security="none" opsInProgress="0"
connection: connID="2" connectTime="20090706084747Z" source="198.51.100.0:57525" destination="198.51.100.0:1389" ldapVersion="3" authDN="" security="none" opsInProgress="0"
connection: connID="3" connectTime="20090706084747Z" source="198.51.100.0:57526" destination="198.51.100.0:1389" ldapVersion="3" authDN="" security="none" opsInProgress="0"
connection: connID="4" connectTime="20090706084747Z" source="198.51.100.0:57527" destination="198.51.100.0:1389" ldapVersion="3" authDN="" security="none" opsInProgress="0"

29.5.1.17 管理コネクタを監視するには

このモニターは、管理コネクタの基本情報を提供します。詳細は、第14.3項「サーバーへの管理トラフィックの管理」を参照してください。

ldapsearchコマンドを"cn=Administration Connector 0.0.0.0 port admin-port-number,cn=monitor"のベースDNとともに使用します。

$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \
--trustAll -b "cn=Administration Connector 0.0.0.0 port 4444,cn=monitor" \
"(objectclass=*)"

構成に応じて、出力は次のようになります:

objectClass: top
objectClass: ds-monitor-entry
objectClass: ds-connectionhandler-monitor-entry
dn: cn=Administration Connector 0.0.0.0 port 4444,cn=monitor
ds-connectionhandler-listener: 0.0.0.0:4444
ds-connectionhandler-num-connections: 0
ds-connectionhandler-protocol: LDAPS
cn: Administration Connector 0.0.0.0 port 4444
ds-mon-config-dn: cn=administration connector,cn=config

29.5.1.18 管理コネクタ統計を監視するには

このモニターは、管理コネクタを介して実行される操作に関する広範な統計情報を提供します。詳細は、第14.3項「サーバーへの管理トラフィックの管理」を参照してください。

ldapsearchコマンドを"cn=Administration Connector 0.0.0.0 port admin-port-number Statistics,cn=monitor"のベースDNとともに使用します。

$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \
--trustAll \
-b "cn=Administration Connector 0.0.0.0 port 4444 Statistics,cn=monitor" \
"(objectclass=*)"

構成に応じて、出力は次のようになります:

dn: cn=Administration Connector 0.0.0.0 port 4444 Statistics,cn=monitor
compareResponses: 0
connectionsClosed: 1
searchResultsDone: 4
ds-mon-resident-time-mod-operations-total-time: 92257568
extendedResponses: 0
bindRequests: 2
operationsAbandoned: 0
bytesWritten: 45056
addResponses: 0
addRequests: 0
ds-mon-resident-time-moddn-operations-total-time: 0
ds-mon-extended-operations-total-count: 0
ds-mon-moddn-operations-total-count: 0
modifyResponses: 1
operationsCompleted: 7
...(more output)...

29.5.1.19 管理コネクタの接続を監視するには

このモニターは、管理コネクタのオープン状態のクライアント接続を表します。

ldapsearchコマンドを"cn=Client Connections,cn=Administration Connector 0.0.0.0 port port-number,cn=monitor"のベースDNとともに使用します。

$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file \
--useSSL --trustAll \
-b "cn=Client Connections,cn=Administration Connector 0.0.0.0 \
port 4444,cn=monitor" \
"(objectclass=*)"

構成に応じて、出力は次のようになります:

objectClass: top
objectClass: ds-monitor-entry
objectClass: extensibleObject
dn: cn=Client Connections,cn=Administration Connector 0.0.0.0 port 4444,cn=monitor
connection: connID="339" connectTime="20120307075218Z" source="198.51.100.0:48213"
destination="198.51.100.0:4444" ldapVersion="3" authDN="" security="TLS"
opsInProgress="1"
cn: Client Connections

29.5.1.20 LDIF接続ハンドラを監視するには

LDIF接続ハンドラは、内部操作を使用してLDIFファイルから読み取られる変更を処理するために使用されます。LDIF接続ハンドラの情報の監視は、接続ハンドラが有効になっている場合のみ使用できます。

ldapsearchコマンドを"cn=LDIF Connection Handler,cn=monitor"のベースDNとともに使用します。

$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \
--trustAll -s base -b "cn=LDIF Connection Handler,cn=monitor" "(objectclass=*)"

構成に応じて、出力は次のようになります:

objectClass: top
objectClass: ds-monitor-entry
objectClass: ds-connectionhandler-monitor-entry
dn: cn=LDIF Connection Handler,cn=monitor
ds-connectionhandler-num-connections: 0
ds-connectionhandler-protocol: LDIF
ds-mon-config-dn: cn=ldif connection handler,cn=connection handlers,cn=config
cn: LDIF Connection Handler

29.5.1.21 ワーク・キューを監視するには

ワーク・キューは、未処理のクライアント・リクエストを追跡し、これらが確実に処理されるようにします。

ldapsearchコマンドを"cn=Work Queue,cn=monitor"のベースDNとともに使用します。

$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \
--trustAll -s base -b "cn=Work Queue,cn=monitor" "(objectclass=*)"

構成に応じて、出力は次のようになります:

dn: cn=Work Queue,cn=monitor
currentRequestBacklog: 0
objectClass: extensibleObject
objectClass: top
objectClass: ds-monitor-entry
requestsSubmitted: 25
cn: Work Queue
maxRequestBacklog: 0
averageRequestBacklog: 0
requestsRejectedDueToQueueFull: 0

29.5.1.22 JVMスタック・トレース情報を監視するには

ディレクトリ・サーバー・インスタンスのJVMスタック・トレース情報にアクセスできます。このリソース・モニターは、org.opends.server.monitors.StackTraceMonitorProviderクラスに実装され、カスタム構成を必要としません。

ldapsearchコマンドを"cn=JVM Stack Trace,cn=monitor"のベースDNとともに使用します。

$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \
--trustAll -s base -b "cn=JVM Stack Trace,cn=monitor" "(objectclass=*)"

構成に応じて、出力の先頭は次のようになります:

dn: cn=JVM Stack Trace,cn=monitor
cn: JVM Stack Trace
jvmThread: id=2 ---------- Reference Handler ----------
jvmThread: id=2 frame[0]=java.lang.Object.wait(Object.java:native)
jvmThread: id=2 frame[1]=java.lang.Object.wait(Object.java:485)
jvmThread: id=2 frame[2]=java.lang.ref.Reference$ReferenceHandler.run(Reference.
java:116)
jvmThread: id=3 ---------- Finalizer ----------
jvmThread: id=3 frame[0]=java.lang.Object.wait(Object.java:native)
jvmThread: id=3 frame[1]=java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java
:116)
jvmThread: id=3 frame[2]=java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java
:132)
jvmThread: id=3 frame[3]=java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.j
ava:159)
jvmThread: id=4 ---------- Signal Dispatcher ----------
jvmThread: id=10 ---------- Time Thread ----------
jvmThread: id=10 frame[0]=sun.misc.Unsafe.park(Unsafe.java:native)
jvmThread: id=10 frame[1]=java.util.concurrent.locks.LockSupport.parkNanos(LockS
upport.java:198)
...(more output)...

29.5.1.23 JVMメモリー使用量を監視するには

ldapsearchコマンドを"cn=JVM Memory Usage,cn=monitor"のベースDNとともに使用します。

$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \
--trustAll -s base -b "cn=JVM Memory Usage,cn=monitor" "(objectclass=*)"

構成に応じて、出力は次のようになります:

dn: cn=JVM Memory Usage,cn=monitor
ps-eden-space-bytes-used-after-last-collection: 0
ps-mark-sweep-total-collection-count: 0
code-cache-bytes-used-after-last-collection: 0
ps-old-gen-current-bytes-used: 25260472
ps-perm-gen-bytes-used-after-last-collection: 0
ps-scavenge-recent-collection-duration: 3
ps-scavenge-total-collection-count: 17
ps-eden-space-current-bytes-used: 32001992
ps-perm-gen-current-bytes-used: 21179960
ps-old-gen-bytes-used-after-last-collection: 0
ps-mark-sweep-total-collection-duration: 0
ps-mark-sweep-average-collection-duration: 0
ps-scavenge-average-collection-duration: 26
ps-scavenge-total-collection-duration: 443
objectClass: extensibleObject
objectClass: top
objectClass: ds-monitor-entry
ps-mark-sweep-recent-collection-duration: 0
ps-survivor-space-bytes-used-after-last-collection: 622592
cn: JVM Memory Usage
code-cache-current-bytes-used: 2143680
ps-survivor-space-current-bytes-used: 622592

29.5.1.24 userRootデータベース環境を監視するには

userRootデータベース環境は、Berkeley DB Java Editionのバックエンドを利用します。JE監視データ(cn=*Database Environment,cn=monitorの下のデータ)は、短期間のみ信頼できます。サーバー・アクティビティが多い間(たとえば、カウンタに応じて1時間から数日)、このデータはオーバーフローする可能性があります。このような場合、JE監視データは、負の値または正の値だが正しくない値を示す可能性があります。これは既知の問題で、Berkeley DB Java Editionの次の主要なリリースで修正される予定です。Oracle SR番号15979と15985がこの問題に対応しています。

ldapsearchコマンドを"cn=userRoot Database Environment,cn=monitor"のベースDNとともに使用します。

$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \
--trustAll -s base -b "cn=userRoot Database Environment,cn=monitor" \
"(objectclass=*)"
dn: cn=userRoot Database Environment,cn=monitor

構成に応じて、出力は次のようになります:

EnvironmentNTempBufferWrites: 0
EnvironmentNNodesExplicitlyEvicted: 0
EnvironmentCleanerBacklog: 0
EnvironmentTotalLogSize: 5386067
EnvironmentLockBytes: 2000
EnvironmentNFullBINFlush: 2
EnvironmentNBINsStripped: 0
EnvironmentLastCheckpointEnd: 5385359
TransactionNCommits: 24
EnvironmentNCleanerEntriesRead: 0
EnvironmentNRepeatFaultReads: 2
TransactionNXACommits: 0
EnvironmentNClusterLNsProcessed: 0
TransactionNBegins: 24
LockNOwners: 25
...(more output)...

29.5.1.25 データベース・キャッシュを監視するには

データベース(DB)キャッシュは、Java Editionノードを格納するために使用されます。DBキャッシュは、ディレクトリ・サーバーのパフォーマンス全体の重要なコンポーネントです。DBキャッシュを注意深くチューニングして監視してください。DBキャッシュには、次のノードが含まれています:

- 上位ノード

- 内部ノード

- リーフ・ノード

上位ノードおよび内部ノードは内部Bツリー構造を表し、リーフ・ノードはユーザー・エントリを表します。可能な最高のパフォーマンスを得るためには、すべてのDBキャッシュ・ノードをDBキャッシュに配置することをお薦めします。DBキャッシュに少なくともBツリー内部構造(上位ノードおよび内部ノード)を含むようにDBキャッシュをサイズ設定することをお薦めします。DBキャッシュが短すぎると、多くの失敗および頻繁な削除が発生し、このことがディレクトリ・サーバーのパフォーマンスに悪影響する可能性があります。

キャッシュのサイズのチューニングは次の方法で行います:

- dbcache-percentの設定

- OUD JVMヒープ(特に古いもの)の適切なサイズ設定。

DBキャッシュの監視は、ldapsearchコマンドをcn=userRoot Database Environment,cn=monitorのベースDNとともに使用して行うことができます:

$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \
--trustAll -s base -b "cn=userRoot Database Environment,cn=monitor" \
"(objectclass=*)"
dn: cn=userRoot Database Environment,cn=monitor

構成に応じて、出力は次のようになります:

EnvironmentNTempBufferWrites: 0
EnvironmentNNodesExplicitlyEvicted: 0
EnvironmentCleanerBacklog: 0
EnvironmentTotalLogSize: 5386067
EnvironmentLockBytes: 2000
EnvironmentNFullBINFlush: 2
EnvironmentNBINsStripped: 0
EnvironmentLastCheckpointEnd: 5385359
TransactionNCommits: 24
EnvironmentNCleanerEntriesRead: 0
EnvironmentNRepeatFaultReads: 2
TransactionNXACommits: 0
EnvironmentNClusterLNsProcessed: 0
TransactionNBegins: 24
LockNOwners: 25
...(more output)...

次のDBキャッシュ成功と失敗カウンタを以下に説明します:

カウンタ

説明

EnvironmentNUpperINsFetch

キャッシュからフェッチされた上位内部ノードの蓄積数。

EnvironmentNUpperINsFetchMiss

失敗した上位内部ノードの蓄積数。

EnvironmentNBINsFetch

キャッシュからフェッチされた下位内部ノードの蓄積数。

EnvironmentNBINsFetchMiss

失敗した上位内部ノードの蓄積数。

EnvironmentNLNsFetch

キャッシュからフェッチされたリーフ・ノードの蓄積数。

EnvironmentNLNsFetchMiss

失敗したリーフ・ノードの蓄積数。

OUDのパフォーマンスを良好にするには、DBキャッシュ内にすべてのノードを配置するか、または少なくともDBキャッシュ内にすべての内部ノードを配置することをお薦めします。

cn=monitorの値は蓄積されるため、定期的(たとえば1分おき)にデルタを計算し、経時的にデルタの増加を監視することが重要です。次のものを更新する必要があります:

DeltaNUpperINsMiss=EnvironmentNUpperINsFetchMiss - EnvironmentNUpperINsFetchMissPrev
DeltaNUpperINsFetch=EnvironmentNUpperINsFetch - EnvironmentNUpperINsFetchPrev
DeltaBINsMiss=EnvironmentNBINsFetchMiss - EnvironmentNBINsFetchMissPrev
DeltaBINsFetch=EnvironmentNBINsFetch - EnvironmentNBINsFetchPrev
DeltaNLNsMiss=EnvironmentNLNsFetchMiss - EnvironmentNLNsFetchMissPrev
DeltaNLNsFetch=EnvironmentNLNsFetch - EnvironmentNLNsFetchPrev

最小レベルのパフォーマンスでOracle Unified Directoryを実行できます。以下に示すように、Bツリー構造をDBキャッシュ内に配置することをお薦めします:

((DeltaNUpperINsMiss/DeltaNUpperINsFetch)*100) as close to 0 as possible
((DeltaNBINsMiss/DeltaNBINsFetch)*100) as close to 0 as possible (< 5% remains acceptable)

可能な最高のパフォーマンスを得るためには、OUDがユーザー・エントリもDBキャッシュ内に配置することをお薦めします。たとえば、次のようにします:

((DeltaNLNsMiss/DeltaNLNsFetch)*100) できるかぎり0に近づけます。

インポート完了後(およびデータ準備後)デルタ比を0に近づけて開始し、時間の経過とともにデルタ比は、データベースのサイズの増加(レプリケーション・メタデータのbc、最小利用のクリアのインパクト、エントリ(新規アプリケーション)の増大、およびエントリ数)によって大きくなります。このため、(カスタム・スクリプトまたはUIを介して)DBキャッシュを監視し、適切なアクション(DBキャッシュのパーセントまたはOUD JVMヒープの増大など)を行うことをお薦めします。

29.5.1.26 エントリ・キャッシュを監視するには

cn=Entry Caches,cn=Monitorエントリにアクセスすることによって、ディレクトリ・サーバー・インスタンスの蓄積状態のすべてのアクティブ・エントリ・キャッシュにアクセスできます。エントリ・キャッシュ・インスタンスがディレクトリ・サーバー構成で有効になっている場合、サーバーは特定のインスタンスの「キャッシュごと」の監視データもリクエストできます:

- cn=FIFO Entry Cache,cn=Monitor

- cn=Soft Reference Entry Cache,cn=Monitor

- cn=File System Entry Cache,cn=Monitor

また、任意の名前を付けられたアクティブ・エントリ・キャッシュ・インスタンス(たとえば、cn=Any Arbitrary Name Entry Cache,cn=Monitor)は、そのインスタンス名でアクセスできるモニターを提供する必要があります。

ldapsearchコマンドを"cn=Entry Caches,cn=monitor"のベースDNとともに使用します。

$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \
--trustAll -s base -b "cn=Entry Caches,cn=monitor" "(objectclass=*)"

構成に応じて、出力は次のようになります:

dn: cn=Entry Caches,cn=monitor
entryCacheHits: 0
entryCacheTries: 0
currentEntryCacheCount: 0
objectClass: extensibleObject
objectClass: top
objectClass: ds-monitor-entry
entryCacheHitRatio: 0
cn: Entry Caches
...

29.5.1.27 ネットワーク・グループを監視するには

ldapsearchコマンドを"cn=Network Groups,cn=monitor"のベースDNとともに使用します。

$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file \
--useSSL --trustAll -b "cn=Network Groups,cn=monitor" "(objectclass=*)"

構成に応じて、出力は次のようになります:

objectClass: top
objectClass: ds-monitor-entry
objectClass: ds-mon-branch
dn: cn=Network Groups,cn=monitor
dn: cn=admin,cn=Network Groups,cn=monitor
ds-mon-compare-operations-total-count: 0
ds-mon-failed-referrals-total-count: 15
ds-mon-unbind-operations-total-count: 13
ds-mon-followed-referrals-total-count: 34
ds-mon-violations-schema-total-count: Not implemented
ds-mon-bind-operations-total-count: 98
ds-mon-persistent-searchs-count: Not implemented
ds-mon-add-operations-total-count: 37
ds-mon-abandon-operations-total-count: 0
ds-mon-moddn-operations-total-count: 0
ds-mon-extended-operations-total-count: 0
ds-mon-searchsubtree-operations-total-count: 310
objectClass: top
objectClass: ds-monitor-entry
objectClass: extensibleObject
ds-mon-discarded-referrals-total-count: Not implemented
ds-mon-mod-operations-total-count: 1
ds-mon-forwarded-referrals-total-count: Not implemented
cn: admin
ds-mon-searchonelevel-operations-total-count: 92966
ds-mon-delete-operations-total-count: 0

dn: cn=default,cn=Network Groups,cn=monitor
...

29.5.1.28 分散を監視するには

ldapsearchコマンドを"cn=Distribution,cn=monitor"のベースDNとともに使用します。

$ ldapsearch -h localhost -p 4444 -D "cn=directory manager" -j pwd-file \
--useSSL --trustAll -b "cn=Distribution,cn=monitor" "(objectclass=*)"

構成に応じて、出力は次のようになります:

objectClass: top
objectClass: ds-monitor-entry
objectClass: ds-mon-branch
dn: cn=distribution,cn=monitor

cn: distrib-we
ds-mon-searchonelevel-operations-total-count: 0
ds-mon-residenttime-bind-operations-max-time: 0
...

ds-mon-delete-operations-total-count: 0

dn: cn=algorithm,cn=distrib-we,cn=distribution,cn=monitor
ds-mon-residenttime-total-time: 0
ds-mon-residenttime-max-time: 0
cn: algorithm
ds-mon-runs-total-count: 0
ds-mon-residenttime-min-time: 0
objectClass: top
objectClass: ds-monitor-entry
objectClass: extensibleObject

dn: cn=partitions,cn=algorithm,cn=distrib-we,cn=distribution,cn=monitor
objectClass: top
objectClass: ds-monitor-entry
objectClass: ds-mon-branch

dn: cn=distrib-part1,cn=partitions,cn=algorithm,cn=distrib-we,cn=distribution,cn
=monitor
...
objectClass: top
objectClass: ds-monitor-entry
objectClass: extensibleObject
ds-mon-modify-operations-total-count: 0
cn: distrib-part1
ds-mon-searchonelevel-operations-total-count: 0
ds-mon-delete-operations-total-count: 0

dn: cn=distrib-part2,cn=partitions,cn=algorithm,cn=distrib-we,cn=distribution,cn
=monitor

...

29.5.1.29 ロード・バランシングを監視するには

ldapsearchコマンドを"cn=load balancing,cn=monitor"のベースDNとともに使用します。

$ ldapsearch -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file \
--useSSL --trustAll -b "cn=load balancing,cn=monitor" "(objectclass=*)"

構成に応じて、出力は次のようになります:

objectClass: top
objectClass: ds-monitor-entry
objectClass: ds-mon-branch
dn: cn=load balancing,cn=monitor
dn: cn=load-bal-we1,cn=load balancing,cn=monitor
ds-mon-aborted-add-operations-total-count: 0
...
dn: cn=algorithm,cn=load-bal-we1,cn=load balancing,cn=monitor

dn: cn=routes,cn=algorithm,cn=load-bal-we1,cn=load balancing,cn=monitor
...
dn: cn=load-bal-route1,cn=routes,cn=algorithm,cn=load-bal-we1,cn=load balancing,cn=monitor
...
dn: cn=load-bal-we2,cn=load balancing,cn=monitor
...
dn: cn=algorithm,cn=load-bal-we2,cn=load balancing,cn=monitor
...
dn: cn=routes,cn=algorithm,cn=load-bal-we2,cn=load balancing,cn=monitor

dn: cn=load-bal-route1,cn=routes,cn=algorithm,cn=load-bal-we2,cn=load balancing,cn=monitor
...
cn: load-bal-route1

dn: cn=load-bal-route2,cn=routes,cn=algorithm,cn=load-bal-we1,cn=load balancing,cn=monitor
...
cn: load-bal-route2

dn: cn=load-bal-route2,cn=routes,cn=algorithm,cn=load-bal-we2,cn=load balancing,cn=monitor

cn: load-bal-route2
ds-mon-searchonelevel-operations-total-count: 9
ds-mon-delete-operations-total-count: 0

29.5.1.30 リモートLDAPサーバーを監視するには

ldapsearchコマンドを"cn=LDAP Servers,cn=monitor"のベースDNとともに使用します。

$ ldapsearch -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file \
--useSSL --trustAll -b "cn=LDAP Servers,cn=monitor" "(objectclass=*)"

構成に応じて、出力は次のようになります:

objectClass: top
objectClass: ds-monitor-entry
objectClass: ds-mon-branch
dn: cn=LDAP Servers,cn=monitor

dn: cn=proxy1,cn=LDAP Servers,cn=monitor
ds-mon-aborted-add-operations-total-count: 0
...
cn: proxy1
ds-mon-searchonelevel-operations-total-count: 0
...
objectClass: top
objectClass: ds-monitor-entry
objectClass: extensibleObject

dn: cn=proxy2,cn=LDAP Servers,cn=monitor
ds-mon-aborted-add-operations-total-count: 0
...
cn: proxy2
ds-mon-searchonelevel-operations-total-count: 0
...
objectClass: top
objectClass: ds-monitor-entry
objectClass: extensibleObject
...
dn: cn=proxy3,cn=LDAP Servers,cn=monitor
...
cn: proxy3
ds-mon-searchonelevel-operations-total-count: 0
...
objectClass: top
objectClass: ds-monitor-entry
objectClass: extensibleObject
...
dn: cn=proxy4,cn=LDAP Servers,cn=monitor
...
cn: proxy4
...
objectClass: top
objectClass: ds-monitor-entry
objectClass: extensibleObject

29.5.1.31 グローバル索引を監視するには

ldapsearchコマンドを"cn=givenname,cn=gi-catalog,cn=Global Index Catalogs,cn=monitor"のベースDNとともに使用します。

givennameが索引化された属性の名前に対応し(たとえば、cnを索引化した場合、cn)、gi-catalogがグローバル索引カタログの名前に対応するようにします。

$ ldapsearch -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file --useSSL \
--trustAll -b "cn=givenname,cn=gi-catalog,cn=Global Index Catalogs,cn=monitor"
"(objectclass=*)"

構成に応じて、出力は次のようになります:

dn: cn=givenname,cn=gi-catalog,cn=Global Index Catalogs,cn=monitor
ds-mon-add-operations-min-time: 0
ds-mon-add-operations-aborted-count: 0
ds-mon-lookup-operations-min-time: 0
ds-mon-getpartitions-operations-total-count: 0
ds-mon-add-operations-max-time: 0
ds-mon-lookup-operations-total-count: 0
ds-mon-memorized-remove-operations-count: 0
ds-mon-remove-operations-aborted-count: 0
ds-mon-add-operations-total-time: 0
ds-mon-getpartitions-operations-aborted-count: 0
ds-mon-lookup-operations-total-time: 0
ds-mon-index-entries: 0
ds-mon-remove-operations-failed-count: 0
ds-mon-getpartitions-operations-min-time: 0
ds-mon-lookup-operations-max-time: 0
ds-mon-getpartitions-operations-average-time: 0
ds-mon-index-creation-date: 1252483187019
ds-mon-getpartitions-operations-last-access-date: 0
ds-mon-remove-operations-total-count: 0
ds-mon-lookup-operations-failed-count: 0
ds-mon-add-operations-failed-count: 0
ds-mon-remove-operations-min-time: 0
ds-mon-add-operations-average-time: 0
ds-mon-lookup-operations-aborted-count: 0
ds-mon-getpartitions-operations-total-time: 0
ds-mon-remove-operations-max-time: 0
ds-mon-getpartitions-operations-max-time: 0
ds-mon-lookup-operations-last-access-date: 0
ds-mon-add-operations-total-count: 0
ds-mon-remove-operations-total-time: 0
ds-mon-remove-operations-average-time: 0
ds-mon-getpartitions-operations-failed-count: 0
objectClass: ds-monitor-entry
objectClass: top
objectClass: extensibleObject
ds-mon-lookup-operations-average-time: 0
ds-mon-remove-operations-last-access-date: 0
cn: givenname
ds-mon-add-operations-last-access-date: 0

29.5.1.32 グローバル索引カタログを監視するには

ldapsearchコマンドを"cn=gi-catalog,cn=Global Index Catalogs,cn=monitor"のベースDNとともに使用します。

givennameが索引化された属性の名前に対応し(たとえば、cnを索引化した場合cn)、gi-catalogがグローバル索引カタログの名前に対応するようにします。

$ ldapsearch -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file --useSSL \
--trustAll -b "cn=gi-catalog,cn=Global Index Catalogs,cn=monitor" \
"(objectclass=*)"

構成に応じて、出力は次のようになります:

dn: cn=gi-catalog,cn=Global Index Catalogs,cn=monitor
ds-mon-replication-received-update-message-errors: 0
ds-mon-configured-index-number: 1
ds-mon-replication-full-update-pending-attribute:
ds-mon-replication-full-update-status: NONE
ds-mon-state: RUNNING_STANDALONE
ds-mon-replication-published-update-message-number: 0
ds-mon-replication-active: false
ds-mon-replication-auto-sync-retries: 0
ds-mon-replication-published-update-message-errors: 0
ds-mon-replication-full-update-errors: 0
ds-mon-replication-received-update-message-number: 0
ds-mon-replication-auto-sync-is-running: false
objectClass: ds-monitor-entry
objectClass: top
objectClass: extensibleObject
ds-mon-replication-configured: false
cn: gi-catalog

29.5.2 manage-tasksコマンドを使用した監視

Oracle Unified Directoryは、特定のタスク(import-ldif、export-ldif、backup、restoreなど)をスケジュールして処理するメカニズムを提供するタスク・バックエンドを提供します。タスクをスケジュールして、反復期間の特定の時刻に実行できます。スケジュール済のタスクを監視するには、manage-tasksコマンドを使用します。詳細は、第14.4項「タスクとしてのコマンドの構成」を参照してください。

29.5.3 JConsoleを使用したサーバーの監視

JConsole (jconsole) Javaユーティリティは、管理エージェントを使用して起動された実行中のJava仮想マシンに接続しているJMX準拠のグラフィカル・ツールです。この汎用ツールは、サーバー監視情報にアクセスするために使用できます。

29.5.3.1 サーバー・インスタンス上でJMXを構成するには

1. サーバーを起動します。

2. JMX接続ハンドラを有効にし、JMXで使用するポート番号を設定します。
未使用かつサーバーを実行しているユーザーがアクセス権を持っているポートを選択します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
set-connection-handler-prop --handler-name "JMX Connection Handler" \
--set enabled:true --set listen-port:1689

3. JMXの読取り、書込みおよび通知の権限をルートDNに追加します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
set-root-dn-prop \
--add default-root-privilege-name:jmx-read \
--add default-root-privilege-name:jmx-write \
--add default-root-privilege-name:jmx-notify

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

29.5.3.2 JConsoleの起動

端末ウィンドウでjconsoleと入力してコンソールを起動します。

コマンドラインからjconsoleを実行するには、JAVA_HOME/binをパスに追加する必要がある場合があります。ここで、JAVA_HOMEはJDKを含むディレクトリです。または、コマンドを入力するときにフルパスを入力することもできます。

JConsoleの使用の詳細は、「JConsoleの使用」(http://download.oracle.com/docs/cd/E17409_01/javase/6/docs/technotes/guides/management/jconsole.html)を参照してください。

29.5.3.3 JConsoleからのサーバー・インスタンスへのアクセス

JConsoleをサーバー・インスタンスに接続するには、リモート・プロセス・フィールドを使用します。次のフィールドが必要です:

- JMX URL:
service:jmx:rmi:///jndi/rmi://''host'':''port''/org.opends.server.protocols.jmx.client-unknown

- hostは、ホスト名、IPv4数値ホスト・アドレスまたは角括弧で囲まれたIPv6数値アドレスです。

- portは、JMXコネクタの10進数のポート番号です。(第29.4項「アラートおよびアカウント・ステータス通知ハンドラの構成」を参照)。

デフォルトのJMX URLは次のとおりです:

service:jmx:rmi:///jndi/rmi://198.51.100.0:1689/org.opends.server.protocols.jmx.client-unknown

- ユーザー名。有効なLDAPユーザー名です。
デフォルトのディレクトリ・マネージャのユーザー名はcn=Directory Managerです。

- パスワード。ユーザーのLDAPパスワードです。

29.5.3.4 JConsoleを使用した監視情報の表示

JConsoleがサーバー・インスタンスに接続されている場合、これは管理オブジェクト(MBean)を表示します。左側のペインのツリーは、現在使用可能なすべてのMBeanを示しています。関連するMBeanを選択することによって、右側のペインでサーバー監視情報にアクセスできます。

次の図は、サーバーcn=LDAP Connection Handler 0.0.0.0 port 1389 Statistics,cn=monitorの属性リストを示しています。

図29-1 Java監視と管理コンソール

29.5.4 ログへのアクセス

サーバーには、サーバー・インスタンスのアクセス、エラーまたはデバッグの情報を記録するロギング・メカニズムがあります。指定されたタイプの複数のロガーをいつでもアクティブにできるため、特定のサブツリーまたは異なるリポジトリのログを作成できます。サーバーは、ログの情報のタイプを制限するロギング・フィルタを現在提供していません。

次のログが用意されています:

- アクセス・ログ。アクセス・ログには、ディレクトリ・サーバーによって処理された操作のタイプに関する情報が記録されます。アクセス・ログはデフォルトで提供されます。

- 監査ログ。監査ログは、アクセス・ログの一種で、ディレクトリ・サーバー上のすべてのアクティビティを記録します。監査ログは、デフォルトでは有効になっていません。

- デバッグ・ログ。デバッグ・ログは、ディレクトリ・サーバーの問題のトラブルシューティングまたはディレクトリ・サーバーの処理に関する詳細情報の提供に使用できる情報を記録します。デバッグ・ログは、デフォルトでは有効になっていません。

- エラー・ログ。エラー・ログは、ディレクトリ・サーバーの処理中に発生したすべての警告、エラーまたは重大なイベントを記録します。

- レプリケーション修復ログ。レプリケーション修復ログは、トポロジの単一のディレクトリ・サーバーの非一貫性を記録します。
レプリケーション修復ログは読取り専用であり、レプリケーションの競合解決を有効にする場合のみ使用できます。

- OUD設定ログ。この設定ログは、Oracle Unified Directoryのプロキシ・サーバー・インスタンスまたはレプリケーション・ゲートウェイ・インスタンスのインストール中に実行した同等のコマンドライン引数を記録します。これによって、以前のインストールに基づいて、プロキシ・サーバーまたはゲートウェイ・サーバーの「サイレント・インストール」を実行できます。
このファイルは、ディレクトリ・サーバー・インスタンスの出力ではありません。

- server.outログ。server.outログは、ブートストラップ構成プロセスを記録し、jarファイルからロードされた拡張子をリストし、接続およびアラートの通知アクティビティを示します。

29.5.4.1 アクセス・ログを表示するには

1. サーバー・インスタンスのログ・ディレクトリに変更します。

$ cd INSTANCE_DIR/OUD/logs

2. テキスト・エディタまたはUNIXのcatコマンドを使用して、accessファイルを開きます。

$ cat access | more
[10/Jan/2012:12:02:11 +0100] CONNECT conn=0 from=198.51.100.0:55416 to=198.51.100.0:5444 protocol=LDAPS
[10/Jan/2012:12:02:12 +0100] BIND REQ conn=0 op=0 msgID=1 type=SIMPLE dn="cn=Directory Manager"
[10/Jan/2012:12:02:12 +0100] BIND RES conn=0 op=0 msgID=1 result=0 authDN="cn=Directory Manager,cn=Root
DNs,cn=config" etime=36
[10/Jan/2012:12:02:12 +0100] UNBIND REQ conn=0 op=1 msgID=2
[10/Jan/2012:12:02:12 +0100] DISCONNECT conn=0 reason="Client Disconnect"
...(more output)...

29.5.4.2 監査ログを表示するには

1. 監査ログのパブリッシャが有効になっていない場合、第29.3.1.1.2項「ログ・パブリッシャを有効にするには」の説明に従ってこれを有効にします。

2. サーバー・インスタンスのログ・ディレクトリに変更します。

$ cd INSTANCE_DIR/OUD/logs

3. テキスト・エディタまたはUNIXのcatコマンドを使用して、auditファイルを開きます。

$ cat audit | more
# 11/Jan/2012:11:20:00 +0100; conn=10; op=18
dn: cn=File-Based Audit Logger,cn=Loggers,cn=config
changetype: modify
replace: ds-cfg-enabled
ds-cfg-enabled: true
-
replace: modifiersName
modifiersName: cn=directory manager
-
replace: modifyTimestamp
modifyTimestamp: 20120111102000Z

# 11/Jan/2012:11:20:20 +0100; conn=11; op=6
dn: cn=File-Based Debug Logger,cn=Loggers,cn=config
changetype: modify
replace: ds-cfg-enabled
ds-cfg-enabled: true
-
replace: modifiersName
modifiersName: cn=directory manager
-
replace: modifyTimestamp
modifyTimestamp: 20120111102020Z
...(more output)...

29.5.4.3 デバッグ・ログを表示するには

1. デバッグ・ログのパブリッシャが有効になっていない場合、第29.3.1.1.2項「ログ・パブリッシャを有効にするには」の説明に従ってこれを有効にします。

2. サーバー・インスタンスのログ・ディレクトリに変更します。

$ cd INSTANCE_DIR/OUD/logs

3. テキスト・エディタまたはUNIXのcatコマンドを使用して、debugファイルを開きます。

$ cat debug | more
[11/Jan/2012:11:39:48 +0100] 0 caught error thread={Worker Thread 43(118)} threadDetail={parentThread=main(1) isDaemon=false clientConnection=LDAP client connection from 198.51.100.0:56288 to 198.51.100.0:2389 operation=SearchOperation(connID=13, opID=1, baseDN=dc=example,dc=com, scope=wholeSubtree, filter=(objectclass=*)) } method={run(SearchOperationBas
is.java:1513)} caught={org.opends.server.types.CanceledOperationException: Client Disconnect}
...(more output)...

29.5.4.4 エラー・ログを表示するには

1. サーバー・インスタンスのログ・ディレクトリに変更します。

$ cd INSTANCE_DIR/OUD/logs

2. テキスト・エディタまたはUNIXのcatコマンドを使用して、errorsファイルを開きます。

$ cat errors | more
[11/Jan/2012:15:14:13 +0100] category=RUNTIME_INFORMATION severity=NOTICE msgID=20381717 msg=Installation Directory:  /local/OUD_BASE/Oracle_OUD1[11/Jan/2012:15:14:13 +0100] category=RUNTIME_INFORMATION severity=NOTICE msgID=20381719 msg=Instance Directory:      /local/OUD_BASE/asinst_4/OUD[11/Jan/2012:15:14:13 +0100] category=RUNTIME_INFORMATION severity=NOTICE msgID=20381713 msg=JVM Information: 1.6.0_30-b12 by Sun Microsystems Inc., 32-bit architecture, 957743104 bytes heap size[11/Jan/2012:15:14:13 +0100] category=RUNTIME_INFORMATION severity=NOTICE msgID=20381714 msg=JVM Host: host1, running SunOS 5.10 sparc, 103079215104 bytes physical memory size, number of processors available 24[11/Jan/2012:15:14:13 +0100] category=RUNTIME_INFORMATION severity=NOTICE msgID=20381715 msg=JVM Arguments: "-Dorg.opends.server.scriptName=start-ds"[11/Jan/2012:15:14:16 +0100] category=PROTOCOL severity=NOTICE msgID=2556180 msg=Started listening for new connections on Administration Connector 0.0.0.0 port 7444[11/Jan/2012:15:14:16 +0100] category=PROTOCOL severity=NOTICE msgID=2556180 msg=Started listening for new connections on LDAP Connection Handler 0.0.0.0 port 4389[11/Jan/2012:15:14:16 +0100] category=CORE severity=NOTICE msgID=458887 msg=TheDirectory Server has started successfully...(more output)...

29.5.4.5 レプリケーション修復ログを表示するには

1. サーバー・インスタンスのログ・ディレクトリに変更します。

$ cd INSTANCE_DIR/OUD/logs

2. テキスト・エディタまたはUNIXのcatコマンドを使用して、replicationファイルを開きます。

$ cat replication | more
[13/Jan/2012:15:00:50 +0100] category=SYNC severity=NOTICE msgID=15139035 msg=The replication server database has version 2 format[13/Jan/2012:15:00:50 +0100] category=SYNC severity=NOTICE msgID=15138878 msg=Replication is up and running for domain cn=admin data with replication server id 18049 host1/198.51.100.0:8989 - local server id is 9338 - data generation is 93408[13/Jan/2012:15:00:52 +0100] category=SYNC severity=NOTICE msgID=15138878 msg=Replication is up and running for domain dc=example,dc=com with replication server id 18049 host1/198.51.100.0:8989 - local server id is 25340 - data generation is 19449577[13/Jan/2012:15:00:53 +0100] category=SYNC severity=NOTICE msgID=15138878 msg=Replication is up and running for domain cn=schema with replication server id 18049 host1/198.51.100.0:8989 - local server id is 13881 - data generation is 8408[13/Jan/2012:15:08:28 +0100] category=SYNC severity=NOTICE msgID=15138893 msg=On suffix cn=admin data, replication server 3844 presented generation ID=-1 when expected generation ID=93408[13/Jan/2012:15:08:28 +0100] category=SYNC severity=MILD_ERROR msgID=14876753 msg=In RS 18049 for dn cn=admin data, update 00000134d765d4b1247a00000001 will not be sent to RS 3844 with generation id -1 different from local generation id 93408[13/Jan/2012:15:08:28 +0100] category=SYNC severity=MILD_ERROR msgID=14876753 msg=In RS 18049 for dn cn=admin data, update 00000134d765d4b1247a00000002 will not be sent to RS 3844 with generation id -1 different from local generation id 93408...(more output)...

29.5.4.6 server.outログを表示するには

1. サーバー・インスタンスのログ・ディレクトリに変更します。

$ cd INSTANCE_DIR/OUD/logs

2. テキスト・エディタまたはUNIXのcatコマンドを使用して、server.outファイルを開きます。

$ cat server.out | more
[23/May/2011:02:27:59 -0700] category=CORE severity=INFORMATION msgID=132
msg=The Directory Server is beginning the configuration bootstrapping process
[23/May/2011:02:28:00 -0700] category=EXTENSIONS severity=INFORMATION msgID=1049147
msg=Loaded extension from file '/OUD_BASE/ORACLE_HOME/lib/extensions/globalindex.jar'
(build 1.0.0)
[23/May/2011:02:28:00 -0700] category=EXTENSIONS severity=INFORMATION msgID=1049147
msg=Loaded extension from file '/OUD_BASE/ORACLE_HOME/lib/extensions/replication-gateway.jar'
(build 1.0.0)
[23/May/2011:02:28:00 -0700] category=EXTENSIONS severity=INFORMATION msgID=1049147
msg=Loaded extension from file '/OUD_BASE/ORACLE_HOME/lib/extensions/snmp-mib2605.jar'
(build 11.1.1.5.0)
[23/May/2011:02:28:00 -0700] category=EXTENSIONS severity=INFORMATION msgID=1049147
msg=Loaded extension from file '/OUD_BASE/ORACLE_HOME/lib/extensions/loadbalancing.jar'
(build 1.0.0)
[23/May/2011:02:28:00 -0700] category=EXTENSIONS severity=INFORMATION msgID=1049147
msg=Loaded extension from file '/OUD_BASE/ORACLE_HOME/lib/extensions/virtualization.jar'
(build 1.0.0)
[23/May/2011:02:28:00 -0700] category=EXTENSIONS severity=INFORMATION msgID=1049147
msg=Loaded extension from file '/OUD_BASE/ORACLE_HOME/lib/extensions/distribution.jar'
(build 1.0.0)
...
more output
...

29.5.4.7 設定ログを表示するには

このログ・ファイルは、プロキシ・サーバーおよびレプリケーション・ゲートウェイのインスタンスに対してのみ使用できます。

1. サーバー・インスタンスのログ・ディレクトリに変更します。

$ cd INSTANCE_DIR/OUD/logs

2. テキスト・エディタまたはUNIXのcatコマンドを使用して、oud-setupファイルを開きます。

$ cat oud-setup | more
May 19, 2011 2:24:36 AM com.sun.dps.ui.deploy.SetupLog initLogFileHandler
INFO: oud-setup application launched May 19, 2011 2:24:36 AM PDT
...(more output)...

29.6 SNMPを使用したサーバーの監視

Oracle Unified Directoryでは、管理情報ベース(MIB) 2605サポートのSimple Network Management Protocol (SNMP)接続ハンドラを含むjarファイル拡張が提供されます。この拡張には、SNMP接続ハンドラ、MIB 2605オブジェクトとSNMPリクエストをサポートするために必要なクラス、およびSNMPマネージャによるサーバー監視情報へのアクセスを可能にするSNMPアダプタが含まれます。

この項の手順を開始する前に、対象のシステムでSNMP管理対象ネットワークを設定済であることを確認してください。

29.6.1 SNMP接続ハンドラおよびその依存性の構成

Oracle Unified Directoryには、有効にして構成できるSNMP接続ハンドラが用意されています。SNMP接続ハンドラは、jarファイル拡張子として提供され、install-dir/lib/extensions/snmp-mib2605.jarにあります。

29.6.1.1 サーバーのSNMPを構成するには

Oracle Unified Directoryを構成して、Simple Network Management Protocol (SNMP)を使用して監視できます。サーバーは、Java Dynamic Management Kit (JDMK)を使用して、SNMP接続ハンドラのスマート・エージェントを作成します。

1. 次のようにdsconfigを使用して、SNMP接続ハンドラが現在の接続ハンドラのリストの下に表示されていることを確認します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
list-connection-handlers

Connection Handler       : Type : enabled : listen-port : use-ssl
-------------------------:------:---------:-------------:--------
JMX Connection Handler   : jmx  : false   : 1689        : false
LDAP Connection Handler  : ldap : true    : 1389        : false
LDAPS Connection Handler : ldap : false   : 636         : true
LDIF Connection Handler  : ldif : true    : -           : -
SNMP Connection Handler  : snmp : false   : 161         : -

2. dsconfigコマンドを使用して、サーバーのSNMPを有効にし、リスニング・ポートを設定します。

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -n -X \
set-connection-handler-prop --handler-name "SNMP Connection Handler" \
--set enabled:true --set listen-port:8085

29.6.1.2 SNMP接続ハンドラのプロパティを表示するには

次のコマンドを実行して、SNMP接続ハンドラのプロパティのリストを表示します。

$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \
get-connection-handler-prop --handler-name "SNMP Connection Handler"

接続ハンドラのプロパティは、次のようにその値とともにリストされます。

Property            : Value(s)
--------------------:------------------------------------------
allowed-client      : -
allowed-manager     : *
allowed-user        : *
community           : OUD
denied-client       : -
enabled             : false
listen-port         : 161
opendmk-jarfile     : -
registered-mbean    : false
security-agent-file : config/snmp/security/oud-snmp.security
security-level      : authnopriv
trap-port           : 162
traps-community     : OUD
traps-destination   : -

29.6.1.3 サーバー・インスタンス上でSNMPにアクセスするには

1. stop-dsおよびstart-dsを使用して、サーバーを再起動します。
サーバーを起動して、構成を変更しなかった場合、再起動操作は必要ありません。

2. SNMP接続ハンドラが動作中であることを確認します。

$ snmpwalk -v 2c -c OUD@OUD localhost:8085 mib-2.66
SNMPv2-SMI::mib-2.66.1.1.1.1 = STRING: "Oracle Unified Directory Server 11.1.1.5.0 -
20090310152800Z"
SNMPv2-SMI::mib-2.66.1.1.2.1 = STRING: "INSTANCE_DIR/bin"
SNMPv2-SMI::mib-2.66.1.1.3.1 = Gauge32: 35
SNMPv2-SMI::mib-2.66.1.1.4.1 = Gauge32: 1
SNMPv2-SMI::mib-2.66.1.1.5.1 = Gauge32: 0
SNMPv2-SMI::mib-2.66.1.1.6.1 = Counter32: 0
SNMPv2-SMI::mib-2.66.1.1.7.1 = Counter32: 1
SNMPv2-SMI::mib-2.66.2.1.1.1.1 = INTEGER: 1
SNMPv2-SMI::mib-2.66.2.1.1.1.2 = INTEGER: 2
SNMPv2-SMI::mib-2.66.2.1.1.1.3 = INTEGER: 3
SNMPv2-SMI::mib-2.66.2.1.2.1.1 = OID: SNMPv2-SMI::internet.27.3.8085
SNMPv2-SMI::mib-2.66.2.1.2.1.2 = OID: SNMPv2-SMI::internet.27.3.1389
SNMPv2-SMI::mib-2.66.2.1.2.1.3 = OID: SNMPv2-SMI::enterprises.42
SNMPv2-SMI::mib-2.66.2.1.3.1.1 = Counter32: 1
SNMPv2-SMI::mib-2.66.2.1.3.1.2 = Counter32: 1
SNMPv2-SMI::mib-2.66.2.1.3.1.3 = Counter32: 1
SNMPv2-SMI::mib-2.66.2.1.4.1.1 = Counter32: 1
SNMPv2-SMI::mib-2.66.2.1.4.1.2 = Counter32: 1
SNMPv2-SMI::mib-2.66.2.1.4.1.3 = Counter32: 1
SNMPv2-SMI::mib-2.66.2.1.5.1.1 = Counter32: 1
SNMPv2-SMI::mib-2.66.2.1.5.1.2 = Counter32: 1
...

MIB 2605に含まれている管理対象オブジェクトは、3つの表(dsTable、dsAppliIfOpsTableおよびdsIntTable)に分割されます。現在、dsIntTable表は実装されていません。

29.6.1.4 SNMPセキュリティ構成

SNMPセキュリティ構成は、使用しているSNMPのバージョンによって異なります。このトピックでは、SNMP V1およびV2c、ならびにV3のセキュリティ構成について説明します。

29.6.1.4.1 SNMPセキュリティ構成: V1およびV2c

SNMP v1およびSNMP v2cの下で、エージェントは情報サーバーとして動作し、IPベースのアクセス制御によってこの情報は不正なアクセスから保護されます。デフォルトでは、MIB 2605は、コミュニティ文字列OUD@OUDを使用して、v1およびv2cでアクセスできます。すべてのマネージャは、MIB 2605によって公開された監視情報を読み取ることができます。

注意:

MIB 2605では読取りアクセスのみが認可されます。

dsconfigコマンドを使用して、SNMP接続ハンドラのプロパティを設定することによってSNMP v1およびSNMP v2cを構成できます。SNMP v1およびSNMP v2cのセキュリティ構成に関するプロパティには次のものがあります:

- allowed-manager

- community

SNMP v1トラップは、サーバー起動時およびサーバーのシャットダウン時に送信されます。デフォルトでは、これらのトラップはlocalhostに送信され、トラップ・コミュニティ文字列「OUD」を使用します。

注意:

デフォルトのトラップ・ポートは、システムで許可されている値に変更する必要がある場合があります。

SNMPトラップも、dsconfigコマンドを使用して、SNMP接続プロパティを設定することによって構成できます。SNMPトラップに関するプロパティには次のものがあります:

- trap-port

- traps-community

- traps-destination

SNMP接続ハンドラのデフォルト値に対応するACLファイルは次のように表されます:

acl = {
{
communities = OUD
access = read-only
managers = all
}
}
trap = {
{
traps-community = OUD
hosts = localhost
}
}

29.6.1.4.2 SNMPセキュリティ構成: V3

SNMP v3プロトコルには、SNMP v1およびSNMP v2cよりも複雑なセキュリティ・メカニズムが用意されています。SNMP v3は、エージェントとそのマネージャ間を送信されるリクエストを認証して暗号化するユーザー・ベースのセキュリティ・モデル(USM)を実装し、ユーザー・ベースのアクセス制御を提供します。defaultUserテンプレートは、SNMPクローニング・メカニズムを使用してエージェント・エンジンの認可されたユーザーを追加するために提供されます。

SNMP v3の下で、前の項で説明したコミュニティ文字列は、MIB 2605の登録元の「コンテキスト」として使用されます。デフォルトでは、MIB2605は、コンテキスト「OUD」を使用してv3でアクセスできます。すべてのユーザーがこれにアクセスできます。

SNMP v3 UACLは、dsconfigコマンドライン・ユーティリティを使用してSNMP接続ハンドラのプロパティを設定することによって構成されます。SNMP v3 UACL構成に関するプロパティには次のものがあります:

- community

- allowed-user

- security-level

SNMP接続ハンドラのデフォルト値に対応するUACLファイルは次のように表されます:

uacl = {
{
context-names = OUD
access = read-only
security-level = authNoPriv
users = *
}
}

29.6.1.4.3 SNMP USM構成: V3

USM MIB (つまり、許可されたユーザーを定義するMIB)は、nullコンテキストで登録され、authNoPrivのセキュリティ・レベルのsnmpAdminユーザーのみがこれに対する読取り/書込みアクセス権を持っています。このsnmpAdminユーザーは、MIB 2605情報にアクセスできるユーザーを追加できます。

SNMP v3 USM構成は、INSTANCE_DIR/OUD/config/snmp/security/oud-snmp.securityにあるテンプレート・ファイルから読み取られます。テンプレート・ファイルは暗号化されていません。

サーバー・エージェントのMIB 2605にアクセスするには、SNMPクローン・メカニズムを使用してユーザーをセキュリティ・ファイルに追加します。snmpAdminを使用して、次の示すようにクローン・メカニズムのSNMPリクエストを送信します。クローニングするユーザーはdefaultUserです。snmpAdminユーザーおよびdefaultUserユーザーはMIB 2605情報にアクセスできません。

- 追加して他のユーザーを構成する管理ユーザー。

userEntry=localEngineID,snmpAdmin,null,usmHMACMD5AuthProtocol,passadmin

- 読取りアクセス権限および書込みアクセス権限を付与されずにクローニングされるテンプレート・ユーザー。

userEntry=localEngineID,defaultUser,,usmHMACMD5AuthProtocol,password,,,3,true

注意:

ユーザーを永続にするためにセキュリティ・ファイルも使用されます。

29.7 レプリケートされたトポロジの監視

これらのトピックでは、dsreplication statusコマンドを使用してレプリケートされたトポロジを監視する方法およびldapsearchコマンドを使用してさらに詳細な監視情報を取得する方法を説明します。

29.7.1 dsreplicationを使用したレプリケーション・ステータスの監視

レプリケーションを監視する最も簡単な方法は、dsreplication statusコマンドを使用することです。このコマンドは、次の情報を含むレプリケーション・ステータスの表を提供します:

- トポロジおよびその接続

- レプリケートされるサーバー間の待機時間

- レプリケートされるサーバー間のデータ一貫性

- レプリケートされるサーバー間のセキュリティ構成

- レプリケーション・プロトコルのピア・ツー・ピア

この項の残りの部分の例では、次の単純なレプリケーション・トポロジを想定しています。

図29-2 単純なレプリケーション・トポロジ

レプリケーション・ステータスを取得するには、次のコマンドを実行します:

$ dsreplication status --adminUID admin --adminPasswordFile pwd.txt -X \
--hostname host1 --port 4444

このコマンドの出力には次のものが含まれます:

- サーバー。トポロジのLDAPサーバーおよびLDAPサーバーがLDAP接続をリスニングしているポートをリストします。

- エントリ。指定したベースDNの各サーバーのエントリ数を示します。この列の情報がすべてのサーバー間で同じでない場合、レプリケーション・トポロジは同期化されていません。

- M.C。トポロジの他のLDAPサーバーによってすでにプッシュされたが指定したLDAPサーバーでまだリプレイされていない更新数を示します。この数が特定のサーバーで大きい場合、そのサーバーの待機時間を調査します。

- A.O.M.C。トポロジの他のディレクトリ・サーバーによってプッシュされたが指定したLDAPサーバーでまだ処理されていない最も古い更新のおよその日付を指定します。

- ポート。指定したLDAPサーバーの直接の接続先のレプリケーション・サーバーのポートを示します。

- 暗号化。LDAPサーバーとそのレプリケーション・サーバーの間でSSL暗号化が有効になっているかどうかを示します。

- 信頼。このサーバーが信頼できるサーバーとして構成されているか、信頼されないサーバーとして構成されているかを示します。詳細は、第26.10項「分離レプリカの使用」を参照してください。

- U.C。信頼されないサーバーで行われたが、まだトポロジにレプリケートされていない変更の数を指定します。詳細は、第26.10項「分離レプリカの使用」を参照してください。

- ステータス。このディレクトリ・サーバーのレプリケーション・ドメインのステータスを示します。ステータスは次のいずれかになります:

- 正常。レプリケーション・サーバーへの接続は、正しいデータ・セットで確立されます。レプリケーションが機能しています。確実なモードを使用すると、このディレクトリ・サーバーからの確認が送信されます。

- 機能低下。レプリケーション・サーバーへの接続は、正しいデータ・セットで確立されます。ディレクトリ・サーバーにはレプリケーション・サーバーのキューで保留中の変更が多数あるため、レプリケーションは低下モードで動作しています。確実なモードを使用すると、このディレクトリ・サーバーからの確認は送信されません。

- 完全更新。レプリケーション・サーバーとの接続が確立され、ローカル・バックエンドを初期化するために、新しいデータ・セットがこの接続から受信されます(オンライン・インポート)。

- 不正データ・セット。レプリケーション・サーバーとの接続が、トポロジの他のディレクトリ・サーバーとは異なるデータ・セットで確立されます。レプリケーションは動作しません。トポロジの他のディレクトリ・サーバーを互換性のあるデータ・セットを使用して初期化する必要があるか、またはこのサーバーを他のサーバーと互換性のある別のデータ・セットを使用して初期化する必要があります。

- 未接続。ディレクトリ・サーバーは、どのレプリケーション・サーバーとも接続されていません。

- 変更ログ。外部変更ログがこのサーバーのベースDNに対して有効になっているかどうかを示します。詳細は、第26.5項「外部変更ログの使用」を参照してください。

- グループID。サーバーが属しているレプリケーション・グループのIDです。詳細は、第6.6項「レプリケーション・グループ」を参照してください。

- 接続先。このディレクトリ・サーバーの接続先のレプリケーション・サーバーの名前、IPアドレスおよびレプリケーション・ポートを表示します。

追加のレプリケーション監視情報は、cn=monitorエントリにあります。ldapsearchコマンドを使用して、レプリケーション・ステータスの包括的なビューを提供する特定の監視属性を追跡できます。詳細は、第29.7.2項「詳細レプリケーション監視」を参照してください。

29.7.2 詳細レプリケーション監視

レプリケーション・ステータスを監視する最も簡単な方法は、dsreplication statusコマンドを使用することです。ただし、詳細なレプリケーション監視情報は、cn=monitorエントリにあります。ldapsearchコマンドを使用して、レプリケーション・ステータスの包括的なビューを提供する特定の監視属性を追跡できます。監視情報は、レプリケーション・サーバーによって統合されます。したがって、監視情報は、実行中のレプリケーション・サーバーをホストしているディレクトリ・サーバーを検索することによってのみ取得できます。

この項の残りの部分の例では、次の単純なレプリケーション・トポロジを想定しています。

図29-3 単純なレプリケーション・トポロジ

これらの例は、管理ポートのcn=monitorエントリにSSL(--useSSL)を介してアクセスし、サーバー(--trustAll)によって示される証明書を自動的に信頼します。

cn=monitorの下の情報は、レプリケートされた単一のベースDNを含むようにフィルタできます。これは、次の2つの方法で実行できます:

- domain-name属性をフィルタとして指定します。例:

$ ldapsearch -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \
--trustAll -b "cn=monitor" "(domain-name=dc=example,dc=com)"

- 検索ベースのベースDNを組み込みます。例:

$ ldapsearch -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \
--trustAll -b "cn=dc_example_dc_com,cn=replication,cn=monitor" \
"(objectclass=*)"

この項では、次の監視トピックについて説明します:

- 第29.7.2.1項「トポロジおよびその接続を監視するには」

- 第29.7.2.2項「レプリケーション待機時間を監視するには」

- 第29.7.2.3項「データの一貫性を監視するには」

- 第29.7.2.4項「レプリケーションのセキュリティを監視するには」

- 第29.7.2.5項「レプリケートされた更新を監視するには」

- 第29.7.2.6項「レプリケーションの競合を監視するには」

29.7.2.1 トポロジおよびその接続を監視するには

各ディレクトリ・サーバーには、レプリケートされたベースDNそれぞれに対するレプリケーション・サーバーの候補のリストが含まれています。ただし、1つのディレクトリ・サーバーは、一度に1つのレプリケーション・サーバーのみと接続されます。

レプリケーション・トポロジおよびその接続の概要を取得するには、レプリケーション・サーバーをホストしているトポロジの任意のディレクトリ・サーバーで次の検索を実行します:

$ ldapsearch -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \
--trustAll -b "cn=monitor" "(connected-to=*)" "connected-to" "lost-connections"
dn: cn=Replication Domain 30839,cn=dc_example_dc_com,cn=replication,cn=monitor
lost-connections: 0
connected-to: llandudno/0:0:0:0:0:0:0:1:8989

dn: cn=Replication Domain 14142,cn=cn_schema,cn=replication,cn=monitor
lost-connections: 0
connected-to: llandudno/0:0:0:0:0:0:0:1:8989

dn: cn=Connected Replica llandudno 27742,cn=Replication Server 8989  1740,cn=cn_
admin data,cn=replication,cn=monitor
connected-to: Replication Server 8989 1740

dn: cn=Connected Replica llandudno 30839,cn=Replication Server 8989  1740,cn=dc_
example_dc_com,cn=replication,cn=monitor
connected-to: Replication Server 8989 1740

dn: cn=Connected Replica llandudno 14142,cn=Replication Server 8989  1740,cn=cn_
schema,cn=replication,cn=monitor
connected-to: Replication Server 8989 1740

dn: cn=Undirect Replica  22052,cn=Connected Replication Server noordhoek:9989 71
64,cn=Replication Server 8989  1740,cn=cn_schema,cn=replication,cn=monitor
connected-to: Connected Replication Server noordhoek:9989 7164,cn=Replication Se
rver 8989  1740,cn=cn_schema,cn=replication

dn: cn=Undirect Replica  19984,cn=Connected Replication Server noordhoek:9989 71
64,cn=Replication Server 8989  1740,cn=dc_example_dc_com,cn=replication,cn=moni
tor
connected-to: Connected Replication Server noordhoek:9989 7164,cn=Replication Se
rver 8989  1740,cn=dc_example_dc_com,cn=replication

dn: cn=Undirect Replica  30030,cn=Connected Replication Server noordhoek:9989 71
64,cn=Replication Server 8989  1740,cn=cn_admin data,cn=replication,cn=monitor
connected-to: Connected Replication Server noordhoek:9989 7164,cn=Replication Se
rver 8989  1740,cn=cn_admin data,cn=replication

dn: cn=Replication Domain 27742,cn=cn_admin data,cn=replication,cn=monitor
lost-connections: 0
connected-to: llandudno/0:0:0:0:0:0:0:1:8989

connected-to属性は、特定のベースDNに関して各ディレクトリ・サーバーが現在接続されているレプリケーション・サーバーを指定します。ディレクトリ・サーバーがレプリケーション・サーバーに直接接続される場合、そのDNにはcn=Connected Replicaが含まれます。トポロジにあるが異なるレプリケーション・サーバーに接続されているディレクトリ・サーバーは、そのDNにcn=Undirect Replicaが含まれます。すべてのレプリケーション・サーバーがその他のすべてのレプリケーション・サーバーと永続的に接続されるため、connected-to属性はレプリケーション・サーバーには存在しません。

lost-connections属性は、ディレクトリ・サーバーとレプリケーション・サーバーの間の接続切断数を示します。各ディレクトリ・サーバーのこの属性の値は、そのサーバーでレプリケーションが停止された回数に近いはずです。この属性の値がずっと大きい場合、予期しない接続損失があり、これを調査する必要があります。

29.7.2.2 レプリケーション待機時間を監視するには

レプリケーション待機時間を監視すると、特定のレプリケーション・サーバーがトポロジ内のその他のサーバーから遅れているかどうかを確認できます。これによって、レプリケーションの遅延および現在のサービスのクオリティの全体像が提供されます。

レプリケーション待機時間を監視するには、レプリケーション・サーバーをホストしているトポロジの任意のサーバーで次の検索を実行します:

$ ldapsearch -p 4444 -D "cn=directory manager" -j pwd-file --useSSL \
--trustAll -b "cn=monitor" "domain-name=dc=example,dc=com" "missing-changes" \
"approx-older-change-not-synchronized"
dn: cn=Replication Domain 30839,cn=dc_example_dc_com,cn=replication,cn=monitor

dn: cn=Replication Server 8989 1740,cn=dc_example_dc_com,cn=replication,cn=monitor
missing-changes: 0

dn: cn=Connected Replica llandudno 30839,cn=Replication Server 8989  1740,cn=dc_
example_dc_com,cn=replication,cn=monitor
missing-changes: 0

dn: cn=Connected Replication Server noordhoek:9989 7164,cn=Replication Server 8989
1740,cn=dc_example_dc_com,cn=replication,cn=monitor
missing-changes: 0

dn: cn=Undirect Replica 19984,cn=Connected Replication Server noordhoek:9989
7164,cn=Replication Server 8989 1740,cn=dc_example_dc_com,cn=replication,cn=monitor
missing-changes: 0

missing-changes属性は、トポロジの他のディレクトリ・サーバーによってすでにプッシュされたが指定したディレクトリ・サーバーでまだリプレイされていない更新数を指定します。

approx-older-change-not-synchronized属性は、トポロジの他のディレクトリ・サーバーによってプッシュされたが指定したディレクトリ・サーバーでまだ処理されていない最も古い更新のおよその日付を指定します。

注意:

これらの属性によって定義されているようなレプリケーション待機時間が大きい場合、送受信された更新数を確認し、トポロジで待機時間の原因になっているサーバーを特定します。これらの属性は、このドキュメントで後述します。

29.7.2.3 データの一貫性を監視するには

データの一貫性を監視すると、トポロジの各レプリケーション・サーバーがトポロジで発生した最新の変更と同期化されて最新であるかどうかを確認できます。

トポロジのディレクトリ・サーバー間でのデータの一貫性を監視するには、レプリケーション・サーバーをホストしているトポロジの任意のサーバーで次の検索を実行します:

$ ldapsearch -p 4444 -D "cn=directory manager" -j pwd-file --useSSL --trustAll \
-b "cn=monitor" "(generation-id=*)" "generation-id"
dn: cn=Replication Server 8989  1740,cn=cn_admin data,cn=replication,cn=monitor
generation-id: cn=admin data 94310

dn: cn=Connected Replication Server noordhoek:9989 7164,cn=Replication Server 8989
1740,cn=cn_admin data,cn=replication,cn=monitor
generation-id: 94310

dn: cn=Replication Domain 30839,cn=dc_example_dc_com,cn=replication,cn=monitor
generation-id: 19399981

dn: cn=Replication Domain 14142,cn=cn_schema,cn=replication,cn=monitor
generation-id: 8468

dn: cn=Connected Replica llandudno 27742,cn=Replication Server 8989  1740,cn=cn_
admin data,cn=replication,cn=monitor
generation-id: 94310

dn: cn=Replication Server 8989  1740,cn=cn_schema,cn=replication,cn=monitor
generation-id: cn=schema 8468

dn: cn=Replication Server 8989  1740,cn=dc_example_dc_com,cn=replication,cn=monitor
generation-id: dc=example,dc=com 19399981

dn: cn=Connected Replica llandudno 30839,cn=Replication Server 8989  1740,cn=dc_
example_dc_com,cn=replication,cn=monitor
generation-id: 19399981

dn: cn=Connected Replication Server noordhoek:9989 7164,cn=Replication Server 8989
1740,cn=cn_schema,cn=replication,cn=monitor
generation-id: 8468

dn: cn=Connected Replica llandudno 14142,cn=Replication Server 8989  1740,cn=cn_
schema,cn=replication,cn=monitor
generation-id: 8468

dn: cn=Connected Replication Server noordhoek:9989 7164,cn=Replication Server 8989
1740,cn=dc_example_dc_com,cn=replication,cn=monitor
generation-id: 19399981

dn: cn=Replication Domain 27742,cn=cn_admin data,cn=replication,cn=monitor
generation-id: 94310

generation-id属性は、各ディレクトリ・サーバーに対して、レプリケートされた各ベースDNのデータのバージョンを示します。ベースDN dc=example,dc=comのすべてのサーバーの生成IDは、19399981です。生成IDの一貫性は、これらのサーバーのデータがそのベースDNで同じであることを意味します。

各ディレクトリ・サーバーも接続先のレプリケーション・サーバーの生成IDを認識しています。レプリケーション・サーバーの生成IDは、そのベースDNの変更ログ・データベースに格納されている更新と関係があります。

指定したベースDNの2つのディレクトリ・サーバーおよびそのレプリケーション・サーバーがすべて同じ生成IDを持っている場合、その2つのディレクトリ・サーバー間でレプリケーションが正しく動作していると見なされます。

29.7.2.4 レプリケーションのセキュリティを監視するには

セキュア・レプリケーション・トポロジでは、特定のベースDNに対して、サーバー間でSSL暗号化が有効になっています。

レプリケーションのセキュリティを監視するには、レプリケーション・サーバーをホストしているトポロジの任意のサーバーで次の検索を実行します:

$ ldapsearch -p 4444 -D "cn=directory manager" -j pwd-file --useSSL --trustAll \
-b "cn=monitor" "(ssl-encryption=*)" "ssl-encryption"
dn: cn=Connected Replication Server noordhoek:9989 7164,cn=Replication Server 89
89  1740,cn=cn_admin data,cn=replication,cn=monitor
ssl-encryption: true

dn: cn=Replication Domain 30839,cn=dc_example_dc_com,cn=replication,cn=monitor
ssl-encryption: true

dn: cn=Replication Domain 14142,cn=cn_schema,cn=replication,cn=monitor
ssl-encryption: true

dn: cn=Connected Replica llandudno 27742,cn=Replication Server 8989  1740,cn=cn_
admin data,cn=replication,cn=monitor
ssl-encryption: true

dn: cn=Connected Replica llandudno 30839,cn=Replication Server 8989  1740,cn=dc_
example_dc_com,cn=replication,cn=monitor
ssl-encryption: true

dn: cn=Connected Replication Server noordhoek:9989 7164,cn=Replication Server 89
89  1740,cn=cn_schema,cn=replication,cn=monitor
ssl-encryption: true

dn: cn=Connected Replica llandudno 14142,cn=Replication Server 8989  1740,cn=cn_
schema,cn=replication,cn=monitor
ssl-encryption: true

dn: cn=Connected Replication Server noordhoek:9989 7164,cn=Replication Server 8989
1740,cn=dc_example_dc_com,cn=replication,cn=monitor
ssl-encryption: true

dn: cn=Replication Domain 27742,cn=cn_admin data,cn=replication,cn=monitor
ssl-encryption: true

ssl-encryption属性は、指定したベースDNの2つのサーバー間でレプリケーション・プロトコルを暗号化するかどうかを指定します。この情報は、ディレクトリ・サーバーまたはレプリケーション・サーバーそれぞれに対して使用できます。レプリケーション・セッションの認証は監視されません。

29.7.2.5 レプリケートされた更新を監視するには

トポロジのサーバーによって送受信された更新数を監視すると、レプリケーションの動作状況がわかります。

送受信された更新を監視するには、次のコマンドを入力します:

$ ldapsearch -p 4444 -D "cn=directory manager" -j pwd-file --useSSL --trustAll \
-b "cn=monitor" "(&(sent-updates=*)(received-updates=*))" \
"sent-updates" "received-updates"
dn: cn=Connected Replication Server noordhoek:9989 7164,cn=Replication Server 8989
1740,cn=cn_admin data,cn=replication,cn=monitor
sent-updates: 7
received-updates: 0

dn: cn=Replication Domain 30839,cn=dc_example_dc_com,cn=replication,cn=monitor
received-updates: 28
sent-updates: 0

dn: cn=Replication Domain 14142,cn=cn_schema,cn=replication,cn=monitor
received-updates: 0
sent-updates: 0

dn: cn=Connected Replica llandudno 27742,cn=Replication Server 8989  1740,cn=cn_
admin data,cn=replication,cn=monitor
sent-updates: 0
received-updates: 0

dn: cn=Connected Replica llandudno 30839,cn=Replication Server 8989  1740,cn=dc_
example_dc_com,cn=replication,cn=monitor
sent-updates: 28
received-updates: 0

dn: cn=Connected Replication Server noordhoek:9989 7164,cn=Replication Server 8989
1740,cn=cn_schema,cn=replication,cn=monitor
sent-updates: 0
received-updates: 0

dn: cn=Connected Replica llandudno 14142,cn=Replication Server 8989  1740,cn=cn_
schema,cn=replication,cn=monitor
sent-updates: 0
received-updates: 0

dn: cn=Connected Replication Server noordhoek:9989 7164,cn=Replication Server 8989
1740,cn=dc_example_dc_com,cn=replication,cn=monitor
sent-updates: 0
received-updates: 28

dn: cn=Replication Domain 27742,cn=cn_admin data,cn=replication,cn=monitor
received-updates: 0
sent-updates: 0

sent-updates属性は、このディレクトリ・サーバーまたはレプリケーション・サーバーによって送信された更新数を示します。

received-updates属性は、このディレクトリ・サーバーまたはレプリケーション・サーバーによって受信された更新数を示します。

これらの属性の値は、トポロジ内の更新のフローを判断する際に役立ちます。レプリケーションが非常に遅いと思われる場合、これらの属性を監視すると役に立ちます。あるサーバーによって送信された更新数が別のサーバーによって受信された更新数より一貫してずっと多い場合、2番目のサーバーがトポロジ内でボトルネックになっている可能性が高いです。

レプリケーション・プロトコルは、2つのサーバー間の更新のフローを制御します。これによって、多数の更新が2つのサーバー間で交換される場合、サーバーはより高い優先度の操作の処理を妨げられることがなくなります。この機能は、送信サーバーが送信できる更新数を受信サーバーが定期的に送信サーバーに提供するウィンドウ・メカニズムに依存しています。

max-send-window構成属性およびmax-rcv-window構成属性を設定して、送信ウィンドウおよび受信ウィンドウのサイズを指定できます。詳細は、第26.3項「dsconfigによるレプリケーション構成の変更」を参照してください。

current-send-window監視属性は、指定時間に送信サーバーが受信サーバーに送信できる変更数を示します。current-send-window属性の値が0と等しくなることが多い場合、転送が停止し、受信サーバーがトポロジのボトルネックになっている可能性が高いです。current-send-window属性の値がmax-send-window属性の値と等しくなることが多い場合、レプリケーション待機時間が長くなっていて、送信サーバーがトポロジのボトルネックになっている可能性が高いです。

current-send-windowプロパティの値を取得するには、次のコマンドを入力します:

$ ldapsearch -p 4444 -D "cn=directory manager" -j pwd-file --useSSL --trustAll \
-b "cn=monitor" "(current-send-window=*)" "current-send-window"
dn: cn=Connected Replication Server noordhoek:9989 7164,cn=Replication Server 8989
1740,cn=cn_admin data,cn=replication,cn=monitor
current-send-window: 93

dn: cn=Replication Domain 30839,cn=dc_example_dc_com,cn=replication,cn=monitor
current-send-window: 100

dn: cn=Replication Domain 14142,cn=cn_schema,cn=replication,cn=monitor
current-send-window: 100

dn: cn=Connected Replica llandudno 27742,cn=Replication Server 8989  1740,cn=cn_
admin data,cn=replication,cn=monitor
current-send-window: 100

dn: cn=Connected Replica llandudno 30839,cn=Replication Server 8989  1740,cn=dc_
example_dc_com,cn=replication,cn=monitor
current-send-window: 72

dn: cn=Connected Replication Server noordhoek:9989 7164,cn=Replication Server 8989
1740,cn=cn_schema,cn=replication,cn=monitor
current-send-window: 100

dn: cn=Connected Replica llandudno 14142,cn=Replication Server 8989  1740,cn=cn_
schema,cn=replication,cn=monitor
current-send-window: 100

dn: cn=Connected Replication Server noordhoek:9989 7164,cn=Replication Server 8989
1740,cn=dc_example_dc_com,cn=replication,cn=monitor
current-send-window: 100

dn: cn=Replication Domain 27742,cn=cn_admin data,cn=replication,cn=monitor
current-send-window: 100

29.7.2.6 レプリケーションの競合を監視するには

同時に同じエントリで複数の操作が実行されると、レプリケーションの競合が発生する可能性があります。場合によっては、レプリケーション・メカニズムによって競合を解決できます。手動の競合解決が必要な場合もあります。

3種類の競合属性を監視できます:

- unresolved-naming-conflicts。レプリケーション・メカニズムによって解決できない名前の競合の数を示します。

- resolved-naming-conflicts。解決された名前の競合の数を示します。

- resolved-modify-conflicts。解決された変更の競合の数を示します。

解決済のレプリケーションの競合および未解決のレプリケーションの競合を監視するには、次のコマンドを実行します:

$ ldapsearch -p 4444 -D "cn=directory manager" -j pwd-file --useSSL --trustAll \
-b "cn=monitor" "(&(unresolved-naming-conflicts=*) \
(resolved-naming-conflicts=*) (resolved-modify-conflicts=*))" \
"unresolved-naming-conflicts" "resolved-naming-conflicts" \
"resolved-modify-conflicts"
dn: cn=Replication Domain 30839,cn=dc_example_dc_com,cn=replication,cn=monitor
resolved-naming-conflicts: 0
unresolved-naming-conflicts: 0
resolved-modify-conflicts: 0

dn: cn=Replication Domain 14142,cn=cn_schema,cn=replication,cn=monitor
resolved-naming-conflicts: 0
unresolved-naming-conflicts: 0
resolved-modify-conflicts: 0

dn: cn=Replication Domain 27742,cn=cn_admin data,cn=replication,cn=monitor
resolved-naming-conflicts: 0
unresolved-naming-conflicts: 0
resolved-modify-conflicts: 0

29.8 汎用のエンタープライズの監視のソリューション

様々な汎用UNIXツールを使用して、サーバー環境を監視できます。これらのツールの詳細は、UNIXシステムのマニュアル・ページを参照してください。

29.8.1 汎用のUNIX監視ツール

Oracle Unified Directoryでは次の汎用UNIX監視ツールを使用できます。

ツール

説明

iostat

ディスクI/OおよびCPUの使用量に関する情報を提供します。

lsof

オープン・ファイル・ディスクリプタに関する情報を提供します。

lslk

ファイル・システム・ロックに関する情報を提供します。

netstat

ネットワーク機能の統計を提供します。

nslookup

ホストおよびドメインに関する情報をDNSサーバーに問い合せることができます。

ping

リモート・ホストまたはネットワーク・ゲートウェイのステータスを問い合せることができます。

sar

UNIXシステムVのパフォーマンス監視ツール。

tcpdump

ネットワーク・トラフィックをデバッグおよび監視できます。

top

プロセスおよびCPUアクティビティの素早く簡単な監視を提供します。

trace

プロセスが行うシステム・コールに関する情報を提供します。

traceroute

最終宛先に到達するためにインターネット全体でパケットが取るパスを提供します。

vmstat

プロセス、仮想メモリー、ディスク、トラップおよびCPUアクティビティに関する統計を提供します。

29.8.2 Solarisの監視ツール

Oracle Unified Directoryでは次のSolarisの監視ツールを使用できます。

ツール

説明

lockstat

OSおよびアプリケーションのロックに関する情報を提供します。DTrace権限が必要です。

mpstat

システムの各プロセッサに関する統計を提供します。

pmap

プロセスで使用しているメモリーのブレークダウンを提供します。

proctool

プロセスおよびスレッドを監視します。

snoop

ネットワーク・トラフィックを監視します。低レベルのパケットをデバッグする際には必須です。

SymbEL/Virtual\\Adrian

前述のツールなどの機能を提供します。

truss

プロセスが行うシステム・コールに関する情報を提供します。

29.8.3 HP-UXの監視ツール

Oracle Unified Directoryでは次のHP-UXの監視ツールを使用できます。

ツール

説明

glance

オープン・ファイル・ディスクリプタ、ロックおよびスレッドに関する詳細システム情報を提供します。

gpm

GlancePlusは、グラフィカル・リアルタイム・パフォーマンス診断ツールです。Glanceは文字ベースのコンポーネントです。

tusc

システム・コール・トラップ機能を提供します。

sysdef

カーネル・パラメータに関する情報を提供します。

landiag

ネットワーク統計を監視します。

sam

一般的なシステム管理ツールを提供します。

30 パフォーマンスのチューニング

Oracle Unified Directoryの目標は、高いパフォーマンスおよびスケーラビリティを実現することです。デフォルトのサーバー構成およびJVM設定でも、サーバーで優れた結果を実現できる可能性はありますが、若干の基本的なチューニングを行うことで、多くの場合、パフォーマンスが大幅に向上します。

Oracle Unified Directoryのデフォルト設定は、制限されたリソースを使用して機器を稼働させている評価担当者および開発者を対象としています。Oracle Unified Directoryを本番環境にデプロイする場合、Java仮想マシン(JVM)およびサーバー構成に対して若干の初期チューニングを行うことによって、スケーラビリティおよびパフォーマンスを向上(特に書込み操作の場合)させることができます。

この章では、次のトピックを取り扱います:

- 第30.1項「パフォーマンスの問題の評価」

- 第30.2項「一般的なパフォーマンス・チューニング」

- 第30.3項「Java仮想マシン設定のチューニング」

- 第30.4項「データベース・キャッシュ・サイズの決定」

- 第30.5項「サーバー構成のチューニング」

30.1 パフォーマンスの問題の評価

パフォーマンスの問題がサーバーとクライアントのどちらに関連しているかを迅速に特定するには、INSTANCE_DIR/OUD/logs/accessにあるアクセス・ログを確認します。このログには、次の形式のエントリが含まれます:

[09/Sep/2009:15:36:18 +0200] SEARCH RES conn=1 op=16 msgID=17
result=0 nentries=1 etime=1

etimeフィールドの値は、サーバーがリクエストの処理に費やした時間(ミリ秒単位)です。一般的には、etimesの値が大きい場合、サーバー側で問題が発生しています(通常この問題は、適切なパフォーマンス・チューニングおよび索引付けを行うことによって解決できます)。パフォーマンスの問題が発生しているが、etimesの値が小さい場合は、クライアント・アプリケーションに問題がある可能性が高くなります。

包括的な監視情報は、cn=monitorエントリにあります。詳細は、第29章「Oracle Unified Directoryの監視」を参照してください。Oracle Unified Directoryのパフォーマンスは、Enterprise Manager Grid Controlプラグインを使用して監視することもできます。詳細は、Oracle Unified Directory用システム監視プラグイン・ユーザーズ・ガイドを参照してください。

30.2 一般的なパフォーマンス・チューニング

パフォーマンス・チューニング戦略は、ディレクトリ・サーバーとプロキシ・サーバーのどちらを実行しているかによって異なります。

特定のデプロイメント・シナリオでは、次の項目によってパフォーマンスが向上する場合があります。

- Javaのバージョン。提供されているJava Runtime Environment (JRE)の最新リリースを使用します。Oracle Unified Directoryは、Java SE 6および7と連携して動作するように設計されています。

- 環境変数。サーバーはOPENDS_JAVA_HOME環境変数を使用して、インストール済のJREを指します。複数のバージョンのJavaがシステムにインストールされている場合は、目的のインストールのルートを指すようにJAVA_HOME環境変数を設定します。これにより、Oracle Unified Directoryではない他のアプリケーションが、JAVA_HOME変数によって指定されたバージョンのJREを使用できるようになります。
サーバー用のJREインストールを指定するには、次のいずれかを実行します:

- dsjavapropertiesコマンドを使用して、適切な環境変数を設定します。
詳細は、「dsjavaproperties」を参照してください。

- OPENDS_JAVA_BIN環境変数を(JAVAのバイナリ・パスを使用して)設定します。

- OPENDS_JAVA_HOME環境変数を(JAVAのインストール・パスを使用して)設定します。

30.3 Java仮想マシン設定のチューニング

JAVA_ARGS環境変数を使用して、JVMに渡すことができるグローバル構成引数を提供するか、java.propertiesファイルを使用できます。javaコマンドで使用できる引数はすべて、どちらの方法でも使用できます。

最適なパフォーマンスを実現するためにJVMをチューニングして、Oracle Unified Directoryアプリケーションを強固かつ応答を早くすることをお薦めします。ヒープ・サイズをチューニングすることによってJVMをチューニングできます。ヒープ・サイズは、次のように分割されます:

- 若い世代: PDUやローカル変数などの操作を含みます。

- 古い世代: JEデータベース・キャッシュやエントリ・キャッシュなどのOracle Unified Directoryキャッシュを含みます。

- 永続世代: 定数およびクラスを含みます。

Oracle Unified Directoryがディレクトリ・サーバー・モードの場合、次のデータベース・キャッシュ・オプションのいずれかを実行できます:

- データベース・キャッシュのデータベース全体をキャッシュします。これによって最適なパフォーマンスが与えられますが、キャッシュ・ウォームアップが長くなり、ヒープ・サイズが大きくなります。

- データベース・キャッシュでデータベースのBツリー(上位ノードおよび内部ノード)の内部ノードのみをキャッシュし、残りのRAMをファイル・システム・キャッシュ用に保持します。これによってパフォーマンスが向上し、ウォームアップが短くなり、ヒープ・サイズが小さくなります。非常に大きいデプロイ(50MBytesエントリ超)用にお薦めします。小規模および中規模のデプロイにお薦めします。

詳細は、第30.4項「データベース・キャッシュ・サイズの決定」を参照してください。

注意:

プロキシ・モードでは、グローバル索引を使用した配布に大きい古い世代を使用します。

詳細は、「dsjavaproperties」を参照してください。

JVMのチューニングに関する追加情報は、Javaパフォーマンスのドキュメント(http://java.sun.com/docs/performance/)を参照してください。Javaチューニングのホワイト・ペーパー(http://java.sun.com/performance/reference/whitepapers/tuning.html)およびガベージ・コレクションのチューニング(http://www.oracle.com/technetwork/java/javase/tech/index-jsp-136373.html)のドキュメントが特に役に立ちます。

次の表では、主なJVMチューニング可能オプションについて説明します。

パラメータ

説明

-server

常にクライアントJVMではなくサーバーJVMを使用します。クライアントVMは、実行時間が短いプロセス用に最適化されているため、できるかぎり迅速に起動する必要があります。サーバーVMはウォームアップに時間がかかりますが、長い目で見れば高速です。

-d32または-d64

次のように、32ビットまたは64ビット・バージョンのJVMを選択します:

- -d32を指定すると、JVMヒープのサイズが3.5GBよりも小さい場合、パフォーマンスが向上します。

- -XX:+UseCompressedOopsは、JVMヒープのサイズが3.5GBから31GBの場合に指定します。

- -d64は、JVMヒープのサイズが32GB以上の場合に指定します。

-XX:+UseCompressedOops

このオプションは、64ビットのJVMを使用し、ヒープ・サイズが32GB未満の場合に使用します。

-Xms2gおよび-Xmx2g

このパラメータによって、JVMで使用できる初期ヒープ・サイズおよび最大ヒープ・サイズが設定されます。ヒープ・サイズを増やすとパフォーマンスが向上する場合がありますが、設定した値が大きすぎる場合、フル・ガベージ・コレクションを実行するための一時停止時間が長くなるという悪影響が生じる可能性があります。通常、初期サイズおよび最大サイズは同じ値に設定する必要があります。

パフォーマンスを最大化するには、DB全体をメモリー内にキャッシュできるようにヒープのサイズを設定します。通常は、サーバーの実行に必要なヒープを割り当て、残りをDBキャッシュに割り当てます。

たとえば、Oracle Unified Directoryインスタンスのヒープ・サイズをuserRootという1つのみのJEバックエンドを使用して変更する場合です。新しい世代、古い世代および永続世代に必要な領域を決定する必要があります。異なる世代のサイズを設定するには、次のことを考慮する必要があります:

- 古い世代に影響を与えるデータベースのサイズ

- 古い世代に影響を与えるエントリ・キャッシュを使用する必要性の判断。

- 古い世代に影響を与える、使用されるGCのタイプ。

- 新しい世代に影響を与える使用量のタイプ。

CMSを古い世代のガベージ・コレクタとして使用する場合、ヒープ・サイズを計算するときに、DBキャッシュによって占有されるサイズ(またはヒープの割合)と整合がとれるよう、-XX:CMSInitiatingOccupancyFractionプロパティを考慮する必要があります。

CMSInitiatingOccupancyFractionを55に設定する場合、DBキャッシュの割合は50に設定する必要があります。また、10GBのディスク上にデータベースがある場合、データベース全体をDBキャッシュ内に収めるには、22GB以上のヒープが必要になります。

-XX:NewSize=512M

ヒープ領域全体は、古い世代と若い世代に分かれます。このパラメータによって、若い世代のサイズが設定されます。残りのメモリー(古い世代)に対しては、DBキャッシュに加えて、若干のオーバーヘッドを保持できるだけのサイズを確保する必要があります。

-XX:+UseConcMarkSweepGC

並行Mark Sweep (CMS)ガベージ・コレクタを使用します。このオプションを使用すると、JVMにおけるLDAP操作のレスポンス時間を最小化できますが、サーバーの全体的なパフォーマンス(スループット)に若干の影響を与える可能性があります。一時停止時間が長くなることを許容できない場合は、このオプションを使用してください。

-XX:CMSInitiatingOccupancyFraction=<percentage>

CMSガベージ・コレクションが開始されるレベルを指定します。デフォルト値は約68%です。デフォルト値以外の割合を設定する場合は、この値を使用してください。

-XX:+UseBiasedLocking

競合があまり発生しないことが予想される場合に、サーバー内で発生するロックのパフォーマンスを向上させます。

-XX:LargePageSizeInBytes=256m

メモリー内に格納する情報に対して、サイズの大きいページを使用します。この引数は主に、UltraSPARC T1プロセッサを使用するシステムに適用されます。

-XX:+UseParallelGC

多数のCPUを持つシステムにおいて特に便利なパラレル・ガベージ・コレクションをシステムが使用する必要があることを指定します。

-XX:+UseParallelOldGC

JVMが古い世代に対してパラレル・ガベージ・コレクションを使用する必要があることを指定します。

-XX:ParallelGCThreads=8

パラレル・ガベージ・コレクション実行時にJVMが8個のスレッドを使用する必要があることを指定します。デフォルトは、CPU数と同じ数のスレッドを使用することですが、非常に多数のCPUがあるシステムまたはCMTベースのシステム(UltraSPARC T1プロセッサを使用するシステムなど)ではこれが不適切である可能性があります。

30.4 データベース・キャッシュ・サイズの決定

Oracle Unified Directoryインスタンスをインストールまたは構成して初期化した場合、<OUD_INSTANCE_DIR>/OUD/db/userRootディレクトリのサイズを測定することによって、データベース・キャッシュ・サイズの要件を決定できます(Oracle Unified DirectoryインスタンスのデータベースがuserRootというデータベース1つのみであることが前提)。

Oracle Unified Directoryインスタンスが構成または初期化されていない場合、DbCacheSizeユーティリティ(com.sleepycat.je.util)を使用して、1つの索引ファイルまたはユーザー・データを含むファイルの内部ノードを格納するために必要なメモリーを決定できます。

DbCacheSizeユーティリティの使用法の詳細は、このJavadocページ(http://docs.oracle.com/cd/E17277_02/html/java/com/sleepycat/je/util/DbCacheSize.html)を参照してください。

たとえば、10バイトの索引および平均キー・サイズを備えた4KBの1000万エントリは次のようになります:

[oud@oel5 bin]$ java -jar -XX:+UseCompressedOops /space/Middleware/Oracle_OUD1/lib/je.jar DbCacheSize -records 10000000 -key 10 -data 4000

=== Database Cache Size ===
Minimum Bytes    Maximum Bytes   Description
---------------  ---------------  -----------
259,725,752      317,907,896  Internal nodes only
40,721,011,192   40,779,193,336  Internal nodes and leaf nodes
=== Internal Node Usage by Btree Level ===
Minimum Bytes    Maximum Bytes      Nodes    Level
---------------  ---------------  ----------  -----
256,180,800      313,709,120     112,360    1
3,503,312        4,149,456       1,262    2
38,864           46,032          14    3
2,776            3,288           1    4

4KBの1000万エントリのデプロイでは、データベース・キャッシュにフル・ユーザー・データを格納するために37GBが必要です(4KBエントリおよびデータベースのBツリーの内部ノード)。データベース・キャッシュに内部ノードのみを格納する場合、索引ごとに303MBが必要です(10索引では3GB)。

30.5 サーバー構成のチューニング

サーバーの様々なコンポーネントをチューニングして、特定のシナリオにおけるパフォーマンスを改善できます。パフォーマンスのチューニングに関する推奨事項のほとんどは、予想されるワークロード、格納されるデータのタイプ、使用可能なハードウェアとリソースなど、いくつかの可変要素に依存します。

チューニングに関する次の一般的な推奨事項によって、特定のデプロイメントにおけるパフォーマンスを改善できます。

30.5.1 バックエンドのチューニング・パラメータ

次のBerkeley DB JEチューニング・パラメータを使用して、パフォーマンスをチューニングできます:

パラメータ

説明

je.checkpointer.highPriority

trueの場合、チェックポインタでは、短い間隔でチェックポイントを完了するために、より多くのリソースが使用されます。Bツリーのラッチは保持され、他のスレッドはより長い期間ブロックされます。ログ・クリーナ・レコードの移行は、削除中およびチェックポイント中にゆっくり実行される(CLEANER_LAZY_MIGRATIONを参照)のではなく、クリーナ・スレッドによって実行されます。trueに設定された場合、チェックポイント中のアプリケーションのレスポンス時間が長くなり、構成済ログの使用率を維持するために、より多くのクリーナ・スレッドが必要になる場合があります。

このプロパティをfalseに設定すると、スループットが向上し、レスポンス時間が短縮されます。

preload-time-limit

起動時にデータベースの内容をメモリー内に事前ロードするようにサーバーを構成できます。データベースのサイズが大きい場合、データベース・キャッシュを事前ロードすることによって、サーバー起動後のウォームアップ時間を短縮できます。詳細は、Oracle Unified Directory構成リファレンスのローカルDBバックエンド構成に関する項を参照してください。

db-cache-percent and

db-cache-size

これらのプロパティを使用して、データベース・キャッシュが使用するメモリー量を構成します。最高のパフォーマンスを得るためには、データベース全体がデータベース・キャッシュに収まるようにサーバーを構成することを考慮します。

インポート後にデータベースのおよそのサイズを判定します。たとえば、userRootバックエンドへのインポートを行った後、次のコマンドを(UNIXシステム上で)実行してデータベースのサイズを確認します:

$ cd INSTANCE_DIR/OUD/db
$ du -sk userRoot/
910616 userRoot/

Windowsシステム上では、同等の手順を使用してデータベースのサイズを確認します。データベースのサイズは静的ではなく、変更が加えられたときの最初のインポート後に増加する場合があります。

JVMヒープを2GBに設定し(-Xms2g -Xmx2g)、db-cache-percentを50に設定すると、DBキャッシュで1GBのメモリーが使用されます。DBキャッシュ・サイズを監視するには、JtraceおよびJMXを使用して、"dn:cn=userRoot Database Environment,cn=monitor"エントリの下にある次のプロパティを確認します:

- EnvironmentCacheDataBytesがDBキャッシュの予期されるサイズと整合性のある値になっていることを確認します。

- EnvironmentNCacheMissが、サーバーをロードするときに予期しない増大が発生しないことを確認します。

レプリケーション・メタデータ、ユーザーおよびアプリケーションのために、データベースは時間の経過とともに非常に大きくなります。これは、インポート後のパフォーマンスに影響する場合があります。Oracle Unified DirectoryのJVMヒープ・サイズ(主に古い世代)をチューニングすることをお薦めします。

db-directory

十分なサイズのストレージを備えた高速なファイル・システム上でデータベースを保持します。このファイル・システムとは異なる場所にアクセス・ログを配置する必要があります。デフォルトでは、データベースのサイズは元の2倍になります。たとえば、インポート後のデータベースのサイズが1GBである場合、ファイル・システムでは2GB以上が使用可能になっている必要があります。

db-evictor-lru-only

このプロパティを使用して、データベース・キャッシュによる情報の保持方法を制御できます。この値をfalseに設定すると、内部ノードがキャッシュ内で保持されるため、JEキャッシュによって保持されるデータベースの内容の割合が低い場合のみ、パフォーマンスが向上します。

db-txn-durability

このプロパティを使用して、書込み操作の永続性を構成します。永続性が低下すると、書込みのパフォーマンスは向上する場合がありますが、JVMやシステムのクラッシュ時にデータが失われる可能性が高くなります。このプロパティの値は、次のいずれかです:

- write-to-disk。すべてのデータが同期的にディスクに書き込まれます。

- write-to-fs。データはすぐにファイル・システムに書き込まれますが、ディスクにフラッシュされるまでファイル・システム内に留まる場合があります。

- write-to-cache。データは内部バッファに書き込まれ、ファイル・システムにフラッシュされた後、必要な場合はディスクにフラッシュされます。

db-log-file-max

このプロパティを使用して、JEログ・ファイルのサイズを制御します。ファイル・サイズを増やすと書込みのパフォーマンスが向上する場合がありますが、目標とする使用率の維持がより難しくなる可能性があります。

db-num-cleaner-threads

およびdb-cleaner-min-utilization

これらのプロパティは、クリーナの動作を制御することによって、データベース・サイズの増加を抑え、書込みの高いスループットを維持します。

db-num-lock-tables

多くのCPUを搭載したシステムでは、このプロパティによってデータベース・ロック・マネージャ内の同時実行性が向上する場合があります。

30.5.2 コア・サーバーのチューニング・パラメータ

次に示すコア・サーバーのチューニング・パラメータを使用して、パフォーマンスをチューニングできます:

- num-request-handlers
このプロパティを構成して、LDAP接続ハンドラで(有効になっている場合はLDAPS接続ハンドラでも)クライアント・リクエストのデコードに複数のスレッドを使用できます。多くのCPUを搭載したシステムでスレッド数を増やすと、パフォーマンスが向上する場合があります。大まかに言えば、このプロパティはCPU数の4分の1(最大値は12)に設定する必要があります。

keep-statsプロパティを無効にすると、接続ハンドラのロック競合が減少する場合があります。詳細は、Oracle Unified Directory構成リファレンスのLDAP接続ハンドラ構成に関する項を参照してください。

- num-worker-threads
このプロパティのデフォルト値は、CPU数の2倍です。ほとんどのデプロイメントには、この値で十分です。

- log-file
アクセス・ログのパブリッシャを高速ファイル・システム上に配置するか、enabledプロパティをfalseに設定して完全に無効にします。詳細は、Oracle Unified Directory構成リファレンスのファイル・ベース・アクセス・ログ・パブリッシャ構成に関する項を参照してください。

30.5.3 追加のチューニング推奨事項

次に示す追加の推奨事項によって、特定のシナリオにおけるパフォーマンスが向上する場合があります。

- エントリ・キャッシュの有効化。エントリ・キャッシュの有効化は、特にディレクトリのサイズが比較的小さい場合(たとえば、数十万エントリまで)に役立ちます。通常は、ソフト参照のエントリ・キャッシュよりもFIFOのエントリ・キャッシュの方が優れた結果を提供します。詳細は、Oracle Unified Directory構成リファレンスのエントリ・キャッシュ構成に関する項を参照してください。
大規模なデータベースの場合は、include-filterプロパティを使用して、特定のデータ・セットのみをキャッシュ内に格納することをお薦めします。静的グループをエントリ・キャッシュ内に格納すると、サーバーの全体的なパフォーマンスが大幅に向上する可能性があります。これにより、ACIの評価などで必要になるグループ・メンバーシップ参照の実行時間が短縮されます。

- 使用されていない仮想属性の無効化。1つ以上の仮想属性によって使用される機能が不要な場合、それらを無効にすると、エントリのデコード時のパフォーマンスが若干向上する可能性があります。詳細は、Oracle Unified Directory構成リファレンスの仮想属性構成に関する項を参照してください。

- 使用されていないアクセス・ロギングの無効化。アクセス・ロギングが不要な場合、サーバーのアクセス・ロガーを無効にすると、パフォーマンスが向上する可能性があります。詳細は、Oracle Unified Directory構成リファレンスのログ・パブリッシャ構成に関する項を参照してください。

- 使用されていないアクセス制御ハンドラの無効化。サーバー内のアクセス制御処理が不要な場合は、アクセス制御ハンドラのenabled構成プロパティをfalseに設定することによって、ハンドラを無効にできます。このプロパティはdsconfigを使用して設定できます。

- ロック競合の削減。多くのCPUが搭載されたシステム(たとえば、コアごとにいくつかのハードウェア・スレッドを提供するチップマルチスレッド化(CMT)システム)では、org.opends.server.LockManagerConcurrencyLevelシステム・プロパティを、使用するワーカー・スレッドと同じ数に設定することによって、ロック競合を削減できます。

注意:

このプロパティは、サーバー起動プロセスの非常に早い段階(サーバー構成へのアクセスよりも前)で必要になるため、JVMシステム・プロパティとして設定する必要があります。

A Oracle Unified Directoryコマンドライン・インタフェース

Oracle Unified Directoryには、ディレクトリ・サーバーおよびプロキシ・サーバーとの連携に使用される多数のコマンドライン・ユーティリティが組み込まれています。また、レプリケーション・ゲートウェイを使用するマルチ・バージョンのトポロジに含まれるようにサーバーを準備するためのユーティリティも用意されています。

この付録では、Oracle Unified Directory 11gリリース2 (11.1.2)で提供されるすべてのコマンドについて説明します。これらのコマンドのなかには、ディレクトリ・サーバー・インスタンスに固有であって、プロキシ・サーバーの構成には使用できないものがあります。同様に、多数のコマンドはプロキシに固有であり、ディレクトリ・サーバーの構成には使用できません。

ここで説明する項目は、次のとおりです:

- 第A.1項「一般的なコマンドラインの使用方法に関する情報」

- 第A.2項「サーバー管理コマンド」

- 第A.3項「データ管理コマンド」

- 第A.4項「LDAPクライアント・コマンド」

A.1 一般的なコマンドラインの使用方法に関する情報

次の各項では、コマンドの一般的な使用方法について説明します:

- 第A.1.1項「サーバー・コマンドとその使用のサマリー」

- 第A.1.2項「サーバー・コマンドによるプロパティ・ファイルの使用方法」

A.1.1 サーバー・コマンドとその使用のサマリー

この項の各表は、サーバー・コマンドとその使用方法のサマリーを示しています。表で使用する凡例は次のとおりです:

リモート

コマンドはリモート・サーバーで起動できます。

オフライン

コマンドはサーバーが停止しているときに起動できます。

オンライン

コマンドは実行中のサーバー・インスタンスに接続しています。

管理ポートのみ

コマンドは、管理コネクタを使用してサーバー(デフォルトでは、ポート4444にあります)にアクセスする必要があります。

注意:

以降の各表に示すすべてのコマンドがプロキシ・サーバー・インスタンス用にサポートされているわけではありません。

表A-1 サーバー管理コマンド

コマンド

リモート

オフライン

オンライン

管理コネクタ

create-rc-script

dsconfig

X

X

X

dsjavaproperties

X

dsreplication

X

X

X

gicadm

X

X

X

oudExtractMovePlan

X

X

oudCopyConfig

X

X

oudPasteConfig

X

start-ds

X

status

X

X

X

X

stop-ds

X

X

X

uninstall

X

X

X

upgrade

X

windows-service

X

表A-2 データ管理コマンド

コマンド

リモート

オフライン

オンライン

管理コネクタ

backup

X *

X

X

X

base64

X

dbtest

X

encode-password

X

export-ldif

X *

X

X

X

import-ldif

X *

X

X

X

ldapcompare

X

X

ldapdelete

X

X

ldapmodify

X

X

ldappasswordmodify

X

X

ldapsearch

X

X

ldif-diff

X

ldifmodify

X

ldifsearch

X

list-backends

X

make-ldif

X

manage-account

X

X

X

manage-tasks

X

X

X

rebuild-index

X

restore

X *

X

X

X

split-ldif

X

X

verify-index

X

* このコマンドはリモートに起動できますが、データ・ファイルはサーバーが実行しているホスト上にある必要があります。

A.1.2 サーバー・コマンドによるプロパティ・ファイルの使用方法

特定のコマンドライン・ユーティリティは、コマンド・プロパティ・ファイルを使用して、次のようなオプションにデフォルト値を指定できます:

- サーバーのホスト名およびポート番号

- サーバーとの通信にSSLまたはStartTLSを使用するかどうか

- サーバーへの接続時に使用するバインドDN

次のユーティリティはプロパティ・ファイルを使用できます:

- backup

- dsconfig

- dsreplication

- export-ldif

- gicadm

- import-ldif

- split-ldif

- ldapcompare

- ldapdelete

- ldapmodify

- ldappasswordmodify

- ldapsearch

- manage-tasks

- oud-setup

- oud-proxy-setup

- oud-replication-gateway-setup

- restore

- status

- stop-ds

- uninstall

次の相互に排他的なオプションは、プロパティ・ファイルが使用されているかどうかを示すためにコマンドライン・ユーティリティとともに使用します:

--propertiesFilePath path

コマンドライン・オプションのデフォルト値が含まれているファイルへのパスを指定します。

--noPropertiesFile

コマンドライン・オプションのデフォルト値の取得にプロパティ・ファイルが使用されていないことを示します。

A.1.2.1 プロパティ・ファイルの検索

共通のプロパティ・ファイルを使用するユーティリティには、次のデフォルトの動作が設定されています:

- --noPropertiesFileオプションを指定した場合、コマンドライン・インタフェースはプロパティ・ファイルの検索を試行しません。コマンドラインで指定されたオプションのみが評価されます。

- --propertiesFilePathオプションを指定した場合、プロパティ値はこのファイルから読み取られます。

- --propertiesFilePathと--noPropertiesFileがどちらも指定されなかった場合、コマンドライン・インタフェースは次の場所でプロパティ・ファイルの検索を試行します:

- USERDIRECTORY/.opends/tools.properties

- INSTANCE_DIR/OUD/config/tools.properties

- このいずれの場所でもプロパティ・ファイルが見つからなかった場合は、デフォルト動作が適用されます(コマンドラインで指定された引数のみが評価されます)。

A.1.2.2 オプションおよびプロパティの優先順位

オプションがコマンドラインで指定された場合、そのオプションとそれに対応する値がコマンドライン・インタフェースによって使用されます。つまり、コマンドラインで指定されたオプションが、プロパティ・ファイルで定義されたプロパティよりも優先されます。

プロパティ・ファイルは標準のJAVAプロパティ・ファイルの形式(property-name=value)を使用します。そのため、このファイルはプロパティ名のバリエーションをサポートしており、プロパティ名を使用するコマンドに従ってプロパティ名がオーバーライドできるようにします。たとえば、プロパティ・ファイルには次の内容を含めることができます:

hostname=localhost
port=4444
bindDN=cn=Directory Manager
bindPasswordFile=/path/pwd-file
baseDN=dc=example,dc=com
searchScope=sub
sortOrder=givenName
virtualListView=0:2:1:0

コマンドライン・インタフェースでportプロパティを使用している場合は、まずtoolname.port定義の検索を試みます。これが定義されていない場合は、port定義の検索を試みます。たとえば、プロパティ・ファイルには、様々なユーティリティに定義されている次のような複数のポート・オプションを設定することもできます:

port=4444
ldapsearch.port=1389
ldapcompare.port=1389
ldapmodify.port=1389
ldapdelete.port=1389

注意:

プロパティ・ファイルでは、値の前後に引用符を使用しないでください(例: port="4444")。

A.2 サーバー管理コマンド

次の各項では、サーバー管理コマンドについて説明します:

- 第A.2.1項「create-rc-script」

- 第A.2.2項「dps2oud」

- 第A.2.3,項「ds2oud」

- 第A.2.4項「dsconfig」

- 第A.2.5項「dsjavaproperties」

- 第A.2.6項「dsreplication」

- 第A.2.7項「gicadm」

- 第A.2.8項「manage-tasks」

- 第A.2.9項「oudCopyConfig」

- 第A.2.10項「oudExtractMovePlan」

- 第A.2.11項「oudPasteConfig」

- 第A.2.12項「oud-replication-gateway-setup」

- 第A.2.13項「oud-setup」

- 第A.2.14項「oud-proxy-setup」

- 第A.2.15項「start-ds」

- 第A.2.16項「status」

- 第A.2.17項「stop-ds」

- 第A.2.18項「uninstall」

- 第A.2.19項「windows-service」

A.2.1 create-rc-script

create-rc-scriptコマンドは、ディレクトリ・サーバーを起動、停止、および再起動するシェル・スクリプトを生成します。

A.2.1.1 シノプシス

create-rc-script [options]

A.2.1.2 説明

create-rc-scriptコマンドは、ディレクトリ・サーバーを起動、停止、および再起動するシェル・スクリプトの生成に使用できます。ディレクトリ・サービスのニーズに適合するように結果のスクリプトを更新できます。このコマンドは、UNIXシステムまたはLinuxシステムのみで使用できます。

create-rc-scriptコマンドは、OPENDS_JAVA_*変数とJAVA_*変数を使用します。

A.2.1.3 オプション

create-rc-scriptコマンドは、短いフォーム(例: -f filename)または同等の長いフォーム(例: --outputFile filename)のいずれかのオプションを受け入れます。

-f, --outputFile filename

出力ファイルへのパスを指定します。

-j, --javaHome javaHomePath

サーバーの実行に使用する必要のあるJavaインストールへのパスを指定します。

-J, --javaArgs javaArgs

サーバーを実行するときにJVMに渡す必要のある引数のセットを指定します。

-u, --userName userName

サーバーの実行に必要なユーザー・アカウントの名前を指定します。ユーザー・アカウントは、スクリプトを実行するために適切な権限を持っている必要があります。

A.2.1.4 一般オプション

--version

ディレクトリ・サーバーのバージョン情報を表示します。

-?, -H, --help

create-rc-scriptコマンドのコマンドライン使用情報を表示します。

A.2.1.5 例

次の例は、create-rc-scriptコマンドの使用方法を示しています。

例A-1 スクリプトの作成

次のコマンドは、ディレクトリ・サーバーを起動、停止、および再起動するスクリプトを生成します。-fオプションによって指定されたmyscriptというファイルが作成されます:

$ create-rc-script -f myscript

例A-2 新規スクリプトを使用したディレクトリ・サーバーの起動

次のコマンドでは、ディレクトリ・サーバーを起動するために、新しく作成されたスクリプト(前の例を参照)を使用しています。

$ myscript start

例A-3 新規スクリプトを使用したディレクトリ・サーバーの停止

次のコマンドでは、ディレクトリ・サーバーを停止するために、新しく作成されたスクリプト(最初の例を参照)を使用しています。

$ myscript stop

例A-4 新規スクリプトを使用したディレクトリ・サーバーの再起動

次のコマンドでは、ディレクトリ・サーバーを再起動するために、新しく作成されたスクリプト(最初の例を参照)を使用しています。

$ myscript restart

例A-5 スクリプトでのJAVA_HOMEおよびJAVA_ARGSの指定

次のコマンドは、-u (--userName), -j (--javaHome)オプションおよび-J (--javaArgs)オプションを使用しています。

$ create-rc-script -f myscript -u sysAdmin -j /usr/java -J "-Xms128m -Xmx128m"

A.2.1.6 create-rc-scriptコマンドにより生成されるコード

上記の例のcreate-rc-scriptコマンドにより、次のコードが生成されます:

# /bin/sh
#
# CDDL HEADER START
#
# The contents of this file are subject to the terms of the
# Common Development and Distribution License, Version 1.0 only
# (the "License").  You may not use this file except in compliance
# with the License.
#
# You can obtain a copy of the license at
# https://OpenDS.dev.java.net/OpenDS.LICENSE.
# See the License for the specific language governing permissions
# and limitations under the License.
#
# When distributing Covered Code, include this CDDL HEADER in each
# file and include the License file at
# trunk/opends/resource/legal-notices/OpenDS.LICENSE.  If applicable,
# add the following below this CDDL HEADER, with the fields enclosed
# by brackets "[]" replaced with your own identifying information:
#      Portions Copyright [yyyy] [name of copyright owner]
#
# CDDL HEADER END

# Set the path to the OpenDS instance to manage
INSTANCE_ROOT="/usr/local/opends/standalone/ds-server-1"
export INSTANCE_ROOT

# Specify the path to the Java installation to use
OPENDS_JAVA_HOME="/usr/java"
export OPENDS_JAVA_HOME

# Specify arguments that should be provided to the JVM
JAVA_ARGS="-Xms128m -Xmx128m"
export JAVA_ARGS

# Determine what action should be performed on the server
case "${1}" in
start)
/bin/su sysAdmin "${INSTANCE_ROOT}/bin/start-ds" --quiet
exit ${?}
;;
stop)
/bin/su sysAdmin "${INSTANCE_ROOT}/bin/stop-ds" --quiet
exit ${?}
;;
restart)
/bin/su sysAdmin "${INSTANCE_ROOT}/bin/stop-ds" --restart --quiet
exit ${?}
;;
*)

echo "Usage:  $0 { start | stop | restart }"
exit 1
;;
esac

A.2.1.7 終了コード

終了コード0は成功を示します。ゼロ以外の終了コードは、エラーが発生したことを示します。

A.2.1.8 場所

create-rc-scriptコマンドは、次のパスに置かれています:

UNIXおよびLinux: INSTANCE_DIR/OUD/bin

A.2.1.9 関連コマンド

第A.2.15項「start-ds」

第A.2.17項「stop-ds」

A.2.2 dps2oud

dps2oudコマンドによって、ディレクトリ・プロキシ・サーバー(DPS)構成をOracle Unified Directory構成に移行できます。

A.2.2.1 シノプシス

dps2oud [options]

A.2.2.2 説明

dps2oudコマンドによって、DPS構成をOracle Unified Directory構成に移行できます。dps2oudコマンドはDPS構成を入力として取り込み、同等のOracle Unified Directory構成の作成に使用されるdsconfigコマンドからなるバッチ・ファイルを生成します。dps2oudコマンドは、ファイルから、または実行中のDPSインスタンス上のLDAPプロトコルを通してDPS構成を読み取ります。

A.2.2.3 オプション

dps2oudコマンドは、次のオプションを受け入れます。

-o, --outputFile file

dsconfigコマンドの出力ファイル。

-f, --dpsConfigFile file

使用するDPS構成ファイルの名前を指定します。

-c, --createDisabledObjects

Creates DPSで無効なオブジェクトを作成します。

-P, --printDsConfigCmds

dsconfigコマンドを印刷します。

A.2.2.4 LDAP接続オプション

-h, --hostname host

DPSサーバーのホスト名またはIPアドレス。

-j, --bindPasswordFile filename

バインド・パスワードが含まれているファイルへのフルパス。

-p, --port port

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

-D, --BindDN bindDN

DPSサーバーへのバインドに使用するDN。

A.2.2.5 一般オプション

-?, -H, --help

このコマンドに対するコマンドライン使用情報を表示し、ディレクトリ・サーバーの停止または再起動を試行しないで終了します。

-V, --version

ディレクトリ・サーバーのバージョン情報を表示します。

A.2.2.6 例

次の例は、dps2oudコマンドの使用方法を示しています。

例A-6 グローバル・ヘルプ・サブコマンドの表示

次のコマンドは、使用可能なグローバル・ヘルプ・サブコマンドを表示します:

$ dps2oud --help

例A-7 ディレクトリ・プロキシ・サーバー構成のOracle Unified Directory構成への移行

DPS構成をOracle Unified Directory構成に移行するには、次の方法のいずれかが使用できます:

方法1: DPS構成をLDIFファイルから読み取る

次のコマンドは、DPS構成をLDIFファイルから読み取る方法を表示します:

$ dps2oud -f dse.ldif -o oud_conf_cmds

次のコマンドは、実行される一連のdsconfigコマンドが含まれているバッチ・ファイルへのパスを指定します:

$ dsconfig -F oud_conf_cmds

方法2: DPS構成を実行中のDPSインスタンスから読み取る

次のコマンドは、DPS構成をDPSインスタンスから読み取る方法を表示します:

$ dps2oud -h dpsHost -p 389 -D "cn=Proxy Manager"  -j /path/pwd-file -o oud_conf_cmds

次のコマンドは、実行される一連のdsconfigコマンドが含まれているバッチ・ファイルへのパスを指定します:

$ dsconfig -F oud_conf_cmds

A.2.2.7 終了コード

終了コード0は、操作が正常に終了したことを示します。ゼロ以外の終了コードは、処理中にエラーが発生したことを示します。

A.2.2.8 場所

- UNIXおよびLinux: INSTANCE_DIR/OUD/bin/dps2oud

- Windows: INSTANCE_DIR\OUD\bat\dps2oud.bat

A.2.2.9 関連コマンド

第A.2.4項「dsconfig」

A.2.3 ds2oud

ds2oudコマンドは、Oracle Directory Server Enterprise Editionディレクトリ・サーバー・インスタンスからOracle Unified Directoryへの移行を管理します。

A.2.3.1 シノプシス

ds2oud [options]

A.2.3.2 説明

ds2oudコマンドにより、Oracle Directory Server Enterprise Editionディレクトリ・サーバー・インスタンスからOracle Unified Directoryへの移行を管理できます。ds2oudコマンドでは、まず、対象となるOracle Directory Server Enterprise Editionディレクトリ・サーバー・インスタンスの診断を許可したあとで、移行タスクを実行します。これは、既存のOracle Unified Directoryインスタンスが、移行されるOracle Directory Server Enterprise Editionディレクトリ・サーバーと互換性を持つように変更されることを前提としています。ds2oudコマンドは、オプションを指定しない場合はインタラクティブ・モードで実行します。インタラクティブ・モードは、移行のすべての局面を1つずつ実行するウィザードのように機能します。

また、ds2oudコマンドはバッチ・モードでも実行できます。バッチ・モードでは、dsconfigコマンドで構成されるバッチ・ファイルが生成されます。これらのコマンドは、同等のOracle Unified Directory構成の作成に使用されます。したがって、ds2oudを1回実行すると、1つのバッチ・ファイルを作成し、それを使用してOracle Unified Directoryインスタンスをいくつでも構成できます。

ds2oudコマンドを実行する際、(Oracle Directory Server Enterprise Editionインスタンスの移行先である)Oracle Unified Directoryインスタンスが接尾辞を使用せずに構成されていることを確認する必要があります。

A.2.3.3 オプション

ds2oudコマンドは、次のオプションを受け入れます。

-d, --diagnose

対象となるOracle Directory Server Enterprise Editionディレクトリ・サーバーを診断します。

-f, --ldifDBFile file

Oracle Directory Server Enterprise Editionディレクトリ・サーバーのLDIFデータベース・ファイルを診断します。

-u, --userSchemaFile file

考慮されるユーザー・スキーマを指定します。これは-fサブコマンドに適用されます。

-a, --migrateAll

スキーマと構成要素をOracle Directory Server Enterprise Editionディレクトリ・サーバーからOracle Unified Directoryサーバーへ伝播します。

-s, --migrateUserSchema

ユーザー・スキーマをOracle Directory Server Enterprise Editionディレクトリ・サーバーからOracle Unified Directoryサーバーへ伝播します。

スキーマの移行は、構成を移行する前に行う必要があります。そうしないと、移行によって予測できない結果がもたらされる可能性があるためです。

-c, --migrateConfiguration

構成要素をOracle Directory Server Enterprise Editionディレクトリ・サーバーからOracle Unified Directoryサーバーへ伝播します。

スキーマの移行は、構成を移行する前に行う必要があります。そうしないと、移行によって予測できない結果がもたらされる可能性があるためです。

-w, --uniqueWorkflowElement

移行するすべてのネーミング・コンテキストに対して一意のワークフロー要素を使用します。これは-cサブコマンドに適用されます。

A.2.3.4 Oracle Directory Server Enterprise EditionのLDAP接続オプション

-D, --odseeBindDN bindDN

Oracle Directory Server Enterprise Editionサーバーへのバインドに使用するDN。

-j, --odseeBindPasswordFile filename

Oracle Directory Server Enterprise Editionのバインド・パスワード・ファイル。

-h, --odseeHostname host

Oracle Directory Server Enterprise Editionサーバーのホスト名。デフォルトの値はlocalhostです。

-p, --odseePort port

Oracle Directory Server Enterprise Editionサーバーのポート番号。デフォルト値は389です。

-Z, --odseeUseSSL

Oracle Directory Server Enterprise EditionのSSL暗号化の接続を確立します。

-P, --odseeTrustStorePath trustStorePath

指定されたパスにOracle Directory Server Enterprise Editionのトラスト・ストア証明書を使用します。このオプションは、-Xを使用している場合は必要ありません。ただし、本番環境で作業する場合はトラスト・ストアを使用する必要があります。

-U, --odseeTrustStorePasswordFile filename

Oracle Directory Server Enterprise Editionのトラスト・ストアの証明書にアクセスするには、指定されたファイルでパスワードを使用します。このオプションは、--odseeTrustStorePathを使用していて、指定したトラスト・ストアがコンテンツへのアクセスにパスワードを必要とする場合のみ、必須です(ほとんどのトラスト・ストアでは必要とされません)。

-X, --odseeTrustAll

Oracle Directory Server Enterprise Editionサーバーによって提示されるすべての証明書を信頼します。このオプションはテストの目的で使用できますが、セキュリティ上の理由から、トラスト・ストアを使用してOracle Directory Server Enterprise Editionがサーバーの証明書を受け入れるかどうかを判別する必要があります。

A.2.3.5 Oracle Unified DirectoryのLDAP接続オプション

--oudBindDN bindDN

Oracle Unified Directoryサーバーへのバインドに使用するDN。

--oudBindPasswordFile filename

Oracle Unified Directoryのバインド・パスワード・ファイル。

--oudHostname host

Oracle Unified Directoryサーバーのホスト名。デフォルトの値はlocalhostです。

--oudPort port

Oracle Unified Directoryサーバーのポート番号。デフォルト値は389です。

--oudAdminPort port

Oracle Unified Directoryサーバーの管理ポート。デフォルト値は444です。

--oudUseSSL

Establishes an Oracle Unified DirectoryのSSL暗号化の接続を確立します。

--oudTrustStorePath trustStorePath

指定されたパスにOracle Unified Directoryのトラスト・ストア証明書を使用します。

--oudTrustStorePasswordFile filename

Oracle Unified Directoryのトラスト・ストアの証明書にアクセスするには、指定されたファイルでパスワードを使用します。このオプションは、--oudTrustStorePathを使用していて、指定したトラスト・ストアがコンテンツへのアクセスにパスワードを必要とする場合のみ必須です(ほとんどのトラスト・ストアでは必要とされません)。

--oudTrustAll

Oracle Unified Directoryサーバーによって提示されるすべての証明書を信頼します。このオプションはテストの目的で使用できますが、セキュリティ上の理由から、トラスト・ストアを使用してOracle Unified Directoryがサーバーの証明書を受け入れるかどうかを判別する必要があります。

A.2.3.6 コマンド入力/出力オプション

-n, --no-prompt

非インタラクティブ・モードを使用します。コマンドのデータが見つからない場合、ユーザーにはプロンプトが表示されず、ツールは失敗します。

-o, --outputFile filename

出力を指定した出力ファイルにリダイレクトします。

-F, --batchFilePath filename

このオプションは、構成を移行するために実行される一連のdsconfigコマンドが含まれている出力ファイルの名前を指定します。

このオプションを指定してds2oudを実行した場合、同等のOracle Unified Directory構成の作成に必要なすべてのdsconfigコマンドを含めたバッチ・ファイルが生成されます。したがって、ds2oudを1回実行すると、1つのバッチ・ファイルを作成し、それを使用してOracle Unified Directoryインスタンスをいくつでも構成できます。

--displayCommand

同等の非インタラクティブなdsconfigコマンドを表示します(Oracle Directory Server Enterprise Editionの構成パラメータを移行するため)。

A.2.3.7 一般オプション

-?, -H, --help

このコマンドに対するコマンドライン使用情報を表示し、ディレクトリ・サーバーの停止または再起動を試行しないで終了します。

-V, --version

ディレクトリ・サーバーのバージョン情報を表示します。

A.2.3.8 例

次の例は、ds2oudコマンドの使用方法を示しています。

例A-8 グローバル・ヘルプ・サブコマンドの表示

次のコマンドは、使用可能なグローバル・ヘルプ・サブコマンドを表示します:

$ ds2oud --help

例A-9 コマンドラインからのインタラクティブ・モードでのds2oudの実行

ds2oudコマンドはインタラクティブ・モードで実行できます。このモードでは、移行オプションに関してプロンプトが表示されます。ds2oudをインタラクティブ・モードで実行するには、次のコマンドを入力します:

$ ds2oud
What do you want to do ?

1)  Diagnose an ODSEE directory server instance
2)  Diagnose an ODSEE LDIF data file
3)  Migrate all ( user schema + configuration )
4)  Migrate the user schema
5)  Migrate global configuration parameters

c)  cancel

前のアクションごとに、まず、接続オプションをOracle Directory Server Enterprise Editionサーバーに対して指定するか(診断の場合)、Oracle Directory Server Enterprise EditionサーバーとOracle Unified Directoryサーバーの両方に対して指定する(移行の場合)必要があります。

例A-10 データ診断用のds2oudの実行

次のコマンドは、Oracle Directory Server Enterprise Editionディレクトリ・サーバーにあるデータを診断するために実行されます:

$ ds2oud -f odseeDataFile.ldif -u 99user.ldif

*******************************************************************************
* Diagnose ODSEE LDIF data file :  odseeDataFile.ldif
*******************************************************************************
The data were validated successfully regarding the OUD schema

例A-11 既存のOracle Directory Server Enterprise Edition構成のOracle Unified Directory構成への移行

次のコマンドを使用した既存のOracle Directory Server Enterprise Edition構成の新しいOracle Unified Directory構成への移行

次のコマンドは、既存のOracle Directory Server Enterprise Edition構成とスキーマを移行します:

$ ds2oud --migrateAll -D "cn=directory manager"
-j /tmp/pwd -h hostname -p ldapPort
--oudBindDN "cn=directory manager" --oudBindPasswordFile /tmp/pwd
--oudHostname hostname2 --oudPort ldapPort2 --oudAdminPort adminPort  -n

次のコマンドは、新しいOracle Unified Directory構成を作成するために実行される一連のdsconfigコマンドが含まれているバッチ・ファイルへのパスを指定します:

$ ds2oud --migrateConfiguration --batchFilePath batchFile
-D "cn=directory manager" -j /tmp/pwd -h hostname
-p ldapPort --oudBindDN "cn=directory manager"
--oudBindPasswordFile /tmp/pwd  --oudHostname hostname2
--oudPort ldapPort2 --oudAdminPort adminPort -n

A.2.3.9 終了コード

0

成功。

1

引数を初期化できません。

2

指定された引数が有効でないか、ユーザー・データのチェックでエラーが発生したため、引数を解析できません。

3

移行プロセスの少なくとも1つのステップが失敗しました。

4

ユーザーがインタラクティブ・モードで操作を取り消しました。

A.2.3.10 場所

- UNIXおよびLinux: INSTANCE_DIR/OUD/bin/ds2oud

- Windows: INSTANCE_DIR\OUD\bat\ds2oud.bat

A.2.3.11 関連コマンド

- 第A.2.4項「dsconfig」

A.2.4 dsconfig

dsconfigコマンドにより、Directory Serverの基本構成を定義できます。

A.2.4.1 シノプシス

dsconfig [subcommands] [Options]

A.2.4.2 説明

dsconfigコマンドにより、サーバー・インスタンスの基本構成を作成、管理、および削除できます。このサーバー構成は、dsconfigが1つ以上のサブコマンドを使用してアクセスできる一連のコンポーネントとして編成されます。すべてのコンポーネントには、ゼロ個以上の構成プロパティが割り当てられています。これらのプロパティに対して問合せを実行し、コンポーネントの動作を変更するように修正できます。

dsconfigコマンドは、管理コネクタを介してSSL上のサーバーにアクセスします(第14.3項「サーバーへの管理トラフィックの管理」で説明しています)。

すべての構成パラメータと-n (--no-prompt)オプションを指定した場合を除き、dsconfigはインタラクティブ・モードで実行します。インタラクティブ・モードは、サーバー構成のすべての局面を1つずつ実行するウィザードのように機能します。詳細は、第14.1.2項「インタラクティブ・モードでのdsconfigの使用」を参照してください。

A.2.4.3 ヘルプ・サブコマンド

dsconfigコマンドは、基本構成の管理に必要なコンポーネントのサブコマンドをリストしたヘルプ関数を指定します。

--help-distribution

分散に関連するサブコマンドを表示します。

--help-general-configuration

一般構成に関連するサブコマンドを表示します。

--help-load-balancing

ロード・バランシングに関連するサブコマンドを表示します。

--help-local-storage

ローカル記憶域に関連するサブコマンドを表示します。

--help-miscellaneous-workflow-elements

その他のワークフロー要素に関連するサブコマンドを表示します。

--help-remote-storage

リモート記憶域に関連するサブコマンドを表示します。

--help-replication

レプリケーションに関連するサブコマンドを表示します。

--help-schema

スキーマに関連するサブコマンドを表示します。

--help-security

認証および認可に関連するサブコマンドを表示します。

--help-virtualization

仮想化に関連するサブコマンドを表示します。

--help-all

すべてのサブコマンドを表示します。

A.2.4.4 一般サブコマンド

次のサブコマンドは、サーバー・インスタンスのオブジェクトとプロパティをリストします。

list-properties

管理対象のオブジェクトとプロパティを表示します。オプション・タイプは次のとおりです:

r — プロパティ値は読取り可能です。

w — プロパティ値は書込み可能です。

m — プロパティは必須です。

s — プロパティは単一値です。

a — 変更を有効にするには管理アクションが必要です。

サブオプションは次のとおりです:

-t, --type type。コンポーネント・タイプ。

-c, --category category。コンポーネントのカテゴリ。typeの値は、--categoryサブオプションを使用して指定されるcategoryに関連付けられたコンポーネント・タイプの1つである必要があります。

--inherited。コンポーネントの継承プロパティを表示するように表示出力を変更します。

--advanced。コンポーネントの拡張プロパティを表示するように表示出力を変更します。

--property property。表示されるプロパティの名前。

A.2.4.5 分散サブコマンド

次のサブコマンドにより、ディレクトリ・サーバーの基本構成を定義できます。

create-distribution-algorithm

分散アルゴリズムを作成します。サブオプションは次のとおりです:

--element-name name。分散ワークフロー要素の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t,--type type。作成する分散アルゴリズムのタイプ。typeの値には、capacity、dnpattern、generic、lexico、またはnumericのいずれかを指定できます。

create-distribution-partition

分散パーティションを作成します。サブオプションは次のとおりです:

--element-name name。分散ワークフロー要素の名前。

--partition-name name。新しい分散パーティションの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t,--type type。作成する分散パーティションのタイプ。typeの値には、capacity、dnpattern、generic、lexico、またはnumericのいずれかを指定できます。

create-workflow-element --type distribution

ワークフロー要素を作成します。サブオプションは次のとおりです:

--element-name name。新しいワークフロー要素の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t, --type type。作成するワークフロー要素のタイプ。typeの値には、ad-paging、backup-local-backend、db-local-backend,distribution、dn-renaming、eus、eus-context、fa、global-index-local-backend、global-index-replication-changes-local-backend、kerberos-auth-provider、ldif-local-backend、load-balancing、memory-local-backend、monitor-local-backend、null-local-backend、pass-through-authentication、plugin、proxy-ldap、rdn-changing、transformations、trust-store-local-backendのいずれかを指定できます。

create-global-index

グローバル索引を作成します。サブオプションは次のとおりです:

--extension-name name。グローバル索引カタログ拡張の名前。

--index-name name。新しいグローバル索引の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

create-extension --type global-index-catalog

拡張を作成します。サブオプションは次のとおりです:

--extension-name name。グローバル索引カタログ拡張の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t,--type type。作成する拡張のタイプ。タイプの値には、global-index-catalog、global-index-catalogs-shared-cache、ldap-serverのいずれかを指定できます。

create-global-index-catalog-replication-domain

グローバル索引カタログ・レプリケーション・ドメインを作成します。サブオプションは次のとおりです:

--extension-name name。グローバル索引カタログ拡張の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

create-extension --type global-index-catalogs-shared-cache

拡張を作成します。サブオプションは次のとおりです:

--extension-name name。新しい拡張の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t,--type type。作成する拡張のタイプ。typeの値には、global-index-catalog、global-index-catalogs-shared-cache、ldap-serverのいずれかを指定できます。

create-workflow-element --type global-index-local-backend

ワークフロー要素を作成します。サブオプションは次のとおりです:

--element-name name。新しいワークフロー要素の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t, --type type。作成するワークフロー要素のタイプ。typeの値には、ad-paging、backup-local-backend、db-local-backend,distribution、dn-renaming、eus、eus-context、fa、global-index-local-backend、global-index-replication-changes-local-backend、kerberos-auth-provider、ldif-local-backend、load-balancing、memory-local-backend、monitor-local-backend、null-local-backend、pass-through-authentication、plugin、proxy-ldap、rdn-changing、transformations、trust-store-local-backendのいずれかを指定できます。

create-workflow-element --type global-index-replication-changes-local-backend

ワークフロー要素を作成します。サブオプションは次のとおりです:

--element-name name。新しいワークフロー要素の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t, --type type。作成するワークフロー要素のタイプ。typeの値には、ad-paging、backup-local-backend、db-local-backend,distribution、dn-renaming、eus、eus-context、fa、global-index-local-backend、global-index-replication-changes-local-backend、kerberos-auth-provider、ldif-local-backend、load-balancing、memory-local-backend、monitor-local-backend、null-local-backend、pass-through-authentication、plugin、proxy-ldap、rdn-changing、transformations、trust-store-local-backendのいずれかを指定できます。

delete-distribution-algorithm

分散アルゴリズムを削除します。サブオプションは次のとおりです:

--element-name name。分散ワークフロー要素の名前。

-f,--force。存在しない分散アルゴリズムを無視します。

delete-distribution-partition

分散パーティションを削除します。サブオプションは次のとおりです:

--element-name name。分散ワークフロー要素の名前。

--partition-name name。分散パーティションの名前。

-f,--force。存在しない分散パーティションを無視します。

delete-extension

拡張を削除します。サブオプションは次のとおりです:

--extension-name name。拡張の名前。

-f,--force。存在しない拡張を無視します。

delete-global-index

グローバル索引を削除します。サブオプションは次のとおりです:

--extension-name name。グローバル索引カタログ拡張の名前。

--index-name name。グローバル索引の名前。

-f,--force。存在しないグローバル索引を無視します。

delete-global-index-catalog-replication-domain

このコマンドはプロキシのみにサポートされます。グローバル索引を管理するには、第A.2.7項「gicadm」を参照してください。

グローバル索引カタログ・レプリケーション・ドメインを削除します。サブオプションは次のとおりです:

--extension-name name。グローバル索引カタログ拡張の名前。

-f,--force。存在しないグローバル索引カタログ・レプリケーション・ドメインを無視します。

delete-workflow-element

ワークフロー要素を削除します。サブオプションは次のとおりです:

--element-name name。ワークフロー要素の名前。

-f,--force。存在しないワークフロー要素を無視します。

get-distribution-algorithm-prop

分散アルゴリズムのプロパティを表示します。サブオプションは次のとおりです:

--element-name name。分散ワークフロー要素の名前。

--property property。表示されるプロパティの名前。

-E,--record。表示出力を1行ごとに1つのプロパティ値を表示するように変更します。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

get-distribution-partition-prop

分散パーティションのプロパティを表示します。サブオプションは次のとおりです:

--element-name name。分散ワークフロー要素の名前。

--partition-name name。分散パーティションの名前。

--property property。表示されるプロパティの名前。

-E,--record。表示出力を1行ごとに1つのプロパティ値を表示するように変更します。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

get-global-index-catalog-replication-domain-prop

このコマンドはプロキシのみにサポートされます。グローバル索引を管理するには、第A.2.7項「gicadm」を参照してください。

グローバル索引カタログ・レプリケーション・ドメインのプロパティを表示します。サブオプションは次のとおりです:

--extension-name name。グローバル索引カタログ拡張の名前。

--property property。表示されるプロパティの名前。

-E,--record。表示出力を1行ごとに1つのプロパティ値を表示するように変更します。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

get-global-index-prop

このコマンドはプロキシのみにサポートされます。グローバル索引を管理するには、第A.2.7項「gicadm」を参照してください。

グローバル索引のプロパティを表示します。サブオプションは次のとおりです:

--extension-name name。グローバル索引カタログ拡張の名前。

--index-name name。グローバル索引の名前。

--property property。表示されるプロパティの名前。

-E,--record。表示出力を1行ごとに1つのプロパティ値を表示するように変更します。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

list-distribution-algorithm

このコマンドはプロキシのみにサポートされます。

既存の分散アルゴリズムをリストします。サブオプションは次のとおりです:

--element-name name。分散ワークフロー要素の名前。

--property property。表示されるプロパティの名前。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

list-distribution-partitions

このコマンドはプロキシのみにサポートされます。

既存の分散パーティションをリストします。サブオプションは次のとおりです:

--element-name name。分散ワークフロー要素の名前。

--property property。表示されるプロパティの名前。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

list-extensions

既存の拡張をリストします。サブオプションは次のとおりです:

--property property。表示されるプロパティの名前。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

list-global-index-catalog-replication-domain

このコマンドはプロキシのみにサポートされます。グローバル索引を管理するには、第A.2.7項「gicadm」を参照してください。

既存のグローバル索引カタログ・レプリケーション・ドメインをリストします。サブオプションは次のとおりです:

--extension-name name。グローバル索引カタログ拡張の名前。

--property property。表示されるプロパティの名前。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

list-global-indexes

既存のグローバル索引をリストします。サブオプションは次のとおりです:

--extension-name name。グローバル索引カタログ拡張の名前。

--property property。表示されるプロパティの名前。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

list-workflow-elements

既存のワークフロー要素をリストします。サブオプションは次のとおりです:

--property property。表示されるプロパティの名前。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

set-distribution-algorithm-prop

このコマンドはプロキシのみにサポートされます。

分散アルゴリズムのプロパティを変更します。サブオプションは次のとおりです:

--element-name name。分散ワークフロー要素の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

set-distribution-partition-prop

このコマンドはプロキシのみにサポートされます。

分散パーティションのプロパティを変更します。サブオプションは次のとおりです:

--element-name name。分散ワークフロー要素の名前。

--partition-name name。分散パーティションの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

set-extension-prop

拡張のプロパティを変更します。サブオプションは次のとおりです:

--extension-name name。拡張の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

set-global-index-catalog-replication-domain-prop

このコマンドはプロキシのみにサポートされます。

グローバル索引カタログ・レプリケーション・ドメインのプロパティを変更します。サブオプションは次のとおりです:

--extension-name name。グローバル索引カタログ拡張の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

set-global-index-prop

このコマンドはプロキシのみにサポートされます。

グローバル索引のプロパティを変更します。サブオプションは次のとおりです:

--extension-name name。グローバル索引カタログ拡張の名前。

--index-name name。グローバル索引の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

set-workflow-element-prop

ワークフロー要素のプロパティを変更します。サブオプションは次のとおりです:

--element-name name。ワークフロー要素の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

A.2.4.6 一般構成サブコマンド

次のサブコマンドによって、コア・サーバーが構成されます。

create-alert-handler

アラート・ハンドラを作成します。サブオプションは次のとおりです:

--handler-name name。新しいアラート・ハンドラの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t,--type type。作成するアラート・ハンドラのタイプ。typeの値には、custom、jmx、またはsmtpのいずれかを指定できます。

create-certificate-mapper

証明書マッパーを作成します。サブオプションは次のとおりです:

--mapper-name name。新しい証明書マッパーの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t,--type type。作成する証明書マッパーのタイプ。typeの値には、custom、fingerprint、subject-attribute-to-user-attribute、subject-dn-to-user-attribute、またはsubject-equals-dnのいずれかを指定できます。

create-connection-handler

接続ハンドラを作成します。サブオプションは次のとおりです:

--handler-name name。新しい接続ハンドラの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t,--type type。作成する接続ハンドラのタイプ。typeの値には、custom、jmx、ldap、snmp、またはldifのいずれかを指定できます。

create-debug-target

デバッグ・ターゲットを作成します。サブオプションは次のとおりです:

--publisher-name name。デバッグ・ログ・パブリッシャの名前。

--target-name java-name。新しいデバッグ・ターゲットの名前で、これはdebug-scopeプロパティの値としても使用できます。このターゲット定義の設定の影響を受ける完全修飾されたOracle Unified DirectoryのJavaパッケージ、クラス、またはメソッド。シャープ記号(#)を使用して、クラス名とメソッド名を分離します(例: org.opends.server.core.DirectoryServer#startUp)。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

create-extended-operation-handler

このコマンドはプロキシに対してサポートされていません。

拡張操作ハンドラを作成します。サブオプションは次のとおりです:

--handler-name name。新しい拡張操作ハンドラの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t,--type type。作成する拡張操作ハンドラのタイプ。typeの値には、cancel、custom、get-connection-id、get-symmetric-key、password-modify、password-policy-state、start-tls、またはwho-am-iのいずれかを指定できます。

create-identity-mapper

IDマッパーを作成します。サブオプションは次のとおりです:

--mapper-name name。新しいIDマッパーの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t,--type type。作成するIDマッパーのタイプ。typeの値には、custom,exact-match、またはmatch-and-replaceのいずれかを指定できます。

create-log-publisher

ログ・パブリッシャを作成します。サブオプションは次のとおりです:

--publisher-name name。新しいログ・パブリッシャの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t,--type type。作成するログ・パブリッシャのタイプ。typeの値には、custom-access、custom-debug、custom-error、file-based-access、file-based-debug、またはfile-based-errorのいずれかを指定できます。

create-log-retention-policy

ログ保持ポリシーを作成します。サブオプションは次のとおりです:

--policy-name name。新しいログ保持ポリシーの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t,--type type。作成するログ保持ポリシーのタイプ。typeの値には、custom,file-count、free-disk-space、またはsize-limitのいずれかを指定できます。

create-log-rotation-policy

ログ・ローテーション・ポリシーを作成します。サブオプションは次のとおりです:

--policy-name name。新しいログ・ローテーション・ポリシーの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t,--type type。作成するログ・ローテーション・ポリシーのタイプ。typeの値には、custom、fixed-time、size-limit、またはtime-limitのいずれかを指定できます。

create-workflow-element --type monitor-local-backend

ワークフロー要素を作成します。サブオプションは次のとおりです:

--element-name name。新しいワークフロー要素の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t, --type type。作成するワークフロー要素のタイプ。typeの値には、ad-paging、backup-local-backend、db-local-backend,distribution、dn-renaming、eus、eus-context、fa、global-index-local-backend、global-index-replication-changes-local-backend、kerberos-auth-provider、ldif-local-backend、load-balancing、memory-local-backend、monitor-local-backend、null-local-backend、pass-through-authentication、plugin、proxy-ldap、rdn-changing、transformations、trust-store-local-backendのいずれかを指定できます。

create-network-group

ネットワーク・グループを作成します。サブオプションは次のとおりです:

--group-name name。新しいネットワーク・グループの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

create-network-group-qos-policy

ネットワーク・グループのリソース制限を作成します。サブオプションは次のとおりです:

--group-name name。ネットワーク・グループの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t, --type type。作成するサービスのクオリティ・ポリシーのタイプ。typeの値には、次のaffinity、referral、request-filtering、またはresource-limitsのいずれかを指定できます。

create-workflow

ワークフローを作成します。サブオプションは次のとおりです:

--workflow-name name。新規ワークフローの名前。この名前は、workflow-idプロパティの値としても使用されます。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

delete-alert-handler

アラート・ハンドラを削除します。サブオプションは次のとおりです:

--handler-name name。アラート・ハンドラの名前。

-f,--force。存在しないアラート・ハンドラを無視します。

delete-certificate-mapper

証明書マッパーを削除します。サブオプションは次のとおりです:

--mapper-name name。証明書マッパーの名前。

-f,--force。存在しない証明書マッパーを無視します。

delete-connection-handler

接続ハンドラを削除します。サブオプションは次のとおりです:

--handler-name name。接続ハンドラの名前。

-f,--force。存在しない接続ハンドラを無視します。

delete-debug-target

デバッグ・ターゲットを削除します。サブオプションは次のとおりです:

--publisher-name name。デバッグ・ログ・パブリッシャの名前。

--target-name name。デバッグ・ターゲットの名前。

-f,--force。存在しないデバッグ・ターゲットを無視します。

delete-extended-operation-handler

拡張操作ハンドラを削除します。サブオプションは次のとおりです:

--handler-name name。拡張操作ハンドラの名前。

-f,--force。存在しない拡張操作ハンドラを無視します。

delete-identity-mapper

IDマッパーを削除します。サブオプションは次のとおりです:

--mapper-name name。IDマッパーの名前。

-f,--force。存在しないIDマッパーを無視します。

delete-log-publisher

ログ・パブリッシャを削除します。サブオプションは次のとおりです:

--publisher-name name。ログ・パブリッシャの名前。

-f,--force。存在しないログ・パブリッシャを無視します。

delete-log-retention-policy

ログ保持ポリシーを削除します。サブオプションは次のとおりです:

--policy-name name。ログ保持ポリシーの名前。

-f,--force。存在しないログ保持ポリシーを無視します。

delete-log-rotation-policy

ログ・ローテーション・ポリシーを削除します。サブオプションは次のとおりです:

--policy-name name。ログ・ローテーション・ポリシーの名前。

-f,--force。存在しないログ・ローテーション・ポリシーを無視します。

delete-network-group

ネットワーク・グループを削除します。サブオプションは次のとおりです:

--group-name name。ネットワーク・グループの名前。

-f,--force。存在しないネットワーク・グループを無視します。

delete-network-group-qos-policy

ネットワーク・グループのサービスのクオリティ・ポリシーを削除します。サブオプションは次のとおりです:

--group-name name。ネットワーク・グループの名前。

--policy-type name。QOSポリシーの名前。

-f,--force。存在しないネットワーク・グループのリソース制限を無視します。

delete-workflow

ワークフローを削除します。サブオプションは次のとおりです:

-f,--force。存在しないワークフローを無視します。

--workflow-name name。ワークフローの名前。

delete-workflow-element

ワークフロー要素を削除します。サブオプションは次のとおりです:

--element-name name。ワークフロー要素の名前。

-f,--force。存在しないワークフロー要素を無視します。

get-administration-connector-prop

管理コネクタのプロパティを表示します。サブオプションは次のとおりです:

--property property。表示されるプロパティの名前。

-E,--record。表示出力を1行ごとに1つのプロパティ値を表示するように変更します。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

get-alert-handler-prop

アラート・ハンドラのプロパティを表示します。サブオプションは次のとおりです:

--handler-name name。アラート・ハンドラの名前。

--property property。表示されるプロパティの名前。

-E,--record。表示出力を1行ごとに1つのプロパティ値を表示するように変更します。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

get-certificate-mapper-prop

証明書マッパーのプロパティを表示します。サブオプションは次のとおりです:

--mapper-name name。証明書マッパーの名前。

--property property。表示されるプロパティの名前。

-E,--record。表示出力を1行ごとに1つのプロパティ値を表示するように変更します。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

get-connection-handler-prop

接続ハンドラのプロパティを表示します。サブオプションは次のとおりです:

--handler-name name。接続ハンドラの名前。

--property property。表示されるプロパティの名前。

-E,--record。表示出力を1行ごとに1つのプロパティ値を表示するように変更します。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

get-debug-target-prop

デバッグ・ターゲットのプロパティを表示します。サブオプションは次のとおりです:

--publisher-name name。デバッグ・ログ・パブリッシャの名前。

--target-name name。デバッグ・ターゲットの名前。

--property property。表示されるプロパティの名前。

-E,--record。表示出力を1行ごとに1つのプロパティ値を表示するように変更します。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

get-extended-operation-handler-prop

拡張操作ハンドラのプロパティを表示します。サブオプションは次のとおりです:

--handler-name name。拡張操作ハンドラの名前。

--property property。表示されるプロパティの名前。

-E,--record。表示出力を1行ごとに1つのプロパティ値を表示するように変更します。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

get-global-configuration-prop

グローバル構成のプロパティを表示します。サブオプションは次のとおりです:

--property property。表示されるプロパティの名前。

-E,--record。表示出力を1行ごとに1つのプロパティ値を表示するように変更します。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

get-identity-mapper-prop

IDマッパーのプロパティを表示します。サブオプションは次のとおりです:

--mapper-name name。IDマッパーの名前。

--property property。表示されるプロパティの名前。

-E,--record。表示出力を1行ごとに1つのプロパティ値を表示するように変更します。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

get-log-publisher-prop

ログ・パブリッシャのプロパティを表示します。サブオプションは次のとおりです:

--publisher-name name。ログ・パブリッシャの名前。

--property property。表示されるプロパティの名前。

-E,--record。表示出力を1行ごとに1つのプロパティ値を表示するように変更します。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

get-log-retention-policy-prop

ログ保持ポリシーのプロパティを表示します。サブオプションは次のとおりです:

--policy-name name。ログ保持ポリシーの名前。

--property property。表示されるプロパティの名前。

-E,--record。表示出力を1行ごとに1つのプロパティ値を表示するように変更します。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

get-log-rotation-policy-prop

ログ・ローテーション・ポリシーのプロパティを表示します。サブオプションは次のとおりです:

--policy-name name。ログ・ローテーション・ポリシーの名前。

--property property。表示されるプロパティの名前。

-E,--record。表示出力を1行ごとに1つのプロパティ値を表示するように変更します。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

get-network-group-prop

ネットワーク・グループのプロパティを表示します。サブオプションは次のとおりです:

--group-name name。ネットワーク・グループの名前。

--property property。表示されるプロパティの名前。

-E,--record。表示出力を1行ごとに1つのプロパティ値を表示するように変更します。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

get-network-group-qos-policy-prop

ネットワーク・グループのサービスのクオリティ・ポリシーのプロパティを表示します。サブオプションは次のとおりです:

--group-name name。ネットワーク・グループの名前。

--policy-type name。サービスのクオリティ・ポリシーの名前。

--property property。表示されるプロパティの名前。

-E,--record。表示出力を1行ごとに1つのプロパティ値を表示するように変更します。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

get-plugin-root-prop

プラグイン・ルートのプロパティを表示します。

--property property。表示されるプロパティの名前。

-E,--record。表示出力を1行ごとに1つのプロパティ値を表示するように変更します。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

get-root-dse-backend-prop

ルートDSEバックエンドのプロパティを表示します。サブオプションは次のとおりです:

--property property。表示されるプロパティの名前。

-E,--record。表示出力を1行ごとに1つのプロパティ値を表示するように変更します。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

get-work-queue-prop

ワーク・キューのプロパティを表示します。サブオプションは次のとおりです:

--property property。表示されるプロパティの名前。

-E,--record。表示出力を1行ごとに1つのプロパティ値を表示するように変更します。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

get-workflow-prop

ワークフローのプロパティを表示します。サブオプションは次のとおりです:

--workflow-name name。ワークフローの名前。

--property property。表示されるプロパティの名前。

-E,--record。表示出力を1行ごとに1つのプロパティ値を表示するように変更します。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

list-alert-handlers

既存のアラート・ハンドラをリストします。サブオプションは次のとおりです:

--property property。表示されるプロパティの名前。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

list-certificate-mappers

既存の証明書マッパーをリストします。サブオプションは次のとおりです:

--property property。表示されるプロパティの名前。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

list-connection-handlers

既存の接続ハンドラをリストします。サブオプションは次のとおりです:

--property property。表示されるプロパティの名前。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

list-debug-targets

既存のデバッグ・ターゲットをリストします。サブオプションは次のとおりです:

--publisher-name name。デバッグ・ログ・パブリッシャの名前。

--property property。表示されるプロパティの名前。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

list-extended-operation-handlers

既存の拡張操作ハンドラをリストします。サブオプションは次のとおりです:

--property property。表示されるプロパティの名前。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

list-identity-mappers

既存のIDマッパーをリストします。サブオプションは次のとおりです:

--property property。表示されるプロパティの名前。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

list-log-publishers

既存のログ・パブリッシャをリストします。サブオプションは次のとおりです:

--property property。表示されるプロパティの名前。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

list-log-retention-policies

既存のログ保持ポリシーをリストします。サブオプションは次のとおりです:

--property property。表示されるプロパティの名前。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

list-log-rotation-policies

既存のログ・ローテーション・ポリシーをリストします。サブオプションは次のとおりです:

--property property。表示されるプロパティの名前。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

list-network-group-qos-policies

既存のネットワーク・グループのQOSポリシーをリストします。サブオプションは次のとおりです:

--group-name name。ネットワーク・グループの名前。

--property property。表示されるプロパティの名前。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

list-network-groups

既存のネットワーク・グループをリストします。サブオプションは次のとおりです:

--property property。表示されるプロパティの名前。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

list-workflow-elements

既存のワークフロー要素をリストします。サブオプションは次のとおりです:

--property property。表示されるプロパティの名前。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

list-workflows

既存のワークフローをリストします。サブオプションは次のとおりです:

--property property。表示されるプロパティの名前。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

set-administration-connector-prop

管理コネクタのプロパティを変更します。サブオプションは次のとおりです:

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

set-alert-handler-prop

アラート・ハンドラのプロパティを変更します。サブオプションは次のとおりです:

--handler-name name。アラート・ハンドラの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

set-certificate-mapper-prop

証明書マッパーのプロパティを変更します。サブオプションは次のとおりです:

--mapper-name name。証明書マッパーの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

set-connection-handler-prop

接続ハンドラのプロパティを変更します。サブオプションは次のとおりです:

--handler-name name。接続ハンドラの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

set-debug-target-prop

デバッグ・ターゲットのプロパティを変更します。サブオプションは次のとおりです:

--publisher-name name。デバッグ・ログ・パブリッシャの名前。

--target-name name。デバッグ・ターゲットの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

set-extended-operation-handler-prop

拡張操作ハンドラのプロパティを変更します。サブオプションは次のとおりです:

--handler-name name。拡張操作ハンドラの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

set-global-configuration-prop

グローバル構成のプロパティを変更します。サブオプションは次のとおりです:

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

set-identity-mapper-prop

IDマッパーのプロパティを変更します。サブオプションは次のとおりです:

--mapper-name name。IDマッパーの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

set-log-publisher-prop

ログ・パブリッシャのプロパティを変更します。サブオプションは次のとおりです:

--publisher-name name。ログ・パブリッシャの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

set-log-retention-policy-prop

ログ保持ポリシーのプロパティを変更します。サブオプションは次のとおりです:

--policy-name name。ログ保持ポリシーの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

set-log-rotation-policy-prop

ログ・ローテーション・ポリシーのプロパティを変更します。サブオプションは次のとおりです:

--policy-name name。ログ・ローテーション・ポリシーの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

set-network-group-prop

ネットワーク・グループのプロパティを変更します。サブオプションは次のとおりです:

--group-name name。ネットワーク・グループの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

set-network-group-qos-policy-prop

ネットワーク・グループのサービスのクオリティ・ポリシーのプロパティを変更します。サブオプションは次のとおりです:

--group-name name。ネットワーク・グループの名前。

--policy-type name。QOSポリシーの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

set-plugin-root-prop

プラグイン・ルートのプロパティを変更します。サブオプションは次のとおりです:

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

set-root-dse-backend-prop

ルートDSEバックエンドのプロパティを変更します。サブオプションは次のとおりです:

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

set-work-queue-prop

ワーク・キューのプロパティを変更します。サブオプションは次のとおりです:

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

set-workflow-element-prop

ワークフロー要素のプロパティを変更します。サブオプションは次のとおりです:

--element-name name。ワークフロー要素の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

set-workflow-prop

ワークフローのプロパティを変更します。サブオプションは次のとおりです:

--workflow-name name。ワークフローの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

A.2.4.7 ロード・バランシング・サブコマンド

次のサブコマンドによって、プロキシ・サーバーのロード・バランシングが構成されます。

create-load-balancing-algorithm

このコマンドはプロキシのみにサポートされます。

ロード・バランシングのアルゴリズムを作成します。サブオプションは次のとおりです:

--element-name name。ロード・バランシングのワークフロー要素の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t,--type type。作成するロード・バランシングのアルゴリズムのタイプ。typeの値には、failover、generic、optimal、proportional、saturation、またはsearchfilterのいずれかを指定できます。デフォルト値はgenericです。

create-load-balancing-route

このコマンドはプロキシのみにサポートされます。

ロード・バランシングのルートを作成します。サブオプションは次のとおりです:

--element-name name。ロード・バランシングのワークフロー要素の名前。

--route-name name。新しいロード・バランシングのルートの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t,--type type。作成するロード・バランシングのルートのタイプ。typeの値には、failover、generic、optimal、proportional、saturation、またはsearchfilterのいずれかを指定できます。デフォルト値はgenericです。

create-workflow-element --type load-balancing

ワークフロー要素を作成します。サブオプションは次のとおりです:

--element-name name。新しいワークフロー要素の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t,--type type。作成するワークフロー要素のタイプ。typeの値には、ad-paging、backup-local-backend、db-local-backend,distribution、dn-renaming、eus、eus-context、fa、global-index-local-backend、global-index-replication-changes-local-backend、kerberos-auth-provider、ldif-local-backend、load-balancing、memory-local-backend、monitor-local-backend、null-local-backend、pass-through-authentication、plugin、proxy-ldap、rdn-changing、transformations、trust-store-local-backendのいずれかを指定できます。

delete-load-balancing-algorithm

ロード・バランシングのアルゴリズムを削除します。サブオプションは次のとおりです:

--element-name name。ロード・バランシングのワークフロー要素の名前。

-f,--force。存在しないロード・バランシングのアルゴリズムを無視します。

delete-load-balancing-route

ロード・バランシングのルートを削除します。サブオプションは次のとおりです:

--element-name name。ロード・バランシングのワークフロー要素の名前。

--route-name name。ロード・バランシングのルートの名前。

-f,--force。存在しないロード・バランシングのルートを無視します。

delete-workflow-element

ワークフロー要素を削除します。サブオプションは次のとおりです:

--element-name name。ワークフロー要素の名前。

-f,--force。存在しないワークフロー要素を無視します。

get-load-balancing-algorithm-prop

ロード・バランシングのアルゴリズムのプロパティを表示します。サブオプションは次のとおりです:

--element-name name。ロード・バランシングのワークフロー要素の名前。

--property property。表示されるプロパティの名前。

-E,--record。表示出力を1行ごとに1つのプロパティ値を表示するように変更します。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

get-load-balancing-route-prop

このコマンドはプロキシのみにサポートされます。

ロード・バランシングのルートのプロパティを表示します。サブオプションは次のとおりです:

--element-name name。ロード・バランシングのワークフロー要素の名前。

--route-name name。ロード・バランシングのルートの名前。

--property property。表示されるプロパティの名前。

-E,--record。表示出力を1行ごとに1つのプロパティ値を表示するように変更します。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

list-load-balancing-algorithm

このコマンドはプロキシのみにサポートされます。

既存のロード・バランシングのアルゴリズムをリストします。サブオプションは次のとおりです:

--element-name name。ロード・バランシングのワークフロー要素の名前。

--property property。表示されるプロパティの名前。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

list-load-balancing-routes

このコマンドはプロキシのみにサポートされます。

既存のロード・バランシングのルートをリストします。サブオプションは次のとおりです:

--element-name name。ロード・バランシングのワークフロー要素の名前。

--property property。表示されるプロパティの名前。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

list-workflow-elements

既存のワークフロー要素をリストします。サブオプションは次のとおりです:

--property property。表示されるプロパティの名前。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

set-load-balancing-algorithm-prop

このコマンドはプロキシのみにサポートされます。

ロード・バランシングのアルゴリズムのプロパティを変更します。サブオプションは次のとおりです:

--element-name name。ロード・バランシングのワークフロー要素の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

set-load-balancing-route-prop

このコマンドはプロキシのみにサポートされます。

ロード・バランシングのルートのプロパティを変更します。サブオプションは次のとおりです:

--element-name name。ロード・バランシングのワークフロー要素の名前。

--route-name name。ロード・バランシングのルートの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

set-workflow-element-prop

ワークフロー要素のプロパティを変更します。サブオプションは次のとおりです:

--element-name name。ワークフロー要素の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

A.2.4.8 ローカル記憶域サブコマンド

create-account-status-notification-handler

アカウント・ステータス通知ハンドラを作成します。サブオプションは次のとおりです:

--handler-name name。新しいアカウント・ステータス通知ハンドラの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t,--type type。作成するアカウント・ステータス通知ハンドラのタイプ。typeの値には、custom、error-log、またはsmtpのいずれかを指定できます。

create-workflow-element --type backup-local-backend

ワークフロー要素を作成します。サブオプションは次のとおりです:

--element-name name。新しいワークフロー要素の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t,--type type。作成するワークフロー要素のタイプ。typeの値には、ad-paging、backup-local-backend、db-local-backend,distribution、dn-renaming、eus、eus-context、fa、global-index-local-backend、global-index-replication-changes-local-backend、kerberos-auth-provider、ldif-local-backend、load-balancing、memory-local-backend、monitor-local-backend、null-local-backend、pass-through-authentication、plugin、proxy-ldap、rdn-changing、transformations、trust-store-local-backendのいずれかを指定できます。

create-workflow-element --type db-local-backend

ワークフロー要素を作成します。サブオプションは次のとおりです:

--element-name name。新しいワークフロー要素の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t,--type type。作成するワークフロー要素のタイプ。typeの値には、ad-paging、backup-local-backend、db-local-backend,distribution、dn-renaming、eus、eus-context、fa、global-index-local-backend、global-index-replication-changes-local-backend、kerberos-auth-provider、ldif-local-backend、load-balancing、memory-local-backend、monitor-local-backend、null-local-backend、pass-through-authentication、plugin、proxy-ldap、rdn-changing、transformations、trust-store-local-backendのいずれかを指定できます。

create-entry-cache

エントリ・キャッシュを作成します。サブオプションは次のとおりです:

--cache-name name。新しいエントリ・キャッシュの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t,--type type。作成するエントリ・キャッシュのタイプ。typeの値には、custom、fifo、file-system、またはsoft-referenceのいずれかを指定できます。

create-group-implementation

このコマンドはプロキシに対してサポートされていません。

グループ実装を作成します。サブオプションは次のとおりです:

--implementation-name name。新しいグループ実装の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t, --type type。作成するグループ実装のタイプ。typeの値には、dynamic、static、またはvirtual-staticのいずれかを指定できます。

create-workflow-element --type ldif-local-backend

ワークフロー要素を作成します。サブオプションは次のとおりです:

--element-name name。新しいワークフロー要素の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t,--type type。作成するワークフロー要素のタイプ。typeの値には、ad-paging、backup-local-backend、db-local-backend,distribution、dn-renaming、eus、eus-context、fa、global-index-local-backend、global-index-replication-changes-local-backend、kerberos-auth-provider、ldif-local-backend、load-balancing、memory-local-backend、monitor-local-backend、null-local-backend、pass-through-authentication、plugin、proxy-ldap、rdn-changing、transformations、trust-store-local-backendのいずれかを指定できます。

create-local-db-index

ローカルDB索引を作成します。サブオプションは次のとおりです:

--element-name name。ローカルDBバックエンドのワークフロー要素の名前。

--index-name name。新しいローカルDB索引の名前で、これはattributeプロパティの値としても使用できます。これによって、索引が維持される属性の名前が指定されます。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

create-local-db-vlv-index

ローカルDBのVLV索引を作成します。サブオプションは次のとおりです:

--element-name name。ローカルDBバックエンドのワークフロー要素の名前。

--index-name name。新しいローカルDBのVLV索引の名前で、これはnameプロパティの値としても使用できます。このプロパティによって、このVLV索引に一意の名前が指定されます。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

create-workflow-element --type memory-local-backend

ワークフロー要素を作成します。サブオプションは次のとおりです:

--element-name name。新しいワークフロー要素の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t,--type type。作成するワークフロー要素のタイプ。typeの値には、ad-paging、backup-local-backend、db-local-backend,distribution、dn-renaming、eus、eus-context、fa、global-index-local-backend、global-index-replication-changes-local-backend、kerberos-auth-provider、ldif-local-backend、load-balancing、memory-local-backend、monitor-local-backend、null-local-backend、pass-through-authentication、plugin、proxy-ldap、rdn-changing、transformations、trust-store-local-backendのいずれかを指定できます。

create-workflow-element --type null-local-backend

ワークフロー要素を作成します。サブオプションは次のとおりです:

--element-name name。新しいワークフロー要素の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t,--type type。作成するワークフロー要素のタイプ。typeの値には、ad-paging、backup-local-backend、db-local-backend,distribution、dn-renaming、eus、eus-context、fa、global-index-local-backend、global-index-replication-changes-local-backend、kerberos-auth-provider、ldif-local-backend、load-balancing、memory-local-backend、monitor-local-backend、null-local-backend、pass-through-authentication、plugin、proxy-ldap、rdn-changing、transformations、trust-store-local-backendのいずれかを指定できます。

create-password-generator

パスワード・ジェネレータを作成します。サブオプションは次のとおりです:

--generator-name name。新しいパスワード・ジェネレータの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t,--type type。作成するパスワード・ジェネレータのタイプ。typeの値には、customまたはrandomのいずれかを指定できます。

create-password-policy

パスワード・ポリシーを作成します。サブオプションは次のとおりです:

--policy-name name。新しいパスワード・ポリシーの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

create-plugin --type password-policy-import

プラグインを作成します。サブオプションは次のとおりです:

--plugin-name name。新しいプラグインの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t,--type type。作成するプラグインのタイプ。typeの値には、dsee-gateway、password-policy-import、referential-integrity、seven-bit-clean、unique-attributeのいずれかを指定できます。

create-password-storage-scheme

パスワード・ストレージ・スキームを作成します。サブオプションは次のとおりです:

--scheme-name name。新しいパスワード・ストレージ・スキームの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t,--type type。作成するパスワード・ストレージ・スキームのタイプ。typeの値には、aes、base64、blowfish、clear、crypt、custom、md5、rc4、salted-md5、salted-sha1、salted-sha256、salted-sha384、salted-sha512、sha1、またはtriple-desのいずれかを指定できます。

create-password-validator

パスワード・バリデータを作成します。サブオプションは次のとおりです:

--validator-name name。新しいパスワード・バリデータの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t,--type type。作成するパスワード・バリデータのタイプ。typeの値には、attribute-value、character-set、custom、dictionary、length-based、repeated-characters、similarity-based、またはunique-charactersのいずれかを指定できます。

create-plugin --type referential-integrity

プラグインを作成します。サブオプションは次のとおりです:

--plugin-name name。新しいプラグインの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t,--type type。作成するプラグインのタイプ。typeの値には、dsee-gateway、password-policy-import、referential-integrity、seven-bit-clean、unique-attributeのいずれかを指定できます。

create-plugin --type seven-bit-clean

プラグインを作成します。サブオプションは次のとおりです:

--plugin-name name。新しいプラグインの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t,--type type。作成するプラグインのタイプ。typeの値には、dsee-gateway、password-policy-import、referential-integrity、seven-bit-clean、unique-attributeのいずれかを指定できます。

create-plugin --type unique-attribute

プラグインを作成します。サブオプションは次のとおりです:

--plugin-name name。新しいプラグインの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t,--type type。作成するプラグインのタイプ。typeの値には、dsee-gateway、password-policy-import、referential-integrity、seven-bit-clean、unique-attributeのいずれかを指定できます。

create-virtual-attribute

このコマンドはプロキシに対してサポートされていません。

仮想属性を作成します。サブオプションは次のとおりです:

--name name。新しい仮想属性の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t,--type type。作成する仮想属性のタイプ。typeの値には、collective-attribute-subentries、custom、entry-dn、entry-uuid、governing-structure-rule、has-subordinates、is-member-of、member、nsuniqueid、num-subordinates、orclguid、password-policy-subentry、proximity、structural-object-class、subschema-subentry、user-definedのいずれかを指定できます。

delete-account-status-notification-handler

アカウント・ステータス通知ハンドラを削除します。サブオプションは次のとおりです:

--handler-name name。アカウント・ステータス通知ハンドラの名前。

-f,--force。存在しないアカウント・ステータス通知ハンドラを無視します。

delete-entry-cache

エントリ・キャッシュを削除します。サブオプションは次のとおりです:

--cache-name name。エントリ・キャッシュの名前。

-f,--force。存在しないエントリ・キャッシュを無視します。

delete-group-implementation

このコマンドはプロキシに対してサポートされていません。

グループ実装を削除します。サブオプションは次のとおりです:

--implementation-name name。グループ実装の名前。

-f,--force。存在しないグループ実装を無視します。

delete-local-db-index

ローカルDB索引を削除します。サブオプションは次のとおりです:

--element-name name。ローカルDBバックエンドのワークフロー要素の名前。

--index-name name。ローカルDB索引の名前。

-f,--force。存在しないローカルDB索引を無視します。

delete-local-db-vlv-index

ローカルDBのVLV索引を削除します。サブオプションは次のとおりです:

--element-name name。ローカルDBバックエンドのワークフロー要素の名前。

--index-name name。ローカルDBのVLV索引の名前。

-f,--force。存在しないローカルDBのVLV索引を無視します。

delete-password-generator

パスワード・ジェネレータを削除します。サブオプションは次のとおりです:

--generator-name name。パスワード・ジェネレータの名前。

-f,--force。存在しないパスワード・ジェネレータを無視します。

delete-password-policy

パスワード・ポリシーを削除します。サブオプションは次のとおりです:

--policy-name name。パスワード・ポリシーの名前。

-f,--force。存在しないパスワード・ポリシーを無視します。

delete-password-storage-scheme

パスワード・ストレージ・スキームを削除します。サブオプションは次のとおりです:

--scheme-name name。パスワード・ストレージ・スキームの名前。

-f,--force。存在しないパスワード・ストレージ・スキームを無視します。

delete-password-validator

パスワード・バリデータを削除します。サブオプションは次のとおりです:

--validator-name name。パスワード・バリデータの名前。

-f,--force。存在しないパスワード・バリデータを無視します。

delete-plugin

プラグインを削除します。サブオプションは次のとおりです:

--plugin-name name。プラグインの名前。

-f,--force。存在しないプラグインを無視します。

delete-virtual-attribute

このコマンドはプロキシに対してサポートされていません。

仮想属性を削除します。サブオプションは次のとおりです:

--name name。仮想属性の名前。

-f,--force。存在しない仮想属性を無視します。

delete-workflow-element

ワークフロー要素を削除します。サブオプションは次のとおりです:

--element-name name。ワークフロー要素の名前。

-f,--force。存在しないワークフロー要素を無視します。

get-account-status-notification-handler-prop

アカウント・ステータス通知ハンドラのプロパティを表示します。サブオプションは次のとおりです:

--handler-name name。アカウント・ステータス通知ハンドラの名前。

--property property。表示されるプロパティの名前。

-E,--record。表示出力を1行ごとに1つのプロパティ値を表示するように変更します。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

get-entry-cache-prop

エントリ・キャッシュのプロパティを表示します。サブオプションは次のとおりです:

--cache-name name。エントリ・キャッシュの名前。

--property property。表示されるプロパティの名前。

-E,--record。表示出力を1行ごとに1つのプロパティ値を表示するように変更します。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

get-group-implementation-prop

このコマンドはプロキシに対してサポートされていません。

グループ実装のプロパティを表示します。サブオプションは次のとおりです:

--implementation-name name。グループ実装の名前。

--property property。表示されるプロパティの名前。

-E,--record。表示出力を1行ごとに1つのプロパティ値を表示するように変更します。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

get-local-db-index-prop

ローカルDB索引のプロパティを表示します。サブオプションは次のとおりです:

--element-name name。ローカルDBバックエンドのワークフロー要素の名前。

--index-name name。ローカルDB索引の名前。

--property property。表示されるプロパティの名前。

-E,--record。表示出力を1行ごとに1つのプロパティ値を表示するように変更します。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

get-local-db-vlv-index-prop

ローカルDBのVLV索引のプロパティを表示します。サブオプションは次のとおりです:

--element-name name。ローカルDBバックエンドの名前。

--index-name name。ローカルDBのVLV索引の名前。

--property property。表示されるプロパティの名前。

-E,--record。表示出力を1行ごとに1つのプロパティ値を表示するように変更します。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

get-password-generator-prop

パスワード・ジェネレータのプロパティを表示します。サブオプションは次のとおりです:

--generator-name name。パスワード・ジェネレータの名前。

--property property。表示されるプロパティの名前。

-E,--record。表示出力を1行ごとに1つのプロパティ値を表示するように変更します。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

get-password-policy-prop

パスワード・ポリシーのプロパティを表示します。サブオプションは次のとおりです:

--policy-name name。パスワード・ポリシーの名前。

--property property。表示されるプロパティの名前。

-E,--record。表示出力を1行ごとに1つのプロパティ値を表示するように変更します。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

get-password-storage-scheme-prop

パスワード・ストレージ・スキームのプロパティを表示します。サブオプションは次のとおりです:

--scheme-name name。パスワード・ストレージ・スキームの名前。

--property property。表示されるプロパティの名前。

-E,--record。表示出力を1行ごとに1つのプロパティ値を表示するように変更します。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

get-password-validator-prop

パスワード・バリデータのプロパティを表示します。サブオプションは次のとおりです:

--validator-name name。パスワード・バリデータの名前。

--property property。表示されるプロパティの名前。

-E,--record。表示出力を1行ごとに1つのプロパティ値を表示するように変更します。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

get-virtual-attribute-prop

このコマンドはプロキシに対してサポートされていません。

仮想属性のプロパティを表示します。サブオプションは次のとおりです:

--name name。仮想属性の名前。

--property property。表示されるプロパティの名前。

-E,--record。表示出力を1行ごとに1つのプロパティ値を表示するように変更します。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

list-account-status-notification-handlers

既存のアカウント・ステータス通知ハンドラをリストします。サブオプションは次のとおりです:

--property property。表示されるプロパティの名前。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

list-entry-caches

既存のエントリ・キャッシュをリストします。サブオプションは次のとおりです:

--property property。表示されるプロパティの名前。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

list-group-implementations

このコマンドはプロキシに対してサポートされていません。

既存のグループ実装をリストします。サブオプションは次のとおりです:

--property property。表示されるプロパティの名前。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

list-local-db-indexes

既存のローカルDB索引をリストします。サブオプションは次のとおりです:

--element-name name。DBローカル・バックエンドのワークフロー要素の名前。

--property property。表示されるプロパティの名前。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

list-local-db-vlv-indexes

既存のローカルDBのVLV索引をリストします。サブオプションは次のとおりです:

--element-name name。DBローカル・バックエンドのワークフロー要素の名前。

--property property。表示されるプロパティの名前。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

list-password-generators

既存のパスワード・ジェネレータをリストします。サブオプションは次のとおりです:

--property property。表示されるプロパティの名前。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

list-password-policies

既存のパスワード・ポリシーをリストします。サブオプションは次のとおりです:

--property property。表示されるプロパティの名前。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

list-password-storage-schemes

既存のパスワード・ストレージ・スキームをリストします。サブオプションは次のとおりです:

--property property。表示されるプロパティの名前。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

list-password-validators

既存のパスワード・バリデータをリストします。サブオプションは次のとおりです:

--property property。表示されるプロパティの名前。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

list-plugins

既存のプラグインをリストします。サブオプションは次のとおりです:

--property property。表示されるプロパティの名前。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

list-virtual-attributes

このコマンドはプロキシに対してサポートされていません。

既存の仮想属性をリストします。サブオプションは次のとおりです:

--property property。表示されるプロパティの名前。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

list-workflow-elements

既存のワークフロー要素をリストします。サブオプションは次のとおりです:

--property property。表示されるプロパティの名前。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

set-account-status-notification-handler-prop

アカウント・ステータス通知ハンドラのプロパティを変更します。サブオプションは次のとおりです:

--handler-name name。アカウント・ステータス通知ハンドラの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

set-entry-cache-prop

エントリ・キャッシュのプロパティを変更します。サブオプションは次のとおりです:

--cache-name name。エントリ・キャッシュの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

set-group-implementation-prop

このコマンドはプロキシに対してサポートされていません。

グループ実装のプロパティを変更します。サブオプションは次のとおりです:

--implementation-name name。グループ実装の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

set-local-db-index-prop

ローカルDB索引のプロパティを変更します。サブオプションは次のとおりです:

--element-name name。ローカルDBバックエンドのワークフロー要素の名前。

--index-name name。ローカルDB索引の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

set-local-db-vlv-index-prop

ローカルDBのVLV索引のプロパティを変更します。サブオプションは次のとおりです:

--element-name name。ローカルDBバックエンドのワークフロー要素の名前。

--index-name name。ローカルDBのVLV索引の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

set-password-generator-prop

パスワード・ジェネレータのプロパティを変更します。サブオプションは次のとおりです:

--generator-name name。パスワード・ジェネレータの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

set-password-policy-prop

パスワード・ポリシーのプロパティを変更します。サブオプションは次のとおりです:

--policy-name name。パスワード・ポリシーの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

set-password-storage-scheme-prop

パスワード・ストレージ・スキームのプロパティを変更します。サブオプションは次のとおりです:

--scheme-name name。パスワード・ストレージ・スキームの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

set-password-validator-prop

パスワード・バリデータのプロパティを変更します。サブオプションは次のとおりです:

--validator-name name。パスワード・バリデータの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

set-plugin-prop

プラグインのプロパティを変更します。サブオプションは次のとおりです:

--plugin-name name。プラグインの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

set-virtual-attribute-prop

このコマンドはプロキシに対してサポートされていません。

仮想属性のプロパティを変更します。サブオプションは次のとおりです:

--name name。仮想属性の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

set-workflow-element-prop

ワークフロー要素のプロパティを変更します。サブオプションは次のとおりです:

--element-name name。ワークフロー要素の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

A.2.4.9 その他のワークフロー要素サブコマンド

この項では、様々なワークフロー操作のサブコマンドについて説明します。

create-workflow-element --type ad-paging

このコマンドにより、ADページングのワークフロー要素が作成されます。サブオプションは次のとおりです:

--element-name name。新しいワークフロー要素の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t, --type type。作成するワークフロー要素のタイプ。typeの値には、ad-paging、backup-local-backend、db-local-backend,distribution、dn-renaming、eus、eus-context、fa、global-index-local-backend、global-index-replication-changes-local-backend、kerberos-auth-provider、ldif-local-backend、load-balancing、memory-local-backend、monitor-local-backend、null-local-backend、pass-through-authentication、plugin、proxy-ldap、rdn-changing、transformations、trust-store-local-backendのいずれかを指定できます。

create-workflow-element --type eus-context

このコマンドにより、EUSコンテキストのワークフロー要素が作成されます。サブオプションは次のとおりです:

--element-name name。新しいワークフロー要素の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t, --type type。作成するワークフロー要素のタイプ。typeの値には、ad-paging、backup-local-backend、db-local-backend,distribution、dn-renaming、eus、eus-context、fa、global-index-local-backend、global-index-replication-changes-local-backend、kerberos-auth-provider、ldif-local-backend、load-balancing、memory-local-backend、monitor-local-backend、null-local-backend、pass-through-authentication、plugin、proxy-ldap、rdn-changing、transformations、trust-store-local-backendのいずれかを指定できます。

create-workflow-element --type eus

このコマンドにより、EUSのワークフロー要素が作成されます。サブオプションは次のとおりです:

--element-name name。新しいワークフロー要素の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t, --type type。作成するワークフロー要素のタイプ。typeの値には、ad-paging、backup-local-backend、db-local-backend,distribution、dn-renaming、eus、eus-context、fa、global-index-local-backend、global-index-replication-changes-local-backend、kerberos-auth-provider、ldif-local-backend、load-balancing、memory-local-backend、monitor-local-backend、null-local-backend、pass-through-authentication、plugin、proxy-ldap、rdn-changing、transformations、trust-store-local-backendのいずれかを指定できます。

create-workflow-element --type fa

このコマンドにより、FAのワークフロー要素が作成されます。サブオプションは次のとおりです:

--element-name name。新しいワークフロー要素の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t, --type type。作成するワークフロー要素のタイプ。typeの値には、ad-paging、backup-local-backend、db-local-backend,distribution、dn-renaming、eus、eus-context、fa、global-index-local-backend、global-index-replication-changes-local-backend、kerberos-auth-provider、ldif-local-backend、load-balancing、memory-local-backend、monitor-local-backend、null-local-backend、pass-through-authentication、plugin、proxy-ldap、rdn-changing、transformations、trust-store-local-backendのいずれかを指定できます。

create-workflow-element --type kerberos-auth-provider

このコマンドにより、Kerberos認証プロバイダのワークフロー要素が作成されます。サブオプションは次のとおりです:

--element-name name。新しいワークフロー要素の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t, --type type。作成するワークフロー要素のタイプ。typeの値には、ad-paging、backup-local-backend、db-local-backend,distribution、dn-renaming、eus、eus-context、fa、global-index-local-backend、global-index-replication-changes-local-backend、kerberos-auth-provider、ldif-local-backend、load-balancing、memory-local-backend、monitor-local-backend、null-local-backend、pass-through-authentication、plugin、proxy-ldap、rdn-changing、transformations、trust-store-local-backendのいずれかを指定できます。

create-workflow-element --type pass-through-authentication

このコマンドにより、パススルー認証のワークフロー要素が作成されます。サブオプションは次のとおりです:

--element-name name。新しいワークフロー要素の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t, --type type。作成するワークフロー要素のタイプ。typeの値には、ad-paging、backup-local-backend、db-local-backend,distribution、dn-renaming、eus、eus-context、fa、global-index-local-backend、global-index-replication-changes-local-backend、kerberos-auth-provider、ldif-local-backend、load-balancing、memory-local-backend、monitor-local-backend、null-local-backend、pass-through-authentication、plugin、proxy-ldap、rdn-changing、transformations、trust-store-local-backendのいずれかを指定できます。

create-workflow-element --type plugin

このコマンドにより、プラグインのワークフロー要素が作成されます。サブオプションは次のとおりです:

--element-name name。新しいワークフロー要素の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t, --type type。作成するワークフロー要素のタイプ。typeの値には、ad-paging、backup-local-backend、db-local-backend,distribution、dn-renaming、eus、eus-context、fa、global-index-local-backend、global-index-replication-changes-local-backend、kerberos-auth-provider、ldif-local-backend、load-balancing、memory-local-backend、monitor-local-backend、null-local-backend、pass-through-authentication、plugin、proxy-ldap、rdn-changing、transformations、trust-store-local-backendのいずれかを指定できます。

delete-workflow-element

このコマンドにより、ワークフロー要素が削除されます。サブオプションは次のとおりです:

--element-name name。ワークフロー要素の名前。

-f, --force。存在しないワークフロー要素を無視します。

list-workflow-elements

既存のワークフロー要素をリストします。サブオプションは次のとおりです:

--property property。表示されるプロパティの名前。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

set-workflow-element-prop

ワークフロー要素のプロパティを変更します。サブオプションは次のとおりです:

--element-name name。ワークフロー要素の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

A.2.4.10 リモート記憶域サブコマンド

この項では、様々なリモート記憶域操作のサブコマンドについて説明します。

create-extension --type ldap-server

このコマンドにより、LDAPサーバー拡張が作成されます。サブオプションは次のとおりです:

--extension-name name。新しい拡張の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t, --type type。作成する拡張のタイプ。typeの値には、global-index-catalog、global-index-catalogs-shared-cache、ldap-serverのいずれかを指定できます。

create-workflow-element --type proxy-ldap

このコマンドにより、プロキシLDAPのワークフロー要素が作成されます。サブオプションは次のとおりです:

--element-name name。新しいワークフロー要素の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t, --type type。作成するワークフロー要素のタイプ。typeの値には、ad-paging、backup-local-backend、db-local-backend,distribution、dn-renaming、eus、eus-context、fa、global-index-local-backend、global-index-replication-changes-local-backend、kerberos-auth-provider、ldif-local-backend、load-balancing、memory-local-backend、monitor-local-backend、null-local-backend、pass-through-authentication、plugin、proxy-ldap、rdn-changing、transformations、trust-store-local-backendのいずれかを指定できます。

delete-extension

を削除します。サブオプションは次のとおりです:

--extension-name name。拡張の名前。

-f,--force。存在しない拡張を無視します。

delete-workflow-element

ワークフロー要素を削除します。サブオプションは次のとおりです:

--element-name name。ワークフロー要素の名前。

-f,--force。存在しないワークフロー要素を無視します。

list-extensions

既存の拡張をリストします。サブオプションは次のとおりです:

--property property。表示されるプロパティの名前。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

list-workflow-elements

既存のワークフロー要素をリストします。サブオプションは次のとおりです:

--property property。表示されるプロパティの名前。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

set-extension-prop

このコマンドにより、拡張のプロパティが変更されます。サブオプションは次のとおりです:

--extension-name name。拡張の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

set-workflow-element-prop

このコマンドにより、ワークフロー要素のプロパティが変更されます。サブオプションは次のとおりです:

--element-name name。ワークフロー要素の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

A.2.4.11 レプリケーション・サブコマンド

この項では、様々なレプリケーション操作のサブコマンドについて説明します。

create-plugin --type dsee-gateway

プラグインを作成します。サブオプションは次のとおりです:

--plugin-name name。プラグインの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t, --type type。作成するプラグインのタイプ。typeの値には、dsee-gateway、password-policy-import、referential-integrity、seven-bit-clean、unique-attributeのいずれかを指定できます。

create-gateway-domain

ゲートウェイ・ドメインを作成します。サブオプションは次のとおりです:

--plugin-name name。DSEEゲートウェイ・プラグインの名前。

--domain-name name。ゲートウェイ・ドメインの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

create-replication-domain

レプリケーション・ドメインを作成します。サブオプションは次のとおりです:

--provider-name name。マルチマスター同期化プロバイダの名前。

--domain-name name。新しいレプリケーション・ドメインの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

create-replication-server

レプリケーション・サーバーを作成します。サブオプションは次のとおりです:

--provider-name name。マルチマスター同期化プロバイダの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

create-synchronization-provider

同期化プロバイダを作成します。サブオプションは次のとおりです:

--provider-name name。新しい同期化プロバイダの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t,--type type。作成する同期化プロバイダのタイプ。typeの値には、custom、replicationのいずれかを指定できます。

delete-gateway-domain

ゲートウェイ・ドメインを削除します。サブオプションは次のとおりです:

--plugin-name name。DSEEゲートウェイ・プラグインの名前。

--domain-name name。ゲートウェイ・ドメインの名前。

-f, --force。存在しないゲートウェイ・ドメインを無視します。

delete-plugin

プラグインを削除します。サブオプションは次のとおりです:

--plugin-name name。プラグインの名前。

-f,--force。存在しないプラグインを無視します。

delete-replication-domain

レプリケーション・ドメインを削除します。サブオプションは次のとおりです:

--provider-name name。同期化プロバイダの名前。

--domain-name name。レプリケーション・ドメインの名前。

-f,--force。存在しないレプリケーション・ドメインを無視します。

delete-replication-server

レプリケーション・サーバーを削除します。サブオプションは次のとおりです:

--provider-name name。同期化プロバイダの名前。

-f,--force。存在しないレプリケーション・サーバーを無視します。

delete-synchronization-provider

同期化プロバイダを削除します。サブオプションは次のとおりです:

--provider-name name。同期化プロバイダの名前。

-f,--force。存在しない同期化プロバイダを無視します。

get-external-changelog-domain-prop

外部変更ログ・ドメインのプロパティを表示します。サブオプションは次のとおりです:

--provider-name name。レプリケーション同期化プロバイダの名前。

--domain-name name。レプリケーション・ドメインの名前。

--property property。表示されるプロパティの名前。

-E,--record。表示出力を1行ごとに1つのプロパティ値を表示するように変更します。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

get-gateway-domain-prop

ゲートウェイ・ドメインのプロパティを表示します。

--plugin-name name。DSEEゲートウェイ・プラグインの名前。

--domain-name name。ゲートウェイ・ドメインの名前。

--property property。表示されるプロパティの名前。

-E,--record。表示出力を1行ごとに1つのプロパティ値を表示するように変更します。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

get-replication-domain-prop

レプリケーション・ドメインのプロパティを表示します。サブオプションは次のとおりです:

--provider-name name。マルチマスター同期化プロバイダの名前。

--domain-name name。レプリケーション・ドメインの名前。

--property property。表示されるプロパティの名前。

-E,--record。表示出力を1行ごとに1つのプロパティ値を表示するように変更します。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

get-replication-server-prop

レプリケーション・サーバーのプロパティを表示します。サブオプションは次のとおりです:

--provider-name name。マルチマスター同期化プロバイダの名前。

--property property。表示されるプロパティの名前。

-E, --record。表示出力を1行ごとに1つのプロパティ値を表示するように変更します。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

get-synchronization-provider-prop

同期化プロバイダのプロパティを表示します。サブオプションは次のとおりです:

--provider-name name。同期化プロバイダの名前。

--property property。表示されるプロパティの名前。

-E,--record。表示出力を1行ごとに1つのプロパティ値を表示するように変更します。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

list-plugins

既存のプラグインをリストします。サブオプションは次のとおりです:

--property property。表示されるプロパティの名前。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

list-gateway-domains

既存のゲートウェイ・ドメインをリストします。サブオプションは次のとおりです。

--plugin-name name。DSEEゲートウェイ・プラグインの名前。

--property property。表示されるプロパティの名前。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

list-replication-domains

既存のレプリケーション・ドメインをリストします。サブオプションは次のとおりです:

--provider-name name。レプリケーション同期化プロバイダの名前。

--property property。表示されるプロパティの名前。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

list-replication-server

既存のレプリケーション・サーバーをリストします。サブオプションは次のとおりです:

--provider-name name。レプリケーション同期化プロバイダの名前。

--property property。表示されるプロパティの名前。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

list-synchronization-providers

既存の同期化プロバイダをリストします。サブオプションは次のとおりです:

--property property。表示されるプロパティの名前。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

set-external-changelog-domain-prop

外部変更ログ・ドメインのプロパティを変更します。サブオプションは次のとおりです:

--provider-name name。レプリケーション同期化プロバイダの名前。

--domain-name name。レプリケーション・ドメインの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

set-gateway-domain-prop

ゲートウェイ・ドメインのプロパティを変更します。サブオプションは次のとおりです:

--plugin-name name。DSEEゲートウェイ・プラグインの名前。

--domain-name name。ゲートウェイ・ドメインの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

set-plugin-prop

プラグインのプロパティを変更します。サブオプションは次のとおりです:

--plugin-name name。プラグインの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

set-replication-domain-prop

レプリケーション・ドメインのプロパティを変更します。サブオプションは次のとおりです:

--provider-name name。レプリケーション同期化プロバイダの名前。

--domain-name name。レプリケーション・ドメインの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

set-replication-server-prop

レプリケーション・サーバーのプロパティを変更します。サブオプションは次のとおりです:

--provider-name name。レプリケーション同期化プロバイダの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

set-synchronization-provider-prop

同期化プロバイダのプロパティを変更します。サブオプションは次のとおりです:

--provider-name name。同期化プロバイダの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

A.2.4.12 スキーマ・サブコマンド

この項では、様々なスキーマ操作のサブコマンドについて説明します。

create-attribute-syntax

このコマンドはプロキシに対してサポートされていません。

属性構文を作成します。サブオプションは次のとおりです:

--syntax-name name。新しい属性構文の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t,--type type。作成する属性構文のタイプ。typeの値には、attribute-type-description、directory-string、generic、またはtelephone-numberのいずれかを指定できます。

create-matching-rule

このコマンドはプロキシに対してサポートされていません。

一致ルールを作成します。サブオプションは次のとおりです:

--rule-name name。新しい一致ルールの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t,--type type。作成する一致ルールのタイプ。typeの値には、collationまたはgeneric.のいずれかを指定できます。

delete-attribute-syntax

このコマンドはプロキシに対してサポートされていません。

属性構文を削除します。サブオプションは次のとおりです:

--syntax-name name。属性構文の名前。

-f,--force。存在しない属性構文を無視します。

delete-matching-rule

このコマンドはプロキシに対してサポートされていません。

一致ルールを削除します。サブオプションは次のとおりです:

--rule-name name。一致ルールの名前。

-f,--force。存在しない一致ルールを無視します。

get-attribute-syntax-prop

このコマンドはプロキシに対してサポートされていません。

属性構文のプロパティを表示します。サブオプションは次のとおりです:

--syntax-name name。属性構文の名前。

--property property。表示されるプロパティの名前。

-E,--record。表示出力を1行ごとに1つのプロパティ値を表示するように変更します。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

get-matching-rule-prop

このコマンドはプロキシに対してサポートされていません。

一致ルールのプロパティを表示します。サブオプションは次のとおりです:

--rule-name name。一致ルールの名前。

--property property。表示されるプロパティの名前。

-E,--record。表示出力を1行ごとに1つのプロパティ値を表示するように変更します。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

list-attribute-syntaxes

このコマンドはプロキシに対してサポートされていません。

既存の属性構文をリストします。サブオプションは次のとおりです:

--property property。表示されるプロパティの名前。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

list-matching-rules

このコマンドはプロキシに対してサポートされていません。

既存の一致ルールをリストします。サブオプションは次のとおりです:

--property property。表示されるプロパティの名前。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

set-attribute-syntax-prop

このコマンドはプロキシに対してサポートされていません。

属性構文のプロパティを変更します。サブオプションは次のとおりです:

--syntax-name name。属性構文の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

set-matching-rule-prop

このコマンドはプロキシに対してサポートされていません。

一致ルールのプロパティを変更します。サブオプションは次のとおりです:

--rule-name name。一致ルールの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

A.2.4.13 セキュリティ・サブコマンド

create-key-manager-provider

キー・マネージャ・プロバイダを作成します。サブオプションは次のとおりです:

--provider-name name。新しいキー・マネージャ・プロバイダの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t,--type type。作成するキー・マネージャ・プロバイダのタイプ。typeの値には、file-based、custom、またはpkcs11のいずれかを指定できます。

PKCS#11は、プロキシ・サーバー・インスタンスに対してサポートされていません。

create-sasl-mechanism-handler

このコマンドはプロキシに対してサポートされていません。

SASLメカニズム・ハンドラを作成します。サブオプションは次のとおりです:

--handler-name name。新しいSASLメカニズム・ハンドラの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t,--type type。作成するSASLメカニズム・ハンドラのタイプ。typeの値には、anonymous、cram-md5、digest-md5、external、custom、gssapi、またはplainのいずれかを指定できます。

create-trust-manager-provider

信頼マネージャ・プロバイダを作成します。サブオプションは次のとおりです:

--provider-name name。新しい信頼マネージャ・プロバイダの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t,--type type。作成する信頼マネージャ・プロバイダのタイプ。typeの値には、blind、file-based、またはcustomのいずれかを指定できます。

create-workflow-element --type trust-store-local-backend

ワークフロー要素を作成します。サブオプションは次のとおりです:

--element-name name。新しいワークフロー要素の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t,--type type。作成するワークフロー要素のタイプ。typeの値には、ad-paging、backup-local-backend、db-local-backend、distribution、dn-renaming、eus、eus-context、fa、global-index-local-backend、global-index-replication-changes-local-backend、kerberos-auth-provider、ldif-local-backend、load-balancing、memory-local-backend、monitor-local-backend、null-local-backend、pass-through-authentication、plugin、proxy-ldap、rdn-changing、transformations、trust-store-local-backendのいずれかを指定できます。

delete-key-manager-provider

キー・マネージャ・プロバイダを削除します。サブオプションは次のとおりです:

--provider-name name。キー・マネージャ・プロバイダの名前。

-f,--force。存在しないキー・マネージャ・プロバイダを無視します。

delete-sasl-mechanism-handler

このコマンドはプロキシに対してサポートされていません。

SASLメカニズム・ハンドラを削除します。サブオプションは次のとおりです:

--handler-name name。SASLメカニズム・ハンドラの名前。

-f,--force。存在しないSASLメカニズム・ハンドラを無視します。

delete-trust-manager-provider

信頼マネージャ・プロバイダを削除します。サブオプションは次のとおりです:

--provider-name name。信頼マネージャ・プロバイダの名前。

-f,--force。存在しない信頼マネージャ・プロバイダを無視します。

delete-workflow-element

ワークフロー要素を削除します。サブオプションは次のとおりです:

--element-name name。ワークフロー要素の名前。

-f,--force。存在しないワークフロー要素を無視します。

get-access-control-handler-prop

アクセス制御ハンドラのプロパティを表示します。サブオプションは次のとおりです:

--property property。表示されるプロパティの名前。

-E,--record。表示出力を1行ごとに1つのプロパティ値を表示するように変更します。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

get-crypto-manager-prop

暗号化マネージャのプロパティを表示します。サブオプションは次のとおりです:

--property property。表示されるプロパティの名前。

-E,--record。表示出力を1行ごとに1つのプロパティ値を表示するように変更します。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

get-key-manager-provider-prop

キー・マネージャ・プロバイダのプロパティを表示します。サブオプションは次のとおりです:

--provider-name name。キー・マネージャ・プロバイダの名前。

--property property。表示されるプロパティの名前。

-E,--record。表示出力を1行ごとに1つのプロパティ値を表示するように変更します。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

get-root-dn-prop

ルートDNのプロパティを表示します。サブオプションは次のとおりです:

--property property。表示されるプロパティの名前。

-E,--record。表示出力を1行ごとに1つのプロパティ値を表示するように変更します。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

get-sasl-mechanism-handler-prop

SASLメカニズム・ハンドラのプロパティを表示します。サブオプションは次のとおりです:

--handler-name name。SASLメカニズム・ハンドラの名前。

--property property。表示されるプロパティの名前。

-E,--record。表示出力を1行ごとに1つのプロパティ値を表示するように変更します。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

get-trust-manager-provider-prop

信頼マネージャ・プロバイダのプロパティを表示します。サブオプションは次のとおりです:

--provider-name name。信頼マネージャ・プロバイダの名前。

--property property。表示されるプロパティの名前。

-E,--record。表示出力を1行ごとに1つのプロパティ値を表示するように変更します。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

list-key-manager-providers

既存のキー・マネージャ・プロバイダをリストします。サブオプションは次のとおりです:

--property property。表示されるプロパティの名前。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

list-sasl-mechanism-handlers

このコマンドはプロキシに対してサポートされていません。

既存のSASLメカニズム・ハンドラをリストします。サブオプションは次のとおりです:

--property property。表示されるプロパティの名前。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

list-trust-manager-providers

既存の信頼マネージャ・プロバイダをリストします。サブオプションは次のとおりです:

--property property。表示されるプロパティの名前。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

list-workflow-elements

既存のワークフロー要素をリストします。サブオプションは次のとおりです:

--property property。表示されるプロパティの名前。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

set-access-control-handler-prop

アクセス制御ハンドラのプロパティを変更します。サブオプションは次のとおりです:

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

set-crypto-manager-prop

暗号化マネージャのプロパティを変更します。サブオプションは次のとおりです:

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

set-key-manager-provider-prop

キー・マネージャ・プロバイダのプロパティを変更します。サブオプションは次のとおりです:

--provider-name name。キー・マネージャ・プロバイダの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

set-root-dn-prop

ルートDNのプロパティを変更します。サブオプションは次のとおりです:

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

set-sasl-mechanism-handler-prop

このコマンドはプロキシに対してサポートされていません。

SASLメカニズム・ハンドラのプロパティを変更します。サブオプションは次のとおりです:

--handler-name name。SASLメカニズム・ハンドラの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

set-trust-manager-provider-prop

信頼マネージャ・プロバイダのプロパティを変更します。サブオプションは次のとおりです:

--provider-name name。信頼マネージャ・プロバイダの名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

set-workflow-element-prop

ワークフロー要素のプロパティを変更します。サブオプションは次のとおりです:

--element-name name。ワークフロー要素の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

A.2.4.14 仮想化サブコマンド

この項では、仮想化のサブコマンドについて説明します。

create-transformation --type add-inbound-attribute

「インバウンドの追加」属性の変換を作成します。サブオプションは次のとおりです:

--transformation-name name。新しい変換の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t,--type type。作成する変換のタイプ。typeの値には、add-inbound-attribute、add-outbound-attribute、filter-inbound-attribute、filter-outbound-attribute、map-attributeのいずれかを指定できます。各変換の詳細は、第11.6.3.2項「CLIを使用した変換の構成例」を参照してください。

create-transformation --type add-outbound-attribute

「アウトバウンドの追加」属性の変換を作成します。サブオプションは次のとおりです:

--transformation-name name。新しい変換の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t,--type type。作成する変換のタイプ。typeの値には、add-inbound-attribute、add-outbound-attribute、filter-inbound-attribute、filter-outbound-attribute、map-attributeのいずれかを指定できます。各変換の詳細は、第11.6.3.2項「CLIを使用した変換の構成例」を参照してください。

create-workflow-element --type dn-renaming

DNリネーム・ワークフロー要素を作成します。サブオプションは次のとおりです:

--element-name name。新しいワークフロー要素の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t,--type type。作成するワークフロー要素のタイプ。typeの値には、ad-paging、backup-local-backend、db-local-backend,distribution、dn-renaming、eus、eus-context、fa、global-index-local-backend、global-index-replication-changes-local-backend、kerberos-auth-provider、ldif-local-backend、load-balancing、memory-local-backend、monitor-local-backend、null-local-backend、pass-through-authentication、plugin、proxy-ldap、rdn-changing、transformations、trust-store-local-backendのいずれかを指定できます。

create-transformation --type filter-inbound-attribute

「インバウンドのフィルタ」属性の変換を作成します。サブオプションは次のとおりです:

--transformation-name name。新しい変換の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t,--type type。作成する変換のタイプ。typeの値には、add-inbound-attribute、add-outbound-attribute、filter-inbound-attribute、filter-outbound-attribute、map-attributeのいずれかを指定できます。各変換の詳細は、第11.6.3.2項「CLIを使用した変換の構成例」を参照してください。

create-transformation --type filter-outbound-attribute

「アウトバウンドのフィルタ」属性の変換を作成します。サブオプションは次のとおりです:

--transformation-name name。新しい変換の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t,--type type。作成する変換のタイプ。typeの値には、add-inbound-attribute、add-outbound-attribute、filter-inbound-attribute、filter-outbound-attribute、map-attributeのいずれかを指定できます。各変換の詳細は、第11.6.3.2項「CLIを使用した変換の構成例」を参照してください。

create-transformation --type map-attribute

属性のマップの変換を作成します。サブオプションは次のとおりです:

--transformation-name name。新しい変換の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t,--type type。作成する変換のタイプ。typeの値には、add-inbound-attribute、add-outbound-attribute、filter-inbound-attribute、filter-outbound-attribute、map-attributeのいずれかを指定できます。各変換の詳細は、第11.6.3.2項「CLIを使用した変換の構成例」を参照してください。

create-workflow-element --type rdn-changing

RDN変更ワークフロー要素を作成します。サブオプションは次のとおりです:

--element-name name。ワークフロー要素の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t,--type type。作成するワークフロー要素のタイプ。typeの値には、ad-paging、backup-local-backend、db-local-backend、distribution、dn-renaming、eus、eus-context、fa、global-index-local-backend、global-index-replication-changes-local-backend、kerberos-auth-provider、ldif-local-backend、load-balancing、memory-local-backend、monitor-local-backend、null-local-backend、pass-through-authentication、plugin、proxy-ldap、rdn-changing、transformations、trust-store-local-backendのいずれかを指定できます。

create-transformation

変換を作成します。サブオプションは次のとおりです:

--transformation-name name。新しい変換の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t,--type type。作成する変換のタイプ。typeの値には、add-inbound-attribute、dd-outbound-attribute、filter-inbound-attribute、filter-outbound-attribute、map-attributeのいずれかを指定できます。

create-workflow-element --type transformations

変換ワークフロー要素を作成します。サブオプションは次のとおりです:

--element-name name。新しいワークフロー要素の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

-t,--type type。作成するワークフロー要素のタイプ。typeの値には、ad-paging、backup-local-backend、db-local-backend,distribution、dn-renaming、eus、eus-context、fa、global-index-local-backend、global-index-replication-changes-local-backend、kerberos-auth-provider、ldif-local-backend、load-balancing、memory-local-backend、monitor-local-backend、null-local-backend、pass-through-authentication、plugin、proxy-ldap、rdn-changing、transformations、trust-store-local-backendのいずれかを指定できます。

delete-transformation

変換を削除します。サブオプションは次のとおりです:

--transformation-name name。変換名。

-f, --force。存在しない変換を無視します。

delete-workflow-element

ワークフロー要素を削除します。サブオプションは次のとおりです:

--element-name name。ワークフロー要素の名前。

-f, --force。存在しないワークフロー要素を無視します。

get-transformation-prop

変換のプロパティを表示します。サブオプションは次のとおりです:

--transformation-name name。変換要素の名前。

--property property。表示されるプロパティの名前。

-E,--record。表示出力を1行ごとに1つのプロパティ値を表示するように変更します。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

list-transformations

既存の変換をリストします。サブオプションは次のとおりです:

--property property。表示されるプロパティの名前。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

list-workflow-elements

既存のワークフロー要素をリストします。サブオプションは次のとおりです:

--property property。表示されるプロパティの名前。

-z,--unit-size unit。指定された単位を使用してサイズ・データを表示します。unitの値には、b、kb、mb、gb、またはtb(バイト、キロバイト、メガバイト、ギガバイト、またはテラバイト)のいずれかを指定できます。

-m,--unit-time unit。指定された単位を使用して時間データを表示します。unitの値には、ms、s、m、h、d、またはw(ミリ秒、秒、分、時、日、または週)のいずれかを指定できます。

set-transformation-prop

変換のプロパティを変更します。サブオプションは次のとおりです:

--transformation-name name。変換要素の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

set-workflow-element-prop

ワークフロー要素のプロパティを変更します。サブオプションは次のとおりです:

--element-name name。ワークフロー要素の名前。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。

A.2.4.15 オプション

dsconfigコマンドは、短いフォーム(例: -h hostname)または同等の長いフォーム(例: --hostname hostname)のいずれかでオプションを受け入れます。

--advanced

拡張コンポーネントとプロパティの構成を可能にします。

A.2.4.16 LDAP接続オプション

dsconfigコマンドは、管理コネクタを介してSSL上のディレクトリ・サーバーに接続します(第14.3項「サーバーへの管理トラフィックの管理」で説明しています)。これらの接続オプションは、ディレクトリ・サーバーとの接続に使用します。

-D, --bindDN bindDN

バインドDNを使用してサーバーにバインドします。このオプションは簡易認証の実行時に使用されます。SASL認証を使用する場合、このオプションは必要ありません。このオプションのデフォルト値はcn=Directory Managerです。

SASLは、プロキシ・サーバー・インスタンスに対してサポートされていません。

-h, --hostname hostname

指定されたホスト名またはIPアドレスのサーバーに接続します。このオプションが指定されない場合は、localhostのデフォルトが使用されます。

-j, --bindPasswordFile filename

サーバーに対して認証を受ける際、指定したファイルにバインド・パスワードを使用します。

-K, --keyStorePath path

指定されたパスにクライアント・キーストア証明書を使用します。

-N, --certNickname nickname

SSLクライアント認証に証明書のニックネームを使用します。

-o, --saslOption name=value

指定されたオプションをSASL認証に使用します。

SASLは、プロキシ・サーバー・インスタンスに対してサポートされていません。

-p, --port port

指定された管理ポートでサーバーに接続します。このオプションが指定されない場合は、ローカル構成の管理ポートが使用されます。

-P, --trustStorePath path

指定されたパスにクライアント・トラスト・ストア証明書を使用します。このオプションは、--trustAllを使用している場合は必要ありません。ただし、本番環境で作業する場合はトラスト・ストアを使用する必要があります。

-u, --keyStorePasswordFile filename

クライアント・キーストアの証明書にアクセスするために、指定されたファイルでパスワードを使用します。このオプションは、--keyStorePathを使用する場合のみ必須です。

-U, --trustStorePasswordFile filename

クライアント・トラスト・ストアの証明書にアクセスするために、指定されたファイルでパスワードを使用します。このオプションは、--trustStorePathを使用していて、指定したトラスト・ストアがコンテンツへのアクセスにパスワードを必要とする場合のみ必須です(ほとんどのトラスト・ストアでは必要とされません)。

-X, --trustAll

サーバーによって提示されるすべてのサーバーSSL証明書を信頼します。このオプションは便宜的に、かつテストの目的で使用できますが、セキュリティ上の理由から、トラスト・ストアを使用してクライアントがサーバーの証明書を受け入れるかどうかを判別する必要があります。クライアントとサーバーが同じインスタンスで実行している場合は、証明書の相互作用は生じません。

--connectTimeout {timeout}

これは、接続の確立に許容される最長時間(ミリ秒)の指定に使用します。タイムアウトを指定しない場合は、0を使用します。デフォルト値は30000です。

A.2.4.17 コマンド入力/出力オプション

--commandFilePath path

このコマンドがインタラクティブ・モードで実行されているときに同等の非インタラクティブ・コマンドの書込み先となるファイルへのフルパスを指定します。

--displayCommand

このコマンドがインタラクティブ・モードで実行されているときに、同等の非インタラクティブ・オプションを標準出力に表示します。

-F, --batchFilePath batchFilePath

実行される一連のdsconfigコマンドが含まれているファイルへのパスを指定します。このオプションでは、行分割、バックスラッシュ('\')、引用文字列内での引用符(")とエスケープ付引用符(\")、およびコメント用ハッシュ('#')をサポートしています。

-n, --no-prompt

非インタラクティブ・モードを使用します。コマンドのデータが見つからない場合、プロンプトが表示されず、コマンドは失敗します。

--noPropertiesFile

このコマンドでは、デフォルトのコマンドライン・オプションを取得するためにプロパティ・ファイルが使用されないことを示します。

--sortMenuItems

インタラクティブ・モードを使用しているときに、メニュー・アイテムをソートできるようにします。ソート順序は、ユーザー・ロケールのアルファベット順です。

--propertiesFilePath path

デフォルトのコマンドライン・オプションが含まれているプロパティ・ファイルへのパスを指定します。

-Q, --quiet

最小モードで実行します。プロセス中に有意なエラーが発生しないかぎり、出力は生成されません。

-s, --script-friendly

スクリプト・フレンドリ・モードで実行します。スクリプトが解析しやすいフォーマットで出力を表示します。

-v, --verbose

標準出力に診断を表示する冗長モードで実行します。

A.2.4.18 一般オプション

-?, -H, --help

このコマンドに対するコマンドライン使用情報を表示し、サーバーの停止または再起動を試行しないで終了します。

-V, --version

サーバーのバージョン情報を表示して、このコマンドの実行を試みるかわりに終了します。

A.2.4.19 例

次の例は、dsconfigコマンドの使用方法を示しています。その他のdsconfigの例については、第14.1項「dsconfigによるサーバー構成の管理」を参照してください。

例A-12 グローバル・ヘルプ・サブコマンドとグローバル・オプションの表示

次のコマンドは、サーバーに対して使用可能なグローバル・ヘルプ・サブコマンドとグローバル・オプションを表示します:

$ dsconfig --help

例A-13 コンポーネントのサブコマンドとヘルプ情報の表示

次のコマンドは、認証および認可に関連するサブコマンドを表示します:

$ dsconfig --help-security

例A-14 個別サブコマンドのヘルプの表示

次のコマンドは、set-distribution-partition-propサブコマンドのヘルプ情報を表示します:

$ dsconfig set-distribution-partition-prop --help

例A-15 コンポーネントのプロパティの表示

次のコマンドは、local-db-indexのプロパティを表示します。-tを指定しない場合は、すべてのコンポーネントのプロパティが表示されます。

$ dsconfig list-properties -c local-db-index
Option Types:

r -- Property value(s) are readable
w -- Property value(s) are writable
m -- The property is mandatory
s -- The property is single-valued
a -- Administrative action is required for changes to take effect

Component       Type     Property                        Options  Syntax
------------------------------------------------------------------------------
local-db-index  generic  attribute                       r-ms-    OID
local-db-index  generic  index-entry-limit               rw-sa    INTEGER
local-db-index  generic  index-extensible-matching-rule  rw--a    LOCALE | OID
local-db-index  generic  index-type                      rwm-a    TYPE

次のコマンドは、crypto-managerのプロパティを表示します。

$ dsconfig list-properties -c crypto-manager
Option Types:

r -- Property value(s) are readable
w -- Property value(s) are writable
m -- The property is mandatory
s -- The property is single-valued
a -- Administrative action is required for changes to take effect

Component       Type     Property                     Options  Syntax
----------------------------------------------------------------------
crypto-manager  generic  key-wrapping-transformation  rw-s-    STRING
crypto-manager  generic  ssl-cert-nickname            rw-sa    STRING
crypto-manager  generic  ssl-cipher-suite             rw---    STRING
crypto-manager  generic  ssl-encryption               rw-s-    BOOLEAN
crypto-manager  generic  ssl-protocol                 rw---    STRING

例A-16 -F, --batchFilePathサブコマンドでサポートされるパラメータ

この例では、-F, --batchFilePathサブコマンドでサポートされる様々なパラメータについて説明しています。

行分割アプローチを使用して-F, --batchFilePathサブコマンドを実行します。ファイル/tmp/batchには、次のコマンド・セットが含まれています:

create-workflow-element \
--type db-local-backend \
--set base-dn:cn=myexample,cn=com \
--set enabled:true \
--element-name myBackend

-F, --batchFilePathサブコマンドを実行します。

dsconfig -X -j /path/pwd-file -F /tmp/batch -n

引用符文字列内で引用符(")とエスケープ付引用符(\")を使用して、-F, --batchFilePathサブコマンドを実行します。ファイル/tmp/batchには、次のコマンド・セットが含まれています:

set-access-control-handler-prop \
--add global-aci:"(targetattr != \"description || mail\") \
(version 3.0; acl \"Allow self entry modification except for \
description and mail attributes\"; allow (write)userdn =\"ldap:///self\";) "

-F, --batchFilePathサブコマンドを実行します。

dsconfig -X  -j /path/pwd-file -F /tmp/batch -n

例A-17 sortMenuItemオプションを使用したロケール別の情報表示

この例では、--sortMenuItemsサブコマンドを使用してユーザーのロケール別に情報を表示する方法について説明します。この例では、dsconfigコマンドを実行する際に、--sortMenuItemsサブコマンドを指定した場合と指定しない場合の情報の表示方法の相違を強調表示しています。ステップ2ではメニューが米国式の順序で表示されるのに対し、ステップ3ではフランス式の順序で表示されます。

1. 次のコマンドを使用して、目的のロケールを設定します:

export LC_ALL=fr_FR.UTF-8

2. --sortMenuItemsサブコマンドを指定しないで、dsconfigコマンドを実行します。

dsconfig -j /path/pwd-file

>>>> SpÃ©cifiez les paramÃ¨tres de connexion LDAP Oracle Unified Directory

Nom d'hÃ´te ou adresse IP du serveur d'annuaire [nixes] :
NumÃ©ro de port d'administration du serveur d'annuaire [11444] :
DN de liaison de l'administrateur [cn=Directory Manager] :

>>>> Menu principal de la console de configuration Oracle Unified Directory

Que voulez-vous configurer ?

1)   Gestionnaire de contrÃ´le      26)  Index VLV de base de donnÃ©es
d'accÃ¨s                             locale
2)   Gestionnaire de notification   27)  Editeur de journal
de statuts de comptes
3)   Connecteur d'administration    28)  StratÃ©gie de conservation de
journal
4)   Gestionnaire d'alertes         29)  StratÃ©gie de rotation des
journaux
5)   Syntaxe d'attribut             30)  RÃ¨gle de correspondance
6)   Mappeur de certificats         31)  Fournisseur de surveillance
7)   Gestionnaire de connexions     32)  Groupe de rÃ©seaux
8)   Gestionnaire de cryptage       33)  StratÃ©gie de qualitÃ© de service
(QoS) du groupe de rÃ©seaux
9)   Cible de dÃ©bogage             34)  GÃ©nÃ©rateur de mot de passe
10)  Algorithme de distribution     35)  StratÃ©gie de mot de passe
11)  Partition de distribution      36)  SchÃ©ma de stockage de mot de
passe
12)  Cache d'entrÃ©e                37)  Valideur de mot de passe
13)  Gestionnaire d'opÃ©rations     38)  Plug-in
d'extension
14)  Extension                      39)  Racine de plug-in
15)  Domaine de journal des         40)  Domaine de rÃ©plication
modifications externe
16)  Domaine de passerelle          41)  Serveur de rÃ©plication
17)  Configuration globale          42)  Nom distinctif (DN) racine
18)  Index global                   43)  Back-end de la DSE racine
19)  Domaine de rÃ©plication du     44)  Gestionnaire de mÃ©canisme SASL
catalogue d'index globaux
20)  ImplÃ©mentation de groupe      45)  Fournisseur de synchronisation
21)  Mappeur d'identitÃ©s           46)  Fournisseur de gestionnaire de
sÃ©curisation
22)  Fournisseur de gestionnaire    47)  Attribut virtuel
de clÃ©s
23)  Algorithme d'Ã©quilibrage de   48)  File d'attente de travaux
charge
24)  Route d'Ã©quilibrage de charge  49)  Workflow
25)  Index de base de donnÃ©es       50)  ElÃ©ment de workflow

q)   quit

Entrez votre choix :

3. --sortMenuItemsサブコマンドを指定して、dsconfigコマンドを実行します。

dsconfig -j /path/pwd-file --sortMenuItems

>>>> SpÃ©cifiez les paramÃ¨tres de connexion LDAP Oracle Unified Directory

Nom d'hÃ´te ou adresse IP du serveur d'annuaire [nixes] :
NumÃ©ro de port d'administration du serveur d'annuaire [11444] :
DN de liaison de l'administrateur [cn=Directory Manager] :

>>>> Menu principal de la console de configuration Oracle Unified Directory

Que voulez-vous configurer ?

1)   Algorithme d'Ã©quilibrage de   26)  Gestionnaire de mÃ©canisme SASL
charge
2)   Algorithme de distribution     27)  Gestionnaire de notification de
statuts de comptes
3)   Attribut virtuel               28)  Groupe de rÃ©seaux
4)   Back-end de la DSE racine      29)  GÃ©nÃ©rateur de mot de passe
5)   Cache d'entrÃ©e                30)  ImplÃ©mentation de groupe
6)   Cible de dÃ©bogage             31)  Index de base de donnÃ©es locale
7)   Configuration globale          32)  Index global
8)   Connecteur d'administration    33)  Index VLV de base de donnÃ©es
locale
9)   Domaine de journal des         34)  Mappeur d'identitÃ©s
modifications externe
10)  Domaine de passerelle          35)  Mappeur de certificats
11)  Domaine de rÃ©plication        36)  Nom distinctif (DN) racine
12)  Domaine de rÃ©plication du     37)  Partition de distribution
catalogue d'index globaux
13)  Editeur de journal             38)  Plug-in
14)  ElÃ©ment de workflow           39)  Racine de plug-in
15)  Extension                      40)  Route d'Ã©quilibrage de charge
16)  File d'attente de travaux      41)  RÃ¨gle de correspondance
17)  Fournisseur de gestionnaire    42)  SchÃ©ma de stockage de mot de
de clÃ©s                             passe
18)  Fournisseur de gestionnaire    43)  Serveur de rÃ©plication
de sÃ©curisation
19)  Fournisseur de surveillance    44)  StratÃ©gie de conservation de
journal
20)  Fournisseur de                 45)  StratÃ©gie de mot de passe
synchronisation
21)  Gestionnaire d'alertes         46)  StratÃ©gie de qualitÃ© de service
(QoS) du groupe de rÃ©seaux
22)  Gestionnaire d'opÃ©rations     47)  StratÃ©gie de rotation des
d'extension                         journaux
23)  Gestionnaire de connexions     48)  Syntaxe d'attribut
24)  Gestionnaire de contrÃ´le      49)  Valideur de mot de passe
d'accÃ¨s
25)  Gestionnaire de cryptage       50)  Workflow

q)   quit

Entrez votre choix :

A.2.4.20 終了コード

終了コード0は、操作が正常に終了したことを示します。1以上の終了コードは、処理中にエラーが発生したことを示します。

A.2.4.21 プロパティ・ファイルの使用方法

サーバーでは、dsconfigコマンドとともに使用されるデフォルトのオプション値を渡すプロパティ・ファイルの使用をサポートしています。プロパティ・ファイルは、様々な構成環境、特にスクリプト済アプリケーションまたは埋込みアプリケーションで作業する場合に便利です。詳細は、第A.1.2項「サーバー・コマンドによるプロパティ・ファイルの使用方法」を参照してください。

プロパティ・ファイルに保存可能なオプションは次のとおりです:

- bindDN

- bindPasswordFile

- certNickname

- hostname

- keyStorePasswordFile

- keyStorePath

- port

- saslOption
SASLは、プロキシ・サーバー・インスタンスに対してサポートされていません。

- trustAll

- trustStorePasswordFile

- trustStorePath

- useSSL

- useStartTLS

プロパティ・ファイルのエントリのフォーマットは、次のとおりです:

toolname.propertyname=propertyvalue

例:

dsconfig.trustAll=Yes

A.2.4.22 場所

- UNIXおよびLinux: INSTANCE_DIR/OUD/bin/dsconfig

- Windows: INSTANCE_DIR\OUD\bat\dsconfig.bat

A.2.4.23 関連コマンド

第A.2.7項「gicadm」

第A.2.6項「dsreplication」

A.2.5 dsjavaproperties

dsjavapropertiesコマンドは、各サーバー・コマンドで使用するJVMバージョンおよびJava引数を指定します。

A.2.5.1 シノプシス

dsjavaproperties [options]

A.2.5.2 説明

dsjavapropertiesコマンドを使用して、各サーバー・コマンドで使用するJVMバージョンおよびJava引数を指定できます。コマンド別のJVMおよびJava引数は、INSTANCE_DIR/OUD/config/java.propertiesに置かれているプロパティ・ファイル内で指定されます。dsjavapropertiesコマンドを実行しないかぎり、プロパティ・ファイルは使用されません。プロパティ・ファイルを編集する場合は、dsjavapropertiesを再実行して、新しい設定が考慮されるようにする必要があります。

dsjavapropertiesを使用して、-serverモードまたは-clientモードでJVMを使用してコマンドを実行するかどうか(特に引数)を指定できます。デフォルトでは、すべてのクライアント・アプリケーションは-clientモードで実行し、すべてのサーバー・ユーティリティは-serverモードで実行しています。一般に、-serverモードのスループットは-clientモードよりも高いものの、起動には若干多くの時間がかかります。

特定のコマンドについては(import-ldif、export-ldif、backup、およびrestore)、コマンドがオンライン・モードで実行しているか、またはオフライン・モードで実行しているかに応じて異なるJava引数(および異なるJVM)を指定することもできます。

overwrite-env-java-homeプロパティがjava.propertiesファイルでfalseに設定されている場合は、プロパティ・ファイルで指定された引数よりもOPENDS_JAVA_HOME環境変数が優先されます。overwrite-env-java-argsプロパティがjava.propertiesファイルでfalseに設定されている場合は、プロパティ・ファイルで指定された引数よりもOPENDS_JAVA_ARGS環境変数が優先されます。

A.2.5.3 オプション

dsjavapropertiesコマンドは、短いフォーム(例: -Q)または同等の長いフォーム(例: --quiet)のいずれかでオプションを受け入れます。

-Q, --quiet

最小モードで実行します。最小モードでは、進捗状況情報は標準出力に出力されません。

-?, -H, --help

このコマンドに対するコマンドライン使用情報を表示し、サーバーの停止または再起動を試行しないで終了します。

-V, --version

サーバーのバージョン情報を表示して、このコマンドの実行を試みるかわりに終了します。

A.2.5.4 例

次の例は、export—ldifコマンドの使用方法を示しています。

例A-18 スクリプトの変更

この例は、コマンドがサーバー・オンラインで実行されるときにJVMの最大ヒープ・サイズである256Mバイトを使用するようにexport-ldifスクリプトを変更する方法を示しています。

1. INSTANCE_DIR/OUD/config/java.propertiesファイルを次のように編集して、export-ldif.online引数を設定します:

export-ldif.online.java-args=-client -Xms8m -Xmx256m

2. dsjavapropertiesコマンドを実行して、変更を有効にします。

$ dsjavaproperties
The script files were successfully updated.  The Oracle Unified Directory
command-line utilities will use the java properties specified in the
properties file INSTANCE_DIR/OUD/config/java.properties

A.2.5.5 終了コード

終了コード0は、操作が正常に終了したことを示します。ゼロ以外の終了コードは、処理中にエラーが発生したことを示します。

A.2.5.6 場所

- UNIXおよびLinux: INSTANCE_DIR/OUD/bin/dsjavaproperties

- Windows: INSTANCE_DIR\OUD\bat\dsjavaproperties.bat

A.2.6 dsreplication

dsreplicationコマンドは、ディレクトリ・サーバー間でレプリケーションを構成して、サーバーのデータが同期化されるようにします。

このコマンドはプロキシに対してサポートされていません。

A.2.6.1 シノプシス

dsreplication [subcommands] [options]

A.2.6.2 説明

dsreplicationコマンドを使用してディレクトリ・サーバー間でレプリケーションを構成し、サーバーのデータを同期化することができます。まず、enableサブコマンドを使用してレプリケーションを有効にし、次にinitializeサブコマンドを使用して一方のディレクトリ・サーバーのコンテンツをもう一方のサーバーのコンテンツで初期化します。

dsreplicationコマンドは、管理コネクタを使用してSSL上のサーバーに接続します(第14.3項「サーバーへの管理トラフィックの管理」を参照すること)。

dsconfigコマンドと同様に、dsreplicationはインタラクティブ・モードで実行できるため、レプリケーションの設定プロセスを段階的に処理することができます。dsreplicationをインタラクティブ・モードで実行するには、次の例に示すように、パラメータを指定しないでコマンド名を入力します:

$ dsreplication
What do you want to do?

1)  Enable Replication
2)  Disable Replication
3)  Initialize Replication on one Server
4)  Initialize All Servers
5)  Pre External Initialization
6)  Post External Initialization
7)  Display Replication Status
8)  Purge Historical
9)  Set the trust flag of the Directory Server
10) Enable External Changelog
11) Disable External Changelog

c)  cancel

Enter choice: 1
...

同等の非インタラクティブ・コマンドを表示するには、--displayCommandオプションまたは--commandFilePathオプションを使用します。

A.2.6.3 サーバー・サブコマンド

dsreplicationコマンドで使用されるサブコマンドは、次のとおりです。

disable

指定されたベースDNに対して、指定されたディレクトリ・サーバーのレプリケーションを無効にします。このサブコマンドは、このサーバーがデータをレプリケートしているサーバーの構成内で、指定されたサーバーへの参照を削除します。サブオプションは次のとおりです:

-D, --bindDN bindDN。レプリケーションが無効になるサーバーへのバインドに使用されるDN。サーバーでグローバル管理者が定義されていない場合、またはレプリケートされる他のサーバーで参照を削除したくない場合には、このオプションを使用する必要があります。このオプションを指定すると、グローバル管理者に対して指定されたパスワードが使用されます。

-a, --disableAll。指定されたサーバーのレプリケーション構成を無効にします。サーバーのコンテンツはレプリケートされなくなり、レプリケーション・サーバー(変更ログとレプリケーション・ポート)が構成されている場合はそれが無効になります。

--disableReplicationServer。レプリケーション・サーバーを無効にします。指定されたサーバーで、レプリケーション・ポートと変更ログが無効になります。

-h, --hostname host。ディレクトリ・サーバーのホスト名またはIPアドレス。

-p, --port port。ディレクトリ・サーバーの管理ポート番号。

disable-changelog

一連のベースDNの外部変更ログを無効にします。レプリケートするデータが存在しない場合、関連付けられたレプリケーション構成がすべて削除されます。外部変更ログの詳細は、第26.5項「外部変更ログの使用」を参照してください。サブオプションは次のとおりです:

-h, --hostname host

ディレクトリ・サーバーのホスト名またはIPアドレス。

-p, --port port

ディレクトリ・サーバーの管理ポート番号。

-D, --bindDN bindDN

外部変更ログの構成場所であるサーバーとのバインドに使用するDN。デフォルト値はcn=Directory Managerです。

enable-changelog

一連のベースDNに対して外部変更ログを作成します。外部変更ログの機能により、特定のベースDNで実行された変更を取得できます。外部変更ログの詳細は、第26.5項「外部変更ログの使用」を参照してください。サブオプションは次のとおりです:

-h, --hostname host

ディレクトリ・サーバーのホスト名またはIPアドレス。

-p, --port port

ディレクトリ・サーバーの管理ポート番号。

-D, --bindDN bindDN

外部変更ログの構成場所であるサーバーとのバインドに使用するDN。デフォルト値はcn=Directory Managerです。

-r, --replicationPort port

変更ログの構成に必要なポート。このオプションは、サーバーで変更ログ(またはレプリケーション)が以前に構成されていない場合のみ、指定する必要があります。デフォルト値は8989です。

enable

指定されたベースDNでデータをレプリケートするようにディレクトリ・サーバーの構成を更新します。指定したサーバーの1つがベースDNでデータをすでにレプリケートしている場合は、このサブコマンドを実行することによって全サーバーの構成が更新されます。したがって、レプリケーション・トポロジに追加されるサーバーごとに1回、このサブコマンドを実行するだけで十分です。サブオプションは次のとおりです:

--bindDN2 bindDN。レプリケートされるコンテンツのある第2のサーバーのバインドに使用するDN。バインドDNが指定されていない場合は、グローバル管理者がバインドに使用されます。

--bindPasswordFile1 filename。レプリケートされるコンテンツのある第1のサーバーへのバインドに使用されるパスワードが含まれているファイル。第1のサーバーに対してバインドDNが指定されていない場合は、グローバル管理者のパスワードがバインドに使用されます。

-D, --bindDN1 bindDN。レプリケートされるコンテンツのある第1のサーバーのバインドに使用するDN。バインドDNが指定されていない場合は、グローバル管理者がバインドに使用されます。

-F, --bindPasswordFile2 filename。レプリケートされるコンテンツのある第2のサーバーへのバインドに使用されるパスワードが含まれているファイル。第2のサーバーに対してバインドDNが指定されていない場合は、グローバル管理者のパスワードがバインドに使用されます。

-h, --host1 host。レプリケートされるコンテンツのある第1のサーバーのホスト名またはIPアドレス。

--noReplicationServer1。第1のサーバーで、レプリケーション・ポートまたは変更ログを構成しません。第1のサーバーにはレプリケートされたデータが含まれますが、レプリケートされたデータの変更をまとめた変更ログは含まれません。レプリケートされた各トポロジには、シングル・ポイント障害を回避するために、変更ログのあるサーバーが少なくとも2つ含まれている必要があります。

--noReplicationServer2。第2のサーバーで、レプリケーション・ポートまたは変更ログを構成しません。第2のサーバーにはレプリケートされたデータが含まれますが、レプリケートされたデータの変更をまとめた変更ログは含まれません。レプリケートされた各トポロジには、シングル・ポイント障害を回避するために、変更ログのあるサーバーが少なくとも2つ含まれている必要があります。

--noSchemaReplication。サーバー間でスキーマをレプリケートしません。スキーマ・レプリケーションはデフォルトで有効になっています。サーバー間でスキーマが同期化されないようにする場合は、このオプションを使用します。

--onlyReplicationServer1。第1のサーバーで、変更ログとレプリケーション・ポートのみを構成します。第1のサーバーにはレプリケートされたデータは含まれませんが、別のサーバー上でレプリケートされたデータの変更をまとめた変更ログは含まれます。

--onlyReplicationServer2。第2のサーバーで、変更ログとレプリケーション・ポートのみを構成します。第2のサーバーにはレプリケートされたデータは含まれませんが、別のサーバー上でレプリケートされたデータの変更をまとめた変更ログは含まれます。

-O, --host2 host。レプリケートされるコンテンツのある第2のサーバーのホスト名またはIPアドレス。

-p, --port1 port。レプリケートされるコンテンツのある第1のサーバーのディレクトリ・サーバー管理ポート番号。

--port2 port。レプリケートされるコンテンツのある第2のサーバーのディレクトリ・サーバー管理ポート番号。

-r, --replicationPort1 port。他のサーバーと通信するために、最初のディレクトリ・サーバーのレプリケーション・メカニズムにより使用されるポート。このオプションは、最初のディレクトリ・サーバーでレプリケーションが以前に構成されていない場合のみ指定します。

-R, --replicationPort2 port。他のサーバーと通信するために、2番目のディレクトリ・サーバーのレプリケーション・メカニズムにより使用されるポート。このオプションは、第2のサーバーでレプリケーションが以前に構成されていない場合のみ指定します。

-S, --skipPortCheck。指定されたレプリケーション・ポートが使用可能かどうかの判別チェックをスキップします。この引数が指定されない場合、サーバーは、ローカル・ホストを構成している場合のみポートが使用可能であると判断します。

--secureReplication1。第1のサーバーのレプリケーション・ポートを介した通信が暗号化されているかどうかを指定します。このオプションは、第1のサーバーでレプリケーションが初めて構成されるときのみ考慮されます。

--secureReplication2。第2のサーバーのレプリケーション・ポートを介した通信が暗号化されているかどうかを指定します。このオプションは、第2のサーバーでレプリケーションが初めて構成されるときのみ考慮されます。

--useSecondServerAsSchemaSource。第2のサーバーを使用して、第1のサーバーのスキーマを初期化します。このオプションと--noSchemaReplicationオプションがいずれも指定されていない場合は、第1のサーバーのスキーマを使用して第2のサーバーのスキーマが初期化されます。

initialize

宛先ディレクトリ・サーバー上の指定されたベースDNのデータのコンテンツを、ソース・サーバーのコンテンツで初期化します。この操作は、レプリケーションを有効にした後で必要になります。サブオプションは次のとおりです:

-h, --hostSource host。宛先サーバーの初期化に使用されるコンテンツのあるソース・サーバーのディレクトリ・サーバー・ホスト名またはIPアドレス。

-O, --hostDestination host。初期化されるコンテンツのある宛先サーバーのディレクトリ・サーバー・ホスト名またはIPアドレス。

-p, --portSource port。宛先サーバーの初期化に使用されるコンテンツのあるソース・サーバーのディレクトリ・サーバー管理ポート番号。

--portDestination port。初期化されるコンテンツのある宛先サーバーのディレクトリ・サーバー管理ポート番号。

initialize-all

トポロジ内のすべてのディレクトリ・サーバーで、指定されたベースDNのデータを指定されたサーバーのデータで初期化します。この操作は、レプリケーションを有効にしてレプリケーションが機能するようにした後で必要になります。または、トポロジ内の個々のサーバーでinitializeサブコマンドを使用することもできます。サブオプションは次のとおりです:

-h, --hostname host。ソース・サーバーのディレクトリ・サーバー・ホスト名またはIPアドレス。

-p, --port port。ソース・サーバーのディレクトリ・サーバー管理ポート番号。

post-external-initialization

import-ldifまたはバイナリ・コピーを使用してトポロジ全体が再初期化された後で、レプリケーションが機能できるようにします。import-ldifまたはバイナリ・コピーを使用してトポロジ内のすべてのディレクトリ・サーバーのコンテンツを初期化した後で、このサブコマンドをコールする必要があります。このサブコマンドを実行しない場合、初期化後にレプリケーションは機能しなくなります。サブオプションは次のとおりです:

-h, --hostname host。ディレクトリ・サーバーのホスト名またはIPアドレス。

-p, --port port。ディレクトリ・サーバーの管理ポート番号。

pre-external-initialization

import-ldifまたはバイナリ・コピーを使用して、初期化のためにレプリケーション・トポロジを準備します。import-ldifまたはバイナリ・コピーを使用してトポロジ内のすべてのディレクトリ・サーバーのコンテンツを初期化する前に、このサブコマンドをコールする必要があります。このサブコマンドを実行しない場合、初期化後にレプリケーションは機能しなくなります。このサブコマンドを実行した後で、トポロジ内のすべてのサーバーのコンテンツを初期化し、さらにサブコマンドpost-external-initializationを実行します。サブオプションは次のとおりです:

-h, --hostname host。ディレクトリ・サーバーのホスト名またはIPアドレス。

-l, --local-only。指定されたディレクトリ・サーバーのみのコンテンツを外部方法によって初期化する場合に、このオプションを使用します。

-p, --port port。ディレクトリ・サーバーの管理ポート番号。

purge-historical

ユーザー・エントリに保存されている履歴情報のパージ処理をレプリケーションによって起動します。この処理には少し時間がかかるため、この処理の最大継続時間を指定する必要があります。サブオプションは次のとおりです:

-h, --hostname host。ディレクトリ・サーバーのホスト名またはIPアドレス。

-p, --port port。ディレクトリ・サーバーの管理ポート番号。

--maximumDuration maximum duration。パージ処理が継続される必要のある最大継続時間を秒単位で指定します。デフォルト値は3600です。

-t, --start startTime。この処理がサーバー・タスクとしてスケジュールされている場合、UTC時間の場合はYYYYMMDDhhmmssZで、ローカル時間の場合はYYYYMMDDhhmmssで表記した処理の開始日時を指定します。タスクを即時実行するようにスケジュールするには、0を使用します。このオプションが指定された場合、操作は指定の時間に開始するようスケジュールされ、その直後にユーティリティが終了します。

--recurringTask schedulePattern。タスクは再帰的であり、crontab(5)互換の時間/日付パターンで表記される値引数に従ってスケジュールされることを示します。

--completionNotify emailAddress。タスク終了時に通知される受信者の電子メール・アドレスを示します。このオプションは、複数回指定できます。

--errorNotify emailAddress。このタスクの実行時にエラーが発生した場合に通知される受信者の電子メール・アドレスを示します。このオプションは、複数回指定できます。

--dependency taskID。このタスクが依存するタスクのIDを示します。依存タスクがすべて実行を完了するまで、タスクの実行は開始しません。

--failedDependencyAction action。依存タスクの1つが失敗した場合に行われる必要のあるアクションを示します。これには、次の値、PROCESS、CANCEL、またはDISABLEのいずれか1つが割り当てられている必要があります。デフォルト値はCANCELです。

set-trust

ディレクトリ・サーバーの信頼フラグを設定します。信頼できないディレクトリ・サーバーによって送信された変更は、トポロジのその他のサーバーにより破棄されます。信頼できるディレクトリ・サーバーのみが変更を送信して、他のディレクトリ・サーバーでその変更がリプレイされるようにすることができます。サブオプションは次のとおりです:

-h, --trustedHost host。変更を実行するディレクトリ・サーバーの完全修飾ホスト名またはIPアドレスを指定します。

-p, --trustedPort port。変更を実行するディレクトリ・サーバーの管理ポート番号を指定します。

-M, --modifiedHost host。信頼フラグが変更されるディレクトリ・サーバーの完全修飾ホスト名またはIPアドレスを指定します。

-c, --modifiedPort port。信頼フラグが変更されるディレクトリ・サーバーの管理ポート番号を指定します。

-t, --trustValue trusted|untrusted。変更されるディレクトリ・サーバーの信頼フラグの新しい値を指定します。値には、trustedまたはuntrustedを指定できます。デフォルト値はtrustedです。

status

登録情報に定義されたすべてのディレクトリ・サーバーの指定されたベースDNに対するレプリケーション構成をリストします。ベースDNが指定されない場合は、すべてのベースDNの情報が表示されます。サブオプションは次のとおりです:

-h, --hostname host。ディレクトリ・サーバーのホスト名またはIPアドレス。

-p, --port port。ディレクトリ・サーバーの管理ポート番号。

-s, --script-friendly。スクリプトにより解析可能なフォーマットでステータスを表示します。

statusサブコマンドは次の値を持ちます:

- 正常。レプリケーション・サーバーとの接続が正しいデータ・セットで確立されます。レプリケーションが機能しています。保証モードを使用している場合は、このディレクトリ・サーバーから承認シグナルが送信されます。

- 機能低下。レプリケーション・サーバーとの接続が正しいデータ・セットで確立されます。ディレクトリ・サーバーのリプレイの必要な多数の変更がレプリケーション・サーバー・キューに保留中であるため、レプリケーションは低下モードで動作しています。保証モードを使用している場合、このディレクトリ・サーバーからの承認シグナルは予想されません。

- 完全更新。レプリケーション・サーバーとの接続が確立され、ローカル・バックエンドを初期化するために、新しいデータ・セットがこの接続から受信されます(オンライン・インポート)。

- 不正データ・セット。レプリケーション・サーバーとの接続が、トポロジの他のディレクトリ・サーバーとは異なるデータ・セットで確立されます。レプリケーションは機能していません。トポロジの他のディレクトリ・サーバーを互換性のあるデータ・セットで初期化するか、このサーバーを他のサーバーと互換性のある別のデータ・セットで初期化する必要があります。

- 未接続。ディレクトリ・サーバーは、どのレプリケーション・サーバーとも接続されていません。

A.2.6.4 オプション

dsreplicationコマンドは、短いフォーム(例: -H)または同等の長いフォーム(例: --help)のいずれかでオプションを受け入れます。

-b, --baseDN baseDN

レプリケートまたは初期化するデータ、あるいはレプリケーションを無効にする必要のあるデータのベースDNを指定します。このオプションを複数回使用すると、複数のベースDNを指定できます。

A.2.6.5 構成オプション

--advanced

このコマンドをインタラクティブ・モードで実行しているときに、このオプションを使用して詳細設定にアクセスします。

A.2.6.6 LDAP接続オプション

-I, --adminUID adminUID

サーバーにバインドするためにグローバル管理者のユーザーIDを指定します。どのサーバーに対しても以前にグローバル管理者が定義されていない場合は、このオプションによって、指定されたデータを使用してグローバル管理者が作成されます。

-j, --adminPasswordFile bindPasswordFile

ディレクトリ・サーバーに対して認証を受ける際、指定したファイルでグローバル管理者パスワードを使用します。

-o, --saslOption name=value

指定されたオプションをSASL認証に使用します。

SASLは、プロキシ・サーバー・インスタンスに対してサポートされていません。

-X, --trustAll

SSLまたはStartTLSのネゴシエーション中にサーバーによって提示される可能性のある証明書をすべて信頼します。このオプションは便宜的に、かつテストの目的で使用できますが、セキュリティ上の理由から、トラスト・ストアを使用してクライアントがサーバーの証明書を受け入れるかどうかを判別する必要があります。

-P, --trustStorePath trustStorePath

指定されたパスにクライアント・トラスト・ストア証明書を使用します。このオプションは、--trustAllを使用している場合は必要ありません。ただし、本番環境で作業する場合はトラスト・ストアを使用する必要があります。

-U, --TrustStorePasswordFile path

クライアント・トラスト・ストアの証明書にアクセスするために、指定されたファイルでパスワードを使用します。このオプションは、--trustStorePathを使用していて、指定したトラスト・ストアがコンテンツへのアクセスにパスワードを必要とする場合のみ必須です(ほとんどのトラスト・ストアでは必要とされません)。

-K, --keyStorePath keyStorePath

指定されたパスにクライアント・キーストア証明書を使用します。

-u, --keyStorePasswordFile keyStorePasswordFile

クライアント・キーストアの証明書にアクセスするために、指定されたファイルでパスワードを使用します。このオプションは、--keyStorePathを使用する場合のみ必須です。

-N, --certNickname nickname

指定された証明書を認証に使用します。

--connectTimeout timeout

接続の確立に許容される最長時間(ミリ秒)を指定します。タイムアウトを指定しない場合は、0を使用します。デフォルト値は30000です。

A.2.6.7 コマンド入力/出力オプション

--commandFilePath path

このコマンドがインタラクティブ・モードで実行されているときに同等の非インタラクティブ・コマンドの書込み先となるファイルへのフルパスを指定します。

--displayCommand

コマンドがインタラクティブ・モードで実行されているときに、同等の非インタラクティブ・コマンドを標準出力に表示します。

-n, --no-prompt

非インタラクティブ・モードで実行します。コマンドのデータが見つからない場合、プロンプトが表示されず、コマンドは失敗します。

--noPropertiesFile

このコマンドでは、デフォルトのコマンドライン・オプションを取得するためにプロパティ・ファイルが使用されないことを示します。

--propertiesFilePath propertiesFilePath

デフォルトのコマンドライン・オプションが含まれているプロパティ・ファイルへのパスを指定します。

-Q, --quiet

最小モードで実行します。プロセス中に有意なエラーが発生しないかぎり、出力は生成されません。

A.2.6.8 一般オプション

-?, -H, --help

このコマンドに対するコマンドライン使用情報を表示し、サーバーの停止または再起動を試行しないで終了します。

-V, --version

サーバーのバージョン情報を表示して、このコマンドの実行を試みるかわりに終了します。

A.2.6.9 例

次の例では、2つのディレクトリ・サーバー、host1およびhost2がインストールされていることが前提となります。両方のサーバーがデフォルトの管理ポート(4444)を使用して構成されています。ベースDN dc=example,dc=comに、host1のデータが移入されます。ベースDNはhost2に存在していますが、空です。この例では、2つのサーバー間でレプリケーションを構成し、host2をデータで初期化しています。

注意:

dsreplicationの最も簡単な使用方法はインタラクティブ・モードで使用することです。その場合、すべての関連引数に関してプロンプトが表示されます。ただし、構成される引数を示すために、これらの例ではインタラクティブ・モードを使用していません。

例A-19 ディレクトリ・サーバー・レプリケーションの有効化

次のコマンドによって、host1およびhost2のベースDNdc=example,dc=comに対してレプリケーションが有効になります。このコマンドは非インタラクティブ・モードで実行し(-n)、すべてのサーバー証明書を受け入れる必要があることを指定します(-X)。

$ dsreplication enable \
--host1 host1 --port1 4444 --bindDN1 "cn=Directory Manager" \
--bindPasswordFile1 /tmp/pwd-file --replicationPort1 8989 \
--host2 host2 --port2 4444 --bindDN2 "cn=Directory Manager" \
--bindPasswordFile2 /tmp/pwd-file --replicationPort2 8989 \
--adminUID admin --adminPasswordFile /tmp/pwd-file --baseDN "dc=example,dc=com" -X -n

例A-20 ディレクトリ・サーバー・レプリケーションの初期化

あるレプリカを別のレプリカから初期化するには、initializeサブコマンドを使用します。次のコマンドによって、host2にあるベースDNdc=example,dc=comがhost1に含まれているデータで初期化されます。このコマンドは非インタラクティブ・モードで実行し(-n)、すべてのサーバー証明書を受け入れる必要があることを指定します(-X)。

$ dsreplication initialize --baseDN "dc=example,dc=com" \
--adminUID admin --adminPasswordFile /tmp/pwd-file \
--hostSource host1 --portSource 4444 \
--hostDestination host2 --portDestination 4444 -X -n

トポロジ全体を初期化するには、initialize-allサブコマンドを使用します。このサブコマンドはソース・ディレクトリ・サーバーの詳細をオプションとして取り、レプリケーションが有効になっているその他のすべてのレプリカを初期化します。

例A-21 ディレクトリ・サーバーのレプリケーション・ステータスの取得

次のコマンドにより、トポロジ内のディレクトリ・サーバーのレプリケーション・ステータスが取得されます。

$ dsreplication status --adminUID admin --adminPasswordFile /tmp/pwd-file -X --hostname host1 --port 4444

dc=example,dc=com - Replication Enabled
=======================================
Server     : Entries:M.C.[1]:A.O.M.C.[2]:Port[3]:Encryption[4]:Trust[5]:U.C.[6]:Status[7]:ChangeLog[8]:Group ID[9]:Connected to[10]
-----------:--------:-------:-----------:-------:-------------:--------:-------:---------:------------:-----------:-------------------------
host1:4444 : 200000 : 0     : N/A       : 1898  : Disabled    :Trusted : N/A   : Normal  : Enabled    : 1         :host1/203.0.113.24:1898
host2:5444 : 200000 : 0     : N/A       : 2898  : Disabled    :Trusted : N/A   : Normal  : Enabled    : 1         :host2/203.0.113.24:2898

[1] The number of changes that are still missing on this server (and that have been applied to at least one
other server).
[2] Age of oldest missing change: the age (in seconds) of the oldest change that has not yet arrived on this
server.
[3] The port used to communicate between the servers whose contents are being replicated.
[4] Whether the replication communication through the replication port is encrypted or not.
[5] Whether this directory server is trusted or not. Updates coming from an untrusted server are discarded and
not propagated.
[6] The number of untrusted changes. These are changes generated on this server while it is untrusted.
Those changes are not propagated to the rest of the topology but are effective on the untrusted server.
[7] The status of the replication domain on this directory server.
[8] Whether the external change log is enabled or not for the base DN on this server.
[9] The ID of the replication group to which the server belongs.
[10] The replication this server is connected to.

例A-22 ディレクトリ・サーバー・レプリケーションの無効化

次のコマンドによって、host2にあるベースDNdc=example,dc=comのレプリケーションが無効になります。あるディレクトリ・サーバーのレプリケーションを無効にすると、そのサーバーに対するすべての参照が、レプリケーション・トポロジにあるその他のディレクトリ・サーバーから削除されます。

$ dsreplication disable --baseDN "dc=example,dc=com" \
--hostname host2 --port 4444 --adminUID admin --adminPasswordFile /tmp/pwd-file \
-X -n
Establishing connections ..... Done.
Disabling replication on base DN cn=admin data of server host2:4444 ..... Done.
Disabling replication on base DN dc=example,dc=com of server host2:4444 ..... Done.
Disabling replication on base DN cn=schema of server host2:4444 ..... Done.
Removing references on base DN cn=admin data of server host1:4444 ..... Done.
Removing references on base DN dc=example,dc=com of server host1:4444 ..... Done.
Removing references on base DN cn=schema of server host1:4444 ..... Done.
Disabling replication port 8990 of server host2:4444 ..... Done.

例A-23 レプリケートされないサーバーでの外部変更ログの構成

次のコマンドによって、レプリケートされないサーバーで外部変更ログが有効になります。

$ dsreplication status -h localhost -p 4444 -D "cn=directory manager" --adminPasswordFile /tmp/pwd-file -X -n

dc=example,dc=com - Replication Disabled
========================================
Server         : Entries : ChangeLog [8]
---------------:---------:--------------
localhost:4444 : 0       : Disabled

dsreplication enable-changelog -h localhost -p 4444 -D "cn=directory manager" --adminPasswordFile /tmp/pwd-file -X -b dc=example,dc=com -n

Establishing connections ..... Done.
Enabling Changelog on base DN 'dc=example,dc=com' ...... Done.
Configuring Replication port on server localhost:4444 ..... Done.

dsreplication status -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -x -n

dc=example,dc=com - Replication Enabled
=======================================
Server     : Entries:M.C.[1]:A.O.M.C.[2]:Port[3]:Encryption[4]:Trust[5]:U.C.[6]:Status[7]:ChangeLog[8]:Group ID[9]:Connected to[10]
-----------:--------:-------:-----------:-------:-------------:--------:-------:---------:------------:----------:-------------------------
host1:4444 : 200000 : N/A   : N/A       : 1898  : Disabled    :Trusted : N/A   : Normal  : Enabled    : 1        : host1/203.0.113.24:1898

[1] The number of changes that are still missing on this server (and that have been applied to at least one
other server).
[2] Age of oldest missing change: the age (in seconds) of the oldest change that has not yet arrived on this
server.
[3] The port used to communicate between the servers whose contents are being replicated.
[4] Whether the replication communication through the replication port is encrypted or not.
[5] Whether this directory server is trusted or not. Updates coming from an untrusted server are discarded and
not propagated.
[6] The number of untrusted changes. These are changes generated on this server while it is untrusted.
Those changes are not propagated to the rest of the topology but are effective on the untrusted server.
[7] The status of the replication domain on this directory server.
[8] Whether the external change log is enabled or not for the base DN on this server.
[9] The ID of the replication group to which the server belongs.
[10] The replication this server is connected to.

A.2.6.10 終了コード

0

成功。

1

引数を初期化できません。

2

指定された引数が有効でないか、ユーザー・データのチェックでエラーが発生したため、引数を解析できません。

3

ユーザーがインタラクティブ・モードで操作を取り消しました。

4

引数が競合しています。

5

指定されたベースDNを使用してレプリケーションを有効にすることができません。

6

指定されたベースDNを使用してレプリケーションを無効にすることができません。

7

指定されたベースDNを使用してレプリカのコンテンツを初期化することができません。

8

指定された資格証明による接続でエラーが生じました。

9

レプリカの初期化に使用するドメインのレプリケーションIDが見つかりませんでした。

10

初期化開始の最大試行回数を超えています。システマティックな「ピアが見つからないエラー」が受信されました。

11

ベースDNでのレプリケーションの有効化でエラーが生じました。

12

ベースDNの初期化でエラーが生じました。

13

構成の読取り中にエラーが生じました。

14

ADSの更新中にエラーが生じました。

15

ADSの読取り中にエラーが生じました。

16

トポロジ・キャッシュの読取り中にエラーが生じました。

17

レプリケーション・サーバーの構成中にエラーが生じました。

18

サポートされていないADSシナリオです。

19

ベースDNでのレプリケーションの無効化でエラーが生じました。

20

ベースDNでのレプリケーション・ポート参照の削除中にエラーが生じました。

21

管理フレームワークの初期化でエラーが生じました。

22

トラスト・ストアのシード中にエラーが生じました。

23

事前外部初期化の起動中にエラーが生じました。

24

事後外部初期化の起動中にエラーが生じました。

25

レプリケーション・サーバーの無効化でエラーが生じました。

26

履歴のパージの実行中にエラーが生じました。

27

指定されたベースDNをパージできません。

28

履歴のパージの起動中にエラーが生じました。

29

履歴のローカル・パージでの構成クラスのロード中にエラーが生じました。

30

履歴のローカル・パージでのサーバーの起動中にエラーが生じました。

31

履歴のローカル・パージでタイムアウト・エラーが生じました。

32

履歴のローカル・パージ実行中の一般的なエラーです。

33

信頼できるホストがADSに見つかりませんでした。

34

変更されたホストがADSに見つかりませんでした。

35

このベースDNでは変更ログを有効にできません。

36

このベースDNでは変更ログを無効にできません。

37

変更ログの構成中にエラーが生じました。

38

指定されたホストが構成に見つかりませんでした。

A.2.6.11 プロパティ・ファイルの使用方法

ディレクトリ・サーバーでは、dsreplicationコマンドとともに使用されるデフォルトのオプション値を渡すプロパティ・ファイルの使用をサポートしています。プロパティ・ファイルは、様々な構成環境、特にスクリプト済アプリケーションまたは埋込みアプリケーションで作業する場合に便利です。詳細は、第A.1.2項「サーバー・コマンドによるプロパティ・ファイルの使用方法」を参照してください。

プロパティ・ファイルに保存可能なオプションは次のとおりです:

- adminUID

- baseDN

- certNickname

- keyStorePasswordFile

- keyStorePath

- saslOption
SASLは、プロキシ・サーバー・インスタンスに対してサポートされていません。

- trustAll

- trustStorePasswordFile

- trustStorePath

プロパティ・ファイルのエントリのフォーマットは、次のとおりです:

toolname.propertyname=propertyvalue

例:

dsreplication.baseDN=dc=example,dc=com

A.2.6.12 場所

- UNIXおよびLinux: INSTANCE_DIR/OUD/bin/dsreplication

- Windows: INSTANCE_DIR\OUD\bat\dsreplication.bat

A.2.6.13 関連コマンド

第A.2.4項「dsconfig」

A.2.7 gicadm

gicadmコマンドは、グローバル索引とグローバル索引カタログを管理します。

このコマンドはプロキシのみにサポートされます。

A.2.7.1 シノプシス

gicadm [subcommand] [options]

A.2.7.2 説明

gicadmコマンドにより、グローバル索引カタログの作成と削除、グローバル索引カタログ内でのグローバル索引の追加、変更、および削除と、グローバル索引カタログのレプリケーションの管理を実行できます。また、グローバル索引と分散との関連付けも実行できます。

gicadmコマンドは、管理コネクタを介してSSL上のサーバーにアクセスします。

A.2.7.3 オプション

gicadmコマンドは、次のオプションを受け入れます。

add-index

新しいグローバル索引をグローバル索引カタログに追加します。サブオプションは次のとおりです:

-c, --catalogName name。グローバル索引カタログの一意の識別子。これは必須の引数です。

--attributeName attribute-name。グローバル索引属性の識別子。この識別子はグローバル索引カタログのコンテキストにおいて一意である必要があり、グローバル索引の識別に使用されます。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。

associate

グローバル索引カタログを分散ワークフロー要素に関連付けます。サブオプションは次のとおりです:

-c, --catalogName name。グローバル索引カタログの一意の識別子。これは必須の引数です。

-d, --distributionWorkflowElement distribution-workflow-element。このグローバル索引カタログを使用する分散ワークフロー要素のオブジェクト名であり、グローバル索引カタログはこの関連付けを解除されます。

create-catalog

新しいグローバル索引カタログを作成します。サブオプションは次のとおりです:

-c, --catalogName name。グローバル索引カタログの一意の識別子。これは必須の引数です。

delete-catalog

グローバル索引カタログを削除します。サブオプションは次のとおりです:

-c, --catalogName name。グローバル索引カタログの一意の識別子。これは必須の引数です。

disable-replication

指定されたグローバル索引カタログに対して指定されたサーバーのレプリケーションを無効にし、そのサーバーに対するすべての参照を、レプリケーション・トポロジにあるその他のサーバーから削除します。サブオプションは次のとおりです:

-c, --catalogName name。グローバル索引カタログの一意の識別子。これは必須の引数です。

--adminUID adminUID。サーバーへのバインドに使用するグローバル管理者のユーザーID。enable-replicationサブコマンドについては、以前にグローバル管理者が定義されていない場合は、指定されたデータを使用してグローバル管理者が作成されます。

disassociate

グローバル索引カタログの分散ワークフロー要素への関連付けを解除します。サブオプションは次のとおりです:

-d, --distributionWorkflowElement distribution-workflow-element。このグローバル索引カタログを使用する分散ワークフロー要素のオブジェクト名であり、グローバル索引カタログはこの関連付けを解除されます。

enable-replication

グローバル索引カタログとそのグローバル索引がすべてレプリケートされるようにサーバー構成を更新します。指定したサーバーの1つが指定されたグローバル索引に対してグローバル索引カタログをすでにレプリケートしている場合は、このサブコマンドを実行することによってトポロジ内の全サーバーの構成が更新されます。したがって、レプリケーション・トポロジに追加されるサーバーごとに1回、このコマンドを実行するだけで十分です。サブオプションは次のとおりです:

-c, --catalogName name。グローバル索引カタログの一意の識別子。これは必須の引数です。

--adminUID adminUID。サーバーへのバインドに使用するグローバル管理者のユーザーID。enable-replicationサブコマンドについては、以前にグローバル管理者が定義されていない場合は、指定されたデータを使用してグローバル管理者が作成されます。

--adminPasswordFile bindPasswordFile。グローバル管理者のパスワードが含まれているファイル。

--localReplicationPort port。レプリケートされるコンテンツのある第1のサーバーのレプリケーション・ポート番号。

--localSecureReplication。第1のサーバーのレプリケーション・ポートを介した通信が暗号化されているかどうかを指定します。このオプションは、第1のサーバーでレプリケーションが初めて構成されるときのみ考慮されます。

--remoteAdminPort port。レプリケートされるコンテンツのある第2のサーバーのディレクトリ・サーバー管理ポート番号。

--remoteHost host。レプリケートされるコンテンツのある第2のサーバーの完全修飾ディレクトリ・サーバー・ホスト名またはIPアドレス。

--remoteBindDN bindDN。レプリケートされるコンテンツのある第2のサーバーのバインドに使用するDN。指定されていない場合は、グローバル管理者がバインドに使用されます。

--remoteBindPasswordFile bindPasswordFile。レプリケートされるコンテンツのある第2のサーバーへのバインドに使用されるパスワードが含まれているファイル。第2のサーバーに対してバインドDNが指定されていない場合は、グローバル管理者のパスワードがバインドに使用されます。

--remoteReplicationPort port。レプリケートされるコンテンツのある第2のサーバーのレプリケーション・ポート番号。

--remoteSecureReplication。第2のサーバーのレプリケーション・ポートを介した通信が暗号化されているかどうかを指定します。このオプションは、初回のみ考慮されます。

export

グローバル索引カタログをファイルにエクスポートします。サブオプションは次のとおりです:

-c, --catalogName name。グローバル索引カタログの一意の識別子。これは必須の引数です。

--exportDirectory directory。グローバル索引カタログのエクスポートに使用されるディレクトリへのパス。これは必須の引数です。

-a, --attributeName attribute-name。グローバル索引属性の名前。このオプションを複数回使用して、複数の索引付き属性を指定できます。このオプションが指定された場合、インポート・ソース内の一致しない索引付き属性はすべてスキップされます。

get-catalog-prop

グローバル索引カタログのプロパティを表示します。サブオプションは次のとおりです:

-c, --catalogName name。グローバル索引カタログの一意の識別子。これは必須の引数です。

--property property。表示されるプロパティの名前。

-E,--record。表示出力を1行ごとに1つのプロパティ値を表示するように変更します。

get-index-prop

索引のプロパティを表示します。サブオプションは次のとおりです:

-c, --catalogName name。グローバル索引カタログの一意の識別子。これは必須の引数です。

-a, --attributeName attribute-name。グローバル索引属性の識別子。この識別子はグローバル索引カタログのコンテキストにおいて一意である必要があり、グローバル索引の識別に使用されます。

--property property。表示されるプロパティの名前。有効なプロパティ名は、all、global-index-deleted-entry-retention-timeout、db-cleaner-min-utilization、db-log-file-max、db-checkpointer-bytes-interval、db-checkpointer-wakeup-interval, db-num-lock-tables, db-num-cleaner-threads, db-txn-no-sync、db-txn-write-no-sync、je-property、db-directory、db-directory-permissions、global-index-catalogs-shared-cache、およびglobal-index-attributeです。

import

ファイルのコンテンツを指定されたグローバル索引カタログにインポートします。サブオプションは次のとおりです:

-c, --catalogName name。グローバル索引カタログの一意の識別子。これは必須の引数です。

--importDirectory directory。グローバル索引カタログのインポートに使用されるファイルへのパス。これは必須の引数です。

--attributeName attribute-name。グローバル索引属性の識別子。この識別子はグローバル索引カタログのコンテキストにおいて一意である必要があり、グローバル索引の識別に使用されます。

--append。既存のグローバル索引を上書きするのではなく、それに追加します。

initialize-replication

グローバル索引カタログのレプリケーションを初期化します。レプリケートされたグローバル索引カタログ(レプリケーション・トポロジの一部)をすべて一度に初期化できます。または、指定されたグローバル索引カタログ(これもレプリケーション・トポロジの一部)からローカルのグローバル索引カタログが初期化されます。サブオプションは次のとおりです:

-c, --catalogName name。グローバル索引カタログの一意の識別子。これは必須の引数です。

--adminUID adminUID。サーバーへのバインドに使用するグローバル管理者のユーザーID。initialize-replicationサブコマンドについては、以前にグローバル管理者が定義されていない場合は、指定されたデータを使用してグローバル管理者が作成されます。

--fromServerPort port。宛先サーバーの初期化に使用されるコンテンツのあるソース・サーバーのディレクトリ・サーバー・ポート番号。

--fromServerHost host。宛先サーバーの初期化に使用されるコンテンツのあるソース・サーバーのディレクトリ・サーバー・ホスト名またはIPアドレス。

--all。指定されたサーバーのコンテンツによってレプリケートされるコンテンツのあるすべてのサーバー上で、グローバル索引属性のコンテンツを初期化します。

list-catalogs

定義済のグローバル索引カタログをリストします。サブオプションは次のとおりです:

--property property。表示されるプロパティの名前。有効なプロパティ名は、all、replication-server、server-id、window-size、heartbeat-interval、およびgroup-idです。

list-indexes

グローバル索引カタログで定義済のグローバル索引をリストします。サブオプションは次のとおりです:

-c, --catalogName name。グローバル索引カタログの一意の識別子。これは必須の引数です。

--property property。表示されるプロパティの名前。有効なプロパティ名は、all、global-index-deleted-entry-retention-timeout、db-cleaner-min-utilization、db-log-file-max、db-checkpointer-bytes-interval、db-checkpointer-wakeup-interval, db-num-lock-tables, db-num-cleaner-threads, db-txn-no-sync、db-txn-write-no-sync、je-property、db-directory、db-directory-permissions、global-index-catalogs-shared-cache、およびglobal-index-attributeです。

post-external-initialization

このサブコマンドは、このツールのimportサブコマンドを使用してレプリケートされたすべてのグローバル索引のコンテンツを初期化した後で、コールする必要があります。これは、有効なインスタンスとしてターゲットとなるインスタンスの生成IDを使用します。サブオプションは次のとおりです:

-c, --catalogName name。グローバル索引カタログの一意の識別子。これは必須の引数です。

-a, --attributeName attribute-name。グローバル索引属性の識別子。このオプションを複数回使用して、複数の索引付き属性を指定できます。このオプションが指定された場合、インポート・ソース内の一致しない索引付き属性はすべてスキップされます。

pre-external-initialization

このサブコマンドは、このツールのimportサブコマンドを使用してレプリケートされたすべてのサーバーのコンテンツを初期化する前にコールできます。レプリケーション・サーバーに保存されているレプリケーション変更ログを削除します。サブオプションは次のとおりです:

-c, --catalogName name。グローバル索引カタログの一意の識別子。これは必須の引数です。

-a, --attributeName attribute-name。グローバル索引属性の識別子。このオプションを複数回使用して、複数の索引付き属性を指定できます。このオプションが指定された場合、インポート・ソース内の一致しない索引付き属性はすべてスキップされます。

remove-index

グローバル索引をグローバル索引カタログから削除します。サブオプションは次のとおりです:

-c, --catalogName name。グローバル索引カタログの一意の識別子。これは必須の引数です。

--attributeName attribute-name。グローバル索引属性の識別子。この識別子はグローバル索引カタログのコンテキストにおいて一意である必要があり、グローバル索引の識別に使用されます。

set-catalog-prop

グローバル索引カタログのプロパティを変更します。サブオプションは次のとおりです:

-c, --catalogName name。グローバル索引カタログの一意の識別子。これは必須の引数です。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。有効なプロパティ名は、all、global-index-deleted-entry-retention-timeout、db-cleaner-min-utilization、db-log-file-max、db-checkpointer-bytes-interval、db-checkpointer-wakeup-interval, db-num-lock-tables, db-num-cleaner-threads, db-txn-no-sync、db-txn-write-no-sync、je-property、db-directory、db-directory-permissions、global-index-catalogs-shared-cache、およびglobal-index-attributeです。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。有効なプロパティ名は、all、global-index-deleted-entry-retention-timeout、db-cleaner-min-utilization、db-log-file-max、db-checkpointer-bytes-interval、db-checkpointer-wakeup-interval, db-num-lock-tables, db-num-cleaner-threads, db-txn-no-sync、db-txn-write-no-sync、je-property、db-directory、db-directory-permissions、global-index-catalogs-shared-cache、およびglobal-index-attributeです。

--add property:value。プロパティに単一値を追加します。ここで、propertyはプロパティの名前、valueは追加される単一の値です。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。有効なプロパティ名は、all、global-index-deleted-entry-retention-timeout、db-cleaner-min-utilization、db-log-file-max、db-checkpointer-bytes-interval、db-checkpointer-wakeup-interval, db-num-lock-tables, db-num-cleaner-threads, db-txn-no-sync、db-txn-write-no-sync、je-property、db-directory、db-directory-permissions、global-index-catalogs-shared-cache、およびglobal-index-attributeです。

set-index-prop

索引のプロパティを変更します。サブオプションは次のとおりです:

-c, --catalogName name。グローバル索引カタログの一意の識別子。これは必須の引数です。

--attributeName attribute-name。グローバル索引属性の識別子。この識別子はグローバル索引カタログのコンテキストにおいて一意である必要があり、グローバル索引の識別に使用されます。

--set property:value。プロパティに値を割り当てます。ここで、propertyはプロパティの名前、valueは割り当てられる単一の値です。同一のプロパティに複数の値を割り当てるには、そのプロパティを複数回指定します。有効なプロパティ名は、all、global-index-deleted-entry-retention-timeout、db-cleaner-min-utilization、db-log-file-max、db-checkpointer-bytes-interval、db-checkpointer-wakeup-interval, db-num-lock-tables, db-num-cleaner-threads, db-txn-no-sync、db-txn-write-no-sync、je-property、db-directory、db-directory-permissions、global-index-catalogs-shared-cache、およびglobal-index-attributeです。

--reset property。プロパティをデフォルト値にリセットします。ここで、propertyはリセットされるプロパティの名前です。有効なプロパティ名は、all、global-index-deleted-entry-retention-timeout、db-cleaner-min-utilization、db-log-file-max、db-checkpointer-bytes-interval、db-checkpointer-wakeup-interval, db-num-lock-tables, db-num-cleaner-threads, db-txn-no-sync、db-txn-write-no-sync、je-property、db-directory、db-directory-permissions、global-index-catalogs-shared-cache、およびglobal-index-attributeです。

--remove property:value。プロパティから単一値を削除します。ここで、propertyはプロパティの名前、valueは削除される単一の値です。有効なプロパティ名は、all、global-index-deleted-entry-retention-timeout、db-cleaner-min-utilization、db-log-file-max、db-checkpointer-bytes-interval、db-checkpointer-wakeup-interval, db-num-lock-tables, db-num-cleaner-threads, db-txn-no-sync、db-txn-write-no-sync、je-property、db-directory、db-directory-permissions、global-index-catalogs-shared-cache、およびglobal-index-attributeです。

status-replication

グローバル索引カタログの基本的なレプリケーション構成を含むリストを表示します。グローバル索引カタログが指定されない場合は、レプリケートされたすべてのグローバル索引カタログの情報が表示されます。サブオプションは次のとおりです:

-c, --catalogName name。グローバル索引カタログの一意の識別子。これは必須の引数です。

--adminUID adminUID。サーバーへのバインドに使用するグローバル管理者のユーザーID。status-replicationサブコマンドについては、以前にグローバル管理者が定義されていない場合は、指定されたデータを使用してグローバル管理者が作成されます。

-s, --scriptFriendly。スクリプト・フレンドリ・モードを使用します。

A.2.7.4 LDAP接続オプション

gicadmコマンドは、管理コネクタを介してSSL上のディレクトリ・サーバーに接続します(第14.3項「サーバーへの管理トラフィックの管理」で説明しています)。これらの接続オプションは、ディレクトリ・サーバーとの接続に使用します。

-h, --hostname host

ディレクトリ・サーバーのホスト名またはIPアドレス。

-D, --bindDN bindDN

サーバーへのバインドに使用するDN。

-j, --bindPasswordFile filename

バインド・パスワードが含まれているファイルへのフルパス。

-K, --keyStorePath path

指定されたパスにクライアント・キーストア証明書を使用します。

-N, --certNickname nickname

SSLクライアント認証に証明書を使用します。

-o, --saslOptionname=value

SASLバインド・オプション。

-p, --port port

ディレクトリ・サーバーの管理ポート番号。

-P, --trustStorePath path

指定されたパスにクライアント・トラスト・ストア証明書を使用します。このオプションは、--trustAllを使用している場合は必要ありません。ただし、本番環境で作業する場合はトラスト・ストアを使用する必要があります。

-u, --keyStorePasswordFile filename

クライアント・キーストアの証明書にアクセスするために、指定されたファイルでパスワードを使用します。このオプションは、--keyStorePathを使用する場合のみ必須です。

-U, --trustStorePasswordFile filename

クライアント・トラスト・ストアの証明書にアクセスするために、指定されたファイルでパスワードを使用します。このオプションは、--trustStorePathを使用していて、指定したトラスト・ストアがコンテンツへのアクセスにパスワードを必要とする場合のみ、必須です(ほとんどのトラスト・ストアでは必要とされません)。

-X, --trustAll

サーバーによって提示されるすべての証明書を信頼します。このオプションはテストの目的で使用できますが、セキュリティ上の理由から、トラスト・ストアを使用してクライアントがサーバーの証明書を受け入れるかどうかを判別する必要があります。

--connectTimeout timeout

接続の確立に許容される最大継続時間(ミリ秒)を指定します。タイムアウトを指定しない場合は、Oを使用します。デフォルト値は、 30000 ミリ秒です。

A.2.7.5 コマンド入力/出力オプション

--noPropertiesFile

このコマンドでは、デフォルトのコマンドライン・オプションを取得するためにプロパティ・ファイルが使用されないことを示します。

--propertiesFilePath propertiesFilePath

デフォルトのコマンドライン・オプションが含まれているプロパティ・ファイルへのパスを指定します。

-v, --verbose

標準出力に診断を表示する冗長モードで実行します。

A.2.7.6 一般オプション

-?, -H, --help

このコマンドに対するコマンドライン使用情報を表示し、ディレクトリ・サーバーの停止または再起動を試行しないで終了します。

-V, --version

ディレクトリ・サーバーのバージョン情報を表示します。

A.2.7.7 例

次の例は、gicadmコマンドの使用方法を示しています。

注意:

グローバル索引カタログの作成、グローバル索引の追加、グローバル索引カタログの分散への関連付けに関する次の例は、分散デプロイメントでグローバル索引カタログを使用するために必要な3つの手順です。

例A-24 グローバル・ヘルプ・サブコマンドとグローバル・オプションの表示

次のコマンドは、グローバル索引カタログの管理に使用可能なグローバル・ヘルプ・サブコマンドとグローバル・オプションを表示します:

$ gicadm --help

例A-25 個別サブコマンドのヘルプの表示

次のコマンドは、create-catalogサブコマンドのヘルプ情報を表示します:

$ gicadm create-catalog --help

例A-26 gicadmを使用したグローバル索引カタログの作成

このコマンドを実行する前に、分散を使用してプロキシをデプロイしておく必要があります。

$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j /path/pwd-file -X \
create-catalog --catalogName myCatalog

例A-27 gicadmを使用したグローバル索引カタログへのグローバル索引の追加

このコマンドを実行する前に、分散を使用してプロキシをデプロイしておく必要があります。さらに、このコマンドを実行する前に、グローバル索引カタログを作成しておく必要があります。

$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j /tmp-pwd-file -X \
add-index --catalogName myCatalog --attributeName telephoneNumber

例A-28 gicadmを使用したグローバル索引カタログの分散への関連付け

このコマンドを実行する前に、分散を使用してプロキシをデプロイしておく必要があります。さらに、このコマンドを実行する前に、グローバル索引カタログを作成しておく必要があります。

$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j /tmp-pwd-file -X \
associate --catalogName myCatalog --distributionWorkflowElement myDistributionName

A.2.7.8 終了コード

終了コード0は、操作が正常に終了したことを示します。ゼロ以外の終了コードは、処理中にエラーが発生したことを示します。

A.2.7.9 場所

- UNIXおよびLinux: INSTANCE_DIR/OUD/bin/gicadm

- Windows: INSTANCE_DIR\OUD\bat\gicadm.bat

A.2.7.10 関連コマンド

- dsconfig

- split-ldif

A.2.8 manage-tasks

manage-tasksコマンドは、ディレクトリ・サーバーでの実行がスケジュールされているタスクの管理と監視を行います。

このコマンドはプロキシに対してサポートされていません。

A.2.8.1 シノプシス

manage-tasks [options]

A.2.8.2 説明

manage-tasksコマンドを使用して、ディレクトリ・サーバーでの実行がスケジュールされているタスクを管理および監視できます。タスクを起動するときに適切なスケジュール情報を指定することにより、タスクがスケジュールされます(第14.4項「タスクとしてのコマンドの構成」を参照)。manage-tasksコマンドを使用して、現在スケジュールされているタスク、またはすでに実行されているタスクをリストすることができます。さらに、タスクのスケジュール済時間と実行時間、タスクのログ・メッセージ、およびオプションについて詳細情報を取得できます。

manage-tasksコマンドはオンライン・サーバー・インスタンスでのみ実行でき、管理コネクタを介してSSL上のサーバーにアクセスします(第14.3項「サーバーへの管理トラフィックの管理」で説明しています)。

A.2.8.3 オプション

manage-tasksコマンドは、短いフォーム(例: -c taskID)または同等の長いフォーム(例: --cancel taskID)のいずれかのオプションを受け入れます。

-c, --cancel taskID

取り消す特定のタスクを指定します。

-i, --info taskID

特定のタスクに関する情報を表示します。

-s, --summary

タスクのサマリーを印刷します。

A.2.8.4 LDAP接続オプション

-D, --bindDN bindDN

バインドDNを使用してディレクトリ・サーバーを認証します。このオプションは簡易認証の実行時に使用されます。SASL認証を使用する場合、このオプションは必要ありません。このオプションのデフォルト値はcn=Directory Managerです。

-h, --hostname hostname

指定されたホスト名またはIPアドレスのディレクトリ・サーバーに接続します。このオプションが指定されない場合は、localhostのデフォルトが使用されます。

-j, --bindPasswordFile filename

ディレクトリ・サーバーに対して認証を受ける際、指定したファイルにバインド・パスワードを使用します。

-K, --keyStorePath path

指定されたパスにクライアント・キーストア証明書を使用します。

-N, --certNickname nickname

指定された証明書をクライアント認証に使用します。

-o, --saslOption name=value

指定されたオプションをSASL認証に使用します。

-p, --port port

指定された管理ポートでディレクトリ・サーバーに接続します。このオプションが指定されない場合は、4444というデフォルトの管理ポートが使用されます。

-P, --trustStorePath path

指定されたパスにクライアント・トラスト・ストア証明書を使用します。このオプションは、--trustAllを使用している場合は必要ありません。ただし、本番環境で作業する場合はトラスト・ストアを使用する必要があります。

-u, --keyStorePasswordFile filename

クライアント・キーストアの証明書にアクセスするために、指定されたファイルでパスワードを使用します。このオプションは、--keyStorePathを使用する場合のみ必須です。

-U, --trustStorePasswordFile filename

クライアント・トラスト・ストアの証明書にアクセスするために、指定されたファイルでパスワードを使用します。このオプションは、--trustStorePathを使用していて、指定したトラスト・ストアがコンテンツへのアクセスにパスワードを必要とする場合のみ必須です(ほとんどのトラスト・ストアでは必要とされません)。

-X, --trustAll

ディレクトリ・サーバーによって提示されるすべてのサーバーSSL証明書を信頼します。このオプションは便宜的に、かつテストの目的で使用できますが、セキュリティ上の理由から、トラスト・ストアを使用してクライアントがサーバーの証明書を受け入れるかどうかを判別する必要があります。

A.2.8.5 コマンド入力/出力オプション

-n,--no-prompt

非インタラクティブ・モードを使用します。必須オプションの値が見つからない場合、プロンプトが表示されず、コマンドは失敗します。

--noPropertiesFile

デフォルトのコマンドライン・オプションの取得にプロパティ・ファイルが使用されていないことを示します。

--propertiesFilePath path

デフォルトのコマンドライン・オプションが含まれているプロパティ・ファイルへのパスを指定します。

A.2.8.6 一般オプション

-?, -H, --help

このコマンドに対するコマンドライン使用情報を表示し、タスクの管理を試行しないで終了します。

-V, --version

ディレクトリ・サーバーのバージョン情報を表示して、このコマンドの実行を試みるかわりに終了します。

A.2.8.7 例

次の例は、manage-tasksコマンドの使用方法を示しています。

例A-29 スケジュール済タスクのサマリーの表示

次のコマンドは、スケジュール済タスクのリストを表示します:

$ manage-tasks -h localhost -p 4444 -D "cn=directory manager" -j /path/pwd-file \
-X -s

ID                Type     Status
-------------------------------------------------
2008101610361710  Backup   Completed successfully
2008101610403710  Restore  Completed successfully
2008101610442610  Restore  Waiting on start time

例A-30 タスク情報の取得

次のコマンドは、特定のタスクに関する情報を返します:

$ manage-tasks -h localhost -p 4444 -D "cn=directory manager" -j /path/pwd-file \
-X -i 2008101610442610
Task Details
-------------------------------------------------------
ID                        2008101610442610
Type                      Restore
Status                    Waiting on start time
Scheduled Start Time      Jan 25, 2009 12:15:00 PM SAST
Actual Start Time
Completion Time
Dependencies              None
Failed Dependency Action  None
Email Upon Completion     admin@example.com
Email Upon Error          admin@example.com

Restore Options
----------------------------------
Backup Directory  /backup/userRoot

例A-31 スケジュール済タスクの取消し

次のコマンドは、スケジュール済タスクを取り消します。このコマンドは、--no-promptオプションを使用して非インタラクティブ・モードで実行します。

$ manage-tasks -h localhost -p 4444 -D "cn=directory manager" -j /path/pwd-file \
-X -c 2008101610442610
Task 2008101610442610 canceled

A.2.8.8 終了コード

終了コード0は、操作が正常に終了したことを示します。終了コード1は、処理中にエラーが発生したことを示します。

A.2.8.9 プロパティ・ファイルの使用方法

ディレクトリ・サーバーでは、manage-tasksコマンドとともに使用されるデフォルトのオプション値を渡すプロパティ・ファイルの使用をサポートしています。プロパティ・ファイルは、様々な構成環境、特にスクリプト済アプリケーションまたは埋込みアプリケーションで作業する場合に便利です。詳細は、第A.1.2項「サーバー・コマンドによるプロパティ・ファイルの使用方法」を参照してください。

A.2.8.10 場所

- UNIXおよびLinux: OUD_ORACLE_HOME/bin/manage-tasks

- Windows: OUD_ORACLE_HOME\bat\manage-tasks.bat

A.2.8.11 関連コマンド

- 第A.3.6項「import-ldif」

- 第A.3.5項「export-ldif」

- 第A.3.1項「backup」

- 第A.3.14項「restore」

- 第A.2.17項「stop-ds」

A.2.9 oudCopyConfig

oudCopyConfigコマンドは、既存の構成のコピーをソース環境から取得するために使用します。

テストから本番環境への移動の詳細は、第28章「テストから本番環境への移動」を参照してください。

A.2.9.1 シノプシス

oudCopyConfig [options]

A.2.9.2 説明

既存の構成のコピーを取得するには、ソース環境でoudCopyConfigコマンドを実行します。

oudCopyConfigコマンドは、次のアクションを実行します:

- テスト・インスタンス(instHomePath)の本番環境への移動に必要な構成データが含まれているアーカイブ(archivePath)を作成します。-archiveLocオプションは、アーカイブへのフルパスを指定します。

- アーカイブに移動計画を作成します。

- すべてのメッセージをlog_directory.に記録します。指定されない場合、記録されたメッセージのデフォルト場所はシステムの一時ディレクトリになります。

A.2.9.3 オプション

oudCopyConfigコマンドは、オプションを次のフォームで受け入れます。

-javaHome, javaHomePath

JDKの絶対パス。

-al, -archiveLoc archivePath

アーカイブの場所の絶対パス。これには、テスト・インスタンス(instHomePath)の本番環境への移動に必要な構成データが含まれています。

-sih, -sourceInstanceHomeLoc instHomePath

本番環境にコピーする既存のインスタンスの絶対パス。

-h, -help

このヘルプ・メッセージを表示して終了します。このパラメータはオプションです。

-ldl, -logDirLoc logPath

既存のログ・ディレクトリの場所。デフォルトの場所は、システムの一時的な場所です。このパラメータはオプションです。

A.2.9.4 例

次の例は、oudCopyConfigコマンドの使用方法を示しています。

例A-32 既存の構成のコピーの取得

次のコマンドは、既存の構成のコピーを取得します。

$ OUD_ORACLE_HOME/bin/oudCopyConfig -javaHome /usr/jdk \
-sourceInstanceHomeLoc /local/asinst_1 -archiveLoc /tmp/oud.jar \
-logDirLoc /tmp/logs

例A-33 ヘルプ・コマンド・オプションの実行

$ OUD_ORACLE_HOME/bin/oudCopyConfig -javaHome /usr/jdk -help

A.2.9.5 場所

- UNIXおよびLinux: OUD_ORACLE_HOME/bin/oudCopyConfig

- Windows: OUD_ORACLE_HOME\bat\oudCopyConfig.bat

A.2.9.6 関連コマンド

- 第A.2.10項「oudExtractMovePlan」

- 第A.2.11項「oudPasteConfig」

A.2.10 oudExtractMovePlan

oudExtractMovePlanコマンドは、-planDirLoc引数により指定された場所にあるmoveplan.xml,というファイル内の構成の編集可能バージョンを作成するために使用します。このディレクトリが存在していて、書込み可能である必要があります。

テストから本番環境への移動の詳細は、第28章「テストから本番環境への移動」を参照してください。

A.2.10.1 シノプシス

oudExtractMovePlan [options]

A.2.10.2 説明

移動計画を編集することによって、特定の構成パラメータを変更できます。移動計画とは、環境にまたがっての移動中にカスタマイズ可能なパラメータを公開するXMLファイルです。

移動計画は、oudCopyConfigコマンドを実行するときに生成され、構成を複製するためにoudPasteConfigコマンドによって使用されます。

A.2.10.3 オプション

oudExtractMovePlanコマンドは、オプションを次のフォームで受け入れます:

-javaHome, javaHomePath

JDKの絶対パス。

-al, -archiveLoc archivePath

アーカイブの場所の絶対パス。

-pdl, -planDirLoc planPath

移動計画を抽出するディレクトリへの絶対パス。移動計画ファイルの名前はmoveplan.xmlです。

-h, -help

このヘルプ・メッセージを表示して終了します。このパラメータはオプションです。

-ldl, -logDirLoc logPath

既存のログ・ディレクトリの場所。デフォルトの場所は、システムの一時的な場所です。このパラメータはオプションです。

A.2.10.4 例

次の例は、oudExtractMovePlanコマンドの使用方法を示しています。

例A-34 構成の編集

次のコマンドによって、構成を編集できます。

$ OUD_ORACLE_HOME/bin/oudExtractMovePlan -javaHome /usr/jdk \
-al /tmp/oud.jar -pdl /tmp -logDirLoc /tmp/logs

例A-35 ヘルプ・コマンド・オプションの実行

$ OUD_ORACLE_HOME/bin/oudExtractMovePlan -javaHome /usr/jdk -help

A.2.10.5 場所

- UNIXおよびLinux: OUD_ORACLE_HOME/bin/oudExtractMovePlan

- Windows: OUD_ORACLE_HOME\bat\oudExtractMovePlan.bat

A.2.10.6 関連コマンド

- 第A.2.9項「oudCopyConfig」

- 第A.2.11項「oudPasteConfig」

A.2.11 oudPasteConfig

oudPasteConfigコマンドは、構成をターゲット環境に貼り付けるために使用します。

テストから本番環境への移動の詳細は、第28章「テストから本番環境への移動」を参照してください。

A.2.11.1 シノプシス

oudPasteConfig [options]

A.2.11.2 説明

ターゲット環境で構成を取得するには、oudPasteConfigコマンドを実行します。

oudPasteConfigコマンドは、アーカイブと修正済の移動計画から取得した構成で新しいサーバー・インスタンスを作成します。

A.2.11.3 オプション

oudPasteConfigコマンドは、オプションを次のフォームで受け入れます:

-javaHome, javaHomePath

JDKの絶対パス。

-al, -archiveLoc archivePath

アーカイブの場所の絶対パス。

-mpl, -movePlanLoc planPath

計画抽出の操作中に抽出された移動計画への絶対パス。

-tih, -targetInstanceHomeLoc instHomePath

Oracle Unified Directoryの構成がリストアされるインスタンス・ホームの絶対パス。

-toh, -targetOracleHomeLoc oracleHomePath

インスタンス・ホームに関連付けられたOracleホームの絶対パス。

-tin, -targetInstanceName instanceName

ターゲット・インスタンス名。指定された場合は、ターゲット・インスタンス・パスとの整合性が必要になります。このパラメータはオプションです。

-h, -help

このヘルプ・メッセージを表示して終了します。このパラメータはオプションです。

-ldl, -logDirLoc logPath

既存のログ・ディレクトリの場所。デフォルトの場所は、システムの一時的な場所です。このパラメータはオプションです。

A.2.11.4 例

次の例は、oudPasteConfigコマンドの使用方法を示しています。

例A-36 構成の貼付け

次のコマンドによって、構成を貼り付けることができます。

$ OUD_ORACLE_HOME/bin/oudPasteConfig -javaHome /usr/jdk -al /tmp/oud.jar \
-tih /tmp/asinst_2 -toh /tmp/Oracle_OUD1 \
-mpl /tmp/moveplan.xml -tin asinst_2

例A-37 ヘルプ・コマンド・オプションの実行

$ OUD_ORACLE_HOME/bin/oudPasteConfig -javaHome /usr/jdk -help

A.2.11.5 場所

- UNIXおよびLinux: OUD_ORACLE_HOME/bin/oudPasteConfig

- Windows: OUD_ORACLE_HOME\bat\oudPasteConfig.bat

A.2.11.6 関連コマンド

- 第A.2.9項「oudCopyConfig」

- 第A.2.10項「oudExtractMovePlan」

A.2.12 oud-replication-gateway-setup

oud-replication-gateway-setupコマンドは、レプリケーション・ゲートウェイ・インスタンスの設定に使用します。

A.2.12.1 シノプシス

oud-replication-gateway-setup [options]

A.2.12.2 説明

oud-replication-gateway-setupコマンドは、レプリケーション・ゲートウェイ・インスタンスのインストールと構成を行います。その際、リスニングに使用するポート、初期ルート・ユーザーのDNとパスワード、およびレプリケーション・ゲートウェイ・データのベースDNも指定します。レプリケーション・ゲートウェイにより、一連のOracle Directory Server Enterprise EditionサーバーとOracle Unified Directoryサーバー間でレプリケーションが機能するようにできます。

このユーティリティは次のモードで実行できます:

- グラフィカル・ユーザー・インタフェース(GUI)モード。GUIモードはデフォルトであり、推奨のインストール・オプションです。oud-replication-gateway-setupのGUIは、レプリケートされたマルチ・ネットワーク環境でレプリケーション・サーバーをインストールおよび構成する際に簡単なインタフェースとして機能します。GUIモードでは、必要に応じてSSLまたはStartTLSを使用してサーバーを容易に設定することもできます。
このユーティリティはグラフィカル・インストーラを起動して、OUD_BASE_LOCATION/INSTANCE_DIRにOracle Unified Directoryインスタンスを作成します。デフォルトのインスタンス・ディレクトリ名はasinst_1であり、asinst_2、asinst_3などの名前を持つ同じサーバー上に後続のインスタンスが設定されます。

- コマンドライン・インタフェース(CLI)モード。コマンドライン・モードは、インタラクティブと非インタラクティブのどちらでも使用できます。インタラクティブCLIモードでは、構成を開始する前に必須情報を入力するようプロンプトが表示されます。GUIが使用できない場合は、--cliオプションを指定して使用します。
このユーティリティはコマンドライン・インストーラを起動して、OUD_BASE_LOCATION/INSTANCE_DIRにOracle Unified Directoryインスタンスを作成します。デフォルトのインスタンス・ディレクトリ名はasinst_1であり、asinst_2、asinst_3などの名前を持つ同じサーバー上に後続のインスタンスが設定されます。

非インタラクティブCLIモードでは、ユーザーが介入せずにサーバーを設定できます。--no-promptオプションと--quietオプションを使用すると、インタラクティブに抑止したり、情報を出力したりすることができます。

オプションを指定しないでoud-replication-gateway-setupコマンドを実行すると、このコマンドはGUIモードで開始しますが、GUIが使用できない場合はインタラクティブ・コマンドライン・モードにフォールバックします。インタラクティブ・コマンドライン・モードで設定を実行するには、--cliオプションを使用します。コマンドがGUIモードで実行している場合、オプションの使用は許可されません。

A.2.12.3 オプション

oud-replication-gateway-setupコマンドは、短いフォーム(例: -i)または同等の長いフォーム(例: --cli)のいずれかでオプションを受け入れます。

-i, --cli

コマンドライン・インストールを使用します。指定されていない場合は、グラフィカル・インタフェースが起動されます。その他のオプション(helpとversionを除く)は、このオプションが指定されている場合のみ考慮されます。

A.2.12.4 レプリケーション・ゲートウェイの構成オプション

-h, --hostname hostname

レプリケーション・ゲートウェイがインストールされるホストの完全修飾名。レプリケーション・トポロジ内のOracle Directory Server Enterprise EditionサーバーとOracle Unified Directoryサーバーは、このホスト名にアクセスできる必要があります。このオプションが指定されない場合は、localhostのデフォルトが使用されます。

--adminConnectorPort port

管理コネクタが管理トラフィックについてリスニングする必要のあるポートを指定します。管理コネクタの詳細は、第14.3項「サーバーへの管理トラフィックの管理」を参照してください。構成ツールと管理ツールはこのポートを使用してレプリケーション・ゲートウェイに接続します。デフォルト値は4444です。

--replicationPortForLegacy port

コンテンツをレプリケートするためにレプリケーション・ゲートウェイと通信するOracle Directory Server Enterprise Editionサーバーによって使用されるポートを指定します。

-S, --skipPortCheck

指定されたポートが使用可能かどうかの判別を試みません。通常、このオプションが指定されていない場合は、oud-replication-gateway-setupコマンドがポートが使用中であるかどうかを検証し、使用中でない場合、コマンドを実行しているユーザーはそのポートにバインドできます。--skipPortCheckオプションを指定した場合、oud-replication-gateway-setupコマンドはポートのチェックをスキップします。

-D, --rootUserDN rootUserDN

レプリケーション・ゲートウェイに対する初期ルート・ユーザーのDN。

-j, --rootUserPasswordFile rootUserPasswordFile

レプリケーション・ゲートウェイに対する初期ルート・ユーザーのパスワードが含まれているファイルへのパス。

-O, --doNotStart

構成が完了したときに、レプリケーション・ゲートウェイを起動しません。

-b, --baseDN baseDN

Oracle Unified DirectoryとOracle Directory Server Enterprise Editionサーバー間でレプリケートされるデータのベースDNを指定します。このオプションを複数回使用することによって、複数のベースDNを指定できます。

A.2.12.5 Oracle Directory Server Enterprise Editionサーバー・オプション

--hostNameLegacy hostname

レプリケートされるコンテンツのあるOracle Directory Server Enterprise Editionサーバーの完全修飾ホスト名またはIPアドレス。

--portLegacy port

レプリケートされるコンテンツのあるOracle Directory Server Enterprise Editionサーバーのポート番号を指定します。このポートは、コンテンツをレプリケートするレプリケーション・メカニズムにより使用されます。

--bindDNLegacy bindDN

レプリケートされるコンテンツのあるOracle Directory Server Enterprise Editionサーバーのバインドに使用するDNを指定します。

--bindPasswordFileLegacy bindPasswordFile

レプリケートされるコンテンツのあるOracle Directory Server Enterprise Editionサーバーのバインドに使用するパスワードが保存されているファイルを指定します。

--secureReplicationLegacy

Oracle Directory Server Enterprise Editionサーバーとレプリケーション・ゲートウェイ間のレプリケーションの更新が暗号化されて送信されたかどうかを指定します。このオプションを有効にした場合は、レプリケーション・ゲートウェイのセキュリティ・オプションにあるオプションを使用して、サーバーが使用する証明書を指定する必要があり、引数--portLegacyを使用して指定されたポートはLDAPポートである必要があります。

--clientAuthenticationToLegacy

クライアント認証を使用して、レプリケーション・ゲートウェイからOracle Directory Server Enterprise Editionサーバーにレプリケーションの更新を送信します。この引数は、属性--secureReplicationLegacyを使用している場合のみ使用できます。

--certFileForClientAuthenticationToLegacy certificateFile

レプリケーションの更新を送信するためにレプリケーション・ゲートウェイがOracle Directory Server Enterprise Editionサーバーに接続しているときにクライアント認証モードで使用される証明書が含まれているファイルを指定します。このファイルには、X.509形式の証明書が含まれている必要があります。

--doNotSendUpdatesToLegacyServer

Oracle Unified Directoryサーバーでの更新をOracle Directory Server Enterprise Editionサーバーに伝播しません。このオプションを使用する場合、Oracle Unified Directoryサーバーで直接加えられた変更はOracle Directory Server Enterprise Editionサーバーのレプリケーション・トポロジに伝播されません。

--doNotUpdateTrustStoreWithLegacyCertsArg

この引数が指定され、レプリケーション・ゲートウェイが暗号化された通信(--secureReplicationLegacy引数を使用して指定されたもの)を使用してレプリケーションの更新をOracle Directory Server Enterprise Editionサーバーに送信する場合は、レプリケーション・ゲートウェイによって使用されるトラスト・ストアをOracle Directory Server Enterprise Editionサーバーのサーバー証明書で更新して、レプリケーションが機能できるようにする必要があります。

--clientAuthenticationFromLegacy

クライアント認証を使用して、レプリケーションの更新をOracle Directory Server Enterprise Editionサーバーからレプリケーション・ゲートウェイに送信します。この引数は、属性--secureReplicationLegacyを使用している場合のみ使用できます。

A.2.12.6 レプリケーション・ゲートウェイのセキュリティ・オプション

--generateSelfSignedCertificate

Oracle Directory Server Enterprise Editionサーバーから暗号化された接続を受け入れるときにレプリケーション・ゲートウェイがサーバー証明書として使用する自己署名証明書を生成します。

--usePkcs11Keystore

Oracle Directory Server Enterprise Editionサーバーから暗号化された接続を受け入れるときにレプリケーション・ゲートウェイがサーバー証明書として使用するPKCS#11トークンの証明書を使用します。

--useJavaKeystore keyStorePath

Oracle Directory Server Enterprise Editionサーバーから暗号化された接続を受け入れるときにレプリケーション・ゲートウェイがサーバー証明書として使用する証明書が含まれているJavaキーストア(JKS)のパスを指定します。

--useJCEKS keyStorePath

Oracle Directory Server Enterprise Editionサーバーから暗号化された接続を受け入れるときにレプリケーション・ゲートウェイがサーバー証明書として使用する証明書が含まれているJCEKSのパスを指定します。

--usePkcs12keyStore keyStorePath

Oracle Directory Server Enterprise Editionサーバーから暗号化された接続を受け入れるときにレプリケーション・ゲートウェイがサーバー証明書として使用する証明書が含まれているPKCS#12キーストアのパス。

--gatewayKeyStorePasswordFile keyStorePasswordFile

証明書キーストアPINが含まれているファイルを指定します。レプリケーション・ゲートウェイがサーバー証明書として使用する証明書(JKS、JCEKS、PKCS#12、またはPKCS#11)が含まれているキーストアにアクセスする必要があります。これは、Oracle Directory Server Enterprise Editionサーバーとの暗号化されたレプリケーション通信に対応できるようにレプリケーション・ゲートウェイを構成する場合に必要です。

--gatewayCertNickname nickname

Oracle Directory Server Enterprise Editionサーバーから暗号化された接続を受け入れるときにレプリケーション・ゲートウェイが使用する証明書のニックネームを指定します。

A.2.12.7 Oracle Unified Directoryサーバー・オプション

--hostNameNg hostname

レプリケートされるコンテンツのあるOracle Unified Directoryサーバーの完全修飾ホスト名またはIPアドレス。

--portNg port

レプリケートされるコンテンツのあるOracle Unified Directoryサーバーのポート番号を指定します。

--bindDNNg bindDN

レプリケートされるコンテンツのあるOracle Unified Directoryサーバーのバインドに使用するDNを指定します。この属性が指定されていない場合は、グローバル管理者がバインドに使用されます。

--bindPasswordFileNg bindPasswordFile

レプリケートされるコンテンツのあるOracle Unified Directoryサーバーのバインドに使用するパスワードが保存されているファイルを指定します。このサーバーに対してバインドDNが指定されていない場合は、グローバル管理者のパスワードがバインドに使用されます。

--replicationPortNg port

他のOracle Unified Directoryサーバーと通信するために、Oracle Unified Directoryサーバーのレプリケーション・メカニズムにより使用されるポートを指定します。このオプションは、指定したOracle Unified Directoryサーバーにレプリケーションを構成していない場合のみ、指定する必要があります。

--secureReplicationNg

Oracle Unified Directoryサーバーのレプリケーション・ポートを介した通信が暗号化されているかどうかを指定します。このオプションは、Oracle Unified Directoryサーバーでレプリケーションが構成されていない場合のみ考慮されます。

-I, --adminUID adminUID

Oracle Unified Directoryサーバーへのバインドに使用するためにグローバル管理者のユーザーIDを指定します。Oracle Unified Directoryでグローバル管理者を定義していない場合は、指定したデータを使用してグローバル管理者が作成されます。デフォルト値はadminです。

--adminPasswordFile bindPasswordFile

グローバル管理者のパスワードが含まれているファイル。

A.2.12.8 セキュアな接続のオプション

-o, --saslOption name=value

これらはSASLバインド・オプションです。

SASLは、プロキシ・インスタンスに対してサポートされていません。

-X, --trustAll

サーバーによって提示されるすべてのサーバーSSL証明書を信頼します。このオプションは便宜的に、かつテストの目的で使用できますが、セキュリティ上の理由から、トラスト・ストアを使用してクライアントがサーバーの証明書を受け入れるかどうかを判別する必要があります。

-P, --trustStorePath path

指定されたパスにクライアント・トラスト・ストア証明書を使用します。このオプションは、--trustAllを使用している場合は必要ありません。ただし、本番環境で作業する場合はトラスト・ストアを使用する必要があります。

-U, --trustStorePasswordFile path

クライアント・トラスト・ストアの証明書にアクセスするために、指定されたファイルでパスワードを使用します。このオプションは、--trustStorePathを使用していて、指定したトラスト・ストアがコンテンツへのアクセスにパスワードを必要とする場合のみ必須です(ほとんどのトラスト・ストアでは必要とされません)。

-K, --keyStorePath path

指定されたパスにクライアント・キーストア証明書を使用します。

-u, --keyStorePasswordFile filename

クライアント・キーストアの証明書にアクセスするために、指定されたファイルでパスワードを使用します。このオプションは、--keyStorePathを使用する場合のみ必須です。

-N, --certNickname nickname

指定された証明書をSSLクライアント認証に使用します。

--connectTimeout timeout

接続の確立に許容される最長時間(ミリ秒)を指定します。タイムアウトを指定しない場合は、0を使用します。デフォルト値は30000です。

A.2.12.9 コマンド入力/出力オプション

-n, --no-prompt

setupを非インタラクティブ・モードで実行します。コマンドのデータが見つからない場合、プロンプトが表示されず、コマンドは失敗します。

-Q, --quiet

最小モードで実行します。プロセス中に有意なエラーが発生しないかぎり、出力は生成されません。

-v, --verbose

標準出力に診断を表示する冗長モードで実行します。

--noPropertiesFile

このコマンドでは、デフォルトのコマンドライン・オプションを取得するためにプロパティ・ファイルが使用されないことを示します。

--propertiesFilePath path

デフォルトのコマンドライン・オプションが含まれているプロパティ・ファイルへのパスを指定します。

A.2.12.10 一般オプション

-?, -H, --help

このコマンドに対するコマンドライン使用情報を表示し、サーバーの停止または再起動を試行しないで終了します。

--version

ディレクトリ・サーバーのバージョン情報を表示して、このコマンドの実行を試みるかわりに終了します。

A.2.12.11 例

次の例は、レプリケーション・サーバー・コマンドの使用方法を示しています。

例A-38 GUIモードでのoud-replication-gateway-setupの実行

次のコマンドは、GUIモードでインストールを実行します:

$ oud-replication-gateway-setup

このユーティリティはグラフィカル・インストーラを起動して、OUD_BASE_LOCATION/INSTANCE_DIRにOracle Unified Directoryインスタンスを作成します。デフォルトのインスタンス・ディレクトリ名はasinst_1であり、asinst_2、asinst_3などの名前を持つ同じサーバー上に後続のインスタンスが設定されます。別のインスタンス名を指定するには、設定を実行する前にINSTANCE_NAME環境変数を、たとえば次のように設定します:

$ export INSTANCE_NAME=my-oud-instance

GUIが起動して、いくつかの画面が表示されます。これらの画面では、スタンドアロン環境またはレプリケートされた環境でレプリケーション・サーバーを順次設定することができます。また、SSL証明書またはStartTLS証明書を設定するためのオプションもあります。

例A-39 コマンドラインからのインタラクティブ・モードでのoud-replication-gateway-setupの実行

oud-replication-gateway-setupコマンドはインタラクティブ・モードで実行できます。このモードでは、インストール・オプションに関してプロンプトが表示されます。oud-replication-gateway-setupをインタラクティブ・モードで実行するには、次のコマンドを入力します:

$ oud-replication-gateway-setup --cli

このコマンドでは、必須の設定値を入力するようプロンプトが表示されます。プロンプトに対して[Enter]キーまたは[Return]キーを押してデフォルト値を受け入れるか、値を入力します。

このユーティリティはコマンドライン・インストーラを起動して、OUD_BASE_LOCATION/INSTANCE_DIRにOracle Unified Directoryインスタンスを作成します。デフォルトのインスタンス・ディレクトリ名はasinst_1であり、asinst_2、asinst_3などの名前を持つ同じサーバー上に後続のインスタンスが設定されます。別のインスタンス名を指定するには、設定を実行する前にINSTANCE_NAME環境変数を、たとえば次のように設定します:

$ export INSTANCE_NAME=my-oud-instance

A.2.12.12 終了コード

0

正常終了または正常なno-opです。

1

予想外のエラーが生じました。バグの可能性があります。

2

ユーザー・データのエラーです。オプションを解析できないか、ユーザーにより指定されたデータが無効です。

4

サーバーの初期化でエラーが生じました。

A.2.12.13 プロパティ・ファイルの使用方法

ディレクトリ・サーバーでは、oud-replication-gateway-setupコマンドとともに使用されるデフォルトのオプション値を渡すプロパティ・ファイルの使用をサポートしています。プロパティ・ファイルは、様々な構成環境、特にスクリプト済アプリケーションまたは埋込みアプリケーションで作業する場合に便利です。詳細は、第A.1.2項「サーバー・コマンドによるプロパティ・ファイルの使用方法」を参照してください。

すべてのoud-replication-gateway-setupオプションは、プロパティ・ファイルに保存可能です。プロパティ・ファイルのエントリのフォーマットは、次のとおりです:

toolname.propertyname=propertyvalue

例:

oud-replication-gateway-setup.hostname=grevalon:1444

A.2.12.14 ログ・ファイル

oud-replication-gateway-setupコマンドは、oud-setup-IDnumberというログ・ファイルに書き込みます。この場合のIDnumberは10進数です。ログ・ファイルは次のパスに置かれています:

- UNIX (Solaris): /var/tmp/

- Linux: /tmp/

- Windows: %TEMP%
デフォルトでは、このフォルダはC:\Documents and Settings\User\Local Settings\Tempです。

A.2.12.15 場所

oud-replication-gateway-setupコマンドは、次のパスに置かれています:

- UNIXおよびLinux: OUD_BASE_LOCATION/OUD_ORACLE_HOME/oud-replication-gateway-setup

- Windows: OUD_BASE_LOCATION\OUD_ORACLE_HOME\oud-replication-gateway-setup.bat

A.2.12.16 関連コマンド

- 第A.2.13項「oud-setup」

- 第A.2.14項「oud-proxy-setup」

A.2.13 oud-setup

oud-setupコマンドは、ディレクトリ・サーバー・インスタンスのインストールと最小限の構成を行います。

このコマンドは、ディレクトリ・サーバー・インスタンスを設定します。プロキシ・サーバー・インスタンスの設定の詳細は、第A.2.14項「oud-proxy-setup」を参照してください。

A.2.13.1 シノプシス

oud-setup [options]

A.2.13.2 説明

oud-setupコマンドは、ディレクトリ・サーバー・インスタンスのインストールと構成を行います。その際、リスニングに使用するポート、初期ルート・ユーザーのDNとパスワード、ディレクトリ・データのベースDN、およびデータベースの移入方法も指定します。これは次のモードで実行できます:

- グラフィカル・ユーザー・インタフェース(GUI)モード。GUIモードはデフォルトであり、推奨のインストール・オプションです。oud-setupのGUIは、レプリケートされたマルチ・ネットワーク環境でスタンドアロンのディレクトリ・サーバーまたはレプリケーション・サーバーをインストールおよび構成する際に簡単なインタフェースとして機能します。GUIモードでは、必要に応じてSSLまたはStartTLSを使用してサーバーを容易に設定することもできます。
このユーティリティはグラフィカル・インストーラを起動して、OUD_BASE_LOCATION/INSTANCE_DIRにOracle Unified Directoryインスタンスを作成します。デフォルトのインスタンス・ディレクトリ名はasinst_1であり、asinst_2、asinst_3などの名前を持つ同じサーバー上に後続のインスタンスが設定されます。

- コマンドライン・インタフェース(CLI)モード。コマンドライン・モードは、インタラクティブと非インタラクティブのどちらでも使用できます。インタラクティブCLIモードでは、構成を開始する前に必須情報を入力するようプロンプトが表示されます。GUIが使用できない場合は、--cliオプションを指定して使用します。
このユーティリティはコマンドライン・インストーラを起動して、OUD_BASE_LOCATION/INSTANCE_DIRにOracle Unified Directoryインスタンスを作成します。デフォルトのインスタンス・ディレクトリ名はasinst_1であり、asinst_2、asinst_3などの名前を持つ同じサーバー上に後続のインスタンスが設定されます。

非インタラクティブCLIモードでは、ユーザーが介入せずにサーバーを設定できます。--no-promptオプションと--quietオプションを使用すると、インタラクティブに抑止したり、情報を出力したりすることができます。

オプションを指定しないでoud-setupコマンドを実行すると、このコマンドはGUIモードで開始しますが、GUIが使用できない場合はインタラクティブ・コマンドライン・モードにフォールバックします。コマンドライン・モードでoud-setupを実行するには、--cliオプションを使用します。指定可能なオプションを次に示します。コマンドがGUIモードで実行している場合、オプションの使用は許可されません。

A.2.13.3 オプション

oud-setupコマンドは、短いフォーム(例: -a)または同等の長いフォーム(例: --addBaseEntry)のいずれかでオプションを受け入れます。

-a, --addBaseEntry

ディレクトリ・サーバー・データベースにベース・エントリを作成するかどうかを示します。

-i, --cli

setupコマンドは、GUIモードではなく、コマンドラインのインタラクティブ・モードで実行します。--cliオプションを指定しないでsetupを実行すると、他のオプションを受け入ることはできません。

-b, --baseDN baseDN

ディレクトリ・サーバーにあるユーザー情報に対してベースDNを使用します。このオプションのデフォルト値はdc=example,dc=comです。このオプションを複数回指定することによって、複数のベースDNを指定できます。

-l, --ldifFile filename

指定されたLDIFファイルを使用して、データベースを移入します。このオプションを複数回指定することにより、複数のファイルからデータをインポートできます。この場合、ファイルはオプション・リストに記載される順序で処理されます。このオプションは、--addBaseEntryオプションまたは--sampleDataオプションのいずれかと同時に使用しないでください。このオプションが指定されない場合、データベースは空のままになります。

-R, --rejectFile filename

却下されたエントリを指定のファイルに書き込みます。-lオプションまたは--ldifFileオプションを使用するインポート中にエントリがデフォルトのスキーマに準拠しない場合、そのエントリは却下されます。

--skipFile filename

スキップされたエントリを指定のファイルに書き込みます。-lオプションまたは--ldifFileオプションを使用するインポート中に指定したベースDN下にエントリを配置できない場合、そのエントリはスキップされます。

-d, --sampleData number-of-entries

サンプルのユーザー・エントリの指定番号を使用してデータベースを移入します。エントリはimportコマンドのMakeLDIFファシリティを使用して生成されます。エントリはデフォルトのexample.templateテンプレートに基づいています。このオプションは、--addBaseEntryオプションまたは--ldifFileオプションのいずれかと同時に使用しないでください。このオプションが指定されない場合、データベースは空のままになります。

--eus

Oracleのエンタープライズ・ユーザー・セキュリティ(EUS)に対応できるようにサーバーを構成します。

-p,--ldapPort port

指定されたポートでディレクトリ・サーバーに接続します。これが指定されない場合は、デフォルト・ポート1389が非ルートとして、389がルートとして使用されます。

--adminConnectorPort port

管理コネクタが管理トラフィックについてリスニングする必要のあるポートを指定します。管理コネクタの詳細は、第14.3項「サーバーへの管理トラフィックの管理」を参照してください。デフォルト値は4444です。

-x, --jmxPort port

MX MBeansサーバー接続用のポートを指定します。このオプションのデフォルト値は1689です。

-S, --skipPortCheck

指定されたポートが使用可能かどうかの判別を試みません。通常、このオプションが指定されていない場合、oud-setupコマンドはポートが使用中でないこと、およびsetupコマンドを実行しているユーザーがそのポートにバインドできることを検証します。--skipPortCheckオプションを指定した場合、oud-setupコマンドはポートのチェックをスキップします。

-D, --rootUserDN rootUserDN

指定したルート・ユーザーDNを使用してディレクトリ・サーバーを認証します。このオプションは簡易認証の実行時に使用されます。SASL認証を使用する場合、このオプションは必要ありません。このオプションのデフォルト値はcn=Directory Managerです。

-j, --rootUserPasswordFile filename

ディレクトリ・サーバーの認証中に初期ルート・ユーザーのパスワードが含まれているファイルを指定します。

-O, --doNotStart

構成が完了したときに、ディレクトリ・サーバーを起動しません。

-q, --enableStartTLS

LDAPポートを使用することにより、StartTLSがディレクトリ・サーバーとセキュアな通信を実行できるようにします。

-Z, --ldapsPort port

LDAP SSL (LDAPS)通信を行うために指定されたポートでディレクトリ・サーバーに接続します。このオプションが明示的に指定されている場合のみ、LDAPSポートが構成され、SSLが有効になります。デフォルト値は1636です。

--generateSelfSignedCertificate

SSLベースの接続を受け入れたり、StartTLSネゴシエーションを実行するときにディレクトリ・サーバーが使用する必要のある自己署名証明書を生成します。

-h, --hostname host

自己署名証明書の生成に使用されるディレクトリ・サーバーのホスト名またはIPアドレス。この引数は、自己署名証明書の引数--generateSelfSignedCertificateが指定されている場合のみ考慮されます。

--usePkcs11Keystore

SSLベースの接続を受け入れたり、StartTLSネゴシエーションを実行するときにサーバーが使用する必要のあるPKCS#11形式の証明書を使用します。

--useJavaKeystore path

サーバー証明書が含まれているJavaキーストア(JKS)へのパスを指定します。

--useJCEKS path

サーバー証明書が含まれているJava Cryptography Extensionキーストア(JCEKS)へのパスを指定します。

--usePkcs12Keystore path

サーバー証明書が含まれているPKCS#12キーストアへのパスを指定します。

-u, --keyStorePasswordFile filename

証明書キーストアにアクセスするために、指定されたファイルでパスワードを使用します。既存の証明書(JKS、JCEKS、PKCS#11、またはPKCS#12)をサーバー証明書として指定する場合は、パスワードが必要です。

-N, --certNickname nickname

指定された証明書をSSLまたはStartTLSクライアント認証に使用します。

-e, --enableWindowsService

ディレクトリ・サーバーをWindowsサービスとして有効化します。Windowsプラットフォームの場合に限られます。

A.2.13.4 コマンド入力/出力オプション

-n, --no-prompt

setupを非インタラクティブ・モードで実行します。コマンドのデータが見つからない場合、プロンプトが表示されず、コマンドは失敗します。

--noPropertiesFile

このコマンドでは、デフォルトのコマンドライン・オプションを取得するためにプロパティ・ファイルが使用されないことを示します。

--propertiesFilePath path

デフォルトのコマンドライン・オプションが含まれているプロパティ・ファイルへのパスを指定します。

-Q, --quiet

最小モードで実行します。プロセス中に有意なエラーが発生しないかぎり、出力は生成されません。

-v, --verbose

標準出力に診断を表示する冗長モードで実行します。

A.2.13.5 一般オプション

-?, -H, --help

このコマンドに対するコマンドライン使用情報を表示し、サーバーの停止または再起動を試行しないで終了します。

-V, --version

ディレクトリ・サーバーのバージョン情報を表示して、このコマンドの実行を試みるかわりに終了します。

A.2.13.6 例

次の例は、ディレクトリ・サーバー・コマンドの使用方法を示しています。

例A-40 GUIモードでのoud-setupの実行

次のコマンドは、GUIモードでインストールを実行します:

$ oud-setup

GUIが起動して、いくつかの画面が表示されます。これらの画面では、スタンドアロン環境またはレプリケートされた環境でディレクトリ・サーバーを順次設定することができます。また、SSL証明書またはStartTLS証明書を設定するためのオプションもあります。

このユーティリティは、OUD_BASE_LOCATION/INSTANCE_DIRにOracle Unified Directoryインスタンスを作成します。デフォルトのインスタンス・ディレクトリ名はasinst_1であり、asinst_2、asinst_3などの名前を持つ同じサーバー上に後続のインスタンスが設定されます。別のインスタンス名を指定するには、設定を実行する前に、INSTANCE_NAME環境変数を、たとえば次のように設定します:

$ export INSTANCE_NAME=my-oud-instance

例A-41 コマンドラインからのインタラクティブ・モードでのoud-setupの実行

oud-setupコマンドはインタラクティブ・モードで実行できます。このモードでは、インストール・オプションに関してプロンプトが表示されます。oud-setupをインタラクティブ・モードで実行するには、次のコマンドを入力します:

$ oud-setup --cli

このコマンドでは、必須の設定値を入力するようプロンプトが表示されます。プロンプトに対して[Enter]キーまたは[Return]キーを押してデフォルト値を受け入れるか、値を入力します。

このユーティリティはコマンドライン・インストーラを起動して、OUD_BASE_LOCATION/INSTANCE_DIRにOracle Unified Directoryインスタンスを作成します。デフォルトのインスタンス・ディレクトリ名はasinst_1であり、asinst_2、asinst_3などの名前を持つ同じサーバー上に後続のインスタンスが設定されます。別のインスタンス名を指定するには、設定を実行する前にINSTANCE_NAME環境変数を、たとえば次のように設定します:

$ export INSTANCE_NAME=my-oud-instance

例A-42 非インタラクティブCLIモードでのoud-setupの実行

レプリケートされた大規模な環境に対して多数のディレクトリ・サーバー・インスタンスを構成する必要がある場合、非インタラクティブなCLIモードでは、oud-setupコマンドを使用してインストール・スクリプトを作成できます。このモードでは、--no-promptオプションと--quietオプションを指定する必要があります。オプションが指定されていない場合、oud-setupコマンドのデフォルトはインタラクティブ・モードになります。

次のコマンドは、非インタラクティブ(--no-prompt)モードと最小(-Q)モードでインストールを実行します。これはLDAPポート(-p)、管理コネクタ・ポート(--adminConnectorPort)、ルートDN (-D)、ルートDNパスワード(-j)が含まれているファイルを設定し、指定されたベースDN (-b)を使用してベース・エントリ(-a)を追加します。

$ oud-setup --cli --no-prompt -Q -p 1389 --adminConnectorPort 4444 \
-D "cn=Directory Manager" -j /path/pwd-file -a -b dc=example,dc=com

例A-43 LDIFインポートを指定した非インタラクティブCLIモードでのoud-setupの実行

次のコマンドは、非インタラクティブ(--no-prompt)モードと最小(-Q)モードでインストールを実行します。これはLDAPポート(-p)、管理コネクタ・ポート(--adminConnectorPort)、ルートDN (-D)、ルートDNパスワード(-j)が含まれているファイルを設定し、LDIFファイル(-l)からインポートしたデータを使用してベース・エントリ(-b)を追加します。

$ oud-setup --cli --no-prompt -Q -p 1389 --adminConnectorPort 4444 \
-D "cn=Directory Manager" -j /path/pwd-file -b dc=example,dc=com \
-l "/home/ldif/company.ldif"

例A-44 サンプル・エントリの生成を指定した非インタラクティブ・モードでのoud-setupの実行

次のコマンドは、非インタラクティブ(--no-prompt)モードと最小(-Q)モードでインストールを実行します。これはLDAPポート(-p)、管理コネクタ・ポート(--adminConnectorPort)、ルートDN (-D)、ルートDNパスワード(-j)が含まれているファイル、ベースDN(-b)を設定し、2000個のサンプル・エントリ(-d)を生成します。

$ oud-setup --cli --no-prompt -Q -p 1389 --adminConnectorPort 4444 \
-D "cn=Directory Manager" -j /path/pwd-file -b dc=example,dc=com -d 2000

例A-45 Windowsでのoud-setupの実行

次のコマンドは、ディレクトリ・サーバーがWindowsサービス(-e)として実行できるようにします。これはLDAPポート(-p)、管理コネクタ・ポート(--adminConnectorPort)、JMXポート(-x)、ルートDN(-D)、ルートDNパスワード(-j)が含まれているファイル、ベースDN(-b)を設定し、10000個のサンプル・エントリを生成します。

C:\> oud-setup.bat --cli -e -p 1389 --adminConnectorPort 4444 -x 1689 \
-D "cn=Directory Manager" -j /path/pwd-file -b dc=example,dc=com -d 10000

このユーティリティはグラフィカル・インストーラを起動して、OUD_BASE_LOCATION/INSTANCE_DIRにOracle Unified Directoryインスタンスを作成します。デフォルトのインスタンス・ディレクトリ名はasinst_1であり、asinst_2、asinst_3などの名前を持つ同じサーバー上に後続のインスタンスが設定されます。別のインスタンス名を指定するには、設定を実行する前にINSTANCE_NAME環境変数を、たとえば次のように設定します:

$ export INSTANCE_NAME=my-oud-instance

A.2.13.7 終了コード

0

正常終了または正常なno-opです。

1

予想外のエラーが生じました。バグの可能性があります。

2

ユーザー・データのエラーです。オプションを解析できないか、ユーザーにより指定されたデータが無効です。

4

サーバーの初期化でエラーが生じました。

A.2.13.8 プロパティ・ファイルの使用方法

ディレクトリ・サーバーでは、oud-setupコマンドとともに使用されるデフォルトのオプション値を渡すプロパティ・ファイルの使用をサポートしています。プロパティ・ファイルは、様々な構成環境、特にスクリプト済アプリケーションまたは埋込みアプリケーションで作業する場合に便利です。詳細は、第A.1.2項「サーバー・コマンドによるプロパティ・ファイルの使用方法」を参照してください。

プロパティ・ファイルに保存可能なオプションは次のとおりです:

- certNickname

- hostname

- keyStorePasswordFile

前のoud-setupオプションはすべて、プロパティ・ファイルに保存可能です。プロパティ・ファイルのエントリのフォーマットは、次のとおりです:

toolname.propertyname=propertyvalue

例:

oud-setup.hostname=grevalon:1444

A.2.13.9 ログ・ファイル

oud-setupコマンドは、oud-setup-IDnumberというログ・ファイルに書き込みます。この場合のIDnumberは10進数です。ログ・ファイルは次のパスに置かれています:

- UNIX (Solaris): /var/tmp/

- Linux: /tmp/

- Windows: %TEMP%
デフォルトでは、このフォルダはC:\Documents and Settings\User\Local Settings\Tempです。

A.2.13.10 場所

oud-setupコマンドは、次のパスに置かれています:

- UNIXおよびLinux: OUD_BASE_LOCATION/OUD_ORACLE_HOME/oud-setup

- Windows: OUD_BASE_LOCATION\OUD_ORACLE_HOME\oud-setup.bat

A.2.13.11 関連コマンド

- 第A.2.12項「oud-replication-gateway-setup」

- 第A.2.14項「oud-proxy-setup」

A.2.14 oud-proxy-setup

oud-proxy-setupコマンドは、プロキシ・サーバー・インスタンスの設定と構成を管理します。

A.2.14.1 シノプシス

oud-proxy-setup [options]

A.2.14.2 説明

oud-proxy-setupコマンドは、プロキシ・サーバー・インスタンスのインストールと構成を行います。その際、リスニングに使用するポート、初期ルート・ユーザーのDNとパスワード、ディレクトリ・データのベースDN、認証方法を指定し、選択したデプロイメントに応じてロード・バランシング、分散、およびグローバル索引カタログも指定します。

oud-proxy-setupは1回のみ起動できます。これは次のモードで実行できます:

- グラフィカル・ユーザー・インタフェース(GUI)モード。GUIモードはデフォルトであり、推奨のインストール・オプションです。設定のGUIは、プロキシ・インスタンスを定義およびデプロイする際に簡単なインタフェースとして機能します。
このユーティリティはグラフィカル・インストーラを起動して、OUD_BASE_LOCATION/INSTANCE_DIRにプロキシ・インスタンスを作成します。デフォルトのインスタンス・ディレクトリ名はasinst_1であり、asinst_2、asinst_3などの名前を持つ同じサーバー上に後続のインスタンスが設定されます。

- コマンドライン・インタフェース(CLI)モード。コマンドライン設定では、プロキシ・ポート、ホスト名、およびセキュリティ構成が定義されます。oud-proxy-setupとともに--cliオプションを指定する場合は、必須値をコマンドラインに指定する必要があります。指定しない場合は、デフォルト値が使用されます。デフォルト値が割り当てられていないパラメータに対して値が指定されないと、設定は失敗し、エラー・メッセージが表示されます。
このユーティリティはコマンドライン・インストーラを起動して、OUD_BASE_LOCATION/INSTANCE_DIRにプロキシ・インスタンスを作成します。デフォルトのインスタンス・ディレクトリ名はasinst_1であり、asinst_2、asinst_3などの名前を持つ同じサーバー上に後続のインスタンスが設定されます。

プロキシ設定CLIモードでは、ライセンスを受け入れるためのプロンプトが表示されます。--no-promptオプションを使用すると、ライセンスが自動的に受け入れられます。

A.2.14.3 オプション

oud-proxy-setupコマンドは、短いフォーム(例: -i)または同等の長いフォーム(例: --cli)のいずれかでオプションを受け入れます。

-i, --cli

コマンドライン・インストールを使用します。指定されていない場合は、グラフィカル・インタフェースが起動されます。その他のオプション(helpとversionを除く)は、このオプションが指定されている場合のみ考慮されます。

-p, --ldapPort port

ディレクトリ・サーバーがLDAP通信のリスニングに使用するポート。デフォルト値は389です。

--adminConnectorPort port

管理コネクタが通信のリスニングに使用するポート。デフォルト値は4444です。

-S, --skipPortCheck

指定されたポートが使用可能かどうかの判別チェックをスキップします。

-D, --rootUserDN rootUserDN

プロキシ・サーバーに対する初期ルート・ユーザーのDN。

-j, --rootUserPasswordFile rootUserPasswordFile

プロキシ・サーバーに対する初期ルート・ユーザーのパスワードが含まれているファイルへのパス。

-q, --enableStartTLS

LDAPポートを使用することにより、StartTLSがサーバーとセキュアな通信を実行できるようにします。

-Z, --ldapsPort port

ディレクトリ・サーバーがLDAP SSL (LDAPS)通信のリスニングに使用するポート。この引数が明示的に指定されている場合のみ、LDAPSポートが構成され、SSLが有効になります。デフォルト値は636です。

--generateSelfSignedCertificate

SSLベースの接続を受け入れたり、StartTLSネゴシエーションを実行するときにサーバーが使用する必要のある自己署名証明書を生成します。

--usePkcs11keyStore keyStorePath

SSLベースの接続を受け入れたり、StartTLSネゴシエーションを実行するときにサーバーが使用する必要のある証明書が含まれているPKCS#11キーストアのパス。

--useJavaKeystore keyStorePath

サーバー証明書として使用する証明書が含まれているJavaキーストア(JKS)のパス。

--useJCEKS keyStorePath

サーバー証明書として使用する証明書が含まれているJCEKSのパス。

--usePkcs12keyStore keyStorePath

SSLベースの接続を受け入れたり、StartTLSネゴシエーションを実行するときにサーバーが使用する必要のある証明書が含まれているPKCS#12キーストアのパス。

-u, --keyStorePasswordFile keyStorePasswordFile

証明書キーストアPINファイル。既存の証明書(JKS、JCEKS、PKCS#12、またはPKCS#11)をサーバー証明書として指定する場合は、PINが必要です。

-N, --certNickname nickname

SSLベースの接続を受け入れたり、StartTLSネゴシエーションを実行するときにサーバーが使用する必要のある証明書のニックネーム。

-O, --doNotStart

構成が完了したときに、サーバーを起動しません。

A.2.14.4 コマンド入力/出力オプション

-Q, --quiet

最小モードで実行します。プロセス中に有意なエラーが発生しないかぎり、出力は生成されません。

-v, --verbose

冗長モードを使用します。

--propertiesFilePath path

デフォルトのコマンドライン・オプションが含まれているプロパティ・ファイルへのパスを指定します。

--noPropertiesFile

デフォルトのコマンドライン・オプションの取得にプロパティ・ファイルが使用されないことを示します。

-n, --no-prompt

ライセンス受入れの場合のみ、インストールを非インタラクティブ・モードで実行します。コマンドのデータが見つからない場合、プロンプトが表示されず、コマンドは失敗します。

A.2.14.5 一般オプション

-?, -H, --help

このコマンドに対するコマンドライン使用情報を表示し、サーバーの停止または再起動を試行しないで終了します。

-V, --version

ディレクトリ・サーバーのバージョン情報を表示して、このコマンドの実行を試みるかわりに終了します。

A.2.14.6 例

次の例は、oud-proxy-setupコマンドの使用方法を示しています。

例A-46 GUIモードでのoud-proxy-setupの実行

次のコマンドは、GUIモードでインストールを実行します:

$ oud-proxy-setup

このユーティリティはグラフィカル・インストーラを起動して、OUD_BASE_LOCATION/INSTANCE_DIRにプロキシ・インスタンスを作成します。デフォルトのインスタンス・ディレクトリ名はasinst_1であり、asinst_2、asinst_3などの名前を持つ同じサーバー上に後続のインスタンスが設定されます。別のインスタンス名を指定するには、設定を実行する前にINSTANCE_NAME環境変数を、たとえば次のように設定します:

$ export INSTANCE_NAME=my-oud-proxy-instance

例A-47 非インタラクティブCLIモードでのoud-proxy-setupの実行

レプリケートされた大規模な環境に対して多数のプロキシ・サーバー・インスタンスを構成する必要がある場合、非インタラクティブなCLIモードでは、設定コマンドを使用してインストール・スクリプトを作成できます。このモードでは、--no-promptオプションと--quietオプションを指定する必要があります。オプションが指定されていない場合、設定コマンドのデフォルトはインタラクティブ・モードになります。

次のコマンドは、非インタラクティブ(--no-prompt)モードと最小(-Q)モードでインストールを実行します。これはLDAPポート(-p)、管理コネクタ・ポート(--adminConnectorPort)、ルートDN (-D)、およびルートDNパスワード(-j)が含まれているファイルを設定します。

$ oud-proxy-setup --cli --no-prompt -Q -p 1389 --adminConnectorPort 4444 \
-D "cn=Directory Manager" -j /path/pwd-file

このユーティリティはコマンドライン・インストーラを起動して、OUD_BASE_LOCATION/INSTANCE_DIRにプロキシ・インスタンスを作成します。デフォルトのインスタンス・ディレクトリ名はasinst_1であり、asinst_2、asinst_3などの名前を持つ同じサーバー上に後続のインスタンスが設定されます。別のインスタンス名を指定するには、設定を実行する前にINSTANCE_NAME環境変数を、たとえば次のように設定します:

$ export INSTANCE_NAME=my-oud-proxy-instance

A.2.14.7 終了コード

終了コード0は、操作が正常に終了したことを示します。ゼロ以外の終了コードは、処理中にエラーが発生したことを示します。

A.2.14.8 ログ・ファイル

設定が終了すると、oud-proxy-setupコマンドはoud-proxy-setup.logというログ・ファイルに書き込みます。このログ・ファイルは次のパスに置かれています:

- UNIX (Solaris):/var/tmp/

- Linux: /tmp/

- Windows: %TEMP%フォルダ。デフォルトでは、このフォルダはC:\Documents and Settings\user\Local Settings\Tempです。

A.2.14.9 場所

- UNIXおよびLinux: OUD_BASE_LOCATION/OUD_ORACLE_HOME/oud-proxy-setup

- Windows: OUD_BASE_LOCATION\OUD_ORACLE_HOME\oud-proxy-setup.bat

A.2.14.10 関連コマンド

第A.2.12項「oud-replication-gateway-setup」

第A.2.17項「stop-ds」

A.2.15 start-ds

start-dsコマンドは、インストールされたサーバー・インスタンスを開始します。

A.2.15.1 シノプシス

start-ds [options]

A.2.15.2 説明

start-dsコマンドは、サーバーの起動と一般的なサーバー情報の指定に使用します。

start-dsは、オプションを指定せずに実行できます。その場合、サーバーはバックグラウンド・プロセスとして起動します。この場合、サーバーが正常に起動するか、起動を妨げるエラーが発生するまで、スクリプトは終了しません。

UNIXシステムでは、INSTANCE_DIR/logs/server.pidでプロセスIDをログに記録できない場合、サーバーは起動しません。サーバーが使用するユーザー・アカウントによってファイルが書込み可能であることを確認します。

A.2.15.3 オプション

start-dsコマンドは、短いフォーム(例: -N)または同等の長いフォーム(例: --nodetach)のいずれかでオプションを受け入れます。

-L, --useLastKnownGoodConfig

現在アクティブな構成を使用するのではなく、最後に成功した起動時に指定されていた構成が使用可能な場合にこの構成を使用して起動を試行します。

-N, --nodetach

サーバーを、端末から連結解除されないフォアグラウンド・プロセスとして起動します。サーバーがこのモードで実行している場合は、別のウィンドウからstop-dsコマンドを使用して、またはサーバーが実行している端末ウィンドウで[Control]+[C]キーを押してサーバーを停止することができます。

-s, --systemInfo

サーバーがインストールされているシステムの一般情報を、インスタンスとインストール・パスも含めて表示し、その後で、サーバーの起動を試行しないで終了します。

-t, --timeout seconds

コマンドが戻るまで最大時間(単位: 秒)以上は待機しません。(サーバーは、それにかかわらず起動プロセスを続行します)。値0は無限タイムアウトを示し、サーバーの起動が完了したときのみコマンドが戻ることを意味します。デフォルト値は60秒です。このオプションは、-N、--nodetachオプションと同時に使用できません。

A.2.15.4 コマンド入力/出力オプション

-Q, --quiet

最小モードで実行します。プロセス中に有意なエラーが発生しないかぎり、出力は生成されません。

A.2.15.5 一般オプション

-?, -H, --help

このコマンドに対するコマンドライン使用情報を表示し、サーバーの停止または再起動を試行しないで終了します。

-V, --version

サーバーのバージョン情報を表示して、このコマンドの実行を試みるかわりに終了します。

A.2.15.6 例

次の例は、start—dsコマンドの使用方法を示しています。

例A-48 サーバーの起動

次のコマンドによって、サーバーが起動します:

$ start-ds

例A-49 フォアグラウンド・プロセスとしてのサーバーの起動

次のコマンドによって、サーバーがフォアグラウンド・プロセスとして起動します。別のウィンドウからstop-dsコマンドを使用して、またはサーバーが実行している端末ウィンドウで[Control]キーを押しながら[C]キーを押してサーバーを停止することができます。

$ start-ds -N

[25/Jul/2007:10:39:17 -0500] category=CORE severity=NOTICE msgID=458887
msg=The Directory Server has started successfully

A.2.15.7 終了コード

終了コード

説明

0

サーバーは正常に起動されました。

1

チェック・エラー。互換性のないオプションにより生成されました。

98

サーバーはすでに起動しています。

99

サーバーは連結解除されたプロセスとして起動する必要があります。

100

サーバーは連結解除されないプロセスとして起動する必要があります。

101

サーバーはWindowsサービスとして起動する必要があります。

102

サーバーは連結解除されたプロセスとして起動する必要があり、Windowsサービスからコールされています。

A.2.15.8 場所

- UNIXおよびLinux: INSTANCE_DIR/OUD/bin/start-ds

- Windows: INSTANCE_DIR\OUD\bat\start-ds.bat

A.2.15.9 関連コマンド

- 第A.2.17項「stop-ds」

A.2.16 status

statusコマンドは、基本的なサーバー・ステータス情報を表示します。

A.2.16.1 シノプシス

status [options]

A.2.16.2 説明

statusコマンドは、サーバーのステータス(起動済または停止)、構成された接続ハンドラ、または定義済バックエンドと接尾辞のリストといった基本的なサーバー・ステータス情報の表示に使用できます。

サーバーが起動している場合、statusコマンドは、管理コネクタを介してSSL上のサーバーに接続します。

詳細は、第14.3項「サーバーへの管理トラフィックの管理」を参照してください。

サーバーが停止している場合は、構成ファイル(特にconfig.ldifファイル)を読み取るファイルシステム・アクセス権を持つユーザーとしてこのコマンドを実行する必要があります。

注意:

サーバーが実行している場合は、特定の監視データのみ(たとえば、バックエンドにあるエントリ数)を表示できます。

A.2.16.3 LDAP接続オプション

statusコマンドは、管理コネクタを介してSSL上のサーバーに接続します(第14.3項「サーバーへの管理トラフィックの管理」で説明しています)。これらの接続オプションは、サーバーとの接続に使用します。

-D, --bindDN bindDN

バインドDNを使用してサーバーを認証します。このオプションは簡易認証の実行時に使用されます。SASL認証を使用する場合、このオプションは必要ありません。このオプションのデフォルト値はcn=Directory Managerです。

-j, --bindPasswordFile filename

サーバーに対して認証を受ける際、指定したファイルにバインド・パスワードを使用します。

-K, --keyStorePath path

指定されたパスにクライアント・キーストア証明書を使用します。

-N, --certNickname nickname

指定された証明書をクライアント認証に使用します。

-o, --saslOption name=value

指定されたオプションをSASL認証に使用します。

SASLは、プロキシ・サーバー・インスタンスに対してサポートされていません。

-P, --trustStorePath path

指定されたパスにクライアント・トラスト・ストア証明書を使用します。このオプションは、--trustAllを使用している場合は必要ありません。ただし、本番環境で作業する場合はトラスト・ストアを使用する必要があります。

-u, --keyStorePasswordFile filename

クライアント・キーストアの証明書にアクセスするために、指定されたファイルでパスワードを使用します。このオプションは、--keyStorePathを使用する場合のみ必須です。

-U, --trustStorePasswordFile filename

クライアント・トラスト・ストアの証明書にアクセスするために、指定されたファイルでパスワードを使用します。このオプションは、--trustStorePathを使用していて、指定したトラスト・ストアがコンテンツへのアクセスにパスワードを必要とする場合のみ必須です(ほとんどのトラスト・ストアでは必要とされません)。

-X, --trustAll

サーバーによって提示されるすべてのサーバーSSL証明書を信頼します。このオプションは便宜的に、かつテストの目的で使用できますが、セキュリティ上の理由から、トラスト・ストアを使用してクライアントがサーバーの証明書を受け入れるかどうかを判別する必要があります。

A.2.16.4 コマンド入力/出力オプション

-n, --no-prompt

非インタラクティブ・モードを使用します。コマンドのデータが見つからない場合、プロンプトが表示されず、コマンドは失敗します。

--noPropertiesFile

このコマンドでは、デフォルトのコマンドライン・オプションを取得するためにプロパティ・ファイルを使用する必要がないことを示します。

--propertiesFilePath path

デフォルトのコマンドライン・オプションが含まれているプロパティ・ファイルへのパスを指定します。

-r, --refresh period

この引数を指定した場合、statusコマンドはコンテンツを周期的に表示します。ステータスの2回の表示の間の期間(単位: 秒)を指定するために使用します。

-s, --script-friendly

スクリプト・フレンドリ・モードで実行します。スクリプトが解析しやすいフォーマットで出力を表示します。

A.2.16.5 一般オプション

-?, -H, --help

このコマンドに対するコマンドライン使用情報を表示し、サーバーの停止または再起動を試行しないで終了します。

-V, --version

サーバーのバージョン情報を表示して、このコマンドの実行を試みるかわりに終了します。

A.2.16.6 例

次の例は、statusコマンドの使用方法を示しています。

例A-50 サーバー・ステータスの表示

次の例では、現在オンラインになっているスタンドアロン・サーバーの現在のステータスが表示されます:

$ status -D "cn=directory manager" -j /path/pwd-file -X -n

--- Server Status ---
Server Run Status:        Started
Open Connections:         1

--- Server Details ---
Host Name:                hostname
Administrative Users:     cn=Directory Manager
Installation Path:        /path/OracleUnifiedDirectory
Instance Path:            /path/asinst_1/OUD
Version:                  Oracle Unified Directory 11.1.1.5.0
Java Version:             1.6.0_24
Administration Connector: Port 4444 (LDAPS)

--- Connection Handlers ---
Address:Port : Protocol    : State
-------------:-------------:---------
--           : LDIF        : Disabled
8989         : Replication : Enabled
0.0.0.0:161  : SNMP        : Disabled
0.0.0.0:636  : LDAPS       : Disabled
0.0.0.0:1389 : LDAP        : Enabled
0.0.0.0:1689 : JMX         : Disabled

--- Data Sources ---
Base DN:                      dc=example,dc=com
Backend ID:                   userRoot
Entries:                      7
Replication:                  Enabled
Missing Changes:              0
Age Of Oldest Missing Change: not available

A.2.16.7 終了コード

終了コード0は、操作が正常に終了したことを示します。ゼロ以外の終了コードは、処理中にエラーが発生したことを示します。

A.2.16.8 プロパティ・ファイルの使用方法

サーバーでは、statusコマンドとともに使用されるデフォルトのオプション値を渡すプロパティ・ファイルの使用をサポートしています。プロパティ・ファイルは、様々な構成環境、特にスクリプト済アプリケーションまたは埋込みアプリケーションで作業する場合に便利です。詳細は、第A.1.2項「サーバー・コマンドによるプロパティ・ファイルの使用方法」を参照してください。

プロパティ・ファイルに保存可能なオプションは次のとおりです:

- bindDN

- bindPasswordFile

- certNickname

- hostname

- keyStorePasswordFile

- keyStorePath

- port

- saslOption
SASLは、プロキシ・サーバー・インスタンスに対してサポートされていません。

- trustAll

- trustStorePasswordFile

- trustStorePath

プロパティ・ファイルのエントリのフォーマットは、次のとおりです:

toolname.propertyname=propertyvalue

例:

status.bindPasswordFile=/path/pwd-file

A.2.16.9 場所

- UNIXおよびLinux: INSTANCE_DIR/OUD/bin/status

- Windows: INSTANCE_DIR\OUD\bat\status.bat

A.2.17 stop-ds

stop-dsは、サービス・インスタンスを停止します。

A.2.17.1 シノプシス

stop-ds [options]

A.2.17.2 説明

stop-dsコマンドは、サーバーの停止または再起動に使用します。これはローカルまたはリモート・サーバー・インスタンスのいずれにおいても操作できます。

サーバーのローカル停止の実行機能は、現在はUNIXベースのシステムのみで使用できます。ローカルで実行している場合、stop-dsはサーバー・プロセスに中断シグナルを送信します。このサーバー停止方法は、stop-dsがオプションを指定せずに実行している場合、およびPIDファイル(INSTANCE_DIR/OUD/logs/server.pid)が存在している場合に使用します。

リモート停止メカニズムにより、サーバーにタスク・エントリを作成するためのLDAPリクエストが発行されます。このコマンドは、サーバー(ローカルまたはリモート)と通信できるすべてのシステムから実行できます。また、これはサーバーの再起動にも使用できます。この場合、サーバーは「インコア」再起動を実行します。つまり、JVMを停止することなくサーバー自身を再初期化します。

リモートで実行している場合、stop-dsコマンドは、管理コネクタを介してSSL上のサーバーと通信します。詳細は、第14.3項「サーバーへの管理トラフィックの管理」を参照してください。

A.2.17.3 オプション

stop-dsコマンドは、短いフォーム(例: -D bindDN)または同等の長いフォーム(例: --bindDN bindDN)のいずれかのオプションを受け入れます。

-r,--stopReason reason

判読可能な停止理由を指定します。理由が指定されている場合、これはサーバーのエラー・ログに表示され、プラグイン停止およびリスナー停止のために指定されます。

-R,--restart

サーバーを停止するかわりに、再起動します。--restartオプションが認証オプションとともに使用されている場合、サーバーはJVMを停止せずにサーバー自身を再初期化します。JVMは停止していないため、JVMの再起動を必要とする構成の変更は有効になりません。--restartオプションを認証なしで使用する場合、サーバーはまず停止し、その後で起動します。新しいプロセスによって元のサーバーが置換されます。

-t,--stopTime time

停止操作がサーバー・タスクとして開始される日付と時間をYYYYMMDDhhmmssのフォーマットで指定します。値0は、停止を即時実行するようにスケジュールします。このオプションを使用する場合、操作は指定の時間に開始するようスケジュールされ、その直後にこのコマンドが終了します。

-Y,--proxyAs authzID

停止リクエスト中に認可制御を使用します。このオプションに指定する値は認可IDである必要があります。認可IDには、dn:の後ろにユーザーDNが続くフォーム、またはu:の後ろにユーザー名が続くフォームが使用できます。クライアントはプロキシ認可v2制御を使用します。これについては、RFC 4370 (http://www.ietf.org/rfc/rfc4370.txt)に説明があります。

A.2.17.4 LDAP接続オプション

stop-dsコマンドは、管理コネクタを介してSSL上のサーバーに接続します(第14.3項「サーバーへの管理トラフィックの管理」で説明しています)。これらの接続オプションは、サーバーとの接続に使用します。

-D, --bindDN bindDN

バインドDNを使用してサーバーを認証します。このオプションは簡易認証の実行時に使用されます。SASL認証を使用する場合、このオプションは必要ありません。このオプションのデフォルト値はcn=Directory Managerです。

-h, --hostname hostname

指定されたホスト名またはIPアドレスのサーバーに接続します。このオプションが指定されない場合は、localhostのデフォルトが使用されます。

-j, --bindPasswordFile filename

サーバーに対して認証を受ける際、指定したファイルにバインド・パスワードを使用します。

-K, --keyStorePath path

指定されたパスにクライアント・キーストア証明書を使用します。

-N, --certNickname nickname

指定された証明書をクライアント認証に使用します。

-o, --saslOption name=value

指定されたオプションをSASL認証に使用します。

SASLは、プロキシ・サーバー・インスタンスに対してサポートされていません。

-p, --port port

指定された管理ポートでサーバーに接続します。このオプションが指定されない場合は、4444というデフォルトの管理ポートが使用されます。

-P, --trustStorePath path

指定されたパスにクライアント・トラスト・ストア証明書を使用します。このオプションは、--trustAllを使用している場合は必要ありません。ただし、本番環境で作業する場合はトラスト・ストアを使用する必要があります。

-u, --keyStorePasswordFile filename

クライアント・キーストアの証明書にアクセスするために、指定されたファイルでパスワードを使用します。このオプションは、--keyStorePathを使用する場合のみ必須です。

-U, --trustStorePasswordFile filename

クライアント・トラスト・ストアの証明書にアクセスするために、指定されたファイルでパスワードを使用します。このオプションは、--trustStorePathを使用していて、指定したトラスト・ストアがコンテンツへのアクセスにパスワードを必要とする場合のみ必須です(ほとんどのトラスト・ストアでは必要とされません)。

-X, --trustAll

サーバーによって提示されるすべてのサーバーSSL証明書を信頼します。このオプションは便宜的に、かつテストの目的で使用できますが、セキュリティ上の理由から、トラスト・ストアを使用してクライアントがサーバーの証明書を受け入れるかどうかを判別する必要があります。

A.2.17.5 コマンド入力/出力オプション

--noPropertiesFile

デフォルトのコマンドライン・オプションの取得にプロパティ・ファイルが使用されないことを示します。

--propertiesFilePath path

デフォルトのコマンドライン・オプションが含まれているプロパティ・ファイルへのパスを指定します。

-Q, --quiet

最小モードで実行します。プロセス中に有意なエラーが発生しないかぎり、出力は生成されません。

A.2.17.6 一般オプション

-?, -H, --help

このコマンドに対するコマンドライン使用情報を表示し、サーバーの停止または再起動を試行しないで終了します。

--version

サーバーのバージョン情報を表示して、このコマンドの実行を試みるかわりに終了します。

A.2.17.7 例

次の例は、stop-dsコマンドの使用方法を示しています。

例A-51 サーバーのローカルでの停止

次のコマンドによって、サーバーが停止します:

$ stop-ds

例A-52 サーバーのリモートでの停止

次のコマンドによって、リモート・サーバー・インスタンスが停止します。

$ stop-ds -h remotehost -p 4444 -D "cn=directory manager" -j /path/pwd-file -X

例A-53 サーバーのリモートでの再起動

次のコマンドによって、リモート・サーバー・インスタンスが再起動します。

$ stop-ds -R -h remotehost -p 4444 -D "cn=directory manager" -j /path/pwd-file -X

A.2.17.8 終了コード

終了コード

説明

0

サーバーは正常に停止しました。

98

サーバーはすでに停止しています。

99

サーバーを起動する必要があります。

100

システム・コールを使用してサーバーを停止する必要があります。

101

システム・コールを使用してサーバーを再起動する必要があります。

102

プロトコルを使用してサーバーを停止する必要があります。

103

サーバーはWindowsサービスとして停止する必要があります。

104

サーバーはWindowsサービスとして再起動する必要があります。

A.2.17.9 プロパティ・ファイルの使用方法

サーバーでは、stop-dsコマンドとともに使用されるデフォルトのオプション値を渡すプロパティ・ファイルの使用をサポートしています。プロパティ・ファイルは、様々な構成環境、特にスクリプト済アプリケーションまたは埋込みアプリケーションで作業する場合に便利です。

詳細は、第A.1.2項「サーバー・コマンドによるプロパティ・ファイルの使用方法」を参照してください。

プロパティ・ファイルに保存可能なオプションは次のとおりです:

- bindDN

- bindPasswordFile

- certNickname

- hostname

- keyStorePasswordFile

- keyStorePath

- saslOption
SASLは、プロキシ・サーバー・インスタンスに対してサポートされていません。

- trustAll

- trustStorePasswordFile

- trustStorePath

プロパティ・ファイルのエントリのフォーマットは、次のとおりです:

toolname.propertyname=propertyvalue

例:

stop-ds.trustAll=yes

A.2.17.10 場所

- UNIXおよびLinux: INSTANCE_DIR/OUD/bin/stop-ds

- Windows: INSTANCE_DIR\OUD\bat\stop-ds.bat

A.2.17.11 関連コマンド

第A.2.15項「start-ds」

A.2.18 uninstall

uninstallコマンドは、サーバー・インスタンスのアンインストールに使用します。これはディレクトリ・サーバー、プロキシ・サーバー、およびレプリケーション・ゲートウェイ・サーバーに適用できます。このコマンドは、ソフトウェアではなく、サーバー・インスタンスを削除します。

A.2.18.1 シノプシス

uninstall [options]

A.2.18.2 説明

uninstallコマンドは、サーバー・インスタンスのアンインストールに使用します。これは次のモードで実行できます:

- グラフィカル・ユーザー・インタフェース(GUI)モード。GUIモードはデフォルトであり、推奨のアンインストール・オプションです。uninstallのGUIは、インスタンス・ファイルを削除する際の簡単なインタフェースとして機能します。

- コマンドライン・インタフェース(CLI)モード。コマンドライン・モードは、インタラクティブと非インタラクティブのどちらでも使用できます。インタラクティブCLIモードでは、アンインストールを開始する前に必須情報を入力するようプロンプトが表示されます。GUIが使用できない場合は、--cliオプションを指定して使用します。
非インタラクティブCLIモードでは、ユーザーが介入せずにインスタンス・ファイルをアンインストールできます。--no-promptオプションと--quietオプションを使用すると、インタラクティブに抑止したり、情報を出力したりすることができます。

GUIモードまたはコマンドライン・モードのいずれで実行しているかに関係なく、削除可能なコンポーネントがリストされます。すべてのインスタンス・ファイルが削除できるとは限らない場合には、まだ存在しているディレクトリをすべてリストしたメッセージが表示されます。

インストールしたサーバーのタイプに応じて、異なるアンインストール・オプションが表示されます。これらのオプションは、次のように大別されます:

- 第A.2.18.3項「ディレクトリ・サーバーの削除」

- 第A.2.18.4項「プロキシ・サーバーの削除」

- 第A.2.18.5項「レプリケーション・ゲートウェイ・サーバーの削除」

注意:

削除すると決定したどのインスタンスのタイプ(ディレクトリ・サーバー、プロキシ、またはレプリケーション・ゲートウェイ)でも、アンインストール手順によってサーバーも停止します。また、レプリケーション・トポロジの一部であるサーバー・インスタンスの場合、そのトポロジから削除中であるサーバーもアンインストール手順によって削除されます。Windowsプラットフォームでは、インスタンスがWindowsサービスとしてインストールされた場合、そのWindowsサービスは登録解除されます。

A.2.18.3 ディレクトリ・サーバーの削除

この項では、ディレクトリ・サーバー・インスタンスを削除するオプションについて説明します。

A.2.18.3.1 オプション

uninstallコマンドは、短いフォーム(例: -i)または同等の長いフォーム(例: --cli)のいずれかでオプションを受け入れます。

-i, --cli

コマンドライン・インストールを使用します。指定されていない場合は、グラフィカル・インタフェースが起動されます。その他のオプション(helpとversionを除く)は、このオプションが指定されている場合のみ考慮されます。

-a, --remove-all

サーバーのすべてのコンポーネントを削除します(このオプションは、その他の削除オプションとの互換性はありません)。

-l, --server-libraries

サーバー・ライブラリと管理ツールを削除します。

-d, --databases

すべてのデータベース・コンテンツを削除します。

-L, --log-files

すべてのログ・ファイルを削除します。

-c, --configuration-files

構成ファイルを削除します。

-b, --backup-files

すべてのバックアップ・ファイルを削除します。

-e, --ldif-files

LDIFファイルを削除します。

-f, --forceOnError

リモート・サーバー・インスタンスでこのサーバーへの参照の更新中にエラーが発生した場合に、アンインストールを続行するかどうかを指定します。この引数は、--no-prompt引数とのみ同時に使用できます。

A.2.18.3.2 LDAP接続オプション

-I, --adminUID user-ID

サーバーにバインドするためにグローバル管理者のユーザーIDを指定します。

-j, --bindPasswordFile filename

ディレクトリ・サーバーに対して認証を受ける際、指定したファイルにバインド・パスワードを使用します。

-o, --saslOption name=value

指定されたオプションをSASL認証に使用します。

-X, --trustAll

サーバーによって提示されるすべての証明書を信頼します。このオプションはテストの目的で使用できますが、セキュリティ上の理由から、トラスト・ストアを使用してクライアントがサーバーの証明書を受け入れるかどうかを判別する必要があります。

-P, --trustStorePath path

指定されたパスにクライアント・トラスト・ストア証明書を使用します。このオプションは、--trustAllを使用している場合は必要ありません。ただし、本番環境で作業する場合はトラスト・ストアを使用する必要があります。

-U, --trustStorePasswordFile filename

クライアント・トラスト・ストアの証明書にアクセスするために、指定されたファイルでパスワードを使用します。このオプションは、--trustStorePathを使用していて、指定したトラスト・ストアがコンテンツへのアクセスにパスワードを必要とする場合のみ、必須です(ほとんどのトラスト・ストアでは必要とされません)。

-K, --keyStorePath path

指定されたパスにクライアント・キーストア証明書を使用します。

-u, --keyStorePasswordFile filename

クライアント・キーストアの証明書にアクセスするために、指定されたファイルでパスワードを使用します。このオプションは、--keyStorePathを使用する場合のみ必須です。

-N, --certNickname nickname

SSLクライアント認証に証明書を使用します。

--connectTimeout timeout

接続の確立に許容される最長時間(ミリ秒)。タイムアウトを指定しない場合は、0を使用します。デフォルト値は30000です。

-h, --referencedHostName host

レプリケーションのためにリモート・サーバーで参照されるこのホストの名前(またはIPアドレス)を指定します。

A.2.18.4 プロキシ・サーバーの削除

この項では、プロキシ・サーバー・インスタンスを削除するオプションについて説明します。

A.2.18.4.1 オプション

uninstallコマンドは、短いフォーム(例: -i)または同等の長いフォーム(例: --cli)のいずれかでオプションを受け入れます。

-i, --cli

コマンドライン・インストールを使用します。指定されていない場合は、グラフィカル・インタフェースが起動されます。その他のオプション(helpとversionを除く)は、このオプションが指定されている場合のみ考慮されます。

-a, --remove-all

サーバーのすべてのコンポーネントを削除します(このオプションは、その他の削除オプションとの互換性はありません)。

-l, --server-libraries

サーバー・ライブラリと管理ツールを削除します。

-L, --log-files

すべてのログ・ファイルを削除します。

-c, --configuration-files

構成ファイルを削除します。

-b, --backup-files

すべてのバックアップ・ファイルを削除します。

-e, --ldif-files

LDIFファイルを削除します。

-f, --forceOnError

リモート・サーバー・インスタンスでこのサーバーへの参照の更新中にエラーが発生した場合に、アンインストールを続行するかどうかを指定します。この引数は、--no-prompt引数とのみ同時に使用できます。

A.2.18.4.2 LDAP接続オプション

-I, --adminUID user-ID

サーバーにバインドするためにグローバル管理者のユーザーIDを指定します。

-j, --bindPasswordFile filename

ディレクトリ・サーバーに対して認証を受ける際、指定したファイルにバインド・パスワードを使用します。

-o, --saslOption name=value

指定されたオプションをSASL認証に使用します。

-X, --trustAll

サーバーによって提示されるすべての証明書を信頼します。このオプションはテストの目的で使用できますが、セキュリティ上の理由から、トラスト・ストアを使用してクライアントがサーバーの証明書を受け入れるかどうかを判別する必要があります。

-P, --trustStorePath path

指定されたパスにクライアント・トラスト・ストア証明書を使用します。このオプションは、--trustAllを使用している場合は必要ありません。ただし、本番環境で作業する場合はトラスト・ストアを使用する必要があります。

-U, --trustStorePasswordFile filename

クライアント・トラスト・ストアの証明書にアクセスするために、指定されたファイルでパスワードを使用します。このオプションは、--trustStorePathを使用していて、指定したトラスト・ストアがコンテンツへのアクセスにパスワードを必要とする場合のみ、必須です(ほとんどのトラスト・ストアでは必要とされません)。

-K, --keyStorePath path

指定されたパスにクライアント・キーストア証明書を使用します。

-u, --keyStorePasswordFile filename

クライアント・キーストアの証明書にアクセスするために、指定されたファイルでパスワードを使用します。このオプションは、--keyStorePathを使用する場合のみ必須です。

-N, --certNickname nickname

SSLクライアント認証に証明書を使用します。

--connectTimeout timeout

接続の確立に許容される最長時間(ミリ秒)。タイムアウトを指定しない場合は、0を使用します。デフォルト値は30000です。

-h, --referencedHostName host

レプリケーションのためにリモート・サーバーで参照されるこのホストの名前(またはIPアドレス)を指定します。

A.2.18.5 レプリケーション・ゲートウェイ・サーバーの削除

この項では、レプリケーション・ゲートウェイ・サーバーのインスタンスを削除するオプションについて説明します。

A.2.18.5.1 オプション

uninstallコマンドは、短いフォーム(例: -i)または同等の長いフォーム(例: --cli)のいずれかでオプションを受け入れます。

-i, --cli

コマンドライン・インストールを使用します。指定されていない場合は、グラフィカル・インタフェースが起動されます。その他のオプション(helpとversionを除く)は、このオプションが指定されている場合のみ考慮されます。

-f, --forceOnError

リモート・サーバー・インスタンスでこのサーバーへの参照の更新中にエラーが発生した場合に、アンインストールを続行するかどうかを指定します。この引数は、--no-prompt引数とのみ同時に使用できます。

A.2.18.5.2 ゲートウェイ接続オプション

-h, --hostname hostname

レプリケーション・ゲートウェイがインストールされているホストの完全修飾名。この名前は、レプリケーション・ゲートウェイの設定時に指定されたものである必要があります。

A.2.18.5.3 Oracle Unified Directoryサーバー接続オプション

-I, --adminUID adminUID

Oracle Unified Directoryサーバーへのバインドに使用するグローバル管理者のユーザーID。以前に新しい生成サーバーでグローバル管理者を定義しなかった場合は、バインドDNを指定します。デフォルト値はadminです。

--adminPasswordFile bindPasswordFile

Oracle Unified Directoryサーバーへのバインドに使用するグローバル管理者(またはバインドDN)のパスワードが含まれているファイル。

A.2.18.5.4 Oracle Directory Server Enterprise Editionサーバー接続オプション

--bindDNLegacy bindDN

レプリケーション・ゲートウェイを介してレプリケートされているコンテンツのあるOracle Directory Server Enterprise Editionサーバーのバインドに使用するDNを指定します。デフォルト値はcn=Directory Managerです。

--bindPasswordFileLegacy bindPasswordFile

レプリケーション・ゲートウェイを介してレプリケートされているコンテンツのあるOracle Directory Server Enterprise Editionサーバーのバインドに使用するパスワードが保存されているファイルを指定します。

A.2.18.5.5 セキュアな接続のオプション

-o, --saslOption name=value

これらはSASLバインド・オプションです。

SASLは、プロキシ・サーバー・インスタンスに対してサポートされていません。

-X, --trustAll

サーバーによって提示されるすべてのサーバーSSL証明書を信頼します。このオプションは便宜的に、かつテストの目的で使用できますが、セキュリティ上の理由から、トラスト・ストアを使用してクライアントがサーバーの証明書を受け入れるかどうかを判別する必要があります。

-P, --trustStorePath path

指定されたパスにトラスト・ストア証明書を使用します。このオプションは、--trustAllを使用している場合は必要ありません。ただし、本番環境で作業する場合はトラスト・ストアを使用する必要があります。

-U, --trustStorePasswordFile path

トラスト・ストアの証明書にアクセスするために、指定されたファイルでパスワードを使用します。このオプションは、--trustStorePathを使用していて、指定したトラスト・ストアがコンテンツへのアクセスにパスワードを必要とする場合のみ必須です(ほとんどのトラスト・ストアでは必要とされません)。

-K, --keyStorePath path

指定されたパスにキーストア証明書を使用します。

-u, --keyStorePasswordFile filename

キーストアの証明書にアクセスするために、指定されたファイルでパスワードを使用します。このオプションは、--keyStorePathを使用する場合のみ必須です。

-N, --certNickname nickname

指定された証明書をSSLクライアント認証に使用します。

--connectTimeout timeout

接続の確立に許容される最長時間(ミリ秒)を指定します。タイムアウトを指定しない場合は、0を使用します。デフォルト値は30000です。

A.2.18.6 コマンド入力/出力オプション

-n, --no-prompt

setupを非インタラクティブ・モードで実行します。コマンドのデータが見つからない場合、プロンプトが表示されず、コマンドは失敗します。

-Q, --quiet

最小モードで実行します。プロセス中に有意なエラーが発生しないかぎり、出力は生成されません。

-v, --verbose

標準出力に診断を表示する冗長モードで実行します。

--noPropertiesFile

このコマンドでは、デフォルトのコマンドライン・オプションを取得するためにプロパティ・ファイルが使用されないことを示します。

--propertiesFilePath path

デフォルトのコマンドライン・オプションが含まれているプロパティ・ファイルへのパスを指定します。

A.2.18.7 一般オプション

-?, -H, --help

このコマンドに対するコマンドライン使用情報を表示し、サーバーの停止または再起動を試行しないで終了します。

--version

ディレクトリ・サーバーのバージョン情報を表示して、このコマンドの実行を試みるかわりに終了します。

A.2.18.8 例

次の例は、サーバー・コマンドの使用方法を示しています。

例A-54 グラフィカル・アンインストーラを使用したアンインストール

次のコマンドによりアンインストーラGUIが開いて、削除の必要なコンポーネントを選択するためのプロンプトが表示されます:

$ uninstall

例A-55 コマンドラインを使用したアンインストール

次のコマンドにより、すべてのコンポーネントを削除するか、または特定のコンポーネントを削除するか指定するためのプロンプトが表示され、uninstallコマンドが実行されます。サーバーが実行中の場合は、続行する前にサーバーを停止するためのプロンプトが表示されます。

$ uninstall --cli

例A-56 非インタラクティブCLIモードでのアンインストール

このモードでは、uninstallコマンドを使用してアンインストール・スクリプトを作成できます。--no-prompt (-n)オプションおよび--quiet (-Q)オプションを指定する必要があります。オプションが指定されていない場合、uninstallコマンドのデフォルトはインタラクティブ・モードになります。-nオプションと-QオプションはどちらもCLIモードのみで機能します。

次のコマンドは、非インタラクティブCLIモードですべてのインスタンス・コンポーネントをアンインストールします。

$ uninstall --cli -a -n -Q

A.2.18.9 終了コード

次の終了コードは、ディレクトリ・サーバーとプロキシ・サーバーに適用できます:

0

成功。

1

ユーザーが操作を取り消しました。

2

ユーザーが無効なデータを指定しました。

3

ファイルシステムへのアクセス(読取り/書込み)中にエラーが発生しました。

5

ディレクトリ・サーバーの構成中にエラーが発生しました。

7

Oracle Unified Directoryサーバーの起動時にエラーが発生しました。

8

Oracle Unified Directoryサーバーの停止時にエラーが発生しました。

9

Windowsサービスの無効化中にエラーが発生しました。

10

アプリケーション固有のエラーです。

11

Oracle Unified Directoryツールの起動時にエラーが発生しました。

12

バグです。

13

Javaバージョンの互換性がありません。

14

ユーザーが無効な入力を指定しました。

50

印刷バージョン。

51

印刷の使用状況。

100

指定されていないエラーのリターン・コード。

次の終了コードは、ゲートウェイ・サーバーに適用できます:

0

正常にアンインストールしました。

1

予想外のエラーです(バグの可能性)。

2

引数を解析できないか、ユーザーにより指定されたデータが無効です。

3

ユーザーがアンインストールを取り消しました。

4

互換性のないJavaバージョンです。

5

レプリケーション・ゲートウェイ構成の初期化中(管理フレームワークのロード中など)にエラーが発生しました。

6

レプリケーション・ゲートウェイの停止時にエラーが発生しました。

7

Windowsサービスの構成解除中にエラーが発生しました。

8

入力限度エラーです。

9

ADSコンテンツの更新中にエラーが発生しました。

10

レガシー・サーバーの構成に関するエラーです。レプリカ構成で指定されたベースDNは無効なDNです。

11

指定されたレガシー(Oracle Directory Server Enterprise Edition)サーバーの1つに互換性がありません。

12

指定された新しい生成(Oracle Unified Directoryベースの)サーバーの1つに互換性がありません。

13

ユーザーが証明書を受け入れません。

14

いくつかのサーバーの構成のロード時に問題が生じたため、ユーザーは続行するつもりがありません。

15

レプリケーション・ゲートウェイの構成に関するエラーです。

16

ユーザーはインタラクティブ・モードでの最大試行回数を乗り越えました。

17

ユーザーがアンインストールを中止しました。

18

ファイルシステムへのアクセス(たとえば、インストール・ファイルの削除)中にエラーが発生しました。

A.2.18.10 プロパティ・ファイルの使用方法

ディレクトリ・サーバーでは、uninstallコマンドとともに使用されるデフォルトのオプション値を渡すプロパティ・ファイルの使用をサポートしています。プロパティ・ファイルは、様々な構成環境、特にスクリプト済アプリケーションまたは埋込みアプリケーションで作業する場合に便利です。詳細は、第A.1.2項「サーバー・コマンドによるプロパティ・ファイルの使用方法」を参照してください。

プロパティ・ファイルに保存可能なオプションは次のとおりです:

- adminUID

- bindPasswordFile

- certNickname

- hostname

- keyStorePasswordFile

- keyStorePath

- saslOption
SASLは、Oracle Unified Directoryに対してサポートされていません。

- trustAll

- trustStorePasswordFile

- trustStorePath

プロパティ・ファイルのエントリのフォーマットは、次のとおりです:

toolname.propertyname=propertyvalue

例:

uninstall.bindPasswordFile=/path/pwd-file

A.2.18.11 ログ・ファイル

uninstallコマンドは、oud-uninstall-IDnumberというログ・ファイルに書き込みます。この場合のIDnumberは10進数です。ログ・ファイルは次のパスに置かれています:

- UNIX (Solaris): /var/tmp/

- Linux: /tmp/

- Windows: %TEMP%フォルダ。デフォルトでは、このフォルダはC:\Documents and Settings\user\Local Settings\Tempです。

A.2.18.12 場所

uninstallコマンドは、次のパスに置かれています:

- UNIXおよびLinux: INSTANCE_DIR/OUD/uninstall

- Windows: INSTANCE_DIR\OUD\uninstall.bat

A.2.18.13 関連コマンド

- 第A.2.12項「oud-replication-gateway-setup」

- 第A.2.13項「oud-setup」

A.2.19 windows-service

windows-serviceコマンドにより、サーバーをWindowsサービスとして手動で有効または無効にすることができます。

A.2.19.1 シノプシス

windows-service [options]

A.2.19.2 説明

windows-serviceコマンドを使用して、サーバーをWindowsサービスとして手動で有効(または無効)にすることができます。WindowsサービスはUNIXデーモンに類似したバックグラウンドで実行するアプリケーションであり、ユーザーが直接制御することはできません。

A.2.19.3 コマンドのオプション

windows-serviceコマンドは、短いフォーム(例: -d)または同等の長いフォーム(例: --disableService)のいずれかでオプションを受け入れます:

-c,--cleanupService service-name

サービスを無効にして、指定されたサービス名に関連付けられているWindowsレジストリ情報をクリーンアップします。

-d, --disableService

サーバーをWindowsサービスとして無効化します。

-e, --enableService

サーバーをWindowsサービスとして有効化します。

-s, --serviceState

サーバーの状態をWindowsサービスとして表示します。

A.2.19.4 一般オプション

-?, -H, --help

このコマンドに対するコマンドライン使用情報を表示し、サーバーの停止または再起動を試行しないで終了します。

-V, --version

サーバーのバージョン情報を表示して、このコマンドの実行を試みるかわりに終了します。

A.2.19.5 例

次の例は、windows-serviceコマンドの使用方法を示しています。

例A-57 サーバーのWindowsサービスとしての有効化

次のコマンドにより、サーバーがWindowsサービスとして有効になります:

$ windows-service -e

例A-58 サーバーのWindowsサービスとしての無効化

次のコマンドにより、サーバーがWindowsサービスとして無効になります:

$ windows-service -d

例A-59 ステータスの表示

次のコマンドにより、Windowsサービスとしてサーバーのステータスが表示されます:

$ windows-service -s

A.2.19.6 終了コード

0

サーバーは正常に起動/停止しました。

1

サービスが見つかりません。

2

サーバー起動エラーです。サーバーはすでに停止しています。

3

サーバー停止エラーです。

A.2.19.7 場所

INSTANCE_DIR\OUD\bat\windows-service.bat

A.2.19.8 関連コマンド

第A.2.13項「oud-setup」

第A.2.14項「oud-proxy-setup」

第A.2.12項「oud-replication-gateway-setup」

A.3 データ管理コマンド

次の各項では、データ管理コマンドについて説明します:

- 第A.3.1項「backup」

- 第A.3.2項「base64」

- 第A.3.3項「dbtest」

- 第A.3.4項「encode-password」

- 第A.3.5項「export-ldif」

- 第A.3.6項「import-ldif」

- 第A.3.7項「ldif-diff」

- 第A.3.8項「ldifmodify」

- 第A.3.9項「ldifsearch」

- 第A.3.10項「list-backends」

- 第A.3.11項「make-ldif」

- 第A.3.12項「manage-account」

- 第A.3.13項「rebuild-index」

- 第A.3.14項「restore」

- 第A.3.15項「split-ldif」

- 第A.3.16項「verify-index」

A.3.1 backup

backupコマンドは、1つ以上のディレクトリ・サーバー・バックエンドのコンテンツをアーカイブします。

A.3.1.1 シノプシス

backup [options]

A.3.1.2 説明

backupコマンドは、1つ以上のディレクトリ・サーバー・バックエンドのコンテンツをアーカイブします。このコマンドにより、この操作を即時に、またはスケジュールされた時間に実行できます。詳細は、第14.4項「タスクとしてのコマンドの構成」を参照してください。

backupコマンドは、サーバーがオンラインまたはオフラインのときに実行できます。サーバーがオンラインのときにバックアップが実行している場合、このコマンドは管理コネクタを介してSSL上のサーバーに接続し、バックアップ・タスクを登録します。管理コネクタの詳細は、第14.3項「サーバーへの管理トラフィックの管理」を参照してください。

A.3.1.3 オプション

backupコマンドは、短いフォーム(例: -B backupID)または同等の長いフォーム(例: --incrementalBaseID backupID)のいずれかのオプションを受け入れます。

-a, --backUpAll

構成済のすべてのバックエンドをバックアップします。このオプションは、--backendIDと同時に使用しないでください。

-A, --hash

バックエンド・アーカイブのコンテンツのハッシュ、またはメッセージ・ダイジェストを生成します。リストア・プロセス中にハッシュをチェックサムとして使用し、バックアップを変更されていないようにすることができます。

-B, --incrementalBaseID backupID

増分バックアップの対象となる既存のバックアップに対してバックアップIDを指定します。このIDが指定されない場合、増分バックアップは最新の増分、またはバックアップ・ディレクトリにある全体バックアップに基づいて行われます。

-c, --compress

バックエンド・アーカイブのコンテンツを圧縮します。使用される圧縮アルゴリズムは、バックエンド・タイプに基づいて異なる場合があります。

-d, --backupDirectory path

指定されたディレクトリにバックアップ・ファイルを書き込みます。複数のバックエンドがアーカイブされる場合は、サブディレクトリがバックエンド別にこのパスの下に作成されます。そうでない場合、バックアップ・ファイルは直接このディレクトリに置かれます。バックエンドが同じである複数のバックアップは同一のディレクトリに置くことができます。増分バックアップを実行する場合は、バックアップ・ディレクトリに少なくとも1つの全体バックアップがすでに含まれている必要があります。これは必須オプションです。

オンライン・バックアップの場合、相対パスのルートは現在の作業ディレクトリではなく、インスタンス・ディレクトリです。たとえば、-d bknov2011を指定した場合、バックアップ・ファイルはinstance-dir/bknov2011に置かれます。

-i, --incremental

完全バックアップではなく、増分バックアップを実行します。増分バックアップには、前回の全体バックアップまたは増分バックアップ以降に変更されたデータのみが含まれます。そのため、増分バックアップは全体バックアップよりも著しく高速に処理されます。増分バックアップをリストアする場合、まず元の全体バックアップをリストアしてから中間の増分バックアップをリストアする必要があります。そのため、このリストア・プロセスは1つの全体バックアップのみのリストアよりも処理に時間がかかる場合があります。バックエンドのタイプによっては、増分バックアップの実行をサポートしていないものがあります。その場合、このオプションは無視されて完全バックアップが実行されます。

-I, --backupID backupID

バックアップに使用する識別子を指定します。指定されない場合は、現在時間に基づいてバックアップIDが生成されます。バックアップIDは、指定されたバックアップ・ディレクトリ内のすべてのバックアップの中で一意である必要があります。

-n, --backendID backendID

保存されるバックエンドのIDを指定します。このオプションを1つのコマンドで複数回使用して、複数のバックエンドをバックアップする必要があることを指定できます。サーバーで使用可能なバックエンドを決定するには、dsconfig list-backendsコマンドを使用します。

-s, --signHash

署名付きハッシュを生成します。これにより、バックアップ・アーカイブとそのコンテンツのハッシュがいずれも変更されていない場合に、より強力な保証が与えられます。このオプションは、オンライン・ディレクトリ・サーバー・インスタンスへの接続が確立されている場合のみ使用できます。その場合は、アーカイブの署名付きハッシュを生成するオンライン・ディレクトリ・サーバーのオプション--hostname、--port、--bindDN、および--bindPasswordFileを指定する必要があります。

-y, --encrypt

バックアップ・アーカイブのコンテンツを暗号化します。このオプションは、オンライン・サーバー・インスタンスへの接続が確立されている場合のみ使用できます。その場合は、アーカイブを暗号化するオンライン・ディレクトリ・サーバーのオプション--hostname、--port、--bindDN、および--bindPasswordFileを指定する必要があります。

A.3.1.4 タスク・バックエンド接続オプション

オンライン・バックエンドを実行するには、タスク・バックエンドにアクセスする必要があります。タスク・バックエンドへのアクセスは、管理コネクタを介してSSLによって指定されます。これらの接続オプションは、バックアップをオンラインで実行するときに使用します。

-D, --bindDN bindDN

バインドDNを使用してディレクトリ・サーバーを認証します。このオプションは簡易認証の実行時に使用されます。SASL認証を使用する場合、このオプションは必要ありません。このオプションのデフォルト値はcn=Directory Managerです。

-h, --hostname hostname

指定されたホスト名またはIPアドレスのディレクトリ・サーバーに接続します。このオプションが指定されない場合は、localhostのデフォルトが使用されます。

-j, --bindPasswordFile filename

ディレクトリ・サーバーに対して認証を受ける際、指定したファイルにバインド・パスワードを使用します。

-K, --keyStorePath path

指定されたパスにクライアント・キーストア証明書を使用します。

-N, --certNickname nickname

指定された証明書をクライアント認証に使用します。

-o, --saslOption name=value

指定されたオプションをSASL認証に使用します。

-p, --port port

指定された管理ポートでディレクトリ・サーバーに接続します。このオプションが指定されない場合は、4444というデフォルトの管理ポートが使用されます。

-P, --trustStorePath path

指定されたパスにクライアント・トラスト・ストア証明書を使用します。このオプションは、--trustAllを使用している場合は必要ありません。ただし、本番環境で作業する場合はトラスト・ストアを使用する必要があります。

-u, --keyStorePasswordFile filename

クライアント・キーストアの証明書にアクセスするために、指定されたファイルでパスワードを使用します。このオプションは、--keyStorePathを使用する場合のみ必須です。

-U, --trustStorePasswordFile filename

クライアント・トラスト・ストアの証明書にアクセスするために、指定されたファイルでパスワードを使用します。このオプションは、--trustStorePathを使用していて、指定したトラスト・ストアがコンテンツへのアクセスにパスワードを必要とする場合のみ必須です(ほとんどのトラスト・ストアでは必要とされません)。

-X, --trustAll

ディレクトリ・サーバーによって提示されるすべてのサーバーSSL証明書を信頼します。このオプションは便宜的に、かつテストの目的で使用できますが、セキュリティ上の理由から、トラスト・ストアを使用してクライアントがサーバーの証明書を受け入れるかどうかを判別する必要があります。

A.3.1.5 タスク・スケジュール・オプション

これらのオプションは、バックアップをスケジュール済タスクとして実行すると指定したときに使用します。

--completionNotify emailAddress

タスク終了時に通知される受信者の電子メール・アドレスを指定します。このオプションは、1つのコマンドで複数回指定できます。

--dependency taskId

このタスクが依存するタスクのIDを指定します。タスクのすべての依存性が実行を完了するまで、タスクの実行は開始しません。

--errorNotify emailAddress

このタスクの実行時にエラーが発生した場合に通知される受信者の電子メール・アドレスを指定します。このオプションは、1つのコマンドで複数回指定できます。

--failedDependencyAction action

依存タスクの1つが失敗した場合に、このタスクが実行する必要のあるアクションを指定します。この値として、PROCESS、CANCEL、またはDISABLEのいずれか1つが割り当てられている必要があります。値を指定しない場合、デフォルトのアクションはCANCELです。

--recurringTask schedulePattern

タスクは再帰的であり、crontab(5)互換の時間/日付パターンとして表記されるschedulePatternに従ってスケジュールされることを示します。

-t, --start startTime

ディレクトリ・サーバー・タスクとしてスケジュールされている際に、YYYYMMDDhhmmssのフォーマットで表記される操作の開始日付と時間を指定します。値0は、タスクを即時実行するようにスケジュールします。このオプションが指定された場合、操作は指定の時間に開始するようスケジュールされ、その直後にコマンドが終了します。

A.3.1.6 コマンド入力/出力オプション

--noPropertiesFile

デフォルトのコマンドライン・オプションの取得にプロパティ・ファイルが使用されていないことを示します。

--propertiesFilePath path

デフォルトのコマンドライン・オプションが含まれているプロパティ・ファイルへのパスを指定します。

A.3.1.7 一般オプション

-?, -H, --help

このコマンドに対するコマンドライン使用情報を表示し、データのバックアップを試行しないで終了します。

-V, --version

ディレクトリ・サーバーのバージョン情報を表示して、このコマンドの実行を試みるかわりに終了します。

A.3.1.8 例

次の例は、ディレクトリ・サーバー・コマンドの使用方法を示しています。

例A-60 すべての構成済バックエンドのバックアップ

次のコマンドは、すべてのディレクトリ・サーバー・バックエンドをアーカイブし(-a)、それらを圧縮し(-c)、指定されたディレクトリに保存します(-d)。

$ backup -a -c -d /tmp/backup

バックエンド別にサブディレクトリを確認するために、バックアップ・ディレクトリのコンテンツを表示します:

$ ls /tmp/backup
config    schema    tasks     userRoot

現在時間に基づいてバックアップIDがシステムに割り当てられていることを確認するために、サブディレクトリのコンテンツを表示します。

$ ls /tmp/backup/userRoot/
backup-userRoot-20081015151640Z  backup.info

-Iオプションを使用して、独自のバックアップIDを割り当てることができます。例:

$ backup -a -c -d /tmp/backup -I October08

割り当てられたバックアップIDを確認するために、userRootサブディレクトリのコンテンツを表示します。

$ ls /tmp/backup/userRoot/
backup-userRoot-October08        backup.info

例A-61 特定のバックエンドのバックアップ

バックアップするバックエンドを指定するには、-nオプションを使用します。次のコマンドは、userRootバックエンドのみをアーカイブします。

$ backup -n userRoot -d /tmp/backup

例A-62 増分バックアップの実行

次のコマンドは、増分バックアップ(-i)を使用してすべてのディレクトリ・サーバー・バックエンドをアーカイブし(-a)、それらを圧縮して(-c)、ディレクトリにデータを保存します(-d)。

$ backup -a -i -c -d /tmp/backup

例A-63 特定のバックエンドでの増分バックアップの実行

現在の構成済バックエンドを表示するには、list-backendsコマンドを使用します。

$ list-backends
Backend ID     : Base DN
---------------:--------------------
adminRoot      : cn=admin data
ads-truststore : cn=ads-truststore
backup         : cn=backups
config         : cn=config
monitor        : cn=monitor
schema         : cn=schema
tasks          : cn=tasks
userRoot       : "dc=example,dc=com"

次のコマンドは、userRootバックエンド(-n)で増分バックアップ(-i)を実行し、そのバックアップを圧縮して(-c)、ディレクトリにデータを保存します(-d)。

$ backup -i -n userRoot -c -d /tmp/backup/userRoot

例A-64 既存のバックアップに対する増分バックアップの実行

-Iオプションまたは--backupIDオプションを使用して2つのアーカイブ済の増分バックアップ・ファイルを作成し、その2つのファイルにID、1234および4898をそれぞれ割り当てているとします:

/tmp/backup/userRoot> ls
./     backup-userRoot-1234   backup.info
../    backup-userRoot-4898   backup.info.save

次のコマンドは、バックアップID 1234に基づいて(-B)すべての構成済バックエンド(-a)で増分バックアップ(-i)を実行し、バックアップID 5438を増分バックアップに割り当てて、ディレクトリにデータを保存します(-d)。

$ backup -a -i -B 1234 -I 5438 -d /tmp/backup

backup.infoのコンテンツは、最新の増分バックアップ(backup_id=5438)がbackup_id=1234に対して依存性を持っていることを示しています:

$ backend_dn=ds-cfg-backend-id=userRoot,cn=Backends,cn=config

backup_id=4898
backup_date=20070727202906Z
incremental=false
compressed=false
encrypted=false
signed_hash=VmBG/VkfMAMMPnR6M8b5kZil7FQ=
property.last_logfile_name=00000000.jdb
property.archive_file=backup-userRoot-4898
property.cipher_algorithm=AES/CBC/PKCS5Padding
property.mac_algorithm=HmacSHA1
property.last_logfile_size=490554

backup_id=1234
backup_date=20070727202934Z
incremental=false
compressed=false
encrypted=false
signed_hash=VmBG/VkfMAMMPnR6M8b5kZil7FQ=
property.last_logfile_name=00000000.jdb
property.archive_file=backup-userRoot-1234
property.cipher_algorithm=AES/CBC/PKCS5Padding
property.mac_algorithm=HmacSHA1
property.last_logfile_size=490554

backup_id=5438
backup_date=20070727203107Z
incremental=true
compressed=false
encrypted=false
dependency=1234
property.last_logfile_name=00000000.jdb
property.archive_file=backup-userRoot-5438
property.last_logfile_size=490554

例A-65 暗号化および署名付きハッシュによるすべての構成済バックエンドのバックアップ

ディレクトリ・サーバーでは、セキュアなアーカイブ済データに対して、バックアップ暗号化(--encryptを使用)、ハッシュの生成(--hashを使用)、および署名付きハッシュ(--signHashを使用)をサポートしています。これらのオプションでは、管理コネクタを介してSSL上でオンライン・サーバー・インスタンスに接続する必要があります。したがって、これらのオプションを使用する場合は、ホスト、管理ポート、バインドDN、およびバインド・パスワード・ファイルも含めた接続の詳細を指定する必要があります。また、SSL接続用に証明書の詳細を指定する必要もあります。

次のコマンドは、すべてのディレクトリ・サーバー・バックエンドをアーカイブし(-a)、それらを圧縮し(-c)、ハッシュを生成し(-A)、そのハッシュに署名し(-s)、データのアーカイブ中にデータを暗号化し(-y)、バックエンドID 123を割り当てて、データをディレクトリに保存します(-d)。自己署名証明書は、-X (--trustAll)オプションを使用して信頼されます。

$ backup -h localhost -D "cn=Directory Manager" -j /path/pwd-file -p 4444 -X \
-a -c -A -s -y -I 123 -d /tmp/backup
Backup task 2008101609295810 scheduled to start immediately
...

例A-66 バックアップのスケジュール

バックエンドをスケジュールするには、タスク・バックエンドにオンラインでアクセスする必要があります。このバックエンドへのアクセスは、管理コネクタを介してSSLによって指定されます。したがって、バックアップをスケジュールする場合は、ホスト、管理ポート、バインドDN、およびバインド・パスワード・ファイルも含めた接続の詳細を指定する必要があります。また、SSL接続用に証明書の詳細を指定する必要もあります。

次のコマンドは、すべてのコンポーネントのバックアップをスケジュールして(-a)、それを/tmp/backupsディレクトリに書き込みます(-d)。開始時間は、--startオプションによって指定されます。バックアップにより、完了通知とエラー通知がadmin@example.comに送信されます。自己署名証明書は、-X (--trustAll)オプションを使用して信頼されます。

$ backup -h localhost -D "cn=Directory Manager" -j /path/pwd-file -p 4444 -X \
-a -d /tmp/backups --start 20090124121500 --completionNotify admin@example.com \
--errorNotify admin@example.com
Backup task 2007102914530410 scheduled to start Jan 24, 2009 12:15:00 PM SAST

このスケジュール済タスクを表示するには、manage-tasksコマンドを使用します。詳細は、第14.4項「タスクとしてのコマンドの構成」を参照してください。

A.3.1.9 終了コード

終了コード0は、操作が正常に終了したことを示します。終了コード1は、処理中にエラーが発生したことを示します。

A.3.1.10 プロパティ・ファイルの使用方法

ディレクトリ・サーバーでは、backupコマンドとともに使用されるデフォルトのオプション値を渡すプロパティ・ファイルの使用をサポートしています。プロパティ・ファイルは、様々な構成環境、特にスクリプト済アプリケーションまたは埋込みアプリケーションで作業する場合に便利です。詳細は、第A.1.2項「サーバー・コマンドによるプロパティ・ファイルの使用方法」を参照してください。

A.3.1.11 場所

backupコマンドは、次のパスに置かれています:

- UNIXおよびLinux: INSTANCE_DIR/OUD/bin/backup

- Windows: INSTANCE_DIR\OUD\bat\backup.bat

A.3.1.12 関連コマンド

- 第A.3.14項「restore」

- 第A.3.10項「list-backends」

- 第A.2.8項「manage-tasks」

A.3.2 base64

base64コマンドは、base64エンコーディング・フォーマットを使用してバイナリ文字列をエンコードします。

A.3.2.1 シノプシス

base64 subcommand[options]

A.3.2.2 説明

base64コマンドは、base64エンコーディング・フォーマットを使用してバイナリ文字列をテキスト表現にエンコードします。base64エンコーディングは、非ASCII文字の文字列を表現するためにLDIFファイルで頻繁に使用します。また、証明書の内容や、MD5またはSHAなどのメッセージ・ダイジェストの出力のエンコードにも多用されます。

A.3.2.3 サブコマンド

base64コマンドで使用されるサブコマンドは、次のとおりです。

decode

base64でエンコードされた情報をrawデータにデコードします。サブオプションは次のとおりです:

-d, --encodedData encoded-data.。rawデータにデコードするbase64でエンコードされたデータ。

-f, --encodedDataFile filename。デコード対象のbase64でエンコードされたデータが含まれているファイルへのパス。

-o, --toRawFile filename。rawデータの書き込み先であるファイルへのパス。

encode

raw dataをbase64にエンコードします。サブオプションは次のとおりです:

-d, --rawData raw-data。base64にエンコードするraw data。

-f, --rawDataFile filename。base64でエンコードされるrawデータが含まれているファイルへのパス。

-o, --toEncodedFile filename。base64エンコードされたデータの書込み先であるファイルへのパス。

A.3.2.4 グローバル・オプション

-?, -H, --help

使用情報を表示します。

-V, --version

ディレクトリ・サーバーのバージョン情報を表示します。

A.3.2.5 例

次の例は、ディレクトリ・サーバー・コマンドの使用方法を示しています。

例A-67 base64による文字列のエンコード

次のコマンドにより、文字列opendsがbase64でエンコードされます。

$ base64 encode -d opends
b3BlbmRz

例A-68 base64によるファイルのコンテンツのエンコード

次のコマンドにより、ファイル(-f)がbase64でエンコードされ、出力ファイル(-o)に書き込まれます。

$ base64 encode -f myrawdata -o myencodeddata

例A-69 base64でエンコードされた文字列のデコード

次のコマンドにより、base64でエンコードされた文字列がデコードされます。

$ base64 decode -d b3BlbmRz
opends

例A-70 base64でエンコードされたファイルのコンテンツのデコード

次のコマンドにより、base64でエンコードされたファイル(-f)がデコードされ、出力ファイル(-o)に書き込まれます。

$ base64 encode -f myencodeddata -o myoutput

例A-71 Linuxシステムでのbase64によるエンコードおよびデコード

次のコマンドは、Linux上でコマンドラインからエンコードとデコードを実行します。クリアテキスト文字列を入力した後で、[Control]-[D]キーを押してコマンドライン上での入力の終わりのシグナルを送ります。

$ base64 encode
hello world
<CTRL-D>
aGVsbGBqd29ybGQK

$ base64 decode
aGVsbG8gd29ybGQK
<CTRL-D>
hello world

A.3.2.6 終了コード

終了コード0は、操作が正常に終了したことを示します。終了コード1は、処理中にエラーが発生したことを示します。

A.3.2.7 場所

- UNIXおよびLinux: INSTANCE_DIR/OUD/bin/base64

- Windows: INSTANCE_DIR\OUD\bat\base64.bat

A.3.3 dbtest

dbtestコマンドは、Oracle Berkeley Java Edition (JE)バックエンドをデバッグします。

A.3.3.1 シノプシス

dbtest subcommands [options]

A.3.3.2 説明

dbtestコマンドは、Oracle Berkeley Java Edition (JE)バックエンドのデバッグに使用します。このコマンドにより、ルート、エントリ、データベース・コンテナ、およびデータベース内の索引のステータスがリストされます。また、デバッグ用にデータベースのダンプも指定されます。

バックエンドは、ディレクトリ・サーバーにデータを格納するためのリポジトリです。バックエンドは特定のタイプのデータベース(DB)を使用してデータを格納し、ディレクトリ内でバックエンドがエントリを検索できるようにする索引セットを維持します。ディレクトリ・サーバーのプライマリ・データベースはBerkeley Java Edition (JE)データベースであり、ここでは、データが鍵付きレコードの単一コレクションとしてBツリー形式で編成されます。

dbtestコマンドを使用して次の情報にアクセスできます:

- ルート・コンテナ。バックエンドIDとバックエンド用のディレクトリを指定します。

- エントリ・コンテナ。エントリ・コンテナがディスクに格納しているベースDN、データベース名に使用するデータベース接頭辞、およびデータベース内のエントリ数を指定します。JEバックエンドの各ベースDNには、それぞれ専用のエントリ・コンテナが割り当てられています。

- データベース・コンテナ。特定のバックエンドIDのデータベース名、タイプ、およびJEデータベース名を指定します。

- 索引ステータス。索引名、タイプ、ステータス、および関連付けられているJEデータベースを指定します。

現在、dbtestコマンドは読取り専用コマンドであり、データベースを変更することはできません。このコマンドはオンライン・モードまたはオフライン・モードで実行できます。ただし、オンライン・モードでdbtestを実行すると、オフライン・モードでの実行よりもかなり長い時間がかかる場合があります。

A.3.3.3 サブコマンド

dump-database-container

レコードをデータベース・コンテナからダンプします。サブオプションは次のとおりです:

-b, --baseDN baseDN。デバッグするエントリ・コンテナのベースDN。必須。

-d, --databaseName databaseName。デバッグするデータベース・コンテナの名前。必須。

-k, --minKeyValue value。データベース・コンテナのコンパレータを使用して指定値の後に順序付けする必要のあるキーを持つレコードのみを表示します。

-K, --maxKeyValue value。データベース・コンテナのコンパレータを使用して指定値の前に順序付けする必要のあるキーを持つレコードのみを表示します。

-n, --backendID backendID。デバッグするローカルDBバックエンドのID。必須。

-p, --skipDecode。ローカル・データベースのデコードを、その適切なタイプに応じてスキップします。

-q, --statsOnly。完全なデータではなく、統計のみを表示します。

-s, --minDataSize size。指定された値以上のデータを持つレコードのみを表示します。

-S, --maxDataSize size。指定された値以下のデータを持つレコードのみを表示します。

list-database-containers

エントリ・コンテナ用のデータベース・コンテナをリストします。サブオプションは次のとおりです:

-b, --baseDN baseDN。デバッグするエントリ・コンテナのベースDN。必須。

-n, --backendID backendID。デバッグするローカルDBバックエンドのID。必須。

list-entry-containers

ルート・コンテナ用のエントリ・コンテナをリストします。サブオプションは次のとおりです:

-n, --backendID backendID。デバッグするローカルDBバックエンドのID。必須。

list-index-status

エントリ・コンテナ内の索引のステータスをリストします。サブオプションは次のとおりです:

-b, --baseDN baseDN。デバッグするエントリ・コンテナのベースDN。必須。

-n, --backendID backendID。デバッグするローカルDBバックエンドのID。必須。

list-root-containers

すべてのローカルDBバックエンドによって使用されるルート・コンテナをリストします。

A.3.3.4 グローバル・オプション

dbtestコマンドは、短いフォーム(例: -H)または同等の長いフォーム(例: --help)のいずれかでオプションを受け入れます。

-?, -H, --help

使用情報を表示します。

-V, --version

ディレクトリ・サーバーのバージョン情報を表示します。

A.3.3.5 例

次の例は、ディレクトリ・サーバー・コマンドの使用方法を示しています。

例A-72 ルート・コンテナのリストの表示

次のコマンドにより、すべてのローカルDBバックエンドによって使用されるルート・コンテナがリストされます:

$ dbtest list-root-containers
Backend ID  Database Directory
------------------------------
userRoot    db

Total: 1

例A-73 エントリ・コンテナのリストの表示

次のコマンドにより、ローカルDBバックエンド上のエントリ・コンテナのリストが表示されます:

$ dbtest list-entry-containers -n userRoot
Base DN            JE Database Prefix  Entry Count
--------------------------------------------------
dc=example,dc=com  dc_example_dc_com   102

Total: 1

例A-74 データベース・コンテナのリストの表示

次のコマンドにより、ローカルDBバックエンド上のデータベース・コンテナのリストが表示されます:

$ dbtest list-database-containers -b dc=example,dc=com -n userRoot
Database Name              Database  JE Database Name                       Entry Count
Type
---------------------------------------------------------------------------------------
dn2id                      DN2ID     dc_example_dc_com_dn2id                      102
id2entry                   ID2Entry  dc_example_dc_com_id2entry                   102
referral                   DN2URI    dc_example_dc_com_referral                   0
id2children                Index     dc_example_dc_com_id2children                2
id2subtree                 Index     dc_example_dc_com_id2subtree                 2
state                      State     dc_example_dc_com_state                      19
objectClass.equality       Index     dc_example_dc_com_objectClass.equality       6
givenName.equality         Index     dc_example_dc_com_givenName.equality         100
givenName.substring        Index     dc_example_dc_com_givenName.substring        396
member.equality            Index     dc_example_dc_com_member.equality            0
uid.equality               Index     dc_example_dc_com_uid.equality               100
cn.equality                Index     dc_example_dc_com_cn.equality                100
cn.substring               Index     dc_example_dc_com_cn.substring               1137
uniqueMember.equality      Index     dc_example_dc_com_uniqueMember.equality      0
telephoneNumber.equality   Index     dc_example_dc_com_telephoneNumber.equality   100
telephoneNumber.substring  Index     dc_example_dc_com_telephoneNumber.substring  956
sn.equality                Index     dc_example_dc_com_sn.equality                100
sn.substring               Index     dc_example_dc_com_sn.substring               541
ds-sync-hist.ordering      Index     dc_example_dc_com_ds-sync-hist.ordering      0
mail.equality              Index     dc_example_dc_com_mail.equality              100
mail.substring             Index     dc_example_dc_com_mail.substring             525
entryUUID.equality         Index     dc_example_dc_com_entryUUID.equality         102
aci.presence               Index     dc_example_dc_com_aci.presence               0

Total: 23

例A-75 データベースのコンテンツのダンプとデコードのスキップ

次のコマンドによってデータベースのコンテンツがダンプされ、エントリの索引付きの値が表示されますが、デコードはスキップされます。

$ dbtest dump-database-container -b dc=example,dc=com -n userRoot \
-d objectClass.equality -p

Key (6 bytes):
64 6F 6D 61 69 6E domain

Data (8 bytes):
00 00 00 00 00 00 00 01

Key (18 bytes):
67 72 6F 75 70 6F 66 75 6E 69 71 75 65 6E 61 6D groupofu niquenam
65 73 es

Data (40 bytes):
00 00 00 00 00 00 00 03 00 00 00 00 00 00 00 9C
00 00 00 00 00 00 00 9D 00 00 00 00 00 00 00 9E
00 00 00 00 00 00 00 9F
...

A.3.3.6 終了コード

終了コード0は、操作が正常に終了したことを示します。終了コード1は、処理中にエラーが発生したことを示します。

A.3.3.7 場所

- UNIXおよびLinux: INSTANCE_DIR/OUD/bin/dbtest

- Windows: INSTANCE_DIR\OUD\bat\dbtest.bat

A.3.3.8 関連コマンド

- 第A.2.4項「dsconfig」

- 第A.3.6項「import-ldif」

- 第A.3.5項「export-ldif」

A.3.4 encode-password

encode-passwordコマンドは、ユーザー・パスワードのエンコードと比較を行います。

このコマンドはプロキシに対してサポートされていません。

A.3.4.1 シノプシス

encode-password options

A.3.4.2 説明

encode-passwordコマンドは、ディレクトリ・サーバーで定義されたパスワード記憶スキームとの相互作用に使用できます。次の3つの操作モードが使用できます:

- スキームのリスト・モード。ディレクトリ・サーバーで使用できるパスワード記憶スキームをリストします。このモードでは、--listSchemesオプションは必須です。

- クリアテキストのエンコード・モード。指定されたパスワード記憶スキームを使用して、クリアテキスト・パスワードをエンコードします。このモードでは、ファイル(--clearPasswordFile)から読み取られるクリアテキスト・パスワードとともに、--storageSchemeオプションが必要です。

- パスワードの検証モード。指定されたエンコード済パスワードに対して指定されたクリアテキスト・パスワードが正しいかどうかを判別します。このモードでは、クリアテキスト・パスワード(--clearPasswordFileによる)とエンコード済パスワード(--encodedPasswordFileによる)が必要です。

ディレクトリ・サーバーで使用可能な認証パスワードのセットは、ルートDSEエントリのsupportedAuthPasswordSchemes属性から取得できます。ldapsearchを使用して、この情報を表示できます。

A.3.4.3 オプション

encode-passwordコマンドは、短いフォーム(例: -f filename)または同等の長いフォーム(例: --clearPasswordFile filename)のいずれかのオプションを受け入れます。

-a, --authPasswordSyntax

値をscheme$authInfo$authValueのフォームでエンコードする認証パスワード構文(RFC 3112 (http://www.ietf.org/rfc/rfc3112.txt)に定義されています)を使用します。このオプションが指定されていない場合は、ユーザー・パスワード構文(値をscheme$valueのフォームでエンコードします)が使用されます。

-E, --encodedPasswordFile filename

指定したファイルからエンコード済パスワードを使用して、指定されたクリアテキスト・パスワードと比較します。--authPasswordSyntaxオプションも指定されている場合、このパスワードは認証パスワード構文を使用してエンコードする必要があります。そうでない場合は、ユーザー・パスワード構文を使用してエンコードします。

-f, --clearPasswordFile filename

クリアテキスト・パスワードをエンコードする場合、またはクリアテキスト・パスワードをエンコード済パスワードと比較する場合は、指定したファイルからクリアテキスト・パスワードを使用します。

-i, --interactivePassword

エンコードするパスワード、またはエンコード済パスワードと比較するパスワードは、ユーザーからインタラクティブにリクエストされます。

-l, --listSchemes

ディレクトリ・サーバーで使用できるパスワード記憶スキームのリストを表示します。このオプションを単独で使用する場合は、ユーザー・パスワード構文をサポートしているパスワード記憶スキームの名前が表示されます。このオプションを--authPasswordSyntaxとともに使用する場合は、認証パスワード構文をサポートしているパスワード記憶スキームの名前が表示されます。

-r, --useCompareResultCode

指定されたクリアテキスト・パスワードが指定されたエンコード済パスワードと一致したかどうかを示す終了コードを使用します。このオプションが指定されている場合、ディレクトリ・サーバーは終了コード6 (COMPARE_TRUE)または終了コード5 (COMPARE_FALSE)を表示します。その他の終了コードは、コマンドが必要な決定を行うための処理に失敗したことを示します。このオプションが指定されていない場合、ゼロの終了コードを使用してコマンドが処理を正常に終了したことを示すか、エラーが発生した場合には、ゼロ以外の終了コードを使用します。

-s, --storageScheme storageScheme

クリアテキスト・パスワードのエンコードに使用するパスワード記憶スキームの名前を指定します。--authPasswordSyntaxオプションが指定されている場合は、サポートされている認証パスワード記憶スキームの名前を値として指定する必要があります。そうでない場合は、サポートされているユーザー・パスワード記憶スキームの名前を指定します。

-?, -H, --help

このコマンドに対するコマンドライン使用情報を表示し、その他のアクションを実行しないで即時に終了します。

-V, --version

ディレクトリ・サーバーのバージョン情報を表示します。

A.3.4.4 例

次の例は、encode-passwordコマンドの使用方法を示しています。

例A-76 サーバーでの記憶スキームのリスト

次のコマンドは、ディレクトリ・サーバーで使用できる記憶スキーム(-l)をリストします。

$ encode-password -l
3DES
AES
BASE64
BLOWFISH
CLEAR
CRYPT
MD5
RC4
SHA
SMD5
SSHA
SSHA256
SSHA384
SSHA512

例A-77 サーバーでの認証済パスコード構文記憶スキームのリスト

次のコマンドは、ディレクトリ・サーバーで認証パスコード構文(-a)をサポートする記憶スキーム(-l)をリストします。

$ encode-password -l -a

MD5
SHA1
SHA256
SHA384
SHA512

例A-78 クリアテキスト・パスワードの別のスキームへのエンコード

次のコマンドにより、指定されたスキーム(-s)を使用して、クリアテキスト・パスワードがファイル(-f)にエンコードされます。

$ encode-password -f /path/clear-pwd-file -s MD5

Encoded Password:  "{MD5}AjxHKRFkRwxx3j9lM2HMow=="

例A-79 認証パスワード構文を使用したクリアテキスト・パスワードの別のスキームへのエンコード

次のコマンドにより、指定されたスキーム(-s)と認証パスワード構文(-a)を使用して、クリアテキスト・パスワードがファイル(-f)にエンコードされます。

$ encode-password -f /path/clear-pwd-file -s MD5 -a

Encoded Password:  "MD5$/imERhcEu3U=$AFqmpZi8EiTIvMFwkcrf8A=="

例A-80 クリアテキスト・パスワードとエンコード済パスワードの比較

次のコマンドにより、ファイル内のクリアテキスト・パスワード(-f)が、ファイル内のエンコード済パスワード(-E)と比較されます。エンコード済パスワードには、パスワード・スキーム(たとえば、MD5)を含めないでください。

$ encode-password -f /path/clear-pwd-file -E /path/encoded-pwd-file -s MD5

The provided clear-text and encoded passwords match

例A-81 クリアテキスト・パスワードとエンコード済パスワードの比較および終了コードの返し

次のコマンドにより、スキーム(-s)を使用してファイル内のクリアテキスト・パスワード(-f)がファイル内のエンコード済パスワード(-E)と比較され、終了コード(-r)が返されます(COMPARETRUEの場合は6、COMPAREFALSEの場合は5)。エンコード済パスワードには、パスワード・スキーム(たとえば、MD5)を含めないでください。

$ encode-password -f /path/clear-pwd-file -E /path/encoded-pwd-file -s MD5 -r

The provided clear-text and encoded passwords match

echo $?
6

例A-82 SSHAを使用したファイル内のパスワードのエンコード

次のコマンドにより、指定されたスキーム(-s)を使用して、クリアテキスト・パスワードがファイル(-f)にエンコードされます。Windowsプラットフォームの場合は、クリアテキスト・パスワード・ファイルへのパス(たとえば、-f \temp\testpassword)を指定します:

$ encode-password -s SSHA -f /path/clear-pwd-file

Encoded Password:   "{SSHA}QX2fMu+2N22N9qI+zu6fIZxsBVID3EsUlYYEbQ=="

A.3.4.5 終了コード

表A-3 終了コード

終了コード

説明

0

操作は正常に完了しました。

1

操作中にエラーが発生しました。

5

COMPARE_FALSE。オプション--rまたは--useCompareCodeResultとともに使用した場合、終了コード5によって、指定されたクリアテキスト・パスワードが指定されたエンコード済パスワードと一致しないことが示されます。

6

COMPARE_TRUE。オプション--rまたは--useCompareCodeResultとともに使用した場合、終了コード6によって、指定されたクリアテキスト・パスワードが指定されたエンコード済パスワードと一致することが示されます。

A.3.4.6 場所

- UNIXおよびLinux: INSTANCE_DIR/OUD/bin/encode-password

- Windows: INSTANCE_DIR\OUD\bat\encode-password.bat

A.3.5 export-ldif

export-ldifコマンドは、ディレクトリ・サーバー・バックエンドのコンテンツをLDIF形式にエクスポートします。

A.3.5.1 シノプシス

export-ldif [options]

A.3.5.2 説明

export-ldifコマンドは、ディレクトリ・サーバー・バックエンドのコンテンツをLDIF形式にエクスポートします。このコマンドにより、エクスポートを即時に実行するか、または指定された日付と時間で実行するようにスケジュールすることができます。詳細は、第14.4項「タスクとしてのコマンドの構成」を参照してください。

一部のバックエンドはディレクトリ・サーバーへインポートできないため、export-ldifコマンドは、monitor、ads-truststore、backup、config-file-handlerなどのバックエンドをエクスポートしません。

export-ldifコマンドは、オンラインまたはオフラインで実行できます。

- オンライン・モード。オンライン・モードでは、export-ldifは管理コネクタを介してSSL上で実行中のディレクトリ・サーバー・インスタンスに接続し、エクスポート・タスクを登録します。タスク・バックエンド接続オプションのいずれかを指定した場合、このコマンドは自動的にオンライン・モードで実行します。管理コネクタの詳細は、第14.3項「サーバーへの管理トラフィックの管理」を参照してください。

- オフライン・モード 。オフライン・モードでは、export-ldifはディレクトリ・サーバー・インスタンスを介さずに、データベースに直接アクセスします。オフライン・エクスポートを実行するには、ディレクトリ・サーバーを停止する必要があります。

A.3.5.3 オプション

export-ldifコマンドは、短いフォーム(例: -b branchDN)または同等の長いフォーム(例: --includeBranch branchDN)のいずれかのオプションを受け入れます。

-a, --appendToLDIF

既存のLDIFファイルを上書きするのではなく、それにエクスポートを追加します。このオプションが指定されない場合、ディレクトリ・サーバーは、指定されたLDIFファイルが存在する場合にそれを上書きします。

-b, --includeBranch branchDN

エクスポートするデータのブランチまたはサブツリーのベースDNを指定します。このオプションを複数回使用して、複数のベースDNを指定できます。このオプションが指定された場合、バックエンド内で指定されたベースDNの1つにないエントリ、またはそれより下のエントリはスキップされます。

-B, --excludeBranch branchDN

エクスポートから除外するデータのブランチまたはサブツリーのベースDNを指定します。このオプションを複数回使用して、複数のベースDNを指定できます。このオプションが指定された場合、バックエンド内で指定されたベースDNの1つにあるエントリ、またはそれより下のエントリはすべてスキップされます。--excludeBranchオプションの使用は、--includeBranchオプションよりも優先されます。含まれるリストと除外されるリストの両方に表示されているDNにあるエントリ、またはそのDNより下にあるエントリは含まれません。この機能によって、ブランチの一部であるデータのみを含めることが可能になります。たとえば、ou=People,dc=example,dc=comより下のエントリを除き、dc=example,dc=comより下のエントリをすべて含めることができます。

-c, --compress

LDIFデータが書き込まれるときに、それを圧縮します。データの圧縮には、import-ldifコマンドの--isCompressedオプションにより使用される形式であるGZIP形式が使用されます。

-e, --excludeAttribute attribute

エクスポート時に、指定された属性名を除外します。このオプションを複数回使用して、複数の属性を指定できます。このオプションが指定された場合、リストされた属性はすべて、エクスポートされるエントリから除外されます。

-E, --excludeFilter filter

エクスポート時に、指定した検索フィルタによって識別されたエントリを除外します。このオプションを複数回使用して、複数のフィルタを指定できます。このオプションが指定された場合、フィルタに一致するバックエンド内のエントリはすべてスキップされます。--excludeFilterオプションの使用は、--includeFilterオプションよりも優先されます。エントリが含まれるリストと除外されるリストの両方でフィルタに一致する場合、そのエントリはスキップされます。

-i, --includeAttribute attribute

指定した属性名をエクスポートに含めます。このオプションを複数回使用して、複数の属性を指定できます。このオプションが指定された場合、リストされない属性はすべて、エクスポートされるエントリから除外されます。

-g, --algorithm algorithm

指定したアルゴリズムがエクスポートで使用されます。このオプションは任意であり、次の値のいずれかを入力できます:

- diskOrder: このオプションにより、Oracle Berkeley DB Java Edition (JE)バックエンドから、ディスクに格納されている順序でデータを読み取ることができます。
このオプションの利点は、次のとおりです:

- データベースがデータベース・キャッシュにまったく適合しない場合にお薦めします。

- 実行用にデータベース・キャッシュを一時的に20%使用し、その後でデータベース・キャッシュを解放します。エクスポート時に、データベース・キャッシュ・メモリーが20%減少します。

注意:

このアルゴリズムはJEバックエンドからディスク順序付けという特別の機能を使用するため、サーバーの実行中にサーバーにアクセスしてエクスポートと同時に変更を行った場合、エラーが発生することがあります。読取り操作は実行可能です。

- entryIdOrder: このオプションにより、Oracle Berkeley DB Java Edition (JE)バックエンドから、データベース・レベルで論理的に格納されている順序でデータを読み取ることができます。
このオプションの利点は、次のとおりです:

- データベースがデータベース・キャッシュに完全に適合する場合、このオプションはdiskOrderアルゴリズムと比べて高いパフォーマンスを提供します。

- データベース・キャッシュから一時的にメモリーが抽出されることはありません。

- サーバーの実行中にサーバーにアクセスしてエクスポートと同時に変更を行う場合でも、このアルゴリズムは実行可能です。

- auto: このオプションは、サーバー停止時にオフライン・モードでdiskOrderを自動的に選択し、サーバー実行時にオンライン・モードでentryIdOrderを自動的に選択します。

-I, --includeFilter filter

指定した検索フィルタによって識別されたエントリをエクスポートに含めます。このオプションを複数回使用して、複数のフィルタを指定できます。このオプションが指定された場合、フィルタに一致しないバックエンド内のエントリはすべてスキップされます。

-l, --ldifFile filename

指定したLDIFファイルにデータをエクスポートします。これは必須オプションです。

オンライン・エクスポートの場合、相対パスのルートは現在の作業ディレクトリではなく、インスタンス・ルートです。したがって、たとえば、この場合のexports/ldif.ldifのパスはinstance-root/exports/ldif.ldifになります。

-n, --backendID backendID

エクスポートされるデータのバックエンドIDを指定します。サーバーで使用可能なバックエンドを決定するには、list-backendsコマンドを使用します。これは必須オプションです。

-O, --excludeOperational

エクスポートにある操作属性を除外します。

--wrapColumn column

LDIFファイルに書き込む際に、長い行を折り返す列を指定します。値0は、データを折り返さないことを指定します。

A.3.5.4 タスク・バックエンド接続オプション

オンライン・エクスポートを実行するには、タスク・バックエンドにアクセスする必要があります。タスク・バックエンドへのアクセスは、管理コネクタを介してSSLによって指定されます。これらの接続オプションは、エクスポートをオンラインで実行するときに使用します。

-D, --bindDN bindDN

バインドDNを使用してディレクトリ・サーバーを認証します。このオプションは簡易認証の実行時に使用されます。SASL認証を使用する場合、このオプションは必要ありません。このオプションのデフォルト値はcn=Directory Managerです。

-h, --hostname hostname

指定されたホスト名またはIPアドレスのディレクトリ・サーバーに接続します。このオプションが指定されない場合は、localhostのデフォルトが使用されます。

-j, --bindPasswordFile filename

ディレクトリ・サーバーに対して認証を受ける際、指定したファイルにバインド・パスワードを使用します。

-K, --keyStorePath path

指定されたパスにクライアント・キーストア証明書を使用します。

-N, --certNickname nickname

指定された証明書をクライアント認証に使用します。

-o, --saslOption name=value

指定されたオプションをSASL認証に使用します。

-p, --port port

指定された管理ポートでディレクトリ・サーバーに接続します。このオプションが指定されない場合は、4444というデフォルトの管理ポートが使用されます。

-P, --trustStorePath path

指定されたパスにクライアント・トラスト・ストア証明書を使用します。このオプションは、--trustAllを使用している場合は必要ありません。ただし、本番環境で作業する場合はトラスト・ストアを使用する必要があります。

-u, --keyStorePasswordFile filename

クライアント・キーストアの証明書にアクセスするために、指定されたファイルでパスワードを使用します。このオプションは、--keyStorePathを使用する場合のみ必須です。

-U, --trustStorePasswordFile filename

クライアント・トラスト・ストアの証明書にアクセスするために、指定されたファイルでパスワードを使用します。このオプションは、--trustStorePathを使用していて、指定したトラスト・ストアがコンテンツへのアクセスにパスワードを必要とする場合のみ必須です(ほとんどのトラスト・ストアでは必要とされません)。

-X, --trustAll

ディレクトリ・サーバーによって提示されるすべてのサーバーSSL証明書を信頼します。このオプションは便宜的に、かつテストの目的で使用できますが、セキュリティ上の理由から、トラスト・ストアを使用してクライアントがサーバーの証明書を受け入れるかどうかを判別する必要があります。

A.3.5.5 タスク・スケジュール・オプション

これらのオプションは、エクスポートをスケジュール済タスクとして実行すると指定したときに使用します。

--completionNotify emailAddress

タスク終了時に通知される受信者の電子メール・アドレスを指定します。このオプションは、1つのコマンドで複数回指定できます。

--dependency taskId

このタスクが依存するタスクのIDを指定します。タスクのすべての依存性が実行を完了するまで、タスクの実行は開始しません。

--errorNotify emailAddress

このタスクの実行時にエラーが発生した場合に通知される受信者の電子メール・アドレスを指定します。このオプションは、1つのコマンドで複数回指定できます。

--failedDependencyAction action

依存タスクの1つが失敗した場合に、このタスクが実行する必要のあるアクションを指定します。この値として、PROCESS、CANCEL、またはDISABLEのいずれか1つが割り当てられている必要があります。値を指定しない場合、デフォルトのアクションはCANCELです。

--recurringTask schedulePattern

タスクは再帰的であり、crontab(5)互換の時間/日付パターンとして表記されるschedulePatternに従ってスケジュールされることを示します。

-t, --start startTime

ディレクトリ・サーバー・タスクとしてスケジュールされている際に、YYYYMMDDhhmmssのフォーマットで表記される操作の開始日付と時間を指定します。値0は、タスクを即時実行するようにスケジュールします。このオプションが指定された場合、操作は指定の時間に開始するようスケジュールされ、その直後にコマンドが終了します。

A.3.5.6 コマンド入力/出力オプション

--noPropertiesFile

デフォルトのコマンドライン・オプションの取得にプロパティ・ファイルが使用されていないことを示します。

--propertiesFilePath path

デフォルトのコマンドライン・オプションが含まれているプロパティ・ファイルへのパスを指定します。

A.3.5.7 一般オプション

-?, -H, --help

このコマンドに対するコマンドライン使用情報を表示し、エクスポートを試行しないで終了します。

-V, --version

ディレクトリ・サーバーのバージョン情報を表示して、このコマンドの実行を試みるかわりに終了します。

A.3.5.8 例

次の例は、ディレクトリ・サーバー・コマンドの使用方法を示しています。

例A-83 オフライン・エクスポートの実行

次のコマンドでは、-bオプションにより指定されたベースDNから開始して、userRootバックエンドをエクスポートします。このコマンドは、-lにより指定されたLDIFファイルにデータをエクスポートします。オフライン・エクスポートの実行前にディレクトリ・サーバーを停止する必要があります。

$ stop-ds
$ export-ldif -b dc=example,dc=com -n userRoot -l /usr/tmp/export.ldif
[17/Oct/2008:12:24:33 +0200] category=JEB severity=NOTICE msgID=8847447
msg=Exported 102 entries and skipped 0 in 0 seconds (average rate 159.4/sec)

例A-84 オンライン・エクスポートの実行

タスク・バックエンド接続オプションのいずれかを指定した場合、エクスポートは自動的にオンライン・モードで実行します。オンライン・エクスポートはSSL上でサーバーに接続するため、SSLサーバー証明書の信頼方法を指定する必要があります。この例では、-Xオプションを使用してすべての証明書を信頼しています。

$ export-ldif -h localhost -p 4444 -D "cn=Directory Manager" -j /path/pwd-file -X \
--includeBranch "dc=example,dc=com" --backendID userRoot \
--ldifFile /usr/tmp/export.ldif

例A-85 エクスポートのスケジュール

エクスポートを後日実行するようにスケジュールするには、-tオプションまたは--startオプションを使用して開始時間を指定します。通常のオンライン・エクスポートと同様、スケジュールされたエクスポートは実行中のディレクトリ・サーバーのタスク・バックエンドに接続するため、関連するタスク・バックエンド接続オプションを指定する必要があります。

この例では、userRootバックエンドのエクスポートを12月24日に開始するようにスケジュールします。

$ export-ldif -h localhost -p 4444 -D "cn=Directory Manager" -j /path/pwd-file -X \
--includeBranch "dc=example,dc=com" --backendID userRoot \
--ldifFile /usr/tmp/export.ldif --start 20081224121500
Export task 2008101712361910 scheduled to start Dec 24, 2008 12:15:00 PM SAST

スケジュール済タスクを表示するには、manage-tasksコマンドを使用します。詳細は、第14.4項「タスクとしてのコマンドの構成」を参照してください。

A.3.5.9 終了コード

- オフライン・モード 。終了コード0は、操作が正常に終了したことを示します。ゼロ以外の終了コードは、処理中にエラーが発生したことを示します。

- オンライン・モード。-tまたは--startが指定された場合、終了コード0はタスクが正常に作成されたことを示します。ゼロ以外の終了コードは、タスク作成時にエラーが発生したことを示します。-tまたは--startが指定されていない場合、終了コードはオフライン・モードに指定された終了コードと同じです。

A.3.5.10 プロパティ・ファイルの使用方法

ディレクトリ・サーバーでは、export-ldifコマンドとともに使用されるデフォルトのオプション値を渡すプロパティ・ファイルの使用をサポートしています。プロパティ・ファイルは、様々な構成環境、特にスクリプト済アプリケーションまたは埋込みアプリケーションで作業する場合に便利です。詳細は、第A.1.2項「サーバー・コマンドによるプロパティ・ファイルの使用方法」を参照してください。

A.3.5.11 場所

- UNIXおよびLinux: INSTANCE_DIR/OUD/bin/export-ldif

- Windows: INSTANCE_DIR\OUD\bat\export-ldif.bat

A.3.5.12 関連コマンド

- 第A.3.6項「import-ldif」

- 第A.3.7項「ldif-diff」

- 第A.3.8項「ldifmodify」

- 第A.3.9項「ldifsearch」

- 第A.2.8項「manage-tasks」

A.3.6 import-ldif

import-ldifコマンドは、Oracle Berkeley DB Java Edition (JE)バックエンドにLDIFファイルから読み取ったデータを移入します。

A.3.6.1 シノプシス

import-ldif options

A.3.6.2 説明

import-ldifコマンドは、Oracle Berkeley DB Java Edition (JE)バックエンドに、LDIFファイルから読み取ったデータまたは、MakeLDIFテンプレートに基づいて生成されたデータを移入します。通常、import-ldifを使用すると、ldapmodifyを使用してエントリを追加するよりも非常に速く処理できます。JEバックエンド全体への完全インポートのほうが、JEバックエンドのブランチへの部分インポートよりも高いパフォーマンスが得られます。

import-ldifコマンドにより、インポートを即時に実行するか、または指定された日付と時間でインポートを実行するようにスケジュールできます。詳細は、第14.4項「タスクとしてのコマンドの構成」を参照してください。

import-ldifコマンドは、オンラインまたはオフラインで実行できます。

- オンライン・モード。オンライン・モードでは、import-ldifは管理コネクタを介してSSL上で実行中のディレクトリ・サーバー・インスタンスに接続し、インポート・タスクを登録します。タスク・バックエンド接続オプションのいずれかを指定した場合、このコマンドは自動的にオンライン・モードで実行します。管理コネクタの詳細は、第14.3項「サーバーへの管理トラフィックの管理」を参照してください。

- オフライン・モード 。オフライン・モードでは、import-ldifはディレクトリ・サーバー・インスタンスを介さずに、データベースに直接アクセスします。オフライン・インポートを実行するには、ディレクトリ・サーバーを停止する必要があります。

A.3.6.3 オプション

import-ldifコマンドは、短いフォーム(例: -b baseDN)または同等の長いフォーム(例: --includeBranch baseDN)のいずれかのオプションを受け入れます。

-a, --append

インポートの開始前にバックエンドをクリアするのではなく、バックエンドにすでに存在するデータにインポートされたデータを追加します。

-A, --templateFile filename

MakeLDIFテンプレートへのパスを指定して、インポート・データを生成します。

-b, --includeBranch branchDN

インポートに含めるデータのブランチまたはサブツリーのベースDNを指定します。このオプションを複数回使用して、複数のベースDNを指定できます。このオプションが指定された場合、インポート・ソース内で指定されたベースDNの1つにないエントリ、またはそれより下のエントリはスキップされます。指定されたベースDNより上にある既存のエントリはすべて保持されます。

-B, --excludeBranch branchDN

インポートから除外するブランチまたはサブツリーのベースDNを指定します。このオプションを複数回使用して、複数のベースDNを指定できます。このオプションが指定された場合、インポート・ソース内でベースDNの1つにあるエントリ、またはそれより下のエントリはスキップされます。--excludeBranchオプションの使用は、--includeBranchオプションよりも優先されます。含まれるリストと除外されるリストの両方に表示されているDNにあるエントリ、またはそのDNより下にあるエントリはインポートから除外されます。この機能により、ブランチの一部のみのデータ(たとえば、ou=People,dc=example,dc=comより下のエントリを除くdc=example,dc=comより下のすべてのエントリ)を含めることができます。

-c, --isCompressed

LDIFインポート・ファイルが圧縮されていることを指定します。ファイルの圧縮には、export-ldifコマンドの--compressLDIFオプションにより使用される形式であるGZIP形式が使用されます。

--countRejects

インポート時に却下されたエントリ数を返します。却下されたエントリ数が0から255の場合は、その数が返されます。却下されたエントリ数が255より大きい場合は、値255が返されます。たとえば、--countRejectsオプションを指定してimport-ldifを実行し、却下されたエントリが16個であった場合は、値16が返されます。import-ldifを実行して却下されたエントリが300個であった場合は、値255が返されます。このオプションは、オンライン・インポートではサポートされていません。

-e, --excludeAttribute attribute

インポートから除外する属性の名前を指定します。このオプションを複数回使用して、複数の属性を指定できます。

-E, --excludeFilter filter

インポートから除外するエントリを識別するための検索フィルタを指定します。このオプションを複数回使用して、複数のフィルタを指定できます。このオプションが指定された場合、インポート・ソース内でフィルタに一致するエントリはすべてスキップされます。--excludeFilterオプションは、--includeFilterオプションよりも優先されます。エントリが含まれるフィルタと除外されるフィルタの両方でフィルタに一致する場合、そのエントリはインポート時にスキップされます。

-F, --clearBackend

--appendオプションを指定しないでインポートする際、指定したバックエンド内のすべてのベースDNに対する既存のエントリをすべて削除することを確認します。これは、バックエンドIDによって指定された複数のベースDNをインポートする場合のみ適用されます。このオプションは、ベースDNが1つだけであるバックエンドに適用されます。

-i, --includeAttribute attribute

インポートに含める属性を指定します。このオプションを複数回使用して、複数の属性を指定できます。このオプションが使用される場合、このセットにリストされていない属性は、インポートされるエントリから除外されます。

-I, --includeFilter filter

インポートに含めるエントリを識別するための検索フィルタを指定します。このオプションを複数回使用して、複数のフィルタを指定できます。このオプションが指定された場合、インポート・ソース内でフィルタの結果に一致しないエントリはすべてスキップされます。

-l, --ldifFile filename

指定されたパスに置かれているLDIFファイルを読み取ります。このオプションは、--templateFileと同時に使用しないでください。

オンライン・インポートの場合、相対パスのルートは現在の作業ディレクトリではなく、インスタンス・ルートです。したがって、たとえば、この場合のimports/ldif.ldifのパスはinstance-root/imports/ldif.ldifになります。

-n, --backendID backendID

データのインポート先であるバックエンドのIDを指定します。サーバーで使用可能なバックエンドを表示するには、list-backendsコマンドを使用します。

-O, --overwrite

指定したスキップ・ファイルまたは却下ファイルがすでに存在する場合は、それを上書きします。このオプションが指定されていない場合、スキップまたは却下されるエントリは、上書きされるのではなく、対応するファイルに追加されます。このオプションは、--rejectFileオプションまたは--skipFileオプションが指定されている場合のみ適用可能です。

-r, --replaceExisting

既存のデータをインポートからのコンテンツに置換します。このオプションが指定されない場合、既存のエントリは上書きされません。このオプションは、--appendオプションが指定されている場合のみ適用可能です。

-R, --rejectFile filename

指定されたファイルを使用して、インポート時に却下されたエントリをすべて保持します。エントリがデフォルトのスキーマに準拠していない場合、そのエントリは却下されます。エントリが却下された理由を示すコメントがエントリの前に入れられます。このオプションが指定されない場合、却下ファイルは書き込まれません。

-s, --randomSeed seed

MakeLDIFテンプレートからエントリを生成する際、乱数発生ジェネレータに対して指定されたシード番号を使用します。乱数発生ジェネレータに特定の値をシードしておくと、同じテンプレートと乱数シードで常に同じデータが生成されることが保証されます。

--skipDNValidation

LDIFインポートの後半部分で、親としての限定的なDN検証を行います。このオプションが指定された場合、重複するDNチェックは行われません。使用しているLDIFインポート・ファイルが正しいかどうか不確かな場合は、このオプションを使用しないでください。

--skipFile filename

指定されたファイルを使用して、インポート時にスキップされたエントリを識別します。エントリがインポート時に指定されたベースDN下に置けない場合、または--excludeBranch、--excludeAttribute、または--excludeFilterの各オプションが使用された場合、そのエントリはスキップされます。

-S, --skipSchemaValidation

エントリがインポートされているときに、そのエントリに対してスキーマ検証を実行しません。このオプションはインポートのパフォーマンス向上に効果的ですが、インポート・データが有効であることを確信できる場合のみ使用してください。

--threadCount count

LDIFファイルの読取りに使用するスレッドの数を指定します。このオプションが指定されない場合は、CPUごとに2つのスレッドのデフォルトが使用されます。

大容量のLDIFファイルをインポートしている場合は、このオプションを使用してスレッド数を増やすことができますが、パフォーマンスへの影響に確信が持てないかぎり、このオプションは使用しないでください。

--tmpDirectory directory

インポート時に作成された索引スクラッチ・ファイルに対して、指定したディレクトリを使用します。ディレクトリが指定されない場合は、デフォルトのINSTANCE_DIR/OUD/import-tmpが使用されます。

A.3.6.4 タスク・バックエンド接続オプション

オンライン・インポートを実行するには、タスク・バックエンドにアクセスする必要があります。タスク・バックエンドへのアクセスは、管理コネクタを介してSSLによって指定されます。これらの接続オプションは、インポートをオンラインで実行するときに使用します。

-D, --bindDN bindDN

バインドDNを使用してディレクトリ・サーバーを認証します。このオプションは簡易認証の実行時に使用されます。SASL認証を使用する場合、このオプションは必要ありません。このオプションのデフォルト値はcn=Directory Managerです。

-h, --hostname hostname

指定されたホスト名またはIPアドレスのディレクトリ・サーバーに接続します。このオプションが指定されない場合は、localhostのデフォルトが使用されます。

-j, --bindPasswordFile filename

ディレクトリ・サーバーに対して認証を受ける際、指定したファイルにバインド・パスワードを使用します。

-K, --keyStorePath path

指定されたパスにクライアント・キーストア証明書を使用します。

-N, --certNickname nickname

指定された証明書をクライアント認証に使用します。

-o, --saslOption name=value

指定されたオプションをSASL認証に使用します。

-p, --port port

指定された管理ポートでディレクトリ・サーバーに接続します。このオプションが指定されない場合は、6664というデフォルトの管理ポートが使用されます。

-P, --trustStorePath path

指定されたパスにクライアント・トラスト・ストア証明書を使用します。このオプションは、--trustAllを使用している場合は必要ありません。ただし、本番環境で作業する場合はトラスト・ストアを使用する必要があります。

-u, --keyStorePasswordFile filename

クライアント・キーストアの証明書にアクセスするために、指定されたファイルでパスワードを使用します。このオプションは、--keyStorePathを使用する場合のみ必須です。

-U, --trustStorePasswordFile filename

クライアント・トラスト・ストアの証明書にアクセスするために、指定されたファイルでパスワードを使用します。このオプションは、--trustStorePathを使用していて、指定したトラスト・ストアがコンテンツへのアクセスにパスワードを必要とする場合のみ必須です(ほとんどのトラスト・ストアでは必要とされません)。

-X, --trustAll

ディレクトリ・サーバーによって提示されるすべてのサーバーSSL証明書を信頼します。このオプションは便宜的に、かつテストの目的で使用できますが、セキュリティ上の理由から、トラスト・ストアを使用してクライアントがサーバーの証明書を受け入れるかどうかを判別する必要があります。

A.3.6.5 タスク・スケジュール・オプション

これらのオプションは、インポートをスケジュール済タスクとして実行すると指定したときに使用します。

--completionNotify emailAddress

タスク終了時に通知される受信者の電子メール・アドレスを指定します。このオプションは、1つのコマンドで複数回指定できます。

--dependency taskId

このタスクが依存するタスクのIDを指定します。タスクのすべての依存性が実行を完了するまで、タスクの実行は開始しません。

--errorNotify emailAddress

このタスクの実行時にエラーが発生した場合に通知される受信者の電子メール・アドレスを指定します。このオプションは、1つのコマンドで複数回指定できます。

--failedDependencyAction action

依存タスクの1つが失敗した場合に、このタスクが実行する必要のあるアクションを指定します。この値として、PROCESS、CANCEL、またはDISABLEのいずれか1つが割り当てられている必要があります。値を指定しない場合、デフォルトのアクションはCANCELです。

--recurringTask schedulePattern

タスクは再帰的であり、crontab(5)互換の時間/日付パターンとして表記されるschedulePatternに従ってスケジュールされることを示します。

-t, --start startTime

ディレクトリ・サーバー・タスクとしてスケジュールされている際に、YYYYMMDDhhmmssのフォーマットで表記される操作の開始日付と時間を指定します。値0は、タスクを即時実行するようにスケジュールします。このオプションが指定された場合、操作は指定の時間に開始するようスケジュールされ、その直後にコマンドが終了します。

A.3.6.6 コマンド入力/出力オプション

--noPropertiesFile

デフォルトのコマンドライン・オプションの取得にプロパティ・ファイルが使用されていないことを示します。

--propertiesFilePath path

デフォルトのコマンドライン・オプションが含まれているプロパティ・ファイルへのパスを指定します。

-Q, --quiet

最小モードで実行します。最小モードを使用すると、インポート・プロセス中に有意なエラーが発生しないかぎり、出力は生成されません。

-d, --debug

デバッグ・モード(冗長)を使用します。デバッグ・モードを使用すると、詳細メッセージまたはデバッグ・メッセージがすべて出力されます。

A.3.6.7 一般オプション

-?, -H, --help

このコマンドに対するコマンドライン使用情報を表示し、インポートを試行しないで終了します。

-V, --version

ディレクトリ・サーバーのバージョン情報を表示して、このコマンドの実行を試みるかわりに終了します。

A.3.6.8 例

次の例は、ディレクトリ・サーバー・コマンドの使用方法を示しています。

例A-86 オフライン・インポートの実行

この例では、LDIFファイルをuserRootバックエンドにインポートします。LDIFファイル・パスは、すべてのプラットフォームで絶対パスである必要があります。オフライン・インポートの実行前にディレクトリ・サーバーを停止する必要があります。

$ stop-ds
$ import-ldif -b dc=example,dc=com -n userRoot -l /usr/tmp/Example.ldif

例A-87 LDIFファイルの一部のオフライン・インポート

この例では、LDIFファイルの一部をuserRootバックエンドにインポートします。このインポートにはベースDN dc=example,dc=comが含まれますが、ブランチou=peopleは除外されます。既存のエントリが置換され(-r)、却下されたエントリに関する情報が/usr/tmp/rejects.ldifに書き込まれます。LDIFファイル・パスは、すべてのプラットフォームで絶対パスである必要があります。オフライン・インポートの実行前にディレクトリ・サーバーを停止する必要があります。

$ stop-ds
$ import-ldif -b dc=example,dc=com -B "ou=people,dc=example,dc=com" \
-l /usr/tmp/Example.ldif -n userRoot -r -R /usr/tmp/rejects.ldif

例A-88 MakeLDIFテンプレートからのデータのインポート

この例では、MakeLDIFテンプレートからのサンプル・データをuserRootバックエンドにインポートします。乱数シード(-s)によって、データの乱数度が決定します。オフライン・インポートの実行前にディレクトリ・サーバーを停止する必要があります。

$ stop-ds
$ import-ldif -n userRoot -A example.template -s 0

例A-89 ユーザー属性のみのインポート

この例では、LDIFファイルをuserRootバックエンドにインポートします。-i "*"によって指定されたユーザー属性のみがインポートされます。LDIFファイル・パスは、すべてのプラットフォームで絶対パスである必要があります。システムによっては、アスタリスクを引用符で囲むか("*")、使用しているシェルに適した文字を使用してアスタリスクをエスケープしなければならない場合があります。オフライン・インポートの実行前にディレクトリ・サーバーを停止する必要があります。

$ stop-ds
$ import-ldif -b dc=example,dc=com -n userRoot -l /usr/tmp/Example.ldif -i "*"

例A-90 ユーザー属性のみのインポートと属性の除外

この例では、LDIFファイルをuserRootバックエンドにインポートします。-i "*"によって指定されたユーザー属性はすべてインポートされますが、roomnumber属性は除外されます。LDIFファイル・パスは、すべてのプラットフォームで絶対パスである必要があります。システムによっては、アスタリスクを引用符で囲むか("*")、使用しているシェルに適した文字を使用してアスタリスクをエスケープしなければならない場合があります。オフライン・インポートの実行前にディレクトリ・サーバーを停止する必要があります。

$ stop-ds
$ import-ldif -b dc=example,dc=com -n userRoot -l /usr/tmp/Example.ldif \
-i "*" -e "roomnumber"

例A-91 操作属性のみのインポート

この例では、LDIFファイルをuserRootバックエンドにインポートします。-i "+"によって指定された操作属性のみがインポートされます。LDIFファイル・パスは、すべてのプラットフォームで絶対パスである必要があります。システムによっては、プラス記号を引用符で囲むか("+")、使用しているシェルに適した文字を使用してプラス記号をエスケープしなければならない場合があります。オフライン・インポートの実行前にディレクトリ・サーバーを停止する必要があります。

$ stop-ds
$ import-ldif -b dc=example,dc=com -n userRoot -l /usr/tmp/Example.ldif -i "+"

例A-92 選択されたユーザーと操作属性のインポート

この例では、LDIFファイルをuserRootバックエンドにインポートします。属性uid、cn、sn、dc、およびcreatorsnameのみがインポートされます。LDIFファイル・パスは、すべてのプラットフォームで絶対パスである必要があります。オフライン・インポートの実行前にディレクトリ・サーバーを停止する必要があります。

$ stop-ds
$ import-ldif -b dc=example,dc=com -n userRoot -l /var/tmp/Example.ldif \
-i "uid" -i "cn" -i "sn" -i "dc" -i "creatorsname"

例A-93 オンライン・インポートの実行

タスク・バックエンド接続オプションのいずれかを指定した場合、インポートは自動的にオンラインで実行します。オンライン・インポートはSSL上でサーバーに接続するため、SSLサーバー証明書の信頼方法を指定する必要があります。この例では、-Xオプションを使用してすべての証明書を信頼しています。

$ import-ldif -h localhost -p 6664 -D "cn=Directory Manager" -j /path/pwd-file \
-X -b dc=example,dc=com -n userRoot -l /usr/tmp/Example.ldif

例A-94 インポートのスケジュール

インポートを後日実行するようにスケジュールするには、-tオプションまたは--startオプションを使用して開始時間を指定します。通常のオンライン・インポートと同様、スケジュールされたインポートは実行中のディレクトリ・サーバーのタスク・バックエンドに接続するため、関連するタスク・バックエンド接続オプションを指定する必要があります。

この例では、userRootバックエンドへのインポートを12月24日に開始するようにスケジュールします。

$ import-ldif -h localhost -p 6664 -D "cn=Directory Manager" -j /path/pwd-file \
-X -b dc=example,dc=com -n userRoot -l /usr/tmp/Example.ldif \
--start 20081224121500
Import task 2008101712361910 scheduled to start Dec 24, 2008 12:15:00 PM SAST

スケジュール済タスクを表示するには、manage-tasksコマンドを使用します。詳細は、第14.4項「タスクとしてのコマンドの構成」を参照してください。

A.3.6.9 終了コード

- オフライン・モード 。終了コード0は、操作が正常に終了したことを示します。ゼロ以外の終了コードは、処理中にエラーが発生したことを示します。

- オンライン・モード。-tまたは--startが指定された場合、終了コード0はタスクが正常に作成されたことを示します。ゼロ以外の終了コードは、タスク作成時にエラーが発生したことを示します。-tまたは--startが指定されていない場合、終了コードはオフライン・モードに指定された終了コードと同じです。

A.3.6.10 プロパティ・ファイルの使用方法

ディレクトリ・サーバーでは、export-ldifコマンドとともに使用されるデフォルトのオプション値を渡すプロパティ・ファイルの使用をサポートしています。プロパティ・ファイルは、様々な構成環境、特にスクリプト済アプリケーションまたは埋込みアプリケーションで作業する場合に便利です。詳細は、第A.1.2項「サーバー・コマンドによるプロパティ・ファイルの使用方法」を参照してください。

A.3.6.11 場所

- UNIXおよびLinux: INSTANCE_DIR/OUD/bin/import-ldif

- Windows: INSTANCE_DIR\OUD\bat\import-ldif.bat

A.3.6.12 関連コマンド

- 第A.3.5項「export-ldif」

- 第A.3.7項「ldif-diff」

- 第A.3.8項「ldifmodify」

- 第A.3.9項「ldifsearch」

- 第A.2.8項「manage-tasks」

A.3.7 ldif-diff

ldif-diffコマンドは、2つのLDIFファイルの差異を特定します。

A.3.7.1 シノプシス

ldif-diff options

A.3.7.2 説明

ldif-diffコマンドは、2つのLDIFファイルの差異の特定に使用できます。結果の出力は、端末に表示するか、出力ファイルに保存できます。結果の出力には、必要に応じて変更を取り消す場合に必要な情報がすべて含まれています。変更操作では、addおよびdelete変更タイプのセットのみが使用され、replace変更タイプは使用されません。削除操作では、削除されたエントリのコンテンツがコメントのフォームで表示される変更に含まれます。

このコマンドは、小規模のデータ・セットで機能するように作成されています。これは、ソースとターゲットのデータ・セットが同時に、メモリーに完全に適合できる場合のみ適しています。使用可能なメモリーに適合できない大規模なデータ・セットでの使用を対象としていません。

注意:

ldif-diffコマンドは、大規模なファイルを対象としていません。一定のサイズ(Windowsシステムでは約600KB、UNIXシステムではこれよりも大きい)を超えるLDIFファイルに対してldif-diffコマンドを実行すると、次のようなメモリー・エラーが発生することがあります:

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space.

A.3.7.3 オプション

ldif-diffコマンドは、短いフォーム(例: -o outputFile)または同等の長いフォーム(例: --outputLDIF outputFile)いずれかのオプションを受け入れます。

-a, --ignoreAttrs file

差異を計算するときに無視する属性のリストが含まれているファイルを指定します。

--checkSchema

スキーマで定義された属性の構文を考慮して、値を比較します。指定したLDIFファイルがサーバー・スキーマに準拠している必要があります。

-e, --ignoreEntries file

差異を計算するときに無視するエントリ(DN)のリストが含まれているファイルを指定します。

-o, --outputLDIF outputLDIF

ソースとターゲットのLDIFファイル間の変更を記録する出力ファイルへのパスを指定します。これが指定されない場合、変更情報は標準出力に書き込まれます。

-O, --overwriteExisting

--outputLDIFオプションで指定された出力ファイルを上書きします。このオプションは、指定した出力ファイルがすでに存在している場合は、ファイルに追加するのではなく、ファイルを上書きするように指定します。このオプションは、--outputLDIFが使用されている場合のみ適用可能です。

-s, --sourceLDIF sourceLDIF

変更が適用されていない元のデータが含まれているソースLDIFファイルへのパスを指定します。このオプションは必須です。

-S, --singleValueChanges

単一値変更モードで実行します。このモードでは、各変更操作が属性値ごとに別個の変更に分解されます。たとえば、1回の変更で5つの値が属性に追加される場合、変更は、それぞれ1つの属性を追加する5つの別個の変更として出力に表示されます。

-t, --targetLDIF targetLDIF

ソースLDIFとの差異が含まれているターゲットLDIFファイルへのパスを指定します。このオプションは必須です。

-?, -H, --help

コマンド使用情報を表示し、追加処理を試行しないで終了します。

-V, --version

ディレクトリ・サーバーのバージョン情報を表示して、このコマンドの実行を試みるかわりに終了します。

A.3.7.4 例

次の例は、ldif-diffコマンドの使用方法を示しています。

例A-95 2つのLDIFファイルの比較と標準出力への差異の送信

次のコマンドでは、ソース・ファイル(-s)をターゲット・ファイル(-t)と比較して、差異を出力します。Windowsプラットフォームの場合は、ソース・ファイルのパス(たとえば、-s \temp\quentin.ldif)とターゲット・ファイルのパス(たとえば、-t \temp\quentin.ldif)を指定します:

$ ldif-diff -s /usr/local/quentin.ldif -t /usr/local/quentinr.ldif

dn: uid=qcubbins,ou=People,dc=example,dc=com
changetype: delete
# objectClass: person
# objectClass: organizationalPerson
# objectClass: top
# objectClass: inetOrgPerson
# cn: Quentin Cubbins
# sn: Cubbins
# uid: qcubbins
# userPassword: qcubbins
# givenName: Quentin
# description: This is Quentin's description.
# mail: qcubbins@example.com

dn: uid=qrcubbins,ou=People,dc=example,dc=com
changetype: add
objectClass: person
objectClass: organizationalPerson
objectClass: top
objectClass: inetOrgPerson
cn: Quentin R Cubbins
sn: Cubbins
uid: qrcubbins
userPassword: qrcubbins
givenName: Quentin
description: This is Quentin R's description.
mail: qrcubbins@example.com

例A-96 2つのLDIFファイルの比較とファイルへの差異の送信

次のコマンドでは、ソース・ファイル(-s)をターゲット・ファイル(-t)と比較して、出力をファイルに送信(-o)します。Windowsプラットフォームの場合は、ソース・ファイルのパス(たとえば、-s \temp\quentin.ldif)とターゲット・ファイルのパス(たとえば、-t \temp\quentin.ldif)を指定します:

$ ldif-diff -s /usr/local/quentin.ldif -t /usr/local/quentinr.ldif \
-o output.ldif

A.3.7.5 終了コード

終了コード0は、操作が正常に終了したことを示します。1以上の終了コードは、処理中にエラーが発生したことを示します。

A.3.7.6 場所

- UNIXおよびLinux: INSTANCE_DIR/OUD/bin/ldif-diff

- Windows: INSTANCE_DIR\OUD\bat\ldif-diff.bat

A.3.7.7 関連コマンド

- 第A.3.9項「ldifsearch」

- 第A.3.8項「ldifmodify」

- 第A.3.11項「make-ldif」

A.3.8 ldifmodify

ldifmodifyコマンドは、LDIFファイルのコンテンツを変更します。

A.3.8.1 シノプシス

ldifmodify options

A.3.8.2 説明

ldifmodifyコマンドは、LDIFファイルのコンテンツの変更に使用できます。ldapmodifyコマンドと類似していますが、ldifmodifyコマンドはディレクトリ・サーバーに接続せず、LDIFファイルでローカルに操作します。また、標準出力での変更情報の受入れも行いません。このコマンドは、1つのファイルからすべての変更を読み取る必要があります。

メモリー容量が限定されている状態で非常に大きいLDIFファイルでの操作を可能にするために、変更可能なタイプに対して次の制約が課せられます:

- DNの変更は行いません。DN変更の操作はサポートされていません。追加、削除、変更の操作のみが実行できます。

- 変更または削除操作の並行処理はできません。追加されるエントリの処理中に、そのエントリを変更または削除することはできません。

A.3.8.3 オプション

すべてのオプション(--helpおよび--versionを除く)が必須です。ldifmodifyコマンドは、短いフォーム(例: -m changeFile)または同等の長いフォーム(例: --changesLDIF changeFile)のいずれかのオプションを受け入れます。

-m, --changesLDIF changeFile

適用する変更が含まれているファイルへのパスを指定します。このファイルのコンテンツはLDIF変更形式である必要があります。

-s, --sourceLDIF sourceFile

更新されるデータが含まれているソースLDIFファイルへのパスを指定します。

-t, --targetLDIF targetFile

指定された変更がすべて適用済のソースLDIFのデータで構成されるターゲットLDIFファイルへのパスを指定します。

-?, -H, --help

コマンド使用情報を表示し、追加処理を試行しないで終了します。

-V, --version

ディレクトリ・サーバーのバージョン情報を表示して、このコマンドの実行を試みるかわりに終了します。

A.3.8.4 例

次の例は、ldifmodifyコマンドの使用方法を示しています。

例A-97 LDIFファイルの変更

ソース・ファイルが次のようであるとします:

dn: uid=qcubbins,ou=People,dc=example,dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
uid: qcubbins
givenName: Quentin
sn: Cubbins
cn: Quentin Cubbins
mail: qcubbins@example.com
userPassword: qcubbins
description: This is Quentin's description.

また、更新(変更)ファイルが次のようであるとします:

## Add new telephone number for Quentin Cubbins
dn: uid=qcubbins,ou=People,dc=example,dc=com
changetype: modify
add: telephoneNumber
telephoneNumber: 512-401-1241

次のコマンドでは、変更ファイル(-m)にリストした変更が含まれているソース・ファイル(-s)を更新して、ターゲット・ファイル(-t)に出力します。Windowsプラットフォームの場合は、変更ファイルのファイル・パス(たとえば、-m \temp\update.ldif)、ソース・ファイルのファイル・パス(たとえば、-s \temp\quentin.ldif)、およびターゲット・ファイルのファイル・パス(たとえば、-s \temp\quentin_updated.ldif)を使用します:

$ ldifmodify -m /usr/local/update.ldif -s /usr/local/quentin.ldif \
-t /usr/local/quentin_updated.ldif

更新されたファイルは、次のようになります:

dn: uid=qcubbins,ou=People,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: person
objectClass: top
objectClass: organizationalPerson
sn: Cubbins
userPassword: qcubbins
description: This is Quentin's description.
cn: Quentin Cubbins
telephoneNumber: 512-401-1241
givenName: Quentin
uid: qcubbins
mail: qcubbins@example.com

A.3.8.5 終了コード

終了コード0は、操作が正常に終了したことを示します。1以上の終了コードは、処理中にエラーが発生したことを示します。

A.3.8.6 場所

- UNIXおよびLinux: INSTANCE_DIR/OUD/bin/ldifmodify

- Windows: INSTANCE_DIR\OUD\bat\ldifmodify.bat

A.3.8.7 関連コマンド

- 第A.3.9項「ldifsearch」

- 第A.3.7項「ldif-diff」

- 第A.3.11項「make-ldif」

A.3.9 ldifsearch

ldifsearchコマンドは、LDIFファイルの中で検索を実行します。

A.3.9.1 シノプシス

ldifsearch [options]

A.3.9.2 説明

ldifsearchコマンドは、LDIFファイル内での検索の実行に使用できます。ldapsearchコマンドと類似していますが、ldifsearchコマンドはディレクトリ・サーバーとのLDAP通信を実行せず、LDIFファイルでローカルに操作します。

A.3.9.3 オプション

ldifsearchコマンドは、短いフォーム(例: -b baseDN)または同等の長いフォーム(例: --baseDN baseDN)のいずれかのオプションを受け入れます。

-b, -baseDN baseDN

検索操作に使用するbase DNを指定します。このオプションを複数回使用することによって、複数のベースDNを指定できます。複数の値が指定された場合は、エントリが検索ベースの範囲内にあるかどうかが調べられます。検索ベースが指定されていない場合、LDIFファイルに含まれているエントリはいずれも検索範囲内であると見なされます。

-f, --filterFile filterFile

検索操作を処理する際に使用する1つ以上のフィルタが含まれているファイルへのパスを指定します。複数のフィルタが存在する場合は、1行に1つのフィルタが表示されるようにファイルを構成する必要があります。このオプションを使用する場合、後続オプションはすべて別個の属性として処理されます。そうでない場合は、最初の後続オプションを検索フィルタにする必要があります。

-l, -ldifFile ldifFile

検索されるデータが含まれているLDIFファイルへのパスを指定します。このオプションを複数回指定することによって、複数のLDIFファイルを指定できます。このオプションは必須です。

-o, -outputFile outputFile

指定された検索基準に一致するエントリが含まれている出力ファイルへのパスを指定します。このオプションが指定されない場合、一致するエントリは標準出力に書き込まれます。

-O, --overwriteExisting

--outputFileオプションで指定された出力ファイルを上書きします。このオプションは、指定した出力ファイルがすでに存在している場合は、データを既存のデータに追加するのではなく、ファイルを上書きするように指定します。これは、--outputFileオプションが使用されている場合のみ適用可能です。

-s, -searchScope searchScope

検索操作の範囲を指定します。次のいずれかの値を指定する必要があります:

- base: --baseDNオプションによって指定されたエントリのみを調べます。

- one: --baseDNオプションによって指定されたエントリとその直接の子のみを調べます。

- subまたはsubordinate: --baseDNオプションによって指定されたエントリとそのサブツリーを調べます。

このオプションが指定されない場合、デフォルト値はsubです。

-t, --timeLimit numSeconds

検索の実行に費やす最長時間(秒)を指定します。この時間の経過後に検索が終了します。

-z, --sizeLimit sizeLimit

ディレクトリ・サーバーがクライアントに返す一致エントリの最大数を設定します。これが指定されていない場合、クライアントが要求する最大数は存在しません。ディレクトリ・サーバーでは、クライアントにより要求されるサイズ限度よりも低い限度を施行することができます。

-T, --dontWrap

一致エントリを表示するときに、長い行の折り返しを行いません。このオプションが指定されない場合、長い行は80列の端末に収まるように(LDIF仕様と適合する方法で)折り返されます。

-?, -H, --help

コマンド使用情報を表示し、追加処理を試行しないで終了します。

-V, --version

ディレクトリ・サーバーのバージョン情報を表示します。

A.3.9.4 例

次の例は、ldifsearchコマンドの使用方法を示しています。

例A-98 LDIFファイルの検索

次のコマンドでは、ベースDN(-b)を指定し、エントリに関してLDIFファイル(-l)を検索し、検索フィルタcn=Sam Carterに一致するエントリが存在する場合は、その結果を画面に返します。Windowsプラットフォームの場合は、LDIFファイルが常駐しているパス(たとえば、-l \temp\Example.ldif)を使用します。

$ ldifsearch -b dc=example,dc=com -l /usr/local/Example.ldif "(cn=Sam Carter)"

dn: uid=scarter,ou=People,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: person
objectClass: top
objectClass: organizationalPerson
ou: Accounting
ou: People
sn: Carter
facsimiletelephonenumber: +1 408 555 9751
roomnumber: 4600
userpassword: sprain
l: Sunnyvale
cn: Sam Carter
telephonenumber: +1 408 555 4798
uid: scarter
givenname: Sam
mail: scarter@example.com

例A-99 フィルタ・ファイルを使用したLDIFファイルの検索

ファイルfilter.ldifに次の検索フィルタが含まれているとします:

(&(ou=Accounting)(l=Cupertino))

次のコマンドでは、検索フィルタ・ファイル内のフィルタに一致するエントリに関してLDIFファイルを検索し、その結果を出力ファイルに出力します。次のコマンドでは、ベースDN(-b)を指定し、検索フィルタ・ファイル(-f)を使用してLDIFファイル(-l)を検索し、その結果をファイル(-o)に出力します。Windowsプラットフォームの場合は、LDIFファイルのファイル・パス(たとえば、-l \temp\Example.ldif)、フィルタ・ファイルのファイル・パス(たとえば、-f \temp\filter.ldif)、および出力ファイルのファイル・パス(たとえば、-o \temp\results.ldif)を使用します:

$ ldifsearch -b dc=example,dc=com -l /usr/local/Example.ldif -f /usr/local/filter.ldif \
-o /home/local/results.ldif

A.3.9.5 終了コード

終了コード0は、操作が正常に終了したことを示します。1以上の終了コードは、処理中にエラーが発生したことを示します。

A.3.9.6 場所

- UNIXおよびLinux: INSTANCE_DIR/OUD/bin/ldifsearch

- Windows: INSTANCE_DIR\OUD\bat\ldifsearch.bat

A.3.9.7 関連コマンド

- 第A.3.8項「ldifmodify」

- 第A.3.7項「ldif-diff」

A.3.10 list-backends

list-backendsコマンドは、使用可能なバックエンドの情報を表示します。

A.3.10.1 シノプシス

list-backends [options]

A.3.10.2 説明

list-backendsコマンドは、ディレクトリ・サーバー・インスタンスで定義されたバックエンドに関する情報の取得に使用できます。バックエンドは、サーバー・データベースへのアクセス提供を実行します。

list-backendsコマンドには、次の3つの操作モードがあります:

- オプションなし。オプションを指定せずに起動した場合、サーバー内に構成されているすべてのバックエンドのバックエンドIDが、そのバックエンドのベースDNとともに表示されます。

- バックエンドIDを指定。--backendIDとともに使用する場合、バックエンドのすべてのベースDNが、指定されたバックエンドIDとともにリストされます。

- ベースDNを指定。--baseDNとともに使用する場合、指定されたDNを持つエントリの保持に使用するバックエンドのバックエンドIDがリストされ、さらに、DNがそのバックエンドに対して構成されたベースDNの1つであるかどうかが示されます。

A.3.10.3 オプション

次のオプションは使用できますが、必須ではありません。list-backendsコマンドは、短いフォーム(例: -b baseDN)または同等の長いフォーム(例: --baseDN baseDN)のいずれかのオプションを受け入れます。

A.3.10.4 コマンドのオプション

-b, --baseDN baseDN: list-backendsコマンドでバックエンドIDのリスト作成の際に使用するベースDNを指定します。また、このオプションは、指定したDNが当該バックエンドのベースDNであるかどうかも指定します。

-n, --backendID backendID: このコマンドが関連付けられたベースDNを表示する際に使用するバックエンドIDを指定します。このオプションを複数回使用して、複数のバックエンドに対するベースDNを表示できます。

A.3.10.5 一般オプション

-?, -H, --help: コマンド使用情報を表示し、その他のアクションを実行しないで即時に終了します。

-V, --version: ディレクトリ・サーバーのバージョン情報を表示して、このコマンドの実行を試みるかわりに終了します。

A.3.10.6 例

次の例は、list-backendsコマンドの使用方法を示しています。

例A-100 現在のバックエンドのリスト

次のコマンドは、ディレクトリ・サーバーにある現在のバックエンドをリストします:

$ list-backends

Backend ID  Base DN
----------  -----------------
backup      cn=backups
config      cn=config
monitor     cn=monitor
schema      cn=schema
tasks       cn=tasks
userRoot    dc=example,dc=com

例A-101 バックエンドIDのリスト

次のコマンドは、ディレクトリ・サーバーにあるバックエンドIDをリストします:

$ list-backends --backendID monitor

Backend ID  Base DN
----------  ----------
monitor     cn=monitor

例A-102 ベースDNのリスト

次のコマンドは、ディレクトリ・サーバーにあるベースDNをリストします:

$ list-backends --baseDN cn=backups

The provided DN 'cn=backups' is a base DN for the back end 'backup'

A.3.10.7 終了コード

終了コード0は、操作が正常に終了したことを示します。終了コード1は、処理中にエラーが発生したことを示します。

A.3.10.8 場所

- UNIXおよびLinux: INSTANCE_DIR/OUD/bin/list-backends

- Windows: INSTANCE_DIR\OUD\bat\list-backends.bat

A.3.11 make-ldif

make-ldifコマンドは、テンプレート・ファイルに基づいてLDIFデータを生成します。

A.3.11.1 シノプシス

make-ldif [options]

A.3.11.2 説明

make-ldifコマンドは、テンプレート・ファイルに基づいたLDIFデータの生成に使用できます。このコマンドにより、パフォーマンスおよびスケーラビリティのテストなど、アプリケーションでの使用に適した量の現実的なサンプル・データを構築したり、本番環境で確認された問題の再現を試行したりすることができます。

A.3.11.3 オプション

make-ldifコマンドは、短いフォーム(例: -o ldifFile)または同等の長いフォーム(例: --ldifFile ldifFile)のいずれかのオプションを受け入れます。

-o, --ldifFile ldifFile

生成済データの書き込み先であるLDIFファイルへのパスを指定します。これは必須オプションです。

-s, --randomSeed seed

乱数発生ジェネレータのシードに使用する整数値を指定します。乱数シードが指定されている場合、同じシードを持つ同じテンプレート・ファイルに基づいてデータを生成すると、常に同じLDIF出力が生成されます。シードが指定されない場合は、同じテンプレート・ファイルを使用するたびに、異なるLDIF出力が生成される可能性があります。

-t, --templateFile templateFile

生成されるデータを記述したテンプレート・ファイルへのパスを指定します。これは必須オプションです。テンプレート・ファイルへの絶対パスを指定する必要があります。

-?, -H, --help

このコマンドに対するコマンドライン使用情報を表示し、コマンドの実行を試みないで終了します。

-V, --version

ディレクトリ・サーバーのバージョン情報を表示します。

A.3.11.4 例

次の例は、make-ldifコマンドの使用方法を示しています。

例A-103 サンプルLDIFファイルの作成

次のコマンドでは、テンプレート(-t)を使用してLDIFファイルを作成し、出力ファイル(-o)に書き込んで、乱数シード(-s)を指定します。Windowsプラットフォームの場合は、出力LDIFファイルへのファイル・パス(たとえば、-o path\to\Example.ldif)およびテンプレート・ファイルへのファイル・パス(たとえば、-t INSTANCE_DIR\OUD\config\MakeLDIF\example.template)を入力します。

example.templateファイルはINSTANCE_DIR/OUD/config/MakeLDIFディレクトリに置かれています。

$ make-ldif -o /path/to/sample.ldif -s 0 \
-t INSTANCE_DIR/OUD/config/MakeLDIF/example.template

Processed 1000 entries
Processed 2000 entries
Processed 3000 entries
Processed 4000 entries
Processed 5000 entries
Processed 6000 entries
Processed 7000 entries
Processed 8000 entries
Processed 9000 entries
Processed 10000 entries
LDIF processing complete.  10003 entries written

例A-104 大きいサンプルLDIFファイルの作成

example.templateファイル(INSTANCE_DIR/OUD/config/MakeLDIFの下のインストール・ディレクトリに置かれています)には、make-ldifにより生成されるエントリ数を設定する変数が含まれています。この数値を変更して、テスト用に非常に大きいサンプルLDIFファイルを作成できます。

example.templateファイルを開いて、numusers変数を変更します。デフォルトでは、この変数は10001に設定されています。この例では、変数を1000001に設定します:

define suffix=dc=example,dc=com
define maildomain=example.com
define numusers=1000001
...

make-ldifコマンドを再実行します:

$ make-ldif -o /path/to/sample.ldif -s 0 \
-t INSTANCE_DIR/OUD/config/MakeLDIF/example.template
...
Processed 999000 entries
Processed 1000000 entries
LDIF processing complete.  1000003 entries written

A.3.11.5 終了コード

終了コード0は、操作が正常に終了したことを示します。終了コード1は、処理中にエラーが発生したことを示します。

A.3.11.6 場所

- UNIXおよびLinux: INSTANCE_DIR/OUD/bin/make-ldif

- Windows: INSTANCE_DIR\OUD\bat\make-ldif.bat

A.3.11.7 関連コマンド

- 第A.3.9項「ldifsearch」

- 第A.3.8項「ldifmodify」

- 第A.3.7項「ldif-diff」

A.3.12 manage-account

manage-accountコマンドは、主にパスワード・ポリシー状態の詳細に関連するユーザー・アカウント情報を管理します。

A.3.12.1 シノプシス

manage-account subcommands options

A.3.12.2 説明

manage-accountコマンドは、主にパスワード・ポリシー状態の詳細に関連するユーザー・アカウント情報を管理します。このコマンドはパスワード・ポリシー状態拡張操作と相互作用して、ユーザーのアカウント、ログイン、およびパスワード情報を返します。パスワード・ポリシー状態拡張操作では1回使用するたびに複数の操作を実行できますが、manage-accountコマンドで一度に実行できるのは1つの操作だけです。ユーザーは、パスワード・ポリシー状態拡張操作を使用するためにpassword-reset権限を持っている必要があります。

すべての時間値は汎用の時間形式で返されます。すべての期間値は秒単位で返されます。

manage-accountコマンドは、管理コネクタを介してSSL上のサーバーに接続します(第14.3項「サーバーへの管理トラフィックの管理」で説明しています)。

A.3.12.3 サブコマンド

clear-account-is-disabled

ユーザー・アカウントの無効な状態をクリアします。これは、アカウントが無効になっている場合に、そのアカウントを有効化する効果をもたらします。

get-account-expiration-time

アカウントの有効期限を返します。

get-account-is-disabled

ユーザー・アカウントの無効な状態を返します。

get-all

ユーザー・アカウントのパスワード・ポリシー状態の情報をすべて返します。

get-authentication-failure-times

ユーザー・アカウントの認証失敗の時刻を返します。

get-grace-login-use-times

ユーザー・アカウントの猶予ログインの使用時刻を返します。

get-last-login-time

ユーザー・アカウントの最終ログイン時刻を返します。

get-password-changed-by-required-time

ユーザーの必要時刻によって変更されたパスワードを返します。

get-password-changed-time

パスワードが最後に変更された時刻を返します。

get-password-expiration-warned-time

今後のパスワード有効期限についてユーザーが最初に警告された時刻を返します。

get-password-history

ユーザー・アカウントのパスワード履歴を返します。

get-password-is-reset

ユーザーのパスワード・リセット状態を返して、次回のログインでユーザーがパスワードの変更を強制されるかどうかを示します。

get-password-policy-dn

指定されたユーザーのパスワード・ポリシーのDNを返します。

get-remaining-authentication-failure-count

ユーザーのアカウントがロックされる前に、ユーザーの残りの認証失敗数を返します。

get-remaining-grace-login-count

ユーザーの残りの猶予ログイン数を返します。

get-seconds-until-account-expiration

アカウントが期限切れになるまでの時間の長さを返します。

get-seconds-until-authentication-failure-unlock

ユーザーのアカウントが自動的にロック解除されるまでの時間の長さを返します。

get-seconds-until-idle-lockout

アカウントがアイドル・ロックされるまでの時間の長さを返します。

get-seconds-until-password-expiration

パスワードが期限切れになるまでの時間の長さを返します。

get-seconds-until-password-expiration-warning

今後のパスワード有効期限についてユーザーが最初に警告されるまでの時間の長さを返します。

get-seconds-until-password-reset-lockout

パスワード・リセット・ロックアウトが発生するまでの時間の長さを返します。

get-seconds-until-required-change-time

必須の変更時間によりユーザーがパスワード変更を要求されるまでの時間の長さを返します。

set-account-is-disabled

アカウントを無効にします。必要なサブオプションは、次のとおりです:

--operationValue true/false。TRUEに設定した場合、ユーザーを無効にします。FALSEに設定した場合、ユーザーを有効にします。

A.3.12.4 オプション

manage-accountコマンドは、短いフォーム(例: -b targetDN)または同等の長いフォーム(例: --targetDN targetDN)のいずれかのオプションを受け入れます。

-b, --targetDN targetDN

パスワード・ポリシー状態情報の取得と設定の対象となるユーザー・エントリのDNを指定します。

A.3.12.5 LDAP接続オプション

manage-accountコマンドは、管理コネクタを介してSSL上のディレクトリ・サーバーに接続します。これらの接続オプションは、ディレクトリ・サーバーとの接続に使用します。

-D, --bindDN bindDN

バインドDNを使用してディレクトリ・サーバーを認証します。このオプションは簡易認証の実行時に使用されます。SASL認証を使用する場合、このオプションは必要ありません。このオプションのデフォルト値はcn=Directory Managerです。

-h, --hostname hostname

指定されたホスト名またはIPアドレスのディレクトリ・サーバーに接続します。このオプションが指定されない場合は、localhostのデフォルトが使用されます。

-j, --bindPasswordFile filename

ディレクトリ・サーバーに対して認証を受ける際、指定したファイルにバインド・パスワードを使用します。

-K, --keyStorePath path

指定されたパスにクライアント・キーストア証明書を使用します。

-N, --certNickname nickname

指定された証明書をクライアント認証に使用します。

-o, --saslOption name=value

指定されたオプションをSASL認証に使用します。

-p, --port port

指定された管理ポートでディレクトリ・サーバーに接続します。このオプションが指定されない場合は、4444というデフォルトの管理ポートが使用されます。

-P, --trustStorePath path

指定されたパスにクライアント・トラスト・ストア証明書を使用します。このオプションは、--trustAllを使用している場合は必要ありません。ただし、本番環境で作業する場合はトラスト・ストアを使用する必要があります。

-u, --keyStorePasswordFile filename

クライアント・キーストアの証明書にアクセスするために、指定されたファイルでパスワードを使用します。このオプションは、--keyStorePathを使用する場合のみ必須です。

-U, --trustStorePasswordFile filename

クライアント・トラスト・ストアの証明書にアクセスするために、指定されたファイルでパスワードを使用します。このオプションは、--trustStorePathを使用していて、指定したトラスト・ストアがコンテンツへのアクセスにパスワードを必要とする場合のみ必須です(ほとんどのトラスト・ストアでは必要とされません)。

-X, --trustAll

ディレクトリ・サーバーによって提示されるすべてのサーバーSSL証明書を信頼します。このオプションは便宜的に、かつテストの目的で使用できますが、セキュリティ上の理由から、トラスト・ストアを使用してクライアントがサーバーの証明書を受け入れるかどうかを判別する必要があります。

A.3.12.6 一般オプション

-?, -H, --help

このコマンドに対するコマンドライン使用情報を表示し、コマンドの実行を試みないで終了します。

-V, --version

ディレクトリ・サーバーのバージョン情報を表示します。

A.3.12.7 例

次の例は、ディレクトリ・サーバー・コマンドの使用方法を示しています。

例A-105 ユーザーのすべてのパスワード・ポリシー状態情報の表示

次のコマンドは、ユーザーのパスワード・ポリシー状態情報を返します:

$ manage-account get-all -h localhost -p 4444 -D "cn=Directory Manager" \
-j /path/pwd-file -X -b "uid=scarter,ou=People,dc=example,dc=com" \

Password Policy DN:  cn=Default Password Policy,cn=Password Policies,cn=config
Account Is Disabled:  false
Account Expiration Time:
Seconds Until Account Expiration:
Password Changed Time:  19700101000000.000Z
Password Expiration Warned Time:
Seconds Until Password Expiration:
Seconds Until Password Expiration Warning:
Authentication Failure Times:
Seconds Until Authentication Failure Unlock:
Remaining Authentication Failure Count:
Last Login Time:
Seconds Until Idle Account Lockout:
Password Is Reset:  false
Seconds Until Password Reset Lockout:
Grace Login Use Times:
Remaining Grace Login Count:  0
Password Changed by Required Time:
Seconds Until Required Change Time:

例A-106 ユーザー・アカウントの無効化

次のコマンドにより、ユーザーのアカウントuid=scarterが無効になります:

$ manage-account set-account-is-disabled --operationValue true \
-h localhost -p 4444 -D "cn=Directory Manager" -j /path/pwd-file -X \
-b "uid=scarter,ou=People,dc=example,dc=com"

Account Is Disabled:  true

例A-107 ユーザー・アカウントの有効化

次のコマンドにより、ユーザーの無効化されたアカウントが再度有効になります:

$ manage-account clear-account-is-disabled \
-h localhost -p 4444 -D "cn=Directory Manager" -j /path/pwd-file -X \
-b "uid=scarter,ou=People,dc=example,dc=com"

Account Is Disabled:  false

A.3.12.8 終了コード

終了コード0は、操作が正常に終了したことを示します。ゼロ以外の終了コードは、処理中にエラーが発生したことを示します。

A.3.12.9 場所

- UNIXおよびLinux: INSTANCE_DIR/OUD/bin/manage-account

- Windows: INSTANCE_DIR\OUD\bat\manage-account.bat

A.3.12.10 関連コマンド

第A.3.16項「verify-index」

A.3.13 rebuild-index

rebuild-indexコマンドは、ディレクトリ・サーバーの索引を再作成します。

A.3.13.1 シノプシス

rebuild-index options

A.3.13.2 説明

rebuild-indexコマンドは、ディレクトリ・サーバーの索引の再作成に使用します。索引は値のリストが含まれているファイルであり、ここでは、それぞれの値がディレクトリ・サーバー・データベース内で接尾辞に対するエントリ識別子のリストに関連付けられています。ディレクトリ・サーバーで検索リクエストを処理する場合、索引内のエントリ識別子のリストを使用してデータベースを検索するため、検索の高速化が図れます。索引が存在しない場合、ディレクトリ・サーバーはデータベース内の各エントリを調べる必要があるため、パフォーマンスが著しく低下します。

rebuild-indexコマンドは次の場合に効果的です:

- 索引のindex-entry-limitプロパティを変更する場合

- 索引を新規に作成する場合

rebuild-indexコマンドは、サーバーをオンラインにして実行できます。ただし、rebuild-indexの実行中はバックエンド・データベースは使用できません。また、rebuild-indexコマンドは通常、サーバーがオフラインになっていて、特に--rebuildAllオプションが指定されている場合に実行速度が上がります。

注意:

時間がたつにつれて、エントリ識別子リストの整然さが失われていきます。このようになると、rebuild-indexコマンドのパフォーマンスは徐々に低下していきます。

大規模なデータベースの索引付けの再実行は、できるだけ避けるようにしてください。あるいは、rebuild-indexコマンドのパフォーマンスが著しく劣化した場合は、データベースを再インポートして、新しい、整然としたエントリ識別子リストで開始してください。

A.3.13.3 オプション

rebuild-indexコマンドは、短いフォーム(例: -b baseDN)または同等の長いフォーム(例: --baseDN baseDN)のいずれかのオプションを受け入れます。

A.3.13.4 コマンドのオプション

-b, --baseDN baseDN

索引付けをサポートしているバックエンドのベースDNを指定します。再作成操作は、指定されたベースDNの範囲内にある索引に対して実行されます。

-i, --index index

再作成する索引の名前を指定します。属性索引の場合、これは属性名になります。再作成する索引を少なくとも1つ指定する必要があります。

--rebuildAll

ベースDNにより指定されたバックエンド内にあるすべての索引を再作成します。このオプションでは、すべての属性索引の索引付けが再実行されるだけでなく、dn2idシステム索引、拡張索引とVLV索引、およびdn2uri索引も再作成されます。rebuildAllオプションは-iオプションと同時に使用できません。

--tmpDirectory

スクラッチ索引ファイル用に一時作業ディレクトリの場所を指定します。デフォルトの一時作業ディレクトリはINSTANCE_DIR/OUD/import-tmpです。

A.3.13.5 タスク・バックエンド接続オプション

索引をオンラインで再作成するには、タスク・バックエンドにアクセスする必要があります。タスク・バックエンドへのアクセスは、管理コネクタを介してSSLによって指定されます。これらの接続オプションは、再作成をオンラインで実行するときに使用します。

-D, --bindDN bindDN

バインドDNを使用してディレクトリ・サーバーを認証します。このオプションは簡易認証の実行時に使用されます。SASL認証を使用する場合、このオプションは必要ありません。このオプションのデフォルト値はcn=Directory Managerです。

-h, --hostname hostname

指定されたホスト名またはIPアドレスのディレクトリ・サーバーに接続します。このオプションが指定されない場合は、localhostのデフォルトが使用されます。

-j, --bindPasswordFile filename

ディレクトリ・サーバーに対して認証を受ける際、指定したファイルにバインド・パスワードを使用します。

-K, --keyStorePath path

指定されたパスにクライアント・キーストア証明書を使用します。

-N, --certNickname nickname

指定された証明書をクライアント認証に使用します。

-o, --saslOption name=value

指定されたオプションをSASL認証に使用します。

-p, --port port

指定された管理ポートでディレクトリ・サーバーに接続します。このオプションが指定されない場合は、4444というデフォルトの管理ポートが使用されます。

-P, --trustStorePath path

指定されたパスにクライアント・トラスト・ストア証明書を使用します。このオプションは、--trustAllを使用している場合は必要ありません。ただし、本番環境で作業する場合はトラスト・ストアを使用する必要があります。

-u, --keyStorePasswordFile filename

クライアント・キーストアの証明書にアクセスするために、指定されたファイルでパスワードを使用します。このオプションは、--keyStorePathを使用する場合のみ必須です。

-U, --trustStorePasswordFile filename

クライアント・トラスト・ストアの証明書にアクセスするために、指定されたファイルでパスワードを使用します。このオプションは、--trustStorePathを使用していて、指定したトラスト・ストアがコンテンツへのアクセスにパスワードを必要とする場合のみ必須です(ほとんどのトラスト・ストアでは必要とされません)。

-X, --trustAll

ディレクトリ・サーバーによって提示されるすべてのサーバーSSL証明書を信頼します。このオプションは便宜的に、かつテストの目的で使用できますが、セキュリティ上の理由から、トラスト・ストアを使用してクライアントがサーバーの証明書を受け入れるかどうかを判別する必要があります。

A.3.13.6 タスク・スケジュール・オプション

これらのオプションは、索引の再作成をスケジュール済タスクとして実行すると指定したときに使用します。

--completionNotify emailAddress

タスク終了時に通知される受信者の電子メール・アドレスを指定します。このオプションは、1つのコマンドで複数回指定できます。

--dependency taskId

このタスクが依存するタスクのIDを指定します。タスクのすべての依存性が実行を完了するまで、タスクの実行は開始しません。

--errorNotify emailAddress

このタスクの実行時にエラーが発生した場合に通知される受信者の電子メール・アドレスを指定します。このオプションは、1つのコマンドで複数回指定できます。

--failedDependencyAction action

依存タスクの1つが失敗した場合に、このタスクが実行する必要のあるアクションを指定します。この値として、PROCESS、CANCEL、またはDISABLEのいずれか1つが割り当てられている必要があります。値を指定しない場合、デフォルトのアクションはCANCELです。

--recurringTask schedulePattern

タスクは再帰的であり、crontab(5)互換の時間/日付パターンとして表記されるschedulePatternに従ってスケジュールされることを示します。

-t, --start startTime

ディレクトリ・サーバー・タスクとしてスケジュールされている際に、YYYYMMDDhhmmssのフォーマットで表記される操作の開始日付と時間を指定します。値0は、タスクを即時実行するようにスケジュールします。このオプションが指定された場合、操作は指定の時間に開始するようスケジュールされ、その直後にコマンドが終了します。

A.3.13.7 ユーティリティ入力/出力オプション

--propertiesFilePath propertiesFilePath

コマンドラインに使用されるデフォルトのプロパティ値が含まれているファイルへのパス。

--noPropertiesFile

デフォルトのコマンドライン引数値を取得する際に、プロパティ・ファイルを使用しません。

-v, --verbose

冗長モードを使用します。

A.3.13.8 一般オプション

-?, -H, --help

このコマンドに対するコマンドライン使用情報を表示し、ディレクトリ・サーバーの停止または再起動を試行しないで終了します。

-V, --version

ディレクトリ・サーバーのバージョン情報を表示して、このコマンドの実行を試みるかわりに終了します。

A.3.13.9 例

次の例は、rebuild-indexコマンドの使用方法を示しています。

例A-108 索引の再作成

まず、次のようにdsconfigコマンドを使用して索引リストを表示します:

$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j /path/pwd-file -X \
-n list-local-db-indexes --element-name userRoot

Local DB Index    : Type    : index-type
------------------:---------:--------------------
aci               : generic : presence
cn                : generic : equality, substring
displayName       : generic : equality, substring
ds-sync-conflict  : generic : equality
ds-sync-hist      : generic : ordering
entryUUID         : generic : equality
givenName         : generic : equality, substring
mail              : generic : equality, substring
member            : generic : equality
objectClass       : generic : equality
orclMTTenantGuid  : generic : equality
orclMTTenantUName : generic : equality, substring
orclMTUid         : generic : equality
sn                : generic : equality, substring
telephoneNumber   : generic : equality, substring
uid               : generic : equality
uniqueMember      : generic : equality

次のコマンドでは、ベースDN(-b)を指定して索引(-i)を再作成します。

このコマンドはオフラインで実行するため、コマンドを実行する前にディレクトリ・サーバーを停止する必要があります。

$ rebuild-index -b dc=example,dc=com -i uid -i mail
[15/Dec/2011:15:28:01 +0100] category=JEB severity=NOTICE msgID=8847497
msg=Rebuild of index(es) uid started with 202 total entries to process
...
[15/Dec/2011:15:28:02 +0100] category=JEB severity=NOTICE msgID=8847493
msg=Rebuild complete. Processed 202 entries in 1 seconds (average rate 135.2/sec)

例A-109 すべての索引の再作成

この例では、--rebuildAllオプションを使用してすべての索引を再作成します。

$ rebuild-index -b "dc=example,dc=com" --rebuildAll

例A-110 拡張索引の再作成

拡張索引は、次の3つのいずれの方法でも再作成できます:

- --rebuildAllオプションを指定してすべての索引を再作成します。

- -iオプションを指定して、拡張索引のベースとなる属性索引を再作成します。例: -i cn。
この属性に基づいている索引は、属性に関連付けられている拡張索引も含めてすべて再作成されます。

- 特定の拡張索引を-iオプションと同時に指定することにより再作成します。例: -i cn.es.lteまたは-i sn.en.sub。

A.3.13.10 終了コード

終了コード0は、操作が正常に終了したことを示します。終了コード1は、処理中にエラーが発生したことを示します。

A.3.13.11 場所

- UNIXおよびLinux: INSTANCE_DIR/OUD/bin/rebuild-index

- Windows: INSTANCE_DIR\OUD\bat\rebuild-index.bat

A.3.13.12 関連コマンド

- 第A.3.16項「verify-index」

- 第A.2.4項「dsconfig」

A.3.14 restore

restoreコマンドは、ディレクトリ・サーバーのバックエンドのバックアップを復元します。

A.3.14.1 シノプシス

restore options

A.3.14.2 説明

restoreコマンドは、ディレクトリ・サーバーのバックエンドのバックアップを復元します。一度に復元できるバックエンドは1つだけです。このコマンドを使用して、復元操作を即時に実行することも、復元を後日実行するようにスケジュールすることもできます。詳細は、第14.4項「タスクとしてのコマンドの構成」を参照してください。

サーバーがオフラインのときにバックエンドを復元するか、サーバーがオンラインのときにバックエンドを後日復元するタスクをスケジュールすることができます。サーバーがオンラインの場合、restoreコマンドは、管理コネクタを介してSSL上のサーバーに接続します。管理コネクタの詳細は、第14.3項「サーバーへの管理トラフィックの管理」を参照してください。

A.3.14.3 オプション

restoreコマンドは、短いフォーム(例: -I backupID)または同等の長いフォーム(例: --backupID backupID)のいずれかのオプションを受け入れます。

-d, --backupDirectory path

バックアップ・アーカイブが含まれているディレクトリを使用して復元します。このディレクトリが存在していて、1つのバックアップ・ディスクリプタ・ファイルと、指定されたバックエンドに対して1つ以上のバックアップが含まれている必要があります。バックアップ・ディスクリプタ・ファイルは、使用可能なバックアップと、その作成に使用するオプションについての情報を取得するために読み取られます。これは必須オプションです。

-I, --backupID backupID

復元するバックアップのバックアップIDを指定します。このオプションが指定されない場合は、バックアップ・ディレクトリに含まれている最新のバックアップが復元されます。

-l, --listBackups

バックアップ・ディレクトリに含まれている使用可能なバックアップに関する情報を表示します。このオプションを指定すると、コマンドは復元を実行しないで終了します。

-n, --dry-run

指定したバックアップが有効であることを検証します(つまり、指定したバックアップが有効なアーカイブとして表示され、ハッシュまたは署名、またはその両方がバックアップのコンテンツと一致していることを確認します)。このオプションは、実際にはバックアップの復元を試行しません。

A.3.14.4 タスク・バックエンド接続オプション

オンライン復元を実行するには、タスク・バックエンドにアクセスする必要があります。タスク・バックエンドへのアクセスは、管理コネクタを介してSSLによって指定されます。これらの接続オプションは、復元をオンラインで実行するときに使用します。

-D, --bindDN bindDN

バインドDNを使用してディレクトリ・サーバーを認証します。このオプションは簡易認証の実行時に使用されます。SASL認証を使用する場合、このオプションは必要ありません。このオプションのデフォルト値はcn=Directory Managerです。

-h, --hostname hostname

指定されたホスト名またはIPアドレスのディレクトリ・サーバーに接続します。このオプションが指定されない場合は、localhostのデフォルトが使用されます。

-j, --bindPasswordFile filename

ディレクトリ・サーバーに対して認証を受ける際、指定したファイルにバインド・パスワードを使用します。

-K, --keyStorePath path

指定されたパスにクライアント・キーストア証明書を使用します。

-N, --certNickname nickname

指定された証明書をクライアント認証に使用します。

-o, --saslOption name=value

指定されたオプションをSASL認証に使用します。

-p, --port port

指定された管理ポートでディレクトリ・サーバーに接続します。このオプションが指定されない場合は、4444というデフォルトの管理ポートが使用されます。

-P, --trustStorePath path

指定されたパスにクライアント・トラスト・ストア証明書を使用します。このオプションは、--trustAllを使用している場合は必要ありません。ただし、本番環境で作業する場合はトラスト・ストアを使用する必要があります。

-u, --keyStorePasswordFile filename

クライアント・キーストアの証明書にアクセスするために、指定されたファイルでパスワードを使用します。このオプションは、--keyStorePathを使用する場合のみ必須です。

-U, --trustStorePasswordFile filename

クライアント・トラスト・ストアの証明書にアクセスするために、指定されたファイルでパスワードを使用します。このオプションは、--trustStorePathを使用していて、指定したトラスト・ストアがコンテンツへのアクセスにパスワードを必要とする場合のみ必須です(ほとんどのトラスト・ストアでは必要とされません)。

-X, --trustAll

ディレクトリ・サーバーによって提示されるすべてのサーバーSSL証明書を信頼します。このオプションは便宜的に、かつテストの目的で使用できますが、セキュリティ上の理由から、トラスト・ストアを使用してクライアントがサーバーの証明書を受け入れるかどうかを判別する必要があります。

A.3.14.5 タスク・スケジュール・オプション

--completionNotify emailAddress

タスク終了時に通知される受信者の電子メール・アドレスを指定します。このオプションは、1つのコマンドで複数回指定できます。

--dependency taskId

このタスクが依存するタスクのIDを指定します。タスクのすべての依存性が実行を完了するまで、タスクの実行は開始しません。

--errorNotify emailAddress

このタスクの実行時にエラーが発生した場合に通知される受信者の電子メール・アドレスを指定します。このオプションは、1つのコマンドで複数回指定できます。

--failedDependencyAction action

依存タスクの1つが失敗した場合に、このタスクが実行する必要のあるアクションを指定します。この値として、PROCESS、CANCEL、DISABLEのいずれか1つが指定されている必要があります。指定されていない場合、バックアップのデフォルトはCANCELになります。

--recurringTask schedulePattern

タスクは再帰的であり、crontab(5)互換の時間/日付パターンとして表記されるschedulePatternに従ってスケジュールされることを示します。

-t, --start startTime

ディレクトリ・サーバー・タスクとしてスケジュールされている際に、YYYYMMDDhhmmssのフォーマットで表記される操作の開始日付と時間を指定します。値0は、タスクを即時実行するようにスケジュールします。このオプションが指定された場合、操作は指定の時間に開始するようスケジュールされ、その直後にコマンドが終了します。

A.3.14.6 コマンド入力/出力オプション

--noPropertiesFile

デフォルトのコマンドライン・オプションの取得にプロパティ・ファイルが使用されないことを示します。

--propertiesFilePath path

デフォルトのコマンドライン・オプションが含まれているプロパティ・ファイルへのパスを指定します。

A.3.14.7 一般オプション

-?, -H, --help

このコマンドに対するコマンドライン使用情報を表示し、サーバーの停止または再起動を試行しないで終了します。

-V, --version

ディレクトリ・サーバーのバージョン情報を表示して、このコマンドの実行を試みるかわりに終了します。

A.3.14.8 例

次の例は、restoreコマンドの使用方法を示しています。

例A-111 バックアップ情報の表示

次のコマンドにより、バックアップ・ディスクリプタ・ファイル(backup.info)内のバックアップ情報がディレクトリ・サーバーに対してリストされます(-l)。このオプションを使用すると、サーバーが実行しているか停止しているかに関係なく、バックアップ情報を表示できます。

$ restore -l -d /tmp/backup/userRoot
Backup ID:          20081016050258Z
Backup Date:        16/Oct/2008:09:30:00 +0200
Is Incremental:     false
Is Compressed:      true
Is Encrypted:       true
Has Unsigned Hash:  false
Has Signed Hash:    true
Dependent Upon:     none

例A-112 バックアップの復元

次のコマンドにより、バックエンドがバックアップ・ディレクトリから復元されます。一度に復元できるバックエンドは1つだけです。このコマンドを実行する前に、サーバーを停止する必要があります。

$ stop-ds
$ restore -d /tmp/backup/userRoot
[16/Oct/2008:10:32:52 +0200] category=JEB severity=NOTICE msgID=8847445
msg=Restored: 00000000.jdb (size 321954)

例A-113 暗号化されたバックアップの復元

ハッシュされたバックアップまたは暗号化されたバックアップを復元するには、管理コネクタを介してSSL上でオンライン・サーバー・インスタンスに接続する必要があります。したがって、暗号化されたバックアップを復元する場合は、ホスト、管理ポート、バインドDN、およびバインド・パスワードも含めた接続の詳細を指定する必要があります。また、SSL接続用に証明書の詳細を指定する必要もあります。

次のコマンドにより、暗号化され、ハッシュされたバックアップが復元されます。自己署名証明書は、-X (--trustAll)オプションを使用して信頼されます。

$ restore -h localhost -p 4444 -D "cn=directory manager" -j /path/pwd-file -X \
-d /tmp/backup/userRoot/
Restore task 2008101610403710 scheduled to start immediately
[16/Oct/2008:10:40:38 +0200] severity="NOTICE" msgCount=0 msgID=9896306
message="The backend userRoot is now taken offline"
[16/Oct/2008:10:40:39 +0200] severity="NOTICE" msgCount=1 msgID=8847445
message="Restored: 00000000.jdb (size 331434)"
[16/Oct/2008:10:40:40 +0200] severity="NOTICE" msgCount=2 msgID=8847402
message="The database backend userRoot containing 102 entries has started"
Restore task 2008101610403710 has been successfully completed

例A-114 復元のスケジュール

復元をスケジュールするには、タスク・バックエンドにオンラインでアクセスする必要があります。このバックエンドへのアクセスは、管理コネクタを介してSSLによって指定されます。したがって、復元をスケジュールする場合は、ホスト、管理ポート、バインドDN、およびバインド・パスワードも含めた接続の詳細を指定する必要があります。また、SSL接続用に証明書の詳細を指定する必要もあります。

次のコマンドでは、--startオプションを使用して特定の開始時間にuserRootバックエンドを復元するタスクをスケジュールします。このコマンドにより、完了通知とエラー通知がadmin@example.comに送信されます。自己署名証明書は、-X (--trustAll)オプションを使用して信頼されます。

このスケジュール済タスクを表示するには、manage-tasksコマンドを使用します。詳細は、第14.4項「コマンドのタスクとしての構成」を参照してください。スケジュールされた復元の日付と時刻の前にサーバーが実行していることを確認する必要があります。

$ restore -h localhost -p 4444 -D "cn=directory manager" -j /path/pwd-file -X \
-d /backup/userRoot --start 20081025121500 --completionNotify admin@example.com \
--errorNotify admin@example.com
Restore task 2008101610442610 scheduled to start Oct 25, 2008 12:15:00 PM SAST

A.3.14.9 終了コード

終了コード0は、操作が正常に終了したことを示します。終了コード1は、処理中にエラーが発生したことを示します。

A.3.14.10 プロパティ・ファイルの使用方法

ディレクトリ・サーバーでは、restoreコマンドとともに使用されるデフォルトのオプション値を渡すプロパティ・ファイルの使用をサポートしています。プロパティ・ファイルは、様々な構成環境、特にスクリプト済アプリケーションまたは埋込みアプリケーションで作業する場合に便利です。詳細は、第A.1.2項「サーバー・コマンドによるプロパティ・ファイルの使用方法」を参照してください。

A.3.14.11 場所

- UNIXおよびLinux: INSTANCE_DIR/OUD/bin/restore

- Windows: INSTANCE_DIR\OUD\bat\restore.bat

A.3.14.12 関連コマンド

- 第A.3.3項「dbtest」

- 第A.2.8項「manage-tasks」

A.3.15 split-ldif

split-ldifコマンドは、指定された分散ワークフロー要素に従って、1つのLDIFファイルを複数のLDIFファイルに分割します。生成されたLDIFファイルは、分散デプロイメントのパーティションの移入に使用されます。

A.3.15.1 シノプシス

split-ldif options

A.3.15.2 説明

split-ldifコマンドは、指定された分散ワークフロー要素に従って、1つのLDIFファイルを複数のLDIFファイルに分割します。LDIFファイル内のデータは、指定された属性と定義された分散タイプに基づいて分割されます。その後、生成されたLDIFファイルはパーティションの移入に使用されます。split-ldifコマンドは次のように、パーティションごとにパーティション・ファイルを作成します:

outputDirectory/outputFilenamePrefix-partitionID.ldif

分散アルゴリズムがエントリの送り先となるパーティションを決定できない場合がありますが、これは、アルゴリズムが必要とするすべてのパラメータがエントリに含まれていないか、必要なパラメータは存在していても、どのパーティションにも一致しないためです。このようなシナリオでは、出力はエラー・ファイルに書き込まれます。

すべての必須パラメータが指定されていないエントリはすべて、次のエラー・ファイルに書き込まれます:

outputDirectory/outputFilenamePrefix-missingrequired-param.ldif

必須パラメータが指定されていても、そのパラメータがどの構成済パーティションにも一致しないエントリはすべて、次のエラー・ファイルに書き込まれます:

outputDirectory/outputFilenamePrefix-partition-not-found.ldif

ただし、グローバル索引の初期化のために、グローバル索引形式と互換性のあるファイルが含まれているディレクトリを使用してください。split-ldifコマンドは、索引付けする属性ごとにディレクトリを1つ作成し、各ディレクトリにはグローバル索引を初期化するためのファイルが含まれます。

グローバル索引カタログは、ディレクトリ内に作成された、LDIF形式ではないファイルを使用して移入されます。詳細は、第A.2.7項「gicadm」を参照してください。

A.3.15.3 オプション

split-ldifコマンドは、短いフォーム(例: -i ldifFile)または同等の長いフォーム(例: --ldifFile ldifFile)のいずれかのオプションを受け入れます。

-i, --ldifFile ldifFile

分割するLDIFファイルの名前。「グローバル索引オプション」および「分割オプション」を使用して動作をカスタマイズすることができます。

-l, --listDistributionNames

ディレクトリ・サーバーの構成から有効化された分散ワークフロー要素をリストします。

注意:

-l, --listDistributionNamesオプションでは、無効になった分散を使用してldifファイルを分割できないため、有効化された分散のみがリストされます。

A.3.15.4 グローバル索引オプション

-x, --index attributeTypeName

リストされた属性タイプに対して、グローバル索引オプションに使用する索引ファイルを生成します。

-c, --onlyCatalog

索引ファイルのみを生成します。

A.3.15.5 分割オプション

-d, --distributionName distributionName

データを分割する分散ワークフロー要素の名前。

-p, --forcePartitionId partitionId

リストされたpartitionIdが設定されているすべてのエントリが同一のパーティションに分散される索引ファイルを生成します。

-o, --outputDirectory outputDirectory

出力LDIFファイルが生成されるディレクトリ。

-O, --outputFilenamePrefix outputFilePrefix

生成するファイル名の接頭辞(これには、パーティションIDと.ldif拡張子が含まれます)。

-f, --force

以前に使用してすでに存在している可能性のある生成済ファイルを上書きします。

A.3.15.6 一般オプション

-V, --version

ディレクトリ・サーバーのバージョン情報を表示します。

-e, --help-examples

使用例を表示します。

-?, -H, --help

このコマンドに対するコマンドライン使用情報を表示し、ディレクトリ・サーバーの停止または再起動を試行しないで終了します。

A.3.15.7 例

例A-115 split-ldifを使用したグローバル索引への1つの索引付け属性の移入

次のコマンドでは、既存のデータベース・ファイル(-i)を使用します。このファイルは、プロキシ・デプロイメントですでに定義されている分散情報に基づいて複数のファイルに分割されます。このコマンドによって、分散ワークフロー要素名(-d)、分割するデータベース・ファイル(-i)、およびグローバル索引ファイル内で索引付けされる属性(-x)が定義されます。-fを指定すると、既存のLDIFファイルが上書きされます。

このコマンドを実行する前に、分散を使用してプロキシ・インスタンスをデプロイしておく必要があります。

$ split-ldif -d "distrib-we" -i database.ldif -x employeenumber -f

この例では、使用している分散アルゴリズムが数値であり、境界1-1000および1000-2000を割り当てた2つのパーティションが設定されているものと想定しています。上記のコマンドを実行すると、次のディレクトリとLDIFファイルが作成されます:

database-1.ldif

このファイルには従業員番号1-999を示すデータベースのエントリがすべて含まれており、これを使用してパーティション1を移入します。

database-2.ldif

このファイルには従業員番号1000-1999を示すデータベースのエントリがすべて含まれており、これを使用してパーティション2を移入します。

catalog\employeenumber

このディレクトリには、従業員番号属性に関するグローバル索引ファイルが含まれています。

例A-116 split-ldifを使用したグローバル索引への複数の索引付け属性の移入

次のコマンドでは、既存のデータベース・ファイル(-i)を使用します。このファイルは、プロキシ・デプロイメントですでに定義されている分散情報に基づいて複数のファイルに分割されます。このコマンドによって、分散ワークフロー要素名(-d)、分割するデータベース・ファイル(-i)、およびグローバル索引ファイル内で索引付けされる属性(-x)が定義されます。-fを指定すると、既存のLDIFファイルが上書きされます。

このコマンドを実行する前に、分散を使用してプロキシ・インスタンスをデプロイしておく必要があります。

$ split-ldif -d "distrib-we" -i database.ldif \
-x employeenumber -x uid -f

この例では、使用している分散アルゴリズムが数値であり、境界1-50000および50000-100001を割り当てた2つのパーティションが設定されているものと想定しています。上記のコマンドを実行すると、次のLDIFファイルとディレクトリが作成されます:

- database-1.ldif: このファイルには従業員番号1-49999を示すデータベースのエントリがすべて含まれており、これを使用してパーティション1を移入します。

- database-2.ldif: このファイルには従業員番号50000-100000を示すデータベースのエントリがすべて含まれており、これを使用してパーティション2を移入します。

- catalog\employeenumber: このディレクトリには、従業員番号属性に関するグローバル索引ファイルが含まれています。

- catalog\uid: このディレクトリには、uid属性に関するグローバル索引ファイルが含まれています。

A.3.15.8 場所

- UNIXおよびLinux: INSTANCE_DIR/OUD/bin/split-ldif

- Windows: INSTANCE_DIR\OUD\bat\split-ldif.bat

A.3.15.9 関連コマンド

gicadm

A.3.16 verify-index

verify-indexコマンドは、ディレクトリ索引データを検証します。

A.3.16.1 シノプシス

verify-index options

A.3.16.2 説明

verify-indexコマンドは、ディレクトリ・サーバー・データベース内の索引とエントリ・データ間の一貫性のチェックに使用します。このコマンドは、索引エントリの限度に達した索引キー数に関する情報も提供します。

このコマンドによって、次の情報がチェックされます:

- すべてのエントリが適切に索引付けされている

- 索引データ参照エントリがすべて存在している

- データは対応する索引データに一致している

現時点では、このコマンドは情報の保存にOracle Berkeley DB Java Editionを使用しているディレクトリ・サーバー・バックエンドのみで使用可能です。現在使用可能なその他のバックエンド・タイプでは、ディスク上の索引は保持されません。したがって、索引の一貫性を検証できるコマンドを使用する必要はありません。

ディレクトリ管理者は、ディレクトリ・サーバーの起動時または停止時でもこのコマンドを使用できます。ただし、サーバーが実行しているときにverify-indexを使用すると、ディレクトリ・サーバーとコマンドの全体的なパフォーマンスに影響が出ることに注意してください。たとえば、稼働率の非常に高いオンライン・サーバーでverify-indexコマンドを実行した場合は、オフラインの、または停止しているサーバーでこのコマンドを実行する場合よりも処理時間が非常に長くなることがあります。

このコマンドを使用するには、--baseDNオプションを使用して、検証が実行されるバックエンドのベースDNを指定する必要があります。

A.3.16.3 オプション

verify-indexコマンドは、短いフォーム(例: -b baseDN)または同等の長いフォーム(例: --baseDN baseDN)のいずれかのオプションを受け入れます。

A.3.16.4 コマンドのオプション

-b, --baseDN baseDN

検証の実行の対象となるベースDNを指定します。指定値は、Berkeley DB Java EditionをベースとしたバックエンドのベースDNである必要があります。これは必須オプションであり、1つのベースDNのみが指定可能です。

-c, --clean

索引が「クリーン」であること、つまり、すべての索引キーにあるすべてのエントリIDが参照するエントリは実際に存在し、その索引キーの基準に一致していることを検証します。このオプションを指定した場合は、--indexオプションを使用して索引を1つだけ指定する必要があります。このオプションを指定しない場合は、検証プロセスによってid2entryデータベース(各エントリIDをそのエントリの実データにマッピングしたもの)がクリーンになり、すべてのエントリ・コンテンツが適切に索引付けされていることが確認されます。

--countErrors

検証中に検出されたエラー数をカウントし、その値を終了コードとして返します。255を超える値は、終了コードの制約のため、255として返されます。

-i, --index index

検証の実行の対象となる索引の名前を指定します。--cleanオプションを指定した場合は、この引数を1回だけ指定する必要があります。そうでない場合、この引数はゼロ回、または複数回指定できます。このオプションが指定されない場合は、すべての索引がチェックされます。属性索引の場合、索引名に属性の名前を使用し、関連付けられたバックエンドでその属性に対して索引を構成する必要があります。また、サーバーで内部使用される次の内部索引を指定することもできます:

dn2id: エントリDNとそれに対応するエントリIDのマッピング。

id2children: エントリのエントリIDとその直接の子のエントリIDのマッピング。

id2subtree: エントリのエントリIDとそのすべての下位エントリのエントリIDのマッピング。

-v, --verbose

冗長モードを使用します。

A.3.16.5 一般オプション

-?, -H, --help

このコマンドに対するコマンドライン使用情報を表示し、サーバーの停止または再起動を試行しないで終了します。

-V, --version

ディレクトリ・サーバーのバージョン情報を表示して、このコマンドの実行を試みるかわりに終了します。

A.3.16.6 例

次の例は、verify-indexコマンドの使用方法を示しています。

例A-117 索引の検証

次のコマンドにより、dc=example,dc=com (-b dc=example,dc=com)下にあるuid索引(-i uid)が「クリーン」である(-c)ことを検証します。この「クリーン」オプションは、uid索引にある各エントリがuid属性を持つ実際のデータベース・エントリにマップしていることをチェックします。

$ verify-index -b dc=example,dc=com -c -i uid

[26/Jul/2007:16:42:31 -0500] category=BACKEND severity=NOTICE msgID=8388709
msg=Checked 150 records and found 0 error(s) in 0 seconds (average rate 331.1/sec)

例A-118 索引の検証とエラー件数のカウント

次のコマンドにより、dc=example,dc=com base DN (-b dc=example,dc=com)下にあるsn (surname)索引(-i sn)内の不一致(--countErrors)の件数をカウントします:

$ verify-index -b dc=example,dc=com -c -i sn --countErrors

[31/Jul/2007:02:23:52 -0500] category=BACKEND severity=NOTICE msgID=8388709 msg=
Checked 466 records and found 0 error(s) in 0 seconds (average rate 1298.1/sec)
[31/Jul/2007:02:23:52 -0500] category=BACKEND severity=NOTICE msgID=8388710 msg=
Number of records referencing more than one entry: 225
[31/Jul/2007:02:23:52 -0500] category=BACKEND severity=NOTICE msgID=8388711 msg=
Number of records that exceed the entry limit: 0
[31/Jul/2007:02:23:52 -0500] category=BACKEND severity=NOTICE msgID=8388712 msg=
Average number of entries referenced is 2.59/record
[31/Jul/2007:02:23:52 -0500] category=BACKEND severity=NOTICE msgID=8388713 msg=
Maximum number of entries referenced by any record is 150

A.3.16.7 終了コード

終了コード0は、操作が正常に終了したことを示します。1以上の終了コードは、処理中にエラーが発生したことを示します。

A.3.16.8 場所

- UNIXおよびLinux: INSTANCE_DIR/OUD/bin/verify-index

- Windows: INSTANCE_DIR\OUD\bat\verify-index.bat

A.3.16.9 関連コマンド

- 第A.3.13項「rebuild-index」

A.4 LDAPクライアントのコマンド

次の各項では、LDAPクライアントのユーティリティについて説明します:

- 第A.4.1項「ldapcompare」

- 第A.4.2項「ldapdelete」

- 第A.4.3項「ldapmodify」

- 第A.4.4項「ldappasswordmodify」

- 第A.4.5項「ldapsearch」

A.4.1 ldapcompare

ldapcompareコマンドは、LDAPエントリを比較します。

A.4.1.1 シノプシス

ldapcompare options

A.4.1.2 説明

ldapcompareコマンドは、ディレクトリ・サーバーに対するLDAP比較リクエストの発行に使用します。比較リクエストを使用して、指定されたエントリ、またはエントリのセットに特定の属性と値の組合せがあるかどうかを判別できます。比較操作が正常に行われた結果として返される情報は、比較の評価がtrueまたはfalseであるかどうかのみを示します。エントリに関するその他の情報は示されません。

コマンドライン上のldapcompareツールの構文として、次のいずれのフォームでも使用できます:

ldapcompare [ options ] attribute:value [ "targetDN" ... | -f DNfile]
ldapcompare [ options ] attribute::base64value [ "targetDN" ... | -f DNfile ]
ldapcompare [ options ] attribute:fileURL [ "targetDN" ... | -f DNfile ]

説明:

- optionsは、次の項で説明するコマンドライン・オプションです。

- attributeは属性タイプの名前であり、この後ろに比較値を指定する3つの方法のいずれか1つが続きます。属性タイプの名前と値の文字列は、シェルに対応できるように一重引用符(")で囲む必要があります。

- targetDNは、指定された属性の検索とその値の比較に使用される識別名(DN)またはDNのリストです。

- DNfileは、指定された属性を検索してその値を比較するための、1行ごとに1つずつDNのリストを含むファイルです。

A.4.1.3 オプション

ldapcompareコマンドは、短いフォーム(例: -D bindDN)または同等の長いフォーム(例: --bindDN bindDN)のいずれかのオプションを受け入れます。

A.4.1.4 コマンドのオプション

--assertionFilter filter

LDAPアサーション制御(RFC 4528に定義しています)を使用して検索を実行し、指定されたフィルタに含まれているアサーションがtrueである場合のみ操作を処理することを示します。

-c, --continueOnError

エラーが発生した場合でも処理を続行します。これは、複数のエントリDNが後続オプションとして、または--filenameオプションによって指定されたファイルの中に設定されている場合に当てはまります。比較リクエストの処理中にエラーが発生した場合、クライアントは、--continueOnErrorオプションが指定されていれば、次のエントリDNを使用して処理を続行し、このオプションが指定されていない場合はエラーを示して終了します。

-f, --filename filename

検索操作を処理する際に使用する1つ以上のフィルタが含まれているファイルへのパスを指定します。複数のエントリDNが存在する場合は、1行に1つのDNが表示されるようにファイルを構成する必要があります。すべての比較は、同じディレクトリ・サーバーとの接続を使用して、ファイルに表示される順序で実行されます。このオプションが指定されない場合は、少なくとも1つのエントリDNが属性と値のアサーションの後に続く必要があります。このオプションを使用する場合、必要な後続オプションは属性と値のアサーションのみです。--filenameオプションは、追加のコマンドライン・オプションとして指定されたどのDNよりも優先されます。追加のDNは無視されるだけです。

-J, --control controloid[criticality[:value|::b64value|:<fileurl]]

ディレクトリ・サーバーに送信された検索リクエストに指定されているコントロールを使用して、検索を実行します。このオプションを使用すると、クライアントが直接サポートできない任意のリクエスト・コントロールを含めることができます。このオプションの値には、次のフォームを使用する必要があります:

oid[:criticality[:value|::b64value|:<fileurl]]

この値の要素は次のとおりです:

- oid: コントロールにOIDを使用します。特定のタイプのコントロールについては、数値OIDのかわりにテキスト名を使用することもできます(検索操作の場合は、DSA IT管理のコントロールに対するmanagedsaitも含まれます)。この要素は必須です。-Jオプションまたはcontrolオプションを使用すると、OIDのかわりに判読可能な名前を使用して、値を必要としないコントロールを参照することができます。これらのOID名は次のとおりです:

- accountusableまたはaccountusability: アカウント・ユーザビリティ・リクエスト・コントロールOID: 1.3.6.1.4.1.42.2.27.9.5.8のかわりに使用(値なし)

- authzidまたはauthorizationidentity: 認可IDリクエスト・コントロールOID: 2.16.840.1.113730.3.4.16のかわりに使用(値なし)

- effectiverights: 有効な権限の取得コントロールOID: 1.3.6.1.4.1.42.2.27.9.5.2のかわりに使用(値=認可ID)

- managedsait: DSA ITの管理コントロールOID: 2.16.840.1.113730.3.4.2のかわりに使用(値なし)

- noopまたはno-op: LDAP No-opコントロールOID: 1.3.6.1.4.1.4203.1.10.2のかわりに使用(値なし)

- pwpolicyまたはpassword policy: パスワード・ポリシー・リクエストOID: 1.3.6.1.4.1.42.2.27.8.5.1のかわりに使用(値なし)

- subtreedeleteまたはtreedelete: サブツリー削除リクエスト・コントロールOID: 1.2.840.113556.1.4.805のかわりに使用(値なし)

- criticality: trueの場合、コントロールをクリティカルとマークする必要があります(つまり、操作がこのコントロールの要件を満たさないかぎり、ディレクトリ・サーバーは操作を処理しません)。falseの場合は、コントロールをクリティカルとマークする必要はありません。このサブコマンドが指定されていない場合、コントロールはクリティカルとマークされません。

- value: コントロールの値を指定します。このフォームは、値を文字列として表記できる場合のみ使用します。これは、::b64valueフォームまたは:< fileurlフォームと連係して使用することはできません。これらのサブコマンドがいずれも指定されていない場合、コントロールには値が設定されません。

- b64value: コントロールの値をbase64でエンコードされたフォームで指定します。このサブコマンドは、:valueフォームまたは:< fileurlフォームと連係して使用することはできません。これらのサブコマンドがいずれも指定されていない場合、コントロールには値が設定されません。

- fileurl: 取り込むコントロールの値のあるファイルを参照するURLを指定します。これは、:valueフォームまたは::b64valueフォームと連係して使用することはできません。これらのサブコマンドがいずれも指定されていない場合、コントロールには値が設定されません。

たとえば、値1.3.6.1.4.1.42.2.27.9.5.2:true:dn:uid=dmiller,ou=people,dc=example,dc=comには、OIDが1.3.6.1.4.1.42.2.27.9.5.2であり、クリティカル(true)とマークされ、認可ID dn:uid=dmiller,ou=people,dc=example,dc=comの文字列値のあるクリティカルなコントロールが含まれます。または、次のOID名、effectiverights:true:dn:uid=dmiller、ou=people、dc=example、dc=comが使用できます。

-n, --dry-run

no-opモードで実行します。つまり、発生する内容を報告しますが、実際に検索を実行したり、どの方法でもサーバーと通信することはありません。

A.4.1.5 LDAP接続オプション

-D, --bindDN bindDN

バインドDNを使用してディレクトリ・サーバーを認証します。このオプションは簡易認証の実行時に使用されます。SASL認証を使用する場合、このオプションは必要ありません。このオプションのデフォルト値はcn=Directory Managerです。

-h, --hostname address

指定されたホスト名またはIPアドレスのディレクトリ・サーバーに接続します。これが指定されない場合は、localhostのデフォルトのアドレスが使用されます。

-j, --bindPasswordFile bindPasswordFile

ディレクトリ・サーバーに対して認証を受ける際、指定したファイルにバインド・パスワードを使用します。このオプションは、簡易認証と、パスワードに基づくSASLメカニズム(CRAM-MD5、DIGEST-MD5、およびPLAINなど)に使用します。認可が実行されない場合、これは必要ありません。このオプションは、--bindPasswordと同時に使用しないでください。

SASLは、プロキシ・サーバー・インスタンスに対してサポートされていません。

-K, --keyStorePath keyStorePath

SSLまたはStartTLS拡張操作を使用する場合は、セキュアな通信のために、指定されたパスにクライアント・キーストア証明書を使用します。このオプションは、SASL EXTERNAL認証を使用する場合など、クライアントがディレクトリ・サーバーに証明書を提示する必要がある場合のみ必要です。

SASLは、プロキシ・サーバー・インスタンスに対してサポートされていません。

-N, --certNickName certNickName

証明書ベースのクライアント認証に対して指定された証明書を使用します。

-o, --saslOption name=value

SASL認証を実行するときに、指定されたオプションを使用します。複数のSASLオプションを指定するには、オプションごとに1回ずつ、このオプションを複数回使用します。

SASLは、プロキシ・サーバー・インスタンスに対してサポートされていません。

-p, --port port

指定されたポートでディレクトリ・サーバーに接続します。このオプションが指定されない場合は、デフォルトのポート389が使用されます。

-P, --trustStorePath trustStorePath

SSLまたはStartTLS拡張操作を使用する場合は、セキュアな通信のために、指定されたパスにクライアント・トラスト・ストア証明書を使用します。このオプションは、--trustAllを使用している場合は必要ありません。ただし、本番環境で作業する場合はトラスト・ストアを使用する必要があります。

-q, --useStartTLS

ディレクトリ・サーバーと通信する際、StartTLS拡張操作を使用します。このオプションは、--useSSLと同時に使用しないでください。

-r, --useSASLExternal

認証に対してSASL EXTERNALメカニズムを使用します。このメカニズムでは、クライアントがディレクトリ・サーバーに提示したSSL証明書を使用してクライアントを識別しようと試行されます。このオプションを使用する場合は、--keyStorePathオプションも同時に使用してクライアント・キーストアへのパスを指定し、--useSSLオプションまたは--useStartTLSオプションを使用してサーバーとのセキュアな通信チャネルを確立する必要があります。

SASLは、プロキシ・サーバー・インスタンスに対してサポートされていません。

--trustStorePassword trustStorePassword

クライアント・トラスト・ストアの証明書へのアクセスに必要なパスワードを使用します。このオプションは、--trustStorePathを使用していて、指定したトラスト・ストアがコンテンツへのアクセスにパスワードを必要とする場合のみ必須です(ほとんどのトラスト・ストアでは必要とされません)。このオプションは、--trustStorePasswordFileと同時に使用しないでください。

-u, --keyStorePasswordFile keyStorePasswordFile

クライアント・キーストアの証明書にアクセスするために、指定されたファイルでパスワードを使用します。このオプションは、--keyStorePathを使用する場合のみ必須です。このオプションは、--keyStorePasswordと同時に使用しないでください。

-U, --trustStorePasswordFile trustStorePasswordFile

クライアント・トラスト・ストアの証明書にアクセスするために、指定されたファイルでパスワードを使用します。このオプションは、--trustStorePathを使用していて、指定したトラスト・ストアがコンテンツへのアクセスにパスワードを必要とする場合のみ必須です(ほとんどのトラスト・ストアでは必要とされません)。このオプションは、--trustStorePasswordと同時に使用しないでください。

-V, --ldapVersion version

クライアントがディレクトリ・サーバーと通信する際に使用する必要のあるLDAPプロトコルのバージョンを設定します。この値には、2 (LDAPv2通信の場合)または3 (LDAPv3の場合)のいずれかを設定する必要があります。このオプションが指定されない場合、クライアントはLDAPv3を使用します。

-w, --bindPassword bindPassword

ディレクトリ・サーバーに対して認証を受ける際、バインド・パスワードを使用します。このオプションは、簡易認証と、パスワードに基づくSASLメカニズムに使用できます。このオプションは、--bindPasswordFileと同時に使用しないでください。パスワードの入力を要求するには、-w -を入力します。

SASLは、プロキシ・サーバー・インスタンスに対してサポートされていません。

-W, --keyStorePassword keyStorePassword

クライアント・キーストアの証明書へのアクセスに必要なパスワードを使用します。このオプションは、--keyStorePathを使用する場合のみ必須です。このオプションは、--keyStorePasswordFileと同時に使用しないでください。

-X, --trustAll

SSLまたはStartTLSのネゴシエーション中にディレクトリ・サーバーによって提示される可能性のある証明書をすべて信頼します。このオプションは便宜的に、かつテストの目的で使用できますが、セキュリティ上の理由から、トラスト・ストアを使用してクライアントがサーバーの証明書を受け入れるかどうかを判別する必要があります。

-Z, --useSSL

ディレクトリ・サーバーと通信する際、Secure Sockets Layerを使用します。SSLを使用する場合は、--portオプションを使用してサーバーのセキュア・ポートを指定する必要があります。

A.4.1.6 コマンド入力/出力オプション

--noPropertiesFile

デフォルトのコマンドライン・オプションの取得にプロパティ・ファイルが使用されないことを示します。

--propertiesFilePath propertiesFilePath

デフォルトのコマンドライン・オプションが含まれているプロパティ・ファイルへのパスを指定します。

-v, --verbose

冗長モードで実行して、プロセス情報と診断情報を標準出力で表示します。

A.4.1.7 一般オプション

-?, -H, --help

このコマンドに対するコマンドライン使用情報を表示し、コマンドの実行を試みないで終了します。

-V, --version

ディレクトリ・サーバーのバージョン情報を表示します。

A.4.1.8 例

次の例は、ldapcompareコマンドの使用方法を示しています。

例A-119 グループ・メンバーシップに関するエンティティの比較

次のコマンドでは、ポート1389 (-p)に接続するホスト名(-h)を指定し、従業員(uid=scarter)がグループ(cn=Accounting Managers)のメンバーであるかどうかを検証します。

$ ldapcompare -h hostname -p 1389 \
"uniquemember:uid=scarter,ou=People,dc=example,dc=com" \
"cn=Accounting Managers,ou=groups,dc=example,dc=com"

Comparing type uniquemember with value uid=scarter,ou=People,dc=example,dc=com
in entry cn=Accounting Managers,ou=groups,dc=example,dc=com
Compare operation returned true for entry
cn=Accounting Managers,ou=groups,dc=example,dc=com

例A-120 属性値とエントリの比較

次のコマンドでは、ポート1389 (-p)に接続するホスト名(-h)を指定し、属性(ou=Accounting)がエンティティ(cn=Sam Carter)のレコードに存在するかどうかを検証します。

$ ldapcompare -h hostname -p 1389 "ou:Accounting" \
"uid=scarter,ou=People,dc=example,dc=com"

Comparing type ou with value Accounting in entry uid=scarter,ou=People,dc=example,dc=com
Compare operation returned true for entry uid=scarter,ou=People,dc=example,dc=com

例A-121 サーバー認証でのldapcompareの使用

次のコマンドでは、サーバー認証を使用して、ホスト名(-h)、SSLポート(-p)、ベースDN (-b)、バインドDN (-D)、バインド・パスワード(-w)、トラスト・ストア・ファイル・パス(-P)を指定し、属性がエントリに存在するかどうかをチェックします。Windowsプラットフォームの場合は、トラスト・ストア・ファイルが常駐しているパス(たとえば、-P \temp\certs\cert.db)を使用します。

$ ldapcompare -h hostname -p 1636 -D "cn=Directory Manager" \
-j pwd-file -P /home/kwinters/certs/cert.db \
'givenname:Sam' "uid=scarter,ou=People,dc=example,dc=com"

Comparing type givenname with value Sam in entry uid=scarter,ou=People,dc=example,dc=com
Compare operation returned true for entry uid=scarter,ou=People,dc=example,dc=com

例A-122 クライアント認証でのldapcompareの使用

次のコマンドでは、比較とともにクライアント認証を使用します。このコマンドは、SSLポート(-p)を指定してSSL (-Z)を使用し、トラスト・ストア・ファイル・パス(-P)、証明書ニックネーム(-N)、キーストア・ファイル・パス(-K)、キーストア・パスワード(-W)を指定して、エンティティに指定された名前givenname=Samがエントリに存在しているかどうかをチェックします。Windowsプラットフォームの場合は、トラスト・ストア・ファイルが常駐しているパス(たとえば、-P \temp\certs\cert.db)と、キーストア・ファイルが常駐しているパス(-K \temp\security\key.db)を使用します。

$ ldapcompare -h hostname -p 1636 -Z \
-P /home/kwinters/security/cert.db -N "kwcert" \
-K /home/kwinters/security/key.db -W KeyPassword \
'givenname:Sam' "uid=scarter,ou=People,dc=example,dc=com"

Comparing type givenname with value Sam in entry uid=scarter,ou=People,dc=example,dc=com
Compare operation returned true for entry uid=scarter,ou=People,dc=example,dc=com

A.4.1.9 終了コード

終了コード6は、比較が成功したことを示します。終了コード5は、比較が成功していないことを示します。その他のすべての終了コードは、処理中にエラーが発生したことを示します。

A.4.1.10 CLIプロパティ・ファイルの使用方法

ディレクトリ・サーバーでは、ldapcompareコマンドとともに使用されるデフォルトのオプション値を渡すプロパティ・ファイルの使用をサポートしています。プロパティ・ファイルは、様々な構成環境、特にスクリプト済アプリケーションまたは埋込みアプリケーションで作業する場合に便利です。詳細は、第A.1.2項「サーバー・コマンドによるプロパティ・ファイルの使用方法」を参照してください。

プロパティ・ファイルに保存可能なオプションは次のとおりです:

- assertionFilter

- bindDN

- bindPassword

- bindPasswordFile

- certNickname

- continueOnError

- control

- dry-run

- filename

- hostname

- keyStorePassword

- keyStorePasswordFile

- keyStorePath

- ldapVersion

- port

- saslOption

- trustAll

- trustStorePassword

- trustStorePasswordFile

- trustStorePath

- useSASLExternal

- useSSL

- useStartTLS

- verbose

プロパティ・ファイルのエントリのフォーマットは、次のとおりです:

toolname.propertyname=propertyvalue

例:

ldapcompare.ldapport=12345

A.4.1.11 場所

- UNIXおよびLinux: INSTANCE_DIR/OUD/bin/ldapcompare

- Windows: INSTANCE_DIR\OUD\bat\ldapcompare.bat

A.4.1.12 関連コマンド

- 第A.4.2項「ldapdelete」

- 第A.4.3項「ldapmodify」

- 第A.4.4項「ldappasswordmodify」

- 第A.4.5項「ldapsearch」

A.4.2 ldapdelete

ldapdeleteコマンドは、エントリを削除するために、LDAP削除リクエストをディレクトリ・サーバーに対して発行します。

A.4.2.1 シノプシス

ldapdelete [option] [DN]

A.4.2.2 説明

ldapdeleteコマンドは、エントリを削除するために、LDAP削除リクエストをディレクトリ・サーバーに対して発行します。--filenameオプションが指定されないかぎり、削除するエントリを指定するために、エントリDNを唯一の後続オプションとして指定する必要があります。

A.4.2.3 開始する前に

多くのUNIXまたはLinuxオペレーティング・システムには共通のLDAPクライアント・コマンドのインストール済バージョンが用意されており、たとえば、/usr/binディレクトリのldapsearch、ldapmodify、およびldapdeleteなどがあります。使用しているシステムにバージョンがインストールされているかどうかをチェックするには、コマンドwhich ldapdeleteを入力します。このコマンドが値(以下に示します)を返す場合は、$PATHをINSTANCE_DIR/OUD/binディレクトリに更新するか、ディレクトリ・サーバー・インスタンスの別名を作成する必要があります。

$ which ldapdelete (UNIX/Linux)
/usr/bin/ldapdelete

A.4.2.4 オプション

ldapdeleteコマンドは、短いフォーム(例: -D bindDN)または同等の長いフォーム(例: --bindDN bindDN)のいずれかのオプションを受け入れます。

A.4.2.5 コマンドのオプション

-c, --continueOnError

エラーが発生した場合でも処理を続行します。この操作は、複数のエントリDNが後続オプションとして、または--filenameオプションによって指定されたファイルの中に設定されている場合に当てはまります。比較リクエストの処理中にエラーが発生した場合、クライアントは、--continueOnErrorオプションが指定されていれば、次のエントリDNを使用して処理を続行し、このオプションが指定されていない場合はエラーを示して終了します。

-f, --filename filename

検索操作を処理する際に使用する1つ以上のフィルタが含まれているファイルへのパスを指定します。複数のエントリDNが存在する場合は、1行に1つのDNが表示されるようにファイルを構成する必要があります。このオプションを使用する場合は、後続オプションを追加しません。削除するエントリのDNを唯一の後続オプションとします。

-J, --control controloid[:criticality[:value|::b64value|:<fileurl]]

ディレクトリ・サーバーに送信された検索リクエストに指定されているコントロールを使用して、検索を実行します。このオプションを使用すると、クライアントが直接サポートできない任意のリクエスト・コントロールを含めることができます。このオプションの値には、次のフォームを使用する必要があります:

oid[:criticality[:value|::b64value|:<fileurl]]

この値の要素は次のとおりです:

- oid。コントロールのOIDを使用します。特定のタイプのコントロールについては、数値OIDのかわりにテキスト名を使用することもできます(検索操作の場合は、DSA IT管理のコントロールに対するmanagedsaitも含まれます)。この要素は必須です。-Jオプションまたはcontrolオプションを使用すると、OIDのかわりに判読可能な名前を使用して、値を必要としないコントロールを参照することができます。これらのOID名は次のとおりです:
accountusableまたはaccountusability: アカウント・ユーザビリティ・リクエスト・コントロールOID: 1.3.6.1.4.1.42.2.27.9.5.8のかわりに使用(値なし)。

authzidまたはauthorizationidentity: 認可IDリクエスト・コントロールOID: 2.16.840.1.113730.3.4.16のかわりに使用(値なし)。

effectiverights: 有効な権限の取得コントロールOID: 1.3.6.1.4.1.42.2.27.9.5.2のかわりに使用(値=認可ID)。

managedsait: DSA ITの管理コントロールOID: 2.16.840.1.113730.3.4.2のかわりに使用(値なし)。

noopまたはno-op: LDAP No-opコントロールOID: 1.3.6.1.4.1.4203.1.10.2のかわりに使用(値なし)。

pwpolicyまたはpassword policy: パスワード・ポリシー・リクエスト・コントロールOID: 1.3.6.1.4.1.42.2.27.8.5.1のかわりに使用(値なし)。

subtreedeleteまたはtreedelete: サブツリー削除リクエスト・コントロールOID: 1.2.840.113556.1.4.805のかわりに使用(値なし)。

- criticality。trueの場合、コントロールをクリティカルとマークする必要があります(つまり、操作がこのコントロールの要件を満たさないかぎり、ディレクトリ・サーバーは操作を処理しません)。falseの場合は、コントロールをクリティカルとマークする必要はありません。このサブコマンドが指定されていない場合、コントロールはクリティカルとマークされません。

- value。コントロールの値を指定します。このフォームは、値を文字列として表記できる場合のみ使用します。これは、::b64valueフォームまたは:< fileurlフォームと連係して使用することはできません。これらのサブコマンドがいずれも指定されていない場合、コントロールには値が設定されません。

- b64value。コントロールの値をbase64でエンコードされたフォームで指定します。このサブコマンドは、:valueフォームまたは:< fileurlフォームと連係して使用することはできません。これらのサブコマンドがいずれも指定されていない場合、コントロールには値が設定されません。

- fileurl。取り込むコントロールの値のあるファイルを参照するURLを指定します。これは、:valueフォームまたは::b64valueフォームと連係して使用することはできません。これらのサブコマンドがいずれも指定されていない場合、コントロールには値が設定されません。
たとえば、値1.3.6.1.4.1.42.2.27.9.5.2:true:dn:uid=dmiller,ou=people,dc=example,dc=comには、OIDが1.3.6.1.4.1.42.2.27.9.5.2であり、クリティカル(true)とマークされ、認可ID dn:uid=dmiller,ou=people,dc=example,dc=comの文字列値のあるクリティカルなコントロールが含まれます。または、次のOID名、effectiverights:true:dn:uid=dmiller、ou=people、dc=example、dc=comが使用できます。

-n, --dry-run

no-opモードで実行します。つまり、発生する内容を報告しますが、実際に検索を実行したり、どの方法でもサーバーと通信することはありません。

-x, --deleteSubtree

指定されたエントリと、その下のエントリをすべて削除します。

A.4.2.6 LDAP接続オプション

-D, --bindDN bindDN

バインドDNを使用してディレクトリ・サーバーを認証します。このオプションは簡易認証の実行時に使用されます。SASL認証を使用する場合、このオプションは必要ありません。このオプションのデフォルト値はcn=Directory Managerです。

-h, --hostname address

指定されたホスト名またはIPアドレスのディレクトリ・サーバーに接続します。これが指定されない場合は、localhostのデフォルトのアドレスが使用されます。

-j, --bindPasswordFile bindPasswordFile

ディレクトリ・サーバーに対して認証を受ける際、指定したファイルにバインド・パスワードを使用します。このオプションは、簡易認証と、パスワードに基づくSASLメカニズム(CRAM-MD5、DIGEST-MD5、およびPLAINなど)に使用します。認可が実行されない場合、これは必要ありません。このオプションは、--bindPasswordと同時に使用しないでください。

SASLは、プロキシ・サーバー・インスタンスに対してサポートされていません。

-K, --keyStorePath keyStorePath

SSLまたはStartTLS拡張操作を使用する場合は、セキュアな通信のために、指定されたパスにクライアント・キーストア証明書を使用します。このオプションは、SASL EXTERNAL認証を使用する場合など、クライアントがディレクトリ・サーバーに証明書を提示する必要がある場合のみ必要です。

SASLは、プロキシ・サーバー・インスタンスに対してサポートされていません。

-N, --certNickName certNickName

証明書ベースのクライアント認証に対して指定された証明書を使用します。

-o, --saslOption name = value

SASL認証を実行するときに、指定されたオプションを使用します。複数のSASLオプションを指定するには、オプションごとに1回ずつ、このオプションを複数回使用します。詳細は、第20.6項「SASL認証の使用方法」を参照してください。

SASLは、プロキシ・サーバー・インスタンスに対してサポートされていません。

-p, --port port

指定されたポートでディレクトリ・サーバーに接続します。このオプションが指定されない場合は、デフォルトのポート389が使用されます。

-P, --trustStorePath trustStorePath

SSLまたはStartTLS拡張操作を使用する場合は、セキュアな通信のために、指定されたパスにクライアント・トラスト・ストア証明書を使用します。このオプションは、--trustAllを使用している場合は必要ありません。ただし、本番環境で作業する場合はトラスト・ストアを使用する必要があります。

-q, --useStartTLS

ディレクトリ・サーバーと通信する際、StartTLS拡張操作を使用します。このオプションは、--useSSLと同時に使用しないでください。

-r, --useSASLExternal

認証に対してSASL EXTERNALメカニズムを使用します。このメカニズムでは、クライアントがディレクトリ・サーバーに提示したSSL証明書を使用してクライアントを識別しようと試行されます。このオプションを使用する場合は、--keyStorePathオプションも同時に使用してクライアント・キーストアへのパスを指定し、--useSSLオプションまたは--useStartTLSオプションを使用してサーバーとのセキュアな通信チャネルを確立する必要があります。

SASLは、プロキシ・サーバー・インスタンスに対してサポートされていません。

--trustStorePassword trustStorePassword

クライアント・トラスト・ストアの証明書へのアクセスに必要なパスワードを使用します。このオプションは、--trustStorePathを使用していて、指定したトラスト・ストアがコンテンツへのアクセスにパスワードを必要とする場合のみ必須です(ほとんどのトラスト・ストアでは必要とされません)。このオプションは、--trustStorePasswordFileと同時に使用しないでください。

-u, --keyStorePasswordFile keyStorePasswordFile

クライアント・キーストアの証明書にアクセスするために、指定されたファイルでパスワードを使用します。このオプションは、--keyStorePathを使用する場合のみ必須です。このオプションは、--keyStorePasswordと同時に使用しないでください。

-U, --trustStorePasswordFile trustStorePasswordFile

クライアント・トラスト・ストアの証明書にアクセスするために、指定されたファイルでパスワードを使用します。このオプションは、--trustStorePathを使用していて、指定したトラスト・ストアがコンテンツへのアクセスにパスワードを必要とする場合のみ必須です(ほとんどのトラスト・ストアでは必要とされません)。このオプションは、--trustStorePasswordと同時に使用しないでください。

-V, --ldapVersion version

クライアントがディレクトリ・サーバーと通信する際に使用する必要のあるLDAPプロトコルのバージョンを設定します。この値には、2 (LDAPv2通信の場合)または3 (LDAPv3の場合)のいずれかを設定する必要があります。このオプションが指定されない場合、クライアントはLDAPv3を使用します。

-w, --bindPassword bindPassword

ディレクトリ・サーバーに対して認証を受ける際、バインド・パスワードを使用します。このオプションは、簡易認証と、パスワードに基づくSASLメカニズムに使用できます。このオプションは、--bindPasswordFileと同時に使用しないでください。パスワードの入力を要求するには、-w -を入力します。

SASLは、プロキシ・サーバー・インスタンスに対してサポートされていません。

-W, --keyStorePassword keyStorePassword

クライアント・キーストアの証明書へのアクセスに必要なパスワードを使用します。このオプションは、--keyStorePathを使用する場合のみ必須です。このオプションは、--keyStorePasswordFileと同時に使用しないでください。

-X, --trustAll

SSLまたはStartTLSのネゴシエーション中にディレクトリ・サーバーによって提示される可能性のある証明書をすべて信頼します。このオプションは便宜的に、かつテストの目的で使用できますが、セキュリティ上の理由から、トラスト・ストアを使用してクライアントがサーバーの証明書を受け入れるかどうかを判別する必要があります。

-Z, --useSSL

ディレクトリ・サーバーと通信する際、Secure Sockets Layerを使用します。SSLを使用する場合は、--portオプションを使用してサーバーのセキュア・ポートを指定する必要があります。

A.4.2.7 コマンド入力/出力オプション

--noPropertiesFile

デフォルトのコマンドライン・オプションの取得にプロパティ・ファイルが使用されないことを示します。

--propertiesFilePath propertiesFilePath

デフォルトのコマンドライン・オプションが含まれているプロパティ・ファイルへのパスを指定します。

-v, --verbose

冗長モードで実行して、プロセス情報と診断情報を標準出力で表示します。

A.4.2.8 一般オプション

-?, -H, --help

このコマンドに対するコマンドライン使用情報を表示し、コマンドの実行を試みないで終了します。

-V, --version

ディレクトリ・サーバーのバージョン情報を表示します。

A.4.2.9 例

次の例は、ldapdeleteコマンドの使用方法を示しています。

例A-123 コマンドラインからのエントリの削除

次のコマンドでは、ホスト名(-h)、ポート(-p)、バインドDN (-D)、バインド・パスワード(-w)を指定して、単一エントリを削除します:

$ ldapdelete -h hostname -p 1389 -D "cn=Directory Manager" -j pwd-file \
"uid=mgarza,ou=People,dc=example,dc=com"

例A-124 DNファイルを使用した複数エントリの削除

次のファイルには、削除するDNのリストが含まれています。このファイルでは、各DNをそれぞれ別の行にリストする必要があります。

uid=mgarza,ou=People,dc=example,dc=com
uid=wsmith,ou=People,dc=example,dc=com
uid=jarrow,ou=People,dc=example,dc=com
uid=mbean,ou=People,dc=example,dc=com

次のコマンドでは、ホスト名(-h)、ポート(-p)、バインドDN (-D)、バインド・パスワード(-w)を指定して、削除するエントリをファイルに読み取ります。エラーが発生した場合、このコマンドは次の検索項目で処理を続行(-c)します。Windowsプラットフォームの場合は、削除ファイルが常駐しているパス(たとえば、-f \temp\delete.ldif)を使用します:

$ ldapdelete -h hostname -p 1389 -D "cn=Directory Manager" -j pwd-file \
-c -f /usr/local/delete.ldif

例A-125 サーバー認証を使用したエントリの削除

次のコマンドでは、サーバー認証を使用してエントリを削除します。次のコマンドでは、ホスト名(-h)、SSLポート(-p)、バインドDN (-D)、バインド・パスワード(-w)、トラスト・ストア・ファイル・パス(-P)、および削除が含まれているLDIFファイル(-f)を指定します。エラーが発生した場合、このコマンドは次の検索項目で処理を続行(-c)します。Windowsプラットフォームの場合は、削除ファイルが常駐しているパス(たとえば、-f \temp\delete.ldif)およびトラスト・ストア・パスワードが常駐しているファイル(たとえば、-P \temp\certs\cert.db)を使用します:

$ ldapdelete -h hostname -p 1636 -c -f /usr/local/delete.ldif \
-D "cn=Directory Manager" -j pwd-file \
-P /home/kwinters/certs/cert.db

例A-126 クライアント認証を使用したエントリの削除

次のコマンドは、クライアント認証を使用して削除オプションを実行します。このコマンドは、SSLポート(-p)を指定してSSL (-Z)を使用し、トラスト・ストア・ファイル・パス(-P)、証明書ニックネーム(-N)、キーストア・ファイル・パス(-K)、キーストア・パスワード(-W)および削除が含まれているLDIFファイル(-f)を指定します。エラーが発生した場合、このコマンドは次の検索項目で処理を続行(-c)します。Windowsプラットフォームの場合は、削除ファイルが常駐しているパス(たとえば、-f \temp\delete.ldif)、トラスト・ストア・パスワードが常駐しているファイル(たとえば、-P \temp\certs\cert.db)およびキーストア・パスワードが常駐しているファイル(たとえば、-K \temp\security\key.db)を使用します。

$ ldapdelete -h hostname -p 1636 -c -f /usr/local/delete.ldif \
-Z -P /home/kwinters/security/cert.db -N "kwcert" \
-K /home/kwinters/security/key.db -W keypassword

A.4.2.10 終了コード

終了コード0は、操作が正常に終了したことを示します。ゼロ以外の終了コードは、処理中にエラーが発生したことを示します。

A.4.2.11 CLIプロパティ・ファイルの使用方法

ディレクトリ・サーバーでは、ldapdeleteコマンドとともに使用されるデフォルトのオプション値を渡すプロパティ・ファイルの使用をサポートしています。プロパティ・ファイルは、様々な構成環境、特にスクリプト済アプリケーションまたは埋込みアプリケーションで作業する場合に便利です。詳細は、第A.1.2項「サーバー・コマンドによるプロパティ・ファイルの使用方法」を参照してください。

プロパティ・ファイルに保存可能なオプションは次のとおりです:

- bindDN

- bindPassword

- bindPasswordFile

- certNickname

- continueOnError

- control

- deleteSubtree

- dry-run

- filename

- hostname

- keyStorePassword

- keyStorePasswordFile

- keyStorePath

- ldapVersion

- port

- saslOption
SASLは、プロキシ・サーバー・インスタンスに対してサポートされていません。

- trustAll

- trustStorePassword

- trustStorePasswordFile

- trustStorePath

- useSASLExternal
SASLは、プロキシ・サーバー・インスタンスに対してサポートされていません。

- useSSL

- useStartTLS

- verbose

プロパティ・ファイルのエントリのフォーマットは、次のとおりです:

toolname.propertyname=propertyvalue

例:

ldapdelete.ldapport=12345

A.4.2.12 場所

- UNIXおよびLinux: INSTANCE_DIR/OUD/bin/ldapdelete

- Windows: INSTANCE_DIR\OUD\bat\ldapdelete.bat

A.4.2.13 関連コマンド

- 第A.4.1項「ldapcompare」

- 第A.4.3項「ldapmodify」

- 第A.4.4項「ldappasswordmodify」

- 第A.4.5項「ldapsearch」

A.4.3 ldapmodify

ldapmodifyコマンドは、ディレクトリ・エントリを変更します。

A.4.3.1 シノプシス

ldapmodify [options] [filter] [attributes]

A.4.3.2 説明

ldapmodifyコマンドを使用して、ディレクトリ・サーバーでLDAP変更、追加、削除、およびDN変更操作を実行できます。ディレクトリ・サーバーで実行する操作は、RFC 2849 (http://www.ietf.org/rfc/rfc2849.txt)に説明するように、LDIF変更形式で指定する必要があります。この変更構文では、changetypeキーワードを使用して変更のタイプを示します。

add変更レコードは、LDIFフォームでaddというchangetype値を持つ完全なエントリであるため、わかりやすい例です。例:

dn: uid=john.doe,ou=People,dc=example,dc=com
changetype: add
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: john.doe
givenName: John
sn: Doe
cn: John Doe
mail: john.doe@example.com
userPassword: password

delete変更レコードは、add変更レコードよりもさらに簡単です。addレコードは、エントリDNを示す1行と、その後のdeleteというchangetypeを示す1行で構成されています。例:

dn: uid=john.doe,ou=People,dc=example,dc=com
changetype: delete

modify変更レコードは、バリアント数のために最も複雑な操作です。modify変更レコードはすべてエントリDNで始まり、その後にmodifyというchangetypeが続きます。次の行は、add、delete、またはreplaceのいずれかと、その後に続く属性名(これは変更のタイプと、変更の対象となる属性を示します)で構成されます。変更レコードにはオプションとして、属性値と、その後に変更に使用する値(つまり、属性に追加する値、属性から削除する値、既存の値セットの置換に使用する値)が続く行を1行以上続けることもできます。変更をダッシュのみを含む行で区分し、次の行を新しいadd、delete、またはreplaceのタグで開始し、その後にコロン1つと次の属性名を続け、さらに属性の値を設定することにより、同じmodify操作において1つのエントリに複数の属性変更を加えることができます。例:

dn: uid=john.doe,ou=People,dc=example,dc=com
changetype: modify
replace: description
description: This is the new description for John Doe
-
add: mailAlternateAddress
mailAlternateAddress: jdoe@example.com

DN変更の変更レコードには常にnewRDN要素とdeleteOldRDN要素が含まれている必要があり、オプションとして、ターゲット・エントリに新しい親を指定するためにnewSuperiorコンポーネントを含めることができます。例:

dn: uid=john.doe,ou=People,dc=example,dc=com
changetype: moddn
newRDN: uid=jdoe
deleteOldRDN: 1

ldapmodifyコマンドに引数が指定されていない場合、このコマンドはポート389のループバック・アドレスを使用する未認証の接続を使用してディレクトリ・サーバー・インスタンスとの相互作用を試行し、リクエストされる変更に関する情報が標準入力から読み取られます。この場合はサーバーの認証方法の指定に使用される引数を少なくとも指定する必要があるため、この処理が成功する可能性はほとんどありません。

A.4.3.3 開始する前に

多くのUNIXおよびLinuxオペレーティング・システムには共通のLDAPクライアント・コマンドのインストール済バージョンが用意されており、たとえば、/usr/binディレクトリのldapsearch、ldapmodify、およびldapdeleteなどがあります。使用しているシステムにバージョンがインストールされているかどうかをチェックするには、コマンドwhich ldapmodifyを入力します。このコマンドが値(以下に示します)を返す場合は、$PATHをINSTANCE_DIR/OUD/binディレクトリに更新するか、ディレクトリ・サーバー・インスタンスの別名を作成する必要があります。

$ which ldapmodify (Unix/Linux)
/usr/bin/ldapmodify

A.4.3.4 オプション

ldapmodifyコマンドは、短いフォーム(例: -D bindDN)または同等の長いフォーム(例: --bindDN bindDN)のいずれかのオプションを受け入れます。

A.4.3.5 コマンドのオプション

-a, --defaultAdd

エントリを追加します。changetype要素のないレコードを追加リクエストとして処理します。このオプションは、LDIF変更形式による情報が含まれていない標準LDIFファイルからのエントリの追加に使用できます。

--assertionFilter filter

LDAPアサーション制御(RFC 4528 (http://www.ietf.org/rfc/rfc4528.txt)に定義しています)を使用して検索を実行し、指定されたフィルタに含まれているアサーションがtrueである場合のみ操作を処理することを示します。

-c, --continueOnError

エラーが発生した場合でも処理を続行します。このオプションは、ファイル--filename内で複数の検索フィルタを使用する場合に使用します。処理中にエラーが発生した場合、ディレクトリ・サーバーは次の検索フィルタの処理を続行します。そうでない場合、このコマンドはすべての検索が完了しないうちに終了します。

-f, --filename filename

変更操作中に使用する1つ以上のフィルタが含まれている指定ファイルから変更を読み取ります。LDIFファイルにあるレコードはLDIF変更形式である必要があります(つまり、changetype要素が含まれていること)。ディレクトリ・サーバーに追加するエントリのみがLDIFファイルに含まれている場合、そのファイルは、エントリがchangetype要素を持っていない場合でも、--defaultAddオプションを指定して使用できます。変更レコード間に少なくとも1つの空白行があるかぎり、指定されたファイルに複数の変更を含めることができます。

このオプションが指定されない場合、ldapmodifyコマンドは標準入力から変更情報を読み取ろうとします。これによって、コマンドライン上でターゲット・ユーザーが変更レコードをインタラクティブに指定するか、変更レコードを他のソースからコマンドにパイプ入力することができます。

-J, --control controloid[:criticality[:value|::b64value|:<fileurl]]

ディレクトリ・サーバーに送信された検索リクエストに指定されているコントロールを使用して、検索を実行します。このオプションを使用すると、クライアントが直接サポートできない任意のリクエスト・コントロールを含めることができます。このオプションの値には、次のフォームを使用する必要があります:

oid[: criticality[:value|::b64value|:<fileurl]]

この値の要素は次のとおりです:

- oid。コントロールのOIDを使用します。特定のタイプのコントロールについては、数値OIDのかわりにテキスト名を使用することもできます(検索操作の場合は、DSA IT管理のコントロールに対するmanagedsaitも含まれます)。この要素は必須です。-Jオプションまたはcontrolオプションを使用すると、OIDのかわりに判読可能な名前を使用して、値を必要としないコントロールを参照することができます。これらのOID名は次のとおりです:
accountusableまたはaccountusability: アカウント・ユーザビリティ・リクエスト・コントロールOID: 1.3.6.1.4.1.42.2.27.9.5.8のかわりに使用(値なし)。

authzidまたはauthorizationidentity: 認可IDリクエスト・コントロールOID: 2.16.840.1.113730.3.4.16のかわりに使用(値なし)。

effectiverights: 有効な権限の取得コントロールOID: 1.3.6.1.4.1.42.2.27.9.5.2のかわりに使用(値=認可ID)。

managedsait: DSA ITの管理コントロールOID: 2.16.840.1.113730.3.4.2のかわりに使用(値なし)。

noopまたはno-op: LDAP No-opコントロールOID: 1.3.6.1.4.1.4203.1.10.2のかわりに使用(値なし)。

pwpolicyまたはpassword policy: パスワード・ポリシー・リクエスト・コントロールOID: 1.3.6.1.4.1.42.2.27.8.5.1のかわりに使用(値なし)。

subtreedeleteまたはtreedelete: サブツリー削除リクエスト・コントロールOID: 1.2.840.113556.1.4.805のかわりに使用(値なし)。

- criticality。trueの場合、コントロールをクリティカルとマークする必要があります(つまり、操作がこのコントロールの要件を満たさないかぎり、ディレクトリ・サーバーは操作を処理しません)。falseの場合は、コントロールをクリティカルとマークする必要はありません。このサブコマンドが指定されていない場合、コントロールはクリティカルとマークされません。

- value。コントロールの値を指定します。このフォームは、値を文字列として表記できる場合のみ使用します。これは、::b64valueフォームまたは:< fileurlフォームと連係して使用することはできません。これらのサブコマンドがいずれも指定されていない場合、コントロールには値が設定されません。

- b64value。コントロールの値をbase64でエンコードされたフォームで指定します。このサブコマンドは、:valueフォームまたは:< fileurlフォームと連係して使用することはできません。これらのサブコマンドがいずれも指定されていない場合、コントロールには値が設定されません。

- fileurl。取り込むコントロールの値のあるファイルを参照するURLを指定します。これは、:valueフォームまたは::b64valueフォームと連係して使用することはできません。これらのサブコマンドがいずれも指定されていない場合、コントロールには値が設定されません。
たとえば、値1.3.6.1.4.1.42.2.27.9.5.2:true:dn:uid=dmiller,ou=people,dc=example,dc=comには、OIDが1.3.6.1.4.1.42.2.27.9.5.2であり、クリティカル(true)とマークされ、認可ID dn:uid=dmiller,ou=people,dc=example,dc=comの文字列値のあるクリティカルなコントロールが含まれます。または、次のOID名、effectiverights:true:dn:uid=dmiller、ou=people、dc=example、dc=comが使用できます。

-n, --dry-run

no-opモードで実行します。つまり、発生する内容を報告しますが、実際に検索を実行したり、どの方法でもサーバーと通信することはありません。

--postReadAttributes attrList

LDAP ReadEntry読込み後制御(RFC 4527 (http://www.ietf.org/rfc/rfc4527.txt)に定義するとおり)を使用して、更新直後であるためディレクトリ・サーバーがターゲットのコピーを返すことを指定します。これは、追加、変更、およびDN変更の操作のみに該当します。このオプションの値には、読込み前エントリの表示に含める属性のカンマ区切りリストを指定する必要があります。このリストには、ldapsearchコマンドで返される属性のリストと同じ規則が適用されます(つまり、すべてのユーザー属性に*が使用でき、すべての操作属性に+が使用でき、指定されたオブジェクト・クラス内のすべての属性に@ocnameが使用できるなど)。属性が指定されない場合は(空の引用符で示されます)、すべてのユーザー属性が返されます。

--preReadAttributes attrList

LDAP ReadEntry読込み前制御(RFC 4527 (http://www.ietf.org/rfc/rfc4527.txt)に定義するとおり)を使用して、更新直後であるためディレクトリ・サーバーがターゲットのコピーを返すことを指定します。これは、削除、変更、およびDN変更の操作のみに該当します。このオプションの値には、読込み前エントリの表示に含める属性のカンマ区切りリストを指定する必要があります。このリストには、ldapsearchコマンドで返される属性のリストと同じ規則が適用されます(つまり、すべてのユーザー属性に*が使用でき、すべての操作属性に+が使用でき、指定されたオブジェクト・クラス内のすべての属性に@ocnameが使用できるなど)。属性が指定されない場合は(空の引用符で示されます)、すべてのユーザー属性が返されます。

-Y, --proxyAs authzID

プロキシ設定された認可制御を使用して、操作の対象となるユーザーのIDを指定します。これは、RFC 4370 (http://www.ietf.org/rfc/rfc4370.txt)に定義するとおり、プロキシ認可制御v2を使用します。このオプションの値には、認可IDをdn:の後にターゲット・ユーザーのDNが続くフォーム(たとえば、dn:uid=john.doe,ou=People,dc=example,dc=com)、またはu:の後にユーザー名が続くフォーム(たとえば、u:john.doe)で指定する必要があります。このオプションが指定されない場合、プロキシ認可は使用されません。

A.4.3.6 LDAP接続オプション

-D, --bindDN bindDN

バインドDNを使用してディレクトリ・サーバーを認証します。このオプションは、簡易認証の実行時に使用します。このオプションのデフォルト値はcn=Directory Managerです。SASL認証を使用している場合、または認証が実行されない場合、これは必要ありません。

-E, --reportAuthzID

バインド・リクエストに認可IDリクエスト・コントロール(RFC 3829 (http://www.ietf.org/rfc/rfc3829.txt)に定義するとおり)を使用して、認証完了時にディレクトリ・サーバーが対応する認可IDをクライアントに返すようにします。(認可IDが含まれている行には接頭辞として#文字が使われ、出力をLDIFとして解釈されるようにする場合のコメントにします。)

-h, --hostname address

指定されたホスト名またはIPアドレスのディレクトリ・サーバーに接続します。これが指定されない場合は、localhostのデフォルトのアドレスが使用されます。

-j, --bindPasswordFile bindPasswordFile

ディレクトリ・サーバーに対して認証を受ける際、指定したファイルにバインド・パスワードを使用します。このオプションは、簡易認証と、パスワードに基づくSASLメカニズム(CRAM-MD5、DIGEST-MD5、およびPLAINなど)に使用します。認可が実行されない場合、これは必要ありません。このオプションは、--bindPasswordと同時に使用しないでください。

SASLは、プロキシ・サーバー・インスタンスに対してサポートされていません。

-K, --keyStorePath keyStorePath

SSLまたはStartTLS拡張操作を使用する場合は、セキュアな通信のために、指定されたパスにクライアント・キーストア証明書を使用します。このオプションは、SASL EXTERNAL認証を使用する場合など、クライアントがディレクトリ・サーバーに証明書を提示する必要がある場合のみ必要です。

SASLは、プロキシ・サーバー・インスタンスに対してサポートされていません。

-N, --certNickName certNickName

証明書ベースのクライアント認証に対して指定された証明書を使用します。

-o, --saslOption name = value

SASL認証を実行するときに、指定されたオプションを使用します。複数のSASLオプションを指定するには、オプションごとに1回ずつ、このオプションを複数回使用します。クライアントでのSASL認証の使用方法の詳細は、第20.7項「SASL認証の構成」を参照してください。

SASLは、プロキシ・サーバー・インスタンスに対してサポートされていません。

-p, --port port

指定されたポートでディレクトリ・サーバーに接続します。このオプションが指定されない場合は、デフォルトのポート389が使用されます。

-P, --trustStorePath trustStorePath

SSLまたはStartTLS拡張操作を使用する場合は、セキュアな通信のために、指定されたパスにクライアント・トラスト・ストア証明書を使用します。このオプションは、--trustAllを使用している場合は必要ありません。ただし、本番環境で作業する場合はトラスト・ストアを使用する必要があります。

-q, --useStartTLS

ディレクトリ・サーバーと通信する際、StartTLS拡張操作を使用します。このオプションは、--useSSLと同時に使用しないでください。

-r, --useSASLExternal

認証に対してSASL EXTERNALメカニズムを使用します。このメカニズムでは、クライアントがディレクトリ・サーバーに提示したSSL証明書を使用してクライアントを識別しようと試行されます。このオプションを使用する場合は、--keyStorePathオプションも同時に使用してクライアント・キーストアへのパスを指定し、--useSSLオプションまたは--useStartTLSオプションを使用してサーバーとのセキュアな通信チャネルを確立する必要があります。

SASLは、プロキシ・サーバー・インスタンスに対してサポートされていません。

--trustStorePassword trustStorePassword

クライアント・トラスト・ストアの証明書へのアクセスに必要なパスワードを使用します。このオプションは、--trustStorePathを使用していて、指定したトラスト・ストアがコンテンツへのアクセスにパスワードを必要とする場合のみ必須です(ほとんどのトラスト・ストアでは必要とされません)。このオプションは、--trustStorePasswordFileと同時に使用しないでください。

-u, --keyStorePasswordFile keyStorePasswordFile

クライアント・キーストアの証明書にアクセスするために、指定されたファイルでパスワードを使用します。このオプションは、--keyStorePathを使用する場合のみ必須です。このオプションは、--keyStorePasswordと同時に使用しないでください。

-U, --trustStorePasswordFile trustStorePasswordFile

クライアント・トラスト・ストアの証明書にアクセスするために、指定されたファイルでパスワードを使用します。このオプションは、--trustStorePathを使用していて、指定したトラスト・ストアがコンテンツへのアクセスにパスワードを必要とする場合のみ必須です(ほとんどのトラスト・ストアでは必要とされません)。このオプションは、--trustStorePasswordと同時に使用しないでください。

-V, --ldapVersion version

クライアントがディレクトリ・サーバーと通信する際に使用する必要のあるLDAPプロトコルのバージョンを設定します。この値には、2 (LDAPv2通信の場合)または3 (LDAPv3の場合)のいずれかを設定する必要があります。このオプションが指定されない場合、クライアントはLDAPv3を使用します。

-w, --bindPassword bindPassword

ディレクトリ・サーバーに対して認証を受ける際、バインド・パスワードを使用します。このオプションは、簡易認証と、パスワードに基づくSASLメカニズムに使用できます。このオプションは、--bindPasswordFileと同時に使用しないでください。パスワードの入力を要求するには、-w -を入力します。

SASLは、プロキシ・サーバー・インスタンスに対してサポートされていません。

-W, --keyStorePassword keyStorePassword

クライアント・キーストアの証明書へのアクセスに必要なパスワードを使用します。このオプションは、--keyStorePathを使用する場合のみ必須です。このオプションは、--keyStorePasswordFileと同時に使用しないでください。

-X, --trustAll

SSLまたはStartTLSのネゴシエーション中にディレクトリ・サーバーによって提示される可能性のある証明書をすべて信頼します。このオプションは便宜的に、かつテストの目的で使用できますが、セキュリティ上の理由から、トラスト・ストアを使用してクライアントがサーバーの証明書を受け入れるかどうかを判別する必要があります。

-Z, --useSSL

ディレクトリ・サーバーと通信する際、SSLを使用します。SSLを使用する場合は、--portオプションを使用してサーバーのセキュア・ポートを指定する必要があります。

A.4.3.7 コマンド入力/出力オプション

--noPropertiesFile

デフォルトのコマンドライン・オプションの取得にプロパティ・ファイルが使用されないことを示します。

--propertiesFilePath propertiesFilePath

デフォルトのコマンドライン・オプションが含まれているプロパティ・ファイルへのパスを指定します。

-v, --verbose

冗長モードで実行して、プロセス情報と診断情報を標準出力で表示します。

A.4.3.8 一般オプション

-?, -H, --help

このコマンドに対するコマンドライン使用情報を表示し、コマンドの実行を試みないで終了します。

-V, --version

ディレクトリ・サーバーのバージョン情報を表示します。

A.4.3.9 例

次の例は、ldapmodifyコマンドの使用方法を示しています。

例A-127 エントリの追加

次のLDIFファイルには従業員のエントリが含まれています:

dn: uid=Marcia Garza,ou=People,dc=example,dc=com
cn: Marcia Garza
sn: Garza
givenName: Marcia
objectClass: person
objectClass: inetOrgPerson
objectClass: top
objectClass: organizationalPerson
ou: Accounting
ou: People

次のコマンドでは、ホスト名(-h)、ポート(-p)、バインドDN (-D)、バインド・パスワード(-w)を指定して、ファイル(-f)から変更を読み取り、エントリ(-a)をデータベースに追加します。Windowsプラットフォームの場合は、LDIFファイルへのパス(たとえば、-f \temp\add_entry.ldif)を指定します。

$ ldapmodify -h hostname -p 1389 -D "cn=Directory Manager" -j pwd-file \
-a -f /usr/local/add_entry.ldif

例A-128 属性のエントリへの追加

次のLDIFファイルでは、telephonenumber属性を追加してエントリを変更します:

dn: uid=Marcia Garza,ou=People,dc=example,dc=com
changetype: modify
add: telephonenumber
telephonenumber: +1 408 555 8283

次のコマンドでは、ホスト名(-h)、ポート(-p)、バインドDN (-D)、バインド・パスワード(-w)を指定して、ファイル(-f)から変更を読み取り、属性をエントリに追加します。Windowsプラットフォームの場合は、LDIFファイルへのパス(例:

-f \temp\add_attribute.ldif)を指定します。

$ ldapmodify -h hostname -p 1389 -D "cn=Directory Manager" -j pwd-file \
-f /usr/local/add_attribute.ldif

例A-129 属性値の変更

次のLDIFファイルでは、telephonenumber属性の値を変更します:

dn: uid=Marcia Garza,ou=People,dc=example,dc=com
changetype: modify
replace: telephonenumber
telephonenumber: +1 408 555 6456

次のコマンドでは、ホスト名(-h)、ポート(-p)、バインドDN (-D)、バインド・パスワード(-w)を指定して、ファイル(-f)から変更を読み取り、属性の値を変更します。Windowsプラットフォームの場合は、LDIFファイルへのパス(たとえば、-f \temp\modify_attribute.ldif)を指定します。

$ ldapmodify -h hostname -p 1389 -D "cn=Directory Manager" -j pwd-file \
-f /usr/local/modify_attribute.ldif

例A-130 複数の属性の変更

次のLDIFファイルには、エントリに対する複数の変更が含まれています:

dn: uid=Marcia Garza,ou=People,dc=example,dc=com
changetype: modify
replace: telephonenumber
telephonenumber: +1 408 555 6465
-
add: facsimiletelephonenumber
facsimiletelephonenumber: +1 408 222 4444
-
add: l
l: Sunnyvale

次のコマンドでは、ホスト名(-h)、ポート(-p)、バインドDN (-D)、バインド・パスワード(-w)を指定して、ファイル(-f)から変更を読み取り、データベースに加えられた変更を処理します。Windowsプラットフォームの場合は、LDIFファイルへのパス(たとえば、-f \temp\mod_attribute.ldif)を指定します:

$ ldapmodify -h hostname -p 1389 -D "cn=Directory Manager" -j pwd-file \
-f /usr/local/mod_attribute.ldif

例A-131 コマンドラインからの属性の削除

次のコマンドでは、ホスト名(-h)、ポート(-p)、バインドDN (-D)、バインド・パスワード(-w)を指定して、エントリのfacsimiletelephonenumber属性を削除します。このコマンドはコマンドラインから実行されているため、dn、changetype、変更操作を入力し、[Control]キーと[D]キー(UNIX、Linux)または[Control]キーと[Z]キー(Windows)を押して処理します:

$ ldapmodify -h hostname -p 1389 -D "cn=Directory Manager" -j pwd-file
dn: uid=Marcia Garza,ou=People,dc=example,dc=com
changetype: modify
delete: facsimiletelephonenumber
(Press Control-D for Unix, Linux)
(Press Control-Z for Windows)

例A-132 コマンドラインからのエントリの削除

次のコマンドでは、ホスト名(-h)、ポート(-p)、バインドDN (-D)、バインド・パスワード(-w)を指定して、エントリを削除します。このコマンドはコマンドラインから実行されているため、dn、changetypeを入力し、[Control]キーと[D]キー(UNIX、Linux)または[Control]キーと[Z]キー(Windows)を押して処理します:

$ ldapmodify -h hostname -p 1389 -D "cn=Directory Manager" -j pwd-file
dn: uid=Marcia Garza,ou=People,dc=example,dc=com
changetype: delete
(Press Control-D for Unix, Linux)
(Press Control-Z for Windows)

例A-133 サーバー認証でのldapmodifyの使用

次のコマンドは、-P SSLオプションを使用してサーバー認証による変更を実行します。次のコマンドでは、ホスト名(-h)、SSLポート(-p)、ベースDN (-b)、バインドDN (-D)、バインド・パスワード(-w)、トラスト・ストア・ファイル・パス(-P)、および変更が含まれているLDIFファイル(-f)を指定します。Windowsプラットフォームの場合は、変更ファイルのパス(たとえば、-f \temp\myldif.ldif)とトラスト・ストア・ファイルのパス(たとえば、-P \temp\certs\cert.db)を指定します:

$ ldapmodify -h hostname -p 1636 -f /home/local/myldif.ldif \
-D "cn=Directory Manager" -j pwd-file \
-P /home/scarter/certs/cert.db

例A-134 クライアント認証でのldapmodifyの使用

次のコマンドは、-P SSLオプションを使用してクライアント認証による変更を実行します。このコマンドは、SSLポート(-p)を指定してSSL (-Z)を使用し、トラスト・ストア・ファイル・パス(-P)、証明書ニックネーム(-N)、キーストア・ファイル・パス(-K)、キーストア・パスワード(-W)および変更が含まれているLDIFファイル(-f)を指定します。Windowsプラットフォームの場合は、変更ファイルのパス(たとえば、-f \temp\myldif.ldif)、トラスト・ストア・ファイルのパス(たとえば、-P \certs\cert.db)、およびキーストア・ファイルのパス(たとえば、-K \security\key.db)を指定します:

$ ldapmodify -h hostname -p 1636 -f /home/local/myldif.ldif \
-Z -P /home/scarter/security/cert.db -N "sccert" \
-K /home/scarter/security/key.db -W keypassword

A.4.3.10 終了コード

終了コード0は、操作が正常に終了したことを示します。ゼロ以外の終了コードは、処理中にエラーが発生したことを示します。

A.4.3.11 CLIプロパティ・ファイルの使用方法

ディレクトリ・サーバーでは、ldapmodifyコマンドとともに使用されるデフォルトのオプション値を渡すプロパティ・ファイルの使用をサポートしています。プロパティ・ファイルは、様々な構成環境、特にスクリプト済アプリケーションまたは埋込みアプリケーションで作業する場合に便利です。詳細は、第A.1.2項「サーバー・コマンドによるプロパティ・ファイルの使用方法」を参照してください。

プロパティ・ファイルに保存可能なオプションは次のとおりです:

- assertionFilter

- bindDN

- bindPassword

- bindPasswordFile

- certNickname

- continueOnError

- control

- dry-run

- filename

- hostname

- keyStorePassword

- keyStorePasswordFile

- keyStorePath

- ldapVersion

- port

- postReadAttributes

- preReadAttributes

- proxyAs

- reportAuthzID

- saslOption
SASLは、プロキシ・サーバー・インスタンスに対してサポートされていません。

- trustAll

- trustStorePassword

- trustStorePasswordFile

- trustStorePath

- useSASLExternal
SASLは、プロキシ・サーバー・インスタンスに対してサポートされていません。

- useSSL

- useStartTLS

- verbose

プロパティ・ファイルのエントリのフォーマットは、次のとおりです:

toolname.propertyname=propertyvalue

例:

ldapmodify.ldapport=12345

A.4.3.12 場所

- UNIXおよびLinux: INSTANCE_DIR/OUD/bin/ldapmodify

- Windows: INSTANCE_DIR\OUD\bat\ldapmodify.bat

A.4.3.13 関連コマンド

- 第A.4.1項「ldapcompare」

- 第A.4.2項「ldapdelete」

- 第A.4.4項「ldappasswordmodify」

- 第A.4.5項「ldapsearch」

A.4.4 ldappasswordmodify

ldappasswordmodifyコマンドは、LDAPパスワードを変更します。

A.4.4.1 シノプシス

ldappasswordmodify options

A.4.4.2 説明

ldappasswordmodifyコマンドは、RFC 3062 (http://www.ietf.org/rfc/rfc3062.txt)に定義するように、LDAPパスワード変更拡張操作を使用したユーザー・パスワードの変更またはリセットに使用できます。

このメカニズムによるユーザー・パスワードの変更は、パスワード属性を対象とした単純なLDAP変更操作に比べて、次に示すように多くの利点を備えています:

- 自分のパスワードの変更。この機能がユーザーのパスワード・ポリシーで使用可能である場合に、このコマンドによってユーザーは自分のパスワードを、有効期限後であっても変更することができます。

- クリアテキスト・パスワードの指定。このコマンドは、ユーザーのIDをさらに検証するために、現在のパスワードのクリアテキスト・バージョンを提供するメカニズムとして機能します。

- 認可IDの使用。ユーザーのパスワードを変更する際、フルDNに加えて認可ID(接頭辞dn:またはu:が付きます)を使用することでユーザーを指定できます。

- パスワードの生成。新しいパスワードが指定されない場合、この機能がユーザーのパスワード・ポリシーで使用可能になっていると、サーバーはユーザーに対して新しいパスワードを生成できます。

A.4.4.3 オプション

ldappasswordmodifyコマンドは、短いフォーム(例: -D bindDN)または同等の長いフォーム(例: --bindDN bindDN)のいずれかのオプションを受け入れます。

A.4.4.4 コマンドのオプション

-a, --authzID authzID

変更するパスワードを持つユーザーに対して認可IDを指定します。認可IDには、dn:の後にターゲット・ユーザーのDNが続くフォーム、またはu:の後にターゲット・ユーザーのユーザー名が続くフォームが使用できます。このオプションが指定されない場合、認可IDはリクエストに含まれず、認証ユーザーのパスワードが変更されます。このオプションは、--provideDNForAuthzIDオプションと同時に使用しないでください。

-A, --provideDNForAuthzID

バインドDNをパスワード変更操作の認可IDとして使用することを指定します。このオプションは、--authzIDオプションと同時に使用しないでください。

-c, --currentPassword currentPassword

ユーザーの現在のパスワードを指定します。このオプションは、--currentPasswordFileと同時に使用しないでください。認証が実行されない場合、たとえば、ユーザーが有効期限の切れた自分のパスワードを変更しようとする場合などは、ユーザーの現在のパスワードを指定する必要があります。バインド・パスワードが指定されている場合でも、パスワード・ポリシー構成に基づいているサーバーでパスワードが必要になることがあります。

-C, --currentPasswordFile currentPasswordFile

指定されたファイルから現在のパスワードを読み取ります。これは、--currentPasswordと同時に使用しないでください。認証が実行されない場合、たとえば、ユーザーが有効期限の切れた自分のパスワードを変更しようとする場合などは、ユーザーの現在のパスワードを指定する必要があります。バインド・パスワードが指定されている場合でも、パスワード・ポリシー構成に基づいているサーバーでパスワードが必要になることがあります。

-J, --control controloid[:criticality[:value|::b64value|:<fileurl]]

ディレクトリ・サーバーに送信された検索リクエストに指定されているコントロールを使用して、検索を実行します。このオプションを使用すると、クライアントが直接サポートできない任意のリクエスト・コントロールを含めることができます。このオプションの値には、次のフォームを使用する必要があります:

oid[:criticality[:value|::b64value|:<fileurl]]

この値の要素は次のとおりです:

- oid。コントロールのOIDを使用します。特定のタイプのコントロールについては、数値OIDのかわりにテキスト名を使用することもできます(検索操作の場合は、DSA IT管理のコントロールに対するmanagedsaitも含まれます)。この要素は必須です。-Jオプションまたはcontrolオプションを使用すると、OIDのかわりに判読可能な名前を使用して、値を必要としないコントロールを参照することができます。これらのOID名は次のとおりです:
accountusableまたはaccountusability: アカウント・ユーザビリティ・リクエスト・コントロールOID: 1.3.6.1.4.1.42.2.27.9.5.8のかわりに使用(値なし)。

authzidまたはauthorizationidentity: 認可IDリクエスト・コントロールOID: 2.16.840.1.113730.3.4.16のかわりに使用(値なし)。

effectiverights: 有効な権限の取得コントロールOID: 1.3.6.1.4.1.42.2.27.9.5.2のかわりに使用(値=認可ID)。

managedsait: DSA ITの管理コントロールOID: 2.16.840.1.113730.3.4.2のかわりに使用(値なし)。

noopまたはno-op: LDAP No-opコントロールOID: 1.3.6.1.4.1.4203.1.10.2のかわりに使用(値なし)。

pwpolicyまたはpassword policy: パスワード・ポリシー・リクエスト・コントロールOID: 1.3.6.1.4.1.42.2.27.8.5.1のかわりに使用(値なし)。

subtreedeleteまたはtreedelete: サブツリー削除リクエスト・コントロールOID: 1.2.840.113556.1.4.805のかわりに使用(値なし)。

- criticality。trueの場合、コントロールをクリティカルとマークする必要があります(つまり、操作がこのコントロールの要件を満たさないかぎり、ディレクトリ・サーバーは操作を処理しません)。falseの場合は、コントロールをクリティカルとマークする必要はありません。このサブコマンドが指定されていない場合、コントロールはクリティカルとマークされません。

- value。コントロールの値を指定します。このフォームは、値を文字列として表記できる場合のみ使用します。これは、::b64valueフォームまたは:< fileurlフォームと連係して使用することはできません。これらのサブコマンドがいずれも指定されていない場合、コントロールには値が設定されません。

- b64value。コントロールの値をbase64でエンコードされたフォームで指定します。このサブコマンドは、:valueフォームまたは:< fileurlフォームと連係して使用することはできません。これらのサブコマンドがいずれも指定されていない場合、コントロールには値が設定されません。

- fileurl。取り込むコントロールの値のあるファイルを参照するURLを指定します。これは、:valueフォームまたは::b64valueフォームと連係して使用することはできません。これらのサブコマンドがいずれも指定されていない場合、コントロールには値が設定されません。

たとえば、値1.3.6.1.4.1.42.2.27.9.5.2:true:dn:uid=dmiller,ou=people,dc=example,dc=comには、OIDが1.3.6.1.4.1.42.2.27.9.5.2であり、クリティカル(true)とマークされ、認可ID dn:uid=dmiller,ou=people,dc=example,dc=comの文字列値のあるクリティカルなコントロールが含まれます。または、次のOID名、effectiverights:true:dn:uid=dmiller、ou=people、dc=example、dc=comが使用できます。

-n, --newPassword newPassword

ターゲット・ユーザーに割り当てる新しいパスワードを指定します。このオプションは、--newPasswordFileと同時に使用しないでください。これらのオプションがいずれも指定されていない場合、パスワード・ジェネレータがユーザーのパスワード・ポリシーで構成されていると、サーバーはユーザーに対して新しいパスワードを自動的に生成します。

-N, --newPasswordFile newPasswordFile

ターゲット・ユーザーに割り当てる指定ファイルから新しいパスワードを読み取ります。このオプションは、--newPasswordと同時に使用しないでください。これらのオプションがいずれも指定されていない場合、パスワード・ジェネレータがユーザーのパスワード・ポリシーで構成されていると、サーバーはユーザーに対して新しいパスワードを自動的に生成します。

A.4.4.5 LDAP接続オプション

--certNickname nickname

証明書ベースのクライアント認証の証明書を使用します。

-D, --bindDN bindDN

簡易認証を介してディレクトリ・サーバーにバインドするときにDNを使用します。このオプションが指定されない場合は、--authzIDオプションを使用してターゲット・ユーザーの認可IDを指定し、--currentPasswordオプションまたは--currentPasswordFileオプションのいずれかを指定してユーザーの現在のパスワードを指定する必要があります。(この使用モードは、ユーザーが自分のパスワードを有効期限後に変更する場合に必要です。)

-h, --hostname address

指定されたホスト名またはIPアドレスのディレクトリ・サーバーに接続します。これが指定されない場合は、localhostのデフォルトのアドレスが使用されます。

-j, --bindPasswordFile bindPasswordFile

ディレクトリ・サーバーに対して認証を受ける際、指定したファイルにバインド・パスワードを使用します。このオプションは、簡易認証と、パスワードに基づくSASLメカニズム(CRAM-MD5、DIGEST-MD5、およびPLAINなど)に使用します。認可が実行されない場合、これは必要ありません。このオプションは、--bindPasswordと同時に使用しないでください。

SASLは、プロキシ・サーバー・インスタンスに対してサポートされていません。

-K, --keyStorePath keyStorePath

SSLまたはStartTLS拡張操作を使用する場合は、セキュアな通信のために、指定されたパスにクライアント・キーストア証明書を使用します。このオプションは、SASL EXTERNAL認証を使用する場合など、クライアントがディレクトリ・サーバーに証明書を提示する必要がある場合のみ必要です。

SASLは、プロキシ・サーバー・インスタンスに対してサポートされていません。

-o, --saslOption name=value

SASL認証を実行するときに、指定されたオプションを使用します。複数のSASLオプションを指定するには、オプションごとに1回ずつ、このオプションを複数回使用します。詳細は、第20.6項「SASL認証の使用方法」を参照してください。

-p, --port port

指定されたポートでディレクトリ・サーバーに接続します。このオプションが指定されない場合は、デフォルトのポート389が使用されます。

-P, --trustStorePath trustStorePath

SSLまたはStartTLS拡張操作を使用する場合は、セキュアな通信のために、指定されたパスにクライアント・トラスト・ストア証明書を使用します。このオプションは、--trustAllを使用している場合は必要ありません。ただし、本番環境で作業する場合はトラスト・ストアを使用する必要があります。

-q, --useStartTLS

ディレクトリ・サーバーと通信する際、StartTLS拡張操作を使用します。このオプションは、--useSSLと同時に使用しないでください。

--trustStorePassword trustStorePassword

クライアント・トラスト・ストアの証明書へのアクセスに必要なパスワードを使用します。このオプションは、--trustStorePathを使用していて、指定したトラスト・ストアがコンテンツへのアクセスにパスワードを必要とする場合のみ必須です(ほとんどのトラスト・ストアでは必要とされません)。このオプションは、--trustStorePasswordFileと同時に使用しないでください。

-u, --keyStorePasswordFile keyStorePasswordFile

クライアント・キーストアの証明書にアクセスするために、指定されたファイルでパスワードを使用します。このオプションは、--keyStorePathを使用する場合のみ必須です。このオプションは、--keyStorePasswordと同時に使用しないでください。

-U, --trustStorePasswordFile trustStorePasswordFile

クライアント・トラスト・ストアの証明書にアクセスするために、指定されたファイルでパスワードを使用します。このオプションは、--trustStorePathを使用していて、指定したトラスト・ストアがコンテンツへのアクセスにパスワードを必要とする場合のみ必須です(ほとんどのトラスト・ストアでは必要とされません)。このオプションは、--trustStorePasswordと同時に使用しないでください。

-w, --bindPassword bindPassword

ディレクトリ・サーバーに対して認証を受ける際、バインド・パスワードを使用します。このオプションは、簡易認証と、パスワードに基づくSASLメカニズムに使用できます。このオプションは、--bindPasswordFileと同時に使用しないでください。パスワードの入力を要求するには、-w -を入力します。

SASLは、プロキシ・サーバー・インスタンスに対してサポートされていません。

-W, --keyStorePassword keyStorePassword

クライアント・キーストアの証明書へのアクセスに必要なパスワードを使用します。このオプションは、--keyStorePathを使用する場合のみ必須です。このオプションは、--keyStorePasswordFileと同時に使用しないでください。

-X, --trustAll

SSLまたはStartTLSのネゴシエーション中にディレクトリ・サーバーによって提示される可能性のある証明書をすべて信頼します。このオプションは便宜的に、かつテストの目的で使用できますが、セキュリティ上の理由から、トラスト・ストアを使用してクライアントがサーバーの証明書を受け入れるかどうかを判別する必要があります。

-Z, --useSSL

ディレクトリ・サーバーと通信する際、Secure Sockets Layerを使用します。SSLを使用する場合は、--portオプションを使用してサーバーのセキュア・ポートを指定する必要があります。

A.4.4.6 コマンド入力/出力オプション

--noPropertiesFile

デフォルトのコマンドライン・オプションの取得にプロパティ・ファイルが使用されないことを示します。

--propertiesFilePath propertiesFilePath

デフォルトのコマンドライン・オプションが含まれているプロパティ・ファイルへのパスを指定します。

A.4.4.7 一般オプション

-?, -H, --help

このコマンドに対するコマンドライン使用情報を表示し、コマンドの実行を試みないで終了します。

-V, --version

ディレクトリ・サーバーのバージョン情報を表示します。

A.4.4.8 例

次の例は、ldappasswordmodifyコマンドの使用方法を示しています。

例A-135 ユーザー・パスワードの変更

次のコマンドでは、ポート1389 (-p)を使用してホスト(-h)に接続し、管理者の認可ID uid=abergin (-a)を指定し、ユーザーの現在のパスワード・ファイル(-C)を指定して、それを新しいパスワード・ファイル(-N)で指定された新しいものに変更します。Windowsプラットフォームの場合は、現在のパスワードと新しいパスワードがそれぞれ存在しているファイル・パスを使用します。たとえば、-C \temp\currentPasswordFileおよび-N \temp\newPasswordFileを使用します。

$ ldappasswordmodify -h hostname -p 1389 \
-a "dn:uid=abergin,ou=People,dc=example,dc=com" \
-C /tmp/currentPasswordFile -N /tmp/newPasswordFile

The LDAP password modify operation was successful

例A-136 別のユーザーのパスワードの変更および生成

次のコマンドでは、ポート1389 (-p)を使用してホスト(-h)に接続し、バインドDN (-D)を指定し、バインド・パスワード・ファイル(-j)を指定して、簡易認証によって接続している別のユーザー(-a)のパスワードを変更および生成します。Windowsプラットフォームの場合は、バインド・パスワード・ファイルが常駐しているファイル(たとえば、-j \temp\bindPasswordFile)を使用します。

$ ldappasswordmodify -h hostname -p 1389 \
-D "cn=Directory Manager" -j /tmp/bindPasswordFile \
-a "dn:uid=abergin,ou=People,dc=example,dc=com"

The LDAP password modify operation was successful
Generated Password:  blb44hjm

例A-137 別のユーザーのパスワードの変更

次のコマンドでは、ポート1389 (-p)を使用してホスト(-h)に接続し、バインドDN (-D)を指定し、バインド・パスワード・ファイル(-j)を指定して、簡易認証によって接続している別のユーザー(-a)のパスワードを新しいパスワード(-N)に変更します。Windowsプラットフォームの場合は、バインド・パスワード・ファイル(たとえば、-j \temp\bindPasswordFile)と新しいパスワード・ファイル(たとえば、-N \temp\newPassword)を指定します。

$ ldappasswordmodify -h hostname -p 1389 \
-D "cn=Directory Manager" -j /tmp/bindPasswordFile \
-a "dn:uid=abergin,ou=People,dc=example,dc=com" -N /tmp/newPassword

The LDAP password modify operation was successful

A.4.4.9 終了コード

終了コード0は、操作が正常に終了したことを示します。ゼロ以外の終了コードは、処理中にエラーが発生したことを示します。

A.4.4.10 CLIプロパティ・ファイルの使用方法

ディレクトリ・サーバーでは、ldappasswordmodifyコマンドとともに使用されるデフォルトのオプション値を渡すプロパティ・ファイルの使用をサポートしています。プロパティ・ファイルは、様々な構成環境、特にスクリプト済アプリケーションまたは埋込みアプリケーションで作業する場合に便利です。詳細は、第A.1.2項「サーバー・コマンドによるプロパティ・ファイルの使用方法」を参照してください。

プロパティ・ファイルに保存可能なオプションは次のとおりです:

- authzID

- bindDN

- bindPassword

- bindPasswordFile

- currentPassword

- currentPasswordFile

- control

- hostname

- keyStorePassword

- keyStorePasswordFile

- keyStorePath

- newPassword

- newPasswordFile

- port

- provideDNForAuthzID

- trustAll

- trustStorePassword

- trustStorePasswordFile

- trustStorePath

- useSSL

- useStartTLS

プロパティ・ファイルのエントリのフォーマットは、次のとおりです:

toolname.propertyname=propertyvalue

例:

ldappasswordmodify.ldapport=12345

A.4.4.11 場所

- UNIXおよびLinux: INSTANCE_DIR/OUD/bin/ldappasswordmodify

- Windows: INSTANCE_DIR\OUD\bat\ldappasswordmodify.bat

A.4.4.12 関連コマンド

- 第A.4.1項「ldapcompare」

- 第A.4.2項「ldapdelete」

- 第A.4.3項「ldapmodify」

- 第A.4.5項「ldapsearch」

A.4.5 ldapsearch

ldapsearchコマンドは、ディレクトリ・サーバーのエントリを検索します。

A.4.5.1 シノプシス

ldapsearch [options] [filter] [attributes]

A.4.5.2 説明

ldapsearchコマンドは、ディレクトリ・サーバーへの検索リクエストの入力に使用できます。このコマンドでは、ディレクトリ・サーバーへの接続を開き、それにバインドして、検索フィルタとスコープ要件を満たすすべてのエントリを、指定されたベースDNから順に返します。また、認証、制御、セキュアな通信メカニズムなど、ディレクトリ・サーバーのその他のコンポーネントのテストにも使用できます。

--filenameオプションを使用して1つ以上の検索フィルタが含まれているファイルを指定した場合は、検索フィルタをオプションとして含めないようにしてください。後続オプションはすべて、リクエストされた属性として解釈されます。

エントリの名前と属性にsn、givenName、uid、およびtitleなどの非ASCII文字が使われている場合、ldapsearchコマンドの実行によって返される非ASCII文字は印刷中に抑制されます。base64コマンドを実行して、Base64でエンコードされた文字列をデコードする必要があります。

特定の属性がリクエストされていない場合は、すべてのユーザー属性(つまり、操作属性以外のすべての属性)が返されます。1つ以上の属性名がリストされる場合は、返された属性のみがエントリに含まれます。

A.4.5.3 開始する前に

多くのUNIXおよびLinuxオペレーティング・システムには共通のLDAPクライアント・コマンドのインストール済バージョンが用意されており、たとえば、/usr/binディレクトリのldapsearch、ldapmodify、およびldapdeleteなどがあります。使用しているシステムにバージョンがインストールされているかどうかをチェックするには、コマンドwhich ldapsearchを入力します。このコマンドが値(以下に示します)を返す場合は、$PATHをディレクトリ・サーバーのインストール・ディレクトリに更新するか、ディレクトリ・サーバー・インスタンスの別名を作成する必要があります。

$ which ldapsearch (Unix/Linux)
/usr/bin/ldapsearch

A.4.5.4 オプション

ldapsearchコマンドは、短いフォーム(例: -b baseDN)または同等の長いフォーム(例: --baseDN baseDN)のいずれかのオプションを受け入れます。

A.4.5.5 コマンドのオプション

-a, --dereferencePolicy dereferencePolicy

検索時の別名の間接参照ポリシーを指定します。別名の間接参照により、別のオブジェクトをポイントするようにエントリを設定できます。このオプションが指定されない場合は、デフォルトのneverが使用されます。可能な値は次のとおりです:

- always: ベースDNの検出時とベースDNより下の検索時の両方で別名を間接参照します。

- find: ベースDNの検出時に別名を間接参照します。

- never: 別名の間接参照を行いません(デフォルト)。

- search: ベースDNより下の検索時に別名を間接参照しますが、ベースDNの検出時には実行しません。

-A, --typesOnly

一致するエントリに属性名を含める検索を実行しますが、属性値は含めません。このオプションが指定されない場合は、属性名と属性値の両方が一致エントリに含まれます。

--assertionFilter filter

LDAPアサーション制御(RFC 4528 (http://www.ietf.org/rfc/rfc4528.txt)に定義しています)を使用して検索を実行し、指定されたフィルタに含まれているアサーションがtrueである場合のみ操作を処理することを示します。

-b, --baseDN baseDN

検索操作に使用するbase DNを指定します。--filenameオプションを使用して複数のフィルタを含むファイルが指定されている場合、このベースDNはすべての検索に使用されます。これは必須オプションです。null値("")を持つベースDNが指定されている場合、サーバーはルートDSEエントリを返します。

-c, --continueOnError

エラーが発生した場合でも処理を続行します。このオプションは、ファイル(--filename)内で複数の検索フィルタを使用する場合に使用します。処理中にエラーが発生した場合、サーバーは次の検索フィルタの処理を続行します。そうでない場合、このコマンドはすべての検索が完了しないうちに終了します。

-C, --persistentSearch ps[:changetype[:changesonly[:entrychangecontrols]]]

検索リクエストに永続検索制御(draft-ietf-ldapext-psearch.txt (https://opends.dev.java.net/public/standards/draft-ietf-ldapext-psearch.txt)に定義)を使用して、指定された検索基準に一致するエントリに加えられた変更に関する情報を取得します。このオプションの値には、次のフォームを使用する必要があります:

ps[:changetype[:changesonly [:entrychangecontrols]]]

この値の要素は次のとおりです:

- ps: 必須演算子。

- changetype: クライアントが通知の受信を必要とする変更のタイプを指定します。これはadd、del、mod、またはmoddnのいずれでも可能であり、すべての変更タイプを登録するにはallが指定でき、あるいは、複数の特定の変更タイプを登録するにはカンマ区切りリストが指定できます。この要素が指定されない場合、デフォルトとしてall変更タイプが含まれます。

- changesonly: trueの場合、クライアントには検索登録後に一致エントリに加えられる変更のみが通知されます。falseの場合、ディレクトリ・サーバーは、ディレクトリ・サーバー内で指定された検索基準に一致する既存のエントリをすべて送信します。この要素が指定されない場合、デフォルトとして、検索が登録された後に生じた更新のエントリのみが返されます。

- entrychangecontrols: trueの場合、ディレクトリ・サーバーは、変更の結果としてクライアントに送信されたエントリにエントリ変更通知制御を含めます。falseの場合、エントリ変更通知制御は含まれません。この要素が指定されない場合、デフォルトとしてエントリ変更通知制御が含まれます。

たとえば、値ps:add,del:true:trueは、永続検索が登録された後に追加または削除された、検索基準に一致するエントリのみを返し、これらのエントリにはエントリ変更通知制御が含まれます。

--countEntries

ディレクトリ・サーバーによって返された一致エントリの総数を表示します。--filenameオプションを使用して複数の検索フィルタが含まれているファイルへのパスを指定した場合は、すべての検索に関して一致エントリの総数が表示されます。

-e, --getEffectiveRightsAttribute attribute

指定された属性に対する有効権限を返します。このオプションは、通常であればエントリの検索結果に表示されない属性の指定に使用できます。たとえば、このオプションを使用して、エントリ内に現在存在しない属性を追加する権限をユーザーが持っているかどうかを判別できます。-eオプションには、--getEffectiveRightsAuthzidオプションまたは-gオプションが必須です。

-f, --filename filename

検索操作を処理する際に使用する1つ以上のフィルタが含まれているファイルへのパスを指定します。ファイルに複数のフィルタが含まれている場合は、1行に1つのフィルタが表示されるようにファイルを構成する必要があります。検索は、同じディレクトリ・サーバーとの接続を使用して、ファイルに表示される順序で実行されます。このオプションを使用する場合、後続オプションはすべて別個の属性として処理されます。そうでない場合は、最初の後続オプションを検索フィルタにする必要があります。

-g, --getEffectiveRightsAuthzid authzid

指定されたauthzidでバインドしているユーザーの有効権限を表示します。このオプションは-eオプションを指定して使用できますが、-Jオプションを指定して使用することはできません。

-G, --virtualListView before:after:index:count|before:after:value

検索結果合計の一部を表示する仮想リスト表示を取得します。次の2つのパターンのいずれかを使用して、仮想リスト表示のサイズを指定します:

- before:after:index:count: ターゲット・エントリと、ターゲット・エントリの前およびターゲット・エントリの後の指定されたエントリ数を返します。ターゲット・エントリは、indexオプションおよびcountオプションに依存します。countオプションに指定できる値は次のとおりです:
count=0。ターゲット・エントリは、指定されたindexの位置にあるエントリで、1から始まり、ソート結果の全体リストに相対しています。

count=1。ターゲット・エントリは、ソート結果のリストにある最初のエントリです。

count>1。ターゲット・エントリは、分数index/countによって表示されるリストの部分にある最初のエントリです。リスト内の最後の結果をターゲットにするには、countオプションよりも大きいindexオプションを使用します。

たとえば、-G 5:10:2:4を使用すると、全体リストの第2四半分の初めに最も近いindexが指定されます。検索によって100のエントリが検出された場合、ターゲット索引は26となり、このパターンは21から36までのエントリを返します。

- before:after:value: ターゲット・エントリと、ターゲット・エントリの前後の指定された数のエントリを返します。ターゲット・エントリは、ソート属性が指定値以上であるソート結果の最初のエントリです。
たとえば、-G 5:10:johnson -S snを使用すると、surname属性からアルファベット順で16のエントリが返されます。その内訳はjohnsonより前の5つ、johnsonに等しいか直後のエントリ、およびjohnsonより後の10のエントリです。

-J, --control controloid[:criticality[:value|::b64value |:<filePath]]

ディレクトリ・サーバーに送信された検索リクエストに指定されているコントロールを使用して、検索を実行します。このオプションを使用すると、クライアントが直接サポートできない任意のリクエスト・コントロールを含めることができます。このオプションの値には、次のフォームを使用する必要があります:

oid[:criticality[:value|::b64value|:<filePath]]

この値の要素は次のとおりです:

- oid。コントロールのOIDを使用します。特定のタイプのコントロールについては、数値OIDのかわりにテキスト名を使用することもできます(検索操作の場合は、DSA IT管理のコントロールに対するmanagedsaitも含まれます)。この要素は必須です。-Jオプションまたはcontrolオプションを使用すると、OIDのかわりに判読可能な名前を使用して、値を必要としないコントロールを参照することができます。これらのOID名は次のとおりです:
accountusableまたはaccountusability: アカウント・ユーザビリティ・リクエスト・コントロールOID: 1.3.6.1.4.1.42.2.27.9.5.8のかわりに使用(値なし)。

authzidまたはauthorizationidentity: 認可IDリクエスト・コントロールOID: 2.16.840.1.113730.3.4.16のかわりに使用(値なし)。

effectiverights: 有効な権限の取得コントロールOID: 1.3.6.1.4.1.42.2.27.9.5.2のかわりに使用(値=認可ID)。

managedsait: DSA ITの管理コントロールOID: 2.16.840.1.113730.3.4.2のかわりに使用(値なし)。

noopまたはno-op: LDAP No-opコントロールOID: 1.3.6.1.4.1.4203.1.10.2のかわりに使用(値なし)。

pwpolicyまたはpassword policy: パスワード・ポリシー・リクエスト・コントロールOID: 1.3.6.1.4.1.42.2.27.8.5.1のかわりに使用(値なし)。

subtreedeleteまたはtreedelete: サブツリー削除リクエスト・コントロールOID: 1.2.840.113556.1.4.805のかわりに使用(値なし)。

- criticality。trueの場合、コントロールをクリティカルとマークする必要があります(つまり、操作がこのコントロールの要件を満たさないかぎり、ディレクトリ・サーバーは操作を処理しません)。falseの場合は、コントロールをクリティカルとマークする必要はありません。このサブコマンドが指定されていない場合、コントロールはクリティカルとマークされません。

- value。コントロールの値を指定します。このフォームは、値を文字列として表記できる場合のみ使用します。これは、::b64valueフォームまたは:< fileurlフォームと連係して使用することはできません。これらのサブコマンドがいずれも指定されていない場合、コントロールには値が設定されません。

- b64value。コントロールの値をbase64でエンコードされたフォームで指定します。このサブコマンドは、:valueフォームまたは:< fileurlフォームと連係して使用することはできません。これらのサブコマンドがいずれも指定されていない場合、コントロールには値が設定されません。

- fileurl。取り込むコントロールの値のあるファイルを参照するURLを指定します。これは、:valueフォームまたは::b64valueフォームと連係して使用することはできません。これらのサブコマンドがいずれも指定されていない場合、コントロールには値が設定されません。

たとえば、値1.3.6.1.4.1.42.2.27.9.5.2:true:dn:uid=dmiller,ou=people,dc=example,dc=comには、OIDが1.3.6.1.4.1.42.2.27.9.5.2であり、クリティカル(true)とマークされ、認可ID dn:uid=dmiller,ou=people,dc=example,dc=comの文字列値のあるクリティカルなコントロールが含まれます。または、次のOID名、effectiverights:true:dn:uid=dmiller、ou=people、dc=example、dc=comが使用できます。

-l, --timeLimit numSeconds

ディレクトリ・サーバーが検索リクエストの処理に費やす最長時間(秒)を指定します。このオプションが指定されない場合、クライアントは時間限度を要求しません。ディレクトリ・サーバーでは、クライアントにより要求される時間限度よりも低い限度を施行することができます。

--matchedValuesFilter filter

LDAPの一致した値の制御(RFC 3876 (http://www.ietf.org/rfc/rfc3876.txt)に定義)を使用して、指定されたフィルタに一致する属性値のみを検索結果に含めることを指定します。このオプションを複数回指定して、複数の一致した値フィルタを指定できます。

-n, --dry-run

no-opモードで実行します。つまり、発生する内容を報告しますが、実際に検索を実行したり、どの方法でもサーバーと通信することはありません。

-s, --searchScope scope

検索操作の範囲を設定します。範囲の値には、次のいずれか1つを指定する必要があります:

- base: --baseDNオプションまたは-bオプションによって指定されたエントリのみを検索します。

- one: --baseDNオプションまたは-bオプションによって指定されたエントリとその直接の子のみを検索します。

- subまたはsubordinate: --baseDNオプションまたは-bオプションによって指定されたエントリがベースであるサブツリーを検索します。これは、--searchScopeが指定されない場合のデフォルトのオプションです。

-S, --sortOrder sortOrder

結果をソートした後で、クライアントに結果を返します。ソート順はソート・キーのカンマ区切りリストであり、各ソート・キーは次の要素で構成されます:

- +/- (プラス記号またはマイナス記号): ソートを昇順(+)にするか、または降順(-)にするかを指定します。この要素が省略された場合は、昇順でソートされます。

- attribute name: データをソートする際に使用する属性の名前。この要素は常に指定する必要があります。

- nameまたはOID Matching Rule: オプションのコロン1つの後に、ソートの実行に使用する一致ルールの名前またはOIDが続きます。この要素が指定されない場合は、指定された属性タイプのデフォルトの順序付け一致ルールが使用されます。たとえば、ソート順序文字列sn,givenNameでは、まずsnによってエントリが昇順でソートされ、次にgivenNameによってソートされます。また、値--modifyTimestampを指定すると、結果は最新の値から順にソートされます。

--simplePageSize numEntries

単純なページ結果制御を指定されたページ・サイズで使用します。

--subEntries

サブエントリ制御を使用して、サブエントリが表示され、通常のエントリは表示されないことを指定します。

-Y, --proxyAsauthzID

プロキシ設定された認可制御を使用して、操作の対象となるユーザーのIDを指定します。これは、RFC 4370 (http://www.ietf.org/rfc/rfc4370.txt)に定義するとおり、プロキシ認可制御v2を使用します。このオプションの値には、認可IDをdn:の後にターゲット・ユーザーのDNが続くフォーム(たとえば、dn:uid=john.doe,ou=People,dc=example,dc=com)、またはu:の後にユーザー名が続くフォーム(たとえば、u:john.doe)で指定する必要があります。このオプションが指定されない場合、プロキシ認可は使用されません。

-z, --sizeLimit numEntries

ディレクトリ・サーバーがクライアントに返す一致エントリの最大数を設定します。このオプションが指定されていない場合、クライアントが要求する最大数は存在しません。ディレクトリ・サーバーでは、クライアントにより要求されるサイズ限度よりも低い限度を施行することができます。

A.4.5.6 LDAP接続オプション

-D, --bindDN bindDN

バインドDNを使用してディレクトリ・サーバーを認証します。このオプションは、簡易認証の実行時に使用します。このオプションのデフォルト値はcn=Directory Managerです。SASL認証を使用している場合、または認証が実行されない場合、これは必要ありません。

-E, --reportAuthzID

バインド・リクエストに認可IDリクエスト・コントロール(RFC 3829 (http://www.ietf.org/rfc/rfc3829.txt)に定義するとおり)を使用して、認証完了時にディレクトリ・サーバーが対応する認可IDをクライアントに返すようにします。(認可IDが含まれている行には接頭辞として#文字が使われ、出力をLDIFとして解釈されるようにする場合のコメントにします。)

-h, --hostname address

指定されたホスト名またはIPアドレスのディレクトリ・サーバーに接続します。これが指定されない場合は、localhostのデフォルトのアドレスが使用されます。

-j, --bindPasswordFile bindPasswordFile

ディレクトリ・サーバーに対して認証を受ける際、指定したファイルにバインド・パスワードを使用します。このオプションは、簡易認証と、パスワードに基づくSASLメカニズム(CRAM-MD5、DIGEST-MD5、およびPLAINなど)に使用します。認可が実行されない場合、これは必要ありません。このオプションは、--bindPasswordと同時に使用しないでください。

SASLは、プロキシ・サーバー・インスタンスに対してサポートされていません。

-K, --keyStorePath keyStorePath

SSLまたはStartTLS拡張操作を使用する場合は、セキュアな通信のために、指定されたパスにクライアント・キーストア証明書を使用します。このオプションは、SASL EXTERNAL認証を使用する場合など、クライアントがディレクトリ・サーバーに証明書を提示する必要がある場合のみ必要です。

SASLは、プロキシ・サーバー・インスタンスに対してサポートされていません。

-N, --certNickName certNickName

証明書ベースのクライアント認証に対して指定された証明書を使用します。

-o, --saslOption name=value

SASL認証を実行するときに、指定されたオプションを使用します。複数のSASLオプションを指定するには、オプションごとに1回ずつ、このオプションを複数回使用します。クライアントでのSASL認証の使用方法の詳細は、第20.7項「SASL認証の構成」を参照してください。

SASLは、プロキシ・サーバー・インスタンスに対してサポートされていません。

-p, --port port

指定されたポートでディレクトリ・サーバーに接続します。このオプションが指定されない場合は、デフォルトのポート389が使用されます。

-P, --trustStorePath trustStorePath

SSLまたはStartTLS拡張操作を使用する場合は、セキュアな通信のために、指定されたパスにクライアント・トラスト・ストア証明書を使用します。このオプションは、--trustAllを使用している場合は必要ありません。ただし、本番環境で作業する場合はトラスト・ストアを使用する必要があります。

-q, --useStartTLS

ディレクトリ・サーバーと通信する際、StartTLS拡張操作を使用します。このオプションは、--useSSLと同時に使用しないでください。

-r, --useSASLExternal

認証に対してSASL EXTERNALメカニズムを使用します。このメカニズムでは、クライアントがディレクトリ・サーバーに提示したSSL証明書を使用してクライアントを識別しようと試行されます。このオプションを使用する場合は、--keyStorePathオプションも同時に使用してクライアント・キーストアへのパスを指定し、--useSSLオプションまたは--useStartTLSオプションを使用してサーバーとのセキュアな通信チャネルを確立する必要があります。

SASLは、プロキシ・サーバー・インスタンスに対してサポートされていません。

--trustStorePassword trustStorePassword

クライアント・トラスト・ストアの証明書へのアクセスに必要なパスワードを使用します。このオプションは、--trustStorePathを使用していて、指定したトラスト・ストアがコンテンツへのアクセスにパスワードを必要とする場合のみ必須です(ほとんどのトラスト・ストアでは必要とされません)。このオプションは、--trustStorePasswordFileと同時に使用しないでください。

-u, --keyStorePasswordFile keyStorePasswordFile

クライアント・キーストアの証明書にアクセスするために、指定されたファイルでパスワードを使用します。このオプションは、--keyStorePathを使用する場合のみ必須です。このオプションは、--keyStorePasswordと同時に使用しないでください。

--usePasswordPolicyControl

バインド・リクエストにパスワード・ポリシー・リクエスト制御を使用して、ディレクトリ・サーバーがバインド・レスポンスで対応する結果制御を返すようにします。これは、クライアントのアカウントの状態に関連した警告またはエラーに関する情報の取得に使用できます。

-U, --trustStorePasswordFile trustStorePasswordFile

クライアント・トラスト・ストアの証明書にアクセスするために、指定されたファイルでパスワードを使用します。このオプションは、--trustStorePathを使用していて、指定したトラスト・ストアがコンテンツへのアクセスにパスワードを必要とする場合のみ必須です(ほとんどのトラスト・ストアでは必要とされません)。このオプションは、--trustStorePasswordと同時に使用しないでください。

-V, --ldapVersion version

クライアントがディレクトリ・サーバーと通信する際に使用する必要のあるLDAPプロトコルのバージョンを設定します。この値には、2 (LDAPv2通信の場合)または3 (LDAPv3の場合)のいずれかを設定する必要があります。このオプションが指定されない場合、クライアントはLDAPv3を使用します。

-w, --bindPassword bindPassword

ディレクトリ・サーバーに対して認証を受ける際、バインド・パスワードを使用します。このオプションは、簡易認証と、パスワードに基づくSASLメカニズムに使用できます。このオプションは、--bindPasswordFileと同時に使用しないでください。パスワードの入力を要求するには、-w -を入力します。

SASLは、プロキシ・サーバー・インスタンスに対してサポートされていません。

-W, --keyStorePassword keyStorePassword

クライアント・キーストアの証明書へのアクセスに必要なパスワードを使用します。このオプションは、--keyStorePathを使用する場合のみ必須です。このオプションは、--keyStorePasswordFileと同時に使用しないでください。

-X, --trustAll

SSLまたはStartTLSのネゴシエーション中にディレクトリ・サーバーによって提示される可能性のある証明書をすべて信頼します。このオプションは便宜的に、かつテストの目的で使用できますが、セキュリティ上の理由から、トラスト・ストアを使用してクライアントがサーバーの証明書を受け入れるかどうかを判別する必要があります。

-Z, --useSSL

ディレクトリ・サーバーと通信する際、SSLを使用します。SSLを使用する場合は、--portオプションを使用してサーバーのセキュア・ポートを指定する必要があります。

A.4.5.7 コマンド入力/出力オプション

--noPropertiesFile

デフォルトのコマンドライン・オプションの取得にプロパティ・ファイルが使用されないことを示します。

--propertiesFilePath propertiesFilePath

デフォルトのコマンドライン・オプションが含まれているプロパティ・ファイルへのパスを指定します。

-T, --dontWrap

一致エントリを表示するときに、長い行の折り返しを行いません。このオプションが指定されない場合、長い行は80列の端末に収まるように(LDIF仕様と適合する方法で)折り返されます。

-v, --verbose

冗長モードで実行して、プロセス情報と診断情報を標準出力で表示します。

A.4.5.8 一般オプション

-?, -H, --help

このコマンドに対するコマンドライン使用情報を表示し、コマンドの実行を試みないで終了します。

-V, --version

ディレクトリ・サーバーのバージョン情報を表示します。

A.4.5.9 例

次の例は、ldapsearchコマンドの使用方法を示しています。その他の例については、第17.4項「ディレクトリ・データの検索」を参照してください。

例A-138 すべてのエントリを返す

次のコマンドは、ディレクトリ・サーバー上のすべてのエントリを返します。このコマンドは、ホスト(-h)上のデフォルトのポート1389 (-p)に接続し、ベースDNをexample.com (-b)として指定し、検索フィルタ(objectclass=*)を使用してすべてのエントリを返します。範囲(-s)が指定されていないため、範囲はデフォルト値であるsub、ベースDNの完全なサブツリーに設定されます。属性が指定されていないため、すべての属性と値が返されます。

$ ldapsearch -h hostname -p 1389 -b dc=example,dc=com "(objectclass=*)"

dn: dc=example,dc=com
objectClass: domain
objectClass: top
dc: example

dn: ou=Groups,dc=example,dc=com
objectClass: organizationalunit
objectClass: top
ou: Groups

dn: cn=Directory Administrators,ou=Groups,dc=example,dc=com
objectClass: groupofuniquenames
objectClass: top
ou: Groups
cn: Directory Administrators
uniquemember: uid=kvaughan, ou=People, dc=example,dc=com
uniquemember: uid=rdaugherty, ou=People, dc=example,dc=com
uniquemember: uid=hmiller, ou=People, dc=example,dc=com

例A-139 値を除く属性名を返す

次のコマンドは、属性名(-A)を返しますが、値は返しません。このコマンドは、ホスト(-h)上のデフォルトのポート1389 (-p)に接続し、ベースDNをdc=example,dc=com (-b)として指定し、検索フィルタobjectclass=*を使用してすべてのエントリを一致させ、3つのエントリ(-z)を返します。属性がデータベースに存在するかどうかをチェックする場合は、-Aオプションを使用すると便利です。

$ ldapsearch -h hostname -p 1389 -b dc=example,dc=com -A -z 3 "(objectclass=*)"

dn: dc=example,dc=com
objectClass
dc

dn: ou=Groups,dc=example,dc=com
objectClass
ou

dn: cn=Directory Administrators,ou=Groups,dc=example,dc=com
objectClass
ou
cn
uniquemember

例A-140 特定の属性値を返す

次のコマンドは、特定の属性とその値を返します。このコマンドは、ホスト(-h)上のポート1389 (-p)に接続し、ベースDNをdc=example,dc=com (-b)として指定し、検索フィルタcn=Sam Carterを使用してすべてのエントリを一致させ、属性(telephonenumber)の値を返します。

$ ldapsearch -h hostname -p 1389 -b dc=example,dc=com "(cn=Sam Carter)" telephoneNumber

dn: uid=scarter,ou=People,dc=example,dc=com
telephonenumber: +1 408 555 4798

例A-141 ルートDSEを返す

ルートDSEは、ディレクトリ・サーバーの名前、バージョン、ネーミング・コンテキスト、およびサポートされる機能についての情報を提供する特殊なエントリです。ルートDSEを指定するには、null値を持つベースDN(例: -b "")を使用します。このベースDNは、デフォルトではすべてのパブリック・ネーミング・コンテキストの下をディレクトリ・サーバーが検索する際の基準となります。デフォルトのnullのベースDNをオーバーライドするには、dsconfigコマンドを使用して、subordinate-base-dnプロパティが指定されている特定のベースDNのセットを指定します。次の例では、ホスト(-h)上のデフォルトのポート1389 (-p)に接続し、ルートDSEを空のベース・エントリ(-b)として指定し、検索の範囲をbase (-s)に指定し、検索フィルタobjectclass=*を使用してすべてのエントリを一致させ、サポートされる制御に対してディレクトリ・サーバーのルートDSE情報を返します:

$ ldapsearch -h hostname -p 1389 -b "" -s base "(objectclass=*)" supportedControl

dn:
supportedControl: 1.2.826.0.1.3344810.2.3
supportedControl: 1.2.840.113556.1.4.319
supportedControl: 1.2.840.113556.1.4.473
supportedControl: 1.2.840.113556.1.4.805
...

例A-142 サーバー認証を使用した検索

次のコマンドは、SSLオプションを使用してサーバー認証による検索を実行します。次のコマンドでは、ホスト名(-h)、SSLポート1636 (-p)、ベースDN (-b)、バインドDN (-D)、バインド・パスワード(-w)、トラスト・ストア・ファイル・パス(-P)、およびエンティティの名を指定します。Windowsプラットフォームの場合は、トラスト・ストア・ファイルのパス(たとえば、-P \certs\cert.db)を指定します。

$ ldapsearch -h hostname -p 1636 -b "dc=example,dc=com" \
-D "uid=scarter,ou=people,dc=example,dc=com" -w bindPassword \
-P /home/scarter/certs/cert.db "(givenname=Sam)"

例A-143 クライアント認証を使用した検索

次のコマンドは、SSLオプションを使用してクライアント認証による検索を実行します。このコマンドはSSLポート(-p)を指定してSSL (-Z)を使用し、トラスト・ストア・ファイル・パス(-P)、証明書ニックネーム(-N)、キーストア・ファイル・パス(-K)、キーストア・パスワード(-W)およびエンティティの名(givenname=Sam)を指定します。Windowsプラットフォームの場合は、トラスト・ストア・ファイルのパス(たとえば、-P \certs\cert.db)およびキーストア・ファイルのパス(たとえば、-K \security\key.db)を指定します:

$ ldapsearch -h hostname -p 1636 -b "dc=example,dc=com" \
-Z -P /home/scarter/security/cert.db -N "sccert" \
-K /home/scarter/security/key.db -W KeyPassword \
"(givenname=Sam)"

例A-144 ユーザーの有効権限を返す

次のコマンドは、ユーザーの属性エントリのほかに、ユーザーに付与されている有効権限を返します。ディレクトリ管理者のみが、別のユーザーに関してこの情報にアクセスできます。このコマンドでは、ホスト名(-h)、ポート1389 (-p)、bindDN (-D)、bindDNパスワード(-w)、ベースDN (-b)、OID名effectiverightsを含むコントロール・スペック・オプション(または、同等のOID: 1.3.6.1.4.1.42.2.27.9.5.2が入力可能)、検索フィルタobjectclass=*、およびaclRights属性を指定します。

$ ldapsearch -h hostname -p 1389 -D "cn=Directory Manager" -j pwd-file \
-b dc=example,dc=com -J "1.3.6.1.4.1.42.2.27.9.5.2"  "(objectclass=*)" \
aclRights

dn: dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0

dn: ou=Groups, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0

dn: ou=People, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0

dn: cn=Accounting Managers,ou=groups,dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0

dn: cn=HR Managers,ou=groups,dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0

dn: uid=bjensen,ou=People, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0

dn: uid=cfuente, ou=People, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:1,proxy:0

例A-145 スキーマを返す

次のコマンドは、ディレクトリ・インスタンスで定義されたオブジェクト・クラスと属性に関してcn=schemaエントリを検索します。このコマンドは、ホスト(-h)上のポート1389 (-p)に接続し、検索の範囲をbase (-s)に設定し、検索フィルタ(objectclass=\*)を使用してすべてのエントリを一致させ、スキーマ・エントリcn=schemaにあるobjectClassの定義を返します。+記号を使用してスキーマを表示することもできます。プラス記号は検索フィルタの後ろに入れます。

$ ldapsearch -h hostname -p 1389 -b cn=schema -s base "(objectclass=*)" objectClasses

dn: cn=schema
objectClasses: ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass X-ORIGIN 'RFC 4512
' )
objectClasses: ( 2.5.6.1 NAME 'alias' SUP top STRUCTURAL MUST aliasedObjectName
X-ORIGIN 'RFC 4512' )
objectClasses: ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c MAY ( searchGu
ide $ description ) X-ORIGIN 'RFC 4519' )
objectClasses: ( 2.5.6.3 NAME 'locality' SUP top STRUCTURAL MAY ( street $ seeAl
so $ searchGuide $ st $ l $ description ) X-ORIGIN 'RFC 4519' )
...

例A-146 永続検索の実行

ldapsearchコマンドは、永続検索(-C)を実行するオプションを指定します。このオプションにより、接続はオープンのまま維持され、変更(add、delete、mod、またはall)が発生した場合でも常に範囲とフィルタに一致するエントリが表示されます。このコマンドは、ポート1389 (-p)に接続し、検索の範囲をbase (-s)に設定し、検索フィルタ(objectclass=\*)を使用してすべてのエントリを一致させます。検索を終了するには、[Control]-[C]キーを押します。

$ ldapsearch -b dc=example,dc=com -p 1389 -D "cn=Directory Manager" \
-j pwd-file -C ps:add:true:true "(objectclass=*)"

例A-147 ACI属性の表示

次のコマンドは、指定されたベースDNからアクセス制御指示(ACI)の属性を表示します。このコマンドは、ポート1389 (-p)に接続し、検索の範囲をbase (-s)に設定し、検索フィルタ(objectclass=\*)を使用してすべてのエントリを一致させて、aci属性を指定します。

$ ldapsearch -p 1389 -D "cn=Directory Manager" -j pwd-file -b dc=example,dc=com \
-s base "(objectclass=*)" aci

dn: dc=example,dc=com
aci: (target ="ldap:///dc=example,dc=com")(targetattr h3.="userPassword")(version
3.0;acl "Anonymous read-search access";allow (read, search, compare)(userdn = "
ldap:///anyone");)
aci: (target="ldap:///dc=example,dc=com") (targetattr = "*")(version 3.0; acl "a
llow all Admin group"; allow(all) groupdn = "ldap:///cn=Directory Administrator
s,ou=Groups,dc=example,dc=com";)

例A-148 監視情報の表示

次のコマンドは、ディレクトリ・サーバーでのアクティビティの情報に関してcn=monitorエントリを検索します。次のコマンドでは、ホスト名(-h)、ポート(-p)、cn=monitorのベースDN (-b)を指定し、バインドDN(-D)およびバインド・パスワード(-w)を使用して認証し、フィルタ(objectclass=\*)を指定します。

$ ldapsearch --useSSL -X -h hostname -p 4444 -b cn=monitor -D "cn=Directory Manager" \
-j pwd-file "(objectclass=*)"

dn: cn=monitor
objectClass: top
objectClass: extensibleObject
objectClass: ds-monitor-entry
currentTime: 20070803161832Z
startTime: 20070803132044Z
productName: Oracle Unified Directory
...

例A-149 プロパティ・ファイルを使用した検索

ディレクトリ・サーバーでは、ldapsearchコマンドとともに使用されるデフォルトのオプション値を渡すプロパティ・ファイルの使用をサポートしています。プロパティ・ファイルは、様々な構成環境、特にスクリプト済アプリケーションまたは埋込みアプリケーションで作業する場合に便利です。詳細は、第A.1.2項「サーバー・コマンドによるプロパティ・ファイルの使用方法」を参照してください。

プロパティ・ファイルに保存可能なオプションは次のとおりです:

- assertionFilter

- bindDN

- bindPassword

- bindPasswordFile

- certNickname

- continueOnError

- control

- countEntries

- dereferencePolicy

- dry-run

- dontWrap

- filename

- getEffectiveRightsAttribute

- getEffectiveRightsAuthzid

- hostname

- keyStorePassword

- keyStorePasswordFile

- keyStorePath

- ldapVersion

- matchedValuesFilter

- persistentSearch

- port

- proxyAs

- reportAuthzID

- saslOption
SASLは、プロキシ・サーバー・インスタンスに対してサポートされていません。

- searchScope

- simplePageSize

- sizeLimit

- sortOrder

- timeLimit

- trustAll

- trustStorePassword

- trustStorePasswordFile

- trustStorePath

- typesOnly

- usePasswordPolicyControl

- useSASLExternal
SASLは、プロキシ・サーバー・インスタンスに対してサポートされていません。

- useSSL

- useStartTLS

- verbose

- virtualListView

A.4.5.10 プロパティ・ファイルを使用して検索するには

1. 任意のテキスト・エディタでプロパティ・ファイルを作成します。ここでは、ファイルをtools.propertiesとして保存します。

hostname=host
port=1389
bindDN=cn=Directory Manager
bindPassword=password
baseDN=dc=example,dc=com
searchScope=sub
sortOrder=givenName
virtualListView=0:2:1:0

2. --propertiesFilePathオプションを指定してldapsearchを使用します。$ldapsearch --propertiesFilePath tools.properties "(objectclass=*)"

A.4.5.11 検索属性

多数の特殊な検索属性を、次に示すように様々な目的で使用することもできます:

*: この記号は、ディレクトリ・サーバーから返されたエントリにすべてのユーザー属性を含める必要があることを示します。

$ ldapsearch -h hostname -p 1389 -b dc=example,dc=com "(objectclass=*)" *

+: この記号は、ディレクトリ・サーバーから返されたエントリにすべての操作属性が含まれることを示します。デフォルトでは、操作属性は返されません。これが指定された場合でも、たとえば、値の構成に使用される計算量が多い場合などの理由で、自動的に返されない操作属性が存在する可能性があることに注意してください。)システムによっては、+記号を引用符で囲むか("+")、バックスラッシュ\+を使用してプラス記号をエスケープしなければならない場合があります。

$ ldapsearch -h hostname -p 1389 -b dc=example,dc=com "(objectclass=*)" "+"

1.1: これは、一致するエントリに属性値を含められないことを示します。システムによっては、1.1文字を引用符で囲むか("1.1")、バックスラッシュ\1.1を使用してエスケープしなければならない場合があります。

$ ldapsearch -h hostname -p 1389 -b dc=example,dc=com "(objectclass=*)" "1.1"

@_objectclass_: これは、指定されたオブジェクト・クラスに関連付けられているすべての属性を、ディレクトリ・サーバーから返されたエントリに含める必要があることを示します。たとえば、@personは、サーバーがpersonオブジェクト・クラスに関連付けられているすべての属性を含める必要があることを示します。

$ ldapsearch -h hostname -p 1389 -b dc=example,dc=com "(objectclass=*)" @person

A.4.5.12 終了コード

終了コード0は、操作が正常に終了したことを示します。ゼロ以外の終了コードは、処理中にエラーが発生したことを示します。

A.4.5.13 場所

- UNIXおよびLinux: INSTANCE_DIR/OUD/bin/ldapsearch

- Windows: INSTANCE_DIR\OUD\bat\ldapsearch.bat

A.4.5.14 関連コマンド

- 第A.4.1項「ldapcompare」

- 第A.4.2項「ldapdelete」

- 第A.4.3項「ldapmodify」

- 第A.4.4項「ldappasswordmodify」

B サポートされている制御および操作

Oracle Unified Directoryは、標準LDAP制御および拡張操作を多数サポートしています。次の各項では、これらの制御および拡張操作をリストします。

- 第B.1項「サポートされているLDAP制御」

- 第B.2項「サポートされている拡張操作」

LDAP制御の使用の詳細は、第17.5.3項「制御を使用した検索」を参照してください。

B.1 サポートされているLDAP制御

サポートされている制御は、Oracle Unified Directoryによってサポートされているリクエスト制御を識別するメカニズムです。これらの制御のオブジェクト識別子は、サーバーのルートDSEのsupportedControl属性にリストされています。

表B-1にディレクトリ・サーバーでサポートされている制御をリストします。

プロキシ・インスタンスをインストール済の場合、プロキシおよびリモートLDAPサーバーでサポートされている制御をリストしている表B-2を参照してください。

表B-1 ディレクトリ・サーバーでサポートされているLDAP制御

OID

LDAP制御

RFCまたはドラフト

1.2.826.0.1.3344810.2.3

一致する値の制御

RFC3876

1.2.840.113556.1.4.319

ページ結果制御

RFC2696

1.2.840.113556.1.4.473

サーバー側ソート制御

RFC2891

1.2.840.113556.1.4.805

サブツリー削除制御

ドラフト

1.3.6.1.1.12

アサーション制御

RFC4528

1.3.6.1.1.13.1

LDAP読込み前制御

RFC4527

1.3.6.1.1.13.2

LDAP読込み後制御

RFC4527

1.3.6.1.4.1.26027.1.5.2

レプリケーション修復制御

1.3.6.1.4.1.4203.1.10.2

LDAP操作なし制御

ドラフト

1.3.6.1.4.1.42.2.27.8.5.1

パスワード・ポリシー制御

ドラフト

1.3.6.1.4.1.42.2.27.9.5.2

実効権限取得制御

1.3.6.1.4.1.42.2.27.9.5.8

アカウント・ユーザビリティ制御

1.3.6.1.4.1.42.2.27.9.5.9

CSN(番号変更制御)

1.3.6.1.4.1.4203.1.10.1

LDAPサブエントリ・リクエスト制御

RFC3672

2.16.840.1.113730.3.4.4

パスワード期限切れ制御

2.16.840.1.113730.3.4.5

パスワードの期限切れ警告制御

2.16.840.1.113730.3.4.12

プロキシ認可v1制御

ドラフト

2.16.840.1.113730.3.4.18

プロキシ認可v2制御

RFC4370

2.16.840.1.113730.3.4.16

認可IDリクエスト制御

RFC3829

2.16.840.1.113730.3.4.17

実在属性専用制御

2.16.840.1.113730.3.4.19

仮想属性専用制御

2.16.840.1.113730.3.4.2

ManageDsaIT

RFC3296

2.16.840.1.113730.3.4.3

永続検索制御

ドラフト

2.16.840.1.113730.3.4.9

仮想リスト表示制御

ドラフト

2.16.840.1.113894.1.8.21

OID検索件数リクエスト制御

表B-2 プロキシでサポートされているLDAP制御

OID

LDAP制御

RFCまたはドラフト

プロキシ・ワークフロー要素によってサポートされている

分散アルゴリズムによってサポートされている

リモートODSEEによってサポートされている

リモートOracle Unified Directoryディレクトリ・サーバーによってサポートされている

備考

1.2.826.0.1.3344810.2.3

一致する値の制御

RFC3876

はい

はい

いいえ

はい

1.2.840.113556.1.4.319

ページ結果制御

RFC2696

はい

いいえ

いいえ

はい

1.2.840.113556.1.4.473

サーバー側ソート制御

RFC2891

はい

いいえ

はい

はい

ターゲットのすべてのエントリが同じリモートLDAPサーバー上にあり、そのリモートLDAPサーバーがサーバー側のLDAP制御をサポートしている場合、サポートされます。

1.2.840.113556.1.4.805

サブツリー削除制御

ドラフト

はい

いいえ

いいえ

はい

ターゲットのすべてのエントリが同じリモートLDAPサーバー上にあり、そのリモートLDAPサーバーがサブツリー削除LDAP制御をサポートしている場合、サポートされます。ターゲットのエントリが複数のリモートLDAPサーバーにまたがる可能性があるため、分散アルゴリズムによってサポートされません。

1.3.6.1.1.12

アサーション制御

RFC4528

はい

はい

いいえ

はい

ターゲットのエントリをホストしているリモートLDAPサーバーがアサーション制御もサポートしている場合、サポートされます。したがって、すべてのリモートLDAPサーバーがOracle Directory Server Enterprise Editionを実行しているプロキシ構成ではサポートされません。

1.3.6.1.1.13.1

LDAP読込み前制御

RFC4527

はい

はい

プロキシが動作するように十分にコンパイルします。

はい

ターゲットのエントリをホストしているリモートLDAPサーバーがLDAP読込み前制御もサポートしている場合、サポートされます。

グローバル索引カタログでは必須です。Oracle Unified Directoryディレクトリ・サーバーでは、この制御を有効にする必要があります。

1.3.6.1.1.13.2

LDAP読込み後制御

RFC4527

はい

はい

いいえ

はい

ターゲットのエントリをホストしているリモートLDAPサーバーがLDAP読込み後制御もサポートしている場合、サポートされます。したがって、すべてのリモートLDAPサーバーがOracle Directory Server Enterprise Editionを実行しているプロキシ構成ではサポートされません。

Oracle Unified Directoryディレクトリ・サーバーでは、この制御を有効にする必要があります。

1.3.6.1.4.1.26027.1.5.2

レプリケーション修復制御

いいえ

いいえ

いいえ

はい

プロキシではサポートされていません。リモートLDAPサーバー間のデータの非一貫性を修復するには、プロキシをバイパスし、Oracle Unified Directoryを実行しているリモートLDAPサーバーに制御を直接送ります。Oracle Directory Server Enterprise Editionを実行しているリモートLDAPサーバーの場合、Oracle Directory Server Enterprise Editionのドキュメントのdsrepairコマンドを参照してください。

1.3.6.1.4.1.4203.1.10.2

LDAP操作なし制御

ドラフト

はい

はい

いいえ

はい

ターゲットのエントリをホストしているリモートLDAPサーバーがLDAP操作なし制御もサポートしている場合、サポートされます。したがって、すべてのリモートLDAPサーバーがOracle Directory Server Enterprise Editionを実行しているプロキシ構成ではサポートされません。

1.3.6.1.4.1.42.2.27.8.5.1

パスワード・ポリシー制御

ドラフト

はい

はい

はい

はい

1.3.6.1.4.1.42.2.27.9.5.2

実効権限取得制御

はい

はい

はい

はい

リモートLDAPサーバーがOracle Unified Directoryを実行しているプロキシの構成によってこの制御が使用される場合、十分な資格証明を持っている場合にはOracle Unified DirectoryでaclRights制御およびaclRightsInfo制御を認可する必要があります。

1.3.6.1.4.1.42.2.27.9.5.8

アカウント・ユーザビリティ制御

はい

はい

はい

はい

1.3.6.1.4.1.4203.1.10.1

LDAPサブエントリ・リクエスト制御

RFC3672

はい

はい

いいえ

はい

ターゲットのエントリをホストしているリモートLDAPサーバーがLDAPサブエントリ制御もサポートしている場合、サポートされます。

2.16.840.1.113730.3.4.12

プロキシ認可v1制御

ドラフト

はい

はい

はい

はい

ターゲットのエントリをホストしているリモートLDAPサーバーがプロキシ認可v1制御もサポートしている場合、サポートされます。プロキシがこの制御モードで構成されている場合、リモートLDAPサーバーは実効権限取得制御もサポートする必要があります。

2.16.840.1.113730.3.4.18

プロキシ認可v2制御

RFC4370

はい

はい

はい

はい

ターゲットのエントリをホストしているリモートLDAPサーバーがプロキシ認可v2制御もサポートしている場合、サポートされます。プロキシがこの制御モードで構成されている場合、リモートLDAPサーバーは実効権限取得制御もサポートする必要があります。

2.16.840.1.113730.3.4.16

認可IDリクエスト制御

RFC3829

はい

はい

はい

はい

ターゲットのエントリをホストしているリモートLDAPサーバーが認可IDリクエスト制御もサポートしている場合、サポートされます。

2.16.840.1.113730.3.4.17

実在属性専用制御

はい

はい

はい

はい

ターゲットのエントリをホストしているリモートLDAPサーバーが実際の属性専用制御もサポートしている場合、サポートされます。

2.16.840.1.113730.3.4.19

仮想属性専用制御

はい

はい

はい

はい

ターゲットのエントリをホストしているリモートLDAPサーバーが仮想属性専用リクエスト制御もサポートしている場合、サポートされます。

2.16.840.1.113730.3.4.2

ManageDsaIT

RFC3296

はい

はい

はい

はい

2.16.840.1.113730.3.4.3

永続検索制御

ドラフト

はい

はい

はい

はい

ターゲットのエントリをホストしているリモートLDAPサーバーが永続検索制御もサポートしている場合、サポートされます。

2.16.840.1.113730.3.4.9

仮想リスト表示制御

ドラフト

はい

いいえ

はい

はい

ターゲットのすべてのエントリが同じリモートLDAPサーバー上にあり、そのサーバーが仮想リスト表示制御をサポートしている場合、サポートされます。

1.3.6.1.4.1.42.2.27.9.5.9

CSN(番号変更制御)

はい

はい

はい

はい

レプリケーション専用で、modifyRequest、delRequestおよびmodDNRequestの各LDAPメッセージに適切です。グローバル索引カタログでは必須です。

B.2 サポートされている拡張操作

サポートされている拡張は、Oracle Unified Directoryによってサポートされているリクエスト拡張操作を識別するメカニズムです。これらの拡張操作のオブジェクト識別子は、サーバーのルートDSEのsupportedExtension属性にリストされています。

Oracle Unified Directoryでサポートされている拡張には次のものがあります:

1.3.6.1.1.8

取消拡張操作

1.3.6.1.4.1.1466.20037

StartTLS拡張操作

1.3.6.1.4.1.26027.1.6.1

パスワード・ポリシー状態拡張操作

1.3.6.1.4.1.26027.1.6.2

接続ID取得拡張操作

1.3.6.1.4.1.26027.1.6.3

対称鍵取得拡張操作

1.3.6.1.4.1.4203.1.11.1

パスワード変更拡張操作

1.3.6.1.4.1.4203.1.11.3

「Who Am I」拡張操作

C Oracle Unified Directoryがサポートしている規格および仕様

この項では、Oracle Unified Directoryがサポートしている様々な規格および仕様について説明し、次のトピックを説明します:

- 第C.1項「Oracle Unified DirectoryがサポートしているRFC」

- 第C.2項「Oracle Unified Directoryがサポートしているインターネット・ドラフト」

- 第C.3項「Oracle Unified Directoryがサポートしているその他の仕様」

C.1 Oracle Unified DirectoryがサポートしているRFC

表C-1は、Oracle Unified Directoryで現在サポートされているRFCのリストです。Oracle Unified Directoryは、新しいプロトコルに準拠するよう絶えず更新されています。

表C-1 サポートされているRFC

番号

説明

RFC 1274

COSINEおよびInternet X.500スキーマ

RFC 1321

MD5メッセージ・ダイジェスト・アルゴリズム

RFC 1777

Lightweight Directory Access Protocol (v2)

RFC 1778

標準属性構文の文字列表現

RFC 1779

識別名の文字列表現

RFC 2079

Uniform Resource Identifiers (URI)を保持するためのX.500属性タイプおよびオブジェクト・クラスの定義

RFC 2222

Simple Authentication and Security Layer (SASL)

RFC 2246

TLSプロトコル

RFC 2246

TLSプロトコル・バージョン1.0

RFC 2247

LDAP/X.500識別名のドメインの使用

RFC 2251

Lightweight Directory Access Protocol (v3)

RFC 2252

Lightweight Directory Access Protocol (v3): 属性構文定義

RFC 2254

LDAP検索フィルタの文字列表現

RFC 2255

LDAP URLフォーマット

RFC 2256

LDAPv3とともに使用されるX.500(96)ユーザー・スキーマの要約

RFC 2307

ネットワーク情報サービスとしてLDAPを使用する方法

RFC 2377

インターネット・ディレクトリ対応アプリケーションの命名計画

RFC 2605

ディレクトリ・サーバーの監視MIB

RFC 2649

操作署名を保持するためのLDAP制御およびスキーマ

RFC 2696

単純なページ結果操作のためのLDAP制御拡張

RFC 2713

LDAPディレクトリのJava(tm)オブジェクトを表すスキーマ

RFC 2714

LDAPディレクトリのCORBAオブジェクト参照を表すスキーマ

RFC 2739

vCardおよびLDAPのカレンダ属性

RFC 2788

ネットワーク・サービスの監視MIB

RFC 2798

inetOrgPerson LDAPオブジェクト・クラスの定義

RFC 2829

LDAPの認証方法

RFC 2830

Lightweight Directory Access Protocol (v3): トランスポート・レイヤー・セキュリティ用の拡張

RFC 2831

SASLメカニズムとしてのダイジェスト認証の使用

RFC 2849

The LDAP Data Interchange Format (LDIF) - 技術仕様

RFC 2891

検索結果のサーバー側ソートのためのLDAP制御拡張

RFC 2926

LDAPスキーマからSLPテンプレートへの変換およびその逆の変換

RFC 3045

ベンダー情報のLDAPルートDSEへの格納

RFC 3062

LDAPパスワード変更拡張操作

RFC 3112

LDAP認証のパスワード・スキーマ

RFC 3174

USセキュア・ハッシュ・アルゴリズム1 (SHA1)

RFC 3296

Lightweight Directory Access Protocol (LDAP)ディレクトリの名前付き従属参照

RFC 3377

Lightweight Directory Access Protocol (v3)

RFC 3377

Lightweight Directory Access Protocol (v3): 技術仕様

RFC 3383

Lightweight Directory Access Protocol (LDAP)のInternet Assigned Numbers Authority (IANA)の考慮事項

RFC 3454

国際化文字列("stringprep")の準備

RFC 3546

トランスポート・レイヤー・セキュリティ(TLS)の拡張

RFC 3671

Collective Attributes in the Lightweight Directory Access Protocol (LDAP)

RFC 3672

Lightweight Directory Access Protocol (LDAP)のサブエントリ

RFC 3673

Lightweight Directory Access Protocolバージョン3 (LDAPv3): すべての操作属性

RFC 3674

Lightweight Directory Access Protocol (LDAP)の機能検索

RFC 3698

Lightweight Directory Access Protocol (LDAP): 追加の一致ルール

RFC 3771

Lightweight Directory Access Protocol (LDAP)中間応答メッセージ

RFC 3829

Lightweight Directory Access Protocol (LDAP)認可IDリクエストおよび応答の制御

RFC 3866

Lightweight Directory Access Protocol (LDAP)の言語タグおよび範囲

RFC 3876

Lightweight Directory Access Protocolバージョン3 (LDAPv3)を使用した一致する値の返送

RFC 3909

Lightweight Directory Access Protocol (LDAP)取消操作

RFC 4346

トランスポート・レイヤー・セキュリティ(TLS)プロトコル・バージョン1.1

RFC 4370

Lightweight Directory Access Protocol (LDAP)プロキシ設定された認可制御

RFC 4403

Universal Description, Discovery, and Integrationバージョン3 (UDDIv3)のLightweight Directory Access Protocol (LDAP)スキーマ

RFC 4422

Simple Authentication and Security Layer (SASL)

RFC 4505

匿名のSimple Authentication and Security Layer (SASL)メカニズム

RFC 4510

Lightweight Directory Access Protocol (LDAP): 技術仕様のロード・マップ

RFC 4511

Lightweight Directory Access Protocol (LDAP): プロトコル

RFC 4512

Lightweight Directory Access Protocol (LDAP): ディレクトリ情報モデル

RFC 4513

Lightweight Directory Access Protocol (LDAP): 認証メソッドおよびセキュリティ・メカニズム

RFC 4514

Lightweight Directory Access Protocol (v3): 識別名のUTF-8文字列表現

RFC 4515

Lightweight Directory Access Protocol (LDAP): 検索フィルタの文字列表現

RFC 4516

Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator

RFC 4517

Lightweight Directory Access Protocol (LDAP): 構文および一致ルール

RFC 4518

Lightweight Directory Access Protocol (LDAP): 国際化された文字列の準備

RFC 4519

Lightweight Directory Access Protocol (LDAP): ユーザー・アプリケーションのスキーマ

RFC 4520

Lightweight Directory Access Protocol (LDAP)のInternet Assigned Numbers Authority (IANA)の考慮事項

RFC 4522

Lightweight Directory Access Protocol (LDAP): バイナリ・エンコーディング・オプション

RFC 4524

COSINE LDAP/X.500スキーマ

RFC 4525

Lightweight Directory Access Protocol (LDAP)変更増分拡張

RFC 4526

Lightweight Directory Access Protocol (LDAP)の絶対Trueフィルタおよび絶対Falseフィルタ

RFC 4527

Lightweight Directory Access Protocol (LDAP)読取りエントリ制御

RFC 4528

Lightweight Directory Access Protocol (LDAP)アサーション制御

RFC 4529

Lightweight Directory Access Protocol (LDAP)のオブジェクト・クラスによる属性のリクエスト

RFC 4530

Lightweight Directory Access Protocol (LDAP) entryUUID操作属性

RFC 4532

Lightweight Directory Access Protocol (LDAP)「Who am I?」操作

RFC 4616

PLAIN Simple Authentication and Security Layer (SASL)メカニズム

RFC 4634

USセキュア・ハッシュ・アルゴリズム(SHAおよびHMAC-SHA)

RFC 4752

Kerberos V5 ("GSSAPI") SASLメカニズム

RFC 5020

Lightweight Directory Access Protocol (LDAP) entryDN操作属性

C.2 Oracle Unified Directoryがサポートしているインターネット・ドラフト

表C-2は、Oracle Unified Directoryがサポートしているインターネット・ドラフトのリストです。

表C-2 Oracle Unified Directoryがサポートしているインターネット・ドラフト

ドキュメント

説明

draft-armijo-ldap-treedelete

ツリー削除制御

draft-behera-ldap-password-policy

LDAPディレクトリのパスワード・ポリシー

draft-furuseth-ldap-untypedobject

LDAP/X.500の構造型オブジェクト・クラス「untypedObject」

draft-good-ldap-changelog

LDAP変更レコードを保持するためのオブジェクト・クラスの定義

draft-haripriya-dynamicgroup

LDAP: LDAPv3のダイナミック・グループ

draft-howard-namedobject

任意の補助オブジェクト・クラスの構造型オブジェクト・クラス

draft-howard-rfc2307bis

ネットワーク情報サービスとしてLDAPを使用する方法

draft-ietf-boreham-numsubordinates

numSubordinates LDAP操作属性

draft-ietf-ldapext-ldapv3-dupent

検索結果の重複エントリ表現のLDAP制御

draft-ietf-ldapext-ldapv3-vlv

検索結果のビュー・ブラウズをスクロールするLDAP拡張

draft-ietf-ldapext-psearch

永続検索: 単純なLDAP変更通知メカニズム

draft-ietf-ldup-subentry

LDAPサブエントリ・スキーマ

draft-ietf-sasl-crammd5

CRAM-MD5 SASLメカニズム

draft-ietf-sasl-rfc2831bis

SASLメカニズムとしてのダイジェスト認証の使用

draft-poitou-ldap-schema-update

LDAPスキーマ更新手順

draft-sermersheim-ldap-subordinate-scope

LDAPの従属サブツリー検索範囲

draft-vchu-ldap-pwd-policy

LDAPディレクトリのパスワード・ポリシー

draft-wahl-ldap-adminaddr

LDAP管理者アドレス属性

draft-weltman-ldapv3-proxy

LDAPのプロキシ設定された認可制御

draft-zeilenga-ldap-noop

LDAP操作なし制御

draft-zeilenga-ldap-entrydn

LDAP entryDN操作属性

C.3 Oracle Unified Directoryがサポートしているその他の仕様

表C-3は、Oracle Unified Directoryがサポートしているドキュメントおよび規格のリストです。

表C-3 Oracle Unified Directoryがサポートしているその他の仕様

番号

説明

DSMLv2.doc

OASISディレクトリ・サービス・マークアップ言語v2.0のドキュメント

DSMLv2.xsd

OASISディレクトリ・サービス・マークアップ言語v2.0の規格

FIPS 180-1

セキュア・ハッシュの規格(SHA-1)

FIPS 180-2

セキュア・ハッシュの規格(SHS) (FIPS PUB 180-2)

D Oracle Unified Directory用語集

この用語集ではLDAPおよびディレクトリ・サービスの説明に使用される用語を定義しており、Oracle Unified Directory固有の用語も含まれます。

D.1 A

D.1.1 中止操作

LDAP中止操作は、未処理リクエストの処理をサーバーが停止するようにリクエストするために使用できます。中止リクエストのプロトコルopは次のとおりです:

AbandonRequest ::= [APPLICATION 16] MessageID

リクエストで指定されたメッセージIDは、中止する操作のメッセージIDです。

中止操作にはレスポンスがないため、中止操作が正しく実行されたかどうかをクライアントが確認する方法はありません。同様に、操作が中止された場合は、それに対するレスポンスはありません。そのため、クライアントは送信されないレスポンスを長い間待っている可能性があります。どちらの問題も取消し拡張操作で説明されています。

バインド、アンバインド、中止およびTLS起動拡張操作は中止できません。

D.1.2 抽象オブジェクト・クラス

抽象オブジェクト・クラスは、エントリで直接は使用できませんが、構造オブジェクト・クラスまたは補助オブジェクト・クラスのサブクラスとする必要があります。そのサブクラスは、抽象クラスで定義される必須またはオプション、あるいはその両方の属性タイプを継承します。

LDAPで定義される最も重要な抽象オブジェクト・クラスのうちの1つがtopオブジェクト・クラスで、サーバー・スキーマで仮想的に定義されるその他すべてのオブジェクト・クラスのルート・クラスです。

D.1.3 抽象構文表記法1

抽象構文表記法1 (ASN.1)は、バイナリ形式でデータをエンコーディングするメカニズムです。各要素がタイプ、長さおよび値を保有するTLV構造を使用します。タイプ・コンポーネントは、要素内に保存される情報の種類を示し、値をエンコードする方法を示すデータ・タイプです。長さコンポーネントは値のバイト数を指定し、値コンポーネントは要素で保持される実データです。

ASN.1要素の例を次に示します:

Null

Null要素はどのような値も保持しません。通常、値の不要な要素を必要とする場合にプレースホルダとして使用されます。

Octet string

Octet string要素は0オクテット(バイト)以上のデータ・セットを保持します。文字列データまたはバイナリ・データの保持に使用できます。

Boolean

Boolean要素は、trueまたはfalseのいずれかを表す値を保持します。

Integer

Integer要素は、整数値を表す値を保持します。

Enumerated

Enumerated要素は、各値が特定の意味を保有する整数値を表す値を保持します。

Sequence

Sequence要素は、0個以上のSequence要素以外のASN.1要素を保持するコンテナで、要素の順序が重要な方式です。

Set

Set要素は、0個以上のSet要素以外のASN.1要素を保持するコンテナで、要素の順序は重要ではない方式です。

ASN.1はバイナリ・コーディング用の一般的なフレームワークですが、データのエンコード方法を実際には定義しないことに注意してください。エンコード方法はエンコーディング・ルールで処理され、多数の様々な種類のASN.1エンコーディング・ルールが存在します。LDAPでは基本エンコーディング・ルールエンコーディングが使用されますが、別のタイプではDistinguished Encoding Rules (DER)、Canonical Encoding Rules (CER)およびPacked Encoding Rules (PER)があります。

D.1.4 アクセス制御

アクセス制御は、ディレクトリ・サーバー内の様々な種類の情報にアクセスできるユーザーを制限するメカニズムを提供します。アクセス制御プロバイダは、次のような様々な事柄を制御するために使用できます:

- クライアントがサーバーからエントリを取得できるかどうか。

- クライアントが取得を許可されたエントリ内の属性の種類。

- クライアントが取得を許可された属性の値。

- クライアントがディレクトリ内でデータを操作できる方法。

アクセス制御の決定には、次のような様々な事柄を考慮できます:

- 認証されたユーザーとしてのDN。

- クライアントがサーバーへの認証を行った方法。

- ユーザーがメンバーである任意のグループ。

- 認証されたユーザーのエントリのコンテンツ。

- ターゲット・エントリのコンテンツ。

- クライアント・システムのアドレス。

- クライアントとサーバーの間の通信が保護されているかどうか。

- 試行の時刻または曜日、あるいはその両方。

アクセス制御構文の詳細は、第22章「データへのアクセス制御」を参照してください。

アクセス制御サブシステムに加えて、ディレクトリ・サーバーには、ユーザーに対する許可内容を制御するために使用できる特権もあります。使用可能な特権の1つはbypass-acl特権で、この特権がなければアクセス制御サブシステムにより強制される制限を、クライアントがバイパスできるようにするために使用できます。

D.1.5 アクセス制御命令(ACI)

「アクセス制御ルール」を参照してください。

D.1.6 アクセス制御ルール

アクセス制御ルール(アクセス制御命令またはACIとも呼ばれる)は、サーバーで数種類の操作を実行するユーザーまたはユーザー・セットに対してアクセス権限を与えるか、または拒否するために使用できるルールです。ディレクトリ・サーバーのアクセス制御ポリシーは、サーバーで定義されるアクセス制御ルールのセット全体で構成されます。

アクセス制御ルールで使用される構文、およびアクセス制御ルールを使用して許可または拒否できる操作の詳細は、第22章「データへのアクセス制御」を参照してください。

D.1.7 アクセス・ログ

ディレクトリ・サーバーのアクセス・ログは、すべての受信されたリクエストおよび返されたレスポンスを含め、サーバーにより処理されたすべての操作を追跡するメカニズムを提供します。サーバー内で実行された内部操作についての情報の取得にも使用される場合があります。

ディレクトリ・サーバーは、アクセス・ロガー(同様にエラー・ログおよびデバッグ・ログのロガー)を実装するための拡張可能なフレームワークを提供します。デフォルトのアクセス制御ログを実装すると、1つの操作ごとに2つのレコードを使用して情報をログ・ファイルに書き込みます。最初のレコードはクライアントから受信したリクエストを反映し、2番目のレコードは操作処理の結果の情報を提供します。

すべてのメッセージには、次のような要素の共通セットが含まれます:

- メッセージのログが記録された時間。

- 処理される操作のタイプ。

- 操作をリクエストしたクライアント接続の接続ID。

- クライアント接続上の操作の操作ID。

- 操作のリスエストに使用されたメッセージのメッセージID。

中止操作の場合は、リクエスト・ログ・メッセージには中止する操作のメッセージIDが含まれます。中止操作に対するレスポンスがなくても、サーバーは、中止が正しく実行されたかどうか、およびミリ秒単位の処理時間を示す結果メッセージをログに記録します。

追加操作の場合は、リクエスト・ログ・メッセージには追加するエントリの識別名が含まれます。応答ログ・メッセージには、操作の結果コード、診断メッセージ、一致したDN、認証IDおよびミリ秒単位の処理時間が含まれる場合があります。

バインド操作の場合は、リクエスト・ログ・メッセージには認証タイプ(SIMPLEまたはSASLとそれに続くメカニズム名)およびバインドDNが含まれます。レスポンス・ログ・メッセージには、結果コード、診断メッセージ、一致したDN、認証ID、認可IDおよびミリ秒単位の処理時間が含まれる場合があります。

比較操作の場合は、リクエスト・ログ・メッセージにはターゲット・エントリDNおよび属性タイプが含まれます。レスポンス・ログ・メッセージには、結果コード、診断メッセージ、一致したDN、認可IDおよびミリ秒単位の処理時間が含まれる場合があります。

削除操作の場合は、リクエスト・ログ・メッセージにはターゲット・エントリDNが含まれます。レスポンス・ログ・メッセージには、結果コード、診断メッセージ、一致したDN、認可IDおよびミリ秒単位の処理時間が含まれる場合があります。

拡張操作の場合は、リクエスト・ログ・メッセージには拡張されるリクエストのオブジェクト識別子が含まれます。レスポンス・ログ・メッセージには、拡張されたレスポンスのOID、結果コード、診断メッセージ、一致したDNおよびミリ秒単位の処理時間が含まれる場合があります。

変更操作の場合は、リクエスト・ログ・メッセージにはターゲット・エントリDNが含まれます。レスポンス・ログ・メッセージには、結果コード、診断メッセージ、一致したDN、認可IDおよびミリ秒単位の処理時間が含まれる場合があります。

DN変更操作の場合は、リクエスト・ログ・メッセージにはターゲット・エントリDN、新規RDN、旧RDN値を削除するかどうかを示すフラグおよび新規上位DNが含まれます。レスポンス・ログ・メッセージには、結果コード、診断メッセージ、一致したDN、認可IDおよびミリ秒単位の処理時間が含まれる場合があります。

検索操作の場合は、リクエスト・ログ・メッセージには検索ベースDN、検索範囲、LDAP検索フィルタおよび検索属性が含まれます。レスポンス・ログ・メッセージには、結果コード、返されたエントリ数、診断メッセージ、一致したDN、認可IDおよびミリ秒単位の処理時間が含まれる場合があります。

アンバインド操作の場合は、リクエスト・メッセージは、アンバインド・リクエストが受信されたことを示すのみです。アンバインド・リクエストに対するレスポンスおよび結果ログ・メッセージはありません。

D.1.8 アカウント有効期限

アカウント有効期限は、ディレクトリ・サーバー・パスワード・ポリシーのコンポーネントで、指定された日付を過ぎると、それ以降アカウントを使用できないことを示すために使用できます。この機能は、指定された日付の後で期限切れとなる一時的なユーザー・アカウント(契約者、インターンまたはその他の一時的な職員用など)の作成に役立ちます。

アカウント有効期限を有効化するには、ターゲット・ユーザーのエントリにds-pwp-account-expiration-time操作属性を追加します。この属性の値は、アカウントの有効期限とする時刻を指定する、一般的な時刻形式のタイムスタンプです。アカウント有効期限の時刻が過ぎると、ユーザーはサーバーに対する認証を許可されません。

D.1.9 アカウント・ロックアウト

アカウント・ロックアウトは、ディレクトリ・サーバー・パスワード・ポリシーのコンポーネントで、バインドの試行に何度も失敗した後でユーザー・アカウントをロックするために使用できます。アカウントがロックされると、ユーザーは認証を許可されません。ロックアウトは、一時的(指定された期間の後で自動的に終了)または永続的(管理者がユーザーのパスワードをリセットするまで有効)にできます。

D.1.10 アカウント・ステータス通知

アカウント・ステータス通知は、サーバーのパスワード・ポリシーに関わる重要な方法でユーザー・アカウントが変更されたことを示すために使用できるメカニズムです。

サーバーで使用可能なアカウント・ステータス通知のタイプには次のものがあります:

- ユーザーのアカウントがアカウント・ロックアウトになった場合

- ユーザーのアカウントがアカウント・ロックアウトになった場合

- ユーザーのアカウントが管理者にロック解除された場合

- ユーザーのアカウントが管理者に手動で無効化または再有効化された場合

- ユーザーのアカウント有効期限を過ぎている場合

- ユーザーのパスワード有効期限を過ぎているか、間もなく有効期限となる場合

- ユーザーのパスワードがパスワードのリセットをされた場合

- ユーザーのパスワードがエンド・ユーザーにより変更された場合

ディレクトリ・サーバーは、アカウント・ステータス通知を処理するために拡張可能なフレームワークを提供します。デフォルトのハンドラはサーバーのエラー・ログにメッセージを書き出しますが、フレームワークを使用して電子メール・メッセージを送信したり、必要なその他のアクションを実行したりできます。

D.1.11 アカウント・ユーザビリティ制御

アカウント・ユーザビリティ制御は、ユーザー・アカウントがサーバーに対する認証に使用できるかどうかを判断するための1組のリクエストとレスポンスの制御を提供します。

リクエスト制御のOIDは1.3.6.1.4.1.42.2.27.9.5.8で、値はありません。検索操作メッセージに含まれるのみです。

対応するレスポンス制御のOIDは1.3.6.1.4.1.42.2.27.9.5.8(リクエスト制御と同様)で、アカウント・ユーザビリティ・リクエスト制御を含む検索リクエストに対する検索結果エントリ・メッセージに含まれます。

アカウント・ユーザビリティ・レスポンス制御の値は、次のようにエンコードされます:

ACCOUNT_USABLE_RESPONSE ::= CHOICE {
is_available           [0] INTEGER, -- Seconds before expiration --
is_not_available       [1] MORE_INFO }

MORE_INFO ::= SEQUENCE {
inactive               [0] BOOLEAN DEFAULT FALSE,
reset                  [1] BOOLEAN DEFAULT FALSE,
expired                [2] BOOLEAN DEFAULT_FALSE,
remaining_grace        [3] INTEGER OPTIONAL,
seconds_before_unlock  [4] INTEGER OPTIONAL }

ユーザー・アカウントが使用可能な場合は、制御にはユーザーのパスワード有効期限までの秒数または-1(パスワード有効期限が有効ではない場合)が含まれます。ユーザー・アカウントが使用可能でない場合は、制御には使用可能でない理由が示されます。

検索リクエストでこの制御を使用する例は、「アカウント・ユーザビリティ・リクエスト制御を使用した検索」を参照してください。

D.1.12 ACID

ACIDは、原子性(Atomicity)、一貫性(Consistency)、独立性(Isolation)および永続性(Durability)を略した頭字語です。この用語は、データベースのトランザクション特性を使用して実現できる特質に関する標準データベース用語です。次の要素があります:

原子性

データベースで実行される各トランザクションは原子的です。つまり、完全に成功または完全に失敗のいずれかです。トランザクションの一部の変更が適用されてそれ以外は適用されないような変更は、部分的な成功ではありません。

一貫性

データベースは常に一貫性のある状態で、コンテンツの整合性が保たれています。トランザクションの成功または失敗に対して、データベースを一貫性のない状態にできないようにする必要があります。

独立性

トランザクションの一部として実行される操作は、データベース内で同時に実行されるその他の操作から独立しています。あるトランザクションがデータベース・コンテンツに対するいくつかの変更に使用される場合は、別のトランザクション操作は変更がコミットされるまで変更の結果を確認できないようにする必要があります。

永続性

データベースにより、正常に完了し、コミット済と報告されたトランザクションはいずれも、永続的な記憶域での保存が保証されます。ディレクトリ・サーバー、基礎となるJVM、オペレーティング・システムまたはハードウェアで、コミット完了の通知の直後に障害が発生しても、変更は失われません。

主要なバック・エンドのデータ・ストアとして使用されるBerkeley DB Java Editionは、ACID準拠をフル・サポートします。ただし、パフォーマンスの理由により必要があれば、これらの制約に対する準拠を緩和する方法もあります。ディレクトリ・サーバーは、このような柔軟性、特に変更を永続的に保持するための構成に関して公開しています(たとえば、変更をすぐにディスクに出力しないようにサーバーを構成することも可能です。これにより、書出しのパフォーマンスを向上させることができますが、ハードウェアまたはソフトウェアの障害が発生した場合にいくつかの変更を消失する原因になる可能性があります)。

D.1.13 追加操作

LDAP追加操作は、ディレクトリ・サーバーでのエントリの作成に使用できます。追加リクエストのプロトコルopは次のように定義されます:

AddRequest ::= [APPLICATION 8] SEQUENCE {
entry           LDAPDN,
attributes      AttributeList }

このリクエストに含まれる要素には、追加するエントリの識別名およびそのエントリに含まれる属性のセットがあります。

LDAP追加操作に対するレスポンスはLDAP結果要素で、次のように定義されます:

AddResponse::= [APPLICATION 9] LDAPResult

D.1.14 別名

別名は、サーバー内の別のエントリを参照する特別なタイプのエントリで、UNIXファイル・システムのシンボリック・リンクによく似ています。aliasオブジェクト・クラス、および別名が参照するエントリのDNと等しい値を持つaliasedObjectName属性が含まれています。

別名は、主に検索操作で使用されます。特に、検索リクエストには、別名を検出する際に使用される間接参照ポリシーを指定する要素が含まれています。使用できる間接参照ポリシーの値には次のものがあります:

neverDerefAliases

サーバーは別名エントリを間接参照しません。

derefInSearching

サーバーは、考えられる検索結果エントリのセットで検出した別名エントリを間接参照しますが、検索ベースDNが別名エントリを指定する場合は、間接参照しません。

derefFindingBaseObj

サーバーは、検索ベース・エントリが別名の場合は間接参照しますが、考えられる検索結果エントリのセット内の別名は間接参照しません。

derefAlways

サーバーは、検索ベース・エントリまたは考えられる検索結果エントリのセットのどちらかで検出された別名を間接参照します。

別名はLDAPv3プロトコルのオプション部分であり、ディレクトリ・サーバーは現在、別名をサポートしていないことに注意してください。

D.1.15 AND検索フィルタ

AND検索フィルタは、0個以上のその他の検索フィルタを保持するコンテナとして機能するための、LDAP検索フィルタのタイプです。エントリがANDフィルタと一致するには、ANDフィルタに含まれるすべてのフィルタと一致する必要があります。

ANDフィルタは、フィルタ全体をカッコで囲み、左カッコの直後にアンパサンドを配置した文字列で表すことができます。たとえば、フィルタ(&(objectClass=person)(uid=john.doe))は、(objectClass=person)および(uid=john.doe)の等価フィルタが埋め込まれたAND検索フィルタを表します。

埋込みフィルタを含まないANDフィルタは、LDAP trueフィルタと呼ばれます。LDAP trueフィルタの文字列表現はアンパサンド(&)で、LDAP trueフィルタは常に任意のターゲット・エントリと一致します。

D.1.16 匿名バインド

匿名バインドはバインド操作のタイプで、長さ0のバインドDNおよび長さ0のパスワードを使用する簡易認証を使用します。ある接続で実行された直前の認証を破棄し、未認証のステータスを返すために使用できます。

同じ結果となるANONYMOUS SASLメカニズムがありますが、通常は匿名バインドという用語はDNおよびパスワードなしの簡易バインド操作を指すことに注意してください。

D.1.17 ANONYMOUS SASLメカニズム

ANONYMOUS SASLメカニズムは、Simple Authentication and Security Layer認証メカニズムのタイプです。その他のSASLメカニズムとは未認証セッションの作成に使用される点で異なっており、接続で実行された可能性のある直前の認証を破棄します。

ANONYMOUS SASLメカニズムは、サーバーのアクセス・ログに含めることのできるリクエストに追跡情報を追加する機能があります。この追跡情報は、バインドを実行するクライアントの情報を提供できます。ただし、認証が実行されていないため、追跡情報の有効性は保証できません。

D.1.18 近似索引

近似索引は、指定されたアサーション値におおよそ等しいエントリを効率的に識別するために使用される索引のタイプです。近似索引は、対応する近似一致ルールを保有する属性に対してのみ維持できます。この一致ルールは索引キーとして使用する正規化された値に対して使用され、そのキーの値は、正規化された値におおよそ等しい値を持つエントリのエントリIDを含むIDリストです。

D.1.19 近似検索フィルタ

近似検索フィルタはLDAP検索フィルタのタイプで、指定されたアサーション値におおよそ等しい、指定された属性の値を含むエントリを識別するために使用できます。サーバーは、近似一致ルールを使用して判断します。

LDAP近似フィルタの文字列表現は、左カッコに続く属性名、チルダ記号、等号、属性値および右カッコで構成されます。たとえば、近似フィルタ(givenName~=John)は、Johnとおおよそ等しい値を含むgivenName属性のエントリと一致します。

D.1.20 ASN.1

「抽象構文表記法1」を参照してください。

D.1.21 アサーション値

アサーション値は、属性値アサーションの値です。アサーション値は、指定された属性の属性値を判断するために一致ルールに指定します。

D.1.22 属性

属性は値の名前付きセットです。属性は属性説明を保有し、その内容には、その属性の名前(属性タイプに関連付けられた名前)、属性オプションのオプション・セットおよび1つ以上の値の集合が含まれます。

エントリには属性の集合が含まれます。エントリが、同じ属性タイプで異なるオプション・セットを伴う複数の属性を持つことは可能です。

D.1.23 属性説明

属性説明は、エントリ内で指定された属性を識別するために使用されます。属性説明には、属性タイプに関連付けられた名前またはOID、および0個以上の属性オプションが含まれます。属性説明に任意の属性オプションが含まれている場合は、属性名またはOIDとはセミコロンで区切られ、その属性説明に複数のオプションが含まれている場合は、個々の属性オプションもセミコロンを使用して区切られます。

D.1.24 属性オプション

属性オプションは、属性の解釈方法についての追加情報を指定するタグの種類です。属性説明には、属性名またはオブジェクト識別子とそれに続く0個以上の属性オプションが含まれます。属性オプションが複数存在する場合は、属性名と、および各属性オプションとは互いにセミコロンを使用して区切られます。たとえば、属性説明userCertificate;binaryでは、属性名はuserCertificateで、属性オプションはbinaryです。

属性オプションは、サーバーが属性を取り扱う方法についての情報(RFC 4522 (http://www.ietf.org/rfc/rfc4522.txt)で説明されるバイナリ・エンコーディング・オプションなど)の提供を含め、いくつかの目的に使用できます。また、属性オプションはいくつかの形式でクライアントにも利点があります(たとえば、RFC 3866 (http://www.ietf.org/rfc/rfc3866.txt)で説明される言語タグ・オプションは、異なる言語での属性値の指定を可能にします)。

D.1.25 属性構文

属性構文は、スキーマ要素であり、属性値に保存できる情報の種類を指定するためのデータ・タイプの種類を定義します。関連付けられた属性タイプの構文に違反する属性値を保存しようとすると、却下されます。

一般的な属性の構文には次のものがあります:

バイナリ

テキスト情報かどうかにかかわらず、任意の種類のデータを保持することが可能で、バイト対バイト・ベースで比較する必要があります。オクテット文字列構文が優先され、バイナリ構文は非推奨になっていることに注意してください。

Boolean

TRUEまたはFALSEのいずれかの値を保持できます。

ディレクトリ文字列

任意の種類の文字列値を保持できます(技術的にはバイナリ値も許容されますが、通常、ディレクトリ文字列値は文字列です)。

識別名

有効な識別名の値を保持できます。

一般的な時刻

タイムゾーン情報および有効桁数が変化するタイムスタンプ(時から秒の小数部までの任意の部分)を含む値を保持できます。たとえば、値20070525222745Zは、UTCタイムゾーンで2007年5月25日午後10時27分45秒のタイムスタンプを表します。

IA5文字列

ASCII文字列を含む値を保持できます(つまり、非ASCII文字の使用は許可されません)。

Integer

整数値を保持できます。正数、負数および0の値も可能です。

オクテット文字列

任意の種類のデータの保持が可能で、バイト対バイト・ベースで比較する必要があります。

住所

複数行の住所の保持が可能で、住所の行はドル記号で区切られます。

印刷可能文字列

印刷可能な文字を任意に組合せた文字列を保持できます。印刷可能な文字には、すべてのASCII文字の大文字と小文字、数字、空白および記号'()+,-.=/:?が含まれます。

電話番号

電話番号の値を保持できます。

サーバーで定義される属性構文のセットは、サブスキーマ・サブエントリのldapSyntaxes属性を取得して確認できます。属性構文の詳細は、「属性構文の理解」を参照してください。

D.1.26 属性タイプ

属性タイプはスキーマ要素であり、オブジェクト識別子、属性構文を伴う名前のセットおよび一致ルールのセットに関連付けられます。

属性タイプのコンポーネントの定義は次のとおりです:

- 属性タイプを一意に識別するために使用されるOID。

- 属性タイプの参照をより容易にするために使用できる0個以上の名前のセット。

- 属性の値に対する等価一致の実行方法を指定する、オプションの等価一致ルール。等価一致ルールが指定されない場合は、デフォルトの等価ルールが関連付けられた属性構文で使用されます。関連付けられた構文にデフォルトの等価一致ルールが存在しない場合は、その属性に対する等価操作は許可されません。

- 属性の値に対する順序付け操作の実行方法を指定する、オプションの順序付け一致ルール。順序付け一致ルールが指定されない場合は、デフォルトの順序付けルールが関連付けられた属性構文で使用されます。関連付けられた構文にデフォルトの順序付け一致ルールが存在しない場合は、その属性に対する順序付け操作は許可されません。

- 属性の値に対する部分文字列一致の実行方法を指定する、オプションの部分文字列一致ルール。部分文字列一致ルールが指定されない場合は、デフォルトの部分文字列ルールが関連付けられた属性構文で使用されます。関連付けられた構文にデフォルトの部分文字列一致ルールが存在しない場合は、その属性に対する部分文字列操作は許可されません。

- 属性の値に対する構文を指定する、オプションの構文OID。構文が指定されない場合は、ディレクトリ文字列構文にデフォルト設定されます。

- 属性が複数の値を持つことを許可されているかどうかを示すフラグ。

- 属性が使用されるコンテキストを示す、オプションの属性使用方法文字列。

- 外部クライアントが属性を変更できるかどうかを示す、オプションのフラグ。

サーバーで定義される属性タイプのセットは、サブスキーマ・サブエントリのattributeTypes属性を取得して確認できます。属性タイプの詳細は、「属性タイプの理解」を参照してください。

D.1.27 属性使用方法

属性タイプの属性使用方法は、属性タイプを使用できるコンテキストを定義します。属性使用方法には、次の4つのタイプがあります:

userApplications

ユーザー定義データの保持に使用するためのすべての属性タイプで使用されます。

directoryOperation

サーバー内の暗黙的な処理のための属性タイプで使用されます。

distributedOperation

ディレクトリ環境全体に配布する必要のある操作データ(つまりレプリケーション)を保管する属性タイプで使用されます。

dSAOperation

1台のサーバーのみで保管し、ディレクトリ環境全体にレプリケートしてはならない操作データを保管する属性タイプで使用されます。

使用方法userApplicationsを持つ属性は、いわゆるユーザー属性です。使用方法directoryOperation、distributedOperationまたはdSAOperationを持つ属性は、いわゆる操作属性です。

D.1.28 属性値

属性値は、属性により保持される実データの要素を示します。関連付けられた属性タイプにより許可された場合は、属性は複数値を保有できます。サーバーが属性値と相互に作用する方法は、属性の属性構文および一致ルールにより制御されます。

D.1.29 属性値アサーション

属性値アサーション(AVA)は、属性説明および属性値の組合せです。アサーション値は、判断のために一致ルールとともに使用されます。一致ルールが等価一致ルールの場合は、属性に指定された値が含まれているかどうかの判断に使用されます。順序付け一致ルールの場合は、AVAは、アサーション値以上の値または以下の値が属性に含まれているかどうかの判断に使用されます。近似一致ルールの場合は、AVAは、アサーション値におおよそ等しい値が属性に含まれているかどうかの判断に使用されます。部分文字列一致はより複雑で、簡易アサーション値ではなく部分文字列アサーションを使用します。

属性値アサーションはLDAP比較操作および等価検索フィルタ、大きいか等しい検索フィルタ、小さいか等しい検索フィルタおよび近似検索フィルタの検索フィルタで使用されます。

D.1.30 監査ログ

監査ログは特別なタイプのアクセス・ログで、サーバーで実行されるすべての変更の情報をログに記録するために使用されます。これらの変更のログはLDAPデータ変換形式で記録され、管理者は実行された変更を正確に確認できます。この情報は、問題を調査する際に診断のために使用可能で、アプリケーションがディレクトリで実行する可能性のある変更の種類をより理解しやすくし、別のリポジトリに対するリプレイの変更について正しい情報を得るために役立ちます。

監査ログという名前は、Netscape Directory Serverでの監査ログの使用を指すレガシー用語です。セキュリティ監査で使用される場合のあるログと混同しないでください。監査ログは、ディレクトリ・データに対する変更を記録するのみで、認証の試行の成功または失敗などは追跡しません。ただし、多くの場合、従来のアクセス・ログおよび監査ログの内容を組み合せて使用し、このような種類の情報を取得できます。必要に応じて、管理者はカスタム・アクセス・ログを実装して、希望する種類の情報の追跡もできます。

D.1.31 認証

認証は、クライアントがクライアント自体をディレクトリ・サーバーに認証要求し、アイデンティティを証明するプロセスです。LDAPでは、バインド操作を使用して実行されます。

認証プロセスには次の2つのフェーズがあります:

識別

クライアントは、いくつかの方法でクライアント自体をサーバーに認証要求します。簡易認証では、バインド・リクエストで指定されたDNがこのために使用されます。Simple Authentication and Security Layer認証では、クライアントのアイデンティティはその他いくつかの方法(証明書、Kerberosプリンシパルまたはその他数種類の識別子の使用など)で取得されます。

アイデンティティの検証

クライアントは、クライアント自体の認証要求をしたユーザーが誰であるかを十分に証明する必要があります。簡易認証では、パスワードを使用して実行されます。SASL認証では、この検証は関連付けられたメカニズム固有の方法で取得されます(パスワード、証明書またはその他の証明の形式の場合があります)。

他のメカニズムよりも厳格であるとみなされる認証メカニズムもあります。たとえば、クライアントの保有するパスワードの推測やその他の方法による取得が容易である場合は、簡易認証はより信頼性が低いと考えられ、証明書またはKerberos資格証明を使用した認証はより厳格でねつ造は困難であると考えられる可能性があります。ディレクトリ・サーバーのアクセス制御を実装すると、リクエストされた操作を許可するかどうかを判断する際に、クライアントの認証メカニズムを考慮するように構成できます。

D.1.32 認証ID

認証IDは、Simple Authentication and Security Layerメカニズムの特定の種類(CRAM-MD5 SASLメカニズム、DIGEST-MD5 SASLメカニズムおよびPLAIN SASLメカニズムなど)で、クライアント自体をディレクトリ・サーバーに認証要求するクライアントに使用される識別子です。認証IDを使用して、識別名ではなくユーザー名(またはその他のわかりやすい識別子)でクライアントがクライアント自体を認証要求できます。

多くの場合、認証IDは次の形式のうちの1つに指定されます:

- 文字列dn:とそれに続くターゲット・ユーザーの識別名(または匿名ユーザーの認証アイデンティティとする必要がある場合は、文字列dn:のみ)。

- 文字列u:とそれに続くユーザーの認証要求に使用されるユーザー名。アイデンティティ・マッパーを使用して、入力されたユーザー名を対応するユーザー・エントリにマッピングします。

D.1.33 認証パスワード構文

認証パスワード構文は、サーバーの記憶域用のユーザー・パスワードをエンコードする標準メソッドを定義します。パスワードのクリアテキスト値の確認を困難あるいは不可能にする方法をお薦めします。

認証パスワード構文はRFC 3112 (http://www.ietf.org/rfc/rfc3112.txt)で説明されており、そこではauthPassword属性タイプ、およびその属性が使用可能な、対応するauthPasswordObject補助オブジェクト・クラスを定義します。

認証パスワード構文を使用してエンコードされるパスワードの基本的な形式は次のとおりです:

scheme $authInfo $ authValue

schemeは値のエンコードに使用されるスキームの名前、authInfoはエンコーディング処理で使用される数種類の修飾子(saltなど)、およびauthValueはエンコードされるパスワードの情報です。たとえば、値SHA1$RzqH67DY3uQ=$atAcDs1eS+IJwPy7V4UDXEoBrDI=を認証パスワード構文を使用してエンコードします。スキームはSHA1、authInfo要素はRzqH67DY3uQ=、authValue要素はatAcDs1eS+IJwPy7V4UDXEoBrDI=です。

ディレクトリ・サーバーでサポートされている認証パスワード・スキームには、次のものがあります:

MD5

MD5メッセージ・ダイジェストを使用します。

SHA1

セキュア・ハッシュ・アルゴリズムのSHA-1バリアントを使用します。

SHA256

セキュア・ハッシュ・アルゴリズムの256ビットSHA-2バリアントを使用します。

SHA384

セキュア・ハッシュ・アルゴリズムの384ビットSHA-2バリアントを使用します。

SHA512

セキュア・ハッシュ・アルゴリズムの512ビットSHA-2バリアントを使用します。

D.1.34 認可

認可は、リクエストされた操作の実行をユーザーが許可されているかどうかを判断するプロセスです。次のような様々なサーバー・コンポーネントが認可プロセスに関わっています:

- アクセス制御ハンドラ。

- 特権サブシステム。

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

- サーバーにインストールされたカスタム・プラグイン。

D.1.35 認可ID

認可IDは、クライアントに使用される識別子で、代替認可アイデンティティの下で実行される1つ以上の操作を示します。この代替認可アイデンティティは、1つの操作の間(プロキシ認可制御とともに使用される場合)または認証セッションが継続している期間(DIGEST-MD5 SASLメカニズム、GSSAPI SASLメカニズムまたはPLAIN SASLメカニズムなどのSASLに近いメカニズムとともに使用される場合)、継続できます。

多くの場合、認可IDは次の形式のうちの1つに指定されます:

- 文字列dn:とそれに続くターゲット・ユーザーの識別名(または匿名ユーザーの認可IDとする必要がある場合は、文字列dn:のみ)。

- 文字列u:とそれに続くユーザーの認証要求に使用されるユーザー名。アイデンティティ・マッパーを使用して、入力されたユーザー名を対応するユーザー・エントリにマッピングします。

代替認可アイデンティティを使用するクライアントの機能は、proxied-auth特権で制御されます。追加のアクセス制御権限が要求される場合もあります。

D.1.36 認可アイデンティティ制御

認可アイデンティティ制御は、RFC 3829 (http://www.ietf.org/rfc/rfc3829.txt)で定義される1組のリクエスト制御とレスポンス制御で、バインド操作とともに使用して、クライアント接続のための認可アイデンティティをクライアントが確認できるようにします。

認可アイデンティティ・リクエスト制御のオブジェクト識別子は2.16.840.1.113730.3.4.16で、値はありません。認可アイデンティティ・レスポンス制御のOIDは2.16.840.1.113730.3.4.15で、その制御の値は、その接続の認可アイデンティティを表す文字列(または匿名ユーザーの認可アイデンティティの場合は空の文字列)です。レスポンス制御は、認証が成功した場合にのみ、レスポンスに追加されます。

認可アイデンティティ制御は、LDAPバインド操作と一緒の場合にのみ使用できるため、クライアントが認可された後は使用できないことに注意してください。Who Am I拡張操作を使用して、バインドが完了した後でいつでも、認可アイデンティティを取得できます。

検索リクエストでこの制御を使用する例は、「認可アイデンティティ・リクエスト制御を使用した検索」を参照してください。

D.1.37 補助オブジェクト・クラス

補助オブジェクト・クラスは、エントリのコア・タイプを定義するものではありませんが、エントリの追加特性を定義します。1つのエントリは、0個以上の補助オブジェクト・クラスを持つことができます。エントリで使用できる補助クラスのセットは、エントリの構造オブジェクト・クラスに関連付けられたDITコンテンツ・ルールにより制御される場合があります。

D.1.38 AVA

「属性値アサーション」を参照してください。

D.2 B

D.2.1 バックエンド

ディレクトリ・サーバーのバックエンドは、データを保管するリポジトリ、およびデータと相互に作用するためのロジックのセットを提供します。通常バックエンドには数種類のデータベースがあり、様々な操作でバックエンドが迅速にエントリを見つけられるように索引のセットが維持される場合があります。すべてのバックエンドには次のような特質があります:

- バックエンドIDは、サーバー内のその他すべてのバックエンドから、該当のバックエンドを一意に識別します。

- 1つ以上のベース識別名のセットは、バックエンドが保持するデータを示します。

- 書込み可能モードは、バックエンドが書込み操作を許可するかどうかを示します。

バックエンドが提供するロジックには次のものがあります:

- DNに基づき、指定されたエントリが存在するかどうかを判断するメソッド

- DNに基づき、エントリを取得するメソッド

- データベースに新規のエントリを追加するメソッド(LDAP追加操作の処理の一部として)

- データベースから既存のエントリを削除するメソッド(LDAP削除操作の処理の一部として)

- データベースでエントリを置換するメソッド(LDAP変更操作の処理の一部として)

- データベースでエントリの名前を変更するメソッド(LDAP DN変更操作の処理の一部として)

- LDAP検索操作を処理するメソッド

- LDAPデータ変換形式でデータベースのコンテンツをエクスポートするメソッド

- LDAPデータ変換形式でデータベースにデータをインポートするメソッド

- データのバックアップを実行するメソッド

- 以前のバックアップの復元を実行するメソッド

D.2.2 バックアップ

バックアップは、ディレクトリ・サーバーのバックエンド内でデータが移動可能であることを表します。各バックエンドは、そのコンテンツのバックアップが可能かどうかを制御し、バックアップ情報が後で実行される復元に適していることを確認します。バックアップする(back up)という用語は動詞(バックエンドのコンテンツをバックアップするアクション)であり、バックアップ(backup)は名詞(バックアップを実行して取得されるもの)であることに注意してください。

バックエンドがバックアップ・メカニズムを提供できない理由がいくつかあります。理由には次のものがあります:

- バックエンドには一時的な、ある時点の情報のみが存在し、この情報をアーカイブしたり、後で復元を試みたりすることは意味がありません(ルートDSEまたは監査バックエンドなど)。

- バックエンドは直接アーカイブできないリモート・リポジトリに情報を保存します。このような場合は、外部リポジトリには通常、それ自体のバックアップおよび復元メカニズムがあります。

ディレクトリ・サーバーが使用する主要なバックエンドは、Berkeley DB Java Editionを使用しており、その基礎となるデータベースおよびバックエンドは完全なバックアップ機能と復元機能を提供します。また、そのバックアップ・メカニズムは移植性が高く、異なるプラットフォーム、異なるファイルシステムの場所に転送が可能で、バイナリ・コピー・メカニズムとしての使用に適しています。

D.2.3 base64エンコーディング

Base64エンコーディングは、テキストのみの形式でバイナリ・データを表す方法です。通常、非ASCII文字を含む値または不明瞭になる可能性のある値(空白で開始または終了する値など)に対して、LDAPデータ変換形式で使用されます。また、証明書のコンテンツや、MD5またはセキュア・ハッシュ・アルゴリズムなどのメッセージ・ダイジェストの出力をエンコードするために頻繁に使用されます。base64エンコーディングは、RFC 1341 (http://www.ietf.org/rfc/rfc1341.txt)の第5.2項で説明されています。

base64エンコーディングの基本原則は、次の文字を含む64文字のアルファベットを指定された順序で定義することです:

ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/

これらの各文字に、リスト内の位置に基づいて0から63の間の数値が割り当てられています(つまり、Aは0、Bは1、Cは2、...+は62および/は63)。値は6ビットのセグメントに細分化され、各6ビットのセグメントは0から63の間の数値に変換され、前述のように指定されたアルファベットから指定された文字に置換されます。これは、バイナリ値の各3バイトがbase64アルファベットの4文字に変換されることを意味します。バイナリ値の長さが3バイトの倍数でない場合は、0を充当し、base64でエンコードされた値の最後に1つまたは2つの等号を付与します。

D.2.4 基本エンコーディング・ルール

基本エンコーディング・ルール(BER)は、抽象構文表記法1エンコーディング・ルールのセットで、情報をバイナリ形式でエンコードする特定の方法を定義します。メッセージをエンコードする基礎的なメカニズムとして使用されます。

D.2.4.1 基本エンコーディング・ルールの概要

多くのネットワーク・プロトコルはテキストベースで、ネットワークのトラフィックを調べる場合に比較的理解しやすいという利点があります。多くの場合、ターゲット・サーバーにtelnet接続して適切なコマンドを入力することによって、ターゲット・サーバーと対話することさえできます。ただし、一般的に、必要以上に冗長で解析が非効率であることなど短所もあります。一方、その他のプロトコルでは、より簡潔で効率的なバイナリ・エンコーディングを使用しています。LDAPはこのカテゴリに属しており、ASN.1(抽象構文表記法1)メカニズム、具体的にはASN.1の種類であるBER(基本エンコーディング・ルール)を使用します。その他にもASN.1に含まれる多くのエンコーディング・ルール(DER、PERおよびCERなど)がありますが、LDAPではBERを使用します。

この項では特にLDAPで使用されるBERのサブセットについて説明し、その他の場合については説明していません。

BER要素はTLV構造を使用し、TLVはタイプ(type)、長さ(length)および値(value)の略です。つまり、次の項で説明するとおり、各BER要素は、1バイト以上で示される要素のデータ・タイプ(通常LDAPでは1バイトのみ)、1バイト以上で示される値の長さ、0バイト以上の値自体のエンコードされた値(エンコードされた値の形式はデータ・タイプに依存)を保有します:

- BERタイプ

- BERの長さ

- BERの値

D.2.4.2 BERタイプ

BERタイプは要素の値のデータ・タイプを示します。BERの仕様では数種類のデータ・タイプがありますが、LDAPで最も一般的に使用されるものにはOCTET STRING(テキスト文字列またはバイナリ・データのいずれも可能)、INTEGER、BOOLEAN、NULL、ENUMERATED (integerと似ているが、各値が特別な意味を保有)、SEQUENCE(配列のように、順序付けられたその他の要素の集合)およびSET(順序に意味を持たない点を除けばsequenceと同様)があります。CHOICE要素もありますが、通常、複数の異なる種類の要素のうち1つを許可します。

通常、BERタイプは1バイトのみで、このバイトにエンコードされたデータが含まれています。2つの最も重要なビット(一番左の2ビット、BERではビッグ・エンディアン/ネットワーク順序を使用するため)が、次のクラス値により、要素のクラスを示すために使用されます:

00

ユニバーサル・クラス。ほとんどのBER要素はユニバーサル・タイプを保有するため、ユニバーサル・タイプを保有する要素は保持するデータの種類を指定します。ユニバーサル・タイプの例には、0x01 (BOOLEAN)、0x02 (INTEGER)、0x04 (OCTET STRING)、0x05 (NULL)、0x0A (ENUMERATED)、0x30 (SEQUENCE)および0x31 (SET)があります。これらのタイプの値すべてのバイナリ・エンコーディングで、一番左の2ビットを0に設定します。

01

アプリケーション固有クラス。このクラスは、アプリケーション全体を通して一貫性のある独自のタイプを、アプリケーションで定義できます。このコンテキストでは、LDAPはアプリケーションとみなされます。たとえば、LDAPで0x42が出現した場合は、アンバインド・リクエスト・プロトコルopを示します。なぜなら、RFC 2251の第4.3項(https://tools.ietf.org/html/rfc2251#section-4.3)で説明されるように、アンバインド・リクエスト・プロトコルopには[APPLICATION 2]タイプがあるためです。

10

コンテキスト固有クラス。このクラスは、指定されたアプリケーション内の特定の使用方法に固有のタイプであることを示します。指定された状況で、適用するコンテキストを判断するための情報が十分であれば、同じタイプを同じアプリケーションの異なるコンテキストで再使用することもできます。たとえば、バインド・リクエスト・プロトコルopの資格証明のコンテキストで、コンテキスト固有のタイプ0x80がバインド・パスワードの保持に使用されますが、拡張操作のコンテキストでリクエストOIDの保持に同じタイプが使用される場合があります。

11

プライベート・クラス。LDAPでは通常使用されません。

次のビット(左から3番目)はプリミティブ/コンストラクテッド・ビットです。0(オフ)に設定されている場合は、その要素はプリミティブとみなされ、データ・タイプのルールに応じて値がエンコードされます。1(オン)に設定されている場合は、エンコードされた形式で一緒に連結された0個以上のほかのASN.1要素から、値が構築されることを意味します。たとえば、ユニバーサルSEQUENCEタイプの0x30の場合は、バイナリ・エンコーディングは00110000で、プリミティブ/コンストラクテッド・ビットは1に設定されており、sequenceの値が0個以上のエンコードされた要素から構築されることを示します。

BERタイプのバイトの最後の5ビットはそのタイプの値を指定し、単純な整数値として取り扱われます(00000は0、00001は1、00010は2、00011は3など)。唯一の特別な値は11111で、タイプの値が、使用可能な5ビットに収まらない大きな値であり、複数のバイトが必要であることを意味します。この値はLDAPでは使用されません。

D.2.4.3 BERの長さ

BER要素のTLV構造で、2番目のコンポーネントは長さです。これは、エンコードされた値のサイズをバイト単位で指定します。ほとんどの場合は、ここでは整数値のバイナリ・エンコーディングをそのまま使用します(たとえば、エンコードされた値が5バイト長の場合は、バイナリで00000101または16進数で0x05とエンコードされます)が、値が127バイトよりも長い場合は、長さのエンコーディングに複数のバイトが必要です。その場合、第1バイトの一番左のビットを1に設定し、残りの7ビットを長さ全体のエンコーディングに必要なバイト数を指定するために使用します。たとえば、500バイトの長さ(16進数で0x01F4)の場合は、エンコードされた長さは実際には次の3バイトで構成されます: 82 01 F4。

長さをエンコードするための別の形式として、いわゆる不特定形式があることに注意してください。このメカニズムでは、長さの一部のみが一度に指定され、HTTP 1.1で使用可能なチャンク・エンコーディングに似ています。ただし、RFC 2251第5.1項(https://tools.ietf.org/html/rfc2251#section-5.1)で説明されるように、LDAPではこの形式は使用されません。

D.2.4.4 BERの値

BER要素には要素の実データが含まれます。BERはバイナリ・エンコーディングのため、このエンコーディングには、データを簡潔な形式で表現できるという利点があります。したがって、各データ・タイプは、次のようにデータ・タイプ自体のエンコードされた形式を持っています:

NULL

NULL要素には値がなく、そのため長さは常に0です。

OCTET STRING

この要素の値は、表現するデータの未処理のバイトを連結したものとしてエンコードされます。たとえば、文字列Helloを表すには、エンコードされた値は48 65 6C 6C 6Fになります。値の長さを0バイトにすることもできます。

BOOLEAN

この要素の値は常に1バイトです。そのバイトのすべてのビットが0 (0x00)に設定されている場合は、値はFALSEです。1つ以上のビットが1に設定されている場合は、値はTRUEです。その結果、TRUEのBOOLEAN値をエンコードする方法が255通りありますが、実際には、通常0xFF(つまりすべてのビットを1に設定)としてエンコードされます。

INTEGER

この要素の値は、2の補数形式のバイナリ整数としてエンコードされます。BER自体はエンコードできる値の大きさに制限を設けていませんが、多くのソフトウェアの実装では4バイトまたは8バイト(つまり32ビットまたは64ビットの整数値)の制限があり、通常LDAPでは最大4バイトを使用します(プラスマイナス20億の範囲で値をエンコードできます)。値には常に少なくとも1バイトがあります。

ENUMERATED

この要素の値は、INTEGER要素の値とまったく同じ方法でエンコードされます。

SEQUENCE

この要素の値は、sequenceに含まれるエンコードされたBER要素を単純に連結したものです。たとえば、テキストHelloおよびthereをエンコードする2つのオクテット文字列要素を持つsequenceをエンコードすると、エンコードされたsequence値は04 05 48 65 6C 6C 6F 04 05 74 68 65 72 65です。sequenceに要素がない場合は、sequence値は0バイトになります。

SET

この要素の値は、SEQUENCE要素の値とまったく同じ方法でエンコードされます。

D.2.4.5 BERエンコーディングの例

前述のSEQUENCE値のエンコーディングの例では、2つの完全なBER要素が連結されています。文字列HelloおよびthereのOCTET STRING表現は次のとおりです:

04 05 48 65 6C 6C 6F
04 05 74 68 65 72 65

どちらのケースでも、最初のバイトはタイプ(0x04、ユニバーサル・プリミティブOCTET STRINGタイプ)で、2番目のバイトは長さ(0x05、値が5バイトであることを示す)です。残りの5バイトは文字列Helloおよびthereをエンコードした表現です。

次の例では、ユニバーサルINTEGERタイプのかわりにコンテキスト固有のタイプ値である5を使用して、整数値3をエンコードします:

85 01 03

次の例では、RFC 2251第4.2項(https://tools.ietf.org/html/rfc2251#section-4.2)で定義されるLDAPバインド・リクエスト・プロトコルopをエンコードします。この要素の簡易BNF表現は次のとおりです:

BindRequest ::= [APPLICATION 0] SEQUENCE {
version                    INTEGER (1 .. 127),
name                       OCTET STRING,
authentication             CHOICE {
simple                [0] OCTET STRING,
sasl                  [3] SEQUENCE {
mechanism        OCTET STRING,
credentials      OCTET STRING OPTIONAL } } }

この例では、パスワードpasswordを持つユーザーcn=testに対する簡易認証を使用したバインド・リクエストをエンコードします。このバインド・リクエスト・プロトコルopの完成したエンコーディングは次のとおりです:

60 16 02 01 03 04 07 63 6E 3D 74 65 73 74 80 08 70 61 73 73 77 6F 72 64

分析すると、このバイト文字列には次の情報が含まれています:

- 最初のバイトは0x60で、バインド・リクエスト・プロトコルopのBERタイプです。定義の一部である[APPLICATION 0] SEQUENCEに由来します。アプリケーション固有であることから、クラス・バイトは01、SEQUENCEであることから、コンストラクテッドです。タイプ値0と合せると、バイナリ表現では01100000、16進数では0x60です。

- 2番目のバイトは0x16で、バインド・リクエスト・シーケンスの長さを示しています。16進数0x16は10進数の22で、0x16の後のバイト数は22です。

- 次の3バイトは02 01 03で、3のユニバーサルINTEGER値です。バインド・リクエスト・シーケンスのバージョン・コンポーネントに対応し、LDAPv3バインド・リクエストであることを示しています。

- 次の9バイトは04 07 63 6E 3D 74 65 73 74で、テキストcn=testを含むユニバーサルOCTET STRINGです。バインド・リクエスト・シーケンスの名前コンポーネントに対応しています。

- 最後のコンポーネントは80 08 70 61 73 73 77 6F 72 64で、タイプcontext-specific primitive 0、長さ8バイトの要素です。バインド・リクエスト・プロトコルopの定義の説明に従って、context-specificは簡易認証タイプにマップされ、OCTET STRINGとして取り扱う必要があります。値の8バイトはエンコードされた文字列passwordを表します。

D.2.5 BER

「基本エンコーディング・ルール」を参照してください。

D.2.6 Berkeley DB Java Edition

Berkeley DB Java Edition (Berkeley DB JE、BDBJEまたはJEとも呼ばれる)は、オラクル社が買収したSleepycat Software社により設計されたpure Javaデータベースです。高いスケーラビリティおよびパフォーマンス、完全なACIDセマンティクスをサポートしたトランザクションBツリー・データベースを提供し、ユーザー・データの保管のための主要なデータベースとして使用されます。

ディレクトリ・サーバーは、情報の保管のために、Berkeley DB Java Editionを使用するバックエンドを提供します。このバックエンドはJEバックエンドまたは単にJEBとよく呼ばれます。バックエンドは、複数の個別のデータベースで構成されるBerkeley DB Java Edition環境を使用します。id2entryデータベースは、エントリIDの値をエントリのコンテンツにマッピングするためのメカニズムを提供します。その他のデータベースは、様々なタイプの操作を処理するエントリ・コンテンツを迅速に見つけるために使用できる索引として機能します。

D.2.7 バイナリ・コピー

バイナリ・コピーは、1つのサーバー・インスタンスのディレクトリ・サーバー・バックエンドのバックアップおよびサーバーの別のインスタンスへのバックエンドの復元を実行するプロセスを指します。これにより、迅速な障害時リカバリ・メカニズムを実現し、レプリカ初期化メカニズムとしても使用できます。

すべてのディレクトリ・サーバー・バックエンドがバイナリ・コピーの使用をサポートする必要はなく、状況によってはサポートしない場合もあります。ディレクトリ・サーバーで使用される主要なバックエンドのタイプはBerkeley DB Java Editionの使用に基づいており、Berkeley DB Java Editionは、異なるオペレーティング・システム、CPUアーキテクチャ間で、異なるファイルシステム上の場所を使用する、バイナリ・コピー・メカニズムの使用をサポートします。ただし、どちらのサーバーも同じベース識別名のセットおよび定義された同じ索引のタイプを持つ必要があります。

D.2.8 バインド操作

LDAPバインド操作は、ディレクトリ・サーバーへの認証に使用できます。バインド操作には次の2つの基本的なタイプがあります:

- 簡易バインド操作は、サーバーへの認証にバインドDNおよびパスワードを必要とする簡易認証を使用します。

- SASLバインド操作は、クライアントを認証するSimple Authentication and Security Layerを使用し、選択されたSASLメカニズムに基づく様々なタイプの資格証明を使用できます。

バインド・リクエストのプロトコルopは次のように定義されます:

BindRequest ::= [APPLICATION 0] SEQUENCE {
version                 INTEGER (1 ..  127),
name                    LDAPDN,
authentication          AuthenticationChoice }

AuthenticationChoice ::= CHOICE {
simple                  [0] OCTET STRING,
-- 1 and 2 reserved
sasl                    [3] SaslCredentials,
...  }

SaslCredentials ::= SEQUENCE {
mechanism               LDAPString,
credentials             OCTET STRING OPTIONAL }

リクエストの要素には次のものがあります:

- LDAPプロトコルのバージョン。使用可能な値は2および3です。ただし、LDAPv2は旧式のプロトコルとして分類されており、使用はお薦めしません。

- バインドDN。簡易認証では常に使用され(ただし、匿名の簡易認証では文字列の長さが0の場合もあります)、一般にSASL認証では使用されません。

- 資格証明。提供される資格証明のタイプは、認証のタイプに基づいて変わります。

- 簡易認証では、資格証明はターゲット・バインドDNに対するパスワード、または匿名の簡易認証では空の文字列です。

- SASL認証では、資格証明には使用するSASLメカニズムの名前が含まれ、オプションで、SASLメカニズムに適したエンコード済の資格証明情報が含まれる場合もあります。

LDAPバインド操作に対するレスポンスは、次のように定義されます:

BindResponse ::= [APPLICATION 1] SEQUENCE {
COMPONENTS OF LDAPResult,
serverSaslCreds    [7] OCTET STRING OPTIONAL }

バインド・レスポンスにはLDAP結果オブジェクトの要素が含まれ、認証のタイプが該当すれば、サーバーSASL資格証明のセットも含まれる場合があることを示します。

D.3 C

D.3.1 取消し拡張操作

LDAP取消し拡張操作は、実行中の操作の処理をサーバーが停止するようにリクエストするために使用できるという点で、コアLDAP中止操作に類似した機能を提供する拡張操作です。中止操作より優れた取消し拡張操作の主要な利点は、取消しリクエストおよび取り消される操作の両方に対してレスポンスの取得が保証されることです。しかし、中止リクエストに対するレスポンスはなく、中止される操作に対するレスポンスがない場合があります。

取消し拡張操作はRFC 3909 (http://www.ietf.org/rfc/rfc3909.txt)で定義されています。取消しリクエスト拡張操作の値は次のようにエンコードされます:

cancelRequestValue ::= SEQUENCE {
cancelID        MessageID
-- MessageID is as defined in [RFC2251]
}

D.3.2 CDDL

「Common Development and Distribution License」を参照してください。

D.3.3 証明書

証明書は、非対称暗号化を実行するために使用できる公開鍵暗号の要素です。特に証明書は、1組の鍵(それぞれ公開鍵および秘密鍵と呼ばれる)で構成され、公開鍵で暗号化された任意のデータを秘密鍵で復号化できるように関連付けられています。RSAなど多くの公開鍵アルゴリズムを使用して、秘密鍵で暗号化された任意のデータを公開鍵で復号化できるように、その反対も可能です。

証明書という用語には、使用されるコンテキストに基づいて異なる意味があります。多くの場合、公開鍵のみを指します(特に、サーバーがクライアントに証明書を提示する場合は常に、またはクライアントがサーバーに証明書を提示する場合は、公開鍵のみが含まれます)。ただし、その他のケースでは、秘密鍵を含みます(たとえば、サーバーがクライアントとの保護された通信チャネルを確立するために秘密鍵の使用を要求したり、クライアントがサーバーに対してクライアント自体の証明書を送信するために秘密鍵へのアクセスを必要としたりします)。

ディレクトリ・サーバーでは、証明書には2つの主要な用途があります。1つ目は、通常、Secure Sockets LayerまたはTLS起動拡張操作の使用を介して、保護された通信メカニズムを提供するためです。この場合は、ネゴシエーション・プロセスで、サーバーのみが公開鍵を使用して復号化できるように、サーバーの公開鍵を使用したクライアントの暗号化情報が必要とされ、その情報は通信を確認できる可能性のあるサード・パーティには公開されません。証明書はデータの署名にも使用される場合があり、この場合は、サーバーが秘密鍵を使用して情報を暗号化し、クライアントはサーバーの公開鍵を使用してその情報を復号化できた場合に、サーバーからの正当なデータであることを確認します。

D.3.4 証明書マッパー

証明書マッパーは、指定されたクライアント証明書に対応する、ディレクトリ・サーバーのユーザーを識別するために必要なロジックを提供します。マッピングでは証明書に含まれる情報を使用する可能性があります。ただし、証明書マッパーの多くは、主に証明書のサブジェクト(証明書の名前で、多くの属性値のペアで構成されており、LDAP識別名とよく似ています)に基づいています。

ディレクトリ・サーバーで使用可能な証明書マッパーの詳細は、Certificate Mapper Configuration(http://www.opends.org/promoted-builds/latest/OpenDS/build/docgen/configuration_guide/certificate-mapper.html)を参照してください。

D.3.5 チェーン

チェーンは、ローカル・サーバーの一部のように見えるリモート・ディレクトリ・サーバー・インスタンスでのデータ作成のメカニズムを提供します。つまり、チェーンを使用して、別のサーバーからのデータを使用したディレクトリ情報ツリーの一部を表示します。DITのチェーン部分のデータに対してサーバーが受信するリクエストは、そのリクエストを実際に含むサーバーに透過的に転送されます。

D.3.6 変更ログ

変更ログは特別な種類のデータベースで、ディレクトリ・サーバー・インスタンスで発生する変更の追跡に使用されます。変更ログには、次の2つの異なる種類があります:

- レプリケーション変更ログは、レプリケーションに必要な形式で変更情報を保管します。

- LDAPアクセスの可能な変更ログは、ディレクトリ環境で発生した変更をクライアントが確認できるdraft-good-ldap-changelogで指定される形式でデータを表示します。

D.3.7 cn=Directory Manager

「ディレクトリ・マネージャ」を参照してください。

D.3.8 集合属性

集合属性は特別なタイプの仮想属性で、RFC 3671 (http://www.ietf.org/rfc/rfc3671.txt)で定義されています。集合属性を使用して、サブエントリ内のエントリのメンバーシップに基づく属性に対して、割り当てる値を定義できます。

D.3.9 Common Development and Distribution License

Common Development and Distribution License (CDDL)は、OSI (http://www.opensource.org/)に承認されたオープン・ソース・ライセンスで、Oracle Unified DirectoryのOpenDSプロジェクトで使用されます。

CDDLはファイルベースのライセンスで、プロジェクト内のファイルに対するすべての変更は、CDDLの下でライセンスされている必要があることを意味します。ただし、新規のファイルは、作成者の選択する任意のライセンス(クローズドソース・ライセンスも含む)の下でライセンスされる場合があります。CDDLはMozilla Public License (MPL)に基づき、特許権の対象となる技術がこのコードを使用するその他のプロジェクトに対して許可されるように、特許許可条項を含んでいます。

CDDLライセンスの内容は、http://www.opensource.org/licenses/cddl1.php (http://www.opensource.org/licenses/cddl1.php)を参照してください。

D.3.10 比較操作

LDAP比較操作は、特定のエントリに指定された属性値が含まれるかどうかの判断に使用できます。比較リクエストのプロトコルopは次のように定義されます:

CompareRequest ::= [APPLICATION 14] SEQUENCE {
entry           LDAPDN,
ava             AttributeValueAssertion }

AttributeValueAssertion ::= SEQUENCE {
attributeDesc   AttributeDescription,
assertionValue  AssertionValue }

リクエストの要素には次のものがあります:

- 比較が実行されるエントリのDN。

- 比較が実行される属性の名前。

- 指定された属性で検索するアサーション値。

LDAP比較操作に対するレスポンスは、LDAP結果要素で、次のように定義されます:

CompareResponse ::= [APPLICATION 15] LDAPResult

D.3.11 接続ハンドラ

接続ハンドラはディレクトリ・サーバーのコンポーネントで、クライアントからの接続の許可、クライアントにより実行されたリクエストの読取りと解析、サーバーによる処理の確認およびクライアントに返す対応するレスポンスの送信を実行します。接続ハンドラはクライアントとの通信をすべて管理するため、関連付けられたプロトコルのサポートを実装する必要があります。

ディレクトリ・サーバーが現在提供するのは、Lightweight Directory Access ProtocolおよびJava Management Extensionsを使用する通信が可能な接続ハンドラ、および操作を実行するためのサーバーのコンポーネント(プラグインおよびその他の種類の拡張など)を使用できる、内部使用のための特別な接続ハンドラです。サーバーは、追加のネットワーク・プロトコルのサポートを実装するために使用できる拡張可能な接続ハンドラAPIも提供します。

D.3.12 接続ID

接続IDは、一意の整数の識別子で、ディレクトリ・サーバー内で維持される各接続に割り当てられます。主にロギングの用途に使用して、指定された接続で実行される様々な操作を関連付けることができます。

接続IDカウンタは、サーバーが受信した最初の接続で0から開始され、接続が追加されるごとに1ずつ増分します。カウンタは、サーバーが再起動されるたびにリセットされます。

内部操作の処理で使用される内部接続には、外部クライアントからの接続と区別するために負の値が割り当てられます。

D.3.13 制御

LDAP制御は、メッセージに含めることのできる要素です。リクエスト・メッセージに含まれる場合は、操作の処理方法の追加情報を提供するために使用できます。レスポンス・メッセージに含まれる場合は、操作が処理された方法の追加情報を提供するために使用できます。

LDAP制御の例を次に示します:

- アカウント・ユーザビリティ制御 - アカウントがサーバーに対して認証できるかどうかを示す1組のリクエストとレスポンスの制御です。

- 認可アイデンティティ制御 - バインド操作の一部として、ユーザーに対する認可アイデンティティを判断するための1組のリクエストとレスポンスの制御です。

- エントリ変更通知制御 - エントリが更新された方法を示す永続検索の一部として実行された検索結果エントリ・メッセージに追加される制御です。

- 実効権限取得制御 - 指定されたエントリにアクセスするためにユーザーが保有する権限についての情報の取得に使用できるリクエスト制御です。

- LDAPアサーション制御 - ターゲット・エントリが指定されたアサーション・フィルタと一致した場合にのみ操作が処理されることを保証するために使用できるリクエスト制御です。

- LDAP no-op制御 - サーバー内の情報を実際には変更しない書込み操作が実行された場合は、操作が成功するかどうかの判断を試みることを確認するために使用できるリクエスト制御です。

- LDAP読込み後制御 - 追加、変更またはDN変更操作を実行した直後に発生したエントリを取得するために使用できる、1組のリクエストとレスポンスの制御です。

- LDAP読込み前制御 - 削除、変更またはDN変更操作を実行する直前に発生したエントリを取得するために使用できる、1組のリクエストとレスポンスの制御です。

- ManageDSAIT制御 - サーバーがリフェラルとしてではなく通常のエントリとしてスマート・リフェラルを扱うように要求するために使用できるリクエスト制御です。

- 一致値制御 - 検索操作から返されたエントリに、指定されたフィルタと一致する値のみが含まれるように要求するために使用できるリクエスト制御です。

- 永続検索制御 - サーバー内で、指定された基準のセットに一致するエントリが更新される場合に、通知を受信するために使用できるリクエスト制御です。

- プロキシ認可制御 - 別のユーザーの認可で操作を実行するように要求するために使用できるリクエスト制御です。

- サーバー側ソート制御 - クライアントに結果を返す前に、サーバーで結果をソートするように要求するために使用できるリクエスト制御です。

- 単純なページングの結果制御 - サーバーは結果のサブセットのみを取得し、結果が繰り返し使用される場合に、結果セット全体をクライアントがページングできるように要求するために使用できるリクエスト制御です。

- 仮想一覧表示制御 - サーバーから検索結果の任意のページを取得するために使用できる1組のリクエストとレスポンスの制御です。

LDAP制御は次のように定義されます:

Control ::= SEQUENCE {
controlType             LDAPOID,
.... criticality             BOOLEAN DEFAULT FALSE,
.... controlValue            OCTET STRING OPTIONAL }

制御には次の要素があります:

- 制御のタイプを指定するオブジェクト識別子。

- クリティカル度。制御が操作の重要な部分とみなされるかどうかを示します(つまり、サーバーが制御を処理できない場合は、操作は失敗します)。

- オプション値。制御の処理方法についての追加情報を提供するために使用できます。

D.3.14 CRAM-MD5 SASLメカニズム

CRAM-MD5 Simple Authentication and Security Layerメカニズムは、ユーザー名およびパスワードを使用して、クライアントがディレクトリ・サーバーへの認証を行う方法を提供します。クリアテキスト・パスワードを公開しない方法であるため、クライアントとサーバーの間の接続が保護されていない場合は、簡易認証またはPLAIN SASLメカニズムよりも安全性に優れています。

CRAM-MD5 SASLメカニズムは、draft-ietf-sasl-crammd5-10 (http://tools.ietf.org/html/draft-ietf-sasl-crammd5-10)のInternet Draftで説明されています。このプロセスは、次のとおりです:

1. クライアントは、メカニズム名がCRAM-MD5で資格証明なしの認証タイプSASLを使用して、バインド・リクエスト・プロトコルopタイプを含むメッセージをサーバーへ送信します。

2. サーバーは、結果コード14 (SASLバインドが進行中です)およびランダムに生成されたデータ(challenge)を含むサーバーSASL資格証明要素とともにバインド・レスポンス・メッセージをクライアントに返信します。

3. クライアントは、メカニズム名CRAM-M5を使用して、2番目のSASLバインド・リクエスト・メッセージに応じてサーバーに応答します。今回は、ユーザーを識別するために使用される認証IDを含むSASL資格証明、およびサーバーから送られたchallengeとクリアテキスト・パスワードを組み合せて計算されたMD5ダイジェストを提供します。

4. サーバーは認証IDを使用してユーザーを識別し、そのユーザー用のクリアテキスト・パスワードを取得して(クリアテキスト・パスワードを取得できない場合は、認証は失敗します)、指定されたダイジェストが有効かどうかを判断するために使用します。サーバーは、認証が成功したかどうかを示す適切なレスポンスを(通常successまたはinvalid credentialsの結果とともに)クライアントに送信します。

CRAM-MD5 SASLメカニズムはDIGEST-MD5 SASLメカニズムとよく似ていますが、DIGEST-MD5がクライアントとサーバーの両方からのランダム・データを含めるのに対して、CRAM-MD5はサーバーからのみであるため、多少脆弱です。DIGEST-MD5では、接続の完全性または機密性、あるいはその両方を保証するプロビジョニングも提供されますが、CRAM-MD5では提供されません。

D.3.15 暗号化アルゴリズム

「UNIX暗号化アルゴリズム」を参照してください。

D.4 D

D.4.1 データベース

データベースは、情報の保管に使用されるリポジトリです。ディレクトリ・サーバーでは、データベースはバックエンドでデータを保管するメカニズムとして使用されます。異なる補助記憶装置を使用して他のバックエンドを作成できますが、Berkeley DB Java Editionは、ディレクトリ・サーバーで使用される主要なデータベースです。

D.4.2 データベース・キャッシュ

データベース・キャッシュは、基礎となるデータベースからのコンテンツを保持するために予約されるメモリーの部分です。データベースからの情報の取得を試行する場合は常に、データベースはディスクにアクセスする前に、最初にこのキャッシュをチェックします。データベース・キャッシュは、負荷のかかるディスクI/Oを回避して、パフォーマンスを大幅に改善するために役立ちます。

データベース・キャッシュは、サーバーのエントリ・キャッシュのかわりに、またはこれに加えて使用できます。データベース・キャッシュは、より簡潔なデータ表現を頻繁に作成しますが(つまり、システムの限られたメモリーで、より多くのデータをキャッシュに保持できます)、通常、エントリ・キャッシュは、サーバーでより効率的に使用できる形式でデータを保持します。

D.4.3 デバッグ・ログ

デバッグ・ログは、サーバーで発生する可能性のある問題のデバッグに使用できる、情報を取得するためのメカニズムを提供します。通常、デバッグ情報は問題の発生時にのみ役立つデータで、量が多いため通常の運用では維持できない場合が頻繁に発生します。デバッグ・ログは、次のような情報のレポートに使用できます:

- サーバー内でスローされた例外の詳細情報

- ネットワーク上のクライアントから読み取られたデータまたはクライアントに書き込まれたデータの情報

- データベースから読み取られたデータまたはデータベースに書き込まれたデータの情報

- アクセス制御またはパスワード・ポリシーの処理などの領域で実行された判断についての情報

D.4.4 削除操作

LDAP削除操作は、サーバー(またはサブツリー削除制御とともに使用する場合はサブツリー)からのエントリの削除に使用できます。削除リクエスト・プロトコルopは次のように定義されます:

DelRequest ::= [APPLICATION 10] LDAPDN

リクエストには、削除されるエントリのDNのみが含まれます。

LDAP削除操作に対するレスポンスは、LDAP結果要素で次のように定義されます:

DelResponse ::= [APPLICATION 11] LDAPResult

D.4.5 非推奨パスワード記憶スキーム

非推奨パスワード記憶スキームは、サーバーで使用可能なパスワード記憶スキームですが、主に移行時の使用を意図しています。非推奨の記憶スキームでエンコードされたパスワードを所有している場合は、ユーザーは認証を許可されますが、パスワードはパスワード・ポリシーで定義されるデフォルトの記憶スキームのセットを使用して再エンコードされます。

このメカニズムは、(デフォルトのスキームよりも脆弱であるなどの理由で)使用を継続しないパスワード記憶スキームを使用する別のサーバーから、ディレクトリ・サーバーへデータを移行する場合を主に意図しています。サーバーに対するユーザー認証と同様、パスワードは非推奨のスキームからデフォルトのスキームに移行されます。

D.4.6 間接参照ポリシー

間接参照ポリシーは検索操作の要素で、検索処理の間に検出される場合のある別名エントリのサーバーでの処理方法を指定します。使用可能な別名間接参照ポリシーの値には次のものがあります:

neverDerefAliases

サーバーは、検索処理中に検出する別名の間接参照を試みることはできません。

derefInSearching

サーバーは、エントリが検索基準に一致するかどうかを判断する検索操作の範囲内で、エントリを間接参照します。検索ベースDNとして指定されるエントリは間接参照されません。

derefFindingBaseObj

サーバーは、エントリが別名の場合は、検索ベースDNとして参照されるエントリを間接参照する必要がありますが、検索操作の範囲内にあるその他の別名エントリは間接参照されません。

derefAlways

サーバーは、検索操作の範囲内で別名エントリを間接参照し、ベース・エントリが別名の場合も間接参照します。

D.4.7 DIGEST-MD5 SASLメカニズム

DIGEST-MD5 Simple Authentication and Security Layerメカニズムは、ユーザー名およびパスワードを使用して、クライアントがディレクトリ・サーバーへの認証を行う方法を提供します。クリアテキスト・パスワードを公開しない方法であるため、クライアントとサーバーの間の接続が保護されていない場合は、簡易認証またはPLAIN SASLメカニズムよりも安全性に優れています。

DIGEST-MD5 SASLメカニズムはRFC 2831 (http://www.ietf.org/rfc/rfc2831.txt)で説明されていますが、改訂された仕様がdraft-ietf-sasl-rfc2831bisに記載されています。このプロセスは、次のとおりです:

1. クライアントは、メカニズム名がDIGEST-MD5で資格証明なしの認証タイプSASLを使用して、バインド・リクエスト・プロトコルopタイプを含むメッセージをサーバーへ送信します。

2. サーバーは、結果コード14 (SASLバインドが進行中です)およびランダムに生成されたデータ(nonce)、その他のものを含むサーバーSASL資格証明要素とともにバインド・レスポンス・メッセージをクライアントに返信します。

3. クライアントはサーバーから送信されたnonce、クライアント自体がランダムに生成したデータ(cnonce)、認証ID、オプション認可ID、ユーザーのクリアテキスト・パスワードおよびその他の情報を取得し、それを使用してMD5ダイジェストを作成します。次にクライアントは、そのダイジェストおよびその他のクリアテキスト情報を含む2番目のバインド・リクエスト・メッセージをサーバーに返信します。

4. サーバーは認証IDを使用してユーザーを識別し、そのユーザー用のクリアテキスト・パスワードを取得して(クリアテキスト・パスワードを取得できない場合は、認証は失敗します)、指定されたダイジェストが有効かどうかを判断するために使用します。サーバーは、認証が成功したかどうかを示す適切なレスポンスを(通常successまたはinvalid credentialsの結果とともに)クライアントに送信します。

5. 完全性または機密性、あるいはその両方で接続を保護する必要があることを示す保護品質(QoP)の値をクライアントが要求した場合は、サーバーはクライアントとの必要なネゴシエーションを開始します。現在、ディレクトリ・サーバーでは、完全性または機密性保護を使用するDIGEST-MD5メカニズムの使用をサポートしていないことに注意してください。

DIGEST-MD5 SASLメカニズムはCRAM-MD5 SASLメカニズムとよく似ていますが、CRAM-MD5がサーバーからのランダム・データのみを含めるのに対して、DIGEST-MD5はクライアントとサーバーの両方からであるため、多少厳格です。DIGEST-MD5では、接続の完全性または機密性、あるいはその両方を保証するプロビジョニングも提供されますが、CRAM-MD5では提供されません。

D.4.8 ディレクトリ情報ツリー

ディレクトリ情報ツリーすなわちDITは、ディレクトリ・サーバーのデータの階層構造を指します。DITには、サーバーに対するベース・エントリであるネーミング・コンテキストが1つ以上あり、その他のエントリはすべて、これらのネーミング・コンテキスト・エントリの1つの下位にあります。つまり、ネーミング・コンテキスト・エントリは親エントリを持たないという点で特殊です。

次のシナリオについて考えます。エントリdc=example,dc=comはネーミング・コンテキストで、2つの直属の子を保有し、その子のDNはそれぞれou=People,dc=example,dc=comおよびou=Groups,dc=example,dc=comで、それらの各エントリはそれ自体の下位エントリを保有しています。ディレクトリ・ツリーの最大の深さについて事前に定義された制限はなく、どのエントリも1つ以上の下位エントリを保有する可能性があります。下位エントリを保有しないエントリはリーフ・エントリと呼ばれ、少なくとも1つの下位エントリを保有するエントリはリーフ以外のエントリと呼ばれます。

D.4.9 directory manager

directory managerという用語は、ディレクトリ・サーバーでルートDNユーザーを指すために使用される共通の名前です。通常、デフォルトのルート・ユーザーはcn=Directory Managerのバインド識別名を使用するため、このように名付けられています。多くのディレクトリ・サーバー以外のタイプとは異なり、ディレクトリ・サーバーでは、デフォルトのルートDNはcn=Directory Managerですが、複数のルートDNを定義できます。

D.4.10 ディレクトリ・サーバー

ディレクトリ・サーバーは、外部クライアントがアクセスできる方法でデータを保管するネットワーク・デーモンのタイプです。一部のサーバーでは、DAPまたはNDSなどその他のプロトコルを使用しますが、通常、ディレクトリ・サーバーでは、クライアントとの通信にLightweight Directory Access ProtocolまたはDirectory Services Markup Languageを使用します。

ディレクトリ・サーバーは、(ディレクトリ情報ツリーと呼ばれる)階層形式でデータを保管し、クライアントがその情報と相互に作用するための次のような機能を提供します:

- 検索操作。指定された基準のセットに一致するすべてのエントリの検出を可能にします。

- 追加操作。サーバーへの新規のエントリの追加を可能にします。

- 削除操作。サーバーからのエントリの削除を可能にします。

- 変更操作。サーバー内の既存の情報の更新を可能にします。

- DN変更操作。サーバー内のエントリの名前の変更を可能にします。

- バインド操作。サーバーに対するユーザー認証を可能にします。

- 比較操作。エントリが特定の属性値の組を保有しているかどうかの判断を可能にします。

ディレクトリ・サーバーは、ネットワーク上のクライアントとの通信にLDAPv3を使用し、DSMLリクエストの処理に使用できるDSMLゲートウェイを提供します。

D.4.11 ディレクトリ・サーバー・エージェント

ディレクトリ・サーバー・エージェント(DSA)はディレクトリ・サーバーの単一インスタンスです。

D.4.12 Directory Services Markup Language

Directory Services Markup Language (DSML)は、ディレクトリ・サーバーとの通信に使用できるプロトコルです。DSMLはLightweight Directory Access Protocolに代わるもので、LDAPで使用される基本エンコーディング・ルールによるエンコーディングのかわりにXMLベースの表現のリクエストおよびレスポンスを使用します。

通常、DSMLは、LDAPのかわりとしては比較的脆弱であると考えられています。LDAPで使用されるBERエンコーディングと比較すると、XML表現はより冗長で処理が高価で、利点があまりなく大きなコストが発生するためです。多くの場合、サーバーとの対話にはDSMLのかわりにLDAPの使用をお薦めします。

D.4.13 識別名

識別名(DNと呼ばれることが多い)は、ディレクトリ・サーバー内のエントリを一意に識別する文字列です。ディレクトリ情報ツリー内のエントリの場所を識別する、0個以上の識別名(RDN)コンポーネントから構成されています。エントリの識別名は、名前と階層的な位置の両方を指定するという点で、ファイルシステムの絶対パスに類似のものとして考えられます。

識別名のRDNコンポーネントはカンマで区切られ、右から左に順序付けられます。DNの一番右のコンポーネントはサーバーのネーミング・コンテキストに一番近く、一番左のコンポーネントはリーフ・エントリに一番近いところにあります。つまり、ディレクトリ階層を、最上位にネーミング・コンテキストがあり、枝を下向きに伸ばすピラミッドのようなものとしてとらえると、DNのRDNコンポーネントの順序は一番下から一番上へとリストされています。

DNが一連のRDNコンポーネントで構成されていても、1つのコンポーネントがエントリのRDNを参照していれば、一番左のRDNコンポーネントを参照していることになります。エントリのRDNに含まれる属性は、エントリにも含まれる必要があります。

DITでは、最上位のエントリはネーミング・コンテキストであり、そのDNはdc=example,dc=comです。スペースを節約するために下位エントリのRDNのみが表示されますが、完全なDNはRDNコンポーネントを一番下から一番上まで連結して取得できます。たとえば、一番下の行で一番左のエントリのDNは、uid=ann,ou=People,dc=example,dc=comです。

LDAP識別名およびLDAP識別名を文字列として表示する方法の詳細は、RFC 4514 (http://www.ietf.org/rfc/rfc4514.txt)を参照してください。

D.4.14 分散

分散は、データをパーティションに分割するプロキシ・デプロイメントのタイプです。データの分割は分散アルゴリズムで決定されます。

D.4.15 DIT

「ディレクトリ情報ツリー」を参照してください。

D.4.16 DITコンテンツ・ルール

DITコンテンツ・ルールはスキーマ要素で、構造オブジェクト・クラスに基づき、エントリとともに使用できる補助オブジェクト・クラス、およびエントリとともに使用することを要求、許可および禁止されている属性タイプを指定します。

DITコンテンツ・ルールのコンポーネントの定義は次のとおりです:

- DITコンテンツ・ルールが関連付けられる構造オブジェクト・クラスのオブジェクト識別子を数字で表したもの。

- DITコンテンツ・ルールのオプション・セットの名前。

- 関連付けられた構造クラスを含むエントリとともに使用可能な補助クラスの補助オブジェクト・クラス名またはOIDのオプション・セット。

- 関連付けられた構造クラスとともにエントリ内に存在する必要のある、属性タイプの属性タイプ名またはOIDのオプション・セット。これらの属性は、エントリのオブジェクト・クラスのいずれかにより許可されていない場合でも、必須です。

- 関連付けられた構造クラスを持つエントリ内に、オプションで存在できる属性タイプの属性タイプ名またはOIDのオプション・セット。これらの属性は、エントリのオブジェクト・クラスのいずれかにより許可されていない場合でも、許可されます。

- 関連付けられた構造クラスを持つエントリ内での存在を禁止されている、属性タイプの属性タイプ名またはOIDのオプション・セット。これらの属性は、エントリのオブジェクト・クラスのいずれかにより許可されている場合でも、禁止されます。

サーバーで定義されるDITコンテンツ・ルールのセットは、サブスキーマ・サブエントリのdITContentRules属性を取得して確認できます。DITコンテンツ・ルールの詳細は、「DITコンテンツ・ルールの理解」を参照してください。

D.4.17 DIT構造ルール

DIT構造ルールはスキーマ要素で、エントリ間の階層関係の定義に使用できます。特に、親エントリの種類を(構造オブジェクト・クラスに基づいて)、指定された構造クラスを持つエントリを保有できるものと定義します。

DIT構造ルールのコンポーネントの定義には次のものがあります:

- ルールを一意に識別するために使用される整数のルールID値。

- DIT構造ルールのオプション・セットの名前。

- DIT構造ルールが関連付けられる名前書式の名前またはオブジェクト識別子。名前書式は、DIT構造ルールを構造オブジェクト・クラスに順に関連付けます。

- 上位のルールIDのオプション・セット。上位ルールのセットが定義されている場合は、ルールの名前書式に関連付けられている構造クラスがその下に存在を許可されている構造クラスの定義に使用されます。

サーバーで定義されるDIT構造ルールのセットは、サブスキーマ・サブエントリのdITStructureRules属性を取得して確認できます。DIT構造ルールの詳細は、「DIT構造ルールの理解」を参照してください。

D.4.18 DN

「識別名」を参照してください。

D.4.19 DSA

「ディレクトリ・サーバー・エージェント」を参照してください。

D.4.20 DSA固有のエントリ

DSA固有のエントリ(DSE)は特別なタイプのエントリで、ディレクトリ・サーバーのシノニムであるディレクトリ・サーバー・エージェントの情報を提供します。

Lightweight Directory Access Protocolは、サーバー内にある情報およびサポートされる操作のタイプについての情報を提供するルートDSEと呼ばれる特別なエントリを定義します。

D.4.21 DSE

「DSA固有のエントリ」を参照してください。

D.4.22 DSML

「Directory Services Markup Language」を参照してください。

D.4.23 DSMLゲートウェイ

DSMLゲートウェイ(またはDSML-to-LDAPゲートウェイ)は、特別なタイプのネットワーク・デーモンで、Directory Services Markup LanguageおよびLightweight Directory Access Protocolの間の変換に使用されます。通常、DSMLゲートウェイはクライアントからのDSMLリクエストを許可し、処理のためにディレクトリ・サーバーに転送するLDAPリクエストに変換します。次に、ディレクトリ・サーバーから返信するLDAPレスポンスをDSMLへ変換し、クライアントに返します。

ディレクトリ・サーバーは、アプリケーション・サーバーで実行可能なWebアプリケーションとして実装されるDSMLゲートウェイを介してDSMLをサポートします。

D.4.24 期間

構成プロパティには、許可された値として期間を指定するものがあります。

期間には、整数、および週(w)、日(d)、時(h)、分(m)、秒(s)またはミリ秒(ms)で指定される単位、または複数の指定子の組合せが含まれます。たとえば1週間は、1w、7d、168h、10080mまたは604800sと指定できます。また、10日と半日は1w3d12h0m0sと指定できます。

期間を必要とするすべてのプロパティが、すべての期間の指定子(w、d、h、m、sおよびms)をサポートしているわけではありません。

次のような期間プロパティもあります:

基本単位

期間プロパティの値の指定に使用可能な最小粒度を指定します。たとえば、基本単位が秒の場合は、ミリ秒で表された値は許可されません。

最大単位(オプション)

期間プロパティの値の指定に使用可能な最大期間の単位を指定します。この単位よりも大きい単位で表された値は許可されません。

下限

プロパティにより許可された最小期間を指定します。

上限(オプション)

プロパティにより許可された最大期間を指定します。

無制限の期間

無制限の期間を指定できるプロパティもあります。-1にデコードされた値またはエンコードされた文字列値unlimitedを使用して表されます。

D.4.25 動的グループ

動的グループはディレクトリ・サーバーのグループのタイプで、メンバーの識別名が明示的に指定される静的グループとは対照的に、LDAP URL形式で検索基準のセットを使用するメンバーシップと定義されます。

動的グループは、大量のメンバーを含むグループを管理する効率的な方法です。動的グループは、静的グループよりもスケーラブルで、そのメンバーシップは、エントリ変更の際に、グループ基準に一致するかまたはそうでないかによって自動的に更新されます。

D.5 E

D.5.1 エントリ

エントリは、ディレクトリ・サーバーで情報を保持する構造体です。次のコンポーネントから構成されています:

- サーバーのその他すべてのエントリから、該当のエントリを一意に識別する識別名。

- エントリのコンテンツ制御に使用されるオブジェクト・クラス値の集合。

- エントリの実データを含む属性の集合。

エントリには、エントリのタイプを定義する構造オブジェクト・クラスが常に1つ必要です。エントリのその他の特性を識別するために使用できる補助オブジェクト・クラスを0個以上保有する場合があります。構造クラスと補助クラスがともに、エントリ内に存在する必要のある必須の属性のセット、およびエントリ内に含めることができるが必須ではないオプション属性を定義します。

D.5.2 エントリ・キャッシュ

エントリ・キャッシュはエントリの保持にシステム・メモリーを使用するメカニズムで、エントリを必要とする際は常に、データベースからデコードする必要なく迅速にエントリにアクセスできるようにする方法です。エントリ・キャッシュ・メカニズムは、連続した操作で同じエントリに複数回アクセスするアプリケーションとともに使用すると特に効果的です。たとえば、最初にユーザー・エントリを検出する検索操作、次にそのユーザーがパスワードを検証するためのバインド操作というアプリケーションは、きわめて一般的な使用のパターンです。

エントリ・キャッシュは、サーバーのデータベース・キャッシュのかわりに、またはこれに加えて使用できます。通常、データベース・キャッシュは簡潔なデータ表現を使用しますが、エントリ・キャッシュはサーバーで効率的に使用できる形式でデータを保持します。

基礎となるデータベースにより維持されるデータベース・キャッシュとは異なり、エントリ・キャッシュはディレクトリ・サーバー自体に管理されます。使用可能な様々なエントリ・キャッシュの実装が多数あります。

D.5.3 エントリ変更通知制御

エントリ変更通知制御は、永続検索制御を使用する検索操作に対するレスポンス内で、クライアントに返される検索結果エントリに含まれる制御です。この制御には、実行された変更のタイプ、変更番号(サーバーが変更ログをサポートする場合は、サーバーの変更ログのアイテムに対応)、およびエントリの名前が変更された場合は変更前のエントリのDNなど、エントリに対する変更の追加情報が含まれます。この制御はdraft-ietf-ldapext-psearch-03 (http://tools.ietf.org/html/draft-ietf-ldapext-psearch-03)で説明されており、OIDは2.16.840.1.113730.3.4.7です。

この制御は次のように定義されます:

EntryChangeNotification ::= SEQUENCE {
changeType ENUMERATED {
add             (1),
delete          (2),
modify          (4),
modDN           (8)
},
previousDN   LDAPDN OPTIONAL,     -- modifyDN ops. only
changeNumber INTEGER OPTIONAL     -- if supported
}

D.5.4 エントリDN

エントリDNは、エントリの現在の識別名のコピーを提供する操作属性です。DNはエントリの属性ではないため、属性値アサーションの実行には使用できません。エントリDNはエントリのDNにアクセスするメカニズムを提供し、RFC 5020で説明されています。

D.5.5 エントリID

エントリIDは、ディレクトリ・サーバー・バックエンド内のエントリを一意に識別するために使用される整数値です。エントリの識別名はこの用途に使用できますが、数値のエントリIDはより簡潔で効率的なデコードが可能なため、幅広い用途により適しています。

エントリIDは、id2entryデータベースの実際のエントリ・データに対するキーとして使用され、関連付けられた索引キーと一致するエントリを識別するIDリストで使用されます。

D.5.6 エントリUUID

エントリUUIDは、entryUUID操作属性に含まれる全体で一意となる識別子で、ディレクトリ・サーバーの各エントリに割り当てられます。RFC 4530 (http://www.ietf.org/rfc/rfc4530.txt)で説明されており、エントリが存続する間は変更されない一意の識別子を意図しています(DN変更操作の結果として変更可能な識別名とは対照的です)。エントリUUIDは十分に安定しているため、DNが変更された場合でも、エントリを追跡するレプリケーション・サブシステムで使用されます。

D.5.7 等価索引

等価索引は、指定されたアサーション値に等しいエントリを効率的に識別するために使用される索引のタイプです。等価索引は、対応する等価一致ルールを保有する属性用にのみ保持できます。この一致ルールは索引キーとして使用する正規化された値に対して使用され、そのキーの値は、正規化された値に等しい値を持つエントリのエントリIDを含むIDリストです。

D.5.8 等価検索フィルタ

等価検索フィルタはLDAP検索フィルタのタイプで、指定された属性の固有の値を含むエントリの識別に使用できます。サーバーは、等価一致ルールを使用して判断します。

LDAP等価フィルタの文字列表現は、左カッコに続く属性名、等号、属性値および右カッコで構成されます。たとえば、等価フィルタの(uid=john.doe)は、john.doeの値を含むuid属性のエントリと一致します。

D.5.9 エラー・ログ

エラー・ログは、エラー、警告およびその他サーバーの使用期間に発生する重大なイベントをレポートするメカニズムを提供します。エラー・ログに書き込まれる各メッセージには、(メッセージが生成されたサーバーの領域を示す)カテゴリ、(メッセージの相対的な重要性を示す)重大度および関連付けられるメッセージ文字列を一意に識別する整数値が含まれます。

D.5.10 エクスポート

「LDIFエクスポート」を参照してください。

D.5.11 拡張操作

LDAP拡張操作は、コア・プロトコル仕様で定義されていないリクエスト操作をクライアントに許可することにより、LDAPプロトコルに対する拡張度を提供します。LDAP拡張操作の例を次に示します:

取消し拡張操作

この操作は、以前にリクエストされた操作の取消しに使用できます。

パスワード変更拡張操作

この操作は、ユーザー・パスワードの変更に使用できます。

TLS起動拡張操作

この操作は、既存の接続上での保護された通信チャネルの開始に使用できます。

Who Am I拡張操作

この操作は、クライアント接続に関連付けられる認可アイデンティティの判断に使用できます。

拡張リクエストのプロトコルopは次のように定義されます:

ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
requestName      [0] LDAPOID,
requestValue     [1] OCTET STRING OPTIONAL }

拡張リクエストの要素には次のものがあります:

- 実行する操作のタイプを示すために使用されるオブジェクト識別子。

- リクエスト処理が進行する間に使用する、追加情報を含むオプション値。

LDAP拡張操作に対するレスポンスは次のように定義されます:

ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
COMPONENTS OF LDAPResult,
responseName     [10] LDAPOID OPTIONAL,
responseValue    [11] OCTET STRING OPTIONAL }

拡張レスポンスには次の要素があります:

- 結果オブジェクトの要素。

- レスポンスのタイプを示すために使用されるオプションOID。

- レスポンスに含まれる追加情報を含むオプションのエンコードされた値。

D.5.12 拡張可能な一致索引

拡張可能な一致索引は、拡張可能な一致検索フィルタを使用する検索操作の処理速度を上げるために使用される索引のタイプです。索引キーは、指定された一致規則を使用する正規化された値で、対応するIDリストには、一致ルールに従って値が一致するすべてのエントリのエントリIDが含まれます。

D.5.13 拡張可能な一致検索フィルタ

拡張可能な一致検索フィルタはLDAP検索フィルタのタイプで、指定された一致ルールを使用して一致したエントリの識別に使用できます。

拡張可能な一致フィルタには次のコンポーネントがあります:

- 判断に使用する一致ルールのOID。これはオプション要素で、指定されない場合は属性タイプの指定が必要となり、属性タイプのデフォルトの等価一致ルールが使用されます。

- ターゲット設定される属性タイプの名前。指定されない場合は、エントリに含まれるすべての属性が調べられます。

- エントリの識別名の属性およびエントリに含まれる属性に対して一致が実行されるかどうかを示すフラグ。

- 一致ルール用のターゲットとして使用されるアサーション値。

LDAP拡張可能な一致フィルタの文字列表現は、次のコンポーネントで順に構成されています:

- 左カッコ

- 属性タイプの名前または指定されなかった場合は空の文字列

- dnAttributesフラグが設定されている場合は文字列:dn、または設定がない場合は空の文字列

- 一致ルールIDが使用可能な場合はコロンとそれに続くOIDで構成される文字列、または一致ルールIDがない場合は空の文字列

- 文字列:=

- アサーション値の文字列表現

- 右カッコ

D.5.14 EXTERNAL SASLメカニズム

EXTERNAL Simple Authentication and Security Layerメカニズムは、LDAPプロトコル・レベルで実行される通信の外部で使用可能な情報を使用して、クライアントがディレクトリ・サーバーへの認証を行う方法を提供します。EXTERNAL認証(現在、ディレクトリ・サーバーがサポートする唯一の形式)の最も一般的な使用方法は、Secure Sockets LayerまたはTLS起動拡張操作のネゴシエーションの間にクライアントが提示した証明書に基づく、サーバーでのクライアントの識別です。ディレクトリ・サーバーは、証明書マッパーを使用してクライアントの証明書をディレクトリのユーザーにマッピングし、オプションで追加検証を実行する場合があります(たとえば、提示された証明書がユーザーのエントリに実際に存在していることを確認します)。

D.6 F

D.6.1 フェイルオーバー・アルゴリズム

すべてのクライアントのリクエストをメイン・リモートLDAPデータ・ソースに送信するロード・バランシング・アルゴリズム。メイン・リモートLDAPが停止する場合は、リクエストはセカンダリ・リモートLDAPサーバーなどに転送されます。このように、1つ以上のリモートLDAPサーバーの障害後、サービスの継続を保証します。

D.6.2 falseフィルタ

「LDAP falseフィルタ」を参照してください。

D.7 G

D.7.1 一般的な時刻

一般的な時刻は、タイムスタンプおよびタイムゾーン情報の表現に使用できる形式です。一般的な時刻の値には、次のコンポーネントがあります:

- 年を表す4桁の数。

- 月を表す2桁の数(01は1月、02は2月、...、12は12月)。

- 該当月の日を表す2桁の数(月およびうるう年かどうかによって01から28、29、30または31まで)。

- 該当日の時を表す2桁の数(午前0時の00から午後11時の23まで)。

- オプションで、時間の分を指定する2桁の数(00から59まで)。

- オプションで、分の秒を指定する2桁の数(00から59まで、またはうるう秒の場合は60まで)。これは、タイムスタンプ値にも時間の分が含まれる場合にのみ追加できます。

- オプションで、秒の小数部を指定する1桁以上の数を続けて表す期間。これは、タイムスタンプ値に分および秒の情報が含まれる場合にのみ追加できます。

- タイムゾーン・インジケータ。UTCタイムゾーンの値を示す大文字のZ、またはプラス記号かマイナス記号とそれに続く2桁または4桁の数で、この数はUTCタイムゾーンからの時差を指定します。

一般化された時刻形式のタイムスタンプの例として、20070508200557Zは、(UTCタイムゾーンで)2007年5月28日午後8時5分57秒の時刻を指定します。米国中部時間サマータイムで等しい値(UTCから5時間の時差)は、20070508150557-0500です。

D.7.2 実効権限取得制御

実効権限取得制御は、指定されたエントリと相互に作用する際に、指定されたユーザーが保有する権限を判断するために使用できる制御のタイプです。この制御のオブジェクト識別子は1.3.6.1.4.1.42.2.27.9.5.2で、次の定義を使用します:

GetRightsControl ::= SEQUENCE {
authzId    authzId
attributes  SEQUENCE OF AttributeType
}

-- Only the "dn:DN form is supported.

検索リクエストでこの制御を使用する例は、「実効権限取得制御を使用した検索」を参照してください。

D.7.3 グローバル索引

プロキシ・デプロイメントで、グローバル索引はデータ・エントリをデータが保管されている分散パーティションにマッピングします。グローバル索引は特定の属性(telephonenumberなど)をマッピングします。たとえば、グローバル索引はtelephonenumber=5551212を分散パーティション1に、telephonenumber=4441212をパーティション2にマッピングできます。

D.7.4 グローバル索引カタログ

グローバル索引カタログには、1つ以上のグローバル索引が含まれます。グローバル索引カタログは、属性の値でエントリが保持するパーティションにマッピングされるものもあるため、ブロードキャストの必要性を減らすために分散デプロイメントとともに使用できます。

D.7.5 大きいか等しい検索フィルタ

大きいか等しい検索フィルタは、指定されたアサーション値以上の、指定された属性の特定の値を含むエントリの識別に使用できるLDAP検索フィルタのタイプです。サーバーでは、順序付け一致ルールを判断に使用します。

LDAP大きいか等しい検索フィルタの文字列表現は、左カッコに続く属性名、大なり記号、等号、アサーション値および右カッコで構成されます。たとえば、大きいか等しいフィルタの(createTimestamp>=20070101000000Z)は、20070101000000Z以上のcreateTimestamp値を保有するエントリと一致します。

D.7.6 グループ

グループは特別なタイプのディレクトリ・サーバーのエントリで、サーバーのユーザーのセットの表示に使用されます。グループは、アクセス制御l、仮想属性など、サーバー内でいくつかの異なる方法で使用可能で、クライアントによる様々な用途にも使用できます。

サーバーで定義されるグループには、次のようないくつかの異なるタイプがあります:

- 静的グループは、メンバーの明示的なリストを提供します。

- 動的グループは、メンバーシップの情報を検索基準のセットから取得します。

- 仮想静的グループは、静的グループのように見えますが、メンバーシップ情報を動的グループのように別のタイプのグループから取得します。

D.7.7 GSSAPI SASLメカニズム

GSSAPI Simple Authentication and Security Layerメカニズムは、Kerberos V5セッションを使用して、クライアントがディレクトリ・サーバーへの認証を行う方法を提供します。Kerberosは通常シングル・サインオン用途に使用されるプロトコルで、クライアントとサーバーの間の通信を保護するための完全性または機密性、あるいはその両方を使用するオプションを提供します(現在、ディレクトリ・サーバーではネットワーク・コンテンツ保護用のGSSAPIをサポートしていませんが、クライアントの認証の場合のみサポートします)。

GSSAPI SASLメカニズムは、RFC 4752 (http://www.ietf.org/rfc/rfc4752.txt)で説明されています。

D.8 I

D.8.1 IDリスト

IDリストは、ディレクトリ・サーバー索引の値として使用されます。関連付けられた索引キーと一致するすべてのエントリのエントリIDのセットが含まれます。

IDリストは、索引エントリ制限により許可されている数よりも多くの索引キーと一致するエントリが存在することを示す、特別な値を保有できる場合があります。その場合は、それ以降索引キーは維持されません。

D.8.2 id2entryデータベース

id2entryデータベースは、エントリIDを対応するエントリのコンテンツにマッピングするデータベースのタイプです。エントリIDは、索引内のIDリストで使用されます。

D.8.3 アイデンティティ・マッパー

アイデンティティ・マッパーは、認証IDまたは認可IDの値を対応するユーザー・エントリにマッピングするために使用できるロジックを提供します。アイデンティティ・マッパーは、多くのSimple Authentication and Security Layerメカニズム、プロキシ認可制御およびパスワード変更拡張操作とともに使用されます。

D.8.4 アイドル・アカウント・ロックアウト

アイドル・アカウント・ロックアウトは、ディレクトリ・サーバー・パスワード・ポリシーの一部で、長期間使用されないままになっているユーザー・アカウントのロックに使用できます。ユーザー認証時刻が記録されるように最終ログイン時刻機能の有効化が必要で、指定された期間内に認証されなかったユーザーによるいずれのバインド操作も拒否します。

長期間アイドルのままであったためにユーザーのアカウントがロックされた場合は、管理者のパスワードのリセットによりロック解除できます。

D.8.5 インコア再起動

インコア再起動は、サーバーの実行に使用されるJVMが実在しない状態でサーバーの再起動を可能にするプロセスです。JVM引数の変更を必要としない、サーバー再起動の必要な変更を適用するために使用できます。インコア再起動は、サーバー・プロセスを停止して再起動するよりも迅速で、JVM内で実行される処理の確認を蓄積したJITキャッシュを維持するという別の利点もあります。

D.8.6 索引

索引はディレクトリ・サーバー・データベースで使用されるメカニズムで、検索基準に一致するエントリの効率的な検出に使用できます。索引は、索引キーと一致するエントリのエントリIDのセットであるIDリストにキーをマッピングします。

ディレクトリ・サーバーは、次の6つの主要な索引のタイプを使用します:

- 近似索引は、指定されたアサーション値におおよそ等しい属性値を含むエントリの識別に使用されます。

- 等価索引は、指定されたアサーション値と一致する属性値を含むエントリの識別に使用されます。

- 拡張可能な一致索引は、指定された拡張可能な一致フィルタと一致するエントリの識別に使用されます。この索引は現在サポートされていません。

- 順序付け索引は、指定されたアサーション値以上または以下の値を保有するエントリの識別に使用されます。

- プレゼンス索引は、指定された属性に少なくとも1つの値を含むエントリの識別に使用されます。

- 部分文字列索引は、指定された部分文字列アサーションと一致する属性値を含むエントリの識別に使用されます。

D.8.7 索引エントリ制限

索引エントリ制限は、指定された索引キーと一致可能なエントリの最大数(つまり、IDリストの最大サイズ)の制御に使用できる構成制限です。サーバー内のエントリと高い割合で一致する索引キーを維持するために、パフォーマンスの影響を制限するメカニズムを提供します。大きなIDリストを必要とする可能性がある場合は、索引なし検索を実行すると、索引を使用するよりも速度を向上できる場合がよくあります。

ディレクトリ・サーバーの索引エントリ制限は、Oracle Directory Server Enterprise EditionのALL IDしきい値に類似のものです。

D.8.8 中間レスポンス

「LDAP中間レスポンス」を参照してください。

D.8.9 Internet Draft

Internet Draftは、IETF (http://www.ietf.org/)を介して定義される仕様の形式です。Internet draftは、通常複数の改訂を経る一時的な仕様で、改訂の間に大幅に変更される場合があります。Internet Draftが安定するとrequest for commentsに昇格します。それ以外のdraftは、サーバーで実装する価値のある、存続可能な機能が記述されている場合もありますが、進展はなく、その後維持されなくなります。

D.9 J

D.9.1 Java Management Extension

Java Management Extensions (JMX)は、監査情報および構成情報へのアクセスに使用できるJavaテクノロジのフレームワークです。

Oracle Unified Directoryでは、監視エントリからの情報を公開するためにJMXを使用します。重大な問題のイベントまたはサーバーでのイベントの際の管理アラートのため、JMX通知メカニズムも使用します。

D.9.2 JMX

「Java Management Extension」を参照してください。

D.10 K

D.10.1 キー・マネージャ・プロバイダ

キー・マネージャ・プロバイダは、サーバー証明書の秘密鍵情報へのアクセスを提供できるサーバーのコンポーネントです。

サーバーで使用可能なキー・マネージャ・プロバイダには次のものがあります:

- JKSキーストアでキー情報にアクセスするためのメカニズム

- PKCS#12ファイルでキー情報にアクセスするためのメカニズム

- PKCS#11トークンでキー情報にアクセスするためのメカニズム

D.11 L

D.11.1 最終ログイン時刻

ディレクトリ・サーバーの最終ログイン時刻機能は、バインド操作を使用してサーバーへの認証をユーザーが最後に実行した時刻を記録するために使用できるメカニズムです。最終ログイン時刻は、ユーザー定義のフォーマットにより、指定された属性に書き込むことができます。

多くのサーバーで、お薦めする最終ログイン時刻フォーマットの定義では、日付のみで時刻は含めないことに注意してください。このフォーマットを使用すると値の更新が1日に一度となり、1日に何度も認証するユーザーは、パフォーマンスへの影響の可能性を削減できます。

最終ログイン時刻は情報提供を目的に維持できますが、アイドル・アカウント・ロックアウト機能の有効化にも使用できます。

D.11.2 最終変更プラグイン

最終変更プラグインは、追加操作の一部としてエントリにcreatorsName属性およびcreateTimestamp属性を追加するため、あるいは変更操作またはDN変更操作の一部としてエントリのmodifiersName属性およびmodifyTimestamp属性を更新するために使用できる操作前アイドル・アカウント・ロックアウトです。

D.11.3 LDAPアサーション制御

LDAPアサーション制御は、ターゲット・エントリが指定されたアサーション・フィルタと一致する場合にのみ操作を実行するために使用できる制御のタイプです。比較操作、削除操作、変更操作、DN変更操作および検索操作とともに使用できます。

LDAPアサーション制御は、RFC 4528 (http://www.ietf.org/rfc/rfc4528.txt)で説明されており、OIDは1.3.6.1.1.12です。制御の値は、LDAPのLDAP検索フィルタとしてエンコードされます。

検索リクエストでこの制御を使用する例は、「LDAPアサーション制御を使用した検索」を参照してください。

D.11.4 ldapcompareコマンド

ldapcompareコマンドは、LDAP比較操作のリクエストに使用できます。

このコマンドの使用方法の詳細は、「ldapcompare」を参照してください。

D.11.5 LDAPデータ変換形式

LDAPデータ変換形式(LDIF)は、テキスト形式でディレクトリ・データを表すメカニズム形式です。LDIFの仕様はRFC 2849 (http://www.ietf.org/rfc/rfc2849.txt)に記載されており、ディレクトリ・データの表現形式のみならず、そのデータを変更するメカニズムについても説明されています。

通常、LDIFレコードは一連の名前/値ペアで構成されています。名前の後に1つのコロン、0個以上の空白および関連付けられた値を続けます。または、2つのコロン、0個以上の空白および値のbase64エンコーディング表現を続けることもできます。各名前/値ペアは、個別の行に指定され、長い行の場合は、行端文字と次の行の先頭に続く1つの空白を使用して2行以上に行送りされます。複数のLDIFレコードは、互いに少なくとも1行の空白行で区切られます。ナンバー(#)記号で開始される行はコメントとして取り扱われ、無視されます。

エントリのLDIF表現の場合は、1行目にエントリの識別名を含む必要があります。LDIFレコードの残りの行は、名前として使用される属性説明とともに、エントリの属性を表します。複数値属性は値ごとに個別の行で表されます。

LDAPデータ変換形式で表されるユーザー・エントリの例を次に示します:

dn: uid=john.doe,ou=People,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: john.doe
givenName: John
sn: Doe
cn: John Doe
mail: john.doe@example.com
userCertificate;binary:: MIIB5TCCAU6gAwIBAgIERloIajANBgkqhkiG9w0BAQUFADA3M
QswCQYDVQQGEwJVUzEVMBMGA1UEChMMRXhhbXBsZSBDb3JwMREwDwYDVQQDEwhKb2huIERvZT
AeFw0wNzA1MjcyMjM4MzRaFw0wNzA4MjUyMjM4MzRaMDcxCzAJBgNVBAYTAlVTMRUwEwYDVQQ
KEwxFeGFtcGxlIENvcnAxETAPBgNVBAMTCEpvaG4gRG9lMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCWNZB4qs1UvjYgvGvB9udmiUi4X4DeaSm3o0p8PSwpOFxSqgWdSwKgUugZ1EJVy
YoakljDFsJ0GVown+dIB24V4ozNs6wa0YotIKTV2AcySQkmzzP3e+OnE9Aa1wlB/PVnh1CFLg
k1UOoruLE10bac5HA8QiAmfNMorU26AwFTcwIDAQABMA0GCSqGSIb3DQEBBQUAA4GBAGrzMKN
bBRWn+LIfYTfqKYUc258XVbhFri1OV0oF82vyvciYWZzyxLc52EPDsymLmcDh+CdWxy3bVkjd
Mg1WEtMGr1GsxOVi/vWe+kT4tPhinnB4Fowf8zgqiUKo9/FJN26y7Fpvy1IODiBInDrKZRvNf
qemCf7o3+Cp00OmF5ey
userPassword: {SSHA}s4Bd9M0tCpRDr8/U+IXetRcAbd8bJY3AFKsn+A==

LDIFでLDAP追加操作を表すには、次の例で示すように、DN直後の行でaddのchangetypeを示すこと以外は、エントリの表現とまったく同じフォーマットです:

dn: uid=john.doe,ou=People,dc=example,dc=com
changetype: add
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: john.doe
givenName: John
sn: Doe
cn: John Doe
mail: john.doe@example.com
userCertificate;binary:: MIIB5TCCAU6gAwIBAgIERloIajANBgkqhkiG9w0BAQUFADA3M
QswCQYDVQQGEwJVUzEVMBMGA1UEChMMRXhhbXBsZSBDb3JwMREwDwYDVQQDEwhKb2huIERvZT
AeFw0wNzA1MjcyMjM4MzRaFw0wNzA4MjUyMjM4MzRaMDcxCzAJBgNVBAYTAlVTMRUwEwYDVQQ
KEwxFeGFtcGxlIENvcnAxETAPBgNVBAMTCEpvaG4gRG9lMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCWNZB4qs1UvjYgvGvB9udmiUi4X4DeaSm3o0p8PSwpOFxSqgWdSwKgUugZ1EJVy
YoakljDFsJ0GVown+dIB24V4ozNs6wa0YotIKTV2AcySQkmzzP3e+OnE9Aa1wlB/PVnh1CFLg
k1UOoruLE10bac5HA8QiAmfNMorU26AwFTcwIDAQABMA0GCSqGSIb3DQEBBQUAA4GBAGrzMKN
bBRWn+LIfYTfqKYUc258XVbhFri1OV0oF82vyvciYWZzyxLc52EPDsymLmcDh+CdWxy3bVkjd
Mg1WEtMGr1GsxOVi/vWe+kT4tPhinnB4Fowf8zgqiUKo9/FJN26y7Fpvy1IODiBInDrKZRvNf
qemCf7o3+Cp00OmF5ey
userPassword: password

LDIFでLDAP削除操作を表すには、フォーマットは次のように、エントリのDNを含む行とそれに続くdeleteのchangetypeを示す行のみです:

dn: uid=john.doe,ou=People,dc=example,dc=com
changetype: delete

LDIFでLDAP変更操作を表すには、もう少し複雑なフォーマットになります。1行目にはエントリのDNを含み、2行目にはmodifyのchangetypeを含みます。3行目で属性変更タイプ(変更、削除、置換または増分)を指定し、これに属性説明が続き、属性説明の名前部分および対応する属性値の値を含む、変更のための指定値を指定する行が追加される場合があります。単一の変更レコードで説明される複数の属性変更では、次の例で示すようにダッシュのみの行で各変更内容を区切ります:

dn: uid=john.doe,ou=People,dc=example,dc=com
changetype: modify
replace: userPassword
userPassword: newpassword
-
replace: description
description: This is the first description value
description: This is the second description value

LDIFでLDAP DN変更操作を表すには、1行目にはエントリのDNを含み、2行目にはmoddnのchangetypeを含みます。3行目には、エントリに割り当てる新規RDNに等しい値を含むnewrdnの名前が含まれ、4行目にはdeleteoldrdnの名前に値1 (deleteOldRDNフラグがtrueの場合)または0 (falseの場合)が続きます。オプションで5行目にnewsuperiorの名前およびリクエストに含まれている場合は新規上位DNの値を含めることができます。例:

dn: uid=john.doe,ou=People,dc=example,dc=com
changetype: moddn
newrdn: uid=johnathan.doe
deleteoldrdn: 1

D.11.6 ldapdeleteコマンド

ldapdeleteコマンドは、LDAP削除操作のリクエストに使用できます。

このコマンドの使用方法の詳細は、「ldapdelete」を参照してください。

D.11.7 LDAP falseフィルタ

LDAP falseフィルタは特別なタイプのOR検索フィルタで、埋込みフィルタ・コンポーネントを含みません。LDAP falseフィルタと呼ばれるのは、常にfalseと評価され、いずれのエントリとも一致しないためです。

LDAP trueフィルタの文字列表現は、(|)です。LDAP falseフィルタは、RFC 4526 (http://www.ietf.org/rfc/rfc4526.txt)で説明されています。

D.11.8 LDAP中間レスポンス

LDAP中間レスポンス・メッセージは、特別なタイプのプロトコルopで、処理の完了前および最終のレスポンス・メッセージが送信される前に、操作の状態の情報を提供する追加メッセージをサーバーが送信できるようにします。RFC 3771 (http://www.ietf.org/rfc/rfc3771.txt)の中間レスポンスの導入前は、検索操作のみが複数レスポンスを送信できました。

中間レスポンス・プロトコルopは次のように定義されます:

IntermediateResponse ::= [APPLICATION 25] SEQUENCE {
responseName     [0] LDAPOID OPTIONAL,
responseValue    [1] OCTET STRING OPTIONAL }

現在ディレクトリ・サーバーでは、中間レスポンス・メッセージを使用する操作をサポートしていません。

D.11.9 LDAPメッセージ

LDAPメッセージは、LDAP通信用の基本的なプロトコル・データ・ユニットです。すべてのリクエストとレスポンスの要素の保持に使用されるコンテナです。

LDAPメッセージは、次の例で示すように定義されます:

LDAPMessage ::= SEQUENCE {
messageID       MessageID,
protocolOp      CHOICE {
bindRequest           BindRequest,
bindResponse          BindResponse,
unbindRequest         UnbindRequest,
searchRequest         SearchRequest,
searchResEntry        SearchResultEntry,
searchResDone         SearchResultDone,
searchResRef          SearchResultReference,
modifyRequest         ModifyRequest,
modifyResponse        ModifyResponse,
addRequest            AddRequest,
addResponse           AddResponse,
delRequest            DelRequest,
delResponse           DelResponse,
modDNRequest          ModifyDNRequest,
modDNResponse         ModifyDNResponse,
compareRequest        CompareRequest,
compareResponse       CompareResponse,
abandonRequest        AbandonRequest,
extendedReq           ExtendedRequest,
extendedResp          ExtendedResponse,
...,
intermediateResponse  IntermediateResponse },
controls       [0] Controls OPTIONAL }

LDAPメッセージには次の要素があります:

- メッセージID。リクエストとレスポンスの関連付けに使用される一意の識別子。クライアントはリクエストにメッセージIDを含ませ、そのリクエストに対するすべてのレスポンス・メッセージは同じメッセージIDを保有します。

- プロトコルop。実際のリクエストまたはレスポンスのコンテナ。

- リクエストの処理方法またはサーバーからのレスポンスに関する追加情報を提供するために使用できる制御のオプション・セット。

D.11.10 LDAP DN変更操作

LDAP DN変更操作は、ディレクトリ・サーバーでのエントリの識別名を変更するために使用できます。エントリの相対識別名の変更、またはそのエントリの新しい親の下への移動、あるいはその両方ができます。ターゲット・エントリが下位エントリを保有する場合は、サブツリーの移動または名前の変更に使用する場合があります。

DN変更リクエストのプロトコルopは次のように定義されます:

ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
entry           LDAPDN,
newrdn          RelativeLDAPDN,
deleteoldrdn    BOOLEAN,
newSuperior     [0] LDAPDN OPTIONAL }

変更DNリクエストには次の要素があります:

- 名前の変更または移動、あるいはその両方を行うエントリのDN。

- エントリで使用する新規RDN。エントリが新しい親の下に移動するのみであれば、現在のRDNと同じ場合があります。

- 現在のRDN属性値をエントリから削除するかどうかを示すフラグ。

- エントリの新しい親を指定する、オプションのDN。

LDAP DN変更操作に対するレスポンスは、LDAP結果で次のように定義されます:

ModifyDNResponse ::= [APPLICATION 13] LDAPResult}

D.11.11 LDAP変更操作

LDAP変更操作は、ディレクトリ・サーバーの既存のエントリの変更に使用できます。変更リクエストのプロトコルopは次のように定義されます:

ModifyRequest ::= [APPLICATION 6] SEQUENCE {
object          LDAPDN,
changes         SEQUENCE OF change SEQUENCE {
operation       ENUMERATED {
add     (0),
delete  (1),
replace (2),
...  },
modification    PartialAttribute } }

変更リクエストには次の要素があります:

- 変更するエントリのDN

- エントリで実行される変更を示す1つ以上の変更要素

LDAP変更操作に対するレスポンスは、LDAP結果で次のように定義されます:

ModifyResponse ::= [APPLICATION 7] LDAPResult

D.11.12 ldapmodifyコマンド

ldapmodifyコマンドは、LDAPの追加操作、削除操作、変更操作およびDN変更操作のリクエストに使用できます。

このコマンドの使用方法の詳細は、「ldapmodify」を参照してください。

D.11.13 LDAP no-op制御

LDAP no-op制御は、LDAPの追加操作、削除操作、変更操作またはDN変更操作に追加して、サーバーのコンテンツに対する変更が実際には実行されないことを示す制御のタイプです。

LDAP no-op制御はdraft-zeilenga-ldap-noopで定義されています。これはまだ作成中の仕様ですが、ディレクトリ・サーバーはオブジェクト識別子に1.3.6.1.4.1.4203.1.10.2を使用してこの制御の基本的なサポートをしています。この制御には値がありません。

ldapmodify操作でのno-op制御の使用例を次に示します。

ldapmodify -h localhost -p 1389 -D "cn=directory manager" -j pwd-file \
-J 1.3.6.1.4.1.4203.1.10.2
dn: uid=aaltay,ou=People,dc=example,dc=com
changetype: modify
replace: telephoneNumber
telephoneNumber: +1 995 589 3333

Processing MODIFY request for uid=aaltay,ou=People,dc=example,dc=com
MODIFY operation failed
Result Code:  16654 (No Operation)
Additional Information:  The modify operation was not actually performed in the
Directory Server back end because the LDAP no-op control was present in the request

D.11.14 LDAP読込み後制御

LDAP読込み後制御は、LDAPの追加操作、変更操作またはDN変更操作に追加して、その操作に対する処理の終了時点とまったく同じターゲット・エントリのコピーを、サーバーが返すようにリクエストする制御のタイプです。RFC 4527 (http://www.ietf.org/rfc/rfc4527.txt)で定義されるLDAP読込みエントリ制御の1つです。

読込み後リクエスト制御のOIDは1.3.6.1.1.13.2で、その値は検索操作の検索属性と同じ方法でエンコードされます。そのレスポンス制御のOIDは1.3.6.1.1.13.2(リクエスト制御のOIDと同じ)で、その値は検索結果エントリと同じ方法でエンコードされます。

ldapmodifyリクエストでの読込み後制御の使用例を次に示します:

$ ldapmodify -h localhost -p 1389 -D "cn=directory manager" -j pwd-file \
--postReadAttributes=telephoneNumber
dn: uid=aaltay,ou=People,dc=example,dc=com
changetype: modify
replace: telephoneNumber
telephoneNumber: +1 995 589 3333

Processing MODIFY request for uid=aaltay,ou=People,dc=example,dc=com
MODIFY operation successful for DN uid=aaltay,ou=People,dc=example,dc=com
Target entry after the operation:
dn: uid=aaltay,ou=People,dc=example,dc=com
telephoneNumber: +1 995 589 3333

D.11.15 LDAP読込み前制御

LDAP読込み前制御は、LDAPの削除操作、変更操作またはDN変更操作に追加して、その操作に対する処理直前とまったく同じターゲット・エントリのコピーを、サーバーが返すようにリクエストする制御のタイプです。RFC 4527 (http://www.ietf.org/rfc/rfc4527.txt)で定義されるLDAP読込みエントリ制御の1つです。

読込み前リクエスト制御のOIDは1.3.6.1.1.13.1で、その値は検索操作の検索属性と同じ方法でエンコードされます。そのレスポンス制御のOIDは1.3.6.1.1.13.1(リクエスト制御のOIDと同じ)で、その値は検索結果エントリと同じ方法でエンコードされます。

ldapmodifyリクエストでの読込み前制御の使用例を次に示します:

$ ldapmodify -h localhost -p 1389 -D "cn=directory manager" -j pwd-file \
--preReadAttributes=telephoneNumber
dn: uid=aaltay,ou=People,dc=example,dc=com
changetype: modify
replace: telephoneNumber
telephoneNumber: +1 995 589 4444

Processing MODIFY request for uid=user.199,ou=People,dc=exampele,dc=com
MODIFY operation successful for DN uid=aaltay,ou=People,dc=example,dc=com
Target entry before the operation:
dn: uid=aaltay.199,ou=People,dc=example,dc=com
telephoneNumber: +1 995 589 3333

D.11.16 LDAP結果

LDAP結果要素は、様々なタイプのLDAP操作のレスポンスに使用される汎用プロトコルopです。LDAP結果の基本的な定義は次のとおりです:

LDAPResult ::= SEQUENCE {
resultCode         ENUMERATED {
success                      (0),
operationsError              (1),
protocolError                (2),
timeLimitExceeded            (3),
sizeLimitExceeded            (4),
compareFalse                 (5),
compareTrue                  (6),
authMethodNotSupported       (7),
strongerAuthRequired         (8),
-- 9 reserved --
referral                     (10),
adminLimitExceeded           (11),
unavailableCriticalExtension (12),
confidentialityRequired      (13),
saslBindInProgress           (14),
noSuchAttribute              (16),
undefinedAttributeType       (17),
inappropriateMatching        (18),
constraintViolation          (19),
attributeOrValueExists       (20),
invalidAttributeSyntax       (21),
-- 22-31 unused --
noSuchObject                 (32),
aliasProblem                 (33),
invalidDNSyntax              (34),
-- 35 reserved for undefined isLeaf --
aliasDereferencingProblem    (36),
-- 37-47 unused --
inappropriateAuthentication  (48),
invalidCredentials           (49),
insufficientAccessRights     (50),
busy                         (51),
unavailable                  (52),
unwillingToPerform           (53),
loopDetect                   (54),
-- 55-63 unused --
namingViolation              (64),
objectClassViolation         (65),
notAllowedOnNonLeaf          (66),
notAllowedOnRDN              (67),
entryAlreadyExists           (68),
objectClassModsProhibited    (69),
-- 70 reserved for CLDAP --
affectsMultipleDSAs          (71),
-- 72-79 unused --
other                        (80), ...  },
matchedDN          LDAPDN,
diagnosticMessage  LDAPString,
referral           [3] Referral OPTIONAL }

LDAP結果の要素は次のとおりです:

結果コード

操作の結果についての汎用情報を提供する整数値。前述の定義ではいくつかの結果コードが指定されますが、別の仕様では多くの別の値が定義されています。

一致したDN

リクエストが存在しないエントリを指定した場合に、見つかった最も近い上位エントリのDNを指定するDN値。一致したDN要素がレスポンスに対して適切でなければ、空のDNの場合があります。

診断メッセージ

処理の結果についての追加情報を提供する判読可能なメッセージ。通常、エラー・メッセージに使用されますが、正常な操作で表示される場合もあります。メッセージがなければ、空の文字列の場合があります。

リフェラル

クライアントが操作を試行できる他のサーバーのLDAP URLのセット。リフェラルがなければ、この要素は欠落する場合があります。

D.11.17 LDAPS

LDAPSは、Secure Sockets Layer上のLightweight Directory Access Protocol通信を指すために使用される用語です。

D.11.18 LDAP検索フィルタ

検索フィルタは、LDAP検索操作で、一致するエントリの定義のための基準を定義するメカニズムを提供します。LDAPで定義される検索フィルタには、次の10種類のタイプがあります:

AND検索フィルタ

0個以上の検索フィルタ要素を保持するコンテナとして機能します。ANDフィルタに含まれるすべての検索フィルタは、一致するANDフィルタのターゲット・エントリと一致する必要があります。

OR検索フィルタ

0個以上の検索フィルタ要素を保持するコンテナとして機能します。ORフィルタに含まれる少なくとも1つの検索フィルタは、一致するORフィルタのターゲット・エントリと一致する必要があります。

NOT検索フィルタ

1つの検索フィルタ要素のコンテナとして機能します。埋込みフィルタは、一致するNOTフィルタのターゲット・エントリとは一致しません。

等価検索フィルタ

指定された属性に対して指定された値を含むエントリを識別するためのメカニズムを提供します。

部分文字列検索フィルタ

指定された部分文字列と一致する属性値を含むエントリを識別するためのメカニズムを提供します。

大きいか等しい検索フィルタ

指定された値以上の属性値を含むエントリを識別するためのメカニズムを提供します。

小さいか等しい検索フィルタ

指定された値以下の属性値を含むエントリを識別するためのメカニズムを提供します。

プレゼンス検索フィルタ

指定された属性に少なくとも1つの値を含むエントリを識別するためのメカニズムを提供します。

近似検索フィルタ

指定された値におおよそ等しい属性値を含むエントリを識別するためのメカニズムを提供します。

拡張可能な一致検索フィルタ

拡張可能なメカニズムを使用して、一致するエントリを識別するために一致ルールを使用するメカニズムを提供します。

LDAP検索フィルタおよび検索フィルタを文字列として表現するメカニズムの詳細は、RFC 4515 (http://www.ietf.org/rfc/rfc4515.txt)を参照してください。

D.11.19 ldapsearchコマンド

ldapsearchコマンドは、LDAP検索操作のリクエストに使用できます。

このコマンドの使用方法の詳細は、「ldapsearch」を参照してください。

D.11.20 LDAP trueフィルタ

LDAP trueフィルタは特別なタイプのAND検索フィルタで、埋込みフィルタ・コンポーネントを含みません。LDAP trueフィルタと呼ばれるのは、常にtrueと評価され、エントリのいずれかと一致するためです。

LDAP trueフィルタの文字列表現は、(&)です。LDAP trueフィルタは、RFC 4526 (http://www.ietf.org/rfc/rfc4526.txt)で説明されています。

D.11.21 LDAPサブエントリ

LDAPサブエントリは、ldapSubEntryオブジェクト・クラスを含むエントリのタイプです。これらのエントリでは、サーバー用の操作データを保持することを意味します。OIDが1.3.6.1.4.1.7628.5.101.1で値のないリクエスト制御を含めて明示的にリクエストしない場合は、クライアントに返されないという点で操作属性に似ています。この動作はdraft-ietf-ldup-subentryで説明されています。

検索でこの制御を使用する例は、「LDAPサブエントリ制御を使用した検索」を参照してください。

D.11.22 LDAP URL

LDAP URLは、エントリまたは検索基準のセットの参照に使用できるURLのタイプです。LDAP URLのフォーマットは、RFC 4516 (http://www.ietf.org/rfc/rfc4516.txt)に説明されており、次の要素を含む場合があります:

- ディレクトリ・サーバーのアドレス

- ディレクトリ・サーバーのポート番号

- 検索ベースDN

- 検索属性のセット

- 検索する検索範囲

- 一致するエントリを識別するLDAP検索フィルタ

- 検索の処理方法についての情報を提供する拡張セット

これらの要素はすべてオプションです。技術的には、LDAP URLに必要なものは文字列ldap://のみです。ただし、より完全なURLはldap://directory.example.com:389/dc=example,dc=com?cn,givenName,sn?sub?(uid=john.doe)です。

D.11.23 LDIFエクスポート

LDIFエクスポート操作は、ディレクトリ・サーバー・バックエンドのコンテンツのすべてまたは一部をLDAPデータ変換形式を使用してファイルに書き込む処理です。LDIFエクスポートは、export-ldifコマンドまたはLDIFエクスポート・タスクを使用して開始できます。

D.11.24 LDIFインポート

LDIFインポート操作は、LDAPデータ変換形式の情報を保有するファイルからディレクトリ・サーバー・バックエンドへデータを追加する処理です。LDIFインポートは、LDAP追加操作よりもきわめて効率的にサーバーへ大量のエントリを追加する方法を提供します。

LDIFインポート操作は、import-ldifコマンドまたはLDIFインポート・タスクを使用して開始できます。

D.11.25 リーフ・エントリ

リーフ・エントリは、サーバー内に下位エントリを持たないエントリです。

D.11.26 小さいか等しい検索フィルタ

小さいか等しい検索フィルタはLDAP検索フィルタのタイプで、指定されたアサーション値以下の、指定された属性の特定の値を含むエントリの識別に使用できます。サーバーは、順序付け一致ルールを判断に使用します。

LDAP小さいか等しい検索フィルタの文字列表現は、左カッコに続く属性名、小なり記号、等号、アサーション値および右カッコで構成されます。たとえば、小さいか等しいフィルタの(createTimestamp<=20070101000000Z)は、20070101000000Z以下のcreateTimestamp値を保有するエントリと一致します。

D.11.27 辞書編集アルゴリズム

プロキシ分散アルゴリズム。アルファベットの範囲設定に基づいてデータをパーティションに分割します。たとえば、[A-E[が1つのパーティションで、[E-H[が次のパーティションです。

D.11.28 Lightweight Directory Access Protocol

Lightweight Directory Access Protocol (LDAP)は、ディレクトリ・サーバーとの通信に使用できるプロトコルです。抽象構文表記法1の基本エンコーディング・ルールのサブセットを使用して、通信をメッセージにエンコードするオープン規格です。

コアLDAPv3の仕様は、実際のプロトコル用エンコーディングを定義するRFC 4511 (http://www.ietf.org/rfc/rfc4511.txt)とともに、RFC 4510 (http://www.ietf.org/rfc/rfc4510.txt)で説明されています。その他多くの仕様が、多くのrequest for commentsおよびInternet Draftで定義されています。

LDAPは、いくつかの異なるタイプの操作を次のように定義します:

中止操作

進行中の操作の処理を中止する方法を提供

追加操作

サーバーに新規エントリを追加する方法を提供

バインド操作

サーバーへの認証の方法を提供

比較操作

エントリが指定された属性値アサーションを保有するかどうかを判断する方法を提供

削除操作

サーバーからエントリを削除する方法を提供

拡張操作

コアLDAPプロトコルに対する拡張として実装されるカスタム処理を実行する方法を提供

変更操作

サーバー内のエントリのコンテンツを変更する方法を提供

DN変更操作

サーバー内のエントリの名前を変更する方法を提供

検索操作

指定された基準のセットに一致するすべてのエントリを識別する方法を提供

アンバインド操作

サーバーから切断するクライアントを示す方法を提供

D.11.29 ロード・バランシング

ロード・バランシングはプロキシ・デプロイメントのタイプで、レプリケートされたリモートLDAPサーバーのセットへのシングル・アクセスを提供します。クライアントのリクエストの送信先であるリモートLDAPサーバーの選択は、ロード・バランシング・アルゴリズムにより決定されます。

D.11.30 検索制限

検索制限は、ディレクトリ・サーバー内の構成オプションで、検索操作処理の進行中にサーバーが調べるエントリ数の制限を実施するために使用できます。この制限は、指定された検索基準に一致するかどうかにかかわらず、サーバーが調べるすべてのエントリに適用されます。

検索制限の構成属性は、索引なし検索またはきわめて大きな候補リストを伴う検索の影響を制限するために使用できます。

検索制限の構成の詳細は「ユーザー・アカウントへのリソース制限の設定」および「ルート・ユーザーのリソース制限の設定」を参照してください。

D.12 M

D.12.1 MakeLDIFコマンド

MakeLDIFコマンドは、LDAPデータ変換形式でエントリを生成するメカニズムを提供します。エントリは、データを生成する方法の制御に使用できる多くのタグを含む、テンプレートに基づいて生成されます。

このコマンドの使用方法の詳細は、「make-ldif」を参照してください。「MakeLDIFテンプレート・ファイルの作成」では、MakeLDIFテンプレート・ファイルの有効な構造およびコンテンツについて説明します。

D.12.2 ManageDSAIT制御

ManageDSAIT制御は、サーバーがスマート・リフェラルを通常のエントリとして扱うようにリクエストするために、使用できる制御のタイプです。削除操作、変更操作またはDN変更操作に追加して、クライアントに返信されたリフェラルではなくスマート・リフェラルを含むエントリに対して操作を適用するようにサーバーにリクエストできます。検索操作にも追加して、検索結果の参照ではなく検索結果エントリとして、スマート・リフェラルを含むエントリをサーバーが返す必要があることを示します。

ManageDSAIT制御はRFC 3296 (http://www.ietf.org/rfc/rfc3296.txt)で定義されています。オブジェクト識別子は2.16.840.1.113730.3.4.2で、値はありません。

検索リクエストでこの制御を使用する例は、「DSA ITの管理制御を使用した検索」を参照してください。

D.12.3 一致したDN

一致したDNは、LDAP結果オブジェクトの要素で、サーバーで見つかった最も近い一致するエントリの追加情報を提供できます。通常、リクエストがターゲット設定したエントリが存在しない場合に使用され、この場合は、一致したDNには、サーバーに存在しており指定されたエントリに最も近い祖先であるエントリの識別名が含まれます。たとえばある操作が存在しないエントリのuid=doesnt.exist,ou=People,dc=example,dc=comをターゲット設定し、エントリのou=People,dc=example,dc=comがサーバーに存在する場合は、これが一致したDNとして返されます。

存在しないエントリをターゲット設定した操作から一致したDNが返される保証はなく、この場合は、LDAP結果の一致したDN要素は空の文字列です。たとえば、サーバー内でその他のエントリとの階層関係を持たないエントリに、リクエストがターゲット設定した場合に使用できます。

D.12.4 一致値制御

一致値制御は、検索操作に追加して、クライアントに返されるエントリに、指定されたフィルタと一致する値のみを含む必要があることを示す制御のタイプです。RFC 3876 (http://www.ietf.org/rfc/rfc3876.txt)で説明されています。

リクエスト制御のOIDは1.2.826.0.1.3344810.2.3です。値は次のようにエンコードされます:

ValuesReturnFilter ::= SEQUENCE OF SimpleFilterItem

SimpleFilterItem ::= CHOICE {
equalityMatch   [3] AttributeValueAssertion,
substrings      [4] SubstringFilter,
greaterOrEqual  [5] AttributeValueAssertion,
lessOrEqual     [6] AttributeValueAssertion,
present         [7] AttributeDescription,
approxMatch     [8] AttributeValueAssertion,
extensibleMatch [9] SimpleMatchingAssertion }

SimpleMatchingAssertion ::= SEQUENCE {
matchingRule    [1] MatchingRuleId OPTIONAL,
type            [2] AttributeDescription OPTIONAL,
--- at least one of the above must be present
matchValue      [3] AssertionValue}

対応するレスポンス制御はありません。

検索リクエストでこの制御を使用する例は、「一致値フィルタ制御を使用した検索」を参照してください。

D.12.5 一致ルール

一致ルールは、サーバーが属性の値と相互に作用する方法を定義するスキーマ要素です。一致ルールには、次の3つの標準タイプがあります:

- 等価一致ルールは、1つの属性値が別の属性値に等しいかどうかを判断するために使用されます。通常、この判断は正規化された値に基づいて実行され、重要ではない相違(大文字と小文字の相違または余分な空白など)は無視されます。

- 順序付け一致ルールは、ソート済リストの2つの値の間の相対的な順序を判断するために使用されます。この判断はサーバー側ソート制御の実行の際に使用されますが、大きいか等しい検索フィルタおよび小さいか等しい検索フィルタのフィルタ・コンポーネントでも使用されます。

- 部分文字列一致ルールは、指定された部分文字列検索フィルタが値に含まれるかどうかの判断に使用されます。

これらの標準一致ルールに加えて、ディレクトリ・サーバーは4番目のタイプ、近似一致ルールを定義します。これは、ある値が別の値におおよそ等しいかどうかの判断に使用されます。おおよそ等しいという定義には幅がありますが、一般的に使用される定義では、類似する、ということです。

一般的な一致ルールの例を次に示します:

booleanMatch

2つのブール値が互いに等しいかどうかを判断する等価一致ルール。

caseExactMatch

大文字と小文字の相違を無視せず、2つの文字列値が互いに等しいかどうかを判断する等価一致ルール。

caseExactOrderingMatch

大文字と小文字の相違を無視せず、2つの文字列値の間で相対的な順序を判断するために使用される順序付け一致ルール。

caseExactSubstringsMatch

大文字と小文字の相違を無視せず、指定された部分文字列が文字列値に含まれるかどうかの判断に使用される部分文字列一致ルール。

caseIgnoreMatch

大文字と小文字の相違を無視して、2つの文字列値が互いに等しいかどうかを判断する等価一致ルール。

caseIgnoreOrderingMatch

大文字と小文字の相違を無視して、2つの文字列値の間で相対的な順序を判断するために使用される順序付け一致ルール。

caseIgnoreSubstringsMatch

大文字と小文字の相違を無視して、指定された部分文字列が文字列値に含まれるかどうかの判断に使用される部分文字列一致ルール。

distinguishedNameMatch

RDNコンポーネントを区切るカンマの前後の余分な空白、およびRDN名と値を区切る等号を無視して、2つの識別名が互いに等しいかどうかを判断する等価一致ルール。個別のRDN値は、対応するRDN属性に関連付けられる一致ルールに基づいて比較されます。

generalizedTimeMatch

2つの一般的な時刻値が互いに等しいかどうかを判断する等価一致ルール。

generalizedTimeOrderingMatch

2つの一般的な時刻値の間で相対的な順序を判断するために使用される順序付け一致ルール。

integerMatch

2つの整数値が互いに等しいかどうかを判断する等価一致ルール。

integerOrderingMatch

2つの整数値の間で相対的な順序を判断するために使用される順序付け一致ルール。

octetStringMatch

2つの値が互いに等しいかどうかをバイト対バイト比較で判断する等価一致ルール。

多くの場合、ディレクトリ・サーバーは、クライアントが認識する必要のない、完全に暗黙的な方法で一致ルールを使用します。クライアントが指定された属性タイプを参照する際は常に、サーバーはその属性に対する適切な一致ルールを自動的に認識して使用します。ただし、拡張可能な一致検索フィルタを使用して操作を実行する際に、サーバーが特定の一致ルールを使用するように、クライアントがリクエストすることも可能です。

サーバーで定義される一致ルールのセットは、サブスキーマ・サブエントリのmatchingRules属性を取得して確認できます。一致ルールの詳細は、「一致ルールの理解」を参照してください。

D.12.6 一致ルールの使用

一致ルールの使用はスキーマ要素で、指定された一致ルールとともに使用可能な属性タイプを判断するために使用できます。拡張可能な一致検索フィルタを使用する場合にのみ適用されることに注意してください。

一致ルールの使用の定義には、適用する一致ルールのオブジェクト識別子、および一致ルールとともに使用できる属性タイプの名前またはOIDのリストが含まれます。属性がこのリストに含まれない場合は、関連付けられた一致ルールはともに使用できません。指定された一致ルールに対して定義される一致ルールの使用がない場合は、その一致ルールは任意の属性タイプとともに使用できるとみなされます。

サーバーで定義される一致ルールの使用のセットは、サブスキーマ・サブエントリのmatchingRuleUse属性を取得して確認できます。一致ルールの使用の詳細は、「一致ルールの使用の理解」を参照してください。

D.12.7 MD5

MD5は、RFC 1321 (http://www.ietf.org/rfc/rfc1321.txt)で定義される一方向メッセージ・ダイジェスト・アルゴリズムです。任意の長さの値を128ビット値にエンコードして、元のクリアテキストに戻して特定できないようにするために使用できます。通常、データのチェックサム用のメカニズムとして使用され、パスワードやその他機密情報のエンコードにも使用されます。

最近の暗号化技術の進歩により、MD5アルゴリズムの脆弱性が見つかっていることに注意してください。これらの発見は、ディレクトリ・サーバーによるMD5アルゴリズムの使用方法のセキュリティに直接は影響しませんが、セキュア・ハッシュ・アルゴリズムなどのより厳格なメカニズムを使用することをお薦めします。

D.12.8 メッセージ

「LDAPメッセージ」を参照してください。

D.12.9 メッセージID

メッセージIDは、メッセージに含まれる整数値で、リクエスト・メッセージとレスポンス・メッセージの関連付けに使用されます。クライアントはリクエスト・メッセージに含めるメッセージID値を選択し、サーバーはすべてのレスポンス・メッセージで同じメッセージIDを使用します。これによりクライアントは、いつでも同じ接続上で複数のリクエストを進行させることができます。すべての進行中のリクエストは常に、異なるメッセージIDを保有する必要があります。通常、クライアントはすべてのリクエスト・メッセージを対象にカウンタを順に増分し続けており、各リクエストは前回のリクエストとは異なるメッセージIDを取得します。

未承諾通知メッセージは、常にメッセージID値が0であることに注意してください。その他のすべてのLDAPメッセージのメッセージID値は、1から2147483647の間です。

D.12.10 変更

変更は、単一の属性に対する変更を記述するLDAP変更操作の要素です。変更リクエストには、ターゲット・エントリに対する1つ以上の変更を含めることができます。

変更は、変更のタイプ(追加、削除、置換または増分)を記述する変更タイプ、および属性説明と0個以上の属性値を含む属性で構成されます。

D.12.11 変更タイプ

変更タイプは、変更が実行された属性値を属性が保有できるようにする4つの方法のうちの1つを説明します。定義された変更タイプは次のとおりです:

追加

1つ以上の値がターゲット属性に追加されます。属性がターゲット・エントリに存在しない場合は、指定された値が追加されます。そうでない場合は、指定された値は、その属性に対してすでに定義された値のセットに追加されます。追加変更タイプは常に少なくとも1つの値を指定する必要があります。

削除

1つ以上の値がターゲット属性から削除されるか、その属性全体がターゲット・エントリから削除されます。1つ以上の特定の値が指定される場合は、それらの値のみがターゲット属性から削除されます(指定される値がその属性の値のセット全体を表す場合は、その属性がエントリから削除されます)。値が指定されない場合は、(含まれる値の数にかかわらず)属性全体がエントリから削除されます。

置換

ターゲット属性の値のセットを指定された値のセットで置換します。置換は0個以上の値を保有し、その動作は次のとおりです:

- エントリのターゲット属性に1つ以上の値が存在し、置換変更に値が含まれない場合は、ターゲット属性はエントリから削除されます。

- エントリのターゲット属性に1つ以上の値が存在し、置換変更に1つ以上の値が含まれる場合は、既存の値のセットは新しい値のセットに置換されます。

- エントリにターゲット属性が存在せず、置換変更に値が含まれない場合は、アクションは発生しません。

- エントリにターゲット属性が存在せず、置換変更に1つ以上の値が含まれる場合は、指定された値のセットを保有する属性がエントリに作成されます。

増分

ターゲット属性の値が指定された量により増分されます。ターゲット属性は1つの値のみを保有してエントリに存在し、その値は整数である必要があります。増分変更も1つの値のみを含み、その値は整数である必要があります。既存の値が増分値で指定された量により増分されます。増分値が負数の場合は、既存の値から、増分値の絶対値に等しい量が減じられます。

D.12.12 DN変更操作

「LDAP DN変更操作」を参照してください。

D.12.13 変更操作

「LDAP変更操作」を参照してください。

D.12.14 監視エントリ

監視エントリは、サーバー・コンポーネントの情報を提供するサーバーのエントリのタイプです。監視の実施に関する統計情報、サーバーの状態の情報または値などその他の情報を提供できます。

ディレクトリ・サーバーは、汎用監視エントリに識別名のcn=monitorを指定します。その他多くの次のような監視エントリがその下に存在します:

- サーバーで構成された各バックエンドの情報

- サーバーで構成された各接続ハンドラの情報

- サーバーが実行しているシステムの一般的な情報

- サーバー・ワーク・キューの状態の情報

- サーバーのバージョン情報

- サーバーで現在アクティブなすべてのスレッドのスタック・トレース

D.13 N

D.13.1 名前書式

名前書式はスキーマ要素で、どの属性タイプを構造オブジェクト・クラスに基づいたエントリの相対識別名で使用するかを制御するために使用できます。

名前書式の定義には次のコンポーネントがあります:

- 名前書式を一意に識別するために使用されるオブジェクト識別子。

- 名前書式の参照をより容易にするために使用可能な0個以上の名前のセット。

- 名前書式が関連付けられる構造オブジェクト・クラスの名前またはOID。構造クラスを持つエントリは、名前書式の要件に準拠したRDNを保有する必要があります。

- 関連付けられた構造クラスを含むエントリのRDNに存在する必要のある属性の、属性タイプ名またはOIDの1つ以上のセット。

- 関連付けられた構造クラスを含むエントリのRDNにオプションで存在する場合のある属性の、1つ以上の属性タイプ名またはOIDのオプション・セット。

サーバーで定義される名前書式のセットは、サブスキーマ・サブエントリのnameForms属性を取得して確認できます。名前書式の詳細は、「名前書式の理解」を参照してください。

D.13.2 ネーミング・コンテキスト

ネーミング・コンテキストは接尾辞とも呼ばれ、サーバーのディレクトリ情報ツリーで最上位のエントリです。このエントリには親はありません。

サーバーで定義されるネーミング・コンテキストのセットは、ルートDSEのnamingContexts属性にリストされます。ネーミング・コンテキストは、ワークフローを介して参照可能です。

D.13.3 ネットワーク・グループ

ネットワーク・グループには、クライアント接続のカテゴリを定義する基準のセットが含まれています。サーバーに送信されたクライアント・リクエストがネットワーク・グループにアタッチされたポリシーに適合している場合は、ネットワーク・グループはそのリクエストをワークフローに転送します。

D.13.4 リーフ以外のエントリ

リーフ以外のエントリは、サーバー内に少なくとも1つの下位エントリを保有するエントリです。

D.13.5 正規化された値

正規化された値は、他の値と効率的に比較できるようにする方法で処理された値です。正規化処理は、一致ルールを使用して実行され、一致ルールのタイプに基づいて変わります。実行できる変換の種類には次のものがあります:

- 大文字と小文字の区別による重要ではない相違を排除するため、すべての文字を小文字(または大文字)に変換

- 値の不要な空白を排除

- 複数の表現を持つ値を共通の形式に変換

D.13.6 切断の通知未承諾通知

切断の通知は、なんらかの理由(サーバーが停止される、またはクライアントが長時間アイドル状態であるなど)により、クライアントとの接続をサーバーが閉じようとしていることを示すために使用できる未承諾通知のタイプです。

切断の通知を含む拡張レスポンスのOIDは1.3.6.1.4.1.1466.20036です。レスポンス値はありませんが、結果コードにより切断の理由が示され、診断メッセージにより判読可能な説明が提供されます。

D.13.7 NOT検索フィルタ

NOT検索フィルタは、1つの埋込み検索フィルタを保持するコンテナとして機能するためのLDAP検索フィルタのタイプです。NOTフィルタは基本的に逆操作で、エントリがNOTフィルタと一致するには、埋込みフィルタとは一致しません。

NOTフィルタは、フィルタ全体をカッコで囲み、左カッコの直後に感嘆符を配置した文字列で表されます。たとえば、フィルタ(!(objectClass=person))は、オブジェクト・クラス値がpersonではないエントリのみ一致します。

D.13.8 数値アルゴリズム

数値の範囲設定に基づいてデータをパーティションに分割するプロキシ分散アルゴリズム。たとえば、[1-1000[が1つのパーティションで、[1000-2000[が次のパーティションです。

D.13.9 nsuniqueid

ディレクトリ・サーバーの各エントリに割り当てる一意の識別子で、LDAPデータベースとしてOracle Directory Server Enterprise Editionを使用するレガシー・アプリケーションからOracle Unified Directoryへの移行の間の名前の競合を解決します。

D.14 O

D.14.1 オブジェクト・クラス

オブジェクト・クラスはスキーマ要素で、オブジェクト識別子および名前のセットを、必須およびオプションの属性タイプのセットと関連付けます。

オブジェクト・クラスのコンポーネントの定義には次のものがあります:

- オブジェクト・クラスを一意に識別するために使用されるOID。

- オブジェクト・クラスの参照をより容易にするために使用できる0個以上の名前のセット。

- オプションの上位クラス。必須またはオプション、あるいはその両方の追加する属性タイプを定義できます。

- オプションのオブジェクト・クラス・タイプ値。オブジェクト・クラスが構造オブジェクト・クラス、補助オブジェクト・クラスまたは抽象オブジェクト・クラスのいずれであるかを示します。

- 属性の1つ以上の属性タイプ名またはOIDのオプション・セット。属性は、オブジェクト・クラスに含まれるエントリに存在する必要があります。

- 属性の1つ以上の属性タイプ名またはOIDのオプション・セット。属性は、オブジェクト・クラスに含まれるエントリにオプションで存在する場合があります。

各エントリに1つの構造オブジェクト・クラスを必要とし、0個以上の補助クラスが存在する場合もあります。エントリのオブジェクト・クラスの一連のセットは、必須または存在できる属性タイプのセットを定義します。構造クラスは、名前書式、DITコンテンツ・ルールまたはDIT構造ルール、あるいはその両方とエントリを関連付けるためにも使用できます。

サーバーで定義されたオブジェクト・クラスのセットは、サブスキーマ・サブエントリのobjectClasses属性を取得して確認できます。オブジェクト・クラスの詳細は、「オブジェクト・クラスの理解」ドキュメントを参照してください。

D.14.2 オブジェクト・クラス・タイプ

オブジェクト・クラス・タイプは、オブジェクト・クラスのカテゴリの定義に使用されます。次の3つのオブジェクト・クラス・タイプ値があります:

構造オブジェクト・クラス

構造オブジェクト・クラスは、エントリの主要なタイプの定義に使用されます。各エントリは構造クラスを1つ必要とし、構造クラスはエントリを説明するオブジェクトの主要なタイプを定義します。

補助オブジェクト・クラス

補助オブジェクト・クラスは、エントリの特性の定義に使用されます。1つのエントリは、0個以上の補助クラスを保有できます。エントリが保有できる補助クラスのセットは、エントリの構造クラスに関連付けられたDITコンテンツ・ルールにより制御できます。

抽象オブジェクト・クラス

抽象オブジェクト・クラスは、エントリでは直接使用せず、構造オブジェクト・クラスまたは補助オブジェクト・クラスのサブクラスとする必要があります。

LDAPオブジェクト・クラスで使用される継承モデルは、Javaクラスの継承モデルとよく似ています。エントリに構造オブジェクト・クラスが1つのみ必要なように、Javaクラスにもスーパークラスが1つ必要です。同様に、エントリは複数の補助クラスを保有できますが、Javaクラスは複数のインタフェースを実装できます。最後に、抽象オブジェクト・クラスのみを含むエントリを作成できないように、抽象Javaクラスのインスタンス化はできません。

D.14.3 オブジェクト識別子

オブジェクト識別子(OID)は、ピリオドで区切られた一連の整数で構成される文字列です。ディレクトリ・サーバーでは、次のような様々な要素のタイプの一意の識別子として使用されます:

- 属性構文

- 一致ルール

- 属性タイプ

- オブジェクト・クラス

- 名前書式

- 制御

- 拡張操作

- サポートされている機能

D.14.4 操作ID

操作IDは、クライアント接続で実行される各操作に割り当てられる整数の識別子です。主にロギングのために使用して、レスポンス・ログ・メッセージを対応するリクエスト・メッセージと関連付けることができます。

クライアント接続で最初に実行される操作には操作IDに0が割り当てられ、クライアント接続上で受信される各追加リクエストのために操作IDが1ずつ増分されます。

D.14.5 操作属性

ユーザー属性は、directoryOperation、distributedOperationまたはdSAOperationの属性使用方法を持つ属性タイプです。操作属性は、サーバー自体で処理を行ったり、サーバーで維持されている(クライアントから明示的に提供されることのない)その他のデータを保持するために必要な情報を格納する場合に使用されます。

操作属性は、検索属性のリストに明示的に含まれる場合を除き、検索操作で返されたエントリには含まれません。明示的な値として+(プラス記号)もすべての操作属性を返すリクエストに含める場合があります。

D.14.6 順序付け索引

順序付け索引は、属性の値の相対的な順序を追跡するために使用される索引のタイプです。正規化された値に対して等価一致ルールのかわりに順序付け一致ルールを使用することを除けば、等価索引とよく似ています。順序付け索引は、対応する順序付け一致ルールを持たない属性に対しては維持できません。

D.14.7 OR検索フィルタ

OR検索フィルタは、0個以上のその他の検索フィルタを保持するコンテナとして機能するためのLDAP検索フィルタのタイプです。エントリがORフィルタと一致するには、そのORフィルタに含まれる少なくとも1つのフィルタと一致する必要があります。

ORフィルタは、フィルタ全体をカッコで囲み、左カッコの直後にパイプ記号(|)を配置した文字列で表されます。たとえば、フィルタ(|(uid=john.doe)(uid=jane.doe))は、(uid=john.doe)および(uid=jane.doe)の等価フィルタを埋め込んだOR検索フィルタを表します。

埋込みフィルタを含まないORフィルタは、LDAP falseフィルタと呼ばれます。LDAP falseフィルタの文字列表現は(|)で、LDAP falseフィルタはいずれのターゲット・エントリとも一致しません。

D.15 P

D.15.1 パーティション

プロキシ分散デプロイメントでは、データは、パーティションと呼ばれるより小さなデータ・チャンクに分割されます。通常、データのパーティションは、高可用性を保証するために、個別のリモートLDAPサーバーまたはレプリケートされたリモートLDAPサーバーのセットに保管されます。

D.15.2 パスワード

パスワードは、一部の認証メカニズムでアイデンティティの証明に使用できる非公開の値です。特に、パスワードは簡易認証、およびCRAM-MD5 SASLメカニズム、DIGEST-MD5 SASLメカニズム、PLAIN SASLメカニズムのSimple Authentication and Security Layerメカニズムで使用されます。

パスワードによるセキュリティは、パスワードの所有者のみがパスワードの内容を認識するという事実に完全に基づいています。別の者がなんらかの方法であるユーザーのパスワードを知ることがあれば、その第三者はユーザーを偽装し、ユーザーが使用可能な操作を実行できます。

ディレクトリ・サーバーには多くのパスワード・ポリシー機能があり、パスワードが第三者個人に知られないことを保証する支援に使用できますが(たとえば、脆弱なパスワードの使用をユーザーに許可しないことを保証する支援をしたり、総当たり攻撃から保護したり、保護された方法で実行される認証の試行およびパスワードの変更を要求したりします)、多くの場合、パスワードは証明書のような別の種類の識別よりも脆弱な保護の形式であるとみなされます。

D.15.3 パスワード有効期限

パスワード有効期限は、ディレクトリ・サーバー・パスワード・ポリシーの要素で、ユーザーが同じパスワードを継続して使用できる期間の長さを制限するために使用できます。パスワード有効期限が有効化されている場合は、ユーザーがパスワードを変更すると、最大パスワード経過時間として指定された期間、パスワードを使用できます。パスワード有効期限が近づくと、ユーザーはバインド・レスポンスの制御の形式で警告メッセージを受け取ることができます。パスワードの有効期限が切れると、それ以降、ユーザーは認証を許可されません。

ユーザーのパスワードの有効期間が切れると、アカウントを使用するには、管理者がパスワードのリセットを実行する必要があります。または、パスワード・ポリシーが適切に構成されている場合は、パスワード変更拡張操作を使用して、ユーザーが自分の有効期限の切れたパスワードを変更することもできます。

D.15.4 パスワード・ジェネレータ

パスワード・ジェネレータは、パスワード変更拡張操作の一部として、ユーザーのパスワードを生成するために使用できるロジックの部分です。パスワード変更リクエストに新しいパスワードが含まれていない場合に使用されます。

D.15.5 パスワード変更拡張操作

パスワード変更拡張操作は、ユーザーのパスワードの変更またはパスワードのリセットに使用できる拡張操作のタイプです。RFC 3062 (http://www.ietf.org/rfc/rfc3062.txt)で説明されており、リクエスト操作およびレスポンス操作のOIDは両方とも1.3.6.1.4.1.4203.1.11.1です。

パスワード変更リクエストの値は次のとおりです:

PasswdModifyRequestValue ::= SEQUENCE {
userIdentity    [0]  OCTET STRING OPTIONAL
oldPasswd       [1]  OCTET STRING OPTIONAL
newPasswd       [2]  OCTET STRING OPTIONAL }

パスワード変更レスポンスの値は次のとおりです:

PasswdModifyResponseValue ::= SEQUENCE {
genPasswd       [0]     OCTET STRING OPTIONAL }

D.15.6 パスワード・ポリシー

ディレクトリ・サーバー・パスワード・ポリシーは、サーバーでのパスワードの保管と維持の方法、およびユーザーの認証を許可する方法を制御するメカニズムを提供します。

パスワード・ポリシーの要素には次のものがあります:

- ユーザー・パスワードの保管に使用される属性。デフォルトでは、userPassword属性です。

- サーバーで保管されたパスワードのエンコードに使用されるパスワード記憶スキームのデフォルトのセット。

- 非推奨パスワード記憶スキームのセット。ユーザーの認証に使用できますが、正常なバインド上のデフォルトのスキームを使用してパスワードを再エンコードします。

- ユーザーが自分のパスワードを変更できるかどうかを示すフラグ。

- パスワード有効期限に関連する多くの設定。最大パスワード経過期間、有効期限前の警告およびユーザーがパスワードの有効期限切れ後にパスワードを変更できるかどうかが含まれます。

- アカウント・ロックアウトに関連する多くの設定。認証を試行して何度も失敗した後で、ユーザーの認証を妨げるために使用できます。

- ユーザーが初めて認証するパスワードの変更が必要かどうか、または管理者にリセットされた後でパスワードの変更が必要かどうか、あるいはその両方を示すフラグ。

- パスワード・バリデータのセット。提案された新しいパスワードの値の使用が許可されるかどうかの判断に使用できます。

- パスワードの変更を許可するために、現在のパスワードの入力をユーザーに要求するかどうかを示すフラグ。

- 新しいパスワードがサーバーで定義されるパスワード記憶スキームの1つを使用してすでにエンコードされている場合、そのパスワードの指定をクライアントに許可するかどうかを示すフラグ。事前にエンコードされたパスワードの許可が必要なアプリケーションもありますが、パスワード・バリデータのように、適用される可能性のある制限をユーザーがバイパスできる場合もあります。

- 最終ログイン時刻の維持に関する設定。値の保管に使用する属性、タイムスタンプで使用するフォーマットおよび認証なしで長時間経過したアカウントをロックするかどうかが含まれます。

- 保護された方法による認証をユーザーに要求するのかどうか、または保護された方法によるパスワードの変更をユーザーに要求するのかどうか、あるいはその両方を制御するフラグ。

D.15.7 パスワード・ポリシー制御

パスワード・ポリシー・リクエスト制御はLDAP制御のタイプで、ユーザー・エントリに対する現在のパスワード・ポリシーの状態についての情報をリクエストするために使用できます。draft-sisbehera-ldap-password-policy (https://opends.dev.java.net/public/standards/draft-behera-ldap-password-policy.txt)で定義されています。リクエスト制御およびレスポンス制御のOIDは両方とも1.3.6.1.4.1.42.2.27.8.5.1です。リクエスト制御には値がありません。レスポンス制御の値は次のようにエンコードされます:

PasswordPolicyResponseValue ::= SEQUENCE {
warning [0] CHOICE {
timeBeforeExpiration [0] INTEGER (0 .. maxInt),
graceAuthNsRemaining [1] INTEGER (0 .. maxInt) } OPTIONAL,
error   [1] ENUMERATED {
passwordExpired             (0),
accountLocked               (1),
changeAfterReset            (2),
passwordModNotAllowed       (3),
mustSupplyOldPassword       (4),
insufficientPasswordQuality (5),
passwordTooShort            (6),
passwordTooYoung            (7),
passwordInHistory           (8) } OPTIONAL }

検索リクエストでこの制御を使用する例は、「パスワード・ポリシー制御を使用した検索」を参照してください。

D.15.8 パスワードのリセット

パスワードのリセットは、ユーザーのパスワードを変更するサーバー管理者の行為です。パスワードのリセットは、アカウントの保有者以外の任意のユーザーにより実行されるパスワードの変更です。

D.15.9 パスワード記憶スキーム

パスワード記憶スキームは、サーバーで保管されるユーザー・パスワードをエンコードするためのメカニズムを提供します。ユーザーが入力したパスワードが正しいかどうかをサーバーは判断できますが、多くの場合、パスワードは、クリアテキスト・パスワードの内容をユーザーに決定させない方法でエンコードされます。現在使用可能なパスワード記憶スキームには次のものがあります:

3DES

パスワードはトリプルDESを使用してエンコードされます。トリプルDESは、データ暗号化規格(DES)のバリエーションで、以前のものよりも3倍時間がかかりますが、厳格な信頼性があります。このアルゴリズムでは、1つの長さ192ビットの組合せキーのために3つの64ビットのキーを使用します。データは、第一の鍵で暗号化され、第二の鍵で復号化され、さらに第三の鍵で再度暗号化されます。3つの鍵すべて、第一のキーと第二のキー、または第二のキーと第三のキーが同一でないことを確認する必要があります。

AES

Advanced Encryption Standardは、128 (AES-128)ビット、192 (AES-192)ビットおよび256 (AES-256)ビットの長さの暗号鍵を使用して、128ビットのデータ・ブロックを処理できる、Rijndaelアルゴリズムに基づいた対称型ブロック暗号です。

BASE64

パスワードはbase64エンコーディングで、保護の形式はたいへん脆弱で、クライアントがこの記憶スキームを要求する場合にのみ使用されます。

BlowFish

パスワードはキーの長さが128ビットのBlowFishアルゴリズムを使用してエンコードされます。

CLEAR

パスワードはクリアテキストで保管されます。まったく保護がないため、クライアントがこの記憶スキームを要求した場合にのみ使用されます。

CRYPT

パスワードはUNIX暗号化アルゴリズムを使用してエンコードされます。一方向アルゴリズムですが、現在の標準よりも脆弱であるとみなされており、通常、この記憶スキームを要求するクライアントにのみ使用されます。

MD5

パスワードはMD5メッセージ・ダイジェスト・アルゴリズムのSaltなしのバージョンを使用してエンコードされます。saltハッシュをお薦めしますが、比較的安全で、セキュア・ハッシュ・アルゴリズムのバリアントはMD5よりも厳格であるとみなされます。

RC4

パスワードは、キーサイズが変更可能で、バイト単位で操作するストリーム暗号のRC4を使用してエンコードされます。このアルゴリズムは、ランダムな置換の使用に基づいています。

SMD5

パスワードはMD5メッセージ・ダイジェスト・アルゴリズムのSalt付きバージョンを使用してエンコードされます。

SHA

パスワードはSHA-1セキュア・ハッシュ・アルゴリズムのSaltなしのバージョンを使用してエンコードされます。このアルゴリズムではSalt付きのバリアントをお薦めします。

SSHA

パスワードはSHA-1セキュア・ハッシュ・アルゴリズムのSalt付きバージョンを使用してエンコードされます。これは、ディレクトリ・サーバーで使用されるデフォルトのパスワード記憶スキームです。

SSHA256

パスワードはSHA-2セキュア・ハッシュ・アルゴリズムのSalt付き256ビット・バージョンを使用してエンコードされます。

SSHA384

パスワードはSHA-2セキュア・ハッシュ・アルゴリズムのSalt付き384ビット・バージョンを使用してエンコードされます。

SSHA512

パスワードはSHA-2セキュア・ハッシュ・アルゴリズムのSalt付き512ビット・バージョンを使用してエンコードされます。

ディレクトリ・サーバーでは認証パスワード構文の使用もサポートしていることに注意してください。

D.15.10 パスワード・バリデータ

パスワード・バリデータはディレクトリ・サーバー・パスワード・ポリシーのコンポーネントで、提案されたパスワードの使用を許可できるかどうかを判断するために使用されます。ディレクトリ・サーバーはカスタム・パスワード・バリデータの開発のために拡張可能なAPIを提供しますが、そのAPIは、次のようないくつかの異なるタイプのパスワード・バリデータに使用されます:

- ユーザーのエントリに含まれる属性の値の中にパスワードの値が存在する場合は、パスワードを拒否するために使用できるバリデータ。

- パスワードの値が許可された文字セットの範囲にある文字を含まない場合は、パスワードを拒否するために使用できるバリデータ。

- パスワードが辞書に存在する言葉である場合は、拒否するために使用できるバリデータ。

- パスワードが長すぎるか短すぎる場合は、拒否するために使用できるバリデータ。

- パスワードが何度も繰り返される文字による文字列を含む場合は、拒否するために使用できるバリデータ。

- パスワードがユーザーの現在のパスワードに酷似している場合は、拒否するために使用できるバリデータ。

- パスワードが十分に一意となる文字を含まない場合は、拒否するために使用できるバリデータ。

D.15.11 永続検索制御

永続検索制御はLDAP制御のタイプで、関連付けられたLDAP検索操作の基準に一致するエントリに対する変更をクライアントに通知するために使用できます。永続検索制御はdraft-ietf-ldapext-psearch (https://opends.dev.java.net/public/standards/draft-ietf-ldapext-psearch.txt)で説明されており、OIDは2.16.840.1.113730.3.4.3です。次のように定義されます:

PersistentSearch ::= SEQUENCE {
changeTypes INTEGER,
changesOnly BOOLEAN,
returnECs BOOLEAN
}

この検索の一部として返される検索結果エントリは、オプションで、エントリが変更した方法を説明するエントリ変更通知制御を含む場合があります。検索でこの制御を使用する例は、「永続検索制御を使用した検索」を参照してください。

D.15.12 PLAIN SASLメカニズム

PLAIN Simple Authentication and Security Layerメカニズムは、ユーザー名およびパスワードを使用して、クライアントがディレクトリ・サーバーへの認証を行う方法を提供します。一般的に、識別名ではなくユーザー名でクライアントがクライアント自体を認証要求できることを除けば、簡易認証とよく似ています。別の認可IDを指定する機能もクライアントに提供します。

簡易認証と同様、PLAIN SASLメカニズムはユーザー・パスワードを保護する形式を提供しないため、Secure Sockets LayerまたはTLS起動拡張操作で提供されるような保護された通信チャネルの場合のみ、この認証方法の使用をお薦めします。

D.15.13 プラグイン

プラグインは、ディレクトリ・サーバーが処理を実行する過程に、カスタム・ロジックを挿入するために使用できるコードの部分です。ディレクトリ・サーバーは、次のような様々なタイプのプラグインを多数サポートします:

- 事前解析プラグイン。サーバーがリクエストの処理を開始する前に、リクエストのコンテンツを変更できるようにします。事前解析プラグインは、すべてのタイプの操作で使用可能です。

- 操作前プラグイン。操作の中心となる処理の前に、サーバーがいくつかのアクションを実行できるようにします。操作前プラグインは、中止操作およびアンバインド操作を除くすべてのタイプの操作で使用可能です。

- 操作後プラグイン。操作の中心となる処理の直後でレスポンスがクライアントに送信される前に、サーバーがいくつかのアクションを実行できるようにします(クライアントへのレスポンスの変更に使用される場合もあります)。操作後プラグインは、すべてのタイプの操作で使用可能です。

- レスポンス後プラグイン。完了した操作のすべての処理の後で、サーバーがいくつかのアクションを実行できるようにします。レスポンス後プラグインは、中止およびアンバインドを除くすべてのタイプの操作で使用可能です。

- 検索結果エントリ・プラグイン。検索操作の一部として送信される検索結果エントリのコンテンツを変更します。

- 検索結果参照プラグイン。検索操作の一部として送信される検索結果参照のコンテンツを変更します。

- 中間レスポンス・プラグイン。クライアントに送信されるLDAP中間レスポンスのコンテンツを変更します。

- 起動プラグイン。サーバーが最初に起動する際にいくつかの処理を実行します。

- 停止プラグイン。サーバーが正常に停止する際にいくつかの処理を実行します。

- 接続後プラグイン。新しいクライアント接続の許可の一部としていくつかの処理を実行します。

- 切断後プラグイン。接続の終了直後にいくつかの処理を実行します。

- LDIFインポート・プラグイン。LDAPデータ変換形式ファイルからインポートされるエントリのコンテンツを変更します。

- LDIFエクスポート・プラグイン。サーバー・バックエンドからエクスポートされるエントリのコンテンツを変更します。

D.15.14 プレゼンス索引

プレゼンス索引は、指定された属性の値を少なくとも1つ保有するエントリの追跡に使用される索引のタイプです。属性ごとにプレゼンス索引キーが1つのみ存在し、そのIDリストには、指定された属性を含むすべてのエントリのエントリIDが含まれます。

D.15.15 プレゼンス検索フィルタ

プレゼンス検索フィルタは、LDAP検索フィルタのタイプで、指定された属性の値を少なくとも1つ保有するエントリの識別に使用できます。LDAPプレゼンス・フィルタの文字列表現は、左カッコに続く属性名、等号、アスタリスクおよび右カッコで構成されます。たとえば、等価フィルタ(aci=*)は、aci属性の値を少なくとも1つ含むエントリと一致します。

D.15.16 特権

ディレクトリ・サーバーには特権サブシステムがあり、ユーザーに権限を付与する機能の定義に使用できます。特権サブシステムは、ユーザーが操作の実行を許可されているかどうかを判断するプロセスで、アクセス制御実装とともに動作します。

ディレクトリ・サーバーで定義される特権には、次のものがあります:

bypass-acl

アクセス制御の評価のバイパスをユーザーに許可

modify-acl

サーバーで定義されるアクセス制御ルールの変更をユーザーに許可

config-read

サーバー構成の読取りアクセス権の保有をユーザーに許可

config-write

サーバー構成の書込みアクセス権の保有をユーザーに許可

server-shutdown

サーバーの停止をユーザーがリクエストすることを許可

server-restart

サーバーのインコア再起動実行のリクエストをユーザーに許可

proxied-auth

異なる認可IDによる操作のリクエストをユーザーに許可

unindexed-search

索引なし検索のリクエストをユーザーに許可

password-reset

その他のユーザーに対するパスワードのリセットをユーザーに許可

update-schema

サーバー・スキーマの更新をユーザーに許可

特権サブシステムの詳細は、「ルート・ユーザーと特権サブシステム」を参照してください。

D.15.17 比例アルゴリズム

クライアントのリクエストをレプリケートされたリモートLDAPサーバーのセットに配布するプロキシ・ロード・バランシング・アルゴリズム。各リモートLDAPサーバーに送信されるリクエストの数は、重み設定により決定されます。

D.15.18 プロトコル・データ・ユニット

プロトコル・データ・ユニット(PDU)は、ネットワーク通信の単一の完全な要素です。LDAPの場合は、PDUはメッセージです。

D.15.19 プロトコルop

プロトコルopは、リクエストまたはレスポンスの核を含むメッセージの要素です。つまり、メッセージのタイプを示します。プロトコルop要素には、次のようないくつかの異なる種類があります:

- 中止操作

- 追加操作

- バインド操作

- 比較操作

- 削除操作

- 拡張操作

- 変更操作

- DN変更操作

- 検索操作

- アンバインド操作

- LDAP中間レスポンス

D.15.20 プロキシ認可制御

プロキシ認可制御は、関連付けられた操作を別のユーザーの認可で実行するリクエストに使用できる制御のタイプです。

2つの異なる形式のプロキシ認可制御があり、いずれも追加操作、比較操作、削除操作、変更操作、DN変更操作または検索操作に追加できるリクエスト制御です。

プロキシ認可v1制御は、初期のバージョンのdraft-weltman-ldapv3-proxyで定義されています。OIDは2.16.840.1.113730.3.4.12で、制御値は次のようにエンコードされます:

proxyAuthValue::= SEQUENCE {
proxyDN LDAPDN
}

プロキシ認可v2制御は、RFC 4370 (http://www.ietf.org/rfc/rfc4370.txt)で定義されています。OIDは2.16.840.1.113730.3.4.18で、値は必要な認可IDに含まれる文字列です。

検索リクエストでこの制御を使用する例は、「プロキシ設定された認可制御を使用した検索」を参照してください。

D.16 Q

D.16.1 保護品質

保護品質(QoP)は、特定のSimple Authentication and Security Layerメカニズム(特にDIGEST-MD5 SASLメカニズムおよびGSSAPI SASLメカニズム)のプロパティで、クライアントとサーバーの間の通信を保護するために使用できます。

次のように、3つの異なるQoPレベルがあります:

auth

関連付けられたSASLメカニズムがクライアント接続の認証にのみ使用されることを示します。クライアントサーバー通信のためのその他の保護は行いません。

auth-int

関連付けられたSASLメカニズムが認証に使用され、完全性保護もクライアントとサーバーの間の通信に提供されることを示します。完全性保護では第3者が通信を解読することを防ぎませんが、検出不可能な方法での介在者による通信の変更を不可能にすることを保証します。

auth-conf

関連付けられたSASLメカニズムが認証に使用され、完全性および機密性の保護もクライアントとサーバーの間の通信に提供されることを示します。第3者が通信を解読できないことを保証します。

現在、ディレクトリ・サーバーではauth保護品質のみをサポートしています。auth-intまたはauth-confのいずれのレベルもサポートしていません。

D.17 R

D.17.1 実在属性専用制御

実在属性専用制御は、サーバーが実在する属性のみを一致するエントリに含めるように要求するために使用できる制御です。つまり、仮想属性は検索結果エントリから除外されます。

実在属性専用制御のリクエスト・オブジェクト識別子は2.16.840.1.113730.3.4.17で、値はありません。

次の検索で、numsubordinates仮想属性がリクエストされ、返されます:

$ ldapsearch -D "cn=directory manager" -j pwd-file -b "ou=people,dc=example,dc=com" \
-s base "objectclass=*" numsubordinates
version: 1
dn: ou=People,dc=example,dc=com
numSubordinates: 50

次の検索で、numsubordinates仮想属性がリクエストされますが、実在属性専用制御が使用されるため、返されません:

$ ldapsearch -D "cn=directory manager" -j pwd-file -J "2.16.840.1.113730.3.4.17" \
-b "ou=people,dc=example,dc=com" -s base "objectclass=*" numsubordinates
version: 1
dn: ou=People,dc=example,dc=com

D.17.2 参照整合性

参照整合性は、エントリの削除や変更の際は常に、エントリへの参照が更新されることを保証するメカニズムです。従来から、参照整合性は主に、識別名構文を持つ属性(特にmemberおよびuniqueMemberなどのグループ・メンバーシップ属性)が削除操作およびDN変更操作のイベントで正しく維持されることを保証するために使用されます。削除操作の場合は、ターゲット・エントリの参照は削除されます。DN変更操作の場合は、ターゲット・エントリに対する参照は操作に応じて名前が変更されます。

ディレクトリ・サーバーは、dsconfigコマンドを使用してインストールできる、構成可能な参照整合性プラグインを提供します。

D.17.3 リフェラル

リフェラルは、操作を処理できる別の場所への参照を提供します。リフェラルは、結果コードに10、および適切なLDAP URLのセットを保有するLDAP結果オブジェクトに含めることができます。検索結果参照でクライアントにも返すことができます。

D.17.4 相対識別名

相対識別名すなわちRDNは、識別名内の単一のコンポーネントです。1つ以上の名前/値ペアで構成され、名前/値ペアの名前と値は等号で区切られます(たとえば、RDN uid=annの場合は、名前はuidで値はann)。複数の名前/値ペアが存在する場合は、プラス記号で区切られます(たとえば、RDN cn=Jon Doe+employeeNumber=12345の場合は、名前/値ペアはcn=John DoeおよびemployeeNumber=12345)。実際には、複数の名前/値ペアを含むRDN(複数値RDNと呼ばれる)はまれですが、エントリに一意の属性がない場合、または役立つ識別情報がエントリのDNに含まれていることを確認する場合に役立ちます。

DNが複数のRDNコンポーネントから構成されている場合も、通常、一番左のコンポーネントがエントリのRDNとして参照されます。たとえば、DN uid=john.doe,ou=People,dc=example,dc=comでは、RDNはuid=john.doeです。エントリのRDNで指定された属性値は、そのエントリに含まれる必要があるため、エントリuid=john.doe,ou=People,dc=example,dc=comは、uidの値john.doeを保有します。

D.17.5 レプリカ

レプリカは、レプリケーションに参加するディレクトリ・サーバー・インスタンスです。

D.17.6 レプリケーション

レプリケーションはデータ同期の形式で、ディレクトリ環境の変更がサーバーの各インスタンスに反映されることを保証するために使用されます。つまり、1つのディレクトリ・サーバー・インスタンスで実行される変更は常に、同じ変更がその他の各インスタンスでも実行されます。

D.17.7 レプリケーション修復制御

レプリケーション修復制御は、トポロジ内の単一のサーバーで、レプリケーションの非一貫性を解決するために使用できる制御です。

レプリケーション修復制御のリクエスト・オブジェクト識別子は1.3.6.1.4.1.26027.1.5.2で、値はありません。

レプリケーション修復制御を使用する例は、「レプリケーションの非一貫性の検出および解決」を参照してください。

D.17.8 request for comments

request for comments (RFC)は、Internet Draftから昇格したIETF (http://www.ietf.org/)の仕様で、Draftと比較して十分安定していると考えられます。

D.17.9 復元

復元操作は、ディレクトリ・サーバー・バックエンドのコンテンツを以前のバックアップから取得した情報で置換するメカニズムを提供します。障害時リカバリ・メカニズムとして機能し、レプリカのバイナリ・コピーの初期化にも使用できる場合があります。

D.17.10 結果

「LDAP結果」を参照してください。

D.17.11 結果コード

結果コードは、操作の結果についての汎用情報を提供する整数値です。定義された結果コードには次のものがあります:

値

名前

説明

0

成功

関連付けられた操作が正常に完了したことを示すために使用されます。

1

操作エラー

関連付けられたリクエストと進行中の別の操作の順序が間違っていたことを示すために使用されます(マルチステージSASLバインドの途中の非バインド・リクエストなど)。

2

プロトコル・エラー

クライアントがサーバーに送信したデータが、有効なLDAPリクエストを構成していなかったことを示すために使用されます。

3

時間制限を超過しました

関連付けられたリクエストの処理を、時間がかかりすぎて完了できないために終了したことを示すために使用されます。検索操作では、時間制限に達した際に一致するエントリの一部が返されている場合もあります。

4

サイズ制限を超過しました

検索操作に含まれる基準に一致するエントリが、サイズ制限の構成により返すことのできるエントリよりも多く存在することを示すために使用されます。

5

Falseを比較

比較操作は正常に終了しましたが、指定された属性値アサーションはターゲット・エントリと一致しなかったことを示すために使用されます。

6

Trueを比較

比較操作は正常に終了し、指定された属性値アサーションはターゲット・エントリと一致したことを示すために使用されます。

7

認証方法がサポートされていません

ディレクトリ・サーバーはリクエストされた認証方法をサポートしていないことを示すために使用されます。

8

強い認証が必要です

ディレクトリ・サーバーはクライアントに強い認証メカニズムを使用する要求をしていることを示すために使用されます。

10

リフェラル

リクエストされた操作はターゲット・サーバーでは処理できませんでしたが、別の場所で試行する可能性があることを示すために使用されます。

11

管理上の制限を超過しました

リクエストされた操作の処理は、管理上の制限に達したため完了できなかったことを示すために使用されます。検索操作では、管理上の制限に達した際に一致するエントリの一部が返されている場合もあります。

12

クリティカルな拡張機能を使用できません

リクエストがサーバーで処理できないクリティカルな制御を含んでいたことを示すために使用されます。

13

機密性が必要です

リクエストされた操作は、クライアントとサーバーとの間に保護された通信チャネルを必要とすることを示すために使用されます。

14

SASLバインドが進行中です

SASLバインド操作が複数のステージを要求し、この結果コードを含むレスポンスは中間ステージの1つであることを示すために使用されます。

16

そのような属性はありません

関連付けられたリクエストは、指定されたエントリに存在しない属性または属性値をターゲット設定したことを示すために使用されます。

17

未定義の属性タイプ

関連付けられたリクエストは、サーバー・スキーマで定義されていない属性タイプを含んでいたことを示すために使用されます。

18

不正な照合

関連付けられた検索リクエストに含まれたフィルタに、適切な一致ルールで定義されていない属性タイプをターゲットとするコンポーネントが存在したことを示すために使用されます。

19

制約違反

リクエストされた操作は、サーバーで定義された制約に違反したため(一意の属性の値を複製したなど)、完了できなかったことを示すために使用されます。

20

属性または値が存在します

エントリにすでに存在するエントリの属性値の作成、または単一値の属性に対する追加の値を作成する操作が試行されたことを示すために使用されます。

21

無効な属性構文

リクエストされた操作により、関連付けられた属性タイプの構文に違反した値の指定が試行されたことを示すために使用されます。

32

該当するオブジェクトがありません

リクエストされた操作は、サーバーに存在しないエントリをターゲット設定したことを示すために使用されます。

33

エイリアスの問題

操作は別名エントリをターゲット設定し、その操作は別名エントリに対して許可されていないことを示すために使用されます。

34

無効なDN構文

リクエストされた操作は、不正な形式のエントリDNを含んでいたことを示すために使用されます。

35

リーフ

リクエストされた操作はリーフ・エントリをターゲット設定しましたが、その操作はリーフでないエントリを要求することを示すために使用されます。

36

エイリアス間接参照の問題

関連付けられた検索操作が、適切に間接参照できない別名を検出したことを示すために使用されます。

48

不正な認証

クライアントが、ターゲット・ユーザーに対して適切でない方法でバインドを試みたことを示すために使用されます(ユーザーは簡易認証を試みたがパスワードを保有していない場合など)。

49

無効な資格証明

クライアントが無効な資格証明を使用して認証を試行したことを示すために使用されます(ターゲットDNまたはパスワードが不正であった場合など)。

50

不十分なアクセス権限

クライアントがリクエストされた操作の実行を許可されなかったことを示すために使用されます。

51

ビジー

サーバーがビジーのため、リクエストされた操作を処理できないことを示すために使用されます。

52

使用不可

サーバーは操作の処理に使用できないことを示すために使用されます。

53

実行要求を拒否

なんらかの理由により、リクエストされた操作の実行をサーバーが拒否していることを示すために使用されます。

54

ループを検出

なんらかのタイプのループ(チェーン・ループまたは別名ループなど)をサーバーが検出したことを示すために使用されます。

60

ソート制御がありません

サーバー側ソート制御を含まない仮想一覧表示制御を含む検索操作を、クライアントがリクエストしたことを示すために使用されます。

61

オフセット範囲エラー

無効なオフセットを指定した仮想一覧表示制御をリクエストに含んでいたことを示すために使用されます(結果セットの最後以外の場所など)。

64

ネーミング違反

ネーミングの制約に違反したDNを持つエントリの作成が、操作により試行されたことを示すために使用されます(たとえば、関連付けられた名前書式により許可されていないRDN属性の使用など)。

65

オブジェクト・クラス違反

エントリに含まれる属性のセットが関連付けられたオブジェクト・クラス定義に違反する、エントリの作成または変更が、操作により試行されたことを示すために使用されます(許可されていない属性の追加または必要な属性の欠落など)。

66

非リーフでは許可されない

関連付けられた操作はリーフでないエントリに対して許可されなかったことを示すために使用されます(1つ以上の下位エントリを保有するエントリの削除の試行など)。

67

RDNでは許可されない

関連付けられた操作はエントリのRDN属性に対して許可されていないことを示すために使用されます。

68

エントリはすでに存在します

追加またはDN変更の操作が、サーバーにすでに存在するDNを持つエントリで実行されたことを示すために使用されます。

69

オブジェクト・クラスの変更は禁止されています

リクエストされた操作により、許可されていない方法でエントリの構造オブジェクト・クラスの変更が試行されたことを示すために使用されます。

71

複数のDSAに影響があります

リクエストされた操作は、複数のサーバーに影響が及んだ可能性があることを示すために使用されます(たとえば、DN変更操作はチェーン・バックエンドを介してあるサーバーから別のサーバーにエントリを移動させる場合があります)。

76

仮想一覧表示エラー

仮想一覧表示リクエストの処理中に問題が発生したため、関連付けられた検索操作は正常に完了できなかったことを示すために使用されます。

80

その他

定義された結果コードでは適切に分類されないなんらかの理由により操作が失敗したことを示します。

81

サーバー停止

確立された接続が使用できないことをクライアントが検出したことを示すために使用される、クライアント側の結果コードです。

82

ローカル・エラー

なんらかのクライアント側の問題が発生し、関連付けられた処理を正常に完了できないことを示すために使用される、クライアント側の結果コードです。

83

符号化エラー

サーバーに送信するリクエストのエンコードを試行中に、エラーが発生したことを示すために使用される、クライアント側の結果コードです。

84

デコード・エラー

サーバーから受信したレスポンスのデコードを試行中に、エラーが発生したことを示すために使用される、クライアント側の結果コードです。

85

タイムアウト

許可された時間内にクライアントがレスポンスを受信しなかったことを示すために使用される、クライアント側の結果コードです。

86

認証タイプが不明です

リクエストされた認証方法をクライアントがサポートしていないことを示すために使用される、クライアント側の結果コードです。

87

フィルタ・エラー

指定されたフィルタ文字列を有効なフィルタとして解析できなかったことを示すために使用される、クライアント側の結果コードです。

88

ユーザーにより取り消されました

クライアントによりリクエストが取り消されたことを示すために使用される、クライアント側の結果コードです。

89

パラメータ・エラー

リクエスト要素として指定されたパラメータに問題があったことを示すために使用される、クライアント側の結果コードです。

90

メモリー不足

リクエストされた操作の処理を試行中(検索結果エントリのキューイング中など)に、クライアントのメモリーが不足したことを示すために使用される、クライアント側の結果コードです。

91

接続エラー

クライアントがターゲット・サーバーとの接続を確立できなかったことを示すために使用される、クライアント側の結果コードです。

92

サポートされていません

リクエストされた操作はクライアントにサポートされていないことを示すために使用される、クライアント側の結果コードです。

93

制御が見つかりません

レスポンスに予想された制御が含まれていなかったことを示すために使用される、クライアント側の結果コードです。

94

結果は返されませんでした

検索リクエストに対して少なくとも1つの結果が返されることを予想したが、サーバーから結果が返されなかったことを示すために使用される、クライアント側の結果コードです。

95

結果をさらに返します

すでに取得された結果よりも、返されるべき多くの結果が存在することを示すために使用される、クライアント側の結果コードです。

96

クライアント・ループ

クライアントがリフェラル・ループを検出したことを示すために使用される、クライアント側の結果コードです。

97

リフェラル制限を超過しました

リクエスト処理の進行中に、クライアントが受信したリフェラルが多すぎることを示すために使用される、クライアント側の結果コードです。

100

無効なレスポンス

関連付けられた操作に対して受信した結果が無効であることを示すために使用される、クライアント側の結果コードです。

101

あいまいなレスポンス

サーバーから受信した結果があいまいであった(関連付けられた操作に対して受信したレスポンスが複数存在したなど)ことを示すために使用される、クライアント側の結果コードです。

112

TLSはサポートされていません

サーバーはTLS起動拡張操作をサポートしていないことを示すために使用されます。

113

中間レスポンス

結果コードは、リクエスト処理の進行中にサーバーにより送信された中間レスポンス・メッセージで使用されます。

114

不明なタイプ

無効または不明なプロトコルopタイプのリクエストをサーバーが受信したことを示すために使用されます。

118

取り消されました

クライアントのリクエストに応じてサーバーによりリクエストに対する処理が取り消されたことを示すために使用されます。

119

そのような操作はありません

サーバーに対して不明なリクエスト(たとえば、すでに処理が完了しているため)の取消しをクライアントが試行したことを示すために使用されます。

120

遅すぎます

以降の取消しができなくなった時点の後で、すでに処理されたリクエストの取消しをクライアントが試行したことを示すために使用されます。

121

取り消せません

取消しできない操作(バインド、アンバインド、中止、取消しまたはTLS起動の各リクエストなど)の取消しをクライアントが試行したことを示すために使用されます。

122

アサーションに失敗しました

ターゲット・エントリと一致しないアサーション・フィルタを持つLDAPアサーション制御をリクエストが含んでいたため、関連付けられた操作が処理されなかったことを示すために使用されます。

123

認可が拒否されました

リクエストにプロキシ認可制御を含んでいたがクライアントがその制御の使用を許可されなかったため、関連付けられた操作が処理されなかったことを示すために使用されます。

D.17.12 ルートDN

ルートDN(すなわちルート・ユーザー)はディレクトリ・サーバーに存在するアカウントのタイプで、UNIXシステムのルート・ユーザーのように、通常、サーバー内のすべてのデータへの完全アクセス権を付与されます。ルート・ユーザーはデフォルトでアクセス制御の評価をバイパス可能で、サーバー構成への完全アクセス権を保有し、大部分のタイプの操作を実行します。

ディレクトリ・サーバーはルート・ユーザーに関して、次の2つの重要な点で他の大部分のサーバーとは異なります:

- ディレクトリ・サーバーでは複数のルート・ユーザーを構成できます。すべての管理者により共有される単一のアカウントではなく、その他のアカウントから独立している個別のルート・アカウントを各管理者が保有できるように各ルート・ユーザーは異なる資格証明のセットを保有できるため、利点になります。

- ルート・ユーザーに付与されるすべての権限は、特権を介して割り当てられます。特権サブシステムを使用して、通常、ルート・ユーザーのみが使用可能な一部またはすべての機能を持つroot以外のユーザーを作成できます。必要な場合はルート・ユーザーから特権を取り去ることもできます。

ルート・ユーザーおよび特権サブシステムの詳細は、「ルート・ユーザーと特権サブシステム」ドキュメントを参照してください。

D.17.13 ルートDSE

ルートDSEは特別なエントリで、サーバーのコンテンツおよび機能の情報を提供します。識別名は相対識別名コンポーネントを持たない長さ0の文字列で、null DNとも呼ばれます。

ルートDSEに含まれる属性には次のものがあります:

namingContexts

サーバーのネーミング・コンテキストをリスト

supportedAuthPasswordSchemes

認証パスワード構文を使用してサポートされるパスワード記憶スキームの オブジェクト識別子をリスト

supportedControl

サーバーでサポートされている制御のOIDをリスト

supportedExtension

サーバーでサポートされている拡張のOIDをリスト

supportedFeatures

サーバーでサポートされている機能のOIDをリスト

supportedSASLMechanisms

サーバーでサポートされているSimple Authentication and Security LayerメカニズムのOIDをリスト

vendorName

サーバーのベンダー名を提供

vendorVersion

製品バージョンの文字列を提供

ldapsearchコマンドを使用してルートDSEを読み取る方法の例を次に示します。この例では、ファイル/tmp/pwd.txtにDirectory Managerのパスワードが含まれています。サーバーはポート1389でLDAPリクエストをリスニングします。

$ ldapsearch -D "cn=Directory Manager" -j /tmp/pwd.txt -p 1389 -b "" \
-s base "(objectclass=*)" +
dn:
supportedLDAPVersion: 2
supportedLDAPVersion: 3
supportedExtension: 1.3.6.1.4.1.4203.1.11.3
supportedExtension: 1.3.6.1.4.1.4203.1.11.1
supportedExtension: 1.3.6.1.4.1.26027.1.6.1
supportedExtension: 1.3.6.1.4.1.26027.1.6.3
supportedExtension: 1.3.6.1.4.1.26027.1.6.2
supportedExtension: 1.3.6.1.1.8
supportedExtension: 1.3.6.1.4.1.1466.20037
vendorName: Oracle Corporation
entryDN:
ds-private-naming-contexts: cn=admin data
ds-private-naming-contexts: cn=ads-truststore
ds-private-naming-contexts: cn=backups
ds-private-naming-contexts: cn=config
ds-private-naming-contexts: cn=monitor
ds-private-naming-contexts: cn=schema
ds-private-naming-contexts: cn=tasks
supportedControl: 1.2.826.0.1.3344810.2.3
supportedControl: 1.2.840.113556.1.4.319
supportedControl: 1.2.840.113556.1.4.473
supportedControl: 1.2.840.113556.1.4.805
supportedControl: 1.3.6.1.1.12
supportedControl: 1.3.6.1.1.13.1
supportedControl: 1.3.6.1.1.13.2
supportedControl: 1.3.6.1.4.1.26027.1.5.2
supportedControl: 1.3.6.1.4.1.42.2.27.8.5.1
supportedControl: 1.3.6.1.4.1.42.2.27.9.5.2
supportedControl: 1.3.6.1.4.1.42.2.27.9.5.8
supportedControl: 1.3.6.1.4.1.4203.1.10.2
supportedControl: 1.3.6.1.4.1.7628.5.101.1
supportedControl: 2.16.840.1.113730.3.4.12
supportedControl: 2.16.840.1.113730.3.4.16
supportedControl: 2.16.840.1.113730.3.4.17
supportedControl: 2.16.840.1.113730.3.4.18
supportedControl: 2.16.840.1.113730.3.4.19
supportedControl: 2.16.840.1.113730.3.4.2
supportedControl: 2.16.840.1.113730.3.4.3
supportedControl: 2.16.840.1.113730.3.4.9
supportedSASLMechanisms: PLAIN
supportedSASLMechanisms: EXTERNAL
supportedSASLMechanisms: CRAM-MD5
supportedSASLMechanisms: DIGEST-MD5
supportedFeatures: 1.3.6.1.1.14
supportedFeatures: 1.3.6.1.4.1.4203.1.5.1
supportedFeatures: 1.3.6.1.4.1.4203.1.5.2
supportedFeatures: 1.3.6.1.4.1.4203.1.5.3
subschemaSubentry: cn=schema
hasSubordinates: true
entryUUID: d41d8cd9-8f00-3204-a980-0998ecf8427e
numSubordinates: 1
namingContexts: dc=example,dc=com
vendorVersion: Oracle Unified Directory 11.1.1.5.0
supportedAuthPasswordSchemes: MD5
supportedAuthPasswordSchemes: SHA1
supportedAuthPasswordSchemes: SHA256
supportedAuthPasswordSchemes: SHA384
supportedAuthPasswordSchemes: SHA512

ルートDSEエントリの検索方法の詳細は、「拡張検索機能の使用方法」を参照してください。

D.17.14 ルート

プロキシ・モードで、ロード・バランシング・アルゴリズムを使用する際に、リクエストが送信されるリモートLDAPサーバーへのパス。

D.18 S

D.18.1 salt

saltはランダム・データの集合で、クリアテキスト・データ(パスワードであることが多い)と組み合せて、クリアテキストをエンコードする方法を変更するために使用できます。特に、saltはエンコード処理に不規則性を導入して、辞書攻撃を防ぐために使用されます。通常、saltはクリアテキスト・パスワードに追加され、そのパスワードは必要とするメッセージ・ダイジェスト・アルゴリズムを使用してエンコードされます。クリアテキストsaltはメッセージ・ダイジェストに追加され、最終的な値はbase64エンコーディングでエンコードされます。このようにしてsaltの内容の判断が可能になり、ユーザーの指定したパスワードが正しいかどうかの判断に使用できます。

UNIX暗号化アルゴリズムは比較的弱い12ビットのsaltを使用しており、それは、値をエンコードする方法が4096通りのみであることを意味します。これは比較的低い数字で、このためユーザー・パスワードの解読に使用する広い範囲の値をすべてエンコードした辞書を構築できます。その他のディレクトリ・サーバーのパスワード記憶スキームでは64ビットのsaltを使用しており、1つの値を18446744073709551616通りにエンコードできます。

D.18.2 飽和アルゴリズム

クライアントのリクエストを優先リモートLDAPサーバーにルーティングするプロキシ・ロード・バランシング・アルゴリズム。メイン・リモートLDAPサーバーが飽和しきい値に達した場合は、リクエストはセカンダリ・リモートLDAPサーバーにルーティングされます。

D.18.3 飽和アラート

リモートLDAPサーバーがオーバーロードであることを示すために、管理者に通知を送信する際の制限値。通常、飽和アラートは飽和しきい値よりも高く設定されています。

D.18.4 飽和しきい値

飽和しきい値は、データ・ソースがオーバーロードとみなされ、これ以上の着信リクエストを適切な方法で処理できないという制限値です。飽和しきい値は、プロキシ飽和アルゴリズムの一部として使用されます。

D.18.5 スキーマ

ディレクトリ・サーバーのスキーマは、サーバーが保持できる情報の種類を制御するルールのセットを定義します。ディレクトリ・スキーマには、次のように様々な要素が多数あります:

属性構文

属性で保管できる情報の種類についての情報を提供します。

一致ルール

属性値との比較方法の情報を提供します。

一致ルールの使用

特定の一致ルールとともに使用できる属性タイプを示します。

属性タイプ

指定された属性の参照に使用できるオブジェクト識別子および名前のセットを定義し、その属性を構文および一致ルールのセットと関連付けます。

オブジェクト・クラス

名前付きの属性の集合を定義し、必須およびオプションの属性のセットに分類します。

名前書式

エントリの相対識別名に含まれる属性のセットに対するルールを定義します。

DITコンテンツ・ルール

エントリとともに使用できるオブジェクト・クラスおよび属性についての追加の制約を定義します。

DIT構造ルール

指定されたエントリが保有できる下位エントリの種類を制御するルールを定義します。

属性はディレクトリに情報を保管するための要素で、スキーマは、エントリ内で使用できる属性のルール、これらの属性が保有できる値の種類、クライアントがこれらの値と相互に作用する方法を定義します。

クライアントは、適切なサブスキーマ・サブエントリを取得して、サーバーがサポートするスキーマ要素を確認できます。

D.18.6 スキーマ検査

スキーマ検査は、エントリがサーバー・スキーマで定義された制約に準拠していることを確認する処理です。内容は次のとおりです:

- エントリに1つの構造オブジェクト・クラスが含まれることを確認します。

- エントリの構造クラスの名前書式が存在する場合は、相対識別名属性がその名前書式に準拠していることを確認します。

- エントリの構造クラスのDITコンテンツ・ルールが存在する場合は、すべての補助オブジェクト・クラスが定義されていることを確認します。

- エントリに含まれるすべてのオブジェクト・クラスがスキーマで定義されていることを確認します。

- エントリに含まれるすべての属性がスキーマで定義されており、オブジェクト・クラスまたはDITコンテンツ・ルール、あるいはその両方により許可されていることを確認します。

- エントリのオブジェクト・クラスまたはDITコンテンツ・ルール、あるいはその両方により要求されたすべての属性が存在することを確認します。

- エントリに含まれるすべての単一値属性が値を1つのみ保有していることを確認します。

- ディレクトリ情報ツリー内のエントリの位置が、DIT構造ルールの定義に準拠していることを確認します。

D.18.7 検索属性

検索操作の検索属性要素は、検索結果エントリに含まれる属性を表す方法を指定します。通常、検索属性のセットは、返す属性の0個以上の属性説明のリストです。値が指定されている場合は、すべてのユーザー属性が返され、操作属性は返されません。

特定の属性説明に加えて、多くの特別な値に次のように様々な意味を持たせることができます:

- 文字列1.1は一致するエントリに含まれる属性が存在しないことを示します。

- 文字列*(アスタリスク)は、一致するエントリにすべてのユーザー属性が含まれることを示します。1つ以上の操作属性に加えて、すべてのユーザー属性をサーバーが返す場合に必要です。

- 文字列+(プラス記号)は、一致するエントリに操作属性が含まれることを示します。

- オブジェクト・クラス名は、接頭辞として文字@を付けた形式で指定できます。オブジェクト・クラスにより参照されるすべての属性は一致するエントリに含まれることを示します。

D.18.8 検索ベースDN

検索ベースDNは検索操作の要素で、検索範囲とともに動作し、検索操作の処理対象として考慮するエントリのサブツリーを定義します。検索ベースDNのエントリまたはその下のエントリ、およびその範囲内のエントリのみが、LDAP検索フィルタと一致する候補とみなされます。

D.18.9 検索フィルタ

「LDAP検索フィルタ」を参照してください。

D.18.10 検索操作

LDAP検索操作は、指定された基準のセットに一致するディレクトリ・サーバーのエントリの識別に使用できます。0個以上のエントリ、また0個以上のリフェラルを返す場合があります。

検索リクエスト・プロトコルopは次のように定義されます:

SearchRequest ::= [APPLICATION 3] SEQUENCE {
baseObject      LDAPDN,
scope           ENUMERATED {
baseObject              (0),
singleLevel             (1),
wholeSubtree            (2),
...  },
derefAliases    ENUMERATED {
neverDerefAliases       (0),
derefInSearching        (1),
derefFindingBaseObj     (2),
derefAlways             (3) },
sizeLimit       INTEGER (0 ..  maxInt),
timeLimit       INTEGER (0 ..  maxInt),
typesOnly       BOOLEAN,
filter          Filter,
attributes      AttributeSelection }

次のような検索リクエストの要素があります:

- 検索ベースDN。検索を実行するディレクトリ情報ツリー内の場所を指定します。

- 検索範囲。検索処理の対象として考慮する、ベースDNのエントリまたはその下のエントリの範囲を指定します。

- 処理中に別名を検出した場合に使用する間接参照ポリシー。

- サイズ制限。検索から返されるエントリの最大数を指定します(または、エントリの最大数を指定しない場合は0)。

- 時間制限。サーバーが検索処理に費やす時間の最大の長さを秒単位で指定します(または、エントリの最大数を指定しない場合はゼロ)。

- typesOnlyフラグ。返されたエントリが属性タイプのみまたは属性タイプと属性値の両方を含むかどうかを示します。

- LDAP検索フィルタ。一致するエントリの識別に使用する基準を指定します。

- 検索属性。一致するエントリに含まれる属性を示すか、またはすべてのユーザー属性が返されることを示す空のリストです。

検索リクエストに対するレスポンスで返すことのできる次の3つの結果要素のタイプがあります。0個以上の検索結果エントリ、0個以上の検索結果参照および1つの検索結果終了メッセージです。エントリおよび参照は任意の順序で返され(検索エントリと参照がばらばらに挿入された状態で)、検索結果終了メッセージは最後に発生してこれ以上の結果は存在しないことを示します。

検索結果エントリ・プロトコルopは次のように定義されます:

SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
objectName      LDAPDN,
attributes      PartialAttributeList }

PartialAttributeList ::= SEQUENCE OF
partialAttribute PartialAttribute

各検索結果エントリには、検索属性リストで定義されたように、エントリのDNおよび0個以上の属性が含まれます(リクエストのtypesOnly要素がtrueの場合は、値なしで属性タイプ名のみが含まれる場合があります)。

検索結果参照プロトコルopは次のように定義されます:

SearchResultReference ::= [APPLICATION 19] SEQUENCE
SIZE (1..MAX) OF uri URI

各検索結果参照には、クライアントが別の一致するエントリを検索する別の場所を指定する1つ以上のLDAP URLが含まれます。

検索結果終了メッセージは、次のように定義されるLDAP結果です:

SearchResultDone ::= [APPLICATION 5] LDAPResult

D.18.11 検索結果終了

検索結果終了メッセージは、検索操作の一部として提供されるメッセージで、検索が完了し、これ以上の検索結果エントリまたは検索結果参照メッセージは存在しないことを示します。

D.18.12 検索結果エントリ

検索結果エントリは、検索操作の一部として返されるエントリです。少なくともエントリの識別名を含み、0個以上の属性を含めることができます。属性には、(検索リクエストのtypesOnlyフラグの値に基づいて)属性タイプ名のみ、または属性のタイプおよび値の両方を含めることができます。返された属性は、クライアント・リクエストの検索属性に基づいていますが、サーバーのアクセス制御構成に基づいて削減できます。

D.18.13 検索結果参照

検索結果参照は、検索操作の一部としてクライアントに情報を返すメカニズムを提供し、その情報は、クライアントが別の一致するエントリを見つけるための検索を実行する、別の場所を示します。別の場所は、LDAP URLの形式で指定されます。

D.18.14 検索範囲

LDAP検索範囲は、検索操作で一致する可能性を検討する検索ベースDNのエントリまたはその下のエントリのセットを示します。

検索範囲の値には次の4つの定義があります:

baseObject

検索操作は、検索ベースDNとして指定されたエントリに対してのみ実行されることを示します。その下には検討されるエントリはありません。

DITのシナリオを考えます。このDITは、検索ベースDNにdc=example,dc=comを持つbaseObject範囲を保有しています。

singleLevel

検索操作は、検索ベースDNとして指定されたエントリの直下のエントリに対してのみ実行されることを示します。ベース・エントリ自体または検索ベース・エントリの直下より下位のエントリは含まれません。

wholeSubtree

検索操作は、検索ベースとして指定されたエントリ、および深さにかかわらず検索ベースの下位すべての指定されたエントリに対して実行されることを示します。

subordinateSubtree

検索操作は、深さにかかわらず検索ベースのすべての下位エントリに対して実行されますが、検索ベース・エントリ自体は含まれません。

D.18.15 セキュア・ハッシュ・アルゴリズム

セキュア・ハッシュ・アルゴリズム(SHA)は、一方向のメッセージ・ダイジェスト・アルゴリズムです。セキュア・ハッシュ・アルゴリズムには、実際には次の2つの異なる形式があります:

- SHA-1はRFC 3174 (http://www.ietf.org/rfc/rfc3174.txt)で定義されており、160ビットのダイジェストを生成します。

- SHA-2はRFC 4634 (http://www.ietf.org/rfc/rfc4634.txt)で定義されており、256ビット、384ビットまたは512ビットのダイジェストの生成に使用できます。

セキュア・ハッシュ・アルゴリズムのすべての形式はMD5アルゴリズムよりも厳格であるとみなされます。最近の進歩により、SHA-1バリアントの脆弱性が示される場合がありますが、ディレクトリ・サーバーでの使用方法が危険であることを示す証拠はなく、SHA-2エンコーディングの問題もありません。

D.18.16 Secure Sockets Layer

Secure Sockets Layer (SSL)はセキュリティ層でネットワーク通信をラップするメカニズムで、クライアントとサーバーの間の通信を暗号化するために使用できます。クライアントとサーバーとの間で通信が変更されないことを保証する、整合性メカニズムも提供します。暗号化は、証明書を使用した暗号化に基づいています。

SSLは元々、Netscape Communications社が開発したプロプライエタリ・プロトコルです。その後標準化されましたが、名前はTransport Security Layerに変更されました。しかし、SSLはこの機能を指すために現在でも一般的に使用される用語で、StartTLS拡張操作との混同を避けるためにディレクトリ・サーバーで使用される用語です。

D.18.17 サーバー側ソート制御

サーバー側ソート制御は、検索操作に追加して、結果がクライアントに返される前に結果がソートされるようにリクエストする制御のタイプです。RFC 2891 (http://www.ietf.org/rfc/rfc2891.txt)で定義されています。

リクエスト制御のオブジェクト識別子は1.2.840.113556.1.4.473で、値は次のようにエンコードされます:

SortKeyList ::= SEQUENCE OF SEQUENCE {
attributeType   AttributeDescription,
orderingRule    [0] MatchingRuleId OPTIONAL,
reverseOrder    [1] BOOLEAN DEFAULT FALSE }

検索リクエストでこの制御を使用する例は、「サーバー側ソート制御を使用した検索」を参照してください。

レスポンス制御のOIDは1.2.840.113556.1.4.474で、値は次のようにエンコードされます:

SortResult ::= SEQUENCE {
sortResult  ENUMERATED {
success                   (0), -- results are sorted
operationsError           (1), -- server internal failure
timeLimitExceeded         (3), -- timelimit reached before
-- sorting was completed
strongAuthRequired        (8), -- refused to return sorted
-- results via insecure
-- protocol
adminLimitExceeded       (11), -- too many matching entries
-- for the server to sort
noSuchAttribute          (16), -- unrecognized attribute
-- type in sort key
inappropriateMatching    (18), -- unrecognized or
-- inappropriate matching
-- rule in sort key
insufficientAccessRights (50), -- refused to return sorted
-- results to this client
busy                     (51), -- too busy to process
unwillingToPerform       (53), -- unable to sort
other                    (80)
},
attributeType [0] AttributeDescription OPTIONAL }

D.18.18 簡易認証

簡易認証は、識別名およびパスワードを使用するディレクトリ・サーバーに対する認証の処理です。バインド操作を使用して実行されます(簡易認証を使用してバインドが実行された場合は、多くの場合、簡易バインドと呼ばれます)。クライアントは指定されたDNを使用してクライアント自体をサーバーに認証要求し、クライアントが誰だと主張しているのかを検証するためにパスワードが使用されます。

簡易認証ではパスワードを保護する方法がないことに注意してください。そのため、通常、Secure Sockets LayerまたはTLS起動拡張操作で提供されるような保護された通信チャネルで使用される場合のみ簡易認証をお薦めします。

D.18.19 Simple Authentication and Security Layer

Simple Authentication and Security Layer (SASL)は、主にユーザー認証のために使用される拡張フレームワークですが、基礎となる通信チャネルの保護に使用される場合もあります。SASLの中核機能はRFC 4422 (http://www.ietf.org/rfc/rfc4422.txt)で説明されていますが、多くのSASLメカニズムが別の仕様で説明されています。

ディレクトリ・サーバーでサポートされているSASLメカニズムには、次のものがあります:

ANONYMOUS SASLメカニズム

このメカニズムは実際にはサーバーに対してユーザーを認証しませんが、以前の認証セッションの破棄に使用できます。

CRAM-MD5 SASLメカニズム

このメカニズムは、パスワード自体を公開しない方法でパスワードを使用して、ユーザーがサーバーへの認証を行う方法を提供します。DIGEST-MD5 SASLメカニズムに似ていますが、より脆弱で、接続の完全性または機密性を保証する方法がありません。

DIGEST-MD5 SASLメカニズム

このメカニズムは、パスワード自体を公開しない方法でパスワードを使用して、ユーザーがサーバーへの認証を行う方法を提供します。CRAM-MD5 SASLメカニズムに似ていますが、より厳格で、接続の完全性または機密性、あるいはその両方を保証する方法も提供します。

EXTERNAL SASLメカニズム

このメカニズムは、実行されるLDAP通信の外で入手できる情報(Secure Sockets LayerまたはTLS起動拡張操作のネゴシエーションを実行する際にクライアントが提示した証明書など)を使用して、ユーザーがサーバーへの認証を行う方法を提供します。

GSSAPI SASLメカニズム

このメカニズムは、Kerberos V5セッションを使用してユーザーがサーバーへの認証を行う方法を提供します。接続の完全性または機密性、あるいはその両方を保証するために使用できるメカニズムも提供します。

PLAIN SASLメカニズム

このメカニズムは、ユーザー名およびパスワードを使用し、ユーザーがサーバーへの認証を行う方法を提供します。簡易認証で提供される保護とよく似ていますが、識別名ではなくユーザー名でユーザーが自分自身を認証要求できるという点でより便利です。

D.18.20 単純なページングの結果制御

単純なページングの結果制御は、検索操作に追加して、結果のサブセットのみを返すことを示す制御のタイプです。検索結果を一度に1ページずつ繰り返し取り出すために使用できます。結果がソートされている必要はなく、検索結果を順に取り出すためにのみ使用できることを除けば、仮想一覧表示制御に似ています。

単純なページングの結果制御はRFC 2696 (http://www.ietf.org/rfc/rfc2696.txt)で定義されています。同じ制御が検索リクエストおよび検索結果終了メッセージの両方で使用されます。オブジェクト識別子は1.2.840.113556.1.4.319で、値は次のようにエンコードされます:

realSearchControlValue ::= SEQUENCE {
size            INTEGER (0..maxInt),
-- requested page size from client
-- result set size estimate from server
cookie          OCTET STRING
}

検索リクエストでこの制御を使用する例は、「単純なページングの結果制御を使用した検索」を参照してください。

D.18.21 サイズ制限

サーバーのサイズ制限は構成オプションで、単一の検索操作から返すことのできるエントリの最大数を制御します。サーバー全体に関わる設定で、ユーザーのエントリのds-rlim-size-limit操作属性でユーザーごとの構成によりオーバーライドできます。

サーバーのサイズ制限(またはユーザーごとの値)は、検索リクエスト・メッセージのサイズ制限要素により制限される場合もあります。

D.18.22 スマート・リフェラル

スマート・リフェラルは特別なタイプのエントリで、別のサーバーまたは別のDITの場所、あるいはその両方のコンテンツを参照するディレクトリ情報ツリーに配置できます。スマート・リフェラル・エントリには、リフェラルで使用されるLDAP URLを含むref属性の1つ以上のインスタンスを持つreferralオブジェクト・クラスが含まれます。

D.18.23 TLS起動拡張操作

TLS起動拡張操作は、クリアテキスト接続上で、Transport Security Layerで保護された通信チャネルの開始に使用できる拡張操作のタイプです。クライアントは、保護された通信と保護されない通信の両方で同じネットワーク・ポートを使用できます。

TLS起動拡張操作は、RFC 4511 (http://www.ietf.org/rfc/rfc4511.txt)で定義されており、RFC 4513 (http://www.ietf.org/rfc/rfc4513.txt)で詳細が説明されています。OIDは1.3.6.1.4.1.1466.20037で、値はありません。レスポンスのOIDは1.3.6.1.4.1.1466.20037(リクエストOIDと同じ)で、値はありません。

D.18.24 静的グループ

静的グループはディレクトリ・サーバーのグループのタイプで、グループのメンバーであるエントリの識別名の明示的なセットを提供することにより、メンバーシップを定義します。

静的グループは外部のクライアントにより十分サポートされますが、大量のメンバーを処理する際は、動的グループほどスケーラブルではありません。

D.18.25 構造オブジェクト・クラス

構造オブジェクト・クラスは、主要なオブジェクト・クラス・タイプの1つです。構造オブジェクト・クラスは、このオブジェクト・クラスを含むのエントリのコア・タイプを定義するという点で特別です。エントリは1つの構造クラスを保有する必要があります(その構造クラスは他の構造クラスまたは抽象オブジェクト・クラスから継承する場合もあります)。

エントリの構造オブジェクト・クラスは、ディレクトリ・データの制限を定義するための他のスキーマ要素により使用される場合もあります。エントリの相対識別名で使用される属性を制御する名前書式の定義により使用される場合があります。また、親エントリを保有する場合、そのタイプを制御するDIT構造ルールにより使用される場合があります。構造オブジェクト・クラスは、DITコンテンツ・ルールによっても使用され、補助オブジェクト・クラスのセット、および必須の、使用可能な、禁止されたエントリの属性タイプを制御します。

D.18.26 サブエントリ

「LDAPサブエントリ」を参照してください。

D.18.27 サブスキーマ・サブエントリ

サブスキーマ・サブエントリはディレクトリ・サーバー内の特別なエントリで、サーバーで定義されるスキーマ要素の情報を提供します。このエントリの属性には次のものがあります:

ldapSyntaxes

サーバー・スキーマで定義された属性構文のセット。

matchingRules

サーバー・スキーマで定義された一致ルールのセット。

matchingRuleUse

サーバー・スキーマで定義された一致ルールの使用のセット。

attributeTypes

サーバー・スキーマで定義された属性タイプのセット。

objectClasses

サーバー・スキーマで定義されたオブジェクト・クラスのセット。

nameForms

サーバー・スキーマで定義された名前書式のセット。

dITContentRules

サーバー・スキーマで定義されたDITコンテンツ・ルールのセット。

dITStructureRules

サーバー・スキーマで定義されたDIT構造ルールのセット。

これらはすべて操作属性であるため、明示的にリクエストされない場合は返されないことに注意してください。

また、ディレクトリ・サーバーでは、ディレクトリ情報ツリーの異なる部分を制御するスキーマ定義の異なるセットを持つ、複数のサブスキーマ・サブエントリを、技術的には保有できることに注意してください。指定されたエントリに適用するスキーマは、エントリからsubschemaSubentry仮想属性を取得して確認できます。現在ディレクトリ・サーバーは単一のスキーマのみをサポートしますが、デフォルトでcn=schemaでそのスキーマを公開します。

D.18.28 部分文字列アサーション

部分文字列アサーションは、属性が指定された部分文字列と一致する属性値を保有するかどうかを判断する処理で、部分文字列一致ルールに指定される引数です。

部分文字列アサーションには、次のセットのうち少なくとも1つのコンポーネントが含まれます:

- 0または1つのsubInitial要素。ターゲット値の先頭に指定する必要があります。

- 0または1つのsubAny要素。値の先頭および最後以外の場所に指定できます。複数のsubAny要素が存在する場合は、一致する属性値には、重複なく部分文字列アサーションに設定された順序ですべてのsubAny要素が含まれる必要があります(つまり、属性値に文字を含まない場合は、2つの異なる部分文字列アサーションのコンポーネントの部分である可能性があります)。subInitialコンポーネントまたはsubFinalコンポーネント、あるいはその両方が存在する場合は、subAny要素がそのいずれかと重複することはできません。

- 0または1つのsubFinal要素。ターゲット値の最後に指定する必要があります。

部分文字列アサーションは、部分文字列検索フィルタを処理する際に使用されます。

D.18.29 部分文字列索引

部分文字列索引は、特定の部分文字列を含むエントリを追跡するために使用される索引のタイプです。部分文字列索引の索引キーは、属性値から取得された6文字の部分文字列で構成され、対応する値はこれらの部分文字列を含むエントリのエントリIDを含むIDリストです。属性の部分文字列一致ルールは、索引キーの正規化された値に使用され、部分文字列索引は部分文字列一致ルールを含まない属性には定義できません。

D.18.30 部分文字列検索フィルタ

部分文字列検索フィルタはLDAP検索フィルタのタイプで、指定された部分文字列と一致する、指定された属性の値を含むエントリを識別するために使用できます。サーバーは、部分文字列一致ルールを使用して判断します。

部分文字列検索フィルタは部分文字列アサーションを含む必要があり、次のタイプのうち少なくとも1つのコンポーネントを保有します:

- subInitialコンポーネント。このコンポーネントの値は一致する値の先頭に含まれます。部分文字列フィルタには、0または1つのsubInitialコンポーネントが存在する可能性があります。

- subAnyコンポーネントのセット。このセットの値は一致する値の任意の場所に含まれます。部分文字列フィルタには0個以上のsubAnyコンポーネントが存在する可能性があり、これらのコンポーネントは、subInitialコンポーネントの後およびsubFinalコンポーネントの前で部分文字列フィルタに指定される順に値を含む必要があります。

- subFinalコンポーネント。このコンポーネントの値は一致する値の最後に含まれます。部分文字列フィルタには、0または1つのsubFinalコンポーネントが存在する可能性があります。

LDAP部分文字列フィルタの文字列表現は、左カッコに続く属性名、等号、アスタリスクで個別のコンポーネントを区切った部分文字列アサーションおよび右カッコで構成されます。たとえば、部分文字列フィルタの(cn=ab*def*mno*stu*yz)には、subInitialコンポーネントのab、subAnyコンポーネントのdef、mnoおよびstu、およびsubFinalコンポーネントのyzが含まれます。

D.18.31 サブツリー

サブツリーという用語には2つの定義があります。

この用語の一般的な定義は、エントリおよびすべての下位エントリを含むディレクトリ情報ツリーの部分です。

サブツリーという用語は、RFC 3672 (http://www.ietf.org/rfc/rfc3672.txt)でも、サブツリーの形式の仕様の中で説明されています。サブツリーの仕様は、指定された基準のセットに基づき、エントリをグループ化するメカニズムを提供します。

D.18.32 サブツリー削除制御

サブツリー削除制御は、削除操作に追加して、エントリおよびその下位エントリすべての削除を許可する制御のタイプです。通常の削除操作は、リーフ・エントリのみをターゲット設定できますが、サブツリー削除制御はリーフ以外のエントリをターゲット設定するために使用できます。

サブツリー削除リクエスト制御のOIDは1.2.840.113556.1.4.805で、値はありません。対応するレスポンス制御はありません。

この制御を使用して、ou=People,dc=example,dc=comサブツリーを削除する例を次に示します。

$ ldapdelete -p 1389 -h localhost -D cn=directory manager -j pwd-file \
-J 1.2.840.113556.1.4.805
ou=People,dc=example,dc=com
Processing DELETE request for ou=People,dc=example,dc=com

D.18.33 サポートされている制御

サポートされている制御は、ディレクトリ・サーバーによりサポートされているリクエスト制御を識別するメカニズムです。これらの制御のオブジェクト識別子は、サーバーのルートDSEのsupportedControl属性にリストされています。

Oracle Unified Directoryで現在サポートされているすべての制御のリストは、「サポートされているLDAP制御」を参照してください。

D.18.34 サポートされている拡張

サポートされている拡張は、ディレクトリ・サーバーによりサポートされている拡張操作を識別するメカニズムです。これらの拡張操作のオブジェクト識別子は、サーバーのルートDSEのsupportedExtension属性にリストされています。

ディレクトリ・サーバーでサポートされているすべての拡張のリストは、「サポートされている拡張操作」を参照してください。

D.18.35 サポートされている機能

サポートされている機能は、ディレクトリ・サーバーによりサポートされているオプション機能を識別するメカニズムです。サーバーでサポートされている多くの機能は、サーバーのルートDSEのsupportedFeatures属性でリストされており、そこではサポートされている機能のオブジェクト識別子がリストされています。

ディレクトリ・サーバーでサポートされている機能には次のものがあります:

1.3.6.1.4.1.4203.1.5.1

RFC 3673 (http://www.ietf.org/rfc/rfc3673.txt)で説明されているように、すべての操作属性をリクエストする際に、+インジケータの使用をサーバーがサポートすることを示します。

1.3.6.1.4.1.4203.1.5.2

RFC 4529 (http://www.ietf.org/rfc/rfc4529.txt)で説明されているように、検索属性のセットに1つ以上のオブジェクト・クラス名を含める機能をサーバーがサポートすることを示します。

1.3.6.1.1.14

RFC 4525 (http://www.ietf.org/rfc/rfc4525.txt)で説明されているように、増分変更拡張の一部である増分変更タイプをサーバーがサポートすることを示します。

1.3.6.1.4.1.4203.1.5.3

RFC 4526 (http://www.ietf.org/rfc/rfc4526.txt)で説明されているように、LDAP trueフィルタおよびLDAP falseフィルタをサーバーがサポートすることを示します。

D.18.36 同期

データ同期は、ディレクトリ環境内の変更を追跡し、他の場所に反映できるようにするメカニズムです。

ディレクトリ・サーバーで提供されるデータ同期の主要なタイプはレプリケーションです。

D.19 T

D.19.1 タスク

タスクは、サーバーでいくつかのタイプの処理を実行するためのロジックのセットを提供します。通常、タスクはサーバー内の管理機能の実行に使用されます。使用可能なタスクの例を次に示します:

- サーバー・スキーマへの新しいファイルの追加

- サーバー・バックエンドのコンテンツをバックアップ

- 以前のバックアップを復元

- LDIFインポート操作の実行

- LDIFエクスポート操作の実行

- サーバー・レプリケーション環境でのレプリカの初期化

- インコア再起動の実行

- サーバー停止の実行

タスクは繰り返し実行可能で、特定のスケジュールに従って定期的に実行するようにスケジュールされます。たとえば、バックアップ・タスクは、サーバー・データを定期的にバックアップするために繰り返し実行できます。タスクのスケジューリングの詳細は、「タスクのスケジュールと構成」を参照してください。

D.19.2 時間制限

サーバーの時間制限は構成オプションで、サーバーが検索操作の処理に費やすことができる時間の最大の長さを秒単位で制御します。サーバー全体に関わる設定で、ユーザーのエントリのds-rlim-time-limit操作属性でユーザーごとの構成によりオーバーライドできます。

サーバーの時間制限(またはユーザーごとの値)は、検索リクエスト・メッセージの時間制限要素により制限される場合もあります。

D.19.3 トランザクション

トランザクションは、データベース内で発生する読取りまたは書込みの操作、あるいはその両方の1つ以上の集合です。トランザクションはACIDという頭字語で説明される場合があり、それは、原子性、一貫性、独立性および永続性の略です。ディレクトリ・サーバーはBerkeley DB Java Editionでトランザクションを使用し、単一のLDAP操作の一部として実行される複数の変更を保証します(id2entryデータベースおよび索引の両方に対する更新など)。

ディレクトリ・サーバーがデータベースの操作のために内部でトランザクションを使用しても、クライアントが単一の原子ユニットとして複数の操作を実行できるトランザクション・メカニズムは現在は公開されていません。トランザクションを公開する可能性のあるメカニズムを説明するInternet Draftもありますが(draft-zeilenga-ldap-txn)、現在、ディレクトリ・サーバーではこの機能をサポートしていません。

D.19.4 Transport Security Layer

Transport Security Layer (TLS)は、クライアントとサーバーの間のネットワーク通信を保護するメカニズムです。Secure Sockets Layerの標準化された形式に対して付与された名前です。

通常、TLSよりSSLという用語をお薦めするのは、SSLの方がより一般的な用語であり、また、TLS起動拡張操作との混同を避けるためでもあります。

D.19.5 trueフィルタ

「LDAP trueフィルタ」を参照してください。

D.19.6 信頼マネージャ・プロバイダ

信頼マネージャ・プロバイダはサーバーのコンポーネントで、サーバーに提示される証明書を信頼するかどうかの判断に使用可能な情報を提供できます。

ディレクトリ・サーバーで使用できる信頼マネージャ・プロバイダの詳細は、Trust Manager Provider Configuration (http://www.opends.org/promoted-builds/latest/OpenDS/build/docgen/configuration_guide/trust-manager-provider.html)を参照してください。

D.19.7 typesOnlyフラグ

TypesOnlyフラグは検索操作の要素で、検索結果エントリの一部として返される属性が属性説明のみを含むのか、または属性説明および属性値の両方を含むのかどうかを示します。

D.20 U

D.20.1 アンバインド操作

LDAPアンバインド操作は、クライアントがサーバーからの切断を実行しようとしていることを示すために使用されます。

アンバインド操作は、基礎となる接続が確立されたままになっている場合に、認証セッションの破棄には使用できないことに注意してください。クライアントがアンバインド・リクエストを送信した後で接続を終了しない場合は、サーバーが実行します。接続を認証されていない状態に戻す必要がある場合は、匿名バインド操作が実行されます。

LDAPアンバインド・リクエスト・プロトコルopは次のように定義されます:

UnbindRequest ::= [APPLICATION 2] NULL

アンバインド・リクエストはいずれの要素も持たず、サーバーはアンバインド・リクエストに対してレスポンスを送信しません。

D.20.2 索引なし検索

索引なし検索は、サーバーで定義された索引のセットを使用する処理ができない検索です。データベースのほとんどまたはすべてのエントリを繰り返し処理する必要があります。

索引なし検索はサーバーにとって高い処理コストがかかる可能性があり、ユーザーは、unindexed-search特権を保有する場合にのみ、索引なし検索の実行を許可されます。

詳細は、「ディレクトリ・データへの索引付け」を参照してください。

D.20.3 UNIX暗号化アルゴリズム

UNIX暗号化アルゴリズムは、最終的に一方向メッセージ・ダイジェストを作成するDESベースの暗号化スキームを使用し、ユーザー・パスワードをエンコードする標準メカニズムです。UNIXベースのシステムでパスワードをエンコードするデフォルトのメカニズムとして従来から使用されているため、UNIX暗号化アルゴリズムと呼ばれます。

UNIX暗号化アルゴリズムは、56ビットの暗号化アルゴリズムに基づき、12ビットのみのsaltを使用するため、脆弱であるとみなされていることに注意してください。このため、バインド操作を使用して値の検証を試行するかわりに、サーバーからパスワードを取得してユーザーが入力した値と比較することをクライアントが必要とする場合にのみ使用されます。

D.20.4 未承諾通知

未承諾通知は、拡張操作メッセージのタイプで、対応するクライアントからのリクエストのない種類のメッセージをサーバーが生成するという点で特殊です。重要な情報をクライアントに通知するために使用される場合もあります。

現在、ディレクトリ・サーバーでは、次の未承諾通知1つをサポートしています。それは切断の通知未承諾通知で、サーバーが接続を閉じようとしていることをクライアントに通知するために使用できます。

D.20.5 URL

「URL」を参照してください。

D.20.6 ユーザー属性

ユーザー属性は、userApplicationsの属性使用方法を持つ属性タイプです。ユーザー属性は、サーバーの内部処理で使用される状態情報の保管に使用される操作属性に対して、ディレクトリで実際に情報を保管するために使用されます。

検索操作で特定の属性を返すようにリクエストしない場合は常に、一致するエントリのすべてのユーザー属性が返されます。明示的な値である*(アスタリスク)も、すべてのユーザー属性を明示的に含めるために追加できます。

D.21 V

D.21.1 仮想属性

仮想属性は、その属性値は実際にはバックエンドに保管されませんが、そのかわりになんらかの方法で動的に生成される属性のタイプです。仮想属性のタイプにより、値は様々な方法で取得できます。属性の値はある種のロジックに基づいて実行時に計算されますが、仮想属性にはハードコードされた値を使用するものもあります。

ディレクトリ・サーバーで使用できる仮想属性のタイプの詳細は、Virtual Attribute Configuration (http://www.opends.org/promoted-builds/latest/OpenDS/build/docgen/configuration_guide/virtual-attribute.html)を参照してください。

D.21.2 仮想属性専用制御

仮想属性専用制御は、サーバーが仮想属性のみを一致するエントリに含めるように要求します。つまり、実在属性は検索結果エントリから除外されます。

仮想属性専用制御のリクエスト・オブジェクト識別子は2.16.840.1.113730.3.4.19で、値はありません。

仮想属性専用制御を使用しないベースDN上の検索の例を次に示します:

$ ldapsearch -p 1389 -D "cn=directory manager" -j pwd-file -b "dc=example,dc=com" \
-s base "objectclass=*"
version: 1
dn: dc=example,dc=com
objectClass: domain
objectClass: top
dc: example

仮想属性専用制御を使用する同じ検索の例を次に示します:

$ ldapsearch -p 1389 -D "cn=directory manager" -j pwd-file \
-J "2.16.840.1.113730.3.4.19"   -b "dc=example,dc=com" -s base "objectclass=*"
version: 1
dn: dc=example,dc=com

D.21.3 仮想ディレクトリ

仮想ディレクトリはネットワーク・デーモンのタイプで、Lightweight Directory Access Protocolを使用してクライアントと通信しますが、異なるソースの組合せから基礎となるデータを取得します。仮想ディレクトリには、次のように様々な機能が数多くあります:

- リレーショナル・データベースまたはフラット・ファイルのように、異なるリポジトリに対してLDAPフロントエンドを提供します。

- 複数のリポジトリのデータをマージするメカニズムを提供します。

D.21.4 仮想一覧表示制御

仮想一覧表示(VLV)は、検索操作に追加して、結果のサブセットのみを返す予定であることを示す制御です。検索結果全体を一度に1ページずつ取り出すために使用できます。サーバーから任意の結果のサブセットを取得するために使用できることを除けば、単純なページングの結果制御に似ており、リクエスト全体にわたり結果が正しくソートされていることを保証するために、検索リクエストにサーバー側ソート制御を含める必要があります。

VLV制御はdraft-ietf-ldapext-ldapv3-vlv-09 (http://tools.ietf.org/html/draft-ietf-ldapext-ldapv3-vlv-09)で定義されます。リクエスト制御のオブジェクト識別子は2.16.840.1.113730.3.4.9で、値は次のようにエンコードされます:

VirtualListViewRequest ::= SEQUENCE {
beforeCount    INTEGER (0..maxInt),
afterCount     INTEGER (0..maxInt),
target       CHOICE {
byOffset        [0] SEQUENCE {
offset          INTEGER (1 .. maxInt),
contentCount    INTEGER (0 .. maxInt) },
greaterThanOrEqual [1] AssertionValue },
contextID     OCTET STRING OPTIONAL }

レスポンス制御のOIDは2.16.840.1.113730.3.4.10で、値は次のようにエンコードされます:

VirtualListViewResponse ::= SEQUENCE {
targetPosition    INTEGER (0 .. maxInt),
contentCount     INTEGER (0 .. maxInt),
virtualListViewResult ENUMERATED {
success (0),
operationsError (1),
protocolError (3),
unwillingToPerform (53),
insufficientAccessRights (50),
timeLimitExceeded (3),
adminLimitExceeded (11),
innapropriateMatching (18),
sortControlMissing (60),
offsetRangeError (61),
other(80),
... },
contextID     OCTET STRING OPTIONAL }

検索リクエストでこの制御を使用する例は、「仮想リスト表示制御を使用した検索」を参照してください。

D.21.5 仮想静的グループ

仮想静的グループは特別なタイプのグループで、外部のクライアントには静的グループのように見えますが、メンバーシップ情報をサーバーの別のグループ(動的グループなど)から取得します。

仮想静的グループはクライアント・アプリケーションが静的グループのみをサポートする場合に主に使用されますが、動的グループでの維持により適している大量のメンバーを保有します。

D.21.6 VLV索引

仮想一覧表示(VLV)索引は、仮想一覧表示制御により効率的な検索処理に使用できる、ディレクトリ・サーバー・データベースで使用されるメカニズムです。VLV索引は特定のクエリおよびソート・パラメータを使用して、仮想一覧表示が実行されることを効率的にサーバーに通知します。また、この索引は、仮想一覧表示をより迅速に使用するために必要な情報の収集および維持をサーバーができるようにします。VLV索引は、ソートするエントリのエントリIDおよび属性値のセットであるIDリストのソート済ブロックを保管します。

D.22 W

D.22.1 Who Am I拡張操作

Who Am I拡張操作は、クライアント接続の認可アイデンティティを判断するための拡張操作を提供します。RFC 4532 (http://www.ietf.org/rfc/rfc4532.txt)で定義されています。

Who Am I拡張操作のリクエスト・オブジェクト識別子は1.3.6.1.4.1.4203.1.11.3で、リクエスト値はありません。レスポンスにはレスポンスOIDはなく、その値は、クライアントの認可アイデンティティを含む文字列(または匿名ユーザーの認可アイデンティティの場合は空の文字列)です。

認可アイデンティティ制御はバインド・リクエストにのみ含まれますが、Who Am I拡張操作により提供される情報はクライアントが認証された後ならいつでも使用できることを除けば、認可アイデンティティ制御により提供される情報と似ています。

D.22.2 ワーク・キュー

ディレクトリ・サーバー・ワーク・キューは、未処理リクエストを追跡し、適切な方法で処理されていることを確認するために使用するメカニズムです。ワーク・キューの機能は拡張可能なAPIにより提供されますが、デフォルトの実装は比較的単純で、キューは多くのワーカー・スレッドのサービスを受けます。空きワーカー・スレッドが存在する場合は、通常、キューは空のままです。すべてのワーカー・スレッドがビジーの場合は、後続のリクエストがワーク・キューに配置され、FIFO方式で処理されます。

D.22.3 ワーカー・スレッド

ワーカー・スレッドは、ディレクトリ・サーバーでのリクエスト処理に使用されるスレッドです。ワーカー・スレッドはワーク・キューと関連付けられ、(必要に応じてリクエストの到着を待っている)キューからリクエストを取得し、適切にリクエストを処理し、次のリクエストのためにキューへ返すというループで動作します。

D.22.4 ワークフロー

ワークフローは、指定されたネーミング・コンテキストの処理を定義します。全体的な処理はタスクの順序付けと同期化に分けられ、ワークフロー要素により定義されます。

D.22.5 ワークフロー要素

ワークフロー要素は、ワークフロー処理の重要な構築ブロックです。サーバーへ送信されたクライアント・リクエストの取扱方法を定義します。ロード・バランシングや分散など、ワークフロー要素のメイン・タスクはプロキシ・サーバーに実装されます。

D.22.6 書込み可能モード

ディレクトリ・サーバーの書込み可能モードは、書込み操作が許可されるかどうかを制御するために使用されます。書込み可能モードの構成は、単一のバックエンドに制限するか、またはサーバー全体に適用できます。

使用可能な書込み可能モードは次のとおりです:

有効

サーバーはすべての書込み操作の処理を試行します。

無効

サーバーはすべての書込み操作を却下します。

内部のみ

サーバーは、内部操作として、または同期によって開始される書込み操作の処理を試行しますが、外部クライアントからのリクエストは却下します。

エントリDNは、エントリの現在のDNのコピーを提供する操作属性です。DNはエントリの属性ではないため、属性値アサーションの実行には使用できません。RFC 5020 (http://www.ietf.org/rfc/rfc5020.txt)で説明されるように、エントリDNはエントリのDNにアクセスするメカニズムを提供します。

オラクル社の法律上の注意点について

コピーライトについて

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

商標と登録商標について

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の登録商標です。

ライセンス制約の保証と結果的に生じる損害の免責

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

保証免責

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

制限付権利

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

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）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

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

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。