Privilege Elevation for Windows
Table of Contents
Overview
Privilege elevation with Windows is the concept that we aren't granting the end user of the device full administrative rights to the machine. We can dynamically grant, and remove, administrative rights depending on application path, application hash, and other criteria. There are two methods that this can be accomplished that I will cover here - through the integration between DEM and Workspace ONE, and with scripts/sensors in Workspace ONE.
DEM Integration with Workspace ONE
DEM is typically a tool associated with Horizon that captures user profile information and applies policy to (generally) non-persistent VDI. Within DEM, there is an option to configure privilege elevation that we can leverage for Workspace ONE-managed endpoints. We can use criteria such as argument, path, hash, publisher, or task to depict what application needs to have privilege elevation. This is really powerful and more closely matches what Intune offers as a competitive feature (though no right-click menu required for DEM, it will automatically pick out applications based on specified criteria). Though use of DEM requires (at time of writing) licensing for Workspace ONE Enterprise, or other licensing for Horizon.
Scripts/Sensors (without using DEM)
If you do not currently use Horizon, or do not have a Workspace ONE Enterprise license, we can use various scripts to add or remove the enrollment user from the local administrators group, and use a sensor to monitor that. With that information, we can also create intelligence workflows to check sensor data every day and automatically remove any user from the administrators group if they haven't done so already. The implementation of this can be customized to what you think is best - this is just what I've come up with in my lab environment.
Setup: DEM Integration with Workspace ONE
Just to reiterate the above point, before pursuing this option, please ensure that you are licensed to use Dynamic Environment Manager (DEM) Enterprise.
Go to this link to download DEM enterprise. Download both the installer and the license file.
Extract the zip folder and install DEM onto your device. For your device (the IT admin device, not the managed endpoint), make sure that you install the management console.
3. Finish installing DEM. Then launch the management console. (Note: in the start menu, it'll be under a VMware DEM folder, then the application is called Management Console)
4. Go to the star icon in the top right corner. Click License. Then import the .lic file downloaded from customer connect.
5. Next, go back to the star icon and click "Import NoAD.XML". In the zip folder that was downloaded to install DEM, there should be a file under the directory (name of unzipped install folder)\Agent Configuration Examples\FlexRepository\NoAD\NoAD Workspace ONE UEM Sample.xml
Tip: to make sure this is the correct file, open the xml file and make sure the ProfileArchivePath location starts with %APPDATA% and not \\FileSrv\. Horizon relies on a file share for DEM configuration, but Workspace ONE will place this file on the device through a Windows profile.
6. Back in the DEM console, go to configure, go to the integration tab, and ensure that Workspace ONE UEM Integration is checked.
7. Next, go to the "User Environment" tab in DEM. Click Global Configuration. Check the box to Activate Privilege Elevation and any additional desired options.
8. Next, when you go to the Privilege Elevation option, it should show as active and you should be able to click the create button to create your policies. Specify what process(es) or application(s) you want to launch with privilege elevation. Once all of them are added, we can continue to export this configuration.
Note: in my example, CMD is an application I am using as part of privilege elevation. Be smart in what applications you specify the user can gain admin rights to. Ideally you'd want to specify a particular application that needs admin rights instead of CMD which is a little bit of a blank check, so to speak.
9. Once completed, go to the star in the top right corner of DEM and select Save As. This will output a .DEMConfig file that we will (later) import into Workspace ONE UEM.
10. In the Workspace ONE UEM console, under Resources - Apps - Native, click Add - Add Application. Upload the .msi installer for DEM (the same one we used to install the management console on our device earlier. Default install behavior is to not install management console, so no worries on endpoints). In my case, I uploaded the x64 installer, so I will specify that as part of the metadata in the UEM console.
11. Under the "Deployment Options" tab, scroll down and find the Install Command field. At the very end, append the following: INTEGRATION_ENABLED=1
12. Now click Save and Assign. Assign to the appropriate devices in your environment. This is the agent that will apply the DEM policy config that we will upload in the UEM console in the next step.
13. In the UEM console, go to Resources - Profiles & Baselines - Profiles - Add. Select Windows for platform, and select a device-based profile. Give the profile a name and a smart group assignment. Then scroll down to the Dynamic Environment Manager payload type, and upload the .DEMConfig file that we had exported from the DEM console earlier. Then click Save and Publish.
Done! Once the DEM application and the profile land on the device, the policy should be in effect. If you created a message as part of enabling privilege elevation, it should show when trying to launch the application. Any subsequent updates to the policy would need to be done in the DEM console, where you'd re-export the .DEMConfig file, and revise the profile in UEM to upload the new version.
Setup: Scripts/Sensors (Without DEM)
Callouts:
This has been tested for a Windows 10 VM joined to an on-premise domain. This has not been tested on a machine not joined to a domain.
The scripts below are based on and modified from EUC Sample here that removes the enrollment user from the Administrators group.
Once the user has been added to the administrators group, they can use their credentials on a UAC prompt to successfully authenticate. However, when a user is removed from the administrators group, (in my testing) they still receive a simple Yes-No prompt for user account control. This would allow the user to continue operating in an elevated context. Thus, it is a good idea to add a line to the Remove Admin script to sign the user out / reboot the machine (using something like Restart-Computer).
Add Scripts to Workspace ONE UEM
In order for this to work, we'll need to add a couple scripts to Workspace ONE UEM (under Resources - Scripts). For each, create the script using the below samples and assign to devices as necessary.
Add to Local Admins:
Language: Powershell
Execution Context: System
Execution Architecture: Auto
Timeout: 30
#Getting UPN from MDM Enrollment
$enrolid = (Get-ItemProperty -Path "HKLM:SOFTWARE\Microsoft\Provisioning\OMADM\Accounts\*" -ErrorAction SilentlyContinue).PSChildname
#loops through in case of more than one GUID on the system
foreach ($row in $enrolid) {
$PATH2 = "HKLM:\SOFTWARE\Microsoft\Enrollments\$row"
$upn = (Get-ItemProperty -Path $PATH2 -ErrorAction SilentlyContinue).UPN
$SID = (Get-ItemProperty -Path $PATH2 -ErrorAction SilentlyContinue).SID
}
$process = Invoke-Command -ScriptBlock {cmd.exe /c "net localgroup Administrators $upn /add"}
if($process -eq "The command completed successfully.") {
exit 0
} else {
exit 1
}
Remove from Local Admins:
Language: Powershell
Execution Context: System
Execution Architecture: Auto
Timeout: 30
#Getting UPN from MDM Enrollment
$enrolid = (Get-ItemProperty -Path "HKLM:SOFTWARE\Microsoft\Provisioning\OMADM\Accounts\*" -ErrorAction SilentlyContinue).PSChildname
#loops through in case of more than one GUID on the system
foreach ($row in $enrolid) {
$PATH2 = "HKLM:\SOFTWARE\Microsoft\Enrollments\$row"
$upn = (Get-ItemProperty -Path $PATH2 -ErrorAction SilentlyContinue).UPN
$SID = (Get-ItemProperty -Path $PATH2 -ErrorAction SilentlyContinue).SID
}
$process = Invoke-Command -ScriptBlock {cmd.exe /c "net localgroup Administrators $upn /delete"}
if($process -eq "The command completed successfully.") {
exit 0
} else {
exit 1
}
In my example, for both scripts, I added both to the app catalog so the user can self-service request admin rights or remove themselves from the administrators group.
Add Sensor to Workspace ONE UEM to Monitor Admininstrator Group Membership
You can also use something like a sensor to determine whether the enrollment. I came up with the below to determine whether the UPN of the enrollment user (borrowed from the above script) is a member of the Administrators group. Ensure to assign out sensors as well once created.
isadmin:
Language: Powershell
Execution Context: System
Execution Architecture: Auto
Response Data Type: String
#Getting UPN from MDM Enrollment
$enrolid = (Get-ItemProperty -Path "HKLM:SOFTWARE\Microsoft\Provisioning\OMADM\Accounts\*" -ErrorAction SilentlyContinue).PSChildname
#loops through in case of more than one GUID on the system
foreach ($row in $enrolid) {
$PATH2 = "HKLM:\SOFTWARE\Microsoft\Enrollments\$row"
$upn = (Get-ItemProperty -Path $PATH2 -ErrorAction SilentlyContinue).UPN
$name = (Get-ItemProperty -Path $PATH2 -ErrorAction SilentlyContinue).Name
$SID = (Get-ItemProperty -Path $PATH2 -ErrorAction SilentlyContinue).SID
}
$WindowsIdentity = New-Object System.Security.Principal.WindowsIdentity $UPN
$WindowsPrincipal = New-Object System.Security.Principal.WindowsPrincipal $WindowsIdentity
Write-Output $WindowsPrincipal.IsInRole([System.Security.Principal.WindowsBuiltInRole]::Administrator)
This sensor will output True or False depending on if the enrollment user is a part of the Administrators group. We can use this as part of a workflow to monitor and take action if the user remains an admin on their device.
Create Freestyle Workflow To Automatically Demote Users at a Specified Time
You can then create a freestyle workflow so that if the above sensor results in True, that the workflow executes to remove the user from the administrators group, and have this workflow run on a schedule. Note: I am going to use an Intelligence Workflow to do this so that I can schedule this to run. You can also do this with Freestyle Orchestrator within Workspace ONE UEM, but that workflow will run automatically.
Conclusion
Both methods discussed above are a way to control a user's administrative actions on a Windows endpoint without granting them unfettered administrative rights. The former option, with DEM, is ideal as you can limit this to a specific process or application. Though this requires licensing for Dynamic Environment Manager. If you find yourself in a situation without such licensing, you can use scripts and sensors to automate adding and removing the enrollment user from the Administrators group. This way you can employ some sort of control (and reporting!) over who has administrative rights on their machine. The latter method, without DEM, is particularly flexible in terms of implementation, due to its use of scripts and sensors, so you are able to tailor it to your organization's needs.