You can use three methods to restore deleted user accounts, computer accounts, and security groups. These objects are known collectively as security principals. In all three methods, you authoritatively restore the deleted objects, and then you restore group membership information for the deleted security principals. When you restore a deleted object, you must restore the former values of the member and memberOf attributes in the affected security principal. The three methods
are:
Method 1: Restore the deleted user accounts, and then add the restored users back to their groups by using the Ntdsutil.exe command-line tool (Microsoft Windows Server 2003 with Service Pack 1 [SP1] only)
Method 2: Restore the deleted user accounts, and then add the restored users back to their groups
Method 3: Authoritatively restore the deleted user accounts and the deleted users' security groups two times
Note: This KB article does not cover details of the AD Recycle Bin feature included in Windows Server 2008 R2; please examine the the References section for more details on this feature.
Methods 1 and 2 provide a better experience for domain users and administrators because they preserve the additions to security groups that were made between the time of the last system state backup and the time the deletion occurred. In method 3, instead of making individual adjustments to security principals, you roll back security group memberships to their state at the time of the last backup.
If you do not have a valid backup of the system state, and the domain where the deletion occurred contains Windows Server 2003-based domain controllers, you can manually or programmatically recover the deleted objects. You can also use the Repadmin utility to determine when and where a user was deleted.
Most large-scale deletions are accidental. Microsoft recommends that you take several steps to prevent others from deleting objects in bulk.
Note To prevent the accidental deletion or movement of objects (especially organizational units), two Deny access control entries (ACEs) can be added to the security descriptor of each object (DENY "DELETE" & "DELETE TREE") and one Deny access control entries (ACEs) can be added to the security descriptor of the PARENT of each object (DENY "DELETE CHILD"). To do this in Windows 2000 Server and in Windows Server 2003, use Active Directory Users and Computers, ADSIEdit, LDP, or the DSACLS command-line tool. You can also change the default permissions in the AD schema for organizational units so that these ACEs are included by default.
For example, to protect the organization unit that is called Users in the AD domain that is called CONTOSO.COM from accidentally being moved or deleted out of its parent organizational unit that is called MyCompany, make the following configuration:
For the MyCompany organizational unit, add DENY ACE for Everyone to DELETE CHILD with the This object only scope: DSACLS "OU=MyCompany,DC=CONTOSO,DC=COM" /D "EVERYONE:DC"
For the Users organizational unit, add DENY ACE for Everyone to DELETE and DELETE TREE with the This object only scope: DSACLS "OU=Users,OU=MyCompany,DC=CONTOSO,DC=COM" /D "EVERYONE:SDDT"
The Active Directory Users and Computers snap-in in Windows Server 2008 includes a Protect object from accidental deletion check box on the Object tab.
Note The Advanced Features check box must be enabled to view that tab.
When you create an organizational unit by using Active Directory Users and Computers in Windows Server 2008, the Protect container from accidental deletion check box appears. By default, the check box is selected and can be deselected.
Although you can configure every object in Active Directory by using these ACEs, this is best suited for organizational units. Deletion or movements of all leaf objects can have a major effect. This configuration prevents such deletions or movements. To really delete or move an object by using such a configuration, the Deny ACEs must be removed first.
This step-by-step article discusses how to restore user
accounts, computer accounts, and their group memberships after they have been
deleted from Active Directory. In variations of this scenario, user accounts,
computer accounts, or security groups may have been deleted individually or in
some combination. In all these cases, the same initial steps apply--you
authoritatively restore, or auth restore, those objects that were inadvertently deleted. Some deleted
objects require more work to be restored. These objects include objects such as
user accounts that contain attributes that are back links of the attributes of
other objects. Two of these attributes are managedBy and memberOf.
When you add security principals such as a user
account, a security group, or a computer account to a security group, you make
the following changes in Active Directory:
The name of the security principal is added to the member attribute of each security group.
For each security group that the user, the computer, or the
security group is a member of, a back link is added to the security principal's
memberOf attribute.
Similarly, when a user, a computer, or a group is deleted from
Active Directory, the following actions occur:
The deleted security principal is moved into the deleted
objects container.
A number of attribute values, including the memberOf attribute, are stripped from the deleted security
principal.
Deleted security principals are removed from any security
groups that they were a member of. In other words, the deleted security
principals are removed from each security group's member attribute.
When you recover deleted security principals and restore their
group memberships, the key point to remember is that each security principal
must exist in Active Directory before you restore its group membership. (The
member may be a user, a computer, or another security group.) To restate this
rule more broadly, an object that contains attributes whose values are back
links must exist in Active Directory before the object that contains that
forward link can be restored or modified.
Although this article
focuses on how to recover deleted user accounts and their memberships in
security groups, its concepts apply equally to other object deletions. This
article's concepts apply equally to deleted objects whose attribute values use
forward links and back links to other objects in Active Directory.
You
can use either of the three methods to recover security principals. When you
use method 1, you leave in place all security principals that were added to any
security group across the forest, and you add only security principals that
were deleted from their respective domains back to their security groups. For
example, you make a system state backup, add a user to a security group, and
then restore the system state backup. When you use methods 1 or 2, you preserve
any users who were added to security groups that contain deleted users between
the dates that the system state backup was created and the date that the backup
was restored. When you use method 3, you roll back security group memberships
for all the security groups that contain deleted users to their state at the
time that the system state backup was made.
Method 1: Restore the deleted user accounts, and then add the restored users back to their groups by using the Ntdsutil.exe command-line tool (Microsoft Windows Server 2003 with Service Pack 1 [SP1] only)
Note This method is valid only on domain controllers that are running
Windows Server 2003 with SP1. If Windows Server 2003 SP1 has not been installed
on the domain controllers that you use for recovery, use Method 2.
In
Windows Server 2003 SP1, functionality was added to the Ntdsutil.exe
command-line tool to help administrators more easily restore the backlinks of
deleted objects. Two files are generated for each authoritative restore
operation. One file contains a list of authoritatively restored objects. The
other file is an .ldf file that is used with the Ldifde.exe utility. This file
is used to restore the backlinks for the objects that are authoritatively
restored. In Windows Server 2003 SP1, an authoritative restoration of a user
object also generates LDIF files with the group membership. This method avoids a
double restoration.
When you use this method, you perform the following
high-level steps:
Check to see if a global catalog in the user's domain has
not replicated in the deletion, and then prevent that global catalog from
replicating. If there is no latent global catalog, locate the most current
system state backup of a global catalog domain controller in the deleted user's
home domain.
Auth restore all the deleted user accounts, and then permit
end-to-end replication of those user accounts.
Add all the restored users back to all the groups in all
the domains that the user accounts were a member of before they were
deleted.
To use method 1, follow this procedure:
Check to see whether there is a global catalog domain
controller in the deleted user's home domain that has not replicated any part
of the deletion.
Note Focus on the global catalogs that have the least frequent
replication schedules.
If one or more of these global catalogs exist,
use the Repadmin.exe command-line tool to immediately disable inbound
replication. To do this, follow these steps:
Click Start, and then click
Run.
Type cmd in the
Open box, and then click OK.
Type the following command at the command prompt, and
then press ENTER:
repadmin /options <recovery dc name> +DISABLE_INBOUND_REPL
Note If you cannot issue the Repadmin command immediately, remove all
network connectivity from the latent global catalog until you can use Repadmin
to disable inbound replication, and then immediately return network
connectivity.
This domain controller will be referred to as the recovery
domain controller. If there is no such global catalog, go to step 2.
It is best to stop making changes to security groups in the
forest if all the following statements are true:
You are using method 1 to auth restore deleted users or
computer accounts by their distinguished name (dn) path.
The deletion has replicated to all the domain
controllers in the forest except the latent recovery domain
controller.
You are not auth restoring security groups or their
parent containers.
If you are auth restoring security groups or organizational
unit (OU) containers that host security groups or user accounts, temporarily
stop all these changes.
Notify administrators and help desk
administrators in the appropriate domains in addition to domain users in the
domain where the deletion occurred about stopping these changes.
Create a new system state backup in the domain where the
deletion occurred. You can use this backup if you have to roll back your
changes.
Note If system state backups are current up to the point of the
deletion, skip this step and go to step 4.
If you identified a
recovery domain controller in step 1, back up its system state now.
If
all the global catalogs located in the domain where the deletion occurred
replicated in the deletion, back up the system state of a global catalog in the
domain where the deletion occurred.
When you create a backup, you can
return the recovery domain controller back to its current state and perform
your recovery plan again if your first try is not successful.
If you cannot find a latent global catalog domain
controller in the domain where the user deletion occurred, find the most recent
system state backup of a global catalog domain controller in that domain. This
system state backup should contain the deleted objects. Use this domain
controller as the recovery domain controller.
Only restorations of the
global catalog domain controllers in the user's domain contain global and
universal group membership information for security groups that reside in
external domains. If there is no system state backup of a global catalog domain
controller in the domain where users were deleted, you cannot use the memberOf attribute on restored user accounts to determine global or
universal group membership or to recover membership in external domains.
Additionally, it is a good idea to find the most recent system state backup of
a non-global catalog domain controller.
If you know the password for the offline administrator
account, start the recovery domain controller in Dsrepair mode. If you do not
know the password for the offline administrator account, reset the password
while the recovery domain controller is still in normal Active Directory
mode.
You can use the setpwd command-line tool to reset the password on domain controllers
that are running Microsoft Windows 2000 Service Pack 2 (SP2) and later while
they are in online Active Directory mode.
Note Microsoft no longer supports Windows 2000.
For more information
about changing the Recovery Console administrator password, click the following
article number to view the article in the Microsoft Knowledge Base:
How to change the Recovery Console administrator password on a domain controller
Administrators of Windows Server 2003 domain
controllers can use the set dsrm password command in the Ntdsutil command-line tool to reset the password for the offline
administrator account.
For more information about how to reset the
Directory Services Restore Mode administrator account, click the following
article number to view the article in the Microsoft Knowledge Base:
How to reset the Directory Services Restore Mode administrator account password in Windows Server 2003
Press F8 during the startup process to start the recovery
domain controller in Dsrepair mode. Log on to the console of the recovery
domain controller with the offline administrator account. If you reset the
password in step 5, use the new password.
If the recovery domain
controller is a latent global catalog domain controller, do not restore the
system state. Go to step 7.
If you are creating the recovery domain
controller by using a system state backup, restore the most current system
state backup that was made on the recovery domain controller now.
Auth restore the deleted user accounts, the deleted
computer accounts, or the deleted security groups.
Note The terms auth restore and authoritative restore refer to the process of using the authoritative restore command in the Ntdsutil command-line tool to increment the version numbers of specific
objects or of specific containers and all their subordinate objects. As soon as
end-to-end replication occurs, the targeted objects in the recovery domain
controller's local copy of Active Directory become authoritative on all the
domain controllers that share that partition. An authoritative restoration is
different from a system state restoration. A system state restoration populates
the restored domain controller's local copy of Active Directory with the
versions of the objects at the time that the system state backup was
made.
For more information
about auth restoring a domain controller, click the following article number to
view the article in the Microsoft Knowledge Base:
How to perform an authoritative restore to a domain controller in Windows 2000
Authoritative restorations are performed
with the Ntdsutil command-line tool and refer to the domain name (dn) path of the
deleted users or of the containers that host the deleted users.
When
you auth restore, use domain name (dn) paths that are as low in the domain tree
as they have to be to avoid reverting objects that are not related to the
deletion. These objects may include objects that were modified after the system
state backup was made.
Auth restore deleted users in the following
order:
Auth restore the domain name (dn) path for each deleted
user account, computer account, or security group.
Authoritative
restorations of specific objects take longer but are less destructive than
authoritative restorations of a whole subtree. Auth restore the lowest common
parent container that holds the deleted objects.
For each user that you
restore, at least two files are generated. These files have the following
format:
ar_YYYYMMDD-HHMMSS_objects.txt This file contains a list of the authoritatively restored
objects. Use this file with the ntdsutil authoritatative restore "create ldif file from" command in any other domain in the forest where the user was a
member of Domain Local groups.
ar_YYYYMMDD-HHMMSS_links_usn.loc.ldf If you perform the auth restore on a global catalog, one of
these files is generated for every domain in the forest. This file contains a
script that you can use with the Ldifde.exe utility. The script restores the
backlinks for the restored objects. In the user's home domain, the script
restores all the group memberships for the restored users. In all other domains
in the forest where the user has group membership, the script restores only
universal and global group memberships. The script does not restore any Domain
Local group memberships. These memberships are not tracked by a global
catalog.
Auth restore only the OU or Common-Name (CN) containers
that host the deleted user accounts or groups.
Authoritative
restorations of a whole subtree are valid when the OU that is targeted by the ntdsutil "authoritative restore" command contains the overwhelming majority of the objects that
you are trying to auth restore. Ideally, the targeted OU contains all the
objects that you are trying to auth restore.
An authoritative
restoration on an OU subtree restores all the attributes and objects that
reside in the container. Any changes that were made up to the time that a
system state backup is restored are rolled back to their values at the time of
the backup. With user accounts, computer accounts, and security groups, this
rollback may mean the loss of the most recent changes to passwords, to the home
directory, to the profile path, to location and to contact info, to group
membership, and to any security descriptors that are defined on those objects
and attributes.
Note Repeat this step for each peer OU that hosts deleted users or
groups.
Important When you restore a subordinate object of an OU, all the deleted
parent containers of the deleted subordinate objects must be explicitly auth
restored.
For each organizational unit that you restore, at least two
files are generated. These files have the following format:
ar_YYYYMMDD-HHMMSS_objects.txt
This file contains a list of the authoritatively
restored objects. Use this file with the ntdsutil authoritatative restore "create ldif file from" command in any other domain in the forest where the restored
users were members of Domain Local groups.
For more information, visit
the following Microsoft Web site:
ar_YYYYMMDD-HHMMSS_links_usn.loc.ldf This file contains a script that you can use with the
Ldifde.exe utility. The script restores the backlinks for the restored objects.
In the user's home domain, the script restores all the group memberships for
the restored users.
If deleted objects were recovered on the recovery domain
controller because of a system state restore, remove all the network cables
that provide network connectivity to all the other domain controllers in the
forest.
Restart the recovery domain controller in normal Active
Directory mode.
Type the following command to disable inbound replication
to the recovery domain controller:
repadmin /options <recovery dc name> +DISABLE_INBOUND_REPL
Enable network connectivity back to the recovery domain controller
whose system state was restored.
Outbound-replicate the auth-restored objects from the
recovery domain controller to the domain controllers in the domain and in the
forest.
While inbound replication to the recovery domain controller
remains disabled, type the following command to push the auth-restored objects
to all the cross-site replica domain controllers in the domain and to all the
global catalogs in the forest:
If all the following statements are true, group membership links
are rebuilt with the restoration and the replication of the deleted user
accounts. Go to step 14.
Note If one or more of the following statements is not true, go to
step 12.
Your forest is running at the Windows Server 2003
forest functional level or at the Windows Server 2003 Interim forest functional
level.
Only user accounts or computer accounts were deleted,
and not security groups.
The deleted users were added to security groups in all
the domains in the forest after the forest was transitioned to Windows Server
2003 forest functional level.
On the console of the recovery domain controller, use the
Ldifde.exe utility and the
ar_YYYYMMDD-HHMMSS_links_usn.loc.ldf file to
restore the user's group memberships. To do this, follow these steps:
Click Start, click
Run, type cmd in the
Open box, and then click OK.
At the command prompt, type the following command, and
then press ENTER:
ldifde -i -f ar_YYYYMMDD-HHMMSS_links_usn.loc.ldf
The LDIFDE import may fail and you may receive the following error message:
Add error on line <xxx>: Invalid Syntax
The server side error is "The parameter is incorrect."
If the problematic line number in the LINKS.LDF file refers to one of three credential roaming attributes, msPKIDPAPIMasterKeys, msPKIAccountCredentials or msPKIRoamingTimeStamp, see the following Microsoft Knowledge Base (KB) article:
Error "The parameter is incorrect" Attempting to Import LDF File for Authoritative Restore
Note This article describes the changes that are required to successfully import the LINKS LDF file.
Enable inbound replication to the recovery domain
controller by using the following command:
repadmin /options <recovery dc name> -DISABLE_INBOUND_REPL
If deleted users were added to local groups in external
domains, do one of the following:
Manually add the deleted users back to those
groups.
Restore the system state and auth restore each of the
local security groups that contains the deleted users.
Verify group membership in the recovery domain controller's
domain and in global catalogs in other domains.
Make a new system state backup of domain controllers in the
recovery domain controller's domain.
Notify all the forest administrators, delegated
administrators, help desk administrators in the forest, and users in the domain
that the user restore is complete.
Help desk administrators may have
to reset the passwords of auth-restored user accounts and computer accounts
whose domain password changed after the restored system was
made.
Users who changed their passwords after the system state backup
was made will find that their most recent password no longer works. Have such
users try to log on by using their previous passwords if they know them.
Otherwise, help desk administrators must reset the password and select the
user must change password at next logon check box, preferably
on a domain controller in the same Active Directory site as the user is located
in.
Method 2: Restore the deleted user accounts, and then add the restored users back to their groups
When you use this method, you perform the following high-level
steps:
Check to see if a global catalog in the user's domain has
not replicated in the deletion, and then prevent that global catalog from
replicating. If there is no latent global catalog, locate the most current
system state backup of a global catalog domain controller in the deleted user's
home domain.
Auth restore all the deleted user accounts, and then permit
end-to-end replication of those user accounts.
Add all the restored users back to all the groups in all
the domains that the user accounts were a member of before they were
deleted.
To use method 2, follow this procedure:
Check to see whether there is a global catalog domain
controller in the deleted user's home domain that has not replicated any part
of the deletion.
Note Focus on the global catalogs that have the least frequent
replication schedules.
If one or more of these global catalogs exist,
use the Repadmin.exe command-line tool to immediately disable inbound
replication. To do this, follow these steps:
Click Start, and then click
Run.
Type cmd in the
Open box, and then click OK.
Type the following command at the command prompt, and
then press ENTER:
repadmin /options <recovery dc name> +DISABLE_INBOUND_REPL
Note If you cannot issue the Repadmin command immediately, remove all
network connectivity from the latent global catalog until you can use Repadmin
to disable inbound replication, and then immediately return network
connectivity.
This domain controller will be referred to as the recovery
domain controller. If there is no such global catalog, go to step 2.
Decide whether additions, deletions, and changes to user
accounts, computer accounts, and security groups must be temporarily stopped
until all the recovery steps have been completed.
To maintain the most
flexible recovery path, temporarily stop making changes to the following items.
Changes include password resets by domain users, help desk administrators, and
administrators in the domain where the deletion occurred, in addition to group
membership changes in the deleted users' groups. Consider halting additions,
deletions, and modifications to the following items:
User accounts and attributes on user
accounts
Computer accounts and attributes on computer
accounts
Service accounts
Security groups
It is best to stop making changes to security groups in the
forest if all the following statements are true:
You are using method 2 to auth restore deleted users or
computer accounts by their domain name (dn) path.
The deletion has replicated to all the domain
controllers in the forest except the latent recovery domain
controller.
You are not auth restoring security groups or their
parent containers.
If you are auth restoring security groups or organizational
unit (OU) containers that host security groups or user accounts, temporarily
stop all these changes.
Notify administrators and help desk
administrators in the appropriate domains in addition to domain users in the
domain where the deletion occurred about stopping these changes.
Create a new system state backup in the domain where the
deletion occurred. You can use this backup if you have to roll back your
changes.
Note If system state backups are current up to the point of the
deletion, skip this step and go to step 4.
If you identified a
recovery domain controller in step 1, back up its system state now.
If
all the global catalogs located in the domain where the deletion occurred
replicated in the deletion, back up the system state of a global catalog in the
domain where the deletion occurred.
When you create a backup, you can
return the recovery domain controller back to its current state and perform
your recovery plan again if your first try is not successful.
If you cannot find a latent global catalog domain
controller in the domain where the user deletion occurred, find the most recent
system state backup of a global catalog domain controller in that domain. This
system state backup should contain the deleted objects. Use this domain
controller as the recovery domain controller.
Only restorations of the
global catalog domain controllers in the user's domain contain global and
universal group membership information for security groups that reside in
external domains. If there is no system state backup of a global catalog domain
controller in the domain where users were deleted, you cannot use the memberOf attribute on restored user accounts to determine global or
universal group membership or to recover membership in external domains.
Additionally, it is a good idea to find the most recent system state backup of
a non-global catalog domain controller.
If you know the password for the offline administrator
account, start the recovery domain controller in Dsrepair mode. If you do not
know the password for the offline administrator account, reset the password
while the recovery domain controller is still in normal Active Directory
mode.
You can use the setpwd command-line tool to reset the password on domain controllers
that are running Microsoft Windows 2000 Service Pack 2 (SP2) and later while
they are in online Active Directory mode.
Note Microsoft no longer supports Windows 2000.
For more information
about changing the Recovery Console administrator password, click the following
article number to view the article in the Microsoft Knowledge Base:
How to change the Recovery Console administrator password on a domain controller
Administrators of Windows Server 2003 domain
controllers can use the set dsrm password command in the Ntdsutil command-line tool to reset the password for the offline
administrator account.
For more information about how to reset the
Directory Services Restore Mode administrator account, click the following
article number to view the article in the Microsoft Knowledge Base:
How to reset the Directory Services Restore Mode administrator account password in Windows Server 2003
Press F8 during the startup process to start the recovery
domain controller in Dsrepair mode. Log on to the console of the recovery
domain controller with the offline administrator account. If you reset the
password in step 5, use the new password.
If the recovery domain
controller is a latent global catalog domain controller, do not restore the
system state. Go to step 7.
If you are creating the recovery domain
controller by using a system state backup, restore the most current system
state backup that was made on the recovery domain controller now.
Auth restore the deleted user accounts, the deleted
computer accounts, or the deleted security groups.
Note The terms auth restore and authoritative restore refer to the process of using the authoritative restore command in the Ntdsutil command-line tool to increment the version numbers of specific
objects or of specific containers and all their subordinate objects. As soon as
end-to-end replication occurs, the targeted objects in the recovery domain
controller's local copy of Active Directory become authoritative on all the
domain controllers that share that partition. An authoritative restoration is
different from a system state restoration. A system state restoration populates
the restored domain controller's local copy of Active Directory with the
versions of the objects at the time that the system state backup was
made.
For more information
about auth restoring a domain controller, click the following article number to
view the article in the Microsoft Knowledge Base:
How to perform an authoritative restore to a domain controller in Windows 2000
Authoritative restorations are performed
with the Ntdsutil command-line tool and refer to the domain name (dn) path of the
deleted users or of the containers that host the deleted users.
When
you auth restore, use domain name (dn) paths that are as low in the domain tree
as they have to be to avoid reverting objects that are not related to the
deletion. These objects may include objects that were modified after the system
state backup was made.
Auth restore deleted users in the following
order:
Auth restore the domain name (dn) path for each deleted
user account, computer account, or security group.
Authoritative
restorations of specific objects take longer but are less destructive than
authoritative restorations of a whole subtree. Auth restore the lowest common
parent container that holds the deleted objects.
Note The Ntdsutil authoritative restore operation is not successful if
the distinguished name path (DN) contains extended characters or spaces. In
order for the scripted restore to succeed, the “restore object
<DN path>” command must be passed as one
complete string. To work around this problem, wrap the DN that contain
extended characters and spaces with backslash-double-quotation-mark escape
sequences. Here is an example: ntdsutil "authoritative restore" "restore
object \"CN=John Doe,OU=Mayberry NC,DC=contoso,DC=com\"" q q
Note The command must be modified further if the DN of objects being
restored contain commas. See the following example: ntdsutil
"authoritative restore" "restore object \"CN=Doe\, John,OU=Mayberry
NC,DC=contoso,DC=com\"" q q
Note If the objects were restored from tape, marked authoritative and
the restore did not work as expected and then the same tape is used to restore
the NTDS database once again, the USN version of objects to be restored
authoritatively must be increased higher than the default of 100000 or the
objects will not replicate out after the second restore. The syntax below is
needed to script an increased version number higher than 100000 (default):
ntdsutil "authoritative restore" "restore object \"CN=Doe\, John,OU=Mayberry
NC,DC=contoso,DC=com\" verinc 150000\"" q q
Note If the script prompts for confirmation on each object being
restored you can turn off the prompts. The syntax to turn off prompting is:
ntdsutil "popups off" "authoritative restore" "restore object \"CN=John
Doe,OU=Mayberry NC,DC=contoso,DC=com\" verinc 150000\"" q q
Auth restore only the OU or Common-Name (CN) containers
that host the deleted user accounts or groups.
Authoritative
restorations of a whole subtree are valid when the OU that is targeted by the ntdsutil "authoritative restore" command contains the overwhelming majority of the objects that
you are trying to auth restore. Ideally, the targeted OU contains all the
objects that you are trying to auth restore.
An authoritative
restoration on an OU subtree restores all the attributes and objects that
reside in the container. Any changes that were made up to the time that a
system state backup is restored are rolled back to their values at the time of
the backup. With user accounts, computer accounts, and security groups, this
rollback may mean the loss of the most recent changes to passwords, to the home
directory, to the profile path, to location and to contact info, to group
membership, and to any security descriptors that are defined on those objects
and attributes.
Note Repeat this step for each peer OU that hosts deleted users or
groups.
Important When you restore a subordinate object of an OU, all the deleted
parent containers of the deleted subordinate objects must be explicitly auth
restored.
If deleted objects were recovered on the recovery domain
controller because of a system state restore, remove all the network cables
that provide network connectivity to all the other domain controllers in the
forest.
Restart the recovery domain controller in normal Active
Directory mode.
Type the following command to disable inbound replication
to the recovery domain controller:
repadmin /options <recovery dc name> +DISABLE_INBOUND_REPL
Enable network connectivity back to the recovery domain controller
whose system state was restored.
Outbound-replicate the auth-restored objects from the
recovery domain controller to the domain controllers in the domain and in the
forest.
While inbound replication to the recovery domain controller
remains disabled, type the following command to push the auth-restored objects
to all the cross-site replica domain controllers in the domain and to all the
global catalogs in the forest:
If all the following statements are true, group membership links
are rebuilt with the restoration and the replication of the deleted user
accounts. Go to step 14.
Note If one or more of the following statements is not true, go to
step 12.
Your forest is running at the Windows Server 2003
forest functional level or at the Windows Server 2003 Interim forest functional
level.
Only user accounts or computer accounts were deleted,
and not security groups.
The deleted users were added to security groups in all
the domains in the forest after the forest was transitioned to Windows Server
2003 forest functional level.
Determine which security groups the deleted users were
members of, and then add them to those groups.
Note Before you can add users to groups, the users who you auth
restored in step 7 and who you outbound-replicated in step 11 must have
replicated to the domain controllers in the referenced domain controller's
domain and to all the global catalog domain controllers in the
forest.
If you have deployed a group-provisioning utility to
re-populate membership for security groups, use that utility now to restore
deleted users to the security groups that they were members of before they were
deleted. Do this after all the direct and transitive domain controllers in the
forest's domain and global catalog servers have inbound-replicated the
auth-restored users and any restored containers.
If you do not have
such a utility, the Ldifde.exe command-line tool and the Groupadd.exe
command-line tool can automate this task for you when they are run on the
recovery domain controller. These tools are available from Microsoft Product
Support Services. In this scenario, Ldifde.exe creates an LDAP Data Interchange
Format (LDIF) information file that contains the names of the user accounts and
their security groups, starting at an OU container that the administrator
specifies. Groupadd.exe then reads the memberOf attribute for each user account that is listed in the .ldf file,
and then generates separate and unique LDIF information for each domain in the
forest. This LDIF information contains the names of the security groups that
the deleted users have to be added back to so that their group memberships can
be restored. Follow these steps for this phase of the recovery.
Log on to the recovery domain controller's console by
using a user account that is a member of the domain administrator's security
group.
Use the Ldifde command to dump the names of the formerly deleted user accounts
and their memberOf attributes, starting at the topmost OU container where the
deletion occurred. The Ldifde command uses the following syntax:
ldifde -d <dn path of container that hosts deleted users> -r "(objectClass=user)" -l memberof -p subtree -f user_membership_after_restore.ldf
Use the following syntax if deleted computer accounts were added
to security groups:
ldifde -d <dn path of container that hosts deleted users> -r "(objectClass=computer)" -l memberof -p subtree -f computer_membership_after_restore.ldf
Run the Groupadd command to build more .ldf files that contain the names of
domains and the names of global and universal security groups that the deleted
users were a member of. The Groupadd command uses the following syntax:
Repeat this command if deleted computer accounts were added to
security groups.
Import each
Groupadd_fully.qualified.domainname.ldf file that
you created in step 12c to a single global catalog domain controller that
corresponds with each domain's .ldf file. Use the following Ldifde syntax:
Run the .ldf file for the domain that the users were deleted from
on any domain controller except the recovery domain controller.
On the console of each domain controller that is used
to import the
Groupadd_<fully.qualified.domain.name>.ldf
file for a particular domain, outbound-replicate the group membership additions
to the other domain controllers in the domain and to the global catalog domain
controllers in the forest by using the following command:
To disable outbound replication, type the following text,
and then press ENTER:
repadmin /options +DISABLE_OUTBOUND_REPL
Note To re-enable outbound replication, type the following text, and
then press ENTER:
repadmin /options -DISABLE_OUTBOUND_REPL
If deleted users were added to local groups in external
domains, do one of the following:
Manually add the deleted users back to those
groups.
Restore the system state and auth restore each of the
local security groups that contains the deleted users.
Verify group membership in the recovery domain controller's
domain and in global catalogs in other domains.
Make a new system state backup of domain controllers in the
recovery domain controller's domain.
Notify all the forest administrators, delegated
administrators, help desk administrators in the forest, and users in the domain
that the user restore is complete.
Help desk administrators may have
to reset the passwords of auth-restored user accounts and computer accounts
whose domain password changed after the restored system was
made.
Users who changed their passwords after the system state backup
was made will find that their most recent password no longer works. Have such
users try to log on by using their previous passwords if they know them.
Otherwise, help desk administrators must reset the password and select the
user must change password at next logon check box, preferably
on a domain controller in the same Active Directory site as the user is located
in.
Method 3: Authoritatively restore the deleted users and the deleted users' security groups two times
When you use this method, you perform the following high-level
steps:
Check to see if a global catalog in the user's domain has
not replicated in the deletion, and then prevent that domain controller from
inbound-replicating the deletion. If there is no latent global catalog, locate
the most current system state backup of a global catalog domain controller in
the deleted user's home domain.
Authoritatively restore all deleted user accounts and all
security groups in the deleted user's domain.
Wait for the end-to-end replication of the restored users
and of the security groups to all the domain controllers in the deleted user's
domain and to the forest's global catalog domain controllers.
Repeat steps 2 and 3 to authoritatively restore deleted
users and security groups. (You restore the system state only one time.)
If the deleted users were members of security groups in
other domains, authoritatively restore all the security groups that the deleted
users were members of in those domains. Or, if system state backups are
current, authoritatively restore all the security groups in those
domains.
To satisfy the requirement that deleted group members must be
restored before security groups to fix up group membership links, you restore
both object types two times in this method. The first restoration puts all the
user accounts and group accounts in place, and the second restoration restores
deleted groups and repairs the group membership information, including
membership information for nested groups.
To use method 3, follow this
procedure:
Check to see whether a global catalog domain controller
exists in the deleted users home domain and has not replicated in any part of
the deletion.
Note Focus on global catalogs in the domain that has the least
frequent replication schedules. If these domain controllers exist, use the
Repadmin.exe command-line tool to immediately disable inbound replication. To
do this, follow these steps:
Click Start, and then click
Run.
Type command in the
Open box, and then click OK.
Type repadmin /options
<recovery dc name>
+DISABLE_INBOUND_REPL at the command prompt, and then press
ENTER.
Note If you cannot issue the Repadmin command immediately, remove all
network connectivity from the domain controller until you can use Repadmin to
disable inbound replication, and then immediately return network connectivity.
This domain controller will be referred to as the recovery
domain controller.
Avoid making additions, deletions, and changes to the
following items until all the recovery steps have been completed. Changes
include password resets by domain users, help desk administrators, and
administrators in the domain where the deletion occurred, in addition to group
membership changes in the deleted users' groups.
User accounts and attributes on user
accounts
Computer accounts and attributes on computer
accounts
Service accounts
Security groups
Note Especially avoid changes to group membership for users, computers,
groups, and service accounts in the forest where the deletion
occurred.
Notify all the forest administrators, the delegated
administrators, and the help desk administrators in the forest of the temporary
stand-down.
This stand-down is required in method 2 because you are
authoritatively restoring all the deleted users' security groups. Therefore,
any changes that are made to groups after the date of system state backup are
lost.
Create a new system state backup in the domain where the
deletion occurred. You can use this backup if you have to roll back your
changes.
Note If your system state backups are current up to the time that the
deletion occurred, skip this step and go to step 4.
If you identified
a recovery domain controller in step 1, back up its system state
now.
If all the global catalogs that are located in the domain where
the deletion occurred replicated the deletion, back up the system state of a
global catalog in the domain where the deletion occurred.
When you
create a backup, you can return the recovery domain controller back to its
current state and perform your recovery plan again if your first try is not
successful.
If you cannot find a latent global catalog domain
controller in the domain where the user deletion occurred, find the most recent
system state backup of a global catalog domain controller in that domain. This
system state backup should contain the deleted objects. Use this domain
controller as the recovery domain controller.
Only databases of the
global catalog domain controllers in the user's domain contain group membership
information for external domains in the forest. If there is no system state
backup of a global catalog domain controller in the domain where users were
deleted, you cannot use the memberOf attribute on restored user accounts to determine global or
universal group membership or to recover membership in external domains. Go to
the next step. If there is an external record of group membership in external
domains, add the restored users to security groups in those domains after the
user accounts have been restored.
If you know the password for the offline administrator
account, start the recovery domain controller in Dsrepair mode. If you do not
know the password for the offline administrator account, reset the password
while the recovery domain controller is still in normal Active Directory
mode.
You can use the setpwd command-line tool to reset the password on domain controllers
that are running Microsoft Windows 2000 Service Pack 2 (SP2) and later while
they are in online Active Directory mode.
Note Microsoft no longer supports Windows 2000.
For more information
about changing the Recovery Console administrator password, click the following
article number to view the article in the Microsoft Knowledge Base:
How to change the Recovery Console administrator password on a domain controller
Administrators of Windows Server 2003 domain
controllers can use the set dsrm password command in the Ntdsutil command-line tool to reset the password for the offline
administrator account.
For more information about how to reset the
Directory Services Restore Mode administrator account, click the following
article number to view the article in the Microsoft Knowledge Base:
How to reset the Directory Services restore mode administrator account password in Windows Server 2003
Press F8 during the startup process to start the recovery
domain controller in Dsrepair mode.Log on to the console of the recovery domain
controller with the offline administrator account. If you reset the password in
step 5, use the new password.
If the recovery domain controller is a
latent global catalog domain controller, do not restore the system state. Go
directly to step 7.
If you are creating the recovery domain controller
by using a system state backup, restore the most current system state backup
that was made on the recovery domain controller that contains the deleted
objects now.
Auth restore the deleted user accounts, the deleted
computer accounts, or the deleted security groups.
Note The terms auth restore and authoritative restore refer to the process of using the authoritative restore command in the Ntdsutil command-line tool to increment the version numbers of specific
objects or of specific containers and all their subordinate objects. As soon as
end-to-end replication occurs, the targeted objects in the recovery domain
controller's local copy of Active Directory become authoritative on all the
domain controllers that share that partition. An authoritative restoration is
different from a system state restoration. A system state restoration populates
the restored domain controller's local copy of Active Directory with the
versions of the objects at the time that the system state backup was
made.
For more information
about auth restoring a domain controller, click the following article number to
view the article in the Microsoft Knowledge Base:
How to perform an authoritative restore to a domain controller in Windows 2000
Authoritative restorations are performed
with the Ntdsutil command-line tool by referencing the domain name (dn) path of the
deleted users or of the containers that host the deleted users.
When
you auth restore, use domain name (dn) paths that are as low in the domain tree
as they have to be to avoid reverting objects that are not related to the
deletion. These objects may include objects that were modified after the system
state backup was made.
Auth restore deleted users in the following
order:
Auth restore the domain name (dn) path for each deleted
user account, computer account, or deleted security
group.
Authoritative restorations of specific objects take longer but
are less destructive than authoritative restorations of a whole subtree. Auth
restore the lowest common parent container that holds the deleted
objects.
By using this Ntdsutil
format, you can also automate the authoritative restoration of many objects in
a batch file or a script. Note This syntax is available only in Windows Server 2003. The only
syntax in Windows 2000 is to use: ntdsutil "authoritative restore" "restore
subtree object DN path".
Auth restore only the OU or Common-Name (CN) containers
that host the deleted user accounts or groups.
Authoritative
restorations of a whole subtree are valid when the OU that is targeted by the Ntdsutil Authoritative restore command contains the overwhelming majority of the objects that
you are trying to auth restore. Ideally, the targeted OU contains all the
objects that you are trying to auth restore.
An authoritative restore
on an OU subtree restores all the attributes and objects that reside in the
container. Any changes that were made up to the time that a system state backup
is restored are rolled back to their values at the time of the backup. With
user accounts, computer accounts, and security groups, this rollback may mean
the loss of the most recent changes to passwords, to the home directory, to the
profile path, to location and to contact info, to group membership, and to any
security descriptors that are defined on those objects and
attributes.
Note Repeat this step for each peer OU that hosts deleted users or
groups.
Important When you restore a subordinate object of an OU, all the parent
containers of the deleted subordinate objects must be explicitly auth
restored.
Restart the recovery domain controller in normal Active
Directory mode.
Outbound-replicate the authoritatively restored objects
from the recovery domain controller to the domain controllers in the domain and
in the forest.
While inbound replication to the recovery domain
controller remains disabled, type the following command to push the
authoritatively restored objects to all the cross-site replica domain
controllers in the domain and to global catalogs in the forest:
After all the direct and transitive domain controllers in the
forest's domain and global catalog servers have replicated in the
authoritatively restored users and any restored containers, go to step
11.
If all the following statements are true, group membership links
are rebuilt with the restoration of the deleted user accounts. Go to step 13.
Your forest is running at the Windows Server 2003
forest functional level or at the Windows Server 2003 interim forest functional
level.
Only security groups were not deleted.
All the deleted users were added to all the security
groups in all the domains in the forest.
Consider using the Repadmin command to accelerate the
outbound replication of users from the restored domain controller.
If
groups were also deleted, or if you cannot guarantee that all the deleted users
were added to all the security groups after the transition to the Windows
Server 2003 interim or forest functional level, go to step 12.
Repeat steps 7, 8, and 9 without restoring the system
state, and then go to step 11.
If deleted users were added to local groups in external
domains, do one of the following:
Manually add the deleted users back to those
groups.
Restore the system state and auth restore each of the
local security groups that contains the deleted users.
Verify group membership in the recovery domain controller's
domain and in global catalogs in other domains.
Use the following command to enable inbound replication to
the recovery domain controller:
repadmin /options recovery dc name -DISABLE_INBOUND_REPL
Make a new system state backup of domain controllers in the
recovery domain controller's domain and global catalogs in other domains in the
forest.
Notify all the forest administrators, the delegated
administrators, the help desk administrators in the forest, and the users in
the domain that the user restore is complete.
Help desk administrators
may have to reset the passwords of auth restored user accounts and computer
accounts whose domain password changed after the restored system was
made.
Users who changed their passwords after the system state backup
was made will find that their most recent password no longer works. Have such
users try to log on by using their previous passwords if they know them.
Otherwise, help desk administrators must reset the password with the
user must change password at next logon check box checked,
preferably on a domain controller in the same Active Directory site as the user
is located in.
How to recover deleted users on a Windows Server 2003 domain controller when you do not have a valid system state backup
If you lack current system state backups in a domain where user
accounts or security groups were deleted, and the deletion occurred in domains
that contain Windows Server 2003 domain controllers, follow these steps to
manually reanimate deleted objects from the deleted objects container:
Follow the steps in the "How to manually undelete objects
in the deleted objects container" section to reanimate deleted users,
computers, groups, or all of these.
Use Active Directory Users and Computers to change the
account from disabled to enabled. (The account appears in the original
OU.)
Use the bulk reset features in the Windows Server 2003
version of Active Directory Users and Computers to perform bulk resets on the
"password must change at next logon" policy setting, on the home directory, on
the profile path, and on group membership for the deleted account as required.
You can also use a programmatic equivalent of these features.
If Microsoft Exchange 2000 or later was used, repair the
Exchange mailbox for the deleted user.
If Exchange 2000 or later was used, reassociate the deleted
user with the Exchange mailbox.
Verify that the recovered user can log on and access local
directories, shared directories, and files.
You can automate some or all of these recovery steps by using
the following methods:
Write a script that automates the manual recovery steps
that are listed in step 1. When you write such a script, consider scoping the
deleted object by date, time, and last known parent container, and then
automating the reanimation of the deleted object. To automate the reanimation,
change the isDeleted attribute from TRUE to FALSE, and change the relative
distinguished name to the value that is defined either in the lastKnownParent attribute or in a new OU or common name (CN) container that is
specified by the administrator. (The relative distinguished name is also known
as the RDN.)
Obtain a non-Microsoft program that supports the
reanimation of deleted objects on Windows Server 2003 domain controllers. One
such utility is AdRestore. AdRestore uses the Windows Server 2003 undelete
primitives to undelete objects individually. Aelita Software Corporation and
Commvault Systems also offer products that support undelete functionality on
Windows Server 2003-based domain controllers.
To obtain AdRestore,
visit the following Web site:
Microsoft
provides third-party contact information to help you find technical support.
This contact information may change without notice. Microsoft does not
guarantee the accuracy of this third-party contact information.
How to manually undelete objects in a deleted object's container
To manually undelete objects in a deleted object's container,
follow these steps:
Click Start, click Run,
and then type ldp.exe.
Note If the Ldp utility is not installed, install the support tools
from the Windows Server 2003 installation CD.
Use the Connection menu in Ldp to perform
the connect operations and the bind operations to a Windows Server 2003 domain
controller.
Specify domain administrator credentials during the bind
operation.
On the Options menu, click
Controls.
In the Load Predefined list, click
Return Deleted Objects.
Note The 1.2.840.113556.1.4.417 control moves to the Active Controls
window.
Under Control Type, click
Server, and the click OK.
On the View menu, click
Tree, type the distinguished name path of the deleted objects
container in the domain where the deletion occurred, and then click
OK.
Note The distinguished name path is also known as the DN path. For
example, if the deletion occurred in the contoso.com domain, the DN path would
be the following path:
cn=deleted Objects,dc=contoso,dc=com
In the left pane of the window, double click the Deleted Object Container.
Note As a search result of Idap query, only 1000 objects are returned by default. Fot example, if more than 1000 objects exist in the Deleted Objects container, not all objects appear in this container. If your target object does not appear, use ntdsutil, and then set the maximum number by using maxpagesize to get the search results .
Double-click the object that you want to undelete or to
reanimate.
Right-click the object that you want to reanimate, and then
click Modify.
Change the value for the isDeleted attribute and the DN path in a single Lightweight Directory
Access Protocol (LDAP) modify operation. To configure the
Modify dialog, follow these steps:
In the Edit Entry Attribute box, type
isDeleted.
Leave the Value box
blank.
Click the Delete option button, and
then click Enter to make the first of two entries in the
Entry List dialog.
Important Do not click Run.
In the Attribute box, type
distinguishedName.
In the Values box, type the new DN
path of the reanimated object.
For example, to reanimate the JohnDoe
user account to the Mayberry OU, use the following DN path:
cn=JohnDoe,ou=Mayberry,dc=contoso,dc=com
Note If you want to reanimate a deleted object to its original
container, append the value of the deleted object's lastKnownParent attribute to its CN value, and then paste the full DN path in the
Values box.
In the Operation box, click
REPLACE.
Click ENTER.
Click to select the Synchronous check
box.
Click to select the Extended check
box.
Click RUN.
After you reanimate the objects, click
Controls on the Options menu, click the Check Out button to remove (1.2.840.113556.1.4.417) from the Active Controls box list.
Reset user account passwords, profiles, home directories
and group memberships for the deleted users.
When the object was
deleted, all the attribute values except SID, ObjectGUID, LastKnownParent and SAMAccountName were stripped.
Enable the reanimated account in Active Directory Users
and Computers.
Note The reanimated object has the same primary SID as it had before
the deletion, but the object must be added again to the same security groups to
have the same level of access to resources. The first release of Windows Server
2003 does not preserve the sIDHistory attribute on reanimated user accounts, computer accounts, and
security groups. Windows Server 2003 with Service Pack 1 does preserve the sIDHistory attribute on deleted objects.
Remove Microsoft Exchange attributes and reconnect the user
to the Exchange mailbox.
Note The reanimation of deleted objects is supported when the deletion
occurs on a Windows Server 2003 domain controller. The reanimation of deleted
objects is not supported when the deletion occurs on a Windows 2000 domain
controller that is subsequently upgraded to Windows Server 2003.
Note If the deletion occurs on a Windows 2000 domain controller in the
domain, the lastParentOf attribute is not populated on Windows Server 2003 domain
controllers.
How to determine when and where a deletion occurred
When users are deleted because of a bulk deletion, you may want to
learn where the deletion originated. To do so, follow these steps:
If auditing has been correctly configured to track the
deletion of organizational unit (OU) containers or of subordinate objects, use
a utility that searches the security event log of domain controllers in the
domain where the deletion occurred. One such utility that searches event logs
on a scoped set of domain controllers is the EventCombMT utility. EventCombMT
is part of the Windows Server 2003 Resource Kit Tools tool set.
For
more information about how to obtain the Windows Server 2003 Resource Kit Tools
tools set, visit the following Microsoft Web page:
Follow steps 1 to 7 in the "How to manually undelete
objects in a deleted object's container" section to locate deleted security
principals. If a tree was deleted, follow these steps to locate a parent
container of the deleted object.
Copy the value of the objectGUID attribute to the Windows clipboard.
You can paste this
value when you enter the Repadmin command in step 4.
Type the following command:
repadmin /showmeta GUID=<objectGUID> <FQDN>
For example, if the objectGUID of the deleted object or container
is 791273b2-eba7-4285-a117-aa804ea76e95 and the fully qualified domain name
(FQDN) is dc.contoso.com, type the following command:
The syntax of this command must include the GUID of the deleted
object or container and the FQDN of the server that you want to source from.
In the Repadmin command output, find the originating date,
time and domain controller for the isDeleted attribute. For example, information for the isDeleted attribute appears in the fifth line of the following sample
output:
If the name of the originating domain controller in the
second column of the output appears as a 32-character alpha-numeric GUID, use
the Ping command to resolve the GUID to the IP address and the name of the
domain controller that originated the deletion. The Ping command uses the
following syntax:
ping –a <originating DC GUID>._msdomain controllers.<fully qualified path for forest root domain>
Note The "-a" option is case sensitive. Use the fully qualified domain
name of the forest root domain regardless of the domain that the originating
domain controller resides in.
For example, if the originating domain
controller resided in any domain in the Contoso.com forest and had a GUID of
644eb7e7-1566-4f29-a778-4b487637564b, type the following command:
The output returned by this command is similar to the following:
Pinging na-dc1.contoso.com [65.53.65.101] with 32 bytes of data:
Reply from 65.53.65.101: bytes=32 time<1ms TTL=128
Reply from 65.53.65.101: bytes=32 time<1ms TTL=128
Reply from 65.53.65.101: bytes=32 time<1ms TTL=128
Reply from 65.53.65.101: bytes=32 time<1ms TTL=128
View the security log of the domain controller that
originated the deletion on or about the time that was indicated in the output
of the Repadmin command in step 5.
Give consideration to time skews
and time zone changes between the computers that were used to arrive at this
point. If delete auditing is enabled for OU containers or for the deleted
objects, pay attention to the relevant audit events. If auditing is not
enabled, pay attention to users who had the permissions to delete OU containers
or the subordinate objects in them, and that also had authenticated against the
originating domain controller in the time before the deletion.
How to minimize the impact of bulk deletions in the future
The keys to minimizing the impact of the bulk deletion of users,
of computers, and of security groups are to make sure that you have up-to-date
system state backups, to tightly control access to privileged user accounts, to
tightly control what those accounts can do, and finally, to practice recovery
from bulk deletions.
System state changes occur every day. These
changes may include password resets on user accounts and on computer accounts
in addition to group membership changes and other attribute changes on user
accounts, on computer accounts, and on security groups. If your hardware fails,
your software fails, or your site experiences another disaster, you will want
to restore the backups that were made after each significant set of changes in
each Active Directory domain and site in the forest. If you do not maintain
current backups, you may lose data or may have to roll back restored objects.
Microsoft recommends that you take the following steps to prevent
bulk deletions:
Do not share the password for the built-in administrator
accounts or permit common administrative user accounts to be shared. If the
password for the built-in administrator account is known, change the password
and define an internal process that discourages its use. Audit events for
shared user accounts make it impossible to determine the identity of the user
who is making changes in Active Directory. Therefore, the use of shared user
accounts must be discouraged.
It is very rare that user accounts, computer accounts, and
security groups are intentionally deleted. This is especially true of tree
deletions. Disassociate the ability of service and delegated administrators to
delete these objects from the ability to create and to manage user accounts,
computer accounts, security groups, OU containers, and their attributes. Grant
only the most privileged user accounts or security groups the right to perform
tree deletes. These privileged user accounts may include enterprise
administrators.
Grant delegated administrators access only to the class of
object that those administrators are permitted to manage. For example, it is
better if a help desk administrator whose primary job is to modify properties
on user accounts does not have permissions to create and to delete computer
accounts, security groups, or OU containers. This restriction also applies to
delete permissions for the administrators of other specific object
classes.
Experiment with audit settings to track delete operations
in a lab domain. After you are comfortable with the results, apply your best
solution to the production domain.
Wholesale access-control and audit changes on containers
that host tens of thousands of objects can make the Active Directory database
grow significantly, especially in Windows 2000 domains. Use a test domain that
mirrors the production domain to evaluate potential changes to free disk space.
Check the hard disk drive volumes that host the Ntds.dit files and the log
files of domain controllers in the production domain for free disk space. Avoid
setting access-control and audit changes on the domain network controller head.
Making these changes would needlessly apply to all the objects of all the
classes in all the containers in the partition. For example, avoid making
changes to Domain Name System (DNS) and distributed link tracking (DLT) record
registration in the CN=SYSTEM folder of the domain partition.
Use the best-practice OU structure to separate user
accounts, computer accounts, security groups, and service accounts in their own
organizational unit. When you use such a structure, you can apply discretionary
access control lists (DACLs) to objects of a single class for delegated
administration, and you make it possible for objects to be restored according
to object class if they have to be restored. The best-practice OU structure is
discussed in the "Creating an Organizational Unit Design" section of the Best Practice Active Directory Design for Managing Windows Networks white paper. To obtain this white paper, visit the following
Microsoft Web site:
Test bulk deletions in a lab environment that mirrors your
production domain. Choose the recovery method that makes sense to you, and then
customize it to your organization. You may want to identify the following:
The names of the domain controllers in each domain that
is regularly backed up
Where backup images are stored
Ideally, these
images are stored on an extra hard disk that is local to a global catalog in
each domain in the forest.
Which members of the help desk organization to
contact
The best way to make that contact
Most of the bulk deletions of user accounts, of computer
accounts, and of security groups that Microsoft sees are accidental. Discuss
this scenario with your IT staff, and develop an internal action plan. At
first, focus on early detection and on returning functionality to your domain
users and to your business as quickly as possible. You can also take steps to prevent accidental bulk deletions from occurring by editing the access control lists (ACLs) of organizational units. For more information about how to use Windows interface tools to prevent accidental bulk deletions, visit the following Microsoft Web site to view "Guarding Against Accidental Bulk Deletions in Active Directory":
For more information about how to prevent accidental bulk deletions by using Dsacls.exe at the command line or by using a script, visit the following Microsoft Web site to view " Script to Protect Organizational Units (OUs) from Accidental Deletion":
Tools and scripts that may help you recover from bulk deletions
The Groupadd.exe command-line utility reads the memberOf attribute on a collection of users in an OU and builds an .ldf
file that adds each restored user account to the security groups in each domain
in the forest.
Groupadd.exe automatically discovers the domains and
security groups that deleted users were members of and adds them back to those
groups. This process is explained in more detail in step 11 of method
1.
Groupadd.exe runs on the following domain controllers:
Windows Server 2003 domain controllers
Windows 2000 domain controllers that have the .NET 1.1
framework installed
Here, ldf_file represents the name of
the .ldf file to be used with the previous argument,
after_restore represents the user file data source,
and before_restore represents the user data from the
production environment. (The user file data source is the good user
data.)
To obtain Groupadd.exe, contact Microsoft Product Support
Services.
The
third-party products that this article discusses are manufactured by companies
that are independent of Microsoft. Microsoft makes no warranty, implied or
otherwise, about the performance or reliability of these
products.
For more information about how to restore an object that contains extended characters, click the following article numbers to view the articles in the Microsoft Knowledge Base:
The Ntdsutil authoritative restore operation is not successful if the distinguished name path contains extended characters in Windows Server 2003 and in Windows 2000
For more information, click the following article numbers to view the articles in the Microsoft Knowledge Base:
Error message when you try to import .ldf files on a computer that is running Windows Server 2003 with Service Pack 1: "Add error on line LineNumber: No such object"
After you restore deleted objects by performing an authoritative restoration on a Windows Server 2003-based domain controller, the linked attributes of some objects are not replicated to the other domain controllers
For more information on how to use the AD Recycle Bin feature included in Windows Server 2008 R2, please reference the Active Directory Recycle Bin Step-by-Step Guide available from this Microsoft Web site:http://technet.microsoft.com/en-us/library/dd392261(WS.10).aspx
Back to the top
