• RSS
  • Twitter
  • FaceBook

Security Forums

Log in

FAQ | Search | Usergroups | Profile | Register | RSS | Posting Guidelines | Recent Posts

*Update* How to: Setup Restricted groups local admin rights

Users browsing this topic:0 Security Fans, 0 Stealth Security Fans
Registered Security Fans: None
Post new topic   Reply to topic   Printer-friendly version    Networking/Security Forums Index -> Exchange 2000 // 2003 // 2007 & Active Directory

View previous topic :: View next topic  
Author Message
imageblur
Just Arrived
Just Arrived


Joined: 10 Aug 2009
Posts: 0
Location: Oklahoma

Offline

PostPosted: Wed Aug 12, 2009 7:06 am    Post subject: *Update* How to: Setup Restricted groups local admin rights Reply with quote

because i dont like one of the admins here I have delete my post for this, google search it:

How to correctly use "Restricted Groups" to give a domain user local admin rights to a client pc.

you should find it on one of my sites

Surprised Twisted Evil Very Happy


Last edited by imageblur on Thu May 12, 2011 8:06 pm; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website
slym
Just Arrived
Just Arrived


Joined: 03 Sep 2009
Posts: 0


Offline

PostPosted: Thu Sep 03, 2009 11:18 pm    Post subject: Reply with quote

Thank you, thank you, thank you! What a great tutorial!

If you revisit this post, I have a couple of questions for you - if I want my techs to have admin rights on all computers in the domain, do I still need to move the computers to the OU I created? Couldn't I just create a security group in that OU for the computers?

And assuming I do (because we are using the computer config settings?), that doesn't effect any other use or policy?

Thank you again!
Sue (trying again on the correct post)
Back to top
View user's profile Send private message
imageblur
Just Arrived
Just Arrived


Joined: 10 Aug 2009
Posts: 0
Location: Oklahoma

Offline

PostPosted: Fri Sep 04, 2009 6:39 am    Post subject: Reply with quote

You could use a security group instead of moving all of the computers into the OU. In our case we have moved the computers so that at a quick glance we know who is in our OU, it is a matter of preference. However if the security group gives you problems (every network has it's own quarks) Moving the computer accounts into the OU is your best bet.

Either way, moving the computer accounts into the OU or creating a security group containg the computer accounts placed in the OU will not affect the basic users policy. In most cases the basic users are getting their policy from the default domain policy.
Back to top
View user's profile Send private message Visit poster's website
AdamV
SF Mod
SF Mod


Joined: 06 Oct 2004
Posts: 24
Location: Leeds, UK

Offline

PostPosted: Sun Sep 06, 2009 5:38 pm    Post subject: Reply with quote

You simply don't need the OU at all, but as you say it can make this easier if you are trying to apply the setting to only a selection of computers.
To apply it to all, simply add a new policy linked to the domain, or an existing OU which contains your computers.
You can put the security group anywhere you like, it does not affect the way the policy works.

One advantage of all this that you don't really mention (you talk about how to do this, but not why) is that it means you can easily control who has local admin rights simply by adding and removing them from a single AD security group centrally, and this will take effect from their next logon (when their security tokens are evaluated).

As far as I can see, step 16 tries to make the group a member of itself - I can't see that achieving anything useful.

Step 17 seems to make the user a member of domain admins, which means they can do all sorts of unwanted things - and automatically makes them a member of the local admins group on other machines, remotely. Probably gives them the ability to log on to lots of servers too (eg through Terminal Services), run nasty scripts to disable everyones accounts or change their passwords. All told, a very bad plan. I cannot imagine why you would want to give this access to anyone this way rather than through postively choosing to add a dedicated admin account to the Domain Admins group explicitly.
Back to top
View user's profile Send private message Visit poster's website
imageblur
Just Arrived
Just Arrived


Joined: 10 Aug 2009
Posts: 0
Location: Oklahoma

Offline

PostPosted: Mon Sep 07, 2009 7:43 pm    Post subject: Reply with quote

To AdamV

If you can read!

Please read my post again and try not to be a dumb ass.

thanks

Smile


P.S.


People that are real admins can really use this and know what they are wanting to accomplish with this.

I will try to say this as slow as possible so you can understand

W E A R E A D M I N S T H A T H A V E " D E S K T O P

S U P O R T " G R O U P S T H A T N E E D T O A C T L I K E

A D M I N ' S O N L O C A L C O M P T E R S

This does NOT give admin rights to the domain or the domain controllers!

If you are that fucking paranoid about security to a local computer your a fucking douche and I will give you $20 bucks for new paddles to your douche canoe fund.

WE ARE GIVING RIGHTS TO PEOPLE WE TRUST, THAT IS WHY THEY ARE GIVEN THESE RIGHTS!


Razz
Back to top
View user's profile Send private message Visit poster's website
Ignatius
Just Arrived
Just Arrived


Joined: 07 Jan 2009
Posts: 0
Location: Leeds, UK

Offline

PostPosted: Mon Sep 07, 2009 8:21 pm    Post subject: Reply with quote

imageblur wrote:

Please read my post again and try not to be a dumb ass.

Whoa!
Back to top
View user's profile Send private message
AdamV
SF Mod
SF Mod


Joined: 06 Oct 2004
Posts: 24
Location: Leeds, UK

Offline

PostPosted: Tue Sep 08, 2009 3:43 pm    Post subject: Reply with quote

OK -1 for style points in calling a forum moderator a dumb ass.

Let me be clear
I have myself written many times on this subject as to why restricted groups are a good way to do this. I was merely trying to point out that you can achieve everything you describe a lot more simply by adding the group to the local admins on selected machine manually - so the point of this method is about ongoing central control.

If you don;t want to give people access to the domain or domain controllers, why would your method include a step to add the desktop admins group to the domain admins?
You clearly don't have a proper understanding of how this works or you would not be needing or wanting to add people to the domain admins group as part of your bizarre little step by step guide. It serves no purpose since the local security process does not have the authority to do that (it can and will only alter the local group memberships), so they are simply not added to that group despite you setting it in a policy.

Also, I frankly don't give much of a stuff who you trust or how much, if you are advocating logging on and having local admin rights as a matter of normal day to day practice, you are nuts. If on the other hand you are talking about a select group of people having an extra account which is not their normal one and which they can use to log in to do support work, I can see this makes sense. This is again why I thought you might like to clarify what you were intending to achieve with this.

In the end you have written an article in a very simple step by step way, clearly aimed at an audience who don't already know how to do this. To do them a fair service you should explain when and how they would best use this to get the benefit without opening a security hole across their entire network. Failing to do so does them a dis-service.
The people that already understand the benefits and risks of this are not the people who will read this article, they (like me) are the ones already doing this.

Incidentally, a really useful group to add people to if you don't want them to have full local admin rights can be the "network configuration operators" group. This gives people the ability to change network settings, and use ipconfig /release | renew which they otherwise can't on XP. Again, this would be for trusted or trained individuals but can be helpful.
Method is similar to yours.
Back to top
View user's profile Send private message Visit poster's website
Tom Bair
SF Boss
SF Boss


Joined: 10 Aug 2002
Posts: 16776955
Location: Portland, Oregon USA

Offline

PostPosted: Tue Sep 08, 2009 9:27 pm    Post subject: Reply with quote

Attention imageblur:

This type of rebuttal is not allowed on this site. I will allow it to pass this time, but any future occurances of not being a gentleman will get you banned by myself.

Leave out the name-calling, bad language, and smart-ass comments as they are not enjoyed by the community-at-large. PLEASE continue to share the knowledge you have, and strive to comment in a civil manner to any rebuttals which may occur.

Thank you,

Tom
Back to top
View user's profile Send private message Visit poster's website
slym
Just Arrived
Just Arrived


Joined: 03 Sep 2009
Posts: 0


Offline

PostPosted: Fri Sep 11, 2009 6:30 pm    Post subject: Reply with quote

Quote:
The people that already understand the benefits and risks of this are not the people who will read this article, they (like me) are the ones already doing this.

First I would like to say AdamV's comment above is a tad bit unfair. I fully understand the implications and risks but have not worked with restricted groups before. We all have to start somewhere. If the issue is with the domain admin rights, please let me know how to accomplish this.

I followed the steps as written with 2 exceptions:

I moved the users to the new OU instead of creating a group. The reason for this is they were previously in OU's with a lot of restrictions and thought it would conflict.

I didn't move the computers - just created a security group for them in the new OU.

End result, the Builtin\Administrators was not listed in user settings in gpresult.

I don't want to get involved in the above argument, but if anyone can help me get this accomplished, I would really be grateful.
Back to top
View user's profile Send private message
slym
Just Arrived
Just Arrived


Joined: 03 Sep 2009
Posts: 0


Offline

PostPosted: Fri Sep 11, 2009 6:34 pm    Post subject: Reply with quote

I'd like to add - my goals of this:

I have 3 users that will be student techs to install software, do updates, etc. If I didn't trust them, I would not be doing this. However, I will also be watching them.

I do not want them to have access to the domain controllers.

Thanks again!
Back to top
View user's profile Send private message
AdamV
SF Mod
SF Mod


Joined: 06 Oct 2004
Posts: 24
Location: Leeds, UK

Offline

PostPosted: Sat Sep 12, 2009 10:36 am    Post subject: Reply with quote

The policy applies to the computers, as it is the local group on the computers which is affected.
So, you need to create and link the policy somewhere that contains the computers you would like it to take effect on.
If you need your techs to be able to easily get admin rights on any computer, then do this on an OU which you can put all your computers in (or where they can be in sub-OUs such as laptops, desktops etc where you might want to have other policies which are different for different situations).
Note: you can't link a policy to the default built in computers container, as it is not an OU.
Ideally, don't link the policy to the domain or you will be giving these same rights to anyone that is able to get physical access to a server and log on to it (if they are not blocked from doing so by some other policy). It is always good practice to keep policies for servers and desktop/laptop computers separate.

So slym, you need to put the computers in your new OU, not the users. It should not matter which OU the users are in - unless they have really restrictive policies applied (like preventing interactive logon for example) then you should have no problem. The computers must be in the OU the new policy is linked to - you can't push a policy out via a group, only an OU, site or domain.

Your techs need to be in a security group which is the one you will add to the local admins group.
This group can be anywhere you like in the domain, it makes no difference to group policy at all - having the group in the same OU the policy is linked to can be useful so you keep track of the relationship, but is not necessary for practical purposes. You may be better off putting the group in an OU which has restricted permissions to prevent unauthorised additions to the group membership.

The only point with the domain admins is really that it is not needed for the solution to work, so you can simply omit that step (17).
Once you have your policy set up, you need to reboot the relevant client computers, or do a command prompt "gpupdate" with an account that already has local admin rights (a reboot may be simpler).

You should be looking for the policy to be applied as a computer setting in gpresult.
Equally if you log on as one of the tech users, you can use "whoami /groups" to see their group memberships (on Vista and Windows 7, for this to work on XP I think you have to find the exe on a Windows Server 2003 machine and copy it to the local machine, it's a while since I did this bit so you might want to do a quick Google for "whoami on XP").

As a matter of good practice, you should really be giving the techs a second user account specifically for this purpose, so instead of logging on as "slym" you would log on as "slym-admin" or whatever, when you know you will be doing things that need local admin rights. That way you are not using an admin account when doing normal daily things like email and web browsing. These admin accounts are the ones you would put in your desktop_techs group.
Back to top
View user's profile Send private message Visit poster's website
slym
Just Arrived
Just Arrived


Joined: 03 Sep 2009
Posts: 0


Offline

PostPosted: Wed Sep 16, 2009 12:24 am    Post subject: Reply with quote

Thank you for the reply. Here's my progress on this:

I moved all computers to an OU, with sub-OUs such as student labs, staff computers, member servers.

I kept the techs in the separate OU that I created because the original student OU policy restricts them pretty good. There is also a security group with the student-techs in it.

I created a policy and in restricted groups, added the student-tech security group, and added administrator to the "this group is a member of". I did not add the domain admin.

I linked this policy to all the sub-OU computer groups, with the exception of the member server OU.

Result - success. They can now do things like windows update.

Interestingly though, both the computer settings and user settings say builtin\administrator. You indicated that the computer settings should say that, but when I was trying before and the user settings didn't show builtin\administrator, they couldn't run windows update. Now that it is in both, they can run updates. Is that normal?

I plan to implement your suggestion of creating two logins for these students, one admin and one regular for everyday use.

My next question, logged in as one of these users, I can browse to the domain controllers using \\servername\c$ and access the hard drive. Even though this policy is not linked to the domain controllers at all. How do I lock that down?

Thank you for all your help!
Back to top
View user's profile Send private message
AdamV
SF Mod
SF Mod


Joined: 06 Oct 2004
Posts: 24
Location: Leeds, UK

Offline

PostPosted: Wed Sep 16, 2009 2:15 pm    Post subject: Reply with quote

Glad it's working.
You should see the policy setting against computers, but I can't really see why you would see it against users as a policy setting. Maybe an oddity of how restricted groups actually applies. I'll do some testing on this.
You should see the group membership listed against users if you do a whoami /groups, this is what you would check to see it is working. Is this what you mean?

To fix the browsing to an administrative share problem:
Change the share permissions on the DC so that the drives are not shared to anyone at root level (bad practice on ANY server, especially a DC), other than possibly to Domain Admins.
You need to make sure that shares like netlogon are still available though, so don't go changing NTFS permissions and cascading them all the way down or you could break logons and group policy very quickly.

Also make sure these tech users have not been added to any other domain groups that could be providing this access.
Back to top
View user's profile Send private message Visit poster's website
slym
Just Arrived
Just Arrived


Joined: 03 Sep 2009
Posts: 0


Offline

PostPosted: Tue Sep 29, 2009 10:31 pm    Post subject: Reply with quote

Thanks for the info - sorry I was so long in getting back to this. The email alert got caught in our mail filters.

I'm not sure I understand you about changing the share permissions. The C drive on the DC is not shared, except through the "default share" and that does not allow you to change permissions. Is there a workaround for that?

Thanks again!
Back to top
View user's profile Send private message
dhazar
Just Arrived
Just Arrived


Joined: 23 Oct 2009
Posts: 0
Location: Provo, UT

Offline

PostPosted: Fri Oct 23, 2009 8:55 pm    Post subject: Reply with quote

Here is a post I created on Restricted group design. I use this method to set up all the machines in my organization so that I can easily assign rights to groups of machines without having to do it on the machines.

http://davidhazar.blogspot.com/2009/10/active-directory-group-policy.html
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   

Post new topic   Reply to topic   Printer-friendly version    Networking/Security Forums Index -> Exchange 2000 // 2003 // 2007 & Active Directory All times are GMT + 2 Hours
Page 1 of 1


 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Community Area

Log in | Register