次の方法で共有


ADSIスキーマモデル

スキーマは、ディレクトリサービスで認識されるすべての種類のオブジェクトの定義を保持するという点で、ディクショナリに似ています。 ADSIクライアントアプリケーションは、スキーマを参照して、特定のADSI実装の機能を検出できます。 また、ADSIには、ディレクトリサービスの基になるスキーマとの通信に使用できるスキーマ管理インターフェイスが用意されています。

一部のスキーマは拡張可能であり、ADSIプロバイダーまたはサードパーティのサプライヤーは、新しいインターフェイスまたは既存のインターフェイスの追加プロパティを公開することができます。 ADSIクライアントは、このデータを使用して、各ディレクトリサービスでサポートされている機能を決定します。

スキーマオブジェクトには、クラス、プロパティ、および構文の3種類があり、それぞれがスキーマ管理インターフェイスIADsClassIADsProperty、およびIADsSyntaxをサポートしています。

メモ

クラスはオーバーロードされた用語です。 C++クラス、Javaクラス、COMクラス、およびADSIクラスがあります。 このドキュメントでは、特に修飾されていない限り、クラスという単語は、カテゴリまたはスキーマオブジェクトの種類を指します。

 

ADSIは、すべてのディレクトリサービスのスキーマを抽象化し、名前空間オブジェクト内のすべての最上位レベルのルートノードに配置します。 ディレクトリサービスが特定のルートノードでサポートするクラスを識別するには、スキーマオブジェクトを列挙し、クラスオブジェクト、プロパティオブジェクト、および構文オブジェクトの一覧を取得します。 詳細については、 「ADSIスキーマの使用」 を参照してください。

ADSI LDAPプロバイダースキーマキャッシュ

ADSIのLDAPプロバイダーは、スキーマデータをローカルコンピューターにキャッシュしようとします。 サブスキーマは、ディレクトリサービスエンタープライズ (rootDSE) のルートにあるsubSchemaSubEntry属性に格納されている識別名によって識別されます。 LDAP v3サーバーは、サブスキーマデータを提供するだけでなく、スキーマが最後に変更された日時を判断するために使用されるmodifyTimeStamp属性を公開する必要があります。

ADSIは、最初にLDAPサーバーにバインドするときに、subSchemaSubEntry属性を使用してサブスキーマデータを取得します。 ADSIがサブスキーマオブジェクトの検出に成功すると、LDAPサーバーに接続しているコンピューターのレジストリにデータへのポインターを格納します。 これらの値がレジストリに格納される正確な場所については、 「ADSIとユーザーアカウント制御」 を参照してください。

次に、ADSIはスキーマデータの処理を試み、modifyTimeStamp属性を読み取ります。 modifyTimeStamp属性が存在し、ADSIがスキーマを正常に処理した場合、ADSIはサブスキーマをディスクに書き込み、キーの下に次の2つのレジストリ値を作成します。 サブスキーマデータが存在しても処理できない場合、これらのレジストリ値は作成されません。

  • modifyTimeStamp属性を含むTime値。 この値は、スキーマデータが最新であることを確認し、スキーマデータが常に再読み込みされるのを防ぐために使用されます。
  • ファイル値。ADSIがファイルシステム内のスキーマデータを格納する場所へのパスを含みます。 既定では、ADSIはLDAPサーバーの名前に対応するファイル名を使用して、<systemroot>\SchCacheディレクトリにサブスキーマをキャッシュします。

サブスキーマデータを処理できても、modifyTimeStamp属性が公開されていない場合、スキーマデータはメモリにキャッシュされますが、ディスクには書き込まれません。 ローカルコンピューター上のADSIを介してLDAP v3サーバーに接続されていて、キャッシュされたサブスキーマが存在しない場合は、次のいずれかの理由が考えられます。

  • サーバーが正しいプロパティを公開しませんでした。
  • ADSIがスキーマを処理できませんでした。
  • ADSIがファイルシステムにファイルを書き込めませんでした。