Create an installer for domain users

Question

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.

Luke Humberdross · Answer

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

See Microsoft's guide here (old article but still relevant). Follow the "Publish a package" section rather than "Assign a package".
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:

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.

Nimral · Answer

I see two approaches.

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.

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.

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.

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.

Create an installer for domain users

2 Answers

Setup

Add your own answers!

Ask a Question