Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AutoBitLocker resource incorrectly identifies Fixed vs Removable drives #11

Closed
MartinVokurek opened this issue May 24, 2018 · 4 comments
Labels
bug The issue is a bug.

Comments

@MartinVokurek
Copy link
Contributor

MartinVokurek commented May 24, 2018

Current implementation of AutoBitLocker resource uses Get-Volume to differentiate between Fixed and Removable drives. This does not work correctly as there are drives reported as Fixed, yet Bitlocker evaluates them as Removable and therefore applies different GPO settings to them. I saw this for certain HP SAS controllers, VMware can also behave this way (https://kb.vmware.com/s/article/1012225) - seems to be related to the way storage controller reports disk capabilities to the OS.

Instead of using Get-Volume, I found \root\cimv2\security\microsoftvolumeencryption:Win32_EncryptableVolume.VolumeType property to correctly report volume types as evaluated by Bitlocker:
0 - OS volume
1 - Fixed volume
2 - Removable volume

MartinVokurek pushed a commit to MartinVokurek/xBitlocker that referenced this issue May 24, 2018
MartinVokurek pushed a commit to MartinVokurek/xBitlocker that referenced this issue May 24, 2018
@johlju
Copy link
Member

johlju commented May 25, 2018

Do you have example output where Get-Volume report the wrong type, but CIM reports it correctly? Labeling this as a bug and help wanted.

@johlju johlju added bug The issue is a bug. help wanted The issue is up for grabs for anyone in the community. labels May 25, 2018
@MartinVokurek
Copy link
Contributor Author

Sure, I found that even my SSD drive connected via USB dongle behaves this way:

gwmi -Namespace root\cimv2\security\microsoftvolumeencryption win32_encryptablevolume -filter "DriveLetter='F:'"|select driveletter,volumetype|fl

driveletter : F:
volumetype  : 2
get-volume -driveletter "F"|select driveletter,drivetype|fl

driveletter : F
DriveType   : Fixed

@johlju
Copy link
Member

johlju commented May 25, 2018

I see that you referenced this issue in commits. You are welcome to send in a PR resolving this! 🙂

@MartinVokurek
Copy link
Contributor Author

MartinVokurek commented May 25, 2018 via email

@johlju johlju added in progress The issue is being actively worked on by someone. and removed help wanted The issue is up for grabs for anyone in the community. labels May 28, 2018
MartinVokurek pushed a commit to MartinVokurek/xBitlocker that referenced this issue May 28, 2018
MartinVokurek pushed a commit to MartinVokurek/xBitlocker that referenced this issue May 28, 2018
MartinVokurek pushed a commit to MartinVokurek/xBitlocker that referenced this issue May 31, 2018
MartinVokurek pushed a commit to MartinVokurek/xBitlocker that referenced this issue May 31, 2018
MartinVokurek pushed a commit to MartinVokurek/xBitlocker that referenced this issue Jun 4, 2018
Fix for issue dsccommunity#11
Readme updates
MartinVokurek pushed a commit to MartinVokurek/xBitlocker that referenced this issue Jun 4, 2018
@johlju johlju closed this as completed in #17 Jun 5, 2018
johlju pushed a commit that referenced this issue Jun 5, 2018
- Fixed issue which caused xBLAutoBitlocker to incorrectly detect Fixed vs Removable volumes (issue #11).
- Fixed issue which made xBLAutoBitlocker unable to encrypt volumes with drive letters assigned (issue #10).
@johlju johlju removed the in progress The issue is being actively worked on by someone. label Jun 5, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug The issue is a bug.
Projects
None yet
Development

No branches or pull requests

2 participants