Re: Site or Domain
- From: "Jorge Silva" <jorgesilva_pt@xxxxxxxxxxx>
- Date: Wed, 9 Aug 2006 19:48:38 +0100
Hi
Here's my VERSION ENJOI
First thing:
Domain aren't security Boundaries, Only forests are security Boundaries.
Domains should not be used as administrative boundaries
Active Directory domains, unlike Windows NT domains, are always part of a
forest, and they are not themselves the ultimate security boundary. For
Windows 2000 and later networks, though, domains are the boundaries for
administration and for certain security policies, such as password
complexity and password reuse rules, which cannot be inherited from one
domain to another. Each Active Directory domain is authoritative for the
identity and credentials of the users, computers, and groups that reside in
that domain. However, service administrators have abilities that cross
domain boundaries. For this reason, the forest is the ultimate security
boundary, not the domain.
A domain is, in fact, a security boundary, but only regarding to the
management of security policies for Active Directory, it does not provide
complete isolation in the face of possible attacks by service
administrators.
Reasons to Create Multiple Domains: Meet security requirements,Meet
administrative requirements,Optimize replication traffic,Retain Microsoft
Windows NT domains.
Do not create multiple domains to accommodate polarized groups or for
isolated resources that are not easily assimilated into other domains. Both
the groups and the resources are usually better candidates for
organizational units (OUs).
When determining whether to create multiple Domains, keep the following
items in mind:
- DNS structure becomes more complex.
- Hardware costs increases.
- Domain administrators Each time a domain is added, a Domain Admins
pre-defined global group is added as well. More administration is required
to monitor the members of this group.
- Security principals As domains are added, the likelihood that security
principals will need to be moved between domains becomes greater. Although
moving a security principal between OUs within a domain is a simple
operation, moving a security principal between domains is more complex and
can negatively affect users.
- Group policy and access control Because group policy and access control
are applied at the domain level, if your organization uses group policies or
delegated administration across the enterprise or many domains, the measures
must be applied separately to each domain.
- Domain controller hardware and security facilities Each Windows Server
2003 domain requires at least two domain controllers to support
fault-tolerance and multimaster requirements. In addition, it is recommended
that domain con-trollers be located in a secure facility with limited access
to prevent physical access by intruders.
- Trust links If a user from one domain must log on in another domain, the
domain controller from the second domain must be able to contact the domain
controller in the user's original domain. In the event of a link failure,
the domain controller might not be able to maintain service. More trust
links, which require setup and maintenance, might be necessary to alleviate
the problem.
- General recommendations for FSMO placement
Place the RID and PDC emulator roles on the same domain controller.
If the load on the primary FSMO load justifies a move, place the RID and
primary domain controller emulator roles on separate domain controllers in
the same domain and active directory site that are direct replication
partners of each other.
-As a general rule, the infrastructure master should be located on a
non-global catalog server that has a direct connection object to some global
catalog in the forest, preferably in the same Active Directory site. Because
the global catalog server holds a partial replica of every object in the
forest, the infrastructure master, if placed on a global catalog server,
will never update anything, because it does not contain any references to
objects that it does not hold. Two exceptions to the "do not place the
infrastructure master on a global catalog server" rule are:
*Single domain forest:
In a forest that contains a single Active Directory domain, there are no
phantoms, and so the infrastructure master has no work to do. The
infrastructure master may be placed on any domain controller in the domain,
regardless of whether that domain controller hosts the global catalog or
not.
*Multidomain forest where every domain controller in a domain holds the
global catalog:
If every domain controller in a domain that is part of a multidomain forest
also hosts the global catalog, there are no phantoms or work for the
infrastructure master to do. The infrastructure master may be put on any
domain controller in that domain.
-At the forest level, the schema master and domain naming master roles
should be placed on the same domain controller as they are rarely used and
should be tightly controlled. Additionally, the domain naming master FSMO
should also be a global catalog server. Certain operations that use the
domain naming master, such as creating grand-child domains, will fail if
this is not the case.
Sites are important to define were users have priority to logon (which site
DC/Gc,etc)...
Sites have to main roles:
- To facilitate authentication, by determining the nearest domain controller
when a user logs on from a workstation
- To facilitate the replication of data between sites Because site names are
used in the records registered in the Domain Name System (DNS) by the domain
locator, they must be valid DNS names.
Active Directory uses sites to:
- Optimize replication for speed and bandwidth consumption between domain
controllers.
- Locate the closest domain controller for client logon, services, and
directory searches.
- Direct a Distributed File System (DFS) client to the server that is
hosting the requested data within the site.
- Replicate the system volume (SYSVOL), a collection of folders in the file
system that exists on each domain controller in a domain and is required for
implementation of Group Policy.
As for the GCs UGMC:
First: The GC enables finding directory information regardless of which
domain in the forest contains the data, and provides Universal Group
Membership Information. Applications also use the first (any object in the
forest) Exchange is the prototypical example of this. (Windows 2003 has the
UGMC (Universal Group Membership caching which isn't the same thing as the
GC, there are some people that doesn't recomend the use of the UGMC, you
should know that is only recomended for sites with less than 100 users, it
can caches 500 Universal Group membership, and refresh its cache every 8
hours, the users need to logon at least one time to their group membership
to cached ).
Second: The GC is only needed when you have DFL (Domain Functional Mode) in
Native Mode or later where Universal security groups are allowed, more than
one domain or if you use any app that needs to contact the GC (Exchange is
an example), if you need to logon with a UPN.
Third: There's a registry setting "IgnoreGCFailures" that you can use in
particular scenarios to force a particular DC NOT TO CONTACT a GC for
authentication process. If you don't use Universal groups for securing
things then you can enable IgnoreGCFailures which will allow you to log on
even if a GC isn't abailable in a Native mode domain. However, if you have a
single domain there is no reason not to make every DC a GC. Note that even
with IgnoreGCFailures enabled, you could run into cases where a GC is needed
say when trying to logon with a UPN, etc.
Fourth: Good practices are to have at least one GC per site, even in a
single domain forest, every DC ALREADY holds ALL of the info so making a DC
a GC costs practically nothing.
The above is also true in a SMALL forest with multiple domains.
As forest size increases the penalty for creating a GC (increase
replication, increased storage) increases.
--
I hope that the information above helps you
Good Luck
Jorge Silva
MCSA
Systems Administrator
"Paul Bergson" <pbergson@xxxxxxxxxxxxxxxxx> wrote in message
news:%23tMoY19uGHA.4456@xxxxxxxxxxxxxxxxxxxxxxx
Single forest and domain with multiple sites as long as you can be
gauranteed that the dc's in China are secure. Otherwise I would go with
the Chinese domain as a child of your forest root.
Management of user, security and distribution groups, etc... are all much
simpler in a single domain structure.
--
Paul Bergson MCT, MCSE, MCSA, Security+, CNE, CNA, CCA
http://www.pbbergs.com
Please no e-mails, any questions should be posted in the NewsGroup
This posting is provided "AS IS" with no warranties, and confers no
rights.
"tke402" <tke402@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:7E5BB7CC-EFDC-40A7-BC56-87B9CD9862BF@xxxxxxxxxxxxxxxx
Hi,
I'm in the process of planning an expansion of my company to China. I'm
hung
up on whether to make the new facility in China a site in our existing
single
domain, or create a new domain. Some background information: There will
be a
T1 connection between the facilities. Headquarters has 150 users, China
will
have 20 users. As of this time, there is no requirement for different
account
policies. All IT support will be remote from headquarters.
Given this what are some opinions? What are some advantages and
disadvantages of having China as a site vs a Domain? Anyone out there in
this
surrent situation? And how do you currently do it?
Thanks
Chris
.
- References:
- Re: Site or Domain
- From: Paul Bergson
- Re: Site or Domain
- Prev by Date: Re: Password GPO
- Next by Date: Re: Security Group Keeps getting removed???
- Previous by thread: Re: Site or Domain
- Next by thread: Re: Site or Domain
- Index(es):
Relevant Pages
|
|
