As its name suggests, TCP/IP is actually two protocols used in concert with one

another.
Internet Protocol (IP) defines how network data is addressed from a source to a
destination
and in what sequence the data should be reassembled at the other end. IP operates
at the
network layer in the OSI Model. Transmission Control Protocol (TCP) is a higher-level
protocol
that operates one layer higher than IP, at the transport layer. TCP manages
connections
between computers. TCP messages are carried (encapsulated) in IP datagrams

IP packets include addresses that uniquely define every computer connected to the
Internet
(see Figure 7-1). These addresses are used to route packets from a sending node to
a receiving
node. Because all the routers on the Internet know the network addresses to which
they
are connected, they can accurately forward packets destined for a remote network.

IP addresses are made up of two main components. The first—the leftmost—is the
network
ID, also called the netid. The other is the host ID, usually written without the space
as hostid. The netid identifies the network, while the hostid identifies each node on
that
For a Class C address, for instance, the netid is set in the first three octets, while the
hostids use the fourth octet. For a Class B address, the first two octets are the netid,
while
the final two octets are hostids.

Subnet Masks
If you look at a computer’s IP configuration, you’ll see that the computer always has
both
an IP address (such as 205.143.60.109) and a subnet mask (such as
255.255.255.0). It is the
subnet mask that defines which part of the computer’s IP address is the netid and
which
part is the hostid. In order to see this clearly, you need to represent the addresses
in binary
form:
Computer IP Address (Dec): 205 143 60 109
Computer IP Address (Bin): 11001101 10001111 00111100 01101101
Subnet mask (Dec): 255 255 255 0
Subnet mask (Bin): 11111111 11111111 11111111 00000000
94 Networking: A Beginner’s Guide, Second Edition
The netid of an address, defined by the subnet mask, is whatever portion of the
address
has a binary 1 set in the corresponding subnet mask. In the preceding example, the
netid is the full first three octets (the first 24 bits), and the hostid is the last octet
(the last 8
bits). Now you can see why 255 (decimal) is used so frequently in subnet masks: It
is because
255 corresponds to having all bits set to 1 in an eight-bit number.

Novell’s IPX/SPX
Novell’s IPX protocol was originally a derivative of the Xerox Network Systems (XNS)
architecture and closely resembles it. While IPX can be used on any of the popular
network
media (Ethernet, Token Ring, and so forth), it was originally designed for Ethernet
networks
and works best with that media. In fact, the IPX protocol depends on EthernetMAC
addresses for its own addresses. IPX addresses are dynamic and are automatically
negotiated
with the server at login, rather than being statically set, as is the case with TCP/IP
without DHCP services. An IPX network address comprises both a 32-bit network
address
and a 48-bit node address. In addition, another 16 bits are used for a connection ID,
which allows up to 65,000 unique client/server connections between a client and a
server.
The address design of IPX theoretically allows for about 281 trillion nodes on each of
16
million networks.
IPX was originally designed only for LANs, but it has been enhanced to support
WANconnections. While typically considered a “chatty” protocol that requires a lot
of
send/acknowledgment transactions, IPX has been enhanced with burst-mode
capabilities,
which increase the size of packets destined for a WANand decrease the number of
back-and-forth communications required. IPX can be routed, but only if the network
includes
an IPX-capable router.
NetBIOS and NetBEUI Protocols
IBM originally developed NetBIOS and NetBEUI to support small networks. Microsoft
adopted the protocols as part of LANManager, a network operating system built on
top
of early versions of the OS/2 operating system.
Neither protocol is routable; each is suitable only for small LANs that do not rely on
routers between different LANsegments. However,NetBIOS can be encapsulated
within
TCP/IP packets on Windows NT networks using a service called NetBIOS over TCP/IP
(abbreviated as NBT).
Microsoft LANs (prior to Windows 2000) rely on a NetBIOS service called NetBIOS
names to identify each workstation uniquely.
In a simple NetBIOS implementation, names are registered with all workstations
through a broadcast message. If no computer has already registered a particular
name,
the name registration succeeds. In a more complex Windows NT–based network
that also
uses TCP/IP, however, the NetBIOS names resolve to TCP/IP addresses through the
use
of Windows Internet Name Service (WINS). The names can also be resolved using
static
name definition entries contained in a file called LMHOSTS (LANManager HOSTS).
Because
many networking applications still use NetBIOS names, either WINS or LMHOSTS
allows such applications to continue to function in a TCP/IP-only network. As far as
the
application is concerned, it is still working with NetBIOS, while TCP/IP performs the
actual
work in the background.

AppleTalk
AppleTalk has been extended in recent years into AppleTalk Phase II, which now
allows
routing of AppleTalk packets (assuming an AppleTalk Phase II–capable router). The
Phase II variant can run over Ethernet, Token Ring, or Apple’s LocalTalk media.
Under
Ethernet, AppleTalk uses a variant of the 802.2 frame type called Ethernet SNAP
(SubNetwork Access Point).
104 Networking: A Beginner’s Guide, Second Edition
While Apple Macintosh computers can use both TCP/IP and IPX/SPX through the
addition of special software, the Macintosh operating system is dependent on
AppleTalk,
so both TCP/IP and IPX/SPX are translated at each node into AppleTalk messages
before
being passed to the operating system. This translation process is one of the reasons
that
Apple Macintosh computers tend to be slower than other types of computers over
network
connections. Still, the approach works and is relatively easy to set up and maintain

Windows Server 2003 Web Edition

The Windows Server 2003 Web edition is a one- to two-processor Web front-end server version
of the operating system focused on application server needs that are dedicated to Web services
needs

Windows Server 2003 Standard Edition

The Windows Server 2003 Standard edition is the most common "file server" version of the
operating system. The Standard edition supports up to four processors per server, has full support
for file and print services functions, can act as a multiprocessor Web server, supports Terminal
Services, provides Media Services, can be set up as a utility server, and can support up to 4GB of
RAM.
The Standard edition is a good version of the operating system to support domain controllers,
utility servers (such as DNS, DHCP, bridgehead servers), file servers, and print server services.
Many small and medium-size organizations find the capabilities of the Standard edition
sufficient for most network services, and even large organizations use the Standard edition for
utility servers or as the primary server in a remote office. Effectively, any environment in which
a system with one to four processors is sufficient can meet the needs of the server functions.

Windows Server 2003 Enterprise Edition

The Windows Server 2003 Enterprise edition is focused on server systems that require up to
eight processors and/or up to 8-node clustering for large scale-up server configurations. With
support for up to 32GB of RAM as well as a 64-bit Itanium version available, the Enterprise
edition is the appropriate version of operating system for high availability and high processing
demands of core application servers such as SQL Servers or large e-commerce back-end
transaction systems.

Windows Server 2003 Datacenter edition is a proprietary hardware version of the operating
system that supports from 8 to 64 processors and up to 8-node clustering. The Datacenter edition
is focused on organizations that need scale-up server technology to support a large centralized
data warehouse on one or limited numbers of server clusters.

In 2005, Microsoft shipped an x64-bit edition of the Windows 2003 operating system to support
64-bit processors. The x64-bit version of Windows 2003 provides support for more memory
access and faster server performance that ultimately increases the scalability capabilities of the
Windows networking environment.

What Is a Directory Service?

In any business-level networked environment, there exists some sort of database of
account information.
In Windows NT, this database was known as the Security Accounts Manager (SAM)
database,
and in early versions of Novell NetWare, it was known as the bindery. No matter
what network
operating system you look at, there has to be a place in which information about
valid users is
stored—things like names, passwords, and maybe even a little security information.
In many operating systems, this accounts database is server- or resource-centric.
By this I mean
that the database only stores information about users who have access to the
resources (files, printers,
applications, etc.) located within the sphere of control of the device upon which the
database is stored.
Novell’s bindery is a perfect example; it stored account information for users who
could access a specific
server (the server in which the bindery files were located). While this type of system
is workable in
smaller environments, it begins to fall apart as networks grow. Think about it: if
every server has its
own accounts database, and I have 100 servers, then I have 100 accounts
databases to manage.
A directory service is a networkwide database that stores resource information,
such as user accounts.
In a directory-based environment, I create a single user account for each user, and
that account is used
to manage all aspects of the user’s network (and sometimes desktop) environment.
To put this another
way, a directory service provides a place to store information about network-based
entities, such as
applications, files, printers, or people. Given the networkwide scope of such a
database, it provides a
consistent way to name, describe, locate, access, manage, and secure information
about those individual
resources.
The directory also acts as the central point of control and management for the
network operating
system. It acts as the central authority to properly identify and authenticate the
identities of resources,
and it brokers the relationships between distributed resources, thus allowing them
to work together.
The directory service must be tightly coupled with the underlying operating system
to ensure the
integrity and privacy of information on the network.
In a Microsoft-based network, the Active Directory Service plays a critical role in an
organization’s
ability to manage the network infrastructure, perform system administration, and
control the user
environment.
Why Use a Directory Service?
When I first started in the networking industry, I worked on what, at the time, was a
midsized
environment—we had four servers and about 200 users. The Internet was still a
thing of the future,
WHY USE A DIRECTORY SERVICE? 5
e-mail wasn’t mission critical (heck, most people didn’t even know what e-mail
was), there was no
such thing as a “fax server” or any other kind of specialized server for that matter,
and FedEx was
used to transfer documents from one site to another (no one would have thought to
invest in a wide
area link for a medium-sized company—they were too expensive).
Today, a midsized environment can include 50 or more servers, support hundreds, if
not thousands,
of users, and include numerous special services that run on dedicated servers. Wide
area links
are common, and bandwidth demands are astronomic! Not to mention the dial-in,
VPN, and other
“new” services that end users are demanding. In these complex networks, the task
of managing the
multitude of network-based resources can be overwhelming.
Directories help administrators manage today’s complex environments by:
◆ Simplifying management. By acting as a single point of management (and

providing a consistent
set of management tools), a directory can ease the administrative tasks associated
with complex
networks.
◆ Providing stronger security. Once again, the fact that access and authentication is

controlled
through a single service, administrators and users are only required to know a
single set of
tools, allowing them to develop a better understanding of them. Directories, since
they offer
a single logon facility, are usually able to provide a more secure authentication
process (since
all logons are managed through a central service, that service can be made
extremely secure).
◆ Promoting interoperability. Most of today’s commercially viable directory services

(AD included)
are based upon a series of industry standards—X.500 and LDAP to name a few (I’ll
describe
these in detail later). Sticking with a standards-based solution makes it easier to
share resources in
a mixed environment or, better yet, to share resources with business partners
without opening too
many doors into your network.
Directories can be thought of as both a management and a user tool. From a
management perspective,
having a centrally controlled and consistent interface to resource information can
drastically
reduce administrative costs. From a user’s perspective, a central service for
authentication can
make accessing resources throughout the network a lot easier. Gone are the days
when users had to

memorize (or worse, write on a Post-It note) multiple logon names and
passwords!

In the field of computer networking and other packet-switched telecommunication networks, the
traffic engineering term quality of service (QoS) refers to resource reservation control
mechanisms rather than the achieved service quality. Quality of service is the ability to provide
different priority to different applications, users, or data flows, or to guarantee a certain level of
performance to a data flow. For example, a required bit rate, delay, jitter, packet dropping
probability and/or bit error rate may be guaranteed. Quality of service guarantees are important if
the network capacity is insufficient, especially for real-time streaming multimedia applications
such as voice over IP, online games and IP-TV, since these often require fixed bit rate and are
delay sensitive, and in networks where the capacity is a limited resource, for example in cellular
data communication.

The Service Advertising Protocol (SAP) is included in the Internetwork Packet Exchange (IPX)
protocol. SAP makes the process of adding and removing services on an IPX internetwork
dynamic. SAP is maintained by Novell.

As servers are booted up, they may advertise their services using SAP; when they are brought
down, they use SAP to indicate that their services will no longer be available. IPX network
servers may use SAP to identify themselves by name and service type. All entities that use SAP
must broadcast a name and Service Type that (together) are unique throughout the entire IPX
internetwork. This policy is enforced by system administrators and application developers.

Provided by Microsoft, Client Services for NetWare, or CSNW, is a tool that allows
users to access files, printers and other computers that are connected to remote Novell
NetWare networks.

Use

1. If your computer is running a version of Windows that includes CSNW, and you have
access to a secure remote NetWare server , you can use CSNW to communicate with the
remote server.

How Does It Work?

2. CSNW is a redirector. It sends requests from your computer to the remote server. The
remote server processes the request then responds to your computer. If you have access,
you will then be able to manipulate resources, like files or printers, on the remote server.

Access

3. You'll need a valid connection, which will likely require a secure login, to a remote
NetWare server in order to access its resources.

Restrictions

4. According to Microsoft TechNet, CSNW is not available on 64-bit versions of Windows

Server 2003 and Windows XP .

Alternatives

5. If you decide not to use CSNW but still need to access resources on a remote NetWare
server, you can use Novell Client.
Read more: What Is Client Services for NetWare? | eHow.com
http://www.ehow.com/facts_5563106_client-services-netware.html#ixzz0vKu665qY
Active Directory Domains
You might recall the definition of a domain from earlier versions of NT: a logical
grouping of computers
and users managed through a central security accounts database. According to this
definition,
a domain was:
◆ Logically, an organizational grouping of resources allowing central management of
those
resources
◆ Physically, a database containing information about those resources
Combining the logical with the physical gave you a management or security
boundary; administrators
for a domain could manage all resources in that domain (database) by default.
The definition of a domain has not changed in Windows 2000 or the Windows Server
2003 products.
A domain still represents a group of resources and is still really just a logical
description of a database
(the Active Directory database). But as we’ve already discussed, what have
changed—and changed
considerably—are the types of information that the domain database can contain.
Domains now act as the basic building blocks of an AD environment. As such, AD
design starts
here, at the domain level. It’s imperative that you have a solid, secure, and efficient
domain plan in
place before you move to any other aspect of creating your Active Directory tree.
The Root Domain
It all starts at the top of the structure with the creation of the first domain in your
environment. This
domain, the first created, is known as the root domain. It acts as the beginning of
your AD namespace.
All subsequent domains will be influenced by your choices here in the beginning!
The name given to the root domain will act as the base for the name of all domains
created later. As
each subsequent domain is added to the structure, it will be added somewhere
below the root domain.
Additional domains are always children of some other domain in the tree. The only
domain that is not
a child is the root (topmost) domain. This concept is illustrated in Figure 8.1.
KingTech.com
Root Domain
Figure 8.1
The root domain
AD BUILDING BLOCKS 155
In Figure 8.1, the first domain for the company King Technologies has been named
KingTech.com.
As the first domain added to the tree, it becomes the root domain. All subsequent
domains will follow
the naming pattern of <something>.KingTech.com, as shown in Figure 8.2.
Figure 8.2 demonstrates the principle of hierarchical naming. Each subsequent
domain adds the
names of all domains above it together to create a distinguished name.
The Difference between DNS and AD Domains
For some reason, our industry often uses the same term to represent completely
different things.
In Chapter 7 we discussed DNS (Domain Name System) domains. A DNS server is
used to resolve
TCP/IP host names into IP addresses. A DNS domain represents a piece of the
overall DNS namespace.
DNS is a service used to find resources: A process submits a host name, and DNS
attempts
to find a record that matches. If a match is found, DNS returns the appropriate IP
address to the
requestor. As such, we could define a DNS domain as a bounded portion of a DNS
namespace used to find IP
host information.
In this chapter, we will discuss NT domains, concentrating on how they relate to
Active Directory.
For our purposes, we can define an NT domain as a bounded area of an AD
namespace used to organize network
resources.
Comparing the two definitions, we can make two generalizations:
◆ DNS domains are for finding resources.

◆ AD domains are for organizing resources.

DN=Seattle.KingTech.com
DN=Sales.Tampa.KingTech.com
DN=Tampa.KingTech.com
Figure 8.2

trees

This concept of creating multiple domains brings us to the topic of this section:
creating Active
Directory trees. We’ve already discussed the importance of the first, or root,
domain. It sets the
beginning of the namespace for the AD tree—in other words, the name given to the
topmost, or
first, domain in the structure will impact the name of all subsequent domains. As
you create additional
domains, they will join the AD tree somewhere below the root domain, forming a
treelike
structure (with the root at the top).
Remember that each domain represents a separate directory database. Each
database also acts as a
security boundary and is individually protected against unwanted access (we’ll
discuss AD security in
Chapter 10). As I mentioned earlier, for instance, administrators of one domain are
not necessarily
administrators of any other. But you can set up your system so that a small group of
administrators
have security privileges over the entire structure, or you can give a group
administrative abilities in a
select few domains. You can also give users permission to access resources
throughout the tree. This
implies that there is some mechanism that allows security to be managed and
maintained between

domains. This mechanism is known as a trust.

Active Directory Forests

In our discussions so far, we have limited ourselves to environments with only one
AD tree. In a singletree
environment, each domain is added to the structure as a new partition of a single
database to create
the tree, as shown in Figure 8.11.
168 Chapter 8 DESIGNING THE ACTIVE DIRECTORY ENVIRONMENT
This configuration works well in most environments, but it has one big limitation: all
objects
within the structure must be a part of the same namespace.
Note Remember that within a namespace, all objects have some common
component to their name.
In the case of KingTech, the name of every object will end in .KingTech.com. Therein
lies the
problem: what if a company has a reason for some objects to belong to one
namespace and other
objects to a different namespace? Such a situation might occur when an
environment requires a
substantial amount of separation between domains that must still share resources.
For instance,
partnerships or joint ventures might require that two distinct businesses share
resources. These
two companies would each have a unique namespace, so both could not fall under a
single root
domain.
Two separate AD trees can establish a relationship, thereby forming an AD forest. A
forest is just a
collection of trees that share a common schema and Global Catalog server (I’ll
discuss the Global
Catalog in a few pages). The trees establish a two-way transitive trust relationship
between their root
domains, as shown in Figure 8.12.
KingTech.com
Tampa Reno
Paradigm
Shift.com
St. Paul Orlando
Figure 8.12
An AD forest
KingTech.com
Domain
Tampa
Domain
Reno
Domain
Sales
Domain
Education
Domain
Figure 8.11
Single-tree
environment
AD BUILDING BLOCKS 169
Once you’ve established this relationship, you have formed a forest. A forest allows
you to do the
following:
◆ Search across all domains through a common Global Catalog server.
◆ Maintain existing DNS names (during an acquisition, for instance).
When to Create a Forest instead of a Single Tree
This is actually a fairly simple decision. If your company requires multiple
namespaces, then separate
trees are mandated. Once this decision has been made, you must then decide if the
trees should create
a formal relationship (create a forest) or if a single external trust will suffice.
Remember, an external
trust is nontransitive.
Ask yourself how much interaction occurs between the two environments. If the two
namespaces
represent two divisions or separate companies that fall under the umbrella of a
single controlling
company, then a forest is the best way to go. If the entities represented by the two
namespaces are in
fact completely separate companies—for example, business partners—then an
external trust might
suffice.
Here’s the crux of the problem: the trees within a forest must share a couple of
things—a common
Global Catalog and a common schema. We’ve discussed the function of the AD
schema; it defines the
structure of the AD database. Since trees within a forest must share a common
schema, then any changes
to the schema must be replicated to all domains within the forest. This doesn’t
sound like too big an issue
until you realize that someone must have Schema Admin rights to the schema of
the overall structure. If
all the domains fall within a single parent company, this is usually not too big an
issue. If, however, the
domains truly represent separate business entities, then this often becomes a bone
of contention. Not
many IT departments want some “outside group” of administrators to have that
level of access to their
environment. We’ll discuss the function of the Global Catalog in a little bit, but the
same issue exists
there—within a forest, the common Global Catalog must be accessible to someone.
Microsoft’s marketing literature suggests creating a forest of the AD trees of your
company and one
or more trees of your business partners or vendors. I’ve tried this a couple of times
in the field, and it
usually becomes a political minefield. Neither company wants to give the other
company’s IT department
the ability to change their schema. If one company, for instance, decides to install
Microsoft Exchange
2000 Server (a program that requires changes to the standard AD schema), then
those changes must be
replicated to the schema of all other trees in the forest. If those changes are done
incorrectly, then the

schema of all trees within the forest can be adversely affected.

AD Organizational Units
So far in this chapter, we’ve discussed Active Directory domains, trees, and forests.
We’ve also discussed
a few of the AD roles that servers can be assigned to provide directory functionality.
Let’s
think for a minute of what some of our discussions so far imply in a real-world
environment.
First, I’ve said that an AD domain can support more than a million objects—users,
computers,
groups, etc. I’ve also suggested that you limit the scope of a domain, either to
reduce the overall
number of objects within the database or to control replication traffic between
physical locations.
After our discussion of AD trees—multiple domains tied together with transitive
trusts—the next
logical step was to tie these trees together to form forests, usually to support
multiple namespaces
while still retaining the ability to centrally manage the environment. So far, so good,
right?
In your mind’s eye, you should be visualizing a series of domains tied together to
represent your
company’s network resources. If you are, then you are on the right track, and you
have the proper
mindset for AD—it’s all just a graphical representation of the things you need to
manage on your
network. See any problems yet?
Think about managing the AD tree of a large company. You’ve got multiple
locations, so you create
multiple domains. Maybe you’ve got a few independent business units that demand
you support their
established naming standards, so you create multiple trees and bring them together
into a single forest.
AD ORGANIZATIONAL UNITS 181
Okay, great, but now what? In a large company, a single site can easily have
thousands of users. In AD
terms, this would result in thousands of user objects, their associated computer
objects, a large number
of group objects, and tons of other objects created in a single domain.
Now imagine trying to manage that number of objects. In your mind, see yourself
opening the Active
Directory Users and Computers tool. What do you see? An endless list of thousands
of objects—hopefully
at least sorted alphabetically—from which you need to pick and choose when
managing? In reality,
this type of representation of your resources would be unmanageable, and it’s one
of the reasons that an
NT environment needed so many domains.
When we talked about the X.500 recommendations, we discussed the use of
container objects to
organize the resources represented in the directory. These container objects did not
represent physical
resources; instead they acted as tools to organize the resources into logical
groupings. Since they are
used to organize your resources, it makes sense that they are called organizational
units (OUs).
In many ways, planning the structure of the OUs in your environment is more
complex than
designing the domain, tree, and forest structure. Since domains usually represent
physical locations
or separate business units, finding the scope of any given domain is usually fairly
straightforward.
Likewise, AD trees are just groupings of domains—again, fairly easy to visualize.
The same holds
true for forests: each represents a unique namespace; finding its limits is easy!
OUs, on the other hand, are used to organize actual resources—user accounts,
printers, servers,
etc. While the scope of a domain is usually easy to find, creating OUs can be
confusing. OUs tie
resources into logical groupings; as we’ll see later, these groupings can represent
departments, locations,
or even projects. Placing your resources into the appropriate OUs can greatly ease
long-term
administration—it’s planning the groupings that cause the headaches. Take
printers, for instance. In
most companies printers are used by whichever users are located near them. If your
OU structure
mirrors the departmental structure of your company (sales, marketing, production,
administration,
etc.), which OU should contain the object of a printer? The printer might be used by
people from
many of these departments, but the printer can have only one record in the tree.
Okay, you say, then I’ll create OUs to represent locations. That will fix the problem;
now the
printer object goes in the OU that represents its location. But what if you need to
manage user
accounts by department?
See what I mean? Planning an OU structure that helps you manage your resources
can be kind of
tricky.
What Are OUs Used For?
OUs form logical administrative units that can be used to delegate administrative
privileges within a
domain. Rather than add another domain to an existing structure, it is often more
advantageous to
just create another OU to organize objects.
Organizational units can contain the following types of objects:
◆ Users
◆ Computers
◆ Groups

◆ Printers
182 Chapter 8 DESIGNING THE ACTIVE DIRECTORY ENVIRONMENT
◆ Applications
◆ Security policies
◆ File shares

◆ Other OUs