Go Premium for a chance to win a PS4. Enter to Win

x
?
Solved

Active Directory - Restricted Groups for individual admin users

Posted on 2007-11-26
9
Medium Priority
?
1,070 Views
Last Modified: 2009-01-23
I am very familiar with how to create GPOs using Restricted groups in order to add groups of users to a local group on a workstation or server... including the difference between the "Members" and "Member of" settings in Restricted Groups policies...

What I am looking for is a suggestion for how to best handle this scenario:
We have 14000 workstations in the enterprise. We use restricted group policies to add particular global groups to the local administrators group on all workstations. Depending on where the workstations are located, and the rights required, some of these policies apply to all machines, and some of them might apply to smaller subsets (several hundred). For example, we might have a global group for "Level_3_PC_Admins" that applies to all workstations, but we might have another group like "Houston_PC_Admins" that should only apply to workstations in the Houston OU (because the desktop support people in Houston don't need admin rights on machines in other locations).

The problem I'm running into is that there are many occasions where I have users that, for various reasons, need to get local admin rights on their own workstation. I don't want to add them to one of the admin groups for their site because then these users would have administrator rights on other workstations in their area.

Since the "Member of" function in the Restricted Groups policy does not apply to users, and only applies to groups... using that functionality means having to create a group which contains only that user, then creating a GPO that makes that group a member of the local administrator group. Then the policy has to be set to only apply to a particular machine.

That is not so difficult, except to consider that if I have a couple hundred requests like this, then I end up with a couple hundred extra groups and policies, which only serves to cause extra bloating and policy processing.

Anyone have another suggestion that can be managed at an enterprise level for when individual users need to have administrator rights only to their own machines?
0
Comment
Question by:dhoffman_98
  • 4
  • 4
9 Comments
 
LVL 30

Accepted Solution

by:
LauraEHunterMVP earned 1500 total points
ID: 20349894
A common concern, and one for which there isn't really a good enterprise answer that I've found.

IF your users are tied to a single PC; i.e., they don't tend to move from one PC to another during the day, best way would probably be through a VBScript that ties onto an Excel spreadsheet or CSV file.  Logic to the effect of "For each computer in ColumnA Row <%h>, add the user in Column B Row <%h> to the local Administrators group.

As you can see that's not exactly long-term manageable, as you'd need to do so anytime a new user/computer comes online, and if you shuffle computer inventory around it can lead to lingering local Administrator memberships that shouldn't still be there.  Anytime I've seen an issue like this on a large scale, it simply gets built into the desktop imaging process - you request a workstation build for user X and the final step in the build process is to add user X to the local admin group.

I'd be interested in other input on this thread, as if someone has derived a more creative solution I'd love to see it.
0
 
LVL 13

Author Comment

by:dhoffman_98
ID: 20349948
Thanks Laura... I was hoping to see a response from you on this, as I have seen your input on similar topics many times in the past, but didn't want to write to you directly.

I do understand what you are saying about using the script, and I have such a script that would work, but because of the manageability of doing it that way, and probably because our auditors would squash that idea, I was hoping to find a better way.

In the long run, it may be possible to have a script that can be centrally located on a SYSVOL share that gets executed by the workstations during startup. The script could call a combination of workstation and user, and then add the appropriate user to the administrator group on that workstation. If a workstation executes the script and it doesn't apply to that workstation, then it shouldn't make a difference. And since the script could be centrally located on the DCs, which are tightly controlled, then perhaps the auditors could be happy with such a solution.

0
 
LVL 30

Expert Comment

by:LauraEHunterMVP
ID: 20349987
It's definitely a tough nut to crack.  The startup script idea has merit since startup scripts run in the LocalSystem security context, thus eliminating the "how do I add a user to the admins group if they're not yet an admin" chicken-and-egg problem with a login script.  The logic could be very similar to what I suggested (maybe add an "if this user isn't already there, add them" error-check), at which point you'd simply need to maintain the XLS/CSV/database/whatever on an ongoing basis.

I've seen some people place the primary username into an AD field of the computer object itself - this would still need to be maintained on an ongoing basis, but then the script could simply query its own computer object in AD rather than tying to an external data file.
0
Get your Disaster Recovery as a Service basics

Disaster Recovery as a Service is one go-to solution that revolutionizes DR planning. Implementing DRaaS could be an efficient process, easily accessible to non-DR experts. Learn about monitoring, testing, executing failovers and failbacks to ensure a "healthy" DR environment.

 
LVL 13

Author Comment

by:dhoffman_98
ID: 20350122
OK, let's follow that train of thought then...
Does a startup script run before GPOs are applied to the computer?
We currently have a top level GPO that uses the "Members" restricted group setting (the destructive one). We did that specifically so that any other scripts or changes that might have been made by someone else with admin rights would get set back to the defaults each time the policy was applied.

So if the startup script runs before the GPOs then the changes would be made by the script, and then the GPO would nullify those changes.

My thinking is that the startup script would have to run AFTER the GPOs since it's in the GPO where you can specify the script to run. And in that case, the GPO can set the standard settings, and then the script can modify them.
0
 
LVL 30

Expert Comment

by:LauraEHunterMVP
ID: 20350176
> "Does a startup script run before GPOs are applied to the computer?"

Startup scripts run synchronously by default, which means that they will run at the same time as the GPO containing them is applied.  See the following for the diff. b/n synchronous and asynchronous processing: http://technet2.microsoft.com/windowsserver/en/library/34b00be7-b5d9-4889-89ba-f0837bb35ff61033.mspx?mfr=true

In the scenario that you're describing, though, I don't believe that there's a predictive way to say "Don't run the script in GPOC until GPOA has finished" - if you run into network latency issues, you could see unpredictable behaviour.
0
 
LVL 13

Author Comment

by:dhoffman_98
ID: 20350276
Well unless someone else chimes in with other ideas, this is already starting to look like more of an administrative headache then.

Aside from turning on the "Wait for network" option (which would probable end up causing issues for remote laptop users expecting to log in with their cached information), there is another possibility...

It may be possible to set some kind of 'flag' that indicates when GPO Processing is complete, and then having the script run a loop until it sees that flag before it processes the list. Once the script is complete, it can remove the flag.

0
 
LVL 85

Expert Comment

by:oBdA
ID: 20353955
Startup scripts won't work here like that. As soon as the "Restricted Groups" GPO is re-applied (about every 90 minutes on a workstation), the user that you added with your startup script will be removed (after all, that's in part what this policy is for: to remove manually added users, and you're adding them manually with the script ...).
Your only chance is another Restricted Groups policy, preferably with the "Member Of" feature.
Oh, and the "Member Of" feature *can* be applied to single users: you're not able to use the object picker to do so, but you can just enter the name of the user directly, and then add the group that the user should be a member of; works just fine (what doesn't work, unfortunately, is the use of environment variables for the user or group name).
0
 
LVL 13

Author Comment

by:dhoffman_98
ID: 20354834
oBdA:

Thanks for bringing that up. Yep, I actually thought about that at lunch today. It was like the light bulb over my head that reminded me... yeah it'll work for maybe the first 90 minutes, and then the policy will revert back again.

I have tried to manually enter user names directly before in the member of setting and haven't had much success with that. I'll give that a test run again tomorrow though to see if that helps at all.
0
 
LVL 30

Expert Comment

by:LauraEHunterMVP
ID: 20354861
That's a very good point, yes - it'd be okay if you weren't using that destructive Member setting in a top-level GPO, but that definitely makes it a less viable option.
0

Featured Post

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Compliance and data security require steps be taken to prevent unauthorized users from copying data.  Here's one method to prevent data theft via USB drives (and writable optical media).
Wouldn't it be nice if objects in Active Directory automatically moved into the correct Organizational Units? This is what AutoAD aims to do and as a plus, it automatically creates Sites, Subnets, and Organizational Units.
This tutorial will walk an individual through the process of transferring the five major, necessary Active Directory Roles, commonly referred to as the FSMO roles to another domain controller. Log onto the new domain controller with a user account t…
Sometimes it takes a new vantage point, apart from our everyday security practices, to truly see our Active Directory (AD) vulnerabilities. We get used to implementing the same techniques and checking the same areas for a breach. This pattern can re…

972 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question