Active Directory Lightweight Directory Services

Provides a data store for directory-enabled applications that do not require AD DS and do not need to be deployed on domain controllers. AD LDS does not support Global Catalogs, Group Policy, domains, forests, or domain trusts. Management cannot be performed using Active Directory Users and Computers. Tools such as ADSIEdit or LDP.exe or a custom front end need to be used. AD LDS is set up to run as a standalone application service,and not a critical system-level service. AD LDS can be stopped or started on demand without having to reboot the machine. You can also control what ports the LDAP service is listening on.

Terms

Instance: An instance is a single installation of AD LDS on a server.Each server can have multiple instances of AD LDS installed they will all be independently managed and use different LDAP and LDAPS ports.

Configuration set: A collection of AD LDS instances that replicate with each other and share a common Schema and Configuration container. Application partitions can be shared among the instances that make up the configuration set as well.

Replica: An instance of AD LDS that is part of a configuration set and replicates with other AD LDS instances.

Partition/naming context: A unique namespace named after the root DN. AD LDS will have at least two partitions per instance: the configuration and schema partitions. AD LDS can also have multiple application partitions.

Application partition: A type of partition that contains application data. AD LDS can have multiple application partitions per instance.

Configuration partition: A type of partition that contains configuration data for the instance or configuration set.

Schema partition: A type of partition that contains the class and attribute definitions.

Bindable object: An object instantiated from an objectClass that has msDS-BindableObject listed as a static auxiliary class in the schema definition for the objectClass. The most common bindable object is the user class. Objects of this type are authenticated by AD LDS directly.

Bindable proxy object: An object instantiated from an objectClass that has msDS-BindProxy listed as a static auxiliary class in the schema definition for the objectClass. The most common bindable proxy object is the userProxy class. Objects of this type are authenticated by AD LDS by proxying the authentication request to Windows.

No SRV Records

AD LDS does not register SRV records in DNS.Instead AD LDS can publish serviceConnectionPoint objects in Active Directory for resource location. These are objects in Active Directory that are usually published under the computer object on which the service is installed. The serviceConnectionPoint objects maintain key pieces of information about the AD LDS installation in the keywords and serviceBindingInformation attributes.

No Global Catalog

AD LDS has multiple partitions, but it does not have a global catalog. The Windows LDAP server accepts a special LDAP control setting that allows you to use one single query that will scan across all of the partitions of an AD LDS instance. Available only to LDAP API�based applications. Loss of the global catalog also impacts a special protocol used by Outlook and Exchange.The Name Service Provider Interface and the backend Address Book support functionality are only provided in the Global Catalog.

Group and User Scope

The scope of an AD LDS group or user is limited to the partition in which it exists.You can,add Windows security principals and AD LDS security principals from the configuration partition to the groups in other partitions.

FSMOs

In an Active Directory forest, you have two FSMOs for the entire forest and three FSMOs for each domain. AD LDS,only has two FSMO roles regardless of the number of partitions or the number of replicas. The two are the naming master and the schema master,whose roles map to the Active Directory domain naming master and schema master. Instead of using RIDs, AD LDS has an algorithm based on the GUID generation algorithm to generate unique SIDs. Instead of the SIDs having just a unique RID, the last four subauthorities in the SID are all generated for each user. While one or more of those subauthorities may match those of other groups or users, there should not be a collision with all four values because AD LDS tries to enforce the uniqueness. This means a RID master is not needed.

Schema

The default AD LDS schema is very small in comparison to the default AD schema.Microsoft supplies LDIF files with AD LDS so you can build up the schema to instantiate some Microsoft standard objects. You can also have multiple schemas on a single machine with AD LDS. Each instance of AD LDS can have its own schema, and you can install multiple instances. AD LDS,has both configuration and schema partitions.There is no root domain or root partition, so the names of these critical partitions are based on a randomly generated GUID.

Authentication

Any object can be used for binding, as long as it is derived from a class that includes the msDS-BindableObject auxiliary class in the schema definition and has a valid password value set for unicodePwd. AD LDS bindable objects can only use simple bind or digest authentication. If you want secure binding with AD LDS users or other AD LDS bindable objects without digest authentication, you must set up a certificate and encrypt the communication channel using SSL. To use secure authentication without SSL, you have to use Simple Authentication and Security Layer binds with Windows local or domain users. Default, an AD LDS user can be authenticated over the standard LDAP port with a clear-text simple bind. You can override this and force an SSL requirement by setting RequireSecureSimpleBind=1 in the msDS-Other-Settings attribute of the object CN=Directory Service,CN=Windows NT,CN=Services,CN= in the configuration partition. AD LDS allows you to configure a bindable proxy object that links to a Windows user. The user can use a simple bind to AD LDS, which then proxies the authentication request to Windows in a secure manner. Bindable proxies will also proxy password changes back to AD. Unlike with AD LDS user simple-bind authentication, the default for using a simple bind for userProxy objects is to require an SSL connection. This can be overridden by setting RequireSecureProxyBind=0 in the msDS-Other-Settings attribute of the CN=Directory Service object.