Module 4: Designing a Schema Policy

Overview

Identifying Business Needs

Schema Fundamentals

Implications of Modifying the Schema

Planning for Schema Modification

The Microsoft® Windows® 2000 Active Directory™ directory service schema contains the definitions of all objects, such as computers, users, and printers, that are stored in Active Directory. The definitions contained within the schema define the classes of objects a directory may contain, and the types of attributes each object may or must have.

Schema modification includes adding or changing object class or attribute definitions to fit the needs of your network. This is a powerful feature of Active Directory that can also have a significant impact on the entire network. You need a carefully designed policy for modifying the schema that includes controlling when and how you implement schema modifications.

At the end of this module, you will be able to:

Identify business needs that require schema modification.

Describe the schema components and the fundamentals of schema modification.

Explain how modifying the schema impacts Active Directory.

Create a management policy to control schema modification.

Identifying Business Needs

Primary Reasons for Schema Modification:

Enabling Schema to Address Business Needs

Installing Directory-Enabled Applications

Schema

Because the default Active Directory schema in Windows 2000 contains hundreds of classes and attributes, the need to change the schema is rare. However, modification may be necessary when an organization's business needs are not addressed by the preexisting definitions in the schema. For example, an organization may require Active Directory to track a unique user attribute, such as Cost Center, not included in the schema. In this case the schema can be modified intentionally to include the new attribute.

Organizations may also plan to use directory-enabled applications. These applications may modify the schema as they are installed so that the applications can fully interact with the directory.

Because a schema change impacts the entire forest, try to avoid unnecessary schema modification. Always identify the importance of the business need, and also determine if the need can be satisfied in a way that does not require schema modification.

Schema Fundamentals

Schema Components

Modifying the Schema

Obtaining and Extending Object Identifiers

Deactivating Schema Components

The Active Directory schema consists of different objects, or components, that control the classes and attributes maintained by Active Directory. Modifying these components changes the definitions of the objects in Active Directory and directly affects how Active Directory operates.

Active Directory schema can be changed in several different ways. You can add or modify components within the schema, but you cannot delete unused components. Unused schema components can only be deactivated.

In this lesson you will learn about the following topics:

Schema components

Modifying the schema

Obtaining and extending object identifiers

Deactivating schema components

Schema Components

Class-SchemaClass-SchemaObjectsObjects

Examples:Examples:

UsersUsers

ComputersComputers

Some possible User ClassSome possible User ClassAttributes :Attributes :Some possible User ClassSome possible User ClassAttributes :Attributes :

accountExpiresbadPasswordTimemailname

accountExpiresbadPasswordTimemailname

Attribute Definition Attribute Definition includesincludesAttribute Definition Attribute Definition includesincludes

Object NameObject IdentifierSyntaxOptional Range Limits

Object NameObject IdentifierSyntaxOptional Range Limits

Class Definition includesClass Definition includesClass Definition includesClass Definition includes

Object NameObject Identifier“May Contain” Attributes“Must Contain” Attributes

Object NameObject Identifier“May Contain” Attributes“Must Contain” Attributes

List of AttributesList of AttributesList of AttributesList of Attributes

accountExpiresbadPasswordTimemailcAConnectdhcpTypeeFSPolicyfromServergovernsIDName…

accountExpiresbadPasswordTimemailcAConnectdhcpTypeeFSPolicyfromServergovernsIDName…

Attribute-Schema Attribute-Schema Objects Examples:Objects Examples:

ServersServers

The schema contains two types of components: class-schema objects that define a class, and attribute-schema objects that define an attribute. These two types of objects are defined separately from each other.

Schema modification involves changing the schema components. Modifying the schema components should not be confused with modifying or creating objects in Active Directory. When you create a new user in Active Directory, you create an object, or instance, of the class User. Modifying the schema involves creating or modifying the class or attribute definitions themselves.

Class-Schema Objects

Classes are definitions for sets of objects that share a set of characteristics, or attributes. For example, Users is a class in Active Directory. Every user created has certain attributes in common with other users, such as a first and last name. Although the value of each user is different, they each possess a first and last name.

Each class in Active Directory has a class-schema object corresponding to it in the schema. The class-schema object is made up of attribute-schema objects. The class-schema object specifies which attributes can or may be used in objects created in this class, and defines the following constraints:

Must-Contains. A list of mandatory attributes that must be present on any object that is an instance of this class.

May-Contains. A list of optional attributes that can be found on an object that is an instance of this class.

Hierarchy rules. A rule that determines the possible parents in the directory tree of an object that is an instance of the class. For example, a user cannot have a server as a parent object.

Note: An object is only allowed to have an attribute that belongs to either the must-contain or the may-contain list of the class.

Attribute-Schema Objects

Attributes are used to define objects. A sample attribute for an object of the User class might be the user's last name. Each user object will have this attribute, but each will hold a different value that is specific to the user. Every attribute has a corresponding attribute-schema object. The attribute-schema object specifies various properties of an attribute, such as the syntax that should be used in it and whether or not it may have multiple values. An attribute-schema object must be defined before it can be added to a class. An attribute-schema object will have the same properties no matter where it is applied, although the value for each property will differ.

Syntax Rules

Syntax rules state that attributes can hold specific types of information, such as an integer or a date-formatted value. For example, when you create a user object, the syntax rule would be that only numeric values are acceptable for the attribute Telephone-Number. Active Directory defines a set of attribute syntax for specifying the type of data contained by an attribute. The predefined syntax does not actually appear in the directory, and you cannot add new syntax.

Modifying the Schema

Schema Modification Occurs When You:

Use the Active Directory Schema to create, modify, or deactivate classes or attributes

Write scripts to automate schema modification

Install software applications that add classes or attributes

To Control Membership of Schema Admins Group:

Control Membership of Local Admins, Domain Admins, and Enterprise Admins Groups

Schema

You can modify the schema by:

Using the Active Directory Schema snap-in. Members of the Schema Admins group can use the Active Directory Schema snap-in in the Microsoft Management Console (MMC) to manage the schema by creating, modifying, and deactivating classes and attributes.

Scripting. You can write a script with Active Directory Service Interfaces (ADSI) that will create, modify, or deactivate classes and attributes. Use this method when you want to automate schema modifications. Scripting also requires you to review the script before running it, which reduces the chance of typographical errors that could cause unwanted schema modifications.

Note: For sample scripts, see the Windows 2000 Server Resource Kit Distributed Systems Guide.

Installing software applications. Software applications that add classes or attributes during the application installation process are referred to as directory–enabled applications.

Controlling Access to the Schema Admins Group

Membership of the Schema Admins group should be carefully monitored, because its members are the only users authorized to change the schema. However, members of the Local Admins, Domain Admins, and Enterprise Admins groups in the forest root domain have the authority to change the membership of the Schema Admins group. Because these groups control membership of the Schema Admins group, they should also be carefully monitored. Membership of these groups can be restricted by using Group Policy.

Obtaining and Extending Object Identifiers

Object Identifiers

Unique identifiers for class and object attributes

Obtained from an ISO issuing authority

Extend to accommodate your enterprise

Object Identifier Format, 1.2.840.x.w.y.z

1.2.840, issuing authority

x.w.y.z for extension

An object identifier is a unique number that identifies an object class or attribute in a directory. Each schema object must have an object identifier. You must obtain an object identifier prior to making any additions to the schema. This includes new attributes and new classes.

Object identifiers are hierarchical, with the root controlled by the International Organization for Standardization (ISO). ISO allocates a branch of the tree to subordinate vendors, or name registration authorities. An object identifier is expressed as a string of numbers delimited by decimal points; for example, 1.2.840.x.w.y.z. The name registration authority issues the leading digits 1.2.840. The remaining digits, x.w.y.z, are reserved for your organization to extend as necessary.

In order to obtain an object identifier, you can either contact ANSI or ISO (www.iso.org) or use object identifier Oidgen.exe in the Windows 2000 resource kit to generate an object identifier. It is recommended that you generate distinct object identifier trees for attributes and classes.

Deactivating Schema Components

Classes and Attributes Are Not Deleted, but Deactivated.

Classes and Attributes Can Be Reactivated

Classes or attributes are never actually removed from the schema, but are deactivated. This feature prevents irreversible mistakes, because classes and attributes can be reactivated. You can deactivate and reactivate a class or attribute by using the Properties dialog box for that object in the Active Directory Schema. When planning to deactivate a class or attribute, consider the following:

You cannot deactivate default schema objects. You can only deactivate objects that have been added to the schema after schema installation.

You cannot deactivate attributes that are in use by a Class Schema object, or any objects of that class with values in that attribute.

When a class or attribute is deactivated, it is no longer replicated throughout the network or to the global catalog server.

Deactivating a class does not deactivate existing objects of that class type. However, you cannot create new objects from a deactivated class.

You cannot use deactivated attributes in new or existing classes.

Objects from deactivated classes and class attributes appear in searches. If you no longer need objects of a certain class, you can deactivate the class, search for objects that are instances of that class, and then delete those objects from Active Directory.

You cannot create new classes or attributes that have the same common name, object identifier, or Lightweight Directory Access Protocol (LDAP) display name as a deactivated class or attribute.

Implications of Modifying the Schema

Schema Modification Can Impact:

Validity of Existing Objects

Replication Latency

Network Performance During Replication

Schema modification impacts your entire network. Modifications can affect existing objects, can createreplication latency, and can increase network traffic.

Possible Effects on Existing Objects

A schema update can make an existing object invalid. For example, suppose Widgets is an instance of object class Products. Products has a May-Contain attribute called Color.If a schema update deletes Color from the May-Contain listof Products, Widgets will be invalid, because Widgets has an attribute that is not in accordance with its class definition.

Active Directory allows deactivated classes and attributes to remain in the directory to ensure that they do not cause any other schema conflicts. However, Active Directory does not automatically remove invalid objects. Therefore, you can search on the invalid attribute and delete it from all existing objects, but Active Directory will not allow you to add the attribute to any new objects.

Replication Latency

Schema replication is a process separate from normal directory replication. To avoid potential conflicts, schema modifications are performed on one domain controller and then replicated across all domain controllers in the forest. However, schema replication can introduce temporary inconsistencies in the schema. It is possible that an object, or instance, of a newly created class may be replicated to a domain controller before the new schema class arrives.

For example, assume you create a new class, Company-Vehicles, at a domain controller. Then you create an instance of this class, Limo, at the same domain controller. However, when the changes are replicated to another domain controller, Limo is replicated before Company-Vehicles. The replication of the instance will fail because the second domain controller is not yet aware of the class Company-Vehicles.

If replication failure occurs, Active Directory automatically replicates the schema from the schema operations master, and the schema cache is immediately updated on the target domain controller. Active Directory then replicates any object that failed to the target domain controller. As a result, the Company-Vehicles class is added into the target domain controller's schema cache. The next replication cycle will successfully add Limo.

Network Performance During Replication

Some schema modifications can have considerable impact on network performance. For example, if you deploy Active Directory and then decide to mark another attribute for inclusion in the global catalog, you can make the change quite easily in the Schema Manager. However, this change causes all global catalogs to set their Update Sequence Numbers (USNs) to 0. As a result, all objects (not just the changed property) in Active Directory must be replicated to each global catalog again, which causes significant network traffic.

Note: The administrative tools shipped with Windows 2000 Advanced Server are designed to manage the default schema. New classes and new attributes may not appear correctly in these tools. The Active Directory administrative tools can be extended to manage the new schema modifications you make. See The Active Directory Programmer's Guide (www.msdn.microsoft.com/library/psdk/adsi/glns2(1)_5kit.htm)for directions.

Planning for Schema Modification

Deciding when to Modify the Schema

Planning for Directory-Enabled Applications

Anticipating Microsoft Exchange 2000

Testing Schema Modifications

Developing a Schema Modification Policy

Design Guidelines

When planning for schema modification, you must first decide whether changes are necessary. You may be able to accommodate some business needs by other changes. However, there may be changes, such as installing a directory-enabled application, which would require modifying the schema. Once you determine that the schema should be modified, you should test the schema modification to ensure its success. To manage the process of schema modification, it is best to devise a policy for schema modification that states when and how it will be changed, and by whom.

Planning for schema modification includes the following:

Deciding when to modify the schema.

Planning for the eventual use of directory-enabled applications.

Anticipating the use of Microsoft Exchange 2000.

Testing the schema modification.

Developing a schema modification policy.

Deciding when to Modify the Schema

SituationSituationSituationSituation Suggested SolutionsSuggested SolutionsSuggested SolutionsSuggested Solutions

No existing class meets needsNo existing class meets needs

Existing class needs attributes but otherwise meets needs

Existing class needs attributes but otherwise meets needs

Need a new set of unique attributes, but not a new class

Need a new set of unique attributes, but not a new class

Existing classes or attributes no longer needed

Existing classes or attributes no longer needed

Create a new classCreate a new class

Create new attributes, derive a new child class, or create an auxiliary class

Create new attributes, derive a new child class, or create an auxiliary class

Create auxiliary classCreate auxiliary class

Deactivate existing class or attributeDeactivate existing class or attribute

Because there are more than 140 classes and more than 850 attributes in the default schema provided with Windows 2000, you should rarely need to add or modify classes and attributes. However, there may be situations where an existing class or attribute does not meet your needs. The previous table describes some of these situations, and suggests solutions.

Not all schema objects can be modified. The following rules apply:

Classes and attributes defined as system cannot be modified or deactivated.

Modifications are subject to certain restrictions that are enforced by Active Directory and are often determined by whether the classes or attributes are part of the default schema or have been added after the original installation.

The set of valid attribute syntax that is recognized by the directory service is also hard-coded and cannot be changed.

The list of mandatory attributes cannot be modified after a class has been created.

Note: For more information about what can and cannot be modified in the schema, see the Windows 2000 Resource Kit.

Planning for Directory-Enabled Applications

Directory-Enabled Applications Modify the Schema in Two Phases:

1. Schema Admins Perform the Schema Components Phase of the Install

2. Any Authorized Individual Can Complete the Install

Directory-enabled applications integrate with Active Directory as they operate, allowing organizations to combine services in an effort to reduce total cost of ownership and network overhead. Directory-enabled applications require special considerations when planning for their use, as these types of applications will likely modify the schema as they are installed.

When designing an application installation routine that must modify the schema, the installation routine should be in two distinct phases, as described in the following:

Phase one modifies the schema. Only members of the Schema Admins group will be allowed to run the part of installation that modifies the schema. Write-access must be enabled for this phase of the install.

Phase two verifies that the schema modifications have successfully taken place, and then the traditional application installation proceeds. Anyone who has been assigned appropriate permissions can run this part of the installation.

You should test any application before installing it on a network, but testing is especially important for applications that will modify the schema.

Anticipating Exchange 2000

Integration of Exchange 2000 and Active Directory Improves Performance

Separate Databases No Longer Necessary

Initial Configuration of Exchange 2000 May Take Extra Time to Complete

LDIF Files Replicated

Global Catalog Replication

Exchange 2000 is fully integrated with Active Directory. With the advent of Active Directory in Windows 2000, the directory database that the operating system provides is now capable of holding all user account details, security information, and messaging data. This means that a separate directory is not necessary for Exchange 2000 data.

The integration of Exchange and Active Directory will increase performance, but the initial configuration may take an extended amount of time. This is because:

Many LDAP Directory Interface Format files, also known as LDIF files, are imported as part of the installation process for the first Exchange 2000 server in Active Directory.

Any additional attributes tagged for global catalog replication will cause all objects (not just the changed property) in Active Directory to replicate to each global catalog again. This can cause significant network traffic. Because the installation of Exchange 2000 tags attributes for replication to the global catalog, it will also have the same impact on Active Directory.

For organizations planning to deploy Active Directory and install Exchange 2000 servers at a future date, it is best to import the Exchange-specific schema changes as soon as possible before Active Directory becomes too large.

Testing Schema Changes

When Testing Schema Modifications, Always:

Test Changes in a Non-Production Environment

Use Thoroughly Tested Scripts

Remember that Objects and Attributes Can Only Be Deactivated

You should always test schema modifications, as well as any other substantial changes to your network. Before developing and testing a schema modification, be sure to remove the schema operations master from the network or set up an isolated test network. If the domain controller is not connected to your primary network, you can test and troubleshoot any problems you may encounter before schema updates are replicated to all of the other domain controllers in the forest.

When testing schema modifications, remember the following:

Always test schema modifications in a test environment that is not part of your forest.

Use thoroughly tested scripts whenever possible to avoid typographical errors when the modifications are applied to a production environment.

Attributes and classes added to your schema can only be deactivated, never deleted.

Developing a Schema Modification Policy

Creating an Experienced Committee Responsible for Schema Modification

Establishing Modification Guidelines

Initiating Schema Modifications

Testing Schema Modifications

Performing Schema Modifications

Schema Modification Committee

Schema Modification Committee

Always thoroughly plan and prepare before making schema modifications. Inconsistencies in the schema can cause significant problems that impair or disable Active Directory network-wide. These problems might or might not be evident immediately.

Creating a Schema Modification Committee

It may be desirable to appoint a committee of individuals who have expertise with directory services to take full responsibility for all schema changes. They should have a thorough understanding of how the schema works, the effects of schema modification, and how to avoid potential problems.

Establishing Modification Guidelines

At minimum, your schema modification policy should include guidelines for the following:

Initiating schema modifications, including:

Submitting schema change requests to an approving committee.

Verifying the critical need for the changes.

Identifying the impact on existing objects, network traffic, and the process of creating new objects.

Obtaining a valid object identifier.

Receiving approval of requested changes from the committee.

Testing schema modifications, including:

Testing the proposed change in a test environment separate from the production environment, or disconnecting the schema master from the network if there is no test environment.

Ensuring that the proposed schema modifications meet the specifications of the needed change.

Ensuring that an effective recovery plan is in place.

Receiving approval to implement the modification.

Performing Schema Modifications, including:

Restricting membership of the Schema Admins group.

Enabling a write copy on the schema operations master.

Verifying that all domain controllers receive the change.

Returning the schema operations master to a read-only copy.

Design Guidelines

Plan and Implement with Care

Prevent Confusion

Prevent Unauthorized Schema Modifications

The following practices will assist you with schema modifications:

Plan and implement schema modifications with care.

Modify the schema only when absolutely necessary.

Plan, document, and implement a schema modification strategy.

Take the simplest approach. Use existing attributes when you create

new classes, and avoid large, multi-valued attributes, which are costly to store and retrieve.

Choose parent classes carefully. Determine where you want users to be able to create objects of the new class.

If you use scripting for large-scale modifications, require intensive testing of the script before the actual implementation.

Prevent confusion.

Use meaningful names for new classes or attributes. Always use distinctive prefixes to distinguish them from existing classes and attributes.

Do not move the role of the schema operations master unless you need to take the current master offline.

Use the common name for the LDAP display name. This will make searches more efficient.

Prevent unauthorized modifications.

Keep the The Schema may be modified on this server check box cleared on your schema operations master.

Closely guard membership of the Schema Admins group.

Lab A: Modifying the Schema

Review

Identifying Business Needs

Schema Fundamentals

Implications of Modifying the Schema

Planning for Schema Modification