As a network administrator, you will be called on to decide when it is appropriate to use AD LDS and when AD DS is required. Consider using AD LDS in the following situations:
■ You need to provide support for departmental applications that require additional identity information that is of no relevance to any other department within the organization. By integrating the additional information in an AD LDS instance, you can ensure that the relevant department has access to it without affecting the directory service for the entire organization .
■ You need to provide support for distributed applications that require access to data in several locations. AD LDS provides the same multimaster replication capabilities as AD DS and can be used to support distributed applications .
■ Your organization is running earlier applications that rely on an LDAp directory. You can migrate earlier data to an AD LDS instance and standardize it by using Active Directory technologies .
■ Your applications rely on an LDAp directory. AD LDS can often be hosted on the same server as the application, providing high-speed and local access to directory data. This reduces replication traffic because all required data is local. Also, you can bundle the AD LDS instance along with the application when you deploy it . For example, if you are installing an accounting application that relies 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.
■ You need 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 the need to deploy AD DS in the perimeter. Note that you could deploy either AD LDS or Active Directory Federation Services (AD FS) in this scenario.
■ You need to provide data associated with user accounts in Ad DS and require extensions to the Ad DS schema to support this data. Using AD LDS in this scenario, you can provide the additional user data without modifying the AD DS schema. For example, if you are installing an application that provides biometric data for each employee in your organization and associates each set of data with the relevant user's AD DS account, you can store the data in an AD LDS instance in a central location . The data sets are associated with the user accounts in AD DS, but because they are in AD LDS, they are not replicated with other AD DS data, hence reducing bandwidth requirements for replication .
■ You need to provide support for local development. AD LDS can be installed on client workstations. This enables you to provide your application developers with portable single-instance directories they can use to develop custom applications that require access to identity data.
Typical applications in which you might use AD LDS include white-page directories, security-oriented applications, and policy store applications. AD LDS is more portable and manageable than AD DS and, if an AD DS solution requires schema modifications, consider using AD LDS instead.
Was this article helpful?