Even though it is based on the same code as AD DS, AD LDS is much
simpler to work with. For example, when you install AD LDS on a server,
it does not change the configuration of the server in the same way that
AD DS does when you create a domain controller. AD LDS is an application
and nothing more. When you install it, you are not required to reboot
the server because the application installation process only adds
functionality to the server and does not change its nature.
However, before you begin, you must first understand what makes up
an AD LDS instance, how AD LDS instances should be used, and what their
relationship is or can be with AD DS directories. Then you can proceed
to the installation of the AD LDS service.
Like AD DS, AD LDS instances are based on the Lightweight
Directory Access Protocol (LDAP) and provide hierarchical database
services. Unlike relational databases, LDAP directories are optimized for
specific purposes and should be used whenever you need to rely on fast
lookups of information that support given applications. Table 1 outlines the
major differences between an LDAP directory and a relational database
such as Microsoft SQL Server. This comparison helps you understand
when to choose an LDAP directory in support of an application over a
relational database.
Table 1. Comparing LDAP Directories to Relational Databases
|
LDAP DIRECTORIES |
RELATIONAL DATABASES |
|---|
|
Fast reads and searches. |
Fast writes. |
|
Hierarchical database design often based on the
Domain Name System (DNS) or the X.500 naming
system. |
Structured data design relying on tables
containing rows and columns. Tables can be linked
together. |
|
Relies on a standard schema structure, a schema
that is extensible. |
Does not rely on schemas. |
|
Decentralized (distributed) and relies on
replication to maintain data consistency. |
Centrally located data
repositories. |
|
Security is applied at the object
level. |
Security is applied at the row or column
level. |
|
Because the database is distributed, data
consistency is not absolute—at least not until replication
passes are complete. |
Because data input is transactional, data
consistency is absolute and guaranteed at all
times. |
|
Records are not locked and can be modified by two
parties at once. Conflicts are managed through update sequence
numbers (USNs). |
Records are locked and can be modified by only
one party at a time. |
Although AD LDS is based on AD DS, it does not include all the features of AD DS.
Table 2 outlines the
differences in features between AD LDS and AD DS.
Table 2. Comparing AD LDS with AD DS
|
FEATURE |
AD LDS |
AD DS |
|---|
|
Includes more than one instance on a
server. |
? |
? |
|
Includes independent schemas for each
instance. |
? |
? |
|
Runs on client operating systems such as Windows
7 or Windows Server 2008 R2 member servers. |
? |
? |
|
Runs on domain controllers. |
? |
? |
|
Directory partitions can rely on X.500 naming
conventions. |
? |
? |
|
Can be installed or removed without a
reboot. |
? |
? |
|
Service can be stopped or started without
reboot. |
? |
? |
|
Supports Group Policy. |
? |
? |
|
Includes a global catalog. |
? |
? |
|
Manages objects such as workstations, member
servers, and domain controllers. |
? |
? |
|
Supports trusts between domains and
forests. |
? |
? |
|
Supports and integrates with public key
infrastructures (PKIs) and X.509 certificates. |
? |
? |
|
Supports DNS service (SRV) records for locating
directory services. |
? |
? |
|
Supports LDAP application programming interfaces
(APIs). |
? |
? |
|
Supports Active Directory Services Interface
(ADSI) API. |
? |
? |
|
Supports the Messaging API (MAPI). |
? |
? |
|
Supports object-level security and delegation of
administration. |
? |
? |
|
Relies on multimaster replication for data
consistency. |
? |
? |
|
Supports schema extensions and application
directory partitions. |
? |
? |
|
Can install a replica from removable
media. |
? |
? |
|
Can include security principals to provide access
to a Windows Server network. |
? |
? |
|
Can include security principals to provide access
to applications and Web Services. |
? |
? |
|
Is integrated into the Windows Server 2008 R2
backup tools. |
? |
? |
As you can see from the contents of Table 2, there are several
similarities and differences between AD LDS and AD DS. For example, it
is easy to see why Exchange Server must integrate with AD DS as
opposed to relying on AD LDS; Exchange Server requires access to the
global catalog service to run. Without it, email users could not look
up recipients. Because AD LDS does not support the global catalog,
Exchange Server cannot rely on it. However, Exchange Server is an
application that requires access to directory data in each site of the
domain or forest. As such, it also relies on your domain controller
positioning to ensure that each user can properly address
emails.
AD LDS, however, provides much of the same functionality as AD
DS. For example, you can create instances with replicas distributed in
various locations in your network, just as with the location of domain
controllers, and then use multimaster replication to ensure data
consistency. In short, AD LDS is a lightweight, portable, and more
malleable version of the directory service offered by AD DS.
Now that you have a better understanding of AD LDS and its feature set, you can
begin to identify scenarios in which you would need to work with this
technology. Consider these scenarios when you decide whether to rely
on AD LDS or AD DS:
-
When your applications need to rely on an LDAP directory,
consider using AD LDS instead of AD DS. AD LDS can often be hosted
on the same server as the application, providing high-speed and
local access to directory data. This reduces network traffic
because all required data is local. In addition, you can bundle
the AD LDS instance with the application when you deploy it. For
example, if you have a human resources application that must rely
on custom policies to ensure that users can access only specific
content when their user object contains a set of particular
attributes, you can store these attributes and policies within AD
LDS.
-
Rely on AD LDS to provide data associated with user accounts
in AD DS but requiring extensions to the AD DS schema to support
it. Using AD LDS in this scenario provides the additional user
data without modifying the AD DS schema. For example, if you have
a centralized application that provides a photograph of each
employee in your organization and associates the photographs with
the users’ AD DS accounts, you can store the photographs in an
AD LDS instance. By storing the photographs in
AD LDS in a central location, they are associated
with the user accounts in AD DS, but because they are in AD LDS,
they are not replicated with all other AD DS data, reducing
bandwidth requirements for replication.
-
Rely on an AD LDS instance to provide authentication
services for a web application such as Microsoft SharePoint Portal
Server in a perimeter network or extranet. AD LDS can query the
internal AD DS structure through a firewall to obtain user account
information and store it securely in the perimeter network. This
avoids having to deploy AD DS in the perimeter or having to
include domain controllers from the internal network in the
perimeter.
-
Consolidate various identity repositories into a single
directory store. Using a metadirectory service such as Forefront Identity Manager (FIM) or the free
Identity Integration Feature Pack (IIFP), you can
obtain data from various sources and consolidate it within an AD
LDS instance. FIM and IIFP support the provisioning of data from a
wide variety of sources such as AD DS forests, SQL Server
databases, third-party LDAP services, and much more. IIFP is a
subset of Microsoft Identity Integration Server (MIIS) and
supports data integration between AD DS, AD LDS, and Exchange
Server. Using these solutions reduces your identity management
overhead by designating a single master source and provisioning
all other repositories from this source.
-
Provide support for departmental applications. In some
cases, departments might require additional identity information,
information that is of no relevance to any other department within
the organization. By integrating this information in an AD LDS
instance, you give the department access to it without affecting
the directory service for the entire organization.
-
Provide support for distributed applications. If your application is
distributed and requires access to data in several locations, you
can also rely on AD LDS because AD LDS provides the same
multimaster replication capabilities as AD DS.
-
Migrate legacy directory applications to AD LDS. If your organization is running legacy
applications that rely on an LDAP directory, you can migrate the
data to an AD LDS instance and standardize it on Active Directory
directory technologies.
-
Provide support for local development. Because AD LDS can be
installed on client workstations, you can provide your developers
with portable single-instance directories that they can use to
develop custom applications that require access to identity data.
Developing with AD LDS is much simpler and easier to manage and
contain than developing with AD DS.
-
When evaluating directory-enabled commercial applications,
you should always give preference to an application that relies on
AD LDS or its predecessor, ADAM, rather than select one that
relies on AD DS schema modifications. Deploying commercial
applications with portable directories is much easier and has much
less impact on your network than deploying applications that will
modify your NOS directory schema forever.
Each of these scenarios represents a possible use of AD LDS. Typical
applications should include white-page directories, security-oriented
applications and network configuration, and policy store
applications.
As you can see, AD LDS is much more portable and malleable than
AD DS will ever be. Whenever you need to think about schema
modifications in AD DS, think of AD LDS instead. On almost every
occasion, AD LDS provides a better choice because AD DS should always
be reserved as a NOS directory and should include integration only
with applications that add functionality to the NOS directory
functions.
New AD LDS Features in Windows Server 2008 R2
Microsoft has provided several updates to AD LDS with the
release of Windows Server 2008 R2. All of these updates are also
included in AD DS :
-
Active Directory Recycle
Bin This feature is made available by a schema update
and offers administrators the ability to recover accidentally
deleted items.
-
Active Directory Web Services
(ADWS) This feature offers a web service interface that
connects to AD LDS instances. This feature is automatically
installed and available when installing the AD LDS role.
-
Active Directory Module for Windows
PowerShell This feature provides a command-line interface for
administrators. You can use PowerShell to perform administrative
tasks interactively or automate repetitive tasks.
All three updates have been discussed before and can be used
with AD LDS in very much the same way they are used with AD DS.
As part of Windows Server 2008 R2, AD LDS can be installed and
configured in both the full installation and in Server Core. In
addition, AD LDS is an ideal candidate for virtualization through
Windows Server 2008 R2 Hyper-V. Because of its light requirements, AD
LDS can easily run within a virtual instance of the Windows Server
2008 R2 operating system and should be considered as such unless the
application that is tied to the AD LDS instance has specific
requirements for physical installation.
In addition, avoid installing AD LDS on domain controllers as
much as possible. Although AD LDS can fully coexist with the domain
controller (DC) role, and even the read-only domain controller (RODC)
role, domain controllers should be considered special roles within
your network and should be tied only to the DNS service and nothing
else, if at all possible. Because DCs are also good candidates for
virtualization, any network that can rely on host servers running
Hyper-V and virtualized instances of other services should virtualize
DCs as much as possible. With a virtual DC, it is much easier to
ensure that no other roles are hosted on the server because all other
roles can also be virtualized within their own instances of Windows
Server 2008 R2.
Also, consider running AD LDS in scenarios in which high
security is required. A good example is one in which you need to run
an authentication directory service in extranets or perimeter
networks. Relying on Server Core installations within these
environments can help reduce the attack surface of servers you expose
outside of your corporate network.
Identifying AD LDS Requirements
As mentioned earlier, AD LDS has very light installation
requirements. They include:
-
A supported operating system such as Windows Server 2008
R2, Standard edition, Enterprise edition, or Datacenter
edition.
-
An account with local administration access rights.
Removing AD LDS from a server requires two activities:
-
First, uninstall any instance of AD LDS that you created
after the role installation, using Programs And Features in Control Panel.
-
Second, use Server Manager to remove the AD LDS
role.
As you can see, both installation and removal requirements are
straightforward. The major caveat is that you must ensure that all
instances have been removed from a server before you remove the
role.
Tip
EXAM TIP
Remember that you need to remove all instances of AD LDS from a server before you can remove the role
from the server.
Installing AD LDS on Server Core
Installing AD LDS is very similar to installing AD DS. First
you must install the server role; then you must create the AD LDS
instances you want to use. Installing AD LDS on the full
installation of Windows Server 2008 R2 is covered in the practice
later in this lesson.
The installation process for AD LDS is as simple on Server
Core as it is on a full installation of Windows Server 2008 R2. Use
the following process:
-
Log on with local administrative credentials to a Windows
Server 2008 R2 stand-alone or member server running Server
Core.
-
Begin by identifying the service name for AD LDS. Use the
following command:
oclist | more
This name should appear after several screens of
information and should be
DirectoryServices-ADAM-ServerCore.
-
Proceed to the installation of the role. Use the following
command:
Dism /online /enable-feature /featurename:DirectoryServices-ADAM-ServerCore
Role names are case-sensitive, so ensure that you type the
role name exactly as displayed; otherwise, the command will not
work. Also, using the Start /w command ensures that the command
prompt does not return until the role installation is
complete.
Note
The DISM command
Windows Server 2008 R2 administrators should get used to the
DISM command, which is designed to replace OCSetup in future
Server Core versions of Windows Server. For more information on
DISM and additional installation and control options, go to
http://technet.microsoft.com/en-us/library/dd744382%28WS.10%29.aspx.
If you run the oclist command again, you see that the AD LDS
role has been added to this server. You can also navigate to the
%SystemRoot%\ADAM folder to view the new AD LDS files. Your server
is ready to host AD LDS instances.
Warning
IMPORTANT
INSTALLED AD LDS FILES
Note that AD LDS will also automatically install the
components for the Windows PowerShell Active Directory Module.
This includes the .NET Framework 3.5.1, Windows PowerShell, and
the Active Directory Web Services.
Practice Installing AD LDS
In this practice, you install the AD LDS role on a server
running the full installation of Windows Server 2008 R2. Then you
browse the contents of the installation folder to identify which
files have been installed.
EXERCISE 1 Install AD
LDS
In this exercise, you install the AD LDS server role.
-
Make sure your Active Directory Domain Server,
SERVER01.contoso.com, is running, and start your member
servers, SERVER03.contoso.com and SERVER04.contoso.com.
-
Log on to SERVER03.contoso.com with the
CONTOSO\Administrator account.
You do not need domain administrator rights to work with
AD LDS. Because each AD LDS installation is independent of AD
DS, you need only local administrator rights to work with it,
but using the domain administrator account is acceptable for
the purpose of this exercise.
-
In Server Manager, right-click the Roles node and click
Add Roles.
-
Review the Before You Begin screen and click
Next.
-
In the Select Server Roles dialog box, select Active
Directory Lightweight Directory Services, click Add Required
Features, and then click Next.
-
Review the information in the Active Directory
Lightweight Directory Services window and click Next.
-
Confirm your choices and click Install.
-
Review the installation results and click Close.
-
Repeat the operation on SERVER04.contoso.com.
AD LDS is installed on both member servers.
The AD LDS installation installs the service and generates a
directory store called Adamntds.dit located in the
%SystemRoot%\Adam folder. It also adds the tools to configure and
manage AD LDS as well as the PowerShell Module for Active
Directory.
When the installation is complete, the role appears in
Server Manager, as shown in Figure 1.
EXERCISE 2 Review the Installed AD LDS
Files
In this exercise, you review the files that AD LDS installs
on servers.
-
Log on to your member server, SERVER03.contoso.com,
using the CONTOSO\Administrator account.
-
From the Start menu, right-click Computer and click Open
to open a Windows Explorer window.
-
Navigate to the %SystemRoot%\ADAM folder.
-
Review the files created by the AD LDS installation
process.
On a full installation of Windows Server 2008 R2, AD LDS
creates the ADAM folder and populates it with 21 files and two
subfolders. The two subfolders include localization
information. In this case, they are in U.S. English. As shown
in Figure 2, the
files contained in the ADAM folder include:
-
The AD LDS program files, including .dll, .exe,
.cat, .ini, and .xml files.
-
The AD LDS directory store, Adamntds.dit.
-
Lightweight directory format (.ldf) files that are
used to populate AD LDS instances when they are
created.
You work with these file types when you configure AD LDS in
the next lesson.
The installation of AD LDS on Server Core does not include
the same files and folders as the installation on a full
installation of Windows Server 2008 R2. Server Core creates only
one folder for localization, whereas the full installation creates
two. In addition, the full installation includes an additional
tool: the Active Directory Schema Analyzer, which is not installed
on Server Core.
