Kaseya Community

Stupid elevation problems.

  • Hey guys, I have a task that I would like to complete in order to simply things for us and some of our customers. What I would like to do is create bat files that my customers can use to execute tasks we would normally do. No, this is not an instance where I can use Kaseya Stick out tongue. So the example I'd like to give is a customer of ours had an issue with updates. Once we fixed that issue, her computer booted up with her network adapted in an errored state. Well the fix was stupid simple, run ipconfig /flushdns and netsh int ip reset. Of course, her network is down so we can't kick those commands through ourselves so I was required to go onsite.

    So what I would like to do is put these commands in a bat file or powershell script that we can guide our users to incase this happens again. Now the problem is that some of the users won't have admin rights to kick off the commands to their fullest. Easy plan turned annoying, right?

    So, does anyone know of a way to create these tools that can kick off in an elevated state which will not require them to enter any credentials? I was considering "runas" but that will prompt for the password to the designated account which completely defeats the purpose.

  • Couldn't you use Group Policy to set the elevated privlages on the bat files you need?  

  • This is exactly the situation where our local admin account would be helpful. See my post "Looking for Feedback". We developed a tool that runs from your workstation once a day/week/month - whatever you need. It generates a random password, calls a procedure against every workstation (via API) to create or update an account with that password, then writes the password to a custom field.

    In your situation, the bat file run by the user would invoke UAC - you'd give them their local account (LAUser) and the machine-specific password and the tool would run.  You'd manually run the procedure and just hit random keys when prompted for the password - when the machine next checks in , that password is set, and if successful in updating the password, writes it to the custom field. This would not be needed if you ran the update daily, but would be recommended if you ran weekly or monthly.

    We'll have it on the automation exchange and our web site in about 10 days.. we're wrapping up the installation guide. $49 per MSP, unlimited agents.


  • You could create a task in Task Scheduler with the credentials stored in the job (you should be able to use Kaseya to create and manage this task and those credentials). This task could run a script file in a protected directory (to prevent a malicious actor from adding commands to take control of the system) and be manually started by the user upon your instruction, without needing any credentials. The directory, the file and all permissions associated could also be controlled by Kaseya.

  • You need to create a shortcut to the .bat file with run as admin selected. These are the steps below:

    1. Make a shortcut pointed to the command prompt (I named it Administrative Command Prompt)

    2. Open the shortcut's properties and go to the Compatibility tab

    3. Under the Privilege Level section, make sure the checkbox next to "Run this program as an administrator" is checked

  • My objective is to not have to give them admin credentials cause that can be dangerous. I'm not sure your method would work EJohnson.

    @Jtinney, interesting idea, I'll look into that

    @Gbarnas, very promising definitely looking into that.

  • @Jtinney, I attempted your trick and I can see where you were leading me. Unfortunately, when I ran the task manually the batch file never executed. PRETTY sure I set it up correctly too.

  • I was able to get this to work and access privileged areas and commands by configuring the task as follows:

    Create Basic task, choose Daily run, browse to batch file, choose to open properties when completed

    In properties, change user to SYSTEM, check the box for Highest privileges, remove the trigger so that no trigger is present. Verify in Settings that 'Allow task to be run on demand' is checked.

    From a non-admin user I was able to create folders and files in protected locations (like C:\Windows) without issue. I was also to run a command that requires elevation within the script without issue.

    Here is the contents of my test batch file. The vssadmin list providers command requires elevation and will fail without it. Net user and net localgroup will run even for standard users but they give some output to look at. All of that written to a folder created in a protected location, which would also fail without the task elevation.

    mkdir %windir%\testbatch

    cd %windir%\testbatch

    net user > netuser.txt

    net localgroup > netlocalgroup.txt

    vssadmin list providers > vssadmin.txt

    I hope that helps!

  • @

    I often use the task scheduler to run tasks with elevated rights, and even leverage the ability to dynamically define a task and credentials without defining a schedule - just call the Run Task Now to run it immediately. I actually wrote a platform that allows a user-mode login script to perform a detection and request an admin-level task to be initiated asynchronously - it would often start that task before the 3-5 seconds it took for the login script to complete.

    Your solution, defining a selection of "stupid-simple" tasks when coupled with bat files to execute them via Run Now is pretty darn sweet! A bat file with a simple menu of these quick fixes running individual bat files that trigger the events is easy to use and maintain, even though it's "so 1980's" :) Might not be too difficult to put this into a GUI. (Our Daily Maintenance GUI is slated for such an MSP-configured capability in the next release, running either local commands or triggering requests for procedures.)

    The one problem I see with this solution is that an MSP will take this logic and apply it to something dumb, like a command prompt. "Just open that command prompt, run the installer, and you're good to go!" is a huge security hole. Users will learn that they can do this any time they want.  We've spent years removing admin rights from end-users and misuse of this cool technique will undo those gains. The generic ability of end user rights elevation needs to be controlled, and that's what our tool can help with. Having an account on the machine that can be given to the user to enter into a UAC prompt requires that they contact the MSP to get the credentials, and they are given only if appropriate. This works whether the agent is online or not, since it is predefined when online and updated daily.

    I have a full library of Kix32 functions that can create a scheduled task in as few as 4 lines of code, and execute it in just 2 (init, run). Reach out if you're interested in this. Works well with VSA!


  • Thanks for the compliments. Wow, Kixtart! Talk about old school. I haven't used that in a long time. It does run extremely well and is a pretty nice language. That's right out of the 90's :) About just as old as Task Scheduler.

    I hedged my answer with some basic security measures to secure said batch files from tampering but yes, common sense (or maybe even some uncommon sense) needs to be used here. You should not in any way configure a task as described to allow an interactive command prompt or shell nor reference or execute a file in an insecure location. BitLocker encryption of the system would also prohibit further tampering of the drive and files as well should someone try to modify the files in another OS. Lots of things to take into account.

    Hopefully the OP is getting some kind of help from these exchanges as well and we're not just blasting them with alerts.

    "With great power comes great responsibility!" -LocalSystem