Lock Windows Device

Expected Console Behavior

In Workspace ONE, you have the "Lock" command available in a device's detail view. For MacOS, that lock command will lock out the device entirely and require a code to be input to the device, given from the Workspace ONE console. This effectively will "lock out" a device so it is bricked until that code is input to the device. This is a useful command if a device is lost, stolen, or an employee who possesses the device is terminated. Compare that behavior to Windows, where that "Lock" command effectively locks the screen (Windows Key + L command), and allows the user, if authenticated, to login again. This article aims to recreate the MacOS lock behavior for Windows.

Update 6/7/24:

In addition to the option below of leveraging bitlocker to lock out a user of a device, you can use a Windows change passcode command to also lock out a device. This is possible for non-directory Windows machines (not AD- or Entra ID-joined). The workflow for this is as follows -

Push Windows password profile to manage local user password on machine
Once profile is applied to device and password is compliant, there is an additional action under "More Actions" in the device detail view to "Change Passcode"
When device lock is desired, leverage "Change Passcode" command. Password on the device is changed for the enrollment user, and the new password is only shown to the IT administrator. This can be communicated to the end user in case of forgotten password (and user will be prompted to change password on next login), or not and user will be unable to login.

Details on the Windows password profile can be found here, and information on the "change passcode" option for Windows can be found here.

How Can We Lock Out a Windows Device? (and key considerations)

The way we can prevent a user from logging back into a device is really one of two ways - (1) make their credentials invalid, or (2) trigger a bitlocker lockout. The former is great with a device joined to Azure AD (or on-prem AD with a line of sight to the domain controller). In this article, I am going to go over the latter, as this will work regardless of device/identity setup. But there are some key considerations with this method - (1) the device must be encrypted via bitlocker for this method to work, and (2) the device must be internet connected to receive the command (which would also be a requirement for an enterprise wipe command from an MDM, anyway)

Now that we've gotten the key considerations out of the way, let's discuss how we are going to trigger the bitlocker lockout on the device. We are going to push a script to the device to require bitlocker to have a recovery screen on next boot. Let's walk through the workflow if we want to lock the device entirely -

Push a script to force bitlocker recovery of the device via Workspace ONE UEM and restart device
Device receives script, device restarts automatically
Windows reboots, prompts user for decryption key to enter Windows OS
User's SSO account (or UEM account) is disabled, which would prevent the end user from accessing the self-service portal and the bitlocker decryption key
1. Important note here - if accounts are SAML JIT-provisioned, the account can stay active in the UEM console while being disabled in the IdP. When a user attempts to sign into the self-service portal, the user will be unable to authenticate with the IdP, and thus unable to access the SP (WS1 UEM Self-Service Portal).

Now that we've walked through how we'll accomplish this, let's set this up in Workspace ONE UEM and test it out on a machine.

🚨Before we begin, even though the below works for me in my environment and my testing, I advise this be tested isolated to one or two virtual machines, in a UAT or non-production environment, before rolling this out in production. This is to ensure that there are no adverse effects, and devices are left in a state that you desire. Note this is a fairly severe action to take, and can result in data loss on the endpoint. Proceed at your own discretion.

Setup

Prerequisite: that you have a Windows encryption profile created and assigned to all applicable devices in WS1 UEM at the top-level OG (or at least a parent OG to the child OG we create below). This will also ensure that encryption keys are escrowed in the console automatically.

First what we want to do is create a sub-og to use for "locked" Windows devices. Login to your Workspace ONE UEM console and go to Groups & Settings - Groups - Organizational Groups - Details - Create Child Organizational Group. Give it a name, set the type to be container, and click save.

2. Next, go to Resources - Scripts. Add a Windows script.

3. Give it a name and description, such as the below.

4. Next, enter the following for the script:

Language: PowerShell
Execution Context & Privileges: System Context
Execution Architecture: Auto
Timeout: 30

Code:

manage-bde -forcerecovery C:

Restart-computer -Force

Note: in the script I am hard-coding a bitlocker recovery on C:\. This can be coded in as a variable instead, though in my environment it's a safe bet that the OS drive is C:

5. Click next, and then click Save (there will be no variables to enter). Next we will need to assign the script.

6. Give the assignment a name, and assign it to the OG that we created earlier. Then click Next.

7. For the deployment trigger, check "Run Once Immediately" and click "Add". This way, once a device is moved into this OG, it will be triggered to lock once.

8. Now that we have completed set up, let's see what happens when we move a device into the OG that this script is assigned to.

Triggering the Lockout of the Windows device

Important: make sure the encryption key is escrowed in the WS1 UEM console prior to moving the device into the OG the script is assigned to. If the key is not escrowed, data from the device may be lost.
Go into the UEM console, find the specific device, and change the OG to the Windows lock OG we created and assigned the script to earlier.

Device Behavior

After pushing the script, the device restarted after a few minutes, and prompts for the bitlocker key. This key is already escrowed in the UEM console as part of the Windows Encryption profile, and the user is unable to recover the bitlocker key since their account is disabled from accessing the self service portal in UEM. This would keep the device in a locked state until the bitlocker key is used from the UEM admin console.

Additional Notes

With Windows, despite the bitlocker lockout, the user is able to boot to a USB drive and boot to an alternate OS to either re-install Windows or still utilize the device. Bitlocker serves to merely protect the corporate data in the main Windows OS install.
In the above article, I mention using the Workspace ONE scripting functionality. This may be possible by also utilizing product provisioning for Windows to push the script. The newer script functionality in WS1 UEM is a little easier to manage than product provisioning, but product provisioning also possesses the ability to push and execute scripts on Windows.
You can also integrate scripts with Freestyle Orchestrator to string together commands, in case there are other actions to sequence in addition to triggering the bitlocker lockout for a potential lost/stolen device
As mentioned above in the article, the device must be internet connected to receive MDM commands (including the ones we are setting up in this article) and this will only work on devices that are encrypted with bitlocker, ideally using the Windows encryption profile
It is always a best practice to test out functionality in a sub-og with isolated devices or a user acceptance testing (UAT) environment where production devices will not be affected by policy changes. It's recommended to pilot this in a UAT environment to ensure device behavior is ideal prior to rolling this out in a production Workspace ONE environment.
In order to query any pending scripts, in a device detail view, go to More Actions - Query - Workflows (see below screenshot)

Page updated

Google Sites

Report abuse