JP2000357119A - ディレクトリ・サービス・システム - Google Patents

Abstract

(57)【要約】 【課題】 別名に関する運用性を向上させる。 【解決手段】 実エントリ１内に属性として別名３を保
持し、従来のような実体を有するエイリアスエントリは
作らない。エイリアスエントリは、破線で示すように、
仮想のエイリアスエントリ２となる。 【効果】 別名に関する運用性に優れたディレクトリ・
サービス・システムを提供できる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ディレクトリ・サ
ービス・システムに関し、さらに詳しくは、別名に関す
る運用性を向上させたディレクトリ・サービス・システ
ムに関する。

【０００２】

【従来の技術】ＰＣ（Personal Computer）等の情報処
理装置で作成した文書をＬＡＮ（LocalArea Network）
等のネットワークを介して送受信する電子メールシステ
ムの普及が進んでいる。

【０００３】かかる電子メールシステムにおいて、受信
者のメールアドレスを検索する、いわゆる電子電話帳機
能として、ＣＣＩＴＴ勧告のＸ．５００（ＩＳＯ９５９
４）等に代表されるディレクトリ・サービスが利用され
始めている。Ｘ．５００準拠のディレクトリ・サービス
は、木構造（ディレクトリツリー）として階層管理され
たデータモデルを有する。木の枝葉に相当する個所に
は、エントリ（ディレクトリエントリ）が配置される。
各々のエントリは、階層情報を含む識別名（ＤＮ：Dist
inguished Name）で一意に識別され、ユーザのメールア
ドレス，姓名，電話番号，ＦＡＸ番号，写真など様々な
情報を属性として記憶可能である。Ｘ．５００は、クラ
イアント−サーバ型の分散システムアーキテクチャを採
用している。クライアントおよびサーバの役割を担う情
報処理装置間の通信プロトコルは、ＯＳＩ（Open Ｓyst
ems Interconnection）の７レイヤ構造に従ったＤＡＰ
（Directory Access Protocol）を規定している。

【０００４】一方、インターネットにおける標準化機関
であるＩＥＴＦ（Internet Engineering Task Force）
は、ＴＣＰ／ＩＰ上のディレクトリクライアント−サー
バ間プロトコルとして「ＬＤＡＰ：Lightweight Direct
ory Access Protocol（RFC２２５１）」を標準化した。

【０００５】ユーザは、クライアント上のアプリケーシ
ョンプログラムからＸ．５００等のディレクトリ・サー
バにＤＡＰまたはＬＤＡＰでアクセスし、ユーザのメー
ルアドレスなどの所望の情報を検索することが出来る。

【０００６】また、ＤＡＰまたはＬＤＡＰは、エントリ
追加，エントリ削除，エントリ名変更，属性値変更など
のディレクトリ更新系要求も規定している。

【０００７】ところで、Ｘ．５００では、各ユーザの情
報を格納するエントリ（実エントリと呼ぶ）の他に、実
エントリの別名をエイリアスエントリで管理する別名機
能について定義している。

【０００８】従来のディレクトリ・サービスにおける別
名機能は、例えば特開平７−１２９４５５号公報に記載
されている。

【０００９】図１２は、従来のディレクトリ情報の例示
図である。図１２中、矩形はエントリであり、木構造を
成す。３５は、あるユーザを表す実エントリである。こ
の実エントリ３５は、識別名ＤＮ"cn=Ｓato,ou=Osaka,o
=ABC,c=JP"に加えて、一般名（cn）とメールアドレス
（mail）を属性として保持している。３６は、エイリア
スエントリである。このエイリアスエントリ３６は、識
別名ＤＮ"cn=Ｓato,ou=Tokyo,o=ABC,c=JP"に加えて、実
エントリ３５の識別名ＤＮ"cn=Ｓato,ou=Osaka,o=ABC,c
=JP"を被エイリアス名属性（aliasedEntryName）３７と
して保持している。エイリアスエントリ３６の識別名Ｄ
Ｎ"cn=Ｓato,ou=Tokyo,o=ABC,c=JP"が、実エントリ３５
の別名となる。

【００１０】ディレクトリ・サーバは、クライアントか
ら受信した検索要求が実エントリを検索対象とする要求
である場合は、該実エントリに含まれる属性値（例えば
メールアドレス）を検索結果として返送する。一方、デ
ィレクトリ・サーバは、クライアントから受信した検索
要求がエイリアスエントリを検索対象とする要求である
場合は、該エイリアスエントリに含まれる被エイリアス
名属性を参照し、該被エイリアス名属性に登録された識
別名ＤＮが表すエントリを検索対象に置換し、該置換し
たエントリに含まれる属性値（例えばメールアドレス）
を検索結果として返送する。つまり、図１２において、
識別名ＤＮが"cn=Ｓato,ou=Osaka,o=ABC,c=JP"である実
エントリ３５または識別名ＤＮが"cn=Ｓato,ou=Tokyo,o
=ABC,c=JP"であるエイリアスエントリ３６を対象とした
検索要求に対する結果は、何れも実エントリ３５に含ま
れる属性値となる。

【００１１】以上のように、ディレクトリ・サービスに
おける別名機能は、複雑な組織構造をディレクトリ情報
に反映させる上で有用な機能である。

【００１２】

【発明が解決しようとする課題】上記従来技術では、次
の問題点により、別名に関する運用性が良好ではなかっ
た。 （１）クライアントから受信した検索要求が別名を検索
対象とする要求であった場合、ディレクトリ・サーバ
は、エイリアスエントリを検索した後、実エントリを探
索する必要があり、複数のエントリを辿る処理によるオ
ーバヘッドが発生し、検索性能が劣化しがちになる。

【００１３】（２）エイリアスエントリも実体のあるデ
ィレクトリエントリであるため、エイリアスエントリに
対する操作も実エントリに対する操作とは個別に行う必
要があり、操作要求が多重になって操作に手間がかか
る。また、処理に時間がかかるため、機器の電源断や異
常などの不慮の事態により処理が中断され、ディレクト
リ情報の整合性が損なわれてしまう可能性が高くなる。
図１３は、別名を持つエントリのエントリ追加，エント
リ削除およびエントリ名変更時におけるクライアント−
サーバ間の通信シーケンスの例示図である。エントリ追
加の場合、クライアント５は、最初に実エントリを追加
する。次に、登録した実エントリのエイリアスエントリ
を追加する。エントリ削除の場合、クライアント５は、
最初に実エントリを削除する。次に、削除した実エント
リのエイリアスエントリを削除する。エントリ名変更の
場合、クライアント５は、最初に実エントリの識別名Ｄ
Ｎを変更する。次に、識別名ＤＮを変更した実エントリ
のエイリアスエントリの被エイリアス名属性の値をエン
トリ名変更後の実エントリの識別名ＤＮに置き換える。
以上のように、操作に手間がかかる。更に、Ｘ．５００
では、１つの実エントリに複数の別名を付与することが
許されているため、３以上の操作要求を必要とする場合
がある。しかし、複数の更新要求を授受する間に機器の
電源断や異常などの不慮の事態により処理が中断する
と、ディレクトリ情報の整合性が損なわれてしまう。例
えば、エントリ削除の処理が中断すると、実エントリは
削除されているがエイリアスエントリは残存するといっ
た状態が発生してしまう。

【００１４】（３）エントリ削除またはエントリ名変更
の場合、運用管理者は、操作対象の実エントリのエイリ
アスエントリの存否を常に意識しなければならない。し
かし、実エントリの情報を参照するだけではエイリアス
エントリの存否を確認できない。このため、管理者は、
実エントリの識別名ＤＮが被エイリアス名属性に設定さ
れているエイリアスエントリを検索するために、ディレ
クトリ・サーバ中の全エントリを探索しなければなら
ず、手間がかかる。

【００１５】（４）付与できる別名が限定され、実エン
トリを管理するサーバの管理範囲以外のディレクトリ木
に属する別名を付与できない。図１４は、あるディレク
トリ情報の例示図である。３８は、実エントリであり、
識別名ＤＮは"cn=Ｓato,ou=Osaka,o=ABC,c=JP"である。
３９は、エイリアスエントリであり、被エイリアス名属
性４０に実エントリ３８の識別名が保持されている。エ
イリアスエントリ３９の識別名ＤＮ"cn=３４５,ou=Peop
le,o=ABC,c=JP"が、実エントリ３８の別名となる。ここ
で、エントリ１３１（識別名ＤＮ"ou=People,o=ABC,c=J
P"）以下のエントリ群はサーバＡに配置し、エントリ１
３２（識別名ＤＮ"ou=Tokyo,o=ABC,c=JP"）以下のエン
トリ群はサーバＢに配置し、エントリ１３３（識別名Ｄ
Ｎ"ou=Osaka,o=ABC,c=JP"）以下のエントリ群はサーバ
Ｃに配置する、という分散構成にした場合を想定する。
人事異動により実エントリ３８を変更する必要が生じた
とき、サーバＣ上の実エントリ３８を移動すると共にそ
のエイリアスエントリ３９内の被エイリアス名属性４０
も変更しなければならない。ところが、セキュリティ等
の問題から、サーバＣを更新できるのはサーバＣの運用
管理者に限定されており、サーバＡを更新できるのはサ
ーバＡの運用管理者に限定されているため、実エントリ
３８を管理するサーバＣの運用管理者は、サーバＡのエ
イリアスエントリ３９を更新できない。従って、実エン
トリを保持するサーバの管理範囲以外のディレクトリ木
に属する別名を付与できず、付与できる別名が限定され
ることになる。

【００１６】（５）ある実エントリに複数の別名を付与
する場合、相当する数のエイリアスエントリを追加しな
ければならない。

【００１７】そこで、本発明の目的は、上記問題点
（１）〜（５）を解消し、別名に関する運用性に優れた
ディレクトリ・サービス・システムを提供することにあ
る。

【００１８】

【課題を解決するための手段】第１の観点では、本発明
は、ユーザの識別名と属性とを保持したエントリに関す
る情報を記憶するデータベースをディレクトリ・サーバ
に備えると共にネットワークを介してのクライアントか
らの要求に応じて前記ディレクトリ・サーバが前記デー
タベース中のエントリに関する情報を検索または更新す
るディレクトリ・サービス・システムであって、前記エ
ントリに、１以上の別名に関する情報を保持可能とした
ことを特徴とするディレクトリ・サービス・システムを
提供する。上記第１の観点のディレクトリ・サービス・
システムでは、別名をエントリ自体に保持するため、検
索時にエントリ間を辿る処理が不要となり、検索性能を
向上できる。また、エントリの操作と別名の操作を一つ
の処理で達成でき、手間がかからず、障害発生時のディ
レクトリ情報の不整合を未然に防ぐことが出来る。ま
た、エントリだけを参照することにより別名を容易に確
認でき、別名を検索するための手間がかからない。ま
た、付与できる別名が限定されず、エントリを管理する
管理者の管理範囲以外のディレクトリ木に属する別名も
付与できる。また、エントリに複数の別名を登録するだ
けで、エントリを増加させること無く、複数の別名を付
与できる。

【００１９】上記第１の観点のディレクトリ・サービス
・システムにおいて、前記エントリは、別名を属性とし
て保持するか又は複数の識別名の一つとして保持するこ
とが好ましい。また、上記第１の観点のディレクトリ・
サービス・システムにおいて、前記ディレクトリ・サー
バは、別名から対応するエントリに関する情報を検索ま
たは更新する別名制御手段を有することが好ましい。

【００２０】第２の観点では、本発明は、上記第１の観
点のディレクトリ・サービス・システムにおいて、エン
トリの別名を一元的に管理する一元管理手段を備えると
共に、前記ディレクトリ・サーバは、更新する別名の一
意性を前記一元管理手段に問い合わせる問合せ手段を有
することを特徴とするディレクトリ・サービス・システ
ムを提供する。上記第２の観点のディレクトリ・サービ
ス・システムでは、他のサーバで登録された名称との重
複を防止することが出来る。

【００２１】第３の観点では、本発明は、上記第１また
は第２の観点のディレクトリ・サービス・システムにお
いて、前記ディレクトリ・サーバは、前記クライアント
からの単一の更新要求で１つのエントリと別名に対する
更新とを受け付けることを特徴とするディレクトリ・サ
ービス・システムを提供する。上記第３の観点のディレ
クトリ・サービス・システムでは、エントリの操作と別
名の操作を一つの要求で達成でき、クライアントに負担
がかからない。

【００２２】

【発明の実施の形態】以下、本発明の実施の形態につい
て図面を用いて説明する。図中、同一の部分には、同一
の符号を付加する。

【００２３】［概要］図１は、本発明に係るディレクト
リ情報の概念図である。１は、あるユーザを表す実エン
トリである。この実エントリ１は、識別名ＤＮ"cn=Ｓat
o,ou=Osaka,o=ABC,c=JP"に加えて、一般名（cn）とメー
ルアドレス（mail）とエイリアス名（aliasName）３と
を属性として保持している。この外に、電話番号や住所
などの様々な属性も追加可能である。前記エイリアス名
３には、実エントリ１の別名である"cn=Ｓato,ou=Toky
o,o=ABC,c=JP"が登録されている。識別名ＤＮ"cn=Ｓat
o,ou=Osaka,o=ABC,c=JP"もしくは"cn=Ｓato,ou=Tokyo,o
=ABC,c=JP"を検索対象とした検索要求を受けたディレク
トリ・サーバは、どちらも実エントリ１を対象とする要
求とみなす。

【００２４】このように本発明に係るディレクトリ情報
では、実エントリ１内に別名を保持し、従来例のような
実体を有するエイリアスエントリは作らない（破線で示
すように、仮想のエイリアスエントリ２となる）。

【００２５】なお、本発明に係るエイリアス名３は別名
の識別名ＤＮを保持するための属性である。そして、別
名を実エントリ中の一属性としているため、１回の操作
により、別名をもつエントリのエントリ追加，エントリ
削除，エントリ名変更を実現できる。これに対して、図
１２に示した従来のエイリアスエントリ３６における被
エイリアス名属性３７は、実エントリ３５の識別名ＤＮ
を保持するための属性である。そして、エイリアスエン
トリも実エントリであるため、１回の操作では、別名を
もつエントリのエントリ追加，エントリ削除，エントリ
名変更を実現できない。

【００２６】［構成］図２は、本発明に係るディレクト
リ・サービス・システムの機能構成図である。このディ
レクトリ・サービス・システム１００は、ディレクトリ
・サーバ４とクライアント５とをネットワーク１２で接
続して構成されている。前記ディレクトリ・サーバ４
は、ディレクトリエントリ情報を記憶するＤＢ６と、ク
ライアント５との間で通信処理を実行する通信制御部１
１と、クライアント５から受信したディレクトリアクセ
ス要求を解析するプロトコル解析部１０と、解析された
要求に従って前記ＤＢ６を検索し要求を実行するエント
リ管理部７とを具備して成る。前記エントリ管理部７
は、実エントリに対するＤＢアクセス処理を実行する実
エントリ管理部８と、別名に関わるＤＢアクセス処理を
実行する別名制御部９とを具備して成る。前記クライア
ント５は、従来と同じ機能構成である。前記ネットワー
ク１２は、ＬＡＮ等である。

【００２７】図３は、前記ディレクトリ・サーバ４のシ
ステム構成図である。このディレクトリ・サーバ４は、
ＣＰＵ１３と、磁気ディスク１６と、主メモリ１５と、
キーボード２１と、バス１４と、ディスプレイ１９と、
マウス２０とを具備して構成される。前記主メモリ１５
には、通信制御プログラム１１と、プロトコル解析プロ
グラム１０と、実エントリ管理プログラム８および別名
制御プログラム９を含むエントリ管理プログラム７とが
格納されている。これらのプログラムは、当初磁気ディ
スク１６に格納され、必要に応じて主メモリ１５に転送
された後、ＣＰＵ１３で実行される。前記磁気ディスク
１６には、ディレクトリＤＢ６がファイルとして格納さ
れている。このディレクトリＤＢ６は、各種属性を含む
ディレクトリエントリ情報を格納するエントリ・テーブ
ル１７と、識別名ＤＮを高速検索するためのインデック
ス情報を格納するＤＮインデックス・テーブル１８とか
ら成っている。前記クライアント５は、従来と同じシス
テム構成である。

【００２８】［ＤＢ６のデータ構造］図４は、前記エン
トリ・テーブル１７のデータ構造例示図である。このエ
ントリ・テーブル１７は、二次元の表形式を成し、各デ
ィレクトリエントリ毎に一行が割り当てられる。また、
各行には、ユニークな行識別番号が割り当てられ、エン
トリＩＤ２２に格納される。また、一般名２３、メール
アドレス２４、エイリアス名２５などの各属性は、列に
格納される。

【００２９】図５は、前記ＤＮインデックス・テーブル
１８のデータ構造例示図である。このＤＮインデックス
・テーブル１８は、二次元の表形式を成し、各識別名Ｄ
Ｎおよびエイリアス名毎に一行が割り当てられ、識別名
ＤＮまたはエイリアス名がＤＮ２６に格納される。ま
た、各行に対応する前記エントリ・テーブル１７の行識
別番号がＩＤ２７に格納される。従って、ある識別名Ｄ
Ｎとその別名とは、同一の行識別番号をＩＤ２７に持つ
ことになる。

【００３０】［操作例および通信シーケンス］図６は、
エントリ追加時の画面表示例である。エントリ追加時画
面２８は、追加する実エントリの識別名ＤＮを入力する
ＤＮ領域２９、一般名ｃｎを入力するｃｎ領域３０、メ
ールアドレスを入力するｍａｉｌ領域３１、別名を入力
する別名領域３２、入力した情報を設定するためのＯＫ
ボタン３３、入力中の情報をキャンセルするためのキャ
ンセルボタン３４から成る。ユーザは、クライアント５
のキーボード等を用いてＤＮ領域２９〜別名領域３２に
文字列を入力した後、ＯＫボタン３３をマウスでクリッ
クする。

【００３１】図７は、別名を持つエントリのエントリ追
加，エントリ削除およびエントリ名変更時におけるクラ
イアント−サーバ間の通信シーケンスの例示図である。
各通信要求は既定のディレクトリアクセスプロトコル
（例えばＤＡＰまたはＬＤＡＰ）である。エントリ追加
の場合、クライアント５は、エイリアス名属性を含む実
エントリを登録する。エントリ削除の場合、クライアン
ト５は、エイリアス名属性を含む実エントリを削除す
る。従って、同時に別名も削除されるエントリ名変更の
場合、クライアント５は、実エントリの識別名ＤＮを変
更する。

【００３２】［動作］ディレクトリ・サーバ４は、クラ
イアント５が発行した各種ディレクトリアクセス要求を
通信制御部１１で受信し、プロトコル解析部１０でアク
セス内容を解析した後、エントリ管理部７に対してエン
トリ更新（追加、変更）、エントリ削除、エントリ名変
更、エントリ検索処理を依頼する。

【００３３】図８は、エントリ管理部７のエントリ更新
処理に関わる動作を表すフローチャートである。Ｓ４０
１では、クライアント５からエントリ追加要求またはエ
ントリ変更要求を受信すると、実エントリ管理部８は、
該エントリの存否やアクセス権限等を確認し、当該更新
要求を受け入れ可能か判定し、受け入れ可能ならば、別
名制御部９に対して、別名に関わる処理を依頼する（Ｓ
４０２へ移行する）。受け入れ不能ならば、Ｓ４０９へ
移行する。Ｓ４０２では、別名制御部９は、別名属性値
を含むエントリ追加要求である場合もしくは更新する別
名属性値を含むエントリ変更要求である場合はＳ４０３
へ移行し、別名属性に関わらない要求である場合はＳ４
０５へ移行する。Ｓ４０３では、別名制御部９は、要求
に含まれる別名属性値が一意（ユニーク）つまり未登録
であるか否かをＤＮインデックス・テーブル１８の検索
によりチェックし、一意である場合はＳ４０４へ移行
し、一意でない場合はＳ４０９へ移行する。Ｓ４０４で
は、別名制御部９は、要求に含まれる別名属性値でＤＮ
インデックス・テーブル１８を更新する。すなわち、別
名属性値を含むエントリ追加要求の場合、ＤＮインデッ
クス・テーブル１８に新たな行を追加し、要求に含まれ
る別名をＤＮ２６に登録する。一方、更新する別名属性
値を含むエントリ変更要求の場合は、ＤＮインデックス
・テーブル１８から変更前の別名に相当する行を検索
し、ＤＮ２６を変更後の別名に置換する。

【００３４】Ｓ４０５では、実エントリ管理部８は、当
該更新要求の内容をＤＢ６に反映する。すなわち、エン
トリ追加要求の場合は、エントリ・テーブル１７に新た
な行を追加し、各属性を対応する列に登録する。一方、
エントリ変更要求の場合は、エントリ・テーブル１７か
ら変更対象のエントリに相当する行を検索し、変更対象
の属性に相当する列に登録された値を要求に含まれる属
性値に置換する。Ｓ４０６では、エントリ追加要求の場
合はＳ４０７へ移行し、エントリ変更要求の場合はＳ４
０８へ移行する。Ｓ４０７では、実エントリ管理部８
は、ＤＮインデックス・テーブル１８に新たな行を追加
し、追加エントリの識別名ＤＮをＤＮ２６に登録する。

【００３５】Ｓ４０８では、実エントリ管理部８は、通
信制御部１１を介して、正常に更新要求を処理した旨を
クライアント５へ返送する。そして、処理を終了する。

【００３６】Ｓ４０９では、実エントリ管理部８は、通
信制御部１１を介して、更新要求がエラーになった旨を
クライアント５へ返送する。そして、処理を終了する。

【００３７】図９は、エントリ管理部７のエントリ削除
処理に関わる動作を示すフローチャートである。Ｓ５０
１では、クライアント５からエントリ削除要求を受信す
ると、実エントリ管理部８は、該エントリの存否やアク
セス権限等を確認し、当該削除要求を受け入れ可能か判
定し、受け入れ可能ならば、別名制御部９に対して、別
名に関わる処理を依頼する（Ｓ５０２へ移行する）。受
け入れ不能ならば、Ｓ５０７へ移行する。Ｓ５０２で
は、別名制御部９は、エントリ・テーブル１７を探索す
ることにより削除対象のエントリを見つけ、当該エント
リのエイリアス名２５に値が登録されているか否かチェ
ックし、登録されている場合はＳ５０３へ移行し、値が
未登録の場合はＳ５０４へ移行する。Ｓ５０３では、エ
イリアス名２５に登録されている別名をＤＮ２６に持つ
行をＤＮインデックス・テーブル１８から削除する。

【００３８】Ｓ５０４では、実エントリ管理部８は、削
除対象のエントリに相当する行をエントリ・テーブル１
７から削除する。Ｓ５０５では、実エントリ管理部８
は、削除したエントリに相当する行をＤＮインデックス
・テーブル１８から削除する。Ｓ５０６では、実エント
リ管理部８は、通信制御部１１を介して、正常に削除要
求を処理した旨をクライアント５へ返送する。そして、
処理を終了する。

【００３９】Ｓ５０７では、実エントリ管理部８は、通
信制御部１１を介して、削除要求がエラーになった旨を
クライアント５へ返送する。そして、処理を終了する。

【００４０】図１０は、エントリ管理部７のエントリ名
変更処理に関わる動作を示すフローチャートである。本
処理は従来と同様であり、別名制御部９は機能しない。
Ｓ６０１では、クライアント５からエントリ名変更要求
を受信すると、実エントリ管理部８は、該エントリの存
否やアクセス権限等を確認し、当該エントリ名変更要求
を受け入れ可能か判定し、受け入れ可能ならばＳ６０２
へ移行し、受け入れ不能ならばＳ６０４へ移行する。Ｓ
６０２では、ＤＮインデックス・テーブル１８を探索す
ることにより変更前の識別名ＤＮが登録された行を見つ
け、ＤＮ２６に登録された値を指定された変更後の識別
名ＤＮに置換する。Ｓ６０３では、通信制御部１１を介
して、正常にエントリ名変更要求を処理した旨をクライ
アント５へ返送する。そして、処理を終了する。

【００４１】Ｓ６０４では、実エントリ管理部８は、通
信制御部１１を介して、エントリ名変更要求がエラーに
なった旨をクライアント５へ返送する。そして、処理を
終了する。

【００４２】図１１は、エントリ管理部７のエントリ検
索処理に関わる動作を示すフローチャートである。本処
理は従来と同様であり、別名制御部９は機能しない。Ｓ
７０１では、クライアント５からエントリ検索要求を受
信すると、実エントリ管理部８は、ＤＮインデックス・
テーブル１８を探索して、検索対象の識別名ＤＮが登録
された行を見つける。Ｓ７０２では、同一のＤＮがＤＮ
２６に登録された行を発見した場合には（Ｓ７０２）、
当該行に登録されたＩＤ２７を参照し、同一のＩＤがＩ
Ｄ２２に登録された行をエントリ・テーブル１７から見
つける。次に、実エントリ管理部８は、検索要求で指定
された０以上の属性を発見した行から抽出し（Ｓ７０
３）、検索結果としてクライアント５へ返送する（Ｓ７
０４）。

【００４３】−他の実施形態− 上記実施形態では、クライアント５から受信したエント
リ更新要求またはエントリ削除要求に既定のエイリアス
名３が含まれている場合に別名に関わる処理を実行する
ものとした（図８のＳ４０２、図９のＳ５０２）。しか
し、別名として扱う属性をサーバの運用管理者が定義で
きるようにしても良い。この場合、図８のＳ４０２また
は図９のＳ５０２において、別名制御部９は、定義され
た属性が要求に含まれている場合に別名に関わる処理を
実行する。

【００４４】また、上記実施形態では、実エントリの識
別名ＤＮおよび別名をＤＮインデックス・テーブル１８
に登録している。しかし、ＤＮインデックス・テーブル
１８に別名を登録しなくてもよい。この場合、図１１の
Ｓ７０１において、まず、ＤＮインデックス・テーブル
１８を検索し、見つからないときは続いてエントリ・テ
ーブル１７のエイリアス名２５を探索すれば良い。

【００４５】また、上記実施形態では、各エントリの別
名を該エントリの属性として保持している。しかし、各
エントリの別名を該エントリの他の識別名ＤＮとして保
持しても良い。この場合、各エントリが複数の識別名Ｄ
Ｎを保持できるようサーバを変更すればよい。

【００４６】また、上記実施形態では、実エントリを保
持するサーバの管理範囲以外のディレクトリ木に属する
別名も付与できる。しかし、図１２の例のような分散サ
ーバ構成の場合、他のサーバで登録された名称と重複し
てしまうことがある。これを確実に防止するためには、
各ディレクトリサーバに登録された別名を一元的にデー
タベースで管理する別名管理サーバをさらに設ければ良
い。各ディレクトリサーバは、別名に関する更新要求を
受信した際、前記別名管理サーバに別名更新の可否を問
い合わせる。別名管理サーバは、データベースを参照
し、問い合わせのあった別名の一意性を確認できたな
ら、該別名をデータベースに登録すると共に、更新可を
ディレクトリサーバに通知する。一方、該別名が既にデ
ータベースに登録済みであった場合は、更新不可をディ
レクトリサーバに通知する。

【００４７】

【発明の効果】本発明のディレクトリ・サービス・シス
テムによれば、次の各効果が得られ、別名に関する運用
性を向上することが出来る。 （１）別名をエントリ自体に保持するため、検索時にエ
ントリ間を辿る処理が不要となり、検索性能を向上でき
る。 （２）更新時には、エントリの操作と別名の操作を一つ
の要求・一つの処理で達成でき、手間がかからず、障害
発生時のディレクトリ情報の不整合を未然に防ぐことが
出来る。 （３）エントリに付与された別名を、当該エントリだけ
を参照することにより容易に確認できる。すなわち、別
名を検索するための手間がかからない。 （４）別名をエントリ自体に格納するため、該エントリ
を管理するサーバへのアクセス権限さえ有していれば、
所望の別名を付与可能である。また、他のサーバの管理
範囲のディレクトリ木に属する別名も付与可能である。
これを許容する場合には、他のサーバで登録された名称
との重複を防止するため、各運用管理者間でネーミング
規則を制定すれば良い。図１４の例の場合、東京の運用
管理者は"cn=１００００,ou=People,o=ABC,c=JP"から"c
n=１９９９９,ou=People,o=ABC,c=JP"までの別名を各東
京ユーザに割り当て、大阪の運用管理者は"cn=２０００
０,ou=People,o=ABC,c=JP"から"cn=２９９９９,ou=Peop
le,o=ABC,c=JP"までの別名を各大阪ユーザに割り当てる
ように予め取り決めておくことにより、名称の衝突を防
ぐことができる。また、別名を一元的に管理するサービ
スをシステムに導入すれば、一意な名称を確実に付与可
能である。 （５）エントリに複数の別名を登録するだけで、エント
リを増加させること無く、複数の別名を付与できる。

【図面の簡単な説明】

【図１】本発明に係るディレクトリ情報の概念図であ
る。

【図２】本発明に係るディレクトリ・サービス・システ
ムの機能構成図である。

【図３】ディレクトリ・サーバのシステム構成図であ
る。

【図４】エントリ・テーブルのデータ構造例示図であ
る。

【図５】ＤＮインデックス・テーブルのデータ構造例示
図である。

【図６】エントリ追加時の画面表示例である。

【図７】別名を持つエントリのエントリ追加，エントリ
削除およびエントリ名変更時におけるクライアント−サ
ーバ間の通信シーケンスの例示図である。

【図８】エントリ管理部のエントリ更新処理に関わる動
作を表すフローチャートである。

【図９】エントリ管理部のエントリ削除処理に関わる動
作を示すフローチャートである。

【図１０】エントリ管理部のエントリ名変更処理に関わ
る動作を示すフローチャートである。

【図１１】エントリ管理部のエントリ検索処理に関わる
動作を示すフローチャートである。

【図１２】従来のディレクトリ情報の例示図である。

【図１３】従来の別名に関わるエントリのエントリ追
加，エントリ削除およびエントリ名変更時におけるクラ
イアント−サーバ間の通信シーケンスの例示図である。

【図１４】従来のあるディレクトリ情報の例示図であ
る。

【符号の説明】

１…実エントリ ３…別名属性 ４…ディレクトリ・サーバ ５…クライアント ６…ＤＢ ７…エントリ管理部 ８…実エントリ管理部 ９…別名制御部 １０…プロトコル解析部 １１…通信制御部 １２…ネットワーク １００…ディレクトリ・サービス・システム

───────────────────────────────────────────────────── フロントページの続き (72)発明者 志賀 賢太 神奈川県川崎市麻生区王禅寺1099番地 株 式会社日立製作所システム開発研究所内 (72)発明者 川上 順彦 神奈川県川崎市麻生区王禅寺1099番地 株 式会社日立製作所システム開発研究所内 (72)発明者 由井 仁 神奈川県横浜市戸塚区5030番地 株式会社 日立製作所ソフトウエア事業部内 Ｆターム(参考） 5B075 NK43 NK46 PP02 PP03 PP12 5B082 GA08 HA00

Claims (5)

【特許請求の範囲】
1. 【請求項１】 ユーザの識別名と属性とを保持したエン
   トリに関する情報を記憶するデータベースをディレクト
   リ・サーバに備えると共にネットワークを介してのクラ
   イアントからの要求に応じて前記ディレクトリ・サーバ
   が前記データベース中のエントリに関する情報を検索ま
   たは更新するディレクトリ・サービス・システムであっ
   て、前記エントリに、１以上の別名に関する情報を保持
   可能としたことを特徴とするディレクトリ・サービス・
   システム。
2. 【請求項２】 請求項１に記載のディレクトリ・サービ
   ス・システムにおいて、前記エントリは、別名を属性と
   して保持するか又は複数の識別名の一つとして保持する
   ことを特徴とするディレクトリ・サービス・システム。
3. 【請求項３】 請求項１または請求項２に記載のディレ
   クトリ・サービス・システムにおいて、前記ディレクト
   リ・サーバは、別名から対応するエントリに関する情報
   を検索または更新する別名制御手段を有することを特徴
   とするディレクトリ・サービス・システム。
4. 【請求項４】 請求項１から請求項３に記載のディレク
   トリ・サービス・システムにおいて、エントリの別名を
   一元的に管理する一元管理手段を備えると共に、前記デ
   ィレクトリ・サーバは、更新する別名の一意性を前記一
   元管理手段に問い合わせる問合せ手段を有することを特
   徴とするディレクトリ・サービス・システム。
5. 【請求項５】 請求項１から請求項４に記載のディレク
   トリ・サービス・システムにおいて、前記ディレクトリ
   ・サーバは、前記クライアントからの単一の更新要求で
   １つのエントリと別名に対する更新とを受け付けること
   を特徴とするディレクトリ・サービス・システム。