この第 4 部では、特殊な配備に関するトピックを扱います。次の章で構成されています。
第 13 章「Solaris での LDAP ベースネームサービスの使用」では、LDAP ベースのネームサービスについて説明します。
第 14 章「仮想ディレクトリの配備」では、Directory Proxy Server の仮想化機能について説明します。
第 15 章「同期されるデータを持つ配備の設計」では、Identity Synchronization for Windows を使用する配備について説明します。
この章では、SolarisTM オペレーティングシステム (Solaris OS) で提供される LDAP ネームサービスの概要を示します。Solaris OS でサポートされるネームサービスについては、『System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP)』のパート I「About Naming and Directory Services」で詳しく説明しています。
この章の内容は次のとおりです。
ネームサービスは、ユーザー、マシン、およびアプリケーションがネットワーク上で互いに通信するために必要な情報を 1 つの場所にまとめて格納します。この情報には、マシン (ホスト) の名前とアドレス、ユーザー名、パスワード、アクセス権、グループメンバーシップ、プリンタなどがあります。集中型のネームサービスがなければ、各マシンがこの情報のコピーを個別に維持しなければなりません。ネームサービスの情報はファイル、マップ、またはデータベーステーブルに格納できます。すべてのデータを集中化すれば、管理が容易になります。
Solaris OS では、次のネームサービスをサポートします。
DNS (ドメインネームシステム)
/etc ファイル (UNIX® オリジナルのネームシステム)
NIS (ネットワーク情報サービス)
NIS+ (ネットワーク情報サービスプラス)
LDAP (Lightweight Directory Access Protocol)
ただし、Sun の戦略的な方向性は、LDAP ベースのネームサービスへの移行です。
LDAP ネームサービスには、ほかのネームサービスにない次の利点があります。
アプリケーション固有のデータベースを置き換えることによって情報を統合し、管理が必要なデータベースの数を減らすことができる
複数の異なるネームサービス間でデータを共有できる
データの集中リポジトリを提供する
マスターサーバーとレプリカの間で、より頻繁なデータ同期が可能になる
マルチプラットフォームおよびマルチベンダー互換
LDAP ネームサービスには、次の制限があります。
Solaris 8 よりも前のクライアントはサポートされていません。
LDAP ネームサービスの設定と管理はほかに比べて複雑であり、慎重な計画が必要です。
同じクライアントマシン上で NIS クライアントとネイティブ LDAP クライアントが共存できません。
Solaris OS は、LDAP ディレクトリサーバーに加えて、Sun Java System Directory Server との組み合わせで LDAP ネームサービスをサポートします。Sun Java System Directory Server の使用も推奨されていますが、必須ではありません。
NIS から LDAP への移行は、データ移行とクライアント移行の 2 つのステップからなるプロセスです。Solaris OS には、NIS から LDAP への移行サービス (N2L サービス) が用意されており、このサービスを利用して両方のステップを実行できます。
N2L サービスは、NIS マスターサーバー上の既存の NIS デーモンを、NIS から LDAP への移行デーモンに置き換えます。またこのサービスは、NIS から LDAP へのマッピングサービスをそのサーバー上に作成します。マッピングファイルでは、NIS のマップエントリと、それに対応する LDAP のディレクトリ情報ツリー (DIT) エントリの間のマッピングを指定します。この移行処理を経た NIS マスターのことを N2L サーバーと呼びます。
NIS スレーブサーバーは、通常どおりに機能し続けます。スレーブサーバーは N2L サーバーを通常どおりの NIS マスターとして認識し、N2L サーバーから定期的にデータを更新します。inityp2l スクリプトは、これらの設定ファイルの初期定義を支援します。N2L サーバーが確立されたら、設定ファイルを直接編集することによって N2L を保守できます。
N2L サービスは次の機能をサポートします。
LDAP DIT への NIS マップのインポート
NIS と同等の速度および拡張性を備えた、DIT 情報へのクライアントアクセス
NIS から LDAP への移行方法の詳細は、『System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP)』の第 15 章「Transitioning From NIS to LDAP (Overview/Tasks)」を参照してください。
NIS+ のデータと LDAP の同期を保つことができますが、そのような同期には、以前は外部エージェントが必要でした。しかしながら、新しい NIS+ デーモンにより、LDAP サーバーを NIS+ データのデータリポジトリとして使用できるようになりました。この機能により、NIS+ クライアントと LDAP クライアントが同じネームサービス情報を共有できます。したがって、メインのネームサービスとして NIS+ を使用する構成から、LDAP を使用する構成への移行が容易になりました。
NIS+ から LDAP への移行方法の詳細は、『System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP)』の第 16 章「Transitioning From NIS+ to LDAP」を参照してください。
「仮想ディレクトリ」は Directory Proxy Server の高度な機能の 1 つであり、複数のデータリポジトリの情報をリアルタイムで集約します。この章では、Directory Server Enterprise Edition 配備における仮想ディレクトリの使用方法について説明します。
仮想ディレクトリのアーキテクチャー上の概念については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 18 章「Directory Proxy Server Virtualization」を参照してください。仮想ディレクトリの設定手順については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の第 23 章「Directory Proxy Server による仮想化 」を参照してください。
この章の内容は次のとおりです。
ディレクトリサービスの要件に次のいずれかが含まれる場合に、仮想ディレクトリの機能を配備できます。
複数のデータリポジトリ上に分散するエントリの集約されたビューを、クライアントアプリケーションが必要としている
たとえば、いくつかのディレクトリサーバーが存在しており、それらのサーバーには同じユーザーが含まれているが、それらがすべて異なるデータであるとします。仮想ディレクトリを使えば、あるユーザーのすべてのディレクトリにわたるエントリの単一ビューを作成できます。さらに、仮想ディレクトリは、個々のすべてのディレクトリを管理するための単一点として機能します。
サポートされるデータリポジトリの種類としては、LDAP ディレクトリ、MySQL などの Java Database Connectivity ( JDBCTM) に準拠したソース、LDIF フラットファイルなどが挙げられます。
ユーザー資格情報とアプリケーション固有データにそれぞれ異なるデータストアが必要である。
たとえば、アプリケーションによっては、企業ディレクトリ内に格納したくない固有データが存在する可能性があります。仮想ディレクトリを使えば、そうしたデータを分離しても、それがアプリケーションのソースの 1 つとして見えるようにすることができます。これにより、アプリケーション開発やデータ管理が単純化されます。なぜなら、アプリケーションがデータインフラストラクチャーの詳細を知る必要がなくなるからです。さらに、バックエンドデータソースに対する変更をアプリケーションから抽象化できます。
ユーザーの企業が別の企業を買収したか、別の企業と合併した。
仮想ディレクトリを使えば、2 つの企業のディレクトリをマージし、それらが単一のディレクトリとして表示されるようにすることができます。たとえば、2 つのディレクトリ dc=example,dc=com および dc=acquisition,dc=com があるとします。どちらのディレクトリも dc=example,dc=com のように見えることを要求するクライアントアプリケーションも存在します。
データベースのテーブルが DIT 階層の形式で表示されることを、クライアントアプリケーションが要求する。
複数のデータリポジトリに対する読み取りおよび書き込み操作が必要である。
類似点のない属性名に基づいて複数のフィールドを結合する条件が必要となる。
複数の LDAP または JDBC バックエンドのディレクトリやデータベース上に分散する複数値属性のサポートを、クライアントアプリケーションが要求する。
属性の名前変更、DN の書き換え、および DN 構文属性の属性値の書き換えが必要となる。
クライアントアプリケーションごとに、ある単一データリポジトリの異なるビューが必要となる。
この節では、仮想ディレクトリがどのようにして特定のビジネス要件を実現するかを示す単純なシナリオを提供します。より複雑なサンプルシナリオや仮想ディレクトリ構成の詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の「仮想設定の例」を参照してください。
Example.com ストアでは、異なる 3 つのデータリポジトリ内にユーザーデータを格納します。Example.com の Directory Server には、ユーザーデータの大部分が格納されています。ユーザーの電子メールアドレスは Active Directory 内に、HR データは MySQL データベース内に、それぞれ格納されています。
Example.com には、すべてのユーザーデータベースの完全なビューを必要とするクライアントアプリケーションがいくつか存在しています。次の図は、あるユーザーの ID の完全なビューを仮想ディレクトリがどのようにしてクライアントアプリケーションに提供するかを示したものです。
このシナリオでは、Example.com が新しい企業 Acquisition.com を買収します。この新しい企業のユーザーデータは、専用の Directory Server 内に格納されています。管理上の都合により、Example.com はこのディレクトリの構造を維持することを望んでいます。ただし、特定のクライアントアプリケーションでは、Acquisition.com のユーザーデータを「あたかも」Example.com のユーザーデータであるかのように表示する必要があります。
次の図は、仮想ディレクトリがどのようにして、買収した企業のデータを既存ディレクトリの構造内に仮想化マージするかを示したものです。
Acquisition.com のディレクトリは、ou=people ブランチの下の個別のブランチとして表示されます。Acquisition.com のディレクトリ内のエントリの DN は、仮想ディレクトリ経由で表示される際に変換されます。
Directory Server Enterprise Edition のコンポーネントである Identity Synchronization for Windows は、パスワードなどのユーザーアカウント情報を Directory Server と Windows の間で同期します。Windows Active Directory と Windows NT の両方がサポートされています。Identity Synchronization for Windows は、あらゆる規模の企業にとって、拡張性と強化されたセキュリティーを備えたパスワード同期ソリューションの構築に役立ちます。
Identity Synchronization for Windows のマニュアルの一覧については、http://docs.sun.com/coll/isw_04Q3 を参照してください。配備で Identity Synchronization for Windows の使用を計画している場合、この章で説明する問題に対処する必要があります。
パスワードの同期方向: Directory Server から Active Directory の方向または双方向にパスワードを同期する場合、Windows 2000 に High Encryption Pack をインストールする必要があります。このインストールにより、Active Directory over LDAP でパスワードを設定するときに必要な 128 ビット SSL が有効になります。
新規ユーザー作成の同期: Identity Synchronization for Windows が新規ユーザーの作成を同期しない場合、idsync resync コマンドを定期的に実行して、新しく作成されたユーザー間のリンクを確立する必要があります。idsync resync を実行することによってユーザーが明示的にリンクされるまでの間、新しく作成されたユーザーへの変更は同期されません。
生成サイズ: Identity Synchronization for Windows では、同期可能なユーザー数の上限は設定されていませんが、ユーザーの総数は配備に影響を及ぼします。主に影響を受けるのは、同期を開始する前に実行する必要がある idsync resync コマンドです。同期されるユーザー数が 100,000 を超える場合、idsync resync コマンドをバッチで実行します。このバッチモードは、最適なパフォーマンスを保証し、Sun Java System Message Queue にかかる負荷を制限します。
パフォーマンス要件: Identity Synchronization for Windows のパフォーマンスを制限する要因としては、ユーザー総数よりも同期率のほうが重要です。この要件のただ 1 つの例外は、idsync resync コマンドを実行するときです。
ピーク時の予測変更率: 同じシステム上でコアと 2 つのコネクタが稼働する Identity Synchronization for Windows の配備では、毎秒 10 件の同期という変更率が持続することは珍しくありません。必要な同期率がこの率を超える場合、Identity Synchronization for Windows を複数のマシンに分散させることによってパフォーマンスの向上を達成できます。たとえば、Identity Synchronization for Windows コアとは別のマシンにコネクタをインストールできます。
同期対象の Windows ドメイン数: 複数の Windows ドメインを同期する場合、activedirectorydomainname 属性または USER_NT_DOMAIN_NAME 属性を Directory Server 属性に同期する必要があります。この同期は、同期ユーザーリスト定義間のあいまいさを解決するために必要です。
配備内の Directory Server マスター、ハブ、および読み取り専用レプリカの数: 複数の Directory Server が存在する配備では、個々のマスターレプリカ、ハブレプリカ、および読み取り専用レプリカ上で Identity Synchronization for Windows Directory Server プラグインを有効にする必要があります。Identity Synchronization for Windows を設定するとき、1 つの Directory Server マスターが優先マスターとして指定されます。マスターの実行中、Directory Server コネクタは優先マスターで発生する変更を検出および適用します。このサーバーが停止した場合、コネクタは必要に応じて 2 番目のマスターに変更を適用できます。優先マスター上では Retro Changelog プラグイン (旧バージョン形式の更新履歴ログプラグイン) を有効にする必要があります。このマスターは、Identity Synchronization for Windows コアと同じ LAN 上に存在する必要があります。
セキュリティー: Directory Server コネクタまたは Active Directory コネクタが SSL を使用して Directory Server または Active Directory に接続する場合、これらのサーバー上で SSL を有効にする必要があります。信頼できる証明書のみを受け入れるようにコネクタが設定されている場合、追加の設定手順を実行する必要があります。この手順では、適切な認証局証明書をコネクタの証明書データベースにインポートします。Directory Server プラグインと Active Directory の間で SSL が必要な場合、Directory Server で SSL を有効にする必要があります。加えて、Active Directory SSL 証明書に署名するために使用される認証局証明書を、Directory Server の証明書データベースにインポートする必要があります。
Identity Synchronization for Windows を組み込んだ詳細な配備シナリオについては、『Sun Java System Identity Synchronization for Windows 6.0 Deployment Planning Guide 』を参照してください。