Module 12:Designing an AD LDS

Implementation

Module Overview

• AD LDS Deployment Scenarios

• Overview of an AD LDS Implementation Design

• Designing AD LDS Schema and Replication

• Integrating AD LDS with AD DS

Lesson: AD LDS Deployment Scenarios

• What is AD LDS?

• AD LDS Usage

• LDAP-Compliant Application Directories

• Extranet Authentication Scenarios

• Using AD LDS for Developing Schema Modifications

What is AD LDS?

Key features:

• Flexibly supports directory-enabled applications

• Does not require the deployment of domains or domain controllers

• Can run multiple instances concurrently on a single computer

AD LDS is an LDAP directory service that provides flexible support for directory-enabled applications, without the requirements of AD DS

AD LDS is an LDAP directory service that provides flexible support for directory-enabled applications, without the requirements of AD DS

• Can use AD DS for the authentication of Windows security principals

• Can be used by AD FS as an authentication store

AD LDS Usage

AD LDS is most commonly used as a solution to the following requirements:

• Providing an LDAP-based application directory

• Providing an extranet authentication store

• Consolidating identity systems

• Providing a schema development environment for AD DS

• Providing a configuration store for distributed applications in Windows Server

• Migrating legacy directory-enabled applications

LDAP-Compliant Application Directories

Applications may be either:

• Directory-aware—capable of reading an LDAP directory

• Directory-enabled—capable of reading and performing other defined LDAP operations on a directory

Directory service—a solution that offers users access to the information stored in the directoryDirectory service—a solution that offers users access to the information stored in the directory

LDAP—a directory standard founded on the legacy X.500 directoryLDAP—a directory standard founded on the legacy X.500 directory

Extranet Authentication Scenarios

AD LDS can be used as an extranet authentication service in the following scenarios:

• Hosting user objects that are not Windows Security principals

• Using AD LDS as the authentication store with corporate account credentials provisioned on instance

• Deploying AD LDS as an extranet authentication store for AD FS

Using AD LDS for Developing Schema Modifications

AD LDS can be used to develop and test schema modifications for AD DS:

• Test schema compatibility of applications

• Stage and test Active Directory–integrated applications

• Test Active Directory integration with AD LDS

Lesson: Overview of an AD LDS Implementation Design

• Key Sizing Factors for AD LDS Servers

• AD LDS Replication Scenarios

• Integration of AD LDS with AD DS

• Guidelines for Designing AD LDS Instances and Application Partitions

Key Sizing Factors for AD LDS Servers

When determining the size of your AD LDS implementation, follow these guidelines:

If server performance is less important than the number of deployed servers, consider deploying multiple instances on one computer

For best performance, deploy instances on separate computers

Use x64 hardware and operating system

Allocate sufficient CPU power for processing queries

Allocate enough memory to cache the entire database

AD LDS Replication Scenarios

Key points for AD LDS replication:

• AD LDS instances replicate data based on participation in a configuration set (CS)

• AD LDS replicates on an independent schedule from AD DS

• AD LDS instances in a CS can replicate any number of application directory partitions

• Directory partitions cannot be replicated between AD LDS instances and AD DS domain controllers

Use AD LDS replication in the following scenarios:

• Providing load balancing

• Providing fault tolerance for AD LDS data

• Spanning multiple geographical location

Integration of AD LDS with AD DS

To integrate AD LDS with AD DS, follow these guidelines:

Use AD DS groups to assign permissions in AD DS whenever possible

Ensure that AD LDS users with AD DS accounts can be authenticated against an AD DS domain controller

Implement synchronization between AD DS and AD LDS to simplify management

Use user proxy objects

Synchronize data from an AD DS forest to a CS of an AD LDS instance with Adamsync.exe

Guidelines for Designing AD LDS Instances and Application Partitions

When designing AD LDS instances and application partitions, consider the following guidelines:

If applications have incompatible schemas, deploy additional instances

If applications have compatible schemas, consider deploying multiple application partitions in an instance

If applications require different schemas, a separate AD LDS instance must be deployed for each application

Lesson: Designing AD LDS Schema and Replication

• Schema Changes and AD LDS

• Replication of AD LDS Data

• Planning AD LDS Replication Traffic across WAN Links

• AD LDS Sites and Site Links

• Guidelines for Designing AD LDS Schema and Replication

AD LDSAD LDS

Schema Changes and AD LDS

Test schema changes in AD LDS before moving them to AD DS

AD DSAD DS

11 22 33

Replication of AD LDS Data

AD LDS uses multimaster replication:

• All instances are writable

• Changes on one instance are replicated to the other instances

AD LDS servers replicate changes to

all serversClient adds “User 2” on

Server 1

Client modifies “User 1” display

name on Server 2

Server 2Server 1

Server 3

Planning AD LDS Replication Traffic across WAN Links

Before designing AD LDS replication over WAN links, consider the following key points:

Create a site for every physical location that is connected through WAN

Implement site links

Use site link costs

Use scheduled replication

Provide sufficient bandwidth for WAN links between sites

Site BSite A#

Site BSite A

Site BSite A

AD LDS Sites and Site Links

The following components influence AD LDS replication:

• Site objects

• Site link objects

• Site link costs

Guidelines for Designing AD LDS Schema and Replication

When designing AD LDS schema and replication, consider the following guidelines:

Use AD LDS to test schema compatibility issues before implementing applications in AD DS

Import only the required schema definition files for each instance

For applications that require a custom schema, create LDIF files to make the schema modifications

AD LDS sites and site links should be designed using the same logic that is used for designing sites in AD DS

Lesson: Integrating AD LDS with AD DS

• User Proxies in AD LDS

• Authentication and Authorization in AD LDS

• Implementing Synchronization between AD DS and AD LDS

AD LDSAD LDS

User Proxies in AD LDS

AD DSAD DS

User proxy object

AD DS account

Verify account

Verify password

• User proxy object maps to AD DS account

• Application performs an LDAP Bind operation for authentication of that user in AD LDS

• Account is verified locally—the password is checked against AD DS

You can view, grant, and deny access control on an object-by-object basis by using:

Authentication and Authorization in AD LDS

You can bind to an AD LDS instance:

• As an AD LDS security principal

• As a Windows security principal

• Through an AD LDS proxy object

• Dsacls

• LDP.exe

Implementing Synchronization between AD DS and AD LDS

To integrate AD DS and AD LDS:

Prepare AD LDS for synchronization

Prepare the configuration for AdamSync

Run the ADAMSync utility to synchronize the data

11

22

33

Lab: Designing an AD LDS Implementation

• Exercise 1: Designing and Configuring AD LDS Replication for Internal Applications

• Exercise 2: Designing and Configuring AD LDS Replication for External Applications

• Exercise 3: Designing Highly Available LDAP Services for Multiple Applications

• Exercise 4: Discussions about Exercises 1-3 design decisions

Estimated time: 75 minutes