Groups Policy to assign user to Local Machine Power Users Groups.

  • Thread starter Thread starter KA Kueh
  • Start date Start date
K

KA Kueh

Dear all,

I have a couple of posts previously on this issues. Everyone says use
Restricted Groups in GPO. But I have tried but could not get it working.
Could someone be kind enough to provide me with some step by step guide? I
think my problem is with understanding the subject. Here is what I am
trying to achieve.

1) Domain users are added to local machine as local Administrator group or
Power Users group now. SO it is very hard to enforce consistent policy as
users on some machine can get around GPO since they have local admin power.
I want to standardize so that everyone is only assigned to just Power Users
group via GPO.
2) Remove Users from Administrator group if it has been assigned previously
on local machine.

I try to achieve this via GPO but did not succeed as I tried to follow some
of the instructions. Firstly, there is no such group as "Power Users" in
Windows 2000 AD so I am stumped.

Detailed instruction would be much appreciated. Thank You.

Regards,
Kueh
 
Power users will only exist locally on the clients, if at all.

Create two restricted groups, "Administrators" and "Power Users", and set
their membership appropriately using the upper edit box. The lower edit box
for the "members of" setting won't work in your scenario. After you have
clicked to create the restricted group, instead of clicking the Browse
button to search for the group, just type the name into the edit box and
click ok. This will make it so the group names aren't resolved until the
policy is applied on the client computers. If you use the Browse button,
only the group you selected will have the policy apply to it. I think
that's the trick you're missing.

N
 
Dear Nick,

Thanks. Forgive me as I am a bit slow here. I am trying to follow your
instructions for adding the "Power Users group restriction, When I close
the GPO edit and go backup again I now see that "Group Name" is
"*S-1-5-32-547" is this correct?.

Regards,
Kueh.
 
It's ok, I don't think my description was the best. It resolved the user
into its proper local Sid so that should work fine for power users. It does
sound like you did the right thing when creating the group. Let's see if I
can explain it better though...

You enter the gpedit UI, navigate to Security Settings->Restricted Groups,
right click on the empty area to the right, and select Add Group. Here you
get a window with an edit box and a browse button. Just type in the group
name here, don't use the Browse button. This will cause it to resolve to a
local account. For well known accounts, it will resolve the name to the
well known local sid (like you saw above). For unknown accounts it will
leave the account name as plain text in the GPO which will then be resolved
locally on the clients.

Click Ok. This pops up a window with two list boxes, one above the other,
and an add remove button next to each. The upper listbox is for setting a
group's membership so it only contains the exact members listed in that list
box. The lower one adds the current account you are creating the restricted
group for into the groups specified in the listbox. The functionality you
require is the one in the upper listbox so you'd click add next to that one.
The next screen will give you the same edit box you saw earlier but this
time for adding users into the group's membership. Just like before, just
type in the names as plain text, don't use the browse button.

As you can see, when dealing with local accounts, using the Browse button
won't give you the behavior you expect. The reason is because the Browse
button causes the account to be resolved to its sid immediately. Since that
sid is then stored into the GPO, only the account corresponding to that sid
will be used. This is good when you are adding domain accounts into the
local administrator group, but not for adding local accounts into a local
group.

I hope this helps explain better.

N

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
 
Back
Top