Information Technology Reference
In-Depth Information
Active Directory Domain Services is the foundation on which a Windows
Server 2008 network is built. By now, you should have enough knowledge to install and imple-
ment a secure, reliable Active Directory network. However, although AD DS is the core tech-
nology in Windows Server 2008, some complementary technologies installed as server roles can
augment AD DS features and flexibility.
This chapter discusses three server roles introduced in Chapter 1: Active Directory Lightweight
Directory Services, Active Directory Federation Services, and Active Directory Rights Management
Services. All these roles use or integrate with AD DS technology to give users flexible, secure access
to applications and network resources. In addition, you learn how to implement read only domain
controllers (RODCs) in a branch office environment.
When you need a highly capable forest-wide directory service that's tightly integrated with your
network OS, Active Directory Domain Services fits the bill. Suppose you want a directory serv-
ice that's only loosely coupled with the OS, however? Perhaps you need one that can accommo-
date directory-enabled applications with diverse schema requirements yet doesn't affect the
current AD DS schema operating throughout your forest? Active Directory Lightweight
Directory Services (AD LDS) is the ideal server role to handle this task.
A
directory-enabled application
uses a directory service to store program data or configuration
information, user information for authentication and authorization purposes, or a combination of
program, configuration, and user information. The Microsoft Exchange e-mail system is an exam-
ple of this type of application because it's tightly integrated with Active Directory. Some organiza-
tions prefer a different e-mail system—one that's directory enabled but requires schema changes that
aren't compatible with the AD DS schema. AD LDS provides the environment for just this situation.
AD LDS, based on LDAP, was formerly known as Active Directory Application Mode (ADAM).
This server role provides most of the functionality of AD DS without the requirements of forests,
domains, and domain controllers. The primary purpose of AD LDS is to support directory-
enabled applications with flexibility that AD DS can't match. For example, the AD DS schema
is forest-wide, and changes to it affect all domains and can adversely affect replication times
when changes are considerable. AD LDS, on the other hand, can be installed on a single server
or a group of servers with a schema unique to the application it's intended to serve. Furthermore,
you can install multiple instances of AD LDS on the same server to support multiple directory-
integrated applications, each with its own schema requirements.
AD LDS does not rely on AD DS, but it can use the services of AD DS if necessary, when
directory-enabled applications require authentication of security principals. The two services can
coexist on the same network, or AD LDS can even be used in a non-domain environment. The
following are some key features of the AD LDS server role:
• Supports directory-enabled applications without the overhead of a domain infrastructure.
• Multiple application directory partitions are supported, allowing more than one applica-
tion to use a single AD LDS instance. Application directory partitions hold the data used
by directory-enabled applications.
• Multiple AD LDS instances on the same server are supported to accommodate several
directory-enabled applications with unique schema requirements.
• Directory replication provides fault tolerance and load sharing, which ensures highly avail-
able and reliable access to application data.
AD LDS has some similarities with AD DS but also a number of differences, summarized in
the following list:
• No global catalog
• No support for group policy
• No computer objects
Search WWH ::
Custom Search