Administration de Windows

Extension du schéma Active Directory

Vikas Malhotra

Vue d'ensemble:

• Comprendre le schéma Active Directory par défaut
• Ajout d'objets classSchema ou attributeSchema
• Obtention et utilisation d'identificateurs d'objets
• Extension du schéma à l'aide de fichiers .ldif

Télécharger le code de cet article: Schema2008_05.exe (151KB)

Depuis l'introduction d'Active Directory lors de la publication de Windows 2000, Microsoft a fourni à ses clients la définition de schéma de base pour l'implémentation d'Active Directory.

La présence d'Active Directory® a également marqué un tournant dans la façon dont de nombreuses applications étaient écrites et implémentées sur Windows®. Auparavant, les applications telles que Microsoft® Echange 5.5 étaient créées de sorte à contenir leur propre structure d'annuaire. Avec l'introduction d'Active Directory, un grand nombre d'applications (Microsoft et autres) ont commencé à tirer parti de la structure sous-jacente qu'il proposait au lieu de créer entièrement leur propre schéma.

Ces applications ont commencé avec l'architecture de base fournie par Active Directory qu'elles ont ensuite étendue en fonction des besoins. Microsoft Exchange 2000, par exemple, utilisait Active Directory pour l'implémentation de la messagerie, définissant ainsi l'avenir de l'architecture de messagerie Microsoft.

Aujourd'hui, de nombreuses applications écrites pour fonctionner dans un environnement Active Directory s'appuient sur son schéma sous-jacent pour fonctionner, et beaucoup définissent également leurs propres modifications du schéma en fonction des besoins. Cela nécessite bien entendu un schéma capable d'extension, comme nous le verrons dans cet article. Par ailleurs, dans la mesure où un grand nombre d'applications dépendent des définitions de base d'Active Directory, la stabilité constante du schéma de base revêt une importance critique. Comme de nombreuses applications doivent fonctionner côte à côte dans le même Active Directory, les modifications effectuées sur une application ne doivent pas avoir d'impact sur les autres.

Qu'est-ce qu'un schéma ?

Pour beaucoup de gens, le schéma Active Directory est une boîte noire, et l'idée de modifier le schéma tout seul peut être effrayante. Vous n'aurez certes pas à étendre votre schéma Active Directory tous les jours, mais vous risquez de devoir le faire pour certaines applications ou en réponse à certains besoins de l'entreprise. Il est donc très important de savoir ce qu'est un schéma et ce qu'il contient, puisque pour un grand nombre d'organisation, Active Directory est un actif vital dont la défaillance en raison d'une mise à jour inexacte peut avoir des conséquences considérables.

La stratégie d'un grand nombre d'organisations consiste à utiliser le service ADLDS (Active Directory Lightweight Directory Service) de Windows Server® 2008 (ou ADAM [Active Directory Application Mode] dans Windows Server 2003) comme alternative pour tester ou implémenter directement les définitions de schéma personnalisées au lieu d'étendre le schéma Active Directory.

Un schéma est la structure sous-jacente qui fournit le format d'un service d'annuaire. Le schéma Active Directory définit les classes et attributs d'objet qui sont utilisés dans ADDS (Active Directory Domain Services). Le schéma de base fournit des définitions pour plusieurs classes (telles qu'utilisateur, ordinateur et organizationalUnit) et attributs (par exemple, telephoneNumber et objectSID) bien connus. Les objets présents dans la définition du schéma de base sont connus en tant qu'objets de Catégorie 1 et les objets qui sont ajoutés sont des objets de Catégorie 2.

Un schéma Active Directory se trouve dans le conteneur défini au chemin cn=Schema, cn=Configuration,dc=X, X étant l'espace de noms de la forêt Active Directory. Notez qu'une forêt Active Directory contient juste un seul schéma ; la modification de la définition du schéma dans une forêt a un impact sur tous les domaines de cette forêt. La figure 1 illustre le nombre de classes et d'attributs qui sont ajoutés au schéma Active Directory dans différentes versions de Windows Server.

Figure 1 Nombre de classes et d'attributs

La mise à jour du schéma pour différentes versions de Windows Server se fait à l'aide d'un utilitaire appelé Adprep. Avec les mises à jour pour Windows Server 2003 R2, la version du schéma passe à 31, et passe à 44 avec Windows Server 2008.

Vous pouvez consulter ces changements en vérifiant la valeur de l'attribut objectVersion de cn=Schema,cn=Configuration,dc=X dans votre Active Directory en utilisant un outil tel qu'ADSIEdit. Notez que certaines applications telles qu'Exchange Server, System Management Server (SMS) ou d'autres applications qui dépendent d'Active Directory peuvent modifier le schéma en fonction de leurs besoins.

Éléments constitutifs

Active Directory consiste en deux types d'objets : ClassSchema (abrégé en classe) et attributeSchema (abrégé en attribut). L'extension du schéma Active Directory est généralement envisagée lorsqu'une organisation veut stocker des données dans des attributs qui ne sont pas disponibles dans le schéma existant. Vous créez un attribut dans un schéma Active Directory en spécifiant tout d'abord un objet attributeSchema dans le conteneur de schéma et en définissant ensuite les propriétés nécessaires du nouvel objet.

Vous trouverez une liste des propriétés des objets attributeSchema ainsi que des informations à leur sujet à l'adresse go.microsoft.com/fwlink/?LinkId=110445. Comme vous le voyez, un grand nombre de propriétés peuvent être définies pour les objets attributeSchema ; plusieurs de ces propriétés sont requises.

En dehors des attributs habituels, il existe également dans un schéma des attributs spéciaux, appelés attributs liés, qui sont implémentés par paires en fournissant un lien avant et un lien arrière. À titre d'exemple, considérons l'appartenance à un groupe dans Active Directory. L'attribut Member de n'importe quel groupe (par exemple un groupe appelé ContosoEmployees possédant un membre appelé John Doe) est le lien avant, et l'attribut memberOf correspondant de l'objet membre est le lien arrière (si bien que, par exemple, lorsque l'attribut memberOf de John Doe est interrogé, le nom unique du groupe ContosoEmployees est calculé).

Le lien avant se comporte généralement comme tous les autres attributs. Les valeurs peuvent être uniques ou multiples (comme avec l'attribut Member, qui peut contenir plusieurs objets comme membres d'un groupe) et sont stockées avec l'objet parent dans l'annuaire.

Les liens arrière, en revanche, sont maintenus par le système pour assurer l'intégrité référentielle. Lorsque vous demandez la valeur d'un attribut de lien arrière, les résultats sont calculés à partir de toutes les valeurs de lien avant correspondantes. Les liens arrière possèdent toujours plusieurs valeurs.

Chaque classe d'objet d'ADDS est définie par un objet classSchema dans le conteneur de schéma. Vous trouverez une liste des attributs essentiels à la bonne définition de l'objet classSchema à l'adresse go.microsoft.com/fwlink/?LinkId=110445.

Il existe trois types de classe pouvant être spécifiés : les classes structurelles, abstraites et auxiliaires. Ces classes sont définies par la valeur de l'attribut objectClassCategory. (Une quatrième catégorie, appelée 88, inclut les classes définies avant les normes X.500 de 1993. Ce type de classe est spécifié par une valeur 0 dans l'attribut objectClassCategory. Ce type de classe ne devrait plus être défini).

Obtention et utilisation d'identificateurs

L'identité de chaque objet classSchema et attributeSchema de l'annuaire est définie à l'aide d'un identificateur d'objet (OID) obligatoire qui est défini par rapport à governsID pour les objets classSchema, et à attributeID pour les objets attributeSchema. Il s'agit de valeurs numériques uniques fournies par certaines autorités émettrices pour identifier les objets. La numérotation est régie par la définition du protocole LDAP (RFC 2251). Certains OID du schéma Active Directory sont émis par l'Organisation internationale de normalisation (ISO) et d'autres sont émis par Microsoft. Un OID doit être unique pour un objet au sein de l'annuaire.

L'OID est une chaîne de chiffres, par exemple 1.2.840.113556.1.y.z, comme illustré à la figure 2. Ainsi, l'OID d'un objet classSchema utilisateur, par exemple, est 1.2.840.113556.1.5.9.

Figure 2 Identificateur pour l'objet utilisateur

Lorsqu'une organisation envisage d'étendre le schéma, elle s'assure que l'OID est unique en obtenant son propre numéro racine OID, qui est ensuite utilisé pour fournir des références uniques aux nouveaux attributs et classes d'objet créés par l'organisation. La racine OID peut être obtenue directement auprès d'une NRA (National Registration Authority) reconnue par l'Organisation internationale de normalisation ; aux États-Unis, il s'agit de l'ANSI (American National Standards Institute).

Vous pouvez obtenir une documentation sur la procédure et les frais d'obtention d'un OID racine sur ansi.org. Pour les autres régions, contactez l'organisation membre d'ISO correspondante ; ISO propose une liste à l'adresse iso.org/iso/about/iso_members.htm.

Les organisations pouvaient auparavant obtenir un OID de Microsoft en envoyant un message électronique à schemreg@microsoft.com. Toutefois, elles n'obtiennent désormais plus qu'une réponse automatique les invitant à télécharger et exécuter le VBScript de la page go.microsoft.com/fwlink/?LinkId=110453.

Pour les OID émis par Microsoft, le numéro est attribué sous l'espace de numéros OID de Microsoft : 1.2.840.113556.1.8000.x, x étant un numéro unique attribué à l'organisation. L'organisation peut ensuite diviser ces OID pour spécifier les objets. Ainsi une organisation pourrait utiliser 1.2.840.113556.1.8000.x.1.y pour les nouveaux objets classSchema et 1.2.840.113556.1.8000.x.2.z pour les objets attributeSchema (x représentant le numéro unique de l'organisation et y et z, respectivement, les numéros attribués aux objets classSchema et attributeSchema spécifiques). Il est également recommandé d'utiliser un préfixe spécifique à l'organisation dans les noms de ces objets pour les distinguer.

Définition des attributs liés

Il est important que la valeur attributeSyntax d'un lien avant soit 2.5.5.1, 2.5.5.7 ou 2.5.5.14. Ces valeurs correspondent aux syntaxes qui contiennent un nom unique, telles que la syntaxe Object (DS-DN).

La valeur attributeSyntax d'un lien arrière doit être 2.5.5.1, qui correspond à la syntaxe Object (DS-DN). Par convention, des attributs de lien arrière sont ajoutés à la valeur mayContain de la classe abstraite supérieure. Ceci permet à l'attribut de lien arrière d'être lu depuis des objets de n'importe quelle classe puisque les attributs de lien arrière ne sont pas, réellement stockés avec l'objet ; au lieu de cela, ils sont calculés en fonction des valeurs de lien avant.

Windows Server 2003 a introduit une fonctionnalité que les organisations peuvent utiliser pour relier deux objets dans un schéma : la génération automatique de linkID. Avec cette fonctionnalité, le système génère automatiquement un linkID pour un nouvel attribut lié lorsque l'attribut linkID de l'attribut est défini sur 1.2.840.113556.1.2.50. Un lien arrière correspondant est créé en définissant linkID sur l'attribut attributeId ou ldapDisplayName du lien avant. Le cache du schéma doit être rechargé après la création du lien avant et avant la création du lien arrière. À défaut, les attributs attributeId ou ldapDisplayName du lien avant ne seront pas trouvés lorsque le lien arrière sera créé. Le cache du schéma est rechargé à la demande, quelques minutes après une modification du schéma ou au redémarrage du contrôleur de domaine.

Si votre Active Directory est au niveau Windows 2000, vous devrez demander des linkID à Microsoft en envoyant un message électronique à schemreg@microsoft.com. Dans la réponse automatique, vous verrez cette ligne : « E-mails sent to schemreg@microsoft.com will be processed only if they are related to linkID registrations for legacy environments. » (Les messages électroniques envoyés à schemreg@microsoft.com ne seront traités que s'ils sont liés aux enregistrements de linkID pour les environnements hérités.) Vous devez alors inclure les informations suivantes dans le message électronique : nom de l'entreprise, nom de contact, adresse de messagerie, numéro de téléphone, préfixe enregistré (le cas échéant), OID enregistré (le cas échéant).

Prêt à étendre le schéma

Supposons que vous ayez décidé d'étendre votre schéma Active Directory. Cette analyse peut avoir nécessité de ne pas tenir compte de l'usage d'un annuaire alternatif implémenté à l'aide d'ADLDS (ou ADAM dans Windows Server 2003) après qu'il eut été établi qu'il ne répondrait pas aux besoins. Vous avez ensuite identifié les nouveaux objets attributeSchema que vous souhaitez ajouter au schéma et, ce faisant, vous avez défini toutes les valeurs requises (cn, ldapDisplayName, et ainsi de suite) qui spécifient ces nouveaux objets. En définissant les valeurs d'attribut de l'objet, vous avez également obtenu l'OID auprès de Microsoft ou d'une autre source. Vous avez essentiellement documenté les éléments ci-dessus en tant qu'exigences métier et spécifications techniques. En outre, vous avez également implémenté un environnement de laboratoire qui imite votre Active Directory et est prêt pour les tests.

Un grand nombre d'organisations créent des comités dont la mission est d'approuver ou de refuser ce type de modifications, et de définir le processus à suivre pour leur implémentation. Ces organes de régulation sont d'une importance cruciale dans la mesure où Active Directory est utilisé comme source d'informations faisant autorité dans de nombreuses organisations, et où il est donc essentiel de le maintenir en état de fonctionnement après que les modifications ont été effectuées.

Une fois que l'organisation donne le feu vert, vous devez mettre en place des plans de test et d'implémentation du projet. Vous pouvez étendre le schéma en ajoutant les nouveaux objets à l'aide du composant logiciel enfichable du schéma d'Active Directory dans la console Microsoft Management Console (MMC) ou en utilisant des méthodes par programmation ou semi programmation pour étendre le schéma (par exemple en utilisant LDIFDE pour importer des fichiers au format .ldif, CSVDE pour importer des fichiers au format .csv ou avec des scripts ADSI).

Quelle que soit la méthode que vous utilisez, cette fonction doit être exécutée sur un serveur qui est connecté au rôle (ou joue le rôle de) FSMO (flexible single master operations) du contrôleur de schéma dans la forêt Active Directory. En outre, le compte que vous utilisez pour la mise à jour du schéma nécessite des privilèges administratifs suffisants pour effectuer la mise à jour. Faites-en donc un membre du groupe Administrateurs du schéma. Enfin, vous devez activer les mises à jour du schéma pour la forêt (qui sont désactivées par défaut).

À moins que la modification ne soit très simple, elle doit être effectuée en mode automatisé afin d'encourager la normalisation entre les phases d'implémentation de test et de production, et de réduire les erreurs que vous risquez de provoquer si vous exécutez ces étapes manuellement. Supposons que vous décidez d'implémenter votre modification à l'aide de LDIFDE. Pour appliquer les mises à jour lors de l'extension du schéma, vous ajoutez normalement les nouveaux attributs et les nouvelles classes, puis ajoutez les nouveaux attributs aux classes et vous déclenchez enfin une recharge du cache. Examinons quelques scénarios.

Ajout d'attributs

Supposons, à titre d'exemple, qu'une organisation appelée Contoso souhaite ajouter à son Active Directory un attribut qui identifie la pointure de chaque employé. La forêt Active Directory comporte deux domaines : contoso.com et employees.contoso.com. La condition requise est que tous les objets créés à l'aide de la définition de classe utilisateur contiennent également ce nouvel attribut.

Il est important de ne pas oublier que la modification du schéma aura un effet sur les deux domaines puisqu'ils se trouvent dans la même forêt. Supposons que vous avez reçu l'OID 1.2.840.113556.8000.9999 de Microsoft et que vous l'avez divisé en 1.2.840.113556.8000.9999.1 pour les objets classSchema et 1.2.840.113556.8000.9999.2 pour les objets attributeSchema pour Contoso. Vous allez maintenant définir toutes les valeurs d'attribut pour ce nouvel objet, comme illustré à la figure 3.

Figure 3 Définition de l'attribut contosoEmpShoe

Par ailleurs, bien que l'attribut contosoEmpShoe doive être disponible pour tous les objets créés en tant qu'objets de classe utilisateur, il n'est pas recommandé de modifier la définition par défaut de la classe utilisateur. Au lieu de cela, vous devez définir une classe auxiliaire appelée contosoUser dont la valeur mayContain est spécifiée par contosoEmpShoe, comme illustré à la figure 4. Vous ajoutez ensuite les attributs définis pour la classe auxiliaire contosoUser à la classe utilisateur.

Figure 4 Définition de la classe contosoUser

Maintenant que vous avez effectué l'analyse et défini les valeurs, il est temps de créer le fichier .ldif qui ressemblera au code de la figure 5. Vous pouvez copier le contenu de la figure 5 dans le Bloc-notes et enregistrer le fichier sous contosoUser.ldif (vous pouvez également obtenir une copie dans le téléchargement de code sur technetmagazine.com).

Figure 5 Fichier .ldif pour étendre votre schéma

#Attribute definition for contosoEmpShoe

dn: CN=contosoEmpShoe,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: top
objectClass: attributeSchema
cn: contosoEmpShoe
attributeID: 1.2.840.113556.1.8000.9999.2.1
attributeSyntax: 2.5.5.12
isSingleValued: TRUE
adminDisplayName: contosoEmpShoe
adminDescription: contosoEmpShoe
oMSyntax: 64
searchFlags: 1
lDAPDisplayName: contosoEmpShoe
systemOnly: FALSE

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

# Classes

dn: CN=contosoUser,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: top
objectClass: classSchema
cn: contosoUser
governsID: 1.2.840.113556.1.8000.9999.1.1
mayContain: contosoEmpShoe
rDNAttID: cn
adminDisplayName: contosoUser
adminDescription: contosoUser
objectClassCategory: 3
lDAPDisplayName: contosoUser
name: contosoUser
systemOnly: FALSE

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

dn: CN=User,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemamodify
add: auxiliaryClass
auxiliaryClass: contosoUser
-

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1

Après avoir généré le fichier .ldif, vous devrez tester intégralement l'implémentation dans un environnement de laboratoire, vérifier la réplication de bout en bout de votre domaine et de votre forêt, et activer la mise à jour du schéma dans la forêt. À ce stade, vous devez ouvrir une session avec un compte doté des privilèges Administrateur du schéma. En outre, vous voudrez probablement désactiver la réplication sortante sur le contrôleur de schéma (dans lequel sera faite la modification) puis exécuter la commande suivante pour importer le fichier .ldif :

ldifde –i –f <Path>\contosoUser.ldif –b
<username> <domain> <password> -k –j. –c
"CN=schema,CN=Configuration,DC=X"
#schemaNamingContext

Une fois la modification effectuée, activez la réplication sortante sur le contrôleur de schéma et vérifiez que la réplication a eu lieu pour tous les contrôleurs de domaine.

Respirez un grand coup, vous avez terminé !^ Vous avez défini dans le schéma un nouvel attribut qui sera associé aux objets créés à l'aide de la classe utilisateur (c'est-à-dire les comptes utilisateur).

Pour vérifier ce changement, ouvrez Utilisateurs et ordinateurs Active Directory, connectez-vous au domaine employees.contoso.com, accédez à l'unité d'organisation (UO) Utilisateurs et créez un nouveau compte utilisateur appelé ContosoTestUser. À présent, ouvrez la console adsiedit.msc et connectez-vous à la partition de domaine dc=employees,dc=contoso,dc=com, développez l'UO Utilisateurs, cliquez avec le bouton droit sur ContosoTestUser et ouvrez la page Propriétés. Allez à l'attribut contosoEmpShoe. Vous pouvez modifier cet attribut et y entrer une valeur. Vous pouvez également utiliser l'utilitaire Ldp.exe pour vérifier et modifier les attributs.

Examinons maintenant un exemple qui définit et relie deux attributs, et imaginons un scénario où Contoso accorde une grande importance à la pointure des employés et souhaite effectuer une sorte de suivi des performances annuelles des employés qui mesurent les pointures au sein de l'entreprise. Ce scénario semble cocasse, certes, mais supposons que Contoso souhaite non seulement connaître le nom des personnes chargées de mesurer la pointure des employés, mais également le nom des employés dont la pointure a été mesurée et leur nombre, le tout en interrogeant un attribut. (Vous pensez probablement que ces données devraient être stockées dans des tables de base de données, mais l'idée ici est simplement d'expliquer le fonctionnement des liens avant et arrière).

Bien sûr, vous effectuerez d'abord le même type d'analyse que celui que j'ai décrit dans l'exemple précédent. Continuons toutefois, et créons les fichiers ldif linkids1.ldif et linkids2.ldif, comme illustré à la figure 6. Exécutons ensuite cette commande pour importer les fichiers .ldif :

Figure 6 Fichiers .ldif de liens avant et arrière

 
#linkids1.ldif
#Attribute definition for Forward Link Attribute

dn: CN=ContosoShoeSizeTaker,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: top
objectClass: attributeSchema
cn: ContosoShoeSizeTaker
attributeID: 1.2.840.113556.1.8000.9999.2.2
LinkID: 1.2.840.113556.1.2.50
attributeSyntax: 2.5.5.1
isSingleValued: TRUE
adminDisplayName: ContosoShoeSizeTaker
adminDescription: ContosoShoeSizeTaker
oMSyntax: 64
searchFlags: 1
lDAPDisplayName: ContosoShoeSizeTaker
systemOnly: FALSE

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

#Reload schema

#linkids2.ldif

#Attribute definition for Backward Link Attribute

dn: CN=ContosoShoeSizesTakenByMe,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: top
objectClass: attributeSchema
cn: ContosoShoeSizesTakenByMe
attributeID: 1.2.840.113556.1.8000.9999.2.3
LinkID: 1.2.840.113556.8000.9999.2.2
attributeSyntax: 2.5.5.1
isSingleValued: FALSE
adminDisplayName: ContosoShoeSizesTakenByMe
adminDescription: ContosoShoeSizesTakenByMe
oMSyntax: 64
searchFlags: 1
lDAPDisplayName: ContosoShoeSizesTakenByMe
systemOnly: FALSE

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

#Add ContosoShoeSizeTaker and ContosoShoeSizesTakenByMe Attribute as MayContain in 
#contosoUser class

dn: CN= contosoUser,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemamodify
add: mayContain
mayContain: ContosoShoeSizeTaker
mayContain: ContosoShoeSizesTakenByMe

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

#Add Backward Link Attribute as MayContain in Top

dn: CN=Top,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemamodify
add: mayContain
mayContain: ContosoShoeSizesTakenByMe

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1

ldifde –i –f <Path>\linkedids<>.ldif –b
<username> <domain> <password> -k –j. –c
"CN=schema,CN=Configuration,DC=X"
#schemaNamingContext

À présent, lorsqu'un objet utilisateur sera créé, il aura également ContosoShoeSizeTaker et ContosoShoeSizesTakenByMe comme attributs. Lors de la création de l'objet utilisateur pour, disons, John, l'attribut ContosoShoeSizeTaker est renseigné avec le nom unique de la personne qui a mesuré la pointure, à savoir Frank. Si vous allez dans les propriétés de l'objet utilisateur Frank et interrogez l'attribut ContosoShoeSizesTakenByMe, le résultat contiendra le nom unique John et le nom de tous les employés que Frank aura mesurés. Pour compléter notre scénario, la direction pourrait récompenser Frank en fonction du nombre de noms uniques existant dans l'attribut ContosoShoeSizesTakenByMe de son compte utilisateur.

Contrôles et vérifications du système

Une mise à jour critique telle que la modification du schéma ne peut pas être effectuée sans une vérification sérieuse des exigences architecturales. Ces contrôles de cohérence et vérifications de sécurité sont utilisés par Active Directory pour s'assurer que les modifications ne causent pas d'incohérence ou d'autres problèmes lorsqu'un ajout ou une modification sont apportés au schéma Active Directory.

Premièrement, la valeur governsID pour chaque classe doit être unique dans le schéma. Lorsque vous définissez un objet schemaClass, tous les attributs qui sont définis dans les listes systemMayContain, mayContain, systemMustContain et mustContain doivent déjà exister. Parallèlement, toutes les classes définies dans les listes subClassOf, systemAuxiliaryClass, auxiliaryClass, systemPossSuperiors et possSuperiors doivent également déjà exister.

En outre, l'objectClassCategory de toutes les classes des listes systemAuxiliaryClass et auxiliaryClass doit appartenir soit à la classe 88 soit à la classe auxiliaire. De même, l'objectClassCategory de toutes les classes des listes systemPossSuperiors et possSuperiors doit être spécifié soit en tant que classe 88 soit en tant que classe structurelle.

Lors de la définition de diverses classes, les classes abstraites peuvent hériter uniquement des autres classes abstraites, les classes auxiliaires ne peuvent pas hériter des classes structurelles et les classes structurelles ne peuvent pas hériter des classes auxiliaires. De plus, l'attribut spécifié dans l'attribut rDNAttID doit avoir une chaîne unicode comme syntaxe et avoir une valeur unique.

Il ne s'agit là que de quelques unes des règles qui régissent les objets classSchema. Mais qu'en est-il des objets attributeSchema ? Comme dans le cas de la valeur governsID pour les classes, la valeur attributeID doit être unique. De même, la valeur mAPIID, si elle existe, doit être unique. En outre, si rangeLower et rangeUpper sont présents, rangeLower doit être plus petit que rangeUpper. Les valeurs attributeSyntax et oMSyntax doivent correspondre. Si l'attribut est syntaxé objet (oMSyntax = 127), il doit avoir la bonne oMObjectClass. Le linkID, s'il existe, doit être unique. De plus, un lien arrière doit avoir un lien avant qui lui correspond.

Et si vous vous faites une gaffe ?

Une fois le schéma étendu avec les nouveaux objets (classes et attributs), ces derniers ne peuvent pas être supprimés. Cependant, une classe ou un attribut peut être désactivé en définissant l'attribut isDefunct sur TRUE sur l'objet de schéma. Vous ne pouvez pas désactiver les objets de schéma qui font partie du schéma par défaut fourni avec Active Directory (objets de Catégorie 1). Vous pouvez uniquement désactiver les objets qui ont été ajoutés au schéma par défaut, c'est-à-dire que seuls les objets de Catégorie 2 peuvent être désactivés et seulement une fois qu'Active Directory a vérifié que la classe n'est pas utilisée dans la liste subClassOf, auxiliaryClass ou possSuperiors d'une classe non défunte existante.

À chaque tentative visant à rendre un attribut défunt, Active Directory vérifie que l'attribut n'est pas utilisé dans le mustContain ou mayContain d'une classe non défunte existante. Vous pouvez réactiver les objets désactivés en définissant l'attribut isDefunct sur FALSE. Si votre Active Directory est au niveau Windows Server 2003, vous pouvez réutiliser les valeurs ldapDisplayName, schemaIdGuid, OID et mapiID de l'objet désactivé.

Conclusion

L'ajout ou la modification de définitions de classe ou d'attribut dans le schéma implique l'ajout ou la modification de l'objet classSchema ou attributeSchema correspondant. Ce processus est identique l'ajout ou la modification d'un objet dans Active Directory, à ceci près que des vérifications supplémentaires sont effectuées pour garantir que ces modifications ne causeront pas d'incohérence ou de problème dans le schéma à l'avenir.

Bien que la modification du schéma Active Directory ne soit pas compliquée, il est important de comprendre la formation du schéma et la façon dont il implémente ces modifications. La modification du schéma Active Directory de production nécessite une planification et une exécution soignées. Vous devez impérativement définir les exigences métier et spécifications techniques des nouveaux objets et effectuer de nombreux tests en laboratoire. Puisque les modifications peuvent avoir des effets profonds, il est recommandé de n'étendre le schéma Active Directory que lorsque cette opération est absolument nécessaire.

Vikas Malhotra travaille pour Microsoft Consulting Services à New York. Au cours des 12 dernières années, il a collaboré avec de nombreuses grandes et moyennes entreprises informatiques afin d'optimiser l'architecture de leur infrastructure, notamment au niveau des répertoires, de la messagerie, de la sécurité et des réseaux de données. Il possède une licence en électronique et télécommunications et une maîtrise en gestion des télécommunications. Vous pouvez le contacter à l'adresse vikasmal@microsoft.com.

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.