特集 Windows Server 2003完全ガイド
|
|
Active Directory によるID管理の改良
MicrosoftはWindows Server 2003でADにいくつかの改良を加え、組織がADの導入や組織変更(例:既存のADスキーマと階層に影響を及ぼす新たな企業買収など)に容易に対処できるようにした。ID管理の側面から最も有効的な変更は、InetOrgPersonオブジェクト・クラスとDirectory Services Markup Language(DSML)のサポートである。
■InetOrgPersonの実装強化
Windows Server 2003では、ADはIDデータ標準のサポートを改善している。特に、InetOrgPersonオブジェクト・クラスのより完全な実装を提供している(従来、InetOrgPersonのサポートはアドオン・キットで提供されていた)。これはユーザーIDとアカウント・データ用の標準フィールド、およびデータ・タイプを指定する。例えば個人の氏名(Michael
Cherry)用のcommon name(cn)フィールド、ユーザーの第1電話番号用のフィールド(telephoneNumber)などである。InetOrgPerson標準(Internet
Request for Comments 2798で規定)は、Lightweight Directory Access Protocol(LDAP)規格をサポートするほかの多数のディレクトリ、例えばSun
MicrosystemsのSun One Directory(旧称Sun iPlanet)などによって利用されている。ADがInetOrgPersonをより完全にサポートしたことで、これらのほかのディレクトリ向けに書かれたアプリケーションとADの連携が可能になり、同規格をサポートするほかのディレクトリからのデータの移行が容易になる。
■DSMLバージョン 2.0をサポート
Microsoftはさらに、Directory Services Markup Languageバージョン 2.0(DSMLv2)をサポートしている。DSMLバージョン1.0は、XMLドキュメントによるディレクトリ・スキーマの定義をサポートしていた。DSMLv2は新たに、XMLドキュメントによるディレクトリ・クエリーとアップデートの表現をサポートしている。これにより、これらのXMLドキュメントを、インターネットをサポートしたSOAPなどのトランスポートと一緒に使用したり、Lightweight
Directory Interchange Format(LDIF)フォーマットを用いてファイルと同様に扱うことが可能になる。
DSMLv2のサポートにより、ADと同規格をサポートするほかのディレクトリ・サービス(Sun One Directory Serverバージョン5.2など)の相互運用性の改善が期待できる。また、ディレクトリからIDデータにアクセスする必要があるが、LDAPクライアントのない携帯電話や携帯情報端末(PDA)などのシナリオをサポートし、ディレクトリ上のIDデータへのファイアウォール経由のアクセスを容易にするかもしれない。
新ID管理ツール:Active Directory Application Mode
Microsoftはさらに、Active Directory Application Mode(ADAM)という新しいID管理ツールを導入した。ADAMは独立したWindows Server 2003サービスとして稼働できるADのインスタンスである。これにより、アプリケーションは自身のみに重要なIDデータを格納するサービスとしてADを使い、そのデータをメインのADデータベースに格納しないで処理することができる。
ADAMはドメイン・コントローラ上で稼働する必要がないため、アプリケーションのIDデータのストアとして便利である。また、異なる用途、あるいは異なるスキーマと複製スケジュールを必要とする複数のインスタンスを同じサーバー上で同時に稼働できる。開発者は組織全体のスキーマの変更(組織のほかの部分で行われたスキーマ変更と競合する可能性がある)を行わなくても、ADAMインスタンス上の基本ADスキーマを変更できる。開発を容易にするため、ADAMはドメイン・コントローラのない開発者のコンピュータ上で稼働させることもできる。これらのすべての機能により、ADAMは特定アプリケーション用のIDデータを格納するツールとして便利である。
ADはWindowsベースのネットワークとセキュリティ搭載アプリケーション(Exchangeなど)用のセキュリティID管理に用いるID情報のためのデータ・ストアなので、アプリケーションはADを認証と許可に使い、ADAMをアプリケーション専用のIDデータ・ストレージとして使うことが想定される。例えばWebアプリケーションは、ADAMを使ってパーソナリゼーション情報を格納するかもしれない。これにより、それらの情報をADに格納しなくても特定ユーザー向けのルック・アンド・フィールをカスタマイズ可能になる(以下の図「AD、ADAM、MIISの相互作用」を参照)。
AD、ADAM、MIISの相互作用 |
アプリケーションは、Active Directory(AD)、Active Directory Application
Mode(ADAM)、LOB(Line Of Business)アプリケーションからデータにアクセスする可能性がある。Microsoft Identity
Integration Server(MIIS)は、この3つのデータ・ストアすべてのIDデータを同期できる。 例えば、上図のようにユーザーが認証と許可を得なければいけないWebアプリケーションを考えてみよう。認証と許可に必要なIDデータはADに格納できる。 ユーザーに関する追加のIDデータ・アトリビュート(ニックネームや興味など)は、これまでADのスキーマ変更を必要としたが、ADAMに格納できるようになった。 ほかのアプリケーション情報(特定のトランザクションなど)は、LOBアプリケーションのデータベースに格納できる。 一部のID情報(ユーザーの氏名など)はすべてのデータ・ストアに必要とされるだろう。またLOBアプリケーションへのアクセスにはパスワードが要求されるだろう。このIDデータを変更する場合、変更は全データ・ストアに反映される必要がある。MIISまたは無料のIdentity Integration Feature Packは、すべてのデータ・ストア間ですべてのIDデータを同期させる手段を提供する。 |
Microsoftは、以下の判断基準のいずれかに該当するIDデータにはADAMを使用するよう企業に推奨している。
-
ローカルでのみ役立つIDデータ。例えば組織内の1部門または特定地域のみで役立つIDデータ
-
IDデータが変化しやすく、従ってIDデータを頻繁にすべてのADドメイン・コントローラに複製する必要がある場合
-
IDデータをADに格納するためにADのスキーマを変更する必要がある場合
将来の方向性:TrustBridgeと協調化
Microsoftは、2002年6月にTrustBridge(開発コード名)という新しいWindowsテクノロジを発表した。同技術により、企業は異なるプラットフォーム上のアプリケーションや独立した組織間でユーザーのID情報を共有可能になるという。TrustBridgeの狙いは、組織が内部リソースをパートナー組織の個人やアプリケーションと共有しやすくすることである。例えば、あるソフトウェア会社は、取引先のPR会社が次期製品の技術仕様書とマーケティング計画書を読めるようにしたいかもしれない。理想は、PR会社のユーザーがソフトウェア会社の情報にシングル・サインオンでアクセスできるようにして、まずPR会社に、続いて再度ソフトウェア会社にログオンする手間を省くことだ。しかし、ソフトウェア会社は何らかの方法でPR会社のユーザーを認証(IDを確認)し、彼らが信頼できることを確認する必要がある。
そんなとき、.NET Passport(MicrosoftのWebユーザー用シングル・サインオン・システム)がマルチプル・アカウントの代替として考えられる。組織は単純に、すべてのユーザー・アカウントをPassportのような1つの信頼できる組織に格納し、その組織に全ユーザーの認証を任せることもできる。この場合の問題点は、この信頼できる組織が攻撃者の格好の目標と化し、また単一点障害(Single Point of Failure)となることである。
TrustBridgeにより、組織は「協調化(federated)ID」という別のソリューションが使用可能になる。協調化IDシステムでは、各組織が自組織のユーザーを認証し、ユーザー・アカウントを維持する。ユーザーがパートナー組織にあるリソースにアクセスしたいときは、ユーザーの所属組織がユーザーのIDの証明書(認証データ)をパートナーに転送し、パートナーはユーザーの所属組織の信頼度に応じてアクセスを許可する。
Windows Server 2003におけるADの変更と、MIIS 2003およびADAMのリリースにより、TrustBridgeが必要とするインフラの大部分は整備されつつあり、多数のID情報の交換と同期が可能になっている。
不足している要素は、Web Services Architectureの完成だが、これは現在、標準化団体によって吟味されている。同アーキテクチャは以下の仕様を含んでいる。
-
WS-Secure Conversation:SOAPメッセージのやりとりを認証する標準的方法
-
WS-Trust:2つの組織間における直接的な信頼関係の構築と、信頼のおけるサード・パーティを介して多数の組織間で仲介による信頼関係を構築するための標準的なメカニズム
-
WS-Federation:WS-Security、WS-Policy、WS-Trust、WS-Secure Conversationの各サービスを組み合わせて協調化を実現する標準的な方法
-
WS-Authorization:許可データとポリシーを管理する標準的方法(許可は、認証後のユーザーに何を許可するかを定義する)
MIIS Server 2003 Enterprise Editionは、AD、ADAM、DSML、Exchange、LDAP、LDIF、Lotus Notes/Domino、Novell eDirectory、Oracle、Sun One Directory、Windows NT Domains、フラット・ファイル(コンマ、タブ、カラム区切りの値)をサポートする。MIIS 2003 Enterprise Editionの価格はプロセッサ当たり2万4999ドル。180日間の評価版が入手できるが、Standard Editionの評価版は存在しない。
Identity Integration Feature PackはMIISと同じ基本コンポーネントをそろえているが、ADとADAM、Exchangeディレクトリしかサポートしない。すでにWindows Server 2003 Enterprise Editionのライセンスを取得した顧客は、無料のアドオンとしてこれを入手できる。主にADの「クロスフォレスト信頼」シナリオで役立つ。クロスフォレスト信頼により、企業は合併などによる組織変更の後で、それまで独立していたAD設備(「フォレスト」)を組み合わせる一方、元の組織はそれぞれのユーザーとコンピュータの管理面の独立性を維持できるようになる。
参考資料
-
Windows Server 2003におけるADの変更点に関する詳細は「Insider's Eye:Active Directoryが次期Windowsで飛躍的進化」を参照。
-
TrustBridgeに関する追加情報は、「Insdier's Eye:シングル・サインオンでシンプルなリソース共有を実現するTrustBridge」を参照
-
GXA Web Servicesに関する追加情報は、「Insdier.NET/Insider's Eye:Webサービスのフレームワークを定義するGXA」を参照。
Directions on Microsoft日本語版 本記事は、(株)メディアセレクトが発行するマイクロソフト技術戦略情報誌「Directions on Microsoft日本語版」から、同社の許可を得て内容を転載したものです。Directions on Microsoftは、同社のWebサイトより定期購読の申込みができます。 |
INDEX | ||
[特集]Windows .NET Server 2003完全ガイド | ||
ADとメタディレクトリ・サービスが切り開く次世代の組織内ID管理 | ||
1.ID管理の重要性と難点 | ||
コラム:MIISのアーキテクチャ | ||
2.Windows Server 2003の最新ADテクノロジ | ||
Windows Server 2003完全ガイド |
- Azure Web Appsの中を「コンソール」や「シェル」でのぞいてみる (2017/7/27)
AzureのWeb Appsはどのような仕組みで動いているのか、オンプレミスのWindows OSと何が違うのか、などをちょっと探訪してみよう - Azure Storage ExplorerでStorageを手軽に操作する (2017/7/24)
エクスプローラのような感覚でAzure Storageにアクセスできる無償ツール「Azure Storage Explorer」。いざというときに使えるよう、事前にセットアップしておこう - Win 10でキーボード配列が誤認識された場合の対処 (2017/7/21)
キーボード配列が異なる言語に誤認識された場合の対処方法を紹介。英語キーボードが日本語配列として認識された場合などは、正しいキー配列に設定し直そう - Azure Web AppsでWordPressをインストールしてみる (2017/7/20)
これまでのIaaSに続き、Azureの大きな特徴といえるPaaSサービス、Azure App Serviceを試してみた! まずはWordPressをインストールしてみる
|
|