What can be used to keep Active Directory data secure?
Published Sep 19 2018 02:54 PM 4,985 Views

First published on TechNet on Sep 26, 2012


With the increase in concern over data privacy and security, one of my customers recently asked about securing Active Directory data while stored on disk and what could be done in relation to network traffic.  My first thoughts were BitLocker and IPSEC.  However, there are a number of different considerations that factor in.   Special thanks to Brent Whitlow for contributing to this post.


Protecting Active Directory Information on Disk


Active Directory data primarily resides in the NTDS.DIT file as well as accompanying log files.  Therefore, you could use encryption technology like BitLocker to encrypt volumes that contain Active Directory data.  BitLocker is ideal for protecting volumes holding Active Directory data because it works with features in the server hardware and firmware to provide secure operating system boot and drive encryption, even if protected disks are removed and someone attempts to read them on another system. While you may use Active Directory to store recovery information for BitLocker volumes, using an external data recovery agent for BitLocker would be more suitable when using BitLocker to protect Active Directory data.   (If replicated Active Directory databases were to become corrupt as a whole or no other DCs were available to retrieve the key, storing the recovery key in Active Directory would be like storing the combination to a locked safe inside the safe and forgetting the combination.)  


Therefore, you would want to safely protect any BitLocker recovery keys so that they are accessible to appropriate personnel, secure, and not prone to compromise.    


Encrypting File System (EFS) is another encryption technology but not good to use for encrypting Active Directory data due to a circular dependency at boot time.  Active Directory requires EFS to unlock the database before it can respond to queries.  Yet, in order for EFS to unlock the file, it needs Active Directory.  EFS and BitLocker operate at completely different levels.  Therefore, using EFS you can make Active Directory too secure by creating a deadlock situation between Active Directory and EFS. Protecting data on a volume is important, but what about other forms of Active Directory data? 


Any backups containing Active Directory data must also be secured.  When using BitLocker on a volume, backups of those volumes may not be encrypted.  Further, physical security of backups remains paramount.


Any virtualized DCs in the environment?   Access to stored virtual hard disk files need to be protected as it the equivalent of a physical hard drive of a physical domain controller.  Virtualized DCs need the same amount of care and consideration if not more.  It is relatively easy for someone with administrative access to the virtualization host to have access to the files on that host.   Choose only reliable and trusted administrators to have administrative access to the virtualization hosts that contain virtualized DCs.


Further, use of removable storage devices can be limited by Group Policy.  As such, you may want to limit who can write to removable storage or limit these devices to read-only access.


Protecting Active Directory Data over the Network


Transmission of Active Directory data over the network may be protected quite easily using methods like IPSEC or 802.1x if these are already in use within the environment.  LDAPS and LDAP become somewhat irrelevant over a secured connection when using IPSEC or 802.1x.  However, LDAP is still used for things like client logon or related to Group Policy so this may be something to protect when not using encryption over the network.  Standard permissions within Active Directory permit access to Authenticated Users. 


IPSEC or 802.1x would cover encryption of traffic for domain joined clients.  Non-domain joined clients do not query personal data stored in Active Directory and would be protected by IPSEC or 802.1x once joined.  Prior to or during the join process, personal data is not queried through LDAP and the user does not have access as an Authenticated User.


One additional item to check would be the use of the old Pre-Windows 2000 Compatible Access Group for older clients like NT4.  Using this option definitely makes Active Directory less secure.


Additional Resources

For information about the Pre-Windows 2000 Compatible Access Group



Virtualizing DCs



Running Domain Controllers in Hyper-V



BitLocker Overview



Planning for Hyper-V Security



Limiting Access to Removable Storage



Version history
Last update:
‎Feb 07 2020 11:57 AM
Updated by: