I’m a big fan of MBAM.
For those of you who are unaware of what MBAM is, the official name is Microsoft BitLocker Administration and Monitoring. It’s a solution that provides an admin interface for BitLocker drive encryption. It allows admins to:
- automate the encryption process
- check compliance of devices in the estate
- report on those devices
- deploy a self-service and helpdesk portal to allow BitLocker key recovery
- and more!
Why am I a big fan of MBAM? Well it provides a more secure and feature driven solution to BitLocker management than the other solutions provided by Microsoft, specifically Active Directory (AD) key storage and Azure Active Directory (AAD) storage. MBAM separates the computer object from the recovery key. This way, if the device is removed from AD or AAD, then my recovery key is gone along with the object.
MBAM also provides something called key rotation. If a recovery key is used then a new key is generated for the device. It’s a single use key which reduces the attack vector, ensuring that the recovery key retrieved by a user, in the self-service portal, and scribbled down on a post-it note stuck to the screen, quickly becomes obsolete.
The problem with MBAM has been it’s been a little neglected over the last few years. As advocates of deploying the Microsoft security stack to ease our Windows 10 upgrades and management, we have been trying to sell customers on using MBAM. However, they have been wary to adopt due to the lack of nurturing and a fast approaching end of support life. Though the extended support end date is 07/09/2024, the mainstream support end date is 07/09/2019. Add to that a lack of feature changes, and many have started to call it a dead duck. Thus, they shy away from investing in the solution.
Luckily, the ConfigMgr Product Group stepped to the rescue like knights in shining armour. The announcement, at MMS in May, sent the Twittersphere in to meltdown—in a good way! Many championed the decision to bring the solution back from the dead.
It didn’t take the product group long to get something out there. The latest ConfigMgr Technical Preview (TP) 1905 release introduced the ConfigMgr integrated version of MBAM. Again, for those who are unaware, the TP release of ConfigMgr is a monthly release of the product which contains functionality that Microsoft is working on. This means it contains features that aren’t yet available in the current branch release of the product. The TP version is restricted to a maximum of ten clients to ensure it is not deployed to the enterprise. You should have an install of TP in your development environment or lab where you can test out the new features. Some features may be be fully formed and almost ready for the current branch release. Others might be out for trial and feedback in the very early stages of their development.
MBAM is one of the latter type features, it’s in its early stage of readiness. You can set it up and test but there are things missing which you would normally expect to see with the current MBAM 2.5SP1 release. For example; no OSD integration, no self-service or helpdesk portal, and no reporting. The main element of MBAM is operational though. It has ability to store keys in the database (the MBAM DB is now built into your CM DB). Also, keys rotate!
Let’s take a look at this exciting new feature. I’ll run through its configuration to give you an idea how it works and what’s required to get started with ConfigMgr integrated MBAM.
To get MBAM up and running in your Technical Preview 1905 site you will need to have your Management Point and clients set up in HTTPS mode. So PKI and certificates are required. This introduces some complexity to the mix. It’s worth investing time at the Microsoft ConfigMgr documentation site and read up on how to do this. I recommend reading the following as a starter:
- Plan for security in Configuration Manager – https://docs.microsoft.com/en-us/sccm/core/plan-design/security/plan-for-security
- PKI certificate requirements for System Center Configuration Manager – https://docs.microsoft.com/en-us/sccm/core/plan-design/network/pki-certificate-requirements
- Step-by-step example deployment of the PKI certificates for System Center Configuration Manager: Windows Server 2008 certification authority – https://docs.microsoft.com/en-us/sccm/core/plan-design/network/example-deployment-of-pki-certificates
Set up Your MBAM Policy
You’ll find new MBAM features under \Assets and Compliance\Overview\Endpoint Protection\Bitlocker Management (MBAM) in the ConfigMgr console. The first step in the process to implement MBAM is to create your MBAM control policy. To do this, right-click Bitlocker Management (MBAM) and select Create BitLocker Management Control Policy.
In the Control Policy you’ll be defining the encryption settings and MBAM settings. To do this ensure you select both Client Management and Operating System Drive checkboxes. Name the policy and click Next.
At the Setup screen you will need to decide whether to enable drive encryption and what cipher strength to apply. The top set of options relate to Windows 7 or 8/8.1 devices, whilst our Windows 10 settings are contained in the last set of drop downs. These give us access to the XTS-AES encryption algorithm introduced with Windows 10 1511. I recommend setting operating system encryption to 256-bit to take advantage of the increased bit strength.
The Client Management screen sets the MBAM settings. Do we want to enable MBAM (I’m pretty sure we do)? Do we want to store the recovery password and key package, or the recovery password only? How often should client check-in with the MBAM service, the default being every 90 minutes?
Finally, the Operating System Drive screen allows the definition of TPM options. Do we allow encryption of device without a compatible TPM device? Do we want to set TPM or TPM+PIN, which requires a pre-boot PIN to be entered when the device is turned on and what is the minimum length of the PIN?
After completing the control policy, it needs to be deployed. If you are familiar with Configuration Baselines, you’ll recognize the MBAM policy is using this technology when deployed. In my example, I have set to allow remediation outside any ConfigMgr maintenance windows and set a schedule to run a compliance evaluation every 7 days.
What’s Happening on the Client?
When the policy is received on the client, you can check if the device is compliant or not in the Configurations tab of the ConfigMgr applet in the Control Panel.
Two new log files will appear in the CCM\Logs folder on the device. These are the BitLockerManagementHandler.log and the BitLockerManagement_GroupPolicyHandler.log.
The BitLockerManagementHandler.log records the installation of the MBAM client install on the device.
The BitLockerManagement_GroupPolicyHandler.log records the communication with the ConfigMgr Management Point, which acts as the MBAM Recovery service endpoint and has this service installed on it.
How come devices aren’t connecting to the MBAM Recovery Service?
OK, so as I stated at the beginning of the blog, some of these TP features are very early into their release cycle and therefore we can expect a bug or two to crop up. With the MBAM feature we have a bug and we need to intervene and move the install process along manually for now.
If you take a look the MBAM logs in Event Viewer on your devices, they are more than likely moaning that the MBAM service can’t be located or doesn’t exist.
Well, that’s a pretty accurate description since the service has failed to install due to the bug. If you open up the MPControl.log on the site server, you’ll see the following error.
This is because of an issue with the PS1 script. You can remedy this by taking the mbamrecoveryser.cab file from your Microsoft Configuration Manager\bin\X64 folder, extracting its contents and copying the Microsoft BitLocker Management Solution folder into your Program Files\SMS_CCM folder. You can then manually execute the PS1 script using the command C:\Windows\system32\WindowsPowerShell\v1.0\PowerShell.exe -ExecutionPolicy RemoteSigned -File C:\Program Files\Microsoft Configuration Manager\bin\x64\mbamrecoveryserviceinstaller.ps1 as highlighted in the mpcpontrol.log.
If the script has run successfully, you’ll then have a SMS_MP_MBAM virtual directory in IIS on the site server.
Hopefully, clients will start to chat with the MBAM Recovery Service and connect successfully.
Encryption and MBAM magic
With the devices now communicating successfully, users will be prompted to start encryption via the MBAM pop up window. Click Start to begin the process.
If you are testing this with a virtual machine, you will get a failure to encrypt as below. The Event Viewer logs will state BitLocker Drive Encryption only supports Used Space Only Encryption on thin provisioned storage.
To test this on a virtual machine, you can kick start encryption by right-clicking the C: drive and selecting Turn on BitLocker or by opening up a CMD prompt as admin and running the manage-bde -on c: command. This will start the disk encryption process and MBAM will escrow the key to the database on completion.
You can take a look at the key in the ConfigMgr database under the dbo.RecoveryAndHardwareCore_Keys table.
You can cross reference this against the client by issuing a manage-bde -protectors -get c: to ensure you are looking at the correct information in the database.
The MBAM feature is a fantastic addition to ConfigMgr. As you can see, it’s a little rough around the edges at the moment and requires the addition of complexity in HTTPS to stand this up. That said, it delivers required functionality for any enterprise deploying MBAM that wants to effectively manage its encrypted endpoints without cloud-based management.
There’s still lots of work to do to get this ready for current branch, so I can’t see this hitting the 1906 release of ConfigMgr. I think we’ll see feature changes and enhancements made in the Technical Previews over the coming months. Potentially we’ll see it trickle into current branch in some form by the end of the year, fingers crossed. In the meantime, watch this space for further news.