This post has been republished via RSS; it originally appeared at: Core Infrastructure and Security Blog articles.

Hi Jason Cody here!

I would like to talk about using Intune policies with Microsoft Entra ID Governance as part of the offboarding process. Using the method below you can rapidly offboard an employee/contractor while preserving device data, Entra ID join status, and Intune enrollment. This could be used for multi-user endpoints or in events where forensics may be necessary for the device.

In the past, quickly offboarding users while preserving data on the devices was fairly easy.  As soon as the decision was made to offboard an employee\contractor they would lose physical access to their equipment and to the facility, their account would be disabled, and typically a security personnel would also ensure they do not leave with any critical company assets in the process.

With the rise in remote work, it is not uncommon for employees or contractors to not only work remotely, but to work in a different geographical location as their company’s office. Requesting the user to travel onsite to the office so that they can be offboarded is impractical and not realistic.

At the same time the nature of today’s authentication\authorization protocols does not allow for rapid offboarding of remote users.  Depending on the protocol and application, a user can continue to access\modify data for an hour or more after their account was disabled.  When it comes to Windows Client, the user can potentially login forever using cached credentials.

While remotely wiping of the device is typically the route we take with these scenarios. Sometimes we need to preserve the data on the device for investigative or legal purposes. In those cases, we need an alternative. One way of addressing this is to revoke logon permissions after the organization has decided to offboard them. This will give the best opportunity to preserve the integrity of data on the device should it be required for investigative or legal purposes.

Things you need to create this workflow

• Intune Licenses
• Permissions to create Intune polices and Entra ID Security Groups
• Windows 10 or higher
  • Entra ID joined or Hybrid Entra ID joined
  • Intune managed or Co-Managed
  • Internet connection
• (optional) Entra ID Governance License for Automation

How it will work

We are going to take advantage of Windows Security User Rights assignments to lock the user out of Windows Client device:

• Deny Local Logon
• Deny Remote Logon
• Deny Remote Desktop Logon

Once prerequires are configured in Intune and Microsoft Entra Id. The overall process will require two steps and can be automated with Logic App, Azure Automation, or PowerShell script.

• Add user to a group that will enforce Deny Device access Intune policy.
• Send a restart command to the users of Windows Client to apply the new policy.

After the restart is complete, the user will no longer be able to login to Windows Client nor access any organizations data on that device. Please note that the device must be online to be aware of the users group membership change.

Please note that the device needs to have internet access for this to work. If the user intentionally keeps the device offline they would be able to continue logging in using cached credentials indefinitely.

Intune steps required to implement authentication restrictions

First, we will create a group that the revoked accounts will be added to, to apply the policies. For this example, we will name this group “Logon Restriction User” and it will be an Assigned Entra ID security group. ¹ Do not populate members into this group yet.

Note: These steps are for Entra ID Joined devices. For Hybrid Entra ID Joined devices a separate configuration using Group Policy Objects will need to be created.

If you want to test this on a subset of devices, then you should also create a device security group for assigning the policies at this time.

Next, In the Intune portal we will go to Device -> Configuration Profile and create a new Settings Catalog Configuration Profile to define User Rights on the target device group. In this policy we will be denying log on and remote access to the local Guest security group.² Assign this policy to a test device group.

Finally, we will create a Local User Group membership configuration. In Intune -> Endpoint Security -> Account Protection create a new Account Protection (preview) policy. In this policy we will be adding the “Logon Restrictive Users” user group to the local Guest security group membership.³ Assign this policy to the test device group used in the prior step.

Validate settings are applied.

1. In local group membership you will see the GUID of the Entra ID Security Group in the local Guest group members

2. In SecPol.msc we will see

Now we are ready to test the policy. Add the test account that will be restricted to the assigned members of the security group and restart the user’s device. In this example, my foster dog Koa was adopted and so they left my house and should no longer have access to their laptop. Cookie however also uses this device and their account is unaffected.

Additional Details

For restarting the device the easiest way to do this is from the Intune portal using device actions. However, I prefer using Graph API to do this by referencing the users known managedDeviceId. Unfortunately, targeting the members of the “Logon Restrictive Users” security group with a script won’t work quickly enough for this. Newly assigned Intune script assignments are not recognized until after the Intune Management Extension service is restarted either manually or via machine reboot.

If you do want to deploy a reboot script, which would be recommended, I would use something like this to clear the cached credentials prior to rebooting. Clearing the cached credentials is not required for group membership changes to be processed so long as the device is online at the time of logon. However, clearing the cached logon is recommended so that the user cannot continue using the device in an offline state. Please note that the device needs to be online long enough to receive these commands.⁴

Warning: Clearing cached credentials in this method will affect all users of the device, not just the targeted user!

To revert the restriction, you will need to remove the user from the “Logon Restrictive Users” security group and temporarily remove the computer from the Endpoint Security Account Protection policy for Local User Group membership policy. Once this policy is removed the user will be able to log in again and the policy can be re-applied. If your processes are well defined, then hopefully you will rarely need to revert this restriction.

Caveats

This method of restricting user logon is considered best effort. When dealing with remote users and devices there are numerous actions a user could take to prevent these controls from taking effect and we cannot always physically prevent the user from taking these actions. The goal with this method is to ensure the user is requesting a new PRT at device logon that contains the group membership change adding them to the local Guest group.

Note¹: It would be recommended to use a Microsoft Entra ID group over an on-premises group, because 1) it would allow for any additional automation task we might implement in Flow in the future, and 2) because when you are working with cloud-based policy it is best practice to use cloud-based groups.

Note²: If you already have policies defining User Rights, make sure you are not creating a policy conflict by applying both policies to the target device.

Note³: If you already have policies defining Local Group Membership, make sure you are not creating a policy conflict by applying both policies to the target device.

Note⁴: This will clear all cached credentials on the device, it is not specific to an individual user so use with caution.

Disclaimer

The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.