A new aspect to securing USB data: SID protectors

Edited by: Andrew Leniart
With Windows evolving further, the built-in protective mechanisms get better and better. Still, Microsoft is not very good at introducing those to the technical community. This article is about a new bitlocker functionality that could revolutionize your concept for protecting USB: SID-protectors.

Admins like using mighty tools to control several aspects of network and system security. They like to restrict, to block things for the sake of security. After a while, they realize that now that everything is secure, nobody can do their work properly and they reverse the process. Rarely, we can introduce measures that are really safe by design, keeping people from doing the things they shouldn't while not messing up the things they should be doing. I guess I have found one of those rare exceptions.

First of all: who is this for? This is for you network admins in need of USB encryption that run or soon plan to run a Windows 8.x or windows 10 domain network. Normally, you would expect to see at least a 2012 DC in that network, too - those OS' are a required for using this new feature that I am about to explain.

Then: What is "it"? It's about providing users with personalized, pre-configured USB thumb drives that

  • Are encrypted and readable only by them
  • Will unlock hands-free anywhere when the user is at the office
  • Will not work on Joe Users home computer, nor on any thief's machine
  • Will bring you one step closer to fully controlling the USB data traffic after all!

This is all made possible by a new bitlocker feature introduced in Windows 8: SID protectors! The key used to unlock the encrypted drive is in the user identity itself, BitLocker uses domain authentication... this is no less than single sign-on extending into bitlocker!

Getting there is pretty easy:

 1 We configure a unique Bitlocker2Go ID for our domain: Provide the unique identifiers for your organization.  We need to set another policy so that all these other USB devices that are not bitlocked yet cannot be written to, anymore: Deny write access to removable drives not protected by BitLocker. Make sure to also check the box “Deny write access to devices configured in another organization

Also enable the policy Control use of BitLocker on removable drives and make sure to uncheck both boxes in it. This will keep users from messing with encryption themselves and also deny access to recovery keys, which is important.

2 Then, we logon as domain user of domain “yourdom” with local admin rights, take an empty thumb drive (x:) and switch to an elevated command line and go 


manage-bde -on x: -rp -used

Instantly, it is encrypted. (Surely, we will be so clever to have configured recovery key AD-backup, before). Next, we add a SID protector, so that only our friend Joe User (Juser) may read it: 


manage-bde -protectors -add -SID yourdom\Juser x:

That's all, you gotta love how easy this is!


We give this device to Joe User and he's happy with it:  Joe can use it on any domain computer, he does not have to enter a password. If he leaves it on his desk, other users cannot take and read it, he may even lose it or have it stolen, it's encrypted to a very strong key (AES 256, require that through here).

But be aware: if he leaves it plugged into a machine, it is unlocked and readable even if he logs off - see the note at the end.


When our dear Joe User turns to BadBoy Joe (TM), and tries to use this drive to transfer data to his private laptop, guess what happens? It is locked, he cannot read it on non-domain-joined machines! 

Can he do anything about it, like use an unlock password? No! He can't, he has no password for the drive, just his SID but that he cannot use since he is not connected to the domain network anymore :)!


What if Joe gets smart and bitlocks his own drive at home? Surely, he would have the recovery key for that one and may write company data to it? No, wrong. Remember we configured a unique ID? That's what Joe hasn't got at home, so that plan would fail unless Joe manages to read that identifier from the registry or from the policy file in the sysvol share and set that at home. In order to prevent that, we need to make the registry portion and also the policy that sets the ID unreadable for Joe. Let me show you how:

 The above screenshot shows, how to distribute the suitable registry permissions for the FVE policy key

The above screenshot shows, how the GPO permissions need to be set, so that no ordinary user may read the policy file itself right from the sysvol share.

PS: Please note, I called our user “Joe User”, not “Admin Joe”. If Joe has local admin rights on the domain computers, he can of course extract the recovery key from the drive to unlock it even at home so the whole concept relies on tightly secured networks, where users use and admins administer.


PSPS: You might have noticed that these measures don't keep users from bringing their own USB thumb drives to read all sorts of malware from. To fight this, I'd like to link one of my other articles where I discuss a method to whitelist storage devices – these combined will end unsafe usb data traffic.

So this was about a new method to keep company data inside the company. 


Note: for those of you who like to ensure that even if the drive is left plugged in on a machine, others cannot read it: deploy a task that locks all removable drives when users log off. The removable drives' drive letters are identified and locked through this command


for /f %a in ('wmic logicaldisk where "drivetype=2" get name') do manage-bde -lock %a

  Let the executor be system and the 3 triggers be "on disconnect from user session" (any user, local computer []1st trigger] + any user, remote computer[]2nd]) and also "on workstation lock" (any user), that looks fool-proof.


Comments (12)

Yes with hyphen. "domain-users".
Distinguished Expert 2019


That's what I thought :-)
The group is called "domain users", so adjust your command, remove the hyphen.
I tried without Hyphen and it gives
ERROR: Invalid Syntax.
"users" was not understood.

Command I used: manage-bde -protectors -add -SID domain.local\domain users x:
Distinguished Expert 2019


Spaces are (as usual) not allowed. Make it:
manage-bde -protectors -add -SID "domain.local\domain users" x: 

Open in new window

It works now!! Thank you so much for your help..

View More

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.