Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have several GPOs set up on our domain at work, in one GPO I have the group set to be Local Administrators via the Restricted Groups feature. However, when one of the users in this group logs in to one of the computers on the domain they are unable to make Administrative changes such as installing and removing programs. I double checked the GPO and everything seems to be set up right. The GPO is linked and is set to enforce the policies.

Update: When I login on a client computer and run gpresult /z I get this:

The following GPOs were not applied because they were filtered out

Technology Department Configuration
    Filtering:  Not Applied (Empty)

Local Group Policy
    Filtering:  Not Applied (Empty)

Why does it say it's empty? Am I forgetting something? I'm looking at all the GPOs that we have in our domain and there are 5 total with each one only being applied to specific groups. These users are in the Technology Department group and are only linked to a single GPO. I don't see where something could be conflicting? The only filters that this group has is they are added to the Remote Desktop Users group, the Allow log on locally, to the Allow log on through Terminal Services, and was set up to the a Local Administrator via Restricted Groups.

share|improve this question
add comment

2 Answers

Restricted Groups gpo's apply to computers, not users. If you want to use a Domain security group to specify which computers the gpo should apply, the computers in scope need to be added to that Domain security group.

share|improve this answer
    
If it applies to computers then why is it that when I try to add a new group to Restricted Groups it restricts me to just adding Security Groups and not computers? –  RandomlyKnighted May 31 '13 at 0:58
1  
@RandomlyKnighted You add a security group to a restricted group, and then that security group becomes part of the group on the local system (i.e. Administrators). The policy has to apply to the OU (either directly or via inheritance) that the computer is a member of. There's a Youtube video here that might help you. –  Bryan May 31 '13 at 7:21
    
I watched that YouTube video and I don't have a OU with the computers listed like he does. All that is listed is my GPOs. –  RandomlyKnighted May 31 '13 at 12:20
    
@RandomlyKnighted: The GPO can be linked anywhere, even the top of the domain, as long as the computers for which the GPO is applying is somewhere under where the GPO is linked. –  Greg Askew May 31 '13 at 15:53
1  
If the GPO is linked at the domain and the GPO Apply permission specifies either: Authenticated Users, Domain Computers, or a Domain security group that the computer is a member of, the GPO should take effect on the computer. –  Greg Askew May 31 '13 at 20:20
show 1 more comment

Things to check:

  • Log on to the client and run the command gpresult /z and ensure that the policy is being applied to this computer. - If not, you've either got your policy linked to the incorrect OU, or the policy is scoped such that it isn't being applied to the client (i.e. filtered by group membership). There is also a GUI in GPMC (which will be installed on a DC) that allows you to do this.
  • Check the event logs of the client you are expecting this policy to take effect. Are there any errors?

Your question states that one user doesn't get admin rights when they log on, which kind of implies that other users do? Have other users actually tried on this very computer? If so, and other users do get admin rights as expected, is this configuration within the same policy? If so, double check group membership. Again, check event logs, as this is likely to offer some major clues as to where the problem is.

As a side note, you shouldn't normally need to enforce policies, unless you have conflicting policies higher up in the pecking order. Policies are applied in the following order. Local, Site, Domain, then the OUs (starting at the root) that the computer/user is a member of, with the last applied policy overriding any previous conflicts, unless of course you use the 'enforce' setting, in which case, the first applied 'enforced' setting will win.

It's difficult to know where the problem lies from the information you've provided, but if you can edit your question to add some more details, demonstrating what you've checked (and found), that will help us to provide a better diagnosis.

share|improve this answer
1  
GPO application is LSDOU, not LDSOU. Also when multiple GPO's are enforced and these GPO's set the same settings the GPO furthest from the client takes precedence. –  joeqwerty May 30 '13 at 19:01
    
@joeqwerty +1 for spotting the deliberate mistake. Corrected, thanks. –  Bryan May 30 '13 at 19:06
    
Glad to help... –  joeqwerty May 30 '13 at 19:10
1  
You can also try running rsop.msc on the end-machine to get a graphical view of what policies are applying. You'll be able to see if there was an error applying the Restricted Groups setting or if another GPO took precedence. –  Kasius May 30 '13 at 19:23
    
I updated the original question. –  RandomlyKnighted May 31 '13 at 0:01
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.