JP5675963B2 - ディレクトリデータを解決するための技法 - Google Patents

Description

本開示は、概してディレクトリデータサービスに関し、詳細にはディレクトリデータを解決するための技法に関する。

ディレクトリデータサービスは、ユーザー認証、メッセージ配送、およびグループポリシーの適用を含む様々なクライアントおよびアプリケーションにディレクトリデータを提供し得る。ディレクトリデータサービスは、例えば企業クラスのメッセージングセキュリティなど、高スループットが重要である複数の用途を果たし得る。アプリケーションおよび／またはディレクトリデータサービスは、キャッシュされたディレクトリデータを使用して性能を高め、ディレクトリサーバーにかかる負荷を減らす。ディレクトリデータは、グループと配布リストとを格納し得る。本開示において、配布リストは、メッセージを配送できる少なくとも１つの宛先電子メールアドレスを有するという点についてのみ、グループとは異なる。グループは複数のメンバーを有し得る。そしてメンバーの各々が、別のグループ（ネスト関係）であり得るか、ユーザーを表すエントリなどの「葉」エントリであり得る。グループは、多数のレベルに及ぶ深いネスト構造であり得る。適用ポリシーは、ディレクトリサーバー内にある１つまたはそれ以上のグループで設定されるか、それらのグループにバインドされ得る。適用ポリシーにバインドされたグループを「対象グループ」と称する。どのポリシーがユーザーに適用されるかを判断するには、アプリケーションが複数のレベルのグループをトラバースしてメンバーを特定する必要がある。トラバース中に、対象グループのメンバーを特定する必要のないグループおよびユーザーがメモリに読み込まれ得る。これらの余剰グループおよびユーザーは、特定のグループのグループメンバーシップ識別情報の解決を試行するときに、さらなる処理時間およびオーバーヘッドを加え得る。加えて、キャッシュ内でグループメンバーシップおよび関連データ構造をリフレッシュすると、ディレクトリサーバーにかかる負担が大きく増加し得る。

上記内容から、現在のディレクトリ技術に関しては、ユーザーまたはサブグループがどのグループのメンバーであるかを判断する目的で使用されるときに、大きな課題および欠点が存在し得ることが理解され得る。

ディレクトリデータを解決するための技法が開示される。特定の一例示的実施形態において、技法は、ディレクトリサーバーの１つまたはそれ以上の対象グループを特定するデータを受信することと、プロセッサを使用して、階層状のディレクトリデータに格納された１つまたはそれ以上のディレクトリエントリを、現在の対象グループに対応するディレクトリエントリからトラバースすることと、第１のディレクトリエントリに格納されたメンバーを特定するために第１のディレクトリエントリを読み出すことと、メンバーが第１のディレクトリエントリに格納されている場合に、そのメンバーのマッピングを現在の対象グループに追加することと、第１のディレクトリエントリがさらなるディレクトリエントリを格納しているかどうかを判断することと、第１のディレクトリエントリにさらなるディレクトリエントリが格納されている場合に、現在の対象グループが別のメンバーのマッピングに追加されるかどうか、およびさらなる階層状のディレクトリデータレベルが現在の対象グループを対象にトラバースされるかどうかを判断するために、さらなるディレクトリエントリを読み出すことと、を含む、ディレクトリデータを解決するための方法として実現され得る。

この特定の例示的実施形態の他の態様によれば、１つまたはそれ以上のディレクトリエントリは、ユーザー、グループ、および配布リストのうちの少なくとも１つを含み得る。

この特定の例示的実施形態のさらなる態様によれば、技法は、第２の対象グループの階層状のディレクトリデータに格納された１つまたはそれ以上のディレクトリエントリのトラバースを繰り返すことをさらに含み得る。

この特定の例示的実施形態のさらなる態様によれば、技法は、グループメンバーシップマップと関連付けられている特定されたユーザーのリストをキャッシュすることをさらに含み得る。

この特定の例示的実施形態のさらなる態様によれば、技法は、グループメンバーシップマップと関連付けられている特定された配布リストのリストをキャッシュすることをさらに含み得る。

この特定の例示的実施形態のさらなる態様によれば、技法は、グループメンバーシップマップと関連付けられている特定されたグループのリストをキャッシュすることをさらに含み得る。

この特定の例示的実施形態のさらなる態様によれば、ポリシーが対象グループに適用され得ることに加え、対象グループに対する１人またはそれ以上のメンバーのマッピングにより、ポリシーを適用することに関わる性能が向上し得る。

この特定の例示的実施形態のさらなる態様によれば、キャッシュでディレクトリエントリが利用可能である場合に、キャッシュを使用して解析が実行され、キャッシュでディレクトリエントリが利用できない場合には、ディレクトリサーバーに対してクエリが実行され得る。

この特定の例示的実施形態のさらなる態様によれば、ディレクトリエントリの期限が切れている場合には、キャッシュでディレクトリエントリが利用できない。

この特定の例示的実施形態のさらなる態様によれば、キャッシュ内のディレクトリエントリは、各ディレクトリエントリに割り当てられた別々のランダム値によって判断される期限に基づいて期限が切れ、ランダム値は、ある時点でキャッシュ内の期限切れのディレクトリエントリをリフレッシュするために必要な負荷を減らすために、キャッシュされたディレクトリエントリの期限を分散させる。

この特定の例示的実施形態のさらなる態様によれば、ディレクトリサーバーの１つまたはそれ以上の対象グループを特定するデータは、アプリケーションから受信され、対象グループに対する少なくとも１つのメンバーのマッピングが、ポリシーを適用するためアプリケーションに提供される。

この特定の例示的実施形態のさらなる態様によれば、技法は、階層状のディレクトリデータに格納された１つまたはそれ以上のディレクトリエントリにおける循環グループ関係をトラバース時に特定することと、循環グループ関係と関連付けられたデータ統合エラー情報を格納しているアラートを管理者に提供することと、をさらに含み得る。

この特定の例示的実施形態のさらなる態様によれば、技法は、ディレクトリサーバーが利用不可であると判断することと、ディレクトリデータを解決するために期限切れの対応ディレクトリエントリを使用することと、をさらに含み得る。

この特定の例示的実施形態のさらなる態様によれば、ディレクトリサーバーは、ＬＤＡＰ対応ディレクトリサーバーであり得る。

この特定の例示的実施形態のさらなる態様によれば、キャッシュされたディレクトリエントリは、グループに対する１つまたはそれ以上のユーザーのマッピングを生成するために階層状のディレクトリデータをトラバースするプロセスによって、およびディレクトリデータサービスクライアントによって使用され得る。

この特定の例示的実施形態のさらなる態様によれば、技法は、少なくとも１つのプロセッサに、方法を実行するためのコンピュータ処理を実行するように命令するために、少なくとも１つのプロセッサによって読み取り可能に構成されたコンピュータプログラム命令を記憶するための少なくとも１つのプロセッサ読み取り可能な記憶媒体として実現され得る。

別の特定の例示的実施形態において、技法は、ディレクトリデータを解決するための製品として実現され得る。そして製品は、少なくとも１つのプロセッサ読み出し可能な媒体と、その少なくとも１つの媒体に記憶された命令と、を備え、命令は、少なくとも１つのプロセッサによって少なくとも１つの媒体から読み出し可能であり、それによって少なくとも１つのプロセッサに、ディレクトリサーバーの１つまたはそれ以上の対象グループを特定するデータを受信するように動作させ、階層状のディレクトリデータに格納された１つまたはそれ以上のディレクトリエントリに対し、現在の対象グループに対応するディレクトリエントリから始まるトラバースを実行し、第１のディレクトリエントリに格納されたメンバーを特定するために第１のディレクトリエントリを読み出し、メンバーが第１のディレクトリエントリに格納されている場合には、現在の対象グループを、そのメンバーのマッピングに追加し、第１のディレクトリエントリがさらなるディレクトリエントリを格納しているかどうかを判断し、第１のディレクトリエントリにさらなるディレクトリエントリが格納されている場合には、さらなる階層状のディレクトリデータレベルが現在の対象グループを対象にトラバースされるかどうかを判断するために、さらなるディレクトリエントリを読み出すように構成されている。

さらに別の特定の例示的実施形態において、技法は、ネットワークに通信可能に連結された１つまたはそれ以上のプロセッサを備える、ディレクトリデータを解決するためのシステムとして実現され得る。そして１つまたはそれ以上のプロセッサは、ディレクトリサーバーの１つまたはそれ以上の対象グループを特定するデータを受信し、階層状のディレクトリデータに格納された１つまたはそれ以上のディレクトリエントリに対し、現在の対象グループに対応するディレクトリエントリから始まるトラバースを実行し、第１のディレクトリエントリに格納されたメンバーを特定するために第１のディレクトリエントリを読み出し、メンバーが第１のディレクトリエントリに格納されている場合には、現在の対象グループを、そのメンバーのマッピングに追加し、第１のディレクトリエントリがさらなるディレクトリエントリを格納しているかどうかを判断し、第１のディレクトリエントリにさらなるディレクトリエントリが格納されている場合には、さらなる階層状のディレクトリデータレベルが現在の対象グループを対象にトラバースされるかどうかを判断するために、さらなるディレクトリエントリを読み出すように構成されている。

この特定の例示的実施形態のさらなる態様によれば、１つまたはそれ以上のディレクトリエントリは、メンバー、グループ、および配布リストのうちの少なくとも１つを含み得る。

この特定の例示的実施形態のさらなる態様によれば、１つまたはそれ以上のプロセッサは、第２の対象グループの階層状のディレクトリデータに格納された１つまたはそれ以上のディレクトリエントリのトラバースを繰り返すようにさらに構成され得る。

この特定の例示的実施形態のさらなる態様によれば、キャッシュでディレクトリエントリが利用可能である場合に、キャッシュを使用して解析が実行され、キャッシュでディレクトリエントリが利用できない場合には、ディレクトリサーバーに対する問い合わせが行われ得る。

この特定の例示的実施形態のさらなる態様によれば、ディレクトリエントリは、各ディレクトリエントリに割り当てられた別々のランダム値によって判断される期限に基づいて期限が切れ、これらのランダム値は、ある時点で期限切れのディレクトリエントリをリフレッシュするために必要な負荷を減らすために、ディレクトリエントリの期限を分散させる。

この特定の例示的実施形態のさらなる態様によれば、ディレクトリサーバーの１つまたはそれ以上の対象グループを特定するデータは、アプリケーションから受信され、対象グループに対する少なくとも１つのメンバーのマッピングが、ポリシーを適用するためにそのアプリケーションに提供される。

この特定の例示的実施形態のさらなる態様によれば、キャッシュで利用可能なディレクトリエントリが、電子メールアドレスのローカル部に由来する完全名を使用したディレクトリエントリの一致を可能にするクエリフィルタトークンを使用して、キャッシュインデックスによって特定される。

さらに別の特定の例示的実施形態において、技法は、電子メールアドレスを格納している、複数の電子メールアドレスをサポートするディレクトリサーバーに向けられたディレクトリデータクエリを受信することと、完全名での一致を可能にするクエリフィルタトークンを使用してディレクトリサーバーに問い合わせることであって、クエリフィルタトークンが、問い合わせ用の完全名を導出するために、電子メールアドレスのローカル部におけるピリオドまたはアンダースコアをスペースに置き換えることと、完全名に対応するディレクトリエントリを取り出すことと、ディレクトリエントリをリクエスタに提供することと、を含む、ディレクトリデータを解決するための方法として実現され得る。

これより、本開示について、添付の図面に示す本開示の例示的実施形態を参照しながら、さらに詳しく説明する。本開示について、例示的実施形態を参照しながら以下説明するが、本開示はこれらの実施形態に制限されないことを理解すべきである。本明細書の教示にアクセスできる当業者であれば、さらなる実施態様、変更態様、および実施形態、さらには、本明細書に記載されている本開示の範囲内であり、かつ本開示が大きな有用性を持つであろう他の使用分野を認識するであろう。

本開示について十分な理解を促すために、添付の図面を参照する。図面中、同様の要素は同様の番号で参照されている。これらの図面は、本開示を制限するものと解釈されるべきなく、例示のみを意図するものである。

本開示の一実施形態にかかる、ディレクトリデータを解決するためのネットワークアーキテクチャを表すブロック図を示す。 本開示の一実施形態にかかるコンピュータシステムのブロック図を表す。 本開示の一実施形態にかかる、ディレクトリデータを解決するためのモジュールを示す。 本開示の一実施形態にかかる、ディレクトリデータを解決するための方法を示す。 本開示の一実施形態にかかる、ディレクトリデータを解決するための構成要素を示すブロック図を表す。 本開示の一実施形態にかかるディレクトリデータ構造を表す。 本開示の一実施形態にかかるディレクトリデータサービスキャッシュアクセスを示す流れ図を表す。 本開示の一実施形態にかかる、クエリフィルタトークンを使用してディレクトリエントリを一致させる方法を表す。

図１は、本開示の一実施形態にかかる、ディレクトリデータを解決するためのネットワークアーキテクチャ１００を表すブロック図を示す。図１は、ネットワークアーキテクチャ１００の簡略図であり、表されていない追加要素を含み得る。ネットワークアーキテクチャ１００は、クライアントシステム１１０、１２０および１３０に加え、ディレクトリサーバー１４０（１）−（Ｎ）およびネットワークデバイス１７０（１）−（Ｎ）も含み得る（そのうちの１つまたはそれ以上が、図２に示すコンピュータシステム２００を使用して実装され得る）。クライアントシステム１１０、１２０および１３０は、ネットワーク１５０に通信可能に連結され得る。ディレクトリサーバー１４０（１）−（Ｎ）は、記憶デバイス１６０（１）−（Ｎ）に通信可能に連結され得る。ネットワークデバイス１７０（１）−（Ｎ）は、管理モジュール（例えばディレクトリデータサービス１５４）を格納し得る。

図２のコンピュータシステム２００を参照すると、クライアントシステム１１０、１２０および１３０のうちの１つまたはそれ以上からネットワーク１５０への接続を提供するために、モデム２４７、ネットワークインターフェース２４８、またはその他何らかの方法が使用され得る。クライアントシステム１１０、１２０および１３０は、例えば、ライトウェイトディレクトリアクセスプロトコル（ＬＤＡＰ）クライアントまたは他のクライアントソフトウェアを使用して、ディレクトリサーバー１４０（１）−（Ｎ）にある情報にアクセス可能であり得る。かかるクライアントにより、クライアントシステム１１０、１２０および１３０が、ディレクトリサーバー１４０（１）−（Ｎ）か、あるいは記憶デバイス１６０（１）−（Ｎ）のうちの１つによってホストされるデータにアクセスでき得る。

ネットワーク１５０および／または１８０は、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、インターネット、セルラー方式ネットワーク、衛星ネットワーク、または、クライアント１１０、１２０、１３０、ディレクトリサーバー１４０（１）−（Ｎ）、およびネットワーク１５０および／または１８０に通信可能に連結された他のデバイスとの間での通信を許可する別のネットワークであり得る。ネットワーク１５０および／または１８０は、スタンドアロンネットワークとして、あるいは互いに協同して動作する上記例示的なタイプのネットワークのうちの１つまたは任意の数をさらに含み得る。ネットワーク１５０および／または１８０は、通信可能に連結された１つまたはそれ以上のクライアントまたはサーバーのうちの１つまたはそれ以上のプロトコルを利用し得る。ネットワーク１５０および／または１８０は、ネットワークデバイスのうちの１つまたはそれ以上のプロトコルと他のプロトコルとの間での変換を行い得る。ネットワーク１５０および１８０は、単一のネットワークとして各々表されているが、１つまたはそれ以上の実施形態によれば、ネットワーク１５０および／または１８０が複数の相互接続されたネットワークを備え得ることが理解されるべきである。

記憶デバイス１６０（１）−（Ｎ）は、ネットワークアクセス可能記憶装置であってよく、ディレクトリサーバー１４０（１）−（Ｎ）に対してローカル、リモート、またはそれらの組み合わせであってもよい。記憶デバイス１６０（１）−（Ｎ）は、低価格ディスクの冗長配列（「ＲＡＩＤ」）、磁気テープ、ディスク、記憶装置エリアネットワーク（「ＳＡＮ」）、インターネット小型コンピュータシステムインターフェース（「ｉＳＣＳＩ」） ＳＡＮ、ファイバチャネルＳＡＮ、共通インターネットファイルシステム（「ＣＩＦＳ」）、ネットワーク接続型記憶装置（「ＮＡＳ」）、ネットワークファイルシステム（「ＮＦＳ」）、光学ベース記憶装置、または他のコンピュータアクセス可能記憶装置を利用してもよい。記憶デバイス１６０（１）−（Ｎ）は、バックアップまたはアーカイブ目的で使用されてもよい。

いくつかの実施形態によれば、クライアント１１０、１２０、および１３０は、スマートフォン、ＰＤＡ、デスクトップコンピュータ、ラップトップコンピュータ、サーバー、他のコンピュータ、またはネットワーク１５０に無線または有線接続経由で連結された他のデバイスであり得る。クライアント１１０、１２０、および１３０は、ユーザー入力、データベース、ファイル、ウェブサービス、および／またはアプリケーションプログラミングインターフェースからデータを受信し得る。

ディレクトリサーバー１４０（１）−（Ｎ）は、例えば、Ｍｉｃｒｏｓｏｆｔ（登録商標） Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙ（登録商標）サーバー、ＩＢＭ（登録商標） Ｌｏｔｕｓ（登録商標） Ｄｏｍｉｎｏ（登録商標）サーバー、Ｓｕｎ（登録商標）ディレクトリサーバー、ＬＤＡＰ対応ディレクトリサーバー、データベースサーバー、１つまたはそれ以上のフラットファイルまたは他のデータ構造を格納するサーバー（例えばＸＭＬ）、あるいはネットワーク１５０に通信可能に連結された他のデバイスなどのディレクトリデータの１つまたはそれ以上のホストであり得る。ディレクトリサーバー１４０（１）−（Ｎ）は、アプリケーションデータ、バックアップデータ、または他のデータを記憶するための記憶デバイス１６０（１）−（Ｎ）のうちの１つまたはそれ以上を利用し得る。ディレクトリサーバー１４０（１）−（Ｎ）のうちの１つまたはそれ以上は、アプリケーションサーバーなど、クライアント１１０、１２０、および１３０に対するデータリクエストを処理し得るホストであり得る。

いくつかの実施形態によれば、ネットワーク１８０は、インターネットを表し得る。そしてネットワークデバイス１７０は、企業ＷＡＮまたはＬＡＮであり得るネットワーク１５０とネットワーク１８０との間の多量のデータトラフィックを扱うデバイスであり得る。例えば、ネットワークデバイス１７０のうちの１つまたはそれ以上は、メールゲートウェイ、ウェブゲートウェイ、あるいは、ユーザー認証および／または認可、識別情報管理、受信者の妥当性検証、アドレス解決、メッセージルーティング、アクセス制御、または他のアプリケーション挙動のためにディレクトリデータサービスを使用する別の機器またはアプリケーションであり得る。非制限的な例として、ネットワークデバイス１７０のうちの１つまたはそれ以上が、Ｓｙｍａｎｔｅｃ（登録商標） Ｂｒｉｇｈｔｍａｉｌ（登録商標） Ｇａｔｅｗａｙ、Ｓｙｍａｎｔｅｃ（登録商標） Ｗｅｂ Ｇａｔｅｗａｙ、Ｓｙｍａｎｔｅｃ（登録商標） Ｄａｔａ Ｌｏｓｓ Ｐｒｅｖｅｎｔｉｏｎ Ｈｏｓｔ、Ｓｙｍａｎｔｅｃ（登録商標） Ｅｎｄｐｏｉｎｔ Ｐｒｏｔｅｃｔｉｏｎ Ａｐｐｌｉｃａｔｉｏｎ、またはＢｒｉｇｈｔｍａｉｌ（登録商標） Ｍｅｓｓａｇｅ Ｆｉｌｔｅｒであり得る。ネットワークデバイス１７０のうちの１つまたはそれ以上は、ディレクトリデータサービス１５４を使用して、１つまたはそれ以上のディレクトリサーバーからのキャッシュデータを管理する。いくつかの実施形態によれば、各ネットワークデバイス１７０は、自身のデータをキャッシュし得る。１つまたはそれ以上の実施形態によれば、キャッシュデータは、ネットワークデバイス１７０のうちの２つまたはそれ以上の間で共有され得る。例えば、ネットワークデバイス１７０（１）は、複数のＢｒｉｇｈｔｍａｉｌ Ｇａｔｅｗａｙスキャナのコントロールセンターホストであり得る。コントロールセンターホストは、Ｂｒｉｇｈｔｍａｉｌ Ｇａｔｅｗａｙスキャナであり得る複数の他のネットワークデバイス１７０間で共有されるキャッシュディレクトリサービスデータを含み得る。キャッシュデータは、ネットワークデバイス１７０に記憶され得るか、あるいはネットワークデバイス１７０に通信可能に連結された電子記憶装置に記憶され得る。

ディレクトリデータサービス１５４は、ネットワークデバイスの構成要素、モジュール、あるいは、ディレクトリデータキャッシュ動作を管理するために統合されたハードウェアおよびソフトウェアの別の組み合わせであり得る。いくつかの実施形態によれば、ディレクトリデータサービス１５４は、高スループット処理用のディレクトリデータサービスを使用して、ゲートウェイ機器あるいは別の装置またはアプリケーションとのディレクトリデータ統合を行うための統一サービス指向アーキテクチャを提供し得る。

ディレクトリデータサービス１５４は、効率的なディレクトリデータグループ解決およびキャッシュ管理を可能にし得る。ディレクトリデータサービス１５４は、階層状のディレクトリサーバーに格納された１つまたはそれ以上のディレクトリエントリをトラバースし得る。トラバースは、現在の対象グループから開始され得る。ディレクトリエントリがキャッシュで利用可能な場合には、キャッシュを使用して解析が実行され得る。ディレクトリエントリがキャッシュで利用不可の場合には、ディレクトリサーバーに対する問い合わせが行われる。ディレクトリエントリがディレクトリサーバーから取り出されたら、キャッシュに書き込まれ得る。ディレクトリデータサービス１５４は、第１のディレクトリエントリに格納されたメンバーを特定するために第１のディレクトリエントリを読み出し得る。メンバーが特定された場合、ディレクトリデータサービス１５４はそのメンバーのマッピングに現在の対象グループを追加し得る。メンバーのマッピングは、そのメンバーと関連付けられた１つまたはそれ以上のグループおよび／または配布リストを示すフラットなデータ構造であり得る。ディレクトリデータサービス１５４は、第１のディレクトリエントリがさらなるディレクトリエントリ（例えば、現在のディレクトリエントリよりもさらに下の階層レベル）を含むかどうかを判断し得る。ディレクトリデータサービス１５４は、現在の対象グループが別のメンバー（例えば、さらなるディレクトリサービスエントリに格納されたネスト構造のグループは、対象グループにマップされるメンバーを含む）のマッピングに追加されるかどうかを判断するために、第１のディレクトリエントリ（例えばネスト構造のグループ）に格納されたさらなるディレクトリエントリを読み出し得る。ディレクトリデータサービス１５４は、現在の対象グループを対象にさらなる階層状のディレクトリデータサービスレベルがトラバースされるかどうか（例えば、対象グループ下に、下方にトラバースしていくさらなる階層レベルが存在するかどうか）を判断し得る。いくつかの実施形態によれば、ディレクトリデータサービス１５４は、グループメンバーシップマップと関連付けられている特定されたユーザーのリスト、グループメンバーシップマップと関連付けられている特定された配布リストのリスト、および／またはグループメンバーシップマップと関連付けられている特定されたグループのリストをキャッシュし得る。いくつかの実施形態によれば、ポリシーが対象グループに適用され、対象グループに対する１人またはそれ以上のメンバーのマッピングにより、ポリシーを適用することに関わる性能が向上し得る。例えば、ディレクトリサーバー内にある１つまたはそれ以上の対象グループを特定するデータが、アプリケーションから受信され得る。特定された対象グループに対するメンバーの１つまたはそれ以上のマッピングが、ポリシーを適用するためのアプリケーションに提供され得る。

いくつかの実施形態によれば、キャッシュエントリは、グループに対する１人またはそれ以上のユーザーのマッピングを生成するためにディレクトリデータサービスによって、およびディレクトリデータサービスクライアントによって同時に使用され得る。

いくつかの実施形態によれば、グループ、配布リスト、および他のディレクトリエントリは期限が切れ得る。期限切れは、各ディレクトリエントリに割り当てられた別々のランダム値によって判断される期限に基づき得る。ランダム値は、多数の期限切れのエントリが同時にリフレッシュされる必要性が発生してディレクトリサーバーに過剰な負荷がかかる確率を下げるために、ディレクトリエントリの期限を分散し得る。

ディレクトリデータサービス１５４は、例えばディレクトリサーバー１４０（１）などのディレクトリサーバーからキャッシュデータを管理できるようにし得る。ディレクトリデータサービス１５４は、ディレクトリサービスデータのリクエストも管理し得る。データをキャッシュすることにより、メールゲートウェイなどのネットワークデバイスの動作が高速化され得るし、１つまたはそれ以上のディレクトリサーバー１４０からの負担が軽減され得る。ただし、初期キャッシュをビルドすると、負荷が大きくなる可能性がある。１つまたはそれ以上の実施形態によれば、ディレクトリデータサービス１５４は、ネットワークデバイスによって使用される前に、キャッシュされたディレクトリデータを事前に読み込み得る。キャッシュデータは、（例えば、ディレクトリサーバーで行われた可能性のあるディレクトリデータに対する変更を省略するなど）「陳腐化」しないように周期的にリフレッシュされる必要があり得る。多数のキャッシュエントリは、同時に、あるいは同じ短時間内に作成され得る。同じ生存時間（ＴＴＬ）、またはキャッシュエントリの期限切れを決定する他の同様の設定を用いて多数のキャッシュエントリを設定すると、短時間に多数のキャッシュエントリをリフレッシュするために、ディレクトリサーバーに多数のクエリが出される可能性がある。この好ましくない挙動は、ディレクトリサーバーおよび／またはディレクトリサーバーを使用するアプリケーションまたはデバイスにおけるスパイク、性能障害、あるいは他の好ましくない挙動の原因となり得る。

本開示の１つまたはそれ以上の実施形態によれば、同じ時点で多数のキャッシュエントリがディレクトリサーバーにリフレッシュリクエスト（例えば、ＬＤＡＰ対応ディレクトリサーバーに対するＬＤＡＰクエリ）に課せられることのないように、キャッシュエントリの期限（例えばＴＴＬ設定）は多様であり得る。例えば、複数のキャッシュディレクトリエントリの許容期限の範囲を決定する１つまたはそれ以上のパラメータが、管理者によって設定され得る。ディレクトリデータサービス１５４は、ユーザーインターフェースを提供し得るし、かつ／または設定されたパラメータを受容し得る。ディレクトリデータサービスからキャッシュディレクトリエントリが作成されると、そのエントリは、ディレクトリデータサービス１５４によって作成時刻が割り当てられ得る。キャッシュディレクトリエントリは、ディレクトリデータサービス１５４によって１つまたはそれ以上のランダム値が割り当てられ得る。１つまたはそれ以上のランダム値は、キャッシュディレクトリエントリの期限（例えば生存時間（ＴＴＬ）を期限の許容範囲内で決定し得る。複数のキャッシュディレクトリエントリの許容期限の範囲内でキャッシュディレクトリエントリの期限をランダム化することにより、ある時点でネットワークデバイス１７０のキャッシュメモリとディレクトリサーバー１４０との間で必要とされる同期の量（例えばリフレッシュリクエスト）が減少し得る。そのため、キャッシュエントリは、ディレクトリサーバーでパフォーマンススパイクまたは他の性能低下が起こらないように、ＴＴＬ設定を、許容される生存時間設定の範囲全体に分散させ得る。

キャッシュエントリの期限が切れている場合には、ディレクトリデータサービス１５４が、ディレクトリサーバーに問い合わせること（例えば、ＬＤＡＰ対応ディレクトリサーバーに対するＬＤＡＰクエリ）によってキャッシュエントリのリフレッシュを試行し得る。キャッシュエントリは、キャッシュで受信され、新たに設定された作成時刻と新たに計算されたＴＴＬとを用いて更新または作成され得る。

いくつかの実施形態によれば、ディレクトリデータサービスが利用不可である場合には、期限切れの対応ディレクトリエントリがリクエストを受けて提供され得る。ディレクトリサーバーが別のディレクトリサーバー（例えば、同じキャッシュエントリを含むディレクトリサーバー）に対して冗長である場合には、ディレクトリサーバーに対するクエリが第１のサーバーから第２のサーバーにフェイルオーバーされ得る。例えば、冗長ディレクトリサーバーにフェイルオーバーするには、ラウンドロビンＤＮＳ（ドメイン名サーバー）方式が使用され得る。いくつかの実施形態によれば、ロードバランシングおよび／またはフェイルオーバーは、ディレクトリサーバー（例えばＬＤＡＰ）ティアで実施され得る。１つまたはそれ以上の実施形態によれば、データアクセスの失敗（例えば、ネットワークの問題や、ディレクトリサーバーの停止）が発生したときに、ディレクトリデータサービス１５４は、キャッシュデータのＴＴＬの期限が切れていても、キャッシュが利用可能であれば、キャッシュからのデータで以てリクエストにサービスする。このため、サイズ限度を超えない限り、データソースキャッシュからデータが削除されることはない。例えば、いくつかのデータアクセスの失敗が短時間で検出された場合に開始し得る高速フェイルオーバーモードが存在し得る。これにより、データソースは、キャッシュデータが利用可能であれば、そのキャッシュデータに対して直ちにサービスを直ちに提供しうるか、あるいは例外（例えばＤａｔａＡｃｃｅｓｓＵｎａｖａｉｌａｂｌｅＥｘｃｅｐｔｉｏｎ）を伴って直ちに失敗し得る。これにより、ディレクトリデータサービス１５４は、ディレクトリサーバーのリソースが利用できない場合でも高スループットを維持することができ得る。一実施形態によれば、ディレクトリデータサービス１５４の高速フェイルオーバー構成は、以下のように実装され得る。

データアクセスの失敗が１２０秒間で５回検出されたら、３００秒間の高速フェイルオーバーに切り替わる。特定のリクエストについて、フェイルオーバー先のキャッシュデータが存在しない場合、ディレクトリデータサービス（ＤＤＳ）コールが一時エラーで失敗し得る。受信者の妥当性検証の場合、かかる一時エラーはＳＭＴＰエラーとなる可能性があり、上流の送信者にそのメッセージを再試行するように命令し得る。他の機能の場合、これらのエラーにより、メッセージが各種内部ＭＴＡ（メッセージトランスファーエージェント）キューに残る可能性があり、そこで再試行され得る。

いくつかの実施形態によれば、キャッシュデータは、冗長ディレクトリデータソースに優先し得る。ディレクトリデータソースとキャッシュとの間での優先順位は設定可能であってよい。例えば、ＳｏｕｒｃｅＡおよびＳｏｕｒｃｅＢという２つの同一の受信者妥当性検証ソースを用いてシステムが構成された場合を考えてみる。ここではＳｏｕｒｃｅＡがクエリ順序における最初のソースである。通常の状況下では、有効な受信者に対してＳｏｕｒｃｅＡだけが問い合わせられ得る。通常の状況下では、無効な受信者に対して両方のソースが問い合わせられ得る。ＳｏｕｒｃｅＡが停止している場合には、キャッシュされた有効な受信者に対してＳｏｕｒｃｅＡのキャッシュからサービスされ得るため、ＳｏｕｒｃｅＢが参照されない場合がある。ＳｏｕｒｃｅＡが停止している場合、キャッシュされていない有効な受信者はＳｏｕｒｃｅＢからサービスされ得る。スティッキーリフレッシュにより、キャッシュされていない有効な受信者はその後もＳｏｕｒｃｅＢからサービスされ得る。ＳｏｕｒｃｅＡが停止している場合、キャッシュされているが期限が切れていない無効な受信者は、通常の状況下と同様に扱われ得る。ＳｏｕｒｃｅＡが停止している場合、キャッシュされた無効な受信者、あるいはキャッシュされているが期限が切れている無効な受信者は、リクエスタに後で再試行するように命令するエラーをもたらし得る。

いくつかの実施形態によれば、ＳｏｕｒｃｅＢが停止している場合には、キャッシュされた有効な受信者がＳｏｕｒｃｅＡのキャッシュからサービスされ得るため、ＳｏｕｒｃｅＢが参照されない場合がある。ＳｏｕｒｃｅＢが停止している場合、キャッシュされていない有効な受信者はＳｏｕｒｃｅＡからサービスされ得る。早期終了およびスティッキーリフレッシュにより、キャッシュされていない有効な受信者はその後もＳｏｕｒｃｅＡからサービスを提供され得る。早期終了とは、検索結果の一意性を検証することなく、複数のデータソースを用いて構成されたディレクトリデータサービスに対する検索を終了することであり得る（例えば、受信者の妥当性検証の場合、リクエストされたディレクトリエントリが見つかる最初のデータソースで検索が停止し得る）。スティッキーリフレッシュとは、キャッシュ内のディレクトリエントリが特定のデータソースと関連付けられており、ディレクトリエントリの期限が切れたときに、ディレクトリデータサービスが、そのデータソースからのディレクトリエントリのリフレッシュを試行するように定義された設定のことであり得る（例えば、ディレクトリエントリが同じデータソースからリフレッシュされ得る限り、システム内の他のデータソースは問い合わせられない）。ＳｏｕｒｃｅＢが停止している場合、キャッシュされているが期限が切れていない無効な受信者は、通常の状況下と同様に扱われ得る。

ＳｏｕｒｃｅＢが停止している場合、キャッシュされた無効な受信者、あるいはキャッシュされているが期限が切れている無効な受信者は、リクエスタに後で再試行するように命じるエラーをもたらし得る。

いくつかの実施形態によれば、冗長ソースはサポートされなくてもよい。ディレクトリデータソースが停止していても、利用可能であれば、キャッシュデータにフェイルオーバーし得る。使用するキャッシュデータが存在しない場合、ソースはデータアクセスエラーを記録し得る。そしてディレクトリデータサービス１５４はデータアクセスアラートを生成し得る。ただし、ディレクトリデータサービス１５４は、引き続き他のデータソースを検索してもよい。一意のエントリが健全なソースのうちの１つに見つかれば、そのコールは成功する可能性があり、スティッキーリフレッシュは、そのエントリを求める以降の要求をそのソースに向け得る。１つより多くのエントリが見つかった場合には、重複エラーが記録され得る。そして、ディレクトリデータサービス１５４は、データ整合アラートを生成し得る。一致するエントリが見つからない場合には、リクエストが一時エラーで失敗し、再試行され得る。

いくつかの実施形態によれば、ディレクトリデータサービス１５４は、１つまたはそれ以上のデータ整合エラーまたは他のエラーを検出し得る。そして、そのエラーと関連付けられた記録および／またはアラート通知を提供し得る。例えば、ディレクトリデータサービス１５４は、処理中にデータエラーに遭遇し得る。そしてエラーを記録し、かつ／またはアラートを管理者に提供し得る。検出されたエラーは、非制限的な例として、電子メールアドレスの重複、ユーザー名重複、行方不明または無効な属性データ（例えば、行方不明の電子メールアドレス、無効な電子メールアドレスフォーマット、存在しないエントリを参照しているグループメンバーシップ属性、および下位および上位グループメンバーシップ属性の不整合値）、および循環グループ関係を含み得る。ディレクトリデータサービス１５４は、各種ディレクトリデータと統合し得る。例えば、ディレクトリデータサービス１５４は、ＬＤＡＰディレクトリ、ＳＱＬデータベース、および／またはフラットファイルを格納しているサーバーであり得るディレクトリサーバー１４０（１）．．．（Ｎ）にアクセスし得る。ディレクトリデータサービス１５４は、電子メールアドレスまたは他のデータを探すディレクトリサーバー（例えばＬＤＡＰクエリ）にアクセスし得る。受信したデータに基づいて、ディレクトリデータサービス１５４はデータ整合エラーを検出し得る。受信した電子メールアドレスが単一のデータソースにおける複数のディレクトリエントリに対応し得るか、あるいはユーザー名が単一のデータソースにおける複数のディレクトリエントリに対応し得る。いくつかの実施形態によれば、データ整合エラーに加え、ディレクトリデータサービス１５４によって認識される他のエラーとしては、ディレクトリデータアクセスエラー（例えば、ＬＤＡＰサーバーからデータを読み出せなかった）、過小データソースキャッシュエラー（例えば、データソースキャッシュまたはキャッシュインデックスが、リクエストされたメモリ内データまたはフェッチされたディレクトリエントリのすべてを保持できるだけの大きさがないことを示している）、および／または（エンドユーザー設定複製エラー（エンドユーザー設定複製動作が失敗したことを示している）を含むエラーを扱い得る。

ディレクトリデータサービス１５４は、サービスの無応答または非稼働、不適切なシャットダウン後のサービス開始、サービスのシャットダウン、およびサービス開始を含むイベントのアラートを提供し得る。これらのアラートに加え、ディレクトリデータサービス１５４は、ディレクトリデータサービス（ＤＤＳ）に固有のアラートを扱い得る。ディレクトリデータサービス１５４は、ディレクトリサーバーデータアクセスアラートを提供し得る。このタイプのアラートは、ディレクトリデータサービス１５４がディレクトリサーバー（例えばＬＤＡＰサーバー）からデータを読み出せない場合にトリガーされ得る。これは、様々な理由で起こり得る。いくつかの例は、ＬＤＡＰサーバーの停止、ネットワークインフラストラクチャの問題、ＤＮＳの問題、ファイアウォールルールのブロックリクエスト、不良データソース管理バインド証明書、および／またはＬＤＡＰ検索タイムアウトを含み得る。

ディレクトリデータサービス１５４によって扱われる他のアラートは、ディレクトリサーバーデータ整合アラートを含み得る。このタイプのアラートは、リクエストが正常に実行されるのを妨げるディレクトリデータに関する問題をディレクトリデータサービス１５４が検出したときにトリガーされ得る。リクエストの失敗に至らないデータ整合の問題は、ディレクトリデータサービス１５４によって「警告」レベルで記録され得るため、アラートをトリガーしない場合がある。ディレクトリデータサービス１５４は、受信者の妥当性検証エラーを記録し得る。受信者アドレスでの検索に対して複数のエントリ（単一のデータソース内に、あるいは複数のソースにまたがって存在）が返された場合、このイベントは、ディレクトリデータサービス１５４によって「情報」レベルで記録され得るため、アラートが生成されない場合がある。複製された受信者は、受信者の妥当性検証機能上、有効であるとみなされ得る。
以下のデータ整合エラーは、アラートをトリガーし得る。

電子メールアドレス（単一のデータソース内に、あるいは複数のソースにまたがって存在）での検索に対して１つより多くのエントリが返される。

ユーザー名（単一のデータソース内に、あるいは複数のソースにまたがって存在）での検索に対して１つより多くのエントリが返される。

以下のデータ整合問題は、ディレクトリデータサービス１５４によって「警告」レベルで記録され得るため、アラートをトリガーしない場合がある。循環グループ参照、無効なグループメンバーシップ属性値、行方不明のプライマリ電子メール属性値、および／または電子メールアドレス値の無効フォーマット。

循環グループ参照は、ディレクトリサーバーがグループメンバーシップを判断するために上から下へとトラバースしているときにディレクトリデータサービス１５４によって認識され得る。例えば、グループＡがグループＢのメンバーであり、グループＢがグループＡのメンバーである場合に、ディレクトリデータサービス１５４がこれを検出してエラーを記録し得る。グループの関係は、多数のレベルに及び深いネスト構造になっていることがあるために、循環グループ参照がいくつか下のレベルで発生し得る。例えば、グループが上位から下位にＡ〜Ｅのネスト構造になっていると仮定すると、グループＢがグループＥのメンバーである可能性があり、循環グループ参照をもたらし得る。いくつかの実施形態によれば、ツリー（すなわちグループ）の特定ノードが以前にアクセスされていると判断し得る再帰的ツリートラバースアルゴリズムが使用され得る。これが循環グループ参照を表し得る。循環グループ参照は、データソース（例えば単一のディレクトリサーバー）で、あるいはデータソースにまたがって検出され得る。

ディレクトリデータサービス１５４は、ディレクトリデータサービス（ＤＤＳ）キャッシュサイズアラートを提供し得る。このタイプのアラートは、ディレクトリデータサービス１５４が、データアクセス層から取り出された新規エントリ用のスペースを確保するために、期限が切れる前にキャッシュエントリを追い出すときにトリガーされ得る。管理者は、アラートおよびログステートメントを参照して適切な措置をとり得る。例示的なアラートは以下を含む。

Ｅｎｔｒｙ Ｃａｃｈｅ

修復方法：キャッシュサイズを増やす。

Ｒｅｃｉｐｉｅｎｔ Ｒｅｆ Ｃａｃｈｅ（電子メールアドレスに関するキャッシュインデックス）

修復方法：キャッシュインデックスサイズ乗数（すなわち、キャッシュインデックスサイズ＝（Ｎ×キャッシュサイズ）と設定するパラメータＮなど、キャッシュインデックスのサイズを決定するパラメータ）を増やす。

Ｕｓｅｒ Ｒｅｆ Ｃａｃｈｅ（ユーザー名に関するキャッシュインデックス）

修復方法：キャッシュインデックスサイズ乗数を増やす。

アラートファイルが、ホスト、特定タイプのアラート条件、およびトリガー事象の時期を伝達し得る。アラートテキストは、管理者に、システムログファイルを参照して追加診断情報を確認するよう促し得る。これにより、影響を抑えつつ、アラート機能の変更または拡張が可能となり得る。

生成されたアラート電子メールは、以下の情報を含み得る。

アラートイベントのタイムスタンプ、

アラートイベントのホスト識別子、

アラートイベント（例えばディレクトリデータサービス１５４）を生成した構成要素、および

所定のディレクトリデータサービスステータスコードに対応するローカライズされたメッセージ。

ステータスコードは大雑把である可能性があり、特定のコードに至る可能性のある多数の潜在的なエラー状況が存在し得る。アラートメカニズムは、特定ホスト上のディレクトリデータサービスインスタンスが特定時期にリクエストを処理できなかったことを単に伝えるだけであり得る。そして根本原因についての詳細な情報はログを参照するように管理者に示し得る。

ディレクトリデータアクセスアラート、ディレクトリデータ整合アラート、ディレクトリデータサービスキャッシュサイズアラート、ユーザー設定複製アラート、または他のタイプのアラートのうちの１つまたはそれ以上のサブタイプを使用可能または使用不可にするためのユーザーインターフェース要素（例えばチェックボックス）が存在してもよい。

ディレクトリデータサービス１５４は、１つまたはそれ以上のデータ整合エラーまたは他のエラーを記録し得る。そしてアラートが別のメカニズムによって生成され得る。例えば、ディレクトリデータサービス１５４は、ディスク上、あるいは他の電子ストレージにアラートファイルを作成する。アラートファイルは、タイムスタンプと、アラート条件のタイプを表す識別子とを格納し得る。ネットワークデバイス１７０上で実行中のプロセスまたはエージェントが、周期的にアラートファイルをポーリングし、アラートメタデータを処理し、１人またはそれ以上のユーザー（例えば、登録されたシステム管理者）にアラート電子メールを送り得る。他の通信チャネルが、ＳＭＳテキストメッセージ、ボイスメール、および／またはウェブページ投稿などをユーザーに通知する目的で使用され得る。いくつかの実施形態によれば、ディレクトリデータサービス１５４は、追加プロセスまたはエージェントを使用せずに直接アラートを送り得る。１つまたはそれ以上の実施形態によれば、ディレクトリデータサービス１５４または別のプロセスが、インターフェースを使用して（例えば、ＳＮＭＰ、Ｗｉｎｄｏｗｓ Ｓｙｓｔｅｍ Ｅｖｅｎｔ、またはカスタムＩＰＣ（プロセス間通信）を介して）アラートを送り得る。

ディレクトリデータサービス１５４によるデータ整合エラーの検出およびシステム管理者への迅速なアラート通知により、システムの性能低下または故障が起きる前にシステム管理者が問題に対処することを可能にし得る。

いくつかの実施形態によれば、ディレクトリデータサービスグループの解決が、１つまたはそれ以上のアプリケーション機能を支援するために実行され得る。例えば、メールゲートウェイが、どのポリシーをユーザーに適用するかを判断するために、１つまたはそれ以上の対象グループのメンバーシップを判断する必要があり得る。すべてのグループを解決しようとすると、ディレクトリサーバーに不要かつ重い負担がかかり得る。例えば、例示的実施形態によれば、メールゲートウェイは、ポリシーグループメンバーシップ（例えば、ｂｍｉｃｏｎｆｉｇ．ｘｍｌなど構成可能なリストに記憶されたポリシーグループメンバーシップ）と交差するグループメンバーシップを解決することのみ必要であり得る。いくつかの実施形態によれば、実行時のグループメンバーシップ拡張は、配布リストの下位メンバーシップに限られ得る（配布拡張が有効である場合）。配布リストの下方拡張および構成可能なリスト（例えばｂｍｉｃｏｎｆｉｇ．ｘｍｌ）にポリシーグループのメンバーとして含まれるグループは、ディレクトリデータサービスクライアントからアドレス解決コールを受け入れる前に実行され得る。上位メンバーシップの「上方」拡張が実行されることはない。これは、以下に示すいくつかの利点を提供し得る。

ｍｅｍｂｅｒＯｆ属性を欠くディレクトリタイプだけでなく、すべてのディレクトリタイプに関するアドレス解決速度の大幅な向上。

配布リストの拡張だけでなく、ユーザーメンバーシップ解決速度の向上。

キャッシュされた配布リストの拡張速度の明らかな向上。

キャッシュされたｄｌｉｓｔおよびグループの数をポリシーで参照されたｄｌｉｓｔおよびグループまで減らすこと、および／またはメッセージを受信することによるメモリオーバーヘッドの大幅な減少。

ポリシーグループメンバーシップを解決するのに、数秒から数分かかり得る。下方のみの拡張モデルは、配布リストの拡張速度を数倍上げ得るが、すべてのｄｌｉｓｔおよびグループを解決してキャッシュを埋めるのに、それでもまだいくらかの時間を要し得る。この間に、アドレス解決コールがキューに入り得る。

解決されたｄｌｉｓｔおよびグループのキャッシュ期限は、最小限のＴＴＬに基づいてスレッドによってリフレッシュされ得る。ｂｍｉｃｏｎｆｉｇ．ｘｍｌポリシーグループメンバーシップへの追加または編集、あるいはディレクトリデータソースの構成変更は、グループの再解決をトリガーし得る。

下方メンバーシップ拡張アルゴリズムは、／ｄａｔａ／ｓｃａｎｎｅｒ／ｅｔｃ／ｂｍｉｃｏｎｆｉｇ．ｘｍｌに列記されたポリシーメンバーシップから取得される電子メールアドレスおよびＬＤＡＰグループ識別名（ＤＮ）のリストから開始され得る。各々のＬＤＡＰグループＤＮは、グループのリストに追加され得る。完全形成された電子メールアドレス（ローカル部＠ｄｏｍａｉｎ．ｃｏｍ）ごとに、ＥｎｔｒｙＤＡＯを使用して、電子メールアドレスがｄｌｉｓｔに対応するかどうかを判断し、対応する場合には、そのアドレスを、拡張されるグループのリストに追加し得る。他のポリシーメンバーシップ形態（例えば、ドメインのみ、ファイルグロブパターン）はスキップされ得る。

ディレクトリエントリが配布リストまたは電子メールのないＬＤＡＰグループであるかどうかに関係なく、次のステップは同じであり得る。
拡張されるグループごとに、

グループエントリをＬＤＡＰサーバーから取り出す

キャッシュエントリ（ＤＮ、プライマリ／エイリアス電子メールアドレスおよび／または下位メンバーシップ）

下位メンバーごとに

ｂｍｉｃｏｎｆｉｇから取得したオリジナルのグループを、下位メンバーの上位メンバーシップに追加する
下位メンバーを再帰的に拡張する
なお、グループのメンバーが、以前に解決されたグループによってすでにキャッシュされている場合、上位メンバーシップは、置換ではなく追加され、キャッシュエントリは維持され得る。また、すでに確認したノードに遭遇すると、循環グループメンバーシップを扱うための論理が拡張を停止し得る。
例えば、ＬＤＡＰサーバーに以下のエントリを有する場合、

そしてｂｍｉｃｏｎｆｉｇ．ｘｍｌに列記された２つのポリシーメンバーシップが以下である場合、

ｄｌｉｓｔ．２＠ｂｒｉｇｈｔｍａｉｌ．ｃｏｍ

ｃｎ＝ｇｒｏｕｐ．１，ｄｃ＝ｂｒｉｇｈｔｍａｉｌ，ｄｃ＝ｃｏｍ
下方へのメンバーシップ解決タスクの完了時に、ディレクトリデータサービスキャッシュに以下のエントリを有することになる。

例えば、グループまたは配布が、下位メンバーのＤＮがソースのベースＤＮ外にある下位メンバーシップを格納している場合、メンバーシップは、それでもトラバースおよびキャッシュされ得る。
メンバーシップキャッシュのデザイン

１つまたはそれ以上のエントリタイプ（ユーザー、配布リスト、グループ）の上位メンバーシップ情報は、別々のマップバックドキャッシュに分けられ得る。これらのキャッシュにおいて、キーはエントリのｕｎｉｑｕｅＩｄであり、値は、そのエントリがメンバーであるグループおよびｄｌｉｓｔのｕｎｉｑｕｅＩｄのリストである。

キャッシュからエントリを解決するには、以下に示す新しいステップが必要となり得る。ｕｎｉｑｕｅＩｄがメインキャッシュで存在することが判明している場合には、マップバックドメンバーシップキャッシュに対して２度目のルックアップが実行され得る。ｕｎｉｑｕｅＩｄのキーが存在しない場合には、そのエントリについて、レポートする上位グループメンバーシップが存在しない場合がある。

なお、ディレクトリデータサービスクライアントに対する対象上位メンバーシップを有するエントリは、下方メンバーシップ拡張タスクの完了後にキャッシュされ得る。メインキャッシュ内の各エントリは、自身の生存時間（ＴＴＬ）を有し得る一方で、メンバーシップマップ全体は、単一のＴＴＬを有するとみなされ、このＴＴＬは、データソースの最小範囲のＴＴＬに設定され得る。その結果、ディレクトリデータサービスクライアントのアドレス解決リクエストにサービスするにあたってアドレス解決エントリがフェッチされたときに、以下の使用事例に遭遇し得る。

エントリがまだキャッシュされていなかった。そのため、エントリは上位メンバーシップを有していない可能性があり、ＬＤＡＰサーバーは、電子メールアドレスおよび下位メンバーシップの有無だけが問い合わせられ得る。

エントリはキャッシュされており、上位メンバーシップを有する場合もあれば有しない場合もある。

エントリはキャッシュされているが、エントリのＴＴＬの期限が切れているために、ＬＤＡＰサーバーは、電子メールアドレスおよび下位メンバーシップの有無だけが問い合わせられ、キャッシュエントリが置換され得る。エントリが上位メンバーシップを有する場合には、ｕｎｉｑｕｅＩｄ（ＤＮ）によって再リンクされ得る。
メンバーシップキャッシュの再ビルドタスク

ディレクトリデータサービスサーバーが初めて開始されたか、あるいはサーバーが再起動されたとき、キャッシュの持続性が有効でない場合には、メンバーシップマップ全体が所与のソース用に再ビルドされ得る。

ディレクトリデータサービスサーバーがｋｉｃｋコマンドを受信し、ｂｍｉｃｏｎｆｉｇ．ｘｍｌファイルがポリシーメンバーシップリストに対する変更を格納している場合には、メンバーシップマップ全体が所与のソース用に再ビルドされ得る。

ディレクトリデータサービスサーバーがｋｉｃｋコマンドを受信し、ｄｄｓｃｏｎｆｉｇ．ｘｍｌファイルが、そのソースのキャッシュを再ビルドする必要があるデータソースに対する変更を格納している場合には、メンバーシップマップ全体が、所与のソース用に再ビルドされ得る。

メンバーシップマップのＴＴＬの期限が切れたら、ＬＤＡＰサーバーディレクトリツリーにおけるグループメンバーの追加および削除を捕捉するために、メンバーシップマップ全体が所与のソース用に再ビルドされ得る。

ディレクトリデータサービスサーバーは、メンバーシップマップが再ビルドされている間、アドレス解決コールをブロックし得る。該当ソースについて、メンバーシップマップビルドタスクの進行中にｋｉｃｋまたはｃｌｅａｒ ｃａｃｈｅコマンドが受信された場合には、タスクが破棄され、ｋｉｃｋコマンドが処理され得る。

再ビルドタスクは、古いコピーの保持中に新しいメンバーシップマップをビルドし得る。それにより、マップの再ビルド中にアドレス解決コールが引き続きサービスされ得る。そして失敗した場合には古いコピーに戻り得る。つまり、再ビルド中、メンバーシップマップは、単一マップの２倍のメモリ消費量でピークに達し得るということであり、かつ、利用可能な古いマップが存在する場合にアドレス解決コールがキューに入っている実時間は、通常のディレクトリデータサービスのｋｉｃｋの場合より、ほんのわずかに長いだけであり得るということである。

メンバーシップマップのＴＴＬの期限が切れたときに再ビルドに対応するために、アドレス解決ソースごとに、スケジューリングされたタスクが存在し、そのソースの低い方のＴＴＬ範囲値に設定された間隔で動作し得る。メンバーシップマップのＴＴＬの期限が切れると、再ビルドタスクが呼び出され得る。下方拡張によって参照されたエントリがすでにキャッシュされている場合には、そのエントリのＴＴＬが検査され得る。期限が切れている場合には、そのエントリおよびそのエントリの下位メンバーシップデータがデータアクセス層からフェッチされ、新たにキャッシュされ得る。期限が切れていない場合には、古いエントリは保持され、そのエントリの下位メンバーシップデータが新しいマップで表され得る。メンバーシップマップデータは、最大ＴＴＬ範囲よりも長く持続し得る。例えば、最小ＴＴＬ範囲が１時間、最大が５．５時間に設定されている場合、メンバーシップマップは、特定のエントリの期限が切れるまでに最大６回サイビルドされ得る。そのため、そのエントリの下位メンバーシップデータは、６時間にわたってキャッシュされた状態であり得る。

再ビルドタスクは、ｂｍｉｃｏｎｆｉｇ．ｘｍｌからグループのリストおよびｄｌｉｓｔを並行して処理するために、スレッドのプールを使用し得る。追加、置換、および追い出しを受けてキャッシュ統計が更新され得る。
メンバーシップキャッシュの再ビルド中のディレクトリデータサービスＡＰＩの挙動は以下のとおり。

何らかのアドレス解決ソースのメンバーシップマップの再ビルド中は、ディレクトリデータサービスサーバーが、クライアントアドレス解決コールにサービスしたり、重複するｋｉｃｋを呼び出したりしないようにされ得る。なお、アドレス解決メンバーシップキャッシュの再ビルド中は、他のディレクトリデータサービスコール（例えば、受信者の妥当性検証）が実行され得る。

新しいメンバーシップキャッシュがビルドされており、かつ旧マップが存在する場合には、アドレス解決コールが依然としてディレクトリデータサービスによってサービスされ得る。旧メンバーシップマップが存在しない場合には、アドレス解決コールがキューに入り、最初のマップをビルドするために必要な時間の存在により、アドレス解決コールがキューに入り得る（例えば、ｂｍｉｃｏｎｆｉｇ．ｘｍｌおよび／または反応の遅いＬＤＡＰサーバーにある多数の大きなグループ）。

ｋｉｃｋまたはｃｌｅａｒ ｃａｃｈｅコマンドがメンバーシップマップのビルド中に受信された場合には、ビルドが破棄され得る。そして、ｃｌｅａｒ ｃａｃｈｅコマンドがサービスされて、必要に応じてメンバーシップマップのビルドが再開され得る。「古い」ｂｍｉｃｏｎｆｉｇ．ｘｍｌおよびｄｄｓｃｏｎｆｉｇ．ｘｍｌは、メンバーシップが再ビルドされる必要があるかどうかが継続的に判断され得る。そして、「古い」マップのＴＴＬが検査され、期限切れになっているかどうかを判断する。ソースでのｃｌｅａｒ ｃａｃｈｅにより、そのソースのメンバーシップマップが再ビルドされ得る。これは、メンバーシップマップの再ビルドが進行中である場合（初回ビルドの場合、あるいは以前に存在していたマップを伴う場合）に対処し、

以下を受けてｋｉｃｋが受信される。

ｄｄｓｃｏｎｆｉｇ．ｘｍｌに対する変更（ソースの追加／編集／削除、キャッシュの持続性の変更、ディレクトリデータサービスのログレベルの変更）

ｂｍｉｃｏｎｆｉｇ．ｘｍｌに対する変更（ＬＤＡＰポリシーメンバーシップの追加／削除）

ｕｓｅｒｐｒｅｆｓ．ｘｍｌの複製
メンバーシップマップがビルドされているソースについて、「Ｃｌｅａｒ Ｃａｃｈｅ」が呼び出され得る。

電子メールアドレスによって参照される配布リストポリシーメンバー
データソースのメンバーシップマップに入れるために、ポリシーメンバーの電子メールアドレスが、データソースアドレス解決クエリによって解決可能であり得る。そのため、このアドレスは、ベースＤＮの範囲内に存在し得ると共に、クエリフィルタを使用して検索可能であり得る。

配布リストがそのＬＤＡＰエントリの識別名（ＤＮ）を使用しているポリシーにリストされている場合、メンバーシップは、エントリがデータソース（例えば、ソースのベースＤＮがｏｕ＝Ａｍｅｒｉｃａｓ，ｄｃ＝ｃｏｍｐａｎｙ，ｄｃ＝ｃｏｍ、配布リストのＤＮがｃｎ＝ａｌｌ−ｓａｌｅｓ−ｄｌｉｓｔ，ｏｕ＝ｇｒｏｕｐｓ，ｄｃ＝ｃｏｍｐａｎｙ，ｄｃ＝ｃｏｍ）の範囲外であっても評価され得る。これは、エントリが自身のＤＮを使用して取り出されるときに、エントリのＤＮが、検索フィルタとして「（ｏｂｊｅｃｔｃｌａｓｓ＝＊」を有する「範囲ベース」検索のために、ＬＤＡＰクエリ内のＤＮに取って代わるからである。

キャッシュの追い出し、サイズ、無効化の効果
ソースのキャッシュが小さくて満杯の状態で新規エントリのキャッシュが試行されると、最低使用頻度（ＬＲＵ）アルゴリズムに基づいてエントリが追い出され得る。メンバーシップキャッシュマップのサイズは無制限であり得るが、下方拡張タスクの最中にキャッシュ制限に達する可能性があり得る（例えば、キャッシュ制限は１０，０００であり、ｂｍｉｃｏｎｆｉｇ．ｘｍｌでグループによって参照されるエントリの総数が１２，０００である）。ｃｏｍ．ｓｙｍａｎｔｅｃ．ｓｍｓ．ｄｄｓ．ｃａｃｈｅ．ＬＲＵＨａｓｈＭａｐの定期的な追い出しが許容されているが、メンバーシップマップは別々であり、かつ無制限であることから、下方拡張の機能は維持され得る。

ソースのメインキャッシュが無効である（あるいはゼロサイズに設定されている）場合でも、メンバーシップキャッシュはデータを受容し得るし、最小ＴＴＬ設定は、スケジューリングされたメンバーシップキャッシュの再ビルドを引き続き司り得る。

期限の切れたキャッシュデータへのフェイルオーバー動作
制限の切れたキャッシュデータへのフェイルオーバーは、ＬＤＡＰサーバーがアクセス不可である場合に発生し得る。

下方へのメンバーシップキャッシュの再ビルドの際に、時期を問わずＬＤＡＰソースがアクセス不可である場合には、旧メンバーシップマップに失敗して戻り、データアクセスアラートを発し、３０秒間隔で再試行してもよい。復帰先の旧マップが存在しない（すなわち、ソースの構成に対する変更、あるいはキャッシュクリアコマンドのために、マップが初回のソース保存に基づいてビルドされている）場合には、アドレス解決コールがキューに入り得る。

ｂｍｉｃｏｎｆｉｇ．ｘｍｌにリストされたｄｌｉｓｔまたはグループがＬＤＡＰサーバーに視認できない場合（例えば、問い合わせは正常に行われたものの、エントリの削除または移動、あるいはアクセス制御の変更により、結果がｎｕｌｌだった場合）には、旧マップへのフェイルオーバーが行われない場合があるが、「ＩＮＦＯ」レベルで記録して、見つからないソースおよびグループ名前を列記し得る。

キャッシュの持続性
メンバーシップマップバックドキャッシュは、キャッシュの持続性ブールの設定に従い、他のキャッシュデータと共にディスクに保持され得る。

図２は、本開示の一実施形態にかかるコンピュータシステム２００のブロック図を表す。コンピュータシステム２００は、本開示にかかる技法を実施するのに適している。コンピュータシステム２００は、中央プロセッサ２１４など、コンピュータシステム２１０の主要サブシステムを相互接続し得るバス２１２と、システムメモリ２１７（例えば、ＲＡＭ（ランダムアクセスメモリ）、ＲＯＭ（読み出し専用メモリ、フラッシュＲＡＭなど）と、入出力（Ｉ／Ｏ）コントローラ２１８と、音声出力インターフェース２２２を介するスピーカシステム２２０などの外部のオーディオデバイスと、ディスプレイアダプタ２２６を介するディスプレイスクリーン２２４などの外部デバイスと、シリアルポート２２８および２３０と、キーボード２３２（キーボードコントローラ２３３を介して仲介）と、記憶装置インターフェース２３４と、フロッピーディスク２３８を受容するように動作可能なフロッピーディスクドライブ２３７と、ファイバチャネルネットワーク２９０と接続するように動作可能なホストバスアダプタ（ＨＢＡ）インターフェースカード２３５Ａと、ＳＣＳＩバス２３９に接続するように動作可能なホストバスアダプタ（ＨＢＡ）インターフェースカード２３５Ｂと、光学ディスク２４２を受容するように動作可能な光学ディスクドライブ２４０と、を備え得る。また、マウス２４６（または他のポイントアンドクリックデバイス、シリアルポート２２８を介してバス２１２に連結）と、モデム２４７（シリアルポート２３０を介してバス２１２に連結）と、ネットワークインターフェース２４８（バス２１２に直接連結）と、電源マネージャ２５０と、バッテリ２５２と、も備え得る。

バス２１２は、上記のとおり、中央プロセッサ２１４とシステムメモリ２１７との間でのデータ通信を可能にする。システムメモリ２１７は、読み出し専用メモリ（ＲＯＭ）またはフラッシュメモリ（どちらも図示せず）と、ランダムアクセスメモリ（ＲＡＭ）（図示せず）とを含み得る。ＲＡＭは、オペレーティングシステムおよびアプリケーションプログラムが読み込まれ得るメインメモリであり得る。ＲＯＭまたはフラッシュメモリは、他のコードと共に、周辺構成要素との相互動作など、基本的なハードウェア動作を制御する基本入出力システム（ＢＩＯＳ）を格納することができる。コンピュータシステム２１０に存在するアプリケーションは、ハードディスクドライブ（例えば固定ディスク２４４）、光学ドライブ（例えば光学ドライブ２４０）、フロッピーディスクユニット２３７、または他の記憶媒体など、コンピュータ読み取り可能な媒体に記憶され、かかる媒体を介してアクセスされ得る。例えば、ディレクトリデータサービス１５４は、システムメモリ２１７に存在し得る。

記憶装置インターフェース２３４は、コンピュータシステム２１０の他の記憶装置インターフェースと同様、固定ディスクドライブ２４４など、情報を記憶および／または取得するための標準的なコンピュータ読み取り可能な媒体に接続することができる。固定ディスクドライブ２４４は、コンピュータシステム２１０の一部であってよく、あるいは別々になっており、他のインターフェースシステムを通じてアクセスされるようになっていてもよい。モデム２４７は、電話リンク経由でリモートサーバーとの、あるいはインターネットサービスプロバイダ（ＩＳＰ）経由でインターネットとの直接接続を提供し得る。ネットワークインターフェース２４８は、ＰＯＰ（通信アクセスポイント）を経由するインターネットとの直接ネットワークリンクを介してリモートサーバーとの直接接続を提供し得る。ネットワークインターフェース２４８は、デジタルセルラー方式電話接続、セルラー方式デジタルパケットデータ（ＣＤＰＤ）接続、デジタル衛星データ接続などを含む無線技法を用いてかかる接続を提供してもよい。

その他多くの装置またはサブシステム（明示せず）が、同様の方法（例えば、文書スキャナ、デジタルカメラなど）で接続されてもよい。逆に言えば、本開示を実施するのに、図２に示す装置のすべてが存在する必要はない。これらの装置およびサブシステムは、図２に示すものとは別の方法で相互接続することもできる。本開示を実装するコードは、システムメモリ２１７、固定ディスク２４４、光学ディスク２４２、またはフロッピーディスク２３８のうちの１つまたはそれ以上などのコンピュータ読み取り可能な記憶媒体に記憶され得る。本開示を実装するコードは、１つまたはそれ以上のインターフェースを介して受信され、メモリに記憶され得る。コンピュータシステム２１０に設けられるオペレーティングシステムは、ＭＳ−ＤＯＳ（登録商標）、ＭＳ−ＷＩＮＤＯＷＳ（登録商標）、ＯＳ／２（登録商標）、ＯＳ Ｘ（登録商標）、ＵＮＩＸ（登録商標）、Ｌｉｎｕｘ（登録商標）、または別の公知のオペレーティングシステムであり得る。

電源マネージャ２５０は、バッテリ２５２の電力レベルを監視し得る。電源マネージャ２５０は、電力レベルを判断できるようにするための１つまたはそれ以上のＡＰＩ（アプリケーションプログラミングインターフェース）、コンピュータシステム２００がシャットダウンするまでの残り時間窓、電力消費率、コンピュータシステムが電源（例えばＡＣ電源）かバッテリのどちらで稼働しているかを示すインジケータ、または他の電力関連情報を提供し得る。いくつかの実施形態によれば、電源マネージャ２５０のＡＰＩは、リモートアクセスが可能（例えば、ネットワーク接続経由でリモートバックアップ管理モジュールにアクセス可能）であり得る。いくつかの実施形態によれば、バッテリ２５２は、コンピュータシステム２００に対してローカルまたはリモートに位置する無停電電源装置（ＵＰＳ）であり得る。かかる実施形態では、電源マネージャ２５０がＵＰＳの電力レベルに関する情報を提供し得る。

図３を参照すると、本開示の一実施形態にかかるディレクトリデータサービス１５４が示されている。図示のとおり、ディレクトリデータサービス１５４は、ディレクトリデータサービス（ＤＤＳ）キャッシュ管理モジュール３１２、ディレクトリデータサービス整合管理モジュール３１４、ディレクトリデータサービスグループメンバーシップモジュール３１６、ディレクトリデータサービスクエリ一般化モジュール３１８、およびエラー記録およびレポートモジュール３１８を含む１つまたはそれ以上の構成要素を格納し得る。

下記の記述は、ネットワーク要素、コンピュータ、および／または１つまたはそれ以上のモジュールを含み得る、ディレクトリデータを解決するためシステムおよび方法の構成要素について記載している。本明細書で使用されるとおり、「モジュール」という用語は、計算ソフトウェア、ファームウェア、ハードウェア、および／またはそれらの各種組み合わせを言及するものと理解され得る。ただし、モジュールは、ハードウェアやファームウェアに実装されたり、プロセッサ読み取り可能な記録可能記憶媒体に記録されたりすることのないソフトウェアと解釈されるべきでない（すなわち、モジュール自体はソフトウェアでない）。なお、モジュールは例示的なものである。モジュールは、各種アプリケーションをサポートするために組み合わせ、統合、分離、および／または複製され得る。また、本明細書において特定のモジュールで実行中であると記載されている機能は、１つまたはそれ以上の他のモジュールで、および／または特定のモジュールで実行され得る機能の代わりに、あるいはその機能に加えて１つまたはそれ以上の他のデバイスによって実行され得る。さらに、モジュールは、互いにローカルであり、かつ／またはリモートである複数のデバイスまたは他の構成要素にまたがって実装され得る。加えて、モジュールは、あるデバイスから移動させて別の装置に追加してもよく、かつ／または両方のデバイスに含まれてもよい。

ディレクトリデータサービス（ＤＤＳ）キャッシュ管理モジュール３１２は、キャッシュ管理のうちの１つまたはそれ以上の態様を扱い得る。例えば、ＤＤＳキャッシュ管理モジュール３１２は、ＴＴＬ設定、ＴＴＬ範囲、または他のキャッシュ期限パラメータを受信、計算、および／または設定し得る。ＤＤＳキャッシュ管理モジュール３１２は、１つまたはそれ以上のＴＴＬパラメータ、キャッシュエントリの作成時刻、作成時刻からの経過時間、および／または他の要因に基づいてキャッシュエントリを期限切れにする時期を判断し得る。

ＤＤＳキャッシュ管理モジュール３１２は、１つまたはそれ以上の設定および／または検出された状況に基づいてフェイルオーバー挙動を判断し得る。ＤＤＳキャッシュ管理モジュール３１２は、データソースおよび／またはキャッシュ間での優先順位の設定を受信、設定、および／または実施し得る。

ディレクトリデータサービス整合管理モジュール３１４は、１つまたはそれ以上のデータ整合エラーまたは他のエラーを検出し得る。そして、そのエラーと関連付けられた記録またはアラート通知を提供し得る。例えば、ディレクトリデータサービス整合管理モジュール３１４は、処理中にデータエラーに遭遇し得る。そしてエラーを記録し、かつ／またはアラートを管理者に提供し得る。検出されたエラーは、非制限的な例として、電子メールアドレスの重複、ユーザー名重複、行方不明または無効な属性データ（例えば、行方不明の電子メールアドレス、無効な電子メールアドレスフォーマット、存在しないエントリを参照しているグループメンバーシップ属性、および下位および上位グループメンバーシップ属性の不整合値）、および循環グループ関係を含み得る。ディレクトリデータサービス整合管理モジュール３１４は、各種ディレクトリデータと統合し得る。例えば、ディレクトリデータサービス整合管理モジュール３１４は、ＬＤＡＰディレクトリ、ＳＱＬデータベース、および／またはフラットファイルを格納しているサーバーであり得るディレクトリサーバー１４０（１）．．．（Ｎ）にアクセスし得る。ディレクトリデータサービス整合管理モジュール３１４は、電子メールアドレスまたは他のデータを探すディレクトリサーバー（例えばＬＤＡＰクエリ）にアクセスし得る。受信したデータに基づいて、ディレクトリデータサービス整合管理モジュール３１４はデータ整合エラーを検出し得る。受信した電子メールアドレスが単一のデータソースまたは複数のデータソースにおける複数のディレクトリエントリに対応し得るか、あるいはユーザー名が単一のデータソースにおける複数のディレクトリエントリに対応し得る。いくつかの実施形態によれば、データ整合エラーに加えて、ディレクトリデータサービス整合管理モジュール３１４によって認識される他のエラーは、ディレクトリデータアクセスエラー（例えば、オフラインだったＬＤＡＰサーバーからデータを読み出せなかった）、過小データソースキャッシュエラー（例えば、データソースキャッシュまたはキャッシュインデックスが、リクエストされたメモリ内データのすべてを保持できるだけの大きさがないことを示している）、および／またはエンドユーザー設定複製エラー（エンドユーザー設定複製動作が失敗したことを示している）を含み得る。

循環グループ参照は、ディレクトリサーバーがグループメンバーシップを判断するために上から下へとトラバースしているときにディレクトリデータサービス整合管理モジュール３１４によって認識され得る。例えば、グループＡがグループＢのメンバーであり、グループＢがグループＡのメンバーである場合に、ディレクトリデータサービス整合管理モジュール３１４がこれを検出してエラーを記録し得る。グループの関係は、多数のレベルに深いネスト構造になっていることがあるために、循環グループ参照がいくつか下のレベルで発生し得る。例えば、グループが上位から下位にＡ〜Ｅのネスト構造になっていると仮定すると、グループＢがグループＥのメンバーである可能性があり、循環グループ参照をもたらし得る。いくつかの実施形態によれば、ツリー（すなわちグループ）の特定ノードが以前にアクセスされていると判断し得る再帰的ツリートラバースアルゴリズムが使用され得る。これが循環グループ参照を表し得る。循環グループ参照は、データソース（例えば単一のディレクトリサーバー）で、あるいは複数のデータソースにまたがって検出され得る。グループの解決中に、循環グループ参照が特定および／または記録され得る。１つまたはそれ以上のアラートが生成され得る。

ディレクトリデータサービス整合管理モジュール３１４は、１つまたはそれ以上のデータ整合エラーまたは他のエラーを記録し得る。そしてアラートが別のメカニズムによって生成され得る。例えば、ディレクトリデータサービス整合管理モジュール３１４は、ディスク上、あるいは他の電子ストレージにアラートファイルを作成し得る。アラートファイルは、タイムスタンプと、アラート条件のタイプを表す識別子を格納し得る。ネットワークデバイス１７０上で実行中のプロセスまたはエージェントが、周期的にアラートファイルをポーリングし、アラートメタデータを処理し、１人またはそれ以上のユーザー（例えば、登録されたシステム管理者）にアラート電子メールを送り得る。他の通信チャネルが、ＳＭＳテキストメッセージ、ボイスメール、および／またはウェブページ投稿などをユーザーに通知する目的で使用され得る。いくつかの実施形態によれば、ディレクトリデータサービス１５４は、直接アラートを送ってもよい。１つまたはそれ以上の実施形態によれば、ディレクトリデータサービス整合管理モジュール３１４または別のプロセス、構成要素、あるいはモジュールが、インターフェースを使用して（例えば、ＳＮＭＰ、Ｗｉｎｄｏｗｓ Ｓｙｓｔｅｍ Ｅｖｅｎｔ、またはカスタムＩＰＣ（プロセス間通信）を介して）アラートを送ってもよい。

ディレクトリデータサービス整合管理モジュール３１４によるデータ整合エラーの検出およびシステム管理者への迅速なアラート通知により、システムの性能低下または故障が起きる前にシステム管理者が問題に対処することを可能にし得る。

ディレクトリデータサービスグループメンバーシップモジュール３１６は、グループのメンバーを特定するために、ディレクトリサーバーをトラバースし得る。ディレクトリデータサービスグループメンバーシップモジュール３１６は、上位グループメンバーシップ、下位グループメンバーシップ、またはそれらの両方を解決し得る。

ディレクトリデータサービスグループメンバーシップモジュール３１６は、効率的なディレクトリデータグループ解決およびキャッシュ管理を可能にし得る。ディレクトリデータサービスグループメンバーシップモジュール３１６は、階層状のディレクトリデータに格納された１つまたはそれ以上のディレクトリエントリをトラバースし得る。トラバースは、現在の対象グループから開始され得る。ディレクトリエントリがキャッシュで利用可能な場合には、キャッシュを使用して解析が実行され得る。ディレクトリエントリがキャッシュで利用不可の場合には、ディレクトリサーバーに対する問い合わせが行われる。ディレクトリエントリがディレクトリサーバーから取り出されたら、キャッシュに書き込まれ得る。ディレクトリデータサービスグループメンバーシップモジュール３１６は、第１のディレクトリエントリに格納されたメンバーを特定するために第１のディレクトリエントリを読み出し得る。メンバーが特定された場合、ディレクトリデータサービスグループメンバーシップモジュール３１６はそのメンバーのマッピングに現在の対象グループを追加し得る。メンバーのマッピングは、そのメンバーと関連付けられた１つまたはそれ以上のグループおよび／または配布リストを示すフラットなデータ構造であり得る。ディレクトリデータサービスグループメンバーシップモジュール３１６は、第１のディレクトリエントリがさらなるディレクトリエントリ（例えば、現在のディレクトリエントリよりもさらに下の階層レベル）を含むかどうかを判断し得る。ディレクトリデータサービスグループメンバーシップモジュール３１６は、現在の対象グループが別のメンバー（例えば、さらなるディレクトリサービスエントリに格納されたネスト構造のグループは、対象グループにマップされるメンバーを含む）のマッピングに追加されるかどうかを判断するために、第１のディレクトリエントリ（例えばネスト構造のグループ）に格納されたさらなるディレクトリエントリを読み出し得る。ディレクトリデータサービスグループメンバーシップモジュール３１６は、現在の対象グループを対象にさらなる階層状のディレクトリデータサービスレベルがトラバースされるかどうか（例えば、対象グループ下に、下方にトラバースしていくさらなる階層レベルが存在するかどうか）を判断し得る。いくつかの実施形態によれば、ディレクトリデータサービスグループメンバーシップモジュール３１６は、グループメンバーシップマップと関連付けられている特定されたユーザーのリスト、グループメンバーシップマップと関連付けられている特定された配布リストのリスト、および／またはグループメンバーシップマップと関連付けられている特定されたグループのリストをキャッシュし得る。いくつかの実施形態によれば、適用ポリシーが対象グループに適用され、かつ、対象グループに対する１人またはそれ以上のメンバーのマッピングにより、ポリシーを適用することに関わる性能が向上し得る。例えば、ディレクトリサーバーの１つまたはそれ以上の対象グループを特定するデータが、アプリケーションから受信され得る。特定された対象グループに対するメンバーの１つまたはそれ以上のマッピングが、ポリシーを適用するためのアプリケーションに提供され得る。

いくつかの実施形態によれば、キャッシュされたディレクトリエントリは、グループに対する１つまたはそれ以上のユーザーのマッピングを生成するために、ディレクトリデータサービスによって、およびディレクトリデータサービスクライアントによって同時に使用され得る。

いくつかの実施形態によれば、グループ、配布リスト、および他のキャッシュされたディレクトリエントリは期限が切れ得る。期限切れは、各ディレクトリエントリに割り当てられた別々のランダム値によって判断される期限に基づき得る。ランダム値は、多数の期限切れのエントリが同時にリフレッシュされる必要性が発生してディレクトリサーバーに過剰な負荷がかかる確率を下げるために、ディレクトリエントリの期限を分散し得る。

ディレクトリデータサービスクエリ一般化モジュール３１８により、ディレクトリサーバーに対するクエリ（例えばＬＤＡＰクエリ）が、クエリフィルタトークンまたは他のメカニズムを使用して様々なディレクトリデータエイリアスを一致させることができ得る。クエリフィルタトークンとエイリアスとの一致については、図８と関連させて、以下でさらに詳述されている。

エラー記録およびレポートモジュール３１８は、ディレクトリデータの解決に関連するログ、レポート、または他の情報を生成し得る。

図４を参照すると、本開示の一実施形態にかかるディレクトリデータを解決するための方法４００が示されている。ブロック４０２で、最上位グループのリストが読み出され得る。本開示で先に定めたとおり、「最上位グループ」は対象グループであり得る。

ブロック４０４で、処理される１つまたはそれ以上の最上位グループが存在するかどうかが判断され得る。リストにおける１つまたはそれ以上の最上位グループが未処理のままである場合には、方法４００がブロック４０８で続行し得る。未処理の最上位グループが存在しない場合には、方法がブロック４０６で終了し得る。

ブロック４０８で、最上位グループが、リスト内の電子メールアドレスまたは別のタイプの一意の識別子によって表されているかどうかが判断され得る。最上位グループが電子メールアドレスによって表されている場合には、方法がブロック４１０で続行し得る。最上位グループが電子メールアドレスによって表されていない場合には、方法がブロック４１２で続行し得る。

ブロック４１０で、最上位グループが配布リストであるかどうかが判断され得る。最上位グループが配布リストである場合には、方法がブロック４１２で続行し得る。最上位グループが配布リストでない場合には、方法がブロック４０４に戻り得る。

ブロック４１２で、最上位グループが、グループのリストに追加され、さらなる解決のために処理され得る。

ブロック４１４で、方法は、解決すべきグループが他にも存在するどうかを判断し得る。解決すべきグループが他にも残っている場合には、方法がブロック４１６で続行し得る。解決すべきグループがグループのリストに残っていない場合には、方法がブロック４０４に戻り得る。

ブロック４１６では、グループメンバーが存在するかどうかを判断するためにグループが解決され得る。グループメンバーが存在する場合には、方法がブロック４１８で続行し得る。他にグループメンバーが存在しない場合には、方法がブロック４１４に戻り得る。

ブロック４１８で、最上位グループが、特定されたグループメンバーのマッピングに追加され得る。

ブロック４２０で、特定されたグループメンバーは、メンバーがグループ（例えばさらなるネストレベル）であるかどうかを判断するために解析され得る。メンバーがグループである場合には、方法がブロック４２４で続行し得る。メンバーがグループでない場合には、方法がブロック４２２で続行し得る。

ブロック４２２で、特定されたグループメンバーは、ユーザーキャッシュに追加され得るユーザーであり得る。

ブロック４２４で、方法は、グループメンバーが配布リストまたはグループであるかどうかを判断し得る。グループメンバーが配布リストである場合には、方法がブロック４２８で続行し得る。メンバーがグループである場合には、方法がブロック４２６で続行し得る。

ブロック４２６で、グループがグループキャッシュに加えられ得る。

ブロック４２８で、配布リストが配布リストキャッシュに追加され得る。

ブロック４３０で、グループメンバー（すなわち配布リストまたはグループ）が、解決すべきグループのリストに追加され得る（例えば、ネスト構造の配布リストまたはグループを解決するためにもう１度繰り返しを実行する）。方法は、ブロック４１４で続行し得る。ブロック４０６で、解決すべき最上位グループが他に残っていない場合には、グループ解決プロセスが終了し得る。

図５を参照すると、本開示の一実施形態にかかるディレクトリデータ解決モジュールの構成要素を表すブロック図が示されている。図示のとおり、ホスト５０２（例えばゲートウェイ機器）は、キャッシュ５０６、データアクセス層５０８、メンバーシップマップビルドタスク５１０、ビルドタスクスケジューラ５１２、およびＡＰＩウェブサービス５１４を格納し得るディレクトリデータモジュール５０４を格納し得る。ＡＰＩウェブサービス５１４およびメンバーシップマップビルドタスク５１０は、キャッシュ５０６およびデータアクセス層５０８に同時にアクセスし得る。データアクセス層５０８は、ディレクトリサーバー５１８へのアクセスを提供し得る。メンバーシップマップビルドタスク５１０は、キャッシュ５０６およびデータアクセス層５０８との１つまたはそれ以上のインタフェースをビルドタスクスケジューラ５１２に提供し得る。ＡＰＩウェブサービス５１４は、キャッシュ５０６およびデータアクセス層５０８との１つまたはそれ以上のインタフェースをディレクトリデータサービスクライアント５１６に提供して得る。

図６Ａ、図６Ｂ、および図６Ｃを参照すると、本開示の一実施形態にかかるディレクトリデータ構造が示されている。例示的実施形態によれば、ディレクトリデータサービスグループ解決モジュールに対象グループが提供され得る。図６Ｂに示すとおり、例示的な対象グループは、「ｇｒｏｕｐ１」および「ｄｌｉｓｔ２」を含み得る。図６Ａに示すドメイン階層の最上位レベルから下へと進み、要素６０２は「ｇｒｏｕｐ１」を格納するものとして特定され、要素６０４は「ｄｌｉｓｔ２」を格納しているものとして特定されている。「Ｇｒｏｕｐ１」は、図６Ｃの要素６１２によって示されたグループキャッシュに追加される。「Ｄｌｉｓｔ２」は、図６Ｃの要素６１０によって示された配布リストキャッシュに追加される。これらの最上位レベルグループは、メンバー、グループ、および配布リストを特定するために、さらに解決される。要素６０２の「ｇｒｏｕｐ１」を解決することにより、メンバー「ｕｓｅｒ１」および「ｕｓｅｒ２」が特定される。これらのユーザーは、図６Ｃの要素６０８で示されたユーザーキャッシュに追加される。これらのユーザーは、対象グループ「ｇｒｏｕｐ１」の一部であることから、メンバーシップマップ６１４における「ｇｒｏｕｐ１」にマッピングされる。要素６０４の「ｄｌｉｓｔ２」を解決することにより、メンバー「ｄｌｉｓｔ１」およびメンバー「ｕｓｅｒ３」が特定される。「Ｄｌｉｓｔ１」は、図６Ｃの要素６１０によって示された配布リストキャッシュに追加される。「ｕｓｅｒ３」は、図６Ｃの要素６０８で示されたユーザーキャッシュに追加される。「Ｄｌｉｓｔ１」およびメンバー「ｕｓｅｒ３」は、対象グループ「ｄｌｉｓｔ２」の一部であり、メンバーシップマップ６１４における「ｄｌｉｓｔ２」にマッピングされる。「Ｄｌｉｓｔ１」はさらに解決され、メンバー「ｕｓｅｒ１」および「ｕｓｅｒ２」を特定する。これらのメンバーは、グループキャッシュにすでに存在する。図示のとおり、図６Ｂの対象グループリストに該当せず、そのために、トラバースされることも、キャッシュされることも、メンバーシップマップキャッシュをビルドするためのプロセスの一部としてメンバーシップマップ６１４に追加されることもないグループおよび配布リストが、他にもいくつか存在する。

図７は、本開示の一実施形態にかかるディレクトリデータサービスキャッシュアクセスを示す流れ図を表す。図示のとおり、いくつかの実施形態によれば、ＬＤＡＰルックアップおよびメンバーシップマップのビルドプロセスは、ＬＤＡＰサーバーから読み出されるだけであり得る（すなわち、書き込みアクセスは許可されない）。ＬＤＡＰクエリを実行するディレクトリデータサービスクライアントが、どのグループのメンバーでもないユーザーを解決するために、ＬＤＡＰサーバーに問い合わせ得る。ＬＤＡＰクエリを実行するディレクトリデータサービスクライアントは、１つまたはそれ以上のグループのメンバーであるユーザーを解決するために、ディレクトリデータサービスキャッシュに問い合わせ得る。タスクスケジューラによってスケジューリングされた最初のメンバーシップマップのビルドが、ＬＤＡＰサーバーから読み出され、取り出されたＬＤＡＰデータをディレクトリデータサービスキャッシュに書き込み得る。キャッシュエントリの期限が切れているか、あるいは存在しない場合には、以降のメンバーシップマップのビルドがＬＤＡＰサーバーから読み出され、取り出されたＬＤＡＰデータをディレクトリデータサービスキャッシュに書き込み得る。ディレクトリエントリがキャッシュに存在し、期限が切れていない場合には、以降のメンバーシップマップのビルドがディレクトリデータサービスキャッシュから読み出され得る。

図８は、本開示の一実施形態にかかる、クエリフィルタトークンを使用してディレクトリエントリを一致させる方法を示す。いくつかの実施形態によれば、ディレクトリサーバーへの問い合わせ時に、クエリフィルタトークンが使用され得る。クエリフィルタトークンにより、トークンが、対応するパラメータトークンの実行時に代用されるクエリにおいて、パラメータのプレースホルダとして動作できる可能性がある。例えば、クエリフィルタトークンは以下を含み得る。

％ｓトークンは、完全電子メールアドレスを問い合わせるクエリにおけるプレースホルダであり得る。％ｕトークンは、電子メールアドレスのローカル部分を問い合わせるクエリにおけるプレースホルダであり得る。％ｄトークンは、電子メールアドレスのドメイン部分を問い合わせるクエリにおけるプレースホルダであり得る。％ｎトークンは、完全名を問い合わせるクエリにおけるプレースホルダであり得る。完全名は、電子メールアドレスのローカル部を取り出し、ピリオドおよびアンダースコアをスペースに置き換えることによって導出され得る。

１つまたはそれ以上のタイプのメールサーバーの管理者は、「メール」属性値に加え、自身の名前および／または名字、あるいはそれらのいくつかの組み合わせに基づいて、自身のサーバーを、ユーザーの電子メールも受け入れるように構成し得る。
想定するエントリ例：
ｄｎ： ＣＮ＝Ｊｏｈｎ Ｂｉｇｂｏｏｔｅ， Ｏ＝ｓｆｄｏｍ１
ｇｉｖｅｎｎａｍｅ： Ｊｏｈｎ
ｏｂｊｅｃｔｃｌａｓｓ： ｄｏｍｉｎｏＰｅｒｓｏｎ
ｕｉｄ： ＪＢｉｇｂｏｏｔｅ＿ｕｉｄ
ｕｉｄ： ＪＢｉｇｂｏｏｔｅ＿ｕｉｄ２＠ｅｎｇ．ｓｙｍａｎｔｅｃ．ｃｏｍ
ｍａｉｌ： ｊｏｈｎ．ｂｉｇｂｏｏｔｅ．ｍａｉｌ＠ｅｎｇ．ｓｙｍａｎｔｅｃ．ｃｏｍ
ｃｎ： Ｊｏｈｎ Ｂｉｇｂｏｏｔｅ
ｓｎ： Ｂｉｇｂｏｏｔｅ

ｅｎｇ．ｓｙｍａｎｔｅｃ．ｃｏｍおよびａｌｉａｓｄｏｍａｉｎ．ｃｏｍのメールを受信するように構成されたメールサーバーは、以下のうちの１つまたはそれ以上を無効な受信者と認識するように構成され得る。
ｊｏｈｎ＠ａｌｉａｓｄｏｍａｉｎ．ｃｏｍ
ｊｏｈｎ＠ｅｎｇ．ｓｙｍａｎｔｅｃ．ｃｏｍ
ｂｉｇｂｏｏｔｅ＠ａｌｉａｓｄｏｍａｉｎ．ｃｏｍ
ｂｉｇｂｏｏｔｅ＠ｅｎｇ．ｓｙｍａｎｔｅｃ．ｃｏｍ
ｊｂｉｇｂｏｏｔｅ＿ｕｉｄ＠ａｌｉａｓｄｏｍａｉｎ．ｃｏｍ
ｊｂｉｇｂｏｏｔｅ＿ｕｉｄ＠ｅｎｇ．ｓｙｍａｎｔｅｃ．ｃｏｍ
ｊｂｉｇｂｏｏｔｅ＿ｕｉｄ２＠ｅｎｇ．ｓｙｍａｎｔｅｃ．ｃｏｍ
ｊｏｈｎ．ｂｉｇｂｏｏｔｅ．ｍａｉｌ＠ｅｎｇ．ｓｙｍａｎｔｅｃ．ｃｏｍ
ｊｏｈｎ．ｂｉｇｂｏｏｔｅ．ｍａｉｌ＠ａｌｉａｓｄｏｍａｉｎ．ｃｏｍ
ｊｏｈｎ．ｂｉｇｂｏｏｔｅ＠ａｌｉａｓｄｏｍａｉｎ．ｃｏｍ
ｊｏｈｎ．ｂｉｇｂｏｏｔｅ＠ｅｎｇ．ｓｙｍａｎｔｅｃ．ｃｏｍ
ｊｏｈｎ＿ｂｉｇｂｏｏｔｅ＠ａｌｉａｓｄｏｍａｉｎ．ｃｏｍ
ｊｏｈｎ＿ｂｉｇｂｏｏｔｅ＠ｅｎｇ．ｓｙｍａｎｔｅｃ．ｃｏｍ

メールサーバー管理者は、これらのエイリアス（例えば、「メール」属性値をユーザーの唯一の配送可能なアドレスとみなすなど）をサポートしないように自身のサーバーを構成し得るので、自身のディレクトリサーバークエリを、これらの各種アドレス形態を包含あるいは除外するように構成することも可能であり得る。大規模なメールサーバー展開では、「ｕｉｄ」および「メール」属性値だけを配送可能なアドレスとして使用し得る。かかる構成は、上記実施例に続いて、以下のアドレスをサポートする。
ｊｂｉｇｂｏｏｔｅ＿ｕｉｄ＠ａｌｉａｓｄｏｍａｉｎ．ｃｏｍ
ｊｂｉｇｂｏｏｔｅ＿ｕｉｄ＠ｅｎｇ．ｓｙｍａｎｔｅｃ．ｃｏｍ
ｊｂｉｇｂｏｏｔｅ＿ｕｉｄ２＠ｅｎｇ．ｓｙｍａｎｔｅｃ．ｃｏｍ
ｊｏｈｎ．ｂｉｇｂｏｏｔｅ．ｍａｉｌ＠ｅｎｇ．ｓｙｍａｎｔｅｃ．ｃｏｍ
ｊｏｈｎ．ｂｉｇｂｏｏｔｅ．ｍａｉｌ＠ａｌｉａｓｄｏｍａｉｎ．ｃｏｍ

いくつかの実施形態によれば、これらのうちの１つまたはそれ以上を捕捉する目的でクエリフィルタが使用され得る。
（｜（ｍａｉｌ＝％ｓ）（ｕｉｄ＝％ｓ）（ｕｉｄ＝％ｕ））

管理者がユーザーの完全名へのエイリアス化を許容するようにしている場合には、クエリを以下のように変更することができる。
（｜（ｍａｉｌ＝％ｓ）（ｕｉｄ＝％ｓ）（ｕｉｄ＝％ｕ）（ｃｎ＝％ｎ））
なお、ここでは、電子メールアドレスのローカル部におけるピリオドまたはアンダーラインを表すホワイトスペースの代用となり得る％ｎトークンが使用され、その結果、ｊｏｈｎ．ｂｉｇｂｏｏｔｅ＠ｅｎｇ．ｓｙｍａｎｔｅｃ．ｃｏｍまたはｊｏｈｎ＿ｂｉｇｂｏｏｔｅ＠ｅｎｇ．ｓｙｍａｎｔｅｃ．ｃｏｍは（ｃｎ＝ｊｏｈｎ ｂｉｇｂｏｏｔｅ）となる。

管理者が、ユーザーの名前および名字へのエイリアス化も許容している場合には、クエリが以下のように変更され得る。
（｜（ｍａｉｌ＝％ｓ）（ｕｉｄ＝％ｓ）（ｕｉｄ＝％ｕ）（ｃｎ＝％ｎ）（ｇｉｖｅｎＮａｍｅ＝％ｕ）（ｓｎ＝％ｕ））

名前および名字のエイリアス化が許容されていると、同じ名前および／または名字を有する２つ以上のユーザーエントリ間で名前空間の「衝突」が発生する可能性がはるかに高まり得る。たとえば、仮想的なディレクトリサーバーが次のようなエントリも格納している場合、
ｄｎ： ＣＮ＝Ｊｏｈｎ Ｗｈｏｒｆｉｎ， Ｏ＝ｓｆｄｏｍ１
ｇｉｖｅｎｎａｍｅ： Ｊｏｈｎ
…
ｃｎ： Ｊｏｈｎ Ｗｈｏｒｆｉｎ
ｓｎ： Ｗｈｏｒｆｉｎ

受信者を一意に特定できないというテキストメッセージを伴う５ｘｘエラーをＳＭＴＰクライアントに返すことにより、ＳＭＴＰサーバー自体がｊｏｈｎ＠ａｌｉａｓｄｏｍａｉｎ．ｃｏｍへの配送試行を扱い得る。ディレクトリデータサービスＬＤＡＰクエリが２つのエントリ（ｇｉｖｅｎＮａｍｅ＝ｊｏｈｎ）を返し得るので、この状況は、上記のデータ整合エラーとして扱われ得る。

図８に示すとおり、例示的な完全なアドレス、電子メールアドレスのローカル部分、対応する完全名、および例示的なクエリが、要素８０２に表されている。例示的なディレクトリエントリが、要素８０６に表されている。ディレクトリサーバーによっては（例えばＩＢＭ Ｌｏｔｕｓ Ｄｏｍｉｎｏ）、ディレクトリエントリの複数の電子メールエイリアスをサポートするものもある。要素８０４に示すとおり、要素８０６に列記されているディレクトリエントリに対して、複数の電子メールエイリアスがサポートされ得る。要素８０８および８１０に示すとおり、「ｊｏｈｎ＿ｓｍｉｔｈ＠ｄｏｍａｉｎ．ｃｏｍ」の電子メールアドレスの妥当性を検証するためにクエリが受信された場合には、トークン％ｓおよび％ｕを使用したディレクトリサーバークエリがディレクトリエントリを見つけることはない。ただし、要素８１２および８１４に表すとおり、完全名で問い合わせるために％ｎトークンが使用された場合には、一致が見つかり得る。％ｎトークンは、電子メールアドレスのローカル部におけるピリオドまたはアンダースコアをスペースで置き換えて、問い合わせ用の完全名を導出する。

この時点で、上記の本開示にかかるディレクトリサーバーを統合が、ある程度までの入力データの処理と出力データの生成とを概して含むということに注意すべきである。この入力データ処理および出力データ生成は、ハードウェアまたはソフトウェアで実施され得る。例えば、上記の本開示にかかるディレクトリサーバー統合と関連付けられた機能を実行するために、ディレクトリデータサービス、または同様の回路あるいは関連する回路で、特定の電子構成要素が用いられ得る。あるいは、命令に従って動作する１つまたはそれ以上のプロセッサが、上記の本開示にかかるディレクトリサーバーを統合と関連付けられた機能を実行し得る。このような場合、かかる命令が１つまたはそれ以上のプロセッサ読み取り可能な記憶媒体（例えば、磁気ディスクまたは他の記憶媒体）に記憶され得るか、あるいは１つまたはそれ以上の搬送波に組み入れられた１つまたはそれ以上の信号を介して１つまたはそれ以上のプロセッサに送信され得ることは、本開示の範囲内である。

本開示は、本明細書に記載されている具体的な実施形態によって範囲が制限されるものではない。実際、上記の記載内容および添付の図面から、本明細書に記載されている実施形態に加え、本開示の他の各種実施形態および変型例が当業者にとって明らかであろう。そのため、かかる他の実施形態および変型例は、本開示の範囲内に収まるものと意図される。さらに、本開示について、特定の目的のための特定の環境における特定の実施態様という文脈で本明細書に記載してきたが、当業者であれば、その有用性がそれに制限されず、本開示が任意の数の目的のために任意の数の環境で有益に実施され得ることを認識するであろう。したがって、以下に述べる請求項は、本明細書に記載されている本開示の全幅および精神を鑑みて解釈されるべきである。

Claims (14)

1. ディレクトリデータを解決するための方法であって、
   ディレクトリサーバーの１つまたはそれ以上の対象グループを特定するデータを受信することと、
   少なくとも１つのコンピュータプロセッサを使用して、階層状のディレクトリデータに格納された１つまたはそれ以上のディレクトリエントリを、現在の対象グループに対応するディレクトリエントリからトラバースすることと、
   第１のディレクトリエントリを読み出して前記第１のディレクトリエントリに格納されたメンバーを特定することと、
   メンバーが前記第１のディレクトリエントリに格納されている場合に、前記現在の対象グループを前記メンバーのマッピングに追加することと、
   前記第１のディレクトリエントリがさらなるディレクトリエントリを格納しているかどうかを判断することと、
   前記第１のディレクトリエントリにさらなるディレクトリエントリが格納されている場合に、前記さらなるディレクトリエントリを読み出して、前記現在の対象グループが別のメンバーのマッピングに追加されるかどうか、およびさらなる階層状のディレクトリデータレベルが前記現在の対象グループを対象にトラバースされるかどうかを判断することと、
   キャッシュ内の１つ又はそれ以上のディレクトリエントリを、前記１つ又はそれ以上の各ディレクトリエントリに割り当てられた別々のランダム値によって判断される期限に基づいて期限切れにすることであって、前記ランダム値は、ある時点でキャッシュ内の期限切れのディレクトリエントリをリフレッシュするために必要な負荷を減らすために、前記キャッシュされた１つ又はそれ以上のディレクトリエントリの期限を分散させるのに用いられ、前記別々のランダム値によって判断される前記期限は特定の許容範囲内にある、ことと、
   を含む、方法。
2. 前記１つまたはそれ以上のディレクトリエントリが、ユーザー、グループ、および配布リストのうちの少なくとも１つを含む、請求項１に記載の方法。
3. 第２の対象グループの階層状のディレクトリデータに格納された１つまたはそれ以上のディレクトリエントリのトラバースを繰り返すことをさらに含む、請求項１に記載の方法。
4. グループメンバーシップマップと関連付けられている特定されたユーザーのリストをキャッシュすることをさらに含む、請求項１に記載の方法。
5. グループメンバーシップマップと関連付けられている特定された配布リストのリストをキャッシュすることをさらに含む、請求項１に記載の方法。
6. グループメンバーシップマップと関連付けられている特定されたグループのリストをキャッシュすることをさらに含む、請求項１に記載の方法。
7. ポリシーが対象グループに適用され、対象グループに対する１人またはそれ以上のメンバーのマッピングにより、ポリシーを適用することに関わる性能が向上する、請求項１に記載の方法。
8. キャッシュでディレクトリエントリが利用可能である場合に、前記キャッシュを使用して解析が実行され、キャッシュでディレクトリエントリが利用できない場合には、前記ディレクトリサーバーに対して問い合わせが行われ得る、請求項１に記載の方法。
9. ディレクトリエントリの期限が切れていると、キャッシュで前記ディレクトリエントリが利用できない、請求項８に記載の方法。
10. ディレクトリサーバーの１つまたはそれ以上の対象グループを特定する前記データがアプリケーションから受信され、かつ対象グループに対する少なくとも１つのメンバーのマッピングが、ポリシーを適用するためアプリケーションに提供される、請求項１に記載の方法。
11. トラバース中、階層状のディレクトリデータに格納された前記１つまたはそれ以上のディレクトリエントリにおける循環グループ関係を特定することと、
    前記循環グループ関係と関連付けられたデータ統合エラー情報を格納しているアラートを管理者に提供することと、
    をさらに含む、請求項１に記載の方法。
12. 前記ディレクトリサーバーが利用不可であると判断することと、
    ディレクトリデータを解決するために前記期限切れの対応ディレクトリエントリを使用することと、
    をさらに含む、請求項９に記載の方法。
13. キャッシュされたディレクトリエントリが、階層状のディレクトリデータをトラバースしてグループに対する１つまたはそれ以上のユーザーのマッピングを生成するプロセスによって、およびディレクトリデータサービスクライアントによって同時に使用されることを可能にする、請求項８に記載の方法。
14. ディレクトリデータを解決するためのシステムであって、
    ネットワークに通信可能に連結された１つまたはそれ以上のプロセッサであって、
    ディレクトリサーバーの１つまたはそれ以上の対象グループを特定するデータを受信し、
    階層状のディレクトリデータに格納された１つまたはそれ以上のディレクトリエントリを、現在の対象グループに対応するディレクトリエントリからトラバースし、
    第１のディレクトリエントリを読み出して前記第１のディレクトリエントリに格納されたメンバーを特定し、
    メンバーが前記第１のディレクトリエントリに格納されている場合に、前記メンバーのマッピングを前記現在の対象グループに追加し、
    前記第１のディレクトリエントリがさらなるディレクトリエントリを格納しているかどうかを判断し、
    前記さらなるディレクトリエントリを読み出して、前記第１のディレクトリエントリにさらなるディレクトリエントリが格納されている場合に、前記現在の対象グループが別のメンバーのマッピングに追加されるかどうか、およびさらなる階層状のディレクトリデータレベルが前記現在の対象グループを対象にトラバースされるかどうかを判断し、
    キャッシュ内の１つ又はそれ以上のディレクトリエントリを、前記１つ又はそれ以上の各ディレクトリエントリに割り当てられた別々のランダム値によって判断される期限に基づいて期限切れにする
    ように構成されている１つまたはそれ以上のプロセッサを備え、
    前記ランダム値は、ある時点でキャッシュ内の期限切れのディレクトリエントリをリフレッシュするために必要な負荷を減らすために、前記キャッシュされた１つ又はそれ以上のディレクトリエントリの期限を分散させるのに用いられ、前記別々のランダム値によって判断される前記期限は特定の許容範囲内にある、システム。