Information Technology Reference
In-Depth Information
• No integration with AD CS
• No trust relationships
• No support for Windows security principals
As you can see, most of the features not supported by AD LDS are enterprise features that
support the infrastructure of a Windows Active Directory network. AD LDS doesn't support
these features because its intended use is more narrowly focused.
AD LDS is an ideal solution when a directory-enabled application isn't needed by the entire
enterprise. For example, a human resources application that's directory enabled is likely to be
used only by the HR Department. AD LDS is a good candidate for this type of application
because there's no need to modify the schema in AD DS.
Perhaps you want to evaluate an application that requires directory support. In this situa-
tion, installing the application in a production environment that modifies the schema is not ideal.
After new objects and attributes are created in an Active Directory schema, these changes
remain, even if the application is no longer needed. With AD LDS, you can install the role on a
server, evaluate the application, and then remove the role with no disturbance to your existing
infrastructure.
Besides supporting directory-enabled applications, AD LDS can be used for a host of other
purposes:
•
Authentication for Web applications
—Although AD LDS doesn't support using Windows
security principals for accessing network resources, it does support using user objects to
store identity information for external applications. For example, your company hosts a
Web portal application that requires authenticating external users who need access to cor-
porate business applications. AD LDS can be deployed on servers outside the corporate
firewall along with Web servers requiring its authentication services. The Web applications
can run on any platform that supports LDAP.
•
Directory consolidation
—Large organizations might have several sources of user identity
information, including multiple forests, phone directories, other LDAP directory services,
human resource databases, and so forth. AD LDS can be used with a metadirectory service,
such as Microsoft Identity Integration Server (see
http://technet.microsoft.com/en-us/
miis/default.aspx
for more on this service), to consolidate identity information from multiple
sources. A directory-integrated application then has a unified view of all these identity
sources through AD LDS.
•
Development environment for AD DS applications
—AD LDS and AD DS are based on the
same code and programming model, so Active Directory-integrated applications can be
developed and tested without the overhead of an AD DS installation. AD LDS is easily
installed and uninstalled on Windows Server 2008 computers and doesn't require ancillary
services, such as DNS.
•
Migration of legacy X.500 applications
—AD LDS supports some X.500 naming conven-
tions not supported by AD DS. Legacy applications requiring these features can be migrated
from older LDAP servers to AD LDS and eventually, if needed, to an AD DS environment.
12
AD LDS is installed on a Windows Server 2008 server by adding the Active Directory
Lightweight Directory Services server role. It can be installed on all editions of Windows Server
2008 except Windows Web Server 2008 and Itanium. It's a good candidate for deployment on a
Server Core installation or as a virtual machine in Hyper-V.
Although you can install AD LDS on a domain controller, it's not recom-
mended. AD DS should, when possible, be installed on a server as a solitary
role (along with DNS, as necessary).
Search WWH ::
Custom Search