Active Directory - Restricted Groups for individual admin users
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?
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?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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.
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.
ASKER
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.
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.
> "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.
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.
ASKER
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.
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.
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).
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).
ASKER
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.
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.
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.
ASKER
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.