Tải bản đầy đủ (.pdf) (40 trang)

Tài liệu Introducing Active Directory pdf

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (177.05 KB, 40 trang )

Introducing
Active Directory
T
he directory service has become one of the hottest new
technologies on corporate networks. Microsoft, a new
member of the directory service club, has created a directory
service on which almost its entire product line depends.
Understanding Active Directory is thus a prerequisite to
any management or deployment of Windows 2000.
In the 1970s, all the computing resources you needed, or could
use, were on the same computer or the terminal you logged on
at. In the 1980s, with the advent of the PC LAN, many files were
located on remote machines, and there were definitive paths
to these machines. LAN users shared the files and printers,
and exchanged e-mail on the LAN. Before the end of the 1990s,
we witnessed the beginning of the paradigm shift where all
information and functionality could be accessed on any server
on any network anywhere . . . and the user did not need to
know where the objects were physically located.
This is the ideal computing model in which all network
objects — servers, devices, functionality, information, authen-
tication, and the transports — combine to become a single
contiguous information system and computing environment.
This environ-ment allows users, whether human or machine,
to attach — or remain attached—to systems from a consis-
tent user interface at any point of entry on the network. No
matter what users require — be they functions of a device,
communication, process, algorithms, or perhaps just infor-
mation and knowledge — they must be able to access such
an object without regard for its physical location.
The Active Directory is Microsoft’s bold leap to realizing the


dream of a truly distributed environment and IS architecture.
It has been talked about for many years. Headlines in the
technical trades were always gloomy. And thus, many network
administrators and systems engineers forgot about the
2
2
CHAPTER
✦✦✦✦
In This Chapter
The Origins of
Active Directory
The Elements of
Active Directory
Comparing Windows
NT and Windows
2000 domains
✦✦✦✦
4667-8 ch02.f.qc 5/15/00 1:56 PM Page 25
26
Part I ✦ Windows 2000 Server Architecture
directory and worked hard to refine or improve what was already in place, at
considerable investment. But now the directory is here. And you probably have
little idea what it is and how to use it. You should not feel ashamed, because not
only are you not alone, but also it is unlike anything you have ever used before.
Every day people ask us about the Active Directory (and these are not only Windows
NT or UNIX and NetWare professionals, but also mid-range and mainframe engineers).
The purpose of this chapter is to drill down to its core, to expose the elements, and
to lay the foundations to bring what’s precious to the surface, and then move for-
ward. First, you must understand everything about the Active Directory (AD) before
you can make the transition from the old ways of managing networks and computing

environments to the promise that waits.
In this chapter, we discuss the elements of AD. We will kick off with a brief discussion
of how and why we will use AD, and from whence it came. Then we break it down into
its constituent components (its logical structure), and finally we discuss how the
components work and interoperate with each other. You will notice that the subject
of Windows domains and trusts is going to be left until a full discussion of the AD has
been achieved.
This chapter also features the first appearance of Millennium City, or
mcity.org
,
which is the example Windows 2000 network infrastructure we use throughout the
book. It’s a network that runs the infrastructure of an entire city, and its Active
Directory is what we used to test the limits of what Microsoft says it’s capable of.
MCITY is essentially one huge Active Directory laboratory.
You don’t need to be in front of your monitor for this chapter. Just curl up with
some snacks and postpone any appointments you might have.
The Omniscient Active Directory:
Dawn of a New Era
The Windows NT client-server architecture was a great improvement over other
server and network offerings, both from Microsoft and other companies. However,
it had a shortcoming that, had it not been resolved in Windows 2000, would have
suffocated the advancement of this highly sophisticated operating system. On
Windows NT— actually any network — resources are not easily distributed. The
interoperation and scalability of numerous NT servers, printers, shares, devices, files,
knowledge resources, functionality, and the sustained availability thereof, collapse
when the ability for all network components and objects to share information is
absent. As discussed briefly in Chapter 1, one of the most significant additions to
Microsoft’s technology is the Active Directory. There is perhaps no other aspect of
Windows 2000 that will have the impact the directory service will, because just about
every new feature or ability of this product depends on a directory service.

4667-8 ch02.f.qc 5/15/00 1:56 PM Page 26
27
Chapter 2 ✦ Introducing Active Directory
Before we haul out the dissecting tools, know this:
✦ The Active Directory service is critical to the deployment and management of
Windows 2000 networks, the integration and interoperation of Windows 2000
networks and legacy NT networks, and the interoperation and unification of
Windows 2000 networks with the Internet. Its arrival is a result of the evolu-
tionary process of Microsoft’s server and network technology. One way or
another, the directory service is in your future.
✦ The Active Directory is a powerful directory service, either as part of a
Windows network or as a standalone service on the Internet. In the latter
role, it is an apt contender as a directory service in the same fashion Internet
Information Server is an apt contender for a Web server. In other words, no
querying client on the Internet needs to know the directory is Windows 2000
AD. Active Directory is 100 percent LDAP-compliant and 100 percent
IP-compliant.
Why Do We Need Directories?
A directory provides information. At its most basic level, it is like a giant white
pages, allowing a user to query a name and get back a phone number . . . and then
possibly being connected to the person by automatically dialing that number. But a
directory in the IT world is a lot more than a telephone book. Before getting into the
specifics of AD, let’s look at some reasons why we need directories. We kick off by
placing AD at the center of all services provided by Windows 2000.
Single Sign-On and distributed security
Active Directory makes it easier to log in to and roam cyberspace. Imagine if you
had to log in at every mall, highway, turnpike, newsstand, public facility, sports
amenity, shop, fast food outlet, movie house, and so on, in the brick and mortar
world we live in. Why then should we have to do this in cyberspace?
In every company today, it is almost impossible to get anywhere on the network

without going through at least three logins. Everyday, we log into NetWare, the
Windows NT domains, voice mail, the host system (to the AS/400 via Rumba),
FTP, and then finally the Internet; we won’t go into how many accounts and logins
we have.
Not only do we have to log in dozens of times a day, and remember dozens
of passwords and user or login IDs, but we also have to know exactly where
information and resources are located on the network. The uniform resource
locator on the World Wide Web has alleviated the resource location problem to
some extent (it obviates having to know exactly where something lives on the
Internet), but it is still not ideal and not very smooth. URLs are perishable, and
for the most part unmanageable in large numbers, which means they often do
not get updated. They are not managed in any sensible, cohesive system.
4667-8 ch02.f.qc 5/15/00 1:56 PM Page 27
28
Part I ✦ Windows 2000 Server Architecture
The ideal is some sort of badge that allows us to log in once and then flash it
wherever we go. For starters, every application and service on our LANs, from
e-mail to voice mail to data access to printer access, should be made available
to us through one universal login, at home or at work. The type or level of access
we have will depend on the attributes or “clearance level” of our badges. The
access token provided by Windows NT security comes close to this, but it is not
accepted by other technologies as a valid means of authentication. Figure 2-1
illustrates several systems that should be accessed and managed from a central
login authority. In many cases, this is already possible with Active Directory-
compliant applications such as SQL Server 2000 and Exchange 2000.
Figure 2-1: Active Directory as a central login authority
Active
Directory
Intranet Cloud
Internet Cloud

Customers: Orders
Customers: Help Desk
Customers: Catalogs
Customers: Websites
Suppliers
Manufacturers
Public Relations
Partners
Investors
Extranet Applications
Security
Administrators
Technical Support People
Groups and Users
Printers, Computers, Equipment
Data and SQL Server Users
ERP and CRM and Payroll Systems
Helpdesk Users
E-mail and Groupware Users
Voicemail and Fax Users
Internal Applications
Remote Users and Road Warriors
Vertical and Horizontal Application
Security
Host Access
LDAP entry point and
other LDAP compliant directories
Organization White Pages
(e-mail, phone, and fax addresses)
Catalog Searching

Interconnection with other directories
Internet Users
Internet Road Warriors
Extranet Access
Security
Extranet Cloud
4667-8 ch02.f.qc 5/15/00 1:56 PM Page 28
29
Chapter 2 ✦ Introducing Active Directory
As you will learn in Chapter 3 and in the chapters in Part III, the single login dream
is achieved using the services of AD and Windows 2000 support for MIT’s Kerberos
authentication. This service is known as Single Sign-On (SSO). SSO has become a
quasi-standard among supporters of the Kerberos protocol, such as Microsoft,
Apple, Sun, and Novell.
Once a trusted user is authenticated via the Kerberos protocol, all other services
that support the Kerberos protocol can accept and allow access to the principal.
This is made possible by the Kerberos use of tickets— the badge idea previously
discussed — which are issued by the directory service.
In Chapter 1, we also told you that the Microsoft network domain architecture in
Windows 2000 has been radically overhauled to seamlessly integrate with the AD
and to extend out to the Internet. Imagine being able to log in to your domain from
anywhere. We will be discussing this in much more depth in a later chapter.
Change management
Active Directory makes it easier to manage the roamers and users of cyberspace
and corporate networks and the computers they use to attach to the network. We
administrators want to be able to manage our users and computing resources in
one central omnipresent repository. We don’t want to repeatedly manage users in
the voice mail directory, on the NetWare servers’ directory, in the Host systems
database, in our e-mail directory, on our Windows domains, and so on.
And we, as managers, need to be able to manage this information easier with

change. Mergers, acquisitions, new products, and services need to be continually
managed on a cohesive and consistent basis. Group Policy, the change control and
change management service of Windows 2000, stores all user and computer
information in AD (as discussed in the section on ZAW in Chapter 1).
Distributed administration
Active Directory lets you delegate administrative function and responsibility and
lets you parcel out chunks of the network or domain for controlled administration.
A distributed directory service makes it possible to delegate the administration of
network resources and users throughout the enterprise. On legacy NT, you can
create users and groups with administrative rights, but it is well nigh impossible
to hide other network resources from these administrators.
Because Active Directory can be partitioned as a mirror of the structure or
organization of the enterprise, it is also possible to partition the administration
of the compartments. In other words, it makes more sense to appoint a member
of a department to perform repetitive management of that department’s resources.
You will see later how administration of the directory can be delegated to individuals
who are only given selective access or right of passage to delegated areas of the
directory.
4667-8 ch02.f.qc 5/15/00 1:56 PM Page 29
30
Part I ✦ Windows 2000 Server Architecture
Application management
Active Directory makes it easier to develop and distribute applications. Application
developers need consistent, open, and interoperable interfaces and APIs against
which they can code functionality that stores and manages information relating
to applications, processes, and services in a distributed information store. We want
to be able to create applications and store application and persistent data to an
“invisible” repository through an open interface. This information should be
available from anywhere and everywhere on the network.
Developers want to be able to create methods that install an application into

a directory on the network for initial configuration and manipulation over the
lifetime or use of the application. We do not want to concern ourselves with
the inner workings of the directory. We want to create our information or config-
uration object, initialize, use it, and be done . . . no matter where the user installs
or invokes our product. And wherever the object we created is moved to, it should
always be accessible to the application.
With all of the above, the cost of access and management has in the past been high.
We are looking for solutions that will, albeit in the long to medium term, reduce the
cost of both management and operation of cyberspace and the information
technology systems running our companies and our lives.
What Is Active Directory?
There are registries and databases that provide directory-type facility for applications
and users. But not one is interconnected, share-centric, or distributed in any way. AD
is a universal distributed information storehouse into which all network objects, such
as application configurations, services, computers, users, and processes, can be
accessed, in a consistent manner, over the full expanse of a network or internetwork.
This is made possible by the logical structure of the directory. And before you start
scratching your head, you should understand that without Active Directory you
cannot log in to a Windows 2000 domain, period. Chapters 7 and 8 discuss this and
illustrate the control you have over AD’s logical and physical structure.
We compare AD to a database later on in this chapter and in Chapter 7 in much
more detail. Meanwhile, if you’re keen to adopt this child, then you need to know
something about its parents.
The Grandfather of the Modern Directory:
The X.500 Specification
The directory service as we are coming to know it began with an interconnection
model proposed by the International Standards Organization (ISO) little more than
20 years ago. This model is popularly known as OSI, which stands for open-systems
interconnection. In the late eighties, OSI was given a huge boost by big business and
government and quickly became the foundation for the information revolution we

are experiencing today.
4667-8 ch02.f.qc 5/15/00 1:56 PM Page 30
31
Chapter 2 ✦ Introducing Active Directory
The OSI model and its seven layers lie at the very genesis of modern information
technology. Without a fundamental understanding of OSI, it is difficult to be an effec-
tive systems engineer, software developer, network administrator, CIO, or Webmaster.
OSI is to IT what anatomy is to medicine. While we assume that you are familiar with
the OSI model, this brief discussion of X.500 serves to provide a common departure
point for all systems engineers not familiar with a directory service.
The X.500 directory service can be found at the OSI application layer, where it sits as a
group of protocols approved and governed by the International Telecommunications
Union (ITU), formerly the CCITT. The objective of X.500 was to provide standards and
interfaces to an open and interoperable global and distributed directory service.
X.500 is made up of many components (databases) all interoperating as a single
contiguous entity. Its backbone is the Directory Information Base (DIB). The entries
in the DIB provide information about objects stored in the directory. Figure 2-2
represents the information contained in the DIB.
Figure 2-2: The X.500 hierarchy (a), and the DIB and the information
it contains (b)
In order to access the information stored in the DIB, both users and computers
needed a structure or model that would make it easier to understand where data
could be located. The model proposed was an object-oriented, hierarchical structure
that resembles an upside-down tree, as illustrated in Figure 2-3. The root of the tree is
X.500 Root
C2
a
Classes
b
Attribute ValuesEntry Identifier

Country
Organization
Person
US
MCITY
Jeffrey Shapiro
P1
C1 C3
O2O1 O3
P2P1 P3
4667-8 ch02.f.qc 5/15/00 1:56 PM Page 31
32
Part I ✦ Windows 2000 Server Architecture
at the top, and the branches and leaves hang down, free to proliferate. This model
assured that any object in the tree is always unique as long as it is inherently part of
the tree and can trace its “roots” to the single node at the top. Active Directory trees
(and DNS) work the same way, as discussed later. The tree is read from the bottom
to the top.
Figure 2-3: The X.500 tree structure
The objects in the X.500 tree represented containers for information representing
people, places, and things. These objects would also be organized or grouped into
classes (for example, groups of countries, companies, localities, and so on).
The X.500 standard included the following container objects:
✦ Countries
✦ Location
✦ OU or organizational unit
Unfortunately, X.500 suffered from several limitations in its early days. It became
bogged down under its own weight (the specification was exhaustive), and in many
respects it was ahead of its time (especially with respect to its ties to OSI). It made
its appearance in the late 1980s at a time when most innovators could care less

about managing information openly and globally, when we were all huddled in our
garages inventing or writing code like crazy, and when we were all competing for
market share at every turn.
X.500 was also born before the advent of the World Wide Web and the mass utiliza-
tion of the Internet by both the public and businesses. And what really dragged it
4667-8 ch02.f.qc 5/15/00 1:56 PM Page 32
33
Chapter 2 ✦ Introducing Active Directory
down was its ties to the OSI protocols (the datalink protocols — DLC — such as
802.2 and 802.3), which turned out to be its Achilles’ heel, because the way of the
Internet world was IP. Meanwhile, the Internet took off on the coattails of TCP/IP,
leaving X.500 struggling in a protocol desert landscape.
Like so many innovations before it, X.500 provided nourishment for other
inventions that followed. And much of the foundation for the modern directory
service, especially Active Directory, can be directly attributed to the vision of
X.500, as we will soon see.
The Father of the Modern Directory: LDAP
The X.500 specifications defined a protocol by which services would be able to
access the information stored in X.500 databases. This protocol was known as the
Directory Access Protocol, or DAP. It consisted of a comprehensive set of functions
that would provide the ability for clients to add and modify or delete information in
the X.500 directory.
DAP, however, was overkill and consisted of far more functionality than was
required for the implementation of a directory service. Therefore, a simplified
version of DAP was created, called the lightweight directory access protocol (LDAP).
After several refinements, LDAP has begun to stand in its own right as a directory
service. After adoption by the Internet Engineering Task Force (IETF), several
important features of LDAP have garnered its widespread support:
✦ LDAP sits atop the TCP/IP stack rather than the OSI stack. This means that
every client with an IP address, able to send and receive packets over IP, can

access and exploit LDAP-compliant directory services. The client needs only
to know how to “talk” to LDAP (IP). TCP, the transport, takes care of the rest.
✦ LDAP performs hyper-searching, which is the ability of a directory to refer to
another for authoritative information. In other words, one LDAP directory can
defer to another to chase information. An example of this is how Web-based
search engines look to other search engines, via hyper-linking, for collateral
information or information that does not exist in their own databases. Directory
services on a worldwide Internet thus can become contiguous and distributed
to form a transparent massive service, limited only by available servers and
network resources.
The replication mechanisms Microsoft is building into its products are so advanced
that products such as SQL Server 2000 will become fully distributed before 2003.
✦ Early on its childhood, LDAP implemented a rich C-based API, making C the de
facto programming language of the directory service. Using the most popular
language of the day with which to call directory functionality ensured LDAP
widespread support in the bustling developer community.
Note
4667-8 ch02.f.qc 5/15/00 1:56 PM Page 33
34
Part I ✦ Windows 2000 Server Architecture
LDAP consists of the following components, which in some shape or form are the
foundations of all modern directories, including the AD:
✦ The data model: This model represents how data is accessed in the
directory. The data model is inherited directly from the data model of
the X.500 specification. Objects are infused with information by way of
assigning attributes to them. Each attribute is type-casted and contains
one or more distinct values. The objects are classified into groups of
classes, such as organizational units (OUs) or Companies.
✦ The organization model: This is the inverted tree paradigm we earlier
discussed, which is also inherited directly from the X.500 specification. It is

the structure adopted by all modern directory services. Of particular note
is how the Domain Name System (DNS) of the Internet is arranged around
inverted trees. The DNS consists of several trees, the root or topmost levels,
that sprout downward and contain millions of leaves (or nodes). Figure 2-4
illustrates the DNS forest and the seven roots. It also illustrates the
.com
tree
and how it has fired the Internet into the commercial juggernaut it is today.
Figure 2-4: The organizational model revolves around
the inverted tree, a hierarchical collection of objects.
✦ The security model: This model specifies how information is securely and
safely accessed. LDAP adopted Kerberos password authentication and has
since added additional authentication layers with the inclusion of the Simple
Authentication Security Layer (SASL). This SASL provides a tiered architecture
for a multitude of service providers. Version 3.0 of LDAP also supports the SSL
or secure socket layer of TCP/IP, which was developed independently by the
Internet community. Windows 2000 supports SSL in its browser, Internet
Explorer.
4667-8 ch02.f.qc 5/15/00 1:56 PM Page 34
35
Chapter 2 ✦ Introducing Active Directory
✦ The functional model: This model specifies the methods for querying and
modifying the directory objects. It includes operations to add entries and to
edit, populate the attribute fields, delete, and query objects in the directory.
✦ The topological model: This model specifies how the directory services
integrates or interoperates with other compliant directories. The ability of
LDAP directories to refer or defer to other directories is inherent in this
model.
LDAP’s popularity flourished with the sudden popularity of the Internet. Today,
many popular applications and server technologies support the protocol. It can

be accessed from most e-mail applications, Web-based applications, and even
embedded systems such as routers and gateway devices.
After X.500
A number of large technology companies are hard at work on directory services.
The two of note who appear to have been at it longer than Microsoft are Banyan
Systems and Novell. Others include Netscape and IBM (Lotus Notes).
Banyan perhaps has been at it the longest with its StreetTalk product that has been
part of the Vines OS for more than a decade. Novell entered the market mid-way
through the 1990s with a directory service aimed at its installed NetWare base, called
the Novell Directory Service (NDS), and it has been working on versions of NDS that
will be independent of the NetWare OS, including a version for Windows NT.
Despite its immaturity, AD has been built on proven technology. One area on
which it heavily depends is replication, and the technology for this comes from
Microsoft Exchange. The Exchange site integration and replication technology has
been proven on millions of installations around the world.
From the ground up, Active Directory has been built on open, international
standards. It is important to note that AD is not an X.500 directory, but it has
borrowed heavily from the X.500 specifications. In particular, it uses LDAP
as the access protocol, which opens it to everyone and everything. In short,
Microsoft has taken everything that was great about X.500 and LDAP and
combined it with proven technologies it has develop-ed for other purposes
over the years (such as Microsoft’s Component Object Model [COM]). AD
can exchange information with any application or service that uses LDAP.
AD also relies on DNS as its locator service, allowing clients to transparently
locate domain controllers (AD hosts) by merely connecting to a DNS server and
looking up the IP addresses for the closest domain controller. (We will discuss
this further in Chapters 7 and 8.)
Note
4667-8 ch02.f.qc 5/15/00 1:56 PM Page 35
36

Part I ✦ Windows 2000 Server Architecture
The Open Active Directory
AD also provides a rich set of APIs to encourage the development of tools and
applications. The AD will thus serve as a repository for application-specific
information, particularly software that is group-driven. For example: We have
developed a customer relationship management (CRM) system for several
medical and dental clients. Our users typically log in to the application and
become apparent as a community of active users to the rest of the practice or
hospital, once authenticated in the AD.
The application is able to obtain enterprise-wide information about the state of the
application at any given time, and we are able to group users according to service
and access levels, governed by objects in the AD. In particular, the application
publishes information about who is logged in and using the system, the files (data)
they have checked out of the database management system (such as SQL Server or
Oracle), and what they are currently doing.
We do not need to provide users with a second login just to use the application.
Instead, when they run the CRM, it checks to see if the AD has authenticated them,
the machine they are accessing the system from, and what they are allowed to
access. Based on this information, we populate the GUI that drives the CRM with
information the user is allowed to see or use.
What About the Registry?
Now that you can see why we need directory services, and where they came from,
where does the registry fit in? In the early days of Windows 95 and Windows NT,
Microsoft improved the information repositories of applications running on the
Windows platform with the creation of the registry. It was a great relief from the
mess created by initialization and configuration files, insecure text files that
anyone could access.
The registry, however, was more a technology or system created to stabilize the
platform or the OS and is a repository for managing information and the configuration
of applications and computers. When users deleted their Windows 3.11 and earlier

version
.ini
files in error, the application was, for better or worse, destroyed (if the
.ini
files were not backed up). The registry set out to change all that. Today, some of
the largest software houses in the world still do not use it; I can’t imagine why.
What’s more, the registry also became the home for the so-called Security Account
Manager (SAM). This database stores and manages all the security and access
control authority of network resources.
There are some similarities between the registry and the AD. Specifically, the
registry is:
✦ Also a database, somewhat cryptic and complex, but still a database.
✦ Open and accessible (except for the SAM part).
4667-8 ch02.f.qc 5/15/00 1:56 PM Page 36
37
Chapter 2 ✦ Introducing Active Directory
✦ Able to be programmed against.
✦ A replicating structure (single master), providing some vestige of a
distributed system.
✦ A system of hierarchical structures, which contains records that hold
configuration data.
For the most part, the similarities end here. Comparing the registry to Active
Directory is like comparing a JetSki to the USS Kitty Hawk. AD is a completely
different animal. Yes, you can still use the registry to store configuration data,
and you would still use the registry on a standalone workstation or server,
even a domain controller. Specifically, the difference is that AD is:
✦ A distributed multi-master database (peer directories update each other
in real time, latency aside).
✦ Built on open, Internet-based standards.
✦ Object-oriented.

✦ Interoperable (almost coexistent) with the Domain Name System of the
Internet.
✦ Able to service any network client using TCP/IP.
✦ Able to grow to gargantuan proportions.
Unfortunately, many applications today still store configuration information in
unguarded flat text files, ignoring the registry for the most part. Ignoring both the
registry and the AD will likely render your application incompatible with Windows
2000, from both a functional perspective and as a Microsoft logo requirement.
AD does not set out to replace the registry. The registry still plays an important role
in Windows 2000, as you will discover in Chapter 18 and in various other places in
this book. In fact, even AD uses the registry to store some configuration-related
information. Microsoft began working on a directory or distributed information
storage facility some time ago, possibly even at the same time it was developing
the registry.
From the outset, Microsoft believed it could only succeed with AD by ensuring
it was based on open standards and interoperable with the Internet, period. In
other words, any IP-based (LDAP) client will be able to access the AD, and like
the Internet Information Server (IIS), FTP, and other services, this access is
transparent (in terms of what OS it is sitting on).
✦ Active Directory supports and coexists with both DNS and LDAP. Both are
modeled on the X.500 standard, especially with respect to its structural and
organizational model.
✦ Active Directory supports open and interoperable standards, especially with
regard to the widespread naming conventions in use today.
Note
4667-8 ch02.f.qc 5/15/00 1:56 PM Page 37
38
Part I ✦ Windows 2000 Server Architecture
✦ Active Directory is seamlessly integrated into the Internet by virtue of
Microsoft’s total adoption and commitment to TCP/IP. All other protocols

that Microsoft supports are essentially provided for backward compatibility
with earlier versions of NT, other network operating systems, legacy
transports such as SNA and the DLC protocols, and NetBEUI clients.
✦ Active Directory provides a rich set of C/C++, Java, VB, and scripting language
interfaces, allowing it to be fully programmed against.
We have investigated which languages or programming environments should be
used to program the Active Directory. For the speed required by complex code and
advanced development, such as creating service providers, C++ is best. For RAD
and the majority of component-based development, Visual Basic, using the Active
Directory Services Interface (ADSI), is best. Java is useful when you need to make
calls to the LDAP API, but we have found Microsoft’s support for Java-based access
to Active Directory lukewarm to say the least.
✦ Active Directory is built into the Windows NT operating system (still at the
core of Windows 2000), making it backward compatible with earlier versions
of Windows NT.
✦ Active Directory is a fully distributed architecture allowing administrators to
write once and update everywhere from a single point of access, across any
network.
✦ Active Directory is highly scalable and self-replicating. It can be implemented
on one machine, or the smallest network, and can scale to support the largest
companies in the world. Resources and adoption permitting, once the kinks
(and it has a few) are worked out, it will likely become a pervasive technology
within a short time.
✦ Active Directory’s structural model is extensible, allowing its schema to evolve
almost without limits. In this regard, Active Directory has to comply with the
X.500 specification that extending the schema requires you to register the new
class with a X.500 governing body. This compliance is achieved by registering
an Object Identifier (OID) with the authorities. In the United States, the
authority is the American National Standards Institute (ANSI).
AD has fully adopted the most popular namespace models in use today. It embraces

the concept of an extendable namespace and marries this concept with the operating
systems, networks, and applications. Companies deploying AD are able to manage
multiple namespaces that exist in their heterogeneous software and hardware.
The Elements of Active Directory
Active Directory is a highly complex product that will no doubt become more
complex and more advanced in future versions. At the core of the product, we find
a number of elements that are native to directory services in general and AD in
particular.
Caution
4667-8 ch02.f.qc 5/15/00 1:56 PM Page 38
39
Chapter 2 ✦ Introducing Active Directory
Namespaces and Naming Schemes
AD has adopted several naming schemes, which allows applications and users to
access the AD using the formats they have most heavily invested in. These name
formats are as follows:
RFC822 names
RFC822 is the naming convention most of us are familiar with, by virtue of our
using e-mail and surfing the World Wide Web. These names are also known as
user principal names (UPN) in the form of
somename@somedomain
, for example,

. AD provides the RFC822 namespace for
all users. If you need to find a person’s extension number at a company (if they
publish it), you need only query the directory and look up
someone@somedomain.
com
(your software will translate that into the correct LDAP query, as shown later).
The UPN is also the login name or user ID to a Windows 2000 domain. Windows

users can now log in to a Windows 2000 network by simply entering their user ID
and password, like this:
User:
Password: *************
It is possible to assign any UPN to a domain for login. In other words, you might
create a domain called MCITY but prefer users to log in as
so that they do not need to remember more than their e-mail addresses.
LDAP and X.500 names
The LDAP and X.500 naming conventions are known scientifically as attributed
naming, which consists of the server name holding the directory (which we refer
to as the directory host), user name, organizational unit, and so on. For example:
LDAP://anldapserver.bigbrother.com/cn=jsmithers,ou=trucksales,
dc=bigbrother,dc=com
LDAP names are used to query the Active Directory.
Active Directory and the Internet
It is possible to locate AD servers anywhere on the Internet or a private intranet.
These AD servers can be full-blown Windows 2000 domain controllers, or they can
serve the single purpose of being LDAP directory servers. The information and
access that users and clients enjoy from these servers is transparent.
The client needs only resolve the closest AD server to it to get information. The
closest server might be on the same site as the client, in which case the DNS server
will resolve to an AD server on the same subnet as the client. Or it may be located
Tip
4667-8 ch02.f.qc 5/15/00 1:56 PM Page 39
40
Part I ✦ Windows 2000 Server Architecture
on a site far away. This means that AD can and will be used as an Internet directory
server without ever being accessed for domain authentication. Multiple AD servers
will link together to provide a global directory service that spans the continent.
Active Directory Everywhere

Microsoft also set out to ensure that the AD was highly scalable and would become
pervasive as quickly as resources permitted. AD, as you will discover in Chapter 8,
is easy to install and set up on a simple server. It is also easy to set up and install
AD as a single-user repository, and it carries virtually no noticeable overhead on
the simplest configuration (we will discuss AD configuration in Part III). In other
words, when AD needs to be small, it can be small, and when it needs to be big, it
can grow at an astonishing rate.
This makes it ideal to use the AD for even the simplest of application information
storage requirements. Although it is no substitute for database management
systems that provide advanced information management services such as infor-
mation analysis and data mining (or the management of corporate data), it may
not be uncommon to find a single-user application deploying AD in the hope that
later scaling up will be as easy as merely further populating the directory. AD even
installs on a standalone 133MHz desktop machine with 64MB of RAM, and is easily
deployable as a domain controller supporting a small company (this configuration is
not what Microsoft officially recommends, and such a configuration should support
little else but a directory with a small helping of user and computer accounts).
On the other hand, it is possible to deploy AD in such a way that it scales to
astonishing levels. As a domain repository, Windows NT 4.0 maxes out at about
100,000 users, but AD can scale to the millions — it can grow as large as the Internet.
All the replicas of the AD are synchronized (which itself is quite an administration
feat, as we will soon see). All copies of an organization’s AD system propagate
changes to one another, similar to how DNS servers propagate domain records.
In practice, an NT domain becomes shaky at between 30,000 and 40,000
accounts, which is why many large companies create multiple resource and
account domains.
The key to the scalability of AD is the domain tree . . . a data hierarchy that can
expand, theoretically, indefinitely. The AD provides a simple and intuitive bottom-
up method for building a large tree. In AD, a single domain is a complete partition of
the directory. Domains are then subdivided or partitioned into organizational units,

allowing administrators to model the domain after their physical organization
structure or relevant business models. A single domain can start very small and
grow to contain tens of millions of objects; thus, objects can be defined at the
smallest corporate atomic structure without the fear of overpopulation, as was
the case with Windows NT 4.0, and NetWare 3.x and 4.x.
Note
4667-8 ch02.f.qc 5/15/00 1:56 PM Page 40

×