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.
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.
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.
Technically, 802.1x is a port authentication protocol, and it doesn't protect data in transmission. Layer 2 encryption usually is not implemented on wired networks.
Nice article Martin.
I'm not sure this is a sound solution when it comes to a virtual DC. Virtual hardware doesn't contain a TPM chip and to use it, it seems that there is measured additional effort. This makes it uncomfortable to me to trust my security system to a product that hasn't been actively encouraged by the DS team,
As much as I would like to use BitLocker on a virtual DC, it doesn't appear to have been vetted by the Microsoft DS team. I would love to see an article posted supporting this from them on this subject.
I agree with Paul. In fact, the BitLocker documentation you link to states:
"BitLocker is not supported for use within a virtual machine. Do not run BitLocker Drive Encryption within a virtual machine. You can use BitLocker in the virtual machine management operating system to protect volumes that contain configuration files, virtual hard disks, and snapshots."
Thanks for the great feedback. I likely should have put a section break in between the discussion of using BitLocker to protect data on physical hardware and the paragraph following that mentioned virtualization. BitLocker wouldn't be practical within a VM. For starters there's no TPM. However, as noted in the following downloadable document, you can use BitLocker on a Hyper-V host to protect where VHDs and configuration files are stored.
Regarding the earlier comment about 802.1x...I prefer IPSEC in comparison. 802.1x when used with wireless or wired connections helps to protect who can connect to the network and you have to have compatible devices in order to implement. Technically it does provide some level of protection...but not as much as other alternatives.