New to Active Directory - we need help configuring GPO

  • Thread starter Thread starter Ali
  • Start date Start date
A

Ali

Hello,

We're trying to institute AD on a Windows 2000 server. We
have 1 domain (no sites) and have created multiple OU's to
delegate security. We'd like to set Group Policy at the
domain level for passwords, control panel limitations,
etc. so it filters through the whole domain. We want all
users in the domain to have the same parameters.

There is a limited group that needs access to everything
on the domain. In all the literature we've read, we are
hesitant to use No Override on Domain GP or Block policy
Inheritance on OU's.

To give full access to the limited group of users
mentioned above, it seems like we need to add this group
to Domain Admins. Is this the best procedure?

Everything we read is ambiguous, and it seems as if there
are multiple ways of doing things. We want to make sure
that we are applying GP's to their fullest advantage.

We tried different ways based on what we have picked off
the internet. For the most part, we were able to make a GP
work. However, when created at the domain level, it seems
to affect the rights of the Domain administrator. How can
we get around that?

Is there a step by step guide that gives explicit
instructions or is everything generally written?

Any help is greatly appreciated.
 
That is not the best procedure. To absolve them of all the restrictions in a
certain GPO, add the group to the GP's ACL, and deny the right to apply the
policy.

--
--
Brian Desmond
Windows Server MVP
(e-mail address removed)12.il.us

Http://www.briandesmond.com
 
Ok here is the deal. We are just very confused. First of
all Creating the GP on the domain level..we have seen
different things happening:


1. The GP does not filter properly down to an OU

2. Upon creating the GP at the domain level...and blocking
such things as access to "control panel", "run in the
start menu"...the administrator loses access to these
things as well.

3. We did somehow get the GP to work properly for a test
user. However, we logged in as the user on two different
test pc's and on one PC the user has no access to run,
control panel. On the 2nd PC the user has access to those
things. What is going on?

I have been able to create a GP and place it into an
actual OU and get everything to function properly.
However, doesnt that defeat the purpose?

So I guess my question is whether or not we should be
creating the GP and applying it at the domain level or
just place it in each OU(which seems to work).

As for creating users...as you know we have created OU's.
We want to have the ability to place a users into multiple
OU's...for example an 'ADMIN' person might also need to be
within 'OFFICE staff'. Do we create groups within the OU
to do this?

We are relatively in-experienced when it comes to AD. Is
there something drawn out step by step. We are just
looking for simple security measure which allow us to
control what the users have access to. Of course....all
admin ppl need to retain their access.

Thanks again.
 
In
Ali said:
Ok here is the deal. We are just very confused. First of
all Creating the GP on the domain level..we have seen
different things happening:


1. The GP does not filter properly down to an OU

2. Upon creating the GP at the domain level...and blocking
such things as access to "control panel", "run in the
start menu"...the administrator loses access to these
things as well.

3. We did somehow get the GP to work properly for a test
user. However, we logged in as the user on two different
test pc's and on one PC the user has no access to run,
control panel. On the 2nd PC the user has access to those
things. What is going on?

I have been able to create a GP and place it into an
actual OU and get everything to function properly.
However, doesnt that defeat the purpose?

So I guess my question is whether or not we should be
creating the GP and applying it at the domain level or
just place it in each OU(which seems to work).

As for creating users...as you know we have created OU's.
We want to have the ability to place a users into multiple
OU's...for example an 'ADMIN' person might also need to be
within 'OFFICE staff'. Do we create groups within the OU
to do this?

We are relatively in-experienced when it comes to AD. Is
there something drawn out step by step. We are just
looking for simple security measure which allow us to
control what the users have access to. Of course....all
admin ppl need to retain their access.

Thanks again.
Click to expand...


OUs are designed for you to organize your domain objects. This includes
Users, Groups and Computers. To do what you are doing by setting a blanket
setting at the domain level would affect ALL objects domain wide, including
your domain controllers (which you DO NOT want this to occur). This will
involve numerous GPO filtering (by denying apply on the GPO) for the objects
that do not require it (such as your admins, DCs and other objects, which
you are just making it very difficult and complex to adminster and keep
track of.

The idea behind OUs is to group certain objects for certain reasons, such as
GPO application and/or delegation. You can create OUs for grouping objects
based on remote location, department or function.

I would highly suggest to group whatever users you want by OUs (by
department or function) and then apply these certain restrictive settings
you want to give those users at the OU level. If you don't want your admins
to be affected by this GPO, put them in their own OU. If separating by
remote locations, and there are specific admins at each location, then
create a child OU under the remote location's OU, called 'admins' and block
inheritance on their OU so they won't get the GPO you applied at that
specifi parent OU. But I would not suggest to do all this at the Domain
level. You'll be setting yourself up for problems due to the complexity you
are subjecting yourself with the way you're currently thinking and
attempting to do it.

FYI: Password settings and password policies will ONLY work at the Domain
level, they do NOT work at the OU level. Normally most admins (depending on
your scenario) will only set these settings here and create OUs to govern
the other objects with GPOs, as I mentioned above.

Here's an example:
Domain - Default Domain GPO
Click to expand...
Password set to min 8 characters
Password Complexity Requirements
No Override
No Network Neighborhood
No Run Command
No Favorites
Above, you have your Domain, and under that we created a Philly OU, with a
GPO with restrictions, and then we created two Child OUs under Philly OU. So
what will happen above is when a user logs in from Philly (assuming you ahve
all the Philly users in this OU), they will get No Control Panel access,
they won't see My Network PLaces, they will not have a Run command
available, and they will have no Favorites on their STart menu. But the
admins, when they login will have nor restrictions. All users in the whole
domain will have a required min password length or 8 characters with
complexity requirements. The password stuff also affects the Philly admins
because the No Override at the domain level is forced even though they have
Block Inheritance. This assures domain level 'required' settings go to
everyone.

Make sense?

Block Inheritance and No Override are designed to control GPO inheritance. I
wouldn't be scared in using them, if I were you, since that's all they do
and will make it easier for you to accomplish your end goal. There is a tool
called 'gpresults.exe' in the resource kit that you can run at a client
machine to see what GPOs have applied to it. There is a 3rd party tool
called FAZAM 2000 by Full Armor (www.fullarmor.com) that will give you a
complete administrative control for all GPOs. In W2k3, there's a new tool
called GPMC that gives you similar features but not as feature rich as
FAZAM.

Desiging your AD domain is part of the whole AD process.

With all due respect, there are a couple classes that exist for W2k and W2k3
on AD which have comprehensive sections (Modules) on how to use GPOs. They
are VERY informative if you choose to attend one, and then you can see how
easy they really are to use. If interested in what these classes are, post
back and I can give you specific course numbers and you can check with
Microsoft's site for a center that delivers them near you.

--
Regards,
Ace

Please direct all replies to the newsgroup so all can benefit.
This posting is provided "AS-IS" with no warranties and confers no
rights.

Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory
 
Moving on.

We'll give your recommendation a try. Seems like there
are multiples ways of structuring AD so it's just a matter
of fine-tuning.

What about setting up printers? The "Printers" wizard is
self-explanatory; however, we are using print servers
(i.e. HP jet directs) that use TCP/IP protocol. We
realize that drivers must be manually installed on all
PC's but what is the best way to deploy through AD?

One further question -- would you recommend that the
administrator maintain a list of passwords and provide a
new password to the end-user or would it be more
advantageous to allow the user to set their own password
(as long as AD has a GPO set up with restriction
limitations)?

Thanks for your help!
 
In
Ali said:
Moving on.

We'll give your recommendation a try. Seems like there
are multiples ways of structuring AD so it's just a matter
of fine-tuning.

What about setting up printers? The "Printers" wizard is
self-explanatory; however, we are using print servers
(i.e. HP jet directs) that use TCP/IP protocol. We
realize that drivers must be manually installed on all
PC's but what is the best way to deploy through AD?

One further question -- would you recommend that the
administrator maintain a list of passwords and provide a
new password to the end-user or would it be more
advantageous to allow the user to set their own password
(as long as AD has a GPO set up with restriction
limitations)?

Thanks for your help!
Click to expand...


Just want to point out they are not necessarily recommendations, but rather
suggestions based on best practices, which are based on the guidelines for
the way the product was designed.

TCP/IP printers, to have control over who can print, GPO publishing and
Printer Location Tracking, should be controlled from one machine only and
then shared out to the clients. If you install the Jetdirect software on
everyone;s desktop and connect directly to the printers, then there is no
central control and you lose all these features.

Password lists can be political, but sometimes can be helpful, such as when
a person is not in that day and you need to log in under their account on
their desktop to retrieve something. This can also come down to a debate
about privacy, but then again, the company owns the equipement and the
employee just uses it to do their work. So it can come down to a gray area.
So it depends on your company or whomever makes the rules. I usually don't
maintain a password list for my clients unless they ask me to. So that would
be up to you. Sorry for no straight answer on this one. But I do highly
recommend to use complexity requirements for passwords and down allow to
reuse the same password in the domain level GPO.

Good luck!
:-)


--
Regards,
Ace

Please direct all replies to the newsgroup so all can benefit.
This posting is provided "AS-IS" with no warranties and confers no
rights.

Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory

HAM AND EGGS: A day's work for a chicken; A lifetime commitment for a
pig. --
=================================
 
Back
Top