Modèle de schéma ADSI

Un schéma est similaire à un dictionnaire dans lequel il contient la définition de chaque type d’objet connu pour un service d’annuaire. Les applications clientes ADSI peuvent parcourir un schéma pour découvrir les fonctionnalités d’une implémentation ADSI donnée. En outre, ADSI fournit des interfaces de gestion de schéma qui peuvent être utilisées pour communiquer avec le schéma sous-jacent d’un service d’annuaire.

Certains schémas sont extensibles et les fournisseurs ADSI ou fournisseurs tiers peuvent choisir de publier de nouvelles interfaces ou des propriétés supplémentaires pour les interfaces existantes. Les clients ADSI utilisent ces données pour déterminer quelles fonctionnalités sont prises en charge pour chaque service d’annuaire.

Il existe trois types d’objets de schéma : les classes, les propriétés et les syntaxes, chacun prenant respectivement en charge les interfaces de gestion des schémas IADsClass, IADsPropertyet IADsSyntax.

Note

La classe est un terme surchargé. Il existe des classes C++, des classes Java, des classes COM et des classes ADSI. Dans ce document, la classe word, sauf indication contraire, fait référence à une catégorie ou à un type d’objet de schéma.

 

ADSI extrait le schéma de chaque service d’annuaire et le place dans chaque nœud racine de niveau supérieur dans l’objet Namespace. Pour identifier les classes qu’un service d’annuaire prend en charge sur un nœud racine donné, vous énumérez l’objet de schéma et obtenez une liste d’objets de classe, d’objets de propriété et d’objets de syntaxe. Pour plus d’informations, consultez Utilisation du schéma ADSI.

Cache de schéma du fournisseur LDAP ADSI

Le fournisseur LDAP pour ADSI tente de mettre en cache les données de schéma sur l’ordinateur local. Un sous-schéma est identifié par un nom unique stocké dans l’attribut subSchemaSubEntry situé à la racine de l’entreprise de service d’annuaire (rootDSE). En plus de fournir les données de sous-schéma, les serveurs LDAP v3 doivent exposer un modifyTimeStamp attribut utilisé pour déterminer la dernière fois que le schéma a été modifié.

Lorsque ADSI se lie d’abord au serveur LDAP, il récupère les données de sous-schéma à l’aide de l’attribut subSchemaSubEntry. Si ADSI réussit à rechercher l’objet subschema, il stocke un pointeur vers les données du Registre sur l’ordinateur qui se connecte au serveur LDAP. Pour plus d’informations sur l’emplacement exact où ces valeurs sont stockées dans le Registre, consultez ADSI et le contrôle de compte d’utilisateur.

ADSI tente ensuite de traiter les données de schéma et lit l’attribut modifyTimeStamp. Si l’attribut modifyTimeStamp existe et ADSI traite correctement le schéma, ADSI écrit le sous-schéma sur le disque et crée les deux valeurs de Registre suivantes sous la clé. Si les données de sous-plan existent, mais ne peuvent pas être traitées, aucune de ces valeurs de Registre n’est créée :

• Valeur Time, qui contient l’attribut modifyTimeStamp. Cette valeur est utilisée pour s’assurer que les données de schéma sont actuelles et empêche le rechargement constant des données de schéma.
• Valeur Fichier, qui contient le chemin d’accès à l’emplacement où ADSI stocke les données de schéma dans le système de fichiers. Par défaut, ADSI met en cache le sous-schéma dans le répertoire systemroot <systemroot>\SchCache avec un nom de fichier correspondant au nom du serveur LDAP.

Si les données de sous-schéma peuvent être traitées, mais qu’aucune modifyTimeStamp attribut est exposé, les données de schéma sont mises en cache en mémoire, mais pas écrites sur le disque. Si un serveur LDAP v3 a été contacté via ADSI sur l’ordinateur local et qu’un sous-plan mis en cache n’est pas présent, il est probable que l’une des raisons suivantes soit :

• Le serveur n’a pas exposé les propriétés correctes.
• ADSI n’a pas pu traiter le schéma.
• ADSI n’a pas pu écrire le fichier dans le système de fichiers.