Oracle® Database

エンタープライズ・ユーザー・セキュリティ管理者ガイド

11gリリース2(11.2)

E50142-01(原本部品番号:E10744-04)

2013年6月

Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド, 11gリリース2 (11.2)

E50142-01

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

原本著者: Rod Ward、Sumit Jeloka

原本協力者:  Srividya Tata、Sarma Namuduri、Nina Lewis、Chi Ching Chui、Janaki Narasinghanallur、Min-Hank Ho、Sudha Iyer、Supriya Kalyanasundaram、Lakshmi Kethana、Van Le、Stella Li、Vikram Pesati、Andy Philips、Richard Smith、Deborah Steiner、Philip Thornton、Ramana Turlapati、Peter Wahl、Pat Huey、Sudheesh Varma、Hozefa Palitanawala、Manoj Kamani

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

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

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

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 Database 11gのエンタープライズ・ユーザー・セキュリティの新機能

- Oracle Database 10gリリース2(10.2)のエンタープライズ・ユーザー・セキュリティの新機能

- Oracle Database 10gリリース1(10.1)のエンタープライズ・ユーザー・セキュリティの新機能

1 エンタープライズ・ユーザー・セキュリティの概要

- 1.1 エンタープライズ・ユーザー・セキュリティの概要

- 1.1.1 ユーザー管理の課題

- 1.1.2 エンタープライズ・ユーザー・セキュリティ: 全体像

- 1.1.2.1 Oracle Internet Directoryでアイデンティティ管理を実装する方法

- 1.1.2.2 エンタープライズ・ユーザーとデータベース・ユーザーの比較

- 1.1.2.3 エンタープライズ・ユーザー・スキーマについて

- 1.1.2.4 エンタープライズ・ユーザーがデータベース・リンクを使用してデータベース・リソースにアクセスする方法

- 1.1.2.5 エンタープライズ・ユーザーの認証方法

- 1.1.3 エンタープライズ・ユーザー・セキュリティのディレクトリ・エントリについて

- 1.1.3.1 エンタープライズ・ユーザー

- 1.1.3.2 エンタープライズ・ロール

- 1.1.3.3 エンタープライズ・ドメイン

- 1.1.3.4 データベース・サーバー・エントリ

- 1.1.3.5 ユーザー・スキーマ・マッピング

- 1.1.3.6 管理グループ

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

- 1.2 エンタープライズ・ユーザー・セキュリティにおける共有スキーマの使用方法

- 1.2.1 エンタープライズ・ユーザー・セキュリティで使用される共有スキーマの概要

- 1.2.2 エンタープライズ・ユーザーに対して共有スキーマを構成する方法

- 1.2.3 エンタープライズ・ユーザーをスキーマにマップする方法

- 1.3 エンタープライズ・ユーザー・プロキシ

- 1.4 エンタープライズ・ユーザー・セキュリティにおける現行ユーザーのデータベース・リンクの使用方法

- 1.5 エンタープライズ・ユーザー・セキュリティのデプロイの考慮事項

- 1.5.1 セキュリティ資格証明の一元化におけるセキュリティ

- 1.5.1.1 一元化されたセキュリティ資格証明管理に関連するセキュリティ上の利点

- 1.5.1.2 一元化されたセキュリティ資格証明管理に関連するセキュリティ上の危険性

- 1.5.2 パスワード認証エンタープライズ・ユーザーのデータベース・ログイン情報のセキュリティ

- 1.5.2.1 信頼できるデータベースとは

- 1.5.2.2 データベース・パスワード検証の保護

- 1.5.3 エンタープライズ・ドメインでのデータベース・メンバーシップの定義に関する考慮事項

- 1.5.4 エンタープライズ・ユーザー・セキュリティのクライアント、データベースおよびディレクトリ間の認証タイプの選択

- 1.5.4.1 標準構成

2 エンタープライズ・ユーザー・セキュリティの準備

- 2.1 ディレクトリを使用するためのデータベースの構成

- 2.2 ディレクトリへのデータベースの登録

- 2.3 データベースでの共有スキーマの作成

- 2.4 共有スキーマへのエンタープライズ・ユーザーのマッピング

- 2.5 エンタープライズ・ユーザーとしてのデータベースへの接続

- 2.6 エンタープライズ・ロールの使用

- 2.7 プロキシ権限の使用

3 構成ツールと管理ツールの概要

- 3.1 エンタープライズ・ユーザー・セキュリティのツールの概要

- 3.2 Oracle Internet Directoryセルフ・サービス・コンソール

- 3.3 Oracle Net Configuration Assistant

- 3.3.1 Oracle Net Configuration Assistantの起動

- 3.4 Database Configuration Assistant

- 3.4.1 Database Configuration Assistantの起動

- 3.5 Oracle Wallet Manager

- 3.5.1 Oracle Wallet Managerの起動

- 3.5.2 orapkiコマンドライン・ユーティリティ

- 3.6 Oracle Enterprise Manager

- 3.7 ユーザー移行ユーティリティ

- 3.8 エンタープライズ・ユーザー・セキュリティ管理者/DBAの責務

4 エンタープライズ・ユーザー・セキュリティの構成タスクとトラブルシューティング

- 4.1 エンタープライズ・ユーザー・セキュリティの構成の概要

- 4.2 エンタープライズ・ユーザー・セキュリティの構成のロードマップ

- 4.3 エンタープライズ・ユーザー・セキュリティのディレクトリの準備(フェーズ1)

- 4.3.1 データベース・ウォレットとパスワードについて

- 4.3.1.1 複数データベース間でのウォレットとsqlnet.oraファイルの共有

- 4.4 データベースおよびディレクトリでのエンタープライズ・ユーザー・セキュリティ・オブジェクトの構成(フェーズ2)

- 4.5 必要な認証方式を使用するためのエンタープライズ・ユーザー・セキュリティの構成(フェーズ3)

- 4.5.1 パスワード認証を使用するエンタープライズ・ユーザー・セキュリティの構成

- 4.5.2 Kerberos認証を使用するエンタープライズ・ユーザー・セキュリティの構成

- 4.5.3 SSL認証を使用するエンタープライズ・ユーザー・セキュリティの構成

- 4.5.3.1 ウォレットおよびディレクトリ内のデータベースDNの表示

- 4.6 現行ユーザーのデータベース・リンクの有効化

- 4.7 エンタープライズ・ユーザー・セキュリティのトラブルシューティング

- 4.7.1 パスワード認証エンタープライズ・ユーザーに関するORA-#エラー

- 4.7.2 Kerberos認証エンタープライズ・ユーザーに関するORA-#エラー

- 4.7.3 SSL認証エンタープライズ・ユーザーに関するORA-#エラー

- 4.7.4 グローバル・ロールがない場合のチェックリスト

- 4.7.5 ユーザー・スキーマ・エラーのチェックリスト

- 4.7.6 ドメイン読取りエラーのチェックリスト

5 エンタープライズ・ユーザー・セキュリティの管理

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

- 5.1.1 アイデンティティ管理レルムのバージョン

- 5.1.2 アイデンティティ管理レルムのプロパティの設定

- 5.1.2.1 アイデンティティ管理レルムのログイン名、Kerberosプリンシパル名、ユーザー検索ベースおよびグループ検索ベースの各属性の設定

- 5.1.3 アイデンティティ管理レルムに対するデータベースとディレクトリ間のデフォルト認証タイプの設定

- 5.1.4 アイデンティティ管理レルム管理者の管理

- 5.2 エンタープライズ・ユーザーの管理

- 5.2.1 新規エンタープライズ・ユーザーの作成

- 5.2.2 エンタープライズ・ユーザー・パスワードの設定

- 5.2.3 エンタープライズ・ユーザーへのエンタープライズ・ロールの付与

- 5.2.4 エンタープライズ・ユーザーへのプロキシ権限の付与

- 5.2.5 エンタープライズ・ユーザーのユーザー・スキーマ・マッピングの作成

- 5.2.6 エンタープライズ・ユーザーのラベル認可の作成

- 5.3 ユーザー定義のエンタープライズ・グループの構成

- 5.3.1 ユーザー定義のエンタープライズ・グループへのエンタープライズ・ロールの付与

- 5.4 エンタープライズ・ユーザー・セキュリティ用のデータベースの構成

- 5.4.1 データベースのユーザー・スキーマ・マッピングの作成

- 5.4.2 データベース・スキーマ・マッピングを管理する管理者の追加

- 5.5 エンタープライズ・ドメインの管理

- 5.5.1 エンタープライズ・ドメインの作成

- 5.5.2 エンタープライズ・ドメインへのデータベースの追加

- 5.5.3 エンタープライズ・ドメインのユーザー・スキーマ・マッピングの作成

- 5.5.4 エンタープライズ・ロールの構成

- 5.5.5 プロキシ権限の構成

- 5.5.6 ユーザー認証タイプの構成と現行ユーザーのデータベース・リンクの有効化

- 5.5.7 ドメイン管理者の構成

A ユーザー移行ユーティリティの使用方法

- A.1 エンタープライズ・ユーザーへのローカルまたは外部ユーザーの移行の利点

- A.2 ユーザー移行ユーティリティの概要

- A.2.1 バルク・ユーザー移行プロセスの概要

- A.2.1.1 手順1: (フェーズ1)移行の準備

- A.2.1.2 手順2: ユーザー情報の確認

- A.2.1.3 手順3: (フェーズ2)移行の完了

- A.2.2 ORCL_GLOBAL_USR_MIGRATION_DATA表について

- A.2.2.1 フェーズ1とフェーズ2の間に変更できるインタフェース表の列値

- A.2.3 ユーザーの旧データベース・スキーマに対する移行の影響

- A.2.4 移行プロセス

- A.3 移行の実行の前提条件

- A.3.1 必須のデータベース権限

- A.3.2 必須のディレクトリ権限

- A.3.3 ユーザー移行ユーティリティの実行に必要な設定

- A.4 ユーザー移行ユーティリティのコマンドライン構文

- A.5 ユーザー移行ユーティリティのヘルプへのアクセス

- A.6 ユーザー移行ユーティリティのパラメータ

- A.6.1 キーワード: HELP

- A.6.2 キーワード: PHASE

- A.6.3 キーワード: DBLOCATION

- A.6.4 キーワード: DIRLOCATION

- A.6.5 キーワード: DBADMIN

- A.6.6 キーワード: ENTADMIN

- A.6.7 キーワード: USERS

- A.6.8 キーワード: USERSLIST

- A.6.9 キーワード: USERSFILE

- A.6.10 キーワード: KREALM

- A.6.11 キーワード: MAPSCHEMA

- A.6.12 キーワード: MAPTYPE

- A.6.13 キーワード: CASCADE

- A.6.14 キーワード: CONTEXT

- A.6.15 キーワード: LOGFILE

- A.6.16 キーワード: PARFILE

- A.7 ユーザー移行ユーティリティの使用例

- A.7.1 独自のスキーマを保持したままのユーザーの移行

- A.7.2 ユーザーの移行と共有スキーマへのマッピング

- A.7.2.1 異なるCASCADEオプションを使用した共有スキーマへのユーザーのマッピング

- A.7.2.2 異なるMAPTYPEオプションを使用した共有スキーマへのユーザーのマッピング

- A.7.3 PARFILE、USERSFILEおよびLOGFILEパラメータを使用したユーザーの移行

- A.8 ユーザー移行ユーティリティの使用におけるトラブルシューティング

- A.8.1 ユーザー移行ユーティリティの一般的なエラー・メッセージ

- A.8.1.1 両フェーズで表示されるエラー・メッセージの解決

- A.8.1.2 フェーズ1で表示されるエラー・メッセージの解決

- A.8.1.3 フェーズ2で表示されるエラー・メッセージの解決

- A.8.2 ユーザー移行ユーティリティの一般的なログ・メッセージ

- A.8.2.1 フェーズ1の一般的なログ・メッセージ

- A.8.2.2 フェーズ2の一般的なログ・メッセージ

- A.8.3 ユーザー移行ユーティリティのエラー・メッセージとログ・メッセージのまとめ

B SSL外部ユーザー変換スクリプト

- B.1 SSL外部ユーザー変換スクリプトの使用方法

- B.2 グローバル・ユーザーから外部ユーザーへの変換

C エンタープライズ・ユーザー・セキュリティとMicrosoft Active Directoryの統合

- C.1 Active DirectoryとOracle Internet Directory間の同期の設定

- C.2 Oracleクライアントと相互運用するためのWindows 2000ドメイン・コントローラの設定

- C.3 Windows 2000ドメイン・コントローラと相互運用するためのOracle Databaseの設定

- C.4 Windows 2000 KDCと相互運用するためのOracle Databaseクライアントの設定

- C.5 クライアントの初期チケットの取得

- C.6 Kerberos認証を使用するエンタープライズ・ユーザー・セキュリティの構成

DOracle9iからOracle Database 11gリリース2 (11.2)へのアップグレード

- D.1 リリース9.2からリリース9.0.4へのOracle Internet Directoryのアップグレード

- D.2 リリース9.2.0.8からリリース11.2へのOracleデータベースのアップグレード

- D.3 Oracle Databaseリリース10g (10.1)以上からOracle Database 11gリリース2 (11.2)へのアップグレード

用語集

索引

はじめに

このマニュアルは、Oracle Database 11gリリース2 (11.2)用の『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』です。

Oracle Databaseには、データを保護する包括的な一連のセキュリティ機能が組み込まれています。これらの機能には、データベース権限、ロール、およびアイデンティティ管理サービスを提供するためのOracle Identity Managementインフラストラクチャとの統合が含まれます。アイデンティティ管理とは、ネットワーク・エンティティのセキュリティ・ライフサイクル全体(アカウントの作成、保留、変更および削除)を組織で管理するプロセスを指します。

このマニュアルでは、Oracle Identity Managementプラットフォームで提供されるディレクトリ・サービスであるOracle Internet Directoryを使用して、Oracle Databaseユーザーを実装、構成および管理する方法について説明します。

ここでは、次の内容について説明します。

- 対象読者

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

- 関連ドキュメント

- 表記規則

対象読者

このマニュアルは、次の1つ以上の作業を行うセキュリティ管理者、DBAおよびアプリケーション開発者を対象としています。

- データベース・ユーザーと権限の管理

- データベース・ユーザーのプロビジョニング

- エンタープライズ・ユーザー用のPL/SQLアプリケーションの開発

このマニュアルを活用するには、SQLおよびOracleに関する実用的な基礎知識が必要です。「関連ドキュメント」に記載されているOracleのセキュリティ機能についても理解している必要があります。

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

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ドキュメントを参照してください。

- 『Oracle Internet Directory管理者ガイド』

- Oracle Identity Managementのユーザー・リファレンス・ガイド

- 『Oracle Database Advanced Security管理者ガイド』

- 『Oracle Database 2日でデータベース管理者』

- 『Oracle Database管理者ガイド』

- 『Oracle Databaseセキュリティ・ガイド』

- Oracle Databaseアドバンスト・アプリケーション開発者ガイド

- 『Oracle Database SQL言語リファレンス』

- 『Oracle Database SQL言語クイック・リファレンス』

- 『Oracle Databaseエラー・メッセージ』

- 『Oracle Databaseリファレンス』

- Oracle Database Heterogeneous Connectivityユーザーズ・ガイド

- 『Oracle Database Net Services管理者ガイド』

このマニュアルに記載されている例の多くは、Oracle Databaseのインストール時に「基本インストール」オプションを選択するとデフォルトでインストールされるサンプル・スキーマを使用しています。これらのスキーマがどのように作成されているか、およびその使用方法は、『Oracle Databaseサンプル・スキーマ』を参照してください。

リリース・ノート、インストール関連ドキュメント、ホワイト・ペーパーまたはその他の関連ドキュメントは、OTN(Oracle Technology Network)から、無償でダウンロードできます。OTNを使用するには、オンラインでの登録が必要です。登録は、次のWebサイトから無償で行えます。

http://www.oracle.com/technetwork/community/join/overview/

OTNのユーザー名とパスワードをすでに持っている場合は、次のOTN Webサイトのドキュメント・セクションに直接移動できます。

http://www.oracle.com/technetwork/indexes/documentation/

エンタープライズ・ユーザー・セキュリティによってサポートされるセキュリティ技術の概念については、次のサード・パーティの出版物を参照してください。

- 『Applied Cryptography, Second Edition: Protocols, Algorithms, and Source Code in C』 Bruce Schneier著。New York: John Wiley & Sons, 1996

- 『SSL & TLS Essentials: Securing the Web』Stephen A.Thomas著。New York: John Wiley & Sons, 2000

- 『Understanding and Deploying LDAP Directory Services』Timothy A.Howes、Ph.D.、Mark C.Smith、Gordon S.Good共著。Indianapolis: New Riders Publishing, 1999

- 『Understanding Public-Key Infrastructure: Concepts, Standards, and Deployment Considerations』 Carlisle Adams、Steve Lloyd共著。Indianapolis: New Riders Publishing, 1999

表記規則

このセクションでは、このマニュアルの本文およびコード例で使用される表記規則について説明します。この項の内容は次のとおりです。

- 本文の表記規則

- コード例の表記規則

- Windowsオペレーティング・システム環境での表記規則

本文の表記規則

本文では、特定の項目が一目でわかるように、次の表記規則を使用します。その規則と使用例を示します。

規則

意味

例

太字

太字は、本文中で定義されている用語または用語集に記載されている用語(あるいはその両方)を示します。

この句を指定すると、索引構成表が作成されます。

イタリック

イタリックは、ドキュメントのタイトルまたは強調を示します。

『Oracle Database概要』
リカバリ・カタログおよびターゲット・データベースが同じディスクに存在しないことを確認します。

固定幅フォントの大文字

固定幅フォントの大文字は、システム指定の要素を示します。このような要素には、パラメータ、権限、データ型、RMANキーワード、SQLキーワード、SQL*Plusまたはユーティリティ・コマンド、パッケージおよびメソッドがあります。また、システム指定の列名、データベース・オブジェクト、データベース構造、ユーザー名およびロールも含まれます。

NUMBER列に対してのみ、この句を指定できます。
BACKUPコマンドを使用して、データベースのバックアップを作成できます。

USER_TABLESデータ・ディクショナリ・ビュー内のTABLE_NAME列を問い合せます。

DBMS_STATS.GENERATE_STATSプロシージャを使用します。

固定幅フォントの小文字

固定幅フォントの小文字は、実行可能ファイル、ファイル名、ディレクトリ名およびユーザーが指定する要素のサンプルを示します。このような要素には、コンピュータ名およびデータベース名、ネット・サービス名および接続識別子があります。また、ユーザーが指定するデータベース・オブジェクトとデータベース構造、列名、パッケージとクラス、ユーザー名とロール、プログラム・ユニットおよびパラメータ値も含まれます。
注意: プログラム要素には、大文字と小文字を組み合せて使用するものもあります。これらの要素は、記載されているとおりに入力してください。

sqlplusと入力して、SQL*Plusをオープンします。
パスワードは、orapwdファイルで指定します。

/disk1/oracle/dbsディレクトリ内のデータ・ファイルおよび制御ファイルのバックアップを作成します。

hr.departments表には、department_id、department_nameおよびlocation_id列があります。

QUERY_REWRITE_ENABLED初期化パラメータをtrueに設定します。

oeユーザーとして接続します。

JRepUtilクラスが次のメソッドを実装します。

固定幅フォントの小文字のイタリック

固定幅フォントの小文字のイタリックは、プレースホルダまたは変数を示します。

parallel_clauseを指定できます。
old_release.SQLを実行します。ここで、old_releaseとは、アップグレード前にインストールしたリリースを示します。

コード例の表記規則

コード例は、SQL、PL/SQL、SQL*Plusまたは他のコマンドライン文の例です。次の例のように固定幅フォントで表示され、通常のテキストと区別されます。

SELECT username FROM dba_users WHERE username = 'MIGRATE';

次の表に、コード例で使用される表記規則とその使用例を示します。

規則

意味

例

[ ]

大カッコは、カッコ内の項目を任意に選択することを表します。

DECIMAL (digits [ , precision ])

{ }

中カッコは、カッコ内の項目をグループ化することを表します。

{ENABLE | DISABLE}

|

縦線は、2つの選択項目の区切りに使用します。

{ENABLE | DISABLE}
[COMPRESS | NOCOMPRESS]

...

省略記号は、構文の説明での繰返しを示します。
また、コード例または本文での省略を示す場合もあります。

CREATE TABLE ... AS subquery;

SELECT col1, col2, ... , coln FROM employees;

その他の記号

大カッコ([ ])、中カッコ({ })、縦線()および省略記号(...)以外の記号は、記載されているとおりに入力する必要があります。

acctbal NUMBER(11,2);
acct    CONSTANT NUMBER(4) := 3;

Italics

イタリック体は、特定の値を指定する必要があるプレースホルダや変数を示します。

CONNECT SYSTEM
Enter password: password
DB_NAME = database_name

UPPERCASE

大文字は、システム指定の要素を示します。これらの要素は、ユーザー定義の要素と区別するために大文字で示されます。大カッコ内にないかぎり、表示されているとおりの順序および綴りで入力します。ただし、大/小文字が区別されないため、大文字または小文字のいずれでも入力できます。

SELECT last_name, employee_id FROM employees;
SELECT * FROM USER_TABLES;
DROP TABLE hr.employees;

lowercase

表名、列名またはファイル名などのユーザー定義のプログラム要素を示します。
注意: プログラム要素には、大文字と小文字を組み合せて使用するものもあります。これらの要素は、記載されているとおりに入力してください。

SELECT last_name, employee_id FROM employees;
sqlplus hr/hr
CREATE USER mjones IDENTIFIED BY ty3MU9;

Windowsオペレーティング・システム環境での表記規則

次の表に、Windowsオペレーティング・システム環境での表記規則とその使用例を示します。

規則

意味

例

「スタート」→メニュー項目を選択

プログラムを起動する方法を示します。

Database Configuration Assistantを起動するには、「スタート」→「プログラム」→「Oracle - HOME_NAME」→「Configuration and Migration Tools」→「Database Configuration Assistant」の順に選択します。

ファイル名およびディレクトリ名

ファイル名およびディレクトリ名は大/小文字が区別されません。特殊文字の左山カッコ(<)、右山カッコ(>)、コロン(:)、二重引用符(")、スラッシュ(/)、縦線(|)およびハイフン(-)は使用できません。円記号(\)は、引用符で囲まれている場合でも、要素のセパレータとして処理されます。Windowsでは、ファイル名が\\で始まる場合、汎用命名規則が使用していると解釈されます。

c:\winnt"\"system32はC:\WINNT\SYSTEM32と同じです。

C:\>

現在のハード・ディスク・ドライブのWindowsコマンド・プロンプトを表します。コマンド・プロンプトのエスケープ文字はカレット(^)です。プロンプトは作業中のサブディレクトリを表します。このマニュアルでは、コマンド・プロンプトと呼びます。

C:\oracle\oradata>

特殊文字

Windowsコマンド・プロンプトで二重引用符(")のエスケープ文字として円記号(￥)が必要な場合があります。丸カッコおよび一重引用符(')にはエスケープ文字は必要ありません。エスケープ文字および特殊文字の詳細は、Windowsオペレーティング・システムのドキュメントを参照してください。

C:\>exp HR/HR TABLES=employees QUERY=\"WHERE job_id='SA_REP' and salary<8000\"

HOME_NAME

Oracleホームの名前を表します。ホーム名には、英数字で16文字まで使用できます。ホーム名に使用可能な特殊文字は、アンダースコアのみです。

C:\> net start OracleHOME_NAMETNSListener

ORACLE_HOMEおよびORACLE_BASE

Oracle8iリリース8.1.3より前のリリースでは、Oracleコンポーネントをインストールすると、すべてのサブディレクトリが最上位のORACLE_HOMEの直下に置かれました。Windowsの場合、デフォルトではC:\orantです。
このリリースは、Optimal Flexible Architecture (OFA)のガイドラインに準拠しています。ORACLE_HOMEディレクトリ下に配置されないサブディレクトリもあります。最上位のディレクトリはORACLE_BASEと呼ばれ、デフォルトではC:\oracle\product\10.1.0です。他のOracleソフトウェアがインストールされていないコンピュータに最新リリースのOracleをインストールした場合、Oracleホーム・ディレクトリはデフォルトでC:\oracle\product\10.1.0\db_nに設定されます。nは最新リリースの番号です。Oracleホーム・ディレクトリは、ORACLE_BASEの直下に配置されます。

このマニュアルに示すディレクトリ・パスの例は、すべてOFAの表記規則に準拠しています。

OFA準拠の詳細、および非OFA準拠ディレクトリ下でのOracle製品のインストールの詳細は、『Oracle Databaseインストレーション・ガイド for Microsoft Windows』を参照してください。

ORACLE_BASE\ORACLE_HOME\rdbms\adminディレクトリに移動します。

エンタープライズ・ユーザー・セキュリティの新機能

この項では、エンタープライズ・ユーザー・セキュリティの新機能と、追加情報の参照先について説明します。以前のリリースの新機能情報も、現行のリリースに移行するユーザーを支援するために提供します。

次の各項では、エンタープライズ・ユーザー・セキュリティの新機能について説明します。

- Oracle Database 11gのエンタープライズ・ユーザー・セキュリティの新機能

- Oracle Database 10gリリース2(10.2)のエンタープライズ・ユーザー・セキュリティの新機能

- Oracle Database 10gリリース1(10.1)のエンタープライズ・ユーザー・セキュリティの新機能

Oracle Database 11gのエンタープライズ・ユーザー・セキュリティの新機能

エンタープライズ・ユーザー・セキュリティ11gには、次の新機能があります。

エンタープライズ・ユーザー・セキュリティは、Oracle Enterprise Managerに付属するグラフィカル・ユーザー・インタフェース(GUI)を使用して管理できるようになりました。Oracle Enterprise Managerを使用すると、エンタープライズ・ユーザー、グループ、ロール、ドメインなどを簡単に構成できます。

関連項目:
第2章「エンタープライズ・ユーザー・セキュリティの準備」

Oracle Database 10gリリース2(10.2)のエンタープライズ・ユーザー・セキュリティの新機能

エンタープライズ・ユーザー・セキュリティ10gリリース2(10.2)には、次の新機能があります。

- エンタープライズ・ユーザー・セキュリティ10gリリース2(10.2)には、複数のデータベース間でsqlnet.oraファイルを共有するための新機能が含まれています。データベースは、1つのsqlnet.oraファイルを他のデータベースと共有しながら、個別のウォレットを維持できます。これによって、エンタープライズ・ユーザー・セキュリティの構成が容易になり、Secure Sockets Layer(SSL)の操作性が向上します。詳細は、「複数データベース間でのウォレットとsqlnet.oraファイルの共有」を参照してください。

- Oracle Internet Directoryのすべてのアイデンティティ管理レルムに対してパスワード・ポリシーが作成されます。これらのポリシーは、レルム内に存在するすべてのエンタープライズ・ユーザーに適用されます。パスワード・ポリシーには、パスワードの複雑性、パスワードの最低文字数などの設定が含まれます。また、アカウントのロックアウトおよびパスワードの有効期限の設定も含まれます。エンタープライズ・ユーザー・セキュリティでは、Oracle Internet Directoryで設定されているレルム全体のパスワード・ポリシーを順守します。
データベースは、エンタープライズ・ユーザーの認証時にOracle Internet Directoryと通信します。ユーザーのアカウントがロックされているか、無効であるか、期限切れであるか、または期限切れが近いかを確認します。これらの場合には、該当する警告またはエラー・メッセージが表示されます。

関連項目:
パスワード・ポリシーとその管理の詳細は、「パスワード・ポリシー」を参照してください。

- ユーザー証明書の識別名(DN)がOracle Internet DirectoryのDNと一致している必要はなくなりました。この機能は、公開鍵インフラストラクチャ(PKI)の認証局がDNでの2つの共通名(CN)の使用をサポートしていない場合に役立ちます。この機能により、ユーザーまたはデータベースに新しい証明書を要求せずにDirectoryを再構成することもできます。詳細は、「SSL認証を使用するエンタープライズ・ユーザー・セキュリティの構成」を参照してください。

エンタープライズ・ユーザー・セキュリティ10gリリース2(10.2)では、セキュリティと使いやすさの両方を向上させる新しいプロキシ機能もいくつか導入されています。

- 特定のエンタープライズ・ユーザー(またはエンタープライズ・ユーザーのリスト)に対するプロキシ権限を作成し、Oracle Internet Directoryに格納できるようになりました。以前は、プロキシ権限は共有スキーマにのみ付与できたため、その共有スキーマ内のすべてのエンタープライズ・ユーザーは必然的にターゲット・ユーザーとしてプロキシされました。

- プロキシ・セッションを確立すると、シングル・ユーザー・セッションになります。以前は、ターゲット・ユーザーとしてプロキシするように元の接続セッションから切り替えると、最初のセッションがアクティブなまま2番目の独立セッションが作成されました。

- プロキシ・アクセスは、SQLPLUSおよびOracle Call Interface(OCI)を通じて可能になりました。以前のプロキシ・アクセスは、OCIを介してのみ確立できました。

新しいプロキシ機能の詳細は、「エンタープライズ・ユーザー・プロキシ」を参照してください。

Oracle Database 10gリリース1(10.1)のエンタープライズ・ユーザー・セキュリティの新機能

エンタープライズ・ユーザー・セキュリティ10gリリース1(10.1)には、次の新機能があります。

- Kerberos認証されたエンタープライズ・ユーザー
データベースに対するKerberosベースの認証は、LDAPディレクトリで管理されているユーザーに対して使用できます。これには、Oracle Internet Directoryや、Directory Integration Platformを使用してOracle Internet Directoryと連携して動作するように同期された他のサード・パーティ・ディレクトリが含まれます。この機能を使用するには、サード・パーティ・ディレクトリから同期されたユーザーを含め、すべてのディレクトリ・ユーザーに、Kerberosプリンシパル名属性(krbPrincipalName属性)を組み込む必要があります。

関連項目:
構成の詳細は、「Kerberos認証を使用するエンタープライズ・ユーザー・セキュリティの構成」を参照してください。

- データベースとOracle Internet Directory間の接続で不要になった公開鍵インフラストラクチャ(PKI)資格証明
このリリースでは、パスワードとSASLベースの認証によりデータベースをOracle Internet Directoryにバインドすることができ、ディレクトリと複数データベースに対するPKI資格証明の設定のオーバーヘッドをなくすことができます。SASL (Simple Authentication and Security Layer)は、Internet Engineering Task Force RFC 2222で定義されている標準です。LDAPなどの接続ベースのプロトコルに認証サポートを追加する方法です。

関連項目:
構成の詳細は、「パスワード認証を使用するエンタープライズ・ユーザー・セキュリティの構成」を参照してください。

- サード・パーティLDAPディレクトリでのユーザー管理のサポート
エンタープライズ・ユーザー・セキュリティの現行のリリースでは、ユーザーとそのパスワードをサード・パーティのLDAPディレクトリに格納し、管理できます。この機能は次のものがある場合に使用できます。

- サード・パーティ・ディレクトリとOracle Internet Directoryを自動的に同期するDirectory Integration Platform。

- Oracle Databaseによる標準パスワード検証の認識機能(これもこのリリースでの新機能)。

1 エンタープライズ・ユーザー・セキュリティの概要

エンタープライズ・ユーザー・セキュリティは、Oracle Database 11gリリース2 (11.2) Enterprise Editionの重要なコンポーネントです。多数のエンタープライズ・データベース・ユーザーの管理およびセキュリティの問題を処理できます。エンタープライズ・ユーザーとは、ディレクトリ内に定義されたユーザーです。ユーザーのアイデンティティはエンタープライズ全体を通して変わることがありません。エンタープライズ・ユーザー・セキュリティはOracle Identity Managementインフラストラクチャに依存しています。そのため、LDAP準拠のディレクトリ・サービスを使用して、ユーザーを一元的に格納し、管理します。

この章では、エンタープライズ・ユーザー・セキュリティの内容とその仕組みについて説明します。項目は次のとおりです。

- エンタープライズ・ユーザー・セキュリティの概要

- エンタープライズ・ユーザー・セキュリティにおける共有スキーマの使用方法

- エンタープライズ・ユーザー・プロキシ

- エンタープライズ・ユーザー・セキュリティにおける現行ユーザーのデータベース・リンクの使用方法

- エンタープライズ・ユーザー・セキュリティのデプロイの考慮事項

1.1 エンタープライズ・ユーザー・セキュリティの概要

この概要では、組織にとってのエンタープライズ・ユーザー・セキュリティの利点、エンタープライズ・ユーザーが認証される仕組みおよび分散データベース・システム全体にわたるリソースにアクセスする仕組みについて説明します。ここでは、次の項目について説明します。

- ユーザー管理の課題

- エンタープライズ・ユーザー・セキュリティ: 全体像

- エンタープライズ・ユーザー・セキュリティのディレクトリ・エントリについて

1.1.1 ユーザー管理の課題

管理者は、会社全体のユーザー情報を最新かつ安全に保つ必要があります。この業務はアプリケーションおよびユーザーの数が増えれば増えるほど難しくなります。通常、各ユーザーはデータベースごとに複数のアカウントを持っているため、複数のユーザー名とパスワードを覚える必要があります。その結果、ユーザーのパスワードは覚えきれないほど多くなり、アカウントは管理者が効率的に管理しきれないほど多くなります。

何千ものユーザーがデータベース・アカウントにアクセスするため、ユーザー管理には多くのリソースが必要です。ユーザー名、電話番号、システム・ロール、システム権限など、複数のアプリケーションで使用される共通の情報は、多くの場合、エンタープライズ内に分散して存在しています。このように、冗長で一貫性のないデータが増えるため、データの管理が困難になっています。

ユーザーとアカウントの管理の問題に加えて、これらの状況によりセキュリティの問題も発生します。たとえば、あるユーザーが退職するか、職務が変更になった場合は、そのユーザーの権限が悪用されることを防ぐため、その日のうちにユーザーの権限を変更する必要があります。しかし、大規模な企業ではたいていの場合、複数のデータベースに分散したユーザー・アカウントが多く、管理者は適時に変更できないことがあります。

同様に、ユーザーがあまりにも多くのパスワードを持っている場合、それらのパスワードをメモに書き留めることで、他者がパスワードを簡単に書き写せるようになることがあります。また、覚えやすいパスワードを選択し、他者が簡単に推測できるようになる場合や、複数のアプリケーションに同じパスワードを使用し、パスワードが見破られてセキュリティ上のリスクが高まる場合もあります。複数のパスワードを覚えておくためのユーザーの工夫はすべて、エンタープライズ・セキュリティを危険にさらす可能性があります。

1.1.2 エンタープライズ・ユーザー・セキュリティ: 全体像

エンタープライズ・ユーザー・セキュリティでは、Oracle Internet Directoryで提供されるアイデンティティ管理サービス、およびLDAP準拠のディレクトリ・サービスを利用して、ユーザー、管理およびセキュリティに関する問題に対処します。アイデンティティ管理とは、組織でネットワーク・エンティティのセキュリティ・ライフ・サイクル全体を管理するプロセスです。通常、組織のアプリケーション・ユーザーの管理を指します。セキュリティ・ライフ・サイクルの手順には、アカウント作成、一時停止、権限変更およびアカウント削除が含まれます。

図1-1に、Oracle Identity Managementインフラストラクチャを基盤として使用するOracleセキュリティ・アーキテクチャに、エンタープライズ・ユーザー・セキュリティを組み込む仕組みを示します。

図1-1 エンタープライズ・ユーザー・セキュリティとOracleセキュリティ・アーキテクチャ

ユーザーは、管理者が選択した構成に応じて、シングル・サイン・オン(SSO)または単一パスワード認証を通じてエンタープライズ・ユーザー・セキュリティを利用します。シングル・サイン・オンを使用する場合、ユーザーの認証が必要なのは1回のみであり、その後の認証は透過的に行われます。この機能ではSSLを必要とするため、Oracle Identity Managementインフラストラクチャの構成要素であるOracleAS Single Sign-Onと混同されることはありません。

単一パスワード認証を使用すると、ユーザーは1つのグローバル・パスワードを使用して複数のデータベースに対して認証を行うことができます。ただし、各接続に固有の認証が必要となります。パスワードは、中心となるLDAP準拠のディレクトリに安全に格納され、暗号化やアクセス制御リスト(ACL)などのセキュリティ・メカニズムを使用して保護されます。この方法により、記憶し管理するパスワードの数を減らし、SSL設定のオーバーヘッドをなくし、操作性を改善します。

エンタープライズ・ユーザー・セキュリティを使用するには、Oracle Internet Directory 10g (9.0.4)以上が必要です。その他のLDAP準拠のディレクトリ・サービスは、Oracle Directory Integration Platformを使用してOracle Internet Directoryと同期することによりサポートされます。別のディレクトリ・サービス製品であるOracle Virtual Directoryでは、LDAPプロトコルやXMLプロトコルを介して、複数のデータ・ソースへの動的な単一アクセス・ポイントを提供します。Oracle Virtual Directoryでは、Oracle Internet Directory、Microsoft Active Directory、Sun Java Systems Directoryなどのインスタンスに格納されているアイデンティティ・データのアプリケーション固有のビューが複数提供されており、Oracle Virtual Directoryを使用してアプリケーション固有のソースへのデータ・アクセスを保護し、既存データ・ソースに対する高可用性を向上させることができます。

この項では、次の項目について説明します。

- Oracle Internet Directoryでアイデンティティ管理を実装する方法

- エンタープライズ・ユーザーとデータベース・ユーザーの比較

- エンタープライズ・ユーザー・スキーマについて

- エンタープライズ・ユーザーがデータベース・リンクを使用してデータベース・リソースにアクセスする方法

- エンタープライズ・ユーザーの認証方法

関連項目:
Oracle Directory Integration PlatformおよびOracle Virtual Directoryを他のディレクトリとともに使用する方法は『Oracle Internet Directory管理者ガイド』を参照してください。

注意:
Microsoft Active Directoryは、Windowsプラットフォーム上のOracleデータベースに対してのみサポートされます。

1.1.2.1 Oracle Internet Directoryでアイデンティティ管理を実装する方法

Oracle Internet Directoryは、アイデンティティ管理レルムの概念を使用してディレクトリ情報ツリー(DIT)内の情報を編成します。ディレクトリ情報ツリーは、ディレクトリ・オブジェクト・エントリで構成される階層ツリー型構造です。ディレクトリ内にある、1つのオブジェクトに関する情報の集まりをエントリと呼びます。このオブジェクトは人である場合も、構成情報などのネットワーク・デバイスに関する情報である場合もあります。DIT内のディレクトリ・オブジェクトの場所に名前を付けて識別するため、各エントリには一意の識別名(DN)が割り当てられます。エントリのDNはエントリ自体とその親エントリで構成され、エントリ自体からDITのルート(最上位)エントリの順で、昇順に接続されています。

1.1.2.1.1 アイデンティティ管理レルムについて

アイデンティティ管理レルムは、ディレクトリ・エントリのサブツリーであり、そのすべてが同じ管理ポリシーによって管理されます。たとえば、イントラネットにアクセスできるエンタープライズ内のすべての従業員はある1つのレルムに属し、エンタープライズのパブリック・アプリケーションにアクセスするすべての外部ユーザーは他のレルムに属します。異なるレルムを使用することによって、ユーザー集団を分離し、各レルムで異なる管理ポリシー(パスワード・ポリシーやネーミング・ポリシーなど)を適用できます。ログインIDの識別に使用されるデフォルトのニックネーム属性はuidで、アイデンティティ管理レルムごとに設定されます。

1.1.2.1.2 アイデンティティ管理レルム固有のOracleコンテキストについて

各アイデンティティ管理レルムには、そのレルムに対するOracle製品情報を格納する、レルム固有のOracleコンテキスト(レルムOracleコンテキスト)があります。レルムOracleコンテキストは、アプリケーションデータ、ユーザーの名前と場所の指定、ユーザーの認証方法、グループの場所、および権限の割り当てといった、そのレルムOracleコンテキストが置かれている特定のアイデンティティ管理レルムに固有の事項すべてを格納します。

関連項目:

- Oracle Internet Directoryとそのアーキテクチャの詳細は、『Oracle Internet Directory管理者ガイド』を参照してください。

- エンタープライズ・ユーザー・セキュリティに使用されるOracle Internet Directoryエントリの詳細は、「エンタープライズ・ユーザー・セキュリティのディレクトリ・エントリについて」を参照してください。

1.1.2.2 エンタープライズ・ユーザーとデータベース・ユーザーの比較

通常、データベース・ユーザーは、次のようなCREATE USER文を使用してデータベースに定義されます。

CREATE USER username IDENTIFIED BY password;

この文によって、ユーザー・スキーマに関連付けられたデータベース・ユーザーが作成されます。データベース・ユーザーは、次のようなCONNECTコマンドを使用してデータベースにアクセスし、パスワードを指定して認証されます。

CONNECT username@database_service_name
Enter Password:

データベース・ユーザーは、アクセスする必要がある各データベースに作成する必要があり、データベースごとに異なるパスワードを選択できます。データベース・ユーザー権限は、各データベースのローカル・ロールによって制御されます。

これに対して、エンタープライズ・ユーザーは、データベース・アクセスについて、Oracle Internet DirectoryなどのLDAP準拠のディレクトリで一元的にプロビジョニングおよび管理されます。エンタープライズ・ユーザーは、ディレクトリ内に識別名(DN)と呼ばれる一意の識別情報を持っています。エンタープライズ・ユーザーがデータベースにログオンすると、データベースはDNを使用してこれらのユーザーを認証します。

エンタープライズ・ユーザーは、グローバル・ユーザーとしてデータベースに定義されます。グローバル・ユーザーは、独自のスキーマを持つことも、アクセスするデータベース内のグローバル・スキーマを共有することもできます。エンタープライズ・ユーザーは、次の2通りの方法でCREATE USER文のGLOBALLY句を使用して作成できます。

次の文に示すように、AS句を使用してユーザーのディレクトリDNを指定できます。

CREATE USER username IDENTIFIED GLOBALLY AS '<DN of directory user entry>';

この場合は、エンタープライズ・ユーザーにそれぞれ専用のスキーマが割り当てられます。

または、次の文に示すように、AS句を使用してNULL文字列を指定することもできます。

CREATE USER username IDENTIFIED GLOBALLY AS '';

AS句でNULL文字列を指定すると、認証ユーザーはディレクトリによって適切なデータベース・スキーマにマップされます。この場合は、Oracle Internet Directoryに設定および格納されているマッピング情報に基づいて、複数のユーザーを共有スキーマにマップできます。

注意:
次の構文を使用して、共有スキーマを作成することもできます。

CREATE USER username IDENTIFIED GLOBALLY;

これは、NULL文字列を指定した場合と同じです。

エンタープライズ・ユーザーがSSLを使用してデータベースに接続するとき、パスワードは使用しません。かわりに、次のCONNECTコマンドを使用します。このコマンドはクライアントのsqlnet.oraファイル内の情報に基づいて、ウォレット・ロケーションを検索します。

CONNECT /@database_service_name

パスワード認証エンタープライズ・ユーザーは、通常のデータベース・ユーザーと同じCONNECT文を使用してデータベースに接続します。たとえば、パスワード認証エンタープライズ・ユーザーは、次の構文を使用してデータベースに接続します。

CONNECT username@database_service_name
Enter password:

データベースは、エンタープライズ・ユーザーから接続リクエストを受信すると、ユーザー認証および認可(ロール)情報を確認するためにディレクトリを参照します。

関連項目:

- エンタープライズ・ユーザーの作成方法と使用方法に関するチュートリアルは、第2章「エンタープライズ・ユーザー・セキュリティの準備」を参照してください。

- 「新規エンタープライズ・ユーザーの作成」

- グローバル・ユーザーの詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

- ディレクトリにユーザーを定義する方法は、『Oracle Internet Directory管理者ガイド』を参照してください。

1.1.2.3 エンタープライズ・ユーザー・スキーマについて

エンタープライズ・ユーザーは個別のデータベース・スキーマ(排他スキーマ)を保持できます。また、エンタープライズ・セキュリティ管理者がエンタープライズ・ユーザーを共有スキーマにマップしている場合は、共有スキーマを保持できます。

1.1.2.3.1 プライベートまたは排他スキーマ

ユーザーがアクセスするデータベースに個別のスキーマを保持する必要がある場合は、次のようにします。

- ディレクトリにエンタープライズ・ユーザーを作成します。

- ユーザーがアクセスする各データベースに、ユーザーごとにグローバル・ユーザー・スキーマを作成します。

アクセスする各データベースにエンタープライズ・ユーザーごとに個別のアカウントを作成すると、オーバーヘッドが大きくなります。かわりに、各データベース内の1つの汎用共有スキーマにアクセスするエンタープライズ・ユーザーを作成すると、エンタープライズ・ユーザー・ソリューションの効率が高まります。

1.1.2.3.2 共有スキーマ

エンタープライズ・ユーザー・ソリューションの真の利点を得るには、エンタープライズ・ユーザーに対して共有スキーマを使用します。この方法の手順は次のとおりです。

- ディレクトリにエンタープライズ・ユーザーを作成します。

- 各データベースに共有スキーマを1つ作成します。

- Oracle Internet Directoryに共有スキーマ・マッピングを1つ作成します。

エンタープライズ・ユーザーがアクセスする各データベース上の汎用共有スキーマにユーザーをマップすると、エンタープライズ・ユーザーごとに個別のスキーマを作成することで生じるオーバーヘッドが大幅に削減されます。

共有スキーマ・エンタープライズ・ユーザーは、そのユーザーがアクセスするすべてのデータベース上の汎用共有スキーマにマップできます。また、あるデータベースでは排他スキーマを持ち、別のデータベースでは共有スキーマを持つようにすることも可能です。共有スキーマ・マッピングはディレクトリに格納されます。

関連項目:

- エンタープライズ・ユーザー用の共有スキーマの作成方法と使用方法は、「エンタープライズ・ユーザー・セキュリティにおける共有スキーマの使用方法」を参照してください。

- データベースでの共有スキーマの作成方法に関するチュートリアルは、「データベースでの共有スキーマの作成」を参照してください。

1.1.2.4 エンタープライズ・ユーザーがデータベース・リンクを使用してデータベース・リソースにアクセスする方法

データベース・リンクは、ローカル・データベースまたはネットワーク定義に格納されるネットワーク・オブジェクトであり、リモート・データベース、そのデータベースへの通信パス、および場合によってはユーザー名とパスワードを識別します。定義されると、データベース・リンクはリモート・データベースへのアクセスに使用されます。Oracle Databaseでは、接続ユーザー・リンク、固定ユーザー・リンクおよび現行ユーザー・リンクをサポートしています。

エンタープライズ・ユーザーは、3種類のデータベース・リンクをすべて使用できます。接続ユーザー・リンクには、リモート・サーバーにアカウントを持つローカル・ユーザーがアクセスします。固定ユーザー・リンクには、リンク定義の一部としてユーザー名とパスワードが含まれます。現行ユーザーのデータベース・リンクでは、エンタープライズ・ユーザーが、リンクの実行中に認証情報を渡したり、リンク定義に認証情報を格納したりせずに、リモート・データベースのオブジェクトにアクセスできます。データベース・ネットワーク接続にはSSLを必要とするため、データベース用の公開鍵インフラストラクチャ(PKI)資格証明を取得して保持する必要があります。現行ユーザーのデータベース・リンクは、エンタープライズ・ユーザーのみがリモート・データベースの接続に使用することができます。

関連項目:

- 現行ユーザーのデータベース・リンクの作成方法と使用方法は、「エンタープライズ・ユーザー・セキュリティにおける現行ユーザーのデータベース・リンクの使用方法」を参照してください。

- Oracle Databaseでサポートされる全タイプのデータベース・リンクの詳細は、『Oracle Database管理者ガイド』を参照してください。

1.1.2.5 エンタープライズ・ユーザーの認証方法

エンタープライズ・ユーザー・セキュリティでは、次の認証方式をサポートしています。

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

- SSLベースの認証

- Kerberosベースの認証

各認証方式にはそれぞれに長所と短所があります。表1-1に、エンタープライズ・ユーザー・セキュリティ実装に最適な認証方式を選択する基準をまとめます。

表1-1 エンタープライズ・ユーザー・セキュリティの認証: 選択基準

パスワード認証

SSL認証

Kerberos認証

パスワードベースの認証

SSLによる厳密認証を行う。

Kerberosバージョン5のチケットを使用した厳密認証を行う。

ユーザーとパスワードを一元管理できる。

ユーザーとPKI資格証明/ウォレットを一元管理できる。

ユーザーとKerberos資格証明を一元管理できる。

各データベース接続に個別の認証が必要である。

SSLを使用したシングル・サインオン(SSO)をサポートする。

Kerberosバージョン5の暗号化チケットと認証子を使用したSSOおよび認証転送をサポートする。

ユーザーの現行の認証方式を保持する。

すべてのユーザーに対してPKI資格証明を生成する必要があるため、初期構成が難しくなる場合がある。(管理者のPKIに関する知識による)

データベース・ユーザーを認証するにはKerberosをインストールして構成する必要があるため、初期構成が難しくなる場合がある。

ユーザーIDを2層または多層アプリケーションで使用できる。OracleAS Single Sign-Onユーザーとエンタープライズ・ユーザーで同じ保管パスワードを使用する。

2層または多層環境のいずれかと互換性がある。

2層または多層環境のいずれかと互換性がある。

Oracle Database 10g以上でOracleリリース7.3以上のクライアントをサポートする。

Oracle Database 10g以上でOracle8i以上のクライアントをサポートする。

Oracle Database 10g以上でOracle Database 10g以上のクライアントをサポートする。

データベース間の接続にSSLが使用されている場合にのみ、現行ユーザーのデータベース・リンクをサポートする。

現行ユーザーのデータベース・リンクをサポートする。

データベース間の接続にSSLが使用されている場合にのみ、現行ユーザーのデータベース・リンクをサポートする。

Oracle Internet Directoryと同期される場合は、サード・パーティ・ディレクトリを使用してユーザーを格納できる。脚注 1

Oracle Internet Directoryと同期される場合は、サード・パーティ・ディレクトリを使用してユーザーを格納できる。脚注 2

Oracle Internet Directoryと同期される場合は、サード・パーティ・ディレクトリを使用してユーザーを格納できる。脚注 3

脚注1 サード・パーティ・ディレクトリがMicrosoft Active Directoryの場合は、ユーザー・パスワードを変更するときに、Active DirectoryとOracle Internet Directoryの両方でパスワードを変更する必要があります。

脚注2 ユーザーのPKCS #12属性を同期するには、Directory Integration Servicesエージェントを変更する必要があります。

脚注3 サード・パーティ・ディレクトリがMicrosoft Active Directoryの場合は、Windowsにログインすることによってデータベースへのシングル・サインオン・ログインが可能になります。ただし、他のサード・パーティ・ディレクトリのDirectory Integration Servicesエージェントを変更してKrbPrincipalName属性を同期する必要があります。この同期は、Microsoft Active Directoryに対して自動的に行われます。

注意:
エンタープライズ・ユーザー・セキュリティでは、3層環境がサポートされています。Oracle Databaseのプロキシ認証機能により、次の両方が可能になります。
(i) 多層でのユーザー名とパスワードのプロキシ

(ii) 多層でのX.509証明書および識別名のプロキシ

関連項目:

- エンタープライズ・ユーザー・セキュリティの各種認証の構成方法は、第4章「エンタープライズ・ユーザー・セキュリティの構成タスクとトラブルシューティング」を参照してください。

- プロキシ認証の使用方法は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

1.1.3 エンタープライズ・ユーザー・セキュリティのディレクトリ・エントリについて

ディレクトリでは、オブジェクトに関する情報の個々のコレクションをエントリと呼びます。エンタープライズ・ユーザー・セキュリティの場合、ユーザー、ロール、データベースなどの要素はディレクトリ・オブジェクトであり、これらのオブジェクトに関する情報はエントリとしてディレクトリに格納されます。

ディレクトリ内の各エントリは、DNによって一意に識別されます。DNによって、一般にディレクトリ情報ツリー(DIT)と呼ばれるディレクトリ・エントリ階層内のエントリの場所が正確にわかります。

注意:
Oracle Database 10g以上では、データベースをOracle Internet Directoryの完全なアイデンティティ管理レルムに登録する必要があります。

関連項目:
ディレクトリ・エントリの詳細は、『Oracle Internet Directory管理者ガイド』を参照してください。

次の各項では、エンタープライズ・ユーザー・セキュリティに関連するディレクトリ・エントリについて説明します。

1.1.3.1 エンタープライズ・ユーザー

エンタープライズ・ユーザーは、ディレクトリ内で定義され、管理されるユーザーです。各エンタープライズ・ユーザーは、エンタープライズ全体で一意の識別情報を持ちます。エンタープライズ・ユーザー・エントリは、レルムOracleコンテキスト内を除き、アイデンティティ管理レルム内の任意の場所に配置できます。

注意:
9.0.4以上のOracle Internet Directoryにエンタープライズ・ユーザーを作成する場合は、9.0.4以上のOracle Internet Directoryに同梱されているDelegated Administration System (DAS)などのツールを使用してください。使用しているデータベースが9iまたは9iR2の場合でも、9.0.4以上のOracle Internet Directoryにユーザーを作成するときには、9iまたは9iR2のEnterprise Security ManagerのGUIツールを使用しないでください。
アイデンティティ管理レルムにエンタープライズ・ユーザーを作成する場合は、Oracle Application Server 10gに同梱されているOracle Internet Directoryセルフ・サービス・コンソールなどのDASベースのツールのみを使用してください。

次の各項で説明するエントリは、レルムOracleコンテキスト内にのみ配置できます。

1.1.3.2 エンタープライズ・ロール

エンタープライズ・ロールは、1つ以上のデータベース・グローバル・ロールを保持する、コンテナのように機能するディレクトリ・オブジェクトです。各グローバル・ロールは、権限が割り当てられている特定のデータベースに定義されますが、エンタープライズ・ロールを使用してディレクトリで管理されます。エンタープライズ・ユーザーにエンタープライズ・ロールを割り当てて、データベースに対するアクセス権限を決定できます。図1-3の例では、OracleDefaultDomainの下に「Manager」というエンタープライズ・ロールがあります。

たとえば、エンタープライズ・ロールsales_managerに、Customer Relationship Management (CRM)データベースに対する権限を持つグローバル・ロールmanage_leadsと財務データベースに対する権限を持つグローバル・ロールbonus_approvalが含まれるとします。図1-2に、この例を示します。

図1-2 エンタープライズ・ロールの例

エンタープライズ・ロールは、1つ以上のエンタープライズ・ユーザーに割り当てることができます。たとえば、エンタープライズ・ロールsales_managerを、同じ職務の多くのエンタープライズ・ユーザーに割り当てることができます。この情報はディレクトリで保護され、ディレクトリ管理者のみがユーザーの管理とそのロールの割当てを行うことができます。ユーザーには、エンタープライズ・ロール以外に、接続先スキーマに対する権限に基づいて、データベース内のローカル・ロールや権限も付与することができます。

エンタープライズ・ロール・エントリは、エンタープライズ・ドメイン・サブツリーに格納されます。各エンタープライズ・ロールには、各データベース・サーバーに対応するグローバル・ロールと、関連付けられたエンタープライズ・ユーザーの情報が含まれます。エンタープライズ・ドメイン管理者は、Oracle Enterprise Managerを使用してエンタープライズ・ロールを作成および管理します。

関連項目:
Oracle Enterprise Managerを使用したエンタープライズ・ロールの作成方法と管理方法は、「エンタープライズ・ロールの構成」を参照してください。

注意:
データベースは、ログイン・プロセスの一環としてディレクトリからユーザーのグローバル・ロールを取得します。ディレクトリ内のユーザーのグローバル・ロールを変更しても、次にユーザーがデータベースにログインするまでその変更は反映されません。

1.1.3.3 エンタープライズ・ドメイン

エンタープライズ・ドメインは、データベースとエンタープライズ・ロールのグループです。ドメインの例には、企業の技術部門や小規模な企業などがあります。図1-3の例では、アイデンティティ管理レルムのOracleDBSecurityエントリの下に「Services」というエンタープライズ・ドメインがあります。エンタープライズ・ドメイン管理者が、Oracle Enterprise Managerを使用してユーザーにエンタープライズ・ロールを割り当て、エンタープライズ・セキュリティを管理するのは、このエンタープライズ・ドメイン・レベルです。

ディレクトリのエンタープライズ・ドメイン・サブツリーは、そのドメインのエンタープライズ・ロール・エントリ、ユーザー・スキーマ・マッピングおよびエンタープライズ・ドメイン管理者のグループという3種類のエントリから構成されます。エンタープライズ・ドメインは、複数のデータベースに適用される情報の管理に使用されます。エンタープライズ・ドメインに含まれるすべてのユーザー・スキーマ・マッピング・エントリは、ドメイン内のすべてのデータベースに適用されます。個々のデータベースに異なるユーザー・スキーマ・マッピングを適用する必要がある場合は、次の項で説明するデータベース・サーバー・エントリを使用します。

前の項で説明したように、エンタープライズ・ロールはドメイン内の特定のデータベースに適用されます。エンタープライズ・ロール、ドメイン・レベルのマッピングおよびドメイン管理者グループは、すべてOracle Enterprise Managerを使用して管理されます。

関連項目:
「エンタープライズ・ドメインの管理」

1.1.3.4 データベース・サーバー・エントリ

データベース・サーバー・エントリ(図1-3で「Sales」と表示されている)は、1つのデータベース・サーバーに関する情報を格納したディレクトリ・エントリです。このエントリは、データベース登録時にDatabase Configuration Assistantによって作成されます。データベース・サーバー・エントリは、完全または部分的なユーザーDNとデータベース共有スキーマ名の間のマッピングを記述する、ユーザー・スキーマ・マッピングと呼ばれるデータベース・レベルのマッピング・エントリの親です。ユーザー・スキーマ・マッピング・エントリは、データベース管理者によってOracle Enterprise Managerを使用して作成されます。

関連項目:
「Oracle Enterprise Manager」

データベース管理者は、Oracle Enterprise Managerで管理されるディレクトリ管理グループOracleDBAdminsに属します。OracleDBAdminsまたはOracleContextAdminsグループ・メンバーのみが、OracleDBAdminsグループに対してユーザーを追加または削除できます。ユーザーがディレクトリにデータベースを登録すると、Database Configuration Assistantによって、登録を実行したユーザーがOracleDBAdminsグループに自動的に追加されます。このグループのディレクトリ・エントリは、DITのデータベース・サーバー・エントリの下に位置します。

関連項目:

- OracleContextAdminsグループの詳細は、表1-2を参照してください。

- 「タスク6: ディレクトリへのデータベースの登録」

- 「エンタープライズ・ドメインの管理」および「データベース・スキーマ・マッピングを管理する管理者の追加」

図1-3 レルムOracleコンテキスト内の関連エントリ

1.1.3.5 ユーザー・スキーマ・マッピング

ユーザー・スキーマ・マッピングは、ユーザーDNとOracleデータベース・スキーマのマッピング情報を格納したディレクトリ・エントリです。マッピングで参照されるユーザーは、データベースへの接続時に指定されたスキーマに接続されます。ユーザー・スキーマ・マッピング・エントリは、レルムOracleコンテキスト内の場所に応じて、1つのデータベースのみ、またはドメイン内のすべてのデータベースに適用できます。

関連項目:

- 「エンタープライズ・ユーザーをスキーマにマップする方法」

- 「エンタープライズ・ドメインのユーザー・スキーマ・マッピングの作成」

1.1.3.6 管理グループ

アイデンティティ管理レルムには、エンタープライズ・ユーザー・セキュリティに関連する管理グループが含まれています。図1-3では、このレルムの管理グループを「グループ」と表記された三角形の中に示しています。各管理グループには、グループ自体へのアクセスを制御するアクセス制御リスト(ACLs)が含まれています。ディレクトリの他の場所に置かれたACLはグループを参照することができるため、ディレクトリ管理者には必要な管理タスクを実行するためのアクセス権が与えられます。レルムを作成した管理ユーザーは自動的にその各グループの最初のメンバーとなり、関連付けられた権限を各グループにより付与されます。ただし、このユーザーは削除することができます。

レルム内の関連する管理グループを表1-2に示します。

注意:
次の点に注意してください。他の方法を使用すると、エンタープライズ・ユーザー・セキュリティ・オブジェクトのセキュリティ構成が無効になり、エンタープライズ・ユーザー機能も無効になる可能性があります。

- レルムOracleコンテキストに含まれるオブジェクトのACLは変更しないでください。変更されたレルムOracleコンテキスト・オブジェクトのACLはサポートされません。

- エンタープライズ・ユーザー・セキュリティのディレクトリ・エントリを変更するには、Oracle Enterprise Manager、Oracle Internet Directoryセルフ・サービス・コンソール、Database Configuration AssistantなどのOracleのツール製品のみを使用してください。

表1-2 レルムOracleコンテキスト内の管理グループ

管理グループ

説明

OracleContextAdmins

DN: (cn=OracleContextAdmins,cn=Groups,cn=OracleContext...)

デフォルト所有者: アイデンティティ管理レルムを作成したユーザー。(インストール時に作成されたレルムの場合は、orcladmin。)

OracleContextAdminsは、関連付けられたレルムOracleコンテキスト内のすべてのグループおよびエントリに対する完全なアクセス権を持ちます。

OracleDBAdmins

DN: (cn=OracleDBAdmins,cn=<database_entry_name>,cn=OracleContext...)

デフォルト所有者: なし。Database Configuration Assistantによって、ディレクトリにデータベースを登録したユーザーが自動的にこのグループのメンバーになります。

このグループのメンバーは、このデータベース固有のユーザー・スキーマ・マッピングを管理します。すでにこのグループまたはOracleContextAdminsのメンバーであるユーザーのみが、OracleDBAdminsグループに対してユーザーを追加または削除できます。

OracleDBCreators

DN: (cn=OracleDBCreators,cn=OracleContext...)

デフォルト所有者: OracleContextAdmins

デフォルトのレルムOracleコンテキストの作成中に、Oracle Internet Directoryコンフィギュレーション・アシスタントにより、これらのグループ・メンバーに対して次のアクセス権/権限が設定されます。

- レルムOracleコンテキストのデータベース・サービス・オブジェクトに対するAdd権限

- デフォルト・ドメインに対するModify権限

OracleDBCreatorsは、Database Configuration Assistantを使用して新規データベースを作成し、ディレクトリに登録します。

OracleDBSecurityAdmins

DN: (cn=OracleDBSecurityAdmins,cn=OracleContext...)

デフォルト所有者: すべてのグループ・メンバー。

デフォルトのレルムOracleコンテキストの作成中に、Oracle Internet Directoryコンフィギュレーション・アシスタントにより、これらのグループ・メンバーに対して次のアクセス権/権限が設定されます。

- OracleDBSecurityサブツリーにおけるすべての権限

- このグループのメンバーシップに対するModify権限

OracleDBSecurityAdminsは、エンタープライズ内のすべてのドメインに対する権限を持ち、次のタスクを実行します。

- データベースとディレクトリ間のデフォルトの認証方式など、エンタープライズ・ユーザー・セキュリティ構成をレルムに設定します。

- グループの所有者がOracleDBSecurityAdminsグループを管理します。

- エンタープライズ・ドメインを作成および削除します。

- エンタープライズ内のあるドメインから別のドメインへのデータベースを移動します。

OracleDomainAdmins

DN: (cn=OracleDomainAdmins,cn=<enterprise_domain_name>,

cn=OracleDBSecurity,cn=Products,cn=OracleContext....)

デフォルト所有者: ドメインを作成または更新したユーザー。

新規コンテキストおよびOracleDefaultDomainが作成されると、初期メンバーがコンテキスト作成者になります。

OracleDomainAdminsグループのメンバーは、エンタープライズ・ドメインに対する完全な権限を持ちます。このグループのメンバーは、ドメイン全体に固有のマッピング、エンタープライズ・ロールおよびプロキシ権限を管理します。このグループのメンバーシップを変更するには、OracleDomainAdmins (ドメインの場合)、OracleDBSecurityAdminsまたはOracleContextAdminsのメンバーであることが必要です。

OracleUserSecurityAdmins

DN: (cn=OracleUserSecurityAdmins,cn=Groups,cn=OracleContext...)

デフォルト所有者: アイデンティティ管理レルムを作成したユーザー。

デフォルトでは、ACLは、関連する権限を設定するOracle Internet Directoryのディレクトリ・ルートに設定されるため、OracleSecurityAdminsはOracleユーザー・セキュリティを管理できます。

OraclePasswordAccessibleDomains

DN: (cn=OraclePasswordAccessibleDomains,cn=Groups,cn=OracleContext...)

デフォルト所有者: OracleDBSecurityAdminsと同じ。

グループ・メンバーは、パスワード認証されたエンタープライズ・ユーザーに対して有効なデータベースを含むエンタープライズ・ドメインです。

1.1.3.7 パスワード・ポリシー

パスワード・ポリシーは、アイデンティティ管理レルム内のユーザー・パスワードすべてに適用されるルール・セットです。パスワード・ポリシーには、パスワードの複雑性、パスワードの最低文字数などの設定が含まれます。また、アカウントのロックアウトおよびパスワードの有効期限の設定も含まれます。

パスワード・ポリシーのエントリは、Oracle Internet Directoryにおいて、すべてのアイデンティティ管理レルムに対して定義されます。Oracle Internet Directory内のパスワード・ポリシーは標準のOracle Internet Directoryエントリで、Oracle Databaseでエンタープライズ・ユーザー・セキュリティに使用できます。

Oracle Internet Directoryでは、すべてのエンタープライズ・ユーザー・パスワードがレルムに対するパスワード・ポリシー・エントリで指定されたルールと一致していることを確認します。データベースは、エンタープライズ・ユーザーの認証時にOracle Internet Directoryと通信します。Oracle Internet Directoryに対して、パスワード・ポリシー違反をレポートするようにリクエストします。データベースは、Oracle Internet Directoryからポリシー違反レスポンスを受け取ると、適切な警告またはエラー・メッセージをユーザーに表示します。

データベースは次のイベントをレポートします。

- ユーザー・パスワードがまもなく期限切れになる場合に警告を表示し、ユーザーが自分のパスワードを何日以内に変更する必要があるかを表示します。

- パスワードが期限切れになった場合に警告を表示し、残っている猶予期間ログイン数についてユーザーに通知します。

- ユーザー・パスワードが期限切れになり、ユーザーに猶予期間ログインが残っていない場合に、エラーを表示します。

- ログイン試行に繰り返し失敗したためにユーザー・アカウントがロックされた場合に、エラーを表示します。

- ユーザー・アカウントが管理者によって無効にされている場合に、エラーを表示します。

- ユーザー・アカウントが非アクティブである場合に、エラーを表示します。

エンタープライズ・ユーザーのデータベースへのログイン試行により、Oracle Internet Directoryではユーザー・アカウント・ステータスが更新されます。たとえば、データベースへのログイン試行が連続して失敗すると、ディレクトリのパスワード・ポリシーにより、ディレクトリではアカウントがロックされます。

関連項目:
パスワード・ポリシーとその管理の詳細は、『Oracle Internet Directory管理者ガイド』を参照してください。

1.2 エンタープライズ・ユーザー・セキュリティにおける共有スキーマの使用方法

次の各項では、共有スキーマとその設定方法について説明します。

- エンタープライズ・ユーザー・セキュリティで使用される共有スキーマの概要

- エンタープライズ・ユーザーに対して共有スキーマを構成する方法

- エンタープライズ・ユーザーをスキーマにマップする方法

1.2.1 エンタープライズ・ユーザー・セキュリティで使用される共有スキーマの概要

ユーザーには必ずしも各データベースで個別のアカウントとスキーマを設定する必要はありません。そのかわりに、ユーザーは共有スキーマに接続し、ターゲット・アプリケーションに関連付けられたオブジェクトにアクセスすることができます。たとえば、ユーザーのTom、Dick、そしてHarrietが、Financeデータベース上のPayrollアプリケーションにアクセスを要求したと想定します。ユーザーはデータベース内に一意のオブジェクトを作成する必要がなく、そのため、自分自身のスキーマを必要としませんが、Payrollスキーマ内のオブジェクトにアクセスする必要があります。

Oracle Databaseでは、エンタープライズ・ディレクトリに格納されている複数のユーザーを個々のデータベース上の共有スキーマにマップできます。このようにユーザーとスキーマを分離すると、データベース上のユーザー・アカウント数が減るため、管理コストが削減されます。つまり、ディレクトリ内でのユーザーの作成に加えて各ユーザー(ユーザー・スキーマ)のアカウントを作成する必要はありません。かわりに、エンタープライズ・ディレクトリにユーザーを作成し、そのユーザーを共有スキーマにマップできます。他のエンタープライズ・ユーザーをそのスキーマにマップすることもできます。

たとえば、Tom、DickおよびHarriet全員が売上データベースと財務データベースの両方にアクセスする場合は、それぞれのデータベースに各ユーザーのアカウントを作成する必要はありません。かわりに、3人のユーザー全員がアクセスできるGUESTなどの単一の共有スキーマを各データベースに作成できます。次に、エンタープライズ・ロールを使用して、売上データベースまたは財務データベース内のオブジェクトへの個々のアクセス権をこの3人のユーザーに付与します。一般的な環境では、最大5,000のエンタープライズ・ユーザーを1つの共有スキーマにマップして、各ユーザーにエンタープライズ・ロールのセットを割り当てることができます。

オブジェクトを含まない別の共有スキーマを作成して、エントリ・ポイントとして使用することをお薦めします。その後、エンタープライズ・ロールを介して他のスキーマのアプリケーション・オブジェクトに対するアクセス権を付与してください。アクセス権をこのように付与しないと、アプリケーション・オブジェクトが不注意または故意に削除または変更される可能性があります。

要約すると、共有スキーマには次の利点があります。

- 共有スキーマによって、各エンタープライズ・ユーザーに対してデータベースごとに専用のデータベース・スキーマを保持する必要がなくなります。

- 各エンタープライズ・ユーザーを、そのユーザーがアクセスする必要がある各データベース上の共有スキーマにマップできます。ユーザーは、データベースへの接続時に共有スキーマに接続します。

- 共有スキーマによって、エンタープライズ内のユーザー管理に必要なコストが削減されます。

1.2.2 エンタープライズ・ユーザーに対して共有スキーマを構成する方法

共有スキーマを構成するには、ローカル・データベース管理者(DBA)がデータベースに1つ以上のデータベース・スキーマを作成する必要があります。エンタープライズ・ユーザーをこのスキーマにマップできます。

次の例では、管理者が共有スキーマを作成し、ユーザーをそのスキーマにマップします。

1. 管理者は、EMPLOYEEというグローバル共有スキーマおよびグローバル・ロールHRMANAGERをHRデータベースに作成します。

2. 管理者は、Oracle Internet Directoryセルフ・サービス・コンソールおよびOracle Enterprise Managerを使用して、ディレクトリでエンタープライズ・ユーザーとロールを作成および管理します。たとえば、管理者は、エンタープライズ・ユーザーHarrietと、MANAGERというエンタープライズ・ロールを作成します。次に、HRデータベース・グローバル・ロールHRMANAGERをエンタープライズ・ロールMANAGERに割り当てます。

3. 管理者は、エンタープライズ・ロールをディレクトリ内のエンタープライズ・ユーザーに割り当てます。たとえば、エンタープライズ・ロールMANAGERをHarrietに割り当てます。

4. 管理者は、Oracle Enterprise Managerを使用して、ディレクトリ内のユーザーHarrietをHRデータベース上の共有スキーマEMPLOYEE にマッピングします。

Harrietは、HRデータベースに接続すると、EMPLOYEEスキーマに自動的に接続され、グローバル・ロールHRMANAGERが付与されます。複数のエンタープライズ・ユーザーを同じ共有スキーマにマップできます。たとえば、エンタープライズ・セキュリティ管理者は、別のエンタープライズ・ユーザーScottを作成し、EMPLOYEEスキーマにマップできます。この場合、HRデータベースに接続すると、HarrietとScottはいずれもEMPLOYEEスキーマを自動的に使用することになりますが、それぞれ異なるロールを持つことができ、個々に監査されます。

関連項目:
監査の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

1.2.3 エンタープライズ・ユーザーをスキーマにマップする方法

グローバル・スキーマ(CREATE USER IDENTIFIED GLOBALLY AS ''で作成されるスキーマ)は、1人のエンタープライズ・ユーザーが所有すること(排他スキーマ)も、複数のエンタープライズ・ユーザーが共有すること(共有スキーマ)もできます。1人のエンタープライズ・ユーザーとその排他スキーマの間のマッピングは、ユーザーDNとスキーマ名の間の関連付けとしてデータベースに格納されます。エンタープライズ・ユーザーと共有スキーマの間のマッピングは、1つ以上のマッピング・オブジェクトを使用してディレクトリ内で行われます。マッピング・オブジェクトは、ユーザーの識別名(DN)を、ユーザーがアクセスするデータベース・スキーマにマップするために使用されます。マッピング・オブジェクトは、Oracle Enterprise Managerを使用して作成します。このマッピングは、次のいずれかです。

- エントリ・レベル(完全DN)マッピング
この方法によって、単一のディレクトリ・ユーザーのDNがデータベース上の特定のスキーマに関連付けられます。その結果、ユーザーごとに1つのマッピング・エントリが作成されます。

- サブツリー・レベル(部分DN)マッピング
この方法によって、複数のエンタープライズ・ユーザーがDNの一部を共有し、同じ共有スキーマにアクセスできます。この方法は、ディレクトリ・ツリー内の共通ルートの下に複数のエンタープライズ・ユーザーがすでにグループ化されている場合に役立ちます。これらのユーザーが共有するサブツリーは、データベース上の共有スキーマにマップできます。たとえば、技術部門のサブツリー内にあるエンタープライズ・ユーザーをすべて、バグ・データベース上の1つの共有スキーマBUG_APP_USERにマップできます。サブツリーのルートは、指定されたスキーマにマップされないことに注意してください。

エンタープライズ・ユーザーがデータベースに接続すると、データベースは、ネットワーク(SSLの場合)またはディレクトリ(パスワード認証およびKerberos認証エンタープライズ・ユーザーの場合)からユーザーのDNを取得します。

ユーザーの接続先となるスキーマを判断するとき、データベースはユーザーDNと次の優先ルールを使用します。

1. ローカル(データベース内)で排他スキーマを探します。

2. ローカルで排他スキーマが見つからない場合は、ディレクトリを探します。ディレクトリ内では、データベース・サーバー・エントリの下で、まずエントリ・レベル・マッピングを探し、次にサブツリー・レベル・マッピングを探します。

3. サーバー・エントリの下でマッピング・エントリが見つからない場合は、エンタープライズ・ドメイン・エントリの下で、まずエントリ・レベル・マッピングを探し、次にサブツリー・レベル・マッピングを探します。

4. ローカルで排他スキーマが見つからない場合またはデータベース内に適切なマッピング・エントリがない場合、データベースは接続を拒否します。それ以外の場合、データベースはユーザーを適切なスキーマに接続します。

たとえば、HarrietがHRデータベースに接続しようとしていて、Harrietの排他スキーマが(データベース内で)見つからないとします。この場合、次のイベントが発生します。

1. HRデータベースは、ディレクトリ内でHarrietのDNでユーザー・スキーマ・マッピングを探します。ディレクトリには、Harrietから共有スキーマEMPLOYEEへのマッピングがあり、このスキーマが返されます。

2. データベースはHarrietのログインを許可し、HarrietをEMPLOYEEスキーマに接続します。

3. データベースは、このデータベースに対するこのユーザーのグローバル・ロールをディレクトリから取得します。

4. また、ユーザーがマップされているデータベース・スキーマに関連付けられているローカル・ロールおよび権限をデータベース独自の表から取得します。

5. データベースは、グローバル・ロールとローカル・ロールの両方を使用して、ユーザーがアクセスできる情報を判断します。

引き続きこの例で、エンタープライズ・ロールMANAGERにHRデータベース上のグローバル・ロールANALYSTと、給与データベース上のUSERが含まれるとします。エンタープライズ・ロールMANAGERを持つHarrietは、HRデータベースに接続するときに、そのデータベース上のスキーマEMPLOYEE を使用します。

- HRデータベースに対する彼女の権限は、次の内容によって判断されます。

- グローバル・ロールANALYST

- HRデータベース上のEMPLOYEE スキーマに関連付けられているローカル・ロールと権限

- Harrietが給与データベースに接続する場合、その権限は次の内容によって判断されます。

- グローバル・ロールUSER

- 給与データベース上のEMPLOYEEスキーマに関連付けられているローカル・ロールと権限

データベース・スキーマにロールおよび権限を付与することにより、指定したユーザー・グループに権限を付与できます。このようなスキーマを共有するすべてのユーザーは、個人のエンタープライズ・ロールに加えてこれらのローカル・ロールおよび権限を取得します。ただし、この共有スキーマにマップされるユーザーはすべて、このスキーマに割り当てられた権限を実行できるため、これを行う場合は十分な注意が必要です。このため、共有スキーマにロールおよび権限を付与することはお薦めしません。

関連項目:

- エンタープライズ・ユーザーの共有スキーマの作成方法は、「タスク1: データベースでのグローバル・スキーマおよびグローバル・ロールの作成」を参照してください。

- 「エンタープライズ・ユーザー・プロキシ」

1.3 エンタープライズ・ユーザー・プロキシ

エンタープライズ・ユーザーは、一時的にターゲット・ユーザーの認可と権限を取得して、別のユーザーとしてデータベースへの接続が必要になる場合があります。この機能は、様々なデータベースに対してエンタープライズ・ユーザーとして動作し、識別情報がOracle Internet Directoryのエントリとして設定されていることが多い中間層のツールまたはアプリケーションに特に役立ちます。このようなアプリケーションは、各エンド・ユーザーの識別情報を切り替えながら単一のデータベース接続を保持できるため、認可された各ユーザーの名前で動作することができます。

エンタープライズ・ユーザー・セキュリティ11gリリース1 (11.1)では、シングル・セッション・モデルの導入によって、プロキシ・メカニズムの効率が強化されています。2セッション・プロキシ・モデルでは、プロキシ・ユーザーとターゲット・ユーザーに別個のセッションを保持する必要がありました。新しいモデルでは、1つのセッションのみがターゲット・ユーザーのセキュリティ・コンテキスト内で保持されます。これにより、パフォーマンスが向上します。

エンタープライズ・ユーザー・セキュリティ11gリリース1 (11.1)以上を使用すると、エンタープライズ・ユーザーにプロキシ権限を細かく割り当てることができます。エンタープライズ・ユーザーには、ローカル・データベース・ユーザーのプロキシとして動作する権限を個別に付与できます。そのため、権限をデータベース内のユーザーの共有スキーマに関連付ける必要はありません。

エンタープライズ・ユーザーに個別にプロキシ権限を割当てできるということは、権限をより厳密に設定できることを意味します。それに対して、共有スキーマに権限を割り当てる場合は、スキーマにマップするすべてのユーザーに同じ権限を割り当てることになります。これによって、保証されていない権限が付与される可能性があります。

エンタープライズ・ユーザーのプロキシ権限は、Oracle Internet Directoryで作成および格納されます。1つの権限で、1つ以上のエンタープライズ・ユーザーまたはグループをターゲット・データベース・ユーザーのプロキシとして設定できます。権限は、エンタープライズ・ドメイン内の特定のデータベースまたはすべてのデータベースに適用できます。

デフォルトでは、ドメイン管理者はエンタープライズ・ドメインのディレクトリでプロキシ権限を管理できます。これらの権限は、Oracle Enterprise Managerを使用して構成および管理されます。

関連項目:
エンタープライズ・ユーザーのプロキシ権限の構成方法は、「プロキシ権限の構成」を参照してください。

このようなプロキシを設定するには、次の手順に従います。

1. 様々なデータベースに対するプロキシ権限が必要なすべてのエンタープライズ・ユーザーを特定します。

2. 対象となる各データベース内のターゲット・ユーザーをすべて特定します。

3. 対象となるターゲット・ユーザーごとに、次の形式でALTER USERコマンドを発行します。

- ALTER USER target_user GRANT CONNECT THROUGH ENTERPRISE USERS

これにより、Oracle Internet Directoryでプロキシ権限を持つエンタープライズ・ユーザーが、target_userのプロキシとして動作できるようになります。プロキシ権限を取り消す場合は、同じ構文を使用し、GRANTをREVOKEで置き換えます。

関連項目:
完全なALTER USER構文は、『Oracle Database SQL言語リファレンス』を参照してください。
Oracle Call Interfaceの使用方法は、『Oracle Call Interfaceプログラマーズ・ガイド』を参照してください。

4. 各エンタープライズ・ユーザーに個別に、またはグループのメンバーとして、プロキシ権限を付与します。詳細は、「エンタープライズ・ユーザーへのプロキシ権限の付与」を参照してください。

注意:
同じデータベース・ユーザーのプロキシとして動作するエンタープライズ・ユーザーを表すグループを設定するには、Oracle Delegated Administration Servicesを使用します(『Oracle Identity Management委任管理ガイド』を参照)。

5. 前述の4つの手順をすべて完了すると、特定したエンタープライズ・ユーザーを、特定して関連付けたすべてのローカル・データベース・ユーザーのプロキシとして設定できます。2つのバージョンのCONNECTコマンドを使用できます。(a)では、エンタープライズ・ユーザーのパスワードをコマンド内に入力しています。(b)では、パスワードを入力するかわりに、sqlnet.oraファイルに指定されている場所にあるウォレットが保持するパスワードを使用しています。

1. エンタープライズ・ユーザーのプロキシ接続をデータベース・ユーザーとして確立するには、次のSQL*Plusコマンド構文を使用し、エンタープライズ・ユーザーのパスワードを指定します。

- CONNECT joeproxy[targetuser]@database_service_name
Enter Password:

ここで、joeproxyをtargetuserとしてプロキシするエンタープライズ・ユーザーの名前に、targetuserをターゲット・データベースの登録ユーザーの名前にそれぞれ置き換えます。大カッコは必須です。パスワードの入力を求められたら、エンタープライズ・ユーザーのパスワードを入力します。

これらのIDが検証されると、この接続要求によって単一のセッションが生成され、このセッションでプロキシ・ユーザーはターゲット・データベースでターゲット・ユーザーとして動作します。元のユーザーのIDは、そのデータベースに対して保持されるため、監査レコードはプロキシ・ユーザーとターゲット・ユーザーの両方のIDを取得できます。

2. パスワードを指定せずに、データベース・ユーザーに対するエンタープライズ・ユーザー・プロキシとして接続する場合は、sqlnet.oraファイルにそのユーザーのパスワードを保持するウォレットの場所が指定されていることを確認します。確認後、次のコマンド構文を使用します。

- CONNECT  [targetuser]/@database_service_name

ここで、targetuserをターゲット・データベースの登録ユーザーの名前に置き換えます。大カッコは必須です。現行のエンタープライズ・ユーザーがtargetuserのプロキシとなります。

注意:
OCIコールを使用する通常のプロキシ・ログイン・メカニズムも使用できます。CONNECT構文は、新しい代替構文です。OCIコール・メカニズムの詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

エンタープライズ・ユーザーのプロキシ権限はOracle Internet Directoryで割り当てられますが、データベース管理者は、エンタープライズ・ユーザーのプロキシ・ターゲットとして使用できるローカル・アカウントを決定できます。エンタープライズ・ドメイン管理者は、データベースのdba_proxiesビューで使用可能なターゲットに対してのみプロキシ権限を割り当てることができます。

1.4 エンタープライズ・ユーザー・セキュリティにおける現行ユーザーのデータベース・リンクの使用方法

Oracle Databaseは、SSL認証ネットワーク接続を介して現行ユーザーのデータベース・リンクをサポートします。現行ユーザーのデータベース・リンクを使用すると、ユーザー自身として、または別のユーザーが所有するストアド・プロシージャ内から使用される場合はそのユーザーとして、2つ目のデータベースに接続できます。このようなアクセスは、プロシージャの範囲内に制限されます。現行ユーザーのデータベース・リンクのセキュリティ上の利点は、別のユーザーの資格証明がデータベース・リンク定義に格納されず、データベース間のネットワーク接続を介して送信されないことです。かわりに、これらのリンクのセキュリティは、データベース間の相互信頼、相互認証およびセキュアなネットワーク接続に基づいています。

たとえば、現行ユーザーのデータベース・リンクをプロシージャ内から使用すると、財務データベースのユーザーであるHarrietは、エンタープライズ・ユーザーScottとして接続することによって買掛管理データベースにアクセスできます。

Harrietが現行ユーザーのデータベース・リンクにアクセスしてスキーマScottに接続するには、Scottが両方のデータベースで(IDENTIFIED GLOBALLYとして作成される)グローバル・スキーマであることが必要です。ただし、Harrietは、次の3つの方法のいずれかで識別されるユーザーとなります。

- パスワード

- GLOBALLY

- EXTERNALLY

1つ目の財務データベースでScottをグローバル・ユーザーとして作成するには、次のように入力する必要があります。

CREATE USER Scott IDENTIFIED GLOBALLY as 'CN=Scott,O=nmt'

これにより、Scottは排他スキーマを持つことができます。そして、Scottは2つ目の買掛管理データベース内の共有スキーマにマップできます。現行ユーザーのデータベース・リンクが機能するために、1つ目のデータベースでScott用に作成されたスキーマを他のユーザーと共有することはできません。

現行ユーザーのデータベース・リンクは、1つのエンタープライズ・ドメイン内の信頼できるデータベース間でのみ機能します。ドメイン内のデータベースは相互に信頼してユーザーを認証します。信頼できるエンタープライズ・ドメインを指定するには、Oracle Enterprise Managerを使用します。Oracle Enterprise Managerを使用して現行ユーザーのデータベース・リンクをドメインに対して有効にすると、それらのリンクはそのドメイン内のすべてのデータベースに対して動作します。ただし、ドメイン内の各データベースは独自のPKI資格証明を持ち、SSLを使用して他のデータベースに対して認証されます。信頼できるエンタープライズ・ドメインの一部であるデータベースを信頼できないものとして指定するには、PL/SQLパッケージDBMS_DISTRIBUTED_TRUST_ADMINを使用します。信頼できるサーバーのリストを取得するには、TRUSTED_SERVERSビューを使用します。

注意:
Oracle Database Enterprise EditionのオプションであるOracle Advanced Securityでは、データベース・リンクを介したRADIUS認証をサポートしていません。

関連項目:

- 「信頼できるデータベースとは」

- 現行ユーザーのデータベース・リンクの詳細は、Oracle Database Heterogeneous Connectivityユーザーズ・ガイドを参照してください。

- SQL構文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- PL/SQLパッケージDBMS_DISTRIBUTED_TRUST_ADMINの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

- TRUSTED_SERVERSビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

- Oracle Netに対するSSLの構成の詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

- ウォレットの作成方法は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

1.5 エンタープライズ・ユーザー・セキュリティのデプロイの考慮事項

エンタープライズ・ユーザー・セキュリティをデプロイする前に、次の点について検討します。

- セキュリティ資格証明の一元化におけるセキュリティ

- パスワード認証エンタープライズ・ユーザーのデータベース・ログイン情報のセキュリティ

- エンタープライズ・ドメインでのデータベース・メンバーシップの定義に関する考慮事項

- エンタープライズ・ユーザー・セキュリティのクライアント、データベースおよびディレクトリ間の認証タイプの選択

1.5.1 セキュリティ資格証明の一元化におけるセキュリティ

エンタープライズ・ユーザーとそれに関連付けられた資格証明の一元管理には一般的な利点がありますが、検討が必要なセキュリティ関連の利点と危険性もたくさんあります。

1.5.1.1 一元化されたセキュリティ資格証明管理に関連するセキュリティ上の利点

管理を一元化すると、ユーザー、資格証明およびロールの管理が簡単かつ迅速になり、エンタープライズ全体のすべてのアプリケーションおよびデータベースに対するユーザーの権限を迅速に取り消すことができます。一元管理を行うと、管理者は1箇所でユーザーを削除してすべてのグローバル権限を取り消すことができるため、不要な権限が保持される危険性を最小限に抑えることができます。

管理を集中化することにより、組織のセキュリティに関する専門技術を集約することができます。専門のセキュリティー意識の高い管理者が、ディレクトリ・セキュリティ、ユーザーのロールおよび権限、データベース・アクセスなど、エンタープライズ・ユーザー・セキュリティのあらゆる面を管理することができます。これは、DBAが管理するデータベースのセキュリティを含むすべてを担当する従来のモデルと比較すると、大きな進歩です。

1.5.1.2 一元化されたセキュリティ資格証明管理に関連するセキュリティ上の危険性

Oracle Internet Directoryはセキュアなリポジトリですが、パブリックからアクセス可能なリポジトリで資格証明を一元管理する場合には、セキュリティ上の問題と固有のリスクがあります。一元化された資格証明は、少なくとも分散された資格証明と同程度には保護できますが、一元化の性質により、認可されていない第三者に資格証明が誤って公開される可能性が高まります。したがって、管理者の権限を制限し、ディレクトリ内に制限されたアクセス制御リスト(ACL)を設定するとともに、管理者が一時的にディレクトリから離れる場合にセキュリティ資格証明を保護する適切なセキュリティ・プラクティスを実装することが不可欠です。

1.5.2 パスワード認証エンタープライズ・ユーザーのデータベース・ログイン情報のセキュリティ

すべてのセキュア・パスワードベース認証方式では、サーバーは、パスワード・ベリファイアでクライアントを認証します。パスワード・ベリファイアは、通常は厳重に保護する必要のあるパスワードのハッシュ・バージョンです Oracleデータベースでのパスワード・ベースの認証もこれと同じです。パスワード・ベリファイアが用意されており、同様に保護する必要があります。これは、ベリファイアがデータベース内にローカルに格納されている場合、またはディレクトリで集中管理されている場合のどちらにも当てはまります。パスワード・ベリファイアを使用して、元のパスワードを取得することはできません。

エンタープライズ・ユーザーのデータベース・パスワードを中央ディレクトリ・サービスに格納して、複数のデータベースからアクセスすることができます。ユーザーがアクセス権を持つすべての信頼できるデータベースは、パスワードを参照し、共有することができます。ディレクトリに格納されたパスワードはクリア・テキスト・パスワードではありませんが、それでも略式あるいは不正なアクセスから保護する必要があります。そのため、必要なアクセス権と操作性を確保した上で、できるかぎり制限の厳しいパスワード関連のACLをディレクトリに定義することは、非常に重要です。(Oracle Databaseは、Oracle Internet Directoryがサポートするすべてのベリファイア・タイプをサポートしていることに注意してください。)

Oracleのツール製品を使用して、アイデンティティ管理レルムの作成時にこれらのパスワード検証を保護するためのACLをディレクトリに設定できます。お薦めする方式は、セキュリティと操作性の各考慮事項のバランスをとることを目的としています。最大限のセキュリティが必要であり、すべてのユーザーにウォレットを設定できる場合は、ユーザーからデータベースへの接続にSSLのみを使用します。SSLのみの方式を使用すると、ディレクトリ・パスワードの保護問題をそっくり回避することができます。

次の各項では、信頼できるデータベースについて、およびディレクトリ内でデータベース・パスワード検証を保護する方法について説明します。

1.5.2.1 信頼できるデータベースとは

SSLでは、厳密認証が行われるため、データベースでは相互の識別情報が確認されます。パスワード認証を使用するエンタープライズ・ユーザー・セキュリティでは、データベース・パスワード検証がディレクトリに一元的に格納され、複数のデータベース間で共有されますが、パスワード認証エンタープライズ・ユーザーにログインを許可する各データベースは信頼できるデータベースである必要があります。各データベースは共有パスワード検証にアクセスできるため、次のセキュリティ対策を順守する信頼できるデータベースであることが重要です。

- 各データベースは、サーバー・コードの改ざんからデータベース自体を保護する信頼できるデータベースであることが必要です。これにより、悪意のあるユーザーがデータベースの識別情報を悪用してディレクトリ内のパスワード検証にアクセスできなくなります。

- 各データベースは、データベース自体のPKIおよびその他の資格証明を盗用から保護する信頼できるデータベースであることが必要です。これにより、悪意のあるユーザーがPKIやその他の資格証明を使用してディレクトリに格納されているパスワード検証にアクセスできなくなります。

1.5.2.2 データベース・パスワード検証の保護

各アイデンティティ管理レルム内のOraclePasswordAccessibleDomainsグループは、レルムの作成時に自動的に作成され、Oracle Internet Directoryセルフ・サービス・コンソールなどのOracle Internet Directoryツールを使用して管理できます。このグループには、ディレクトリに格納されているユーザーのデータベース・パスワード検証を参照する必要があるメンバー・データベースを含むエンタープライズ・ドメインが配置されます。

選択したレルムに対して、パスワード認証接続を受け入れるデータベースを決定します。Oracle Internet Directoryセルフ・サービス・コンソールを使用して、これらのデータベースを含むドメインをOraclePasswordAccessibleDomainsグループに配置します。ユーザー・サブツリーのACLにより、データベースで使用するパスワード検証を保持するディレクトリ属性へのアクセスが許可されます。

他のすべてのユーザーは、この属性へのアクセスを拒否されます。パスワード検証の属性への匿名読取りアクセスを防止するACLは、ディレクトリ・ツリーのルートにあります。

操作性を考慮し、デフォルトでは、OracleDefaultDomainはOraclePasswordAccessibleDomainsグループのメンバーとなります。これは必要に応じて削除できます。

1.5.3 エンタープライズ・ドメインでのデータベース・メンバーシップの定義に関する考慮事項

ドメインのデータベース・メンバーシップを定義する場合は、次の基準を考慮します。

- 現行ユーザーのデータベース・リンクは、1つのエンタープライズ・ドメイン内のデータベース間でのみ機能します。これらのリンクを使用するには、これらのデータベース間およびこれらを管理するDBA間に相互信頼が必要です。

- エンタープライズ・ユーザーに適用される認証タイプは、ドメイン・レベルで定義されます。したがって、ドメイン内のデータベース・メンバーシップはそのタイプに応じて定義する必要があります。

注意:
1つ以上のデータベースでSSLベースの証明書認証のみをサポートする場合、それらのデータベースを同じドメイン内でパスワード認証のデータベースと組み合せることはできません。

- エンタープライズ・ロールはドメイン・レベルで定義されます。複数のデータベース間でエンタープライズ・ロールを共有するには、データベースが同じドメインのメンバーであることが必要です。

1.5.4 エンタープライズ・ユーザー・セキュリティのクライアント、データベースおよびディレクトリ間の認証タイプの選択

エンタープライズ・ユーザー・セキュリティでは、クライアント、データベースおよびディレクトリ間の接続に対して、表1-3に示す認証タイプをサポートしています。

表1-3 エンタープライズ・ユーザー・セキュリティ: クライアント、データベースおよびディレクトリ間の接続に対してサポートされる認証タイプ

接続

サポートされる認証タイプ

クライアントとデータベース間

パスワード、SSLおよびKerberos

データベース間(現行ユーザーのデータベース・リンク)

SSLのみ

データベースとディレクトリ間

SSLおよびパスワード

ただし、接続に対する認証タイプの組合せの中には、他の組合せに比べて妥当なものもあります。たとえば、すべてのユーザー接続に対してSSLを使用し、クライアントとデータベース間の接続に高レベルのセキュリティを設定しながら、ディレクトリに対する認証にパスワードを使用するようにデータベースを構成することは、通常ありません。この構成はサポートされますが、接続に一貫性のあるセキュリティは提供されません。データベースとディレクトリ間の接続には、ユーザーとデータベース間の接続と同じレベル以上の安全性を持たせることが理想的です。

1.5.4.1 標準構成

クライアント、データベースおよびディレクトリ間で使用する認証タイプの一般的な組合せは、次のとおりです。

- 現行ユーザーのデータベース・リンクを必要としないすべての接続に対してパスワード認証を使用します。

- すべての接続に対してSSL認証を使用します。

- クライアントとデータベース間の接続にはKerberos認証を使用し、データベースとディレクトリ間の接続にはパスワード認証を使用します。

2 エンタープライズ・ユーザー・セキュリティの準備

エンタープライズ・ユーザー・セキュリティを使用すると、エンタープライズ全体でデータベース・ユーザーを一元的に管理できます。エンタープライズ・ユーザーは、Oracle Internet Directoryに作成され、ディレクトリに登録された様々なエンタープライズ・データベースに対するロールや権限を割り当てることができます。

この章では、エンタープライズ・ユーザー・セキュリティを簡単に使用できるようにチュートリアル方式を採用します。次の各手順では、エンタープライズ・ユーザー・セキュリティの構成について説明します。

1. ディレクトリを使用するためのデータベースの構成

2. ディレクトリへのデータベースの登録

3. データベースでの共有スキーマの作成

4. 共有スキーマへのエンタープライズ・ユーザーのマッピング

5. エンタープライズ・ユーザーとしてのデータベースへの接続

6. エンタープライズ・ロールの使用

7. プロキシ権限の使用

2.1 ディレクトリを使用するためのデータベースの構成

エンタープライズ・ユーザー・セキュリティの構成の第1ステップは、ディレクトリを使用するようにデータベースを構成することです。Net Configuration Assistant (NetCA)ツールを実行すると、データベースで使用する必要があるディレクトリのホスト名およびポートを構成できます。

ディレクトリを使用するようにデータベースを構成する手順:

1. netcaコマンドを使用してNetCAを起動します。

- Windowsでは、「スタート」メニューからNetCAを起動することもできます。
「スタート」→「すべてのプログラム」→「Oracle - OracleHomeName」→「Configuration and Migration Tools」→「Net Configuration Assistant」の順にクリックします。

- UNIXシステムでは、次のコマンドを使用してNetCAを起動できます。
$ORACLE_HOME/bin/netca

「ようこそ」画面が表示されます。

2. 「ディレクトリ使用構成」を選択します。「次へ」をクリックします。
「ディレクトリ・タイプ」画面が表示されます。

3. 「次へ」をクリックします。
ディレクトリの場所画面が表示されます。

4. Oracle Internet Directoryサーバーが稼働しているホストの名前を入力します。また、LDAPの非SSLポート番号およびSSLポート番号も入力します。これらのポート番号のデフォルトは389および636です。「次へ」をクリックします。
Oracleコンテキストの選択画面が表示されます。

5. 使用するデフォルトのOracleコンテキストを選択します。ディレクトリ・サーバーに複数のアイデンティティ管理レルムがある場合は、これを選択する必要があります。「次へ」をクリックします。
「ディレクトリ使用構成-完了」画面が表示されます。

6. ディレクトリ使用構成が正常に完了したことを確認します。「次へ」をクリックします。

7. 「終了」をクリックします。
ldap.oraファイルが$ORACLE_HOME/network/adminディレクトリに作成されます。Windowsでは、このディレクトリは$ORACLE_HOME\network\adminディレクトリです。ldap.oraファイルには、ディレクトリに関する接続情報の詳細が格納されます。

2.2 ディレクトリへのデータベースの登録

次のステップは、データベースをディレクトリ・サービスに登録することです。Database Configuration Assistant (DBCA)ツールを使用すると、データベースをOracle Internet Directoryに登録できます。

データベースをディレクトリに登録する手順:

1. dbcaコマンドを使用してDBCAを起動します。

- Windowsでは、「スタート」メニューからDBCAを起動することもできます。
「スタート」→「すべてのプログラム」→「Oracle - OracleHomeName」→「Configuration and Migration Tools」→「Database Configuration Assistant」の順にクリックします。

- UNIXシステムでは、次のコマンドを使用してDBCAを起動できます。
$ORACLE_HOME/bin/dbca

「ようこそ」画面が表示されます。

2. 「次へ」をクリックします。
「操作」画面が表示されます。

3. 「データベース・オプションの構成」を選択します。「次へ」をクリックします。
「データベース」画面が表示されます。

4. 構成するデータベース名を選択します。オペレーティング・システムの認証を使用していない場合は、SYSユーザー資格証明の入力を求められることもあります。「次へ」をクリックします。
「管理オプション」画面が表示されます。

5. Database Controlを使用してデータベースの管理を続行する場合は、「Database Controlで構成済のデータベースを維持」を選択します。また、Grid Controlを使用したデータベースの管理を選択することもできます。「次へ」をクリックします。
「セキュリティ設定」画面が表示されます。

6. 11gのセキュリティ設定を維持する場合は、「11gのデフォルトの高度セキュリティ設定を維持」を選択します。「次へ」をクリックします。
「ネットワーク構成」画面が表示されます。

7. 「データベースを登録する」を選択してデータベースをディレクトリに登録します。Oracle Internet Directoryへのデータベースの登録を許可されたユーザーの識別名(DN)を入力します。また、ディレクトリ・ユーザーのパスワードも入力します。ウォレット・パスワードを入力します。「パスワードの確認」フィールドに、同じパスワードを再入力します。「次へ」をクリックします。

注意:
データベースでは、ランダムに生成されたパスワードを使用してディレクトリにログインします。このデータベース・パスワードは、Oracleウォレットに格納されます。また、このウォレットを使用して、SSL接続に必要な証明書を格納することもできます。
指定するウォレット・パスワードは、データベース・パスワードとは異なります。ウォレット・パスワードは、ウォレットの保護に使用します。

「データベース・コンポーネント」画面が表示されます。

8. 「次へ」をクリックします。
「接続モード」ページが表示されます。

9. 「専用サーバー・モード」または「共有サーバー・モード」を選択します。「終了」をクリックします。
「確認」ダイアログ・ボックスが表示されます。

10. 「OK」をクリックします。

注意:
データベースをディレクトリに登録した後に、データベース・ウォレットの自動ログインが有効になっていることを確認します。デフォルトのウォレットは、$ORACLE_BASE/admin/database_sid/walletディレクトリに作成されます。
ウォレット・ディレクトリにcwallet.ssoファイルが存在することをチェックすることで、ウォレットに対する自動ログインが有効であることを確認できます。このファイルが存在しない場合は、Oracle Wallet Managerを使用してウォレットを開き、ウォレットに対する自動ログインを有効にするオプションを使用して、自動ログインを有効にできます。

2.3 データベースでの共有スキーマの作成

データベースに共有スキーマを作成すると、複数のエンタープライズ・ユーザーを同じスキーマにマップできます。例2-1では、共有スキーマglobal_ident_schema_userを作成し、CONNECTロールを付与します。

例2-1 共有スキーマの作成

SQL> CREATE USER global_ident_schema_user IDENTIFIED GLOBALLY;
User created.
SQL> GRANT CONNECT TO global_ident_schema_user;
Grant succeeded.

2.4 共有スキーマへのエンタープライズ・ユーザーのマッピング

エンタープライズ・ユーザー・セキュリティは、Enterprise Managerを使用して管理できます。例2-2では、DN cn=users, dc=us, dc=oracle, dc=comを共有データベース・スキーマglobal_ident_schema_userにマップします。

例2-2 共有スキーマへのエンタープライズ・ユーザーのマッピング

ユーザー・スキーマ・マッピングを作成するには、次のようにします。

1. Enterprise Managerにログインします。

2. 「サーバー」タブをクリックします。「セキュリティ」セクションで「エンタープライズ・ユーザー・セキュリティ」をクリックします。
「Oracle Internet Directoryログイン」ページが表示されます。

3. 「ユーザー」フィールドに、エンタープライズ・ユーザーを管理できるディレクトリ・ユーザーの識別名(DN)を入力します。「パスワード」フィールドに、ユーザー・パスワードを入力します。「ログイン」をクリックします。
「エンタープライズ・ユーザー・セキュリティ」ページが表示されます。

4. 「エンタープライズ・ドメインの管理」をクリックします。
「エンタープライズ・ドメインの管理」ページが表示されます。

5. データベースを含むエンタープライズ・ドメインを選択します。「構成」をクリックします。
「ドメインの構成」ページが表示されます。

6. 「ユーザー・スキーマ・マッピング」タブをクリックします。エンタープライズ・ドメインに適用されているユーザー・スキーマ・マップがすべて表示されます。

7. 「作成」をクリックします。
「マッピングの作成」ページが表示されます。

8. 「自」セクションで、「サブツリー」を選択します。「検索」アイコンをクリックします。DNのcn=Users, dc=us,dc=oracle,dc=comを選択します。

9. 「至」セクションで、「スキーマ」フィールドにglobal_ident_schema_userと入力します。「続行」をクリックします。
「ドメインの構成」ページにユーザー・スキーマ・マッピングが追加されます。

10. 「OK」をクリックします。

2.5 エンタープライズ・ユーザーとしてのデータベースへの接続

この時点で、マップされたOracle Internet Directoryサブツリー内のすべてのユーザーは、エンタープライズ・ユーザーとしてデータベースに接続できます。例2-3に、データベースに接続するcn=orcladmin, cn=users, dc=us,dc=oracle,dc=comユーザーを示します。

例2-3 エンタープライズ・ユーザーとしてのデータベースへの接続

SQL> CONNECT orcladmin
Enter password:
Connected.

2.6 エンタープライズ・ロールの使用

エンタープライズ・ロールはディレクトリに作成されます。エンタープライズ・ロールには、エンタープライズ・ドメインに属する様々なデータベースのグローバル・ロールが格納されます。エンタープライズ・ロールは、エンタープライズ・ユーザーにデータベース権限を割り当てるために使用します。

例2-4では、2人のエンタープライズ・ユーザーのJoeとNinaを作成します。この2人のユーザーはいずれもサブツリーcn=Users, dc=us,dc=oracle,dc=comに作成されます。このサブツリーはすでにEUSDBデータベースのglobal_ident_schema_userにマップされています。

NinaはHRマネージャです。EUSDBデータベースのhr.employees表に対するSELECT権限を必要とします。例2-4では、エンタープライズ・ロールを使用してこれを実現します。

例2-4 エンタープライズ・ロールの使用

2人のエンタープライズ・ユーザーのJoeとNinaの作成から始めます。エンタープライズ・ユーザーは、Oracle Internet Directoryセルフ・サービス・コンソールを使用して作成できます。

エンタープライズ・ユーザーのJoeとNinaを作成する手順:

1. Oracle Internet Directoryセルフ・サービス・コンソールに接続します。次のURLを使用します。
http://hostname:port/oiddas/

hostnameは、Oracle Internet Directoryサーバーが稼働しているホストの名前です。port番号は、Oracle Internet Directoryセルフ・サービス・コンソールが稼働しているTCPポート番号です。デフォルトは7777です。

2. 「ディレクトリ」タブをクリックします。
「サインイン」ページが表示されます。

3. Oracle Internet Directoryにユーザーを作成できるユーザーとしてログインします。
「ユーザー」ページが表示されます。

4. 「作成」をクリックします。
「ユーザーの作成」ページが表示されます。

5. 「ユーザー名」にjoeと入力します。その他の必須フィールドに値を入力します。「有効」で「有効」を選択します。

6. 「送信」をクリックします。

7. 「別のユーザーの作成」をクリックします。
「ユーザーの作成」ページが表示されます。

8. 「ユーザー名」にNinaと入力します。その他の必須フィールドに値を入力します。「有効」で「有効」を選択します。

9. 「送信」をクリックします。「OK」をクリックします。

次に、hr.employees表へのアクセスを許可するグローバル・ロールをデータベースに作成します。次のSQL*Plus文は、グローバル・ロールhr_accessを作成し、必要な権限を付与します。

SQL> CREATE ROLE hr_access IDENTIFIED GLOBALLY;
Role created.
SQL> GRANT SELECT ON hr.employees TO hr_access;
Grant succeeded.

次にhr_accessというエンタープライズ・ロールを作成し、グローバル・ロールを割り当てます。そして、このエンタープライズ・ロールをエンタープライズ・ユーザーNinaに割り当てます。エンタープライズ・ロールは、Enterprise Managerを使用して作成できます。

エンタープライズ・ロールhr_accessを作成する手順:

1. Enterprise Managerにログインします。

2. 「サーバー」タブをクリックします。「セキュリティ」セクションで「エンタープライズ・ユーザー・セキュリティ」をクリックします。
「Oracle Internet Directoryログイン」ページが表示されます。

3. 「ユーザー」フィールドに、エンタープライズ・ユーザーを管理できるディレクトリ・ユーザーの識別名(DN)を入力します。「パスワード」フィールドに、ユーザー・パスワードを入力します。「ログイン」をクリックします。
「エンタープライズ・ユーザー・セキュリティ」ページが表示されます。

4. 「エンタープライズ・ドメインの管理」をクリックします。
「エンタープライズ・ドメインの管理」ページが表示されます。このページには、アイデンティティ管理レルム内のエンタープライズ・ドメインが一覧表示されます。

5. データベースを含むエンタープライズ・ドメインを選択します。「構成」をクリックします。
「ドメインの構成」ページが表示されます。

6. 「エンタープライズ・ロール」タブをクリックします。

7. 「作成」をクリックします。
「エンタープライズ・ロールの作成」ページが表示されます。

8. 「名前」フィールドにhr_accessと入力します。

9. 「追加」をクリックし、データベース・グローバル・ロールをエンタープライズ・ロールに追加します。
「検索と選択: データベース・グローバル・ロール」ウィンドウが表示されます。

10. データベースのhr_accessグローバル・ロールを選択します。「選択」をクリックします。

注意:
グローバル・ロールを選択するには、データベースにログインする必要があります。

11. 「権限受領者」タブをクリックします。「追加」をクリックします。
「選択: ユーザーまたはグループ」ウィンドウが表示されます。

12. ユーザーNinaを選択します。「選択」をクリックします。

13. 「エンタープライズ・ロールの作成」ページで「続行」をクリックします。

14. 「ドメインの構成」ページで「OK」をクリックします。

これで、エンタープライズ・ユーザーNinaは、データベースのhr.employees表にアクセスできます。次のSQL*Plus文は、そのことを示しています。

SQL> CONNECT Nina
Enter password:
Connected.
SQL> SELECT employee_id FROM hr.employees;
EMPLOYEE_ID
-----------
100
101
102
...
...
107 rows selected.

エンタープライズ・ユーザーJoeは、エンタープライズ・ロールが割り当てられていないため、hr.employees表にアクセスできません。

SQL> CONNECT joe
Enter password:
Connected.
SQL> SELECT employee_id FROM hr.employees;
SELECT employee_id FROM hr.employees

ERROR at line 1:
ORA-00942: table or view does not exist

2.7 プロキシ権限の使用

プロキシ権限はエンタープライズ・ドメイン・レベルで作成されます。プロキシ権限により、エンタープライズ・ユーザーはローカル・データベース・ユーザーの代わりとなることができます。つまり、エンタープライズ・ユーザーはローカル・データベース・ユーザーとしてデータベースにログインできます。プロキシ権限は、個々のエンタープライズ・ユーザーまたはグループに付与できます。プロキシ権限は、複数のデータベース間でエンタープライズ・ユーザーとして動作する中間層アプリケーションでは特に有用です。

例2-5に、プロキシ権限の使用を示します。エンタープライズ・ユーザーjoeは販売マネージャであり、ターゲット・データベース・ユーザーSHとしてエンタープライズ・データベースにログインする必要があります。SHユーザーは、販売履歴関連の表を含むSHサンプル・スキーマを所有しています。

例2-5 プロキシ権限の使用

エンタープライズ・ユーザー・プロキシの許可の第1ステップは、ターゲット・データベース・ユーザーを変更(ALTER)し、エンタープライズ・ユーザーによって接続(CONNECT)できるようにすることです。次のSQL文は、SHデータベース・アカウントをロック解除してパスワードを設定し、エンタープライズ・ユーザー・プロキシを使用できるようにアカウントを変更(ALTER)します。

SQL> CONNECT SYSTEM
Enter password:
Connected.
SQL> ALTER USER SH IDENTIFIED BY hrd2guess ACCOUNT UNLOCK;
User altered.
SQL> ALTER USER SH GRANT CONNECT THROUGH ENTERPRISE USERS;
User altered.

次に、Enterprise Managerを使用してプロキシ権限を構成します。これにより、エンタープライズ・ユーザーjoeは、ローカル・データベース・ユーザーSHとして接続できます。

エンタープライズ・ユーザーjoeのプロキシ権限を構成する手順:

1. Enterprise Managerにログインします。

2. 「サーバー」タブをクリックします。「セキュリティ」セクションで「エンタープライズ・ユーザー・セキュリティ」をクリックします。
「Oracle Internet Directoryログイン」ページが表示されます。

3. 「ユーザー」フィールドに、エンタープライズ・ユーザーを管理できるディレクトリ・ユーザーの識別名(DN)を入力します。「パスワード」フィールドに、ユーザー・パスワードを入力します。「ログイン」をクリックします。
「エンタープライズ・ユーザー・セキュリティ」ページが表示されます。

4. 「エンタープライズ・ドメインの管理」をクリックします。
「エンタープライズ・ドメインの管理」ページが表示されます。このページには、アイデンティティ管理レルム内のエンタープライズ・ドメインが一覧表示されます。

5. 構成するエンタープライズ・ドメインを選択します。「構成」をクリックします。
「ドメインの構成」ページが表示されます。

6. 「プロキシ権限」タブをクリックします。

7. 「作成」をクリックして新しいプロキシ権限を作成します。
「プロキシ権限の作成」ページが表示されます。

8. 「名前」フィールドに、プロキシ権限の名前としてSH_Proxyと入力します。

9. 「ターゲットDBユーザー」タブが選択されていることを確認します。「追加」をクリックします。
「検索と選択」ウィンドウが表示されます。

10. SHユーザーを含むデータベースにログインします。エンタープライズ・ユーザー・プロキシを許可するように変更されているすべてのデータベース・ユーザーのリストが表示されます。

11. SHユーザーを選択します。「選択」をクリックします。
「プロキシ権限の作成」ページの「ターゲットDBユーザー」にSHユーザーが追加されます。

12. 「権限受領者」タブをクリックします。

13. 「追加」をクリックします。
「選択: ユーザーまたはグループ」ウィンドウが表示されます。

14. 「検索ベース」で「cn=users,dc=us,dc=oracle,dc=com」を選択します。「表示」で「ユーザー」を選択します。「実行」をクリックします。
サブツリーcn=users,dc=us,dc=oracle,dc=comの下のユーザーのリストが表示されます。

15. cn=joe,cn=users,dc=us,dc=oracle,dc=comを選択します。「選択」をクリックします。
「プロキシ権限の作成」ページの「権限受領者」にユーザーjoeが追加されます。

16. 「プロキシ権限の作成」ページで「続行」をクリックします。
「ドメインの構成」ページにプロキシ権限SH_Proxyが追加されます。

17. 「OK」をクリックします。

これで、エンタープライズ・ユーザーjoeは、ローカル・データベース・ユーザーSHとしてログインできます。次のSQL文は、そのことを示しています。

SQL> REMARK Joe uses his own password to connect as the local database user, SH.
SQL> CONNECT joe[SH]
Enter password:
Connected.
SQL> SELECT * FROM SH.sales WHERE cust_id=4;

PROD_ID    CUST_ID TIME_ID   CHANNEL_ID   PROMO_ID QUANTITY_SOLD AMOUNT_SOLD
---------- ---------- --------- ---------- ---------- ------------- -----------
37          4 31-MAY-00          3        999             1       60.43
39          4 31-MAY-00          3        999             1       38.45
40          4 31-MAY-00          3        999             1        48.1
...
...
72 rows selected.

3 構成ツールと管理ツールの概要

Oracleデータベースに対してエンタープライズ・ユーザー・セキュリティを構成するときの主要な作業は、エンタープライズ・ユーザーとデータベース情報を格納するためのディレクトリ・オブジェクトの作成です。一部の実装では、データベースがネットワーク上の正しいディレクトリ・サーバーの位置を確認できるように、特別なネットワーク構成ファイル(ldap.ora)の作成が必要になる場合もあります。

エンタープライズ・ユーザー・セキュリティの構成と管理タスクのいずれでも、Oracle Enterprise Managerが主要なツールになりますが、この章では使用可能なすべてのツールについて説明します。項目は次のとおりです。

- エンタープライズ・ユーザー・セキュリティのツールの概要

- データベース・コンフィギュレーション・アシスタント

- Oracle Wallet Manager

- Oracle Enterprise Manager

- Oracle Netコンフィギュレーション・アシスタント

- ユーザー移行ユーティリティ

- エンタープライズ・ユーザー・セキュリティ管理者/DBAの責務

3.1 エンタープライズ・ユーザー・セキュリティのツールの概要

エンタープライズ・ユーザーは、識別情報がOracle Internet DirectoryなどのLDAPディレクトリに格納され、一元的に管理されるデータベース・ユーザーです。表3-1に、エンタープライズ・ユーザー・セキュリティの構成および管理タスクと、その実行に使用されるツールの概要を示します。ツール名は、そのツールを説明している項にリンクしています。

表3-1 エンタープライズ・ユーザー・セキュリティのタスクとツールの概要

タスク

ツール

ユーザーの作成およびそのパスワードの管理

Oracle Internet Directoryセルフ・サービス・コンソール

ネットワークを介してディレクトリを使用するためのデータベースのOracleホームの構成

Oracle Netコンフィギュレーション・アシスタント

Oracle Internet Directoryへのデータベースの登録および登録解除

データベース・コンフィギュレーション・アシスタント

エンタープライズ・ユーザー・セキュリティのOracleウォレットの管理

Oracle Wallet Manager

- マッピング、ロール、プロキシ権限など、Oracle Internet Directoryでのエンタープライズ・ドメインとデータベースの構成

- Oracle Internet Directoryでのエンタープライズ・ユーザー・セキュリティに関連するアイデンティティ管理レルムの属性および管理グループの管理

Oracle Enterprise Manager

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

このツールおよびレルムの詳細は、『Oracle Identity Management委任管理ガイド』を参照してください。

Oracle Internet Directoryセルフ・サービス・コンソール

Oracle Internet Directoryへのデータベース・ユーザーのバルク移行の実行

ユーザー移行ユーティリティ

3.2 Oracle Internet Directoryセルフ・サービス・コンソール

Oracle Internet Directoryセルフ・サービス・コンソールは、Delegated Administration Servicesに基づいたツールです。このツールは、ディレクトリで管理されるアプリケーション・データへの管理アクセスを可能にするセルフ・サービス・アプリケーションです。Oracle Internet Directoryですぐに使用できる状態になっています。

Delegated Administration ServicesとOracle Internet Directoryセルフ・サービス・コンソール・ツールの詳細は、『Oracle Identity Management委任管理ガイド』を参照してください。

3.3 Oracle Net Configuration Assistant

Oracle Net Configuration Assistantは、グラフィカル・ユーザー・インタフェースを持つウィザードベースのツールです。主な用途は、リスナー名やプロトコル・アドレスなどの基本的なOracle Netネットワーク・コンポーネントの構成、およびディレクトリ・サーバーを使用するためのOracleホームの構成です。後者に使用する場合、このツールはエンタープライズ・ユーザー・セキュリティの構成で重要になります。

ドメイン・ネーム・システム(DNS)検出(自動ドメイン名検索)を使用してネットワーク上のOracle Internet Directoryを探す場合、このアシスタントは不要です。DNS検出を使用するよう構成することをお薦めします。この構成の詳細は、『Oracle Internet Directory管理者ガイド』を参照してください。

データベースをディレクトリに登録するには、次の2つのタスクのいずれかを実行する必要があります。

- ネットワークにOracle Internet DirectoryのDNS検出を構成します。

関連項目:
DNSサーバー検出の詳細は、『Oracle Internet Directory管理者ガイド』を参照してください。

- ネットワークにDNS検出を構成しない場合は、Oracle Net Configuration Assistantを使用してOracleホーム用のldap.oraファイルを作成します。

データベースは最初にldap.oraファイルを使用してネットワーク上の正しいOracle Internet Directoryサーバーを探します。この構成ファイルには、ディレクトリ・サーバーのホスト名、ポート番号およびアイデンティティ管理レルム情報が含まれています。

データベースの登録が完了すると、データベース・ウォレットに格納されているデータベースDNによってレルムが確認されます。

3.3.1 Oracle Net Configuration Assistantの起動

Oracle Net Configuration Assistantを起動するには、次のようにします。

- (UNIXの場合)$ORACLE_HOME/binから、コマンドラインで次のように入力します。

netca

- (Windowsの場合)「スタート」→「プログラム」→「Oracle - HOME_NAME」→「Configuration and Migration Tools」→「Net Configuration Assistant」の順に選択します。

このツールを起動すると、図3-1に示すような開始ページが表示されます。

このページで「ディレクトリ使用構成」オプションを選択し、「次へ」をクリックしてエンタープライズ・ユーザーを格納するディレクトリ・サーバーを選択します。次に、「終了」をクリックして、Oracleホーム用に適切に構成されたldap.oraファイルを作成します。

図3-1 Oracle Net Configuration Assistantの開始ページ

関連項目:

- このツールを使用してエンタープライズ・ユーザー・セキュリティ用にOracleホームを構成する方法は、「タスク5: (オプション)ディレクトリを使用するためのOracleホームの構成」を参照してください。

- このツールの詳細なドキュメントは、Oracle Net Configuration Assistantのオンライン・ヘルプおよび 『Oracle Database Net Services管理者ガイド』を参照してください。

3.4 Database Configuration Assistant

Database Configuration Assistantは、Oracleデータベースの作成と構成に使用するウィザードベースのツールです。

Database Configuration Assistantを使用して、データベースをディレクトリに登録します。その処理中に、Database Configuration Assistantはデータベースの識別名(DN)と、対応するエントリおよびサブツリーをOracle Internet Directoryに作成します。

3.4.1 Database Configuration Assistantの起動

Database Configuration Assistantを起動するには、次のようにします。

- (UNIXの場合)$ORACLE_HOME/binから、コマンドラインでdbcaと入力します。

- (Windowsの場合)「スタート」→「プログラム」→「Oracle - HOME_NAME」→「Configuration and Migration Tools」→「Database Configuration Assistant」の順に選択します。

関連項目:

- このツールを使用してデータベースを登録する方法は、「データベースをディレクトリに登録する手順」を参照してください。

- このツールの詳細は、『Oracle Database管理者ガイド』を参照してください。

3.5 Oracle Wallet Manager

セキュリティ管理者は、Oracle Wallet Managerを使用してOracleクライアントおよびサーバーの公開鍵セキュリティ資格証明を管理します。作成されたウォレットは、Oracle Database、Oracle Application Server 10gおよびOracle Identity Managementインフラストラクチャで読み取ることができます。

関連項目:
『Oracle Database Advanced Security管理者ガイド』の「Wallet Managerの使用」を参照してください。

3.5.1 Oracle Wallet Managerの起動

Oracle Wallet Managerを起動するには、次のようにします。

- (Windowsの場合)「スタート」→「プログラム」→「Oracle - HOME_NAME」→「Integrated Management Tools」→「Wallet Manager」の順に選択します。

- (UNIXの場合)コマンドラインでowmと入力します。

3.5.2 orapkiコマンドライン・ユーティリティ

orapkiコマンドライン・ユーティリティを使用すると、管理者は、ウォレット、証明書失効リストおよびその他の公開鍵インフラストラクチャ(PKI)の要素をコマンドラインから管理できます。このユーティリティはスクリプト内で使用できるため、多くの日常的なPKIタスクを自動化できます。orapkiコマンドを使用すると、次のタスクを実行できます。

表3-2 orapkiコマンドの概要

対象オブジェクト

orapkiコマンドで実行可能な操作

証明書

作成または表示

証明書失効リスト(CRL)

削除、表示、ハッシュ、一覧表示またはアップロード

ウォレット

作成、表示、追加またはエクスポート

関連項目:
『Oracle Database Advanced Security管理者ガイド』の「orapkiユーティリティ」を参照してください。

3.6 Oracle Enterprise Manager

エンタープライズ・ユーザー・セキュリティでは、Oracle Enterprise Managerを使用して、Oracle Internet Directoryに格納されたエンタープライズ・ユーザー、管理グループ、エンタープライズ・ドメイン、およびエンタープライズ・ロールを管理します。Oracle Enterprise Manager Database ControlまたはOracle Enterprise Manager Grid Controlに付属するWebベースのユーザー・インタフェースを使用して、エンタープライズ・ユーザー・セキュリティを管理できます。

エンタープライズ・ユーザーは、データベース・アクセスについて、Oracle Internet DirectoryなどのLDAP準拠のディレクトリで一元的にプロビジョニングおよび管理されるユーザーです。エンタープライズ・ドメインは、データベース、エンタープライズ・ロール(エンタープライズ・ユーザーに割り当てられているアクセス権限)およびプロキシ権限(エンタープライズ・ユーザーが別のユーザーとしてデータベースに接続できるようにする権限)を格納するディレクトリ構成メンバーです。

関連項目:
エンタープライズ・ユーザー・セキュリティの管理グループ、エンタープライズ・ドメイン、エンタープライズ・ロール、エンタープライズ・ユーザー、共有スキーマおよびユーザー・スキーマ・マッピングの詳細は、第1章「エンタープライズ・ユーザー・セキュリティの概要」を参照してください。

Oracle Enterprise Manager Database ControlまたはGrid Controlの「エンタープライズ・ユーザー・セキュリティ」リンクにアクセスするには、次の手順に従います。

1. ブラウザ・ウィンドウにDatabase ControlまたはGrid ControlのURLを入力します。次に例を示します。

https://mydbhost:1158/em

2. 管理データベース・ユーザーとしてログインします。

3. 「サーバー」タブをクリックします。「セキュリティ」セクションで「エンタープライズ・ユーザー・セキュリティ」をクリックします。

注意:
Enterprise Manager Grid Controlを使用している場合、ターゲット・データベースの「サーバー」タブにアクセスするには、そのデータベースのページに移動する必要があります。

「Oracle Internet Directoryログイン」ページが表示されます。

4. 「ユーザー」フィールドに、アイデンティティ管理レルムに対する管理権限を持つディレクトリ・ユーザーの識別名(DN)を入力します。「パスワード」フィールドに、ユーザー・パスワードを入力します。「ログイン」をクリックします。
「エンタープライズ・ユーザー・セキュリティ」ページが表示されます。

3.7 ユーザー移行ユーティリティ

ユーザー移行ユーティリティは、データベース・ユーザーをOracle Internet Directoryに一括して移行し、エンタープライズ・ユーザーとして格納および管理できるようにするコマンドライン・ツールです。このツールは、バルク移行を2つのフェーズに分けて実行します。フェーズ1で、データベース・ユーザー情報を表に移入します。フェーズ2で、ディレクトリにデータベース・ユーザー情報が移行されます。

このツールは、Oracle Databaseクライアントのインストール時に次の場所に自動的にインストールされます。

$ORACLE_HOME/rdbms/bin/umu

このユーティリティの基本構文は次のとおりです。

umu parameter_keyword_1=value1:value2

parameter_keyword_2=value
parameter_keyword_3=value1:value2:value3
...
parameter_keyword_n=value

パラメータが複数の値をとる場合は、コロン(:)で区切ります。

関連項目:
このツールを使用してデータベース・ユーザーをディレクトリに移行するための詳細な手順(使用例を含む)は、付録A「ユーザー移行ユーティリティの使用方法」を参照してください。

3.8 エンタープライズ・ユーザー・セキュリティ管理者/DBAの責務

エンタープライズ・ユーザー・セキュリティ管理者は、エンタープライズ・ユーザーを計画、実装および管理します。表3-3に、エンタープライズ・ユーザー・セキュリティ管理者の主なタスク、タスクの実行に使用するツールおよびタスクの関連項目へのリンクを示します。

表3-3 エンタープライズ・ユーザー・セキュリティ管理者の一般的な構成および管理タスク

タスク

使用するツール

関連項目

Oracle Internet Directoryでのアイデンティティ管理レルムの作成

Oracle Internet Directoryセルフ・サービス・コンソール(Delegated Administration Services)

このタスクを実行する方法は『Oracle Internet Directory管理者ガイド』

Oracle Internet Directoryでのアイデンティティ管理レルムのアップグレード

Oracle Internet Directoryコンフィギュレーション・アシスタント

『Oracle Internet Directory管理者ガイド』およびこのツールのオンライン・ヘルプ

ネットワーク上でのOracle Internet Directoryの自動検出を有効にするためのDNSの設定。この構成をお薦めします。

Oracle Internet Directoryコンフィギュレーション・アシスタント

『Oracle Internet Directory管理者ガイド』(ドメイン・ネーム・システム・サーバー検出)およびこのツールのオンライン・ヘルプ

ディレクトリ・アクセスを可能にするためのldap.oraファイルの作成

Oracle Netコンフィギュレーション・アシスタント

「タスク5: (オプション)ディレクトリを使用するためのOracleホームの構成」

ディレクトリへのデータベースの登録

Database Configuration Assistant

「タスク6: ディレクトリへのデータベースの登録」

エンタープライズ・ユーザー・セキュリティのパスワード認証の構成

Oracle Enterprise Manager

「パスワード認証を使用するエンタープライズ・ユーザー・セキュリティの構成」

エンタープライズ・ユーザー・セキュリティのKerberos認証の構成

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

- Oracle Enterprise Manager

「Kerberos認証を使用するエンタープライズ・ユーザー・セキュリティの構成」

エンタープライズ・ユーザー・セキュリティのSSL認証の構成

- Oracle Net Manager

- Oracle Enterprise Manager

- Oracle Wallet Manager

「SSL認証を使用するエンタープライズ・ユーザー・セキュリティの構成」

ディレクトリでのユーザー・エントリおよびOracle管理グループの作成または変更

Oracle Internet Directoryセルフ・サービス・コンソール(Delegated Administration Services)

- 「アイデンティティ管理レルムの管理」

- 「エンタープライズ・ユーザーの管理」

ディレクトリでのエンタープライズ・ロールおよびドメインの作成または変更

Oracle Enterprise Manager

- 「エンタープライズ・ドメインの管理」

- 「エンタープライズ・ロールの構成」

ディレクトリ、データベースおよびクライアントのウォレットの作成または変更

- Oracle Wallet Manager

- orapkiコマンドライン・ユーティリティ

『Oracle Databaseセキュリティ・ガイド』

- 『Oracle Database Advanced Security管理者ガイド』の使用

- 「orapkiユーティリティ」

ユーザーのデータベースまたはディレクトリ・パスワードの変更

Oracle Internet Directoryセルフ・サービス・コンソール(Delegated Administration Services)

「エンタープライズ・ユーザー・パスワードの設定」

データベースのディレクトリ・パスワードの変更

Database Configuration Assistant

「データベースのディレクトリ・パスワードを変更する手順」

ローカル・システムでのユーザー・ウォレットの管理、またはデータベースおよびディレクトリのウォレット・パスワードの更新

Oracle Wallet Manager

『Oracle Database Advanced Security管理者ガイド』

MITのKerberos V5などのKDCがオペレーティング・システムに組み込まれていない場合の初期Kerberosチケットのリクエスト

okinitユーティリティ

okinitユーティリティを使用して初期Kerberosチケットを取得する方法は『Oracle Database Advanced Security管理者ガイド』

多数のローカルまたは外部データベース・ユーザーの、エンタープライズ・ユーザー・セキュリティのディレクトリへの移行

ユーザー移行ユーティリティ

付録A「ユーザー移行ユーティリティの使用方法」

4 エンタープライズ・ユーザー・セキュリティの構成タスクとトラブルシューティング

この章では、エンタープライズ・ユーザー・セキュリティの構成方法を順序立てて説明します。これには、初期データベースとディレクトリの準備から、パスワード、KerberosチケットまたはSSLを使用して認証されるエンタープライズ・ユーザーとしてデータベースに接続するまでの手順が含まれます。トラブルシューティングの項は、エンタープライズ・ユーザー・セキュリティの実装をテストする際に役立ちます。

この章では、次の項目について説明します。

- エンタープライズ・ユーザー・セキュリティの構成の概要

- エンタープライズ・ユーザー・セキュリティの構成のロードマップ

- エンタープライズ・ユーザー・セキュリティのディレクトリの準備(フェーズ1)

- データベースおよびディレクトリでのエンタープライズ・ユーザー・セキュリティ・オブジェクトの構成(フェーズ2)

- 必要な認証方式を使用するためのエンタープライズ・ユーザー・セキュリティの構成(フェーズ3)

- 現行ユーザーのデータベース・リンクの有効化

- エンタープライズ・ユーザー・セキュリティのトラブルシューティング

4.1 エンタープライズ・ユーザー・セキュリティの構成の概要

エンタープライズ・ユーザー・セキュリティを構成するということは、エンタープライズ・ユーザーがアクセスできるように、共有スキーマとグローバル・ロールをデータベースに作成することを意味します。ディレクトリにアイデンティティ管理レルムを構成してデータベース・ロールとスキーマを反映し、そのデータベース・ロールとスキーマにディレクトリ・ユーザーを関連付けます。これらの手順は、選択した認証方式(パスワード、KerberosまたはSSL)にかかわらず適用されます。

認証タイプによる構成の主な違いは、ネットワーク接続構成です。次の3つの接続タイプを検討する必要があります。

- クライアントとデータベース間

- データベースとディレクトリ間

- データベース間(現行ユーザーのデータベース・リンクを保護できるのはSSLのみ)

エンタープライズ・ユーザー・セキュリティでは、データベース、ディレクトリおよびクライアント間の認証タイプの様々な組合せをサポートしています。この章で説明するエンタープライズ・ユーザー・セキュリティの最も一般的な3つの実装では、クライアントとデータベース間の接続およびデータベースとディレクトリ間の接続に対して、次の認証方式を使用します。

- 両方の接続にパスワードを使用

- 両方の接続にSSLを使用

- クライアントとデータベース間の接続にはKerberosを、データベースとディレクトリ間の接続にはパスワードを使用

エンタープライズ・データのセキュリティと整合性はセキュアなネットワーク接続の作成に依存するため、これらの認証方式のいずれを選択するかは、主にネットワーク環境に基づいて決定します。一般的なネットワーク環境では、すべてのクライアント、データベースおよびディレクトリが、ファイアウォールの内側にある同じネットワーク内に存在する場合や、複数のネットワークに分散されてインターネットに公開される場合があります。エンタープライズ・ユーザー・セキュリティのネットワーク接続を保護するには、環境に応じて認証タイプを選択できます。

次に認証タイプの選択で考慮する点は、SSLやKerberosなどの厳密な認証タイプでは、構成が複雑になり、追加のソフトウェアや継続的なメンテナンスが必要になる点です。

図4-1に、エンタープライズ・ユーザー・セキュリティの構成プロセスを示します。この構成プロセスは、実装とユーザーの認証方法に基づいた判断ポイントを記載した段階的なプロセスです。破線で示されている構成手順はオプションです。

図4-1 エンタープライズ・ユーザー・セキュリティの構成フロー・チャート

簡潔にするために、このフロー・チャートでは一部の製品名と機能は略語で示されています。次の表に、使用されている略語とその意味を示します。

略語

意味

DBCA

Database Configuration Assistant

EM

Oracle Enterprise Manager Database ControlまたはGrid Control

IM Realm

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

Netmgr

Oracle Net Manager

ODM

Oracle Directory Manager

OID

Oracle Internet Directory

OID DAS

Oracle Internet Directory Delegated Administration Services

OWM

Oracle Wallet Manager

SQL

SQL*Plus

関連項目:
レルムOracleコンテキストとその管理グループ、およびエンタープライズ・ユーザー・セキュリティに関連するエントリの詳細は、第1章「エンタープライズ・ユーザー・セキュリティの概要」を参照してください。

4.2 エンタープライズ・ユーザー・セキュリティの構成のロードマップ

この項では、図4-1に示した構成手順を詳しく説明します。この構成手順は、次の順序で実行する必要があります。

1. エンタープライズ・ユーザー・セキュリティのディレクトリの準備(フェーズ1)

2. データベースおよびディレクトリでのエンタープライズ・ユーザー・セキュリティ・オブジェクトの構成(フェーズ2)

3. 必要な認証方式を使用するためのエンタープライズ・ユーザー・セキュリティの構成(フェーズ3)。次の3つの認証方式のいずれかを選択して設定することで、エンタープライズ・ユーザー・セキュリティの構成は完了します。

- 「パスワード認証を使用するエンタープライズ・ユーザー・セキュリティの構成」

- 「Kerberos認証を使用するエンタープライズ・ユーザー・セキュリティの構成」

- 「SSL認証を使用するエンタープライズ・ユーザー・セキュリティの構成」

4.3 エンタープライズ・ユーザー・セキュリティのディレクトリの準備(フェーズ1)

エンタープライズ・ユーザー・セキュリティの他の部分を構成する前に、この構成フェーズを実行する必要があります。

11gリリース2(11.2)のエンタープライズ・ユーザー・セキュリティには、必要なバージョンのOracleスキーマがインストールされたリリース9.0.4(以上)のOracle Internet Directoryが必要です。このスキーマには下位互換性があります。Oracle Internet Directoryをインストールした後で、次のディレクトリ使用構成タスクを実行します。

- タスク1: (オプション)ディレクトリでのアイデンティティ管理レルムの作成

- タスク2: (オプション)アイデンティティ管理レルムのプロパティの設定

- タスク3: ディレクトリでの管理ユーザーの特定

- タスク4: (オプション)アイデンティティ管理レルムに対するデータベースとディレクトリ間のデフォルト認証タイプの設定

- タスク5: (オプション)ディレクトリを使用するためのOracleホームの構成

- タスク6: ディレクトリへのデータベースの登録

タスク1: (オプション)ディレクトリでのアイデンティティ管理レルムの作成

必要に応じて、Oracle Internet Directoryセルフ・サービス・コンソール(Delegated Administration Services)を使用して、ディレクトリにアイデンティティ管理レルムを作成します。また、Oracle Internet Directoryコンフィギュレーション・アシスタントを使用すると、Oracle9iのOracleコンテキストをリリース9.0.4以上のアイデンティティ管理レルムにアップグレードできます。

Oracle Database 10gまたはOracle Database 11gを使用するには、リリース9.0.4 (以上)のアイデンティティ管理レルムが必要です。リリース9.0.4のレルムは、Oracle9iと下位互換性があるため、必要であれば、Oracle9iとOracle Database 11gリリース2(11.2)を同じレルムに登録し、同じドメインに配置できます。

関連項目:
Oracle Internet Directoryにアイデンティティ管理レルムを作成する方法は、『Oracle Identity Management委任管理ガイド』を参照してください。

タスク2: (オプション)アイデンティティ管理レルムのプロパティの設定

表4-1に、リリース9.0.4のアイデンティティ管理レルムのデフォルトを示します。

表4-1 アイデンティティ・レルムのデフォルト

ユーザー検索ベース

グループ検索ベース

ログイン名属性(ニックネーム)

cn=Users,realm_DN

cn=Groups,realm_DN

uid, ユーザーID

別の設定を使用する場合は、Oracle Internet Directoryセルフ・サービス・コンソールを使用してユーザー検索ベース、グループ検索ベースおよびログイン名属性(ニックネーム)を設定します。ディレクトリで使用する予定のアイデンティティ管理レルムには、必要なコンテキスト管理者も設定できます。

このタスクを実行するには、「アイデンティティ管理レルムのプロパティの設定」を参照してください。

注意:
各アイデンティティ管理レルムには、そのレルムのみのルート・ユーザーであるorcladminユーザーが含まれます。これらのレルム固有のorcladminユーザーは、ディレクトリ・エントリcn=orcladmin,cn=Users,<realm_DN>で表されます。レルム固有のorcladminユーザーとしてエンタープライズ・ユーザー・セキュリティ管理ツールにログインしている場合は、そのレルムのディレクトリ・オブジェクトのみ管理できます。別のレルムのオブジェクトを管理するには、そのレルムのorcladminユーザーとして管理ツールにログインする必要があります。

タスク3: ディレクトリでの管理ユーザーの特定

ディレクトリで次のタスクの実行を認可された管理ユーザーを特定します。

- データベースの登録

- データベース・セキュリティの管理

- エンタープライズ・ドメインの作成および管理

これらのタスクを実行できる管理ユーザーがまだ存在しない場合は、第5章「エンタープライズ・ユーザー・セキュリティの管理」を参照して作成します。

注意:
1人の管理者がエンタープライズ・ユーザー・セキュリティのすべての管理タスクを実行できますが、様々な管理者を作成し、セキュリティ・タスクをそれぞれ別の管理者に割り当てることもできます。このようにセキュリティ・タスクを分離することによってセキュアなエンタープライズ環境が実現しますが、この環境では、各管理者間の連携が必要となります。

タスク4: (オプション)アイデンティティ管理レルムに対するデータベースとディレクトリ間のデフォルト認証タイプの設定

デフォルトでは、アイデンティティ管理レルムに対するデータベースとディレクトリ間の認証タイプはパスワードに設定されます。別のデフォルト設定が必要な場合は、Oracle Enterprise Manager Database ControlまたはGrid Controlのインタフェースを使用して設定を変更します。たとえば、公開鍵インフラストラクチャ(PKI)を使用する場合は、認証タイプをSSLに設定する必要があります。「アイデンティティ管理レルムに対するデータベースとディレクトリ間のデフォルト認証タイプの設定」を参照してください。

注意:

- このレルム全体のデフォルト設定は、LDAP_DIRECTORY_ACCESS初期化パラメータを設定することで、データベースで上書きできます。このパラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

- SSLを使用する場合、Oracle Internet Directoryに対して双方向SSL認証を設定する方法は、『Oracle Internet Directory管理者ガイド』を参照してください。

タスク5: (オプション)ディレクトリを使用するためのOracleホームの構成

この手順はオプションです。ドメイン・ネーム・システム(DNS)検出機能(ネットワーク上のディレクトリを検索するためのドメイン名自動検索)を使用するユーザーは、この手順を実行する必要はありません。(DNSサーバー検出の詳細は、『Oracle Internet Directory管理者ガイド』を参照してください。)

ネットワークにDNS検出を使用していない場合は、Oracle Net Configuration Assistant (NetCA)を使用してOracleホーム用のldap.oraファイルを作成する必要があります。この構成ファイルでは、データベースがディレクトリに接続できるように、ディレクトリ・ホストおよびポートの情報とアイデンティティ管理レルムの場所を指定します。(「Oracle Net Configuration Assistantの起動」を参照してください。)

Oracleホーム用のldap.oraファイルを作成するには、次のようにします。

1. Oracle Net Configuration Assistantのようこそページで、ディレクトリ・サービス使用構成を選択し、「次へ」をクリックします。

2. 「ディレクトリ使用構成」ページで、使用している環境に適したオプションを選択します。ウィザードに表示される指示に従い、オンライン・ヘルプを参照して、Oracleホーム用のldap.oraファイルを作成します。

注意:

- データベースとディレクトリ間のSSL認証では、ldap.oraファイルに入力したSSLポートにより、クライアントとサーバーの両方が相互に証明書を送信する双方向認証がサポートされている必要があります。そのため、Oracle Internet Directoryに対するPKIデジタル証明書とウォレットを取得し、Oracle Internet DirectoryをSSL相互認証モードで起動する必要があります。ldap.oraファイルの2番目のポートには、SSL相互認証ポートを指定する必要があります。(『Oracle Internet Directory管理者ガイド』を参照してください。)

- データベースとディレクトリ間の接続にパスワード認証を使用する場合は、ldap.oraファイルに入力したSSLポートで、認証なしのSSLがサポートされている必要があります。Oracle Internet Directoryにウォレットまたは証明書は不要です。ldap.oraファイルの2番目のポートには、認証なしのSSLポートを指定する必要があります。

関連項目:
NetCAを使用してディレクトリ使用を構成する例は、「ディレクトリを使用するためのデータベースの構成」を参照してください。

タスク6: ディレクトリへのデータベースの登録

ディレクトリを使用するようにOracleホームを構成した後は、Database Configuration Assistantを使用してデータベースをディレクトリに登録します。この登録によってディレクトリにエントリが作成され、データベースはディレクトリにバインド(ログイン)できるようになります。

注意:
このタスクを実行するには、ディレクトリ・スーパーユーザーであるか、OracleDBCreatorsグループまたはOracleContextAdminsグループのメンバーであることが必要です。

データベースをディレクトリに登録すると、Database Configuration Assistantによって次の構成タスクが実行されます。

- 新しいデータベース・サービス・エントリおよびサブツリーを作成し、使用しているアイデンティティ管理レルムのOracleコンテキストでDNを割り当てます。

- デフォルトのエンタープライズ・ドメインにデータベースを追加します。

- LDAP_DIRECTORY_ACCESSパラメータを3つの有効値NONE、PASSWORD、SSLのいずれかに設定して、データベースとディレクトリ間の認証タイプを設定します。Database Configuration Assistantは、アイデンティティ管理レルムに対するデータベースとディレクトリ間のデフォルト認証属性設定を読み取り、データベースに対する認証タイプ設定を判断します。
データベース初期化パラメータ・ファイルに存在するLDAP_DIRECTORY_ACCESSパラメータにより、データベースがディレクトリに対する認証を試行するかどうかと、その方法が決定されます。管理者は、ALTER SYSTEMコマンドを使用してこの認証タイプ設定を変更できます。

- 次の形式で、データベースDNを含むデータベース・ウォレットを作成します。
cn=short_database_name,cn=OracleContext,realm_DN

short_database_nameは、データベースの完全修飾ドメイン名の最初の部分です。

たとえば、db1.us.example.comというデータベースがある場合、データベースの短縮名はdb1です。

- ディレクトリ・アクセス用のデータベース・パスワードをランダムに生成し、データベース・ウォレットとディレクトリに格納します。

- ORACLE_BASE環境変数が存在する場合、作成されたウォレットは$ORACLE_BASE/admin/Oracle_SID/wallet(UNIX環境の場合)に格納されます。ORACLE_BASE環境変数が存在しない場合は、$ORACLE_HOME/admin/Oracle_SID/walletディレクトリが使用されます。
Windows環境では、スラッシュ(/)をバックスラッシュ(\)に置き換えます。

データベース・ウォレットがすでに存在している場合、Database Configuration Assistantはそのウォレットを使用し、ウォレット内のパスワードを更新します。

- データベース・ウォレットの自動ログインを有効にします。

注意:
Oracle Internet Directoryに対する認証に使用するデータベースのパスワードベースの資格証明は、Oracle Internet DirectoryにOracleデータベースを登録すると、ウォレットに格納されます。

データベースをディレクトリに登録する手順:

このツールを起動するには、「Database Configuration Assistantの起動」を参照してください。

1. Database Configuration Assistantを起動した後、「データベース内のデータベース・オプションの構成」を選択し、「次へ」をクリックします。

2. データベースを選択し、「次へ」をクリックします。

3. データベースを登録するには、「データベースを登録する」をクリックします。

4. OracleDBCreatorsグループのユーザーのディレクトリ資格証明を入力します。

5. データベース・ウォレットのパスワードを入力します。

注意:
手順5で入力したデータベース・ウォレット・パスワードを記憶しておいてください。データベースの登録が完了した後でパスワードを取得することはできません。パスワードを忘れた場合、数段階の手順を経て、新しいウォレットを作成し、データベースを再登録する必要があります。詳細は、「データベース・ウォレットとパスワードについて」を参照してください。

6. データベースの登録のみを行う場合は、「終了」をクリックします。他のデータベース機能を構成する場合は、「次へ」をクリックします。

関連項目:
DBCAを使用してデータベースを登録する例は、「ディレクトリへのデータベースの登録」を参照してください。

データベースのディレクトリ・パスワードを変更する手順:

Database Configuration Assistantを起動した後、「データベース内のデータベース・オプションの構成」を選択し、「次へ」をクリックします。

1. データベースを選択し、「次へ」をクリックします。

2. 「データベース・パスワードの再生成」を選択します。

3. OracleDBCreatorsグループのユーザーのディレクトリ資格証明と、データベース・ウォレットのパスワードを入力します。「OK」をクリックします。

4. パスワードの再生成のみを行う場合は、「終了」をクリックします。他のデータベース機能を構成する場合は、「次へ」をクリックします。

ディレクトリからデータベースを登録解除する手順:

このツールを起動するには、「Database Configuration Assistantの起動」を参照してください。

1. Database Configuration Assistantを起動した後、「データベース内のデータベース・オプションの構成」を選択し、「次へ」をクリックします。

2. データベースを選択し、「次へ」をクリックします。

3. データベースを登録解除するには、「登録解除」オプションを選択します。

4. 適切な権限を持つユーザーのディレクトリ資格証明を入力します。

5. データベース・ウォレットのパスワードを入力します。

ディレクトリからデータベースを登録解除すると、Database Configuration Assistantによって次の構成タスクが実行されます。

- ディレクトリからデータベース・エントリおよびサブツリーが削除されます。

- LDAP_DIRECTORY_ACCESSパラメータがNONEに設定されます。

- エンタープライズ・ドメインからデータベースが削除されます(ユーザーに十分な権限がある場合)。

注意:
ユーザー権限によっては、Database Configuration Assistantがディレクトリ内のドメインからデータベースを削除できない場合があります。削除できない場合は、Oracle Enterprise Manager Database ControlまたはGrid Controlを使用してエンタープライズ・ドメインから削除します。

- データベース・ウォレットは削除されません。

関連項目:
ウォレットの削除方法の詳細は、『Oracle Database Advanced Security管理者ガイド』のOracle Wallet Managerユーザー・インタフェースのナビゲートおよびWallet Managerの管理に関する項を参照してください。

注意:
Database Configuration Assistantを使用してOracle Internet DirectoryからOracle Databaseを登録解除するには、次のいずれかのメンバーであることが必要です。

- Oracle Context Adminグループ

- Database Adminグループ(登録解除しているデータベース)とDatabase Security Adminグループの両方

- Database Adminグループ(登録解除しているデータベース)とDomain Adminグループ(データベースを含むエンタープライズ・ドメイン)の両方

4.3.1 データベース・ウォレットとパスワードについて

データベースとディレクトリ間の接続の保護にSecure Sockets Layer (SSL)を使用していない場合でも、データベースにはウォレットが必要です。SSLが使用されている場合は、このウォレットを使用してデータベースのデジタルPKI証明書を格納する必要があります。

Database Configuration Assistantを使用してデータベースをディレクトリに登録する際に入力するウォレット・パスワードは、ウォレット自体に対するパスワードです。このパスワードは、データベースのディレクトリ・ログイン資格証明ではありません。

このウォレット・パスワードは、後でOracle Wallet Managerを使用して変更できます。ただし、このウォレット・パスワードを忘れた場合は、ウォレットとパスワードをまったく新たに生成する必要があります。生成するには、最初に既存のデータベース・ウォレットを削除し、新しいウォレット(空のウォレットも可)を作成して、デフォルトのウォレット・ロケーションである$ORACLE_HOME/admin/Oracle_SID/wallet(UNIX環境の場合)に配置します。次に、データベースをディレクトリから登録解除し、そのデータベースをディレクトリに再登録します。この登録時に、別のデータベース・ウォレットとパスワードが生成されます。

関連項目:
Oracle Wallet Managerを使用して、ウォレットのパスワードを変更する方法および公開鍵インフラストラクチャ(PKI)資格証明を管理する方法は、『Oracle Database Advanced Security管理者ガイド』のOracle Wallet Managerの使用に関する項を参照してください。

エンタープライズ・ユーザー・セキュリティで使用するディレクトリを準備した後は、エンタープライズ・ユーザー・セキュリティのデータベース・オブジェクトとディレクトリ・オブジェクトを作成できます。詳細は、「データベースおよびディレクトリでのエンタープライズ・ユーザー・セキュリティ・オブジェクトの構成(フェーズ2)」を参照してください。

関連項目:

- ディレクトリにアイデンティティ管理レルムを構成する方法は、『Oracle Internet Directory管理者ガイド』を参照してください。

- LDAP_DIRECTORY_ACCESS初期化パラメータの値を変更する方法は、『Oracle Databaseリファレンス』を参照してください。

4.3.1.1 複数データベース間でのウォレットとsqlnet.oraファイルの共有

ウォレットにはデータベースの識別情報が含まれているため、複数のデータベース(レプリカを除く)でウォレットを共有することはできません。したがって、sqlnet.oraファイルにウォレット・ロケーションが含まれている場合、そのsqlnet.oraファイルは複数のデータベースで共有できません。

1つのsqlnet.oraファイルを複数のデータベース間で共有するには、次の前提条件を満たす必要があります。

- ユーザー認証でパスワードまたはKerberosを使用する必要があります。

- パスワードを含むウォレットは、Database Configuration Assistantによって作成されるデフォルトのウォレット・ロケーションに存在する必要があります。

前述の条件を満たした場合、sqlnet.oraファイルにウォレット・ロケーション情報が含まれていないため、複数のデータベースでファイルを共有することができます。

ただし、SSL認証がユーザー(クライアント)とデータベースの間で使用される場合は、sqlnet.oraファイルにウォレット・ロケーションを指定する必要があります。この場合、sqlnet.oraファイルは、SSL認証エンタープライズ・ユーザー用の複数のデータベースで共有できません。

4.4 データベースおよびディレクトリでのエンタープライズ・ユーザー・セキュリティ・オブジェクトの構成(フェーズ2)

これは、エンタープライズ・ユーザー・セキュリティの実装に必要な構成手順の第2フェーズです。この項で説明する構成手順は、次の推奨設定を前提としています。

- 「エンタープライズ・ユーザー・セキュリティのディレクトリの準備(フェーズ1)」で説明されているタスクを完了し、データベースとディレクトリの準備を終えている。

- ユーザーは、アイデンティティ管理レルムのUsersサブツリーに格納されている。

- デフォルトのエンタープライズ・ドメインであるOracleDefaultDomainを使用している。これは、データベースをディレクトリに登録する際に、Database Configuration Assistantで使用されるドメインです。

エンタープライズ・ユーザー・ログインが機能するためには、データベースはアイデンティティ管理レルム内のエンタープライズ・ドメインに存在している必要があります。

関連項目:

OracleDefaultDomainを使用しない場合、またはユーザーをアイデンティティ管理レルムのUsersサブツリーに格納しない場合は、次のドキュメントを参照してください。

- 新しいアイデンティティ管理レルムの作成方法または既存のアイデンティティ管理レルムの変更方法、およびディレクトリ・オブジェクトに対するアクセス制御リストの設定方法は、『Oracle Internet Directory管理者ガイド』を参照してください。

- データベースを配置するドメインを別に作成するには、「エンタープライズ・ドメインの作成」を参照してください。続いて、次の構成手順でOracleDefaultDomainを新しいドメイン名で置き換えます。

データベースおよびディレクトリでエンタープライズ・ユーザー・セキュリティ・オブジェクトを構成するには、次のタスクを実行します。

- タスク1: データベースでのグローバル・スキーマおよびグローバル・ロールの作成

- タスク2: エンタープライズ・ドメインのユーザー・スキーマ・マッピングの構成

- タスク3: エンタープライズ・ドメインでのエンタープライズ・ロールの作成

- タスク4: エンタープライズ・ロールへのグローバル・データベース・ロールの追加

- タスク5: データベース・アクセスのためのエンタープライズ・ユーザーへのエンタープライズ・ロールの付与

タスク1: データベースでのグローバル・スキーマおよびグローバル・ロールの作成

この手順はOracle Enterprise Managerを使用して実行することもできますが、次の例ではSQL*Plusを直接使用しています。

1. エンタープライズ・ユーザーに対して共有スキーマを作成します。次の構文例では、guestという共有スキーマを作成します。

SQL> CREATE USER guest IDENTIFIED GLOBALLY AS '';

共有スキーマを使用しない場合は、一重引用符の間にユーザーDNを指定して排他スキーマを作成します。

2. 手順1で作成した共有スキーマにCREATE SESSION権限を付与して、ユーザーがこの共有スキーマに接続できるようにします。次の構文例では、guest共有スキーマにCREATE SESSION権限を付与します。

SQL> GRANT CREATE SESSION TO guest;

あるいは、CREATE SESSION権限をグローバル・ロールに付与できます。このグローバル・ロールは、エンタープライズ・ロールを通じて特定のユーザーに付与します。手順3を参照してください。

3. 関連する権限を保持するグローバル・ロールをデータベースに対して作成します。次の構文例では、emproleおよびcustroleグローバル・ロールを作成します。

SQL> CREATE ROLE emprole IDENTIFIED GLOBALLY;
SQL> CREATE ROLE custrole IDENTIFIED GLOBALLY;

グローバル・ロールは、後で作成するエンタープライズ・ロールに関連付けてから、エンタープライズ・ユーザーに割り当てます。

4. 手順3で作成した新しいグローバル・ロールに権限を付与します。次の構文例では、SELECT権限をproducts表のemproleおよびcustroleグローバル・ロールに付与します。

SQL> GRANT select ON products TO custrole, emprole;

関連項目:
この手順で使用する構文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

タスク2: エンタープライズ・ドメインのユーザー・スキーマ・マッピングの構成

Enterprise Managerを使用し、次の手順に従ってOracleDefaultDomainのユーザー・スキーマ・マッピングを構成します。

1. Enterprise Managerにログインします。

2. 「サーバー」タブをクリックします。「セキュリティ」セクションで「エンタープライズ・ユーザー・セキュリティ」をクリックします。
「Oracle Internet Directoryログイン」ページが表示されます。

3. 「ユーザー」フィールドに、エンタープライズ・ユーザーを管理できるディレクトリ・ユーザーの識別名(DN)を入力します。「パスワード」フィールドに、ユーザー・パスワードを入力します。「ログイン」をクリックします。
「エンタープライズ・ユーザー・セキュリティ」ページが表示されます。

4. 「エンタープライズ・ドメインの管理」をクリックします。
「エンタープライズ・ドメインの管理」ページが表示されます。このページには、アイデンティティ管理レルム内のエンタープライズ・ドメインが一覧表示されます。

5. 「OracleDefaultDomain」を選択します。「構成」をクリックします。
「ドメインの構成」ページが表示されます。

6. 「ユーザー・スキーマ・マッピング」タブをクリックします。ドメイン・レベルで作成されたユーザー・スキーマ・マップがすべて表示されます。データベース・レベルで作成されたユーザー・スキーマ・マップは、ここには表示されません。

7. 「作成」をクリックして、ドメインに新しいユーザー・スキーマ・マッピングを作成します。
「マッピングの作成」ページが表示されます。

8. 「自」セクションで、「ユーザー」を選択して個々のエンタープライズ・ユーザーをデータベース・スキーマにマップします。あるいは、「サブツリー」を選択して複数のユーザーが含まれるディレクトリ・サブツリーをマップします。「検索」アイコンを使用して該当するユーザーまたはサブツリーを検索できます。

9. 「至」セクションで、ユーザーまたはサブツリーのマップ先となるスキーマの名前を入力します。これは、タスク1で作成したスキーマです。

10. 「マッピングの作成」ページで「続行」をクリックします。

11. 「ドメインの構成」ページで「OK」をクリックします。

注意:
ユーザー・スキーマ・マッピングは、エンタープライズ・ドメイン内の個々のデータベースに対して作成することもできます。このようなマッピングは、その特定のデータベースに対してのみ適用され、ドメイン内の他のデータベースには適用されません。

関連項目:
ユーザー・スキーマ・マッピングの作成に関する例は、「共有スキーマへのエンタープライズ・ユーザーのマップ」を参照してください。

タスク3: エンタープライズ・ドメインでのエンタープライズ・ロールの作成

Enterprise Managerを使用し、次の手順に従ってOracleDefaultDomainにエンタープライズ・ロールを作成します。

1. 「エンタープライズ・ドメインの管理」ページで「OracleDefaultDomain」を選択します。「構成」をクリックします。
「ドメインの構成」ページが表示されます。

2. 「エンタープライズ・ロール」タブをクリックします。

3. 「作成」をクリックして新しいエンタープライズ・ロールを作成します。
「エンタープライズ・ロールの作成」ページが表示されます。

4. 「名前」フィールドに、エンタープライズ・ロールの名前を入力します。「続行」をクリックします。
「ドメインの構成」ページに新しいロールが表示されます。

関連項目:
エンタープライズ・ロールの作成および使用に関する例は、「エンタープライズ・ロールの使用」を参照してください。

タスク4: エンタープライズ・ロールへのグローバル・データベース・ロールの追加

Enterprise Managerを使用し、次の手順に従って、タスク1で作成したグローバル・データベース・ロールをタスク3で作成したエンタープライズ・ロールに追加します。

1. 「ドメインの構成」ページで作成したエンタープライズ・ロールを選択します。「編集」をクリックします。
「エンタープライズ・ロールの編集」ページが表示されます。

2. 「DBグローバル・ロール」タブが選択されていることを確認します。「追加」をクリックし、エンタープライズ・ドメインに属するデータベースからグローバル・ロールを追加します。

「検索と選択: データベース・グローバル・ロール」ページが表示されます。

3. 追加するグローバル・ロールを含むデータベースを選択します。ユーザー名およびパスワードを指定して、選択したデータベースにログインします。「ジャンプ」をクリックします。

4. 追加するグローバル・ロールを選択します。「選択」をクリックします。

「エンタープライズ・ロールの編集」ページに選択したロールが表示されます。

関連項目:
エンタープライズ・ロールの作成および使用に関する例は、「エンタープライズ・ロールの使用」を参照してください。

タスク5: データベース・アクセスのためのエンタープライズ・ユーザーへのエンタープライズ・ロールの付与

Enterprise Managerを使用し、次の手順に従って、タスク3で作成したエンタープライズ・ロールをエンタープライズ・ユーザーに付与します。

1. 「エンタープライズ・ロールの編集」ページで「権限受領者」タブをクリックします。

2. 「追加」をクリックします。
「選択: ユーザーまたはグループ」ページが表示されます。

3. 検索ベースを選択するか、ユーザーまたはグループが含まれるサブツリーを選択します。エンタープライズ・ロールをユーザーに付与する場合は、「表示」で「USER」を選択します。ロールをグループに付与する場合は、「表示」で「グループ」を選択します。必要に応じて、「名前」フィールドにユーザーまたはグループの共通名を入力します。「ジャンプ」をクリックします。

4. エンタープライズ・ロールを付与するユーザーまたはグループを選択します。「選択」をクリックします。

5. 「エンタープライズ・ロールの編集」ページで「続行」をクリックします。

6. 「ドメインの構成」ページで「OK」をクリックします。

関連項目:
エンタープライズ・ロールの作成および使用に関する例は、「エンタープライズ・ロールの使用」を参照してください。

4.5 必要な認証方式を使用するためのエンタープライズ・ユーザー・セキュリティの構成(フェーズ3)

第3フェーズでは、選択した認証方式に基づいて、エンタープライズ・ユーザー・セキュリティの構成を完了します。次の項のいずれかに進みます。

- 「パスワード認証を使用するエンタープライズ・ユーザー・セキュリティの構成」

- 「Kerberos認証を使用するエンタープライズ・ユーザー・セキュリティの構成」

- 「SSL認証を使用するエンタープライズ・ユーザー・セキュリティの構成」

関連項目:
エンタープライズ・ユーザー・セキュリティでのパスワード認証、Kerberos認証およびSSL認証のそれぞれの利点を比較する場合は、表1-1「エンタープライズ・ユーザー・セキュリティの認証: 選択基準」を参照してください。

4.5.1 パスワード認証を使用するエンタープライズ・ユーザー・セキュリティの構成

デフォルトでは、新しいエンタープライズ・ドメインは、サポートされているすべてのユーザー認証タイプ(パスワード、KerberosおよびSSL)を受け入れるように構成されます。エンタープライズ・ユーザーがパスワードによって認証されるようにする場合は、次のタスクの説明に従ってエンタープライズ・ドメインを構成する必要があります。

この項で説明する構成手順は、次の設定を前提としています。

- 「エンタープライズ・ユーザー・セキュリティのディレクトリの準備(フェーズ1)」で説明されているタスクを完了し、ディレクトリの準備を終えている。

- 「データベースおよびディレクトリでのエンタープライズ・ユーザー・セキュリティ・オブジェクトの構成(フェーズ2)」で説明されているタスクを完了し、データベースおよびディレクトリでのエンタープライズ・ユーザー・セキュリティ・オブジェクトの構成を終えている。

- 『Oracle Internet Directory管理者ガイド』の説明に従って、Oracle Internet Directoryに、認証なしのSSLインスタンスを構成してある。ldap.oraファイルを使用している場合は、この認証なしのSSLインスタンスのポート番号がディレクトリSSLポートとしてファイルに記載されていることも確認してください。

パスワード認証を使用するエンタープライズ・ユーザー・セキュリティを構成するには、次のタスクを実行します。

- タスク1: (オプション)エンタープライズ・ドメインでパスワード認証を受入れ可能にする

- タスク2: パスワード認証エンタープライズ・ユーザーとしての接続

タスク1: (オプション)エンタープライズ・ドメインでパスワード認証を受入れ可能にする

デフォルトでは、OracleDefaultDomainはパスワード認証を受け入れるように構成されます。この構成を変更している場合は、Oracle Enterprise Manager Database ControlまたはGrid Controlを使用し、次の手順に従ってOracleDefaultDomainのパスワード認証を有効にします。

1. Enterprise Managerにログインします。

2. データベースの「サーバー」タブをクリックします。「セキュリティ」セクションで「エンタープライズ・ユーザー・セキュリティ」をクリックします。
「Oracle Internet Directoryログイン」ページが表示されます。

3. 「ユーザー」フィールドに、エンタープライズ・ユーザーを管理できるディレクトリ・ユーザーの識別名(DN)を入力します。「パスワード」フィールドに、ユーザー・パスワードを入力します。「ログイン」をクリックします。
「エンタープライズ・ユーザー・セキュリティ」ページが表示されます。

4. 「エンタープライズ・ドメインの管理」をクリックします。
「エンタープライズ・ドメインの管理」ページが表示されます。このページには、アイデンティティ管理レルム内のエンタープライズ・ドメインが一覧表示されます。

5. 「OracleDefaultDomain」を選択します。「構成」をクリックします。
「ドメインの構成」ページが表示されます。

6. 「構成」タブをクリックします。

7. 「許容されたユーザー認証タイプ」で、「パスワード」を選択します。

8. 「OK」をクリックします。

タスク2: パスワード認証エンタープライズ・ユーザーとしての接続

ディレクトリ・ログイン名がhscortea、パスワードがEasy2remのエンタープライズ・ユーザーの場合は、次のSQL*Plusコマンドを使用してデータベースに接続します。

SQL> connect hscortea@<Oracle Net Service Name>
Enter password:
/* Enter Easy2rem when prompted for the password*/

データベースでは、エンタープライズ・ユーザー(hscortea)を認証するために、このユーザーに関連付けられているディレクトリ・エントリと照合してユーザー名/パスワードの組合せを検証します。次に、適切なスキーマを特定し、ユーザーのグローバル・ロールを取得します。検証に成功すると、データベースへの接続が確立されます。

接続が成功した場合は、Connected to:...というメッセージが表示されます。このメッセージは、接続と設定が正常に行われたことを示す確認メッセージです。エラー・メッセージが表示された場合は、「パスワード認証エンタープライズ・ユーザーに関するORA-#エラー」を参照してください。

正常に接続された場合は、SQL*Plusプロンプトに次のように入力して、ディレクトリから適切なグローバル・ロールが取得されたことを確認します。

select * from session_roles

グローバル・ロールがディレクトリから取得されなかった場合は、「グローバル・ロールがない場合のチェックリスト」を参照してください。

これで、パスワード認証を使用するエンタープライズ・ユーザー・セキュリティの構成が完了しました。

関連項目:

- エラーの診断方法と解決方法は、「エンタープライズ・ユーザー・セキュリティのトラブルシューティング」を参照してください。

- アイデンティティ管理レルムの構成方法と、エンタープライズ・ドメイン、エンタープライズ・ロールおよびエンタープライズ・ユーザーの作成方法と管理方法は、第5章「エンタープライズ・ユーザー・セキュリティの管理」を参照してください。

4.5.2 Kerberos認証を使用するエンタープライズ・ユーザー・セキュリティの構成

この項で説明する構成手順は、次の設定を前提としています。

- 『Oracle Database Advanced Security管理者ガイド』の「Kerberos認証の構成」の説明に従ってデータベースをKerberos認証サーバーに登録し、Oracle Net Servicesの構成を終えている。

- 「エンタープライズ・ユーザー・セキュリティのディレクトリの準備(フェーズ1)」で説明されているタスクを完了し、ディレクトリの準備を終えている。

- 「データベースおよびディレクトリでのエンタープライズ・ユーザー・セキュリティ・オブジェクトの構成(フェーズ2)」で説明されているタスクを完了し、データベースおよびディレクトリでのエンタープライズ・ユーザー・セキュリティ・オブジェクトの構成を終えている。

- 『Oracle Internet Directory管理者ガイド』の説明に従って、Oracle Internet Directoryに、認証なしのSSLインスタンスを構成してある。ldap.oraを使用している場合は、この認証なしのSSLインスタンスのポート番号がディレクトリSSLポートとしてファイルに記載されていることも確認してください。

Kerberos認証を使用するエンタープライズ・ユーザー・セキュリティを構成するには、次のタスクを実行します。

- タスク1: Kerberosプリンシパル名属性を表示するためのOracle Internet Directoryセルフ・サービス・コンソールの構成

- タスク2: (オプション)アイデンティティ管理レルムのKerberosプリンシパル名ディレクトリ属性の構成

- タスク3: krbPrincipalName属性でのエンタープライズ・ユーザーのKerberosプリンシパル名の指定

- タスク4: (オプション)エンタープライズ・ドメインでKerberos認証を受入れ可能にする

- タスク5: Kerberos認証エンタープライズ・ユーザーとしての接続

タスク1: Kerberosプリンシパル名属性を表示するためのOracle Internet Directoryセルフ・サービス・コンソールの構成

デフォルトでは、Oracle Internet Directoryセルフ・サービス・コンソールのユーザー・インタフェースには、Kerberosプリンシパル名を構成できるフィールドは表示されません。ディレクトリにKerberos認証ユーザーを初めて作成する場合は、次の手順に従って、「ユーザーの作成」ページにkrbPrincipalName属性が表示されるようにこのツールを構成する必要があります。

1. Oracle Internet Directoryセルフ・サービス・コンソールにログインします。
ブラウザ・ウィンドウにOracle Internet Directoryセルフ・サービス・コンソールにアクセスするためのURLを入力します。次に例を示します。

http://myhost1:7777/oiddas

orcladminユーザーとしてログインします。

2. 「構成」タブをクリックします。「ユーザー・エントリ」サブタブをクリックします。

3. 「ユーザー属性の構成」ページが表示されるまで、「次へ」をクリックします。

4. 「ユーザー属性の構成」ページで、「新規属性の追加」をクリックします。
「新規属性の追加」ページが表示されます。

5. 「新規属性の追加」ページで、「ディレクトリ属性名」ボックスから「krbPrincipalName」 (またはアイデンティティ管理レルムのorclCommonKrbPrincipalAttributeに対して構成した属性)を選択し、このページで次の手順を実行します。

1. 「UIラベル」に、「Kerberosプリンシパル名」などの値を入力します。

2. 「検索可能」および「表示可能」を選択します。

3. 「UIタイプ」から「単一行テキスト」を選択します。

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

6. 「次へ」をクリックして「属性カテゴリの構成」ページに移動します。「基本情報」を選択し、「編集」をクリックします。
「カテゴリの編集」ページが表示されます。

7. 「カテゴリの編集」ページで次の手順を実行します。

1. 左側のカテゴリ・リストで「krbPrincipalName」を選択します。

2. 「移動」をクリックし、krbPrincipalNameを右側のリストに移動します。

3. 「完了」をクリックします。

8. 最後のステップに到達するまで「次へ」をクリックします。「終了」をクリックして作業内容を保存します。

タスク2: (オプション)アイデンティティ管理レルムのKerberosプリンシパル名ディレクトリ属性の構成

Oracle Internet Directoryセルフ・サービス・コンソールを使用して、ディレクトリで使用するアイデンティティ管理レルムのKerberosプリンシパル名の格納に使用するディレクトリ属性を入力します。デフォルトでは、Kerberosプリンシパル名はkrbPrincipalName属性に格納されますが、アイデンティティ管理レルムのorclCommonKrbPrincipalAttributeを変更することにより、ディレクトリ構成に応じて変更できます。このタスクの詳細は、「アイデンティティ管理レルムのログイン名、Kerberosプリンシパル名、ユーザー検索ベースおよびグループ検索ベースの各属性の設定」を参照してください。

注意:
デフォルトでは、Oracle Internet Directoryセルフ・サービス・コンソールのユーザー・インタフェースには、Kerberosプリンシパル名を構成できるフィールドは表示されません。ディレクトリにKerberos認証ユーザーを初めて作成する場合は、「ユーザーの作成」ウィンドウにkrbPrincipalName属性が表示されるようにコンソールを構成する必要があります。

タスク3: krbPrincipalName属性でのエンタープライズ・ユーザーのKerberosプリンシパル名の指定

Oracle Internet Directoryセルフ・サービス・コンソールを使用して、エンタープライズ・ユーザーのディレクトリ・エントリのkrbPrincipalName属性にエンタープライズ・ユーザーのKerberosプリンシパル名(Kerberos_username@Kerberos_realm)を指定します。このタスクの詳細は、「新規エンタープライズ・ユーザーの作成」を参照してください。

タスク4: (オプション)エンタープライズ・ドメインでKerberos認証を受入れ可能にする

デフォルトでは、OracleDefaultDomainはすべての認証タイプを受け入れるように構成されます。この構成を変更している場合または別のドメインを使用する場合は、Oracle Enterprise Manager Database ControlまたはGrid Controlを使用し、次の手順に従ってエンタープライズ・ドメインのKerberos認証を有効にします。

1. Enterprise Managerにログインします。

2. データベースの「サーバー」タブをクリックします。「セキュリティ」セクションで「エンタープライズ・ユーザー・セキュリティ」をクリックします。
「Oracle Internet Directoryログイン」ページが表示されます。

3. 「ユーザー」フィールドに、エンタープライズ・ユーザーを管理できるディレクトリ・ユーザーの識別名(DN)を入力します。「パスワード」フィールドに、ユーザー・パスワードを入力します。「ログイン」をクリックします。
「エンタープライズ・ユーザー・セキュリティ」ページが表示されます。

4. 「エンタープライズ・ドメインの管理」をクリックします。
「エンタープライズ・ドメインの管理」ページが表示されます。このページには、アイデンティティ管理レルム内のエンタープライズ・ドメインが一覧表示されます。

5. 「OracleDefaultDomain」を選択します。「構成」をクリックします。
「ドメインの構成」ページが表示されます。

6. 「構成」タブをクリックします。

7. 「許容されたユーザー認証タイプ」で、「Kerberos」を選択します。

8. 「OK」をクリックします。

タスク5: Kerberos認証エンタープライズ・ユーザーとしての接続

MITのKerberos V5などのKDCがオペレーティング・システムに組み込まれていない場合、ユーザーはokinitユーティリティを使用してFORWARDABLEフラグが設定されている初期チケットを取得する必要があります。『Oracle Database Advanced Security管理者ガイド』のokinitユーティリティを使用した初期チケットの取得に関する項を参照してください。

Windows 2000やLinuxまたはUNIXの一部のバージョンのように、KDCがオペレーティング・システムに組み込まれている場合は、ユーザーがログインすると、オペレーティング・システムによって(FORWARDABLEフラグが設定された)そのユーザーのチケットがキャッシュから自動的に取得されます。

ユーザーは、SQL*Plusを起動し、コマンドラインに次のコマンドを入力してデータベースに接続します。

SQL> connect /@<net_service_name>

データベースは、Kerberosを使用してユーザーを認証します。また、パスワードによってデータベース自体をディレクトリに対して認証します。

接続が成功した場合は、Connected to:...というメッセージが表示されます。このメッセージは、接続と設定が正常に行われたことを示す確認メッセージです。エラー・メッセージが表示された場合は、「Kerberos認証エンタープライズ・ユーザーに関するORA-#エラー」を参照してください。

正常に接続された場合は、SQL*Plusプロンプトに次のように入力して、ディレクトリから適切なグローバル・ロールが取得されたことを確認します。

select * from session_roles

グローバル・ロールがディレクトリから取得されなかった場合は、「グローバル・ロールがない場合のチェックリスト」を参照してください。

これで、Kerberos認証を使用するエンタープライズ・ユーザー・セキュリティの構成が完了しました。

関連項目:

- エラーの診断方法と解決方法は、「エンタープライズ・ユーザー・セキュリティのトラブルシューティング」を参照してください。

- アイデンティティ管理レルムの構成方法と、エンタープライズ・ドメイン、エンタープライズ・ロールおよびエンタープライズ・ユーザーの作成方法と管理方法は、第5章「エンタープライズ・ユーザー・セキュリティの管理」を参照してください。

4.5.3 SSL認証を使用するエンタープライズ・ユーザー・セキュリティの構成

この項で説明する構成手順は、次の設定を前提としています。

- 適切なPKI資格証明を取得し、エンタープライズ・ユーザー・セキュリティ実装に含めるディレクトリ、データベースおよびクライアントのウォレットの作成を、Oracle Wallet Managerを使用して終わらせている。

- Oracle Internet Directoryの各エンタープライズ・ユーザー・エントリが一意のPKI資格証明でプロビジョニングされていることを確認済である。ただし、このリリースでは、エンタープライズ・ユーザーのPKI証明書とOracle Internet Directoryエントリに異なるDNを指定できます。また、このリリースでは、データベース・エントリ自体のPKI証明書とOracle Internet Directoryエントリに異なるDNを指定できます。
証明書とディレクトリで異なるDNを使用できるようにするには、それぞれのOracle Internet Directoryユーザー・エントリにユーザー証明書をプロビジョニングする必要があります。ユーザー証明書は、ユーザー・エントリのusercertificate属性にプロビジョニングされます。証明書をプロビジョニングしない場合は、証明書の対象DNがディレクトリのユーザーDNと一致していることを確認する必要があります。

Oracle Internet Directory 10gリリース2 (10.1.2)には証明書一致ルールがあり、証明書とディレクトリで異なるDNを使用できるようにする新機能をサポートしています。Oracle Internet Directoryのorclpkimatchingrule属性によって、使用する一致タイプが決定します。

orclpkimatchingruleのデフォルト値は2です。この値により、プロビジョニングされたユーザー・エントリとプロビジョニングされていないユーザー・エントリの両方をサポートできます。データベースでは、ディレクトリにプロビジョニングされたユーザーの証明書を検索し、それに基づいてユーザーのOracle Internet Directory DNを検出します。証明書の検索に失敗すると、ユーザーの証明書DNとOracle Internet Directory DNで完全一致を使用する動作に戻ります。

すべてのユーザーの証明書がOracle Internet Directoryにプロビジョニングされている場合は、orclpkimatchingruleを1に設定できます。この値により、Oracle Internet Directoryは常に証明書検索を実行します。たとえば、認証局が証明書DNで2つの共通名をサポートしていない場合にディレクトリDNで2つの共通名を使用していると、すべてのユーザー証明書をディレクトリにプロビジョニングする必要があります。その後で、orclpkimatchingruleを1に設定できます。

PKI証明書とOracle Internet Directoryで異なるDNを使用する機能をサポートしない場合は、orclpkimatchingruleの値を0に設定できます。この設定は、すべての証明書DNがディレクトリDNと一致し、証明書をプロビジョニングしない場合に使用します。

独自のマッピング・ルールを作成して、証明書DNをOracle Internet Directory 10gリリース2 (10.1.2.0.2)のディレクトリDNにマップすることも可能です。マッピング・ルールを使用するには、orclpkimatchingruleを3または4に設定します。

すべてのユーザーに対してマッピング・ルールを使用する場合は、orclpkimatchingruleを3に設定します。証明書ベースの検索および完全一致もサポートする必要がある場合は、orclpkimatchingruleを4に設定します。

表4-2では、orclpkimatchingrule属性の各値について説明します。

表4-2 Oracle Internet Directoryの一致ルール

値

ルール

orclpkimatchingrule=0

完全一致。クライアント証明書の対象DNに基づいてバインドが実行されます。このDNは、ディレクトリ内のユーザーのDNと比較されます。

orclpkimatchingrule=1

証明書ハッシュ。証明書のハッシュされた値に基づいてバインドが実行されます。

orclpkimatchingrule=2

(デフォルト)

証明書ハッシュ/完全一致。証明書のハッシュされた値に基づいてバインドが実行されます。この操作に失敗すると、クライアント証明書の対象DNに基づいてバインドが実行されます。

orclpkimatchingrule=3

マッピング・ルールのみ。

orclpkimatchingrule=4

マッピング・ルール/証明書ハッシュ/完全一致。マッピング・ルールに基づいてバインドが実行されます。この操作に失敗すると、証明書のハッシュされた値に基づいてバインドが実行されます。さらに、この操作に失敗すると、証明書の完全一致に基づいてバインドが実行されます。

関連項目:
orclpkimatchingrule属性の変更方法は、『Oracle Internet Directory管理者ガイド』およびOracle Identity Managementのユーザー・リファレンス・ガイドを参照してください。

注意:
検索対象の証明書を持つユーザー・エントリがレルムのユーザー検索ベースに存在しない場合、または証明書の検索機能をサポートしていない古いバージョンのOracle Internet Directoryを使用している場合は、証明書の検索が失敗します。証明書の検索が失敗すると、データベースは、正常な接続を確立するために、ユーザーDNを証明書DNと照合する従来の動作に戻ります。

- 『Oracle Database Advanced Security管理者ガイド』のSSLの有効化に関する項の説明に従って、クライアント・データベースのOracle Net接続に対するSSLの有効化が終わっている。SSLを有効にしたときに、次の手順を実行していることを確認してください。

- TCPSのデータベース・リスナーに対してSSLを有効にし、対応するTNS名を指定した。

- データベースの登録時にDatabase Configuration Assistantによって自動的に作成されたデータベース・ウォレットに、データベースのPKI資格証明を格納した。

- 『Oracle Internet Directory管理者ガイド』の説明に従って、Oracle Internet Directoryでの双方向SSL認証インスタンスの構成を終えている。

- 「エンタープライズ・ユーザー・セキュリティのディレクトリの準備(フェーズ1)」で説明されているタスクを完了し、ディレクトリの準備を終えている。

- 「データベースおよびディレクトリでのエンタープライズ・ユーザー・セキュリティ・オブジェクトの構成(フェーズ2)」で説明されているタスクを完了し、データベースおよびディレクトリでのエンタープライズ・ユーザー・セキュリティ・オブジェクトの構成を終えている。

SSL認証を使用するエンタープライズ・ユーザー・セキュリティを構成するには、次のタスクを実行します。

- タスク1: エンタープライズ・ドメインでSSL認証を受入れ可能にする

- タスク2: SSLへのLDAP_DIRECTORY_ACCESS初期化パラメータの設定

- タスク3: SSL認証エンタープライズ・ユーザーとしての接続

タスク1: エンタープライズ・ドメインでSSL認証を受入れ可能にする

デフォルトでは、OracleDefaultDomainはすべての認証タイプを受け入れるように構成されます。この構成を変更している場合または別のドメインを使用する場合は、Oracle Enterprise Manager Database ControlまたはGrid Controlを使用し、次の手順に従ってエンタープライズ・ドメインのSSL認証を有効にします。

1. Enterprise Managerにログインします。

2. データベースの「サーバー」タブをクリックします。「セキュリティ」セクションで「エンタープライズ・ユーザー・セキュリティ」をクリックします。
「Oracle Internet Directoryログイン」ページが表示されます。

3. 「ユーザー」フィールドに、エンタープライズ・ユーザーを管理できるディレクトリ・ユーザーの識別名(DN)を入力します。「パスワード」フィールドに、ユーザー・パスワードを入力します。「ログイン」をクリックします。
「エンタープライズ・ユーザー・セキュリティ」ページが表示されます。

4. 「エンタープライズ・ドメインの管理」をクリックします。
「エンタープライズ・ドメインの管理」ページが表示されます。このページには、アイデンティティ管理レルム内のエンタープライズ・ドメインが一覧表示されます。

5. 「OracleDefaultDomain」を選択します。「構成」をクリックします。
「ドメインの構成」ページが表示されます。

6. 「構成」タブをクリックします。

7. 「許容されたユーザー認証タイプ」で、「SSL」を選択します。

8. 「OK」をクリックします。

タスク2: SSLへのLDAP_DIRECTORY_ACCESS初期化パラメータの設定

この初期化パラメータは、データベース初期化パラメータ・ファイルを編集するか、SET句を指定してALTER SYSTEM SQLコマンドを発行することで変更できます。

たとえば、次のALTER SYSTEMコマンドは、サーバー・パラメータ・ファイルのLDAP_DIRECTORY_ACCESSパラメータ値をSSLに変更します。

ALTER SYSTEM SET LDAP_DIRECTORY_ACCESS=SSL SCOPE=SPFILE

関連項目:

- 初期化パラメータの編集方法は、『Oracle Database管理者ガイド』を参照してください。

- LDAP_DIRECTORY_ACCESS初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

- SET句を指定してALTER SYSTEMコマンドを使用する方法は、『Oracle Database SQL言語リファレンス』を参照してください。

タスク3: SSL認証エンタープライズ・ユーザーとしての接続

SSL認証エンタープライズ・ユーザーとして接続する場合は、適切なOracleウォレット機能が構成されており、クライアントのsqlnet.oraファイルにウォレット・ロケーションが指定されていないことを確認します。クライアントのsqlnet.oraファイルにウォレット・ロケーションが含まれている場合、そのファイルは複数のユーザーおよびデータベースで共有できません。ウォレット・ロケーション・パラメータの値を指定する必要があるのは、サーバーのsqlnet.oraファイルのみです。

関連項目:
ユーザーとデータベース間でSSL認証を使用する場合におけるユーザーのウォレットのデフォルトの場所は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

SSL認証エンタープライズ・ユーザーとして接続するには、次の手順を実行します。

1. Oracle Wallet Managerを使用して、ディレクトリからユーザー・ウォレットをダウンロードします。『Oracle Database Advanced Security管理者ガイド』のLDAPディレクトリからのウォレットのダウンロードに関する項を参照してください。

2. Oracle Wallet Managerを使用して、ユーザー・ウォレットの自動ログインを有効にします。自動ログインを有効にすると、シングル・サインオン(.sso)ファイルが生成され、SSLアダプタに対する認証が可能になります。Oracle Wallet Managerの自動ログイン機能の使用方法は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

3. クライアントOracleホームがサーバーOracleホームを指している場合は、そのクライアントに対してTNS_ADMIN環境変数を(クライアントのsqlnet.oraファイルを指すように)設定します。(サーバーのsqlnet.oraファイルにはウォレット・ロケーションが設定されている必要があり、クライアントのsqlnet.oraファイルにはウォレット・ロケーションを指定できないため、サーバーとクライアントはこのファイルを共有できません。)
別のクライアントOracleホームがある場合は、TNS_ADMIN環境変数を設定する必要はありません。

4. SQL*Plusを起動し、コマンドラインに次のコマンドを入力します。

SQL> /@connect_identifier

connect_identiferは、データベース・クライアントに対してSSLを構成したときに設定したOracle Netのサービス名です。

接続が成功した場合は、Connected to:...というメッセージが表示されます。このメッセージは、接続と設定が正常に行われたことを示す確認メッセージです。エラー・メッセージが表示された場合は、「SSL認証エンタープライズ・ユーザーに関するORA-#エラー」を参照してください。

正常に接続された場合は、SQL*Plusプロンプトに次のように入力して、ディレクトリから適切なグローバル・ロールが取得されたことを確認します。

select * from session_roles

グローバル・ロールがディレクトリから取得されなかった場合は、「グローバル・ロールがない場合のチェックリスト」を参照してください。

これで、SSL認証を使用するエンタープライズ・ユーザー・セキュリティの構成が完了しました。

注意:
セキュリティ上の目的で、データベースとのエンタープライズ・ユーザー・セッションからログアウトした後は、ユーザー・ウォレットの自動ログインを無効にしてください。これは、クライアント・コンピュータを複数のユーザーで共有している場合に特に重要です。Oracle Wallet Managerを使用してOracleウォレットの自動ログインを無効にする方法は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

4.5.3.1 ウォレットおよびディレクトリ内のデータベースDNの表示

Database Configuration Assistantを使用してディレクトリにデータベースを登録すると、データベース・ウォレットとデータベース・ディレクトリ・エントリに対して同一のDNが自動的に作成されます。データベースDNを表示するには、次のオプションのいずれかを使用します。

Oracle Directory Managerを使用して、レルムOracleコンテキストの下にあるディレクトリ内で次を検索します。

cn=<short_database_name>,cn=OracleContext,<realm_DN>

short_database_nameは、データベースの完全修飾ドメイン名の最初の部分です。たとえば、db1.us.example.comというデータベースがある場合、データベースの短縮名はdb1です。

- コマンドラインで次のmkstoreユーティリティ構文を使用します。

mkstore -wrl <wallet_location> -viewEntry ORACLE.SECURITY.DN

wallet_locationは、データベース・ウォレットへのパスです。

関連項目:

- エラーの診断方法と解決方法は、「エンタープライズ・ユーザー・セキュリティのトラブルシューティング」を参照してください。

- アイデンティティ管理レルムの構成方法と、エンタープライズ・ドメイン、エンタープライズ・ロールおよびエンタープライズ・ユーザーの作成方法と管理方法は、第5章「エンタープライズ・ユーザー・セキュリティの管理」を参照してください。

4.6 現行ユーザーのデータベース・リンクの有効化

現行ユーザーのデータベース・リンクには、データベース間にSSL対応のネットワーク接続が必要です。現行ユーザーのデータベース・リンクを有効にする前に、関係するすべてのデータベースについて、SSLを有効にし、Oracleウォレットを作成してPKI資格証明を取得する必要があります。

次に、Oracle Enterprise Manager Database ControlまたはGrid Controlを使用し、次の手順に従ってディレクトリのエンタープライズ・ドメイン内のデータベース間で現行ユーザーのデータベース・リンクを有効にします。

1. Enterprise Managerにログインします。

2. 「サーバー」タブをクリックします。「セキュリティ」セクションで「エンタープライズ・ユーザー・セキュリティ」をクリックします。
「Oracle Internet Directoryログイン」ページが表示されます。

3. 「ユーザー」フィールドに、エンタープライズ・ユーザーを管理できるディレクトリ・ユーザーの識別名(DN)を入力します。「パスワード」フィールドに、ユーザー・パスワードを入力します。「ログイン」をクリックします。
「エンタープライズ・ユーザー・セキュリティ」ページが表示されます。

4. 「エンタープライズ・ドメインの管理」をクリックします。
「エンタープライズ・ドメインの管理」ページが表示されます。このページには、アイデンティティ管理レルム内のエンタープライズ・ドメインが一覧表示されます。

5. 構成するエンタープライズ・ドメインを選択します。「構成」をクリックします。
「ドメインの構成」ページが表示されます。

6. 「構成」タブをクリックします。

7. 「このドメインの現行ユーザーのデータベース・リンクを有効化します。」を選択します。

8. 「OK」をクリックします。

4.7 エンタープライズ・ユーザー・セキュリティのトラブルシューティング

この項では、発生する可能性のある問題とその対処方法を説明します。項目は次のとおりです。

- パスワード認証エンタープライズ・ユーザーに関するORA-#エラー

- Kerberos認証エンタープライズ・ユーザーに関するORA-#エラー

- SSL認証エンタープライズ・ユーザーに関するORA-#エラー

- グローバル・ロールがない場合のチェックリスト

- ユーザー・スキーマ・エラーのチェックリスト

- ドメイン読取りエラーのチェックリスト

4.7.1 パスワード認証エンタープライズ・ユーザーに関するORA-#エラー

パスワード認証を使用したエンタープライズ・ユーザー・セキュリティの使用時にORA-#エラーを受け取った場合は、次の項でエラーを検索して適切な処置を行ってください。

ORA-1017: 無効なユーザー名/パスワードです。ログインが拒否されました

原因: エラー・メッセージを参照してください。

処置: 「ユーザー・スキーマ・エラーのチェックリスト」を参照してください。

ORA-28030: LDAPディレクトリ・サービスへアクセス中にサーバーに問題が発生しました。

原因: データベースとディレクトリ間の接続に問題があることを示しています。

処置: 次の点を確認します。

1. デフォルトのウォレット・ロケーションを使用していない場合は、データベースのsqlnet.oraファイルに正しいwallet_location値が指定されていることを確認します。ウォレット・ロケーションは、Oracle Net Managerを使用して入力できます。デフォルトのウォレット・ロケーションを使用している場合は、sqlnet.oraファイルにウォレット・ロケーションを指定する必要はありません。sqlnet.oraファイルにウォレット・ロケーションが指定されている場合は、その値が正しいことを確認する必要があります。

2. Oracle Internet Directoryのドメイン・ネーム・システム(DNS)サーバー検出を使用していない場合は、$LDAP_ADMIN、$ORACLE_HOME/ldap/admin、$TNS_ADMINまたは$ORACLE_HOME/network/adminに正しいldap.oraファイルがあることを確認します。(DNSサーバー検出の詳細は、『Oracle Internet Directory管理者ガイド』を参照してください。)

3. (DNS検出またはldap.oraファイルで)使用されているSSLポートが、認証なしのSSLをサポートしていることを確認します。

4. データベース初期化パラメータ・ファイルのLDAP_DIRECTORY_ACCESSパラメータがPASSWORDに設定されていることを確認します。

5. Database Configuration Assistantを使用して、Oracle Internet Directoryに対するデータベースの認証に使用するデータベース・パスワードを再設定します。これにより、データベース・パスワードはデータベース・ウォレットでローカルに、またOracle Internet Directoryのデータベース・エントリでリモートに再設定されます。

6. データベース・ウォレットの自動ログインが有効になっていることを確認します。Oracle Wallet Managerを使用するか、$ORACLE_HOME/admin/<ORACLE_SID>/wallet/にcwallet.ssoファイルがあることを確認します。

7. データベース・ウォレットに格納されているパスワードを使用して、データベースをOracle Internet Directoryにバインドできることを確認します。

- mkstoreコマンドライン・ユーティリティを次の構文で使用し、ウォレットからデータベース・パスワードを取得します。

mkstore -wrl <database wallet location> -viewEntry ORACLE.SECURITY.PASSWORD

- 次のldapbindでmkstoreから戻されたパスワードを使用します。

ldapbind -h <directory host> -p <non-SSL directory port> -D "<database DN>" -q
Please enter bind password: Password returned by mkstore

8. データベースが1つのエンタープライズ・ドメインにのみ属していることを確認します。

注意:
mkstoreユーティリティは、トラブルシューティングの目的にのみ使用します。このツールの名前および機能は、将来変更される可能性があります。

ORA-28043: DB-OID接続のバインド資格証明が無効です

原因: データベースのディレクトリ・パスワードがディレクトリと同期していません。

処置: Database Configuration Assistantのパスワードの再生成ボタンを使用して、データベースの新規ディレクトリ・パスワードを生成し、ディレクトリと同期させてデータベース・ウォレットに格納します。

ORA-28271: LDAPディレクトリ・サービスのユーザー・エントリを読み込む権限がありません。

原因: エラー・メッセージを参照してください。

処置: 次の点を確認します。

1. Oracle Internet Directoryセルフ・サービス・コンソールを使用して、このユーザーを含むユーザー検索ベースが、使用しているレルムのユーザー検索ベース属性にリストされていることを確認します。

2. Oracle Internet Directoryでユーザー検索ベースに対するACLをチェックして、verifierServicesグループにユーザー・エントリの読取り権限があり、ディレクトリ・ツリーのユーザー検索ベース・エントリとユーザー・エントリ間でこの権限がACLによって無効になっていないことを確認します。

3. エンタープライズ・ドメインが、該当するレルムOracleコンテキストのパスワードでアクセス可能なドメイン・グループに含まれていることを確認します。

ORA-28272: ドメイン・ポリシーがパスワード・ベースのGLOBALユーザー認証を制限します。

原因: エラー・メッセージを参照してください。

処置: Oracle Enterprise Managerのインタフェースを使用して、このエンタープライズ・ドメインのユーザー認証ポリシーを「パスワード」または「ALL」に設定します。

ORA-28273: LDAP識別名へのユーザー・ニックネームのマッピングが存在しません。

原因: エラー・メッセージを参照してください。

処置: 次の点を確認します。

1. ユーザーのユーザー・エントリがOracle Internet Directoryに存在することを確認します。

2. Oracle Internet Directoryセルフ・サービス・コンソールを使用して、このユーザーを含むユーザー検索ベースが、使用しているアイデンティティ管理レルムにリストされていることを確認します。

3. ユーザー・エントリに正しいログイン名が含まれていることを確認します。

- Oracle Internet Directoryセルフ・サービス・コンソールを使用して、レルムのディレクトリに対して構成されているログイン名属性を見つけます。

- ユーザー・データベース・ログインの試行中に指定された名前が、ユーザー・ディレクトリ・エントリのその属性の値であることを確認します。

4. データベースにグローバル・ユーザーの排他スキーマがある場合は、データベースのDNがOracle Internet Directoryのユーザー・エントリのDNと一致することを確認します。

ORA-28274: ユーザー・ニックネームに対応するORACLEパスワード属性が存在しません。

原因: エラー・メッセージを参照してください。

処置: 次の点を確認します。

1. ディレクトリ内のユーザー・エントリにorcluserオブジェクト・クラスがあることを確認します。このクラスがない場合は、次の手順を実行します。

- Oracle Internet Directoryセルフ・サービス・コンソールを使用して、新規ユーザー作成用のデフォルト・オブジェクト・クラスにorcluserが含まれていることを確認してから、次のいずれかを実行します。

- Oracle Internet Directoryセルフ・サービス・コンソールを使用して、ユーザーを再作成します。

- orcluserおよびorcluserV2オブジェクト・クラスを追加します。

2. ユーザー・エントリにorclpassword属性の値があることを確認します。値がない場合は、ユーザーのディレクトリ・パスワード(userpassword属性)を再設定します。これにより、Oracle Internet Directoryはユーザーのデータベース・パスワード検証を再生成します。

3. Oracle Internet Directoryセルフ・サービス・コンソールを使用して、このユーザーを含むユーザー検索ベースが、使用しているレルムのユーザー検索ベース属性にリストされていることを確認します。

4. ユーザー検索ベース属性に対するACLで、verifierServicesグループによるorclpassword属性への読取りおよび検索アクセスが許可されていることを確認します。これは、デフォルトで正しく設定されますが、変更されている場合があります。

ORA-28275: LDAP識別名へのユーザー・ニックネームのマッピングが複数存在します。

原因: ユーザー検索ベース内のディレクトリに、ユーザーのログイン名がデータベース接続時に指定されたログイン名と一致する複数のユーザーDNがあります。

処置: Oracle Internet Directoryセルフ・サービス・コンソールを使用して、レルムOracleコンテキストと関連付けられているすべてのユーザー検索ベース内でログイン名値を一意にします(2つのユーザーが同じログイン名を共有しないようにします)。

ORA-28277: グローバル・ユーザーのパスワードでの認証中に、LDAP検索が失敗しました。

原因: エラー・メッセージを参照してください。

処置: 関連するディレクトリ・インスタンスが起動および稼働していることを確認します。

ORA-28278: パスワード・ベースのGLOBALユーザーのためのドメイン・ポリシーが登録されていません。

原因: データベースが、必要なエンタープライズ・ドメイン情報を読み取ることができません。

処置: 「ドメイン読取りエラーのチェックリスト」を参照してください。

ORA-28862: SSL接続に失敗しました。

原因: エラー・メッセージを参照してください。

処置: SSL以外の接続文字列を使用していることを確認します。

4.7.2 Kerberos認証エンタープライズ・ユーザーに関するORA-#エラー

Kerberos認証を使用したエンタープライズ・ユーザー・セキュリティの使用時にORA-#エラーを受け取った場合は、次の項でエラーを検索して適切な処置を行ってください。

ORA-1017: 無効なユーザー名/パスワードです。ログインが拒否されました

原因: エラー・メッセージを参照してください。

処置: 「ユーザー・スキーマ・エラーのチェックリスト」を参照してください。

ORA-28030: LDAPディレクトリ・サービスへアクセス中にサーバーに問題が発生しました。

原因: データベースとディレクトリ間の接続に問題があることを示しています。

処置: パスワード認証エンタープライズ・ユーザーのトラブルシューティングの項の「ORA-28030: LDAPディレクトリ・サービスへアクセス中にサーバーに問題が発生しました。」を解決するための処置を参照してください。

ORA-28271: LDAPディレクトリ・サービスのユーザー・エントリを読み込む権限がありません。

原因: エラー・メッセージを参照してください。

処置: パスワード認証エンタープライズ・ユーザーのトラブルシューティングの項の「ORA-28271: LDAPディレクトリ・サービスのユーザー・エントリを読み込む権限がありません。」を解決するための処置を参照してください。

ORA-28292: Kerberosベースの認証のためのドメイン・ポリシーが登録されていません

原因: エラー・メッセージを参照してください。

処置: 次の操作を実行します。

1. Oracle Enterprise Manager Database ControlまたはGrid Controlを使用して、このエンタープライズ・ドメインのユーザー認証ポリシーを「Kerberos」または「すべて」に設定します。

2. 「ドメイン読取りエラーのチェックリスト」を参照してください。

ORA-28290: 同じKerberosプリンシパル名に複数のエントリが見つかりました

原因: このユーザーのKerberosプリンシパル名が、このユーザーを含むユーザー検索ベース内で一意ではありません。

処置: Oracle Internet Directoryセルフ・サービス・コンソールを使用して、Kerberosプリンシパル名を変更するか、そのプリンシパル名が一意になるように他のコピーを変更します。

ORA-28291: Kerberosプリンシパル値が見つかりません。

原因: エラー・メッセージを参照してください。

処置: 次の点を確認します。

1. ディレクトリ内のユーザー・エントリにkrbprincipalname属性があることを確認します。
krbprincipalname属性がない場合は、次の点を確認します。

- Oracle Internet Directoryセルフ・サービス・コンソールを使用して、新規ユーザー作成用のデフォルト属性にkrbprincipalnameが含まれていることを確認してから、次のいずれかを実行します。

- Oracle Internet Directoryセルフ・サービス・コンソールを使用して、ユーザーを再作成します。

- orclcommonattributesオブジェクト・クラスを追加します。

2. ユーザー・エントリにkrbprincipalname属性の値があることを確認します。値がない場合は、Oracle Internet Directoryセルフ・サービス・コンソールを使用して入力します。

3. Oracle Internet Directoryセルフ・サービス・コンソールを使用して、このユーザーを含むユーザー検索ベースが、使用しているレルムOracleコンテキストにリストされていることを確認します。

4. ユーザー検索ベース属性に対するACLで、verifierServicesグループによるkrbprincipalname属性への読取りおよび検索アクセスが許可されていることを確認します。これは、デフォルトで正しく設定されますが、変更されている場合があります。

ORA-28293: 一致するKerberosプリンシパルが、どのユーザー・エントリにも見つかりません

原因: エラー・メッセージを参照してください。

処置: 次の点を確認します。

1. ユーザーのユーザー・エントリがOracle Internet Directoryに存在することを確認します。

2. Oracle Internet Directoryセルフ・サービス・コンソールまたはldapsearchを使用して、このユーザーを含むユーザー検索ベースが、使用しているアイデンティティ管理レルムにリストされていることを確認します。

3. 次の手順に従って、ディレクトリ内のユーザー・エントリに正しいKerberosプリンシパル名が含まれていることを確認します。

- Oracle Internet Directoryセルフ・サービス・コンソールを使用して、レルムのディレクトリに対して構成されているKerberosプリンシパル名属性を検索します。

- 正しいKerberosプリンシパル名がユーザーのディレクトリ・エントリのその属性に表示されることを確認します。

4. データベースにグローバル・ユーザーの排他スキーマがある場合は、データベースのDNがOracle Internet Directoryのユーザー・エントリのDNと一致することを確認します。

ORA-28300: LDAPディレクトリ・サービスのユーザー・エントリを読み込む権限がありません。

原因: エラー・メッセージを参照してください。

処置: データベース・ウォレットに、データベースとディレクトリ間の接続に使用する正しい資格証明が含まれていることを確認します。ウォレットDNは、Oracle Internet Directory内のデータベースのDNと同じであることが必要です。資格証明を取得するには、次の手順を実行します。

1. mkstoreコマンドライン・ユーティリティを次の構文で使用し、ウォレットのデータベース・パスワードを取得します。

mkstore -wrl <database wallet location> -viewEntry ORACLE.SECURITY.PASSWORD -viewEntry ORACLE.SECURITY.DN

2. これらの値が正しくない場合は、Database Configuration Assistantを使用してデータベース・ウォレットを再設定します。

3. 次のldapbindでmkstoreから戻されたDNおよびパスワードを使用します。

ldapbind -h <directory host> -p <non-SSL directory port> -D "<database DN>" -q
Please enter bind password: Password returned by mkstore

注意:
mkstoreユーティリティは、トラブルシューティングの目的にのみ使用します。このツールの名前および機能は、将来変更される可能性があります。

ORA-28302: LDAPディレクトリ・サービスにユーザーが存在しません。

原因: エラー・メッセージを参照してください。

処置: ユーザー・エントリがディレクトリに存在することを確認します。

4.7.3 SSL認証エンタープライズ・ユーザーに関するORA-#エラー

SSL認証を使用したエンタープライズ・ユーザー・セキュリティの使用時にORA-#エラーを受け取った場合は、次の項でエラーを検索して適切な処置を行ってください。

ORA-1017: 無効なユーザー名/パスワードです。ログインが拒否されました

原因: エラー・メッセージを参照してください。

処置: 「ユーザー・スキーマ・エラーのチェックリスト」を参照してください。

ORA-28030: LDAPディレクトリ・サービスへアクセス中にサーバーに問題が発生しました。

原因: データベースとディレクトリ間の接続に問題があることを示しています。

処置: 次の点を確認します。

1. データベースのsqlnet.oraファイルに、正しいwallet_location値があることを確認します。値がない場合は、Oracle Net Managerを使用して入力します。

2. Oracle Internet Directoryのドメイン・ネーム・システム(DNS)サーバー検出を使用していない場合は、$LDAP_ADMIN、$ORACLE_HOME/ldap/admin、$TNS_ADMINまたは$ORACLE_HOME/network/adminに正しいldap.oraファイルがあることを確認します。(DNSサーバー検出の詳細は、『Oracle Internet Directory管理者ガイド』を参照してください。)

3. (DNS検出またはldap.oraファイルで)使用されているOracle Internet DirectoryのSSLポートが、双方向SSL認証をサポートしていることを確認します。

4. データベース初期化パラメータ・ファイルのLDAP_DIRECTORY_ACCESSパラメータがSSLに設定されていることを確認します。

5. データベース・ウォレットの自動ログインが有効になっていることを確認します。Oracle Wallet Managerを使用するか、$ORACLE_HOME/admin/<ORACLE_SID>/wallet/にcwallet.ssoファイルがあることを確認します。

6. mkstoreコマンドライン・ユーティリティを次の構文で使用し、データベース・ウォレットにデータベースDNが含まれていることを確認します。

mkstore -wrl <database_wallet_location> -viewEntry ORACLE.SECURITY.DN

ウォレットにデータベースDNが含まれていない場合は、Database Configuration Assistantを使用して、データベースをOracle Internet Directoryに再登録します。

7. 次のldapbindでデータベース・ウォレットを使用して、そのデータベースがOracle Internet Directoryにバインドできることを確認します。

ldapbind -h <directory_host> -p <directory_SSLport> -U 3 -W "file:<database wallet_location>" -Q
Please enter SSL wallet password: wallet_password

8. データベースが1つのエンタープライズ・ドメインにのみ属していることを確認します。

注意:
mkstoreユーティリティは、トラブルシューティングの目的にのみ使用します。このツールの名前および機能は、将来変更される可能性があります。

ORA-28301: SSL認証のためのドメイン・ポリシーが登録されていません。

原因: エラー・メッセージを参照してください。

処置: Oracle Enterprise Manager Database ControlまたはGrid Controlを使用して、このエンタープライズ・ドメインのユーザー認証ポリシーにSSLが含まれるように設定します。

ORA-28862: SSLハンドシェイクに失敗しました

原因: エラー・メッセージを参照してください。

処置: SSL接続の構成方法は、『Oracle Database Advanced Security管理者ガイド』のSecure Sockets Layer(SSL)に関する章を参照してください。

4.7.4 グローバル・ロールがない場合のチェックリスト

エンタープライズ・ユーザーはデータベースに接続できるが、select * from session_rolesでグローバル・ロールが戻されない場合には、次の点を確認します。

1. グローバル・ロールがデータベースに作成されていることを確認します。グローバル・ロールを作成するには、次の構文を使用します。

CREATE ROLE <role_name> IDENTIFIED GLOBALLY;

2. Oracle Enterprise Managerを使用して、ディレクトリのエンタープライズ・ロールにグローバル・ロールが含まれていることを確認します。

3. Oracle Enterprise Managerを使用して、ディレクトリのユーザーにエンタープライズ・ロールが割り当てられていることを確認します。

4. これらの確認に問題がない場合は、「ドメイン読取りエラーのチェックリスト」を参照してください。

4.7.5 ユーザー・スキーマ・エラーのチェックリスト

データベースがユーザー・スキーマを読み取ることができない場合は、次の点を確認します。

1. これがSSL認証エンタープライズ・ユーザーである場合、次の両方をチェックして正しいユーザー・ウォレットが使用されていることを確認します。

- クライアントのsqlnet.oraファイルにWALLET_LOCATIONパラメータ値がないこと。

- 正しいsqlnet.oraファイルが使用されるように、TNS_ADMINパラメータが適切に設定されていること。

2. 次の構文を使用して、グローバル・ユーザーとしてデータベースにスキーマが作成されていることを確認します。

CREATE USER username IDENTIFIED GLOBALLY AS ' ';

または、次の構文を使用します。

CREATE USER username IDENTIFIED GLOBALLY AS '<DN>';

3. 次に当てはまることを確認します。

- ユーザー・スキーマが排他スキーマであること(CREATE USER username IDENTIFIED GLOBALLY AS 'user_DN';構文で作成されたスキーマ)。

- SSL認証ユーザーであること。

当てはまる場合は、ユーザー・ウォレットのDNがCREATE USER文で使用されたDNと一致していることを確認します。

Oracle Wallet Managerを使用して、ユーザー・ウォレットのDNを表示します。

次の構文を使用してCREATE USER文で使用されたDNを表示します。

SELECT EXTERNAL_NAME FROM DBA_USERS WHERE USERNAME='schema';

4. 共有スキーマを使用している場合は、次の点を確認します。

- Oracle Enterprise Manager Database ControlまたはGrid Controlを使用して、エンタープライズ・ドメイン全体またはデータベースのいずれかに対してユーザー・スキーマ・マッピングを作成していることを確認します。

- ユーザー・スキーマ・マッピングが(エンタープライズ・ドメイン全体ではなく)このデータベースへの適用を目的としている場合は、そのデータベースがディレクトリ内のそのデータベース自体のエントリまたはサブツリーを読み取ることができることを確認します。
それを確認するには、データベースとディレクトリ間の接続タイプについて次のldapsearchコマンドを入力します。

- データベースがSSLを介してディレクトリに接続する場合は、次のコマンドを使用します。

ldapsearch -h directory_host -p directory_SSLport -U 3 -W "file:database_wallet_path" -Q -b "database_DN" "objectclass=*"
Please enter SSL wallet password: wallet_password

wallet_passwordは、ウォレットのオープンや変更を可能にするウォレットに対するパスワードです。

- データベースがパスワード認証を使用してディレクトリに接続する場合は、次のコマンドを使用します。

ldapsearch -h directory_host -p directory_port -D database_DN -q -b "database_DN" "objectclass=*"
Please enter bind password: database_directory_password

database_directory_passwordは、mkstoreなどのユーティリティから戻されたデータベースのバインド・パスワードです。

データベース・エントリおよび関連するマッピングが表示されます。

- ユーザー・スキーマ・マッピングがこのデータベースだけでなくエンタープライズ・ドメイン全体に適用される場合は、「ドメイン読取りエラーのチェックリスト」を参照してください。

4.7.6 ドメイン読取りエラーのチェックリスト

データベースがOracle Internet Directoryのエンタープライズ・ドメイン情報を読み取ることができない場合は、次の点を確認します。

1. Oracle Enterprise Manager Database ControlまたはGrid Controlを使用して、データベースが正確に1つのエンタープライズ・ドメインのメンバーであることを確認し、メンバーでない場合は追加します。

2. コマンドラインに次のコマンドのいずれかを入力し、データベースがそれ自体のドメインを参照できることを確認します。

- データベースがSSLを介してディレクトリに接続する場合は、次のコマンドを使用します。

ldapsearch -h directory_host -p directory_SSLport -U 3 -W "file:database_wallet_path" -Q -b "cn=OracleContext, realm_DN" "objectclass=orclDBEnterpriseDomain"
Please enter SSL wallet password: wallet_password

wallet_passwordは、ウォレットのオープンや変更を可能にするウォレットに対するパスワードです。

- データベースがパスワード認証を使用してディレクトリに接続する場合は、次のコマンドを使用します。

ldapsearch -h directory_host -p directory_port -D database_DN -q -b "cn=OracleContext, realm_DN" "objectclass=orclDBEnterpriseDomain"
Please enter bind password: database_directory_password

database_directory_passwordは、データベース・ウォレット内のパスワードで、Oracle Internet Directoryに対するデータベースのパスワードです。

このldapsearchコマンドが戻すのは、1つのエンタープライズ・ドメインのみです。

ドメインが戻されず、Oracle Enterprise Managerにデータベースがドメインのメンバーとして表示される場合は、データベースを再起動します。データベースを再起動すると、エンタープライズ・ドメインのキャッシュ値が更新されます。

複数のドメインが戻された場合は、Oracle Enterprise Managerを使用して他のドメインからデータベースを削除します。

3. コマンドラインで次のコマンドのいずれかを入力し、データベースがエンタープライズ・ドメインのサブツリーを読み取ることができ、その結果、エンタープライズ・ロールとマッピングを読み取ることができることを確認します。

- データベースがSSLを介してディレクトリに接続する場合は、次のコマンドを使用します。

ldapsearch -h directory_host -p directory_SSLport -U 3 -W "file:database_wallet_path" -Q -b "cn=OracleContext, realm_DN" "objectclass=orclDBEnterpriseRole"
Please enter SSL wallet password: wallet_password

wallet_passwordは、ウォレットのオープンや変更を可能にするウォレットに対するパスワードです。

- データベースがパスワード認証を使用してディレクトリに接続する場合は、次のコマンドを使用します。

ldapsearch -h directory_host -p directory_port -D database_DN -q -b "cn=OracleContext, realm_DN" "objectclass=orclDBEnterpriseRole"
Please enter bind password: database_directory_password

database_directory_passwordは、データベース・ウォレット内のパスワードで、Oracle Internet Directoryに対するデータベースのパスワードです。

このldapsearchは、このドメインに対して作成したすべてのエンタープライズ・ロールを戻します。戻されない場合は、Oracle Enterprise Managerを使用してエンタープライズ・ロールとマッピングを作成します。

4. Oracle Enterprise Manager Database ControlまたはGrid Controlを使用して、関連するエンタープライズ・ドメインのユーザー認証ポリシーを設定または再設定します。エンタープライズ・ドメインのユーザー認証ポリシーの設定方法は、「ユーザー認証タイプの構成と現行ユーザーのデータベース・リンクの有効化」を参照してください。

5 エンタープライズ・ユーザー・セキュリティの管理

この章では、Oracle Enterprise Managerを使用してOracle Databaseのエンタープライズ・ユーザー・セキュリティを管理する方法を説明します。この章では、次の項目について説明します。

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

- エンタープライズ・ユーザーの管理

- ユーザー定義のエンタープライズ・グループの構成

- エンタープライズ・ユーザー・セキュリティ用のデータベースの構成

- エンタープライズ・ドメインの管理

5.1 アイデンティティ管理レルムの管理

アイデンティティ管理レルムは、ディレクトリ・エントリのサブツリーであり、そのすべてが同じ管理ポリシーによって管理されます。レルムOracleコンテキストは、ディレクトリ・アイデンティティ管理レルム内のサブツリーであり、ディレクトリを使用するインストール済のOracle製品によって使用されるデータが含まれます。

アイデンティティ管理レルムのプロパティは、Oracle Internet Directoryセルフ・サービス・コンソールなどのOracle Internet Directoryツールを使用して設定できます。

Oracle Enterprise Manager Database ControlまたはGrid ControlのWebインタフェースを使用すると、アイデンティティ管理レルム内のエンタープライズ・ユーザー・セキュリティ関連のエントリを管理できます。

この項では、エンタープライズ・ユーザー・セキュリティのアイデンティティ管理レルムを管理する方法を説明します。ここでは、次の項目について説明します。

- アイデンティティ管理レルムのバージョン

- アイデンティティ管理レルムのプロパティの設定

- アイデンティティ管理レルムに対するデータベースとディレクトリ間のデフォルト認証タイプの設定

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

注意:
レルムOracleコンテキスト内にユーザーを作成しないでください。

関連項目:

- アイデンティティ管理レルムとレルムOracleコンテキスト、およびこれらの相互関連の詳細は、「Oracle Internet Directoryでアイデンティティ管理を実装する方法」を参照してください。

- エンタープライズ・ユーザー・セキュリティに使用されるOracle Internet Directoryエントリの詳細は、「エンタープライズ・ユーザー・セキュリティのディレクトリ・エントリについて」を参照してください。

5.1.1 アイデンティティ管理レルムのバージョン

エンタープライズ・ユーザー・セキュリティで使用できるのは、Oracle Application Server 10g (9.0.4)以上に同梱されているOracle Internet Directory 10g (9.0.4)以上で提供されるアイデンティティ管理レルムのみです。リリース9.0.4(以上)のアイデンティティ管理レルム内のエンタープライズ・ユーザー・セキュリティのディレクトリ・エントリは、Oracle Database 11gリリース2(11.2)用のOracle Enterprise Managerを使用して管理できます。

5.1.2 アイデンティティ管理レルムのプロパティの設定

アイデンティティ管理レルムには、Oracle Internet Directoryセルフ・サービス・コンソールなどのOracle Internet Directoryツールを使用して表示および管理できるプロパティが多数あります。表5-1では、これらのプロパティを説明します。

表5-1 アイデンティティ管理レルムのプロパティ

プロパティ

説明

ログイン名の属性

ログイン名の格納に使用するディレクトリ属性の名前。デフォルトでは、ログイン名はuid属性に格納されますが、ディレクトリ構成に応じて変更できます。以前のリリースでは、この属性はcn属性でした。

Kerberosプリンシパル名の属性

Kerberosプリンシパル名の格納に使用するディレクトリ属性の名前。デフォルトでは、Kerberosプリンシパル名はkrbPrincipalNameディレクトリ属性に格納されますが、アイデンティティ管理レルムのorclCommonKrbPrincipalAttributeを変更することにより、ディレクトリ構成に応じて変更できます。

ユーザー検索ベース

ディレクトリに格納されているエンタープライズ・ユーザーのノードに対する完全識別名(DN)。

グループ検索ベース

このアイデンティティ管理レルムに対してディレクトリに格納されているユーザー・グループのノードに対する完全DN。

バージョンの互換性

このプロパティはすでに使用されていません。ただし、リリース8.1.7以前のデータベースは、Oracle Database 10g以上のデータベースと同じレルム内に存在できないため、それが81000に設定されていないことを確認する必要があります。

注意:
各アイデンティティ管理レルムには、そのレルムのみのルート・ユーザーであるorcladminユーザーが含まれます。これらのレルム固有のorcladminユーザーは、ディレクトリ・エントリcn=orcladmin,cn=Users,realm_DNで表されます。レルム固有のorcladminユーザーとしてエンタープライズ・ユーザー・セキュリティ管理ツールにログインしている場合は、そのレルムのディレクトリ・オブジェクトのみ管理できます。別のレルムのオブジェクトを管理するには、そのレルムのorcladminユーザーとして管理ツールにログインする必要があります。

5.1.2.1 アイデンティティ管理レルムのログイン名、Kerberosプリンシパル名、ユーザー検索ベースおよびグループ検索ベースの各属性の設定

これらのアイデンティティ管理レルムの属性を設定すると、データベースはエンタープライズ・ユーザー・セキュリティのエントリを特定できます。

アイデンティティ管理レルムのログイン名、Kerberosプリンシパル名、ユーザー検索ベースおよびグループ検索ベースの各属性を設定する手順:

1. Oracle Internet Directoryセルフ・サービス・コンソールにログインします。
ブラウザ・ウィンドウにOracle Internet Directoryセルフ・サービス・コンソールにアクセスするためのURLを入力します。次に例を示します。

http://myhost1:7777/oiddas

orcladminユーザーとしてログインします。

2. 「構成」タブをクリックします。「アイデンティティ管理レルム」サブタブをクリックします。
「ディレクトリ構成」ページが表示されます。

3. 使用可能なフィールドに適切な情報を入力します。

4. 「送信」をクリックし、変更内容をディレクトリに保存します。

関連項目:
Oracle Internet Directoryセルフ・サービス・コンソールの使用方法は、『Oracle Identity Management委任管理ガイド』を参照してください。

5.1.3 アイデンティティ管理レルムに対するデータベースとディレクトリ間のデフォルト認証タイプの設定

LDAP_DIRECTORY_ACCESSパラメータの初期値は、レルム・レベルのデータベースとディレクトリ間のデフォルトの認証属性設定から取得されます。このパラメータは、Oracle Internet Directoryへの登録時に個々のデータベースに設定されます。

Oracle Enterprise Manager Database ControlまたはGrid Controlのインタフェースを使用すると、データベースでOracle Internet Directoryに対する認証に使用する認証メカニズムを設定できます。認証メカニズムは、パスワードまたはSSLに設定できます。

アイデンティティ管理レルムに対するデータベースとディレクトリ間のデフォルト認証タイプを設定する手順:

1. Enterprise Managerにログインします。

2. 「サーバー」タブをクリックします。「セキュリティ」セクションで「エンタープライズ・ユーザー・セキュリティ」をクリックします。
「Oracle Internet Directoryログイン」ページが表示されます。

3. 「ユーザー」フィールドに、エンタープライズ・ユーザーを管理できるディレクトリ・ユーザーの識別名(DN)を入力します。「パスワード」フィールドに、ユーザー・パスワードを入力します。「ログイン」をクリックします。
「エンタープライズ・ユーザー・セキュリティ」ページが表示されます。

4. 「OIDレルム管理」をクリックします。
「OIDレルム管理」ページが表示されます。現在のDB-OID認証方式が表示されます。

5. 現在のDB-OID認証方式を変更するには、「変更」をクリックします。
「レルム構成」ページが表示されます。

6. 「DB-OID認証」で「パスワード」または「SSL」を選択します。

7. レルム内のすべてのデータベースおよびクライアントがリリース10g以上である場合は、パスワード検証機能を無効にできます。この機能は、10gより前のデータベース用の追加パスワード・フィールドを移入するためにディレクトリによって使用されます。パスワード検証を無効にするには、「パスワード検証」を選択解除します。

8. 「OK」をクリックします。

5.1.4 アイデンティティ管理レルム管理者の管理

アイデンティティ管理レルムには、様々なレベルの権限を持つ管理グループが含まれています。表5-2に、エンタープライズ・ユーザー・セキュリティに関連するアイデンティティ管理レルムの管理グループを定義します。これらのグループの詳細は、「管理グループ」を参照してください。

表5-2 エンタープライズ・ユーザー・セキュリティのアイデンティティ管理レルム管理者

管理グループ

定義

Oracle Database登録管理者

(OracleDBCreators)

新しいデータベースをレルムに登録します。

Oracle Databaseセキュリティ管理者

(OracleDBSecurityAdmins)

OracleDBSecurityディレクトリ・サブツリーに対するすべての権限を持ちます。エンタープライズ・ユーザー・セキュリティのすべてのディレクトリ・オブジェクトの作成、変更および読取りができます。

Oracleコンテキスト管理者

(OracleContextAdmins)

関連付けられたレルム内のすべてのグループとエントリに対する完全なアクセス権を持ちます。

ユーザー・セキュリティ管理者

(OracleUserSecurityAdmins)

ディレクトリ内のエンタープライズ・ユーザーのセキュリティ管理に必要な関連する権限を持ちます。たとえば、OracleUserSecurityAdminsはユーザー・パスワードを変更できます。

アイデンティティ管理レルム管理者を管理する手順:

1. Enterprise Managerにログインします。

2. 「サーバー」タブをクリックします。「セキュリティ」セクションで「エンタープライズ・ユーザー・セキュリティ」をクリックします。
「Oracle Internet Directoryログイン」ページが表示されます。

3. 「ユーザー」フィールドに、エンタープライズ・ユーザーを管理できるディレクトリ・ユーザーの識別名(DN)を入力します。「パスワード」フィールドに、ユーザー・パスワードを入力します。「ログイン」をクリックします。
「エンタープライズ・ユーザー・セキュリティ」ページが表示されます。

4. 「OIDレルム管理」をクリックします。
「OIDレルム管理」ページが表示されます。このページには、アイデンティティ管理レルム内のエンタープライズ・ユーザー・セキュリティ関連の管理グループが一覧表示されます。

5. 編集する管理グループを選択します。「編集」をクリックします。
「編集」ページが表示されます。「OIDレルム管理」ページで選択したグループの現在のメンバーであるディレクトリ・ユーザーが一覧表示されます。

6. ディレクトリ・ユーザーをグループに追加するには、「追加」をクリックします。
「ユーザーの選択」ウィンドウが表示されます。

7. 「検索ベース」を選択します。検索ベースは、ユーザーを探すために検索するディレクトリ・サブツリーです。「ジャンプ」をクリックします。

8. 管理者として追加するユーザーを選択します。「選択」をクリックします。
「編集」ページにユーザーが追加されます。

9. 「OK」をクリックします。

5.2 エンタープライズ・ユーザーの管理

この項では、Oracle Internet Directoryセルフ・サービス・コンソールおよびOracle Enterprise Managerを使用してエンタープライズ・ユーザーを管理する方法を説明します。ここでは、次の項目について説明します。

- 新規エンタープライズ・ユーザーの作成

- エンタープライズ・ユーザー・パスワードの設定

- エンタープライズ・ユーザーへのエンタープライズ・ロールの付与

- エンタープライズ・ユーザーへのプロキシ権限の付与

- エンタープライズ・ユーザーのユーザー・スキーマ・マッピングの作成

- エンタープライズ・ユーザーのラベル認可の作成

5.2.1 新規エンタープライズ・ユーザーの作成

Oracle Internet Directoryセルフ・サービス・コンソールなどのOracle Internet Directoryツールを使用すると、ディレクトリにユーザーを作成できます。

注意:
新規エンタープライズ・ユーザーを作成する前に、ユーザー検索ベースをディレクトリに定義し、また、ユーザー作成ベースを検証する必要があります。「ログイン名、Kerberosプリンシパル名、ユーザー検索ベースおよびグループ検索ベースのID管理レルム属性の設定」を参照してください。

新しいエンタープライズ・ユーザーを作成する手順:

1. Oracle Internet Directoryセルフ・サービス・コンソールにログインします。
ブラウザ・ウィンドウにOracle Internet Directoryセルフ・サービス・コンソールにアクセスするためのURLを入力します。次に例を示します。

http://myhost1:7777/oiddas

orcladminユーザーとしてログインします。

2. 「ディレクトリ」タブをクリックします。「ユーザー」サブタブをクリックします。
「ユーザー」ページが表示されます。

3. 「作成」をクリックして新しいユーザーを作成します。
「ユーザーの作成」ページが表示されます。

4. 「ユーザーの作成」ページで適切なユーザー情報を入力します。「送信」をクリックして新しいエンタープライズ・ユーザーを作成します。

注意:
ユーザーのデータベースに対する認証がKerberos資格証明を使用して行われており、krbPrincipalName属性が表示されていない場合、この属性の構成方法は「タスク1: Kerberosプリンシパル名属性を表示するためのOracle Internet Directoryセルフ・サービス・コンソールの構成」を参照してください。

5.2.2 エンタープライズ・ユーザー・パスワードの設定

Oracle Internet Directoryセルフ・サービス・コンソールを使用すると、Oracle Internet Directoryでエンタープライズ・ユーザー・パスワードを設定および管理できます。

エンタープライズ・ユーザー・パスワードは、次の用途で使用されます。

- ディレクトリ・ログイン

- グローバル・ユーザーのパスワード認証をサポートするデータベースへのデータベース・ログイン

エンタープライズ・ユーザーのパスワードを設定する手順:

1. Oracle Internet Directoryセルフ・サービス・コンソールにログインします。
ブラウザ・ウィンドウにOracle Internet Directoryセルフ・サービス・コンソールにアクセスするためのURLを入力します。次に例を示します。

http://myhost1:7777/oiddas

orcladminユーザーとしてログインします。

2. 「ディレクトリ」タブをクリックします。「ユーザー」サブタブをクリックします。
「ユーザー」ページが表示されます。

3. 「検索」フィールドに、エンタープライズ・ユーザーのユーザー名(ログイン名)または電子メール・アドレスの一部を入力します。「ジャンプ」をクリックします。
検索基準に合致するすべてのユーザーのリストが表示されます。

4. 新規パスワードを作成するユーザーを選択します。「編集」をクリックします。
「ユーザーの編集」ページが表示されます。

5. 「パスワード」フィールドに、新規パスワードを入力します。「パスワードの確認」フィールドでパスワードを確認します。「送信」をクリックします。

5.2.3 エンタープライズ・ユーザーへのエンタープライズ・ロールの付与

エンタープライズ・ロールは、様々なデータベースのグローバル・ロールをグループ化できるようにするディレクトリ・オブジェクトです。エンタープライズ・ロールをエンタープライズ・ユーザーに割り当てて、エンタープライズ・データベースに対する権限を付与できます。

エンタープライズ・ロールをエンタープライズ・ユーザーに付与するには、次のようにします。

1. Enterprise Managerにログインします。

2. 「サーバー」タブをクリックします。「セキュリティ」セクションで「エンタープライズ・ユーザー・セキュリティ」をクリックします。
「Oracle Internet Directoryログイン」ページが表示されます。

3. 「ユーザー」フィールドに、エンタープライズ・ユーザーを管理できるディレクトリ・ユーザーの識別名(DN)を入力します。「パスワード」フィールドに、ユーザー・パスワードを入力します。「ログイン」をクリックします。
「エンタープライズ・ユーザー・セキュリティ」ページが表示されます。

4. 「エンタープライズ・ユーザーの構成」をクリックします。
エンタープライズ・ユーザーの構成ページが表示されます。

5. エンタープライズ・ユーザーを検索する「検索ベース」を選択します。検索ベースは、エンタープライズ・ユーザー・エントリが含まれるサブツリーです。必要に応じて、「名前」フィールドにエンタープライズ・ユーザーの共通名を入力できます。「表示」ボックスで「USER」を選択します。「ジャンプ」をクリックします。
基準に合致するユーザーのリストが表示されます。

6. 構成するエンタープライズ・ユーザーを選択します。「構成」をクリックします。
「ユーザーの構成」ページが表示されます。

7. 「エンタープライズ・ロール」タブをクリックします。

8. 「権限」をクリックします。
エンタープライズ・ロールの選択ウィンドウが表示されます。

9. 付与するエンタープライズ・ロールを選択します。「選択」をクリックします。

10. 「ユーザーの構成」ページで「OK」をクリックします。

5.2.4 エンタープライズ・ユーザーへのプロキシ権限の付与

プロキシ権限により、エンタープライズ・ユーザーはローカル・データベース・ユーザーの代わりとなることができます。つまり、エンタープライズ・ユーザーはローカル・データベース・ユーザーとしてデータベースにログインできます。プロキシ権限は、個々のユーザーまたはグループに付与できます。プロキシ権限は、複数のデータベース間でエンタープライズ・ユーザーとして動作する中間層アプリケーションでは特に有用です。

プロキシ権限はエンタープライズ・ドメイン・レベルで作成されます。作成されたエンタープライズ・ドメインのプロキシ権限は、エンタープライズ・ユーザーに付与できます。

プロキシ権限をエンタープライズ・ユーザーに付与するには、次のようにします。

1. Enterprise Managerにログインします。

2. 「サーバー」タブをクリックします。「セキュリティ」セクションで「エンタープライズ・ユーザー・セキュリティ」をクリックします。
「Oracle Internet Directoryログイン」ページが表示されます。

3. 「ユーザー」フィールドに、エンタープライズ・ユーザーを管理できるディレクトリ・ユーザーの識別名(DN)を入力します。「パスワード」フィールドに、ユーザー・パスワードを入力します。「ログイン」をクリックします。
「エンタープライズ・ユーザー・セキュリティ」ページが表示されます。

4. 「エンタープライズ・ユーザーの構成」をクリックします。
エンタープライズ・ユーザーの構成ページが表示されます。

5. エンタープライズ・ユーザーを検索する「検索ベース」を選択します。検索ベースは、エンタープライズ・ユーザー・エントリが含まれるサブツリーです。必要に応じて、「名前」フィールドにエンタープライズ・ユーザーの共通名を入力できます。「表示」ボックスで「USER」を選択します。「ジャンプ」をクリックします。
基準に合致するユーザーのリストが表示されます。

6. 構成するエンタープライズ・ユーザーを選択します。「構成」をクリックします。
「ユーザーの構成」ページが表示されます。

7. 「プロキシ権限」タブをクリックします。

8. 「権限」をクリックします。
プロキシ権限の選択ウィンドウが表示されます。

9. 付与するプロキシ権限を選択します。プロキシ権限は、エンタープライズ・ドメインに対してすでに作成されている必要があります。「選択」をクリックします。

10. 「ユーザーの構成」ページで「OK」をクリックします。

5.2.5 エンタープライズ・ユーザーのユーザー・スキーマ・マッピングの作成

ユーザー・スキーマ・マッピングは、エンタープライズ・ユーザーをグローバル・データベース・スキーマにマップします。エンタープライズ・ユーザーがデータベースにログインすると、デフォルトにより、マップされたスキーマに接続されます。

ユーザー・スキーマ・マッピングを作成するには、次のようにします。

1. Enterprise Managerにログインします。

2. 「サーバー」タブをクリックします。「セキュリティ」セクションで「エンタープライズ・ユーザー・セキュリティ」をクリックします。
「Oracle Internet Directoryログイン」ページが表示されます。

3. 「ユーザー」フィールドに、エンタープライズ・ユーザーを管理できるディレクトリ・ユーザーの識別名(DN)を入力します。「パスワード」フィールドに、ユーザー・パスワードを入力します。「ログイン」をクリックします。
「エンタープライズ・ユーザー・セキュリティ」ページが表示されます。

4. 「エンタープライズ・ユーザーの構成」をクリックします。
エンタープライズ・ユーザーの構成ページが表示されます。

5. エンタープライズ・ユーザーを検索する「検索ベース」を選択します。検索ベースは、エンタープライズ・ユーザー・エントリが含まれるサブツリーです。必要に応じて、「名前」フィールドにエンタープライズ・ユーザーの共通名を入力できます。「表示」ボックスで「USER」を選択します。「ジャンプ」をクリックします。
基準に合致するユーザーのリストが表示されます。

6. 構成するエンタープライズ・ユーザーを選択します。「構成」をクリックします。
「ユーザーの構成」ページが表示されます。

7. 「ユーザー・スキーマ・マッピング」タブをクリックします。ユーザーに直接または間接的に適用されているユーザー・スキーマ・マップがすべて表示されます。
ユーザーは個別にスキーマにマップできます。あるいは、複数のユーザーを含むディレクトリ・サブツリーをデータベース・スキーマにマップすることもできます。

8. 「作成」をクリックします。
「マッピングの作成」ページが表示されます。

9. 「自」セクションで、「ユーザー」を選択して個々のエンタープライズ・ユーザーをデータベース・スキーマにマップします。あるいは、「サブツリー」を選択して複数のユーザーが含まれるディレクトリ・サブツリーをマップします。

10. 「至」で、データベース・スキーマにマップするには、「データベース」を選択します。エンタープライズ・ドメイン内のすべてのデータベースに共通するスキーマにマップするには、「ドメイン」を選択します。
エンタープライズ・ドメイン内には、共通スキーマ名を持つ複数のデータベースを保持できます。エンタープライズ・ユーザーをこのようなスキーマにマップすると、そのエンタープライズ・ユーザーはドメインに含まれる各データベースの個々のスキーマに自動的にマップされます。

11. 前の手順で「データベース」を選択した場合、スキーマを含むデータベースの名前を選択します。次に、データベース・スキーマ名を入力します。検索アイコンを使用してスキーマを選択することもできます。スキーマを選択するには、データベースにログインする必要があります。
前の手順で「ドメイン」を選択した場合は、ドメイン名を選択し、「スキーマ」フィールドに共通スキーマ名を入力します。

12. 「マッピングの作成」ページで「続行」をクリックします。

13. 「ユーザーの構成」ページで「OK」をクリックします。

5.2.6 エンタープライズ・ユーザーのラベル認可の作成

ディレクトリに格納されるOracle Label Security (OLS)ポリシーには、複数のプロファイルを関連付けることができます。各プロファイルは、ポリシー認可および権限のセットです。これらのポリシー認可および権限は、プロファイルに属するすべてのエンタープライズ・ユーザーに適用されます。プロファイルは、エンタープライズ・ユーザーに割り当てることができます。

ラベル認可をエンタープライズ・ユーザーに割り当てるには、次のようにします。

1. Enterprise Managerにログインします。

2. 「サーバー」タブをクリックします。「セキュリティ」セクションで「エンタープライズ・ユーザー・セキュリティ」をクリックします。
「Oracle Internet Directoryログイン」ページが表示されます。

3. 「ユーザー」フィールドに、エンタープライズ・ユーザーを管理できるディレクトリ・ユーザーの識別名(DN)を入力します。「パスワード」フィールドに、ユーザー・パスワードを入力します。「ログイン」をクリックします。
「エンタープライズ・ユーザー・セキュリティ」ページが表示されます。

4. 「エンタープライズ・ユーザーの構成」をクリックします。
エンタープライズ・ユーザーの構成ページが表示されます。

5. エンタープライズ・ユーザーを検索する「検索ベース」を選択します。検索ベースは、エンタープライズ・ユーザー・エントリが含まれるサブツリーです。必要に応じて、「名前」フィールドにエンタープライズ・ユーザーの共通名を入力できます。「表示」ボックスで「USER」を選択します。「ジャンプ」をクリックします。
基準に合致するユーザーのリストが表示されます。

6. 構成するエンタープライズ・ユーザーを選択します。「構成」をクリックします。
「ユーザーの構成」ページが表示されます。

7. 「ラベル認可」タブをクリックします。
ユーザーに関連付けられているすべてのユーザー・プロファイルのリストが表示されます。

8. 「追加」をクリックします。
ユーザー・プロファイルの選択ウィンドウが表示されます。

9. ユーザーの追加先となるユーザー・プロファイルを選択し、「選択」をクリックします。選択できるのは、ポリシーごとに1つのプロファイルのみです。

10. 「ユーザーの構成」ページで「OK」をクリックします。

5.3 ユーザー定義のエンタープライズ・グループの構成

ユーザー定義のエンタープライズ・グループを使用すると、エンタープライズ・データベースに対して同じロールまたは権限を必要とするエンタープライズ・ユーザーを1つにまとめてグループ化することが簡単にできます。エンタープライズ・グループはディレクトリに格納されます。

5.3.1 ユーザー定義のエンタープライズ・グループへのエンタープライズ・ロールの付与

エンタープライズ・ロールは、様々なデータベースのグローバル・ロールをグループ化できるようにするディレクトリ・オブジェクトです。エンタープライズ・ロールをエンタープライズ・グループに割り当てて、グループ・メンバーにエンタープライズ・データベースに対する権限を付与できます。

エンタープライズ・ロールをエンタープライズ・グループに付与するには、次のようにします。

1. Enterprise Managerにログインします。

2. 「サーバー」タブをクリックします。「セキュリティ」セクションで「エンタープライズ・ユーザー・セキュリティ」をクリックします。
「Oracle Internet Directoryログイン」ページが表示されます。

3. 「ユーザー」フィールドに、エンタープライズ・ユーザーを管理できるディレクトリ・ユーザーの識別名(DN)を入力します。「パスワード」フィールドに、ユーザー・パスワードを入力します。「ログイン」をクリックします。
「エンタープライズ・ユーザー・セキュリティ」ページが表示されます。

4. 「ユーザー定義のエンタープライズ・グループの構成」をクリックします。
エンタープライズ・グループの構成ページが表示されます。

5. エンタープライズ・グループを検索する「検索ベース」を選択します。検索ベースは、エンタープライズ・グループ・エントリが含まれるサブツリーです。必要に応じて、「名前」フィールドにエンタープライズ・グループの共通名を入力します。「表示」ボックスで「グループ」を選択します。「ジャンプ」をクリックします。
基準に合致するグループのリストが表示されます。

6. 構成するエンタープライズ・グループを選択します。「構成」をクリックします。
「グループの構成」ページが表示されます。

7. 「エンタープライズ・ロール」タブをクリックします。
エンタープライズ・グループに付与されたエンタープライズ・ロールのリストが表示されます。

8. 「権限」をクリックして新しいエンタープライズ・ロールをグループに付与します。
エンタープライズ・ロールの選択ウィンドウが表示されます。

9. 付与するエンタープライズ・ロールを選択します。「選択」をクリックします。

10. 「グループの構成」ページで「OK」をクリックします。

5.4 エンタープライズ・ユーザー・セキュリティ用のデータベースの構成

Oracle Internet Directoryに登録されたデータベースのエンタープライズ・ユーザー・セキュリティは、Enterprise Managerを使用して構成できます。ユーザーまたはサブツリーをデータベース・スキーマにマップできます。また、データベースのスキーマ・マッピングおよびエンタープライズ・ドメイン・メンバーシップを変更できる管理者をディレクトリ内で構成できます。

5.4.1 データベースのユーザー・スキーマ・マッピングの作成

ユーザー・スキーマ・マッピングは、エンタープライズ・ユーザーをデータベースのグローバル・スキーマにマップします。エンタープライズ・ユーザーがデータベースにログインすると、デフォルトにより、マップされたスキーマに接続されます。

ユーザー・スキーマ・マッピングを作成するには、次のようにします。

1. Enterprise Managerにログインします。

2. 「サーバー」タブをクリックします。「セキュリティ」セクションで「エンタープライズ・ユーザー・セキュリティ」をクリックします。
「Oracle Internet Directoryログイン」ページが表示されます。

3. 「ユーザー」フィールドに、エンタープライズ・ユーザーを管理できるディレクトリ・ユーザーの識別名(DN)を入力します。「パスワード」フィールドに、ユーザー・パスワードを入力します。「ログイン」をクリックします。
「エンタープライズ・ユーザー・セキュリティ」ページが表示されます。

4. 「データベースの構成」をクリックします。
「データベースの構成」ページが表示されます。アイデンティティ管理レルムに登録されているデータベースのリストが表示されます。

5. データベース名を選択します。「構成」をクリックします。
「データベースの構成」ページが表示されます。

6. 「ユーザー・スキーマ・マッピング」タブをクリックします。データベース・レベルで作成されたユーザー・スキーマ・マップがすべて表示されます。エンタープライズ・ドメイン・レベルで作成されたユーザー・スキーマ・マップは、ここには表示されません。

7. 「作成」をクリックして、データベースに新しいユーザー・スキーマ・マッピングを作成します。
「マッピングの作成」ページが表示されます。

8. 「自」セクションで、「ユーザー」を選択して個々のエンタープライズ・ユーザーをデータベース・スキーマにマップします。あるいは、「サブツリー」を選択して複数のユーザーが含まれるディレクトリ・サブツリーをマップします。「検索」アイコンを使用して該当するユーザーまたはサブツリーを検索できます。

9. 「至」セクションで、ユーザーまたはサブツリーのマップ先となるスキーマの名前を入力します。検索アイコンを使用してデータベースで該当するスキーマを検索できます。スキーマ名にアクセスするには、データベースにログインする必要があります。

10. 「マッピングの作成」ページで「続行」をクリックします。

11. 「データベースの構成」ページで「OK」をクリックします。

5.4.2 データベース・スキーマ・マッピングを管理する管理者の追加

データベースのデータベース・スキーマ・マッピングを管理する権限があるディレクトリ・ユーザーは、データベースのデータベース・スキーマ・マッピングを作成または削除できます。

データベース・スキーマ・マッピングを管理するための管理者を追加するには、次のようにします。

1. Enterprise Managerにログインします。

2. 「サーバー」タブをクリックします。「セキュリティ」セクションで「エンタープライズ・ユーザー・セキュリティ」をクリックします。
「Oracle Internet Directoryログイン」ページが表示されます。

3. 「ユーザー」フィールドに、エンタープライズ・ユーザーを管理できるディレクトリ・ユーザーの識別名(DN)を入力します。「パスワード」フィールドに、ユーザー・パスワードを入力します。「ログイン」をクリックします。
「エンタープライズ・ユーザー・セキュリティ」ページが表示されます。

4. 「データベースの構成」をクリックします。
「データベースの構成」ページが表示されます。アイデンティティ管理レルムに登録されているデータベースのリストが表示されます。

5. データベース名を選択します。「構成」をクリックします。
「データベースの構成」ページが表示されます。

6. 「管理者」タブをクリックします。データベース・スキーマ・マッピングを管理できる管理者のリストが表示されます。

7. 「追加」をクリックして管理者を追加します。
「ユーザーの選択」ウィンドウが表示されます。

8. 「検索ベース」を選択します。検索ベースは、ユーザーを探すために検索するディレクトリ・サブツリーです。「ジャンプ」をクリックします。

9. 管理者として追加するユーザーを選択します。「選択」をクリックします。
「データベースの構成」ページにユーザーが追加されます。

10. ユーザーが他の管理者を追加または削除できるようにする場合は、追加されたユーザーに対応する「管理グループ所有者」チェック・ボックスを選択します。

11. 「OK」をクリックします。

5.5 エンタープライズ・ドメインの管理

エンタープライズ・ドメインは、エンタープライズ・ロール、プロキシ権限、ユーザー・スキーマ・マッピング、現行ユーザーのデータベース・リンクおよび許可された認証メカニズムを共有できるデータベースのグループです。データベースが所属できるエンタープライズ・ドメインは1つのみです。

エンタープライズ・ドメインは管理ドメインと考えられ、そのドメインのDomain Adminsグループによって管理されます。これらの管理者は、エンタープライズ・ドメインにデータベースを追加できます。

アイデンティティ管理レルムには、OracleDefaultDomainというエンタープライズ・ドメインが含まれています。OracleDefaultDomainは、レルムがディレクトリに最初に作成されたときから、レルムに属します。新しいデータベースは、レルムに登録されると、自動的にそのレルムのOracleDefaultDomainのメンバーになります。独自のエンタープライズ・ドメインを作成および削除できますが、OracleDefaultDomainはレルムから削除しないでください。

この項では、Oracle Enterprise Managerを使用してディレクトリ内のエンタープライズ・ドメインを管理する方法を説明します。ここでは、次の項目について説明します。

- エンタープライズ・ドメインの作成

- エンタープライズ・ドメインへのデータベースの追加

- エンタープライズ・ドメインのユーザー・スキーマ・マッピングの作成

- エンタープライズ・ロールの構成

- プロキシ権限の構成

- ユーザー認証タイプの構成と現行ユーザーのデータベース・リンクの有効化

- ドメイン管理者の構成

5.5.1 エンタープライズ・ドメインの作成

エンタープライズ・ドメインは、エンタープライズ・ロール、プロキシ権限、ユーザー・スキーマ・マッピング、現行ユーザーのデータベース・リンクおよび許可された認証メカニズムを共有できるデータベースの管理ドメインです。

OracleDefaultDomainを使用しない場合は、アイデンティティ管理レルムに新しいエンタープライズ・ドメインを作成できます。

エンタープライズ・ドメインを作成するには、次のようにします。

1. Enterprise Managerにログインします。

2. 「サーバー」タブをクリックします。「セキュリティ」セクションで「エンタープライズ・ユーザー・セキュリティ」をクリックします。
「Oracle Internet Directoryログイン」ページが表示されます。

3. 「ユーザー」フィールドに、エンタープライズ・ユーザーを管理できるディレクトリ・ユーザーの識別名(DN)を入力します。「パスワード」フィールドに、ユーザー・パスワードを入力します。「ログイン」をクリックします。
「エンタープライズ・ユーザー・セキュリティ」ページが表示されます。

4. 「エンタープライズ・ドメインの管理」をクリックします。
「エンタープライズ・ドメインの管理」ページが表示されます。このページには、アイデンティティ管理レルム内のエンタープライズ・ドメインが一覧表示されます。

5. 「作成」をクリックして新しいエンタープライズ・ドメインを作成します。
「ドメインの作成」ページが表示されます。

6. 「名前」フィールドに、新しいエンタープライズ・ドメインの名前を入力します。「OK」をクリックします。
「エンタープライズ・ドメイン」ページのエンタープライズ・ドメインのリストに新しいエンタープライズ・ドメインが追加されます。

5.5.2 エンタープライズ・ドメインへのデータベースの追加

Domain Adminsグループのメンバーは、エンタープライズ・ドメインにデータベースを追加できます。データベースは、「ドメインの構成」ページからエンタープライズ・ドメインに追加できます。また、新しいエンタープライズ・ドメインを作成している場合は、「ドメインの作成」ページからデータベースを追加することもできます。

注意:
エンタープライズ・ドメインへのデータベースの追加には、次の制限事項が適用されます。

- データベースをエンタープライズ・ドメインに追加できるのは、データベースとエンタープライズ・ドメインの両方が同じレルム内に存在する場合のみです。

- データベースを2つの異なるエンタープライズ・ドメインのメンバーとして追加することはできません。

データベースをエンタープライズ・ドメインに追加するには、次のようにします。

1. Enterprise Managerにログインします。

2. 「サーバー」タブをクリックします。「セキュリティ」セクションで「エンタープライズ・ユーザー・セキュリティ」をクリックします。
「Oracle Internet Directoryログイン」ページが表示されます。

3. 「ユーザー」フィールドに、エンタープライズ・ユーザーを管理できるディレクトリ・ユーザーの識別名(DN)を入力します。「パスワード」フィールドに、ユーザー・パスワードを入力します。「ログイン」をクリックします。
「エンタープライズ・ユーザー・セキュリティ」ページが表示されます。

4. 「エンタープライズ・ドメインの管理」をクリックします。
「エンタープライズ・ドメインの管理」ページが表示されます。このページには、アイデンティティ管理レルム内のエンタープライズ・ドメインが一覧表示されます。

5. 構成するエンタープライズ・ドメインを選択します。「構成」をクリックします。
「ドメインの構成」ページが表示されます。

6. 「データベース」タブが選択されていることを確認します。「追加」をクリックし、新しいデータベースをエンタープライズ・ドメインに追加します。
データベースの選択ページが表示されます。アイデンティティ管理レルムに登録されているデータベースのリストが表示されます。データベースを追加できるのは、他のどのエンタープライズ・ドメインにも属していない場合のみです。

7. 追加するデータベースを選択します。「選択」をクリックします。

8. 「ドメインの構成」ページで「OK」をクリックします。

5.5.3 エンタープライズ・ドメインのユーザー・スキーマ・マッピングの作成

ユーザー・スキーマ・マッピングは、エンタープライズ・ユーザーをデータベースのグローバル・スキーマにマップします。エンタープライズ・ユーザーがデータベースにログインすると、デフォルトにより、マップされたスキーマに接続されます。

エンタープライズ・ドメインのユーザー・スキーマ・マッピングを作成すると、マッピングはドメイン内のすべてのデータベースが適用されます。ただし、データベースでそのマッピングが有効になるには、そのデータベースにマッピングで使用された名前のスキーマが必要です。

エンタープライズ・ドメインのユーザー・スキーマ・マッピングを作成するには、次のようにします。

1. Enterprise Managerにログインします。

2. 「サーバー」タブをクリックします。「セキュリティ」セクションで「エンタープライズ・ユーザー・セキュリティ」をクリックします。
「Oracle Internet Directoryログイン」ページが表示されます。

3. 「ユーザー」フィールドに、エンタープライズ・ユーザーを管理できるディレクトリ・ユーザーの識別名(DN)を入力します。「パスワード」フィールドに、ユーザー・パスワードを入力します。「ログイン」をクリックします。
「エンタープライズ・ユーザー・セキュリティ」ページが表示されます。

4. 「エンタープライズ・ドメインの管理」をクリックします。
「エンタープライズ・ドメインの管理」ページが表示されます。このページには、アイデンティティ管理レルム内のエンタープライズ・ドメインが一覧表示されます。

5. 構成するエンタープライズ・ドメインを選択します。「構成」をクリックします。
「ドメインの構成」ページが表示されます。

6. 「ユーザー・スキーマ・マッピング」タブをクリックします。ドメイン・レベルで作成されたユーザー・スキーマ・マップがすべて表示されます。データベース・レベルで作成されたユーザー・スキーマ・マップは、ここには表示されません。

7. 「作成」をクリックして、ドメインに新しいユーザー・スキーマ・マッピングを作成します。
「マッピングの作成」ページが表示されます。

8. 「自」セクションで、「ユーザー」を選択して個々のエンタープライズ・ユーザーをデータベース・スキーマにマップします。あるいは、「サブツリー」を選択して複数のユーザーが含まれるディレクトリ・サブツリーをマップします。「検索」アイコンを使用して該当するユーザーまたはサブツリーを検索できます。

9. 「至」セクションで、ユーザーまたはサブツリーのマップ先となるスキーマの名前を入力します。

10. 「マッピングの作成」ページで「続行」をクリックします。

11. 「ドメインの構成」ページで「OK」をクリックします。

5.5.4 エンタープライズ・ロールの構成

ID管理レルム内のエンタープライズ・ドメインには、複数のエンタープライズ・ロールを含めることができます。エンタープライズ・ロールは、エンタープライズ・ドメイン内の1つ以上のデータベースに対するOracleロールベースの認可のセットです。

エンタープライズ・ロールを使用すると、エンタープライズ・ドメインに属する異なるデータベースのグローバル・ロールをグループ化できます。エンタープライズ・ロールはエンタープライズ・ユーザーに割当てできます。

エンタープライズ・ロールを作成するには、次のようにします。

1. Enterprise Managerにログインします。

2. 「サーバー」タブをクリックします。「セキュリティ」セクションで「エンタープライズ・ユーザー・セキュリティ」をクリックします。
「Oracle Internet Directoryログイン」ページが表示されます。

3. 「ユーザー」フィールドに、エンタープライズ・ユーザーを管理できるディレクトリ・ユーザーの識別名(DN)を入力します。「パスワード」フィールドに、ユーザー・パスワードを入力します。「ログイン」をクリックします。
「エンタープライズ・ユーザー・セキュリティ」ページが表示されます。

4. 「エンタープライズ・ドメインの管理」をクリックします。
「エンタープライズ・ドメインの管理」ページが表示されます。このページには、アイデンティティ管理レルム内のエンタープライズ・ドメインが一覧表示されます。

5. 構成するエンタープライズ・ドメインを選択します。「構成」をクリックします。
「ドメインの構成」ページが表示されます。

6. 「エンタープライズ・ロール」タブをクリックします。

7. 「作成」をクリックして新しいエンタープライズ・ロールを作成します。
「エンタープライズ・ロールの作成」ページが表示されます。

8. 「名前」フィールドに、エンタープライズ・ロールの名前を入力します。「続行」をクリックします。
「ドメインの構成」ページに新しいロールが表示されます。

次に、作成したこのエンタープライズ・ロールを構成できます。エンタープライズ・ロールの構成には、エンタープライズ・ロールへのデータベース・グローバル・ロールの追加、およびエンタープライズ・ユーザーまたはグループへのエンタープライズ・ロールの割当てが含まれます。

データベース・グローバル・ロールをエンタープライズ・ロールに追加するには、次のようにします。

1. 「ドメインの構成」ページで作成したエンタープライズ・ロールを選択します。「編集」をクリックします。
「エンタープライズ・ロールの編集」ページが表示されます。

2. 「DBグローバル・ロール」タブが選択されていることを確認します。「追加」をクリックし、エンタープライズ・ドメインに属するデータベースからグローバル・ロールを追加します。

「検索と選択: データベース・グローバル・ロール」ページが表示されます。

3. 追加するグローバル・ロールを含むデータベースを選択します。ユーザー名およびパスワードを指定して、選択したデータベースにログインします。「ジャンプ」をクリックします。

4. 追加するグローバル・ロールを選択します。「選択」をクリックします。

「エンタープライズ・ロールの編集」ページに選択したロールが表示されます。

5. 他のデータベースについて、手順2から4を繰り返します。

これで、エンタープライズ・ユーザーまたはグループにエンタープライズ・ロールを割り当てることができます。

エンタープライズ・ユーザーまたはグループにエンタープライズ・ロールを割り当てるには、次のようにします。

1. 「エンタープライズ・ロールの編集」ページで「権限受領者」タブをクリックします。

2. 「追加」をクリックします。
「選択: ユーザーまたはグループ」ページが表示されます。

3. 検索ベースを選択するか、ユーザーまたはグループが含まれるサブツリーを選択します。エンタープライズ・ロールをユーザーに付与する場合は、「表示」で「USER」を選択します。ロールをグループに付与する場合は、「表示」で「グループ」を選択します。必要に応じて、「名前」フィールドにユーザーまたはグループの共通名を入力します。「ジャンプ」をクリックします。

4. エンタープライズ・ロールを付与するユーザーまたはグループを選択します。「選択」をクリックします。

5. 「エンタープライズ・ロールの編集」ページで「続行」をクリックします。

6. 「ドメインの構成」ページで「OK」をクリックします。

5.5.5 プロキシ権限の構成

プロキシ権限はエンタープライズ・ドメイン・レベルで作成されます。プロキシ権限により、エンタープライズ・ユーザーはローカル・データベース・ユーザーの代わりとなることができます。つまり、エンタープライズ・ユーザーはローカル・データベース・ユーザーとしてデータベースにログインできます。プロキシ権限は、個々のエンタープライズ・ユーザーまたはグループに付与できます。プロキシ権限は、複数のデータベース間でエンタープライズ・ユーザーとして動作する中間層アプリケーションでは特に有用です。

エンタープライズ・ドメインに対してプロキシ権限を作成するには、次のようにします。

1. Enterprise Managerにログインします。

2. 「サーバー」タブをクリックします。「セキュリティ」セクションで「エンタープライズ・ユーザー・セキュリティ」をクリックします。
「Oracle Internet Directoryログイン」ページが表示されます。

3. 「ユーザー」フィールドに、エンタープライズ・ユーザーを管理できるディレクトリ・ユーザーの識別名(DN)を入力します。「パスワード」フィールドに、ユーザー・パスワードを入力します。「ログイン」をクリックします。
「エンタープライズ・ユーザー・セキュリティ」ページが表示されます。

4. 「エンタープライズ・ドメインの管理」をクリックします。
「エンタープライズ・ドメインの管理」ページが表示されます。このページには、アイデンティティ管理レルム内のエンタープライズ・ドメインが一覧表示されます。

5. 構成するエンタープライズ・ドメインを選択します。「構成」をクリックします。
「ドメインの構成」ページが表示されます。

6. 「プロキシ権限」タブをクリックします。

7. 「作成」をクリックして新しいプロキシ権限を作成します。
「プロキシ権限の作成」ページが表示されます。

8. 「名前」フィールドに、プロキシ権限の名前を入力します。「続行」をクリックします。
「ドメインの構成」ページにプロキシ権限が表示されます。

次に、権限に対するターゲット・データベース・ユーザーを追加する必要があります。また、エンタープライズ・ユーザーまたはグループに権限を付与し、ターゲット・データベース・ユーザーのプロキシとして動作できるようにする必要があります。

プロキシ権限に対するターゲット・データベース・ユーザーを追加するには、次のようにします。

1. 「ドメインの構成」ページで作成したプロキシ権限を選択します。「編集」をクリックします。
「プロキシ権限の編集」ページが表示されます。

2. 「ターゲットDBユーザー」タブが選択されていることを確認します。「追加」をクリックします。
「検索と選択」ウィンドウが表示されます。エンタープライズ・ユーザー・プロキシを許可するように変更されているすべてのデータベース・ユーザーのリストが表示されます。

3. プロキシするターゲット・データベース・ユーザーを選択します。「選択」をクリックします。

これで、エンタープライズ・ユーザーまたはグループにプロキシ権限を付与できます。

エンタープライズ・ユーザーまたはグループにプロキシ権限を付与するには、次のようにします。

1. 「プロキシ権限の編集」ページで「権限受領者」タブをクリックします。

2. 「追加」をクリックします。
「選択: ユーザーまたはグループ」ウィンドウが表示されます。

3. 検索ベースを選択するか、ユーザーまたはグループが含まれるサブツリーを選択します。プロキシ権限をユーザーに付与する場合は、「表示」で「USER」を選択します。プロキシ権限をグループに付与する場合は、「表示」で「グループ」を選択します。必要に応じて、「名前」フィールドにユーザーまたはグループの共通名を入力します。「ジャンプ」をクリックします。

4. プロキシ権限を付与するユーザーまたはグループを選択します。「選択」をクリックします。

5. 「プロキシ権限の編集」ページで「続行」をクリックします。

6. 「ドメインの構成」ページで「OK」をクリックします。

5.5.6 ユーザー認証タイプの構成と現行ユーザーのデータベース・リンクの有効化

エンタープライズ・ユーザーは、パスワード認証、SSL認証またはKerberos認証を使用して認証できます。エンタープライズ・ドメインに対して許可される認証モードは、Enterprise Managerを使用して設定できます。また、エンタープライズ・ドメイン内のデータベースに対して現行ユーザーのデータベース・リンクを有効にできます。これらのリンクを使用すると、データベースは相互に信頼してユーザーを認証できるようになります。

ユーザー認証タイプを構成し、現行ユーザーのデータベース・リンクを有効にするには、次のようにします。

1. Enterprise Managerにログインします。

2. 「サーバー」タブをクリックします。「セキュリティ」セクションで「エンタープライズ・ユーザー・セキュリティ」をクリックします。
「Oracle Internet Directoryログイン」ページが表示されます。

3. 「ユーザー」フィールドに、エンタープライズ・ユーザーを管理できるディレクトリ・ユーザーの識別名(DN)を入力します。「パスワード」フィールドに、ユーザー・パスワードを入力します。「ログイン」をクリックします。
「エンタープライズ・ユーザー・セキュリティ」ページが表示されます。

4. 「エンタープライズ・ドメインの管理」をクリックします。
「エンタープライズ・ドメインの管理」ページが表示されます。このページには、アイデンティティ管理レルム内のエンタープライズ・ドメインが一覧表示されます。

5. 構成するエンタープライズ・ドメインを選択します。「構成」をクリックします。
「ドメインの構成」ページが表示されます。

6. 「構成」タブをクリックします。

7. 「許容されたユーザー認証タイプ」で、許可する認証タイプを選択します。

8. ドメインに対して現行ユーザーのデータベース・リンクを有効にする場合は、「このドメインの現行ユーザーのデータベース・リンクを有効化します。」を選択します。

9. 「OK」をクリックします。

5.5.7 ドメイン管理者の構成

ドメイン管理者は、ドメインにおけるすべての権限を持ちます。ドメインに対するデータベースの追加または削除、ユーザー・スキーマ・マッピングの作成、プロキシ権限の管理およびドメイン構成設定の変更ができます。ドメイン管理者は、Enterprise Managerから追加または削除できます。

エンタープライズ・ドメイン管理者を追加するには、次のようにします。

1. Enterprise Managerにログインします。

2. 「サーバー」タブをクリックします。「セキュリティ」セクションで「エンタープライズ・ユーザー・セキュリティ」をクリックします。
「Oracle Internet Directoryログイン」ページが表示されます。

3. 「ユーザー」フィールドに、エンタープライズ・ユーザーを管理できるディレクトリ・ユーザーの識別名(DN)を入力します。「パスワード」フィールドに、ユーザー・パスワードを入力します。「ログイン」をクリックします。
「エンタープライズ・ユーザー・セキュリティ」ページが表示されます。

4. 「エンタープライズ・ドメインの管理」をクリックします。
「エンタープライズ・ドメインの管理」ページが表示されます。このページには、アイデンティティ管理レルム内のエンタープライズ・ドメインが一覧表示されます。

5. 構成するエンタープライズ・ドメインを選択します。「構成」をクリックします。
「ドメインの構成」ページが表示されます。

6. 「管理者」タブをクリックします。エンタープライズ・ドメインの管理者のリストが表示されます。

7. 「追加」をクリックして管理者を追加します。
「ユーザーの選択」ウィンドウが表示されます。

8. 「検索ベース」を選択します。検索ベースは、ユーザーを探すために検索するディレクトリ・サブツリーです。「ジャンプ」をクリックします。

9. 管理者として追加するユーザーを選択します。「選択」をクリックします。
「ドメインの構成」ページにユーザーが追加されます。

10. ユーザーが他の管理者を追加または削除できるようにする場合は、追加されたユーザーに対応する「管理グループ所有者」チェック・ボックスを選択します。

11. 「OK」をクリックします。

A ユーザー移行ユーティリティの使用方法

この章では、ユーザー移行ユーティリティについて説明します。このユーティリティを使用すると、データベース・ユーザーをLDAPディレクトリに一括して移行し、エンタープライズ・ユーザーとして一元的に格納および管理できます。ここでは、次の項目について説明します。

- エンタープライズ・ユーザーへのローカルまたは外部ユーザーの移行の利点

- ユーザー移行ユーティリティの概要

- 移行の実行の前提条件

- ユーザー移行ユーティリティのコマンドライン構文

- ユーザー移行ユーティリティのヘルプへのアクセス

- ユーザー移行ユーティリティのパラメータ

- ユーザー移行ユーティリティの使用例

- ユーザー移行ユーティリティの使用におけるトラブルシューティング

A.1 エンタープライズ・ユーザーへのローカルまたは外部ユーザーの移行の利点

データベース・ユーザー・モデルからエンタープライズ・ユーザー・モデルに移行すると、エンタープライズ環境における管理、セキュリティおよび操作性の問題が解決されます。エンタープライズ・ユーザー・モデルでは、すべてのユーザー情報がLDAPディレクトリ・サービスに移行されます。

エンタープライズ・ユーザー・セキュリティを使用すると、次の利点によって、エンタープライズ全体のユーザーを簡単かつ安全に管理できます。

- LDAPバージョン3準拠のディレクトリ・サーバーにユーザー資格証明、ロールおよび権限を一元的に格納します。

- X.509v3準拠の証明書を使用してシングル・サインオンを可能にするインフラストラクチャを提供します。通常、エンドツーエンドのSSLが必要な場所にデプロイされます。

- 適時にメンテナンスし、ユーザー・パスワードを少なくすることでセキュリティを強化します。
エンタープライズ・ユーザー・モデルに固有のユーザー情報を一元化すると、管理が簡単になります。セキュリティ管理者は、ユーザー情報に対して必要な保守変更を即時実行できるため、重要なネットワーク・リソースへのアクセスを効率的に制御し続けることができます。また、エンタープライズ・ユーザー・モデルでは記録しておくパスワードの数が少なくなるため、ユーザーにとっても使いやすいものです。その結果、ユーザーが推測しやすいパスワードを選択したり、他者が書き写すことができる場所にパスワードを書き留めたりすることが少なくなります。

関連項目:
エンタープライズ・ユーザー・セキュリティの概念の詳細は、「エンタープライズ・ユーザー・セキュリティの概要」を参照してください。

A.2 ユーザー移行ユーティリティの概要

ユーザー移行ユーティリティは、エンタープライズ・ユーザー管理者がユーザーをローカル・データベース・モデルからエンタープライズ・ユーザー・モデルに移行できるようにするコマンドライン・ユーティリティです。何千ものローカルおよび外部データベース・ユーザーを、集中的に管理できるLDAPディレクトリ内のエンタープライズ・ユーザー環境に簡単に移行できます。このユーティリティは、Oracle JDBC OCIドライバを使用してデータベースに接続します。

エンタープライズ・ユーザー管理者は、データベース内の次のユーザー・サブセットのあらゆる組合せを移行対象として選択できます。

- コマンドラインまたはファイルで指定されたユーザーのリスト

- すべての外部ユーザー

- すべてのグローバル・ユーザー

また、エンタープライズ・ユーザー管理者は、ユーザーの移行方法を決定するユーティリティ・パラメータの値を指定することもできます。次に例を示します。

- 移行ユーザーを挿入するLDAPディレクトリ・ツリー内の場所

- 様々なデータベースに複数のアカウントを持つユーザーと1つのディレクトリ・ユーザー・エントリのマッピング

次の各項では、移行プロセスとユーザー・スキーマに対する変更について説明します。

注意:
外部ユーザーの移行後、その外部認証および認可のメカニズムは、ディレクトリベースのメカニズムに置き換わります。移行ユーザーが新たに作成されたディレクトリ・エントリにマップされる場合は、そのユーザーに対して新規パスワードがランダムに生成されます。

A.2.1 バルク・ユーザー移行プロセスの概要

バルク・ユーザー移行プロセスには、2つのフェーズがあります。フェーズ1では、ユーザー情報をインタフェース・データベース表に移入して移行プロセスを開始します。次に、エンタープライズ・ユーザー管理者は、情報が正確であることを確認した後、フェーズ2でデータベースとディレクトリに対する変更をコミットして移行を完了します。次の各手順でプロセスを説明します。

- 手順1: (フェーズ1)移行の準備

- 手順2: ユーザー情報の確認

- 手順3: (フェーズ2)移行の完了

A.2.1.1 手順1: (フェーズ1)移行の準備

移行プロセスの第1フェーズでは、エンタープライズ・ユーザー管理者のスキーマにORCL_GLOBAL_USR_MIGRATION_DATAインタフェース表が存在するかどうかがチェックされます。存在する場合、管理者は、(コンテンツはクリアした)表の再利用、表およびコンテンツの再利用、表の再作成を選択できます。フェーズ1は複数回実行でき、実行のたびにインタフェース表に追加されます。表が存在しない場合は、管理者のスキーマに表が作成されます。インタフェース表には、データベースおよびディレクトリからユーザーの移行に関する情報が移入されます。使用されるコマンドライン・オプションにより、この表に移入される情報が決定されます。

注意:
ユーティリティにより、SYSスキーマにインタフェース表が作成されることはありません。

A.2.1.2 手順2: ユーザー情報の確認

この手順は、データベースおよびディレクトリに対する変更のコミット前に、インタフェース表内のユーザー情報が正しいことをエンタープライズ・ユーザー管理者が確認できるようにするための中間手順です。

A.2.1.3 手順3: (フェーズ2)移行の完了

インタフェース表のユーザー情報の確認後、フェーズ2が開始されます。表から情報が取得され、ディレクトリおよびデータベースが更新されます。

移行ユーザーのディレクトリ・エントリが存在するかどうかによって、次のようにパスワードがランダムに作成されます。

- 新たに作成されたディレクトリ・エントリに移行ユーザーがマップされる場合は、パスワードがランダムに生成され、データベースとディレクトリの両方に対する資格証明として使用されます。

- データベース・パスワードが設定されていない既存のディレクトリ・エントリに移行ユーザーがマップされる場合は、データベース・パスワードのみがランダムに生成されます。

どちらの場合も、必要なランダム・パスワードが生成されると、インタフェース表のDBPASSWORD列とDIRPASSWORD列にそれぞれ格納されます。エンタープライズ・ユーザー管理者は、これらのパスワードをインタフェース表から読み取り、移行ユーザーに通知できます。

関連項目:
コマンドライン・オプションとその説明のリストは、「ユーザー移行ユーティリティのパラメータ」を参照してください。

A.2.2 ORCL_GLOBAL_USR_MIGRATION_DATA表について

この表は、バルク・ユーザー移行プロセスのフェーズ1で、移行ユーザーに関する情報が移入されるインタフェース表です。この表に移入される情報はデータベースから取得され、ディレクトリ内の既存のエントリと照合されます。ディレクトリに対応する情報がある場合は、表内のそのユーザーの情報がマークされます。エンタープライズ・ユーザー管理者がこの表の情報を確認した後、フェーズ2でディレクトリおよびデータベースに変更が適用されます。

注意:
ORCL_GLOBAL_USR_MIGRATION_DATAインタフェース表には、機密情報が格納されます。この表へのアクセスは、データベース権限を使用して厳重に管理する必要があります。

表A-1に、表の列を示します。

表A-1 ORCL_GLOBAL_USR_MIGRATION_DATA表のスキーマ

列名

データ型

NULL設定

説明

USERNAME (主キー)

VARCHAR2(30)

NULL以外

データベース・ユーザー名

OLD_SCHEMA_TYPE

VARCHAR2(10)

-

移行前のデータベースでの旧スキーマ・タイプ

PASSWORD_VERIFIER

VARCHAR2(30)

-

未使用

USERDN

VARCHAR2(4000)

-

ディレクトリ内のユーザーの(新規または既存の)識別名(DN)

USERDN_EXIST_FLAG

CHAR(1)

-

ディレクトリにDNがすでに存在しているかどうかを示すフラグ

SHARED_SCHEMA

VARCHAR2(30)

-

共有スキーマ名(フェーズ2でユーザーが共有スキーマにマップされる場合)

MAPPING_TYPE

VARCHAR2(10)

-

マッピング・タイプ(データベースまたはドメイン)

MAPPING_LEVEL

VARCHAR2(10)

-

マッピング・レベル(エントリまたはサブツリー)

CASCADE_FLAG

CHAR(1)

-

ユーザーの削除時に使用されるカスケード・フラグ(共有スキーマ・マッピングの場合のみ)

DBPASSWORD_EXIST_FLAG

CHAR(1)

-

このユーザーのデータベース・パスワード検証がディレクトリにすでに存在しているかどうかを示すフラグ

DBPASSWORD

VARCHAR2(30)

-

ランダムに生成され、ディレクトリに格納されるデータベース・パスワード検証

DIRPASSWORD

VARCHAR2(30)

-

新しいエントリ用にランダムに生成されたディレクトリ・パスワード

PHASE_COMPLETED

VARCHAR2(10)

-

正常に完了したフェーズに関する情報

NEEDS_ATTENTION_FLAG

CHAR(1)

-

管理者の注意を必要とする異常が行に格納されているかどうかを示すフラグ

ATTENTION_DESCRIPTION

VARCHAR2(100)

-

注意フラグが設定された場合の管理者に対する説明的なヒント

KERBEROS_PNAME

VARCHAR2(30)

-

外部KerberosユーザーのKerberosプリンシパル名

A.2.2.1 フェーズ1とフェーズ2の間に変更できるインタフェース表の列値

ユーティリティのフェーズ1の実行後に、必要に応じて、エンタープライズ・ユーザー管理者は表A-2に示すインタフェース表の列を変更できます。

表A-2 フェーズ1とフェーズ2の間に変更できるインタフェース表の列値

列名

有効値

制限事項

USERDN

ユーザーのDN

この値を変更した場合は、それに応じてUSERDN_EXIST_FLAG値とDBPASSWORD_EXIST_FLAG値が設定されていることを確認する必要があります。

USERDN_EXIST_FLAG

T/F

USERDN列値を変更した場合は、この列値も変更して、USERDNの新しいステータスを反映する必要があります。

DBPASSWORD_EXIST_FLAG

T/F

USERDN列値を変更した場合は、この列値も変更して、新しいUSERDNに対してデータベース・パスワードが存在するかどうかを反映する必要があります。

SHARED_SCHEMA

共有スキーマ名

共有スキーマがデータベースに存在する場合のみ指定します。

MAPPING_TYPE

DB/DOMAIN

この値は、SHARED_SCHEMAがNULL以外に設定されている場合のみ設定します。

MAPPING_LEVEL

ENTRY/SUBTREE

この値は、SHARED_SCHEMAがNULL以外に設定されている場合のみ設定します。

CASCADE_FLAG

T/F

この値は、SHARED_SCHEMAがNULL以外に設定されている場合のみ設定します。この列をtrue (T)に設定すると、ユーザーのスキーマ・オブジェクトは強制的に削除されます。この列をfalse (F)に設定すると、フェーズ2に進む前に、ユーザー・スキーマ・オブジェクトをすべて削除する必要があります。

PHASE_COMPLETED

ZERO/ONE/TWO

NEEDS_ATTENTION_FLAGで指定された競合や不明確さを解決できた場合は、この列値をONEに変更し、ユーティリティでフェーズ2を実行できます。

A.2.3 ユーザーの旧データベース・スキーマに対する移行の影響

共有スキーマ・マッピングを使用しない場合、ユーザーの旧データベース・スキーマは保持されます。共有スキーマ・マッピングを使用する場合、ユーザーのローカル・スキーマはデータベースから削除され、移行の実行前にエンタープライズ・ユーザー管理者が作成した共有スキーマにマップされます。移行ユーザーが旧ローカル・データベース・スキーマにデータベース・オブジェクトを所有している場合、管理者は、CASCADEパラメータをNOに設定して、そのスキーマとオブジェクトが削除されないように指定できます。CASCADEパラメータをNOに設定すると、旧ローカル・スキーマにデータベース・オブジェクトを所有しているユーザーは正常に移行されないため、そのオブジェクトは削除されません。

ローカル・データベース・スキーマにオブジェクトを保持する必要があるユーザーを共有スキーマにマップする場合は、バルク・ユーザー移行を実行する前に、そのオブジェクトを共有スキーマに手動で移行できます。ただし、オブジェクトを共有スキーマに移行すると、その新しいスキーマを共有するすべてのユーザー間でオブジェクトは共有されます。

表A-3に、MAPSCHEMAおよびCASCADEパラメータの設定による影響をまとめます。

表A-3 共有スキーマ・マッピングの選択とCASCADEオプションの指定による影響

MAPSCHEMAパラメータの設定

CASCADEパラメータの設定

ユーザー移行は成功するか

ユーザー・スキーマ・オブジェクトは削除されるか

PRIVATE

NO (デフォルト設定)

はい

いいえ

SHARED

NO

はい脚注 1

いいえ

SHARED

YES

はい脚注 2

はい

脚注1 ユーザーの移行は、そのユーザーが旧データベース・スキーマにオブジェクトを所有していない場合のみ成功し、それ以外の場合は失敗します。

脚注2 ユーザーの移行は成功し、そのユーザーの旧データベース・スキーマは削除されます。

関連項目:
MAPSCHEMA、CASCADEおよびこのユーティリティで使用可能なその他のパラメータの詳細は、「ユーザー移行ユーティリティのパラメータ」を参照してください。

A.2.4 移行プロセス

エンタープライズ・ユーザーは、ディレクトリ内で定義および管理され、パスワードまたは証明書を使用してデータベースに対して認証されます。パスワードで認証されるユーザーには、ディレクトリに格納されたOracleデータベースのパスワードが必要です。証明書で認証されるユーザーには、有効なX.509 v3証明書が必要です。

このユーティリティは、移行時に次の手順を実行します。

1. 移行対象のユーザーをデータベースから選択します。

2. 対応するユーザー・エントリを作成するか、ディレクトリ内の既存のエントリを使用します。

3. 移行ユーザーに対して新規データベース・パスワードを作成し、対応する検証をディレクトリにコピーします。

4. 移行ユーザーのエントリに関するスキーマ・マッピング情報をディレクトリに挿入します。 (オプション)

5. 移行ユーザーのローカル・データベース・スキーマを削除または変更します。 (オプション)

注意:
現行のリリースでは、証明書ベースの認証を使用しているユーザーは、移行後にパスワード認証を使用できるようになります。以前は、SSLベースの認証ユーザーは、Oracleデータベースのパスワードを再設定する必要がありました。このプロセスの過程でユーザー・ウォレットは作成されません。

関連項目:
Oracleウォレットを作成、管理および使用する方法は、『Oracle Database Advanced Security管理者ガイド』のOracle Wallet Managerに関する章を参照してください。

A.3 移行の実行の前提条件

ユーザー移行ユーティリティは、Oracle Databaseクライアントのインストール時に次の場所に自動的にインストールされます。

$ORACLE_HOME/rdbms/bin/umu

次の各項では、ユーザー移行ユーティリティを使用してユーザーを正常に移行するために、実行する必要があるプログラムと必須のユーザー権限について説明します。

A.3.1 必須のデータベース権限

このユーティリティを正常に使用するには、エンタープライズ・ユーザー管理者に次のデータベース権限が必要です。

- ALTER USER

- DROP USER

- CREATE TABLE

- SELECT_CATALOG_ROLE

これらの権限により、エンタープライズ・ユーザー管理者はユーザーの変更および削除、ディクショナリ・ビューの参照、このユーティリティで使用されるインタフェース表の作成ができるようになります。

A.3.2 必須のディレクトリ権限

必須のデータベース権限に加えて、エンタープライズ・ユーザー管理者には、次のタスクを実行できるようにするディレクトリ権限が必要です。

- 特定のユーザー・ベースおよびOracleコンテキストの下に位置するディレクトリでのエントリの作成

- 検索ベース下のユーザー・エントリの参照

A.3.3 ユーザー移行ユーティリティの実行に必要な設定

ユーザー移行ユーティリティを使用する前に、次の手順を実行します。

1. ディレクトリ・サーバーが、認証なしのSSL対応の状態で稼働していることを確認します。

2. データベース・サーバーが、暗号化および整合性が有効にされた状態で稼働していることを確認します。

3. データベース・リスナーにTCPリスニング・エンド・ポイントが指定されていることを確認します。

4. アイデンティティ管理レルムがまだ存在しない場合は、ディレクトリに作成します。

5. 親コンテキストがまだ存在しない場合は、ディレクトリ内のユーザー・エントリに対して作成します。デフォルト(推奨)の場所は、Oracleコンテキストの共通コンテナ内のorclcommonusercreatebaseサブツリー内です。

6. Oracle Net Configuration Assistantを使用してldap.oraファイルを作成し、データベースのOracleホームに対してディレクトリ・アクセスを設定します。ldap.oraファイルには、ユーティリティが正しい管理コンテキストを特定できるように、アイデンティティ管理レルムのDNを含める必要があります。ドメイン・ネーム・システム(DNS)検出を使用している場合は、$LDAP_ADMIN、$ORACLE_HOME/ldap/admin、$TNS_ADMIN、$ORACLE_HOME/network/admin、最後にDNSサーバーで、このファイルの検索が行われます。(DNSサーバー検出の詳細は、『Oracle Internet Directory管理者ガイド』を参照してください。)

注意:

- ユーザーの移行時に共有スキーマ・マッピングを使用する場合は、共有スキーマを作成してからこのユーティリティを実行する必要があります。

- ユーザー移行のフェーズ1とフェーズ2の両方に同じldap.oraファイルを使用する必要があります。

関連項目:

- ユーザー移行の完了後にエンタープライズ・ユーザー認証を設定する方法は、第4章「エンタープライズ・ユーザー・セキュリティの構成タスクとトラブルシューティング」を参照してください。

- 『Oracle Internet Directory管理者ガイド』

A.4 ユーザー移行ユーティリティのコマンドライン構文

データベース・ユーザーからエンタープライズ・ユーザーへのバルク移行を実行するには、次の構文を使用します。

umu parameter1 parameter2 ...

単一の値をとるパラメータの場合は、次の構文を使用します。

keyword=value

複数の値をとるパラメータの場合は、次の構文のようにコロン(:)を使用して値を区切ります。

keyword=value1:value2:...

例A-1に、バルク・ユーザー移行プロセスの両フェーズでユーティリティを実行するために使用する構文を示します。

例A-1 ユーザー移行ユーティリティのコマンドライン構文

umu PHASE=ONE

DBADMIN=dba_username:password
ENTADMIN=enterprise_admin_DN:password
USERS=[ALL_GLOBAL | ALL_EXTERNAL | LIST | FILE]
DBLOCATION=database_host:database_port:database_sid
DIRLOCATION=ldap_directory_host:ldap_directory_port
USERSLIST=username1:username2:username3:...
USERSFILE=filename
MAPSCHEMA=[PRIVATE | SHARED]:schema_name
MAPTYPE=[DB | DOMAIN]:[ENTRY | SUBTREE]
CASCADE=[YES | NO]
CONTEXT=user_entries_parent_location
LOGFILE=filename
PARFILE=filename
KREALM=EXAMPLE.COM

umu PHASE=TWO

DBADMIN=dba_username:password
ENTADMIN=enterprise_admin_DN:password
DBLOCATION=database_host:database_port:database_sid
DIRLOCATION=ldap_directory_host:ldap_directory_port
LOGFILE=filename
PARFILE=filename

注意:
エンタープライズ・ユーザー管理者がコマンドラインで必須パラメータを指定しないと、そのパラメータの入力を求めるプロンプトが対話形式で表示されます。

関連項目:

- すべての使用可能なパラメータとその説明の詳細なリストは、「ユーザー移行ユーティリティのパラメータ」を参照してください。

- ユーティリティの一般的な使用例は、「ユーザー移行ユーティリティの使用例」を参照してください。

A.5 ユーザー移行ユーティリティのヘルプへのアクセス

ユーザー移行ユーティリティを使用するためのコマンドライン構文を表示するには、システム・プロンプトに次のコマンドを入力します。

umu HELP=YES

HELPパラメータをYESに設定すると、ユーティリティは実行されません。

A.6 ユーザー移行ユーティリティのパラメータ

次の各項では、このユーティリティの実行時に使用できるパラメータのキーワードと値を示します。キーワードでは大/小文字は区別されません。

A.6.1 キーワード: HELP

属性

説明

有効値:

YESまたはNO (これらの値では大/小文字は区別されません。)

デフォルト設定:

NO

構文例:

HELP=YES

説明:

このキーワードは、ユーティリティのヘルプを表示するために使用します。YESに設定すると、コマンドライン構文の詳細が表示されます。コマンドを実行するには、値をNOに設定するか、パラメータに値を指定せずにデフォルトを受け入れます。

制限事項:

なし

A.6.2 キーワード: PHASE

属性

説明

有効値:

ONEまたはTWO (これらの値では大/小文字は区別されません。)

デフォルト設定:

ONE

構文例:

PHASE=ONE
PHASE=TWO

説明:

ユーティリティのフェーズを指定します。ONEの場合、コマンドライン引数に指定された情報およびディレクトリ内の既存のユーザー・エントリがインタフェース表に移入されます。TWOの場合、インタフェース表で使用可能な情報を使用してディレクトリおよびデータベースが更新されます。

制限事項:

なし

A.6.3 キーワード: DBLOCATION

属性

説明

有効値:

host:port:sid

デフォルト設定:

デフォルト設定はありません。

構文例:

DBLOCATION=my_oracle.us.example.com:7777:ora902

説明:

データベース・インスタンスのホスト名、ポート番号およびSIDを指定します。

制限事項:

- このパラメータは必須です。

- このパラメータの値は、フェーズ1とフェーズ2の両方で同一であることが必要です。

- データベースには暗号化および整合性のための構成が必要です。

A.6.4 キーワード: DIRLOCATION

属性

説明

有効値:

host:port

デフォルト設定:

この値は、デフォルトではldap.oraファイルから自動的に移入されます。

構文例:

DIRLOCATION=my_oracle.us.example.com:636

説明:

LDAPサーバーが認証なしのSSLで稼働しているディレクトリ・サーバーのホスト名とポート番号を指定します。

制限事項:

このパラメータの値は、フェーズ1とフェーズ2の両方で同一であることが必要です。

A.6.5 キーワード: DBADMIN

属性

説明

有効値:

username:password

デフォルト設定:

デフォルト設定はありません。

構文例:

DBADMIN=system:manager

説明:

データベースへの接続に必要な権限を持つデータベース管理者のユーザー名とパスワードを指定します。

制限事項:

- このパラメータは必須です。

- このパラメータのusername値は、フェーズ1とフェーズ2の両方で同一であることが必要です。

A.6.6 キーワード: ENTADMIN

属性

説明

有効値:

userDN:password

デフォルト設定:

デフォルト設定はありません。

構文例:

ENTADMIN=cn=janeadmin,dc=acme,dc=com:Easy2rem

説明:

ディレクトリへのログインに必要な権限を持つエンタープライズ・ディレクトリ管理者のユーザー識別名(UserDN)とディレクトリ・パスワードを指定します。UserDNは二重引用符("")で囲んで指定することもできます。

制限事項:

このパラメータは必須です。

A.6.7 キーワード: USERS

属性

説明

有効値:

value1:value2...
次の値を指定できます。

- ALL_EXTERNAL: Kerberos認証およびRADIUS認証を使用するユーザーを含め、すべての外部ユーザーを選択する場合に指定します。

- ALL_GLOBAL: すべてのグローバル・ユーザーを選択する場合に指定します。

- LIST: コマンドラインでキーワードUSERSLISTを使用してユーザーを指定する場合に指定します。

- USERSFILE: キーワードUSERSFILEで指定したファイルからユーザーを選択する場合に指定します。

このパラメータは複数の値をとります。値はコロン(:)で区切ります。

(これらの値では大/小文字は区別されません。)

デフォルト設定:

デフォルト設定はありません。

構文例:

- USERS=ALL_EXTERNAL:ALL_GLOBAL
この使用例では、すべての外部ユーザーとすべてのグローバル・ユーザーを移行することをユーティリティに指示しています。

- USERS=ALL_EXTERNAL:FILE
この使用例では、すべての外部ユーザーとUSERSFILEに指定されたすべてのユーザーを移行することをユーティリティに指示しています。

説明:

移行対象のユーザーを指定します。このパラメータに複数の値を指定すると、これらのユーザー・セットの結合が使用されます。

制限事項:

このパラメータは、フェーズ1でのみ必須で、フェーズ2では無視されます。

A.6.8 キーワード: USERSLIST

属性

定義

有効値:

user1:user2:...
ユーザー名はコロン(:)で区切ります。

デフォルト設定:

デフォルト設定はありません。

構文例:

USERSLIST=jdoe:tchin:adesai

説明:

移行対象のデータベース・ユーザーのリストを指定します。このリストのユーザーは、USERSパラメータで指定された他のユーザーとともに移行されます。

制限事項:

このオプション・パラメータは、USERSパラメータでLISTが指定されている場合のみ有効です。

A.6.9 キーワード: USERSFILE

属性

定義

有効値:

ファイル名とパス

デフォルト設定:

デフォルト設定はありません。

構文例:

USERSFILE=/home/orahome/userslist/hr_users.txt

説明:

移行対象のデータベース・ユーザーのリスト(1行に1つのユーザー)が記述されているファイルを指定します。このファイルのユーザーは、USERSパラメータで指定された他のユーザーとともに移行されます。

制限事項:

このオプション・パラメータは、USERSパラメータでFILEが指定されている場合のみ有効です。

A.6.10 キーワード: KREALM

属性

説明

有効値:

kerberos realm

デフォルト設定:

デフォルト設定はありません。

構文例:

KREALM=EXAMPLE.COM

説明:

外部Kerberosユーザー用のKerberos REALMを指定します。通常、これはデータベース・サーバーのドメイン名です。このパラメータを指定しないと、移行対象の外部ユーザーはすべて非Kerberosとみなされます。

制限事項:

- このパラメータは、フェーズ1でのみ有効です。

A.6.11 キーワード: MAPSCHEMA

属性

説明

有効値:

schema_type:schema_name
次のスキーマ・タイプを指定できます。

- PRIVATE
ユーザーの旧ローカル・スキーマを保持します。スキーマ・タイプがPRIVATEの場合、スキーマ名は無視されます。ディレクトリにマッピング・エントリは作成されません。

- SHARED
ユーザーを共有スキーマにマップします。ディレクトリにマッピング・エントリが作成されます。スキーマ名により、共有スキーマ名が指定されます。共有スキーマのマッピング時に、ユーザーのローカル・スキーマがデータベースから削除されるかどうかは、キーワードCASCADEの設定によって決定されます。

(これらの値では大/小文字は区別されません。)

デフォルト設定:

PRIVATE

構文例:

MAPSCHEMA=SHARED:HR_ALL

説明:

インタフェース表にスキーマ・マッピング情報を移入するかどうかを指定します。

制限事項:

- 「有効値」のSHAREDオプションを参照してください。

- このパラメータは、フェーズ1でのみ有効です。

A.6.12 キーワード: MAPTYPE

属性

説明

有効値:

mapping_type:mapping_level
次のマッピング・タイプを指定できます。

- DB

- DOMAIN

次のマッピング・レベルを指定できます。

- ENTRY

- SUBTREE

マッピング・タイプとマッピング・レベルはコロン(:)で区切ります。

(これらの値では大/小文字は区別されません。)

デフォルト設定:

DB:ENTRY

構文例:

MAPTYPE=DOMAIN:SUBTREE

説明:

キーワードMAPSCHEMAをSHAREDに設定したときに適用されるスキーマ・マッピングのタイプを指定します。DBをマッピング・タイプとして指定すると、データベースのディレクトリにマッピングが作成されます。DOMAINをマッピング・タイプとして指定すると、データベースを含むドメインのディレクトリにマッピングが作成されます。ドメイン・マッピングの場合は、関連するOracleコンテキストでのLDAP検索によって、データベースを含むドメインが特定されます。

制限事項:

このパラメータは、MAPSCHEMAがSHAREDに設定されている場合のみ有効です。

関連項目:
このマッピング・レベル・オプションの使用方法は、「SUBTREEマッピング・レベル・オプションの使用について」を参照してください。

A.6.13 キーワード: CASCADE

属性

説明

有効値:

- NO
ユーザーが共有スキーマにマップされる場合、ユーティリティではユーザーのローカル・スキーマをデータベースから削除しようとします。このパラメータをNOに設定すると、ユーザーはローカル・スキーマにオブジェクトを所有していない場合のみ移行されます。旧ローカル・スキーマにオブジェクトを所有しているユーザーは移行されません。このようなユーザーについては、移行ログ・ファイルにエラー・メッセージが記録されます。

- YES
このパラメータをYESに設定すると、すべてのユーザーのスキーマ・オブジェクトが移行時にローカル・スキーマとともに削除されます。以前にユーザーに付与された権限およびロールも取り消されます。

(これらの値では大/小文字は区別されません。)

デフォルト設定:

NO

構文例:

CASCADE=YES

説明:

ユーザーが共有スキーマにマップされる場合に、ユーザーのローカル・スキーマを削除するかどうかを指定します。

制限事項:

このパラメータは、MAPSCHEMAがSHAREDに設定されている場合のみ有効です。

A.6.14 キーワード: CONTEXT

属性

説明

有効値:

ユーザー・エントリの親の識別名(DN)。これは、Oracle Internet Directoryアイデンティティ管理レルムのユーザー検索ベースまたはユーザー作成ベースと同一です。
親DNは二重引用符("")で囲んで指定することもできます。

デフォルト設定:

Oracleコンテキストのcn=Commonの下のorclCommonUserCreateBase属性に設定された値
Oracleコンテキストを示すディレクトリ情報ツリー・ダイアグラムは、図1-3「レルムOracleコンテキスト内の関連エントリ」を参照してください。

構文例:

CONTEXT="c=Users, c=us"

説明:

ユーザーのユーザーIDと一致するディレクトリ・エントリがない場合に、ユーザー・エントリを作成するディレクトリ下の親エントリのDNを指定します。

制限事項:

このパラメータは、フェーズ1でのみ有効です。

A.6.15 キーワード: LOGFILE

属性

説明

有効値:

ファイル名とパス

デフォルト設定:

$ORACLE_HOME/network/log/umu.log

構文例:

LOGFILE=home/orahome/network/log/filename.log

説明:

各ユーザーの移行に関する詳細が書き込まれるログ・ファイルを指定します。

制限事項:

なし

A.6.16 キーワード: PARFILE

属性

説明

有効値:

ファイル名とパス

デフォルト設定:

デフォルト設定はありません。

構文例:

PARFILE=home/orahome/network/usr/par.txt

説明:

ユーザー移行に使用するパラメータのリストが記述されているテキスト・ファイルを指定します。パラメータは1行に1つずつ、ファイルに記述する必要があります。パラメータをパラメータ・ファイルとコマンドラインの両方に指定すると、コマンドラインに指定したパラメータが優先されます。

制限事項:

なし

A.7 ユーザー移行ユーティリティの使用例

次の各項では、このユーティリティで一般的に使用される構文例を示します。

A.7.1 独自のスキーマを保持したままのユーザーの移行

旧データベース・スキーマを保持したままユーザーを移行するには、MAPSCHEMAパラメータをPRIVATE (デフォルト設定)に設定します。たとえば、ユーザーscott1、scott2およびすべての外部データベース・ユーザーを、旧スキーマを保持したまま、新たに生成されたデータベース・パスワードとディレクトリ・パスワードとともにc=Users, c=usにあるディレクトリに移行するには、例A-2に示す構文を使用します。

注意:
デフォルトでは、移行対象の外部ユーザーはすべて非Kerberosとみなされます。既存のKerberosユーザーについては、移行後にユーティリティを使用してKerberosプリンシパル名属性をOracle Internet Directoryに設定できます。そのためには、Kerberos REALM値を使用してコマンドラインにKREALMパラメータを指定します。たとえば、Kerberos REALM値がEXAMPLE.COMの場合は、KREALM=EXAMPLE.COMと入力します。このように設定した後は、user@kerberos_realm形式の名前を持つユーザーがKerberosユーザーとみなされます。Oracle Internet Directoryでは、Kerberosプリンシパル名はデータベース・ユーザー名を使用して設定されます。
関連項目: 「キーワード: KREALM」

例A-2 MAPSCHEMA=PRIVATE (デフォルト)を使用したユーザーの移行

umu PHASE=ONE

DBLOCATION=machine1:1521:ora_sid
DBADMIN=system:manager
USERS=ALL_EXTERNAL:LIST
USERSLIST=scott1:scott2
DIRLOCATION=machine2:636
CONTEXT="c=Users,c=us"
ENTADMIN="cn=janeadmin":Easy2rem

umu PHASE=TWO

DBLOCATION=machine1:1521:ora_sid
DBADMIN=system:manager
DIRLOCATION=machine2:636
ENTADMIN="cn=janeadmin":Easy2rem

フェーズ1が正常に完了した後、インタフェース表にユーザー移行情報が移入されます。その後、エンタープライズ・ユーザーの管理者はこの表を調べて、内容を確認できます。MAPSCHEMAパラメータに値が指定されていないため、フェーズ1はデフォルト値PRIVATEを使用して実行されます。その結果、すべてのユーザーの旧データベース・スキーマおよびオブジェクトは保持されます。

A.7.2 ユーザーの移行と共有スキーマへのマッピング

旧データベース・スキーマを削除してユーザーを移行し、新しい共有スキーマにマップするには、MAPSCHEMAパラメータをSHAREDに設定します。共有スキーマは既に存在しているか、移行プロセスの実行前にエンタープライズ・ユーザーの管理者がパラメータを設定して作成する必要があります。次の例では、ユーザーscott1、scott2およびすべての外部データベース・ユーザーを、新たに生成されたデータベース・パスワードとディレクトリ・パスワードとともにc=Users, c=usにあるディレクトリに移行し、移行したすべてのユーザーをデータベースの新しい共有スキーマにマップします。

例A-3に示す構文を使用し、MAPSCHEMAをSHAREDに設定して移行プロセスを実行します。

例A-3 MAPSCHEMA=SHAREDを使用したユーザーの移行

umu PHASE=ONE

DBLOCATION=machine1:1521:ora_sid
DBADMIN=system:manager
USERS=ALL_EXTERNAL:LIST
USERSLIST=scott1:scott2
MAPSCHEMA=SHARED:schema_32
DIRLOCATION=machine2:636
CONTEXT="c=Users, c=us"
ENTADMIN="cn=janeadmin":Easy2rem

umu PHASE=TWO

DBLOCATION=machine1:1521:ora_sid
DBADMIN=system:manager
DIRLOCATION=machine2:636
ENTADMIN="cn=janeadmin":Easy2rem

フェーズ1が正常に完了した後、インタフェース表にユーザー移行情報が移入されます。その後、管理者はこの表を調べて内容を確認できます。ユーザーscott1、scott2および外部ユーザーには、ランダムに生成される新しいデータベース・パスワードおよびディレクトリ・パスワードが割り当てられます。CASCADEパラメータに値が指定されていないため、フェーズ1はデフォルト値NOを使用して実行されます。その結果、データベース・スキーマにデータベース・オブジェクトを所有するユーザーの移行は失敗し、スキーマは自動的に削除されません。どのユーザーの移行が失敗したのか調べるには、デフォルトで$ORACLE_HOME/network/log/umu.logに置かれているログファイルを確認します。

A.7.2.1 異なるCASCADEオプションを使用した共有スキーマへのユーザーのマッピング

CASCADEパラメータの設定により、移行時に共有スキーマにマップするとき、ユーザーの旧データベース・スキーマを自動的に削除するかどうかが決定されます。CASCADEは、MAPSCHEMAがSHAREDに設定されている場合のみ使用できます。

A.7.2.1.1 CASCADE=NOを使用した共有スキーマへのユーザーのマッピング

デフォルトでは、CASCADEパラメータはNOに設定されます。この設定は、移行ユーザーを共有スキーマにマップするときに、旧スキーマにデータベース・オブジェクトを所有しているユーザーは移行されないことを意味します。データベース・オブジェクトを所有していないユーザーの場合、旧データベース・スキーマは自動的に削除され、新しい共有スキーマにマップされます。

関連項目:
CASCADEをNOに設定してユーザーを共有スキーマにマップする構文例は、例A-3を参照してください。NOはCASCADEのデフォルト設定であるため、ユーティリティのコマンド構文にこのパラメータを指定する必要はありません。

A.7.2.1.2 CASCADE=YESを使用した共有スキーマへのユーザーのマッピング

データベース・オブジェクトを所有している移行ユーザーや、旧データベース・スキーマに所有しているオブジェクトを保持する必要がある移行ユーザーがないことがわかっている場合は、CASCADEパラメータをYESに設定すると、すべてのユーザーのスキーマおよびスキーマ・オブジェクトが自動的に削除され、ユーザーは新しい共有スキーマにマップされます。例A-4に、CASCADEをYESに設定する場合に使用する構文を示します。この例では、ユーザーscott1、scott2およびすべての外部データベース・ユーザーをc=Users, c=usにあるディレクトリに移行し、移行したすべてのユーザーをデータベースの新しい共有スキーマにマップします。

例A-4 CASCADE=YESを使用したユーザーの移行と共有スキーマへのマッピング

umu PHASE=ONE

DBLOCATION=machine1:1521:ora_sid
DBADMIN=system:manager
USERS=ALL_EXTERNAL:LIST
USERSLIST=scott1:scott2
MAPSCHEMA=SHARED:schema_32
CASCADE=YES
DIRLOCATION=machine2:636
CONTEXT="c=Users, c=us"
ENTADMIN="cn=janeadmin":Easy2rem

umu PHASE=TWO

DBLOCATION=machine1:1521:ora_sid
DBADMIN=system:manager
DIRLOCATION=machine2:636
ENTADMIN="cn=janeadmin":Easy2rem

フェーズ1が正常に完了した後、インタフェース表にユーザー移行情報が移入されます。その後、管理者はこの表を調べて内容を確認できます。CASCADEパラメータがYESに設定されているため、データベース・オブジェクトを所有しているユーザーを含め、移行したすべてのユーザーの旧データベース・スキーマは自動的に削除されます。

注意:
CASCADEパラメータをYESに設定する場合は、エンタープライズ・ユーザー管理者が移行対象のユーザーのデータベースのバックアップまたはエクスポート・ダンプを作成してから、このユーティリティを実行することをお薦めします。これにより、移行したユーザーの旧データベース・オブジェクトが必要になった場合に、エクスポート・ダンプから取得できます。

A.7.2.2 異なるMAPTYPEオプションを使用した共有スキーマへのユーザーのマッピング

MAPSCHEMAがSHAREDに設定されている場合は、MAPTYPEパラメータの値を指定することでマッピング・タイプを設定できます。このパラメータは2つの値(マッピング・タイプとマッピング・レベル)をとります。

マッピング・タイプは、データベースを表すDBまたはエンタープライズ・ドメインを表すDOMAINに設定できます。マッピング・タイプDBを指定すると、マッピングは共有スキーマが格納されているデータベースにのみ適用されます。マッピング・タイプとしてDOMAINを指定すると、共有スキーマが格納されているデータベースを含むエンタープライズ・ドメインと、そのドメイン内のすべてのデータベースにマッピングが適用されます。

マッピング・レベルはENTRYまたはSUBTREEに設定できます。ENTRYを指定すると、ユーザーは完全識別名(DN)を使用して共有スキーマにマップされます。この場合、ユーザーごとに1つのマッピングが作成されます。SUBTREEを指定すると、DNの一部を共有するユーザー・グループが一緒にマップされます。この場合、ディレクトリ・ツリーの共通ルートの下にすでにグループ化されているユーザー・グループに対して1つのマッピングが作成されます。例A-5に、MAPTYPEパラメータを設定する場合に使用する構文を示します。この例では、ユーザーscott1、scott2およびすべての外部データベース・ユーザーをc=Users, c=usにあるディレクトリに移行し、移行したすべてのユーザーをデータベースの新しい共有スキーマにマップします。また、マッピングはデータベースを含むエンタープライズ・ドメインに適用され、エントリ・レベルで実行されるため、ユーザーごとに1つのマッピングが作成されます。

例A-5 MAPTYPEパラメータを使用したユーザーの移行と共有スキーマへのマッピング

umu PHASE=ONE

DBLOCATION=machine1:1521:ora_sid
DBADMIN=system:manager
USERS=ALL_EXTERNAL:LIST
USERSLIST=scott1:scott2
MAPSCHEMA=SHARED:schema_32
MAPTYPE=DOMAIN:ENTRY
DIRLOCATION=machine2:636
CONTEXT="c=Users, c=us"
ENTADMIN="cn=janeadmin":welcome

umu PHASE=TWO

DBLOCATION=machine1:1521:ora_sid
DBADMIN=system:manager
DIRLOCATION=machine2:636
ENTADMIN="cn=janeadmin":welcome

A.7.2.2.1 SUBTREEマッピング・レベル・オプションの使用について

移行対象のユーザー(scottなど)が、その下のサブツリーにユーザー・エントリを保持する予定がある場合は、このユーザー・エントリ(cn=scott)からスキーマへのサブツリー・レベルのマッピングを作成することに意味があります。ただし、データベースは、このユーザーをサブツリー内のユーザーとして解釈しないため、マッピングはscott自身には適用されません。たとえば、DNがcn=scott,o=acmeのユーザーscottを移行し、ユーティリティの実行時にマッピング・レベルとしてSUBTREEを選択した場合、cn=scott,o=acmeから共有スキーマへの新しいマッピングが作成されますが、ユーザーscottはそのスキーマにマップされません。scottディレクトリ・エントリの下に作成された新しいユーザーのみが共有スキーマにマップされます。したがって、SUBTREEマッピング・レベルは、ユーザー・ディレクトリ・エントリが他のユーザー・ディレクトリ・エントリの下にある場合のみ指定する必要がありますが、これは通常のディレクトリ構成ではありません。

マッピング・エントリが1つしかない単一の共有スキーマに任意のサブツリー・ユーザーをマップする場合は、Oracle Enterprise Managerを使用してそのマッピングを作成する必要があります。

関連項目:
Oracle Enterprise Managerの使用方法は、「エンタープライズ・ドメインのユーザー・スキーマ・マッピングの作成」を参照してください。

A.7.3 PARFILE、USERSFILEおよびLOGFILEパラメータを使用したユーザーの移行

ユーザー情報とユーザー移行ユーティリティのパラメータをテキスト・ファイルに入力し、PARFILEおよびUSERSFILEパラメータを使用して情報およびパラメータをユーティリティに渡すことができます。LOGFILEパラメータは、各ユーザーの移行に関する詳細が書き込まれるログ・ファイルのディレクトリ・パスを設定します。

PARFILEパラメータは、バルク・ユーザー移行のパラメータを記述したテキスト・ファイルの場所をユーティリティに指示します。USERSFILEパラメータは、パラメータのかわりにデータベース・ユーザーを記述する点を除いて、PARFILEパラメータと同様に機能します。パラメータおよびユーザー・リストには、1行に1つのパラメータまたはユーザーを記述します。LOGFILEパラメータは、ユーザーの移行時に発生するシステム・イベント(エラーなど)の書込み先をユーティリティに指示します。USERSFILEパラメータは、移行プロセスのフェーズ1で使用します。PARFILEおよびLOGFILEパラメータは、両フェーズで使用できます。

例A-6に、ユーザーscott1、scott2およびすべての外部データベース・ユーザーを、旧スキーマを保持したまま、c=Users, c=usにあるディレクトリに移行するための一般的なパラメータ・テキスト・ファイルの構文を示します。この例では、移行イベントのログは、ユーティリティが実行されるディレクトリのerrorfile1ファイルに書き込まれます。別の場所に書き込む場合は、ファイル名とともにパスを指定します。

例A-6 PARFILEパラメータで使用するパラメータ・テキスト・ファイル(par.txt)

DBLOCATION=machine1:1521:ora_sid
DBADMIN=system:manager
USERS=ALL_EXTERNAL:LIST:FILE
USERSLIST=scott1:scott2
USERSFILE=usrs.txt
DIRLOCATION=machine2:636
CONTEXT="c=Users, c=us"
ENTADMIN="cn=janeadmin":Easy2rem
LOGFILE=errorfile1

例A-7に、一般的なユーザー・リスト・テキスト・ファイルの構文を示します。

例A-7 USERSFILEパラメータで使用するユーザー・リスト・テキスト・ファイル(usrs.txt)

user1
user2
user3

これらのパラメータおよびユーザー・リストのテキスト・ファイルを使用して移行プロセスのフェーズ1を実行するには、例A-8に示す構文を使用します。

例A-8 PARFILE、USERSFILEおよびLOGFILEパラメータを使用したユーザーの移行

umu PHASE=ONE

DBADMIN=system:manager
PARFILE=par.txt
LOGFILE=errorfile2

注意:
LOGFILEパラメータが2回、すなわち、1回目はパラメータ・テキスト・ファイルにerrorfile1と(例A-6を参照)、2回目はコマンドラインにerrorfile2と(例A-8を参照)指定されていますが、コマンドラインのパラメータがパラメータ・ファイル内に指定されたパラメータより優先されます。したがって、例A-8でログ・ファイルが書き込まれるのは、コマンドラインに指定された値であるerrorfile2です。

A.8 ユーザー移行ユーティリティの使用におけるトラブルシューティング

移行時の障害は、エラー・メッセージとログ・メッセージによってエンタープライズ・ユーザー管理者にレポートされます。次の各項では、一般的なエラー・メッセージとログ・メッセージおよびその解決方法について説明します。

関連項目:
エラー・メッセージとログ・メッセージの五十音順リストとその説明の記載箇所については、「ユーザー移行ユーティリティのエラー・メッセージとログ・メッセージの要約」を参照してください。

A.8.1 ユーザー移行ユーティリティの一般的なエラー・メッセージ

ユーティリティの実行中にエラーが発生した場合は、エラー・メッセージが表示され停止します。次の各項では、これらのメッセージおよびエラーの解決方法について説明します。

- 両フェーズで表示されるエラー・メッセージの解決

- フェーズ1で表示されるエラー・メッセージの解決

A.8.1.1 両フェーズで表示されるエラー・メッセージの解決

次のエラー・メッセージは、移行のフェーズ1またはフェーズ2の実行中に表示される可能性があります。

- 属性値が不明です : : orclCommonNicknameAttribute

- データベース接続の失敗

- データベース・エラー: < database_error_message >

- データベースがドメインに存在しません : : DB-NAME = < database_name >

- データベースがディレクトリに登録されていません : : DB-NAME = < dbName >

- ディレクトリ接続の失敗

- ディレクトリ・エラー : : < directory_error_message >

- 複数のエントリが見つかりました : : uniqueMember = < database_DN >

属性値が不明です : : orclCommonNicknameAttribute

原因: ニックネーム属性がルート・アイデンティティ管理レルムのディレクトリに設定されていません。

処置: Oracle Internet Directoryセルフ・サービス・コンソールを使用して、アイデンティティ管理レルムのニックネーム属性を設定します。

データベース接続の失敗

原因: データベースに接続できませんでした。

処置: 次の手順を実行します。

1. データベース・ステータスをチェックし、暗号化および整合性のための構成が行われているかどうかを確認します。

2. ユーティリティを実行しているエンタープライズ・ユーザー管理者の権限と資格証明をチェックします。

データベース・エラー: < database_error_message >

原因: データベース・エラーが発生しました。

処置: データベースのデータベース・エラー・メッセージの詳細をチェックします。

関連項目:
データベース・エラー・メッセージの解決方法は、『Oracle Databaseエラー・メッセージ』を参照してください。

データベースがドメインに存在しません : : DB-NAME = < database_name >

原因: データベースがエンタープライズ・ドメインのメンバーではありません。

処置: Oracle Enterprise Managerを使用して、データベースをディレクトリ内のエンタープライズ・ドメインに追加します。

データベースがディレクトリに登録されていません : : DB-NAME = < dbName >

原因: ldap.oraファイルが指すOracleコンテキスト内にデータベースのエントリがありません。

処置: Database Configuration Assistantを使用して、データベースをディレクトリに登録します。

ディレクトリ接続の失敗

原因: ディレクトリに接続できませんでした。

処置: 次の手順を実行します。

1. ディレクトリ・サーバー・ステータスをチェックし、ディレクトリ・サーバー・ポートが認証なしのSSL用に構成されているかどうかを確認します。

2. ユーティリティを実行しているエンタープライズ・ユーザー管理者の権限と資格証明をチェックします。

ディレクトリ・エラー : : < directory_error_message >

原因: ディレクトリ・エラーが発生しました。

処置: ディレクトリのディレクトリ・エラー・メッセージの詳細をチェックします。

関連項目:
Oracle Internet Directoryのエラー・メッセージの解決方法は、『Oracle Internet Directory管理者ガイド』を参照してください。

複数のエントリが見つかりました : : uniqueMember = < database_DN >

原因: データベースがディレクトリ内の複数のエンタープライズ・ドメインに属しています。

処置: Oracle Enterprise Managerを使用して、データベースが1つのエンタープライズ・ドメインにのみ属するようにします。

A.8.1.2 フェーズ1で表示されるエラー・メッセージの解決

移行のフェーズ1の実行中に、構文エラーやその他のエラーが発生する場合があります。次のエラー・メッセージは、移行のフェーズ1の実行中に表示される可能性があります。

- 引数が不明または重複しています : : < parameter >

- データベース・オブジェクトが不明です : : SHARED-SCHEMA = <shared_schema_name >

- ファイル読取り中のエラー : : < file_name > : : < io_error_message >

- ファイル読取り中のエラー : : PARFILE = < file_name > : : < io_error_message>

- ローカル・ホスト名の取得に失敗しました

- SYSスキーマでのインタフェース表の作成はできません

- 無効な引数または値です : : < argument >

- フェーズ用の引数が無効です

- 値が無効です : : < user > [ USERSFILE ]

- 値が無効です : : < user > [ USERSFILE ] { = = DBADMIN }

- 値が無効です : : < user > [ USERSLIST ]

- 値が無効です : : < user > [ USERSLIST ] { = = DBADMIN }

- ロギングに失敗しました : : < io_error_message >

- エントリが見つかりませんでした : : CONTEXT = < context >

引数が不明または重複しています : : < parameter >

原因: 構文エラー。パラメータが欠落しているか、複数回入力されました。

処置: 使用構文をチェックします。

データベース・オブジェクトが不明です : : SHARED-SCHEMA = <shared_schema_name >

原因: 共有スキーマがデータベースに存在しません。

処置: 共有スキーマを作成します。

ファイル読取り中のエラー : : < file_name > : : < io_error_message >

原因: 構文エラー。USERSFILEパラメータに指定したユーザー・リストが記述されたファイルを読み取ることができません。

処置: 次の手順を実行します。

1. ファイルが存在することを確認します。

2. 読取りができるように正しい権限がファイルに設定されていることを確認します。

ファイル読取り中のエラー : : PARFILE = < file_name > : : < io_error_message>

原因: 構文エラー。PARFILEパラメータに指定したパラメータのリストが記述されたファイルを読み取ることができません。

処置: 次の手順を実行します。

1. ファイルが存在することを確認します。

2. 読取りができるように正しい権限がファイルに設定されていることを確認します。

ローカル・ホスト名の取得に失敗しました

原因: 構文エラー。データベースの場所またはディレクトリの場所に対するローカル・ホスト名を読み取ることができません。

処置: DBLOCATIONおよびDIRLOCATIONパラメータを使用してホスト名情報を明示的に入力します。

関連項目:

- 「キーワード: DBLOCATION」

- 「キーワード: DIRLOCATION」

これらのパラメータの使用方法は、各項目を参照してください。

SYSスキーマでのインタフェース表の作成はできません

原因: SYSスキーマにはインタフェース表を作成できません。

処置: DBADMINパラメータに別のユーザーを指定します。

関連項目:
DBADMINパラメータの設定方法は、「キーワード: DBADMIN」を参照してください。

無効な引数または値です : : < argument >

原因: 構文エラー。引数名または値が正しく入力されていません。

処置: 使用構文をチェックします。

関連項目:

- 「ユーザー移行ユーティリティのコマンドライン構文」

- 「ユーザー移行ユーティリティのヘルプへのアクセス」

- 「ユーザー移行ユーティリティのパラメータ」

このユーティリティのコマンドライン構文の使用方法は、各項目を参照してください。

フェーズ用の引数が無効です

原因: 構文エラー。このエラーは、フェーズ1専用のコマンドライン引数を使用してフェーズ2を実行している場合に発生します。

処置: 使用構文をチェックします。

値が無効です : : < user > [ USERSFILE ]

原因: 構文エラー。このエラー・メッセージに示されたユーザーは、DBLOCATIONパラメータに指定されたデータベースのユーザーではないため、無効です。

処置: USERSFILEパラメータで指定されたファイルから無効なユーザーを削除します。

値が無効です : : < user > [ USERSFILE ] { = = DBADMIN }

原因: 構文エラー。USERSFILEパラメータに指定されたファイルに、移行ユーティリティを実行しているユーザーが指定されています。

処置: ファイルからそのユーザーを削除します。

値が無効です : : < user > [ USERSLIST ]

原因: 構文エラー。このエラー・メッセージに示されたユーザーは、DBLOCATIONパラメータに指定されたデータベースのユーザーではないため、無効です。

処置: USERSLISTパラメータから無効なユーザーを削除します。

値が無効です : : < user > [ USERSLIST ] { = = DBADMIN }

原因: 構文エラー。USERSLISTパラメータに移行ユーティリティを実行しているユーザーが指定されています。

処置: USERSLISTパラメータからそのユーザーを削除します。

ロギングに失敗しました : : < io_error_message >

原因: 構文エラー。ログ・ファイルが見つからないか、書込み先のファイルを開けません。

処置: 次の手順を実行します。

1. ログ・ファイルが存在することを確認します。

2. 情報を書込みできるように正しい権限がログ・ファイルに設定されていることを確認します。

エントリが見つかりませんでした : : CONTEXT = < context >

原因: CONTEXTエントリがディレクトリに存在しません。

処置: 次の手順のいずれかを実行します。

- ディレクトリ管理ツールまたはLDAPコマンドライン・ユーティリティを使用して、ディレクトリにコンテキスト値に対するエントリを作成します。

- 別の有効なコンテキスト値を指定します。

A.8.1.3 フェーズ2で表示されるエラー・メッセージの解決

ほとんどのエラー・メッセージは、フェーズ1の実行中に発生します。フェーズ1が正常に完了した後、フェーズ2の実行中に次のエラーが発生する可能性があります。

データベース・オブジェクトが不明です : : TABLE = ORCL_GLOBAL_USR_MIGRATION_DATA

原因: インタフェース表が見つかりません。

処置: 次の手順のいずれかを実行します。

- フェーズ1を実行してインタフェース表を作成します。

- DBADMINパラメータに指定されているユーザーが、フェーズ1でこのパラメータに指定したユーザーと同一であることを確認します。

A.8.2 ユーザー移行ユーティリティの一般的なログ・メッセージ

通常、ユーザーが正常に移行されたかどうかにかかわらず、ログ・メッセージは移行対象の各ユーザーのログ・ファイルに書き込まれます。次の各項では、これらのメッセージおよびエラーの解決方法について説明します。

A.8.2.1 フェーズ1の一般的なログ・メッセージ

移行のフェーズ1の実行中に、ユーザーの情報がインタフェース表に正常に移入されなかったことを示すメッセージがログ・ファイルに書き込まれる場合があります。フェーズ1の完了後に、ログ・ファイルを調べて次のメッセージの有無を確認します。

- 複数のエントリが見つかりました : : < nickname_attribute > = < username >

- エントリが見つかりませんでした : : < nickname_attribute > = < username > : : エントリが見つかりました : DN = < dn >

複数のエントリが見つかりました : : < nickname_attribute > = < username >

原因: ニックネーム属性が複数のユーザーと一致しているか、ユーザーが複数のニックネーム属性と一致しています。

処置: 複数の一致を解決し、このメッセージがログ・ファイル・エントリに表示されたユーザーに対してユーティリティを再度実行します。

エントリが見つかりませんでした : : < nickname_attribute > = < username > : : エントリが見つかりました : DN = < dn >

原因: ニックネームが一致するエントリは見つかりませんが、DNに対するエントリがディレクトリにすでに存在します。

処置: ユーザーに対して別のDNを指定します。

A.8.2.2 フェーズ2の一般的なログ・メッセージ

移行のフェーズ2の実行中に、ユーザーが正常に移行されなかったことを示すメッセージがログ・ファイルに書き込まれる場合があります。フェーズ2の完了後に、ログ・ファイルを調べて次のメッセージの有無を確認します。

- 属性が存在します : : orclPassword

- 属性値が不明です : : orclPassword

- データベース・オブジェクトが不明です : : SHARED-SCHEMA = < shared_schema >

- エントリが見つかりました : : DN = < user_DN >

- 値が無効です : : <interface_table_column_name> = < interface_table_column_value >

- エントリが見つかりませんでした : : DN = < user_DN >

属性が存在します : : orclPassword

このメッセージは通常、「値が無効です::<column_name>=<column_value>」のメッセージとともに発生します。

原因: エントリにorclPassword属性の値がすでに存在します。

処置: インタフェース表のDBPASSWORD_EXIST_FLAG列をチェックし、TまたはFの値が、このユーザーに対するデータベース・パスワードの有無を正しく反映していることを確認します。

属性値が不明です : : orclPassword

このメッセージは通常、「値が無効です::<column_name>=<column_value>」のメッセージとともに発生します。

原因: このユーザーのエントリのorclPassword属性がNULL値です。

処置: インタフェース表のDBPASSWORD_EXIST_FLAG列をチェックし、TまたはFの値が、このユーザーに対するデータベース・パスワードの有無を正しく反映していることを確認します。

データベース・オブジェクトが不明です : : SHARED-SCHEMA = < shared_schema >

原因: このユーザーに対して指定された共有スキーマがデータベースに存在しません。

処置: 次の手順のいずれかを実行します。

- 正しい共有スキーマがこのユーザーに指定されていることを確認します。誤った共有スキーマ名が指定されている場合は、インタフェース表のSHARED_SCHEMA列を編集し、このユーザーに対してフェーズ2を再度実行します。

- データベースに共有スキーマを作成し、このユーザーに対してフェーズ2を再度実行します。

エントリが見つかりました : : DN = < user_DN >

このメッセージは通常、「値が無効です::<column_name>=<column_value>」のメッセージとともに発生します。

原因: 指定されたユーザーDNのエントリがすでに存在します。

処置: インタフェース表のUSERDN_EXIST_FLAG列をチェックし、TまたはFの値が、ディレクトリ内でのこのDNに対するユーザー・エントリの有無を正しく反映していることを確認します。

値が無効です : : <interface_table_column_name> = < interface_table_column_value >

原因: インタフェース表の列のこのユーザーに対する値が無効です。通常、このメッセージは、このユーザーに関する他のログ・メッセージを伴います。

処置: このユーザーに対して正しい値が入力されていることを確認します。

エントリが見つかりませんでした : : DN = < user_DN >

このメッセージは通常、「値が無効です::<column_name>=<column_value>」のメッセージとともに発生します。

原因: DNに対するエントリがディレクトリに存在しません。

処置: インタフェース表のUSERDN_EXIST_FLAG列をチェックし、TまたはFの値が、ディレクトリ内でのこのDNに対するユーザー・エントリの有無を正しく反映していることを確認します。

A.8.3 ユーザー移行ユーティリティのエラー・メッセージとログ・メッセージのまとめ

表A-4と表A-5に、すべてのエラー・メッセージとログ・メッセージのリストを示します。また、メッセージとその解決方法が記載された項へのリンクも示します。

表A-4 ユーザー移行ユーティリティのエラー・メッセージのリスト

ユーザー移行ユーティリティのエラー・メッセージ

フェーズ

引数が不明または重複しています : : < parameter >

1

属性値が不明です : : orclCommonNicknameAttribute

両方

データベース接続の失敗

両方

データベース・エラー: < database_error_message >

両方

データベースがドメインに存在しません : : DB-NAME = < database_name >

両方

データベースがディレクトリに登録されていません : : DB-NAME = < dbName >

両方

データベース・オブジェクトが不明です : : SHARED-SCHEMA = <shared_schema_name >

1

データベース・オブジェクトが不明です : : TABLE = ORCL_GLOBAL_USR_MIGRATION_DATA

2

ディレクトリ接続の失敗

両方

ディレクトリ・エラー : : < directory_error_message >

両方

ファイル読取り中のエラー : : < file_name > : : < io_error_message >

1

ファイル読取り中のエラー : : PARFILE = < file_name > : : < io_error_message>

1

ローカル・ホスト名の取得に失敗しました

1

SYSスキーマでのインタフェース表の作成はできません

1

無効な引数または値です : : < argument >

1

フェーズ用の引数が無効です

1

値が無効です : : < user > [ USERSFILE ]

1

値が無効です : : < user > [ USERSFILE ] { = = DBADMIN }

1

値が無効です : : < user > [ USERSLIST ]

1

値が無効です : : < user > [ USERSLIST ] { = = DBADMIN }

1

ロギングに失敗しました : : < io_error_message >

1

複数のエントリが見つかりました : : uniqueMember = < database_DN >

両方

エントリが見つかりませんでした : : CONTEXT = < context >

1

表A-5 ユーザー移行ユーティリティのログ・メッセージのリスト

ユーザー移行ユーティリティのログ・メッセージ

フェーズ

属性が存在します : : orclPassword

2

属性値が不明です : : orclPassword

2

データベース・オブジェクトが不明です : : SHARED-SCHEMA = < shared_schema >

2

エントリが見つかりました : : DN = < user_DN >

2

値が無効です : : <interface_table_column_name> = < interface_table_column_value >

2

複数のエントリが見つかりました : : < nickname_attribute > = < username >

1

エントリが見つかりませんでした : : DN = < user_DN >

2

エントリが見つかりませんでした : : < nickname_attribute > = < username > : : エントリが見つかりました : DN = < dn >

1

B SSL外部ユーザー変換スクリプト

Oracle Database 10gリリース2 (10.2)より前のリリースでSSL認証外部ユーザーを使用していた場合は、Oracle Database 11gリリース2 (11.2)へのアップブレード後、SSL外部ユーザー変換スクリプトを実行する必要があります。このスクリプトにより、Oracle Database 10gリリース2 (10.2)より前のリリースのSSL認証外部ユーザーはOracle Database 11gリリース2 (11.2)のSSL認証外部ユーザーに変換されます。

注意:
SSL外部ユーザー変換スクリプトは、Oracle Database 10g リリース2 (10.2)より前のリリースからアップグレードした場合にのみ、実行する必要があります。

この章では、次の項目について説明します。

- SSL外部ユーザー変換スクリプトの使用方法

- グローバル・ユーザーから外部ユーザーへの変換

B.1 SSL外部ユーザー変換スクリプトの使用方法

SSL外部ユーザー変換スクリプトの構文は次のとおりです。

$ORACLE_HOME/rdbms/bin/extusrupgrade
--dbconnectstring database connect string
--dbuser database user
--dbuserpassword database user password
[-a]
[-l username1,username2,...]
[-f filename]
[-o]
[-h]

database connect stringは、hostname:port_no:sidの形式で指定する必要があります。hostnameはデータベースが稼働しているホストの名前、port_noはリスナーのポート番号、sidはデータベース・インスタンスのシステム識別子です。

すべてのSSL認証外部ユーザーを変換するには、-aオプションを使用します。次に例を示します。

extusrupgrade --dbconnectstring mymachine:1521:11gR2 --dbuser system --dbuserpassword manager -a

変換するユーザーをカンマ区切りのリストで指定する場合は、-lオプションを使用します。次に例を示します。

extusrupgrade --dbconnectstring mymachine:1521:11gR2 --dbuser system --dbuserpassword manager -l user1,user2,user3

変換するユーザーのリストが記述されたファイルを指定する場合は、-fオプションを使用します。次に例を示します。

extusrupgrade --dbconnectstring mymachine:1521:11gR2 --dbuser system --dbuserpassword manager -f usernames.txt

指定ファイルには、各行に1つのユーザー名を記述する必要があります。次に、サンプルのusernames.txtファイルを示します。

user#1
user>2
user,3
user4
user5

ユーザー名に特殊文字(#など)が含まれたユーザーを変換する場合は、-fオプションを使用する必要があります。

注意:
同じコマンドで-lオプションと-fオプションを組み合せることができます。スクリプトは、-lオプションと-fオプションの両方のユーザーのリストを結合します。-lオプションと-fオプションとともに-aオプションを使用すると、-aオプションは無視されます。

SSL認証外部ユーザーのリストを標準出力デバイスに出力する場合は、-oオプションを使用します。出力には、extusrupgradeスクリプトを使用して変換できるユーザーがリストされます。-oオプションは、他のどのオプションとも組み合せることができません。

extusrupgrade --dbconnectstring mymachine:1521:11gR2 --dbuser system --dbuserpassword manager -o

次に、この出力サンプルを示します。

user1
user2
user3

ヒント:
コマンド出力をファイルにリダイレクトすると、変換できるユーザーのリストを取得できます。このファイルを編集し、-fオプションで使用できます。

B.2 グローバル・ユーザーから外部ユーザーへの変換

Oracle Database 10g以上では、SSL認証外部ユーザーとSSL認証グローバル・ユーザーをデータベースに共存させることができます。以前のリリースでは、SSLユーザーに対する制限があり、ユーザーの認証にOracle Internet Directoryを使用するかどうかに応じて、すべてのSSLユーザーがグローバル・ユーザーまたは外部ユーザーのいずれかである必要がありました。

Oracle Internet Directoryが使用できないときでも、ユーザーがデータベースに接続できるようにする場合は、ユーザーを外部ユーザーとして構成する必要があります。SSL外部ユーザー変換スクリプトを使用して、SSL認証グローバル・ユーザーをSSL認証外部ユーザーに変換できます。

次に例を示します。

extusrupgrade --dbconnectstring mymachine:1521:11gR2 --dbuser system --dbuserpassword manager -l user1,user2

この例では、2つのグローバル・ユーザーが外部ユーザーに変換されます。

C エンタープライズ・ユーザー・セキュリティとMicrosoft Active Directoryの統合

エンタープライズ・ユーザーは、Oracle Identity Managementインフラストラクチャの一部であるOracle Internet Directoryを利用します。所属している組織がActive Directoryなどのサード・パーティのディレクトリを使用してユーザー・エントリを格納および管理している場合は、サード・パーティのディレクトリとOracle Internet Directoryを統合してエンタープライズ・ユーザー・セキュリティを管理できます。

エンタープライズ・ユーザーのKerberos認証では、Microsoft Windowsドメイン・コントローラ上で動作するKerberos Key Distribution Center (KDC)が発行するチケットを利用できます。

この付録では、Kerberos認証を使用したエンタープライズ・ユーザー・セキュリティとMicrosoft Active Directoryの統合手順を示します。次の項目について説明します。

- Active DirectoryとOracle Internet Directory間の同期の設定

- Oracleクライアントと相互運用するためのWindows 2000ドメイン・コントローラの設定

- Windows 2000ドメイン・コントローラと相互運用するためのOracle Databaseの設定

- Windows 2000 KDCと相互運用するためのOracle Databaseクライアントの設定

- クライアントの初期チケットの取得

- Kerberos認証を使用するエンタープライズ・ユーザー・セキュリティの構成

C.1 Active DirectoryとOracle Internet Directory間の同期の設定

Oracleコンポーネントは、Oracle Internet Directoryを利用してセキュリティを一元管理します。組織によっては、Active Directoryを使用するMicrosoft Windowsドメインを設定してセキュリティを一元管理している場合があります。エンタープライズ・ユーザー・セキュリティとActive Directoryを併用できるように構成するには、Oracle Internet DirectoryとActive Directory間の同期を設定する必要があります。

2つのディレクトリを同期するには、同期プロファイルを使用します。このプロファイルには、2つのディレクトリの同期に必要な構成情報が含まれています。構成情報には、同期の方向、マッピング・ルールと書式、Microsoft Windowsドメインの接続の詳細などがあります。マッピング・ルールには、一方のディレクトリのドメインと属性を他方のディレクトリにマップするためのドメイン・ルールと属性ルールがあり、オプションで属性の書式設定があります。

関連項目:
Oracle Internet DirectoryとMicrosoft Active Directoryの統合手順は、『Oracle Identity Management統合ガイド』を参照してください。

C.2 Oracleクライアントと相互運用するためのWindows 2000ドメイン・コントローラの設定

Windows 2000ドメイン・コントローラで、次のタスクを実行する必要があります。

1. Microsoft Active DirectoryでOracle Databaseプリンシパルを作成します。
これにより、Microsoft Active Directoryにデータベースの新しいユーザーが作成されます。

2. ktpassコマンドライン・ユーティリティを使用して、Kerberosのkeytabファイルを作成します。
ktpassユーティリティは、Windows 2000サポート・ツールの一部です。Windows 2000ドメイン・コントローラをKDCとして使用するには、keytabファイルが必要です。

3. 前の手順で作成したkeytabファイルを、データベース・サーバーがインストールされているコンピュータにコピーします。

関連項目:
この手順の詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

C.3 Windows 2000ドメイン・コントローラと相互運用するためのOracle Databaseの設定

Oracle Databaseがインストールされているホスト・コンピュータで、次のタスクを実行する必要があります。

- Kerberosパラメータを使用してデータベースのsqlnet.oraファイルを更新します。

関連項目:
この手順の詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

C.4 Windows 2000 KDCと相互運用するためのOracle Databaseクライアントの設定

Oracle Kerberosクライアントで、次の手順を実行する必要があります。

1. Kerberosクライアント構成ファイルを作成します。
Kerberosクライアント構成ファイルは、Windows 2000ドメイン・コントローラをKerberos KDCとして参照します。

2. クライアントのsqlnet.oraファイルにKerberosパラメータを指定します。
手動でファイルを更新することも、Oracle Net Managerユーティリティを使用することもできます。

関連項目:
この手順の詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

C.5 クライアントの初期チケットの取得

クライアントがデータベースに接続するには、初期チケットをリクエストする必要があります。初期チケットにより、その他のサービス・チケットを要求する権限を持つクライアントとして識別されます。初期チケットは、okinitコマンドを使用してリクエストします。

関連項目:
okinitを使用した初期チケットのリクエストの詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

C.6 Kerberos認証を使用するエンタープライズ・ユーザー・セキュリティの構成

Kerberos認証を使用するエンタープライズ・ユーザー・セキュリティを構成するには、次の手順に従います。

1. Oracle Internet Directoryにデータベースを登録します。
データベースの登録には、Database Configuration Assistantを使用できます。

2. データベースおよびOracle Internet Directoryでエンタープライズ・ユーザー・セキュリティ・オブジェクトを構成します。
データベースでグローバル・スキーマとグローバル・ロールを作成します。また、エンタープライズ・ドメインでエンタープライズ・ロールを作成します。エンタープライズ・ドメインのユーザー・スキーマ・マッピングを構成して、グローバル・データベース・ロールをエンタープライズ・ロールに追加し、データベースにアクセスするエンタープライズ・ユーザーにエンタープライズ・ロールを付与します。

3. Kerberos認証を受け入れるようにエンタープライズ・ドメインを構成します。
Oracle Enterprise Managerを使用して、エンタープライズ・ドメインに対するKerberos認証を有効にします。

4. Kerberos認証エンタープライズ・ユーザーとして接続します。
SQL*Plusを起動し、connect /@net_service_nameコマンドを使用してKerberos認証エンタープライズ・ユーザーとして接続します。

関連項目:
この手順の詳細は、「Kerberos認証を使用するエンタープライズ・ユーザー・セキュリティの構成」を参照してください。

D Oracle9iからOracle Database 11g リリース2 (11.2)へのアップグレード

この付録では、エンタープライズ・ユーザー・セキュリティに関連したOracle9iデータベース(9.2.0.8)からOracle Database 11gリリース2(11.2)へのアップグレードについて説明します。次の項目について説明します。

- リリース9.2からリリース9.0.4へのOracle Internet Directoryのアップグレード

- リリース9.2.0.8からリリース11.2へのOracleデータベースのアップグレード

- Oracle Databaseリリース10g (10.1)以上からOracle Database 11gリリース2 (11.2)へのアップグレード

D.1 リリース9.2からリリース9.0.4へのOracle Internet Directoryのアップグレード

Oracle9i Databaseリリース2では、Oracle Internet Directoryリリース9.2またはリリース9.0.4を使用できます。Oracle Database 11g リリース2(11.2)には、Oracle Internet Directory 9.0.4以上が必要です。Oracle Internet Directoryリリース9.2を使用している場合は、リリース9.0.4にアップグレードする必要があります。

Oracle Internet Directoryリリース9.2をOracle Internet Directoryリリース9.0.4にアップグレードする方法は、次のとおりです。

1. Oracle Internet Directoryコンフィギュレーション・アシスタントを使用して、Oracle Internet Directoryをアップグレードします。これは、Oracle Database 11g リリース2(11.2)インスタンスをディレクトリに登録する場合に必要です。

2. エンタープライズ・ユーザー・セキュリティに使用するOracleコンテキストがルート・コンテキストでない場合は、Oracleコンテキストをアイデンティティ管理レルムにアップグレードします。Oracle Internet Directoryコンフィギュレーション・アシスタントのコマンドライン・ユーティリティを次のように使用します。

oidca mode=CTXTOIMR

この手順は、Oracle Database 11g リリース2(11.2)インスタンスをレルムに登録する場合に必要です。

Oracle Database 11g リリース2(11.2)データベースのルートOracleコンテキストは、ID管理レルムではないため使用できません。

3. ldapmodifyやbulkmodifyなどのOracle Internet Directoryツールを使用して、orcluserV2 objectclassを既存のユーザー・エントリに追加します。このobjectclassは、ユーザーによるデータベース・パスワードの変更およびデータベースに対するKerberos認証に必要です。

4. Oracle9i DatabaseとOracle Database 11gリリース2 (11.2)の両方に含まれるレルムでは、Oracle Internet Directoryリリース9.0.4のDASベースのツールを使用してユーザーを作成および管理します。Oracle Internet Directoryセルフ・サービス・コンソールまたはEnterprise Security Managerコンソールを使用できます。Oracle9iでインストールされたEnterprise Security Managerまたはエンタープライズ・ログイン・アシスタントは使用しないでください。

D.2 リリース9.2.0.8からリリース11.2へのOracleデータベースのアップグレード

Oracle Database 11g リリース2(11.2)にアップグレードするOracle9i Database (9.2.0.8)インスタンスごとに、次の手順を実行します。

1. Oracle Wallet Managerを使用して、データベース・ウォレットに対する自動ログインを無効にします。

2. rdbms_server_dn初期化パラメータから、データベース識別名(DN)を保護された場所にあるファイルにコピーします。

3. データベースをOracle Database 11g リリース2(11.2)にアップグレードします。

4. データベースのadminディレクトリが格納されている場所に応じて、データベース・ウォレットを$ORACLE_BASE/admin/olddbuniquename/walletまたは$ORACLE_HOME/admin/olddbuniquename/walletに移動します。$ORACLE_HOMEは、新規のOracle Database 11g リリース2(11.2)用であることに注意してください。walletディレクトリの作成が必要な場合があります。

5. 古い$ORACLE_HOME/network/admin/ldap.oraファイルを新しい$ORACLE_HOME/ldap/admin/ldap.oraファイルにコピーします。あるいは、Oracle Net Configuration Assistantを使用して、新しいldap.oraファイルを作成できます。

6. mkstoreコマンドライン・ユーティリティを使用して、(前の手順でセキュアなディレクトリの場所に作成したファイルから)データベースDNをウォレットに挿入します。次の構文を使用します。

mkstore -wrl database_wallet_location -createEntry
ORACLE.SECURITY.DN database_DN

ウォレット・パスワードを要求するプロンプトが表示されます。

mkstoreコマンドに誤りがあった場合は、-modifyEntryオプションを使用して訂正できます。

7. Database Configuration Assistantを使用して、データベースとディレクトリ間のパスワードをデータベース・ウォレットに生成します。データベースの変更オプションを選択します。

8. Oracle Wallet Managerを使用して、データベース・ウォレットに対する自動ログインを再び有効にします。

9. Oracle Net Managerを使用して、sqlnet.oraファイルの新しいウォレット・ロケーションを手順4で指定したディレクトリに設定します。

CNなどのニックネーム属性のデフォルトは変わりません。アップグレード処理では、デフォルトのニックネーム属性の設定は変更されません。Oracle Internet Directoryリリース9.2からリリース9.0.4にアップグレードした後、Oracle Database 11gリリース2(11.2)にログインできない場合は、DASベースのOracle Internet Directoryセルフ・サービス・コンソールを使用してパスワードを再設定する必要があります。

D.3Oracle Databaseリリース10g (10.1)以上からOracle Database 11gリリース2 (11.2)へのアップグレード

Oracle Database 11gリリース2(11.2)にアップグレードするOracle Database 10gリリース1 (10.2)以上のインスタンスごとに、次の手順を実行します。

1. データベースをOracle Database 11g リリース2(11.2)にアップグレードします。

2. データベースのadminディレクトリが格納されている場所に応じて、データベース・ウォレットを$ORACLE_BASE/admin/olddbuniquename/walletまたは$ORACLE_HOME/admin/olddbuniquename/walletに移動します。$ORACLE_HOMEは、新規のOracle Database 11g リリース2(11.2)用であることに注意してください。walletディレクトリの作成が必要な場合があります。

3. 古い$ORACLE_HOME/network/admin/ldap.oraファイルを新しい$ORACLE_HOME/ldap/admin/ldap.oraファイルにコピーします。あるいは、Oracle Net Configuration Assistantを使用して、新しいldap.oraファイルを作成できます。

4. Oracle Wallet Managerを使用して、データベース・ウォレットに対する自動ログインを再び有効にします。

5. Oracle Net Managerを使用して、sqlnet.oraファイルの新しいウォレット・ロケーションを手順2で指定したディレクトリに設定します。

用語集

アクセス制御

特定のクライアントまたはクライアント・グループに対して特定のデータへのアクセス権を付与または制限するシステム機能。

アクセス制御リスト(ACL)

ユーザーが定義するアクセス・ディレクティブのグループ。ディレクティブは、特定のクライアント、クライアント・グループまたはその両方に対して特定のデータへのアクセス・レベルを付与する。

Advanced Encryption Standard

Advanced Encryption Standard (AES)は、米国商務省国立標準技術研究所によってDESに代わるものとして承認された新しい暗号アルゴリズムである。AES規格は、米国連邦情報処理標準197番で入手できます。AESアルゴリズムは、128、192および256ビットの長さの暗号鍵を使用して、128ビットのデータ・ブロックを処理できる対称型ブロック暗号です。

AES

「Advanced Encryption Standard」を参照。

属性

LDAPディレクトリ内のエントリの性質を説明する情報項目。エントリは属性のセットから構成され、それぞれの属性がオブジェクト・クラスに属する。さらに、各属性にはタイプと値があり、タイプは属性の情報の種類を説明し、値には実際のデータが格納されています。

認証

コンピュータ・システムのユーザー、デバイスまたはその他のエンティティの識別情報を検証するプロセスであり、システムのリソースへのアクセス権を付与するための前提条件となることが多い。認証されたメッセージの受信者は、そのメッセージの発信元(送信者)を確認できる。認証は、第三者が送信者を装っている可能性を排除するものとみなされる。

認証方式

分散環境のユーザー、クライアントまたはサーバーの識別情報を検証するセキュリティ方式。ネットワーク認証方式では、ユーザーにシングル・サインオン(SSO)の利点も提供できる。Oracle Advanced Securityがインストールされている場合は、Oracle Databaseで次の認証方式がサポートされる。

- Kerberos

- RADIUS

- Secure Sockets Layer(SSL)

- Windowsシステム固有の認証

認可

オブジェクトまたはオブジェクトのセットにアクセスするためにユーザー、プログラムまたはプロセスに付与される権限。Oracleでは、認可はロール・メカニズムを通じて行われる。1つのユーザーまたはユーザー・グループに対して、1つのロールまたは一連のロールを付与できる。また、ロールに他のロールを付与することもできる。認証されたエンティティが利用できる権限のセット。

自動ログイン・ウォレット

アクセス時に資格証明を指定せずにサービスへのPKIベースまたはパスワードベースのアクセスを可能にするOracle Wallet Managerの機能。自動ログイン・アクセスは、自動ログイン機能がウォレットに対して無効になるまで有効である。ファイルシステム権限は、自動ログイン・ウォレットに必要なセキュリティを提供する。ウォレットに対して自動ログインが有効になっている場合は、そのウォレットを作成したオペレーティング・システム・ユーザーのみ、そのウォレットを使用できる。これらはシングル・サインオン機能を提供するため、SSOウォレットと呼ばれることもある。

ベース

LDAP準拠ディレクトリでのサブツリー検索のルート。

CA

「認証局」を参照。

CDS

「セル・ディレクトリ・サービス(CDS)」を参照。

セル・ディレクトリ・サービス(CDS)

外部ネーミング・メソッドの1つ。このサービスを使用すると、ユーザーはOracleのツール製品を透過的に使用でき、アプリケーションでは分散コンピューティング環境(DCE)にあるOracle Databaseデータベースにアクセスできる。

証明書

識別情報を公開鍵に安全にバインドするITU x.509 v3標準データ構造。

証明書は、信頼できる識別情報(認証局)によってエンティティの公開鍵が署名されたときに作成される。この証明書は、エンティティの情報が正しく、公開鍵が実際にそのエンティティに属することを保証する。

証明書には、エンティティの名前、識別情報および公開鍵が含まれます。シリアル番号、有効期限、および証明書に付随する権利、使用および権限も含まれることがあります。最後に、その証明書を発行した認証局に関する情報が含まれます。

認証局

他のエンティティ(ユーザー、データベース、管理者、クライアント、サーバー)が本物であることを証明する、信頼できる第三者。ユーザーを証明するとき、認証局は最初にそのユーザーが証明書失効リスト(CRL)に掲載されていないことを確認してからそのユーザーのアイデンティティを検証し、証明書を付与し、認証局の秘密鍵を使用してその証明書に署名します。認証局には自身の証明書と公開鍵があり、公開されています。サーバーおよびクライアントは、これらを使用して認証局の署名を検証します。認証局は、証明書サービスを提供する外部の会社の場合や、企業のMIS部門のような内部の組織の場合があります。

証明連鎖

エンド・ユーザーまたはサブスクライバの証明書とその認証局の証明書を含む順序付きの証明書リスト。

証明書リクエスト

認証リクエスト情報、署名アルゴリズム識別子および認証リクエスト情報に対するデジタル署名の3つの部分から構成される証明書リクエスト。認証リクエスト情報は、対象の識別名、公開鍵およびオプションの属性セットから構成される。属性では、対象の識別情報に関する郵便の宛先などの追加情報、または対象エンティティが後で証明書失効を要求するためのチャレンジ・パスワードを提供できる。「PKCS #10」を参照。

証明書失効リスト

(CRL)失効した証明書のリストを含む署名付きデータ構造。CRLの信頼性と整合性は、CRLに付加されているデジタル署名によって提供される。通常、CRLの署名者は、発行された証明書に署名したエンティティと同じである。

チェックサム

メッセージ・パケットに含まれているデータに基づいてメッセージ・パケットの値を計算し、その値をデータとともに渡して、データが書き換えられていないことを認証するメカニズム。データの受信者は暗号チェックサムを再計算して、それをデータとともに送られた暗号チェックサムと比較します。これらが一致している場合は、データが送信中に書き換えられなかったことの確率的な証明になります。

暗号ブロック連鎖(CBC)

暗号化方式の1つ。先行するすべてのブロックに従って暗号ブロックの暗号化を行い、ブロック再生攻撃からデータを保護する。許可されていない復号化が段階的に困難になるように設計されている。Oracle Advanced Securityでは、外部暗号ブロック連鎖が使用されています。これは、内部暗号ブロックよりも安全性が高く、実質的なパフォーマンスの低下を伴わないためです。

暗号スイート

ネットワーク・ノード間でメッセージを交換するために使用される認証、暗号化およびデータ整合性のアルゴリズムのセット。たとえば、SSLハンドシェイク中に2つのノードがネゴシエーションして、メッセージの送受信中に使用する暗号スイートを確認する。

暗号スイート名

暗号スイートは、特定のセッションで接続により使用される暗号保護の種類を示す。

暗号文

暗号化されたメッセージ・テキスト。

クリアテキスト

暗号化されていない平文。

クライアント

サービスを利用する側。クライアントはユーザーの場合や、データベース・リンク中にユーザーとして機能するプロセス(プロキシともいう)の場合がある。

機密保護

暗号化の機能。機密保護によって、メッセージを参照(暗号文を復号化する)できるのはメッセージの本来の受信者のみであることが保証される。

接続記述子

特別にフォーマットされた、ネットワーク接続のための宛先の記述。接続記述子には、接続先のサービスおよびネットワーク・ルート情報が含まれます。接続先サービスは、Oracle9iまたはOracle8iデータベースのサービス名か、Oracleデータベース・バージョン8.0のOracleシステム識別子(SID)を使用して指定されます。ネットワーク・ルートは、少なくとも、ネットワーク・アドレスを使用してリスナーの場所を示します。「接続識別子」を参照。

接続識別子

接続記述子または接続記述子にマップされる名前。接続識別子は、ネット・サービス名、データベース・サービス名、ネット・サービス別名のいずれかである。ユーザーは、接続するサービスの接続文字列で接続識別子とともにユーザー名とパスワードを渡すことにより、接続リクエストを開始する。

CONNECT username@connect_identifier
Enter password:

接続文字列

ユーザー名、パスワード、ネット・サービス名など、ユーザーが接続先のサービスに渡す情報。次に例を示します。

CONNECT username@net_service_name

Enter password:

資格証明

データベースにアクセスするために使用するユーザー名、パスワードまたは証明書。

CRL

「証明書失効リスト」を参照。

CRL配布ポイント

(CRL DP) X.509バージョン3証明書標準で指定されるオプションの拡張子であり、証明書の失効情報が格納される区分CRLの位置を示します。通常、この拡張子の値はURLの形式です。CRL DPによって、1つの認証局ドメイン内の失効情報を複数のCRLにポストできます。CRL DPによって、失効情報はより管理しやすい部分に細分化され、CRLが膨大に増加するのが回避されるため、パフォーマンスが向上します。たとえば、CRL DPを証明書に指定し、その証明書の失効情報をダウンロードできる、Webサーバー上のファイルを指すようにできます。

CRL DP

「CRL配布ポイント」を参照。

暗号化

データのエンコーディングおよびデコーディング処理であり、メッセージを保全する。

データ・ディクショナリ

データベースに関する情報を提供する読取り専用の表のセット。

データベース管理者

(1) Oracleサーバーまたはデータベース・アプリケーションを操作および管理する個人。(2) DBA権限を付与され、データベース管理機能を実行できるOracleユーザー名。通常、これら2つを同時に意味します。多くのサイトでは、複数のDBAがいます。(3) OracleDBAdminsディレクトリ管理グループのメンバーで、ディレクトリの特定のデータベース・エントリのデータベース・ユーザー・スキーマ・マッピングを管理します。Database Configuration Assistantは、ディレクトリにデータベースを登録したユーザーを、そのデータベースのOracleDBAdminsグループの最初のメンバーとして、自動的にグループに追加します。

データベース別名

「ネット・サービス名」を参照。

データベース・インストール管理者

データベース作成者とも呼ばれる。この管理者は、新規データベースの作成を担当する。この作業には、Database Configuration Assistantを使用したディレクトリへの各データベースの登録が含まれる。この管理者は、データベース・サービス・オブジェクトおよび属性に対する作成および変更のアクセス権を持つ。この管理者は、デフォルトのドメインも変更できる。

データベース・リンク

ローカル・データベースまたはネットワーク定義に格納されるネットワーク・オブジェクトであり、リモート・データベース、そのデータベースへの通信パス、および場合によってはユーザー名とパスワードを識別する。定義されると、データベース・リンクはリモート・データベースへのアクセスに使用されます。

あるデータベースから別のデータベースへのパブリックまたはプライベート・データベース・リンクは、DBAまたはユーザーによってローカル・データベースに作成される。

グローバル・データベース・リンクは、Oracle Namesで各データベースからネットワーク内の他のすべてのデータベースに自動的に作成される。グローバル・データベース・リンクはネットワーク定義に格納される。

データベース・メソッド

「Oracleデータベース・メソッド」を参照。

データベース・パスワード検証

ユーザーのデータベース・パスワードから導出される不可逆的な値。この値は、データベースに対するパスワード認証時に、接続ユーザーの識別情報を証明するために使用される。

データベース・セキュリティ管理者

データベース・エンタープライズ・ユーザー・セキュリティの最上位レベルの管理者。この管理者は、すべてのエンタープライズ・ドメインに対する権限を持ち、次のことに責任を担っている。

- Oracle DBSecurityAdminsおよびOracleDBCreatorsグループの管理

新規エンタープライズ・ドメインの作成。

- エンタープライズ内のあるドメインから別のドメインへのデータベースの移動

DCE

「分散コンピューティング環境(DCE)」を参照。

復号化

暗号化されたメッセージ(暗号文)の内容を元の判読可能な形式(平文)に変換するプロセス。

辞書攻撃

パスワードに対する一般的な攻撃。攻撃者は、多数の想定されるパスワードとそれに対応するベリファイアの辞書を作成します。次に、攻撃者は何らかの手段でターゲット・パスワードに対応するベリファイアを入手し、辞書でベリファイアを検索してターゲット・パスワードを入手します。

Diffie-Hellman鍵交換アルゴリズム

これは、安全でないチャネルを通じて通信する2者に、当時者のみが知っている乱数で合意させる方法である。当時者は、Diffie-Hellman鍵交換アルゴリズムの実行中に安全でないチャネルを通じて情報を交換するが、攻撃者がネットワーク通信を分析して、合意した乱数を推定するのは計算上不可能である。Oracle Advanced Securityでは、Diffie-Hellman鍵交換アルゴリズムを使用してセッション鍵を生成する。

デジタル署名

デジタル署名は、公開鍵アルゴリズムを使用して送信者の秘密鍵で送信者のメッセージに署名するときに作成される。このデジタル署名によって、文書が信頼できるものであること、別のエンティティで偽造されていないこと、変更されていないこと、送信者によって拒否されないことが保証される。

ディレクトリ情報ツリー(DIT)

LDAPディレクトリ内のエントリのDNから構成される階層ツリー型構造。「識別名(DN)」を参照。

ディレクトリ・ネーミング

データベース・サービス、ネット・サービス名またはネット・サービス別名を中央ディレクトリ・サーバーに格納されている接続記述子に変換するネーミング・メソッド。A

ディレクトリ・ネーミング・コンテキスト

ディレクトリ・サーバー内で意味を持つサブツリー。通常は、組織サブツリーの最上位です。あるディレクトリでは、固定のこのようなコンテキストが1個のみ許可されますが、他のディレクトリでは、ディレクトリ管理者によって0個から多数までのコンテキストを構成できます。

分散コンピューティング環境(DCE)

分散環境を提供するために複数のシステムにまたがって動作する統合ネットワーク・サービスのセット。分散アプリケーションとオペレーティング・システムまたはネットワーク・サービスとの間のミドルウェアであり、クライアント/サーバー・コンピューティング・モデルに基づきます。DCEはOpen Groupによってサポートされている。

識別名(DN)

ディレクトリ・エントリの一意の名前。親エントリからディレクトリ情報ツリーのルート・エントリまでのすべての個々の名前から構成されます。「ディレクトリ情報ツリー(DIT)」を参照してください。

ドメイン

ドメイン・ネーム・システム(DNS)ネームスペース内の任意のツリーまたはサブツリー。一般にドメインは、ホスト名が共通の接尾辞(ドメイン名)を共有するコンピュータのグループを表す。

ドメイン・ネーム・システム(DNS)

ドメインの階層に編成された、コンピュータおよびネットワーク・サービスのネーミングのためのシステム。DNSは、ユーザーにわかりやすい名前でコンピュータの位置を特定するためにTCP/IPネットワークで使用される。DNSは、このわかりやすい名前を、コンピュータが理解できるIPアドレスに変換する。

Oracle Net Servicesでは、DNSはTCP/IPアドレスのホスト名をIPアドレスに変換する。

暗号化テキスト

暗号化アルゴリズムを使用して暗号化されたテキスト。暗号化プロセスの出力ストリーム。最初に復号化の対象とならないかぎり、そのままでは読取りまたは解読できません。暗号文とも呼ばれます。暗号化テキストは、最終的には平文になります。

暗号化

対象受信者以外には判読不能なものとしてメッセージの形式を変換するプロセス。

エンタープライズ・ドメイン

データベースとエンタープライズ・ロールのグループで構成されたディレクトリ構造。1つのデータベースが同時に複数のエンタープライズ・ドメイン内に存在することはありません。エンタープライズ・ドメインは、共通ディレクトリ・データベースを共有するコンピュータの集合であるWindows 2000ドメインとは異なる。

エンタープライズ・ドメイン管理者

新規エンタープライズ・ドメイン管理者を追加する権限を含め、特定のエンタープライズ・ドメインの管理を認可されたユーザー。

エンタープライズ・ロール

エンタープライズ・ユーザーに割り当てられるアクセス権限。エンタープライズ・ドメイン内の1つ以上のデータベースに対するOracleロールベースの認可のセット。エンタープライズ・ロールは、ディレクトリに格納され、1つ以上のグローバル・ロールが含まれています。

エンタープライズ・ユーザー

ディレクトリで定義および管理されるユーザー。各エンタープライズ・ユーザーは、エンタープライズ全体で一意の識別情報を持ちます。

エントリ

ディレクトリの基本要素であり、ディレクトリ・ユーザーに関係のあるオブジェクトに関する情報が含まれている。

外部認証

KerberosやRADIUSなどのサード・パーティ認証サービスによるユーザー識別情報の検証。

ファイルシステム・メソッド

Identix Biometric認証を構成する際にファイルに指紋テンプレートを格納すること。このメソッドのかわりに、Oracleデータベース・メソッドを使用することもできる。

米国連邦情報処理標準(FIPS)

暗号化モジュールのセキュリティ要件を定義する米国連邦政府の標準であり、コンピュータおよびテレコミュニケーション・システム内の非機密情報を保護するセキュリティ・システムで使用されます。米国商務省国立標準技術研究所(NIST)によって発行されます。

FIPS

「米国連邦情報処理標準(FIPS)」を参照。

フォレスト

相互に信頼する1つ以上のActive Directoryツリーのグループ。フォレスト内のすべてのツリーは、共通のスキーマ、構成およびグローバル・カタログを共有する。フォレストに複数のツリーが含まれる場合、ツリーは連続したネームスペースを形成しない。特定フォレスト内のすべてのツリーは、推移的な双方向の信頼関係を介して相互に信頼する。

転送可能なチケット認可チケット

Kerberosの場合。FORWARDABLEフラグが設定されたサービス・チケット。このフラグにより、ユーザーにパスワードの再入力を要求せずに転送を認証できる。

GDS

「グローバル・ディレクトリ・サービス(GDS)」を参照。

グローバル・ディレクトリ・サービス(GDS)

DCE CDSと任意のX.500ディレクトリ・サービス間でエージェントとして機能するDCEディレクトリ・サービス。GDSとCDSはどちらも使用されなくなり、DCEでのみ使用されている。

グローバル・ロール

ディレクトリで管理されるロールだが、その権限は単一のデータベースに格納されている。グローバル・ロールは、次の構文を使用してデータベースに作成される。

CREATE ROLE <role_name> IDENTIFIED GLOBALLY;

グリッド・コンピューティング

単一の大規模コンピュータとして機能する大量のサーバーおよびストレージを調整するコンピューティング・アーキテクチャ。Oracle Grid Computingは、柔軟性のあるオンデマンド・コンピューティング・リソースをすべてのエンタープライズ・コンピューティング・ニーズに対して作成する。Oracle 10g以上のグリッド・コンピューティング・インフラストラクチャで稼働しているアプリケーションは、フェイルオーバー、ソフトウェア・プロビジョニングおよび管理のための共通インフラストラクチャ・サービスを利用できる。Oracle Grid Computingは、リソースの需要を分析し、それに応じて供給を調整する。

HTTP

Hypertext Transfer Protocol: World Wide Web上でのファイル(テキスト、グラフィック・イメージ、サウンド、ビデオおよびその他のマルチメディア・ファイル)の交換に関するルール・セット。TCP/IPプロトコル・スイート(インターネット上での情報交換の基礎)に対して、HTTPはアプリケーション・プロトコルである。

HTTPS

標準のHTTPアプリケーション・レイヤーのサブレイヤーとしてSecure Sockets Layer (SSL)を使用したプロトコル。

識別情報

エンティティの公開鍵とその他の公開情報の組合せ。公開情報には、電子メール・アドレスなどのユーザー識別データを含めることができる。宣言どおりのエンティティとして証明されているユーザー。

アイデンティティ管理

オンライン、すなわちデジタルなエンティティの作成、管理および使用。アイデンティティ管理には、デジタル識別情報の作成(デジタル識別情報のプロビジョニング)から、メンテナンス(電子リソースへのアクセスに関する組織ポリシーの施行)、さらに最終的な終了までのライフ・サイクル全体の安全な管理が含まれる。

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

Oracle Internet Directoryのサブツリーであり、Oracleコンテキストだけでなく、それぞれアクセス制御リストで保護されているユーザーおよびグループの追加サブツリーも含む。

初期チケット

Kerberos認証では、初期チケットまたはチケット認可チケット(TGT)によって、ユーザーが追加のサービス・チケットを要求する権利を持つものとして識別される。初期チケットがないと、他のチケットは取得できない。初期チケットは、okinitプログラムを実行し、パスワードを指定することで取得される。

インスタンス

稼働中のすべてのOracleデータベースは、Oracleインスタンスに関連付けられている。データベースが(コンピュータのタイプに関係なく)データベース・サーバー上で起動すると、Oracleによってシステム・グローバル領域(SGA)というメモリー領域が割り当てられ、Oracleプロセスが起動する。このSGAとOracleプロセスの組合せをインスタンスと呼ぶ。インスタンスのメモリーおよびプロセスは、関連付けられているデータベースのデータを効率的に管理し、1つ以上のデータベース・ユーザーを処理する。

整合性

受信したメッセージの内容が、送信された元のメッセージの内容から変更されていないことの保証。

Javaコード不明瞭化

Javaコード不明瞭化は、Javaプログラムをリバース・エンジニアリングから保護するために使用される。特別なプログラム(obfuscator)を使用して、コードに見つかったJavaシンボルをスクランブルする。プロセスは、元のプログラム構造をそのまま保持し、意図した動作を隠すためにクラス、メソッドおよび変数の名前を変更する一方でプログラムが正常に稼働するようにする。不明瞭化されていないJavaコードをデコンパイルして読み取ることは可能だが、不明瞭化されたJavaコードのデコンパイルは、米国政府の輸出規制を満たすのに十分なほど困難になっている。

Java Database Connectivity (JDBC)

Javaプログラムからリレーショナル・データベースに接続するための業界標準のJavaインタフェース。Sun Microsystemsが定義した。

JDBC

「Java Database Connectivity (JDBC)」を参照。

KDC

Key Distribution Center。Kerberos認証では、KDCはユーザー・プリンシパルのリストを管理し、ユーザーの初期チケットに関してkinit(okinitはOracleバージョン)プログラムを通じてアクセスされます。KDCおよびチケット認可サービスが同じエンティティに結合されることが多いですが、その場合もKDCと呼ばれます。チケット認可サービスは、サービス・プリンシパルのリストを管理し、このようなサービスを提供するサーバーに対してユーザーの認証が必要な場合にアクセスされます。KDCは、セキュア・ホストで実行する必要のある信頼できるサード・パーティです。チケット認可チケットおよびサービス・チケットを作成します。

Kerberos

Massachusetts Institute of TechnologyのAthenaプロジェクトで開発されたネットワーク認証サービスであり、分散環境でのセキュリティを強化します。Kerberosは信頼できるサード・パーティ認証システムであり、共有秘密鍵に基づき、サード・パーティがセキュアであることを前提とします。シングル・サインオン機能とデータベース・リンク認証(MIT Kerberosのみ)があり、パスワードを一元的に保管してPCのセキュリティを強化します。

鍵

データの暗号化時に、指定されたアルゴリズムによって指定された平文から生成される暗号文を決定する値。また、データの復号化時に、暗号文を正しく復号化するために必要な値。正しい鍵が提供された場合のみ、暗号文は正しく復号化される。

対称型暗号化アルゴリズムでは、同じデータの暗号化と復号化の両方に同じ鍵が使用される。非対称型暗号化アルゴリズム(公開鍵暗号化アルゴリズムまたは公開鍵暗号方式とも呼ぶ)では、同じデータの暗号化と復号化に異なる鍵が使用される。

鍵のペア

公開鍵およびそれに関連付けられている秘密鍵。「公開鍵と秘密鍵のペア」を参照。

keytabファイル

1つ以上のサービス・キーを含むKerberosキー表ファイル。キー表ファイルは、ユーザーが各自のパスワードを使用する場合と同様に、ホストまたはサービスで使用されます。

kinstance

Kerberos認証されたサービスのインスタンス化または場所。これは、任意の文字列だが、通常はサービスのホスト・コンピュータ名を指定する。

kservice

Kerberosサービス・オブジェクトの任意の名前。

LDAP

「Lightweight Directory Access Protocol (LDAP)」を参照。

ldap.oraファイル

次のディレクトリ・サーバー・アクセス情報を含むファイル。Oracle Net Configuration Assistantによって作成される。

- ディレクトリ・サーバーのタイプ

- ディレクトリ・サーバーの場所

- クライアントまたはサーバーで使用するデフォルトのアイデンティティ管理レルムまたはOracleコンテキスト(ポートを含む)

Lightweight Directory Access Protocol (LDAP)

標準の拡張可能ディレクトリ・アクセス・プロトコル。LDAPクライアントおよびサーバーが通信に使用する共通言語です。Oracle Internet Directoryなど、業界標準のディレクトリ製品をサポートする設計規則のフレームワーク。

リスナー

サーバー上のプロセスであり、着信クライアント接続リクエストをリスニングし、サーバーへのトラフィックを管理する。

クライアントがサーバーとのネットワーク・セッションをリクエストするたびに、リスナーが実際のリクエストを受信する。クライアント情報がリスナー情報と一致する場合、リスナーはサーバーへの接続を付与する。

listener.oraファイル

次の内容を識別するリスナーの構成ファイル。

- リスナー名

- 接続リクエストを受け入れるプロトコル・アドレス

- リスニングするサービス

通常、listener.oraファイルは、UNIXプラットフォームでは$ORACLE_HOME/network/adminに、WindowsではORACLE_BASE\ORACLE_HOME\network\adminにあります。

介在者

第三者によるメッセージの不正傍受という特徴を持つセキュリティ攻撃。第三者(介在者)は、メッセージを復号化して再暗号化し(元のメッセージを変更する場合と変更しない場合があります)、元の宛先である受信者に転送します。これらの処理はすべて、正当な送受信者が気付かないうちに行われます。このタイプのセキュリティ攻撃は、認証が行われていない場合のみ機能する。

メッセージ認証コード

データ認証コード(DAC)とも呼ばれる。秘密鍵を追加したチェックサム。鍵を持つ人のみが暗号チェックサムを検証できる。

メッセージ・ダイジェスト

「チェックサム」を参照。

ネーミング・メソッド

クライアント・アプリケーションがデータベース・サービスへの接続を試みるときに、接続識別子を接続記述子に変換するために使用する解決メソッド。

米国商務省国立標準技術研究所(NIST)

米国商務省の機関であり、コンピュータおよびテレコミュニケーション・システム内の暗号ベース・セキュリティ・システムの設計、取得および実装に関連するセキュリティ標準の開発を担う。連邦機関、または連邦の機能を遂行するために連邦政府にかわって情報を処理する連邦機関の請負業者やその他の組織によって運営されている。

ネット・サービス別名

ディレクトリ・サーバーのディレクトリ・ネーミング・オブジェクトの代替名。ディレクトリ・サーバーには、定義されたネット・サービス名またはデータベース・サービスのネット・サービス別名が格納される。ネット・サービス別名のエントリには、接続記述子情報はない。かわりに、別名の対象のオブジェクトの場所のみ参照する。クライアントがネット・サービス別名のディレクトリ検索をリクエストすると、ディレクトリは、エントリがネット・サービス別名であることを判断し、そのネット・サービス別名が実際に参照しているエントリであるかのように検索を実行する。

ネット・サービス名

クライアントがデータベース・サーバーを識別するために使用する名前。ネット・サービス名は、ポート番号とプロトコルにマップされる。接続文字列またはデータベース別名とも呼ぶ。

ネットワーク認証サービス

分散環境で、クライアントからサーバー、サーバー間およびユーザーからクライアントとサーバーの両方を認証する手段。ネットワーク認証サービスは、ユーザーに関する情報、ユーザーがアクセスする様々なサーバー上のサービスに関する情報、およびネットワーク上のクライアントとサーバーに関する情報を格納するためのリポジトリである。認証サーバーは、物理的に異なるコンピュータにすることも、システム内の別のサーバー上の共同の場所にある設備にすることもできる。可用性を保証するために、一部の認証サービスを複製してシングル・ポイント障害を回避できる。

ネットワーク・リスナー

1つ以上のプロトコルで1つ以上のデータベースの接続リクエストをリスニングするサーバー上のリスナー。「リスナー」を参照。

NIST

「米国連邦情報処理標準(FIPS)」を参照。

否認防止

メッセージの発信元、配信、送信または伝送の明白な証明。

不明瞭化

情報を判読不能な形式にスクランブルするプロセス。スクランブルに使用されているアルゴリズムが不明な場合、スクランブル解除が非常に困難になる。

不明瞭化プログラム

Javaソース・コードの不明瞭化に使用される特殊なプログラム。「不明瞭化」を参照。

オブジェクト・クラス

名前を持った属性のグループ。エントリに属性を割り当てるには、これらの属性を保持するオブジェクト・クラスをそのエントリに割り当てる。同じオブジェクト・クラスに関連付けられているすべてのオブジェクトは、同じ属性を共有する。

Oracleコンテキスト

1. LDAP準拠のインターネット・ディレクトリ内にあるcn=OracleContextというエントリ。このディレクトリには、Oracle Net Servicesディレクトリ・ネーミングおよびチェックサムのセキュリティのエントリなど、Oracleソフトウェア関連のすべての情報が格納されている。

1つのディレクトリに1つ以上のOracleコンテキストを設定できる。Oracleコンテキストは、通常はアイデンティティ管理レルムにある。

OracleContextAdmins

Oracle Internet Directoryの管理グループの1つ。このグループのメンバーは、関連付けられたレルムOracleコンテキスト内のすべてのグループおよびエントリへの完全なアクセス権を持つ。

Oracleデータベース・メソッド

Oracleデータベースを使用して、Indentix Biometric認証を構成する際に指紋テンプレートを格納すること。このメソッドのかわりに、ファイルシステム・メソッドを使用することもできる。

OracleDBAdmins

Oracle Internet Directoryの管理グループの1つ。このグループのメンバーは、ディレクトリに登録されている特定のデータベースのデータベース・ユーザー・スキーマ・マッピングを管理する。

OracleDBCreators

Oracle Internet Directoryの管理グループの1つ。このグループのメンバーは、Database Configuration Assistantを使用して新規データベースを作成し、ディレクトリに登録する。

OracleDBSecurityAdmins

Oracle Internet Directoryの管理グループの1つ。このグループのメンバーは、すべてのエンタープライズ・ドメインでエンタープライズ・ユーザーのアイデンティティ管理レルムを構成する権限を持つ。

Oracle Net Services

OracleサーバーまたはDesigner/2000などのOracleのツール製品を実行する2台以上のコンピュータがサード・パーティ・ネットワークを通じてデータを交換できるようにするOracle製品。Oracle Net Servicesは、分散処理および分散データベース機能をサポートする。Oracle Net Servicesは、通信プロトコルに依存しないためオープン・システムであり、ユーザーは多くのネットワーク環境へのインタフェースとしてOracle Netを使用できる。

OraclePasswordAccessibleDomains

「パスワードでアクセス可能なドメインのリスト」を参照。

Oracle PKI証明書使用

証明書でサポートされるOracleアプリケーションのタイプを定義する。

OracleUserSecurityAdmins

Oracle Internet Directoryの管理グループの1つ。このグループのメンバーは、ディレクトリ内のOracleデータベース・ユーザーのセキュリティを管理できる。

パスワードでアクセス可能なドメインのリスト

パスワード認証ユーザーからの接続を受け入れるために構成されたエンタープライズ・ドメインのグループ。

PCMCIAカード

Personal Computer Memory Card International Association (PCMCIA)標準に準拠する小さなクレジット・カード・サイズのコンピューティング・デバイス。これらのデバイスはPCカードとも呼ばれ、メモリー、モデムまたはハードウェア・セキュリティ・モジュールの追加に使用される。PCMCIAカードは、ハードウェア・セキュリティ・モジュールが公開鍵と秘密鍵のペアの秘密鍵コンポーネントを安全に格納する際に使用され、暗号操作も実行する場合がある。

ピア識別情報

SSL接続セッションは、特定のクライアントと特定のサーバー間のセッションである。ピアの識別情報は、セッションのセットアップの一部として設定される場合がある。接続先は、X.509証明連鎖によって識別されます。

PEM

インターネット上で安全な電子メールを提供するためにInternet Architecture Boardによって採用されたInternet Privacy-Enhanced Mailプロトコル標準。PEMプロトコルは、暗号化、認証、メッセージ整合性および鍵管理を提供する。PEMは、データ暗号化鍵を暗号化するための対称型スキームと公開鍵スキームの両方を含む様々な鍵管理アプローチと互換性を持つよう意図された包括的な標準である。PEMの仕様は、4つのInternet Engineering Task Force (IETF)ドキュメント、RFC 1421、1422、1423および1424に記載されている。

PKCS #10

認証リクエストの構文を記述するRSA Security社のPublic-Key Cryptography Standards (PKCS)仕様。認証リクエストは、識別名、公開鍵およびオプションの属性セットから構成され、証明書をリクエストするエンティティによって一括して署名される。このマニュアルでは、認証リクエストを証明書リクエストと呼ぶ。「証明書リクエスト」を参照。

PKCS #11

暗号情報を保持し、暗号操作を実行するデバイスに対する、Cryptokiと呼ばれるアプリケーション・プログラミング・インタフェース(API)を定義するRSA Security社のPublic-Key Cryptography Standards (PKCS)仕様。「PCMCIAカード」を参照。

PKCS #12

通常はウォレットと呼ばれる形式で個人認証資格証明を格納および転送するための転送構文を記述するRSA Security社のPublic-Key Cryptography Standards (PKCS)仕様。

PKI

「公開鍵インフラストラクチャ(PKI)」を参照。

平文

暗号化されていないメッセージ・テキスト。

プリンシパル

Kerberos資格証明のセットが割り当てられているクライアントまたはサーバーを一意に識別する文字列。通常、これにはkservice/kinstance@REALMという3つの部分が含まれます。ユーザーの場合、kserviceはユーザー名です。「kservice」、「kinstance」および「レルム」も参照してください。

秘密鍵

公開鍵暗号化では、この鍵が秘密鍵です。主に復号化に使用されますが、デジタル署名とともに暗号化にも使用されます。「公開鍵と秘密鍵のペア」を参照してください。

プロキシ認証

ファイアウォールなどの中間層を伴う環境で一般に使用されるプロセス。エンド・ユーザーは中間層に対して認証を行い、中間層はエンド・ユーザーのプロキシとして、ユーザーのかわりにディレクトリに対して認証を実施します。中間層は、プロキシ・ユーザーとしてディレクトリにログインします。プロキシ・ユーザーは識別情報を切り替えることができ、ディレクトリにログインするとエンド・ユーザーの識別情報に切り替わります。プロキシ・ユーザーは、特定のエンド・ユーザーに適した認可を使用して、そのエンド・ユーザーにかわって操作を実行できます。

公開鍵

公開鍵暗号化では、この鍵がすべてに対して公開されます。主に暗号化に使用されますが、署名の検証にも使用できます。「公開鍵と秘密鍵のペア」を参照してください。

公開鍵暗号化

メッセージの送信者が受信者の公開鍵でメッセージを暗号化するプロセス。配信時に、メッセージは受信者によって秘密鍵を使用して復号化される。

公開鍵インフラストラクチャ(PKI)

公開鍵暗号化の原理を利用した情報セキュリティ・テクノロジ。公開鍵暗号化には、共有の公開鍵と秘密鍵のペアを使用した情報の暗号化および復号化が含まれる。パブリック・ネットワーク内にセキュアでプライベートな通信を提供する。

公開鍵と秘密鍵のペア

暗号化および復号化に使用される2つの数値のセットであり、一方を秘密鍵と呼び、もう一方を公開鍵と呼ぶ。通常、公開鍵は広範に使用可能であるが、秘密鍵はそれぞれの所有者が保持する。数学的な関連性はあるが、一般には公開鍵から秘密鍵を導出するのは計算上不可能とみなされている。公開鍵と秘密鍵は、公開鍵暗号化アルゴリズムまたは公開鍵暗号方式とも呼ばれる非対称型暗号化アルゴリズムでのみ使用される。鍵のペアの公開鍵または秘密鍵のいずれかで暗号化されたデータは、鍵のペアのうち関連付けられている鍵で復号化できる。ただし、公開鍵で暗号化されたデータを同じ公開鍵で復号化することはできず、秘密鍵で暗号化されたデータを同じ秘密鍵で復号化することはできない。

RADIUS

Remote Authentication Dial-In User Service (RADIUS)は、リモート・アクセス・サーバーが中央サーバーと通信してダイアルイン・ユーザーを認証し、リクエストされたシステムまたはサービスへのアクセスを認可できるようにするクライアント/サーバー・プロトコルおよびソフトウェアである。

レルム

1. アイデンティティ管理レルムの省略形。 2.Kerberosオブジェクト。1つのKey Distribution Center/Ticket Granting Service (KDC/TGS)の下で動作するクライアントとサーバーのセット。同じ名前を共有する異なるレルム内のサービス(kserviceを参照)は一意である。

レルムOracleコンテキスト

Oracle Internet Directoryのアイデンティティ管理レルムの一部であるOracleコンテキスト。

レジストリ

コンピュータの構成情報を格納するWindowsリポジトリ。

リモート・コンピュータ

ローカル・コンピュータ以外のネットワーク上にあるコンピュータ。

ルート鍵証明書

「信頼できる証明書」を参照。

スキーマ

1. データベース・スキーマ: 表、ビュー、クラスタ、プロシージャ、パッケージ、属性、オブジェクト・クラスなどのオブジェクトと、それらに対応する一致ルールの名前付きコレクションであり、特定のユーザーに関連付けられています。 2.LDAPディレクトリ・スキーマ: 属性、オブジェクト・クラス、およびそれらに対応する一致ルールのコレクション。

スキーマ・マッピング

「ユーザー・スキーマ・マッピング」を参照。

Secure Hash Algorithm (SHA)

指定されたデータから160ビットの暗号メッセージ・ダイジェスト値を生成することにより、データの整合性を保証するアルゴリズム。データのわずか1ビットが変更された場合でも、データのSecure Hash Algorithmチェックサムが変更される。Secure Hash Algorithmで元のデータと同じ結果が生成されるように指定されたデータ・セットを偽造することは、計算上不可能と考えられる。

264ビット未満の長さのメッセージを受け取り、160ビットのメッセージ・ダイジェストを生成するアルゴリズムである。このアルゴリズムは、メッセージ・ダイジェストが長いほど、総当たり攻撃と侵入攻撃に対する安全度が増す。

Secure Sockets Layer (SSL)

ネットワーク接続を保護するためにNetscape社が開発した業界標準プロトコル。SSLは、公開鍵インフラストラクチャ(PKI)を使用した認証、暗号化、およびデータの整合性を提供する。

サーバー

サービスのプロバイダ。

サービス

1. Oracleデータベース・サーバーなど、クライアントによって使用されるネットワーク・リソース。

2. Windowsレジストリにインストールされ、Windowsによって管理される実行可能プロセス。サービスが作成され、開始された後は、コンピュータにログオンしているユーザーがいない場合でも実行できる。

サービス名

Kerberosベース認証の場合は、サービス・プリンシパルのkservice部分。

サービス・プリンシパル

「プリンシパル」を参照。

サービス表

Kerberos認証では、サービス表はkinstanceに存在するサービス・プリンシパルのリストである。KerberosをOracleで使用するには、その前にこの情報をKerberosから抽出し、Oracleサーバー・コンピュータにコピーする必要がある。

サービス・チケット

クライアントの認証に使用される信頼できる情報。初期チケットとも呼ばれるチケット認可チケットは、okinitを直接または間接的に実行し、パスワードを指定することで取得され、クライアントがサービス・チケットを要求するために使用される。サービス・チケットは、クライアントがサービスへの認証を受けるときに使用されます。

セッション鍵

少なくとも二者(通常はクライアントとサーバー)によって共有される鍵であり、単一の通信セッション中のデータ暗号化に使用されます。セッション鍵は通常、ネットワーク・トラフィックを暗号化するために使用されます。クライアントとサーバーはセッションの開始時にセッション鍵をネゴシエーションすることができ、その鍵はそのセッションの関係者間のすべてのネットワーク・トラフィックを暗号化するために使用されます。クライアントとサーバーが新しいセッションで再び通信する場合は、新しいセッション鍵をネゴシエーションします。

セッション・レイヤー

プレゼンテーション・レイヤーのエンティティが必要とするサービスを提供するネットワーク・レイヤーであり、エンティティで対話の編成と同期およびデータ交換の管理を行えるようにする。このレイヤーは、クライアントとサーバー間でネットワーク・セッションを確立、管理および終了する。セッション・レイヤーの例には、ネットワーク・セッションがある。

SHA

「Secure Hash Algorithm (SHA)」を参照。

共有スキーマ

複数のエンタープライズ・ユーザーが使用できるデータベースまたはアプリケーション・スキーマ。Oracle Advanced Securityでは、データベース上の同じ共有スキーマへの複数のエンタープライズ・ユーザーのマッピングがサポートされます。これにより、管理者はそれぞれのデータベースでユーザーごとにアカウントを作成する必要がなくなります。管理者は、ユーザーを1つの場所、つまり、エンタープライズ・ディレクトリに作成して、そのユーザーを共有スキーマにマップできます。この共有スキーマには他のエンタープライズ・ユーザーもマップできます。ユーザー/スキーマの分割とも呼ばれます。

単一鍵ペア・ウォレット

単一のユーザー証明書とそれに関連する秘密鍵が含まれるPKCS #12形式のウォレット。公開鍵は証明書に埋め込まれている。

単一パスワード認証

単一のパスワードを使用して複数のデータベースでユーザーを認証する機能。Oracle Advanced Security実装では、パスワードはLDAP準拠のディレクトリに格納され、暗号化やアクセス制御リストで保護される。

シングル・サインオン(SSO)

ユーザーが1度認証を受けると、その後の他のデータベースまたはアプリケーションへの接続に、厳密な認証が透過的に実施される機能。シングル・サインオンでは、ユーザーは1回の接続中に入力した単一のパスワードで複数のアカウントおよびアプリケーションにアクセスできる。単一のパスワードによる単一の認証。Oracle Advanced Securityは、Kerberos、DCEおよびSSLベースのシングル・サインオンをサポートしています。

スマートカード

ユーザー名やパスワードなどの情報を格納するため、また認証交換に関連する計算を実行するための集積回路が埋め込まれた(クレジット・カードに似た)プラスチックのカード。スマートカードは、クライアントまたはサーバーでハードウェア・デバイスによって読み取られる。

スマートカードは、1回かぎりのパスワードとして使用できる乱数を生成できる。この場合、スマートカードは、サーバー上のサービスと同期するため、サーバーはスマートカードによって同じパスワードが生成されると想定する。

Sniffer

ネットワークからのプライベート・データ・トラフィックを不正にリスニングまたは取得するために使用されるデバイス。

sqlnet.oraファイル

次の内容を指定するクライアントまたはサーバーの構成ファイル。

- 修飾されていないサービス名またはネット・サービス名に付加するクライアント・ドメイン

- 名前を変換する際にクライアントで使用するネーミング・メソッドの順序

- 使用するロギングおよびトレース機能

- 接続のルート

- デフォルトのOracle Names Server

- 外部ネーミング・パラメータ

- Oracle Advanced Securityパラメータ

通常、sqlnet.oraファイルは、UNIXプラットフォームでは$ORACLE_HOME/network/adminに、WindowsプラットフォームではORACLE_BASE\ORACLE_HOME\network\adminにあります。

SSO

「シングル・サインオン(SSO)」を参照。

システム・グローバル領域(SGA)

Oracleインスタンスのデータおよび制御情報を含む共有メモリー構造のグループ。

システム識別子(SID)

Oracleインスタンスの一意の名前。Oracleデータベース間を切り替えるには、ユーザーが目的のSIDを指定する必要がある。SIDは、tnsnames.oraファイル内の接続記述子のCONNECT DATA部分と、listener.oraファイル内のネットワーク・リスナーの定義に含まれる。

チケット

所有者の識別に役立つ情報。「サービス・チケット」を参照。

tnsnames.ora

接続記述子が含まれているファイル。各接続記述子はネット・サービス名にマップされます。すべてのクライアントまたは各クライアントで使用するために、このファイルを集中して維持することも、ローカルで維持することもできます。このファイルは通常、プラットフォームに応じて次の場所にあります。

- (UNIXの場合)ORACLE_HOME/network/admin

- (Windowsの場合)ORACLE_BASE\ORACLE_HOME\network\admin

トークン・カード

ユーザーが容易に認証サービスを利用できるように、数種類のメカニズムを提供するデバイス。一部のトークン・カードは、認証サービスと同期されている1回かぎりのパスワードを提供する。サーバーは認証サービスとやりとりすることにより、トークン・カードが提供するパスワードをいつでも検証できる。チャレンジ・レスポンス・ベースで動作するトークン・カードもある。その場合、サーバーはユーザーがトークン・カードに入力するチャレンジ(番号)を提供する。そして、トークン・カードは別の番号(チャレンジから暗号的に導出)を提供し、それをユーザーがサーバーに提供する。

トランスポート・レイヤー

データ・フロー制御とエラー・リカバリ方式を通じてエンドツーエンドの信頼性を維持するネットワーキング・レイヤー。Oracle Net Servicesは、トランスポート・レイヤーにOracleプロトコル・サポートを使用します。

信頼できる証明書

一定の信頼度を有すると認定されたサード・パーティの識別情報で、ルート鍵証明書とも呼ばれることがある。信頼できる証明書は、エンティティが本人(本物)であるという識別情報を検証する際に使用される。通常は、信頼する認証局を信頼できる証明書と呼ぶ。複数レベルの信頼できる証明書がある場合、証明連鎖で下位レベルにある信頼できる証明書では、それより上位レベルの証明書すべての再検証を必要としない。

信頼できる認証局

「認証局」を参照。

トラスト・ポイント

「信頼できる証明書」を参照。

ユーザー名

データベース内のオブジェクトに接続およびアクセスするための名前。

ユーザー・スキーマ・マッピング

ユーザーが存在するディレクトリ内のベースおよびユーザーがマップされるデータベース・スキーマの名前という値のペアを含むLDAPディレクトリ・エントリ。マッピングで参照されるユーザーは、データベースへの接続時に指定されたスキーマに接続されます。ユーザー・スキーマ・マッピング・エントリは、1つのデータベースにのみ適用できるか、ドメイン内のすべてのデータベースに適用できる。「共有スキーマ」を参照。

ユーザー/スキーマの分割

「共有スキーマ」を参照。

ユーザー検索ベース

LDAPディレクトリ内のユーザーが存在するノード。

ビュー

1つ以上の表(またはその他のビュー)の選択的な表示で、構造とデータの両方を示す。

ウォレット

個々のエンティティのセキュリティ資格証明の格納と管理に使用されるデータ構造。ウォレット・リソース・ロケータ (WRL)は、ウォレットの位置を特定するために必要なすべての情報を提供する。

ウォレット不明瞭化

ウォレット不明瞭化は、アクセスの前にユーザーにパスワードを問い合せずにOracleウォレットを格納およびアクセスするために使用される(シングル・サインオン(SSO)をサポートする)。

ウォレット・リソース・ロケータ

ウォレット・リソース・ロケータ(WRL)は、ウォレットの位置を特定するために必要なすべての情報を提供します。ウォレットが格納されているオペレーティング・システム・ディレクトリへのパス。

Windowsシステム固有の認証

Windowsサーバーおよびそのサーバー上で稼働しているデータベースへのクライアントのシングル・ログイン・アクセスを可能にする認証方式。

WRL

「ウォレット・リソース・ロケータ」を参照。

X.509

デジタル証明の業界標準仕様。

索引
A  C  D  E  G  K  M  N  O  P  R  S  U  V

A

Active Directoryの統合, C.1

ATTENTION_DESCRIPTION列, A.2.2

C

CASCADEパラメータ, A.2.3

CASCADE_FLAG列, A.2.2, A.2.2.1

CONNECT, 1.3, 1.3

D

データベース・リンク

RADIUSはサポートされない, 1.4

DBPASSWORD列, A.2.2 DBPASSWORD_EXIST_FLAG列, A.2.2, A.2.2.1 ディレクトリ管理グループ

OracleContextAdmins, 1.1.3.6

OracleDBAdmins, 1.1.3.6

OracleDBCreators, 1.1.3.6

OracleDBSecurityAdmins, 1.1.3.6

OraclePasswordAccessibleDomainsリスト, 1.1.3.6

OracleUserSecurityAdmins, 1.1.3.6

DIRPASSWORD列, A.2.2

E

エンタープライズ・ユーザー・セキュリティ

コンポーネント, 1.5

構成フロー・チャート, 4.1

構成のロードマップ, 4.2

ディレクトリ・エントリ, 1.1.3

エンタープライズ・ドメイン, 1.1.3.3

エンタープライズ・ロール, 1.1.3.2

エンタープライズ・ユーザー, 1.1.3.1

マッピング, 1.2.3

グローバル・ロール, 1.1.3.2 概要, 1.1 共有スキーマ, 1.2.1

構成, 1.2.2

ツールの概要, 3.1 サード・パーティ・ディレクトリの使用, 1.1.2

G

グループ

OracleContextAdmins, 1.1.3.6

OracleDBAdmins, 1.1.3.6

OracleDBCreators, 1.1.3.6

OracleDBSecurityAdmins, 1.1.3.6

OraclePasswordAccessibleDomainsリスト, 1.1.3.6

OracleUserSecurityAdmins, 1.1.3.6

用語集, Glossary

K

KERBEROS_PNAME列, A.2.2

M

MAPPING_LEVEL列, A.2.2, A.2.2.1

MAPPING_TYPE列, A.2.2, A.2.2.1

mkstoreユーティリティ, 4.5.3.1

N

NEEDS_ATTENTION_FLAG列, A.2.2

ニックネーム, 4.3

O

OLD_SCHEMA_TYPE列, A.2.2

Oracle Internet Directory

エンタープライズ・ユーザー・セキュリティでサポートされるバージョン, 1.1.2

Oracle JDBC OCIドライバ

ユーザー移行ユーティリティで使用, A.2

OracleContextAdminsディレクトリ・グループ, 1.1.3.6

定義, Glossary

OracleDBAdminsディレクトリ・グループ, 1.1.3.6

概念, 1.1.3.4

定義, Glossary

OracleDBCreatorsディレクトリ・グループ, 1.1.3.6

定義, Glossary

OracleDBSecurityAdminsディレクトリ・グループ, 1.1.3.6

定義, Glossary

OraclePasswordAccessibleDomainsリスト・ディレクトリ・グループ, 1.1.3.6

定義, Glossary

OracleUserSecurityAdminsディレクトリ・グループ, 1.1.3.6

定義, Glossary

ORCL_GLOBAL_USR_MIGRATION_DATAインタフェース表, A.2.1.1

アクセス, A.2.2

ATTENTION_DESCRIPTION列, A.2.2

CASCADE_FLAG列, A.2.2, A.2.2.1

DBPASSWORD列, A.2.2

DBPASSWORD_EXIST_FLAG列, A.2.2, A.2.2.1

DIRPASSWORD列, A.2.2

KERBEROS_PNAME列, A.2.2

MAPPING_LEVEL列, A.2.2, A.2.2.1

MAPPING_TYPE列, A.2.2, A.2.2.1

NEEDS_ATTENTION_FLAG列, A.2.2

OLD_SCHEMA_TYPE列, A.2.2

PASSWORD_VERIFIER列, A.2.2

PHASE_COMPLETED列, A.2.2, A.2.2.1

SHARED_SCHEMA列, A.2.2, A.2.2.1

USERDN列, A.2.2, A.2.2.1

USERDN_EXIST_FLAG列, A.2.2, A.2.2.1

USERNAME列, A.2.2

P

段落タグ

用語集, Glossary

パスワード・ポリシー, 1.1.3.7 PASSWORD_VERIFIER列, A.2.2 PHASE_COMPLETED列, A.2.2, A.2.2.1 プロキシ

接続, 1.3, 1.3

R

RADIUS

データベース・リンクはサポートされない, 1.4

S

共有スキーマ, 1.2.2

SHARED_SCHEMA列, A.2.2, A.2.2.1

SSL外部ユーザー変換スクリプト, B.1

SYSスキーマ, A.2.1.1

U

EUSのアップグレード, D.1

ユーザー移行ユーティリティ

インタフェース表へのアクセス, A.2.2

ヘルプへのアクセス, A.6.1

ATTENTION_DESCRIPTION列, A.2.2

CASCADEパラメータ, A.2.3

CASCADE_FLAG列, A.2.2, A.2.2.1

証明書で認証されるユーザー, A.2.4

DBPASSWORD列, A.2.2

DBPASSWORD_EXIST_FLAG列, A.2.2, A.2.2.1

ユーティリティのディレクトリの場所, A.3

DIRPASSWORD列, A.2.2

例

パラメータ・テキスト・ファイル(par.txt), A.7.3

ユーザー・リスト・テキスト・ファイル(usrs.txt), A.7.3

CASCADE=NOの使用, A.7.2

CASCADE=YESの使用, A.7.2.1.2

MAPSCHEMA=PRIVATEの使用, A.7.1

MAPSCHEMA=SHAREDの使用, A.7.2

MAPTYPEオプションの使用, A.7.2.2

PARFILE, USERSFILEおよびLOGFILEパラメータの使用, A.7.3

KERBEROS_PNAME列, A.2.2 LOGFILEの優先順位, A.7.3 MAPPING_LEVEL列, A.2.2, A.2.2.1 MAPPING_TYPE列, A.2.2, A.2.2.1 MAPSCHEMAパラメータ

PRIVATE, A.6.11

SHARED, A.6.11

MAPTYPEパラメータ

DBマッピング・タイプ, A.6.12

DOMAINマッピング・タイプ, A.6.12

ENTRYマッピング・レベル, A.6.12

SUBTREEマッピング・レベル, A.6.12, A.7.2.2.1

NEEDS_ATTENTION_FLAG列, A.2.2 OLD_SCHEMA_TYPE列, A.2.2 ORCL_GLOBAL_USR_MIGRATION_DATAインタフェース表, A.2.1.1 パスワードで認証されるユーザー, A.2.4 PASSWORD_VERIFIER列, A.2.2 PHASE_COMPLETED列, A.2.2, A.2.2.1 削除したスキーマ・オブジェクトの取得, A.7.2.1.2 共有スキーマ・マッピング, A.2.3 SHARED_SCHEMA列, A.2.2, A.2.2.1 現行のリリースのSSL認証, A.2.4 SYSスキーマ, A.2.1.1 USERパラメータ

ALL_EXTERNAL, A.6.7

ALL_GLOBAL, A.6.7

LIST, A.6.7

USERSFILE, A.6.7

USERDN列, A.2.2, A.2.2.1 USERDN_EXIST_FLAG列, A.2.2, A.2.2.1 USERNAME列, A.2.2 Oracle JDBC OCIドライバの使用, A.2 X.509 v3証明書, A.2.4 USERDN列, A.2.2, A.2.2.1 USERDN_EXIST_FLAG列, A.2.2, A.2.2.1 USERNAME列, A.2.2

V

データベース・ウォレットDNの表示, 4.5.3.1

オラクル社の法律上の注意点について

コピーライトについて

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）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

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

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。