Direct Inward Dialing: +1 408 916 9892
IT administrators should constantly monitor the health of their Active Directory environment. This proactive step is important for ensuring that AD performance is optimized, and the IT team is not flooded with help desk calls.
This article looks at just four ways in which IT teams can assess and check their AD health, and take remedial actions, if necessary. This is not an exhaustive list.
The command Repadmin /replsummary summarizes the replication status of all the domain controllers in all the domains in the forest. You will also get to know the last time a DC replicated, and why it stopped replicating.
Here's a sample output:There are four system components that are critical for the efficient running of Active Directory Domain Services: 1) DFS Replication, 2) DNS Server, 3) Intersite Messaging, and 4) Kerberos Key Distribution Center (See the screenshot below).
Make sure that these components are running properly by executing the following command:
$Services='DNS','DFS Replication','Intersite Messaging','Kerberos Key Distribution Center','NetLogon',’Active Directory Domain Services’ ForEach ($Service in $Services) {Get-Service $Service | Select-Object Name, Status}
A sample output after executing this command is shown below. Note that we're also checking the health of the NetLogon service, and Active Directory Domain Services (denoted by NTDS) as a whole. The sample status here shows that all services are running.
The DCDiag tool can be used by IT administrators to test several aspects of a domain controller including DNS. One of the most common reasons for the non-performance of AD is DNS. DNS failure can in turn lead to replication failure. Executing DCDiag for DNS will enable IT administrators to check the health of DNS forwarders, DNS delegation, and DNS record registration.
Here's the command to run this:DCDiag /Test:DNS /e /v
The first step towards mitigating the vulnerability of unsecure LDAP binds is to identify whether you are affected, which you can do by looking through event ID 2887. Event 2887 is logged by default in the DC once every 24 hours, and it shows the number of unsigned and cleartext binds to the DC. Any number greater than zero indicates your DC is allowing unsecure LDAP binds.
Next, you need to detect all devices and applications using unsecure binds by looking through event ID 2889. Event 2889 is logged in the DC each time a client computer attempts an unsigned LDAP bind. It displays the IP address and account name of the computer that attempted to authenticate over an unsigned LDAP bind.
The PowerShell cmdlet for getting this is as follows:Get-WinEvent -FilterHashtable @{ LogName = 'Security' ID = 2889 }
In this sample output, we don't see any unsecure binds.