End User Software Management When Running as Normal Users on Windows
-
@scottalanmiller said:
So this is being discussed in a few thread and offline as well and the question arose... if people are not local admins in how they run on their desktops, and you don't want to heavily restrict software deployments, how can this be handled in a secure yet productive way.
I have some thoughts but as a non-Windows Admin, especially a non-desktop admin, I'm sure that a lot of people will have better insight than me. But I am familiar with a few good options.
- Allow Admin Escalation. If you have a user who is qualified, trusted and authorized to act as an admin (e.g. would be trusted with IT, but that is not their duties) then allowing escalation to admin would be okay. @Minion-Queen gets this. She isn't allowed to run as a local admin for using her computer, but she had an admin account so that if she wants to install something she does not have to go through IT to do it (but can, that's what IT is for.)
- Use a product like LANDesk. Using this you can a web page where users can click to install any pre-selected application. This is very smooth and way easier than a normal software installation. It does require prepping the applications, but it is a nice middle ground with application verification and really, really easy end user capabilities and can be used for ANY end user and can have approval workflow when necessary (manager approves license or whatever.)
- You can make something like LANDesk using Chocolatey (or other tools) that are locked to a private (or the public) repos and enable using that locally or through a custom interface. Lots of options.
- Have IT do it through scripts or GPO. Not as "all on the end user" but makes the system pretty easy and quick. Can be automated through a portal as well, bringing us back to #3.
- Just have a good ticket system and workflow for IT to do it. This is simpler than it sounds in most cases.
I haven't met users that I can trust yet. They either install malware eventually, or worse, install bootlegs at will. 5 is probably the best option.
-
The hardest question is "what security are you looking for."
We certainly have clients that demand that they have a person with this kind of access and literally most of our service calls and their cost is us cleaning up after they blow away storage, cripple servers, install malware (over and over again) and bring down production. But the customer continues to demand it, so we continue to make money fixing it.
But would we trust them or call them secure? No. It's better than nothing, but if the people cannot be trusted, it's still handing over the power to destroy everything. So it all depends on the people who are given the access and what level of security you seek.
-
@marcinozga said:
I haven't met users that I can trust yet. They either install malware eventually, or worse, install bootlegs at will. 5 is probably the best option.
All of the options outside of #1 will prevent the malware (unless it sneaks past IT) and bootlegs.
-
@JaredBusch said:
As an outsourced IT Service Provider, we cannot be always available to clients to handle this need in as timely a fashion as needed at times (i.e. the owner says he needs his cat pics screensaver installed now).
The compromise we have come up with is a domain account that is added to the local administrators group in AD.
I'm in the boat and also use group policy to push a local admin account to the machines through group policy. If a machine (esp laptops) decides it doesn't want to log in to the domain, you can just log in with the local account and get it going.
-
Here is an idea, as well. Not great, but should work, right?
Make a script or tool (nothing fancy) that will get admin rights to install software BUT is locked to a specific folder or folders (network ones, presumably.) So you create a universal deployment point and make it universally mountable and read only. Then with this tool, any user is able to run an installer from that location directly, but only that location.
Does not handle middle of the night, ad hoc requests. But it does allow for a continuously growing repository of packages to install that is easily leveraged. And if you do need to do a middle of the night request you only need to get something downloaded to that location, nothing more.
-
@Mike-Davis said:
@JaredBusch said:
As an outsourced IT Service Provider, we cannot be always available to clients to handle this need in as timely a fashion as needed at times (i.e. the owner says he needs his cat pics screensaver installed now).
The compromise we have come up with is a domain account that is added to the local administrators group in AD.
I'm in the boat and also use group policy to push a local admin account to the machines through group policy. If a machine (esp laptops) decides it doesn't want to log in to the domain, you can just log in with the local account and get it going.
Yeah, we push that LocalAdmin via GPO. It is not manually setup on the machines.
-
@scottalanmiller said:
Here is an idea, as well. Not great, but should work, right?
Make a script or tool (nothing fancy) that will get admin rights to install software BUT is locked to a specific folder or folders (network ones, presumably.) So you create a universal deployment point and make it universally mountable and read only. Then with this tool, any user is able to run an installer from that location directly, but only that location.
Does not handle middle of the night, ad hoc requests. But it does allow for a continuously growing repository of packages to install that is easily leveraged. And if you do need to do a middle of the night request you only need to get something downloaded to that location, nothing more.
Setting up a Repo of sorts would be good for that... and a Web interface a la LanDesk or Chocolatey would be nice too... Limited only by the bandwidth of the device trying to connect and whether or not you require them to use VPN or ZT or something to access the repo when working remotely.
-
@dafyre said:
@scottalanmiller said:
Here is an idea, as well. Not great, but should work, right?
Make a script or tool (nothing fancy) that will get admin rights to install software BUT is locked to a specific folder or folders (network ones, presumably.) So you create a universal deployment point and make it universally mountable and read only. Then with this tool, any user is able to run an installer from that location directly, but only that location.
Does not handle middle of the night, ad hoc requests. But it does allow for a continuously growing repository of packages to install that is easily leveraged. And if you do need to do a middle of the night request you only need to get something downloaded to that location, nothing more.
Setting up a Repo of sorts would be good for that... and a Web interface a la LanDesk or Chocolatey would be nice too... Limited only by the bandwidth of the device trying to connect and whether or not you require them to use VPN or ZT or something to access the repo when working remotely.
Right, and in theory this would lower bandwidth usage (for most businesses at least) while increasing install performance.
-
@scottalanmiller said:
@dafyre said:
@scottalanmiller said:
Here is an idea, as well. Not great, but should work, right?
Make a script or tool (nothing fancy) that will get admin rights to install software BUT is locked to a specific folder or folders (network ones, presumably.) So you create a universal deployment point and make it universally mountable and read only. Then with this tool, any user is able to run an installer from that location directly, but only that location.
Does not handle middle of the night, ad hoc requests. But it does allow for a continuously growing repository of packages to install that is easily leveraged. And if you do need to do a middle of the night request you only need to get something downloaded to that location, nothing more.
Setting up a Repo of sorts would be good for that... and a Web interface a la LanDesk or Chocolatey would be nice too... Limited only by the bandwidth of the device trying to connect and whether or not you require them to use VPN or ZT or something to access the repo when working remotely.
Right, and in theory this would lower bandwidth usage (for most businesses at least) while increasing install performance.
This is why I asked months ago in the original chocolatey threads about setting up your own stuff for it.
-
@scottalanmiller said:
Here is an idea, as well. Not great, but should work, right?
Make a script or tool (nothing fancy) that will get admin rights to install software BUT is locked to a specific folder or folders (network ones, presumably.) So you create a universal deployment point and make it universally mountable and read only. Then with this tool, any user is able to run an installer from that location directly, but only that location.
Does not handle middle of the night, ad hoc requests. But it does allow for a continuously growing repository of packages to install that is easily leveraged. And if you do need to do a middle of the night request you only need to get something downloaded to that location, nothing more.
While this might sound simple, I have no idea how you would kick it off? Ultimately I don't see how this could be much different than options 2 and 3. You create a script that uses the RunAs command with saved credentials as @JaredBusch mentioned, that launches a menu of the things in the repo directory that you can choose to install?
I can't think of another way (though I'm not a programmer, I don't even play one on TV) to have local admin rights run a script that a user couldn't tear apart and find the admin password inside that would be a network user that would somehow be limited to only have access to specific folders for the user to pick an installer there at random for them to install.
Not to mention it's really probably to much to ask them to install it anyway, so you'd need to build installer scripts so the users don't have to answer any questions for the install.
And we're right back at options 2 and 3 above.
-
@Dashrender said:
@scottalanmiller said:
Here is an idea, as well. Not great, but should work, right?
Make a script or tool (nothing fancy) that will get admin rights to install software BUT is locked to a specific folder or folders (network ones, presumably.) So you create a universal deployment point and make it universally mountable and read only. Then with this tool, any user is able to run an installer from that location directly, but only that location.
Does not handle middle of the night, ad hoc requests. But it does allow for a continuously growing repository of packages to install that is easily leveraged. And if you do need to do a middle of the night request you only need to get something downloaded to that location, nothing more.
While this might sound simple, I have no idea how you would kick it off? Ultimately I don't see how this could be much different than options 2 and 3. You create a script that uses the RunAs command with saved credentials as @JaredBusch mentioned, that launches a menu of the things in the repo directory that you can choose to install?
I can't think of another way (though I'm not a programmer, I don't even play one on TV) to have local admin rights run a script that a user couldn't tear apart and find the admin password inside that would be a network user that would somehow be limited to only have access to specific folders for the user to pick an installer there at random for them to install.
Not to mention it's really probably to much to ask them to install it anyway, so you'd need to build installer scripts so the users don't have to answer any questions for the install.
And we're right back at options 2 and 3 above.
If you use powershell, it saves everything in an encrypted file, IIRC, so the user can't (easily) get at the admin username & Password.
-
@Dashrender said:
Not to mention it's really probably to much to ask them to install it anyway, so you'd need to build installer scripts so the users don't have to answer any questions for the install.
IF $ABOVE=="True" THEN $isMoot
Basically, if this statement is true, then the issue is moot because they could not be installing software on their own and need IT anyway.
-
@scottalanmiller said:
@Dashrender said:
Not to mention it's really probably to much to ask them to install it anyway, so you'd need to build installer scripts so the users don't have to answer any questions for the install.
IF $ABOVE=="True" THEN $isMoot
Basically, if this statement is true, then the issue is moot because they could not be installing software on their own and need IT anyway.
But that is the point of using a Repo-like install. Install the software, configured the way IT wants it. Then the user just has to click a link on the web site... we KNOW they are good at that, lol.
-
@scottalanmiller said:
@Dashrender said:
Not to mention it's really probably to much to ask them to install it anyway, so you'd need to build installer scripts so the users don't have to answer any questions for the install.
IF $ABOVE=="True" THEN $isMoot
Basically, if this statement is true, then the issue is moot because they could not be installing software on their own and need IT anyway.
I'm not sure about your users, but my users would definitely ask on every dialog box - Heck, they call about the EULA for Adobe after an update is installed. I try to remember to launch it before I leave so I accept it and move on.
-
@Dashrender said:
@scottalanmiller said:
@Dashrender said:
Not to mention it's really probably to much to ask them to install it anyway, so you'd need to build installer scripts so the users don't have to answer any questions for the install.
IF $ABOVE=="True" THEN $isMoot
Basically, if this statement is true, then the issue is moot because they could not be installing software on their own and need IT anyway.
I'm not sure about your users, but my users would definitely ask on every dialog box - Heck, they call about the EULA for Adobe after an update is installed. I try to remember to launch it before I leave so I accept it and move on.
There's GPOs for that.
-
As frequently as they are making updates for Flash, and Reader - I didn't bother digging into what it takes to do upgrades through software pushes.
Sure, there are GPOs for the EULA itself, but if I'm doing the install, it's not that big a deal to get rid of the EULA either.
-
@JaredBusch said:
@Mike-Davis said:
@JaredBusch said:
As an outsourced IT Service Provider, we cannot be always available to clients to handle this need in as timely a fashion as needed at times (i.e. the owner says he needs his cat pics screensaver installed now).
The compromise we have come up with is a domain account that is added to the local administrators group in AD.
I'm in the boat and also use group policy to push a local admin account to the machines through group policy. If a machine (esp laptops) decides it doesn't want to log in to the domain, you can just log in with the local account and get it going.
Yeah, we push that LocalAdmin via GPO. It is not manually setup on the machines.
Consider changing this practice. I used to do it that way, too, but it's no longer considered secure and Microsoft won't even allow you to do it anymore in the newer versions of Windows Server in the GPPs.
Account info disseminated this way isn't hard to find, I believe its in the SYSVOL folder somewhere, and once an attacker had it they could laterally jump from machine to machine with ease. This would be especially bad if that policy was applied to more than just workstations.
This doesn't produce the exact same results, but today you would want to use Microsoft's LAPS (Local Administrator Password Solution):
https://www.microsoft.com/en-us/download/details.aspx?id=46899
I've set it up several times now and it's really easy to use.I'm sorry if you're already familiar with it, but I didn't want anyone to think your suggestion is a good practice these days.
-
I also wanted to add that I love Admin Arsenal's PDQ Inventory and Deploy. They aren't the cheapest software ever, but in my situation it works out well. Their licensing policy is per admin, so I'm free to use it at all my clients' offices as long as I'm the one using it. I do outsourced IT, so it's perfect.
At a few smaller locations that don't have a central server (or workstation they use as a server) I've setup chocolatey scripts and used Ninite, too. Both work well.
It's really cut down on the admin pop-ups caused by Adobe Reader, Adobe Flash, and Java.
When provisioning a new workstation there's obviously a need to use admin credentials a lot. But thereafter I find that if you can take care of these frequently updated pieces of software users rarely encounter admin UAC prompts.
-
@Brett said:
@JaredBusch said:
@Mike-Davis said:
@JaredBusch said:
As an outsourced IT Service Provider, we cannot be always available to clients to handle this need in as timely a fashion as needed at times (i.e. the owner says he needs his cat pics screensaver installed now).
The compromise we have come up with is a domain account that is added to the local administrators group in AD.
I'm in the boat and also use group policy to push a local admin account to the machines through group policy. If a machine (esp laptops) decides it doesn't want to log in to the domain, you can just log in with the local account and get it going.
Yeah, we push that LocalAdmin via GPO. It is not manually setup on the machines.
Consider changing this practice. I used to do it that way, too, but it's no longer considered secure and Microsoft won't even allow you to do it anymore in the newer versions of Windows Server in the GPPs.
So I read through the LAPS you linked to.. and I have to ask.. What's the difference between JB's creating a specific account and granting that account local admin and the fact that by default domain admin group is added to the local administrators group on every PC on the domain?
LAPS is more about the local admin account password being set the same on every machine, but JB's solution isn't the local admin account, it's a domain account that's granted local admin access.
I have done what LAPS is meant to replace - use GPO to set the local admin password to a specific password, and your point about it applying to more than just workstations is well received. I'm going to look into LAPS. Thanks.
-
I had way too many problems with virus issues and computer performance with letting users have admin access on desktop and laptop computers. I have pretty much eliminated these issues by making them all users and only installing pre-apporved software. I have Ninite Pro running as SYSTEM in a GPO/logon script to update 3rd party software and also I use it to push software remotely on demand.
I did run into a problem with UPS Worldship that needed to update several times a week and needed local admin rights to do so. The problem was solved by running the Microsoft Application Compatibility toolkit.
https://www.microsoft.com/en-us/download/details.aspx?id=7352
It allows you to create a database for the files that you would like to be whitelisted to run as admin so they can be executed if the user doesn't have admin access to it. You can also limit by file version (which is the default, so be careful).
