OU Delegation

  • Thread starter Thread starter Fred Yarbrough
  • Start date Start date
F

Fred Yarbrough

BACKGROUND:
We have a sister company in Knoxville (connected to us via a WAN link) who
uses our domain. We located a DC there and they have a couple of other file
and printer sharing machines too. I created them an OU for their site and
added their users, computers, DC, and servers to this OU. This all works
like a champ.


PROBLEM:
I need to allow their onsite admin to be able to administrator their OU.
They need to be able to login to the DC and do things and to perform basic
administrator functions for their site. I added this user to the Delegate
Control function for their OU but it does not seem to allow them to login to
the DC. Is there something special that I must do to permit this? The DC
is also used for some minor file sharing. In the past this admin was just
granted Domain Administrator rights but I am trying to reduce their
privileges to only allow them to administrator their own OU.

Thanks,
Fred
 
Normally it is not a good idea to move a domain controller out of the domain
controller container for the sake of consistent application of security
policy. In a default AD domain you would have to add the "delegated" user to
the right to logon locally in Domain Controller Security Policy. If you have
Domain Controller Security Policy linked to that OU and applied to your dc
then that is where you should configure it. Otherwise check the Local
Security Policy on the domain controller for the user right to logon
locally. You will still find that he has limited access to the dc itself.
You still need to be a domain admin to do things like change tcp/ip
configuration on the domain controller. --- Steve
 
Physical access should be limited hence it would be highly essential to
setup Terminal Services / Remote Admin mode on the local DC for AD
delegated admin tasks.

Do not forget to create a group and add that to the list of authorized users
in both "Terminal Services Configuration > Permissions" and
"Local Security Settings > Local Policies > User Rights Assignment > Allow
logon on locally" (Win 2000 only).

Do let us know if this helps.
 
Fred Yarbrough said:
PROBLEM:
I need to allow their onsite admin to be able to administrator their OU.
Click to expand...
They need to be able to login to the DC and do things and to perform basic
administrator functions for their site. I added this user to the Delegate
Control function for their OU but it does not seem to allow them to login to
the DC.
Click to expand...

Usually that isn't directly related to OU delegation (which
allows for adding/removing/resetting accounts/passwords
in the OU but not necessarily logging onto the computers.

To allow Logon to the DC, you will have to either add the
user to a group with this privilege (e.g., Domain Admins,
Server Operators, etc.) or create a group for the explicit
purpose and give it the necessary privileges.
Is there something special that I must do to permit this? The DC
is also used for some minor file sharing. In the past this admin was just
granted Domain Administrator rights but I am trying to reduce their
privileges to only allow them to administrator their own OU.
Click to expand...

Delegating the OU (control of the AD objects) and making
someone a server or even domain admin are two separate
issues.
 
Steven,
Thanks for the response. I am talking about a W2K3 Native Mode AD
implementation here. I had the same thoughts as you on moving the DC from
the default Domain Controller OU. The reason that I did move this DC to
their site OU was in hopes that I could define an OU policy that would limit
what the Admin could do to only their OU. If I attempt to grant a Logon
Locally privilege back at the Domain Controller OU they have this right on
all other DC's too. Does this make sense?

Since this is a DC, there is no Local Security Policy that I can find.

I am well versed with permissions but don't have a clue with this policy and
OU delegation stuff.


Thanks,
Fred
 
Fred Yarbrough said:
Steven,
Thanks for the response. I am talking about a W2K3 Native Mode AD
implementation here. I had the same thoughts as you on moving the DC from
the default Domain Controller OU. The reason that I did move this DC to
their site OU was in hopes that I could define an OU policy that would limit
what the Admin could do to only their OU. If I attempt to grant a Logon
Locally privilege back at the Domain Controller OU they have this right on
all other DC's too. Does this make sense?
Click to expand...

I have never had good results in moving DCs to other
OUs even though one would expect it to work.

If you do this I strongly suggest you move it to a CHILD
OU of the default DC OU.

Even this has been probablematic at times, but seems to
work ok under latest versions.
 
Herb,
Understood somewhat. I figured that the Log On Locally privilege was
the probable issue here. I guess that the fact that this is a DC and not
just a normal server with a Local Security Settings is what is somewhat
perplexing me. I only want this site Admin to be able to Administer
machines within their realm. I have moved the DC into their site's OU and
set a Logon Locally privilege for the admin in that OU's policy. I will
have to check and see if this works.

On another note, I would also like for this Admin to have Administrator
privileges on each machine within their OU. Is this possible through
policies?


Thanks,
Fred
 
machines within their realm. I have moved the DC into their site's OU and
set a Logon Locally privilege for the admin in that OU's policy. I
Click to expand...
will

It is discouraged to move a DC out of the default "Domain Controllers" OU,
as erratic behavior have been reported. Besides, this may cause unexpected
support issues.
 
Ok. I sorta get that feeling. How is the best way to allow a user to be
the Administraor for a remote site? Is the fact that I am wanting to all
them access to login to the DC the issue here?


Thanks,
Fred
 
Perhaps there is some confusion here.

Assuming that you have structured administration using OU, any domain member
Servers that will only be managed by IT from that location should be placed
within
that location's OU. IT (local) can be given administrative rights to these
local
servers. Group policies can then be created to target only these machines in
the
specific OU.

However, DCs stay in the default "Domain Controllers". Administratively, a
security group could be created that is granted minimum rights and
permissions
sufficient to perform local IT tasks such as backup (on the DC). Taking note
of
the points highlighted previously, in addition, should cover all your
intended needs.

If an account is made a member of "Domain Admins", s/he will have full
access to all DCs in the same domain (regardless of physical location),
which is
probably not what you want.

See below for a textual graphics example. Hope this helps.

domain.com
--- Domain Controllers
------ DC01, DC02 (contained with "Domain Controllers")
--- NewYork
--- Boston
------ Servers (contained within "Boston")
--------- Server_Exchange, Server_File, etc. (contained within "Servers")
 
Fred Yarbrough said:
Herb,
Understood somewhat. I figured that the Log On Locally privilege was
the probable issue here. I guess that the fact that this is a DC and not
just a normal server with a Local Security Settings is what is somewhat
perplexing me. I only want this site Admin to be able to Administer
machines within their realm.
Click to expand...

Ok, I can conceive of the issue but in some sense
DC administration might be administering the whole
domain anyway.
I have moved the DC into their site's OU and
set a Logon Locally privilege for the admin in that OU's policy. I will
have to check and see if this works.
Click to expand...

I think moving the DC to another, especially non-child, OU
is a VERY BAD IDEA.

I thought it made perfect sense until I tried it.

For access you really should just build a Group and give the
privileges you wish them to have and on which machines.
(See below for GPO to set machines.)
On another note, I would also like for this Admin to have Administrator
privileges on each machine within their OU. Is this possible through
policies?
Click to expand...

Believe it or not, it is.

Make a restricted group along with the PRIVILEGE group above
concept.

Restrict the group to those machines you wish by assigning
the OU at the appropriate level or filtering using (machine
account) permissions.

Restricted groups could REQUIRE the EngAdmin group be
in the Administrators group of all, and ONLY all, computers
in the Engineering OU (with proper linkage of the GPO.)
 
Fred Yarbrough said:
Ok. I sorta get that feeling. How is the best way to allow a user to be
the Administraor for a remote site? Is the fact that I am wanting to all
them access to login to the DC the issue here?
Click to expand...

And it really has little or nothing to the problem you
are actually trying to solve. (Really.)

If you MUST organize DCs by location (or other criteria)
I strongly suggest those OUs be child OUs of the default
DC OU.

I have no real reason why doing otherwise gets so screwy
but I assure you I have tried it with terrible but not in your
face results -- it works well enough you forget about it
but you domain gets flaky.

Others have confirmed this behavior and there may even be
a KB article on it.

It also may have been fixed in some Service Pack but most
of use stopped trying this long ago.

I do have child OUs in the DC OU and they seem ok.
 
Your reason for moving the dc into the OU being delegated would not really
give you much. For instance it will not allow the users delegated authority
to the OU domain admin like access to the domain controller for things like
changing networking configuration, configuring Local Security Policy,
starting and stopping services [though that can be configured via Group
Policy] , or installing software. If you grant logon locally access to
Domain Controller Security Policy it would allow a user to logon to all
domain controllers in a default installation. You could create a child OU of
the domain controller's container with it's own GPO to configure the user
right for logon locally that would apply to just domain controllers in that
child OU. All other Domain Controller Security Policy would still apply to
that child OU other than settings you define in the GPO for that child OU
such as logon locally. In fact that could be the only setting you define in
the GPO for the child OU. There is a Local Security Policy for all Windows
2003 computers. That made it harder to find compared to W2K but secpol.msc
will bring it up. --- Steve
 
I forgot to add that adding a user to user rights [privileges] or privileged
groups [server operator, etc] is another way to give a regular user more
configuration ability for domain controllers. However membership in
privileged groups would apply to all domain controllers. --- Steve


Steven L Umbach said:
Your reason for moving the dc into the OU being delegated would not really
give you much. For instance it will not allow the users delegated
authority to the OU domain admin like access to the domain controller for
things like changing networking configuration, configuring Local Security
Policy, starting and stopping services [though that can be configured via
Group Policy] , or installing software. If you grant logon locally access
to Domain Controller Security Policy it would allow a user to logon to all
domain controllers in a default installation. You could create a child OU
of the domain controller's container with it's own GPO to configure the
user right for logon locally that would apply to just domain controllers
in that child OU. All other Domain Controller Security Policy would still
apply to that child OU other than settings you define in the GPO for that
child OU such as logon locally. In fact that could be the only setting you
define in the GPO for the child OU. There is a Local Security Policy for
all Windows 2003 computers. That made it harder to find compared to W2K
but secpol.msc will bring it up. --- Steve


Fred Yarbrough said:
Steven,
Thanks for the response. I am talking about a W2K3 Native Mode AD
implementation here. I had the same thoughts as you on moving the DC
from
the default Domain Controller OU. The reason that I did move this DC to
their site OU was in hopes that I could define an OU policy that would
limit
what the Admin could do to only their OU. If I attempt to grant a Logon
Locally privilege back at the Domain Controller OU they have this right
on
all other DC's too. Does this make sense?

Since this is a DC, there is no Local Security Policy that I can find.

I am well versed with permissions but don't have a clue with this policy
and
OU delegation stuff.


Thanks,
Fred
Click to expand...
Click to expand...
 
Most tasks can be accomplished without the ability to
log in to the DC, and there are advantages for you in
making the delegated powers be exercised in this way.

You have not stated what privs were and/or will be
delegated, but access to the DC can impact the well-being
of your entire forest.

All DCs should remain within the Domain Controllers OU
in order to have the DC related GPOs applied to them,
Of course, you could define in a couple of ways so that the
DC related GPOs are still applied to the DC after it was
moved to this OU defined for this sister company site, but
I find that less direct and more likely to lead sooner or later
to error conditions or mistaked.

The delegated user cannot log in to the DC because they have
not been grant the user right to Log on locally. In order to
have this granted, on just that DC (again, you really do not
need this - they should be able to do most things from an
adminstrative workstation with the adminpak.msi installed)
you will need to apply a GPO that impacts this DC only, and
contain the one overwriting policy value for this user right.
 
I can see the local policy running the secpol.msc but I cannot make a change
to it. I guess that I will make the Child OU under the Domain Controller OU
and set the policy there.

Thanks to all.


Fred


Steven L Umbach said:
Your reason for moving the dc into the OU being delegated would not really
give you much. For instance it will not allow the users delegated authority
to the OU domain admin like access to the domain controller for things like
changing networking configuration, configuring Local Security Policy,
starting and stopping services [though that can be configured via Group
Policy] , or installing software. If you grant logon locally access to
Domain Controller Security Policy it would allow a user to logon to all
domain controllers in a default installation. You could create a child OU of
the domain controller's container with it's own GPO to configure the user
right for logon locally that would apply to just domain controllers in that
child OU. All other Domain Controller Security Policy would still apply to
that child OU other than settings you define in the GPO for that child OU
such as logon locally. In fact that could be the only setting you define in
the GPO for the child OU. There is a Local Security Policy for all Windows
2003 computers. That made it harder to find compared to W2K but secpol.msc
will bring it up. --- Steve


Fred Yarbrough said:
Steven,
Thanks for the response. I am talking about a W2K3 Native Mode AD
implementation here. I had the same thoughts as you on moving the DC from
the default Domain Controller OU. The reason that I did move this DC to
their site OU was in hopes that I could define an OU policy that would
limit
what the Admin could do to only their OU. If I attempt to grant a Logon
Locally privilege back at the Domain Controller OU they have this right on
all other DC's too. Does this make sense?

Since this is a DC, there is no Local Security Policy that I can find.

I am well versed with permissions but don't have a clue with this policy
and
OU delegation stuff.


Thanks,
Fred


user
to link)
who site
and The
DC
Click to expand...
Click to expand...
 
OK. If you can not change Local Security Policy then their is another
Group/security policy overriding it. Possibly you have the Domain Controller
Security Policy linked to that OU. FYI you can use the RSOP mmc snapin on
that computer [ if it is W2K, otherwise do it via GPMC] and it should show
exactly what GPO's are applying a particular policy setting. However moving
to a child OU of the DC OU sounds like a good plan. --- Steve


Fred Yarbrough said:
I can see the local policy running the secpol.msc but I cannot make a
change
to it. I guess that I will make the Child OU under the Domain Controller
OU
and set the policy there.

Thanks to all.


Fred


Steven L Umbach said:
Your reason for moving the dc into the OU being delegated would not
really
give you much. For instance it will not allow the users delegated authority
to the OU domain admin like access to the domain controller for things like
changing networking configuration, configuring Local Security Policy,
starting and stopping services [though that can be configured via Group
Policy] , or installing software. If you grant logon locally access to
Domain Controller Security Policy it would allow a user to logon to all
domain controllers in a default installation. You could create a child OU of
the domain controller's container with it's own GPO to configure the user
right for logon locally that would apply to just domain controllers in that
child OU. All other Domain Controller Security Policy would still apply
to
that child OU other than settings you define in the GPO for that child OU
such as logon locally. In fact that could be the only setting you define in
the GPO for the child OU. There is a Local Security Policy for all
Windows
2003 computers. That made it harder to find compared to W2K but
secpol.msc
will bring it up. --- Steve


Fred Yarbrough said:
Steven,
Thanks for the response. I am talking about a W2K3 Native Mode AD
implementation here. I had the same thoughts as you on moving the DC from
the default Domain Controller OU. The reason that I did move this DC
to
their site OU was in hopes that I could define an OU policy that would
limit
what the Admin could do to only their OU. If I attempt to grant a
Logon
Locally privilege back at the Domain Controller OU they have this right on
all other DC's too. Does this make sense?

Since this is a DC, there is no Local Security Policy that I can find.

I am well versed with permissions but don't have a clue with this
policy
and
OU delegation stuff.


Thanks,
Fred


Normally it is not a good idea to move a domain controller out of the
domain
controller container for the sake of consistent application of
security
policy. In a default AD domain you would have to add the "delegated" user
to
the right to logon locally in Domain Controller Security Policy. If
you
have
Domain Controller Security Policy linked to that OU and applied to
your
dc
then that is where you should configure it. Otherwise check the Local
Security Policy on the domain controller for the user right to logon
locally. You will still find that he has limited access to the dc itself.
You still need to be a domain admin to do things like change tcp/ip
configuration on the domain controller. --- Steve



BACKGROUND:
We have a sister company in Knoxville (connected to us via a WAN link)
who
uses our domain. We located a DC there and they have a couple of other
file
and printer sharing machines too. I created them an OU for their site
and
added their users, computers, DC, and servers to this OU. This all
works
like a champ.


PROBLEM:
I need to allow their onsite admin to be able to administrator
their
OU.
They need to be able to login to the DC and do things and to perform
basic
administrator functions for their site. I added this user to the
Delegate
Control function for their OU but it does not seem to allow them to
login
to
the DC. Is there something special that I must do to permit this? The
DC
is also used for some minor file sharing. In the past this admin
was
just
granted Domain Administrator rights but I am trying to reduce their
privileges to only allow them to administrator their own OU.

Thanks,
Fred
Click to expand...
Click to expand...
Click to expand...
 
Why not load the admin tools on the site admins computer. He can connect
without logging into the DC.
 
Back
Top