Click here to get back home

Delegate Control to rename and add/remove computer from domain

 HomeNewsGroups | Search | About
 microsoft.public.windows.server.security    Post an article   get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content
Subject Author Date
Delegate Control to rename and add/remove computer from domain Flash3200 02-27-2007
Posted by Flash3200 on February 27, 2007, 4:05 pm
Please log in for more thread options
I want to delegate control to our Desktop Support group to be able to
add computers to the domain and also be able to rename computers
already on the domain. It is as easy as just giving them the rights
to create objects and delete objects for the computer objects? There
are a ton of possibilities of what they can do to computer objects but
most don't appear to apply. Anyone gone through this already?

Thanks


Posted by Roger Abell [MVP] on February 28, 2007, 8:33 am
Please log in for more thread options
>I want to delegate control to our Desktop Support group to be able to
> add computers to the domain and also be able to rename computers
> already on the domain. It is as easy as just giving them the rights
> to create objects and delete objects for the computer objects? There
> are a ton of possibilities of what they can do to computer objects but
> most don't appear to apply. Anyone gone through this already?
>

No, it is not quite that simple.

(First, as an aside, I would highly recommend that you adopt a
practice of defining groups to which delegations are made, and
name them well so that they are clearly existing for use only in
that (set of) delegation(s). Then, put the groups of those that
should hold the delegation in this new delegation group. It can
become very, very difficult to unravel delegations in the grants
on the delegated objects at a later date if you do not approach
this with a plan that you do keep using consistently).

Why is it not that simple?
For example, computer objects get created in a default location
(which, if the domain is at W2k3 functional mode you can adjust)
and they may need to be granted ability to move computer objects
from there to OUs, or between OUs, etc.. Yes, you could require
that they precreate computer objects in the correct OUs, but believe
me, that will not always happen.
You said delegating create/delete for computer objects is planned.
Did you mean in the entire domain ? If so you just gave them the
ability to delete a DC, or other server. If not, then the issues that
I mentioned before come into play, and you make the delegations
at specific OUs.
What about rename? Well, rename also involves letting the actual
computer know about this, so are they also admins on the machines
whose objects are involved in the rename?



Posted by Flash3200 on February 28, 2007, 9:54 am
Please log in for more thread options
>
>
> >I want to delegate control to our Desktop Support group to be able to
> > add computers to the domain and also be able to rename computers
> > already on the domain. It is as easy as just giving them the rights
> > to create objects and delete objects for the computer objects? There
> > are a ton of possibilities of what they can do to computer objects but
> > most don't appear to apply. Anyone gone through this already?
>
> No, it is not quite that simple.
>
> (First, as an aside, I would highly recommend that you adopt a
> practice of defining groups to which delegations are made, and
> name them well so that they are clearly existing for use only in
> that (set of) delegation(s). Then, put the groups of those that
> should hold the delegation in this new delegation group. It can
> become very, very difficult to unravel delegations in the grants
> on the delegated objects at a later date if you do not approach
> this with a plan that you do keep using consistently).
>
> Why is it not that simple?
> For example, computer objects get created in a default location
> (which, if the domain is at W2k3 functional mode you can adjust)
> and they may need to be granted ability to move computer objects
> from there to OUs, or between OUs, etc.. Yes, you could require
> that they precreate computer objects in the correct OUs, but believe
> me, that will not always happen.
> You said delegating create/delete for computer objects is planned.
> Did you mean in the entire domain ? If so you just gave them the
> ability to delete a DC, or other server. If not, then the issues that
> I mentioned before come into play, and you make the delegations
> at specific OUs.
> What about rename? Well, rename also involves letting the actual
> computer know about this, so are they also admins on the machines
> whose objects are involved in the rename?

I gotcha... I guess I should have further explained myself...
I have changed the locations where Computer object get created from
the Computers container to a specified OU, so when they do get added
to the domain they populate there. From that point on since we then
have policies that are applied to this OU we are then able to deploy
a 3rd party utility to our computers and then a Domain Admin manually
moves those PCs to the OU they need to be in. So I only really need
to delegate the created/delete to that specific OU, correct? Our
Desktop Support group are already local administrators on each PC, so
I know they should be able to rename a PC but I wasn't sure if they
needed some other delegated rights on those OUs to do so. Thanks for
any info you can share.


Posted by Roger Abell [MVP] on March 1, 2007, 2:42 am
Please log in for more thread options

>>
>>
>> >I want to delegate control to our Desktop Support group to be able to
>> > add computers to the domain and also be able to rename computers
>> > already on the domain. It is as easy as just giving them the rights
>> > to create objects and delete objects for the computer objects? There
>> > are a ton of possibilities of what they can do to computer objects but
>> > most don't appear to apply. Anyone gone through this already?
>>
>> No, it is not quite that simple.
>>
>> (First, as an aside, I would highly recommend that you adopt a
>> practice of defining groups to which delegations are made, and
>> name them well so that they are clearly existing for use only in
>> that (set of) delegation(s). Then, put the groups of those that
>> should hold the delegation in this new delegation group. It can
>> become very, very difficult to unravel delegations in the grants
>> on the delegated objects at a later date if you do not approach
>> this with a plan that you do keep using consistently).
>>
>> Why is it not that simple?
>> For example, computer objects get created in a default location
>> (which, if the domain is at W2k3 functional mode you can adjust)
>> and they may need to be granted ability to move computer objects
>> from there to OUs, or between OUs, etc.. Yes, you could require
>> that they precreate computer objects in the correct OUs, but believe
>> me, that will not always happen.
>> You said delegating create/delete for computer objects is planned.
>> Did you mean in the entire domain ? If so you just gave them the
>> ability to delete a DC, or other server. If not, then the issues that
>> I mentioned before come into play, and you make the delegations
>> at specific OUs.
>> What about rename? Well, rename also involves letting the actual
>> computer know about this, so are they also admins on the machines
>> whose objects are involved in the rename?
>
> I gotcha... I guess I should have further explained myself...
> I have changed the locations where Computer object get created from
> the Computers container to a specified OU, so when they do get added
> to the domain they populate there. From that point on since we then
> have policies that are applied to this OU we are then able to deploy
> a 3rd party utility to our computers and then a Domain Admin manually
> moves those PCs to the OU they need to be in. So I only really need
> to delegate the created/delete to that specific OU, correct? Our
> Desktop Support group are already local administrators on each PC, so
> I know they should be able to rename a PC but I wasn't sure if they
> needed some other delegated rights on those OUs to do so. Thanks for
> any info you can share.
>
In that scenario you are probably fine. I grant the support group
full control on computer objects in the OU, not just create/delete,
in order to make sure they are unhindered in their tasks. Since
your DAs move them to other locations that would probably be
inapplicable in your case as it is a per-OU grant.

Roger



Posted by Flash3200 on March 1, 2007, 12:11 pm
Please log in for more thread options
>
>
>
>
>
>
> >> >I want to delegate control to our Desktop Support group to be able to
> >> > add computers to the domain and also be able to rename computers
> >> > already on the domain. It is as easy as just giving them the rights
> >> > to create objects and delete objects for the computer objects? There
> >> > are a ton of possibilities of what they can do to computer objects but
> >> > most don't appear to apply. Anyone gone through this already?
>
> >> No, it is not quite that simple.
>
> >> (First, as an aside, I would highly recommend that you adopt a
> >> practice of defining groups to which delegations are made, and
> >> name them well so that they are clearly existing for use only in
> >> that (set of) delegation(s). Then, put the groups of those that
> >> should hold the delegation in this new delegation group. It can
> >> become very, very difficult to unravel delegations in the grants
> >> on the delegated objects at a later date if you do not approach
> >> this with a plan that you do keep using consistently).
>
> >> Why is it not that simple?
> >> For example, computer objects get created in a default location
> >> (which, if the domain is at W2k3 functional mode you can adjust)
> >> and they may need to be granted ability to move computer objects
> >> from there to OUs, or between OUs, etc.. Yes, you could require
> >> that they precreate computer objects in the correct OUs, but believe
> >> me, that will not always happen.
> >> You said delegating create/delete for computer objects is planned.
> >> Did you mean in the entire domain ? If so you just gave them the
> >> ability to delete a DC, or other server. If not, then the issues that
> >> I mentioned before come into play, and you make the delegations
> >> at specific OUs.
> >> What about rename? Well, rename also involves letting the actual
> >> computer know about this, so are they also admins on the machines
> >> whose objects are involved in the rename?
>
> > I gotcha... I guess I should have further explained myself...
> > I have changed the locations where Computer object get created from
> > the Computers container to a specified OU, so when they do get added
> > to the domain they populate there. From that point on since we then
> > have policies that are applied to this OU we are then able to deploy
> > a 3rd party utility to our computers and then a Domain Admin manually
> > moves those PCs to the OU they need to be in. So I only really need
> > to delegate the created/delete to that specific OU, correct? Our
> > Desktop Support group are already local administrators on each PC, so
> > I know they should be able to rename a PC but I wasn't sure if they
> > needed some other delegated rights on those OUs to do so. Thanks for
> > any info you can share.
>
> In that scenario you are probably fine. I grant the support group
> full control on computer objects in the OU, not just create/delete,
> in order to make sure they are unhindered in their tasks. Since
> your DAs move them to other locations that would probably be
> inapplicable in your case as it is a per-OU grant.
>
> Roger- Hide quoted text -
>
> - Show quoted text -

Thanks for the info!


Similar ThreadsPosted
domain access control for local user of domain computer? April 3, 2008, 5:14 pm
Using DSACLS to delegate the right to delegate March 31, 2006, 2:28 pm
Rename Domain Admin Account June 10, 2008, 4:03 am
Non-Domain computer access September 6, 2005, 3:47 pm
Disabled Domain Computer Accounts September 20, 2006, 4:09 pm
Problem with Domain Computer account December 18, 2006, 2:46 pm
PCs still function on domain with computer account disabled June 14, 2006, 3:51 pm
users reaching server from computer not in domain September 22, 2007, 10:45 pm
prevent access to shared folder when not on a domain computer July 11, 2005, 8:50 pm
How to open LSA API on Win2k in order to determine if a computer is member of domain October 17, 2007, 5:45 am

Our other projects:

Art Dolls, Fairies and Mermaids - Sunnyfaces.net

Roy's Linux, Programming and Search Engines messages

1-Script XML SitemapXML Sitemap