One of the more involved aspects of managing Active Directory infrastructure is handling its recovery. This results primarily from the distributed and dynamic characteristics of its content, its dual nature (comprising of hierarchical database and file-system based SYSVOL structure), as well as lack of friendly, intuitive interface that would simplify dealing with its idiosyncrasies. While it is reasonable to expect a forest- or domain-wide disaster would necessitate a complex and time-consuming endeavor, it might be surprising to realize that even restoring individual objects is far from straightforward, and presents a variety of unique challenges.
This article offers an overview and discuss how some of new features incorporated into Windows Server 2008 Directory Services could help with their remediation.
In general, object recovery is accomplished by either performing an authoritative restore or reanimating the tombstone of a deleted object, depending on whether a valid System State backup is readily available. For more details, refer to the Microsoft Knowledge Base article 840001, the length of which should give you an idea about magnitude of the effort involved.
However, even with clear instructions describing each of implementation steps, additional caveats must be taken into consideration. The first one (increasing complexity of authoritative restore) concerns identifying the most appropriate backup set. In this case, your decision depends on the ability to establish point in time when an undesired change or deletion took place. This, in turn, determines which backup set contains target data in its correct state.
Unless you have invested extra resources and money in developing Active Directory monitoring and auditing solution, such determination might be difficult or even impossible to make without performing at least a few restores. This is a time consuming process, consisting of restarting a domain controller in Directory Services Restore Mode, restoring Active directory Database from one of available backups, and running ntdsutil
command line utility, attempting to extract the right object). The second one, applicable in the same context and relevant in case of deletions, results from limitations of ntdsultil
interface, which expects you to provide Distinguished Name of each objects you want to restore. Again, this might be difficult to accomplish without being able to identify its previous status. The third one affects efficiency of reanimating tombstoned objects and relates to the fact that a deletion, besides renaming, and placing them in a designated Active Directory container hidden from majority of standard AD management tools also strips off most of their attributes. This leaves only a few such as, objectGUID, objectSID (and sIDHistory, if present) as well as sAMAccountName).
With additional information available from CN and lastKnownParent attributes, these are sufficient to locate them and perform undeletion. However, all the missing ones must be repopulated for the object to become fully functional, which requires, as in the first two cases, access to historical data.
With Windows Server 2008-based domain controllers (regardless of the domain or forest functional level), each of these challenges become considerably easier to handle thanks to the Database Mounting Tool. Implemented as DSAMAIN.EXE command line executable, this utility allows you to launch backups of Active Directory or Lightweight Directory Services (previously known as Active Directory Application Mode or simply ADAM) databases in the read-only state. This facilitates browsing content via any program capable of communicating via LDAP over an arbitrary set of ports (this includes majority of standard AD management tools, including Active Directory Users and Computers, Active Directory Domains and Trusts, Active Directory Sites and Services, ADSIEdit or LDP.EXE).
Although DSAMAIN.EXE is most frequently associated with the new Active Directory snapshot feature (which our next article will discuss in detail), its functionality extends to any standard backup created with Windows Server 2008 (as well as any third-party programs that leverages Volume Shadow Copy Service) from which Active Directory database (NTDS.DIT file) can be extracted. Note that this applies to full volume and System State backups in the VHD format, as well as those created via ifm
context of ntdsutil
for the purpose of implementing Install from Media procedure.
DSAMAIN requires that the location of the database is specified via the -dbpath
parameter. In addition, you must also designate an arbitrary integer value that will determine an LDAP port (paired with the -ldapPort
parameter), which will be used for access to directory services. By default, providing this number automatically assigns the next three integers as ports utilized by SSL-based LDAP, Global Catalog (GC), and GC SSL access. However, you do have an option to modify this default assignment with /sslPort
, /gcPort
and /gcsslPort
parameters). An optional -allowNonAdminAccess
switch allows you to delegate permissions for viewing database content to non-Administrators. Without it, this ability is limited strictly to members of Domain Admins and Enterprise Admins groups.
For example, the following command executed on a Windows Server 2008 system hosting a domain controller would make the Active Directory database (extracted from a VSS-generated backup to the D:Restore80408NTDSntds.dit
) available for offline browsing on LDAP port 33389 to members of Domain Admins and Enterprise Admins groups. The full description of DSAMAIN syntax is available in Windows Server 2008 Technical Library:
DSAMAIN -dbpath "D:Restore80408NTDSntds.dit" -ldapPort 33389 |
If the database is in a consistent state and the port is not used by another service, you should receive a confirmation stating "Microsoft Active Directory Domain Services startup complete." DSAMAIN launched in this fashion will remain active until you stop its execution with CTRL+C key combination, which triggers display of the "Active Directory Domain Services was shut down successfully" message and return of the command prompt. In the meantime, however, you can examine the copy of Active Directory just initiated using any LDAP-capable utility that allows you to target specific directory services instance, including the following:
-ldapPort
parameter (33389 in our example). Alternatively, you can launch the console directly from the Command Prompt by executing DSA.MSC /SERVER=DC_Name:LDAP_Port_Number
.
DSSITE.MSC /SERVER=DC_Name:LDAP_Port_Number
.
DOMAIN.MSC /SERVER=DC_Name:LDAP_Port_Number
from the Command Prompt).
In the resulting dialog box, type stopservice
in the Attribute text box with 1
as its value (make sure that the DN path is empty), and follow by clicking on Enter and Run command buttons.
-t
parameter to designate LDAP port to connect to). For more information about their syntax, refer to CSVDE and LDIFDE Microsoft TechNet articles.
There is one additional, extremely convenient way of generating data that can be mounted using DSAMAIN.EXE that has been introduced in Windows Server 2008 domain controllers. This new method relies on point-in-time, Volume Shadow Copy Service (VSS) based captures (known as snapshots) of the content of a drive hosting Active Directory database. We will review their characteristics in more details in the next article.
This article was first published on ServerWatch.com.