Why we should BitLocker (or any other drive encryption) should be clear. A stolen laptop is only worth as much as the retrievable data on it + the value of the laptop. In large enterprises this could be millions of dollars, but for personal use this could lead to embarrassment or worse.

But enterprises seem to struggle with the implementation of BitLocker, amongst the pain points:

• No auditing – unsure which laptops have it enabled or which ones don’t
• Administrative overhead – administrators must manually enable it
• Scripting – if enabled during deployment scripting is required
• Storage of keys in Active Directory – clear text storage of recovery keys

In order to cope with these and other challenges, Microsoft has released the BitLocker Administration and Monitoring toolkit. For the ones that try to download it on the website, sorry, it is only available in the Microsoft Desktop Optimization Pack which comes with a software assurance agreement with Microsoft.

This post goes into the architecture, what users see of it.. and more in depth knowlegde.. soon, the post with the install instructions!

BitLocker implementation architecture

There are two types of deployment possible. The basic or standard deployment uses native Windows / Microsoft tools that are already available in Active Directory/Windows 2008/R2 Server and Windows 7 Enterprise/Ultimate. The deployment does not require additional software, nor additional cost for licensing. The second type uses the Microsoft BitLocker Administration and Monitoring toolkit. This toolkit allows enterprises more control over the deployment of BitLocker and provides reporting feedback on the compliancy of computers. While the implementation of the toolkit requires additional servers to host the services the advantages for enterprises can be worth the additional cost. For example the recovery keys for recovering data are stored in a more secure location, roles are automatically available for delegated access to the recovery keys and auditing is applied automatically throughout the entire process. Even more, the deployment of BitLocker does not have to be done with administrative privileges allowing for deployment of BitLocker with minimal rights for end-users.

Figure 1: Roll-out flow chart with MBAM

Server architecture

The MBAM architecture uses centralized services to control a client application on each computer in combination with Group Policies. There are 5 centralized role services for MBAM:

• Recovery and Hardware Database
• Compliance Status Database
• Compliance and Audit Reports
• Administration and Monitoring Server
• Group Policy Template on a server or client computer

While all services can be installed on a single server, the recommended architecture for production deployment is a minimum of three servers with the following roles installed:

• Recovery and Hardware Database, Compliance Status Database, and Compliance and Audit Reports features are installed on a server.
• Administration and Monitoring Server feature is installed on a server.
• Group Policy template is installed on a server or client computer.

All the server components can either be installed on a Windows 2008 SP2 server, or Windows 2008R2 edition. Both client and server applications are available in x86 and x64 architecture. For the database storage and audit reports, SQL 2008R2 server is required, this must be installed on the same server and cannot be located remotely.

Figure 2: Infrastructure Design

Note: The Recovery and Hardware database is an encrypted database (for security), and requires SQL 2008R2 Enterprise edition.

Client Architecture

All clients will have a small application installed that connects to the services using standardized http (optional SSL) protocols. In order to support the roll-out and be able to configure the MBAM Group Policy settings a new Group Policy Object must be created and applied to all systems required to run BitLocker. The application creates a new BitLocker application entry in the control panel of the computer which allows minor management to BitLocker by a user privileged account. For example see the status of the drives and removable drives or change the PIN required to start the computer. The application itself requires no configuration or user input during/after install so it can easily be deployed using centralized deployment tools or scripts. For installation of the tool, an administrative account is required.

Group Policy architecture

When the MBAM toolkit is used, the regular Group Policy settings for BitLocker should not be applied as they are replaced with dedicated MBAM settings that control the MBAM client and in return control the BitLocker policies on a client. The recommended policy settings can be found here.

Administrator experience

When the MBAM toolkit is installed web services will be created, these web services can (by default) only be accessed using Windows integrated authentication and thus additional security measures must be taken to configure Kerberos. Or the default installation can be adjusted to also allow basic authentication in order to make the website more accessible for administrators. The website shows the following main topics:

• Audit Reports
  • Enterprise compliancy report
  • Computer compliancy report
  • Hardware audit report
  • Recovery audit report
• Drive Recovery
• Manage TPM
• Hardware

Figure 3: Website overview

Figure 4: Reports

The manage TPM module allows an administrator to remotely create an ownerfile for the TPM allowing the user to control the TPM chip.

Figure 5: Recovery reports

Operations on the TPM or Drive recovery are audited and stored in the audit recovery reports.

User Experience

When a laptop is deployed, the deployment only requires the MBAM agent to be installed in order to control the BitLocker process. Thus the laptop does not have to be handed over to the user after the BitLocker process has completed the encryption cycle, but can directly be given to a user. As soon as the agent connects to the MBAM services a pop-up will show asking the user to start the encryption process.

Figure 6 &7 & 8: User experience with MBAM

Security with MBAM

As the encryption keys and recovery keys for BitLocker are stored in the MBAM database, it is vital that this information is secure and can only be accessed by administrators. For this additional security groups are created. Thus each role within the BitLocker process for retrieving audits, resetting/handing out recovery keys is delegated to a group. These groups are by default created on the servers where the service is installed, and these groups should only contain Active Directory groups that are connected to the administrators based on granted roles. By using multiple role groups, auditors can be granted the rights to the reports, but can be disallowed to retrieve the actual recovery keys.