Delegation of access to Bitlocker Recovery Passwords – this way, please!

Edited by: Andrew Leniart
In this article, I will show you how delegation of control for Bitlocker recovery passwords in Active Directory is supposed to work using the common wizard, and why I think that you should do it differently.

This article is meant for system administrators, who try to apply the principle of least privilege when it comes to Active Directory. I find it relevant because the usual way of using the delegation of control wizard cannot satisfy the need for least privilege and we need to use a largely unknown method instead, which will be described here.

Imagine you have applied bitlocker to all your machines and you use Active Directory to store the recovery passwords. Please be aware, that without having these recovery passwords, you are facing data loss, as soon as the end-user forgets his PIN. Furthermore, these passwords are not comparable to PINs, because, with PINs, you are only able to start the machines, so a thief, that has somehow acquired such a PIN, will not be able to access the data on the drive. Recovery passwords, however, give you full control over the drives. Thus, they need to be guarded well.

Now imagine, that for your next vacation, you plan to enable a trusted colleague to read the recovery passwords of a certain OU for recovery purposes: if someone forgets his PIN, they should ask you colleague to help them out. How do you proceed?

Well, normally, you will use the delegation of control wizard, when it comes to delegating specific permissions in AD, so let’s see if we can use it. It turns out to be hidden well, but in the end (remember, bitlocker used to be called msfve "Microsoft Full Volume Encryption"), you might find it should be possible like this:

Keep in mind, that we wanted to apply only read permissions and not enable our colleague (Mr. Loser in this example) to delete...

After applying this, you would surely test it with your colleague’s account. To your surprise, it does not work. In fact, nothing has changed, he cannot see the passwords. Readers, how many of you arrived at this point? Quite a few, I assume. And what do we do now, turn to the “big G” and search the internet for a solution? Or will you rather experiment with the permissions? Back in the day, I did the latter, just to find out, that unless we grant FULL CONTROL, it will not work.

So what’s wrong here, why are we unable to grant read permissions only? Please imagine what full control implies… our colleague can not only read the passwords, but he himself may delegate access and enable other users to read these passwords, or even decide to delete the passwords (OK, let’s call it “accidentally delete them”). Without a doubt, this is unacceptable. So let’s google.

Googling reveals, that Microsoft documentation on this topic is hard to find. Imagine, this should concern bitlocker admins since server 2008 came out...but not before 2011, a Microsoft employee wrote this blog post: which names it: 

Normally in AD, all attributes are readable by “Authenticated Users”. Some attributes should inherit permissions, but should not be readable by “just anyone”. To protect attributes like this, they can be marked as “confidential”.

Aha, so there we have it, the “confidentiality bit” is what this is all about. Microsoft has further protected access to these passwords, setting that bit, and the delegation of control wizard does not know what to do with it. Google that, please, you will find even more misconceptions, like for example on

All objects created with the Confidentiality bit set to 1, are only available for users, who have full control access to that object. These objects are hidden for other users in Active Directory.

Fortunately, this is kind of wrong. For the "dumb" delegation of control wizard, it is true, but there is a way to access those without full access and it requires you to use admin’s old friend LDP.exe, which is a tool built-in to Windows 10 and also the server OS’.

From the Microsoft blog, you may gather, that what we need to do, is grant the so-called “control access” in addition to merely read access - then the recovery passwords are accessible, read-only.

So to be honest, I got the idea for the key part of this article from that Microsoft blog post. But what that blog does not tell you, is that with LDP.exe, we can go far beyond what’s possible using the delegation of control wizard. Remember: the delegation of control wizard can ONLY target the “big players” like containers or OUs. LDP.exe however, can target single computers or even single recovery passwords to single partitions! That means if you ever wanted to grant a colleague read permissions for a certain server’s bitlocker recovery password, there is no way to do it short of using LDP.exe unless you would like to resort to complicated scripting.

Let me give you an example, a complicated one: I would like to let my colleague, Mr. Loser (username: mine\loser) access only the recovery password for partition c: of server C2.

So on our DC, as domain admin, I start LDP.exe, 

connect to my AD [> Connection > Connect > OK > Bind (CTRL-B) > OK  > Tree (CTRL-T) > OK] 

and I navigate to the OU where our server C2 is in, which is here called “Rechner”. Double click the computer object and I can see, it has three bitlocked partitions (3 recovery passwords are visible). Partition c: was the first I encrypted, so based on the time stamp, I select the topmost entry, right-click it and select > Advanced > Security Descriptor 

and click on OK in the following dialogue, too, to arrive here, where we can grant access by adding a DACL, with just read access and of course "control access" which overcomes the confidentiality bit:

Now click on update and there you go. Colleague Mr. Loser will be able to see a single recovery password on the Bitlocker recovery tab in ADUC now, while the other two are hidden for him as desired.

Mission complete!

For the most common case, granting permissions on the OU level, you select an OU and do it exactly the same way – the result will be, that Mr. Loser can see all recovery passwords of all machines inside that OU, but not delete them, nor change permissions :-)

Be aware of one thing, though: in my opinion, the reason that this method is rather unknown, is that most people we delegate these permissions to are fully trusted, anyway. I mean, give someone a recovery password and he can own the machine if he can only get physical access. So the reason I post this is rather to promote the method of per-machine delegation that LDP.exe gives us than to remind you of the principle of least privilege that the standard method kind of violates. Still, ruling out that your vacation-substitute deletes all these keys by accident is important.

There is one final line of “fine-print”: if you happen to use a server 2016 1607 DC (my screenshots used server 2019), you will find that its version of LDP.exe does for some strange reason not offer to change the security descriptor! Oops… here you will need to use LDP.exe on a windows 10 client, or, if you insist on making these changes at the server itself, download the good old ADAM from (archived download, no longer on Microsoft servers!) and extract it – it holds a working version of LDP.exe, that you may use as a standalone executable on server 2016.

So that’s all for now. If you have questions, please ask a related question here on EE!


Comments (0)

Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.

Get access with a 7-day free trial.
You Belong in the World's Smartest IT Community