技術解説 Windowsメタディレクトリ入門 ――　エンタープライズ環境におけるID情報管理の統合化とMicrosoft Identity Integration Server 2003　―― デジタルアドバンテージ 2003/08/21

　コンピュータ・ネットワークを安全かつ効率的に運用するには、ユーザーやアプリケーションなどに関するID（IDentification＝身分証明）を管理して、IDごとに利用できるリソースやサービスを制限するのが一般的だ。

　企業ユーザーのほとんどは、Windowsを使い始めるとき、自分のユーザー名とパスワードを入力して、自分が誰かをWindowsに認証してもらってからログオンしなければならない。これにより、部外者によるコンピュータの使用を禁止したり（ログオンに失敗するとWindowsを使えない）、一般ユーザーと管理者で実行可能な処理や利用可能なリソースに差を付けたりすることができるようになる。

　このWindowsログオン用のID情報は、ドメイン環境ならドメイン・コントローラに、ワークグループ環境ならローカル・コンピュータに保存されており、ログオン・ダイアログで入力されたユーザー名／パスワードがID情報と合致するかどうかが検査される。

　ユーザーに関するID情報としては、氏名や住所、役職、メール・アドレスなどがある。これ以外にも、コンピュータならコンピュータ名やIPアドレスなどが、アプリケーションなら提供可能なサービス一覧などがID情報として管理されることになる。

　こうしたさまざまなID情報を一元的に管理・検索するシステムがディレクトリ・サービスであり、マイクロソフトは、Windows標準のディレクトリ・サービスとして、Windows 2000にActive Directoryを組み込んだ。

複雑化するID管理

　こうしたID管理は、全社で一元的に行うのが理想的である。例えば社員を識別するIDカードがあったとしたら、同じIDカードを社内のどこででも使えるのが当たり前だ。事務所に入るとき、会議室に入るとき、食堂で食事をするときなど、それぞれ別々のIDカードが必要になるのではとても面倒で使いづらい。

　これはだれが考えても分かることだが、現実のコンピュータ・システムでは、さまざまな理由から、社内の至るところにID情報が別々に存在し、連携することなく独立して管理されていることの方が多い。

　この理由の1つは、ひとくちに社内の情報システムといっても、人事管理システムやそのほかの業務アプリケーション、メールサーバ、ファイル／プリンタ共有をつかさどるネットワークOSなど、実際には目的や用途に応じてさまざまなものが導入されており、これらを統合するのは容易ではないからだ。Active Directory（以下AD）は、こうした社内のID情報をADのレベルで一元的に管理可能にするしくみとして紹介された。しかし現実には、導入時期も、導入される場所も、利用目的もまったく異なる情報システムを、すべて単一のディレクトリ・サービスを使用するように修正するのは容易ではない。

　また急激なビジネス環境の変化にアプリケーションを臨機応変に対応させるために、アプリケーションが独自の形式などでIDを管理する必要に迫られることも少なくない。中央にあるディレクトリ・サービスで管理するデータ形式に手を入れるのは容易ではないが、単一アプリケーションだけで閉じているのなら、IDとして管理する属性を追加・変更するのは容易だからだ。

　また技術的には可能であっても、企業の地理的な事情や組織構成などによって、ID管理の統合化が阻害される場合もある。例えば、営業所や工場などが遠隔地にあり、低速なネットワーク回線しか利用できない場合には、認証や業務アプリケーション実行に必要なID情報をこれらの場所に物理的に配置しておかないと、認証やアプリケーション実行のたびに低速回線を通したID情報へのアクセスが発生してしまう。

　このような理由から、ID情報の単一管理は、多くの企業において「絵に描いた餅」になっているのが現状だ。

複数のID情報が連携せずに管理されている現状

現実問題として、多くの企業では、ネットワークOSやアプリケーション、プラットフォーム、部署などの単位で必要なID情報を独立して管理している。ID情報は、一部が互いに重複するものが多い。放置しておくと、整合性のないID情報が乱立して、同期などがとれなくなる。

メタディレクトリとは何か？

　ID情報の物理的な統合が困難なら、ID情報は分散配置したまま、論理的に単一のID情報管理サービスを提供してはどうか。これを可能にするのがメタディレクトリである。

メタディレクトリを利用したID情報管理

メタディレクトリは、ID情報の変更検知やデータ変換機能、ID情報の同期機能などを持ち、複数のディレクトリ（ID情報）をとりまとめる単一のインターフェイスを提供する。

　図にあるとおり、メタディレクトリは、さまざまなID情報にアクセスする機能とデータ変換機能、ID情報の変更検知、情報の同期機能を持っており、複数のID情報をとりまとめて単一のインターフェイスを提供する。これにより、物理的には複数のID情報をそのままに、論理的にはあたかも単一のディレクトリ・サービスとしてID情報にアクセスできるようになる。

メタディレクトリに求められる機能

　メタディレクトリには次のような機能が求められる。

■多種多様なID情報への接続機能
　いうまでもなく、メタディレクトリの価値は、多くのID情報を一元的に管理できるということだ。従ってメタディレクトリが対応するID情報が多ければ多いほど、メタディレクトリの価値は大きい。これには、多種多様なID情報データベースから、変更されたデータの取得、新規オブジェクトのデータベースへの追加、データベースからのオブジェクトの削除、既存オブジェクトの属性値の変更を行える必要がある。

　現在一般的な企業の情報システムでは、具体的には以下のようなID情報に対応する必要があるだろう。

• マイクロソフトActive Directory、Novell eDirectory、SunONE Directory Serverなどのベンダ独自のディレクトリ・サービス
• インターネット標準であるLDAPベースのディレクトリ・サービス
• 非LDAPベースのディレクトリ・サービス
• Exchange ServerやLotus Notesなどのアプリケーション・サーバ
• SQL Server、OracleなどのRDBMS
• CSV形式などのテキスト・ファイル

■ID情報間でのフロー管理機能
　メタディレクトリが管理するID情報のいずれかが変更されたら、メタディレクトリはそれを検出し、必要ならばほかのディレクトリ・サービスにその更新内容を通知し、ID情報の整合性を維持できなければならない。あるいは、複数のID情報からデータを収集し、それらを統合して1つのディレクトリ・サービスとしてアクセス可能にする必要がある。

　ID情報へのデータの追加、変更、削除が発生したら、メタディレクトリはそれらの内容（変更イベントと呼ばれる）を検知して、必要ならデータ変換を行い、別のID情報に変更イベントを通知し、変更イベントの内容を別のID情報に伝播させる。このようなID情報のフロー管理を行わなければ、ID情報間での不整合が発生し、すぐに無秩序な状態になってしまう。

　メタディレクトリの価値は、複数のID情報にアクセスできる単一のインターフェイス（アクセス方式やセキュリティ・モデルなど）が提供されることだ。これには、別々のID情報を収集して、メタディレクトリのレベルで統合する必要がある（このように収集されたID情報の集まりは“join”と呼ばれる）。情報収集の際には、関連する情報同士を同一の情報として追跡する機能なども求められる。

■データの完全性維持
　前のフロー管理で述べたとおり、メタディレクトリ環境で統合されるID情報は、それぞれが整合性のとれた状態で同期する必要がある。このことは、同期処理の途中で何らかの障害が発生した場合においても守られなければならない。

　複数のID情報を同期する過程で、一部のID情報に対する同期処理だけが失敗に終わると、データベースの不整合が生じてしまう。こうした一連のデータ変更処理を完結させるしくみとしてトランザクションがあるのだが、メタディレクトリ・サービスとしてトランザクション機能を持ったものは多くない。この場合メタディレクトリ・サービスは、データ更新のログなどを管理することで、データ変更の完全性を維持するようになっている。

Microsoft Identity Integration Server 2003

　Windows Server 2003, Enterprise Edition向けのメタディレクトリ・サービスとして、マイクロソフトでは、「Identity Integration Feature Pack for Microsoft Windows Server Active Directory」と「Microsoft Identity Integration Server 2003, Enterprise Edition」という製品を用意している（当初は「Microsoft Metadirectory Services 2003」という名称になるとされていた）。いずれも2003年8月現在では英語版のみが利用可能であり（英語版のリリースに関するニュースは「マイクロソフト、Microsoft Identity Integration Server 2003のRTMを完了（英語プレスリリースの参考訳）」を参照）、日本語版は現在開発中となっている。これらはマイクロソフトが買収したZOOMIT Corporation社のメタディレクトリ製品（ZOOMIT VIA）をベースとして開発されたものであり、以前から提供されていた「Microsoft Metadirectory Services（MMS）2.1／2.2」（日本語版は提供されていない）の後継となる。Microsoft Identity Integration Server 2003, Enterprise Edition（以下MIIS 2003と記述）は有償のフルセットのメタディレクトリ・サービスであるが、機能を限定して無償としたのがIdentity Integration Feature Pack for Microsoft Windows Server Active Directoryである。後者はWebページからダウンロードすることができる。

• Microsoft Identity Integration Server 2003のページ

• Microsoft Identity Integration Server 2003（英語版）のページ

• Identity Integration Feature Pack for Microsoft Windows Server Active Directory（英語版）のダウンロード・ページ

　両者の必要システム要件や機能をまとめると次のようになる。

	Identity Integration Feature Pack for Microsoft Windows Server Active Directory	Microsoft Identity Integration Server 2003, Enterprise Edition
ベースOS	Windows Server 2003, Enterprise Edition
対応DBシステム	SQL Server 2000, Enterprise Edition／Standard Edition／MSDE（Developer Edition） SP3（MSDEはテスト用途でのみ利用可）	SQL Server 2000, Enterprise Edition SP3
接続先ディレクトリ	Microsoft Active Directory／ADAM（Active Directory Application Mode）／Microsoft Exchange 2000 Server／Microsoft Exchange Server 2003	Microsoft Active Directory／ADAM／Microsoft Exchange 2000 Server／Microsoft Exchange Server 2003／SunONE Directory Server 4.x、5.x／SQL Server 7.0、2000／Oracle 8i、9i／DSML 2.0（Directory Services Markup Language）／LDIF（LDAP Directory Interchange Format）／カンマ区切りテキスト／固定長テキスト／属性−値を組にしたテキスト／NT 4ドメイン（SAM）／Exchange 5.5／Lotus Notes/Domino 4.6、5.0／Novell eDirectory／SQL Serverの「データ変換サービスDTS」機能を経由したほかのRDBMS

　このように、無償のIdentity Integration Feature Packは、基本的にActive DirectoryとADAM（後述）、Exchange Serverの3種類のディレクトリにしか接続できない。これに対し有償のMIIS 2003の方は、他社のディレクトリ製品やデータベース製品、Lotus Notes/Dominoなどのアプリケーション、各種テキスト・ファイルなど、豊富なデータ形式を統合することが可能である。

■ID情報管理の柔軟性と全社統合を可能にするADAM

　いうまでもなくActive Directoryは、Windows 2000 ServerおよびWindows Server 2003といったOSシステムの持つディレクトリ・サービスである。これに対しADAM（Active Directory Application Mode）は、OSのシステム・サービス・レベルではなく、Windowsドメインとは無関係に任意のインスタンスで利用可能な軽量なディレクトリ・サービスである（ドメイン・コントローラでなくても利用できる）。ディレクトリ・サービスの提供のみを目的としており、大がかりな導入設定や管理者のトレーニングなどを行わなくても、ユーザーやアプリケーションのニーズに応じて、自由にインスタンスを作成したり、スキーマやデータを拡張したりできる。

• Active Directory in Application Mode の紹介（マイクロソフト）

　本稿の冒頭で述べたとおり、異なるアプリケーションごとに、それぞれID情報を管理する必要に迫られることは少なくない。この際、Active Directoryのように中央集中型のディレクトリ・サービスを利用するように開発できればよいのだが、現実はそうならないと説明した。中央のデータ・スキーマ（データ構造）の修正は、万一の影響が全社に及ぶなどするため、あまり頻繁な修正は行いたくないからだ。

　ADAMは、Identity Integration Feature Pack／MIIS 2003と組み合わせることで、この問題を解決する。ADAMは、アプリケーションがID情報を管理するためのサービスを提供する。アプリケーションは、これらのサービスを利用して、独自のID情報管理が可能だ。ADAMはActive Directoryとは独立して自由なインスタンスで実行できる。複数のアプリケーションが、それぞれ独自のADAMインスタンスを使用することもできる（複数のアプリケーションで共通のADAMインスタンスを利用することも可能）。

　しかしこのままでは、アプリケーション独自のID情報が乱立してしまう。そこでIdentity Integration Feature Pack／MIIS 2003の登場である。ADAMによって管理されたID情報は、それぞれが独立していても、Identity Integration Feature Pack／MIIS 2003を利用することで一元的に管理できるようになるわけだ。

現実の企業ネットワークを統合可能にするMIIS 2003

　これまで、マイクロソフトの製品戦略は、すべてをマイクロソフトのテクノロジで固めるという暗黙の了解の下に展開されることが多かった。しかし現実の企業ネットワークで、すべてがマイクロソフト製品一色で統一できることはまれである。MIIS 2003の登場により、Windows製品と他社製品を企業ネットワークで共存させ、それらを効率よく管理することが可能になるものと期待される。

関連記事
連載 ディレクトリ統合	第4回 シングル・サインオンはメタディレクトリからXMLへ（@IT／Master of IP Network）

　

技術解説

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）