Configuring Entra ID Device settings

The first settings we need to look at are the Device settings. This is where we can configure what users can and cannot do with their devices. This includes setting who can enroll devices into Intune and Entra ID, as well as the security around it.

How to do it…

While the vast majority of our device settings will be configured within Intune, there are a few within Entra ID that are worth setting up before we move into the Intune configuration.

Following these steps will configure your Entra environment for device enrollment:

1. First, within Entra ID, expand Devices, click Overview, and then click Device Settings.
2. We need to ensure Users may join devices to Microsoft Entra is set to either All or Selected as we need our machines to be Entra ID joined. We can restrict device types later within Intune, so it is best just to leave this one set to All.

   Regarding Multi-factor authentication, leave this set to No and use Conditional Access as recommended. This will give you much more granular control and reporting.

   The maximum number of devices is something to note here. It is also a setting within Intune, so there are two places where you can check if users have issues enrolling devices. The Entra ID setting here is for all registered devices, so it will include any personally enrolled devices that are not Intune joined. It is also worth noting that this will include any previous devices as Entra ID does not automatically clean stale devices (although this can be scripted; see the following Automating it section).

   Unless you have a large number of devices per user, leave this set to 50 devices per user.

   You can ignore the blue text link, as we configured that with the Entra ID roles earlier.

   The final setting here (Restrict non-admin users from recovering the BitLocker key(s) for their owned devices (preview)) lets your end users retrieve their own BitLocker keys (after authenticating). This is a personal preference; changing it to Yes would result in additional support calls in the event of a power cut or other events that could trigger BitLocker. For this example, we are leaving it set to No.

3. Once you have configured the settings, click Save.

This recipe has allowed our tenant to accept Intune device enrollment.

Automating it

Again, we can use PowerShell to automate this configuration to make it more easily repeatable:

1. Set some variables and change them so that they match your environment:

   $devicequota = 50
   ##Set to 0 to block Entra ID Registration
   $azureadregister = 1
   ##Set to 0 to block Entra ID Join
   $azureadjoin = 1
   ##Set to 1 to require MFA
   $mfa = 0
   ##Set to False to block BitLocker
   $bitlocker = "true"

   While this is displaced on one screen in the GUI, these are two separate policies, so we need to create the JSON for the non-BitLocker settings. This JSON will include some nested arrays, as each section of the page is an array in itself.

2. These settings are all configured with defaults from the initial tenant configuration, so if you need to check the raw JSON values, run a GET request against this URL: https://graph.microsoft.com/beta/policies/authorizationPolicy/authorizationPolicy.
3. We are simply manipulating the retrieved values to receive our new values. You can copy and paste this script block as we set our values in Step 1:

   $jsonsettings = @"
   {
   "@odata.context":"https://graph.microsoft.com/beta/$metadata#policies/deviceRegistrationPolicy/$entity",
   "multiFactorAuthConfiguration":"$mfa",
   "id":"deviceRegistrationPolicy",
   "displayName":"Device Registration Policy",
   "description":"Tenant-wide policy that manages intial 
   provisioning controls using quota restrictions, additional 
   authentication and authorization checks",
   "userDeviceQuota":$devicequota,
   "azureADRegistration":{
   "appliesTo":"$azureadregister","allowedUsers":null,
   "allowedGroups":null,"isAdminConfigurable":false
   },
   "azureADJoin":{
   "appliesTo":"$azureadjoin","allowedUsers":[],"allowedGroups":[],
   "isAdminConfigurable":true
   }
   }
   "@

4. Then, we manipulate the BitLocker settings:

   $jsonbitlocker = @"
   {"defaultUserRolePermissions":
   {"allowedToReadBitlockerKeysForOwnedDevice":$bitlocker}}
   "@

5. Now, set the URLs for each setting we are changing:

   $registrationuri = "https://graph.microsoft.com/beta/policies/deviceRegistrationPolicy"
   $bitlockeruri = "https://graph.microsoft.com/beta/policies/authorizationPolicy/authorizationPolicy"

6. For deviceRegistrationPolicy, we need to send a PUT request:

   Invoke-MgGraphRequest -Method PUT -Uri $registrationuri -Body $jsonsettings -ContentType "application/json"

7. For the BitLocker policy, we must send a PATCH request as we are amending existing settings:

   Invoke-MgGraphRequest -Method PATCH -Uri $bitlockeruri -Body $jsonbitlocker -ContentType "application/json"

These steps have configured our tenant to allow enrollment and let users view their BitLocker keys.

As we mentioned earlier, clearing out stale devices requires a script, so we will run through that quickly as well:

1. For this, we need a different module:

   Install-Module -Name Microsoft.Graph.Identity.DirectoryManagement -Repository PSGallery -Force -Scope CurrentUser
   import-module Microsoft.Graph.Identity.DirectoryManagement

2. Set the necessary variables:

   $daystodisable = 90
   $daystoremove = 120

   Now, we will disable anything over 90 days (or whatever the variable is set to). It is always best to do something slightly less drastic initially.

3. After setting the date we are looking for, loop through the devices and find any that have not been seen in that time, then disable them.
4. We are using the Get-MgDevice module here to retrieve all devices from Entra ID. This is the same as running a GET request against this URL: https://graph.microsoft.com/beta/devices.

   We are adding -All to get everything and not restrict with pagination and then filtering on devices that have not logged on in the last 90 days.

   For each of the devices we find, we are calling the Update-MgDevice command, which is the same as running a POST/PATCH request against the same URL. However, rather than having to retrieve, manipulate, and then upload the JSON, this module takes inline parameters to do the hard work for us:

   $dt = (Get-Date).AddDays(-$daystodisable)
   $Devices = Get-MgDevice -All | Where-Object {$_.ApproximateLastLogonTimeStamp -le $dt}
   foreach ($Device in $Devices) {
       $deviceid = $Device.Id
       Update-MgDevice -DeviceId $deviceid -AccountEnabled $false
   }

5. Then, do the same retrieval, but look for anything older than our delete date, which is also disabled (this will stop us from deleting something we had to re-enable previously but still has not been seen for whatever reason). For these devices, remove them using Remove-MgDevice. This is the same as running a DELETE command against the Devices/DeviceID section of Graph:

   $dt = (Get-Date).AddDays(-$daystoremove)
   $Devices = Get-MgDevice -All | Where-Object {($_.ApproximateLastLogonTimeStamp -le $dt) -and ($_.AccountEnabled -eq $false)}
   foreach ($Device in $Devices) {
       $deviceid = $Device.Id
       Remove-MgDevice -DeviceId $deviceid
   }

This script has configured your tenant to allow enrollment and configured key device settings.