So yet another Bit locker blog post!

So yet another Bit locker blog post!

Bit locker is not a new technology it has been around for many years, and I remember the day of deploying MBAM for enterprises, and fighting with TPM preparation scripts and logic as well as firmware configurations before the technology was really standardized.

Overview of BitLocker Device Encryption in Windows - Windows security | Microsoft Docs

Today most hardware meet HSTI (Hardware Security Test Interface ) which makes deploying enterprise security tools like Bit locker, HVCI (Hardware Virtualization Code Integrity), and other tools very easy to do as most modern hardware are meeting HSTI and we can now deploy there security measures with relative ease.

So here is a go at my baseline configuration I deploy with enterprise customers and why!

So we have two or maybe three options here but one being custom OMA settings, and really that’s painful so the two options are Endpoint Security Policy or Intune Device Policy? There has been quite a bit of discussion which is better, to me Endpoint Security sounds better and looks to roll up better from a reporting perspective, but experience has shown me they are not as reliable. Now this is just my experience so when working with enterprise level deployments I always want to stick to the tried and true it will work method for that I have found Intune Device Policy to be the best choice.

Head over to Devices > Windows > Configuration profiles > + Create Profile

Select > Windows 10 and later > Templates > and select Endpoint protection > and Create

Now naming here could go many ways I typically try to understand how the enterprise works from a deployment perspective, some organizations have a very uniform endpoint security policy across all devices, others have very granular polices based on depts or personas. So sometimes you can lump all endpoint security policies to the same template or build separate templates for each workload.

For the sake of this blog we are going with simply bit locker. Now after I have given this policy a name, I move one and configure Windows Encryption You will see I keep these settings very minimal. For Azure AD join I configure on 4 policies and that is it. The reason for this is because bit locker comes with many pre-configured or default options, one of those being leverage TPM where available and use software KSP if no TPM is available. This is what we want to have the most reliable disk encryption deployment, many admins will see a lot of options and want to configure them simply because they are there, some advice I have learned over 20 yrs. only configure what you NEED nothing more. Windows and many of these  options are designed to take advantage of the most secure method available always go with that to have reliable deployments.

Now for Hybrid join there is more and I will discuss further down!

Encrypt devices: Required

This is simply enable disk encryption, little secret for HSTI devices joining Azure AD join will auto bit locker and escrow key, but this needs to be on for the policy to take effect.

Warning for other disk encryptions: Block

This will prevent windows from prompting the end user a nagging message to say they do not have 3rd part disk encryption obviously this is what we want, but if your enterprise has 3rd party Disk Encryption probably best to leave this on or use some logic to prevent a software encryption over your software encryption.

Allow standard users to enable encryption during Azure AD Join: Allow

This is critical if you are deploying AADJ devices with standard user profiles, easy to set and necessary.

Configure encryption methods: Enable

I checked this only because AES-XTS 128 is the windows standard, but many enterprises want 256bit because that’s what most standards recommend this is no big deal as you can set it here, but keep in mind if the machine was already encrypted with AES-XTS 128 you have to decrypt and Re-Encrypt before you can be complaint at 256bit. For me the difference between the two is irrelevant because brute force hacking is the difference a few thousand years that it will be a social engineered hack before brute anyway.

128 vs 256-bit SSL Encryption - What are Differences? (cheapsslshop.com)

Select Next > Assign to your group > and Deploy.. Checking your local devices

Because everything is more complicated with Hybrid Join, I configure the below, rely defining the additional auth at startup only so I can specify escrow my key to Azure AD, without this windows will try and escrow to AD and typically fail

Troubleshooting:

So troubleshooting is for bit locker in my opinions has gotten pretty strait forward, if the policy has landed event viewer has pretty much everything you need to understand what's going wrong or right if you want to validate your deployment. There are slew of other TPM related troubleshooting but I'll be honest we don’t see to many TPM issues any more in the Windows 10 world but if it happens this article covers that.

Guidelines for troubleshooting BitLocker - Windows security | Microsoft Docs

After I deploy my policy I got to event viewer to look to make sure Event 796 & 845 kick off to make sure bit locker kicked off and my key is backed up.

  • Event ID: 796 Looking to see bit locker policy take effect

  • Event ID: 845 Bit locker Key has been escrowed to Azure AD

Autopilot Profile Azure AD Join According to Me!

Autopilot Profile Azure AD Join According to Me!

So We Are Still Talking DNS Suffix for Azure AD Join Devices

So We Are Still Talking DNS Suffix for Azure AD Join Devices