2

My organization is running AD DS on Server 2008 R2 schema. Already a bad start, I know, but let's pretend that's impossible to change. In our default domain policy, we have the following setting enabled to require AD backup of TPM owner authorization value hashes:

Computer Settings\Policies\Administrative Templates\System\Trusted Platform Module Services\Turn on TPM backup to Active Directory Domain Services

As a result, when I try to encrypt an AD-bound Windows 8 Enterprise machine with BitLocker, it fails because Windows 8 tries to store the TPM authorization hash as a child object (with type ms-TPM-OwnershipInformation) of the computer object, while the Server 2008 R2 schema requires storing this information as an attribute (specifically, msTPM-OwnerInformation) of the computer object. This is perfectly fine and dandy - in fact, it's clearly documented in a TechNet article that this behavior is intentional, and the solution is to update to Server 2012 schema. Cool.

The bit that concerns me is that when I try to encrypt an AD-bound Windows 8.1 Enterprise machine, it succeeds under these same circumstances. However, despite the policy setting requiring the TPM backup, it simply doesn't occur - it is neither stored in the computer attribute, nor is it created as a child object to the computer.

I have not been able to find any documentation that would indicate that Windows 8.1 behaves differently from Windows 8 on this matter. As the mainstream support end date for Server 2008 R2 is not until 01/13/14, I wouldn't expect that Microsoft has intentionally implemented what I have described. Might this then be an unintended behavior? If so, how might one best address the matter with Microsoft?

Prosun
  • 203
  • 1
  • 2
  • 9

2 Answers2

1

You are encrypting Windows 8 therefore the 2008r2 schema does need extending to support 2012 extensions for TPM.

Info posted by Greg is for Windows 7 and server 2008r2 which does not need a schema update.

0

You're confusing two different settings.

To prevent BitLocker encryption unless the information is backed up in Active Directory, you need to enable the following Group Policy setting:

Computer > Policies > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives

"Do not enable BitLocker until recovery information is stored to AD DS for operating system drives"

To enable TPM Recovery, you don't need to update the schema. You need to enable write access to the ms-TPM-OwnershipInformation attribute for the Self identity. Microsoft provides the Add-TPMSelfWriteACE.vbs script for this.

Backing Up BitLocker and TPM Recovery Information to AD DS
http://technet.microsoft.com/en-us/library/dd875529%28v=ws.10%29.aspx

You can also backup the information to Active Directory after the fact. This is sometimes useful for computers that are rejoined to the domain:

manage-bde -protectors -get c: 

(get the Numerical Password ID)

manage-bde -protectors -adbackup c: -id {<guid>}  
Greg Askew
  • 34,339
  • 3
  • 52
  • 81
  • I appreciate the feedback, but I don't believe that I am confusing any settings. I am **not** referring at all to BitLocker recovery information, I am talking about [TPM recovery information](http://technet.microsoft.com/en-us/library/dn466534.aspx). In my domain, we back that up to AD; however, [as documented here](http://technet.microsoft.com/en-us/library/jj131725.aspx#BKMK_AuthValue), the manner in which that occurs is different in Windows 8 than in Windows 7. Yet in Windows 8.1, this behavior is different still than Windows 8, with no documentation to explain the discrepancy. – Prosun Aug 28 '14 at 19:52
  • Ok, that was unclear because you said you encrypted the drive and "it" succeeded. If this is a bug, it would be in 8.1/2012 R2, not 2008 R2. You may want to reach out to Microsoft. – Greg Askew Aug 28 '14 at 20:11
  • Sorry about that; I was torn on how to phrase that, and decided to describe it in terms of BitLocker to add more context to my scenario. And I'll probably go ahead and do that, unless I can be proven wrong on my concern. – Prosun Aug 28 '14 at 21:37