Domain Password Policy & Blocking Policy Inheritance

  • Thread starter Thread starter Fat Bastard
  • Start date Start date
F

Fat Bastard

While testing the implementation of a domain password policy it was
not working and I discovered the problem was the "Block Policy
inheritance" option was checked for the DC OU. I deply applications
using GPO and do not want these deployed to the domain controllers.

Is there a way to achieve this by being able to leave the block policy
option checked or leave it checked and use another method to prevent
it from applying to the DC's? Hopefully one that is automatic instead
of going into each App GPO, adding each DC and denying read access.
 
I think you can make use of security permission of GPO to achieve what you
want.

BR,
Denis
 
Did you have something specific in mind?

Something other than what I mentioned about denying read to DC's on
the policies.
 
Maybe I'm naive or something, but this seems to me to be a natural
application of Organisational Units (OUs).

The OU "Domain Controllers" is provided automatically when the Domain is
created and presumably, all the Domain Controller computer accounts are in
that OU.

Create an OU under the domain root (same level as the Domain Controllers OU)
for all other computers (e.g. an AllNonDCComputers OU). Link the Software
Installation GPOs to this new OU (e.g. AllNonDCComputers) instead of at the
Domain level. Then, the Software Installation GPOs will not apply to Domain
Controllers and there is no need to resort to more esoteric solutions.

The Password policy would be settings in the Default Domain Policy that is
linked to the Domain and thus would apply to the Domain Controllers in the
Domain Controllers OU and all the other computers in the (for example)
AllNonDCComputers OU.
 
Hi,

Actually you would want to have the client workstations in a separate
OU. You could bunch them up in a new OU like Bruce mentioned. Thats
the way most of the organizations setup their AD structure.

users in a separate OU.

Keeping these machine and User accounts in their default containers
doesnt help help you achieve anything. By moving them to a OU, you can
apply GPOs to them exculsively like you want here.

You can delegate control of these ous or part managing these ous.

I would really not put a Software Installation Policy at the top of my
Domain. I dont want that policy to hit my DCs, my Servers or some of
my workstations. Just hit the Computers I want it to.

--
Gautam Anand
e: gautam at hotpop dot com
---------------------------------
| Can anyone help with this? Still looking for a solution.
|
| On Thu, 30 Sep 2004 21:24:07 GMT, Fat Bastard <[email protected]>
| wrote:
|
| >While testing the implementation of a domain password policy it was
| >not working and I discovered the problem was the "Block Policy
| >inheritance" option was checked for the DC OU. I deply
applications
| >using GPO and do not want these deployed to the domain controllers.
| >
| >Is there a way to achieve this by being able to leave the block
policy
| >option checked or leave it checked and use another method to
prevent
| >it from applying to the DC's? Hopefully one that is automatic
instead
| >of going into each App GPO, adding each DC and denying read access.
|
 
Thank you for the tip. That explains why the problem I have isn't
more common.

So I am guessing that when a computer is added to the domain it is
added to the default container and then I would need to manually move
it to the separate OU. If this is true could the manual move to the
OU be automated?

Thanks again for the tip. I will give it a try.
 
I don't believe a move to an OU could be automated when a machine
joins the domain.
Yes by default its put in the Computers container. And users in the
users container. I suspect someone might have figured out to do this
via a script but I have yet to see that.

You could probably put that one up in the Microsoft Wishlist if you
don't get an answer here or on the net.

--
Gautam Anand
e: gautam at hotpop dot com
---------------------------------
| Thank you for the tip. That explains why the problem I have isn't
| more common.
|
| So I am guessing that when a computer is added to the domain it is
| added to the default container and then I would need to manually
move
| it to the separate OU. If this is true could the manual move to the
| OU be automated?
|
| Thanks again for the tip. I will give it a try.
|
| On Mon, 4 Oct 2004 23:12:25 +0530, "Gautam Anand"
<[email protected]>
| wrote:
|
| >Hi,
| >
| >Actually you would want to have the client workstations in a
separate
| >OU. You could bunch them up in a new OU like Bruce mentioned. Thats
| >the way most of the organizations setup their AD structure.
| >
| >users in a separate OU.
| >
| >Keeping these machine and User accounts in their default containers
| >doesnt help help you achieve anything. By moving them to a OU, you
can
| >apply GPOs to them exculsively like you want here.
| >
| >You can delegate control of these ous or part managing these ous.
| >
| >I would really not put a Software Installation Policy at the top of
my
| >Domain. I dont want that policy to hit my DCs, my Servers or some
of
| >my workstations. Just hit the Computers I want it to.
|
 
Actually, if you use an unattended installation to deploy WIN2000 or WIN XP
you can specify the location of the computer account by stipulating the
"MachineObjectOU" line under the [Identification] section. It would look
something like this:

MachineObjectOU="OU=WIN2000,OU=WORKSTATIONS,DC=MyCompany,DC=com" -OR-
MachineObjectOU="OU=WINXP,OU=WORKSTATIONS,DC=MyCompany,DC=com"

Granted, you would have to have created the OU structure before hand!

This does not work with RIS, IIRC. It is solely an unattended installation
thing.

Furthermore, there is a utility that is available in WIN2003 environments
that will change the default location of computer account objects as well as
the default location of user account objects. Please take a look at the
following MSKB Article:

http://support.microsoft.com/?id=324949

HTH,

Cary
 
You can pre-create the computer account in the OU you want it in. Then,
when the computer with a Computer Name the same as the pr-created account
joins the domain, that computer account will be used..
 
Back
Top