Network configuration operators group windows 10

My friend, your day has come: https://lists.zx2c4.com/pipermail/wireguard/2020-November/006094.html

I tested this on a Windows 10 Home machine yesterday, and it works (seemingly) great. I needed to get the user on the «Network Configuration Operators» group to get WireGuard working on that machine. Once completed, WireGuard connected, the (limited) user could control it, and they were able to get into our infrastructure from out and about.

BE ADVISED: In the link above, the attachment is part of their open-source mailing list software (or this hero’s email client did it), so «the .reg file» I refer to is simply called attachment.bin at that link. Download that, and rename it nco.reg.

Essentially, it seems to make use of SysInternals’ psexec.exe to run regedit as the Windows «SYSTEM» user, which, by importing the .reg file from above, allows you to create the «Network Configuration Operators» group on Windows 10 Home (File > Import > nco.reg). I didn’t just install some random .reg file on the internet willy nilly — I did inspect it personally with a text editor, and I threw it up against VirusTotal (here).

That group does not exist on Windows 10 Home to begin with — your instincts are correct (try a running net localgroup on an administrative command prompt — you won’t see it in the list of groups on the system).

FAIR WARNING: The user I performed this fix on seemed to be experiencing some problems on her laptop this morning (links not loading on and off the VPN, «out of memory» errors and such) — I have no idea if it’s related, but I don’t think it is. That laptop has just been a bum in the past, and we need to replace it.

In my last post I introduced Steel Run As, a free tool that allows you to give standard users the right to run specific programs that require administrator privileges. Today I will show you how this utility can be used to allow standard users to change the network settings. This as an example of how end users can change Windows settings with Steel Run As and how you use the tool in batch scripts.

Perhaps it is not a good example because the easiest way to allow standard users to change the network settings is to add them to Network Configuration Operators group. However, this might give them more rights than you want. Furthermore, you can use batch scripts to automatically set specific TCP/IP settings, for example if an user always has to use the same IP in one location. This way, changing the IP can be done with just a mouse click.

The TCP/IP settings have to be configured through the Control Panel applet. That’s why you can’t just tell Steel Run As to run a certain program with administrator rights. But you can write a little batch script that Steel Run As will execute with admin privileges.

On a Windows XP machine this script could look like this:

@echo off
set /P IP=IP address:
set /P Gateway=Gateway IP address:
netsh interface ip set address name=»Local Area Connection» static %IP% 255.255.255.0 %Gateway% 1
set /P DNS=DNS server IP address:
netsh interface ip set dns «Local Area Connection» static %DNS%

You have to replace «Local Area Connection» with the network interface name on the user’s laptop . The name of the wireless interface usually is «Wireless Network Connection.» You can find the appropriate name in the network settings Control Panel applet.

Once you have created the batch file, you can create the Steel Run As executable that will run this batch file with administrator rights. (Note: you better use an account of the Network Configuration Operators group for security reasons; please read the comments to this article.)

Next you have to copy the BAT file and the Steel Run As executable to a folder of the user’s laptop. Launching the Steel Run As executable will open a Command Prompt where the user can enter the IP address, the router address and the DNS server address. You can just remove the set commands and replace the variables with specific settings, if the user needs a certain configuration.

The whole thing is a bit more complicated with Windows Vista. As usual UAC is in our way. The easiest way would be to just disable UAC on the user’s laptop. But since we are security-minded administrators, we have to find another solution.

We have to make sure that the batch script is executed at an elevated UAC privilege level. It is not possible to configure the privilege level for batch files like for binary executables. But we can elevate commands within batch scripts. For this we need the free Script Elevation PowerToys. You can get them from the Technet Magazines June 2008 downloads. Once you have unpacked them, you have to right click on the ElevateCommand.inf and select «install».

This will allow you to use the elevate command in batch scripts:

@echo off
set /P IP=IP address:
set /P Gateway=Gateway IP address:
elevate netsh interface ip set address name=»Local Area Connection» static %IP% 255.255.255.0 %Gateway% 1

The user will have to confirm the corresponding UAC prompt, but there is no administrator credential required. For some reason batch scripts won’t execute lines that come after the elevate command. That’s why we need another batch script for configuring the DNS server:

@echo off
set /P DNS=DNS server IP address:
elevate netsh interface ip set dns «Local Area Connection» static %DNS%

You have to create a Steel Run As executable for each of the two batch scripts. This is not nice. Perhaps you have an idea how to accomplish this task with just one script? I suppose there are ways in a more sophisticated scripting language like PowerShell.

For the sake of completeness, here are the commands that reset the TCP/IP setting to DHCP:

Subscribe to 4sysops newsletter!

elevate netsh interface ip set address «Local Area Connection» dhcp
elevate netsh interface ip set dns «Local Area Connection» dhcp

Last Updated on March 28, 2022 by rudyooms

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
2. Restricted Groups
3. Local Users and Groups
4. PowerShell Win32App
5. Endpoint Security Account Protection
6. Combining them!

When I showed you which options you have to make sure Adminless is implemented, I will show you what problems you can run into and how to solve them.

7. Solutions to make the user happier with the idea he/she is a local admin
8. Changing Network Address
9. MakeMeAdmin

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 CustomScriptsaddtogroup.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:ProgramDataCustomScriptsaddtogroup.ps1`"" 
Register-ScheduledTask -TaskName "AddUserToNetworkOperatorGroup" -Trigger $Time -User $User -Action $Action -Force 

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:SOFTWAREPOLICIESSinclair Community College" 
$registryPath2 =  "HKLM:SOFTWAREPOLICIESSinclair Community CollegeMake 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!

Все нижеописанное относится к Windows 2003, являющейся членом домена Active Directory. Итак, по умолчанию в ней существуют следующие группы безопасности:

1) Administrators (Администраторы) — члены группы обладают полным доступом ко всем ресурсам системы. По умолчанию содержит встроенную учетную запись Administrator.

2) Backup Operators (Операторы архива) — члены этой группы имеют право архивировать и восстанавливать файлы в системе независимо от того, какими правами эти файлы защищены. Backup Operators могут входить в систему и завершать ее работу, но они не имеют права изменять настройки безопасности. По умолчанию пуста.

3) Guests (Гости) — эта группа позволяет выполнить регистрацию пользователя с помощью учетной записи Guest и получить ограниченные права на доступ к ресурсам системы. Члены этой группы могут завершать работу системы. По умолчанию содержит пользователя Guest.

4) Power Users (Опытные пользователи) — члены этой группы могут создавать учетные записи пользователей, но они имеют право модифицировать настройки безопасности только для созданных ими учетных записей. Кроме того, они могут создавать локальные группы и модифицировать состав членов созданных ими групп. То же самое они могут делать с группами Users, Guests и Power Users. По умолчанию пуста.

5) Replicator (Репликатор) — членом группы Replicator должна быть только учетная запись, с помощью которой можно зарегистрироваться в службе репликации контроллера домена. Ее членами не следует делать рабочие учетные записи. По умолчанию пуста.

6) Users (Пользователи) — члены этой группы могут выполнять большинство пользовательских функций. Могут создавать локальные группы и регулировать состав их членов. Они не могут получить доступ к общему каталогу или создать локальный принтер. По умолчанию содержит служебные учетные записи NT AUTHORITYAuthenticated Users (S-1-5-11) и NT AUTHORITYINTERACTIVE (S-1-5-4).

7) Network Configuration Operators (Операторы настройки сети) — группа, члены которой имеют некоторые права по настройке сетевых служб и параметров. По умолчанию пуста.

Remote Desktop Users (Удаленные пользователи рабочего стола) — эта группа содержит имена пользователей, которым разрешен удаленный доступ к рабочему столу.

9) HelpSenicesGroup (Группа служб поддержки) — группа для поддержки справочной службы Help and Support Service. По умолчанию содержит учетную запись SUPPORT_388945aO.

10) Performance Log Users (Пользователи журналов производительности) — члены этой группы могут просматривать журналы производительности. По умолчанию содержит служебную учетную запись NT AUTHORITYNETWORK SERVICE (S-l-5-20).

11) Performance Monitor Users (Пользователи системного монитора) — группа, члены которой могут выполнять мониторинг производительности системы. По умолчанию пуста.

12) Print Operators (Операторы принтеров) — члены этой группы могут администрировать принтеры в домене. По умолчанию пуста.

13) TelnetClients (Клиенты telnet) — группа, члены которой имеют доступ к службе Telnet Server на данном компьютере. По умолчанию пуста.

Default Windows, Безопасность, Шпаргалки