Link to home
Start Free TrialLog in
Avatar of Pkafkas
Pkafkas

asked on

Is there a way to elevate permissions for a batch file without being prompted for a password?

I am trying to deploy local windows firewall rules to several separate Windows 7 laptops.  We have Novell NetWare in our environment; hence, using Group Policy from a WIndows Domain to propagation to the devices, is not a n option (unfortunately).

I have discovered that if one executes a batch file, with the command:

netsh advfirewall firewall add rule name="NetScaler Gateway Plug-in" dir=in action=allow profile=public program="C:\Program Files\Citrix\Secure Access Client\nsload.exe" protocol=TCP enable=yes

Open in new window


that works really well ( https://support.microsoft.com/en-us/help/947709/how-to-use-the-netsh-advfirewall-firewall-context-instead-of-the-netsh ); but, the problem is that when executing the above command you need to run the command prompt as an administrator.

User generated image
As you can see if the user does not have admin privileges or does not know the administrator password, then the only other thing I can think is to create 2 batch files and manually copy the files to the user's laptop.  1 file will have the  'runas' command to use the local administrator user account and then to trigger another batch file with the changes:

runas /user:administrator C:\data\mybatchfile.bat

Open in new window


https://www.windows-commandline.com/windows-runas-command-prompt/

So the batch file: mybatchfile.bat will actually have the code that adds the firewall rule(s):

netsh advfirewall firewall add rule name="NetScaler Gateway Plug-in" dir=in action=allow profile=public program="C:\Program Files\Citrix\Secure Access Client\nsload.exe" protocol=TCP enable=yes

Open in new window


Question1:  Is there a way to streamline the deployment approach because our users will require these local windows firewall rules and these users are not administrators on their company laptops.  

Question2:  Is there a way to elevate permissions for a batch file as the script begins executing?  So you will not be prompted for a password?
Avatar of James Rankin
James Rankin
Flag of United Kingdom of Great Britain and Northern Ireland image

Have you tried using CPAU from JoeWare for elevation of batch?
You could configure a startup script. Startup scripts run elevated by default and can be placed on a central network share so that you modify one script for all. Downside, you need to visit each machine to configure the startup script, once (but you can use it from then on).
Avatar of Pkafkas
Pkafkas

ASKER

Mr. McKnife:  We really want to limit the exposure of administrative privileges on the laptops.  Putting startup script to run elevated by default is not what we want.  Thank o though.

Mr. James Rankin:  Will we need to download anything for your suggestion to work?  CPAU from JoeWare for elevation of batch
"We really want to limit the exposure of administrative privileges on the laptops." - anyone should. That's why you should use the way I propose. No password is needed. Completely secure. Tools like CPAU are not secure, since their credentials are, at some point, converted to plain text files (and then deleted, which implies, they can be recovered).
I'm not getting into a discussion about security, I've used CPAU several times in the past and had the thing approved by security teams. It's up to you how you handle risk versus functionality. If you want admin rights then somehow you need to run elevated, unless you pay for something like Ivanti Application Control that can do elevation on-the-fly. CPAU is a no-cost option and I've never had it knocked back or compromised. YMMV. If you're prepared to pay for something like Ivanti where there's more of a feeling of security around the code base, then that's an option too.
Why not use PSEXEC and run it against all the machines from your machine?
You can supply the credentials, and have it run "silently" to all the users machines.


https://docs.microsoft.com/en-us/sysinternals/downloads/psexec
I use a task to do firewall settings via PowerShell. See if this is an option for you

See my article on Firewall as Code
https://www.experts-exchange.com/articles/31687/Windows-Firewall-as-Code.html

User generated image
Just another note on CPAU and security (no need to discuss, correct): https://micksmix.wordpress.com/2013/03/20/capturing-credentials-from-encrypted-runas-software/ mentions CPAU and has tried it out and could capture the password as a standard user. It needs know-how, though, so if you think users don't have that know-how, use CPAU. Again: using a startup script would not need to work with passwords at all and is recommended for that reason.

Psexec is ok, but would
A require all machines to be on at execution time
B need (dangerous) firewall exceptions
C work easier if used with a credential set that fits anywhere (which one should definitely avoid at all cost).
I didn't say no need to discuss, I said I wasn't going to discuss it. All software has flaws. Flaws get found and fixed. Security teams exist to detect and mitigate and advise. Updating is a responsibility. YMMV.
Avatar of Pkafkas

ASKER

Hello Shaun Vermaak,

I like the idea of using powershell; but, I am not very familiar with it.  If I copy the commands into Windows PowerShell ISE and then save it to a .ps1 file and then execute it.  I get the response:


The requested operation requires elevation (Run as administrator).  

How can I use powershell to add the firewall rules and to use admin rights to the remote laptops?


netsh advfirewall firewall add rule name="NetScaler Gateway Plug-in" dir=in action=allow profile=public program="C:\Program Files\Citrix\Secure Access Client\nsload.exe" protocol=TCP enable=yes
netsh advfirewall firewall add rule name="NetScaler Gateway Plug-in" dir=in action=allow profile=public program="C:\Program Files\Citrix\Secure Access Client\nsload.exe" protocol=UDP enable=yes
netsh advfirewall firewall add rule name="Citrix HDX Engine" dir=in action=allow profile=private program="C:\Program Files (x86)\Citrix\ICA Client\wfica32.exe" protocol=TCP enable=yes
netsh advfirewall firewall add rule name="Citrix HDX Engine" dir=in action=allow profile=private program="C:\Program Files (x86)\Citrix\ICA Client\wfica32.exe" protocol=UDP enable=yes
netsh advfirewall firewall add rule name="Citrix HDX Engine" dir=in action=allow profile=public program="C:\Program Files (x86)\Citrix\ICA Client\wfica32.exe" protocol=TCP enable=yes
netsh advfirewall firewall add rule name="Citrix HDX Engine" dir=in action=allow profile=public program="C:\Program Files (x86)\Citrix\ICA Client\wfica32.exe" protocol=UDP enable=yes

Open in new window

Echo McKnife. Tough I think the issue is a confusion of terms. a startup within the programs, .. is actually the wrong option as it is run at user level. What I believe McKnife suggests is to configure the system to run the script at computer bootup (poweron) script. The local user unless they have local administrative rights will not be able to access this script (unless when configuring the security settings on it are lax)

Have not used or worked with a novell netware network setup in quite some time.


When configuring the system for novell netware.
runing mmc, adding the local group policy, computer configuration, windows settings, scripts (startup/shutdown)... These run at Computer level (elevated)
or create a script that when you configure a system for novell netware, you update the firewall at the same time.

The other option if you have a centralized anti-virus/SEP ... mcaffee, symantec, etc. use them to distribute the firewall rules.
Avatar of Pkafkas

ASKER

Hello Ron Malmstead,

Correct me if I am wrong; but, if we run PSexec, from a PC, that can connect to a remote computer by launching the command prompt with admin credentials, correct?

The computers will need to be connected to the network in some way; but,
Question1:  Can anything block the >psexec \\computer_name cmd -u administrator    ... from running?

Question2:  Is it normal to execute the above command from my desktop and to successfully connect to the remote computer as administrator without being prompted for a password?

I just connected from my dekstop to a remote computer (on the same LAN network) with spsexec and I was able to manually run the DOS commands to add the firewall rules just fine.  I verified that it worked as well.  But I am surprised that the above psexec command did not prompt me to enter the administrator password fro the remote computer.
It will have used cached credentials - check your network credential manager.
Avatar of Pkafkas

ASKER

For whatever reason, the PSexec option only works from PC to PC if the destination PC is logged on with administrative rights.  If the destination PC has a user logged on with non-admin rights (as our employees are) then the PSexec command will not connect.

>psexec \\computer_name cmd -u administrator

Even if I put the -p PASSWORD, it will not connect correctly if a user is logged on to that destination device as a non-admin.  Why, I am not sure; but, it is what it is.  We are under a time crunch and time is not on our side.

What does work is if you:

1.  Copy 2 batch files to the C: Drive.  
       a.  Batch1.bat
       b.  Batch2.bat

2.  Double-click: 'Batch1.bat'
       a.  The code reads:
runas /user:administrator C:\Batch2.bat

Open in new window

3.  The above will trigger a command prompt asking for the user to enter a password for the administrator's account.  
      a.  Then after the password has been accepted, 'Batch2.bat' will be executed with administrator provileges.
      b.  The BAtch2. bat file has the firewall rules that we need added.
      c.  Such as:

netsh advfirewall firewall add rule name="NetScaler Gateway Plug-in" dir=in action=allow profile=public program="C:\Program Files\Citrix\Secure Access Client\nsload.exe" protocol=TCP enable=yes

Open in new window


It is not the cleanest way to do it; but, it works.  since every other option requires the user to have admin privileges before we can connect to that destination device... that is what we will do.
So you need to visit any pc now in person? Then use the chance and setup a startup script that points to a script file on a network share so that you will not need this in the future.
Avatar of Pkafkas

ASKER

These firewall rules may be installed from the installation of the NetScaler gateway.  And we will test if the installation file puts the firewall rules on the computer automatically (installed with administrator level).  if it does, then that will help and only the spot users will need some assistance.

In the future, what I want is to enable Powershell on all new images and that will allow us to make these changes from the powershell and be totally seamless to the user.
Powershell is nothing that needs to be enabled. It is just there. Powershell will not let you centrally manage things in a workgroup environment. I still would like to know, why you wouldn't even look at the startup script option - it is so easy.
Avatar of Pkafkas

ASKER

With my research and testing, one needs to actually open powers shell up on both the source and destination devices as an administrator and start the WinRM service.

https://www.howtogeek.com/117192/how-to-run-powershell-commands-on-remote-computers/

states these steps and I have verified that they are indeed necessary for our organization.  Aparantly the services and local windows firewall rules are not already set.


1.  Open Powershell on both devices, as an administrator.

2.  Execute the following command:
Enable-PSRemoting -Force
on both devices.

3.  Since our computers are not part of a windows domain, they are in a workgroup.  We use Novell Netware on Windows 7 PC's.
        a.  We need to configure the trusted host setting on both computers so run this command:
             
Set-Item wsman:\localhost\client\trustedhosts *
       b.  The restart the service:
Restart-Service WinRM

4.  Then you can establish a remote connection from the host PC by typing this command:
     
Enter-PSSession -ComputerName COMPUTER -Credential administrator


5.  You will be prompted to enter the administrator password for the destination pc, by a pop-up window.
      a.  At this point your powershell window can execute commands on the remote PC.  like so...
      b.  
netsh advfirewall firewall add rule name="NetScaler Gateway Plug-in" dir=in action=allow profile=public program="C:\Program Files\Citrix\Secure Access Client\nsload.exe" protocol=UDP enable=yes

it works really well as long as the services have started and the security rules are allowed for the host and devices to connect to each other.  You will still need the local administrator credentials.  I think of it as when you connect a dive to a new network and are prompted do you want other devices to see resources on your PC (yes/no).  You can say yes; but the other devise will still require security credentials.
You don't need firewall exceptions, remote management, no passwords to hide, nothing at all. You just need a startup script. Sorry for being awkward, but you seem to ignore that this will make your life so much easier. You can run powershell scripts as startup scripts, too.
Avatar of Pkafkas

ASKER

What do you mean as startup scripts?  Run a powershell at startup on a PC, I do not follow.

How will this help in changing a local firewall rule on a PC on a case by case basis?
Steps are:
1 At a client, open gpedit.msc, navigate to computer config - windows settings - scripts - startup. There, on the Powershell Scripts tab, add a script location, like \\server\scriptshare\mypowershellscript.ps1
2 the script can hold your netsh commands
***That's all, folks*** :-)
No, that's not all. The script execution policy needs to be set to remote signed, first, by executing (on an elevated powershell):
Set-ExecutionPolicy RemoteSigned

Open in new window

Also, that share where you put the script needs to be accessible anonymously. You set this here:
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options ->"Network access: shares that can be accessed anonymously". Just add the name of the share: scriptshare
Now that's all. On the next startup, your machine will execute the script code. In fact, will will do it on every new start from then on.
Make sure to grant only read permissions on that share (that is extremely important).

You can have multiple startup scripts, if needed. You can now centrally change the startup script contents, so new commands will be executed by your machines. They are executed as system account that has all privileges.
Let me clarify, just to make sure: "Network access: shares that can be accessed anonymously" needs to be set on the server that hosts the scriptshare, not on the client(s).
Avatar of Pkafkas

ASKER

Interesting process McKnife.  Keep in mind that I will need to visit every device in person to achieve the GPO (we do not have a native windows domain here).

I just wonder if that will help our remote users that will be out of the office 1.5 - 2.0 months at a time. If they cannot  access \\server\scriptshare\mypowershellscript.ps1 when the laptop initially logs on that might be a problem.

Thank you for your advice.  There is always more than 1 way to complete a task, the trick is to find out which way works best to achieve the business's objectives.
The point is that you have to determine whether the settings you are pushing should equally apply to system on your LAN and to systems that are mobile.

GPO based rules, apply only when the system is on the LAN authenticating to the AD DC.
When they are remote, the rules are not applied.

The option provided will refresh the rules once the users return to the LAN and the GPOs are refreshed. Though the System Startup script will only run on bootup when the system is on the LAN.

You could look at a powershell that will query a controlled destination for information that is accessible whether the user is on the LAN or remote.
ASKER CERTIFIED SOLUTION
Avatar of Pkafkas
Pkafkas

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
This is funny. You have said, that you are unable to use GPOs, we were aware of that from the start. But you yourself were initially unaware that your Novell Netware environment had the script distribution ability ZENworks? Anyway, good that you found it.
Avatar of Pkafkas

ASKER

Yes, its funny but its a good think when you learn about different technologies and how to use them correctly to achieve the business' objectives.