Freigeben über

  • Artikel

Active Directory

Export, Compare, and Synchronize Active Directory Schemas

John Policelli

At a Glance:

  • 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.

fig01.gif

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.

fig02.gif

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.

fig03.gif

Figure 3 Load base schema window

fig04.gif

Figure 4 Present and missing attributes

fig05.gif

Figure 5 Viewing only the missing elements

fig06.gif

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 in Figure 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.

John Policelli (Microsoft MVP for Directory Services, MCTS, MCSA, ITSM, iNet+, Network+, and A+) is a solutions-focused IT consultant with over a decade of experience in architecture, security, strategic planning, and disaster recovery planning. John has spent the past 9 years focused on Identity and Access Management and providing thought leadership for some of the largest installations of Active Directory in Canada. You can reach him via his blog at policelli.com/blog.