1

Some users in the company require ability to change IP address on network adapters. (Engineering users need to directly connect their laptops to various machines that won't lease out address via DHCP).

We looked at the Network Configurations Operator group as the solution and it kind of works but not the way we need it. Due to restrictions imposed by Cyber Essentials cert requirements we can not add users directly to the NCO group. We can only create a secondary account that is a member of the group and then can be used for elevation in UAC prompt. This has been tested and worked fine on standalone and domain joined machine but when we tried to use it on the Azure AD joined device we ran into a problem. On Azure joined device somehow it is not possible to elevate with the secondary account unless it is admin. Membership of Network Configuration Operators technically should be sufficient to access Network Adapter settings but it is not. I tried running the PS/CMD window as the secondary user and changing IP using netsh command but that complains about permissions as well.

It is still possible to change adapter settings if logged in directly to the secondary account but users are complaining that it takes too long to switch between accounts if they need to change the IP settings more than few times a day.

At this point I am not sure if this is a general thing for Azure joined machines or is one of our default config policies blocking that somehow.

I looked at 3rd party tools like NetSet man that once installed allows user to manage network settings without elevation but it is coming from a small developer and our security dept is concerned about patching, also it did go a bit buggy in testing.

We are potentially looking at whitelisting the action via ThreatLocker but this is still in deployment so may not be an option just now.

Has anyone run into that issue? Ideally I would want to get the secondary NCO account to work for elevation but any other suggestions that meet above restrictions will be appreciated.

Journeyman Geek
  • 133,878
Marcin M
  • 11

1 Answers1

0

Here's an approach I adopt when I want to give users the ability to do something that would normally require privilege elevation:

  • Create a PowerShell script that performs the task.
  • Remove all write access to that script, especially for unprivileged users.
  • As a privileged user, create a scheduled task with an event trigger, triggering on a custom event of your choosing. E.g.:
<QueryList>
  <Query Id="0" Path="Application">
    <Select Path="Application">*[System[Provider[@Name='NetChangeScript'] and (EventID=2)]]</Select>
  </Query>
</QueryList>
  • Set the scheduled task to run your PowerShell script (elevated).
  • Create another PowerShell script that the user can run, which accepts the details of the IP changes and perhaps saves them to a file, read by the first script.
  • At the end of the PowerShell script, trigger the scheduled task. E.g.:
Write-EventLog -LogName Application -Source "NetChangeScript" -EntryType Information -EventID 2 -Message "Changing IP address"

You do have to be careful in your scripts that you don't provide a route for further privilege escalation. Validate all input (including when reading from the file with the new IP address in it). Make sure unprivileged users cannot change anything except that file.

Note that you can pass simple messages to the elevated script by using different event IDs. E.g. event ID 2 might be to change the IP; event IP 1 might be to set to DHCP, etc.

Rob Pomeroy
  • 191