How to empower restricted users to execute defined administrative tasks

As an introduction, I will name some example scenarios that I think are quite common, which would profit from this concept of mine.

Scenario 1: A user-initiated full system image backup/restore
Think of laptop users that are frequent travelers. You might want to image-backup their machines from time to time and providing scripts to do that. However, these scripts need administrative rights, so by default, non-admin users may not run them, nor can you apply a scheduled task, since these frequent travelers are offline most of the time and schedules will be missed or started and then aborted. Instead, you are looking for a way to let the user decide “I am in the office for the next two hours and now is a good time for a backup”.

Scenario 2: Disabling and re-enabling the NIC
Imagine your user is having a connectivity problem and he doesn’t see another way to solve it but to disable and re-enable the NIC. May normal users do that? No, so they would need to restart their machine, which is a rather unpleasant solution for many of us who keep lots of windows open. Using the outlined method, users will be able to do that with a simple double click.

Scenario 3: Creating a user account
Imagine your road warrior user being on the road again, with no ability to connect to the company network. However, some application misbehaves, it simply does not start anymore but it is needed most urgently. What can he do? Should he start to analyze the problem? Wouldn’t it be a better idea to be able to give him a temporary local test user he can logon with? It would, since very often, apps not starting anymore are immediately usable again under a clean profile. May non-admins create other user accounts? No again! But once more, we can solve this scenario by allowing the user to execute a simple, pre-defined script. [Wouldn’t it be a wiser idea to pre-create such a test user account and keep it handy at all times for the road warrior? In my opinion, it would not, because of security implications. Enabling him to create such an account on demand and restrict its usability to maybe 3 days (then the account expires), would be a better idea]

Now for the more generic use-case: this method is suitable to run any script with administrative rights. What could these scripts be used for? You name it. Microsoft has made windows usable without administrative rights pretty well, but many admins will agree, that from time to time over the years, there were a few situations where they would have liked the users to be able to do something only admins are supposed to do.

You need to be aware that this is a decision with security implications. If you set up your users as non-admins for a reason, this reason will normally be “they should not mess with the PC configuration, nor should they be able to decrypt or manipulate the pc in any malicious way, be it reading out confidential data or passwords of others, or be it retrieving license keys (that are only accessible by admins)”.

So how can we achieve that goal without at the same time allowing them to mess with system security? The answer is straight and easy: You need to use scripts that do not interact with the user.

User interaction means visibility of the script execution in terms of a window that the user might click on – this needs to be avoided. So any commands that you run need to be working without requiring user input. Furthermore, the script file itself must not be writable by the user, else, he would be able to change it at will and execute whatever he wanted. You achieve that by simply putting the script into a non-writable folder, we created c:\windows\admin for that.

Ok, now let’s put this to action. I will pick scenario 2 as an example: Disabling and re-enabling the NIC

1st, as admin, we will create a batch script: c:\windows\admin\NIC_restart.bat – the contents will need to be just three lines of code:

netsh interface set interface name="Local Area Connection" admin=DISABLED
timeout 3
netsh interface set interface name="Local Area Connection" admin=ENABLED

(The timeout command makes the system wait for a little until the NIC is ready to be re-enabled.)

Please note: For those of you who want to work with this example: you will need to adapt "Local Area Connection” to match the name of your active NIC as seen in ncpa.cpl, as it could be different and is language dependent.

2nd, as admin, we need to create a scheduled task and set it like this:

• Taskname: “NIC_restart”
• Executing account: system
• Task action: c:\windows\admin\NIC_restart.bat
• Trigger: On event, Log: Application, Source Application, Event ID: 999

[choosing the odd number 999 has a reason: it is not in use by windows]

For those of you unfamiliar with scheduling event triggered tasks: what we have created is a task, that launches whenever an event log entry of that kind is created.

3rd and final step: provide the user with a batch file NIC_Restart_Task.bat that he may place in his personal folders or the desktop that triggers that task by writing to the event log in the requested manner. That batch would go:

powershell Write-EventLog -LogName Application -Source "Application" -EventId 999 -message 'This event was created by %username% for the sole purpose to launch the task NIC_restart'

You prefer to provide a Powershell script? Sure. Just save it as NIC_Restart_Task.ps1and make it:

Write-EventLog -LogName Application -Source "Application" -EventId 999 -message "This event was created by $env:username for the sole purpose to launch the task NIC_restart"

That’s it. If the user launches that batch/that Powershell script, the NIC will be disabled and re-enabled using administrative powers. Do this test now, it is easy and takes only 2 minutes to set up. The sole requirement is to have a Powershell script execution enabled (set-executionpolicy remotesigned).

If you followed this far, you might ask yourself 

This looks like a funny method - why on earth would Microsoft make it that hard?

Good question. In fact, it did not use to be that hard on OS' prior to windows 10. On windows 2000 to windows 8.1, for example, we could simply alter the permissions on task files and registry keys to allow others to use them. Windows 10/Server 2016 made it finally even more complicated if not impossible (see "Windows Server 2016 and scheduled tasks" for a confirmation) - I once asked on the Technet forum and no MS expert was able to tell me what other, official method should be used for this goal – in fact, they were not even aware of this method.

Why would Microsoft not mention anywhere that the way I show is even possible?

As I wrote, it has security implications and since many company administrators have no idea what they are doing, changing these task ACLs, Microsoft saw overall security endangered. Since only a few people will even need this, they removed it completely (or so my theory goes). So be warned (again) and use this with caution: never enable users to modify the scripts that you enable them to use as system account! The scripts need to remain in restricted folders like my example folder c:\windows\admin which you can create below c:\windows, which is already protected.

That's it. Please feel free to add any questions to this article!