So unless you have been living under a rock for the past couple of years, you should be aware that Microsoft have a big push on for organisations to shift towards what they call Modern Management of Windows.
Modern Management focuses around the utlitisation of technologies including Azure Active Directory, Intune and Autopilot to allow for provisioning of settings in order to manage both devices and users. Marketing and buzz words aside, what does this mean for administrators who have spent the vast majority of their careers working in active directory environments and who leverage ConfigMgr to manage their estate?
In this series we will both take a high level overview and compare some of the features of a standalone Intune environment versus the traditional on premise environment. Step by step actions are included to help you deploy settings through the console.
As you will probably be aware aware, in the latest build of ConfigMgr (1710) there is now a “Co-Management” feature to allow both Intune and ConfigMgr to manage the device at the same time. This helps to provide a bridge towards a fully modern managed scenario and is something that I am sure will be expanded over the coming releases of ConfigMgr and Intune, to help organisations leverage both environments.
To allow us to compare and contrast the two platforms as separate entities though, in this series we will keep to a standalone scenario.
Lets start with Intune and look at the levels of granular control it provides when compared to traditional Windows management. Intune is by its nature and build an MDM platform, however with the Intune and Windows product teams in Microsoft working ever closer together we will see the reach of Intune extending further and further into the OS.
For those of you who have been in IT for an extended period like myself, you might try to rationalise Intune MDM profiles as group policy in the cloud. This is where a lot of administrators will immediately complain that settings contained within are in no way a match for group policy, so it is important to say at this point that Microsoft doesn’t intend for it to be a direct replacement.
Group policies have been around as we know them today since the days of Windows 2000, and they have continued to become heavier with settings as each version of Windows has arrived. Rather than attempt to convert hundreds of thousands of settings, Microsoft looked at what were the basic level of controls that an admin would like to have on their machines to control as a bare minimum.
Lets start with encryption, here we are of course talking specifically about Windows Encryption, aka BitLocker. BitLocker for many organisations has become the go to / easy solution for rolling out encryption to your estate. Rolling out BitLocker settings here is very straight forward and offers the same granular control that you have with group policy / ConfigMgr in place. In fact some of the settings are provisioned easier through Intune.
One of the main benefits for Windows Professional licensed users will immediately observe is reporting via the console via observing the profiles deployed and assigning compliance policies. In a traditional management scenario BitLocker is managed through MBAM, which is an enterprise licensing feature.
Comparison – ConfigMgr
In a ConfigMgr environment drive encryption reporting can be done for Windows Professional licenses but needs additional software or reporting through the likes of PowerBI reporting (https://msendpointmgr.com/2017/11/14/bitlocker-compliance-reporting-with-powerbi/). For enterprise customers BitLocker can be managed / reported on via MBAM which used to be part of the MDOP suite but is now included in the enterprise license under SA.
Setting Up A Drive Encryption Policy
Here we will run through the process of setting up a policy for BitLocker.
Note: I am assuming that you have already set up a group to deploy the settings to in this instance, have your device(s) enrolled and have the TPM in an enabled state.
- Log onto the Azure management portal
- Click on Intune (if this option isn’t available, then go to More Services and add it as a favourite for later)
- Click on Device configuration
- Click on Profiles
- Click on + Create profile
- Give your profile a name, e.g. “BitLocker Settings”
- Select the Platform as “Windows 10 and later”
- Select the Profile type as “Endpoint Protection”
- Click on Configure and then Windows Encryption in the middle pane. You should now have a screen similar to the one below:
- Configure the required encryption settings for your OS drive and fixed / removable disks where required.
In the below example I am opting to encrypt only the OS drive and back the recovery key up to Azure AD:
- Click OK, OK again and then Create
- Now click on Assignments and assign the profile to a group
- You should now have something similar to the below in the list of profiles:
- Open the company portal on the end user device and click on the cog wheel icon at the bottom left
- Scroll down and click on the Sync button
- You should now be prompted that Encryption is needed, clicking on this will present you with a start encryption screen. Assuming you have no other third party encryption enabled, click both tick-boxes and then click on the Yes button:
- A check will now run for BitLocker prerequisites and you will then be requested to backup the recovery key:
- Select whether you want to encrypt only the used space or the entire drive:
- Select whether you want to use XTS-AES (recommended)
- Click on start encrypting
- Once encrypted you can verify your deployed settings via PowerShell:
BitLocker – Window Professional
At the time of writing this post, those eagle eyed people might notice that the final encryption method used is XTS-AES but the strength is 128 bit and not the 256 bit specified in the policy. If you are using Windows 10 Professional then you should manually set the encryption strength using something similar to the below before encryption:
XTS-AES 256-bit: Reg ADD HKLM\SOFTWARE\Policies\Microsoft\FVE /v EncryptionMethodWithXtsOs /t REG_DWORD /d 7 /f
For more info on BitLocker cipher values visit – https://blogs.technet.microsoft.com/dubaisec/2016/03/04/bitlocker-aes-xts-new-encryption-type/
BitLocker Key Retrieval
Now that you have your devices encrypted, it is a good idea to know where to obtain the recovery key just in case something goes wrong. There are two methods here, first of which is how to retrieve the key from a user’s logged in session.
- Go to Settings
- Click on Access work or school
- Expand the Azure AD account
- You should now be presented with a page similar to the one below
- Scroll down, find the machine and click Get Bitlocker keys
Azure AD Portal
The other method of course is to use the Azure AD portal to retrieve the key.
- Log onto the Azure Portal (https://portal.azure.com)
- Click on Azure Active Directory
- Click on Devices
- Locate and click on the device which you need the recovery key for. Example:
- Click on the copy icon to copy the recovery key to your clipboard
In this post we have explored how to control drive encryption through Intune in a standalone environment. You should now be cable to compare and contrast your experience of deploying BitLocker settings through the traditional method compared to the new modern method that is Intune MDM profiles.
- Traditional Management vs Modern Management – Part 1 – Encryption
- Traditional Management vs Modern Management – Part 2 – Office 365
- Traditional Management vs Modern Management – Part 3 – AAD/Auto MDM Enrollment
- Traditional Management vs Modern Management – Part 4 – Windows AutoPilot
- Traditional Management vs Modern Management – Part 5 – Security