High availability solution in Active Directory and Exchange Server

Friday, 6 June 2014

Disaster Recovery: Active Directory Users and Groups

Active Directory is one of the most critical services in a Windows network. To avoid downtime and loss of productivity, it’s essential that you have effective disaster recovery plans in place for problems related to Active Directory. This point may sound obvious, but it’s

amazing how many administrators don’t have a plan for one of the most common Active Directory®failure scenarios: accidental deletion of data.

Accidental deletion of objects is one of the most common root causes of service failure. When I do seminars and conferences, I often ask who has had an Active Directory failure due to accidental deletion of data. And every time, nearly everyone raises his hand.

To understand why data recovery is so complex, you first need to understand the following: how Active Directory stores and replicates objects, how it deletes objects, and the mechanics of authoritative and non-authoritative restores.

Storing Objects

Active Directory is a specialized object database that implements the X.500/LDAP data model. The data store (called the Directory Information Tree or DIT) is based on the Extensible Storage Engine (ESE), an indexed sequential access method (ISAM) database engine. Conceptually, Active Directory stores the DIT in two tables: the data table (which contains the actual Active Directory objects and attributes), and the link table (which contains the relationships between objects).

Each Active Directory object is stored in a separate row in the data table, with one column per attribute. The data table contains all the entries for all of the replicas stored on the domain controller (DC). On a normal DC, the data table contains entries from the domain NC (naming context), the configuration NC, and schema NC. On a global catalog, the data table contains entries for each object in the forest.

Active Directory uses the distinguished name tag (DNT)—a 32-bit integer—to uniquely identify each row in the data table. The DNT, used to refer to objects internally, is much smaller than other identifiers like the distinguished name (DN) and the objectGUID (a 16-byte binary structure). But unlike the objectGUID, the DNT is a local identifier, and is different on each DC.

How Active Directory Links Objects

Active Directory manages two kinds of relationships between objects in the DIT: the parent-child relationship (also referred to as the container relationship) and the reference relationship (also referred to as the link relationship). To implement the parent-child relationship, Active Directory stores an additional column in the data table called the parent distinguished name tag, or PDNT. This column always contains the DNT of the object’s parent.

Each attribute in Active Directory is defined by an attributeSchema object in the Active Directory Schema container. Certain attributes in Active Directory are defined as link attributes, as determined by an even, non-zero value in the linkID attribute of the attributeSchema object. Link attributes establish a relationship between objects in the directory and can be single-valued or multi-valued. The member attribute of a group object is an example of a multi-valued link attribute—it establishes a link between the group object and its member objects.

Even though it appears that the member attribute of a group contains the DNs of the members (as displayed by the Active Directory Users and Computers snap-in, for instance), this is not how Active Directory stores them. When you add the DN of a member object to a group’s member attribute, Active Directory stores the object’s DNT, not its DN. Since the DNT doesn’t change, even when an object is renamed, you can rename a user object and Active Directory won’t have to sort through all the groups in the system to update the DN in each of the member attributes. This is how Active Directory maintains referential integrity within the DIT. Figure 1 shows a representation, though greatly simplified, of how the data table and link table relate to each other. These tables show that the three user objects—Molly Clark, Alexander Tumanov, and Makoto Yamagishi—are all members of the Senior Engineers group.

Figure 1 How data and link tables relate

Data Table
DNT	PDNT	Object Class	Cn
14529	14401	organizationalUnit	Engineers
14530	14529	Group	Senior Engineers
14531	14529	User	Molly Clark
14532	14529	User	Alexander Tumanov
14533	14529	User	Makoto Yamagishi
Link Table
Attribute	DNT	Forward Link
Member	14530	14531
Member	14530	14532
Member	14530	14533

These links are called forward links. Similarly, Active Directory also provides backward link attributes. These provide a reference from the linked-to object back to the object that refers to it, meaning the object with the forward link. The memberOf attribute for users and groups is an example of a back link attribute. The attributeSchema object that describes a back link attribute has a linkID value that is one greater than the even-numbered linkID value of the corresponding forward link attribute. For instance, the member attribute in the Windows Server® 2003 R2 schema has a linkID value of 2; the memberOf attribute that serves as the back link has a linkID value of 3. For more information Figure 2 provides a list of the linked attributes defined by default in the Windows Server 2003 R2 schema.

Figure 2 Link attributes in the Windows Server 2003 R2 schema

Forward Link Attribute	linkID	Back Link Attribute	Linked
member	2	memberOf	3
manager	42	directReports	43
owner	44	ownerBL	45
siteObject	46	siteObjectBL	47
nonSecurityMember	50	nonSecurityMemberBL	51
queryPolicyObject	68	queryPolicyBL	69
privilegeHolder	70	isPrivilegeHolder	71
managedBy	72	managedObjects	73
hasPartialReplicaNCs	74
hasMasterNCs	76	masteredBy	77
syncMembership	78
serverReference	94	serverReferenceBL	95
bridgeheadTransportList	98	bridgeheadServerListBL	99
netbootServer	100	netbootSCPBL	101
frsComputerReference	102	frsComputerReferenceBL	103
fRSMemberReference	104	fRSMemberReferenceBL	105
fRSPrimaryMember	106
siteLinkList	142
siteList	144
msCOM-PartitionLink	1040	msCOM-PartitionSetLink	1041
msDS-NC-Replica-Locations	1044
msFRS-Hub-Member	1046
msCOM-UserPartitionSetLink	1048	msCOM-UserLink	1049
msDS-SDReferenceDomain	2000
msDS-HasInstantiatedNCs	2002
msDS-NonMembers	2014	msDS-NonMembersBL	2015
msDS-MembersForAzRole	2016	msDS-MembersForAzRoleBL	2017
msDS-OperationsForAzTask	2018	msDS-OperationsForAzTaskBL	2019
msDS-TasksForAzTask	2020	msDS-TasksForAzTaskBL	2021
msDS-OperationsForAzRole	2022	msDS-OperationsForAzRoleBL	2023
msDS-TasksForAzRole	2024	msDS-TasksForAzRoleBL	2025
msDS-HasDomainNCs	2026
msSFU30PosixMember	2030	msSFU30PosixMemberOf	2031
msDS-hasMasterNCs	2036	msDs-masteredBy	2037
msDS-ObjectReference	2038	msDS-ObjectReferenceBL	2039
msDFSR-ComputerReference	2050	msDFSR-ComputerReferenceBL	2051
msDFSR-MemberReference	2052	msDFSR-MemberReferenceBL	2053

Back link attributes are always multi-valued and they’re maintained automatically by Active Directory. In fact, you can’t directly modify a back link attribute. Even though it appears that you can modify the memberOf attribute of a user or group through the Active Directory Users and Computers MMC snap-in, the snap-in is actually modifying the member attribute of the corresponding group, and Active Directory updates the memberOf attribute behind the scenes. This is why you don’t need permissions on the user object to add the user to a group; you are really only modifying the member attribute of the group object. Because each DC manages its back link attributes locally, changes to back links are never replicated. Only the change to the forward link attribute, such as the member attribute of a group, is replicated.

On a normal DC, the data table contains entries for domain objects as well as objects from the Configuration and Schema containers. But some group types can contain references to objects that reside in another domain. How does Active Directory store a DNT for an object that is not in its data table? The answer lies with the Infrastructure Master FSMO (Flexible Single Master Operations) role owner and something called a phantom object.

Phantom Objects

When you add a member from one domain to a group in another domain, Active Directory automatically creates a special object in the data table called a phantom, which contains the objectGUID, objectSid, and DN of the new member. This provides a DNT that can be stored in the member attribute of the group. If a domain controller is a global catalog, it will not need to create a phantom because it already has an entry in its data table for each object in the forest.

The DC that holds the Infrastructure FSMO role periodically checks the entries in its data table against a global catalog and when it finds that an object has been moved, renamed, or deleted, it updates the phantoms in the data table and replicates the change to the other DCs in the domain. And by virtue of a reference count, the infrastructure master can also remove phantoms that are no longer referred to by any forward link attribute in the domain.

Phantoms allow DCs to manage references to objects in other domains within the forest, but forward link attributes can also refer to objects that are outside the forest—for instance, in a trusted domain. In this case, Active Directory creates an object called a foreign security principal (FSP) in the CN=ForeignSecurityPrincipals container in the domain NC. The FSP contains the foreign object’s Security Identifier (SID) and other attributes that identify the object in the foreign domain, but there is no process to ensure that the FSP is kept up to date. For the purposes of data recovery, we treat FSPs as we would any other Active Directory object.

Deleting Objects

Here, I focus primarily on restoring users and their group memberships. However, the same principles apply to recovering other linked attributes.

When Active Directory deletes an object, it doesn’t physically delete the object from the DIT. Instead, it marks the object as deleted by setting its isDeleted attribute to true, which renders the object invisible to normal directory operations. Active Directory removes all attributes that are not designated to be saved, as defined by the schema, and changes the relative distinguished name (RDN) of the object to <old RDN>\0aDEL:<objectGUID>. It then moves the object to the CN=Deleted Objects container for the NC. (There are some classes of objects in the Configuration NC that Active Directory does not move to the Deleted Objects container.) Active Directory removes any forward links to other objects that the deleted object holds—which reduces their reference count in the link table. If there are other objects that contain forward links to the now deleted object, Active Directory removes those links as well.

The resulting object is a called a tombstone. Active Directory replicates this tombstone to other DCs, where the same changes are made. Note that Active Directory does not replicate the changes made to forward links that refer to the deleted object. Each DC makes the equivalent change locally, so there is no need to replicate it. This has consequences for recovering group memberships, as I will discuss later in the article.

Active Directory maintains tombstoned objects in the DIT as determined by the tombstoneLifetime attribute of the CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=<root domain> object. The garbage collection process on each DC removes tombstones that are older than the configured tombstone lifetime. By default, the tombstone lifetime is 60 days for Windows® 2000, Windows Server 2003, and Windows Server 2003 R2. It is 180 days for Windows Server 2003 SP1.

The tombstone lifetime has a significant bearing on the restore process. You cannot restore from a backup that is older than the tombstone lifetime. Because objects that have been deleted and then garbage collected from the domain no longer have tombstones, the deletion operation will never re-replicate to the restored DC. The deleted objects will then remain on the restored DC as lingering objects and the restored DC will never properly converge with the other DCs in the domain.

Replicating Objects

Whenever a domain controller performs an update operation of any sort—for instance adding an object or modifying an attribute—the DC assigns a unique 64-bit number to the update operation, called an update sequence number (USN). Active Directory tags the objects and attributes that are updated with the USN to help determine whether they need to be replicated.

Active Directory replicates objects on an attribute-by-attribute basis. That is, if you modify an attribute of an object, Active Directory will replicate just that attribute, not the entire object. To do this, Active Directory keeps track of the changes it makes to each attribute with replication metadata. The replication metadata for an attribute includes:

The local USN, which identifies the change operation on the local DC.
The invocationID of the DC that originated the change (specifically, the invocationID attribute of the DC’s corresponding nTDSSettings object), which identifies a particular generation of the DIT on a domain controller.
The USN of the original operation as it exists on the originating DC.
A time stamp that contains the DC system time for when the originating change was made.
A 32-bit sequential version number that is incremented each time the value is changed.

When a destination DC requests changes from its source DC partner, it sends the USN of the last successfully replicated change to the source DC along with an up-to-dateness vector that includes the largest originating USN the destination DC has seen from each DC that has a replica of the NC being replicated. The source DC uses this information to send only those updates that the destination DC has not already seen.

As the destination DC processes the incoming attribute updates, it checks the version number of each attribute. If the version number of an incoming attribute is greater than the version the DC already has for that attribute, the DC stores the incoming value. If the incoming version number is equal to the version the DC already has, the DC compares the timestamps and uses the attribute with the latest timestamp. If the timestamps are the same, the destination DC chooses the value with the largest invocationID. This guarantees that every DC will eventually settle on the same value for every replicated attribute.

Linked Value Replication

In Windows 2000, Active Directory replicated multi-valued attributes in the same fashion as single-valued attributes. This caused problems for large, dynamic group objects whose multi-valued member attribute could change frequently on different DCs. If an administrator added a user to a group on one DC and a different administrator added a different user to the group on another DC within the replication latency window, Active Directory would choose the later addition and completely lose the earlier addition. Microsoft addressed this problem in Windows Server 2003 with a process called linked value replication (LVR).

With Windows Server 2003 forest functional level or interim forest functional level, Active Directory replicates the individual values of multi-valued forward link attributes separately, with each value having its own replication metadata. This effectively solves the problem found in Windows 2000 where nearly simultaneous updates of group membership on different DCs could cause data to be lost.

There is one point to be aware of, however. Raising the forest functional level does not automatically fix up existing multi-valued link attributes with the new replication metadata. Only values that are added after raising the forest functional level will have the new metadata. This will have a significant effect on recovering group memberships, as you’ll see in a moment.

Backing Up

Windows includes the very basic NTBACKUP utility, which can be used to perform a system state backup of a DC. The system state of a domain controller includes its registry, SYSVOL, Active Directory DIT files, and critical system files. Most third-party backup utilities also have the ability to backup and restore the system state of a DC.

To perform a system state backup to a disk file, use the following command:

NTBACKUP backup systemstate /F “<filename>”

Here, <filename> is the name of the backup file to be created and should use the .bkf extension.

Performing a Non-Authoritative Restore

Restoring deleted Active Directory objects from backup is a two-step process. First, you reboot the DC into Directory Services Restore mode (DSRM) and then you restore the entire Active Directory DIT from the system state backup using the Windows NTBACKUP utility or an equivalent third-party product. This process will overwrite the entire DIT.

There are two ways to boot a DC into DSRM. If you have access to the system console of the DC, shut down and restart the DC and press F8 when prompted to bring up the Windows boot menu. Select Directory Services Restore from the menu and enter the DSRM password.

If you are managing the server remotely, you won’t be able to access the Windows boot menu. Instead, you can change the system boot options by selecting Properties from My Computer, clicking the Advanced tab, and pressing the Settings button located under Startup and Recovery. Press the Edit button in the System startup section to edit the boot.ini file, and add the switch /SAFEBOOT:DSREPAIR to the end of the line, as shown in Figure 3. (For more information about boot.ini switches, see microsoft.com/technet/ sysinternals/information/bootini.mspx.)

Figure 3 Setting boot options for DSRM (Click the image for a larger view)

When you reboot the server, it will come up in DSRM. Remember that you have to remove the /SAFEBOOT switch from boot.ini when you want to restart the DC in normal mode.

Once you’ve logged in using the DSRM password, restore the system state backup using the NTBACKUP command again, but without specifying any parameters. (You can’t perform a restore using NTBACKUP from the command line.) When the wizard comes up, select Restore files and settings and click Next. Then select the backup file and check the System State box as shown inFigure 4.

Figure 4 Using the Backup or Restore Wizard to restore system state (Click the image for a larger view)

If you were to boot the DC back into normal mode at this point, the Active Directory replication process would bring the restored domain controller back into sync with the other DCs in the domain, and all of the restored data would be overwritten with current data. Clearly, this isn’t your goal. Instead, you need a way to force the objects being restored to replicate out to the other domain controllers in the domain.

Performing an Authoritative Restore

NTDSUTIL also increases the version number of each attribute by 100,000 for each day between the date of the backup and the date of the restore. Unless there are attributes that are being updated more than 100,000 times a day (a pretty unlikely scenario), the version number of the restored attributes will be much greater than the version numbers held by other DCs, and the authoritatively restored object will replicate to the other DCs. The other objects that were restored non-authoritatively from backup will be ultimately overwritten by the existing data from the other domain controllers.

After you’ve completed the non-authoritative restore, but before you reboot into normal mode, you use the NTDSUTIL program to perform an authoritative restore of the objects you want to recover. Despite the name, authoritatively restoring an object does not "restore" it; it simply ensures that Active Directory will replicate the object to the other DCs. To do this, NTDSUTIL assigns the next available USN to the local USN of the attributes of the object. This causes the object to be sent to replication partners the next time they synchronize. To restore a single object, make sure the DC is booted in DSRM, and follow these steps:

Open a command window and type:
```
ntdsutil
```
At the ntdsutil prompt, type:
```
authoritative restore
```
At the authoritative restore prompt, type:
```
restore object “<DN of object to be restored>”
```
For example, if you want to restore the Molly Clark account from the Eng OU in the DRNET domain, you would enter:
```
restore object “CN=Molly Clark,OU=Eng,DC=DRNET,DC=com”
```
If you want to authoritatively restore an entire directory subtree, for instance an OU, you would instead enter:
```
restore subtree “OU=Eng,DC=DRNET,DC=com”
```
(NTDSUTIL also provides a restore database command that authoritatively restores the entire domain as well as the configuration and schema NCs. Restoring the entire domain is fraught with peril and I don’t recommend you use that option. If you need to restore an entire domain, you should restore one domain controller and repromote the other DCs in the domain as described in "Planning for Active Directory Forest Recovery",
When prompted, confirm that the authoritative restore should increase the version numbers of the respective objects and their attributes.
Exit ntdsutil (you’ll need to type quit two times).
Reboot the DC into normal Active Directory mode.

The next time the DC replicates with its partners, the user you restored will replicate out. But restoring the user object is only half the problem. When you introduce object links like those between a group and its members, the situation is more complicated. There are a few fundamental problems you may face during and after the restore, which I will describe in the next few sections.

First, let’s review what happens when you delete an object that has back links. Say you delete a user object that is a member of one or more groups. Each domain controller that has a copy of the user object will convert it into a tombstone and remove any references from the link table, thereby removing the user object from any group memberships in the user’s domain. (Remember that removing the user from group memberships is not a replicated change since each DC updates the group membership locally. The version number and local USN of the group’s member attribute remain unchanged.) A short time later, the phantom objects will be removed from the link tables in other domains, again without updating the replication metadata of the group’s member attribute.

When you non-authoritatively restore the DIT on a domain controller in the user’s domain, you recover the user object along with all of the group memberships in groups in the domain, so the restored DC is self-consistent. And after you use the NTDSUTIL utility to authoritatively restore the user, the user object replicates out to all the other DCs in the domain.

But because the replication metadata of the current groups in the domain is unchanged, the member attributes of the groups on the restored DC are inconsistent with those on the other DCs. And there is nothing to make them converge on a common state. Thus, the user’s memberships will not be restored on the other DCs in the domain.

Problem: Group Memberships within the Domain Don’t Restore

Authoritatively restoring the user object does not recover the user’s group memberships. Why not? Because the membership relationship is stored and replicated using the member attribute of the group objects (the forward-links), not the memberOf attribute of the user (the back-link). The problem is how to find the user’s old group memberships and, once you know them, how to recover them properly.

Microsoft has made incremental improvements to the process of recovering a user’s group memberships, so the technique you use depends on the version of Active Directory you are running. The following section applies primarily to Windows 2000 Active Directory.

Determining the user’s old group memberships is pretty easy: simply inspect the backlink attribute on the restored DC—in this case, the memberOf attribute of the user object. The memberOf attribute will contain all of the memberships to local and global groups in the user’s domain. You can use the Active Directory Users and Computers MMC snap-in (ADUC), or you can use the LDIFDE utility, which is included with Windows Server, to list the restored user’s group memberships.

The following LDIFDE command line will list the groups in the DRNET domain that Molly Clark is a member of, storing the results in the output.ldf file:

C:\> ldifde –r “(distinguishedName=CN=Molly Clark,
OU=Engineering,DC=DRNET,DC=Local)” –l memberOf –p Base –f output.ldf

Note that you must boot the DC into normal mode to use any LDAP tools and, again, you must disable inbound replication; otherwise the data you restored would be overwritten. The easiest way to disable inbound replication is to use the REPADMIN command:

REPADMIN /options <dcname>+DISABLE_INBOUND_REPL

Here, <dcname> is the name of the DC you are restoring to. And don’t forget to re-enable replication using –DISABLE_INBOUND_REPL when you are finished.

If you are recovering only a few users, simply adding the user back to the groups manually using ADUC is pretty easy. If you are recovering more than a few users, there are some tools that can automate some of the process. The Microsoft GROUPADD utility (available from Microsoft Product Support Services) can accept the LDIF file you created to list the user’s old group memberships, and in turn generate an LDIF file that recreates those memberships. For instance, you would use this GROUPADD command to process the LDIF file we created in the earlier example for Molly Clark:

C:\> groupadd /after_restore output.ldf

This command will create a new LDIF file for each domain that Molly Clark had group memberships in with the name groupadd_<domain>.ldf (where <domain> is the fully qualified domain name of the domain whose groups will be updated). You would import the LDIF file created above with the following command:

C:\> ldifde –i –k –f groupadd_child.drnet.net.ldf

With Windows Server 2003, Microsoft improved NTDSUTIL to take advantage of the additional metadata that is present in the member attribute to support link-value replication (LVR). If the restored user object had been a member of any groups in the domain, and the user’s group membership was stored with LVR metadata, then NTDSUTIL increases the version number of the corresponding value of the member attribute, which then causes the restored membership to replicate out.

The Windows Server 2003 SP1 version of NTDSUTIL incorporates the GROUPADD functions and will automatically create LDIF files as it performs the authoritative restore of the user object. Figure 5shows the new version of NTDSUTIL, and Figure 6 shows the contents of the automatically created LDIF file.

Figure 6 Contents of LDIF file created by NTDSUTIL

dn: CN=EngDL,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngDL,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngGG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngGG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngUG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngUG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-

Figure 5 New NTDSUTIL with GROUPADD capabilities built in (Click the image for a larger view)

If you are restoring an entire OU that contains a number of users and groups, adding the users back to their groups manually is quite tedious. Another way to recover the restored group memberships is to authoritatively restore the groups themselves.

There are two problems with authoritatively restoring groups, though. The first problem is fairly obvious: if you restore a group, the membership in that group will revert to its state as of the time of the backup. This means that any changes you have made to the group since the last backup will have to be reapplied to the group. The second problem is a little more subtle and has to do with the way Active Directory replication works. After an authoritative restore of both users and groups, there is no guarantee in which order they will replicate out. If a group object replicates to a DC before the restored user object, the replicating domain controller will automatically remove the user reference from the group because the user object does not yet exist on that DC. When the user object replicates in later, it will not be added to the group.

The easiest solution to this problem is to perform the authoritative restore of the groups a second time. After you perform the first authoritative restore, reboot into normal mode and make sure that replication takes place properly. Then reboot back into DSRM and run NTDSUTIL to perform an authoritative restore of the groups the user was a member of. This guarantees that when you boot back into normal mode, the user object will have replicated out before the group objects referring to it replicate.

Problem: Group Memberships in Other Domains Don’t Restore

The "which groups was this user a member of" problem is actually more difficult than I’ve described. The user you’re restoring may have been a member of domain local and universal groups in other domains and those group memberships will not be restored when you do the non-authoritative restore. So how do you know what groups the user belonged to in other domains? The answer is in the global catalog. Along with its own domain’s data, the global catalog contains a read-only copy of the data from the other domains in the forest.

To take advantage of the global catalog’s forest-wide data, you must perform the non-authoritative restore on a global catalog, which means you must have backed up a global catalog to begin with. Now, when you run LDIFDE to identify the user’s group memberships, you can find out the user’s universal group memberships from other domains.

When you list the group memberships of the user you are recovering, connect to the global catalog port 3268 instead of the default 389, and specify the root domain of the forest as the base of the search. LDIFDE will display the recovered user’s group memberships, including membership in universal groups in all the domains in the forest. Here’s how to do this:

C:\> ldifde –r “(distinguishedName=CN=Don Clark,
OU=Engineering,DC=DRNET,DC=Local)” -t 3268 –l memberOf –p Base –f output.ldf

If you run GROUPADD or the new NTDSUTIL on a global catalog, you will produce one LDIF file for the user’s domain, and one LDIF file for each domain in which the restored user was a member of a universal group. When you import these LDIF files, you will restore all the group memberships for the user. Well, almost all—which brings us to the next problem.

Problem: Recovering Domain Local Group Memberships in Other Domains

There are three kinds of groups in a Windows Active Directory environment. Global groups can only contain members in the same domain, but can be used as a member within domain local groups in its own domain and other domains in the forest. The member attribute of global groups does not appear in the global catalog, but this is not an issue because global groups only contain members from their own domain. Universal groups can contain members from any domain and can be used as members in other universal groups in the forest and in domain local groups in its own domain and other domains in the forest. The member attribute of universal groups is replicated to global catalogs. Domain local groups can contain members from any domain in the forest, but cannot be used as members in groups in other domains. More importantly, the member attribute of domain local groups, like that of global groups, does not appear in the global catalog. The result is that there is no easy way to recover the user’s membership in domain local groups in other domains.

Before Windows Server 2003 SP1, the only way to recover domain local group memberships in foreign domains was to restore a DC in each domain, manually search the domain data for any domain local groups that contained the restored user, and then add the user back to the groups you identified. In a large environment with lots of domains, this approach is prohibitively time-consuming.

The Windows Server 2003 SP1 version of NTDSUTIL can help. When you run NTDSUTIL on a domain controller, the utility creates a text file that contains the DN and GUID of the restored user objects. Then for each foreign domain, you can non-authoritatively restore a single DC, copy the text file to the DC, and run NTDSUTIL to generate a new domain-specific LDIF file that adds the recovered user back to the domain local groups it was a member of.

To do this, perform the following steps on a DC in each foreign domain:

Boot the DC in the foreign domain into DSRM.
Use NTBACKUP to restore a copy of the DIT that contains the restored user’s group memberships.
Copy the .txt file created by NTDSUTIL to the current DC.
Open a command window and type ntdsutil.
Type authoritative restore.
Type create LDIF file(s) from <file name> (where <file name> is the name of text file).
Type quit two times to exit ntdsutil.
Reboot the DC to normal Active Directory mode.
Type ldifde –i –f <ldif filename> (where <ldif filename> is the name of the LDIF file you just created).

And now you have restored all the deleted user’s group memberships.

Step-by-Step

Recovering Active Directory users and their group memberships, particularly in a multi-domain environment, is complicated. The specific steps required to properly recover group memberships depend on the version of Windows you are running.

If you are running Windows 2003 SP1, you would take the following steps:

Boot a GC into DSRM and perform a system state restore using a backup that contains the deleted user.
Use NTDSUTIL to perform an authoritative restore of the deleted user. NTDSUTIL will create a text file containing the restored object DNs and GUIDs, and one or more LDIF files to restore the user’s group memberships.
Use LDIFDE –i –f <LDIF filename> (where <LDIF filename> is the name of the LDIF files created in step 2) to import the group memberships in the current domain and other domains.
Reboot the global catalog into normal mode.
On a DC in each foreign domain, boot into DSRM and perform a system state restore using a backup that contains the group memberships of the restored user.
Run NTDSUTIL using the create ldif files command.
Reboot the DC into normal mode.
Using LDIFDE –i –f <filename> (where <filename> is the name of the LDIF file you created in step 6) to restore the group memberships in the foreign domain.
At this point you can optionally force replication with REPADMIN /syncall.

If you are running a version of Windows Server 2003 without SP1 installed, or if you are running Windows 2000, there are some additional steps involved. Since the older version of NTDSUTIL doesn’t create LDIF files, use the GROUPADD utility to create them. The process is:

Boot a global catalog into DSRM and perform a system state restore using a backup that contains the deleted user.
Disable the NIC or unplug the cable to prevent inbound replication.
Reboot the global catalog in normal mode.
Use LDIFDE –r "(distinguishedName=<dn>)" -t 3268 -l memberOf –p Base -f membership.ldf to dump the membership of the user with the distinguished name <dn>.
Use GROUPADD /after_restore membership.ldf to create LDIF files.
Use LDIFDE –i –f <filename> (where <LDIF filename> is the name of the LDIF file created by GROUPADD in Step 5) to import the group memberships in the current domain and other domains.
Re-enable inbound replication using REPADMIN /options <dcname> -DISABLE_INBOUND_REPL.
On a DC in each foreign domain, boot into DSRM and perform a system state restore using a backup that contains the group memberships of the restored user.
Reboot the DC into normal mode.
Using LDIFDE –i –f <filename> (where <filename> is the name of the LDIF file created by GROUPADD in step 5) to restore the group memberships in the foreign domain.
At this point, you can optionally force replication with REPADMIN /syncall.

The only thing left now for the pre-Windows Server 2003 SP1 environment is to recover the foreign domain local group memberships for the restored user. Your only choices are to manually restore the domain local group memberships or to restore a DC from backup and authoritatively restore the domain local groups.

Summary

Even though it’s quite easy to accidentally delete users or even OUs from Active Directory, properly recovering the deleted users and their group memberships can be surprisingly complex, time-consuming, and error-prone. To ensure that you can recover from these sorts of disasters as quickly as possible, you have to understand the mechanics of object linking, replication, deletion, and authoritative restores.

Do you think you can get all the steps right the first time you try this in your production environment? To make sure you’re ready the next time you have to recover the CEO’s user object, have a written plan prepared for recovering deleted objects. And be sure to practice the plan at least once or twice before you have to try it on real data. Your boss (and your CEO) will appreciate it.

Recovering from a complete domain-level Active Directory crash

Having an entire Active Directory domain fail is almost unthinkable. Almost. Ignore the odds and prepare for the worst, as Brien Posey shows you how to recover from this unlikely but devastating event.

What could possibly be worse than having a server on your network crash? How about havingevery server on your network become inaccessible because of a massive, domain-wide Active Directory failure? As horrifying as a total domain failure may sound, the solution could be just as scary. You may be able to salvage the domain, but, if you can’t, you may have to strip the domain bare, delete the domain, re-create the domain, and finally, add the servers back into the domain. I’ll show you how to recover from a domain-level Active Directory failure and avoid this worst-case scenario.

Back up now before it's too late
Recovering from a domain-level Active Directory failure is a major undertaking. Make absolutely certain that you have a good backup of your entire Active Directory before you try any of these techniques.
You should also make sure that you’ve tried every other possible diagnostic and repair technique before attempting to work through any of the techniques that I’m about to discuss. These techniques may solve your problem, but they stand an equal chance of destroying Active Directory completely. If you’re sure you’re ready, let’s roll the dice.

Trying to save the domain
As you may recall, various operations master roles are associated with some of the critical Active Directory functions. Some of these roles are forest-based and others are domain-based. A domain can’t function if the domain-level operation master roles aren’t being performed. Therefore, there’s a chance that, rather than having a corrupt Active Directory database, you may simply have a domain controller that’s failing to perform its designated roles.

The first step to recovering from such a problem is to note which servers are performing which roles. You need to make note of the forest-level roles as well as the domain-level roles. If the forest-level roles are being handled by a domain controller within the failing domain, you certainly don’t want to do anything to disrupt the servers that are performing the server-level roles. If the forest-level roles are handled by a domain controller within the failing domain and the rest of your domains seem to be functioning correctly, it’s a good indication that you may simply have a domain-level role failure rather than an entire domain failure.

When the entire domain fails, the other domains usually won’t be able to communicate with the failed domain and also cease to function. For detailed instructions on locating the various server roles, see “Understanding Windows 2000 domain controller operations master roles.”

Once you’ve determined which server holds the domain-level operation master roles, try transferring those roles to another domain controller. If no other domain controllers exist within the domain, try temporarily installing a copy of Windows 2000 Server onto a spare PC and making the spare server a domain controller. Then, attempt to transfer the roles to it.

To transfer a role, open Active Directory Users And Computers. Next, right-click on the domain name and select the Connect To Domain Controller command from the resulting context menu. Now, select the domain controller that you want to transfer the role to from the list of domain controllers and click OK. Finally, right-click on the domain name and select the Operations Master command from the context menu.

You’ll see the Operations Master properties sheet. As you go through each tab on the properties sheet, you’ll see the name of the server that presently holds the designated role and the name of the server that you selected to transfer the role to. To transfer the role, click the Change button. After you’ve transferred each role, click OK to close the properties sheet.

If the domain has serious-enough problems, you may not be able to transfer the roles. If this is the case, you’ll have to seize the roles. The stipulation for doing so is that in order to seize a role, you must take the server that presently holds the roles offline. Once it’s offline, you must never reattach the server to the network or you’ll risk destroying the entire Active Directory. Of course, you can always format the server and bring it back online with a new copy of Windows.

To seize a role, open the command prompt window and enter the following commands:
NTDSUTIL
ROLES
CONNECTIONS
CONNECT TO SERVER servername (where “servername” is the server that you’re going to move the role to)
QUIT

Now, enter one of the following commands to seize the role (the exact command depends on which role you want to seize):
SEIZE INFRASTRUCTURE MASTER
SEIZE RID MASTER
SEIZE PDC

Removing an orphaned domain
Normally, when you use the DCPROMO command to demote a domain controller, the DCPROMO utility will ask you if the domain controller that you’re demoting is the last domain controller in the domain. If it is, after the demotion is complete, the DCPROMO utility will automatically remove all of the metadata related to the domain from Active Directory.

To sum up, DCPROMO should erase the domain from Active Directory automatically after the last domain controller has been demoted. Unfortunately, things aren’t always this easy. It’s possible for Active Directory corruption or a catastrophic hardware failure to shut down domain controllers without you ever having the chance to demote them. If Active Directory thinks that domain controllers still exist within the domain, you won’t be able to delete the domain through the usual method. When Active Directory can no longer recognize or interact with a particular domain because of corruption within Active Directory, the domain is said to be “orphaned.”

To remove an orphaned domain, start NTDSUTIL by opening a command prompt, typingNTDSUTIL, and pressing [Enter]. When the NTDSUTIL prompt appears, type METADATA CLEANUP and press [Enter].

Next, connect to the server you’ll be cleaning up by typing CONNECTIONS and pressing [Enter]. Doing so will display the Server Connections prompt. Next, type CONNECT TO SERVER servername, where servername is the name of the server you’re connecting to. After you enter this command, you should see two messages. One of these messages states that NTDSUTIL is binding itself to the specified server using the supplied credentials. The next message confirms the connection.

If you don’t receive these messages, try reentering your credentials using the SET CREDS command and then try the CONNECT TO SERVER command once again. If the command still doesn’t work, check your ability to communicate with the target server.

After you connect to the target server, type QUIT and press [Enter]. This will return you to the METADATA CLEANUP prompt. Next, type SELECT OPERATION TARGET and press [Enter]. This will take you to the SELECT OPERATION TARGET prompt. Next, enter the LIST DOMAINS command. The NTDSUTIL command will inform you of how many domains it is aware of in the forest and will display each domain and a corresponding number.

Locate the domain that the failing domain controller belongs to and make note of the number that corresponds to it. Now, type SELECT DOMAIN number and press [Enter]. In this command, you should replace the word number with the number that corresponds to the domain with which you want to work.

Once you’ve selected the domain, you’ll see a confirmation message that tells you what domain you’re attached to and also informs you that you aren’t presently connected to any specific site or server. This is fine because you’re working with a domain-level issue rather than a site-level or a server-level problem. When you get this confirmation message, double- and triple-check to make sure that you’ve selected the correct domain. Otherwise, you could destroy the wrong domain.

When you’re sure that you’re working with the correct domain, enter the QUIT command to return to the METADATA CLEANUP prompt. Finally, type the command REMOVE SELECTED DOMAIN, take a deep breath, and press [Enter]. You should see a confirmation message stating that the domain was deleted.

If you receive an error message, it could be because the domain has been deleted already through the natural process or by another administrator. It’s also possible that you could get an error message if Active Directory still contains computer accounts or domain controller accounts. Simply having computer or domain controller accounts present won’t always make the process fail, but I have seen it happen. If you receive such an error, use the technique that I’ll present in the next section to fix the problem.

You must now complete the process by entering the QUIT command twice, followed by the EXIT command. Remember that you’ve only deleted the reference to the domain from a single domain controller. You must wait for the next replication cycle to complete before the domain will be wiped off of other domain controllers. Once the replication cycle is complete, you’ll be free to begin rebuilding the domain.

Removing orphaned domains that have computer or domain controller accounts present
If my previous technique fails, it could be because computer or domain controller accounts still exist within Active Directory. Normally, you’d use a domain controller within the domain to remove the computer accounts and then do a DCPROMO to demote all of the domain controllers. However, if all of your domain controllers are failing, this may not be an option.

If this is the case, take all of the domain controllers in the failing domain offline. Next, use a domain controller in a different domain to open Active Directory Users And Computers. Remove all of the computer accounts from the failing domain. Remember that since the domain controllers are gone, the computers will never be able to attach to the old domain again once they’re removed from Active Directory. You’ll have to reconstruct the domain and then manually reattach the computers to the new version of the domain.

Once you’ve removed all of the computer accounts, you can use the technique in the Daily Drill Down “Picking up the pieces after a failed domain controller demotion” to remove all of the domain controller accounts from the domain. Once you’ve completed this step, you should have no trouble removing the orphaned domain by using the technique that I discussed earlier.

Conclusion
You may be familiar with the saying, “We had to destroy the village in order to save it,” the point of which applies to failed domains as well as doomed villages. Recovering from a complete domain failure can be a study in futile rescue efforts. You may be able to save the failed domain, but, if you can’t, you may have to completely destroy and then rebuild the domain that’s damaged. By going ahead and destroying the malfunctioning domain, you’re cutting out the corruption in Active Directory. Once you’ve removed the corruption, Active Directory will be healthy once again. You’ll then be free to rebuild the domain.

Answers to Microsoft Active Directory Interview Questions.

Active Directory enables single sign on to access resources on the network such as desktops, shared files, printers etc. Active Directory provides advanced security for the entire network and network resources. Active Directory is more scalable and flexible for administration.
Functional levels help the coexistence of Active Directory versions such as, Windows NT, Windows 2000 Server, Windows Server 2003 and Windows Server 2008. The functional level of a domain or forest controls which advanced features are available in the domain or forest. Although lowest functional levels help to coexist with legacy Active Directory, it will disable some of the new features of Active Directory. But if you are setting up a new Active Directory environment with latest version of Windows Server and AD, you can set to the highest functional level, thus all the new AD functionality will be enabled.
Windows Server 2003 Domain Functional Levels: Windows 2000 mixed (Default), Windows 2000 native, Windows Server 2003 interim, and Windows Server 2003.
Forest Functional Levels: Windows 2000 (default), Windows Server 2003 interim, Windows Server.
Windows Server 2008 Domain Functional Levels: Windows 2000 Native, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2.
Forest Functional Levels: Windows 2000, Windows Server 2008, Windows Server 2008 R2.
It is possible to take a backup copy of existing Domain Controller, and restore it in Windows Server machine in the remote locations with slower WAN link.
Active Directory is designed for Server Operating System, and it cannot be installed on Windows 7.
Windows Server Operating System. Free hard disk space with NTFS partition. Administrator's privilege on the computer. Network connection with IP address, Subnet Mask, Gateway and DNS address. A DNS server, that can be installed along with first Domain Controller. Windows Server intallation CD or i386 folder.
Flexible Single-Master Operation (FSMO) roles,manage an aspect of the domain or forest, to prevent conflicts, which are handled by Single domain controllers in domain or forest. The tasks which are not suited to multi-master replication, There are 5 FSMO roles, and Schema Master and Domain naming master roles are handled by a single domain controller in a forest, and PDC, RID master and Infrastructure master roles are handled by a single domain controller in each domain.
Infrastrcture master role is a domain-specific role and its purpose is to ensure that cross-domain object references are correctly handled. For example, if you add a user from one domain to a security group from a different domain, the Infrastructure Master makes sure this is done properly.Intrastrcuture master does not have any functions to do in a single domain environment.If the Domain controller with Infrastructure master role goes down in a single domain environemt, there will be no impact at all. Where as, in a complex environment with multiple domains, it may imact creation and modification of groups and group authentication.
Schema Master role and Domain Naming Master role.
PDC Emulator
You should be a member of Enterprise Admins group or the Domain Admins group. Also you should be member of local Administrators group of the member server which you are going to promote as additional Domain Controller.
Use netdom query /domain:YourDomain FSMO command. It will list all the FSMO role handling domain controllers.
No, there should be only one Domain Controller handling RID master role in a Domain.
There should be only one Domain Controller handling Infrastructure master role in a domain. Hence if you have two domains in a forest, you can configure two Infrastructure masters, one in each domain.
If PDC emulator crashes, there will be immediate impact on the environment. User authentication will fail as password changes wont get effected, and there will be frequent account lock out issues. Network time synchronization will be impacted. It will also impact DFS consistency and Group policy replication as well.
Domain controllers and Sites. Domain controllers are physical computers which is running Windows Server operating system and Active Directory data base. Sites are a network segment based on geographical location and which contains multiple domain controllers in each site.
Domains, Organizational Units, trees and forests are logical components of Active Directory.
Active Directory database is divided into different partitions such as Schema partition, Domain partition, and Configuration partition. Apart from these partitions, we can create Application partition based on the requirement.
Adding one group as a member of another group is called 'group nesting'. This will help for easy administration and reduced replication traffic.
Group types are categorized based on its nature. There are two group types: Security Groups and Distribution Groups. Security groups are used to apply permissions to resources where as distribution groups are used to create Exchange server email communication groups. Group scopes are categorized based on the usage. There are three group types: Domain Local Group, Global Group and Universal Group.
Domain local groups are mainly used for granting access to network resources.A Domain local group can contain accounts from any domain, global groups from any domain and universal groups from any domain. For example, if you want to grant permission to a printer located at Domain A, to 10 users from Domain B, then create a Global group in Domain B and add all 10 users into that Global group. Then, create a Domain local group at Domain A, and add Global group of Domain B to Domain local group of Domain A, then, add Domain local group of Domain A to the printer(of Domain A) security ACL.
Active Directory is backed up along with System State data. System state data includes Local registry, COM+, Boot files, NTDS.DIT and SYSVOL folder. System state can be backed up either using Microsoft's default NTBACKUP tool or third party tools such as Symantech NetBackup, IBM Tivoli Storage Manager etc.
There are two types of Active Directory restores, Authoritative restore and Non-Authoritative restore.
Non-Authoritative means, a normal restore of a single Domain controller in case that particular domain controller OS or hardware crashed. After non-authoritative restoration completed, compares its data base with peer domain controllers in the network and accepts all the directory changes that have been made since the backup. This is done through multi master replication.
Where as, in Authoritative restore, a restored data base of a Domain controller forcefully replicated to all the other domain controllers. Authoritative restore is performed to recover an active directory resource or object(eg. an Organizational Unit) which accidentally deleted and it needs to be restored.
We can use NTDSUTIL command line to perform Authoritative restore of Active Directory. First, start a domain controller in 'Directory Service Restore Mode'. Then, restore the System State data of Domain controller using NTBACKUP tool. This is non-authoritative restore. Once non-authoritative restore is completed, we have to perform authoritative restore immediately before restarting the Domain Controller.
Open command prompt and type NTDSUTIL and enter, then type authoritative restore and press enter, then type restore database and press enter, click OK and then click Yes. This will restore all the data in authoritative restore mode. If you want to restore only a specific object or sub-tree, you can type below command instead of 'restore database'.
restore subtree ou=OU_Name,dc=Domain_Name,dc=xxx
Authoritative restore, Configurable settings, Partition management, Set DSRM Password etc.
A tombstone is a container object for deleted items from Active Directory database, even if objects are deleted, it will be kept hidden in the active directory data base for a specific period. This period is known as tombstone lifetime. Tombstone lifetime is 180 days on Windows Server 2003 SP1 and later versions of Windows Server.
Garbage collection is a process of Active Directory. This process starts by removing the remains of previously deleted objects from the database. These objects are known as tombstones. Then, the garbage collection process deletes unnecessary log files. And the process starts a defragmentation thread to claim additional free space. The garbage collection process is running on all the domain controllers in an interval of 12 hours.
In multimaster replication method, replication conflicts can happen. Objects with replication conflicts will be stored in a container called 'Lost and Found' container. This container also used to store orphaned user accounts and other objects.
Lost and Found container can be viewed by enabling advanced features from View menu of Active Directory User and Computers MMC.
Yes, it is included.
[Never say no] We had set up an additional domain for a new subsidiary of the firm, and I was a member of the team who handled installation and configuration of domain controllers for the sub domain.[or] I was supporting an existing Active Directory network environment of the company, but I have installed and configured Active Directory in test environment several occasions.
No one installs Active Directory in a cluster. There is no need of clustering a domain controller. Because Active Directory provides total redundancy with two or more servers.
Active Directory Recycle bin is a feature of Windows Server 2008 AD. It helps to restore accidentally deleted Active Directory objects without using a backed up AD database, rebooting domain controller or restarting any services.
Read only domain controller (RODC) is a feature of Windows Server 2008 Operating System. RODC is a read only copy of Active Directory database and it can be deployed in a remote branch office where physical security cannot be guaranteed. RODC provides more improved security and faster log on time for the branch office.
To find out forest and domain functional levels in GUI mode, open ADUC, right click on the domain name and take properties. Both domain and forest functional levels will be listed there. TO find out forest and domain functional levels, you can use DSQUERY command.
KCC can be expanded as Knowledge Consistency Checker. It is a protocol procecss running on all domain controllers, and it generates and maintains the replication topology for replication within sites and between sites.
We can use command line tools such as repadmin and dcdiag. GUI tool REPLMON can also be used for replication monitoring and troubleshooting.
SYSVOL is a folder exits on each domain controller, which contains Actvie Directory related files and folders. SYSVOL mainly stores important elements of Group Policy Objects and scripts, and it is being replicated among domain controllers using File Replication Service (FRS).
Kerberos is a network authentication protocol. Active Directory uses Kerberos for user and resource authentication and trust relationship functionality. Kerberos uses port number 88.
All versions of Windows Server Active Directory use Kerberos 5.
Kerberos 88, LDAP 389, DNS 53, SMB 445.
FQDN can be expanded as Fully Qualified Domain Name.It is a hierarchy of a domain name system which points to a device in the domain at its left most end. For example in system.
Dsadd - to add an object to the directory, Dsget - displays requested properties of an object in AD, Dsmove - Used to move one object from one location to another in the directory, DSquery - To query specific objects.
A tree in Active Directory is a collection of one or more domains which are interconnected and sharing global resources each other. If a tree has more than one domain, it will have contiguous namespace. When we add a new domain in an existing tree, it will be called a child domain.
A forest is a collection of one or more trees which trust each other and sharing a common schema.It also shares common configuration and global catalog. When a forest contains more than one tree, the trees will not form a contiguous namespace.
Replication between domain controllers inside a single site is called Intrasite replication, where as replication between domain controllers located in different sites is called Intersite replication. Intrasite replication will be very frequent, where as Intersite replication will be with specific interval and in a controlled fashion just to preserve network bandwidth.
Shortcut trust is a manually created transitive trust which is configured to enable fast and optimized authentication process.For example, If we create short cut trust between two domains of different trees, they can quickly authenticate each other without traveling through the entire parent domains. short cut trust can be either one-way or two-way.
Selective authentication is generally used in forest trust and external trusts. Selective authentication is a security setting which allows administrators to grant access to shared resources in their organization’s forest to a limited set of users in another organization’s forest. Selective authentication method can decide which groups of users in a trusted forest can access shared resources in the trusting forest.
Trusts can be categorized by its nature. There can be two-way trust or one-way trust,implicit or explicit trust, transitive or non transitive trust. Trust can be categorized by types, such as parent and child, tree root trust, external trust, realm trust forest trust and shortcut trust.
ADAC- Active Directory Administrative Center is a new GUI tool came with Windows Server 2008 R2, which provides enhanced data management experience to the admin. ADAC helps administrators to perform common Active Directory object management task across multiple domains with the same ADAC instance.
ADSIEDIT- Active Directory Service Interfaces Editor is a GUI tool which is used to perform advanced AD object and attribute management. This Active Directory tool helps us to view objects and attributes that are not visible through normal Active Directory Management Consoles. ADSIEDIT can be downloaded and installed along with Windows Server 2003 Support Tools.
This is due to domain functional level. If domain functional level of Windows Server 2003 AD is Windows 2000 Mixed, Universal Group option will be greyed out. You need to raise domain functional level to Windows 2000 native or above.
ADMT - Active Directory Migration Tool, is a tool which is used for migrating Active Directory objects from one domain to another. ADMT is an effective tool that simplifies the process of migrating users, computers, and groups to new domains.
When a domain controller is disconnected for a period that is longer than the tombstone life time, one or more objects that are deleted from Active Directory on all other domain controllers may remain on the disconnected domain controller. Such objects are called lingering objects. Lingering objects can be removed from Windows Server 2003 or 2008 using REPADMIN utility.
The Global catalog is a container which contains a searchable partial replica of all objects from all domains of the forest, and full replica of all objects from the domain where it is situated. The global catalog is stored on domain controllers that have been designated as global catalog servers and is distributed through multimaster replication. Global catalogs are mostly used in multidomain, multisite and complex forest environment, where as Global catalog does not function in a single domain forest.

In a forest that contains only a single Active Directory domain, there is no harm in placing both GC and Infrastructure master in same DC, because Infrastructure master does not have any work to do in a single domain environment. But in a forest with multiple and complex domain structure, the infrastructure master should be located on a DC which is not a Global Catalog server. Because the global catalog server holds a partial replica of every object in the forest, the infrastructure master, if placed on a global catalog server, will never update anything, because it does not contain any references to objects that it does not hold.
Command line method: nslookup gc._msdcs.<forest root DNS Domain Name>, nltest /dsgetdc:corp /GC. GUI method: Open DNS management, and under ‘Forward Lookup Zone’, click on GC container. To check if a server is GC or not, go to Active Directory Sites and Services MMC and under ‘Servers’ folder, take properties of NTDS settings of the desired DC and find Global Catalog option is checked.
As per Microsoft, a single AD domain controller can create around 2.15 billion objects during its lifetime.
When a user enters a user name and password, the computer sends the user name to the KDC. The KDC contains a master database of unique long term keys for every principal in its realm. The KDC looks up the user's master key (KA), which is based on the user's password. The KDC then creates two items: a session key (SA) to share with the user and a Ticket-Granting Ticket (TGT). The TGT includes a second copy of the SA, the user name, and an expiration time. The KDC encrypts this ticket by using its own master key (KKDC), which only the KDC knows. The client computer receives the information from the KDC and runs the user's password through a one-way hashing function, which converts the password into the user's KA. The client computer now has a session key and a TGT so that it can securely communicate with the KDC. The client is now authenticated to the domain and is ready to access other resources in the domain by using the Kerberos protocol.
Lightweight Directory Access Protocol (LDAP) is an Internet standard protocol which is used as a standard protocol for Active Directory functions. It runs directly over TCP, and can be used to access a standalone LDAP directory service or to access a directory service that is back-ended by X.500.
Active Directory related files are by default located at %SystemRoot%\ntds folder. NTDS.DIT is the main Active Directory database file. Apart from this other files such as EDB.LOG, EDB.CHK, RES1.LOG, TEMP.EDB etc. are also located at the same folder.
Global Catalog servers produce huge traffic related to the replication process.There for making all the domain controllers in the forest as Global Catalog servers will cause network bandwidth poroblem. GCs should be placed based on Network bandwidth and user or application requirement.

Thursday, 5 June 2014

Clean up server metadata

You perform the metadata cleanup process by using Ntdsutil.exe, a command-line tool that is automatically installed on all domain controllers. Metadata cleanup removes data from Active Directory that identifies a domain controller to the replication system. This procedure is required only for Active Directory domain controllers that were not successfully demoted using Dcpromo. This procedure does not have to be performed for domain member servers or client computers. On a domain controller that is running Windows Server 2003 with Service Pack 1 (SP1), metadata cleanup also removes File replication service (FRS) connections and attempts to transfer or seize any operations master roles (also known as flexible single master operations or FSMO roles) that the retired domain controller holds. These additional processes are performed automatically.

You can also use a script to clean up server metadata on most Windows operating systems. For information about using this script, see Remove Active Directory Domain Controller Metadata on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkID=123599).

Administrative credentials

To complete this procedure, you must be a member of the Enterprise Admins group.

To clean up server metadata

Open a command prompt.
Type the following command, and then press ENTER:

ntdsutil
At the ntdsutil: prompt, type:

metadata cleanup

Perform metadata cleanup as follows:

If you are performing metadata cleanup by using the version of Ntdsutil.exe that is included with Windows Server 2003 SP1, at the metadata cleanup:prompt, type:

remove selected server ServerName

Or

remove selected server ServerName1 on ServerName2

Value	Definition
ServerName, ServerName1	The distinguished name of the domain controller whose metadata you want to remove, in the form cn=ServerName,cn=Servers,cn=SiteName, cn=Sites,cn=Configuration,dc=ForestRootDomain
ServerName2	The DNS name of the domain controller to which you want to connect and from which you want to remove server metadata

If you are performing metadata cleanup by using the version of Ntdsutil.exe that is included with Windows Server 2003 with no service pack, perform metadata cleanup as follows:

At the metadata cleanup: prompt, type:

connection
At the server connections: prompt, type:

connect to server Server
At the server connections: prompt, type:

quit
At the metadata cleanup: prompt, type:

select operation target
At the select operation target: prompt, type:

list sites

A numbered list of sites appears.
At the select operation target: prompt, type:

select site SiteNumber
At the select operation target: prompt, type:

list domains in site

A numbered list of domains in the selected site appears.
At the select operation target: prompt, type:

select domain DomainNumber
At the select operation target: prompt, type:

list servers in site

A numbered list of servers in a domain and site appears.
At the select operation target: prompt, type:

select server ServerNumber
At the select operation target: prompt, type:

quit

At the metadata cleanup: prompt, type:

remove selected server

Value	Description
Server	The DNS name of a domain controller that you want to connect to
SiteNumber	The number associated with the site of the server that you want to clean up that appears in the list
DomainNumber	The number associated with the domain of the server that you want to clean up that appears in the list
ServerNumber	The number associated with the server that you want to clean up that appears in the list

At this point, Active Directory confirms that the domain controller was removed successfully. If you receive an error message that indicates that the object cannot be found, Active Directory might have already removed the domain controller.

To verify that the server was removed, type list servers in site, and then press ENTER. Ensure that the domain controller that you wanted to be removed is no longer displayed in the command output.
At the metadata cleanup: and ntdsutil: prompts, type quit.

Important
If the domain controller that was removed was also a DNS server, ensure that references to it are removed from the Name Servers tab in the DNS console. To do this, open the DNS console using another DNS server in the domain (dnsmgmt.msc), and then click the domain name under Forward Lookup Zones. Remove any references to the domain controller that was removed from the domain.

Flexibility Schema Operations Master (FSMO) Roles in 2008 Server

As we are all aware that certain tasks needs to be performed by single one, so as far AD 2008 goes some tasks are performed by single domain controller and they jointly called as FSMO roles.

There are five roles:

They are further classified in two

1. Forest Roles

Schema Master - As name suggests, the changes that are made while creation of any object in AD or changes in attributes will be made by single domain controller and then it will be replicated to another domain controllers that are present in your environment. There is no corruption of AD schema if all the domain controllers try to make changes. This is one of the very important roles in FSMO roles infrastructure.
Domain Naming Master - This role is not used very often, only when you add/remove any domain controllers. This role ensures that there is a unique name of domain controllers in environment.

2. Domain Roles

Infrastructure Master - This role checks domain for changes to any objects. If any changes are found then it will replicate to another domain controller.
RID Master - This role is responsible for making sure each security principle has a different identifier.
PDC emulator - This role is responsible for Account policies such as client password changes and time synchronization in the domain

Where these roles are configured?

Domain wide roles are configured in Active Directory users and computers. Right click and select domain and here option is operations master.
Forest roles Domain Naming master is configured in active directory domain and trust right click and select operations master. It will let you know the roles.
(c)Forest roles Schema Master is not accessible from any tool as they want to prevent this. Editing schema can create serious problem in active directory environment. To gain access you need to create snap-in and register dll file by regsvr32 schmmgmt.dll.