Not allowing user to install software

loss4words

Hi guys,

I've been trying to figure this out on my own but I think I need your advice I have several PCs on which I'd like to prevent users to be able to install software and just use whatever comes pre-installed on the image. All computers run Windows XP and are in the same OU. Is there a group policy I could enable or anything else I could do to achieve this?

Thank you and sorry for the newbie question

phoeneous

Easiest way is to make sure they are not a member of the local admin or power users group. If you want to use gpo, look at software restriction policies.

loss4words

Thanks phoeneous. I made sure the user is not a member of local admin or power user group. Group "Domain Users" is, though, part of local Administrator group and the account that I don't want to be installing software is part of domain users group. Could this be why I'm running into this issue?

Sorry for being such a newbie

Jack2

loss4words wrote: »

Thanks phoeneous. I made sure the user is not a member of local admin or power user group. Group "Domain Users" is, though, part of local Administrator group and the account that I don't want to be installing software is part of domain users group. Could this be why I'm running into this issue?

Sorry for being such a newbie

Thats is why your users can install whatever they want.

What is the organizational policy on users having Administrative rights?
Do you have the direct authority to set this policy in place? If you do, great!

If you don't, document your case and get it approved. Then get it IN WRITING from above that there is an approved policy and that you have been asked to implement it for the BENEFIT of the company.

This configuration is far from ideal and setting up some type of control is recommended practice.

Setting up a controlled environment can be difficult, develop a thick skin and wear a flack jacket.

In the long run you will have PCs that run better with out extra Cr*p being installed on them.

Been there, Doing that....

loss4words

Jack2 wrote: »

Thats is why your users can install whatever they want.

What is the organizational policy on users having Administrative rights?
Do you have the direct authority to set this policy in place? If you do, great!

Thanks for your adivce, Jack2.

The computers in question share one generic domain account that users log in to. There are other domain users in the organization that do need administrative rights on their computers, most users in fact, and maybe that could be the reason why this was set up this way? In any case, I just wanted to limit this one particular domain user account that people use to log on to computers located in one specific OU. I do have access to group policies at the OU level but not at domain level so I was hoping there was something I could do before I elevate this request to higher folks.

Thanks again

phoeneous

loss4words wrote: »

Thanks phoeneous. I made sure the user is not a member of local admin or power user group. Group "Domain Users" is, though, part of local Administrator group and the account that I don't want to be installing software is part of domain users group. Could this be why I'm running into this issue?

Sorry for being such a newbie

That is exactly why.

You should look into creating an Acceptable Use Policy too, a document that defines what users can and cannot do.

phoeneous

loss4words wrote: »

The computers in question share one generic domain account that users log in to.

That is a terrible practice, difficult to audit and no accountability.

loss4words

phoeneous wrote: »

That is exactly why.

Thanks, phoeneous. Is there anything I can do without removing "domain users" group from local admins group to restrict this domain account from installing stuff? I beleive this group membership is being pushed down with a policy that is beyond my control.

There must be a reason why System Admins at my work place decided to do this. I think most likely it's because most people at my job do need administrative rights on their computers and it's only a fraction who don't.

Thanks guys for your help.

That is a terrible practice, difficult to audit and no accountability.

I guess I should explain why this was decided . We have several computer labs and people who have access to the building may freely go into these labs and use the computers. Since we have a large number of people walking in and out it was decided to make one generic account instead of creating many indivdual domain accounts, and have it configured for autologon so that these users won't need to type in username/password. I'm not sure if this is a good practice, but it is what it is.

RobertKaucher

loss4words wrote: »

There must be a reason why System Admins at my work place decided to do this. I think most likely it's because most people at my job do need administrative rights on their computers and it's only a fraction who don't.

More likely it is because they are lazy more so than there is an actual need to users to have local admin permissions. As a very lazy person, I can recognize the symptoms myself.

loss4words wrote: »

I guess I should explain why this was decided . We have several computer labs and people who have access to the building may freely go into these labs and use the computers. Since we have a large number of people walking in and out it was decided to make one generic account instead of creating many indivdual domain accounts, and have it configured for autologon so that these users won't need to type in username/password. I'm not sure if this is a good practice, but it is what it is.

You can be sure it is not. This will cause, in the long run, more support calls and sequellae such as what you are dealing with now. As a truely lazy admin I would limit users to only the rights they need to have. But since someone else is apparently dealing with these issues, the risk vs. reward ratio is clearly in favor of allowing users to be local admin. Meaning if I make the choice, but you deal with the consequences, I will choose what seems easiest for me.

Where I a student with ill motives this is what I would do:
1. Check the registry to get the password for the common account.
2. Make a batch file that added this common user to the Domain Admins group. I would also ensure that this batchfile copied itself to the Startup folder on all PCs in the domain. Requires a 2 line batch file.
3. Since I am a local admin I would then do something that caused some sort of issue and would require helpdesk or an admin to logon.
4. Wait until the common account is eventually added to the domain admins group and then have lots of fun.

MentholMoose

loss4words wrote: »

Is there anything I can do without removing "domain users" group from local admins group to restrict this domain account from installing stuff?

If it ever comes to that, watch out. Removing admin rights from an account causes major problems for user profiles, so the profiles will probably need to be wiped and recreated. At least that was my experience at a previous job where I cleaned up a similar mess. My situation was not as dire, though, since users had been given admin rights only to their own PCs, rather than everywhere.

RobertKaucher wrote: »

More likely it is because they are lazy more so than there is an actual need to users to have local admin permissions. As a very lazy person, I can recognize the symptoms myself.

Honestly I think it is worse than just laziness. If Domain Users are in the Administrators group of all machines, then besides being able to do anything to any machine while logged on locally, anybody can also do anything to any machine remotely. Employees can snoop on other employees, such as checking the browser cache or history, or they can copy confidential financial documents, all remotely.

Also, if any user has a weak or easily guessed password, or no password at all, then anybody that can get credentials and can somehow get on the network can do anything they want. If users really must have admin rights, then give them admin rights to ONLY the machines they need, since chances are the guy in shipping and receiving or the new intern don't need admin on the machines used by the CEO or IT staff. If that is too advanced, then add interactive users to the administrators group, which at least prevents some of the remote vulnerability.