0

I’ve been struggling with something for quite some time now. The boss wants a directory in our fileserver, that he will put program installation files in, all can read and only he can modify.

He wants client workstations to have a script that reads the directory and shows the user what files are there. Then the user, which is a normal domain user (without the ability to install anything), would be able to click install and it would install it.

The idea behind it is to have local admin at the user's station and have the script know the local admin's password and then install the program on the user's computer with those local admin credentials.

This is a very problematic issue because I cannot see how I can secure it without storing the local admin password inside the script, which is a very bad thing.

I tried to think about encrypting the password somehow and converting the script to an executable, but I cannot see a way that a user that knows a little bit about computers wouldn’t be able to decompile the executable. If I use PowerShell encryption, it would be suited for one machine and one user only.

Then I thought of another way: making a call from the client workstation to the filer and then making the filer use psexec back to the user, but this is getting too spaghetti.

Then I thought about making a call from the user's computer to the filer and then from the filer back to the user using invoke-command, but I need to allow WinRM to all the clients.

I'm using PowerShell for this. Maybe someone here has done something similar and can advise me on how to do that securely.

The first option worked great, so I would like to stick with it if possible, but I have to figure out how to secure this thing and not just put credentials in a PowerShell script that sits on the user's computer.

3
  • Sound like your boss has some self-service portal in mind. I would not try to build something like this on your own. There are already existing solutions: reddit.com/r/sysadmin/comments/86hiy7/… However the easy way would be to just install all software packages via GPO. As long as the software does not require a high license fee this is the simpler solution.
    – Robert
    Commented Jul 17, 2020 at 16:19
  • There are enterprise tools the do this automagically. Admin creates a software list, assign them to groups that users are a member of and then software automatically gets installed. This is called role-based software deployment. One such this is call SCCM. If you give a user a list of stuff, they will install stuff they never really need, and your licensing cost, without a control (metering solution) like SCCM, will go through the roof.
    – postanote
    Commented Jul 17, 2020 at 19:17
  • Yes, we do use GPO to install software, but his main goal is to create like an app store for the users.SCCM is a great choice for this kinf of scenario only he dont want 3rd side apps Commented Jul 18, 2020 at 5:51

2 Answers 2

1

I see two approaches.

  1. Get a different boss. He obviously has no clue how complicated the task he demands really is, it's always the details, and I doubt he has had a look at them. Windows installations are extremely tricky to master in detail.

Still reading? Okay. It can be done.

  1. The key point is to run your script as a "scheduled task" in the background. When you setup a new "scheduled task" per machine, you are prompted for a username and a password this task should use. Here you pass in your installation account credentials. The password cannot be retrieved afterwards, so it can be considered safe. This "scheduled task" does now have full administrative rights, and if you use a domain user account (give it admin rights on the clients, and only user right on the server) your script can easily access the installation files over the network and trigger the installation.

Be warned though, that many installation programs are rather dumb, they will install the program for use by the user which installs the program (i.e. your installer user) and not for the user logged in in the foreground. Some installers can be parametrized to install to "all users", which will probably do, for the others you'll have to make your script smarter so it can add "all required settings, licenses(!), icons, whatever a program needs to function" into the foreground user's profile after the software's installer has finished.

There is absolutely no legit way to have a user account perform the task. If there was any way a user can elevate his privileges to administrator without knowing an administrator password or being given administrative rights by an administrator, any user could do anything any time, which is almost equivalent to running all user accounts as administrators all the time.

  1. Now you need some additional script, web GUI, whatever you like, which lets the user choose from the software on the server, probably check whether the user has permissions to have the software installed, and probably whether the user's computer meets the requirements for the installation (Hardware? Free disk space? ...) to succeed. Then you'll have to store that information in a location where your background installer can read it. A simple list on the server will do.

  2. Finally the background script will periodically access that list and trigger the installers.

Done.

Let me say that what you have in mind is programming an automated software distribution facility. There are commercial tools available which do it, one is even built-in Windows Active Directory and comes for free. I don't know how many years and money the developers have sunk in each, to get to a point where their installers master many (most? all? some?) of the many installer variants used by various Windows software. At first they may look expensive per client, but I doubt that you'll be able to beat any commercial solution in terms of cost, reliability, features, documentation and community support with anything you'll be able to make in Powershell.

0
1

This sounds like a job for Group Policy software deployment. This gets around the issue of users lacking administrative rights.

By publishing a package, it will make the software available to users under Control Panel (as opposed to just automatically installing it).

From end users' perspectives:

Setup

  1. See Microsoft's guide here (old article but still relevant). Follow the "Publish a package" section rather than "Assign a package".
  2. Delegate the appropriate permissions for the GPO and the "software repository" share. You could create a security group specifically for this called Optional Software Administrators, for example, and add your boss as a member. Ensure the ACE applies to This object and all descendant objects: Grant Modify NTFS permissions on the Software folder for Optional Software Administrators:
  3. Install the Group Policy Management console on your boss's machine by running this PowerShell command elevated:
Add-WindowsCapability -Name "Rsat.GroupPolicy.Management.Tools~~~~0.0.1.0" -Online

From here on out, your boss is ready to start copying installers to the Software share and modifying the software deployment GPO accordingly (though, he'll need to be guided initially). And it's all without local machine or domain admin privileges and a (reasonably) easy experience for all involved!

You could even make things easier for end users and your boss by pushing out shortcuts directly to where they need to go. Installation of Group Policy Management console could also be automated if this needs to scale up to more administrative users or if your boss roams around multiple machines.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .