Export, Compare, and Synchronize Active Directory Schemas

• Using LDIFDE to export the schema from the source forest
• Comparing schemas with the Active Directory DS/LDS Schema Analyzer
• Import your schema into the target forest

  Contents

Exporting the Schema from the Source Forest
Compare the Active Directory Schemas
Create an LDIF File with the Missing Elements
Import the Schema into the Target Forest
Wrapping Up

Each Active Directory forest has its own schema, which defines the objects and attributes that the directory service uses to store data. When organizations have multiple Active Directory forests, IT administrators have to manage multiple Active Directory schemas; ensuring consistency between schemas is vital when managing multiple forests. In this article, I will walk you through a streamlined process to manage multiple Active Directory schemas.

The Flexibility of Schema Synchronization and Comparison

One of the biggest advantages of the process I've detailed in this article is that it is not exclusive to Active Directory schema management. This process can also be used to synchronize schemas between various combinations of Active Directory, ADAM (Active Directory Application Mode), and AD LDS directories. The schema synchronization can be performed to synchronize schemas between the following:

• Active Directory and Active Directory
• ADAM and ADAM
• AD LDS and AD LDS
• Active Directory and ADAM
• Active Directory and AD LDS
• AD LDS and ADAM

This process can also be used to compare schemas bet-ween various combinations of Active Directory, ADAM, and AD LDS directories. The schema comparison can be performed to compare schemas between the following:

• Active Directory and Active Directory
• ADAM and ADAM
• AD LDS and AD LDS
• Active Directory and ADAM
• Active Directory and AD LDS
• AD LDS and ADAM
• Active Directory and an LDIF file
• ADAM and an LDIF file
• AD LDS and an LDIF file

It is important to note that using this process to synchronize Active Directory schemas is not suited for all attributes and classes. In fact, there are known issues with the use of this process to extend the Active Directory schema, for Exchange Server. Using the procedures listed in this document for preparing your Active Directory schema for Exchange Server and it is not supported; you must run setup.exe /PrepareSchema from the Exchange Server setup directory to extend the schema for Exchange Server. Therefore, if your environment includes non-custom attributes and classes, you must first ensure that the use of this process is supported for those non-custom attributes and classes before you go ahead and use it to synchronize Active Directory schemas. Please note that the use of this process to export and compare schemas will not have an adverse effect on non-custom attributes or classes.

Organizations may deploy more than one production Active Directory forests for a variety of business or technical reasons. Often, additional Active Directory forests are deployed well after the production forest has been deployed. In some cases, this occurs years later.

Active Directory was released nearly a decade ago. Over the years, organizations have undoubtedly made numerous schema modifications to their production forest. Identifying these schema modifications to the forest is a challenging task. It's even more difficult to ensure that the schema modifications that were previously made to the production forest are made in new testing forests in a consistent manner.

In this article, I focus on a scenario in which you are deploying a new user acceptance testing ( UAT ) Active Directory forest that will be used by end users to test applications that leverage Active Directory for authentication and authorization. Five custom attributes exist in your production Active Directory schema, and you need to ensure that the schema from the source production forest is consistent with the new target UAT forest.

There are a number of scenarios, however, in which you can use the process I discuss in this article to streamline the management of multiple schemas. There are also scenarios in which this process is not recommended and is not supported. For more on this, see the sidebar "The Flexibility of Schema Synchronization and Comparison."

Exporting the Schema from the Source Forest

The first step is to export the schema from the source forest. This is required so that you can later compare the source forest's schema with the target forest's schema to decide which attributes and classes to synchronize.

The LDIFDE command-line tool, which ships with Windows Server 2003 and Windows Server 2008, can be used to export the schema from the source forest. This tool creates a file that is formatted with the LDAP Data Interchange Format (LDIF). No special permissions are required to export the schema from the source forest, and any domain user can perform this task.

To export the schema from the source forest, do the following:

1. Log on to a member server or a domain controller.
2. Open a Command Prompt window.
3. Type the following into the Command Prompt window:
   ldifde -f PRODSchema.ldif -d CN=Schema,CN=Configuration,DC=WS08DOMAIN01,DC=local

4. Press Enter.

Figure 1 shows the output you'll see from this command.

Figure 1 Exporting the Schema from the Source Forest

In this command, the -f PRODSchema.ldif parameter tells LDIFDE to write the output to a file called PRODSchema.ldif. The -d CN=Schema,CN=Configuration,DC=WS03DOMAIN01,DC=local parameter tells LDIFDE to use the schema partition as the root of the LDAP search. The DC=WS08DOMAIN01,DC=local part of the command must be replaced with the distinguished name of the forest root domain in your source forest.

Figure 2 Load target schema window

Compare the Active Directory Schemas

Now that you have exported the schema from the source forest, you are ready to compare this schema with that in the target forest. This step allows you to identify any attributes and classes that exist in the source forest but do not exist in the target forest.

Windows Server 2008 includes the AD DS/LDS Schema Analyzer tool when the Active Directory Lightweight Directory Services server role is installed. It can be used to compare schemas in a number of different ways. Note that this tool was previously called the AD Schema Analyzer in Windows Server 2003. In this article, I refer to it as the AD DS/LDS Schema Analyzer since my examples are using Windows Server 2008. The steps in the comparison and export, however, can also be performed using the Windows Server 2003 version of this tool.

To compare the Active Directory schemas of the source and target forests, do the following:

1. Log on to a member server or a domain controller that has AD LDS installed and belongs to a domain in the target forest.
2. Find the PRODSchema.ldif file that was created in the previous section and copy it to the server you log on to.
3. Go to Start, click Run, and type the following: C:\WINDOWS\ADAM\ADSchemaAnalyzer.exe
4. Hit Enter and the AD DS/LDS Schema Analyzer will open.
5. On the File menu of the AD DS/LDS Schema Analyzer window, click Load target schema.
6. In the Load target schema window, shown in Figure 2, click the Load LDIF button.
7. Browse to the location of the LDIF file and click Open.
8. The LDIF file will be imported into the AD DS/LDS Schema Analyzer.
9. On the File menu, click Load base schema.
10. In the Load base schema window, enter a domain controller to connect to in the Server[:port] field, a username, a password, and a domain, as shown in Figure 3.
11. Click Ok.
12. To filter for the non-present elements, select Hide present elements from the Schema menu. The missing elements will be listed under the Attributes node, as shown in Figure 5.
13. Expand the Attributes node and the present and non-present elements (attributes and classes) will be listed, by default. The attributes that are consistent between forests appear with a checkmark in the box beside the element name, as shown in Figure 4. The elements that exist in the source forest, but are missing from the target forest appear with an empty box.

Figure 3 Load base schema window

Figure 4 Present and missing attributes

Figure 5 Viewing only the missing elements

Figure 6 Mark non-present elements you want to include

Dealing with Domain-Relative SIDs in Schema Class Objects

If the schema in the source forest was prepared for Read-Only Domain Cont-rollers (RODCs), by running the adprep /rodcprep command, you might need to perform an additional task after you complete the import the schema into the target forest. When the adprep /rodcprep command is run, the following three schema classes may have a domain-relative SID in their default security descriptor:

• Domain-DNS
• DMD
• SAM-Domain

The default security descriptor for these three schema classes includes the Enterprise Read-Only Domain Controllers security group, which may contain the domain-relative SID. The SID for this security group is in the form of <domain SID>-498. For example, if the domain SID is S-1-5-21-886666173-4210462831-1041481479, the SID for the Enterprise Read-Only Domain Controllers security group will be S-1-5-21-886666173-4210462831-1041481479-498. As you would expect, a domain-relative SID from the source forest will not be usable in a security descriptor in the target forest.

The steps required to address this issue vary depending on your forest functional level (FFL) of your source and target forests:

• If the target forest has an FFL of Windows Server 2008 or later, you can replace the offending SID with "RO".
• If the source forest has an FFL of Windows Server 2008 and the target forest has an FFL earlier than Windows Server 2008 (for example, Windows Server 2003), you need to replace the "RO" in the SDDL with the SID of the target forest's Enterprise Read-Only Domain Controllers security group.

Only Windows Server 2008 domain controllers understand the meaning of "RO"; Windows Server 2003 and Windows 2000 Server domain controllers do not. Therefore, if all domain contro-llers in the target forest have Windows Server 2008 installed, and you do not plan to introduce any domain controllers that have Windows Server 2003 or Windows 2000 Server installed in the future, you should aim to use "RO" in the default security descriptor of a schema object. If the target forest includes domain controllers that have Windows Server 2003 or Windows 2000 Server installed, or such domain controllers may be introduced in the future, you must use the SID of the Enterprise Read-Only Domain Controllers security group, which will include the domain-relative SID.

Create an LDIF File with the Missing Elements

Now you have completed a comparison of the Active Directory schemas and identified the elements (classes and attributes) that exist in the source forest but do not exist in the target forest. You now have to create another LDIF file that will contain these missing elements. This new LDIF file will be used to import the missing elements into the target schema.

You can use the AD DS/LDS Schema Analyzer to create an LDIF that contains the missing elements, by doing the following:

1. To include all missing elements in the LDIF file, on the Schema menu in the AD DS/LDS Schema Analyzer window, click Mark all non-present elements as included, and then click OK on the confirmation. To control which missing elements are included in the LDIF file, click the box beside each element you want to include. A plus (+) sign will be added beside the element, as shown inFigure 6.
2. On the File menu in the AD DS/LDS Schema Analyzer, click Create LDIF file.
3. In the Select LDIF file window, enter a location and filename for the LDIF file and click Save.

Import the Schema into the Target Forest

The final step in this process is to import the Active Directory schema into the target forest. The LDIFDE tool can be used to import the missing elements from the source forest into the target forest. As previously mentioned, the missing elements are contained in the LDIF file that was just created by the AD DS/LDS Schema Analyzer.

To import the Active Directory schema into the target forest, use an account that is a member of the Enterprise Admins and Schema Admins groups to perform the following tasks:

1. Log on to the domain controller that holds the schema Master Operations Master role.
2. Open a Command Prompt window.
3. In the Command Prompt window, type the following:
   ldifde -i -f MissingElements.ldf -c dc=X DC=WS08DOMAIN02,DC=net

4. Hit Enter.

In this command, the -i parameter tells LDIFDE to perform an import. The -f MissingElements.ldf parameter tells LDIFDE to import from a file called MissingElements.ldf. The -c dc=X DC=WS08DOMAIN02,DC=net parameter tells LDIFDE to replace all instances of dc=X with DC=WS08DOMAIN02, DC=net. The DC=WS08DOMAIN02,DC=net part of the command must be replaced with the distinguished name of the forest root domain in your target forest.

Wrapping Up

At this point, the schema in the target forest has been extended to include the missing elements.

Active Directory schema management is a complex task. And it becomes even more complex when multiple Active Directory forests are deployed in your environment. However, by using the process explained in this article, you can streamline the management of multiple Active Directory schemas and ensure you have a consistent schema across all your forests.

Active Directory: Protect your Active Directory data

Adapted from “Protecting Critical Data by Managing the Active Directory Identity Lifecycle” (Realtime Publishers)

You must protect your Active Directory-based identity data. It’s an important part of ensuring any identity system you put in place that works with Active Directory is protected such that it’s able to do its job of authenticating and authorizing the right people to the right resources.

You have to ensure the data within Active Directory is sacrosanct and only users with a business reason to access Active Directory information are granted that access. All the great identity-provisioning processes in the world won’t help you if your Active Directory is a free-for-all that anyone can fiddle with to his heart’s content. You need to take a deep look at your Active Directory security model and determine the best techniques and best practices for securing the data residing within.

The challenges of securing Active Directory

Managing the Active Directory security model isn’t exactly straightforward. The nature of a hierarchical directory service that serves many purposes (including application directory, authentication directory, desktop management directory and so on) means the security model can be a handful. More important, if you don’t take a proactive approach to managing your Active Directory security, it can quickly get out of control.

Consider, for example, the simple task of delegating user account management in Active Directory. Because of the granular nature of the Active Directory security model, a seemingly simple task such as managing user accounts could evolve into a dizzying array of permissions you’ll have to delegate:

• Permission to create user objects
• Permission to delete user objects
• Permission to move user objects
• Permissions on user object properties (this may break down into sensitive properties, such as department, manager, and group memberships, and non-sensitive properties such as telephone number and office address)
• Permission to reset the user’s password or unlock his account
• Permission to control who can change a user’s permissions

This list is by no means comprehensive, but it underscores the potential complexity of managing delegation on just this one task. Consider that each of these tasks (or at least groups of them) might be delegated to other subgroups. These permission sets might also vary based on the organizational unit (OU) in which the users are located. Add to the mix that parent objects in Active Directory can inherit permissions from their children (for example, permissions can move from the Marketing OU to the Users OU under Marketing). You can see things can really get gummed up if you’re not careful.

Not only is the complexity of the Active Directory security model challenging, it requires discipline to establish a good delegation model and keep it organized over time. One-off requests and unusual business needs drive you to make compromises. The ultimate goal is to protect the data in Active Directory that’s critical to your organization’s authentication and authorization mechanisms, so it’s important to keep a handle on Active Directory security.

Understand the Active Directory security model

Understanding the Active Directory security model is about comprehending how Active Directory is structured. Not unlike a relational database, Active Directory contains a schema that defines the available classes of objects and their associated attributes. A user object in Active Directory is an instantiation of the schema class “user.” That user object, as per the schema, contains a set of attributes such as first name, last name, department, manager, phone number and so on.

Each object in Active Directory also has an associated security descriptor. This security descriptor defines the permissions on that object. These show an example of a user object’s permission set, or Access Control List (ACL), as viewed from Active Directory Users and Computers.

The ACL is composed of a set of security principals (usually users or groups) that have rights over that object, and the rights or permissions associated with each security principal. A particular permission can be either an “Allow” or “Deny.” Allow is the default. This grants a permission to the security principal. If Deny is selected, then that permission is explicitly denied to that security principal. In fact, if an object inherits permissions from its parent and there are clashing Allow and Deny Access Control Entries (ACEs) for a given permission, then typically the Deny will win.

Standard and extended rights

Not every object class in Active Directory has the same set of associated permissions. This is great because it means you can tailor permissions to the type of object involved. Consider this example: a “trigger replication” permission associated with an Active Directory naming context object lets you delegate who can force replication between two domain controllers. Trigger replication has no relevance to a user object, though. In fact, every object has an associated set of “standard rights.” These include familiar ones such as:

• Read
• Write
• List
• Create
• Delete
• Read and Write Properties

Beyond the standard rights, a schema class can also have extended rights. Familiar examples of extended rights are the permissions found on a computer object. A computer has permissions such as “Read and Write host name attributes” specific to the computer class of each object.

This extensibility within the Active Directory security model lets you create a rich and granular delegation of tasks for your administrators and users. If you extend the Active Directory schema with a new class of object, it can have its own set of extended rights that control delegation specific to that object type (though you also have to be aware of the various differences across the object classes you want to delegate).

Understand security inheritance

Another aspect that makes the Active Directory security model challenging is the notion of inheriting permissions through the Active Directory hierarchy. A permission set at the top of a domain can trickle all the way down through nested OUs to objects at the lowest levels of the domain hierarchy.

You can control this inheritance, both from the top down as well as the bottom up. For example, say you’re setting permissions for user objects within an OU hierarchy composed of a top-level Marketing OU and two sub-OUs called Users-East and Users-West. You want to take advantage of inheritance to set permissions for all user objects at the Marketing OU level and have that trickle down to all user objects in both sub-OUs. You can do so by creating the new ACE within the Marketing OU’s ACL (using Active Directory Users and Computers as an example) and then, after setting the permissions, have it apply to all “Descendant User Objects.”

If you were running the Users-East OU, you might decide the permissions placed upon your user objects at the higher level don’t apply. If you have sufficient permissions, you can essentially turn off the inheritance that comes down from the Marketing OU. You can do so by simply clearing the checkbox in the Advanced section of the ACL editor in Active Directory Users and Computers. That breaks that inheritance chain.

Understand delegation

Within the context of Active Directory, delegation is the process by which you grant permissions to Active Directory objects. This lets users and groups perform specific tasks against Active Directory objects. Delegation implies some kind of orderly plan for giving the right users the right permissions on the right Active Directory objects, across your Active Directory structure.

An example of delegation may be a group called Help Desk Admins, to which all help desk team members belong. You can grant this group the ability to reset user passwords on all user objects within your Active Directory domain. This lets them handle one of the primary tasks of their job. Another common example of delegation is letting admins join computers to the domain. This is a delegated permission on computer objects, typically applied to OUs where computer objects might reside.

Creating a delegation model for Active Directory is probably one of the most important planning tasks you can perform. This is especially true when it involves delegating access to sensitive data held within Active Directory. It doesn’t matter whether you’ve just rolled out Active Directory or if you’re in the process of migrating your 10-year-old Active Directory to a new domain structure. In either case, it’s never too late to plan and create a delegation model that protects critical objects within Active Directory and delegates access appropriately.

There’s a lot of data within Active Directory that can and should be secured, but not all of it relates to your identity system. The following list highlights areas to start with in terms of protecting your identity data within Active Directory:

User properties: Attributes on your users may or may not be sensitive and require delegation. There are certain attributes—such as the user’s Job Title, Department and Manager—that are often managed by the HR department. If Active Directory is integrated into an HR system, those attributes might be managed through that system. In that case, you’d want to prevent all users from being able to modify these attributes on their own.

Group memberships: You can use groups to control access to a variety of resources, from public file servers to sensitive database data. Controlling who has permissions to change group memberships is probably one of the first steps you should take in your Active Directory delegation tasks. This translates into who can write to the Members attribute on Active Directory group objects. A user with this permission can modify group memberships.

OU moves: Although moving objects such as users between OUs may seem fairly benign from an identity-management perspective, such a move can often have downstream effects. Some organizations have automated processes associated with OU membership that could change things, such as a user’s group memberships or what Group Policy settings they process. These changes could inadvertently grant the user unintended access to resources. As a result, moving OU user objects should be tightly controlled.

Delegation tools

You have some help with respect to delegation. This comes in the form of the Active Directory Users and Computers Delegation of Control (DoC) Wizard. The DoC Wizard is available whenever you right-click a container object (such as a domain or OU) within Active Directory Users and Computers. It essentially turns a set of standard tasks you might want to delegate within Active Directory into a template.

It also lets you create custom delegation tasks by picking object classes and choosing what rights you need on those classes. The DoC Wizard stamps a set of permissions you’ve requested on the container with which you’re working.

The DoC Wizard makes simple delegation tasks easy, but it does have several shortcomings:

• It only supports a small set of delegation tasks (though you can extend the set).
• It’s a moment-in-time delegation. In other words, no state of the delegation you just performed is kept. Permissions are simply stamped on the Active Directory objects upon which you’re focused. You can’t modify that delegation through the wizard after the fact. You’d need to go in and manually edit permissions on the ACL directly.
• The DoC Wizard gives you no bird’s-eye view of delegation across your entire Active Directory. Because it’s ultimately just stamping privileges, there’s no way to “keep track” of what delegations you’ve done without looking at the ACLs of each Active Directory object of interest.

Active Directory delegation best practices

A number of best practices have emerged over the years that are worth considering as you determine how to create your delegation model and protect your Active Directory data. A common approach is the “role-based” approach to delegating tasks within Active Directory. This involves listing out the tasks you expect people to perform within Active Directory. This list should be fairly long, as you’ll want to really flesh out all those things you expect people to do against your Active Directory, especially when it comes to modifying sensitive objects.

The next step is identifying those groups of users that need to perform each task or role. By performing this mapping between groups that need access to Active Directory and the types of access you want to support, you’re effectively creating a role-based delegation model you can make real through permissions within Active Directory.

You can design an Active Directory delegation model that breaks security of Active Directory into tasks or roles and then assigns those tasks to user groups. This approach can greatly simplify Active Directory security management and take it from reactive granting of permissions to proactive managing of access to Active Directory data.

Consider all these aspects and how they affect the overall security level of the data stored in your Active Directory directories. Combining and parsing all these techniques can help put your Active Directory data at a safe degree of lockdown.