Domain Controller Security Policy

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi,
I have a problem which is giving me real problems. We are in the process of
merging a number of domains into one. I want the old domain admin people to
log onto the DC's in their own geographical areas and be able to do
everything that they used to be able to do, but only for their site and not
domain wide. I'm trying to create a policy that applies to a site, that
gives a group access to log on locally to the DC, install software etc, but
which won't allow them access to do anything that may upset the domain in
general.

I've created a new group into which I will add the admin people for that
area. I've created a site into which their local DC is configured. When I
create a policy that changes the "user rights assignment" for the group, it
isn't applied and I get the message "The local policy doesn't permit you to
log on interactively".

Any ideas?
 
The answer is LSDOU... sound cryptic?

(L)ocal
(S)ite
(D)omain
(OU) or Organizational Unit

This is the order in which each of the Group Policies is applied with the
preceeding one being overwritten by the next on in line. Thus, when you
apply a policy to the site, it is overwritten by the Default Domain Policy
and that is overwritten by the Default Domain Controllers OU Policy. Domain
Controllers are controlled primarily via the Default Domain Controllers
Policy associated with the Domain Controllers OU. Now you can move the
Domain Controllers out of the Domain Controllers OU and put them in an OU of
your creation. So, you create OUs like "Domain Controller in Site A" and so
on. Then you could apply access policies to these.

However, it still won't really solve your problem. You see, each of the
domain controllers is an equal peer in the Domain. So, giving someone access
to the domain controller (DC) gives them the inheirent ability to affect the
organization. Hold tight control over the DC's is important for the security
and stability of your computing environment. However, you could create OU's
and put all of the other resources of the various locations in the OU's. You
can put the computers, users, and groups particular for the site in an OU for
the office location and then give the admins in that location near complete
control over those resources without giving control to the domain controllers
or domain.
 
Paul,

Thank you for your quick response. I thought I had it sorted by applying a
no over ride on a policy applied to the site. Unfortunately this affected all
machines in the Site, not just the DC. Your response has drawn my attention
to moving the DC out of the default OU and appying a new policy to it. I am
going to reconfigure my test network and test it out. I think you may well
have put me back on the right track!

Thanks,

Cliff.
 
Glad to be of service.
--
Paul Hinsberg


Cliff said:
Paul,

Thank you for your quick response. I thought I had it sorted by applying a
no over ride on a policy applied to the site. Unfortunately this affected all
machines in the Site, not just the DC. Your response has drawn my attention
to moving the DC out of the default OU and appying a new policy to it. I am
going to reconfigure my test network and test it out. I think you may well
have put me back on the right track!

Thanks,

Cliff.
Click to expand...
 
Back
Top