OUs & Child domains....

[Brain]

Instead of breaking down the main domain into smaller child domains, can the
same be achieved by OUs? i mean users logging to particular OUs & their
actions to be restricted to that OU only.
do we have to create a parent/child domain architecture or can be achieved
using OUs.

Thanks in Advance.
Brian

 

[Guest]

I'd say keep it simple...
Only think about separate domains if you have slow links between sites...
You don't want user authentication crossing the site. Even then you can have
a DC with GC in each site. OUs are great for organizing and applying
different group policies. OUs don't restrict users but for the Group Policy
applied to it (OU).
I hope to have helped you on this...

 

[Cary Shultz [A.D. MVP]]

Brian,

There are a lot of ways that you can make use of OUs and GPOs to do things.
It is simply a matter of finding out what you really need to do and then
implement things to best suit those needs.

If you have some 600 users and they are all in one building then you do not
really need to worry about setting up multiple Sites ( a very easy thing to
do ). If, one day, some of the business units should move to another
building then - if you set things up properly - the only thing that you
would need to worry about would be setting up a Site in ADSS MMC and adding
at least one DC / GC in that Site ( and, naturally, the Site-to-Site VPN if
you did not have a dedicated, private T1 between the two buildings ).

The idea of using OUs instead of Domains is a very very very good idea.
Generally! There might come a time when one BU wants to have a really
secure password policy but none of the others do. This might be the time to
explore a child domain. There might be other factors as well. You may
even get into the area of a new forest due to legal reasons ( as the forest
is the only true security boundary! ). But that is putting the cart before
the horse right now. Just some things that you might have to consider down
the road.

Generally you could simply create an OU for each of the Business Units and
then move the user account objects into the correct OU. You could do the
same for the computer account objects.

You could then create the GPOs and link each to the appropriate OU. This is
just a technical sidenote - you do not create GPOs at the level you are.
Meaning, if you are at one of the OUs and you right click on it and select
Properties and then go to the GPO tab and click on New... and give it a
friendly name you have created the GPO. Now, what have you really done?
You are not creating it in that OU or at the OU-level. You are creating it
at the domain-level on the DC that holds the FSMO Role of PDC Emulator (
assuming that you have not changed this ). Once you enter the friendly name
( such as 'Office XP' ) three things happened: the GPC ( Group Policy
Container ) was created in the AD Database, the GPT ( Group Policy
Template ) was created in the shared SYSVOL on the DC that holds the FSMO
Role of PDC Emulator and the GPO was linked to that specific OU.

There are a lot of things to take into consideration. I think, based on
what very little information that you have supplied us, that this would be a
good starting point. One thing to try to remember is to K I S S - keep it
simple, stupid! You can really go overboard and make this a very
complicated thing!

HTH,

Cary

 

[Brain]

Thanks Cary for an elaborate reply. it seems that i am on right track.
now how do i prevent users from one BU accessing the machines, file &
folders from another BU? do we need to setup a group policy or something
else needs to be done. The catch here is that even machines should not be
accessed across BUs. Each BU should be indepenent of each other.

Thanks in advance
Brian.

 

[Cary Shultz [A.D. MVP]]

Brian,

Sorry for the delayed reply.

This would be controlled via Share and NTFS permissions. Well, for the
Files and Folders. I would suggest that you create a Folder for each BU.
You could then follow the prescribed MS way to do things ( create a global
security group that contains the users in question, create a local group,
make the global group a member of the local group and apply the NTFS and
Share permissions to the local group ) or you could come up with a way of
your own ( possible just create a local group for the one specific folder,
make the users in question a member of that group and apply the permissions
to that local group - you could do the same for a global group.... ).

For the machines I might look in to a DENY log on locally policy where you
give a group ( or groups ) an explicit DENY...

HTH,

Cary

 

[Sanjeev]

Thanks Cary for the reply....
i think i am all set to start now.
will put more questions if there are any.

Thanks again