This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
I can not seem to figure out what is required to get Intune Bitlocker to prompt a user (even as admin) for a password. I have read all the docs repeatedly and I feel I'm just missing something.
What do I need to get Bitlocker to work as documented?
Right now it seems my policy enables bitlocker but never prompts.
As admin I can set a pin.
I'm lost with Bitlocker it seems overly simplified in documentation and then nothing works in practice.
Intune has no ability to do this. Today, you need to use a supplemental method, like a script, to prompt an end-user for a PIN (aka preboot authentication password) to set. This script will need to be run elevated as well as this does require local admin privileges to set (or reset).
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(86.4, 66%, 18%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ENH%3C/text%3E%3C/svg%3E)
In addition to Jason's comment, here is a good blog post that has a workaround where you can use TPM startup and then deploy an app to get the user to set a Bitlocker PIN. https://oliverkieselbach.com/2019/08/02/how-to-enable-pre-boot-bitlocker-startup-pin-on-windows-with-intune/
Yeah I had started reading the link mentioned above.
I'm not really used to administrating bitlocker. Do most people use the startup password? Does it seem like a bad idea to encrypt with an end user password?
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(108.80000000000001, 77%, 20%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EM%3C/text%3E%3C/svg%3E)
It needs to be emphasized that a password protectors is fundamentally different from using TPM+PIN.
The PIN in conjunction with the TPM is only enabling the holder to start the device, nothing else.
The password however gives the holder full control over the device. He may manipulate it, decrypt it, whatever.
Don't use the password. Furthermore, attackers are able to brute-force passwords, whereas PINs cannot be brute-forced, since the TPM locks out after only 32 tries.
I wrote an article about (among other things) how to setup a random PIN automatically and display it to the end user: https://www.experts-exchange.com/articles/33771/We-have-bitlocker-so-we-need-MBAM-too.html?preview=hG26jVC1xow%3D
Don't use the password. Furthermore, attackers are able to brute-force passwords,
This is not a good statement to make as comparing recovery passwords to pre-boot authenticators (aka PINs) to not valid. You called this out in your first sentence so not sure you are later trying to compare them. BitLocker always has a recovery password, Whether the user has access or possession of that recovery password is a different question. In general, it is non-standard for users to have possession of the recovery password in an enterprise environment as this is only needed in the event there is a BitLocker recovery event (which should be rare). However, PINs are something the user should possess If you enable them) as these are needed every time the system is powered on.
As for brute forcing a recovery password, good luck with that. It's a random, 48-character password.
Hello Jason.
I don't think the author is talking about the numerical 48-digit recovery password. I see no indication of that, so my warning is about passwords, as in the password protector one may choose to setup if no TPM is available. As he calls it "end user password" I am pretty sure he means something the end user sets himself, but @ComputerHabit should tell us.
No, breaking a recovery password is not done by brute force,
Side note on your "BitLocker always has a recovery password" - no. You may choose not to set one which is usually done in environments that try to stay FIPS compliant, see https://learn.microsoft.com/en-us/troubleshoot/windows-client/windows-security/bitlocker-recovery-password-not-fips-compliant
I'm looking to use a Startup Pin. It was pointed out that startup pins could prevent things like multiple reboots during software installations and upgrades. This got me thinking about how if I do need to run an upgrade for a user that is remote I would have to decrypt first.
Initially I was thinking my Workstation admins would just build systems and encrypt and transmit the pin to users. But then if I do upgrade an OS and they're in the field they'd have to put the pin back or send the system back to helpdesk just to set the pin. This setup I'm doing is for users who do not have a centralized office and who will mostly be remote or working from home. Lots of travel.
I don't want my end users having Admin access of course and that seems to be the main criteria to set the startup pin. So the app mentioned is probably the way to go.
Doing all this though makes me think that a Silent setup of Bitlocker might be great. But am I less secure because of this. I could use a Power On Password from BIOS but that might become pretty hard to maintain a password list and if we keep them the same then employees leaving know the password.
"if I do upgrade an OS and they're in the field they'd have to put the pin back or send the system back to helpdesk just to set the pin"
A bitlocked system is upgradable and the PIN is kept. When you start an OS feature upgrade, Bitlocker is suspended automatically.
That said, I am not sure I understand what you are afraid of.
Not afraid. Just ignorant. :)
I'm just trying to ensure I have thought this all the way through.
Also it has not been exactly easy to find out all the caveats to using Bitlocker and the setup for Administration. So far inhouse MBAM is a pain and the documentation leaves way to much open to guess.
Intune is turning out to be much like that as well. It's not well documented WHAT you should do if you want a certain outcome. It would be nice if Microsoft posted solutions instead of vague documents.
It took me much time to find out that there 'could' be caveats to setting certain Bitlocker policies. I don't even know if they are true or not because i get mixed results with policies already.
True on enabling FIPS, but that's not common at all and folks choose not to enable it for that sole reason and not because it is truly something you can brute force crack. Not having a recovery password makes life much more difficult on everyone when a recovery is needed.
I agree that the OP did not ask about or mention the recovery password, my response was to your comment which did mention it and you made a statement, "Don't use the password." that is not a good recommendation. What the OP is asking about is the preboot authenticator (aka PIN) which I called out.
As noted, this is why we generally recommend orgs not configure a preboot authenticator unless they truly feel there is a risk to their systems and they've validated that there is a valid attack vector on the TPMs in use on their devices.
There are caveats to every policy you can set and every configuration you make on a system. Exploring all of the options is a good thing, but there's no way to document every possibility. If you have specific feedback or questions, please post them here or on the docs pages. The doc author can coordinate updates as can I.
Have you seen this five-part blog series that we put together: https://techcommunity.microsoft.com/t5/intune-customer-success/enabling-bitlocker-with-microsoft-endpoint-manager-microsoft/ba-p/2149784? I don't think this left much, if anything, out.
There's also a wealth of community resources in general.
"I agree that the OP did not ask about or mention the recovery password, my response was to your comment which did mention it and you made a statement, "Don't use the password.""
@ComputerHabit
So you hope to allow your users to set a PIN. Why wouldn't you just set one randomly and tell them, like my script does? It can be deployed.
OK, fair. I think we are on the same page here and this is an example of where ambiguity in common use terms is problematic at best. In the context of BitLocker, "password" almost always refers to a recovery password -- this has probably lead to some of the OP's confusion.
I completely agree that using BitLocker without a TPM is just never a good idea and should in general only be used in a testing environment.
As for the preboot authenticator, why use one at all?
Why use PBA? Not only does the encryption key enter RAM without PBA and can be extracted by attackers, but also the windows logon mask proved to be circumventable in the past.
From when AD came up (Win2k server) to late 2015, any attacker that got hold of a machine that booted to the logon prompt could simply fake a domain controller. It was hilarious, what terrible negligence. And that would not have been possible with PBA.
Refer to https://www.blackhat.com/docs/eu-15/materials/eu-15-Haken-Bypassing-Local-Windows-Authentication-To-Defeat-Full-Disk-Encryption-wp.pdf
(Attention: don't let the title mislead you, all domain joined computers are affected, not only bitlocked ones)
After you read that, would you ever again trust the windows logon mask alone? I wouldn't.
Not here to debate the strength of security controls in Windows although the attack vector described in that article is super old and well mitigated. It's also another reason to start using AADJ and WHfB instead of using on-prem domains for Windows endpoints.
As for physically extracting the encryption key from RAM, as noted, that's super non-trivial and DMA extraction is also mitigatable using a single policy that's been on by default since Win 10 1709 I believe.
Security is always about risk evaluation and mitigation and each org and person can choose to act upon these as they see fit. I suggest you use current info though to base your decisions on though.
No, you are not here to debate. But you asked "why use PBA" and I answered that.
Security is about simplicity.
The logon screen and its mechanisms are complex - the preboot auth is far less complex.
At the logon screen, the device is possibly accessible from the network - at PBA logon, it's definitely not.
At the logon screen, an attacker who stole the device might just plug in an ethernet cable and wait for a device to feature upgrade on its own some day, which will suspend bitlocker - all that has been seen and documented, ready to be abused. Cold boot attacks on RAM are "super non-trivial"? Well, what attacker are you talking of? The man on the street doesn't pull that trick, no. But if you have serious data to protect, you should not allow cold boot attacks since you never know who will get hold of your device and publicly available manuals for CBA exist.
So to me, there is not even room for debate "why use PBA". We have been using PBA for over a decade now and no, it does not bother people. Admins are there to mitigate problems that come from PBA usage, but I haven't seen any.
Ok, that's just my opinion, I know.
That's a bit of a loaded question. In general, we try to discourage folks from using a pre-boot authenticator as it prevents systems from rebooting without requiring human intervention. This can be quite undesirable in a number of situations including unattended updates which are common in most environments. There are some attack vectors on TPMs though -- whether these are viable depends on the TPMs your systems use (the attacks are all physical in nature) and whether they are truly a risk is for your org to decide. I'd say in general, most orgs should not consider this a risk, but I don't have any responsibility there so that's possibly easy for me to say. You will find debate on this point.
Note that the pre-boot auth password is not used to encrypt to drive and is not user specific. It's just a hardware level password used to unlock the TPM.
I don't want my end users having Admin access of course and that seems to be the main criteria to set the startup pin. So the app mentioned is probably the way to go.
No, not at all which is exactly why I called out that a preboot authenticator (aka PIN) and recovery password are two completely different things. As I called out in my previous answer, the only thing that the preboot auth does is unlock the TPM so that the encryption key is available to the OS to use to access the encrypted disk volume. The recovery password is used to recovery a BitLocker volume that has been locked for one of a variety of reasons usually related to the detection of tampering with the device or OS. Users do not choose recovery passwords, these are generated randomly by the system and are 48 characters long. You don't keep a list of these, these are escrowed (aka saved with controlled) to an escrow system like MBAM or ConfigMgr (this is truly the main purpose in life for MBAM) or saved to AAD or AD.
The main reason to set up a preboot auth is to mitigate the risk of a physical attack on the TPM that could allow the encryption key to be stolen. As noted, this is a physical level, hardware attack on the TPM itself that greatly depends on the physical design of the TPM and motherboard as how big of risk this type of attack actually is.
Not having a PIN does equate to a lower level of security because of this, but as with all security, you need to evaluate the risk and compare that against other factors to determine whether you truly need it. Thus, I'll say it again here that most orgs do not deem the use of a prebott authenticator necessary as the physical attacks on the TPM are generally non-trivial and not ubiquitous, i.e., attacks vary between different types of TPMs and motherboards and not all TPMs are even susceptible to any known attacks.
I'm only talking about the Startup Pin and not the password for Bitlocker recovery. Details on the templates say you need Admin.
I am concerned about stolen laptops.
Right. That's the entire point of using BitLocker. A preboot authenticator is not required for this. Once again, a preboot authenticator protects against physical attacks on the TPM, most of which are non-trivial and vary (if possible at all) between different TPMs.
Thus, the question here again is do you truly feel these non-trivial attacks are truly a risk? Most orgs do not (and thus do not use a preboot authenticator). Our general guidance is that the burden of a preboot authenticator on the users as well as normal IT processes do not justify its use. This is not a universal recommendation, just our general guidance that most choose.