Windows 7 Interactive Installers - User has no admin privelages

Content Authoring
1

(imported topic written by macook91)

Does anybody know of a way to get a Windows 7 user without admin privileges to be able to run noisy installers using BigFix? I currently am using the Software Distribution Packages interface to deploy to XP machines without any issue, however in Windows 7 the Interactive Services Detection pops up asking me if I’d like to view the message. When you “view the message,” the installer appears to work just fine. I would however just like to push noisy installers to users and have the installer pop up just like on XP. Has anybody been able to accomplish this?

2

(imported comment written by MattBoyd)

The problem is that, even if you could run installers with admin (SYSTEM) rights interactively in Windows 7, it doesn’t mean you should. It is a security risk in Windows 7, and always was in XP. Allowing a user to directly interact with an admin-privileged process largely defeats the purpose of least privilege.

Because of this, I disabled the Interactive Services Detection service on all of our clients. Even if the service wants to interact with the user, we don’t want it to. Ever. I will continue to take this stance, and I made a “poster” (see attached image) to help show why. We decided to disable Interactive Services Detection after the OpenOffice uninstaller launched a survey in Internet Explorer as SYSTEM that the user could access, even though we specified “/quiet” mode.

What’s the name of the software you’re having issues with? What part of the installer is noisy? Is it noisy because the user needs to enter a serial number or license key? If so, can the license key be passed as a command line parameter to the installer? You could probably prompt the user for input using a simple VBScript and RunAsCurrentUser.exe, then write that to a registry key and have the action read from that. This is something that I plan to do myself (http://forum.bigfix.com/viewtopic.php?id=6630).

FWIW, I have yet to come across an install that couldn’t be automated. I’ve seen some tough buggers, but have managed to find workarounds in these cases.

Edit: The image didn’t take, so here it is: http://i.imgur.com/wwFM8.jpg

3

(imported comment written by macook91)

Our users dont have admin rights, and we dont want them installing certain things. So on XP i made a bunch of offers, so our users can accept the offer and it will pop up the installer for Firefox or MS Project, or whatever it may be that we have approved. I was hoping to do this with Windows 7 too, but its looking more and more like I cant, at least with interactive installers. I made some attempts with runas, but they were unsuccessful.

4

(imported comment written by NoahSalzman)

Love the image Boyd… I prefer warez.ru myself… but Mega Upload helps drive the point home.

5

(imported comment written by MattBoyd)

Thanks Noah! :wink:

6

(imported comment written by macook91)

This is cute and all, but doesn’t answer the question. I want to know if there is any way to get an installer to run with a gui WITHOUT having to have the Interactive Services Detection pop up, just like you have been able to do for years in XP using Bigfix. I get that the Interactive Services Detection is something we dont want our users to deal with.

7

(imported comment written by MattBoyd)

macook

I want to know if there is any way to get an installer to run with a gui WITHOUT having to have the Interactive Services Detection pop up, just like you have been able to do for years in XP using Bigfix.

Macook, I’m pretty sure the answer is no. BigFix does not include the ability to circumvent Interactive Services Detection in Windows 7. What you’ve been doing in XP is viewed by some as a security risk, and I’m not sure that you really need the Mozilla Firefox or Microsoft Office installers to run interactively. Can you make them offers that the user accepts, then run the installers silently?

Now playing devil’s advocate… there is a way to circumvent Interactive Services Detection by using Windows API functions to spawn a separate process as SYSTEM in the user’s console session. Microsoft SCCM has this ability. The setting is called “allow users to interact with this program.” My only experience with SCCM was a few months in a non-production environment, so I’m not an expert. However, I can tell you that their practices document (http://msdn.microsoft.com/en-us/library/bb680479.aspx) recommends NOT using this feature with admin rights for the same reason… security.

8

(imported comment written by SystemAdmin)

This is one of my pain points with BF/ TEP as well. There apparently are API ways to deal with this in Win 7 that are not implemented in Big Fix. Why this apparently isn’t being investigated, I don’t know. SCCM/SMS (we had it in our org for a while) dealt with the problem by installing items as an AD resource account with admin privileges on all PCs. This way it was as if the end user was running the installer with alternate credentials. There are very clunky ways i can think of to make this happen in BF. 1. Buy a least privilege management product such as Beyond Trust or Avecto. $$, but it will allow you to define applications for which an end user may attach an admin token during the execution process. 2. Use BF to temporarily create a local admin account on the PC, install the app as that admin interactively, then delete the account at the end of the process. 3. Use Sysinternals PSExec with the -s -i switches to elevate they system to interactive. I say YUCK on the latter two. #1 is to expensive for some orgs, but the API wizardry behind it could be implemented in TEM.

9

(imported comment written by SystemAdmin)

Add my vote to getting this resolved. If SCCM can do it, surely TEM can do it and do it better. Outdoing M$ would provide incentive to stick with TEM instead of SCCM which is included in our EA.

10

(imported comment written by SystemAdmin)

+1 for us as well. We still have SCCM around for this very reason. My desktop group does not want to let go of it because of the reduced functionality. UGH.

11

(imported comment written by BenKus)

So can you guys confirm what you want a little more? If I understand, you want to specify a “run as an Admin AD User” for an action so that you can pick a user to use?

The security of this sounds pretty suspect… I don’t have a lot of details about how SCCM works, but what if we find that it is insecure… and by “insecure” I mean that anyone with admin access to any computer could find the AD Admin user (and thus control any computer) if they tried hard enough?

If it is insecure in this method, would you guys say that you wouldn’t want BigFix to implement an insecure function OR would you say “if MS is doing it, then I don’t care if it is secure?”… The reason that I ask is that security concerns are the primary reason that we don’t implement this feature.

Ben

12

(imported comment written by macook91)

We want “runasadministrator.exe” just like we have “runascurrentuser.exe” right now. I dont how it would be insecure if we were able to add a local admin user to our workstations, feed BigFix the password for it, and BigFix is able to encrypt the password and use it to install applications with the elevated privileges. It would also make sense as FerrariGuy was stating, to have BigFix create a temporary admin account, of which only BigFix knows the password, run the fixlet using it, then delete the account.

The thing for you guys is that everyone out there is moving toward having all their users log in without admin privileges, yet there are still cases where you have to have admin privileges to run something. I am at a CSU, and the entire state of California I know for a fact is using a payroll system that was implemented in the late 70’s. The legacy software we use to get into the system simply will not run without admin privileges on the machine, forcing us to allow our users to have admin accounts on their workstations and violate our own information security policies. If BigFix could offer a run as administrator command, I could make that application an offer, and the users would never need admin privileges.

Like I said earlier, that little screenshot Boyd provided is cute and all, but there are cases where admin privileges are necessary for the user to get their jobs done. Furthermore, this is a place of business, our users have no reason to cause damage to their own workstations by getting a command prompt as system, we’re just trying to meet the information security laws we have to follow while still allowing our users to do their jobs.

13

(imported comment written by BenKus)

So I don’t think you can securely run an installer using a centralized admin account (whether AD admin account or a local account)… but… I like your idea to generate a local random user and password… I think that approach could work…

Let me play with the idea a bit…

Ben

14

(imported comment written by MattBoyd)

macook

Like I said earlier, that little screenshot Boyd provided is cute and all, but there are cases where admin privileges are necessary for the user to get their jobs done. Furthermore, this is a place of business, our users have no reason to cause damage to their own workstations by getting a command prompt as system, we’re just trying to meet the information security laws we have to follow while still allowing our users to do their jobs.

You’re right, if you can trust your users, that significantly reduces your risk (IMO) of running interactive process as an administrator. However, your systems would still (potentially) be at risk to the shatter attack (http://en.wikipedia.org/wiki/Shatter_attack) because you now have the admin process in the same console session, as was the case in XP. I guess it all comes down to what your appetite for risk is.

macook

The legacy software we use to get into the system simply will not run without admin privileges on the machine

I’ve seen legacy applications like that too, and there are (usually) ways around the admin privileges requirement. Specifically, what component of the software will not run without admin privileges? Is it because it needs write permissions on folder in the file system that the user doesn’t have? At any rate, this is a lot different than running an Firefox and MS Project installers interactively, which is what you initially indicated that you were trying to do.

Ben Kus

If it is insecure in this method, would you guys say that you wouldn’t want BigFix to implement an insecure function OR would you say “if MS is doing it, then I don’t care if it is secure?”… The reason that I ask is that security concerns are the primary reason that we don’t implement this feature.

I don’t think that I’m completely opposed to this feature, I’m just concerned that it will be widely misused. I don’t think people completely understand the implications of it, and I really think it should only be used as a last resort. If someone really wants to do it, they could use PSExec or write RunAsAdministrator.exe themselves… it’s not hard, and there are already some source code examples out there… I really don’t think that SCCM’s methods are any more secure, but I don’t know enough about it to say for sure.

If there is a legitimate need for this, then maybe it should be a feature. Still, I feel that if there is software or an installer that needs interactive admin rights, then there’s a security bug in the software or installer. We (as admins) should not make our systems less secure in order to get around it. I still haven’t seen a good example of something that couldn’t be coaxed into running without interactive admin rights.

15

(imported comment written by SystemAdmin)

The InfoSec person in me applauds the urge to prevent the possibility of rights abuse in the BF product, but there are market and political realities to consider here as well. BF is supposed to make my life easier. If I have to spend many extra hours bludgeoning a poorly written product into being silent so it can install in the background, I’m going to find a way to install it that doesn’t require BF because my duties are vast, and my time is limited. That’s not going to make me feel good about our investment in Big Fix. Warn me about the consequences of my action, but let me make the final decision as to what’s best in our environment. It’s imperative that I have a method of devoting a predictable period of time to a deployment task.

I really like what Beyond Trust (“Power Broker†http://www.beyondtrust.com/ ) and Avecto (“Privilege Guard†http://www.avecto.com/) have done to eliminate admin rights for end users needing to perform a particular task, run a particular EXE, or install a particular program. For the defined instance of the item that needs to be executed, an admin token is attached to the standard end user’s ID that is valid for that instance. I want BF to do the same for software deployment, that way I can run ANY deploy as the end user and the end user receives an admin token only for the instance of the actions run via the deployment tasks.

The last time I had to compensate for the inability to do this I spent several days trying to make an ancient interactive uninstaller silent. The product was no longer supported by the vendor, who would not communicate with me, and the uninstaller had been sourced from a 3rd party that no longer supported it as well. Ifinally had to create a

capture

of an uninstall using InstallRite and deploy that. If our organization owned either of the two above products I could have simply set a rule in AD and ran the uninstaller as the end user. It was ridiculous to have to spend my time that way because BF could not directly support the task I needed to do! My superiors are far more likely to just have me provide admin rights to all end users (they’ve threatened to do this) than spend lots of time figuring out how to fix products that require admin rights. I really don’t want that.

16

(imported comment written by JasonHonda)

Not sure if this is related, but many times I believe this issue is caused by the fact that BES Client service does not run with “Allow service to interact with desktop” privileges. This was a change I believe Vista and later that services by default do not have that permission and following with best practices for a secure environment we don’t force that option and with 8.0 and later of our platform we even leave it unchecked even in XP I believe. In nearly all cases we can find a way around user interaction to get things done.

It sounds like this is extremely important to some and I recommend looking into changing that setting and seeing if the desired functionality changes, and then I believe you should be able to create your own fixlets for changing that setting and accepting the security risks associated with that on your own. Hope this helps.

17

(imported comment written by SystemAdmin)

jason_honda

“Allow service to interact with desktop” privileges.

This no longer works in Win 7. In Win 7, PSExec is the only tool thus far that I’ve found allows the system to interact with the desktop. Something to do with Session 0 isolation… I think I’ve read that there are API ways to deal with it though as PSExec would seem to prove.

18

(imported comment written by SystemAdmin)

Jason, I’m glad you mentioned that “Allow service to interact with desktop” was not enabled on v8.0 agents. Understanding that helped identify why some tasks were failing in our environment.

I reset that option after installing v8.0 on clients so that our installs continue to function as expected.

waithidden cmd /C sc config besclient type= own type= interact

Back to the main topic … In my reading on the privilege elevation topic, most articles circle back to the “allow users to interact with this program” checkbox in SCCM as boyd pointed out or how to bake it into a new program in C#.

I’m with FerrariGuy, a utility that is written using the API M$ provides like PSexec might do the trick.

Another idea … since TEM is based on a PKI system, is there a cryptographic function available where a password (or other sensitive information) could be encrypted using the native TEM PKI. Since the agents already verify signatures, the next logical step would be to allow decryption of data. For example, a custom task is created that calls a cryptographic function that encrypts a pass phrase (much like the license key). Since each agent already has the public key, it could decrypt the sensitive data into a buffer in memory and allow it to be called by perhaps a special variable for the duration of the task. Runas would become feasible in this scenario.

19

(imported comment written by JackCoates91)

FYI, I’ve added a link to this thread to the bug where we track what I hope will someday be called runaslocaladmin.

We definitely want to make this possible to do, but we also feel it’s critical to do so in a secure fashion. I don’t think those goals are incompatible, but they do make for a solution that takes more than a couple of evenings to design.

Thanks,

Jack

20

(imported comment written by SystemAdmin)

Just throwing my 2 cents in…

Personally, there should never be a reason to need to install an application interactively with the user. If you invest in a decent MSI authoring tool (like Installshield AdminStudio), you can create a transform for the “noisy” MSIs. There hasn’t been a MSI yet that we haven’t been able to quietly install (e.g. msiexec /qb /i someinstall.msi TRANSFORMS=someinstall.mst). Taking a little extra time to do this ensures that every PC has that application installed the same way, which makes it easier to support when any issues come up.

For installs that aren’t MSI based, either find out if the supplier has options for it, or worst case you can reauthor (capture) the install and convert it into a MSI.

For applications that require you to be an admin, it’s usually a poorly written or an old app. The app probably needs to write to specific registry keys or folders on the PC that a non-priv user wouldn’t have access to modify. Use a tool like Sysinternals ProcMon to watch what happens when you try to run the app as a non-priv user. Once you determine what needs to be opened up, you can create some custom actions in the transform to take care of the permissions on that.

The last thing you want to do is break your security by allowing users to be admins of their PCs or allowing them to choose options on the installations running under an account with admin rights.

Paul