This blog will be about which kind of problems you could encounter when you are deploying Adminless and of course how to solve them! I will guide you through the whole Adminless process and I will show you how yo can manage your local administrators with Intune / MDM.

When you are migrating to the Modern Workplace you will need to make sure, your end users do not have local admin permissions.  There should really be no discussion, whatsoever.

*Source: Microsoft Vulnerabilities Report 2021 | BeyondTrust (great report!!)

I will divide this blog into 8 sections. The first 5 will show you how to be sure the users are no local admins and the last three parts will be about how to make your users happier…

Let’s begin with the first 5. Okay, so what options do we have to make sure the user is no local admin?

1. Autopilot

When you performed an Azure Ad Join (no autopilot) the user who joins the device is a local admin by default. This reason alone could be a very good reason to restrict enrollment for personal devices and only allow Autopilot.

Autopilot is one of the solutions if you don’t want your first user to be admin, so make sure you configured the “user account type” to “No”.

Of course, using Autopilot is an excellent idea but it does not solve this problem:

If you look carefully, you will notice there are 2 SID’s. These two SIDS are representing the

*Azure Ad global administrator group

*Azure Ad Device administrators

How to manage local administrators on Azure AD joined devices | Microsoft Docs

In my opinion, the old school administrative active directory tiering three-tier model still applies.

Source: Mastering the lions PAW: How to build a privileged access workstation – ppt download (slideplayer.com)

When applying this model, you are making sure no global admin is going to have any permission on the endpoint. I will show you in option 4 how to make sure these two sids are removed.

On the endpoint, you need to make sure only a local workstation admin is added to the local administrator’s group. I guess that’s why it is called a LOCAL administrator group?

But beware, you also need to make sure you have a local admin password solution in place. (LAPS). I hope Microsoft will have its own laps solution soon. But for now, maybe look at these blogs.

When you use Hounddog/GFI//GFIMAX/Logicnow/Maxfocus/Solarwinds I mean N-Able monitoring, this could really be a good option.

2. Restricted Groups

The second option you have is configuring the restricted groups. Restricted Groups can be used to add/remove local administrators on the endpoint itself. When restricted groups are configured it will replace all users inside the local administrator group with the users you configured in the XML.

It’s a great solution for managing the local administrator’s group. But there is a little downside, this configuration is only applied once.

If someone is logged on to the device after the policy is applied and has global admin permissions he or she could add/remove users from the local administrator group. (as shown earlier, users in the global admin group are local admins by default)

If you want the permissions to reapply, you will need to make a change to the device configuration policy.

3.Local Users and groups

This option is definitely not my most favorite one, but you could configure the local administrator’s group by configuring a csp

./Vendor/MSFT/Policy/Config/LocalUsersAndGroups/Configure.

<GroupConfiguration>
    <accessgroup desc = "">
        <group action = ""/> 
            <add member = ""/>
            <remove member = ""/>
    </accessgroup>
</GroupConfiguration>

As shown above…. When you only specify “add member” these users will be added to the local administrator’s group. Existing members are not removed if you don’t specify the removed member properties.

If you want to read some more background information about this option, Ru Campbell created a blog about it:

How to Manage Local Administrators and Groups with Intune – Petri

4. PowerShell Win32App

As shown in the first three options, you will need to make sure the user who enrolls the device is no local admin.  Only making sure the user is no local admin is not enough, you will need to make sure the global admin users ids are removed from the local admin group.

Take a look at one of my first blogs.

The blog speaks for itself, when you are deploying this Win32 app you are always in control of who are members of the local administrator’s group. When you are scheduling this PowerShell script at each logon, you will make sure the permissions are applied each time.

5. Endpoint Security Account Protection

Configuring a Custom Settings Policy could be difficult, luckily you could do pretty much the same by configuring a new Endpoint Security Profile configuration

Looking at the picture above, it does the exact same thing as the CSP but the possibility to add some human errors into it is limited

6.Combining options

Only using Autopilot without any additional configuration is not the best practice. I would recommend using Autopilot and another option. If you would like to stick to supported Microsoft solutions I would recommend option 3 even when Microsoft is advising option 2….

Beware: Don’t combine the local users and groups and the restricted group’s solution.

Of course, I really like the Microsoft Solution but to be honest, we are using Autopilot and the Win32App PowerShell script with our own LAPS.

7. Solutions to let the user think they are local admin.

Now we have seen, how you could make sure users are no local admin anymore we need to take a look at how to increase the user experience. It’s obvious when you are no local admin, there are limitations. Here are some limitations which you can run into.

In my opinion, the possibility to let users install Apps on their own from the company portal is one of the best solutions when you have implemented Adminless.

Change system time: 

Windows 10: The Sands of time – Call4Cloud 

Installing Printers (Drivers) 

Birds of Printer drivers – Call4Cloud 

Installing Software 

Applocker on the Company portal Express – Call4Cloud 

Removing public desktop icons 

Public Desktop icons and Adminless: The far side of Intune – Call4Cloud 

Restarting services 

The non admin user: The battle of restarting services – Call4Cloud 

 8. Changing Network address

One of the biggest concerns we heard, when we are implementing adminless (besides the issues I addressed in the previous chapter) is the possibility to let field engineers change their local IP address.

A lot of customers we are migrating to the modern workplace all have some field engineers whose job is to assist other companies 24×7.

Here is an example:  one of our customers who is specialized in fresh food packaging needs to service the fresh food packaging machines which are placed at their customer. If there is an issue with one of the fresh food packing machines, they need to be able to change their local IP address for their device/laptop. Otherwise, they can not do their job.

You will need to give the user the possibility to change their local IP address to start troubleshooting.  To do so, you will need to add the user to the network configuration operators group.

As I have shown with the PowerShell Win32app to change the local admin group,  you can do the same with the network configuration operators group. (please beware of the dutch translation)

$content = @' 
$loggedonuser = Get-WMIObject -class Win32_ComputerSystem | Select-Object -ExpandProperty username 
Add-LocalGroupMember -Group "Netwerkconfiguratieoperators" -Member $loggedonuser 
'@ 
 
 # create custom folder and write PS script 
$path = $(Join-Path $env:ProgramData CustomScripts) 
if (!(Test-Path $path)) 
{ 
New-Item -Path $path -ItemType Directory -Force -Confirm:$false 
} 
Out-File -FilePath $(Join-Path $env:ProgramData CustomScripts\addtogroup.ps1) -Encoding unicode -Force -InputObject $content -Confirm:$false 
  
# register script as scheduled task 
$Time = New-ScheduledTaskTrigger -AtLogOn 
$User = "SYSTEM" 
$Action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-ex bypass -file `"C:\ProgramData\CustomScripts\addtogroup.ps1`"" 
Register-ScheduledTask -TaskName "AddUserToNetworkOperatorGroup" -Trigger $Time -User $User -Action $Action -Force 

Or use a CSP to do the same but with a big difference that you will need to add the users as members

OMA-URI:
./Device/Vendor/MSFT/Policy/Config/LocalUsersAndGroups/Configure

Value:
<GroupConfiguration>
<accessgroup desc = “Network Configuration Operators”>
<group action = “U”/>
<add member = “S-1-12-1-…”/>
<add member = “S-1-12-1-…”/>
<remove member = “”/>
</accessgroup>
</GroupConfiguration>

Let’s test it out and try to change the local IP address (the old way). When trying to open the network connection properties you will be presented with a UAC prompt.

After entering your own credentials, you can change the IP address. 

Video:

9. Make Me Admin

If you want to skip all other options to provide the user with some additional functionality you could definitely use Make me Admin.

Make Me Admin is a simple, open-source application for Windows that allows standard user accounts to be elevated to administrator-level, on a temporary basis.

Home · pseymour/MakeMeAdmin Wiki · GitHub 

It’s also available on Chocolatey. Go and make some chocolatey right now.

With Make me Admin, they can shift-click on everything and choose to run as administrator. Isn’t that great?

But only using “Make me admin” and relying on the hope it will not be abused by your end users, is also not best practice.  You will need to make sure you forward or monitor the logs.

syslog Configuration · pseymour/MakeMeAdmin Wiki · GitHub

There are also some other policies you could configure. Deploy an Intune PowerShell script to make sure some policies are applied

$registryPath =  "HKLM:\SOFTWARE\POLICIES\Sinclair Community College" 
$registryPath2 =  "HKLM:\SOFTWARE\POLICIES\Sinclair Community College\Make me admin" 
 
$Name = "Admin Rights Timeout" 
$value = "5" 
$Name2 = "Remove Admin Rights On Logout" 
$value2 = "1" 
New-Item -Path $registryPath -Force | Out-Null 
New-Item -Path $registryPath2 -Force | Out-Null 
New-ItemProperty -Path $registryPath2 -Name $name -Value $value -PropertyType DWORD -Force | Out-Null 
New-ItemProperty -Path $registryPath2 -Name $name2 -Value $value2 -PropertyType DWORD -Force | Out-Null 

Conclusion

With all the cards on the table, we need to choose the path we need to take when we want to ease some restrictions when Adminless is implemented.  Some options you have to increase user experience are not to be implemented, right away. They need to be carefully thought of.

Of course, making sure the user can install software should not be a discussion but please make sure MakeMeAdmin is only implemented for the users who really need it and make sure you are monitoring it otherwise you could be this guy!