Protecting Active Directory

(1)

… … … …… … … … . . … … … . . . … … … …

Network

Frontiers

Whitepaper

Protecting Active Directory

Active Directory has become a very critical piece of every Windows organization. So critical in fact, that tolerance to downtime for an Active Directory server is almost nil.

And yet, most tape-based backup and restoration systems can take from half a day to over a day for restoration of an Active Directory server.

(2)

No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as permitted under § 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the copyright holder. Contact information is [email protected].

(3)

The crucial role of Active Directory

Regulatory requirements – whether Sarbanes-Oxley, California SB1386 or the Health Insurance Portability and Accountability Act (HIPAA) – require that your organization protect sensitive information at all times, regardless of where it is stored. The key to compliance is the ability to monitor and enforce security policies at all times – a task which poses challenges for many organizations. As a critical component of most network infrastructures, Active Directory is positioned to help meet many of these requirements with greater ease and fewer headaches. Active Directory provides a central service for administrators to organize network resources, manage users, computers, and applications. Many different objects can be stored in the Active Directory, including:

•

Users

•

Groups

•

Security credentials such as certificates

•

System resources such as computers (or servers) and printers

•

Replication components, settings are themselves objects in the Active Directory

•

COM component configuration, which was stored in the registry in Windows NT, is now stored in the class store in the Active Directory

•

Rules and policies to control the working environment

(4)

Understanding the layers within an AD

system

Each AD server, called a Domain Controller (DC) uses a three-layer model when creating and accessing Active Directory databases and records.

Directory System Agent Database layer Extensible Storage Engine

Active Directory model

Directory Systems Agent (DSA)

Let’s say that you want to access a server’s directory over your network. When you double-click one of the server’s within your Network Neighborhood, Active Directory is being accessed for verification of privileges, and therefore, the DSA is the first step in the access process. The DSA sits at the top of the three-layer AD model and creates an instance of the directory service, making it available for use. DSA also has the job of then communicating with the underlying layers as well as facilitating AD replication between servers.

The Database layer

The database layer of AD manages and interprets the database tables, and all of the parent-child relationships within the AD database structure. We’ll discuss the actual files that the database maintains below. For now, know that there are really only two tables within the database—the object table holds the database and the link table holds the relationship information.

The Extensible Storage Engine (ESE)

(5)

link tables. Any change made to the database is also appended to the current log file, and its disk image is always kept up to date.

•

Edbxxxxx.log is the current log file. When a change is made to the database, it is

written to the Edb.log file first. When the Edb.log file is full of transactions (10 MB), it is renamed to Edbxxxxx.log (it starts at 00001 and continues to increment using hexadecimal notation). Since Active Directory uses circular logging, old log files are constantly deleted, once their transactions have been written to the database. At any point in time, you will find the edb.log file, and maybe one or more Edbxxxxx.log files.

•

Res1.log & Res2.log are “placeholders” — designed to reserve (in this case) the

last 20 MB of disk space on this drive. This is designed to give the log files sufficient room for a graceful shutdown if all other disk space is consumed.

•

Edb.chk stores the database checkpoint, which identifies the point where the

database engine needs to replay the logs, generally at the time of recovery or initialization. By examining this checkpoint file, AD can write any uncommitted transactions to the database during system startup after a crash.

Tertiary files and components

The Domain Controller is just that, a controller of many network objects within your Windows environment. Therefore, any discussion about the layers and structures of your DC will also have to include some of the key tertiary files and services that also have to be taken into account.

•

System State data on your computer holds vital information for the launching

and operation of the computer. You have to plan for the protection, and restoration, of the system state data if you are to be able to restore an Active Directory server.

•

The system Registry is also vital to the restoration of a Domain Controller. A corrupt or missing Registry is fatal to a Windows system.

•

The other components and services that interact with the Active Directory are

DNS, Certificate Server, and all File Replication Service settings.

How data is written to the database

When data is being changed (added, deleted, modified) on a domain controller, there is a very definite process that takes place.

(6)

1. Once the DSA knows that is going to happen (let’s say a new record is going to be added) a transaction is created by the DSA.

2. The transaction is then written to the transaction log (Edbxxx.log) before being committed to the AD database.

3. Once the transaction has been written to the transaction log, it is then written to

page memory within the DC’s RAM and then onto disk in the form of a table entry

in the Ntds.dit database.

This process isn’t as immediate as it might have seemed when reading it above. The changes aren’t committed to disk until the DC has a period of idle time. Therefore, if the computer crashes after a transaction has been process and written to the log file,

but before the changes have been committed to disk, the DC will use the log file to

update the AD database. If the DC crashes after a transaction has taken place, but

before the transaction can be fully written to the log file, the DC will then roll back the

transaction as if it never occurred.

Setting up the AD server

For performance reasons, the log files and checkpoint file should be located on a different disk than the database to reduce disk contention. For disaster recovery reasons, having the log and checkpoint files on a different disk ensures that if the primary disk fails, the data can be rebuilt from the logs and checkpoint files. If these log files aren’t reconfigured for a different storage location during setup, they will reside in the Ntds directory within C:\WINNT.

During the setup of your system, the AD wizard will default install all of the above listed files within the NTDS directory within the WINNT directory. If you have a single hard drive with a single volume, then so be it.

(7)

Understanding your AD server’s role

In order to backup and restore your Domain Controllers properly, you must understand their role as a service provider in your organization, and in relation to each other. Your DC is a server that hosts a domain database and performs authentication services. In Windows 2000/2003 Server, the domain database is a part of the Active Directory database. In Windows 2000/2003, object changes can be made on any DC within the environment instead of just a primary domain controller (PDC), as in Windows NT Server 4.0. DCs must initiate and perform replication operations to ensure that all DCs in the environment host a current and accurate version of the directory. In case of failure, it is important to know if the particular DC was a GC or operations master role holder so that appropriate action can be taken.

The global catalog

The global catalog's primary function is to provide fast and efficient searches that extend across the entire Active Directory forest. A GC holds a read/write full replica of all objects within the domain for which it is a member and a read-only partial replica (all objects but only a partial attribute set) of every other domain within the forest. The global catalog, therefore, makes directory structures within a forest transparent to end users, creating a search mechanism that makes finding objects in the directory uncomplicated and efficient. In addition, the global catalog is also required for the enumeration of universal group memberships and user principal names (UPNs) in a native Windows 2000/2003 domain. As a result, if a DC cannot contact a GC at the point of client logon, cached local logon credentials are all the client will receive, and access to remote resources will be denied.

(8)

Global Catalog setting

As Windows 2000/2003 DCs hold a replica of all objects belonging to their domain and have full read/write access to these objects, administration (and recovery of the data) of the domain can be done via any DC participating within that domain. These operations affect the state of an object and must therefore be replicated to the other DCs.

However, the replication of changed objects does not occur immediately. Replication is triggered after a period of time, gathering all changes and providing them to other DCs in collections. As a result, in normal operation the Active Directory on any DC can be regarded as always being in a state of loose consistency. That is, the information on all DCs within a Windows 2000/2003 environment is likely to be different as replication changes may be on the way from other DCs or waiting to be triggered.

Let’s say that you have to DCs in your organization—one for production and one for sales. An administrator adds a new server (keyserve1) to the production domain and a different administrator adds a new ordering server (orders) to the sales domain.

prod.yourco.com sales.yourco.com

Global

keyserve1.production.yourco.com

orders.sales.yourco.com

Loose consistency

(9)

Backing up your Domain Controller

There are three things you need to understand in order to back up your domain controller; what you are going to back up, how often you need to perform your backups, and the access rights you’ll need.

Backing up the System State

Active Directory must be backed up as a part of the computer's System State. Depending upon how you set up your files and where you chose to store files, this collection might either be in the WINNT directory of the boot drive, or some of the files might be on other volumes and drives.

•

System Start-up Files (boot files) are the files required for Windows 2000/2003

to boot. They are automatically backed up as part of the System State.

•

System registry contents are automatically backed up when you back up System

State data. In addition, a copy of your registry files are saved in the folder %SystemRoot%\Repair\Regback allowing you to restore the registry without doing a complete restore of the System State.

•

Class registration database of COM+, the Component Object Model (COM), is a

binary standard for writing component software in a distributed systems environment. The Component Services Class Registration Database is backed up and restored with the System State data.

•

SYSVOL, or the system volume, provides a default Active Directory location for

files that must be shared for common access throughout a domain.

•

Active Directory, including the Ntds.dit, Edb.chk, Edbxxx.log, Res1.log and

Res2.log files.

Before you get started, there are a few things you should know:

•

The procedure adds a command line instruction to a scheduled LiveState Recovery backup job.

•

This procedure is to be executed when creating a LiveState Recovery backup job for a domain controller.

•

When restoring a system state, the DC will be down. If it is the only DC in your network, end users will not be able to access domain resources until the procedure is completed.

•

You do not want to find that your system state backup is older than the Active Directory tombstone age (by default, 60 days).

•

Successful execution is indicated by the proper operation of the restored Active Directory.

(10)

On the server, run Notepad (Start > Programs > Accessories > Notepad) and type this line in:

ntbackup backup systemstate /f C:\systemstate.bkf

The ntbackup command line

From the File menu, select Save as, and browse to the CommandFiles folder. On the example server, it is in the default location of C:\Program Files\Symantec\Live State Recovery\Advanced Server 3.0\Agent\CommandFiles. Make sure the filename has a .bat suffix and that the Save as type field is set to All Files. Click

Save.

Save the command file

Start LiveState Recovery (Start > Programs > Symantec >Live State Recovery) and click the Tools menu. Choose Create Backup Job.

(11)

The LiveState Recovery Backup Job Wizard

Select the type of backup job you want to create. The example shows weekly Full Backups. You may also want to schedule daily incrementals if your backup policy calls for it. Click Next.

Backup type selection

Select the drive or drives necessary for the backup. The example server needs only its C:\ drive. Click Next.

(12)

Specify the location you want to write the backup image to. Enter a filename for the image. The example writes the image to a network share, \\backupserver\LiveStateRecovery_images.

Backup location selection

Next, schedule the job. The server’s performance will be impacted for a short time while the backup job runs, so schedule it at an appropriate time when usage is low.

Backup Job Wizard Schedule screen

Choose the compression level. The default is a good compromise between file size and backup speed. If you have limited backup storage space you can also specify

Medium or High compression. Limiting the number of backups saved will also help

(13)

Backup job options

The Advanced button on the Options screen allows you to set password security on the image file itself. Click OK.

Advanced Options dialogue

In the Command Files screen, select the system_state.bat command file under

Before data capture.

The Command Files configuration screen

(14)

Backup job settings summary

You will now have a system state backup file included in the server’s regular backup image.

Ensuring that your backup isn’t on a tombstone

If the backup is older than the tombstone age set in Active Directory, then it is not considered to be a good backup.

When an object is deleted in Windows 2000/2003, the DC from which the object was deleted informs the other DCs in the environment about the deletion by replicating what is known as a tombstone.

A tombstone is a representation of an object that has been deleted but not fully removed from the directory. The tombstone will eventually be removed based on the tombstone lifetime setting, which by default is set to 60 days. If a DC is restored to a state prior to the deletion of an object, and the tombstone for that object is not replicated to the restored DC before the tombstone expires, the object remains present only on the restored DC, resulting in an inconsistency. Thus it is important that the DC be restored prior to expiration of the tombstone, and that inbound replication from a DC containing the tombstone to the restored DC is completed prior to expiration of the tombstone.

Active Directory protects itself from restoring data older than the tombstone lifetime by disallowing the restore. As a result, the useful life of a backup is equivalent to the "tombstone lifetime" setting for the enterprise.

Required rights for backup purposes

(15)

Restoring a domain controller

Restoring a Domain Controller (DC) isn’t as straightforward as restoring a normal computer or even a standard database server. Because of it’s role as a centralized security clearing house, and its replicated peer-to-peer relationship with other Domain Controllers in your organization, you have to take a few more steps to restore a Domain Controller than other devices. For this reason, we will split the restoration procedure directions into two sets—restoring the data of a Domain Controller and restoring the entire database of a Domain Controller.

There are several items to note when thinking about the restoration of a Domain Controller:

•

To restore the System State data, the person performing the procedure must be a Local Administrator.

•

You will also need to ensure that the backup you are restoring was taken within the tombstone lifecycle, by default this is set to 60 days.

If you are going to restore the Domain Controller to a completely different computer, you need to think about these things:

•

By default, the Hal.dll is not backed up as part of System State, however the Kernel32.dll is. Therefore if you are trying to restore a backup onto a machine

that requires a different HAL—to support a multiprocessor environment, for example—you will run into compatibility issues with the new HAL and the original Kernel32.dll. The only workaround for this situation is to explicitly copy the

Hal.dll from the original machine and install it on the new machine. The limitation is

that the new machine will now be bound to using only a single processor.

•

If you backup and restore the boot.ini file, you may have some incompatibility with your new hardware configuration, resulting in a failure to boot. Before restore, ensure that the boot.ini file is correct for your new hardware

environment.

•

If your new hardware has a different video adapter or multiple network adapters, uninstall your video adapters and NICs before you restore data. When you restart the computer; the normal Plug and Play functionality will make the necessary changes.

•

It is direly important that the partitions on the new machine match those on the

original machine. Specifically, all the drive mappings must be the same and the

partition size must be at least the same as on the original machine.

The types of Active Directory restorations

(16)

Elements of a primary SYSVOL restore for a single Domain

Controller

If there is no other functioning DC in the domain, a PRIMARY restore of the SYSVOL should be done. A primary restore builds a new ntfrs (Windows NT File Replication Service) database by loading the data present under SYSVOL on the local DC. This method is the same as non-authoritative except that the SYSVOL should be marked PRIMARY.

Elements of a non-authoritative restore

Using this method, settings and entries that existed in the domain, schema, configuration, and optionally the global catalog naming contexts maintain the version number they had at the time of backup. As such, a non-authoritative restore is the default method for restoring Active Directory.

A non-authoritative restore is performed by restoring the SYSVOL of the Domain Controller in a non-authoritative manner. This is the default SYSVOL restoration method, and during this process the local copy that is held on the restored DC will be compared with that of its replication partners (using MD5 Checksums). Once a non-authoritative restore has been completed, the DC will examine the version number of an object’s attribute in its tables. If the version in the newly restored tables is older than versions on other DCs within the domain, the object will then be updated on the newly restored DC, ensuring that the database is up-to-date and synchronized with the rest of its peers.

Elements of an authoritative restore

An authoritative restore should be used when human error is involved such as when an administrator has accidentally deleted a number of objects; that change has replicated to all the DCs, existence of those objects is removed from the domain; and the administrator is unable to easily recreate these objects.

An authoritative restore requires all the steps of a non-authoritative restore before it can be initiated. The primary difference between the two is that an authoritative restore has the ability to increment the version number of the attributes of all objects in an entire directory, all objects in a subtree, or an individual object (provided that it is a leaf object) to make it authoritative in the directory.

Completely opposite of the non-authoritative restore, because the version number of the object attributes you wish to be authoritative will be higher than the existing instances of the attribute held on replication partners, the objects on the restored DC will appear to be more recent and therefore be replicated out to the rest of the DCs within the environment.

(17)

You should also note that an authoritative restore will not overwrite new objects that have been created after the backup was taken.

Similarly to the Active Directory authoritative restore, this method will typically be used when human error is involved and the error has propagated out to other domain controllers. The authoritative restore of SYSVOL does not occur automatically after an authoritative restore of Active Directory, additional steps are required. By restoring the SYSVOL authoritatively, you are specifying that the copy of SYSVOL that was restored from backup is authoritative for the domain. Once the necessary configurations have been made, the local SYSVOL will be marked as authoritative and be replicated out to the other DCs within the domain.

Performing a non-authoritative restore of a DC (new

OS)

To restore that system state, including the Active Directory, proceed as follows. Install Windows 2000/2003 Server on the computer, following the guidelines in our general caveats discussed earlier. The LiveState Recovery Advanced Server Edition must be installed. Don’t worry about what you are going to name your machine, or whether or not you are going to join a domain at this point. This will all be replaced later.

Do not promote the machine to a Domain Controller.

Reboot the system into Directory Services Restore Mode by pressing the F8 key upon system startup and selecting Directory Services Restore Mode.

Log in as Administrator (local system account, no domain selection is available). Start the LiveState Recovery Backup Image Browser (Start > Programs > Symantec

LiveState Recovery > Backup Image Browser) and select the backup image

containing the system state backup. Click Open.

(18)

Select the system state backup file.

Select the file to restore From the File menu, select Restore.

The Image Browser FIle menu

The Restore Items dialogue appears. Enter a local destination folder, and click

Restore.

Restore Items dialogue

(19)

The ntbackup GUI

Start the Restore Wizard and click the Import File button.

Restore Wizard file selection Select the system state backup file and click OK.

Enter backup file name

(20)

The system state marked for restore

The wizard presents a summary of its restore task. If everything looks correct, click

Finish.

Summary of restore task

When the system state restore is complete, a report is generated with the time elapsed, file sizes and so on. Click Close and reboot the server.

(21)

Restoring the data of a Domain Controller

Restoring the data of a DC is much easier than restoring the entire computer’s Active Directory database structure. Basically, restoration of the DC’s data comes down to whether you can manually reconfigure the DC so that the data is correct, or whether the problem is so drastic that the entire directory needs to be restored from a backup.

Process steps for restoring the data of a Domain Controller

Simply put, if the error can be resolved manually, do so. You’ll save yourself a lot of time and trouble. However, if the error can’t be resolved manually, then you’ll have to ask yourself whether or not the entire directory has to be restored. If you only have a single Domain Controller, then you shouldn’t perform a subtree restore. Instead, you’ll need to perform a Global Catalog restore.

Restoring a subtree of the Active Directory

Restoring a subtree is probably the most common restore method as it corrects an error that concerns only a partial data loss, which is the most common one. Before you get started, there’s a few things you should understand:

•

The procedure restores the entire Active Directory from backup, and then specifies what part of that restore is to be kept (authoritative) when the DC comes back online and synchronizes with other domain controllers.

(22)

•

The procedure requires downtime for the domain controller. If the domain controller is the only one in your network, the entire network will be affected, so the procedure should be carried out after business hours and a warning sent to all users.

•

You must be aware of the Active Directory tombstone lifecycle, by default 60 days. Active Directory will not allow data older than the tombstone lifetime to be restored, and you don’t want to discover that the backup data is too old while performing this procedure.

•

Successful execution is indicated by the desired Active Directory data being restored to the DC and replicated out to any other DCs.

To perform an authoritative restore of a subtree follow these steps:

Reboot the DC into Directory Services Restore Mode by pressing the F8 key upon system startup and selecting Directory Services Restore Mode.

Log in as Administrator with the domain Administrator password.

Start the LiveState Recovery Backup Image Browser (Start > Programs > Symantec

LiveState Recovery > Backup Image Browser) and select the backup image you

want to restore from. Click Open.

Select backup image in Backup Image Browser

(23)

Select the Active Directory folder for the restore

From the File menu, select Restore. Point the Ntds folder to its original location, C:\Winnt. Click Restore.

The Restore Items dialogue

When the restore process has finished, close the Backup Image Browser. Open a command prompt and type ntdsutil, press Enter.

At the next prompt, type authoritative restore and press Enter.

At the next prompt, type restore subtree <path>. Following is an example for a path: OU=Engineering, OU=Cupertino, DC=Whitepaper, DC=com.

At the Authoritative Restore Confirmation dialog box, click OK. Type Quit, and repeat until you exit out of the application.

Restart the server. Confirm that the restored Active Directory contains the correct backup information. If this DC is the only one in your network, you’re done. If it’s not the only one, you may have to force replication of the backed up subtree to the other DCs, as outlined in Microsoft Knowledge Base article #316829, Possible Active

Directory Inconsistency After You Restore a Domain Controller.

Performing a Global Catalog Restore

(24)

A good backup needs to contain at least the system state, the contents of the system disk and the SYSVOL folder. If you have spread out the log and database files on separate disks, those files must be part of the backup. Also, the backup must be newer than the tombstone age set in Active Directory. Here are a few things you should be aware of:

•

The procedure restores the Global Catalog by recovering the entire system volume of an Active Directory server.

•

The procedure is supported by the Symantec Recovery Environment Boot CD.

•

The procedure is to be executed if the Global Catalog server has failed due to a hardware problem or if the Active Directory itself has become corrupted.

•

The procedure entails downtime for the Active Directory service, so end users will be unable to log on to workstations or access network resources for the duration.

•

Due to the importance of the Active Directory service, any trouble with the procedure is potentially serious.

•

Successful execution of the procedure is indicated by the proper operation of the Active Directory services after recovery.

To restore an Active Directory server’s system volume using the boot CD, put the CD in and restart the computer. If your computer doesn’t start from the CD, check that your system is set to boot from CD-ROM. Here’s what you’ll see at the bottom of the screen as the recovery CD boots:

Recovery Environment boot screen

When the system starts, the Recovery Environment is automatically launched. The

System Restore feature is used to restore partitions or entire drives. The Backup Image Browser is for restoring individual files and directories, and the Utilities offer

a collection of network and disk tools.

Symantec Recovery Environment console

(25)

Recovery Environment Utilities

Enter IP address and other information with the Modify button.

Network Configuration

Once you’re done, head back to the Utilities and test connectivity with your backup server with ping.exe. Enter the name of the machine (in our case, “backupserver”) and click OK.

Ping Address, from Utilities

(26)

Ping hostname

Ping IP address

The next step is connecting to the server where you keep your backups. Click on

Utilities and select Map Network Drive.

(27)

Use an account that is local to the backup server and has read permission on your domain controller’s backup folder.

The drive map authentication dialogue

Next, start the System Restore wizard from the Recovery Environment console.

System Restore for recovering an entire drive

System Restore presents you with two choices, Restore drives or Restore files and

folders. The Restore files and folders option simply starts the Backup Image Browser.

So check Restore drives.

System Restore Wizard

(28)

Backup image drive selection

From that drive, select the appropriate image to restore to your system and click

Open.

Restoring C: drive from 10/17/03

Information about the selected image including creation date, image description, and file system size appears in the System Restore Wizard. If all looks correct click Next.

(29)

showing volume labels, sizes, and file system types. In this example, I am restoring the C: drive, which is unlabeled on the disk. It’s not too hard to figure out which volume it occupies as I previously labeled the other partitions. However, if you have more than one unlabeled volumes of the same size, you’ll be guessing. If you’re that unlucky, you could boot back into Windows and label the drive with the Disk Management utility.

Note the volume management options you have at this point. By deleting volumes, you could free up space and restore a larger backup image to the disk. Click Next.

Select the correct volume for the restore

The System Restore Wizard then prompts for error checking (ensures accuracy but takes longer) and advanced restore options including disk signature and master boot record. If you’re recovering the domain controller because of a failed hard drive, then restoring the disk signature is appropriate as it contains information such as drive letter assignments. The master boot record (MBR) can be restored as well. The MBR occupies the first sector of the hard drive and contains information about disk partitions and OS boot location. Click Next.

System Restore options

(30)

Last chance to make changes

A progress screen gives you the percent completion and elapsed time.

Progress of the C: drive restore

(31)

Restoring the Database of a Domain

Controller

In case of a complete failure of a Domain Controller or an Organisations Master it can be unavoidable to restore the whole database of the server. The reason for this is that secure channel issues come into play when a DC remains disconnected from other DCs for a period greater than that specified in the maximumpasswordage registry entry. This issue can be corrected using the following decision tree:

Process Steps for restoring the Database of a Domain Controller

If the Domain Controller that you have to restore was the only Domain Controller on your network you need to perform a Global Catalog Restore. If the Domain Controller was an operations master you can seize the roles that have disappeared with the server, otherwise perform a Non-Authoritative Restore.

Seizing the Schema Master Role

Before you seize the schema master make sure that the current operations master has been removed from the network. Also verify that the copy of the schema on the new operations master is up to date with the rest of the domain controllers in the forest. Next perform the following steps to seize the schema master:

1. Click Start, click Run, type cmd and hit the Enter key

(32)

4, At the fsmo maintenance prompt type connections and hit the Enter key

5. At the server connections prompt type connect to server followed by the fully qualified domain name and hit the Enter key

6. At the server connections prompt type quit and hit the Enter key

7. At the fsmo maintenance prompt type seize schema master and hit the Enter key

8. At the fsmo maintenance prompt type quit and hit the Enter key

9. At the ntdsutil prompt type quit and hit the Enter key

After you have seized the schema master make sure that the previous schema master never gets connected to your network again.

Seizing the Domain Naming Master Role

Before you seize the domain naming master make sure that the current operations master has been removed from the network. Also verify that the new operations master is up to date with the rest of the domain controllers in the forest. Next perform the following steps to seize the domain naming master:

2. At the command prompt type ntdsutil and hit the Enter key 3. At the ntdsutil prompt type roles and hit the Enter key

4. At the fsmo maintenance prompt type connections and hit the Enter key

7. At the fsmo maintenance prompt type seize domain naming master and hit the Enter

key

After you have seized the schema master make sure that the previous schema master never gets connected to your network again.

Seizing the Relative ID Master Role

(33)

7. At the fsmo maintenance prompt type seize RID master and hit the Enter key

Seizing the PDC Emulator Role

Before you seize the PDC emulator master make sure the current operation master has been removed from the network and verify that the new operations master is up to date. Next perform the following steps to seize the PDC emulator:

7. At the fsmo maintenance prompt type seize PDC and hit the Enter key

You can return the original PDC emulator to service later and return the role to it.

Seizing the Infrastructure Master Role

(34)

7. At the fsmo maintenance prompt type seize infrastructure master and hit the Enter key

Protecting Active Directory

Network

Frontiers

Whitepaper

Protecting Active Directory

Contents

The crucial role of Active Directory

•

•

•

•

•

•

•

Understanding the layers within an AD

system

Directory Systems Agent (DSA)

The Database layer

The Extensible Storage Engine (ESE)

•

•

•

Tertiary files and components

•

•

•

How data is written to the database

Setting up the AD server

Understanding your AD server’s role

Backing up your Domain Controller

Backing up the System State

•

•

•

•

•

•

•

•

•

•

Ensuring that your backup isn’t on a tombstone

Required rights for backup purposes

Restoring a domain controller

•

•

•

•

•

•

The types of Active Directory restorations

Elements of a primary SYSVOL restore for a single Domain

Controller

Elements of a non-authoritative restore

Elements of an authoritative restore

Performing a non-authoritative restore of a DC (new

OS)

Restoring the data of a Domain Controller

Restoring a subtree of the Active Directory

•

•

•

•

Performing a Global Catalog Restore

•

•

•

•

•

•

Restoring the Database of a Domain

Controller

Seizing the Schema Master Role

Seizing the Domain Naming Master Role

Seizing the Relative ID Master Role

Seizing the PDC Emulator Role

Seizing the Infrastructure Master Role