Active Directory - Restricted Groups for individual admin users

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.

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.

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?"

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.

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.

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).

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.