Goal / Scope
Active Directory or directory services is the backbone of a good network. It allows for configuration of devices and role management of users as well as a good central location for network information. Maintaining a high level of health for Active Directory is very valuable. Currently, there are many resources available online, but few seem to organize the information and look holistically at the Active Directory environment. This reference document should provide a baseline for reviewing a Microsoft Active Directory environment completely and organize it to be effective. Feedback and comments are welcome.
The scope of this document is to provide a step by step process for performing a Microsoft Active Directory health check in any organization and provide recommendations and next steps to remediate and / or stabilize the environment. The target Active Directory forest / domain functional levels for this document are 2003 through 2012, but due to the high level overview approach, other functional levels should benefit from this process as well.
After performing the steps in the process outlined below, issues present in the environment, performance bottlenecks, and overall health concerns should be understood and steps to address them available.
Health Check Tasks
1.1 event logs
Document: event log errors and warnings.
Determine Critical Events: review and document event log errors and warnings that impact Active Directory health as well as overall state.
1.2 Microsoft Best Practices Analyzer(s)
- The Microsoft Best Practice Analyzer: running the Best Practice Analyzer for general server health is also recommended to catch any issues potentially related to Active Directory.
- The Microsoft Active Directory Domain Services and DNS Server Best Practice Analyzer(s): running the Best Practice Analyzer specifically targeted at Active Directory services and DNS services will provide additional information concerning Microsoft’s recommendations for a healthy and stable Active Directory environment.
The BPA for Active Directory Services is located in Server Manager > Roles > Active Directory Domain Services. Scroll down to ‘Best Practices Analyzer’ and click ‘Scan This Role’. The DNS Server BPA is located in Server Manager > Roles > DNS Server. Scroll down to ‘Best Practices Analyzer’ and click ‘Scan This Role’.
1.3 Obtaining Information
Note: To make life easier and where budget permits, there are software packages out there like Quest’s Spotlight on Active Directory which are well worth the cost given the functionality. The following health check process will only leverage free tools and utilities.
Most of the following information can be collected via scripts, but will be important to the outcome of the health check.
- Servers: number / type / role(s) / names / IP Addresses
- Server Specifications: CPU(s) / RAM / virtual / physical hardware architecture / number of NICs / OS version(s) / Service Pack level(s) / manufacture of hardware of physical servers or hosts of virtual servers
- Location(s) of Servers: DMZ / site(s) / high availability / redundancy (if applicable)
- Hardware Drivers: versions, are latest versions of all drivers installed and up to date, and if not provide reasoning the hardware is not using the latest drivers.
- unrelated products / software: what other software is installed on the server, running in the background
- antivirus software: installed on the Domain controllers and clients
- Other servers sharing resources: for virtual servers, what other servers are running on the host sharing resources
In order to obtain the bulk of information regarding the Domain Controller servers, the following utility script(s) can be used: AD_Health PowerShell script and DC_Info PowerShell script, and can be found here. The DC_Info script is actually part of the AD_Health script, but is include separately in case the need arises to only query for basic server information. The AD_Health script checks a number of different functions and tasks required in an Active Directory environment and reports the results in a file called “c:\scripts\logfile” by default. This can be modified in the script. The script can (and was actually created to) be used and run as a scheduled task. This could provide daily reports on key information about the Active Directory environment.
Another PowerShell script that duplicates some of the information obtained from the above scripts can also be leveraged. This PowerShell script will provide a summary via email if configured correctly. The script can be found here.
The last PowerShell script used for the Active Directory health check is the vCheck PowerShell script which provides the following information:
- FSMO Owners
- Domain Naming
- Active Users and Machine Counts
- User Accounts
- Computer Accounts
- Domain Admins Group Members
- Passwords Set to Never Expire
- Computers Inactive
- Computer Name
- Password Last Set Time Stamp
- DCDiag Failures
- Line Item
- Pattern (Result)
This script also provides a summary of the statistics for running the script such as time to complete, plug-ins used, etc. It is also a great scheduled task to provide email reports on the health of the Active Directory environment from a security standpoint and keeping accounts / objects cleaned up. The screenshot below is a sample of the output, that can be emailed, emailed as an attachment, and / or displayed as html.
Note: Active Directory Health Check script from thesysadmins was added to this list and is another great way to collect information on older domain controllers that may not have PowerShell.
The following commands (in bold) can be run using a command prompt on any domain controller in the environment. The results / output can be piped to a text file instead of displaying them in the command window by appending “> c:\temp\filename.txt“. Simply using “filename.txt” will place the file in the directory the command was issued from.
1.4 Manually obtaining information
Some situations will require manual information gathering. Below are some methods to gather required information without using scripts.
Note: If running on a DC prior to Server 2008, you will need to install the Windows Server 2003 Administration Tools Pack (Adminpak) from here
Find System Boot Time and Uptime:
systeminfo | find “System Boot Time:”
systeminfo | find “System Up Time:”
Display current TCP/IP network configuration:
Analyze the state of domain controllers in a forest:
Provide an overview of any replication failures, and if last replication attempts were successful:
repadmin / showrepl
Update: Instead of using repadmin, the new Active Directory Replication Status Tool (ADREPLSTATUS) can be used. The requirements are the following:
- .NET Framework 4
- Server 2003 Domain Controllers and later.
Returns the FSMO roles holders:
netdom query fsmo
1.5 Active Directory Sites and Services
- Verify site objects are created for every geographical site
- Verify subnet object(s) are created for all subnet(s) being utilized
- Verify subnets are correctly assigned to corresponding sites
1.6 Decommissioned / Rogue DCs
Sometimes DCs are decommissioned / disabled without being removed from Active Directory using the dcpromo command:
- If the Domain Controller is not tombstoned then run dcpromo to remove the domain controller properly
- If the Domain Controller has been decommissioned but is still in Active Directory Sites and Services, then using the following guide will help clean things up.
- Advanced Domain Controller removal requires using ntdsutil.exe to clean up metadata, and should be used with caution. However, if this approach fails, adsiedit is the last resort for clean up of a domain controller, but it is recommended to contact Microsoft for support at this point.
1.7 Check Domain Controllers for general configuration
- IP Configuration: Is the subnet configured correctly? Are DNS servers configured correctly (the domain PDC should be first, then the Domain Controller itself or another local site Domain Controller second. If another option is required, the higher level (root domain) PDC can be used as well.
- Time: All DCs should be in time synchronization with the root domain PDC – find the time on the PDC (taking time zones into account) and verify.
- Windows Firewall: Inbound ports – UDP/TCP 53, 88, 389, 464; UDP 123, 137; TCP 139, 445, 3268 need to be open and available for proper Active Directory functionality.
Run the Microsoft Active Directory Topology Diagrammer (ADTD)
- must be run from a workstation on the domain, with Microsoft Visio installed.
- ADTD.Net Setup.msi which can be obtained from here .
Install and run “ADTD.exe”.
Populate the Server/Domain box, and run through the tabs ticking off what is to be included in the Visio output (the more detail the better) > click Discover! > click Draw!
The results will provide a lot of useful information such as FSMO role holders, Operating System and Service Pack Level of Domain Controllers, Site Links, etc. in a visual format.
1.9 Additional Investigations
- Active Directory design
- Security and Group Policy
- Network Analysis
- Network Configuration(s): firewalls / routers / switches / network load of equipment used
- Network Services: DNS and DHCP should be reviewed for accuracy and missing information.
- Active Directory Domain Sites: number of physical location(s) / number of Active Directory site(s)
- Usage Time Frame(s): What times during any given day are the loads for authentication higher / lower
- Client Types: Windows, Apple, Linux platforms, other
- OS versions and Services Packs: (as applicable)
- 3rd Party Add-ons: What 3rd party helper add-ons are running (if any) for non Windows platforms for authentication and Active Directory integration
2.0 Best Practices per Microsoft recommendations
2.1 Forest / Domain Configuration and Naming
The Microsoft best practice design rule is to design a single Forest with a single Domain whenever possible. By having a single Forest and Domain, central administration can be maintained while, at the same time, it allows for granular subordinate Organizational Unit (OU) administration and delegation of authority. This structure would provide the least amount of administrative overhead. The PDS recommendation is thus to create a single forest / domain to maintain centralized administration and use other AD components (Organizational Units and Security Groups) to delegate administration and authority to agency / program units as required.
|Simple to create and maintainNo trusts necessaryLower hardware costs||An adverse change made to the schema could potentially corrupt Active Directory and affect the entire forest|
|Multiple||Separate schema in multiple forest||More domain controllers resulting in higher hardware costs|
Table 2 – Forest / Domain
Two possible DNS naming conventions have been suggested, and will be detailed here.
The first would be to use external naming both internally as well as externally. For example, domain.com would be the DNS suffix internally and domain.com would also be used as the external addresses.
The second would be to create a DNS naming convention that uses an alternate extension internally so instead of domain.com, internaldomain.com would be used for internal resolution.
Both methods are valid; however, PDS is recommending the second method that uses the .local or .internal extension. This will allow for the creation of a completely separate domain that is not internet routable. Anything that requires access to resources on the internal domain would have separate DNS entries. The internal domain name should be something purchased and valid per Internet domain name policies.
2.2 Active Directory Sites
Active Directory sites are a collection of locations seperated by WAN connections or low speed connections having differnet IP subnets. “Well-connected” WAN connections generally don’t require site separation. “Well-connected” WAN connections inferes LAN speeds or better. Site links are created to reflect the WAN connections between these sites so that a replication topology can be generated to control replication traffic between domain controllers distributed among them. Sites are created and domain controllers are distributed among them to provide faster authentication and resource accessibility for users at each site. Client computers are configured to attempt communication with servers located in the same site as the client before looking for domain contollers in other sites.
Requirements for using multiple sites:
- Geographically different sites connected by a lower speed WAN connection but require high availability of data and network resources
- Sites require dynamic mapping of network resources such as printers and mapped drives
- Sites require access to documents and data from a central location but also locally maintained documents and data
Active Directory Sites are used as replication boundaries between Domain Controllers from the same domain. Active Directory Sites are also used to improve performance and the end-user experience by providing location awareness for manipulating provided services. Multiple Sites control replication traffic and resource communication latency over network slow links. Also location awareness for resource mapping or other configuration can be leveraged in Active Directory Domains at 2008 functional level or better using Group Policy Preferences. Even if all WAN connected sites are connected via high speed links, Active Directory Sites provide other functionality aside from replication boundaries and WAN latency. This functionality should be considered as well for future scope.
|Number of Sites||Advantages||Disadvantages|
|Single||Less AdministrationChanges replicate faster||Too much traffic over slower WAN linkslimited ability for location awareness|
|Multiple (recommended)||Controlled replication over WAN linksAbility for location awarenessimproved performance over slow WAN connections||Sites are arranged per subnets, so configuration updates need to happen when additional subnets are added or removedpotential delays in replication of changes|
Table 7 – Single vs. Multiple Sites
Summary of Best Practices for Securing Active Directory Domain Services
The following table provides a summary of the recommendations provided in this document for securing an Active Directory Domain Services installation. Some best practices are strategic in nature and require comprehensive planning and implementation projects; others are tactical and focused on specific components of Active Directory and related infrastructure. Practices are listed in approximate order of priority, that is., lower numbers indicate higher priority. Where applicable, best practices are identified as preventative or detective in nature. All of these recommendations should be thoroughly tested and modified as needed for your organization’s characteristics and requirements.
|Best Practice||Tactical or Strategic||Preventative or Detective|
|2||Patch operating systems||Tactical||Preventative|
|3||Deploy and promptly update anti-virus and antimalware software across all systems and monitor for attempts to remove or disable it||Tactical||Both|
|4||Monitor sensitive Active Directory objects for modification attempts and Windows for events that may indicate attempted compromise||Tactical||Detective|
|5||Protect and monitor accounts for users who have access to sensitive data||Tactical||Both|
|6||Prevent powerful accounts from being used on unauthorized systems||Tactical||Preventative|
|7||Eliminate permanent membership in highly privileged groups||Tactical||Preventative|
|8||Implement controls to grant temporary membership in privileged groups when needed||Tactical||Preventative|
|9||Implement secure administrative hosts||Tactical||Preventative|
|10||Use application whitelisting on domain controllers, administrative hosts, and other sensitive systems||Tactical||Preventative|
|11||Identify critical assets, and prioritize their security and monitoring||Tactical||Both|
|12||Implement least-privilege, role-based access controls for administration of the directory, its supporting infrastructure, and domain-joined systems||Strategic||Preventative|
|13||Isolate legacy systems and applications||Tactical||Preventative|
|14||Decommission legacy systems and applications||Strategic||Preventative|
|15||Implement secure development lifecycle programs for custom applications||Strategic||Preventative|
|16||Implement configuration management, review compliance regularly, and evaluate settings with each new hardware or software version||Strategic||Preventative|
|17||Migrate critical assets to pristine forests with stringent security and monitoring requirements||Strategic||Both|
|18||Simplify security for end users||Strategic||Preventative|
|19||Use host-based firewalls to control and secure communications||Tactical||Preventative|
|21||Implement business-centric lifecycle management for IT assets||Strategic||N/A|
|22||Create or update incident recovery plans||Strategic||N/A|
2.3.1 Security Groups
Security groups are used to secure resources by allowing administrators to assign the same permissions to a large number of users in one operation. Windows 2000 security groups can be one of three types. They can either be:
• Universal group – used to grant users permission across an entire forest.
• Global group – used to organize user objects from the same domain
• Domain Local group – used to grant users permission to gain access to network resources such as folders, files or printers in the domain
Active Directory Management Role Groups
The actual use of security groups for Active Directory management is not very common. This is an important step for helping maintain the security and integrity of Microsoft Active Directory. Depending on what the business requirements dictate, rights should be delegated to each of the groups setting the access of each group based on the roles of the members of the group.
Domain Local groups will be granted rights at the Domain and OU level. Then the Global groups are assigned into the Domain Local groups. See matrix below where the row across the top is domain global groups containing the users and other domain global groups and the first column is the level of access for each of the objects. For each level of access, a domain local group is created and then domain global groups are populated into these groups based on role requirements.
Further information on Security Groups and Active Directory management, based on roles can be found here.
|Admin L1||Admin L2||Admin L3||Help Desk L1||Help Desk L2||Help Desk L3|
|Create, Modify, Delete Users||X||X|
|Create, Modify Users||X||X||X||X|
|Create Modify, Delete Computers||X||X|
|Create, Modify Computers||X||X||X||X||X|
|Create, Modify, Delete Groups||X||X||X|
|Create, Modify Groups||X||X||X|
|Create, Modify, Delete OUs||X|
|Create, Modify OUs||X|
Table 9 – Security Group Assignments for AD Administration
File and Printer security groups
File system security groups will be managed in a similar way to the Active Directory managment groups. The file resources will have domain local security groups associated directly with them and the end-user objects and global security group objects which require access to the resource will be maintained in global groups associated to the domain local groups. This becomes increasingly important when Group Policy Preferences are introduced into the environment. For further information on Group Policy Preferences and Microsoft recommended best practice please look here (coming soon).
2.3.2 Antivirus and Antimalware Deployments
An out-of-date malware scanner is only marginally better than no scanner at all. Antivirus and Antimalware protection should be checked and verified up to date on all systems. Please see Antivirus and Antimalware Recommendations (coming soon) for more details.
2.3.3 Incomplete Patching
If you don’t keep up with security fixes, your network won’t be yours for long.
Microsoft releases security bulletins on the second Tuesday of each month, although on rare occasions security updates are released between the monthly security updates (these are also known as “out-of-band” updates) when the vulnerability is determined to pose an urgent risk to customer systems.
A consistent and well maintained patching plan should be in place to reduce the risk of system compromise.
Known Issues / Troubleshooting
This section is for the issues that have well defined and tested solutions. As part of a good health check, if a known issue presents itself, it is nice to provide the generally accepted solution.
Active Directory Health Script
Active Directory Health Check PowerShell Script
vCheck Active Directory Health Check
Remove a Domain Controller from Active Directory Manually