Active Directory Schema
The schema is the blueprint of AD DS,the schema defines every class and attribute that can be stored in AD DS. Before an object can be created in AD DS, its class must first be defined in the schema.There is one schema per forest,and a copy of the schema is replicated to every domain controller in the forest.To customize AD DS for use on a network, you can modify the schema to create new object types, add new attributes to existing object types, and modify the type of information installed on an attribute. To do this, use the MMC snap in called Active Directory Schema. Modifying the schema is subject to the same cautions as modifying a systems registry,improper schema modifications can have a devastating effect on the entire network.
Requirements for Modifying the AD DS schema
You can modify the schema on only one domain controller in the forest, and you can only modify the schema if your user account is a member of the Schema Admins group.This domain controller is the Schema Operations Master,the first domain controller deployed in a forest is the schema master. To make schema changes, you must be logged on to the Schema Operations Master, or you must be able to access the domain over the network. The Administrator account in the forest root domain is automatically made a member of the Schema Administrators group, but members of the Domain Admins group are not automatically part of the Schema Admins group.Users who are not members of this group can also modify the schema if an administrator has granted them the appropriate permissions to the schema object.
Launching Active Directory Schema
Because of the potential dangers, the Active Directory Schema snap in
is not added to the Administrative Tools on a domain controller by default. To use the
snap in you must first register the schmgmt.dll and then add the snap in to an MMC. To
launch Active Directory Schema, complete these steps:
1. To register the dll, open a command prompt, type Regsvr32 schmmgmt.dll, and then press Enter.
2. To add the Active Directory Schema to an MMC, click Start and select Run. Type mmc and press Enter.
3. On the File menu of the blank MMC console, click Add/Remove Snap in.
4. Click Active Directory Schema from the list of snap-ins provided, click Add, and then click OK. Before changing the schema, be sure that the schema snap in is connected to the domain controller that is currently functioning as the Schema Master. To connect to the schema operations master, right-click the Active Directory Schema object in the console tree and click Connect To Schema Operations Master from the shortcut menu.
The schema is made up of classSchema objects and attributeSchemaobjects. The classSchema objects are definitions that are stored in the schema and are used to define classes. Classes define groups of attributes that have something in common. The User class includes a variety of attributes, including the users logon name, first name, last name, and password.
The schema also defines the attributes that can be stored for each class. Attributes are defined globally in AD DS as attributeSchema objects, and each class can use multiple globally defined attributes. Each of these attributes is defined by attribute objects that also have their own definition that specifies information such as the type of data that they store and the minimum and maximum length or value. The directory service uses attributeSchema
objects to define the type of the data stored in attributes for each object of a given class and to enforce the constraints defined in the attributeSchema
The classSchema object specifies the attributes that are associated with the object. The specification includes all of the attributes that can be associated with the object, which can be broken into four categories:
mustContain attributes, which include mandatory attributes that must be present on any object that is an instance of this class
mayContain attributes, which include optional attributes that may be found on an object that is an instance of this class
systemmayContain attributes, which are optional attributes configured during object creation, and which cannot be modified after the object has been created
systemmustContain attributes, which are mandatory attributes configured during object creation, and which cannot be modified after the object has been created
Modifying the Schema
The process of modifying the AD DS schema involves creating or modifying the classes and attribute object types displayed in Schema Manager. Classes are collections of attributes that either form an AD DS object type by themselves or contribute certain attributes to another object type. The latter instance is known as an auxiliary class. To add attributes to an existing object type, the best method is to create a new class containing the new attributes and add it to the object type as an auxiliary. This method is more manageable and less dangerous than modifying the class representing the object type
Creating new attribute objects corresponding to the information fields you want to
add to the object
Creating a new class object to be used as an auxiliary to the existing object type
Adding the newly created attributes to the new auxiliary class
Adding the auxiliary class to the existing object class
Creating an attribute is a matter of supplying a name by which the attribute will be identified and specifying the type of data that will be stored there. The data can be text or numerical, and you can apply constraints that limit the data to a particular length or value type.To create an attribute
object, follow these steps:
1. Right-click the Attributes container in the Active Directory Schema console tree and click Create Attribute from the shortcut menu. This first produces a warning that creating an object permanently modifies the AD DS, and then it produces the Create New Attribute dialog box
2.In the Identification area, specify the name for the new object. The Common Name field should contain the name by which the attribute will be listed in standard dialog boxes, and the LDAP Display Name field should contain the name by which it is known in the LDAP directory hierarchy. Often these two names are the same. The Unique X.500 Object ID field must contain a numerical string that uniquely identifies the attribute object in the X.500 namespace. Standards organizations such as the International Telecommunications Union issue Object IDs (OIDs) to ensure that they have unique values.
3.In the Description box, fill in a description of the object and its function. In the Syntax And Range area, define the nature of the data to be stored in the attribute. The Syntax field provides more than a dozen options that define the types of information that can be stored in an attribute.
4. Click OK, and the the new attribute object is created.You can also configure the new attribute object by opening the Properties dialog box from the shortcut menu. From this window, you can specify a description for the object, modify its range of possible values, and enable any of the following options:
Deactivate this attribute
Index this attribute in Active Directory
Ambiguous Name Resolution (ANR)
Replicate this attribute to the Global Catalog (GC)
Attribute is copied when duplicating a user
Index this attribute for containerized searches in Active Directory
Creating Object Classes
Attribute objects by themselves are useless until they belong to an object class. You can add the attribute objects you created to an existing class, but creating a new class object for them is more practical. To create a class object, right-click the Classes container in the Active Directory Schema snap-in and choose Create Class from the shortcut menu. This displays the Create New Schema Class dialog
As with an attribute object, you must first specify a Common Name, an LDAP Display Name, and a Unique X.500 Object ID. In the Inheritance And Type area, specify the Parent Class for the new object and choose one of the following three class types:
Structural class: The typical directory objects you work with in programs such as Active Directory Users And Computers. A structural class object can have either an abstract class or another structural class as its parent object.
Abstract class: Objects from which structural class objects are derived. You can also specify an existing abstract class as the parent of a new abstract class object.
Auxiliary class: Collections of attributes you can add to either an abstract or structural class object to augment its capabilities. New auxiliary class objects can be derived only from abstract classes. To hold your new attributes, create an auxiliary class type
Adding Attributes to a Class
After you create the attribute objects and the class object to contain them, you must add the attributes to the class. You do this by opening the Properties dialog box for the newly created class object. The dialog box for a class object has four tabs, including the standard Default Security tab. On the General tab, supply a description for the object and specify whether the object class should show while browsing. You can also disable the object by deselecting the Class Is Active check box. In the Attributes tab, add your newly created attribute objects to the class by clicking Add for either the Mandatory or Optional list and then selecting the objects by name. When an attribute is mandatory, you must supply a value for the attribute when creating a new object of that class.
Adding an Auxiliary Class to a Structural Class
An auxiliary class object can not store attribute information until you add the auxiliary class object to a structural class object, such as a user or computer. To do this, open the structural class objects Properties dialog box and select the Relationship tab.On this tab, click Add Class for the Auxiliary Classes list, and select the class object you just created. This causes AD DS to add the attributes in the auxiliary class to the structural class. In the Possible Superior list, specify which other object classes can contain the current object class. For example, the user object class has the organizational unit object class in its Possible Superior list, which enables the creation of new users in OUs. The opposite is not true, you can not create an OU beneath a user, so the user object is not a possible superior of the OU object.