0

I need to re-work our current security model for desktop computers, and would like some insight as to what changes can be made as well as best practices.

Currently we have the helpdesk role that is published via GPO to add it to the local admins group on computers. For users that require to be local admins, we deny their computer access to the GPO and add their account to the local admins group. This poses a problem when our helpdesk staff needs to work on the computer when the local admin user is not present. Former admins (that is, no longer working here) placed the users in the helpdesk role that only needed local admin use on their computer.

We now have 30 power users that are now beginning to realize that they can access \computername\c$ shares.

How can I eliminate the helpdesk/local admin conflict without creating GPOs for every computer account?

Can I disable the local admin shares to a specific group and add our power users to that group or is that not a good policy?

  • Why do you deny the local-admin users the GPO that grants helpdesk access? – paj28 Dec 12 '13 at 16:59
  • We find the GPO overwrites any local rules. That is why we deny the computer to the GPO - so the changes we make do not get overwritten. We have forest functional level of 2008. – AWippler Dec 12 '13 at 18:11
1

This is a perfect example of how Security Groups and the Best Practices concept of Separation of Duties comes into play.

Create security groups for your users, by departmental or functional role - one of those security groups should be something like "Helpdesk-LocalAdmin" (choose something consistent with your own naming convention - if you don't have a standardized naming convention already, it's never too late to establish one).

Create a group policy, call it something like "HelpdeskLocalAdmin", and:

  • Expand "Computer configuration\Policies\Windows Settings\Security Settings\Restricted Groups"
  • In the right pane of "Restricted Groups", right click and hit "Add Group..."
  • Type the name of your Helpdesk Local Admins group, ie: Helpdesk-LocalAdmin and hit 'OK"
  • Click Add under "This group is a member of:"
  • Add the "Administrators" Group.
  • Click OK

Now, for each of your Helpdesk personnel who should be granted Local Administrator account access, add them to the "Helpdesk-LocalAdmin" security group, and the GPO will automatically be applied.

Explanation: Every "privilege" in a networked / computing environment should be "default deny", meaning that users must be explicitly granted access to network / server / application resources. This allows you to very specifically control who has access to what, instead of attempting to later deny those who shouldn't have access and keep track of them.

  • We already have this set up. – AWippler Dec 12 '13 at 18:55
  • ...So what's the question then? Why do you have your GPOs set up backwards like you described in your original post? – Panther Modern Dec 12 '13 at 19:25
  • The GPO overwrites any local changes we make. Is there an option to update that I am not aware of? – AWippler Dec 13 '13 at 18:16
  • Why would you be making local changes, and why are you not managing everything from GPOs in the first place? – Panther Modern Dec 13 '13 at 18:36
  • If you absolutely need to have "power users" log into their machines as local admins then why can you not add the helpdesk-localadmin group to the local admin list too? – Rod MacPherson Dec 13 '13 at 18:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.