0

I recently asked this same question here about a month ago -> BitLocker Recovery Keys Not Showing in Active Directory

But things have changed now and I am still getting the same results. I am going to go as into detail as I can for this post so I don't have to make any more posts (hopefully).

Ok, so we need to store these keys on AD to meet DoD requirements and I wrote a little bit of Java to find out how many we have. After running my Java we have 97 out of 230 computers that have a stored key in AD.

I created a group policy for bitlocker and named it "GP - Bitlocker"

The first settings I changed are in this directory: Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Bitlocker Drive encryption

"Store bitlocker recovery information in active directory domain service"

"Choose Drive Encryption Method and Cipher Strength (Windows 8 / Server 2012)"

"Choose Drive Encryption Method and Cipher Strength (Windows 10)"

"Choose Drive Encryption Method and Cipher Strength (Windows Server 2008, Windows 7)"

Additionally I have changed settings in ../Operating System Drives (the .. being the previous directory)

"Require additional authentication at startup"

"Enforce drive encryption type on operating system drives"

"Choose how BitLocker-protected operating system drives can be recovered"

As for where the group policy is linked, it is stored in a directory with all of my other group policies that we have on our domain named "Group Policy Objects." It was linked to all OUs that we wanted to have the GP enabled but we took it off because it wasn't working and we wanted to only run tests on limited computers.

At the moment, "GP - Bitlocker" is linked to 2 OUs, "Test_Environment" and "Not known." Not known is an OU with real people's computers on our domain with an unspecified department and test_environment is just temporary computers that we use to test GPs.

"Not Known" had 4/16 computers with a stored key and test_enivronment has 1/4 computers with a stored key.

Our scope for the GP

Right now what we are thinking is that since many of our employees don't consistently connect to the VPN or even log onto their computers, they aren't able to get the GP update. We are a construction company and as such, we have many people who work out in the field for months at a time and don't use their computers. However, I think 97 should be more around 180 or so to be accurate to those who have computers in the field. If I am missing any information please let me know and I will be happy to fill in the gaps.

Anon
  • 13
  • 1
  • 2
  • 6
  • You mentioned DOD. Are any of the systems configured for FIPS? If so, some of those settings are inconsistent with FIPS and will not work. Also, you need to enable Group Policy environment debug logging on the systems that aren't working to confirm it is processing the policy, and if BitLocker is already enabled. Since the box is unchecked to require recovery information to be saved to AD, if it is enabled and something doesn't work with saving the recovery information to AD, it would need to be saved by running a manage-bde or PowerShell command. – Greg Askew Jul 30 '21 at 18:23
  • @GregAskew Where do you see the unchecked box for recovery information to be saved in AD? – Anon Jul 30 '21 at 18:50
  • https://i.stack.imgur.com/BiVfs.png Do not enable BitLocker until... – Greg Askew Jul 30 '21 at 19:02
  • @GregAskew Ok I read about that in the group policy description, sounds like I wanted to have that on. I will have to get back to you on the FIPS and whether our systems are configured for it or not – Anon Jul 30 '21 at 20:06
  • Go back to the basics; `1.` Should the GPO be applied to the computers in question? To answer that, run Group Policy Modeling in the GPMC. `2.` If the GPO should be applied, is it being applied? To answer that, run Group Policy Results in the GPMC. `3.` If the GPO should be applied, and it is being applied, are the conditions for the policy settings to be applied being met? – joeqwerty Jul 30 '21 at 21:37
  • Most organizations use recovery passwords. Storing plain text recovery agent passwords are prohibited in FIPS, so that is where a recovery key is needed. Typically you would use a key or a password, but not both and definitely not password if FIPS mode is enabled. BitLocker is hard coded to not use a recovery password/fail if FIPS mode is enabled. – Greg Askew Jul 31 '21 at 00:12

1 Answers1

0

Nick, when you asked your first question, your setting for recovery passwords (the 48 digit key that appears in the AD computer ovbject on the bitlocker recovery tab) were: "Do not allow 48-digit recovery password"

Now you changed that to require the recovery passwords. However, as these systems are encrypted already, these passwords will never make it to AD (as they are saved only at the moment of encryption and NOT afterwards), unless you manually make them. That should be done using a script that you deploy as immediate schedule task, for example batch code for c: drives:

for /f "tokens=1,2" %%a in ('manage-bde -protectors -get C: -Type recoverypassword ^| findstr ID') do manage-bde -protectors -adbackup c: -id %%b
Bernd Schwanenmeister
  • 482
  • 2
  • 5
  • ...alas, since they didn't get created in the first place (as you forbid that), you will have to create them, first: manage-bde -protectors -add c: -rp – Bernd Schwanenmeister Aug 05 '21 at 11:58