Tag Archives: BitLocker

MBAM Configuration Nuances

This week we are continuing testing of the new Microsoft Bitlocker Administration and Management 2.0 tool (MBAM).

MBAM is not overly complicated, but it does have several service tiers and dependencies which make initial setup a bit irksome. After plowing though configuration of a SQL database, SQL Reporting Services, and IIS, we are still need to configured MBAM Group Policy settings, and then we needed to do a fir number of tweaks to make the service actually work. Here are the most significant deviations from the official documentation:

  1. The Group Policy templates for MBAM are not uploaded to the AD Policy Store during product installation, nor does the documentation recommend that you complete this step. However, if you want to be able to edit MBAM Policy from any workstation in the domain, you really do need to upload the ADMX templates. Making this happen is easy… just use the MBAM installer to install the MBAM policy templates locally, then open c:windowsPolicyDefinitions, and copy BitLockerManagement.admx and BitLockerUserManagement.admx to \[domain]SYSVOL[domain]PoliciesPolicyDefinitions (you will need domain admin rights to do this. Also copy the corresponding .adml files in the local language directory of your local PolicyDefinitions directory to the local language directory on the domain controller (in my case, these are in the “en-US” subdirectory).
  2. After installing the MBAM Client and policy settings, clients were failing to auto-initiate encryption, and were failing to report status to the management server.  The MBAM Admin Event Logs were showing the following error:
    Log Name: Microsoft-Windows-MBAM/Admin
    Source: Microsoft-Windows-MBAM
    Event ID: 4
    Task Category: None
    Level: Error
    User: SYSTEM
    Computer: machinename.domainname.com
    Description: An error occurred while sending encryption status data.
    Error code: 0x803d0013

    This is occurring for a few reasons.  One, the MBAM server is not trusted for delegation, so it cannot perform Kerberos authentication in IIS.  Two, the public URL for MBAM services (https://bitlocker.uvm.edu) does not match the internal name of the server (BAM1).  To fix this, we needed perform a few additional configuration steps:

    1. Create the following key and value on the MBAM management server:
      DWORD(32-bit) - DisableMachineVerification
      Value = 1
    2. On the MBAM Administration Server AD object, enable the “Trust for delegation for any service (Kerberos Only) option”, under the Delegation tab.
    3. Use the “setspn” utility to add additional principal names for the public URL of the server to the AD server account:
      setspn -A HOST/bitlocker.mydomain.com MYDOMAINMyServer$
      setspn -A HTTP/bitlocker.mydomain.com MYDOMAINMyServer$
      setspn -A RestrictedKrbHost/bitlocker.mydomain.com MYDOMAINMyServer$
      (Note that if using a service account to run the MBAM Administration Service, you should use “setspn” to set the HOST/HTTP names for the service account instead of the domain computer account).
    4. It appears that it may also be necessary to add the “BackConnectionHostNames” Reg_multi_Sz value to “HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaMSV1_0” to include any public dns names used by the MBAM Administration Server (this likely only is necessary in a load balanced configuration).

    We then needed to perform an IISRESET on the management server, and cycle the MBAM Clients.

  3. The MBAM Help Desk web application was failing to display reports.  This was happening because the installer grabbed the unencrypted reporting services URL from the reporting services instance.  I had to open:
    C:inetpubMicrosoft BitLocker Management SolutionHelp Desk Websiteweb.config
    Then locate the tag, and edit the URL value to the SSL version of the Reporting Services web site.
  4. The MBAM documentation claims that you will use MBAM policies in place of standard Windows BitLocker policies.  This is somewhat misleading… Many MBAM policy settings also will change the “classic” BitLocker policy settings, so it will appear that you have configured both classic and MBAM policies in the editor.  This would not really be a problem were it not for the fact that MBAM policies are not comprehensive.  You may need to return to the “classic” settings to configure appropriate behavior in your environment.  For example, we experienced difficulty in encrypting a Dell Latitude 10 tablet using MBAM.  On this machine, we saw the following error in the MBAM Admin Event Log:
    Event ID: 2
    An error occurred while applying MBAM policies.
    Volume ID:\?Volume{VolumeGUID}
    Error Code: 0x803100B6
    Details:  No pre-boot keyboard or Windows recovery Environment detected.  The user may not be able to provide the required input to unlock the volume.

    This error is happening because our policy is set to “Allow PIN” (BitLocker PIN Authenticator is allowed, but not required).  Apparently, MBAM default-fails the attempted encryption, even though this is not a “fatal” error.  To allow encryption to continue, I needed to set the classic policy “Enable use of BitLocker authentication requiring preboot keyboard input on slates” as defined here:
    With this policy in place, encryption completes successfully on the tablet computer.

Other than these caveats, the tool does appear to be working.  Setting up our PGP Universal Server was easier, but suffering though the pain of ongoing PGP disk encryption support was agonizing.  Hopefully a little time spent on configuring a solid BitLocker support environment will bear lasting fruit for our constituents down the road.

Additional Resources:

Rick Delserone’s MBAM: Real World Information – A rundown on MBAM Certificate Configuration, Group Policy Templates, and undocumented registry settings:

SQL Server 2012, Transparent Data Encryption, and Availability Groups

We are looking into using Microsoft Bitlocker Administration and Monitoring (MBAM) 2.0 to manage BitLocker in our environment. One requirement for MBAM is a SQL Server database instance that supports Transparent Database Encryption (TDE).  (Update 2013-06-04:  Microsoft now claims that TDE is “optional” with MBAM 2.0, which is nice to know.  If only they had told me this before I went to the trouble of setting up SQL 2012 Enterprise just for this project!)  Currently we also are in the process of investigating the creation of a consolidation SQL 2012 Enterprise Edition “Always On” Availability Group. I wanted to see if I could create the MBAM Recovery Database in a SQL 2012 Availability Group. This proved slightly tricky… fortunately I was able to find a decent reference here:

The trick is, you need to create SQL Certificates that on each member server of the Availability Group that have the same name and are generated from the same private key. The procedure follows…

On the first server in the group, create a SQL Master Key and Certificate by running the following code. The script will create a backup file in your SQL Server data directory. Move this file to an archival location. If you lose the file and password, you will not be able to recover encrypted databases in a disaster event:


-- Create a Master Key

-- Backup the Master Key
   TO FILE = 'Server_MasterKey'
   ENCRYPTION BY Password = 'Password2';

-- Create Certificate Protected by Master Key
CREATE Certificate SQLCertTDEMaster
   WITH Subject = 'Certificate to protect TDE key';

-- Backup the Certificate
BACKUP Certificate SQLCertTDEMaster
   TO FILE = 'SQLCertTDEMaster_cer'
   WITH Private KEY (
       FILE = 'SQLCertTDEMaster_key',
       ENCRYPTION BY Password = 'Password3'

Now create a master key on any secondary servers in the availability group, and create the same cert by using the backup file from the first step, above. You will need to copy the certificate backup files to the local server data directory, or use a network share that is accessible to the account running the script:

-- Create a Master Key
-- Backup the Master Key
   TO FILE = 'Server_MasterKey'
   ENCRYPTION BY Password = 'Password2';

-- Create Certificate Protected by Master Key
CREATE Certificate SQLCertTDEMaster
   FROM FILE = 'SQLCertTDEMaster_cer'
   WITH Private KEY (
       FILE = 'SQLCertTDEMaster_key',
       Decryption BY Password = 'Password3'

To avoid needless trouble, create your new database and add it to your availability group before encrypting the database. Once the database is created, you can initiate encryption by opening SQl Management Studio, right-clicking your database, select tasks, then select “Manage Database Encryption”. Select the option to generate the database encryption key using a server certificate. Select the certificate created above, and select the option to “set database encryption on”.

Once the database is encrypted, be sure to test availability group failover to make sure the secondary servers are able to work with the encrypted database.

Dell XPS 12 – The Windows 8 Flagship?

Regular readers of my blog (all two of you) may recall the “series” I started this fall on Windows 8 launch devices (concerning the HP Envy X2 and the Samsung SmartPC Pro 700t). These devices both had strengths, but failed in other ways that made them difficult or impossible to support in an enterprise environment. This month, I got my hands on a device that breaks though that barrier and satisfies in a big way. The new Dell XPS 12 finally arrived on our campus about two weeks ago. We immediately were taken with its light weight (3 lbs.), sleek styling, and novel materials (full carbon fiber base, carbon fiber and aluminum lid, and that unique flip-over touch screen). The 8-second boot time is another impressive feature. A longer battery life would have been appreciated, but I can live with it. Other helpful enhancements would be the inclusion of an active stylus. I also would appreciate slightly more resistance in the keyboard.

Others have weighed in on the appearance, performance, and usability of this fancy Ultrabook, though, so I will forgo further commentary on those aspects of the XPS 12. What most concerned us was the ability to support OS redeployment, BitLocker encryption, and hardware servicing on our Campus.

We unboxed and re-deployed the computer with Windows 8 Enterprise within one day. There were a few deployment hiccoughs, but in general re-deployment was what we have come to expect from Dell. All required drivers for the XPS 12 were made available in a single downloadable CAB file. We extracted this CAB to our MDT/LiteTouch Deployment Share, rebuilt our boot media, and initiated a LiteTouch deployment. There was a brief problem getting LiteTouch to start… we needed to disable the “Safe Boot” option in EFI/BIOS, and we needed to set the EFI boot mode to “Legacy” to allow our boot media to operate. Once those changes were made, the XPS 12 booted to our USB WinPE media without complaint. Upon completion of deployment, all devices in the device manager reported as functioning. There were no “poorly-behaved” drivers that required un-scripted installation. We did find that the track-pad was behaving strangely. Investigation revealed that the PnP process had grabbed a Windows 7 track-pad driver from our deployment share. We corrected this manually, then separated our Windows 8 drivers from our Windows 7 drivers in the Deployment Workbench… this should prevent the problem from recurring in future deployments.

BitLocker was easy to implement. The TPM chip readily was recognized by the OS, and TPM-with-PIN encryption was accomplished in minutes. I spent half a day trying to encrypt an older Dell Latitude E6500 a few months back. This was a breeze by comparison.

On the servicing front, we have good news. Dell now is allowing on-site servicing for all XPS models, with full reimbursement for parts and labor for qualified technicians. Physical serviceability is a big concern for newer Ultrabooks. A troubling trend in tablet and notebook design is the use of solder on drive mounts and glue to hold batteries in place (the latest “Retina” MacBooks and the MS Surface tablets suffer from these problems). Fortunately, it appears that all major components of the XPS 12 can be removed and replaced without the need to re-solder or remove glue. The most frequently swapped components such as the battery, mSATA drive, and memory chips look pretty easy to access. The keyboard is a bit of a pain to get to, but at least it can be serviced.

If only more Windows 8 launch products had been this good… I hope we see more products of this quality coming from Dell (and other vendors) in the near future.

Update:  2013-11-1

Five months into using the XPS 12, I started to have trouble with the trackpad.  It would not click anymore!  Since we are working with an evaluation unit, I do not have warranty coverage, so I figured I had no warranty to void by attempting to repair it on my own.

Some digging in the Dell support site revealed that the so-called XPS 12 “User Manual” is actually a service manual!  The readily available PDF document illustrates step-by step how to remove the carbon fiber base plate and the battery in order to get to the track pad.  (The only challenging part was locating a #5 Torx screwdriver to take off the base plate.)  Within 15 minutes I had removed the click pad, and cleaned the trapped grit out from under it.  (Within a half hour I had the unit re-assembled.  In another 15 minutes I had taken the base plate back off, reconnected the battery power connector, and re-attached the base plate, again.)  The unit powered back on as normal, with the track pad working like new.

At a time when consumer devices are moving towards non-serviceable designs (think MacBook Retina), it is nice to see a device that is thin and light while still maintaining serviceability.  Perhaps the track pad on the MacBook Retina is less prone to trapping grit, but imagine if it did?  With all the components glued together, you might be out $2000 because of a bit of sand.  I really have to hand it to Dell.  These XPS Ultrabooks are really nicely engineered.


BitLocker, Windows 7, and Smart Cards

Mounting frustration with PGP Whole Disk Encryption has me revisiting BitLocker options this week. We last touched on this subject back in the early days of Vista. It appears that enough has changed with Windows 7 that we need to do some policy updates.

First off, I discovered that the BitLocker system volume encryption wizard was not presenting me with startup PIN or startup key options. Further, it also was not backing up recovery key data to Active Directory, as we originally designed it to under Vista. Why? Because Vista BitLocker policies do not apply to Windows 7! A quick step through the “Windows 7”-specific settings in Computer->Policies->Administrative Templates->Windows Components->BitLocker Drive Encryption (and the child “Operating System Drives” settings), and we are back in action.

Next, I noticed new settings related to smart cards in the new Group Policy settings. Does BitLocker now support storage of drive encryption keys on a Smart Card? No… not for system volumes anyway. Still, I was intrigued by option for removable and non-system volumes, and decided to try encrypting my office eSATA drive using BitLocker and a Smart Card certificate.

Microsoft provides the following information on certificate template requirements for BitLocker:
Madeningly, they specify that you should provide the ‘Enhanced Key Usage OID value of’, if you are going to specify an OID. They also say that your “key usage attribute” should be one of three possible options with names like “CERT_DATA_ENCIPHERMENT_KEY_USAGE
“. The problem with this guidance is that the Certificate Template Manager MMC snapin does not expose any such options, and I cannot find docmentation for management of certificate templates using “certutil.exe”, or any other available command line utilities. Am I supposed to use ADSI edit to do all my certificate management these days? Sheesh.

Some googling determined the following:

  1. Enhanced Key Usage, or EKU, is labeled “Application Policies” in the Certificate Template MMC, and they are exposed under the “Extensions” tab of a template properties dialog box.
  2. OID info is not displayed in the list of Application Policies. However, OID maps to the friendly name “BitLocker Drive Encryption”. Select this policy and add it as a cirtical extension, or just leave the Application Policies list empty. Note that you will need to have the “BitLocker Drive Encryption” feature activated on any system from which you you are editing the Certificate Template (I am indebted to DXter for this post which led me on the path to solving this little mystery).
  3. The “key usage attribute” referred to in the BitLocker documentation also is exposed in the “Extensions” tab of the Certificate Template properties dialog. In this case, we will be looking at the “Key Usage” extension. Selecting a value of “Allow key exchange only with key encryption (key encipherment)” appears to work.
  4. Under the “Request Handling” tab, I also specified that the certificate will be used for “Encryption”, and not “smartcard logon”, since I don’t want to use this same cert for Smart card logon… perhaps that will change later on. We also needed to enforce the use of the “Microsoft Smart Card Key Storage Provider” under the “Cryptography” tab, since we want to generate the certificate key on the smart card. (Note that you need CNG-compliant cards to use this option. CNG cards are the way to go!)

BitLocker Recovery Tool Problems

The motherboard on my trusty Dell Latitude D820 went sour this Sunday, requiring a full replacement.  No one was ever killed by losing access to their laptop for a few days, but I was somewhat annoyed to have lost access to my iTunes installation (thus making backup and sync of my iPod impossible), and I also had a few video files which I was working with stored locally.  So I decided to try testing out the BitLocker recovery tool to see if I could get access to my files.

First, we had to grab the BitLocker Recovery Tool from Microsoft:

I installed the tool onto a Vista desktop, and connected my laptop drive to the system using a SATA-to-USB converter, such as the one seen here:
That worked really well… my BitLocker-encrypted drive immediately became visible to Windows, although it (quite naturally) could not be read.

I then ran repair-bde.exe, providing the BDE recovery key which I had escrowed in Active Directory.  I used the option to extract the recovered data to an image file on my external ieee1394 drive.  Repair-bde dutifully extracted the drive contents to a file, and reported success.

Now the tricky part… how do we read this massive image file?  It does not appear to be a WIM file (i.e. “imagex /mount” claims that this is not a valid WIM image).  It cannot be mounted as an ISO, nor can it be extracted using any of the archive handlers supported by 7-zip.  It cannot be mounted as a virtual disk using Virtual PC.  What is it???

I contacted Microsoft support to find out… support claims that I should use “IMGMOUNT.EXE” to mount the image.  Some Googling suggests that this utility is part of the short-lived “Automated Deployment Services”, or “ADS” product that Microsoft released to allow deployment of Windows Server 2003 images:

So I downloaded ADS, and did a “custom” install, and selected the “image creation tools”.  This installed “IMGMOUNT.EXE” on my system, in the “%ProgramFiles%Microsoft ADSbin” directory.  Unfortunately, IMGMOUNT also reports that this is not a valid image.  Microsoft support also told me that the third-party tool “ISOBuster” should be able to mount the image:
But this failed to work, too.  I guess the image generated by Repair-bde.exe simply was not valid.

Oh well, by this time, my laptop has been repaired and I was able to get back into my OS using the BitLocker recovery password.  I guess the takehome lesson is not to use the recover-to-image option of the repair-bde tool… instead, recover to the root on an external drive.  This may not work any better, but at least you will know immediately if the utility is successful in decrypting your drive contents.

The other problem that I ran into was the fact that I lost my TPM chip with the motherboard.  As you may know, your BitLocker decryption keys are stored on your TPM, and that your TPM cannot be detached from your motherboard.  New motherboard=new TPM.  Oh well… It looks like I need to turn off BitLocker on my system, decrypt the whole drive, and then re-activate BitLocker.  There does not appear to be a way to write the BitLocker decryption keys to the TPM once the drive is already encrypted… Bummer!