Active Directory Schema Version. Schema master — Active Directory schema master

A directory service is used to identify users and resources on a network. Compared to previous versions of Windows Microsoft Windows In 2003, Active Directory capabilities have been significantly expanded. Active Directory provides a unified network management tool that makes it easy to add, remove, and move users and resources.

Introducing Active Directory

Active Directory tools allow you to design the directory structure to suit your organization. In this lesson, you will become familiar with the use of Active Directory objects and the purpose of its components.

After studying the material in this lesson, you will be able to:

explain the purpose of Active Directory object and schema attributes;

Define and describe the functions of Active Directory components.

Active Directory Objects

Like all services that make information accessible and useful, Active Directory stores information about network resources. These resources, such as user data, descriptions of printers, servers, databases, groups, computers, and security policies, are called objects.

An object is a single named set of attributes that represent a network resource. The attributes of an object are its characteristics in the directory. For example, user account attributes may include the user's first and last name, department, and address. email(Figure 2-1)

In Active Directory, objects can be organized into classes, that is, into logical groups. An example of a class is a collection of objects representing user accounts, groups, computers, domains, or organizational units (OUs).

Note Objects that are capable of containing other objects are called containers. For example, a domain is a container object that can contain users, computers, and other objects.

What objects can be stored in Active Directory is determined by its schema.

SchemeActiveDirectory

An Active Directory schema is a list of definitions that define the types of objects that can be stored in Active Directory and the types of information about them. These definitions themselves are also stored as objects, so Active Directory manages them using the same operations that are used for other objects in Active Directory.

There are two types of definitions in a schema: attributes and classes. They are also called schema objects or metadata.

Attributes are defined separately from classes. Each attribute is defined only once and can be used in multiple classes. For example, the Description attribute is used in many classes, but it is defined only once in the schema, which ensures its integrity.

Classes, also called object classes, describe what Active Directory objects can be created. Each class is a collection of attributes. When an object is created, attributes store information that describes it. For example, attributes of the User class include Network Address, Home Directory, etc. Each object in Active Directory is an instance of an object class.

Windows 2000 Server has a built-in set of base classes and attributes. By defining new classes and new attributes for existing classes, experienced developers and network administrators can dynamically extend the schema. For example, if you need to store information about users that is not defined in the schema, you can extend the schema for the Users class. However, such an expansion of the scheme is a rather complex operation with possible serious consequences. Because the schema cannot be deleted, only deactivated, and is automatically replicated, you must prepare and plan for its expansion.

As you know, nothing lasts forever, everything changes, especially in an industry like IT. Once deployed, the infrastructure is constantly evolving, expanding, improving, and there comes a time when you need to introduce a domain controller running a later version into your Active Directory operating system.

It would seem - what is the problem? But, as practice shows, problems arise largely due to the fact that system administrators have little knowledge of the theory and are frankly confused in this matter. Therefore, it's time to figure out what it is AD scheme and how it relates to our case.

AD circuit is called a description of all directory objects and their attributes. Essentially the diagram reflects basic structure directory and is of paramount importance for its proper functioning.

New OS versions contain new objects and attributes, so for them normal functioning as domain controllers we will need to update the schema.

It seems clear, but not entirely, so let’s move on to common mistakes and misconceptions.

• Updating the schema is necessary to include PCs running newer versions of Windows into the domain. This is not true, even the most recent ones Windows versions can work quite successfully in the domain Windows level 2000 without schema update. Although, if you do update the scheme, then nothing bad will happen.

• To include a controller running a newer OS into a domain, you need to upgrade the domain (forest). This is also not true, but unlike the previous case, this operation will make it impossible to use domain controllers running an OS lower than its operating mode. Therefore, in case of an error, you will have to restore your AD structure from a backup.

We will also draw your attention to the operating mode of the forest and domain. Domains included in the forest may have different operating modes, for example, one of the domains may operate in Windows mode 2008, and the rest in Windows 2003 mode. The forest operating scheme cannot be higher than the operating scheme of the oldest domain. In our example, the forest operating mode cannot be higher than Windows 2003.

At the same time, the lower operating mode of the forest does not in any way prevent the use of a higher operating mode in the domain; all that is required for this is to update the schema.

Having familiarized ourselves with the theory, let's move on to a practical example. Let's say we have a Windows 2000 level domain (mixed mode) - the most low level AD - which has a controller under Windows control 2003, and our goal is to create a new controller to replace the failed one.

The new server runs Windows 2008 R2. Please note that we did not have any difficulties in enabling of this server to an existing domain.

In our case, all roles are on the same controller, so we copy the folder \support\adprep on hard drive(in our case to the root of the C: drive) and proceed to updating the forest schema. To successfully complete the operation, your account must be included in the following groups:

• Schema Administrators
• Enterprise administrators
• Administrators of the domain in which the schema owner is located

To update the forest schema, run the command:

C:\adprep\adprep /forestprep

Read the standard warning and continue by clicking C, then Enter.

The schema update process will begin. As you can see, its version will change from 30 (Windows 2003) to 47 (Windows 2008 R2).

After updating the forest schema, you must update the domain schema. Before doing this, you should make sure that the domain is running at least in Windows 2000 mode (native mode). As we remember, our domain operates in mixed mode, so we should change the domain operating mode to primary or upgrade it to Windows 2003. Since in this domain we do not have controllers running Windows 2000, it would be most reasonable to upgrade the domain mode.

To successfully update the domain schema, this operation should be performed on Infrastructure owner and have rights Domain Administrator. We execute the command:

C:\adprep\adprep /domainprep

And carefully read the information displayed. When upgrading a domain schema from Windows 2000 or Windows 2003, you must change permissions file system for group policies. This operation is performed once and in the future, for example, updating the schema from the 2008 level to 2008 R2, it must be performed. To update GPO permissions, enter the command:

C:\adprep\adprep /domainprep /gpprep

In AD versions starting from Windows 2008 appeared new type Domain Controllers: Read Only Domain Controller (RODC), if you are planning to deploy such a controller then you need to prepare a schematic. In general, we recommend doing this operation regardless of whether you are going to install RODC in the near future or not.

This operation can be performed on any domain controller, but you must be a member of the Enterprise administrators And Master of naming And Infrastructure Master must be available.

C:\adprep\adprep /rodcprep

As you can see, updating the domain schema, if properly planned, does not cause any difficulties, however, in any case, you should remember that this is an irreversible operation and have the necessary backup copies on hand.

Since the release of Active Directory with Windows 2000, Microsoft has provided users with a definition of the basic schema for implementing Active Directory.

The release of Active Directory® also marked a change in the way many applications were written and implemented on Windows®. Previously, applications such as Microsoft® Exchange 5.5 were built with their own directory structure. Since the introduction of Active Directory, many applications (from Microsoft and other companies) have begun to take advantage of the underlying structure provided rather than creating their own schema from scratch.

Initially, the base architecture provided by Active Directory was used, which was then extended as necessary. Microsoft Exchange 2000, for example, used Active Directory to implement messaging systems, thereby defining the future of Microsoft messaging architecture.

Today, many applications built to run in an Active Directory environment rely on its basic design, and many applications also define the necessary own changes schemes. To do this, of course, you need a circuit that can be expanded, which will be discussed in this article. Moreover, since many applications depend on underlying definitions in Active Directory, continued stability of the underlying schema is critical. Because many applications must work together in the same Active Directory, changes to one application should not affect other applications.

What is a schema?

For many people, the Active Directory schema is a bit of a black box, and the idea of ​​changing the schema themselves can be daunting. Of course, extending the Active Directory schema isn't something you need to do every day, but some applications or businesses require it. Therefore, it is very important to understand the nature of the scheme and its composition, since Active Directory is an important asset for many organizations, the failure of which due to an incorrect update can have serious consequences.

As a strategy, many organizations use Active Directory Lightweight Directory Services (ADLDS) to Windows Server® 2008 (or Active Directory Application Mode (ADAM) in Windows Server 2003) as an alternative for testing or directly implementing custom schema definitions instead of extending the Active Directory schema.

A schema is a basic structure that provides a format for a directory service. The Active Directory schema defines the attributes and object classes used in Active Directory Domain Services (ADDS). The core schema contains definitions for many well-known classes (such as user, computer, and organizationalUnit) and attributes (such as telephoneNumber and objectSID). The objects in the main schema definition are called category 1 objects, and the objects that are added are called category 2 objects.

The Active Directory schema is located in a container defined by the path cn=Schema, cn=Configuration,dc=X, where X is the namespace of the Active Directory forest. Keep in mind that an Active Directory forest only contains one schema; Making changes to a schema definition in a forest affects all domains in that forest. On rice. 1 shows the number of classes and attributes added to the Active Directory schema in different versions of Windows Server.

Number of classes and attributes

Updating the schema for different versions Windows Server is implemented using the Adprep utility. When you upgrade to Windows Server 2003 R2, the schema version is updated to 31, and when you upgrade to Windows Server 2008, it is updated to 44.

You can find the version number by checking the value of the objectVersion attribute at cn=Schema,cn=Configuration,dc=X in Active Directory using a tool such as ADSIEdit. Note that some applications, such as Exchange Server, System Management Server (SMS), and other Active Directory-dependent applications, may change the schema to suit the application's requirements.

Basic components

Active Directory consists of two types of objects: classSchema (class for short) and attributeSchema (attribute for short). Typically, an Active Directory schema extension is considered if the organization needs to store data in certain attributes that are not available in the existing schema. An attribute in a Directory schema is created by specifying an attributeSchema object in the schema container and then defining the required properties of the new object.

For a list of attributeSchema object properties and information, see go.microsoft.com/fwlink/?LinkId=110445. As you can see, you can define a large number of properties for attributeSchema objects, some of which are required.

In addition to regular attributes, the schema also contains special attributes called linked attributes, which are implemented in pairs by specifying forward and backward links. As an example, consider group membership in Active Directory. The membership attribute of any group (for example, a ContosoEmployees group with member John Doe) is a forward link, and the corresponding memberOf attribute of a member object is a back link (so that when the memberOf attribute of member John Doe is queried, the distinguished name (DN) of the ContosoEmployees group is calculated).

The forward link works the same way as any other attribute. The values ​​can be single-valued or multi-valued (like the membership attribute, which can contain multiple objects as members of a group) and are stored in the directory along with the parent object.

Backlinks, on the other hand, are maintained by the system to ensure data integrity. When a back link attribute value is queried, the result is calculated based on all corresponding forward link values. Backlinks are always ambiguous.

All object classes in ADDS are defined by a classSchema object in the schema container. For a list of the attributes that are most important to successfully defining a classSchema object, see go.microsoft.com/fwlink/?LinkId=110445.

There are three types of classes that can be defined: structural, abstract, and utility. The class type is determined by the value of the objectClassCategory attribute. (The fourth category, known as 88, includes classes defined before the 1993 X.500 standards. This class type is indicated by a value of 0 in the objectClassCategory attribute. This type should no longer be defined.)

Obtaining and using identifiers

The identities of all classSchema and attributeSchema objects in the directory are defined using required object identifiers (OIDs), governsID for classSchema objects and attributeID for attributeSchema objects. These are unique numeric values ​​provided by specific centers to identify objects. Numbering is in accordance with the definition of the LDAP protocol (RFC 2251). Some object identifiers in the Active Directory schema are issued by the International Organization for Standardization (ISO) and Microsoft. The object identifier in the directory must be unique.

The object ID is a string of numbers, for example 1.2.840.113556.1.y.z, as shown in rice. 2. So the classSchema user object ID is 1.2.840.113556.1.5.9.

User object ID

When an organization wants to extend a schema, it ensures that the object identifier is unique by obtaining its own root OID number, which is used to create unique identifiers for the organization's new attributes and object classes. The object identifier root can be obtained directly from the ISO national registration office (in the US, the American National Standards Institute (ANSI)).

The procedure and service fees for obtaining the root object ID can be found at ansi.org. In other regions, contact the appropriate ISO member organization, which is listed at iso.org/iso/about/iso_members.htm.

Previously, organizations received an object ID from Microsoft by sending an email to [email protected]. However, this now results in an automated response asking you to download and run the VBScript from go.microsoft.com/fwlink/?LinkId=110453.

Object identifiers issued by Microsoft are assigned numeric identifier space numbers Microsoft objects: 1.2.840.113556.1.8000.x, where x is a unique number assigned to the organization. An organization can separate these identifiers to identify objects. So, you can use 1.2.840.113556.1.8000.x.1.y for new classSchema objects and 1.2.840.113556.1.8000.x.2.z for attributeSchema objects (where x is the unique organization number, and y and z are the numbers assigned certain classSchema and attributeSchema objects, respectively). It is also recommended that you use a unique organization prefix to distinguish the names of these objects.

Defining Associated Attributes

The attributeSyntax value of the back link must be 2.5.5.1, which is Object syntax (DS-DN). Typically, back link attributes are added to the mayContain value of the class with the greatest abstraction. This ensures that the back link attribute can be read from objects of any class, since such attributes are not stored in the object but are calculated based on the forward link values.

Windows Server 2003 introduced a feature that organizations can use to link two objects in a schema: automatic creation linkIDs. This function ensures that a linkID is automatically generated for a new linked attribute if the attribute's linkID is set to 1.2.840.113556.1.2.50. The corresponding back link is created by setting the linkID to the attributeId or ldapDisplayName of the forward link. The schema cache must be reloaded after creating a forward link and before creating a backward link. Otherwise, the attributeId or ldapDisplayName attribute will not be found when creating a link back. The schema cache is reloaded on demand a few minutes after a schema change or when the domain controller is rebooted.

If you are running Windows 2000 Active Directory, you must request linkIDs from Microsoft by sending an email to [email protected]. The automatic response will contain the following line: "E-mails sent to [email protected] will be processed only if they are related to linkID registrations for legacy environments." (Email messages sent to [email protected], will only be processed if they relate to registration of linkIDs for legacy environments.) To do this, you must include the following information in your email: Company Name, Contact Name, Email Address, Phone Number, Registered Prefix (if required), Registered Site ID (if required).

You can start expanding the scheme

Let's say you decide to extend your Active Directory schema. The solution may involve discontinuing use of the alternative directory implemented through ADLDS (or ADAM in Windows Server 2003) once it is determined that it will not meet the requirements. The next step is to define new attributeSchema objects that need to be added to the schema; this defines any necessary values ​​(such as cn, ldapDisplayName, etc.) that indicate these new objects. When you define attribute values ​​for an object, you also obtain the object identifier from Microsoft or another source. The above activities are documented as business requirements and technical specifications. Moreover, an experimental laboratory environment has been implemented that simulates the operation of Active Directory and is ready for testing.

Many organizations create special committees to approve or reject such changes and establish a process for their implementation. These checks and balances are critical because Active Directory is used as a trusted source of information in many organizations, and the importance of maintaining it after changes are made cannot be overstated.

Once an organization decides to proceed with a project, plans for testing and implementation of the project must be defined. You can extend the schema by adding new objects by using the Microsoft Management Console (MMC) Active Directory schema snap-in or by using programmatic or semi-programmatic methods (for example, using LDIFDE to import LDIF files; using CSVDE to import CSV files; or using scripts for ADSI interfaces).

Regardless of the method you choose, this function must be performed on a server that has or is connected to the FSMO (Flexible Single Master Operations) schema master role in the Active Directory forest. Besides, account The user used to update the schema requires sufficient administrative rights to perform the update, so it must be included in the Schema Administrators group. Finally, you must enable schema updates for the forest (disabled by default).

Unless the change is simple, it should be done automatically to ensure standardization between the testing and implementation phases and to prevent errors that can occur with manual steps. Let's say you decide to implement a change using the LDIFDE tool. To install updates when expanding the schema, you must add new attributes and classes, add new attributes to the classes, and then run a cache reload. Below are some examples.

Adding attributes

For the sake of this discussion, let's assume that an organization called Contoso needs to add an attribute to Active Directory that identifies the shoe size of all employees. There are two domains in the Active Directory forest: contoso.com and employees.contoso.com. It is required that all objects created using the user class definition also contain this new attribute.

It is important to remember that a schema change affects both domains because they are in the same forest. Let's say you receive object ID 1.2.840.113556.8000.9999 from Microsoft, which splits into 1.2.840.113556.8000.9999.1 for the classSchema object and 1.2.840.113556.8000.9999.2 for Contoso's attributeSchema. Now you need to define all the attribute values ​​for this new object, as shown in rice. 3.

Defining the contosoEmpShoe attribute

Additionally, although the contosoEmpShoe attribute should be available to all objects created as user class objects, it is not recommended to change the default user class definition. Instead, you should define a helper class contosoUser with its mayContain attribute set to contosoEmpShoe, as shown in rice. 4. You then need to add the attributes defined for the contosoUser helper class to the user class.

Defining the contosoUser class

Now that the analysis has been done and the values ​​have been determined, you need to create an LDIF file that will look something like the code in rice. 5. You can copy the code to rice. 5 into Notepad and save the file as contosoUser.ldif (included in the download at technetmagazine.com).

LDIF file for schema extension

#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.1 2 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 lDA PDisplayName: 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

After you create the LDIF file, you must thoroughly test your implementation in a pilot lab environment, verify end-to-end domain and forest replication, and enable schema updates in the forest. You must now log in using an account that has Schema Administrator rights. You may need to disable outbound replication on the schema master (where the changes will be made) and run the following command to import the LDIF file:

Ldifde –i –f \contosoUser.ldif –b -k –j. –c "CN=schema,CN=Configuration,DC=X" #schemaNamingContext

After making changes, enable outbound replication on the schema master and ensure that replication is complete for all domain controllers.

Take a deep breath - you're done! You have defined a new attribute in the schema that will be associated with objects created using the user class (that is, user accounts).

To test the changes, open Active Directory Users and Computers, connect to the employees.contoso.com domain, select the users' organizational unit, and create a new user account named ContosoTestUser. Now open the adsiedit.msc console and connect to the domain partition dc=employees,dc=contoso,dc=com, expand the Users partition, right-click ContosoTestUser, then open the Properties page. Find the contosoEmpShoe attribute. You can change this attribute to enter a value. You can also use utility program Ldp.exe to check and change attributes.

Now let's look at an example of defining and relating two attributes and imagine that the Contoso company is very important to the shoe size of its employees and it needs to track the annual productivity of specialists who measure the shoe size of the company's employees. While this may seem ridiculous, let's also assume that Contoso needs to track not only who is responsible for measuring employees' shoe sizes, but also the employees whose sizes were measured and the number of them, all by querying a single attribute. (Although you might think that database tables would be more appropriate for storing this kind of data, the purpose here is simply to explain how forward and backward links work.)

Of course, first you will do an analysis similar to the one I mentioned in the previous example. However, now let's go ahead and create the LDIF files (linkids1.ldif and linkids2.ldif) as shown in rice. 6. Then we'll run the following command to import the LDIF files:

LDIF files of forward and backward links

#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 d n: 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.99 99.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 lDAPDisplayN ame: 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 \linkedids.ldif –b -k –j. –c "CN=schema,CN=Configuration,DC=X" #schemaNamingContext

Now when you create a user object, it will also have the ContosoShoeSizeTaker and ContosoShoeSizesTakenByMe attributes. When you create a user object for John, for example, the ContosoShoeSizeTaker attribute is populated with the distinguished name of the person who measured the shoe size, Frank. If you now go to the properties of Frank's user object and query the ContosoShoeSizesTakenByMe attribute, the result will contain the distinguished name of Frank and the others whose shoe size Frank measured. To complete our case, management can reward Frank based on the number of distinguished names that exist in the ContosoShoeSizesTakenByMe attribute of his user account.

System of checks and balances

A critical update, such as a schema change, cannot be performed without verifying compliance with the architectural requirements. These security and consistency checks are used by Active Directory to ensure that changes do not cause inconsistencies or other problems when extending or changing the Active Directory schema.

First of all, the governsID value for each class must be unique in the schema. When defining a schemaClass object, all attributes defined in the systemMayContain, mayContain, systemMustContain, and mustContain lists must already exist. At the same time, all classes defined in the lists subClassOf, systemAuxiliaryClass, auxiliaryClass, systemPossSuperiors and possSuperiors must also already exist.

Additionally, the objectClassCategory attribute of all classes in the systemAuxiliaryClass and auxiliaryClass lists must be class 88 or an auxiliary class. Likewise, the objectClassCategory attribute of all classes in the systemPossSuperiors and possSuperiors lists must be defined as class 88 or a structural class.

When defining different classes, abstract classes can only be derived from others abstract classes, auxiliary classes cannot be derived from structural classes, and structural classes cannot be derived from auxiliary classes. Additionally, the attribute specified in rDNAttID must be unambiguous and have Unicode string syntax.

These are some of the rules relating to classSchema objects. What about rules for attributeSchema objects? Just like the governsID value for classes, the attributeID value must be unique. In addition, the mAPIID value (if any) must be unique. Next, if rangeLower and rangeUpper are present, the value of rangeLower must be less than the value of rangeUpper. The attributeSyntax and oMSyntax values ​​must match. If the attribute syntax is object syntax (oMSyntax =127), it must have the correct oMObjectClass. The linkID, if present, must be unique. Additionally, a back link must have a corresponding forward link.

What if there was an error?

Once the schema has been extended and new objects (classes and attributes) have been added to it, they cannot be deleted. However, classes and attributes can be disabled by setting the isDefunct attribute of a schema object to TRUE. You cannot deactivate schema objects that are part of the default schema that comes with Active Directory (Category 1 objects). Only objects added to the default schema can be deactivated, i.e. Category 2 objects, and only after checking that the class is not used in the subClassOf, auxiliaryClass, or possSuperiors lists of any existing effective class.

When you try to disable any attribute, Active Directory checks to see if it is used in the mustContain and mayContain lists of any existing valid class. Disabled objects can be enabled again by setting the isDefunct attribute to FALSE. If Active Directory is running at the Windows Server 2003 level, you can reuse the ldapDisplayName, schemaIdGuid, OID, and mapiID values ​​of disabled objects.

Conclusion.

When you add or change class or attribute definitions in a schema, you also add or change the corresponding classSchema or attributeSchema object. This process is similar to adding or changing any object in Active Directory, except that additional checks that the changes do not cause inconsistency and cannot cause problems in the circuit in the future.

Although changing the Active Directory schema is not a complicated process, it is important to understand the schema structure and the process for implementing these changes. All changes to the Active Directory schema must be carefully planned and carried out very carefully. It is important to define business requirements and technical specifications for new objects and carry out comprehensive testing. Because changes can have a significant impact, it is recommended to extend the Active Directory schema only when absolutely necessary.

It is difficult to underestimate the importance of the "Active Directory Schema" for networks built on the basis of an Active Directory domain environment. This is the basis of AD technology and it is very important to correctly understand the principles of its functioning. Most system administrators do not pay due attention to the scheme due to the fact that they rarely have to deal with it. In this article I will tell you what a schema version is, why we need to know it, and most importantly, how to view the current version.

First of all, a few words about the schema itself; each object created in Active Directory, be it a user or a computer, has certain parameters called attributes. The most simple example can serve as the “Last Name” attribute of the user object. The schema defines what objects we can create in Active Directory and what attributes they will have.

Active Directory allows the use within one organization of several domain controllers built on the basis different versions Windows OS. Namely on Windows based Server 2000, Windows Server 2003, Windows Server 2003 R2, Windows Server 2008. Since these versions were released in different years, and each new version has more functionality than the previous one, each operating system has its own understanding of the scheme. Therefore, when you added a new Windows Server 2008-based controller to an organization where existing controllers were built on Windows Server 2003, you had to run the " Adprep" Thus, you have updated your organization's diagram to the level with which it works Windows Server 2008.

The schema update process was performed before the first installation Windows controller Server 2008 and the actual procedure for installing a new controller may not have been performed. If you are just starting to work with an Active Directory organization and do not know what activities were carried out before you arrived, in order to understand the completeness of the structure, you will need to know at what level the current organization's Schema operates.

Possible versions of the circuit:

13 - Windows 2000 Server
30 - Windows Server 2003 RTM, Windows 2003 With Service Pack 1, Windows 2003 With Service Pack 2
31 - Windows Server 2003 R2
44 - Windows Server 2008 RTM

Even if all the controllers in your organization run on Windows Server 2003 R2, and the circuit version shows “44”, you should not be surprised, this indicates that the circuit has already been updated to the Windows Server 2008 RTM level, but the controller itself for some reason there was no reason to install it.

There are several ways to view the schema version; the easiest way is using the DSQuery utility. For this purpose in command line you must enter the command with the following parameters:

“dsquery * cn=schema,cn=configuration,dc=domainname,dc=local -scope base -attr objectVersion”

Naturally in the part “ dc=domainname,dc=local" you must substitute your own domain name. (Example: dc=microsoft,dc=com )

The result of entering the command is to obtain the attribute " ObjectVersion", which will be the version number of the scheme:

Rice. 1 Obtaining the schema version through the DSQuery utility.

The second method is longer and involves the use of the “ ADSIEdit.msc". To view the schema version, you will have to connect to the Active Directory schema partition.

"CN=Schema,CN=Configuration,DC=domain,DC=local"

And find the value of the attribute " objectVersion".

Fig.2 Getting the schema version through the snap-in " ADSIEdit.msc».

Knowing the version of the scheme, you can always say with confidence whether the scheme needs to be updated and, if necessary, to what level.

It should be noted that schema updates can be made software tightly integrated with Active Directory. The most striking example is Microsoft Exchange Server. And often in an organization planning to implement Exchange Server, it is necessary to find out whether the schema has been prepared? And if so, what version of Exchange Server. There are currently three versions of Exchange that work with Active Directory, but there are six options for modifying the schema. You can understand whether the Active Directory Exchange Schema has been changed by the server by using the attribute “ rangeUpper", which takes the following values:

4397 - Exchange Server 2000 RTM
4406 - Exchange Server 2000 With Service Pack 3
6870 - Exchange Server 2003 RTM
6936 - Exchange Server 2003 With Service Pack 3
10628 - Exchange Server 2007
11116 - Exchange 2007 With Service Pack 1

As you can see, the schema update also occurs when installing the SP3 update set for Exchange Server 2000/2003 and SP1 for Exchange 2007.

View attribute value " rangeUpper" You can use the DSQuery utility:

"dsquery * CN=ms-Exch-Schema-Version-Pt,cn=schema,cn=configuration,dc=domainname,dc=local -scope base -attr rangeUpper"

Rice. 3 Getting the attribute " rangeUpper" via the DSQuery utility.

If after entering this command a response is returned indicating the absence of the attribute " rangeUpper" we can conclude that the scheme has not been changed.

The schema update process is very important point for each Active organizations Directory, therefore you should avoid unnecessary, unjustified actions. Understanding the essence of attributes " objectVersion" and« rangeUpper" gives a specialist an advantage when working with Active Directory in an unfamiliar organization, and is also an auxiliary tool when solving problems.

Material provided by resource

As you know, nothing lasts forever, everything changes, especially in an industry like IT. Once deployed, the infrastructure is constantly evolving, expanding, improving, and there comes a time when you need to add a domain controller running a later version of the operating system to your Active Directory.

It would seem - what is the problem? But, as practice shows, problems arise, largely due to the fact that system administrators have little knowledge of the theory and are frankly confused in this matter. Therefore, it's time to figure out what it is AD scheme and how it relates to our case.

AD circuit is called a description of all directory objects and their attributes. Essentially, the schema reflects the basic structure of the directory and is of paramount importance to its proper functioning.

New versions of the OS contain new objects and attributes, so for them to function properly as domain controllers we will need to update the schema.

It seems clear, but not entirely, so let’s move on to common mistakes and misconceptions.

• Updating the schema is necessary to include PCs running newer versions of Windows into the domain. This is not true, even the most latest versions Windows can run quite successfully in a Windows 2000-level domain without updating the schema. Although, if you do update the scheme, then nothing bad will happen.

• To include a controller running a newer OS into a domain, you need to upgrade the domain (forest). This is also not true, but unlike the previous case, this operation will make it impossible to use domain controllers running an OS lower than its operating mode. Therefore, in case of an error, you will have to restore your AD structure from a backup.

We will also draw your attention to the operating mode of the forest and domain. Domains included in a forest can have different operating modes, for example, one of the domains can operate in Windows 2008 mode, and the rest in Windows 2003 mode. The forest operating scheme cannot be higher than the operating scheme of the oldest domain. In our example, the forest operating mode cannot be higher than Windows 2003.

At the same time, the lower operating mode of the forest does not in any way prevent the use of a higher operating mode in the domain; all that is required for this is to update the schema.

Having familiarized ourselves with the theory, let's move on to a practical example. Let's say we have a Windows 2000 level domain (mixed mode) - the lowest level of AD - in which there is a controller running Windows 2003, and our goal is to create a new controller to replace the failed one.

The new server runs Windows 2008 R2. Please note that we did not have any difficulties in incorporating this server into an existing domain.

However, when we try to add a new domain controller, we will receive an error:

To successfully turn on a controller under control of more than new version OS we will need to update the forest schema and domain schema. The exception is Windows Server 2012, which will update the schema on its own when adding a new domain controller.

To update the schema, use the Adprep utility, which is located in the folder \support\adprep on installation disk Windows Server. Starting with Windows Server 2008 R2, this utility is 64-bit by default; if you need to use the 32-bit version, you should run it adprep32.exe.

To perform a forest schema update this utility should be launched on The owner of the scheme, and to update the domain schema to Infrastructure owner. To find out which controllers have the FSMO roles we need, use the command:

Netdom query FSMO

In Windows 2008 and newer, this utility is installed by default, and in Windows 2003 it must be installed from the disk from the directory \support\tools

The output of this command will result in a list of all FSMO roles and controllers that have these roles:

In our case, all roles are on the same controller, so we copy the folder \support\adprep to the hard drive (in our case, to the root of the C: drive) and proceed to updating the forest schema. To successfully complete the operation, your account must be included in the following groups:

• Schema Administrators
• Enterprise administrators
• Administrators of the domain in which the schema owner is located

To update the forest schema, run the command:

C:\adprep\adprep /forestprep

Read the standard warning and continue by clicking C, then Enter.

The schema update process will begin. As you can see, its version will change from 30 (Windows 2003) to 47 (Windows 2008 R2).

After updating the forest schema, you must update the domain schema. Before doing this, you should make sure that the domain is running at least in Windows 2000 mode (native mode). As we remember, our domain operates in mixed mode, so we should change the domain operating mode to primary or upgrade it to Windows 2003. Since in this domain we do not have controllers running Windows 2000, it would be most reasonable to upgrade the domain mode.

To successfully update the domain schema, this operation should be performed on Infrastructure owner and have rights Domain Administrator. We execute the command:

C:\adprep\adprep /domainprep

And carefully read the information displayed. When upgrading a domain schema from Windows 2000 or Windows 2003, you must change file system permissions for group policies. This operation is performed once and in the future, for example, updating the schema from the 2008 level to 2008 R2, it must be performed. To update GPO permissions, enter the command:

C:\adprep\adprep /domainprep /gpprep

AD versions since Windows 2008 have introduced a new type of domain controller: a read-only domain controller (RODC), if you plan to deploy such a controller, then you need to prepare a diagram. In general, we recommend performing this operation regardless of whether you intend to install RODC in the near future or not.

This operation can be performed on any domain controller, but you must be a member of the Enterprise administrators And Master of naming And Infrastructure Master must be available.

C:\adprep\adprep /rodcprep

As you can see, updating the domain schema, if properly planned, does not cause any difficulties, however, in any case, you should remember that this is an irreversible operation and have the necessary backup copies on hand.
Source http://interface31.ru/tech_it/2013/05/obnovlenie-shemy-active-directory.html