Re: Local admin through group policy and keep admin on local machi
- From: "Roger Abell [MVP]" <mvpNoSpam@xxxxxxx>
- Date: Thu, 22 Mar 2007 20:27:31 -0700
"Kevin Rhodes" <KevinRhodes@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:C9F8B4E1-85BC-498A-954A-7B5D0F583199@xxxxxxxxxxxxxxxx
Thanks for your help Roger!
I think that you understand our situation correctly. When it comes to
implementaion, I am a little confused about how to add members to the
Support
group and limit them only to this OU.
The GPO linked to the OU that contains the set of computer objects
has restricted group def for Support, stating it should be member-of
Administrators (on the computers in that OU)
This GPO states nothing about the members in the group Support,
only that the group Support must be in those computers' Administrators
groups.
The user group is: "Support" and it is a member of administrators
(built-in)
My current GPO for the OU is: Resticted group, "Support"
The member of this GPO is the domain's group: "Support"
If I add user accounts to the domain Support group, they don't have local
admin. You mentioned: "If you want to control the domain accounts that
are
members in
Support, do this in a GPO that has the DCs OU within its scope." Can you
walk me through that part?
Say that you do want to control members of Support.
One might do this with a restricted group definition for Support in
a GPO linked to the DC OU. In this restricted group definition one
would use the "members" list and not use the "member of" list, i.e.
one does opposite of on the OU of managed computers.
If you have multiple different sets of client systems with multiple
different sets of domain accounts for each, then you just end up
with multiple OUs (likely subOUs), multiple GPOs, multiple
SupportA, SupportB, etc. and you might end up with the uber
Support group being a member of each SupportA, SupportB, etc.
BTW-This beta server does not have SP1 or SP2 installed at present.
I have no idea whether this usage of restricted groups works on any
beta version of software - but for the OU of computers, it is the version
of the computers in the OU that is important.
"Roger Abell [MVP]" wrote:
The way I am hearing this is that you need a custom support
group to always be in the machine local Administrators group
on all of a set of machines that you have in an OU, and then,
on some of those machines you also need to have the domain
account of a user of the machine, and this last part differs per
machine.
How I would go about this is via Restricted Group definintion
in GPO for the custom support group, and then adding the per
machine domain account via script (just run at cmd prompt) or
via manual addition if number of machines needing this is small.
To add the custom support group, let us say it is named Support,
a domain group, use a GPO that is linked to the OU and in it
define as a Restricted Group "Support" (yes, not Administrators
but Support, the group to be added to each local Administrators
group). In the Restricted Group definition leave the Members
list empty, and in the Member Of list add Administrators.
If you want to control the domain accounts that are members in
Support, do this in a GPO that has the DCs OU within its scope.
The GPO linked to the OU will make sure that Support is in
Administrators and it will not cause anything that is already
in the machine local Administrators group to be removed.
If you then add the per machine domain account as/where
needed it will stay a member of Administrators. If that domain
user removes Support from their machine's Administrators group
the Support group will be restored as a member as soon as the
GPO is reapplied.
As far as you wanting to immediately refresh policy, it sounds
like you have tried gpudate on the client but not find it to work.
If that is the case it may be that you did this before the changed
GPO had replicated to the DC preferred by that client. Make
sure that you use the /force switch.
Roger
"Kevin Rhodes" <KevinRhodes@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:1E4FAEDB-40EC-4196-8A25-899DA211AF5C@xxxxxxxxxxxxxxxx
I have created a local admin group policy giving a group admin rights
over
an
OU (this is to be for our help desk). Some of our software programs
require
users to have local admin access as well (so I give it to them through
their
domain account on the local PC-I don't want to add them to help desk
group
and give them local admin on all the OU PCs). The problem is that the
following day the admin account on the local PC is automatically
removed
from
the list of administrators. I have this set up in a beta environment so
we
don't have to go to each machine, each day, to add them back in. Any
ideas
on
how to block this? I have tried to turn "no override" on in the GP
options,
but this too disappears the following day. Is there anyway I can speed
up
whatever cycle time it is on so that I don't have to wait a day to see
if
it
works? (I always do a forced update after I make changes). Thanks in
advance.
.
- References:
- Re: Local admin through group policy and keep admin on local machine?
- From: Roger Abell [MVP]
- Re: Local admin through group policy and keep admin on local machi
- From: Kevin Rhodes
- Re: Local admin through group policy and keep admin on local machine?
- Prev by Date: Re: Active Directory Design Question - Delegation and Use of OUs
- Next by Date: Re: Local admin through group policy and keep admin on local machi
- Previous by thread: Re: Local admin through group policy and keep admin on local machi
- Next by thread: Re: Local admin through group policy and keep admin on local machine?
- Index(es):
Relevant Pages
|
Loading
