Solved

Restricted Group not working

Posted on 2007-03-21
15
460 Views
Last Modified: 2010-03-05
I created a group policy to apply Restricted Groups to the local Administrators group on workstations.  My understanding is that once the policy is in place, the local Administrators group will always reset itself to the restricted group membership after a reboot.  My tests prove otherwise.  

Once the worksations reboot, the policy applies and sets the group membership according to the policy which establishes the following members:  administrator, domain\domain admins, domain\techgroup, and domain\anotherGroup.  I log on to the pc as a member of the domain\techgroup and see that the new groups were added correctly.  I remove one of the groups, reboot the workstation, and expect to see that the Administrators group reset back to the original four.  It doesn't.

Another test was to add an individual user account to the local Administrator's group.  It remains after the reboot.  GPResult shows the policy is being read and applied, and RSoP on an XP box shows the policy is a "Winning GPO."  What am I doing wrong?
0
Comment
Question by:kimberlypace
  • 5
  • 3
  • 3
  • +2
15 Comments
 
LVL 10

Expert Comment

by:Phadke_hemant
ID: 18766968
only "administrator" doesn't mean local administrators. you have to add workstation\administrator in the group
0
 
LVL 33

Expert Comment

by:Busbar
ID: 18766970
how did oyu applied the GPO, did you applied it to the machine account?
0
 

Author Comment

by:kimberlypace
ID: 18767436
The group policy works the first time and lists the correct members -- but when I log on to the local workstation and either add or remove a member, the policy doesn't correct the membership after the next reboot.  The policy is linked to an OU that contains the workstations along with a group I created named WorkstationTest which has the workstations as members.
0
 
LVL 10

Expert Comment

by:Phadke_hemant
ID: 18767592
group policy applies only if you are logged on to domain. it will never apply if you are logging on to local machine
0
 

Author Comment

by:kimberlypace
ID: 18767695
you're missing the point.  The workstation is a member of the domain and I am logging on using a domain account.  The GP is configured under computer configuration -- not user configuration and GPResults shows the policy applying.  The local Adminsitrators group is changed by the policy and shows the correctly configured groups the first time the workstation is rebooted after becoming a member the group WorkstationTest.  The problem is:  when I either remove one of the members or add another user/group, the local administrators group does not change back to the original restricted group setting when I reboot.
0
 
LVL 51

Expert Comment

by:Netman66
ID: 18767832
You don't need to add the Administrator (local user) to this policy.  By default it's already present and can't be removed.

Remove that one entry from your Restricted Group membership.

Let us know.
0
 
LVL 77

Accepted Solution

by:
Rob Williams earned 500 total points
ID: 18767919
I assume "the point" is; the policy seems to work properly, but when you manually make a change locally, to the administrators group on the PC, it does not update or change to the restricted group account choices after logging off and back on.

I can't explain why [I'll bet Netman66 can :-) ] but I have noticed on systems that it seems to take up to 36 hours to "repair" itself, back to the accounts you have set within restricted groups. Much more than the usual 90 minutes, even if you run gpupdate, but it does work fine. Have you tried waiting an extended period of time?

If you make a change within restricted groups and run gpupdate, that does seem to be enforced right away.
0
Too many email signature updates to deal with?

Do you feel like you are taking up all of your time constantly visiting users’ desks to make changes to email signatures? Wish you could manage all signatures from one central location, easily design them and deploy them quickly to users? Well, there is an easy way!

 
LVL 10

Expert Comment

by:Phadke_hemant
ID: 18767998
yes on server use gpupdate /force command and then check the reflected changes
for account related changes you may need to restart the worstation
0
 

Author Comment

by:kimberlypace
ID: 18768027
ok -- i removed "administrator" from the restricted group membership -- and did a gpupdate/force.
RobWill you might be right about the 36 hours -- at one point this afternoon two of my workstations did show the correct group membership after a reboot.  I will test again tonight and see what happens tomorrow.  i've also played with load order precedence and Enforce/Yes.
Thanks for the ideas.
0
 

Author Comment

by:kimberlypace
ID: 18768105
3 out of 5 test workstations reset the local Administrators group after a reboot.  Will wait to see what happens tomorrow.
0
 
LVL 51

Expert Comment

by:Netman66
ID: 18770212
They should reset after 90 minutes.  I suspect the addition of "Administrator" was causing the policy to error in the background and stop applying.

If you've removed that entry and machines have reset, you can attempt to alter the admin group again to see what happens.
0
 
LVL 77

Expert Comment

by:Rob Williams
ID: 18771764
For the record, just as an observation; what I have noticed over time is any change to the policy is pushed out to the client machine within 90 minutes or forced with gpupdate, as you would expect.
However, if you manually add a user to the workstation's admin group, without tapering with the GPO, the local admin group on the workstation does not seem to update to your restricted group selections for up to 36 hours, even with logging off and on, or running gpupdate. I must say I don't recall testing a reboot.
Actually I have found this useful. On occasion I have to make a local user an admin to install or modify something. It will maintain the change for me to make the changes and I can then walk away knowing by tomorrow it will revert to my GP options.
Again, not stating this is how it is supposed to function, but rather an observation on some of my networks. 2003 servers by the way.

While on this topic, I always like to note; kimberlypace be careful with what OU's you apply restricted groups. It is possible to lock yourself out if applied to your DC.
0
 

Author Comment

by:kimberlypace
ID: 18774389
Thanks for all the help.  Final result -- rebooting the workstation did not force the computer policies to be reapplied -- but waiting the 90 minutes to xx hours did.  The group reset itself some time during the night.  I tested again, making changes this a.m. and waiting a couple of hours (without rebooting and without gpupdate) and the local Administrators group reset.  I feel comfortable deploying this policy  to all 3000 workstations now.  RobWill and NetMan66 were pretty much right on!
0
 
LVL 51

Expert Comment

by:Netman66
ID: 18776126
Did you mean to split this?

If so, post a Q in Community Support with a link to this Q asking to reopen for a split.

If not, ignore me....
0
 
LVL 77

Expert Comment

by:Rob Williams
ID: 18776396
I am in full agreement with a point split. Please do so !
--Rob
0

Featured Post

Free Gift Card with Acronis Backup Purchase!

Backup any data in any location: local and remote systems, physical and virtual servers, private and public clouds, Macs and PCs, tablets and mobile devices, & more! For limited time only, buy any Acronis backup products and get a FREE Amazon/Best Buy gift card worth up to $200!

Join & Write a Comment

Welcome to my series of short tips on migrations. Whilst based on Microsoft migrations the same principles can be applied to any type of migration. My first tip Migration Tip #1 – Source Server Health can be found here: http://www.experts-exchang…
The password reset disk is often mentioned as the best solution to deal with the lost Windows password problem. In Windows 2008, 7, Vista and XP, a password reset disk can be easily created. But besides Windows 7/Vista/XP, Windows Server 2008 and ot…
With the advent of Windows 10, Microsoft is pushing a Get Windows 10 icon into the notification area (system tray) of qualifying computers. There are many reasons for wanting to remove this icon. This two-part Experts Exchange video Micro Tutorial s…
With the advent of Windows 10, Microsoft is pushing a Get Windows 10 icon into the notification area (system tray) of qualifying computers. There are many reasons for wanting to remove this icon. This two-part Experts Exchange video Micro Tutorial s…

757 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

Need Help in Real-Time?

Connect with top rated Experts

21 Experts available now in Live!

Get 1:1 Help Now