Posts Tagged ‘BitLocker’

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.

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:

http://technet.microsoft.com/en-us/library/dd875548(WS.10).aspx

Madeningly, they specify that you should provide the ‘Enhanced Key Usage OID value of 1.3.6.1.4.1.311.67.1.1′, 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 1.3.6.1.4.1.311.67.1.1 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:
http://www.microsoft.com/downloads/details.aspx?FamilyID=4FFD0D16-A51B-48B1-9042-AE1FB2DE40C6&displaylang=en

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:
http://insidecomputer.stores.yahoo.net/seatasatousb.html
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:
http://www.microsoft.com/downloads/details.aspx?FamilyID=D99A89C9-4321-4BF6-91F9-9CA0DED26734&displaylang=en

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 ADS\bin” 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:
http://www.isobuster.com/
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!