Modèle de schéma ADSI

Un schéma est similaire à un dictionnaire en ce qu’il contient la définition de chaque type d’objet connu d’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 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 les fonctionnalités prises en charge pour chaque service d’annuaire.

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

Notes

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 de 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 attribut modifyTimeStamp utilisé pour déterminer la dernière modification du schéma.

Lorsque ADSI se lie pour la première fois au serveur LDAP, il récupère les données de sous-schéma à l’aide de l’attribut subSchemaSubEntry . Si ADSI réussit à trouver l’objet de sous-schéma, il stocke un pointeur vers les données dans le 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 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 qu’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-schéma 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 garantir que les données de schéma sont actuelles et empêchent le rechargement constant des données de schéma.
• Valeur De 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>\SchCache avec un nom de fichier correspondant au nom du serveur LDAP.

Si les données du sous-schéma peuvent être traitées, mais qu’aucun attribut modifyTimeStamp n’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-schéma mis en cache n’est pas présent, c’est probablement pour l’une des raisons suivantes :

• 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.