Block gpedit.msc from being run?

raksasas

Limp Gawd
Joined
Dec 14, 2002
Messages
477
Is there a way to keep a spacific user account from being able to get into the group policy editor?

The account I need to block it from has to stay in the administrator group, but I don't want to block it from the Administrator account. I need need to do this because I removed a lot of setting do this account. I thought I made so that they can't change the settings to the taskbar and start menu. I though made it so they can't acess the start menu and task bar settings window but it looks like someone still figured out how to make the taskbar hide. I do not want it to be hidden. First thing I did was look at Run (which I made sure I cleared the run history in the regedit) and i saw gpedit.msc in it.
 
Go into the local policy editor and take away run. That way they can't run anything that you don't give them an icon for. It's under user configuration, administrative templates, start menu and taskbar. Make sure the taskbar is still locked while your in there.
 
Pleeeease do not take this the wrong way. That is the [textbook] wrong way to manage accounts. It is always better to add functionality to a restricted group/account. I say, create a new group, based off of the administrator template, then remove the run setting from the start menu! Save it as DONKEY-GROUP1 and make that account part of the new group.

M
 
Even if you take away run, they can still access it via command prompt -> mmc if they are in the administrators group.
 
I've run into the same problem at work trying to restrict internet access. It would be great if someone knew how. I'm still clueless...
 
screwmesa said:
Even if you take away run, they can still access it via command prompt -> mmc if they are in the administrators group.

or as I've seen, create a batch file on the desktop and execute it.

ebratcher said:
I've run into the same problem at work trying to restrict internet access. It would be great if someone knew how. I'm still clueless...

proxy?
 
We use a proxy server but users are able to bypass the proxy by changing setting under Tools>Internet Options>Connections Tab>Lan Settings. Using gpedit you can disable changing the settings but we believe some users have figured out how to use gpedit
 
Ah, of course, and they need to stay as admins right... interesting...

could you deny execute permissions to everyone except the local admin to the file \system32\mmc.exe ??

just a thought...
 
Why do they HAVE to be admins? I'd quit my job 5 seconds after that became a corporate policy. I will NEVER give our users Admin on a box, and I'd like to hear what line of work your users are in that require them to be admins. I work in a financial setting, and I can't count the number of times the Federal Reserve has told me that one of their programs wouldn't work unless I made them a local Admin. After grilling them, I ask for their supervisor and then proceed to chew them a new one. Then it's off to development where I can then get the list of files/directories that I need to grant my user access to.

Giving a user local admin rights is like handing a road flare to an epileptic guy in a fireworks factory; sooner or later something's going to blow up.
 
typhoon43 said:
Giving a user local admin rights is like handing a road flare to an epileptic guy in a fireworks factory; sooner or later something's going to blow up.

lol, so true :p
 
We want to restrict the ability to edit group policies in Active Directory to a subgroup of domain admins (e.g., the senior administrators). All administrators still need be members of domain admins for completing other administrative tasks, except that the junior administrators will not be allowed to edit group policies. How do I go about achieving this?

As you know, by default domain admins have the right to create group policy, manage group policy and modify GPO links. Additional users can be given the right to create and manage their own GPOs by adding them to the group "Group Policy Creator Owners Group." However, to restrict administrators, you must take a different tack. Two possible approaches are:

* Prevent some administrators from using group policy administration tools. Place admins you want to restrict in an OU (organizational unit) on which you create a GPO and restrict access. An administrative template property that can be used is the "Administrative Templates, Windows Component, Microsoft Management Console." The setting "restrict the users to the explicitly permitted list of snap-ins" allows you to prevent admins from loading administrative tools in an MMC (Microsoft Management Console). The item "Restricted/Permitted snap-ins"' folder lists the tools for you to check. You can easily check those that cannot be used to modify group policy. Your admins can thus manage the items they need to, but cannot open group policy MMCs. You can further restrict junior admins by creating custom MMC consoles for tasks you want them to do, and then also set the "Restrict the user from entering author mode if applicable" setting in the GPO. This setting prevents users from creating MMC consoles and adding tools that they wish to use.

* Modify permissions. This is a more complex undertaking. Two approaches are possible. In either, you start by creating a special group for junior admins and including their accounts. Then you must either remove them from the domain admins group, and give this new group the administrative access they need, or leave the admins in the domain admins group and use the "deny" permission on object access in Active Directory to prevent them from doing the things that you don't want them to do. One possibility here might be to deny them the right to work with GPO links. As you know, a GPO is created and linked to a site, domain or OU container. If an admin does not have the ability to link a GPO, he effectively cannot not create them. You then must set permissions on existing GPOs to prevent junior admins from changing them.

In either case don't forget to create written polices that specify what the junior admins can do and cannot do. Include the penalty for attempting or doing the things they shouldn't. Make all aware of these restrictions. You can enforce the policy using the methods described above (don't forget to test your solution) but ultimately, if a way can be found around it, sooner or later someone will. If the policy is clear, and you monitor their activity, then you can better deal with it. And, I have found, that when everyone knows the rules and the consequences, less people express their curiosity. Oh, I agree, traffic laws don't prevent everyone from running a red light, but they do keep most people in check. What if no one knew the rules?
 
typhoon43 said:
Why do they HAVE to be admins? I'd quit my job 5 seconds after that became a corporate policy. I will NEVER give our users Admin on a box, and I'd like to hear what line of work your users are in that require them to be admins. I work in a financial setting, and I can't count the number of times the Federal Reserve has told me that one of their programs wouldn't work unless I made them a local Admin. After grilling them, I ask for their supervisor and then proceed to chew them a new one. Then it's off to development where I can then get the list of files/directories that I need to grant my user access to.

Giving a user local admin rights is like handing a road flare to an epileptic guy in a fireworks factory; sooner or later something's going to blow up.

So true. These are just local machine they are not on a network Because they are located in police cars so accessing data other then what is locally isn't really a problem which word, and 2 programs called Ileads, Imobile.

Now the admin issue. I really don't want to give them admin rights to the machine at all. But the only way I can get the 2 programs to run right is to give them admin rights. I have tried putting them down to Power users and giving them full access to those folders for them. The two programs will not fully function under even power users.

The Ideal way to fix this is to build a new local group based off the admin template which has been said. Which is fine, if this in a good setting I would build the group and make am image of the laptop and put on all the laptops. But all the laptops in the are not the same model. We run about 5 different models of CF-28s, CF-29's. Each model has it's own set of drivers. that means making 5 images or so. and taking the time to build the group from scratch 5 times or so. This I do not have time to do. Now, if I could just make the group on one of the models then copy the group and paste them on to the other laptops. That would save a lot of time. So basicly the fastest way to do it is just give them admin rights locally though it's not the smart way. (Note: all the models run the same software, XP, Word, Ileads, Imobile. Only difference is the drivers)

Let me state this again. These machines are not part of a DOMAIN!!

I hope this sheds a lil light on my situation.
 
Back
Top