Software installation wihtout Admin rights

[MFuhge]

Hi,
we have a big problem here with some of our notebook users. They need to be able o install software, when they visit a customer for example, but they must not get Admin rights.
They must not be able to change he owner of directorys and some oher scurity related problems would occur, if they get Admin rights.
What to do?

 

[jrbarnett]

Hi,

Some software packages can be installed with Power User level rights - but not all.
I would set up a power user account on a test box and try and install some of the software packages and see what happens.

John

 

[MFuhge]

does anyone know, which rights you get by that?

 

[jrbarnett]

Hi,

This is not a full list but here goes:

Power users cannot take ownership of files/folders, change access rights they don't have full control over, install services, change swapfile settings, decrypt data held on EFS partitions belonging to other users, access hidden administrative shares from remote machines (eg the C$, Admin$) or adjust the system clock.

Perhaps somebody else has a complete list somewhere, plus also the different rights that a user has to a power user/administrator.

John

 

[euston]

Some software installation requires such registry changes that oblige the installer to be administrator or have admin rights.

 

[MFuhge]

Thank you for the infos!

We will try the power users and if possible I will adjust the rights in the registry when needed. I will do it by monitoring access with the tools from sysinternals.

 

[bcastner]

Make them local Adminitrators to the laptops, and let them install anything they want in a local console session.

 

[MFuhge]

@bcastner
-They will get access to all files on the Notebook, also the profiles of other users.
-They can access security related parts of the registry
-All "easy" attacks on AD I know so far (I'm no pro for that) need local Admin on one of the AD machines
-It would be far too easy to place malicious programs / viruses / trojans on the Notebook

I would do it, if I get them out of AD. But that's not possible :/.

 

[bcastner]

Read a little more about NTFS permissions. The local Administrator is not a Supreme Being on the local machine. These permissions apply no matter whether they are making a logon to an AD Domain or a local console logon. You will note that even Domain Administrators do not have by default access to the datastores of local profiles.

In addition the ACLs of the registry are not changed by a local console logon.

And finally, the local profile is not the same as the Domain profile for the user.

Is there a security risk or virus risk? Yes of course there is. You are using a portable computer at sites that are outside of your control. But consider your original problem statement, in part: "Hi, we have a big problem here with some of our notebook users. They need to be able o install software, when they visit a customer for example.." In this situation it seems reasonable to use the feature of the local security context; and to have the protection of the Domain security context back at the home office.

For example, the local context is used to install software at the customer site. The Domain context is more restrictive. When the user logs on to your Domain in all likeliehood the software will refuse to run in the more restrictive security context.

This is the reason that MS recommends permitting the local user/owner to retain local Administrator rights. They can use the machine in both security contexts.

Trying to monitor a software installation using sysinternals tools is a good idea. Unfortunately, many softwares create and use registry entries while active and not just during installation. It does not seem to me an extraordinary risk to allow the user to install in the local security context.

 

[bcastner]

You might also benefit by using Greg Palmer's RUNAS wrapper. Essentially this just protects the sensitive RUNAS permission information with a visual basic wrapper to use the native RUNAS facility with higher priviliges.

See the discussion by Greg yesterday: thread779-676827