Siêu thị PDFTải ngay đi em, trời tối mất

Thư viện tri thức trực tuyến

Kho tài liệu với 50,000+ tài liệu học thuật

© 2023 Siêu thị PDF - Kho tài liệu học thuật hàng đầu Việt Nam

building a cicso network for windows 2000 phần 5 pps
PREMIUM
Số trang
60
Kích thước
8.8 MB
Định dạng
PDF
Lượt xem
1185

building a cicso network for windows 2000 phần 5 pps

Nội dung xem thử

Mô tả chi tiết

214 Chapter 6 • Designing the Windows 2000 Network

When you determine the number of domains for the forest, begin with a

single domain model and grow from there. Although it is recommended

that you have complete documentation of the existing Windows NT domain

configuration, you will want to set that configuration aside while you

design the Windows 2000 Active Directory. Many legacy NT domains were

created for reasons that are no longer applicable to Windows 2000. For

example, the Windows NT domain SAM database was limited to 40,000

objects, while Windows 2000 Active Directory domains in native mode can

have up to a million objects or more. Another reason that organizations

created additional domains was for the purpose of separation or delegation

of administrative duties. With Windows 2000 Active Directory, administra￾tion can now be delegated within the organizational unit hierarchy, so this

reason is also no longer valid.

Each domain created will cause some additional traffic on the network.

However, since there is no longer a PDC that requires high availability to

all other BDCs, the network infrastructure does not have to provide high

availability to any single Windows 2000 domain controller (DC). Except for

where you need granular control over replication, you can completely

ignore physical infrastructure when you create domains. The following are

the reasons that may prompt you to create additional domains within your

forest.

Separate organizations If an enterprise has one or more subsidiaries or

partnership ventures, they each may require a separate domain, especially

if they each will require separate namespaces.

Domain security policy The domain level security policy that exists for

each domain is applicable only to a domain unit. For example, if one group

needs to have passwords changed every 60 days, and another group

requires passwords to be changed every 15 days, then they must belong to

separate domains.

Highly sensitive resource security If a business unit worked on

extremely sensitive data, it would add a level of security to provide that

unit a separate domain with its own administration.

Granular control over replication Each domain is a physical partition of

the Active Directory database. The objects within a domain are only repli￾cated to other DCs in that domain. Take, for example, an organization that

has two campuses located in two different countries. Each campus con￾tains 5000 or more users and has its own administrative group. If this

organization had a single domain, then any change made on any DC would

be replicated to the DCs in both countries. If this organization created a

domain for each country, then changes made to an object in one country

www.syngress.com

71_BCNW2K_06 9/10/00 12:46 PM Page 214

Designing the Windows 2000 Network • Chapter 6 215

would only be replicated within that country. (Note that this does not

reduce the replication of attributes that are copied to the global catalog.)

The first thing to do is create a logical design for your domains. Each

domain should have a known set of users and a function associated with

it. The next thing to do is to apply this design to the physical network. This

does not have to be an exact microscopic representation of each user and

relation to the network. However, it does have to depict the wide area net￾work (WAN) or low-speed links that a domain will span, as well as any vir￾tual private network (VPN) links, and will resemble Figure 6.6. What you

are looking for is a set of two or more domains that span the same link, or

for any domain with more than 10,000 objects that spans a WAN link. To

estimate the number of objects in a domain, multiply the number of users

by four. Once you identify these domains, you need to decide whether the

available bandwidth should be enough to handle the intra-domain traffic,

whether to upgrade the links, or whether to split the domain into smaller

ones. You must create two domains for a logical unit that is separated by a

link that allows only Simple Mail Transport Protocol (SMTP) traffic across

it. You will also want to create two domains when the logical unit spans a

“pay per bit” link, even if it is a high-speed, reliable connection. You may

prefer to change or upgrade the link if the original logical domain contains

a sizeable number of roaming users. If these roaming users are in a single

domain, they will have access to network resources regardless of the loca￾tion where they log on.

www.syngress.com

Ethernet network Token ring network

Ethernet network

root.com

branch.root.com

twig.root.com

Ethernet network

Figure 6.6 Logical domain structure applied to physical network.

71_BCNW2K_06 9/10/00 12:46 PM Page 215

216 Chapter 6 • Designing the Windows 2000 Network

You should have selected the root domain of the forest in your forest

plan. This domain will be the first domain installed for that forest. This

domain is critical because its loss (the loss of all of its DCs) can affect all

other domains in the forest; in addition, it can only be restored from

backup and cannot be reinstalled as a root. For this reason, you will want

the root domain to have at least one or more DCs located in different geo￾graphic locations to ensure the domain is always available.

The next thing to do is to logically organize the domains into a tree

structure and then apply DNS names to them. You should already know

how many namespaces you will need, and what they are, from the DNS

plan. You should also have as many logical domains as you have name￾spaces, or more domains than namespaces. For example, Acme has three

namespaces, acme.com, omega.com, and alpha.com. Acme.com has been

selected as the root domain for the forest. Acme’s domain plan lists four

domains, one for the Acme business, one for Omega and one for Alpha. In

addition, another domain was specified for Human Resources (HR) at Acme

because of the highly sensitive resources on that network. HR is located in

its own physically secure building in New York and does not share space

or administration with any other Acme business unit. The only domain

that would remain unnamed from a namespace point of view is HR’s

domain. Logically, because HR is within the Acme business, its domain

should be a subdomain of Acme.com. The name could reflect the unit or

its location, or another name that makes sense to the group. Possible

names include hr.acme.com, ny.acme.com, or something else that HR may

select. The final DNS/domain plan would look something like Figure 6.7.

NOTE

Even if you upgrade an existing Windows NT domain system to Windows

2000, you will need to establish new DNS names for each domain. If you

have fewer namespaces than you have domains, then you will also logi￾cally organize these domains into nested subdomains. Legacy Windows

NT domains used the NetBIOS Name System (NBNS) to assign names and

locate domains on the network. NBNS was a flat naming system with no

hierarchical organization to the system whatsoever. In addition, NBNS is

not a global system (whereas DNS is)—you cannot log on to a public

network and use NBNS to access resources. NetBIOS names still exist in

Windows 2000 as downlevel names for backward compatibility, but the

focal names for the domains are the DNS names in the format of subdo￾main.domain.com.

www.syngress.com

71_BCNW2K_06 9/10/00 12:46 PM Page 216

Designing the Windows 2000 Network • Chapter 6 217

Kerberos

The trusts within a forest are all based on Kerberos, a network authentica￾tion service developed for use on client/server networks and has since

been applied to use over the Internet.

Active Directory uses Kerberos to verify the identity of users, services,

resources, and domains. Kerberos does not rely on Windows 2000 or on

specific IP addresses to validate an identity. Kerberos uses credentials for

identity verification.

Windows NT trusts differ from the way that Kerberos trusts work. For

example, in a legacy Windows NT domain system, if the Zeus domain

trusted Hera domain, then it did not follow that Hera trusted Zeus.

Instead, a separate trust relationship had to be created for Hera to trust

Zeus. If we add in a third domain, Hercules, and Zeus trusts Hera and

Hera trusts Hercules, then in the legacy Windows NT world, Zeus did not

trust Hercules. This is illustrated in Figure 6.8.

www.syngress.com

acme.com forest

acme.com

omega.com alpha.com

hr.acme.com

Figure 6.7 Sample DNS/domain plan for Acme.

71_BCNW2K_06 9/10/00 12:46 PM Page 217

218 Chapter 6 • Designing the Windows 2000 Network

Kerberos trusts are both transitive and bidirectional, and they are

automatically created upon the installation of a domain into a forest. For

example, if Olympus.com were created and zeus.Olympus.com was installed

next, then zeus.Olympus.com would trust Olympus.com and Olympus.com

would trust zeus.Olympus.com. In addition, if hera.Olympus.com were

installed, then not only would it trust Olympus.com and vice versa, but the

trust relationship would flow through to zeus.Olympus.com, and

hera.Olympus.com would trust zeus.Olympus.com. This is illustrated in

Figure 6.9.

Figure 6.9 Transitive, bidirectional, Kerberos trusts.

www.syngress.com

Figure 6.8 Nontransitive, unidirectional, legacy Windows NT trusts.

Zeus

Hera

Legacy domains—the one-way trusts are non-transitive.

Hercules

olympus.com

zeus.olympus.com hera.olympus.com

Kerberos trusts are two-way and transitive. It is assumed that

zeus.olympus.com and hera.olympus.com trust each other

because of their trusts with olympus.com.

71_BCNW2K_06 9/10/00 12:46 PM Page 218

Designing the Windows 2000 Network • Chapter 6 219

Since Kerberos trusts are created automatically upon installation, you

do not need to do too much in the way of administration of them. However,

when you are planning access to resources, you do need to know how they

work.

Site Topology

The site topology is the formative basis for your infrastructure needs. Like

DNS and domains, however, your existing infrastructure is also the forma￾tive basis for your site topology. It is somewhat like the chicken and the

egg debate (which came first?), except that you are given an infrastructure

to start with and can change it after you establish the site topology—

which, once you change the infrastructure, may lead to changing the site

topology again. Take heart, though, the site topology, while critical, can be

adjusted at any point in time for any reason, and is done so in a fairly

straightforward manner.

The site topology represents the physical infrastructure in a logical

manner. There is only one site topology per forest. Sites are defined as a

set of well-connected IP subnets, which means that you really don’t want

to select an IP subnet out of a building in Germany, another from a

building in France, a third from a building in Australia, and then consider

that a site. Instead, you would define the IP subnets within the building in

Germany as one site, the IP subnets in France as another site, and the

Australian IP subnets as a third.

An interesting feature about sites is that they are not domain-centric. A

site can span a domain, or a domain can span a site. For example, there

can be two users who have computers on the same IP subnet, and so by

definition belong to the same site, as illustrated in Figure 6.10 where a

computer belongs to root.com and another belongs to domain.com. Each

computer belongs to a different domain, but the IP subnet only belongs to

a single site—this is an example of a site spanning domains. Likewise, two

users who have computers on different IP subnets in different sites can

both belong to the same domain—this is an example of a domain spanning

sites. This is also illustrated in Figure 6.10, since computers belonging to

the root.com domain exist in both Site 1 and Site 2.

Intrasite Replication Characteristics

Intrasite replication is the replication traffic that occurs within a single

site. This site may contain DCs from one domain or DCs from multiple

domains. The site may contain global catalog servers, or it may not have

any. The replication within the site will consist of updates to at least one

domain’s partition, the schema, and the configuration. More complex sites

will also have replication of additional domains and the global catalog.

www.syngress.com

71_BCNW2K_06 9/10/00 12:46 PM Page 219

Tải ngay đi em, còn do dự, trời tối mất!