Securing Active Directory also involves good backup practices

Due to its role as the key component for enterprise identity management, Active Directory continues to draw unwanted attention from unscrupulous actors looking to infiltrate an organization's systems.

Despite the underlying technology being 20 years old, Active Directory remains a core infrastructure component that most organizations use to manage users and their credentials. Azure Active Directory is the cloud-based heir apparent to Active Directory, but it's not a straight swap for the on-premises version. Many enterprises continue to use Active Directory for user credentials to access networked resources and SaaS, such as apps for file sharing and other collaboration needs. This streamlined single sign-on process makes it both convenient and more secure when users do not have to create separate user IDs and passwords for every separate service. But this credential storehouse also makes Active Directory a tempting target for attackers.

Security researchers have noted a trend with attacks that focus more narrowly on overtaking the Active Directory system. Its commanding role within the data center makes Active Directory the perfect malware launching pad. Once hackers get elevated privileges, they will pick up unfettered access and can hide their presence from logs and further fortify their position. In the most extreme cases, these breaches result in a ransomware attack that will require a payout to decrypt data. Securing Active Directory from these incidents can avoid damaging a company's reputation and the notoriously difficult recovery effort for domain controllers.

Click on this book cover
image to learn more
about the book from
Packt Publishing.

The Active Directory Administration Cookbook from Packt Publishing devotes a chapter to securing Active Directory by making stricter password policies and saving Group Policy objects.

The following excerpt from comes from Chapter 10 and explains why administrators should perform preventive maintenance and backup the Active Directory domain controllers to restore them should a worst-case scenario arise.

By creating a backup of the system state, all the information to restore a domain controller is copied off the system and onto removable media. This way, when a domain controller becomes non-functional, the backup can be used to restore the functionality to a new Windows Server or to boot up from the backup media to restore the entire domain controller.

Windows Server Backup uses Volume Shadow Copies with the Active Directory VSS Writer to make a backup of the Active Directory files while they are in use. This way, there is no need to stop the Active Directory Domain Services service to make a consistent backup. In most third-party applications, this functionality is called Application-consistent backups.

Domain controllers can be restored authoritatively or non-authoritatively. When restored authoritatively, the restored domain controller will take the role of authoritative replication partner for Active Directory and SYSVOL replication; all domain controllers will assume that its version of the database and SYSVOL are the truth. When restoring non-authoritatively, the domain controller will report itself as a new Active Directory replication partner and replicate from other domain controllers, ignoring any changes it might have made before being restored.

The DSRM (Domain Services Restore Mode) password for the domain controller is stored on the system and provides the ability to logon with a local administrator account when the Active Directory Domain Services service is not running. When the service runs on a domain controller, this password cannot be used. Document the password properly.

As modern malware attacks on environments feature invalidating backups, make sure to store backups for domain controller off the network, and ideally off-site.