ADSI-Schemamodell

Ein Schema ähnelt einem Wörterbuch, da es die Definition jedes Typs von Objekten enthält, die einem Verzeichnisdienst bekannt sind. ADSI-Clientanwendungen können ein Schema durchsuchen, um die Features einer bestimmten ADSI-Implementierung zu ermitteln. Darüber hinaus stellt ADSI Schemaverwaltungsschnittstellen bereit, die für die Kommunikation mit dem zugrunde liegenden Schema eines Verzeichnisdiensts verwendet werden können.

Einige Schemas sind erweiterbar, und ADSI-Anbieter oder Drittanbieter können dort neue Schnittstellen oder zusätzliche Eigenschaften für vorhandene Schnittstellen veröffentlichen. ADSI-Clients verwenden diese Daten, um zu bestimmen, welche Features für die einzelnen Verzeichnisdienste unterstützt werden.

Es gibt drei Arten von Schemaobjekten: Klassen, Eigenschaften und Syntaxen, die jeweils die Schemaverwaltungsschnittstellen IADsClass, IADsProperty und IADsSyntax unterstützen.

Hinweis

Klasse ist ein überladener Begriff. Es gibt C++-Klassen, Java-Klassen, COM-Klassen und ADSI-Klassen. In diesem Dokument verweist die Wortklasse, sofern nicht anders qualifiziert, auf eine Kategorie oder einen Typ des Schemaobjekts.

 

ADSI abstrahiert das Schema jedes Verzeichnisdiensts und platziert es in jedem Stammknoten der obersten Ebene im Namespace-Objekt . Um zu ermitteln, welche Klassen ein Verzeichnisdienst auf einem bestimmten Stammknoten unterstützt, listen Sie das Schemaobjekt auf und rufen eine Liste von Klassenobjekten, Eigenschaftsobjekten und Syntaxobjekten ab. Weitere Informationen finden Sie unter Verwenden des ADSI-Schemas.

ADSI LDAP-Anbieterschemacache

Der LDAP-Anbieter für ADSI versucht, Schemadaten auf dem lokalen Computer zwischenzuspeichern. Ein Unterschema wird durch einen distinguished Name identifiziert, der im subSchemaSubEntry-Attribut im Stammverzeichnis des Verzeichnisdienstunternehmens (rootDSE) gespeichert ist. Zusätzlich zur Bereitstellung der Unterschemadaten sollten LDAP v3-Server ein modifyTimeStamp-Attribut verfügbar machen, das verwendet wird, um den Zeitpunkt zu bestimmen, zu dem das Schema zuletzt geändert wurde.

Wenn ADSI zum ersten Mal an den LDAP-Server gebunden wird, werden die Subschemadaten mithilfe des subSchemaSubEntry-Attributs abgerufen. Wenn ADSI das Subschemaobjekt erfolgreich findet, speichert es einen Zeiger auf die Daten in der Registrierung auf dem Computer, der eine Verbindung mit dem LDAP-Server herstellt. Informationen dazu, wo genau diese Werte in der Registrierung gespeichert werden, finden Sie unter ADSI und Benutzerkontensteuerung.

ADSI versucht dann, die Schemadaten zu verarbeiten und liest das modifyTimeStamp-Attribut . Wenn das attribut modifyTimeStamp vorhanden ist und ADSI das Schema erfolgreich verarbeitet, schreibt ADSI das Subschema auf den Datenträger und erstellt die beiden folgenden Registrierungswerte unter dem Schlüssel. Wenn die Unterschemadaten vorhanden sind, aber nicht verarbeitet werden können, wird keiner der folgenden Registrierungswerte erstellt:

• Ein Time-Wert , der das modifyTimeStamp-Attribut enthält. Dieser Wert wird verwendet, um sicherzustellen, dass die Schemadaten aktuell sind und verhindert, dass die Schemadaten konstant neu geladen werden.
• Ein Dateiwert , der den Pfad enthält, zu dem ADSI die Schemadaten im Dateisystem speichert. Standardmäßig zwischenspeichert ADSI das Unterschema im <Verzeichnis systemroot>\SchCache mit einem Dateinamen, der dem Namen des LDAP-Servers entspricht.

Wenn die Unterschemadaten verarbeitet werden können, aber kein modifyTimeStamp-Attribut verfügbar gemacht wird, werden die Schemadaten im Arbeitsspeicher zwischengespeichert, aber nicht auf den Datenträger geschrieben. Wenn ein LDAP v3-Server über ADSI auf dem lokalen Computer kontaktiert wurde und kein zwischengespeichertes Unterschema vorhanden ist, hat dies höchstwahrscheinlich einen der folgenden Gründe:

• Der Server hat die richtigen Eigenschaften nicht verfügbar gemacht.
• ADSI konnte das Schema nicht verarbeiten.
• ADSI konnte die Datei nicht in das Dateisystem schreiben.